CTP liberado de Enterprise Library para .NET 2.0!

Así sin más, el equipo de Enterprise Library pone a disposición de la comunidad la versión August CTP of Enterprise Library for .NET 2.0.
El readme que viene con el archivo, aclara los puntos que se incluyen, lo que funciona, lo que todavía no funciona y sobre todo algo que hizo que saltaran mis ojos: Dependency Injection.
El tan sonado tema, ahora en EL... Interesante, ya que hace poco se anunció la liberación de Spring.NET y todavía más, encontré por ahí Castle Project que es otra implementación más de Dependency Injection.
En una serie de webcast acerca de arquitectura, Avanade, el alma matter de EL, presentó el tema de Frameworks, donde se vió que los servicios que se tienen con EL son meramente de infrastructura, y en su caso, complementó mediante aspectos, otro punto que ofrecen tanto Spring como Castle así que ahora... ¿Cuando introducirán aspectos en EL? El modelo que presentó Avanade es harto interesante, como plataforma de desarrollo empresariales.

Comentarios: Pragmatic Starter Kit: Unit Testing in C# with NUnit

Terminé de leer este libro y me ha quedado un excelente sabor de boca. No puedo recomendarlo más. Trata de manera directa y precisa el uso de pruebas unitarias en el contexto de C#, yendo un más allá de la mera sintáxis de NUnit, aclarando sobre todo el como usar las pruebas unitarias, que se debe probar, maneras de anticiparse a los errores, Mock Objects (¿cuál será una buena traducción para esto?) y finalmente una tarjeta con los principios generales y prácticas recomendadas para el uso de las pruebas unitarias que sirve de recordatorio de los temas leídos.
Este libro forma parte de una triada, que toca en los restantes tomos los temas de control de versiones, con sabores CVS y SVN, y la automatización de los procesos de construcción, pruebas y liberación. Me gusta este enfoque centrado en un tema habiendo leído antes libros que tocan varios puntos a la vez. Esto permite una exposición detallada y a la vez breve (el libro tiene 200 +/- páginas) de los temas sin caer en puntos omisos ni breves introducciones.
Otra característica interesante es la oferta del libro en formato PDF o comprar ambas versiones al mismo tiempo. Tenemos así la versión impresa para una buena lectura de noche o en transporte público y la facilidad de traerlo con nosotros en el disco duro del equipo.
En fin, un libro interesante para novatos y experimentados por igual.

Nueva versión de Spring.NET

Ya está liberada la versión 1.0 de Spring.NET que tiene como principal característica la implementación de AOP además ser la base para los subsecuentes desarrollos.

Patrones, fábricas, contenedores: Spring.NET

Spring es la realización del patrón de diseño Inversion of Control, una alternativa para enfrentar la creciente complejidad en la construcción de soluciones, a las cuales se les exige cada vez más flexibilidad y adaptibilidad a las cambiantes situaciones de la industria.
En la edición de Septiembre de MSDN, Griffin Caprio, miembro del equipo que está desarrollando Spring.NET, publica en la columna Design Patterns el artículo Dependency Injection, una breve introducción a los conceptos de Inversion of Control, Dependency Injection y Spring.NET

El café es mi tipo

You Are an Espresso

At your best, you are: straight shooting, ambitious, and energetic At your worst, you are: anxious and high strung You drink coffee when: anytime you're not sleeping Your caffeine addiction level: high

What Kind of Coffee Are You?

Patrones de Diseño.

Recién leí en la edición del mes de julio de MSDN Magazine la columna Behind The Scenes que trató acerca de Discover the Design Patterns You're Already Using in the .NET Framework.
Los patrones de diseño son de aquellas cosas que no siempre se entienden la primera vez. Muchas veces nos ayuda verlos ya implementados y en el caso del artículo, como se implementaron en la BCL de .NET.
Una vez conocidos, tiene uno la urgencia de aplicarlos para todo lo que nos va apareciendo (un singleton aquí, strategy por allá, command ¿por qué no?), después de un tiempo, nos recordamos una vez más que todo en exceso es malo. Además de la equivocada idea de que aplicar un patrón de diseño, es copiar el código, perdemos de vista que los patrones de diseño se aplican durante el diseño, no se obvian y se corta y pega código al momento de la construcción.
Los patrones que se mencionan en el artículo son los clásicos de Gamma et alias. Muchos los consideran los "creadores" de los patrones, aunque realmente este concepto viene de otra disciplina, la arquitectura y existen otras fuentes de patrones.
Microsoft por su parte, desde el inicio de Patterns & Practices, ha promovido algunos conjuntos de patrones, así tenemos a Enterprise Solution Patterns Using Microsoft .NET, los Data Patterns y finalmente, Integration Patterns.
Patrones de Diseño. ¿Cuál es el mejor modo de usarlos? Conocerlos, entenderlos y aplicarlos sin hacer "copiar y pegar".

