sábado, marzo 29, 2008

Paseando por Galway, Aran Islands y Connemara

sábado, marzo 29, 2008 por Martín

Ya que últimamente se suceden los comentarios reclamando más posts sobre Irlanda, os ucento lo que hicimos el fin de semana pasado, que no lo había comentado. Nos fuimos con unos amigos de viaje por el Oeste de Irlanda. La verdad es que nos lo pasamos genial, y a todos los que tengan planeado visitar la isla, no puedo más que recomendarles el centrarse en la parte Oeste de Irlanda en lugar de en las zonas más habitadas del Este, incluido Dublín.

Los dos primeros días los dedicamos a Galway y alrededores, incluyendo los famosos acantilados de Moher. La verdad es que Galway es muy pequeño, pero en mi opinión muchísimo más acogedor que ciudades más grandes como Dublín o Cork. Por lo que pude ver en esos dos días, hay muchísima vida nocturna. Muchísimos locales con conciertos en directo tanto de grupos tradicionales como más modernos, muchos night clubs, restaurantes, etc.



El Domingo, nos fuimos a las islas de Arán. En avioneta.



Aer Arann tiene un servicio bastante frecuente entre las cercanías de Galway e Inishmore, que es la isla más grande y habitada de entre las tres que hay. No sé si alguno de vosotros os pasará como a mi, pero con el paso de los años y de los vuelos, cada vez me gusta menos eso de montarme en un avión. Y lo de montarme en una avioneta en la que cogen ocho personas y una va de copiloto, pues casi que menos. Pero bueno, la realidad es que el vuelo fue muy suave. Son sólo unos ocho minutitos, casi todos por mar y a no mucha altura, así que no hay demasiado peligro. Supongo :) Por cierto, que si a alguien le gusta volar incluso menos que a mi, hay un servicio de ferry bastante frecuente también, y el viaje lleva unos 30 minutos.

Inishmore es un sitio especial. Con sólo unos 860 y pico habitantes censados para 31 km2, os podréis imaginar como de poblada está la isla. Lo mejor de todo es que te puedes alquilar unas bicis y recorrértela a tu gusto. La isla en si misma no es demasiado bonita en cuanto a vegetación se refiere, aunque también es cierto que la época en que la hemos visitado no ayuda. Sin embargo, se respira tanta tranquilidad que a mi me hizo sentir que estaba en un lugar donde no me importaría quedarme una temporada. Sentir el viento, el mar, los árboles moverse, sin nada de ruido... En fin.

La parte norte de la isla sí que es bastante espectacular, y en ella hay uno de los fuertes prehistóricos (1000 antes de cristo) más importantes de Europa: Dun Aonghasa. Ver ese sitio, de por sí, merece la visita a la isla. La parte inferior de la isla también es chula, y mucho más llanita. En esta parte, además, hay una zona con una colonia de focas que también resulta bastante chula.




El Lunes, ya de vuelta de la isla, sniff, nos dimos un paseo muy rápido por la región de Connemara. Se trata de una región montañosa que le gustaría mucho a los amantes del trekking. Dentro de Connemara, la abadía de Kylemore es bastante espectacular.



Y como decía el otro, eso es todo amigos. Que por cierto, muy importante. Todas estas estupendas fotos y más son de a mi amigo Javier, que era uno de nuestros fotógrafos oficiales, y que sin el ni este viaje ni mi estancia en Irlanda serían lo mismo. ¡Gracias Javi!

Amazon mejora su oferta de cloud computing con IPs estáticas y múltiples datacenter

sábado, marzo 29, 2008 por Martín

Ayer estuve leyendo las novedades que ha añadido Amazon a su oferta de cloud computing y la verdad es que cada vez resulta realmente más atractiva.

Parece que lo primero que han hecho es añadir IPs estáticas; o bueno más correctamente lo que ellos denominan IPs elásticas, que sería como una IP estática pero asociada con una cuenta de usuario. De modo que un usuario no puede tener más de cinco IPs elásticas pero que las puede manejar a su antojo dándolas de alta, de baja, asociándolas a diferentes instancias en diferentes momentos, etc. En el blog de RightScale presentan un muy buen ejemplo de como utilizar estas nuevas IPs.

