Geek & Roll

Del artículo:

Un proceso es un instrumento de autoridad. Un proceso es una proclamación de qué hacer, cómo debemos de hacerlo y en qué orden. Un proceso es conservador, jerárquico y formal. Un proceso mantiene el status quo. Es la administración imponiendo orden y control desde arriba. Si los procesos fueran un partido político, sería de derecha.

Es fácil ser seducido por las bondades de la metodología ágil. Promesas de equipos auto suficientes, entregas frecuentes y listas para producción, Yippi-kay-ay. Demasiado proceso y en vez de avanzar nos quedamos llenando reportes y formas; muy poco proceso y todo se vuelve un manojo de actividad descontrolada y poco empuje (y entrega).

El artículo discute la etiqueta “ágil” que tanto se usa en administración de proyectos de software hoy en día. Por ahí leí que “scrum” (intercambiado por ágil en esta ocasión) no es una bala de plata para tener proyectos exitosos. Existen factores como la experiencia y motivación del equipo, así como también la naturaleza del proyecto, por lo que una aproximación orientada a personas tiene más sentido que orientado a procesos, y viceversa.

Lean el artículo fuente (en Inglés), y los invito a dejar sus comentarios sobre el tema, experiencias personales, etc.

Últimamente he estado pensando en el principal problema de twitter (aparte de la estabilidad): el ruido. Es dificil separar la información “real” del ruido que llegamos a tener en nuestra timeline de un solo vistazo. Esta es una propuesta pequeñita de mejora:

Una de las principales fuentes de ruido son los hashtags (palabras “marcadas” que se utilizan para ayudar en la búsqueda). Hay gente que termina dedicando incluso más caracteres a los hashtags que al post en si.

Mi propuesta de 15 minutos no implica cambiar el funcionamiento de la publicación de hashtags, sino separarlos (por medio de programación) del contenido del post. Se entiende mejor con un ejemplo (click en las imágenes para ver a tamaño completo):

Este es un tweet normal:

Y este es uno con los hashtags separados del contenido del post.

A mi me parece que la diferencia, aunque en un sólo tweet se ve pequeña, sería de gran ayuda al leer Twitter por medio del sitio web.

No pretendo que esto llegue hasta twitter (ni que fuera la gran cosa), pero si a alguien le interesa, sería más o menos sencillo de implementar en un userscript de greasemonkey.

Antes de que digan cualquier cosa, si, ya estamos pensando en que cuando aparezca mi sección diga “tweet & roll” en el header.

O “El diablo está en los detalles”.

Recientemente he estado usando Grails como framework para desarrollo Web con Java y, francamente, estoy bastante sorprendido. Realmente es un boost a la productividad, tanto que una vez que terminé mi diagrama UML del dominio de mi primera aplicación en Grails y comencé a programar las clases de dominio, no podía creer que esas mismas clases fueran las que se usarían para persistir en la base de datos. No hay que crear archivos hbm.xml ni configurar Spring. Sólo crear la clase del dominio, y ya.

Después de varias sesiones nocturnas de un par de horas leyendo sobre Grails, y viendo el código que genera el scaffolder incluído, empecé a crear mis controladores, vistas, refactorizando el modelo. Todo iba bien hasta que me topé con la necesidad de usar datos enumerados (enums).

La solución en sí es sencilla. El problema es que no existe documentación suficiente para utilizar enums con Grails. Después de consultar distintas fuentes e invertir buena parte de mi Domingo en dar con la solución, aquí les presento el código con el que pueden lograr utilizar enums en Grails. Leer el resto de este post.

El primer 90% del código toma 90% de tiempo de desarrollo. El 10% restante de código toma el siguiente 90% del tiempo de desarrollo. Tom Cargill.

Algo que todo project manager debería tener presente ;)

Axel: Wey, soñé una onda bien curada
Rafyta: ¿Qué?
Axel: que definía behavior dentro del CSS
Axel: por ejemplo: #elemento:click { .bloques: fadeout() }
Axel: Está curadísimo, sería sencillo hacer un parser para aplicar las func…
Rafyta: http://yellowgreen.de/morecss
Axel: …
Axel: FUCK!

No sé que es peor, si soñar con CSS y Javascript o tener un sueño “pidata”.

Por si quedaba duda, fue April’s fool.

Esto es algo de lo más difícil que me ha tocado escribir desde que decidí iniciar un weblog. A lo largo de los años he defendido el modelo de fuente abierta, el Software Libre, el uso de GNU/Linux y los formatos abiertos.

Como sabrán, en el trabajo me he visto en la necesidad de usar día a día Windows Vista, y aunque puedo ver muchas de sus deficiencias, también he visto algunas de las características que hacen de Windows un sistema operativo tan atractivo para tantas personas. Probando el beta de Windows 7 no pude dejar de pensar en querer algo así para mi computadora.

Y bién, dicen que reconocer el error es de sabios. Más aún corregirlo. Después de batallar más de dos días tratando de instalar Netbeans y Grails en mi laptop personal, terminé por instalar Windows 7 y no puedo estar más contento. Junto con Windows Vista en mi laptop de trabajo, forman mi ecosistema de cómputo 100% Windows. Ahora soy más productivo y feliz.

