Después de años de haber ocupado WordPress para alojar mi blog, decidí que era hora de un cambio radical y fue así como di con Jekyll, que vendría siendo una plataforma simple para servir el contenido del blog. Tiene algunos puntos en contra así como algunos puntos a favor, y estos últimos pesaron más y así fue como se dio que decidí implementarlo.

El principal punto a favor es que no tendré que lidiar con actualizaciones, moderaciones y todos esos temas anexos a WordPress. Estaba corriendo WordPress 3.2.1, que salió el 4 de Julio del 2011: fueron 3 años y medio en que simplemente no me dio el tiempo para verificar que todos los plugins que tenía habilitados siguieran funcionando como deben con una nueva versión. Estaba tan cansado del spam que simplemente decidí cerrar absolutamente la posibilidad de mandar correo desde WordPress mismo.

En fin, eso ya quedó en el pasado y ahora sólo existe Jekyll, que espero me acompañe por los años que vendrán. Prometo que haré una serie de posts acerca de Jekyll y sus ventajas, así como tutoriales para que ustedes mismos, mis fieles lectores, puedan montarlo en sus propias implementaciones.

Hasta la próxima!

Lo único que tenemos que hacer es hacer la instalación mínima, y una vez instalado ejecutar los siguientes comandos como root:

yum groupinstall "X Window System"
yum install gnome-classic-session gnome-terminal nautilus-open-terminal control-center liberation-mono-fonts
unlink /etc/systemd/system/default.target
ln -sf /lib/systemd/system/graphical.target /etc/systemd/system/default.target
reboot

Fuente

Desde hace algún tiempo que me vengo corriendo de no tener que instalar gettext en Mac OS, ya que implica hacer algunos cambios en código fuente, pero hoy ya no lo pude postergar más: composer se quejaba de que necesitaba una dependencia, de lo contrario no instalaba el software que necesitaba. Manos a la obra entonces, aquí una guía rápida de cómo instalar gettext para PHP en Mac OS X Mavericks.

Aunque yo no he sacado la última certificación todavía, si he estado leyendo acerca de cuáles son los requerimientos y nada mejor para eso que referirse a Lorna Jane, la cual conocí durante algunas charlas y es toda una eminencia en el mundo de PHP. Ya ha publicado libros y yo mismo me había colgado varias veces de su blog para proyectos en los cuales había trabajado. Además hace charlas bastante dinámicas y entretenidas, así que si tienen la oportunidad de ir a verla a alguna charla, no se lo pierdan!

Cabe la casualidad que ella también enseña para la certificación y como tal, fue una de las primeras personas en sacar esta nueva versión. Para el gusto de nosotros, creó un compilado de varios documentos que nos pueden resultar útiles a la hora de estudiar para esta nueva versión. Lo que sí, tiene un costo de US$25, pero vale la pena ya que son 70 preguntas de ejemplo.

Pasen a dar una vuelta por su blog y vean además las demás guías que ella recomienda, hay algunos links muy buenos.

http://www.lornajane.net/posts/2014/zend-certified-php-developer-5-5

Por lo demás, hace algún tiempo también hablé de la certificación en mi propio blog, pero eso es para la versión 5.3, la cual pueden ver haciendo click en este pedazo de texto.

Tal como prometí en uno de los primeros posts del año, ha llegado la hora de cumplir con mi mandamiento y este es el segundo post en la serie de posts que seguirán al respecto de la internacionalización y localización de su sitio.

En esta entrega, explicaré a grandes rasgos cómo capturar la locale de un usuario, con algunos métodos de fallback si es necesario.

Lo primero que les contaré, es que gran parte de la información de un usuario ya la manda el navegador: un usuario que habla español es muy probable que ocupe un navegador en español, como también un usuario de habla holandesa ocupará un navegador en holandés.

El año pasado (2013 ya!) di una conferencia acerca de las cosas que hay que tomar en cuenta con la internacionalización y la localización. De tal forma como presenté en esa charla, también expondré algunos de los puntos más importantes en mi blog, de forma que quede accesible para todo el mundo.

