dev \ efor monitoriza tus desarrollos .NET

Cada vez programo menos. Si bien sigo siendo una auténtica puta del teclado, pico mucho menos código que antes, digamos que mis servicios han sido reorientados hacia...buffff, no lo sé ni yo, dejémoslo estar así ;-).

Así todo, siempre he opinado que programar o desarrollar aplicaciones software (que suena mejor...) es un hábito del que ningún informático debería nunca renegar. Tod@s, algun@s durante más tiempo, otr@s con menos suerte y gloria, hemos pasado por la etapa en la que picar o tirar líneas de código a machete era nuestra labor principal, por no decir, única labor. Los que habéis pasado por el mundo de la consultoría como programadores junior me imagino que me entendéis, ¿verdad? Es la rampa de salida inicial de much@s informátic@s, su entrada al ruedo del apasionante mundo del desarrollo de software.

Por ello, aunque cada vez veo menos el splash screen de IDEs como Visual Studio o Eclipse, soy de los que intenta no descolgarse demasiado de los avances que se van dando en este campo. Quizás luego no lo ponga en práctica yo, ni siquiera llegue a instalarme ese último service pack o plugin que ha salido para hacer no sé qué historia, pero al menos, me auto-obligo a mantenerme al día en el ámbito del desarrollo de software, que con todos los cambios que hay, día sí y noche también, no es moco de pavo ;-).

Dicho esto, tras leer ayer un post sobre ALM del amigo Lobosoft que me hizo desempolvar una tarea y correspondiente post pendiente, hoy os paso a presentar uno de los últimos descubrimientos que he realizado en mis esporádicas pero intensas "rondas de vigilancia tecnológica" en el mundo del desarrollo de software": Dev \ efor. La susodicha asegura ser un plugin gratuito (aunque leo que sacarán la correspondiente versión comercial) para Visual Studio 2005/2008 que monitoriza el progreso de tu desarrollo software. Suena bien, ¿no?

Aunque no soy de los siguen a rajatabla ninguna métrica de calidad de código, en el pasado sí que he utilizado herramientas como FxCop (¡thanks titán!), que te ayudan a mejorar tu código con una serie de buenas prácticas, consejos, etc. Por eso, quizás rememorando (¿y añorando?) el pasado, esta utilidad gratuita me llamó en seguida la atención. Aseguran que este plugin mide, analiza y presenta en diferentes formatos, métricas de desarrollo de software siempre interesantes: cuánto tiempo hemos pasado con cada proyecto de Visual Studio, cuántas líneas de código hemos tirado esta semana, qué evolución sigue la calidad del código que estamos generando, etc. Las métricas de código que utiliza el plugin están basadas en Visual Studio Team System Code Metrics, por lo que parecen bastante fiables, de ahí que puedan servir para coronar a un@s y sacar los colores a otr@s ;-).

Hoy admito que no he hecho los deberes y que no he llegado ni siquiera a instalar el plugin, con lo que no os puedo dar un feedback más empírico. Hoy, como veis, simplemente quería lanzar un guante tecnológico ;-). Aún así, conociéndome cómo soy (nostálgico que de vez en cuando abre el Visual Studio 2008 para desarrollar cualquier C# CCA (Chorri-Console Application), seguro que acabo instalando el plugin y monitorizando mi propio código. ¡Qué peligro! ¿Seré productivo programando? Tranquil@s, prometo que si dev \ efor me dice que soy un pocket programmer (programador paquete), muy a mi pesar, prometo...que lo contaré, transparencia hacia los lectores 100% ;-).

Si alguien ya conoce o ha utilizado dev \ efor o herramientas de métrica de código similares, no hace falta decir que sus impresiones y comentarios serán más que bienvenidos...

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Ja.NET SE: Java 5 JDK para .NET

IKVM, bridge entre Java y .NET del que ya hablé en su día, ya tiene rival. ¿Duro? Lo veremos, de momento sólo puedo decir que hoy me he topado con otro de estos famosos puentes que intentan de alguna manera enlazar las dos plataformas de desarrollo software más conocidas y utilizadas.

El proyecto en cuestión se denomina Ja.NET y deriva del proyecto Apache Harmony, proyecto que aboga desde hace tiempo por un Java SE totalmente opensource, en otra palabras, un Java SE no tan made in Sun Microsystems ;-). Los creadores de Ja.NET pretenden ofrecer una implementación opensource del entorno Java 5 SE JDK para .NET, incluyendo librerías, herramientas, y por supuesto, un entorno de ejecución basado en .NET, es decir, una especie de Java Virtual Machine "a lo .NET".

Aparentemente, este nuevo JDK, en vez de generar el famoso e interoperable Java Byte Code a ejecutar por las típicas JVMs, tiene toda la magia para poder compilar código Java a código CIL (antes conocido como MSIL), código que podría ser directamente invocado desde una aplicación C# por ejemplo. Parece que esta conversión utiliza Cecil, una potente librería de Mono para inspección y modificación de assemblies.

