Depura el envió de correos con "smtp4dev" [HERRAMIENTA]

Casi siempre que se hacen aplicaciones web, surge la necesidad de notificar al usuario por correo sobre algún suceso, ya sea registro, suscripción u otro. Así que como developer, siempre nos vemos en la necesitad de probar código para enviar correo. La practica nos enseña que no hay que esperar hasta último momento (ya en producción) para probar el envió de correos, pero usualmente probar estas funcionalidades es un dolor de cabeza, especialmente en Windows (¿quien ya ha configurado un servidor smtp en Windows?).

Pues para aliviar esta carga, les quiero compartir esta sencilla herramienta, que francamente me salvo la vida muchísimas veces para probar envíos de correo, se llama "smtp4dev".
Realmente no hay mucho que ver o explicar, smtp4dev es un sencillo programa que se aloja en el taskbar y escucha el puerto 25, por cualquier correo entrante.

"Bandeja de entrada de smtp4dev"

Entonces si usas Java Mail o la funcion mail() de PHP para enviar un correo, smtp4dev lo recibe y te despliega una notificación de recibido, el correo "recibido" lo pueden abrir con Thunderbird o Outlook sin mayor problema.

"Notificación de correo entrante"

Simple, funcional y open source ¿qué más se puede pedir?, pueden descargar smtp4dev acá:

http://smtp4dev.codeplex.com/

Espero que les sirva, tanto como me ha servido (y lo sigue haciendo!)
Saludos!

Ser o no ser... jefe?

"Imagen ligeramente inspirada en hechos reales xD"

"¿Cómo se proyecta usted en su futuro de acá a diez años?" preguntó la encargada de recursos humanos que se encargó de hacerme la entrevista laboral. "Como coordinador de equipos de desarrollo o subgerente de IT" fue mi respuesta, sabiendo que la evolución lógica de un programador es a convertirse en jefe de equipos de desarrollo o subgerente y eso además me hacía ver visionario y con metas propuestas. Desde entonces esa había sido mi meta personal o mi aspiración para mi próximo puesto de trabajo una vez ganada experiencia y de ser posible mayores grados académicos. Hoy en día me pongo a pensar ¿es eso lo que realmente quiero hacer dentro de diez años?

Según mi experiencia hasta la fecha, cuando se trabaja en IT, a diferencia de otros puestos de trabajo dentro de una empresa, no se cuenta con muchos puestos de trabajo a los que uno puede aspirar si uno se encuentra en el primer escalón (programador, analista de QA, técnico de redes, sysadmin, etc). Mas bien, en la mayoría de los casos solo se cuenta con una línea vertical de puestos de trabajo a los que se puede aspirar y esa es, la del jefe directo de cada uno.

Sabiendo que lo más probable es que nuestro próximo puesto de trabajo al cual aspirar es al de jefe de equipos de IT (llámese coordinador, arquitecto de software, manager, subgerente o gerente), ¿es realmente ese el puesto al que queremos aspirar?

Sin pensarlo podríamos decir que si, ya que este nuevo puesto conlleva a nuevas responsabilidades, un aumento de autoridad y un mejor salario y mejores prestaciones laborales pero recientemente caí en la cuenta que al ser promovido a un puesto más administrativo te alejas del área que te apasiona, que te ha causado esa satisfacción que experimentas cada día que regresas del trabajo.

En IT se experimenta un extraño sentimiento de pasión por lo que se hace, es como si lo hicieramos mas por satisfacción personal que por un salario y el salario fuera mas un bonus o un medidor de reputación. La gran cantidad de proyectos Open Source son prueba de ello y la cantidad de programadores jubilados que siguen desarrollando sistemas por simple pasatiempo.

Un amigo me explicó hace unos días que, aunque se podría pensar que la evolución natural en el ámbito laboral es aspirar al puesto de trabajo del jefe inmediato, no todas las personas poseen las aptitudes y actitudes para ejercer las labores administrativas de un puesto de esta naturaleza por más experiencia y conocimiento que tengan y aun si las tuvieran, carecen del deseo para esta aspiración o solamente lo hacen por la pura necesidad de un aumento salarial o porque a los de recursos humanos no tienen idea de otro tipo de incentivo que compense los años laborales que un empleado brinda a la empresa.

Es obvio entonces que necesitamos recibir incentivos que compensen la trayectoria de un trabajador en un puesto de trabajo y se supone que una promoción a un puesto administrativo es el incentivo natural pero deberían haber alternativas a esto si la persona no está capacidada o no posee el deseo de aspirar a un puesto superior.

En lo personal no me considero capacitado (aún) para desarrollar las funciones administrativas relacionadas con el siguiente escalón en mi jerarquía de puestos de trabajo y a sabiendas que estando en ese puesto probablemente no sentiré la misma satisfacción que siento al programar me he quedado pensando en este dilema en el cual debo decidir si seguir con la corriente de aspirar al siguiente escalón o quedarme con lo que me apasiona buscando incentivos alternativos que lo compensen. Por el momento pienso seguir la corriente e investigar cuan satisfactorio es el siguiente escalón en el sentido personal y profesional.

¿Aspiran ustedes a obtener el puesto de sus jefes en un futuro?

Una Imagen Vale Mas Que Mil Líneas de Código

Esta semana charlando con un colega de trabajo aprendí una importante lección sobre porqué unos programadores triunfan más que otros. Es cierto que existen muchos factores importantes para lograr un empleo decente como programador, ejemplo de ello son la experiencia, habilidad, conocimiento y persistencia pero hay un punto que he comprobado lo decisivo que puede ser para lograr el éxito: tu imagen profesional.

Él mismo me comentaba: "Yo no soy tan buen programador como X o Y pero sé muy bien como venderme ante mi jefe y eso me ha valido mas que mis habilidades". Comprendí que puedes ser el mejor programador pero si tu jefe no se da cuenta de ello, muchas veces tus esfuerzos son en vano o son aprovechados por otros más astutos.

A raíz de esta interesante charla elaboré las siguientes conclusiones:

