El dominio de la tecnología Publicado por Ale Vouilloz , sábado 4 de julio de 2009 at 12:05, in Etiquetas: celulares, dominio, Tecnologia

Este articulo no es para nada técnico e invita a la reflexión con la siguiente pregunta:

El hombre domina a la tecnología, o la tecnología domina al hombre?

En principio esta pregunta parece simple de responder al reconocer que el hombre es el productor inicial de la tecnología, por lo tanto, este mismo debería ser el único que pueda resolverla. De esta forma es esencial tener siempre presente el fundamento del origen de la tecnología, el de facilitar algunos aspectos de la vida humana. Pero en la actualidad se evidencian signos de dependencia que que no promueven ese bienestar.

Voy a ejemplificar con lo que me llevo a meditar y a escribir este articulo:

Me encontraba tratando de activar en mi sistema operativo (Ubuntu Linux) un gestor de ventanas llamado Compiz. Cuando resolví los conflictos de incompatibilidades con la versión del driver de mi placa de video, pude activarlo! Ahora tenia a disposición un montón de efectos deslumbrantes y cosas que servían para...mmm...para...[pausa de silencio...] Esto me robo un montón de tiempo y no lo voy a usar para otra cosa que para presumirle a mis amigos!. Termine dejando solamente activo un zoom de escritorio y un control de ventanas transparentes, un 1% de todo lo que permite Compiz. La tecnología me ayudo o me domino temporalmente?

Otro ejemplo claro podemos encontrarlo en las funcionalidades que traen los teléfonos móviles (Se los puede seguir llamándolos teléfonos móviles?). La novedad por la cual empresas como Sony Ericsson pueden atraer a sus clientes para incrementar sus ganancias se conoce como Shake Control y Gesture Control que permite maravillas como controlar el volumen del mp3 que estamos escuchando moviendo el brazo. [pausa de silencio...] Pero si en mi radio portátil que llevaba hace 20 años podía subir el volumen girando una ruedita con solo mover mi dedo pulgar!!!
Más? El touch screen con lapices en pantallas pequeñas es más incomodo que presionar botones!!

La única vez que me asombre con una funcionalidad de estos aparatitos fue cuando un nokia 1100 me alumbro la parrilla para ver como se iban asando las costillas.

En fin, los teléfonos móviles son la cuna donde se crian multitud de funcionalidades tecnológicas sin sentido.

Más? Con Facebook estamos mas conectados con nuestros amigos...mmm... [pausa de silencio...] En muchos casos no es asi, las redes sociales en algunos casos provocan más aislamiento social aun, pero esto da para discutirlo en un articulo exclusivo.

Aunque pienso que una persona verdaderamente inteligente nunca seria capaz de consumir estas cosas (no veo a Einstein gastando parte de su sueldo en comprar un iphone) hay que reconocer que están pasando cosas con la tecnología que no nos beneficia en lo mas mínimo.

Pero la tecnología por si sola no podría fascinarnos al punto de dominarnos, algo mas debe haber. Creo que uno de los motores que mueven y promueven esta redención casi total y ridícula hacia la tecnología es el consumismo inducido por el sistema económico.

El mundo actual con sus programas de MTV, sus publicidades gráficas que abarcan paredes de edificios enteros y su películas "hollywoodenses" bombardean nuestras mentes para hacernos creer que con el último celular somos mas "fashion", que con la última Mac vamos a ser mas productivos aunque solamente usemos un editor de texto para escribir nuestro diario intimo.

Reconozco que como amante de la tecnología existen momentos en que ella me domina. Lucho para que no sea asi y yo tomar el poder. Al escribir este blog precisamente estoy sacando provecho de ella, o no? [pausa de silencio...]

La negación al cambio Ágil Publicado por Ale Vouilloz , martes 16 de junio de 2009 at 11:41, in Etiquetas: agil, metología, scrum

