martes, julio 31, 2007

¿Vale la pena buscar colaboradores en sf.net?

martes, julio 31, 2007 por Martín

Ahí queda esta pregunta abierta. Y es que tengo que reconcer que el servicio de recruitment de SourceForge.net me frustra. En fin, aunque hay que reconocer que SourceForge no tiene ninguna culpa; bastante hacen ofreciéndome ese servicio gratuito.

El caso es que lo que os voy a contar ya no es la primera, ni la segunda vez que me pasa. Pero iluso de mi, la semana pasada volví a picar, y se me ocurrió publicar un trabajo buscando gente interesada en hacer algo con jLibrary. La idea era (y es) probar jLibrary, crear alguna aplicación interesante sobre la web (incluso tipo scribd, que la gente la pueda usar para probar frameworks web; en fin que es un campo de pruebas interesante, y se me ocurrió publicar un anuncio para ver si había alguien interesado en el Open Source y sus oportunidades.

Durante las tres semanas que ha estado el anuncio abierto me han llegado mensajes de trece personas interesadas, cosa que me parece que está bastante bien, y se asimila a lo que ya he tenido en las otras ocasiones que he publicado un trabajo. Lo que me frustra es que la mayoría de las personas que se ponen en contacto conmigo:

  1. No tienen ni idea de que va el proyecto o,

  2. tienen idea pero ni siquiera se lo han descargado y/o probado o,

  3. no tienen los conocimientos suficientes de Java para bajarse Maven y construir el proyecto o,

  4. tienen los conocimientos pero en cuanto ven que les pides un poco de esfuerzo para al menos construir el proyecto, ejecutar los unit tests, etc., se les baja el subidón inicial y prefieren buscar otra cosa más sencilla o,

  5. (y esta es la buena) asumen que es un trabajo remunerado. Lo siento, pero en esta ocasión va a ser que no.


Uno de los últimos me mató cuando me pedía que le enviase la documentación de sus tareas y diagramas de diseño que especificasen lo que tenía que hacer. No sé si lo hizo a propósito pero vaya bajón de moral.

En fin que tras mis experiencias buscando gente en sf.net me queda claro que los canales tradicionales: amigos, usuarios de tu aplicación, empresas interesadas, son mucho más productivos.

lunes, julio 30, 2007

Blogs de emprendedores

lunes, julio 30, 2007 por Martín

Javier Martin está recogiendo en Loogic una lista con los blogs de 100 emprendedores cuya mayoría desarrollan proyectos para Internet y hablan sobre ello en su blog.

La idea me parece muy buena. Eso sí, la mayoría parece estar relacionada con el mundo de los blogs, portales de noticias y cosas por el estilo, aunque hay más de una excepción muy interesante.

Si alguno se echa en falta, podéis darle un toque.

La web de ahora dentro de 10 años

lunes, julio 30, 2007 por Martín

En Think Vitamin le han preguntado a 16 importantes desarrolladores, diseñadores y emprendedores, qué es lo que creen que dentro de 10 años estaremos viendo como la tecnología clave en estos días cuando miremos hacia atrás.

Lo que me parece más interesante es que prácticamente no hay consenso entre las dieciséis personas. Dos piensan que los microformatos, otros apuntan a Applet, su iPhone y el múndo de los móviles, hay quien simplemente dice YouTube, Safari, la agregación de información, el aspecto social, o el aspecto de publicación. Yo no sigo demasiado el mundo del diseño/desarrollo web pero la verdad es que me esperaba mucho más consenso, algo como que el 50% dijese que la web social ha sido lo más grande, o que la mitad pensase que los microformatos han cambiado la web. No sé, me ha quedado un poco la impresión de que está todo muy difuso todavía.

Quizás tenga razón Jeffrey Kalmikoff de SkinnyCorp cuando dice que todo el enfasis en lo web 2.0 y en buscar locamente el encajar productos dentro de lo que se ha convertido ya en una marca comercial está enlenteciendo el mundo del desarrollo web. Se está llegando a un punto en que no importa la funcionalidad sino que lo importante es que todo tenga bordes redondeados, muchos colores y que se integre con Facebook (por poner un ejemplo).

viernes, julio 27, 2007

Presentaciones de las OSCON 2007

viernes, julio 27, 2007 por Martín

Pues nada, notita rápida. Ya se pueden descargar algunas de las presentaciones que se pudieron ver esta semana en la OSCON 2007.

Desde aquí.

Tienen buena pinta.

Sobre programación multihilo y el modelo de memoria de Java

viernes, julio 27, 2007 por Martín

El modelo de memoria de Java y lo fácil que hace el crear aplicaciones multihilo a veces nos hace olvidar que existe un sistema operativo y un hardware
por debajo que ponen restricciones sobre que cosas y de que modo puede trabajar nuestros programas. Con la llegada de las CPUs con múltiples núcleos aparece
una sombra sobre Java: Mi programa que está funcionando bien con uno o dos núcleos, ¿va a funcionar bien con 16 núcleos?

En TheServerSide han publicado una entrevista muy interesante,
y de un nivel técnico bastante alto, a Cliff Click, el creador del compilador HotSpot -server y que ahora trabaja para Azul Systems.

Vale la pena.

miércoles, julio 25, 2007

Google nos protege de los malvados Singleton

miércoles, julio 25, 2007 por Martín

Un Singleton es un patrón de diseño muy popular por su sencillez. Como seguro que casi todos ya sabéis, la idea que promueve es que sólo se pueda crear una única instancia de una clase. A pesar de la aparente sencillez, la realidad es que implementar un Singleton no es algo tan sencillo, especialmente cuando entran en juego temas de sistemas distribuidos, diferentes classloaders, bla bla bla... En fin, que como con casi todo lo polémico pues hay seguidores y detractores.

Como en Google creen que los Singleton son una cosa muy importante, pues han tenido la gentileza de crear y hacer Open Source el Google Singleton Detector. Sí, con Google delante, para que no se espante. Una herramienta para detectar Singletons en nuestro código. Además, no sólo detecta Singletons, sino que también Hingletons (helper singleton), Mingletons (method singleton) y Fingleton (field singleton).

En el trabajo bromeabamos con que esto del 20% de tiempo para proyectos propios parece que da para mucho. Uno se pregunta por que en lugar de crear un proyecto tan concreto, por qué no habrán contribuido a algo mucho más conocido como Findbugs.

martes, julio 24, 2007

Más charlas de escalabilidad en Google

martes, julio 24, 2007 por Martín

Hace unas dos semanas ya publicaba un post haciendo referencia a algunas charlas de escalabilidad de la Google Conference on Scalability.

El caso es que hay más, y aunque algunos ya os habréis dado cuenta, dejo aquí los enlaces para completar la serie.

No creo que las vaya a ver todas así que ya comentaréis si hay alguna especialmente recomendable.

lunes, julio 23, 2007

7 razones para no subcontratar si eres una pequeña empresa tecnológica americana

lunes, julio 23, 2007 por Martín

Interesante artículo de Vivek Wadhwa, profesor de la Universidad de Duke, BusinessWeek en el que analiza el porque las empresas pequeñas americanas no están enviando trabajo fuera.

El artículo se basa en un estudio del profesor Amar Bhide de la Universidad de Columbia en el que se entrevistó con 106 CEOs de compañías tecnológicas. A parte de las diferentes conclusiones del artículo, lo que me ha parecido más interesante son los 7 impedimentos más importantes que se encuentran las subcontratas:
  • Tener al cliente lejos: Muy a cuento de las metodologías ágiles, si el cliente está lejos, es difícil ajustarse a sus requisitos (y más aún poder tenerlo onsite)
  • Los equipos deben trabajar juntos: Tener equipos de desarrollo en diferentes puntos del mapa hace difícil que se compenetren.
  • Gestión de equipos: Coordinar los equipos en multiples lugares y zonas horarias se hace complicado.
  • Equipos más pequeños a menudo son más productivos: Así que si la razón de sacar el desarrollo a aun país más barato es tener más desarrolladores, entonces quizás esto no solucione el problema.
  • Falta de habilidades:Hay paises en el que por falta de infraestructura no se pueden encontrar determinados perfiles (pone el ejemplo de desarrolladores de juegos en India).
  • Problemas con la propiedad intelectual: especialmente al mover software a paises como china.
  • Competición por el talento: es fácil que las empresas grandes se lleven a los mejores talentos, así que a las empresas difíciles les es difícil encontrar personal adecuado.


No deja de ser una visión interesante. Personalmente no estoy de acuerdo con algunos de los puntos:
  • Los equipos deben trabajar juntos: Pensar esto me parece un poco como vivir en el pasado. Hay ejemplos de sobra de equipos que trabajan en diferentes países con éxito (casi cualquier producto Open Source con fama). La clave es que es algo difícil, y por lo tanto requiere calidad, calidad en todos los equipos de desarrollo. Si dispones de gente capacitada, tanto dará donde estén los unos o los otros, al menos desde el punto de vista de crear software.
  • Equipos más pequeños a menudo son más productivos: En esto estoy de acuerdo, pero tampoco le veo mucho la relación con la subcontrata. Está la justificación que he comentado arriba de que no se debería subcontratar por el simple hecho de tener más desarrolladores, pero claro, eso no implica que no puedas tener tu pequeño equipo de fueras de serie en ... España por ejemplo. Claro que entonces tocaría pensar en el resto de puntos, como estar lejos del cliente.
  • Falta de habilidades: Efectivamente. Pero también hay países que tienen habilidades que quizás no podamos encontrar donde estamos, y en ese caso igual nos tenemos que mover ahí.

    Hace poco hablaba con un amigo de por qué Babelgum una empresa de capital italiano que compite con Joost se ha establecido en Dublin centro, en lugar de desarrollar en Italia que es más barato. Pues investigando un poco me comentaba un amigo que simplemente ha sido porque en Italia no podían encontrar los perfiles adecuados para emprender el proyecto.

¿Alguien se anima a opinar?

domingo, julio 22, 2007

La biblia de Java7

domingo, julio 22, 2007 por Martín

Todavía queda para que salga a la luz pero Andrew Miller está recopilando toda la información de Java 7 que va saliendo a la luz cada día. La recopilación de enlaces es enorme.

Os dejo el enlace por si alguien quiere irse preparando.

jueves, julio 19, 2007

Pero... ¿alguien ha visto una empresa de software?

jueves, julio 19, 2007 por Martín

No me puedo resistir a comentar el debate de moda, si faltan o no programadores. Todo esto empezó con alguien que opinaba que faltaban prgramadores, y a continuación el artículo se propagó como la polvora por otros medios como meneame o barrapunto. Poco a poco han ido saliendo opiniones. Algunas críticas que todavía echaron más leña al fuego, aunque mucha gente está de acuerdo. Después también hay quien hace notar que lo que faltan son programadores motivados, y por supuesto quien critica a las empresas o quien opina que es simplemente la ley de oferta y demanda.

Yo, me voy a guardar mi opinión porque sería volver a marear la perdiz, una vez más. Más o menos comparto un poco la de todos. Está claro que las empresas no encuentran programadores, está claro que si pagasen más dinero aparecerían más, está claro que los jovenes quieren ganar lo máximo posible, está claro que hace años todos sufrimos cuando empezamos, y está claro que programar hoy en día no motiva a mucha gente.

Lo que me ha llamado la atención es que nadie (creo) haya sacado el tema de que faltan empresas de software en España. Porque, digo yo que el habitat natural para los programadores son las empresas de software, ¿no? Ahí es donde puedes encontrar a la mayoría de programadores en otros paises. Sin embargo en España, ¿dónde están las empresas de software?

La mayoría de empresas en España son consultoras, empresas de servicios, o por decirlo de un modo menos políticamente correcto: cárnicas. Esto tiene como consecuencia un mercado totalmente viciado. Es decir, un mercado en el que las empresas subcontratan, tricontratan o cuatricontratan gente para trabajar para el cliente final. Eso sí, si hay suerte igual puedes estar en una software factory, aunque en ocasiones casi seguro que es mejor que no. Un mercado en el que las empresas sí, crean software, pero que el software se quedará ahí, para toda la vida. Software que casi siempre es 1-1, un proveedor-un cliente, release (si hay suerte), mantenimientos, y fin de vida. Software que utilizarán los 1, 10, 100, o 1000 empleados del cliente. Todo ello aderezado con todo el politiqueo correspondiente, con todas las luchas de poder, con todas las luchas entre consultoras trabajando en el mismo cliente, y con la sensación de que lo que estás programando no lo utilizará ni el gato y que simplemente vale para que el dinero que se debería llevar el programador se lo vayan apropiando los diferentes escalafones. Difícil motivarse así, ¿no?

Porque al final a todo el mundo le gusta estar orgulloso de su trabajo. Y no es lo mismo el pensar que tu aplicación la va a usar sólo una empresa (por muy grande que sea), que hacer un software y ver como todo el mundo lo quiere utilizar, ver como se distribuye por internet, ver como aparecen clientes desde Japón interesándose por el mismo. ¿Por qué no pasa esto en España? ¿Por qué no exportamos software? ¿Por qué todos los programas vienen de US, UK, Irlanda, Alemania, Francia, Bélgica, ... si hasta voy a decir Italia? Fácil, porque no tenemos industria de software. Simplemente tenemos trabajo basura. Y así es muy complicado "encontrar programadores".

De todas las personas que conozco trabajando en esto de IT, al final los que están más contentos son siempre los que están en empresas que hacen verdaderamente software; que evidentemente las hay en España, pero como he dicho, ¿cuántas? ¿Cuántas empresas en España hacen software antes de venderlo? ¿Cómo está el capital de riesgo en España para crear verdaderas empresas de software? Las menos, y normalmente pequeñas, y que sufren para subsistir porque al final las ayudas y los concursos públicos se mueven como sabemos todos que se mueven.

Esto quizás sea la cosa que más me ha chocado al venir a Irlanda. El encontrarte con un panorama tan diferente. Un panorama en el que vas a las páginas de trabajo y sobran ofertas bien pagadas, en el que la gente se va de los trabajos y se coge meses sabáticos porque sabe que no va a tener problemas en volver y encontrar otro trabajo, incluso mejor. Y es que la mayoría de este trabajo son para empresas ..... de software. Empresas que consiguen capital de riesgo y arrancan un producto sin clientes, poniendo a trabajar la maquinaria comercial y acabando con un software que se vende en todo el mundo; empresas spin-off que surgen como consecuencia de inversiones de capital o de entidades que ven un nicho en el sector y que deciden invertir; empresas de emprendedores que aprovechan las suculentas subvenciones del gobierno irlandés.¿Subcontratación? Claro que la hay, y alguna oferta me llegó en su momento, pero es muchísimo menos habitual que en España. Y eso que aquí si que existe el fantasma del offshore y los equipos de programadores en la India (nosotros tenemos uno) o los paises del Este.

Pero bueno, sobre Irlanda e IT me reservo otro post para otro momento porque no es sólo esa la diferencia.

Concluyendo, que para conseguir un mercado, y una buena oferta y demanda, y que aparezcan los codiciados programadores, en lugar de discutir tanto sobre si necesitamos o no regularizar la profesión, crear colegios, irse todos a huelgas, o sobre si los programadores ahora son unos señoritos, mejor haría todo el mundo en reflexionar sobre si la industria del software es lo suficientemente saludable como para generar riqueza en España.

Me ha quedado un buen rant :)

