Entregar valor, no versiones

Llevamos casi 20 años sacando versiones de software y cada día hay cosas que mejorar.

¿Como quieres entregar tu trabajo?

Cuando acabas de programarlo. Todo empieza

Una vez el programador acaba la tarea, JIRA o historia de usuario marca la tarea como solucionada, algún compañero revisa el código y otro prueba que lo programado soluciona la necesidad original.

Cuando se va acabando la iteración el responsable de producto debe seleccionar cuales serán visibles, cuales son cambios que aportan valor al usuario.

Una vez marcadas en Jira empieza la complicada e importante tarea de escribir un "Texto de resolución" que realmente le explique al usuario porque ese cambio le ayudará a ser feliz.

¿Compras un aparato de 4 ruedas con motor de combustión?

o

¿Compras algo que te haga sentir libre?

Sabemos que internamente solemos poner nombres técnicos para enterarnos de las cosas, pero rara vez ese texto que usamos para describir la tarea o situarnos en el problema, es lo que le estamos aportando al usuario.

Un listado para controlarlo todo

Con nuestro listado de cambios bien escrito, lo ideal es que el usuario pueda profundizar esa idea "comercial" para conocer como esa novedad le cambiará la vida. Lo ideal es que todos los cambios tengan un hiperenlace a la ayuda, podemos ofrecerle al usuario una ventana para que se regocije en la novedad que más le interese y pasar por alto las que no le aportan especialmente.

Al mismo tiempo nos aseguramos que en la ayuda está reflejado el cambio o actualizada la captura. Cada versión mejora la documentación y la tenemos perfectamente sincronizada con el producto.

Este simple enlace cierra el circulo de la prueba y la documentación.

Los siete magnificos

Con esas decenas y decenas de cambios que aportan valor, tenemos que seleccionar unas pocas (No más de 7) que serán las que definan la versión, las que realmente son algo más, las que se recordarán, las que hagan que los usuarios se enamoren.

De esos 7 magnificos puedes hacer videos, post o fortalecer la comunicación.

Consistencia

A las personas nos gustan que las cosas cuadren, que todo tenga un sentido. Por ello si defines unos objetivos/palabras para la versión, y pones un poco de ellos en todas las novedades, el usuario sentirá que los puntos están conectados. Si las palabras se repiten en los diferentes cambios y novedades, sentirán que se trabaja en un mismo rumbo, que todo tiene consistencia.

Sencillo y agradable

Es buena idea realizar una plantilla con un guión de contenidos para novedades de producto y conseguirás ¡un producto que apasione!

Grupo Visual MS obtiene la Certificación ISO 27001

Grupo Visual MS, así como cada una de sus divisiones –Visual Trans, Velneo y vidiv– han recibido la Certificación ISO 27001: Sistemas de gestión de seguridad de la información.

La ISO 27001:2013 es la norma internacional que proporciona un marco de trabajo para los sistemas de gestión de seguridad de la información (SGSI) con el fin de proporcionar confidencialidad, integridad y disponibilidad continuada de la información, así como cumplimiento legal. La certificación ISO 27001 es esencial para proteger sus activos más importantes, la información de sus clientes y empleados, la imagen corporativa y otra información privada. La norma ISO incluye un enfoque basado en procesos para lanzar, implantar, operar y mantener un SGSI.

La implantación de la ISO 27001 es la respuesta ideal a los requisitos legislativos y de los clientes, incluyendo el RGPD y otras amenazas potenciales, incluyendo: Crimen cibernético, violación de los datos personales, vandalismo / terrorismo, fuego / daños, uso malintencionado, robo y ataque de virus.

De esta manera, tanto el grupo, como nuestras divisiones, refuerzan la confidencialidad, integridad y disponibilidad de la información, tanto interna (empleados, operativa), como externa (clientes), manteniendo la importancia que este tema siempre nos ha supuesto.

Héctor Valladares, Nacho Lamas, Enrique Moldes y Domi Fernández, recogen las certificaciones del grupo y de las divisiones.

¿Por qué mantener el código fuente limpio?

Realizamos un curso de Clean Code en el vCenter, impartido por Alberto Basalo.

El motivo del curso es concienciar, reforzar las buenas prácticas e incidir en los beneficios que aporta mantener nuestro código limpio, como puede ser la rentabilidad. Os dejo un resumen.

Cosas que debemos tener en cuenta cuando escribimos código:

• Pensar en el mantenimiento.

• Pensar en la evolución.

• No caer demasiado en él “por si acaso”.

Recomendaciones para mantener el código fuente limpio y legible

• Facilitar la lectura del código. El código se lee 10 veces más veces de las que se escribe. Facilitar su lectura nos hace más productivos.

• Keep it simple. No adornes, fácil de entender, fácil de leer.

• No dupliques código.

