Google presentará hoy Gears su apuesta para el desarrollo offline de aplicaciones Web

Quedan 3 horas para que comienze en Londres el Google Developers Day, una reunión global de todos los desarrolladores de Google. Independientemente de la amplia agenda de sesiones, el principal anunció del día parece que será Google Gears.

Google Gears es un plugin open source para navegadores web que ofrece un API Javascript para el desarrollo de aplicaciones que se pueden ejecutar tanto offline como online e independientemente del navegador. Parece ser que Gears ofrece, en sus 700K de tamaño, tres APIs: 1. para manejar objetos, 2. una base de datos relacional para almacenar los objetos y realizar búsquedas, y 3. un API para la sincronización de datos mediante Javascript.

Después de que Adobe haya apostado fuerte por Apollo este movimiento de Google parece encaminado definitivamente a popularizar este tipo de aplicaciones web "persistentes". ¿Estamos pues ante el futuro de la programación web?

Más sobre esto en la noticia en Techcrunch.

Como hacerse rico con un mini-juego de flash

El otro día comentaba como hacerse rico con una infraestructura sencilla. Hoy no me puedo resistir a comentar como hacerse rico con una arquitectura incluso mucho más sencilla.

Tan simple como: 1. coger una idea que funciona en alguna otra parte (por ejemplo WOW), 2. crear un mini juego en Flash, y 3. ver como ingresas 8.000 dólares al mes con el jueguecito.



No es exactamente rico, pero da para unos caprichos.

Fuentes:

How to get rich programming.
3 tips to profit from casual games.

Recovery-Oriented computing

Recovery-Oriented Computing (ROC) es (más bien era) un proyecto de investigación para la creación de servicios altamente fiables en internet. ROC se centra en la recuperación ante fallos, de hecho asume que no importa lo sólido o robusto que sea el software o el sistema analizado, ya que siempre existirá la posibilidad de fallo (humano, hardware, software).

Sus tres leyes básicas son:

• Las tasas de fallo de software y hardware son significantes y siempre aumentan.


• Los fallos no se pueden nunca predecir por completo de antemano.


• El herror humano, especialmente durante mantenimiento, es una de las mayores fuentes de errores.

Fuentes:
The Berkeley/Stanford Recovery-Oriented Computing (ROC) Project.
Wikipedia.

Meebo, cuando el cliente grande acecha

Me ha parecido bastante interesante el análisis que hacen en Businessweek de la situación actual de Meebo.

Si algo me ha enseñado mi trabajo actual es que no hay nada peor que tener a un "mega-cliente" en el cogote, presionando constantemente para obtener resultados para ayer, y tirando del proyecto a golpe de talonario y más personal. Parece que algo parecido le está pasando a Meebo. Todo el capital de riesgo que ha recibido hace que los inversores comiencen a pedir resultados. Y cuando estás sufriendo para construir un producto estable, llega un super cliente y empieza a exigir resultados. ¿No os suena?:

"Can we wait for two weeks after the launch?" asks Jen, 26. "They're dying for it now, now, now," Sternberg responds. "I want it to be really solid," Jen says, her leg bouncing against the black vinyl of her chair. Sternberg thinks for a moment and comes up with a compromise: "I'll tell them we're shooting for a week, maybe two--that we want a quality product."

¿Puede pasar Meebo de ser un producto para geeks a convertirse en otra historia de éxito de la web 2.0? ¿Es el factor diferencial las jornadas de trabajo de 14 y 16 horas?

En resumen, capital de riesgo, presión, dificultad para encontrar el personal adecuado, y muchas horas trabajando. Muy interesante lectura.

Java en tiempo real

Java Real-Time System 2.0 fue presentado por Sun Microsystems en la pasada JavaOne. Durante la última semana han aparecido unos cuantos enlaces sobre este sistema donde se explica a qué escenarios y sectores está orientado.

• The case for Real-Time in the Enterprise : Entrevista a Greg Bollella y Dave Hofert, distinguished engineer y manager de Sun Real-Time Java Marketing respectivamente, en la Java One.
• Real-Time Garbage Collection : Una nueva entrevista a Bollella y Hofert, sobre como funciona la recolección de basura en estos sistemas.
• El podcast de Javaposse donde la segunda parte está también dedicada a Java Real-Time System 2.0 y donde también participan Bollella y Hofert.

Los tres enlaces anteriores son podcasts.

