Instalando varnish

En un artículo anterior ya hicimos una introducción previa a varnish por lo que si quieres saber mejor cómo puede ayudarte te aconsejo que lo leas por encima.

En este artículo os voy a explicar los puntos mínimos que hemos de cubrir para tener una configuración mínima de varnish funcionando. Al acabar el tutorial tendrás una instalación mínima que funciona, que cachea en parte tu aplicación web y que será la base para construir sistemas mucho más complejos que se adapten a tus necesidades.

Consideraciones previas

El tema de los puertos

Como bien sabrás los servidores web funcionan habitualmente escuchando el puerto 80 para http y el 443 para https (En este artículo dejaremos de lado https ya que debido a que el tráfico está encriptado hay que tener algunas consideraciones adicionales).

Varnish es un acelerador web que se coloca delante del servidor web, entre este y el usuario. Es decir, las peticiones que antes se dirigían hacia el web server, ahora las atenderá varnish, y varnish se encargará de hablar con el servidor web.

Por tanto, varnish y apache (o nginx) no pueden estar escuchando en el mismo puerto.

Existen varias soluciones a este problema. Podríamos instalar varnish en otro servidor, siendo esta una de las soluciones habituales en entornos de alta demanda.

También podemos mover el puerto en el que apache atiende a otro diferente, por ejemplo el 8000. Entonces, dejaremos que varnish sirva sobre el 80 y realice las peticiones sobre el 8000, donde el servidor web le atenderá.

Varnish en el mismo servidor donde ya corren varias webs

En mi caso, me encontré con que tenía varias webs en el servidor, todas ellas corriendo con apache y, por supuesto, en el puerto 80. Yo quería instalar varnish en el mismo servidor, por lo que debía hacer varios cambios en las configuraciones que me iban a dejar las webs caídas por algo de tiempo.

Yo aproveché para hacer un cambio de servidor completo, gracias a las ventajas de los servidores virtuales. Creé una nueva instancia, instalé un sistema limpio y actualizado, configuré apache para correr en el puerto 8000 y varnish en el 80 moví sólo una web. Una vez estuvo todo correcto, empecé a mover webs del server antiguo al nuevo. Cuando finalicé la migración de todas las webs apagué el server antiguo. Sólo pagué por dos servidores durante los días que los tuve en marcha pero el proceso me sirvió para limpiar bien la casa.

Otra alternativa si no quieres, o no puedes levantar otra máquina virtual es instalar varnish en el puerto 8000 en lugar del 80. A partir de aquí, sólo tu sabes que corre en el 8000 (también puedes filtrar el tráfico por IP para que nadie haga el cotilla). Así puedes ir probando todas tus webs con varnish, accediendo a ellas a través del nuevo puerto. Cuando estés seguro de que todo funciona, configuras apache para servir en el 8000 y varnish en el 80, es decir, le das la vuelta a la instalación. Es bastante sencillo y seguro.

Memoria y CPU

Varnish es básicamente un consumidor de memoria y CPU. En realidad, básicamente de memoria, porque la CPU que usa la está ahorrando a otros servicios como el servidor web o la base de datos.

En mi experiencia,  con 500 MB o 1 GB es suficiente para que varnish suponga una mejora MUY importante en rendimiento del server. Pero estos números dependen de cada uno, tipo de web, comportamiento de las visitas, si usamos un CDN para estáticos o bien si los guardaremos en varnish, etc…

Si instalas varnish en tu servidor actual, tienes que asegurarte de que dispones de esa memoria adicional. Ten en cuenta también que cuando varnish esté correctamente configurado, tu apache correrá mas ligero por lo que necesitará menos recursos que pueden asignarse a varnish.

Si lo estás instalando en un servidor nuevo que hará de frontal, mi consejo es que empieces con una configuración mínima de 2GB o 4 GB que siempre puedes ampliar en el futuro, especialmente si corres con virtual servers. ¿Todavía con máquinas físicas? Tendrás que llamar a tu proveedor para le meta RAM, pero.. ¿De verdad estás usando aún máquinas físicas?

Instalando varnish

Ya he hablado antes de que existen diferentes configuraciones posibles. Aquí vamos a explicar como instalar varnish en un servidor nuevo, donde un apache escucha en el puerto 8000 y varnish correrá delante de el en el puerto 80.

