jueves, diciembre 05, 2013
martes, diciembre 03, 2013
miércoles, octubre 10, 2012
Cuadrar Ventanas Mosaico en Openbox
(text Editor) ~/.config/openbox/rc.xml
Y pegar el siguiente texto en la sección de KeyBindings:
<!-- Keybindings for window tiling -->
<keybind key="W-Left"> # HalfLeftScreen
<action name="UnmaximizeFull">
<action name="MoveResizeTo">
<x>0</x>
<y>0</y>
<height>100%</height>
<width>50%</width>
</action>
</action></keybind>
<keybind key="W-Right"> # HalfRightScreen
<action name="UnmaximizeFull">
<action name="MoveResizeTo">
<x>-0</x>
<y>0</y>
<height>100%</height>
<width>50%</width>
</action>
</action></keybind>
<keybind key="W-Up"> # HalfUpperScreen
<action name="UnmaximizeFull">
<action name="MoveResizeTo">
<x>0</x>
<y>0</y>
<width>100%</width>
<height>50%</height>
</action>
</action></keybind>
<keybind key="W-Down"> # HalfLowerScreen
<action name="UnmaximizeFull">
<action name="MoveResizeTo">
<x>0</x>
<y>-0</y>
<width>100%</width>
<height>50%</height>
</action>
</action></keybind>
<keybind key="C-Left"> # QuartLowerLeftScreen
<action name="UnmaximizeFull">
<action name="MoveResizeTo">
<x>0</x>
<y>-0</y>
<width>50%</width>
<height>50%</height>
</action>
</action></keybind>
<keybind key="C-Right"> # QuartUpperRightScreen
<action name="UnmaximizeFull">
<action name="MoveResizeTo">
<x>-0</x>
<y>0</y>
<width>50%</width>
<height>50%</height>
</action>
</action></keybind>
<keybind key="C-Up"> # QuartUpperLeftScreen
<action name="UnmaximizeFull">
<action name="MoveResizeTo">
<x>0</x>
<y>0</y>
<width>50%</width>
<height>50%</height>
</action>
</action></keybind>
<keybind key="C-Down"> # QuartLowerRightScreen
<action name="UnmaximizeFull">
<action name="MoveResizeTo">
<x>-0</x>
<y>-0</y>
<width>50%</width>
<height>50%</height>
</action>
</action></keybind>
<keybind key="A-Right"> # FullScreen
<action name="UnmaximizeFull">
<action name="MoveResizeTo">
<x>0</x>
<y>0</y>
<width>100%</width>
<height>100%</height>
</action>
</action></keybind>
<keybind key="A-Left"> # MiddleScreen
<action name="UnmaximizeFull">
<action name="MoveResizeTo">
<x>center</x>
<y>center</y>
<width>50%</width>
<height>50%</height>
</action>
</action></keybind>
miércoles, junio 20, 2012
OpenEJB 4.0.0 + Debian 6 + Running Tomcat 6 installed from repository
http://openejb.apache.org/tomcat.html
Al momento de la instalación se presentaran problemas de permisos de directorios y archivos, para solventar esto debemos otrogar permisos de escritura a los siguientes directorios y archivos:
sudo chmod 777 /var/lib/tomcat6/conf/server.xml sudo chmod 777 /usr/share/tomcat6/bin/catalina.sh sudo chmod 777 /usr/share/tomcat6/bin/catalina.bat (este archivo no existe, debemos crearlo antes) sudo chmod 777 /usr/share/tomcat6/lib sudo chmod 777 /etc/tomcat
Una vez realizada la instalación de manera satisfactoria debemos reasignar los permisos anteriores a los directorios y archivos:
sudo chmod 644 /var/lib/tomcat6/conf/server.xml sudo chmod 755 /usr/share/tomcat6/bin/catalina.sh sudo chmod 755 /usr/share/tomcat6/bin/catalina.bat sudo chmod 755 /usr/share/tomcat6/lib sudo chmod 755 /etc/tomcat
martes, marzo 27, 2012
Trasladar todas las Ramas de un Repositorio Git a otro
#!/bin/bash for remote in `git branch -r `; do git checkout --track $remote; done
#!/bin/bash git remote add new-origin git@my_gitosis_server.com:my_new_repos.git
#!/bin/bash git push --all new_remote
martes, enero 10, 2012
Crear instancia de Trac apuntando a un repositorio Subversion
#!/bin/bash
PROY=$1
if [ -z "$1" ];
then
echo Por favor, introduzca el nombre del proyecto a crear
read PROY
fi
ADMIN_USERNAME=$2
if [ -z "$2" ];
then
echo Por favor, introduzca el usuario administrador del proyecto
read ADMIN_USERNAME
fi
SVN=/srv/svn
if [ -d $SVN ]; then
echo El directorio $SVN existe, continuamos con el proyecto
else
mkdir $SVN
fi
#Creamos el svn
mkdir $SVN/$PROY
mkdir /tmp/$PROY
mkdir /tmp/$PROY/trunk
mkdir /tmp/$PROY/branches
mkdir /tmp/$PROY/tags
#Importamos los directorios al SVN
svnadmin create $SVN/$PROY --fs-type fsfs
svn import /tmp/$PROY file://$SVN/$PROY -m "Inicio"
#Borramos directorios temporales
rm -rf /tmp/$PROY
#Cambiamos permisos y propietario de los ficheros
find $SVN/$PROY -type f -exec chmod 660 {} \;
find $SVN/$PROY -type d -exec chmod 2770 {} \;
chown -R www-data.www-data $SVN/$PROY
#Comprobamos si existe el directorio $DIR_TRAC , si no lo creamos
DIR_TRAC=/srv/trac
if [ -d $DIR_TRAC ]; then
echo El directorio $DIR_TRAC existe, continuamos con el proyecto
else
mkdir $DIR_TRAC
fi
#Importamos el SVN al TRAC y agregamos un administrador
trac-admin $DIR_TRAC/$PROY initenv
trac-admin $DIR_TRAC/$PROY permission add developer TRAC_ADMIN
trac-admin $DIR_TRAC/$PROY permission add $ADMIN_USERNAME developer
#Cambiamos los permisos a los ficheros y directorios del trac
find $DIR_TRAC/$PROY -type f -exec chmod 660 {} \;
find $DIR_TRAC/$PROY -type d -exec chmod 2770 {} \;
chown -R www-data.www-data $DIR_TRAC/$PROY
lunes, junio 06, 2011
La importancia de ser humilde
lunes, mayo 09, 2011
Los 6 principios de Ágil Simple
Cuando estamos durante una implementación ágil, en particular en equipos ágiles nuevos, a menudo hacemos las cosas demasiado complejas y dificiles. Tenemos la tendencia a poner parches y sobre el proceso hastas que termina siendo un monstruo grande y poco útil. ¡Necesitamos intervenir a tiempo! Así que respiren profundo, relájense y veamos juntos cómo simplificar nuestra vida en un equipo ágil.
El punto de inicio son 6 principios básicos que llamo "Ágil Simple".
Los 6 principios de Ágil Simple
- Colaborar
- Trabajar juntos
- Respetar las prioridades
- Respetar al cliente, al proceso, al producto, al equipo y a nosotros
- Hacer la cosa más simple que funcione - y ahí parar
- Mejorar en cada iteración
Repasemos rápidamente esta lista.
1. Colaborar
Muy simple, "colaborar" significa comunicarse de forma efectiva entre nosotros. No existe un equipo ágil sin comunicación. La comunicación tiene que ser lo más cerca posible al tiempo-real , y con la mejora calidad. En contadas ocasiones las personas del equipo podrían no elegir el mejor método de comunicación, pero esto debería ser la excepción a la regla.
2. Trabajar juntos
El paso siguiente a comunicarse bien es trabajar juntos. Por ejemplo, un Dueño del Producto, un tester y un desarrollador llegan a un acuerdo sobre lo que significa una historia en particular. Esto nos significa que el tester y el desarrollador siguen caminos separados. Debemos trabajar juntos y cerca para asegurarnos que este entendimiento compartido siga siendo compartido. Por otro lado, la programación de a pares es beneficiosa por muchos motivos. Está probado que trabajar de a pres incrementa de forma significativa la calidad del producto sin afectar la productividad.
3. Respetar las prioridades
Siempre, siempre, siempre debemos trabajar sobre un backlog PRIORIZADO. Debemos trabajar sobre los requerimientos en el órden en que aparecen en el backlog a menos que surja alguna circunstancia excepcional (como ser una historia demasiado grande para que entre en la iteración, y esperamos a la siguiente iteración para meter antes una historia pequeña). Todos deberían seguir la regla "lo próximo para hacer debería ser una tarea de la más alta prioridad en la que podamos trabajar". Esto significa que más de una persona va a trabajar en la misma historia. Además significa que habrá menos historias abiertas (se limita el trabajo en progreso, o WIP). También nos lleva a entregar al máximo valor en cada iteración.
4. Respetar al cliente, al proceso, al producto, al equipo y a nosotros
¿Cuándo sabe el cliente exactamente lo que quiere? ¡Cuando lo ven, por supuesto! ¿Cuándo saben lo que sienten por el producto? Cuando lo ven. Tenemos que dejar al cliente que vea más seguido a su producto, recolectar el feedback y utilizarlo. Debemos respetar al proceso y seguirlo; todos somos responsables por el éxito del proceso. Debemos respetar al producto disminuyendo su complejidad y quitando la deuda técnica. Debemos respetar al equipo y no imponer metas irreales; el equipo tiene que ser sustentable y ser capaces de resolver sus propios problemas. Debemos respetarnos entre nosotros, trabajando juntos hacia el éxito y apoyandonos todo el tiempo. Podría seguir sobre este tema mucho más. Prueben hacer el siguiente ejercicio: en un papel escriban todas las distintas maneras en la que se podría mejorar el respeto sobre estos temas, y al lado de cada una escriban una lista de los efectos que generarían ese cambio. Se van a sorprender de la diferencia que pueden lograr.
5. Hacer la cosa más simple que funcione - y ahí parar
Todos en la industria del software tenemos la tendencia a hacer demasiado en cada característica. Es como si las recubriéramos en oro. Y es muy facil caer en esta trampa. Es común escuchar cosas como "mientras estaba en eso hice XYZ", o "la historia no decía nada, pero yo sé que al usuario lo quiere así que lo hice". Ninguna de estas frases deberían escucharse en un equipo ágil. Debemos hacer la cosa más simple que funcione - y luego parar. Debemos preguntarle al cliente (recordar que lo respetamos al involucrarlo) si estamos en lo cierto.
6. Mejorar en cada iteración
Recuerden, lograr un 1% mejor por cada iteración de 2 semanas hará que el equipo sea un 25% después de un año. No se necesitan grandes mejoras, sino muchas mejoras pequeñas. Este es el concepto clave de "Ágil Simple" porque nos permite entender que nunca seremos perfectos.
Estos 6 principios están pensados para que los equipos vuelvan a pensar en lo que es importante. Los principios están muy inspirados en los principios del desarrollo Lean. Yo creo en estos principios. Y creo que los equipos logran hacer una enorme diferencia cuando ellos también los creen. ¿Cuántos de estos principios están violando hoy, y qué van a hacer para volver a hacer lo esencial?
lunes, enero 17, 2011
Prólogo del Libro: "Diseño Ágil con TDD" de @carlosble
Erase una vez que se era, un lejano país donde vivían dos cerditos, Pablo y Adrián que, además, eran hermanos. Ambos eran los cerditos más listos de la granja y, por eso, el gallo Iván (el gerente de la misma) organizó una reunión en el establo, donde les encargó desarrollar un programa de ordenador para controlar el almacén de piensos. Les explicó qué quería saber en todo momento: cuántos sacos de grano había y quién metía y sacaba sacos de grano del almacén. Para ello sólo tenían un mes pero les advirtió que, en una semana, quería ya ver algo funcionando. Al final de esa primera semana, eliminaría a uno de los dos.
Adrián, que era el más joven e impulsivo, inmediatamente se puso manos a la obra. "¡No hay tiempo que perder!", decía. Y empezó rápidamente a escribir líneas y líneas de código. Algunas eran de un reciente programa que había ayudado a escribir para la guardería de la vaca Paca. Adrián pensó que no eran muy diferentes un almacén de grano y una guardería. En el primero se guardan sacos y en el segundo, pequeños animalitos. De acuerdo, tenía que retocar algunas cosillas para que aquello le sirviera pero bueno, esto del software va de reutilizar lo que ya funciona, ¿no?.
Pablo, sin embargo, antes de escribir una sola línea de código comenzó acordando con Iván dos cosas: qué era exactamente lo que podría ver dentro de una semana y cómo sabría que, efectivamente, estaba terminada cada cosa. Iván quería conocer, tan rápido como fuera posible, cuántos sacos de grano había en cada parte del almacén porque sospechaba que, en algunas partes del mismo, se estaban acumulando sacos sin control y se estaban estropeando. Como los sacos entraban y salían constantemente, no podía saber cuántos había y dónde estaban en cada instante, así que acordaron ir contabilizándolos por zonas y apuntando a qué parte iba o de qué parte venía, cada vez que entrara o saliera un saco. Así, en poco tiempo podrían tener una idea clara del uso que se estaba dando a las distintas zonas del almacén.
Mientras Adrián adelantaba a Pablo escribiendo muchas líneas de código, Pablo escribía primero las pruebas automatizadas. A Adrián eso le parecía una pérdida de tiempo. ¡Sólo tenían una semana para convencer a Iván!
Al final de la primera semana, la demo de Adrián fue espectacular, tenía un control de usuarios muy completo, hizo la demostración desde un móvil y enseñó, además, las posibilidades de un generador de informes muy potente que había desarrollado para otra granja anteriormente. Durante la demostración hubo dos o tres problemillas y tuvo que arrancar de nuevo el programa pero, salvo eso, todo fue genial. La demostración de Pablo fue mucho más modesta, pero cumplió con las expectativas de Iván y el programa no falló en ningún momento. Claro,todo lo que enseñó lo había probado muchísimas veces antes gracias a que había automatizado las pruebas. Pablo hacía TDD, es decir, nunca escribía una línea de código sin antes tener una prueba que le indicara un error. Adrián no podía creer que Pablo hubiera gastado más de la mitad de su tiempo en aquellas pruebas que no hacían más que retrasarle a la hora de escribir las funcionalidades que había pedido Iván. El programa de Adrián tenía muchos botones y muchísimas opciones, probablemente muchas más de las que jamás serían necesarias para lo que había pedido Iván, pero tenía un aspecto "muy profesional".
Iván no supo qué hacer. La propuesta de Pablo era muy robusta y hacía justo lo que habían acordado. La propuesta de Adrián tenía cosillas que pulir, pero era muy prometedora. ¡Había hecho la demostración desde un móvil! Así que les propuso el siguiente trato: “Os pagaré un 50% más de lo que inicialmente habíamos presupuestado, pero sólo a aquel de los dos que me haga el mejor proyecto. Al otro no le daré nada.”. Era una oferta complicada porque, por un lado, el que ganaba se llevaba mucho más de lo previsto. Muy tentador. Pero, por el otro lado, corrían el riesgo de trabajar durante un mes completamente gratis. Mmmmm.
Adrián, tan impulsivo y arrogante como siempre, no dudó ni un instante. "¡Trato hecho!", dijo. Pablo explicó que aceptaría sólo si Iván se comprometía a colaborar como lo había hecho durante la primera semana. A Iván le pareció razonable y les convocó a ambos para que le enseñaran el resultado final en tres semanas.
Adrián se marchó pitando y llamó a su primo Sixto, que sabía mucho y le aseguraría la victoria, aunque tuviera que darle parte de las ganancias. Ambos se pusieron rápidamente manos a la obra. Mientras Adrián arreglaba los defectillos encontrados durante la demo, Sixto se encargó de diseñar una arquitectura que permitiera enviar mensajes desde el móvil hasta un webservice que permitía encolar cualquier operación para ser procesada en paralelo por varios servidores y así garantizar que el sistema estaría en disposición de dar servicio 24 horas al día los 7 días de la semana.
Mientras tanto, Pablo se reunió con Iván y Bernardo (el encargado del almacén) para ver cuáles deberían ser las siguientes funcionalidades a desarrollar. Les pidió que le explicaran, para cada petición, qué beneficio obtenía la granja con cada nueva funcionalidad. Y así, poco a poco, fueron elaborando una lista de funcionalidades priorizadas y resumidas en una serie de tarjetas. A continuación, Pablo fue, tarjeta a tarjeta, discutiendo con Iván y Bernardo cuánto tiempo podría tardar en terminarlas. De paso, aprovechó para anotar algunos criterios que luego servirían para considerar que esa funcionalidad estaría completamente terminada y eliminar alguna ambigüedad que fuera surgiendo.Cuando Pablo pensó que, por su experiencia, no podría hacer más trabajo que el que ya habían discutido, dio por concluida la reunión y se dispuso a trabajar. Antes que nada, resolvió un par de defectos que habían surgido durante la demostración y le pidió a Iván que lo validara. A continuación, se marchó a casa a descansar. Al día siguiente, cogió la primera de las tarjetas y, como ya había hecho durante la semana anterior, comenzó a automatizar los criterios de aceptación acordados con Iván y Bernardo. Y luego, fue escribiendo la parte del programa que hacía que se cumplieran esos criterios de aceptación. Pablo le había pedido ayuda a su amigo Hudson, un coyote vegetariano que había venido desde América a pasar el invierno. Hudson no sabía programar, pero era muy rápido haciendo cosas sencillas. Pablo le encargó que comprobara constantemente los criterios de aceptación que él había automatizado. Así, cada vez que Pablo hacía algún cambio en su programa, avisaba a Hudson y este hacía, una tras otra, todas las pruebas de aceptación que Pablo iba escribiendo. Y cada vez había más. ¡Este Hudson era realmente veloz e incansable!.
A medida que iba pasando el tiempo, Adrián y Sixto tenían cada vez más problemas. Terminaron culpando a todo el mundo. A Iván, porque no les había explicado detalles importantísimos para el éxito del proyecto. A la vaca Paca, porque había incluido una serie de cambios en el programa de la guardería que hacía que no pudieran reutilizar casi nada. A los inventores de los SMS y los webservices, porque no tenían ni idea de cómo funciona una granja. Eran tantos los frentes que tenían abiertos que tuvieron que prescindir del envío de SMS y buscaron un generador de páginas web que les permitiera dibujar el flujo de navegación en un gráfico y, a partir de ahí, generar el esqueleto de la aplicación. ¡Eso seguro que les ahorraría mucho tiempo! Al poco, Sixto, harto de ver que Adrián no valoraba sus aportaciones y que ya no se iban a usar sus ideas para enviar y recibir los SMS, decidió que se marchaba, aún renunciando a su parte de los beneficios. Total, él ya no creía que fueran a ser capaces de ganar la competición.
Mientras tanto, Pablo le pidió un par de veces a Iván y a Bernardo que le validaran si lo que llevaba hecho hasta aquel momento era de su agrado y les hizo un par de demostraciones durante aquellas 3 semanas, lo que sirvió para corregir algunos defectos y cambiar algunas prioridades. Iván y Bernardo estaban francamente contentos con el trabajo de Pablo. Sin embargo, entre ellos comentaron más de una vez: "¿Qué estará haciendo Adrián? ¿Cómo lo llevará?".
Cuando se acercaba la fecha final para entregar el programa, Adrián se quedó sin dormir un par de noches para así poder entregar su programa. Pero eran tantos los defectos que había ido acumulando que, cada vez que arreglaba una cosa, le fallaba otra. De hecho, cuando llegó la hora de la demostración, Adrián sólo pudo enseñar el programa instalado en su portátil (el único sitio donde, a duras penas, funcionaba) y fue todo un desastre: mensajes de error por todos sitios, comportamientos inesperados... y lo peor de todo: el programa no hacía lo que habían acordado con Iván.
Pablo, sin embargo, no tuvo ningún problema en enseñar lo que llevaba funcionando desde hacía mucho tiempo y que tantas veces había probado. Por si acaso, dos días antes de la entrega, Pablo había dejado de introducir nuevas características al programa porque quería centrarse en dar un buen manual de usuario, que Iván había olvidado mencionar en las primeras reuniones porque daba por sentado que se lo entregarían. Claro, Adrián no había tenido tiempo para nada de eso.
Moraleja:
Además de toda una serie de buenas prácticas y un proceso de desarrollo ágil, Pablo hizo algo que Adrián despreció: acordó con Iván (el cliente) y con Bernardo (el usuario) los criterios mediante los cuáles se comprobaría que cada una de las funcionalidades estaría bien acabada. A eso que solemos llamar "criterios de aceptación", Pablo le añadió la posibilidad de automatizar su ejecución e incorporarlos en un proceso de integración continua (que es lo que representa su amigo Hudson en este cuento). De esta manera, Pablo estaba siempre tranquilo de que no estaba estropeando nada viejo con cada nueva modificación. Al evitar volver a trabajar sobre asuntos ya acabados, Pablo era más eficiente. En el corto plazo, las diferencias entre ambos enfoques no parecen significativas, pero en el medio y largo plazo, es evidente que escribir las pruebas antes de desarrollar la solución es mucho más eficaz y eficiente.
Sitio Web: http://www.dirigidoportests.com
Descarga: http://www.dirigidoportests.com/wp-content/uploads/2010/02/disenoAgilConTdd_ebook.pdf