Oracle compra Sun (y MySQL)

El índice Nasdaq ha temblado, digo se ha tambaleado, hoy más que nunca, y no precisamente por culpa de la crisis. Gracias a un tweet de Kirai, al mediodía me enteraba de la rápida y sigilosa maniobra empresarial consumada con "alevosía y nocturnidad" hoy mismo por el gigante Oracle. En lo que se ha convertido probablemente en la noticia tecnológica del día y del mes, Oracle ha anunciado públicamente (puede que la web esté caída) haber llegado a un acuerdo para la compra de Sun Microsystems por un valor aproximado de 7400 milloncejos de dólares, vamos, calderilla para tipos como yo ;-).

Si bien ya se habían hecho públicos ciertos movimientos y reuniones entre sheriffs de IBM y Sun durante las últimas semanas, este repentino anuncio de adquisición por parte de Oracle creo que ha pillado totalmente desprevenid@ a mucha más gente de la que podíamos llegar a imaginar.

La duda que asola Internet a esta hora reside en las implicaciones que tendrá esta vertiginosa pero inteligente maniobra en dos de los "productos estrella" de Sun, hablo, como no, de Java y de MySQL. Personalmente no espero demasiados cambios ni licencias más restrictivas en la tecnología Java que Sun "liberó" hace algún tiempo, el enfado de la community podría ser de los que hacen época e historia.

Respecto a MySQL, cuya adquisición por parte de Sun anuncié en este blog hace poco más de un año, por el momento todo el mundo dice que MySQL va incluída en el intercambio de cromos. Creo que ésta es sin duda la parte más inteligente de la operación realizada por Oracle, donde se me empiezan a ocurrir múltiples combinaciones y jugadas.

A día de hoy puede que MySQL no sea competencia directa de Oracle, pero doy por descontado que una de las grandes razones para que Oracle haya comprado Sun es precisamente MySQL y su excelente rendimiento y progresión en los últimos años. Si bien todo el mundo está hablando del jugoso pastel llamado "Java" del que Oracle acaba de apoderarse, yo me arriesgo y apuesto por MySQL como principal activo de la compra, tecnología en la que a buen seguro Oracle ha visto cosas que le pueden interesar sobremanera de cara al futuro.

¿Y ahora qué? ¿Tendremos un mix denominado MyOracle o apostarán por Oracle como sistema de base de datos comercial y seguirán ofreciendo MySQL como base de datos opensource? Sun tampoco lo hizo, con lo que no creo que Oracle se atreva ahora a quitar el rasgo opensource que ha caracterizado a MySQL desde sus inicios. Yo desde luego espero seguir viendo por mucho tiempo el adjetivo Community Edition al lado de la marca MySQL. Como siempre, lo veremos, o en su defecto, lo leeremos ;-). Señoras y señores, hagan sus apuestas...

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 .

MaxPermSize reserva memoria permanente

El lunes os hablaba de un intercambio de mails curioso gracias a la inmediatez e importancia de Twitter, anécdota que venía precedida por la mediocre impresión que me causó la live demo de JBoss Portal. Esto no podía quedar así, por ello, para quitarme el mal sabor de boca tecla, tal y como le prometí al amigo Tomás, hoy he sacado un ratín para hacer mis primeros pinitos con JBoss Portal. Las de hoy no han sido pruebas exhaustivas, pero la impresión a decir verdad sigue siendo mala no muy buena. Ahora explico por qué...

El primer paso ha sido bajarme un bundle o paquete que ya contiene una instancia preconfigurada de JBoss Portal 2.7.0 GA "desplegada" (I mean deployed...) bajo un servidor de aplicaciones JBoss 4.2.3, otro producto cañerito del fructífero matrimonio JBoss-RedHat. Como ya he aprendido la lección, ahora soy de los que empiezan por leerse el típico quickstart o manual de referencia con las acciones básicas para saber por dónde agarrar el embolao. Por lo que dice en el documentillo, tan sencillo como descomprimir el archivo descargado, acceder a la carpeta "bin" y ejecutar el típico run.bat si estamos en Windows (es el caso) o run.sh si estamos enel lado oscuro ;-), es decir, lo de siempre. Ésta es una de las cosas buenas que tienen los proyectos opensource, más concretamente, los proyectos relacionados con Java: la forma de arrancar un servidor de aplicaciones, el proceso de deploy de las aplicaciones, e incluso la estructura de directorios y el nombre de los archivos, es muy parecido casi siempre, con lo que en poco tiempo te quedas con la idea general. Lo dicho, que la idea está asumidisima hace tiempo, en cambio...

