Archivo de la categoría "General"

Soluciones para gestionar el rendimiento de las aplicaciones Ruby on Rails

Tuesday, 6 de May de 2008

El mercado de soluciones dedicadas a gestionar el rendimiento de aplicaciones Ruby on Rails sigue creciendo y ya cuenta con un nuevo competidor. New Relic ha conseguido nada menos que 3,5 millones de dólares en una primera ronda de financiación, y tratará de hacerse hueco en un escenario hasta ahora dominado por FiveRuns (que, dicho sea de paso, acaba de publicar una entrevista a nuestro compañero Xavier Noria).

El producto de New Relic se llama RPM y, al menos en teoría, proporciona información que los desarrolladores pueden utilizar para detectar, diagnosticar y arreglar con rapidez los problemas de rendimiento de la aplicación. Por el momento, parece que el RM-Manage de FiveRuns incorpora bastantes más funcionalidades (seguimiento de bases de datos, Web daemon, etc.) pero habrá que esperar a las tarifas de New Relic para ver qué es lo que le interesa a cada empresa.

Como siempre, hay quien opina que no es necesario un servicio propietario para realizar estas funciones, y que hay recursos gratuitos suficientes, tipo Query Reviewer. En cualquier caso, el lanzamiento es interesante, no sólo por la inversión realizada (comparable con la de FiveRuns y Engine Yard ), sino porque demuestra que tanto los medios como los inversores están empezando a tener muy en cuenta los movimientos en el escenario Ruby on Rails. De hecho, la todopoderosa Teccrunch se hizo eco de la noticia.

Vía Ruby Inside.

Entrevista en Rails TakeFive

Friday, 2 de May de 2008

FiveRuns ha publicado la entrevista que me han hecho para la serie Rails TakeFive.

Sin perder de vista la visión de conjunto

Wednesday, 30 de April de 2008

Kelly Waters nos da algunas claves para no perder de vista la visión de conjunto (the big picture) durante el desarrollo de un proyecto ágil. Aquí os dejo una traducción libre:

“Cuando utilizamos un enfoque basado en el desarrollo ágil, no hay grandes especificaciones ni diseños inamovibles. El alcance del proyecto varía. Algunos requisitos evolucionan, y otros nuevos van emergiendo. Las funcionalidades crecen, cambian y desaparecen a lo largo de todo el ciclo de vida del proyecto. En este entorno variable, la cuestión es: ¿qué podemos hacer para no perder de vista la visión de conjunto?

Aunque el desarrollo ágil consiste, en gran parte, en trocear los objetos hasta conseguir pedazos pequeños y manejables -para obtener, por ejemplo, el product backlog y el sprint backlog- es muy importante no perder de vista el contexto global, para que nos sirva como guía y referencia a lo largo de todo el proceso.

Este contexto se nos presenta en 3 formas principales:

  • Contexto de negocio
  • Contexto de proyecto
  • Contexto de la solución

Visión de conjunto

Contexto de negocio

ALGUNAS PREGUNTAS ÚTILES: ¿Cuál es la visión de negocio? ¿Cuáles son los retos y las oportunidades desde el punto de vista del negocio? ¿Cuáles son los objetivos de negocio a corto, medio y largo plazo? ¿Quiénes son los clientes? ¿Por qué compran y para que utlizan las solución que vamos a desarrollar? ¿Qué les gusta y qué no les gusta del proyecto? ¿Quién es la competencia y cómo son sus soluciones?

Sin esta información global de contexto, cualquier equipo de desarrollo está trabajando con una gran desventaja. La gente de desarrollo puede ser muy innovadora y si los equipos de desarrollo cuentan con una visión interna real del contexto de negocio, pueden ser mucho más proactivos. Con esta información, es mucho mas probable que las soluciones innovadoras emerjan a la superficie.


Contexto del proyecto

Muchos de los elementos definidos en la fase de inicio de un proyecto tradicional siguen siendo importantes en un entorno de desarrollo ágil.

