Patrones de uso para volatile en Java

Brian Goetz gurú de la concurrencia en Java y autor del aclamado Java Concurrency in Practice ha publicado un excelente artículo en developerWorks titulado Managing volatibility en explica como funciona la palabra volatile en Java el que expone diferentes patrones para su uso.

Básicamente la diferencia entre volatile y utilizar synchronized es que volatile sólo te garantiza la visibilidad entre threads para esos atributos una vez que sus valores son modificados, mientras que synchronized te garantiza también la exclusión mutua. Utilizar volatile suele ser más barato a la hora de escribir que el adquirir locks pero plantea riesgos en cuanto a thread-safety que realmente hacen que sólo se utilice cuando realmente se sabe lo que se está haciendo. Ahí es donde Brian Goetz hace realmente un excepcional trabajo exponiendo varios patrones para su uso. Me permito resumirlos aquí:

• Variables de estado: El caso más típico, marcar como volatile el típico atributo true/false. Las operaciones son simples y la visibilidad del estado es inmediata.


• Inicialización única: Utilizar volatile para la típica inicialización perezosa de un objeto. El ejemplo típico sería el idioma double-checked-locking.


• Publicación de estado de variables públicas: Tener variables públicas que otros threads estarán observando. Al actualizar el estado estas variables volatile lo reflejarán inmediatamente.


• Beans volatiles: Declarar los atributos volatiles en el JavaBean y ofrecer métodos get/set simples sin ninguna operación adicional.


• Bloqueos baratos: La idea aquí es mezclar el uso de volatile y synchronized para mejorar el rendimiento. De este modo las operaciones que requieran thread-safety estarán sincronizadas y el resto simplemente manejarán el atributo volatile

Sobre Applets, latencia y bugs

En todas las tecnologías hay bugs. Es natural, ya que se supone que errar es humano. Pero dentro de los bugs, tenemos bugs en minúsculas y BUGS en mayúsculas. Son estos últimos los que pueden echar al traste con el éxito de una tecnología.

La semana pasada me encontré cara a cara con uno de estos últimos. Uno de estos que le pueden sacar los colores a cualquier empresa y que te hacen preguntarte, ¿pero como demonios ha estado este bug sin resolver durante diez años? Porque hay bugs, como en este caso, que realmente influyen en una plataforma, y que silenciosamente pueden estar minando la adopción de la misma contribuyendo en gran parte a que no tenga el éxito que debería tener. Son bugs justo dentro del corazón de la arquitectura.

Pero voy al grano. Imaginaros un Applet. Como muchos sabéis, un Applet se ejecuta en el navegador del usuario. La primera vez que se ejecuta el navegador se descarga todos los recursos necesarios, para que en sucesivas ejecuciones del Applet ya no sea necesario realizar este paso, y sea como lanzar un programa local con el consecuente aumento de rendimiento.

Pero, ¿qué pasa cuando el Applet no encuentra un recurso? Es decir, por ejemplo si utilizamos reflection para cargar una clase con un simple Class.forName("org.foo.Sample"); o cuando buscamos un fichero de propiedades Class.getClassLoader.getResource("test.properties") . Pues en este caso el comportamiento del ClassLoader del Java Plugin (AppletClassLoader) es el siguiente:

• Intentar cargar el recurso localmente.
• Si el recurso no está disponible, entonces cargar el recurso remotamente del lugar desde donde se descargó todo el contenido.
• Si no encuentra nada, simplemente lanzar un ClassNotFoundException.

El problema de este comportamiento, aparentemente normal y que huele a implementación inicial pensando en una carga perezosa de clases, es que cae en una de las falacias de la computación más habituales: asumir que la latencia es cero.

Alguno pensará, "bueno hombre, no es tan grave, total por un par de llamadas remotas que se hagan". El problema, es que no son un par. Swing (y esta es otra), por ejemplo, para todo JavaBean intentará cargar dinámicamente un objeto BeanInfo con el nombre del Bean. Así que por ejemplo si tienes un botón MyJButton, Swing intentará cargar MyJButtonBeanInfo cuando vaya a renderizar el botón. ¡Imaginaros esto para todos los componentes web de tu interfaz! Decenas, o cientos, de llamadas remotas destinadas a finalizar con un 404 porque no será capaz de encontrar esos recursos.

Lo realmente chocante en este bug es que ¿no se daba cuenta la gente de Sun que los Applets están pensados para Internet? Internet, señores, que no intranets. Que en Internet a lo mejor estás haciendo una demo a gente que está a decenas de miles de kilometros de ti y donde la latencia es más de 300 milisegundos en round-trip. Hagamos la cuenta fácil, 300 * 100 = 30 segundos desperdiciados en llamadas 404, y eso asumiendo una latencia bastante optimista. ¿Cómo se puede pretender que una tecnología tenga éxito si ya de antemano la diseñas para el fracaso?

Bueno, la buena noticia al final es que el bug está solucionado. La mala noticia es que lo han solucionado sólo en el JDK 6. Eso sí, en la página del bug podréis ver como afirman que se solucionó en el JDK 5. Pero va a ser que no, y eso que he probado con al menos tres revisiones. (4,6,11)

¿Y cómo se arregla el bug? Claro, porque resulta que en el bug report se han limitado a decir que está solucionado, pero no han hecho explícita la solución. Una idea muy brillante si tenemos en cuenta que estamos hablando de las clases del Java Plugin, que ni siquiera vienen incluidas en el código fuente del JDK cuando te lo descargas. Pues nada, que no me quedó otra que mirar dentro del OpenJDK y ver como lo habían solucionado. Es algo tan simple como añadir el siguiente parámetro al applet:

<param name="codebase_lookup" value="false"/>

¿Complicadísimo verdad? Pues aquí tenéis una de las razones por las que los Applets no han triunfado y que les ha llevado diez años corregir, y eso que mirando el código fuente del JDK estimaría que se trata de un cambio de unas 15 líneas más o menos echando por lo alto.

Pues nada, así está Java en el UI.

P.S. Una cosa que se me olvidaba comentar. Si os pica la curiosidad y queréis investigar el bug, la mejor forma de hacerlo es utilizar un capturador de tráfico web como Charles y un simulador de latencia como Shunra.

Google se desmarca de la virtualización

Hoy va de DataCenters. En un artículo muy interesante en TheRegister, Luiz André Barroso de Google realiza diferentes afirmaciones en las que prácticamente desprecia todo lo relacionado con la virtualización, siéndo el siguiente probablemente el párrafo más llamativo:


"I think it will be very sad if we need to use virtualization," he said. "It is hard to claim we will never use it, but we don't really use it today."

Como se puede leer en el artículo, Google, ha seguido y planea continuar con la estrategia de apliar miles de máquinas baratas montando DataCenters descomunales (ha anunciado 4 de estos DataCenters de más de 600 millones de dólares en los últimos meses). Esta estrategia choca frontalmente con la de comprar pocas máquinas pero muy potentes (y caras) y desplegar virtualizar ahí todo tu software.

Pero claro, esta estrategia se sienta sobre la base de decenas de ingenieros trabajando full-time para optimizar todo el código de multi-threading, multi-core y clustering, en lugar de delegar esta tarea en algún proveedor de hierro, algo que no todas las compañías se pueden permitir.

Ahora bien... ¿sobrevirán al consumo de energía? Lectura muy interesante.

¿Reventarías tu DataCenter para probar el failover?

Seguramente no, ¿verdad? En HP parece que lo saben y han hecho la prueba por nosotros. El video se puede ver en este enlace. En él, ingenieros de HP simulan una explosión de gas y se cargan unos cuantos racks más ... una pecera con tres pececillos de colores. Posteriormente muestran como los diferentes sistemas van recuperándose en otro centro de datos de backup.

Por cierto, que en algún blog critican el uso de los pececillos de colores. Aunque yo espero que no se hayan muerto en el experimento :)

¿Terracotta hace Oracle más barato?

Interesante análisis en RegDeveloper en el que afirman que Terracotta puede abaratar drásticamente el precio de las bases de datos, en particular Oracle.

Terracotta, un producto del que ya he hablado varias veces, permite realizar clustering a nivel de máquina virtual, posicionándose como un producto muy a tener en cuenta para la creación de cachés. Es ahí donde le puede hacer daño a las bases de datos, ya que sus creadores afirman que son capaces de reducir el impacto en las bases de datos hasta situarlo en tan sólo 1/5 de lo normal.

Pero claro, si esa afirmación es correcta, una consecuencia directa es que ya no se necesita una base de datos tan grande ni tan potente, que no se necesitan tantos nodos para servir la base de datos, o mismamente que una base de datos Open Source podría hacer perfectamente el trabajo.

Por lo que se lee en el artículo, parece que poco a poco van ganando clientes, entre ellos Goldman Sachs, y en campos importantes como el financiero o el de las telecomunicaciones. Así que habrá que estar al tanto.

¿Open Terracotta + MySQL? Sería interesante conocer experiencias.

Agilidad, Arquitectura y el problema de las 5 de la mañana

Hace unos días recomendaba el libro Release It!. Hoy, leyendo InfoQ he visto que Michael Nygard, el autor de libro, ha publicado el artículo Agile, Architecture and the 5am Production Problem en el portal.

El artículo es una parte de su libro. Se puede encontrar en la sección de antipatrones de estabilidad y muestra los problemas asociados con los puntos de integración. El artículo y todo el libro se centra en la importancia de la programación defensiva y el asumir que algo siempre va a fallar para sacar exitosamente software a producción, en lugar de diseñar el sistema simplemente para que pase las pruebas del equipo de calidad.

Si todavía estáis dudando si leeros el libro, quizás este artículo os pueda dar una idea de sobre lo que trata.

Morriña: Lumeiradas de San Xoan

Ya decía yo hace una semana que hoy tocaba otra vez morriña. 23 de Junio, Noite Meiga en Galicia Alban Heruin en Irlanda. El día en el que toda Galicia arde (no como lo hará en dos meses por culpa de los incendios) celebrando la noche más corta del año.



Como se puede leer en la entrada de la wikipedia, la fiesta en Galicia tiene un significado diferente al que tiene en otras partes de España. Se trata de auyentar a los malos espíritus, a las meigas, la noche para quitarse los malos de ojo.

La noche en la que es mejor no estar sólo, no acercarse a sitios abandonados o no adentrarse en los bosques porque es hoy cuando los espíritus son más propensos a aparecer. Y ahí de ti como te encuentres con La Santa Compaña.

Cuantas veces habré ido a recoger las Herbas de San Xoan con mi querida abuela para lavarse la cara al día siguiente y librarse de todas las envidias. Pero ojo, es importante dejarlas fuera porque es el orballo (rocio) lo que las purifica.

En fin, que en Coruña son especial. Podéis navegar por flickr para encontrar montones de fotos de las hogueras de San Juan en Coruña ya que son fiesta de interés turístico nacional.



PS 1. Se me olvidaba comentar que la morriña es menos gracias a que Bea y Txema nos han invitado a una verbena!

PS 2. Las fotos de las hogueras han sido sacadas por estorde y santamarta. Gracias!

Sobre Software Libre y las nuevas formas de encontrar trabajo (y IV) (Hacerse mercenario)

Como muchos sabéis, hace unos meses escribí una serie de artículos en los que trataba de resumir muchas de las formas con las que hoy en día se puede encontrar trabajo gracias al Open Source, algo que hace unos años era impensable:
Sobre Software Libre y las nuevas formas de encontrar trabajo (I)
Sobre Software Libre y las nuevas formas de encontrar trabajo (II)
Sobre Software Libre y las nuevas formas de encontrar trabajo (y III)

Hacerse mercenario del Software Libre

En esa lista olvidé añadir una posibilidad con la que me encontré hace un par de semanas y que tanto InfoQ, como Rod Johnson en su blog, como OpenLogic han sacado a la palestra estos días.

Esta posibilidad es, como comenta el título del blog, vender tu alma al diablo. Hacerte mercenario del Open Source. O hablando más claro, que te subcontraten para dar soporte a proyectos de Software Libre. ¿Cómo es esto? Bueno, la verdad es que esta opinión tan dura que tengo viene a raiz de un email que me llegó hace tres semanas del CEO de OpenLogic y que directamente fue a parar a la basura, pero que he recuperado ya que la blogsfera ha sacado el tema a relucir. A continuación podéis ver algunos fragmentos (es bastante largo, al que le interese todo se lo puedo proporcionar, pero vamos que es lo mismo que podéis leer en su web):

I am contacting you because I’m looking for help supporting Apache Jackrabbit; we have customers who use Jackrabbit and look to us for support. We also have an offer going on right now – we are giving iPods to the next 25 people to join once they resolve their first issue.

We are inviting committers from leading open source projects to join the OpenLogic Expert Community. OpenLogic offers enterprises 24x7, one source of support for over 160 open source projects. We provide a first line of support – taking the calls from our enterprise customers and answering basic questions. For more complex issues (and after we’ve screened out the “read the manual” type questions), we turn to the OpenLogic Expert Community.