En una reunión de amigos, pizzas y cervezas de sábado por la noche, he tenido una interesante discusión sobre agilidad/clacisismo en el desarrollo de software.

Cómo había minoría de mujeres y además como ellas empezaron a intercambiar opiniones sobre la familia, ropa, modas, etc, aprovechamos la excusa perfecta para nuestra charla geek.

El tema comenzó cuando un colega se animó a describir su nueva metodología de trabajo en la empresa en la que se desempeña como desarrollador senior (un muy conocido site de e-commerce para America Latina). Nos contó al resto como adoptaron Scrum, y de como los cambios implementados promovieron la productividad siendo ésta consecuencia directa de un sentimiento de mayor responsabilidad y compromiso en todos los equipos, que a su vez era producida por una mayor participación en ciertas funciones que ántes no les incumbía, tales como estimaciones con números de Fibonacci, monitorización de un backlog en pizarra física a la vista de todos, reuniones diarias, presentaciones de demos de Sprints, etc.

Pero como suele suceder en toda charla saltó alguien que inició el debate. Ésto sabemos que es bueno, ya que produce intercambio de opiniones y replanteamientos de ideas. Su argumento inicial era el siguiente:

Al colega que contó su experiencia le había funcionado una metodología Ágil y la habian podido adaptar al proceso de su empresa porque desarrollaban para un dueño de producto que era interno a la compañía. Si el dueño de producto es un cliente ajeno a la compañia no se puede usar un método ágil ya que al cliente no le interesa ir viendo como se va haciendo todo, si no que sólamente le interesa el resultado final.

En un principio pareció un planteo iteresante de analizar pero cuando se entro de lleno al debate, el argumento no tenía bases para su defensa.

La discusión llevo a la conclusión de que un cliente externo a la empresa se interesaría más aún que un interno en el progreso de su sistema que ha pedido desarrollar. Ésta conclusión se heredo del hecho que la confianza depositada por un externo en un equipo siempre es menor que la que tendría un interno a la organización, o al menos en circunstancias normales ésto debería ser así, por el fácil acceso que tendría un gerente interno a los skills del personal. Por lo tanto un externo es siempre más "celoso" con su capital de inversión. O sea, que si éste logra comprender que podrá ir teniendo pequeñas porciones usables de su producto final en susecivas entregas cada de 15 días o un mes y que en caso de que una pequeña porción de producto no es la que realmente se necesita, el cambio sería menor, lo que decrementaría el riesgo del proyecto entero. Resumiendo, mientras exista un inversor que más desconozca el riesgo de su proyecto pedido, más querrá estár al tanto del progreso del mismo. Por lo tanto si un cliente externto sabe que la agilidad es la herramienta que le resuelve ese dilema...la preferirá siempre!!!

Obviamente el único que no acepto ésta conclusión fue "el contra", cambiando constantemente de argumentos desviando así el debate y cambiando el foco de su ya perdida discusión.

Moraleja: Existen personas que siempre van a estar tirando en contra de un cambio positivo, aunque éstos sean fácilmente demostrables, por alguna razón que no termino de entender bien, pero me gustaría saber porque. ¿Será por una personalidad de llevar "la contra" como mi amigo, pereza, o miedo al cambio? Lo que si se ahora, es que éstas personas están presentes tanto en cargos gerenciales como en líderes de proyectos y desarrolladores.

¿Que factores piensan que pueden llevar que algunas personas se opongan al cambio Ágil?

LiveCD de Ágil Publicado por Ale Vouilloz , viernes 5 de junio de 2009 at 13:45, in Etiquetas: agil, metología, scrum

Un alto porcentaje de la gente que crítica a Ágil no conoce de que va el tema y se resisten a comprender sus ventajas por una multitud de motivos sin sentido y presentando excusas tontas como: “ahh, pero en mis proyectos no se podría aplicar, mis proyectos son especiales”. Pfff…Ahora somos todos especiales!! Otros reconocen ciertas ventajas pero no se animan al cambio debido a que algunas prácticas propuestas exigen cierta destreza.

