Hacía bastante tiempo que no escribía algo en el blog, así que parto hoy nuevamente con un nuevo post, aprovechando de celebrar el hecho que haya sido seleccionado para dar una charla en PFCongres 2013 en Utrecht, referente a cómo moverse lentamente de SVN a Git.

Una de las temáticas que tocaré en dicha charla, será el traspaso íntegro de un repositorio en SVN, con hooks y otros checks, a Git, que tiene dos tipos de hooks. La primera de estos, es el que ocurre de forma local: ella se referencia hacia la carpeta .git/hooks/ donde se almacenan todos los hooks locales. Sin embargo, estos hooks locales tienen un gran problema: no se traspasan al servidor remoto cuando hacemos un push, con lo cual los únicos que ejecutaremos dichos hooks seremos nosotros mismos: los demás no podrán ejecutarlos.

Este post es una historia llena de sentimientos encontrados, escalofriantes partidos de futbol, encontrarle el sentido a las cosas y volver a vivir como un adolescente enamorado. Ah, y también tiene relación con jQuery. Seguramente a estas alturas ya tengo toda su atención del mundo, así que ahora procederé a explicar el sentido de todo esto.

Corría el año 2001 cuando aprendí de forma bastante incipiente que podía escribir “Hola mundo” en la Web, mediante código escrito por mi en notepad! La primera vez que pude hacer eso, fue en un computador Compaq que tenía un procesador Cyrix que… bueno, francamente era una mierda de equipo. Corría Windows 95 porque no se podía Windows 98, tenía la friolera cantidad de 28MB en RAM y se quedaba pegado sólo porque uno lo miraba (o dejaba de, cualquiera de las dos condiciones servía al menos una vez al día). La cosa es que por aquellos años, mediante tarea en la Universidad, tuve que hacer una página que validara algunos formularios mediante el temido JavaScript: ese lenguaje críptico donde cualquier equivocación significaba que el navegador simplemente dejaba de responder con un mensaje de error tipo “Error en la línea 0, columna 0”. Gran aporte. Debo confesar que jamás me llamó la atención: encontraba JavaScript engorroso, complicado y en general poco divertido de programar (no se podía hacer casi nada que no fuera validar formularios). Si quieres leer cómo sigue esta historia, haz click en “continuar leyendo”.

Desde hace algún tiempo que tenía las ganas de aliviarle un poco de carga a mi Mac y de paso, acelerar el desarrollo en un par de milisegundos por request, aunque la verdad estaba tan cómodo con el rendimiento del equipo que en realidad no hacía falta. Sin embargo, en un rato de ocio me propuse a instalar el famoso nginx como un proxy y servidor de contenido estático, cosa de dejar al apache sólo encargado de la parte PHP. Quise expresamente esta solución ya que he visto nginx sirviendo PHP directamente y puede dar lugar a unos bugs muy pero muy extraños, así que como buen developer que soy, prefiero quedarme con algo estable y bien probado para poder avanzar rápido en mi trabajo a tirarme a probar cosas nuevas que pueden no resultar como quiero y hacerme perder tiempo valioso.

Siguiendo esa misma filosofía, les presento una de las maneras más rápidas de integrar nginx en el sistema de la manzanita y de paso podrán apreciar que especialmente en lo que concierne contenido estático, andará bastante más liviano el equipo, especialmente teniendo en cuenta que Apache levantará PHP con xdebug, profiler y un montón de cosas más que no necesitamos en un simple CSS, imagen o archivo con JavaScript.

Siguiendo con el artículo previo, ahora toca saber cómo instalar ese tan ansiado servidor propio de Git al mismo estilo que SVN, de forma que nosotros podamos controlar los accesos sin el inconveniente de pagarle a Github para que él almacene los proyectos por nosotros.

Lo primero será un pequeño resumen de todo lo que se verá en este artículo, de modo que vayan preparando sus mentes ávidas de conocimientos:

• ¿Por qué Gitolite?

• Instalando Gitolite

• Configuración de llaves públicas y privadas

• Creando un repositorio

• Agregando más clientes al repositorio

• Notas de instalación en Windows

• Importando proyectos desde SVN a Git

No son pocos temas y trataré de ser lo más resumido posible sin dejar de explicar ciertas cosas para entender el proceso. Así que partamos.

Desde hace algún tiempo que en el trabajo tenemos cada vez con mayor frecuencia un problema bastante grave: hay tantas cosas nuevas de tantas personas que actualmente a SVN se le está haciendo la pista muy pesada y además, el no poder desactivar rápidamente características que no dan un buen resultado (AKA las que empeoran las ventas) complica las cosas aún más.

