Otro de esos pequeños problemas cotidianos que pueden acabar por convertirse en una tarea pesada. Siempre que tengo que importar datos de una hoja Excel acabo dando mil vueltas exportando a csv por aquí, importando por allá, etc. cuando en realidad es extremadamente sencillo, copiar y pegar.

En el Excel, seleccionamos las celdas a copiar y… las copiamos , Ctrl+C o click en el botón derecho y copiar.

En el cliente de Microsoft SQL Server, abrimos la tabla donde queremos importar los datos y seleccionamos todo haciendo click en la celda superior izquierda, la primera de todas.

Ahora simplemente debemos pegar las celdas que habíamos copiado anteriormente, (Ctrl+V o botón derecho y pegar). Ya está! Así de sencillo. Anda que no le he dado vueltas yo a estas cosas…

Debes prestar atención, eso sí, a las características de cada campo (autonuméricos, campos null, etc…).

Como sabéis, suelo hacer muchas, muchísimas fotos mensualmente. Además las suelo hacer con distintas cámaras, con lo que al sacarlas de las tarjetas de memoria y meterlas en la misma carpeta no quedan ordenadas cronológicamente. Muchas veces he tenido que pasarme horas renombrándolas para tenerlas bien ordenaditas, sobre todo cuando quiero hacer un libro de fotos.

Hoy estaba decidido a crearme un script propio en PHP usando la librería EXIF que leyese esta información y renombrase las fotos en base a ella cuando me he encontrado con Jhead, un pequeño programilla disponible para Linux, Windows y OSX que lo hace directamente y además tiene multitud de opciones.

Simplemente debes descargar el ejecutable y copiarlo en alguna ruta accesible (/usr/local/bin, c:\windows…) y listo para utilizar.

Desde la línea de comandos, nos vamos a la carpeta donde tenemos las fotos mezcladas y ejecutamos:

Eso es todo, automáticamente nuestras fotos quedarán ordenadas por nombre, algo como:

• 2010-01-04_12-05-12.jpg
• 2010-01-04_12-05-20.jpg
• 2010-02-01_19-10-02-jpg
• ….

Es decir: YYYY-MM-DD_HH-MM-SS.jpg.

Un trabajo menos .

Desde hace mucho tiempo utilizo como media preventiva de seguridad el paquete Portsentry en los servidores para detectar potenciales accesos maliciosos y bloquearlos directamente en el firewall. El problema es que por defecto Portsentry deja sus logs en el archivo principal del sistema, /var/log/messages, lo que genera tal cantidad de ruido que es imposible encontrar algo útil en el log. El archivo donde loguea Portsentry no es configurable sino que viene predefinido en tiempo de compilación, con lo que deberemos recompilarlo si queremos que sea otro. Podríamos compilar e instalar el fuente directamente, pero no quiero perder las ventajas que ofrece rpm, veamos como hacerlo para Centos5.5 (o RHEL5.5).

Lo primero que debemos hacer es descargar e instalar el rpm con los fuentes desde aquí.

Ahora debemos modificar el archivo donde se configura dónde logueará:

Editamos el archivo portsentry_config.h cambiando la línea 32 para que quede así:

Con esto simplemente le decimos que loguee al “facility” local6 en vez de al “daemon” por defecto.

Se guarda el archivo y se empaqueta de nuevo:

Ya podemos reconstruir el rpm:

Si todo va bien tendremos el paquete generado:

Y ahí estará nuestro portsentry-1.2-1.te.x86_64.rpm preparado para loguear donde queremos que lo haga. Sólo queda instalarlo. Si tu arquitectura es de 32bits lo encontrarás en /usr/src/redhat/RPMS/i386.

Nos queda un detalle, configurar syslog para que guarde donde nos interesa la facility local6. Para eso editamos /etc/syslog.conf. Añadimos al final de todo la línea:

y al principio de todo veremos algo parecido a:

La cambiaremos por:

Es decir, le decimos que de local6 no loguee nada en /var/log/messages. Solo nos queda reiniciar los demonios:

A partir de ahora tendremos nuestro log general bien limpio y la información de se seguridad separada.

Recientemente he tenido que cambiar el SAI que tenía en casa desde hace unos años, un Powermust 1000 que me había dado muy buen resultado, sin embargo las baterías habían llegado a su fin. En App encontré uno con muy buena pinta, con puerto USB para monitorización, indicaban que soportaba Linux y, además, fabricado en España , el Salicru SPS 900 One, a un precio insuperable. Me lo llevo .

La decepción llegó al instalarlo. La monitorización se hace a través de una aplicación propia, algo que no me convencía ya que estaba acostumbrado a utilizar nut y a tenerlo integrado en Cacti.

Leyendo y probando algunos drivers encontré cómo hacerlo funcionar . Muy sencillo.

Esto instalará todo lo necesario y dejará los scripts para acceder vía web al estado del SAI en la ruta indicada.

No voy a entrar en detalles de la configuración, sólo indicar que el driver a utilizar es blazer_usb:

Con eso iniciamos los demonios upsd y si todo va bien  lo tendremos funcionando. Si vamos a la ruta donde dejamos los scripts web veremos:

Primer paso preparado. Vamos ahora a configurar el monitor de avisos para que sepamos cuando el SAI cambia de estado (se va la luz en casa, vuelve, se queda sin batería, etc.). Esto lo controla el demonio upsmon. Como veis se monitoriza todo bien excepto el nivel de batería, este SAI no informa de ese dato, pero tampoco es algo crítico, los cambios de estado sí que funcionan correctamente, con eso es suficiente para nuestro propósito.

Primero preparamos la configuración.

Además de definir los mensajes que queremos recibir, le indicamos también que en los cambios de estado llame al script /bin/avisoups.

Este script se ejecutará en cada cambio de estado que se produzca en el SAI y recibirá como parámetro el texto correspondiente al nuevo estado. En mi caso me envío un email y un SMS a través de Gammu.

Levantamos el demonio upsmon y probamos a enchufar y desenchufar la alimentación externa del SAI. Si todo va bien recibirás un email y/o un sms con el aviso .

Cuando al SAI se le termine la batería apagará el servidor para evitar que se corte la alimentación de golpe. Si configuras la Bios para que arranque automáticamente cuando reciba alimentación, se reiniciará él solito en cuanto vuelva la luz .

Integración con Cacti

Para integrar la monitorización en Cacti podemos utilizar estas plantillas ya creadas.

Una vez instalada y creada en el host que hace de monitor debemos configurar el “Data source” correspondiente indicando el SAI que debe monitorizar, en mi caso salicru@localhost.

Si todo ha ido bien, comenzaremos a ver la gráfica de nuestro SAI. Tendremos sólo las líneas Input, Output y Load, la de Batteries, como he indicado, no se recibe en este SAI.

Ya tenemos nuestro SAI baratito bien instalado y configurado. A partir de ahora nos avisará cuando haya cortes de luz, apagará el equipo, se encenderá de nuevo automáticamente y, si lo configuramos todo bien, tendremos hasta un SMS en nuestro móvil. Y todo ello monitorizado a través de Cacti .

Vuelvo con un artículo sobre la serie que hice hace algún tipo acerca de Adobe Air.

Uno de los principales problemas con los que me he encontrado al desarrollar con Air es a la hora del despliegue, ya que los clientes deben instalarse primero el framework y después la aplicación, lo que da lugar a muchas dudas y potenciales problemas. Para solucionarlo existe una librería de Adobe que permite saber si un cliente tiene instalado el framework y tu aplicación directamente desde una página web y lanzar la instalación de ambos en caso de que no los tenga, de esta manera los usuarios no tienen que descargar nada, todo muy sencillo e intuitivo.

Para interactuar con esta librería existe además una pequeña aplicación Flash que se distribuye con el sdk de Flex con los conceptos básicos: comprobar si el cliente tiene el framework y lanzar la instalación si es necesario. La podéis encontrar en:

Sin embargo puede ser realmente tedioso configurarla y programarla adecuadamente, así que existe Badger, una aplicación AIR que enmascara todo este proceso con un sencillo asistente donde rellenas los parámetros, incluidas las cadenas de texto a utilizar, y te genera el código necesario. Puedes descargarla aquí.

Al ejecutarla veremos la pantalla principal.

Por defecto solo hay un template, así que el primer menú lo podemos obviar. Con el segundo seleccionas tu aplicación AIR para que Badger cargue automáticamente algunos de los parámetros y, cuando has terminado, con la última opción “Export badge” generas el código.

Dentro de la configuración hay dos campos importantes. “application url“, debes introducir la url completa (con http://) desde donde se descargará la aplicación, y “publisher ID“, donde tienes que seleccionar la ruta donde la tienes instalada localmente para que Badger lea automáticamente este dato, imprescindible para comprobar si el cliente ya la tiene instalada.

Al subir todos los archivos generados a tu web (el html puedes integrarlo adecuadamente) y cargar la url en un navegador verás algo parecido a esto suponiendo que no tienes la aplicación (o el framework) instalados.

Al hacer click en “Instalar”, si no tienes el framework instalado, te pedirá autorización y comenzará la descarga:

Para finalmente acabar instalando tu aplicación.

Si el cliente ya tuviese la aplicación instalada podremos lanzarla automáticamente también. Para conseguirlo es necesario, primero, que en el descriptor de la aplicación hayas configurado el siguiente parámetro a “true“:

Ahora, si el cliente ya tiene nuestra aplicación, veremos algo como esto:

Y al hacer click en “Lanzar ahora” nuestra aplicación se cargará ella sola .

Como veis es muy sencillo para el cliente instalar así nuestras aplicaciones AIR, nada que ver con tener que descargar el framework por un lado y la aplicación por el otro.

Parece que últimamente me aburro mucho . Hace unos días, leyendo un artículo, se me ocurrió de nuevo explicar cómo se hacen esos sistemas de correo instantáneos que se suelen utilizar para registrarse en webs y que después no te envíen spam . La idea me pareció muy adecuada para poner un ejemplo práctico de algo que vimos hace tiempo sobre otras utilidades para un servidor de correo y, tal y como me ocurrió hace unos meses, lo que era un artículo se convierte en proyecto.

La idea, por tanto, es crear un sistema que, sin necesidad de ningún registro, te permita crear una cuenta de correo y recibir y leer emails en ella por espacio de una hora, al cabo de este tiempo la cuenta se autodestruye y todos los emails serán devueltos. En nuestra aplicación tendremos dos opciones para crear la cuenta, aleatoria o personalizada, creo que no hacen falta más explicaciones. Una vez usas una cuenta puedes volver a ella más tarde cuando la necesites volviendo a crear una cuenta personalizada con el mismo usuario. Esto es útil, por ejemplo, para que te recuerden la contraseña que utilizaste para registrar en aquella web de descarga de películas y de la que ya no te acuerdas .

Qué necesitamos

• Servidor Linux con Qmail como MTA.
• Apache, PHP y MySQL.
• Pear MimeDecode: para procesar los correos entrantes con PHP.
• Una plantilla superchula de FreeCssTemplates
• Jquery: para todo lo que es ajax y Javascript
• ZeroClipboard:  para copiar y pegar automáticamente
• Jquery ScrollTo: pluggin para desplazar el scroll automáticamente.
• Una imagen de “Cargando” para las acciones ajax que personalizas aquí.
• Diccionarios de palabras “aleatorias”. Aquí hay unos cuantos.
• Adodb (opcional) para el acceso a base de datos.

Eso es todo, sólo hay que juntar las piezas adecuadamente.

Preparando Qmail

Nuestro primer paso, antes de ponernos con los temas puramente web, será configurar adecuadamente el servidor de correo para nuestro propósito. Para ello necesitamos crear un usuario del sistema que reciba todo el correo dirigido a un dominio. Esto lo podemos hacer del siguiente modo:

Añadimos nuestro nombre de host en:

/var/qmail/control/rcpthosts

Y el usuario al que dirigiremos los correos en:

/var/qmail/control/virtualdomains

Reiniciando Qmail conseguiremos que los correos enviados a cualquier cuenta del dominio vayan al buzón del usuario indicado, es decir cualquiercosa[arroba]usaytira.me.

Pero no queremos que los correos vayan al buzón del usuario sino simplemente procesarlos. Para eso editamos el archivo:

/home/usaytirame/.qmail-default

Sólo con esa línea. Con este comando conseguimos redirigir los correos entrantes a un script en el que podremos recuperarlos y reutilizarlos a nuestro antojo como veremos a continuación.

Procesando los emails entrantes

Vamos a comenzar por crear una base de datos donde guardaremos los emails recibidos. Como queremos poder acceder a los emails dirigidos a cada cuenta independientemente, haremos dos tablas, una (emails) la utilizaremos como tabla maestra para las cuentas de correo que se creen y en la otra (correos) iremos almacenando los emails recibidos para cada una de esas cuentas.  La estructura sería poco más o menos la siguiente:

Creo que es suficientemente descriptiva. El campo fecha de emails nos servirá para controlar los 60 minutos de duración máxima.

Pues ya tenemos todo preparado. Veamos cómo procesamos los emails.

/home/usaytirame/procesa.php

Tenemos la primera parte del procesado preparada. De aquí debemos destacar:

Con esto leemos desde la entrada estandar el contenido del email. Recordad que no estamos en una aplicación web sino en un script ejecutado en la consola del sistema.

La otra línea importante es:

Con ella conseguimos procesar el email y separar su estructura en un array asociativo con los distintos parámetros. Os ayudará mucho ver el contenido de ese array:

Llegados a este punto podemos hacer una prueba. Necesitamos el contenido completo de un email, podemos sacarlo de nuestro cliente de correo o del propio servidor.

Si todo ha ido bien veremos en pantalla un array con la estructura del correo.

No voy a detallar todo el proceso ya que alargaría mucho el artículo. Vamos con el siguiente paso:

En la primera parte del script comprobamos si la cuenta a la que va destinado el email existe en nuestra base de datos, si no, muy importante, devolvemos un código 100 que indica a qmail que debe devolver el correo ya que no existe el usuario.

Si la cuenta existe recogemos el cuerpo del mensaje. Yo lo hago con la función get_content, que analiza la estructura del correo y devuelve el contenido. Esta parte os la dejo a vosotros. Básicamente consiste en comprobar las distintas partes que puede tener un correo y devolver lo que estimemos oportuno. Un detalle muy importante a tener en cuenta es la codificación tanto del email como de nuestra base de datos y la aplicación web. En mi caso las dos últimas están en UTF-8, con lo que debo convertir todos los textos del email a esta misma codificación. La estructura que teníamos inicialmente en un array tendrá parámetros que nos indican el charset en el que viene el email. Las funciones de conversión de PHP te pueden ser útiles: iconv, utf8_encode, etc.Finalmente introducimos todos los campos del email en la base de datos.

Puedes volver a probar a procesar el email de prueba tal y como hicimos antes. Recuerda que debes añadir el registro de la tabla emails para que  guarde el correo, si no la cuenta no existirá. Una vez te funcione desde la línea de comandos ya puedes probar a enviarte un correo real .

La aplicación web

No creo que hacer la parte web propiamente dicha necesite muchas explicaciones. Tenemos ya todos los elementos preparados, sólo debemos añadir los formularios para crear la cuenta de correo (aleatoria o personalizada) y, con un poco de ajax, ir cargando los correos a medida que van llegando. No  hay más truco.

Añadiré, eso sí, algunas aclaraciones interesantes.

Para crear las cuentas aleatorias, en vez de utilizar una secuencia aleatoria de números y letras, que daría como resultado algo ininteligible, usamos los diccionarios que comentaba más arriba. Los importamos en una tabla de la base de datos y simplemente tenemos que buscar aleatoriamente una palabra que no esté utilizada todavía como cuenta de correo, sencillo y muy impactante visualmente ya que estás ofreciendo cuentas legibles y con sentido.

Como en cualquier otra aplicación accesible públicamente, hay que añadir algún tipo de mecanismo de seguridad. En mi caso lo he hecho implementando una blacklist de direcciones IP. Cada vez que se crea una cuenta actualizo en una base de datos el número de cuentas que se han creado desde esa IP, si pasa del límite que estimemos oportuno, esa IP se pasa a la tabla de lista negra y cuando intente crear una nueva cuenta no se le dejará.

Nos falta una cosa: Eliminar las cuentas que tienen más de una hora. Muy sencillo, una tarea en el CRON que ejecuta un script que lanza una consulta a la base de datos que elimina las cuentas (y sus correos asociados) que se crearon hace más de 60 minutos.

Finalmente he añadido la opción de reiniciar esos 60 minutos de tiempo, simplemente actualizando el timestamp de la base de datos y algunos efectos visuales para plegar y desplegar los mensajes usando Jquery.

No hay mucho más, en unas cinco horas tenemos la aplicación hecha y funcionando.

Conclusiones

Como conclusión, la misma que hice hace unos meses con el primer proyecto. La copio tal cual porque es igual de válida.

Bueno, y todo este rollo ¿para qué?. Pues muy sencillo, para que veais que hoy en día la tecnología está al alcance de todos, es sencillo y rápido crear un proyecto en Internet, hay de todo por todas las esquinas, la tecnología no es lo importante, lo que verdaderamente cuenta es cómo mueves ese producto tecnológico para rentabilizarlo y obtener un beneficio de él.

Ya tengo mi proyecto superchulo funcionando, sólo me ha costado unas 5 horas de trabajo. Le he puesto un poco de Adsense por aquí y por allí. ¿Y ahora qué? ¿A esperar a que la gente entre y me haga millonario? Es mucho más complicado que eso como todos sabéis, primero tienes que tener una masa de usuarios elevada que le dé movimiento al proyecto y después tienes que conseguir que la mayoría de ellos sean gente normal, no gente técnica, usuarios avanzados que no pagamos por nada ni pinchamos en publicidad .

Hoy en día, en Internet, como en cualquier negocio, las técnicas de marketing y venta son mucho más importantes que la tecnología en sí misma, es duro reconocerlo, pero es así. De nada sirve que tengas el mejor producto del mundo mundial si no consigues que la gente lo utilice y se deje dinero, así de claro. Si tienes los conocimientos adecuados para mover el negocio, no te preocupes, la tecnología te la aporta cualquier partner por un módico precio, pero poner en manos de otro toda la estrategia de ventas de tu negocio no está tan claro ¿no?.

Espero que os sirva de algo el artículo. He querido mostrar, fundamentalmente, cómo utilizando algunas librerías que puedes obtener sin coste puedes hacer algo realmente útil y funcional con muy poco esfuerzo. Seguro que sacáis alguna idea.

Perdón por el rollo , al final me ha costado mucho más escribir el artículo que implementarlo.

Podíamos haber añadido una opción que he visto por ahí que consiste en crear una cuenta automáticamente cada vez que entra un email para una cuenta que no existe, pero estaríamos creando cuentas para todo el spam que recibamos, así que prefiero no hacerlo. Si quisierais hacerlo creo que ya sabéis cómo.

Recientemente nos hemos encontrado con un problema que nos ha tenido varios días bloqueados hasta conseguir averiguar el origen. Llevamos mucho tiempo utilizando webservices programados en .NET desde aplicaciones PHP sin ningún problema, pero esta vez estaba hecho con la nueva tecnología WCF (Windows Communication Foundation) de Microsoft .NET 3.5. El problema era que en cuanto lo subimos a producción la aplicación PHP devolvía un pantallazo en blanco sin más información. Analizando los logs vimos que el proceso de Apache provocaba un Segmentation Fault con lo que no llegábamos a ver ninguna excepción.

Tras muchas pruebas conseguimos aislar el error en la línea de código que instanciaba el nuevo webservice, si eliminábamos esa parte todo funcionaba correctamente.

Lo más curioso es que en los entornos de preproducción sí que funcionaba, no entendíamos nada. Analizando las máquinas de los distintos entornos todas eran idénticas en cuanto a versiones y configuración excepto algunos parámetros SOAP para PHP, en la máquina de producción tienen la caché de wsdl activada mientras que en los demás está desactivada.

No puede ser que el error sea el cacheo. Pues sí, lo es, en cuanto desactivamos la caché del servidor de producción todo comenzó a funcionar correctamente.

Perfecto, pero la caché tiene que estar activada, la aplicación hace uso de unos 35 webservices, si para cada instancia de cada uno de ellos hay que cargar previamente el wsdl, el rendimiento cae por los suelos, es imprescindible.

Pues nada, solución increíblemente cutre:

Así es, desactivamos la caché antes de instanciar sólo este webservice y la volvemos a activar después. No hemos encontrado otra manera de solucionarlo ni hemos encontrado ninguna referencia de alguien que haya sufrido el mismo problema. La solución es mala, muy mala, no deja de ser un apaño, pero funciona y nos permite salir del paso hasta que sepamos por qué ocurre.

Si hace unas semanas veíamos como integrar las incidencias de Jira en Eclipse, hoy veremos como hacer lo propio con Microsoft Team Foundation Server (TFS).

En determinados proyectos nos vemos obligados utilizar TFS para el control de versiones, pero en nuestro caso lo utilizamos desde Eclipse utilizando un plugin desarrollado por Teamprise. A finales de 2009 Microsoft compró esta empresa con lo que el plugin se llama ahora Microsoft Visual Studio Team Explorer Everywhere 2010, casi nada , así que ya es parte de Visual Studio.

El paso final de la integración consiste en poder acceder a las incidencias del TFS desde el sistema integrado en Eclipse, Mylyn. Para conseguirlo Teamprise tiene otro plugin, Teamprise Mylyn Conector.

La instalación es muy sencilla, se descomprime en la carpeta de Eclipse, se reinicia éste y a funcionar. Veamos como configurarlo. Si no visualizamos la lista de tareas en nuestro Eclipse, vamos a “Window -> Show view -> Task list”, nos aparecerá la ventana correspondiente. Haciendo click con el botón derecho vamos a “New -> Query” y en la ventana que se abre seleccionamos “Add task repository“.

En la nueva ventana seleccionamos “Teamprise repository“:

Indicamos los datos del TFS:

Seleccionamos el nuevo repositorio creado:

El proyecto al que necesitamos acceder:

Y el tipo de incidencias a cargar: Eso es todo, en la ventana de “Task list” nos aparecerá la lista de las incidencias:

Tal y como veíamos en el caso de Jira, desde ahí podremos ver las incidencias, modificarlas, crear otras nuevas, asociar contextos, programar las tareas, etc.

¿La pega? Que no permite realizar filtros en las incidencias. Así como cuando vimos la integración con Jira la creación de consultas era muy completa, permitiendo múltiples filtros, en este caso se limita a recoger todas las incidencias del tipo indicado, no pudiendo, por ejemplo, recoger sólo las incidencias o tareas asociadas a nuestro usuario. Es un mal menor, sí, pero limita tu productividad ya que tienes que revisar todas las incidencias una por una hasta encontrar las tuyas. En el propio plugin de TFS el comportamiento es muy parecido, no puedes hacer filtros en las incidencias, como mucho puedes ordenarlas alfabéticamente por el “Asigned to” y localizar las tuyas, poco útil también.

Estoy tratando de mejorar el sistema de backups que utilizo habitualmente usando Amazon S3 como plataforma de almacenamiento. S3 (así como otros servicios Cloud de Amazon) tienen dos ventajas importantes, por un lado la disponibilidad, del orden del 99,99% y por otro el precio, altamente competitivo, cobran por espacio utilizado y por peticiones realizadas pero aún así sale por un precio espectacular.

Nuestro backup es del orden de 40gb, y, si el sistema va bien, planeo utilizarlo también para backups personales (fotos sobre todo ).

El requerimiento básico es que la sincronización se realizará de manera automatizada desde un servidor Linux con lo que el sistema debe permitir el envío desatentido.

Buscando por ahí como hacerlo encontré FuseOverAmazon, un sistema basado en Fuse que permite montar un “bucket” de S3 como si fuese una unidad local y sobre la que posteriormente podríamos utilizar rsync. ¿Qué más se puede pedir? Dicho y hecho, vamos a probarlo. En mi caso utilizo CentOS.

Vamos a probarlo.

Si todo ha ido bien tendrás montado en /mnt/s3 tu “nombrebucket” y podrás listar los archivos, copiar, eliminar, etc., como si fuese una unidad del equipo. Hasta aquí todo ha ido bien.  Sólo nos queda sincronizar nuestro backup:

Y aquí es donde viene el problema. En mi caso han pasado 4 días y aún no ha pasado del 10% de la sincronización, funciona todo bien pero la sincronización es extremadamente lenta, no sé si estoy haciendo algo mal, si es normal, o no, pero es imposible de utilizar así.

Como la idea no ha sido del todo buena, tenemos un plan B. Se trata de utilizar s3sync, un script en Ruby que hace el proceso muy sencillo, sólamente hay que configurarlo indicando tus datos de acceso y a funcionar:

Donde “prefijo” puede ser nulo.

Esto enviará a nombrebucket/prefijo/ tu backup.  De momento las pruebas son mucho más satisfactorias que con s3fs, la velocidad se puede considerar más que adecuada, sobre todo comparada con el anterior.

Como decía, de momento estoy probando el rendimiento y la velocidad, pero no estoy del todo convencido, así que estoy pensando en utilizar Amazon EC2 en vez de S3, de manera que lanzando una instancia de una máquina virtual pueda hacer un rsync clásico contra un sistema de ficheros de verdad. La ventaja es que la máquina virtual puedo lanzarla sólo cuando la necesite y pararla después, con lo que con una hora diaria podría ser suficiente, recordemos que Amazon EC2 cuesta, entre otras cosas, por cada hora que utilizas la instancia. Adicionalmente se podría hacer después un volcado del backup desde EC2 a S3, pero en nuestro caso los 40gb sería una limitación que encarecería el precio considerablemente aún en el caso de utilizar rotaciones semanales.

Ya os contaré .

Hoy voy a hablaros de algo que ha revolucionado mi entorno de trabajo. Hasta ahora tenía por un lado el entorno de desarrollo con Eclipse y por el otro el sistema de incidencias web con Jira (también sirven Trac o Bugzilla). La verdad es que me resultaba muy pesado ir cambiando de uno a otro para revisar las incidencias y más aún para cambiar los archivos necesarios para revisar las distintas incidencias. Cuando digo que me resultaba pesado me refiero a que entonces no me daba cuenta del tiempo que perdía, pero ahora sí.

Para comenzar veremos cómo podemos acceder a las incidencias desde el propio Eclipse sin necesidad de cambiar de aplicación. La magia viene aportada por Mylyn.

Para instalar el plugin necesario para Jira debemos añadir el repositorio donde se encuentra desde

con la url:

Desde este nuevo repositorio seleccionamos los componentes a instalar, probablemente Mylyn ya lo tengas instalado. Esto es lo que debes escoger:

Si en vez de Jira usas Trac o Bugzilla, utiliza el conector adecuado.

Una vez reiniciado Eclipse mostraremos la pestaña de incidencias desde

Desde el primer icono de la pestaña vamos a “Add Repository“.

Seleccionas el tipo de repositorio de incidencias que vas a crear.

Y añades los datos de acceso al mismo.

Si todo ha ido bien verás una pantalla similar a ésta donde puedes crear tu primera consulta de incidencias o seleccionar una previamente guardada en el servidor ya que importa tus filtros existentes.

Si decides crear una consulta nueva tienes un formulario con todas las opciones a tu disposición. Por ejemplo, yo he creado una que me lista todas las incidencias reportadas por mi.

Automáticamente irá recuperando del servidor las incidencias que cumplan los requisitos especificados en los filtros.

Haciendo doble click en una incidencia se abre el detalle de la misma con todas sus opciones que podremos modificar a nuestro antojo, añadir comentarios nuevos, adjuntar archivos, etc.

Mylyn aporta al sistema funcionalidades extra, una de ellas es la de programarnos las incidencias en función de nuestra carga de trabajo y tener una previsión de lo que vamos a hacer y cuando. Esta información no se guarda en el servidor, es interna.

A la hora de adjuntar archivos, además de seleccionar los que tengamos en nuestro equipo podremos hacer directamente desde Eclipse una captura de pantalla, recortar el trozo que nos interesa y enviarlo a Jira, todo en uno y sin salir de nuestro entorno de desarrollo.

Llegamos a una de las opciones que realmente hacen que ahorremos muchísimo tiempo, el contexto. Cada incidencia tiene un circulito a su izquierda que permite activar esa tarea. Al activar una tarea el sistema asume que todos los archivos que vayas abriendo mientras la tengas activada están asociados a la resolución de la misma.

Abre algunos archivos de ejemplo y en la pestaña “Context” de la incidencia verás cómo va asociándolos. Si ahora, en vez de cerrar la incidencia en la “X” la desactivas de nuevo en el circulito, verás como automáticamente se cierran también todos los archivos asociados. Y aquí viene lo bueno, si vuelves a activarla se abren automáticamente todos los archivos sobre los que estabas trabajando. Este sistema te permite cambiar rápidamente el entorno de trabajo de una incidencia a otra sin tener que buscar de nuevo todos los fuentes uno a uno.

Hay una opción más para trabajar con los contextos que permite que distintos usuarios los compartan y consiste en subirlos al propio servidor de Jira. Se suben como archivos zip como si fuese un archivo adjunto a la incidencia normal y corriente, pero Mylyn sabe lo que tiene que hacer con ellos cuando se recuperan.

Finalmente otra opción interesante es la integración con Subversion. Teniendo una incidencia activada, cada vez que hagamos commit al repositorio nos adjuntará automáticamente en el comentario del svn información acerca de la incidencia que se resuelve, eso que nunca hacemos .

Como veis tenemos el desarrollo junto a las incidencias y la resolución de las mismas en Subversión completamente integrado en una sola aplicación. Cuando os comentaba al principio del artículo sobre que no me daba cuenta de lo pesado que era hacerlo en tres pasos, ahora veis a qué me refería, es una de esas cosas que hasta que las tienes no sabes lo que vale.