Software as Utility (aka Software as Service)

Un Poco de Historia

Como casi todos a esta altura ya saben, las primeras computadoras era extremadamente caras, lentas y ocupaban mucho pero mucho espacio. Los operadores (o programadores) las utilizaban moviendo llaves de forma manual.

Primer Hito: El Procesamiento Batch

A medida que, de a poco (y gracias al transistor), las computadoras iban ganando velocidad el tiempo que se insumía entre “ejecuciones” de programas comenzó a tener importancia. Para solucionar este problema, aparece el procesamiento batch: Gran Idea!

Ahora los operadores pueden perforar tarjetas (“offline”; sin acceder a la computadora) y luego dejarlas en espera para que la computadora ejecute el programa inmediatamente después de terminar la ejecución actual. Es decir, desaparece el tiempo muerto entre programas.

La piratería ya no tiene sentido…

Este fin de semana tuve que reinstalar mi notebook. Estaba usando el windows 7 RC, pero dado que tiene fecha de vencimiento y que además tenia una licencia para el windows 7 RTM decidí hacer la migración.

Luego de formatear, instalar el windows 7 y dejar todo correctamente configurado me puse a ver que software necesitaba y, para mi sorpresa, me di cuenta que existía una versión gratuita (y muchas veces hasta open source) para cada necesidad. Si bien no es algo nuevo, es la primera vez que al momento de instalar de cero una maquina no tuve la necesidad de acudir a algún programa comercial (y eso que como dije, estoy dentro de un windows).

Google Wave: Colaboración vs. Cooperación

Está claro que google sabe innovar y este nuevo producto o plataforma lo demuestra. Ideado por la misma gente que implementó Google Earth, nace Google Wave.

Qué es Google Wave?

La mejor forma de describir a Google Wave es como una plataforma para trabajar de forma cooperativa (la forma colaborativa es obsoleta!). Busca reemplazar tecnologías obsoletas (como por ejemplo el email) y unificar todas las cosas que andan dando vuelta en la web (wikis, chat, redes sociales, blogs, etc).

Una técnica de estimación de proyectos basada en Casos de Uso

Si bien el movimiento ágil (tan de moda últimamente) dice claramente que no se debe ni puede estimar un proyecto completo al momento de iniciarlo y que cualquier técnica que intente hacerlo va a terminar mal; no son pocas las veces que se necesita conocer de ante mano la duración estimada del mismo. Hay que tener muy en claro que esta estimación suele ser de mínima (el proyecto no va a tardar nunca menos de esto) pero la duración real puede incrementarse mucho; a menos que sean sumamente estrictos y acotarse a hacer únicamente lo que se escribió dentro de los casos de uso utilizados en la estimación.

A partir de un mail, donde alguien preguntaba como estimar un proyecto; se me ocurrió postear una forma a mi me da resultados aceptables. No tiene conceptos teóricos, es una solución netamente empírica que a mí me funciona (si utiliza algunos conceptos teóricos “blandos”, pero nada más). Algunas ideas están tomadas prestadas del libro “Software Estimation” de Steve McConnell (muy recomendado).

Disclaimer: Desde ya que la estimación y planificación de proyectos es una tarea muy compleja y única. Cada proyecto tiene sus detalles, sus compromisos, sus equipos, tiempos, costos, etc. Cada proyecto es un mundo y como tal, esta técnica que yo utilizo debe ajustarse y modificarse con criterio (y hasta puede no servir). Sea cual sea la técnica final a utilizar, siempre tener cuenta de no cometer errores conocidos.

Terminada ya la introducción pertinente al tema, les comento la técnica:

Notificar cambios de forma sistematica

En los últimos días me surgió la necesidad de notificar a la vista cada vez que ocurrian cambios en el modelo. La solución rápida, aburrida y repetitiva es la de ir a la clase base del modelo y publicar los eventos. Luego ir a cada clase del modelo y en todos los setters agregar el codigo para notificar el cambio.

Haciendo uso de Reflection, delegates anonimos y generics; implementé otra solución que si bien no es super novedosa, me pareció que vale la pena compartir con ustedes.

Jornadas Agiles 2008

Ya se vienen las “Primeras jornadas latinoamericanas sobre metodologías ágiles” en el hotel Bauen. Entre otras cosas, durante las jornadas se dictaran cursos para certificarse como scrum master (al cual estoy inscripto hace rato).

A pesar de no haber participado en la organización, se que se hizo bastante a pulmón y ad-honorem asi que esta bueno ver que no se necesita ser una gran empresa para organizar este tipo de eventos.

Les dejo el link en caso que quieran ver el programa de charlas y anotarse en alguna:Jornadas Agiles 2008

Drop Box – Almacenamiento Remoto

Gracias a la invitacion de un amigo mio, estuve probando DropBox.

DropBox se instala como una carpeta virtual dentro de windows o mac y uno puede copiar archivos como si estuviese trabajando local, pero esto se transmite a un almacenamiento remoto; permitiendo compartir informacion entre distintas ubicaciones de una manera muy facil. La sincronizacion es excelente, no interfiere para nada. Entre otras cosas tambien tiene versionado de documentos y la posibilidad de compartir carpetas.

Les recomiendo que lo miren, funciona muy bien. En la pagina hay videos de demostracion de su uso. La pagina es: http://www.getdropbox.com

Si les interesa me pueden dejar un comentario, con algun email y les envio una invitacion. Por el momento me quedan 5.

RAF 08

Enviada a la lista de arquitectura del MUG, les dejo el link a los videos de la RAF (Regional Architect Forum) 2008.

http://www.arquitectum.org/portal/Publicaciones/Videos/RAF08/tabid/81/Default.aspx (lamentablemente el link no funciona mas)

Estimando con Planning Poker

Planning Poker

Estimar es la tarea más difícil del proceso de desarrollo. Nunca se tiene menos información que al momento de estimar y por otro lado, las decisiones tomadas marcan el futuro del proyecto. Si bien todos sabemos que son estimaciones, usualmente estos números (generados a partir de no conocer el problema) llegan al cliente y vuelven al equipo de desarrollo en forma de deadlines estrictos e inquebrantables. Hace poco, leyendo más que nada sobre la metodología SCRUM, me encontré con un método de estimación llamado “Planning Poker” que parece muy prometedor.

El Remero que podria ser programador

En 1994 se celebro una competición de remo entre dos equipos:

• Uno compuesto por trabajadores de una reconocida empresa argentina
• El otro por sus colegas de una similar japonesa.

Apenas fue dada la orden de partida, los remeros japoneses comenzaron a destacarse. Llegaron a la meta prontamente. El equipo argentino lo hizo una hora después. De regreso a nuestro país, la Dirección se reunió para analizar las causas del desconcertante e imprevisto resultado. Se llego a esta conclusión: En el equipo japonés había un jefe de equipo y diez remeros, mientras que en el argentino había un remero y diez jefes de equipo.