No compila ...

Festival del Humor (V)

noreply@blogger.com (Pedro) — Mon, 07 May 2012 15:10:00 +0000

Código para copiar Lists

// (...)
List<Pais> escalas = (List) RemoteUtil.getSessionBean(Constantes.LISTA_ESCALAS, false);
List<Pais> escalasTemp = new ArrayList<Pais>();
if (escalas != null && escalas.size() > 0) {
    escalasTemp = new ArrayList(Arrays.asList(new Pais[escalas.size()]));
    Collections.copy(escalasTemp, escalas);
}
// (...)

Cortesía de E.B.

Compactando imágenes de disco en VirtualBox

noreply@blogger.com (Pedro) — Thu, 03 May 2012 22:30:00 +0000

Cuando se afronta la configuración de una máquina virtual, una de las dudas que se suelen plantear gira en torno a la definición de los discos virtuales. Hoy en día, todos los software de máquinas virtuales (VirtualBox, VMWare, ...) ofrecen la posibilidad de elegir si los ficheros de imagen de los discos virtuales van a ser estáticos o dinámicos.

Los discos virtuales estáticos reservan el espacio completo de la capacidad de la máquina virtual en el momento de su creación. Por el contrario, las imágenes dinámicas se inicializan con un tamaño pequeño y, según va siendo necesario más espacio, la imagen del disco dinámico va creciendo. Este crecimiento es siempre 'a más' , ya que por mucho que se libere espacio en el sistema guest la imagen no va a ver reducido su tamaño salvo que se realice un procedimiento de compactación .

En entornos virtualizados de producción la decisión más adecuada suele ser la definición de discos con tamaño estático.El rendimiento de este tipo de imágenes es más rápido y no se pierde rendimiento en reservas de nuevo espacio en el host .

Sin embargo, en entornos de desarrollo, en los que el espacio de los discos del host suele ser un factor limitante, suele ser más interesante reservarlos de manera dinámica.

Situación

En un entorno de trabajo con una máquina virtual con imágenes dinámicas es probable que en un cierto momento el disco crezca de tamaño - por ejemplo, en una instalación de un software - para después volver a ver reducido su tamaño. Cuando esto ocurre, la imagen no ve reducido su tamaño de nuevo.

Por ejemplo:

sobre una máquina Linux vacía, con un disco dinámico de tamaño máximo 20GB y tamaño real de 1GB, vamos a instalar un WAS. Para ello, es necesario copiar los binarios a la máquina (1,5 GB ) , descomprimirlos (4 GB) , e instalarlos ( 2 GB) . Además, durante el proceso de instalación se crean un conjunto de ficheros temporales que pueden ocupar algún giga más. Al terminar el proceso de instalación, es probable que el disco ocupe unos 10 GB, cuando realmente sólo harían falta unos 3 GB.

¿Para qué necesitamos un disco ocupando 10 GB en este caso? Podríamos borrar los ficheros que no usamos. Escribimos los comandos rm que procedan y dejaríamos la máquina con esos 3GB ocupados - por ejemplo, se podría comprobar con el comando df de Linux - .Pero el fichero de imagen sigue ocupando 10GB. ¿Cómo solucionarlo? Utilizando las herramientas de compactación del software de máquina virtual.

Compactando... (I)

Las herramientas de compactación que ofrecen tanto VMWare como VirtualBox localizan bloques en disco con ceros escritos, y liberan ese espacio del fichero de imagen dinámica.

Por ejemplo, la herramienta de VirtualBox tiene la sintaxis

C:\Program Files\Oracle\VirtualBox\VBoxManage.exe modifyhd <ficheroImagen.vdi> -compact

Si pasamos esta herramienta por nuestra imagen de disco gigante debería devolverla a los 3GB esperados. Sin embargo, al ejecutarla sobre la imagen de disco y después de un rato, vemos con gran pena que el tamaño permanece inmutable.

¿Por qué?

Por la forma en la que los sistemas operativos borran ficheros. Cuando un sistema operativo borra un fichero lo que suele hacer es eliminarlo de las tablas de asignación de ficheros, de manera que sus sectores vuelven a estar disponibles para nuevos ficheros. Sin embargo, el espacio de disco no se escribe con ceros.

¿Y entonces?

Pues habrá que escribir con ceros el espacio de disco no usado antes de compactar.

Zero-filling

Aunque en Windows la solución es análoga, nos vamos a centrar en la solución para Linux. Hay dos maneras principales de hacer la operación de escritura a cero de la información de los bloques de disco vacíos. O haciendo un wiping -borrado seguro- en cada operación de borrado de ficheros - que degrada mucho el rendimiento de la máquina virtual- , o haciendo una operación de mantenimiento de zerofilling de los bloques borrados antes de hacer la compactación. Esta será nuestra opción.

Los pasos siguientes son para CentOS / RHEL , aunque en otras distribuciones va a ser muy similar.

Como precondición, habrá que instalar la utilidad zerofree en el sistema guest , disponible en los repositorios 3rd party de casi todas las distribuciones.

Reiniciar la máquina virtual
Pulsar <ESC> en el menú de grub.
Seleccionar la opción en grub que arranque el sistema en modo rescue , o si no existe, localizar la opción que arranque el sistema de modo normal y pulsar la tecla <a> . Esto entrará el modo append de grub .
Añadir, al final de la linea, la palabra single . Esto hará que Linux arranque en modo single user, sin red, pero con la posibilidad de desmontar el sistema de ficheros raíz.
Una vez que el sistema haya arrancado y esté en el prompt - un signo de que todo ha ido correctamente es que llega al prompt sin pasar por una pantalla de login - , habrá que desmontar el sistema de ficheros y volver a montarlo en modo readonly. Para comprobar en qué sistema de ficheros está montado / habrá que lanzar un comando mount y comprobar la linea que contiene 'on / type'.

[root@virtual01 /]# mount/dev/mapper/vg_virtual01-lv_root on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
(...)

En el caso del ejemplo, el sistema de ficheros a compactar es /dev/mapper/vg_virtual01-lv_root , que es un volumen LVM, aunque sería exactamente igual con volúmenes IDE , /dev/hdxY , SCSI o SATA, /dev/sdxY , etc.
A continuación, habría que montar ese volumen en modo sólo lectura y lanzar el comando zerofill sobre el sistema de ficheros.

[root@virtual01 /]# mount -n -o remount,ro -t ext4 /dev/mapper/vg_virtual01-lv_root /
[root@virtual01 /]# zerofree /dev/mapper/vg_virtual01-lv_root

Sólo faltaría apagar la máquina

[root@virtual01 /]# shutdown -h -P 0

Una vez hecho esto, el sistema está listo para volver a intentar la operación de compactación.

Compactando... (y II)

Ahora si, podemos volver a intentar hacer la operación de compactación

C:\Program Files\Oracle\VirtualBox\VBoxManage.exe modifyhd <ficheroImagen.vdi> -compact
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%...

Si todo ha ido bien el fichero de imagen de disco tendrá ahora un tamaño muy similar al tamaño usado dentro del sistema de ficheros, y que se puede consultar desde el sistema guest con, por ejemplo para Linux, un df .

Generando entidades con Entity Framework

noreply@blogger.com (Manel) — Tue, 01 May 2012 18:00:00 +0000

La oficina es un foco de conversaciones y discusiones (absurdas la mayoría de las veces). El otro día un compañero me comentaba que estaba encantado trabajando con EF. Y yo le pregunté por curiosidad "¿Y cómo generas las entidades?" y su respuesta fue "¿Cómo que cómo?... desde el menú". Mi compañero desconocía que hay varias formas de generar varias formas de generar entidades con EF.

Data Base First y Model First.
Estos son las dos formas soportadas por el IDE. Data Base first es la aproximación más utilizada por los usuarios, se modela la base de datos y se utiliza el asistente de entity framework dejando todas las opciones por defecto.

Model First es muy parecido, desde el asistente del Entity Data Model, seleccionamos Empty model creamos el modelo. El diseñador cuenta con un sasistente para generar el script de la base de datos.

Plain Old CLR Objects (POCOs)
Una de las características más criticadas de la primera versión de EF fue que las entidades generadas derivaban de la clase EntityObject.
Las entidades de se generan mediante plantillas t4, estas plantillas se pueden cambiar o modificar. De esta manera, si nos interesa crear POCOs tan solo debemos indicarlo añadiendo una plantilla al proyecto.

Code First.
Desde la aparición del EF 4.1 existe una nueva forma de definir el mapeo de las entidades vía código. A esto los amigos de Redmond le han llamado CodeFirst.
Por defecto todo funciona con una convención predefinida.
Pero si queremos trabajar personalizando los nombres o con una base de datos legacy, CodeFirst nos permite definir los mapeos mediante dos formas, vía atributos o mediante código directo.
Supongamos este Modelo de datos:

Lo único que tenemos que hacer es crear las clases que necesitemos. En este caso para personalizar el nombre de la tabla o indicar la PK utilizaremos anotaciones

    [Table("Libros")]
    public class Libro
    {
        [Key]
        [Column ("IdLibro")]
        public int Id { get; set; }
        public string Titulo { get; set; }
        public ICollection<Autor> Autores { get; set; }

        public Libro()
        {
            Autores = new HashSet<Autor>();
        }
    }

    [Table ("Autores")]
    public class Autor
    {
        [Key]
        [Column("IdAutor")]
        public int Id { get; set; }
        public string Nombre { get; set; }
        public ICollection<libro> LibrosEscritos { get; set; }

        public Autor()
        {
            LibrosEscritos = new HashSet <libro>();
        }
    }

Ahora lo que debemos generar es el DataBaseContext para que EF sepa qué clases debe mapear

    public class LibrosContex : DbContext
    {
        public LibrosContex()
            : base("ConnectionStringName")
        {

        }
        public DbSet<Libro> Libros { get; set; }
        public DbSet<Autor> Autores { get; set; }
    }

Desgraciadamente, a fecha de hoy la personalización mediante atributos de EF no permite personalizar el nombre de la tabla intermedia. Esto me permite completar el ejemplo utilizando el API fluido para la configuración del mapeo, indicando el nombre de la tabla intermedia en la relación Many to Many.

        protected override void OnModelCreating(DbModelBuilder modelBuilder)
        {
            modelBuilder.Entity<Libro>()
                .HasMany<Autor>(l => l.Autores)
                .WithMany(a => a.LibrosEscritos)
                .Map(t =>
                {
                    t.MapLeftKey("IdAutor");
                    t.MapRightKey("IdLibro");
                    t.ToTable("AutoresLibros");
                });
            
        }

El uso del contexto generado con code first es igual que el generado por los asistentes

static void Main(string[] args)
        {
            using (var dbContex = new LibrosContex())
            {
                var libro = new Libro();
                libro.Titulo = "El Hobbit";

                var autor = new Autor();
                autor.Nombre = "J.R.R. Tolkien";

                libro.Autores.Add(autor);
                autor.LibrosEscritos.Add(libro);

                dbContex.Autores.Add(autor);

                dbContex.SaveChanges();

                var n = dbContex.Libros.Count<Libro>().ToString();
                Console.WriteLine("Libros en BD: " + n);
                Console.ReadLine();
            }
        }

