Primera presentación en Red Hat - BRMS

Ayer fue mi primera vez como disertante en una conferencia/charla que organizó Red Hat como parte de los Technology Day, y en este caso le toco al Business Rule Management System (BRMS) o como se conoce en el mundo open source, Drools. Tuve la suerte de que la presentación no la di solo, sino que la di con el gran Gus Yasue, que la tiene más que clara con BRMS y este tipo de eventos, con mucha concurrencia (casi 50 personas) en el Restaurante A222.
Básicamente la agenda fue:

1. Explicar el concepto de un Motor de Reglas
2. Como JBoss BRMS implementa arquitecturalmente la plataforma
   
3. Una demo del ciclo de vida de reglas de como crear, tesear y deployar una regla
4. Beneficios

La audiencia estaba enganchada y tuvo muchas preguntas, y por sobre todo ellos tuve a dos compañeros de lujo en primera fila, Gastón Coco y Santiago Blanco, de APIT.
En fin, fue una muy buena experiencia para romper el hielo y comenzar a representar a Red Hat en eventos de este tipo (aparte de los más pequeños con un cliente en particular), creo que se sacaron fotos e incluso Coco iba a twittear algo, todavía no vi nada, después las subo como así también un video que estoy armando un poco más resumido.

Charla de Cloud en APIT - Gracias Santi!

Esta semana en APIT, el Ing. Santi Cardarelli nos honró con su presencia para contarnos su experiencia en todos los tipos de Cloud, sus beneficios y como integrar las clouds dentro de las empresas.
Obviamente cuando uno lee revistas, noticias y blogs, por lo menos cloud es algo que se escucha muy a menudo y de alguna manera esto hizo que se deje de hablar taaaaanto de SOA (buzzword), la diferencia clave es que por lo menos cloud tiene implementaciones reales y cuando hablamos de SOA siempre fue todo muy teórico, está claro que son dos cosas distintas uno es para integrar (SOA) y el otro es un concepto más de infraestructura (Cloud). En fin, algunas cosas que generaron discusiones durante la charla fueron:
1) Performance. Está claro que cloud está basado arriba de Virtualización, y obviamente puede traer algunos inconvenientes a la hora de esperar cierto tiempo de respuesta ya que todo está corriendo sobre el mismo fierro, ejemplo una aplicación Online (Web) necesita procesar un pedido y hay un Batch de otra aplicación consumiendo muchísimo, como para todo eso es tan transparente es dificil lidiar, obviamente creo que la tecnología está cada vez más cerca de solucionarlo, ya sea migrando procesos de un fierro a otro (más ocioso) de una manera transparente, pero creo que falta un poco.
2) Seguridad. Este es un tema que yo considero importante pero no me preocupa, hace 10 años nadie ponia su tarjeta de crédito en ningún sitio web, ya pasó eso, ahora hay bancos virtuales como Paypal.
3) PaaS como modelo seguro de desarrollo? Es un tema, crear aplicaciones sobre force o GAE es realmente interesan? No terminaría casándome con una empresa y tengo que lidiar de por vida con eso, como les pasó a las empresas con los Mainframes de IBM, por ejemplo. Nose, creo que startups, aplicaciones pequeñas pueden tener un muy buen uso de los PaaS sin tener que contratar a un arquitecto :)
4) Escalabilidad: Este creo que es uno de los puntos fundamentales (posiblemente junto al costo) creo que pensándolo arquitecturalmente tiene mucho peso.
Aca les dejo la presentación que uso Santiago:

Nueva clase de Ruby y RoR en el CAECE

Esta noche, fuimos invitados nuevamente por Santi Cardarelli al CAECE para la materia de Arquitecturas Web, donde vamos a dar una clase de Ruby y Ruby on Rails, la diferencia de la del año pasado es que:

1. Vamos a actualizar las presentaciones (con mejor semántica)
2. Vamos a mechar con Live Coding
3. Vamos (Damian Garcia) a dar Rails 3