Dependiendo de tu sistema operativo tendrás que descargar el paquete del repositorio adecuado. En mi caso, usé un debian y la instalación fue mi sencilla, simplemente un

sudo apt-get install varnish

El archivo de configuración de varnish es /etc/default/varnish. Allí configuré varnish para usar el puerto 80 y una memoria de 1024 MB. Esta es la parte que te interesa:

DAEMON_OPTS=»-a :80 \
-T localhost:6082 \
-f /etc/varnish/default.vcl \
-S /etc/varnish/secret \
-s malloc,1024m»

Un restart de apache y varnish, y todo está corriendo ya bajo varnish.

sudo service apache2 restart

sudo service varnish restart

NOTA: El orden es importante. A partir de ahora, siempre que quieras reiniciar tu servidor web debes reiniciar primero apache y luego varnish. Si lo haces al revés, varnish podría no reflejar parte de los cambios que hayan necesitado reiniciar tu apache.

Y ya lo tienes, si visitas tu web debería funcionar. El navegador ha pedido la página al puerto 80, allí varnish ha atendido la petición, ha visto que no tenía la página en memoria y la ha solicitado al apache. Cuando ha obtenido la respuesta, la ha entregado a tu navegador.

Puedes usar firebug u otro plugin que estudies las cabeceras de respuesta de la petición.  Verás que la respuesta incluye algunos campos como  Age=0, Via=1.1 varnish-v4 y X-varnish.

Varnish instalado, pero, ¿Está funcionando?

Técnicamente si. Está funcionado. Si el ejemplo que has usado es una página estática con algunos recursos pesados como imágenes notarás claramente como se sirve más rápido. Puedes verlo fácilmente con firebug, evaluando los tiempos de respuesta. Puedes comparar pidiendo la misma página al puerto 80 y al 8000 y mirando los tiempos.

También puedes fijarte en la cabecera http llamada age. Si tiene un valor diferente a cero y se incrementa en cada petición, significa que se está sirviendo desde la cache.

También puedes abrir tu log de apache y realizar múltiples peticiones. Verás como sólo aparece la primera. El resto, se entregan desde varnish y apache ni se entera.

También puedes usar la herramienta de consola varnishstat para ver que es lo que está pasando en varnish. main.cache_hit es un indicador que deberíamos mirar. Expresa el número de peticiones que se han servido desde la cache de varnish.

Mi varnish no cachea

Puede ocurrir, y en la realidad es muy frecuente, que después de una instalación básica de varnish no notemos ninguna mejora. Esto puede deberse a diferentes motivos que iremos exponiendo más adelante.

Uno de ellos puede ser la configuración de tiempos de expiración de tu apache. Si apache está sirviendo las páginas indicando que no se cacheen, o sin tiempos de expiración, varnish obedecerá a esas directivas y no cacheará salvo que se lo digamos explicitamente.

Otro motivo son las cookies. Como sirven para guardar estados dentro de una sesión concreta, varnish es muy conservador y por defecto decide ignorar cualquier petición que tenga cookies, para evitar riesgos y servir una página de un usuario a otro. ¡Imagina que ocurriría si consulto mi saldo bancario y me enseñan los datos de otro cliente!

En el siguiente artículo os explicaré como solucionar el tema de las cookies y os mostraré lo que debería ser un archivo básico de configuración que ofrece un buen rendimiento.

Varnish. ¿Qué es y cómo puede solucionar casi todos tus problemas?

Dice la wikipedia que Varnish es un acelerador de aplicaciones web, también conocido como un caché de proxy http inverso. Vale, muy bien, y eso, ¿Que significa y para que sirve?

En realidad es bastante sencillo. Se trata de un servicio que se coloca entre tu servidor web y tus clientes, es decir, entre tu apache o nginx y los navegadores o servicios que realizan peticiones a tu servidor. La parte interesante es que se encarga de cachear en memoria peticiones de recursos (páginas, imágenes, css, javascripts, etc..) que se le hacen recurrentemente a tu servidor http. Eso significa que se ahorrarán muchas peticiones a tu servidor web, que serán servidas directamente a los clientes desde memoria y no desde disco.