Apropiarse de los sistemas que has desarrollado. Programaste un CRM tan user friendly que a los usuarios se les sube el autoestima al utilizarlo. Resolviste un bug de antaño en una aplicación que reduce significativamente sus tiempos de uso. Entregaste tus desarrollos con el tiempo suficiente para que e proyecto no saliera en rojo. Los usuarios están eufóricos porque dejaste sudor y lágrimas con tal de dejar hermoso ese sistema pero acaso ellos saben quien lo desarrolló? Quizá te estés perdiendo de muchas ovaciones porque nadie sabe que tu desarrollaste ese maravilloso sistema. Es importante apropiarse de lo que desarrollas. Así, aparte de recibir ovaciones si lo dejaste reluciente, sabrán a quién llamar cuando falle o requieran un cambio, lo cual visto desde el punto de vista positivo, te convierte en alguien fundamental para que dichos sistemas funcionen. Basta a veces con dejar tu autoría en el código fuente (ojo, no es lo mismo que aplicar copyrigths al código).

Evitar la apatía y el comportamiento antisocial. En los lugares de trabajo suelen existir grandes programadores, excelentes para encontrar bugs en horas, bugs que a todos los demás nos hubiera tomado semanas, grandes conocedores del lenguaje en el que programan pero a veces tienen un pequeño problema: los jefes no se dan cuenta de sus habilidades y su esfuerzo.Porque? porque llegan temprano, se sientan en su computadora, se encierran en su mundo y no escuchan más que a música que sale de sus audífonos, sin hablar con nadie mas. Almuerzan solos, nunca asisten a los eventos de convivencia ni se postulan como voluntarios para actividades extra laborales. Hacen su trabajo, lo hacen muy bien, sí, pero no hacen nada más que eso y poseen un comportamiento antisocial. Los charlistas y expositores motivacionales de hoy en día nos viven diciendo que hay que aprovechar la inteligencia emocional. Las emociones y el comportamiento del indivíduo son fundamentales para demostrar nuestra capacidad laboral. Es momento de escucharlos y aplicar sus consejos.

Exhibir tus logros y tu esfuerzo ante tu jefe. Quizá descubriste un bug antíguo en un programa que te tocó refactorizar y arreglar esto te tomó más tiempo que el estimado en tu plan de trabajo. Quizá hasta tuviste que quedarte horas extra o llegar los fines de semana con tal de cumplir con las fechas y al final nadie te dio ni siquiera un estimulante "gracias". Seguramente ni siquiera se dieron cuenta de tu sacrificio porque quizás ni siquiera les notificaste de ello. Es bueno siempre mantener informado a los superiores de los imprevistos pero no como "jefe, tenemos un problema" sino algo que suene mucho mejor y suene en beneficio de tu imagen, por ejemplo "jefe, ocurrió una catástrofe con el proyecto que hubiera impactado en las fechas de no ser porque con esfuerzo lo resolví durante el fin de semana...".

Considerar hacia dónde apuntar tu imagen. Pueda que seas el programador más respetado de las comunidades web de programadores locales pero seguramente tu jefe es un old-school a quien no le interesa qué tan famoso y respetado seas en la web y en tu lugar de trabajo nadie te conozca o a tus habilidades. Es importante que tu imagen brille donde más te convenga que lo haga. Si eres empleado, dala a conocer a tus colegas y superiores.

Darse a conocer sin perder la humildad. Todo se demuestra de mejor manera con hechos antes que con palabras. La iniciativa, la disposición para ayudar y la solidaridad son buenas herramientas.

Cabe mencionar que la recompensa de vender tu imagen no se verá de la noche a la mañana y a veces, si se tiene mala fortuna, el jefe no se interese en valorar y compensar a los mejores en su equipo pero la clave está en perseverar y si no basta con esto, buscar otro lugar donde sí valoren tu imagen como profesional.

Una Imagen Vale Mas Que Mil Líneas de Código

Esta semana charlando con un colega de trabajo aprendí una importante lección sobre porqué unos programadores triunfan más que otros. Es cierto que existen muchos factores importantes para lograr un empleo decente como programador, ejemplo de ello son la experiencia, habilidad, conocimiento y persistencia pero hay un punto que he comprobado lo decisivo que puede ser para lograr el éxito: tu imagen profesional.

Él mismo me comentaba: "Yo no soy tan buen programador como X o Y pero sé muy bien como venderme ante mi jefe y eso me ha valido mas que mis habilidades". Comprendí que puedes ser el mejor programador pero si tu jefe no se da cuenta de ello, muchas veces tus esfuerzos son en vano o son aprovechados por otros más astutos.

A raíz de esta interesante charla elaboré las siguientes conclusiones:

Apropiarse de los sistemas que has desarrollado. Programaste un CRM tan user friendly que a los usuarios se les sube el autoestima al utilizarlo. Resolviste un bug de antaño en una aplicación que reduce significativamente sus tiempos de uso. Entregaste tus desarrollos con el tiempo suficiente para que e proyecto no saliera en rojo. Los usuarios están eufóricos porque dejaste sudor y lágrimas con tal de dejar hermoso ese sistema pero acaso ellos saben quien lo desarrolló? Quizá te estés perdiendo de muchas ovaciones porque nadie sabe que tu desarrollaste ese maravilloso sistema. Es importante apropiarse de lo que desarrollas. Así, aparte de recibir ovaciones si lo dejaste reluciente, sabrán a quién llamar cuando falle o requieran un cambio, lo cual visto desde el punto de vista positivo, te convierte en alguien fundamental para que dichos sistemas funcionen. Basta a veces con dejar tu autoría en el código fuente (ojo, no es lo mismo que aplicar copyrigths al código).

