Ya es hora de mirar nuevos horizontes - Beyond Java

En dos semanas tengo planificado, junto con Gonzalo de Pedro y Andrés Calabrese, dar una charla con el objetivo de presentar técnicas y conceptos de programación que están cambiando a la industria del desarrollo de software y que Java, por ser la plataforma de desarrollo indiscutida, le cuesta adoptarlas aunque muchas veces se pueda.
Estaría dirigida a los profesionales que trabajan en java y quieren abrir sus mentes y ver como se están desarrollando el software en otras plataformas para luego traer esas técnicas al mundo java.
En principio los temas que se nos ocurren son los siguientes:

• Continuation
• Open classes
• AOP / Hooks
• Subject Oriented Porgramming
• Duck Typing
• Mix-in
• Clousures
• OOP con Prototipado (Javascript & Self)
• Domain Specific Languages
• Behavior Driven Development
• Conventions over Configuration
• Concurrencia con Earlang
• Behavioral completeness

Un poco la idea es abrirle la cabeza a los desarrolladores Java como para que vean que fuera de la burbuja java (empresarial) existen conceptos muy interesantes que le puede hacer la vida como desarrollador mucho más feliz y como dice DHH más productiva.

Si tienen alguna sugerencia, por favor no duden en comentar.

RadRails 0.9.1 - El Code Assist ya está funcionando

En el post anterior comenté que el Code Assitant del RadRails (Aptana) no estaba funcionando muy bien, bueno, antes de ayer bajé la nueva versión y ahora está funcionando bien, asi hagan el update, pero ojo que es una beta y para hacer el update hay que apuntar a otra URL, por favor lean aca como hacerlo.
Lo que si me dejó de funcionar, pero tenemos que investigarlo un poco más, es el tema de el output de los rSpec que venimos usando para diseño y test. El problema es que el output (a diferencia de xunit) antes lo tiraba a consola dentro del aptaba y ahora me lo tira a una consola de DOS que cuando termina de ejecutar se cierra sola... pero bue ya lo resolveremos.

Bill on Rails... segunda iteración cumplida

Hace un par de meses comencé junto a un grupo de gente de IBM un proyecto relativamente pequeño, que se encargará del manejo de ordenes de compra y seguimiento de facturas emitidas por los proveedores. Obviamente, este proyecto tiene otros dos objetivos:
- Implementar y aprender sobre Ruby on Rail y sobre todo el lenguaje Ruby
- Desarrollar el software de una manera iterativa incremental utilizando metodologías ágiles como Scrum y XP,
Luego de cuatro meses en donde estuvimos investigando, aprendiendo en conjunto y luego comenzando con el desarrollo de la aplicación tuvimos muy buenos resultados y me gustaría comentarle algunas cosas que venimos haciendo:

• Estamos usando Aptana como entorno de desarrollo que posee un plug-in muy copado para desarrollo de aplicaciones RoR llamado RadRails, este fue comprado (o algo por el estilo) por Aptana hace unos meses. Si bien todavía está un poco verde y no tiene mucho code assistance te da una mano bastante grande facilitándote la ejecución de los generators y las tareas rake. Aparte de permitir debug y syntax high-lighting.
• Como base del Aptana tambien estamos usando InstanRails que te instala de una todo el entorno Ruby, MySQL (con phpMyAdmin) y el Apache, en dos clicks tenes el entorno listo para comenzar a programar. No hay que olvidarse que al Aptana hay que apuntar al IntantRails para que tome el interprete Ruby.
• Como herramienta fundamental de comunicación estamos usando el Wiki, tenemos todo centralizado assets, tutoriales, backlog de requerimientos, direcciones de svn, estandares, arquitectura, release plan, build & deploy, etc, etc.
• Todo el manejo de Tareas e Issue tracking estamos usando la fantástica herramienta de Trac que nos permite mantener en un único lugar parte del SCM necesario para llevar a cabo el desarrollo, obviamente integrado con Mylyn y SVN. Realmente es una herramienta muy simple y que tiene todo lo necesario para asignación de tareas y defectos como así también su seguimiento.
  