Como se aprecia en la imagen, en el log del servidor de aplicaciones JBoss, la flecha roja indica que JBoss AS ha arrancado sin problemas. Normalmente, ver un mensaje de este tipo en la consola suele indicar que el servidor está listo para que le den cañita brava. Precisamente eso es lo que he hecho, ya que siguiendo el manual, he accedido directamente a la URL inicial de JBoss Portal, http://localhost:8080/portal, con toda la ilusión del mundo por ver mi tesoro, digo, mi portal, en acción. Para mi desesperación, tanto Firefox como Explorer no son capaces de mostrarme nada, con lo que vuelvo a la consola para comprobar que los errores de tipo OutOfMemory campan a sus anchas por JBoss AS. En serio, no acabo de entender eso de que te bajes una demo preconfigurada de Internet, sigas las instrucciones de pé a pá, la arranques como Dios manda, y no veas nada, sólo las típicas y feas excepciones lanzadas por Java; I can't believe my eyes...

Menos mal que el texto OutOfMemory lo dice todo, con lo que en seguida he ido a inspeccionar el contenido del fichero run.bat, que es donde se le indica a JBoss qué JDK utilizar, qué variables de entorno configurar, y lo más importante, con cuánta memoria arrancar y el  máximo a reservar. Claro, en seguida veo la línea que puede estar dando guerra:

Traduciendo esto a lenguaje pseudo-natural: JBoss AS inicia (-Xms) el heap o cantidad de memoria reservada para la Java Virtual Machine a 128 Mbytes de RAM, permitiendo que este tamaño de pila o heap crezca hasta un tamaño máximo (-Xmx) de 512 Mbytes. ¡Pues parece que el niño no tiene suficiente!

Siguiendo los sabios consejos del compi situado a mi izquierda, el primer intento es equiparar el mínimo de memoria necesaria con el máximo permitido, es decir, poner los dos parámetros a 512. Reinicio de JBoss AS...,¡qué va, tampoco carbura! Entra entonces en liza desde el lejano Oeste, un nuevo consejo que acepto de muy buen grado: mantener equiparados los parámetros inicial y máximo, y probar fortuna con el parámetro MaxPermSize, un parámetro que sin saber a ciencia cierta a qué hace referencia exactamente, sabemos que ha dado buen resultado en otras ocasiones digamos que problemáticas ;-). Por tanto, la línea relativa a asignación de memoria de JBoss AS del fichero run.bat queda de la siguiente manera:

set JAVA_OPTS=%JAVA_OPTS% -Xms512m -XX:MaxPermSize=256m -Xmx512m

Se arranca de nuevo correctamente JBoss AS, accedo a la URL inicial..., ¡y por fin veo la luz! 

Qué bonito, ¿eh? Por fin tengo JBoss Portal up and running para exprimirlo y evaluarlo hasta límites insospechados, en otras palabras, listo para hacerle mil y una putadas ;-). 

Le debo una a mi compi, y otra a MaxPermSize, que según lo que explican claramente en esta página, indica el tamaño máximo de la memoria non-heap (también conocida como PermGen), en definitiva, el tamaño máximo de "memoria permanente" asignada a la JVM. 

Esperad, que ahora que tengo a JBoss Portal vivito y coleando, llega la prueba de las pruebas, una pequeña maldad que sólo se le ocurre a usuarios cabrones y enrrevesados como yo: Paro JBoss AS, mato el  proceso java.exe que anda dando vueltas por ahí, vuelvo a editar el fichero run.bat para dejarlo tal y como venía "de fábrica"(set JAVA_OPTS=%JAVA_OPTS% -Xms128m -Xmx512m), arranco de nuevo JBoss AS con esta nueva configuración y..., ¿qué creeís que ha pasado? Lo que me temía, aunque no me explico por qué, JBoss Portal ahora funciona de perlas, cuando la primera puesta en marcha tras la descarga inicial ha sido un auténtico desastre.

¿Explicación? Lo único que se me ocurre es la NO volatilidad del parámetro MaxPermSize, es decir, visto lo visto, entiendo que MaxPermSize modifica la memoria permanente asignada a la JVM, y JVM guarda (en este caso) esta configuración entre distintas sesiones o arranques, dándole igual que el parámetro desaparezca del run.bat y que se termine el proceso java.exe por las bravas. En otras palabras, un parámetro muy a tener en cuenta a la hora de lidiar con problemas de memoria muy típicos de las aplicaciones Java.