El stack Open Source y Java de Joost

jueves, julio 19, 2007 por Martín

Joost es una aplicación que está llamada al éxito. Viene avalada por los fundadores de Skype y Kazaa y básicamente se dedica a distribuir contenidos de televisión a través de una red P2P

En la ficha de Techcrunch podéis ver más detalle sobre la compañía, que como se aprecia ya ha recibido 45 millones de dólares en capital de riesgo. El caso es que un amigo me comentaba que su stack está completamente basado en Open Source y Java.

Investigando un poco se puede llegar a su página sobre Open Source donde describen todos los productos que utilizan tanto en cliente como en servidor. No los voy a listar porque ya lo podéis leer vosotros mismos. Destaca que utilizan PostgreSQL, Jetty, el hosting está en Ubuntu, el framework web es Apache Wicket, para clientes pesados utilizan Eclipse RCP, y por supuesto Spring.

Bueno, la verdad es que después utilizan un montón de cosas más e incluso lenguajes como perl, python, ruby, pero más que nada para interoperar. Su base se ve que sigue siendo Java. Sólo hay que echarle un vistazo a la lista de frameworks Java Open Source que utilizan:

abdera.client, abdera.core, abdera.extensions, abdera.parser, abdera.protocol, abdera.security, abdera.server, acegi-security, acegi-security-cas, acegi-security-catalina, acegi-security-jboss, acegi-security-jetty, acegi-security-resin, acegi-security-tiger, activation, ant, antlr, antlr3, aopalliance, arq, asm, aspectjlib, aspectjrt, aspectjtools, aspectjweaver, avalon-framework, axiom-api, axiom-impl, axis, axis-ant, batik, bcmail-jdk14, bcprov-jdk14, burlap, cas-server, cas-server-generic, cas-server-jdbc, cas-server-ldap, cas-server-trusted, cas-server-x509, cglib-nodep, colt, commons-attributes-api, commons-attributes-compiler, commons-beanutils, commons-beanutils-core, commons-cli, commons-codec, commons-collections, commons-configuration, commons-dbcp, commons-digester, commons-discovery, commons-el, commons-fileupload, commons-httpclient, commons-httpclient-contrib, commons-io, commons-jci-core, commons-jci-eclipse, commons-jci-janino, commons-jexl, commons-jxpath, commons-lang, commons-logging, commons-logging-adapters, commons-logging-api, commons-pool, comp4swt, concurrent, dom4j, ehcache, ehcache-remote-debugger, fop, geoip, geronimo-spec-jta, hadoop, hadoop-test, hessian, hsqldb, hsqldb-release, htmlunit, ibatis, ibatis-common, ibatis-dao, ibatis-sqlmap, icu4j, iri, itext, jakarta-slide-webdavlib, janino, jardiff, jasper-compiler, jasper-runtime, jasperreports, jaxen, jaxme-api, jaxrpc, jbarcodebean, jcalendar, jcommon, jdbm, jdom, jdtcore, jena, jetty, jetty-plus, jetty-util, jfreechart, jgroups-all, jmdns, jmxremote, jmxremote_optional, jnlp, jnlp-servlet, joda-time, joesnmp, joseki, json, jsp-api, jsr173, jsr173-ri, jsr94, jss-asn1, jstl, jta, jung, junit, ldapbp, log4j, lucene, lucene-similarity, lucene-snowball, mail, mina-core, mina-filter-codec-asn1, mina-integration-spring, mockrunner, nekohtml, ognl, opencsv, oro, oscache, oscore, osworkflow, poi, postgresql, propertyset, pull-parser, quartz, rmissl, rome, rome-fetcher, rome-itunes-rss-ext, rome-media-rss-ext, saaj, sandler, serializer, servlet-api, shared-asn1, slf4j-simple, spread, spring, spring-aspects, spring-beans, spring-binding, spring-core, spring-ldap, spring-mock, spring-webflow, standard, stax-api, stax-utils-snapshot, stringtemplate, swtplus, velocity, velocity-dep, velocity-tools, wicket, wicket-auth-roles, wicket-contrib-dojo, wicket-contrib-velocity, wicket-extensions, wicket-spring, wsdl4j, wstx-asl, xalan, xbean, xbean_xpath, xercesImpl, xml-apis, xmlpublic, xmlunit, xpp3, xstream, yale-cas-client