¿Qué os parece el remix? Yo mismo no soy muy partidario de estos bridges o pegamentos de segunda clase, sobre todo por el overhead que suponen en su mayoría. Ahora bien, hay casuísticas un tanto extrañas en las que estas utilidades pueden tener su hueco. Por ejemplo, cuando tenemos una lógica de negocio o ciertos algoritmos muy complejos implementados en Java desde hace un porrón de tiempo, puede pasar que al jefe de proyecto de turno, se le ocurra la brillante idea de desarrollar una aplicación .NET para darle a la aplicación una interfaz de usuario más atractiva para los usuarios. ¿A que suele pasar? Está claro que lo que vende es el mariconeo de pantalla ;-).

Pues bien, ahí es donde yo creo que pueden entrar este tipo de frameworks; sería cuestión de compilar el código Java con Ja.NET para generar código que pueda ser utilizado desde una aplicación desarrollada en C# ó VB.NET por ejemplo. La verdad es que el enfoque se me hace muy similar, por no decir igual, que el de IKVM.

A ver si saco algo de tiempo para hacer unas pequeñas pruebas comparativas entre IKVM y Ja.NET, y de paso monitorizo el avance de estos dos interesantes proyectos. Por el momento, IKVM Vs. Ja.NET, pronto en sus PCs de desarrollo ;-).

Vía: InfoQ

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

El timeout del comando sí importa

Hoy retomo un tema relacionado con MySQL que la semana pasada no pude terminar por culpa de un error bastante serio de Google. No voy a hablar directamente de MySQL, pero sí voy a desahogarme con un problemilla (¡qué típico!) que he tenido a la hora de acceder a esta base de datos a través de programación. Sirva como adelanto comentar que este problemilla es extrapolable a todas las bases de datos del mercado; sin embargo, como las pruebas han sido contra MySQL, le daremos el dudoso honor de aparecer en mi post a ella ;-).

El caso es que la semana estuve midiendo tiempos y rendimiento de diferentes sentencias DML lanzadas contra MySQL. Más que nada, me interesaba analizar el comportamiento de los procedimientos almacenados o stored procedures que MySQL soporta a partir de la versión 5.0, frente a las clásicas sentencias en texto plano de select, insert, update y delete. Aunque existen herramientas tipo query analyzer que exprimen todo el jugo a cada consulta y miden tiempos y rendimiento de manera bastante precisa, me apetecía medir tiempos desde el mismísimo campo de batalla, desde la trinchera del programador, a pie de código. Inmejorable ocasión por tanto para probar MySQL Connector/NET 5.2 (última versión de este conector disponible a día de hoy) desde una aplicación de consola dummy programada en C#. Aparte de que quería probar este conector, tiene su lógica hacerlo de esta manera, ya que hoy en día toda aplicación que necesita acceder a base de datos utiliza conectores de diversos tipos dependiendo de la tecnología y lenguaje de programación que se esté utilizando.

Sin más preámbulos ni rollos macabeos, me centraré (por fin) en narrar lo que me pasó durante estas pruebas realizadas contra una base de datos MySQL remota, aunque dentro de las misma red que mi equipo de trabajo. Como siempre, todas estas pruebas y comparaciones suelen empezar suavecito, con sentencias select no demasiado complicadas, 1000 inserciones en una tabla, etc. Hasta aquí todo bien, tiempos parecidos, incluso ligeramente mejores para las queries en texto plano. Palabras mayores, paso a ejecutar un programita que realiza 100000 (cien mil) inserts en texto plano dentro de un bucle for en C#, es decir, ni más ni menos que 100000 llamadas a ExecuteNonQuery(). La ejecución tarda un rato, casi dos minutos, pero va bien, las filas son insertadas como Dios manda (¿Cómo manda Dios?).

Pasamos entonces a ver qué tal funciona lo mismo, pero haciendo una única llamada desde código al método ExecuteNonQuery(). ¿Cómo? Llamando (a gritos) a un stored procedure que realiza las mismas inserciones, aunque en un loop interno definido en el propio procedimiento almacenado, no a nivel de código cliente. ¡Vamos allá!

¡Pues va a ser que ha petado! A ver qué dice el error lanzado por el conector..."Fatal error encountered during command execution". Buff, ¡qué mal rollo Arroyo! Sinceramente, me he quedado igual o peor, no tengo ni idea de qué está pasando, y el error lanzado no es de gran ayuda, como ocurre desgraciadamente muchas veces.

Vuelvo a ejecutar varias veces lo mismo con idéntico resultado, hasta que me apiado y paulatinamente voy bajando el número de inserciones del procedimiento almacenado hasta llegar a un punto en que ¡funciona! ¿Tendrá MySQL un límite de memoria/hilos/procesos en los procedimientos almacenados? No creo..., entonces, ¿será cosa del conector? Mientras me hago esta última pregunta me quedo mirando fijamente la consola, concretamente mi atención se centra en el tiempo cronometrado (por mí) que se muestra tras el error, 30 segundos y pico. ¡Ajá! Ya caigo..., me suena que las sentencias SQL tienen un timeout, es más, me suena que ese timeout suele tener por defecto un valor de 30 segundos. Vamos a tirar de la ayuda, que para algo la suelen realizar...

