sgoliver.net blog

Nueve meses después de la aparición de las anteriores versiones hoy se estrenan Mono 2.6 y MonoDevelop 2.2, herramientas clave para el desarrollo de aplicaciones .NET sobre Linux y Mac OS (además de Windows, por supuesto).

Entre las novedades más destacadas de la plataforma Mono 2.6 se encuentran la implementación de WCF, el soporte para LINQ to SQL, el nuevo Soft Debugger, la integración de los frameworks ASP.NET MVC, ASP.NET AJAX y Microsoft Dynamic Language Runtime, y la inclusión preliminar de algunas características de C# 4.0 como los parámetros con nombre y los parámetros opcionales.

MonoDevelop 2.2 también se presenta con muchas novedades, entre las que destacan el soporte oficial para Windows y Mac OS, el soporte para múltiples runtimes .NET (multi-targeting), las muchas novedades en cuanto a edición de código (plantillas de código, formateo y generación de código, selección de bloques, …), la enorme ampliación de las opciones de refactorización, y las extensiones para el desarrollo con ASP.NET MVC, Moonlight, IPhone (MonoTouch) y Python.

En definitiva, una buena noticia para el mundo del desarrollo bajo la plataforma .NET en cualquier sistema operativo.

Os animo a probar estas herramientas.

Y no sólo su algoritmo de búsqueda, sino toda la infraestructura sobre la que se apoya su buscador, en busca de mejoras considerables en cuanto a su velocidad de indexado y precisión de los resultados, entre otros muchos aspectos. Todo nos lo cuentan en este noticia.

Y para que probemos las novedades han habilitado un enlace independiente al tradicional: http://www2.sandbox.google.com/

Tal como nos cuentan, un usuario de a pié como somos la mayoría no debería notar grandes diferencias al realizar una búsqueda con este nuevo motor, a excepción de algunas diferencias en el orden de los resultados que nos instan a que les comuniquemos a través de los mecanismos de feedback que proporcionan en la nueva web.

Y ahora una reflexión, ¿no os parece un tanto arriesgada esta maniobra? Está claro que la mejora continua y la innovación deben llegar por caminos de este tipo, pero parece extraño que un producto consolidado a un nivel tan alto como el buscador web de Google intente cambiar a estas alturas.

Los conspiranoicos ya hablan de la presión que está ejerciendo el renovado buscador de Microsoft Bing y la reciente noticia de que Yahoo lo utilizará también como su motor de búsqueda. Aunque Matt Cutts, uno de los grandes de Google, intenta dejar claro que la competencia nada tiene que ver con este tema:

Q: Is this Caffeine Update because of Company X or Y is doing Z?

A: Nope. I love competition in search and want lots of it, but this change has been in the works for months. I think the best way for Google to do well in search is to continue what we’ve done for the last decade or so: focus relentlessly on pushing our search quality forward. Nobody cares more about search than Google, and I don’t think we’ll ever stop trying to improve.

En fin, veremos como acaba este experimento, y sobre todo esperemos que Google no mate a la gallina de los huevos de oro que tantos éxitos le ha dado en los últimos años. Y no por Google, sino por el bien de los usuarios y de las búsquedas en internet.

Three weeks ago we released the second beta of NRtfTree 0.3. Since then, we have fixed some bugs you reported and we have been preparing the final release of the library. Today we release NRtfTree 0.3 Final with the following changes since last beta:

• Added a new test project (NUnit).
• Version numbering scheme updated to “major.minor.build.revision”.
• SimpleDemo project updated to console application.
• Removed redundant code in RtfLex.
• ImageNode ScaleX and ScaleY properties returned incorrect values.
• RtfTreeNode.Rtf property inserted incorrect blank spaces when MergeSpecialCharacters property is true.
• RtfTree.Text property returned non-document-text characters in images, objects and field nodes.
• New method RtfTreeNode.SelectSingleChildGroup().

You can get complete information about NRtfTree versions in NRtfTree Changelog.

Download NRtfTree 0.3 now!

I’ve just published the second beta of NRtfTree 0.3.0.

You can review all the new features and changes of this new version at this post, or you can visit the new changelog section of NRtfTree.

One of the most important features of NRtfTree 0.3.0 beta 2 is a great performance improvement. You can read about this new feature at this post I wrote some days ago.

If you are new to NRtfTree you can also read the new FAQ and Examples sections.

