Primera edición de Spain.js

La primera edición de la Conferencia Internacional de JavaScript, Spain.js, tendrá lugar los días 5, 6 y 7 de Julio en Madrid.

En ella podremos disfrutar de desarrolladores tan destacados como Jeremy Ashkenas (creador de CoffeeScript y Backbone.js), Alex MacCaw (creador de Spine.js), Vicent Martí (Github) y Karolina Szczur (Nodejistsu) entre otros muchos.

El objetivo del evento es dar un empuje a un lenguaje que siempre ha tenido una consideración menor para los programadores, pero que cada vez está más presente en nuestro día a día.

¡Espero veros allí!

 

Conferencia Rails 2011


I'm Attending Conferencia Rails 2011
Otro año más se vuelve a celebrar en Madrid la Conferencia Rails, encuentro anual de desarrolladores y empresas alrededor de Ruby on Rails, y este año vuelve más internacional que nunca con speakers tan destacados como Sven Fuchs, Paolo Perrota, Simon Tokumine, Nicolás Sanguinetti,.. y viejos conocidos como Javier Ramírez o Sergio Gil.

Si estás interesados en temas como la programación web, la integración continua, programación para dispositivos móviles, Node.js, Backbone.js, CoffeeScript… Te esperamos del 13 al 15 de Julio en el Retiro.

Build Less

So what to do then? The answer is less. Do less than your competitors to beat them. Solve the simple problems and leave the hairy, difficult, nasty problems to everyone else. Instead of oneupping, try one-downing. Instead of outdoing, try underdoing.

  • Less features
  • Less options/preferences
  • Less people and corporate structure
  • Less meetings and abstractions
  • Less promises

37 Signals – Getting Real: Build Less

Siendo más productivo con Scrum

Scrum es una metodología de desarrollo de software enmarcada dentro de las metodologías ágiles y que propone un ciclo iterativo e incremental. Pero, ¿Qué son las metodologías de desarrollo ágiles?

Las metodologías ágiles se basan en 4 principios fundamentales recogidos en el manifiesto ágil.

  • Individuos e interacciones sobre procesos y herramientas.
  • Software funcionando sobre documentación extensiva.
  • Colaboración con el cliente sobre negociación contractual.
  • Respuesta ante el cambio sobre seguir un plan.

Scrum toma esos principios y propone los siguiente:

  • Divide las tareas en pequeños incrementos con una planificación mínima.
  • Estos incrementos son llamados Sprints y suelen durar entre 2 semanas y 1 mes.
  • Pone énfasis en la comunicación cara a cara.
  • Los equipos son multidisciplinares y auto-organizados de entre 5 y 9 personas.
  • El software funcional es la primera medida de progreso.
  • Se realizan periódicamente entregas del producto, lo que permite:
    • Evaluar el trabajo realizado.
    • Advertir sobre problemas que se detecten.
    • Sugerir mejoras.

Existen 2 tipos de roles: cerdos y gallinas.

Los cerdos son aquellos roles que están comprometidos directamente en el desarrollo del producto:

  1. Product Manager: Representa a la voz de cliente. Escribe y prioriza las historias de usuario.
  2. Scrum Master: Su trabajo es eliminar los problemas que impiden que el equipo alcance el objetivo del Sprint.
  3. Scrum Team: Responsables de la entrega del producto. El equipo debe reunir todas las habilidades necesarias para el éxito del proyecto.

Las gallinas son todos aquellos que aunque están involucrados en el desarrollo del proyecto, no está comprometidos, es decir, no forman parte directa del scrum. Este grupo está formado por usuarios, clientes y managers.

Por otro lado, scrum propone una serie de artefactos que nos permiten gestionar las tareas y tener más control sobre lo que está pasando en cada momento del Sprint.

Product Backlog
Es una lista de requisitos priorizados, con estimaciones que son recogidos por el Product Manager en colaboración con el cliente. Normalmente estos requisitos son escritos en forma de historias de usuarios y deben ser lo más detalladas posibles para ayudar en la medida de lo posible ha realizar las estimaciones. Esta lista debe ser revisada con frecuencia con objeto de ajustar prioridades, estimaciones y re-priorizar las historias de usuarios.

