El primer paso es empezar

Aquí un link a una historia del blog de 37signals donde hablan sobre el paso más importante a la hora de hacer algo, “empezar”. Estoy muy de acuerdo con este post, no nos podemos quedar pensando en todo lo que necesitamos para empezar un negocio, hay que trabajar y lo que necesitemos saber lo vamos a aprender en el camino.

El ejemplo que usan son dos dibujos de Vincent Van Gogh con dos años de diferencia. El primero de un carpintero es muy malo y el segundo hecho dos años más tarde, demuestra una gran habilidad de la técnica. Esto sirve para hacer el punto de que este maestro empezó tarde en su vida y que no era un niño prodigio sino que aprendió trabajando duro y mediante la práctica. 

Seamos como Van Gogh y empecemos a trabajar.

Post de 37signals: The first step is to start

Published
Categorized as Default

Wireframes y Prototipos

Para crear una buena aplicación web es esencial empezar con la interface. Con lo que el cliente final tiene que trabajar cada día. La interface tiene que ser clara y comunicar efectivamente lo que el usuario necesita hacer o entender con cada pantalla.

Lograr una interface clara no es fácil. La realidad es que la mayoría de las veces cometemos pequeños errores que confunden a los usuarios. Lo que significa que la unica forma de llegar a un diseño efectivo es viendo a los usuarios usar lo que tienes, entender los problemas con los que se encuentran y solucionarlos. En resumen “user testing” y re diseñar.

Mi herramienta favorita para lidiar con este asunto son los wireframes. Aunque regularmente los hago usando OmniGraffle, en proyectos reciente he empezado a hacerlos en papel y el resultado ha sido muy interesante.

Primero dibujo con muy pocos detalles dos o tres pantallas y hago que algún miembro del equipo use los wireframes como si fueran el producto final. Para hacer click tienen que tocar el papel donde hay botones dibujados. Este tipo de “user testing” informal ayuda a detectar problemas grandes en el diseño y al ser un simple “sketch” en una hoja de papel, hace muy fácil botar ese diseño y probar uno nuevo.

Ayer mismo estaba trabajando en una aplicación que uno de sus componentes principales es una agenda. Probamos al menos 15 diseños diferentes para resolver la presentación de la data en la pantalla. Luego hicimos pruebas con dos personas que visitaron la oficina donde estábamos y descubrimos problemas con donde teníamos los botones para realizar acciones sobre la data. En 2 minutos hice un nuevo dibujo con un pequeño cambio y las próximas dos personas que hicieron el “test” no se encontraron con el mismo problema.

Este acercamiento al “user testing” es informal y agil pero estoy convencido de que ayuda a mejorar las interfaces en una etapa temprana del proceso. Definitivamente sigo pensando que una vez que tengamos un prototipo en html y funcional deberíamos hacer más pruebas e incorporar cambios que ayuden a resolver los problemas encontrado en las pruebas.

Esta última parte es la que nunca veo suceder. Mucha gente hace “testing” pero luego ignoran los resultados y no hacen nada por mejorar los problemas que se encuentran.

Para hacer “testing” es necesario ser humilde, aceptar los resultados y hacer cambios para resolver los problemas.

Los wireframes en papel hacen más fácil este proceso. No cuesta mucho dibujar un “sketch” con algunas ideas nuevas y probarlas rápidamente.

Es mejor producir muchas ideas de “baja resolución” y encontrar la que mejor funciona, que producir una sola idea de “alta resolución” y apostar todo a ella.

Published
Categorized as Default

El UI no se puede dejar para después

Hay que ser realista y admitir que la mayor parte de las aplicaciones que usan las personas diariamente son una porquería. Mal diseñadas, feas a la vista y con mas “features” de los que una persona cuerda quisiera aprender. El software es una herramienta y el UI (interface) es lo que permite usar esa herramienta. De que vale tener una herramienta que hace cosas maravillosas pero que sólo son accesibles a dos o tres personas.

El problema de las malas interfaces y mal software empieza cuando se ensambla un equipo para crear una aplicación nueva. Muchas veces este equipo solo tiene una persona, un programador. El programador como por instinto comienza a crear esta herramienta de la mejor forma que conoce, creado modelos de data, tablas en una base de datos y “queries” para aceder esa data. Dejando para último algo que equivocadamente se le llama “hacer que se vea bonito”.

La calidad de una herramienta se mide en función a cuan fácil hace el trabajo para el que se diseño. Un software que puede hacer mil cosas pero esas mil cosas son difíciles de hacer es un software de mala calidad.

Ultimamente he estado haciendo research para un proyecto en el que estoy trabajando. Me ha tocado estudiar aplicaciones para el mercado de salud y la verdad es que no se ni como catalogarlas. Son realmente malas. Basta con hacer una búsqueda rápida en Google Images ver lo malas que son.

