November 2008 - Artículos

spamEl correo electrónico es una de las herramientas más importantes de trabajo, todos tenemos un cliente de correo que chequeamos varias veces al día ya sea en nuestro trabajo o en nuestros hogares. Es tanto un medio de comunicación como un sistema para recibir alertas y recordatorios, todos los sistemas se comunican con nosotros mediante correo electrónico, "se te ha asignado un nuevo ticket", "quedan 3 días para renovar las licencias", "inscríbete para el curso de seguridad", "tienen una reunión en media hora", y otros muchos mensajes nos ordenan y recuerdan las tareas que debemos realizar.

Esto crea tal dependencia que en mi primer empleo, en que desarrollaba un CRM, verifiqué una hipótesis muy lógica: cuando no hay correo electrónico el trabajo simplemente no se realiza.

Es claro, el costo de recorrer todos los sistemas con el fin de verificar si tengo algo que hacer con ellos es enorme, las reuniones simplemente desaparecen, la comunicación con los equipos de otros países vuelve a ser como a principios de siglo. Que el servicio de correo no esté disponible hace que la gente se comporte como si le hubiesen cortado la electricidad, no trabajan y no porque no tengan voluntad sino porque el sistema motor se ha apagado.

Por lo tanto, uno puede hacer el siguiente razonamiento: email=bueno => (no email)=(no bueno). La verdad es algo distinta, existe otro tipo de parálisis que se presenta por exceso de email y eso me sucede todos los días. Lo explico.

En mi trabajo recibo entre 20 y 30 email diarios (algo menos los sábados y los domingos), cuando no estoy vinculado a ningún proyecto, número que ha llegado a ascender hasta los 60 emails en mi ante último proyecto. Esto representa algo así como un mail cada 8 minutos.
Pero de donde salen tantos emails!? Son emails institucionales del estilo:

  • no hay aire acondicionado en el 7mo piso.
  • el server unixXXXX será retirado.
  • conflictos políticos en Bolivia, estén alerta si necesitan viajar
  • nuevos productos
  • nuevas políticas
  • nuevos managers o cambios de posiciones
  • posiciones abiertas
  • cumpleaños
  • millones de marketing
  • opciones de compra de acciones
  • ventanas de mantenimientos
  • reuniones
  • trainings
  • que cargues las horas
  • que el equipo de ayuda a la comunidad no sé que cosa quiere
  • las invitaciones a las revisiones de proyectos
  • los blogs de los managers a los que uno está forzado a sindicarse
  • miles de recursos humanos
  • las subastas internas
  • cambios en la obra social
  • y millones de etcéteras que asombrarían hasta a los xmen.

Ahora, cuando estoy en un proyecto, a estos se le suman varios tipos de emails más por lo que la interrupción es constante y la única manera de poder trabajar es no abriendo el outlook. Esto, que a priori resulta una solución, se convierte en una pesadilla al día siguiente en donde uno puede encontrarse con una cantidad de correo verdaderamente apabullante. Por lo que muchos optan por perder algunas horas creando toda clase de filtros, digo algunas horas porque la variedad de fuentes es enorme. Otra cosa espantosa es que a medida que transcurre uno por distintos proyectos, va haciéndose merecedor de nuevos emails que no dejan de llegar una vez que se abandona ese proyecto, por esta razón la creación de filtros no se hace solo una vez.

Pero esta tampoco es una solución muy feliz, es demasiado común reunirse a conversar y que la mitad de los participantes no tengan ni la menor idea de lo que se está hablando simplemente porque "todos esos mail van directo a la papelera". Otro efecto interesante es el de "sí, lo vi pero no lo leí bien", esto no es de gente floja sino que se produce un hábito de leerlos a medias o entre lineas.

Si bien los generadores de mail son en su inmensa mayoría las herramientas de desarrollo, recursos humanos, marketing, los managers de todos los niveles y las áreas de soporte, algunos lideres de proyectos también tienen su lugarcito en esta locura, claro que estos emails suelen estar mucho más relacionados al proyecto que el resto, pero aún así son email que no siempre se leen como debieran, cosa que produce el enojo de muchos productores.

El tema es que muchas personas parecen llevarse bastante bien con esta situación mientras que otras realmente lo sufren. Por lo general uno puede distinguir entre los productores de este spam y los receptores, los productores ya los mencioné pero de entre los receptores, que en principio somos todos, quiero resaltar a los desarrolladores. El problema es que si bien los desarrolladores solemos ser quejumbrosos por naturaleza, esta vez tenemos una justa razón para hacerlos: necesitamos concentrarnos! Es como tratar de resolver una ecuación diferencial en una habitación plagada de mosquitos hambrientos.

Hay una frasecita que escucho casi a diario cuando se aborda este tema: "es que, en algún momento tenemos que trabajar". Comparto. Esto es confesión de improductividad por emails.

Lucas Ontivero.

KeyPadawanEsta es la segunda entrega de Key Padawan. Próximamente escribiré sobre los detalles de esta herramienta ya que tiene algunas cosas interesantes pero todavía no es el momento porque todavía es una gran BETA. 

El cambio de la versión anterior se debe a que mientras lo usaba me estorbaba mucho. Otra cosa es que no funcionaba bien en teclados en ingles (Esta versión funciona mejor aunque no maneja bien el layout del teclado de mi notebook).

