Una imagen ocupa más de 1.000 palabras

~ davidgu ~ 1 comentario

El refrán decía …

«Una imagen vale más que mil palabras»

Fontana di trevi
Una imagen vale más que 1000 palabras.
Fontana de Trevi. Roma

Pero nadie nos dijo que si añadimos una imagen a nuestro proyecto de software o página web, nuestra creación ocupará mucho más tamaño.

Aunque parezca que lo importante es el código, procesos, tablas, etc, las imágenes son parte fundamental del interfaz de usuario y un buen uso puede conseguir que nuestras aplicaciones tengan un estilo sencillo y agradable que ayude a los usuarios a ser un poco más felices.

Del mismo modo debemos tener mucho cuidado con el uso de las imágenes, suelen ser parte importante de los recursos que componen nuestra aplicación. En muchas ocasiones superan el 25% del tamaño en bytes de nuestro proyecto

Tres consejos rápidos:

  • Usa herramientas de compresión y limpieza de los ficheros, te ayudarán a reducir enormemente el tamaño de la imagen sin tener perdida de calidad.
  • Uso del formato y número de colores necesarios. Si es imagen con pocos colores PNG, si son imágenes con miles de colores JPG
  • Organización en los nombres. Muchas veces no se puede encontrar el nombre apropiado a un recurso y se invierte tiempo en volver a crear otro.

Una herramienta que es muy útil es PngCrush, que permite por linea de comandos optimizar y comprimir cualquier imagen PNG

pngcrush.exe -rem alla -reduce fichero.png

Checklist para un cambio tecnológico en la empresa

~ davidgu ~ Deja un comentario

En las empresas suele ser habitual tener que hacer todo tipo de cambios para adaptarse a las diferentes situaciones. En especial los cambios de herramientas tecnológicas.
Lo más importante es saber en todo momento que es un cambio que afecta a personas y que en muchas ocasiones poco importa lo bueno o lo mala que sea la herramienta. La palabra clave para el cambio se llama comunicación. Es necesaria mucha comunicación, es mejor en exceso que en defecto.

Por la experiencia de los últimos cambios tecnológicos en los que he estado involucrado he creado este checklist

1. Conocer la nueva herramienta y probarla

Es importante tener claro que la nueva herramienta es la más adecuada para la empresa y deberemos hacer las pruebas necesarias para no tener sorpresas de última hora.

2. Conocer las fortalezas y debilidades de la herramienta que vamos a sustituir

Debemos conocer la herramienta que vamos a sustituir o el proceso que vamos a quitar. Todo lo que desconozcas de ella podrá ser utilizado en tu contra 😉

3. Comunicar las intenciones y las motivaciones del cambio

A las personas les gusta conocer los porqués, si se hace el cambio es por algún motivo. Esta fase es muy importante ya que es donde ganamos aliados

4. Aclarar dudas con los detractores y personas clave

Siempre tendrás personas con dudas, que no les gusta el cambio. Algunas estarán molestas porque no les consultaste o porque se enteran a última hora. Es importante hablar con todos ellos y que se sientan escuchados. En muchos casos te aportarán información importante que no has tenido en cuenta.

5. Formación a todos

La formación es la excusa perfecta para que todos se imaginen el cambio. El primer paso para aceptar un cambio es imaginarte a ti mismo con el cambio realizado. La formación nos ayuda a sacar a las personas del día a día para que se puedan imaginar una vez realizado el cambio.

6. Comunicar que ya queda poco y que estarás personalmente para ayudar

A todo el mundo le gusta saber que estarás allí y que si hay problemas podrás ser totalmente accesible. Es importante transmitir seguridad. Serás el socorrista de la piscina, no importa si sabes nadar o no, lo importante es que estés atento.

7. Cambio gradual

Siempre que puedas busca la posibilidad de implantar la nueva herramienta de forma gradual, primero 2 usuarios, luego 10,  luego 100. Siempre salen detalles o elementos no previstos que puedes ir solucionando tranquilamente cuando el cambio afecta a pocos usuarios

8. Pedir confirmación de que el cambio ha ido bien y si hay algún detalle pendiente

Algún usuario puede estar mal a gusto con el cambio y no transmitirlo directamente, suele ser muy efectivo pedir confirmación del cambio y enterarte de los pequeños flecos que puedan quedar.

5 motivos para usar DucksBoard

~ davidgu ~ Deja un comentario

Desde hace unos meses usamos la herramienta Ducksboard para representar los valores de los indicadores más importantes de la empresa. Después de este tiempo, puedo detallaros los 5 principales motivos por los que volvería a usarla.

1. Interfaz

Una de las primeras cosas que impresiona al empezar a usar Ducksboard es el cuidado detalle que tiene en todo su interfaz, desde la parte de administración a la parte de presentación. Todo tiene un estilo sencillo y agradable. Aunque intentes poner algún elemento feo no lo conseguirás.

2. +101 widgets