Guau!

martes, julio 17, 2007

Una conversación sobre bases de datos

martes, julio 17, 2007 por Martín

En ACM Queue publicaron hace unos meses una conversación/entrevista entre Michael Stonebraker toda una institución en el mundo de las bases de datos y Margo Seltzer cofundador de Sleepycat Software (Berkeley DB).

El artículo es uno de esos que lees y te quedas con las ganas de que siga, y siga, y siga. Buenísimo. Gira en torno al tema de que las bases de datos relacionales se han quedado obsoletas, y el actual escenario de motores gigantescos de bases de datos intentando acaparar mercados para el que no están preparadas. Temas como data warehouse, bases de datos en memoria para mercados financieros, por qué fracasaron las bases de datos orientadas a objetos, o la necesidad de cambiar el modelo de programación hacia lenguajes como ruby on rails son algunos de los temas que tocan.

No cuento nada más porque de veras que vale la pena leerlo.

lunes, julio 16, 2007

Los negocios abandonan Second Life

lunes, julio 16, 2007 por Martín

Hace un año escribía sobre como me fascinaba el modelo de negocio que habían creado los creadores de Second Life, y poco después notaba que incluso se podía pasear virtualmente por Dublín, la ciudad donde vivo.

Parece que hasta ahora todo era bonito, todo indicaba que toda la locura alrededor de la creación de negocios virtuales, eventos virtuales, empresas que compran islas completas, no podría durar demasiado. En TechCrunch y especialmente en este artículo de Los Angeles Times firman lo que puede ser un golpe definitivo de realidad directamente al estómago del mundo virtual. Y es que ya se sabe que cuando las críticas ven la luz en medios como estos, no sería raro que comenzarán a leerse más y más malas noticias.

