miércoles, octubre 10, 2012

Cuadrar Ventanas Mosaico en Openbox

Editar el archivo rc.xml

(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

Siga las instrucciones del sitio web oficial del proyecto Apache TomEE (OpenEJB)

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

Una última palabra de consejo general cuando nos preparamos para estudiar las reglas específicas de diseño. Para producir grandes productos, los diseñadores, incluso los mejores, nunca deben sobrestimar el valor de su experiencia. Todo proyecto ambicioso de software es un nuevo reto: no hay recetas seguras.
El diseño de un gran producto de software es una nueva aventura intelectual. Demasiada autoconfianza puede hacer daño. Cuantos más libros se hayan leído (o escrito), cuantas más clases se hayan seguido (o impartido), cuantos más lenguajes de programación se conozcan (o se hayan diseñado), cuantos más software O-O se haya examinado (o producido), cuantos más patrones de diseño se hayan aprendido (o diseñado), cuanto mayor sea el número de reuniones a las que haya asistido (o se hayan moderado), cuantos más colegas con talento se hayan conocido (o contratado), cuanto mayor sea el número sea el número de proyectos en que se haya colaborado (o dirigido), mejor preparado se estará para lidiar con un nuevo desarrollo. Pero no vaya a pensar que sus experiencias lo hacen infalible. En el diseño de software avanzado no hay sustituto para el pensamiento fresco y las ideas creativas. Todo nuevo problema reclama nuevas ideas; y cualquiera, desde el experimentado jefe de proyecto hasta el último recluta, puede tener la visión correcta de una cuestión particular; y cualquiera se puede equivocar. Lo que distingue al gran diseñador no es necesariamente el tener menos ideas malas, sino el saber cómo descartarlas, venciendo a su orgullo y quedándose con las buenas ideas, hayan sido o no de su creación. La incompetencia y la inexperiencia son obstáculos obvios en la búsqueda de la solución correcta; el engreimiento puede ser igual de malo.

Fuente: Bertran Meyer "Construcción de Software Orientado a Objetos"

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

  1. Colaborar
  2. Trabajar juntos
  3. Respetar las prioridades
  4. Respetar al cliente, al proceso, al producto, al equipo y a nosotros
  5. Hacer la cosa más simple que funcione - y ahí parar
  6. 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?

Original: 6 principles of Simple Agile, por Bob Hartman

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