¿Conclusión? Aparte de la lección del parámetro MaxPermSize, y aunque al amigo Tomás no le haga gracia, he de decir que JBoss Portal se está cubriendo de gloria conmigo; no es normal que te bajes una demo configurada y que eso no funcione ni a tiros. Es más, diría que JBoss Portal está a puntito de ingresar en la "lista negra de Lonifasiko", de la que, aviso para aplicaciones navegantes, es realmente difícil salir ;-).

SaludoX.

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

Eclipse diferencia plugins de dropins

Si hay una cosa que me fascina de los proyectos opensource es la gran capacidad que tienen para admitir "cambios en caliente" así como las facilidades que ofrecen para mejorar la experiencia del usuario gracias a los plugins y extensiones. Normalmente es tan sencillo como descomprimir un archivo bajo cierto directorio, como mucho tocar un fichero de configuración XML, y ¡voilá! Plugin funcionando perfectamente a las mil maravillas. Como digo, me encanta esa filosofía de intentar hacerlo todo más fácil y configurable para el usuario.

Este modo de funcionamiento, o mejor dicho, esta filosofía de desarollo, se personifica claramente en proyectos de la talla de Mozilla Firefox o Eclipse. Sin ir más lejos, en este último proyecto, ¿qué desarrollador no conoce la subcarpeta "plugins"?

Esta mítica y mística carpeta es el máximo exponente de lo que puede llegar a ser un auténtico repositorio de extensiones super útiles que nos permiten desarrollar todo tipo de aplicaciones software bajo este excelente IDE. Además de poder desarrollar en el sempiterno Java, estos addins nos permiten programar en C++, Python, crear aplicaciones para la plataforma J2ME, para la tan de moda Android, Pentaho BI, etc. Eclipse se ha convertido en los últimos años en el IDE opensource más versátil, plural y configurable en la historia del desarrollo del software. Que conste que yo soy de la "escuela Visual Studio", que dicho sea de paso, es una maravilla, pero he de admitir que Eclipse está muy pero que muy bien.

Total, que andaba yo la semana pasada con ganas de trastear con Google Web Toolkit, un web framework del que había oído hablar que permitía desarrollar de forma muy sencilla, en Java, aplicaciones AJAX visualmente muy ricas. Como neanderthal que soy y porque me gusta ver las tripas de todo, primero probé los ejemplos sencillos "por fuerza bruta", invocando el runtime de GWT a machete, por línea de comandos; sin embargo, como supondréis, en los tiempos que corren, lo lógico es desarrollar aplicaciones GWT de forma algo más visual, por ejemplo, con el plugin actualmente disponible para Eclipse, denominado Cypal Studio for GWT.

Haciendo de nuevo el cavernícola y sin leerme el correspondiente manual de instalación, me bajo el plugin del invento y lo descomprimo bajo el directorio "plugins" que tanto adoro. "¡Pues vaya mierda, esto no funciona!" pienso al arrancar Eclipse y ver que no hay rastro del Cypal Studio éste. Empiezo a leer la documentación (como debía haber hecho desde el principio...) y en seguida me me topo con el requirement de que se ha de utilizar la versión Eclipse IDE for JEE Developers y como versión base mínima, Eclipse 3.3, requisitos que no cumplo ni de lejos con mi ya anticuado y clásico Eclipse 3.2.2. Toca actualizarse por tanto a la versión 3.4 de la plataforma, conjunto de releases denominadas con el codename de Ganymede.

Más de lo mismo, queda confirmado que Lonifasiko es el único animal que tropieza más de dos veces con la misma piedra: instalo la versión de Eclipse requerida, copio los tres ficheros .jar que componen el plugin bajo "Eclipse\plugins\", arranco de nuevo el entorno con "eclipse -clean" y... nueva decepción, no tengo plantillas GWT ni posibilidad de configurar en "Preferences" el flamante kit de desarrollo web de Google. ¿Lo siguiente? Lo típico, repetir los pasos anteriormente realizados con más cautela y prestando más atención a lo que estamos haciendo: cerrar Eclipse por si las moscas, borrar los .jar, volver a bajarme el .zip, descomprimir bajo el directorio "plugins" por sexta vez, y otro arranque en limpio del IDE. ¡Qué va, no hay manera!