La segunda novedad es que ahora es posible disponer de servidores en múltiples localizaciones, gracias a lo que Amazon llama availability zones. Así pues, ahora amazon permite reservar instancias en diferentes regiones que pueden estar en diferentes países y continentes, y a su vez dentro de cada región se pueden seleccionar diferentes availability zones. Cada availability zone, garantiza su independencia de las otras zonas dentro de la misma región, de modo que si existe un desastre en una de las zonas, la otra todavía seguirá activa. Nuevamente en el blog de RightScale tienen un ejemplo fenomenal sobre como utilizar esta funcionalidad.

Se ve que Amazon se está espabilando a raíz de los últimos movimientos en el mercado. ¡Si es que no hay nada como la competencia!

jueves, marzo 27, 2008

Round Robin Databases

jueves, marzo 27, 2008 por Martín


El año pasado por un requerimiento del trabajo me encontré on una herramienta que nunca había visto antes. Se trata de RRDTool. En su momento iba a postear sobre ello pero me imaginé que era algo bastante conocido ya que parece que mucha gente de sistemas está familiarizada con este tipo de herramientas. Hace unos días me encontré con un requisito que se ajustaba a este tipo de soluciones y la gente tampoco conocía el concepto por detrás de RRDTool, así que supongo que no está de más guardar el conocimiento por aquí.

RRDTool es una herramienta construida sobre el concepto de Round-Robin Database. Se trata de un tipo muy específico de base de datos, orientadas al almacenamiento de datos basados en series temporales, y que garantizan el espacio final ocupado por sus elementos.

RRDTool es muy sencillo de utilizar, y probablemente con un ejemplo se entienda mejor como funciona. Imaginaros un sistema de análisis bursátil. Cada día, una cotización puede variar de valor unas cuantas veces por segundo. Imaginémonos que varía 3 veces por segundo. Esto significa que en un día, asumiendo un intervalo de trading de ocho horas, se tienen 8*60*60*3 = 86400 valores por día. Si asumimos por ejemplo 100 valores a seguir, tendríamos 8640000 cotizaciones al día, lo que son casi 10 millones. En una semana (de 5 días), andaríamos cerca de los 40 millones de valores, y en un mes laboral rondaríamos los 200 millones.

Ahora bien, ¿a quién le interesa el valor que tenía la acción de Endesa en el segundo 20, del minuto 35, a las cuatro de la tarde del 21 de Enero del 2008? Respuesta simple: a nadie. Comúnmente la granularidad fina en los datos temporales es sólo interesante en una ventana corta de tiempo. Por ejemplo en un sistema de seguimiento de transacciones, interesa saber que ha fallado una transacción en las pocas horas, pero pasados los meses la información de exáctamente cuándo deja de perder importancia (sigue teniendo importancia el saber que hubo un fallo, pero ya no importa si en lugar de minutos nos quedamos con el día).

Lo que hace RRDTool es agrupar la información conforme a intervalos de tiempo que nosotros definimos. Por ejemplo, le podemos decir que queremos que guarde los datos con una granularidad de 1 segundo para la primera hora, con granularidad de 5 minutos, para las siguientes 23 horas, con granularidad de 30 minutos para 1 semana, 1 hora para los tres primeros meses, y 1 día para los últimos 9 meses del año. Al introducir datos en RRDTool, la herramienta se encarga de realizar las agruaciones y las medias conforme a los intervalos que hemos definido.

Seguramente, incluso los que no habíais oído hablar del concepto de Round-Robin Database ya os habríais encontrado con estos sistemas hace tiempo. En la página web de RRDTool tienen una amplia galería de ejemplos, pero si vais por ejemplo a Yahoo Finance (por poner un ejemplo) veréis como para mostrar las gráficas, la granularidad de los valores de una acción dependen del tipo de intervalo que escogéis: 1 minuto para el día, 5 minutos para 5 días, 1 día para el intervalor de 1 mes, etc. Se trata de economizar información.

En su web tienen bindings para lenguajes como Python y Ruby. Para los javeros, existe una implementación 100% Java de RRDTool: rrd4j que yo he probado y funciona bastante bien.

Pues nada más por hoy. ¡Espero que esto le sea útil a alquien!

martes, marzo 25, 2008

Y más WTF

martes, marzo 25, 2008 por Martín

El mes pasado me pasaban una viñeta sobre la medida WTF para las Code Reviews. Hoy la han dejado caer de nuevo por mi trabajo y alguien contestó con esta otra web, The Daily WTF, que seguro que alguno conocerá, pero que yo no conocía y es realmente graciosa.