Resumiendo
Entity Framework nos permite elegir varias estrategias de generación de las entidades y los mapeos: Data Base First, Model First y Code First. Además de poder elegir si las entidades son POCOs o no.
Personalmente prefiero code first, aunque sea por la sensación de control o de menos magia que el resto de formas.

JRebel Yell

noreply@blogger.com (Pedro) — Mon, 23 Apr 2012 18:52:00 +0000

Hace cosa de un mes y pico me preguntaron en el chollo si habíamos usado JRebel para desarrollar portlets en Liferay. ¿Jotaqué? ... Y me puse a buscar en el google qué era eso.

Resulta que JRebel es un agente Java que evita despliegues en servidores de aplicaciones Java porque permite sustituír código en caliente en toda una manada de servidores de aplicaciones como Tomcat, Jboss, WAS, Jetty, Resin, Netweaver, etc. Y tiene plugins para una buena parte de los grandes IDE para Java: Eclipse, Netbeans, InteliJ, JDeveloper, ...

Soy un asiduo seguidor de Eclipse, y seguro que, como yo, muchos nos hemos encontrado con las limitaciones en el reemplazo de código en caliente que obliga a redesplegar las aplicaciones en el contenedor una y otra vez. Cambiar el cuerpo de método estático, añadir un método, definir una constante, modificar el contexto de Spring, ... nunca más!! JRebel al rescate!! ... o no...

JRebel es una buena herramienta con una gran campaña de marketing. ¿Marketing? Si, porque es de PAGO. Y en mayúsculas. Desde la licencia standalone por 130$/año y usuario hasta la flotante con servidor de licencias por 350$/año y usuario. Sí, es cara.

Pero ellos lo argumentan diciendo que te puedes ahorrar 10 minutos de despliegues por cada hora de desarrollo.

Todo su marketing se enfoca en esto.

Y yo no me lo acababa de creer, así que me registré en una trial de un mes y empecé a usarlo para desarrollar portlets en Liferay. Instalé el plugin de JRebel en Eclipse, añadí el plugin de maven al pom.xml , configuré el agente en el Tomcat y empecé a usarlo.

La primera impresión fue genial. Magia. Pillaba los cambios. Así de fácil.Yo cambiaba una clase o una JSP de mi portlet y los cambios aparecían al segundo. Genial. Flipa. OyeManelmiraesto. Nomoredeploys.

El entusiasmo sólo dura un par de horas, y los defectos empiezan a notarse. Liferay tarda como el doble en arrancar. Y se ha vuelvo más gordo y lento.

El primer portlet de prueba era muy básico, pero los proyectos que solemos hacer -normalmente basados en Maven- suelen tener varios módulos con varias librerías, y los cambios sólo se aplicaban si se hacían en el proyecto web. Los cambios en superclases o interfaces tampoco funcionan. Y clases nuevas sólo se detectaban a veces. Evidentemente no funciona con SWT. Ni tampoco con GWT.

A su favor, sí que se detectan los cambios en las JSP e incluso en el contexto de Spring. Tiene plugins también para Hibernate y JSF - que no he probado - .

El plugin se encarga de recordarte un par de veces al día todo el tiempo que has ahorrado en despliegues contabilizando como despliegue cada guardado de un fichero con el servidor levantado. Y sí, en efecto, en una jornada puede contabilizar dos o tres horas. Pero me parece algo exagerado contarlos todos. Sobre todo teniendo en cuenta que hay días que no hago ni un solo despliegue. Sólo programar.

¿Que se evitan despliegues? Pues claro. Es un ahorro considerable de tiempo. Pero no siempre estamos haciendo corrección de bugs, con lo que las fases de despliegue continuado no son la tónica general.

Ya terminó la trial y hoy me llamó un comercial que me puso en un serio aprieto con mis habilidades con el inglés. Sorprendente que me llamasen, si. Y por eso estoy escribiendo esto.

Se lo merecen, tienen un buen producto. Aunque no creo que mi empresa lo vaya a comprar. Como puse en el correo que mandé hace un par de semanas a la persona que me preguntó sobre él:

Es una herramienta ÚTIL, PRÁCTICA, especialmente indicada para programadores productivos para los que los despliegues en el servidor suponen una rotura de un ritmo de trabajo alto. Utilizarla requiere EXPERIENCIA en desarrollo para darse cuenta rápidamente de cuándo está desplegando automáticamente y cuándo no. Puede suponer una mejora notable en la productividad de ciertos programadores en determinados tipos de desarrollos.

Y es CARA, cuesta 349 euros por año y programador para entornos empresariales. ¿Vale la pena ese coste para hacerlo extensible a todos los programadores? No lo creo, sobre todo teniendo en cuenta que hay otros factores como un mejor equipo informático o un monitor más grande que mejorarían en mayor medida la productividad de los programadores y que tienen un coste similar o menor.Eso si, hay una versión SOCIAL no válida para uso comercial y que yo tengo instalado en el Eclipse del equipo de mi casa.

Intentando entender REST

noreply@blogger.com (Manel) — Mon, 09 Apr 2012 22:00:00 +0000

Desde la primera vez que escuché el término servicio REST, siempre lo han utilizado como contrapunto a los servicios web SOAP. Es decir que un servicio REST es una url que recibe peticiones y responde sin usar XML, usando principalmente JSON. Además, si para realizar las peticiones utiliza los verbos http: post, put, delete y get se dice que es RESTful.

"Una mentira repetida mil veces termina siendo verdad" - Goebbels.
No fue hasta que escuché el podcast Hanselminutes: Misunderstanding REST with Mike Amundsen cuando descubrí que REST no era lo que me estaban contando.
REST es un estilo de arquitectura o de diseño informático. No existen unas normas o reglas fijas que definan claramente qué es REST o qué no.
Dentro de este estilo arquitectónico Roy Fielding es considerado por muchos como el referente. Fielding fue el primero en utilizar el término REST en su trabajo para su doctorado: "Architectural Styles and the Design of Network-based Software Architectures". En concreto en el capítulo 5: Representational State Transfer (REST)

Para explicar este estilo Fielding utiliza HTTP como ejemplo. En el documento se enumeran una serie de condiciones:

Debe ser Cliente/Servidor
La comunicación debe realizarse sin estado, es decir que una petición debe contener toda la información necesaria para que el servidor la procese. Y lo mismo aplicado a la respuesta.
La información debe ser explicita o implícitamente cacheable
Interfaz uniforme:

Los recursos deben estar identificados (en http los recuros se identifican por la URI)
La manipulación de los recursos se realiza mediante la representación (en http los mensajes indican el tipo de contenido, por ejemplo text/html, application/xmlapplication/xml)
Los mensajes deben ser autodescriptivos: si requiere autenticación, si son cacheable, etc.
Y un último punto que no me quedó muy claro "hypermedia as the engine of application state" y que desarrolla aquí

El sistema debe permitir añadir capas, de tal forma que un cliente no sepa si se está conectando directamente al servidor. Por ejemplo, el sistema debe permitirla implantación de un balanceador de carga.
Código bajo demanda, como el javascript en html, el cliente se descarga el código y luego lo ejecuta. (Esta condición no es obligatoria para que un sistema sea REST.)

¿Qué es REST?
Si he de ser sincero no me ha quedado de todo claro. Lo que sí puedo decir es que REST no es un sistema para hacer CRUDs.
HTTP es el mejor ejemplo de REST y así que un API WEB que siga el estilo REST debe aprovechar al máximo todas las características de HTTP, utilizar metadatos para de las cabeceras para indicar comportamientos, resultados de operaciones, datos de autenticación o de formatos del cuerpo. Por otro lado el cuerpo solo debe utilizarse para intercambiar información.

La pregunta que yo me hago es: La gente utiliza el termino REST o RESTful para decir que un servicio web no es SOAP, cuando la definición de REST de Fielding es dice otra cosa completamente diferente, ni habla de servicios web. ¿Merece la pena o el esfuerzo explicar que están utilizando el término de forma incorrecta? ¿o como ya está expandida esta acepción del término no merece la pena meterse en a discutir estas cosas si al final nos estamos entendiendo?

NHibernate y Entity Framework

noreply@blogger.com (Manel) — Mon, 20 Feb 2012 07:00:00 +0000

A diferencia del mundo Java, donde Hibernate es un estándar de facto, los ORMs en .Net no gozaron de fama hasta la llegada de Entity Framework.
A pesar de la existencia de NHibernate, Microsoft decidió crear un su propio ORM. Y aunque Entity Framework no gozó de buena salud hasta el lanzamiento de su segunda versión (EF4), su popularidad y su uso ha sido muy superior a un producto mucho más maduro como NHibernate.

Desde mi modesto punto de vista el uso de EF tiene dos peligros:

Las herramientas y el Api de EF son muy intuitivos y permiten a un desarrollador sin experiencia trabajar sin preocuparse de lo que sucede por debajo.
Un desarrollador familiarizado con (N)Hibernate puede pensar que los dos ORM se rigen por los mismos principios y se comportan de manera similar.

Cualquiera de los dos casos nos lleva a un escenario, donde el desconocimiento el comportamiento del ORM podría terminar desencovando en una aplicación con pies de barro.

El otro día, comiendo con un compañero que está desarrollando una aplicación con EF, hablamos de mis post sobre (N)Hibernate y las diferencias que había entre los dos ORMs tras leer mis post y comparar con su experiencia en el trabajo. Lo cierto es que me sorprendió lo diferente que se pueden llegar a comportar.

Como ya hemos visto con anterioridad, NHibernate utiliza una session para comunicarse con la base de datos. Se podría decir que el Object Context de Entity Framework es el equivalente a la session de NHibernate, pero en ocaciones las medias verdades son muy peligrosas.

Conexiones a base de datos
Abrir y cerrar conexiones contra la base de datos es algo muy costoso.
La sessión de NHibernate la abre cuando la necesita y la cierra al terminar una session o al hacer commit en una transacción. Desgraciadamente el comportamiento por defecto de Entity Framework dista mucho de ser el mismo, segun la msdn: "By default, the object context manages connections to the database. The object context opens and closes connections as needed. For example, the object context opens connection to execute a query, and then closes the connection when all the result sets have been processed."
Es decir que por defecto se abre una conexión por cada consulta que se lanza. Afortunadamente la mayoría de proveedores de ADO.Net incluyen un pool de conexiones, pero de todas formas, es importante ser consciente que a nivel de ADO.Net EF abre y cierra una conexión por defecto.

Recuperando objetos
En anteriores entradas ya hemos visto como recupera los objetos NHibernate, la session tiene una caché de primer nivel, donde se almacenan todos los objetos, NHibernate decide si cuando le piden un objeto debe ir a buscarlo a la base de datos o no.

La política de recuperación de objetos del Objet Context de EF es diferente. Veamos un poco de código:

    static void Main(string[] args)
    {
        NHibernateEFEntities dbContex = new DBContext ();

        Pelicula pelicula1 = dbContex.Peliculas.First<pelicula>();
        Console.WriteLine(pelicula1.Titulo);

        pelicula1.Titulo = "Modificado";
                        
        Pelicula pelicula2 = dbContex.Peliculas
                                .Where(x => x.IdPelicula == pelicula1.IdPelicula).First<pelicula>();

        Console.WriteLine("¿son el mismo objeto? {0}", pelicula1.Equals(pelicula2));

        Console.WriteLine(pelicula2.Titulo);
            
        Console.ReadLine();
    }