Tus visitantes tendrán una mejor experiencia porque es verdaderamente rápido y tu servidor http funcionará mucho más relajado ya que tendrá que atender muchas menos peticiones.

Lo más interesante de varnish es que es muy rápido. Mucho más que un apache o nginx. Un servidor pequeño puede pasar de un límite de 10 o 100 peticiones por segundo a varios miles. Trabaja en memoria y está programado a bajo nivel. No toca el disco y básicamente usa dos recursos como son la memoria y la CPU que habitualmente están desaprovechados en un servidor web. Los recursos de un servidor se usan más y mejor.

¿Quien necesita un varnish?

Generalmente se entiende que necesitas un varnish en servidores de alto rendimiento, es decir, aquellos que tienen muchísimas peticiones por segundo. Mi opinión es mucho más amplia. Practicamente cualquier instalación puede beneficiarse de un varnish ya que:

  • Varnish acelera muchísimo la velocidad de entrega de los recursos de tu web. Eso es bueno para la experiencia de los usuarios y también es muy bueno para el SEO.
  • Varnish libera recursos de tu servidor. Eso significa que podrías contratar un servidor con menos memoria o CPU y asumir la misma carga de trabajo. Muy interesante para los que tenemos contratada una VPS para nuestros jueguecitos.
  • Varnish permite escalar horizontalmente, es decir, te permite disponer varios servidores web que entreguen el mismo contenido. Lleva implementado un balanceador de carga que puede ayudarte mucho si un día tu web es más famosa que facebook. Puedes empezar con un único servidor y poco a poco ir añadiendo servidores en función de tus necesidades.
  • Puede ayudarte con la seguridad de tu web. En parte porque te asegura más capacidad de carga, es más difícil que te lo tumben. Además, muchas reglas de seguridad que habitualmente colocamos en un htaccess pueden llevarse a la configuración de varnish, respondiendo antes y más rápido que un apache.

La pregunta del millón. ¿Es fácil?

Si. Es sencillo de instalar. La documentación es buena aunque se echa en falta un tutorial. A veces hay que leer más de lo deseable, pero aquí estoy yo para ayudarte ;-). Hay muchos recursos en la red que te pueden ayudar.

Necesitas algunos conocimientos mínimos de configuración de servicios web. Por ejemplo, si varnish corre en el mismo servidor que apache, tendrás que cambiar el puerto en el que apache escucha (generalmente el 80), porque no puedes tener dos servicios escuchando el mismo puerto.

Si instalas varnish en otro servidor (muy recomendable si piensas balancear carga en el futuro), tendrás que apuntar tu dominio a la nueva máquina.

Yo no soy ningún lumbreras como devop y monté mi primer varnish en unas horas.

¿Es peligroso usar varnish?

Respuesta rápida. No.

Respuesta más meditada. Depende de ti.

Por defecto, varnish no cache nada que tenga una cookie. Las cookies se usan para mantener sesiones de usuarios, por ejemplo. Como varnish no sabe cual es el objetivo de una cookie en concreto, simplemente no hace nada si ve cookies. En la mayoría de instalaciones no existe ningún peligro usando un varnish por defecto. Sin embargo, la principal frustación es que varnish apenas hace nada en muchas instalaciones porque casi todas las webs usan cookies. No te preocupes, que es fácil decirle como ignorarlas.

Por otro lado, varnish es una cache. Es tu responsabilidad saber que puedes cachear y que no. Como ya hemos dicho, varnish es muy miedoso y no cachea nada si intuye algún peligro. Mediante los ficheros de configuración le diremos que riesgos debe ignorar. Por ejemplo, es habitual decirle a varnish que no cache ninguna página de administración, o que ignore todas las cookies excepto las de sesión.

Varnish para contenido estático como imágenes o assets

Las páginas web tienen mucho contenido estático que se entrega una y otra vez en cada página y que raramente cambia, por ejemplo, imágenes, archivos css o javascripts. Este tipo de archivos son candidatos de primer nivel a ser cacheados y, en realidad, generalmente el propio browser ya los cachea. Con varnish puedes, además, evitar que apache esté sirviendo una y otra vez el mismo recurso, dedicándose sólo a aquello que es importante, generar páginas html.