• Responsabilidad única. Un proceso/función sólo hace una cosa y la hace solo ella. Retornar un valor.

• Procesos/funciones pequeños. Cuanto más pequeño más reutilizable.

• Los nombres deben mostrar la intención y ocultar los detalles (no ofuscar):

  • Las variables que sean sustantivos.

  • Los procesos/funciones que lleven verbos. Que describen la acción.

  • Es útil tener un vocabulario definido y reducido. Diccionario de nombres.

• Evita la globalización. Mejor si una función recibe todo por parámetros y no usa variables globales compartidas.

• Jerarquizar los procesos. Evitar llamadas de todo contra todo.

• Buscar alguna forma de hacer pruebas, aunque sea de forma genérica. Si se puede automatizar mejor.

La técnica del Boy Scout

Los Boy Scout cada vez que salen al campo, al regresar dejan la zona un poco más limpia de lo que la encontraron al llegar.

Cuando hay que tocar código, de paso que has pasado por ahí, déjalo un poco mejor de lo que estaba.

Me gustó la comparativa con hacer artesanía, por el cariño que ponen a sus productos.

Manifiesto de un artesano o artesana del software

• No sólo software que funciona, también software bien diseñado.

• No sólo respondo al cambio, también agregar valor.

• No sólo individuos e interacciones, también una comunidad de profesionales.

• No sólo colaboración con el cliente, también asociaciones productivas.

Frases que me han llamado la atención de Robert C. Martin, autor del libro “Código limpio”

La proporción de tiempo dedicado a la lectura frente a la escritura es muy superior a 10 a 1. Constantemente leemos código antiguo como parte del esfuerzo por escribir un nuevo... [Por lo tanto,] facilitar la lectura hace que sea más fácil de escribir.

No es el lenguaje lo que hace que los programas parezcan simples. ¡Es el programador el que hace que el lenguaje parezca simple!

La duplicidad es el principal enemigo de un sistema bien diseñado.

El código limpio siempre parece escrito por alguien a quien le importa.

Un nombre descriptivo largo es mejor que un nombre corto enigmático. Un nombre descriptivo largo es mejor que un comentario descriptivo largo. Nombra una variable con el mismo cuidado con el que nombras a un primogénito.

El código limpio no solo se escribe siguiendo un conjunto de reglas. No te conviertes en un artesano de software al aprender una lista de heurísticas. El profesionalismo y la artesanía provienen de valores que impulsa la disciplina.

Una función debería hacer una sóla cosa, hacerla bien, y hacerla sólo ella.

Ley de Curly

Un bug anda suelto

Uno de los objetivos de nuestros productos es que sean estables, que sean fiables. Intentamos que cada cambio realizado en el producto, en el código fuente, no rompa, no estropee nada. Es vital para todos nosotros que cada usuario disfrute de mejoras y no de disgustos.

En este post voy a intentar explicar como en una de las versiones de Velneo un hábil bug pudo escaparse de todas las barreras de defensa que tenemos.

Barrera 1: El programador

Un buen desarrollador con años de experiencia comete menos errores, el código que realiza se protege de los bugs. Aunque en algunos casos se ve como el "culpable" de introducir el bug, tambien es el "culpable" de crear el producto. Si no se toca código es difícil añadir bugs.

Barrera 2: La integración continua

Dentro de la integración continua se pueden usar diferentes sistemas para detectar bugs (Pruebas unitarias, pruebas funcionales, análisis estáticos de código, etc.)

Dentro de la integración continua es muy útil tener automatizadas todas estas pruebas automáticas que detectan fallos de desarrollo y nos da garantías de que los cambios subidos no rompen nada.

En Velneo contamos con la herramienta "vEst" que es una aplicación que ejecuta la mayoría de las funciones de Velneo cada vez que un programador toca una línea de código. Vienen a ser unos 2.000 test que prueban base de datos, objetos, procesos, javascript, etc.

Cada día intentamos añadir más tests para poder comprobar el mayor porcentaje de funcionalidades de la plataforma en todos los sistemas operativos (win ,lin ,mac ,ios ,android).

Barrera 3: El equipo de desarrollo

Ya sea por revisión por pares o por programación por parejas, se pueden detectar los bugs antes de que el código salga del departamento de desarrollo.

