La primera versión de Wordpress fue lanzada hace ya 10 años. Quizá este CMS ha sido uno de los responsables del nacimiento de muchos blogs. Sin desmerecer otras plataformas como Blogger o otros CMS de publicación como Drupal, sin duda Worpress es una de las herramientas más usada para publicar en blogs, incluso para crear web de todo tipo.

Fue un 27 de Mayo de 2003 cuando se presentó oficialmente la versión 0.70, por parte de su creador Matt Mullenweg. Completamente libre y con licencia GPL era una evolución de B2/Cafelog. Después llegaron los miles de plugins, librerías y plataforma libres basadas en Wordpress, como Lighpress.

Muchas empresas usan Wordpress como gestor de contenidos como CNN, Pepsi, Yahoo, Adidas, BBC, Dell, Nokia o Adobe. No es de extrañar ya que se calcula que el 15% de las web en el mundo están construidas con Wordpress. La versión más descargada es la 3.5 (la última actualmente). Matt Mullenweg puede enorgullecerse que se han realizado hasta la fecha más de 66 millones de instalaciones de su plataforma.

Aprovechando el recopilatorio realizado por Ayuda Wordpress, enlazamos las distintas versiones por las que ha ido pasando Wordpress a lo largo de su historia. Sin contar las revisiones de seguridad, pero ya sabéis que casi nadie se libra de esos errores.

• Versión oficial de lanzamiento: 0.70
• WP 1.0 “Miles Davis” Enero 2004
• WP 1.2 “Charles Mingus”. Mayo 2004
• WP 1.5 1.5 “Billy Strayhorn”. Febrero 2005
• WP 2.0 “Duke Ellington”. Diciembre 2005
• WP 2.1 “Ella Fitzgerald”. Enero 2007
• WP 2.2 “Stan Getz”. Mayo 2007
• WP 2.3 “Dexter Gordon”. Septiembre 2007
• WP 2.5 “Michael Brecker”. Marzo 2008
• WP 2.6 “McCoy Tyner”. Julio 2008
• WP 2.7 “John Coltrane”. Diciembre 2008
• WP 2.8 “Chet Baker”. Junio 2009
• WP 2.9 “Carmen McRae”. Diciembre 2009
• WP 3.0 “Thelonious Monk”. Junio 2010
• WP 3.1 “Django Reinhardt”- Febrero 2011
• WP 3.2 “George Gershwin”. Julio 2011
• WP 3.3 “Sonny Stitt”. Diciembre 2011
• WP 3.4 “Grant Green”- Junio 2012
• WP 3.5 “Elvin Jones”. Diciembre 2012
• WP 3.6 en breve

Se ha creado una web oficial para celebrar este décimo aniversario y animando a la gente a compartir con el hashtag #wp10 cómo te ha cambiado la vida. Seguro que a muchos blogger y desarrollador tienen mucho que decir.

Sitio web | Wordpress
Más información | WP 10 aniversario

Hablamos poco de CMS en este nuestro/vuestro blog Genbeta Dev. A ver si nos enmendamos. Para empezar hoy os presentamos un CMS llamado Bolt cuya consideración está subiendo como la espuma entre la comunidad developer de buena parte de Europa ya que no sólo se centra en una buena experiencia para el editor o el usuario final sino que también se preocupa de hacer más fácil la vida para el desarrollador, aquel que se tiene que calentar la cabeza creando nuevos módulos, funcionalidades y themes (o adaptando los ya existentes a los requisitos de los clientes).

Bolt, como la mayoría de los CMS, está desarrollado en PHP aunque con la novedad de hacerlo a través de un framework basado en componentes de Symfony2 llamado Silex (aunque su nombre se parezca mucho a mi apellido no tenía el gusto de conocerlo hasta hoy). Además se puede conectar indistintamente a MySQL, SQLite o PostgreSQL (lo que le da flexibilidad) y utiliza el generador de templates Twig (también basado en Symfony2 y de la misma empresa que Silex) para que el código resultando sea limpio y fácil de trastear.

Como no podía ser de otra forma, Bolt se trata de software libre y cuenta con una licencia MIT. Además cuenta con una buena documentación para desarrolladores y puedes forkear (neolengua rules!) su repositorio de Github y darle tu toque personal.

Habrá que ver si puede competir con gigantes de la talla de Wordpress, Drupal o Joomla pero desde luego siempre viene bien que haya más tipos de pescado en la lonja para la salud del medio.