La tercera es la vencida :)
Un break de casi seis meses, pero heme aquí de vuelta. La motivación (dirían los abogangsters) de este comentario, es la ya anunciada aparición de Microsoft Vista, aka "Longhorn", la página indica que a partir del 3 de agosto de este año estará disponible el Beta 1, así que de seguro ya hay un bonche de manos ansiosas de juguetear con Vista.

Casi seis meses. Esta vez si ha sido demasiado tiempo. Pero también han sido bastantes cosas las que han sucedido.
En estos meses, me he involucrado con J2EE, con tecnología "empresarial" (que afán de descalificar todo lo no está etiquetado como "enterprise"), con application servers, queues, persistencia, logs, web services, transaction monitors, patterns, standards, api's....¡waa!
He encontrado cosas muy interesantes, y también cosas que me han dejado pensando acerca de aquellos que hacen de sus herramientas de trabajo su religión y viven buscando descalificar a la competencia.
Es increible como termina uno embrollado y llevado a esta "guerra" de bluffing y demostraciones inocuoas que finalmente es parte del negocio de nuestros queridos fabricantes (léase $un y Micro$oft).
Nosotros trabajamos día a día con las herramientas que proveen y solucionamos problemas, nos desesperamos, hacemos "magia" (para algunos), estupideces para otros. Al final, nos apasionamos y plenamente aceptamos la herramienta como parte integral de nuestro ser; suda, vibra y sangra al igual que nosotros. Tal vez hasta en casa la tenemos como un miembro más de la familia, un hijo, una hermana, tal vez hasta lo vemos como padre, con veneración y respeto.
Y damos la vida, nos jugamos la reputación, creamos enemigos en lugar de amigos potenciales, azúzamos con puyas estúpidas y pretendemos tener la más grande.
Cuando por alguna situación nos tenemos que ubicar en la esquina contraria a la de nuestra preferencia, forzados a trabajar con "subherramientas", gadgets con defectos, monoliticos artefactos de la prehistoria, podemos encontrarle todos los errores del mundo. Lo enormemente sorprendente es encontrar ¡que ellos mismos señalan sus errores!
Dentro de todo este aprendizaje express, cayó en mis manos un libro que, correctamente aplicado, nos ayuda ha ubicar, que no existen marcas ni fabricantes ni nada más.
Mi percepción de esta historia, es que Java (el oscuro contrincante) nació de un fortuito accidente mercadológico, estuvo en el lugar apropiado, en el momento apropiado. Gracias a una pujante comunidad se convirtió en un concepto asociado a internet y al igual que la red de redes, tuvo un crecimiento explosivo.
A diferencia de internet, la tecnología Java fue de nuevo incubada y esteroizada bajo la paternal tutela de $un, que sin ser una empresa de software, vió la oportunidad de abarcar otro$$$ mercado$$$. Así que le invirtió tiempo y dinero (sin mucho cerebro) y llevó esa práctica tecnología al stand de herramienta "empresarial" (junto con su hardware, claro). Para eso tuvo que desarrollar (o "reinventar" o maquillar) conceptos rimbombantes que sonaran a "enterprise" y así nació J2EE, claro.
La comunidad Java independiente, a la fecha cuestiona seriamente si el camino al que $un llevó la tecnología Java es el correcto. Cuestiona duramente si su especificación realmente es "empresarial", cuestiona si la guía que ha proporcionado es la correcta para el mundo de desarrolladores que día a día se gana el sueldo usando sus productos.
¿Qué tiene que ver esto en un blog asociado a .NET? Creo que mucho. No le pido a nadie que arranque una desbandada de desarrolladores Java a .NET; no creo que nadie se encargue de vivir encontrando defectos al contrincante (a menos que sea su trabajo).
Lo que veo, es que la comunidad .NET tiene que aprender de estos errores históricos de industria. Tiene que aprender que la comunidad Java es en realidad quién ha hecho crecer la adopción de la tecnología Java, proporcionando herramientas y prácticas que realmente ayudan a resolver los problemos con los que nos enfrentamos todos los días.
Estamos a meses de que se libere una nueva versión del .NET Framework, hasta donde he visto, vienen algunos cambios radicales. Lo importante es que seamos capaces de tener una actitud crítica y objetiva acerca de esta nueva oferta de herramientas de trabajo. ¿Realmente nos hace más productivos? ¿La manera como nos guían nos lleva a mejores resultados? ¿Ganan ellos y ganamos nosotros? ¿o se trata de otra relación histórica del ganador y el perdedor?

