Jesús L.C. – Apuntes de un aprendiz
Problem solver, product developer, eternal learner. Refactoring, TDD, CI/CD pipeline, agile
Estas son algunas de las charlas que más me han gustado últimamente: Cómo mejorar como desarrollador, no te fíes, es justo al revés, por Jorge Franco y Angélica Sanz https://www.youtube.com/watch?v=y2k0Zl1xrLg Javier Abadía – Refactorizar rima con Simplificar, o por qué el miedo conduce a código inmantenible https://www.youtube.com/watch?v=iytUjwSfjDE Juanjo Montiel – ¡Se me ha roto la … Continúa leyendo Charlas interesantes Enero 2020
Después de haber arreglado más o menos 1000 bugs en mi carrera como programador (de los que más o menos 700 los había cometido yo), creo que tengo una visión más o menos sencilla de como deberíamos escribir un ticket para que ayudemos lo máximo posible al programador de soporte. Así esa persona no tendrá que devanarse los sesos en entender que es lo que parece está ocurriendo
Ejemplos como los siguientes son de lo más comunes cuando estamos haciendo soporte de usuarios:
– El formulario está fallando
– ¿Qué formulario? ¿Cuál es la URL?¿Qué es más o menos lo que falla?¿Qué estabas haciendo, cuéntame los pasos? ¿Con qué navegador?¿Puedes pasarme una captura de pantalla?…
– El informe que me descargo está en mal
– ¿Qué formulario? ¿Cuál es la URL?¿Qué es más o menos lo que falla?¿Qué estabas haciendo, cuéntame los pasos? ¿Con qué navegador?¿Puedes pasarme una captura de pantalla?…
La primera pregunta que tenemos que hacernos ante un problema así es: ¿Cuál es el comportamiento normal? ¿Que hacía eso que “parece” que está fallando? ¿Tenemos un sitio para trackear las subidas y ver si se hemos subido algo últimamente?
¿En serio? ¿Cómo es posible que la mejor manera de hacer debug sea usando un patito de goma? Aunque visto así, pueda parecer un poco bizarro voy a contarte porqué hacer debug con un patito de goma es más efectivo de lo que parece. No es una técnica novedosa, los programadores más experimentados utilizan esta técnica para encontrar problemas en su código de una manera sencilla e intentar reducir su frustración cuando algo no termina de encajar del todo.
En realidad, está técnica viene explicada en el libro The Pragmatic Programer, voy a intentar explicar que es exactamente eso del patito de goma y porqué creo que es una táctica super efectiva.
Ya hemos hablado de como instalar Varnish para ganar performance en nuestra aplicación web. Utilizar Varnish elimina la necesidad de que una aplicación web regenera la misma página una y otra vez, así ganamos una muchísima velocidad ya que servimos las peticiones web al instante.
Aun así, no es oro todo lo que reluce y el hecho de utilizar Varnish conlleva algunos retos que vamos a discutir: es necesario tener en cuenta qué páginas de nuestro sitio son stateless(sin estado), como son las URL a cachear, tiempo de vida de los objetos en caché, invalidación de la caché… así que antes de adentrarnos en los detalles de la configuración de Varnish vamos a exponer estos temas y a explicar un poco como podemos resolverlos.
Tienes un proyecto, empieza a funcionar, a ganar visitas, mola ¿verdad? pero casi al mismo tiempo el rendimiento empieza a flojear. Las páginas cargan cada vez más despacio ¿Qué hacemos?
Que no cunda el pánico, hay muchas tareas que podemos hacer para mejorar el performance: optimizar partes del código backend, optimizar las llamadas a los assets, minimizar los assets, optimizar queries a la base de datos, cachear las queries con memcached o similar, incluso poner un acelerador HTTP que cachee las peticiones. De eso vamos a hablar hoy, de Varnish.
Varnish es un software que permite contrarrestar la perdida de velocidad de una aplicación web. Para ello Vanish Cache trabaja como proxy inverso, situándose delante del servidor HTTP, cacheando la respuesta de dicho servidor web en memoria. La próxima vez que un usuario visite la misma URL, será Varnish quien la sirva, con ello conseguimos una gran aceleración de las respuestas de nuestra aplicación web.
A los desarrolladores les encanta compartir código en forma de paquetes, apps, o pequeños módulos. Compartir mola, pero una de las características que muchos desarrolladores olvidan son los archivos README. Este archivo es una de las piezas más importantes de los proyectos y muchos desarrolladores no invierten el tiempo suficiente.
Un README empezó como una guía para desarrolladores. Se podía acceder después de descargar el código y mostraba instrucciones relacionadas con la configuración, instalación, derechos de autor, solución a problemas conocidos y mucho más. Los repositorios de código populares empezaron a poner los readme como página principal del proyecto y se convirtieron de ser información técnica a ser directamente la presentación del proyecto. Este cambio significa pasar de ser documentos para desarrolladores a convertirse en herramientas de marketing con la información básica del proyecto.
Ya hemos visto como organizar nuestro repositorio de recetas, así que en este post nos manchados para instalar Virtualbox, Vagrant, Chef y todo lo necesario para tener un entorno de creación de máquinas automatizado. Con esto tendremos entornos autmáticos y podremos dejar de oír eso de «en mi ordenador funciona ;)»
Lo primero de todo es tener Virtualbox, para poder ejecutar las máquinas virtuales, también podemos utilizar VMWare o Hyper-V.
Lo primero descargarnos VirtualBox de aquí https://www.virtualbox.org/wiki/Downloads e instalarlo, yo he utilizado Virtualbox 4.3.8
Ya hemos visto como instalar RVM en otro post, así que no vamos a profundizar en esto. Tenemos que una versión de Ruby >2.0, así que vamos a instalar con la ayuda de RVM Ruby 1.9.3 así que abriendo un terminal en Mac escribimos:
$ rvm install ruby-1.9.3
$rvm use ruby-1.9.3
$ruby -v
Instalar Vagrant es una tarea sencilla, solo tenemos que ir a su web oficial http://vagrantup.com/ y descargarnos la ultima versión, en nuestro caso Vagrant 1.5.1
Existen muchas maneras de unir a Vagrant y chef-solo, la más sencilla es instalar plugins para vagrant. Ahora vamos a instalar una serie de plugins que nos ayudarán a la hora de crear recetas, así que abrimos un terminal (nos aseguramos de estar utilizando ruby 1.9.3 con ruby -v) y escribimos:
vagrant plugin install vagrant-omnibus
vagrant plugin install vagrant-librarian-chef
vagrant plugin install vagrant-hostsupdater
Listo, para comprobar que está todo correctamente instalado solo tenemos que hacer vagrant plugin list veremos todos los plugins instalados en Vagrant. Si queréis ver los plugins disponibles en Vagrant aquí una recopilación https://github.com/mitchellh/vagrant/wiki/Available-Vagrant-Plugins
Anteriormente ya hemos hablado sobre Vagrant para crear máquinas virtuales con las que poder trabajar. También hemos comentado como tener recetas con chef para poder aprovisionar máquinas virtuales. Ahora viene el turno de como tener un sistema propio para disponer de maquinas virtuales y aprovisionarlas de todo el software necesario de manera sencilla y ágil.
Disponer de máquinas virtuales con configuraciones a medida no trae evita dolores de cabeza a la hora de instalar software o de probar desarrollos. Con Vagrant y chef podemos disf¡poner de máquinas idénticas a las que utilizamos en producción, idénticas en el sentido de versiones de software, así nos será más fácil saber si añadir una nueva librería será sencillo. Podremos asegurar que las librerías y frameworks que utilizamos son compatibles 🙂
Con la ayuda de plugins para Vagrant como ommibus podemos disponer de una serie de recetas de Chef con los que instalar aplicaciones como (nginx, apache, mysql, …) de manera sencilla además con Berkshelf o Librarian podremos disponer de un repositorio completo de recetas y utilizarlas como mejor nos convenga.
Hace poco estuvimos hablando de Vagrant y de cómo crear máquinas virtuales para hacer nuestras pruebas, probar nuevas tecnologías o lo que queramos.
Pero es un poco rollo cada vez que creamos una máquina tener que instalar todo el software etc. Desde Vagrant configurando el VagrantFile se pueden hacer muchas cosas, incluso existe GUI como http://getprotobox.com/ que nos ayudan a crear Manifest con los Virtualhost de Apache2 configurados.
Pero hay veces que necesitamos algo más y para ello existen muchas soluciones hoy comentamos una de ellas Chef.
Existen 2 versiones de Chef, una llamada Chef Server enfocado a tener una máquina como servidor de recetas a la que máquinas cliente Chef para obtener la información de configuración. Esta versión es algo compleja y quizás para empezar sea algo difícil de configurar. No obstante, más adelante podríamos abordar esta solución.
Hay veces que nos surgen problemas en nuestro código, así que aquí traemos una serie de “truquitos” para intentar evitar quebraderos de cabeza. Git bisect Es un comando para cuando tenemos un problema con la versión actual y sabemos que en una versión pasada esa parte del software funcionaba correctamente, localizar el commit que introduce … Continúa leyendo Git: Un par de trucos
Jesús L.C. - Apuntes de un aprendiz 