Vía | Bolt (a través de un tuit de @aNieto2k)

CMS es el acrónimo de Content Management System, lo que en el idioma cervantino viene a significar Sistema para la Gestión del Contenido. Drupal es un framework pero a su vez es un CMS y muchas veces los desarrolladores olvidan (olvidamos) esto último, nos centramos en mil y una historias y dejamos un poco de lado que la acción de publicar contenido sea una experiencia agradable y productiva. Spark es una distribución todavía en fase alpha para Drupal 7 (y en un futuro para Drupal 8) cuyo objetivo es esto último.

Surgido de algunas de las mentes más brillantes de la comunidad, a Spark se le empieza a conocer como el Pressflow (una distro muy popular y centrada en mejorar el rendimiento por defecto de Drupal) para la experiencia del editor y se centra en tres grandes áreas específicas:

• Edición in situ del contenido
• Herramientas más flexibles para el posicionamiento del contenido
• Una administración más amigable para terminales móviles

Además de todo lo relacionado con la integración multimedia y la gestión de flujos.

Los vídeos (como el que encabeza este post) muestran un gran potencial (la demo no tanto, pero no hay que olvidar que está en una fase muy temprana todavía) y pueden hacer pensar incluso en un Wordpress killer que pueda llegar a amenazar el dominio de WP en el mundo de la blogosfera y los nuevos mass media. Veremos a ver que depara el futuro.

Vía | drupal.org
Sitio | Spark Drupal
En Genbeta Dev | Omega, responsive design también en Drupal

Dos grandes eventos se han solapado este fin de semana en Barcelona. Por un lado ha estado el legendario festival Sonar. Por el otro se han celebrado los Drupal Developer Days, uno de los eventos más importantes de Drupal a nivel internacional enfocado al desarrollo. De hecho había primeras figuras mundiales de la comunidad Drupal y empresas multinacionales de postín. Vamos, un lujo y allí (en el Drupal Developer Days, no en el Sonar) ha estado Genbeta Dev con un reportero de excepción… bueno, no, miento, conmigo, que de excepcional tengo bien poco. Podría haceros una espectacular reseña pero en los tiempos de Twitter todo se va contando al momento y lo mejor es recuperar esos tuits y que os hagáis una idea de lo que allí se coció sábado y domingo tanto en las charlas y sprints como en todo lo que rodeó al evento.

(Aviso que al ser un workshop de carácter internacional la gran mayoría de tuits son en inglés aunque alguno hay en español y lo mismo hasta alguno en catalá)

Y eso fue todo lo que los Drupal Developer Days Barcelona 2012 han dado de sí. Nos vemos en el próximo evento.. ¡y recordad saludarme si me veis, que no muerdo (no siempre)!

Foto | Joan Martinez Serres
Más info | Drupal Developer Days Barcelona 2012
En Genbetadev | Drupal Day, profesionales de Drupal codo a codo un día en Barcelona
En Genbetadev | Codemotion España 2012, lo que se dijo en Twitter

Este es el tercer capítulo de la miniserie sobre Branching. Que se ha compuesto de Labeling, Branching y este, Manos en la masa. Y que trata sobre técnicas de división del desarrollo en el repositorio de código que nos haga más fácil el manejar la complejidad inherente a toda construcción de aplicaciones de software.

Este ejemplo lo voy a mostrar en Visual Studio 11 beta contra un Team Foundation Service, pero es muy similar el realizarlo en Git, Mercurial o SVN. Lo importante no es la herramienta, si no tener claro que el uso de estas técnicas nos hace crecer en la madurez de nuestros equipos y nos facilita y prepara para cuando las cosas se tuercen que es casi siempre.

Haciendo un branch

En la ventana que se me abre, veo mi directorio de carpetas de proyectos, en donde abro la de GenbetaDev.

Aquí me encuentro la carpeta troncal Trunk de mi desarrollo y de la cual quiero hacer una nueva rama. Para ello pulso con el botón derecho encima del nodo del cual quiero que salga la rama, y en el menú contextual selecciono “Branching and Merging”.

En el menú desplegable selecciono la opción “Branch”, y se me abre una ventana en donde le pongo un nombre en el repositorio a la carpeta que va a contener la nueva rama; qué versión del código original quiero copiar en el Branch (el último, una etiqueta específica, una fecha, etc.); y si quiero descargar la nueva rama en mi workspaces actual o convertirla en mi código por defecto.

