Java en Centos 5.x

Actualmente para instalar Java en Centos tenemos básicamente dos opciones, una es instalar el Openjdk el cuál lo tenéis disponible desde yum y la otra es instalar java de sun. Os voy a dejar los paquetes de Java de sun x86_64 para Centos con lo que únicamente tendréis que descargar el tar.bz2 y ejecutar:

tar xvfj java_x86-64-centos-1.6.u7.tar.bz2

yum –nogpgcheck localinstall  java-1.6.0-sun-1.6.0.7-1jpp.x86_64.rpm java-1.6.0-sun-devel-1.6.0.7-1jpp.x86_64.rpm java-1.6.0-sun-fonts-1.6.0.7-1jpp.x86_64.rpm

java y md5

Cheli

La extorsión que ejercen algunas compañias

Hace poco he vivido el peor momento colaborando en un proyecto de software libre, y resulta cómico porque lo normal es que colaborar en estos proyectos me resulte divertido, reconfortante además de que aprendo mucho. El caso es que a raiz de realizar unos cursos de formación en Barcelona organizados por la empresa Openbravo decidí montar una bitácora con el nombre obtrainings en honor a los cursos, inicalmente junto a un compañero que conocí en Barcelona,  con la idea de apoyar y retroalimentarnos de la gente que realizara los cursos en el futuro. Al final el único editor de la bitácora acabé siendo yo mismo y la idea inicial terminó diluyéndose y convirtiéndose en una bitácora dónde hablaba de las novedades del producto y dónde escribía artículos y tutoriales de Openbravo ERP.

Pasaron algunos meses y me fuí enterando de algunas cosas siempre por terceras personas, por ejemplo me enteré que algunos directivos de openbravo leían la bitácora ya que me llegaban comentarios del tipo –Oye, ¿sabes que el otro día estuve con tal y me dijo que le gustó el artículo pascual de obtrainings?– donde tal era el directivo en cuestión. Lo bueno era que yo sabía de estas cosas sin que nunca nadie de Openbravo me hubiera dicho nada aunque eso tampoco me importaba, y entonces fué cuando vinieron los problemas.

Igual que escribía artículos contando las bondades que me parecían interesantes de openbravo, escribía artículos donde criticaba los puntos débiles o las cosas a mejorar dentro del sistema y metodologías de desarrollo que se estaban llevando a cabo, siempre con la intención de que se detectaran esos problemas y se corrigieran. Parece que esto no les gustó a esos directivos e igual que no se pusieron en contacto conmigo para decirme que algo les había gustado tampoco lo hicieron cuando les disgustó alguno de mis apuntes de obtrainings. Hasta aquí todo correcto, sólo que a mi me hubiera gustado tener retroalimentación con sus opiniones ya que sin ella se avanza más despacio.

Lo indignante fué que en vez de ponerse en contacto conmigo lo que empezaron a hacer es contactar con mi jefe para decirle que me atara en corto. Se ve que no les quedó claro que cuando yo escribo en mi bitácora escribo en nombre propio, que las opiniones, decisiones o consideraciones respecto a openbravo que haga mi empresa las realizan sus dos socios fundadores y que yo en esas deciones no tengo ni voz ni voto. Que igual que cuando Openbravo tiene que tratar algún tema con mi empresa se ponen en contacto con mis jefes y yo quedo totalmente al margen, cuando yo escribo algo mi empresa está totalmente al margen también, lo que puede significar que mi opinión y la de mi empresa no concuerden en muchos sentidos. Mi rol dentro de la empresa es de consultor y desarrollador, al final hago lo que me mandan y punto lo que no quita que tenga mis propias opiniones.

A lo mejor pensaban que podrían extorsionarme y hacer que dejara de escribir lo que pienso. Eso nunca lo iban a conseguir y como mucho hubieran conseguido que me despidieran, quizá era eso lo que pretendían, no lo se.