ALGUNAS PREGUNTAS ÚTILES: ¿Cuáles son los problemas específicos o las oportunidades que el proyecto intenta abordar? ¿Cuál es la visión para el proyecto? ¿Cuáles son los objetivos del proyecto? ¿Cuál es el enfoque? ¿Cuál es el coste previsto y el plazo de entrega? ¿Cuáles son los beneficios y cómo se van a conseguir? ¿Quién trabajará en el proyecto y cuál será su estructura?

Las respuestas a éstas y otras preguntas constituyen una guía de referencia importante para el equipo. Esta guía se hace más necesaria si cabe en un desarrollo ágil, en el que hay libertad para cambiar las cosas durante todo el proceso. Con esta información, el equipo dispone de algunos parámetros con los que trabajar, y tiene claro cuáles son los resultados esperados.


Contexto de la solución

He escrito varios posts sobre cómo escribir buenas historias de usuario. Me gusta que sean tan pequeñas, autoexplicativas y manejables. Hacen que las cosas resulten sencillas. Pero, ¿qué deberíamos hacer antes de llegar al detalle de las historias de usuario? Es importante enmarcarlas dentro del contexto global de la solución. Las siguientes herramientas pueden ayudarnos:

  • Mapa (roadmap) de producto de “alto nivel” (no entra en detalles). Utilizando una línea de tiempo amplia -por ejemplo, meses o trimestres- este mapa nos permite destacar las funcionalidades clave del producto y los diferentes hitos principales que se producen a lo largo del proyecto. A diferencia de un plano, un mapa de producto es indicativo y evoluciona a medida que las cosas cambian. Proporciona al equipo una estructura del plan de sprints, y ayuda a identificar las prioridades y a establecer los objetivos de cada sprint.
  • Visuales de alto nivel. Pueden ser wireframes o maquetas con las pantallas clave, un storyboard conceptual para el interfaz de usuario, etc. Sea cual sea su forma, este boceto de alto nivel debe mostrar cómo funcionará la solución desde la perspectiva del usuario. No hace falta que estos visuales especifiquen todas las pantallas, ni todas las funcionalidades. La solución final ni siquiera tiene que mostrar el mismo aspecto de los visuales (de hecho, casi nunca lo hace). Pero constituye una buena guía para arrancar el proyecto porque cubre los escenarios principales a los que se va a enfrentar el usuario-tipo.
  • Arquitectura (de alto nivel) de la solución. No hace falta que sea un diseño detallado. Lo que necesitamos es una arquitectura que nos sirva para entender las tecnologías clave, la estructura del producto, y cómo se comporta la solución desde una perspectiva técnica. Puede ser una imagen que vaya evolucionando. Algo así como el boceto que dibujamos en una pizarra al iniciar el proyecto, pero complementado con los detalles que vamos añadiendo a medida que el proyecto avanza y tomamos decisiones técnicas.


Resumen:
Un equipo de desarrollo ágil necesita trocear las cosas en pequeños fragmentos y hacer las entregas de manera incremental. Para hacerlo, resulta especialmente importante tener en mente el contexto general. Mi consejo es que utilices herramientas-guía de alto nivel, ligeras y muy visuales (objetivos del proyecto, mapa de producto, arquitectura de la solución), y las mantengas pegadas en la pared junto con las historias de usuarios y las tareas diarias.

Podéis leer el post original aquí.

La libertad y el usuario. Las 4 libertades esenciales del software libre según Richard Stallman

Thursday, 24 de April de 2008

Richard Stallman, gurú de la informática y genuino impulsor del software libre, pasó por Madrid hace unos días y dio una conferencia en la que habló sobre la libertad y el usuario. Aquí os dejo un resumen libre, basado sobre todo en la primera parte de la conferencia. Es un poco largo, pero creo que merece la pena. Esta es la controvertida visión de Stallman:

Sobre Richard Stallman. “En el año 83 lancé el movimiento de software libre. El objetivo era, primeramente, desarrollar un sistema operativo libre para que fuese posible usar una computadora en libertad. Este sistema se llamó GNU. Comencé su desarrollo en enero del 84. En el año 92 faltaba un componente importante, el kernel. Otro programador [Linus Torvalds] liberó un kernel que se llamaba Linux. La combinación del sistema completo GNU y el kernel Linux era un sistema completo y libre. Desde entonces es posible (más o menos) comprar un PC y usarlo en libertad, siempre que uses una versión netamente libre GNU Linux, y no instales otros programas privativos.”

Premisa. El software libre es aquel que respeta la libertad del usuario, en contraposición al software privativo, que sume a los usuarios en una situación de inhibición e impotencia. Inhibición porque los usuarios tienen prohibido compartirlo con los demás, e impotencia porque no poseen el código fuente y, por tanto, no pueden cambiar el programa ni saber qué es lo que el programa verdaderamente está haciendo.

Según Stallman, un programa de software es libre si proporciona al usuario las 4 libertades esenciales:

LIBERTAD 0. La libertad de ejecutar el programa como quieras.
LIBERTAD 1. La libertad de estudiar el código fuente del programa y cambiarlo para que haga lo que tú quieres que haga.
LIBERTAD 2. La libertad de ayudar a tu prójimo: es decir, la libertad de distribuir copias del programa a los demás cuando quieras.
LIBERTAD 3. La libertad de contribuir a tu comunidad, es decir: la libertad de distribuir copias de tus versiones cambiadas cuando quieras.

GNU oficial

Con estas 4 libertades, el programa es software libre. Sus usuarios son libres y el sistema social de su distribución y uso es un sistema ético que respeta la libertad del usuario y la solidaridad social de la comunidad. Si una de estas libertades falta o es insuficiente, el programa se convierte en software privativo, porque el sistema social de su distribución y su uso no es ético. Un programa privativo no es una contribución a la humanidad, sino un ataque. Es un trampa que intenta atraer a la gente para que ceda su libertad.

(more…)

Prohibido “Recomendar a una amigo”

Tuesday, 22 de April de 2008

Facilitar recomendaciones comerciales a través del correo electrónico es ilegal según la Agencia Española de Protección de Datos. No es posible enviar ningún mail con contenidos publicitario o promocional salvo que exista un consentimiento previo e informado del destinatario, algo que casi nunca sucede en los típicos “Recomendar a un amigo” de los sitios web.

Así aparece reflejado en una Resolución de la Agencia, del 20 de febrero de 2008, en la que se multa a una página web por ofrecer a los internautas la facilidad de remitir a la dirección de correo electrónico de un familiar o de un amigo un mensaje informativo invitando al destinatario a registrarse. La infracción ha sido considerada leve, pero muchos piensan que puede constituir un importante golpe para el marketing viral.

El envío de este tipo de correos electrónicos, aunque lo llevan a cabo los propios internautas, se realiza desde la dirección IP de la empresa sancionada, por lo que la Agencia estima que la página web es responsable.

Leer el artículo en El Economista.

La evolución de los medios.

Saturday, 19 de April de 2008

En el blog de Alberto estaba esta presentación con datos mas que interesantes.En tres palabras, más videos, mas participación y menos televisión.

Meeting de Rails en Barcelona

Thursday, 17 de April de 2008

Hoy hemos celebrado la reunión mensual de raileros en Barcelona, en las oficinas de Linqia.

Fuimos siete, Christian presentó algunos aspectos de escalabilidad de Linqia. Hablamos también del stack EC2/S3/SQS, y de git, entre otras cosas.

Hoy fui a la reunión con el Segway y una vez terminada improvisamos unas prácticas en Gran de Gràcia.

10 maneras en que Internet (tal y como la conocemos) puede morir

Sunday, 13 de April de 2008

Alistair Croll ha escrito en Gigaom un curioso post en el que hace una lista sobre las 10 maneras en que Internet -tal y como la conocemos- desaparecerá en el futuro. Aquí va una traducción libre:

“A menudo pensamos en Internet como una plataforma para la comunicación global, en la que la información fluye de forma libre, los innovadores pueden lanzar nuevas aplicaciones a voluntad, y todo el mundo tiene su propia voz. Pero es poco probable que la Internet de nuestros hijos se parezca a la que conocemos ahora. ¿Cómo puede morir Internet? Hay 10 posibilidades:

1. Alguien destruye los DNS (Servicio de Nombres de Dominio). Internet se basa en los DNS. Pero si alguien rompe el modo fundamental en el que encontramos los sitios web, ya no podríamos confiar en las URL’s nunca más. El Phishing -o fraude informático- sería fácil. Domina el DNS e Internet será tuya.

2. Ataque de una red de zombies. Un número incalculable de PC’s esclavos están esperando a la intentona de los hackers del lado oscuro. Matt Sergeant, de Message Labs, calcula que la red de bots está formada por entre 5 y 10 millones de equipos (aunque algunos rebajan bastante esta estimación). Hoy, los bots saturan nuestros buzones de correo con spam. Pero en el pasado, han sido utilizados para atacar empresas y países, y para chantajear a sitios web. Al final, es una carrera de armamento en el que solo una de las partes respeta las reglas.

3. Fallo masivo en la infraestructura física. Si un accidente con un par de cables en el Mediterráneo puede hacer que Internet deje de funcionar para cientos de millones de usuarios, imagina lo que podría conseguir un ataque intencionado.

Internet puede morir

4. Guerra por fragmentación. Desde Usenet, la gente se ha ido agrupando con aquellos que piensan igual que ellos. En su libro “The Big Switch”, Nicholas Carr cita un estudio según el cual el 90% de los enlaces originados en en el seno de la comunidad conservadora y liberal permanecen en el seno de esa comunidad. Algunas herramientas de enlaces de referencia pueden ser configuradas para mantener a los visitantes en sitios que mantienen su punto de vista. ¿El resultado final? Islas de gente que piensa lo mismo, cada vez más seguros de que sólo hay una respuesta correcta, la suya propia. Se acabaron los sueños de una comunidad global tal y como la imaginaron los creadores de Internet.

5. Un virus realmente bueno acaba con los routers. El mecanismo auto-sanador de Internet recae en el Border Gateway Protocol (BGP). Pero, ¿y si alguien se cuela en los routers? En una presentación de NANOG, en 2006, Cisco se concentró en los puntos vulnerables y concluyó que “los ataques más dañinos son causados por una mala configuración deliberada de un router en el que se confía”. Corrompe el BGP y no sólo impedirás que fluya el tráfico en Internet, sino que también dañarás nuestra capacidad de llegar a los routers para arreglarlos.

6. Las actualizaciones rompen el funcionamiento de las actualizaciones. Casi todo el software está diseñado hoy en día para parchearse y mantenerse actualizado. Pero a veces el proceso de actualización automática desencadena sus propios problemas. El 16 de agosto de 2007, Skype se cayó en lo que la compañía dijo fue un efecto colateral de una actualización masiva a Windows. Sólo es cuestión de tiempo que una actualización se convierta en una pieza fundamental del software, haciendo imposible que se actualice a sí misma, y dejando así sin servicio a millones de usuarios hasta requerir una intervención manual.

7. La Red deja de ser neutral. Si los proveedores empiezan a cobrarnos por el acceso a los sitios de la misma manera que hacen las compañías de televisión por cable con su servicio Premium, pronto encontrarás un cargo de Google en tu factura mensual. Esto ocurre ya con muchos móviles que incluyen servicios de Facebook o YouTube. Es, quizá, la muerte más odiosa, porque significaría el fin de la innovación: nadie sería capaz de lanzar el próximo Skype, Twitter o YouTube sin la aprobación de los proveedores.

8. Los abogados se meten en el ajo. Internet ha sido un experimento de libertad de expresión. Eso puede haber llegado a su fin. Incapaces de perseguir a los propios sitios, los abogados la toman con las compañías de hosting y las de registro. Es así como el grupo suizo de banca Julius Baer silenció al “chivato” de Wikileaks. Y una vez que hay un precedente, vendrán otros casos. La industria discográfica se está planteando si puede perseguir a los proveedores por hacer posible la violación del copyright. Esta es la ironía de la neutralidad de la Red: cuando las telecos empiezan a tratar a diferentes bytes de forma diferente, dejan de ser “proveedores comunes” y pueden ser responsables por lo que transmiten, incluyendo contenido ilegal. Así que tendrán que responder.