Evitar la apatía y el comportamiento antisocial. En los lugares de trabajo suelen existir grandes programadores, excelentes para encontrar bugs en horas, bugs que a todos los demás nos hubiera tomado semanas, grandes conocedores del lenguaje en el que programan pero a veces tienen un pequeño problema: los jefes no se dan cuenta de sus habilidades y su esfuerzo.Porque? porque llegan temprano, se sientan en su computadora, se encierran en su mundo y no escuchan más que a música que sale de sus audífonos, sin hablar con nadie mas. Almuerzan solos, nunca asisten a los eventos de convivencia ni se postulan como voluntarios para actividades extra laborales. Hacen su trabajo, lo hacen muy bien, sí, pero no hacen nada más que eso y poseen un comportamiento antisocial. Los charlistas y expositores motivacionales de hoy en día nos viven diciendo que hay que aprovechar la inteligencia emocional. Las emociones y el comportamiento del indivíduo son fundamentales para demostrar nuestra capacidad laboral. Es momento de escucharlos y aplicar sus consejos.

Exhibir tus logros y tu esfuerzo ante tu jefe. Quizá descubriste un bug antíguo en un programa que te tocó refactorizar y arreglar esto te tomó más tiempo que el estimado en tu plan de trabajo. Quizá hasta tuviste que quedarte horas extra o llegar los fines de semana con tal de cumplir con las fechas y al final nadie te dio ni siquiera un estimulante "gracias". Seguramente ni siquiera se dieron cuenta de tu sacrificio porque quizás ni siquiera les notificaste de ello. Es bueno siempre mantener informado a los superiores de los imprevistos pero no como "jefe, tenemos un problema" sino algo que suene mucho mejor y suene en beneficio de tu imagen, por ejemplo "jefe, ocurrió una catástrofe con el proyecto que hubiera impactado en las fechas de no ser porque con esfuerzo lo resolví durante el fin de semana...".

Considerar hacia dónde apuntar tu imagen. Pueda que seas el programador más respetado de las comunidades web de programadores locales pero seguramente tu jefe es un old-school a quien no le interesa qué tan famoso y respetado seas en la web y en tu lugar de trabajo nadie te conozca o a tus habilidades. Es importante que tu imagen brille donde más te convenga que lo haga. Si eres empleado, dala a conocer a tus colegas y superiores.

Darse a conocer sin perder la humildad. Todo se demuestra de mejor manera con hechos antes que con palabras. La iniciativa, la disposición para ayudar y la solidaridad son buenas herramientas.

Cabe mencionar que la recompensa de vender tu imagen no se verá de la noche a la mañana y a veces, si se tiene mala fortuna, el jefe no se interese en valorar y compensar a los mejores en su equipo pero la clave está en perseverar y si no basta con esto, buscar otro lugar donde sí valoren tu imagen como profesional.

Feliz día del programador ( y 7 preguntas frecuentes )

¡Ayer fue el día del programador, felicidades a todos los que practican esta interesante profesión!.

Inspirado por este artículo, y recordando platicas con varios compañeros a lo largo de los años, redacte esta entrada con las preguntas más frecuentes con las que me he encontrado con respecto a esta profesión que me da de comer. Espero que les guste, y si tienen alguna otra que agregar o sugerencias, son más que bienvenidas:

1. ¿Programar es para todos?
No. Definitivamente no. Así como la gente que se desmaya viendo sangre y no se puede dedicar a asistir en una cirugía o en Emergencias, sucede lo mismo a la hora de programar. Programar no solo es aprender un lenguaje de memoria, y sentarse a digitar todo el día hasta que las cosas sirvan.

"Un programador (el buen programador) diseña con creatividad, la mejor lógica de la abstracción de la información para producir resultados útiles."

Y sobre todo, no pierde el tiempo re-escribiendo código. Un programador, es un individuo apasionado por resolver problemas, para hacer mejorar el diario vivir de los usuarios. Suele ser autodidacta, y no espera a que alguien más resuelva sus problemas, el procura resolverlos todos.

2. ¿Programar es una habilidad?
Si, tal como aprender a dibujar bien, o hablar en publico, programar es una habilidad, y como tal, requiere tiempo y dedicación para que alguien sea considerado un "maestro". Quizás no tengas la "habilidad natural" para programar (y no todos la tenemos), pero es valido recordar aquella frase que dice:

"Practice makes perfect" / "La practica hace al maestro".

 Si a ti te cuesta, pero te gusta o te apasiona, no dudes en practicar, leer, estudiar y practicar más, para llegar al nivel que deseas. Y no se olvide tampoco, de que las cosas buenas toman TIEMPO.

Lea, investigue, aprenda, y no deje de hacerlo.

3. ¿Cual es la actitud del programador?
La actitud correcta del programador, es "agarrar el toro por los cuernos". Es despedazar problemas, es simplificar procesos, es superar retos. Si eres un programador que se queja constantemente, esa actitud se vera reflejada en el código que escribas. Por eso es tan importante que un programador sea una persona feliz, tranquila, con ánimos de superación, positivo.

Quiero esta camisa :)

Escribir código es como escribir cuentos, y si el autor esta triste y escribe en ese estado, seguramente los cuentos serán un reflejo de los sentimientos del autor. Si usted se queja por el IDE, el OS, el compilador, así será el código que produce... esto yo he cometido ese error, y lo mejor que pude hacer fué cambiar de actitud, para no escribir código "lleno de quejas".

4. ¿Entiende los conceptos avanzados de la programación?
Ya sea con programación funcional u orientada a objetos, usted debe comprender los conceptos y los tecnicismos asociados a su estilo de programación favorito.
Estos conceptos ayudan a pensar "outside the box", y te ahorran trabajo (como los patrones de diseño).

Si tienes dificultad con los conceptos, lo mejor es "agarrarlo al suave" y aprender un paso a la vez, como los bebes cuando aprenden a caminar, un pasito a la vez.
Lea, pregunte, investigue, y practique con ejemplos hasta que domine el concepto por completo. Porque si no comprendes lo basico, ¿cómo vas a comprender lo avanzado?

5. ¿Qué recursos ocupa un programador en Internet?
Se los resumo en tres recursos que uso casi constantemente:

• Google para buscar códigos de errores, y entender cuando surge un tipo especifico de "Exception".
• Wikipedia para leer sobre leyes, teorías, conceptos.
• StackOverflow para hacer las preguntas difíciles y también las preguntas tontas :)
• La documentación del lenguaje que este usando, también le será muy útil, y las listas de correo, grupos y comunidades que se desarrollan alrededor.

StackOverflow.com

6. ¿Diseñar antes de programar?
Como Informatico, en algun momento nos enseñan la importancia de diseñar, y en otro momento caemos en la practica de codificar mientras se avanza (code as you go). Se necesita un balance entre diseñar el software, y el deseo de ponerse manos a la obra. Tenga al menos la idea de que va a hacer antes de sentarse a programar, piense y elabore un algoritmo, o un pequeño caso de uso, o un diagrama de ER, y le aseguro que va a terminar lo que tiene pensado hacer.

Un buen diseño, es hermoso.

Lo importante es no entrar en ese circulo vicioso de desesperación, aburrimiento, y cansancio tipico de los proyectos de software que no se diseñan con anticipacion. Al diseñar, se evita perder la direccion (resolver un problema), y se vuelve más facil el desarrollo (y la depuracion) del software.

7. ¿Cómo maneja un programador con el estrés?

Run!

Bueno, depende del individuo, muchos juegan o #Beben , y otros hacen ejercicio. El estres en este medio es bastante común, y se debe a varios factores, tanto internos como externos al programador. Lo mejor, suele ser encontrar un hobby totalmente diferente a la programación, y que de preferencia te aleje de la computadora. Practicar un deporte, dibujar o tocar un instrumento musical suelen ser excelentes formas de lidear con el estres asociado con la práctica.
Y claro, un cambio de actitud ayuda mucho también.

Muchas felicidades programadores, gracias a los que trabajan en los bancos, a los que contribuyen en el mundo del software libre, a los que enseñan sin recelo lo que aprenden, gracias a todos, porque nos hacen la vida más facil. ¡Saludos colegas!

Feliz día del programador ( y 7 preguntas frecuentes )

¡Ayer fue el día del programador, felicidades a todos los que practican esta interesante profesión!.

Inspirado por este artículo, y recordando platicas con varios compañeros a lo largo de los años, redacte esta entrada con las preguntas más frecuentes con las que me he encontrado con respecto a esta profesión que me da de comer. Espero que les guste, y si tienen alguna otra que agregar o sugerencias, son más que bienvenidas:

1. ¿Programar es para todos?
No. Definitivamente no. Así como la gente que se desmaya viendo sangre y no se puede dedicar a asistir en una cirugía o en Emergencias, sucede lo mismo a la hora de programar. Programar no solo es aprender un lenguaje de memoria, y sentarse a digitar todo el día hasta que las cosas sirvan.

"Un programador (el buen programador) diseña con creatividad, la mejor lógica de la abstracción de la información para producir resultados útiles."

Y sobre todo, no pierde el tiempo re-escribiendo código. Un programador, es un individuo apasionado por resolver problemas, para hacer mejorar el diario vivir de los usuarios. Suele ser autodidacta, y no espera a que alguien más resuelva sus problemas, el procura resolverlos todos.

2. ¿Programar es una habilidad?
Si, tal como aprender a dibujar bien, o hablar en publico, programar es una habilidad, y como tal, requiere tiempo y dedicación para que alguien sea considerado un "maestro". Quizás no tengas la "habilidad natural" para programar (y no todos la tenemos), pero es valido recordar aquella frase que dice:

"Practice makes perfect" / "La practica hace al maestro".

 Si a ti te cuesta, pero te gusta o te apasiona, no dudes en practicar, leer, estudiar y practicar más, para llegar al nivel que deseas. Y no se olvide tampoco, de que las cosas buenas toman TIEMPO.

Lea, investigue, aprenda, y no deje de hacerlo.

3. ¿Cual es la actitud del programador?
La actitud correcta del programador, es "agarrar el toro por los cuernos". Es despedazar problemas, es simplificar procesos, es superar retos. Si eres un programador que se queja constantemente, esa actitud se vera reflejada en el código que escribas. Por eso es tan importante que un programador sea una persona feliz, tranquila, con ánimos de superación, positivo.

Quiero esta camisa :)

Escribir código es como escribir cuentos, y si el autor esta triste y escribe en ese estado, seguramente los cuentos serán un reflejo de los sentimientos del autor. Si usted se queja por el IDE, el OS, el compilador, así será el código que produce... esto yo he cometido ese error, y lo mejor que pude hacer fué cambiar de actitud, para no escribir código "lleno de quejas".

4. ¿Entiende los conceptos avanzados de la programación?
Ya sea con programación funcional u orientada a objetos, usted debe comprender los conceptos y los tecnicismos asociados a su estilo de programación favorito.
Estos conceptos ayudan a pensar "outside the box", y te ahorran trabajo (como los patrones de diseño).

Si tienes dificultad con los conceptos, lo mejor es "agarrarlo al suave" y aprender un paso a la vez, como los bebes cuando aprenden a caminar, un pasito a la vez.
Lea, pregunte, investigue, y practique con ejemplos hasta que domine el concepto por completo. Porque si no comprendes lo basico, ¿cómo vas a comprender lo avanzado?

5. ¿Qué recursos ocupa un programador en Internet?
Se los resumo en tres recursos que uso casi constantemente:

• Google para buscar códigos de errores, y entender cuando surge un tipo especifico de "Exception".
• Wikipedia para leer sobre leyes, teorías, conceptos.
• StackOverflow para hacer las preguntas difíciles y también las preguntas tontas :)
• La documentación del lenguaje que este usando, también le será muy útil, y las listas de correo, grupos y comunidades que se desarrollan alrededor.

StackOverflow.com

6. ¿Diseñar antes de programar?
Como Informatico, en algun momento nos enseñan la importancia de diseñar, y en otro momento caemos en la practica de codificar mientras se avanza (code as you go). Se necesita un balance entre diseñar el software, y el deseo de ponerse manos a la obra. Tenga al menos la idea de que va a hacer antes de sentarse a programar, piense y elabore un algoritmo, o un pequeño caso de uso, o un diagrama de ER, y le aseguro que va a terminar lo que tiene pensado hacer.