Sin embargo, podemos realizar pequeños pasos para introducirnos en ágil y asomarnos levemente a ver más o menos de que se trata.

Una forma de asomarse al agilismo puede llegar a ser éste desafío que lo tomé prestado de ésta web chilena y permite que los conservadores y cautelosos puedan experimentar sin “dañar nada de su sistema”, similar a un liveCD :) como se calcula la velocidad de un equipo de desarrollo usando Kanban o mejor dicho algo de Kanban.

1. Listar en post-its las tareas de cada uno para las próximas dos semanas

2. Escribir en cada post-it el tiempo que demoraría en hacerse en condiciones óptimas (sin interrupciones)

3. Frente al escritorio de trabajo, crear un panel (que llamaremos Panel Kanban) con 3 columnas: Ítemes que no han partido, ítemes comenzados e Ítemes finalizados

4. En las dos semanas, mover los post-its de una columna a otra a medida que se progresa

5. Al final de las 2 semanas, sumar los numeros de aquellas tareas que estén en la columna “finalizados”

Al dividir la suma de horas “ideales” logradas sobre el total de horas de trabajo de las 2 semanas, habrán medido su velocidad. Ahora tienen una medida de cuanto son capaces de realizar cada 2 semanas, y por ende tienen una guía cerca de cuanto pueden comprometerse para la próxima.

¿Que les parece esta experiencia?

Resultado de la encuesta sobre RIA's Publicado por Ale Vouilloz , jueves 30 de abril de 2009 at 01:23, in

Otra vez una encuesta con tan pocos votantes no es indicador de mucho.
Pero creyendo en una tendencia de 29 votos se destacan las herramientas Flash/Flex, Ajax con librerias Javascript y GWT sobre JavaFX, Silverlight y OpenLaszlo.
No hay mucho para decir. Es lo que esperaba.

Lean en la producción de Software Publicado por Ale Vouilloz , viernes 27 de marzo de 2009 at 12:39, in Etiquetas: agil, ingeniería, Lean, metología, procesos, software

Considerado por los expertos como el sistema de fabricación del siglo XXI, Lean Manufacturing es un sistema de gestion de proceso de producción impulsado por Toyota. Su objetivo primordial es implantar la eficacia en todos los procesos del negocio, eliminando las actividades que no aportan valor añadido (denominadas waste), con el fin de generar beneficios tangibles para el cliente final.

Veamos los cinco principios del Lean:

1. "Understanding Consumer Value" o comprensión de lo que es valor para el cliente; el foco se externaliza desplazándose hasta el consumidor final, que es quien decide lo que es importante y le aporta valor.
2. "Value Stream Analysis" o estudio de todas las fases del proceso de producción, para determinar las que añaden valor y las que se deben cambiar o eliminar.
3. "Flow" o unificación de las fases de trabajo en un espacio único.
4. "Pull" o fase final, en la que el producto no se termina hasta que los clientes no hacen el pedido.
5. "Perfection" u objetivo final. En la medida en que se eliminan los pasos innecesarios y los flujos de trabajo se adaptan a los pedidos de los clientes, se comprueban las reducciones de costes, esfuerzo y tiempos de trabajo en todas las áreas de la empresa. continuas.

Mejoras Continuas.

El soporte a los principios del Lean Manufacturing, se realiza en tres áreas funcionales básicas: gestión, planificación y ejecución, y reducción de actividades sin valor añadido.

En el área de gestión, esta metodología analiza todos los procesos y prácticas respecto a una serie de indicadores clave, y establece unos criterios fundamentales que sirven de punto de partida para medir las mejoras y progresos durante el proceso de implementación del Lean Manufacturing.