Y es que parece que el rey de los mundos virtuales está vacio. Los 8 millones de usuarios registrados no son más que un bluff y realmente en las horas puntas sólo llegan a unos 40.000 usuarios concurrentes, no mucho más que cualquier juego multijugador gratuito y sin duda con prespuesto mucho más modesto.

Signos de "se vende" en los comercios, islas como las de Dell o Best Buy desiertas, gigantescas salas de eventos sin eventos ni personas, hoteles de lujo totalmente vacios mientras que los pocos usuarios se agrupan en casinos, burdeles o clubs de striptease. Eso es lo que parece que queda en Second Life, eso sí generando como se puede ver en el articulo de LA Times unos 6.8 millones de dólares este pasado Junio, que quien me los diera a mi.

Lo cierto es que al final sale a la luz lo que todos ya nos olíamos, que las empresas abren delegación en Second Life por el hecho de estar ahí. Porque hay que saber estar a la última, y si quieres ser moderno hay que estar ahí. Así que a gastar unos dólares en comprarse la islita, nota de prensa, y a otra cosa mariposa. Y me da que esto no está pasando sólo en los mundos virtuales.

Tipos de virtualización

lunes, julio 16, 2007 por Martín

Me he topado con un post de John Rath en el que se explican los diferentes tipos de virtualización disponibles hoy por hoy en el mercado.

Permitiendo el resumirlo un poco, lo divide en:
  • Virtualización de Data Centers: Encapsular todos tus data center a nivel mundial via grids de modo que se pueda virtualizar el uso de sus recursos.
  • Virtualización de servidores o sistemas operativos: Lo que ya todos conocemos, Xen, VMWare, etc.
  • Virtualización de almacenamiento: Encapsular el acceso a dispositivos de almacenamiento físico.
  • Virtualización de ficheros: Capa de abstracción sobre sistemas de ficheros.
  • Virtualización de aplicaciones: Ofrecer acceso a aplicaciones sin ni siquiera tener que instalarlas.
  • Virtualización del escritorio: Citrix, VMWare player, ...

