viernes, diciembre 28, 2007

Buen Desarrollador != Buen Consultor != Buen Bombero (resolutor de problemas)

En los últimos meses he estado involucrado en varios proyectos de revisión de código y aplicaciones. Este tipo de proeyctos me resultan muy entretenidos por el análisis que se debe realizar la necesidad de aplicar ingeniería reversa no solo al código sino al razonamiento asociado al mismo, pero ese no es el punto de este post.

Como parte de los proyectos pude trabajar con muchas personas distintas en un mismo tipo de entorno y esto me hizo recuerdo de las grandes diferencias entre tes términos que muchas veces son mezclados por razones erróneas, el desarrollador, el consultor y el resolutor de problemas.

En uno de los proyectos que hicimos trabajamos con un muy buen desarrollador un persona queera muy buena dise;ando y escribiendo aplicaciones, un amplio manejo de patrones, TDD, herramientas de ciclo de vida, en fin una persona que sería invaluable en cualquier equipo de desarrollo de aplicaciones o productos. Sin embargo, esta persona no tenía los skills para ser un buen consultor o revisor. Como consultor le faltaba la capacidad de presentar y exponer sus resultados de administrar los tiempos de avance y manejar la presión y riesgos de una situación complicada.

Ahora en otro proyecto teníamos un buen consultor. Alguien que podía integrarse en un equipo rapidamente podía transmitir sus hallazgos, medir el impacto de cambios y desarrollos más allá del código. Analizar riesgos y oportunidades de manero coordinada, en fin un buen consultor y además era un buen desarrollador pero aún así no era un buen resolutor ¿porque? porque no supo desenvolverse en un escenario que no era el suyo controlado. Es decir al ver código de otras personas tuvo problemas en entenderlo, asimilarlo y simplemente se perdió en el entorno donde alguien más con otros criterios desarrollo la solución y terminó frustrandose.

También en estos proyectos tuvimos la suerte de contar con buenos revisores gente que no solo supo entender rapidamente lo que el código hacía sino ademas el razonamiento detrás de la escritura de ese código y las potenciales áreas de falla. Estas personas además supieron construirse un entorno de pruebas, confirmar sus hipótesis de áreas de mejora, pudieron emitir recomendaciones e implementarlas. En fin este perfil se siente mucho más cómodo en entornos desconocidos y donde la documentación e información es escasa y no clara

Es importante que cada uno sepa cual de estos perfiles le sienta mejor para poder explotarlo al máximo

martes, noviembre 27, 2007

Programación Ágil

Una de las razones más importantes por las cuales Dilbert se mantiene en el corazón de los profesionales de TI es que muchas veces pone en palabras lo que muchos pensamos. Últimamente hay una explosión de uso de metodología ágil y hay también una explosión de gente que bajo el título de metodología ágil se quita de encima todas las cosas que no quieren hacer.

En fin creo que este comic del día de ayer que lo refleja mejor.

Pueden ver más historias de Dilbert en http://www.dilbert.com y suscribirse para recibir en su correo la historieta del día

lunes, octubre 29, 2007

Otro empleado más de Microsoft trabajando en Open Source

Hace ya un tiempo escribí una cuantas líneas con relación a SubSonic y ActionPack lo interesante que me parecia. En los últimos meses Rob Conery, la mente detrás de SubSonic, ha estado escribiendo mucho sobre el futuro de SubSonic dado que LINQ cumple con muchas de las necesidades que SubSonic pretendía cubrir y en ese análisis Rob empezó a ampliar su visión para incluir todo el modelo MVC que tanto admira de Ruby on Rails.

Es así que el viernes publicó un mensaje que no es sorpresivo para la gran mayoría. Rob se une al equipo de ASP.Net para trabajar en proyectos Open Source y de comunidad relacionados con el nuevo framework MVC de ASP.Net. Al mismo tiempo Rob seguirá manteniendo y encargandose de la evolución del SubSonic, que seguirá siendo un proyecto Open Source, así que asegurandose de llevarlo al mejor nivel.

SIn duda creo que fue una muy buena decisión del equipo de ScottGu y sin duda ya nos enteraremos de muchas cosas interesantes que vendrán de la mano del equipo Rails MVC que se está formando dentro del equipo de ASP.Net.

¡Felicitaciones a Rob y al equipo de ASP.Net!

sábado, octubre 27, 2007

Virtualización y MinWin