Total que después de la tercera reunión con mi jefe por estos temas, cada vez que escribía algo que pensaba que podría no haber gustado a alguien en openbravo ya sabía que al día siguiente tendría otro encuentro. Al principio se que estas llamadas venían de Miguel Magán, pero luego ya ni siquiera me enteraba de quién había venido el mensaje.  Lo que hice es ponerme en contacto con Miguel para decirle que cuando tuviera un problema con lo que yo escribía que se pusiera en contacto conmigo y no con mi jefe con los mismos argumentos de competencias dentro de mi empresa que he expuesto anteriormente. Él me contesto dándome consejos como gran magnate de los negocios (notese la ironía), porque según él debo ser más diplomático. Yo seré muy directo y diré las cosas tal cual las pienso pero por lo menos no intento extorsionar a nadie cosa que él si hizo conmigo.

Al final y después de muchas desilusiones de cómo se estaba llevando el proyecto y al sumarle lo que os estoy contando decidí descontinuar la bitácora. Curiosamente fué en ese momento cuando Openbravo se puso en contacto conmigo por primera vez. Primero Paolo Juvara me escribió para pedirme que siguiera colaborando en el proyecto y pidiéndome que qué podía hacer para convencerme, yo le expliqué lo que estaba pasando y le dije que la decisión ya estaba tomada. Me sorprendio que me comentara que él de estas cosas no se había enterado. Después se puso en contacto conmigo Josep Mitjà, un tío bastante coherente con el que tuve una conversación telefónica muy cordial y aunque no estuvimos de acuerdo en bastantes puntos fué la primera vez que tuve el placer de hablar sobre todos los asuntos que yo comentaba en mi bitácora con una persona de openbravo.

Lo que me ha quedado claro después de este tiempo es algo que ya he comentado alguna vez, Openbravo es una empresa que se ha metido en el software libre porque lo ha visto como una oportunidad de negocio, cosa muy lícita y que yo defiendo, pero que no tiene muy claro las implicaciones ético sociales que esto conlleva y concretamente las consideraciones que debería tomar hacia la comunidad, y me refiero a la comunidad del software libre porque visto lo visto dudo mucho que pueda existir una comunidad de openbravo. Almenos algunos de sus directivos no lo tienen muy claro porque utilizan tácticas sucias al uso en empresas tradicionales.

Por último quiero dar las gracias a la gente con la que me he encontrado en el irc y los foros, entre ellos muchos desarrolladores de openbravo, que me han ayudado y a las que he intentado ayudar en lo que he podido. Ellos no tienen nada que ver con lo que cuento en este apunte, ellos igual que yo son gente que pretendía crear una comunidad alrededor del proyecto y que creían realmente en que eso fuera posible. De nuevo gracias.

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

El tema tabú, los sueldos

Estoy un tanto harto de que en este país , España, sea un tema tabú. La última fué cuando en una conversación mientras comía se comentaba que un empleado de una de las personas que había en la mesa era informático. A la pregunta de cuanto cobraba la respuesta fué, eso no te lo puedo decir, yo inmediatamente increpé, si me lo puedes decir, no me digas que no me lo puedes decir, otra cosa es que no quieras porque es un tema tabú para tí. Entonces va y me dice que eso es un dato personal, bueno entonces ¿si le hubiera preguntado su edad/nombre/etc tampoco me lo hubiera dicho? estoy seguro que si.

Yo como pienso que no tiene la menor importancia que la gente sepa lo que cobro, es más pienso que sería bueno saber lo que cobra la gente porque luego están las leyendas urbanas que en tales puestos de trabajo se cobra mucho y no es verdad o alrevés. Yo cobro 1.117.21€ limpios al mes con las pagas prorrateadas lo que equivale a que si tuviera 14 pagas, que es lo mínimo que tiene todo el mundo, estoy cobrando (1.117.21 x 12)/14= 957,6€ con lo que todavía no llego a mileurista. Si además tenemos en cuenta que esto es lo que cobro desde hace dos meses que fué cuando me renovaron el contrato y que antes cobraba un pelín menos, que hace 8 que fué cuando me renovaron el anterior y cobraba hasta entonces bastante menos y que hace unos 10 estaba a media jornada y cobraba todavía menos pues tenemos que en un año me han subido unas 3 veces el sueldo y sigo cobrando poco, muy poco.

Lo bueno es que viendo como está el mercado aquí en Alicante no me puedo quejar y de hecho dentro de lo que cabe estoy bastante contento.

Otro tema es que entre el alquiler, la comida y demás cositas que hay que pagar las paso un tanto putas pero de eso ya hablaremos en otra ocasión.

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