A continuación me solicita que haga un mapeado de la carpeta del repositorio de código a mi disco duro. Es decir, en qué carpeta local voy a guardar el código almacenado en el Branch. Y aquí te voy a dar un consejillo.

En desarrollos medios o pequeños, sin mucha complejidad, yo utilizo la misma carpeta para el Trunk y los Branch. Así me evito modificar el código en la rama inadecuada por no darme cuenta de cual solución estoy abriendo. Puede que no sea la mejor práctica, pero a mi me funciona muy bien para evitar errores.

Una vez realizado esto, pulsamos el botón de “Map” y el sistema se pone a realizar el branching de nuestro código. Observándose en el explorador del repositorio, cuando finalice el proceso, nuestra nueva rama y el que está configurada como solución por defecto.

Fundiendo ramas

Para ello, desde la ventana del explorador del repositorio, pulso con el botón derecho sobre la rama que quiero fundir con otra, y escojo “Merge”. Abriéndose la ventana de un asistente en donde debo escoger cual es la rama destino para realizar la actualización y cual es la versión de código que nos queremos llevar.

Acto y seguido el TF Service se pondrá a trabajar y añadirá y modificará los ficheros de forma automática, siempre que sea posible. Y en el caso de que no lo pueda hacer porque la modificación tiene posibilidades de no hacerse correctamente, entonces nos marca el Merge como manual y debemos de utilizar la herramienta de comparación de código para completar la unión.

Pero de esta herramienta hablaré en el próximo capítulo,

Más información | Visual Studio Team Foundation Server Branching and Merging Guide Git. Magia Con Los Branches

En GenbetaDev | Etiquetando,haciendo crecer nuestro árbol del repositorio de código, Branching, haciendo crecer nuestro árbol del repositorio de código

En el artículo anterior de esta miniserie, estuve tratando sobre la necesidad básica de tener un repositorio de código. Y de una primera aproximación a la gestión más madura del trabajo por medio del etiquetado de versiones: labeling.

En esta segunda parte, final, quiero dar un paso adelante y describir una técnica de separación de las líneas de desarrollo en el repositorio de código fuente que nos ayude, en gran medida, a organizar la complejidad inherente a todo desarrollo en equipo.

Branching, dicho de forma espantosa sería algo como “rameando” o ir haciendo ramas, se utiliza en los repositorios de código. No es algo novedoso, ni mucho menos. De hecho, al menos desde los años 70 ya existen aplicaciones como CA Software Change Manager, que permiten hacer branching; mucho antes de que algunos de nuestros lectores hubiese, tan siquiera nacido.

Porqué necesitamos hacer branching

Vemos que vamos a necesitar hacer una pantalla típica de CRUD: alta, modificación, baja y listado de piezas. Para ir más deprisa vamos a trabajar los cuatro al mismo tiempo en la misma pantalla, por lo cual vamos a trastear en el mismo código tanto en la capa de representación, en la de negocio y en la de acceso a datos.

Para que no haya problemas, habilitamos la capacidad de checkin múltiple, así varios podemos tocar el mismo código al mismo tiempo, y mantenemos la coherencia del código por medio de merges. Cuando lo tenemos acabado y vemos que ha funcionado bien, le ponemos una etiqueta, y continuamos con la siguiente pantalla.

Cuando tenemos terminado el módulo de almacén, y todas sus pantallas, volvemos a etiquetar y le damos al cliente el módulo para su puesta en producción. Y nos disponemos a continuar con el módulo de facturación, que está muy relacionado con el de almacén.Nos volvemos a repartir el trabajo, y empezamos a modificar y añadir las líneas del nuevo código al ya existente de almacén.

Y en esto nos encontramos que el cliente ha encontrado un fallo crítico y hay que corregirlo y publicar una actualización. Para ello nos hacemos una copia de seguridad, recuperamos la etiqueta, realizamos los arreglos, volvemos a etiquetar y se lo mandamos al cliente el módulo arreglado.

¿Y ahora cómo vuelvo al código original, que aún no funciona y que está en desarrollo; y, además, le añado los arreglos añadidos en la nueva versión?

La respuesta más obvia es, utilizando desarrollo en ramas (branching).

