Archivo para June de 2007

Mascotas y desvaríos

Nuestro compañero de trabajo, Koldo, tiene una mascota un tanto… peculiar: una araña del tipo grammostola.

Personalmente no tendría ninguna mascota en casa, pero esto ni de coña. Pero a lo que voy. Resulta que la araña está en un terrario con la temperatura y humedad controladas y, una vez al día, de comer se le da un grillo.

Pero estos grillos no tienen terrario, vamos, son comida deberían estar en la nevera. Pero claro, un grillo muerto no es aliciente para que la araña coma por lo que tienen que estar vivos, y no sólo eso, sino que tienen que estar a mayor temperatura que la araña para que ésta los vea y pueda cazarlos. Para eso, el dueño de los bichitos ha hecho con un soldador metido en aceite un control de temperatura para los mismos. Buen invento.

Este invento es necesario porque con una temperatura menor que la del terrario, a parte de que la araña no sería capaz de verlos para cazarlos, el grillo en el primer momento que viera moverse a la araña la atacaría para defenderse y sería posible incluso que la matase.

A la conclusión que llegamos fue que un pequeño cambio en las condiciones iniciales, en las condiciones del medio, puede dar la vuelta a los papeles y ser el grillo el asesino de la araña.

Pero no contentos con esto, desvariamos un poco más y no se nos ocurre otra cosa que decir: «Mmm… o sea que si cambiamos la temperatura del despacho del jefe, nos convertiremos inmediatamente en jefes y él en empleado con lo que… una cosa interesante, sí.».

No sé si así escrito os hará algo de gracia, pero a nosotros nos entró la risa floja un buen rato :D .

Cosas infinitas

Hay dos cosas que son infinitas: el Universo y la estupidez humana. Y del Universo no estoy tan seguro.

Albert Einstein, científico.

Binary Bytes

Resulta que los múltiplos y submúltiplos de las unidades del Sistema Internacional, tal y como las conocemos, van de 1000 en 1000 (de 103 en 103).

Pero como en informática van de 1024 en 1024 (de 210 en 210) por su proximidad a 1000 de la potencia de 2 correspondiente, pues no se pueden deberían utilizar los prefijos y sufijos del susodicho Sistema Internacional literamente, es decir, tendríamos que tener unos prefijos específicos para esto.

Y para eso, los señores de la Comisión Electrotécnica Internacional han definido en 1998 unos nuevos prefijos para estas medidas que utilizan las potencias de 2 para los múltipos en lugar de las potencias de 10. Estas unidades están formadas por los prefijos del Sistema Internacional, pero en lugar de añadir bytes (por ejemplo Kilo bytes) hay que añadir binary bytes (por ejemplo Kilo binary bytes). Todos los nombres, abreviaturas y equivalencias son:

Prefijos del SI Prefijos Binarios
Nombre (Símbolo) Valor Nombre (Símbolo) Valor
Kilobyte (KB) 103 Kibibyte (KiB) 210
Megabyte (MB) 106 Mebibyte (MiB) 220
Gigabyte (GB) 109 Gibibyte (GiB) 230
Terabyte (TB) 1012 Tebibyte (TiB) 240
Petabyte (PB) 1015 Pebibyte (PiB) 250
Exabyte (EB) 1018 Exbibyte (EiB) 260
Zettabyte (ZB) 1021 Zebibyte (ZiB) 270
Yottabyte (YB) 1024 Yobibyte (YiB) 280

El uso de estas unidades está recomendado por el IEEE y por el CIPM.

Y como en Linux son muy avanzados ellos, en Gnome al menos, todas las unidades que los archivos ya se expresan mediante estas unidades. Bueno, en realidad las unidades siempre fueron las mismas, es decir, usando potencias de 2 a no ser que se especificase lo contrario, pero ahora ya ponen la abreviatura de la unidad correcta.

Parece que a partir de ahora habrá que cambiar el chip cerebral para poder acostumbrarse a estas nuevas unidades. Que son las mismas, pero con otro nombre.

7-zip

7-zip, ese algoritmo de compresión de datos tan prometedor que te lo venden como si fuese la panacea y además libre, es una auténtica mierda.

