Lo que hemos hecho en 2016 (técnicamente hablando)

Si hace unos días en geekia publicabamos lo que habíamos hecho durante el pasado año, ahora voy a intentar hacer lo mismo pero desde un punto de vista más técnico.

Este año, como anteriores 😉 el desarrollo principal ha sido bajo drupal, si bien todavía la mayor parte ha sido con la versión 7, por fin hemos podido preparar un par de proyectos en su nueva versión 8. Una API para alimentar una futura aplicación y una web para una clínica neurológica de Almería. Ya solo con este trabajo, nos ha convencido para tenerlo en cuenta para futuros proyectos durante este año.

WordPress, aunque hemos preparado un sitio, todavía no es un CMS con el que nos encontremos muy a gusto, ojo, sigo pensando que es la mejor opción para un blog, de echo, éste está funcionando con él. Eso sí, Genesis nos ha enamorado 😉

En cuanto a frameworks PHP seguimos con PhalconPHP y Symfony y aunque nos gustaría empezar con algún otro, por ejemplo Laravel, todavía estamos más que servidos con éstos.

Además este año también ha sido el cambio en la versión de PHP, ya estamos con la 7.0, aunque en producción todavía estamos simultaneandola con la versión 5.6 ya que tenemos varios proyectos que no funcionan con la nueva versión.

Para front-end seguimos con Foundation y de momento no pensamos en cambiarlo, aunque no tenga ya soporte para IE 8 😉

Además, durante este año hemos “subido” en desarrollos javascript, para ello hemos usado frameworks como Sencha (manteniendo varios simuladores), continuado con angularjs en el proyecto de cambia tu mundo para Cáritas y empezando con reactjs para la UXSpain 2016 y react native para una próxima aplicación.

En definitiva un año en lo técnico completito, espero que este nuevo año que acabamos de empezar nos permita seguir aprendiendo y mejorando en todo y algo que he echado mucho en falta ha sido la de compartir y cooperar un poco más con la comunidad 🙁

Por cierto, Feliz Año nuevo… un poco atrasado.

 

Drupal 8, el mejor corazón para un desarrollo

Hace unos meses empezamos a trabajar con una empresa que tiene tiendas por toda España, la mayor parte del trabajo es y ha sido relacionado con el marketing, tanto online como offline pero ahora ha tocado la parte técnica, más concretamente en “mejorar” su programa de fidelización.

Actualmente cuentan con un programa de bonos los cuales se reparten en unas fechas determinadas del año. Para romper la estacionalidad decidimos crear unos bonos que se “consumirán” a través de una App. Salvo una serie de condiciones que nos exigió el cliente, algunas que no compartimos, nos aceptaron la creación de la app.

Limpiando para mejorar

El primer problema con el que nos encontramos fue su ERP, aunque bastante potente, estaba un poco limitado para extraer datos, además de que necesitaba urgentemente  un saneo de los mismos. Estamos hablando de una bbdd de aproximadamente 500.000 usuarios, la gran mayoría recurrentes y repartidos por mucha parte de la geografía española. Esa “limpieza” se ha estado llevando a cabo durante estos últimos meses y gracias a la empresa desarrolladora del ERP se ha podido mejorar su conexión con el exterior, con una serie de servicios web tanto para la gestión de usuarios, como para el consumo de bonos.

El corazón de la app

Una vez estaba resuelta la conexión, comenzamos con la creación de una API que “alimentaría” la propia app. Para ello decidimos usar… a ver si lo adivinas… pues si, drupal y más concretamente pensamos en la versión 8 ya que su desarrollo potenciando la omnicanalidad lo hace el más adecuado para ello, además de servirnos como banco de pruebas para el uso de esta nueva versión de nuestro CMS favorito 😉

El desarrollo lo comenzamos con la versión 8.0.0, pero actualmente lo hemos migrado a la 8.2.0, con todo lo que ello ha conllevado. Todos los servicios se han segurizado con OAuth 2.0, además del propio basic_auth del core de drupal. Desde el CMS se gestionan las ofertas que se mostrarán en la app así como la conexión con el gestor de notificaciones, para ello hemos usado parse, y nos está dando muy buenos resultados.

Otra de las funcionalidades que se gestionan desde aquí, es la geoposición de las distintas tiendas que dispone el cliente, mediante la creación de un nodo específico y su correspondiente service.

Drupal 8 nos ha permitido integrar a través de su API REST, todo lo necesario para poder servir los datos de forma correcta, sencilla y segura.

…y por fin, la app

Para el desarrollo de la app hemos optado por un desarrollo híbrido y, aunque tenemos experiencia ya en Ionic, hemos elegido React-Native, a pesar de que solo hemos hecho un desarrollo (en React), su flexibilidad y potencia nos hizo creer que era la mejor opción. De momento, y salvo el cambio tan rápido de versiones que están teniendo, lo cual no está del todo mal, pensamos que la opción ha sido la más acertada.

Durante esta fase, todavía en desarrollo, se ha tenido que “experimentar” muchísimo, tanto que daría para un nuevo post, eso si, por si os puede interesar los módulos que estoy usando son estos:

"dependencies": {
    "base-64": "^0.1.0",
    "immutable": "^3.8.1",
    "parse": "^1.9.2",
    "react": "^15.3.2",
    "react-native": "^0.34.1",
    "react-native-checkbox-field": "^1.0.8",
    "react-native-datepicker": "^1.3.2",
    "react-native-extended-stylesheet": "^0.2.0",
    "react-native-linear-gradient": "^1.5.4",
    "react-native-maps": "^0.8.2",
    "react-native-nav": "^1.1.4",
    "react-native-push-notification": "^2.1.1",
    "react-native-qr-barcode": "^0.6.4",
    "react-native-radio-buttons": "^0.11.0",
    "react-native-remote-push": "^1.0.3",
    "react-native-router-flux": "^3.26.16",
    "react-native-side-menu": "^0.19.0",
    "react-native-swiper": "^1.4.5",
    "react-native-vector-icons": "^2.1.0",
    "react-redux": "^4.4.5",
    "redux": "^3.6.0",
    "redux-thunk": "^2.0.1"
  }