Cuando he terminado de hacer el módulo de almacén, no solamente lo etiqueto si no que creo una nueva rama, que es una copia del código, en donde voy a ir desarrollando el nuevo módulo de facturación. Así, si tengo que modificar el módulo de almacén, no tengo que esperar a tener una versión funcional del de facturación, o andar haciendo copias de seguridad.

Como se ve en la figura, este sistema es mucho más robusto y seguro. Y evito que los trabajos en un módulo me afecten al trabajo en los demás.

Diferentes sabores

El primero es una forma secuencial en donde tengo el tronco de la aplicación (siempre lista para ser desplegada), etiquetado cada punto de publicación y en donde las modificaciones y añadidos se inician, se completan y se unen al tronco por medio de una rama. Una vez terminada la misma, iniciaría otra rama para el siguiente módulo.

Esta forma de trabajo tiene la ventaja de ser muy ordenada y que la dirección de las actualizaciones siempre es del branch al trunk. Es decir, del nuevo desarrollo a la línea base. Como inconveniente, se complica hacer varios trabajos de forma simultánea. A menos que arranquemos tareas de similar duración que acaben al mismo tiempo o que no compartan nada de código (lo cual es difícil en cuanto empiezas a trabajar en capas).

Lo más habitual es que el grafo del árbol de ramas alrededor del tronco principal, sea de múltiples direcciones. No solamente de las ramas hacia el trunk, si no de este a diferentes ramas o, incluso, entre ramas diferentes.

Así, por ejemplo, en la figura anterior he iniciado una corrección en el trunk mientras termino el módulo1. Ya que he terminado la corrección, hago un merge de este con el branch del módulo 2, para que esté actualizado; ya que hay cosas en la capa de negocio que están implicadas.

Como se ve, con esta forma de trabajo voy a tener una versión de la aplicación lista para ser publicada en cualquier momento. Aseguro el no tener que esperar a que se acabe un trabajo para iniciar otro. Y puedo mantener actualizado los módulos según lo necesite en cada caso.

El mayor inconveniente es la complejidad. Si somos varios equipos, y realizamos desarrollos cruzados, con puntos en común crecientes y que se deben mantener sincronizados, puedo tener un árbol con muchas ramas que llegue a ser confuso o difícil de abarcar.

A partir de este punto de madurez, podemos ir ganando complejidad subdividiendo los trabajos incluso hasta tener una rama por Sprint o por tarea dentro de un Sprint. Teniendo siempre claro que el concepto subyacente es que el desarrollo no impida tener código funcionando en cualquier momento.

Incluso podemos llegar a un sistema de branching similar a una publicación continua, en donde no trabajamos contra un tronco, si no con simultaneas ramas. Y donde se activan o desactivan las funcionalidades según tengamos finalizados y probados los módulos.

Ahora solamente queda el pasar de la teoría a la práctica y ver un ejemplo en mi repositorio de código.

Más información | Visual Studio Team Foundation Server Branching and Merging Guide, Git. Magia Con Los Branches
En GenbetaDev | Etiquetando,haciendo crecer nuestro árbol del repositorio de código, Manejo de ramas de desarrollo con git

Una de las cosas que más me sorprenden y escandalizan es la cantidad de empresas y compañeros que trabajan sin un repositorio de código. No conocen las virtudes de configurar un punto único en donde almacenar, versionar y recuperar las cientos o miles de horas/hombre invertidas en millones de líneas de programación.

Cuando toca juntar las fuentes de dos o tres personas es un auténtico dolor, pero la cosa se hace imposible cuando lo ha de realizar todo un equipo o departamento. Haciéndose una costumbre el perder código, o tener una árbol de carpetas de “copias de seguridad“ en el ordenador que se utiliza para hacer las publicaciones y que, generalmente, es el del líder del equipo.

Pero incluso cuando se establece, por fin, un repositorio de código, se trabaja continuadamente en un mismo tronco (trunk). El cual soporta las modificaciones y actualizaciones más variopintas. Sufriendo roturas a causa de errores o el no poder publicar hasta que se termine la decimonovena modificación o arreglo.

A estos equipos les invito a dar un paso en la escalera de la madurez del ecosistema y a leer esta serie que trata sobre la técnica de branching. Es decir, la forma de construir software alrededor de un núcleo estable, minimizando las causas de ruptura o de no disponibilidad.

Y que voy a iniciar con el etiquetado de las versiones.

Las herramientas