Por otra parte BEA Systems no se queda atrás y anuncia WebLogic Event Server una versión ligera de su servidor de aplicaciones, y WebLogic Real Time 2.0, que aseguran ofrece pausas de tan sólo 10 milisegundos.

En este artículo de BEA es donde se pueden leer las notas más interesantes. Como que según ellos, Java RTS pone realmente en apuros a las aplicaciones nativas escritas en C/C++ en cuanto a escalabilidad y rendimiento, o como uno de sus clientes dentro de los servicios financieros perdía 200.000 dólares al día hasta que comenzó a utilizar WebLogic RTS. Según promocionan en WebLogic, WebLogic Event Server es capaz de soportar la evaluación de 10.000 reglas y la ejecución de 50.000 transacciones complejas por segundo (no hay datos sobre el hardware utilizado para el test).

Mucho tráfico + infraestructura sencilla = mucho dinero

Lo más habitual en los casos de éxito en Internet es leer historias acerca de pequeños proyectos que han ido creciendo y creciendo hasta conseguir hacerse un hueco entre los más grandes del sector (léase flickr, youtube, twitter, digg, ...). Una vez que estas compañías alcanzan la fama es habitual ver a sus creadores rondando por diferentes conferencias explicando como han conseguido aumentar su escalabilidad, como ahora tienen 40 servidores para las diferentes capas del sistema, o mismamente como han pasado de ser tres personas a 40 en los últimos seis meses. Nadie duda que sean casos de éxito.

Sin embargo, el Wall Street Journal se hace eco hoy de un caso especialmente atípico, y que yo no conocía, por eso le dedico esta entrada en el blog. Se trata de plenty of fish. Si hacéis click en el enlace veréis que se trata de una web de citas, pero con la peculiaridad de que es una web de citas "free", es decir, que no requiere ningún tipo de pago por usar sus servicios. Como bien se puede leer en el WSJ, en estos momentos el portal creado por Markus Frind está entre los 100 sitios más visitados de Estados Unidos.

Hasta aquí podemos pensar que la única peculiaridad de este sitio es que ofrece un servicio de citas gratuito. Pues no. Lo que hace verdaderamente especial a este caso de éxito es que la empresa del señor Markus tiene exactamente 1 empleado, es decir, el mismo (bueno, más la novia que parece ser que ahora le ayuda a enviar emails). Pero no sólo no ha aumentado el número de empleados, sino que además el sitio web se sostiene simplemente sobre una arquitectura minimalista y unos cuantos servidores (media docena según WSJ) alojados en un servicio de host externo (aqui me pierdo un poco porque en su web Makus afirma utilizar un único servidor, pero en WSJ afirman que usa seis externos. Quizás éstos sean de almacenamiento).

Pero, ¿cómo puede una arquitectura así sobrevivir a la carga que imponen 1.2 millones de miembros activos, miles de ellos activos pidiendo cientos de páginas por segundo? La clave según desvela Markus es Akamai, que sirve la mayor parte de las 100 millones de imágenes que se piden diariamente, y aunque el único servidor web puede servir decenas de millones, según Markus la mayoría están en sus 8 gigas de RAM así que no es ningún reto.

De todas formas, servir 100 millones de imágenes a través de Akamai, no es algo barato como bien señalan en DataCenterKnowledge. Pero la verdad es que viendo los ingresos de Markus a través de AdSense, no debe ser ningún problema para él.

Y ahí es a donde quería llegar yo. Con una arquitectura minimalista y con una empresa formada por un único empleado y medio, este hombre es actualmente un mito del AdSense. Ingresando nada más y nada menos que 10.000 dólares diarios, Markus afirma en WSJ que PlentyofFish genera entre 5 y 10 millones de dólares al año (aquí un cheque por dos meses que mostró hace un año), y sólo con ads, sin requerir ningún tipo de registro o membership como hacen las compañías que tradicionalmente ofrecen estos servicios.

En mi opinión se trata de un ejemplo espectacular de como monetizar una idea simple, con una arquitectura simple, sin un diseño atractivo, sin toda la parafernalia del "2.0" o sin tener que crecer y crecer en número de empleados, y todo únicamente basándose en el negocio de anuncios online y sin requerir ningún tipo de registro ni coste para el usuario.