Eric Traut es el Distinguished Engineer a cargo del desarrollo del core de virtualización en Microsoft. Hace un tiempo (no conozco la fecha exacta) dió una charla en una universidad. La charla esta focalizada en hipervisores y la arquitectura del hipervisor de Windows Server 2008. Es una charla muy buena que permite entender en términos generales los aspectos y razones de la virtualización y en particular de hipervisores vale la pena.

Ah, un bonus esta sobre el final de la charla en la que Eric Traut menciona la existencia de MinWin una versión minimalista del core de Windows que sería el corazón de Windows 7, el sucesor de Vista. Obviamente este kernel no tiene interfaz gráfica y esta limitado a lo escencial peso 25 MB y solo contiene 100 archivos, gran avance frente a Windows Core ¿verdad? Si solo les interesa ver MinWin en acción el video resumido esta a continuación

Via: Mary Jo Foley y su blog

PD: me pareció interesante combinar youtube y soapbox :)

F# y Visual Studio

F# es un lenguaje funcional tipado que esta basado en OCaml y ha sido adecuado para ser eficiente en plataforma .Net. F# fue creado hace 2 años por un equipo de investigadores de Microsoft en Cambridge y ha tenido mucha receptividad en el mundo de los lenguajes funcionales. A decir verdad, F# es utilizado en el mundo "real" por el equipo de XBox Live con buenos resultados.

F# ha ganado mucha visibilidad con algunos desarrolladores del equipo de Visual Studio y finalmente hace una semana S. Somasegar, el VP de la división de productos para desarrolladores, anunció la creación de un equipo mixto entre desarrolladores de visual studio y el equipo de investigación para llevar adelante la integración y evolución de F# .

