cambrico.net

Artículos destacados, Enero 2012

pedro — Sun, 05 Feb 2012 22:24:50 +0000

Primera batería de destacados de 2012:

De Drupal

Detrás de las cámaras: Drupalcon Munich.
Extendiendo Facet API.
Introducción a Drupal Commerce.
Productos y displays de Commerce en el mismo formulario usando subform.
Ctools modal + Field Collection para mejora la experiencia de usuario.
Atajo de urls git para projectos en drupal.org.

De otras cosas

La guía más simple y sencilla sobre Git.
Estupenda analogía sobre los fallos en la estimación de proyectos IT.
Las 10 principales razones por las que la gente deja sus trabajo.

Si tenéis curiosidad, podéis consultar los destacados de otros meses.

categorías:

destacados

Rebase en Git

pedro — Thu, 19 Jan 2012 22:48:49 +0000

Está claro que Git es el control de versiones de moda, los tiempos de CVS quedan ya muy lejanos y la gente, poco a poco va migrando del sistema más utilizado, subversion, a sistemas distribuidos como puedan ser Git, Mercurial o Bazaar.

Como Drupal hace un tiempo que está utilizando Git para sus repositorios oficiales, la mayoría de drupaleros hemos optado por esta opción y a la hora de controlar nuestro código, hay muchas alternativas de uso, siendo Gitflow una de las que más convence.

El término rebase en Git tiene dos acepciones muy diferenciadas que voy a intentar resumir aquí y que pueden resultar confusas.

Rebase utilizado como parámetro de pull

Cuando hacemos git pull, nos traemos los cambios del repositorio que elijamos o tengamos configurado, y uno de los parámetros que podemos utilizar es rebase:

git pull --rebase

¿Qué hace esto? Al realizar un pull estamos haciendo un fetch y justo después un merge, pasándole la opción rebase, git intentará traer todos los cambios y después aplicar nuestras modificaciones encima en lugar de intentar hacer un merge desde el punto en el que estábamos, esto hará que nuestro histórico tenga mucho mejor aspecto. Veámoslo en acción.

Para hacer la prueba me he hecho un fork del repositorio Spoon-Knife en github, cuyo propósito es hacer tests.

Clonamos y accedemos:

git clone git@github.com:pcambra/Spoon-Knife.git cd Spoon-Knife

Utilizando una herramienta de visualización o git log, podemos ver la situación actual.

Para mostrar las diferencias entre git pull y git pull --rebase, voy a hacer un checkout de un cambio antiguo, crearé un fichero nuevo y le haré commit.

git checkout ed12290ba92e1b0a932f5250e06699a0abf47e84 touch mifichero.txt git add mifichero.txt git commit -m "Commit inicial de un fichero vacío"

Con lo que el repositorio queda así:

Ahora ya que intencionadamente de alguna manera hemos forzado un conflicto, metiendo un commit en un estado "antiguo", si hacemos un pull (recordemos que es fetch + merge), va a hacer un merge automático de nuestros cambios a partir del estado en el que lo hemos hecho, quedando el árbol de nuestro repositorio un tanto lioso:

Ahora bien, si hacemos lo mismo:

git checkout ed12290ba92e1b0a932f5250e06699a0abf47e84 touch mifichero.txt git add mifichero.txt git commit -m "Commit inicial de un fichero vacío"

Pero en lugar de hacer simplemente pull, hacemos git pull --rebase, primero hará el fetch+merge y luego aplicará nuestros cambios encima, dejándonos una estructura más legible que seguro que agradecemos en el futuro.

Nota: Git no siempre va a poder hacer git pull --rebase, por descontado si hay conflictos, no sobreescribe el código sino que nos dejará editar y entonces forzará hacer un merge manual.

Podéis ver un ejemplo muy similar en este post y también es altamente recomendable esta explicación de Randy Fay.

Comando rebase

El comando rebase hace algo muy diferente; cuando tenemos una serie de commits que queremos asociar juntos, normalmente por la misma razón que el ejemplo anterior, mantener una historia de commits un poco más limpia, podemos utilizar git rebase.

git rebase -i BRANCH/HASH

Pongamos el ejemplo anterior

Y le añadimos un fichero, hacemos commit, pero por ejemplo nos damos cuenta que el fichero está vacío, o no nos acaba de gustar y hacemos múltiples commits, generando un histórico similar a este:

Para juntar todos estos commits en uno solo, podemos utilizar git rebase, el procedimiento sería localizar la rama o el hash anterior al primer commit que queremos agregar y usarlo como parámetro de git rebase:

git rebase -i bdd3996d38d885e18e5c5960df1c2c06e34d673f

Nota: El hash se puede averiguar usando git log o normalmente con cualquier herramienta gráfica de manejo de git.

Lo que nos llevará a una pantalla similar a esta, ya que le hemos indicado con -i que es interactivo. Este fichero lista todos los commits que hemos seleccionado para agregar para que elijamos qué queremos hacer con ellos.

Los commits que queramos conservar los dejamos como pick y los que queramos agregar los marcamos como squash:

Después guardamos y nos llevará a un segundo proceso, en el que nos muestra todos los mensajes de los commits a agregar.

Aquí deberemos escribir el comentario que queramos conservar para nuestro commit agregado.

Guardamos también este fichero y voilà, el resultado es un único commit con el mensaje que hayamos introducido en el paso final y todos los cambios juntos.

Git rebase en más detalle.

categorías:

git

control de versiones

Artículos destacados, Diciembre 2011

pedro — Tue, 03 Jan 2012 23:53:23 +0000

Artículos más interesantes de Diciembre.

De Drupal

Combinando Drupal, HTML5 y microdata.
Git submodule aplicado a Drupal.
Features tools: separando elementos en Features para actualizar.
Crear nodos referenciados con popups en Drupal 7.
Estrategias prácticas de testing en Drupal vs Upal.
Ubercart 3 vs Drupal Commerce.
OpenLayers Plus.
Exportables en módulos de Drupal: Ctools o Features.
Features component alter.

De otras cosas

Psicología del comercio electrónico social.
Modelo de trabajo con Git: gitflow.
Cómo son de grandes los arrays en PHP.
UDF en MySQL.
Who broke the build?
Varnish: detectando y redirigiendo según el dispositivo.
Respectando tu tiempo y el de los demás.

Si tenéis curiosidad, podéis consultar los destacados de otros meses.

categorías:

destacados

2011 en el bolsillo

pedro — Sat, 31 Dec 2011 00:07:17 +0000

Cerramos 2011 y siempre he considerado que es una buena práctica echar la vista atrás a modo de retrospectiva y análisis. Aunque es bastante cierto que me he pensado mucho hacerla este año puesto que ha sido bastante complicado a todos los niveles, he tenido grandes cambios a nivel laboral, pero también bastante agitación personal durante todo el año.

No quiero que este post sea el típico resumen de éxitos empalagosos, así que contaré directamente lo que me ha pasado mes a mes

Enero. Después de la release party de Drupal 7, el mes empezó con un cambio drástico laboral, a mediados de mes empecé mi andadura con Commerce Guys en un sprint de código que duró una semana (fotos). A final de mes viajé a Ginebra con Lorena (fotos).

Febrero. ¡Más viajes!, los Drupal Developers Days de Bruselas fueron un gran evento a principio de Febrero (fotos). En Junio de 2012 lo celebraremos en Barcelona ¡y la vamos a armar bien gorda!.

Marzo. De nuevo en la carretera, para la Drupalcamp de Lisboa (fotos) donde hago una presentación por primera vez en inglés (que sale de aquella manera) y nos dio tiempo a hacer algo de turismo (fotos). También presenté en el Ecomm retail. Una semana en Paris en un sprint y formación de Commerce.

Abril. Termino de dedicar el 100% de mi tiempo a contribuir en Drupal Commerce para empezar trabajo en cliente en un proyecto nuevo. Aprovecho el ir a las oficinas de Paris para pasar la semana santa con Lorena allí. A final de mes empiezo a encontrarme enfermo y acabo por terminar ingresado.

Mayo. Me paso medio mes en el hospital y otro medio de baja en casa. No hay mucho más que contar, un mes para olvidar.

Junio. Desde drupal.cat organizamos el Drupal day de Barcelona (fotos), y estoy muy satisfecho con el resultado. Acabo el quinto curso de inglés de la EOI. Volviendo poco a poco a trabajar.

Julio. La Drupalcamp empieza a organizarse y va a ocupar gran parte de mi tiempo durante los siguientes meses. Tengo la oportunidad de retomar gran parte de las contribuciones en drupal.org que estaba empezando a hacer. Commerce reorder y Commerce Feeds. Además, mi "viejo" macbook tiene ahora un nuevo dueño :).

