Este año he podido disfrutar asistiendo ambos días, además he disfrutado como más me hubiese gustado hacerlo siempre. Dado que desde hace un tiempo he estado trabajando más intensamente con Rails, y este ha sido el primer evento relacionado con el tema al que he podido asistir, eso si no contamos el evento de Tog en octubre .

Como es habitual, aporto mi pequeña gota de feedback y como también es normal, no lo haré de todas las charlas, sino de aquellas que más me impactaron o que por una causa u otra más recuerdos han dejado en mi. Para los que se queden con ganas de más, les recuerdo que la organización grabó las charlas y que seguramente pronto estarán disponibles los vídeos como en otras ocasiones.

Apertura y keynote por fxn. Una manera de abrir la conferencia singular, con referencias a hechos que originaron cambios. Personas que fueron contra corriente, con formas de pensar y/o hacer diferentes… Somos reacios al cambio, somos animales de costumbres y nos cuesta aceptar algo nuevo, pero cuando el cambio es llevado a cabo, cuando nos dejamos embaucar por lo extraño, sin duda disfrutamos como niños. Rails sin dudarlo es una pequeña cosa que ha hecho una gran diferencia. Frameworks hay muchos, intentos de hacerlo de otra forma también, pero corrientes como la que vivimos no han habido tantas. Lo que más me maravilla de esta comunidad es que muchos hemos llegado a ella con experiencia sobre otras, con lecciones aprendidas a fuego y veo cosas que me gustan bastante.

Caso de éxito: “Tog: Open Web, Social Networks y cintas de video”. Una explicación de la visión sobre los objetos sociales y sobre lo que una red social debería crearse. Intentando mostrar el aporte que Tog podría hacer con respecto a crear una red social. No sé si fue la charla, si oir a Aitor en estado catarroso o si definitivamente Tog tiene el tirón que parece. El caso es que el último día las votaciones de mejor proyecto del año 2008 recayó sobre él XD, y eso que fue liberado a ¡finales de septiembre! La verdad es que el trabajo detrás de esta primera inflexión que supuso la liberación del código se remonta a bastantes meses atrás. Antes hubo pruebas, proyectos, afinamiento de ideas y tras todo eso la creación de lo que ahora mismo es. Todo ello entorno a la idea que nos mueve de los objetos sociales y su valor.

Rails HOT or NOT. Os recomiendo verla en video . No había utilizado todos los plugins que se comentaron, en ocasiones no podía decir nada malo por uno de ellos, pero sin duda descubrí opciones, opiniones en base a experiencias y espero pronto leer las conclusiones en la lista de ror-es; además de invertir algo de tiempo en cacharrear con alguno de ellos.

Speed dating. Un experimento que pudo hacer que nos relacionásemos gente con proyectos en busca de gente y gente en busca de proyectos, aunque tubo un mayor aporte de empresas que buscaban personal para contratar que lo yo personalmente hubiese querido encontrar. Aún así, una grata experiencia.

Caso de éxito: “b5map: Maps on Rails”. La verdad es que ya conocía la web desde hacía tiempo, conozco Aitor por sus post en jaiku, pero desconocía las tiranteces que parece haber entre los ayuntamientos. Algo que me llamó mucho la atención, fue descubrir que el proyecto se había llevado a cabo aunando a freelances y pequeñas empresas, algo loable viniendo de una administración pública.

Keynote por Obie. Una forma de ver el mundo laboral y empresarial diferente a lo que se ve en este país. Sin duda oír hablar a Obie diciendo que son buenos desarrollando, que les gusta y que eso es a lo que se dedican y es lo que le transmiten a sus clientes; lo cual despertó algún comentario en los asistentes, dada la comparación con lo que vivimos aquí en España. Aplicación de Pair Programming todo el tiempo, un ambiente laboral agradable, invitaciones a personas destacadas dentro del mundo de la programación para que interaccionen con la gente que trabaja en Hashrocket, etc etc. Fue agradable de escuchar y creo que sería increíble trabajar en esos ambientes (al lado de la playa ) y de con esas premisas. Aunque sin duda mi conclusión actual es que no estamos tan lejos de conseguirlo, y que la nueva cultura de empresas pequeñas haciendo software creada entorno a Rails, podría llevarnos a eso.

Por comentar, me queda por ver a fondo la charla de Emili Parreño sobre ActiveRecord, echarle un vistazo a Typus, probar EC2 de Amazon, hacerse con uno de los aparatos que vimos en: Hardware Hacking en Ruby y casi en Rails para iluminar los deploys y definitivamente: hacer TAFT .