El añade también un par de opciones más (Virtual Networks, Virtual World) pero que ya se salen un poco del tema en mi opinión. Para ver más referencias, pues a su blog. Y mientras tanto pues ya sabéis, si alguien os pregunta qué es la virtualización ya podemos contestar a la gallega. ¿Qué tipo de virtualización?

viernes, julio 13, 2007

BEA Mission Control un JConsole pero en mejor

viernes, julio 13, 2007 por Martín

Con la máquina virtual de BEA, JRockit, viene por defecto desde hace tiempo una aplicación llamada BEA Mission Control. Esta aplicación es como JConsole, es decir, que te permite monitorizar la máquina virtual y ver cosas como su consumo de memoria, CPU, información sobre los threads, o monitorizar los beans JMX entre otras cosas.

El caso es que Mission Control sorprende porque añade una serie de funcionalidades de lo más interesantes que lo convierten en una mejor alternativa a JConsole para sistemas que funcionan con la máquina virtual de BEA. Se trata de una aplicación desarrollada con Eclipse RCP y la verdad es que muestra la información de una manera más fácil de analizar y de digerir (por ejemplo la información sobre los threads se presenta de forma más útil).

Además, lo cierto es que te deja hacer cosas que no puedes hacer con JConsole como el hacer profile en tiempo real de tu aplicación viendo invocaciones a diferentes métodos y el tiempo que lleva realizarlas, o hacer profile para ver las excepciones que ocurren en el servidor, o por ejemplo detectar y que te muestre los diferentes deadlocks que se puedan estar produciendo entre threads.

En resumen, que vale la pena utilizarla si usáis JRockit. Tiene dos extensiones para grabar el "profiling" de la aplicación y analizarlo posteriormente y también un detector de memory leaks. Lo malo es que para esto ya entras en la versión de pago (y para usarlo en producción también).

Os dejo unas capturas de pantalla para los que nunca hayáis usado esta herramienta y queréis ver como es.




miércoles, julio 11, 2007

GC para tiempos bajos de respuesta (y II)

miércoles, julio 11, 2007 por Martín

Continuo y finalizo el post de ayer sobre recolección de basura en sistemas que necesitan tiempos rápidos de respuesta.

  1. Optimizar el tamaño de los TLABs : Esta es para nota. Un TLA (TLAB en Sun JDK, Jon Masamitsu escribió hace un año una excelente entrada sobre esto) es una zona de memoria en la que un thread tiene permiso exclusivo para acceder lo que significa que el thread puede reservar memoria sin ningún tipo de bloqueo por lo que el rendimiento es mayor.

    Configurar un tamaño adecuado de estos TLAs es algo complicado, de hecho se hace una tarea muy ardua sin una buena herramienta para controlar los cambios en el rendimiento, pero puede incrementar considerablemente el rendimiento.
  2. Ajustar el límite para la recolección de basura : Las recolecciones completas de basura no se realizan cuando el heap está lleno, ya que en ese momento se lanzaría una OutOfMemoryException, sino que se lanzan al llegar a un determinado límite. Las máquinas virtuales permiten cambiar ese límite.

    En ocasiones este límite puede ser demasiado bajo, y si realmente se conoce muy bien el funcionamiento de la aplicación se puede ajustar para que sea un poco mayor y de este modo quepan más objetos en memoria (con el consiguiente coste de recolección).
  3. Evitar la fragmentación y optimizar el ratio de compactación: Las máquinas virtuales sufren el mismo problema que la memoria física o los discos duros. El almacenamiento continuo de objetos crea fragmentación. Para solucionar esto, existe lo que se llama compactación. Periodicamente, con cada recolección de basura, la máquina virtual tratará de compactar algo del espacio del heap para que cojan más objetos.

    Las máquinas virtuales suelen ofrecer parámetros avanzados para configurar el modo en el que se compacta la memoria. Por ejemplo en JRockit es posible establecer el tanto por ciento de heap que se quiere compactar en cada recolección. Un porcentaje alto hará que se gaste mucho tiempo compactando, mientras que un porcentaje bajo puede incrementar demasiado la fragmentación, llegando incluso en el caso límite a provocar OutOfMemoryException cuando no hay más espacio para colocar objetos en memoria. Otra opción típica es en lugar de especificar el ratio de compactación sería especificar directamente el máximo número de objetos que pueden ser compactados en cada recolección de basura.
  4. Conocer el tamaño de los objetos: Conocer el tamaño de los objetos que la aplicación maneja también es importante. En un caso extremo, si se están almacenando objetos demasiado grandes, que no cojan en la young generation (e.g. enormes imágenes) irán directamente a parar a la old generation, incluso cuando se usen tan sólo temporalmente. En este caso, y si nuestra aplicación maneja frecuentemente este tipo de objetos, podemos caer en una situación en las recolecciones completas de basura sean muy frecuentes, o en la que simplemente obtengamos OutOfMemoryExceptions.

Bueno, más o menos estas son las cosillas que recogí en el análisis y que quizás a alguien le valgan. Dejo aquí unos enlaces con mucha más información y que he utilizado de fuente:

BEA JRockit configuration and tuning guide
BEA Memory Management Concepts Guide
IBM Garbage Collection Policies
Tuning Garbage Collection with the 5.0 Virtual Machine
Jon Masamitsu's Weblog

Si alguno tenéis alguna recomendación, añadido, corrección, etc., pues los comentarios son más que bien recibidos.

martes, julio 10, 2007

GC para tiempos bajos de respuesta (I)

martes, julio 10, 2007 por Martín