¿Cómo se comportará EF con este código? Supongamos que la primera película que se recupera de la base de datos es Casablanca. En la línea 8 le cambiamos el nombre por "Modificado" y después la recuperamos de la base de datos. Al ejecutar la línea 12 el programa dice que pelicula1 y pelicula2 son iguales y al ejecutar la línea 14, por consola aparece "Modificado". Parece que esta vez EF y NH se comportan igual, pero consultemos el Log de EF:

EntityFramework.NHibernateEFEntities Information: 0 : Executing 1: 
SELECT TOP (1) [c].[IdPelicula] AS [IdPelicula], [c].[Titulo] AS [Titulo], [c].[IdGenero] AS [IdGenero], [c].[Ano] AS [Ano] FROM [dbo].[Peliculas] AS [c]

EntityFramework.NHibernateEFEntities Information: 0 : Finished 1 in 00:00:00.0008783: [DbDataReader(IdPelicula:int, Titulo:varchar, IdGenero:int, Ano:int)]

EntityFramework.NHibernateEFEntities Information: 0 : Executing 2: 
SELECT TOP (1) [Extent1].[IdPelicula] AS [IdPelicula], [Extent1].[Titulo] AS [Titulo], [Extent1].[IdGenero] AS [IdGenero], [Extent1].[Ano] AS [Ano] FROM [dbo].[Peliculas] AS [Extent1] WHERE [Extent1].[IdPelicula] = @p__linq__0 { p__linq__0=[Int32,0,Input]1 }

EntityFramework.NHibernateEFEntities Information: 0 : Finished 2 in 00:00:00.0002692: [DbDataReader(IdPelicula:int, Titulo:varchar, IdGenero:int, Ano:int)]

¿Sorprendido? EF ha ejecutado dos consultas, pero en los resultados parece como si supiera que ya tenía en memoria el objeto que se cargó en la primera query. La respuesta de lo que ha pasado está, como casi siempre, está en la msdn.
EF se comporta de forma muy diferente a NH a la hora de recuperar los objetos en de la base de datos. Lo más importante que debemos saber es que siempre va a realizar la consulta contra la base de datos. Lo que condiciona el comportamiento de EF a la hora de devolver el objeto es el MergeOption de la consulta:

AppendOnly: Es la opción por defecto, si una entidad recuperada de una consulta ya existen en el contexto, se devuelve la del contexto y no la recuperada de la base de datos
OverwriteChanges: Como su propio nombre indica si el objeto existe en el contexto, se sustituye por el que se ha recuperado de la base de datos.
PreserveChanges: si se recupera de la base de datos una entidad cargada previamente pueden ocurrir dos cosas:

Si el objeto no había sido modificado, se sustituye por el nuevo
Si se había modificado se mantienen los cambios en el objeto asociado al contexto.

NoTracking: EF no hace seguimiento del objeto.

En definitiva EF siempre hace las consultas de la base de datos y según el MergeOption se recuperan unos datos u otros, si a esto le sumamos a que por defecto el ObjectContext abre una conexión por cada consulta. Si el programador que usa EF no conoce estas características (ya sea por desconocimiento o suposiciones incorrectas) puede tener problemas de rendimiento en determinados escenario a la hora de poner un proyecto en producción. Recordad, los ORMs no son magia, y siempre hay una base de datos por debajo.

Repositorio vs DAO

noreply@blogger.com (Manel) — Wed, 25 Jan 2012 23:14:00 +0000

Una de las partes más importantes de una aplicación, tanto en Java como en .Net, es el acceso a datos. Las dos estrategias más famosas son el DAO y el Repositorio, aunque algunos los confunden, son estrategias diferentes que dan solución al mismo problema.

Patrón DAO
DAO son las siglas de Data Access Object, pero para entenderlo mejor vayamos a las fuentes J2EE Core Paterns:
"Use a Data Access Object (DAO) to abstract and encapsulate all access to the data source. The DAO manages the connection with the data source to obtain and store data. (...)
The DAO implements the access mechanism required to work with the data source.(...)
The DAO completely hides the data source implementation details from its clients."

En román paladino: el DAO es el responsable de componer los datos de sistemas externos, en caso de una base de datos, será el responsable de componer y ejecutar las consultas SQL necesarias para hacer las operaciones. Por ejemplo:

    interface IFacturaDAO
    {
        Factura Get(int id);
        void Save(Factura factura);
        void Delete(Factura factura);

        ICollection<Factura> getFacturasSinCobrar();
    }

Más o menos este es el ejemplo clásico, un interfaz que nos permite realizar como mínimo las operaciones de un CRUD.

Patrón Repositorio
Si para el patrón DAO consultamos J2EE Core Patterns, para la definición del repositorio debemos acudir a Martin Fowler:
"Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects"

Aunque la definción de los colaboradores de Fowler (Edward Hieatt y Rob Mee) es breve y clara, creo que deja muchos interrogantes abiertos. Únicamente indica que se debe implementar un interfaz similar al de una colección y que por debajo ya se encargará acceder a los datos.

    interface IFacturaRepositoy : ICollection<Factura>
    {
        ICollection<Factura> GetFacturasSinCobrar();
    }

En este ejemplo, además del interfaz de ICollection, el respositorio de facturas implementa una consulta que recupera las facturas sin cobrar. Pero al implementar ICollection hay que sopesar si se debe implementar el método Clear(), yo personalmente no lo haría ;)

Las ¿consultas son reglas de negocio? ¿o es parte del acceso a datos?
Si os fijáis en los ejemplos anteriores, tanto el DAO como el repositorio de factura exponen Este es un debate muy importante que condiciona el desarrollo de la capa de acceso a datos y la implementación de las reglas de negocio.
Utilices DAOs o Repositorios, si crees que las consultas forman parte de las reglas de negocio y quieres mantener la independencia entre negocio y acceso a datos, ¿como puedo escribir las querys, sin usar SQL en la capa de negocio? La solución nos la ofrece otra vez Fowler con el patrón Query Object: "An object that represents a database query"
Si crees que las consultas son solo consultas o que programar una implementación de query object es un esfuerzo innecesario, siempre puedes escribir las consultas dentro de tu DAO (incluso dentro del repositorio, estirando un poco la interpretación del patrón).
Algunos de vosotros pensareis, este Query Object se parece mucho a un criteria de Hibernate. Sí, tenéis razón, se podría decir que el api de criteria es una implementación de Query Object. ¿Y por qué no usarlo en la capa de negocio? Porque si usas criteria fuera de la capa de acceso a datos, estas añadiendo una referencia a Hibernate (a un mecanismo de acceso a datos) en tu capa de negocio. Pero de esto hablaremos más tarde en este post (la tercera vía)
En .Net Linq nos permite hacer implementaciones limpias del patrón repositorio. Linq nos permite hacer consultas sobre colecciones IQueriables y está soportado por el framework. Pero ¿exponer IQueriable fuera de nuestro acceso a datos nos permite mantener a nuestras entidades ignorantes de los mecanismos de persistencia? Sí y no.
En teoría sí ya que Linq forma parte del framework, pero en la realidad es que, de esta forma, se limita el número de opciones a disposición del programador: NHibernate, Entity Framework, o algun otro sistema que soporte Linq. Porque el coste de implementar IQueriable en un sistema que utiliza Ado.Net es altísimo y no creo que merezca la pena.
En definitiva se podría decir que se aplican las reglas de negocio en dos momentos de la aplicación:

al aplicar condiciones para recuperar los datos (recuperar las facturas no pagadas)
Antes de persistir los cambios en la base de datos.

Con la palabra "Antes" ya queda claro que es en la capa de negocio donde se deben aplicar las validaciones, cambios de estado, etc. la duda está a la hora de recuperar los datos ¿dentro o fuera del acceso a datos?

Tercera vía: los ORM ya nos abstraen de la base de datos.
La gran ventaja de los patrones DAO y repositorio es que abstraen al resto del código de la base de datos, mediante estos mecanismos, si cambia la base de datos no tenemos que tocar la implementación de las reglas de negocio.
Al utilizar ORMs como Hibernate o Entity Framework la abstracción con la base de datos está asegurada. Si ya tenemos una capa de abstracción ¿por qué añadir otra? evitar perder funcionalidad que ofrece el ORM directamente. De esta forma el código es más seco (DRY), incluso se podría decir que cumple el principio de responsabilidad única, ya que el encargado de guardar el objeto es el ORM. Por último, al no tener DAOs ya no tienes la duda de ¿la consulta es una regla de negocio o forma parte del acceso a datos? al usar el ORM directamente también se usan directamente sus mecanismos de consulta.

Reflexiones finales
En una aplicación empresarial, donde es importante tener organizado el código, donde muchas cosas pueden cambiar a petición del cliente y además el equipo estará formado por varias personas, intentaría mantener la capa de acceso a datos completamente aislada, es decir que usaría DAO o Repositorio.

En .Net dudaría si implementar repositorios exponiendo IQueriables ya que muchos controles del framework, paginan y ordenan estas colecciones.
En Java utilizaría DAOs sin lugar a dudas, no implementaría Query Objects, dejando las consultas en el DAO.
Si estas en una empresa con personas que programan en Java y .Net un DAO con hibernate creo que es la mejor solución.

El uso directo de un ORM lo dejaría en proyectos pequeños o medianos, con una persona desarrollando y que requieran cambios rápidos. Aunque eso es un riesgo en un entorno empresarial, ya que desaparece esa persona, y lo que para unos es orden, para otros es caos.

¿Y tu qué opinas? ¿cómo plantearías la estrategia de acceso a datos de una aplicación?

RWJ. Keep it simple!!

noreply@blogger.com (Pedro) — Thu, 19 Jan 2012 13:52:00 +0000

"La belleza de lo simple"

boolean orderByAsc = false;
if (orden.equals("asc")) {
    orderByAsc = true;
}

El proyecto que estoy sufriendo está lleno de cosas así. ¿El programador no podría haber hecho algo tan fácil como... ?

boolean orderByAsc = "asc".equals(orden);

Y además, no petaría si orden fuese null.

La base de datos ¿Fin o Medio?

noreply@blogger.com (Manel) — Mon, 16 Jan 2012 23:03:00 +0000

Cuando se plantea un desarrollo a medida, una de las primeras preguntas que se hace es: ¿Qué base de datos se va a utilizar?
Aunque creáis que no, tomar la base de datos como un medio o como un fin, condiciona en gran medida el desarrollo del sistema.

Base de datos como Fin
Si consideramos que la base de datos es la parte más importante de la aplicación, nos preocuparemos de que los datos sean fácilmente legibles. En primer lugar diseñaremos un modelo de datos, que posteriormente se traducirá a clases.
La base de datos será el centro del negocio, otras aplicaciones podrían atacar directamente a nuestra base de datos.

Base de datos como Medio
Desde este punto de vista, la base de datos se considera como un mero sistema para persistir los objetos de negocio de nuestra aplicación
Son los objetos de nuestra aplicación los que realmente ofrecen valor, la consulta de datos de nuestro sistema se debe realizar mediante una capa de servicios que desarrollaremos nosotros, el acceso directo a base de datos podrías dar como resultado lecturas incorrectas.
Adaptaremos el modelo de datos a las necesidades de nuestro código, primando el diagrama de clases sobre modelando los datos.

