Showing posts with label Software. Show all posts
Showing posts with label Software. Show all posts

24 September 2013

Adiós InOutTV


Hace unos años escribía esto sobre un grabador de TDT inteligente y el problema de ofrecer firmware inmaduro en productos caros:


InOutTV ha hecho una apuesta arriesgada: ofrecer un producto con un firmware totalmente inmaduro e ir puliéndolo a base de las quejas constantes de sus usuarios.
(...)
si bien estamos malacostumbrados a trabajar con software que funciona mal en nuestros ordenadores, la gente no perdona que el aparato con el que ve la televisión y graba sus series favoritas falle, se bloquee o se muera cuando le viene en gana.

A día de hoy, esto es lo que pone en su web:

"la compañía se encuentra en concurso de acreedores desde el pasado 18 de junio de 2012 (...) se informa a los usuarios que los equipos receptores comercializados por InOutTV y/o sus partners comerciales dejarán de recibir la guía de programación de SincroGuíaTV a partir del 1 de noviembre"
Es bastante probable que la calidad de su firmware haya tenido algo que ver con esta mala noticia. Una prueba más de que la implementación es tan importante o más que las sobrevaloradas ideas. La idea del producto era muy buena y está funcionando en otros países.

Saludos.

20 September 2010

Integer to Hexadecimal in Javascript. Industry versus Academia.


How would an average programmer working in industry convert an integer to hexadecimal in Javascript?

He would assume that he is not the first one in having the problem. He'd bet Javascript itself has a specific function or some standard library out there solves the problem.

Just googling around he would find a quick, clean and nice answer such as this one:

yourNum = yourNum.toString(16);



And, what about the average academician?

He would probably spend a whole day building and testing an impossible-to-understand, prone-to-error implementation.

Here is some Javascript I found at the website of some top-researchers in knowledge representation from a well-known university.

// *** Hexidecimal/Decimal Functions (needed to determine QuickTime version number from VBScript) ***
   
   function tohex(i) {
      a2 = ''
      ihex = hexQuot(i);
      idiff = eval(i + '-(' + ihex + '*16)')
      a2 = itohex(idiff) + a2;
      while( ihex > 16) {
         itmp = hexQuot(ihex);
         idiff = eval(ihex + '-(' + itmp + '*16)');
         a2 = itohex(idiff) + a2;
         ihex = itmp;
      } 
      a1 = itohex(ihex);
      return a1 + a2 ;
   }
   
   function hexQuot(i) {
      return Math.floor(eval(i +'/16'));
   }
   
   function itohex(i) {
      if( i == 0) {
         aa = '0' }
      else { if( i== 1) {
                aa = '1'}
         else {if( i== 2) {
                  aa = '2'}
            else {if( i == 3) {
                     aa = '3' }
               else {if( i== 4) {
                        aa = '4'}
                  else {if( i == 5) {
                           aa = '5' }
                     else {if( i== 6) {
                              aa = '6'}
                        else {if( i == 7) {
                                 aa = '7' }
                           else {if( i== 8) {
                                    aa = '8'}
                              else {if( i == 9) {
                                        aa = '9'}
                                 else {if( i==10) {
                                          aa = 'A'}
                                    else {if( i==11) {
                                             aa = 'B'}
                                       else {if( i==12) {
                                                aa = 'C'}
                                          else {if( i==13) {
                                                   aa = 'D'}
                                             else {if( i==14) {
                                                      aa = 'E'}
                                                else {if( i==15) {
                                                         aa = 'F'}

                                                }
                                             }
                                          }
                                       }
                                    }
                                 }
                              }
                           }
                        }
                     }
                  }
               }
            }
         }
      }
      return aa
   }


Weird.

27 August 2010

Cuestión de fidelidad


¿Por qué el concepto de fidelidad y mejora laboral está visto de manera diferente dependiendo del rango al que se aplique?

Siempre recuerdo cómo a algunos empleados se les denomina "trepas". Efectivamente, hay algunos a los que se les ve de lejos, pero también hay grandes malinterpretaciones. En el campo de la informática, por ejemplo, a un programador que desea pasarse a la gestión de proyectos se le suele ver como un trepa. Pero, ¿acaso una persona no puede preferir o ser más adecuado para dirigir proyectos software que para programarlos? Lo mismo para los que desean ser comerciales o relaciones públicas.

Quizá sea porque estos puestos suelen estar mejor remunerados o porque dan la sensación de tener cierto prestigio o poder sobre las personas. Pero, ¿y si diéramos a elegir entre dos tareas igualmente importantes sin variar el salario? Ésa sería una forma de filtrar a los verdaderos trepas de quienes simplemente desean o se sienten mejor preparados encargarse de otra tarea.

Viene esto al tema de la fidelidad empresarial. Mucha gente se cambia de profesión simplemente porque no está en el puesto que desea (también por la remuneración, eso está claro). En ciertos sectores y momentos, estos cambios no están bien vistos y se les suele marcar como trabajadores "poco fieles", en casos extremos "traidores".

Pero, ¿qué pasa con los empresarios o los altos cargos? Echando la memoria atrás he visto gente que ha creado o dirigido empresas para posteriormente dividirlas en varias y dejar a la original en manos de otros, estar permanentemente de viaje sin velar por la empresa o los empleados, o desaparecer de la gerencia de una empresa familiar. También cambiar de empresa o montar una nueva simplemente por el salario, por afán de aventura, por haber agotado la subvención de turno o por necesidad de demostrar algo a los colegas.

Este rasgo, sin embargo, suele ser considerado "positivo" en esos puestos y personas. Indica capacidad de progreso, de emprender nuevas aventuras, de mejora profesional, de riesgo. A estas personas raramente se las considera "traidoras" aunque hayan dejado sin su liderazgo y experiencia o hayan incumplido las promesas por las que contrataron a toda una plantilla.

Hasta hace poco, en el modelo tradicional de empresa, la fidelidad del empresario y altos cargos estaba tan garantizada o más que la de los trabajadores.

Hoy el mercado ha cambiado en muchos sectores. Las empresas se crean y se destruyen. Igual que es previsible que un trabajador cambie de empresa, ocurre lo mismo con empresarios y altos cargos, aunque en este segundo caso el impacto sea mucho mayor.

Son las reglas del juego. Pero no es justo denominar "trepa", "vendido" o "traidor" al trabajador que se mueve y "persona de éxito" o "emprendedor" al empresario o inversor que busca nuevos retos.

31 December 2009

Los pequeños detalles (y más sobre El Quijote en audiolibro)


En la anterior entrada se utilizaba una página web con el Quijote en audiolibro como ejemplo para descargar una serie de ficheros de manera elegante con ruby y wget. Es decir, para solucionar la chapuza de tener que bajarse 126 ficheros sueltos en vez de uno solo.

Otro pequeño fragmento en ruby para renombrar los ficheros a algo más coherente, sin espacios ni acentos molestos (el acento en UTF-8 da problemas en mi reproductor de audio). Otra excusa más para practicar con ficheros y expresiones regulares:

Dir.foreach(".") do |f|
unless (m = f.match(/Parte\s(.*)\sCap.+tulo-(.*)\.mp3/)).nil?
File.rename(f.to_s, "P" + m[1] + "-Capitulo-" + m[2] + ".mp3")
end
end

Lo triste del asunto viene ahora al organizar el audiolibro en un gestor de ficheros mp3. Noto algo raro y decido echar un vistazo a los tags ID3. Atención a cómo se han rellenado los campos:

Nombre de la pista: Don Quijote de la Mancha
Álbum: Cap‚tulo 01
Artista: Estudios Roma
Año: 2005
Comentarios: www.estudiosroma.com
Género: Voz

Se han intercambiado los campos de la pista y del álbum de manera que todas las pistas tienen el mismo nombre y pertenecen a 126 álbumes diferentes (con su acento mal puesto incluido). Nótese que, sin embargo, la propaganda aparece bien repartida. Ahora resulta que el artista no fue Miguel de Cervantes, sino Estudios Roma. Qué cosas.

Éste es el típico ejemplo de cómo cagarla al final un proyecto por falta de interés. Se ha hecho la lectura del libro y la grabación de manera correcta. Un esfuerzo enorme. Y, después, en la parte más fácil (la distribución), se han colgado 126 ficheros en una página web, TODOS erróneamente etiquetados y que el usuario se apañe.

El usuario ya hará sus 126 clicks para descargarse los ficheros, renombrará los ficheros para quitar el acento maldito  y arreglará las etiquetas de las susodichas 126 pistas para que sus programas de gestión de música no se hagan la picha un lío.

¿Tanto costaba hacer ese minúsculo esfuerzo final para dejar el tema bien cerrado? Una prueba más de que jamás se piensa en el usuario. Ni el técnico chapucero que quiere irse a casa, ni la empresa privada que recibe el dinero fresco de la subvención, ni el político que se cuelga las medallas por este proyecto cultural.

¿Es esto ver las cosas de una manera negativa? No. Es ver la realidad. No sirve de nada encomiar el enorme esfuerzo realizado y el dinero invertido en "difusión cultural" cuando la propia forma de difundirlo es la barrera más importante para disfrutar de esa cultura.

28 December 2009

La elegancia como paradigma de la programación


Tras algún tiempo en esto creo que todos, empezando por uno mismo y siguiendo por universidades y empresas, debemos hacer un esfuerzo en evolucionar tal y como lo hacen los lenguajes de programación. En no quedarnos anclados con las tecnologías y lenguajes por mucho que las dominemos.

Sólo se aprende mediante ejemplos sencillos pero reales. Esto es muy importante. Sólo ante un problema real uno aguza el ingenio y el aprendizaje. El por qué hay problemas donde no debería es otro asunto.


Ejemplo: El Quijote en audiolibro

Queremos escuchar el Quijote en audiolibro. Buscamos en Google y nos encontramos con la agradable sorpresa de que el Gobierno de Aragón ha hecho un gran esfuerzo en grabarlo y dejarlo disponible. Sin embargo, el panorama es el siguiente: A una persona muy astuta le ha dado por colgarlo en una página web por capítulos separados. Son nada menos que 52 para la primera parte y 74 para la segunda. La mayor parte de la gente querrá escucharlo en su mp3 y no hay forma (aparente, a primera vista) de bajárselos con un sólo clic. Sólo necesitamos la friolera de ¡126 clics!

Un grandísmo esfuerzo (lectura, grabación, difusión...) que nos deja con mal sabor de boca por no tener un poco de cuidado al final, en la fase más sencilla. Algo muy típico en los proyectos. ¿Cómo no se les ocurriría poner un sólo fichero .zip o similar (o unos pocos) para descargarlo?


Soluciones

Para el usuario medio, esto supone un verdadero infierno. Tendría que tragarse los 126 clicks o buscar algún gestor de descargas medianamente inteligente. Para colmo, el directorio web está sin permisos de listar, de manera que no se puede hacer un "descárgame todos los ficheros (o todos los mp3) del directorio".