Me ha llamado la atención que el primer post de hoy es de un chaval de Barcelona que trata de "pedirle ayuda" a alguien que había publicado unos tutoriales de estructuras de datos en Internet. Habiendo publicado bastantes tutoriales y artículos en Internet, yo también recibí en su tiempo montones de correos eventuales de gente que te contactaba para ver si le ayudabas con las prácticas, proyectos, empresas, etc. Eso sí, nunca me habían llegado a ofrecer dinero por hacer una práctica. No tiene desperdicio :)

Dear Rob

First of all sorry for my English isn't really good : -) Well , my name es ***** ***** and I'm computer ( last year ) student in politechnical
University of Catalonia (barcelona SPAIN ). I'm writing you because

I need help in computer graphics and I'm totally desperate. The situation
is the following, I'm doing the last courses of my studies and also working ,
no way i need earn money . Conclusion, no time for be focus in all the
subjects...and particularly computer graphics subject. I have to submit a
computer graphics project for the next Monday until 8,30 am, and really for
me impossible to do it, no time, poor computer grapichs knowlodege ,etc,etc..

So i was looking on internet good example and i found your web page.. and i
decide to write you for do a business.

Probably for you my project will be easy to manage, because is an introduction
subject of computer graphics, and maybe you don't need to spend more than 4
hours.. for the reason if you want I can pay you 150 ? for this first part
and 150 ? more for the second part.. if you are agree. I'm not a reach man is
a effort for me pay all this money but as i said you I'm totally desperate and
i will do but i think is a reasonable price.

So if you are interested this is my proposition :

- Give me response to my proposal
- If you are agree more or less agree i send you my project translate (the
original is in catalan) -We can arrange the way for pay you, by PayPal, your
own bank account, as you prefer...
- I send you the money according ( I will have trust ... no other way to do it.. )
- You send me the project , finish of course before Sunday (the deadline for
submit the project is on Monday 26 of November until 8:30 pm )

Best Regards,

***** *****

lunes, marzo 24, 2008

Trabajando en el campo

lunes, marzo 24, 2008 por Martín

Como ya sabréis los que seguís este blog, el mes pasado anuncié que se había acabado un ciclo. Uno de los cambios más radicales que estoy notando es el del lugar de trabajo.

El cliente donde estoy trabajando está en Monkstown Farm que es probablemente uno de los lugares más extraños para encontrar una empresa en Dublin. Se trata de una zona residencial, donde construyeron un pequeño edificio de oficinas que sólo tiene dos inquilinos, uno de ellos la empresa para donde trabajo. Total, que la zona donde trabajo está llena de casas, parquecitos y por qué no, hasta alguna sorpresa:



Esta foto está burdamente sacada de Flickr. Buscando Monkstown town en Flickr os daréis una idea de a lo que me refiero con que esto es un sitio muy tranquilo.



No es algo necesariamente malo, especialmente teniendo en cuenta que el centro de Dublin no es una zona especialmente agradable para trabajar. De hecho es muy agradable el caminar hasta el trabajo. Eso sí, el único problema es la falta de lugares para comprar comida.

jueves, marzo 20, 2008

IBM abrirá un centro de cloud computing en Dublin

jueves, marzo 20, 2008 por Martín

Noticia portada en los periódicos tanto online como impresos por estas zonas. Resulta que IBM abrirá el primer centro europeo de cloud computing en Dublin. Según se comenta en la noticia que enlazo, parece que IBM dará trabajo a 21 personas y basará su tecnología en software Open Source.

Hace poco ya comentaba que Sun se preparaba para competir con Amazon. Y la verdad es que parece que esto se está convirtiendo en una moda ya que hace unos días HP lanzaba su plataforma de cloud computing y parece que pronto lo hará Microsoft.

Está claro claro que los vendedores de servidores tienen que ponerse las pilas para entrar en un mercado ahora mismo dominado por Amazon y lleno de pequeños proveedores. A medida que pasan los meses cada vez son más empresas las que se apuntan a la moda del cloud computing y que ahorran costes, y dolores de cabeza, utilizando centros de computación virtuales, que además de ser bastante baratos son mucho más sencillos de administrar y, por qué no, proponen un modelo de computación mucho más limpio.

La verdad es que la cosa se pone la mar de interesante en este frente.