Actualmente, todos los programadores invierten un valioso tiempo en revisar y compartir los cambios de los compañeros. Es vital poner toda la atención posible para descubrir si algún bug paso las dos primeras barreras. En este caso de este bug, pasó delante de mis ojos y no fui capaz de verlo :-(

Barrera 4: El departamento de pruebas

Todos los Jiras, tienen que ser "cerrados" por el equipo de pruebas o la persona que ha introducido la necesidad/incidencia. Al mismo tiempo se prueban las novedades sobre aplicaciones estándar para ver si funciona correctamente. Un buen tiempo dedicado a probar que todo funciona bien y sin cambios puede detectar bugs que han llegado a esta barrera.

Barrera 5: Los betatesters

Si el bug no se ha encontrado dentro de los equipos de desarrollo y pruebas, el producto con el error llega al betatester. Es importante que el betatesters invierta tiempo en probar las novedades y cambios y que actúe casi como un usuario final. En algunos casos intentamos poner esta versión en producción, para poder darle una garantía de prueba real.

Si el bug ha pasado todas estas barreras, ha llegado al cliente, posiblemente el coste es ya muy alto. Comunicaciones, revisiones, emails, disculpas, mala imagen, inestabilidad, etc.

Cada vez que un bug salta todas las barreras, intentamos analizar como pudo pasar por cada barrera, para dar un punto de mejora y evitar que pasen más en el futuro.

Cómo describir adecuadamente una incidencia a un desarrollador

Uno de los puntos más conflictivos, problemáticos y complicados de una empresa de software es la comunicación entre los departamentos de soporte y de desarrollo. Uno de los puntos clave en esta comunicación son la notificación de incidencias y como éstas son interpretadas y gestionadas.

Para muchos desarrolladores esta es una parte crítica, por lo que debemos prestar una especial atención, cuidado y profesionalidad.

De la buena comunicación de una incidencia depende la calidad del producto, la velocidad de desarrollo y la buena relación entre soporte y desarrollo.

Os pongo unos consejos que nos puede ayudar a que todos los que introducimos incidencias podamos colaborar al éxito global.

El título

• El título ideal, es claro, conciso y directo. Un buen título debería ser suficiente para que un desarrollador pueda situarse mentalmente en lo que ocurre y donde.
• Se debe transmitir lo que ocurre y no lo que se cree que ocurre.
• Debe ayudar a situar al desarrollador en el componente y área de la aplicación donde ocurre la incidencia

Mal título: El programa rompe.

Mal título: Al pulsar el botón de “Facturar” no hace nada, debe ser por estar bloqueada la entidad.

Mal título: El formulario aparece pequeño.

Buen título: En el formulario de facturas de cliente al hacer "click" en el botón "Aceptar" no se cierra el formulario.

La descripción

• Incluye un resumen, los pasos para reproducir la incidencia, los resultados esperados y lo que ocurre en realidad.
• Evita usar palabras descriptivas (sale mal, está feo, es pequeño, no me gusta), trata de ser conciso y describir adecuadamente.

Mal: Cuando imprimo, no ocurre nada. La aplicación no funciona.

Bien: Pulso en el botón “Imprimir”, aparece el cuadro de dialogo de impresión, la barra de progreso de impresión no aparece.

• Debemos de poner claramente lo que sucede:

Mal: Abrimos un fichero.

Bien: Hacemos doble click en el fichero para abrirlo.

Información adicional

En ocasiones, como añadido, puede ser aconsejable una captura con lo que sucede. Puede ayudar al desarrollador a tener una visión global.

Si la incidencia ocurre con unos datos específicos o una aplicación particular. Es muy aconsejable añadir a la incidencia una versión acotada de la aplicación donde sea realmente fácil observar el comportamiento.

Hay que tener en cuenta que es una información adicional, una imagen o unos datos acompañados de un mal título o mala descripción, solo conseguirá liar al desarrollador.

Resumen

• Intenta escribir la incidencia tan corta como sea posible, esto te ayudará a dejarlo más claro.
• Relee la incidencia justo antes de enviarla y ponte en la mente de la persona que la leerá.
• Un buen resumen de la incidencia ayuda a que se solucione antes.
• Un mal resumen de la incidencia creará un conflicto.
• No añadas opiniones o creencias, limítate a transmitir lo que ves.
• Por encima de todo, se preciso. A los desarrolladores les gusta la precisión.

Enlaces de interés

• http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

Las contraseñas

Toda nuestra vida digital está protegida simplemente por unas palabras o conjunto de letras y números. Es lo que llamamos comúnmente contraseñas.

Si una contraseña de uno de nuestros servicios es descubierta por alguna otra persona o por algún malware, puede hacernos mucha pupa, borrando información o filtrándola donde no queremos.

Es importante que tengamos un poco de cuidado en su creación y uso.

• Utiliza siempre contraseñas robustas. Aquí hay cierto debate entre que es más robusto, una contraseña con complejidad (que incluya caracteres especiales, mayúsculas, minúsculas y números) o una contraseña con mayor longitud. Lo mejor será que sea ambas cosas, es decir: compleja y larga.
  • Que la contraseña no tenga relación con nuestro nombre de usuario (Ejemplo usuario: david / contraseña: david12).
  • Evita usar elementos comunes como el nombre de algún familiar, tu fecha de nacimiento o tu aniversario, el nombre de alguno de tus hijos y términos del estilo que alguien podría averiguar.
  • Evita usar letras seguidas del teclado como es “asdfgh”, “qwerty”, “asdf123”.
• No reutilices contraseñas. Nunca emplees la misma contraseña en diferentes aplicaciones y servicios.
• Siempre que sea posible usa el doble factor de autenticación, será más seguro que la mejor contraseña. Eso sí, evita si es posible que sea utilizando el envío de mensajes SMS. Esta opción es la menos segura, ya hay delincuentes con conocimiento y capacidades para saltársela.

Si usas contraseñas inadecuadas es fácil que te las puedan descubrir. Un ejemplo :

• Las 3 contraseñas más usadas según los datos de 4.600.000 cuentas de LinkedIn hackeadas fueron: link, 1234, y work.
• Las 3 contraseñas más usadas según los datos de 58.000 cuentas de Twitter hackeadas fueron: 123456, 123456789, y 102030.
• Las 3 contraseñas más usadas según los datos de 450.000 cuentas de Yahoo! hackeadas fueron: 123456, password, y welcome.

Si tu contraseña no es adecuada, ¡cámbiala ahora mismo!

Nada es seguro al 100%. Ten siempre presente que, tarde o temprano nos van a atacar y debemos estar preparados.

Números de versión en software

Todas nuestras divisiones hacen software y quien más, quien menos, trabaja todo el día con versiones de aplicaciones. La versión de desarrollo, la versión de un determinado cliente, el parche que arregla el problema, la versión de ayer, la nueva y revolucionaria versión.

Todas las versiones deberían llevar un nombre, un nombre que nos permita:

• Firmar: Identificar inequívocamente un estado de nuestra aplicación en un momento dado.
• Integrar: Conocer con quien “se lleva” bien esta versión.
• Trazar: Permitir conocer en que ciclo/iteración se ha desarrollado.
• Distinguir: Marca comercial principal (año, funcionalidades principales).

Existen muchos tipos de numeración de versiones:

En Visual estamos unificando el criterio a la siguiente configuración:

Que esté compuesto por cuatro dígitos que nos permitan tener la suficiente flexibilidad para cubrir todas las necesidades de las distintas configuraciones. Por ejemplo:

11.3.0.9323

11.xx.xx.xx - Versión mayor
Cambio mayor de la aplicación con cambios importantes. Esta numeración suele estar marcada por cambios estratégicos comerciales en la división que pueden ir acompañados por una buena campaña de comunicación.

xx.3.xx.xx - Versión menor
Es el ciclo básico de trabajo y son los cambios programados para ese ciclo de desarrollo, se supone que va acompañado con pruebas, novedades y documentación, videos, etc.

xx.xx.0.xx - Parche
Son los inevitables parches que arreglan un problema y deben poder publicarse rápidamente, no se acompañan de novedades, ni de documentación, ya que estas versiones deben poder sacarse rápidamente, aunque lo ideal sea no necesitar sacar ninguna.

xx.xx.xx.9323 - Sello
Es lo que identifica inequívocamente a la versión, evita que existan en la calle dos aplicaciones distintas con el mismo número de versión. Muy cómodo cuando en soporte o programación usan decenas de versiones en el día a día. Es un número consecutivo que puede ser el Build, Changelist, etc.

FAQ

A mi me gusta lo de Snow Leopard, Lion, froyo, gingerbread. ¿Por qué no usamos nombres frikis?

Todo nombre friki (comercial) tiene un número de versión “técnico”.

Menudo rollo, por la fecha del fichero se puede saber, y es más cómodo que aprender todo esto.

En algunos casos la fecha puede servir, pero al mover los ficheros de sistemas esa fecha puede cambiar y la sorpresa a la hora de poner en un cliente puede ser monumental.

¿Qué número le pongo a una beta que no quiero que se ponga en un cliente?

Si tienes una versión interna de pruebas y no quieres que se le ponga a un cliente, tenemos que decidir poner algo en el número de parche que identifique esa circunstancia por ejemplo 11.3.99999.9423. Donde 99999 nos indica que es un parche "especial".

Para innovar en tecnología

Para innovar en tecnología, ¡también debemos innovar en software!

Gracias al empuje de, por ejemplo, vForwarding o vERP en nuestro día a día en Visual, estamos conviviendo muchas palabras relacionadas con el mundo del software empresarial de las que es interesante conocer su significado.

Vamos a repasar estos conceptos.

Release Candidate (RC)

Es una versión con calidad de versión final que aparece unos días antes de la versión final. En un mundo ideal esta versión sería idéntica a la versión final. Desde esta versión a la versión final solo hay cambios menores o muy graves permitidos por el release manager.

Beta

Representa generalmente la primera versión completa del programa informático o de otro producto, que es posible que sea inestable, pero útil para que las demostraciones internas y las inspecciones previas seleccionen a clientes.

Pruebas funcionales

Una prueba funcional es una prueba basada en la ejecución, revisión y retroalimentación de las funcionalidades previamente diseñadas para el software. La pruebas funcionales se hacen mediante el diseño de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paquete informático.

Integración continua

Es una metodología informática que consiste en hacer integraciones automáticas de un proyecto lo más a menudo posible para así poder detectar fallos cuanto antes. Entendemos por integración la compilación y ejecución de tests de todo un proyecto.

Herramienta de control de código fuente

Es la gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo. Una versión, revisión o edición de un producto, es el estado en el que se encuentra dicho producto en un momento dado de su desarrollo o modificación.

Iteración

En el contexto de un proyecto se refieren a la técnica de desarrollar y entregar componentes incrementales de funcionalidades de un negocio.

Esto está comúnmente asociado al desarrollo ágil de software, pero podría referirse a cualquier material. Una iteración resulta en uno o más paquetes atómicos y completos del trabajo del proyecto que pueda realizar alguna función tangible del negocio. Múltiples iteraciones contribuyen a crear un producto completamente integrado.

Metodologías agiles

Es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo ágil; la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo es llamado una iteración.

Hazlo realidad

Hace unos días años un amigo me recomendó leer un libro (Getting Real) con el que realmente comparto la inmensa mayoría de consejos que apunta sobre cómo tener una empresa de desarrollo de software y no morir en el intento.

Perfectamente ordenados y de forma práctica, recorre temazos como:

• Diseño
• Funcionalidades de las aplicaciones
• Versiones
• Promoción
• Soporte
• Trabajo en equipo
• Motivación

Todos los puntos nos suenan mucho, ¿verdad?

Está escrito por una empresa muy reconocida en Internet llamada 37 Signals, absorbida por Basecamp hoy día, con varias aplicaciones para trabajo en equipo, gestión de proyectos, gestión de contactos, notas, etc.

Aunque el libro haya sido escrito hace ya más de diez años, continúa muy vigente hoy en día. Conforme iba leyéndolo, fui escribiendo un resumen en español que paso a compartiros.

Línea de salida

En un proyecto, la fecha límite y el presupuesto son intocables, si ves que no llegas, reduce el alcance. Elimina todo lo que no es realmente necesario: documentación, especificaciones técnicas, funcionalidades superfluas... Es bueno hacer equipo con el cliente, es una voz útil y debes involucrarlo en el proceso.

Es fundamental que el software sea intuitivo. No es necesaria formación para aprender a usar Google o Amazon, tu software debe ser igual de simple y usable. No te obsesiones con estudiar mucho a la competencia porque puede limitar tu pensamiento.

No engordes

No te excites cuando las cosas parezcan ir bien y pienses en contratar a talentos a destajo. Un equipo reducido y trabajando en objetivos cercanos es mucho más ágil que una gran organización. El mercado de las tecnologías exige ser ágil, no pierdas esa cualidad. Además, siendo pequeño puedes ser más cercano al cliente.

Prioridades

Lo primero es definir la visión de la aplicación, por ejemplo para BaseCamp es "Project Management is communication".  Esta filosofía condicionará muchas decisiones sobre la aplicación. Se parte de lo abstracto y se acaba en los detalles.

Usa equipos de 3 personas: 1 desarrollador + 1 diseñador + alguien entre los dos mundos. Las limitaciones te guían y te ayudan a focalizarte. No te preocupes de posibles problemas en el futuro (escalabilidad), pasa de ellos, concéntrate en los de ahora.

Seleccionando funcionalidades

Es muy importante filtrar las funcionalidades que quieres añadir a la aplicación. Piensa lo que necesita, luego divídelo entre dos una vez y luego otra. Una nueva funcionalidad es como adoptar un hijo, el proceso es el siguiente:

1. Di al cliente que no vas a incluir esa funcionalidad que te pide.
2. Pídele a esa funcionalidad que 'demuestre que lo vale'.
3. Si sale que no 'lo vale', fin. Si sale que 'sí lo vale', continua.
4. Boceta la pantalla.
5. Diseña la pantalla.
6. Prográmala.
7. Prueba, prueba, prueba, prueba, prueba y vuelve a probar.
8. Comprueba si los mensajes de ayuda deben cambiarse.
9. Actualiza el 'tour del producto' si es necesario.
10. Actualiza los contenidos / promesas de marketing si es necesario.
11. Actualiza los términos del servicio si es necesario.
12. Comprueba si algunas promesas han sido rotas.
13. Comprueba si la estructura del precio está afectada.
14. Lánzalo.
15. Aguanta la respiración.

Las propuestas de los clientes hay que olvidarlas, las verdaderamente importantes 'flotan en el ambiente'. Hay que preguntarse qué sobra en la aplicación, no qué hace falta.

Proceso

1. Brainstorming
2. Esquemas en papel
3. Pantallas en HTML
4. Desarrollo (programación)

Es importante hacer software que sea un marco general, sin muchas opciones. Cuanto más abierto, más fácil será que el usuario encuentre soluciones, no barreras. Pon a funcionar tu software cuanto antes para pulirlo bien. Desarrollar aplicaciones no es neurocirugía, las cosas no tienen que salir 100% bien a la primera, además el test bueno, es en real.

Organización

Las reuniones no son trabajo. La 'reunionitis' es síntoma de conceptos poco claros en la empresa. Si te reúnes mucho es que debes aclarar conceptos a tu equipo. Si no queda otro remedio haz reuniones de máximo 30 minutos, cuantas menos personas mejor y sin agenda del día.

Equipo

No es obligatorio contratar mucha gente, es preferible poca, buena y bien avenida que empezar a contratar gente porque pienses que los necesitas, probablemente te ralenticen, sea mucho más difícil de gestionar, problemas de comunicación, etc.

Diseño de la interfaz

La interfaz es tu producto y no lo que hay desarrollado debajo. Se diseña antes de programar nada y siempre desde el centro de la página (cuerpo principal que será un post, un menú, etc.) hacia fuera (colores, logo, encabezado y pie, márgenes, menús laterales....).

Hay que diseñar 3 estados: normal (aplicación en uso) blanco (aplicación nueva, que el cliente no vea una patalla vacía, fea).

Como no hay datos, habrá que incluir tutoriales y comentarios de ayuda, capturas de pantalla de ejemplo con datos, explicar cómo será la pantalla, contestar a estas preguntas: ¿qué es esta página?, ¿qué hago ahora?, ¿cómo será esta página cuando esté completa? ¿cómo serán los errores? (cuando la aplicación falla).

Es lo que llamamos 'diseño defensivo'. No todas las páginas deben mantener cabecera, pie, etc. Pesa más el contexto/funcionalidad de cada pantalla que la coherencia extrema de todo. El texto es diseño. Las pantallas de administración/personalización no deben estar separadas, sino que se deben poder editar los valores en la pantalla principal.

Código

Se debería pagar a los programadores para que quiten código de un programa, no para que lo escriban. Se debe permitir que fluya la información hacia fuera: XML, JSON, API... para otros desarrolladores.

Palabras

No escribas documentos muertos como borradores (mejor trabajar con cosas reales), especificaciones técnicas (son un brindis al sol, nadie las lee, están desactualizadas...). No hagas ningún documento que viva fuera/aparte de las aplicaciones.

Habla en lenguaje coloquial, sin ser pedante/técnico. Pon texto real, no Lorem Ipsum. Piensa en tu producto como en una persona con personalidad, el texto debe tener esa personalidad. El texto es la voz de tu producto y está 24 horas hablando a tus clientes.

Precios y registro en la web

El alta y la baja deben ser procesos sencillos, rápidos y gratuitos. La importación y exportación de datos debe ser fácil y poder hacerse en cualquier momento. Si hay que dar malas noticias (subida de precios) se comunicará con antelación y se darán periodos de adaptación para suavizar el impacto entre los clientes.

Promoción y publicidad

Se seguirá la filosofía de Hollywood:

1. Trailer (intriga): Se contactará con expertos apelando a su vanidad para que hablen de ti: Boing Boing, Digg, TechCrunch...
2. Pre-estreno Semanas antes del lanzamiento publica las características que tendrá, da acceso a los expertos que vieron el trailer, pon pantallazos, anima a la gente a que esté informad, que se dé de alta, es decir, crea expectación.
3. Lanzamiento: Lanza el marketing a saco, consigue que blogs enlacen con tu página, publica los progresos: número de usuarios que lo usan, noticias, actualizaciones... manténlo vivo.

En cualquier caso ten en cuenta que la mejor promoción es un excelente producto. Ingredientes aconsejables en tu web:

• Vista general que explique los beneficios del producto.
• Tour guiado a los visitantes por sus características.
• Pantallazos y videos con la filosofía tras el producto.
• Ejemplos reales de lo que se puede hacer.
• Testimonios, prensa y noticias reales sobre el mismo.
• Foro.
• Precios.
• Blog, útil y ameno, dirigido al perfil de usuarios del producto.

Los blogs funcionan mejor que la publicidad y son más baratos. Comenta donde te comenten y pregúntales si quieren ser 'VIP', sé elegante con los que te critican.

También es promoción publicar videotutoriales, trucos o consejos. Puede ser interesante usar tecnologías e integraciones llamativas.

Aprovecha el poder del upgrade: si alguien no puede hacer algo porque está en una versión básica, dile que pagando algo más podría hacerlo, y que tendría además otras ventajas que pasarás a mencionar.

El nombre de la aplicación debe ser explicativo y recordable, no pongas 'Project Manager Collaboration', si no 'BaseCamp', por ejemplo.

Que el dominio .com esté cogido no es crítico, puedes añadirle algo tipo 'ourbasecamp.com'

Soporte

Derriba el muro entre soporte (camareros) y programación (cocina). Deben cambiarse los roles de vez en cuando para sentir el feedback de los clientes en cocina.

Formación: usa la ayuda y las FAQ para completar el manual y la formación. Nadie aprende a usar Google o Amazon, ¿por qué deben aprender a usar tu aplicación? Si recibes soportes repetitivos por el mismo tema, pon información o enlace a FAQ en el punto donde se produce esa duda.

Los soportes deben responderse en el momento (90% en 90 minutos), personalmente, sin textos enlatados.

Fomenta que los foreros se ayude unos a otros, quítate de en medio. Si hay problemas técnicos, avisa a todos, aunque casi nadie se hubiera enterado.

Post-Lanzamiento

30 días después del lanzamiento saca una actualización. Realiza publicaciones sobre las nuevas mejoras.

No hay betas, si tu app no está para consumo público, mejor no la publiques.

Los bugs suceden, no pasa nada. Se priorizan por impacto (gravedad y alcance de usuarios) y punto. Si te chivan uno y no es prioritario explica por qué no es urgente, que hay otros que afectan a más gente. Sobre todo sé honesto.

Hay un punto en el que debemos dejar que el producto simplemente exista, sin añadirle funcionalidades hasta el infinito.

Conclusión

Concéntrate en poner todo esto en práctica, ejecutarlo. Las ideas sin ejecución no sirven de nada. Mantén el equipo motivado. Puedes aplicar la filosofía 'Getting Real' a otras áreas de la vida, no solo al software

También podéis leer el libro completo en inglés (son pocas páginas) de forma totalmente gratuita.

Lo que no nos enseñaron en clase de matemáticas

Seguro que os pasó lo que a mí, y si no, tuvisteis mucha suerte: mis profesores de matemáticas no fueron precisamente los que hicieron que me gustaran... Más bien parecían empeñados en lo contrario.

Conjunción astral

Hace unos días se produjo una conjunción astral (ya sabéis los que me conocéis -o sobre los que ejerzo proselitismo salvaje- que astronomía sí, pero lo otro NO, así que no me entendáis mal ;-)) .