If you join the OpenLogic Expert Community, you will:

• get paid for each issue you resolve for your project. You can choose which issues you want to work on and you can choose to take that payment in cash or merchandise. You can even decide to direct your payment to your favorite open source organization.
• receive a $25 gift certificate to Amazon or Starbucks just for signing up. In order to become a member, you’ll need to sign our OpenLogic Expert Community agreement so that we can share confidential customer data with you. We understand reading legal agreements is not fun, so we’ve tired to keep it short and sweet -- and we’ll give you a gift certificate for your trouble.
• have the opportunity to hear first hand the challenges real users encounter when using your software.

Expuestos los hechos, no puedo más que comentar que realmente la estrategia de esta empresa me parece de lo más barriobajera. Por diferentes razones, incluso a las que Rod Johnson expone probablemente por no lanzarse al patio de lo políticamente incorrecto.

Primero, esta empresa contacta a cualquiera, estrategia que me parece bastante poco profesional, sucia, y también mezquina cuando la contrapones con sus argumentos a favor de su modelo de negocio. Y es que yo, en Jackrabbit soy un cualquiera, por mucho que tenga un proyecto basado en Jackrabbit, por mucho que mi nombre aparezca en la lista de contruibuidores, y por mucho que esporádicamente comente cosas en los foros.

Simplemente van a saco e intentan captar incautos que quieran hacer de soporte técnico para ellos, aunque ni siquieran sean muy activos, simplemente analizan la información del proyecto y proceden al envío de emails captación masivos.

Segundo, y como consecuencia del primer punto, esta empresa le hace un flaco favor al Software Libre. Obviamente (o al menos si tienen sentido común), esta gente no apunta a los top committers de los proyectos ya que la mayor parte de ellos ya tienen trabajos en empresas que los esponsorizan o que son propietarias del proyecto en cuestión. Así que su objetivo es la comunidad.

Por ejemplo, en el muy supuesto caso, de que para un proyecto cualquiera en concreto, un 50% entrase en el juego que plantean (esperemos que no), tendríamos que esas personas probablemente dejarían de participar en los foros porque tendrían su tiempo ocupado en resolver incidencias para otros. En este caso, dicho proyecto habría perdido el 50% de su comunidad lo que claramente tendría una influcencia negativa en su salud.

Muchos proyectos se basan en la comunidad. La comunidad y la colaboración son lo que realmente mueven a un proyecto de software libre. Un proyecto sano, es un proyecto con una comunidad sana. Cuanta más gente participa en los foros más dudas se resuelven, más confianza tienen los nuevos participantes, o más se animan las personas a participar en el proyecto y aportar sus parches. Esta empresa, OpenLogic, con su forma de actuar ataca a la linea de flotación de las comunidades.

Es esa actitud, la de asaltar directamente a los desarrolladores más modestos de los proyectos Open Source la que realmente me parece despreciable en su modelo; la de querer minar comunidades saludables convirtiéndolas en comunidades de mercenarios a sueldo que se peleen por resolver las incidencias con las compensaciones más suculentas.

Tercero, el modelo que plantean no es tan bonito. Ahí coincido bastante con Rod Johnson. Realmente plantean un modelo donde pagan a apagafuegos para que les saquen las castañas del fuego cuando en su equipo son incapaces de solucionar sus propios problemas. El contribuidor Open Source pasa a ser el último en la cadena, el que recibe todos los marrones.

Intentan vender unos sueldos magnificos de 100 dólares a la hora cuando probablemente sean 100 dólares a la semana por resolver un marronazo. Claro, por algo ellos no te recomiendan dejar tu trabajo diario para unirte a su programa.

Cuarto, en el caso de que un desarrollador fuese realmente bueno, no necesitaría realmente acudir a este tipo de empresas, sino que podría convertirse en un consultor autónomo y ofrecer sus servicios con su cuenta. Todos sabemos (especialmente en España) lo que significa estar subcontratado. Y en este caso encima estas subcontratado específicamente como la última opción, el come-marrones de turno para el proyecto Open Source en cuestión.

Pues bien, en caso de tener que ser un come marrones, pues casi mejor serlo por tu cuenta, sin tener que darle el 500% del beneficio a una empresa que no va a hacer nada más que rellenar el parte de la incidencia.

Fin de la crítica. Voy a parar aquí aunque realmente esto daría para rato. Ahora me voy a cambiar el traje y me convierto en abogado del diablo. Sea como sea la oferta que plantean es una opción para encontrar trabajo con el Open Source (de hecho, es que es un trabajo). Realmente puede ser una opción cuando no tienes otra fuente de ingresos, no planeas montarte un negocio con tu cuenta, y lo único que quieres es ganar un dinerillo durante unas semanas, meses, o lo que sea. En este caso, pues probar es una opción, pero yo intentaría tener siempre claro el donde te vas a meter, y el tipo de trabajo que vas a hacer. Pero vamos, que si lo que haces normalmente es estar en casa aburrido contestando dudas de Spring, y no te quieres meter en lios, pues puede ser una forma de ganar dinero, aunque la actitud de la emrpesa sea más o menos ética, pero una forma de ganar dinero a fin de cuentas.

El otro punto en el que puedo hacer de abogado del diablo es criticando la actitud de Rod Johnson. Porque, siendo sinceros, ¿qué va a decir? Interface21 es una empresa que vive directamente de dar soporte y consultoría, nada más. Y, la realidad es que aunque han hecho una gran labor y han contratado a muchos de los colaboradores, lo cierto es que muchas de las personas que participan en sus foros y resuelven problemas y dudas lo hacen por puro placer y en su tiempo libre.

Claro, estas personas, son un beneficio enorme para Interface21 ya que ellos pueden mantener a sus mejores desarrolladores ocupados en mejorar el producto (algo a fin de cuentas bueno para todos), mientras otras personas de su empresa y muchos voluntarios, que no veran un duro, hacen las labores de soporte técnico.

Desde el punto de vista de Interface21, OpenLogic es un peligro importante ya que les ataca en dos puntos críticos para ellos: Uno, les roban contratos de soporte ya que pueden acercarse a los clientes vendiéndoles la moto de que disponen de un equipo de soporte con muchos contribuidores del proyecto; y dos, ocupan el tiempo de la gente que participa en sus foros con incidencias de sus empresas cliente lo que potencialmente disminuye la participanción en sus foros y en general debilita la comunidad.