En el núcleo tengo el repositorio de código, control de versiones y gestor de proyectos: el Team Foundation Service Preview. Que es una versión en la nube del Team Foundation Server 11; a la que me han dado acceso por invitación. De precios y costes aún no se ha anunciado nada, pero es un servicio muy completo que me permite hacer prácticamente todo lo que puedo hacer con un TFS 11 beta pero con la flexibilidad, escalabilidad, accesibilidad y disponibilidad que nos provee un sistema basado en la Cloud. Un ejemplo más del desarrollo del concepto SaaS.

Para el que tenga máquina o que quiera trastear en un entorno local, puede utilizar el Team Foundation Server 11 Beta, que está disponible para su descarga y uso sin coste, hasta que salga la versión definitiva de pago. Y aún entonces, se va a publicar una versión gratuita.

El acceso al repositorio de código lo hago desde Visual Studio 11 beta, el cual ha remozado totalmente el interfaz de la antigua versión. Y que llevo utilizando desde la versión Developer Preview presentada en el evento BUILD del año pasado.

Pero tanto ahora como en el futuro puedo utilizar cualquier fabricante o versión de repositorio de código para poner en práctica el branching. Por ejemplo, un Visual Studio 2010 contra un SVN; o un Eclipse contra un TFS, o un Git; o incluso un muy poco aconsejable y anticuado sourcesafe.

Etiquetas, un primer paso

¿Pero qué pasa cuando hemos realizado una publicación en integración; y encontramos varios errores que hay que solucionar; y a los dos días nos damos cuenta que hemos roto la versión publicada y que hay que volver a la última válida? Pues que tenemos un desastre a la vista, ya que en esos dos días algunos ficheros han sido modificados, otros han sido borrados y la mayoría no se han tocado. Y, además, el impacto de cada uno de ellos en el resto de la aplicación depende de muchos otros factores.

La forma más sencilla de poder acceder a una versión específica de mi código, es por medio del uso de etiquetas. Es decir, hago una instantánea de la evolución de mi aplicación en un momento dado y le doy un nombre para poder recuperarla como una unidad. Así no tengo que preocuparme de saber qué versión de cada fichero es la correcta para el momento específico, ni cual ha sido cambiada anterior o posteriormente. Es una especie de backup de los hitos importantes en el desarrollo de la aplicación.

En TFS, realizar etiquetados es algo tan sencillo como entrar en la pestaña del Team Explorer, y seleccionar el enlace del Source Control Explorer para abrir la ventana del Explorador de Código. Aquí pulso el botón derecho del ratón encima del nodo raíz del proyecto, o el nodo que queramos etiquetar, y selecciono “Apply label“. Así abrimos una ventana emergente en donde debemos introducir el título de la etiqueta y su descripción.

Mi consejo: sé cuidadoso. En el título incluye la fecha y describe de forma expresiva lo que caracteriza a esta versión del código. Ten en cuenta que para recuperar esta instantánea tendrás que hacer un Get specific version por etiqueta. Y en el listado que se abre en una nueva ventana emergente, seleccionar la que almacena la versión que deseas recuperar. Por lo cual el título, cuanto más descriptivo mejor.

Aquí no se acaba

Los problemas empiezan a crecer cuando dos o más desarrolladores están modificando el mismo código al mismo tiempo. Ya que el sistema de etiquetas es lineal, por lo cual tarde o temprano tendremos un nudo gordiano en donde no hay forma de tener una versión estable del proyecto sin un gran y doloroso esfuerzo.

Y aquí llegamos a los troncos y las ramas: branching.

Más información | Visual Studio Team Foundation Server Branching and Merging Guide, Git. Magia Con Los Branches
En GenbetaDev | Manejo de ramas de desarrollo con git

CMIS (Content Management Interoperability Services), es un estándar abierto para el diseño de una capa de abstracción que permita el control de diversos gestores de contenidos y repositorios documentales de una forma genérica. Para ello, CMIS define un modelo de dominio y una serie de mecanismos estándares de comunicación como Web Services o RESTful AtomPub.

OASIS es el reponsable de la gestión de este estándar desde Mayo de 2010, el cual contempla la gestión de dos tipos de objetos principalmente: directorios y documentos. A partir de estos, se establecerá una jerarquía de almacenamiento asignándo propiedades a ambos y complementándolos con el control de acceso a los mismos, control de versiones o incluso definiendo relaciones entre ellos.