Como nota a parte, está claro que la temática y el perfil de usuarios del sitio web influyen mucho en los ingresos. Este blog no tiene tantos usuarios, pero aunque los tuviese no generarían tanto dinero simplemente porque lo frecuentan personas que no suelen pinchar en los anuncios de google (por cierto, gracias a todos los que pincháis :D). Pero está claro que un negocio orientado a gente que si que hace click puede ser potencialmente muy rentable.

Libro gratis sobre Struts 2

En InfoQ están ofreciendo gratuitamente el libro Starting Struts 2 de Ian Roughley. Es un mini libro de 111 páginas así que parece lectura fácil.

El open source puede ser barato pero todavía queremos soporte

Esta parece ser la conclusión que extraen en Reg. Developer sobre el panel que ayer se podía ver en la Open Source Business Conference, evento celebrado en California.

En este panel, representantes de diferentes compañías comentaban, y parecían coincidir, como el Open Source les ha ayudado a reducir el coste en licencias enormemente incluso ayudándoles a comenzar proyectos que de otro modo sería imposible arrancar, pero que todavía dependían de start-ups para obtener soporte.

Otra de las preocupaciones más importantes era el que los desarrolladores de Open Source se centraban principalmente en ciertas características del software (asumo que se refiere a las más excitantes) y dejaban de lado otras (asumo que serán las más aburridas).

Como ventaja, algún conferenciante nombró que el Open Source les servía para librarse de la tiranía de las marcas comerciales en cuanto a timelines, y que contribuir a productos OSS les permitía realmente ganar control sobre la evolución de dichos productos.

Leyendo el artículo, la conclusión más importante que saco es que a las empresas no les importaría el pagar mucho más dinero en soporte a cambio de obtener un nombre de prestigio detrás de un producto Open Source. En realidad, se trata de una cuestión mucho más política que práctica. Es el preferir tener a un gigante detrás en lugar de a una start-up, aún a costa de tener que pagar un impuesto de fama adicional.

Buen artículo sobre NIO 2

En artima han publicado una entrevista muy buena. a Alan Bateman, líder del JSR-203 (JSR 203: More New I/O APIs for the JavaTM Platform ("NIO.2")).

En el artículo se explican claramente las diferencias entre NIO y el futuro NIO 2 que aparecerá en Java 7. Entre las principales mejoras:

• Nueva implementación de java.io.File con más rendimiento y funcionalidades.
• Interfaz para monitorizar cambios en el sistema de ficheros (ej. editores).
• Posibilidad de crear interfaces para sistemas de ficheros propios (ej. en memoria, en base de datos, en S3, ...).
• Soporte de multicast para sockets
• Nuevo modelo de entrada y salida basada en eventos para ficheros y sockets en lugar de polling

La parte final del artículo/entrevista está realmente bien ya que explica las ventajas de la entrada y salida basada en eventos en frente al actual sistema asíncrono. Básicamente la clave es:

The Selector in the current API can deliver great performance and scalability when mapped to an operating system that has a highly scalable polling interface—both Solaris and Linux have such interfaces for example. Asynchronous I/O delivers great performance when the underlying operating system has a high performance and scalable asynchronous I/O facility. The application and server design is also critical.

De todos modos, aún habrá que esperar bastante.

¿Está Ruby en decadencia?

Hoy he podido ver como en algún blog citan el informe de TIOBE para el mes de Mayo en el que parece que el uso de Ruby no ha crecido durante los dos últimos meses e incluso ha decrecido. Citando al informe:

Although, Ruby is the rising star if you look back 1 year, it is not growing more the last couple of months. Even worse, since April it is slightly declining. If this appears to be the new trend, then also Ruby does not become the "next big programming language.



Una vez dicho esto, la verdad es que me parece un análisis bastante sensacionalista. Tanto como el título de este tópico :-) Simplemente no se puede pronosticar la tendencia de un lenguaje a partir de sus resultados en los dos últimos meses, especialmente cuando el lenguaje es tan joven, y es totalmente normal que esté sujeto a altibajos. No siempre va a mantener la espectacular subida del último año.

Incluso en el caso de que Ruby mantuviese la tendencia y se quedase estancado, sería algo absolutamente normal. Hay que pensar que a corto plazo el objetivo de Ruby es llegar a la línea marcada por PHP, no a la línea marcada por Java. Ruby no tiene todavía calado empresarial como para plantearse siquiera ese objetivo. Ruby ha estado subiendo a costa de restar desarrolladores especialmente a lenguajes de programación como Java, pero realmente lo que le debe hacer subir es el restarle programadores a su competidor directo.