En los últimos años, estamos asistiendo al proliferación de las bases de datos documentales. Esta movimiento se podría considerar como el punto extremo del uso de la base de datos como medio. Ya que de esta forma abandonamos toda la experiencia y el conocimiento que ya existe en las bases de datos relacionales, por un sistema menos estándar.
Lo cierto es que esta moda me recuerda a las bases de datos orientadas a objetos, de las que tanto se hablaba en los 90, mientras que hoy en día parece que nadie se acuerda de ellas.

Aunque personalmente considero las bases de datos como medio y no como fin, ¿por qué?
Los objetos son los que contienen la información relevante, los objetos no son nadie sin las reglas de negocio a aplicar, que las tengo en las clases, no en la base de datos (nada de procedimientos almacenados, funciones de base datos o trigers). Si alguien quiere acceder a mis datos que me lo pida a través de una capa de integración. Mis datos los toco yo, nadie más.
Eso no significa que no use características de las base de datos, quizás la más importante sea la transaccionalidad, delego en ella la generación de ids.

Aunque esta aproximación no siempre se puede aplicar, por ejemplo en grandes empresas con bases de datos enormes que alimentan a varias aplicaciones y con un departamento de administración de base de datos. Muchos consideran que trabajar con DBAs es un suplicio por las restricciones que imponen, pero en modelos realmente grandes, con millones de registros, que alguien conozca como se comporta la base de datos y que nos indique como diseñar las tablas para evitar problemas de rendimiento es una ventaja.

¿Y tu qué opinas? ¿Modelas primero la base de datos y en ella basas tus objetos? ¿Comienzas por el diagrama de clases? ¿o eres de los aventureros que se adentra en las bases de datos documentales?

Abstracción, aplicaciones con pies de barro

noreply@blogger.com (Manel) — Tue, 10 Jan 2012 21:17:00 +0000

Cuando desarrollamos aplicaciones, utilizamos varios mecanismos de abstracción que nos permiten, entre otras cosas, centrarnos en problemas funcionales, abstrayendonos de ciertos problemas técnicos. Por ejemplo con java o con .net un desarrollador no suele preocuparse por la gestión de memoria porque el recolector de basura de cada plataforma se encarga de eso.

Los propios lenguajes de programación no mas que abstracciones que permiten comunicarnos de forma sencilla con las máquinas.

La abstracción ha permitido que más desarrolladores puedan trabajar, ya que el nivel de conocimiento necesario para hacer el trabajo ha disminuido. Si tuviésemos que trabajar en ensamblador ¿cuanta gente sería capaz de software de calidad?

La abstracción bien entendida
Estamos viviendo una época que pasará a los anales de la historia, seguramente en unos años el final del siglo XX y el principio del XXI se conocerá como La revolución informática. Esta revolución no sería posible sin la abstracción, que permite que mucha gente pueda usar los ordenadores de diferente manera y cada vez con menos conocimiento.

Pero nunca debemos olvidar qué es lo que estamos usando o de lo qué nos estamos abstrayendo. A pesar de utilizar lenguajes que nos abstraen del comportamiento del micro procesador o del concepto de memoria, no podemos olvidarnos que estos elementos condicionan de forma muy importante el resultado.

Creo que un desarrollador debe conocer con un cierto nivel de detalle el comportamiento de la última capa de abstracción. Por ejemplo, un desarrollador web debe conocer http, qué pasa cuando se hace un post, qué es una petición ajax, etc.

Aplicaciones con pies de barro
Es muy importante tener afianzados conocimientos básicos sobre la tecnología que usamos, porque podremos evitar muchos problemas conociendo el contexto en el que trabajamos.
Microsoft creó Asp.Net WebForms como una forma de acercar de forma casi transparente a los desarrolladores de Winforms al entorno web. Con un Visual Studio no necesitas saber http, ni html, ni nada, tan solo arrastrando cajitas y con los asistentes incluidos en el IDE, puedes llegar a hacer aplicaciones de forma relativamente sencilla y rápida.
Por ejemplo al dibujar un botón, tan solo hay que hacer doble click sobre él para abrir una ventana donde pueda condificar la operación necesaria. Esta magia oculta el submit del form, el código funciona y todos felices y contentos.
Creo que ASP.Net WebForms es un gran framework de desarrollo web (a pesar de lo que muchos opinan), pero esta abstracción puede llegar a ser muy peligrosa en malas manos, ya que el desconocimiento de http puede provocar que se comentan errores, provocando problemas de rendimiento y de otra índole.

En el mundo java el uso de Hibernate es casi el estándar de acceso a datos. Este ORM oculta las comunicaciones de la base de datos, pero el desarrollador nunca debería olvidar que al final lo que se ejecuta son instrucciones SQL. Problemas muy comunes en los ORMs, como el n+1 select, vienen provocados por el desconocimiento de la abstracción.
El acceso a datos es una de las partes más importantes de la aplicación, un error en este punto puede provocar problemas catastróficos muy difíciles de solucionar.
Un ORM no es una tecnología trivial, su uso en cada aplicación debería ser estudiado con mucho cuidado y no usarse a la ligera. Como es un estándar de facto, muchos desarrolladores lo usan sin ser conscientes de lo que hacen.

Conocer la técnica de ORM es fundamental, no es una opción.

Nunca olviden que todo termina en una base de datos relacional; empezar con objetos y pensar OO no significa que tengamos que olvidarnos que el data base existe.

Estas dos frases han sido extraídas de un post de Fabio Maulo, donde da consejos a los nuevo usuarios de NHibernate y que pueden aplicarse a los desarrolladores de java.

Debemos evitar hacer aplicaciones con pies de barro, que se basan en algo que desconocemos, que se usa por costumbre, o porque a otros les ha funcionado, pero que no sabemos lo que hace y que en cualquier momento se puede desmoronar.

Resumiendo, no debemos basarnos nunca en conocimiento casual, en algo que hace magia pero que no tenemos ni idea de cómo lo hace.

Hibernate y NHibernate (II) Objetos y sesión

noreply@blogger.com (Manel) — Wed, 04 Jan 2012 00:00:00 +0000

En entradas anteriores de NoCompila.com:

Estudiamos como Hibernate y NHibernate es capaz de decidir si debe hacer un Insert o un Update de un objeto. Esta decisión la toma en base al id. Después de escribir el post y revisando la documentación, he descubierto (N)Hibernate también puede utilizar una propiedad version para decidir entre Insert y Update.
Vimos que Hibernate y NHibernate se comportan igual, o prácticamente igual, a la hora de generar insert o updates.

Después de unas cuantas charlas con compañeros he decido ampliar el post y hablar sobre la sesión y los objetos, creo que es un tema fundamental para entender el funcionamiento del ORM.
Como lo que vamos a ver son cosas básicas que son iguales en java y en .net solo voy a poner el código en c#, además voy a utilizar unas versiones antiguas (c# 2.0 y NHibernate 2.1) para utilizar métodos y sintaxis lo más comunes y facilite la compresión.
Además vamos a utilizar la clase y el mapeo del post anterior, os los recuerdo:

    class Entidad
    {
        private int _id;
        private string _nombre;

        virtual public int Id
        {
            get { return _id; }
            set { _id = value; }
        }

        virtual public string Nombre
        {
            get {return _nombre;}
            set { _nombre = value; }
        }

        public Entidad()
        {
        }
        public Entidad(string nombre)
        {
            Nombre = nombre;
        }
    }

La sesión
La sesión de (N)Hibernate es, según la documentación del ORM, una implementación del patrón Unit of Work. La sesión controla todos los cambios que se realizan a los objetos que tiene asociados y sabe si tiene que hacer un delete, update o insert.
Además funciona a modo de caché, ya que al hacer las peticiones de base de datos a través de ella esta puede saber si el objeto ya está cargado en memoria sin necesidad de lanzar una select.
¡¡¡OJO!!! a la sesión no se pueden asociar dos objetos del mismo tipo con el mismo id. de la misma forma que una base de datos no puedes insertar dos registros con la misma pk en la misma tabla.

Estado de los Objetos
Los objetos en (N)Hibernate pueden estar en tres estados:
Transient: es un obejto que no está asociado a una sesión de (N)Hibernate. Es decir cuando creamos un objeto con un new
Persistent: es un objeto que está asociado a una sesión. Al hacer flush() en la sesión, el estado del objeto se envia a base de datos.
Detached: es un objeto asociado a una sesión que ya no existe.
para más información cosultad la documentación oficial

Asociando objetos a la sesión
Hacer que un objeto sea Persistent es relativamente sencillo, como es de imaginar el objeto session nos ofrece varios métodos:

save: se utiliza cuando se envía un objeto nuevo a la base de datos. Por ejemplo cuando creamos un objeto que no existe en la base de datos. Lo que hace save es ponerle un id al objeto, según la política que esté definida en el mapeo.
update: sirve para asociar un objeto que ya sabemos que existe en base de datos en la sesión. Es decir, a diferencia de save, update no le asigna id al objeto.
SaveOrUpdate: lo vimos en el post anterior, asocial al objeto a la sesión, decidiendo si usar save o update

Veamos un ejemplo:

            Configuration cfg = new Configuration();
            cfg.Configure();
            ISessionFactory sf = cfg.BuildSessionFactory();
            ISession session = sf.OpenSession();

            Entidad e1 = new Entidad("UNO"); //creamos un objeto transient
            session.Save(e1); //el objeto se vuelve Persistent

            session.Flush();//Se lanza un Insert en la base de datos
            session.Close(); //e1 pasa a ser detached 

            session = sf.OpenSession();

            Entidad e2 = new Entidad(); //se crea el objeto transient
            e2.Id = e1.Id;
            e2.Nombre = "DOS";

            session.Update(e2); // e2 se vuelve Persistent

            e2.Nombre = "TRES";

            session.Flush ();
            session.Close(); //e2 pasa a ser detached

            sf.Close();

¿Cuantas querys se lanzan contra la base de datos?¿y en qué momento?
Se lanzan tan solo dos querys contra la base de datos, un insert y un update:

    INSERT 
    INTO
        Entidades
        (Nombre) 
    VALUES
        (@p0);
    select
        SCOPE_IDENTITY();
    @p0 = 'UNO'

    UPDATE
        Entidades 
    SET
        Nombre = @p0 
    WHERE
        Id = @p1;
    @p0 = 'TRES', @p1 = 1032

El insert se lanza en la primera sesión que creamos, en la línea 7 al hacer el save. Lo hace aqui porque el generador de id que está definido en el mapeo es native, esto significa que le tiene que pedir a la base de datos el id. Únicamente por esta razón lanza el insert en esa línea. Si subiésemos definido el generador como guid el ORM le asignaría como id un new System.Guid() y no ejecutaría el insert en ese momento.

El update se lanza en la linea 22, al hacer el flush de la segunda sesión.
Es muy importante no confundir session.save y session.update con operaciones de base de datos. Os recuerdo que la sesión es la encargada de realizar las comunicaciones con la base de datos, save y update solo pasan a persistent un objeto. Fijaos en el update del log, el valor de nombre es TRES, pero en el código se hizo update con el nombre valiendo DOS. Esto es porque update solo asoció el objeto a la sesión. Es la sesión al hacer flush la que envía los cambios que tiene controlados a la base de datos.