Sprint Backlog
El Sprint Backlog agrupa las tareas que se han seleccionado al inicio de la iteración del Product Backlog para ser desarrolladas durante la siguiente iteración. Las tareas deben ser más detalladas y las estimaciones más aproximadas. Ninguna tarea debe durar más de dos jornadas de trabajo, en ese caso debe dividirse en varias tareas más concretas.

Burn Down
Es una gráfica que muestra el avance del equipo en el desarrollo de la iteración. En el eje Y se encuentras los puntos de historia a realizar durante la iteración, y el eje X los días disponibles. Cada día se va trazando una línea desde arriba a la izquierda hasta abajo a la derecha donde se podrá ver el trabajo restante. Un ejemplo de burn down lo podemos ver en la wikipedia.

Tablón de Scrum
Es un poster, normalmente dividido en 3 o 4 columnas que nos permite de un simple vistazo saber en qué estado se encuentra la iteración. En la primera columna (ToDo) se agrupan las tareas que quedan por hacer, En la segunda las que se están desarrollando en ese momento (WIP: Work In Progress) y en la tercera las tareas terminadas (Done). En la cuarta podemos poner nuestro Burn down y las tareas imprevistas o impedimentos.

Finalmente, para reforzar la comunicación cara a cara del equipo, scrum propone 4 tipos de reuniones o ceremonias.

Planificación de Scrum
Esta reunión se realiza al comienzo de una iteración y en ella el equipo debe seleccionar del Product Backlog las tareas que se realizaran en el siguiente Sprint y añadirlas al Sprint Backlog. Las tareas deben seleccionarse en función de su prioridad y el valor que aporten al negocio y posteriomente estimarlas para intentar predecir cuanto trabajo será posible sacar adelante en la siguiente iteración.

Daily Scrum
Se realiza todos los días a la misma hora en el mismo lugar y todos los miembros del equipo deben permanecer de pie durante el tiempo que dure la reunión que no debe sobre pasar los 15 min. Pueden asistir todas las personas involucradas pero sólo pueden hablar los cerdos. Durante la reunión el Scrum Master pregunta a cada miembro del equipo qué hizo durante el día anterior, qué va a hacer ese día y si ha tenido algún impedimento para alcanzar su objetivo.

Revisión de Sprint
En las reuniones de revisión de Sprint se revisa el trabajo planificado y se presenta a los interesados en forma de demo.

Retrospectiva
Al final de cada iteración el equipo de trabajo se reúnen para discutir sus impresiones sobre el Sprint anterior y para proponer mejoras que puedan aumentar el rendimiento del equipo.

Además de todo lo anterior existen otra serie de herramientas que un equipo de desarrollo ágil pueden incorporar para mejorar su productividad. Las habituales suelen ser:

  • Test Driven Development.
  • Test de aceptación.
  • Integración Continua.
  • Refactoring.
  • Pair Programming.

Al final lo más importante es encontrar la metodología con la que el equipo se encuentre más cómodo y que les permita ser más productivos, realizar el máximo número de tareas posible y ser capaces de corregir errores e incorporar cambios durante el desarrollo del producto, para que finalmente el cliente obtenga el producto que mejor se ajuste a sus necesidades.

Extendiendo FormBuilder para añadir nuevos helpers personalizados

A la hora de hacer nuevos formularios en rails siempre había echado de menos algún helper que te ayudara a incluir los típicos mensajes de error junto al campo al que se refieren para contextualizar cada uno de los mensajes, en lugar de que aparezcan todos listados en la cabecera del formulario.

La idea fundamental de lo que pretendía conseguir es la siguiente:
ejemplo de errores en campos de formulario

Todo esto usando para ello un helper de FormBuilder para que el objeto concreto quede implícito y que el código resultante (en haml) nos quede como el siguiente:

= form_for @user do |form|
   .field
      = form.label :name
      = form.error :p, :name
      = form.text:field :name

El primer parámetro indica el tag html que queremos usar como contenedor del error, y el segundo en atributo del modelo que debemos comprobar. Además, al tag contenedor le añadiremos la clase “error” de css para luego poder darle algunos estilos.

Tras dar algunas vueltas googleando me dí cuenta de que crear un nuevo helper no era tarea demasiado complicada, así que le eché un ojo a FormHelper y observé que está dividido en tres partes principales:

  1. El modulo FormHelper, que encapsula a todos los helpers de formularios.
  2. La clase FormBuilder, que es el resultado de usar el helper form_for y que contiene una instancia del objeto al que se refiere el formulario. Tiene métodos internos con el mismo nombre que los helpers que hacen uso de estos.
  3. La clase InstanceTag, que  es la encargada de generar el código para cada uno de los tags html. Es llamada desde los helpers.

Finalmente, adaptando un poco el código de otros helpers en el mismo fichero, el resultado fue:

module ActionView
  module Helpers
    module FormHelper
      def error(object_name, tag_name, method, options = {})
        InstanceTag.new(object_name, method, self, options.delete(:object)).to_error_tag(tag_name)
      end
    end

    class InstanceTag
      def to_error_tag(tag_name)
      	unless @object.errors[@method_name].blank?
      	  content_tag tag_name, @object.errors[@method_name].first, :class => :error
      	end
      end
    end

    class FormBuilder
      def error(tag_name, method, options = {})
        @template.error(@object_name, tag_name, method, objectify_options(options))
      end
    end
  end
end

Que también se puede ver en su gist correspondiente.

 

Actualización 22 de Marzo de 2011:

Otra forma de personalizar los mensajes de error de los formularios en rails, que acabo de ver en la guía de rails y que ya no recordaba, es usando ActionView::Base.field_error_proc. Simplemente se necesita asignarle un nuevo Proc que reciba el tag html y una instancia del modelo y listo. Podemos devolver lo que deseemos.

HTML5 & CSS3

En estos momentos en los que los fabricantes de navegadores compiten para ver cuál es el más “moderno” y que cada vez parece que tenemos más cerca la publicación del nuevo estándar de html los desarrolladores web debemos ponernos al día y comenzar a implementar los nuevos estándares en nuestras webs. Para ello es importante tener a mano algunas buenas guías, presentaciones y algún libro que nos ayuden a mejorar nuestras webs mientras siguen funcionando en los navegadores más antiguos (lease IE6).

HTML5 and CSS3 de Brian P. Hogan hace un recorrido por el nuevo estándar dando para cada caso ejemplos de uso y soluciones alternativas (normalmente basadas en jQuery) que nos permitan usarlas en navegadores que actualmente no tienen suporte para ellas.

Haciendo un repaso rápido de los temas que se tocan en el libro y que forman parte de HTML5:

Nuevos elementos estructurales: Para hacer nuestros documentos más semánticos se han incorporado muchas etiquetas nuevas y se han eliminado muchas otras que aún seguían haciendo referencia a presentación. Algunas de estas nuevas etiquetas son header, footer, nav, section, article.

Web forms: Una de mis partes preferidas son los nuevos campos para formularios que nos van a ahorrar gran cantidad de javascript y nos va a permitir crear formularios muy complejos de una manera muy sencilla. Algunos de los nuevos elementos son: email, search, slider(type=range), date, color, number. Además se han añadido attributos muy interesantes como placeholder, autofocus y contenteditable.

CSS3: Para permitirnos mejorar visualmente nuestras webs sin necesidad de añadir clases o ids a cada elemento se han añadido montones de selectores y pseudo-selectores, entre ellos destacaría :nth-child(n) que nos permite crear tablas cebreadas sin necesidad de añadir las típicas clases odd y even.

Canvas: Nos permite crear imágenes complejas o gráficos programaticamente con javascript y sin necesidad de liberías externas como Flash.

