Saltar al contenido

Categoría: Desarrollo y Programación

Automatiza tareas de desarrollo web con Guard

Hace tiempo en una charla de Paul Irish, ví un programa llamado Live-reload para recargar automáticamente una página en el navegador cada vez que realicemos un cambio en ella. Pero nunca había podido configurarla en Linux, luego hace unos días en una entrevista de Addi Osmani vi un comentario que me hizo volver a tratar de instalarla, su comentario fue: «Ya en el 2013 nadie debería perder tiempo en recargar manualmente el navegador».

Así que me puse instalar el programa y descubrí Guard, una aplicación hecha en Ruby para chequear las modificaciones realizadas a archivos y realizar acciones en base a ello. Esto permite por ejemplo, que al realizar algún cambio en un archivo escrito con SASS o SCSS genere el CSS automáticamente, si modificas un archivo JS de desarrollo genere el archivo final ya comprimido, generar el archivo JS desde CoffeScript, entre otros. De esta manera automatiza gran cantidad de tareas que usualmente harías manualmente a través de comandos del Editor/IDE.

Instalación

Aunque existen instaladores para MacOS y Windows los desarrolladores prefieren instalarlo a través de Ruby GEMs, el proceso es sencillo y se aplica para todos los sistemas operativos que soporten Ruby, para ello en la consola debes ejecutar los comandos:

gem install bundle #facilita el proceso
gem install guard #el programa que estamos comentado
gem install guard-livereload #extensión para actualizar el navegador
gem install guard-sass #para pre-procesado de CSS

Configuración

Luego te diriges a la raíz del proyecto que estás elaborando, allí ejecutas el comando:’

bundle init

Nota: Si el comando falla es porque no tienes el comando gem en tu variable $PATH
Esto creará un archivo llamado Gemfile que contiene toda la información de los gems utilizados en el proyecto y las dependencias de lo mismos. Una vez creado con el comando mencionado, lo abres y agregas el siguiente contenido:

gem 'guard'
gem 'guard-livereload'
gem 'guard-sass', :require => false

Luego debes crear un archivo con el nombre Guardfile en la raíz del proyecto, en él se definirán las reglas que deben ocurrir para realizar las acciones. El siguiente ejemplo está diseñado para ser usado en un proyecto PHP con el framework Yii:

# Módulo para que al modificar un archivo SASS genere el CSS ya comprimido
guard 'sass',
:input => 'css',
:output => 'css',
:style => :compressed

#reglas para la recarga del navegador
guard 'livereload' do

#actualiza el navegador al ocurrir cambios en las vistas, modelos y controladores.
watch(%r{protected/views/.+\.php})
watch(%r{protected/views/.+/.+\.php})
watch(%r{protected/views/.+/.+/.+\.php})
watch(%r{protected/models/(.+)/(.+)\.php$})
watch(%r{protected/controllers/(.+)\.php$})

#Comprime los archivos de Javascript utilizando un script llamado compressJS ubicado en la carpeta js/
watch(%r{js/.+\.original\.js}) {`js/compressJs`}

#Una vez generado los archivos JS finales (ya comprimidos) recarga el navegador
watch(%r{js/.+\.js})

#Recarga el navegador cuando se modifica un archivo CSS
watch(%r{css/.+\.css})
end

La sintaxis es watch(%r{EXPRESION_REGULAR_DE_ARCHIVOS}) {comando a ejecutar}, con esto puedes jugar a detectar cambios en algunos archivos y realizar a través de una secuencia de comandos, tareas respecto a ese archivo modificado. También noten como por ejemplo al comprimir el archivo JS no se recarga el navegador, sino en otra regla cuando se modifica un archivo JS, es decir, algunas cosas deben hacerse a través de la definición de varias reglas.

Uso del programa

Para ejecutarlo debes iniciar guard con el comando:

bundle exec guard

A partir de ahora guard chequeará los cambios en los archivos y ejecutará las acciones configuradas. Para refrescar el navegador automáticamente, es necesario instalar LiveReload para Firefox o Chrome . Una vez instalada, ve a la pestaña donde estas visualizando el proyecto, presionas el botón de LiveReload y debería conectarse sin problemas a guard.

Complemento de LiveReload
Botón para conectarse con Guard LiveReload

Para probarlo, edita un archivo de vista  y debería actualizarse la página sin problemas. También al editar un archivo SASS (o SCSS) debería generar el archivo CSS y a su vez recargar la página para ver la nueva apariencia, al editar los archivos de Javascript deberían comprimirse y cualquier otra acción que hayas configurado.

