jenaiz.com

Hace pocos días SpringSource liberaba la beta de SpringSource Application Platform. La verdad es que medios como: Infoq, javahispano, yahoo, theserverside, etc, se han hecho eco de la noticia. Hasta ahora no había querido comentar nada, dado que tenía ganas de descubrir algo más en profundidad sobre el mismo. En principio me parecía un nuevo server, sin embargo una entrevista realizada a Rod Johnson en dzone me ha descubierto que la idea de Platform se acerca más a ellos.



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.

Habiendo leido el post de Linked, de porqué ahora trabajan más con Rails que con Java, y leer que Martín también toca el tema, a su manera con Grails. No he querido dejar pasar que nosotros en el trabajo, también hemos tenido unas conversaciones interesantes sobre las bondades de Rails y por qué gusta trabajar con él (según yo) y por qué Java (según otros).

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.

En Pensamientos Ágiles despierto leyendo un post que en cierta manera me ha hecho recordar: Análisis de rendimiento y la necesidad de contratar especialistas.

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.

Usar Leopard durante los primeros días ha sido agotador tanto física como sicológicamente.

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.

La verdad es que he empleado bastante tiempo, pero al final ha merecido la pena. He estado mirando modelos, marcas distintas, leyendo comparativas y la conclusión, es que como todo, depende de la experiencia de cada uno; aunque sí que es verdad que hay portátiles y portátiles.

Mi decisión se fundamenta en varios conceptos. Necesitaba un portátil manejable y apto para viajar con él, con una buena calidad en la máquina, y debía suplir con creces mi pc de sobremesa; además de cumplir un mínimo de características técnicas. En este dilema entraron otros factores, no tenía ninguna intención de seguir utilizando Windows XP, tenía pocas ganas de empezar a utilizar Windows Vista. Por primera vez en años, directamente de casa mi dilema se iniciaba en: una distribución de linux o probar Leopard. Aquí las opciones se reducían, más cuando no quería pagar por licencias de Windows que no utilizaría. Quizás aquí habría que añadir mi cada vez más ganas de hacer cosas con Ruby on Rails y mis ganas, bueno ejem, terribles ganas de usar Apple.

Así que pensando con la cabeza sé que hice bien y si añado las ganas y el corazón sé que... acerte de pleno

Como es habitual he tomado algunas fotos de la escena al desempaquetar:





Y las primeras pantallas antes de usar Leopard.


Mis primeras impresiones son muy buenas, ya os iré contando. Las características técnicas:

Procesador Core 2 Duo de Intel a 2,2 GHz
1 GB de SDRAM DDR2
Disco duro Serial ATA de 160 GB a 5.400 rpm
más detalles

La verdad es que los rumores se han confirmado, What's "in the Air? era la frase con la que apple nos sorprendía ayer en la keynote que todos los años da Steve Jobs en la Macworld; la curiosidad estaba servida, y la maquinaria del marketing más puro en marcha.

La charla a las 9.00 hora local fue retransmitida por algunos medios, en formato nanoblog, actualizada cada pocos minutos, casi como si estuviésemos allí. Y tras un análisis del mercado de descargas, algún anuncio sobre el iPod, etc. Llegó el momento; el momento más esperado por muchos, el nuevo producto era anunciado. Un nuevo portátil the world's thinnest notebook. Las sospechas de muchos hasta este día se habían confirmado.

De forma precisa unos minutos antes de que Steve entrase en acción, tenían la web "caida", pero no con una OutOfMemoreyException, umm no! tenían un we'll be back soon. Y un mensaje más explicativo diciendo que estaban actualizando la tienda.

Un hecho que no se podía dejar escapar por el momento en el que se estaba produciendo, eso significaba para los ojos de muchos que estaba a punto de acontecerse un alumbramiento y efectivamente, así ha sido el Macbook Air, un nuevo modelo ultraligero.

Con unas características extravagantes como la ausencia de dvd o cd, con otras un tanto más extraordinarias:

Pantalla de 13,3 pulgadas (igual que el MacBook)
Grosor de 0.4-1.94 cm
Apenas 1,2 kilos (más o menos similar a otros ultraligeros)
Procesador Intel Core 2 Duo a 1.6 o 1.8 GHz
Disco duro de 80 GB o bien 64 GB de memoria SSD (disco duro de estado sólido)

Nota: un procesador, creado especialmente por Intel para este producto.
Todas las especificaciones en Apple

Lo alucinante es la sincronización, el espectáculo, el marketing y el marketing viral que se ha producido. Todo el mundo expectante por lo que podría suceder, así que al final tenemos lo que esperábamos.

De momento, lo que a mi me ha dolido más a sido la no actualización del Macbook normal, esperaba que lo ampliasen de alguna forma, memoria era raro, quizás HD, aunque tampoco era muy posible, pero quizás cpu o la gráfica, algún detalle curioso, pero bueno, seguiremos al tanto de la exposición que aún le quedan unos días y todo podría pasar.

Aps! Y ahora son Apple, Inc y no Apple Computer, Inc XD, se nota que apple amplia mercado y deja de ligarse única y exclusivamente a ordenadores (bueno, ya se "notaba" antes), quien sabe quizás algún día se meta en consolas y nos sorprenda aún más.

