2.50MP25 md5
Cheli
Los problemas de siempre con merges en Openbravo ERP
Ya hablé en su día de porqué el sistema de módulos no aportaba nada nuevo al desarrollo de Openbravo ERP. Entre otras cosas hablaba del problema de los merges y como se trasladaba el problema del core a los módulos. Esta vez me ha tocado sufrirlo en un módulo de Philanthros ERP, pero hagamos un poco de historia.
Philanthros ERP es un desarrollo que se encargó a Openbravo para la versión 2.40. Openbravo también ha sido el encargado de migrarlo a la versión 2.50 y generar las plantillas y módulos actuales. Aunque digo que es Openbravo el que ha desarrollado Philanthros no os penséis que son los encargados del desarrollo del core, ni mucho menos, los encargados fueron los que pertenecen a lo que Openbravo llama Custom. Esto no es más que tener su propio equipo de consultoría y desarrollo dentro de casa, vamos lo mismo que puede hacer cualquier consultoría al uso de las que ya conocemos. De hecho se nota mucho que han sido estos quién han hecho el desarrollo por algunas chapucillas la baja calidad del código en muchos aspectos. Informes mal internacionalizados, estilo de código caótico y que no sigue la guía de estilo de Openbravo, código insertado a pelo (hard coded), etc.
Estos días se ha abierto una incidencia sobre el proceso de completar factura de compras en Philanthros ERP. Al revisar el código me he dado cuenta que en su día se personalizó el pl/sql que se ejecuta en este proceso y se renombró como CUS_INVOICE_POST (el original se llama C_INVOICE_POST), este a su vez se insertó en un módulo llamado sales. Pues bueno, cada vez que se ha ido actualizando el core se ha ido parcheando progresivamente el pl/sql orginal, pero el que se personalizó como es natural no ha estado afectado por estos cambios. ¿Qué he tenido que hacer? pues revisar los 33 parches que se han aplicado al archivo original desde septiembre de 2009, que es cuando se creó este fork por llamarlo de alguna forma, e ir integrándolos en la versión en uso.
No os podéis ni imaginar el trabajo de chinos que ha supuesto realizar todo este trabajo al estar tan desvirtuado el archivo personalizado que desarrolló Openbravo, pero bueno, parece que al final lo he conseguido.
Este es el problema de siempre, que cuando personalizas un archivo del core tienes que integrar manualmente los cambios que se le hagan.
Cheli
UPyD y la alcaldía de Alicante
Me he quedado sorprendido al ver que el actual director de la Escuela Politécnica de Alicante, el señor Fernando Llopis, se presenta para alcalde de Alicante por el UPyD. Este señor es el mismo que como profesor de la universidad anteponía sus intereses personales a los de los alumnos, promoviendo en sus asignaturas y en exclusiva los productos de Microsoft en detrimento de que el alumno adquiriera aptitudes generales. Parece que su objetivo siempre fué que los ingenieros informáticos de la universidad de Alicante terminaran siendo desarrolladores y usuarios únicamente de dichos productos, por suerte no lo consiguió.
Ahora que se presenta para alcalde, ¿qué podemos esperar?.
Cheli
Nueva versión de la máquina virtual de Philanthros 2.50MP24
En esta nueva versión se actualiza a MP24 y se actualiza Philanthros ERP a la última versión del trunk. Algunas novedades son:
- Internacionalización del selector de producto.
- Se ha corregido el módulo de esquema contable. Ahora carga el esquema contable sectorial para ONGs.
- También se han corregido los módulos con datos de referencia que no funcionaban como por ejemplo el de impuestos.
Philanthros 2.0 con MP24 Virtualbox.
Cheli
Openbravo 2.40MP12.20
2.40MP12.20 md5
Actualización: Si quieres obtener la última versión de la rama 2.40 ponte en contacto conmigo (cheli en aradaen.com).
Cheli
¿Para que sirve un SAI?
A parte de para lo obvio de mantener la corriente cuando se va la luz o controlar la tensión de entrada, un SAI sirve para mas cosas. ¿No os ha sucedido nunca eso de tener una regleta con interruptor debajo de la mesa y sin daros cuenta pulsar el botón y cortar la luz?, a mi sí.
Lo que me ha sucedido esta noche es aún más curioso. Tenía una botella de agua en el suelo y cuando he ido a cambiarme, al abrir el armario la he tirado con tan mala suerte que ha caido sobre el botón y ha cortado el suministro. En este caso no hubiera pasado nada grave porque no tenía nada importante abierto en el ordenador, pero el SAI me ha salvado del apagón.
Cosas que pasan.
Cheli
Cómo deshacerse de Ubuntu One
¿Qué se hace cuando uno está jodido?
Openbravo 2.50MP24
2.50MP24 md5
2.50MP24 (megaupload)
Nota: Estoy teniendo problemas de ancho de banda, por favor intentar primero el enlace de megaupload y si no funciona utilizad el otro.
Cheli
Ciclo de vida de soporte recomendable para productos empresariales 2
Hace casi un año que escribí sobre que ciclo de vida de soporte sería el recomendable para un producto empresarial. En aquel entonces comenté que 2 años me parecían excesivamente poco tiempo (me refería al ciclo de vida de soporte que tuvo Openbravo 2.35). Ahora Openbravo nos dice que va a tener ciclos de vida de almenos 5.5 años. Es un avance sin duda y es una cosa que mucha gente venía pidiendo desde hace tiempo.
Un día me puse a pensar que versión de las actuales de Openbravo (2.40 y 2.50) le pondría a un cliente nuevo si pudiera tomar yo la decisión. La principal métrica a utilizar sería que número de bugs tiene abiertos y cuantos se cierran en cada actualización. Pues bien, según esta métrica los bugs que se han cerrado en las últimas versiones son:
| 2.40 | 2.50 | |
| 2.40MP12.19/2.50MP24 | 1 | 50 (3 nuevas funcionalidades) |
| 2.40MP12.18/2.50MP23 | 3 | 86 (4 nuevas funcionalidades) |
| 2.40MP12.17/2.50MP22 | 3 | 80 (5 nuevas funcionalidades) |
| 2.40MP12.16/2.50MP21 | 7 | 98 (5 nuevas funcionalidades) |
Esta tabla muestra los datos de las últimas 4 subversiones de Openbravo 2.40 y Openbravo 2.50, si nos vamos moviendo hacia atrás os podéis imaginar que la diferencia se hace mucho más notable. Tampoco os llevéis a error por la numeración, en 2.40 hubo un momento que pensaron que era mejor cambiarla y pasar a versionar con subversión x.y para cambios pequeños y (x+1).0 para cambios grandes, ya que supongo que pensarían que con una numeración muy alta daría la impresión de que habían parcheado mucho. Como veis esto en 2.50 no da lugar porque los cambios siguen siendo tremendos.
Otra diferencia fundamental es que en 2.50 al margen de corregir bugs se introducen en cada versión muchas funcionalidades nuevas, lo que por lógica lleva a tener nuevos bugs y así hasta el infinito. Tampoco penséis que la diferencia es porque salen más paquetes de mantenimiento en una versión que en otra. La periodicidad de las dos versiones sigue un ritmo de más o menos un paquete al mes y ha sido así al menos durante los últimos 10 meses.
Con este panorama no tendríamos ninguna duda de que la versión 2.40 es la mejor opción, pero aún así alguno me dirá «Es que la 2.50 tiene módulos». Si tenemos en cuenta que la mayoría de los módulos que se proporcionan por parte de Openbravo y sus socios tecnológicos en el sistema de gestión de módulos no son libres, y que además yo tengo la política de ofrecer a mis clientes sólo software libre, entonces los módulos existentes no me servirían de nada. Sólo me quedaría el inconveniente de que aplicar actualizaciones y gestionar mis desarrollos es algo más eficiente en 2.50.
El problema es que antes no sabíamos hasta cuando Openbravo iba a soportar la versión 2.40, pero ahora nos aseguran que lo harán hasta septiembre de 2014, lo cual no está mal.
Llegado a este punto pensé, ¿y que hay de la 3.0?. Paolo Juvara dijo que a partir de la versión 3.0rc2 se puede utilizar en producción. Imaginaos el escenario, si yo con lo que os acabo de decir estoy poniendo en duda que la versión 2.50 sea la mejor opción para poner en producción, pues pensad que resultados podría arrojar el mismo análisis sobre una versión que está todavía en desarrollo. Pero no pasa nada, para solventar este problema Openbravo ha llamado a estas versiones RC, que típicamente significa Release Candidate o Versión Candidata, pero que está claro que para Openbravo no significa eso. Estas versiones en cualquier otro proyecto serio se utilizan cuando ya tienes lista la versión final, pero quieres dejar un margen de unos días o una semana para que la gente la pruebe, y en caso de descubrirse un fallo grave se corrige y se lanza la siguiente RC, y así hasta que no hay ningún fallo grave a corregir y se lanza la versión final. La diferencia es que lo que Openbravo llamó 3.0RC1 puede significar perfectamente 3.0 prealfa1 y así sucesivamente hasta tener una beta1 en la MP10 y una versión que podríamos considerar final en una MP30.
Por cierto Paolo Juvara es el nuevo director general y a parte de decir esta insensatez, es el mismo que en su día dijo que un software con licencia MPL (la de Openbravo) no se puede redistribuir. Menudo porvenir tiene Openbravo con esta persona al frente, muy triste.
Y mientras tanto algunos de mis clientes continúan pagando el soporte mientras la versión MP24 sigue sin aparecer en el gestor de actualizaciones, y después de notificárselo el día 2 en soporte, dos después del lanzamiento, a día de hoy todavía no nos han contestado.
Cheli