miércoles, marzo 19, 2008

¿Está grails listo para el 'prime time'?

miércoles, marzo 19, 2008 por Martín


Llevo (llevamos) ya unas semanas trabajando con Grails así que no os extrañéis si de vez en cuando sale por este blog algún post como éste sobre este framework. Una de los problemas que se le achaca a frameworks como Grails (o uncluso Ruby on Rails) es su incapacidad para afrontar proyectos grandes.

Aún así, poco a poco van apareciendo casos de uso de empresas importantes adoptando estas tecnologías. Es el caso de Sky que ha lanzado un nuevo sitio de "cotilleos" basado en grails y cuyos desarrolladores han relatado su experiencia recientemente en este hilo de la lista de correo de grails. Muchas de las lecciones son aplicables también a otros frameworks como JRuby on Rails o Ruby on Rails por lo que puede ser interesante echarle un vistazo.

El sitio web fue desarrollado por 18 desarrolladores, aunque no comentan cuanto tiempo les ha llevado. Durante el primer día recibieron 1 millón de peticiones (que creen que son muy pocas para lo que esperan), aunque realmente sólo un porcentaje de ellas llegaron hasta la capa web. Para hacer frente a la carga contrataron un CDN y colocaron los correspondientes balanceadores de carga.

Estas son algunas de las conclusiones a las que han llegado:


  • Desarrollar una aplicación web en grails es más divertido y sencillo que hacerlo en puro Java.

  • El soporte de herramientas es bastante pobre y es algo que debe mejorarse. De esto no puedo más que dar fe.

  • Utilizaron ocho diferentes entornos y tuvieron problemas en cuanto a la configuración. No les quedó más remedio que crear su propio plugin para manejar su entorno.

  • La documentación en cuanto a como arrancar con grails es insuficiente. No hay una receta clara sobre como empezar a utilizar el framework ni recomendaciones/buenas prácticas para entornos de preducción.

  • El framework de testing que expone grails ahorra muchísimo trabajo, especialmente a la hora de testear la interacción con la base de datos.

  • Fue muy común el encontrarse con plug-ins que no satisfacían todos sus requisitos, es decir que muchos plug-ins no están pensados para 'usos extremos', y tuvieron que tocar su código y modificarlos más veces de las que hubiesen deseado.

  • Los problemas de compatibilidades entre plug-ins fueron también bastante comunes, aunque reconocen que el estado general del ecosistema de plug-ins es aceptable.



En las próximas semanas probablemente comente algunas de mis/nuestras experiencias con este framework. Aunque por ahora, lo que puedo decir es que subscribo todos y cada uno de los puntos de la experiencia de los desarrolladores de Sky.

viernes, marzo 14, 2008

El nuevo modelo de empaquetado de EJBs

viernes, marzo 14, 2008 por Martín

En TheServerSide publican la segunda parte de la serie sobre las novedades en EJB 3.1. Este artículo habla sobre el nuevo TimerService que tiene muy buena pinta, y sobre el nuevo sistema de empaquetado.

Ya he sido crítico con EJB 3.1 antes, y aunque como ya he dicho el nuevo TimerService me gusta bastante, lo cierto es que el nuevo empaquetado no me gusta. Ya no es sólo el hecho de cambiar algo que se ha mostrado efectivo durante todo este tiempo sino más bien el transfondo que hay detrás de este cambio, que no es otro que el mismo que hay tras el cambio de hacer las interfaces opcionales: querer abarcar con EJBs todos los escenarios habidos y por haber.

Quizás es que estoy chapado a la antigua, y que vengo de cuando había EJB 1.x, y que casi todo lo que he hecho con EJBs ha sido con EJB 2.x, pero, ¿no hay nadie más por ahí al que esto...



...no le parezca más simple que esto?



En mi opinión la simplicidad no está en el tamaño de los dibujos, si no más bien en su estructura. Y, nuevamente en mi opinión, el meter todo en un sitio sin separar vista y negocio, el mezclar parte web y parte no necesariamente web, el entremezclar recursos utilizados en diferentes partes y permitir su uso indeferente, no son cosas que hagan una solución mucho más simple. Para mi, es justamente al contrario, la propuesta favorece la confusión. Y eso no es simplicidad.