La solución para el iniciado es obvia: hacerse un programa para bajar los ficheros modificando la pequeña parte del nombre que cambia tras una URL común: (URL#Capítulo-01.mp3, URL#Capítulo-02.mp3, etc...).

Nótese el peñazo que supone realizar una tarea tan simple con los lenguajes más difundidos como Java o C#. Bucle, incremento de las cadenas, función para descargar un fichero, etc... Es un ejercicio interesante comprobar lo complicado y largo que puede resultar una tarea tan trivial con estos lenguajes. Tanto que hasta desanima.

Sin embargo compruébese una posible manera de descargarse la primera parte en un sistema con ruby y wget (nótese que la URL es fea de narices gracias a que el mismo experto anterior ha utilizado espacios y acentos en el nombre de los ficheros):

("01".."52").each {|i| `wget http://www.aularagon.org/files/espa/elquijote/p1/Parte%201%20Cap%C3%ADtulo-#{i}.mp3`}

La verdad es que la elegancia, expresividad e integración con el sistema de este lenguaje es bestial. Hace falta haber hecho el ejercicio de escribir un programa equivalente en otros lenguajes para darse cuenta del avance que un lenguaje como éste supone a la hora de pensar.

Sólo mediante su uso en problemas reales o ejercicios estimulantes es como se descubre todo su potencial. Una vez descubierto, es difícil argumentar el uso de cualquier otro lenguaje (por muy difundido que esté) para realizar la misma tarea.

No creo que haya excusa para permanecer ajenos a estos lenguajes y emplearlos para crear soluciones de todo tipo, empresariales incluidas. Y menos sabiendo que existen cosas como jRuby.

19 September 2008

Cuando los usuarios prueban el firmware. El fiasco de InOutTV y el Siemens M665T


Actualización (febrero 2009): InOutTV hace caso a las quejas de sus usuarios e inicia el programa de betatesters. ¿Demasiado tarde?.


Las pruebas de Software

Todo el que conoce un poco cómo funciona el desarrollo de software sabe que las pruebas de software son uno de los pilares básicos y, desgraciadamente, más descuidados de todo el desarrollo.

Estas pruebas comienzan desde la propia concepción del software, se desarrollan durante la programación y son efectuadas finalmente por gente independiente, que se encarga de probar el producto a fondo tal y como lo haría un usuario, o incluso peor. A éste se le llama departamento de QA en los ambientes más cool, si bien no deja de ser el departamento de calidad o de pruebas de toda la vida.

El grado de implantación y calidad de todo este proceso es variable en las empresas. A los programadores el tema de las pruebas unitarias les puede sonar a chino o pueden ser expertos. El departamento de calidad puede ser "Manolo" o puede, simplemente no existir. A los directivos les puede parecer estupendo que todo esté probado o les puede dar igual si con eso se adelanta el lanzamiento. Todo esto se ve reflejado finalmente en la calidad del software.


Cuando los usuarios prueban el producto

El tema de las pruebas de software es complejo, muy complejo, más cuanto más variopinto es el entorno sobre el que se desarrolla la aplicación. No es lo mismo desarrollar sobre un producto cuyo hardware y software de base controlas al cien por cien, que desarrollar algo que sea capaz de funcionar en cualquier PC con Windows, por poner un ejemplo.

En éstas y otras ocasiones una buena manera de realizar las pruebas finales es ofrecer a los usuarios que prueben el producto antes de lanzarlo masivamente. A ésto se le suele llamar beta testing o, en determinadas ocasiones, retos (cuando se trata de productos de seguridad, etc...). Durante varios meses los usuarios prueban el producto o se enfrentan al reto propuesto de manera gratuita. De hecho generalmente se ofrecen una serie de suculentos beneficios para ellos (el regalo del producto, descuentos o incluso una gran recompensa), normalmente en proporción a su labor. Al fin y al cabo los usuarios están trabajando para la empresa que lo ha puesto a su disposición, ahorrándoles a ellos probar el producto del que luego se beneficiarán.


Software vs Firmware


Como se ha comentado, el proceso de probar el producto depende enormemente del control que se tenga sobre la plataforma destino. Hoy día prácticamente todo aparato electrónico dispone de un microprocesador y algo de software para controlarlo. A este pequeño software que reside dentro del dispositivo y que no tiene sentido fuera de él se le llama firmware. Lo llevan las cámaras fotográficas, los reproductores de mp3, nuestro coche y hasta determinados microondas.

La principal diferencia a nivel de usuario entre software y firmware es que, mientras el primero estamos acostumbrados a que pueda fallar sin demasiado perjuicio, el segundo jamás debería hacerlo. Imaginemos desde el caso más extremo (que el ABS de nuestro coche falle) hasta el aparentemente más inocuo (se nos borran todas las fotos de nuestra cámara). Un auténtico fiasco, en cualquier caso.

No estamos acostumbrados, ni debemos acostumbrarnos, a que esto ocurra en software (firmware) de aparatos de consumo. El resultado sería lavadoras que estropean la ropa, coches con control de tracción que se salen en las curvas, microondas que fríen nuestros productos o cámaras de fotos que no borran fotos comprometidas a pesar de que le dimos al botón de "borrar". Comportamientos totalmente inesperados que nos pillan a traición.

Estas cosas ocurren, por supuesto, pero en muy pocas ocasiones y, cuando lo hacen, suelen ser titulares de webs del sector y suelen corregirse rápidamente. En caso contrario la empresa se arriesga a una pésima fama o incluso a su ruina.

Es por ello que la calidad del firmware suele ser muchísimo más alta que la del software general. En primer lugar porque el entorno está totalmente controlado: la empresa dispone y vende unidades exactamente iguales. En segundo: porque el producto está hecho para gente de la calle, que no tiene por qué estar familiarizada con el software o los ordenadores.

Hasta nuestros abuelos son capaces de utilizar un vídeo o un teléfono móvil sencillo. El firmware no puede fallar.


InOutTV y el Siemens M665T

Hace más de un año la empresa InOutTV presentó un novedoso producto (novedoso en nuestro país, ya habitual en otros). El Siemens M665T, un sintonizador de TDT con disco duro integrado y una guía de televisión propia que permitía, entre otras cosas, grabar series semanales o diarias pulsando sólo un botón y un largo etcétera de beneficios que podéis ver en su publicidad. Un invento que ya ofrecen como servicio remoto compañías de televisión si investigamos un poco, por cierto. La guía de programación es de pago, ofreciéndose de manera gratuita por un periodo inicial de tiempo. Al preguntar a la empresa por el futuro, no se sabe cuándo dejará de ser gratuita ni cuánto costará el servicio.

La cuestión es que prometía ser un aparato tremendamente sencillo. Incluso alguien que no supiera programar un vídeo por su complejidad sería capaz de grabar todos los capítulos de una serie seleccionándola en la guía visual y marcándola como "grabar siempre".

El aparato tiene un formato similar a un reproductor de DVD y, como digo, promete una tremenda facilidad de uso, su verdadero fuerte. Interiormente intuyo que utiliza alguna minidistribución de linux o similar para realizar todas sus funciones. Cosa que, como usuario, no debería importarme en absoluto.


Un hardware regular, un firmware muy verde


Basta con buscar información sobre el aparato en Internet o ser o hablar con uno de los propietarios del producto para comprobar los problemas que adolece.

Empezando por el hardware, se observa una calidad muy mejorable de todos los componentes. Una fuente de alimentación que genera un fuerte pitido, un disco duro que hace demasiado ruido, una elevadísima temperatura de funcionamiento y un mando a distancia con el que hay que apuntar al milímetro para que el aparato reaccione ya ponen los pelos de punta en los primeros instantes de uso.

Bastante gente ha informado de bloqueos y muerte súbita de su aparato, más acusada recientemente tras una nueva versión del firmware que hace imposible poner el aparato en modo standby (con el disco duro apagado) y que genera tanto ruido y calor que hay gente que ha tenido que retirarlo de su dormitorio. Incluso muchos de los que lo tienen en el salón no conciben un disco duro funcionando 24/7 con su ruido, su calor y su derroche de energía y optan por desconectarlo a mano por la noche.

Pero, sin duda alguna, el auténtico fiasco de este equipo es su firmware (que se actualiza automáticamente vía TDT). Algún día llegará a ser un sofware maduro, pero actualmente no lo es. Lleva más de un año a la venta, con nada menos que diez versiones en 18 meses. Basta acudir a su información de las revisiones para comprobar cómo, versión a versión, se han dedicado a corregir fallos de lo más básico.

Cosas tan aparentes y fáciles de probar como que el display LCD donde se muestra la hora desaparecía, reaparecían grabaciones una vez borradas, grabaciones que no se realizaban y un larguísimo etcétera han tenido que corregirse versión tras version.

Repito: 10 versiones en 18 meses corrigiendo las funcionalidades más básicas en un aparato con hardware y software cerrado dan una idea de las pruebas a las que ha sido sometido.


Una comunidad decepcionada


La parte buena del asunto es que las correcciones se han ido efectuando, lo cual indica una voluntad por parte de la empresa de que las cosas mejoren, aunque todavía dista bastante de ser un aparato sin fallos. La parte mala es que apenas nadie desde que compró el aparato ha podido disfrutar de las características por las que pagó: aparte de los errores aparentemente menos importantes, mucha gente ha sufrido la ingrata experiencia de perderse el último capítulo de una serie programada para grabar siempre porque ese día o esa semana le dio al aparato por no grabarla, grabar sólo un trozo o grabarla sin audio.

Y la cosa no queda ahí. Los fallos afectan incluso sólo viendo la televisión: reinicios del aparato, bloqueos y un largo etcétera que hacen desistir de su utilización.

Pero lo más triste de todo esto es que estos fallos no han sido detectados por la empresa y sus pruebas. La mayor parte de los errores han sido detectados y comunicados al servicio de atención al cliente por los propios usuarios bien directamente o bien a través de las quejas vertidas en un foro. Sin programa de beta testing, sin descuentos, sin regalos, sin ningún beneficio extra ni aviso previo.

En ese mismo foro los usuarios comparten sus pesares y comprueban, una y otra vez, cómo no son tontos ni inútiles, cómo no tienen mala señal de TDT, cómo no se ha vuelto loco únicamente su aparato, sino cómo cada nueva versión de firmware hace enfurecer al personal por haber introducido nuevos errores o haber cambiado el comportamiento del aparato. Por haber introducido nuevas funcionalidades (butaca TV, por ejemplo) sin haberlas probado primero.

La empresa considera esta práctica "normal" y no reembolsa el importe del aparato a los usuarios insatisfechos con un producto que falla más que una escopeta de feria. Considera que los fallos del firmware no son responsabilidad suya. Son cosas que "ocurren" y ellos corrigen con buena voluntad pero de las que parecen no ser responsables.

Cualquier queja la achacan a la unidad, que cambian si está en garantía. Cosa que de nada sirve, obviamente, puesto que los errores son manifiestamente del firmware, como puede comprobarse a los pocos días en cuanto reaparecen en la nueva unidad. La empresa sí ofrece, sin embargo, un irrisorio periodo de prueba de 7 días con el que no da tiempo ni a comprobar la correcta grabación de una serie semanal.

Toda esta información, la desesperación de la gente y todos los fallos de este aparato pueden leerse en detalle acudiendo a las siguientes direcciones:
InOutTV ha hecho una apuesta arriesgada: ofrecer un producto con un firmware totalmente inmaduro e ir puliéndolo a base de las quejas constantes de sus usuarios.

Algo que, como comentan algunos usuarios, es habitual en software libre ofrecido sin cargo alguno (ofrecer un producto por buena voluntad e ir puliéndolo a base de las pruebas y sugerencias de una comunidad), no tiene sentido que lo sea aquí. En este caso se trata de un firmware propietario, de pago y embebido en un aparato doméstico de fácil utilización y uso diario. Un refrito que no podía dar otro resultado: un aparato que funciona cuando quiere y una muchedumbre desesperada que, si ha podido disfrutar de su producto, ha sido sólo a temporadas y con resultado irregular. Con un elevado número de gente que se ha sentido estafada y ha terminado vendiendo, regalando o usando el aparato sólo para ver la televisión.

No siempre la culpa es del usuario. A veces, muchas, es culpa de un software mal hecho. La cuestión es que, si bien estamos malacostumbrados a trabajar con software que funciona mal en nuestros ordenadores, la gente no perdona que el aparato con el que ve la televisión y graba sus series favoritas falle, se bloquee o se muera cuando le viene en gana.

Más todavía, la gente no quiere, y no debe, saber qué son las versiones de firmware, cómo se resetea un aparato a la configuración de fábrica o cómo se formatea el disco duro. Hasta ahí podíamos llegar: extender los eternos y farragosos problemas de la informática generalista a nuestros aparatos domésticos. Los usuarios nunca van a tragar con eso.

Sin embargo puede decirse que InOutTV ha sacado el primer firmware emocional: cualquiera que compre este aparato va a sentir inmediatamente un cabreo tremendo, unido a una sensación de imbécil integral, que sólo podrá paliar compartiendo sus angustias con el resto de usuarios en los mencionados foros.

Ahora ya sabes por qué no habías oido hablar de este producto que lleva en el mercado más de un año y que, en su concepción, es tremendamente interesante y un buen candidato a ser número uno en ventas.

Parece que la propia empresa ni siquiera se atreve a publicitarlo como es debido. ¿Por qué será?.

15 July 2008

AJAX y PHP - Construyendo Aplicaciones Web Interactivas


Packt Publishing es una joven editorial inglesa volcada por completo en ampliar la documentación en cantidad y, sobre todo, en calidad de un amplio abanico de soluciones de software libre. Bajo su lema Community Experience Distilled, Packt Publishing nos ofrece en sus libros precisamente eso: títulos escritos por gente activa en diversas comunidades de software que condensan lo más interesante y práctico de cada materia.

En estos momentos acaba de publicar la versión en español de uno de sus libros más vendidos en el mercado anglosajón bajo el título "AJAX y PHP - Construyendo Aplicaciones Web Interactivas".

AJAX han sido las siglas más de moda en estos últimos años en el mundo del desarrollo web pero... ¿sabemos realmente qué significa?. ¿Cómo surgió?. ¿Realmente hacía falta?. ¿Ha supuesto realmente una revolución o ha sido otra moda más?. Con estas provocadoras preguntas comienza el primer capítulo de un libro que promete ser ameno desde sus inicios.

El segundo capítulo también nos lleva a la reflexión y al conocimiento de técnicas de amplio uso en la web que contribuyen a tapar esos agujeros sueltos que nos suelen quedar en las pequeñas tareas de siempre: JavaScript avanzado en los navegadores, DOM, CSS, XML y el objeto XMLHttpRequest. Y, muy importante, las diferencias y sutilezas de estas tecnologías al enfrentarse a los diversos navegadores de actualidad (Firefox, Opera, Internet Explorer...).

El tercer capítulo se centra en la parte técnica ya de manera más práctica construyendo un pequeño framework para la realización de peticiones asíncronas y aplicación práctica de PHP y DOM, bases de datos (MySQL) y recomendaciones generales de cara al código.

A pesar de lo que parece con estos primeros capítulos, no deja de ser un libro práctico para todos los públicos. Con la información técnica básica separada en los apéndices acerca de la preparación del entorno (instalación de PHP, Apache, MySQL...) bajo Windows y las diversas variantes de Unix que será de gran utilidad para el neófito, es un libro que se disfruta a todos los niveles.

El resto de los capítulos se dedica, uno a uno, a transmitir los conceptos fundamentales para dominar este conjunto de tecnologías de una manera amena que realmente engancha. En cada capítulo se construye una aplicación web diferente de la mano de los autores y acompañada de una explicación detallada:

  • Validación de formularios
  • Chat basado en AJAX (con XML y con JSON)
  • Sugerir y autocompletar
  • Gráficas en tiempo real con AJAX y SVG
  • Presentación de datos en grid con AJAX
  • Lector RSS
  • Arrastrar y soltar con la biblioteca script.aculo.us
Todo el código está escrito en inglés, igual que el original, salvo los textos de la intefaz y los comentarios, que están en castellano. Sin duda una excelente elección por parte de la editorial.

El libro sale como primera recomendación en Amazon para el tema "ajax php", con una puntuación de 4,5 estrellas sobre 5 de casi una treintena de compradores, por encima de otros títulos y colecciones más conocidas sobre el tema.

Hay información en detalle sobre el libro (en inglés) en:
Se puede comprar en Amazon y otros almacenes de libros o directamente a la editorial, en formato papel o ebook.

Packt Publishing cuida mucho de los detalles y he tenido el placer de ser el traductor de este libro, poniendo todo mi empeño en que esta edición, completamente revisada y adaptada al castellano, merezca la pena incluso para aquellos que saben inglés a la perfección. Espero que lo disfrutéis y no dudéis en poneros en contacto conmigo o directamente con la editorial para cualquier asunto relacionado con el libro.

09 June 2008

¿Te llaman y cuelgan?. Puede NO ser una equivocación.


Hace un tiempo que bastante gente se queja de que recibe llamadas con características peculiares:

  • Son de teléfonos "extraños". Parecen del extranjero, de centralita, de otra comunidad autónoma y un número que no reconoces...
  • Poseen algún patrón temporal: todos los días a una hora similar, te llaman varias veces seguidas, varios días a la misma hora, varias semanas...
  • Te llaman, se oye un extraño silencio y en cuanto contestas, cuelgan. Es más, cuando te ha pasado varias veces seguidas te callas, esperas varios segundos a ver si escuchas algo pero no cuelgan. Sólo lo hacen si contestas (o si esperas demasiado tiempo sin contestar).
¿Quién será?. ¿Una equivocación?. ¿Algún maníaco?. ¿Alguna peligrosa banda que quiere saber a qué horas estamos en casa?.

En absoluto. Con gran probabilidad estás siendo víctima de las tecnologías empleadas por los call centers destinadas -cómo no podía ser de otra forma- a aumentar la productividad del negocio para encuestarte o venderte algo.

Asentadas y tradicionales en otros países, a la que ya están más que acostumbrados y donde ya existen organismos que intentan frenarlas o limitarlas, estas técnicas de los call centers son relativamente nuevas en el nuestro y están empezando a extenderse hasta resultar molestas. Qué pena que siempre importemos rápidamente los usos más lucrativos de la tecnología a costa de lo que sea. Pero centrémonos, ¿a qué se deben estas llamadas "extrañas" exactamente?.

Lejos quedan los tiempos en que un teleoperador se dedicaba a llamar a un listado de números de teléfono para encuestar o vender algo. Se sabe que sólo un 25-35% de las llamadas son respondidas por una persona (puede no haber nadie en casa, estar comunicando, ser un fax, etc...) y es una tarea desagradable y repetitiva, por lo que se presta muy bien a la automatización. ¿Por qué no lo hace un aparato o un programa?. Rapidamente apareció lo que se denomina un marcador predictivo, aunque no resulta tan predictivo como muchos esperarían.

El marcador predictivo es un aparato (más generalmente un software) que se dedica a llamar a un listado de números de manera más o menos inteligente. Su objetivo fundamental es proporcionar un flujo de llamadas constante a los teleoperadores para que no estén ociosos ni un segundo. Es decir, el aparato llama por ellos y luego les pasa las llamadas. Como es tan "inteligente", es capaz de discriminar el tipo de llamada por la respuesta: sabe si no hay nadie en casa, si está comunicando, si detrás de ese número hay un fax o un módem, si hay un contestador, o lo, más interesante, si ha respondido una persona, que son las únicas llamadas que pasa a los teleoperadores, maximizando así la productividad.

Ésta es la teoría y hasta aquí no parece haber excesivos problemas, puesto que al fin y al cabo no se diferencia en nada de una llamada tradicional desde el punto de vista del usuario. Si son capaces de discriminar llamadas, mejor para ellos. Si estás en casa te molestan una vez y ya está, pero ¿qué tiene que ver con que te estén llamando y colgando durante varios días?. ¿O por qué te cuelgan en cuanto abres la boca?. La explicación está en el propio funcionamiento del aparato.

Si decimos que sólo el 25-35% de las llamadas son respondidas por una persona y hay que proporcionar un flujo constante a los teleoperadores, es obvio que el aparato debe realizar muchísimas llamadas para obtener buenas candidatas. Se le denomina predictivo porque se basa en estadísticas (número de teléfonos esperados contestados por una persona, tiempo medio de conversación del operador, etc...) para ir realizando llamadas continuamente y en número "adecuado". Si se hacen pocas llamadas puede haber operadores ociosos y eso no gusta a las empresas. Pero, ¿qué ocurre si hacen demasiadas, es decir, si los "sofisticados algoritmos" de los marcadores predictivos (como algunos fabricantes anuncian) no son tan predictivos?.

Surge el problema que más molesta al usuario: las denominadas llamadas silenciosas. Estas llamadas son aquellas llamadas candidatas que en el momento de ser transferidas al teleoperador son canceladas porque en ese momento están todos ocupados.

En primer lugar uno se enfrenta al molesto silencio de la detección de voz humana (o de detección de contestador, según se mire), donde el programa espera a que respondas antes de dar la llamada como válida. Si has sufrido la desgracia de que te llamen varias veces seguidas y hecho la prueba de no contestar porque estabas harto comprobarás que la llamada permanece "a la escucha" hasta que dices algo. Lo normal sería que en este momento la llamada fuera transferida a un operador y tú no te dieras "demasiada cuenta" (aunque el retraso y a veces los tonos de llamada son claramente perceptibles). Pero con las llamadas silenciosas el aparato finaliza la conexión porque no hay teleoperadores disponibles, lo que el usuario percibe como que le cuelgan en las narices en cuanto abre la boca.

Tu número, además, permanecerá entre los candidatos a ser llamados en una nueva ronda por medio de este sofisticado mecanismo, donde es más que probable que todos los operadores vuelvan a estar ocupados y la historia vuelva a repetirse. A veces son varias llamadas seguidas o en días consecutivos. En este punto empiezas a volverte paranoico pensando en quién te podrá estar acosando.

Y así hasta el gran día. Ese día volverás a recibir una llamada extraña que te recuerda a las anteriores pero donde un teleoperador te responderá justo cuando vayas a colgar y todas tus dudas se disiparán: han sido ellos, pensarás rápidamente. Por supuesto es muy posible que utilicen un número diferente para llamarte en diferentes ocasiones y negarán en rotundo la utilización de estas técnicas, diciéndote que es la primera vez que hablan contigo (obviamente). Todo eso a pesar de que los fabricantes explican claramente cómo funcionan y de la posibilidad de las llamadas silenciosas, que incluso tilda de "muy frecuentes" cuando hay pocos teleoperadores o éstos hablan con el cliente más tiempo del esperado.

Yo particularmente (esto es pura especulación) tampoco descartaría que utilizaran esta técnica para saber en qué franja horaria hay gente en casa y volver a llamar unos días o semanas después del calentón, cuando a uno ya se le ha olvidado. Aunque pensándolo bien, esto quizá sí que sería demasiado sofisticado, ya que no parece que entre los parámetros que manejan los sofisticados algoritmos de los marcadores predictivos se encuentren algunos como "nivel de fastidio del usuario", "número de intentos fallidos anteriores" o "probabilidad de que el cliente mente a algún familiar tuyo cuando coja la llamada".

Si deseas información acerca de algún número concreto que te ha estado llamando, puedes utilizar WhoCallsMe.com. Verás que no eres el único al que llaman y cuelgan desde el 914523902 o el 911716371, entre otros muchos.

Cosas similares se han comentado también en barrapunto y menéame. Y seguro que investigando por ahí hay muchas más páginas al respecto.

Así que la próxima vez que os ocurra, estad tranquilos. Es mucho más probable que os esté llamando un algoritmo predictivo que un impredecible acosador.

11 February 2008

Qué significa ser un buen manager


Inexplicablemente en el mundo ibérico apenas encontramos información acerca de la gestión de equipos de desarrollo de software, y menos adaptados a nuestra idiosincrasia, sociedad y circunstancias. Ni se puede gestionar un equipo de software como si fuera una fábrica de producción industrial en serie como en modelos antiguos, ni tampoco es prudente calcar a ciegas modelos anglosajones que tan bien parecen funcionar en otros entornos sociales muy diferentes al nuestro.

En nuestro país ni siquiera encontramos traducciones de libros clásicos acerca de este tema que son éxitos de ventas en varios países. ¿A qué se debe este hecho?.

Es por ello que este artículo está escrito intencionadamente en castellano: ya existen abundantes weblogs y bibliografía sobre el tema en el mundo aglosajón (indico algunas referencias interesantes al final). Al referirme a manager, hablo más específicamente de un manager frente a un equipo de software, en unos casos puede coincidir con lo que en España conocemos como "jefe de proyectos" y en otros puede ser algo más general, que no sólo vela por el desarrollo del producto a corto plazo sino por el desarrollo del equipo y de la empresa en general.

Tengámoslo claro desde un principio: el papel fundamental de un buen manager es conseguir que los trabajos salgan adelante. Esto es indiscutible. No en vano uno de los mayores éxitos de ventas sobre gestión de proyectos, anteriormente titulado "The art of project management", va a pasar a titularse sencillamente "Making things happen" en su segunda edición. Sin embargo, para que las cosas "ocurran" se requiere otra serie de cualidades que van más allá de las puramente técnicas, como bien saben los promotores de las metodologías más modernas.

Desde el punto de vista humano, este puesto de responsabilidad conlleva muchas implicaciones. Existen detalles sutiles no siempre tenidos en cuenta, generalmente eclipsados por las cuestiones técnicas y el trabajo del día a día, que no pueden pasarse por alto.

Algunos de ellos, son asegurarse de que el equipo de software:

  1. Siente que el manager conoce y aprecia su trabajo. Si bien un manager no puede conocer tantos detalles técnicos como su equipo, sí debe tener un bagaje técnico suficiente para poder apreciar y valorar lo que se está haciendo, así como para demostrar y justificar sus decisiones y que el equipo las entienda. En caso contrario, el equipo tomará las decisiones tomadas como una manía o un capricho sin sentido, incluso pudiendo llegar a tomárselo (con razón o sin ella) como algo en su contra.
  2. Se sienta como una parte más de la organización. Debe conocer sus responsabilidades, éxitos y fracasos y sobre todo, sentir que el manager delega completamente las tareas encomendadas al equipo. Un manager que no sabe delegar hace sentir a su equipo de segunda; un equipo que jamás se esforzará al máximo puesto que sabe que las decisiones ya están tomadas de antemano aunque se respire un falso clima de cooperación y democracia. Este punto está estrechamente relacionado con el primero.
  3. Se sienta valorado y atendido tanto desde el punto de vista económico como humano. Los humanos tenemos la necesidad de sentirnos a gusto en el trabajo, de respirar un buen ambiente y de ser recompensados en la medida en que creemos que debemos serlo. El porcentaje depende de cada uno, pero un ambiente artificial o enrarecido y unas condiciones económicas mediocres son un desamparo seguro. La indiferencia y el trato calcado y deshumanizado hacia diferentes empleados, más habitual conforme mayor es la empresa, no contribuyen a mejorar este aspecto.
  4. Entienda qué tiene que hacer. Muy relacionado con lo anterior, ideas contradictorias por parte del manager o por parte de diferentes departamentos, desembocarán en estrés, retrasos y una calidad deficiente, seguramente por el temor que sienten muchos desarrolladores a preguntar y aclarar lo que se espera de ellos. Temor a que, en un entorno altamente competitivo y con constantes demostraciones de superioridad, se tenga la sensación de que preguntar, aunque sea para aclarar dudas o compartir soluciones, implica reconocer que no se está a la altura.
  5. Esté en un lugar tranquilo y con un cierto nivel de intimidad. Un equipo de desarrollo de software es un equipo de lo que en el mundo anglosajón se ha dado en denominar "trabajadores del conocimiento". Como para cualquier escritor, músico, deportista o simplemente un estudiante, la concentración es imprescindible y requiere su tiempo. Sin concentración no hay productividad. Un ambiente de trabajo con charlas entre compañeros, llamadas telefónicas, música de fondo o con constantes interrupciones son garantías seguras de una productividad nula o terriblemente deficiente.
  6. No se dedique a "tapar agujeros", pero tampoco esté encasillado. Está comprobado que la dispersión de tareas reduce la productividad; las personas no trabajamos bien alternando constantemente de tarea en tarea, consiguiendo no sentirnos parte de ninguna. Sin embargo, tampoco debemos encasillar a un equipo o a una persona con una sola tarea, lenguaje de programación o especialidad, porque puede haber agradables sorpresas detrás de un desarrollador.
  7. Entienda y justifique tu posición como manager. Si un equipo o alguno de sus miembros siente que está haciendo tareas que no le corresponden a él (esto es, trabajo como manager) además del suyo propio, sin ningún tipo de recompensa (no necesariamente económica), se sentirá infravalorado. Curiosamente también puede darse el caso contrario: que el manager se exceda en sus responsabilidades y colisione con tareas en las que debería haber delegado (labores de análisis, documentación, pruebas...) eclipsando así al equipo de desarrollo y quitándoles la escasa parcela de terreno libre que poseen para poder sentirse orgullosos y útiles.
  8. No sufra de agravios comparativos. La administración pública dispone de unos baremos y unas categorías laborales cuantificables. En la empresa privada ocurre generalmente lo contrario: nadie tiene ni la más remota idea de lo que cobra la gente a la que ve todos los días, salvo alguna rara excepción donde existe una carrera profesional definida. ¿Alguien puede explicar por qué?. El secretismo y la discriminación salarial (generalmente asociados) o el disfrute de otro tipo de beneficios siempre acaba saliendo a la luz y es la causa principal de crispación del ambiente laboral, especialmente si los beneficiados siempre son amigos, conocidos, familiares... En el ambiente se generan envidias y competitividad, haciendo que el desarrollador se preocupe más de saber cuánto cobra un compañero o por qué a otro se le condeden siempre determinados beneficios que de hacer bien su trabajo.
  9. Sea educado hacia la independencia y la responsabilidad. Un buen manager no debe crear obstáculos ni frenar a su equipo de desarrollo, ni tampoco tratarlo como a ese niño consentido al que jamás se exige responsabilidad ni se explica el alcance de sus actos y cómo puede corregirlos por sí mismo. Aunque parezca una buena estrategia a corto plazo porque proporciona una visión placentera y divertida, educar en la dependencia genera una gran inseguridad (o una falsa sensación de seguridad, según el tipo de personalidad) que puede llegar a impedir el desarrollo personal y profesional.
En definitiva, un buen manager debería ser recordado por el equipo de desarrollo como esos profesores a los que añoramos. Como alguien que comparte sus conocimientos (y algo más) sin esperar nada a cambio, que no eclipsa pero tampoco abandona en la estacada. Como alguien ecuánime que sabe escuchar.

Alguien que, como el buen maestro, realmente desea que los miembros de su equipo sean independientes y se desarrollen al máximo sin ponerles obstáculos. Para que, si sus capacidades se lo permiten, llegue ese gran día en que el alumno supere al maestro.


Blogs recomendados:
Artículos recomendados:
Bibliografía recomendada:

30 November 2007

On programming


Who doesn't talk to his colleagues about programming?.

Sometimes it's more interesting to talk about the human aspects of programming than about the technological issues that techies are talking about all the time (a thread here, an interface there, let's add some reflection...).