Lo primero que harás con ducksboard será trastear con los widgets que tiene, seguro que usas algún servicio de los disponibles ( Analytics, Zendesk, Twitter, Facebook, etc ). Una vez los «tires» en el panel podrás jugar con las posibilidad de cada widget.

3. Madera de buena calidad

Los fondos de nuestros Dashboards, son muy chulos, en especial los de madera, es algo muy tonto, pero es un buen motivo para elegir uno u otro producto.

4. API

Panel de ducksboard mostrando captura de web con info incrustadaEl API será lo que empezarás a usar cuando acabes de jugar con todos los widgets predefinidos que tienen funcionado. Es lo realmente potente y donde podrás empezar a sacarle partido para mostrar toda la información que necesitas.
Todo el API funciona con peticiones REST pasandole la información que quieres actualizar. Yo principalmente actualizo la información desde Python y Velneo, pero se puede actualizar de cientos de formas. Para probar sin duda Curl
Mi última incorporación a los paneles de ducksboard fue la imagen de una web con la información incrustada de rendimiento, errores y tamaño. De esta manera tenemos controladas el estado de todas nuestras webs.
El limite es la imaginación.

5. No es perfecto

Otra de las sensaciones que tendrás al usar Ducksboard es que parece que se te queda corto, como que tiene pocas cosas. En verdad tiene todo lo que usarás, nada es superfluo. Es un producto centrado en el 20% de las funcionalidades que usarán el 80% de los clientes.
De todas formas durante los últimos meses he visto como la gente de patolandia, se lo curra y va añadiendo cosas nuevas para facilitar la vida

Números de versión de tu software

~ davidgu ~ 2 comentarios

Nombre para las versionesTodas las divisiones hacemos software y más quien menos trabaja todo el día con versiones de aplicaciones. La versión de desarrollo, la versión del cliente Pepiño, 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 :

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

Existen muchos tipos de numeración de versiones :

http://en.wikipedia.org/wiki/Versioning

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

Esta compuesto con cuatro dígitos que nos permite tener la suficiente flexibilidad para cubrir todas las necesidades de las distintas configuraciones.
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, lo ideal es no sacar ninguna)
  • xx.xx.xx.9323 – Sello ( Es lo que identifica inequivocamente 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 tiene un número de versión “técnico”, lo de los nombres comerciales es para “nenazas” y aquí somos muy “pros”.

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é numero 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. 11.3.BETA.9432

¿Qué NO es una iteración?

~ davidgu ~ Deja un comentario

Ya que sabemos lo que es una iteración deberíamos tener claro lo que no lo es.

Iteraciones de tiempo variable. Un concepto clave en la iteración es el tiempo, todos sabemos que tenemos 24 horas en un día, no sirve decir a última hora, alarga hoy el día en una hora que necesito acabar un trabajo. Si en esta iteración has fallado, reconócelo y cambia algo para que no vuelva a suceder, cambiar la fecha de la iteración en el último momento no es viable.

La iteración no es un hito/meta Cuando pensamos que una iteración es el día de salida de la versión es que estamos confundiendo términos. La iteración es todo lo que se repite, tiene un principio y un fin.

Una iteración no es privada o pública, los entregables serán públicos o privados pero la iteración es lo que nosotros hacemos y repetimos cada vez para hacerlo cada vez mejor y más completo.

No validar el resultado de la iteración.  Cuando hacemos algo repetidas veces y no evaluamos sin el resultado ha sido bueno o malo, difícilmente sabremos si lo hemos hecho bien o ha salido mal y hay que cambiar cosas.

Hacer algo perfecto para no tocarlo jamás. El que itera intenta hacer las cosas lo mejor posible con los recursos que tiene (tiempo y conocimientos) pero también es consciente que en la siguiente iteración puede mejorarlo aún más.

Una iteración que siempre hace lo mismo y no mejora Quiere decir que no se adapta a los cambios y no mejora nada, se llama «rutina». No existe ningún tipo de evolución, acabará siendo un fracaso.

Querer llegar al objetivo de un único salto. Si quiero en una iteración conseguir mi objetivo lo normal es fracasar, porque nunca lo has hecho antes y no conoces lo que necesitas ni tus capacidades para ello. Da pasos y no des saltos.

¿Podría Jcobos haber hecho Velneo V7 si no hubiera hecho 5 veces la plataforma?
¿Podría Nadal ganar al tenis sin haber jugado cientos de miles de partidos?
¿Podría Mou ser tan simpático con los periodistas si no hubiera estado en cientos de ruedas de prensa?
¿Podrían los seres humanos ser una especie tan avanzada si no hubiera evolucionado generación tras generación?

¿Qué es una iteración?

~ davidgu ~ 1 comentario

Últimamente estamos hablando en muchos frentes de esta palabra. Pero realmente no sabemos exactamente que significa y que nos puede aportar. Unas pistas :

En el colegio:
Una iteración es un curso de un año en el que tenemos que recibir clases, tener exámenes, hacer trabajos y cada año va incrementando la dificultad para hacernos personas con más conocimientos.

En los días:
Cada día es una iteración, hacemos básicamente lo mismo ( desayunar, comer, viajar, etc ), pero cada día intentamos hacerlo mejor. Cuando añadimos una cosa nueva que creemos que nos aporta (ir a la piscina) al principio nos cuesta, pero al cabo de un tiempo lo hacemos sin problema y nadamos muy rápido. Si vemos que algo no es bueno, ver mucho la tele, en la siguiente iteración (al siguiente día) lo intentamos reducir o quitar.

En una empresa de software
Cada versión o periodo de tiempo, se hace siempre las mismas cosas ( probar, programar, informar, enviar mails, hacer campañas de marketing, instalar, evaluar, etc ) Con las iteraciones lo que intentamos es hacer siempre lo mismo, un poquito mejor. Quitando lo que ya no vale y añadiendo cosas nuevas que nos ayuden a cumplir nuestro objetivo.
Cada iteración nos cuesta menos hacer las cosas, porque ya las hemos hecho antes y hay poco nuevo que descubrir.

La gestión de iteraciones nos sirve para muchas cosas:

Problema : Quiero adelgazar

  • Opción sin iteraciones : Me hago una dieta puntual.
  • Opción con iteraciones : Intento cambiar algo en mi iteración diaria para que dentro de un año tener mejor figura.

Problema : Quiero que mis compañeros me valoren mejor

  • Opción sin iteraciones : Les invito a cenar.
  • Opción con iteraciones : Hago un feedback cada 6 meses, les escucho e intento ir cambiando esos detalles

Problema : Quiero subir el Everest

  • Opción sin iteraciones : Muero en el campo base 1 por cansancio
  • Opción con iteraciones : Subo montañas de 2.000 metros, luego de 3.000 metros, luego 5.000 metros, luego de 7.000 y luego subo al Everest

La gestión por iteraciones no sólo nos ayuda a conseguir nuestro objetivo, sino a ir adaptándonos a los cambios ( los nuestros, los del entorno y a los del objetivo ) a lo largo del tiempo.

Como describir adecuadamente una incidencia a un desarrollador

~ davidgu ~ 2 comentarios

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 Juan esta es una parte crítica en la que nos transmite constantemente que tenemos que tener 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, esta feo, es pequeño, no me gusta ), trata de ser conciso y describir

  • 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 abrilo

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
http://developer.apple.com/bugreporter/bugbestpractices.html
http://developer.skype.com/SkypeGarage/ReportIssue