Por este hecho, en una de las reuniones del lunes (que por increíble que parezca se hacen todos los lunes), me pidieron si podía encontrar alguna solución a este nuevo problema que estaba surgiendo. A decir verdad, en un principio no le dediqué mucho tiempo al tema debido a que estaba ocupado con otras cosas hasta que el martes pasado, para el update del miércoles estuve todo el día clasificando código y viendo qué era apto para poder salir a producción y qué no. Por supuesto que esto representó un dolor de cabeza descomunal debido a que ocurría muy a menudo que más de una persona había hecho modificaciones a los mismos archivos en distintos lugares. Fue en este momento en que de verdad deseé que hubiera alguna herramienta que me permitiera fácilmente poder ir y revisar de un fix a otro de forma rápida e indolora. ¿El secreto? Esa herramienta existe, lo único malo es que intuitivo no es.

Esta es una noticia cortita para avisarles que desde hace como 2 años tengo cuenta en Github pero que hasta el momento nunca la había ocupado. Como ya les había contado en otro post, cuando fui a la última conferencia me sorprendió mucho lo bien que hablaban de git así que decidí subirme al carro y de esa forma, aprovechar de liberar mis propias classes para que estén abiertos y disponibles al mundo entero. A la vez, actualizarlas me va a ser ahora mucho más fácil que antes. Así, ya era hora de tirarme a la piscina y así es que subí mi primer proyecto libre a github: mis propias classes. Mi dirección es: https://github.com/unreal4u/ y en ella podrán encontrar todas mis classes. Si les interesa saber qué hace cada uno, presiona leer más para ver qué es lo que hace cada class.

Aunque un poco más tarde y corto de lo normal, aquí llegan todos los links interesantes que no alcancé a leer durante octubre.

Aprovecho asimismo de contarle al 14,09% de público que vuelve constantemente a la página, que se vienen varias cosas nuevas, entre ellas:

• Un nuevo skin hecho desde cero para el blog!

• Descubrí git, así que esperen una buena tanda de artículos al respecto

• También volví a trabajar con APC, así que espero que este mes pueda sacar una nueva class y además escribir en el blog sobre lo mismo

Y sin más, los (pocos) links destacados de este mes son:

Hace ya algunos meses atrás, WURFL cambió las políticas para ocupar su sistema, y aunque normalmente soy más asiduo a la fantástica solución y sobretodo variada información que ofrecía la misma (con una altísima tasa de fiabilidad), con los precios actuales todo el interés se me vino abajo. Llegó la hora de empezar a buscar nuevas soluciones a precios más aterrizados, ojalá open-source, lo cual es justamente terreno mío: encontrar soluciones óptimas a menor costo posible. Es así como, en resumidas cuentas, ideé un plan donde si bien es cierto había que pagar, se puede hacer pagando el más barato de WURFL Cloud, pero manteniendo e incluso incrementando la velocidad de detección de un dispositivo móvil, sin sacrificar (mucho) la fiabilidad que se consigue con WURFL. Es así como surgió este post, que servirá dos propósitos: si sólo quieren una detección rápida les espera la solución completa, pero si también quieren saber con precisión cuál es el dispositivo móvil que el usuario está ocupando en ese momento, sigan leyendo que aquí sabrán cómo hacerlo de la forma más barata posible.

Desde bastante tiempo que no hacía esta sección y lamentablemente mi navegador nuevamente se encuentra lleno de páginas donde hay cosas muy interesantes pero que no he tenido el tiempo de visitar o leer en su totalidad (o soy tan pajarón que si creo un bookmark lo olvidaré). La mejor forma que tengo de respaldar esta información es simplemente escribirlas en mi blog así que eso haré. Los links mencionados no tienen ningún orden específico.

A continuación, los links más interesantes colección septiembre 2012:

¿A quién no le ha pasado que sabemos que un proceso determinado es lento y queremos optimizarlo para que de esta forma ande más rápido y los gerentes te promocionen a sub-gerente general para -tiempo después- casarte con la hija de alguno de ellos, unos meses después y gracias en parte al tremendo éxito de esa misma optimización y también porque tu nuevo suegro ya encontró el heredero perfecto, terminar manejando la multinacional y -de pasada- un Lamborghini Y un Ferrari del año? Bueno, aunque suena muy prometedor, cada vez que intentamos optimizar nuestro código no parece surtir efecto alguno dejándonos sin esa posibilidad de primera promoción que hará despegar tu carrera profesional a las nubes.

El gran secreto detrás del por qué nuestras optimizaciones no parecen surtir efecto es lamentablemente debido a una razón bastante simple: el 95% del tiempo creemos o intuimos que cierto pedazo de código es el lento cuando, en la vida real, ese 5% que en realidad descartamos porque es demasiado simple, es el que está provocando el cuello de botella. ¿Quieres saber cómo sigue la historia? Haz click en leer más entonces.