Yo nuevamente voy a dar la parte de Ruby, por que es un lenguaje que me maravilló desde un comienzo y vamos a tener mucho live coding, ol objetivo no va a ser enseñar Ruby (no se puede en hora y media) pero si dejar claros los principios y características cualitativas. Acá les dejo la presentación como para que la vean, obviamente acá no van a poder ver la parte la historia que voy a contar ni el código fuente con los ejemplos.

Caracteristicas de Ruby

View more presentations from gbrey.

Tengo diez minutos

... antes de tomar finales, estoy en al buffet de la UTN y quería contarles en que estoy.
Obviamente muchas cosas cambian, pase de ser una familia paqueña a una multitud (de 3 a 4), obviamente cada día estoy más enamorado de mi familia y Mecha tiene mucho que ver en esto, su tranquilidad y organización me dejan disfrutar de todo esto y también poner mucho foco en el trabajo y universidad.
Con respecto a Red Hat, cada día voy poniendome más a tono, visitando clientes, haciendo presentaciones y aprendiendo productos. Actualmente estoy trabajando mucho con:

• BRMS (motor de reglas que viene de Drools)
• Relevando y planificando migraciones de tecnologías y al Application Server empresarial de JBoss (el que tiene soporte)
• Pensando estrategias de disponibilización de información (a gran escala) con grids de datos.

Esto último fue lo más interesante que estuve viendo, sobre todo con este proyecto que les recomiendo a todos de pegarle una mirada, se llama Infinispan, y plantea ir al próximo paso de los repositorios de información distribuidos, escalables, con tolerancia a fallo y extremada performance. Lo que me pareció muy interesante es el concepto de distribuir (y no replicar) datos en diferentes nodos y ganar performance alocando los objetos en los nodos donde más se están usando. En el sitio hay varios ejemplos, videos y la semana pasada DZone sacó una refcard.

En la facu, comenzamos un nuevo cuatrimestre donde seguimos los mismos docentes pero con la presencia de Coco en todas las clases. Esteban Lorenzano está viajando por Europa y demostrando sus conocimientos y pasión por Smalltalk en la ESUG. Pero hay mucha pila y la gente de la catedra es muy grosa, cuatrimestre a cuatrimestre vamos incorporando cosas nuevas (este cuatrimestre vamos a tener temas nuevos de Arquitecturas Móviles, Infraestructura y DB NonSQL).

En fin, fue un post muy cortito pero que de alguna manera resume mis experiencias en el último més.

Si sos macho virtualizá con KVM (Fedora 13)

Eso fue lo que me dijeron acá. Y luego de utilizar varios años VirtualBox, quedé maravillado con las virtudes de KVM. En unos pasos sencillos (y con ayuda del Ing. Hernan Petiti) en unos minutos le levantamos el módulo de KVM al kernel de Fedora 13 e instalé una par de nodos de Red Hat 5.4 para hacer unas pruebas de grids (Infinispan) y clusters.
Esto más o menos lo que hice:
1- Instalar el grupo de packetes de virtualización
#yum group install virtualization
2- Levantar el servicio de libvirtd
#service libvirtd start
3- Verificar que el módulo kvm-intel esté levantadoV
#lsmod | grep kvm

Si dice "kvm XXXXX 1 kvm_intel" está todo bien, sino hay que hacer:

#modprobe kvm_intel

4-Levantar el manager de virutalización que se conecte al Hypervisor y así crear/agregar/correr las máquinas virtuales
#virt-manager

Importante:
En mi Thinkpad T410i, tuve que entrar al BIOS y habilitar las dos opciones de Virtualización del Procesador de Intel.

Actualmente tengo dos máquinas con linux con java y con un directorio compartido por nfs con el Host y un winchot. Las tengo las tres levantadas y realmente no tengo ningún inconveniente, cosa que con VirtualBox me comía la máquina, solo teniendo dos. En fin, en estos días vos a contar un poco las cosas que estoy haciendo con grids de datos, motores de reglas, portales, etc, etc.