Esta noticia es muy interesante pues complementa la visión de .Net como una plataforma para todos los desarrolladores y los lenguajes de su preferencia: lenguajes fuertemente tipados orientados a objetos (C#, VB.Net, Delphi, boo), lenguajes dinámicos (IronPython, IronRuby, JavaScript, VB, Iron*) y ahora lenguajes funcionales (F#).

Esto me plantea una gran disyuntiva respecto a cual sería mi lenguaje de hobby. Hasta ahora nunca dude que fuera C# pero dado que este lenguaje ya es mi herramienta de trabajo creo que debería buscar otra alternativa para mantener la cabeza abierta, mi primera opción era sin dudarlo IronPython pero ahora se me plantea  la duda de F#. .

¿Por qué? los lenguajes dinámicos estan de moda pero no me son ajenos sin embargo no tengo ninguna experiencia con lenguajes funcionales y este es un reto interesante. En fin lo maravilloso de todo esto es que puedes elegir.

Para mas información en F# pueden recurrir a los siguientes recursos:

martes, octubre 16, 2007

Licencias Microsoft son Open Source

La OSI (Open Source Initiative) ha dado por aprobadas las dos licencias que Microsoft presentó hace unos meses. Las mismas en una primera instancia fueron observadas por los términos y poca claridad de las mismas luego de una revisión y adaptación de las mismas por parte de Microsoft el viernes pasado fueron oficialmente aprobadas.

Para conocer el texto de las dos licencias pueden ingresar al sitio de OSI:

Es muy interesante este anuncio porque con esta aprobación productos como IronPython y IronRuby son certificados por la comunidad Open Source como Codigo Libre. ¡Cooool!

Notas de un fin de semana largo

Este fin de semana largo tuve tiempo de revisar varios blogs y webear en general así que hago un resumen de cosas interesantes que pasaron entre el viernes y hoy:

  1. Oracle - BEA: La compra de BEA es un movimiento que se veía venir tarde a temprano y Oracle es tan solo el actor circunstancial. Lo interesante de este movimiento es que si se completa (que dudo que no sea así) Oracle tendría aproximadamente un 40% del mercado de App Servers frente al 24% de JBoss, hasta ahora el lider. En este análisis no voy a entrar en detalle porque es relativamente complejo pero si alguien esta interesado recomiendo leer los posts que estoy leyendo o simplemente entrar al blog de Marc Fleury y leer sus posts de análisis que son muy buenos.
  2. Beta de Net60: Net60 es una implementación de .Net CF para el sistema operativo de Symbian. Esta es una gran noticia para los desarrolladores de aplicaciones móbiles con .Net porque al ser Symbian el gran dueño del mercado de sistemas operativos de celulares esta oferta incrementa mucho el alcance de las soluciones desarrolladas. Por ahora no me queda claro el modelo de comercialización de RedFiveLabs y su implementación es compatible solo con la versión 1.0 de CF pero es definitivamente algo para tener en el radar.
  3. Microsoft's Big Mac Sales: El jueves en el almuerzo comentabamos con mi jefe todo el mercado para la venta de Windwos a usuarios de MacBook y como mucha gente estaba comprando Mac para instalar Windows. Después me enteré que Microsoft Watch publicó un artículo al respecto. Algunos número que quiero destacar: 20% de las ventas de retail de office son de la versión Mac, se estima que el 10% de las ventas de Vista en Retail son para usuarios de Mac. Si bien hay que aclarar que el mercado de Retail no es el ingreso principal de Microsoft no deja de ser un número muy importante y confirma que cada vez más usuarios de Microsoft serán también usuarios de Mac.
  4. MSDN Magazine: La edición de noviembre del MSDN Magazine ya esta línea y puede ser accedida en http://msdn.microsoft.com/msdnmag/issues/07/11/default.aspx. EL l foco de los artículos de este mes es seguridad y recomiendo mucho el artículo de code reviews claro que para mí un mejor nombre sería security code reviews, en fin no tenemos porque estar todos de acuerdo en todo :).

November 2007 MSDN Magazine cover

lunes, octubre 08, 2007

Proyecto personal

Hace unas semanas que trato de definir que emprenderé como proyecto personal para poder dedicarme a escrbir código. Obviamente este proyecto debería estar en un área de interés mio, es decir: Performance o Servicios. Hablando más en términos de tecnología: WCF, BizTalk o Revisión de código .Net orientada a performance.

Con esas bases se me han venido un par de ideas a la cabeza y por ahora tengo un par de alternativas que parecen acentuarse cada vez más:

  • WCF.FI: FastInfoset (en wikipedia)es una especificación que viene del mundo Java para la serialización binaria de un Infoset XML. Esta serialización esta basada en ASN.1 y por ahora ya tiene unas cuantas implementaciones. En WCF tenemos un mecanismo de serialización binario propio de .Net y solo existe una implementación, hasta donde sé, de FI para .Net. Esta implementación es desarrollo de noemax y sin duda parece la alternativa para aquellos que quieran implementar una solución basada en WCF y FI, pero sería bueno implementar lo necesario para proveer este servicio en un entorno de Test.
    • Pros: Permite que trabaje bastante con WCF, XML y servicios y puede ser de utilidad en muchos escenarios.
    • Cons: Uno de los requerimientos base es soportar el manejo de ASN.1 que en el framework es inexistente así que hay que construir mucha plataforma antes de llegar a lo interesante.
  • DNN.Performance: DotNetNuke es ampliamente utilizado y recomendado en todos los ámbitos. Sin embargo, todas y cada una de mis experiencias con la plataforma me ha dejado claro que el equipo de desarrollo jamas como objetivo el performance de la aplicación. Todas las páginas y componentes que he revisado pueden mejorar sustancialmente con un poco de análisis y esfuerzo así que es una posibilidad contribuir a este equipo.
    • Pros: Es un proyecto que involucra muchos aspectos del framework y que seguramente puede tener impacto en muchas instalaciones y sitios web.
    • Cons: Dado el ciclo de desarrollo de DNN puede requerir mucho tiempo antes de brindar resultados terminando en un branch antiguo siendo el optimizado
  • Catalogo UDDI: En este caso el objetivo sería construir un catalogo de servicios (no solo un directorio) basado en UDDI 3.0.
    • Pros: Me permitiría aprender UDDI y puede ser de mucha utilidad.
    • Cons: El futuro de UDDI lo veo incierto en el mercado en general así que no se cuanto pueda escalara la solución.
  • Parallel FX: No se qué... pero me encantaría hacer algo con Parallel FX claro que aca como primer punto esta conseguir un drop del mismo y eso no pasará en un buen tiempo.

En fin como verán la decisión no es simple por ahora quien lleva las de perder es DNN pero uno nunca sabe que pasará. Cualquier sea el caso los avances y aprendizaje serán reflejados en este espacio.

La noticia corre rapido

EL día de hoy por distintos gerentes de programa y producto (ScottGu por ejemplo) se dió a conocer que Microsoft hará disponible el código de las clases base de .Net. El código incluirá comentarios y estará integrado nativamente para el debug en VS 2008.

Este es un gran hito para el equipo de producto y para todos los programadores .Net. Eso sí, es muy importante aclarar los términos de la licencia que hacen esto posible, el código estará disponible bajo los términos de Microsoft Reference License. Es decir .Net NO es open source esto significa que todos aquellos que estén involucrados activamente en el desarrollo de productos open source DEBEN abstenerse de mirar estas librerias Miguel de Icaza es el primero en hacerlo saber a los colaboradores de Mono. A el ya se suman muchos responsables de proyectos Open Source para asegurarse de evitar problemas.

En fin, para todos aquellos que no son colaboradores son buenas noticias. Habrá mucho tiempo divertido y de aprendizaje revisando el código fuente de todos los componentes de las librerias base del Framework.

PS: Este post lleva días como draft y seguramente la noticia ya es vieja ... :(

miércoles, agosto 08, 2007

Iron* para Firefox

Reisando mi largamenet retrasada lista de blogs hoy me entere que Mozilla tiene un proyecto denominado IronMonkey que tiene por objetivo que se puedan ejecutar scripts escritos en IronRuby y en IronPython en firefox.

Esta notiicia es enorme porque significa que efectivamente se estaría brindando la posibilidad a los programadores Web de utilizar otros lenguajes además de ECMAScript en los dos navegadores más utilizados ... esperen si consdieramos que Silverlight estará disponible para Safari en Mac estamos por encima del 99% de los navegadores.

El objetivo del proyecto es crear un traductor de CIL a ABC que es el código intermedio de Tamarin, la maquina virtual para JavaScript desarrollada por Adobe e integrada en los productos Mozilla.

Si Mozilla logrará efectivamente construir un traductor, con rendimiento en Web aceptable, de CIL a ABC en realidad cualquier lenguaje basado en DLR podría ser ejecutado en Firefox. Esto abre la puerta a VBX, IronPHP y cualquier otros que se vea por ahí. Eso es muuuuy emocionante.

Por otro lado Miguel de Icaza pulico en su Blog una pequeña prueba del rendimiento de Tamarin comparado con Mono y resulta que aún en lenguajes nativos Mono es más rápido. Su planteamiento es "Mono podría integrarse en Firefox y ser VM de scripting".

La idea de Miguel es díficil que sea aceptada en el corto plazo por tiempos, planificación y otros aspectos, pero la idea de tener navegadores que soporten CIL assemblies nativamente, además del soporte para SilverLight, en todas las plataformas es una linda utopia.

viernes, febrero 16, 2007

SubSonic - ActionPack

Una de las ventajas de los lenguajes dinámicos es que los ORMs o pseudo-ORMs que se utilizan pueden generarse totalmente con la información de la base de datos. El más conocido ejemplo de esto hoy en día es ActiveRecord que es una implementación del patrón ActiveRecord en Ruby, y es el más famoso por ser utilizado por Ruby on Rails(ROR). Como los que leen mi blog saben soy un seguidor de Python más que Ruby por lo que mi implementación favortia de este tipo de ORMS es SQLObject, y si quieren un framework MVC prefiero TurboGears, pero bueno no voy a desviarme del tema.

Los que me conocen saben también que no soy amigo de los ORM entonces porque lo que se preguntarán porque lo menciono en el mundo dinámico. Bueno porque en el mundo dinámico el costo de creación del objeto en sí hace que el costo del ORM sea despreciable. Además que todo el manejo de SQLObject me parece muy coherente y segundo porque todo el concepto de mapeo puede hacer que todo el proceso sea muy complicado. Pero si se pudiera tener algo efecitvo y ligero no estaría de más.

En el mundo CLR he visto varios intentos de hacer cosas similares (ActiveRecord de CastleProject por ejemplo) casi siempre asociado a proyectos de creación de frameworks MVC al estilo de ROR (MonoRail). Sin embargo en estos proyectos he encontrado el problema común de la creación de los objetos, dado que el CLR es fuertemente tipado las clases deben ser conocidas por el compilador y no pueden ser modificadas posteriormente lo que limita mucho la creación automática.

Muchos proyectos han optado por la generación de código fuente para evitarse el problema de la generación del CIL. Esta opción es muy utilizada (CodeSmith es el ejemplo del que más he oido hablar) y creo que da buenos resultados, sin embargo estas soluciones requieren que cuando cambias o agregas elementos a tu base de datos debas regenerar la solución y recompilarla, dado que muchas veces agregas elementos sin modificar lo anterior no es lo más lógico reconstruir todo al menos no desde el origen.

CastleProject trato de usar su conocimiento de generación de CIL para facilitarlo así que basandose en NHibernate obtuvieron algo interesante, pero aún así se debe declarar la clase base y su comportamiento con lo cual no ganaron mucho.

Revisando algunas cosas me encontré con Commerce Starter Kit una aplicación para la creación de sitios de comercio electrónico, el proyecto en si es interesante, pero lo que más me llamó la atención fue su enfoque MVC basado en SubSonic y ActionPack ¿porque me llamo la atención? porque no es necesario generar el código intermedio convirtiendose en una verdadera DAL sin código.

Al principio me pareció demasiado vudú por el hecho ya mencionado de ser el CLR tipado así que me dedique a ver la solución, conforme revise SubSonic (la parte de acceso a datos de ActionPack) entendí su solución y me encantó.

Lo que hace SubSonic es crear un proveedor de Build para ASP.Net lo que le permite que generen el código en demanda y sin necesidad de crear los archivos intermedios, una solución sencilla y altamente efectiva.

Este simple cambio de ubicación hace que la solución sea mucho más fácil de utilizar que otros modelos que haya visto y genera un escenario muy limpio ¿Por qué? porque las clases se generán dinámicamente y sin necesidad de crear archivos adicional y sin importar el lenguaje en el que programes.Obviamente un nivel de abstracción no es lo suficientemente bueno si no puedes modificarlo por lo que, si así lo quieres, puedes generar los archivos intermedios y/o modificar las plantillas DOM para la generación de los mismos.

Si uno lo piensa la tecnología utilizada es la misma que en los otros casos pero el enfoque y modo de combinación es lo que hace que SubSonic sea una solución muy simple y práctica para el uso en frameworks Web y estoy pensando seriamente en su validez en otros escenarios.

A veces la innovación no esta en la tecnología sino en la forma de uso de la misma. Ya les contare de mis pruebas con SubSonic y en un siguiente post hablaré de la parte de scaffolding de Action Pack.

Nota: Obviamente piensen que para usarlo tienen que tener su modelo de datos completo después de todo Active Record parte de la base de datos.

domingo, febrero 11, 2007

LOB Adapter SDK for WCF

La semana pasada estuve en un conjunto de conferencias de distintos temas y fuera de un tema de HPC que estoy analizando lo que más me llamo la atención, y que creo que es un salto muy interesante en el concepto de integración de aplicaciones, es el LOB Adapter SDK for WCF (Kit de desarrollo de adaptadores para aplicaciones de negocio para WCF)

Este SDK, que esta en Beta junto con BizTalk R2, es una extensión a WCF para construir conectores con aplicaciones de negocio. En primera instancia debo decir que me pareció muy raro que hubiera algo de este estilo pues con lo extensible que es WCF el construir un nuevo transporte y/o encoder es bastante simple con lo que se podría crear bindings para cualquier aplicación.

Sin embargo hay un par de aspectos que son importantes para los conectores que son necesarios implementar y que los sabios pudieron explicar a este moral.

  • Metadata: Es necesario buscar un mecanismo para el intercambio y acceso a la metadata de la aplicación de negocios a la que se quiere acceder. Esto no es un tema simple porque a diferencia de un servicio o servicios específicos en cuyo caso se puede intercambiar toda la información relacionada con esquemas, contratos y políticas de comunicación (WS-MetadataExchange es el protocolo diseñado para este intercambio) una aplicación puede exponer una gran variedad de funciones y endpoints de distinta indoles y/o categoría de manera no organizada en servicios. Estas funciones, adempás, pueden o no estar disponibles y variar de acuerdo a la instalación o configuración del sistema.
    El mejor ejemplo de este tipo de comportamiento lo dan SAP, JDE, PeopleSOft, Siebel cuyos sistemas pueden tener dependiendo de la instalación y configuración conjuntos muy distintos de funciones expuestas para el acceso por parte de los usuarios. .
  • Creación del proxy: Un problema derivado del anterior esta en la creación del cliente dado que la metadata no es necesariamente expuesta en términos manejables por MEX (WS-MetadataExchange) svcutil no es una herramienta que se pueda utilizar para la creación del cliente.

Anteriormente los distintos adaptadores de LOB se generaban los desarrolladores del mismo eran los encargados de crear herramientas para realizar las dos tareas anteriores por ejemplo: el SAP.Net conector de SAP tenia herramientas para la creación los proxies a ser utilizados en .Net mientras que el SAP Adapter para BizTalk tenía otra herramienta para la creación de los esquemas a ser utilizados en los endpoints y el intento de SAP data source para SSIS tenía su propio desarrollo para solucionar estos problemas.

Obviamente con el crecimiento de necesidades de integración en las distintas aplicaciones esto es una necesidad cada vez más común. Por ejemplo solo en productos de microsoft los siguientes productos necesitan conectores a sistemas de este tipo: BizTalk, SharePoint, SSIS, SSRS (Reporting), MILM (Identity Lifecycle Manager), potencialmente MOM y seguro algún otro que se me pasa de lado.

Por todo esto es que el equipo de integración de Microsoft empezó a trabajar en un framework para la creación de adaptador para aplicaciones de negocio que cumpla con los requerimientos base de todas las aplicaciones permitiendo que la conexión punto a punto pueda ser resulta una sola vez y reutilizada por todos.

El framework obviamente se basa en la plataforma de servicios y comunicación de Microsoft WCF y provee una arquitectura que ya explicaré en algún otro post. El framework provee un conjunto de elementos reutilizables que asegura que el desarrollador de un conector tenga que limitarse a lo estrictamente necesario, que es:

  • Emision, consulta y busqueda de Metadata: La diferencia en este punto es que el desarrollador expondrá unas cuantas interfaces comunes y que manejan las descripciones de manera abstracta. El framework brindará todo el mapeo de esos esquemas con WSDL, XSD, MEX, etc. asegurando que una aplicación que necesite de adaptadores no deba conocer a los mismos directamente y pueda hacer uso de las mismas.
  • Creación de conexiones: Es bastante claro que el adaptador es el que conoce como conectarse con el servidor por lo que la creación de las conexiones es netamente su responsabilidad.
  • Envio y recepción de mensajes: El día que nos podamos librar de esto estaremos listo para dar el siguiente y buscar otro trabajo :)

En otro post entraré en más detalle de la plataforma pero debo decir que lo que vi hasta ahora es muy bueno y vale la pena seguirle el paso

Marc Fleury deja RedHat

Los que me conocen y con los que hemos hablado de Java Application Servers saben que a pesar de que no soy un fanático de Java para mi la mejor solución de ese lado es JBoss. Esta opinión se basa en muchas cosas: su enfoque respecto al stack de JEE, su visión de donde van los application servers en general y su visión de un Open Source Profesional - aún hoy considero que el paper de Marc Fleury en el tema, fundador de JBoss, es muy interesante como modelo de negocios y algo a considerar.

Hace un tiempo RedHat compro JBoss y fue todo un hito en el mundo Open Source, Marc estaba muy emocionado por tener todo el respaldo que le daba Red Hat para seguir trabajando en su modelo de Open Source profesional y fortalecer el áea de Investigación y desarrollo.

Bueno, con todo eso dicho voy al tema del post. Habitualmente sigo el curso de JEMS (Java Enterprise Middleare Suite) y hace ya unos dos meses que se corrían muchos rumores de la "infelicidad" de Marc Fleury en Red Hat, principalmente porque sus expectativas de lo que podría hacer y quería hacer no se estaban realizando. Creo que el pobre Mac no contaba con que al final del día Red Hat es una corporación y no precisamente alineada con su modelo Open Source Profesional.

Todo esto se fortalece cuando hace un mes casi Marc toma "vacaciones indefinidas" respaldado por el nacimiento de su último hijo, este aviso disparó muchos más rumores y casi aseveraciones de la inminente salida de Fleury la historia siguió por semanas pero fue recien el día de hoy se oficializó que Marc no vuelve a Red Hat. Los comentarios que leí dicen que por un tiempo se dedicará a la enseñanza y a pasar tiempo con su familia, esa es una gran noticia para Marc pero algo para pensar para los que defienden el modelo de Red Hat como un modelo de Open Source comercial.

Es bien sabido que Red Hat es la oveja negra de todos aquellos que se consideran seguidores del modelo Open Source sin embargo creo que esto es la prueba definitiva de la divergencia entre el proveedor más importante de Linux para empresas y la corriente Open Source.

Sinceramente espero que no sea lo último que escuchemos de Marc insisto que hasta la fecha su visión en relación a Open Source es la única que me ha parecido sostenible y coherente. Eso sí no puedo negar que espero que la próxima vez que se sepa de él sea en el mundo de CLI y no de JVM ;)

