soft·in·spain

El proceso de preparar un entorno para el desarrollo web en equipo está resultando más complicado de lo que suponía. Todavía no hemos podido empezar con Scrum, se me está haciendo eterno.

Hasta ahora del desarrollo web del producto que queremos tratar con Scrum se encargaba una persona, esta utilizaba un servidor linux (CentOS) interno para ello, desde su máquina Windows editaba el código, lo subía al servidor para probarlo y depurarlo, y finalmente lo subía al servidor de producción, también CentOS, cuando se daba el visto bueno. Ahora como vamos a ser varias personas trabajando con el mismo código necesitamos otro entorno.

En principio opté por Windows como SO de escritorio, instalando XAMPP y EclipsePDT. Pero nos hemos encontrado con muchos problemas, demasiados, para poder ejecutar el software allí. Y, sobre todo, me quedaba la duda de que problemas futuros nos encontraríamos cuando en el entorno Windows el software funcionara pero al pasarlo al CentOS no, el trabajo extra de hacerlo funcionar en dos platarformas sin necesidad real.

Por ello hemos decido hoy poner CentOS como entorno de desarrollo en los ordenadores, claro que eso implica un retraso, pero creo que lo recuperaremos rápidamente al ganar en compatibilidad con los servidores.

Básicamente la idea es que cada desarrollador tenga en su máquina un servidor web completo, para que desarrolle, pruebe y depure en local, luego cuando lo tenga lo suba al servidor subversion y de ahí se pueda sacar una copia diaria al servidor de pruebas interno.

¿Es esa la mejor forma de trabajar? ¿Sabéis como lo hacen en otros equipos? ¿Alguna idea?

En Arcadina tenemos un proceso a base de scripts en Python para la compilación del programa de gestión para fotógrafos PhotoGestión. Los scripts se encargan de lanzar la compilación del código fuente en todas las variantes del programa (con el dcc32 de Delphi), de lanzar el compilador del proceso de instalación (InnoSetup), de hacer las imágenes ISO para grabar los CDs (cdrtools win32) y de subir ví­a FTP a nuestro servidor los ficheros de actualización.

Esta semana pasada lancé el proceso, no se hace de forma automática sino cuando queremos publicar alguna mejora o corrección, y todo funcionó bien menos el subir por FTP.

Subí­a el primer archivo de 6 y se quedaba ahí­, esperando. Entrabas en el directorio del servidor y comprobabas que el fichero tení­a el tamaño adecuado, pero el script no avanzaba. He de decir que se utiliza el ftplib de Python para realizar esta labor.

Si lo subí­a con el FileZilla todo perfecto, si lo hací­a desde linea de comandos con el ftp de Windows también, pero no con el Python. Me actualicé a la última versión, y nada, continuaba igual.

Hasta que ayer domingo, si domingo, caí­ en la cuenta… ¿Que habí­amos cambiado para que dejara de funcionar? ... Pues el servidor interno de la empresa, que ahora hace de puerta de enlace. Fue volver a poner el anterior gateway, un SMC barricade que ya tiene 5 años, cambiar la configuración IP y volver a funcionar todo.

¿Porque me empeñe en buscar el problema en algo que habí­a funcionado sin fallos durante mucho tiempo? ¿Porque no pensé en el cambio que habí­amos hecho la semana anterior? Debe ser deformación profesional, el buscar siempre en el software.

Desde hace unos dí­as en varios blogs se viene comentando el tema de los programadores, de lo difí­cil que es encontrar a buenos, etc.

El otro dí­a leí­ en Presión Blogosférica un post con en el que no puedo estar más que de acuerdo.

Hoy en el blog de Jose Luis Sánchez comenta otro aspecto del asunto.

Llevo 15 años viviendo de desarrollar software, pero siempre como autónomo. No puedo opinar de como se trabaja en una gran empresa, nunca lo he hecho, pero si he trabajado con y para pequeñas empresas, debo haber tenido mucha suerte porque en todas ellas se valoraba muy bien mi trabajo. Aunque por lo visto eso es una excepción, lástima.