Un buen diseño, es hermoso.

Lo importante es no entrar en ese circulo vicioso de desesperación, aburrimiento, y cansancio tipico de los proyectos de software que no se diseñan con anticipacion. Al diseñar, se evita perder la direccion (resolver un problema), y se vuelve más facil el desarrollo (y la depuracion) del software.

7. ¿Cómo maneja un programador con el estrés?

Run!

Bueno, depende del individuo, muchos juegan o #Beben , y otros hacen ejercicio. El estres en este medio es bastante común, y se debe a varios factores, tanto internos como externos al programador. Lo mejor, suele ser encontrar un hobby totalmente diferente a la programación, y que de preferencia te aleje de la computadora. Practicar un deporte, dibujar o tocar un instrumento musical suelen ser excelentes formas de lidear con el estres asociado con la práctica.
Y claro, un cambio de actitud ayuda mucho también.

Muchas felicidades programadores, gracias a los que trabajan en los bancos, a los que contribuyen en el mundo del software libre, a los que enseñan sin recelo lo que aprenden, gracias a todos, porque nos hacen la vida más facil. ¡Saludos colegas!

Qué Motiva a un Equipo de IT?

Hace poco tuve la oportunidad de ver la conferencia de TED de Dan Pink en la cual nos explica lo que mejor funciona para motivanos a realizar una u otra tarea en nuestro trabajo y lo increíblemente diferente que reaccionamos a las recompensas monetarias dependiendo del tipo de actividad que realizamos. Los invito a que dediquen no más de 20 minutos en presenciar dicha conferencia:

"TED Talk - Dan Pink - La Sorprendente Ciencia de la Motivación"

Los miembros de un equipo de IT somos entes que mediante la creatividad transformamos necesidades de información de un cliente en una pieza de software funcional. Nosotros trabajamos mucho haciendo uso de nuestra creatividad. Aunque muchas aplicaciones luzcan similares y aunque existan herramientas que facilitan y automatizan las tareas de desarrollo, siempre existe un momento en el que expresamos una forma única de llevar a cabo una tarea.

Tomando las ideas presentadas en el video de TED podemos generar una lista extendida de las cosas que realmente motivan a un informático a crear software de mejor calidad en un menor tempo.

• Libertad de acción: Tal como lo menciona Dan en su conferencia de TED, Google y otras empresas han obtenido grandes resultados permitiéndole a sus empleados de IT ciertas franjas de tiempo para dedicarlas en proyectos de su elección.
• Reputación: No es ningún secreto que una característica común entre programadores (y otros de IT) es su egocetrismo. Debido a ello muchos programadores se sienten mucho mas motivados por ganar reconocimiento por competencias y retos mas que por ganancias económicas.
• Importancia de los proyectos: Entre más personas vayan a utilizar lo que estás desarrollando y entre más vital sea este proyecto para tu empresa, el equipo se sentirá más comprometido con el mismo, sabiendo que por ser parte del proyecto los ojos de los altos mandos están puestos en su desarrollo y por ende, en quienes lo están llevando acabo sabiendo que si tiene éxito estos serán reconocidos.
• Diversificación: Trabajar en proyectos de diferentes índoles y constante cambio de tecnologías y frameworks que incrementen los conocimientos y experiencia del equipo, pudiendo extender su horizonte de habilidades.
• Actualización: Herramientas actuales y sin temor a experimentar con nuevas librerías y frameworks. A nadie le gusta trabajar con tecnologías pasadas de moda solamente porque quienes toman las decisiones de adquirirla no conocen lo que realmente están comprando y en muchas ocasiones no son ellos quienes van a usarla.
• Involucramiento de sus superiores: Si eres el gerente, jefe de área, coordinador o líder de un proyecto de IT, aunque no hayas estudiado nada de informática es tu deber involucarte y aprender por lo menos a nivel general la terminología técnica del proyecto y brindar completo apoyo a tu equipo de IT. Si los jefes de IT no se involucran y no tienen ni la remota idea de lo que el equipo de IT realiza, este no se siente apoyado y posiblemente ellos te hagan pasar por escenas como este episodio de The IT Crowd:

"The IT Crowd - The Internet"

Alguna otra sugerencia para motivar a un equipo de IT?

Qué Motiva a un Equipo de IT?

Hace poco tuve la oportunidad de ver la conferencia de TED de Dan Pink en la cual nos explica lo que mejor funciona para motivanos a realizar una u otra tarea en nuestro trabajo y lo increíblemente diferente que reaccionamos a las recompensas monetarias dependiendo del tipo de actividad que realizamos. Los invito a que dediquen no más de 20 minutos en presenciar dicha conferencia:

"TED Talk - Dan Pink - La Sorprendente Ciencia de la Motivación"

Los miembros de un equipo de IT somos entes que mediante la creatividad transformamos necesidades de información de un cliente en una pieza de software funcional. Nosotros trabajamos mucho haciendo uso de nuestra creatividad. Aunque muchas aplicaciones luzcan similares y aunque existan herramientas que facilitan y automatizan las tareas de desarrollo, siempre existe un momento en el que expresamos una forma única de llevar a cabo una tarea.

Tomando las ideas presentadas en el video de TED podemos generar una lista extendida de las cosas que realmente motivan a un informático a crear software de mejor calidad en un menor tempo.