jueves, enero 18, 2007

Windows Movie Maker y MOV

Este post será muy corto y concreto hace una semana o más decidí utilizar por primera vez Windwos Movie Maker a fin de editar y adecuar unas cuantas filmaciones que se realizaron con una pequeña camara digital. Debo decir que WMM es en realidad muy fácil de usar y pude ubicarme muy rápido, lamentablemente cuando quise importar los archivos encontré que WMM no podía importar archivos MOV :S

Entonces empecé a entender, WMM importa archivos basados en Codecs de Windows o DirectShow y obviamente Apple y QuickTime no proveen los mismos. Ademas que no tenía instalado QuickTime Player (no soy muy fanático del mismo)

Estuve buscando un Codec para el formato de QuickTime y cuando estaba a punto de darme por vencido encontre QuickTime Alternative,  que es un codec para Windows y un filtro para DirectShow que permite visualizar MOV. Lo instale y ahora puedo ver los videos en WIndows Media PLayer y estoy editando los videos en Windows Movie Maker.

viernes, enero 12, 2007

Larga vida Community Server

Bueno este post tiene por objetivo explicar mi larga ausencia y ver si puedo retomar la escritura.

Como ya comenté tuve problemas con mi portátil lo que me limitó mucho y no me permitió trabajar en varias ideas que tenía en la cabeza. Para resumir una larga historia luego de casi tres meses de esperar que el soporte técnico de HP pudiera reparar la portátil y/o que llegaran las partes HP decidió entregarme una nueva portátil, la nueva es una Compaq nx6320, es un buen equipo y por ahora el único reclamo que me hizo golpearme la cabeza contra la pared es que su LCD solo soporta hasta 1024x768 pero bueno a todo uno se acostumbra.

