Archivos para las entradas con etiqueta: software

Este artículo se basa en mi experiencia en el trabajo, desarrollo de aplicaciones web, y de llevar a estas el requerimiento no funcional del rendimiento del navegador al momento de hacer el render de la página. Para poder medir este requerimiento use la herramienta web GTmetrix que realiza dos pruebas (YSlow y Page Speed) de la página web a mostrar.

Hasta este momento parte de mi trabajo ha sido trabajar con el CMS modx, que pesar de tener una nueva versión llamada revolution (con muchas mejoras sobre la versión anterior), sigue con el problema de manejar el código (html o php) a través de la base de datos y dificultando su manejo a través de su administrador. Para paliar este problema, y mostrar las maravillas de automatizar tareas, realize una clase en Java para interactuar entre archivos físicos (de tu ambiente de desarrollo) y la base de datos con el código de estos (sin tener que abrir el administrador de modx).

(Algunas) herramientas para automatizar

Para automatizar tenemos muchas herramientas que permiten hacerlo, como por ejemplo, scripts de shell o archivos de procesos por lotes. Debido a que son herramientas que cubren necesidades diferentes preferí no apegarme a una de estas opciones, en cambio, dada la extensión del lenguaje Java y las herramientas basadas en este lenguaje que permiten automatizar tareas en el desarrollo decidí usar Apache Ant.

Si buscas compresores para CSS o Javascript hay muchos online, que desde mi punto de vista son buenos para hacer el proceso una sola vez. Sin embargo, si deseas integrar esta actividad de manera continua en tus proyectos creo que verás que no es ameno estar desarrollando en x programa, abrirlo, copiar el contenido del archivo, pegarlo en el navegador y poner el resultado en un nuevo archivo. Por este motivo para la compresión de las hojas de estilos y archivos javascript he usado YUI Compressor que es una clase Java y que se puede ejecutar desde línea de comandos. Para la compresión de HTML use la herramienta HTML Compressor que básicamente cambia los saltos de línea y tabuladores en espacios en blanco.

Para el manejo de los elementos de modx hice una clase en Java (para ejecutar desde la línea de comandos) y evitar trabajar con estos a través del navegador (dejando la tarea del desarrollo a herramientas hechas para esto). Al desarrollo lo llame modxConnect y la idea es que una vez que se encuentra comprimidos los elementos (html) modxConnect inserte el contenido de los elementos en la base de datos de modx. Falta mucho desarrollo, pero es un primer acercamiento.

Para los siguientes pasos supongo que ya esta configurado todo este ambiente:

  • Java (si ya esta configurado el acceso al classpath mejor)
  • Apache Ant que este accesible desde línea de comandos (lo puedes agregar al classpath) y si no pues tienes que poner la ruta completa del ejecutable (en Apache Ant User Manual puedes encontrar como instalarlo y empezar a usarlo).
  • YIU Compressor, HTML Compressor y modxConnect accesibles a través de la línea de comandos (o configurando el archivo de Apache Ant para determinar la ruta de donde se encuentran).

Ahora ya que tienes listo este ambiente de desarrollo vamos a empezar la configuración para la automatización.

Configurar

Uno de los beneficios de Apache Ant, es que solo tienes que crear un archivo XML llamado build.xml (por lo general, pero puedes hacer referencia a otro archivo) y es donde definirás las tareas (targets) repetitivas que deseas realizar de manera automática. La estructura básica del archivo build.xml es:

<?xml version="1.0" encoding="UTF-8"?>
<project name="NombreProjecto" default="clean" basedir=".">
	<property file="build.properties" />
	<target name="clean" depends="" description="">
		<delete dir="${build}" />
		<delete dir="${dist}" />
	</target>
	<target name="clean" depends="" description="">
		<delete dir="${build}" />
		<delete dir="${dist}" />
	</target>
</project>

Ahora comentemos un poco de las etiquetas (que puedes ver más a detalle en Apache Ant User Manual):

  • project: se usa para definir información al proyecto. El atributo name es para asociarle un nombre, default es la tarea (target) que se ejecutará por default y basedir para asociar el directorio sobre el que se estará trabajando.
  • property: se usa para asociar “variables” al archivo build.xml, puedes ponerlas directamente o asociar un archivo properties con los valores, a los que haces referencia con los placeholders ${nombreVariable}.
  • target: es la definición de una tarea que realizará. El atributo name es el nombre de esta (y como será llamada por Ant), depends es la lista de tareas que deben completarse antes de llevar a cabo la tarea seleccionada y description es una descripción de la tarea.

Antes de continuar, necesitamos la información del archivo build.properties:

dir.src=src
dir.build=build
dir.sub=assets
dir.js=js
dir.css=css
dir.server=C:/servers/xampp/htdocs/app
dir.chunks=chunks
dir.lib=lib
dir.classPHP=class
dir.processPHP=process
dir.propertiesPHP=properties
dir.modx=C:/servers/xampp/htdocs/cmsModx
dir.ftp=urlFTP
server.dir=00.000.00.00
server.usr=usuario
server.pwd=password
file.css=style.css
file.js=scripts.js
file.chunk.css=html.css.xhtml
file.chunk.js=html.js.xhtml
dir.compressor=C:/tools/yuicompressor-2.4.2/build
class.compressor=yuicompressor-2.4.2.jar
dir.compressorHTML=C:/tools/htmlcompressor
class.compressorHTML=htmlcompressor-0.9.1.jar

Y ya que se definió una tarea, para realizarla necesitas llamar a ant y darle el nombre de la tarea como parámetro:

ant nombreTarget

Una de las primeras tareas, y practicas en Java, es tener por separado el ambiente de desarrollo y el ambiente de producción, que por lo general es la compilación de los fuentes, pero en este caso solo será los archivos fuentes con cierto proceso (compresión) y para llevar a cabo esta tarea, se puede definir una tarea como la que sigue:

<target name="makeDirs" description="Crea los directorios sobre los que se trabajara">
	<copy todir="${dir.build}">
		<fileset dir="${dir.src}">
			<exclude name="**/*.*" />
			<exclude name="**/js/src/**" />
		</fileset>
	</copy>
</target>
  • copy: copia los archivos/directorios a donde se indique todir.
  • fileset: define, a través de dir, los archivos que serán copiados.
  • exclude: define la referencia de los archivos que no deben ser copiados a todir, se pueden usar comodines (** significa que no importa la carpeta)

Para este caso solo se crea la estructura de directorios (como lo tengas en desarrollo) ya que en otras tareas se harán los procesos para comprimir los diferentes tipos de archivos. Puedes permitir copiar las clases PHP o las imágenes desde un principio (aunque más adelante puedo dar unas ideas para no hacerlo aún).

Empecemos a hacer una de las tareas repetitivas: comprimir CSS y JS. Si se dificulta tener una sóla hoja de estilos (siempre es más ordenado separar los estilos de las secciones en diferentes archivos) entonces primero juntemos toda la información de las hojas de estilos en un sólo archivo (lo mismo pasa con los archivos de los javascripts), para eso se pueden hacer unas tareas como estas:

<target name="conCSS" description="Concatena los CSS a un archivo en el directorio BUILD">
	<concat destfile="${dir.build}/${dir.sub}/${dir.css}/${file.css}" force="no">
		<filelist dir="${dir.src}/${dir.sub}">
			<file name="${dir.css}/charset.css" />
			<file name="${dir.css}/reset.css" />
			<file name="${dir.css}/estilo1.css" />
			<file name="${dir.css}/estilo2.css" />
			<file name="${dir.css}/estilo3.css" />
		</filelist>
	</concat>
</target>
<target name="conJS" description="Concatena los JS a un archivo en el directorio BUILD">
	<concat destfile="${dir.build}/${dir.sub}/${dir.js}/${file.js}" force="no">
		<filelist dir="${dir.src}/${dir.sub}">
			<file name="${dir.js}/jquery-1.4.2.js" />
			<file name="${dir.js}/jquery.ui.core.js" />
			<file name="${dir.js}/jquery.ui.widget.js" />
			<file name="${dir.js}/jquery.ui.mouse.js" />
			<file name="${dir.js}/jquery.ui.draggable.js" />
			<!-- wrapper > -->
			<file name="${dir.js}/wrapStart.js" />
			<file name="${dir.js}/main1.js" />
			<file name="${dir.js}/main2.js" />
			<file name="${dir.js}/main3.js" />
			<file name="${dir.js}/wrapEnd.js" />
			<!-- < wrapper -->
		</filelist>
	</concat>
</target>
  • concat: con esta tarea concatenas los archivos (de filelist) en el path/archivo definido en destfile.
  • filelist: define los archivos que serán concatenados. Si agregas uno más Ant automáticamente lo incluirá en el archivo final.
  • En la tarea de la compresión de los javascript puse dos archivos para crear el template de carga de las acciones de jQuery, donde $document.ready(function() { esta en  wrapStart.js mientras que en wrapEnd.js se encuentra });

Comprimir los archivos de CSS y JS ya concatenados (con el YUI Compressor):

<target name="compressCSS" description="comprime el CSS de BUILD" depends="conCSS">
	<exec executable="cmd">
		<arg line="/c java -jar ${dir.compressor}/${class.compressor} ${dir.build}/${dir.sub}/${dir.css}/${file.css} -o ${dir.build}/${dir.sub}/${dir.css}/${file.css} " />
	</exec>
</target>