• Libertad de acción: Tal como lo menciona Dan en su conferencia de TED, Google y otras empresas han obtenido grandes resultados permitiéndole a sus empleados de IT ciertas franjas de tiempo para dedicarlas en proyectos de su elección.
• Reputación: No es ningún secreto que una característica común entre programadores (y otros de IT) es su egocetrismo. Debido a ello muchos programadores se sienten mucho mas motivados por ganar reconocimiento por competencias y retos mas que por ganancias económicas.
• Importancia de los proyectos: Entre más personas vayan a utilizar lo que estás desarrollando y entre más vital sea este proyecto para tu empresa, el equipo se sentirá más comprometido con el mismo, sabiendo que por ser parte del proyecto los ojos de los altos mandos están puestos en su desarrollo y por ende, en quienes lo están llevando acabo sabiendo que si tiene éxito estos serán reconocidos.
• Diversificación: Trabajar en proyectos de diferentes índoles y constante cambio de tecnologías y frameworks que incrementen los conocimientos y experiencia del equipo, pudiendo extender su horizonte de habilidades.
• Actualización: Herramientas actuales y sin temor a experimentar con nuevas librerías y frameworks. A nadie le gusta trabajar con tecnologías pasadas de moda solamente porque quienes toman las decisiones de adquirirla no conocen lo que realmente están comprando y en muchas ocasiones no son ellos quienes van a usarla.
• Involucramiento de sus superiores: Si eres el gerente, jefe de área, coordinador o líder de un proyecto de IT, aunque no hayas estudiado nada de informática es tu deber involucarte y aprender por lo menos a nivel general la terminología técnica del proyecto y brindar completo apoyo a tu equipo de IT. Si los jefes de IT no se involucran y no tienen ni la remota idea de lo que el equipo de IT realiza, este no se siente apoyado y posiblemente ellos te hagan pasar por escenas como este episodio de The IT Crowd:

"The IT Crowd - The Internet"

Alguna otra sugerencia para motivar a un equipo de IT?

Proyecto Euler (Reto para programadores)

Proyecto Euler es un sitio web dedicado a los programadores que desean aprender, ejercitar su mente y que tenga un poco de tiempo libre, ofreciendo una serie de retos matemáticos, en orden de dificultad ascendente, que se pueden resolver en el lenguaje de programación que uno prefiera. Nombrado así en honor al matemático y físico Suizo: Leonhard Euler (¿recuerda el Problema de los puentes de Königsberg y las constantes e y π ?, pues es parte de la extensa obra de Euler). A la fecha, el Proyecto Euler posee 295 problemas de naturaleza matemática de dificultad variada. Existe un foro en el sitio, preguntas y respuestas que se habilitan para cada problema una vez que este está resuelto, y diferentes "niveles" para los usuarios registrado, de acuerdo a la cantidad de problemas que este a resuelto.

Si estas aprendiendo un lenguaje nuevo, o simplemente quieres retos nuevos e interesantes que resolver, este es el sitio perfecto para desempolvar tu conocimiento y ponerte a razonar.

Visita el Proyecto Euler:

http://www.projecteuler.net

Proyecto Euler (Reto para programadores)

Proyecto Euler es un sitio web dedicado a los programadores que desean aprender, ejercitar su mente y que tenga un poco de tiempo libre, ofreciendo una serie de retos matemáticos, en orden de dificultad ascendente, que se pueden resolver en el lenguaje de programación que uno prefiera. Nombrado así en honor al matemático y físico Suizo: Leonhard Euler (¿recuerda el Problema de los puentes de Königsberg y las constantes e y π ?, pues es parte de la extensa obra de Euler). A la fecha, el Proyecto Euler posee 295 problemas de naturaleza matemática de dificultad variada. Existe un foro en el sitio, preguntas y respuestas que se habilitan para cada problema una vez que este está resuelto, y diferentes "niveles" para los usuarios registrado, de acuerdo a la cantidad de problemas que este a resuelto.

Si estas aprendiendo un lenguaje nuevo, o simplemente quieres retos nuevos e interesantes que resolver, este es el sitio perfecto para desempolvar tu conocimiento y ponerte a razonar.

Visita el Proyecto Euler:

http://www.projecteuler.net

Dos conceptos de programación que debes manejar.

Advertencia: Post para programadores ;)
Update (17 Junio): Se publica la versión correcta del artículo.

Como en toda carrera, cada cierto tiempo y en algún lugar, alguien inventa o idea nuevos conceptos que cambian paradigmas para bien. El problema de estos (nuevos o no tan nuevos conceptos) radica en que vienen acompañados de terminologia que suele ser complicada y que tambien intimidante.
"Dependency Injection" y "Design by Contract" son dos ejemplos perfectos de lo que menciono, y precisamente les quiero recomendar cuatro lecturas para comprenderlos, ¡y tambien los invito a que los practiquen!... y si ya los conoce, vale la pena repasarlos.

Para "Dependency Injection" recomiendo que lean esta entrada en StackOverflow:

http://stackoverflow.com/questions/130794/what-is-dependency-injection

Luego lea el siguiente artículo publicado en el blog de Google Testing (que de paso, recomiendo que lean seguido):

http://googletesting.blogspot.com/2008/07/how-to-think-about-new-operator-with.html

Para "Design by Contract" pregúntate a ti mismo ¿cuando fue la ultima vez que implementaste interfaces y "assertions" en tu código? y lea:

http://www.dugaldmorrow.com/index.php?option=com_content&task=view&id=19&Itemid=38

Y si quiere un poco más de teoría:

http://www.eiffel.com/developers/design_by_contract.html

Invito a los programadores, que no conocían o comprendían totalmente estos conceptos (como yo) que los entiendan y apliquen lo más pronto posible, para hacer su desarrollo de software un poco más fácil :)

¿Qué otro concepto de programación crees que es importante comprender?
Espero que a alguien le sirva, Saludos!

Dos conceptos de programación que debes manejar.

Advertencia: Post para programadores ;)
Update (17 Junio): Se publica la versión correcta del artículo.

Como en toda carrera, cada cierto tiempo y en algún lugar, alguien inventa o idea nuevos conceptos que cambian paradigmas para bien. El problema de estos (nuevos o no tan nuevos conceptos) radica en que vienen acompañados de terminologia que suele ser complicada y que tambien intimidante.
"Dependency Injection" y "Design by Contract" son dos ejemplos perfectos de lo que menciono, y precisamente les quiero recomendar cuatro lecturas para comprenderlos, ¡y tambien los invito a que los practiquen!... y si ya los conoce, vale la pena repasarlos.