There are ideas that my most respectable colleagues agree on but that unfortunately seem to be forgotten (or unkown) by a vast number of people working in the field.

They can be summarized in the following sentences:

If you're a software engineer, your basic building material is human intellect and your primary tool is you.
A leader has the expertise of a competent programmer and recognizes that programming is only 15 percent communicating with the computer and 85 percent communicating with people.
Programming is communicating with another programmer first and communicating with the computer second.
Some creative programmers view the discipline of standards and conventions as stifling to their creativity. The opposite is true. [...]. Without standards and conventions on large projects, project completion itself is impossible. Creativity isn't even imaginable.
A programming masterpiece requires just as much discipline. If you don't try to analyze requirements and design before you begin coding, much of your learning about the project will occur during coding and the result of your labors will look more like a three-year-old's finger painting than a work of art.
By all means, get excited about programming. But excitement is no substitute for competency. Remember which is more important.

Opps... wait! I forgot to say something before you just discard this post: these sentences are not ours. They're Steve McConell's.

19 October 2007

Software Practices - Sandwich Design


Today, I was reading a colleague's blog. In his last post (in Spanish) he defends the programmer as a software professional and provides a great outlook of its generally misconceived role, duties and difficulties. That immediately reminded me about the opposite figure: the architecture astronaut as described in Joel Spolsky's article. At some companies both roles officially exist (software astronauts not being desing as such but in other pompus terms). Sometimes they even group them into separate buildings, Kilometers away from each other.