Download now the new version of NRtfTree!

Since first public version, the objective of every new release of NRtfTree was to add new funtionality to the library. In NRtfTree 0.3.0 we also want to improve performance.

The main bottleneck in NRtfTree was the RTF lexer component (RtfLex class). While analyzing source code we dicovered two main problems:

1. Each token define and initialize its own StringBuilder object to load keywords, parameters and text.
2. The lexer Peek and Read the same characters repeatedly.

Both problems has been fixed in versión 0.3.0 beta2. RtfLex now define StringBuilder objects at class level and initialize them setting its lengh to 0 every time it starts a new token, and some methods has been rewriten to read characters only once.

This two simple changes result in a great performace improvement. In our tests, the load time of a simple RTF document (1.3mb, text only) was significantly reduced:

Document Load Time

Yes, the chart is correct. Load time is now over 100 times faster.

Memory allocation has been improved too. In previous versions, each RTF tree node initialized its child node list, even if it had no children at all. In NRtfTree 0.3.0 beta2, only group nodes creates its children list (if node type is not GROUP, ChildNodes property is set to null).

In our tests, memory allocated by a simple RTF document tree (1.3mb, text only) was reduced in about 20%:

A new versión of NRtfTree library will be released in a few days. Now it’s time to talk about some of the features of this new version (NRtfTree 0.3.0 beta2).

First of all, let’s review the most significant features of beta1:

• New license: LGPL.
• New class RtfDocument to easily create Rtf documents.
• New property MergeSpecialCharacters to merge adjacent text and control nodes (special characters).
• New property Text to get plain text from RTF documents.
• New methods to select nodes.
• New methods to work with node lists.

NRtfTree 0.3.0 beta2 will include significant enhancements:

• New class RtfMerger to merge RTF documents (Thanks to Fabio Borghi).
• New format options in RtfDocument. Now you can set document margins, paragraph indentation and text alignment.
• Stylesheet table support.
• New methods to select group nodes.
• New methods to search and replace text in text nodes.
• Performance greatly improved.

Beta 2 will fix some bugs too:

• Corrected StringBuilder initialization to avoid out of memory exception.
• RtfFontTable access by \f keyword parameter, not by index.
• Some RTF code generation errors (blank spaces, special characters…).

You can get a detailed changelog in NRtfTree Changelog.

Acabo de consultar en Sourceforge la fecha exacta en que publiqué la última versión de la librería NRtfTree, y me ha sorprendido [no sé si para bien o para mal] comprobar la cantidad de tiempo que ha pasado desde entonces. Casi dos años. Para ser exactos, desde el 2 de septiembre de 2007 no he publicado ninguna novedad sobre la librería.

Como podréis suponer no he estado trabajando todo este tiempo en la librería, más aún tratándose de una versión beta que tan solo faltaba pulir un poco antes de publicar su versión final. Los motivos reales de la demora no han sido otros que el trabajo y la inversión de tiempo en otros proyectos que se encontraban más arriba en mi lista de prioridades.

Sin embargo, estos últimos días NRtfTree ha vuelto a estar entre los primeros puestos de mi lista de proyectos personales y he podido dedicar finalmente algo de tiempo a pulimentar aquello que liberé hace ya 668 días.

La versión publicada volverá a llevar consigo la etiqueta “beta”. Concretamente la numeración oficial será NRtfTree 0.3.0 beta2. Y después de tanto tiempo después de la última versión ¿por qué otra beta?. En la inminente nueva versión de la librería he corregido todos los errores relevantes que me habéis reportado, pero también he añadido algunas nuevas características que merecen ser probadas públicamente durante algún tiempo. Además, algunas clases han sufrido varios cambios internos en pro de un mejor rendimiento de la librería, motivo por el cual también me parece apropiado un tiempo adicional de prueba antes de la versión final.

Estimo que el resultado de este trabajo verá la luz en un par de semanas [o quizá antes], ya que aunque el código fuente se encuentra prácticamente listo, aún me quedan bastantes labores burocráticas pendientes, como por ejemplo la generación de la documentación de la librería, y la actualización del proyecto en Sourceforge, en la web oficial y en la sección del proyecto en mi propia web, donde espero poder añadir una nueva sección con nuevos tutoriales y ejemplos de uso.

Una vez publicada la nueva versión de NRtfTree, comenzaré con la actualización de JRtfTree para tratar de mantener ambos proyectos los más sincronizados posible.