Bootcamp de Ventas en Sao Paulo

Esta semana estoy en Sao Paulo participando de un Bootcamp de ventas para todo lo que es el portfolio de productos de Plataformas y Middleware de Redhat. La verdad que es una muy buena experiencia de entender un poco la proposición de valor de la empresa (orientada a subscripciones) y por supuesto lo interesante de compartir experiencias aprendiendo con gente de diferentes áreas (principalmente ventas), roles y países (mexico, brasil y chile). Fue una semana muy dura y paramos por el barrio de Itaim Bibi y tengo el Hotel en diagonal al edificio y donde Red Hat tiene las oficinas. Realmente estoy impresionado por el modelo de negocio, la manera en la cual se está encarando la oferta en LATAM a través de servicios y los productos para infraestructura y Java. El curso es bastante intenso con exámenes todos los días con exposiciones y puntuaciones, por ahora voy 3ro, pero dudo que llegue con el mismo puesto mañana. Acá subí algunas fotos pero seguro voy a sacar un par más:

Chau IBM... Hola Red Hat

En Julio del 2010, fue mi último día en IBM, luego de casi 7 años tomé la decisión de buscar cambiar de empresa. Por que? Bueno, hay varias razones y muchas de ellas tienen que ver con lo que expliqué en mi post anterior (link) y otras más soft. Lo loco es que NO me voy por la plata, todo el mundo sabe que la realidad económica en IBM es patética para muchos y es pero que alguna vez cambie, hay gente muy buena (aunque cada vez menos).
Realmente tenía muchas ganas de pasar a un rol con más client facing y exposición, y Red Hat me ofreció formar parte del grupo de Solution Architects para Latin America, particularmente yo voy a estar focalizado en Argentina para todo lo relacionado con Middleawre, o sea, todos los productos y soluciones en/sobre JBoss.
Antes de irme a Red Hat tuve una oferta dentro de IBM para el area de Software, donde iba a tener un rol similar, pero más techie para un laboratorio, pero digamos que el conjunto de skills técnico no son los que quiero desarrollar y aparte me siento mucho más identificado con el modelo de negocio de Red Hat por que:
el código está abierto
no se vende el software sino soluciones (e2e) y servicios de implementación y soporte de los productos (subscripciones)
red hat prefiere tener pocas personas, pero muy buenas y con experiencia (esto lo iba a tener si aceptaba la oferta en la otra área de IBM) que no es el caso del area de IBM donde yo estaba.

Por otro lado, no estoy entrando a un lugar completamente desconocido, en mi equipo están que ya las conocía, los Ingenieros utenianos de Diego Cicero y Gustavo Yassue, lo cual me da cierta tranquilidad. Y podría decir que en 2 semanas he recibido más

Obviamente fue muy difícil tomar la decisión ya que es volver a empezar y lo más fácil era quedarme en una empresa conocida, con lo bueno y lo malo, y por otro lado se que voy a perder muchas cosas que me fascinaban de IBM, como son las siguientes:
1) Certificación de arquitectura, dejé el package listo y submitido
2) Crecimiento en liderazgo técnico
3) Flexibilidad laboral, IBM es un pionero en esto

En fin, no quiero seguir aburriendo pero no quería dejar de contarles este cambio importante en mi vida profesional y personal ya que cambié de trabajo un Lunes y el Martes fuí papá por segunda vez :)

Que quiero ser cuando sea grande profesionalmente hablando

