¿Alguna vez os he comentado que mi jefe es un crack? Pues lo es. No sólo sabe muchísimo sino que además siempre te sorprende con alguna historia interesante. Hoy me estuvo comentando como nació VNC y como se hizo Open Source. Desconozco si es una historia conocida, seguro que en algún lado estará publicada o habrá salido, pero bueno, a mi me ha gustado bastante así que voy a hablar un poco de ello.
Todo empezó hablando sobre Open Source y como muchos proyectos Open Source habían tenido éxito gracias a haber tomado la decisión en un determinado momento de liberarlos como código abierto. Hace 12 años mi jefe trabajaba en los Olivetti Research Laboratories de la universidad de Cambridge, que posteriormente pasaron a ser los laboratorios de Oracle y más tarde se convirtieron en los laboratorios de AT&T, nombre por el que quizás hayan sido más famosos.
Él trabajaba en omniORB un motor de CORBA que todavía está en uso y cuyo rendimiento era altísimo llegando a latencias de microsegundo por aquellos tiempos. OmniORB fue el primer proyecto Open Source lanzado por el laboratorio. Inicialmente eran muy reacios a liberar el código fuente y los proyectos que realizaban, y éste motor fue como la primera prueba. El resultado fue un éxito, y el proyecto ganó más y más popularidad.
Al mismo tiempo que realizaban este proyecto, otro equipo del laboratorio jugaban con algo que se conocían como Active Badge System que era un sistema de localización de personas. El caso es que las salas donde trabajaban estaban llenas de dispositivos de infrarojos para detección de personas. Cada persona llevaba un pequeño "badge" en su ropa que emitía señales infrarojos que se detectaban por los dispositivos de la sala. Mediante este sistema desde un control central podías saber dónde se encontraba cada persona en un momento dado.
Como aplicación práctica utilizaban los teléfonos. La idea era que si una persona recibía una llamada, el sistema detectaba dónde se encontraba dicha persona y el teléfono que tuviese más cercano se pondría a sonar sin que la persona no tendría que volver hasta su puesto. El sistema funcionaba muy bien. Incluso iban mucho más allá y disponían de un ordenador que a partir de todas las señales de infrarojos y de un modelo tridimensional en VRML de las salas era capaz de dibujar dónde se encontraban las personas y el modelo se iba actualizando en tiempo real.
Buscando más aplicaciones para esto del Active Badge fue como de repente surgió la idea de compartir un escritorio. Sería como con los teléfonos, el usuario se acercaría al ordenador y el "Active Badge System" detectaría donde se encuentra el usuario y le enviaría el escritorio remoto. VNC ya existía por entonces aunque su finalidad era algo diferente.
Una cosa llevó a la otra, se hizo Open Source, y ahí está. ¿Quién no lo ha utilizado alguna vez?
miércoles, enero 30, 2008
martes, enero 29, 2008
El nuevo motor de almacenamiento de MySQL se llama Maria
martes, enero 29, 2008 por Martín
Vaya nombre ha escogido Michael Videnius para lo que es el nuevo y reluciente motor de almacenamiento MySQL. Según comenta en su blog, aunque el trabajo lo comenzaron hace un par de años, sólo ha sido en los últimos cuatro meses cuando se han puesto realmente serios con él.
Maria viene a sustituir al ya vetusto y siempre criticado MyISAM, pero no será parte estándar de las distribución hasta MySQL 6.0. La idea es la de proporcionar un motor rápido y compacto como MyISAM para modos no-transaccionales pero al mismo tiempo solucionar las carencias de éste como son la falta de transaccionalidad. Pero eso todavía será para Maria 2.0. Por ahora la versión que han lanzado es una alternativa a MyISAM pero con tolerancia a caidas del servidor.
Muchos bloggers se han hecho eco de esta noticia, aunque creo que no demasiados sitios web ya que sólo he visto la noticia en Artima. Kevin Burton comenta por ejemplo que al menos tenemos una opción más, aunque habrá que esperar hasta que podamos tirar a la basura MyISAM e InnoDB. Por su parte, Colin Charles y Giuseppe Maxia han han estado intentando romper Maria pero parece que realmente el motor sobrevive a fallos.
La verdad es que el motor promete bastante. A ver si con suerte, ahora que Sun Microsystems está detrás de la compañía quizás esto avance incluso más rápido.
Maria viene a sustituir al ya vetusto y siempre criticado MyISAM, pero no será parte estándar de las distribución hasta MySQL 6.0. La idea es la de proporcionar un motor rápido y compacto como MyISAM para modos no-transaccionales pero al mismo tiempo solucionar las carencias de éste como son la falta de transaccionalidad. Pero eso todavía será para Maria 2.0. Por ahora la versión que han lanzado es una alternativa a MyISAM pero con tolerancia a caidas del servidor.
Muchos bloggers se han hecho eco de esta noticia, aunque creo que no demasiados sitios web ya que sólo he visto la noticia en Artima. Kevin Burton comenta por ejemplo que al menos tenemos una opción más, aunque habrá que esperar hasta que podamos tirar a la basura MyISAM e InnoDB. Por su parte, Colin Charles y Giuseppe Maxia han han estado intentando romper Maria pero parece que realmente el motor sobrevive a fallos.
La verdad es que el motor promete bastante. A ver si con suerte, ahora que Sun Microsystems está detrás de la compañía quizás esto avance incluso más rápido.
lunes, enero 28, 2008
EJB 3.1: No necesitas interfaces si total no vas a hacer tests
lunes, enero 28, 2008 por Martín
El viernes pasado TheServerSide publicaba un artículo sobre EJB 3.1 que habla de dos de las novedades de EJB 3.1: las interfaces opcionales y los singleton.
Atención a lo que su autor escribe en un momento dado respecto a las interfaces opcionales:
Interface-based programming is clearly a useful technique in writing loosely-coupled, unit-testable applications. That is precisely why both EJB 2.1 and Spring promote the idea of component interfaces. In fact, at least one interface is required even for EJB 3.0 Session Beans (this is not a requirement for EJB 3.0 Message Driven Beans).
Bien, hasta ahora todo bien. Ojo al siguiente párrafo que no tiene desperdicio:
The trouble is that component interfaces are just a needless abstraction in a lot of circumstances. I can't remember the times I silently cursed under my breath as I carried out the mechanical task of writing interfaces just because the framework needed it or the architect sitting in some ivory tower mandated it. A lot of times, just a regular Java object is really all you need for your foreseeable needs, especially if you don't really do much unit testing and loose-coupling is just not enough of a concern for the application.
Me pierdo un poco en este párrafo. Corregidme si me equivoco, pero me parece entender que ahora ya no necesitamos las interfaces porque hay ocasiones en que, total, no vamos a hacer tests unitarios, y que no nos preocupa el acoplamiento entre los componentes.
Yo creo que a veces todo esto de los hands-on architects, pragmatic architects, etc. se le va a la gente tan de las manos, que hasta se utiliza para justificar lo injustificable. Señores autores de la especificación de EJBs (sé que no me leen, no sé para que me dirijo a ellos), el desarrollo basado en interfaces es fundamental dentro de la programación de componentes ya que la testabilidad y el desacoplamiento son características fundamentales en estos sistemas. Y les pese o no, un EJB es exactamente eso, un componente. Es lo que ha sido siempre, y tampoco hay ido tan mal (al menos desde EJB 2.x).
Una cosa está clara, y ha sido así toda la vida. El que mucho abarca, poco aprieta. Y está claro que estos señores quieren abarcar mucho. Demasiado. Incluso a expensas de sugerir cosas como no hacer tests unitarios. En fin, cuando lees estas perlas de un miembro de la spec. de EJB 3 y JEE 6, y autor de EJB3 in Action, te das cuenta del despropósito total y el sin sentido que ha sido esta tecnología durante todo este tiempo.
Más les valdría haber estandarizado Spring y mantener EJB 2.x que tampoco era tan malo.
Atención a lo que su autor escribe en un momento dado respecto a las interfaces opcionales:
Interface-based programming is clearly a useful technique in writing loosely-coupled, unit-testable applications. That is precisely why both EJB 2.1 and Spring promote the idea of component interfaces. In fact, at least one interface is required even for EJB 3.0 Session Beans (this is not a requirement for EJB 3.0 Message Driven Beans).
Bien, hasta ahora todo bien. Ojo al siguiente párrafo que no tiene desperdicio:
The trouble is that component interfaces are just a needless abstraction in a lot of circumstances. I can't remember the times I silently cursed under my breath as I carried out the mechanical task of writing interfaces just because the framework needed it or the architect sitting in some ivory tower mandated it. A lot of times, just a regular Java object is really all you need for your foreseeable needs, especially if you don't really do much unit testing and loose-coupling is just not enough of a concern for the application.
Me pierdo un poco en este párrafo. Corregidme si me equivoco, pero me parece entender que ahora ya no necesitamos las interfaces porque hay ocasiones en que, total, no vamos a hacer tests unitarios, y que no nos preocupa el acoplamiento entre los componentes.
Yo creo que a veces todo esto de los hands-on architects, pragmatic architects, etc. se le va a la gente tan de las manos, que hasta se utiliza para justificar lo injustificable. Señores autores de la especificación de EJBs (sé que no me leen, no sé para que me dirijo a ellos), el desarrollo basado en interfaces es fundamental dentro de la programación de componentes ya que la testabilidad y el desacoplamiento son características fundamentales en estos sistemas. Y les pese o no, un EJB es exactamente eso, un componente. Es lo que ha sido siempre, y tampoco hay ido tan mal (al menos desde EJB 2.x).
Una cosa está clara, y ha sido así toda la vida. El que mucho abarca, poco aprieta. Y está claro que estos señores quieren abarcar mucho. Demasiado. Incluso a expensas de sugerir cosas como no hacer tests unitarios. En fin, cuando lees estas perlas de un miembro de la spec. de EJB 3 y JEE 6, y autor de EJB3 in Action, te das cuenta del despropósito total y el sin sentido que ha sido esta tecnología durante todo este tiempo.
Más les valdría haber estandarizado Spring y mantener EJB 2.x que tampoco era tan malo.
jueves, enero 24, 2008
Saas, innovación o seguridad... o quizás ambos
jueves, enero 24, 2008 por Martín
En OnStartups publicaron ayer un post bastante interesante sobre multitenancy. Multitenancy es un término que denomina a la capacidad de alojar diferentes clientes dentro de tu centro de datos. En el artículo definen cinco niveles diferentes:
Dejando un poco al lado el tema de multitenancy que ya lo he tratado otras veces junto al de virtualización. A mi lo que me ha interesado realmente en el artículo, y con lo que he charlado ampliamente con mi jefe, es el nivel 5.
La idea de tener una versión de tu software para poder mostrársela a los clientes es muy, pero que muy interesante. Aquí, no me estoy refiriendo a una versión demo de la versión estable de tu producto, sino a una versión demo quizás de la última snapshot o de la última semana. ¿Cuán es la razón? Time-to-market (TTM).
El TTM de un producto puede ser bastante grande, especialmente si hay bastantes funcionalidades. Las metodologías ágiles solucionan esto en cierto grado promoviendo las releases frecuentes en intervalos cortos de tiempo, pero aún así la realidad es que ciertas funcionalidades pueden tardar varios meses en ver la luz. Pero, aunque el TTM de un producto sea grande, eso no quiere decir que lo tenga que ser el TTS (Time to Sell, ojo que este término me lo he inventado). Siempre pasa que hay ciertas funcionalidades que están en el roadmap, y que ya se han implementado pero todavía no están en una versión estable, que pueden ganar una venta; y los comerciales se encuentran sin la posibilidad de demostrar dichas funcionalidades y teniendo que conformarse con un "eso lo tenemos para la próxima versión" (bueno en realidad dirán éso, y 100 cosas más :D).
Tener un sistema demo, con lo "último de lo último" puede valer una venta. Ahora bien, ¿vale la pena el riesgo? Porque evidentemente, lo "último de lo último" no habrá pasado unos controles de calidad tan minuciosos como puedan haber pasado las versiones estables de nuestro sistema. ¿Cómo puede reaccionar un cliente a un fallo en este tipo de demo? A un cliente razonable, probablemetne no le importará mucho, pero otros clientes pueden llevarse una muy mala impresión de nuestro producto. Una solución obvia es disponer de un sistema de demo con la última versión estable de nuestro sistema, esa que nunca falla, y utilizarla para las presentaciones. En el momento en que pregunten por algo "especial" que sabemos que les sorprenderá, siempre se puede sacar un "mmm... bueno, sé que no debería enseñarte esto, pero lo haré". El cliente probablemente se muestre complacido, ya que a fin de cuentas le estamos enseñando algo "especial", "sólo para él", y en caso de fallo bueno, la impresión no será tan mala :-)
¿Qué opináis? ¿Vale la pena apostar por una demo con lo último o mejor apostar por lo seguro?
- Nivel 0: Caos. Cada cliente en su propio servidor. Las actualizaciones se aplican a cada cliente y cada uno puede correr sobre una versión diferente.
- Nivel 1: Caos controlado. Todos los clientes se ejecutan en diferentes servidores físicos, sobre la misma versión del software.
- Nivel 2: Multi-tenant (vertical). El sistema es capaz de alojar múltiples clientes con la misma versión de software en el mismo servidor. Nuevos clientes se alojan en el mismo servidor. Tiene el problema de que sólo escala hacia arriba.
- Nivel 3: Multi-tenant (horizontal). Se consigue la escalabilidad horizontal y múltiples clientes pueden compartir múltiples servidores utilizando la misma versión del software.
- Nivel 5: Utopía. Es igual que el nivel 3 pero ahora además se consigue la forma de ejecutar diferentes versiones del software para el mismo cliente.
Dejando un poco al lado el tema de multitenancy que ya lo he tratado otras veces junto al de virtualización. A mi lo que me ha interesado realmente en el artículo, y con lo que he charlado ampliamente con mi jefe, es el nivel 5.
La idea de tener una versión de tu software para poder mostrársela a los clientes es muy, pero que muy interesante. Aquí, no me estoy refiriendo a una versión demo de la versión estable de tu producto, sino a una versión demo quizás de la última snapshot o de la última semana. ¿Cuán es la razón? Time-to-market (TTM).
El TTM de un producto puede ser bastante grande, especialmente si hay bastantes funcionalidades. Las metodologías ágiles solucionan esto en cierto grado promoviendo las releases frecuentes en intervalos cortos de tiempo, pero aún así la realidad es que ciertas funcionalidades pueden tardar varios meses en ver la luz. Pero, aunque el TTM de un producto sea grande, eso no quiere decir que lo tenga que ser el TTS (Time to Sell, ojo que este término me lo he inventado). Siempre pasa que hay ciertas funcionalidades que están en el roadmap, y que ya se han implementado pero todavía no están en una versión estable, que pueden ganar una venta; y los comerciales se encuentran sin la posibilidad de demostrar dichas funcionalidades y teniendo que conformarse con un "eso lo tenemos para la próxima versión" (bueno en realidad dirán éso, y 100 cosas más :D).
Tener un sistema demo, con lo "último de lo último" puede valer una venta. Ahora bien, ¿vale la pena el riesgo? Porque evidentemente, lo "último de lo último" no habrá pasado unos controles de calidad tan minuciosos como puedan haber pasado las versiones estables de nuestro sistema. ¿Cómo puede reaccionar un cliente a un fallo en este tipo de demo? A un cliente razonable, probablemetne no le importará mucho, pero otros clientes pueden llevarse una muy mala impresión de nuestro producto. Una solución obvia es disponer de un sistema de demo con la última versión estable de nuestro sistema, esa que nunca falla, y utilizarla para las presentaciones. En el momento en que pregunten por algo "especial" que sabemos que les sorprenderá, siempre se puede sacar un "mmm... bueno, sé que no debería enseñarte esto, pero lo haré". El cliente probablemente se muestre complacido, ya que a fin de cuentas le estamos enseñando algo "especial", "sólo para él", y en caso de fallo bueno, la impresión no será tan mala :-)
¿Qué opináis? ¿Vale la pena apostar por una demo con lo último o mejor apostar por lo seguro?
jLibrary web disponible
jueves, enero 24, 2008 por Martín
Daniel Latorre ha sido tan amable de anunciar oficialmente (en castellano) en su blog el lanzamiento de la nueva web de jLibrary y su demo online. Durante los últimos meses Daniel y yo mismo hemos estado trabajando en llevar a jLibrary a la web, y creo que el objetivo se ha cumplido y que el resultado es bastante satisfactorio.
Desde que comencé el proyecto allá a finales del 2003, desde siempre la principal "feature" que había faltado era la posibilidad de navegar tus respositorios de documentos via web. La aplicación de escritorio es fenomenal, y siempre recibo mensajes o leo mensajes en el foro del proyecto hablando maravillas de la misma. Pero lo cierto es que una de las cosas de las que me arrepiento en este proyecto es el de no haber lanzado la web con mucha más antelación. Pero bueno, el proyecto siempre ha sido un playground en si mismo, y creo que tanto Daniel como yo mismo lo hemos aprovechado para aprender nuevas tecnologías estos últimos meses.
La demo está disponible en http://demo.jlibrary.org. Daniel explica en esta entrada como utilizarla. Ambas páginas, la demo y jLibrary, comparten el mismo servidor pero son distintos repositorios de documentos. La única diferencia es que la demo te permite subir documentos y jugar un poco con ellos. Se puede acceder a ambos repositorios usando el cliente de escritorio, aunque eso ya está explicado en la documentación.
Por aportar algo más deciros que el desplegar esta web online nos ha ayudado ha encontrar algunos leaks en el sistema que estaban ahí, ocultillos. Hemos desplegado un sistema de monitorización que nos ha sido bastante útil para ello, así que ahora estamos bastante contentos con el resultado. El servidor es bastante modesto y está ejecutándose sobre un VPS con 384Mb de RAM, aunque realmente no utiliza mucho. La verdad es que no tengo números muy exactos porque siempre reinicio el servidor para meter algún parchecillo, pero la última vez que miré llevaba una semana de ejecución y no había hecho ni una sola "major garbage collection", lo que está muy bien :)
Claro que una segunda lectura es que la actividad no es demasiada, jejeje. Solemos tener entre 5-10 sesiones abiertas, se suelen crear cada dia unos 3 o cuatro documentos, actualizarse lo mismo y la gente va creando también unos cuantos comentarios. El repositorio anda por los 100Mb, 200Mb de tamaño y normalmente la gente visitará unas 1000 o 2000 páginas por día, más o menos.
Update: Desde que lo han anunciado en javaHispano ahora ya sabemos que soporta bien las 60-70 sesiones concurrentes :-)
Como veis, números muy modestos, pero estamos bastante contentos con el resultado. Por cierto, muchas gracias Dani por echarme una mano con esto, ya que si no estuvieras tú por ahí, no creo que el proyecto hubiese visto la luz.
Desde que comencé el proyecto allá a finales del 2003, desde siempre la principal "feature" que había faltado era la posibilidad de navegar tus respositorios de documentos via web. La aplicación de escritorio es fenomenal, y siempre recibo mensajes o leo mensajes en el foro del proyecto hablando maravillas de la misma. Pero lo cierto es que una de las cosas de las que me arrepiento en este proyecto es el de no haber lanzado la web con mucha más antelación. Pero bueno, el proyecto siempre ha sido un playground en si mismo, y creo que tanto Daniel como yo mismo lo hemos aprovechado para aprender nuevas tecnologías estos últimos meses.
La demo está disponible en http://demo.jlibrary.org. Daniel explica en esta entrada como utilizarla. Ambas páginas, la demo y jLibrary, comparten el mismo servidor pero son distintos repositorios de documentos. La única diferencia es que la demo te permite subir documentos y jugar un poco con ellos. Se puede acceder a ambos repositorios usando el cliente de escritorio, aunque eso ya está explicado en la documentación.
Por aportar algo más deciros que el desplegar esta web online nos ha ayudado ha encontrar algunos leaks en el sistema que estaban ahí, ocultillos. Hemos desplegado un sistema de monitorización que nos ha sido bastante útil para ello, así que ahora estamos bastante contentos con el resultado. El servidor es bastante modesto y está ejecutándose sobre un VPS con 384Mb de RAM, aunque realmente no utiliza mucho. La verdad es que no tengo números muy exactos porque siempre reinicio el servidor para meter algún parchecillo, pero la última vez que miré llevaba una semana de ejecución y no había hecho ni una sola "major garbage collection", lo que está muy bien :)
Claro que una segunda lectura es que la actividad no es demasiada, jejeje. Solemos tener entre 5-10 sesiones abiertas, se suelen crear cada dia unos 3 o cuatro documentos, actualizarse lo mismo y la gente va creando también unos cuantos comentarios. El repositorio anda por los 100Mb, 200Mb de tamaño y normalmente la gente visitará unas 1000 o 2000 páginas por día, más o menos.
Update: Desde que lo han anunciado en javaHispano ahora ya sabemos que soporta bien las 60-70 sesiones concurrentes :-)
Como veis, números muy modestos, pero estamos bastante contentos con el resultado. Por cierto, muchas gracias Dani por echarme una mano con esto, ya que si no estuvieras tú por ahí, no creo que el proyecto hubiese visto la luz.
lunes, enero 21, 2008
Larry Ellison a VMWare: Su software lo podría haber escrito mi gato
lunes, enero 21, 2008 por Martín
Parece que a Larry Ellison no le gusta VMWare. Al menos eso es lo que se puede entrever atendiendo al artículo que publicaban hace un par de días en el Financial Times.
Según Larry Ellison, VMWare está condenada al fracaso, incluso a pesar de haber sido la compañía de moda el año pasado en Wall Street y haber protagonizado el éxito tecnológico más importante en los mercados después de la salida a bolsa de Google. Según Larry Ellison no pasará mucho hasta que Microsoft eclipse a esta compañía igual que hizo en el pasado con Netscape una vez que su software de virtualización se incluya en sus servidores.
Y es que el CEO de Oracle no ve nada especial en VMWare, de hecho se atreve a afirmar: "that the base layer of software on which virtualisation depends, called a hypervisor, was so simple that his cat could write it.". Es decir, que incluso su gato podría haber escrito la capa de virtualización de VMWare.
Bueno, pero no sólo Microsoft y el gato de Larry Ellison son las amenazas de VMWare. Ellison también comentó que el negocio de la virtualización pronto será "commoditized" y destacó a Xen como inmediata amenaza con un mercado que va creciendo cada vez más.
Por cierto, ¿Cómo respondió la CEO de VMWare?
“If his very smart cat could write it, my very smart tortoise could write his database.”
Parece que estas dos personas no se llevan demasiado bien :-)
Según Larry Ellison, VMWare está condenada al fracaso, incluso a pesar de haber sido la compañía de moda el año pasado en Wall Street y haber protagonizado el éxito tecnológico más importante en los mercados después de la salida a bolsa de Google. Según Larry Ellison no pasará mucho hasta que Microsoft eclipse a esta compañía igual que hizo en el pasado con Netscape una vez que su software de virtualización se incluya en sus servidores.
Y es que el CEO de Oracle no ve nada especial en VMWare, de hecho se atreve a afirmar: "that the base layer of software on which virtualisation depends, called a hypervisor, was so simple that his cat could write it.". Es decir, que incluso su gato podría haber escrito la capa de virtualización de VMWare.
Bueno, pero no sólo Microsoft y el gato de Larry Ellison son las amenazas de VMWare. Ellison también comentó que el negocio de la virtualización pronto será "commoditized" y destacó a Xen como inmediata amenaza con un mercado que va creciendo cada vez más.
Por cierto, ¿Cómo respondió la CEO de VMWare?
“If his very smart cat could write it, my very smart tortoise could write his database.”
Parece que estas dos personas no se llevan demasiado bien :-)
domingo, enero 20, 2008
¿Es MapReduce un paso atrás?
domingo, enero 20, 2008 por Martín
La gripe que inevitablemente estoy incubando sumado a que llevo unos días un poco desconectado debido al esfuerzo de arrancar algo del que probablemente pronto tengáis noticia y que me tiene muy ilusionado, me ha hecho mantenerme un poco apartado del blog estos días y también de las noticias blogosféricas. Y claro, hoy al ir repasando mis feeds me he encontrado con el tremendo lio que se ha montado debido al último artículo de Michael Stonebraker: MapReduce: A major step backwards.
StoneBraker es una referencia dentro del mundo de la base de datos. Recientemente, uno de sus artículos tubo enorme aceptación al cuestionarse si las bases de datos relacionales habían quedado obsoletas en un mundo en el que las bases de datos especializadas tenían cada vez más éxito. Sin embargo, parece que ahora ha dado con un hueso muy duro de roer con la comunidad de la computación distribuida.
StoneBraker afirma en su artículo que MapReduce es un enorme paso atrás en la computación distribuida, en base a los siguientes argumentos:
Prácticamente todos los medios de noticias y bloggers están de acuerdo en que StoneBraker ha cometido un error muy básico, que es comparar peras con naranjas, bases de datos con algoritmos de computación distribuida.
Hay quien trata de exponer todos los errores del artículo y opina que los autores (David J. DeWitt es coautor) es que los autores se han despistado y que si en lugar de hablar de MapReduce hubiesen hablado de Amazon SimpleDB el artículo hubiera tenido sentido. Hay también es más drástico y opina que StoneBraker ya no es una referencia para él.
Hay quien también apunta que el propio Google es consciente que el algoritmo no es lo mejor que podría ser pero que cumple su objetivo perfectamente. Otras comunidades y blogs como High Scalability, InfoQ o YComb se han hecho también eco del tema.
Lo cierto es que a mi también me ha chocado bastante la comparación entre MapReduce y una base de datos. Leyendo el artículo, la verdad es que uno sigue el hilo y hasta puede estar de acuerdo en algún punto de los puntos uno, y dos; pero es en los siguientes puntos, tres, cuatro y cinco, donde el artículo pierde definitivamente el norte.
A mi me da la impresión de como si durante estos años un montón de gente hubiese acudido a estas personas con preguntas del estilo "¿Por qué necesito una base de datos si Google no la usa?", "¿Tienen alguna base de datos como BigTable?", "¿Por qué va Google tan rápido sin base de datos y la que ústedes nos han recomendado va tan lenta?", y se hayan querido despachar a gusto. Realmente me suena a esto. A un "estamos hartos de tantos emails sobre BigTable y vamos a dejar las cosas claras".
En fin, la verdad es que los que nos manejamos a niveles muchísimo más modestos, pues por lo menos podemos intentar aprovechar estos lios para pillar un poco de aquí y otro poco de allá en los comentarios y aprender los entresijos de algunas tecnologías. Que al final es lo que vamos a sacar en limpio :-)
StoneBraker es una referencia dentro del mundo de la base de datos. Recientemente, uno de sus artículos tubo enorme aceptación al cuestionarse si las bases de datos relacionales habían quedado obsoletas en un mundo en el que las bases de datos especializadas tenían cada vez más éxito. Sin embargo, parece que ahora ha dado con un hueso muy duro de roer con la comunidad de la computación distribuida.
StoneBraker afirma en su artículo que MapReduce es un enorme paso atrás en la computación distribuida, en base a los siguientes argumentos:
- Representación de datos anticuada. No aprovecha los conocimientos adquiridos en los últimos años y las ventajas de utilizar esquemas y lenguajes de acceso a datos de alto nivel.
- Una aproximación menos que óptima basada en fuerza bruta.
- Nada nuevo, ya existía hace 25 años.
- Adolece de la falta de la mayor parte de funcionalidades disponibles dentro de las bases de datos relacionales.
- Es incompatible con todas las herramientas disponibles para bases de datos, es decir generadores de informes, herramientas de BI, data mining, data warehousing, etc.
Prácticamente todos los medios de noticias y bloggers están de acuerdo en que StoneBraker ha cometido un error muy básico, que es comparar peras con naranjas, bases de datos con algoritmos de computación distribuida.
Hay quien trata de exponer todos los errores del artículo y opina que los autores (David J. DeWitt es coautor) es que los autores se han despistado y que si en lugar de hablar de MapReduce hubiesen hablado de Amazon SimpleDB el artículo hubiera tenido sentido. Hay también es más drástico y opina que StoneBraker ya no es una referencia para él.
Hay quien también apunta que el propio Google es consciente que el algoritmo no es lo mejor que podría ser pero que cumple su objetivo perfectamente. Otras comunidades y blogs como High Scalability, InfoQ o YComb se han hecho también eco del tema.
Lo cierto es que a mi también me ha chocado bastante la comparación entre MapReduce y una base de datos. Leyendo el artículo, la verdad es que uno sigue el hilo y hasta puede estar de acuerdo en algún punto de los puntos uno, y dos; pero es en los siguientes puntos, tres, cuatro y cinco, donde el artículo pierde definitivamente el norte.
A mi me da la impresión de como si durante estos años un montón de gente hubiese acudido a estas personas con preguntas del estilo "¿Por qué necesito una base de datos si Google no la usa?", "¿Tienen alguna base de datos como BigTable?", "¿Por qué va Google tan rápido sin base de datos y la que ústedes nos han recomendado va tan lenta?", y se hayan querido despachar a gusto. Realmente me suena a esto. A un "estamos hartos de tantos emails sobre BigTable y vamos a dejar las cosas claras".
En fin, la verdad es que los que nos manejamos a niveles muchísimo más modestos, pues por lo menos podemos intentar aprovechar estos lios para pillar un poco de aquí y otro poco de allá en los comentarios y aprender los entresijos de algunas tecnologías. Que al final es lo que vamos a sacar en limpio :-)
miércoles, enero 16, 2008
Oracle compra BEA. SUN compra MySQL
miércoles, enero 16, 2008 por Martín
Hay días en que parece que la gente se levanta juguetona; con ganas de dar noticias vamos. Y eso parece ser que es lo que han pensado a la vez SUN, BEA, Oracle y MySQL.
Por una parte tenemos que Sun Microsystems compra MySQL. Está claro que la compañía americana no pierde el tiempo y ya que este año pasado ha tenido beneficios todos sus trimestres, pues hay que gastárselo en algo. Que mejor que comprar MySQL. Un producto tan relacionado con su mercado.... ejem.
Bueno está claro que sus razones tendrán. En un inicio la compañía se especulaba que iba a salir a bolsa, así que supongo que es mejor comprarla ahora que cuando valga cuatro veces más cara. Pero, ¿se va a dedicar Sun ahora a vender bases de datos? ¿va a mejorar su integración con Solaris? Quien sabe. Desde luego si Sun tenía ya ventaja en la cantidad de Open Source que aportaba a la industria, ahora tiene mucha más. Será muy interesante ver como evoluciona el producto.
Y ya que comentaba lo de salir a bolsa. De enhorabuena están los accionistas de BEA con su 24.4% de premium. Oracle ha comprado BEA y ahora si que es de verdad. Parece que los directivos de BEA han sabido negociar y han conseguido un extra de 1.200 millones de dólares respecto a la oferta del año pasado.
La verdad es que en un único día desaparecen dos de las compañías más punteras en cuanto desarrollo de software y que mejor estaban funcionando para integrarse en dos enormes gigantes. La verdad es que Oracle es famoso por gafar todo lo que toca. Vamos que salvo la base de datos que no cabe duda de que es lo que realmente mueve la compañía, pues los otros productos que ha ido comprando han ido desvaneciéndose con el tiempo. Incluso... este año casi no se ha hablado de Coherence desde su compra.
Sería un buen tópico de discusión. ¿Ahogan los departamentos legales y de marketing a estas compañías?
Por una parte tenemos que Sun Microsystems compra MySQL. Está claro que la compañía americana no pierde el tiempo y ya que este año pasado ha tenido beneficios todos sus trimestres, pues hay que gastárselo en algo. Que mejor que comprar MySQL. Un producto tan relacionado con su mercado.... ejem.
Bueno está claro que sus razones tendrán. En un inicio la compañía se especulaba que iba a salir a bolsa, así que supongo que es mejor comprarla ahora que cuando valga cuatro veces más cara. Pero, ¿se va a dedicar Sun ahora a vender bases de datos? ¿va a mejorar su integración con Solaris? Quien sabe. Desde luego si Sun tenía ya ventaja en la cantidad de Open Source que aportaba a la industria, ahora tiene mucha más. Será muy interesante ver como evoluciona el producto.
Y ya que comentaba lo de salir a bolsa. De enhorabuena están los accionistas de BEA con su 24.4% de premium. Oracle ha comprado BEA y ahora si que es de verdad. Parece que los directivos de BEA han sabido negociar y han conseguido un extra de 1.200 millones de dólares respecto a la oferta del año pasado.
La verdad es que en un único día desaparecen dos de las compañías más punteras en cuanto desarrollo de software y que mejor estaban funcionando para integrarse en dos enormes gigantes. La verdad es que Oracle es famoso por gafar todo lo que toca. Vamos que salvo la base de datos que no cabe duda de que es lo que realmente mueve la compañía, pues los otros productos que ha ido comprando han ido desvaneciéndose con el tiempo. Incluso... este año casi no se ha hablado de Coherence desde su compra.
Sería un buen tópico de discusión. ¿Ahogan los departamentos legales y de marketing a estas compañías?
domingo, enero 13, 2008
High Performance AJAX Applications
domingo, enero 13, 2008 por Martín
En la Yahoo Developers Network se puede ver el video de una presentación muy interesante de Julian Leconte titulada High Performance AJAX Applicatons.
Julian Leconte es ingeniero del equipo de desarrollo web de Yahoo y en esta presentación trata temas tan interesantes como el rendimiento de JavaScript, DHTML, CSS, AJAX y como utilizar algunas herramientas para medirlo. La presentación se construye sobre el fenomenal trabajo que ha realizado Steve Souders con su High Performance Web Sites. Por cierto, la presentación es totalmente agnóstica y aunque utiliza ejemplos de YUI (Yahoo User Interface), todo lo que se puede aprender en ella es aplicable a cualquier otro entorno y frameworks.
Julian Leconte es ingeniero del equipo de desarrollo web de Yahoo y en esta presentación trata temas tan interesantes como el rendimiento de JavaScript, DHTML, CSS, AJAX y como utilizar algunas herramientas para medirlo. La presentación se construye sobre el fenomenal trabajo que ha realizado Steve Souders con su High Performance Web Sites. Por cierto, la presentación es totalmente agnóstica y aunque utiliza ejemplos de YUI (Yahoo User Interface), todo lo que se puede aprender en ella es aplicable a cualquier otro entorno y frameworks.
viernes, enero 11, 2008
Más sobre MapReduce
viernes, enero 11, 2008 por Martín
Dándole un repaso a los blogs de escalabilidad que hay en inglés parece que estos días le han estado dando una vuelta de tuerca más al tema de MapReduce. Todo se debe a la publicación en ACM Computing de una nueva versión del artículo sobre MapReduce publicado en el 2004 por Jeffrey Dean y Sanjay Ghemawat. El artículo es de pago pero hay quien lo publica en su blog.
El artículo es muy similar a la versión original. Prácticamente un clon pero mejor formateado y más legible. A mayores incluye nuevas estadísticas sobre el uso de MapReduce en Google durante estos últimos años, que es lo realmente interesante si ya habíais leido el artículo original.
Según se puede leer en el artículo la primera versión estable de MapReduce se publicó en Febrero del 2003 aunque fue ampliamente mejorada en Agosto también del 2003. A día de hoy los autores comentan que se han implementado unos 10.000 programas distintos (aunque en las estadísticas sólo dan unos 6000 sumando implementaciones de map y reduce). Se ejecutan unos 100.000 trabajos de media utilizando este framework que procesan unos 20 petabytes al día. Muy impresionante, desde luego.
Entre las aplicaciones que usan MapReduce, están las que ya comentaron en su momento: problemas de machine learning, froogle y Google News, Google zeitgeist, y alguna otra. Han añadido a mayores Google Trends, el procesado de imágenes por satélite (asumo Google Earth y Google Maps), y el procesado de modelos de lenguaje para traducción (Google Translator?).
Lo más jugoso es la tabla resumen que muestran en el artículo:
Si queréis ampliar conocimientos sobre MapReduce y toda la infraestructura de computación de Google, probablemente el mejor recurso es el curso sobre sistemas distribuidos que se puede encontrar en Google Code, donde hay mucho material interesante.
También puede que sea interesante (no lo he visto) el video sobre MapReduce en sistemas multicore que publicaron en Febrero del año pasado y del que también está disponible la publicación original.
El artículo es muy similar a la versión original. Prácticamente un clon pero mejor formateado y más legible. A mayores incluye nuevas estadísticas sobre el uso de MapReduce en Google durante estos últimos años, que es lo realmente interesante si ya habíais leido el artículo original.
Según se puede leer en el artículo la primera versión estable de MapReduce se publicó en Febrero del 2003 aunque fue ampliamente mejorada en Agosto también del 2003. A día de hoy los autores comentan que se han implementado unos 10.000 programas distintos (aunque en las estadísticas sólo dan unos 6000 sumando implementaciones de map y reduce). Se ejecutan unos 100.000 trabajos de media utilizando este framework que procesan unos 20 petabytes al día. Muy impresionante, desde luego.
Entre las aplicaciones que usan MapReduce, están las que ya comentaron en su momento: problemas de machine learning, froogle y Google News, Google zeitgeist, y alguna otra. Han añadido a mayores Google Trends, el procesado de imágenes por satélite (asumo Google Earth y Google Maps), y el procesado de modelos de lenguaje para traducción (Google Translator?).
Lo más jugoso es la tabla resumen que muestran en el artículo:
Si queréis ampliar conocimientos sobre MapReduce y toda la infraestructura de computación de Google, probablemente el mejor recurso es el curso sobre sistemas distribuidos que se puede encontrar en Google Code, donde hay mucho material interesante.
También puede que sea interesante (no lo he visto) el video sobre MapReduce en sistemas multicore que publicaron en Febrero del año pasado y del que también está disponible la publicación original.
miércoles, enero 09, 2008
Dos documentos sobre software factories y costes de desarrollo
miércoles, enero 09, 2008 por Martín
Tenía pendiente publicar un artículo sobre un documento que vi en el blog de Kybele Consulting y Javier Garzás me lo ha puesto hoy todavía más fácil.
La entrada que quería publicar era sobre la ponencia consideraciones económicas sobre la fabricación de software que Javier publicaba en el blog de su compañía hace unas semanas. Se trata de una presentación muy interesante y que analiza algo que muchas veces los técnicos nos olvidamos de pensar que es el coste real que puede tener el aplicar una refactorización, buena práctica o patrón para el negocio.
Hoy mismo, también se puede encontrar en su blog otro documento muy interesante. Es un mindmap de los principales factores a tener en cuenta a la hora de mejorar o implantar un departamento, equipo o software factory.
Ambos documentos muy interesantes.
La entrada que quería publicar era sobre la ponencia consideraciones económicas sobre la fabricación de software que Javier publicaba en el blog de su compañía hace unas semanas. Se trata de una presentación muy interesante y que analiza algo que muchas veces los técnicos nos olvidamos de pensar que es el coste real que puede tener el aplicar una refactorización, buena práctica o patrón para el negocio.
Hoy mismo, también se puede encontrar en su blog otro documento muy interesante. Es un mindmap de los principales factores a tener en cuenta a la hora de mejorar o implantar un departamento, equipo o software factory.
Ambos documentos muy interesantes.
martes, enero 08, 2008
Oooh ¡Un Java pub quiz!
martes, enero 08, 2008 por Martín
Los chicos del JUG de Dublin son realmente originales y se les ha ocurrido organizar un ¡Java Pub Quiz!
Los que no sepáis lo que es un pub quiz pues se trata de una costumbre muy británica. Se reune un grupo de gente en un pub y se juega a una especie de trivial en las que se van haciendo preguntas y los diferentes equipos que se forman las van contestando. Aquí es común tener este tipo de concursos los días entre semana cuando los pubs no tienen mucha gente, ya que sirven para traer personas y que consuman más alcohol claro.
Mis compañeros ya me han dicho que pasan. No sé si me animaré pero está claro de que esta sería la única posibilidad que tendría de ganar un pub quiz por aquí :D
Los que no sepáis lo que es un pub quiz pues se trata de una costumbre muy británica. Se reune un grupo de gente en un pub y se juega a una especie de trivial en las que se van haciendo preguntas y los diferentes equipos que se forman las van contestando. Aquí es común tener este tipo de concursos los días entre semana cuando los pubs no tienen mucha gente, ya que sirven para traer personas y que consuman más alcohol claro.
Mis compañeros ya me han dicho que pasan. No sé si me animaré pero está claro de que esta sería la única posibilidad que tendría de ganar un pub quiz por aquí :D
domingo, enero 06, 2008
Granjas, fábricas y nubes, el futuro de la computación
domingo, enero 06, 2008 por Martín
Según Julio Guijarro y Steve Loughan ambos miembros del grupo de investigación que tiene HP en Bristol ese es el futuro de la computación distribuida. Julio y Steve han publicado el pasado Diciembre una presentación muy interesante en la que hablan de como los modelos de servidor único y de un cluster de servidores han quedado obsoletos en favor de un modelo de granja con cientos de servidores donde el sistema de ficheros es distribuido y el almacenamiento y la CPU se alquila. Se trata de una infraestructura ágil, como ellos la denominan, y que tenderá en el futuro a una gran fábrica de grids con decenas de miles de servidores
Esta evolución se sustenta en la base de que las arquitecturas actuales han anulado ciertas asunciones que en el pasado eran verdaderas pero que Julio y Steve afirman que ya no lo son. Pongo la lista a continuación ya que aunque es posible que no se esté de acuerdo de todo me parece un buen resumen sobre las consecuencias arquitectónicas que tienen algunas tendencias actuales.
Arquitectura: Virtualización. Asunciones que ya no son ciertas:
Arquitectura: Granjas de servidores. Asunciones que ya no son ciertas:
Arquitectura: Map/Reduce. Asunciones que ya no son ciertas:
Arquitectura: Sharding. Asunciones que ya no son ciertas:
El análisis realizado me ha parecido muy interesante. El argumento central de la presentación es que la computación poco a poco se está conviertiendo en una commodity, como las granjas que nos preparan la comida o las fábricas que nos hacen la ropa.
Sistemas sobre los que he estado hablando continuamente en los últimos meses, como S3, EC2, la nueva SimpleDB o Hadoop han cambiado la forma de entender la computación distribuida y, concretando en el caso de Amazon, proponen un modelo de renting muy atractivo que permite a pequeñas startups ponerse a la altura de grandes corporaciones.
Por cierto, que no lo había comentado, Julio Guijarro es el líder del proyecto SmartFrog, que personalmente no conocía y que tiene como objetivo el proporcionar una tecnología que describa sistemas de software distribuidos como colecciones de componentes manejables y activables. Por la descripción se me antoja como algo similar a Dryad de Microsoft. Eso sí, éste está liberado bajo licencia LGPL.
Esta evolución se sustenta en la base de que las arquitecturas actuales han anulado ciertas asunciones que en el pasado eran verdaderas pero que Julio y Steve afirman que ya no lo son. Pongo la lista a continuación ya que aunque es posible que no se esté de acuerdo de todo me parece un buen resumen sobre las consecuencias arquitectónicas que tienen algunas tendencias actuales.
Arquitectura: Virtualización. Asunciones que ya no son ciertas:
- Los sistemas permanecen activos por enormes espacios de tiempo.
- Crear un nuevo sistema es caro y lento.
- Duplicar un sistema existente es algo muy caro.
- Los sistemas deben controlarse manualmente.
- Los relojes están sincronizados.
- La RAM nunca se "swappea".
- Las máquinas que están en ejecución no pueden ser movidas y/o clonadas.
Arquitectura: Granjas de servidores. Asunciones que ya no son ciertas:
- El fallo en un sistema es un evento inusual.
- El 100% de disponibilidad se puede conseguir.
- Los datos siempre están cerca del servidor.
- Se necesita acceso físico al servidor.
- Las bases de datos son la mejor forma de almacenamiento.
- Necesitas tener millones de euros para ser un competidor en tu rama.
Arquitectura: Map/Reduce. Asunciones que ya no son ciertas:
- Es difícil trabajar con terabytes de datos.
- El código se ejecuta siempre en una única máquina.
- El código ejecutado secuencialmente es mejor que el código ejecutado en paralelo.
- La mejor forma para almacenar los datos es con sistemas RAID.
- Las bases de datos son mejores que los sistemas de ficheros.
Arquitectura: Sharding. Asunciones que ya no son ciertas:
- Una única granja puede escalar hasta el infinito.
- Necesitas proporcionar 100% de disponibilidad al 100% de tus usuarios.
- Cambios en la aplicación cambian la totalidad del esquema de base de datos.
El análisis realizado me ha parecido muy interesante. El argumento central de la presentación es que la computación poco a poco se está conviertiendo en una commodity, como las granjas que nos preparan la comida o las fábricas que nos hacen la ropa.
Sistemas sobre los que he estado hablando continuamente en los últimos meses, como S3, EC2, la nueva SimpleDB o Hadoop han cambiado la forma de entender la computación distribuida y, concretando en el caso de Amazon, proponen un modelo de renting muy atractivo que permite a pequeñas startups ponerse a la altura de grandes corporaciones.
Por cierto, que no lo había comentado, Julio Guijarro es el líder del proyecto SmartFrog, que personalmente no conocía y que tiene como objetivo el proporcionar una tecnología que describa sistemas de software distribuidos como colecciones de componentes manejables y activables. Por la descripción se me antoja como algo similar a Dryad de Microsoft. Eso sí, éste está liberado bajo licencia LGPL.
sábado, enero 05, 2008
Irlanda se enfrenta a un serio problema de falta de licenciados en ingenierías
sábado, enero 05, 2008 por Martín
Esto es lo que se podía leer el pasado Miércoles en esta noticia de Silicon Republic. Y aunque no os lo parezca, parece que es algo que aquí no le sorprende a nadie. Me perdonaréis que en esta entrada me centre en informática obviando otras ingenierías.
Hablando con mis compañeros todos vienen a coincidir que la carrera de informática en Irlanda poco a poco se ha ido devaluando estos últimos años, algo similar a lo que ha pasado en España. Alguna de las razones es que la informática se ha ido popularizando con el tiempo y ha pasado a ser algo que puedes aprender en cualquier parte, como un hobby, mientras que hace años prácticamente la única forma de hacer algo serio en esto era estudiando la carrera; en esa época el informático era ese ser superior capaz de dominar y programar algo llamado ordenador que no todo el mundo tenía en casa. Ahora mismo la gente se decanta por estudiar otro tipo de carreras mientras que a mayores pueden estudiar por las tardes algún evening course en computación.
A eso hay que sumar que los informáticos por aquí encontraban salarios muy jugosos (los salarios no han crecido mucho en los siete u ocho últimos años) y todavía más jugosos si emigrabas a los Estados Unidos. No había tantos licenciados y por lo tanto se pagaba mucho dinero. Hoy por hoy, mis compañeros me comentan que a los jovenes no les atrae ya la informática. Es algo que está bien, que sirve para jugar con el ordenador, navegar por internet y disfrutar de las redes sociales y eso de la web 2.0, pero punto. Mejor estudiar leyes, finanzas, empresariales u otra cosa que por aquí hay bastante oferta también.
Eso sí, si os paráis a leer el artículo de Silicon Republic veréis que un recién licenciado entra a trabajar cobrando 33.000€ o más, que aunque el coste de la vida en Irlanda es bastante alto, pues para un irlandés que viva con sus padres y que acaba de salir de la facultad se me antoja como un pero que muy buen sueldo que incluso permite ahorrar bastante bien.
Bastante diferente a los 600,700 euros que te puedan ofrecer en España....
Hablando con mis compañeros todos vienen a coincidir que la carrera de informática en Irlanda poco a poco se ha ido devaluando estos últimos años, algo similar a lo que ha pasado en España. Alguna de las razones es que la informática se ha ido popularizando con el tiempo y ha pasado a ser algo que puedes aprender en cualquier parte, como un hobby, mientras que hace años prácticamente la única forma de hacer algo serio en esto era estudiando la carrera; en esa época el informático era ese ser superior capaz de dominar y programar algo llamado ordenador que no todo el mundo tenía en casa. Ahora mismo la gente se decanta por estudiar otro tipo de carreras mientras que a mayores pueden estudiar por las tardes algún evening course en computación.
A eso hay que sumar que los informáticos por aquí encontraban salarios muy jugosos (los salarios no han crecido mucho en los siete u ocho últimos años) y todavía más jugosos si emigrabas a los Estados Unidos. No había tantos licenciados y por lo tanto se pagaba mucho dinero. Hoy por hoy, mis compañeros me comentan que a los jovenes no les atrae ya la informática. Es algo que está bien, que sirve para jugar con el ordenador, navegar por internet y disfrutar de las redes sociales y eso de la web 2.0, pero punto. Mejor estudiar leyes, finanzas, empresariales u otra cosa que por aquí hay bastante oferta también.
Eso sí, si os paráis a leer el artículo de Silicon Republic veréis que un recién licenciado entra a trabajar cobrando 33.000€ o más, que aunque el coste de la vida en Irlanda es bastante alto, pues para un irlandés que viva con sus padres y que acaba de salir de la facultad se me antoja como un pero que muy buen sueldo que incluso permite ahorrar bastante bien.
Bastante diferente a los 600,700 euros que te puedan ofrecer en España....
viernes, enero 04, 2008
Los artículos más vistos en Pensamientos Ágiles en el 2007
viernes, enero 04, 2008 por Martín
Este es un blog bastante modesto pero la verdad es que estoy contento por haber sido capaz de generar tanto contenido este año. 217 entradas me parecen bastantes, incluso cuando mi idea inicial era no escribir demasiado. Pues bien, como ha pasado un año se me ha ocurrido que quizás estaría bien el mirar cuáles han sido los artículos que mas se han leido en este blog durante este año.
Y esta es la lista de los "ganadores":
Con el tiempo la lista cambiará. Como comentaba al principio, este blog no es precisamente famoso así que se mueve mucho por lo que va llegando por Google y se nota bastante cuando alguien menea un artículo o cuando se publica en barrapunto, incluso aunque sólo recoja unos cuantos votos.
Muchas gracias a todos los que leéis este blog que a fin de cuentas sois los que habéis construido este top 10.
Y esta es la lista de los "ganadores":
- Mucho tráfico + infraestructura sencilla = mucho dinero que contaba el éxito de plentyoffish.com (y que fue meneado en su día).
- Libro gratis sobre Struts 2. Ni que decir tiene que el gran culpable aquí es google y dan fé los 16 bookmarks en del.icio.us :-)
- jLibrary 1.1 disponible. Olé, aunque creo que la gente habrá llegado aquí también por google :-)
- Sobre software libre y las nuevas formas de encontrar trabajo (y III). Esperaba que este artículo estuviese más alto pero cuando lo publiqué no tuvo mucha repercusión. Un cuarto puesto no está mal de todos modos.
- Categorías en IT dentro de Irlanda (y otros países). También meneado aunque creo sin mucho éxito. Un quinto puesto para este post que explicaba las diferencias que me encontré en las categorías al comparar España e Irlanda en cuanto a mercado laboral en IT.
- Hadoop toma protagonismo. El sexto lugar para el post que presentaba Hadoop y hablaba de como cada vez más gente hablaba sobre él, valga la redundancia.
- Jugando con JIRA y Mylyn. En su momento tocó evaluar estas herramientas y de ahí salió este post situado en el séptimo puesto. Las entradas vienen de Google, eso sí, al final no adoptamos Mylyn. Mucho lío.
- Instrumentando clases Java con anotaciones y class weaving. Vaya, en un año poco prolífico en artículos me he encontrado con éste del que ya no me acordaba. Creo que de lo más técnico que he publicado en el blog.
- Construyendo aplicaciones con Maven 2 y Eclipse RCP. En el noveno puesto esta entrada que creo que está aquí por Google, ya que no creo que tanta gente pueda estar interasada en concretamente en construir aplicaciones con Maven 2 y RCP.
- Sobre Software Libre y las nuevas formas de encontrar trabajo (I). Y por último, pero no por ello menos importante el artículo original sobre la serie en la que hablaba de aprovechar el Open Source para encontrar el trabajo de tu vida, o casi.
Con el tiempo la lista cambiará. Como comentaba al principio, este blog no es precisamente famoso así que se mueve mucho por lo que va llegando por Google y se nota bastante cuando alguien menea un artículo o cuando se publica en barrapunto, incluso aunque sólo recoja unos cuantos votos.
Muchas gracias a todos los que leéis este blog que a fin de cuentas sois los que habéis construido este top 10.
jueves, enero 03, 2008
Utilizando HermesJMS con WebLogic
jueves, enero 03, 2008 por Martín
Alex me preguntaba en el post que escribí hace tiempo cómo utilizar HermesJMS con WebLogic Server.
Casualmente James Bayer publicó ayer una entrada en su blog donde explica como configurar HermesJMS para poder descubrir las colas y tópicos JMS en WebLogic Server. Una nota: si os da problemas lo de añadir weblogic.jar a un grupo de librerías (creo que con el don't scan debería estar todo bien) probad a simplemente añadir el weblogic.jar al classpath de HermesJMS.
Por cierto, para los que os dediquéis al software financiero, parece que HermesJMS tiene algunas funcionalidades para procesar mensajes FIX.
Casualmente James Bayer publicó ayer una entrada en su blog donde explica como configurar HermesJMS para poder descubrir las colas y tópicos JMS en WebLogic Server. Una nota: si os da problemas lo de añadir weblogic.jar a un grupo de librerías (creo que con el don't scan debería estar todo bien) probad a simplemente añadir el weblogic.jar al classpath de HermesJMS.
Por cierto, para los que os dediquéis al software financiero, parece que HermesJMS tiene algunas funcionalidades para procesar mensajes FIX.
Suscribirse a:
Entradas (Atom)