A todo esto, hay que sumar que determinados proyectos en Java deben haber contribuido a frenar el avance de Ruby. Mucha gente seguro que prefiere utilizar JRuby o Grails ahora que el soporte de el modelo Ruby on Rails es mucho mejor y más estable, simplemente porque pueden seguir aprovechando todo lo que ya existe sobre Java.

Eventualmente, y en el hipotético caso de que esta tendencia se mantuviese, entonces estaríamos ante la definitiva prueba de madurez de la comunidad Ruby. Significaría que ha alcanzado su base de usuarios estable, y obligaría a toda la comunidad a crear nuevos productos bandera que como Ruby on Rails permitan dar un nuevo salto hacia arriba, y eventualmente acercarse más al mundo de la empresa.

Así que resumiendo mi opinión, estoy seguro de que Ruby todavía tiene cosas que decir.

Patrones de eventos

En InfoQ publican una presentación de Ian Cartwright de Thoughtworks sobre Event patterns creada en colaboración con Martin Fowler.

La presentación expone diferentes patrones orientados a sistemas asíncronos basados en eventos: broadcast de eventos, repetición de secuencia de eventos, snapshots de eventos, colaboración basada en eventos.

La verdad es que el haber trabajado durante estos últimos 10 meses en un sistema de trading basado en eventos como el que se describe una charla te da una visión completamente diferente de este tipo de sistemas. El cambio de forma de pensar que supone el migrar de una arquitectura síncrona a un modo de ejecución asíncrono creo que vale mucho la pena. Sólo entonces eres consciente en realidad (y no sólo en libros) de el aumento de la capacidad de escalabilidad y resistencia a errores que se obtiene sólo con cambiar el chip.

¿El problema?: Que te encuentras con nuevos retos como garantizar el envio de eventos, el gestionar y controlar todos esos eventos en memoria, el mantener un buen sistema de auditoría o el mantener un buen sistema de subscripciones para evitar brodcasts innecesarios.

Otras dos sobre escalabilidad: S3 y Ruby on Rails.

Dos más para tener en cuenta:
Set Amazon servers on fire, not yours.
Scaling scribd

Lecciones aprendidas al crear last.fm

Matthew Ogle y Anil Bawa Cavia explican en el FoWA 2007 todo lo que han aprendido durante los tres años de vida de last.fm No es una charla técnica sino más bien trata sobre como dirigir comunidades, como tratar tu contenido, como monetizarlo, como fomentar la interacción, y estas cosas. Interesante de todos modos.

Está en En slideshare.

Google developer podcast

Un nuevo podcast para el saco. Como el nombre indica en él hablarán ingenieros de Google sobre temas diversos. Entre los participantes, Dick Wall and Carl Quinn de JavaPosse.

Los peligros de GC ergonomics

Jon Masamitsu es el maestro de la garbage collection en Java y hace un par de semanas publicó una entrada muy interesante sobre como, y lo más importante, por que, alterar los valores de GC ergonomics.

GC ergonomics es un sistema que corre paralelamente al garbage collector y va ajustando los tamaños de los diferentes espacios del heap de modo que se ajusten mejor al funcionamiento aparente de la aplicación. De este modo, si la aplicación no tiene mucha actividad, GC ergonomics reducirá el tamaño del heap (de sus secciones en bases a factores de reducción individuales), y si la aplicación requiere más objetos entonces ampliará el tamaño.

El problema es que hay muchas aplicaciones a las que no les interesa este funcionamiento, porque en caso de que haya mucha actividad y que ésta no siga unos patrones predefinidos entonces el sistema de GC ergonomics puede hacer más daño que ayuda moviendo constantemente los límites y ocasionando major garbage collections innecesarios.

En el blog explica varios truquillos para tunning o como desactivar el sistema de GC ergonomics que en algunos casos es simplemente lo mejor.

¿Son los applets el auténtico AJAX killer?

Mientras la gente todavía se está preguntando como se va a distribuir JavaFX en la JavaOne 2007 el equipo de Jasper Potts demostró la potencia que se puede conseguir al mezclar los mundos de JavaScript y Applets.

Jasper realizó una demo impresionante sobre como reaccionar desde applets a eventos Javascript y viceversa. En la demo se muestra como realizar cosas que actualmente no es posible desde AJAX como la gestión de threads, el interactuar con el escritorio o el aprovechamiento del hardware 3D, y todo ello parece que soportado en todos los navegadores más importantes.

