4Trabes - De todo un poco

Usando un keystore con Play

2010-07-27T08:08:00Z

Este post es para Simón. El otro día mientras le dábamos clase en el Master de Software Libre nos dijo que últimamente no escribíamos mucho. Acto seguido le prometimos un post dedicado. Seguro que se lo tomó a broma :)

Play en su versión actual (1.0.3.1) no soporta keystores, sin embargo, con un poquito de Python podemos modificar el script play para que lo haga.

Alrededor de la línea 468 del fichero $PLAY_HOME/play (en el contexto del método do_java) metemos un código parecido a este:

trustStore = readConf('java.trustStore')
if not trustStore == '':
    if os.path.exists(trustStore):
        print "~ using keystore \"%s\"" % trustStore
        java_args.append('-Djavax.net.ssl.trustStore=%s' % trustStore)
        trustStorePassword = readConf('java.trustStore.password')
        if trustStorePassword == '':
            print "~ WARNING: No java.trustStore.password key found in config. You need a password to use a keystore"
        else:
            java_args.append('-Djavax.net.ssl.trustStorePassword=%s' % trustStorePassword)

Y ya podemos configurar nuestro keystore en el fichero conf/application.conf de nuestra aplicación.

java.trustStore=/home/david/opt/javacerts/development
java.trustStore.password=123456

play run y a correr.

Timestamps automáticos para los modelos de Play

2010-06-23T11:10:00Z

Una de las cosas a las que me he acostumbrado al trabajar con Rails es al mantenimiento automático de timestamps (a saber, fecha de creación y fecha de actualización). El framework Play no tiene nada del estilo, así que aquí os dejo la clasecilla que usamos nosotros para obtener este comportamiento. Con sólo dejarla en app/models todos los modelos tendrán los atributos createdAt y updatedAt y sus valores se actualizarán automáticamente. A nosotros nos gusta así, pero podéis afinar el comportamiento a vuestro gusto.

package models;

import java.util.*;
import javax.persistence.*;
import play.db.jpa.*;

@MappedSuperclass
public class Model extends play.db.jpa.Model {

    public Date createdAt;

    public Date updatedAt;

    @PrePersist
    void onPrePersist() {
        if (this.createdAt == null) {
            this.createdAt = new Date();
        }
        this.updatedAt = this.createdAt;
    }

    @PreUpdate
    void onPreUpdate() {
        this.updatedAt = new Date();
    }
}

Git 1.7 me hace más feliz

2010-06-02T15:36:00Z

La versión 1.7 de Git incluye, entre otras novedades, una nueva opción para el comando git branch: --set-upstream, que facilita fijar que una rama local haga tracking de una rama remota (útil en nuestro primer push por ejemplo).

$ git remote add origin git@myawesomerepo.com:myproject.git
$ git push origin master
$ git branch --set-upstream master origin/master

La última línea sustituye a los mecanismos anteriores: llamar a git config de un modo oscuro

$ git config branch.master.merge refs/heads/master

...o bien usar una herramienta externa tipo git_remote_branch.

$ grb track master origin

Pefiero usar esta nueva opción.

Play framework: fix para el módulo de Ivy

2010-05-19T14:29:00Z

La versión 1.0 del módulo de Ivy tiene un pequeño bug que hace que los comandos Play de otros módulos no puedan ejecutarse. No voy a entrar en explicaciones, sólo os dejo el fix: tenéis que eliminar la última línea del fichero ${play.path}/modules/ivy-1.0/commans.py.

    print "\n"
    print "~~~~~~~~~~~~~~~~~~~~~~~~~~~~"
    print "~ Application dependencies ~"
    print "~~~~~~~~~~~~~~~~~~~~~~~~~~~~"
    for jar in os.listdir(os.path.join(application_path, 'lib')):
        print(jar)
    print "\n"

sys.exit(0)  # ¡Esta línea es maligna!

Maven a todo color

2010-05-12T13:49:00Z

Hay una cosa que siempre me ha fastidiado de la salida que escupe maven al ejecutar los tests: nunca sé, así de un vistazo, si todo ha ido bien o si ha fallado algo. Así que tras googlear un poco me he topado con esto http://ju-n.net/colorize-maven-output.

Se trata de una función bash que utiliza sed para procesar la salida de maven y colorearla.