Pues bien, he de anunciar que el Internship se ha dado por clausurado y el resultado no ha sido nada alentador.

La verdad es que se juntaron varias cosas, como ya apuntan en el blog de Linking. Una vez más se ha evidenciado la importancia de la dedicación total, es difícil que un proyecto propio o sideproject se convierta en una realidad cuando el tiempo empleado para ello es muy limitado.

Creo sinceramente que el momento en el tiempo no fue el mejor (verano); que se junto con el comienzo de nuestra nueva actividad; que quizás es bastante cierto que faltó algo de presión por tener un entregable; que nuestra dedicación no era completa y se juntó con otras actividades que colapsaron nuestro día a día; y quizás otros factores que no soy capaz de ver en este momento. Todo esto suena a excusas explicatorias, pero nada más lejos; lo importante es el análisis de lo ocurrido y sacar conclusiones, para aprender de la experiencia.

Para mi es un trago amargo pensar en el resultado, no se puede decir que de la experiencia no haya sacado nada, pues no estaría diciendo la verdad. Sin embargo he querido concluir totalmente con ello y en principio dado que no podía comprometerme una vez más y mentirme a mi mismo y a mis compañeros sobre el tiempo real que podría dedicar, he decicido no continuar activamente con el proyecto. No descarto volver a hacer más cosas en el proyecto, pero a día de hoy no tengo la certeza suficiente de cuánto puedo dedicarme a él.

Por mi parte pude asistir a todas las charlas que se dieron los dos días, pero no pude quedarme a los talleres, otra vez será. La verdad es que se habló de todo: Cherokee, Software Quality Assurance, JCR, Struts 2, Grails, RIA, Netbeans Rich Client Platform, Maven, JavaME, y un largo etcétera.

Me gustaría hablar de todas ellas, cada una a su modo me aportó algo interesante, las experiencias vertidas, los problemas con los que se habían topado. Sin embargo mi memoria y las que más se me quedaron grabadas, por determinados temas fueron dos charlas: Software Quality Assurance, impartida por Francisco Morero Peyrona y Desarrollo JavaME SIN necesidad de portabilidad, impartida por Curro Rueda.

Por su parte Peyrona logró hacerme recordar mi último proyecto, a cada cosa que Peyrona contaba, me acordaba de una situación distinta, de una fase. Como comentaba, la responsabilidad de que se pueda garantizar calidad en cada una de las partes, recae en cuánta calidad queremos dar a cada fase más que en sí realmente podemos dar dicha calidad. Una conclusión extraida allí mismo, hablando la voz de la experiencia:

Dime cuánto quieres gastar y te diré cuantas garantías de calidad tendrá tu software.

Por otro lado Curro me hizo recordar una época anterior, en la que trabajé con móviles, y pude realizar algunas cosillas, y digo bien, cosillas, porque oirle hablar de los problemas que se habían encontrado, oirle decir que el orden en la ejecución de determinadas funciones afectaba a que determinados terminales funcionen y otros no, el ver como resolvieron el problema de los tamaños de las fuentes, cómo ahorrar en cantidad de espacio en memoria, y un largo etcétera. Sin duda me hace recordar que yo hice cosillas, y ellos han realizado un trabajo impresionante para garantizar que con un sólo jar, puedas tener una aplicación corriendo en una gran cantidad de dispositivos, al margen del:

Java Write Once, Run Anywhere.

… y de la cruda realidad.

Una espinita que se me quedó clavada fue oir en la mesa redonda sobre frameworks web algunas cosas sobre Ruby on Rails, que ya han sido suficientemente desmitificadas y demostradas, o algunas otras que carecen de fundamento.

Por otro lado, destacar que como suele pasar en estos casos, hubo oportunidad de saludar a los amigos y de hacer nuevos conocidos, al igual que de cenar con algunos de ellos , un saludo a todos ellos y nos vemos en la próxima!

Durante dos días tendremos la oportunidad de escuchar y también de interactuar con los talleres organizados a tal efecto.
Algunos de ellos para conocer: OpenCms, Trails, Spring, OpenXava, Glassfish o ItsNat.

Es un encuentro organizado conjuntamente por Sun MicroSystems y javaHispano (asociación sin ánimo de lucro), tal como ellos lo describen: “un evento sobre tecnología Java creado por la comunidad y para la comunidad”.