Definitivamente estoy en crisis (cambio) llegando a los 30, un segundo hijo (luz), all boys en primera y profesionalmente aturdido. Muchas veces dije lo que quiero ser o adonde apunto, y estoy seguro que lo tengo claro, al menos la visión la tengo.
Y no se si lo puedo describir en tan solo una palabra, pero lo más que se le parece es a lo que en IBM, Oracle, Sun, Microsoft llaman Fellow, es un puesto de mucha categoría que se la otorgan a técnicos reconocidos en la industria que poseen un gran liderazgo y han aportado con técnicas, productos o metodologías para la mejora. Y sobre todo poseen una visión del futuro tanto del negocio como de la tecnología.
Obviamente para llegar a eso tengo que crecer muchísimo, vivir nuevas experiencias e involucrarme en otro tipos de actividades que no estoy haciendo actualmente. En mi todo list tengo lo siguiente, se aceptan consejos:
1) Hacer un Doctorado - Esto lo vengo pateando y analizando, definitivamente no quiero hacer un master, considero que investigar y tratar de unir el gap entre lo académico y la industria podría ser muy interesante. Definitivamente la ciencia/academia solo no me interesa por el momento, al menos no en Argentina.
2) Relacionarme más con el negocio (client facing). Participar más en ciclos de venta, pre-venta, entender los diferentes contextos de las empresas y ver como ofrecer soluciones. Realizar consultorías, evaluaciones y recomendaciones en diferentes empresas.
3) Tener un puesto de Arquitecto Empresarial. Este es uno de los objetivos de largo plazo, me interesaría muchísimo formar parte de un equipo de arquitectura empresarial para tomar decisiones de alto nivel y ver como IT puede bajar costos alineándola con el negocio de la manera más ordenada.
4) Enseñar, enseñar, enseñar. Amo la educación, compartir mis conocimientos y ayudar a pensar. Pararte adelante de un grupo de profesionales y transmitir un mensaje tiene un desafío muy grande día a día.. Como siempre digo, los conocimientos van y viene el criterio no.
5) Reconocimiento de la industria a través del aporte. Escribiendo artículos y libros, dando presentaciones, teniendo un blog (bueno, no como este) haciendo networking, contribuyendo en el open source y publicando patentes creo que va a ser la manera en la cual voy a lograr esto.

En fin, vamos a ver como salgo de esta crisis y veo de que manera estoy parado de un tiempo aca. Aclaro que el plan es de acá a 20 años o más, voy a estar ocupado, no?

Buscando la certificación de IT Architect

Como comenté en un post anterior, a principio de año submití un paquete de 40 páginas sobre mi experiencia, conocimientos, skills, educación y otras cosas más para certificar en la carrera de arquitecto en IBM donde tuve que describir mis 10 años de experiencia en IT y con más detalle los últimos 4 años como arquitecto. La primera revisión pasó sin problemas, pero cuando tuve las 3 entrevistas con otros 3 "colegas" no me fue tambien, y terminaron declinando mi certificación. Era esperable, el proceso es muy tedioso y como toda certificación, en algunos aspectos tiene temas muy "fordistas" y "metodológicos" que si no usas los nombres correctos para ciertos elementos te penan muchísimo. En fin, el proceso es bastante transparente y sigo creyendo y es por eso que el més que viene vuelvo a presentarme. Ahora bien, que fue lo que determinaron que no sabia? bueno aca les dejo un detalle:
1) No tengo experiencia aplicando una metodología de diseño para crear arquitecturas.
2) No trabajé con muchos tipos de arquitectuas y plataformas.
3) No conozco los "key trend" de las industrias en las que trabaje.
Estos son tres puntos de veintipico de otros requerimientos. Obviamente estoy de acuerdo con el último punto, el 3, que la verdad no le di ni bola cuando armé mi paquete y ni lo charlé con mi mentor, sabía que ese punto no lo tenia claro.
Con respecto a los otros dos, me sorprendí muchísimo, debido a que en IBM doy cursos explicando la metodología de diseño de arquitectura y a su vez apliqué y conozco otros como Agile Modeling y ADD. Y el 2do punto, tambien de pareció ridículo, pero luego vi que mi paquete no estaba taaaaan claro que tengo experiencia en varias plataformas y tipos de arquitectura (batch, fat client, thin client, 3 tier, client-server), en fin, fue un golpe muy duro cuando recibí el resultado y 2 de los 3 puntos que no pasé eran incorrectos y fallé en la comunicación. Ahora bien, el 2 de Julio arranco el proceso nuevamente con el objetivo de obtener la certificación junto a mi mentor Kenn Roberson que me ayuda, cochea y contiene en mis momentos de catarsis desde Dallas.