Resignado (y de muy mala leche), acudo de nuevo a las instrucciones, aguanto como un titán párrafo tras párrafo, hasta que hacia el final de la página leo una nota relativa a las versiones Ganymede de Eclipse; esto seguro que me interesa...¡vaya que sí me interesa! La primera línea lo dice bien clarito: a partir de las versiones Ganymede, es decir, 3.4 y superiores, la forma de instalar los plugins se ha cambiado. Leo por ahí que ahora, el directorio plugins sólo va a admitir plugins en los que confía, es decir, de fabricantes más o menos fiables, seguros, "coleguitas". Esto implica que "los otros plugins", los plugins no oficiales, irán obligatoriamente bajo la carpeta dropins, teniendo que crear a mano incluso su propia estructura de directorios.

¡Manos a la obra! Siguiendo las instrucciones, creo bajo "Eclipse\dropins" una carpeta denominada "Cypal", y dentro de ésta, otra carpeta denominada "plugins" (lo sé, ¡menudo lío!). donde planto los tres .jars que tanta guerra me están dando:

Vuelta a arrancar por enésima vez Eclipse "a ras" y ya tenemos, por fin, el plugin de Cypal Studio ready para perrear con el super entorno de Google Web Toolkit:

Así que ya sabéis, con versiones de Eclipse 3.4 o superiores (cualquier release de Ganymede o superior), si el plugin a utilizar es "no oficial", olvídate del directorio "plugins" de toda la vida y pásate a "dropins", que la cosa se ha puesto seria y Eclipse ya no se fía ;-).

SaludoX.

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

Entregar o no el código fuente

Hoy domingo, voy a intentar, por una vez en la vida del blog, escribir un "post-pregunta" corto y un tanto controvertido. Me interesa más que nunca conocer la reacción y pensamiento de los frequent readers del blog, con lo que espero que el tema se debata en profundidad en los comentarios.

Allá voy: ¿Hay que entregar el código fuente de una aplicación software al cliente? Aunque parezca algo trivial, os juro que el asunto de la entrega del código fuente siempre es algo peliagudo. No me refiero a distribuir las librerías opensource o cierta funcionalidad de un software propietario que se ha utilizado en el desarrollo de la aplicación, ya que ahí entramos en el complicado terreno de los miles tipos de licencias específicas que existen a día de hoy. Librerías aparte, me refiero a la entrega del código fuente de la aplicación en su conjunto, al "conocimiento adicional y específico" generado para el cliente, en pocas palabras, la base, el "corazón" de la aplicación.

Digo controvertido, porque muchas veces directamente este punto o término ni siquiera se especifica en el contrato formal con el cliente; un vacío "legal" muy peligroso, ya que la empresa desarrolladora dirá que no tiene por qué darlo, mientras que el cliente, al ser el pagador, dirá que tiene derecho a él.

Pienso por tanto que la entrega o no entrega del código fuente es un punto que se ha de especificar claramente en el contrato que se firma con el cliente; conviene hacerlo porque luego siempre hay confusiones, malentendidos y malos rollos entre las partes implicadas, y tampoco es plan..., por lo que es mejor dejar todo "atadito" incluso antes de empezar a tirar las primeras líneas de código. En caso de acordar la cesión del mismo, opino también que dicha entrega de conocimiento debe de alguna manera facturarse; y si no se especifica nada, sorry but there is no source code, así de simple.

La pregunta que os dejo hoy es bien clara y obvia: ¿Qué opináis al respecto? ¿Qué soléis hacer en vuestros proyectos, en vuestra organización? La piedra está lanzada...

SaludoX.

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

G1 con Android a la romana

Google últimamente está cogiendo prestada demasiadas veces la frase "Veni, vidi, vici" del grandísimo Julio César. Se planta ante un montón de periodistas e internautas, les mira a los ojos fijamente, y les dice ejerciendo de pater nostrum de la red: "Éste es mi nuevo caballo ganador"; y a continuación muestra el producto o servicio de turno dejando perplejo a medio Internet. Si hace poco fue Chrome, ayer le tocó el turno a la presentación oficial del primer smartphone con sistema operativo Android, el denominado T-Mobile G1:

Sí señor, ya está aquí, ya llegó, pero...¿ya barrió? No, por el momento no. Lo de ayer ha sido simplemente un pasito, un avance muy importante en lo que a sistemas operativos opensource para dispositivos móviles se refiere. De la presentación de ayer hay que quedarse con eso: que el software que movía el hardware de la dichosa maquinita era opensource, ni más ni menos que Android, y el bicho parecía bastante ágil. ¿Y lo demás? Nada nuevo, porque el hardware presentado no es nada del otro mundo, de hecho, HTC tiene terminales mucho mejores actualmente en el mercado.