Yo por mi parte estaré por allí, para escuchar algunas charlas, asistir a alguno de los talleres y cómo no, para intercambiar opiniones con algunos de los asistentes, conocidos y no conocidos. Ya sabéis, si nos vemos por allí no dudéis en saludar, aunque no nos hayamos visto en persona, será un placer conoceros. Nos vemos por allí!!

Sin embargo aunque las evidencias son claras, y algunas empresas gastan enormes cantidades de dinero en que esto ocurra, no siempre se dan cuenta que existen puntos que a menudo olvidan. Pero no lo digo yo, lo dice Gordon Bethune, Chief Executive de Continental Airlines, alguien que opina algo clarividente:

“There isn’t any customer satisfaction without employee satisfaction [...]“

Evidentemente, el trato que trasmites a tus empleados llega de formas muy dispares a tus clientes, de tal forma que se cierra una cadena que podría hacer fuerte la relación de la que hablamos.

¿Evidente? Entonces, por qué no solemos preocuparnos por nuestros empleados; porqué seguimos contabilizándolos como números y no como lo que son: personas; por qué no pensamos que son la cara con la que nos presentamos a nuestros clientes.

Hay algo que no hay que olvidar, los equipos los forman personas, con sus vidas, sus problemas, sus ideas… Gestiona y dirige equipos de personas y tendrás proyectos de los que estar orgullosos en su plenitud. O mejor:

“You have to treat your employees like customers”

Y tendras clientes fieles y empleados con ganas de trabajar.

(Via 37signals)

Hay muchos tipos de decisiones: lógicas, triviales, drásticas, trágicas, etc. Y hay algunas, maravillosas decisiones que se convierten en una aventura

Definición de Aventura:
(Del lat. adventūra, t. f. del part. fut. act. de advenīre, llegar, suceder).
1. f. Acaecimiento, suceso o lance extraño.
2. f. Casualidad, contingencia.
3. f. Empresa de resultado incierto o que presenta riesgos. Embarcarse en aventuras.
4. f. Relación amorosa ocasional.
via RAE

Yo quisiera quedarme con la 3ª definición, ciertamente, lo que hace que una aventura sea excitante, digna de contarse es el riesgo, la certeza de la incertidumbre parcial o absoluta de los acontecimientos, el libre albedrío…

En estos momentos, disfruto del día primero de mi aventura, estoy en las fases iniciales, intentando adaptarme al nuevo estado, disfrutando de estos primeros momentos extraños de lo nuevo. Mi decisión fue tomada hace cosa de tres semanas, aunque si bien es cierto que la semilla llevaba mucho tiempo en el interior y ha decidido germinar en este momento. No voy a entrar en los detalles de la decisión, porque como es de esperar, no deben ser comprendidos por todos, sólo por ti y quizás, sólo quizás, por unos pocos.

Desde esta mañana puedo decir que he emprendido mi propio vuelo, que he adoptado la posición de hacer algo y no permanecer sentado día tras día. Desde hoy emprendo mi propia andadura como Freelance, muchas opciones, un largo camino, incertidumbre… y ganas por emprender, ganas por iniciar mi propio camino.

Hay proyectos que llevan esperando demasiado tiempo para ser terminados, ideas que se congelaron por falta de dedicación, y ganas, sobre todo las ganas de luchar por llevarlas a cabo, por tropezar y volverme a levantar. Ganas por ver como alguna logra hacerse realidad y disfrutar con ello.

La verdad es que no puedo desvelar nada aún sobre lo que tenemos preparado, es demasiado pronto para ello, pero sí os puedo decir que a partir de ahora estoy aquí, más que nunca para disfrutar. Abierto para tratar ideas, para colaborar en el desarrollo de ellas e incluso como no, para aportar nuestra visión al respecto.

La plataforma está basada en la tecnología OSGi de forma interna, además de permitir su uso al usuario final. Comenta la participación de SpringSource en orientar más a OSGi al sector empresarial. También han estado trabajando de forma intensa en la nueva versión de Spring la 2.5.

El porqué su Application Platform, no implementa Java EE 5 según sus propias palabras:

[...]does not satisfy the needs of our customers[...]

También es cierto que nos habla de incompatibilidades entre OSGi y Java EE. Creen que el JSR-277 y OSGi podrían convivir de una mejor manera.

