viernes, 23 de agosto de 2013

La rubias tambien tocan blues

Que el blues -y la guitarra- ha sido tradicionalmente un territorio masculino no es que sea precisamente un secreto. De hecho, no recuerdo ninguna guitarrista clásica de blues que haya tenido cierta notoriedad.

Asi que me está llamando mucho la atención que en los últimos tiempos Spotify me esté sugiriendo (con la fantástica característica de radio personalizada tomando como base una lista o un músico) a unas cuantas chicas que no lo hacen nada mal. Ni como cantantes ni como guitarristas.


Ana Popovic (sitio oficial, Wikipedia). Nacida en Belgrado aunque vive desde hace tiempo en Memphis. Lleva mas de 15 años de carrera musical y es probablemente la mas completa de las cuatro que os presento.


Joanne Shaw Taylor(sitio oficial, Wikipedia). Inglesa, con un estilo mas limpio que la Popovic aunque tampoco le hace ascos a tocar versiones de Hendrix (hay un buen montón de videos tocando Manic Depression). Tiene sólamente tres discos editados con los que ha conseguido unos cuantos premios.



Dani Wilde (Página oficial), otra británica que está codeándose con los mas grandes desde que en 2007 fuera descubierta por la casa de discos Ruf Records durante un pequeño concierto en el Royal Albert Hall. En 2011 realizó casi 180 conciertos por America y Europa que la han consagrado como una de las mejores chicas con guitarra de la actualidad. No es rubia, pero la incluimos en esta lista.



Samantha Fish (Sitio oficial), la mas joven y recién llegada al panorama musical. Hasta hace un año apenas era conocida fuera de Kansas City, pero se está abriendo camino a toda velocidad. Aún parece un poco verde técnicamente, habrá que estar pendiente de su progresión.



 

martes, 20 de agosto de 2013

Hendrik Röver & The Pilgrim Rose

Un poco de buen country Made in Spain para alegrar el dia con aroma de los Flying Burrito Brothers. Hendrik Röver es el lider de los históricos Del Tonos, y Pilgrim Rose una banda asturiana de puro Country con fiddle, banjo y mandolinas. Un lujo de disco que puedes comprar por unos míseros 6€



 

domingo, 18 de agosto de 2013

Los buenos propósitos

Mucha gente hace buenos propósitos -la mayoría incumplidos rápidamente- a principios de año. Dejar de fumar. Hacer algún curso de idiomas. Ir a un gimnasio. Los expertos los saben, y aprovechan la ocasión para bombardear con mensajes publicitarios que aprovechen la ocasion con las correspondientes ofertas.

En mi caso no recuerdo haberlo hecho nunca, o al menos no en los últimos años, en esas fechas navideñas. Por contra, este verano he estado en mi lugar habitual de los últimos años, un pueblecito donde no hay mucho que hacer y la tranquilidad es absoluta.

Este año no he podido correr por las mañanas los 4Km que solía hacer cada dia el año pasado primero por una fascitis plantar y luego por dolor en la rodilla por jugar en la arena, asi que he tenido que conformarme con dar algunas caminatas a primera hora del dia por un camino de tierra pŕoximo a la playa. Y eso ha hecho que tenga algún tiempo para darle algunas vueltas a la cabeza y pensar en algunas cosas que me gustaría cambiar. Una lista de buenos propósitos que ha surgido espontáneamente y que voy a poner por escrito aqui para no perderla de vista cuando el dia a dia me vaya arrastrando a la comodidad de dejar pasar un dia tras otro.

Sin un orden particular:

  • Dormir mas. Imprescindible. No puedo estar mucho tiempo como largas temporadas el año pasado, durmiendo a las 2:00 y despertando a las 6:00. Un dia, vale. Dos es una excepción. Mas imposible. Como siempre me falta tiempo se que esto es lo que mas me va a costar, asi que será en lo que ponga más esfuerzo. Mínimo 7:30h de sueño diario
  • Trabajar menos horas, trabajar mejor. Producir mas. Cuando en el punto anterior ponía ese horario no es precisamente porque estuviera de copas cada noche, sino por temas relacionados con el trabajo. Es lo malo que tiene el ser co-empresario de una micro-pyme. Muchas de esas horas fueron dedicadas a aprender Grails, Groovy y temas relacionados con metodologías ágiles. Y de esas no me quejo, pero si de las trabajadas en casa directamente relacionadas con proyectos de la empresa. Necesito producir mas en menos horas. Eliminar distracciones.
  • No todos los proyectos tienen porque ser para un cliente. Tengo unas cuantas ideas de proyectos que quiero hacer. No sé muy bien como, de donde sacar el tiempo, el dinero y los recursos para llevarlos a cabo. Pero se que si no intento hacer algunos de ellos de una forma u otra me arrepentiré en el futuro. No se si la forma será implicando a otros miembros de la empresa, haciendo una Π Week al estilo Kaleidos, en casa en ratos libres, o como. Lo que si que sé es que será
  • Tiempo libre. Lo necesito. Los últimos años han sido un sinvivir. Se acabó. No puedo y no quiero. En los ultimos tiempos, mis hijos han crecido sin que yo apenas ni me entere ni les haya prestado el 1% la atención que merecen. Nunca he sido muy familiar pero una cosa es eso y otra apenas ver a la familia a la hora de comer los fines de semana. Game Over.
    Leer. Salvo en vacaciones, no leo nada que no esté directamente relacionado con programación. Tambien se acabó. Tengo por terminar de este verano Pensar rápido, pensar despacio, Guerra y Paz y 1Q84. Y luego mas cosas. Por no hablar de volver a coger una guitarra de vez en cuando.
  • Andar. Deporte. No es que me quiera poner cachas, es que tras tantos años de hábitos perniciosos para las neuronas estos dos años y medio en los que he hecho un mínimo de deporte he llegado al convencimiento de que es la mejor forma de tener el cerebro despierto y en forma. Y eso es exactamente lo que quiero: Andar un par de kilómetros (perfecto además para pensar) y seguir corriendo ocasionalmente. Y si además puedo hacerlo sin el agobio de tengo que volver a casa lo antes posible para terminar no-se-que-cosa, mejor.