Ahora depende de ustedes que utilicen estas herramientas todos los días, pues mejorarán su trabajo al automatizar ciertas tareas y enfocarse en otras mas importantes. Si alguien conoce otra utilidad para Guard, no duden en dejar un comentario.

1 comentario

Mi experiencia al desarrollar 2 plugins de WordPress bajo software libre

Este artículo cuenta mi experiencia luego de tres años, al desarrollar un proyecto de software libre (licencia GPL) y motivarlos a crear sus propios proyectos o colaborar en los existentes. Si no te gusta leer mucho, básicamente quiero compartir que al crear y mantener un proyecto de software libre logras: aprender a ser mejor programador al recibir correcciones de otras personas,  conoces gente de varias partes del mundo interesadas en tu programa, ves correr el programa en lugares no pensados, recibes código programado por otras personas, puedes recibir dinero sin previo aviso y sin nada a cambio, consigues futuros clientes y recibes felicitaciones por resolver un problema de otra persona.

Inicio

Como mi blog hecho con WordPress empezó a acumular años, el historial de artículos se hizo grande y ocupaba mucho espacio para mostrarlo. La solución por defecto es mostrar los años en una caja desplegable pero lucía muy feo y conseguí un sencillo plugin que los mostraba en un menú desplegable con animación hecha en Javascript. El plugin dejó de soportarse al poco tiempo y no siguió funcionando con WordPress, por ello, decidí hacer uno similar y como estaba aprendiendo jQuery (estaba de moda) lo utilicé para la implementación y nombre. Escribirlo fue fácil pues WordPress ofrece una excelente documentación, además, utilicé el plugin que usaba como base.

¿Ofrecerlo como software libre o usar una licencia cerrada y venderlo?

Una vez terminado, pense en 3 posibilidades: usarlo para mi mismo, venderlo por un precio muy barato y ganar algo de dinero por él, liberarlo como software libre porque le podría servir a alguien con la misma necesidad que yo. Decidí ésta última porque por primera vez tenía algo que surgía de una necesidad y estaba seguro de servirle a mucha gente en la misma situación que yo. Lo subí a WordPress y mi sorpresa es que tuvo bastantes descargas los primeros días (creo que como 300).

Por novatada, empecé a recibir peticiones (no quejas) de gente que deseaba mejor código porque no me entendían, soporte para otros días (me decían que si hablaba español por qué no había menús en este lenguaje), soporte para cambiar el formato del mes, etc. Aproveché un tiempo libre y lancé una segunda versión con el código mas sencillo y limpio, documentado, soporte para multi-idioma (en ese momento inglés y español) e implementé la funcionalidad del mes.

Primeras contribuciones

Luego de esos cambios pensé que el plugin estaba listo y no era necesario hacer mas cosas, para mi sorpresa empecé a recibir ideas de nuevas funcionalidades, código de personas para añadir compatibilidad de características de WordPress desconocidas para mi, por ejemplo, para ese entonces no conocida de WordPress MU, shortcodes, filtros, etc. Recibí parches para mejorar el código SQL porque había una persona con miles de posts, etc.

Mi sorpresa es ver como gente desconocida, se tomó el tiempo para estudiar el código elaborado por mí, modificarlo para soportar sus necesidades y compartirlo conmigo para incluirlo en la rama oficial, permitiendo al resto de usuarios disfrutar de estas funcionalidades. Además, las funcionalidades implementadas eran interesantes y muy variadas, yo sólo no hubiese podido hacerlas porque eran situaciones muy distintas en cada caso. Otra cosa interesante, fue que uno de los primeros programadores en enviarme código, tradujo el plugin a Checo y Esloveno, dos idiomas que jamás pensé contar en mi plugin.

Mantenimiento

Una vez con una base de funcionalidades generales, gente empieza a pedir características  mas complejas, a veces fuera de las funcionalidades o el objetivo del plugin, generalmente algunas se resolvían con otro plugin y otras tuve que agregarlas. Una de las mas solicitadas era la posibilidad de excluir tareas pero fallé, sin embargo, otro de los primeros programadores  en contribuir lo implementó sin que le pidiera ayuda y pude ofrecerlo al resto.

Al momento de estabilizarse el proyecto: buena base de usuarios, programadores voluntarios contribuyendo en el proyecto. Noté un incremento en el soporte, la gente al ver que el plugin funciona bien desean expandir sus posibilidades y empiezan a contactarte para ver como realizar ciertas cosas o dar nuevas idea.  Comencé a recibir donaciones simplemente por realizar el plugin, motivandome a realizar nuevas funcionalidades (como soportar muchas instancias que requería casi re-escritura total).