Hay alguna línea de pensamiento que cree que no es buena idea hacerlo. Argumentan que las imágenes o vídeos consumen mucha memoria, limitando la cantidad de entradas que varnish puede asumir. Algunos de los defensores de esta idea usan CDNs para servir contenidos estáticos. Otros usan nginx que tiene mecanismos para cachear en memoria estos contenidos estáticos. It’s up to you! Es una decisión de arquitectura.

Personalmente, soy un gran defensor de usar varnish para contenidos estáticos, especialmente en instalaciones pequeñas. Además, es muy fácil de configurar. Si miras un log de apache verás que la mayoría de peticiones son de pequeños archivos estáticos. ¿Cuantas veces se pide el logo de tu web o tu favicon? Con varnish, esas peticiones desaparecen.

Varnish con WordPress

Varnish es completamente agnóstico respecto al tipo de web o contenido que se está entregando. Sólo sirve y cachea peticiones web. Por tanto, funciona perfectamente con wordpress. Sin embargo, como todo sistema de cache hemos de tener en cuenta conceptos como la invalidación de entidades.

Un ejemplo. ¿Que pasa si varnish está cacheando tus páginas por 30 minutos, pero alguien añade un comentario en un post?  Tenemos dos soluciones. La primera, ignorar el problema. El comentario aparecerá cuando pasen los 30 minutos de vida. La segunda, purgar la cache automáticamente. Sin miedo. Es fácil. Los mejores plugins de cache de wordpress saben hablar con varnish y pedirle que invalide una página cuando se produce un cambio. Simplemente tendrás que configurar tu varnish para que acepte peticiones de purge y configurar tu wordpress para que lance esas peticiones cuando lo estime conveniente.

Varnish con Symfony y otros frameworks

Symfony tiene mecanismos casi de serie para comunicarse con un varnish u otros proxies. Tienes que mirarte el tema de ESI (Edge Side Includes). Seguro que otros frameworks también lo usan. En todo caso, no es difícil de implementar a mano.

Básicamente, lo de ESI consiste en crear unas marcas en html que le dicen a varnish u otros CDNs que determinadas partes de tu página pueden ser diferentes para cada usuario. Por ejemplo, el menú de un usuario logado puede ser diferente a uno anónimo.  En esas marcas ESI se le dice que url debe solicitar al servidor para recuperar esa parte de la información.Cuando varnish encuentra esas marcas en una página que está en su memoria, realiza una llamada al apache para cargar la parte de la página que le falta, la incluye en la página madre y la entrega al cliente.

Aquí hay algunas consideraciones que desarrollaré más ampliamente en otro tema. Y es que symfony es un framework pesado y a veces puede suponer un problema hacer muchas llamadas esi dentro de la misma página, resultando en una carga más lenta de  tu web. Pero existen estrategias para minimizar el problema y aún así el uso de varnish puede mejorar el rendimiento de tu servidor a cambio de una entrega de algunos recursos algo más lenta.

 

Ofertas de trabajo: ¿De que palo va la empresa?

Durante estos últimos meses he hecho varias entrevistas laborales, en realidad, muchas entrevistas. Y he leído muchísimas más ofertas de trabajo, todas relacionadas con el mundo de la programación php y/o web, en el área de Barcelona, donde vivo. Hay muchas cosas que contar, por ejemplo cuales son los mejores portales, como detectar empresas interesantes, saber lo bueno y lo malo de las carnicas (consultoras les llaman), como evitar perder tu tiempo y el de tu entrevistador, etc…

Pero hoy me voy a centrar más en como detectar el rollo que lleva una empresa, que te vas a encontrar allí y que esperan de ti, basándome exclusivamente en la redacción de la oferta de trabajo. Me he centrado en mi área, que es el php y el desarrollo web en general. Seguro que los javeros tienen otras historias similares o incluso más surrealistas.

Empresas chupiguais con capital guiri que hacen barbacoas

Las detectarás porque siempre escriben las ofertas en inglés. No siempre es así, pero suelen pedir buen nivel de inglés porque el jefe es guiri y está hasta cansado de relacionarse con mediterráneos bajitos que gritan mucho. A menudo hablan de las barbacoas, algo que no cuadra demasiado con las aficiones barcelonesas, tan acostumbrados que estamos a ver cemento por todas partes. Apenas sabemos que hacer ante una hamburguesa rodeada de llamas.