Para poder utilizarlo también con watchr (sobre el que David ha blogueado recientemente) hemos (gracias David) introducido un par de modificaciones en el script que aparece en el enlace anterior:

  # aquí irían todos los exports de colores
  ...
  # hacemos un alias del comando sed que aparece en el enlace de más
  # arriba sin olvidarnos de resetear los estilos al final
  alias colorize-mvn-output='sed -e [...] && echo -ne ${RESET_FORMATTING}'

  mvn-color() {
      $(which mvn) $@ | colorize-mvn-output
  }
  alias mvn="mvn-color"

  mvn-watchr() {
      watchr $@ | colorize-mvn-output
  }

  # como usamos watchr para más cosas que ejecutar tests 
  # de maven, no creamos un alias que sobreescriba el comando 
  # watchr

Ahora, cuando hagamos directamente

  $ mvn test

o bien utilicemos watchr llamando a

 $ mvn-watchr path/to/script.file

obtendremos unos resultados muchos más coloridos.

Y con esto queda explicado mi extraño tweet.

Watchr aplicado: autotesting con Maven

2010-05-10T22:16:00Z

Variante de la receta que os traje el otro día. Esta vez utilizando Maven en lugar de Ant. Sólo hay que modificar un poco el fichero de configuración de Watchr y listo.

watch( 'src/main/java/(.*)\.java' )  do |md|
    file = "#{md[1]}Test"
    test(file) if File.exists?("src/test/java/#{file}.java")
end

watch( 'src/test/java/(.*Test)\.java' ) { |md| test(md[1]) }

def test(file)
    system("mvn test -Dtest=#{file.gsub("/",".")}")
end

Watchr aplicado: JUnit autotesting con Ant

2010-05-07T12:19:00Z

Ingredientes

Watchr
Fichero de configuración de Watchr
Tarea Ant para testear una clase con JUnit

Preparación

Instalamos Watchr en nuestro sistema (es necesario disponer de Ruby en nuestra cocina para preparar esta receta):

$ gem install watchr

Preparamos un fichero de configuración de Watchr (watchr.conf) y reservamos:

watch( 'src/(.*)\.java' )  do |md|
    file = "#{md[1]}Test"
    test(file) if File.exists?("test/#{file}.java")
end

watch( 'test/(.*Test)\.java' ) { |md| test(md[1]) }

def test(file)
    system("ant -Dtest=#{file.gsub("/",".")} test-file")
end

Es importante elegir los sabores adecuados de expresiones regulares para que Watchr vigile tanto el código fuente como, los ficheros de test.

Después creamos una tarea Ant que testea una clase indicada mediante párametro:

$ ant -Dtest=mi.paquete.MiClase test-file

Sazonamos la tarea al gusto. El chef recomienda:

<target name="test-file" depends="test-compile">
    <junit>
        <classpath refid="project.classpath.test"/>
        <formatter type="brief" usefile="false"/>
        <test name="${test}"/>
    </junit>
</target>

Mezclamos todo y emplatamos:

$ watchr watchr.conf

Algunos chefs, prefieren presentar el plato usando Ant:

<target name="autotest">
    <exec command="watchr">
        <arg value="watchr.conf"/>
    </exec>
</target>

Esto último es opcional, sólo para aquellos cocineros que quieran manejar todo lo relativo a su proyecto con Ant.

Gestión de dependencias en aplicaciones Play!, versión inicial: Ant + Maven

2010-04-29T16:17:00Z

Uno de los cambios derivados de nuestra migración a Play! como framework MVC para aplicaciones web Java, es el uso de Ant como gestor de builds. En Trabe utilizamos Maven habitualmente, ya que nuestros proyectos se adaptan bien a la estructura y ciclo de vida que marca esta herramienta, sin embargo, las aplicaciones Play! y sus módulos definen su propia estructura de directorios y utilizan Ant. Maven está muy bien cuando te ciñes a su estructura de proyecto, pero si haces algo distinto se hace necesario escribir descriptores gigantes y, francamente, el soporte Ant de Play está suficientemente bien como para aceptar el cambio.

Usar Ant en este contexto sólo tiene un problema: Ant no gestiona dependencias. Para solventarlo, como no tenía mucho tiempo para pensármelo, opté inicialmente por combinar Ant y Maven. Esta solución es aplicable a cualquier proyecto que utilice Ant como gestor de builds, no sólo a los proyectos Play!

Para gestionar las dependencias con Maven, lo primero es crear un POM con lo mínimo:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
                             http://maven.apache.org/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.4trabes</groupId>
    <artifactId>awesome</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>4Trabes awesome Play library</name>

    <dependencies>
       <dependency>
            <groupId>org.op4j</groupId>
            <artifactId>op4j</artifactId>
            <version>1.0</version>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-dependency-plugin</artifactId>
                <configuration>
                    <outputDirectory>lib/</outputDirectory>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