Para que se den una idea de cuanto tomo todo el proceso la entrega no se concretó sino hasta el 20 de diciembre por lo que después de las fiestas estuve instalando y configurando el equipo (Vista, Office 2007, Net fx3, SQL 2005 SP2, etc, etc) y estuvo listo para reiniciar actividades para fin de año.

Bueno ahora ya saben que tengo tan sólo un par de semanas con total capacidad de operación. y en dichas semanas estuve trabajando en un pequeño proyecto que es lo que da nombre a este post.

Para ponerlos en contexto a fines del año pasado me involucré en la creación de un pequeño sitio de comunidad (nada de tecnología) y por ser el que trabaja con computadoras me toco encargarme de ver el hosting, plataforma y todo aquello.

Dado que la comunidad no será manejada y en realidad tiende a ser bastante pública tenía que ser una plataforma fácil de usar y administrar por no techies. Tipicamente para este tipo de escenarios en proyectos que realizo utilizo WIndows SharePoint Services. Pero como en este caso el hosting no siempre lo provee y no necesitabamos toda la plataforma decidí evaluar dos alternativa DotNetNuke y Community Server, ¿por qué esas dos? 1)por que son las que conocía 1) habia jugado con ellas alguna vez 3) Son muy utilizadas y probadas.

Dado que el criterio de selección final iba a ser la usabilidad creí que la mejor forma de probar era bajar el último build de ambos, instalarlo, configurarlo, crear un tema y dejar un pequeño sitio de prueba funcionando.