Estaba leyendo en Menéame un artículo sobre por qué el 1 dejó de ser un número primo porque me recordaba a lo de que Plutón ya no es un planeta y me acordé de que había comprado un par de libros de una nueva colección de RBA sobre matemáticas para ver qué tal eran, y uno de ellos hablaba precisamente de números primos.

Y cuando me puse a leerlos por encima vi una referencia a un tema que ya había visto en un documental sobre bosques y selvas de la serie Planeta Tierra de la BBC narrada por David Attenborough que me había pasado David Gutiérrez (y que yo también os recomiendo).

Vamos a ver de qué trata.

Planeta Tierra: Las Cigarras

Hay unas cigarras que viven durante mucho tiempo en estado de ninfa, de larva, y que una vez pasado ese tiempo despiertan lo justo para procrear y morir a continuación de reproducirse.

Ya el hecho de que dediquen la mayor parte de su vida en estado larvario para vivir como adultos unos pocos días es bastante impactante. Pero hay más.

Estas cigarras se llaman, respectivamente, Magicicada Tredecim y Magicicada Septendecim. Lo importante aquí es el apellido que, como podéis deducir, se refiere a un número. En concreto al 13 y al 17 respectivamente. ¿Y por qué?

Aquí viene lo interesante: tanto una como otra, como acabo de explicar, se pasan mucho tiempo en estado de ninfa, y sí, como habréis deducido, el primero se pasa 13 años en ese estado y el segundo 17. Exactos, ni más ni menos, siempre lo mismo. No se pasa uno 12 ó 14 años y de media 13, o el otro unas veces 16 años y otras 18 y de media 17. No. Siempre 13 años o siempre 17.

