Hoy en día, el uso de GIT o de cualquier otra herramienta de control de versiones, no es opcional a la hora de desarrollar proyectos en equipo, ya sean tecnológicos o de otro tipo.

Para desarrollar nuestros productos, en Simettric formamos equipos entre profesionales de diferentes perfiles: diseñadores, profesionales de comunicación y copy, gestores de contenido, traductores… necesitamos que todos ellos puedan acceder y trabajar de modo seguro a ciertas partes del proyecto e incluso al código en sí, sin pisar el trabajo del otro.

El objetivo de este artículo, es el de proveer de una guía comprensible a profesionales no desarrolladores de software para que puedan integrarse en nuestro flujo de trabajo gracias a GIT.

En esta guía vamos a mostrar cómo usar git bajo MacOSX, Linux o cualquier sistema que tenga una línea de comandos Bash. (En Windows gracias al cliente gratuito de GIT disponible para esta plataforma se puede emular, pero haremos una guía específica para ese entorno en el futuro).

¿Por qué usar GIT?

Existen otros sistemas de control de versiones, pero GIT es actualmente el más utilizado por su facilidad de uso y también, gracias a servicios populares como github o bitbucket, que nos dan herramientas muy potentes para trabajar en equipo, siendo gratuitas para proyectos abiertos u Open Source. Hablaremos de estos servicios más adelante en este artículo.

Git nos da ventajas tanto si trabajamos de forma solitaria como si lo hacemos en equipo.

  • Podemos tener registrado cada cambio en los archivos en los que trabajemos y volver a cada uno de ellos en todo momento
  • Podemos incluso crear diferentes ramas, pudiendo avanzar con cambios en los archivos de forma independiente en cada una de ellas, de una forma más cómoda y segura que si tuviésemos una copia de la carpeta de nuestro proyecto
  • Si trabajamos en equipo, podemos ver quién ha cambiado los archivos en todo momento y volver a versiones anteriores
  • También podemos ver, en el caso de archivos de texto, qué líneas han cambiado exactamente y quien ha registrado los cambios
  • Si trabajamos en equipo, podemos crear una rama mientras el resto trabaja en una versión anterior, nosotros avanzar con una versión nueva y cuando estos cambios estén validados y listos, añadirlos a la rama en la que trabaja todo el equipo.

En esta guía no vamos a entrar en el uso de ramas para no complicar innecesariamente la introducción. En futuros artículos, cursos y workshops hablaremos en detalle sobre este y otros temas.

En Simettric también tenemos la filosofía de usar pocas ramas y nuestros colaboradores no desarrolladores suelen trabajar por lo general en una única rama, la principal o “master” del proyecto.

Repositorios

Un repositorio no es más que “la carpeta” del proyecto que contiene los archivos con los que vamos a trabajar. De hecho, para crear un repositorio en nuestro ordenador, lo único que deberíamos hacer es crear la carpeta en sí e inicializar un repositorio en ella.

Vamos a hacerlo desde el Terminal.

Nota:

Si no tienes costumbre de utilizar la línea de comandos, te recomiendo este tutorial para aprender lo básico, necesario para operaciones rutinarias con GIT.

Paso 1. Abrimos el terminal

Al abrir el Terminal, por defecto se nos sitúa en “la carpeta Home” de nuestro usuario. Para saber donde estamos, podemos mostrar nuestro directorio actual escribiendo siguiente comando

Al pulsar enter nos aparecerá nuestra ruta actual, en mi caso /Users/asier.

Paso 2. Vamos al directorio en el cual queremos crear la carpeta y la creamos

Nuestro objetivo va a ser ir al escritorio y crear una carpeta llamada my_project en ella. En ese directorio será donde inicializaremos el repositorio de GIT para empezar a trabajar.

Por lo tanto, vamos a ir al escritorio (en el caso de MacOSX, si estamos en nuestra Home, se trata de una carpeta llamada Desktop)

Una vez en el escritorio, creamos la carpeta my_project mediante el comando mkdir

Y nos situamos en dicha carpeta

Paso 3. Inicializamos el repositorio

Ahora que ya hemos creado una carpeta donde trabajar, podemos empezar a trabajar con GIT e inicializar un repositorio en ella

Esto nos ha creado un directorio oculto, llamado .git que contendrá una pequeña base de datos de los cambios que vayamos haciendo, junto a la configuración del repositorio.

Notas:

Si ya tenemos un directorio de proyecto previamente con archivos creados en él, bastará con situarnos en el mismo y llamar al comando git init .  de la misma forma en la que lo hemos hecho en este último paso.

Si no estamos acostumbrados a la línea de comandos y queremos crear los directorios desde Finder en Mac, navegando por ellos de forma gráfica en lugar de por línea de comandos, podemos configurar de forma sencilla la opción de abrir el Terminal desde la carpeta que nos interese desde Finder.

Añadir archivos y registrar cambios

Una vez inicializado el repositorio, podemos trabajar en esa carpeta de forma normal. Creando archivos en ella, modificando los archivos que creemos.. desde fuera del terminal, como lo haríamos normalmente.

Sin embargo, para que GIT registre un cambio, tenemos que decírselo explícitamente, no vale con guardar los archivos. Por ello, cuando queramos registrar un cambio que no queremos perder, tendremos que ejecutar esos dos comandos en el terminal en el directorio de nuestro proyecto.

Vamos a ver en detalle qué hacen estos dos comandos:

Con git add .  le decimos a GIT que registre los archivos nuevos que hemos creado y los archivos que hemos eliminado. Yo recomiendo ejecutarlo siempre que queramos registrar un cambio, incluso si no hemos añadido archivos nuevos o eliminado nada.

Con git commit -a -m "mensaje..."  le decimos a GIT que registre los cambios con un mensaje descriptivo para nosotros y el resto del equipo.

Cada vez que queramos que GIT recuerde un cambio relevante, tendremos que realizar este proceso. Por ello, recomiendo tener a mano la ventana del terminal situada en el directorio del proyecto, mientras trabajamos en él.

Visualizar archivos cambiados pendientes de registrar por GIT

Para ver qué archivos han cambiado desde nuestro último “commit”, podremos hacerlo con el siguiente comando:

Esto nos devolverá el listado de archivos que GIT sabe que han cambiado, pero que no se han guardado en su base de datos de cambios.

Volver a un cambio anterior

Para volver a un cambio concreto que hayamos hecho sobre nuestros archivos, primero debemos ver el histórico de cambios que hemos realizado. De momento podemos hacerlo con este comando:

Este comando nos devuelve el listado de los cambios que hemos ido registrando.

Nota:

En este artículo veremos más adelante cómo podemos verlo de forma más sencilla, si utilizamos un entorno gráfico o web, como en el caso de GitHub o Bitbucket. Pero es importante conocer cómo podemos hacerlo desde la línea de comandos primero.

Sabiendo los cambios que hemos ido registrando sobre los archivos del repositorio y los identificadores de cada commit, podemos volver a restaurar nuestro repositorio al commit que nos interese.

Repositorios externos y servicios de hosting de GIT

Hasta ahora hemos visto cómo trabajar con GIT en repositorios que se encuentran en nuestro equipo, en local. Pero todos sabemos que nuestro equipo se puede estropear o puede no estar disponible.

Otra necesidad surge cuando trabajamos en equipo, si alguien quiere trabajar en ese mismo proyecto, necesita alguna forma de centralizar los cambios y los archivos, de una forma similar a cómo lo haría con sistemas como DropBox pero con toda la potencia que nos da GIT.

GIT nos permite montar servidores en los que podemos configurar nuestros repositorios de forma centralizada, pero lo normal es utilizar servicios en la nube como GitHub, Bitbucket o Gitlab, que son los más utilizados.

Estos servicios además, nos permiten integrarnos con otros servicios en la nube, pudiendo avisar automáticamente en Slack cuando hagamos un cambio en el repositorio o incluso, automatizar la subida a un servidor web sin necesidad de utilizar un cliente de FTP.

Algunos de estos servicios, como Bitbucket, son totalmente gratuitos para grupos de trabajo pequeños. Otros como Github, son gratuitos solo para proyectos abiertos u Open Source.

Crear un repositorio externo en Bitbucket y autorizarnos para subir/bajar cambios desde nuestro equipo

Después de registrarnos en Bitbucket, desde el menú de creación, podemos crear un repositorio privado nuevo:

Tras crear nuestro repositorio, necesitamos añadir claves de acceso ssh para poder trabajar desde nuestro equipo sin tener que estar indicando nuestra contraseña constantemente.

Una clave ssh es un acceso seguro asociado a un usuario de un ordenador. Con ellas, podemos acceder a otros servidores sin tener que utilizar contraseñas y desde ellos, se puede revocar el acceso, en caso de perder el equipo.