Efectivamente, confirmado queda que el comando para atacar la base de datos tiene un timeout por defecto de 30 segundos, lo que implica que si el comando no termina, se dispara un error. Claro, ahora todo coincide ya que seguramente la ejecución del stored procedure dura más de 30 segundos, lanzándose la excepción nada aclarativa recibida. ¿Solución? Establecer un valor más alto para dicho timeout. Aunque no se recomienda tocar este parámetro ya que es difícil que la ejecución de una query o stored procedure dure más de 30 segundos (excepto en las monstruosas transacciones y procesos batch que realizan bancos y demás), esta vez vamos a añadir una simple línea de código C# asignando un valor entero muy alto al timeout del command, pa' cubrirnos las espaldas ;-).

Compilamos, y ¡allá vamos de nuevo!

¡Voilá! Como se puede apreciar en la imagen de arriba, las 100000 inserciones se han realizado perfectamente, en un tiempo ligeramente inferior a las 100000 inserciones realizadas "a pelo".

Como adelantaba al principio del post, aunque en este caso particular el ejemplo se ha desarrollado con el conector de .NET para MySQL, esto mismo sirve para otros conectores, tanto a MySQL, como a Oracle, SQL Server, Sybase, o el repositorio de datos que sea. De hecho, si no me equivoco, todos los conectores a base de datos vienen por defecto con un timeout por comando de 30 segundos, tiempo más que suficiente en el 99.99% de los casos, y si no anda Lonifasiko por ahí cerca con ganas de marcheta ;-).

Tened en cuenta por tanto que el timeout en los accessos a base de datos existe, y aunque rara vez se da, hay casos en los que se supera y es necesario reajustar su valor manualmente por código. Soy el primer timeout-breaker, o ¿tiene alguien alguna otra experiencia similar que contar con otro conector hacia MySQL o hacia otra base de datos? Seguro que sí...

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

CsharpRepl, shell interactivo de C#

Tras la dura resaca de mi primer cumpleaños (¡que joven que soy!), hoy lunes "de empanada monumental" toca hablar sobre las andanzas de l@s imparables chic@s de Mono, que como siempre, están que no paran. Una vez más me entero de una excelente utilidad/herramienta gracias a mi habitual lectura del blog más tirano de la blogosfera opensource .NET. Esta vez, el project leader Miguel de Icaza nos daba a conocer la utilidad CsharpRepl, que viene a ser una especie de shell interactivo de C#. En otras palabras, una parte del compilador de C# de Mono que nos permite evaluar expresiones y ejecutar sentencias contra el runtime de Mono a través de la línea de comandos.

Puede que esta utilidad no sorprenda a los habituales de ciertos lenguajes de scripting; ni tampoco a los "comodones" como yo que utilizamos Visual Studio como herramienta de desarrollo, ya que este entorno integra la siempre útil ventana de "Inmediatos", que viene a ser más o menos lo mismo que CsharpRepl. ¡Qué de alegrías nos ha dado esta dichosa ventanita y cuántas veces ha evitado que tengamos que recompilar nuestra aplicación! Aunque parezca increible, todavía hoy en día hay muchos programadores que desconocen las maravillas que encierra esta ventanita mágica que traga con (casi) todo. Es un "must-try" pero mucha gente no la conoce porque inexplicablemente viene oculta por defecto dentro de Visual Studio, ¡hay que activarla a mano! Manda huevos...

Bueno, volvamos al tema que nos ocupa, que no es otro que CSharpRepl, el shell que te evitará hacer debug 178 veces. Disponible ya en los nightly builds de Subversion a partir del día 1 de Septiembre, el comando csharp que habilita este shell vendrá ya integrado en la versión 2.2 de Mono. Aunque el equipo está abierto (como siempre) a todo tipo de sugerencias de funcionalidad a incorporar a la utilidad, de momento el shell publicado permite cargar assemblies, importar namespaces, evaluar expresiones más o menos complejas, utilizar LINQ a machete e incluso escribir pequeños programitas de varias líneas gracias a la edición multi-línea:

Admito que empezar a realizar pruebas con Mono sigue siendo una de mis asignaturas pendientes para la nueva temporada 2008/2009, pero seguro que con este tipo de utilidades y herramientas con las que nos deleita muy a menudo el equipo de Mono, mi pas(it)o al lado oscuro será algo más indoloro. Ya que estamos, para no olvidarme de mis promesas y objetivos de cara a la temporada 2008/2009, voy a empezar a utilizar CSharpRepl desde ya mismo:

csharp> var goals = new string[]{"write quick and better posts", "write posts frequently", "increase readers", "a more professional look & feel blog", "earn some money"};

csharp> goals.Add("test Mono");

Mono Team, thanks again for your time and effort.

SaludoX.

Si quieres estar meta-informado y volverte enfermo crónico vía RSS, suscríbete al Txoko de Lonifasiko .

Hotnews del Proyecto Mono

Esta semana ha sido una de las más importantes en mucho tiempo para toda la gente involucrada e interesada en el proyecto Mono. El equipo liderado por Miguel de Icaza no ceja en su empeño por lograr una implementación open source de la plataforma Microsoft .NET, con la firma idea de poder correr aplicaciones .NET bajo cualquier sistema operativo, ya sea Windows, Linux, Unix, Solaris o Mac OS X.

Decía que había sido una semana muy importante. ¿Que por qué? Porque esta semana el equipo de Mono ha hecho públicas dos noticias muy importantes que dejan bien claro el titánico esfuerzo y el arduo trabajo que está llevando a cabo esta comunidad patrocinada por Novell.

La API de Winforms 2.0 está completa