Ellos lo llaman la nueva generación de Applets, y desde luego que lo parece.

Muy bueno. Echarle un vistazo al video porque vale la pena verlo.

HermesJMS, monitorización Open Source de sistemas de mensajería

Hoy he estado jugando con HermesJMS y la verdad es que me parece que ofrece un buen valor (0 euros, es código abierto) para lo que ofrece. Es un producto bastante conocido si no me equivoco pero nunca había tenido la suerte de probarlo.

Lo he estado probando con ActiveMQ y con el proveedor JMS de WebLogic y funciona con ambos, aunque con este último es necesario hacer algún pequeño truquillo para esquivar el mamut que es "weblogic.jar". La herramienta te permite monitorizar todas tus colas, tópicos, ver su contenido en tiempo real, ver en detalle los mensajes que se van transmitiendo o monitorizar la longitud de las colas entre otras cosas.



Una de las formas más sencillas de tirar abajo un servidor de aplicaciones es el no configurar correctamente los sistemas de mensajería. Un pequeño error puede hacer que los mensajes se vayan acumulando en las colas, con lo que en cuestión de minutos, horas o días el servidor se caerá abajo con un espléndido OutOfMemory. Con una herramienta de este estilo puedes monitorizar la salud de tu sistema sin demasiadas complicaciones y sin recurrir a productos caros y más complejos.

Y hablando de empujones: Joost y Spring

Otros dos productos muy de moda que reciben empujones:

Interface21 (Spring) gets 10M VC Funding

Joost Announces $45 million Funding From Sequoia, Index, CBS & Viacom

Algunos enlaces sobre HTTP

Algunos enlaces sobre HTTP. Viejos pero siempre útiles:

HTTP/1.1 Pipelining FAQ
Reusing socket connections with HTTPUrlConnection
HTTP persistent connections

Intel le da un empujón a Jajah

No está muy al hilo de la temática de este weblog pero no me resisto a comentar aquí esta noticia. Parece que Jajah ha recibido un empujón más que considerable de Intel, nada más y nada menos que 20 millones de dólares en capital de riesgo.

La guerra está servida. Intel era partner de Skype pero por lo que se intuye de las declaraciones de estos últimos la relación va a enfriarse.

Yo, por mi parte, probaré Jajah que ya tocaba.

Artículo sobre las soluciones de virtualización de BEA

Dentro del portal Arch2Arch de BEA hay un interesante artículo de hace unos días en el que explica la base de la solución de virtualización de BEA.

La idea que propone su Liquid IBM es, si no he leido mal, básicamente el ejecutar las instrucciones Java directamente sobre los nuevos hypervisors que a su vez se ejecutan directamente sobre el hardware, por lo que no se necesita un sistema operativo. Con esta solución, un programa Java se saltaría dos capas de indirección y conseguiría el suficiente rendimiento como para que las soluciones de virtualización tengan realmente sentido. En el camino se pierden bastantes funcionalidades, básicamente todas las que requieran un sistema operativo (por ejemplo el interfaz de usuario), pero parece una solución muy atractiva para aplicaciones de servidor.

Sea como sea, el artículo lo explica mejor que yo.

Introducción a Tomcat 6

Covalent ha publicado una Introducción a Tomcat 6 como parte de su serie de webinars. La próxima semana probablemente estará el audio, pero por ahora ya se pueden descargar las transparencias. No es demasiado técnico pero está bien para tener sumarizadas todas las novedades.

Lo malo: requiere registro en su web.

Se acerca la nueva versión de Google Analytics

Ole! Parece ser que se acerca la nueva versión de Google Analytics. Informes al email, cuadro de control personalizado, gráficos de comparación entre periodos. Hasta han puesto un tour.

Que software más bueno. De lo mejor de Google.

¿Es Spring el nuevo Java EE?

Me ha parecido interesante el artículo de Salil Deshpande, ex CEO of The Middleware Company, publicado en su ex-portal TheServerSide.