¿Y por qué esos números? Pues la explicación en si es sencilla: hay un parásito de ambas cigarras que tiene también un período de madurez largo, aunque no tanto, y pasa a la vida adulta cada 2 años.

Como las cigarras, vive el tiempo necesario para reproducirse y muere. ¿Y qué tiene que ver esto con los años que se pasa la cigarra en estado larvario? Aquí es donde entran las matemáticas, ésas que no nos enseñaron.

Aquí vienen unas pocas de matemáticas

Si os fijáis, tanto el número 13 como el número 17 son números primos. ¿Qué quiere decir esto? Que no pueden dividirse por otro número natural que no sea él mismo o el 1 para dar otro número natural.

Los números pares no son primos porque son divisibles por 2, exceptuando el propio 2 que sí que es primo.

Siguiendo hasta el 10, el 3 es primo, ya que no es divisible por ningún otro número. El 4, sin embargo, es par y es divisible por 2. El 5 es primo. El 6 es divisible por 3 y por 2, así que no. El 7 sí, pero el 8 de nuevo es divisible por 2. Y el 9 es divisible por 3, así que tampoco. El 10, divisible por 2 y por 5, así que no es primo.

Hay infinitos números primos y además no hay ninguna ecuación que nos diga si un número es primo o una función que nos permita predecir o calcular qué números serán primos. Es en definitiva un número muy interesante que da para mucho y que tiene muchas utilidades en la vida real, usándose en campos tan diversos como pueden ser la criptografía, la estadística, la ingeniería o la música.