"We are API complete" anunciaba este pasado martes, de modo realmente discreto, Jonathan Pobst en su blog. Mono alcanza de esta manera, tras cuatro años de intenso trabajo, el gran hito de que su API pública de Windows Forms sea igual (exactly the same) que la API original de .NET Windows Forms, incluso con el mismo número de métodos soportados. ¿Que cuántos son? Preparaos...¡12776 métodos! No, no es el número del Gordo de Navidad; es el número de métodos que nos permiten desarrollar esas pedazo de aplicaciones de escritorio que tanto nos gustan. Sí, lo sé, estoy viendo tu cara, yo tambien he flipado...

Lógicamente, como en toda plataforma de software recién liberada, nos avisan de que puede haber bugs. De hecho, piden públicamente la contribución de la gente para testear dichas librerías y reportar cualquier fallo o comportamiento anómalo que pudiera detectarse. Este anuncio no hace sino confirmar que Windows Forms 2.0 era una de las últimas piezas clave aún por terminar para el gran puzzle que constituirá la release de la versión 2.0 de Mono. Actualmente en versión Mono 1.9.1 (denominada Mono 2.0 Beta), se prevé que en cuanto corrijan una serie de bugs que inevitablemente irán saliendo, en los próximos meses tendremos en la calle la versión 2.0 de este cross-platform framework.

Liberado el código de Moonlight

¡Quien dijo temer a un Martes y 13! La gente de Mono no desde luego, porque el mismo martes, a la par que daban el anterior notición, publicaban por primera vez el código fuente de Moonlight. Como much@s sabréis, Moonlight es la implementación open source de Silverlight, la tecnología cross-browser propietaria de Microsoft que pretende dar una vuelta de tuerca al concepto de rich web user experience. Se trata en otras palabras de que el usuario alucine cuando navega por la red, flipe con las animaciones e interactúe con el contenido multimedia que le ofrecen las webs. Se trata en definitiva de mejorar notablemente la experiencia de navegación de millones de internautas.

Tal y como anuncia Miguel, esta publicación no es ni mucho menos Moonlight 1.0, ni puede llegar a calificarse de versión beta; es simplemente la primera publicación de código fuente de Moonlight, que se puede mapear más o menos con Silverlight 1.0. La idea de esta publicación va orientada expresamente a que desarrolladores y otras personas interesadas analicen, testeen y aporten nuevas ideas. A buen seguro, la comunidad, tal y como ha hecho hasta ahora, responderá.

Futuro de Mono

Aunque llevaban mucho tiempo trabajando en la sombra sin hacer demasiado ruido, estos dos anuncios son un claro ejemplo de que el proyecto Mono sigue vivo, muy vivo diría yo. En mi opinión, esto no ha hecho más que empezar, ya que a buen seguro la próxima publicación de Mono 2.0 significará un salto cualitativo definitivo en las aspiraciones de esta plataforma, que a su vez supondrá un balón de oxígeno y el espaldarazo definitivo que necesita este proyecto y este equipo de cracks que tanto se lo están currando. Desde aquí, mis felicitaciones y millones de aplausos para todo el equipo de Mono.

Yo, aunque he hecho alguna pruebilla en plan chorra con esta plataforma, he de admitir que no me he metido a fondo con ella. Es lo de siempre: "Tengo que...pero no tengo tiempo pa...". Por tanto, añado a mi larga y extensa todo-list de este año 2008, con el check de medium-high priority activado, la tarea de probar a fondo la plataforma Mono cuando publiquen la versión 2.0. En serio, I promise...

SaludoX.

No olvides suscribirte al feed RSS para enterarte de todas las actualizaciones del Txoko de Lonifasiko .

Guía de instalación de Visual Studio 2008

Soy bastante lanzado a la hora de instalar cualquier tipo de programa en mi máquina, tanto en el curro como en casa. Esta manía o actitud (o depende cómo se mire, aptitud), tiene sus riesgos, pero soy así por naturaleza, soy un early adopter que lo prueba todo; , un conejillo de indias que le hace mil y una putadas a su PC instalando continuamente versiones Beta, Alpha, CTPs y RTMs de todo tipo de herramientas y utilidades que pilla.

Esta vez en cambio, me estaba sorprendiendo a mi mismo de lo mucho que estaba tardando en instalar Visual Studio 2008, el nuevo IDE o entorno de desarrollo de Microsoft lanzado allá por finales de Febrero. Sinceramente estaba muy a gusto con Visual Studio 2005 SP1, pero claro, no vaya a ser que me quede desfasado, fuera de la onda tecnológica, y por ello deje de ser "cool, hot y amazing". Así que esta semana me he puesto el buzo, he instalado Visual Studio 2008 y se me ha ocurrido la brillante (¿?) idea de compartir con tod@s vosotr@s todo el proceso de instalación de Visual Studio 2008, plus una serie de consejillos del abuelo Lonifasiko. Tan sólo comentar que VS2005 y VS2008 pueden convivir en perfecta armonía en la misma máquina; yo, por problemas de espacio en disco (en pleno 2008...), he "preferido" desinstalar VS2005. Allá vamos:

1.- Backup de proyectos de Visual Studio 2005. Soy lanzado pero no tonto, así que con lo baratos que están los CDs y DVDs, el primer consejo es realizar un backup de todos los proyectos desarrollados con Visual Studio 2005. Seguro que no pasa nada, pero nos curaremos en salud...