Para terminar este post rabioso, quiero dejar claro cual creo debe ser el proceso básico para la creación de un software, ya sea para el web o para desktop o para lo que sea.

  1. Entender lo que quiere el cliente.
  2. De lo que quiere el cliente, escoger lo que necesita. En otras palabras la menor cantidad posible de features que todavía logren que el cliente compre el producto.
  3. Diseñar visualmente las herramientas necesarias para facilitar lo que necesita el cliente.
  4. Probar el diseño con clientes.
  5. Crear la tecnología necesaria para hacer posible las herramientas diseñadas.
  6. Llevar el producto al cliente.
  7. Repetir el proceso.

La mayor parte de las aplicaciones que veo en el mundo profesional fallan miserablemente en casi todos los puntos. ¿Que opinas? Deja un comment abajo.

Published
Categorized as Default

Deployment para Web Apps con GIT

La meta de este post es explicar como hacer deployment de un web app con un solo comando como:

$ git push production

Una vez entrado este comando, el repositorio local envia las diferencias a la copia del repositorio en el servidor de producción y un script de post-update se encarga de actualizar esta copia. Listo un deployment automatizado. Lo mejor de todo es que si haces cambios en cualquiera de los dos lados facilmente puedes reconciliar los cambios en ambos lados. Esta misma estrategia se puede utilizar con varios servidores. Por ejemplo:

$git push staging

$git push client-testing

Supongo que queda clara la idea. Así que ahora el proceso paso a paso de como hacerlo.

Voy a partir de la premisa de que estás usando github pero eso se podría hacer de igual manera con cualquier otro servicio o sin usar ninguno de estos servicios.

  1. Crea un repositorio en GitHub y haz un clone a tu sistema local
    $git clone [email protected]:USERNAME/reponame.git
     
  2. Entra por ssh a tu server y haz un clone del repo al directorio donde deben estar los files recuerda que el punto al final de comando es importante para que git ponga los files en el directorio que estas sin crear uno nuevo.
    $git clone [email protected]:USERNAME/reponame.git .
      
  3. Una vez “clonado” el repo en tu server de producción debes editar el file que se llama .git/hooks/post-update. Borra todo el contenido de este archivo y sustituye con este file. Despues de eso debes añadir permisos para ejecutar ese archivo.
    $chmod +x post-update
      
  4. Ahora en tu sistema local debes añadir como un “remote” al repositorio que está en tu servidor de producción.
    $git remote add production [email protected]:/full/path/to/repo
      
  5. Una vez hagas esto ya podrás hacer
    $git push production

Debe hacer una aclaración para que esto funcione debes haber crear key pairs de ssh para poder entrar a tu servidor remoto sin usar passwords. Hace un tiempo hice un blog post sobre eso que podría ayudar. 

Si algo no queda claro no duden en dejar comentarios abajo.

Published
Categorized as Default

Kaleidoscope

Kaleidoscope es un app para Mac OS X que sirve para comparar archivos y ver sus diferencias. Esto se utiliza con frecuencia en ambientes de trabajo con sistemas de manejo de código (SCM). Este app además de remplazar la herramienta que trae Xcode, incluye varias innovaciones interesantes.

Lo más que me llama la atención de Kaleidoscope es que tiene un modo para comparar diferencias de imagenes. Estoy seguro que deben haber unos cuantos apps para hacer esto pero esta es la primera vez que me encuentro con uno y realmente me encanta.

Otra cosa interesante es que tiene disponible 3 modos para expresar visualmente las diferencias entre los archivos. Además de esto se integra facilmente con GIT y SVN porque tiene un componente para hacer correr la aplicación desde el Terminal.

Diseño
Esta aplicación fue diseñada por los maestros de Sofa una empresa ejemplo de lo que toda empresa de software debería aspirar ser. Se nota que este producto fue manejado con mucho cuidado y con muchísima atención a los detalles. Es rápido, fácil de usar y se ve bien. Los “keyboard shortcuts” son buenos y tienen un app para el Terminal. Simplemente algo bien pensando y excelentemente ejecutado.

Muy recomendada. Me gustaría saber que piensan.

Published
Categorized as Default

Como crear y aplicar un “patch” con svn

Advertencia: Este “post” podría ser algo aburrido o incomprensible para los lectores que no hace desarrollo web y que no usan un sistema de control de versión para sus proyectos. Si usted es un web developer y no está usando un “version control system” pues la debes estar pasando muy mal. Yo uso subversion (svn) pero pero hay mas para escoger. El más popular entre los “cool kids” hoy día es Git gracias a GitHub pero también está Mercurial, CVS y muchos otros. Cada uno tiene sus ventajas y desventajas así que lea bien antes de seleccionar con cual casarse.