Os mantendré informados.

Tras unos días jugueteando con el recién estrenado Wolfram|Alpha, he de decir como conclusión que me ha dejado un sabor de boca un tanto agridulce.

Y que nadie me entienda mal, no esperaba más de esta nueva herramienta, pero como ingeniero informático, como amante de la inteligencia artificial, y como gran entusiasta del tratamiento automático del lenguaje natural, aún me quedaba esa ilusión de que alguien, en algún momento de un futuro no muy lejano, fuera capaz de ir un paso más allá de los motores de búsqueda tradicionales, donde como todos sabemos Google sigue manteniendo su reinado indiscutible. No ha ocurrido así en esta ocasión, Wolfram|Alpha no ha traido consigo ninguna revolución en este campo, y de ahí el mal sabor de boca, pero resulta innegable que Stephen Wolfram ha iniciado un nuevo camino [en mi opinión prometedor] hacia ese objetivo.

Os pongo en antecedentes para quien aún no haya oído hablar del tema. ¿Conocéis a Stephen Wolfram? ¿Os suena quizá la compañía Wolfram Research? ¿Habéis utilizado alguna vez la aplicación informática Mathematica? Los que hayáis estudiado cualquier titulación técnico-científica seguro que habéis respondido afirmativamente a alguna de las preguntas anteriores. Para los que no, puedo contaros que Wolfram Research es la compañia que desarrolla la aplicación Mathematica, que puede considerarse como una de las herramientas de cálculo matemático más importantes de la actualidad con millones de usuarios, y Stephen Wolfram es la cabeza pensante que hay detrás de esa aplicación y de esa compañía. Pues bien, después de varios años de desarrollo, Wolfram|Alpha representa el nuevo proyecto de Stephen Wolfram, y se enmarca dentro del campo de los motores de búsqueda.

Wolfram|Alpha se planteó como un proyecto ambicioso, como un motor de búsqueda que, lejos de limitarse a ofrecer una lista de enlaces relacionados con el concepto buscado, fuera capaz de dar respuestas directas a preguntas sobre hechos concretos realizadas en lenguaje natural. Y no sólo eso, sino algo mucho más interesante, que fuera capaz de hacer “cálculos” con la información disponible, es decir, que tuviera la capacidad de inferir nuevos conocimientos más complejos [que no existan de forma explícita entre la información disponible] a partir de otros de los que sí se dispone, todo con el objetivo de generar una respuesta directa, correcta y completa a la pregunta del usuario. Como se puede comprobar estos objetivos van mucho más allá de lo que es, al menos a día de hoy, el “todopoderoso” Google.

Después de la presentación en sociedad del proyecto, ¿cuánto de lo que se prometía es cierto, y cuánto ha quedado de momento en el tintero? Pues es dificil de contestar a esto, todo depende del punto de vista que se utilice.

¿Es capaz de responder Wolfram|Alpha a preguntas directas escritas en lenguaje natural? Sí, pero con matices. En primer lugar, hay que decir que por el momento tan sólo entiende inglés, pero aún escribiendo en ese idioma el éxito de la respuesta dependerá mucho de la construcción de la pregunta, teniendo a veces que reformularla en varias ocasiones. La búsqueda de palabras clave sigue funcionando mejor que el lenguaje natural. Aún así hay que reconocer que se defiende bastante bien con preguntas directas, como por ejemplo “¿Cuál es la población de Madrid?“.