Suelen incluir frases como «No nine to six mentality» que viene a significar que vas a tirar más horas que un reloj o «startup ambient», que es como decir que te pagarán poco, igual te despiden en seis meses, pero te prometen ser CTO en 1 año.

Importante Empresa del Sector … busca = Cárnica

La verdad es que en estos tiempos se esconden poco. A veces cuesta detectarlos porque cambian de nombre cada dos por tres o usan palabrejas que se confunden en google para que no descubras que es un tío con un móvil en una mesa de coworking.

No tienen porque ser malas ofertas, depende un poco de la consultora. Mis últimos dos trabajos los he conseguido así, o sea que pueden ser de ayuda.

Pero hay que tener algunas precauciones con ellos. Por ejemplo, si la oferta es muy genérica, sobretodo a principio de año o en verano, significa que no hay una oferta clara detrás. Sólo están recogiendo perfiles para su base de datos, esperando tener candidatos preparados cuando les surja la necesidad. Salvo que no te importe, sólo te harán perder el tiempo y con suerte te llamarán dentro de 3 meses.

Otra precaución; busca ofertas similares en otras cárnicas. Es común que una empresa pida el mismo perfil a varias consultoras. Una vez me presenté a tres entrevistas para la misma empresa. Tres llamadas telefónicas, tres reuniones, dos exámenes (al tercero le envié a cagar). Si ves la oferta repetida, busca la mejor consultora. Si puede ser elige la cárnica que sólo cobra la selección, incorporándote con nómina en casa del cliente. Los que subcontratan simplemente se llevarán parte de tu sueldo y procurarán retenerte con ellos el mayor tiempo posible. A veces pueden recolocarte si el proyecto se acaba, pero.. ¿A quien le importa? También puedes recolocarte tu mismo y además es poco probable que te aguanten sin hacer nada más de un mes o dos.

Y no te cortes al preguntar el nombre del cliente o las condiciones. No les gusta dar esos datos, pero tu tiempo puede ser más importante.

Si la consultora es sólo un tío sólo con un móvil, malo. Mis dos peores experiencias han sido de esas. Por lo general se trata de un antiguo «recruiter» que dejó una consultora y se ha montado por su cuenta. El sector del recruitment es muy cerrado. Sus antiguos compañeros se la tienen jurada, sus antiguos clientes le conocen y saben que no puede garantizar nada. Es muy probable que tu currículum acabe en la basura y una posible oferta laboral cerrada para siempre.

Inmenso stack tecnológico

Encontrarás una lista interminable de conocimientos necesarios o recomendables para conseguir el puesto.

Sacado de una oferta real en una startup barcelonesa: Big Data, Nagios, Chef, Puppet, Ansible, Apache, Nginx, Ruby, Python,  Git, Solr, Tomcat, JBoss, Passenger, Unicorn, CloudWatch, Zabbix, Redis, Memcached, ElasticSearch, Cassandra, DynamoDB, Docker, VirtualBox, MongoDB, PostgreSQL, MySQL, AWS.»

Consejo: Huir como de la peste. Generalmente denota que no tienen ni puta idea de lo que se llevan entre manos, pero han leído mucho en twitter. A veces viene motivado por una dirección que tiene miedo de sus programadores y lleva al absurdo la idea de no reinventar la rueda (una buena idea, por cierto). Otras veces tienen un gurú tecnológico suelto por la empresa que va picoteando de flor en flor instalando la última tecnología que citan en stackoverflow.

En todo caso y, salvo honrosas excepciones, se trata de empresas que buscan desarrollos muy rápidos contrayendo una fuerte deuda tecnológica que puede hipotecar su futuro. Al depender de un stack tan inmenso de tecnologias, a veces demasiado inmaduras, corren un serio riesgo de no poder reorientar su negocio más adelante, o de quedarse pillados cuando una de esas tecnologías pinche, y si no, que se lo digan a los pringados que confiaron en Parse, la plataforma SaaS de Facebook, que cerró sus puertas hace unos días dejando un montón de desarrollos tirados.

Frameworks pesados y plantillas en browser

Por frameworks pesados me refiero a Symfony2, Laravel o Zend, excelentes decisiones para muchos desarrollos web. Pero la contradicción salta cuando a la vez están pidiendo Angular.js o React.js, que son sistemas de plantillas que generan la vista en el cliente (el navegador) generalmente a partir de datos json que se piden al servidor vía ajax.