Workshop en Raleigh 2010

Durante estas últimas dos semanas estuve nuevamente en el Research Triangle Park, en el estado de North Carolina. El objetivo principalmente es para juntar los responsables del equipo de proyecto (Requerimientos, PM, Arquitectura, Test y Desarrollo) junto con el Cliente para definir las prioridades, arquitectura y plan de trabajo para la segunda parte del año para la aplicación en la cual vengo trabajando hace 2 años y medio.
La verdad que el resultado fue muy productivo creamos, estimamos y planificamos alrededor de 25 user stories. Por otro lado definimos la arquitectura de un nuevo sub-sistema que va a recibir millones de XML por MQ y donde muchos requerimientos de performance, disponibilidad, seguridad y modificabilidad fueron atacados.
Esta vez no tuvimos que hacer muchos ajustes a la metodología y todo fue más rápido, el equipo ya está muy maduro.
Por suerte tuve la posibilidad de seguir más o menos mi dieta y hacer ejercicios a la mañana, corriendo por el RTP, que prácticamente es un bosque con empresas de IT y también de jugar al tenis, esta vez en cancha de cemento y con una raqueta que no era la mia, me dí cuenta que apesto aún más. La verdad que el recorrido matutino (a veces solo y otras acompañado) era bastante lindo.
Generalmente los días fueron parecidos, terminábamos de trabajar a las 18 aprox, de ahi pasábamos por el hotel a dejar las cosas (estaba a 3km de la oficina) y luego íbamos a comer, obviamente cuanto más tiempo podíamos hacer y estirar la hora de comida mejor, pero generalmente terminamos comiendo temprano. Pude volver a comer en lugares geniales de comida norteamericana como Champs, Chilis y Cheesecake Factory. Esta vez no comi en ningún lugar de comida de India. Pero si probé comida Thai, que estuvo bien, y muy buena comida Cajun. En fín, comimos de lo lindo y como siempre probando buenas cervezas, principalmente estuve tomando mucho Blue Moon (con la rodaja de naranja gay) y Samuel Adams.
Despues de comer, generalmente volvíamos al Hotel a jugar al PES2010 en la PS3 o y al Guitar Hero/RockBand en una Wii, teniamos dos TVs en cada habitación, así que podíamos estar todos juntos, jugando, tomando fernet y cerveza.
También durante el finde en el medio que tuvimos, nos fuimos a Kitty Hawk, una ciudad balnearia a 3 horas de donde estábamos linda. Y el domingo estábamos preparados para ver el mal final de Lost, hicimos unos nachos con cheedar, salsa picante y por supuesto buenas cervezas. Digamos que esto último fue lo único interesante.
Cuando Ahora estoy varado en Miami ya que perdí la conexión, así que en 5 minuto salgo para el aeropuerto. (ya llegado a Bs As, actualicé el post por que no tuve tiempo de terminarlo en el lobby del hotel de Miami)

Curso de Arquitecturas de Software

Hace unos meses, junto con dos grandes profesionales (Ing. Gastón Escobar y Ing. Ulises Martins), con los que curse gran parte de mi carrera, nos pusimos de acuerdo para lanzar un curso eLearning sobre Arquitectura de Software, venimos trabajando muy duro y ya estamos a punto de comenzar, los invito a mirar los contenidos y quien quiera anotarse, es muy bienvenido :)

Creo que luego de dar 5 años APIT y trabajar como arquitecto (cada uno de nosotros) en grandes empresas como IBM, Oracle, Accenture e interactuar día a día con otros profesionales en el ambiente académico y web, contamos con una madurez que nos permite abordar un tema tan crítico con propiedad.

Este curso es dictado a través de la Secretaria de Cultura y Extensión Universitaria de la UTN, y tiene un costo. Aca les dejo el link para más información:

Curso de Arquitecturas de Software

Y que hace un líder técnico?

A los largo de mis casi 11 años trabajando en IT, los roles que forman mayor parte de mi CV y que realmente tengo formación, están relacionados como Líder Técnico y Arquitecto. Por un tiempo los hice al mismo tiempo pero finalmente me terminé quedando con el de Arquitecto, que realmente es muy diferentes al de liderazgo, y aunque creo que ambos necesitan skills duros que se pueden formar, creo que los factores fundamental para tener el rol es el sentido común y la pasión por lo que haces, de nada sirve ser un referente sin poder transmitirlo en los aspectos y decisiones del día a día, es algo que no puede ser forzado.
Por otro lado, hay algo que podes hacer como líder que no podes hacer como arquitecto. Para ser arquitecto necesitás calle, experiencia, años de vuelo trabajando en diferentes momentos (en la industria), diferentes metodologías, tecnologías... aunque como líder, para hacerlo bien, tenes que tener la vocación y el don para hacerlo. Cuando uno es un líder natural todo es más simple y no fuerza sus decisiones diarias, le salen naturalmente y busca el bien común, no el propio.
En mi caso particular me costó/cuesta mucho más ser Arquitecto que lo que me costó ser líder técnico, quizá por mi inclinación democrática socialista que me hacer ser transparente y realmente creer en lo importante del equipo y no de las individualidades. Día a día yo me esfuerzo para ser arquitecto, pensando mis decisiones en todo momento del día, capacitándose, dando clases, etc. Pero cuando era líder todo me iba más natural.
Ahora bien, hace unos años debí tomar una decisión en la cual tuve que tomar un camino, si el del liderazgo puro/management o arquitecto (técnico), me costó, pero me fui por el del Arquitecto, ya que siendo líder el techo del crecimiento en lo técnico (por algo soy ingeniero) es muy bajo, rápidamente se convertís en un burócrata siguiendo procesos y donde la creatividad se deja de una lado, cosa que no pasa con el arquitecto, o lo que quiero ser en un futuro (ya voy a hablar en otro post).
En fin, hasta acá vengo aburrido con mi vida que no es ejemplo para nadie, pero más de una vez he recibido la pregunta, y que hace un líder técnico? bueno, aca traté de recopilar las actividades y responsabilidades que yo considero importante para este rol. Con respecto a las responsabilidades:

1. Formar el equipo. Creo que es actividad más importante de un líder es contar con personas capaces de hacer su trabajo y buscar complemente entre las fortalezas y debilidades de cada integrante.
2. Proveer guía y soporte técnica al equipo. No concibo tener un líder que no sepan lo que hacen los integrantes, tampoco creo que el líder debe ser el mejor técnico, pero si debe tener el conocimiento para destrabar y resolver problemas impartiendo prácticas que mejoren la calidad del trabajo. Repito, no debe ser el mejor técnico, pero si de la media para arriba.
3. Estimar, Asignar y planificar tareas. Muchos líderes creen que esto es lo único que tienen que hacer, aparte de controlar que se hagan. Definitivamente creo que esta es una de las tareas menos importantes del líder. Un equipo bien configurado no necesita a un pelmazo que lo único que haga es asignar y controlar. Acá es importante emplear sus conocimientos para poder estimar y tener la grandeza para consultar a sus integrantes y generar comprometimiento de grupo.
4. Coordinar (no controlar) las tareas. Aca hay otro punto escabroso, y es una de las cosas que más odio del liderazgo, el control. Se supone que en software la gente que trabaja es profesional y responsable de su tarea y no debería ser controlada y ser preguntada por el progreso, cualquier desvío que ocurra debería ser notificado en el momento justo para tomar acción. Obviamente no siempre es así, la gente es jodida y no siempre tira a un mismo lado, con lo cual creo hay que ser muy cuidadoso con el punto 1. Acá puedo escribir mucho más, pero no tengo ganas... quizá en otro post :)
   