Lo primero que hay que tomar en cuenta es la diferenciación entre localización e internacionalización. Estos dos términos suelen confundirse fácilmente, cuando tienen una diferencia fundamental entre ellas, así que con esto ya sabrán cómo entretener a sus mamás/esposas/pololas demostrando su vasto conocimiento en cosas que nada les interesa.

La localización es la traducción propiamente tal de cadenas de textos y otros ajustes que tienen que ver con las costumbres y reglas de un cierto lugar. La internacionalización en cambio se refiere al hecho de preparar la aplicación (hacerlo compatible) para que pueda ser localizado. De esta manera, podemos decir que internacionalizamos nuestra aplicación para que pueda ser localizado.

Si bien es cierto he estado desaparecido por bastante tiempo, no me he olvidado de mi blog querido y he hecho hartas mejoras: de partida me cambiaré a otro host, ya cambié el DNS (de GoDaddy a NameCheap), y estoy trabajando en un nuevo diseño del blog mismo que se enfocará un poco más en entregar respuesta de forma más rápida.

Por el momento, sólo me queda desearles a todos un feliz año nuevo!

Hacía ya algún tiempo que no me tocaba instalar un webserver, y justo estos días me tocó instalar tres (con otro más por hacer en el horizonte), así que decidí hacer una nueva entrada actualizando el antiguo y de esa forma ahorrarme algún que otro problema que pudiera surgir en el futuro.

Lo que haremos con esta máquina es instalar Apache y la última versión estable de tanto PHP como MySQL. Además configuraremos algunos valores bases de SELinux e iptables, y finalmente instalaremos Logwatch para recibir un informe día a día de la actividad en el servidor. Aprovecharemos asimismo de instalar también OPcache para PHP, el cual ya viene incorporado de forma predeterminada en PHP 5.5, pero para la rama 5.4 todavía no.

Hace poco se decidió, con gran ayuda de Zend, incluir Zend Optimizer+ en el código fuente de PHP como la opción predeterminada para que hiciera de opcode cache en favor de APC u otro. Las principales razones tenían que ver con que con Zend Optimizer+ estaban trabajando más personas que con APC (sólo Rasmus Lerdorf estaba trabajando con APC, mientras que de Zend Optimizer+ más personas conocían su funcionamiento [Fuente: lista de correos PHP-DEV]), también es más rápido que APC y como última gran razón (hay varias más), la manera de trabajar es más consistente que APC. Por lo tanto, la opción más lógica era por supuesto realizar el cambio.

A partir de PHP 5.5 ya viene incluida, aunque existen packages para PHP 5.3 y 5.4, tan fácil de instalar como invocar un simple yum install php-opcache. El nuevo nombre pasó de ser Zend Optimizer+ a opcache, así que de ahora en adelante, me referiré sólo a opcache.

Desde que me cambié de trabajo, trabajo (valga la redundancia) con un equipo bastante más grande de gente y uno de los problemas más comunes al que tenemos que hacerle frente es cómo subir código nuevo al servidor final. Hay varios proyectos en paralelo andando y cada desarrollador necesita tener la habilidad de poder subir sus cosas al servidor en producción.

Esta metodología de trabajo si bien es cierto es rápida, también puede provocar un sinfín de otros problemas, aunque los más graves han sido hasta el momento de sincronización: dos personas que trabajan en el mismo archivo y que, al momento de realizar la sincronización con el servidor en producción, topan en la problemática de que aparecen archivos con cambios en los cuales hay un ancestro en común pero del que no se sabe si está 100% listo para subirlo al servidor de producción o no.

Durante mi búsqueda de solución a este problema, di con algunos candidatos de forma de poder automatizar este proceso. Entre los candidatos estaban Capistrano, Phing o Fabric. Sin embargo, por su facilidad de uso y su nula dependencia Phing resultó el ganador absoluto.