What does all this has to do with this post's title?. Well, I dare say that officially separating both roles warps each individual's mind towards two software design approaches. Top-down and bottom-up. Analysis and synthesis.

Astronauts deal with ideas, designs and hopes. They analyse a problem. They concieve a view of the solution and try to put it somewhere, somehow. Call it a UML diagram or whatever. They generally don't care too much about technological or programming issues, as every difficulty can be overcome, and think the hard work is done. Remember, top-down. Once decomposed it should be easy.

If you ever wrote a line of code in a medium-sized project —which you might not if you're in the Cosmo Team— and you're humble and honest —scarce virtues— you know that, at this point, the process just reverses and it's not easy at all.

Programmers need to deal with lines of code and machines. They are forced to syntethise, given their circumstances. They take some sort of specification, design —when lucky—, a technological environment in form of software and hardware and need to combine all this to produce something that works —or, at least, appears to—. In some way, it's pure bottom-up. The programmer's materials for the building process are existing technologies, libraries, language primitives, etc. that must be mixed together "upwards" to match the design, functionality or specification. The same materials that might have been overlooked during the analytical process.

This is the main reason why, when left alone —probably by inertia—, most programmers take the bottom-up approach. The bad news is that they generally forget that the bottom-up approach is also a design approach that also involves an analytical process. But they generally rush to code. When the main program and some tricky parts are outlined the hard work is done. Remember, bottom-up. Design will magically arise and every piece will fit. Once a few things are outlined or coded it should be easy.