¿Porqué tuve que aprender a hacer esta cosa?

Hoy estaba trabajando en un proyecto que llevo completando hace meses en sesiones de una hora. A este paso terminaré en el 2030 pero terminaré. El punto es que necesitaba mostrarle unos cambios que había hecho a un amigo pero no quería hacer un “commit” porque no estaba seguro. Así que creer un “patch” y eso fue lo que le envié.

Un “patch” es básicamente un file de texto que contiene todas las diferencias generadas desde la revisión pasada del repositorio. Este archivo es ideal para enviar por mail, IM o para reportar “bug fixes” a proyectos “open source” donde no se tiene privilegio de “commit”.

Como hacer un patch con svn (usando el terminal):

  1. Navegue hasta el hasta el directorio principal de su proyecto (debe estar funcionando con svn) Ejemplo: cd ~/Proyects/FavoriteCustomer/
  2. Escriba svn diff > [filename] Ejemplo: svn diff > ~/Desktop/bug_fix.patch

Listo ya creó un “patch”. El segundo comando creará un file con todas las diferencias en su proyecto.

Como aplicar un patch con svn (usando el terminal):

  1. Verifique el archivo de “patch” que va a aplicar y asegúrese que no le hará daño a su proyecto.
  2. Navegue hasta el directoria principal de su proyecto y escriba:
    patch -p0 -i [filename] Ejemplo: patch -p0 -i ~/Desktop/bug_fix.patch

Eso es todo.

Published
Categorized as Default

Electrónica101: TweetDoorBell


El primer proyecto que quiero hacer con el Arduino es un timbre que cuando se presione envie un mensaje a Twitter diciendo que hay alguien el la puerta junto a una foto de la persona. Hoy terminé la primera parte.


En esta versión del proyecto lo que tengo funcionando es un circuito con un botón que cuando se presiona envia un mensaje via puerto serial. Hice un pequeño script en Python que escucha el puerto serial y espera mensajes de parte del Arduino. Cuando el mensaje del Arduino llega este script envia un mensaje a la cuenta de twitter que cree para este propósito.

Lo próximo que voy a hacer es añadir la lógica necesaria para que se tome la foto usando un webcam, la suba a yfrog y añada el url en el post de twitter.

Una vez esto funcione bien lo próximo sería la parte más complicada, que es integrar un timbre común y corriente con el arduino para poder detectar cuando alguien lo toca. Ya tengo una idea de como lo quiero hacer pero no se se si funcione.

Published
Categorized as Default

Electrónica101: LED Interactivo

Hoy pude dedicarle un poco de tiempo a leer Getting Started With Arduino y ya he tenido un par de sorpresas. La más interesante hasta el momento es la idea que se define con el término inglés de “tinkering”.

“Tinkering” se trata de tomar objetos electrónicos descartados y cambiarlos, añadir extraer y combinar elementos para crear nuevos objetos, algunas veces esto se hace sin un objetivo definido. Jugar para aprender.

Cuando pienso en esta idea no puedo evitar pensar en como fue mi proceso de aprendizaje de todo lo que se y hago. Por ejemplo empecé a aprender programación cuando vi unas cuantas lineas de código, vi lo que hacían y las cambié para ver si lograba otro comportamiento. Esto se ha repetido millones de veces a lo largo de muchos años. Ahora el proceso es otro pero empezó de esta forma. Me gusta esta forma de aprender así que estoy más motivado que nunca.


El proyecto de esta semana

Esta semana lo que hice fue un circuito muy simple que detecta cuanta luz recibe un sensor y basado en esto define la frecuencia con la que parpadea un LED. Un proyect simple y el resultado es bastante impresionante (por lo menos para mi).

Una cosa que creo que le añadió un poco más de emoción a este proyecto fue que usé una libreria de Python para leer el resultado de la lectura del sensor. Así que ahora tengo un pequeño dispositivo que sirve para medir cuanta intensidad de luz recibe este sensor desde un script de Python. Me pregunto que puedo hacer con esto…

Published
Categorized as Default

Chrome Developer Tools


Este vídeo es sobre las herramientas para developers que tiene mi nuevo browser favorito (por lo menos esta semana) Google Chrome. Esto fue durante una sesión para expertos en aplicaciones web, en el evento Google I/O 2010.

Un “feature” interesante es que ahora te permite editar el código JavaScript mientras la aplicación está corriendo. En otras palabras, encuentras en error en tu JS editas el cambio y puedes ver los resultados sin tener que hacer refresh o editar el “source”.

¿Has usado los dev tools de WebKit (Safari/Chrome)?
¿Usas Firefox/Firebug?
¿Qué prefieres? 

Published
Categorized as Default