A mi me gusta el modelo de separación en componentes propuesto por EJBs hasta ahora. Como en el caso de las interfaces, me parece una buena y muy recomendable práctica. El nuevo modelo, totalmente anárquico, está claro que apunta hacia desarrollos minimalistas, buscando el exponer EJBs como una tecnología fresca que se puede utilizar para todo. Sin embargo, ya empiezo a ver proyectos con datasources entremezclados y gente preguntándose dónde se ha declarado cada cosa, incompatibilidades entre recursos, proyectos que de pronto hay que separar en contenedor web y servidor de aplicaciones y se paran durante meses porque se diseñaron para ejecutarse como WARs, etc.

En fin, que parece que sigue la tendencia a lightweight EJBs. La verdad es que lo que noto es que cada vez esto le importa menos a la gente. Los que vivimos la época dorada de los EJBs poco a poco vamos dejando el paso a otras personas que no se tragan lo de que hay que usar EJBs por narices. Hay alternativas, y saben utilizar esas alternativas. Por lo tanto, en mi opinión estos cambios poco ayudan y al abrir el abanico de posibilidades están haciendo todavía más complejo el desarrollo y mantenimiento de aplicaciones basadas en EJBs.

Pero bueno, eso y el avance lento de los servidores de aplicaciones en parte debido a ese relevo generacional serían merecedores de otro post.

miércoles, marzo 12, 2008

¿La solución para plazos delicados? Arquitectura sencilla.

miércoles, marzo 12, 2008 por Martín

El Coding The Architecture London User Group ha publicado su primer podcast (slides)., que con un poco de suerte será el primero de una larga lista.

Es un podcast bastante interesante, ya que se trataba de exponer un caso práctico de un proyecto y como escogieron su arquitectura, aunque la calidad del audio no es demasiado buena. En ella hablan de un proyecto para desarrollar un sistema de análisis de riesgos que tuvieron hace unos meses para un banco de inversiones en Londres y que estaba programado para realizarse en 4 semanas. Sin embargo, tanto los requisitos no funcionales, no ya en cuanto a carga, si no más bien en cuanto a seguridad, como los funcionales ya que la lógica de el análisis de riesgos era bastante compleja, hacían que el proyecto fuese totalmente inabordable.

Después de duras discusiones, la solución fue adaptar la solución al márgen de tiempo disponible. Se encontró que para lo que realmente quería el banco era más que suficiente con prescindir del 90% de la lógica de análisis de riesgos y tener un sistema que más bien diese pistas sobre anómalias en lugar de algo 100% fiable; que no era necesario utilizar un potente servidor de aplicaciones sino que con un stack basado en Tomcat y Spring era más que suficiente; que a veces hay que dejar también tecnologías que en un principio son buena idea, como Hibernate o Maven, ya que el proyecto es lo suficientemente pequeño, y los plazos suficientemente ajustados, para que no tengan tanto sentido; o que muchas veces el cliente dispone ya de las herramientas para cubrir requisitos no funcionales, como en este caso el Veritas Cluster Server, y se pueden aprovechar también en lugar de ponernos nosotros a reimplementarlas.

La aproximación que siguieron para solucionar el problema es también bastante interesante. En lugar de rendirse al cliente y aceptar sus exigencias, apostando por la venta fácil y la entrega con retrasos, lo que se hizo fue la opción honesta que es ofrecer una solución adecuada pero con los plazos que se consideraban indispensables: en este caso seis meses. El cliente se da cuenta de la magnitud del proyecto y aceptan reducir funcionalidad. El proveedor de servicios se da cuenta de las necesidades inmediatas del cliente y aceptan prescindir de ciertas soluciones innecesarias.

En resumen un acuerdo entre ambas partes para reducir el espectro del proyecto que resulta en un final feliz. ¿Tenéis alguna historia similar?

sábado, marzo 08, 2008

Análisis de rendimiento y la necesidad de contratar especialistas

sábado, marzo 08, 2008 por Martín


Hace unos días, una persona de la que obviamente no voy a revelar ni el nombre ni nada sobre la empresa, me enviaba un correo en el que me preguntaba consejo:

Actualmente estamos en el proceso de implementacion de una aplicacion web en java, desarrollada utilizando JSF(ICefaces) + Spring + Hibernate, se esperan de 1000 a 2000 usuarios concurrentes, la aplicacion se accede desde todo el pais, de lado de la aplicaciones hemos echo bastante tunning, ej. No Lazy loading, No n+1 select, paginacion. Tambien al JVM un poco; pero apesar de eso, cuando llegamos a 500 usuarios activos la aplicacion ya no funciona.