Solución al misterio de las cigarras

¿Y por qué intervienen los números primos en este caso? El hecho de que las cigarras maduren a los 13 años o a los 17 y no en otro número evita que coincidan siempre con los parásitos, que lo hacen a los dos años.

Así, únicamente coincidirán con los parásitos cada 26 ó 34 años dependiendo de la cigarra, y no se los encontrarán también con esa misma frecuencia, por lo que una generación se podrá encontrar al parásito, pero la siguiente no. Pero además, entre ambas cigarras no se pisarán el terreno si no es cada 13 x 17 = 221 años.

Esto sucede porque al tratarse de números primos no permiten coincidencias con múltiplos o submúltiplos que no sean la multiplicación de ambos.

Pero bueno, ¿al final para qué os cuento todo esto?

Pues porque el uso de los números primos es bastante importante en programación y en la informática en general. Un ejemplo ya lo comenté: la criptografía, y en concreto el modelo RSA que está basado en el uso de números primos y en la inexistencia de una ecuación que los prediga obligando a un cálculo complicado con los medios actuales.

Además, muchas veces los puedes aplicar donde menos te lo esperas.

Recientemente he actualizado vBugMan incluyendo un refresco automático del panel principal. Para el que no lo haya visto, está compuesto por cuatro rejillas y cada una de ellas con su propia búsqueda.

