Archivo de la etiqueta: desarrollo

Instalar App Android en Tarjeta SD Externa

 

Recordar, los 3 valores posibles son:

 

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:installLocation="preferExternal|auto|internalOnly"
    ... >

preferExternal: Se instalará en la memoria SD externa excepto en el caso que no haya espacio suficiente disponible.

auto: Se instalará en la memoria interna o externa en función de varios factores de configuración de nuestro dispositivo.

internalOnly: Es la opción por defecto. Se indica explícitamente que la aplicación se instalará en la memoria interna.

 

Cheli

Curso de Desarrollo en OpenERP

Estoy ofreciendo cursos de desarrollo en OpenERP. He empezado con una modalidad de mini cursos con el siguiente temario:

 

Sesion 1: Introducción a OpenERP

  • Arquitectura de OpenERP.
  • MVC de OpenERP.
  • Integración de Módulos.
  • Extendiendo el Modelo (herencia).
  • Extendiendo la Vista (herencia).
  • Definición de un módulo.
  • Objetos, atributos y métodos.
    •  ORM
  • Vistas.

 

Sesion 2: Ventanas 1

  • Extender una ventana.
  • Tipos básicos.
    • Añadir un campo.
    • Eliminar un campo.
    • Modificar un campo.
  • Tipos relacionales.
  • Crear una ventana nueva.
  • Internacionalización.

 

Sesion 3: Ventanas 2

  • Más tipos relacionales.
  • Gestión del modelo mediante métodos del ORM
    • Crear (create).
    • Borrar (unlink).
    • Modificar (write).
    • Recuperar (browse).
  • Disparadores.

El precio de cada sesión es de 110€, haciendo un total de 330€ si se quiere realizar el curso entero. El curso consta de varios vídeos explicativos en los que se proponen una serie de ejercicios prácticos. Cada vez que se completa una sesión se os envían las diapositivas utilizadas en las explicaciones y el código de las soluciones a los ejercicios. Adicionalmente se pueden realizar preguntas sobre las explicaciones que se resolverán por correo-e o por conferencia.

 

Cheli

¿Qué hace que un proyecto y su plataforma de desarrollo fracase?

Son cosas que todos sabemos pero que sigo viendo en muchos proyectos, algunos de ellos se han hecho bastante populares.

  1. Debe estar documentada. Es de perogrullo pero es una cosa que a ningún desarrollador le gusta hacer pero es lo primero que buscamos cuando estamos programando. Un API sin documentación no sirve de mucho. Ejemplos de bibliotecas que triunfan y tienen una gran documentación y puede que parte de su éxito sea justamente este detalle son PHP, QtJava.
  2. Compatibilidad a lo largo del tiempo. Un api de programación tiene que ser estable a lo largo del tiempo, si se empiezan a cambiar las interfaces de los métodos o funciones, se crean incompatibilidades binareas, etc esta biblioteca nos dará muchísimos quebraderos de cabeza. Lo que suelen hacer algunos fabricantes es que durante la versión mayor de una biblioteca se mantiene la compatibilidad y cuando se pasa a la siguiente versión mayor ya si que se puede añadir lo que se quiera porque se permite la incompatibilidad con la versión anterior.
  3. Debe facilitar la actualización. Cuando se crea una nueva versión se debería pensar en la forma de actualizar desde la versión anterior de manera que luego no existan problemas en las migraciones.
  4. No se pueden dejar funcionalidades a medias. Si empiezas un desarrollo y no lo terminas no puedes dejar la aplicación llena de partes de dicho desarrollo pero que en verdad no sirven de nada.
  5. El código fuente debe estar en inglés. Habrá gente que no le guste pero el idioma internacional para la tecnología es el inglés y es el que todos los desarrolladores suelen entender. Si tu código está en otro idioma estás cerrando puertas para que otros desarrolladores entren al proyecto.

Existen muchos más problemas asociados pero estos 5 me parecen fundamentales. En Openbravo me he encontrado estos y nos está afectando actualmente en varios proyectos en los que estoy metido en mi empresa.

