Etiqueta: desarrollo sofware

Eventos en backbonejs

Una de las formas más interesantes de desacoplar código, vistas fundamentalmente, usando un framework MV* tipo backbone es aprender a usar correctamente los eventos y patrones asociados. Observer (pub/sub), Event Aggregator, Mediator, …

La mejor lectura al respecto que he encontrado es este post de Derick Bailey (creador de MarionetteJS), donde de forma muy ilustrativa examina distintas opciones finalizando con como hacerlo con eventos. Es recomendable también leer los comentarios, donde Derick responde a varias dudas de los lectores.

La sección sobre Eventos de Developing Backbone Applications explica bien como usar los eventos en general en backbone y esta otra sección revisita el post de Derick exponiendo la diferencia entre Event Aggregator y Mediator.

Pero para trabajar con Eventos de forma correcta además de los patrones y las especifidades de backbone es necesario conocer algunas técnicas y características de javascript relacionadas con el contexto. La siguiente selección de artículos puede ahorrarte un par de horas de quebraderos de cabeza:

Libro: Developing Backbone.js Applications

He terminado de releer estos días Developing Backbone.js Applications, escrito fundamentalmente por Addy Osmani con la colaboración de más gente vía pull-requests en github. Los primeros capítulos del libro (Introduction, Fundamentals, Basics) se leen muy rápido y dan una buena idea, no sólo de como usar backbone si no de porqué usar un framework MVC.

La idea de mezclar el uso concreto de la herramienta con explicaciones de más alto nivel de patrones se produce a lo largo de más capítulos del libro, por lo que uses backbone o no lo que aprendas te seguirá sirviendo. Esto creo que es el principal aliciente del libro, ya seas un programador novato e inexperto en backbone, o no, puedes aprovechar las explicaciones sobre patrones MV*, Mediator vs Event Aggregator, Desarrollo Modular, …

Otra de las cosas que me gusta del libro y que es muchas veces ignorada es que dedica un capítulo entero a testing. Tal vez demasiado centrado en explicar distintas herramientas (Jasmine, QUnit, Sinon) pero aún así d utilidad.

Algunos otros capítulos me dan la impresión de ser demasiado específicos, como aquellos dedicados a desarrollo para móviles y a otros frameworks construidos sobre backbone como Marionotte y Thorax. El capítulo sobre herramientas por ejemplo también es muy específico y al ritmo al que evolucionan en estos momentos ya se ha quedado desactualizado.

Salvando eso, creo que sigue siendo un libro muy recomendable.

Aitor Guevara hablando de la arquitectura de Ducksboard

Un vídeo algo antiguo (2013) en el que Aitor Guevara (CTO de Ducksboard) nos habla de cual era la arquitectura de Ducksboard en aquel momento. A pesar de que el vídeo dura más de una hora y media Aitor consigue hacer amena una charla técnica. No entra al mínimo detalle técnico pero si da una buena idea general. Responde sin rubor a preguntas como cual era el costo de la infraestructura que tenían en Linode (400$) o cuantos clientes de pago tienen.

https://www.youtube.com/watch?v=ArpNnabLqZE

Por el medio de la charla caen perlas del estilo de:

  • Usamos twisted para hacer aplicaciones asíncronas en python. ¿Conoceis nodejs? pues lo mismo pero tiene 10 años en lugar de 1.
  • Usamos backbone, porque tenemos un montón de javascript. Tenemos un montón no porque nos guste si no porque es lo que hay.

Otra de las cosas que más me gustan es la defensa que hace de PostgreSQL, que es el componente central de su infraestructura (especialmente hacia el minuto 50 pero en realidad lo hace en varios momentos). Hacia el minuto 44 explica como usan ellos backbone. La verdad es que aquí no me quedo muy claro desde donde servían el html, o si iba todo en los templates, porque el django del frontend en principio sólo actuaba como API Rest sirviendo JSON al navegador. Eso si, su django usa SQLAlchemy y no django-orm porque tenían cosas en el postgres que django-orm no soporta.

Los últimos minutos de la charla presenta un par de herramientas que «análisis del negocio» que también son de interés.

En este post además del vídeo están las transparencias.

Video: Aplicaciones en tiempo real con python y postgres

Una charla de como montar aplicaciones en tiempo real con python y postgres. Tiempo real entendido como notificaciones de un chat, hacer algo cada vez que se actulice una tabla de la bd etc,…

El vídeo se hace un poco largo, seguramente con las transparencias llegaba para hacerse una idea general. Pero aún así se hace interesante por alguna de las técnicas que emplea:

  • Aboga por no usar frameworks en python. Con las librerías de hoy en día es sencillo montar una API Rest gestionando las llamadas de bajo nivel directamente
  • Usa las funciones de postgres de LISTEN y NOTIFY que combinadas con un trigger permiten que código cliente (psycopg2) sean notificados cuando algo pasa en la base de datos (se modifica una fila o lo que sea) y actuén en consecuencia (provocar un cambio en el navegador mediante websockets)
  • Para simplificar la API y el diseño de la bd, los datos se guardan como tipos nativos postgres (varchar, boolean,…), y se usa la función de postgres row_to_json para recuperarlos una cadena de texto con formato json.
  • Usa httpie para probar la API Rest. Si alguna vez usaste curl para esto enseguida verás que está bien conocer httpie.
  • A pesar de que la idea principal de la charla es montar una aplicación en tiempo real con el mínimo número de dependencias (complejidad) el proceso de build que monta no parece trivial. pip para dependencias en python, nodeenv (una especie de entorno virtual para node que se integra con el virtualenv de python), bower para las dependencias javascript de cliente,… Todo ello orquestrado por un Makefile.
  • No muestra como hacer la parte del frontend, pero en todo caso el código está en su repo

Comentarios al artículo de Complejidad y Reversibilidad de Kent Beck

Andrés me pincha para que lea y comente el último post de Kent Beck en su muro de facebook. Como todo lo que escribe Beck hay que leerlo con atención y se pueden sacar lecciones interesantes. Pero este artículo en particular se me hace complicado de leer porque creo que mezcla demasiadas cosas a la vez. Comienza con una teoría general sobre sistemas complejos y luego salta a prácticas concretas de facebook para atajarla en distintos estadios del desarrollo sin pararse a explicar que técnicas tienen sentido en según que contextos. Analicémoslo por tanto atendiendo al artículo como dos partes separadas.

Complejidad y Software

Software complexity es un término con definición propia en el mundo académico. En la práctica todo desarrollador tiene una noción intuitiva de que es complejidad y debería tener como principio el atajarla. Beck explica alguno de los elementos de la complejidad y cuales de ellos se puede intentar mantener bajo control en un producto como facebook. La cuestión es, si en otro tipo de productos software se puede o tiene más sentido atacar otro frente distintos al de la irreversibilidad. Personalmente se escapa de mis conocimientos esta reflexión pero apunto algunos elementos para el debate:

  • Estados. Atendiendo al producto como un todo (hardware, acciones del usuario, red,..) seguramente será difícil de atajar. Si nos quedamos con las acciones (interacción) del usuario me recuerda a la diferenciación entre mapa y camino de la que se reapropió Andrés atendidendo a Verplank.
  • Interdependencias. SOLID, KIS, Patrones, Modularidad o cualquier práctica de buen diseño entiendo que ayuda a disminuirla a no ser que se me escape algo.
  • Incertidumbre. Supongo que es el más complicado. Usuarios usando la aplicación en formas no previstas. Requisitos cambiantes,…
  • Irreversibilidad. Nada que decir, es en el que se centra Beck.

Atajar la Irreversibilidad

La segunda parte del artículo habla de algunas de las técnicas que usan en Facebook para combatirla. Algunas pueden ser consideradas de modernas como el Frequent Pushes (¿Continuous Delivery?) y otras como el Code Review llevan con nosotros mucho tiempo. Beck las enumera todas juntas pero creo que intentar ponerlas bajo una clasificación más o menos habitual en factorías de software tradicionales puede ayudar a decidir cuales pueden ser aplicables en cada caso. Dejo fuera (IRC y Data-informed decisions)

  • Desarrollo
    • Development servers
    • Code review
    • Correlation
  • Pre-Producción / Testing
    • Internal usage
    • Staged rollout
    • Advance countries
    • Shadow production
  • Producción
    • Frequent pushes
    • Soft launches
    • Dynamic configuration
    • Right hand side units
    • Double write/bulk migrate/double read