Agosto. Acudo a la Drupalcon Londres, lo que significa hacer el primer viaje después de haber sido ingresado, y presento un par de BOFs. Aprovechamos para visitar la ciudad (de nuevo), ver el Stonehenge y Nottingham y estrenar la Nikon D3100 (fotos). Decido que hacer coincidir las Drupalcon con vacaciones no es un buen negocio.

Septiembre. Se celebra la primera Drupalcamp sobre comercio electrónico en Lucerne y presento un par de sesiones, que salen mucho mejor que la de Lisboa. Se abre la inscripción de socios en la Asociación Española de Drupal (por fin). Mes de locos organizando la Drupalcamp. Hago un cambio personal muy importante que hace tiempo que consideraba hacer.

Octubre. Empezamos con la Drupalcamp (fotos), que personalmente creo que sale muy bien a pesar de que no todo el mundo esté de acuerdo. Cambio de proyecto y empiezo a trabajar para otro cliente en una web de un volumen importante. Se nos va Xana.

Noviembre. Drupalcamp Toulouse (fotos), acudo aunque no presento nada. Termino proyecto y puedo dedicar algo de tiempo aquí y allá a Drupal Commerce y contribuciones relacionadas. Anunciamos los Drupal developer days en Barcelona para Junio de 2012. Una de mis sesiones propuestas sale aceptada en la drupalcon de Denver.

Diciembre. Tiempo entre proyectos (50%). Sale a la luz el primer proyecto para cliente en el que he trabajado (este). Doy una charla en decharlas en la UJI de Castellón y aprovechamos para visitar Valencia el fin de semana (fotos).

Entre mis objetivos para 2011 estaba el viajar, contribuir más y fomentar más Drupal.

Mi único objetivo para 2012 es aprender, de verdad, a conciliar trabajo, comunidad y familia.

categorías:

personal

objetivos

Video y resumen del taller de Drupal Commerce en decharlas

pedro — Mon, 19 Dec 2011 18:45:33 +0000

Hace unos días estuve en la Universidad Jaume I de Castellón dando una charla-taller sobre Drupal Commerce en el marco de charlas de tecnología organizado por decharlas, hubo unos 65 asistentes, entre los que había desde público novato a gente que ya está montando tiendas online con Commerce o considerando hacerlo.

La charla introductoria dura unos 40 minutos y en ella presento las características principales de Drupal Commerce, el video ya está disponible:

Después de la charla pasamos a una demo bastante completita en la que repasé con ejemplos la teoría de la presentación anterior. Hay ejemplos rápidos, complejos e incluso de alguna tienda ya en producción. También hay video disponible.

Del taller que vino después no hay video, porque fue bastante práctico y la gente se puso los monos de trabajo para hacer ejemplos y trabajar un poquito con Commerce, muchísimas gracias por la ayuda en el taller a David, Sergio y por supuesto la de Alessandro por montar el taller con la gente de decharlas.

categorías:

drupal:

Gestión básica de imágenes en Drupal 7 y Views 3

pedro — Wed, 07 Dec 2011 10:43:56 +0000

Una de las necesidades básicas que cubre Drupal 7 es la gestión de imágenes en el propio core, y de la que Views 3 se aprovecha para poder mostrar listados con imágenes utilizando los estilos que podemos definir y personalizar. En esta entrega de la serie que vengo haciendo sobre Views 3 para Drupal 7 veremos cómo crear estilos de imágen y cómo utilizarlos en nuestras vistas.

Para los que vengáis de Drupal 6, los estilos de imagen no será nada nuevo, básicamente es la inclusión del módulo ImageCache en el core de Drupal 7.

Qué son estilos de imagen

Los estilos de imagen en Drupal 7 son el equivalente a los presets de Imagecache para Drupal 6, es decir, ofrece diversos "marcos" con diferentes tamaños, dimensiones u otros efectos para las mismas imágenes originales. Podemos subir una imagen de grandes dimensiones en un contenido y mostrarla en miniatura en unos listados y en tamaño grande en el contenido principal sin la necesidad de subir varias imagenes editadas a los tamaños que buscamos.

Es una funcionalidad imprescindible para facilitar la edición de contenido que incluya imágenes ya que homogeniza los tamaños y permite cuadrar mucho mejor el diseño. Además, si necesitamos cambiar el tamaño de las imágenes de una determinaza zona de nuestra web, podemos simplemente modificar los estilos sin tocar las imágenes originales, con el consecuente ahorro de tiempo. También tiene ventajas a la hora del rendimiento de la web ya que "cachea" los tamaños de las imágenes cuando se accede a estas por primera vez y los siguientes visitantes verán la imagen con las dimensiones correctas. Para más información podéis visitar este artículo sobre Imagecache que hice hace un tiempo, es para Drupal 6, pero la mayoría de conceptos siguen vigentes.