Sobre todo porque es un poco un recordatorio de lo que ha pasado en los últimos tres años. Y además tiene toda la razón. ¡Es que parece que fue ayer! El artículo va muy en la línea de este post de hoy mismo de Ignacio Coloma. Hay que reconocer que Spring se ha impuesto al yugo de toda especificación posible, y además con el mérito de haber hecho de AOP una cosa habitual, hasta el punto de que probablemente nadie utilizará AOP si no existiese Spring. Probablemente algo parecido pasará con OSGi que parece ser la nueva baza de los chicos de Interface21.

Pero volviendo al artículo original, personalmente, yo ya sabéis que soy gallego, y en fin, que ni lo uno ni lo otro, que hay sitio para todos. Nosotros utilizamos Spring, pero también tenemos nuestro servidor de aplicaciones que nos ayuda en muchas cosas que de otro modo nos complicarían muchísimo la vida el hacerlas nosotros a mano (léase mensajería ... bueno, ejem, ... ayuda mmmm ... , clustering y failover, integración con third parties, bla bla bla).

De cualqueir modo, el mérito de Spring es impresionante. Sobrevivir manteniéndose al márgen de los estándares y convertirse en estándar de facto tiene realmente muchísimo mérito.

Graded Browser Support

Como hoy hemos definido nuestro soporte oficial de navegadores en la empresa, pues se me ha ocurrido el dedicarle unos parrafos a esto en el blog. A ver que os parece.

Graded Browser Support es un enfoque creado por Yahoo para tratar de mantener controlado el soporte de diferentes navegadores web en un producto.

Con el paso de los años y al hacerse cada vez más y más comúnes nuevos navegadores y sistemas operativos, las empresas de software se encuentran con que es cada vez más y más difícil el garantizar que un producto funciona bien en una plataforma determinada ya que el número de combinaciones es cada vez mayor.

Como mínimo, una aplicación web tendrá que afrontar al menos la combinación Sistema Operativo + Navegador Web (10.000 posibles combinaciones según Yahoo), y eso en caso de que sea una aplicación web para el usuario final. En caso de ser una aplicación orientada a la empresa, tendrá que tenerse en cuenta también el servidor web en el que se desplegará. Por último, en caso de ser un applet, el plugin Java aparece como una vuelta de tuerca más a la combinatoria.

La aproximación de Graded Browser Support resuelve este problema presentando diferentes grados de soporte. Esta aproximación presenta una serie de grados que van de mayor a menor soporte.

En el grado de mayor soporte, Grado A por ejemplo, el usuario tiene garantizado que la aplicación ha sido completamente probada y que todas las funcionalidades se encuentran disponibles. Normalmente los equipos de tests ejecutarían todas las pruebas posibles sobre este tipo de configuraciones. Un ejemplo podría ser: Java Plugin 1.5.0_11 + Firefox 1.5 + Windows XP SP 2.

Conforme se va descendiendo a través de la pirámide de grados, el nivel de soporte va disminuyendo. Así por ejemplo Grado B podría ser Java Plugin 1.6.0_01 + FireFox 1.5 + Ubuntu 7.04. Grado C, Java Plugin 1.5.0_04 + IE 7.0 + Windows Vista, etc. etc. Conforme se va bajando en los grados, el nivel de seguridad en las funcionalidades del producto disminuye. El equipo de test ejecutará sólo un subconjunto de las pruebas para las funcionalidades más básicas, es decir, medida que se desciende en la pirámide, el número de pruebas es menor. Eso no quiere decir que el resto de funcionalidades no vayan a funcionar correctamente. Simplemente quiere decir que el producto está menos probado en esas plataformas.

Ya acabando, un Grado X representaría todas las combinaciones extrañas en las que el producto no ha sido probado. Esto no significa que no funcione, sino simplemente que el equipo de test no ha ejecutado ningún tipo de prueba. Pues por ejemplo: Java Plugin 1.5.0_04 + Safari 1.2 + Mac OS X, por poner algo.

Y por último podríamos añadir el grado "No soportado" que simplemente representaría configuraciones que no se soportarán de ninguna de las maneras. No quiere decir que no se sepa si va a funcionar o no, sino que se está completamente seguro de que no se puede ejecutar el programa con esa plataforma. Pues por ejemplo en cualquier navegador que tenga instalado el Java Plugin 1.3.1

Bueno, aquí quizás os he mentido un poquito porque Graded Browser Support sólo define realmente tres niveles, que son los que he puesto en negrita, es decir el A, el C y el X. Pero bueno, en mi opinión cada uno puede adaptar esta idea y añadir los niveles que crea conveniente. Lo importante es el concepto y facilitar el trabajo de los desarrolladores, de los equipos de test, a la vez que se ofrece al usuario una serie de garantías bajo una serie de plataformas, todo documentado y bien clarito.