Para añadir una clave, necesitamos ir a Opciones de Bitbucket / Seguridad / Claves SSH, de nuestra cuenta. Al asociar nuestras claves SSH en nuestra cuenta de Bitbucket, podremos gestionar directamente todos los repositorios a los que tengamos acceso en Bitbucket.

Si no tenemos creada una clave en nuestro equipo para nuestro usuario, necesitamos crear una. Bitbucket tiene un tutorial para crear nuestras claves, pero el resumen sería el siguiente:

Abrir el terminal y ejecutar el siguiente comando:

Se nos preguntará el sitio donde queremos generar la clave (por defecto el directorio .ssh de nuestra home) y una contraseña. Podemos dejar por defecto todo, aunque la seguridad será mayor si indicamos una contraseña.

Tras generar las claves, se nos crea un archivo id_rsa e id_rsa.pub en el directorio que le hemos indicado. Nos interesa el contenido del archivo id_rsa.pub, que es el que añadiremos en Bitbucket.

Si hemos dejado la ruta por defecto, podremos abrir el directorio con los archivos mediante el comando:

Esto nos abrirá el Finder y con nuestro editor de texto favorito, copiaremos el contenido del archivo id_rsa.pub en la pantalla de añadir clave de nuestra cuenta de Bitbucket.

Una vez añadida la clave, ya no tendremos que volver a hacerlo para ese usuario y ese equipo cuando trabajemos con repositorios en Bitbucket.

En otros servicios como Github, el proceso sería similar y al igual que ocurre en el caso de Bitbucket, suelen tener documentación y tutoriales de ayuda para hacerlo.

Añadir un repositorio externo a nuestro repositorio local

Ahora que ya tenemos un repositorio creado en Bitbucket y nuestro usuario+ordenador autorizado, podremos asociar dicho repositorio remoto a nuestro repositorio local.

Podemos asociar nuestro repositorio local con infinitos repositorios remotos. Esto es interesante por ejemplo, si queremos tener un repositorio en Bitbucket para nosotros y un repositorio para nuestro cliente en Github.

Podemos elegir en cada momento qué cambios vamos a subir a cada repositorio para que otras personas se los descarguen. Y también, podemos elegir, desde qué repositorio nos vamos a descargar nosotros, los cambios de otras personas que trabajen en ese mismo proyecto.

Para asociar el repositorio que acabamos de crear, en Bitbucket tenemos la siguiente ayuda en el resumen del repositorio que hemos creado allí antes:

Como vemos, tendríamos que ejecutar el siguiente comando en el directorio de mi repositorio local:

Este comando registra esa ruta ssh://… en nuestro repositorio local con el nombre “origin”.

En mi caso, la ruta de mi repositorio remoto sería ssh://git@bitbucket.org/asiermarques/newproject.git  en el tuyo, puedes verla en la parte superior derecha del resumen del repositorio:

El desplegable nos permite elegir entre ssh o https. Utilizaremos siempre ssh.

El segundo comando que vemos es

Este comando subirá nuestros archivos al repositorio “origin” (que es el que hemos creado en Bitbucket) y a la rama “master”, la única que hemos creado y que se crea por defecto.

Subir cambios desde nuestra carpeta local a un repositorio externo

Como hemos visto en el punto anterior, los cambios que registremos en nuestro repositorio local, se subirán a un repositorio externo mediante el comando push

Básicamente, origin es el nombre del repositorio remoto y master la rama a la cual subimos. Si tuviésemos un repositorio llamado “cliente” y una rama de “traducciones”, haríamos lo siguiente:

Una vez subidos los cambios registrados mediante los commits que hayamos hecho, podremos visualizar la historia directamente en Bitbucket y ver cada uno de los cambios hechos en los archivos del repositorio:

Actualizar nuestra carpeta de trabajo local con los cambios subidos por otros al repositorio externo

Para actualizarnos con los cambios que otras personas hayan subido a un repositorio externo, utilizaremos el comando pull:

De igual forma, “origin” es el nombre del repositorio que hemos registrado y “master” la rama de la cual nos interesa descargar y actualizar nuestros archivos.

Si al descargarnos los archivos existiese algún conflicto porque dos personas hayan tocado la misma línea de un archivo, GIT nos lo avisaría y deberíamos corregir aquello que estuviese mal o desactualizado antes de poder registrar cambios nuevos.

Crear un repositorio local y una carpeta de proyecto, desde un repositorio externo

En algunas ocasiones, quizás nos interesa descargarnos un proyecto que ya esté en marcha desde un repositorio externo. Para ellos existe el comando git clone.

Por ejemplo si quisiéramos descargar la última versión de WordPress a una directorio de nuestro escritorio en Mac, haríamos:

Con el comando cd nos situaríamos en el directorio en el cual queramos bajarnos el proyecto WordPress, en nuestro caso la carpeta del escritorio de Mac.

Una vez allí, hacemos git clone para descargarnos la última versión de WordPress, esto nos creará el directorio WordPress en el escritorio.

Herramientas gráficas para trabajar con GIT

Hemos visto cómo utilizar el terminal para utilizar GIT mediante línea de comandos.

Existen algunas aplicaciones que nos permiten utilizarlo de forma más amigable desde asistentes o con una interfaz gráfica, pero la recomendación es aprender a utilizar bien GIT desde la consola/terminal para comprender qué es lo que estamos haciendo realmente.

Algunas opciones interesantes son:

Conclusión

A modo de guía, hemos visto los aspectos más importantes que vas a necesitar para trabajar con GIT en equipo o en solitario en tu día a día.

En el último año se están empezando a escuchar dudas por parte de nuestros clientes sobre qué son las Progressive Web Applications o PWA y qué diferencia hay con las aplicaciones instalables desde un store (nativas o híbridas).

Lo que se denomina una PWA (Progressive Web App), no es más que una aplicación web de navegador (web app) o incluso un sitio web, que hace uso de tecnologías ya disponibles que nos permiten dotarla de una UX mucho más próxima a la que obtendríamos con una aplicación instalable en nuestro ordenador o dispositivo móvil. Incluso podemos acceder a ellas o utilizarlas sin conexión a Internet.

Y esto es muy importante. Lo es, porque la barrera de instalación de aplicaciones en el dispositivo del usuario es cada vez más alta. Y la dificultad para retener esas instalaciones también lo es.

En el 2015, ComScore publicó un informe en el que se recogía que el 78% de los usuarios solo utilizaba realmente 3 apps de las instaladas en su dispositivo móvil. También mostraba que más efectivo captar audiencias a través de una webapp que a través de las instalaciones de sus apps y que las primeras crecen mucho más rápidamente.

Si pensamos también en la facilidad de publicación de una webapp en comparación de una aplicación que se instale a través de un store, nos sobran los argumentos para adoptar esta estrategia a la hora de plantear nuestro producto.

Actualmente, el valor que buscamos entregar al plantear nuestra aplicación como una PWA, actualmente es el siguiente:

  1. La mejor experiencia de uso sin conexión a Internet.
  2. Notificaciones
  3. Funcionamiento en segundo plano, sin tener el navegador abierto.
  4. Progressive enhancement
  5. UI (y su UX) lo más próxima a una aplicación instalable

Todo esto se puede conseguir con tecnología actual que ya está disponible para desarrolladores web y que son compatibles actualmente con los navegadores más relevantes que existen en la actualidad. Existen tecnologías muy interesantes que están en proceso de poderse utilizar también en dichos navegadores como por ejemplo: Web Bluetooth, NFC, Sensor de luz, Sensor de proximidad, Acelerómetro y Giroscopio.

Como se puede intuir, en unos años las aplicaciones web en sí podrán cubrir desde el navegador prácticamente la gran mayoría de problemáticas que resuelven las aplicaciones instalables en la actualidad. Bien es cierto que existen límites también que deben desaparecer para que podamos pensar en que las aplicaciones web puedan sustituir casi por completo a las aplicaciones nativas.

Realmente la parte más importante de una Progressive web application es la de plantear el desarrollo de nuestra webapp con una estrategia de offline first web development.

Con esta estrategia de desarrollo de aplicaciones web y sitios web, nos centramos en que la UX de nuestra aplicación web sea lo mejor posible sin disponer de conexión a Internet. Esto también mejorará notablemente la experiencia de uso también, cuando el usuario tenga conexión.

Esta estrategia plantea pensar en las aplicaciones desde otra perspectiva. Simplificando un poco, lo que se busca es que la primera vez que el usuario acceda a una aplicación web, esta se guarde en el equipo o móvil del usuario. La próxima vez que vuelva a abrir en el navegador o con un acceso directo en la pantalla de inicio, en lugar de conectarse a Internet, la aplicación arrancará como si “estuviese instalada” en el móvil u ordenador del usuario.

Esto implica técnicamente el diseñar estrategia de caché de la aplicación con la capacidad de actualizarse cuando una nueva versión se suba a Internet.

Otro requisito de trabajar offline es el de precisamente, no interrumpir el trabajo del usuario cuando este no disponga de conexión y tener capacidad de sincronizarse cuando la conexión esté disponible de nuevo. De hecho, al plantear una estrategia de offline-first, la aplicación debería funcionar perfectamente sin estar conectada.

Otro pilar importante es el trabajo en segundo plano. Gracias a una tecnología llamada Service Workers, los desarrolladores web podemos hacer funcionar aplicaciones web incluso si esta o el sitio web no están abiertos en el navegador web.

Esto nos permite realizar operaciones avanzadas como en una aplicación instalada en el equipo o dispositivo móvil: comunicarnos con el servidor, gestionar notificaciones push y mostrarlas al usuario…

Este diseño deberá tener en cuenta la implementación de un Progressive enhancement, mediante el cual vamos comprobando los límites del dispositivo del usuario para ir añadiendo características. Por ejemplo: si la conexión está disponible o no, si hay soporte para notificaciones, si hay soporte para Bluetooth… la idea es bastante básica y no es nueva, pero cuidar esto es un punto crítico a la hora de plantear una Progressive web application.

Estas tecnologías hacen también que empecemos a ver cambios en el diseño de UI de las aplicaciones que utilizamos a diario y también nos planteemos aplicarlos nosotros.

Algo a lo que ya empezamos a estar acostumbrados es a “instalar un icono” del sitio/app web en la pantalla de inicio del dispositivo. De esta forma la aplicación o sitio web arrancará sin necesidad de abrir el navegador, con look and feel nativo.

Ejemplo de App Banner

Otro cambio significativo es el App Shell. A nivel básico, con App Shell conseguimos que el usuario al arrancar la web obtenga inmediatamente el layout y toda la interfaz de la aplicación, sin un preloader o una página en blanco en el navegador y a medida que se va obteniendo la información se va dibujando el resto de la información.

De esta forma el usuario sabe exactamente lo que está cargando y donde va a aparecer antes de que lo haga, aprendiendo nuestra interfaz al mismo tiempo.

Ejemplo de App Shell

Ejemplo de App Shell de Linkedin

Combinar esta técnica de diseño con una buena estratega de desarrollo offline-first y las técnicas de desarrollo que hemos visto anteriormente, incrementarán notablemente la experiencia de uso y sentará las bases para ir implementando tecnologías más avanzadas que harán de nuestro sitio web, o aplicación web, un software muy potente que no necesitará instalarse por parte del usuario en sus dispositivos.

En Simettric tenemos amplia experiencia desarrollando plugins y themes avanzados para WordPress, así como creando servicios online que se apoyen en su inicio sobre este sistema con el objetivo de migrar después a arquitecturas más sólidas como Symfony o Laravel.

Nuestra recomendación para construir proyectos que requieran escalar y un alto grado de mantenibilidad es evitar utilizar soluciones como WordPress “para todo”.
Estas soluciones están pensadas para crear sitios de contenido y resuelven esa problemática de forma decente, si nuestros requisitos son de diferente naturaleza y queremos código mantenible, no son la mejor opción.
También hay que tener en cuenta que WordPress no ha evolucionado a nivel de arquitectura a lo largo de los años, dificultando el aplicar buenas prácticas de desarrollo.

Sin embargo, a veces nos encontramos escenarios en los que por alguna razón se requiere utilizar esta plataforma y hemos creado soluciones open source para trabajar de la mejor forma con la misma.

Sense

Sense es un framework MVC con Contenedor de dependencias, diseñado para poder crear desarrollos Enterprise o escalables, que sean mantenibles y fácilmente migrables en un futuro a frameworks como Symfony3 o Laravel.

Su sistema de rutas funciona mediante anotaciones en los controladores, integra composer junto al componente de Inyección de dependencias de Symfony y permite separar la vista completamente del código. Incluso permite integrar de forma sencilla sistemas de vistas como Twig.

Sense te aísla por completo de los hooks de WordPress y te permite trabajar como trabajarías en Laravel o Symfony3.

WP Query Builder

Inspirada en el Query Builder de Doctrine2, con esta herramienta podrás crear consultas complejas a la base de datos de WordPress mediante expresiones testables en lugar de SQL que utilizan la clase WP_Query por debajo.