Creación de estilos de imágenes en Drupal 7

Para crear estilos de imágenes, simplemente debemos acceder a Configuración en nuestra instalación de Drupal

Y una vez aquí encontraremos el apartado Estilos de imagen dentro de Medios Audiovisuales.

En esta pantalla podremos ver todos los estilos que ya tenemos configurados, con el núcleo de Drupal ya vienen varios, como thumbnail para miniaturas o large para imágenes grandes, además de otros que puedan haber sido creados por otros módulos. Para crear los nuestros, hacemos click en Añadir estilo.

A continuación le debemos dar un nombre y accederemos a la pantalla de configuración.

Lo realmente importante de la pantalla de configuración de estilos son los efectos/acciones que podemos seleccionar, con el core vienen unos cuantos que suelen ser suficientes, pero hay muchos otros que los complementan y que comentaré más adelante en el artículo. Los básicos son:

Recortar: Hace un "crop" de toda la vida, le ponemos las dimensiones y recortará al tamaño indicado perdiendo el resto de la imagen.
Desaturar: Convierte la imagen a blanco y negro.
Redimensionar: Se le dan valores para alto y ancho y la imagen se redimensiona a ese tamaño pudiendo quedar alargada o achatada si no respetamos las proporciones originales.
Girar: Admite un valor en grados para girar la imagen y un color de fondo para el trozo que queda sin contenido.
Escala: Se le da un valor para ancho, y/o un valor para alto y escalará la imagen, si solamente se pone un valor, respetará las proporciones orginales.
Escalar y recortar: Es el más útil de todos, se le da un valor para ancho y/o un valor para alto y combinará las acciones de escalar y recortar para tener la imagen al tamaño deseado con las proporciones buscadas.

La característica más potente de los estilos de imagen es que se pueden combinar múltiples acciones en un solo estilo, por ejemplo recortar y poner en blanco y negro, el orden se define por la interfaz drag&drop que proporciona el core de Drupal.

Ejemplo de configuración con Escalar y recortar

Los estilos de imagen se utilizan en múltiples sitios en la administración de Drupal, en este ejemplo veremos cómo usarlos con Views, pero es también muy importante destacar que en la gestión de presentación de los tipos de contenido también vamos a disponer de estos estilos para las imágenes.

Utilización con Views 3

Vamos a ver cómo utilizar e integrar esta magnífica funcionalidad de Drupal en nuestro módulo favorito últimamente: Views 3. Crearemos una vista de contenido en la que mostraremos un estilo de imagen, yo voy a usar uno que he creado, llamado "article" y que tiene un efecto de Escalar y recortar a 600x200.

El primer paso es acceder al interfaz de Views en Estructura » Vistas y hacer click en Agregar nueva vista

Esta pantalla ya nos tiene que resultar familiar después de seguir los artículos introductorios a Views 3 para Drupal 7, por ejemplo el de cómo crear una vista simple. Resumo la configuración que he hecho para nuestro ejemplo:

La vista la he configurado con el nombre "03 Lista de lugares con imagenes" y he dejado tanto el nombre del sistema como el título y la ruta en las que genera automáticamente.
He marcado que queremos mostrar contenido de tipo Lugar, ordenado de más nuevo a más viejo.
Creo una página para el ejemplo con las opciones de título y ruta por defecto, podéis cambiarlas a vuestro gusto.
El formato de presentación es lista HTML, que recordemos que mostrará contenido dentro de un tag ul con elementos li.
Necesitamos mostrar el contenido con presentación de tipo campos para poder configurar los estilos de imagen.

Una vez hecho esto, le damos a Continue & edit para seguir configurando nuestra vista y veremos el interfaz completo de Views, en este ejemplo solamente vamos a usar los campos, por defecto ya nos configura automáticamente el título, que normalmente querremos que esté ahí, pero necesitamos un campo de imagen, así que le damos al enlace de agregar.

Y como vimos en el artículo sobre agregar campos a una vista, podemos buscar y filtrar por lo que necesitemos, en nuestro caso el campo de imágenes para los lugares.

Lo seleccionamos y le damos a Añadir. Entonces veremos las opciones de un campo de tipo imagen, la que nos interesa es la que pone Estilo de imagen, en la que podemos encontrar todos los estilos de imágenes que tengamos disponibles en nuestro sitio, si creamos más estilos desde el interfaz, Views los detectará automáticamente y nos los ofrecerá para los campos de tipo imagen.