¿Es capaz de inferir Wolfram|Alpha nuevos datos a partir de los ya disponibles? Una vez más la respuesta es sí pero a medias. Es cierto que podremos hacer preguntas donde obliguemos al buscador a esforzarse un poco más para generar la respuesta, como por ejemplo “¿Que día cumplió Shakespeare 17 años?“. Dado que dificilmente ese dato aparezca de forma explícita en ninguna fuente de información, para responder a esta pregunta Wolfram|Alpha ha tenido que recuperar la fecha de nacimiento de Shakespeare y sumarle 17 años, es decir, de alguna forma ha calculado la respuesta a partir de la información disponible. ¿Cuál es el problema entonces? Pues el único “pero” que se puede poner es precisamente cuál es esa fuente de información de la que parte el buscador. Aunque en un primer momento pudo entenderse que al igual que los buscadores tradicionales Wolfram|Alpha obtendría su información directamente de la web esto no es así en realidad. Este nuevo buscador obtiene su información de varias fuentes externas de datos pretratados y adecuados expresamente para la ocasión. Y sí, estamos hablando de bases de datos gigantescas, pero ni mucho menos infinitas. ¿Qué quiero decir con esto? Pues básicamente que los contenidos que podremos encontrar en Wolfram|Alpha serán los que los desarrolladores del proyecto hayan seleccionado para formar parte de la base de información propia de la aplicación, lo que quiere decir que Wolfram|Alpha entiende de muchas temas pero no de todos, algo que casi sí podemos decir [dentro de los límites obvios] de los buscadores tradicionales. Y todo esto me lleva a una pregunta preocupante: si esa base de información se mantiene aislada del día a día de la actualidad ¿cuánto tiempo tardaremos en empezar a ver datos desactualizados como respuestas a nuestras preguntas? Espero que mucho, por el bien y el futuro del proyecto.

En definitiva, Wolfram|Alpha me parece un proyecto interesante, de gran valor desde el punto de vista técnico-científico, pero con una utilidad moderada para el usuario medio. Se trata de una aplicación a medio camino entre un motor de búsqueda tradicional (por ejemplo Google) y una enciclopedia online (por ejemplo Wikipedia). En ningún caso viene a sustituir a ninguno de los dos [simplemente no se ha diseñado para eso], pero sí los complementa a las mil maravillas, eso sí, siempre dependiendo del contexto de la búsqueda. En Wolfram|Alpha no encontraremos opiniones, ni noticias, ni tutoriales, ni artículos extensos, … en este nuevo buscador tan sólo encontraremos hechos, datos concretos sobre un tema concreto.

Y para descubrir las posibilidades que ofrece lo mejor es jugar un poco con él haciendo preguntas de lo más variopintas. Por ejemplo, realizar algún cálculo algebraico complejo (no olvidemos que Wolfram|Alpha tiene por detrás entre otras cosas la aplicación Mathematica),  conocer la posición genealógica de tu primo segundo, saber la cantidad de azucar que tiene una naranja, o averiguar algo tan elaborado como cuántas calorías quema un hombre de 28 años, 1.75 de altura y 75 Kg de peso si corre durante 30 minutos a un ritmo de 6 minutos/km. ¿Responde Google a esto de forma directa?

Para terminar, os dejo el enlace a un video de demostración de este nuevo motor de búsqueda donde pueden verse muchas de las posibilidades que nos ofrece y la inmensa variedad de información tanto textual como gráfica que es capaz de mostrar en sus resultados [Video demostración Wolfram|Alpha].

Como vimos en un artículo anterior, hace poco más de dos meses se publicó la versión definitiva de Moonlight 1.0, la implementación open source de la tecnología Silverlight de Microsoft.

En aquel momento ya se anunció que la primera beta de Moonlight 2.0 podría ver la luz en el mes de Mayo, y los chicos de Novell no nos mintieron ya que Miguel de Icaza acaba de anunciar en su blog la disponibilidad de la primera versión preliminar (preview) de Moonlight 2.0.

Las novedades son muchas y se pueden consultar más al detalle en los artículos dedicados al lanzamiento de Moonlight 2.0 en los blogs de Miguel de Icaza o Chris Toshok (líder del equipo de desarrollo de Moonlight), pero dentro de las novedades más interesantes están las siguientes:

• Por fin tenemos la máquina virtual de Mono dentro del plugin de Moonlight para el navegador, lo que nos permitirá utilizar C# o cualquier lenguaje que pueda compilarse para esta máquina virtual (Ruby, Python, Boo…) para el desarrollo de aplicaciones sobre esta plataforma.
• Se incluyen todos los controles Silverlight de Microsoft, gracias a que éstos son ahora open source. Esto nos asegura mayor compatibilidad y coherencia de estilos con las aplicaciones Silverlight 2.0.
• Negotiated layout (siento no traducir esto, pero queda mejor en inglés). Ya nos podemos olvidar de establecer las posiciones y los tamaños de los controles de forma absoluta ya que a partir de ahora contaremos con contenedores que distribuirán convenientemente los controles en el espacio disponible, al estilo por ejemplo de los layouts de Swing (Java).
• Soporte para DeepZoom.
• Nuevas herramientas de desarrollo para construir .xaps compatibles con Silverlight 2.0.
• Se incluyen incluso algunas de las novedades de Silverlight 3.0, como por ejemplo el soporte para aplicaciones fuera del navegador (out-of-browser applications), la inclusión del SaveFileDialog, o el soporte de la clase WritableBitmap.

