La semana pasada asistí a una conferencia en la EPI de Gijón (la Escuela Politécnica de Gijón, de la Universidad de Oviedo), con este título: "Los retos de las enseñanzas de ingeniería hoy. Una propuesta de futuro". El ponente era D. Javier Uceda Antolín, que fue Rector de la Politécnica de Madrid.
Además de hablar largo y tendido sobre los campos emergentes a los que se puede aplicar la ingeniería: nanotecnología, bio-ingeniería, etc. (curiosamente no mencionó, ni de pasada, campos tan interesantes y tan de moda como "la nube" o campos tan "sci-fi de toda la vida" como la inteligencia artificial ... será porque como ahora la informática no #EsIngeniería...) dejó caer dos ideas que me parecen muy interesantes y dignas de mención.
Siendo sinceros, me parecen muy interesantes y muy dignas de mención, porque llevo un montón de tiempo dando la matraca con ellas a quien me quiere escuchar y me llena el ego que alguna personalidad importante me de la razón ...
La primera de ellas es que, cito palabras textuales: "es fundamental la participación de los profesionales en la enseñanza universitaria. Nadie se fiaría de un profesor de una escuela de aviación que no haya aterrizado nunca un avión de verdad, por muchas horas de simulador que tenga".
Pregunta: ¿Puede un profesor que nunca haya participado en un proyecto ágil enseñar Scrum?
Respuesta optimista: Si, lo importante es dominar la teoría para que cada uno la pueda aplicar en su carrera profesional.
¡Pero si la teoría de Scrum es un folio por las dos caras (como mucho)! La complicación de verdad, está en saber esos trucos que da la experiencia, las trampas del día a día ...
Este negocio tiene una cosa que, como decía Homer Simpson, es como la cerveza: causa y solución de todos nuestros males. Y es que solamente hay una variable: el conocimiento (que está en las personas). No hay una materia prima "de pata negra" que podamos explotar, no hay maquinaria japonesa ultra-avanzada que podamos comprar, no hay atajos, no hay mas trucos que tener a los mejores para poder tener los mejores productos y dar los mejores servicios.
Y el problema, es que no hay nada que sustituya a esta máxima. Algunas consultoras creen que, con mucha publicidad y trajes caros, pueden distraer la atención del cliente y que no se de cuenta de que, en realidad, tienen personal mediocre. A la larga, por muchos botes de Egoist de Channel que echen, la cosa acaba cantando.
Lo mismo pasa con las enseñanzas universitarias regladas: al final, si apruebas, tienes un "título oficial". Lo del "titulo oficial" es una garantía buenísima de que el título que te van a dar al final de la carrera es eso, "oficial". Pero no garantiza que los conocimientos recibidos sean los mejores. De hecho, solamente se me ocurre una forma de garantizar eso: aprender de los mejores.
Hace unos meses, un conocido me pidió consejo sobre unos estudios de "Diseño y Programación de Videojuegos" que imparte una universidad privada. Lo primero que hice fue entrar en la web, navegar por las asignaturas y buscar los nombres de los profesores para ver su curriculum.
No los encontré... así que le dije a mi conocido que ni de coña se metiera ahí. El programa de la Universidad de Oviedo me pareció mucho mejor y ... que coño, el titulo no era "oficial".
Pero aún no siendolo, si los profesores de la privada fuesen auténticos gurús de los videojuegos ... lo hubiera recomendado con los ojos cerrados (después de todo, el "titulo oficial" hoy en día es papel mojado, porque informática ya no #EsIngeniería).
El libro "Founders At Work" es una recopilación de entrevistas a algunos de los emprendedores mas importantes del sector (entre ellos los fundadores o primeros empleados de Apple, Google, Yahoo, Hotmail, Blogger, Adobe, etc.). Las entrevistas están hechas de tal forma que, al final, cuando dejas el libro, sin darte cuenta, tienes una visión mas o menos global, desde un montón de puntos de vista diferente, de como se hacen negocios en Silicon Valley, como funcionan los fondos de capital-riesgo allí donde funcionan de verdad, etc.
Y una cosa muy curiosa es que, al principio, los gestores de fondos, miraban con lupa la idea, el plan de proyecto, los números...buscaban negocios que tuviesen visos de rentabilidad. Últimamente, en cambio, en lo que se fijan es en el equipo promotor. Les da igual la idea, les da igual el negocio, les dan igual los números...el papel lo aguanta todo. Los mejores siempre triunfan, si el negocio es una porquería, saben que pueden cambiarlo y adaptarlo. Las ideas van y vienen, pero un profesional de alta calidad cuesta mucho tiempo y esfuerzo conseguirlo.
La última moda en Silicon Valley parece que son los Rockstar Programmers: gurús que están tan valorados que tienen hasta representantes, como los actores de Hollywood.
Y eso nos lleva de nuevo a los retos de la enseñanza de la ingeniería, a la conferencia de la semana pasada y al segundo punto que decía este señor ex-rector:
El conocimiento está en internet al alcance de todo el mundo. Incluso mencionó las plataformas de cursos masivos en internet, tipo EdX o Coursera. Pero no llegó a hacerse la pregunta clave...
¿Que va a pasar cuando los RockStar Programmers empiecen a ofertar cursos? ¿Que va a pasar cuando la asignatura Ingeniería del Software en Coursera la imparta Erich Gamma o Ward Cunningham? ¿Que va a pasar cuando la asignatura de Sistemas Operativos la imparta Linus Torvalds? ¿Que va a pasar cuando la asignatura de Java la imparta James Gosling? Es como si Jimmi Hendrix (DEP) te enseñase a tocar la guitarra. Como aprender a conducir con Fernando Alonso. Como recibir clases particulares de golf de Tiger Woods!
¿Va a ser suficiente la promesa de un "titulo oficial" para competir con este modelo formativo? ¿alguna empresa con dos dedos de frente va a dar mas valor a un titulo, por muy oficial que sea, que a una formación recibida directamente de los mas grandes del negocio?
Y sobre todo: ¿Hay alguien en las universidades que se haya planteado todo esto esto? ... y encima de todo, la LSP!.
Monday, May 13, 2013
Tuesday, April 30, 2013
Gorm4Ebean
Hace un par de semanas hemos liberado nuestro primer proyecto bajo licencia de código abierto: Gorm4Ebean.
Se trata de una librería, muy sencilla, que permite utilizar el API EBean ORM de forma muy similar al API de Grails: GORM.
Personalmente, tengo la mala costumbre de desarrollar muchas (demasiadas) herramientas. Soy de los que se pasan mas tiempo afilando el hacha que cortando, pero es así, que le vamos a hacer. Me parece horrible retorcer una aplicación para encajarla con determinados componentes cuando se puede desarrollar una capa intermedia que abstraiga de toda la fontanería... debe ser deformación de cuando estuve con el Framework PA. Aunque ahora, "lo que mas se lleva" son los DSLs. Tenemos DSL para cualquier cosa: configuración del componente A, scripting, persistencia, configuración del componente B (otro DSL distinto del de A, porque como el dominio es distinto, pues lenguaje distinto...), etc. Algunos son interpretados, otros compilados. La verdad, demasiados... aunque con Groovy se hacen como churros.
Ahora con la crisis, cada vez estamos mas concienciados con el reciclaje y la productividad y zurcir los calcetines y hacer sopa con el cocido de ayer y todas estas cosas....y me he dado cuenta de la pila de herramientas y utilidades que hemos desarrollado durante años y nunca han visto la luz. La mayoría estaban demasiado acopladas a los proyectos (o directamente eran basura), pero otras no...otras se podían haber publicado o reciclado.
Pensándolo detenidamente, nuestro negocio no pasa por comercializar este tipo de herramientas (para el que tenga interés en saber a que nos dedicamos de verdad, nuestra web es www.nortia-in.es ) y la alternativa a publicarlas es dejarlas cogiendo polvo en un cajón.
En el caso de la librería Gorm4Ebean (que lleva un DSL incluido, faltaría mas) la verdad que fue una cosa fortuita: Aplicación Swing con Griffon ... Nos rompemos los cuernos para conseguir sacar GORM de Grails y utilizarlo en un entorno Swing, solamente para darnos cuenta de que la gestión de sesiones de Hibernate no es compatible (o mejor dicho, "duramente compatible") con el modelo de hilos de Swing.
Así que, buscando por internet (bendito StackOverflow) nos topamos con la librería eBean, que es una especie de Hibernate pero "sessionless". La verdad que no es muy conocida. Los proyectos conocidos que la usan son: Play! (un framework web que no conozco muy bien), el famosisimo juego indie Minecraft y ...luego ya debemos de ser nosotros los siguientes.
Pero bueno, funciona bastante bien! El problema es que con GORM tenemos una arquitectura basada en Domain Objects: ya sabes, con la lógica de negocio y los datos todos juntos y revueltos, métodos save(), list(), delete(), etc., nada anemico...
En cambio, eBean a priori parece que encaja mejor en una arquitectura de capas tradicional: VOs anémicos, capa de negocio, capa de DAOs, etc.
Entonces ¿que hacemos? ¿Tiramos todo y rehacemos la aplicación con la arquitectura de capas? ¿O hacemos algo con eBean para que encaje con todo el código que ya teníamos hecho?
Obviamente, hemos elegido la segunda opción y de ahí sale la librería gorm4ebean.
Se trata de una librería, muy sencilla, que permite utilizar el API EBean ORM de forma muy similar al API de Grails: GORM.
Personalmente, tengo la mala costumbre de desarrollar muchas (demasiadas) herramientas. Soy de los que se pasan mas tiempo afilando el hacha que cortando, pero es así, que le vamos a hacer. Me parece horrible retorcer una aplicación para encajarla con determinados componentes cuando se puede desarrollar una capa intermedia que abstraiga de toda la fontanería... debe ser deformación de cuando estuve con el Framework PA. Aunque ahora, "lo que mas se lleva" son los DSLs. Tenemos DSL para cualquier cosa: configuración del componente A, scripting, persistencia, configuración del componente B (otro DSL distinto del de A, porque como el dominio es distinto, pues lenguaje distinto...), etc. Algunos son interpretados, otros compilados. La verdad, demasiados... aunque con Groovy se hacen como churros.
Ahora con la crisis, cada vez estamos mas concienciados con el reciclaje y la productividad y zurcir los calcetines y hacer sopa con el cocido de ayer y todas estas cosas....y me he dado cuenta de la pila de herramientas y utilidades que hemos desarrollado durante años y nunca han visto la luz. La mayoría estaban demasiado acopladas a los proyectos (o directamente eran basura), pero otras no...otras se podían haber publicado o reciclado.
Pensándolo detenidamente, nuestro negocio no pasa por comercializar este tipo de herramientas (para el que tenga interés en saber a que nos dedicamos de verdad, nuestra web es www.nortia-in.es ) y la alternativa a publicarlas es dejarlas cogiendo polvo en un cajón.
En el caso de la librería Gorm4Ebean (que lleva un DSL incluido, faltaría mas) la verdad que fue una cosa fortuita: Aplicación Swing con Griffon ... Nos rompemos los cuernos para conseguir sacar GORM de Grails y utilizarlo en un entorno Swing, solamente para darnos cuenta de que la gestión de sesiones de Hibernate no es compatible (o mejor dicho, "duramente compatible") con el modelo de hilos de Swing.
Así que, buscando por internet (bendito StackOverflow) nos topamos con la librería eBean, que es una especie de Hibernate pero "sessionless". La verdad que no es muy conocida. Los proyectos conocidos que la usan son: Play! (un framework web que no conozco muy bien), el famosisimo juego indie Minecraft y ...luego ya debemos de ser nosotros los siguientes.
Pero bueno, funciona bastante bien! El problema es que con GORM tenemos una arquitectura basada en Domain Objects: ya sabes, con la lógica de negocio y los datos todos juntos y revueltos, métodos save(), list(), delete(), etc., nada anemico...
En cambio, eBean a priori parece que encaja mejor en una arquitectura de capas tradicional: VOs anémicos, capa de negocio, capa de DAOs, etc.
Entonces ¿que hacemos? ¿Tiramos todo y rehacemos la aplicación con la arquitectura de capas? ¿O hacemos algo con eBean para que encaje con todo el código que ya teníamos hecho?
Obviamente, hemos elegido la segunda opción y de ahí sale la librería gorm4ebean.
Monday, March 25, 2013
Arquitectura Efímera.
Tenía en mente empezar esta entrada haciendo referencia al disco de Fangoria que se llama igual que esta entrada: "Arquitectura Efímera". Referencia, ahora que lo pienso, un poco tonta que pensaba aprovechar para hacer un guiño a algunos colegas que seguramente serían los únicos a los que les podría hacer un poco de gracia.
El caso es que buscando por Google imágenes o vídeos para ilustrar la tontería, me he enterado de que existe de verdad una disciplina de la Arquitectura que se llama así: Arquitectura Efímera, y que se centra en el diseño de construcciones que no tienen propósito de perdurar en el tiempo. Por ejemplo: decorados, ferias, stands, etc.
Y ahora que ya tengo la entradilla destrozada, voy al grano ...
Acabo de terminar de leer el libro "97 cosas que todo programador debería saber", de la editorial O'Reilly. Es un libro que, como su propio título aventura, se divide en 97 capítulos, cada uno escrito por un gurú de la programación.
No obstante, se subtitula como: "Conocimiento colectivo de los expertos" (¿como lo viste?).
En realidad, se nota que a muchos de los expertos lo pilló la editorial "a salto de mata" y los comprometieron a traición para colaborar en el libro. Algunos expertos se vengaron malamente escribiendo cosas como "Algo mágico ocurre cuando testers y programadores trabajan juntos." (sic). O algún que otro capítulo que es una fumada en toda regla de principio a fin.
De todas formas, la mayoría son consejos muy útiles e interesantes para cualquier programador que quiera mejorar.
Uno de los consejos que mas me ha llamado la atención de todos; me ha llamado tanto la atención como para escribir una entrada en este blog que lleva tres años abandonado, es el que escribe Yuriy Zubareb, a la sazón, arquitecto en la consultora ThoughtWorks (donde trabajan gurús como Martin Fowler o Rebecca Parsons), en que habla justamente de lo efímero que es el código, o mejor dicho, que no es.
Bueno, en realidad su consejo no es ese. Su consejo es: "Escribe código como si fueras a mantenerlo el resto de tus días". Que, a la postre, termina siendo un alegato en pro de la mantenibilidad y la extensibilidad del código, ponerse en la piel de compañero que lo va a mantener, etc.
Al terminar su capítulo deja la siguiente frase (aviso, traducción mía que puede ser mas o menos chapucera):
En mi caso, haciendo memoria, creo que la mayoría de lo que he escrito en los últimos 9 años sigue rondando por ahí...aunque con los recortes y la crisis ya no estoy del todo seguro de que aún quede alguien por ahí, cagándose en todo al utilizar el FWPA.
Ah, y por cierto....
El caso es que buscando por Google imágenes o vídeos para ilustrar la tontería, me he enterado de que existe de verdad una disciplina de la Arquitectura que se llama así: Arquitectura Efímera, y que se centra en el diseño de construcciones que no tienen propósito de perdurar en el tiempo. Por ejemplo: decorados, ferias, stands, etc.
Y ahora que ya tengo la entradilla destrozada, voy al grano ...
Acabo de terminar de leer el libro "97 cosas que todo programador debería saber", de la editorial O'Reilly. Es un libro que, como su propio título aventura, se divide en 97 capítulos, cada uno escrito por un gurú de la programación.
No obstante, se subtitula como: "Conocimiento colectivo de los expertos" (¿como lo viste?).
En realidad, se nota que a muchos de los expertos lo pilló la editorial "a salto de mata" y los comprometieron a traición para colaborar en el libro. Algunos expertos se vengaron malamente escribiendo cosas como "Algo mágico ocurre cuando testers y programadores trabajan juntos." (sic). O algún que otro capítulo que es una fumada en toda regla de principio a fin.
De todas formas, la mayoría son consejos muy útiles e interesantes para cualquier programador que quiera mejorar.
Uno de los consejos que mas me ha llamado la atención de todos; me ha llamado tanto la atención como para escribir una entrada en este blog que lleva tres años abandonado, es el que escribe Yuriy Zubareb, a la sazón, arquitecto en la consultora ThoughtWorks (donde trabajan gurús como Martin Fowler o Rebecca Parsons), en que habla justamente de lo efímero que es el código, o mejor dicho, que no es.
Bueno, en realidad su consejo no es ese. Su consejo es: "Escribe código como si fueras a mantenerlo el resto de tus días". Que, a la postre, termina siendo un alegato en pro de la mantenibilidad y la extensibilidad del código, ponerse en la piel de compañero que lo va a mantener, etc.
Al terminar su capítulo deja la siguiente frase (aviso, traducción mía que puede ser mas o menos chapucera):
Si te paras a pensarlo, el código que escribiste hace muchos años sigue influyendo en tu carrera, quieras o no. Sin querer, vas dejando una rastro de tus conocimientos, actitud, tenacidad, profesionalidad, nivel de compromiso y grado de diversión (N. del T: degree of enjoyment, que no se traducir mejor.) en cada método, clase y módulo que has diseñado y escrito. La gente se formará opiniones sobre tí basándose en el código que vean. Si estas opiniones son negativas, sacarás menos rendimiento a tu carrera de lo que esperas.Puede parecer una obviedad pero estoy convencido de que muy poca gente que se dedica (o que nos dedicamos, me incluyo) a programar lo habíamos pensado así. No somos conscientes del rastro que estamos dejando detrás de nosotros. El software que construimos es menos efímero de lo que creemos en un principio y, si lo pensamos da hasta vértigo (al que lo tenga claro, que hay alguno que le da todo absolutamente igual. Eso sí, luego se quejan...)
En mi caso, haciendo memoria, creo que la mayoría de lo que he escrito en los últimos 9 años sigue rondando por ahí...aunque con los recortes y la crisis ya no estoy del todo seguro de que aún quede alguien por ahí, cagándose en todo al utilizar el FWPA.
Ah, y por cierto....
Tuesday, October 18, 2011
Classloader problem with diRMI and Grails
When trying to expose DiRMI services from a Grails-based web application, a fatal ClassNotFound exception may rise.
I have found the next caveat:
Extending DiRMI ClassResolver and Environment class.
And that's all folks! It works!
I have found the next caveat:
Extending DiRMI ClassResolver and Environment class.
class ClasspathResolver implements ClassResolver {
public Class resolveClass(String name)
throws ClassNotFoundException {
return Thread.currentThread().contextClassLoader.loadClass(name)
}
}
class GEnvironment extends Environment {
public Session newSession(ChannelBroker broker) throws IOException {
def session = super.newSession(broker)
session.classResolver = new ClasspathResolver()
return session
}
}
And that's all folks! It works!
Friday, November 5, 2010
Grails SortedSet composition ClassCastException
Grails domain objects stored in SortedSet (or related with others using a SortedSet) must implement Comparable. Otherwise a weird ClassCastException (with no Stacktrace at all) will be thrown
Monday, January 11, 2010
Peer Unverified Exception accessing secure web sites with HttpClient
When trying to access to secure web sites (https protocol) using apache HttpClient library, sometimes you can get the following error:
This exception occurs when page is sending a non trusted certificate. So, the solution to this exception is to import the certificate into your trusted certificates database.
Where "client" is the HttpClient instance.
javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:371)
at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:129)
at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:326)
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:129)
at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:164)
at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:119)
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:349)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:555)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:487)
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:465)
This exception occurs when page is sending a non trusted certificate. So, the solution to this exception is to import the certificate into your trusted certificates database.
- Step 1. Export web page authenticate.
- Step 2. Create truststore file.
keytool -import -v -trustcacerts -alias certAlias -keypass changeme -file thefile.cert -keystore truststore -storepass changeme
- Step 3. Copy "truststore" file to your project.
- Step 4. Add the following code (in Groovy):
def keyStore = java.security.KeyStore.getInstance( KeyStore.defaultType )
def store =getClass().getResourceAsStream( "/cert/truststore" )
keyStore.load( store, "thepassword".toCharArray() )
client.connectionManager.schemeRegistry.register(
new Scheme("https", new SSLSocketFactory(keyStore), 443) )
Where "client" is the HttpClient instance.
- IMPROTANT NOTE. "truststore" file mus be generated with JKS format. OpenJDK uses GKR format by default wich is not compatible. Sun JDK uses JKS format by default.
Friday, December 4, 2009
Stupid half an hour problem starting Griffon
When i was trying to launch any Griffon app I ever got a rare ClassNotFoundException with GriffonStarter class.
Half an hour later I realized that my griffon path was: /griffon-0.2. I changed it to /griffon and voilá: it works
Half an hour later I realized that my griffon path was: /griffon-0.2. I changed it to /griffon and voilá: it works
Subscribe to:
Posts (Atom)