Para nuestro ejemplo, he sleccionado el estilo "article", que está configurado con el efecto Escalar y recortar a 600x200 píxels, también he seleccionado que vincule al contenido, otras opciones son que vaya sin enlace o enlace a la propia imagen original.

Para la vista final, he añadido el campo de descripción y he quitado las etiquetas de todos los campos. Una vez hayamos configurado nuestra vista, ojo, no os olvideis de darle a Guardar, podemos probar nuestras páginas con el enlace de Ver página o View page que encontraréis en cada Display:

Y este es el resultado final:

Todo es más fácil en un video

Estilos de imagen en Drupal 7 con Views 3 from Pedro Cambra on Vimeo.

Efectos y acciones adicionales: Recursos

Cuando vayáis dominando el uso de estilos de imagen, os recomiendo profundizar en el tema con algunos módulos adicionales que extienden la funcionalidad de los estilos en el núcleo de Drupal 7.

La primera recomendación y más importante es Imagecache Actions, que ha conservado su nombre de la versión de Drupal 6 pero que tiene versión para Drupal 7. Este módulo proporciona efectos y acciones adicionales muy interesantes, como marcas de agua, texto sobre imagen, manipulaciones de color, etc.
Los módulos para imágenes en popup Colorbox, Thickbox y Lightbox2 (entre otros) proporcionan soporte para estilos de imagen y permiten elegir en qué estilo se abre una imagen, galerías, etc.
Si lo que necesitais es seleccionar el area de cortado de la imagen al crear contenido, podéis probar Image javascript crop o EPSA Crop.
Módulos como smartcrop e Imagefield focus toman la decisión de cuál es el mejor area de recortado en base a algoritmos inteligentes.
Si necesitáis mostrar galerías, os recomiendo Gallery Formatter.
Imagecache proportions permite seleccionar diferentes estilos para imagenes cuadradas, alargadas o ensanchadas.

Podéis encontrar las vistas y recursos utilizados para este tutorial en este enlace de descarga, las instrucciones de uso están en el propio README del fichero o en el repositorio de github.

Si os está gustando la serie de tutoriales y/o tenéis sugerencias para futuros videos y artículos, por favor, no dudéis en dejar un comentario.

Crédito de la foto, Stuck in Customs. Thanks for sharing using Creative Commons!

categorías:

drupal

drupal:

views

7.x

Artículos destacados, Noviembre 2011

pedro — Sun, 04 Dec 2011 17:22:44 +0000

Recopilatorio de artículos de Noviembre:

De Drupal

Administrando drupal en remoto con drush.
Drupal vs Joomla vs Wordpress a nivel de seguridad.
Crear un plugin para Feeds con Feeds tamper.
Construyendo plugins para FacetsAPI con Ctools.
Malabarismos con variables usando Context.
Cómo crear pedidos de Drupal Commerce programáticamente.
Método para añadir soporte para Color en una plantilla.
Actualización de Drupal 6 a 7 usando Migrate y también usando Drush.
Cómo instalar de forma simple ApacheSolr 3.x para Drupal 7.
Menús multilingües en Drupal 7 e iniciación a multilenguaje en Drupal 7.
Formularios personalizados y paso a paso en perfiles de instalación para Drupal 7.
Guía básica de Drupal Commerce.

De otras cosas

Los cupones incrementan el abandono en el momento de checkout.
Novedades de PHP 5.4.
Cómo programar una extensión de Google Chrome.
Formulario de upload con barra de progreso en HTML5.
Arrays más rápidos en PHP.
Análisis del estado del comercio electrónico en España enfocado a los métodos de pago.

Si tenéis curiosidad, podéis consultar los destacados de otros meses.

categorías:

destacados

Drupal Commerce el 12 de Diciembre en decharlas

pedro — Tue, 29 Nov 2011 09:03:51 +0000

El próximo 12 de Diciembre estaré como ponente en una charla introductoria sobre Drupal y un taller sobre Drupal Commerce en la Escuela Superior de Tecnología y Ciencias Experimentales de la Universitat Jaume I de Castellón organizado por la gente de decharlas. El evento será de 16h a 20h.