Son muchos los gestores de contenidos que actualmente han apostado por CMIS a la hora de exponer su funcionalidad. Esto hace posible diseñar aplicaciones más flexibles y con un menor grado de acoplamiento, ya que la dependencia de un estándar y no de una implementación específica del software de gestión de contenidos permite poder migrar a otro proveedor de forma más sencilla.

En este artículo y en sucesivas entregas profundizaremos en las bases de CMIS, en su implementación en Alfresco y en su uso desde las aplicaciones cliente que diseñemos.

CMIS y Java Content Repository

Antes de comenzar a analizar a fondo CMIS, una de las primera preguntas que nos puede surgir es, ¿Porque otro estándar para el acceso abstracto a repositorios documentales si ya existe JCR?

Al margen de que en CMIS se interopera no a nivel de lenguaje Java, sino a nivel HTTP (Web Services o REST), el foco de ambos estándares es distinto, con lo que son totalmente compatibles.

Lo más llamativo es que si usamos Apache Chemistry para implementar nuestro servidor, podemos hacer que cualquier repositorio que ya cumpla JCR, sea ahora accesible vía CMIS de forma directa.

A continuación, podemos ver un gráfico muy descriptivo que explica cómo estos estándares interactuan entre ellos:

Haz clic en la imagen anterior para ver el detalle completo :)

El modelo de dominio

CMIS acaba definiendo un modelo de dominio, de forma que nuestra aplicación deberá trabajar sobre este a la hora de acceder a los contenidos del repositorio.

En el modelo de dominio vamos a manejar varios tipos de objetos: documentos, directorios, relaciones y políticas.

En general, cualquier objeto del modelo va a poder tener propiedades a modo de metadatos, las cuales tendrán un ID conocido y un valor. Por ejemplo, cualquier objeto tiene definida una fecha de creación (cm:created) y la persona que lo creó (cm:creator). Por otra parte, e incluyendo los atributos anteriores, un directorio también podrá tener la referencia al padre o el nombre del directorio (cm:name). Podemos encontrar más detalles sobre los atributos mapeados entre CMIS y Alfresco en su guía de referencia.

Como conceptos avanzados, CMIS incorpora también el manejo de los privilegios de acceso a los objetos (ACL) y lo que se conoce como “interpretaciones” (renditions). Las renditions nos permiten la obtención de versiones especiales de los documentos en base a unos criterios, por ejemplo para la generación de un thumbnail.

Bindings

Como detallábamos en la introducción, CMIS define al margen del modelo de dominio una serie de estándares de comunicación con el fin de favorecer la interoperabilidad de su arquitectura.

Estos dos estándares son: Web Services para comunicación SOAP/XML y RESTful AtomPub para transmisión HTTP de documentos ATOM (extendidos con atributos definidos por CMIS).

Sobre este modelo de comunicación, el repositorio que implemente CMIS deberá ofrecer los siguientes servicios:

• Repositorio. Información y funcionalidades disponibles en el repositorio.
• Navegación. Navegación por la estructura de directorios.
• Objetos. Operaciones CRUD sobre objetos.
• Inserción multidirectorio. Gestión de la inyección de un mismo objeto en múltiples destinos.
• Búsqueda. Tratamiento de consultas con CMISQL.
• Versionado. Acceso a documentos y a sus versiones.
• Relaciones. Búsqued de objetos y de sus relaciones.
• Permisos. Gestión de las políticas de acceso y de los ACLs concretos de los objetos.

Conclusiones

En este artículos hemos presentado el estándar CMIS ofrecido por OASIS para conseguir un acceso abstracto a los repositorios documentales. En próximas entregas veremos cómo interactuar con Alfresco a través de CMIS y hacer uso de otras funcionalidades avanzadas de CMIS como las renditions o las búsquedas.

OASIS | CMIS Specification
CMIS | Domain model
JCR | JCR – CMIS comparison

Puede parecer que el mundo de los CMS está bastante abarrotado. Los hay de todos los colores, open source y propietarios, basados en PHP, en Java, en Ruby… Pero la verdad es que construidos sobre Django no hay muchos y, que diablos, cuantos más mejor, vivan la diversidad y la posibilidad de elección. El caso es que Mezzanine es un CMS basado en Django, con licencia BSD y que ha alcanzado recientemente su versión 1.0.

Sus creadores (que reconocen sin pudor haberse inspirado en Wordpress) llevan dos años trabajando en el proyecto y la verdad es que tiene una pinta más que aceptable. Algunas de sus principales características son:

• Navigación semántica
• Integración con Twitter Bootstrap, disqus, bit.ly o Google Analytics
• Formularios HMTL5 que permiten drag&drop y edición inline
• Widgets configurables
• Suite de testo

Además de todo lo que se le debe de pedir a cualquier CMS por cutre que sea: URLs amigables, sistema de blogs, templates personalizables, tags… Como añadido incorpora un sistema de ecommerce desarrollado por la misma gente de Mezzanine llamado Cartridge.

Tiene demo online, abundante documentación, una lista de correo, tracker para incidencias y, como no, puedes hacerte tu propio fork cogiendo el código de su repositorio de Github. Ya sólo queda probarlo y ver que tal, aunque lo cierto es que, como comentabamos al principio del post, el de los CMS es un terreno muy explotado y con soluciones realmente buenas en el mercado. Veremos a ver.

Pd1: ¿de verdad los usuarios y desarrolladores de Django se llaman a si mismos Djangonauts? Bastante curioso, desde luego.

Pd2: venga va, enlacico a ese temazo que es ‘Mezzanine’ de los Massive Attack. ¡Vivan los 90s!

Vía | Django Users Google Group
Más info | Mezzanine

El pasado veintidós de febrero Atlassian hacía pública la nueva versión de su buque insignia Jira 5. Jira es una aplicación/servicio web multiplataforma escrito en Java que permite la gestión de proyectos así como el seguimiento de errores e incidentes.

Está ampliamente difundido en la industria del desarrollo de software y presenta licencia propietaria para gestión de equipo y proyectos de software propietario así como una licencia de uso gratuito para proyectos y equipos de Software Libre y/o Código Abierto.

Como en Genbetadev queremos saber más sobre este nuevo lanzamiento, nos hemos puesto en contacto con el embajador de la compañía en nuestro país y le hemos preguntado acerca de su visión personal sobre la nueva versión y sobre el futuro inmediato de la estrategia de la compañía australiana.

Hemos asaltado a David Bonilla con preguntas relacionadas con lo que Jira 5 tiene que ofrecernos como desarrolladores y esto es lo que nos ha contado.

NOTA: Los siguientes párrafos NO son una transcripción textual de la conversación mantenida con David Bonilla.

Aspectos Fundamentales

Las aplicaciones molan, pero las plataformas molan mucho más

Jira 5 permite que nuestros proyectos no solo sean parte de nuestra organización sino que ademas puedan ser compartidos hacia el exterior incluso con gente que no son usuarios de Jira.

Nueva API, nuevo espíritu

Rich es un peso pesado dentro del panorama internacional, fue mencionado en la última Sping I/O por su fantástico artículo Principios modernos del desarrollo web que no dejó a nadie indiferente.

En Jira 5 se ha conseguido que la API, a parte de ser buena, sea estable, así que Atlassian garantiza la perfecta compatibilidad de su API de plugins con todas las versiones de Jira 5.x algo de agradecer que seguro muchos desarrolladores para Facebook envidian y ansían para sí.

Han sido varias las mejoras a la API de red que ahora no solo funcionan perfectamente para la extracción de datos sino que además ofrecen un punto de entrada facilitando la creación y modificación de los mismos.

Make Cash: Atlassian Plugin Exchange

Podemos buscar plugins desde el propio Jira 5 e instalarlos al vuelo. Aún no se dispone de pasarela de pago pero esta planificada su inclusión en un futuro cercano con los costes habituales de servicio.

Si lo que nos gusta es crear pero no disponemos de la financiación requerida, siempre podemos recurrir al marketing para plugins del que el mismo David Bonilla escribió un estupendo artículo.

Si lo que nos gusta es programar de forma independiente pero eso de comer nos llama mucho la atención, esta es una opción nada despreciable.

Jira 5 se vuelve social

Ser un Troll de las Cavernas mola, pero ya esta bien…

Aplicaciones de terceros

• Zendesk
• Satisfaction
• Google Apps
• Tempo
• Salesforce

Todo son facilidades oiga

Quien diga que eso no es una mejora de la comunicación interna de la compañía es un necio o un ciego, o lo que es aún peor, un mentiroso.

Bonus Track

Como curiosidad os dejo un enlace al primer plugin de Jira 5 de la empresa española Deiser.

Conclusión

Más Información | Jira 5 Bonillaware, Página oficial de Jira 5 en Castellano