JSF,Spring,Hibernate
Tomcat 6.14, Pool DBCP
Solaris 10 UltraSparcT1, 16 Micro Procesadores, 8 GB de RAM
JDK 1.5


El correo sigue con algunos detalles sobre pools:


<Resource name="jdbc/dsAcreditacion" auth="Container"
type="javax.sql.DataSource"
...
maxActive="25" maxIdle="10"

<Connector port="80"
maxThreads="500" minSpareThreads="25" maxSpareThreads="250"
maxHttpHeaderSize="8192" enableLookups="false"
redirectPort="8443" acceptCount="5000" connectionTimeout="20000"
disableUploadTimeout="true" maxKeepAliveRequests="1"/>


Y finalmente las dudas:

¿cuales cree que deberian ser las configuraciones para el pool de
conecciones y para el Connector de Tomcat, para manejar 1000 o 2000
usuarios recurrentes?

¿ hay alguna relacion entre cantidad de usuarios recurrentes y tamaño de
pool ?


Este, es el tipo de preguntas que muchas empresas obligatoriamente se plantearán llegado un determinado punto. Idealmente serían preguntas que el personal de sistemas sería capaz de responder ya que son los que tendrán que mirar por dichos servidores, aunque realmente el/los Arquitectos ya las deberían haber tenido en cuenta durante el diseño de la aplicación y deberían ser conscientes de las limitaciones de la arquitectura escogida y de su capacidad para escalar, y los desarrolladores deberían estar también minimamente familiarizados con algunos conceptos.

Pero, como no todo el mundo es de color de rosa, la realidad es que muchas empresas no tienen el personal adecuado para estas tareas. Ya sea por falta de experiencia, o por venir de otras plataformas, o por lo que sea, pero el caso es que muchas veces una empresa se encuentra sin respuesta para este tipo de preguntas.

En este caso, una opción es preguntar al autor de un blog. Sin embargo, yo sólo actuaré como médico de cabecera. No puedo solucionar el problema, simplemente podría decirte que estás malito, y que tu dolor en la barriga se puede deber a una intoxicación, o podría ser algo más grave, por lo que te recomendaría ir al especialista.

Siguiendo con el ejemplo anterior, puedo decir que la capacidad de no poder despachar más de 500 usuarios con esa configuración indica un problema. Podría ser que tengas un problema con las librerías que usas (AJAX?) y que el límite de 500 threads sea lo que te esté evitando el poder servir a más usuarios; o quizás decirte que el problema puede ser un memory leak que te evite escalar; o tal vez si la base de datos va a recibir muchas peticiones concurrentes, 25 hilos pueden hacer de cuello de botella; o que alojar un único tomcat en un máquina de 8Gb es tontería siendo sólo una de las razones que el tener un heap tan grande sería contraproducente y probablemente todo funcionase mejor con 4 tomcats con 2Gb cada, o quizás incluso más.

Y no es que no quiera o que me moleste especialmente que me preguntéis, pero es que todo esto no dejan de ser recomendaciones de alguien que en este caso actua como médico de cabecera. Alguien que por la distancia y por el desconocimiento tanto del negocio como de la aplicación y su arquitectura no puede dar más que una serie de sugerencias. Alguien que estando en la empresa durante unos días podría realmente ofrecer soluciones para esos problemas pero que moralmente no puede ofrecer un juicio de valor por la distancia.

En un caso como este, y a falta de ganas o presupuesto para contratar a personal con experiencia, lo ideal es contratar un especialista durante un tiempo. Alguien que se pase unas semanas con la aplicación y te redacte un informe de evaluación del rendimiento y de ofrezca sugerencias para su mejora. Alguien que te prepare un plan de monitorización de las aplicaciones. Alguien que se siente contigo y te asesore sobre los cambios necesarios en la arquitectura para mejorar su escalabilidad, resistencia, tolerencia a fallos, etc.

Estos especialistas no tienen porque ser necesariamente baratos. Pero como sugería en mi metáfora anterior, y como pasa en la vida real: "Una cosa es ir al médico de cabecera, o quedarse en casa automedicarse y otra muy diferente es ir al especialista".

Foto vía everyplace@flickr

miércoles, marzo 05, 2008