Este tipo de proyectos han oído campanas y se han subido al carro, sin saber exactamente donde es la fiesta. Les han dicho que eso de las plantillas en el browser es la hostia, que podrán hacer con el mismo código la web y la app android e iOS, ahorrándose una pasta en desarrolladores.

El problema vendrá después cuando descubran que un symfony tarda 100ms sólo en devolverte un «hola mundo». Cuando le tiran 5 o 6 peticiones por página el servidor se queda tieso, el navegador congelado y todo el mundo grita y corre desnudo por la oficina aterrorizado.

Node.js, Go y Erlang + plantillas en browser=la ruta de los valientes o el cementerio está lleno de cadáveres

Si te va la fiesta, te molan las startups y cambiar de curro cada 6 meses, estás de enhorabuena.

Muchos de estos ya se han pegado la hostia antes con los frameworks pesados y las plantillas en browser. Pero, erre que erre, continúan hacia el precipicio y deciden reemplazar todo o parte de su backend por tecnologías más rápidas como Node, Go o Erlang. Y no es que crea que está mal, cuidado, el problema viene cuando programas un backend entero de un ecommerce en node, por ejemplo. En pocos días el código acaba siendo un código spagheti de niveles infumables, lleno de llamadas callback que nadie sabe entender.

Y todo vino por ahorrarte 4 duros en el programador de la app móvil.

No será extraño ver como en unos años aparecerán frameworks de desarrollo en estos lenguajes, si no están apareciendo ya. Mi consejo es mirarte ese tipo de ofertas laborales con mucha precaución. El tortazo puede doler mucho.

Y no es que esté en contra de estos lenguajes. Node.js es muy interesante para acelerar algunas partes de un proceso, por ejemplo, implementar un servidor de publicidad o responder a llamadas ajax muy ligeras. Go es un lenguaje muy bueno, especialmente en computación paralela y al mismo nivel de rendimiento del C. Puede ser una gran elección para encapsular lógica de negocio que necesite mucha computación. Erlang es un lenguaje muy antiguo (1998 aprox) que ha tenido un fuerte resurgir ante la aparición de Node y Go. Básicamente los programadores en Erlang han levantado la mano gritando que ellos ya hacían lo mismo hace 15 años y nadie les hacia ni p…. caso. Y algo de razón tienen.

Domain Drive Design (DDD), Arquitectura hexagonal y Microservicios

Este tipo de ofertas laborales pueden ser interesantes.

En este blog os hablaremos bastante de estos temas, pero como ahora estamos centrados en ofertas laborales os diré que este tipo de empresas suelen tener unos cuantos cuarentones pasados de vueltas cansados de remover mierda en códigos antiguos inmantenibles, que todavía conservan la esperanza de programarlo bien desde cero y de una puñetera vez.

Y es que, no nos engañemos, pocos proyectos empiezan desde cero usando DDD o arquitecturas hortogonales. Requieren mucha visión de futuro y por lo general las prisas para sacar un producto no permiten «perder» el tiempo en sutilezas teóricas que alargan el desarrollo, a priori.

Por lo general se trata de empresas que tienen mucho código picado en algún framework o esquema antiguo, que podía ser muy bueno en su momento pero que hoy no satisface sus necesidades (Los del node.js y compañía acabarán aquí en 5 años). Tienen un grupo de programadores gruñones diciendo que esto es una mierda y que toca rehacerlo desde hace años. La gente se va, entra personal nuevo que no entiende nada y poco a poco la cosa se va liando. Hasta que un día, alguien en la dirección cansado de ver programadores inmolados a lo bonzo piensa que quizás tenían razón y toque meter algo de pasta para refactorizar.

Y aquí es donde los viejos del lugar deciden que a partir de ahora no se casarán con ninguna tecnología ni framework. Han oído hablar de DDD y piensan que es la solución a sus problemas ya que a nivel teórico permite aislar tu capa de negocio del framework y otros detallitos.O sea, vamos a volver a programar como toda la vida, pero usaremos un framework para que no se note.

El papel lo aguanta todo. Prepárate para picar líneas de código redundantes por un tubo y escribir más documentación que libros tiene Corín Tellado.