Ya. ¿Carta a los reyes magos?. ¿Pura lógica?. Seguramente parte de ambas. Mañana, de vuelta de vacaciones, empieza el reto, en un año veremos que he conseguido.



domingo, 11 de agosto de 2013

Relaciones en GORM (The Definitive Guide to Grails 2)

Desde que comenzamos en mi empresa con Grails, uno de los puntos donde estábamos un tanto inseguros era el tema de la forma en que se manejan las relaciones con GORM. Por una parte, nunca habíamos usado Hibernate ni ningun otro ORM, y por otro, siempre habíamos diseñado la base de datos y las relaciones entre las entidades de forma manual.

En estos dias de vacaciones estoy leyendo el (muy recomendable) libro "The Definitive Guide to Grails 2", con el que estoy afianzando algunos conceptos que ya he manejado en el ultimo año y estoy aprendiendo algunas otras técnicas que estoy seguro de que me me van a ser muy utiles en el corto plazo.

En particular, el capítulo 3 dedicado a las clases de dominio tiene un apartado sobre las relaciones entre las clases de dominio y el mapeo que se realiza en base de datos que me ha resultado especialmente claro, asi que voy a intentar resumirlo y traducirlo por aqui por si a alguien mas le puede ser de utilidad.

Partamos de las dos siguiente clases simples:

class Car {
  Engine engine
}

class Engine {
  Car car
}

Claramente tenemos una relación one-to-one simple: un coche tiene un motor y un motor tiene un coche. Ninguna de las dos clases es propietaria de la relación. Y probablemente esto no sea lo que necesitemos en nuestra aplicacion.

Si queremos (lo mas probable en el caso anterior) definir cual es la clase propietaria de la relación, deberíamos hacerlo de la siguiente forma, definiendo explicitamente que un motor pertenece a un coche:

class Car {
  Engine engine
}
class Engine {
  static belongsTo = [car:Car]
}

De esta forma decimos a Grails que el coche es la parte propietaria de la relación, que el motor pertenece al coche, y no al revés.

El parámetro [car:Car] de la propiedad belongsTo es un mapa (y podríamos incluir varios valores: [car:Car, otherClass:TheOtherClass, ....]). La clave del mapa (car) representa el nombre de la propiedad que se añadirá (y usaremos luego para recuperar datos) a la clase Engine. Con esta definición, conseguiremos tambien que cuando se realice el mapeo en base de datos, tengamos una foreign-key en la tabla CAR que referencia a la clave primaria (el ID) de la tabla ENGINE

Obviamente, en algunos casos puede ser deseable tambien disponer de la foreign-key en el otro sentido, esto es: tener la foreign-key en la tabla ENGINE referenciando a la clave primaria de CAR. La forma de hacerlo en definiendo la propiedad hasOne en la clase Car, de la siguiente forma:

class Car {
   static hasOne = [engine: Engine]
}


En algunas circunstancias podemos tener situaciones donde la relacion necesita un lado propietario de la misma, pero no se necesita tener la referencia (back-reference: el ID del propietario en la clase debil de la relación). Grails soporta este tipo de relación de forma similar al caso anterior, pero indicanto solamente el nombre de la clase en lugar de usar una mapa:

class Engine {
   static belongsTo = Car
}

Una de las aplicaciones mas claras de esta aproximación es que automatizan los borrados en cascada: cada vez que se borra un coche de la base de datos se borrará el motor asociado.

Las relaciones de uno-a-muchos se representan facilmente tambien en Grails. Supongamos que tenemos una aplicacion con Albums de música que tienen canciones (Song) y que pertenecen a un Artista. La definicion de estas tres clases podría ser algo asi:

class Artist {
  String name
  static hasMany = [albums:Album]
}

class Album {
  String title
  static hasMany = [songs:Song]
  static belongsTo = [artist:Artist]
}

class Song {
  String title
  Integer duration
  static belongsTo = Album
}

En el ejemplo anterior, un Artist tiene muchos Albums, y un Album perteneca a su Artist propietario. De la misma forma, un Album tiene muchas canciones, y cada cancion tiene su Album propietario. En cualquier caso, una canción no tiene referencia a su Album: dada una canción no podremos saber a que Album pertence, aunque desde los Albumes si que podremos obtener su lista de canciones.

Como vemos, la clase Artist tiene una propiedad, albums, que es una coleccion de objetos Album. El tipo de coleccion que Grails usa por defecto en estos casos es un java.util.Set , que es una coleccion sin orden. Si necesitas otro tipo de coleccion (por ejemplo: List o SortedSet que mantienen un orden, lo que puede penalizar el rendimiento) puedes hacerlo pero tendrás que declararlo explícitamente, por ejemplo:

class Album {
  String title
  static hasMany = [songs:Song]
  static belongsTo = [artist:Artist]
  SortedSet songs
}

Nota: para que este comportamiento funcione, la clase Song tiene que implementar el interface Comparable

No voy a entrar en la problemática del rendimiento que puede provocar el uso de estas propiedades, pero si que recomiendo echar un vistazo a estas dos entradas ( 1 y 2) de Burt Beckwith sobre las recomendaciones de usar el concepto de Bag de Hibernate para estas relaciones u otro tipo de técnicas.

Ultimos enlaces compartidos

Aerotrastornados - Blog Aeronáutico