Vamos que, haciendo de abogado del diable, la respuesta de Rod Johnson tampoco es tanto mirando a la comunidad en general, sino que es también en cierto punto una respuesta interesada, mirando a su modelo de negocio y mirando a proteger a su propia comunidad.

Bueno, esto es todo. La verdad es que el post me ha quedado un poco ladrillo, pero bueno, el verme un poco involucrado por ser uno de los que ha recibido la oferta me ha hecho rajar un poco de más. Lo dicho, la opción de ganar dinero y encontrar un trabajo está ahí, pero yo tendría claro que es simplemetne convertirse en mercenario. Que puede que no esté mal para ganarse unos euros durante un tiempo, pero que yo no tomaría como la carrera a seguir dentro del Open Source.

Nuevas metodologías de desarrollo (humor)

No me puedo resistir a poner aquí un enlace a este post Asshole Driven Development.

Destornillante.

ThoughtWorks anuncia CruiseConstrol Enterprise

Después de seis años parece que ThoughtWorks se ha decidido a comercializar (ellos lo llaman adaptar el software a la nueva web) el ubicuo CruiseControl y han anunciado el lanzamiento de CruiseControl Enterprise.

Resulta muy curioso que con la cantidad de productos que han explotado ya el mercado durante tanto tiempo, sea ahora cuando al final se hayan decidido a sacar sus buenos euros de la operación cuando otras compañías como JetBrains o PMEase ya están aprovechando ese mercado hace tiempo.

Java Servlets 3.0

Han dado de alta la especificación de Java Servlets 3.0.

Para mi resulta bastate decepcionante que el target sea finales del... 2008! Hombre tampoco tenía que ser ahora, pero dado que muchas de las cosas que estandariza se están usando ya, no vendría mal darse algo de prisa.

En fin. La principal novedad ya la estaréis intuyendo: Diferentes colores y sabores de Comet. A mayores genéricos, anotaciones, plugabilidad (¿existe esta palabra?) de frameworks web, compatibilidad con las specs. de REST y JSF 2.0, y algunas cosillas más.

Primer draft en Octubre. Será interesante leerlo.

WebLogic y virtualización

Virtualización es, sin duda alguna, una de las palabras que más sonará en los próximos años.

Una de las compañías que está apostando más abierta y claramente por este concepto es BEA que no se oculta en afirmar que la virtualización será una de las bases de su futuro negocio.

En la pasada JavaONE ya coprotagonizaron con Intel una de las keynotes en las que presentaron una demo de su WebLogic Virtual Server Edition. El video está aquí y en el se puede ver como arrancan máquinas virtuales directamente sobre Vmware ESX, como asocian servicios a esas máquinas virtuales o como las máquinas virtuales se rearrancan y rearrancan WebLogic en caso de que se produzca algún error.

La idea desde luego es muy prometedora. La principal ventaja de todo esto, a mayores de todas las asociadas a la administración de sistemas, es que este servidor de aplicaciones virtual es capaz de traducir el bytecode en instrucciones de virtualización. En sistemas de virtualización de última generación que no requieren un sistema operativo para funcionar esto significa que tu aplicación se evita las capas de máquina virtual y de sistema operativo, lo que en teoría debería multiplicar el rendimiento de la misma. Todo esto está explicado en este white paper.

Este pasado Miércoles BEA ha realizado dos webminars que pueden resultar también interesantes para mantenerse actualizado respecto a su stack de virtualización:

Webinar: Virtualisation and BEA Liquid VM: Performance and Flexibility
Webinar: BEA Redefines Virtualized Software Appliances for Java with WebLogic Server Virtual Edition

Esos webinars se pueden ver en diferido (bueno realmente yo sólo he podido ver la presentación porque su sistema de video-streaming no me funcionaba) aunque el contenido del segundo webinar todavía no está disponible para ver, pero se supone que pronto lo estará.

A virtualizarse tocan...

Restifícate

Joe Gregorio ha publicado un tutorial en el que muestra como transformar un API relativamente compleja de RPC a REST. El API en cuestión es el de DayTrader, un ejemplo desarrollado por IBM basado en el entorno de stock trading y que fue donado a Apache Geronimo en el 2005.

En el tutorial Joe va mostrando como ir conviertiendo los diferentes métodos a REST, como seleccionar las entidades o como mapear los diferentes métodos con el protocolo HTTP y URLs concretas.

Interesante para empezar.

Construyendo aplicaciones con Maven 2 y Eclipse RCP

En las últimas semanas he estado modificando jLibrary y migrando su proceso de construcción de Ant a Maven 2. El principal reto ha sido sin ninguna duda el integrar Maven 2 con Eclipse RCP, ya que automatizar la construcción de aplicaciones en este último es bastante complejo.

Afortunadamente al final todo ha salido bien. La clave al final está en utilizar el Maven PDE Plugin y seguir su guía. A nuesro fichero pom.xml hay que añadirle una nueva entrada en plugins especial:

<plugin>
<!-- Maven PDE Eclipse Plugin configuration -->
<groupId>org.codehaus.mojo</groupId>
<artifactId>pde-maven-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<eclipseInstall>E:\eclipse-final</eclipseInstall>
<pdeProductFilename>jlibrary.product</pdeProductFilename>
<pdeBuildVersion>3.2.1.r321_v20060823</pdeBuildVersion>
<format>folder</format>
</configuration>
</plugin>

Si seguís la guía del Maven PDE plugin veréis que los proyectos tienen que estar en una localización especial workspace/plugins. Este es el lugar donde el plugin buscará todas las cosas para instalar. Toda la instalación se basa en el fichero de producto de la aplicación (ejemplo) que especifica todas las partes a construir.

Por último, el otro fichero a tener en cuenta es el de configuración del build (ejemplo). Las posibilidades de configuración son muy amplias. Lo que más me gusta es que con tan sólo modificar una línea puedes tener tu aplicación preparada para ejecutarse en montones de plataformas diferentes:

configs=win32, win32, x86
linux, gtk, ppc &\
linux, gtk, x86 & \
linux, gtk, x86_64 & \
linux, motif, x86 & \
solaris, motif, sparc & \
solaris, gtk, sparc & \
aix, motif, ppc & \
hpux, motif, PA_RISC & \
macosx, carbon, ppc

En fin, que si necesitáis más ayuda simplemente echarle un vistazo a la página donde explico el proceso de construcción para jLibrary, y al proyecto cliente en el SVN de jLibrary. Es bastante sencillo así que no debería haber problemas para adaptarlo a vuestros productos.

Morriña