Para descomprimir un archivo lleno de música en Mp3 y Ogg (para UltraStarNG) de 2 533 487 895 bytes y dejarlo en 2 667 514 343 bytes (la diferencia es de 134 026 448 bytes, escasos 128 MB) ha tardado la friolera de ¡¡16 minutos y 45 segundos!!

No me quiero ni imaginar cuanto tardó en comprimirse.

Actualización 2007-06-11: Mi amigo BeRt ha hecho una pequeña comparativa de diferentes formatos de compresión en Linux, entre ellos están tar, tar.gz, tar.bz2, rar, zip y 7z.

Organización de proyectos con Subversion

Generalemente, sobre todo en empresas pequeñas, la organización de los archivos de un proyecto, tanto de código fuente como de recursos (imágenes, CSS’s, Javascripts, etc.) viene siendo un caos. En la mayoría de las ocasiones está el directorio principal y todo ahí metido.

Esto de por sí ya es contraproducente a la hora del mantenimiento y extensión de cualquier proyecto con lo que la mejor manera es separar cada parte del proyecto en su directorio correspondiente, de forma que los recursos estáticos (imágenes, CSS’s y Javascripts) estén en varios directorios, los objetos de negocio en otro, las vistas en otro, etc. Incluso cada uno de estos se puede distribuir internamente para facilitar su mantenimiento posterior.

Aquí es donde se aplica esta máxima de la informática que dice: «Divide y vencerás». Divide la localización de tus archivos y vencerás al problema del mantenimiento.

Pero en esto de la organización existe otro problema: el de la gestión de líneas de desarrollo y versiones. Y, como no, existen aplicaciones que nos ayudan enormemente a realizar esta labor, como CVS o Subversion.

Este problema, el de las versiones, se nos ha dado en el trabajo, cuando después de desarrollar una pequeña arquitectura en PHP siguiendo el modelo MVC, hemos desarrollado una aplicación que usa dicha arquitectura. Pero resulta que en un momento dado, la arquitectura cambió lo suficiente (al estar en desarrollo es totalmente normal) que si se aplicaban dichos cambios a la aplicación, ésta dejaba de funcionar y los cambios que había que realizar eran demasiado grandes para adaptarla. Y es por esto por lo que se decidió hacer una versión con lo que ya había para luego seguir con el desarrollo de la rama principal por otro lado.

A priori esto no es más que un diseño lógico de la distribución de los archivos del proyecto, pero Subversion, el sistema de control de versiones que usamos, propone una distribución de directorios de lo más… lógica. Veamos:

  • En cada proyecto se crean tres directorios: trunk, tags y branches.
  • En el directorio trunk se encuentra la rama principal de desarrollo, es decir, la rama donde está la última versión estable y funcional de la aplicación o arquitectura.
  • En tags se hacen copias de la rama principal como versiones independientes. Esto es lo que ha solucionado nuestro problema de la aplicación que usaba la arquitectura en un punto determinado. Ha bastado con hacer la versión 0.1 (tags/0.1) y usarla para la aplicación en cuestión. Esta versión ya no se puede tocar.
  • En branches están versiones en desarrollo, es decir, versiones inestables cuyas características están siendo implementadas. Por ejemplo, se puede hacer un branch especial que pruebe una nueva teconolgía en branches/specialbranch. Una vez que esa tecnología ha sido probada y aprobada para la inclusión en la rama principal, se hace un merge de los distintos archivos en trunk y la rama branch se puede eliminar.
  • La única diferencia entre un tag y un branch es que los tags nunca cambian. En el primer momento que cambien se convierten en branches.
  • En resumen, trunk es la rama principal de desarrollo, tags son versiones estables e inmutables y branches son versiones de prueba de nuevas características.

Este tipo de organización puede parecer compleja o, incluso, innecesaria. Pero en cuanto se empiezan a gestionar varios proyectos que usen las características de otros o que se hagan releases de versiones, esta arquitectura se vuelve imprescindible. Además, Subversion cuenta con comandos que ayudan a realizar todas estas acciones como svn copy ..., svn merge ..., svn move ..., etc.

Lo malo de esto es que no se puede aplicar a nuestro cerebro ;) .

Pintada

La vaca muge y el cerdo grunge.

Pintada en una calle de León. Un poco ofensiva, pero las opiniones son como los culos, todos tenemos uno.

«Beba Colayork»

Chapa de Colayork