Para "Dependency Injection" recomiendo que lean esta entrada en StackOverflow:

http://stackoverflow.com/questions/130794/what-is-dependency-injection

Luego lea el siguiente artículo publicado en el blog de Google Testing (que de paso, recomiendo que lean seguido):

http://googletesting.blogspot.com/2008/07/how-to-think-about-new-operator-with.html

Para "Design by Contract" pregúntate a ti mismo ¿cuando fue la ultima vez que implementaste interfaces y "assertions" en tu código? y lea:

http://www.dugaldmorrow.com/index.php?option=com_content&task=view&id=19&Itemid=38

Y si quiere un poco más de teoría:

http://www.eiffel.com/developers/design_by_contract.html

Invito a los programadores, que no conocían o comprendían totalmente estos conceptos (como yo) que los entiendan y apliquen lo más pronto posible, para hacer su desarrollo de software un poco más fácil :)

¿Qué otro concepto de programación crees que es importante comprender?
Espero que a alguien le sirva, Saludos!

Jade Raymond: La Reina de Ubisoft

Si bien la industria de los vídeo juegos es dominada por el género masculino también existen féminas que desempeñan cargos importantes en las grandes compañías.  Tal es el caso de la canadiense Jade Raymond que con tan solo 34 años es la productora ejecutiva y líder de Ubisoft Toronto así como también la principal productora de la saga Assasin's Creed.

En los inicios de su carrera se desempeñó como programadora para Sony - participando en Jeopardy! y Rival Pursuit -, IBM y Microsoft, llegando a formar parte de diversos grupos de investigación. Luego de unos años y debido al éxito de su trabajo se desempeñó como productora ejecutiva en Electronic Arts participando en el vídeo juego The Sims Online. Su proyecto mas reciente consiste en el siguiente título para la saga Splinter Cell.

Por sus preferencias es fácil deducir que es una amante de los vídeo juegos y de una otra manera eso ha influido en su éxito. Por ejemplo, se dice que durante 3 meses llego a jugar 10 horas diarias entre EverQuest y Tekken 3, su personaje de vídeo juegos favorito es Donkey Kong y si estuviese en un isla desierta lo que se llevaría sería un Tetris, nada mal ¿no?.

Con el éxito también viene la polémica, se vio involucrada en una disputa legal entre Ubisoft y el sitio somethingawful.com que publicó un cómic que "daño gravemente la reputación e imagen de Jade Raymond"  en el cual ofrecía "servicios sexuales" a tres adolescentes para motivarlos a comprar el juego Assasin's Creed. Ubisoft también fue criticado por aparentemente utilizar a Jade Raymond como imagen - altamente atractiva - para publicitar y promocionar sus títulos.

A pesar de todos los inconvenientes ocurridos, hay que destacar la labor de Jade Raymond y su contribucion a la industria de los vídeo juegos, mas importante aún, el hecho de romper esquemas y tomar la batuta en una industria dominada por el género masculino. ¡Hasta la próxima!.

Jade Raymond: La Reina de Ubisoft

Si bien la industria de los vídeo juegos es dominada por el género masculino también existen féminas que desempeñan cargos importantes en las grandes compañías.  Tal es el caso de la canadiense Jade Raymond que con tan solo 34 años es la productora ejecutiva y líder de Ubisoft Toronto así como también la principal productora de la saga Assasin's Creed.

En los inicios de su carrera se desempeñó como programadora para Sony - participando en Jeopardy! y Rival Pursuit -, IBM y Microsoft, llegando a formar parte de diversos grupos de investigación. Luego de unos años y debido al éxito de su trabajo se desempeñó como productora ejecutiva en Electronic Arts participando en el vídeo juego The Sims Online. Su proyecto mas reciente consiste en el siguiente título para la saga Splinter Cell.

Por sus preferencias es fácil deducir que es una amante de los vídeo juegos y de una otra manera eso ha influido en su éxito. Por ejemplo, se dice que durante 3 meses llego a jugar 10 horas diarias entre EverQuest y Tekken 3, su personaje de vídeo juegos favorito es Donkey Kong y si estuviese en un isla desierta lo que se llevaría sería un Tetris, nada mal ¿no?.

Con el éxito también viene la polémica, se vio involucrada en una disputa legal entre Ubisoft y el sitio somethingawful.com que publicó un cómic que "daño gravemente la reputación e imagen de Jade Raymond"  en el cual ofrecía "servicios sexuales" a tres adolescentes para motivarlos a comprar el juego Assasin's Creed. Ubisoft también fue criticado por aparentemente utilizar a Jade Raymond como imagen - altamente atractiva - para publicitar y promocionar sus títulos.

A pesar de todos los inconvenientes ocurridos, hay que destacar la labor de Jade Raymond y su contribucion a la industria de los vídeo juegos, mas importante aún, el hecho de romper esquemas y tomar la batuta en una industria dominada por el género masculino. ¡Hasta la próxima!.

Tazas de Café Dignas de un Geek

Pensaba titular este post como "Tazas de Cafe Dignas de un Programador" pero la verdad es que todo aquel que trabaja frente a una computadora siente la imperiosa necesidad de tener una taza de café en su mano izquierda (o en su derecha, si es que son diestros), es como si fuera un accesorio más de la computadora y aunque no se ha comprobado científicamente, yo asumo que el café ayuda a pensar mejor y a aclarar la mente. Yo personalmente dependo del café y esta camiseta resume perfectamente mi situacion:

"Instant Programmer - Just Add Coffee (link)"

Así que en este post les traigo una recopilación de las tazas de cafe dignas de cualquier geek.

Porque cuando tienes una idea en la cabeza, no puedes perder la concentración ni para revolver el café (link):

Que soluciones más malevolas y fabulosas se te podrían ocurrir si bebes café directamente de la cabeza de Darth Vader! (link):

No hay nada más cool(para los geeks, no para la gente normal) que una taza que cambia de color según la temperatura de su contenido (link):