El plan es hablar un poco primero sobre Drupal, qué es y cómo se utiliza, casos de éxito, ejemplos, demos... y después introducir Drupal Commerce. También pasaremos a la acción, veremos cómo crear una tienda, manejar productos, usar la interfaz para modificar el comportamiento para ajustarlo a nuestras necesidades, consejos, recomendaciones de módulos contribuidos, también resolveré dudas y todo a lo que nos de tiempo. Lo vamos a pasar en grande aprendiendo Commerce.

Si estáis por Castellón, os podéis apuntar gratis en la página de inscripción (plazas limitadas).

También estaré el 1 de Diciembre presentando un caso de éxito en la sesión mensual de drupal.cat en el Citilab.

categorías:

drupal:

Barcelona Drupal developer days 2012

pedro — Sun, 27 Nov 2011 21:11:17 +0000

Tengo el placer de anunciar oficialmente que Barcelona será la sede del evento europeo Drupal developer days en Junio de 2012. Si os interesa drupal, tanto a nivel profesional como aficionado, no estaréis en mejor sitio los días 15-16-17 de Junio.

¿Qué son los Drupal developer days?

Durante 3 días el Citilab de Cornellà se convertira en la capital de Drupal a nivel internacional, cientos de drupaleros europeos se desplazarán a Barcelona para pasar unos días compartiendo conocimientos, haciendo comunidad y pasandolo en grande.

Habrá sesiones y talleres dirigidas por drupaleros de primer nivel, sprints de código, traducción, networking, cerveza y la mejor compañía. En 2011 han sido en Bruselas, con más de 600 asistentes.

¿Y si quiero colaborar?

Puedes contactar conmigo o con Ramon Vilar, y también a través de drupal.cat. ¡Nos hacen falta muchas manos!

Estad atentos a la web oficial porque en breve pondremos más novedades.

categorías:

drupal

drupal:

eventos

drupal.cat

Empiezo un proyecto: ¿debo elegir Drupal 6 o Drupal 7?

pedro — Thu, 10 Nov 2011 20:20:09 +0000

Una de las preguntas más recurrentes estos días es si utilizar Drupal 6 para nuevos proyectos o directamente lanzarse a la piscina y montar un Drupal 7. Podéis encontrar este mismo dilema planteado en los grupos de drupal.org, y en otros foros de la materia con tantas opiniones como respuestas y comentarios. Estos días el debate se ha reactivado y como llevo tiempo pensando en ofrecer mi visión del tema, os plantearé una serie de escenarios y mi opinión sobre cual es la mejor elección para cada uno.

¿Así que ya has considerado todas las opciones de software libre y privativo para montar tu aplicación web? si estás por aquí, es que has tomado la decisión correcta: Drupal, ¡enhorabuena!, ahora queda una decisión igual o más difícil, ¿debería usar drupal 6 o drupal 7?.

Podría resumir este artículo de la forma que sugiere @rvilar en twitter:

Pero prefiero ofrecer una reflexión un poco más profunda y razonada, así que vuelvo a preguntar: ¿debería usar drupal 6 o drupal 7? La respuesta depende, mayoritariamente, de dos factores: El perfil del proyecto que estás a punto de empezar y el tuyo propio o el de tu empresa.

Hay algunos criterios que yo considero "reglas de corte" para ambos perfiles y que a mi modo de ver la elección está muy clara.

Tipo de proyecto

Proyecto personal o web propia con intenciones educativas. Si tu proyecto es un hobbie, o tu motivación principal es aprender Drupal, no lo dudes, Drupal 7 es tu opción, aprenderás mucho más y este aprendizaje será más duradero que si usas Drupal 6. Además de ahorrarte solucionar muchos problemas de Drupal 6 que ya vienen resueltos en Drupal 7.
Proyecto de comercio electrónico. Si estás haciendo una tienda online, no hay ninguna duda, Drupal Commerce es un proyecto mucho más maduro y estable en este momento para Drupal 7 de lo que nunca lo fue Ubercart para Drupal 6 o 7. Mucho más flexible, extensible y limpio, encontraréis grandes ventajas nada más comenzar. Más en mi sesión sobre Commerce de la Drupalcamp Spain 2011.
Proyecto enfocado al rendimiento. Hay muchos proyectos de alto volumen de visitas (algunos de MUY alto volumen) que usan Drupal 6, por ejemplo SceneBeta, Idealista News o En Buenas Manos. Perdón, ¿he dicho Drupal 6?, estos proyectos no usan Drupal en sí, sino Pressflow, un fork de Drupal orientado a la performance. Y casi todos los cambios que aporta, junto a otros muchos enfocados a la escalabilidad han sido ya incluidos de base en Drupal 7, soporte maestro-esclavo, gestión de sesiones anónimas, etc.