9. Jardines vallados. Muchos países ponen restricciones al uso de Internet. El firewall de China -que incluye 30.000 personas clasificadas por usos impropios- es un buen ejemplo. Internet es una herramienta de intercambio social y esta “revolución” podría asustar a cualquier gobierno. Imagina, por ejemplo, que el congreso de Estados Unidos prohibiese la pornografía online y bloquease los sitios para adultos (que constituyen el 18.8 % de las visitas en 2004 según Hitwise). En vez de una Internet global, regresaríamos a los estándares de decencia impuestos por los legisladores. Sería como Dirty Dancing una vez tras otra.

10. El ser humano acaba consigo mismo. Como señalaba la revista Discover hace unos años, tenemos muchas maneras de acabar con nosotros mismos, desde las armas nucleares hasta las plagas, pasando por un agujero negro creado por nosotros mismos mediante un acelerador de partículas. ¿Y qué sería Internet sin usuarios?

Internet ha cambiado de forma ya, dejando atrás sus aspiraciones iniciales de academia libre para convertirse en una plataforma comercial controlada por empresas y proveedores. En muchos sentidos, el tiempo transcurrido entre el nacimiento de ARPAnet en 1969 y el fin de Netscape el pasado febrero constituye simplemente un reducido período en la historia que la generación Facebook no olvidará.”

Podéis leer el post original aquí.

Como no podía ser de otra manera, hay quienes se han tomado con humor estas profecías un tanto catastrofistas. Esta es la versión de coña: 10 formas (y pico) en las que Internet podría morir

Clientes …. (2)

Monday, 31 de March de 2008

En un post anterior iniciaba una serie que ahroa seguiremos, frases reales de proyectos con clientes:

La de hoy también es buena:

” Tienes razón pero no me vas a convencer”

Paciencia.

Dibújalo antes de construirlo. Recursos de diagramación y más

Wednesday, 26 de March de 2008

No importa si eres un consultor IT, un analista de negocio o un diseñador web. “Dibujar” lo que tienes en la cabeza antes de lanzarte a redactar, a programar o a diseñar puede resultarte de gran ayuda. No hace falta que utilices lápiz y papel, claro. Hay otras maneras. Te sugerimos que aproveches los diferentes recursos de diagramación para abordar el proyecto con una visión más amplia y certera. Estos recursos te permitirán:

1. Asegurarte de que el planteamiento de partida tiene bases sólidas.
2. Te darán la oportunidad de “discutir” el proyecto hasta conocer mejor la visión de tu cliente.

Al fin y al cabo, es en ese estadio inicial cuando más sencillo y menos traumático resulta introducir cambios.

Te proponemos las siguientes herramientas:

Diagramas de flujo: Son esquemas que representan la estructura y el flujo de navegación de un sitio web o de una aplicación. Algo así como un “plano” en el que se muestran las conexiones y la interacción entre las diferentes partes de un sistema. El aspecto de los elementos es lo de menos mientras pueda comprenderse el flujo. Esta visión esquemática y de conjunto te permitirá sacar a la luz bastantes nudos y contradicciones que hasta el momento habían pasado inadvertidos.

DiagramaFlujoElemental

Wireframe o “maqueta”. Un wireframe es una representación esquemática de una página web. No muestra elementos gráficos, porque lo importante es establecer el contenido y el comportamiento de las diferentes páginas.

El wireframe puede ser más o menos detallado: se considera de baja fidelidad cuando se limita a representar aspectos generales, y de alta fidelidad cuando alcanza un gran nivel de detalle, por ejemplo, en el caso de una maqueta dinámica que permite, incluso, interactuar al usuario.

Wireframe