Como lo muestra el GIF animado, esta versión tiene una pequeña área de visualización que es transparente, se oculta automáticamente, se puede mover, se puede redimensionar, puede estar siempre visible y posee un trayicon y un menú con opciones básicas.

Bueno, espero que sea de utilidad.

Saludos.

 

Lucas Ontivero

He terminado de leer este libro de Terence Parr, The Definitive ANTLR Reference - Building Domain Specific Languages, y es realmente excelente si estas interesado en compiladores,

interpretes, analizadores de código, generadores de código y otras cosillas.

 

El libro trata sobre la versión 3.0 de Antlr y tiene toda la forma de un manual de referencia en el cual van presentandose temas y ejemplos de implementaciones de lenguajes. Por último desarrolla todo un compilador para un lenguaje de ejemplo.

 

En breve volveré sobre este tema que me encanta.

Saludos.

 Lucas Ontivero

Pregunta al experto y la UTN-FRC te invitan al Primer Fish Bowl  en Córdoba

Cuando y donde: UTN Regional Córdoba, Salón de Actos, Miércoles 12 de Noviembre a partir de las 18:30hs.

 

Trasfondo

En mi ciudad, Córdoba-Argentina, se viene observando cada vez más que en las charlas conferencias sobre tecnología la cantidad de asistentes disminuye progresivamente. En mi opinión, la cual comparto con algunos amigos, esto se debe a que mucha gente, por diversos motivos, va perdiendo o ha perdido el tren de la tecnología o al menos este los va superando y apabullando en su vorágine. Otra causa posible es que la diversidad y puntualidad de los temas que se presentan hace que el público objetivo sea naturalmente pequeño, aún más si se trata de presentaciones de productos y más todavía si esos productos están en beta o por salir al mercado y no presentan una solución real al momento ni tiene aplicación inmediata.

Pero hay más, las presentaciones son justamente eso, comunicación unidireccional, una persona que habla y otros muchos que son meros receptores que no eligieron la temática sobre la que quieren escuchar sino que asisten a presenciar "lo que hay".

Por este motivo, este Miércoles 12 de Noviembre a las 18:30 hs se realizará en la UTN-FRC el primer FishBowl.

Para quienes no conozcan esta modalidad les comento un poco de qué se trata:

 

El inicio

En el inicio del evento se plantean las bases del mismo. Esto para que las personas que no conocen o no saben de la modalidad puedan ponerse al tanto. Después de esos 15 minutos introductorios, los asistentes deben dirigirse a un pizarrón, o tablón, que contiene una grilla de vacantes y horarios. O sea, algo similar a esto:


Evento 1 Evento 2 Evento 3
Hora 1


Hora 2


En esa grilla, cada persona asistente puede proponer un tema. Cada tema propuesto compite con otros en el caso de que existan más temas que los horarios y vacantes posibles. Los demás asistentes votan, si así lo desean, por alguno de los temas ya propuestos o simplemente proponen aquellos temas que les interesan.

Al finalizar esa etapa las charlas con mayores votaciones son las que se llevan a cabo.

 

La interacción

La idea general es que, en cada charla se colocan 4 sillas. Cada persona que quiere opinar sobre el tema en cuestión debe sentarse en una de las sillas y solo recién emitir su opinión. Siempre debe quedar una silla disponible (para que se siente quien quiere opinar). Si las 4 estuvieran ocupadas, la persona que ya no tiene más que decir, o que ha estado más tiempo, o aquella que simplemente tiene la voluntad de pararse y volver a la "zona" de escuchas lo hace.

Los asistentes pueden ir pasando por diferentes grupos, y no necesariamente deben quedarse en una charla, o en la charla inicialmente elegida. La persona que propuso el tema de la charla es la que inicia la misma, y al mismo tiempo puede o debería, preferentemente, actuar como moderador.

Hay que destacar que no es necesario conocer un tema para proponerlo. Puede, por ejemplo, proponerse un tema del cual una persona quisiera obtener conocimientos ya que es posible que dentro de los asistentes se encuentren personas que sepan del mismo.

En esta oportunidad, cada charla debería tomar alrededor de 45 minutos. Si el mismo se agota antes de tiempo, este se disuelve y las personas pueden ir a observar o participar de otras charlas. Es posible llevar computadoras, y mostrar código y/o presentaciones, bajo la idea de que los asistentes deberán asomarse a la pantalla y tratar de ver algo.

Si se cuenta con algún medio de proyección, también es posible usarlo, aunque esto dependerá directamente de las instalaciones. Que temas tratar: Los temas son de informática, y no necesariamente de código. Tampoco están relacionados a una empresa, industria, propietario o modalidades de distribución. Simplemente es informática. Se podría hablar de generación automática de código, software factories, test unitarios, análisis estático de código, cloud computing, pair programming vs. revision de código, test automation, herramientas de productividad, estimaciones, secure programming, XSS y SQL injection, domain specific languages, CMMi vs Agile, store procedures vs SQL inline, web client vs smart clients, lenguajes funcionales, hasta XNA o el mercado del desarrollo de juegos, o lo que sea.

 

Lucas Ontivero