Pero posiblemente te lo pases bien.

Fullstack Developer

Un «palabro» nuevo que hace unos años se resumía en LAMP+php+sql+html+css+javascript+photoshop. Suena mejor decir fullstack developer, ¿verdad? 😉

En resumen, que vas a hacer de todo y vas a tirar más horas que un reloj, porque tanto estarás preocupado porque al jefe no le gusta el botoncito de un formulario como en que la base de datos que diseñó el primo de alguien no tiene ni una tabla bien normalizada.

Si además aparecen las siglas SEO+UX es que quieren que lo hagas bonito. Y si citan angular.js o similar, además te va a tocar pringar con la app de móvil.

Los ágiles

Un clásico en estos tiempos, negocio de antiguos gurús seo reconvertidos en scrum masters. No hay mucho que decir, a fin de cuentas la mitad o más de las ofertas de hoy en día incluyen las siglas agile o scrum.

Sólo dos comentarios.

El primero, tu di que si, que lo tuyo es el scrum. ¿A fin de cuentas, porqué contradecir a tu futuro empleador?

Lo segundo, una pequeña reflexión. Poco después de acabar mis estudios apareció una metodología de desarrollo nueva  lamada Proceso Unificado de Desarrollo (PUD) que mucha gente conocía como UML. A mi me preocupaba el tema, a fin de cuentas no conocía de que iba la cosa y los diagramas del UML eran infumables, apenas podías entender los casos de uso y nada más. En mi empresa se gastaron una pasta en formación y herramientas. Hoy el UML está más tieso que Matusalén y lo que se lleva es el Scrum y las metodologías agile. Los egipcios ya hacían pirámides, ¿Que métodología usaban entonces?

El consejo: Tu di que si.

La verdad es que el scrum, como cualquier otra metodología planificación es interesante, útil y siempre es infinitamente mejor que no usar ningún método. La realidad es que siempre que veo equipos prácticando scrum detecto los mismos problemas: Todas las empresas lo están adaptando pero ninguna finaliza, los equipos se autoorganizan a menudo de manera clandestina y la burocracia es mayor de lo deseable.

O sea que, di que si, que ya inventarán algo nuevo.

La Integración Continua, Jenkins y el TDD

Don’t worry, be happy. Viene a ser la versión moderna de tocar el código en el servidor, pero añadiendo unas cuantas capas para que no se note.

No te asusten estas siglas, por lo general se trata de equipos de trabajo bien gestionados. Por lo menos sabes que usan algún sistema de control de versiones, con developers que saben que de vez en cuando la cagan, y por eso programan pensando en las pruebas de su código.

En mi opinión, son empresas recomendables.

Sin embargo, no es oro todo lo que reluce, luego no te quejes si no te avisé. El sistema consiste básicamente en que cualquier funcionalidad debe tener un test automático asociado. Es más, cualquier desarrollo debe hacerse siempre pensando primero el test (Test Drive Design). Una vez subido al control de versiones (buena cosa) un sistema descarga el código, ejecuta los test y si todos está correcto sube a producción. El problema viene de aquellos que creen que puede programarse un test para cualquier cosa, y no siempre es así. Si el equipo no incluye otro tipo de pruebas, puedes acabar en la versión antigua de tocar código en producción.

Conocimientos de UX (Usabilidad)

¡Alarm, Alarm, Alarm!

Lee el resto de requisitos y decide en consecuencia. Muchos no tienen ni idea de lo que significa usabilidad. Para algunos empresaurios significa «hacer cosas bonitas, no como el otro programador que cada botón lo pintaba de un color».

La usabilidad es un área superinteresante que tiene poco que ver con el diseño. Se trata de medir las mejoras que se producen sobre unos indicadores definidos por negocio cuando hay cambios en el interfaz de usuario.Por decirlo así, es más estadística que diseño. Intenta responder preguntas como «¿Cuantos usuarios comprarán si hago el botón más grande o si cambio una call to action?»

Si lo que están pidiendo es auténtica usabilidad, vas a tener suerte. Si lo que piden son botones bonitos, espero que te guste el photoshop.

Otros

Me gustaría ir extendiendo este artículo con otras burradas que se os ocurran. Si tienes alguna buena historia, no te cortes y déjanos un comentario.