Same dog, different collar?. Sure. Now a different set of problems arises: forgotten functionalities, huge refactoring efforts, this-is-not-what-I-expected user dissatisfaction, etc. but that's another story.

So, why don't we take the best of both worlds and use 'Sandwich Design' practices?. Let's analyze the problem without overlooking or ignoring the building materials, skills or details. Let's take a wider point of view and try to provide a solution from both sides, from the top and from the bottom.

In the software development world you'll often see architecture astronauts proposing completely absurd, complex or already solved solutions. You'll often see programmers who excel at programming and know about tiny pieces of technology that could potentially solve complex problems but who don't care at all about what the general problem is.

I think that working from both ends, analysis and synthesis will converge more easily, also mitigating friction among teams and processes and providing a shorter schedule.

This is much easier to achieve in small or medium-sized companies that take a more integrated approach in Software Development. In fact, I believe the best ones really forget about prejudices and myths, roles and methodologies and, aware or not, are using Sandwich Design all the time.

26 June 2006

12 pasos hacia un código mejor


Hace ya seis años Joel Spolsky escribió un artículo titulado "The Joel Test: 12 Steps to Better Code", proponiendo un pequeño test para evaluar el lugar donde trabajamos o vamos a trabajar.

Gracias al wiki para traducciones que abrió Joel, pude contribuir facilmente a su traducción.