No lo llaméis "Gphone" (por favor...)

Aunque el nombre del terminal no ayuda nada con la "G" de Google bien presente, quería aprovechar este post para desmitificar lo que mucha gente erróneamente conoce ya como Gphone. Aunque mucha gente piensa que es un teléfono creado por Google, que quede claro que el nuevo caballito ganador de marras está fabricado por HTC, siendo su nombre en clave hasta hace bien poco HTC Dream. ¿Por qué entonces lo de Gphone que tanto se oye? Porque el terminal ayer presentado se ha tuneado para los servicios de Google (Google Maps, Gmail, GTalk, etc.) y porque lleva como S.O. Android, un proyecto que mucha gente asocia muy equivocádamene sólo con Google, cuando es un proyecto impulsado por la Open Handset Alliance. También Google forma parte de esta alianza, pero también es verdad que hay otras muchas compañías del mundo de las telecomunicaciones y del software involucradas ($$$) en el proyecto. Por tanto, aunque no hay que quitar cierto mérito a Google por ser una de las grandes impulsoras del proyecto Android y sobre todo, de su SDK para desarrolladores, creo que también deberáimos mencionar al resto de empresas de la Open Handset Alliance. Como habréis notado, lo del nombrecito del "Gphone" es un asunto que me quema bastante...¡tampoco es plan acaparar todo señores Sergey y Larry!

¿Y ahora qué?

Puntualizado el asunto (¡qué a gusto se queda uno después de no hablar bien de Google!), creo que la presentación de ayer viene a completar el amplio abanico de posibilidades actuales en el mundillo de los dispositivos móviles. Hablé en su día de que este año se presentaba calentito y visto lo visto, no andaba muy mal encaminado. El panorama actual y futuro inminente es el siguiente: El iPhone 3G lleva tiempo dando guerra, los nuevos dispositivos con Windows Mobile 6.1 de HTC van muy finos y ahora sale este G1 que abre la caja de Pandora. Por si fuera poco, no olvidemos que Windows Mobile 7 está ya en camino (aunque con algo de retraso), y que el Nokia Tube estará entre nosotros muy pero que muy pronto. ¿Qué significa esto? Guerra, guerra de la buena, de la que nos gusta a los usuarios, ésa que abarata los precios un montón y que te permite comprar gadgets más o menos "asequibles" ;-).

Volviendo a la cita histórica del principio, creo que Google acabará cambiándola, o al menos, acabará cambiando el orden de las palabras de la cita para convertirla en "vidi, veni, vici". La razón es sencilla: En Google, primero ven (porque tienen muuucha visión de negocio), luego desarrollan y vienen (porque tienen recursos, son rápidos y buenos), y finalmente (casi siempre) ganan. ¿Ganarán esta vez con Android?

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 .

Razones del éxito de MySQL

Apostaría ahora mismo sin titubear a que el 75% de las webs en la onda de las redes sociales y otros servicios online del estilo, llevan MySQL como servidor de base de datos. ¿Por qué se ha convertido MySQL en piedra angular de muchísimos proyectos que tanto éxito están teniendo? Son muchas y variadas las razones, así que antes de aburriros y hacer que os enganchéis a la aleatoriedad de StumbleUpon, os las resumo en este post, como diría el amigo Frank, my way:

• Despacito pero con buena letra. Esta filosofía de trabajo y de publicación de versiones es a mi entender, la que está haciendo que esta base de datos sea hoy por hoy una de las grandes. El equipo de MySQL lleva muchos años trabajando duro en la sombra, sin hacer demasiado ruido, sin prometer cosas que saben no pueden cumplir; han ido poquito a poco pero siempre con paso firme, y es ahora cuando están recogiendo los frutos de todo el trabajo realizado. Sinceramente, creo se lo han ganado.

• Apoyo y respaldo de gran parte de la comunidad opensource. A cambio, dicha comunidad juega un papel determinante en las decisiones que se toman en torno al producto: roadmap, corrección de bugs, adición de nueva funcionalidad, etc. Por si esto fuera poco, a primeros de año Sun Microsystems compraba MySQL, con lo que la inyección de dinero e ideas habrá sido considerable.
  