Ante el primer problema y preguntando diréctamente cómo funciona tal método de una clase a desarrolladores de Openbravo, gente que lleva trabajando para la empresa Openbravo desde hace bastante tiempo y que están en el equipo de ingeniería la respuesta es – No lo se, yo pillo un ejemplo parecido que ya esté hecho y copio y pego. A la pregunta de si estaba documentado la respuesta era no y que en todo caso se iban a la propia definición en el código de la biblioteca.La culpa no es de ellos, la culpa es de que el que escribió las bibliotecas y herramientas que utilizan no las documentó y actualmente no hay ningún recurso en Openbravo para documentarlas.

El segundo caso me pasó cuando intentamos utilizar un informe que desarrollamos según las indicaciones del wiki de Openbravo, este informe funcioaba perfectamente en la versión 2.35 pero al intentar compilarlo en la versión 2.40 no funcionaba. El problema venía porque habían modificado unos atributos privados de la clase base  de la que heredaba la clase que lanzaba el informe. En verdad habían hecho bastante limpieza en esa clase y si a eso le añadimos que a los atributos no se accede mediante métodos públicos, una interfaz pública pues no tiraba. Lo suyo es que como se comenta más arriba se mantenga el api de todas las bibliotecas que se utilizan en el proyecto a lo largo del tiempo. Se podría refactorizar el código pero siempre que mantuvieras las interfaces de las clases, pero es que en muchos casos ni siquiera hay interfaces bien definidas.

El tercer caso me ha pasado al intentar actualizar Openbravo, se supone que Openbravo utiliza un fork propio de ddlutils para la manipulación de la información en la base de datos. Su actualizar de la 2.40beta  a la 2.40 funcionaba  a la perfección con la instalación de la 2.40beta limpia pero si intentaba aplicarlo sobre uno de nuestros proyectos me dió un error tan chorra como que un campo que no era único había pasado a ser único en una tabla y al detectar duplicados no podía terminar el proceso de actualización de la base de datos dejándola en un estado inconsistente. Este tipo de cambios no se deberían dar en una base de datos medianamente estable, pero si se dan y quieres hacerlos debes tener mucho cuidado de que no existan problemas al actualizar.

El cuarto caso es muy típico en Openbravo, la aplicación está plagada de campos, ventanas/pestañas que no sirven para nada pero que por alguna extraña razón alguien dejó ahí. Esto a parte de confundir al usuario da una sensación de dejadez impresionante. Aquí os dejo un ejemplo.

El quinto caso sigue ocurriendo en Openbravo, han ido limpiando muchas partes del código pasándolo al inglés pero todavía queda mucho trabajo por hacer, sigue habiendo mucho código en castellano.

¿Qué problemas soléis encontrar vosotros en los proyectos en los que estáis?

Cheli

Tanteando realizar cursos de Openbravo

Estoy planteándome empezar a dar cursos de Openbravo, la emrpesa Openbravo ya realiza una serie de cursos pero tienen algunos inconvenientes. El primero es que son muy caros y el segundo es que se realizan en Madrid, Barcelona o Pamplona.

Lo que me he planteado es dar dos cursos, uno de funcional y otro de desarrollo básico a un precio alrededor de un tercio de lo que oferta Openbravo. Para que os hagais una idea estos cursos en Openbravo salen por 2.490€ y tienen una duración de 5 días.

Los cursos que yo planteo serían los viernes por la tarde y sábados por la mañana durante 4 semanas en Alicante por lo que seguimos teniendo el problema de localización pero ahora con una alternativa nueva (Alicante) y en otro horario (viernes tarde y sábados mañana). Me gustaría que me digerais si os resulta interesante y si pensáis que tendrían buena acogida para así poder empezar a prepararme el material necesario (apuntes, local, datos de ejemplo, ejercicios).

 

Actualización: Finalmente tenemos el curso de desarrollo en formato  de videos guiados.

 

Cheli