DotNetNuke

DotNetNuke (DNN) es uno de los proyectos Open Source ASP.Net más grandes del planeta y esta enfocado en la fácil creación y mantenimiento de sitio, portales y aplicaciones Web. Los que me conocen saben que DNN no es mi plataforma favorita y esta lejos de serlo pero las razones son netamente técnicas y de rendimiento - Si bien DNN sigue prácticas altamente probadas de diseño y hace un uso muy efectivo de varios patrones, en mi opinión esta sobrediseñado y todo este sobrediseño hace que el rendimiento caiga conforme mayor su uso solo como ejemplo los invito a revisar como esta implementado el manejo de RSS - pero como en este caso no necesitamos escalar mucho y tenía ante todo la necesidad de ser fácil decidí considerarlo.

A continuación van los resultados de cada paso

Instalación

La instalación de DNN fue bastante simple, copiando los archivos en la carpeta Web y luego siguiendo los pasos del asistente DNN fue capaz de tener el sitio funcionando en un par de minutos, definitivamente fue un punto a favor.

Configuración

El proceso de configuración consiste en la limpieza de los datos de ejemplo, creación de unos cuantos foros, un par de blogs y un conjunto de galerias. Aquí es donde DNN empezó a caer en rating, limpiar los datos creados por defecto fue fácil, pero cuando empezé a buscar la creación de nuevos elementos pude ver que no toda la funcionalidad que necesita estaba incluida y necesitaba descargar varios módulos. Entonces entre al sitio de DNN e ingrese en un su buscador una simple frase Create a Forum, si no hubiera cerrado el navegador probablemente aún estaría esperando la respuesta (no el rendimiento que uno espera), bueno intentemos de nuevo :S Error inesperado. Ok DNN no me ayudará. Pero encontré un buen sitio DNN Creative que con sus tutoriales me permitió hacer un par de cosas. Ahora vamos con los blogs pero esto no soporta enclosures y así la lista seguía y bajaba otro módulo y otro módulo... basta, esto me sirve para entender el concepto.