Creo que sigue siendo un artículo vigente; he aquí un pequeño extracto:

¿Te suenan las siglas SEMA?. Es un sistema un tanto exótico de medir lo bueno que es un equipo de desarrollo de software. No, ¡espera!. ¡No sigas el enlace!. Te costaría unos seis años solamente entenderlo. Por eso he creado un cutre-test altamente irresponsable de mi propia cosecha para medir el nivel de calidad de un equipo de desarrollo. Lo bueno que tiene este test es que hacerlo cuesta unos tres minutos. Con todo el tiempo que te ahorrarás, puedes aprovechar y estudiar medicina.

El Test de Joel
  1. ¿Utilizas software de control de versiones?
  2. ¿Puedes generar el producto en un solo paso?
  3. ¿Compilas el producto diariamente?
  4. ¿Tienes una base de datos para los bugs?
  5. ¿Corriges los bugs antes de añadir más código?
  6. ¿Tienes una planificación actualizada?
  7. ¿Tienes un documento de especificaciones?
  8. ¿Están los programadores en un lugar tranquilo?
  9. ¿Utilizas las mejores herramientas que puedes comprar?
  10. ¿Tienes gente para probar los productos?
  11. ¿Haces escribir código a los nuevos candidatos en las entrevistas?
  12. ¿Haces pruebas de usabilidad "de vestíbulo"?

La traducción completa está aquí.

29 May 2006

Si los arquitectos fueran ingenieros de software


Para iniciar una serie de reflexiones acerca del desarrollo de software, propongo como aperitivo un texto que se acerca bastante a la realidad de quien se enfrenta a tareas de desarrollo de software.

Se trata de un paralelismo que muestra a lo que tendría que enfrentarse un arquitecto si las cosas funcionaran como lo hacen en el mundo del desarrollo software.

El texto original no es mío. Se titulaba "If architects had to work like web designers" y ya no sé muy bien cuál es la fuente original, así que los interesados tendrán que buscarla.

Dejo una traducción de mi propia cosecha aquí:

Querido Sr. Arquitecto,

Por favor diséñeme y constrúyame una casa. No estoy muy seguro de cómo la quiero, así que lo dejo a su discreción. Mi casa debería tener entre 2 y 45 habitaciones. Simplemente asegúrese de que sea fácil añadir o quitar habitaciones en cualquier momento. Cuando me enseñe los planos ya le comunicaré mi decisión final. No se olvide de traerme el estudio de costes para cada configuración y así pueda elegir la que más me convenga.

Tenga siempre en cuenta que la nueva casa que elija debe ser más barata que en la que estoy viviendo ahora. Asegúrese, sin embargo, de que no sufre de las mismas deficiencias que mi casa actual (el suelo de la cocina vibra al andar sobre él y las paredes no tienen aislamiento suficiente).

Mientras va diseñando, también recuerde que quiero que los costes de mantenimiento sean mínimos. Esto puede implicar la incorporación de materiales fuera de presupuesto como aluminio, vinilo, etc… (si finalmente decide no utilizar aluminio debería justificarme su decisión en detalle).

Por favor asegúrese de que posea un diseño actual y de que se utilicen los materiales más modernos en la construcción de la casa, pues quiero que sea una muestra de los métodos e ideas más vanguardistas. Le aviso de antemano de que el diseño de la cocina tiene que tener en cuenta, entre otras cosas, la instalación de mi frigorífico de hielo de 1952.

Para asegurarse de que está construyendo la casa correcta para nuestra familia no olvide hablarlo con nuestros hijos y también con nuestra familia política. Mi suegra le dará unas buenas pautas de cómo debería diseñar la casa, ya que nos visita al menos una vez al año. Asegúrese de que valora todas estas ideas con especial cuidado para tomar la decisión correcta. Sin embargo, no olvide que soy yo quien tiene la última palabra.

Por favor no me moleste con detalles sin importancia ahora. Su trabajo es planificar la construcción de la casa: ver las cosas de forma global. Éste no es el momento adecuado, por ejemplo, de elegir el color de la moqueta. Por cierto, no olvide que a mi mujer le gusta el azul.

Tampoco se preocupe en este momento de los recursos necesarios para construir la casa en sí misma. Su prioridad absoluta es diseñar los planos y las especificaciones detalladas. Una vez que le dé mi visto bueno, sin embargo, espero que la casa esté construida en 48 horas.

A pesar de que está diseñando la casa totalmente a mi medida, no olvide que antes o después acabaré vendiéndola, así que debe ser atractiva para una gran variedad de potenciales compradores. Por favor asegúrese antes de terminar los planos de que existe consenso positivo en mi barrio acerca de las características de mi casa. Le aconsejo que se acerque a la casa que le construyeron a mi vecino el año pasado. Nos gusta mucho. Tiene muchas cosas que nos gustaría que la nuestra también tuviera, especialmente la piscina de 25 metros. Con un poco de esmero, supongo que podrá incluirla también en nuestra casa sin que influya en los costes finales.