La sesión tiene una propiedad llamada flushMode donde se define la política de flush. Yo recomendaría hacer un flush manual antes de cerrar la sesión para evitarnos sorpresas inesperadas.

Lock: solo se debe usar con objetos detached y sirve para atachearlos a la sesión. ¿entonces cual es la diferencia con update? Cuando se hace update de un objeto detached hibernate siempre lanzará un update a la base de datos (salvo que en mapping se le marque con select-before-update, entonces lanzará una select antes para saber si debe actualizar). Es decir si no sabemos si el objeto ha cambiado desde que se cerró la sesión podemos usar Update, si sabemos que no cambio podemos usar lock.

            Configuration cfg = new Configuration();
            cfg.Configure();
            ISessionFactory sf = cfg.BuildSessionFactory();
            ISession session = sf.OpenSession();

            Entidad e1 = new Entidad("UNO"); 
            Entidad e2 = new Entidad("ALFA");
            session.Save(e1); 
            session.Save(e2);

            session.Flush();
            session.Close();  

            session = sf.OpenSession();

            e2.Nombre = "BETA";

            session.Update(e1); 
            session.Lock(e2, LockMode.None);

            session.Flush ();
            session.Close();

            session = sf.OpenSession();

            session.Lock(e2, LockMode.None);
            e2.Nombre = "GAMMA";

            session.Flush();
            session.Close();

            sf.Close();

En las líneas 7 y 8 lanza los inserts correspondientes para cada objeto.
En el flush de la linea 21 lanza un update para actualizar el objeto e1, esta operación no sería necesaria porque el objeto no cambió, pero al reasociarlo con update se lanza una actualización contra la base de datos. Fijaos que en la linea 16 hemos actualizado el nombre de la e2, pero al estar detached ninguna sessión capturó el cambio, así que en la linea 21 no se nos lanza un update para este objeto.
En el flush de la linea 29 se lanza un update de la e2 ya que esta vez sí que hemos cambiado el nombre del objeto cuando estaba asociado a la sesión.
Aquí tenéis el log con las querys:

    INSERT 
    INTO
        Entidades
        (Nombre) 
    VALUES
        (@p0);
    select
        SCOPE_IDENTITY();
    @p0 = 'UNO'

    INSERT 
    INTO
        Entidades
        (Nombre) 
    VALUES
        (@p0);
    select
        SCOPE_IDENTITY();
    @p0 = 'ALFA'

--Flush Línea 21
    UPDATE
        Entidades 
    SET
        Nombre = @p0 
    WHERE
        Id = @p1;
    @p0 = 'UNO', @p1 = 1047

 --Flush Línea 29
    UPDATE
        Entidades 
    SET
        Nombre = @p0 
    WHERE
        Id = @p1;
    @p0 = 'GAMMA', @p1 = 1048

Merge: Quizás lo describía mejor su antiguo nombre SaveOrUpdateCopy, es decir, busca en la sesión y en base de datos el objeto, si existe lo machaca con el que lo pasamos y devuelve una instancia del objeto asociado a la sesión. Con este método evitamos que la sesión lance un error al intentar asociar un objeto con un id ya asociado a la sesión.

No sé si ha quedado claro, veamos un ejemplo

            Configuration cfg = new Configuration();
            cfg.Configure();
            ISessionFactory sf = cfg.BuildSessionFactory();
            ISession session = sf.OpenSession();

            Entidad e1 = new Entidad("UNO"); 
            Entidad e2 = new Entidad("ALFA");
            e1 = (Entidad)session.Merge(e1);
            e2.Id = e1.Id; 
            e2 = (Entidad)session.Merge(e2);

            session.Flush();
            session.Close();  

            session = sf.OpenSession();

            e2.Nombre = "BETA";

            session.Merge(e2); 
            
            session.Flush ();
            session.Close();

            sf.Close();

En este caso el merge de la línea 8 provoca un insert, ya que como pasamos a la sesión un objeto sin Id (N)Hibernate va a la base de datos para calcularla. En la línea 10 se machaca el objeto de sesión e1, con el e2 (porque tienen el mismo id) pero no se lanza ninguna query. En la línea 12 en el flush de la primera sesión se realiza un update que cambia el nombre de UNO a ALFA en la base de datos. En la línea 19 en el merge de una nueva sesión se lanza una select, ya que el objeto que se le pasa no está en la sesión y tiene que ir a la base de datos a buscarlo. En la línea 21, el flush provoca un update actualizando el Nombre a BETA

--Línea 8, Merge
    INSERT 
    INTO
        Entidades
        (Nombre) 
    VALUES
        (@p0);
    select
        SCOPE_IDENTITY();
    @p0 = 'UNO'

--Línea 12, Flush
    UPDATE
        Entidades 
    SET
        Nombre = @p0 
    WHERE
        Id = @p1;
    @p0 = 'ALFA', @p1 = 1053

--Línea 19, Merge
    SELECT
        entidad0_.Id as Id0_0_,
        entidad0_.Nombre as Nombre0_0_ 
    FROM
        Entidades entidad0_ 
    WHERE
        entidad0_.Id=@p0;
    @p0 = 1053

--Línea 21, Flush
    UPDATE
        Entidades 
    SET
        Nombre = @p0 
    WHERE
        Id = @p1;
    @p0 = 'BETA', @p1 = 1053

Espero que con esto quede claro como se comporta NHibernate, está claro que esto no cubre todos los casos, pero creo que es interesante y necesario conocer como se comportan los objetos con la sesión y como se pasan de transient a persistent y a detached.

Hibernate y NHibernate

noreply@blogger.com (Manel) — Mon, 02 Jan 2012 22:42:00 +0000

El otro día en la oficina estaba hablando con un compañero sobre Hibernate. Este compañero me comentaba que debía asociar a la sesión objetos antes de guardarlos. Según me explicaba, al hacer un new de un objeto y guardarlo directamente con Hibernate, el ORM daba fallos en algunos escenarios pudiendo lanzar inserts cuando debería hacer updates o al revés (no me acuerdo).
Desgraciadamente para mí, nunca he podido utilizar NHibernate en un proyecto real de producción, pero estaba seguro que el comportamiento que me describía no se daba en .Net y siendo proyectos hermanos, supuse que el comportamiento sería igual en Hibernate.
Este compañero de la oficina es difícil de convencer, así que programé una mini aplicación de consola en c# para demostrarle como se comportaba el ORM.

Primero hice una clase Entidad:

    class Entidad
    {
        private int _id;
        private string _nombre;

        virtual public int Id
        {
            get { return _id; }
            set { _id = value; }
        }

        virtual public string Nombre
        {
            get {return _nombre;}
            set { _nombre = value; }
        }

        public Entidad()
        {
        }
        public Entidad(string nombre)
        {
            Nombre = nombre;
        }
 
    }

Depues añadí el Mapping de NHibernate

Y por último el código del programa. Tened en cuenta que es una aplicación de NHibernate donde se trabaja directamente con session, es decir, que este código no es una buena referencia para escribir una aplicación profesional.

    class Program
    {
        static void Main(string[] args)
        {
            Configuration cfg = new Configuration();
            cfg.Configure();
            ISessionFactory sf = cfg.BuildSessionFactory();
            ISession session = sf.OpenSession();

            Entidad entidad = new Entidad("PRUEBA");
            session.SaveOrUpdate(entidad);

            session.Flush();
            session.Close();

            session = sf.OpenSession();
            Entidad entidad2 = new Entidad();
            entidad2.Id = entidad.Id;
            entidad2.Nombre = "MODIFICADO";

            session.SaveOrUpdate(entidad2);

            session.Flush();
            session.Close();

            sf.Close();      
        }
    }

Como podéis ver, el código es muy simple. Se crea una entidad y se llama directamente al método SaveOrUpdate y cerramos la sesión. Si os fijáis en el mapeo de Entidad podéis ver que el generador del id es native, esto significa que la base de datos es la responsable de asignarle un ID. En mi caso (un SQL Server) la columna Id de la tabla Entidades está definida como identity (autoincremental). Mirando la consulta de base de datos que ejecuta NHibernate podemos ver lo siguiente:

INSERT 
    INTO
        Entidades
        (Nombre) 
    VALUES
        (@p0);
    select
        SCOPE_IDENTITY();
    @p0 = 'PRUEBA'

Podemos ver claramente como NHibernate no envía el Id y deja a la base de datos asignarle un valor, despés de insertar el registro, recupera el id haciendo select SCOPE_IDENTITY
Después de eso se cierra la sesión y se crea otra nueva, además se crea una nueva entidad que copia las propiedades Id y Nombre del objeto anterior y se vuelve a guardar. Esta vez nos encontramos con un objeto creado fuera de la sesión de NHibernate, pero que representa a un registro existente en base de datos. ¿Qué hará el ORM cuando tenga que almacenarlo en la base de datos? ¿Sabrá hacerlo? Esto es lo que hace NHibernate:

UPDATE
        Entidades 
    SET
        Nombre = @p0 
    WHERE
        Id = @p1;
    @p0 = 'MODIFICADO', @p1 = 1

NHibernate ha sabido que tenía que hacer un update aunque el objeto no llegó de la sesión. ¿Cómo lo hace? Muy sencillo, en el mapeo se indica que el tipo de generador de id es native, lo que significa que será la base de datos la responsable de asignar id. En el primer caso, como el objeto no tenía id, hizo un insert, en el segundo como ya tenía id hizo un update.

Como comenté anteriormente, mi compañero no es fácil de convencer, y no le gustó mi explicación. Así que intentó ponerla en duda. Me pidió que quitase el identity a la base de datos y que asignase el id de forma manual.
No voy a volver a copiar y pegar todo el código, porque es el mismo, solo os indicaré que puse esta línea antes del primer SaveOrUpdate() esto:

    entidad.Id = 1024;

además modifiqué el mapping

Esta vez, al asignar de forma manual el id, NHibernate no sabe si tiene que lanzar un update o un insert ¿Cómo pensais que se comportaría al guardar el primer objeto?

    SELECT
        entidad_.Id,
        entidad_.Nombre as Nombre0_ 
    FROM
        Entidades entidad_ 
    WHERE
        entidad_.Id=@p0;
    @p0 = 1024

    INSERT 
    INTO
        Entidades
        (Nombre, Id) 
    VALUES
        (@p0, @p1);
    @p0 = 'PRUEBA', @p1 = 1024

Como podemos ver NHibernate no hace magia, lanza un select contra el Id para saber si el objeto existe en base de datos. Como no existe lanza un insert. Con el segundo objeto hace lo mismo:

    SELECT
        entidad_.Id,
        entidad_.Nombre as Nombre0_ 
    FROM
        Entidades entidad_ 
    WHERE
        entidad_.Id=@p0;
    @p0 = 1024

    UPDATE
        Entidades 
    SET
        Nombre = @p0 
    WHERE
        Id = @p1;
    @p0 = 'MODIFICADO', @p1 = 1024