Google recibe 1300 curriculums al día

Si quieres trabajar en Google está claro que lo mejor es tener paciencia porque el proceso de selección puede ser largo. En el show de Oprah hicieron un reportaje sobre la vida en Googleplex y al final Oprah afirma que Google está actualmente recibiendo nada más y nada menos que 1300 curriculums al día.

Hace poco Google fue reconocida como la marca más importante del mundo y se ve que debe ser cierto porque la gente está loca por trabajar ahí.

Terracotta vs JBossCache

Interesante documento que muestra un caso de uso de Terracotta frente a JBossCache. Obviamente gana terracotta porque el documento viene de su web, pero resulta interesante ver la aproximación al Caching desde el punto de vista de esta herramienta. No obstante sería mucho más interesante ver una comparación frente a caches mas serias como los productos de Tangosol o Gigaspaces.

El código fuente está disponible por si alguien se anima a jugar.

Galicia Global

Galicia Global es un sitio web donde se pueden registrar todos los gallegos, más que nada para demostrar que estamos en todas partes, aunque recurriendo un tópico la verdad es que al mapa le falta la luna.

Escalando flickr

Cal Henderson project lead the Flickr dio esta interesante presentación en la Web 2.0 Expo hace dos semanas. La presentación queda un poco sosa sin más que las slides pero no he sido capaz de encontrar nada como el audio o una descripción de lo que dijo (tampoco he buscado mucho), así que si alguien tiene algún enlace mejor se agradecería.

Actualización. En la misma conferencia Cal Henderson dio otra charla: Scalable Web Architectures. No la he visto todavía.

Las claves en la arquitectura de base de datos de digg: memcached y sharding

Leo en ComputerWorld que el pasado Martes, Eliott White III estuvo hablando en la conferencia anual de MySQL. Ahí estuvo comentando algunos detalles interesantes sobre la arquitectura de digg que parece que ha llegado ya a los 1.2 millones de usuarios registrados. Me permito recapitular aquí algunos datos:

• 100 servidores desplegados sobre varios data center alojando 30 gb de datos.


• Un balanceador de carga que envia las consultas a servidores PHP. Servidores MySQL esclavos proveen de datos a los servidores PHP, mientras que uns ervidor MySQL maestro provee de datos a los servidores esclavos.


• Para evitar el sobrecargar la base de datos con consultas utiliza memcached. Memcached almacena porciones compactas de datos que se pueden utilizar para crear dinámicamente una página web. Esto lo diferencia de servidores de cache web tradicionales que almacenan la página completa. Otros sitios conocidos que utilizan memcached son Wikipedia, Sourceforge, Slashdot o Livejournal.


• Para hacer las consultas más eficientes hacen lo que se ha denominado recientemente como Sharding. Consiste en dividir una base de datos enorme en varias bases de datos más pequeñas de modo que el acceso sea mucho más eficiente. La base de datos se puede dividir por tablas, rangos, fechas, usuarios, etc. MMORPGs populares como EVE Online o World of WarCraft utilizan esta técnica para controlar las ingentes cantidades de datos que manejan.
  
  Los comentarios de White sobre Sharding son muy interesantes. Como bien dice, existen diferencias fundamentales entre particionar una base de datos y realizar sharding, siendo quizás la más importante que los shards suelen estar en máquinas diferentes, como sería por ejemplo el tener mundos diferentes en data centers diferentes en un MMORPG.
  
  White añade que el concepto de Sharding pone complejidad sobre el desarrollo ya que imposibilita el hacer operaciones habituales como joins sobre tablas.
  
  Aparentemente ingenieros de Google fueron los que acuñaron el término de Sharding. Este artículo en ZDNet muestra su uso dentro de su sección financiera. Hace poco Google contribuyó un proyecto de Shards en Hibernate.
  


• 20 servidores de bases de datos.


• 30 servidores web.


• Varios servidores de búsqueda ejecutando Lucene.


• Todos los servidores menos uno corren sobre MySQL 5. Los servidores con más carga transaccional así como las unidades de backup utilizan el motor InnoDB, mientras que los servidores OLAP utilizan MyISAM.


• Arquitectura inusual ya que el 98% de las operaciones son lecturas.

Interesante.