<target name="compressJS" description="comprime el js de BUILD" depends="conJS">
	<exec executable="cmd">
		<arg line="/c java -jar ${dir.compressor}/${class.compressor} ${dir.build}/${dir.sub}/${dir.js}/${file.js} -o ${dir.build}/${dir.sub}/${dir.js}/${file.js} " />
	</exec>
</target>
  • exec: establece que se usará una instrucción de línea de comando.
  • arg: es propiamente la llamada a la instrucción para comprimir el archivo.

Con esto ejecuta

ant compressJS compressCSS

y siempre se generarán los archivos de JS y CSS comprimidos.

Los archivos HTML y PHP son muchos y no tiene caso que los concatenemos, pero si se puede “comprimir” (eliminar los metacaracteres) para agilizar la transferencia de los archivos. Esto se resuelve con la siguiente tarea:

<target name="compressAll" depends="makeDirs">
	<apply executable="java" parallel="false">
		<fileset dir="${dir.src}/" includes="**/*.html,**/*.php,**/*.xhtml">
			<exclude name="**/config/**" />
			<exclude name="**/css/**" />
			<exclude name="**/js/**" />
			<exclude name="**/lib/**" />
			<exclude name="pagina1.php" />
			<exclude name="pagina2.php" />
			<exclude name="pagina3.php" />
		</fileset>
		<arg value="-jar"/>
		<arg path="${dir.compressorHTML}/${class.compressorHTML}"/>
		<arg line="--type html"/>
		<srcfile/>
		<arg value="-o"/>
		<mapper type="glob" from="*" to="${dir.build}/*"/>
		<targetfile/>
	</apply>
	<copy todir="${dir.build}/${dir.sub}/${dir.lib}">
		<fileset dir="${dir.src}/${dir.sub}/${dir.lib}" includes="**/*.php"></fileset>
	</copy>
</target>
  • apply: es otra forma de ejecutar un comando (en línea de comandos) aplicado a los archivos definidos por fileset.
  • fileset: conjunto de archivos que serán comprimidos. En includes se seleccionan todos los archivos HTML, PHP y XHTML, excepto pagina1.php, pagina2.php y pagina3.php.
  • arg: argumentos para la llamada de la línea de comandos.
  • srcfile: referencia al archivo de fileset.
  • mapper: define la salida del archivo.
  • Al final copia todos los archivos excluidos (clases de PHP) a la carpeta build.

Por último resolvemos el inconveniente de modx respecto a los elementos con modxConnect. La definición de la tarea:

<target name="copyServer" depends="compressJS,compressCSS,compressAll">
	<exec executable="cmd">
		<arg line="/c C:\Java\jdk1.6.0_03/bin/java -jar C:\tool\modxConnect.jar" />
	</exec>
	<!-- limpiar el cache del modx -->
	<exec executable="cmd">
		<arg line="/c curl http://SITEURE/clearCache.html" />
	</exec>
</target>
  • El primer comando es para llamar a la clase que hace el mapeo (modxConnect). Como se encuentra no es funcional (por la configuración que se encuentra en los archivos properties del jar). Para poder usarlo tienes que configurar la base de datos, los paths donde se encontrarán los archivos (ya comprimidos) y crear los chunks a través del modx y después ligar el archivo físico con el id del chunk (en los archivos properties vienen comentarios al respecto).
  • El segundo comando es para limpiar la cache del modx. Se necesita definir un documento y asociarle el snippet con el código siguiente:
<?php
// Snippet para limpiar la cache
$paths = array(
	'config.cache.php',
	'sitePublishing.idx.php',
	'registry/mgr/workspace/',
	'lexicon/'
);
$contexts = $modx->getCollection('modContext');
foreach ($contexts as $context) {
	$paths[] = $context->get('key') . '/';
}
$options = array(
	'publishing' => 1,
	'extensions' => array('.cache.php', '.msg.php', '.tpl.php'),
);
if ($modx->getOption('cache_db')) $options['objects'] = '*';
	$results= $modx->cacheManager->clearCache($paths, $options);
return 'OK';
?>

Ya configuraste todo, pero no te olvides de agregar una tarea que borre todo lo que generaste

<target name="clean" description="limpiar los paths">
	<delete dir="${dir.build}" />
	<delete dir="${dir.server}" />
</target>

Que lo haga la computadora

La parte más sencilla de esto: usar Apache Ant. Una de las ventajas de modularizar la construcción, es que puedes hacer cualquier paso intermedio y no tener siempre que ejecutar todo, por esa razón se separo la concatenación de los archivos de la compresión o la creación de el árbol de producción.

Para ejecutar todas las tareas, ponemos

ant compressAll

Por ejemplo, esta modificando la hoja de estilos y solo quieres concatenar los archivos (sin comprimir) sólo ejecutas