Sin duda algunas de las técnicas como Staged Rollout es discutible en que fase van y son clasificables bajo esta óptica. La idea de intentar clasificarlas es sólo para poder compararlas con una forma de trabajo que nos resulte más cercana para a partir de ahí ver cuales podemos empezar a aplicar y en que punto de nuestro proceso.

Qué puedo aplicar y cómo si no soy Facebook

Más que técnicas concretas en realidad lo que Beck plantea es una cultura (o dos). El Desarrollo Ágil y el DevOp. Intentar aplicar alguna de sus estrategias de forma separada sin abrazar la filosofía subyacente creo que sólo produce desgaste. Con esto no quiero decir que tengas que hacer pair programming y tener un devop en tu equipo, pero sí al menos comprender que hay valor en los principio que proponen.

Para mi los pasos en ese camino son tres: Tests, Automatización y Monitorización.

Monitorización. Si no estás midiendo lo que sucede rendimiento, comportamiento de usuarios, … saber lo que está pasando o cuando un cambio no tiene el efecto previsto.

Automatización. Si hacer un despliegue es costoso e implica varios pasos, se harán pocos , se tardará más tiempo en tener feedback, se introducen más posibilidades de error y no hablemos de lo que supone revertir un mal cambio. Si no se automatizan los procesos se vuelve más complicado que todos los desarrolladores tengan el mismo entorno y este sea parecido a producción.

Tests. Probablemente la piedra angular. Estoy leyendo Working Effectively with Legacy Code, y en los primeros capítulos expone algunas cuestiones sobre tests que tienen relevancia para la «reversibilidad». En el libro comparan trabajar sin tests a hacer acrobacias sin red, y expone dos formas de introducir cambios en un sistema.

Changes in a system can be made in two primary ways. I like to call them Edit and Pray and Cover and Modify. Unfortunately, Edit and Pray is pretty much the industry standard. When you use Edit and Pray, you carefully plan the changes you are going to make, you make sure that you understand the code you are going to modify, and then you start to make the changes. When you’re done, you run the system to see if the change was enabled, and then you poke around further to make sure that you didn’t break anything. The poking around is essential. When you make your changes, you are hoping and praying that you’ll get them right, and you take extra time when you are done to make sure that you did.
Superficially, Edit and Pray seems like “working with care,” a very professional thing to do. The “care” that you take is right there at the forefront, and you expend extra care when the changes are very invasive because much more can go wrong. But safety isn’t solely a function of care. I don’t think any of us would choose a surgeon who operated with a butter knife just because he worked with care. Effective software change, like effective surgery, really involves deeper skills. Working with care doesn’t do much for you if you don’t use the right tools and techniques.
Cover and Modify is a different way of making changes. The idea behind it is that it is possible to work with a safety net when we change software. The safety net we use isn’t something that we put underneath our tables to catch us if we fall out of our chairs. Instead, it’s kind of like a cloak that we put over code we are working on to make sure that bad changes don’t leak out and infect the rest of our software. Covering software means covering it with tests. When we have a good set of tests around a piece of code, we can make changes and find out very quickly whether the effects were good or bad. We still apply the same care, but with the feedback we get, we are able to make changes more carefully.

En esencia, durante el desarrollo tener tests te permite probar y si no funciona revertir a coste casi cero. En producción el coste de revertir no es cero (al menos sin aplicar otras de las técnicas mencionadas) pero al menos te permite detectar errores de forma temprana.

 

 

 

 

Compilando y depurando un plugin de ejemplo para gvSIG 2.1 desde Eclipse

Joaquín del Cerro ha publicado un artículo explicando como compilar y depurar un plugin de ejemplo para gvSIG 2.1 con NeatBeans. He adaptado sus instrucciones para Eclipse que es mi IDE habitual. Este artículo no es tan detallado como el suyo así que seguramente tendrás que consultar los dos, especialmente los pasos previos que comenta Joaquín para que todo funcione.