Mucha gente que conozco aquí en Irlanda no entiende realmente por qué no me llama demasiado la atención el país, por qué no voy más a hacer turismo, o que no me maraville de lo verde que es todo.

Este video lo explica todo. Lo mejor del mundo: Galicia.

P.S. 1: Hoy tengo mucha morriña.
P.S. 2: Air Lingus vuela a Galicia desde Dublin.
P.S. 3: Hoy me he enterado que este año Galicia vuelve a ser la región del mundo con más banderas azules.
P.S. 4: En 7 días volveré a tener morriña.

Blogs sobre Data Centers

Data Center Knowledge es una de las webs que leo a veces ya que suelen poner noticias interesantes.

Hoy han publicado una lista con montones de blogs sobre Data Centers que quizás a alguno le interese.

Europa se acerca

El 29 de Junio se lanzará Europa, y seguramente se lanzará a tiempo. Personalmente soy un fan incondicional del proceso de desarrollo que utilizan para el desarrollo de Eclipse y muchos de sus subproyectos. Es realmente admirable ver como todo el desarrollo funciona como un reloj y como periódicamente van cumpliendo todos los hitos marcados.



En RegDeveloper analizan esta nueva versión y los diferentes proyectos que la forman, muchos de ellos debutantes como el Dynamic Languages Toolkit, Device Debugging Tool o la SOA Tools Platform entre otros.

Ian Skerret ha agrupado todas las partes de Europa en ohloh para extraer una serie de métricas llamativas:

- 17 million LOC
- 290 contributors
- 5055 person years of effort
- $278,041,377 estimated cost of development

Lo que queda ahora es esperar...

IBM publicará un videojuego sobre management

En una demo llamada Innov8 que está disponible en YouTube se puede ver el aspecto de lo que será el primer videojuego del gigante azul. El videojuego que estará aparentemente disponible de manera gratuita para las universidades se empezará a vender en Septiembre.

Parece ser que se trata de parte de una iniciativa en la que IBM trata aplicar técnicas del mundo de los videojuegos al management ya que según comentan las técnicas aplicadas en juegos como WOW pueden ser útiles a la hora de manejar multinacionales modenas (ejem).

La noticia original para los que queráis enteraros de más está aquí.

Irlanda: Anuncio curioso en el Metro

Hoy me he encontrado este anuncio curioso en el Metro:



Al principio pensé, "Tenía que pasar, estamos todos tarados". Pero bueno, falsa alarma, se trata de un anuncio viral de una web tipo "calendario" para almacenar fechas señaladas. El anuncio es bastante bueno :)

Las historias de tres emprendedores a detalle

blow-by-blow, a detalle, así narran sus historias tres emprendedores en el sitio web Found+READ. Se trata de tres historias bastante diferentes.

Por un lado está el fracaso, o como le llaman ahí, la perdida de la virginidad. El ver que las cosas no son tan fáciles como parecen; el juntarte con personas no adecuadas y no ser capaz de parar las cosas cuando se deben parar; o el encontrarte con la frustración de la falta de apoyo financiero y tener que invertir más dinero del que deberías.

Por otra parte está el primer éxito, el ver como eres capaz de hacer crecer capital riesgo, y como la ilusión, desconfianza y la ansiedad se apoderan de ti durante los meses de negociaciones.

Y por último tenemos la ilusión. La ilusión de dirigir tu propio negocio, tanta, que te hace dedicarte a tu proyecto en lugar de hacer tu trabajo o que te da fuerzas dejar tu trabajo en Yahoo o para abandontar Google a los cinco días de haber entrado.

Tres historias de emprendedores aparentemente normales (tampoco me he dedicado a averiguar quien son muy a fondo que digamos), es decir, nada del emprendedor que es primo del subdirector de ebay y cosas así.

Comet con Tomcat 6, Jetty y Grizzly

Hace unas semanas comentaba que estaba evaluando proyectos comerciales y Open Source para implementar un sistema basado en Comet. Parte de ese trabajo fue evaluar las implementaciones de Tomcat 6 y Jetty. De esa evaluación extraje algunas ideas que paso a resumir por aquí, por si a alguien le hace falta.

Jetty

Jetty se basa en el soporte de continuations (ver Continuation en general), que simplemente (o no tan simplemente) consiste en aparcar el procesado de una request en concreto para poder hacer disponible el Thread que la estaba tratando para otras requests.

La principal característica de la implementación de Jetty es que se sigue construyendo sobre el modelo tradicional de Servlets, con la única diferencia de que existe un API adicional que te permite aparcar una request en concreto. Para eso creas un objeto Continuation sobre la request. También se puede asociar estado con esa Continuation:

protected void doGet(HttpServletRequestt request, 
HttpServletResponse response) ... {
....
Continuation continuation = 
ContinuationSupport.getContinuation(request,this);
continuation.setObject(new CometRateSender());
}

Una vez que has trabajado con la Continuation puedes aparcarla por un rato:

protected void doGet(HttpServletRequestt request, 
HttpServletResponse response) ... {

.... code above ....
continuation.suspend(100).
}

¿Cuál es el truco? Pues bien, resulta que después de llamar a suspend, Jetty lanza una excepción concreta que el motor de Servlets capturará. Una vez capturada, Jetty almacena esa request y pasa a utilizar el Thread liberado para manejar otras peticiones. Cuando ha pasado el timeout, Jetty recupera la request "suspendida" y vuelve a ejecutar el método doGet/doPost de nuevo.

Como veis se trata de una triquiñuela inteligente que no a todos gustará ya que se basa en lanzar excepciones internamente y rellamara a los métodos get y post continuamente lo que te obliga a realizar un proceso un tanto extraño de las peticiones. El caso es que para ser honestos, el rendimiento es bueno. Con una configuración normalita (Sun Fire V240, 2 Cores y Solaris 8), y ejecutando un test bastante exigente (streaming continuo y constante en tiempo real), fue capaz de mantener de 2000 a 3000 conexiones concurrentes (y aquí concurrente significa enviar continuamente datos al cliente, nada de dormir) manteniendo un 80/90% de la CPU ocupada y rondando unos 500Mb de consumo de memoria.

Tomcat 6

Desde el lanzamiento de la versión 6 (ahora la versión estable de este producto) Tomcat soporta también el modelo Comet, aunque de una forma bastante diferente a Jetty.

El modelo de Tomcat no es un maquillaje sobre la especificación de Servlets, sino que han evitado cualquier tipo de integración y han creado un API propia de gestión de eventos. Esto tiene la desventaja de obligarte a programar de un modo diferente pero por otra parte ofrece un mayor control sobre el modelo de comunicación de tu aplicación web.