No hay que olvidar que se trata de una versión preliminar, por lo que aún no está completa ni alineada completamente con Silverlight 2.0, pero hay que reconocer el trabajo enorme y la rapidez del equipo de desarrollo de Moonlight para disminuir cada día la ventaja que llevaba Silverlight con respecto a esta plataforma. Veamos como evoluciona el proyecto en los próximos meses.

Ya lo comentamos en una entrada anterior, los rumores eran insistentes sobre la inminente llegada de un nuevo lenguaje a Google AppEngine. Y por fin ha llegado, AppEngine estrena hoy algunas novedades, y entre ellas la más solicitada por todos los usuarios, el soporte para el lenguaje Java. Eso sí, tan sólo podrán probar la versión preliminar de esta caracterísitica los primeros 10000 usuarios que lo soliciten accediendo a este enlace.

Google AppEngine ha sido desde el principio un serivicio muy interesante, pero algunos desarrolladores lo descartaban porque las restricciones en cuanto al lenguaje de programación a utilizar eran muy grandes, sólo se soportaba el lenguaje Python, algo que hacía que en muchos casos resultara complicado migrar aplicaciones ya existentes a esta plataforma.

Con la llegada de Java este servicio se hará mucho más popular, permitiendo a más personas explotar las características de esta plataforma y de toda la infraestructura proporcionada por Google (de forma gratuita hasta unos límites bastante permisivos [límites, más límites], o bien pagando por el servicio para disminuir esas limitaciones [precios]).

Algunos datos sobre las nuevas características de Google AppEngine en relación al lenguaje Java:

• Se soportan las versiones de Java 5 y 6, y los estandares Java Servlet y Java Server Pages (JSP). Al igual que en el caso de Python, también existirán algunas restricciones en el entorno de ejecución para java. Así, por ejemplo, tan sólo se podrá hacer uso de las siguientes APIs de la librería estandar de java [JRE Class White List], aunque como puede comprobarse la lista de las permitidas es inmensa.
• Para el acceso a datos se puede utilizar tanto la propia API de datos AppEngine como las interfaces estandar Java Data Objects 2.3 (JDO) o Java Persistence API 1.0 (JPA).
• Los servicios de Caché y Correo de AppEngine también se pueden utilizar a través de las interfaces estandar JCache (JSR 107) y JavaMail, así como el acceso HTTP/HTTPS a otros hosts mediante la API básica java.net.URLConnection.
• El acceso a los servicios de login y manipulación de imágenes se realiza mediante APIs propias de AppEngine.

Como parte del soporte para el lenguaje java, Google también ha desarrollado un nuevo plugin [AppEngine Eclipse Plugin] para el entorno de desarrollo Eclipse que facilitará el desarrollo, prueba y despliegue de aplicaciones java sobre la plataforma AppEngine, e incluso el desarrollo de aplicaciones con la nueva versión de Google Web Toolkit 1.6 (GWT) y su publicación sobre AppEngine o cualquier otro entorno. Este plugin es compatible con las versiones de Eclipse 3.3 (Europa) y 3.4 (Ganymede).

Para más información sobre el soporte java de AppEngine se puede consultar la web oficial con la documentación preliminar de desarrollo.

Como última nota en relación al nuevo soporte java de Google AppEngine quiero mencionar la posibilidad utilizar AppEngine con otros lenguajes basados en la máquina virtual java, como describe por ejemplo Guillaume Laforge en este artículo, donde explica cómo utilizar el lenguaje Groovy en AppEngine.

Además del soporte para Java, Google AppEngine ha presentado más novedades interesantes:

• Soporte para tareas programadas (servicio CRON).
• Soporte para Google Web Toolkit 1.6 (GWT).
• Soporte para Google Secure Data Connector.
• Nueva herramienta para importar datos de forma masiva a AppEngine. Y anuncian que en breve estará también disponible una herramienta para exportar datos.

A la vista de todas estas novedades es innegable que Google AppEngine se ha posicionado con fuerza en el apartado de hospedaje de aplicaciones web escalables, frente a importantes competidores como los también famosos Amazon Web Services (AWS).