En otras palabras, una vez que el proyecto se mantiene, el mantenimiento consiste en arreglar bugs, dar soporte a las personas y dependiendo de la frecuencia de solicitudes, agregar funcionalidades nuevas. En este punto es bien porque ya vez el fruto del esfuerzo realizado anteriormente, sin embargo, me parece delicado descuidarlo porque se puede ir todo para atrás. Pues aquí la gente confía mas en tí y espera respuestas rápidas, tal vez algunas sean incómodas al exigir como si estuviesen pagando altas sumas por ello, pero otras son buenas al agradecerte por el esfuerzo realizado.

Conclusiones

Después de este tiempo, puedo decir que es uno de los proyectos mas satisfactorios a nivel profesional y pesonal, en el primer ámbito porque me permite mejorar mis capacidades de programación, conseguir nuevos clientes (mi mayor cliente lo conseguí al solucionarle un problema con este plugin), mejora el currículo (puedo demostrar capacidad de liderar un proyecto, experiencia con PHP y WordPress, Javascript, etc) y mas. Respecto a la parte personal, cada vez que recibo un correo de una persona agradeciendome por el trabajo, por el tiempo ahorrado al utilizar este programa, al ver ejecútandose en sitios conocidos o muy extraños. Me alegra saber que he ayudado a otra persona sin nada a cambio, además cuando recibo donaciones pues también es bien saber que se recibe una recompensa monetaria extra por un trabajo que muchas veces es para mí (para mi blog).

Si alguno tiene una idea o programa en mente, es sencillo y sienten que pueden ayudar a otro, liberelenlo bajo una licencia de código abierto, publiquen el repositorio y con el tiempo verás como crece con la ayuda de otros programadores. Realmente es una buena experiencia.

Si alguno desea conocer o probar mis 2 plugins, pueden hacerlo en las siguientes direcciones:

Happy Hacking!

1 comentario

NoSQL Style (Parodia Geek de Gangnam Style)

Leyendo una entrada de Geeksroom ví esta buena parodia (no musicalmente) de Gangnam Style pero acerca de la tecnología NoSQL, la letra es realmente buena, cuando dijo que era para datos estructurados me pareció bien hecha pues aclara cuando usarla (mucha gente piensa que NoSQL es un sustituto de SQL).

En fín, les dejo observar este vídeo para que disfruten un rato Geek y Musical.

NoSQL Style (Gangnam Style Parody for Geeks)

¡Comparte este video con sus amigos Geeks!

1 comentario

Automatización de pruebas funcionales con Selenium en Yii usando Netbeans

El título de esta entrada es un poco largo, pero intentaré de explicarles de una manera sencilla como podemos hacer pruebas funcionales en nuestras aplicaciones hechas con el framework de PHP Yii, usando Selenium y Netbeans. Para quienes no conocen las pruebas funcionales, son aquellas para comprobar la correcta ejecución de cada una de las funcionalidades del sistema, muchas veces hacemos este proceso manualmente: entrando al sitio, escribiendo a mano (o usando un plugin del navegador) cada campo, haciendo clic en los botones y así sucesivamente. Pero cuando el sistema se hace muy grande o estamos en agregando funcionalidades, se puede perder mucho tiempo en realizar este proceso, si se deja para el final (como en las metodologías antiguas) puede ser muy tarde y si se omite tendremos un software con potenciales fallas.
La idea es automatizar este proceso, para que con un solo clic se ejecuten muchas pruebas y asegurarnos el correcto funcionamiento del programa a lo largo del desarrollo y mantenimiento del mismo.

 

Configuración en Netbeans

Para esta guía deben tener ya instalado y configurado los siguientes programas: Netbeans, PHP Unit, un programa hecho con Yii framework, Selenium Server, Firefox (Debe ser igual para otro navegador pero no lo probé), Linux (No sé si este proceso es igual para Windows).

Primero lo que vamos a hacer es instalar un plugin de Netbeans para manipular el servidor de Selenium desde el IDE, este paso es opcional pero me parece mas fácil iniciarlo / detenerlo con un clic que a través de comandos. Para ello vamos a:

  1. Entrar en Netbeans.
  2. Luego en el menú «Tools -> Plugins -> Available Plugins«.
  3. Allí buscamos el que tenga el nombre de «Selenium Module for PHP» le damos clic en Install.
  4. Una vez finalizada la instalación, en la pestaña de Servicios en la parte de Servidores tendremos el de Selenium.