En Tomcat 6, un Servlet que quiera realizar Comet tiene que implementar una interfaz concreta, CometProcessor. Cuando Tomcat detecta una llamada a un Servlet que implementa esta interfaz, en lugar de llamar a los métodos doGet y doPost llamará al método especial event:

public void event(CometEvent ce) 
throws IOException, ServletException {

HttpServletRequest request = ce.getHttpServletRequest();
HttpServletResponse response = ce.getHttpServletResponse();
....
}

Tomcat define varios tipos de eventos que se pueden tratar dentro de este método. Así tenemos BEGIN, READ o END, por ejemplo, que marcan el ciclo de vida de la aplicación Comet:

public void event(CometEvent ce) 
throws IOException, ServletException {

... code above ...
if (ce.getEventType() == CometEvent.EventType.BEGIN) {
// store the response somewhere

} else if (ce.getEventType() == CometEvent.EventType.ERROR) {
... get response ...
response.getOutputStream().close();
ce.close();
} else if (ce.getEventType() == CometEvent.EventType.READ) {
.. read bytes and handle them ...
}
}

El método READ se puede utilizar para realizar una implementación basada en polling. De otro modo, la idea es cachear los objetos response y periódicamente utilizarlos para enviar las notificaciones. La mala noticia es que todo el modelo de programación multitarea y la sincronización quedan en manos del desarrollador. Añade algo de complejidad pero tampoco es tan complicado.

Tras los tests realizados, los resultados en cuando a clientes soportados son más o menos los mismos que Jetty, aunque en Tomcat llegué a los 4000 usuarios concurrentes, pero no sería justo decir que soporta más ya que con Tomcat dediqué mucho más tiempo. Todo esto a todo trapo, con la CPU a 80/90%. Sin embargo en Tomcat la memoria utilizada es mucho mayor llegando a 1Gb, es decir el doble. Este consumo de memoria se debe a que yo sí que cacheé los objetos response, pero sinceramente era sólo una prueba, y puede que haya mejores formas de hacerlo.

Grizzly

La verdad es que Grizzly no lo he evaluado. Pero lo he incluido aquí simplemente para enlazar un par de artículos (este y este) que he visto en el blog de lasterra y que seguro que a más de a uno le interesan.

¿Por qué no lo he evaluado? Pues porque es un producto demasiado nuevo, muy difícil de meter en bancos (donde Tomcat está muy enraizado), y porque a uno deja de darle mala espina el ver que toda la documentación de un producto se encuentra únicamente en un blog en concreto, el de su autor. Casi podríamos invertarnos un término nuevo: "Single point of documentation". La falta de referencias importantes (salvo Sun) también le echa a uno atrás la verdad. En fin, además es que lees las mailing lists, foros y eso, y no deja de parecerte un proyecto "inflado", por decirlo de algún modo; porque en las presentaciones no dejan de hablar de sus múltiples hazañas, pero después vas a los foros y listas y nada de nada, ni referencias, ni cientos de mensajes a mayores de los del propio autor.

Personalmente encuentro que Tomcat es una apuesta segura. Fácil de vender, sobradamente probado, con muchas empresas que dan soporte, y conocido en todas partes. Jetty me ha parecido mejor, pero la difernecia no es tan grande como para superar el resto de ventajas de Tomcat.

Parece que ya es verano en Dublin

Sin quererlo pues resulta que ya van para casi diez meses aquí en Irlanda. Llegué en verano, con solecillo, y parece que por aquí definitivamente ya ha llegado de nuevo por aquí.

Hacía mucho que no escribía nada sobre Irlanda, de hecho mi último post es de Marzo. Así que como hoy hemos ido a la playita pues os dejo aquí algunas fotos para veáis como es la playa por aquí.



Fuimos a Bray y hacía mucho, mucho calor, para lo que aquí estamos acostumbrados claro. Osea, unos 25 graditos :-) Como se ve en las fotos, había bastante gente. Lo malo es que las playas de por aquí no son demasiado buenas. Esta por ejemplo era el 90% piedras, y después algo de arena. Pero bueno, por aquí creo que hay playas bastante mejores que habrá que visitar.

Sobre el agua. Como era de esperar fría, pero la verdad es que menos de lo que me esperaba. Yo diría que está al nivel de la playa de Lago cerca de la playa de Miño, todo por la zona de Betanzos. Hasta me atrevería a decir que por la zona de la costa de la muerte el agua está todavía más fría que por aquí la verdad, aunque igual simplemente es que hacía mucha calor y tenía ganas de agua :-)



Por cierto, para los que me conocen, sí, estoy como un cangrejo.

Probando Wily Introscope

Durante esta semana de cuatro días (el lunes era festivo en Irlanda) he estado bastante ocupado. Me ha tocado evaluar Introscope de Wily, empresa que CA compró el año pasado, así que he compartido miércoles, jueves y viernes con dos consultores de la compañía, y un tercero de su partner en Irlanda. En fin, que me han hecho un marcaje muy directo intentando mostrarme las maravillas de su producto.

Y la verdad es que me ha quedado una cosa muy clara. Si en algún momento fuese comercial, tengo claro que querría vender algo como Introscope. Es decir, un producto maduro, avanzado, con montones de funcionalidades y que no me deje el culo al aire cuando voy a un cliente.

A partir de aquí OJO! porque esto va a derivar en publicidad gratuita de un producto comercial :-)

El producto es espectacular. Funciona de la siguiente manera: Introscope se instala en un servidor central donde tiene una base de datos de eventos. Posteriormente instalas agentes en las diferentes partes que quieras monitorizar como WebLogic, WebSphere, Tomcat, MQ Series, Oracle, o cualquier otro producto soportado. Estos agentes normalmente se ejecutan como agentes Java que se encargarán de instrumentar toda clase que intente cargarse en la virtual machine. La instrumentación es muy flexible y, todavía más importante, configurable, y va desde contar el número de invocaciones a métodos, calcular el tiempo de respuesta, realizar cálculos complejos, segregar en base a parámetros, capturar excepciones, etc.

El producto inicialmente viene con una instrumentación por defecto que captura todo lo relativo a errores, EJBs, Servlets, CPU, Garbage Collection, y todas estas cosillas, más que suficiente para empezar. Pero posteriormente tú puedes escoger que paquetes o clases instrumentar, y por supuesto esto incluye tus propias aplicaciones. También trae, como era de esperar, soporte de JMX, y aunque inicialmente sólo monitoriza unos cuantos MBeans, tú puedes cambiar eso después para que monitorize los que tu quieras, incluso los tuyos claro.