Una nueva versión de ruby ha sido liberada, en concreto la versión 1.9.0 y lo normal sería actualizarse a ella. Sin embargo en la lista de ruby preguntaron cuál era el propósito de dicha versión, y si se seguía el típico nombrado de versiones de los kernels de linux o si por el contrario era una versión superior que había que instalar por corregir bugs y por ofrecer nuevas características.

La respuesta viene de varias fuentes, pero la conclusión es la misma. La versión 1.9.0 no es estable, es una versión para desarrollo, no para entornos de producción. Se recomienda hacer compatible tu código con ella, para que el paso a la nueva versión de producción sea menos traumático, pero no se recomienda hacer uso de ella en entornos de producción, sino esperar a la release que sí será lanzada para ello, la 2.0.

El cambio puede ser algo traumático, así que un listado de las características nuevas ha sido publicado en eigenclass; es aconsejable echarle un vistazo, pues vienen ejemplos de lo nuevo.

Si queréis leer opiniones al respecto, quizás la trazada por Dave Thomas en su blog os guste; os advierto que la conclusión es la misma.

He estado mirando con tranquilidad un post de Jonathan Weiss sobre seguridad, bueno más bien la presentación de que se pueden extraer algunos consejos para securizar una aplicación web desarrollada con RoR. Ya se sabe como son la presentaciones, que a veces pueden no ser suficientes, así que si te interesa, puedes ver el video que acompaña al post.

En la lista de ruby on rails ha sido poco comentado, supongo que la mayoría de gente los utiliza de forma regular; sin embargo, la presentación destaca una lista de cosas bastante interesantes para el uso cotidiano. Destaco algunas:

- Elimina las páginas por defecto de las aplicaciones: 404, 500, etc. y sustitúyelas por unas propias.
- Desactiva el header del servidor, para que no sea fácil averiguar qué estás corriendo.
- Él comenta que establezcas una configuración en el servidor de tal forma que los .svn no sean accesibles; yo iría más lejos, haz eso y además hazte un script para limpiar tu aplicación de estos direcctorios.
- Cuida tus cookies, te da algunos consejos.
- Elimina los formatos en las entradas por parte de usuario que no son necesarios y protege las partes en las que permites que se utilizen, utilizando diferentes sistemas.
- Protégete del sql injection, te da recomendaciones sencillas para ello.
- Algunos consejos sobre los plugins.

Por si tenéis más ganas de leer algunos consejos o cosillas interesantes os paso un blog, la verdad es que no se actualiza mucho, pero es probable que queráis leer algunos de sus antiguos post, podrían ayudaros.

¿Conocéis blogs o webs sobre seguridad en Ruby on Rails? No os importe decirlo, la verdad es que nunca vienen mal tenerlos a mano.

Imagina una historia:

Un día te levantas y te apetece tomar un café, decides ir a una cafetería cercana y pides un café, pagas por él y te dan agua manchada. No hay café, mejor, no vas a obtener café.

Otra más:

Andas sobrado, tienes tanto dinero que decides comprarte uno de los coches más caros del mundo y tras pagar, te enseñan el coche, que podría ser algo parecido a un coche o no

No son buenas historias, no son leyendas, más bien son ejemplos sencillos de lo que parece una realidad; pero lo peor es que existe un sector en el que las cosas se dan de esta manera y el sector sobrevive.

Sí, hablamos del sector tecnológico, sobrevive y se dan casos como el anterior, donde las empresas venden Porsche y obtiene triciclos las veces que los obtienen. La pregunta es ¿cómo sobrevive un sector con esta precariedad? ¿Por qué nadie hace nada aparente para remediarlo? Es extraño que un sector en el que el desastre es lo normal (un 80% frente a un 20% de éxito), se sigan haciendo las cosas de la misma forma.

¿Qué fue lo que se me perdió? ¿Qué no vi?

No cabe duda que el nuevo año siempre nos hace plantearnos algún que otro propósito, sin embargo leyendo una entrada de Daniel Latorre me ha dado por escribir lo que quería proponerme para ver a final de año, a cuánto he sido fiel.

De su lista los siguientes pueden aplicarse directamente:

Conocer un lenguaje cada año
Leer un libro técnico cada 3 meses
Leer también algún libro no técnico
Aprende/Mejora tu inglés

En mi caso, desearía potenciar el conocimiento de Ruby on Rails para realmente sentir que lo manejo. El reto de un libro técnico cada x tiempo es singular, la verdad es que tenía pensado leer más para así mejorar el inglés, y sin duda es un buen remedio ponerse una meta así. En mi caso proponerme una meta suele hacer que dé más de mi para lograrla.

Personalmente tengo otros propósitos que en parte también son grandes deseos para el nuevo año:

El side project. Tanto leer, tanto programar y tan poco creado hacen algunas veces que nos sintamos huérfanos de creaciones. Mi deseo sería dar rienda suelta a alguna idea y llevarla hasta el final. El año pasado vino cargado de grandes ideas que ninguna vio la luz, este año desearía que eso cambiará; trabajaremos en ello... ¡trabajamos en ello!

El Mac. Llevo años con ganas de uno de ellos, con ganas de trabajar intentasamente con su sistema operativo y ver qué de cierto tienen las cosas que de ellos se dicen, y este año realmente quiero probarlo. Ahorro para ello.

El eterno olvidado: mi Blog. La verdad es que todos los años me hago la misma promesa, pero luego me olvido. Me agradaría publicar más en el blog, contar más cosas, dar salida a más pensamientos y eliminar del estado drafts algunos post. Este año empiezo con las ganas de lograrlo.