Una vez que tenemos los «previos» realizados, creamos un nuevo workspace en eclipse, por ejemplo workspace-gvsig-landregistry.

Nos aseguramos de que tenemos instalados en eclipse:

Abrimos la perspectiva de eclipse de SVN Repository Exploring, desde Window -> Open perspective -> Other, o cualquier otro de los sitios desde los que se puede abrir.

Y añadimos el repositorio del plugin desde File -> New -> Repository Location o el icono correspondiente. Como URL usaremos:

http://devel.gvsig.org/svn/gvsig-plugintemplates/org.gvsig.landregistryviewer/trunk/org.gvsig.landregistryviewer/

Seleccionamos el repositorio que acabamos de añadir y en el menú contextual escogemos Check out as maven project

Si no tenemos el conector de maven-svn instalado, nos pedirá instalarlo. En la ventana previa al checkout nos aseguraremos de que la opción «All projects» está activada

Puede tardar un ratito en descargar, sobre todo si tiene que descargar muchas dependencias. Cuando acabe, pasamos a la perspectiva Java y ya tendremos los proyectos correspondientes al plugin configurados en el workspace.

Si no tienes la opción de Build automatically activada, haz un build all. A continuación pon un punto de ruptura para comprobar que todo funciona correctamente en el punto que indica Joaquín (método createWindow de la clase LandRegistryViewerExtension).

Tras lanzar gvSIG en modo debug,


./gvSIG --debug --pause

configuramos el debugger. En Debug Configurations, añadiremos una nueva configuración del tipo Remote Java Application

En name pondremos lo que queramos, por ejemplo org.gvsig.landregistryviewer.app, en project org.gvsig.landregistryviewer.app.mainplugin y en port 8765. Si antes de crear la configuración de debug seleccionamos el proyecto org.gvsig.landregistryviewer.app.mainplugin en el package explorer nos rellenará automáticamente name y project.

Al darle a debug debería abrirse gvSIG y pararse la ejecución en el punto que hemos marcado.

Aptana. Un IDE para desarrollo web

Hace unos meses escribía en el blog que estaba buscando un IDE para desarrollo web el cliente. Al final no me he dedicado tanto a web-cliente como pensaba y he estado jugando más en la parte de backend sobre todo con nodejs.

Dado que es el primer IDE (para web) que pruebo y tampoco tengo gran experiencia en desarrollo web me resulta difícil hacer una buena revisión, pero aquí van algunos pros y contras de programar Javascript en Aptana desde el punto de vista de alguien que viene de Java+Eclipse.

Contras

* El debugger de Apata es incompatible con la última versión de firebug por lo que debes instalar una más antigua. Tuve unos cuantos problemas intentando instalarlo y no he sido capaz de hacer un cambio en el código y recargar la página sin tener que relanzar todo firefox a través del debugger. En resumen el debugger no he sido capaz de hacerlo funcionar de una forma cómoda y he vuelto a firebug.
* El preview de la página cuando está puesto el código del google analytics hace que se cierre aptana.
* Para que el Code Assist funcione correctamente, hay que tener unos ficheros de documentación en un formato especial (ScriptDoc), y practicamente ninguna librería los tiene.
* En el «Save Action» sólo se pueden quitar los trailing spaces, estaría bien que permitiera al menos reformatear el código
* No es capaz de navegar por ocurrencias correctamente. Si marco una variable no soy capaz de moverme entre las apariciones de esa variable (Ctrl + .) como en java. Tampoco es capaz de encontrar desde donde se llama a una función (aunque este es un problema genérico de los lenguajes dinámicos). Aquí hay un listado de funcionalidades aunque no está del todo actualizado. No he probado a documentar las funciones con ScriptDoc, tal vez así el editor sea más inteligente.
* La documentación es escasa
* Así como cuando programo en Java todo el equipo usa Eclipse, con web no pasa lo mismo. Así que la idea de tener que crear workspaces y proyectos dentro del workspace llenos de directorios de configuración ocultos me resulta conceptualmente incómodo.