Esta vez, después de comprobar que el objeto existe en base de datos mediante otro select, el ORM decide lanzar un update.
Después de todo esto pesaréis que la discusión quedó zanjada, y que mi compañero confía en mi explicación... pues de eso nada. Mi compañero ahora sostiene que Hibernate y NHibernate se comportan de forma diferente, lo que me obliga a hacer el mismo programa en java para demostrarle que Hibernate y NHibernate (al menos en este caso) se comportan de la misma forma.
Así que volví a crear la clase entidad (perdonad si me cargo alguna convención de java, al final, el 90% de mi tiempo lo paso picando vb.net):

public class Entidad {
 private Integer id;
 private String Nombre;
 public void setId(Integer id) {
  this.id = id;
 }
 public Integer getId() {
  return id;
 }
 public void setNombre(String nombre) {
  Nombre = nombre;
 }
 public String getNombre() {
  return Nombre;
 }
}

El mapeo de Hibernate es prácticamente igual que el de NHibernate y este post ya es demasiado largo, así que os copio el código del programa de consola:

 public static void main(String[] args) {
  // TODO Auto-generated method stub
  Configuration conf = new Configuration().configure();
  SessionFactory sf = conf.buildSessionFactory();
  Session session = sf.openSession();
  
  Entidad entidad = new Entidad();
  entidad.setNombre("Prueba");
   
          session.saveOrUpdate(entidad);

          session.flush();
          session.close();
         
          session = sf.openSession();
          Entidad entidad2 = new Entidad();
          entidad2.setId(entidad.getId());
          entidad2.setNombre("MODIFICADO");

          session.saveOrUpdate(entidad2);

          session.flush();
          session.close();

          sf.close();
  
 }

Como podeis ver en java he hecho lo mismo que en c#. La primera vez que se ejecuta el código la base de datos tiene configurado el campo id con identity y las consultas que lanza Hibernate son:

insert into Entidades (Nombre) values (?)
update Entidades set Nombre=? where Id=?

Y al quitar el identity y poner assigned en el mapeo la aplicación genera estas consultas:

select entidad_.Id, entidad_.Nombre as Nombre0_ from Entidades entidad_ where entidad_.Id=?
insert into Entidades (Nombre, Id) values (?, ?)
select entidad_.Id, entidad_.Nombre as Nombre0_ from Entidades entidad_ where entidad_.Id=?
update Entidades set Nombre=? where Id=?

En resumen, y obviando la diferencia de formatos de logs entre Hibernate y su hermano de .NET, los dos ORMs se comportan de la misma forma. (N)Hibernate utiliza el ID para saber si un objeto está en base de datos y saber si tiene que lanzar un update o un insert.
Como nota curiosa he de mencionar que para el ejemplo de java he usado Hibernate 4 y me he llevado una sorpresa al descubrir que buildSessionFactory() está deprecado pero esto no afectó a mi prueba de concepto.

RWJ. La memoria en la JVM

noreply@blogger.com (Pedro) — Tue, 20 Dec 2011 00:35:00 +0000

Aunque muchas veces se nos olvida, la JVM es un proceso del sistema operativo como otro cualquiera. Si, si. Lo que leéis. Y como en el resto de procesos, la memoria está dividida en tres regiones : el stack, el heap y el code segment

el stack es la zona de memoria donde se almacenan los parámetros que se pasan a una función en una llamada, las variables locales e información de retorno. Cada vez que se llama a una función desde dentro de otra, se apilan los parámetros de la nueva función y sus variables hasta que se haga return.
el heap es el área de memoria en el que "se hacen los malloc() " . En él se guardan las estructuras de datos permanentes en memoria. Y en los lenguajes orientados a objetos, se crean los objetos. Y si se usa mucho, acaba por llenarse.
el code segment es la zona de memoria donde reside el código del proceso. En el caso de la JVM, es la parte del código que no está programado en Java. Es decir, el core nativo de la JVM.

Como comentaba, la JVM es un proceso como otro cualquiera. Y la gran idea que tuvo Sun fue hacer un proceso que ejecutase procesos. Y esos pseudoprocesos están escritos en bytecode, una especie de código máquina para JVM, independiente de la plataforma sobre la que se ejecute la JVM.

Como tuvieron tiempo para pensárselo, hicieron las cosas a conciencia: los programas Java se compilan a bytecode común y se ejecutan en la JVM -específica por sistema operativo- . La orientación a objetos está muy presente en todo el diseño del lenguaje y, como no, en el de la propia JVM. La máquina virtual ofrece mecanismos para liberar la memoria de los objetos obsoletos, llamado garbage collector. Y el propio código de los programas Java forma parte del paradigma objetual.

El área de memoria de los procesos de la JVM tiene un diseño propio, muy parecido al de los sistemas operativos, pero diseñado para facilitar el garbage collecting:

el stack, con el mismo funcionamiento comentado antes
el heap, en el que se crean todos los objetos utilizados, y sobre los que posteriormente se hará recolección de basura, con dos partes :

young generation: en el que se crean los nuevos objetos (eden) y con dos survival spaces por los que van pasando los objetos antes de llegar a la
tenured (old) generation, en el que acaban los objetos persistentes a los gc.

el permanent generation space , equivalente al code segment. En él se va cargando la información de las clases y métodos utilizados. La memoria usada en este espacio no se libera jamás, y hará falta más espacio cuantas más clases utilice el proceso.

A nivel de implementación de sistema operativo, tanto el heap como el permgen space se guardan en el heap del proceso JVM, aunque cuando hablamos de Java, solemos decir que el permgen space no es parte del heap.

Por cuestiones de diseño y seguridad, la memoria máxima que el proceso de la JVM va a utilizar se define en el momento de arrancarla, y no es posible aumentarla. ¿Cómo? Con las siguientes opciones :

-Xms64m , que indica que el tamaño del heap reservado al arrancar la JVM será de 64 megas.
-Xmx1024m, que limita a 1024 megas el tamaño máximo de heap reservable.
-XXMaxPermSize=128m , limita a 128 megas el tamaño máximo de la permanent generation.

La memoria máxima reservada por defecto para la JVM de Sun es -Xmx64m . Pero estos y otros muchos parámetros son configurables .

Leído todo esto, es posible que empecéis a distinguir los diferentes errores de memoria de la JVM

java.lang.StackOverflowError . Error de desbordamiento de pila, que ocurre cuando se apilan tantas llamadas a funciones que se salen de su espacio de memoria ( normalmente con llamadas recursivas infinitas )
java.lang.OutOfMemoryError : heap space . Ocurre cuando el heap se llena por completo y el gc no es capaz de liberar espacio. Puede deberse a memory leaks o a que nuestro programa necesita más memoria.
java.lang.OutOfMemoryError : PermGen space failure . Cuando el permgen space se llena a tope. Puede deberse a que no hay memoria suficiente para cargar todas las clases que llamamos (¿¿nos cargamos todo apache commons?? ) o a memory leaks en classloaders que recargan clases en caliente pero no liberan bien la memoria de las anteriores.

Y en cuanto al tema del garbage collector, yo creo que se merece una entrada propia. ¿Se echa de menos algún dibujo en el artículo?

Comprando chollos

noreply@blogger.com (Pedro) — Tue, 13 Dec 2011 20:19:00 +0000

Soy de los que les gustan los libros. Me parece mucho más fácil aprender de un libro que de blogs o de una plataforma de formación online. Pero lo malo es que los libros técnicos cuestan una pasta.

Yo creo que a día de hoy ya sabemos todos que los libros salen muuuy baratos en amazon (sobre todo en el de US). Lo malo son los sablazos que nos pegan por los portes.

Pues resulta que play.com no sólo vende juegos y camisetas. También vende libros, y aunque no es la repera como amazon, lo que si que tiene son chollazos en la parte de segunda mano - libros muy baratos y portes gratis - .
La semana pasada me compré estos libros y ... ya los tengo en casa:

The Unified Modeling Language por 4,76 €
Refactoring in Large Software Projects por 4,30 €
Bitter java por 5,30 €
Beyond Java por 2,90 €

Y todo con portes gratis y enviados en paquetes separados para evitar grandes males. Por eso os aconsejo consultar de vez en cuando los libros de programación ordenados por precio .

Consejos de Coco

noreply@blogger.com (Manel) — Wed, 02 Nov 2011 07:00:00 +0000

Hola niños, soy Coco y hoy voy a enseñaros la diferencia entre servidor y cliente en aplicaciones web.

El cliente es un navegador, y hay de muuuuuuuuuuchas clases. Algunos tienen una E azul muy gorda y todo el mundo habla mal de ellos. Otros tienen un zorro enroscado. Dicen que los hackers usan uno con una O roja. Google también tiene el suyo y puede hacer que se esconda debajo de la E azul.
Pero todos hacen dos cosas pintar HTML y ejecutar Javascript.

El servidor es un ordenador muy grande que hace muchas cosas, es muy potente y puede hacer casi de todo: poner pelis y música, imprimir, hacer ficheros, leer bases de datos,… el límite lo pone tu imaginación.
Pero el pobre servidor está solito, no tiene usuarios que jueguen con él, así que cuando programes para él haz que hable con los navegadores, que tenga algo de compañía.
Si pones al servidor a hacer cosas solito se pone muy triste. Lo peor que puedes hacerle es obligarle a mostrar un cuadro de diálogo, en esos casos el servidor esperará a que alguien venga y le responda, pero lo triste es que nadie llegará. Algunas veces la depresión es tan grande que el servidor dejará todo esperando la respuesta.

Para hablar con la gente el servidor puede mandar html y javascript o incluso ficheros (eso los muy listos) al navegador, donde lo mostrará todo muy bonito (en unos más que en otros), preguntarle cosas con cuadros de dialogo o guadar pdfs...

Ya sabeis niños, el amigo del servidor es el navegador, haz que hable con él, y no lo pongas a hablar solo, que se deprime.

¡¡¡Y COMO VUELVA A VER UN MSGBOX EN UNA DLL COMIENZO A CORTAR MANOS!!!

Grep en Windows

noreply@blogger.com (Manel) — Mon, 31 Oct 2011 07:00:00 +0000

Esta tarde hablando con un compañero le pregunté si se podía crear un logger para log4net en el que solo sacase los WARN de una clase. Me comentó que él haría un grep y que eso era una de las razones por las cuales le gustaban más los sistemas tipo Linux/UNIX. Entonces recordé que en windows tambien podemos hacer cosas de este tipo y le comenté que con findstring se podía hacerse. He de reconocer que no suelo pensar en línea de comandos. Hace años que dejé eso (desde que no tengo que editar autoexec.bat y el config.sys para ejecutar según que juegos).

Me gustan las ventanas y no lo niego
Creo que los sistemas de ventanas son muy cómodos, no solo a nivel usuario. Para realizar tareas de administración me gusta tener una ventana donde vea todas las opciones y poder editar. Me resulta infinitamente más cómodo que tener que leerme un fichero de script y esperar que las opciones que necesite y que no estén configuradas vengan en una linea comentada.
Aunque reconozco que para ciertas operaciones por lotes la linea de comandos está muy bien y que debería pensar más en eso de lo que suelo hacer.

