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.
Anotaciones de diversos temas relacionados con código abierto, metodologías de desarrollo y programación con Ruby on Rails
lunes, julio 25, 2005
domingo, febrero 13, 2005
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?
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?
viernes, septiembre 10, 2004
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í.
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í.
viernes, junio 18, 2004
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.
martes, abril 27, 2004
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
"AAAARRRRGGGHHH" Al más puro estilo Charlie Brown
miércoles, marzo 31, 2004
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.
lunes, marzo 29, 2004
¿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!
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!
jueves, marzo 25, 2004
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
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
miércoles, marzo 24, 2004
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
lunes, marzo 22, 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.
SharpReader es otro RSS reader, harto bueno y harto recomendable, chk it out.
domingo, marzo 21, 2004
¿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
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
viernes, marzo 19, 2004
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.
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.
viernes, marzo 12, 2004
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
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
lunes, febrero 23, 2004
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.
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.
lunes, febrero 16, 2004
Al fin hoy me leí de una corrida la documentación que acompaña al Authorization and Profile Application Block, el últimisisisisisimo release del conjunto de Application Blocks que Microsoft pone a disposición a la comunidad de desarroladores .NET.
Igual que los anteriores Applications Blocks, éste se encarga de una de las tareas rutinarias de cualquier aplicación, en este caso, la autorización y manejo de perfiles de usuario.
En este caso, se ofrecen clases para el manejo de autorización de acciones de los usuarios, basandosé en el concepto de Roles, idéntico al concepto de Grupos en la administración de servidores Windows, mediante el cual los permisos se asignan a conjuntos de usuarios que realizan las mismas tareas y requieren todos los mismos permisos.
También se incluyen clases para manejar Perfiles de usuarios, es decir, un tipo de "catálogo" que incluso pueden ser de fuentes distintas al mismo tiempo (Active Directory, ERP, CRM, Passport).
El definir el acceso a la fuente de datos (providers) como interfaces, permite que el desarrollador programe una clase con las características particulares que requiera su solución. El código fuente incluye providers para obtener autorizaciones basadas en Active Directory y perfiles almacenados en SQL Server, ¿qué tal si usamos bases de datos Jet como almacenes (stores) de perfiles? Para usuarios de algunos servicios gratuitos de hosting no existe más base de datos que Jet (léase Access), así que sería una extensión más que bienvenida.
Para concluir, Microsoft ha sabido mantener una congruencia en sus dichos y haceres. Antes de publicar cualquier Application Block, genera un documento de Practices que crea los cimientos de lo que será la realización de un Application Block. Ejemplos añejos y sonados, son el Exception Management Application Block cuyo documento seminal fue Exception Management Architecture Guide y el mayormente usado y incluso con una actualización mayor de versión, el Data Access Application Block que se definió en el documento original Best Practices for Using ADO.NET.
Igual que los anteriores Applications Blocks, éste se encarga de una de las tareas rutinarias de cualquier aplicación, en este caso, la autorización y manejo de perfiles de usuario.
En este caso, se ofrecen clases para el manejo de autorización de acciones de los usuarios, basandosé en el concepto de Roles, idéntico al concepto de Grupos en la administración de servidores Windows, mediante el cual los permisos se asignan a conjuntos de usuarios que realizan las mismas tareas y requieren todos los mismos permisos.
También se incluyen clases para manejar Perfiles de usuarios, es decir, un tipo de "catálogo" que incluso pueden ser de fuentes distintas al mismo tiempo (Active Directory, ERP, CRM, Passport).
El definir el acceso a la fuente de datos (providers) como interfaces, permite que el desarrollador programe una clase con las características particulares que requiera su solución. El código fuente incluye providers para obtener autorizaciones basadas en Active Directory y perfiles almacenados en SQL Server, ¿qué tal si usamos bases de datos Jet como almacenes (stores) de perfiles? Para usuarios de algunos servicios gratuitos de hosting no existe más base de datos que Jet (léase Access), así que sería una extensión más que bienvenida.
Para concluir, Microsoft ha sabido mantener una congruencia en sus dichos y haceres. Antes de publicar cualquier Application Block, genera un documento de Practices que crea los cimientos de lo que será la realización de un Application Block. Ejemplos añejos y sonados, son el Exception Management Application Block cuyo documento seminal fue Exception Management Architecture Guide y el mayormente usado y incluso con una actualización mayor de versión, el Data Access Application Block que se definió en el documento original Best Practices for Using ADO.NET.
viernes, febrero 13, 2004
Caso curioso... El esposo de una amiga me comenta que en su trabajo, la gente que utiliza free software en sus proyectos están en el rango de los veintes.... ¿casualidad? ¿ambiente? ¿educación? o simplemente intentando cambiar al mundo :D
¿Cual es la diferencia entre un wannabe y algún iniciado en Linux? LFS.
Linux from Scratch es un interesante trabajo de Gerard Beeksmans mediante el cual es posible compilar desde cero tu propia distribución de Linux y para los más aventurados, también el ambiente gráfico.
.NET Framework en el mundo libre.
Miguel de Icaza ha trabajado desde hace más de un año para ampliar el alcance de .NET Framework llevandolo a los ambientes Unix/GNU/Linux mediante su proyecto Mono que avanza a pasos seguros y constantes. Bien sabemos que Microsoft no va a sacar .NET de Windows, pero Mono nos permite trabajar con la mejor plataforma de desarrollo en el sistema operativo con el que pretendemos cambiar al mundo.
moraleja: No necesitas estar en tus "veintes" para revolucionar al mundo, necesitas luchar hombro a hombro, día a día junto con otros que igual que tú, quieren hacer del mundo un lugar mejor.
¿Cual es la diferencia entre un wannabe y algún iniciado en Linux? LFS.
Linux from Scratch es un interesante trabajo de Gerard Beeksmans mediante el cual es posible compilar desde cero tu propia distribución de Linux y para los más aventurados, también el ambiente gráfico.
.NET Framework en el mundo libre.
Miguel de Icaza ha trabajado desde hace más de un año para ampliar el alcance de .NET Framework llevandolo a los ambientes Unix/GNU/Linux mediante su proyecto Mono que avanza a pasos seguros y constantes. Bien sabemos que Microsoft no va a sacar .NET de Windows, pero Mono nos permite trabajar con la mejor plataforma de desarrollo en el sistema operativo con el que pretendemos cambiar al mundo.
moraleja: No necesitas estar en tus "veintes" para revolucionar al mundo, necesitas luchar hombro a hombro, día a día junto con otros que igual que tú, quieren hacer del mundo un lugar mejor.
miércoles, febrero 11, 2004
¡Hola a todos!
Por fin he entrado a la onda esta de los blogs.... Espero compartir con todos lo más posible de información, comentarios y conocimiento además de algún mal chiste de vez en cuando.
Contrario a la añeja tradición, he dejado atrás el nick de siempre, ahora, con un poco más de personalidad fantástica han de conocerme como Chilli Coder.
¿Por qué? No sé. Simplemente me pareció gracioso.
ja
Por fin he entrado a la onda esta de los blogs.... Espero compartir con todos lo más posible de información, comentarios y conocimiento además de algún mal chiste de vez en cuando.
Contrario a la añeja tradición, he dejado atrás el nick de siempre, ahora, con un poco más de personalidad fantástica han de conocerme como Chilli Coder.
¿Por qué? No sé. Simplemente me pareció gracioso.
ja
Suscribirse a:
Entradas (Atom)