Mínima información acerca del proyecto, nuestra lista de dependencias (sin preocuparse de los scopes) y, muy importante, la configuración del plugin de dependencias para que copie las librerías en el directorio lib (o en otro lado, a gusto del consumidor).

Ahora es cuestión de añadir a nuestro build.xml una tarea que invoque el goal copy-dependencies del plugin dependency de Maven:

<target name="deps">
    <exec executable="mvn">
        <arg value="-f"/>
        <arg value="deps.xml"/>
        <arg value="dependency:copy-dependencies"/>
    </exec>
</target>

Pan comido. Cada vez que ejecutemos ant deps se descargarán las librerías que no tengamos.

Si se trata de un proyecto Play!, es buena idea configurar el plugin de dependencias para que excluya las librerías que vienen de serie con el framework para evitar conflictos. Aquí os dejo las exclusiones para la versión 1.0.2.1 (creo que están todas).

<excludeArtifactIds>
    activation,antlr,backport-util-concurrent,bcprov-jdk15,c3p0,
    cglib-nodep,commons-beanutils,commons-codec,commons-fileupload,
    commons-httpclient,commons-lang,commons-logging,core,dom4j,
    ehcache,ejb3-persistence,ezmorph,filters,geronimo-servlet_2.5_spec,
    groovy-all,gson,hibernate,hibernate-core,
    hibernate-commons-annotations,hibernate-entitymanager,hsqldb,
    jamon,jaxen,jsr107cache,jta,junit,log4j,lucene-analyzers,
    lucene-core,mail,oval,snakeyaml,slf4j-api,slf4j-log4j12
</excludeArtifactIds>

Aunque esta solución es válida decidí investigar un poco más y finalmente decidí cambiar Maven2 por Ivy, que me parece más “natural”. Pero eso lo dejo para otro post.

rvm + rails3.0.0.beta + ruby 1.9.1

2010-04-28T10:36:00Z

Desde hace unos meses estoy “viviendo en edge”. Para ello estoy usando rvm , que nos permite tener varias versiones de ruby con sus correspondientes gemas.

Tras actualizar a la beta de rails e intentar ejecutar la consola (con el nuevo comando rails console ) me topé con el siguiente error:

$ rails console
/home/andion/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/1.9.1/irb/completion.rb:9:in `require': no such file to load -- readline (LoadError)
    from /home/andion/.rvm/rubies/ruby-1.9.1-p378/lib/ruby/1.9.1/irb/completion.rb:9:in `<top (required)>'
    from /home/andion/.rvm/gems/ruby-1.9.1-p378/gems/railties-3.0.0.beta/lib/rails/commands/console.rb:3:in `require'
    from /home/andion/.rvm/gems/ruby-1.9.1-p378/gems/railties-3.0.0.beta/lib/rails/commands/console.rb:3:in `<top (required)>'
    from /home/andion/.rvm/gems/ruby-1.9.1-p378/gems/railties-3.0.0.beta/lib/rails/commands.rb:32:in `require'
    from /home/andion/.rvm/gems/ruby-1.9.1-p378/gems/railties-3.0.0.beta/lib/rails/commands.rb:32:in `<top (required)>'
    from /home/andion/git/efimera-eopages/script/rails:10:in `require'
    from /home/andion/git/efimera-eopages/script/rails:10:in `<main>'

Cuando me encontré con el problema estaba usando rvm0.1.23, rails3.0.0.beta y ruby1.9.1 pero supongo que la solución será extensible a las siguientes betas de rails (ahora mismo uso rails3 beta 3 y ruby 1.9.2 y todo sigue bien tras el fix)

Revisé algunas soluciones, pero todas estaban orientadas al uso de un ruby de sistema y no a través de rvm, además, la solución que ofrece la web de rvm aunque parecía lógica, tampoco me funcionaba:

$ rvm package install readline
Package 'readline' is unknown.
Usage: 'rvm package {install,uninstall} {openssl,zlib,readline,iconv,ncurses}'

Googleando un poco más si que he visto alguna gente con el mismo problema por aquí y por allá

La solución para mí: una mezcla de las solución que da rvm y la sabiduría popular: reinstalar ruby 1.9.1 con el flag: readline-dir a un directorio válido para rvm:

$ rvm uninstall 1.9.1
$ rvm install 1.9.1 --with-readline-dir=$rvm_path/.rvm/usr

Edit 06/05/2010

Tras actualizar a Ubuntu Lynx y con rvm 0.1.29 el problema se mantiene, pero la solución que poponen en la web de rvm lo arregla:

$ rvm package install readline ; rvm remove 1.9.1 ; rvm install 1.9.1 -C --with-readline-dir=$rvm_path/usr

Rock 'n' Troll

2010-04-12T16:50:00Z

Debido a algunos comentarios recibidos en el blog hemos decidido incluir un sistema de trolling. Como no se trata de censurar sino de denunciar que un comentario es inapropiado, que está fuera de lugar o que es ofensivo, los comentarios de trolls aparecerán marcados con la etiqueta Rock ‘n’ troll y su texto estará sombreado. Seguirá siendo posible leer su contenido, pero ya avisamos que probablemente se trate de una ventosidad mental y no merezca la pena perder el tiempo leyéndolo.

Op4j: bending the Java Spoon

2010-03-08T08:55:00Z

Del creador de Jasypt llega ahora la beta de op4j: una librería pensada para hacer felices a los programadores Java.

It is a Java library aimed at improving quality, semantics, cleanness and readability of Java code, especially auxiliary code like data conversion, structure iteration, filtering, mapping

Básicamente, mediante encadenamiento de métodos podremos realizar las típicas tareas “coñazo” del código Java en una sola línea, con un enfoque más declarativo (qué hacer y no cómo hacerlo).

Se entiende mejor con un ejemplo extraído de la documentación: obtener a partir de una lista de cadenas con fechas en formato “dd/MM/yyyy” un conjuto de objetos Calendar que no incluya ni nulos ni fechas futuras.

Antes

Calendar now = Calendar.getInstance();
SimpleDateFormat dateFormat = new SimpleDateFormat("dd/MM/yyyy");
Set<Calendar> set = new LinkedHashSet<Calendar>();
for (String element : list) {
  if (element != null) {
      try {
          date = dateFormat1.parse(element);
      } catch (ParseException e) {
          throw new SomeException(e);
      }
      Calendar calendar = Calendar.getInstance();
      calendar.setTimeInMillis(date.getTime());
      if (!calendar.after(now)) {
          set.add(calendar);
      }
  }
}

Después

Calendar now = Calendar.getInstance();
Set<Calendar> set = Op.on(list).toSet().
    map(FnString.toCalendar("dd/MM/yyyy")).
        removeAllNullOrTrue(FnCalendar.after(now)).get();

No está nada mal. Podéis probarlo y colaborar a su desarrollo ofreciendo feedback a su autor.

Más FypURL

2010-01-23T23:56:00Z

No sé si os acordáis de FypURL, una pequeña aplicación que montamos Asís y yo por impulso/capricho en una tarde de abril hace casi tres años. Desde entonces hemos seguido dando servicio a su humilde base de usuarios.

Últimamente he estado pensando que era una pena no haber ofrecido ninguna novedad en estos tres años y aprovechando que algunos Trábicos hemos comenzado a jugar con las extensiones de Google Chrome, he publicado una extensión para usar FypURL: ofrece un acceso directo a los bookmarklets de fypeo y desfypeo y permite crear una lista de enlaces a las fypurls de nuestros conocidos. No está mal como experimento.

Esto no es lo último que voy a hacer con FypURL. Tengo planeadas algunas cosas y habrá que ver si hago un hueco para llevarlas a cabo (o hacemos, si lío a alguien más, jeje). De partida responderé a la petición de bastante gente y en brevé liberaré el código fuente de FypURL. A día de hoy ya he liberado el código de la extensión para Chrome y está disponible en Github. No es nada del otro mundo pero puede ser interesante con fines educativos.

Si queréis seguir al tanto de lo que pasa con FypURL sólo teneís que seguir a FypURL en Twitter.

El cuadro

2010-01-14T11:17:00Z

Llevabamos un tiempo pensando en colgar cuadros por la oficina para darle algo de ambientillo, aunque no habíamos empezado porque necesitabamos un primer cuadro. Gracias a la artista de Carolina y a nuestra querida Marta ya lo tenemos y hemos estrenado las pared. Esperemos que sea el primero de muchos.

Feliz 2010

2009-12-31T10:46:00Z

El deseo de los miembros de Trabe para todo el mundo: mucha felicidad en 2010.

Como el año pasado, el bambú también os desea feliz año.

Bye bye Galicia Global

2009-12-31T09:47:00Z

Ya lo habíamos anunciado. Galicia Global ha cerrado sus puertas hoy 31 de diciembre de 2009. Este cierre es definitivo, hemos eliminado todos los datos que teníamos almacenados, backups, etc. No hay vuelta atrás.

Ha sido una experiencia gratificante. Os agradecemos a todos vuestra participación.