Servidor Selenium
Servidor Selenium

Antes de iniciar las pruebas, debemos arrancar el servidor de Selenium con clic derecho y luego en «Start». Luego procedemos a configurar el proyecto actual (el realizado en Yii) para indicar a Netbeans donde se encuentran las pruebas y PHP Unit:

  1. Hacemos click derecho en el proyecto y luego en «Properties».
  2. En la sección «Sources» existe una caja llamada «Test Folder», en ella vamos a colocar la ruta absoluta a la carpeta /protected/tests del proyecto (en caso de no funcionar, entonces a /protected/tests/unit).
  3. Luego en la misma ventana, cambiamos la sección «PHPUnit» y activamos donde dice «Use Bootstrap» donde rellenamos la caja de texto a la ruta absoluta de /protected/tests/bootstrap.php
  4. Luego activamos la opción «Use XML Configuration» y rellenamos en la caja la ruta absoluta de /protected/tests/phpunit.xml.

Con esto ya esta configurado Netbeans, sin embargo, en mi caso no funcionó de una vez hasta hacer unos pequeños ajustes:

  1. En mi caso no quería detectar al navegador Firefox, para hacerlo funcionar en el archivo de configuración (phpunit.xml) tuve que eliminar todo el contenido dentro de las etiquetas <selenium></selenium> dejándolas como las acabo de escribir.
  2. En el archivo WebTestCase.php,en la función setUp() necesité colocar $this->setBrowser(‘*firefox’); para indicar el navegador por defecto.
  3. Como estaba usando Bootstrap para el frontend, Selenium debe esperar un poco hasta que algunos eventos de Javascript terminen de mejorar la apariencia visual, para ello en el archivo /protected/config/main.php se agrega enla sección de preload lo siguiente (asumiendo la carga de log como se encuentra por defecto):
'preload' => array('log',
  php_sapi_name() !== 'cli' ? 'bootstrap' : '',
),

Listo, ya con presionar Alt + F6 empezará a ejecutar todas las pruebas, si solo quieren para la clase actual deben presionar Shift + F6.

Consejos para las pruebas

A continuación les doy unos consejos y extractos de código, pues al principio me costó encontrar como realizar las siguientes tareas en Selenium.

Iniciar sesión en cada prueba

Para ello deben crear en WebTestCase.php (la clase principal para las pruebas) un método para el login que comience con _ (piso), pues éstos no se ejecutarán en las pruebas, aquí mi les dejo código y luego en cada prueba hacen un $this->_login() donde requieran identificarse.

protected function _login() {
	$this->windowMaximize();
	$this->open("site/login");
	$this->type("LoginForm_username", "skatox"); //Donde LoginForm_username es el id del usuario
	$this->type("LoginForm_password", "contrasena");
	$this->click("LoginForm_rememberMe"); //Permite recordar y no estar autenticando cada rato
	$this->click("name=yt0");
	$this->waitForPageToLoad(self::PAGE_LOAD_WAIT_TIME); //constante que declaré para esperar un tiempo
}

Interactuar con la ventana de confirmación al eliminar un elemento del grid

En este caso se me complicó porque se debe interactuar con una ventana de javascript, el siguiente código también está en WebTestCase.php porque lo utilizo a lo largo de todas las pruebas, los parámetros son: $confirmMsg que es el mensaje de confirmación que aparece en la ventana y $nonFoundMsg, mensaje de cuando se ha borrado el elemento.

protected function _testDelete($confirmMsg, $nonFoundMsg){
  sleep(self::WAIT_JS_TIME); //tiempo para esperar la ventana de javascript
  $this->chooseCancelOnNextConfirmation(); //Selecciona el boton cancelar para probar este paso
  $this->click($this->firstDeleteXpath); //Hace clic en el boton de eliminar del grid (Xpath)
  $this->assertConfirmationPresent($confirmMsg); //Se asegura que esta bien el mensaje
  $this->getConfirmation();
  sleep(self::WAIT_JS_TIME);
  $this->chooseOkOnNextConfirmation(); //Escoge aceptar
  $this->click($this->firstDeleteXpath);
  $this->assertConfirmationPresent($confirmMsg);
  $this->getConfirmation();
  $this->waitForTextPresent($nonFoundMsg); //Espera que no hayan resultados porque los borró
}

Ya con estos pasos pueden empezar a realizar las pruebas funcionales de forma automática, si quieren conocer como se vé, les dejo un vídeo de unas pruebas de un módulo de una aplicación que estoy realizando:

Pruebas funcionales de Yii usando Netbeans
15 comentarios