• Muchísima funcionalidad a coste reducido/cero. Aunque como muchos otros productos opensource, MySQL también tiene una edición de pago denominada MySQL Enterprise, a la mayoría de aplicaciones y webs les sobra con la edición gratuita MySQL Community Server. Es así de simple, si ofreces algo que funciona muy bien, es sencillo de configurar y gestionar, y encima es gratis, te has metido a muchos desarrolladores en el bolsillo, tarea harta difícil con la variedad de productos y plataformas que tenemos hoy en día. Es un modelo de negocio acertado, si alguien necesita soporte o funcionalidad extra, don't worry, ya se informará y pagará la licencia de la edición "pro", licencia por cierto irrisoria si la comparamos con licencias del resto de bases de datos del mercado.

• Multiplataforma. Es una ventaja el que ofrezca versiones tanto para Linux como para Windows, y más, comprobar que en ambos casos el rendimiento es muy bueno. A eso se le llama hacer amigos...
  

Como podéis comprobar, se nota que MySQL no tiene abuela, ya estoy yo, sin estar en nómina de Sun, para alabar todas sus bondades ;-). Simplemente hablo desde la óptica de mi relativamente corta experiencia con MySQL, pero hasta el momento sólo tengo buenas palabras hacia esta base de datos cuya mascota es un simpático delfín llamado Sakila.

Durante esta corta pero intensa convivencia, he tenido el placer de comprobar como MySQL aguanta y gestiona como un campeón (y sin demasiados recursos hardware), bases de datos con tablas pobladas por millones de registros, tablas sometidas a infinitas sentencias insert a lo largo del día, acompañadas de un estrés continuo de sentencias select realizadas sin piedad, alguna. Y ahí sigue, al pie del cañón, con el delfín venga bucear ;-).

Por todas estas razones, no es de extrañar que a fecha de hoy, a la hora de arrancar un nuevo proyecto o desarrollo de aplicación software, MySQL sea una de las candidatas mejor situadas (sino la mejor...) en la cada vez más apretada parrilla de salida del Gran Premio de las Bases de Datos.

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 .

Sun Microsystems compra MySQL

No hay mucho más que decir, es sin duda la noticia tecnológica del día. Sí, esa clase de noticia económica que hace que el índice tecnológico Nasdaq de la Bolsa de Nueva York se tambalee o se dispare por las nubes, haciendo rico a más de un listillo. Casualidad, hace unos días hablaba yo del enorme potencial que atesora MySQL, por lo que veo que no soy el único con esa opinión, ¿eh Sun Microsystems? Ya me podían pagar un dinerillo por hacerles de consultor-oráculo ;-)

Jugada maestra y muy inteligente por parte de Sun, que se hace con los servicios de una compañía en pleno auge, que además cuenta con un respaldo total por parte de la comunidad opensource de desarrolladores. Aplauso para Sun...

La nota de prensa oficial de Sun la podéis encontrar aquí.

Resumen friki de la noticia:

GRANT ALL PRIVILEGES ON MYSQL TO SUN_MICROSYSTEMS

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.

Miro: Reproductor de video y TV online muy completo

A raíz de una de ésas dichosas daily newsletters a las que todo informático que se precie debe estar suscrito (que no se ofenda quien no lo esté), me llegó el otro día el chivatazo de Miro. Es un reproductor (sí, pariente de Winamp, QuickTime, Windows Media Player, etc.) de vídeo y TV online que me ha sorprendido gratamente. Vamos, que después de instalarlo y probarlo, no lo he desinstalado, es decir, que me lo he quedado como default player. Aparte de reproducir vídeos en todo tipo de formatos (MPEG, AVI, MOV, XVID...), este compacto player integra la posibilidad de suscribirse a canales de TV online, blogs de vídeos y podcasts.

¡Pero esto no es todo (que conste que Miro no me paga)! Aunque he visto millones de plugins que guardan los vídeos de YouTube con más o menos éxito, lo bueno de Miro es que integra un buscador de vídeos de YouTube, con lo que una vez realizada la búsqueda, puedes descargarte los vídeos a tu biblioteca de vídeos para verlos offline cuando más te apetezca. El otro día por ejemplo estuve viendo los goles del partido Eibar-Córdoba (2-1) que alguien generosamente ya había colgado en Internet. Y last but not least, Miro actúa también como cliente bittorrent de vídeos, con lo que una vez la descarga del torrent termina, sólo queda darle al play.

Se me olvidaba: Miro es opensource (creo que por debajo lleva Python), es gratuito, y funciona de cine tanto en Windows como en Linux como en Mac. ¡Bravo Miro!

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.