Todos estos agentes capturarán toda esa información y la envían al servidor central. Para acceder a ella se utiliza una aplicación de escritorio o también se puede acceder mediante una consola web. Es decir, el único overhead que añade el producto en los servidores de aplicaciones es el enviar todas las métricas cada 15 segundos, que es el intervalo que se utiliza para actualizar los datos en el servidor central. Como era de esperar, cuantas más clases más overhead.

Toda esta información se renderiza después en forma de árbol donde hay colgando miles de métricas que ofrecen gráficas interesantes. En las gráficas se pueden definir alertas de aviso o peligro, crear acciones (enviar emails, ejecutar scripts), crear informes de explotación, y lo más interesante, diseñar cuadros de mandos donde simplemente copias y pegas las gráficas en las que estés más interesado. Los cuadros de mando son multinivel, así que puedes hacer lo típico de empezar con un cuadro orientado a dirección y terminar en uno orientado al equipo de operaciones.



En la comunidad de Wily (sólo para clientes) se pueden descargar gratuitamente diferentes módulos para monitorizar: Spring, Hibernate (lo probamos), JPA, Garbage Collection, y cosillas así.

Otra de las funcionalidades más espectaculares es la de traza de sesiones. Ahí Introscope funciona como un profiler, y te traceará todo a nivel de milisegundos. Después te muestra bonitos gráficos de como se han ejecutado las diferentes transacciones, puedes ver los errores que se han producido, el tiempo que ha llevado cada paso de la transacción e incluso monitorizar queries SQL o procedimientos almacenados y ver su tiempo de ejecución y cosas así.

Más o menos lo mismo para los errores. El manager te mantiene un historial con todos los errores que se van produciendo en los diferentes agentes. Una ventana de consultas históricas te permite buscar errores en el pasado, pues por ejemplo cuando vuelves del fin de semana (como me tocará a mi el lunes).

El producto a mayores trae una serie de añadidos que le dan más interés si cabe. Un detector de cambios (ChangeDetector) en el que puedes decirle a Introscope que monitorize cambios sobre diferentes tipos de fichero: Clases Java, ficheros de texto o binarios, propiedades de la virtual machine, etc. Después Introscope te muestra una barra horizontal en la línea de tiempo de las gráficas donde resalta los momentos de tiempo en los que se ha detectado un cambio, y puedes ver también los cambios realizados. A nivel de cambio, sólo decir que hasta te permite hacer diff para ver lo que ha cambiado. De este modo es muy fácil detectar cambios bruscos en el rendimiento que se han debido a algún cambio en la configuración.

Otro añadido muy interesante es su EPA (Enterprise Performance Agent, creo). Básicamente es una aplicación que se puede ejecutar en cualquier máquina y que lanzá scripts realizados en Perl, Java y cualquier otro lenguaje. La única condición de esos scripts es que tienen que volcar métricas en un formato especial de clave,valor. EPA recoge la salida de esos scripts y las envia al Enterprise Manager central. Nosotros por ejemplo instalamos un par de scripts de perl para enviar la salida de netstat y vmstat hacia el servidor central, con lo que puedes ver en tu cuadro de mandos la salida de cualquier programa de este estilo. Ni que decir tiene que nuestro a nuestro jefe de operaciones le caía la baba cuando veía que podía tener vmstat en gráficos, a todo color, y acompañado de otras métricas de negocio.

Después tendríamos el LeakHunter que más que nada resulta útil en tiempo de desarrollo ya que lo único que hace es llevar cuenta del tamaño de todas las colecciones de datos (según Wily fuente del 80% de los memory leaks) que hay en el sistema y conforme avanza el tiempo te avisará si realmente es un leak o no.

Bueno, no me enrollo mucho más que no me dan comisión. Eso sí, este producto es muy recomendable si como nosotros tenéis un software que se vende en base a SLAs. No sólo te permite probar que estáis cumpliendo vuestros SLAs sino que además es una herramienta con la que realmente puedes probar que los estás cumpliendo. Definitivamente, salir a producción con una herramienta como esta es mucho más sencillo.

Ah, ¿el precio? Como era de esperar, no apto para todos los bolsillos. No os digo más pero hablamos de cifras en torno a las decenas de miles de euros. En este caso se cumple lo de "el que algo quiere algo le cuesta".

¿Alguno tiene experiencia con Introscope? ¿Qué herramientas utilizáis vosotros?

Quiero mi consola de administración

Uno de los artefactos por el que claramente apuesta el libro que recomendaba hace unos días es el ofrecer una consola de administración para las aplicaciones.

La idea, con la que estoy completamente de acuerdo, es muy sencilla. Lo malo es que a pesar de estar totalmente de acuerdo, siempre he acabado por no hacerlo, en cualquiera de los trabajos en los que he estado. Shame on me! La verdad es que al final he caido siempre en la vieja práctica de crear un interfaz de usuario muy amigable para administrar el sistema. Sin embargo, el hacer esto tiene normalmente varios problemas:

• Suelen ser aplicaciones Swing o web que simplemente acceden directamente a los servicios. Por lo tanto si los servicios cambian las aplicaciones deben de cambiar.
• Tienen asociado un coste de mantenimiento importante. Cada vez que se cambia algo (punto anterior) y cada vez que se añade una nueva funcionalidad, es necesario el crear nuevas páginas o ventanas con nuevos interfaces de usuario para administrar esta parte nueva del sistema.
• Es una solución propensa a errores. Incluso cuando tu backend esté perfectamente probado, pasas a lidiar con todos los errores asociados a un framework de creación de interfaces de usuario: Swing, Java Server Faces, Seam, Struts, SWT/JFace, ...
• Hacer pruebas es complicado. Probar los servicios es fácil, simplemente un conjunto de tests unitarios y tests de integración y listo. Pero si le vas a ofrecer un interfaz de usuario de administración al usuario final entonces tendrás que probarlo. Y esto nuevamente tiene asociados unos costes importantes.
• No son scriptables. Este tipo de UIs están bien para usuarios, pero no para administradores, que como bien dice el nombre al final deberían realmente ser las personas que utilicen las interfaces de administración. Un administrador va a preferir cien mil millones de veces algo con lo que pueda hacer scripts y automatizar tareas que una interfaz de usuario que por muy bonita que sea le obligue a crear uno a uno todos los usuarios del sistema.
  
  Esta probablemente sea una de las razones más poderosas para basar el sistema de administración algún sistema de comandos que sea scriptable. Te permite automatizar tareas tediosas, crear tus propios scripts de mantenimiento, replicar sistemas de manera sencilla, y realizar un sinfín de tareas que de otro modo serían demasiado complicadas.