Ayer y hoy tuve la oportunidad de participar en las reuniones de dos comunidades Microsoft: Technet y la Comunidad.NET del D.F.
Lo que más me sorprendió, sobre todo hoy en la reunión de Technet, fue la cantidad de participantes. En ambos eventos el espacio planeado fue insuficiente para satisfacer la demanda.
Además, algo que confirme, es que soy un developer. Las pláticas de Technet fueron bastante buenas, pero la verdad, lo mío, lo mío es el SW.
Otra cosa bastante notoria para mí, fue la diferencia de participación de los miembros de las comunidades ¿Será cierto eso de que los desarrolladores somos "ratas de biblioteca"?
De la reunión de ayer, Comunidad.NET, me sorprendió agradablemente fue la propuesta de Erik Martínez Roqueñi en relación al intercambio de experiencias. Creo que para eso son las comunidades, eso es lo que da fuerza a un grupo, un intercambio de experiencias, la diversidad de ambientes, las aportaciones de jóvenes y veteranos por igual.
¿Qué podemos hacer para desarrollar nuestra Comunidad.NET? Participar. Participar en la medida de nuestras capacidades e intereses.
En lo particular, me gustaría tener la oportunidad de hablar acerca de los Applications Blocks. Tengo experiencia en el Data Access Application Block, estoy terminando la implementación de unos providers para el Authorization and Profile Application Block y voy a iniciar un proyecto en el cual además de los anteriores, planeo usar el User Interface Process Application Block.
Realmente no soy expositor de carrera y la cuestión de hacerla de instructor no se me da mucho, pero me anima el hecho de promover una cultura de participación e intercambio para apoyarnos mutuamente. Nadie sabe todo y existe más de una manera de matar una mosca, alguna será mejor que otra, pero nunca lo sabremos hasta exponerla a un grupo de colegas e intercambiar puntos de vista.
En fin, es bueno ver que la Comunidad crece, pero ahora se tiene que hacer el esfuerzo para conseguir que se mantega así.

Después de una larga jornada fuera, este artículo.NET Tools: Ten Must-Have Tools Every Developer Should Download Now -- MSDN Magazine, July 2004 me ha motivado a bloggear de nuevo. Chk it out las herramientas que ofrecen, uso la mayoría y sip, realmente ayudan.

Estas son las cosas que me hacen desesperar, todavía no puedo ni entender y menos usar la versión 1 y estos chiquillos y chiquillas ya sacaron User Interface Process (UIP) Application Block - Version 2.0
"AAAARRRRGGGHHH" Al más puro estilo Charlie Brown

Interesante secuencia de artículos publica Microsoft Bélgica en relación al diseño de aplicaciones en n-tier, este es el segundo de la serie y trata el Business Layer: Microsoft Belgi� & Luxemburg - MSDN - N-Tier Application Development with Microsoft .NET. Dentro de la página de Patterns and Practices se encuentra el documento Application Architecture for .NET: Designing Applications and Services, que es el blueprint de las aplicaciones .NET en general.

¿Qué hacer cuando necesitas convertir esas cadenas vacías a NULL? En este foro dBforums - Changing empty string behaviour, se toca el punto, y creéme, ayuda.
Es el clásico caso de que haces una aplicación donde pueden guardar comentarios, y no falta el usuario que guarda comentarios "en blanco", espacios que se convierten en una cadena de texto, que para los efectos de las consultas, no NULL's. Entonces, aplicas la pequeña sugerencia del artículo y ¡listo!

Para esos que preguntaron...."What is SharePoint 2003?" y a los que les gustaría ver .NET en mi aplicación.
Los chiquillos y las chiquillas de Redmond, lanzaron ya una versión beta de un nuevo Starter Kit, ASP.NET Issue Tracker Starter Kit, solo espero que no desbanque a Project Server & Sons.
ja