Perfil de desarrollador o empresa

Ya dedicado y especializado en Drupal. Si tu perfil es de empresa/desarrollador con ya recorrido en Drupal, no debes dudar ni un momento en empezar tus próximos proyectos en Drupal 7, acaba ya con tus frustraciones y sufrimientos provocados por peleas con temas como la intenacionalización, integración de javascript, CCK, views... y empieza nuevas luchas con espíritu renovado: entities, fields api, ajax, views (otra vez); te lo pasarás mejor. Si quieres ver un resumen de las novedades a nivel técnico, os recomiendo las slides de mi presentación en la Drupalcamp Spain 2011: "Desarrolladores, bienvenidos a Drupal 7". Además tendráss la oportunidad de colaborar y ayudar al proyecto y a la comunidad drupalera mejorando, completando o incluso migrando módulos y código contribuido. Dos ejemplos propios:
- En su momento tomamos la decisión de migrar uno de los proyectos propios de Neurotic: marujeo.com a Drupal 7, y al principio fue duro (hace bastantes meses que se hizo la migración, de aquella ni había salido la versión estable), pero por el camino aprendimos un montón, migramos MySQL Report y More Comments a Drupal 7, además de proveer algunos parches a otros proyectos para que ahora otros pueden disfrutarlos.
- La migración a Drupal 7 de cambrico.net ha ocurrido hace pocos días, pero también me ha servido para migrar GetClicky que ahora tiene una versión para D7.
Novato, pero que quiere especializarse en Drupal. Es prácticamente el mismo caso que si fuera un proyecto personal, si estás empezando con Drupal con la intención de quedarte, Drupal 7 es la apuesta más segura y la que tiene más recorrido. Aprenderás cosas nuevas y te costará mucho menos tiempo que aprender Drupal 6 y luego actualizar los conocimientos y el trabajo realizado. Además, el sistema base sobre el que estás construyendo se quedará obsoleto mucho más tarde. Tened en cuenta que Drupal 6 dejará de tener soporte en el momento que Drupal 8 vea la luz.

Efectivamente todas estas consideraciones tienen algunos peros, por supuesto.

Tomemos otro criterio: el tamaño del proyecto. Podemos simplificar y dividir los proyectos en tres tamaños: los proyectos pequeños, que serían aquellos que apenas requieren personalización de desarrollo, alguna cosilla de theming y que podemos estimar en un mes o menos. Los proyectos medianos estarían entre uno y tres meses y seguramente tendrán varios módulos propios y bastante personalización a nivel de plantilla. Y luego están los grandes proyectos, cuyo desarrollo implica más de tres meses y muy probablemente "fuerza" un mantenimiento continuo posterior.

Proyectos pequeños: Casi con total seguridad todos los elementos necesarios para completar este tipo de proyectos tengan ya versión en Drupal 7, ¿por qué entonces no usar código más actualizado y mejorado? Muchos mantenedores de módulos están centrándose en Drupal 7 y por supuesto, la mayoría de nuevas contribuciones empezarán a ni siquiera tener versión para Drupal 6. A la larga estos proyectos necesitarán migrarse, así que, como he comentado más arriba, algo desarrollado en Drupal 7 durará más sin tener que actualizar versión.
Proyectos medianos: Este es un caso en el que puedo entender elegir Drupal 6, si estamos manejando un proyecto con un plazo muy ajustado y un presupuesto parecido, pero con mucha funcionalidad (esta es la definición de proyecto mediano en Drupal, en realidad) y nuestro equipo no está acostumbrado a lidiar con Drupal 7, puede que no podamos asumir desarrollarlo en la nueva versión. Sobre todo si hay algunos módulos imprescindibles que no están completos o no parecen muy estables. Aún así, esta decisión tiene un riesgo importante, si eliges Drupal 6 de forma recurrente porque no te "atreves" con Drupal 7 debido a que no has trabajado antes con él, puedes acabar tardando demasiado en actualizarte y corres el riesto de quedarte obsoleto más rápido de lo que crees. En el caso de que en la planificación de tu proyecto se haya conseguido dejar algo de margen, no dudes en empezar con Drupal 7.
Grandes proyectos: Seguramente el punto más controvertido, puesto que mucha gente todavía está recomendando Drupal 6 para grandes proyectos. Personalmente me parece un error. Los grandes proyectos implican una gran cantidad de desarrollo y sobre todo un mantenimiento posterior, y es en esta segunda parte donde Drupal 7 gana muchísimos puntos, Drupal 7 será simplemente más mantenible, los módulos irán tendiendo a actualizarse y desarrollarse más en Drupal 7 y Drupal 6 irá poco a poco, cayendo en el olvido. Hay otro par de razones por las que usar Drupal 7, la primera de ellas es que puede llegar el momento en el que el proyecto se alarga tanto (o alguna de sus fases en desarrollo) que ya haya salido Drupal 8 (recordemos que el plan de release de D8 hoy por hoy es una incógnita) y estemos publicando algo totalmente obsoleto y fuera de soporte de seguridad. La segunda es un poco más "intangible", y relacionada con el Software Libre, con grandes proyectos open source, viene gran responsabilidad y tendrá mucha más utilidad ayudar a la comunidad en Drupal 7 que en Drupal 6.