Con OSGi tendremos una mejor, más eficiente y rápida manera de desplegar/testear y de redesplegar nuestras aplicaciones. Pudiendo desplegar sólo las partes que hayan cambiado. Podremos empaquetar en grupos y versionar esos paquetes (bundles). Tendremos más modularidad y un sistema de versiones encargado de todo ello, manejado por el servidor. Dando al usuario un mayor control sobre la división de la aplicación. Podremos hacer uso de dos versiones distintas de una librería, especificando al servidor la versión que queremos utilizar. OSGi y la forma de trabajar con bundles, permitirá una forma más rápida de parchear posibles fallos en su servidor.

La licencia es GPLv3, por lo que la gente podrá crear plugins para la infraestructura, y liberarlos como open source.

La explicación a ser Platform y no server:

We didn’t want to call it a server because it will be able to be extended and accept different deployment modules, so it will be broader in scope than a typical server.

Algo que nos facilitará la vida de cara al desarrollo, es SpringSource Tool Suite. Podremos declarar módulos OSGi, pudiendo desplegar sólo las partes que han cambiado. Aunque esto estará disponible para sus clientes, proveeran alguna herramienta adicional para open source.

La conclusión del para qué y el porqué ahora, viene dada al final de la entrevista. Concluyendo:
- Es el momento correcto, el mercado y los analistas lo confirman.
- La idea de los servidores tradicionales es demasiado anticuada y OSGi plantea grandes beneficios junto con Spring.
- Y por los beneficios reales: inicios rápidos, da solución al versionado, manejo de librerías y dependencias y cree que:

the product is introduced in the right place at the right time.

Sin duda el precedente debería de ser: No discutas enfrentando tecnologías tipo: PHP vs Java, .Net vs Java, Ruby vs Java. Al final seguramente estarás enardecido, encolerizado y no habrá valido la pena. ¿Por qué? Porque esto se convierte en una conversación religiosa a poco que empieza. Parto de la base con respecto a esto de que no quiero enfrentarlas, ese no es el fin.

Lo que yo destaco en Rails es la simpleza, y la forma en la que las cosas sencillas, continúan siendo sencillas y las cosas complejas en ocasiones se reduce su complejidad por el tratamiento que rails hace.

Bien, para iniciar una conversación de este tipo es conveniente estar preparado. Algunas de estas razones son obviedades. Aunque, han salido otras como la escalabilidad del sistema que son algo más peliaguadas, y que tienen pinta de seguir el camino trazado por Java es lento de antaño.

Yo no les voy a dar una lista de empresas grandes que utilizan rails. Ni les voy a dar un listado de portales con una carga o complejidad suficiente para pensar que Rails funciona, lo siento, para mi eso es evidente y/o trivial y… no necesita de ser demostrado.

Ni tampoco les voy a enseñar una razón de peso para que la imagen se grabe mejor que las palabras, intentando traer algo de humor al post.

Ni les voy a listar algunas de las que podrían ser, razones de ruby como lenguaje o las de Rails como framework.

Ni voy a utilizar el término enterprise de forma despectivo, para promover Rails.

¿Entonces a qué voy a dedicar este post?

Pues a estos hechos, sin duda, no. Ahí están para el que los quiera ver. Además eso ya lo han hecho los demás y yo no aportaría nada.

Yo, sólo les voy a recomendar una tontería, algo simple. Si pénsais por un momento cuánto cuesta realizar determinadas tareas en los desarrollos web, si hacéis un determinado repaso sencillo y rápido de determinadas tareas. Una vez ahí lo normal sería recomendar un tutorial de iniciación a Rails, algo rápido. Con la intención de probar, pero yo os considero ábidos con los lenguajes POO y con ganas de ver algo de la verdad sobre la cuestión, así que pasaré de esto y os doy mi granito de arena.

Leer un par de capítulos de un libro tal como: Agile Web Development; algo simple, con poco esfuerzo y luego ustedes dirán que les parece. Ambos son:

Capítulo 14. Active Records Basics.
Capítulo 15. More Active Records.

Si habéis desarrollado en web con Servlets, JSP, Struts, JSF, Hibernate, Spring y un largo etc. Si tras haber hecho eso no véis cierta magia en esos capítulos, si no sentís ganas de investigar y descubrir que son las migrations, que hacen los gems, rake, capistrano, etc. No vayamos a más, dejémoslo; sin más.

Para mi es evidente la razón que ofrece Martín; y creo que su actuación como médico de cabecera es una buena decisión y consejo. Al margen de las recomendaciones de Martín y del post, yo me quedo con:

Actualmente estamos en el proceso de implementación…