¿Por qué los viernes y los lunes no son buenos días para hacer cosas importantes?

~ davidgu ~ 1 comentario

Generalmente para hacer algo importante y delicado, se necesita mucha concentración y mucho tiempo a posteriori por si aparece algún problema.

Si queremos tener garantía de que algo salga mal lo que debemos hacer es

  • Hacer las cosas con prisas
  • Ponerlo a funcionar y marcharme corriendo
  • Hacer las cosas sin estar plenamente concentrado
  • Estar cada uno del equipo a distintas guerras

Los viernes suele ser ese día en que muchas personas ya piensan en el fin de semana y acabar las cosas para que no le quede nada pendiente, la prioridad es acabar la semana y descansar mentalmente el fin de semana. Día de acabar

El lunes es el día en que tenemos que resituarnos, preparar la semana, contar a los compañeros las aventuras del fin de semana y empezar con energía la semana. Día de organizarse

El resto de días de la semana, prácticamente sabemos lo que tenemos que hacer, estamos situados, orientados y con ganas de hacer las cosas bien. No hay problema echarle más horas a un tema para que quede perfecto, siempre tenemos más días para ajustar tiempos.

Buscando como hace las compañías para sacar productos :

Microsoft
Parches de seguridad – Martes – http://en.wikipedia.org/wiki/Patch_Tuesday

Ubuntu 11.10 – Versión – Jueves 13 Octubre 2011
Ubuntu 11.10 will be published on Jueves, October 13, 2011 for free public download.

Firefox 7.0 – Versión – Martes, 27 septiembre, 2011
Mozilla Firefox Significantly Reduces Memory Use to Make Web Browsing Faster

Google Chrome 15 – Versión – Martes, 25 octubre 2011
Making Chrome even more app-ealing

Mac OS X Lion – Versión – Miércoles 20 de Julio de 2011
OS X Lion ya está a la venta en el Mac App Store

Adobe – Versión – Martes 20 de septiembre de 2011
Adobe Unveils Photoshop Elements 10

QT – Versión – Jueves 29, de septiembre de 2011
Qt Creator 2.3.1 released

Pero si te preguntas, ¿No hay excepciones?
Efectivamente, el lunes y viernes son perfectos para las excepciones, es genial, cuando algo va mal y no puede ser el martes, el miércoles o el jueves, tienes dos días más de comodín!