Por favor, prepáreme un conjunto completo de proyectos. No hace falta en este momento que el diseño sea el final, puesto que por ahora sólo se usarán como promoción comercial. Le aviso, sin embargo, que será usted el responsable de cualquier incremento en los costes como resultado de rediseños posteriores.

¡Debe estar usted emocionado de trabajar en un proyecto tan interesante como éste! Poder utilizar las técnicas y materiales de última generación y poseer toda esa libertad para diseñar es algo que no ocurre a menudo. Contacte conmigo lo antes posible para contarme sus ideas y entregarme los planos.

PD: Mi mujer me acaba de decir que no está de acuerdo con muchas de las instrucciones que le acabo de dar en esta carta. Como arquitecto, es su responsabilidad resolver estas diferencias; yo ya lo he intentado en el pasado y jamás he sido capaz de lograrlo. Si no es usted capaz de aceptar esta responsabilidad, tendré que empezar a buscar otro arquitecto.

PD2: A lo mejor lo que realmente necesito no es una casa, si no una auto-caravana. Si cree que es el caso, comuníquemelo lo antes posible.


Actualización (29 de mayo de 2006):


Esta traducción la tenía almacenada desde hace tiempo y la he publicado directamente. Al parecer ya había sido traducida por otra persona en Mundo Geek

19 May 2006

What is NOT beta software


From Wikipedia:

"A beta version or beta release usually represents the first version of a computer program that implements all required features although additional features may be added. It is likely to be unstable but useful for internal demonstrations and previews to select customers, but not yet ready for release."

Yes, we all confuse terms from time to time but, come on, this one is easy. Isn't it?

What is NOT beta software:

  • An idea you had while having some beers with a couple of friends at the local pub which led to a wonderful (but empty) web site to announce it. (Great way to confuse and disappoint people).
  • An attempt to show how cool you are in a new language or framework by creating a new, incomplete and buggy implementation of a useless program which you never think to finish or mantain. (Does it make sense to call something beta if you're not following a development cycle?).
  • Three lines of code at sourceforge.net that you want other people to develop and finish for you without event knowing exactly what you want. (Do the words 'analysis', 'design' or 'specification' mean something to you?).
  • A program which constantly shows error messages when you're using it as expected. (That's not unstable, that's crap).
  • Desktop software without any kind of documentation, tips or hints on how to install it or use it, that only works on your computer. (Great way to distribute it!).
  • A way to publicize other products or projects by means of a powerpoint presentation about a non-existing program which shows a couple of screenshots you designed the day before. (No comments).
Software development is hard and anyone can do whatever he wishes, but fortunately English is a very rich language. Some other useful terms that may describe some programs more accurately include (from Wikipedia again):

"Pre-alpha: Sometimes a build known as pre-alpha is issued, before the release of an alpha or beta. In contrast to alpha and beta versions, the pre-alpha is usually not "feature complete". At this stage designers are still determining exactly what functionalities the product should have. Such builds can also be called development releases or nightly builds."

"Alpha: The alpha version of a product still awaits full debugging or full implementation of all its functionality, but satisfies a majority of the software requirements. It often lacks features promised in the final release, but demonstrates the feasibility and basic structure of the software."

"Vaporware (...) is software or hardware which is announced by a developer well in advance of release, but which then fails to emerge (...). The term implies deception, (...) it implies that the announcer knows that product development is in too early a stage to support responsible statements about its completion date, feature set, or even feasibility."

Snake oil is a Traditional Chinese medicine used for joint pain. However, the most common usage of the words is as a derogatory term for medicines to imply that they are fake, fraudulent, and usually ineffective. The expression is also applied metaphorically to any product with exaggerated marketing but questionable or unverifiable quality."

So could we all please stop spreading the wrong meaning of 'beta'?

05 May 2006

Your IT degree is over. Some advice for a smooth transition.


Yep, you finally managed to pass all your exams and deliver your final project on time. Five or more years dealing with complex algorithms, software engineering practices and countless other topics which give you a solid base and a bit of fun. Now you should be prepared to face reality with a relatively high degree of comfort. Are you sure?.

A math teacher recently told me that all formal studies are taught based on the supossition that when you finish that stage, you'll continue studying. Primary School is a preliminary to High School, High School to University, University is your career towards your PhD, and so on. So, what happens when you find a job, thus breaking the education link?.

Your mileage may vary, but I bet most of us felt really annoyed during that transition. Reality can be very different to what you had imagined. You need to get used to it.

With your permission, here's some advice that can make the transition smoother:

  1. Learn English (and learn it well). If you're in the IT field, no matter in which country, English is no longer a plus. It's a must. Just as nowadays you can't conceive a computer with no network, think of English as the mean of communication in the field. Superficial understanding of a technical article is not enough, so make a little effort if you need to improve it.
  2. Find a good mentor. This is a difficult one, but try hard to find a mentor inside your organization if you can. He can be your boss, a colleague or maybe even someone from other department. An experienced, willing-to-teach person can solve your doubts, clear your thoughts, refer you to good information sources and guide you towards the right direction.
  3. Search the Web. Yeah, the web can be full of rubbish but, believe me, it's also full of invaluable information and incredibly smart people. To begin with, don't miss a single article from Joel Spolsky . Browsing through his weblog you'll learn how to write a specification, how to schedule a project, etc... in a useful and realistic manner, far away from formal methods that are rarely used (another lesson you'll learn when you face reality). This is just an example, have a look and you'll find other superb sources of information.
  4. Read books. Fortunately, superb books are available on every conceivable topic. I don't recommend you to buy very technical books, cause they are expensive and they'll get outdated in a year. These are the kind of books that should be bought by your company. Instead, spend a few bucks in classic or more pleasant to read books that you can leave on your bedside table. There are lots of them, but maybe you can begin with "Peopleware: Productive Projects and Teams" or "The Pragmatic Programmer", depending on your interests. Buy them in English and always check an on-line store before paying extra money at some expensive bookstores.
  5. Be patient and humble, but believe in yourself. Your career dind't begin at University. It begins now. So be patient and humble, ask when you need it and learn as much as you can. Experience is important, but don't underestimate yourself when you hear or read from others, cause you might surpass their abilities in a short period of time. Many people exaggerate (or even lie), so be critic and believe in yourself as much as you believe in others.
This is just a little introduction that I hope can help you through this process, but don't forget that your experience is the one that matters. So go for it.

PS: How was your transition from University to your first job? Any advice? Share your story with us!


Feedback from readers:

25 May 2006, Ghost:

  1. Play with as much as possible as you can - do a Ruby On Rails application, write a Python script, make a modification to a PERL program and contribute to a SourceForge Java application. It's not going to hurt and you will learn different techniques that you may not be officially taught at Uni.
  2. Have at least one demonstration program you can reference in your resume and show off when asked. Preferably this should be something in the field that you want to get into. If it's desktop applications - make sure you have a version that runs on your laptop backed by a MySQL or Access database, if it's web based make sure that your name is on the site somewhere and include the URL in your resume as well as having a local test copy on your laptop.
  3. Always take your laptop to interviews with you. Make sure it's loaded with code, you have a local copy of MSDN or the JRE runtime reference, or the Python library reference as well (preferably all of them). Be prepared to show off your own code if that answers a question in more detail than you could yourself (Remember - actions speak louder than words).
  4. SourceForge projects may be considered lame - but they are very public and it is quite easy to send a link to a list of contributions that you have made. It also shows that you can work in a team, respond to externally submitted bugs and make your own contributions. All of this is important.