Os recomiendo este artículo de la empresa finlandesa Mearra, del que he ~~robado~~ sacado estos dos gráficos.

Coste del desarrollo en Drupal

El grafico ilustra el coste de desarrollar en Drupal 7 vs Drupal 6 (y Drupal 8). Cuanto más tiempo pasa, más caro se hace el desarrollo en D6 y más se abarata en D7. Al principio, usar D7 es solo para "valientes" puesto que tienes que mantenerte al día con los cambios en el core (que no han sido pocos) y el coste acaba siendo terrible, de la misma magnitud que la ayuda y poder de decisión sobre las nuevas funcionalidades, un claro ejemplo es Examiner.com cuyo equipo ha aportado una cantidad de apoyo tremenda para que Drupal 7 haya sido posible.

Coste del mantenimiento en Drupal

El mantenimiento a largo plazo de un proyecto en Drupal 7 es mucho más barato que uno en Drupal 6, y llegará un momento en el que el coste de mantener un Drupal 6 se dispare y obligue a que se migre a Drupal 7 o incluso Drupal 8. Esto, sumado a lo que he comentado más arriba, sobre las releases de los módulos, cada vez veremos menos módulos para Drupal 6 y los que haya estarán menos mantenidos y no se beneficiarán de las nuevas actualizaciones.

Otros criterios y consideraciones

Internacionalización: El componente multilenguaje es uno de los más importantes a considerar, Drupal 7 tiene grandes mejoras en este aspecto, podéis ver las ventajas de Drupal 7 en esta presentación de Ramon Vilar de Ymbra (cat). Si el proyecto tiene un fuerte componente multilingüe tendréis que evaluar si os compensa usar Drupal 7 con las evoluciones que trae, por otro lado podéis encontrar algunos módulos adicionales que todavía no están listos.
Las versiones -dev no son malignas: Uno de los argumentos recurrentes que he visto para no utilizar Drupal 7 es que muchos módulos están en versiones de desarrollo o betas. Aunque hay artículos que recomiendan no usar versiones -dev (de desarrollo), alphas o betas, se debe evaluar cada caso, ya que las versiones -dev en drupal.org no son estilo "nighty builds", sino que suelen ser bastante funcionales a no ser que el modulo indique lo contrario, normalmente las versiones de desarrollo incluyen mejoras y correcciones de errores de las estables así que hay que perderle el miedo a hacer pruebas. Y para que no me acuseis de irresponsable: estas pruebas hacedlas siempre, siempre en entorno controlado.
Proyectos en producción: Ya para finalizar, si vuestro proyecto ya está online en Drupal 6, es posible que todavía no sea el momento de actualizarlo, sobre todo si tiene mucha funcionalidad o es un proyecto muy voluminoso en cualquier aspecto (usuarios, visitas...), aunque casi todos los puntos anteriores se podrían aplicar a una actualización dentro de 6 meses o 1 año. Eso sí, si tenéis una tienda online con Ubercart en Drupal 6, os recomiendo echarle un vistazo y experimentar con el módulo Commerce Migrate que provee una herramienta automatizada para traspasar los datos desde Ubercart a Drupal Commerce.

¡Ya podéis empezar a darme palos en los comentarios! ¿Vosotros cómo lo véis? ¿Habéis empezado ya proyectos en Drupal 7? ¿o seguís estancados en ~~la edad de piedra~~ Drupal 6?

Firmado: Pedro Cambra, que, a 11 de Noviembre de 2011 lleva 11 meses desarrollando en Drupal 7.

Foto cortesía de laurie.mcgregor. ¡Thanks for sharing in CC!

categorías:

drupal: