Alpha's Manifesto

La madriguera de una insignificante figurita blanquinegra.

Consejos de comunicación, parte 2: No eludas la pregunta

Ser conciso y no-ambiguo

Respuesta

¿Les ha pasado esto alguna vez?

Ustedes: Estará listo el reporte para esta tarde?
Alguien más: Lo que pasa es que estuve trabajando durante todo el día ayer en el otro trabajo del que hablamos y se extendió más de lo que esperaba porque los números no concordaban con el estimado original.

Si sienten la insatisfacción de una respuesta inexistente en esa conversación ficticia, sabrán de qué voy a hablar hoy.

(Leer más →)

Bugs con el manejo de fechas

...it's more likely than you think.

Muchos se habrán enterado del problema que tuvo Windows Azure con el día bisiesto del 29 de Febrero de 2012, el famoso leap year bug que causó downtime en la nube por todo el día. En algún momento se dijo que el problema no estaba relacionado con las fechas sino que fue coincidente, pero explicaciones posteriores confirmaron que era un problema de generación de certificados en el día bisiesto. Las razones de por qué se hace y cuáles fueron los problemas están explicados detalladamente en el blog de Azure: Summary of Windows Azure Service Disruption on Feb 29th, 2012.

Alguien preguntó en StackOverflow cómo protegerse de estos problemas. Por supuesto, si a Microsoft le pasa, a cualquiera de nosotros nos puede pasar. Por supuesto, no está del todo claro cómo fue que se generó la fecha inexistente, ni en qué lenguaje y Microsoft no da datos al respecto, pero esta persona aclara que aparentemente en el Framework .NET esto no ocurre.

Hay una respuesta en particular que me gustó enormemente, a pesar de no haber respondido la pregunta. Él habla de un proyecto en el que está embarcado llamado Noda Time, basado en el Joda Time de Java. Esta API resuelve muchos problemas que por lo general ni siquiera conocemos.

Me gustaría transcribir y traducir parte de su post, indicando algunos ejemplos de estos problemas (aunque no te interese la programación puede que encuentres esto muy curioso):

(…)

  • Mapear un horario local a zona horaria no es tan simple como pensarías. Una fecha/hora local puede ocurrir una vez, dos veces (ambigüedad) o ninguna vez (se salta) por transiciones de horarios de verano.
  • Las zonas horarias varían históricamente – más de lo que TimeZoneInfo generalmente quiere revelar, francamente (no soporta una zona horaria cuya idea de “tiempo estándar” cambia durante el tiempo, o que cambia a horario de verano de forma definitiva.)
  • Incluso con la base de datos de zonas horarias, los IDs de zonas horarias no son de fiar. (CLDR se encarga de esto, algo que estoy esperando en soportar en Noda Time eventualmente.)
  • Las representaciones textuales de fechas y horas son una pesadilla, no sólo en términos de su ordenamiento, sino también los separadores de fecha, los separadores de hora, y cosas raras como los nombres de los meses genitivos.
  • El comienzo del día no es siempre medianoche – en Brasil, por ejemplo, el cambio de horario de primavera mueve el reloj de 11.59:59 PM a 1 AM.
  • En algunos casos (bueno, yo conozco uno) una zona horaria puede forzar a que todo un día se salte – El 30 de Diciembre de 2011 no ocurrió en Samoa! Sospecho que muchos programadores pueden ignorar esto, pero…
  • Si vas a usar otro calendario aparte del Gregoriano, sé cuidadoso y asegúrate de saber cómo se va a comportar.

(…)

Soy un zorrinito CST.

Encontrando problemas de performance en SQL

Cuando la respuesta no es obvia

Otro de los foros de Stack Exchange que suelo leer es Database Administrators, en donde, como imaginarán, las preguntas y respuestas rondan sobre bases de datos y tecnologías afines. Cada tanto me encuentro con alguna joyita útil y este fue uno de esos casos.

La pregunta trataba sobre alguien que tenía problemas de performance cuando no se trataba de el acceso a disco ni del consumo de CPU. Muy apropiadamente, la pregunta se llama SQL: What is slowing down INSERTs if not CPU or IO?, y por supuesto, siendo un caso particular puede que no nos sea realmente útil la respuesta. Lo que quiero destacar de esta pregunta es el método de investigación que usaron y las herramientas con las que analizaron la performance interna del motor de base de datos. Puede ser muy revelador para nosotros trabajar con estas herramientas cuando la respuesta no es obvia y los planes de ejecución no son suficientes para detectar problemas de performance.

Soy un zorrinito performante.

Joel Test para programadores

Simpleza autocrítica

Para quienes no conocen el Joel Test, es una prueba muy simple, solo 12 preguntas que nos guían a darnos cuenta si nuestro equipo de desarrollo va por el buen camino o tenemos cosas que arreglar.

De ahí alguien preguntó si había una especie de Joel Test para la evaluación de un programador en particular, especialmente preguntas para hacer en entrevistas y para evaluar a gente de forma individual. Alguien mencionó que se podía trabajar con la Programmer Competency Matrix de IndianGeek, con la que ya he trabajado anteriormente. Aún así, no se ajusta específicamente a todas las características que alguien quisiera medir en un programador.

Al fin y al cabo, las respuestas no fueron muy iluminadoras, usuarios relacionados hicieron una pregunta en Quora sobre qué hay que preguntar a un candidato antes de contratarlo, las respuestas son un poco más interesantes y más allá del tema del entrevistado y la contratación, es interesante como ejercicio preguntarnos esas cosas a nosotros mismos y evaluar las respuestas.

Soy un zorrinito evaluado.

¿Cuántos colores existen?

Seis: Blanco, negro, rojo, verde, azul y amarillo. (?)

Un link interesante que me encontré pregunta ¿Cuántos colores existen? y se presta a una buena cantidad de respuestas.

Alguien respondió desde un punto de vista físico, apropiado a la temática del foro, y su respuesta es que existen ∞ colores, interesante número. Se basa en las propiedades de las frecuencias y su posible combinación. Aunque se discute luego sobre la real aplicación de la longitud de Planck y de la longitud Hubble para aplicar límites, ese número no cambia realmente.

Otro se aproximó más al lado médico, especificando la resolución de los distintos fotoreceptores oculares. En este caso la respuesta sería muy variable, pero aproximándose al billón de colores.

Alguien más introduce la teoría del color y el diagrama McAdam para hablar de una cantidad pequeña, pero no definida, junto con una última, bastante cercana, desmiente las anteriores diciendo que nuestra resolución de distinción de colores es limitada (aunque variable) y que el espectro visible es también limitado, lo que significa que lejos de ser infinito, es también una cantidad bastante pequeña.

Soy un zorrinito decolorado.

Cómo uso Trello para trabajar

Mi guía novata a la organización

Hace un tiempo ya, y realmente, el día que salió, yo ya tenía una cuenta de Trello. Era simple, era bonito, era rápido, pero no veía el gran poder que tenía. Es porque, como muchas cosas, hay que saber utilizarlas.

Hoy es para mi una herramienta fundamental en mi organización (personal y laboral) y me ha vuelto más productivo y ha evitado muchos de esos momentos de “¿y ahora qué?” o “¿en qué estaba?“. Voy a compartirles el como para que sepan cómo lo hago yo, y espero comentarios de cómo lo hacen ustedes. Hasta que arregle los comentarios del blog, pueden responderme a @AlphaTwi, y si quieren expresarse un poco más, pueden enviarme un mail a alpha@furries.com.ar.

Trello por default

Trello se compone de boards (pizarras) que a su vez se componen lists (listas), que a su vez contienen cards (tarjetas).

Cuando crean un board por primera vez, verán esto como su contenido.

Trello default lists

(Puede que se vea distinto si su resolución de pantalla es menor, en ese caso pasará al modo mobile.)