Hace unas semanas tuve que realizar un pequeño análisis de la recolección de basura en JRockit para llegar a una recomendacción de argumentos, políticas, etc. Voy a poner aquí algunas de las notas por si a alguno le resultan útiles, aunque la verdad es que muchos seguro que ya las conocéis de sobra.

Gran parte de este análisis está basado en la búsqueda de tiempos de respuesta bajos. En el caso de intentar optimizar un sistema para un máximo throughput, sería necesario realizar algunos cambios. Son notas genéricas en la medida de lo posible aunque mi análisis estaba orientado a JRockit.

  1. Preferir GC estático sobre dinámico: Algunas máquinas virtuales, como por ejemplo JRockit, tienen un modo de ejecución dinámico en la que van modificando los parámetros del algoritmo de recolección de basura en base al rendimiento de la aplicación. Son capaces de aumentar el tamaño del heap, disminuirlo, cambiar el tamaño de las generaciones o cambiar los valores de los diferentes parámetros según crean conveniente.

    El problema de esto es que con un algoritmo dinámico pierdes el control de la gestión de basura, y aunque la máquina virtual es realmente inteligente, en muchas ocasiones te desea restringir lo máximo posible la libertad del GC para tener la situación controlada.

    Este es el caso de los sistemas donde no se puede tolerar de ningún modo un tiempo de respuesta alto, ya que puede significar el incumplimiento de un SLA y como consecuencia una perdida económica importante.
  2. Establecer el máximo el mínimo del heap al mismo valor: De lo contrario, la máquina virtual estará gastando valiosos ciclos de CPU en alargar y encoger el tamaño del heap continuamente según considere conveniente. Nuevamente esto puede afectar al rendimiento de la aplicación e influir negativamente en los tiempos de respuesta.
  3. Asegurarse de que el tamaño del heap no es tan o más grande que la memoria física: En un servidor (o cualquier ordenador) siempre hay más procesos ejecutándose a parte de la máquina virtual. Estos procesos requerirán su espacio de memoria física. Si el tamaño del heap de la máquina virtual es demasiado grande entonces podemos caer una situación en la que nuestro servidor esté continuamente paginando porque no habrá suficiente memoria física para todos los procesos, o sólo para él si ha pedido demasiada memoria. Esto originará continuos accesos a memoria virtual para intercambiar páginas de memoria, lo que enlentecerá todo el sistema, disminuyendo drásticamente el rendimiento del mismo.
  4. Utilizar un algoritmo de recolección concurrente: Hoy por hoy la mayoría de máquinas virtuales te ofrecen la posibilidad de utilizar diferentes algoritmos según tus necesidades. Dos de los algoritmos más típicos son el concurrente, orientado a tiempos de respuesta bajos, y el paralelo orientado a conseguir un máximo throughput.

    En el algoritmo concurrente la recolección de basura se hace paralelamente a la ejecución de la aplicación, en pequeñas pausas que dan la impresión de que no hay recolección de basura. La desventaja es que se dedica constantemente tiempo de CPU para realizar esta labor.

    En un algoritmo paralelo, el recolector simplemente no realiza la recolección de basura hasta que no se llena por completo el heap. Una vez que el heap está completo, se para la ejecución de todos los hilos y se inicia una enorme recolección de basura dedicando todas las CPUs disponibles a esa tarea. Todas las CPUs realizan la recolección de modo paralelo.

    El problema de este último algoritmo para sistemas de respuesta baja es que la recolección puede ser enormemente costosa y detener el sistema por segundos o incluso minutos, lo que significa con toda seguridad romper SLAs que tengas marcados. Es por ello que un sistema como estos no puede recurrir a una recolección de este estilo que para por completo la ejecución del sistema.
  5. Optimizar el tamaño de la young generation:
  6. Los algoritmos orientados a una rápida respuesta suelen estar basados en generaciones. Normalmente hay dos generaciones, una joven (young generation, nursery en JRockit) en la que se alojan los objetos recientemente creados, y otra vieja (old generation) en la que se van guardando los objetos que permancen más tiempo en memoria. Las recolecciones de basura en la young generation suelen ser cortas y rápidas. Cuando la young generation se llena, se realiza una recolección, se vacia la generación y se mueven los objetos que deban quedar en memoria a la old generation. El tamaño de esta young generation es bastante importante. La idea es mantener su tamaño lo más grande que sea posible al tiempo que se mantiene el tiempo de recolección en un rango aceptable. Si la young generation es demasiado grande, las recolecciones serán más costosas y esto impactará en el rendimiento del sistema. Al mismo tiempo, estaremos dejando menos espacio disponible para la old generation, lo que eventualmente puede hacer que las recolecciones completas de todo el heap sean más frecuentes. Por el contrario, si el tamaño de la young generation es demasiado pequeño, no daremos tiempo a que los objetos se liberen, y la mayor parte serán promocionados rápidamente a la old generation, lo que hará que ésta última se llene rápidamente causando recolecciones completas de todo el heap. Es importante pues mantener el tamaño de la young generation en un punto equilibrado. Lo suficientemente grande para darle tiempo a los objetos a ser desreferenciados pero sin que sea demasiado costoso realizar una recolección de basura en ella.


Como he visto que este post me queda bastante largo he decidido dividirlo en dos. Muy pronto pondré la segunda parte. Mientras tanto si alguien quiere aportar algo... bievenenido sea.

domingo, julio 08, 2007

Irlanda: PowerScourt Falls

domingo, julio 08, 2007 por Martín

Ayer, aprovechando uno de los pocos (¿el único?) días en los que no ha llovido durante el último mes o más (que no señores políticos irlandeses, que no necesitamos plantas de desalinización), decidí salir a dar una vuelta en bici que hacía muchísimo que no la cogía.