Por lo mismo no esperen ver más artículos sobre GNU/Linux, ahora me enfocaré en programación para la plataforma Windows, .NET y programas disponibles para Windows.

Hoy por la mañana descubrimos el sitio www.tikkia.com, el cual es una red social enfocada a profesionistas del área de las TI en Latinoamérica, creada por el mismo grupo responsables de la Super Happy Dev House México. Después de probar un poco el sitio que se encuentra en fase Beta decidimos hacerle una pequeña entrevista a Santiago Zavala, programador de Tikkia y responsable de asuntos internacionales del sitio. La entrevista después del salto.

Leer el resto de este post.

Edit: ELF 1.2 ha salido a la luz. Visiten http://www.cesarolea.com/everlastingflame/ para mas detalles.

El mejor (¿único?) auto hangup para BlackBerry, Everlasting Flame (ELF para los amigos), se encuentra muy próximo a pasar a su versión 1.2. La novedad principal es que ahora la interfaz gráfica es bilingüe, dependiendo de la configuración de localización de la BlackBerry, todo el texto cambia de Inglés a Español. Claro, soporte para más idiomas es trivial de agregar, siempre y cuando alguien me mande la traducción del texto :)

Hay dos cosas como prioridad para la versión 1.3:

• Remarcado automático después de que la llamada se termine
• Reescritura de la arquitectura de las opciones para hacer el sistema más flexible y robusto (y espero que con menos bugs)

El remarcado automático actualmente falla al querer reiniciar una llamada. La API te permite invocar a la aplicación del teléfono (a través de la clase Phone) y pasarle un número pero al terminar la llamada esta aplicación ya está abierta, por lo tanto no sirve. Inyectando la tecla Send tampoco funciona. Tengo que encontrar una forma de ser notificado cuando la aplicación Phone regrese a su pantalla inicial (la de tiene el historial de números marcados) y entonces intentar automatizar el menú para iniciar la llamada.

La reescritura de la arquitectura de las opciones es algo que sabía que llegaría eventualmente. Si se desean agregar más opciones se tiene que evitar los largos bloques condicionales anidados que son fuente de errores y nada extendibles. No serán características que tengan un impacto directo para las características del programa, pero son bases sólidas para poder continuar agregando características útiles.

Visiten el sitio oficial del proyecto, descárguenlo, úsenlo, reporten errores y sugieran características. Si EFL les es de utilidad, no se olviden de contribuir, donando cualquier cantidad de dinero (ya se puede por paypal), lo que anima al equipo de desarrollo (o sea yo) a seguir con el proyecto. También se puede colaborar escribiendo documentación, traduciendo y programando.

Me da mucho gusto anunciar al mundo y en exclusiva por Geek&Roll.com que Everlasting Flame, la aplicación definitiva para los usuarios del “plan sin fin universitario” de Telcel (ver aquí y aquí) va a ver la luz muy pronto. He creado un proyecto en Google Code donde estará guardado el código para todos aquellos que deseen contribuir al proyecto. Algunos detalles de la aplicación:

• Será liberada bajo la licencia GPLv3
• Contrario a lo que dije en posts anteriores, los binarios no tendrán costo
• Si se desea ayudar al proyecto podrás hacerlo donando a una cuenta de PayPal que será dada a conocer más adelante que puedes conocer en el sitio del proyecto cesarolea.com/everlastingflame
• Otra manera de ayudar es uniéndote al proyecto como programador o haciendo documentación
• Si deseas que se incluya o se le de prioridad a cierta característica, la mejor manera de hacerlo es donando al proyecto o pagando para su desarrollo, siempre respetando las cláusulas de la licencia GPLv3
• Bajo ninguna circunstancia se puede hacer responsable al equipo del proyecto Everlasting Flame sobre cualquier daño causado directa o indirectamente por el uso de esta aplicación. Esto incluye cobros relacionados con la duración de las llamadas

Información sobre la descarga, instalación y uso de la aplicación será publicada en la Web del proyecto.

Hace un par de días me topé de manera azarosa (para variar) con LOLcode, un lenguaje de programación “esotérico” (raro/inútil/conceptual) que utiliza la sintaxis de LOLCATS, esas fotos de gatos haciendo cosas chuscas con letreros muy, mmm… particulares, mala ortografía, palabras cortadas, etc. Anyway, me bajé el parser para PHP de lolcode.com y no pude evitar modificarlo para nuestros propios fines.

Sin más preámbulo aquí está el KIUBO (Hello World) en NORTEÑO:

KPDO MORRO
 OIGA “KIUBO”
CHILO

Lo que en PHP sería:

<?php
 echo (”Hello World”);
?> 

Algunas consideraciones:

• NEL = null
• SIX = array
• PISTO = loop
• HIELERA = base de datos
• 24 = tabla
• PURO PEDO = // (comentarios)

La spec está abierta a colaboraciones / sugerencias. Aún no hay sitio oficial, pero en cuanto “haiga” lo comunicaremos por este mismo medio.