El flujo ya es bastante apropiado en la forma en la que se presenta, y es ideal para grandes grupos de gente (ah, es multiusuario). Básicamente, las cosas se van dando de alta en la lista To Do, al momento en que comienzan a trabajarse, se mueven a Doing, y al momento de terminarlas se pasan a Done.

Preguntas respondidas

La simple disposición de tareas de esta forma ayuda a responder muchas preguntas.

Cuando las cosas están en To Do es porque es importante ver cuáles son todas las cosas pendientes. Responde preguntas como “terminaremos para hoy/mañana?” o “cuando termines con esto estás libre?“.

La lista de Doing ayuda a ver qué progreso se está haciendo. Responde preguntas como “En qué está trabajando José?” o “Qué estaba haciendo yo?” (especialmente útil para los que lidian mucho con interrupciones).

La lista de Done ayuda a ver qué se terminó. ¿Qué sentido tiene esa lista? Ayuda a responder preguntas como “¿Qué porcentaje de tareas terminamos?“, “¿Avanzamos mucho?“, “¿Qué está presente en esta versión?“.

Mi variante: el día a día

Mis cambios a ese esquema por default no han sido radicalmente distintos, pero lo suficiente como para mencionar. Este es el caso de mi trabajo, tengo distintos esquemas para distintos tipos de proyectos personales (y creo que esa es una de las cosas que hace a esta herramienta tán versátil). Estas son mis listas y para qué se usan:

To Do: Igual que siempre este es el listado de todo lo que se tiene que hacer, o que algún día tiene que ser resuelto. Puede ser mañana, puede ser la semana entrante, puede ser “algún día” indefinido.

Get Done Today: Al principio del día, luego de checkear mis correos y verificar qué cosas tengo pendientes que no sabía antes, elijo desde To Do un listado de ítems que obligatoriamente tengo que terminar el día de hoy. Puede basarse en prioridad, en tiempo disponible, en urgencias, en la dirección del viento. La forma de elegirlas no importa, lo que importa es que esas tareas son mi compromiso del día. Me sirve también para reportar en nuestra scrum meeting qué es lo que voy a estar haciendo.

Doing right now: Como su nombre lo dice, el listado de cosas que estoy haciendo ahora mismo. Si no tengo nada acá, probablemente esté almorzando. Si tengo más de tres tarjetas aquí, seguramente algo saldrá mal. Cuando me llaman por teléfono, me buscan en la oficina o me interrumpe un email, este es el lugar al que vuelvo a mirar y resumo mis tareas.

Waiting for feedback: Este es el listado de cosas que comencé pero estoy bloqueado y requiero que alguien más intervenga. Es porque la tarea depende de alguien más o porque estoy esperando respuesta de alguien para poder continuar. Siempre les agrego un comentario a esas tarjetas para poder leer cuál fue la última vez que la actualicé y para saber qué estoy esperando que me respondan o hagan. Puede que una vez que me respondan las tarjetas se muevan de aquí a To Do, o, si tengo suerte, a Done.

Done: Nuevamente, aquí es donde vienen a morir las cosas que ya hice. Mantengo este listado hasta el fin del día, en donde lleno mis timesheets (mi empresa requiere que llene un listado de qué actividades realicé cada día). Las tarjetas me ayudan a recordar, y el tener que limpiar esa lista me hace recordar llenar el timesheet.

Este es un ejemplo con mi día de hoy (exitosamente cerrando la semana):

My Work Today in Trello

Probablemente lean mis ítems y no entiendan en qué estoy trabajando, porque los títulos no son muy explicativos. Ese es otro beneficio: no tienen que serlo. Sólo tienen que decir lo suficiente como para que yo recuerde de qué se trataba todo. Si necesito más detalles uso los comentarios o las descripciones de las tarjetas (que, dicho sea de paso, soporta Markdown). Si necesito varios puntos intermedios agrego una checklist (como el primer item en la imagen), y es todo a gusto.

Espero que esto haya sido útil para quién lo lea. Si tienen sugerencias, estoy encantado de oírlas, sería muy útil para mi también aprender de alguien que sepa organizarse mejor.

Soy un zorrinito organizado.