Siempre he visto la programación más como artesaní­a que como cadena de montaje, ya lo comenté hace un tiempo, por lo tanto has de poner ganas, ilusión en lo que haces o se puede convertir en una tortura, como en todo trabajo ¿no?.

No creo que falten programadores, faltan buenos programadores, no estoy diciendo que yo lo sea, pero ahora como director de proyectos/empresario lo veo a diario, ves a quien se limita a realizar su trabajo y quien pone toda la carne en el asador para intentar hacer el mejor código y mejor producto que pueda. Yo lo llamo autoexigencia, creo que si no lo tienes no puedes ser un buen programador.

Nunca he sido de los ortodoxos a la hora de programar, en cada caso he buscado la mejor solución para el problema en cuestión aún sabiendo que no era lo que marcan los cánones.

Como he comentado, estamos utilizando InstantObjects como ORM, pero hay aspectos que requieren ciertas mejoras, por ejemplo cuando queremos realizar búsquedas complejas. Al menos yo no he conseguido que dichas búsquedas se realicen a una velocidad aceptable.

Después de varias pruebas he optado por hacer un bypass de InstantObjects y consultar directamente la base de datos. Se que no es correcto, que si estoy trabajando con objetos no deberí­a en ningún caso saber como es la estructura en la que se almacenan dichos objetos en la base de datos, pero es que tengo una maní­a, me gusta que los programas sean ágiles, que las consultas no tarden más de 2 segundos en responder, cosas mí­as.

El caso es que en algunas ocasiones me interesará tratar con objetos y en otras con consultas SQL. Para los reports y grids me interesa (siempre por cuestiones de rendimiento) consultar directamente la base de datos y cuando el usuario localiza el dato que quiere, a partir de ahí­ si que todo son objetos.

Por cierto, he descubierto un componente para mostrar datos muy bueno, Virtual TreeView, lo único es que hay que currarse el proceso de carga de datos, pero luego funciona muy bien. Prueba de ello es que se utiliza en el propio IDE de Delphi. Muy recomendable.

He decidido que, siempre que se pueda, utilizaré componentes y librerí­as OpenSource para las aplicaciones. He puesto la puntilla de “siempre que se pueda” porque hay ocasiones en las que no encuentro equivalentes OpenSource para determinados componentes, como por ejemplo, para listados, informes y documentos, estoy investigando “FastReports”

De momento estos son los componentes, librerí­as y aplicaciones que estoy utilizando:

• TortoiseSVN Cliente de subversion para el control del código fuente
• Subversion Servidor para el control del código fuente
• InnoSetup para preparar los instaladores
• Python para el proceso de compilado y empaquetado. Utilizo varias librerí­as para python que permiten desde subir por FTP las aplicaciones hasta crear imágenes ISO preparadas para grabar en CD
• DUnit para las pruebas unitarias, aquí­ una buena explicación de como funciona DUnit.
• Firebird, fantástica base de datos, con un tamaño mí­nimo tiene un rendimiento muy bueno y unas funcionalidades como los mejores.
• JVCL la famosa JEDI.
• Virtual TreeView, ya lo he comentado
• Indy, para todo lo relacionado con comunicaciones TCP/IP

• DelphiZip para manejar ficheros ZIP, para copias de seguridad, intercambio de información, etc.

  Pendiente de probar:

• Pages para imprimir Visual TreeView (en este punto todaví­a estoy trabajando)
• Gráficos de barras, tartas, lí­neas, etc. de momento tengo pendiente de probar estos dos:
  • XYGRAPH

• RiverSoftAVG

  Nuestra intención es colaborar en lo posible con dichos proyectos OpenSource, como lo estamos haciendo con InstantObjects.

Comentaba hace un tiempo que habí­amos decidido utilizar tiOPF como capa de persistencia para PhotoGestión, al final no ha sido así­. No terminó de gustarme como se planteaban determinadas cosas.