Quien no acompaña su café con un poco de pan dulce o galletas? y si no tienes donde colocarlas? no hay problema! (link):

Una taza con Deja Vú, ya que a final de cuentas, ahí es donde irá a parar el exceso de café (link):

Porque la ocasión lo amerita. En el mundo tambien hay mujeres geek (link):

Porque algunos pasamos todo el día trabajando con beans (link):

Para los aficionados a la fotografía (link):

Es una taza de café? es un mouse? es una taza de café mouse!!! Por el momento solo es un concept design pero yo bien compraría uno (link):

No te durará mucho pero valdrá la pena. Taza de café comestible (link):

Alguna otra que consideran merece estar en la lista?

cafe programador geek

Tazas de Café Dignas de un Geek

Pensaba titular este post como "Tazas de Cafe Dignas de un Programador" pero la verdad es que todo aquel que trabaja frente a una computadora siente la imperiosa necesidad de tener una taza de café en su mano izquierda (o en su derecha, si es que son diestros), es como si fuera un accesorio más de la computadora y aunque no se ha comprobado científicamente, yo asumo que el café ayuda a pensar mejor y a aclarar la mente. Yo personalmente dependo del café y esta camiseta resume perfectamente mi situacion:

"Instant Programmer - Just Add Coffee (link)"

Así que en este post les traigo una recopilación de las tazas de cafe dignas de cualquier geek.

Porque cuando tienes una idea en la cabeza, no puedes perder la concentración ni para revolver el café (link):

Que soluciones más malevolas y fabulosas se te podrían ocurrir si bebes café directamente de la cabeza de Darth Vader! (link):

No hay nada más cool(para los geeks, no para la gente normal) que una taza que cambia de color según la temperatura de su contenido (link):

Quien no acompaña su café con un poco de pan dulce o galletas? y si no tienes donde colocarlas? no hay problema! (link):

Una taza con Deja Vú, ya que a final de cuentas, ahí es donde irá a parar el exceso de café (link):

Porque la ocasión lo amerita. En el mundo tambien hay mujeres geek (link):

Porque algunos pasamos todo el día trabajando con beans (link):

Para los aficionados a la fotografía (link):

Es una taza de café? es un mouse? es una taza de café mouse!!! Por el momento solo es un concept design pero yo bien compraría uno (link):

No te durará mucho pero valdrá la pena. Taza de café comestible (link):

Alguna otra que consideran merece estar en la lista?

cafe programador geek

En una empresa: el codigo es el enemigo.

Voy a escribir un par de artículos a la semana, hace poco conseguí trabajo y me esta consumiendo, pero las experiencias y habilidades son invaluables.

El código en exceso es malo. Requiere mantenimiento periódico. Posee errores ... que deben ser encontrados, depurados y mitigados. Añadir funcionalidad extra, implica que el código antiguo se tiene que adaptar.


Mientras hay mas código escrito:

• Existen mas lugares en donde se esconden los infames bugs (que se combaten depurando o escribiendo más código)
  
• El proceso de compilación tarda mas tiempo
  
• Los Checkouts del repositorio de control de versiones también se alargan
• Un empleado nuevo tardara más tiempo en comprender el sistema
• Es mas complicado refactorizar código
• Y también es mas difícil encontrar documentación precisa de: que hace qué, cuándo, dónde y por qué.
  

"Este libro debería leerse en la Universidad..."

Más código, significa menos flexibilidad y funcionalidad; esto para muchos es una paradoja, pero la mayoría de veces, una solución simple, rápida y elegante, es mejor que una "mega super función general que hace de todo".

"Este es más común..."

El código es escrito por ingenieros de sistemas, técnicos programadores o consultores; digamos simplemente que son desarrolladores. Producir más código, requiere mas desarrolladores. Varios desarrolladores deben comunicarse. Un desarrollador tiene un costo de "canal de comunicación" de n^2, como pueden ver, las comunicaciones incrementan exponencialmente con cada desarrollador en el proyecto ( 1^2=2, 2^2=4, 3^2=9, etc...).
Añadamos un poco de papeleo (burocracia) a los canales de comunicación:

• Control de actividades de desarrollo, por metas y diarias.
• Documentos que constan la finalización de las actividades programadas.

... si hago esto por cada desarrollador... termino con un enorme costo organización, en función del tiempo gastado en cada desarrollador, o en función de un nuevo puesto de trabajo para que alguien realice esta tarea.

¿No se debería hacer todo lo posible para incrementar la productividad del individuo en términos del buen código que este escribe? La idea es simple: Escribir menos código para hacer algo (y si se puede, que sea buen código). Si tiene que escribir menos código, se contratan menos personas, y se reducen los costos de comunicación.

Después de todo, una buena empresa debe ser eficiente y eficaz, ¿no?. Si algo ya existe, úselo. Si hay mejores tecnologías, procure utilizarlas. Y si sus desarrolladores le dicen que hay que utilizar una nueva tecnología, procure prestar atención a lo que dicen, y si es factible hágalo.

"Buen equipo, buena silla, buen escritorio... son necesarios para producir buen código."

La comodidad de un desarrollador de software no puede ser discutida. Estos merecen buenas sillas, estar cómodos en sus cubículos o escritorios, café cerca y como máximo, ocho horas de trabajo diarias. El trabajo de un desarrollador de software, no solo es uno de los mas estresantes, sino también es uno de los mejor remunerados. Y si no trata bien a sus desarrolladores, estos producen código enmarañado, descuidado e irresponsable, hackeado para que funcione (ley del llegue)... malo en pocas palabras. Codificar mal, siempre es producir mas código del que se necesita.


Repitan conmigo:

"desarrolladores infelices, producen mal código, que aumenta mis costos".

En la empresa en la que estoy trabajando, la mayoría de desarrolladores piensan que los "usuarios" son los enemigos. Para mi, el código es el enemigo, y para la empresa también.

Una cosa más, para los desarrolladores que leen este articulo... sigan como consejo la sabiduría innegable de xkcd:

programar opinion codigo empresa programador desarrollo