2.- Despedida de Visual Studio 2005. Abrimos por última vez (quién sabe en esta vida...) el gran (sí, gran) Visual Studio 2005.


Contemplamos "su apariencia" fijamente unos minutos, cerramos los ojos, alabamos todo lo que nos ha ayudado, nos cagamos en él por las que nos ha liado, y en el nombre de todos los IDEs...amén.

3.- Lectura del archivo readme. Será que me estoy haciendo mayor y más "segurola", pero últimamente estoy cogiendo la buena manía de abrir los archivos readme.txt, readme.html, o leeme.txt que todo software trae o debería traer. Le pego una lectura rápida en la que no veo nada raro, salvo alguna issue con las SDKs de Windows Mobile 6, cosa que apunto rápidamente para desinstalar antes de proceder.

4.- Limpieza previa a la desinstalación de Visual Studio 2005. Antes de procecer con la desinstalación de VS2005, con la idea de hacer bien las cosas y de paso "hacer un poco de limpieza" y liberar espacio en disco, he echado una ojeada a la fatídica lista de programas instalados con la opción "Agregar/Quitar programas". Después de exclamar en alto "¡qué de movidas tengo instaladas!", procedo a desinstalar "todo lo relacionado con VS2005". En mi caso, entre otras cosas desinstalo ASP.NET AJAX Extensions, el plugin MySQL Tools for Visual Studio, SQL Server 2005 Everywhere Edition CTP, el plugin AnkhSvn para trabajar contra Subversion, GPS.NET for VS2005, Enterprise Library for .NET Framework 2.0 (January 2006) y Microsoft Device Emulator.

Así mismo, fiándome del readme, por si las moscas quito Windows Mobile 6 Standard SDK y Windows Mobile 6 Professional SDK. Y ya que estamos de rebajas, por el mismo precio quito Microsoft Robotics Studio 1.5, del que ya tenemos sustituto CTP (sí, definitivamente estoy enfermo...). Lógicamente, todo esto que cuento depende de lo que tenga instalado cada uno en su máquina; yo cuento MI proceso de desinstalación/instalación.

5.- Reset. ¿Por qué? Porque yo no lo hice, y tan pronto como comenzó el proceso de desinstalación de VS2005...¡sorpresa!

¡Ah sí, ya me acuerdo! Aquellos controles que instalé cuando desarrollaba para Windows Mobile. También los he desinstalado en el paso anterior, pero por lo visto han dejado "su particular huella" en el registro de Windows., o donde sea. Por eso, después de haber desinstalado muchas cosas (entre 10 y 15) ...seguro que un buen reset no viene mal.

6.- Desinstalación de Visual Studio 2005. "Definitivamente te voy a echar de menos compañero...":


Pulsamos "Aceptar" con la lágrimilla en los ojos, y tras un buen (repito, un buen) rato...

La desinstalación termina y nos avisa de que puede haber otros componentes que requieran de una desinstalación manual. Ya puestos a tunear la máquina, me cepillo MSDN 2005, Microsoft Document Explorer 2005 y Microsoft Visual Studio 2005 Tools for Office Runtime.

6.- Instalación de Visual Studio Team System 2008 Development Edition. Nombre más largo no pueden sacar no...

Decimos unas cuantas veces amén (= pulsar "Next"), configuramos la instalación (de momento nunca he utilizado Crystal Reports)...

...y tras otra larga espera (menos mal que dejé de fumar...), pantalla de "instalación ok"...

...y tras pulsar victorioso "Finish", el típico "messagebox maligno"...

...que visto lo ocurrido en el Paso 5, me "invita" a hacer un...

7.- Reset. Pues eso, ¡reset!

8.- Visual Studio 2008 ready to go! Como esta vez he decidido que de momento no voy a instalar en local la ayuda de MSDN 2008 (el que quiera, que la instale), ¡despegamos! Selecciono en mi caso "C# a muerte"...

...and ¡we're in!


9.- Tomaros una buena cerveza (o lo que queráis), que os lo merecéis, este proceso agota.

Como he dicho antes, este proceso de desinstalación de Visual Studio 2005 e instalación de Visual Studio 2008 es relativo a MI máquina. Con ello os quiero decir que si alguien sigue esta "mini guía" (por llamarla de alguna manera) y no consigue instalar ni desinstalar todo lo que quiere, le cae un rayo al salir de casa, se le rompe la máquina, o la abuela fuma, me podéis escribir un comentario diciendo que no os ha funcionado (e incluso que soy un paquete), pero en absoluto me hago responsable de nada de nada. Si es que parezco un abogado ;-)

Por cierto, espero que lo aquí contado le sirva de algo a alguien. Ésa es la intención...

SaludoX.

DOR: Debug Or Release

El mismo colega (¡suerte en tu nueva etapa campeón!) que sacaba a la luz las carencias del método String.Replace me ha vuelto a poner a prueba con otra duda existencial sobre el fascinante mundo de Microsoft .NET y Visual Studio. No sé cómo lo hace, pero al final siempre consigue que me ponga cabezón y me pique con estos "retos tecnológicos" que me plantea:

Colega: "Miguel, ¿cómo puedo saber, sin tener el código fuente, si un ensamblado .NET, bien sea un .exe o una .dll que me han pasado, está compilada en modo debug o release?"

Miguel (con cara de póker...): "Joder tío, es que te pasan unas cosas...me vienes con cada preguntita...en serio, acabas antes si escribes un libro tronco..."

Colega: "¡Ja, te he vuelto a pillar tío! No, en serio, tranqui, no te piques ni pierdas tiempo con ello, era por si te sonaba alguna forma rápida de poder saber eso..."

Como me jode no poder ayudar a un compañero con una duda que a priori parece tan sencilla y evidente. ¿Que no pierda tiempo, que no me pique? No sabes lo que estás diciendo chaval...acabas de herir mi orgullo informático hasta lo más profundo, ese orgullo friki con tintes de batalla y autosuperación que todo informático posee (aunque algunos no lo saquen a relucir). Y es que si no fuera por estas aventurillas y mini-retos, ¿qué sería de la triste vida de un informático? Vamos allá...

Mirando por Internet y todavía con el orgullo malherido, en seguida encuentro este post que explica de maravilla cómo diferenciar las versiones debug y release. Una vez más, se cumple el principio básico de todo error o duda informática: "Mira por Internet, seguro que antes que a ti le ha pasado a alguien...".

Como bien indican en ese útil post, para saber si una librería o ejecutable .NET (hablamos siempre de managed code) está compilado en modo debug o release, sólamente hace falta leer los atributos del ensamblado (librería o ejecutable) en cuestión. Fiándome 100% de lo que dicen, basta con mirar el valor del atributo IsJITTrackingEnabled; si está a true, la .DLL o el .EXE están compilados en modo debug; si está a false, se trata de una versión release.

Para leer los atributos de un ensamblado .NET (.NET assembly), tenemos varias posibilidades:

• Utilizar alguna utilidad gratuita como Reflector for .NET. ¡Qué gran utilidad!
  
• Complicarse la vida y hacerlo mediante código .NET, cargando dinámicamente la assembly en cuestión y analizando sus atributos "al vuelo".

Al no tener nada mejor que hacer en este frío y lluvioso Domingo de Pascua (¡qué triste!), y porque en el fondo soy un "batallador informático" (¿?), he cogido prestado parte del código expuesto en el post del amigo Jim, y me he currado una pequeña utilidad que a través de una interfaz gráfica muy sencilla nos dirá si un ensamblado .NET está en versión debug o release. Ésta es la apariencia inicial de la aplicación:


Si pulsamos el botón saldrá un cuadro de diálogo donde podremos seleccionar el ensamblado .NET que queremos chequear:

Y poco más...una vez seleccionado el ensamblado .NET, la utilidad nos mostrará de forma gráfica si se trata de una versión debug (como en la imagen) o release:


Indicar que la aplicación sólo funciona para ensamblados .NET, es decir, para managed code, y que tan sólo necesita tener instalado .NET Framework 2.0 en vuestra máquina (lo tendréis ya instalado...). Os dejo tanto el ejecutable, como el código fuente de la utilidad (proyecto de Visual Studio zipeado) en mi espacio de SkyDrive.

Para aquellos temerosos del malware creado por desconocidos como yo, deciros que la utilidad es totalmente inofensiva; no os va a formatear vuestro disco duro, ni va a recopilar las credenciales de vuestra cuenta de GMail; como mal mayor, la aplicación pegará un pete brutal y os dejará con la miel en los labios, sin saber si el ensamblado era debug o release; lo siguiente será cagarse en mí mil veces y escribir un comentario en el post diciendo que soy una paquete ;-). ¡Pues vale! ¡Qué le vamos a hacer! Se aceptan todo tipo de críticas y comentarios...es la dura vida del blogger informático ;-)

SaludoX.

Migrando aplicaciones .NET a 64 bits

¡Quien me iba a decir a mí que hoy lunes iba a tener ocasión de trastear con un Windows XP de 64 bits! ¿Qué pasa? Pues no, hasta hoy no lo había probado, ¿y? La diferencia con el Windows XP Professional "de toda la vida" (el de 32 bits) es que éste limita la memoria física y virtual a 4Gb, mientras que esta versión con instrucciones de 64 bits a priori sube el techo hasta los 128 Gb, con lo que si te lo propones, tienes slots y sobre todo, un buen bolsillo, puedes acabar con toda la RAM de la tienda de informática de tu barrio.