Creando un tema

Asumiendo que mi sitio estaba listo (solo asumiendo) me puse a trabajar en crear un tema. Los temas de DNN se basán en archivos HTML y ASCX que definen las zonas de trabajo para que luego DNN ponga el contenido. Me baje la guía de creación de temas del sitio y empezé a trabajar en ello parar resumir estuve un par de horas cambiando cosas y jamas pude hacer que DNN luciera como quería. Es cierto que es muy flexible y con unos días más de trabajo lo hubiera logrado pero esto era solo una prueba y no tenía días de trabajo.

Conclusión

Al final mi sitio no tenía todo lo que quería y tenía un tema a medias :S.

Antes de seguir tengo que reconocer que DNN tiene como gran ventaja el gran número de módulos disponibles si quieren crear un sitio o aplicación que vaya más allá de una comunidad la funcionalidad es accesible, completamente integrada y definitivamente es una buena alternativa que requiere una inversión importante de tiempo.

Community Server

Community Server (CS) es un producto de Telligent una empresa de desarrollo .Net que construyo la plataforma para su uso y luego la comercializó siendo la versión Personal gratuita para uso no comercial y en un solo dominio. Además que no está activa toda la funcionalidad de CS, ah y requiere que el logo de Powered By este en todas las páginas.

Antes de seguir hay que aclarar que dado que este es un producto específico para comunidades lo que le da cierta ventaja sobre DNN, también debo decir que tecnológicamente me parece una plataforma mucho más interesante que DNN.