«Beba Colayork, exquisita…» es lo que rezaba un cartel de los años cincuenta del siglo pasado en mi pueblo, cuando uno de los primeros grandes empresarios conocidos de El Bierzo, Antonio Guerra, después de su viaje a Nueva York, decidió comercializar una bebida de similar formulación a la de la actual Coca-Cola a la que llamó Colayork.

Por aquel entonces era una bebida demasiado innovadora para los tiempos que corrían y, además, era cuando la competencia empezaba a llegar a nuestro país desde el otro lado del Atlántico. Exactamente no sé como fue la historia del litigio, pero aquel fue el principio de decadencia de las Bodegas Guerra, que no sólo tenían Colayork, sus vinos también fueron harto importantes y, de hecho, aún lo son aunque no bajo el mismo nombre.

Lo único que he encontrado de la Colayork es una pequeña historia de alguien que lo conocía cuando iba por Madrid.

Mi padre recuerda toda aquella historia, recuerda al señor Guerra y beber su Colayork de niño. Y sabía igual que la Coca-Cola. Quién sabe qué se bebería ahora si el litigio lo hubiera ganado Don Antonio.

Instituto Juan del Enzina de León

Antiguo Instituto Juan del Enzina de León

Antiguo Instituto Juan del Enzina de León

En la primera foto, de los años 20, está el antiguo instituto Juan del Enzina, antes conocido como Instituto General y Técnico, que fue derribado a finales de los años 60 del siglo pasado en León para construir uno con arquitectura cuadrada de la época de Franco.

En la foto de abajo está la plaza de Santo Domingo en León en los años 50, pudiéndose ver el Instituto General y Técnico al fondo a la izquierda, al lado del edificio Pallarés, el de los toldos.

Pero ahora ya no está porque a algún listo se le ocurrió la maravillosa idea de derribarlo. Menos mal que el resto de la plaza está casi igual que antes.

Productividad y programación extrema

Hace unos días el jefe se empeñó en que una aplicación a la que no le pudimos dedicar el tiempo necesario, sobre todo el tiempo dedicado a calcular el tiempo, teníamos que terminarla para hoy. Cuento un poco como iba:

  • La aplicación lleva parada 1 año (si, 12 meses, de verdad).
  • Estabamos dos para hacerla, dos programadores con experiencia en diseño y desarrollo de aplicaciones.
  • Existía una aplicación previa cuya funcionalidad era entre mala y muy mala con lo que decidimos rehacerla de nuevo desde cero, decisión que siempre respaldaré.
  • La documentación existente, tanto de requisitos como de la aplicación previa era… bueno, ya os lo podéis suponer, ninguna.
  • La aplicación es vía web desarrollada en PHP 5 y MySQL 5. Si, llega y sobra esta arquitectura, sólo que hay que hacerlo bien.
  • Es una aplicación que tiene que mantener pedidos de productos, manteniendo de clientes, proveedores y productos.
  • Tiene algo especial que es que en cada pedido, el proveedor correspondiente tiene que validar si sus productos están disponibles.
  • Al ser vía web, la presentación debe ser más o menos bonita con lo que conlleva el maquetado. Además, para mí una aplicación web no está bien hecha si no genera HTML válido. Y lo genera, por cierto.
  • Lógicamente tiene que tener seguridad y cada usuario sólo puede ver ciertas cosas y realizar ciertas acciones.
  • Resumiendo, una aplicación que no es difícil pero tampoco es trivial, lleva su tiempo.

El caso es que después del año parada, ahora hay prisa por terminarla, de hecho hemos tenido un mes para recoger requisitos (que al final se usaron los anteriores, es decir, a ojo), para planificarla, hacer la documentación y desarrollarla con sus correspondientes pruebas.

De entrada eso es imposible; pero no contento con eso, el jefe, que siempre está haciendo algo, pues me asignó otro tipo de tareas menores de manteniento típicas, pero que llevan su tiempo, con lo que calculo que mi productividad total para esta aplicación ha sido del 50%.

Pero aún no contento con eso tampoco, el señor jefe se empeño en que teníamos que terminarla hoy. Toda no, pero sí la funcionalidad básica, es decir, el mantenimiento de todos los datos, la maquetación y presentación dejando de lado la seguridad por el momento. Y como había que entregarla hoy, el jefe nos dijo que teníamos que echar horas. Horas extras. Horas extras para hacer programación extrema. El cáncer de la programación.