El caso es que me han encomendado probar en dicha máquina por temas de compatibilidad, algunas aplicaciones software que se han desarrollado recientemente, en especial, una aplicación Windows Forms (C# con .NET Framework 2.0) que se pelea a través de una serie de formularios contra una base de datos Access muy sencilla.

Suponía que iba a haber algún que otro problemilla, y os adelanto, que los ha habido. Seguramente será porque después de copiar todos los archivos de la aplicación al nuevo pepino no he rezado lo suficiente a la patrona de los informáticos, Santa Tecla. El caso es que según he hecho doble clic en el .exe......cataclón:

Como la aplicación trabaja contra Access a través del driver OleDB, utilizando el motor de base de datos Microsoft Jet 4.0, he pensado que simplemente tendría que registrar (con el comando regsvr32) alguna DLL o como mucho, instalar una versión de dicho motor compatible con arquitecturas de 64 bits. He ido raudo y veloz a Google, y como siempre, he respirado hondo al ver que una vez más, se ha cumplido la máxima del programador: "siempre hay alguien a quien le ha pasado lo mismo antes que a ti". Y por lo visto, la solución no era instalar una versión específica de Microsoft Jet 4.0 para arquitecturas de 64 bits (de hecho no la hay...), sino simplemente cambiar el target platform de la aplicación desde el propio Visual Studio 2005, tal y como se suele hacer con los proyectos para dispositivos móviles desarrollados con .NET Compact Framework, donde tan pronto cambiamos de PocketPC 2003 a Windows Mobile 5, como de WM 5.0 a WM 6.0.

Así que nada, empezando a digerir una nueva lección impartida por el Profesor Internet, abrimos la página de propiedades del proyecto de Visual Studio 2005, donde vemos que el proyecto está compilado para "Any CPU", la configuración por defecto para cualquier proyecto:

Pero claro, nuestro proyecto no es "cualquier proyecto", es una aplicación que ha de correr tanto en 32 como en 64 bits. ¡Ahí es nada! Pues bien, es tan fácil como desplegar la combo de target platform, seleccionar x86, guardar los cambios y compilar:

Al querer que la aplicación corra en 64 bits, más de uno (me incluyo) hubiera seleccionado ipso facto x64 en vez de x86, acción muy lógica, pero errónea. Seleccionando x86, estamos indicando que independientemente de la arquitectura y bits que tengan las instrucciones de la máquina, esta aplicación es una aplicación específica para plataformas x86, es decir, ha de correr en un entorno de ejecución gobernado por instrucciones de 32 bits. Y para ello, Windows XP Professional x64 Edition trae un emulador para x86 denominado WOW64, el cual permite correr aplicaciones de 32 bits sin problemas en una arquitectura Windows de 64 bits. ¡A tope!

Tan sólo queda copiar los archivos generados en esta compilación "especial" a la máquina destino y rezar 64 plegarias a San Blador (Santo de los programadores). Con la aplicación funcionando perfectamente sobre un Windows XP de 64 bits (lógicamente sigue funcionando para 32 bits), si vamos al task manager podremos ver que el identificador del proceso lleva la coletilla "*32", señal inequívoca de la naturaleza de la aplicación:

Una vez más, lección realmente interesante y productiva la de hoy, me voy tranquilo y muy contento a la camita. SaludoX.

El rebaño de ovejas de Artalde

Llevo un semestre escribiendo en el blog (6 meses ya desde aquellas primeras promesas) y todavía no he hablado de Artalde. No me lo puedo creer....aunque adivino que nueve de cada diez lectores de este post se estarán preguntando ahora mismo qué es Artalde. Bien, simple y llanamente, Artalde es el grupo de usuarios de .NET de Euskadi. Para los más curiosos, comentar que el nombre de "Artalde" viene del euskera, y significa "rebaño de ovejas", así que Artalde viene a ser más o menos el rebaño de ovejas .NET-eras de Euskadi, ovejas que por supuesto cuentan (contamos) con el label vasco de calidad ;-).

Al igual que muchos otros grupos de usuarios que se han creado en España alrededor de la tecnología Microsoft .NET, Artalde pretende de alguna manera agrupar y organizar a todas aquellas personas de Euskadi y alrededores que tengan especial interés, debilidad o pasión por esta tecnología.

Con el objetivo de "hacer piña" y sobre todo potenciar la comunicación entre desarrolladores, el grupo suele organizar charlas y sesiones técnicas periódicamente, teniendo normalmente los eventos lugar en la Universidad de Deusto, en el Aula de Videoconferencia, en la segunda planta del edificio ESIDE. Si no me equivoco, ha pasado ya más de un año desde la creación de Artalde, y hay que decir que las sensaciones del grupetto son muy buenas; se están organizando eventos con bastante asiduidad y la respuesta de la gente está siendo muy positiva.

No hace falta ni decir que el grupo está totalmente abierto a que cualquier persona se anime y se "suba al estrado" para compartir su conocimiento en la materia; da igual que sea sobre ASP.NET, Silverlight, Windows Communication Foundation, desarrollo para Windows Mobile con .NET Compact Framework, Microsoft Robotics Studio...ya veis todo lo que engloba el mundo de la tecnología Microsoft .NET, hay para dar y tomar. De momento, los más animados están siendo Rodrigo Corral, crack y ex-compañero mío, e Ibon Landa, otro de los grandes impulsores del proyecto Artalde. La verdad es que se lo están currando...además, de vez en cuando, cuando las agendas lo permiten, suele acercarse gente de la propia Microsoft a impartir alguna que otra sesión, lo que nunca viene nada mal.

Sinceramente, ya que a nivel profesional es materialmente imposible abarcar todo el abanico de tecnologías disponibles hoy en día, asistir a las charlas de Artalde es una muy buena manera de mantenerse al día en tecnología Microsoft .NET, para que por lo menos "las siglas te suenen", además de poder conocer y entablar relación, incluso profesional, con mucha gente del "mundillo .NET".

Paralelamente a la página oficial de Artalde, la gente del grupo utiliza activamente el correspondiente grupo de Google, donde se lanzan preguntas al aire, dudas, se anuncian los eventos y se cuelgan presentaciones y demás material.

