Para mostrar el contenido de un fichero en un determinado momento, se puede hacer:
git show :
Por ejemplo:
git show master^^:docs/README
Esto mostrará el contenido de README hace dos commits desde el tip de master.
También podemos usar un hash de un commit anterior:
git show b9299450ad3816e:docs/README
Para los acostumbrados a Subversion, es el equivalente a svn cat
Una pequeña ayuda para usar la herramienta fab de fabric (herramienta/librería en python para facilitar el uso de una shell remota): Cuando has creado un fabfile con numerosas tareas (y que además puedan tener nombres largos), puede ser un poco tedioso recordar y escribir completamente las tareas a ejecutar. P.ej:
$ fab my_long_named_task
Para habilitar el bash tab completion para fab, he creado un pequeño script:
_fabric_completion()
{
local cur opts
COMPREPLY=()
cur="${COMP_WORDS[COMP_CWORD]}"
opts=$(fab -F short --list)
COMPREPLY=( $(compgen -W "${opts}" -- ${cur}) )
return 0
}
complete -F _fabric_completion -o default fab
basta con incluirlo con cualquier nombre en /etc/bash_completion.d/ et voilá, al pulsar tab nos autocompletará la tarea a ejecutar. Lamentablemente esto no da soporte para autocompletion de parámetros de las tareas.
De un tiempo a esta parte, vengo utilizando git en algún proyecto como sistema de control de versiones, pero nunca se me había ocurrido postear algo sobre ello. Mi intención es poner pequeños posts sobre el uso de git (si las ganas de escribir me lo permiten 
). Aquí va el primero:
Cómo modificar un commit antiguo:
Si hemos hecho un checkin, y acto seguido nos damos cuenta de que nos hemos dejado un fichero sin subir, o bien acabamos de hacer otra corrección que debería haber ido en el anterior, simplemente se añade el cambio al índice de forma normal, y después:
$ git commit --amend
Hasta aquí lo fácil. Si el tras el commit en cuestión hicimos una serie de cambios y commits, pero aun así decidimos que queremos modificar dicho commit en lugar de hacer uno nuevo tras los últimos, podemos hacerlo del siguiente modo:
Primero localizamos el hash del commit a modificar
$ git rebase acc643cd^ -i En el editor que git nos muestra, poner 'edit' al commit a modificar $ git commit --amend Ya tenemos el commit modificado. Por último: $ git rebase --continue
Por supuesto esta práctica deberíamos evitarla si el commit en cuestión ya había sido publicado en un repo accesible, pero a mi me resulta muy muy útil trabajando con mis repos locales o en aquellos que se positivamente que solo yo toco.
Este fin de semana tuve el placer de asistir al Agile Open Spain 2011 en Pamplona, y al igual que en el anterior de 2010, las sensaciones que me llevo son inmejorables. Una de los aspectos que más aprecio en este tipo de eventos es la posibilidad de comprobar que gente a la que que sigues en twitter son de carne y hueso, y con quienes puedes tener una buena charla (con y sin cervezas de por medio). A destacar la gran afluencia de aragoneses en la cita.(ver fotos foto1 y foto2 en el flickr de Pablo Jimeno).
El viernes por la tarde fue dedicado a la propuesta y organización de las sesiones del día siguiente, y a conocerse y dialogar, aunque, a diferencia del AOS 2010, no hubo tantos juegos para forzar a conocer gente nueva y sobretodo a realizar agrupaciones por comunidades para facilitar el posterior contacto (esto fue comentado como algo a recuperar en la retrospectiva final). Muy buenas propuestas para las sesiones del día siguiente, muchos temas interesantes, y pocas a las que poder asistir.
Se completó la jornada con una cena a base de unos pintxos y bocatas buenísimos en un garito de la plaza del castillo cuidadosamente regada con las mejores cebadas que pudimos encotrar, y que se prolongó hasta bien entrada la madrugada. Un placer haber compartido esos ratos con algunos de los asistentes.
El Sábado por la mañana bien puntuales y con ganas de empezar las sesiones (precedidas por un muy buen desayuno a cargo de la organización).
La primera a la que asistí fue a la sesións sobre internship o acogida por parte de empresas de personas procedentes de otras, con el fin de generar un enriquecimiento mutuo, de la que salió la intención de dar más visibilidad a la iniciativa, y generar una lista de empresas/personas interesadas en este tipo de intercambios.
A esto siguió una muy divertida introducción a Ruby que me puso los dientes largos (mi única experiencia con ruby es algún trasteo con scripts de buildr), seguido de una charla de Jose Luis Soria (Plain Concepts) sobre estimación, de la que salí con la firme intención de mejorar en este aspecto.
A destacar la muy interesante charla de Artitz (@artziS) de Biko2 sobre la incorporación de UX en las metodologías ágiles. Totalmente de acuerdo con el en la necesidad de la colaboración contínua en los ciclos de desarrollo, en lugar de la metodología tradicional de tener un equipo de UX totalmente separado del product owner y equipo de desarrollo. Interesante también la propuesta válida para proyectos o equipos más pequelos de que el product owner sea el encargado de user experiencie, e incluso que sea un perfil de UX el que se haga cargo del rol de product owner. Una pena no haber tenido un clon para haber podido asistir a “Lean Code”, en la que los asistentes se ensuciaron las manos en un teclado 
.
A pesar de que la tarde se hizo más dura (el día anterior y lo intenso del actual empezaban a pasar factura), pude sacar algunas ideas interesantes en las sesiones de “Inceptions” y aprendizaje contínuo, que trataré de aplicar en lo sucesivo.
Por último se hizo la retrospectiva, de la que surgió la intención para futuros AOS de “abrir” el evento a personas de otros ámbitos distintos al desarrollo, acompañado del “reto” lanzado por Teresa Oliver de organizar el siguiente AOS en Zaragoza, al que también aspirarán las Canarias.
Esperemos tener el placer de hacer de anfitriones en el próximo!!!
A la hora de hacer una búsqueda en LDAP, puede presentarsenos la necesidad de saber únicamente si tenemos alguna entrada que cumpla una condición x, sin importarnos los atributos que estas entradas tengan. Para evitar obtener dichos atributos, lo que supondría un coste innecesario, y si el api que estemos usando nos obliga a especificar los atributos a obtener, puede usarse el atributo especial “1.1″, que indica que solo habrán de devolverse los DN de las entradas que coincidan con la consulta.
Si se desea mapear un campo de tipo enum en una entidad de JPA, puede hacerse de forma muy sencilla con la anotación @enumerated:
@Entity
public class MyEntity {
public static enum MyEnumType {
ONE_VALUE, OTHER_VALUE;
}
private MyEnumType myValue;
@Enumerated(EnumType.STRING)
private MyEnumType getMyValue() {
return myValue;
}
La anotación enumerated nos permite especificar EnumType.STRING o EnumType.ORDINAL, que almacenará en la base de datos los valores de la enumeración como una cadena con el nombre del valor de la enumeración o como el número de la posición en que se declara, respecivamente.
Para mapear enumeraciones más complejas en las que se desee controlar el valor específico que se almacena en la base de datos, es necesario recurrir a la definición de nuevos tipos usando Hibernate.
Una funcionalidad que me costó encontrar entre la documentación de screen es la posibilidad de asociar a una tecla por configuración varios comandos de screen. Para ello, se puede utilizar la keyword “eval”, seguido de los comandos entrecomillados. He aquí un ejemplo:
bind w eval "kill" "focus up"
Un caso de uso que puede ser necesario es redireccionar a la vista actual cuando una excepción es capturada mediante un exception handler definido en pages.xml. En mi caso se trataba del error producido por s:fileUpload cuando el tamaño de subida de un fichero es superior al definido en la configuración. El error hemos de tratarlo en el pages.xml dado que la excepción ocurre a nivel del filtro de seam.
El modo de hacerlo:
<exception class="org.jboss.seam.web.FileUploadException">
<redirect view-id="#{facesContext.externalContext.requestServletPath}#{facesContext.externalContext.requestPathInfo}">
<message severity="error">La subida de un fichero falló...</message>
</redirect>
</exception>
Una operación que he necesitado hacer en una función de PL/PGSQL es copiar una fila de una tabla en la propia tabla, pero haciendo modificaciones de alguno de sus campos. Lo ideal es no necesitar conocer el resto de los campos que van a quedar igual en la copia, únicamente nos interesan los campos a modificar. He aquí la solución:
DECLARE node tablaacopiar%rowtype; newNode tablaacopiar%rowtype; BEGIN FOR node IN SELECT * FROM tablaacopiar WHERE ... newNode := node; newNode.campo1='blahblha'; newNode.otrocampo='patatin'; INSERT INTO tablaacopiar SELECT newNode.*; END LOOP; END;
Este sábado estuve en un taller que organizaba hispalinux y el ayto de zaragoza: http://pinguinos.jornadaszaragoza.com/
Pingüino (http://www.hackinglab.org/pinguino/index_pinguino.html) es una placa basada en un PIC al estilo Arduino, y el taller consistía en el montado de varios ejemplos de la mano de Francisco Javier Suvires.
Después, Ramón Martinez Palomares (aka Rampa), nos hizo una breve introducción a una solución para generar números aleatorios basado en pingüino y que, con un coste muy reducido pasa tests como FIPS-140, ENT y diehard.. Increible lo que hizo con unas pocas resistencias, unos cuantos transistores y un pingüino…
Por mi parte me resultó muy divertido (al margen de momentos de pánico del estilo: emm…….¿como iba esto de los colores de las resistencias?, menos mal que google se acuerda de todo lo que vamos olvidando xD). He aquí un montaje de prueba:
