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.