5. Peer Review. Si bien esto es un tema delicado para los agilistas, yo considero que los peer reviews son necesarios y la frecuencia debería varias de acuerdo al nivel del proyecto con el uso de herramientas de análisis de código. Los beneficios de las revisiones de código o trabajo, son buenas desde muchos puntos de vista, no solo mejorar el deliverable sino transferir conocimiento y buscar consistencia, como arquitecto participo y me gusta mucho.
   
6. Definición de las normas de convivencia. Cada equipo tiene sus normas, reglas y procesos a seguir, el líder debe coordinar las tareas necesarias para generarlo y asegurarse que sea beneficioso para el equipo. Acá entran temas de la organización, y el ecosistema en el que está inmerso el equipo. Un equipo en donde se pueda generar un ambiente sano de aprendizaje constante donde nadie es penado por equivocarse es difícil de lograr, esa armonía es muy importante y no se puede escribir en un wiki con el resto de las reglas. Pero va a depender mucho del líder y los detalles propios del equipo.
   
7. Preocuparse por el crecimiento profesional de los miembros del equipo. Esta es una de las responsabilidades que más me gustaba como líder y donde estoy seguro que di lo mejor de mi por muchos años. Es muy importante como líder saber las aspiraciones de los integrantes del equipo y tratar de unir las actividades diarias con dichas aspiraciones. Obviamente no siempre los integrantes saben sus aspiraciones, con lo cual es importante ayudar a definirla, hablar de visión acá es un poco apresurado, pero importante. Aca también entras técnicas como el coaching, de acuerdo a la urgencia muchas veces es mejor dar la caña de pescar y no el pescado .
   

En fin, estas son las actividades que todo líder técnico tiene que hacer y precuparse por mejorar, los que estén trabajando con dicho rol, los invito a realizar una auto-evaluación y ver que tan bien están en cada uno de los aspectos listados. Por supuesto si tienen otras responsabilidades para agregar, no duden en comentar.

Basta con la mentira de separar el Diseño y Desarrollo

Hace años que pienso lo mismo y digo sin escrupulos, el diseño y la programación lo se pueden separar, dejemos de mentir. Como puede existir un diseñador de objetos que no toque código, imposible, algunos puntos:
1) No voy a discutir del diseño iterativo y el diseño "up-front", luego de 11 años en SW puedo asegurar que el único diseño valido es el evolutivo o iterativo, no existe el otro, y si existe es inválido. No puedo pensar como entener un modelo puede ser sumamemente top-down, quizá me falte inteligencia pero el evolutivo es el único que me sale a mi.
2) TDD, es imposible poder diseñar un software sin dirigirlo por test, ok, si, soy Arquitecto, pero cuando quiero programar algo, lo tengo que dirigir por test, no puedo pensar de otra manera, si separamos el rol del diseñador y el programador, TDD pierde importancia
3) Senior y Juniors: Una de las cosas que impiden el diseño (según muchos) es que un junior no puede diseñar. "Estoy muy en desacuerdo con ello", un junior si puede diseñar, definitivamente, pero problemas pocos complejejos, sencillos. No puedo concerbir la idea de un programador que no diseñe, programar es llevar a cabo el diseño a algo tangible.
4) UML. Ugghhhh, si, me gusta, pero no para dividir dos perfiles. El perfil es el mismo, el desarrollador diseña, SI, lo hace.}

Si están por entrar a una empresa donde esos roles estén separador, digan no!

Clase de Ruby y Rails en la CAECE

El año pasado, con Damian Garcia, fuimos invitados por Santiago Cardarelli a dar una clase de Rails a alumnos de 4to Año del CAECE, para la materia Arquitecturas Web, que dicta Santi. Básicamente dimos una introducción a Ruby y presentamos Rails. Lo interesante de esto es que la segunda parte de la clase, preparamos un Workshop donde los alumnos levantaron una VM (en VirtualBox) con todo el setup de Rails andando y lanzaron crearon una aplicación en rails.
Presentaciones