Hace meses, visitamos la PowerScout House y sus jardines, una casa señorial bastante espectacular del siglo 13 que bien merece la pena visitar para un fin de semana. Está en Eniskerry, dentro del condado de Wicklow, pero muy cerca de Dublín. Una de las cosas que nos quedaron por ver eran las cataratas de la propiedad, que se encuentran bastante lejos, a unos 7 km. Así que me decidí a tirar para allí en bici.

La verdad es que probablemente no es el mejor viaje para hacer en bici ya que resulta bastante rompepiernas. Todo es subir y bajar pequeñas colinas sin demasiado descanso. El recorrido es la mayor parte a través de carreteras bastante estrechas, a veces incluso entre acantilados, pero muy bonito. Los conductores irlandeses son bastante concienciados, supongo que porque aquí se anda bastante en bici, pero aún así las carreteras tan estrechas te dejaban algo intranquilo cuando pasaban coches.

Por el camino me encontré con alguna sorpresa, y también algún paisaje típico irlandés. Fijaros lo atípica que es esta ciudad porque estas fotos están sacadas a menos de 20 km. del centro.

Y finalmente, tras mucho pedalear, ahí estaba la dichosa cascada. Si no me equivoco es la más alta de Irlanda con 130 metros. La verdad es que el sitio estaba realmente bien, y había bastante gente haciendo barbacoas, y también una novia con sus damas haciéndose las fotos.



Creo que serían unos 50 km. entre las vueltas que di. Como podéis suponer hoy mis piernas están todavía protestando.

sábado, julio 07, 2007

Sourceforge revoluciona el mundo del Open Source (otra vez)

sábado, julio 07, 2007 por Martín

Hace casi 8 años (aquí un enlace a una presentación sobre su historia) Sourceforge.net revolucionó el mundo del Open Source al ofrecer a todo el mundo un repositorio público para alojar proyectos de manera gratuita. Durante todos estos años, Sourceforge.net se ha convertido en un punto de referencia para el mundo del Open Source y un lugar donde se alojan e incuban desde proyectos recien creados hasta otros mucho más maduros y mundialmente conocidos.

Es de sobra conocido, que durante todos estos años Sourceforge ha tenido muchos problemas, pero siempre los han ido resolviendo con bastante profesionalidad. Ahora, tras todo este tiempo, parece que están decididos a darle un nuevo empujón al mundo del software libre gracias al SourceForge MarketPlace.

Ayer me llegó un correo avisándome de que el SourceForge MarketPlace entraba en fase de beta y que se podía probar ya públicamente. Todavía no me he apuntado pero si vais a la web veréis que ya hay algo más de 60 proyectos que ofrecen servicios (cuando miréis habrá más seguramente). Pinchando en cada proyecto se puede ver los diferentes servicios que dicho proyecto ofrece, la duración del servicio y el precio del mismo.



Por lo que he visto navegando por el servicio los proyectos pueden vender servicios utilizando tarjeta de crédito, paypal o mediante un acuerdo para pagar con dinero en efectivo. Si no me equivoco se trata de una beta en la que le van ofreciendo gradualmente acceso a los proyectos, ya que a mi me ha llegado hoy la invitación pero ya había otros proyectos inscritos de unos cuantos días antes.

En mi opinión se trata de un gran empujón al Open Source. El concepto de donaciones introducido hace años ya estuvo muy bien, pero sin lugar a dudas esto va mucho más allá y rompe definitivamente el mito de "el Open Source es gratis y vive de donaciones".

Es más, seguro que mucha gente confusa con el concepto de OSS mostrará más interés al ver que hay soporte comercial detrás, y por parte de los desarrolladores originales. Por otra parte, ofrecer soporte comercial siempre te requiere un pequeño esfuerzo que SourceForge.net hace ahora por nosotros, lo que supone una gran ayuda para el proyecto pequeño que está empezando.

Un diez de nuevo para SourceForge.

jueves, julio 05, 2007

Charlas sobre escalabilidad en Google

jueves, julio 05, 2007 por Martín

Hace un par de semanas se celebró en Seattle la Seattle Conference on Scalability organizada por Google. Algunos videos ya se pueden por fin encontrar en google video:

Todavía no he visto ninguna pero espero que estén bien.

martes, julio 03, 2007

Java EE 6

martes, julio 03, 2007 por Martín

Cuando algunos servidores de aplicaciones todavía no soportan Java EE 5, el Java Community Porcess ha presentado ya lo que será Java EE 6. Pero tranquilos, que por ahora la especificación no verá la luz hasta el 2008, aunque claro, no queda tanto :)

El caso es que leyendo un poco el JSR hay unas cuantas cosillas que llaman la atención (o no tanto). Sobre todo lo más importante es parece que se reconoce finalmente el descontrol de la especificación, y parece que por fin (¿tarde?) se intentan poner soluciones a esto.

Lo primero es que se reconoce que la plataforma no puede crecer al ritmo y de la forma que lo ha estado haciendo hasta ahora:

It would not be appropriate for the Java EE platform to grow without bound to include all the interesting and useful technologies desired by web and enterprise application developers.

La solución en este caso es la creación de puntos de extensión y SPIs. Será interesante ver si alguna especifiación de módulos y plug-ins tiene hueco por aquí.

Segundo, se reconoce la perdida de rumbo y sentido de la especificación durante los últimos años, lo que ha complicado innecesariamente la vida a los desarrolladores:

The reach of the Java EE platform has become so broad that it has lost some of its original focus.

Para solucionar esto se propone perfiles que contengan subconjuntos de la especificación y que hagan mucho más fácil el ponerse a trabajar con la misma. Así, un desarrollador web sólo necesitará descargarse el Java EE Web Profile y no tendrá que lidiar con todo lo que no tenga que ver con el desarrollo web.

Y tercero, se reconoce el fracaso y se prepara la expulsión de ciertas tecnologías que han dejado de ser necesarias:


It's also the case that some technologies included in the Java EE platform are no longer as relevant as they were when they were introduced to the platform.


