Balsamiq Mockups

Una de las partes mas complejas de desarrollar una aplicación es la comunicación entre las distintas personas involucradas. Es fácil que se creen malentendidos, que en ocasiones pueden generar mucha frustración, y una gran perdida de tiempo malgastando esfuerzos en la dirección equivocada. Creo que siempre ayuda mucho más hacer bocetos o cualquier otro tipo de gráfico para representar lo que se quiere, que una lista de cosas que se pueden entender de muchas formas.

Illusion of agreement
Illusion of agreement

Y una aplicación que me encanta, para poder hacer muy rápidamente bocetos de las pantallas de tu aplicación, es Balsamiq Mockups. A pesar de estar hecha en AIR (el aspecto de estas aplicaciones no me suele gustar) es muy bonita, y realmente sencilla. Una prueba definitiva de lo sencilla que es es que se puede empezar a usar sin tener que usar la documentación. Solo tuve que consultarla para ver como enlazar dos mocks entre si, que aun así es muy fácil. Es mucho más rápido (al menos para mi) hacer bocetos de las pantallas con Balsamiq Mockups que dibujarlos a mano. Además tiene un modo presentación a pantalla completa.

Pero lo que realmente triunfaría sería poder editar y compartir mockups de forma remota, no se si mediante una interfaz web o algo parecido. Eso es lo que mas echo de menos para poder trabajar de forma colaborativa a distancia.  No me gusta que sea software privativo, pero no conozco otra alternativa libre. Y aunque la licencia vale unos 79$, si escribes una revisión en tu blog te dan una licencia gratis 😀

Aqui podeis ver un pantallazo sobre un mockup de la aplicación en la que estoy trabajando ahora:

facturagem_mockups

Conferencia Rails 2009

logo conferencia rails
conferencia rails

Este año la conferencia rails promete, además de haber un día mas para talleres prácticos, vendrá gente como: Nathaniel Talbott, David A. Black, Yehuda Katz, Obie Fernandez y Scott Chacon.

Desde hace algún tiempo tengo curiosidad hacia otras alternativas a las bases de datos relacionales,  asi que voy a ir con muchas ganas a la charla sobre key value stores y a la de casandra DB.

Tampoco pienso perderme dos charlas que hablarán sobre el concepto de desarrollador,  el desarrollador total y la herramienta de desarrollo defintiva ,  ni tampoco la de alternativas ligeras a rails.

Nos vemos allí 🙂

Enviar emails desde rails a través de gmail

Pensaba que rails soportaba el envio de emails con tls de serie, pero no es asi. Para poder enviar emails a través de gmail, es necesario usar tls, pero es muy sencillo de añadir mediante un plugin:

Y ya solo queda añadir el parametro en la configuración de ActionMailer para que use tls:

Después de haber hecho durante años las validaciones de email mediante mas o menos complicadas regex, he descubierto que la libreria Tmail tiene una clase Address, que te parsea la dirección de email y te lanza una excepcion si no es correcta. Asi, por ejemplo para validar un email podemos hacer:

planetaki

Hace tiempo que decidi probar planetaki, me llamaba mucho la atención. La primera sensación fué que estaba muy bien pensado para gente no friki, que no sabe lo que es un feed. Y probé a crearme mi propio planetaki, y fué increiblemente sencillo. El diseño mola mucho, esta todo muy cuidado.

He usado ya unos cuantos agregadores, (Google Reader, NetVibes, Bloglines …) y aunque el que mas me gusta es el google reader, todos ellos tienen en común algo que no me gusta. Cuando lees bastantes blogs, en general no te interesa saber absolutamente todo lo que escriben los autores, simplemente quieres seguirlo en lineas generales.

Y te vas de vacaciones, o pasas un tiempo sin leer blogs, y te van apareciendo cada vez mas feeds sin leer. Al final lo vives un poco como una obligación, y marcar los no leidos como leidos se vuelve rutinario y aburrido. Esa es otra idea que me gustó de planetaki. Tienes una sola página con tus ultimos feeds, nada de carpetas con el numero de elementos sin leer. Esta opción me gusta mucho para feeds que no me importe dejar sin leer posts, por ejemplo, tiras comicas o blogs de gente que me gusta hojear solo de vez en cuando.

A pesar de que me gustó mucho, no me sirve por que hay blogs que quiero saber cuantos post tengo por leer y no me quiero perder ni uno. Y necesito también alguna forma de clasificar los blogs que leo, no es lo mismo dedicar media hora a leer tiras comicas o blogs superficiales, que blogs técnicos sobre el desarrollo de rails.

Hace poco descubrí gracias a Perronaider, feedly, es un plugin de firefox, usa google reader por debajo, pero presentandolo en bonito. Tengo que probarme a ver si me acostumbro (me estoy volviendo perro viejo), pero tiene muy buena pinta.

dreaming in code

Dreaming in code

Dreaming in code es la historia de un proyecto de software, con gente muy brillante, ideas muy buenas e innovadoras, pero que fracasa estrepitosamente. Como dice el subtitulo del libro:

Two Dozen programmers, three years, 4,732 bugs, and one quest for trascendant software.

Lo mejor del libro es como explica la dificultad de desarrollar software. El autor, Scott Rosenberg es un periodista con experiencia como programador, cuenta de una manera muy divulgativa y muy clara por que que cuesta tanto hacer software que funcione bien, entregarlo a tiempo, y que sea fácil de usar. En este caso cuenta la historia del desarrollo de Chandler, una agenda para gestionar calendarios, tareas y notas de una forma muy eficaz. Te hace pensar que para gestionar tareas no tenemos ninguna herramienta que sea efectiva y productiva.

La fuente de ideas y de dinero para el proyecto,  Mitchell Kapor,  es uno de los creadores de lotus 1.2.3 tenia mucho dinero (que habia ganado con Lotus) y decidió crear chandler retomando muchas de las ideas originales de Agenda, un programa para msdos que no llego a triunfar por su curva de aprendizaje.

El desarrollo de chandler empieza en el 2001,  pero pronto empiezan a tener problemas, el proyecto se vuelve demasiado ambicioso, y los miembros del equipo pasan mucho tiempo desarrollando partes de forma aislada y no pueden enseñar o ver nada. Por ejemplo, como en aquella epoca estaba muy de moda el p2p, decidieron crear un nuevo sistema de ficheros que fuese descentralizado. Y el proyecto se empieza a convertir en un sumidero de horas de trabajo y dinero.

Finalmente, aunque tardaron varios años mas de lo previsto en tener algo que se pudiera enseñar y Kapor abandonó el proyecto, lograron sacar Chandler, aunque con bastantes modificaciones respecto a la idea original. Ya no seria una aplicación p2p, si no que tendria un servidor (en java) y un cliente (python). Chandler ahora mismo tiene muy buena pinta, y es bastante usable aunque algo pesado, pero tiene muchas ideas que podrian influir mucho en cualquier gestor de tareas / agenda nuevo.

Muy recomendable, y no solo para gente técnica.