Lo dicho, os animo a uniros al grupo y a asistir y hacer un poco de ruido en todos los eventos que se organicen.

SaludoX.

Interoperando con Ikvm

Interoperabilidad. Qué palabra tan bonita, y ¡que bien suena! Es una de las múltiples palabras que utilizan los comerciales informáticos (podríamos escribir una enciclopedia) a la hora de "vender proyectos". En el mundo de la programación casi siempre se relaciona interoperabilidad con una batalla campal entre Microsoft .NET y Java, las dos plataformas reinas del mundo de la programación informática. Se han escrito ríos (más bien océanos) de tinta con estudios comparativos entre estos dos poderosos frameworks, siempre intentando desestabilizar o buscar puntos débiles en uno u otro bando.

Este contencioso internacional de la programación tiene pinta de seguir abierto "per secula seculorum" (es como Irak, Palestina, Afganistán y estos países...), complicando enormemente la vida a los programadores, generando desconfianza en las empresas cliente, y emborronando el ya de por sí maltrecho mundo de la informática en general. Siempre se oye hablar de herramientas bridge o cross-platform que a cambio de un buen puñado de dólares prometen el oro y el moro en cuanto a interoperabilidad se refiere. Para el caso concreto de limar asperezas entre .NET y Java, acabo de descubrir el proyecto opensource Ikvm. Una vez más, me quito el sombrero ante proyectos desinteresados de este tipo que alumbran el oscuro mundo de la interoperabilidad. A grandes rasgos, el proyecto Ikvm:

• incluye una implementación .NET de una Java Virtual Machine
• permite utilizar librerías java desde aplicaciones .NET
• facilita el desarrollo de aplicaciones .NET en Java

Sobre todo me llamó la atención el segundo punto, el poder "jugar" con una librería de Java desde una aplicación .NET. Hay muchas librerías potentes de Java que no tienen su implementación en .NET; es en estos casos donde Ikvm puede echarnos una mano (¡y no al cuello!). Así que nada, me he bajado la conocida librería de data mining Weka, en formato .jar y aquí os detallo la experiencia religiosa que he tenido con Ikvm:

• Lo primero de todo es convertir con el comando ikvmc la librería weka.jar a weka.dll, libreria directamente accesible desde .NET:

En la siguiente imagen se puede apreciar que la nueva librería weka.dll ocupa casi el doble que la original weka.jar, pero bueno, estamos en versión beta, ¿verdad? ;-)

• El siguiente paso es abrir un proyecto con Visual Studio o MonoDevelop (si utilizamos MONO), y añadir una referencia a la recien creada weka.dll y otra a la librería propia de Ikvm denominada IKVM.OpenJDK.ClassLibrary.

• Una vez aquí, el límite lo pone vuestra imaginación. Toda la funcionalidad de una compleja librería Java fácilmente accesible desde el entorno .NET. Como si queréis empezar a probar redes bayesianas de Weka...¡todo vuestro!
  

Os puedo asegurar que un colega del curro ha utilizado satisfactoriamente Weka desde una aplicación .NET. ¿Rendimiento? No he realizado ningún test, pero todo sabemos que esta clase de "puentes" siempre conllevan cierta penalización; no va a ser todo gratis ;-)

SaludoX.

.NET Tip of the Day

No sé qué leches andaba mirando por Internet el otro día, cuando por casualidad aterricé en una página en la que cada día comentan un tip diferente relacionado con .NET. Me pareció curiosa y acabé leyendo un par de tips sobre cómo acelerar el launching del VS2005 y cómo sacarle chispas también al VS2005. Ya sabéis, cuando no hay más RAM, uno se las ingenia cómo puede ;-)

Seguro que estáis pensando en la típica ventanita con el terrible "Did you know..." o "Tip of the day..." que suelen traer muchos programas. Sí, esas ventanitas en las que todo el mundo desmarca el checkbox en el que pone "Show always tips on startup". A ver, está claro que este tipo de cosas pueden llegar a cansar; yo, de momento, para no tener que visitar la página de marras everyday, me he suscrito vía RSS y así, de vez en cuando echas un vistazo a tu lector RSS favorito y listo. Con algo de suerte, puede que aprendas una cosa nueva (o no), y te vayas (más) contento (o no) a la cama.

SaludoX.

MS liberará código del .NET Framework

MS acaba de hacer público que va a liberar parte del código del .NET Framework. ¿Comorrrr? Que sí, que va en serio. Lo van a liberar bajo un formato de licencia denominado Microsoft Reference License (MS-RL), licencia que todavía no me he atrevido a leer ;-)

Pero bueno, es sin duda una buena noticia. Este anuncio implica que los developers podremos en un futuro bajarnos, "bucear" e incluso hacer debug por las entrañas del .NET Framework. Será posible con .NET Framework 3.5 y Visual Studio 2008 CodeName "Orcas".

Aunque sólo sea por curiosidad, os imagináis la cantidad de llamadas y demás cosas que implica un simple binding de una fuente de datos al típico control DataGrid (2 líneas de código en C#). Pues señoras y señores, ¡ahora lo vamos a poder ver! ¡Uf! Me da hasta miedo ;-)

Podéis encontrar más información aquí.

SaludoX.