En el área de planificación y ejecución, la fabricación comienza cuando el cliente hace el pedido. Mediante el sistema Kanban de planificación y ejecución, se establece un flujo ordenado y automático de materiales, tanto en lo que se refiere a peticiones y aprovisionamientos como a cantidades, proveedores y lugares de destino, basándose en la demanda actual.

Los proveedores también pueden formar parte del sistema gracias al desarrollo de portales web en los que pueden verificar los niveles de existencias y reponer ellos mismos el material en función de los niveles acordados.

La posibilidad de replicar actividades repetitivas sin necesidad de emitir órdenes de trabajo para cada una de ellas o de establecer líneas de producción independientes para cada trabajo, son otras de las ventajas de este sistema que reduce los tiempos muertos entre cada etapa.

Por último, el sistema Lean incide con especial interés en la reducción de actividades que no aportan valor añadido ”waste”. Básicamente, esta metodología identifica siete tipos de waste:

• Exceso de producción o producción temprana: producir más de lo que el cliente demanda o hacerlo antes de tiempo. Ocupa trabajo y recursos valiosos que se podrían utilizar en responder a la demanda del cliente.
• Retrasos: por falta de planificación, de comunicación o de tardanza en el suministro de materiales, herramientas, información…
• Transportes desde o hacia el lugar del proceso: los materiales se deberían entregar y almacenar en el punto de fabricación, para evitar traslados innecesarios.
• Inventarios: se deben reducir al mínimo ya que suponen un coste financiero y de almacenamiento.
• Procesos: dedicar más esfuerzos de los necesarios en revisiones y actualizaciones; la calidad se debe insertar en todas las fases del proceso de forma que cada una de ellas sea correcta desde el principio.
• Defectos: multiplican los costes y el tiempo de trabajo y consumen una parte importante de los recursos para su solución.
• Desplazamientos: los empleados deben tener a su disposición todas las herramientas y recursos que vayan a necesitar para evitar desplazamientos innecesarios.

Mejoras Operativas

90% reducción de tiempos en el ciclo de trabajo

50% incremento de la productividad

80% reducción del inventario

80% mejora de la calidad final

75% reducción del espacio utilizado

Para eliminar o reducir el waste, existen una serie de técnicas que abarcan todas las áreas funcionales como: análisis de producción de la empresa, análisis de las actividades de valor, sistema de gestión de calidad total, mantenimiento totalmente productivo, análisis Kaizen de costes y fijación de precios, ingeniería y gestión del cambio y gestión de la documentación.

Como se ha visto, la implantación de la metodología Lean implica el compromiso de toda las áreas funcionales de la empresa y supone un cambio de mentalidad basado en la calidad total. Además ayuda a generar una dinámica propia de mejora, por lo que la adaptación a las caracteristicas de cada caso es indispensable. Por todo ello las ideas centrales del pensamiento Lean no incluyen explicitamente una implementación.

Fuente: Principios Lean para una fabricación eficaz. de IFS España

Ahora bien, En el caso puntual de la industria del software la respuesta rápida al cambio es un requisito indispensable. Cuantas veces hemos oido la frase: "¿Pero como, ahora es tan dificil agregar un botón en el formulario?" Haciendo una analogía apresurada con la ingeniería de puentes, ¿cuántos habitantes de una región(clientes) han pedido modificar el puente ya construido para que en vez de que sea de tipo colgante sea en arco. El cliente ve un proyecto de software como algo blando, fácilmente modificable, y sabemos que no siempre es asi. Pero entonces, ¿qué hacemos? Tratamos de persuadir al cliente que la Ingeniería del Software es tan rígida como la Ingenería Civil o buscamos adaptarnos a la flexibidad requerida.

Teniendo en cuenta lo anterior, la industria del software es el contexto ideal para implementar Lean. Toyota y muchas empresas ajenas a la industria del software tuvieron éxito y mejoraron su productivad con su implementación. Si el software se identifica tanto con los principios del Lean, ¿porqué no implementarlo?