Todo lo que quiso saber acerca de RSS y weblogs y no se atrevió a preguntar: The XML Files: All About Blogs and RSS -- MSDN Magazine, April 2004

El artículo Building a Desktop News Aggregator es una breve introducción a lo que es RSS y el desarrollo de un cliente con herramientas .NET. Fuera del tema de RSS y .NET, la definición de requerimientos funcionales se me hace ideal; frases simples, objetivas, verificables que delimitan perfectamente lo que el sw al final hará y como satisfacerá al usuario.
SharpReader es otro RSS reader, harto bueno y harto recomendable, chk it out.

¿Quién dijo que enviar correos desde aplicaciones .NET es fácil? Tal vez cuando haces los ejemplos con tú máquina, pero cuando empiezas a trabajar con hoster, que va, ya no es "ezy"....
System.Web.Mail, OH MY! aunque no me resolvió el problema, me dió una ayudadita para entender todo esto del envío de correos desde aplicaciones .NET.
Al final lo resolví usando CSLMail, un componente que encontré en WinToolZone. Simple, sencillo y efectivo, lo único es que no viene con código fuente, pero al fin y al cabo, deje de sufrir con el envío de correos :D

Junto con el lanzamiento de la versión 0.31 del Proyecto Mono hay una nota muy interesante acerca de la reciente reunión del grupo de desarrolladores del proyecto, ONLamp.com: Will Mono Become the Preferred Platform for Linux Development? [Mar. 11, 2004].
El punto es, comparto la opinión de Miguel ("To me C is dead. Except for the JIT!"). Aunque han aparecido otros lenguajes populares como es el caso de Perl, Python, PHP y... ¡ah! si Java, ninguno ofrece una solución tan completa e integrada desde su concepción.

Ha sido una temporada fuera bastante larga.

Para empezar, ¡que inventazo eso de los RSS feeds! Ahora con un solo lector, tengo las noticias de los temas que me interesan sin andar saltando de sitio en sitio, ni estar recibiendo mensajes en mi cuenta de correo, esto simplemente es fantástico.

En otros temas, ORM mejor conocido como Object Role Modelling, es una metodología bastante, pero en serio, bastante interesante para el modelado conceptual de bases de datos. Parte de expresiones comunes y corrientes (no vulgares) acerca del dominio del problema, y de relaciones (facts o hechos) entre las entidades (objetos).

Aunque es una metodología añeja, existen referencias documentales que llegan hasta los 70's (uuuhhhhh!) Se ha dado a conocer al gran público con la herramienta Microsoft Visio, parte del Visual Studio .NET 2003 Enterprise Architect. Incluido desde la versión anterior (2002) no siempre me pareció claro esto del ORM, e incluso compré un libro, Professional UML with Visual Studio .NET: Unmasking Visio for Enterprise Architects, el cual desde el punto de vista de UML me dejo más que satisfecho, pero por la parte ORM (razón original de compra), dedica solo un pobre capítulo. En cambio, la seccón Resources en http://www.orm.net, han sido especialmente clarificadores.

Chéquenlo, le apuesto seriamente a esta metodología, que si bien tal vez no se convierta en el mainstream, seguro nos ayudará a producir mejores modelos relacionales.

Otra noticia más, ¡Mono on SPARC! un avance má en el camino de Mono. Excelente trabajo de esos tipos.

En fin... son tantas cosas que a veces no da tiempo ni para respirar.

CUF

Después de una semana de Solaris-head :D Vuelvo a las andadas y es impresionante encontrar cosas nuevas de buenas ideas existentes. En el anterior post hice referencia al Data Access Application Block for .NET, ahora encuentro en ASP.NET Web, una liga a un interesante artículo de Maxim V. Karpov, quién hace un estudio acerca del uso del polimorfismo en el acceso a datos y hace referencia al Data Access Block 3.0 (Abstract Factory), resultado del trabajo de Diego González en el Workspace Microsoft Patterns & Practices Data Access for .NET.
Este Application Block, a diferencia del anterior, usa los principios de herencia, interfaces y patrones para tener una clase auxiliar que nos permite construir nuestras clases de acceso a datos y usarlas con este AB, teniendo un solo conjunto de código.
Aunque esto es nuevo en el ambiente Windows, durante el desarrollo del proyecto Mono, también se hizo uso de esta ténica, ¿Quién fue primero? No sé, pero lo importante es que tenemos a disposición estas útiles implementaciones para integrarlas a nuestros proyectos.