De ellos, sin duda alguna el que más me ha parecido “magia” ha sido redux… cómo he podido estar desarrollando sin conocer esta maravilla 😉

Para esta parte del desarrollo cambiamos del IDE (o editor) que estábamos usando hasta ahora, NetBeans, por Atom con Nuclide y ya se ha convertido en nuestro editor de código de cabecera… tranquilos, SublimeText todavía no lo he desinstalado y lo sigo usando para otros menesteres 😉

El soporte que tiene Nuclide de React-Native es sin duda alguna mejor que en otros editores, lógico por una parte ya que ha sido desarrollado también por los mismos, Facebook

Una vez todo funcione junto, el flujo de la app deberá ser como esto:

Flujo de la app

 

Esperemos poder presentar el desarrollo muy pronto 😉

No me aclaro

Hace unos meses (ya casi un año) migré este blog a Drupal 8, en principio solo para “practicar” con el nuevo CMS. Me gusta, y cada vez más, esta versión de Drupal y está haciendo que sea más “elegante” a la hora de programar…pues sí, también se puede ser elegante cuando se programa 😉 pero, y tal y como ponía en el blog, creo que WP es más correcto para este cometido, el de blog.

Con ello no quiero decir que Drupal no sirva para esto, al contrario, pero creo que si se trata “solo” de un blog, WP es más que suficiente.

Ahora vendrán los WP lovers a darme “caña” y decirme que con este CMS también se pueden crear más cosas a parte de un blog…

Entonces, ¿qué co#o hago con el otro blog? 😛

Y ahora qué, o por qué tener 40 no es ­únicamente de fiebre

Pues sí­, hace ya unas semanas que pasé la psicol­ógica barrera de los 40 “tacos” y… no ha pasado nada.

No he tenido (todaví­a) la depresi­ón que mucho amigos me han dicho que tendrí­a, no me he comprado la moto, como otros me decí­an, querí­a salir a correr (running suena más cool) y ni me he comprado las zapatillas, ahora, eso sí­, he descubierto steam quién me lo iba a decir teniendo unos socios como los que tengo (por jugones claro) 🙂

Este año, además, ha sido la primera vez que me he podido tomar unas vacaciones de más de ¡¡¡20 dí­as!!!, aunque por problemas personales, no las hemos podido disfrutar como nos hubiera gustado, me lo he pasado francamente bien.

Mis hijasUna cosa a celebrar también, han sido los 5 años que hemos cumplido en Geekia y que, seg­ún las estadí­sticas:

8 de cada 10 nuevas PYMES fracasan antes de cumplir los 5 años. Y tan solo 1 de cada 10 consigue sobrevivir más de 10 años.

O sea, que pertenecemos a ese 20% de empresas que todaví­a existen… COMO MOLAAAA 🙂

SPAM SPAM pero ahora en Analytics

El SPAM cada vez se vuelve más “listo”. Correos, comentarios en blogs, redes sociales, buz­ón de casa, el cristal de mi coche 😛 y ahora también en las analí­ticas de Google.

Hay mucha informaci­ón sobre ello en la red, pero si os interesa aprender un poco más, echadle un vistazo a este post de @laux_es que lo explica bastante bien y es en el que me he basado para poder hacer lo mismo pero en Apache.

La alarma salt­ó después de comprobar una subida en el consumo del servidor. Comprobando las analí­ticas vi que la mayorí­a de los sitios que habí­an subido, lo hacian de la misma forma, referencias. “Blanco y en botella”, estaba sufriendo un “caso agudo de spammierditis” (creo que voy a tener que ver menos a Ned Flanders) y habí­a que ponerle remedio. Lo primero deberí­an ser los filtros de las propias análiticas  y evitar las peticiones a nivel de servidor.

La opci­ón más sencilla es a traves de .htacces

RewriteEngine On
RewriteCond %{HTTP_REFERER} ^http(s)?://(www\.)?.*4webmasters\.org.*$ [NC,OR]

.

.

… y todo el listado de webs chungas

El problema con este sistema, es que al usar principalmente Drupal en los desarrollos, tocarí­a cada vez que hay una actualizaci­ón del core, tener que modificar manualmente esos .htaccess. No es muy ­óptimo la verdad.

Así­ que he optado por una soluci­ón en el httpd.conf con la técnica de Deflector.

Para ello he creado un deflector.map con el listado de esas “dudosas” referencias que por desgracia me imagino que crecerá 🙁 y las he llamado en cada uno de los VirtualHost que tenemos en el server:

RewriteMap deflector “txt:/path/to/deflector.map”

RewriteCond “%{HTTP_REFERER}” !=””
RewriteCond “${deflector:%{HTTP_REFERER}}” “=-”
RewriteRule “^” “%{HTTP_REFERER}” [R,L]

RewriteCond “%{HTTP_REFERER}” !=””
RewriteCond “${deflector:%{HTTP_REFERER}|NOT-FOUND}” “!=NOT-FOUND”
RewriteRule “^” “${deflector:%{HTTP_REFERER}}” [R,L]

De esta forma tengo un ­único archivo com­ún a todos los sitios y que podrá ir creciendo en el futuro sin necesidad de ir “tocando” uno a uno cada sitio.