El mismo RUP propone cierta flexibidad al cambio. Eso si, exige abundante documentación para poder llevarla a cabo. En un ciclo productivo Lean se analizaria que documentación es útil en la producción y que documentación es pérdida de tiempo y recursos. Aquí es donde entran las metologías ágiles. Si, es verdad, al igual que las religiones, todas se parecen. Pero cada una busca su implementación de la filosofía Lean para maximizar la producción. Noten que ahora hice referencia a Lean como una filosofía y no como una metología. Si se quiere se puede ver a Lean como una especificación de principios y a cada metodología agil como una implementación de Lean que intenta conducir un proyecto por el camino del éxito.

Sin dejar la objetividad de un ideal de fábrica de software productiva y metodológica, quiero abrir el debate y leer sus opiniones.

FileDrop: Drag & Drop de archivos fácil en Java Publicado por Ale Vouilloz , jueves 19 de marzo de 2009 at 12:25, in Etiquetas: Drag, Drop, FileDrop, Java, Swing

Así es como se presenta éste api, sencillo, de dominio público y muy, pero muy útil.

FileDrop no tiene licencia, es de dominio público y tal como se aclara en su web, podemos hacer lo que se nos antoje con el. El zip de descarga contiene además del jar, el archivo FileDrop.java con toda la funcionalidad embebida para que podamos incluírlo en la ruta de paquetes de alguna aplicación propia sin tener dependencias de jar externos.

Para ver cuan fácil es usar el Drag & Drop de archivos en Java con FileDrop, vamos a ir más alla del ejemplo de su web y vamos a hacer un componente que muestre imágenes y acepte archivos de imagenes "dragueados" desde el sistema. Algo similiar se podría hacer con visores PDF, reproductores multimedia, o cualquier funcionalidad relacionada al drag & drop de archivos integrada a una aplicación Java standalone. En éste link puse el código fuente del ejemplo.

Primero implementmos el visor de imágenes como un componente. También es posible implementar el visor de imagenes extendiendo de JPanel, Canvas o un JLabel en lugar de un JComponent.
Luego es necesario definir una clase que maneje la transferencia del objeto a draguear. Para nuestro propositito sólo se soportará transferencia de objetos java.awt.Image.

Y Finalmente, hacemos uso de FileDrop en el método que instancia nuestro visor de imágenes.

Como se aprecia en el ejemplo, en el método FileDroped del listener se espera un array de objetos File, ésto permite manejar múltiples "dropeos" de archivos. Una aplicación útil podría ser la típica lista de reproducción que al dropear múltiples archivos .mp3 en el contenedor Swing reproduzca el elemento [0] y encole el resto en la lista.

Espero que les sirva y cualquier duda, comenten.

FEST Swing: Testing de GUIs Publicado por Ale Vouilloz , viernes 13 de marzo de 2009 at 16:13, in Etiquetas: Fest, junit, Swing, test

FEST Swing no es un festival sobre el estilo musical que hace mover las caderas :D

FEST es el acrónimo de Fixtures for Easy Software Testing y esta compuesto por cuatro módulos, uno de éstos modulos se llama FEST-Swing y su función es la de proporcionar una ayuda para la dificil y tediosa tarea de escribir test para las interfaces gráficas de usuario programadas con el api de java Swing.

FEST Swing se integra perfectamente con TestNG y con JUnit. Además desde una tarea ant es posible generar screenshots de las pantallas que fallaron, util para reportar.

Sin más parafernalia veamos un ejemplo:

dialog.comboBox("domain").select("Users");
dialog.textBox("username").enterText("leia.organa");
dialog.button("login").click();
dialog.optionPane().requireErrorMessage()
            .requireMessage("Please enter your password");

El ejemplo ilustra como testear un dialogo de login y la validación cuando el usuario olvida llenar el campo de texto password.

Aunque su sintaxis es muy intuitiva, en su wiki podrán encontrar una completa documentación de uso.