Tras unos días de remanso, me gustaría contaros mis impresiones sobre el evento que la pasada semana se organizó en la Universidad Complutente, y al cual ya os comenté que asistiría.
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!
Pues muchas gracias por lo piropos: me siento muy alagado y me satisface saber que he podido ser de ayuda, aunque sea para recordar…
Creeme que no sólo me sirvió para recordar, la verdad, me sirvió para más
. Pero oir hablar de las garantías de calidad, me hace sino otras cosas sí afirmarme en que si quieres calidad tienes que estar dispuesto a pagar por ella, destinar recursos, conocer los límites hasta los que estás dispuesto, etc. Algo que tú muy bien comentabas; pero sobre todo y ante todo, tienes que *quererla*… mal vamos cuando no la queremos.
En dicho proyecto, no sólo por ser el último terminado, sino por otros motivos, hubiese encajado como un ejemplo perfecto para analizar.
Sólo lamento una cosa, no haberme acercado a saludar
.
Hola Jesús:
Yo también tengo pendiente escribir algunas notas sobre el OpenJavaDay pero he tenido que priorizar mis entradas (post) en el blog.
Tengo muchas ganas de escribir especialmente sobre SQA, porque me vengo dedicando a ella desde hace algún tiempo.
Peyrona dijo algunas verdades muy grandes y me gustaría tener oportunidad de charlar con él e intercambiar impresiones.
Un saludo
Yo os diria que en verdad me parecio el evento muy interesante, asisti como particular, aunque es bien conocido y tampoco escondo mi pertenencia a Sun.
Pero de verdad que el nivel me parecio muy alto, los ponentes muy capaces, y sobre todo un gran aplauso para la organización de un evento de dos dias por una comunidad “open” (sin animo de lucro, sin presupuesto, sin ……un largo etc). Y a los que comentan lo contrario o hacen críticas siempre que son constructivas adelante, pero sino les diría que se remangen ellos a ver si lo hacen mejor.
El año pasado fue un dia, este año dos. El nivel mucho más alto, los asistentes creo que también elevarón mucho el nivel, el primer año parecia que había mucho estudiante perdido.
En definitiva, al margen de las ponencias. ¡OLE! por el evento y en definitiva un ¡OLE! por la comunidad. El resto para gustos los colores.
“El resto para gustos los colores”
Efectivamente, es por esto que a cada uno nos gusta más una ponencia, un tema, una forma de exponer, la forma de presentar unas trasparencias, una determinada tecnología, un framework, etc. ¿Es por esto por lo que vas a desmerecer que alguien opine? Cada cual verá en las opiniones vertidas si les aporta algo o no. Cada uno tenemos unos intereses particulares, y desarrollamos nuestra labor en un campo distinto, por eso cada uno vemos más aporte en un tema u otro, sin embargo, también somos libres de hablar sobre el evento en general.
El hecho de que el evento me pareciese bastante bueno, es algo que ya he destacado, sin embargo siempre, por muy bien que lo hagamos hay cosas mejorables, de ello se aprende y se mejora.
Muchas gracias por los comentarios.
Hola Jesús.
Tengo curiosidad por saber en que no estás de acuerdo respecto a lo que se dijo sobre Ruby On Rails en la mesa redonda.
Yo creo recordar que mencioné que como no es tipado lo hace inapropiado para proyectos grandes (mucho código, muchas clases), y que acopla tabla-modelo-vista por defecto lo cual es bueno para desarrollo rápido pero que en seguida se convierte en un problema.
Me encantaría conocer otro punto de vista.
De todas formas hazte a la idea de que en un evento Java o JVM céntrico suelen correr collejas a RoR lo cual también ocurre en los eventos Ruby.
Saludos
Me hago cargo que en un evento java céntrico llueven collejas para todos los demás XD osea todo lo no-java.
Sin embargo hubiese estado bien un defensor de un framework como Rails, vistas las “copias” que de él están ocurriendo en el mundo java, no para defenderse de las collejas sino para que la comunidad java hubiese apreciado que puede aprender de un framework tan joven, porque de todo se puede sacar algo positivo.
Sobre lo que se oyó y no debió ser: se comentó que en ruby on rails no hay posibilidad de hacer test, algo que es totalmente infundado, véase el hecho de que con un simple: rails name-app, ya tenemos un directorio para test funcionales y de integración que podemos ejecutar e ir ampliando, o simplemente un vistazo a Rspec.
Lo de no ser tipado, lo he oido utilizar tanto en su contra como a su favor XD.
Y sobre el nombre por defecto de las tablas en base al modelo, bueno, creo recordar que se le achacó no soportar sistemas legacy (tablas con nombres particulares), lo cual es infundado.
En definitiva, “convention over configuration” tanto si nos gusta como sino, es algo que puede facilitarnos la vida, que Rails lo tiene y lo utiliza al máximo, y aunque se puede obviar hasta el extremo de definir nuestra propia convention, yo personalmente respetaría la que tiene o la modificaría para mis necesidades, pero no la eliminaría. ¿Que existen proyectos en los que esto es un problema? Seguro. No hay soluciones para todo, eso es evidente. También existen proyectos en los que los nombres de tabla son criptográficos.
Sin más, es otro framework web, con sus virtudes y sus defectos.
Por qué no decir que Grails no tiene migrations y que esto sí es un problema, por la usabilidad que introduce para gestionar un sistema de versiones en el modelo de datos? (Esto es algo que se comentó, y no pareció que a nadie le chocase
).
Por qué algunas veces nos montamos XML hiper extensos para definir una navegabilidad que no podemos conocer porque somos incapaces de seguir el flujo del fichero de configuración?
Para qué definir un get y un set en un Bean con propiedades públicas? De hecho, para qué definir dichas propiedades si mapean una tabla coincidente con el nombre del bean? Más aún, para que mantener propiedades en una tabla, mantener propiedades en un bean y….
Y no creas que defiendo Rails, defiendo su uso cuando corresponda, al igual que defiendo el uso de struts o de strust 2 o de seam o de ItsNat o de Loom … cuando corresponda y siempre que me ayude al desarrollo. Y destacaré cada cosa útil que tenga un framework, por encima de arremeter contra él sin más.
Yo creo recordar que mencioné que como no es tipado lo hace inapropiado para proyectos grandes (mucho código, muchas clases), y que acopla tabla-modelo-vista por defecto lo cual es bueno para desarrollo rápido pero que en seguida se convierte en un problema.
Jose María, Me da un tanto pena que una persona como tú, que me consta es muy inteligente, diga algo así en público y se quede tan pancho. Lo primero por ser algo taaaaan subjetivo, y lo segundo por ser “no verdad”.
Sobre lo segundo… ya te ha comentado Jesús que no es así, pero no se me ocurre en que momento puede ser un problema que algo sea más fácil (me pregunto porque se está haciendo también en Java en ese caso). Si el 90% de las veces me lo hace más sencillo y el 10% restante puedo cambiarlo, me pregunto que será lo que lo hace tan malo. No sé, torpeza mia que no lo veo, supongo.
Sobre si un lenguaje no-tipado es malo para proyectos grandes. Detecto que antepones las tecnologías a las personas (seguramente lo entiendo mal), porque yo he visto “obras de arte” y “autenticos infiernos” en ambos casos, tipados y no tipados. Son las personas, no las herramientas. Pero no sé, me gustaría saber si a la gente de Amazon, ebay, Google (bueno, google tiene de todo, pero ganan los no-tipados), les han dicho que sus lenguajes principales no son apropiados. Aunque supongo que te refieres a los proyectos serios de verdad, los bancos y compañia, dónde estoy de acuerdo en que se usa mucho más Java. Pero de nuevo ahí dudo que una persona inteligente como tú se crea que es porque razones técnicas en lugar de puramente comerciales de las empresas que tratan con los bancos. Me pregunto que habría pasado si cuando lo anunció hace años, IBM hubiera empezado a ofrecer servicios sobre PHP.
En fin, lo dejo, que no es momento. Un saludo José María.
Al: “Jose María, Me da un tanto pena que una persona como tú, que me consta es muy inteligente, diga algo así en público y se quede tan pancho. Lo primero por ser algo taaaaan subjetivo, y lo segundo por ser “no verdad”.”
Alberto, la verdad es que me he quedado bastante alucinado por el tono de tu comentario, llevarlo al terreno personal y utilizar la clásica técnica de argumentar en plan “si no piensas como yo que tengo la verdad absoluta es que eres una mierda” me parece terrible. Prefiero considerarme un imbécil y tener el derecho a opinar y a equivocarme.
El acoplamiento por defecto tabla-modelo-vista es de toda la vida una práctica pésima, no es algo que diga yo, ese acoplamiento lo he oido defender un día sí y otro también en el mundo Ruby sin pudor alguno. Pero yo nunca he dicho que no se pueda desacoplar.
Respecto al tema del tipado prefiero que responda Dmitry Jemerov de IntelliJ:
http://www.artima.com/lejava/articles/javaone_2008_dmitry_jemerov.html
“Honestly, I don’t know any language today that would become the next big thing. Groovy is interesting, but it’s a dynamic language and has all the problems of dynamic languages. It’s OK for small pieces of code. But building something the size of IntelliJ IDEA [in a dynamic language] would be a complete nightmare.
A dynamic language works great when you have a clearly-defined structure of an application, where you know where everything lives, where everything is, and what everything is around you. For example, with a Rails application, you have a very strict structure: You have controllers and views and models, and so on. It’s all very uniform. You can easily jump into any place of the application and understand what’s around you: Here comes the model, and here’s the data from the Web request, and so on. That’s easy to figure out.
With a product like IntelliJ, there is no such uniform structure. It’s very big and very diverse. In my day job, I have to make changes in many places of the code. Static types are the only thing that lets me jump into any place in the code base and understand what everything is around me. I need to know what things are, what I can do with various things around the code that I need to change. With static types, I see that immediately. With a dynamically-typed language, I would need to spend half an hour investigating what goes where and what is what before being able to make a single change. “
Jose María, lo cierto es que el único tono de mi comentario es de cierta incredulidad porque te considero una persona inteligente. Si eso lo consideras un ataque personal no se que decirte. Mis disculpas personales y sinceras por haber hecho que te sientas ofendido. Pero lo malo de hablar en público es que precisamente no todo el mundo tiene la misma opinión.
No pienso ni lo contrario ni lo mismo que tú. Lo único que defiendo es que con muchas tecnologías se pueden llegar a un fin satisfactorio, y nadie tiene la verdad absoluta, ni siquiera Dmitry Jemerov. No sé, que quieres que te diga respecto a eso, pero me llama la atención que dice…. “In my day job”, lo que se podría decir que es SU día, y no sé, no creo que todos hagamos entornos de desarrollo, y también me creo que algunos hacen cosas más grandes y otros más pequeñas, ¿no crees?. ¿No crees que deducir de una frase así que un lenguaje tipado no vale para un proyecto grande es un poco exagerado?. Me vuelvo a preguntar… ¿qué es más grande?, ¿Amazon o Intellij?. No sé, no me voy a molestar en poner citas, creo que ha quedado claro mi punto.
Sobre si el acoplamiento tabla-modelo-vista es una mala práctica… no puedo evitar pensar en Gavin King proponiendo patrones. Me pregunto porque lo seguirá entonces tanta gente en distintos lenguajes y a distintos niveles. Me sale el chiste de las moscas, pero como ni me gusta el chiste, ni creo que seamos todos tan tontos… pues no sé. Será que yo todo lo que he hecho y sigo haciendo es minúsculo y por eso soy tan tonto que me gusta.
En fin, sinceramente, seguramente me equivoco y te vuelvo a pedir disculpas, pero si que me parece que tus comentarios parecen de un poseedor de la verdad absoluta. De argumentos has andado esta vez justito. Antes de que me digas que yo tampoco los he dado…. me gustaría que pensaras que frase debo argumentar, porque creo (seguramente en esto también me equivoco) que sólo he planteado dudas sobre las dos situaciones (porque si nos ayuda es malo el acomplamiento, y como siendo tan malos hay proyectos grandes en lenguajes no tipados). Ok, vale, he dicho que los bancos compran lo que las empresas les venden y que normalmente los desastres y los éxitos los consiguen las personas, eso si que debería argumentarlo supongo, ¿o no?.
No te calientes en exceso José María, que ni merece la pena ni es para tanto.
Hola Jesús,
Mi comentario es un simple apunte y es que el tema de migations en Grails está en camino o al menos eso dicen. Ahora, de aquí que llegue pues ya veremos cuanto tiempo pasa
. Se comenta que lo quieren hacer con LiquiBase (que nunca he probado).
Un saludo!
Qué casualidad! Hoy estaba mirando el tema de las migrations en Grails, porque me parecía extraño que ni tan siquiera existiese alguna implementación al margen del core oficial.
He visto que había algo así como un plugin, y dbmigrate, que ya lo conocía de antes y no es lo que buscaba exactamente. Supongo que están “trabajando en ello”.
La verdad es que cuando trabajas con ellas, piensas: cómo algo tan sencillo puede falitarme tanto la vida.