Audio y video: Una de las características más conocidas es la inclusión de las etiquetas para audio y video que nos darán soporte nativo en el navegador, después, por supuesto, de que se resuelva la batalla sobre formatos que hay abierta entre los distintos navegadores.

Eye Candy (border-radius, shadows, gradients y transformations): Por supuesto, también se hablan de las nuevas propiedades de CSS que nos va a permitir crear bordes redondeados, sombras, gradientes y mucho más sin necesidad de añadir imágenes como fondos.

Por otro lado, se encuentran algunas API’s javascript que aunque no pertenecen directamente al estándar, está asociadas al él y que habrá que tener en cuenta en el futuro. Las más destacadas son:

Local Storage: Que nos permite guardar cosas como la configuración de la aplicación sin necesidad de usar para ello cookies.

Session Storage: Que permite guardar datos en el navegador que se borran automáticamente al cerrar la sesión.

Web SQL databases: Bases de datos relacionales asociadas a un dominio y persistente entre sesiones.

Offline applications: Permite definir archivos que deben ser cacheados para que la aplicación pueda ejecutarse sin necesidad de conexión a internet.

History: Permite manejar el historial del navegador.

Cross-documents messages: Nos da la posibilidad de enviar mensajes entre ventanas con contenido cargado desde diferentes dominios.

Websockets: Crean una conexión con estado entre un navegador y un servidor.

Geolocation: Permite obtener la latitud y la longitud de un navegador web.

Por otro lado, existen otro montón de tecnologías que aún no se encuentran suficientemente maduras para usar en ningún navegador y por las cuales todavía tendremos que esperar un tiempo. Entre ellas se encuentran las siguientes:

CSS3 Transitions: Animaciones sobre interacciones directamente en CSS.

WebWorkers: Ejecución de javascript en segundo plano.

3D canvas con WebGL: Creación de imágenes 3D sobre el objeto canvas.

IndexedDB: Bases de datos de tipo clave/valor en el navegador similares a las NoSQL.

Drag & Drop: Api para arrastrar y soltar elementos entre el sistema operativo y el navegador.

Client-side form validations: Validaciones de formularios en el navegador sin usar javascript.

En resumen, nos esperan unos años muy prometedores en lo que ha desarrollo web se refiere con montones de tecnologías nuevas que vienen a facilitarnos el trabajo y a abrirnos un montón de posibilidades nuevas. Creo que es importante que comencemos a usar esas tecnologías desde ya para que los usuarios más avanzados puedan comenzar a beneficiarse de ellas, sin dejar de lado a los usuarios de navegadores sin soporte, y para que cuando llegue el resto de usuarios todas esas tecnologías se encuentren maduras y todos podamos disfrutar de una web mejor.

¿Qué hace a un buen programador?

Pensando sobre las cualidades que debe tener un buen programador, y para que se me quede bien grabado, según Andrew Hunt y David Thomas en su libro The pragmatic programer, todos los programadores deben compartir las siguientes cualidades.

adoptador precoz / adaptador veloz: Instinto para probar nuevas tecnologías y técnicas, y para adaptarlas rápidamente al resto de su conocimiento.

inquisitivo: Tendencia a preguntarse cómo funcionan las cosas, lo que puede afectar a sus decisiones futuras.

pensador crítico: Siempre se pregunta por qué las cosas se hacen cómo se hacen y rara vez se conforma con aceptarlas tal cual.

realista: Intenta entender la naturaleza de cada problema al que se enfrenta, lo que le permite afrontar los problemas sabiendo cómo de dificiles y cuánto tiempo pueden tomar.

hombre orquesta: Se interesa por un amplio espectro de tecnologías, y aunque su trabajo requiera ser un especialista, siempre será capaz de afrontar nuevos retos.

Todas estas características no serían nada sin la más importante.

Piensa en tu trabajo

Para completar la lista dejo la guía para programadores pragmáticos que se encuentra al final del libro Referencia rápida para desarrolladores pragmaticos.