Simple Form

Inspirado en la forma de trabajar de los formularios de Symfony2/3, con esta librería de formularios podrás crear y validar formularios de forma simple, mantenible y minimalista.

Simple Form lo puedes utilizar en todo tipo de aplicaciones basadas en php sin dolores de cabeza. Y utiliza Zend Validator como sistema de validaciones.

WP Simple ORM

Nuestra última librería para WordPress. Aun en desarrollo, WP Simple ORM te permite trabajar con contenidos de WordPress como si fuesen Entidades, gestionando las relaciones entre ellas.

En Simettric estamos comprometidos totalmente con el Open Source e iremos liberando más código, no solo relacionado con WordPress, síguenos en github.

El 10 de Octubre Simettric organiza junto a Plain Concepts y con la ayuda de Cylicon Valley la segunda edición de PucelaTechDay, una iniciativa dentro de ElComité.

Participaremos con una charla en la que hablaré sobre Xamarin Forms, mostrando de forma práctica y en directo cómo crear una aplicación nativa multiplataforma para iOS y Android.

El evento contará también con charlas muy interesantes sobre DevOps y entornos MEAN de Javascript.

Más información en pucelatechday.com.

Una de los primeros problemas que nos encontramos al crear formularios para una aplicación nativa para iOS/Android en Xamarin Forms es que el control de Editor no se ajusta por defecto al texto que lo contiene.

Aunque podemos resolverlo de varias formas, la mejor y más natural es que la altura del campo de texto se vaya adaptando según vayamos insertando el texto en él.

Para ello necesitaremos crear un método de extensión que resetee los valores iniciales del layout de la misma, utilizando Reflection para acceder al método privado InvalidateMeasure.

Lo haríamos de la siguiente forma:

Y en el control básicamente nos suscribiremos al evento TextChanged para llamar al método que hemos implementado como extensión.

De esta forma nuestro control de texto irá cambiando de altura en base al texto que lo contiene.

Aunque la mayoría de los desarrollos web que hacemos son en Symfony2, en Simettric trabajamos mucho con WordPress. Elegimos esta opción de CMS frente a otras por su mercado y popularidad, decidiendo enfocarnos en una sola opción para dar un mejor servicio.

Pero WordPress no es perfecto, tiene muchas limitaciones que aún no están solventadas y que impiden pensar en esta solución de CMS de la misma forma en la que pensamos con herramientas o frameworks como Symfony2 o Silex. A pesar de esto, muchos clientes que empiezan con su servicio en Internet establecen como requisito esta opción para construir sus plataformas o ya disponen de un desarrollo que ha ido evolucionando sobre esta opción.

En proyectos de este tipo a veces WordPress es una opción factible por la tipología de producto a desarrollar coincidiendo con un presupuesto reducido. En otros proyectos no es la mejor opción, sobre todo si el producto va a evolucionar en features, necesitando ser mantenible y evolucionar de forma coherente también en UX, esto último complicado sin invertir en desarrollo y diseño.

¿Qué es y por qué utilizamos Inyección de dependencias en un proyecto de WordPress?

Algo importante si vamos a construir un proyecto WordPress que va a requerir escalar o si debemos migrar una plataforma hecha sobre este sistema a otra arquitectura más solida como la que nos pueden proporcionar Symfony2 o Laravel, es el pensar cómo podemos reutilizar el código ya hecho.

La Inyección de Dependencias es un patrón de arquitectura de software que nos permite desacoplar nuestro código al máximo, para poder no sólo migrar de un framework/cms/desarrollo a medida a otras soluciones, sino también el poder sustituir cada una de las partes que lo forman.

En este sentido, gracias a la Inyección de Dependencia lo que hacemos es separar nuestro código de negocio de todo código que tenga que ver con WordPress. Esto nos permite tener una capa totalmente independiente que podemos mover en un futuro de una instalación WordPress a un proyecto Symfony2 sin modificar prácticamente nada de lo que hayamos programado.

¿Cómo lo implementamos?

Existen varias librerías que nos permiten gestionar Inyección de Dependencias en php, las más conocidas y usadas son Pimple y el componente de Symfony2 de Inyección de Dependencias que además cuenta con un sistema de configuración de servicios muy potente.

Para WordPress o desarrollo simples por lo general utilizamos Pimple por ser una opción más simple y ligera. Vamos a ver un ejemplo simple de cómo trabajaríamos con esta librería.