Espero y deseo que realmente estén en esta fase y estén realizando pruebas de carga y de estress en fases de desarrollo y sea ahí donde están viendo que tienen un problema. Es cierto lo que comenta Martín, es bueno contar con un arquitecto o experto en la materia y aunque no sea durante todo el proceso de desarrollo sino más bien de forma puntual, haya alguien que se encarge de aportar ese conocimiento al desarrollo.

Es importante que durante las fases de diseño se hayan estudiado los requerimientos y desde la fase 0 se haya tenido en cuenta que la aplicación debía soportar este nivel de acceso y ese número de usuarios concurrentes. Importante es el diseño de la aplicación para tener posibilidades de escalabilidad e importante que desde el momento en el que hay algo funcional se empiecen a pensar en las pruebas de carga y en como vamos a comprobar que lo que estamos haciendo realmente soporta nuestros requerimientos iniciales.

Pero hay más. Más importante que tener a alquien con la experiencia suficiente y con el tiempo suficiente, es dejarle hacer su trabajo y hacer caso de sus recomendaciones, ¿trivial? Pues sí, pero a veces cuesta un poco.

Por ejemplo, si desde el principio nuestra arquitectura no iba orientada a cluster, que es una de las posibles soluciones que planteaba Martín, es bastante problable que si no se tuvo en cuenta en los diseños, haya que cambiar parte del desarrollo, porque nuestro sistema no soporte cluster. O si se plantea como solución tener un balanceador de carga, pues resulta que nuestro sistema de sesiones hay que volverlo a diseñar. O resulta que tenemos un máquina impresionante como parece por los datos, pero nuestro diseño de base de datos es malo, no está optimizado y realizamos peticiones un tanto innecesarias y que sobrecarga en sistema y se convierte en el cuello de botella.

Lo obvio de esto es que a nadie se le ocurriría poner un sistema como este en producción, dado que ya es evidente que tienen un problema. Y lo obvio de esto es que se van a necesitar de un tiempo determinado para que el sistema aguante tal cantidad de carga. Lo curioso es que sistemas peores y más inestables llegan a producción y se viven situaciones verdaderamente dramáticas, aunque técnicamente ya hubiese saltado la alarma y se hubiese puesto en entredicho continuar con una determinada tecnología, un determinado planteamiento de diseño e inclusive un posible pase a producción. Pero el que sea obvio no implica que se quiera ver.

Desde el primer día he sufrido problemas con la conexión a internet. Digamos que los síntomas han sido claros. La conexión a internet a través de mi router empezaba de un modo bastante bueno, y poco a poco se iba empobreciendo hasta llegar a desaparecer totalmente. El modo de reproducirlo era bastante sencillo; bastaba con abrir una web tras otra hasta abrir las suficientes como para que la conexión se hubiese ralentizado, a partir de ese momento no se podía navegar más, ni tan sólo un ping respondía.

Haciendo pruebas conseguí encontrar una solución, para ello basta con cambiar la ip de la tarjeta, y de nuevo el sistema se convertía en usable. Lo malo es que poco tiempo después se repetía. Buscando en internet descubrí numerosas webs y comentarios en los que se hablaba de problemas con la pila TCP/IP, un nivel de paquetes alto hacía que hubiese desbordamiento de la misma y bloqueo de la tarjeta de red, todo esto había empezado a suceder con Leopard; en versiones anteriores no ocurría. Sinceramente la explicación parecía adecuada al comportamiento de lo que ocurría con mi conexión, sin embargo un error tan grave no parece claro que haya sido mantenido tanto tiempo sin una solución.

Algunos de los post que he leido son de diciembre, por lo que me parece que ha pasado suficiente tiempo, si un problema tan grave ocurriese.

Hablando con conocidos, viendo de que podría ser el problema de red, planteamos que el router que tenía no era demasiado bueno, y que podía estar causando el problema. El caso es que en mi red anterior formada con PC con Windows XP y Ubuntu, nunca había habido problemas. Aunque sí es verdad que el activar el Wifi sí había traido algún comportamiento extraño. Así que empezamos a sospechar o bien un mal funcionamiento del router o bien determinadas incompatibilidades entre router y Leopard.

Al final tras haber aislado el error, y ser capaz de reproducirlo, cambié el router y probé con un modelo con más garantías que el Amper Xavi 7768r, un Linksys WR200G, un modelo más abanzado y moderno que el mio. Tras unos días de pruebas, conseguí superar el test: internet rulez! Y por fin puedo disgrutar de mi conexión y del wifi XD.