Linea de comandos en Windows.
Aunque parezca mentira hay linea de comandos en windows, y a fata de una hay dos: El command (para mi MS-DOS aunque no lo sea) y el Powershell.
Powershell es mucho más pontente que la consola de MS-DOS. Fue desarrollado por Mircrosoft para contentar a los administradores de windows que echaban de menos una linea de comando ponente, como la de UNIX. Se lanzó en el 2003 y actualmente se distribuye con los sistemas operativos, tanto de servidor (Server 2008) como de escritorio (Windows 7).
La nueva política de Microsoft intenta que todos sus productos tengan soporte powershell para que los administradores puedan hacer las mismas operaciones tanto desde ventanas como desde linea de comandos, así que sqlserver trae sus scripts de powershell, exchange server también, etc.
Por ejemplo si instalas el Server Core de Windows 2008 Server, se teiene que hacer todo desde la línea de comandos.

Punto negro de powershell
Powershell tiene una carencia importante: No hay una instruccion equivalente a tail -f en UNIX. Lo más parecido es get-content -wait, pero no funciona todo lo bien que sería necesario. Afortunadamente la comunidad de ususarios han generado herramientas para suplir esta carencia. Esperoemos que los chicos de Redmond añadan soporte oficial en próximas actualizaciones.

Ya está bien de tanto coñazo ¿y lo del grep como va?
Para filtrar lineas de fichero en MS-DOS existe la instrucción findstr y para volcar a un fichero cualquier salida de comando utilizamos > así que para hacer el filtro que necesitaba en el log solo tenía que hacer:

findstr WARN aplicacion.log > logfiltrado.log

En powershell se haría concatenando tres comandos: get-content, select-string y out-file, los comandos en powershell se concatenan con pipes:

get-content aplicacion.log | select-string WARN | out-file logfiltrado.log

Visual Studio, SVN y conflictos.

noreply@blogger.com (Manel) — Tue, 25 Oct 2011 16:30:00 +0000

Mi compañero Pedro ha comenzado una serie de post sobre desarrollo en Java. En sus primeras entregas ha comenzado por uno de los puntos básicos del desarrollo en equipo: el repositorio de código fuente (o sistema de control de versiones). Como bien indica, uno de los más utilizados actualmente es el Subversion (SVN). Este sistema se comporta muy bien con grandes equipos y al permitir trabajar de forma desconectada hace que sea unos de los sistemas más utilizados por los proyectos Open Source.

Conflictos en SVN
De todas formas, si se trabaja con Visual Studio, se deben tener ciertas precauciones, debido a la forma de gestionar los conflictos que tiene SVN. Se detecta un conflicto cuando dos o más programadores realizan cambios en las mismas líneas de un fichero a la vez. Para indicar los conflictos SVN modifica el fichero de trabajo, marcándolos de esta forma:

<<<<<<< fichero
    modificaciones del usuario
=======
    última versión subida al SVN
>>>>>>> revisión

Además añade tres ficheros:

fichero.ext.mine: la copia del fichero de trabajo que usaba el usuario antes de lanzar el update.
fichero.ext.rOLDREV: una copia de la versión del fichero antes de que el usuario comenzase a modificarlo.
fichero.ext.rNEWREV: una copia de la última versión del fichero en el momento de detectar el conflicto.

Visual Studio y SVN
Visual Studio utiliza ficheros índice que le indican con qué trabajar:

fichero.sln: define la solución, contiene todos los proyectos, sus rutas y el modo de acceder a ellos.
fichero.csproj o fichero.vbproj: De forma similar a los sln, los ficheros de proyecto (proyectos vb o c#) contienen una lista con todos los ficheros que utilizan (código fuente, referencias a librerías, ...)

Los conflictos con estos ficheros pueden producirse inconscientemente por parte de los programadores, ya que al añadir un proyecto a la solución, o un fichero a un proyecto, el Visual Studio modifica los sln y los proj. Estas modificaciones, si se producen en paralelo, seguramente provocarán conflictos en y el SVN marcará estos en los ficheros. Con estos ficheros marcados el Visual Studio no es capaz de leerlos, por lo tanto, desaparecerían los proyectos o incluso la solución, del explorador de proyectos (lo que provocaría un buen susto a más de uno).
Para solucionar este problema, tan solo hay que salir del entorno de desarrollo y resolver el conflicto, depués volver a cargar los proyectos o la solución que provocaba el error.

Soluciones
SVN es un sistema muy extendido. A pesar de sus problemillas con Visual Studio, muchos de los proyectos Open Source de .NET lo utilizan.
Una de las estrategias más utilizadas para evitar estos problemas es ignorar los cambios en los ficheros solución y de proyecto para que el SVN no gestione sus actualizaciones. Cada vez que se realice un update, se deben buscar los proyectos, ficheros y referencias añadidas para incluirlas de forma manual, para que únicamente el Visual Studio gestione los ficheros índice. Aunque esto no parezca la mejor solución es una de las más extendidas.
Si todos los miembros del equipo de desarrollo están en la misma oficina, podemos utilizar otra estrategia. Siempre que un desarrollador añada un fichero, este lo sube y avisa al resto del equipo para que actualicen, de esta forma no se producirán conflictos en los ficheros índice.

Conclusiones
El SVN es un buen sistema para trabajo en equipo, aunque no lo recomendaría para utilizar con el Visual Studio. Sobre todo en las fases iniciales de un proyecto, donde varias personas suben ficheros en paralelo. En proyectos de mantenimiento, donde el desarrollo principal ya se ha finalizado y las tareas más habituales son editar ficheros (no borrarlos o añadirlos) podría ser una solución aceptable.
Existen soluciones alternativas al SVN, tanto de pago (Team Foundation, Source Safe) como gratuitas (como Mercurial o Git). Microsoft parece que apuesta por Mercurial, al menos eso parece indicar el soporte a este sistema por parte de www.codeplex.com, el portal que aloja proyectos Open Souce que gestiona Microsoft.

Javascript, JSON y las fechas

noreply@blogger.com (Manel) — Mon, 24 Oct 2011 06:00:00 +0000

En estos últimos años se ha puesto muy de moda el uso de JSON con Ajax para el envío de datos entre la página web y el servidor. Pero si consultamos la definición de JSON podemos comprobar que este formato no tiene soporte para fechas.

Formato fecha en JSON

Los desarrolladores que implementan los serializadores de JSON deben decidir que estrategia utilizar. Por otro lado, los que explotan servicios de terceros que envían fechas por JSON deben conocer son enviados, así que es recomendable solicitar la documentación donde se explique en qué formato se envían los datos.

Como programador en .NET sé que el serializador viene por defecto con el framework envía las fechas en un string con el siguiente formato: /Date(1319130612160)/

La cifra que va entre paréntesis indica el número de milisegundos transcurridos desde el 01/01/1970. Este formato es el mismo que usa javascript para crear sus fechas. Si nos fijamos, podemos ver como el serializador de Microsoft ya nos da hecho el constructor del Date en javascript, así que para convertir a fecha tan solo hay que quitar las barras al string y poner un new delante. Se podría codificar una funcion parecida a esta:


        function DateDeserialize(dateStr) {
            return eval('new ' + dateStr.replace(/\//g, '') + ';');
        }

Formateando Fechas en Javascript

Desgraciadamente Javascript no tiene funciones para formatear las fechas. La única solución es programar nuestras propias funciones. La otra forma que conozco de hacerlo es utilizando JQueryUI, un conjunto de plugins oficial de JQuery, pero para esto, el proyecto web debería estar ya usando eso. No incluiría unas librerías que pesan tanto en un proyecto solo para solucionar este problema.

El datepicker es plugin que se utiliza para decorar inputs para incluir un calendario. Además tiene un método llamado formatDate con el que podemos formatear las fechas con una sintaxis que resulta familiar para la mayoría de los programadores, por ejemplo: $.datepicker.formatDate('dd-mm-yy', fecha)

Conclusión

Siempre que se pueda, hay que evitar trabar con fechas en javascript. Todo ese trabajo es mucho mejor realizarlo en el lado del servidor. Es más rápido y se dispone de un api mucho más completo (lo que evita muchos problemas).

Reemplazando con expresiones regulares

noreply@blogger.com (Pedro) — Thu, 20 Oct 2011 22:30:00 +0000

En ciertas ocasiones he necesitado reemplazar todas las apariciones de una cierta expresión dentro de una cadena. La última vez era necesario hacer una transformación de URLs dentro del HTML de una página obtenido con un httpclient . Una buena parte de los programadores Java con los que he trabajado conocen la función replaceAll() de java.lang.String , pero casi nunca la he visto aplicada a expresiones regulares.

Por ejemplo, imaginemos que queremos modificar todas las apariciones de /display/xxxx/yyyy como atributo en el HTML y sustituirlas por http://nocompila.com:8081/display?space=xxxx&page=yyyy , en donde xxxx e yyyy puede ser cualquier expresión alfanumérica.

Para hacer esto he llegado a ver de todo, hasta construcciones del árbol DOM del html, búsqueda de nodos con atributos href con recorridos en profundidad (nada de XPath), obtención de su valor como String, tokenización, recomposición y asignación de nuevo a través del API DOM.

Pues con expresiones regulares es muy fácil, sólo hay que hacer uso de sus matching groups : dentro de una expresión regular es posible utilizar paréntesis para envolver ciertas partes de la expresión. Y se puede usar el contenido de los paréntesis en la expresión de sustitución referenciándolo con $i , siendo i la posición del grupo de paréntesis en la expresión y comenzando a numerarlos en 1.

Para nuestro ejemplo se haría

String html = // obtener html de la url

String newHtml = html.replaceAll(  
                     "=\"/display/([^/]+)/([^\"]+)\""
                   , "=\"http://localhost:8081/display?space=$1&page=$2\"");

Fácil, ¿verdad? . El único inconveniente es coger soltura con las expresiones regulares, pero el esfuerzo suele valer la pena.

Festival del Humor (IV)

noreply@blogger.com (Pedro) — Thu, 20 Oct 2011 14:50:00 +0000

Hola, os dejo una muestra de código que nos llega desde el otro lado del charco :

public class CertificadoConSaldo implements Serializable {

 private static final long serialVersionUID = 1L;

 private transient CertificadoIVR certificadoIVR ;

 private Cuenta[] cuentas;

 /**
  * Constructor default
  */
 public CertificadoConSaldo() {

 }

 /**
  * Implementa un adapatador que convierte un CertificadoConSaldoIvrCEVO en
  * un certificadoConSaldo para mostrar en el XML
  */
 public CertificadoConSaldo(CertificadoConSaldoIvrCEVO vo) {
  certificadoConSaldoIvrCEVO = vo;
 }

 public Cuenta[] getCuentas() {

  if (certificadoIVR.getCuentas() != null) {

   List listaCuentas = certificadoIVR.getCuentas();
   cuentas = new Cuenta[listaCuentas.size()];

   int index = 0;
   for (Iterator iterator = listaCuentas.iterator(); iterator
     .hasNext();) {

    CuentaIvrVO cuentaIvrVO = (CuentaIvrVO) iterator.next();
    cuentas[index++] = new Cuenta(cuentaIvrVO);
   }
  }

  return cuentas;
 }

 public void setCuentas(Cuenta[] cuentas) {
  this.cuentas = cuentas;
 }

}

Lo peor es que cuanto más lo leo más errores encuentro. ¿En cuántas lineas dejaríais la clase? ¿Qué errores le veis?

Por cierto, todas nuestras entradas de festival del humor son genuinas y auténticas.

RWJ. Control de versiones: Subversion (y II)

noreply@blogger.com (Pedro) — Tue, 18 Oct 2011 23:47:00 +0000

Como comentábamos en el post anterior, cuando hacemos un commit de un directorio del proyecto (el raíz tambien es un directorio) SVN va a comprobar que, para cada fichero marcado como modificado, la versión base del fichero en nuestra working copy coincide con la última versión de ese fichero subido al repositorio. En caso de no coincidencia sería necesario actualizar primero los contenidos de la working copy con la última versión que hay en el repositorio.

Los directorios también mantienen un número de versión que cambia cuando cambia el número de versión de alguno de sus contenidos. Además es posible guardar un comentario con cada commit

¿Y esto llega para todo lo que hablamos? ¿Marcar versiones entregadas del código fuente del proyecto? ¿Mantener ramas de desarrollo paralelas? ¿Sólo con esto?

Pues para conseguir esto hay que basarlo en convenciones. Cuando se crea un repositorio y antes de empezar a subir ficheros hay que crear tres directorios :

branches
tags
trunk

Una vez creados estos directorios en el repositorio ( que, por ejemplo, tendrá la url http://repo/svn/miproyecto/ ) cada integrante del equipo de desarrollo tendrá que hacer un checkout sobre http://repo/svn/miproyecto/trunk . Este directorio albergará la rama principal de desarrollo y todo el equipo trabajará contra él.

Independientemente de que las versiones de svn se numeren secuencialmente es recomendable nombrar cualquier software con un formato x.y.z . Cambios pequeños en el software - por ejemplo, corrección de bugs- deberían incrementar el número z . Cambios funcionales notorios deberían incrementar el número y, mientras que el valor de x aumentaría sólo con cambios profundos en el producto.

Cuando el código de trunk cumple con los objetivos que el equipo de desarrollo ha marcado para liberar una versión del programa se lanza sobre el repositorio un copy to de la rama /trunk en un directorio con la versión de software, por ejemplo, /tags/1.0.0 . En las observaciones de esta operación es recomendable indicar el changelog del software.

De esta manera, el directorio /tags/1.0.0 pasaría a contener la versión 1.0.0 del software , mientras que el equipo de desarrollo seguiría desarrollando con su working copy apuntando a /trunk . Sucesivas versiones del software se marcarían de esta misma forma.

En proyectos más complejos en los que es necesario dar soporte a diferentes versiones del producto puede surgir la necesidad de abrir una rama de desarrollo paralela al trunk - cuya última versión liberada fue la 3.5.1 - por ejemplo, para corregir bugs sobre una versión 2.2.0 . En este caso el procedimiento a seguir sería hacer un copy to de /tags/2.2.0 a /branches/2.2.x , comentando la apertura de una rama paralela de desarrollo. El equipo responsable de la rama debería hacer un nuevo checkout del proyecto sobre la URL http://repo/svn/miproyecto/branches/2.2.x . Nuevas versiones del programa desarrollado sobre el trunk se seguirán etiquetando como hasta ahora mientras que las nuevas releases del branch se etiquetarán manteniendo las versiones de la rama. En nuestro caso el número de la siguiente versión sería 2.2.1

Por último, puede que modificaciones de algunos ficheros en la rama deban pasar al trunk - es el sentido habitual de incorporación-. En estas circunstancias es cuando procede hacer un merge de ambas ramas. Esta parte es un poco más compleja y la maestría haciendo merges sólo se consigue haciendo muchos.

Si no estáis usando un sistema de control de versiones, ¿a qué esperáis?

RWJ. Control de versiones: Subversion (I)

noreply@blogger.com (Pedro) — Tue, 18 Oct 2011 05:30:00 +0000

Uno de los primeros conceptos que solemos abordar cuando incorporamos un programador sin experiencia a nuestro equipo de trabajo es el de sistema de control de versiones.

- ¿Alguna vez has hecho una práctica en equipo, cada uno programando un módulo?
- Si, una vez hicimos una aplicación web y mientras mi compañero escribía las páginas yo programaba el acceso a los datos.
- ¿Cómo compartíais los ficheros?
- Con una carpeta compartida de Windows.
- ¿Y podíais seguir trabajando cada uno en vuestra casa y al día siguiente juntar los cambios?
- No, teníamos que estar trabajando juntos con acceso a la red de Windows.
- ¿Guardábais versiones del código que generábais? 
- Si, a última hora sacábamos un .zip con la fecha y la hora en el nombre del fichero.
- ¿No era un poco coñazo que si uno tocaba un fichero, al otro le dejase de compilar el proyecto? ¿Podías modificar los dos el fichero a la vez?

- No...

Los sistemas de control de versiones, a veces llamados también repositorios de código fuente - aunque un repositorio de código fuente no tiene por qué gestionar versiones- son herramientas diseñadas para evitar estos problemas (y algunos otros) de forma que facilitan:

Trabajar simultáneamente sobre un mismo proyecto a más de una persona.
Registrar qué cambios se han hecho en cada momento en el proyecto, quién los ha hecho o recuperar una versión antigua
Publicar los cambios que un integrante del equipo de proyecto ha hecho una vez están terminados, y no antes ( cuando puede que ni siquiera compile el proyecto).
Trabajar de manera offline , de manera que los cambios se pueden hacer fuera de la red y publicarlos después de un tiempo.
Etiquetar los diferentes entregables elaborados durante la duración del proyecto.

Los sistemas de control de versiones se clasifican en conectados y desconectados. Ejemplos de los primeros son CVS o SourceSafe. De los segundos: SVN, Git, Mercurial . La diferencia radica en que los entornos conectados requieren de una conexión continua al repositorio y éste controla, en cada momento, qué usuario está tocando qué ficheros; mientras que los entornos desconectados no requieren de conexión contínua. El principal inconveniente de estos últimos es que, como cada programador no tiene por qué saber si alguien más está editando los mismos ficheros, pueden aparecer modificaciones simultáneas de un mismo fichero de manera más habitual.

Los sistemas conectados han caído en desuso por su menor flexibilidad, y de los desconectados, el sistema con creces más usado es Subversion - SVN - .

Subversion se basa en la existencia de un repositorio centralizado de código en un servidor único, contra el que los diferentes desarrolladores interactúan mediante programas cliente como TortoiseSVN. La comunicación entre los clientes y el servidor se puede realizar mediante diferentes protocolos, siendo el más común http.

El repositorio SVN es un directorio en el servidor en el que se pueden subir ficheros y crear estructuras de directorios. Cada vez que se hace una subida o modificacion en el repositorio se aumenta el número de versión de los ficheros modificados y se almacena el login del usuario que realizó el cambio. Adicionalmente, se guarda un histórico de todas las versiones anteriores por las que ha pasado cada fichero.

Para recuperar una cierta versión del código el servidor busca las versiones de cada fichero con el mismo número de versión o con el mayor número posible por debajo. La última versión es la HEAD.

La dinámica de trabajo con SVN es simple. El programador hace un checkout de la versión HEAD del repositorio, cuyo resultado es la obtención de una working copy en su sistema de ficheros local. Este código puede ser modificado por el programador. Cuando el programador finaliza su trabajo hace un commit de sus ficheros de manera que sus modificaciones pasan a formar parte del repositorio, incrementando en una unidad la versión del código fuente.

Dado que el programador no tiene por qué estar trabajando solo, en cualquier momento puede hacer un update del código de manera que se actualiza su working copy con los nuevos cambios que otros programadores puedan haber realizado.

Si durante este tiempo otro programador ha modificado uno de nuestros ficheros, en el proceso de update aparecerá un conflict que habrá que resolver, unificando las modificaciones realizadas por nosotros mismos con las del otro programador. Si las modificaciones afectan a partes diferentes del fichero se suelen resolver de manera automática, pero en muchas ocasiones surge la necesidad de resolver los conflictor haciendo un merge de ambas versiones de los ficheros.

- Si, vale, muy bien, todo esto ya me lo sé que lo leí el otro día en un blog
- Pues enseguida te cuento cómo trabajar con esto, que es lo que no cuentan en todos los blogs.

Real World Java - RWJ -

noreply@blogger.com (Pedro) — Mon, 17 Oct 2011 18:11:00 +0000

Cada vez que un estudiante de informática sale del entorno académico para incorporarse al mundo laboral como programador se enfrenta a un sinfín de novedades, no sólo tecnológicas, si no sobre todo organizativas. Se dejan a un lado las prácticas, que muchas veces parecían enormes, para formar parte de proyectos realizados por equipos de varias personas, cientos (o miles) de horas, problemas de gestión de configuración, múltiples entornos,...

En nuestro entorno profesional tenemos bastante suerte y los chicos que se incorporan a la empresa suelen ser titulados universitarios (o casi) en informática, algunos de ellos con las cosas bastante claras. Sin embargo, siempre acabamos teniendo que contar lo mismo: herramientas de control de versiones, compilación, estilos de programación, arquitectura, diseño, etc. En varias ocasiones hemos pensado en escribir sobre ello: hacer una especie de manual de formación para novatos. Pero los blogs son más divertidos.

La idea es ir escribiendo una serie de entradas sobre algunos de estos temas: herramientas, entornos ... y sobre todo, estilos de programación.

Muchas veces la gente que comienza en este mundo olvida que el fin de todo esto es hacer negocio. Y las diferentes empresas siguen diferentes políticas a la hora de hacer este negocio. Nosotros creemos que la calidad del producto sí es importante. Y empieza por hacer que nuestro trabajo se haga siempre igual, pero mejorando cada vez un poco más.

Mac OS X Lion ¿Poca duración de batería?

noreply@blogger.com (Pedro) — Thu, 01 Sep 2011 17:01:00 +0000

Buenas. Ya sé que no va de programación, pero bueno, tampoco es nada fácil dar con esto.

Pues resulta que hace no mucho tiempo empecé a notar un bajón notable en la autonomía de mi macbook pro, del orden de 4h30 a 3h de batería. Se me juntó eso con la actualización a Lion y empecé a echarle la culpa a esto. Pero seguía rechinándome. No puede ser.

Total, que hablando con un amigo se me encendió la lucecita mientras le estaba contando cómo los mac pro tenían dos gráficas y cambiaban dinámicamente para ahorrar energía. ¿Sería que no pasaba a la integrada?

Hay un programa que se llama gfxCardStatus que te permite ver el estado de la gráfica del mac. Lo instalo y bingo, sólo con el navegador abierto, tarjeta dedicada activa. Además tiene un valor añadido, te dice qué módulos son los que fuerzan a estar activa a la tarjeta dedicada.

Pues resulta que Firefox (y Chrome también) hacen que la tarjeta gráfica dedicada se active - por temas de aceleración gráfica - con el consiguiente bajón de batería.

En resumen, navegar con Firefox consume un 30% más de batería que navegar con Safari en un Macbook Pro con tarjeta gráfica dual.

Festival del Humor (III)

noreply@blogger.com (Pedro) — Wed, 24 Aug 2011 07:05:00 +0000

Me acaba de saltar el proxy con esta url de malware