Pero es que yo por ahí no paso. Primero porque no son horas que hay que hacer por culpa de que se jode la productividad de la empresa. La aplicación lleva un año parada. Dudo mucho que corra esta prisa.

Y segundo, y más importante, porque la productividad del trabajador no depende de las horas que eches. De hecho cuantas más horas eches, menor productividad. Porque estás más cansado, porque no tienes tiempo libre y tu humor no es el mismo. Porque si estás cansado cometes errores. Porque si cometes errores tienes que hacer horas para solucionarlos. Y así tenemos a la pescadilla que se muerde la cola y volvemos a la misma mierda. Luego la productivad del lunes trabajando 12 horas es de 12 horas. La del martes es de 9. La del miércoles es de 6. La del jueves de 4 y el viernes a tomar por el mismísimo porque estás hasta los huevos. Te vas a dormir y sigues programando en sueños.

¿Pero tan difícil es hacer entender a los jefes que esto de la informática no es como picar piedra? Que aquí hay mucho que pensar, mucho que diseñar y poco que programar. Que no hay que estar horas y horas aporreando el teclado. Que aquí hay que hacer las cosas bien desde el principio y con eso se ahorran muchas horas extras (muy generalmente impagadas) y sobre todo muchos dolores de cabeza. Quizás me gane mala fama por decir las cosas como son (como en la anterior empresa) pero es que no hay otra forma. Y se lo dije, y pasó por el aro en principio.

La aplicación finalmente se entregó a tiempo pero no gracias a las horas extras (de hecho creo que sólo hicimos un par de ellas) sino a la buena planificación perdiendo el tiempo (es un decir) en hacer la documentación pertinente. Cuando entregamos esta primera fase fue rápido e indoloro. Vale, ok, todo lo que está funciona. Sin problemas, seguimos con lo nuestro. Pero luego por detrás nos enteramos de que dice que sólo está el 5% ¡el 5%! Bueno sí, justo. Y encima se lo dice a los demás en lugar de a nosotros. Puf, es que me pongo negro.

Menos mal que sabemos cómo hacemos el trabajo y como va de verdad, si fuese un tío sin experiencia seguro que se volvía loco. A ver si ahora la terminamos y queda contento, porque aunque la aplicación es perfectamente funcional, de alabos nada. Es lo que hay.

Reykjavik en flor

Portada del libro Reykjavik en Flor de Sexto S dT

«Reykjavik en Flor» es un libro que me regaló mi compañero de trabajo escrito por Sexto ‘S. d’T., pseudónimo, lógicamente.

Esta novela, la primera de este autor leonés, trata de las andanzas de un joven desesperado por los aconteceres de su vida, incurriendo en continuas descripciones surrealistas a la par que narraciones de pequeñas historias muy centradas en un alcoholizado día a día.

Es una novela fácil de leer, amena y con descripciones surrealistas impresionantes. Vamos, a mí, que no me gusta leer literatura, me ha parecido muy entretenida, incluso al final tenía ganas de terminar para saber qué sucedía.

Aquí no voy a hacer una gran reseña, primero porque no sé hacerla (tipo comentario de texto, no lo hago desde el instituto y ya llovió…), y segundo porque no os quiero desvelar ni un ápice de la historia.

Pero sí me gustaría poner el párrafo que más me ha gustado, aunque existen bastantes que merece la pena releer para poder absorber toda esa mezcla de vocabulario, pero éste se mete con eso con lo que yo tanto me meto :) :

— [...] Marcos, todo un devoto del Buen Jesus Cristo, me hizo en una ocasión una pregunta [...] que no era otra que cómo se podía llegar a amar a la Virgen María, ya no exclusivamente en espíritu, sino en cuerpo también, una pregunta con verdadero calado místico ¿verdad?
— ¿Y qué le contestó usted padre?
— Le dije, amigo Berlín, que la única forma de amar a la Virgen María es amando sin medida a cada mujer de la tierra. [...]

Si queréis adquirila, en León está en la Web de la librería Pastor aunque también está en la librería Iguazú.

Y si alguno que me conozca lo quiere leer yo se lo presto :) .