Entre las candidatas a pasar por la guillotina están EJB CMP y JAX-RPC.

Por lo demás, pues nada, la tradicional lista de nuevas tecnologías, nuevas APIs, actualizaciones, etc. Lo podéis ver en el JSR. También resulta bastante curioso que cosas como Timers o Work Managers se aprueben ahora, varios años después de que ya muchos servidores de aplicaciones soportasen ese concepto, y de que tantos desarrolladores lo pidiesen, algo que llevó a BEA e IBM a definir la especificación commonj.

En fin, que parece que queda aún JEE para rato.

lunes, julio 02, 2007

Jugando con JIRA y Mylyn

lunes, julio 02, 2007 por Martín

Uno de los plug-ins más interesantes que vienen con Europa es Mylyn, vamos lo que antes se conocía como Mylar pero que ahora ya forma parte de los plugins "de primera" que vienen con Eclipse.

Mylyn te permite integrar Eclipse con gestores de tareas como Bugzilla o JIRA enfocando el desarrollo a la resolución de tareas. La idea es que pasar del típico desarrollo descoordinado a algo más orientado a tareas, de forma que se pueda estimar su duración, que se asocie un determinado contexto (clases, métodos, atributos) a dichas tareas, que se integre con el sistema de control de versiones y que se pueda interactuar con el sistema de tareas que utiliza la empresa.



El soporte de JIRA todavía está en incubación, y hay que descargárselo de otro sitio de updates, pero bueno, se pueden hacer cosas como buscar tareas, crear grupo de tareas, asociar los contextos (esto es de lo más chulo de la herramienta y os recomiendo echar un vistazo), actualizar las tareas con comentarios y attachments, y también tiene la integración con subversion de modo que cuando haces commits actualizará la tarea en JIRA.

De todas formas se nota que para JIRA todavía está algo flojo porque hay cosas que no funcionan, como que no es capaz de ver attachments (pero sí es capaz de subirlos), o que no es capaz de asociar los contextos de trabajo con las tareas de JIRA (la idea es que si tienes un contexto de trabajo con varias clases, lo asocias a la tarea, y así otro desarrollador se lo descarga y sabe exactamente qué es lo que tiene que mirar).

Si os interesa más el tema aquí dejo unos enlaces:

domingo, julio 01, 2007

jLibrary 1.1 disponible

domingo, julio 01, 2007 por Martín

Pues nada, me toca anunciar esta actualización de mi proyecto jLibrary que la mayoría ya conocéis. No me voy a parar mucho en las novedades porque, tampoco son muchas y las podéis encontrar en la web.

Lo más notable es la migración del cliente a Eclipse 3.2, la sustitución del protocolo de servicios web por algo más ligero basado en tunnelling HTTP, la posibilidad de añadir propiedades personalizadas a los documentos, y finalmente que ahora hay una nueva versión para Mac OS X. Además las versiones de Linux son mucho más estables ahora, y el proceso de construcción está basdo en Maven 2 y ahora es mucho más sencillo, lo que debería hacer más fácil que alguien interesado en el proyecto sea capaz de ponerse a trabajar con el en minutos.

Dejando a parte las novedades, para mi esta ha sido más que nada una versión de compromiso. Ha sido una actualización moral. Con jLibrary 1.0 había una serie de cosas que no me gustaban nada, especialmente que no pudieras subir documentos grandes (+10Mb) sin incrementar el tamaño del heap de las máquinas virtuales del cliente y servidor, todo ello debido al consumo y a la forma en que Axis transmite los contenidos. Otro compromiso fue las continuas peticiones por parte de usuarios de poder crear propiedades personalizadas, aunque esto último también tiene que ver con la orientación que le quiero dar ahora al proyecto. Y por último estaba la necesidad moral de cambiar el método de construcción; sustituir todos los hacks de Ant por algo mucho más decente y sencillo basado en Maven.

Todos estos cambios han llevado mucho más tiempo del que me temía. Mi cambio de residencia y de forma de vida ha reducido drásticamente el tiempo que le he podido dedicar al proyecto; y si antes podía dedicarle dos horitas extras al día, pues ahora se han convertido en dos horitas extras a la semana. Todo ello me ha hecho replantearme el futuro de jLibrary.

Y es que para mi ahora mismo jLibrary ha llegado a lo que debe ser un punto de inflexión. Muy probablemente esta sea la última versión del cliente basado en Eclipse RCP, que yo haga. En su momento estaba interesado en la tecnología, pero creo que ya la he aprendido más que de sobra :-) Así que es algo que no me motiva demasiado ya.

Lo que sí que me interesa mucho más ahora es trabajar en la parte servidor de jLibrary. En mi opinión el proyecto puede ser un banco de pruebas muy bueno para muchas tecnologías. Es un servidor estable, que ofrece una abstracción documental sobre una tecnología estándar (JSR-170) y que se me antoja como un banco de pruebas muy interesante. La idea es que para mi es más fácil ahora utilizar jLibrary para probar un determinado framework que crear desde cero todo un modelo de datos, relaciones, persistencia, configuración, etc.

Es decir, que si quiero probar Wicket, Seam y similares, pues puedo utilizar jLibrary para ello; que si quiero jugar con Grails, pues más de lo mismo; qué si lo que quiero es crear una web de reviews, un sistema de blogs, un youtube de documentos, o una alternativa a diggs meneames y similares, pues ahí está un framework que me ofrece ya las abstracciones para documentos, directorios, recursos, categorías, tags, relaciones, bookmarks, que además soporta propiedades personalizadas, y que tiene una aplicación de escritorio para administrar todos los datos.

Si alguien está interesado en esta idea, tiene algo en mente, quiere probarlo, etc., pues sólo tiene que mandarme un correo (mpermar en gmail). Las posibilidades están ahí, y a ver si sale algo de todo esto. Quizás no salga nada, pero mientras se pueda juguetear y aprender, pues ya habrá beneficio.