En fin, estas son algunas razones y supongo que os darán una idea de los problemas asociados. Yo mismo, ahora que estoy peleando para sacar una versión de actualización de jLibrary, me encuentro con que sufro para mantener el interfaz de usuario. Para mi, ya no es sencillo juguetear con pantallas de administración como esta:



Sí, es una pantalla muy bonita, pero mantenerla me implica todo lo explicado anteriormente: Mantener los widgets, lidiar con cosas como "que si migro a Eclipse 3.2 entonces han cambiado los widgets y tengo que modificar el código para que las listas salgan con borde porque ahora ya no salen", asegurarme de que no hay errores, etc. Si por el contrario tuviese una simple consola de comandos con funciones como crearUsuario, crearRol, añadirUsuarioAGrupo todo se limitaría simplemente a llamar a esos métodos y punto.

Probablemente una de las mejores formas de crear una consola de administración es simplemente codificar una pequeña aplicación que exponga todos los métodos de nuestro servicio de administración en forma de comandos. Hay una ventaja adicional asociada a esto, que es que una vez que tengamos diferentes scripts creados, estos servirán como tests de integración del sistema por lo que realmente se están matando dos pájaros de un tiro: tests de integración y administración.

Ahora bien, en caso de tener tiempo (y ahora entro en la parte concreta de Java) probablemente nos convenga seguir la aproximación que servidores de aplicaciones como BEA WebLogic o IBM WebSphere siguen. Esto es, envolver nuestro sistema de administración en una serie de MBeans que sean los que expongan las operaciones. Estos MBeans invocarán a nuestro sistema de administración. Una vez se tiene esto, se crea una consola de administración sencilla utilizando algún lenguaje dinámico (por ejemplo WebLogic utiliza Jython; WebSphere jacl and jython) que simplemente ejerza de wrapper entre el usuario y los MBeans, por ejemplo exponiendo todos los MBeans en forma de objetos python que el usuario pueda invocar.

Si se consigue un sistema como este nos encontraríamos ante el entorno ideal de administración. El paso siguiente es aprovechar esos MBeans para exponer el entorno de administración en otros formatos, pues por ejemplo una consola web (como hacen WebLogic y WebSphere), o incluso aplicaciones de escritorio.

Una ventaja adicional a todo esto es que los MBeans se pueden exponer también hacia sistemas de gestión SNMP utilizando alguna librería de transformación JMX-SNMP, de modo que el estado de nuestro sistema de administración puede ser monitorizado con cualquier herramienta que soporte SNMP.

En fin, aquí dejo un diagramilla que me he currado mientras escribía esto.

10 signos de que estamos en una burbuja tecnológica

En RegDeveloper publican un muy interesante artículo de Gavin Clarke, en el que compara la situación actual con la que se vivió allá por el 1999. Digo muy interesante por el factor histórico y aprender más sobre lo que pasó entonces (aunque huele mal), sin siquiera entrar en muchas más valoraciones sobre lo que comenta.

Según Gavin, hay muchos paralelismos:

• Las compañías lanzan productos frívolos.
• Montones de dinero para gastar.
• Prácticas de comercio indeseables.
• Falsa evangelización.
• Cifras falsas.
• Todavía no sabemos como hacer dinero.
• Ganarse a los desarrolladores.
• Revisitar continuamente las mismas ideas.
• Marketing, marketing, marketing.

y sin duda, el mejor paralelismo ...

• Maduritos en bici y scooter yendo a trabajar en Silicon Valley.

Personalmente encuentro muy emocionante la batalla que se está librando entre los "pro web 2.0" y los "pro burbuja". La verdad es que la situación actual es bastante desquiciante en muchos sentidos, pero sobre todo cuando toca leer la valoración económica de muchas startups (googleando un poco).

Pero, por otra parte, también es cierto que por ahora no ha habido salidas a bolsa como en el año 2000, por lo tanto el riesgo de que explote algo es muchísimo menor. Aún asi, seguro que más de uno está siendo cauto a la hora de invertir sus pensiones o adquirir opciones en la compañía. Será muy interesante la reacción de los medios y la gente cuando alguna de estas hi-tech anuncie su salida a bolsa (que tarde o temprano lo harán). Seguramente entonces será cuando empiecen a aparecer los verdaderos paralelismos y fantasmas.

Release it!

Release it! es uno de los libros que he leido últimamente y que me atrevería a recomendar. Se trata de uno de los últimos libros de la serie The Pragmatic Programmers que hay que ver realmente el éxito que han tenido que ya han publicado 32 libros (y los que hay planeados) después de su mítico The Pragmatic Programmer.

Últimamente la serie ha venido un poco a menos. Hace poco leí uno de los de Rails pero la verdad es que tampoco me gustó demasiado. Sin embargo este es diferente. No se trata del mejor libro del mundo; ni tan siquiera me atrevería a decir que te de la llave mágica para hacer una release. Es más, casi afirmaría que es un libro que divaga bastante, y que en muchos capítulos pierde totalmente el hilo del objetivo principal, hacer una release.



Para ser sinceros, cualquiera que lo lea podrá afirmar que es un conjunto de obviedades recogidas en un libro (contol de cambios, mantener el equilibro entre web - appserver - base de datos, controlar la contención de recursos, etc.). Y ya siendo muy críticos, lo cierto es que el autor se podría haber ahorrado algunas secciones que simplemente estar por estar (por ejemplo una de seguridad en la que el consejo básicamente es no guardar las contraseñas en ficheros planos).

Sin embargo, y a pesar de que esta parece una advertencia en lugar de una recomendación, lo cierto es que el libro está lleno de ejemplos prácticos y de historias de la vida laboral del autor, que lo hacen realmente entretenido de leer. Sin lugar a dudas los capítulos más interesantes son los que dedica exclusivamente a contar historias sobre proyectos problemáticos, y con los que inevitablemente te sientes identificado de algún modo.

En resumen, me ha parecido bastante entretenido así que me animo a recomendarlo. Probablemente en los próximos días trate algunos de los temas que aparecen en este libro, porque valen realmente la pena.

hipoqih, gallegos en California

Siempre está bien ver que hay productos en la tierra de uno que cogen fama en el extranjero. Parece que hipoqih un proyecto de tres gallegos asentados en Coruña y que han estado presentado su trabajo en la Where 2.0 Conference en California. En KillerStartups también los destacan.

¿El nuevo panoramio? A ver si hay suerte.