ant compressCSS

y ya solo subes el archivo y haces el debug (lo mismo se puede hacer con los javascript).

Conclusiones

Este artículo se centra en mejorar algunos procesos en el desarrollo de software. Después de estar trabajando un tiempo de esta manera mi experiencia me dice que HAY QUE ORGANIZAR LOS PROYECTOS (y esto incluye como se implementará) para atender procesos que son susceptibles de automatizar y mejorar la calidad en este rubro.

También es dar algunas ideas respecto a lo que se me ocurre automatizar:

  • Esteganografía: crear procesos que oculten datos dentro de imágenes (el uso más sencillo que he visto al respecto) como inyectar claves en ciertas imagenes del sitio web.
  • FTP: subir cierta parte del desarrollo (como las imágenes) sin tener que abrir el programa FTP.
  • Ambientes de desarrollo: generar la estructura general de los proyectos siempre que se inicie (sin estar apegado a un IDE).
  • Criptografía: hacer procesos para encriptar información (en la base de datos o en archivos).
  • Desarrollo: puedes poner códigos que midan el tiempo de cierta sección (consulta a la base de datos por ejemplo) y que en la aplicación final no necesitas.

Sí, eso lo hice el fin de semana pero no pude configurar mucho. Para empezar la versión de la distribución fue 4.0 Etch (me gusta más Sarge el nombre de la distribución anterior). Comparada con la versión anterior esta distribución tiene un GUI para la instalación (me recordo mucho a Suse 10). Por suerte o desgracia la conexión a internet me ayudó a la instalación (la desgracia porque descargue las tres imagenes de los dvd’s) y no hubo mayor problema. Ahora me falta configurar mi tarjeta de sonido (una Creative Value 2) y queda lista para aprender a usar comandos de consola y cosas raras que hace Jaime.

Esa es la pregunta que me hice al momento de platicar con el jefe de jefes de la consultora para la que trabajo.

¿Bien de qué platicamos? Pues como he comentado antes en este blog me interesa implantar sobre mi la metodología de desarrollo PSP (Personal Software Process antes de que se emocionen los fans de sony) para poder tener una mejor predicción de tiempo que tardo en hacer un programa (claro, de menos de 10,000 líneas de código). Así que platique de metodologías de ingeniería de software (a nivel teorico estudiantil) porque para ser sinceros lo más ordenado que hay en la consultora son las fiestas y si quiere llegar a su visión que tiene de la consultora pues le va a hacer falta esto. Como yo no supuse ya tiene una idea al respecto, el problema que vi es que lo quiere formalizar todo como si fuera un modelo matemático. No esta mal su idea (de hecho ingeniosa) pero su idea es de meter todo el desarrollo de sistemas (hasta definio sistema) a un modelo que creo que esta reinventando el hilo negro (sí, así como yo) pero como decía mi maestro de ingeniería de software: algo es mejor que nada.

El problema es que ni los matemáticos pudieron formalizar las matemáticas, esto porque las matemáticas estan desarrolladas sobre el lenguaje humano que es el diablo mismo para estos temas. Entonces si tienes que interactuar con el lenguaje (hacer sistemas de computo es creer que lo que entendimos es lo que el cliente cree que necesita) tienes una fuerte barrera para desarrollar algo formal (o axiomatizado en el modelo de la consultora) y de hecho que tengas a una persona introduce una subjetividad que no puedes librar. Si la persona conoce del negocio entonces esa subjetividad es menor pero ya saben que muchas veces pensamos que las cosas podrían hacer mejor como las pensamos (así como cierto político que perdió las elecciones del 2006 y ahora ya anda con su partido político).

Ahora a mi me toca hacer algo que en mi vida había pensado: establecer las etapas del desarrollo. ¿Por qué si no tego experiencia en este ramo? Nada más por hacer la pregunta de ¿tienes metodologías de desarrollo de software? Yo desde un principio fui claro en que no tengo experiencia alguna en este sentido pero el jefe de jefes me ha dejado esa tarea (espero pronto ver un cero más a mi sueldo) y pues espero salga bien. La mala es que es para el miercoles y tengo que estudiar al respecto este fin de semana (porque al igual que el 24 tengo que venir medio día al igual que Oscar).

Bueno ya les contaré al respecto.

La semana pasada asisti al CONSOL (congreso nacional de software) que se realizó en la rectoría general de mi Universidad. Todo el mundo hablaba del software libre y las maravillas de este frente al software comercial, la duda que me ha surgido es esta:

¿qué de malo tiene el software libre con respecto al software comercial?

Porque a pesar de ser todo un movimiento social-tecnologico no deja de ser algo humano y pues ya ven que las cosas humanas tienen sus imperfecciones, así que no creo que el software libre sea la resolución de muchos males respecto al software.