Recortando el currículum y el primer empleo

    Publicado el Sunday 29 de August de 2010. | 5 comentarios
    Categoría: Yo, programador | Tags:

    Homer una vez tuvo que leer un currículum que tenía cuatro páginas.

    De vez en cuando, como casi todo el mundo, me gusta actualizar el currículum y añadir lo último en lo que he estado trabajando o lo nuevo que he aprendido. Según dicen algunas normas no escritas, lo suyo es que el currículum no pase de dos páginas, o directamente nadie lo leerá. Así que, si durante toda nuestra vida laboral no hacemos más que añadir y añadir cosas, llega un momento en el que, después de doce años trabajando, tu currículum puede llegar a ser aburridamente largo. Y hay que meter tijera para reducirlo, por supuesto.

    Por donde empezar está claro: en tecnología, cuanto más antiguo es un trabajo, menos relevancia tiene hoy en día. Así que tu primer empleo, después de unas cuantas sesiones reductoras, pasa de ser una larga descripción, para convertirse, año tras año, en una simple frase que casi da hasta pena dejarla. Y en ese momento piensas ¿debería directamente eliminarlo? Pues no, yo no quiero quitar mi primer trabajo porque le tengo mucho cariño. Y es que, aunque nada de lo que usaba por aquel entonces se use ya ahora, aprendí a trabajar en una oficina, a tener un jefe, un horario y a que las vacaciones no duraban 4 meses, sino 22 días laborables. Y como me apetece hablar un poco ello, a modo de historia del abuelo cebolleta, hoy contaré como fue mi primer trabajo.

    Si, yo tuve uno de estos.

    Junio de 1998, era la época del rincón del vago, los móviles Nokia 5110 y la PlayStation, los monitores de 14″ con culo y los Pentium II con 128Mb, el inicio de la burbuja puntocom y la salida a bolsa de terra.es. Internet llevaba ya algunos años en España con cosas tan penosas como Infovia y no existía infojobs o jobsket para encontrar empleo, ni nada parecido. Así es que tuve que buscar mi primer trabajo como seguramente hicieron nuestros padres: mirando en el periódico (de papel, me refiero; en concreto el segundamano) y llamando por teléfono desde casa (casi nadie de mi edad teníamos móvil). Llevaba ya algunos años programando en Clipper por mi cuenta con libros en casa, así que probé suerte y llamé a la única oferta que había de “Programador Clipper”. Y como en el carné de conducir, que aprobé todo a la primera; al primer sitio que llamé, les gusté y me contrataron. Por aquel entonces había una gran demanda de programadores, pues había que adaptar todas las aplicaciones para evitar el efecto 2000 y también para que aceptaran la nueva moneda que se avecinaba, el euro.

    La empresa donde entré a trabajar se llamaba Teleinformática (que fue comprada por Azertia, que fue comprada por Soluziona, que fue comprada por Indra) y su principal cliente era el BBV (que todavía no se había fusionado con Argentaria).

    Me incorporé a un equipo de diez programadores que desarrollaban aplicaciones de banca electrónica. En aquellos tiempos los bancos no tenían páginas web tan buenas como ahora, así que tenían que crear aplicaciones para que sus clientes (generalmente empresas) pudieran enviar operaciones al banco (a través de un modem) para hacer transferencias, consultar movimientos y todas estas cosas que ahora hacemos desde internet a diario.

    La aplicación estrella se llamaba SIETE: una aplicación de escritorio desarrollada en Clipper y que corría sobre MS-DOS. Entonces Windows 95 era relativamente joven y, aunque ya había un departamento que creaba la misma aplicación para Windows en Delphi, se mantenían las dos versiones. Poco a poco el departamento de Windows creció y el de MS-DOS desapareció, pero eso es otra historia.

    Empecé a interesarme en Clipper en el 90, mis padres me compraron todos estos libros en el corte inglés (tuve una adolescencia muy dura). Ahora los guardo como un tesoro (que solo yo puedo apreciar, claro). Pincha en la foto para verla un poco más grande.

    Clipper era un lenguaje procedural, no orientado a objetos, con un sistema integrado muy cómodo para manejar base de datos, pues estaba basado en dBase III. No teníamos potentes IDEs como ahora, programábamos con editores prehistóricos como QEdit, Aurora y otros más que no recuerdo. Compilábamos con scripts en BAT que tardaban minutos en generar un ejecutable. Tampoco teníamos control de versiones, así que usábamos una carpeta compartida entre todos en un servidor remoto y avisábamos cuando alguien tenía que tocar algo para no pisarnos los fuentes.

    No había internet, ni correo electrónico, ni nada por el estilo, así que las tareas las definía tu jefe de proyecto, las estimaba con Microsoft Project, las imprimía y te las daba en un papel donde ibas tachando las que ibas haciendo. La única manera de “comunicación” era compartir carpetas y copiar archivos, y los disquetes de 3.5″ claro. Ni comparación con ahora, que no podemos trabajar sin internet o correo (ya sea corporativo o gmail/hotmail/etc), buscar documentación o ejemplos o tutoriales o lo que sea, vamos.

    QEdit

    Programando como machos con el QEdit. Era duro, pero peor era el Edit...

    Aurora

    Los profesionales usábamos Aurora, ¡con sintaxis coloreada!

    No había patrones, ni buenas prácticas ni metodologías ágiles. Te daban cientos de fuentes caóticos que habían sido tocados por decenas de personas antes. Y había que buscarse la vida. Al final, al cabo del tiempo, le cogías el truco, pero era bastante duro, pues te pasabas la mayor parte del tiempo intentando descifrar lo que había hecho el programador anterior. Por supuesto no existían las pruebas unitarias ni nada parecido, pero había algo que no fallaba: un departamento de control de calidad exclusivo para probar, que pasaban cientos de baterías de pruebas y hasta que no se pasaban todas, no se liberaba una versión. Así que al final, entre todos y con mucho esfuerzo, sacábamos el trabajo y conseguíamos hacer funcionar esa endemoniada aplicación que después correría en los PCs de cientos de clientes del BBV.

    Y así pase dos años y medio, primero con Clipper y luego con Delphi, hasta que a finales del año 2000 me empezó a picar la curiosidad por un lenguaje nuevo y que parecía bastante interesante porque se podían construir aplicaciones para internet: Java. Pero eso también es otra historia.

    Así es que cuando miro mi currículum y veo esa última frase en el apartado de experiencia que pone “1998-2000: Programador en Clipper de aplicaciones en banca electrónica”, algo dentro de mi me dice que ya ha sufrido suficientes recortes, y que no merece la pena borrar dos años de mi vida para ganar dos líneas de espacio. Así es que así se quedará, para siempre.

    ¿Y tú? ¿Cómo fue tu primer trabajo?

    Artículos relacionados: Al principio, todo era mágico

    Popularity: 1% [?]

    Mac OS: escribir en unidades NTFS

      Publicado el Monday 21 de June de 2010. | 1 comentario
      Categoría: Apple | Tags: , , ,

      El soporte de Mac OS para escritura en unidades NTFS viene desactivado por defecto. Este es un truco para habilitarlo que he probado satisfactoriamente en Snow Leopard.

      1. Renombrar el binario /sbin/mount_ntfs por /sbin/mount_ntfs.orig

        Desde un Terminal puedes utilizar este comando (te pedirá password de root)

        sudo mv /sbin/mount_ntfs /sbin/mount_ntfs.orig
        
      2. Crear un script llamado /sbin/mount_ntfs con el siguiente contenido (usa tu editor de texto favorito):
        #!/bin/sh
        /sbin/mount_ntfs.orig -o rw "$@"
        
      3. Dar permisos de ejecución al fichero que acabamos de crear. Puedes utilizar estos comandos desde el terminal (pedirá password de root)
        sudo chown root:wheel /sbin/mount_ntfs
        sudo chmod 755 /sbin/mount_ntfs
        

      No requiere reiniciar. Ahora ya puedes usar esa unidad USB en NTFS llena de música que también usas en el PC con Windows que tienes en casa escondido. :D El truco por supuesto no es mío, está sacado del foro de Mac Rumors.

      Popularity: 1% [?]

      Crónica de la GR8conf 2010 en Copenhague

        Publicado el Friday 28 de May de 2010. | 1 comentario
        Categoría: Programación y diseño, Yo, programador | Tags: , , , ,

        Los pasados 19 y 20 de Mayo tuve la oportunidad de asistir en representación de Paradigma Tecnológico, la empresa donde trabajo, a la GR8 European Conf en Copenhague, la versión europea de la GR8, una conferencia que trata exclusivamente sobre Groovy y otras tecnologías creadas con este lenguaje como Grails, Griffon y Gradle.

        El recinto de acogida fue la IT University, ahí pasamos todo el día, horas de la comida y cena incluidas. Pese a que la wifi no resistió todo el tráfico de los asistentes, en general diré que el sitio, la organización y la comida fueron bastante buenos. Además, al volcán islandés Eyjafjalla le debe gustar también Groovy, porque esa semana nos dio a todos los asistentes un respiro y se pudo volar con normalidad a la ciudad.

        Fueron solo dos días y muchas ponencias, así que los organizadores tuvieron que ingeniárselas para que diera tiempo a todo, dando como resultado una agenda bastante apretada: incluso a la hora de comer había una pequeña charla de 20 minutos sobre algún tema. Además, el primer día hubo Hackergarten night coding, así que los que no tuvimos suficiente con las charlas (o sea, todos), nos pudimos quedar hasta la hora que quisimos dentro del recinto para programar algún plugin (o lo que sea) con alguno de los líderes de Groovy, Grails, Gradle o Griffon. Más adelante comentaré la experiencia en el Hackergarten, pero en resumen diré que fue de lo más interesante, aunque agotador (acabámos a las once la noche).

        Pero lo mejor de la conferencia ha sido, sin duda, que el nivel técnico de todos los ponentes (y del público también, dadas las preguntas que se hacían durante las charlas) ha sido muy muy alto. Supongo que tener que viajar hasta Copenhague a una conferencia que trata sobre un tema tan especializado como el ecosistema Groovy, ha hecho que la proporción de expertos respecto a gente “normal” haya sido más acusada.

        Más información:

        Groovy on the way to success

        En esta primera ponencia, Philippe Delebarre y Raffaele Cigni, de la Oficina Europea de Patentes (EPO) nos cuentan su problemática situación actual y como la han solucionado. Su oficina gestiona actualmente más de 140.000 patentes al año, y su sistema informático es una gran aplicación host basada en Cobol muy antigua que se está quedando obsoleta: cada vez hay más patentes que tramitar y sus procesos son cada vez más lentos. Por dos veces han intentado migrar sus sistemas, pero sin éxito alguno. Primero un ET y después un ESB: las dos soluciones o eran muy caras, o muy difíciles de mantener, con grandes ficheros XML de configuración, etc.
        Su solución final ha consistido en la elaboración de un lenguaje propio de dominio (DSL) al que han bautizado como DFP (data flow process) con el que crean procesos. Es un lenguaje muy simple, intuitivo, fácil de usar y de mantener. A su alrededor, han creado todo una plataforma que es capaz de leer y procesar estos ficheros DFP, por lo que su trabajo de mantenimiento consiste en crear nuevos procesos o modificar los existentes, y desplegarlos en la plataforma que han diseñado, responsable de procesar todos sus DFP. Con esto han conseguido una forma barata de migrar su sistema aumentando la velocidad de procesamiento de las patentes: ahora están listas en varios días en vez de semanas (hay que tener en cuenta que una patente suelen requerir correcciones manuales, pero el sistema desarrollado contempla el rechazar alguna patente si le falta algún dato, etc).

        Esquema de la plataforma de procesamiento de patentes

        Mi conclusión tras ver la ponencia es que no solo de Grails viven las aplicaciones empresariales: Groovy es un excelente lenguaje de scripting que, junto con un DSL bien diseñado, puede agilizar la creación y mantenimiento de aplicaciones de procesamiento automatizado de datos.

        Quickie: Grails update

        En una breve exposición de apenas 20 minutos, Graeme Rocher nos cuenta el estado de Grails en la actualidad y nos cita algunos sitios importantes desarrollado con este framework como la tienda online Walmart, una aplicación 2.0 para la gestion de tareas llamada Manymoon, la página de la universidad Northwestern, y un buscador de ¡baños públicos! llamado Sitorsquat.com, entre otros. Como nota destacable, nos cuenta que se ha mejorado el soporte de Grails para Eclipse en el nuevo SpringSource Tool y nos adelanta su roadmap:

        Grails 1.2 ha mejorado considerablemente su rendimiento

        • Mejoras sustanciales en el rendimiento
        • Pluggable test framework: poder insertar nuevos framework de test como pluggins
        • Global constraints/mappings: constraints globales que afectan a todos los objetos de dominio
        • Soporte Gorm para NoSQL
        • Soporte para despliegue de aplicaciones cloud
        • Integración con Gemfire RabbitMQ

        Y para Grails 2 en septiembre con grandes cambios.

        • Mejorar la integración con aplicaciones ricas de escritorio (RIA)
        • Mejoras en el sistema de plugins (basado en Osgi), despliegue de plugins en caliente
        • Múltiples datasources (¡bien!)
        • Database migration e ingeniería inversa (creación de clases de dominio a partir del modelo de datos)
        • Arranque más rápido (supongo que por los problemas que tiene Grails al desplegarse sobre Google App Engine)

        En resumen, Graeme nos cuenta que Grails 2 va a ser muy diferente y que el cambio mayor de versión esta justificado. Esperamos ansiosos su salida, que estima entre septiembre y final de año (la verdad es que no recuerdo bien la fecha).

        Grails Internals – Demystifying the Magic

        Grame continúa después con una presentación bastante extensa (y que me es imposible resumir) sobre como funciona el arranque de Grails, los class loaders implicados, el BootStrap, etc. Acaba con la creación de una aplicación de ejemplo básico y la depuración, línea a línea, del código de Grails al recibir una petición http: para ello inserta un par (bueno, unos cuantos al final) de puntos de ruptura en clases clave del código, como GrailsWebRequestFIlter y UrlMappingsFilter, intentando explicar todos los pasos y procesos que toman parte de la petición. Muy interesante e instructivo.

        Graeme explicando la secuencia de una petición HTTP en Grails

        Gaelyk, a lightweight Groovy toolkit for Google App Engine

        Durante la comida, Guillaume Laforge, en unos breves 20 minutos, nos resume el funcionamiento de Gaelyk, un framework ligero para el desarrollo de aplicaciones Groovy para Google App Engine. Gaelyk no es más que un conjunto de clases que añaden dinámicamente a los Groovlets y Groovy Templates los atributos y métodos necesarios para acceder cómodamente a las APIs que nos ofrece Google para acceder a sus servicios de Xmpp, BigTable (memcache, blob y datastore), email, images, etc. La verdad es que esta presentación me pilló comiendo, así que no puedo contar más.

        Flying with Griffon

        La presentación de Andres Almiray, el creador de Griffon consiste primero en una introducción donde explica qué es y cómo funciona Griffon y después en el desarrollo, en directo, de una pequeña aplicación de ejemplo en Swing con Griffon.

        Griffon es un framework de desarrollo, muy parecido en concepto y arquitectura a Grails (de hecho, comparten código), para la elaboración de aplicaciones MVC con Swing, Groovy y Java. Al igual que Grails, posee un comando para la creación de proyectos, generación de clases, empaquetado de la aplicación e instalación de plugins. De la misma manera que lo hace Grails, el tener por separado controladores, modelos y vistas hace que el desarrollo sea mucho más cómodo y mejor estructurado. Sobre todo para la elaboración de las vistas, donde existe un DSL propio con el que generar todo el código Swing, pero sin tener que sufrir escribiéndolo. Además, podemos utilizar la anotación @Bindable en nuestros beans para que cualquier modificación en los atributos del modelo se transmitan directamente a las vistas y viceversa, sin tener que programar manualmente toda la gestión de estos eventos del patrón Obverser de Swing, con sus event listeners y demás parafernalia. Por supuesto, esto solo es posible gracias a Groovy sus transformaciones AST.

        Andres preparándose para dejar al público atónito...

        Esta presentación fue, para mí, una de las mejores, y ahora voy a explicar por qué: hace más de un año que uso Flex y Adobe Air en mi trabajo diario para hacer aplicaciones de escritorio. Y estoy muy contento, tanto por el lenguaje de desarrollo como por los resultados finales obtenidos. Swing siempre me ha parecido la parte más aspera de Java: aunque use un IDE para la elaboración de ventanas y componentes, la cantidad de código necesaria para construir una aplicación es simplemente desproporcionada, lo que hace que programar Swing acabe siendo una tarea poco agradable. Y esta ha sido la principal razón por la que, hace ya más de un año, cuando tuvimos que decidir qué tecnología usar para crear una aplicación de escritorio para un proyecto, nos hayamos decantado por Flex y Adobe Air en vez de Java y Swing, pese a ser Java el lenguaje con el que más cómodo nos encontramos (simplemente porque es el que más usamos a diario) y haber sido Flex/Adobe Air, en su momento, nuevos para nosotros.

        Este precedente me sirvió para apreciar más todo el trabajo que ahorra Griffon en el desarrollo de aplicaciones Swing en comparación con Java. La prueba de ello fue cuando Andres empezó a hacer su demo, la programación de una aplicación con Griffon. Esta aplicación consistía en un pequeño cliente que se conectaba a una cuenta de Twitter (usando login y password) para listar todos sus followers. Todo programado desde cero, paso a paso y en directo, editando el código, compilando, corrigiendo errores y probando. El resultado final no tenía más de 10 clases y el código era compacto y fácil de entender. Había creado una aplicación desde cero, con una estructura básica coherente, perfectamente funcional, y ejecutable desde un Java Web Start, un applet o aplicación de escritorio. Hacer lo mismo con Java habría llevado, sin duda, muchísimo más tiempo.

        Por ejemplo, esto es una vista Swing hecha con Griffon:

        application(title:'gr8', pack:true, locationByPlatform:true {
            busyComponent(busy: bind{ model.busy }) {
        	panel {
        	   borderLayout()
        	   panel(constraints: NORTH) {
        	      gridLayout(rows: 3, cols: 2)
        	      label 'Username:'
        	      textField columns: 20, text: bind('username', target: model)
        	      label ' Password:'
        	      passwordField columns: 20, text: bind('password', target: model)
        	      label ''
        	      button 'Login', actionPerformed: controller.login
        	   }
        	   scrollPane(constraints: CENTER) {
        	        table {
        	            tableFormat = defaultTableFormat(columnNames: ['Id', 'Name'])
        	            eventTableModel(source: model.followers, format: tableFormat)
        	            installTableComparatorChooser(source: model.followers)
        	        }
        	    }
        	}
            }
        }

        Para acabar la presentación, Andres anunció en directo la liberación de la versión 0.3.1 de Griffon, donde incluye, principalmente, una guía completa y documentación de referencia para el programador: http://dist.codehaus.org/griffon/guide

        Mi conclusión es, tras acabar la demo, que Griffon es al desarrollo de aplicaciones de escritorio, lo que Grails es al desarrollo web: una manera de hacer lo mismo, pero más fácil, muchísimo más rápido, con menos código (y errores) y, sin duda, mucho más divertido.

        • Presentación de la ponencia de Griffon en Slideshare.
        • Descarga el código fuente de Gritter (197kb), la aplicación desarrollada por Andrés durante la conferencia.

        El post acaba aquí, pero hubo muchas más ponencias interesantes, así que… continuará…

        Popularity: 1% [?]

        Accediendo a los datos internos de Grails

          Publicado el Monday 17 de May de 2010. | 2 comentarios
          Categoría: Programación y diseño | Tags:

          A veces es inevitable tener la sensación de que Grails es demasiado sencillo y que esconde, a propósito, algo debajo. Debajo no tiene nada más que Spring, y gracias a ello, podemos entrar en sus “tripas”, verlo e incluso modificarlo.
          Veamos algunas formas sencillas se obtener información útil para nuestros desarrollos.

          Entorno

          Primero es saber en que entorno estamos trabajando ahora mismo. Podemos hacer que nuestro BootStrap (o un controlador o servicio, lo que sea), ejecute una acción u otra en función del entorno actual en el que se ha arrancado. Para ello tenemos la clase grails.util.Environment y los métodos isDevelopmentMode() y getCurrent()

          import grails.util.Environment
          
          class BootStrap  {
          
               def init = { servletContext ->
          
                   if (Environment.isDevelopmentMode()) {
                       println "development"
                   }
          
                   switch (Environment.getCurrent().name) {
                       case "development":
                           println "development"
                           break;
                       case "otro" :
                           println "otro"
                   }
               }
          }
          

          Para arrancar en un entorno u otro, hay que pasar el parámetro grails.env: grails -Dgrails.env=X war o grals -Dgrails.env=X run-app

          application.properties

          La configuración del application.properties se obtiene a través de ApplicationHolder.application.applicationMeta. Por ejemplo, el siguiente fragmento muestra todo el contenido de este fichero (es un GSP):

          <%@ page import="org.codehaus.groovy.grails.commons.ApplicationHolder" %>
          
          <h1>Meta:</h1>
          <g:each in="${ApplicationHolder.application.applicationMeta}" var="name">
          
              <li>${name}</li>
          
          </g:each>
          

          Config.groovy

          Todos nuestros datos de configuración que poquito a poco hemos ido metiendo en el Config.groovy están accesibles desde cualquier lugar de tu aplicación en el objeto ConfigurationHolder.config y ConfigurationHolder.flatConfig:

          <%@ page import="org.codehaus.groovy.grails.commons.ConfigurationHolder" %> 
          
          <h1>Config (flat)</h1>
          <g:each in="${ConfigurationHolder.flatConfig}" var="name">
          
                <li>${name}</li>
          
          </g:each>
          
          <h1>Datasource</h1>
          <g:each in="${ConfigurationHolder.config.dataSource}" var="name">
          
                <li>${name}</li>
          
          </g:each>
          

          Podemos crear en el fichero Config.groovy nuestra propia sección:

          xmpp {
              priority = 20
              client {
                    host = "192.168.3.1"
                    port = 2832
                    domain = "peterpan"
              }
          }
          ftp {
              user = "hoy"
              passwd = "gan"
          }
          

          Y luego acceder a estos valores desde un controlador así:

          import org.codehaus.groovy.grails.commons.ConfigurationHolder as CH
          
          class TestController {
          
              def index = {
                  def prio = CH.config.xmpp.priority
                  def host = CH.config.xmpp.client.host
                  def port = CH.config.xmpp.client.port
                  def doma = CH.config.xmpp.client.domain
          
                  def ftpuser = CH.config.ftp.user
                  def ftppasw = CH.config.ftp.password
              }
          }
          

          basePath

          Si quieres saber donde están físicamente los archivos de tu aplicación:

          import org.codehaus.groovy.grails.commons.ApplicationHolder;
          ...
          println ApplicationHolder.application.mainContext.servletContext.context.basePath
          

          La factoría de Spring

          Ahora vamos con Spring. Para acceder al contexto de la aplicación, al factory, tenemos ApplicationHolder.application.mainContext. De ahí podemos sacar beans, o mostrar todos los que ya hay:

          <%@ page import="org.codehaus.groovy.grails.commons.ApplicationHolder" %>
          
          <h1>System beans</h1>
          
          <g:each in="${ApplicationHolder.application.mainContext.getBeanDefinitionNames()}" var="name">
          
                <li>${name}/li>
          
          </g:each>
          

          Incluso podemos obtener un bean del sistema con ApplicationHolder.application.mainContext.getBean(beanName)

          web.xml

          Finalmente, podemos acceder a los atributos y parámetros de nuestro archivo /WEB-INF/web.xml con ServletContextHolder.servletContext.context

          <%@ page import="org.codehaus.groovy.grails.web.context.ServletContextHolder" %>
          
          <h1>Servlet context Attributes:</h1>
          
          <g:each in="${ServletContextHolder.servletContext.context.attributes}" var="name">
              <li>${name}</li>
          </g:each>
          
          <h1>Servlet context parameterss:</h1>
          
          <g:each in="${ServletContextHolder.servletContext.context.parameters}" var="name">
              <li>${name}</li>
          </g:each>
          

          Y a otros valores como el contextPath con ServletContextHolder.servletContext.context.contextPath y el resto de método de la interfaz javax.servlet.ServletContext

          Conclusión

          Como podemos observar, la aparente simplicidad de Grails no sirve para protegernos ni para esconder toda su información: existe toda una serie de clases con las que Grails nos facilita obtener beans de la factoría Spring, datos de sus archivos de configuración y parámetros y atributos de la aplicación Web. Resumen de clases y métodos usados:

          • grails.util.Environment.isDevelopmentMode()
          • grails.util.Environment.getCurrent().name
          • grails.util.GrailsUtil.grailsVersion
          • org.codehaus.groovy.grails.commons.ApplicationHolder.application.applicationMeta
          • org.codehaus.groovy.grails.commons.ApplicationHolder.application.mainContext.servletContext.context.basePath
          • org.codehaus.groovy.grails.commons.ConfigurationHolder.config
          • org.codehaus.groovy.grails.commons.ConfigurationHolder.config.dataSource
          • org.codehaus.groovy.grails.commons.ConfigurationHolder.flatConfig
          • org.codehaus.groovy.grails.commons.ApplicationHolder.application.mainContext.getBean(beanName)
          • org.codehaus.groovy.grails.web.context.ServletContextHolder.servletContext.context.attributes
          • org.codehaus.groovy.grails.web.context.ServletContextHolder.servletContext.context.parameters

          Espero que os haya servido de utilidad.

          Popularity: 1% [?]

          ITIL v.3 por Ernesto Vilches

            Publicado el Saturday 17 de April de 2010. | 4 comentarios
            Categoría: Literatura y CF, Noticias | Tags:

            Conozco a Ernesto Vilches desde que era pequeño, aunque él me conoce a mí desde que nací, más que nada porque es mi padre. No suelo hablar de cosas personales en el blog, pero este caso es especial porque está relacionado con la tecnología. Después de bastante tiempo trabajando duro, ha acabado y publicado su primer libro. Enhorabuena papá, no todo el mundo puede presumir de haber escrito un libro.

            De venta en el corte inglés: http://ebooks.elcorteingles.es/GUIA-DE-GESTION-DE-SERVICIOS-BASADA-EN-FUNDAMENTOS-DE-ITIL-V3-LibroEbook-9788492684601.html

            Popularity: 1% [?]

            Mini tutorial, log4j en Grails

              Publicado el Tuesday 13 de April de 2010. | 4 comentarios
              Categoría: Programación y diseño | Tags: , , ,

              El siguiente mini tutorial intenta explicar como configurar Grails para que ciertas clases (las que nosotros queramos) escriban sus logs en un fichero distinto. Esto puede ser necesario si, por ejemplo, hemos programado un componente en concreto usando varias clases que generan muchas trazas, y el fichero de log general de nuestro servidor de aplicaciones nos las muestra todas juntas y mezcladas, haciendo difícil el seguimiento de errores. Lo que vamos a hacer es:

              • Configurar log4j para que cree un fichero de log independiente llamado pepito.log
              • Configurar una clase para que escriba sus trazas en este fichero de log.

              Primero tenemos que editar el fichero grails-app/conf/Config.groovy y añadirle un nuevo appender y una categoría nueva en la sección log4j.

              log4j = {
                  appenders {
                      console name: 'stdout', layout: pattern(conversionPattern: '%d{yyyy-MM-dd HH:mm:ss} %-5p [%c{2}] %m%n')
              
                      rollingFile name:'pepitoAppender', file: "/tmp/pepito.log", append: true,
                          layout: pattern(conversionPattern: '%d{yyyy-MM-dd HH:mm:ss} %-5p [%c{2}] %m%n')
                  }
              
                  info pepitoAppender:'pepito', additivity:false
                  ...
              }
              

              El atributo additivity:false indica que si se usa ese appender, no se utilice ninguno otro más. De esta manera se evita que los logs salgan, además, en la salida standard y, por lo tanto, en el fichero de log principal de nuestro servidor de aplicaciones.

              Ahora tenemos que especificar en cada una de las clases (nuestro controladores, servicios, etc) que utilice nuestra categoría “pepito”. Para ello, utilizaremos el constructor LogFactory.getLog() indicando como parámetro un String que empiece siempre con "pepito.", por ejemplo "pepito.xxxx" o "pepito."+MiClase.class.getName()

              package pepito
              import org.apache.commons.logging.*
              
              class PepitoController {
              
                  private static Log log = LogFactory.getLog("pepito."+PepitoController.class.getName())
              
                  def index = {
                      log.info "Esto debería salir en pepito.log"
                  }
              }
              

              Si utilizamos Tomcat, podemos hacer que nuestros logs se creen en la carpeta $CATALINA_HOME/logs con el siguiente código:

              log4j = {
              
                  def catalinaBase = System.properties.getProperty('catalina.base')
                  def logDirectory = !catalinaBase? '/tmp': "${catalinaBase}/logs"
              
                  appenders {
                      rollingFile name:'pepitoAppender', file: "${logDirectory}/pepito.log", append: true,
                          layout: pattern(conversionPattern: '%d{yyyy-MM-dd HH:mm:ss} %-5p [%c{2}] %m%n')
                  }
              

              Así, si está definida la propiedad Java ‘catalina.base’ con el directorio de instalación de Tomcat (ya se encarga el propio Tomcat de definir esta propiedad cuando arranca), utilizará el directorio logs de Tomcat. Si no estuviera definida, utilizará “/tmp”.

              Otra forma de hacerlo sería especificando un appender distinto para cada environment. De esta manera podemos cambiar o añadir parámetros de configuración en los appenders, como el tamaño del fichero, el número de backups:

              log4j = {
              
                  appenders {
              
                      development {
                          rollingFile name:'pepitoAppender', file: "/tmp/pepito.log", append: true,
                              layout: pattern(conversionPattern: '%d{yyyy-MM-dd HH:mm:ss} %-5p [%c{2}] %m%n')
                      }
                      production {
                          rollingFile name:'pepitoAppender', file: "/usr/local/tomcat/logs/pepito.log", append: true,
                              maxBackupIndex: 10, maxFileSize: "10MB",
                              layout: pattern(conversionPattern: '%d{yyyy-MM-dd HH:mm:ss} %-5p [%c{2}] %m%n')
                      }
                  }
              

              Más información:

              Popularity: 1% [?]

              Entendiendo como funciona el desarrollo a medida

                Publicado el Monday 15 de March de 2010. | 2 comentarios
                Categoría: Humor, Pensamientos informaticos | Tags: ,

                La toma de requisitos, las funcionalidades, las pruebas de aceptación, todo son conceptos relativos y su significado depende de quién lo mire. Una estupenda guía para entender como ven cada una de las partes los encargados de crear un aplicación a medida:

                1. Lo que el cliente dijo.
                2. Lo que entendió.
                3. Lo que se planeó.
                4. Lo que se desarrolló.
                5. Lo que describió el analista del negocio.
                6. La documentación.
                7. Lo que se desarrolla.
                8. Por lo que ha pagado el cliente.
                9. El soporte.
                10. Lo que el cliente realmente necesitaba.

                Vía: Making Good Software, compartido en su Google Reader por Javier Neira

                Popularity: 1% [?]

                Probando Grails en Google App Engine

                  Publicado el Monday 1 de March de 2010. | 4 comentarios
                  Categoría: Programación y diseño | Tags: , ,

                  Este es un pequeño tutorial para probar una aplicación desarrollada con Grails sobre Google App Engine. La aplicación es lo más sencilla posible: no tiene clases de dominio ni servicios ni nada, tan solo un controlador que pinta “Hola mundo”. Las versiones que he utilizado son Grails 1.2.1 (descárgatelo de aquí: http://grails.org/Download) y Google App Engine SDK para Java 1.3.1 (descárgatelo de aquí: http://code.google.com/p/googleappengine/downloads/list)

                  El primer paso de todos es crear una cuenta en http://code.google.com/appengine y crear una aplicación. Para este ejemplo, asumiremos que el nombre de la aplicación es tuapp, pero podría ser cualquier otro. El nombre de la aplicación en App Engine debe coincidir con el nombre de la aplicación Grails.

                  Descargar el Google App Engine SDK, descomprimirlo en un directorio y establecer la variable de entorno APPENGINE_HOME para que apunte a dicho directorio. Ejecutar los siguientes comandos (se supone que tenemos instalado Grails y que el comando grails está en el PATH)

                  grails create-app tuapp
                  cd tuapp
                  grails set-version 1

                  Google App Engine no acepta números de versión decimales (como 0.1), por eso es importante que la versión sea un número entero, como 1, 2, etc.

                  Hay que desinstalar el plugin de Tomcat (solo se desinstala para esta aplicación, no para todo el sistema) ya que el plugin de Google App Engine lleva su propio servidor.

                  grails uninstall-plugin tomcat
                  grails install-plugin app-engine

                  Elegir jpa cuando te pregunte.

                  Ahora vamos a crear un controlador de prueba:

                  grails create-controller test.Test

                  Editar grails-app/controllers/test/TestController.groovy y modificar el closure index para que quede así:

                  package test
                  
                  class TestController {
                      def index = { render "Hola mundo" }
                  }
                  

                  Editar el fichero grails-app/conf/UrlMappings.groovy y cambiar el mapeo de “/” para que apunte al controller que acabamos de crear

                  "/"(controller:'test', action:'index')

                  Lanzar la aplicación con:

                  grails run-app

                  Probar que todo funciona visitando http://localhost:8080. Parar el servidor con CTRL+C.

                  Añadir las siguientes lineas al fichero grails-app/conf/Config.groovy con los datos de tu cuenta de Google.

                  google.appengine.email="tumail@gmail.com"
                  google.appengine.password="tupassword"

                  Despliega la aplicación con el siguiente comando:

                  grails app-engine deploy

                  Prueba que todo funciona correctamente visitando http://tuapp.appspot.com. He hecho más de una prueba, y no he conseguido hacerlo funcionar. Parece que la primera petición http que se hace a la aplicación, Google App Engine la inicializa y Grails tarda demasiado. Google App Engine tiene un límite de 30 segundos por petición, y si se supera ese tiempo, mata la petición. Y con ella, el proceso de arranque. Al parecer es un bug conocido: http://jira.codehaus.org/browse/GRAILSPLUGINS-1736. En fin, estaré al tanto para ver si se arregla este bug, ya que es bastante interesante poder disponer de un hosting gratuito para nuestras aplicaciones en Grails. Mientras tanto, probaremos otras opciones como Gaelyk, que es bastante más ligero.

                  Popularity: 1% [?]

                  Spring 2GX day en Madrid

                    Publicado el Saturday 20 de February de 2010. | 11 comentarios
                    Categoría: Noticias, Programación y diseño | Tags: , , , ,

                    Spring 2GX day es el primer evento gratuito organizado entre SpringSource y Javahispano que trata exclusivamente sobre Grails y Spring. La verdad es que fueron muchas cosas de las que se hablaron, y aunque el saber no ocupa lugar, la memoria siempre tiene un límite, así que intentaré contar mi propia versión del Spring 2GX day, es decir, de lo que me acuerdo.

                    Llego a las 8:15 y ya hay cola para registrarse, parece que este en evento va a haber mucha gente. Más tarde nos contarán que aunque inicialmente se esperaban unos 150 asistentes, a final serán más de 400. La organización, desbordada, tiene que planificar sobre la marcha, cambiar de sala de audiencias a una mayor y se quedan sin algunos items para todos que regalan durante el registro a todos los ponentes (como bolis, panfletos, etc.). Pese a todos los inconvenientes, todo sale perfectamente. ¡Felicidades Javahispano! :)
                    La presentación corre por parte parte de Abraham, de Javashipano, agradeciendo a todos los sponsors su ayuda y contándonos que no van a poder hacer streaming de las ponencias por problemas técnicos, una pena para los que no pudieron venir, aunque pueden estar tranquilos: todos los vídeos y transparencias van a ser publicados, pero tendrán que esperar un poquito. También comenta que en todas las ponencias se va a sortear un libro a uno de los asistentes (a mí no me tocó ninguno, una pena porque el libro The Definitive Guide to Grails, 2nd edition, venía firmado por el propio Graeme Rocher).

                    Empiezan las ponencias. Entra Graeme Rocher, creador de Grails, entre aplausos. Aunque comienza su introducción en castellano, prefiere continuar en inglés donde se encuentra más cómodo, sobre todo a la hora de utilizar palabras técnicas. Graeme empieza a hablar sobre Grails comentando que esta construido sobre hombros de gigantes: Java, Groovy, Spring, Hibernate, Sitemesh y Quartz (he encontrado la presentación aquí: http://europe.springone.com/europe-2009/file?path=/springone-amsterdam-2009/slides/GraemeRocher_HowToBuildTwitterIn40minsUsingGrails.pdf)

                    Finalizada la presentación y usando SpringSource Tool Suite en su portátil, nos muestra un caso practico para enseñarnos que Grails es realmente Spring y que la capa web de Grails es Spring MVC. Para ello, crea una aplicación de prueba desde cero, añade en un controller el applicationContext de Spring implementando la interfaz ApplicationContextAware y accede con este contexto a diferentes beans de Spring desde Grails, como un DataSource, el SessionFactory de Hibernate, etc. Después, para demostrar que Gorm es Hibernate, crea un clase de dominio y la guarda desde la sesión actual del sessionFactory de Spring y con el método dinámico save() de Gorm, con idénticos resultados.

                    La siguiente ponencia, de Sergi Almar, nos cuenta las ventajas de utilizar la capa web de Spring 3.0, explicando como es posible programar vistas completamente diferentes, como XML, JSON o HTML con el mismo controlador para soportar, por ejemplo, peticiones Rest y Ajax reutilizando código.

                    Paramos a tomar un cafe o zumo, cortesía de los sponsors, y seguimos las ponencias. Ahora entran Nacho Brito y Alvaro Sanchez-Mariscal, donde Alvaro nos explica las bondades de la plataforma Grails y anima a los dudosos y escépticos a dar el paso a probarla. Para ello utiliza una gran dosis de humor y auto-crítica, recordándonos lo “felices” que éramos con Struts 1, mapeando las acciones en interminables xml y que ahora es posible hacer exactamente lo mismo y más, sin tocar ni un xml. Después, Nacho Brito nos cuenta como novedad el nuevo campus virtual semi-presencial de escuela de groovy y ofrece una oferta de descuento del 50% para los matriculados ese día. Una interesante manera de hacer un curso de Groovy y Grails desde casa con material de estudio y tests de mano de los creadores de escuela de Groovy y de el libro manual de desarrollo web con Groovy. Finaliza la ponencia con Juanfer Blasco, responsable de Arquitectura y Plataformas del Dpto. De Tecnologías de la Información del Ayuntamiento de Vitoria-Gasteiz, contando un caso de éxito de formación e implantación de Groovy y Grails gracias a Escuela de Groovy.

                    La siguiente ponencia es de Joris Kuipers, donde nos explica OSGi, un nuevo sistema para desplegar modularmente nuestras aplicaciones y evitar problemas de dependencias o de reinicios durante los despliegues. Con un contenedor OSGi, ya no desplegamos ears o wars de manera monolítica en un sistema de classloaders jerárquico, sino que desplegamos jars que exponen beans en un sistema de classloaders en forma de grafo, donde se exportan e importan servicios. El tiempo apremia y dado que se arrastran algunos retrasos en todas las ponencias, Joris tiene que acabar deprisa su exposición con una demo donde despliega diferentes servicios en caliente. Personalmente no conocía OSGi, y la demo me deja impresionado y con ganas de utilizarlo en futuros proyectos.

                    La última ponencia es de los creadores de Jobsket a los que ya conocía, sin saberlo, de twitter: Martín Pérez, Jordi Monné y Dani Latorre. Nos explican un caso de éxito real de implantación de Grails en su proyecto Jobsket y nos cuentan, con sinceridad, las cosas buenas de Grails pero también las malas. Muchas de ellas reconocen que ahora han sido mejoradas o arregladas (como el soporte de plugins, que cuando empezaron no funcionaban muy bien), pero eso no quita para que también reconozcan que el uso de Grails, en el fondo, ha merecido la pena y ha mejorado su productividad. El código de su proyecto es 70% Java y 30% Grails: con unos 350 gsp, el principal uso de Grails es para la capa de presentación. Para el resto de código, como el acceso a diferentes bases de datos y los crawlers para recolectar información, utilizan Java, donde se sienten más cómodos y aprovechan código anterior que ya tenían realizado. Jobsket es un portal de empleo donde su principal punto fuerte es el análisis de curriculums para empresas, realizado con Lucene, y la recolección sistemática de ofertas de empleo en otros portales para calcular la valoración de sus curriculums a partir de los sueldos ofertados.

                    No conocía Jobsket, así que he entrado y me he registrado ayer mismo al volver a casa, y me ha sorprendido algunas cosas: que es capaz de decirte que empleos o provincias tienen los sueldos más altos (y bajos) y sus variaciones diarias. Como si de la bolsa se tratara, podemos entrar todos los días y ver la evolución del mercado. Y todo gracias a su sistema de crawlers que están constantemente recolectando información. Una imagen vale más que mil palabras: http://www.jobsket.es/trabajos-de-tecnologias-de-la-informacion

                    Hora de comer, dada la cantidad de gente que hay, me voy con Roberto Gil, Jose Vicente Carretero, Carlo Scarioni y Pablo Pazos haciendo una comida ligera en el centro de Boadilla (picadillo de chorizo, torreznos, carcamusa y presa de ibérico…, no te digo “ná”)

                    Continuamos con las ponencias, ahora le toca el turno a Federico Caro de Paradigma Tecnológico, donde nos habla sobre Spring Security 3.0 de una manera, primero teórica, y después práctica, bastante interesantes.

                    Después continúa Juan José Martín, que nos cuenta como Spring Roo nos ayuda a crear la estructura básica necesaria de archivos y configuración para empezar un proyecto con Spring. No conocía Roo, así que es una grata sorpresa para mí que existan este tipo de herramientas que te generan el código y el esqueleto básico para arrancar una aplicación. Roo es una shell inteligente: es decir, sabe en que estado se encuentra tu proyecto y te sugiere cual es el siguiente paso que debes dar, con autocompletado de parámetros obligatorios y mostrando después los opcionales.

                    Siguiente ponencia, espectacular, de la mano de Tomas Lin, donde nos muestra como integrar aplicaciones ricas de escritorio con Flex/Air con Grails. Para ello, primero nos enseña como crear scaffoldings de nuestras entidades (es decir, crud: altas, bajas, borrados y modificaciones) usando un cliente flash incrustado en html con flex. El resultado final es un crud mucho más vistoso y usable que el generado por Grails con html puro, gracias al plugin de Grails Flex Scaffolding. También nos muestra la clara integración que existe entre todas las herramientas de Adobe, como Photoshop y Catalyst, con Flex Builder, un entorno de desarrollo basado en Eclipse para crear aplicaciones ricas. Con Flex Builder, conecta varios combos que se actualizan con un servicio web creado con Grails y XFire. Tomas Lin está haciendo un libro sobre Grails y Flex que se puede leer aquí: http://flexongrails.com

                    Un cafe rápido, donde puedo conocer y hablar con los creadores de Jobsket, unos auténticos emprendedores y ejemplo a seguir de como es posible vivir con talento y creando una aplicación innovadora como la suya.

                    Finaliza el día con dos charlas, por un lado Groeme Rocher presenta en una sala una introducción a Groovy y Grails, y por otro, Joris Kruipers presenta cloud para simples mortales. No puedo hablar de la ponencia de Groeme porque no asistí, pero no dudo que escuchar una introducción sobre Grails de su propio creador, sea la mejor manera de empezar a con Groovy y Grails.

                    La ponencia de Joris Kruiper es muy esclarecedora. Empieza con una presentación donde explica los diferentes sistemas de cloud: Saas, Paas, IaaS, después muestra los diferentes y principales proveedores de cloudcomputing actuales, entre ellos Amazon Web Services (como IaaS), CloudFoundry (con un modelo mixto entre IaaS y PaaS), y Google App Engine (con un claro modelo de PaaS). Para acabar, nos hace dos demostraciones en vivo: la primera, sobre como crear una aplicación en Grails y desplegarla en CloudFoundry desde la línea de comandos con el plugin de Cloud Foundry para Grails. Y la última, la creación y despliegue de una aplicación Grails en Google App Engine. La conclusión final que nos ofrece es que el mejor sistema de cloud computing es el de Amazon, siempre que asumamos que debemos ser nosotros los encargardos de la instalación y despliegue de todos sus componentes. Y que Google App Engine es una buena manera de empezar, ya que es gratuito para las primeras 10 aplicaciones, pero a cambio debemos cambiar nuestro manera de programar las aplicaciones, ya que Google App Engine no soporta Gorm, solo JPA, y no permite hacer joins en base de datos o acceder al sistema de archivos, entre otras muchas cosas (más información en el blog de Tomas Lin). Para acabar, Joris Kruiper nos ofrece a todos los asistentes cuentas de prueba para CloudFoundry, donde las primeras 48 horas de “cloud” son gratuitas. También nos recuerda que, durante estas 48 horas de prueba, apaguemos el servidor cuando no lo utilicemos para que no se consuman a los dos días, y que nos duren mucho más.
                    Durante la ronda de preguntas, Tomas Lin nos explica que Google App Engine es un fantástico sistema para manipular y servir imágenes.

                    Mi conclusión final es que fue un gran evento con grandes ponentes, centrado en tecnologías punteras como Spring y Grails, y donde se puede conocer gente y aprender cosas nuevas de mano de primeras figuras del panorama tecnológico actual. Sinceramente, mi enhorabuena a Javahispano y Springsource: espero que se repita todos los años.

                    Más información:

                    Popularity: 1% [?]

                    Un generador de passwords en grails

                      Publicado el Wednesday 17 de February de 2010. | 2 comentarios
                      Categoría: Programación y diseño | Tags: ,

                      A raíz del post en wwhatsnew donde se listan diferentes aplicaciones web para generar passwords seguras, he decidido crear un sencillo servicio de Grails que genera passwords. En DATA he quitado los números 1 y 0, y las letras L minúscula, I mayúscula y las dos oes, así se evitan confusiones del tipo “eso es una o mayúscula o un cero?”, aunque se pueden volver a añadir. La proporción de símbolos, números y letras es de 25%/25% y 50%, respectivamente. El código es autoexplicativo.

                      class PasswordGeneratorService {
                      
                          int DEFAULT_SIZE = 8
                          Random rnd = new Random()
                          String DATA =
                              '!$%&().?=/*+!$%&().?=/*+'+
                              '234567892345678923456789'+
                              'abcdefghijkmnpqrstuvwxyz'+
                              'ABCDEFGHJKLMNPQRSTUVWXYZ'
                      
                          String generateNew() {
                              return generateNew(DEFAULT_SIZE)
                          }
                      
                          String generateNew(int size) {
                              StringBuffer result = new StringBuffer()
                      
                              size.times {
                                  result << DATA[rnd.nextInt(DATA.length())]
                              }
                      
                              return result.toString()
                          }
                      }

                      En alt1040 han creado un interesante post sobre como crear contraseñas seguras.

                      Popularity: 1% [?]