• No hubo mucha discusión con la decisión de usar SVN para el versionado, es rápido, fácil de configurar, se pone atrás de un apache, lo que permite mantener la autenticación y autorización corporativa y se integra perfectamente con el eclipse y el Trac. En este ultimo punto, le pusimos un hook para no permitir commitear a menos que haya una tarea en estado "working" asociada.
• Uno de los Plug-ins que me está maravillando (gracias Andrés Calabrese) es Mylyn, la verdad que la gente que lo inventó realmente tuvo una idea genial debido a que no solo permite integrar las tareas del trac (o de cualquier issue tracking) en el IDE, sinó que también permite el uso de contextos lo cual aumenta la productividad minimizando la cantidad de información visualizada. Les recomiendo escuchar este podcast de 20 minutos en donde explica brevemente que es Mylyn y como utilizarlo.
• El Build & Deploy automático lo estamos encarando utilizando Capistrano y guiándonos con el nuevo libro de la serie de pragmatic programmers llamado "Deploying Rails Applications". Todavía no tenemos un entorno con Capistrano funcionando pero no falta mucho, cuando cierre voy a postear algo sobre el tema.
• La referencia obligatoria del lenguaje es este libro "Programming Ruby", la primera edición está abierta y es gratuita. No se que hablar mas de Ruby, realmente es un lenguaje que cada día me gusta más. En este post explico por que. Lo único que voy a agregar es que definitivamente antes de tirar líneas en Ruby, les pido por favor que lean, no se les ocurra programar como si estarían en Java.... no van a llegar a nada.
• El framework, Ruby on Rails, que les puedo decir... está muy bien enfocado y acotado a los que quisieron hacer, pequeñas aplicaciones web con bases de datos atrás. Lo único que me resulta un poco flojo es el tema de la concurrencia de migrations, si bien es una excelente idea, si no tenés cuidado se puede armar un con los mapeos a la base de datos, nosotros lo minimizamos tratando de poner un solo encargado para crear las migraciones, les pido que lean por que la idea es muy buena, todavía le falta madurar pero el approach está bueno. Todo lo que es ActiveRecord y AJAX, la verdad que me tengo que sacar el sombrero, Rails lo resuelve de una manera muy elegante, ya voy a hablar del tema.
• En cuanto al Diseño y Unit Test venimos usando técnicas de BDD (Behavior Driven Development) utilizando rSpec y el plug-in para rails de rSpec que realmente está bastante cerradito para lo que es la parte de Modelos (ActiveRecords). Resultó muy práctico e interesante empezar a escribir las especificaciones de los Modelos para empezar y luego a través de los generadores de rSpec para Rails creamos los modelos. Lo único un poco málo es que la documentación es bastante poca y siempre que te topas con un problema hay que arremangarse y tratar de solucionarlo y muchas veces se pierde mucho tiempo, pero bueh... es un costo que estamos asumiendo. Obviamente no solo estoy trabajando en esto, con lo cual cuando vuelvo a Java y a JUnit me quiero pegar un tiro :(
  

Me faltó hablar un poco de la metodología que usamos, pero prefiero terminar aca y escribir en otro post sobre esto ya que hace una semana también estuve involucrado en la definición de una metodología (ágil) para un proyecto un poco más grande y más importante que este :p

Cursos muy buenos de JavaScript en Video

Hace un tiempo, en Yahoo! UI Library: YUI Theater, se publicó un curso muy completo de un lenguaje que me resultó muy interesante, y que muchos piensan que más que un lenguaje es un juguete. En mi humilde opinión, es el gran lenguaje con conceptos increibles. Ya algo escribí luego de la charla de lenguajes prototipados.
Este curso es muy completo y el instructor (Douglas Crockford) lo hace muy llevadero. Yo lo hubiese querido haber hecho 8 años atrás cuando empecé a programar aplicaciones Web y pensaba que JS era un juguete (que equivocado que estaba)
Parte 1

Parte 2

Parte 3

Parte 4


Las diapositivas las pueden bajar de aca

Espero que les guste.

Ruby: un lenguaje muy simpático

En IBM estamos empezando un proyecto en Ruby y la verdad que el lenguaje me está cayendo muy pero muy simpático.
Acá les quiero dejar una presentación muy buena sobre 10 features que tiene el lenguaje. Espero que les guste, también les dejo un resumen:
#10 Convenciones
#9 Todo es un objeto
#8 (Casi) Todo es un mensaje
#7 Ruby es más dinámico de lo que parece (Open clases, reflection, hooks, singleton method, code evaluation, etc)
#6 Ruby es fuertemente tipado pero no estáticamente tipado
#5 No te preocupes por las interfaces (Duck Typing)
#4 Soporta Mix-Ins (Algo parecido a lo que se podría hacer con herencia multiple)
#3 Closures
#2 IR (docs) es tu amigo, IRB (consola interactiva, recomendable) también es otro amigo
#1 Deja de escribir tanto código!
Este es el link
Creo que todos, antes de hablar bien o mal de ruby, deberían saber que posee estas features.

Un camino que lleva a RIA

Luego de 7 meses bastante duros, pudimos llevar a producción la release 2.3 del proyecto que vengo trabajando hace años. La verdad que esta release tuvo un gustito particular, debido a que no solo se agregó mucha funcionalidad, en muy poco tiempo, sino que también tuvimos que implementar nuevas tecnologías para agregar items de usabilidad que impactaron bastante en la arquitectura.
Básicamente el objetivo fue pasar de una aplicación web tradicional a algo más híbrido y más parecido a una RIA (Rich Internet Application).

Voy a tratar de listar un par de prácticas y lecciones aprendidas que tuvimos en esta release:

• Tener bien separado los diferentes concerns del browser, Contenido (HTML), los Estilos (CSS), Eventos(JavaScript) y Comportamientos (JavaScript). Esto ayuda a tener un código más simple, claro y mantenible. Lo que hicimos fue framework en JavaScript que obligó a estructurar un poco más el código javascript, con lo cual cada funcionalidad tenia su archivo/objeto/metodo en donde debía escribirse. Realmente JavaScript me resultó un lenguaje increíble, muy potente...
  
• Como parte del proceso de transformar una Web Tradicional a una RIA, tuvimos que mantener las páginas como están y agregar los items de usabilidad desde allí, o sea, tener un único refresco completo por pagina (cada vez que se va de una página a otra), y mientras el usuario realice transacciones en esa página, recién ahí utilizar AJAX/AHAH para actualizar partes de ella. Es importante destacar que el uso de AJAX y AHAH brinda una gran performance, mejorando la latencia y utilización de recursos, debido a que hay menor transferencia de datos y que la página no se refresca por cada transacción.
• JSON es la mejor manera para intercambiar datos entre el browser y el Server. Todos los delta de página son devueltos en un único objeto JSON con pedacitos de HTML renderizados en el Server. Está claro que JSON es muy superior a XML en este conexto, ya voy a hablar un poco más de esto.
• Una parte interesante fue la modificación que le hicimos al componente de Vista, debido que se componentizaron los renderizadores de HTML, y ahora estos renderers son utilizados tanto para crear el HTML de la página completa como los delta de HTML que viajan a través de JSON.
• El manejo de eventos en el browser tuvo un cambio en el final de la release, empezamos usando Event Handling y terminamos con Event Delegation (con bubbling) lo que mejoró muchísimo la performance. En este link se explica muy bien la diferencia.
  
• Ni Client Pulling, ni Server Pushing son la mejor solución. Luego de implementar un Indicador de Progreso para transacciones largas, llegamos a la conclusión que las actualizaciones del Server al Browser (Reverse AJAX) debe ser una solución intermedia entre los dos enfoques, ya que esto evita muchos problemas de performance y concurrencia.
• YUI Yahoo es una librería de JavaScript increíble ya que posee muchísimos widgets y componentes configurables, como los Menus, Paneles (eliminamos los malditos popups), Connections, etc Pero sobre todo nos permitió lidiar con el cross browser compatibility.
• Firebug rocks!
  

Obviamente nos faltaron muchas cosas por mejorar y hacer:

• Armar un buen entorno de Unit Test de JavaScript, estuve probando JSUnit, pero no lo pudimos institucionalizar :(
  
• Realizar inclusiones de JS dinámicamente
• Tener un mapeo de Evento<->Comportamiento más declarativo en JS que permita reutilizar más comportamientos o behavior, creo que estamos bastante bien, pero todavía necesitamos más trabajo.
• No pudimos resolver, por falta de tiempo, como enviar solo la información que cambió en el formulario del browser.
  
• El HTML de la aplicación todavía es muy muy feo, hay que trabajar más en este tema para poder tener el contenido mejor representado.
• No pudimos incluir el Spring Webflow, lo que nos hubiese permitido tener una aplicación con flujos mejor definidos y un modelo más stateful en el server.
  

Espero que les sirva esta experiencia que ganamos, calculo que en algún momento explotaré cada uno de los puntos planteados y daré más detalles... probablemente en algún articulo y mejor redactado.

Web Semántica - Seminario Athenas - 21 de Agosto

La agenda es la siguiente:
19:00 hs: Presentación.
19:05 hs: Grandes personajes de la historia: Tim Berners-Lee.
19:20 hs: Cómo funciona internet hoy
19:35 hs: Qué es la web semántica (metadatos, XML y RDF)
20:15 hs: Coffee break.
20:30 hs: Qué es una ontología y para qué sirve
20:45 hs: Ejemplos de OWL
20:55 hs: Cómo integramos todo esto: webservices
21:10 hs: Cómo funcionará internet mañana.
21:30 hs: Cierre

Hace un tiempo que vengo tratando de seguir el tema, escuché un podcast de Tim Berners-Lee, en el cual dijo que el actualmente está trabajando en esto y tambien escuché un par de comentarios de compañeros de trabajo como Fernando Sanabria y Gona, aunque todavía no lo pude conceptualizar. Creo que va a ser muy interesante.

5 puntos débiles que se le podrían encontrar a YUI Yahoo!

En IBM venimos trabajando hace un par de meses transformando nuestra aplicación Web Tradicional en algo más "RIA Oriented" y la verdad que fue un trabajo duro pero que viene resultando muy pero muy interesante, todavía estamos en el medio del testing y refactoring pero ya puedo decir que realmente es posible enriquecer una aplicación web con JavaScript, AJAX y CSS y sobre todo utilizando un excelente toolkit como YUI, ya que es una herramienta excelente, con mucha documentación, con una madurez y soporte increíble... podría estar escribiendo 5.000 líneas de lo bueno que YUI es y no creo que tenga mucho sentido, me parece que lo mejor en estos casos es buscar los puntos flojos para poder solucionarlos, y bueno, aquí van:

1. El excelente componente Connection Manager carece de llamadas sincrónicas (bloqueantes) y esto es más por un capricho del autor que por otra cosa (en mi humilde opinión). Está claro que no son tan importantes pero no cuesta nada dejar la posibilidad.
2. Todavía no tienen una solución para almacenar información del lado del browser y asi permitir construir aplicaciones RIA offline. Creo que este es un tema que hay que tener algo en cuenta ya otras tools como Dojo están un poco adelante.
3. Los componente son un poco duros para extender, si bien son bastante configurables muchas veces es necesario dejar puntos de extensión sencillos para poder agregar funcionalidad que todavía no traen. Alguno puede decir que JavaScript es un lenguaje prototipado que te permite extender y modificar el comportamiento en tiempo de ejecución y es verdad, pero muchas veces eso no es muy simple te hacer. Aca se puede hablar mucho más pero estoy con un poco de sueño :)
   
4. No provee una implementación para hacer Server Pushing o Comet y esto es algo bastante interesante a tener en cuenta. Justamente estas semanas estamos trabajando en esto pero estamos concentrados en el modelo de threads que hay que tener en el server poder enviar info al browser sin que el browser la pida. Actualmente estamos resolviendo el esto teniendo un client polling con una única conexión ajax por vez y con un time out relativamente largo (de 4 a 5 segundos aprox) como para que venga siempre con info del server.
5. Le faltan utilidades sencillas para manejo de JavaScript como tiene Prototype y JQuery, realmente es invaluable poder acceder a elementos del DOM utilizando el $, o agregar estilos de manera muy sencilla y obviamente sin perder portabilidad.

Antes de cerrar quiero destacar dos puntos importantes:

• esto es una critica totalmente constructiva a YUI desde mi humilde opinión. Vuelvo a repetir que de las herramientas que vi, y me recomendaron, es la que más documentación, soporte y madurez tiene.
• muchos de estos puntos débiles que he encontrado a YUI principalmente vienen por el lado de la integridad conceptual que quisimos lograr armando el framework en JavaScript ya que en un momento estábamos usando 3 tools diferentes y no era muy lógico. Actualmente estamos usando YUI y Prototype, pero calculo que próximamente la saquemos o pongamos JQuery que es un poco más liviana y hace cosas parecidas.

Esto es todo...

De paseo por Tandil

La semana pasada nos vinimos con mi familia a MDQ por unos 10 días y el Viernes pasado decidimos ir a Tandil , por un lado a pasear (ya que está a 165 KM de aca) y por otro lado a visitar y cenar con mis 5 compañeros de IBM que están estudiando en la UNICEN y trabajan desde Tandil ya que IBM nos regaló una cena a todo el proyecto (31 personas) y la gente de Tandil por no estar en Bs As no pudo asistir, asi que fui allá a replicarla. Aca están algunas de las fotos que sacamos:

Y luego de haber disfrutado de tandil estas son las actividades que hicimos y recomiendo hacer:

• Comer una picada en "Epocas de Quesos"
• Comprar fiambres para llevar en Syquet (Para la gente de IBM, Bs As... lo prometido es deuda)
• Cenar en Antares (Fue ahi donde comimos con la gente de IBM Tandil)
  
• Hacer todos los recorridos de Sierras (centinela, reserva del tigre, piedra movediza, etc) y Lagos (dique)
  
• La verdad que la ruta MDQ-Tandil es bellisima

Muchas gracias a Esteban Storch que me guió y me recomendó los lugares que arriba describí.

Comentario: How to spot the dreaded non-coding architect

Me encantó este post... sore todo me recuerda hace un par de años cuando el termino de Arquitecto se estaba poniendo de moda y todo se hacia en java y los "arquitectos" lo unico que hacien eran leer ariculos de SUN y Patrones.
Igualmente quiero hacer una salvedad.. si bien se puden detectar estos dos tipos de arquitectos, pero que nadie se olvide de la tercera categoría de arquitectos.... que esos si son los peores que ni se gastan en leer ni estandares, patrones,
buenas practicas.

Este es el link: http://softarc.blogspot.com/2007/06/how-to-spot-dreaded-non-coding.html

Resumen: (Could this be flamebait - probably! But here goes anyway)

By Architect here I'm not talking Enterprise level folk who pretty much don't cod

Aplicaciones RIA con JavaScript offline - Indignado

En estas ultimas semanas estuve un poco ocupado con el proyecto con el que vengo trabajando hace años en IBM, ya vo y a hablar un poco de todo lo que estamos haciendo con JavaScripts, AJAX, AHAH, JSON y CSS....
En este post solo quiero expresar mi indignación de como parece cierta parte de la industria (google con google gears, mozilla con firefox 3, etc) esta encarando el manejo de aplicaciones RIA con JavaScript para que puedan funcionar sin conexión a internet, debido a que apuntan a tener una base de datos RELACIONAL!!!! en el browser, nada más no nada menos... Mi humilde opinión es la siguiente
"Si ya tenemos nuestros objetos en un lenguaje potente como JavaScript (OO y Prototipado) por que no persistimos o mantenemos dichos objetos, para que meter una RDBMS en el browser?? Para que SQL??"
Estas son mis razones:

1. La gente se olvida de los problemas de transformar objetos en tablas y viceversa?
   
2. Estamos en el browser, o sea, vamos a tener como todo, objetos que solo tienen comportamiento y objetos que tienen estado y comportamiento, y objetos que solo van a tener estado, ese estado que estamos persistiendo va a terminar en otro modelos de objetos, como es el DOM, para que necesito pasar por SQL y Tablas? No nos alcanza con objetos??
3. Se olvidan de los problemas de performance ? o sea, una nueva capa en el browser que nos abstraiga de la persistencia de datos, ejemplo Google Gears, vamos a tener más comportamiento, más interacciones, más transformaciones de datos, más uso de memoria, con que sentido??? Ya están diciendo que Google Gears likea mal, te cuelga todo...
   
4. Se olvidan de los problemas de modificabilidad que esto trae? Ejemplo, se agrega un campo más a un formulario, lo cual implica, cambiar como mínimo 5 lugares entre el html, el javascritp, la validación, el objeto, la tabla, el sql, y sigo contando
5. La gente se da cuenta que van a tener que empezar a mantener dos bases de datos como mínimo? Las migraciones? Que onda los upgrades? Me parce que estamos equivocando el camino.
6. En Java, todo está apuntando a la transparencia, en donde todo debería ser más "simple", llegar a un nivel en el cual ni tengas que hacer un objeto.save(), por que en JavaScript tenemos que volver a conceptos arcaicos...
7. La gente se olvida que meter un modelo relacional en el browser obliga a perder las abstracciones que ya se pueden modelar con objetos en JavaScript, que pasa con el polimorfismo?? la herencia?, la posibilidad de agregar comportamiento de manera dinámica? Nos están obligando a separar los datos del comportamiento otra vez, pero esta vez sin ninguna razón
   
8. Que va a pasar con los tipos?? JavaScript no es Java, quizá se mas facil guardando todo en string, aunque no lo se, la transformación siempre cuesta y en este caso vamos a tener que definir mas cosas

Seguramente hay más razones, pero tengo que entrar en una reunión y tengo que cortar aca...
Espero que la gente no caiga en estoy y haya aprendido la lección del problema que tenemos hoy en día en el server para integrar un modelo objetos con un modelo relacional...

Igualmente voy a investigar un poco más, debe haber alguna librería javascript que nos permita algo más transparente sin tener que usar SQL, creo que dojo offline está apuntando por ese lado, y con independencia de método de persistencia.

Metodologías Agiles - Seminario Athenas - 25 de Junio

Abstract
Luego de 30 años desarrollando software, la industria sigue teniendo muchos problemas para terminar los proyectos en tiempo y forma. Durante ese tiempo evolucionaron tanto las tecnologías que utilizamos como los tipos de sistemas que construimos, sin embargo las metodologías parecen no haber sufrido grandes modificaciones. Con esa perspectiva, a partir de finales de los '90 surgieron algunas ideas que proponen renovar la forma en que construimos software y hoy comienzan a popularizarse a nivel mundial.
El objetivo de este seminario es introducir los conceptos que guían estas nuevas metodologías "ágiles", haciendo foco en dos de sus representantes más reconocidos: eXtreme Programming y Scrum.

La agenda es la siguiente:
19:00 hs: Presentación.
19:05 hs: Grandes personajes de la historia: Donald Knuth.
19:20 hs: Teoría e historia de las metodologías ágiles.
20:00 hs: Coffee break.
20:10 hs: eXtreme Programming. Conceptos y casos exitosos.
20:50 hs: Scrum. Conceptos y casos exitosos.
21:30 hs: Conclusiones y cierre

Video cómico de RoR vs Java

APIT en el SEI!

La semana pasada tuvimos un intercambio de mails con Paul Clements y uno de los primeros resultados de esto fue incluir, en la lista de (http://www.sei.cmu.edu/architecture/educators.html) Universidades que enseñan Arquitectura de Software, nuestra materia (APIT).

El segundo resultado estará por venir, pero les puedo adelantar que Paul se encontró interesado en el contenido de una de nuestras clases, la de "Rol del Arquitecto de Software", si bien el 40% del material no es nuestro el resto si lo es, por lo tanto creo que puede haber mucho fruto en el futuro.

Andres tuvo su primer encuentro nerd en APIT

Como todos los martes, nos juntamos con la gente de APIT, a discutir sobre las próximas clases. Ayer eramos pocos, así que lo llevé al chancho para que escuche y vaya aprendiendo de arquitectura de software. Así que para que vayan viendo, la calidad que van a tener las clases y presentaciones con la ayuda de Andrés, aca pueden bajarlas:

• Estilos Arquitectónicos (Garlan & Shawn)
• Tácticas para lograr atributos de calidad

La verdad que se portó muy bien, eso sí, cuando vino la picada, se desesperó y tuve que abrirle un danonino que se devoró y quedó pipon por un buen rato.

Al que posteo esto lo mataría - Diferencias entre C++/Java/C#

Los que me conocen, saben que el detalle extremo de las cosas me rompe un poco. Y este tipo de post me ponen frenetico por que nunca voy a saber la respuesta a menos que alguien me la diga.

http://www.bloggingaboutjava.org/cms/wordpress/2007/04/differences-between-c-java-and-c/

Ahora bien, ganas algo sabiendo dicha diferencia???, si igualmente tenes que tener el test case para verificar el comportamiento.

Hoy empiezan los seminarios athenas 2007 con un disertante de lujo

Venia notando hace tiempo que al seminario athena le estaba faltando un poquito más de difusión, por lo tanto doy mi granito de arena para que se conozca un poco más esta iniciativa que tuvo en estos últimos meses excelentes charlas y este año están planificadas muchas más.
Hoy arranca con Luciano Bello, alias "el taliban del software libre", sobrenombre puesto por Flavio Fernandez (alto groso del labsistemas también), la descripción de la charla la pueden encontrar acá.

Quilmes Rock 2007 en vivo por Internet

Está todo el mundo al tanto que el sitio 10Musica.com está transmitiendo el Quilmes Rock 2007 en vivo??? Ya lo habían hecho el año pasado con el Pepsi. La calidad de video y sonido no es del todo mala. Bueno, era eso, espero que puedan disfrutar de lo que queda, si lo leen antes de las 22, van a poder ver a los piojos ;)
http://www.10musica.com/micro_site/quilmesrock/home/envivo.php?idxBanda=0

El traspié de un grande - Almirante Irizar

En mi país todos los días se escuchan malas noticias que me hacen poner algo mal, pero hacer mucho que no me pasaba lo que me pasó cuando me enteré lo que pasó con el emblemático Almirante Julian Irizar. Desde que me enseñaron sobre este grande, en la secundaria, me generaba mucha espectativa poder verlo en acción, pero el día que lo vi anclado en el puerto de Bs. As. esos metros de largo y algo me dejaron con la boca abierta y con un orgullo de que mi pais pudiera contar con un rompehielos de esta envergadura para la expediciones a la antartida. Recuerdo que estuve con un amigo más de media hora observándolo e imaginándolo en acción.
Realmente espero que pueda ser remolcado y reparado para que siga permitiendo a mi país el uso de este emblemático rompehielos.

APIT - Primer Cuatrimestre 2007

Mañana, Jueves 22 de Marzo, empieza el primer cuatrimestre del 2007, no tengo idea cuanta gente se habrá anotado pero por lo que me vienen comentando hay varios, espero que así sea, cuanta más gente haya en el curso más divertido se pone.
Con respecto al programa, finalmente, hicimos una mezcla entre las supuestas dos materias y quedó algo como esto:

1-Metodologías Iterativas de Desarrollo

• Introducción a las metodologías orientadas a Iteraciones
• Metodologías Ágiles de Desarrollo
• Buenas prácticas para el desarrollo de software y la Arquitectura

2-Arquitectura de Software

• Concepto de Arquitectura de Software
• Tipos de Arquitectura y Ciclos de Generación de Arquitecturas
• Modelado y Vistas de Arquitecturas
• Principios de Arquitectura
• Requerimientos Funcionales, Restricciones y No Funcionales.
• Análisis de Atributos de Calidad y QAW (Método del SEI)
• Influencias de la Arquitectura
• Primera solución técnica y primera percepción de la arquitectura.

3-Creación de Arquitecturas de Software

• Tácticas para la lograr los Atributos de Calidad
• Estilos Arquitectónicos y Patrones de Arquitectura (POSA)
• Método de Creación de Arquitecturas ADD (Método del SEI)
• Organización de la Lógica de Negocio (Arquitectura no Intrusiva, Domain Driven Design, Transaction Script, Workflows, Aspectos y Declaratividad)
• Presentación (Tipos de Dispositivos y Clientes, Control y Navegabilidad, Integración con el Dominio o Lógica de Negocio, Clientes Pesados, Clientes Livianos – Web y Rich Internet Application)
• Persistencia (Mecanismos de Persistencia, Archivos, Base de Datos, Base de Objetos, Prevalencia, Frameworks de Persistencia y Impedance Mismatch)
• Integración (Business Integration, Point-to-Point, EAI, SOA, Colas, Web Services, ESB, Coreografia de Procesos)

4-Comunicación de la Arquitectura

• Concepto de Comunicación y Entendimiento de Arquitectura
• StakeHolders y Preocupaciones. ViewPoints, Views y Modelos IEEE 1470
• Workproducts y Deliverables de la Arquitectura
• Frameworks y Roadmap de Arquitecturas (Model View 4.1, The Open Group Architecture Framework)
• Armado del SAD
• Características de la documentación de la Arquitectura

5-Evaluación y Viabilidad de Arquitecturas

• En que consiste la evaluación
• Cuando y Por que.
• Riesgos
• Costos y Beneficios
• Métodos de Evaluación de Arquitecturas, ATAM (Método del SEI)

6-Implementación de Arquitectura y Rol del Arquitecto de Software

• Responsabilidades del Arquitecto.
• Rasgos y Características del Arquitecto
• Liderazgo y Mentoring
• Responsabilidades y Aseguramiento de la calidad del Arquitecto
• Propuesta de Solución y Evaluación Técnica incluyendo Estimaciones y Métricas
• Procesos de Construcción de Software
• Mantenimiento de Software.
• SCM

Como pueden ver, al programa es más o menos lo mismo que venimos dando, excepto que :
- sacamos un par de temas de metodologías, solo vamos a dar metodologías iterativas y ágiles
- agregamos el QAW, en la intro a Arquitectura, una manera muy interesante para relevar y priorizar los Atributos de Calidad
- vamos a dar el método del SEI, ADD (Architecture Driven Desing) como para guiar la creación de la arquitectura, voy a ver de invitar a alguien con experiencia utilizando dicho método.
- sacamos la clase de Arquitectura de Seguridad, debido a que vamos a hablar de seguridad como algo ortogonal a lo largo de toda la materia.
- Agregamos SCM
Con respecto a los integrantes de la cátedra, hemos perdido a una mente celebre como Hernan Liendo, ya que va a dedicarle a full a TADP y no va a poder dedicarle tiempo a APIT, por otro lado hemos un posible nuevo ingreso de Leo Gassman, de TADP, fue alumno en el 2005 cuando empezamos.
Con respecto a los TP, seguimos manteniendo el Paper, una investigación, y el TP Cuatrimestral en donde el grupo debe crear a implementar en código una arquitectura.
Para quien esté interesado de participar de oyente, vamos a dar clases todos los jueves en Medrano, pueden ver el calendario en el siguiente link, ahí lo vamos a tener actualizado.
Estoy muy contento debido a que en dos años de la materia ya nos estamos sintiendo cómodos en como va quedando y siento que estamos cumpliendo los objetivos que tuvimos cuando empezamos. Está claro que mucho tuvo que ver la incorporación grandes mentes como Nicolas Passerini, Gastón Coco, Juan Arias y Hernan Liendo.