Con el fin de optimizar su funcionamiento en internet y para evitar que la carga de las rejillas genere problemas al usuario (aunque no sean más que efectos del cursor, por ejemplo, mostrando el reloj de arena o esperas innecesarias), configuré los tiempos de tal forma que no coincidiera el refresco de las cuatro rejillas al mismo tiempo.

Para ello basta configurar un valor para el timer (intervalo de tiempo entre ejecución y ejecución de los procesos que cargan los registros de las rejillas) distinto para cada rejilla. Pero no me parecía bastante con eso ya que, conscientemente e inconscientemente, solemos poner tiempos que son múltiplos de 5 ó de 10, lo que haría que coincidieran las cargas al cabo de un tiempo.

Tampoco iba a poner a unos ciertos milisegundos y a los otros otra cantidad, porque de nuevo iba a usar cantidades que fueran múltiplos de 5 o de 10. Y tampoco iba a ponerlos porque sí, sin razonar.

Haciendo cálculos

Los tiempos iniciales que me había planteado como óptimos para cada refresco eran: 120, 160, 200 y 250 segundos. De esta forma, de inicio, el refresco de las rejillas no coincidiría siempre.

Haciendo unos cálculos podemos ver que los primeros que coincidirían (120 y 160) lo harían cada 480 segundos, es decir, cada 8 minutos (se calcula fácilmente a partir de la descomposición en números primos y calculando el mínimo común múltiplo: 120 = 2^3 * 3 * 5, 160 = 2^ 5 * 5 ---> 2^5  * 3 * 5 = 480).

Además, cada 40 minutos coincidirían 3 de los refrescos y los 4 se refrescarían de forma coincidente cada 3 horas y 20 minutos. Así que, aunque hubiera que esperar más de tres horas a que coincidieran los 4, las coincidencias de 3 y 2 refrescos me parecían demasiado frecuentes.

Recordé entonces la historia de la cigarra (que no la fábula de La cigarra y la hormiga) y me puse a buscar unos números primos que se adaptaran a los tiempos que quería poner. Al final, después de revisar una tabla de números primos y pensarlo un poco, usé los valores 127, 167, 227 y 257 para los valores en segundos.

De esta forma, los primeros que coincidirían serían los que tuvieran los tiempos de 127 y 167 y, para que sucediera, el panel debería estar abierto casi 6 horas (127 x 167 = 21.209 s ).  Pero es que para que coincidan 3 de los refrescos, habría que esperar 55 días con el panel abierto.

Y ya, para que coincidan todos los refrescos al mismo tiempo, el panel debería estar abierto más de 39 años (127 x 167 x 227 x 257 = 1.237.311.851 s).

Esta última cifra da una idea bastante clara de la potencia del uso de los números primos y cómo se pueden aplicar de forma sencilla en programación e informática.