Tanto lo diagramas de flujo como las maquetas nos proporcionan una excelente oportunidad para “discutir” el proyecto con el resto del equipo y, por supuesto, con el cliente antes de empezar a programar y diseñar, de forma que los malentendidos y los cambios y modificaciones no resulten demoledores. En ambos casos, el aspecto de los diagramas es absolutamente secundario. De hecho, introducir elementos de diseño en esta fase suele consistir un grave error: el cliente enseguida centrará la discusión en las formas y colores, dejando de lado otros temas fundamentales.

Wireframe vs prototipo. Ojo. Un wireframe no debe confundirse con un prototipo. Hay una diferencia fundamental entre ambos: los prototipos se construyen para funcionar -aunque no cuenten con una funcionalidad completa- mientras que los wireframes o maquetas tienen como principal objetivo representar el sistema, y no tanto actuar. Como ya hemos comentado, podríamos realizar un wireframe de baja fidelidad con lápiz y papel, y sería perfectamente válido siempre que resulte comprensible.

EL PUNTO DE VISTA DEL USUARIO: OTRAS HERRAMIENTAS INTERESANTES

Especificaciones. Las especificaciones constituyen un sistema muy extendido para documentar, comunicar y conseguir un acuerdo con el cliente sobre el diseño de la aplicación. El problema es que, en el mundo del desarrollo web -convertido muchas veces en una carrera enloquecida- el exceso de documentación y una recogida de requisitos excesivamente reglada pueden eternizar el desarrollo de un proyecto. Y lo que nosotros buscamos es un desarrollo ágil. Por eso, dentro de la metodología ágil SCRUM han surgido herramientas alternativas a las especificaciones tradicionales. Una de las más consolidadas son las historias de usuario.

User stories/Historias de usuario.
Una historia de usuario es una forma de recoger los requisitos de un proyecto en tan sólo un par de frases. Esas frases se anotan en una pequeña cartulina o tarjeta para garantizar que los requisitos no crecen hasta hacerse inabarcables, y se formulan en un lenguaje corriente, para que tanto el equipo como el cliente pueda entenderlas a la perfección. El objetivo es capturar de forma rápida y efectiva los requisitos reales del cliente, sin perderse en montañas de documentación y procesos formales. De esta forma, en un entorno de cambio constante, los cambios pueden ser absorbidos sin que el proyecto se desplome.

Las historias de usuario se llaman así precisamente porque recogen el punto de vista del usuario. En su blog, Kelly Waters nos propone el siguiente sistema: Una historia de usuario debe centrarse en el QUIÉN, el QUÉ, y el POR QUÉ, no en el CÓMO. Por ejemplo, en un sitio web de empleo, dos de las historias de usuario serían:

  • Como persona en busca de trabajo, quiero buscar un empleo para progresar profesionalmente.
  • Como seleccionador de personal, quiero publicar una oferta de trabajo para encontrar a un nuevo miembro del equipo.

La estructura sería:
Como [rol de usuario], quiero [objetivo], de forma que pueda [motivación]

La importancia de la última parte -la que corresponde al POR QUÉ- no está tan acreditada, pero también es cierto que conocer la motivación del usuario puede darnos buenas pistas sobre sus necesidades.

Card sorting. Esta técnica de tarjetas resulta útil cuando se quiere construir una estructura de contenidos basándose en el punto de vista del usuario. Consiste en observar y analizar la forma en que los usuarios agrupan y asocian unas tarjetas etiquetadas con diferentes temas. Siguiendo el comportamiento y el orden de los usuarios se puede organizar la información del sitio web. Hay dos tipos de card sorting:

  • Abierto. Los usuarios pueden agrupar las diferentes categorías temáticas con total libertad, haciendo tantos grupos como crean necesario.
  • Cerrado. Se establece un número limitado de conjuntos, de forma que el usuario debe ubicar cada tema en uno de esos grupos. Por ejemplo, se establecen desde el principio los grupos “qué hacemos” “quiénes somos” “cómo lo hacemos” y el usuario debe incluir cada tema en una de esas 3 categorías.