Instalación

La instalación de CS fue también muy simple, copiando los archivos en la carpeta Web y luego siguiendo los pasos del asistente la comunidad estaba lista en un abrir y cerra de ojos.

Configuración

Dado que al momento de instalar CS pregunta si se incluirán datos de ejemplo no fue necesario realizar una limpieza y pude empezar directamente con la creación de los blogs, foros y galerías. La verdad que la tarea fue muy simple (el panel de control es muy claro) y en menos de media hora tenía creado todo mi contenido de ejemplo. Tuve algunos problemas habilitando la publicación de usuarios anónimos pero una búsqueda en el sitio de CS permitió que un CS MVP me diera la respuesta. Punto a favor.

Creando un tema

La creación de temas fue un poco más compleja porque al principio me costó entender el modelo de skinning de CS pero de nuevo un par de búsquedas en el sitio me dieron la pauta y resulto mucho más simple de lo que pensaba. CS basa sus plantillas en Contenidos y regiones (muy similar a los conceptos de master pages de ASP.Net 2.0) así que una vez comprendido pude crear un tema de blog en un par de horas.

El tema de sitio tomaría más pero el concepto era el mismo

Conclusión

Al final mi sitio lucía como una comunidad, tenía el funcionamiento de una comunidad y tenía blogs y galerias con temas propios.

Claramente las ventajas de CS para el manejo de comunidades superan por mucho a las de DNN pero tienen la contra de las limitaciones por licenciamiento y que no es tan fácil integrar nuevas aplicaciones (bueno si es fácil pero los add-ons no están disponibles en la versión Personal).

Como el título ya denotaba al final me quede con CS Personal y no me arrepiento luego de dos semanas de trabajo (donde el mayor trabajo fue el diseño del tema y del contenidodel sitio) hoy la comunidad esta en línea y pronta a hacerse pública.

Como siempre no faltará quien diga que soy un ignorante en DNN o que si quiero otro dominio CS Personal no me sirve o ...[insertar razones por las que DNN es el mejor software del plante], es probable que todo sea cierto pero CS Personal resolvió mis necesidades actuales de manera más simple, rápida y adecuada, al final ¿no es eso lo que importa?