Pros

* Me gusta la consola interactiva. Puedo probar código sin tener que abrir la consola javascript del navegador.
* Me gusta el Content Assist de html, creo que funciona bastante bien.
* Al margen del problema con el debugger, me gusta la funcionalidad de preview ( https://wiki.appcelerator.org/display/tis/Side-by-Side+Previewing ). Me permite poner en dos pestañas paralelas mi código (html, css, js) y el navegador empotrado de aptana, al salvar uno de los ficheros la previsualización se recarga automáticamente. Está bien para ir viendo como queda. Una pena que no haya encontrado forma de debuguear desde el preview.
* Me gusta el «Go To Declaration (F3)», aunque se equivoca de vez en cuando, si por ejemplo has estado haciendo pruebas en otro fichero, poniéndolo a las funciones el mismo nombre puede saltar a la que no es.
* Me gusta la buena integración (heredada de eclipse) con el escritorio. Poder copiar un fichero en el explorador de archivos y pegarlo en una vista de aptana, o copiar un snippet de código de una página web y pegarlo en Aptana creando automáticamente un nuevo fichero
* El sistema de templates para no arrancar proyectos como una página en blanco funciona bien.
* Es relativamente fácil, extender la funcionalidad a través de Snippets y Rubles. Aunque los Rubles hay que escribirlos en Ruby

Enlaces de interés sobre aptana

* Una revisión genérica de Aptana.
* Documentación sobre html, css, y javascript

Conclusiones

Me da la impresión de que la mayoría de opiniones favorables vienen de gente que lo uso en su día cuando no había opciones libres/gratuitas mejores. Además da la impresión de que el proyecto está muerto desde que lo compró Appcelerator.

Creo que el caso de uso más favorable para Aptana es que ya estés usando el IDE en el backend (ruby, php, python) y sólo toques ocasionalmente el cliente por lo que no te merece cambiar de entorno.

Trabajar con Word (docx) y Excel (xls y xlsx) desde Java

Iconos Word y Excel de MS OfficeEn Cartolab hemos trabajado ultimamente en procesar y generar documentos de Excel (xls y xlsx) y de Word (docx) desde Java. Tras probar algunas librerías open source las que estamos usando son:

Apache POI Spreadsheet para hojas de cálculo de Excel. Es fácil de usar y funciona bien tanto para los formatos binarios antiguos de xls (Excel 97-2007) como para xlsx (Excel 2007 OOXML). El How-To y la Quick Guide de la web son suficientes para empezar a escribir código.

Docx4j para documentos docx (OpenXML de Word 2007). La mejor forma de usarla es crear un documento vacio o con las cabeceras y pies de página desde Word o LibreOffice y definir en él los estilos. Desde nuestro código abrimos el documento y vamos añadiendo nuevos párrafos u otros elementos asignándole los estilos que hemos definido mediante el método addStyledParagraphOfText(styleID, text);. El styleID lo obtendremos consultado el fichero styles.xml que está comprimido dentro del docx. Si tenemos que hacer cosas más elaboradas el código se complica bastante pero al menos permite hacerlas. Para arrancar puedes leer como substituir placeholders por tu propio contenido, este otro artículo un poco más general y los ejemplos de código que vienen con la librería.

Para trabajar con documentos .doc de Word también probamos con Apache POI pero es complicado de usar y el resultado no es demasiado bueno. Así que por ahora no tenemos una alternativa válida para este formato.

En algún otro momento también hicimos pruebas con:

  • JasperReports que está muy bien para generar pdf pero el odt y el word lo saca maquetado en forma de tablas por lo que no nos valía.
  • iText. Que en versiones antiguas de la librería permitía sacar los resultados en rtf y era sencilla de emplear. Pero las últimas versiones se ha creado una nueva librería que no hemos probado todavía.

En esta pregunta de StackOverflow dan más alternativas. ¿Alguien usa otras librerías, preferiblemente open source y gratuitas, distintas a estas?

Organizar los ficheros de routes en nodejs – expressjs

Una de las tecnologías que estamos probando en Cartolab para aplicaciones web es nodejs con express como framework. Hay un montón de tutoriales de como empezar a usarlos, pero a poco que escribas empiezas a preguntarte como organizar el código, y ahí empiezan los problemas. express es un framework no opinativo, es decir proporciona un montón de utilidades pero da liberar total al usuario sobre como mezclarlas, así que se van desarrollando distintos modos de hacerlo.

La primera pregunta en mi casa sobre organizar el código fue acerca de los ficheros bajo el directorio routes. Podemos entender las routes de express como el equivalente al controlador en ese patrón llamado MVC que cada framework implementa como quiere, o viéndolo de otro modo como el mapeo entre una url y una función.

Vamos a ver cuatro estrategias distintas, cada una con sus ventajas e incovenientes.

Todo en app.js

La versión que se suele emplear en los tutoriales de iniciación. Escribimos en un único fichero todo el código de la aplicación.

  • Poco código boilerplate
  • Añadir una nueva url implica tocar un sólo fichero
  • Nada reusable
  • Sólo válido para proyectos pequeños

Es tan sencillo como escribir el mapeo antes de crear el servidor y usar funciones anónimas para la lógica


app.get('/', function(){res.send('root page'});

Mapear en app y la lógica en ficheros distintos

Este es el segundo ejemplo más habitual. Las url se definen en el fichero principal y las funcionalidades se agrupan en distintos ficheros bajo el directorio routes.

  • Añadir una nueva url implica tocar como mínimo dos ficheros
  • Favorece la reutilización, pero siempre debemos colocar las url a mano
  • Implica escribir más código que en el anterior y perder legibilidad

A pesar de que es muy habitual ver esto no me gusta porque no ganamos demasiado, y tener que hacer cambios en dos ficheros acaba introduciendo errores.


// app.js
var routes = require('./routes');  // Coje el fichero ./routes/index.js por defecto
var user = require('./routes/user');

app.get('/', routes.index);
app.get('/users', user.list);


// routes/user.js
exports.list = function(req, res){
res.send("respond with a resource");
};


// routes/index.js
exports.index = function(req, res){
res.send("root page");
};

Hacer el objeto app global y derivar todo hacia los ficheros de routes

Evitamos declarar app como variable local, para poder usarla en el resto de ficheros sin tener que preocuparnos de pasar parámetros. El código queda muy limpio pero se dificulta el testing y se pueden introducir bugs difíciles de detectar.

A mi me gusta esta aproximación cuando tenemos poco código y queremos hacer algo rápido, pero hay que ser consciente de los problemas que tiene.

  • No es una muy buena práctica hacer app global, en el siguiente punto vemos una mejora. Pero al hacerlo así obtenemos código más legible
  • Es bastante modular (excepto por hacer app global)
  • Es bastante legible
  • Hay separación de conceptos, cada fichero se encarga de unas determinadas url y funcionalidades

Referencias

Veamos como quedaría la implementación


// app.js
app = express(); //IMPORTANT! define the global app variable prior to requiring routes!
require('./routes');


// routes/index.js
require('./main');
require('./users');


// routes/main.js
app.get('/', function(req, res) {
res.send("root page");
});


// routes/users.js. list() could be an anonymous function, this is only for showing it in another way.

function list(req, res) {
res.send("user list");
};

app.get("/users", list);

Inyectar app en los ficheros de routes

Es similar al ejemplo anterior, pero el objeto principal es inyectado en los controladores en lugar de usarlo como una variable global. Sacrificamos un poco de legibilidad (hay que meter bastante código «inútil») pero a cambio ganamos en modularidad y testabilidad.

Veamos una posible implementación, teniendo en cuenta que este código no lo he visto en ningún sitio, lo he escrito a partir del artículo de dailyjs y podría tener algún otro problema.

A mi esta es la aproximación que más me gusta, cuando el código aumenta y no nos queremos ir a soluciones más complicadas.


// app.js
var app = express();
// ...
app.use(express.json());
require('./routes')(app); // Must be called after app.use(express.json()) and urlencoded;


// routes/index.js
module.exports = function(app) {
require('./main')(app);
require('./users')(app);
};


// routes/main.js
module.exports = function(app) {
function index(req, res) {
res.send("root page");
};
app.get('/', index);
};

Otras estrategias

Hay estrategias más complejas, que por ahora no me ha hecho falta probar.

Qué es Twitter Bootstrap y cómo aprender a usarlo

Generar una plantilla básica sobre la que empezar un proyecto web que tenga en cuenta los distintos navegadores y tamaños de dispositivos consume mucho más tiempo del que debería. Para minimizar este problema durante los últimos dos o tres años han surgido varios frameworks de diseño web. Si te dedicas a esto y no has estado debajo de una piedra este tiempo, sin duda habrás oído hablar de twitter-bootstrap, que es el que se ha hecho más popular.

¿Qué es bootstrap?

Bootstrap o twitter-bootstrap es un framework creado originalmente por dos desarrolladores/diseñadores de twitter para acelerar el diseño de nuevas aplicaciones web.

El framework proporciona clases css y código javascript para definir el layout de la página, crear componentes que respondan a eventos y estilizar los elementos html más habituales. Estos ejemplos están hechos con la versión 2, pero valen para hacerse una idea.

Podemos decir que los principios en los que se basa la última versión (la 3) son:

  • Responsive Design: Que según mi definición particular consiste en que la página trata de «hacer lo correcto» al ser visualizada independientemente del dispositivo y tamaño de la pantalla. El término fue acuñado por Ethan Marcotte en 2010.
  • Mobile first: Al contrario que en la versión 2, en la 3, el diseño responsivo es la opción por defecto al trabajar con bootstrap
  • Cross Browser: Trata de ser compatible con la mayoría de navegadores.
  • Integración con jQuery: Está muy integrado con jquery para el que define nuevos plugins
  • Buenas prácticas: Trata de emplear algunas de las prácticas más extendidas en cuanto a usabilidad, uso de css3/html5, organización del código, …

¿Qué me aporta bootstrap?

Si eres desarrollador con poca experiencia en diseño te proporciona una forma muy rápida de crear un layout responsivo básico de la página en la que empezar a meter tu código.

Si eres diseñador, obtienes una enorme cantidad de clases CSS que personalizar a tu gusto, sin tener que partir de cero.

Si quieres aprender a hacer las cosas mejor, es un compendio de buenas prácticas.

Aprendiendo a usar bootstrap

La documentación de la página de bootstrap debería ser tu principal fuente de información, sobre todo porque el resto de documentación tiende a quedar más desactualizada, aún así, hay una serie de tutoriales que a mi me han resultado más útiles para empezar, sobre todo porque te permiten coger ideas más generales de lo que permite hacer.

Los enlazo en el orden que creo que merece la pena seguirlos:

  1. Tutorial de w3resource: Hay partes del tutorial que están con la versión 2, pero cubre muchos aspectos
  2. Understanding twitter bootstrap 3. También se le escapa alguna etiqueta de la v2 como el container-fluid, pero en general te permite aprender a diseñar un ejemplo básico.
  3. Una introducción a los componentes que proporciona bootstrap como el scrollspy o las ventanas modales
  4. Actualizado 31/Agosto/2015. En Udemy acaban de publicar un post con una muy buena introducción a boostrap.
  5. Bootstrap 3 Tutorial – An Introductory Course | Udemy. Una serie de videotutoriales muy chulos donde emplean unas cuantas clases que no he visto en otros sitios. Es de pago pero barato. Con los recursos anteriores seguramente ya no te será necesario este curso, así que mira alguno de los vídeos de muestra antes de comprarlo

Otros recursos

Desde que nació bootstrap han ido apareciendo un montón de recursos que sacan partido a este framework

Conclusiones

En un par de días puedes revisar los enlaces que se proporcionan en este artículo, y refactorizar alguna web sencilla que tengas para que use bootstrap. Será un tiempo bien empleado que recuperarás con creces.

No he probado otros frameworks del estilo, pero supongo que serán parecidos, cada uno con sus fortalezas y debilidades. Si le tienes manía a bootstrap, escoge otro, pero desde luego es una herramienta a meter en tu caja si eres desarrollador web.