Entre unas cosas y otras el proyecto se habí­a ralentizado, casi detenido, ahora lo hemos relanzado de nuevo, con la incorporación de un nuevo programador, y hemos decidido cambiar el ORM, ahora estamos investigando InstantObjects y de momento mucho mejor, más similar a como querí­a yo que fuera el ORM a utilizar.

Contaré por aquí­ como vamos avanzando, y algún que otro detalle, estamos pensando incluso en colaborar con el desarrollo de la librerí­a porque creo que podemos aportar algo.

Cuando tienes una base de usuarios que se han habituado a un interfaz determinado, hay que pensar muy bien el introducir cambios radicales.

A raí­z de lo que está ocurriendo con el Office 2007, todaví­a me confirmo más en dicha afirmación.

También ha ocurrido con el IE7, la primera vez que entré, lo encontré raro, no sabí­a porque, hasta que me di cuenta que no tení­a menú.

Recuerdo el cambio de Windows 3.11 a Windows 95, el no encontrar nada, no saber como moverme, claro que con el tiempo pues te acostumbras, y cuantos más sistemas manejas, ocurre como con los idiomas, mejor se te da el aprender uno nuevo.

Tení­amos previsto para nuestro producto PhotoGestión hacer un cambio que creí­amos serí­a bueno porque daba al producto más potencia en el acceso a los datos y, porque no negarlo, una apariencia más moderna.

Pero la realidad es muy cabezona y nos dice que las personas somos (unos más, otros menos) reacios a los cambios, los rechazamos de entrada, porque nos hace sentir incómodos, perdidos, desorientados. En definitiva, que vamos a realizar los cambios de forma gradual, sin grandes estridencias.

Como dice RBA : “Lo curioso es que estas cosas pasan”.

Yo digo que no es “curioso”, sino lamentable, que corto se queda el lenguaje, a veces. Y como en otras ocasiones sobran las palabras.

Leyendo la impresionante (por el contenido) presentación de la arquitectura de eBay (ví­a Tecnorantes) he visto reflejada parte de mi filosofí­a de programación (que no siempre he podido seguir, por desgracia).

Uno de los puntos que más me ha gustado leer es lo de: “No stored procedures”. Es algo que siempre me ha parecido incorrecto, el poner parte de la lógica de la aplicación en la misma base de datos, lo he hecho, claro, pero nunca me ha gustado. Primero: creas una dependencia con el sistema de base de datos elegido. Segundo: cargas al servidor de base de datos con un trabajo extra, que en determinados entornos no es conveniente. Tercero: Te obliga a programar en lenguajes que en muchos casos, veáse TransactSQL, son una birria para desarrollar y no digamos para depurar (_aunque últimamente esto ha cambiado_)

Desarrollar la lógica separada de la base de datos tiene la ventaja que puedes utilizar una infraestructura n-tier, puedes manejar el repositorio de código fuente mejor, es más fácil incorporar nuevos programadores puesto que todos desarrollan en el mismo lenguaje, puedes reaprovechar código…

Una buena recomendación, en la mayorí­a de los casos.

Los dí­as 30 de junio por la tarde y 1 de julio por la mañana tendrá lugar un curso de Ruby on Rails en Valencia, en el Colegio Oficial de Ingenieros de Telecomunicaciones.

Más información en el blog de Vicent Gozalbes

Yo ya me he apuntado… A ver si retomo el tema porque desde que hice los primeros pinitos ha pasado algo de tiempo.

Desde hace poco tengo interés por hacer aplicaciones web porque estoy convencido que en el futuro todo será on-line, en esto soy casi novato porque profesionalmente siempre he hecho aplicaciones de escritorio (Windows), y lo poco que he hecho en web me he basado en PHP y modificando sistemas CMS ya existentes (Xoops, osCommerce, PHPNuke, etc.), a ver si con el curso me animo y lanzo alguna cosilla de las que tengo en mente.

Un aspecto de la informática que siempre me ha fascinado ha sido la búsqueda de formas para mostrar información al usuario.

Ví­a The Business of software llego a éste blog donde se dedican a recopilar capturas de pantalla de cuadros de mando o dashboards.

Una fuente de inspiración.