El offshoring perdiendo popularidad en USA

miércoles, marzo 05, 2008 por Martín

Un reciente estudio publicado en WallStreetTechnology indica que el OffShoring está perdiendo popularidad en los Estados Unidos.

El estudio fue realizado por una compañía independiente que entrevistó a 1400 CIOs de compañías con más de 100 empleados. La estadística muestra que el 94% de los entrevistados no están realizando ningún tipo de offshoring, el 86% no tiene ningún plan de hacerlo en los próximos dos años.

Centrándose un poco ya en los resultados donde han habido experiencias en el offshoring, 111 de los 1400 entrevistados estaban actualmente realizando offshoring, y el 43% parece lo suficientemente feliz como para aumentar las operaciones. Pero, 61 de los 1400 afirmaron haber cesado las operaciones de offshoring, siendo la razón más popular la de un difícil management del proyecto, con además el 30% de esos 61 afirmando que las ganancias no fueron como se esperaba.

Cuando se habla de offshoring en USA, irremediablemente los ojos apuntan a la India, y la verdad es que creo que son más, y cada vez más, los que se muestran más descontentos con los resultados de enviar trabajos a dicho país. Me ha parecido bastante interesante el post publicado en The Tired Architect en el que se predice el fin del offshoring en la India. Siendo un comentario que viene desde el centro de Bangalore no deja de ser esclarecedor.

La verdad es que mi experiencia con el desarrollo en la India no deja de ser aliviadora. Pero aliviadora porque no tuve que meterme en ello. Retrasos de varios años, turnover masivo en el personal subcontratado, proyectos desarrollados sin ningún tipo de control y apenas documentación, caos generalizado en los procesos de desarrollo, reuniones inmanejables entre varios paises en zonas horarias completamente diferentes, y quizás lo más desesperante, un bajo, muy bajo, nivel técnico.

Es increible ver como la gente sigue pensando que esto del desarrollo de aplicaciones es una commodity que puedes mandar a 10.000 kilómetros donde hacen programas como chorizos y los venden al kilo.

Vía softarc@blogspot.

martes, marzo 04, 2008

Aprovechando Lucene en memoria

martes, marzo 04, 2008 por Martín


Ya estoy de vuelta de estas mini vacaciones. Que bonita estaba Galicia, y más si tienes la suerte de ir a una boda en un pazo en Silleda, que no le tiene nada que envidiar a Irlanda.

En fin, que tenía pendiente postear sobre algo en lo que he estado trabajando en los últimos días, que no es nada complejo pero es algo que al menos yo no conocía: El utilizar Lucene en memoria

¿Por qué habríamos de querer hacer algo así? Pues bien, Lucene es una de las mejores librerías Open Source que pueden existir. Además tiene una cantidad de proyectos satélite que de por sí los hace muy interesantes para su uso en nuestras propias aplicaciones.

Muchas veces, los que hemos trabajado bastante con Lucene nos dábamos cuenta de que había ciertas funcionalidades que sería realmente útil para nuestras aplciaciones. Por ejemplo, para ejecutar algoritmos de stemming sobre textos, o quizás para simplemente filtrar stop words, o buscar con soporte de sinónimos, etc. El problema, era que para hacer esto necesitabas tener un índice de Lucene en disco con las desventajas que esto conllevaba.

Crear un índice de Lucene en memoria es algo tan sencillo como esto (me disculpáis que me coma los imports):

RAMDirectory idx = new RAMDirectory();
Analyzer analyzer = new SnowballAnalyzer("Spanish",SpanishAnalyzer.getStopWords());
IndexWriter writer = new IndexWriter(idx, analyzer, true);


(En este caso, la clase SpanishAnalyzer es propia, pero podéis utilizar cualquier analyzer ahí)

Ahora se podrían crear documentos y añadirlos al índice:

Document doc = new Document();
doc.add(new Field("id","abcde",Field.Store.YES,Field.Index.NO));
doc.add(new Field("text","esto es un texto de prueba",Field.Store.YES,Field.Index.TOKENIZED));
writer.addDocument(document);


Y por supuesto, hacer búsquedas:

Searcher searcher = new IndexSearcher(idx);
QueryParser parser = new QueryParser("text",analyzer);
Query query = parser.parse(text);
// Search for the query
Hits hits = searcher.search(query);


Sencillo y poderoso. Me encanta Lucene.