En este primer ejemplo, vemos cómo hemos inicializado el contenedor de dependencias en primer lugar. Este contenedor nos servirá para almacenar instancias de objetos, a las que llamamos “servicios” y parámetros que pueden ser datos de configuraciones o todo lo que no sea una instancia de un objeto.

En este ejemplo, hemos creado un servicio “wordpress.query” que nos devolverá el $wp_query global que estamos acostumbrados a usar en cualquier desarrollo WordPress. Aunque pueda parecer que este ejemplo no da mucho valor o no tiene sentido, en realidad hemos dotado de una flexibilidad a nuestro código de una forma muy sencilla.
Si en un futuro necesitamos extender la clase \WP_Query y utilizar una implementación propia, tenemos la certeza de que si hemos usado el servicio “wordpress.query” sólo tenemos que cambiar el código en la implementación del servicio “wordpress.query”, el resto de código que haga uso de este servicio seguiría funcionando sin ningún cambio.

Vamos a ver un ejemplo donde este valor se va a ver con más claridad.

Imaginemos que necesitamos desarrollar un sistema de contactos sobre WordPress que haga uso de Custom Post Types y que pueda ser migrable en un futuro a un framework como Symfony2 o Silex.

Lo primero que hacemos es crear la clase que hará de entidad de los contactos.

Una vez creada la clase Contact, vamos a crear una interfaz que definirá cómo trabajamos con los contactos a nivel de guardado y recuperación de datos.

Con esta interfaz definimos cómo debería hacerse la lectura y escritura de datos en la fuente que sea: base de datos, servicio web… lo que sea, nos es indiferente.

Tras crear la interfaz, creamos una clase que implementa dicha interfaz.

Esta clase estará acoplada a la lógica y funcionamiento de WordPress y es la que tendremos que sustituir al migrar a Symfony2 para que utilice Doctrine2 por ejemplo en lugar de WordPress.

Ahora vamos a crear el modelo en el que tendremos la lógica de negocio y que estará aislada de WordPress.

En el modelo de contacto ya podemos hacer operaciones sin pensar de dónde estamos recuperando la información de contacto o dónde la estamos guardando.

Obviamente este es un ejemplo muy simple y probablemente necesitaríamos crearnos más implementaciones para otros servicios que dependan de funcionalidad de WordPress, como el envío de correo con \wp_mail por ejemplo.

Pero lo que pretendo mostrar con este ejemplo es cómo desacoplar la lógica de negocio de uno de los puntos que más suele atarnos a WordPress: el acceso a los datos.

Una vez teniendo separadas las partes implementadas, vamos a instanciarlas para poder utilizarlas en nuestro plugin o theme.

Como vemos, hemos definido cada instancia de clase con su servicio en el contenedor. Hay que matizar que cada vez que se llame por ejemplo al servicio “contact.model” siempre se traerá la misma instancia de ese objeto en lugar de crear una instancia nueva. Es como utilizar el patrón Singleton, pero sin sus defectos y con la flexibilidad de poder cambiar las clases desde un único sitio.
No obstante, si se desea que se comporte de otro modo, en la documentación de Pimple podéis encontrar cómo hacerlo.

Desde nuestro plugin o theme podríamos entonces utilizar nuestro código de esta forma:

Como podemos comprobar, las operaciones que no tienen que ver con WordPress no dependen del mismo.

Si en un futuro cambiamos a Symfony2, bastaría con cambiar el objeto que implemente la interfaz RepositoryInterface dentro del servicio “contact.repository”.
Con este cambio, podremos mover nuestro código sin cambiar nada en el servicio “contact.model” que es el que hace todo el trabajo de negocio.

Hay otra ventaja adicional y es que el separar en servicios nuestro código, este se puede cubrir con tests unitarios sin problemas, haciendo el código mucho más robusto y estable aunque esté funcionando bajo WordPress.

En definitiva, desarrollando de esta forma la calidad y flexibilidad de nuestros desarrollos aumenta significativamente.

 

Una de las features más comunes a la hora de desarrollar una aplicación móvil suele ser la de colocar un sistema de login y registro tras un splash screen inicial.

Tenemos la problemática añadida de que en dispositivos Android, podemos volver atrás y quizás no nos interese que esa vista esté disponible en el histórico de navegación una vez autenticado el usuario.

Un buen ejemplo de implementación podemos encontrarla en el github de Craig Dunn. Basándonos en esta idea, vamos a ver paso a paso una implementación de ejemplo.