Ruby para Java Developers

View more presentations from gbrey.

Ruby On Rails Introduction

Workshop
Utilizamos Tuquito Rails

Ruby on Rails Workshop

Pensando arquitecturalmente desde Caracas, Venezuela

Hoy domingo, viajé hacia Lima, luego Venezuela para dar, nuevamente, el curso para Arquitectos (de tres días) en IBM. Estoy escribiendo el post desde el avión, en cuanto llegué al hotel lo pongo. Como todos los viajes, me vi unas pelis y lloré como un tarado... estar lejos de Andrés, y de Mechi (y el/la chancho/a) me pone muy sentimental y cualquier media fuerte me hace quebrar.
Por ahora los viajes vienen muy bien, solo que tuve que correr para agarrar la conexión en Lima, pero bueh BAU.
En fin, voy a estar pocos días, el Miércoles a la tardecita me vuelvo y tengo mucho trabajo como para "disfrutar" o recorrer, el poco tiempo libre que tenga lo voy a usar para quemar algo de grasas, ya sea corriendo o en la bici en el hotel.
Esto es todo por hoy, nada nerd/técnico interesante para contar. Eso si, alguien quiere algo de Venezuela, no duden en avisar, eso si, nada de color rojo ;)

Arquitectura de Software, ciencia? ingenieria? arte? o alquimia?

Siempre es un tema que sale con birras de por medio y nunca llegamos a la conclusión, digamos que:
1. Es ciencia? La verdad que no, sin entrar en detalle en la definición, la arquitectura de software está claramente lejos de la formalización, gracias adiós, jamás podría pensar un modelo formal para manejar las variables que se consideran para crear una arquitectura, y menos que eso poder validarla. Aunque hay ciertos aspectos de la ciencia que si son interesantes y se usan para tomar decisiones, se me ocurren temas de disponibilidad.
2. Es una ingeniería? Aca creo que nos vamos acercando un poco, aunque todavía no creo que el software haya llegado a la ingeniería todavía, siendo ingeniero (de sistemas, no de software) podría decir que nos falta mucha madurez para tener un un método que me permita obtener el mismo resultado (o parecido) y asegurar la completitud de las necesidades. Obviamente esa es la manera conservadora de ver la ingeniería.
3. Es un arte? Aca estamos un poco más cerca, definitivamente... el proceso de creación de arquitectura está más cerca de la creatividad que de los metodos formales de diseño. En que cabeza cabe que el diseño puede ser "formalizado" y definido en un proceso? Está claro que pueden haber guias, experiencias documentadas, ejemplos, maneras de comunicar un diseño, pero ahora tener un proceso (input-X-output) repetitivo en diferentes contextos y situaciones, yo no creo. Ahora tampoco creo que es puramente artístico la creación de la arquitectura, se supone que debemos que elegir la solución más simple, con mayor reuso (assets, patterns, estilos, etc) y restringidos por tiemos y costos, esta ultima parte destruye (felizmente) la fumatina de los arquitectos. Que según Esteban Lorenzano "Arquitecto con tiempo es más peligroso que mono con navaja"

Ahora bien, si bien creo que la arquitectura de software tiene algunos componentes de la ciencia, se podría decir que está muy cerca de la ingeniería y tiene mucho del arte, he llegado a la conclusión que yo a la arquitectura de software encasillaría dentro de lo que es una alquimia, por que? bueno.... algunos puntos:

• La alquimia se basa en algunos aspectos de la ciencia, sobre todo las bases
  
• La experiencia y sabiduría de quien la practica es el elemento fundamental de la alquimia
• Arte, que más decir aca la alquimia definitivamente está muy influenciado por la creatividad y la constante expresión
• El aprendizaje constante de nuevas técnicas
• La búsqueda del resultado/transformación más apropiado
  
• La amplitud recibir y compartir experiencias místicas dentro del proceso

Bueno, este es mi aporte del mes :) opiniones/insultos más que bien recibidos/as