1: Crear las interfaces para el LoginManager y el UserProvider

Esta interfaz define dos operaciones: showMainPage, que se encargará de mostrar al usuario la primera pantalla que debe ver tras autenticarse. También implementa el método logout, que cerrará la sesión del usuario y mostrará la pantalla de login.

La interfaz IUserProvider la usaremos para recuperar la información del usuario ya sea de un base de datos, un servicio web o un archivo de recursos.

2: Implementar la interfaz AutenticationManager en la clase App de nuestro proyecto Xamarin.Forms compartido o PCL.

Lo primero que hacemos es crear un asembly para indicar qué clase implementa el servicio de IUserProvider. De esta forma el servicio estará disponible en todas las pantallas de la aplicación Xamarin.Forms.

Hemos indicado que la clase App implementa la interfaz ILoginManager, por lo que implementamos los dos métodos que conlleva dicha interfaz.

Un detalle a fijarse, consultamos a la propiedad “IsLoggedIn” con Properties.ContainsKey(“IsLoggedIn”). Esta propiedad la establecemos en la pantalla de login si el usuario se autentica.
Lo ideal sería añadir un sistema que al hacer login guardase en una base de datos local o almacenamiento interno del teléfono, los datos de email y contraseña para que se recordasen cuando el usuario vuelva a abrir la aplicación y no haya información en la propiedad IsLoggedIn.

Una vez comprobado si el usuario está autenticado, establecemos la propiedad MainPage con la página interna dentro del sistema de navegación de Xamarin.Forms o por el contrario, si el usuario no está autenticado, establecemos la propiedad MainPage a la página de Login.

Hay que notar el detalle de que la página de Login no forma parte de la navegación es decir, no es una NavigationPage.
Si estableciésemos la LoginPage como una NavigationPage, en Android el usuario podría pulsar en el botón de volver atrás accediendo a esa pantalla estando logueado. El no meterla en el sistema de navegación es como establecer una Activity con el history desactivado para que no esté accesible con el botón de atrás.

3: Crear página de login y su ViewModel

El ViewModel se encargará de actualizar los valores automáticamente indicados en la vista sin que nosotros tengamos que lidiar con eventos de los inputs. Todo gracias al patrón MVVM.

Establecemos tres propiedades: Email, Password y Loading. La última propiedad la usaremos para controlar la visualización de un ActivityIndicator (la típica rueda que mostramos mientras estamos cargando información).

En la página de login mostramos los inputs para que el usuario inserte email y contraseña además de un ActivityIndicator.
Los inputs y el ActivityIndicator están enlazados al viewModel, por lo que cuando cambien sus valores se actualizará la información del viewModel automáticamente y al revés.

Hemos mostrado también un botón que al pulsarse comprobará si el usuario existe con esa combinación de email+contraseña, estableciendo la página principal correspondiente.

 

4: Crear página interna con botón de logout en la barra de navegación

Una vez autenticado el usuario, en la página podemos mostrar lo que queramos. Hemos añadido una opción en la navegación superior para mostrar la opción de “cerrar sesión” o “salir”, que llamará al método logout del LoginManager.

Con esto tenemos implementado un sistema de login para Xamarin.Forms que funcionará en Android, iOS y WindowsPhone.

El pasado viernes finalizamos un curso centrado en desarrollo HTML5, CSS3 y Javascript de 170 horas diseñado para el programa de plan de empleo comarcal, iniciativa de Lanbide, Bilbao Ekintza e Init que tuvo lugar en el centro de innovación social Eutokia.

curso-html5-peco-header

Desde Simettric, impartimos un completo temario de Javascript, en el que vimos principalmente los siguientes puntos

  • Inicialización al lenguaje Javascript
  • Entornos actuales de desarrollo Javascript; navegador, móvil y escritorio.
  • Aspectos avanzados de programación en Javascript: creación y clonación de objetos, métodos privados, eventos.
  • Programación con jQuery: manipulación del DOM, eventos de teclado, ratón y entorno, eventos personalizados, iteraciones y selectores avanzados.
  • Consumo y conceptos de APIs REST, CORS y JSON.
  • Manejo de errores y debug con consola.
  • Uso de servicios cloud tipo BaaS, Backoffice as a service.

Algunos de los alumnos partían sin conocimientos de programación, por lo que se conjugó la formación práctica con base teórica de programación que permitió a dichos alumnos alcanzar un buen nivel en poco tiempo, a pesar de empezar desde cero.