Comma NET

La Cara Oculta de Delphi 6

2010-10-26T00:41:00.003+02:00

Todo hombre de negocios sabe que no debe regalar aquello que puede vender. Todo hombre de negocios inteligente sabe, además, que no debe tirar aquello que puede regalar.

"La Cara Oculta de Delphi 6" es un libro al que profeso mucho cariño. Invertí en su preparación muchas horas, me sirvió para afianzar mi empresa... y estoy satisfecho con el resultado. Pero ya ha pasado tiempo suficiente como para dar por cerrada una etapa profesional, y para pasar a la siguiente. Aquí está la versión electrónica del libro, por si a alguien todavía le interesa:

La Cara Oculta de Delphi 6

Es tiempo de ascender otro escalón...

Cómo espiar los mensajes de un control

2010-09-08T00:18:00.020+02:00

Sigo con trucos necesarios para implementar un sistema de gestión de ventanas más o menos complejo. Imagine que tiene un botón, y que debe responder a los clics del mismo. Ni lo piense: desde la ventana, o desde la clase que contiene al botón, añade un manejador al evento Click del botón. Esta es una ventaja que tiene .NET y su sistema de eventos multicast sobre el viejo y más sencillo sistema de eventos de Delphi nativo. En Delphi nativo solamente podíamos asociar un único manejador a cada evento. En .NET, el evento puede disparar cuantos manejadores necesitemos.

La gran pregunta: ¿y qué ocurre si lo que quiero interceptar es un mensaje que no tiene un evento de "alto nivel" asociado? La solución "clásica" es crear una clase derivada a partir del botón. Pero, ¿y si no es posible hacerlo? Por ejemplo, puede que le toque lidiar con un botón que usted no ha creado (la culpa siempre es de otro). En mi caso, no se trata de un mero botón, sino de la mismísima ventana principal. Estoy escribiendo un gestor genérico de ventanas, y necesito interceptar el mensaje WM_ACTIVATEAPP. Podría obligar al programador que utilice mi gestor a derivar su ventana principal de una clase base mía, debidamente retocada. Sería chapucero, no obstante.

Este es un problema bastante general del modelo de programación orientada a objetos que terminó imponiéndose en nuestros lenguajes de programación: el tipo de objeto va unido indisolublemente a su entidad. Un coche de turismo no se puede convertir dinámicamente en una ambulancia... aunque en la vida real, los turismos puedan utilizarse así. Este problema hace complicado trabajar con bases de datos orientadas a objetos cuyo modelo de objetos sea parecido al de C++, Java o C#. No me malinterprete: el modelo con tipos estáticos es estupendo para escribir cierto tipo de programas, pero es malo para las bases de datos, en las que un objeto de la clase Contacto puede fácilmente en un Cliente, y no podemos perder las referencias al contacto durante la metamorfosis.

Lo interesante es que existe una solución muy conocida para este problema... en el API de bajo nivel de Windows; si busca window subclassing encontrará montones de páginas sobre esta técnica. La pregunta es, ¿cómo conseguir lo mismo utilizando Windows Forms?

La respuesta la tiene la clase NativeWindow, que nos evita tener que usar PInvoke o cosas peores. ¿Hay que interceptar los mensajes que recibe un control? Pues creamos una clase derivada de NativeWindow, sobrescribimos su método virtual WndProc y, para asociarla al puñetero botón, usamos el método AssignHandle de NativeWindow para copiar en una instancia de la nueva clase el identificador de ventana del botón a vigilar. Los mensajes de ventana que normalmente recibiría el botón serán ahora recibidos también por nuestra instancia de la clase derivada de NativeWindow.

Es cierto que seguimos necesitando crear una clase por herencia. Si necesitamos realizar esta operación de vigilancia con N tipos diferentes de botones, ¿significa que tendremos que crear N clases derivadas de NativeWindow? Resulta que no: podemos definir una sola clase derivada de NativeWindow sin tener conocimiento del control concreto que vigilaremos y las acciones concretas que queremos ejecutar. Lo que haríamos en su WndProc, sencillamente, sería llamar a una variable de tipo delegate que especificaríamos al crear las instancia de dicha clase. Y sería ese delegado donde implementaríamos el código necesario:

private sealed class PeepingTom : NativeWindow, IDisposable
{
  public delegate void WindowProc(ref Message m);

  private WindowProc tommy;

  public PeepingTom(Control ladyGodiva, WindowProc tommy)
  {
    this.tommy = tommy;
    this.AssignHandle(ladyGodiva.Handle);
  }

  public void Dispose()
  {
    this.ReleaseHandle();
  }

  protected override void WndProc(ref Message m)
  {
    tommy(ref m);
    base.WndProc(ref m);
  }
}

Los nombres, por supuesto, hacen referencia a la historia de Lady Godiva, que se paseó desnuda a caballo por todo Coventry para obligar a su marido a bajar los impuestos (¡que no se le ocurra la idea a la Sonsoles, please!), y a un tal Peeping Tom, o Tomasito el Mirón, que desobedeciendo las órdenes del cabreado marido, se escondió para regocijarse con la visión de la damita en pelotas.

Suponga ahora que tenemos un formulario con un botón, y que queremos saber cuándo el ratón pasa por encima del botón. Para asignarle un espía al botón, dado el diseño de nuestra clase, tenemos que esperar al evento Load del formulario, para asegurarnos de que el identificador de ventana del botón haya sido creado. En ese momento, hacemos algo parecido a esto:

private void Form1_Load(object sender, EventArgs e)
{
  new PeepingTom(button1,
    delegate(ref Message m)
    {
      if (m.Msg == 0x02A1)
        this.Text = "Mouse hover";
      else if (m.Msg == 0x02A3)
        this.Text = "Mouse leave";
    });
}

El ejemplo no es muy bueno, porque para esta tarea en particular, ya tenemos eventos en la clase Button, pero espero que sirva para que se haga una idea.

Una ventana dentro de otra

2010-09-04T17:29:00.008+02:00

Este es un truco rápido y sencillo que, sin embargo, es difícil encontrar a la primera buscando en Internet:

¿Cómo meter una ventana dentro de otra?

¿Y para qué le puede hacer falta tal cosa? Un uso evidente sería crear un sistema de docking, que permita agrupar dinámicamente varias ventanas dentro de un contenedor; naturalmente, saber cómo meter una ventana independiente dentro de otro control es sólo el comienzo del proceso.

Pero existe otro uso más mundano: imagine que está creando un administrador de ventanas. Teóricamente, el administrador debe permitirle cambiar el estilo de la aplicación a petición del usuario: de ventanas SDI individuales, a una interfaz basada en pestañas e incluso a un sistema MDI. ¿Cómo deberían implementarse las ventanas para que pudiesen utilizarse con este gestor? Una posibilidad, que he utilizado en varios proyectos, es que las "ventanas" se diseñen como controles de usuarios (UserControl). El motivo es lo fácil que se añade un control dentro de otro, ya sea en tiempo de diseño o de ejecución.

Sin embargo, no es tan evidente cómo meter una instancia de la clase Form dentro de, digamos, un TabPage. Si lo intenta, sin más, provocará una excepción advirtiendo que "no se puede meter un control de nivel superior dentro de otro". El error, por fortuna, nos indica también la solución. Hay una propiedad poco conocida de la clase Form, que hay que poner a false. Por ejemplo, si queremos meter una instancia de la clase Form2 dentro de una nueva página de un TabControl, necesitaremos algo parecido a esto:

var f2 = new Form2();
f2.TopLevel = false;
f2.FormBorderStyle = FormBorderStyle.None;
f2.Dock = DockStyle.Fill;
var tp = new TabPage(
  tabControl1.TabPages.Count.ToString());
tabControl1.TabPages.Add(tp);
tp.Controls.Add(f2);
f2.Visible = true;

Aquí he metido la ventana, que puede haber sido diseñada al antojo del programador, dentro de un control de pestañas. Pero es igualmente posible meterla directamente dentro de un prototipo vacío de ventana hija MDI... o lo que se le ocurra.

Validación en Entity Framework

2010-08-22T20:27:00.016+02:00

Metodologías e ideologías

Debo comenzar confesando que la moda domain-driven me parece ridícula. Es cierto que la programación orientada a objetos es estupenda… y que el modelo relacional también lo es. También es cierto que, al mezclarlos, se produce un desajuste que en inglés llaman impedance mismatch. Pero los intentos de "resolver" el problema mediante la metodología domain-driven consisten, básicamente, en cargarse todas las bondades del modelo relacional, de la arquitectura cliente-servidor y, de paso, la mayoría de los avances aparecidos y probados en estos cuarenta años de bases de datos relacionales.

No es éste el lugar para explicar todo lo que tengo en contra del DD, por lo que me limitaré a un solo argumento. ¿Existe alguna diferencia básica, digamos, entre una aplicación "de negocios" y una aplicación, digamos, como Word o un sistema operativo? Claro que la hay: el dinamismo de las llamadas reglas de negocio. Usted puede escribir una clase para un procesador de texto y atiborrarla de reglas sobre el tratamiento de las mayúsculas. Probablemente, dentro de cinco años esas reglas seguirán siendo igual de malas o apropiadas. En cambio, las reglas para el funcionamiento de una aplicación de negocios cambian constantemente. Si usted enchufa esas reglas como parte de métodos de las clases "de negocio", tendrá que contratar a un nerd granujiento a jornada completa, para que cada vez que el dueño del negocio se cambie los gayumbos, cambie la programación de las clases afectadas, recompile y reinstale el sistema.

Por supuesto, esto es lo que todo nerd desea: un trabajo fijo a jornada completa, ya sea cambiando detallitos insignificantes de la clase Order o "tuneando" el núcleo de su instalación personal de Linux, que le deje tiempo para conectarse al Facebook y para jugar a dragones y mazmorras. Es comprensible. Otra cosa es que sea racional o eficiente. O bueno para alguien excepto para el propio nerd.

La cabra y el monte

Las modas, al final, visten a personas reales. Quiero decir, que si al artista se le olvidó la ranura en el pantalón para hacer pis, el portador de la prenda ya se las arreglará para orinar; eso, o reventará. Por mucho domain-driven que haya infectado la cabecita del pobre programador, en cuanto necesite hierba, la cabra irá al monte… o reventará, ya sabe. ¿Un ejemplo? Teóricamente, en el mundo ideal de nuestros guitar heroes con acné, cada clase debería ocuparse de su propia validación. Pero, ¡oh, qué penita!, los programadores reales que trabajan con Entity Framework han adquirido la costumbre de acumular validaciones dentro del código del método SaveChanges (hay varias formas de conseguirlo).

¿Es eso bueno, o malo? Hay de todo. Esperar a SaveChanges para comprobar que una fecha de nacimiento no pertenece al siglo XII, por ejemplo, es una soberana estupidez. Pero si la regla depende del estado de una entidad, no le queda más remedio que enredar con el administrador del estado: la pureza domain-driven exige que este estado sea externo a la entidad. Por ese motivo, era tan complicado utilizar entidades con servicios WCF en la versión anterior de .NET. Y por ese motivo, gracias al cielo, Microsoft ha terminado ciscándose en la pureza y regalándonos self-tracking entities en la nueva versión. Viva lo impuro cuando resuelve problemas.

¿Y qué dice la sacrosanta teoría sobre todo esto? En honor a la verdad, la Programación Orientada a Objetos dice que, en este caso particular, la centralización es mala. Y tiene razón… si se tiene en cuenta el contexto sobre el que se desarrolla esta metodología: un mundo en el que las principales extensiones a una aplicación se producen principalmente mediante la incorporación de nuevas entidades. Pero este no es el escenario característico de una aplicación de ventas, de préstamos o de Bolsa, donde es más probable que aparezcan nuevas reglas para los viejos objetos que nuevos objetos con nuevas reglas. El impacto de la modificación de las nuevas reglas es mayor si el código que las controla está disperso a lo largo y ancho de los ficheros individuales de clases de entidades.

Y hay más: observe que estas reglas de negocio suelen referirse al estado observable de las entidades de negocio. Traducido a código fuente: las reglas de negocio, por lo general, afectan a propiedades públicas de estas clases. Al fin y al cabo, estas reglas son establecidas por analistas funcionales… o por el propio jefe del cotarro; es decir, por gente que no tiene por qué enredarse con protected, private e internal.

Cabalgando la ola

La centralización, por lo tanto, no siempre es mala; digamos, entonces, que aceptamos que una parte de las reglas de negocio se implementan como parte del mecanismo de sincronización de los cambios con la base de datos. Sin embargo, ¡seguimos necesitando al nerd! Para cada cambio en las reglas, sigue siendo necesario recompilar la aplicación… y redistribuirla.

No sólo eso: imagine que su aplicación la utilizan varias empresas. O incluso, que la utiliza una sola empresa, pero que ésta tiene sucursales en distintos países, con diferentes legislaciones e idiosincrasias. Cada vez que en China cambien las reglas de descuentos para sujetadores, en la sucursal de Groenlandia tendrán que reinstalar el maldito software de ventas.

¿Y si movemos esas reglas fuera de la aplicación? Hablo de ubicar las reglas en un fichero de texto, de manera que la aplicación lo lea, digamos que al iniciarse. El contenido del fichero sería traducido a código ejecutable (eso es muy sencillo, con toda la tecnología que ofrece .NET) que se ejecutaría como parte del método SaveChanges del contexto.

Será más sencillo si muestro un ejemplo de reglas. La sintaxis concreta que he utilizado imita a la de C#, pero está claro que las variaciones son posibles:

class Order
{
  on insert
    Created = DateTime.Now;
  on update
    Modified = DateTime.Now;
  rule MustPaidBeforeShipping is
    Paid || !ShipDate.HasValue;
}

La explicación:

Las reglas se definen por clase. Esto es así por la forma en la que puede tener lugar la validación durante OnSavingChanges: el componente que ejecuta el script recorrerá los ObjectStateEntry modificados en el contexto. Para cada uno de ellos, se elegirá el conjunto de reglas a ejecutar o verificar de acuerdo al tipo de entidad asociado, y luego, al estado de la entidad.
Es recomendable que se respete la herencia. Si una regla se define en una clase base, debe respetarse también en las posibles clases derivadas, siempre que una de estas no la anule.
Como mínimo, se deben soportar dos tipos de reglas: verificaciones y asignaciones a propiedades. En el ejemplo, hay dos asignaciones a propiedades, separadas según el estado de la entidad, y una sola verificación, que al no mencionar el estado, se activará tanto para inserciones como para actualizaciones.
Cada regla tiene un identificador asociado. El escenario típico de estas validaciones será un proceso WCF remoto. Imagine que asociamos un mensaje de error directamente con la regla: ¿en qué idioma debería estar? Un servicio de capa intermedia debe evitar atarse a un idioma concreto, porque puede estar siendo utilizado por clientes configurados para idiomas diferentes. De todos modos, debería ser posible sustituir el identificador por un literal de cadena, para casos sencillos en que no se prevé la traducción a otros idiomas.
Las expresiones trabajarían, principalmente, sobre entidades aisladas, por lo que no habría que preocuparse por extensiones del tipo LINQ: si usted quiere verificar que el total de una orden no sea superior a un valor, por ejemplo, prográmelo donde realmente corresponde, es decir, en la base de datos. Entity Framework no le puede ofrecer garantías, llegados a este punto, de que el grafo de entidades asociados a la entidad modificada, esté completamente cargado en memoria. Sólo piense, por ejemplo, lo difícil que es verificar la unicidad de una columna en un proceso cliente, sin tener todas las entidades en memoria y sin lanzar una consulta adicional al servidor.

Sobre las expresiones soportadas: en principio, no haría falta complicarlas con índices y corchetes, por las razones antes expuestas. Las expresiones básicas serían constantes y "rutas de objetos" (object paths). Estas rutas siempre comenzarían por una propiedad de la clase que define la regla, o por una clase o espacio de nombres. En nuestro ejemplo, ShipDate.HasValue comienza por una propiedad de la clase Order, pero DateTime.Now es, evidentemente, una propiedad estática de una conocida clase. Este tipo de sintaxis es muy fácil de implementar y traducir.

Las expresiones, que son el núcleo de nuestro sistema, se traducirían como árboles de expresiones LINQ, que se pueden compilar a código nativo dinámicamente. En esto ya tengo también bastante experiencia: el sistema es sencillo y muy eficiente (lo he utilizado en filtros a la medida para un servidor RTD para Excel, implementado dentro de una aplicación de servicios de Windows).

En resumen

Se trata solamente, en esta etapa, de una propuesta: crear un componente que, a partir de un script externo, se ocupe de determinadas validaciones e inicializaciones dentro del Entity Framework. Es fácil señalar el método SaveChanges como el punto donde se insertaría el componente de validación. Probablemente existan más puntos donde se pueda actuar.

En principio, el script con las reglas puede estar ubicado en un fichero de texto. Esto sería apropiado si las aplicaciones clientes accediesen a las entidades a través de un servicio WCF. Sería este servicio quien centralizaría el manejo del script y determinaría las reglas a cumplir. Pero sería sencillo extender el mecanismo, en ausencia de una capa intermedia, ubicando las reglas en la base de datos, para simplificar el cambio de las mismas.

Por supuesto, escribo esto, en este momento, para recabar sugerencias.

Música para piano

2010-06-02T16:01:00.001+02:00

... pues eso: música para piano.

Trabajo en Delphi

2010-03-29T16:35:00.003+02:00

Se busca programador en lenguaje Delphi, abstenerse freelance, se valoraran conocimientos en base de datos SQL. Imprescindible Delphi.
Empresa situada en Madrid. Enviar curriculum a wis@worldwis.es.

(... y sí: dentro de poco habrá noticias sobre nuevos cursos de C#, y gracias a Marcos Santín, de Delphi, y más...)

Cagarse en el chocolate

2009-07-24T14:39:00.019+02:00

Serie: Los N Pecados Capitales

En la empresa de Willy Wonka, se fabrica un exquisito chocolate. Al menos, esa es la opinión general. La producción está a cargo de los umpalumpas: una extraña raza de friquis canijos, adictos a la programación en Java, a los que pagan con granos de cacao.

Los umpalumpas tienen la curiosa manía de inventarse canciones sobre la marcha, y luego pretender que se trata de tonadas tradicionales, de las de toda la vida. Por ejemplo, si un niño glotón se cae dentro del río de chocolate, improvisan una canción explicando por qué no se debe uno inclinar demasiado sobre la corriente. Si un proyecto de desarrollo fracasa estrepitosamente, se inventan melodías que hacen referencia a dominios escuálidos, programación ágil e inversión del control. Son pintorescos, estos personajillos.

Pero los umpalumpas tienen también una costumbre muy fea. Alex, un umpalumpa de Pontevedra, revuelve el chocolate fundido cuando siente que algo más se revuelve en su interior:

- Willy… ehm… señor Wonka.
- ¿Sí, Alex?
- Tengo un apretonciño de intestinos…
- Te aguantas. Esta barra de chocolate tenía que estar para ayer.
- ¡Pero es que me lo voy a hacer encima!
- Caga entonces dentro de la tina del chocolate.
- ¡¿Cómo?!
- Joder, Alejandrito, ¿tengo que dibujarte un diagrama de clases?
- Pero, ¿cómo vamos a echar mierda dentro del chocolate?
- A ver, ¿de qué color es el chocolate? Marrón. ¿Y la mierda? Marrón. Un poco de mierda espesa aporta crema al cacao.
- Pero… es que estoy un poco estreñido y estoy cagando boliñas, como las de las cabras…
- Pues mejor aún: chocolate con cacahuetes, y si las bolas son más grandes, con nueces y avellanas.

Por desgracia, la mierda de umpalumpa es sumamente corrosiva. Por su culpa, caen aviones, revientan naves espaciales, fallan sistemas de soporte vital en hospitales y se aplican dosis excesivas de radiación a pacientes de radioterapia. Será mierda, pero hay que tomársela muy en serio.

Hay mil y una maneras de cagarse en el chocolate. Por mencionar unas pocas:

Una aplicación para almacenar expedientes médicos, escrita en dBase, generaba claves primarias mediante el sucio mecanismo de contar los registros en el fichero y aumentar el valor en uno. Mientras el hospital tuvo un único ordenador en admisión, el chocolate sabía a ambrosía. Un día instalaron un segundo ordenador, y en algún momento, se crearon dos registros simultáneamente… con la misma clave primaria. Migrando la aplicación a InterBase, en el 2000, alguien tropezó con la historia clínica de un buen señor que había sufrido la extirpación de sus ovarios.
En la historia anterior, el error no se detectó porque los índices de aquella versión de dBase no permitían la comprobación de unicidad. Pero conozco un par de sistema implementados sobre Oracle en los que los “diseñadores” (es un decir) han evitado el uso de claves primarias concienzudamente.
La mismísima Borland se cagó, en su momento, en el chocolate de la casa. Cuando apareció Delphi 2, se produjo una ola de fallos en aplicaciones de servidor. La causa: en servidores con procesadores Xeon, fallaban determinadas operaciones sobre cadenas de caracteres, porque la implementación del tipo String no era thread-safe.
Todos sabemos, o eso espero, que no debemos acceder a los métodos de un objeto de ventana desde un hilo diferente a aquel en el que fue creada. Sin embargo, este tipo de violación no es verificada en ningún caso por .NET Framework v1.1. Muchas aplicaciones, por lo tanto, ignoran total o parcialmente el problema… hasta que migran a una versión más reciente de la plataforma y empiezan a reventar por todas partes. Entonces, improvisan cantando los umpalumpas, la culpa es de Microsoft, evidentemente.

¿Se ha dado cuenta ya de cuál es el patrón emergente? Se trata siempre de fallos que se producen al no tener en cuenta la concurrencia. La técnica ingenua de generación de claves primarias funciona mientras hay un solo ordenador. La implementación defectuosa de las operaciones de cadenas funciona incluso cuando hay varios hilos, pero siempre que exista un único núcleo. Los errores de reentrancia de Windows Forms y WPF se producen pero no se notan… hasta que el sistema revienta por causas desconocidas.

Cuando se trabaja con una base de datos relacional, además, en teoría existe una forma muy sencilla de evitar la mayoría de los errores: trabaje con transacciones serializables. ¡Pero la mayoría de los programadores, o desconocen su existencia, o tienen miedo a la pérdida de velocidad! De hecho, la mayoría de las operaciones complejas en las bases de datos habituales pueden implementarse con un nivel de aislamiento más bajo, si se ordenan inteligentemente las instrucciones. Esto es algo, sin embargo, que se encuentra fuera del alcance de la mayoría. Y quien sospecha que hay algo que puede fallar en su implementación, termina cagando dentro del chocolate: ya haremos algo cuando falle.

Otra fuente habitual de tropezones en el cacao: los errores de redondeo. ¿Cuántos programadores, de los que trabajan con aplicaciones financieras, tienen idea sobre los problemas de estabilidad numérica y sus consecuencias en el desarrollo? Es más fácil tener una idea vaga de que existe un problema "teórico", y dejar que sea el desdichado usuario el que hunda sus dientes en la mierda de umpalumpa. Sólo entonces merece la pena hacer algo.

¿Existe alguna solución mágica para evitar sustancias extrañas en nuestros alimentos? Por desgracia, sólo hay una forma, y requiere una cualidad personal muy extraña y poco valorada: la ética profesional. Pero estamos en crisis, y la ética es un bien caro y escaso. Al menos, deberíamos presionar a las autoridades europeas para que los productos de software lleven una etiqueta de advertencia, como las de los sándwiches que venden en las gasolineras:

"Puede contener trazas de cacahuetes, pescado, huevo, gluten
y mierda de umpalumpa."

Libro sobre Delphi Prism

2009-07-22T11:08:00.002+02:00

Nuevo libro sobre Delphi Prism

Ahora tengo prisa (reunión con cliente), pero luego editaré el post, e incluiré fotos y ampliaré el texto. ¡Libro recomendado, por supuesto!

El Bien y el Mal

2009-07-20T20:36:00.003+02:00

Lo único necesario para que el Mal triunfe, es que los hombres buenos no hagan nada.
(cita atribuida, erróneamente, a Edmund Burke, pero que no por ello es menos cierta)
(y no, no tiene nada que ver con la Informática)

Me descuido un poco... y veo que se me acumulan 211 comentarios en el último post. Eso es bueno, por supuesto: muchas gracias. Siento no haber estado disponible: estoy con el libro, el curso de EF y un software a entregar para ayer.

Y ahora pregunto yo: ¿sería buena idea si montásemos un foro? Principalmente para soporte y esas cosas. Me comprometo a entrar regularmente. Y tendría que haber una carpeta para "off-topics", que si no, sería demasiado aburrido. Tengo que preguntar primero a los que alojan mi página (los buenos amigos de la Delphi Magazine) sobre softwares compatibles con sus servidores, por supuesto...

Una decepción y un rayo de esperanza

2009-04-15T16:04:00.006+02:00

La decepción

Apartaos de este libro cuanto podáis: Essential LINQ (Microsoft .NET Development Series). Ni se me ocurriría comprar un libro de Calvert (ya he tenido la mala experiencia), pero pensé que al estar Dinesh Kulkarni en el potaje, la cosa cambiaría. ¡Qué error!:

Las dos terceras partes del libro son las típicas obviedades sobre LINQ for Objects que puede encontrar en Intuitive C# gratuitamente, o en el libro de Octavio sobre LINQ por una fracción del precio. Es el tipo de énfasis que hace un autor que odia las bases de datos y sólo le interesa hacer trinos y gorgoritos con el lenguaje.
El contenido sobre LINQ to SQL (un sistema ya condenado) es el doble o el triple (me niego a contar páginas) que el contenido sobre el Entity Framework.
... pero ni siquiera el contenido sobre LINQ to SQL es medianamente funcional, así que ya puede imaginar lo que hay sobre el EF.
Charlie Calvert nos obsequia con sus mañas características de escritor: apéndices sobre todo lo humano y divino (para engordar el libro y encarecerlo), incluyendo una tabla de seis páginas sobre los atajos de teclados en Visual Studio 2008 (que usted puede encontrar perfectamente en la ayuda de VS).

El rayo de esperanza

Este otro libro, Programming Entity Framework, de Julia Lerman, es harina de otro costal. Para empezar, tiene 792 páginas con un tipo de letra legible, pero compacto. Nada de trucos sucios para engordar artificialmente el contenido.

En segundo lugar, se tratan todos los temas necesarios: ESQL, los puñeteros formatos de bajo nivel para crear un esquema conceptual y mapearlo a una base de datos, el uso avanzado de procedimientos almacenados, los problemas actuales al intentar trabajar en múltiples capas (¡sinceridad, por una vez en la vida!), cómo usar EF desde ASP.NET y Windows Forms, y los problemas y soluciones en cada plataforma...

Además, y esto es muy importante, la autora escribe bien. No he terminado el libro, y me va a llevar un par de semanas, pero hasta donde he llegado, me siento satisfecho.

Perestroika

2009-04-04T15:39:00.023+02:00

El funcionario de la calva brillante con la mancha como un mapamundi se levantó y se dirigió hacia los micrófonos. Carraspeó y comenzó a hablar cansinamente, como hablaban los funcionarios de la extinta Unión Soviética:

- Daraguíe tavarischi - es decir, "hola, troncos" - El Soviet Supremo me ha encargado la honrosa tarea de comunicaros dos noticias. Una buena y una mala. La buena es que hoy ya es viernes.

Un murmullo de satisfacción teñida de falsa sorpresa recorrió la sala.

- La mala - titubeó, aunque sólo un momento - la mala es que lo nuestro no funciona.

Los ecos del murmullo cesaron abruptamente.

- ... y no me refiero a lo de enfriar en una nevera las semillas de patata antes de sembrarlas, para aclimatarlas al frío - el anciano hijo de Trofim Lysenko se levantó airado y abandonó la asamblea - sino a este invento del comunismo.

Una mosca atravesó la enorme sala zumbando. Nadie la detuvo.

- Sí, coño, hemos estado haciendo el panoli durante setenta años. Y para nada. Hemos matado de hambre a media Ucrania. Hemos jodido a conciencia a polacos, húngaros y checos, y a buena parte de Alemania. ¿Y todo para qué? Para que nuestros obreros pasen hambre y frío, para fabricar estos horribles coches y esos espantosos sintetizadores alemanes democráticos que se funden antes de terminar la primera estrofa de la Kalinka. Esto, maí vesyolye rebyata, no firula...

Los murmullos se reanudaron. El delegado de Dirkadirkastán alzó tímidamente la mano y preguntó:

- Y ahora, ¿qué?
- Ahora - el calvo hizo una pausa teatral - ahora... ¡perestroika!

En Redmond parecen estar también algo revueltos y perestroikos:

Self-tracking entities in the Entity Framework

Y ya era hora, coño. Ya era hora de que alguien se diese cuenta de que todo este invento del POJO, del POCO y del MOJO POCO no funciona cuando se trata de escribir aplicaciones multicapas. La vanguardia del proletariado, por supuesto, pondrá el grito en el cielo, pero de momento andan callados. Puede que no hayan comprendido lo que hay en juego. En realidad, los fundamentalistas javalinos suelen comprender muy pocas cosas.

Es verdad que los de Microsoft se asemejan más a los chinos que a los rusos: cada cierto tiempo se inventan una Revolución Cultural y no son muy ortodoxos en lo tocante al martinismo-fowlerismo. Además, acaban de perder al Gran Timonel. Y tienen una misma palabra para crisis y oportunidad: suena parecido a crisistunidad.

Mientras tanto...

2009-03-06T22:16:00.002+01:00

... y porque no solo de pan vive el hombre, un poco de rock instrumental, hecho en casa:

Everyday Hero

Dedicado a todos los que tienen que enfrentarse día a día con su correspondiente Mr. Butters.

Mr. Butters (I)

2009-03-02T18:53:00.010+01:00

Mr. Butters es un "experto" imaginario, que trabaja en una empresa imaginaria, y que "controla mogollón" sobre bases de datos, aunque la única base de datos con la que ha trabajado en su puñetera vida es Oracle 9, utilizando sólo los trucos que aprendió para Oracle 7. Es un tipo que desconfía de las foreign keys, que considera peligrosos los triggers y los procedimientos almacenados, y que prefiere que el acceso a datos se haga con ODBC... sobre todo por compatibilidad, coño, que somos una empresa seria.

Mr. Butters, por supuesto, es sólo un producto de mi febril imaginación. Cualquier coincidencia con la realidad, es un mero resbalón de mis neuronas.

The Waste Brain

Mr. Butters is the silliest dork, breeding
Incompetence out from the dead land, mixing
Idiocy and arrogance, stirring
Foolishness with an amazing lack of common sense.

Visual Basic kept us warm, covering
Bugs in forgetful snow, feeding...
(etc, etc)

Ajedrez

2009-02-28T18:01:00.004+01:00

Otra seta, perdón, libro sobre LINQ

2009-02-18T00:24:00.012+01:00

Cuando comparo este libro con una seta (y la seta sale ganando al final) no es sólo por la capacidad de propagación por esporas de los libros sobre LINQ sino, principalmente, por su potencial alucinógeno. Leo un par de páginas y alucino. Luego viene la resaca. Pasa un par de horas y siento el mono de volver a comprobar cuán malo es el libro. Y así, entre risas y risas, me lo he leído. Pero las setas tienen fibra y son buenas para el colon.

Vale, me he pasado. Si a usted le cuesta leer en pantalla, este libro puede sustituir a la ayuda en línea, siempre que renuncie al índice, a las búsquedas y a ese estilo seco de los documentos de Microsoft que tanto gusta a los amantes del dolor. De todos modos, supongo que tengo que justificarme. Ahí va eso...

El principal problema de (joder, qué pedazo de título)... bueno, de este título, es la bisoñez del autor, acompañada de un exceso de entusiasmo, buenrrollismo y grandes dosis de soberbia injustificada. Este es un libro de apenas 380 páginas, con los típicos listados sin abreviar y con un tipo de letra más grande que la del texto. A pesar de todo esto, el autor se permite escribir un ditirambo de cuarenta páginas en honor a los ORM... demostrando de paso que no tiene ni pajolera idea del asunto. Ahí va un sabroso "tip" (página 5):

Note: Writing stored procedures does not equate to bad design. On the contrary, stored procedures if managed correctly are an excellent alternative to dynamic SQL. If you use a code generator to create your CRUD stored procedures, or if you develop them by hand and have good oversight, in many cases you will be able to use them in conjunction with an ORM tool.

¡Gracias, gran Vijay (así se llama el pavo), por perdonar nuestras viles existencias! Pero siento interrumpir: usted, ¿ha entendido algo? ¿Son buenos o no los procedimientos almacenados? ¿Sólo si se escriben a mano, o si los crea una herramienta? Ah, ¿en ambos casos? Entonces, ¿para qué mencionar que mañana lloverá o no? El problema está en que el Gran Vijay "sabe" que los procedimientos almacenados sólo son buenos si sirven a los propósitos del Gran ORM. Pero soltar tal chorrada es peligroso. Te puede enemistar con esa bestia cejijunta del DBA (en cristiano, el Administrador de Bases de Datos). Los DBA's, cuando se enfadan, te dejan sin índices secundarios y te echan sal en el café.

"Claro, Marteens, cabronazo, pero nos has ocultado el contexto de la parida". Bien aquí tiene el contexto: el señor Mehta nos explica que la compañía X ha escrito software para un fabricante de comida para perros. ¿Y sabe qué?, pues que usaron procedimientos almacenados. La cosa se les escapa de las manos (claro, porque son unos pecadores relacionales). Y de repente, llega la gran oportunidad: pueden vender la aplicación a un fabricante de comida para gatos. Aquí viene la Segunda Parida:

With the increased development costs, Company X won't be making enough money to justify this deal [...] so they hire a consulting company to help reduce their overhead.

Vijay, hermanito, que nunca se te ocurra montar una empresa con los ahorros de papá, que te los vas a fundir. La consultoría, evidentemente, les endiña un ORM a la Compañía X, y según palabrita del niño Vijay, (they) optimize and normalize the company database. Lamento señalar que:

Lo de "optimizar y normalizar" suele resultar bastante costoso. Es como empezar de cero. Para que resulte viable, es obligatorio que la consultoría subcontrate programadores en algún país remoto del Tercer Mundo. Quizás los tiros vayan por ahí.
Ah, de repente la base de datos carece de "normalización". ¿Esa es una consecuencia de utilizar procedimientos almacenados?

Pero la diversión continúa:

Company X is able to eliminate the thousands of stored procedures (que ya funcionaban) and instead use "automagic" mapping features to generate its SQL. Development costs go down, profits go up and everyone is happy [...]

... especialmente el niño Vijay, que ya tiene el ejemplo canónico que siempre se escribe en los primeros capítulos. Menos mal que enseguida nos aclara que "this is an oversimplified example". Menos mal. Porque cuando la magia entra por la puerta, la inteligencia salta corriendo por la ventana.

Vale, reconozco que los escritores solemos rellenar los primeros capítulos con la misma alegría con la que los chinos echaban melamina en la leche para bebés. El problema es que los problemas continúan a lo largo del libro... excepto en las páginas que contienen información irrelevante, o en las que se limitan a tirar de la ayuda. Para no hacer esta masacre demasiado larga, aquí tiene un botón de muestra, sumamente divertido y revelador. El hermanito Vijay intenta explicarnos por qué prefiere no usar var para declarar variables locales con tipo implícito (p. 149):

The reason to be explicit with the types is the same reason that you strongly type variables in the world of software development: to make it easier to understand and gain a negligible performance increase.

Las negritas son mías, por supuesto: resulta que este señor no comprende un sencillísimo truco del lenguaje en que programa, y sin embargo, le recomienda pasar a un sistema que exige un conocimiento en profundidad de ese mismo lenguaje y de su modelo de objetos.

Claro, que si usted se siente molesto conmigo puede dar ejemplo de solidaridad y comprarse el engendro. Pero recuerde que, cada vez que alguien compra un libro malo, el Diablo aparece y mata un cachorrito.

La verdad es que me extrañó un poco el ejemplo de la comida para perros. Pero luego recordé que son los musulmanes quienes consideran que el perro es un animal impuro. Los hindúes, en realidad... bueno, no recuerdo si los consideran seres divinos o si se los comen.

Hat tip to Alfredo Novoa: se casan con ellos.

Garantías

2009-02-09T02:07:00.012+01:00

La Programación no es trabajo ni para cobardes ni para desmemoriados. La máquina es una bestia salvaje atada por una cadena: si queremos ganarnos la vida con ella, tenemos que despojarnos del miedo irracional. Pero también tenemos que recordar, en todo momento, cuál es la longitud de la puñetera cadena.

Cuando hablo de "cadena", usted debe entender "contrato": cada pieza de software debe dejar bien claro qué es lo que hace por nosotros, siempre que le proporcionemos lo que especifica el contrato. Math.Sqrt nos calculará la raíz cuadrada de un número, siempre que le proporcionemos un número no negativo. El indexador de la clase genérica Dictionary nos devolverá el valor asociado a una clave, aunque sólo cuando la clave se haya almacenado antes. Ignorar la existencia de estos contratos nos puede llevar a uno de dos problemas:

Pedimos la raíz cuadrada de menos uno, y el león nos come una oreja.
El problema anterior suele pasar una sola vez. El aprendiz de domador suele quedar aterrorizado, y de ahí en adelante no se acerca al león, excepto cuando su abogado está presente (para que se coma al león en caso necesario). El abogado, por desgracia, termina siendo un problema mayor que el propio león.

A continuación, voy a presentarle varias joyas que muestran los problemas que se pueden presentar cuando el programador decide ignorar, por excesivo terror, las garantías que le ofrecen los contratos. El problema con estas "joyas" es que, cuando uno se las encuentra, pierde un tiempo valioso intentando decidir si:

Se trata de una genialidad.
O se trata de una simple cagada.

El 99% de los casos corresponde a la segunda opción, pero uno se niega a perder tan pronto la fe en el género humano.

La primera perla negra tiene que ver, como no podía ser de otro modo, con la ya mencionada clase Dictionary. Estoy harto de ver este fragmento de código en el software de cierta empresa imaginaria:

if (dict.ContainsKey(key))
    dict[key] = value;
else
    dict.Add(key, value);

Esto podría pasar como buena programación en Ankh-Morpork, pero aquí solemos ser un poco más exigentes. Un buen día, uno de los leones, el método Add, se adelantó al gato y le comió la lengua al programador, cuando éste intentó insertar una clave duplicada en un diccionario. De ese día en adelante, el programador pincha primero el diccionario con una vara larga, para ver si ya existe la clave. En caso afirmativo, actualiza el valor asociado a la clave; de lo contrario, inserta el nuevo par clave/valor. El problema es que el mismo resultado se obtiene con menos charla:

dict[key] = value;

En efecto, cuando se realiza una asignación sobre el indizador un diccionario, si exista la clave, se actualiza el valor; de lo contrario, se inserta. Hay dos posibilidades: o el programador lo sabía, y se le olvidó... o nunca se tomó la molestia de leerse la documentación. Prefiero pensar lo primero. Al fin y al cabo, la memoria viene genéticamente determinada, y uno no debe reñirle al prójimo por sus genes.

Por cierto, y si me permite el paréntesis, ¿sabía usted que podemos inicializar un diccionario genérico como si se tratase de una vulgar colección? ¡Es que un diccionario genérico es una colección! El quid está en saber qué tipo de colección: sus elementos son instancias de la clase genérica KeyValuePar. Esta es la técnica:

private Dictionary<int, string> d =
    new Dictionary<int, string>()
    {
        {1, "Uno"},
        {2, "Dos"},
        {3, "Tres"},
    };

Preste atención a la coma, aparentemente superflua, que sigue al tercer par de valores. Se trata de un sencillo, pero poco conocido, truco sintáctico que permite añadir o quitar pares, en cualquier momento, sin preocuparnos por el carácter especial del último par. Este mismo truco se aplica a los inicializadores de objetos, e incluso a la declaración de tipos enumerativos. Si le parece una barbaridad y una concesión (hay gente para todo), recuerde que en C^# el punto y coma es un terminador, no un separador. ¿Qué hay de malo en querer usar la coma también como terminador, en estos casos?

Vamos ahora a otra garantía que solemos olvidar... o simplemente desconocer. Esta vez, la garantía tiene que ver con el propio lenguaje:

double d = 0.0;
if (cond)
    d = 1.0;
else
    d = 2.0;

Naturalmente, la inicialización de la variable local sobra:

double d;
if (cond)
    d = 1.0;
else
    d = 2.0;

No pasa nada porque se deje d sin inicializar... aparentemente. La instrucción que sigue lo garantiza, sin importar cuál de sus ramas se ejecute. Por supuesto, en este caso sencillo, habría sido más fácil escribir todo el código de esta manera:

double d = cond ? 1.0 : 2.0;

El programador que escribió el primer fragmento ha olvidado la sección de la especificación de C^# que explica el concepto de asignación definida. La ha olvidado, o nunca se ha tomado la molestia de leerla.

Otro disparate frecuente debido al temor a lo desconocido:

private double f()
{
    double d = 0.0;
    OpenXXX();
    try {
        if (cond)
            d = f1();
        else
            d = f2();
    }
    finally {
        CloseXXX();
    }
    return d;
}

En realidad, el código anterior combina varios disparates debido al olvido o desconocimiento de las garantías de los contratos. Para empezar, vuelve a sobrarnos la inicialización de la variable local: la rama try del bloque try/finally nos garantiza la asignación definida de la variable, y la rama finally es irrelevante, si no utilizamos d en su interior. Tenga en cuenta que, si se ejecuta el finally, nunca llegaremos a la instrucción return.

Pero la zarpa que realmente aterra al programador del ejemplo es la posibilidad de ejecutar un return dentro de la rama try, por desconocimiento (u olvido) del funcionamiento de esta instrucción. Podemos ejecutar ese return sin problemas, y el código se simplifica entonces enormemente:

private double f()
{
    OpenXXX();
    try {
        return cond ? f1() : f2();
    }
    finally {
        CloseXXX();
    }
}

El código simplificado es más corto, más comprensible y, probablemente, algo más eficiente, y ya no hablemos de la elegancia. ¿Moraleja? Conozca sus deberes y derechos, tal y como los especifican los contratos de su software, y así será mejor programador. O, mejor aún: RTFM (again).

Más extraña que la ficción

2009-01-26T12:44:00.018+01:00

Había una vez una empresa imaginaria, habitada por escarabajos peloteros que practicaban el cargocultismo mientras arrastraban sus fragantes bolitas de excrementos y esperaban el regreso de John Frumm. Un buen día, apareció un feo insecto en sus instalaciones, amenazando con devorar los cimientos corporativos. Para exterminarlo, los escarabajos ejecutaron la danza ritual del pollo de Skinner y practicaron un exorcismo.

Demasiado folklore acumulado en un solo punto del espaciotiempo, en mi opinión. Un punto imaginario, quise decir...

... y si enmascarar un bug mediante el simple expediente de unir dos instrucciones try/catch no es bailar la danza del pollo de Skinner, que vuelva John Frumm y lo vea.

Por supuesto, el problema real es que el nido del monstruo sigue estando ahí, no tan evidente como el dinosaurio de Monterroso, pero aún amenazante.

Libro sobre concurrencia

2008-12-16T18:15:00.004+01:00

Llevaba anunciándose desde hace unos cuantos meses, y finalmente está disponible: Concurrent programming on Windows, de Joe Duffy, quien, por cierto, nada tiene que ver con la señorita que canta aquello de "You got me begging you for mercy"...

El libro entra por derecho propio en la categoría tocho, en el buen sentido de la palabra. Si tiene un poco de cuidado con los testigos potenciales, puede arrojarlo desde una primera planta sobre cualquiera de sus enemigos. Asegúrese antes, sin embargo, de que el destinatario no lleva casco.

Observe que la sigla .NET no aparece en el título: en realidad, el libro trata sobre concurrencia utilizando el API nativo de Windows y también .NET. Esa es la buena noticia. La mala es que las partes que tratan sobre .NET suelen ir después de las disertaciones sobre el API nativo, y confieso que llego con sueño a la fiesta.

Si usted ya tiene experiencia con hilos y sincronización, puede que el libro no le enseñe muchas cosas nuevas: la culpa no es del autor, por supuesto, sino que a veces en realidad no hay "más allá". Me ocurría, en su momento, con InterBase: muchas personas me preguntaban por qué no escribía un libro sólo sobre InterBase... y la respuesta era y es que no había mucho de lo que escribir.

Task panels

2008-12-15T14:27:00.002+01:00

Por si a alguien le hace falta, he subido un fichero a la sección de ejemplos de mi página con el código de un control para paneles de tareas:

Haga clic sobre la imagen para ir a la página de ejemplos, donde encontrará las instrucciones pertinentes.

Consenting adults, consenting ducks

2008-11-29T17:49:00.017+01:00

Hace poco, escribía en los comentarios de otra entrada que esto la Informática no es una ciencia, sino una ingeniería... y Alfredo Novoa respondía que ni siquiera eso. La siguiente anécdota demuestra cuán cierta es, desgraciadamente, esta afirmación.

La historia viene a cuento de una característica "novedosa" llamada duck typing. Según sus defensores, si una clase tiene métodos Add, Remove e Insert, y un indexador, ¿qué hay de malo en asignar una instancia de la clase a una variable de tipo ICollection? Eso es, en pocas palabras, el duck typing: si algo camina como un pato, nada como un pato, vuela como un pato (es decir, las tres cosas las hace mal) y además caga como un pato (es decir, constantemente), entonces, según los adeptos del mecanismo, tiene que ser un pato. Naturalmente, yo digo que puede ser una oca, o un pato robot, o el conde Duckula. No es buena idea tratar al señor conde como a un vulgar pato. Y así lo hice ver aquí, aunque de pasada:

Internal affaires

Algún tiempo más tarde, alguien se quejó en un comentario... y como no suelo llevar cuenta de los comentarios tras cierto tiempo, no me percaté del hecho hasta hace un par de días. Esta es el comentario:

Cuál es el problema que le ves al "duck typing". Los que lo utilizan, suponen que los programadores son "consenting adults".

Consenting adults, eh...

En principio, eso serviría también para justificar las conversiones de tipos bestiales que son el pan de cada día en C++. Al fin y al cabo, si yo sé que un puntero se representa como un entero de 32 bits en mi plataforma, ¿por qué no voy a poder incrementar ese entero en cuatro para acceder al siguiente elemento de un vector? Consenting adults. No estamos locos. Sabemos lo que queremos...

Ahora bien, ¿es tan peligroso el duck typing como las conversiones bestiales? Veo dos problemas principales:

Una pila no es simplemente un objeto que tiene dos métodos Push y Pop. Esos dos métodos, además, tienen que satisfacer determinado contrato. En la práctica, si el pato es mío, es un descuido mío el que no haya hecho que la clase correspondiente implemente la interfaz deseada. Si el pato es ajeno, es muy peligroso asumir que puedo tratar a un águila como a un pato simplemente porque ambos tienen pico.
Si el pato es ajeno, además, los problemas con el versionado de clases pueden ser peliagudos. O "plumiagudos", si lo prefiere...

En cualquier caso, me hace gracia el uso de la teoría de los consenting adults. Hace poco, en Alemania, un buen señor pidió a otro consenting adult que le cortase la picha y se la comiese (en ese orden). El otro, efectivamente, cumplió con lo pactado. Luego mató a la víctima, como ésta había solicitado, se comió un muslo, y puso el otro a secarse para hacer jamón. Al caníbal lo pillaron, y lo llevaron a juicio. E inmediatamente, se armó el correspondiente revuelo: ¿por qué condenarlo? ¿No se limitó a hacer lo que el otro pirado le pedía? ¿No eran una parejita de consenting adults?

Evidentemente, tengo mi propia opinión al respecto. Yo, al canibalizado, si lo pillase antes de ser devorado, no le haría nada. Al fin y al cabo, si quiere que otro lo mate y se lo zampe, es su problema. Es, en efecto, un consenting adult: se supone que sabe lo que hace. Mi problema es con el caníbal: es un pirado, y tengo serias sospechas de que intentará repetir la acción. La próxima vez, no estoy seguro de que vaya a encontrar un consenting adult para satisfacer sus antojos culinarios. Es un individuo peligroso. No sé si eso bastará (junto con lo que ya ha hecho) para enviarlo a la cárcel, pero en mi barrio no lo quiero.

Lo mismo se aplica a los duck typers. ¿De manera que usted es aficionado a transformar el agua en vino, perros en patos y patos en borricos? Ah, claro, usted sabe lo que hace. Pero lo que usted hace es peligroso. No me gustaría verle enredando con mis proyectos...

¡No publique vectores!

2008-11-28T00:20:00.004+01:00

Nueva píldora orientada a objetos:

Las propiedades o métodos que devuelven vectores son una mala idea

¡Te lo dije!

2008-11-18T09:50:00.022+01:00

Permítame que me eche unas risas... ya, sí, ya puedo continuar...

Sin duda, usted conocerá a Beavis y su amiguete Butt-head. Son dos friquis metaleros de dibujos animados, que se pasaban la vida intentando "anotar"; meter un gol, ya me entiende... Cuando la serie llegó a su fin, el creador, jocosamente, escribió un epitafio para sus personajes:

- They never scored.

Nunca "anotaron". Pobrecillos. Lo mismo, por desgracia, se puede decir del compilador de Borland para .NET: nunca llegó a marcar gol. Murió virgen aunque no casto.

¿Una tragedia? Nah. Tragedias son las guerras, el hambre, las enfermedades. Concedo que puede ser una molestia. Mi sabor favorito de Häagen-Dazs ya no se vende en mi barrio. Es molesto, e irritante, eso sí. De todos modos, tengo todo el derecho del mundo a decir: ¡TE LO DIJE!

... y nada más que la verdad

Veamos los hechos desnudos: un buen día, la compañía antes conocida como Inprise decide que su negocio de compiladores es una ruina. Segrega la compañía (igual que las babosas segregan un moquillo adherente), bautiza CodeGear al retoño, y anuncia que tiene un montón de novios. Pero la petición de mano se demora infinitamente y toda la villa comienza a sospechar que se trataba de un farol. Tras varias peripecias, aparece el Príncipe Azul, un tal Embarcadero, cabalgando radiante sobre su moto acuática, y carga con la solterona (¿le habrán pagado para que se la llevase de una puñetera vez?).

Uno esperaría que, tras tan accidentado romance, la parejita se pusiese a fabricar pequeños ogros, como Fiona y Shrek, pero... es que Fiona ya aportaba al enlace dos monstruitos: Delphi para Win32 y Delphi.NET. Ah, sí, y esa abominación de "Delphi para PHP" y otros engendros que mejor dejo sin clasificar. Bueno, menos trabajo para el ogro, ¿o no?

Entonces, la comedia se transforma en drama: Shrek tira Delphi.NET por la ventana y toma en adopción el brillante hijo de un vecino, llamado Oxygen, aka Chrome. ¿Sabía Shrek lo que iba a hacer con su vástago desde el primer momento? ¿Se convenció a su pesar de que Delphi.NET no tenía arreglo? A todas estas, los representantes de Fiona parecen haberse puesto de acuerdo en mostrar su mejor sonrisa a los medios. Pero uno imagina que la procesión debe ir por dentro...

El bien o el mal

No me entienda mal: Oxygen es un producto que me gusta y que recomiendo sin reservas. De hecho, en cierta manera lo considero un familiar cercano. Freya ha copiado impúdicamente algunas ideas de Oxygen/Chrome, como la palabra clave method o los niveles de visibilidad. Muchas características comunes son fruto de una evolución paralela: es un indicio de que ambos proyectos arribaron a los conclusiones lógicas en esos puntos. A la vez, me empeño en creer voluntariosamente que puede que alguna característica de Freya se haya podido filtrar a Oxygen/Chrome.

¿Es el párrafo anterior una recomendación de compra de Delphi Prism? ¡Más despacio, por favor! Si usted odia orgánicamente las llaves, le recomendaría que comprase Oxygen. Delphi Prism es Oxygen más toda la morralla de "compatibilidad" con los obsoletos módulos heredados de CodeGear. ¿Alguien en sus cabales se atreve a programar con dbExpress.NET... cuando dbExpress nativo terminó siendo un fracaso sonado? Si va a programar con Oxygen, mi recomendación es que utilice ADO.NET, o los productos de acceso a datos de RemObjects. Cualquier otra decisión, significaría empantanarse por puro capricho.

En cualquier caso, Embarcadero tiene un bonito problema: Delphi Prism y Delphi for Win32 son dos lenguajes muy diferentes. ¿Tendrá secuela este peliculón?

Genericidad en vez de typeof

2008-11-17T09:28:00.018+01:00

Permítame un breve descanso entre tantos disparates. He estado usando últimamente una técnica sencilla y conocida para identificar posibilidades de simplificación en código heredado de .NET v1.1. La técnica consiste en buscar métodos, en el código fuente, que reciban un parámetro de tipo System.Type, para considerar la posibilidad de convertir dicho método en un método genérico.

El caso típico se encuentra casi siempre en el "gestor" de ventanas:

public interface IFormManager
{
    Form ShowForm(Type formType);
}

ShowForm recibe un tipo de ventana como parámetro, y debe encontrar una ventana abierta cuyo tipo sea exactamente el especificado. Si la encuentra, debe activarla y pasarla a primer plano. En caso contrario, debe crear una ventana de este tipo, y mostrarla. La regla que he mencionado establece que el método anterior debería transformarse en algo parecido a lo siguiente:

public interface IFormManager
{
    T ShowForm<T>()
        where T: Form, new();
}

Puntos a destacar:

El parámetro de tipo T se ha restringido de dos maneras. En primer lugar, debe ser una clase descendiente de Form. Usted, naturalmente, puede exigir de sus ventanas que desciendan de alguna clase más concreta, o que implementen algún tipo de interfaz general, o ambas cosas a la vez.
Por otra parte, he exigido que las ventanas tengan un constructor sin parámetros. Este es un requisito opcional, que no valdrá en todos los casos, pero que he incluido aquí para simplificar un poco el código.
Observe que será imposible, al utilizar este método, que el compilador pueda "inferir" el parámetro de tipo. Si no ha trabajado aún con la inferencia de tipos en llamadas a métodos genéricos, traduzca la oración anterior así: "siempre tendremos que indicar explícitamente el tipo de ventana" (algo bastante razonable).

¿Qué hemos ganado con esta transformación? Antes, para mostrar una ventana, teníamos que escribir código como el siguiente:

// "manager" implementa "IFormManager"
MiVentana v = manager.ShowForm(
    typeof(MiVentana)) as MiVentana;

Si no efectuamos la conversión de tipos, obtendremos como resultado un valor de tipo Form, sin más adornos. En cambio, con la versión genérica obtendremos el tipo originalmente deseado:

MiVentana v = manager.ShowForm<MiVentana>();

Para cerrar el círculo, le mostraré una sencilla implementación inicial del tipo de interfaz:

public class FormManager : IFormManager
{
    private List<Form> forms = new List<Form>();
 
    public T ShowForm<T>()
        where T: Form, new()
    {
        foreach (var f in forms)
            if (f.GetType() == typeof(T))
            {
                f.Show();
                f.BringToFront();
                return f as T;
            }
        var frm = new T() { Visible = true };
        frm.FormClosed += (sender, e) =>
            forms.Remove((Form)sender);
        forms.Add(frm);
        return frm;
    }
}

Creo que la primera parte, la que ejecuta el bucle, es fácil de comprender. Luego he complicado un poco las cosas: observe que puedo ejecutar el constructor sin parámetros del tipo T gracias a las restricciones establecidas sobre el parámetro genérico. Si mis ventanas no se pudiesen construir de esa manera, sino que requiriesen parámetros, entonces tendría que utilizar un poco de reflexión. Tenga presente, no obstante, que la ejecución de un constructor sin parámetros sobre un parámetro de tipo genérico es implementada por el compilador como una llamada al API de reflexión (lo sé porque Freya hace exactamente lo mismo).

¿Ve esas llaves tras la llamada al constructor? Se trata simplemente de una asignación a la propiedad Visible del formulario recién creado. Podía haberla sustituido por una llamada al método Show, pero quise mostrar un ejemplo de inicialización de objetos. Luego, resolvemos un problema más serio: FormManager lleva una lista de las ventanas abiertas (o abiertas e invisibles). Las ventanas se añaden al ser creadas, pero ¿cuándo se eliminan de esta lista? Para ello, asociamos un manejador al evento FormClosing de cada nueva ventana. En vez de crear el manejador como un método independiente, he preferido utilizar una expresión lambda.

Comentarios adicionales: ¿para qué hace falta una interfaz IFormManager? ¿No sería más sencillo diseñar ShowForm como un método estático, dentro de una clase estática? La clave del uso de IFormManager está en la posibilidad de usar diferentes implementaciones según nos convenga. La manía de recurrir a métodos estáticos a la primera es una manifestación de lo que yo llamo "la fiebre del singleton". Es cierto que, al final, nuestro gestor de ventana tendrá que proveer algún singleton, como la variable "manager" de mi ejemplo de uso. Pero la aparición del singleton debe retrasarse todo lo que podamos.

Antología del Disparate - III

2008-11-12T23:13:00.015+01:00

Advertencia: Cualquier parecido con
la coincidencia, es sólo una sospechosa irrealidad...

uando, meses atrás, se me ocurrió la idea de escribir sobre el cargocultismo estaba pensando, en particular, en el problema artificial, creado por mis amigos imaginarios, que voy a discutir a continuación. Repasemos la definición: el cargocultista es el individuo que practica determinados rituales técnicos porque sabe, o ha oído decir, que a otros les funcionan, pero sin comprender realmente cómo se supone que tienen que funcionar.

En el mundo de la programación, uno de esos rituales misteriosos tiene que ver con la creación de gestores especiales para distintos módulos de la aplicación, sobre todo cuando se trata de proyectos grandes. Una aplicación "decente" tiene que definir, por fuerza, un "gestor" de menúes, un "gestor" de excepciones, un "gestor" de formularios... y así hasta el aburrimiento o la bancarrota. Para ser exactos, una parte importante de esta secta de cargocultistas no utiliza la palabra "gestor" sino manager, que se supone que debe darle un poco más de dignidad al engendro.

Como suele ocurrir en todos los casos de cargocultismo, la propia idea de un gestor de menúes y ventanas no es mala. ¡Todo lo contrario! Estos módulos suelen ahorrar mucho código repetitivo, y tienen la bonita propiedad de dejarse reutilizar fácilmente de un proyecto al siguiente. Incluso cuando se utilizan en un único proyecto, nos ofrecen la libertad de hacer cambios notables en la interfaz de usuario sin necesidad de retocar todo el código. Visual Studio, por ejemplo, nos permite elegir entre una aplicación MDI tradicional o una en la que los documentos aparecen en páginas paralelas accesibles por pestañas. Lo verdaderamente malo, es inventarse uno de estos gestores sin saber por qué, para qué o cómo.

Cuello de botella

A diferencia de disparates anteriores, esta vez el problema no está en una simple instrucción equivocada, sino en el diseño global de un módulo. Los problemas comienzan con la decisión, consciente o inconsciente, de esta gente de ignorar el mecanismo preestablecido para la traducción en .NET y de montar un barroco sistema basado en ficheros XML externos. El vínculo entre cada elemento de la interfaz y su correspondiente cadena se realiza manualmente. Supongamos que usted quiere añadir una etiqueta a un formulario que debe decir "Total". De acuerdo a la metodología de estos señores:

Primero debe ocurrírsele un nombre global para identificar la etiqueta. No se les ocurrió generar ese nombre a partir del nombre del control y del formulario donde se encuentra.
Luego tiene que ir a cada fichero XML de traducción y crear una entrada que traduzca el identificador al correspondiente idioma.
Cada formulario tiene un método Traducir. No crea que se trata de un método virtual heredado: la herencia visual es algo desconocido en esta metodología. Tiene que añadir una instrucción manualmente a Traducir en la que asignará a la propiedad Text de la etiqueta, el resultado de una llamada explícita a un método que busca en un diccionario en memoria la traducción correspondiente.

Usted se dirá que... bueno, es bastante trabajo, claro... pero con un poco de disciplina... etc, etc. ¡Ah, cuán equivocado estaría! ¿No le he dicho aún que esta gente trabajaba con SourceSafe, para el control de versiones? Imagine lo que ocurre cada vez que dos programadores intentan programar dos formularios que nada tienen que ver entre sí: ¡se tienen que pegar por el acceso a los ficheros de idiomas!

De todas maneras, aunque no se produjese este increíble cuello de botella, el sistema es inaceptable:

Microsoft ofrece, de serie y sin coste adicional, un mecanismo idéntico en funcionalidad y sin ninguno de estos problemas: ficheros de recursos y ensamblados satélites.
El sistema de Microsoft no le obliga a añadir código manualmente en ningún momento.
El sistema de Microsoft le permitiría, incluso, ahorrar trabajo suponiendo la existencia de un "idioma neutro", para el cuál no tendría que mantener una tabla de recursos adicional.
El sistema de Microsoft es verificable en tiempo de compilación: si compila, funcionará. En cambio, el invento en cuestión utiliza cadenas como claves en el diccionario. Resulta imposible verificar automáticamente la existencia de errores de mecanografía. Por supuesto, si esta gente hubiese usado enumerativos para las claves, el problema se resolvería... pero los dioses ciegan a aquellos a quienes quieren destruir.

Moraleja parcial: no hay que reinventar la rueda, si además, va a rodar más despacio.

Escarnio de la locura

Pues bien, queridos amiguitos, hay también un menú diseñado de acuerdo a esta locura con sistema. Hay claves con formato de cadenas, que tienen que transmitirse desde el código al fichero externo y viceversa, hay versiones del menú para cada idioma soportado y todo lo demás. Pero me voy a centrar en un aspecto muy concreto: en cómo se maneja la ejecución de los comandos del menú.

Cada vez que se ejecuta un comando del menú principal, se invoca un manejador de eventos situado en la ventana principal. No crea que hay un manejador diferente para cada comando, lo cuál habría sido relativamente sencillo de conseguir: todos los comandos van a parar al mismo método. Y ese método, cómo no, contiene una inmensa instrucción switch, que toma la cadena de caracteres designada como clave del comando para ejecutar el código apropiado.

¿Y en qué consiste ese "código apropiado"? Maravíllese: en una llamada a un método global estático de una clase independiente, a la que llamaremos Acciones, que se encuentra en un gigantesco fichero C^#.

Nuevamente, tenemos un fichero que se convierte en un cuello de botella.

Claro, los conflictos por el acceso al fichero de acciones sólo tendrían que surgir cuando se modificase la estructura del menú... ¿o no? Resulta que no: cuando esta gente tiene que mostrar una ventana que permite una sola instancia, incluye, en el fichero de acciones, un bucle explícito para buscar si existe ya una instancia del tipo de ventanas en una lista global. Si la encuentran, la activan. Y si no, la crean. Y este código se repite tropecientas y tantas veces, una por cada ventana de este tipo, en el fichero de acciones.

Con un poco de reflexión, el código común se podría haber reducido a una simple llamada.
Pero mejor aún, el switch original ni siquiera tendría que haber pasado por la clase Acciones, sino que tendría que llamar directamente a métodos estáticos de las clases de ventanas correspondientes. De esa manera, cualquier cambio en la forma de mostrar una ventana, se aislaría dentro del código de la propia ventana.
Para rematar, esta gente ni siquiera utilizó una metodología uniforme para la creación y activación. A veces llamaban a Show, otras veces combinaban BringToFront, Activate y Focus; a veces cambiaban la forma del cursor, y en otros casos, mostraban una ventana splash con el mensaje "Espere un poco...". Esto complica mucho limpiar el código.

Con todo, lo peor es que a estar alturas todavía les cuesta creer que este sistema sea un error: el cargocultismo susurró en sus oídos que necesitaban un "gestor de menúes" para su aplicación "seria", y ahora tiemblan cada vez que mis tijeras podan porciones cada vez mayores de este cadáver exquisito. Mientras limpio los fluídos putrefactos de mis instrumentos de corte, veo ojos asustados y oigo el coro de plañideras a mi alrededor. Sonrío tranquilizadoramente, pero compruebo que mi sonrisa parece cada día más siniestra.

Y es que uno termina hartándose, ¿sabe?

Antología del Disparate - II

2008-11-11T00:03:00.013+01:00

Advertencia: Cualquier parecido con
la realidad, es sólo una sospechosa coincidencia...

stamos otra vez en una aplicación que maneja un buen puñado de hilos. El "genio" que la programa ya ha tomado consciencia de los peligros de la falta de sincronización, y dedica su tiempo libre a repartir bloqueos a diestra y siniestra. Este es un bello ejemplo de cómo se las gasta el caballerete (imaginario, of course):

private bool flag;
 
public void YoQueSe()
{
    if (Monitor.TryEnter(flag))
    {
        // Código "sincronizado" ...
        Monitor.Exit(flag);
    }
}

¿Puede ver los disparates? Son varios, por supuesto. ¿Cómo cree que se manifestó el problema? ¿Se atreve a imaginar cómo se le pudo haber ocurrido esta barbaridad a su perpetrador?

Esta es, amigo mío, la declaración del método TryEnter de la clase Monitor:

public static bool TryEnter(object obj);

Como puede ver, el parámetro del método debe ser un Object, o más exactamente, una referencia a un objeto. Como Object es la clase base final del CLR, cualquier cosa que pasemos como parámetro servirá, a efectos del sistema de tipos. El método incluso admite que pasemos un valor de tipo Boolean...

... con la única pega de que Boolean es una estructura, un tipo con semántica de asignación por valor. Para poder pasar un Boolean donde se espera un objeto, .NET aplica la operación llamada boxing al valor. Es decir, crea un objeto temporal del tamaño adecuado, y copia en su interior el valor que queríamos pasar. ¿No queríamos una referencia? Tras el boxing ya tenemos una.

¿Y qué hay con la llamada final a Exit? Este es el prototipo de este segundo método:

public static void Exit(object obj);

Nuevamente, nos piden un objeto. Y el compilador no protesta si pasamos un valor de tipo Boolean. Simplemente mete el valor en una "cajita" y pasa el puntero a ésta. ¿La pena? Pues que las llamadas a TryEnter y Exit deberían utilizar el mismo objeto... y cada vez que se realiza el boxing, ¡se crea una instancia temporal diferente!

¿Qué consecuencias cree que tenía el disparate? Sorprendentemente, ¡ninguna!... al menos, mientras la aplicación se mantuvo ejecutando sobre .NET v1.1. Fue al migrar a .NET 3.5 que estos errores empezaron a ser detectados en tiempo de depuración. La llamada a Exit comenzó a generar una excepción, advirtiendo que se intentaba desbloquear a través de un objeto no bloqueado. Claro, sería una estupidez que el CLR tuviese que verificar en cada llamada a Exit que el objeto pasado no sea una instancia creada por boxing: penalizaría a los buenos programadores para evitar que los peores metiesen la pata.

¿Se da cuenta de que, ni siquiera en .NET v1.1, la aplicación estaba protegiendo la sección de código de marras? Si en algún momento se produjeron errores de sincronización en dicha sección, o fueron ignorados... o se perdieron gracias a la demencial política de manejos de excepciones de mi aplicación imaginaria. Observe que hay un segundo error en el código mostrado: se supone que las llamadas a TryEnter y Exit deberían estar asociadas a una instrucción try/finally.

Y ahora viene lo mejor: ¿cómo imagina que se le ocurrió la burrada al genio? El uso de TryEnter nos permite reconstruir los hechos. En realidad, el aprendiz de brujo intentó usar la instrucción lock en primer lugar. ¡Pero lock sí que puede detectar cuando alguien le pasa una estructura en vez de una referencia! Y como lock no se dejaba violentar, el muy pillo tradujo el código que suponía que se generaba para dicha instrucción. Pero como manazas que es, incluso eso lo hizo mal...

Moraleja: odio repetirme pero, por favor, esos genios que deambulan por ahí, ¡RTFM!

Antología del Disparate - I

2008-11-10T17:15:00.027+01:00

Advertencia: Cualquier parecido con
la realidad, es una cochina casualidad...

n buen señor, presuntamente un experto en casi todo, bien pagado y considerado, recibe el encargo de crear una "base de datos en memoria"... tarea que, para el resto de nosotros, los mortales, consiste en meter objetos en un contenedor. Monta su colección basada en ICollection (estamos en los remotos tiempos de .NET v1.1) y añade internamente un par de Hashtable's para permitir el acceso directo dada una clave. Como las "cosas" que tiene que guardar en el contenedor no tienen una clave primaria clara, decide con buen tino añadir una clave artificial, que implementa de la siguiente manera:

public class Cosa
{
    private static int staticId;
    private int instanceId;

    // ...
}

El campo estático staticId contiene el valor a asignar a la próxima "cosa" que se cree, mientras que instanceId representa la clave única y artificial de cada instancia. Esta clave, como sospechará, se asigna automáticamente durante la construcción de instancias.

El problema es que la aplicación en cuestión consume hilos a manos llenas, y es posible que se creen dos "cosas" a la misma vez. Nuestro sujeto, que no es del todo lerdo, sabe que tiene que protegerse, y diseña el siguiente constructor:

public Cosa()
{
    // ¡INCORRECTO!
    Interlocked.Increment(ref staticId);
    instanceId = staticId;
}

¿Dónde está el disparate? ¿Cómo, y cuándo, cree usted que se manifestará? ¿Cómo se puede corregir?

El disparate, evidentemente, está en el uso incorrecto de la clase Interlocked. Se trata, en realidad, de un caso flagrante de cargocultismo. El "experto" conocía un par de datos correctos:

El patrón de asignación de un identificador autoincremental exige el uso de primitivas de sincronización, o de lo contrario, pueden producirse anomalías.
La clase Interlocked permite sustituir determinados usos de la instrucción lock de forma más eficiente.

Hasta ahí, todo bien: el experto había oído sonar campanas. Lo malo es que no sabía dónde. No se tomó la molestia de leerse hasta el final la ayuda de Interlocked (¿para qué?). Peor aún: no se preguntó cómo demonios se las arregla esta clase para que el código sea equivalente a un lock en toda regla. El concepto de "actualización atómica" le resultó tan extraño como escuchar a un marine hablar con Alpha Bravo Charlie a través de su mágica radio-cocotero.

Para explicar qué es lo que está mal en el código original, es mejor que le presente el código correcto:

public Cosa()
{
    // ¡CORRECTO!
    instanceId = Interlocked.Increment(ref staticId);
}

Como ve, el arreglo es sencillo: hay que asignar a instanceId el resultado de la llamada a Interlocked.Increment, en vez de desperdigar la llamada y la asignación entre dos instrucciones; enseguida veremos por qué. En caso de que no existiese Interlocked, la forma correcta de realizar esta operación sería:

public Cosa()
{
    lock (typeof(Cosa))
        instanceId = ++staticId;
}

Los más puristas verán con malos ojos el bloqueo sobre el typeof, pero lo he escrito así para abreviar. Pues bien: el código anterior es equivalente al código correcto. El motivo por el que usamos lock es evitar que, entre la modificación de la variable global y la asignación de su valor en el campo de la instancia pueda cederse el control a otro hilo. Si esto ocurriese, podría ser que recibiésemos un valor duplicado en instanceId. La clase Interlocked, precisamente, nos garantiza que el incremento de la variable estática y la copia del valor correcto como valor de retorno tengan lugar de forma atómica, sin posibilidad de que otro hilo pueda acceder a la variable estática modificada. La llamada a Increment, por otra parte, es mucho más eficiente que el uso de lock.

Por el contrario, en el código erróneo original, el "genio" ha roto la atomicidad de la operación... por no tomarse la molestia de examinar bien la documentación o meditar sobre el problema. ¿Cuándo se manifestó el error? Esta es la parte que suele infundir horror en los corazones sensibles: el error fue detectado casi por casualidad:

Por una parte, para que se produzca el error, tienen que intercalarse las operaciones de dos hilos de manera muy especial. Estos problemas no se detectan con una simple ejecución... si no hay suerte.
Para rematar, y esto es tan grave como todo lo anterior, la aplicación tenía un sistema de "manejo" de errores demencial, que se tragaba todas las excepciones gracias a cantidades industriales de instrucciones try/catch repartidas uniformemente a lo largo y ancho del código. En caso de producirse un error, la aplicación se lo callaba taimadamente.

Un buen día, fue necesario sacar una copia de la colección de "cosas" en un dataset vulgar y corriente... y ahí fue que saltó la violación de la unicidad.

Y usted quizás se pregunte si mi personaje imaginario (¡porque cualquier parecido con la realidad... ya sabe!) se merece que lo vapulee de este modo. Pues sí, se lo merece. En este caso, el resultado de su metedura de pata es que, en ocasiones, la aplicación veía muertos y perdía registros fantasmas. Nada grave: sólo se trataba de dinero. Imagine, en cambio, que la aplicación controlase aviones, o trenes de pasajeros, o que monitorizase constantes vitales en un hospital. ¡Todos a la cárcel! Hace mucho, migrando una aplicación de altas hospitalarias desde dBase a InterBase, tropecé con el expediente médico de un caballero al que habían, aparentemente, operado de los ovarios. En realidad, por un error parecido, la clave primaria del expediente de este señor coincidía con la clave del expediente de una mujer, y los registros de detalles eran compartidos por ambos expedientes.

Moraleja: las optimizaciones son buenas. Pero, ¡por favor!, léase bien el manual antes de experimentar con métodos que no conoce.

Vea también: Más ligero que un bloqueo.

¡Cuidado con el Entity Framework!

2008-11-02T19:48:00.008+01:00

Una advertencia rápida: he recibido unos cuantos correos de programadores que quieren empezar proyectos con el ADO.NET Entity Framework, un añadido tardío del SP1 de Visual Studio 2008. Esta semana iré respondiendo todo el correo atrasado que tengo, pero prefiero ir adelantando aquí mi opinión.

Y mi opinión es que el Entity Framework (EF, en lo sucesivo) está demasiado verde. La versión del SP1, es cierto, está muy adelantada con respecto a las versiones liberadas durante las betas... pero eso es ya un síntoma de la fase actual del proyecto. En concreto, ¿cuáles son mis pegas?

La principal: fallos de estabilidad. Puede que sea un problema de mi sistema, pero me he encontrado con errores al realizar operaciones tan simples como añadir una nueva tabla a un modelo ya existente. Me he encontrado de repente con tres errores en el código generado (relacionados con las "asociaciones", es decir, las claves externas). Al eliminar la tabla nueva y la tabla con la que se relaciona, me he encontrado en la extraña situación de que ninguna de las dos tablas vuelve a aparecer en el esquema relacional de la base de datos (pero sí aparecen en el Server Explorer y en SQL Server Management Studio).
Creo que, por razones "ideológicas", se han dejado funcionalidad importante fuera. En concreto, el atributo identity de SQL Server es como si no existiese. Para crear una "entidad" cuya clave es autoincremental, disponemos de un constructor sin parámetros... y de un método estático que obliga a pasar un valor explícito para la clave.
En realidad, detalles entrañables como el anterior son puntos del diseño, no una omisión o un descuido: los javalíes exigen que sus ORMs generen el código mínimo, y esas "chorradas" de claves automáticas entran en la categoría Prescindible para esta gente. Bien, me parece estupendo... pero queda usted avisado de lo que encontrará.
Tenga muy presente que el EF debe funcionar con SQL Server, Oracle y lo que se presente. Eso puede ser una ventaja para determinadas aplicaciones. Pero para quien vaya a trabajar directamente con SQL Server, es más un problema que otra cosa. Ya le he dicho que se ignoran las identidades. Resulta que también se ignoran las columnas rowversion, que son la clave para acelerar el trabajo con la concurrencia optimista en SQL Server.
La documentación es un asco. Lo siento, "asco" es la palabra exacta. De momento, hay que irse a Internet, y el individuo que ha creado la ayuda es un sádico que ha repartido cada bit de información útil entre cincuenta páginas diferentes, con el único propósito de hacerle sufrir. No hay libros sobre este tema: hay anunciado uno de David Sceppa en Amazon... para el 2010. Espero que el mío esté muchísimo antes. Ah, sí, hay vídeos en inglés, pero tardas una hora de metraje en enterarte de lo que podrías leer en cinco minutos. Una de las razones por la que los vídeos siguen siendo solamente "material de apoyo" en mis cursos a distancia.
No tengo aún experiencia de primera mano en cómo funciona un sistema en tres capas basado en este invento. Es cierto que hay ahora un nuevo tipo de "ADO.NET Data Services", basado en HTTP. No sé cuán rápido puede ser este sistema para aplicaciones que necesitan verdaderamente rapidez y escalabilidad. Y a juzgar por lo que he visto, y por las experiencias con las tres capas en LINQ for SQL, me temo lo peor. Pero repito: todavía no he llegado a tanto.

Resumiendo, no lo veo muy claro. No es una opinión definitiva, pues como es natural, todavía me falta soltura con la herramienta. Puede que dentro de tres meses me parezca una maravilla. Mi consejo, para que no me malinterprete, es: sea prudente. En los mapas antiguos, en las zonas inexploradas se colocaban advertencias como Hic sunt dracones. Algún animal extraño nada en las ignotas aguas del ADO.NET Entity Framework. Puede terminar resultando un dragón, una sirena o un inofensivo calamar gigante.

... y para que se haga una idea de cómo bajan las aguas, eche un vistazo a este documento:

Voto de reprobación

Le advierto que las críticas vienen, en este caso, del lado oscuro de la Fuerza (es decir, de los javalíes).

El escarabajo pelotero

2008-11-01T17:59:00.001+01:00

Serie: Los N Pecados Capitales

Algunos sostienen que fue Aldous Huxley; la mayoría cree que fue J.B.S. Haldane, pero es también posible que se trate de una anécdota apócrifa. Cuentan que un teólogo victoriano preguntó a Haldane, biólogo de profesión, si podía deducir algo sobre Dios a partir de su huella en el Universo. La respuesta fue: "no sé, quizás una desmedida afición por los escarabajos".

Puede que Dios ame a los escarabajos, pero lo que es seguro es que algunos escarabajos han sido adorados como dioses. El escarabajo pelotero (Scarabaeus sacer) es una especie de cucaracha acorazada que se pasa el día entero recogiendo mierda y amasándola en forma de pelotitas. Es un verdadero comemierdas, porque se alimenta de esa misma materia prima, e incluso deposita sus huevos dentro de las bolas de estiércol para su incubación.

Los egipcios, que para algunas cosas había que darles de comer aparte, observaron a los pequeños escarabajillos saliendo de su incubadora de mierda y dedujeron, los muy listos, que el bicho se autoenterraba en porquería para luego renacer, como ave fénix... aunque algo más pringada. Compararon la faena cotidiana del escarabajo, arrastrando bolitas de caca, con la sagrada misión de Ra, el dios encargado del disco solar. Y añadieron este bicho de mierda a su interminable lista de dioses, diosecillos y otros seres espirituales.

Más tarde, cuando el cristianismo llegó a Egipto, los coptos, que no andaban muy finos con esto de las metáforas, vieron en el escarabajo un símil anticipatorio del sacrificio de Cristo. En algunos libros de la época, se llega a llamar a Cristo el "bonus scarabaeus": el buen escarabajo. Esto es lo que yo llamo una metáfora de mierda...

En Informática, un escarabajo pelotero es el desgraciado que cree que las aplicaciones se escriben acumulando minúsculas pelotitas de mierda, una sobre la otra, de manera progresiva, a la vez que se canta una alegre canción. Hay escarabajos, no obstante, que creen que lo de la canción es opcional. Les va más el chasquido del látigo.

Un buen escarabajo pelotero es un individuo "constructivo", en el peor de los sentidos. ¿Hay que ordenar una lista? Fácil, se dice el insecto. Planta sus pezuñas sobre el primer elemento, y busca el menor de los restantes elementos. Si es diferente del primero, intercambia ambos. Luego pasa al siguiente elemento y repite el algoritmo. ¿Funciona? ¡Pues claro que funciona! Y es que he elegido al ejemplar más inteligente de la especie a la vez que el algoritmo más sencillo. El problema es que nuestro insecto ignora que existe una técnica llamada quicksort, y que a partir de cierto tamaño, su uso se convierte en una necesidad. De manera que ya podemos identificar uno de los síntomas del trastorno:

Pobre pensamiento algorítmico

Ahí está el verdadero problema: no se trata de desconocer la existencia de un algoritmo dado, sino de la arrogancia que a veces, por desgracia, viene aparejada con el desconocimiento. Y si un escarabajo se permite ignorar la Algorítmica, no se le ocurra hablarle de estructuras de datos.

El daño que puede causar este angelito depende de lo alto que se encuentre en la jerarquía de una empresa. Imaginémoslo jefe de un proyecto que comienza. ¿Cómo lo haría? La necesidad de resultados inmediatos podría con él... y se lanzaría a rodar bolitas de mierdas, sin importar que el montón de bolitas se parezca más a una pirámide que al castillo que tiene que construir. Ya se encargarán los de marketing de colgar un gran cartel a la entrada de la pirámide que diga: "CASTILLO".

Pero lo peor es que nuestro sujeto es ahora un jefecillo, y ya no tiene que ensuciarse las manos en mierda, porque para eso tiene su equipo. Este es el resultado:

Un ciego, para dirigir a videntes, les obligará a vendarse los ojos

Mientras menos información suministre a su equipo, el buen señor se sentirá más seguro. Nadie podrá darse cuenta a tiempo de su ineptitud. Y si la pirámide de bolitas de mierda se derrumba, la culpa siempre será los esclavos.

¿Tiene arreglo un escarabajo pelotero? Todo depende de cuán alto haya logrado reptar. Si el individuo está bajo su mando, hay una sencilla solución: cree un ambiente laboral intelectualmente estimulante. Organice seminarios internos, y haga rotar al ponente. Traiga revistas técnicas y libros a la oficina. El amor propio obra milagros.

Por el contrario, si el escarabajo está o estará por encima de usted en la jerarquía de mando, sobre todo si tiene potestad para interferir en su trabajo... huya. A esas alturas, el buen señor estará convencido de que ha llegado a su posición gracias, precisamente, a lo que él considera sus virtudes (ver el Principio de Peter), y cualquiera que contradiga su estilo, será visto como un enemigo peligroso. Váyase. Déje que su pirámide de estiércol se derrumbe sobre su cabeza. Ya se las apañará para renacer de entre la caca.

Cargocultismo

2008-04-26T20:21:00.007+02:00

Serie: Los N Pecados Capitales

Durante la Segunda Guerra Mundial, las tropas americanas desembarcaron en muchas islas cuyos habitantes habían tenido poco o ningún contacto con la civilización occidental. Ante los ojos de estos nativos, se desarrollaba un drama sacado de la ciencia ficción: unos seres curiosos, venidos de muy lejos, que realizaban ceremonias incomprensibles, a través de las cuales obtenían un nivel de bienestar material antes desconocido en la zona.

Uno de aquellos seres, por ejemplo, pasaba horas hablando con una extraña caja de la que sobresalían cuerdas de metal. Al parecer, aquellas conversaciones con la misteriosa caja conseguían que en la isla se posaran gigantescos pájaros de hierro, procedentes de la tierra de los antepasados, de cuyos vientres se extraían toneladas de comida, armas y otros objetos deslumbrantes y probablemente útiles. No, no se trataba de dioses, pero era evidente que aquella tribu había descubierto cómo contactar con sus antepasados y recibir la correspondiente bendición material.

Llamaba también la atención el que buena parte de estos marines fuesen de piel oscura... como la mayoría de los nativos, pues he olvidado aclarar que mi historia tuvo lugar en la Melanesia. Esto hacía que la idea de contactar con los antepasados para recibir un cargamento resultase más creíble: los negros de aquella tribu lo habían logrado, ¿no? En la mente de estos melanesios comenzó a forjarse la image de un tal John Frumm (¿John from America, quizás?) un marine negro que prometía volver para ayudar a los nativos tras la guerra.

Naturalmente, terminó la guerra y John Frumm no regresó. O si regresó, no lo reconocieron. Ante la ausencia, ¿por qué no intentar seguir el camino de Frumm? Tallaron radios de madera de cocotero, y pintaron líneas con hollín sobre zonas despejadas. Nativos con hojas de palmeras en sus manos imitaban el código de banderas de los norteamericanos, con la esperanza que aquel baile que habían visto ejecutar a John Frumm atrajese el cargamento de los antepasados a las islas.

Aún hoy, "tropas" de melanesios desharrapados desfilan en algunas islas con rifles de madera al hombro. El fenómeno se conoce como cargo cult y, como puede sospechar, ha sufrido algunos cambios en su necesaria evolución. Por ejemplo, para algunas sectas, los blancos se oponen a revelar el secreto del "cargo", y periódicamente estalla la violencia contra los pocos occidentales que tienen a mano. Ha surgido también algún mesías nativo que ha reclamado ser un avatar de John Frumm, y ha propiciado el correspondiente cisma entre los cultocarguistas.

La Informática está llena de cargocultistas: personas que han visto a otras usar con éxito determinada técnica, y que luego se lanzan a repetir la ceremonia sin entender realmente de qué se trata. Por ejemplo, todo el mundo ha leído sobre la maravillosa revolución que se produjo cuando Santa Programación Orientada a Objetos se encarnó entre los mortales, allá por los tiempos de gloria de C++. Por lo tanto, cuando es necesario escribir una aplicación para bases de datos, intentan utilizar eso de los "objetos". Y establecen principios como: "sólo es profesional aquel que define una clase Cliente". O: "tenemos que usar UML, o Java, o servicios Web... aunque no tengamos ni puñetera idea de por qué, pues es lo que hacen los programadores serios". Amén, hermano.

Observe que el cargocultismo es un mal diferente del síndrome del pollo de Skinner. En este último, se cree en la existencia de una relación causa/efecto inexistente, mientras que el cargocultismo se basa en una conexión real, que verdaderamente funciona... excepto que el cargocultista no comprende por qué. ¿Otra diferencia? Nadie confesaría voluntariamente que actúa como un pollo de Skinner, mientras que el cargocultismo tiene cierta aura de respetabilidad a su alrededor. Cuestione a un cargocultista, y parecerá que está cuestionando los principios más básicos de la profesión.

Además, tengo mejor opinión de un pollo de Skinner que de un cultocarguista. En cierto modo, todos hemos sido pollos de Skinner: el aprendizaje y la experiencia son la medicina contra ese estado. Por el contrario, es difícil curar a un cargocultista.

Y es que, en este mundo, mucha gente sigue esperando el regreso de John Frumm.

El Pollo de Skinner

2008-04-19T13:09:00.026+02:00

Serie: Los N Pecados Capitales

Burrhus F. Skinner fue un famoso psicólogo estadounidense, mundialmente conocido por sus trabajos en la escuela conductista; aparte de lo anterior, y sin menoscabo de lo dicho, fue también un redomado cabrón (y que me perdonen sus descendientes y herederos). No es éste el momento de explicar el adjetivo, sin embargo. Sólo quiero contar uno de sus muchos experimentos.

Skinner puso un pollo frente a una caja que, de manera totalmente aleatoria, recompensaba al animalito, de cuando en cuando, con una golosina. El minúsculo cerebro del ave, no obstante, intentaba establecer una relación causa/efecto entre sus acciones y las recompensas. Si los pollos hablasen, ésta sería una posible transcripción de sus pensamientos:

¡Vaya, se ha abierto la caja! ¡Y qué gusano más sabroso había dentro! Veamos, ¿qué estaba haciendo cuando se abrió la caja? Entonces movía el cuello, de arriba a abajo. Repitámoslo. Arriba. Abajo... Nada, recórcholis... ¡espera, se vuelve a abrir! Gulp... Parece que si levanto una pata en el segundo movimiento, funciona. Ahí vamos... Espera, debo haberlo hecho mal. Corrijamos el movimiento de la cola... ¡Abrete, maldita seas!

Los pollos de Skinner terminaban elaborando complicadas danzas con el propósito de influir en la apertura de la caja de las golosinas. A pesar de todo, la caja se abría por motivos completamente distintos...

Muchos programadores y analistas se comportan como los pollos de Skinner. Se enfrentan a sistemas complicados, cuyo funcionamiento no conocen a fondo. Tras mil peripecias, logran que la aplicación funcione, pero atribuyen la causa del correcto funcionamiento a factores equivocados. Y el toque de brujería termina transformándose en un Principio, con mayúsculas, que todo recién llegado debe acatar, so pena de terribles torturas.

¿A santo de qué cuento esta historia? No sea mal pensado: estaba recordando algunos casos pintorescos que he conocido como consultor, y se me ocurrió recopilar algunos de los patrones, o más bien antipatrones, que son frecuentes en este mundillo. El primer antipatrón que me ha venido a la mente es el del Pollo de Skinner. Pero habrá más...

Espectros

2008-04-13T22:23:00.010+02:00

La ley de Beer establece que un rayo de luz se atenúa exponencialmente al atravesar un material dieléctrico, como el vidrio. Esta ley es necesaria para reproducir materiales transparentes coloreados, como en la siguiente imagen, que copio del post anterior:

La mayoría de los ray tracers, XSight RT incluido, implementan la ley de Beer asociando un filtro a estos materiales. El código correspondiente, en XSight RT, está ubicado dentro del método Trace que heredan todos los samplers del motor:

if (attenuation)
{
   // Exponential attenuation inside transparent media.
   filter.blue *= (float)Math.Exp(attFltr.blue * info.Time);
   filter.green *= (float)Math.Exp(attFltr.green * info.Time);
   filter.red *= (float)Math.Exp(attFltr.red * info.Time);
}

Esta parece ser la extrapolación más "natural" de la ley de Beer para que se pueda aplicar a luz multicromática. Sin embargo, es fácil darse cuenta del problema que crea esta implementación. Para intervalos pequeños, es posible controlar los parámetros para dar con cualquier color deseado para el vidrio. Para intervalos grandes, sin embargo, cualquier componente del filtro de atenuación que sea menor que la unidad, terminará eliminando completamente el correspondiente canal de color de la imagen.

Por ejemplo, si digo que mi material tiene un filtro de atenuación con componentes 1, 0, 0 (para el rojo, verde y azul), estaré consiguiendo un vidrio rojo. Si cambio el filtro a 1, 0.5, 0, lograré que los objetos delgados de este material sean de color naranja... pero para objetos más gruesos, la luz terminará atenuándose hacia el rojo puro.

¿Es esto un comportamiento "natural"? Evidentemente no, sino que se trata de un comportamiento inducido por la implementación de los colores en el ray tracer. Esto me ha llevado a investigar, por simple curiosidad, sobre cómo podría implementarse un ray tracer que trabajase con píxeles de cuatro, cinco o más canales espectrales. Hay, sin embargo, muy poca documentación sobre este asunto, aunque me consta que algunos programas comerciales implementan recursos parecidos. Si usted sabe algo sobre el tema, le agradecería cualquier pista.

... y se me ocurre otra idea: buena parte del código consiste en instrucciones por triplicado que manipulan los tres componentes básicos de color de un píxel. ¿Sería posible idear una representación diferente del color que simplificase estos cálculos? Por ejemplo, ¿tiene algún sentido el ray tracing con colores en el espacio HSV? ¿Simplificaría el código? ¿Lo haría más eficiente? De momento, es una pregunta abierta...

Para terminar, una curiosidad: a primera vista, es lógico pensar que una esfera de cristal tintado debería mostrar un tono mucho más claro en los bordes, en comparación con su centro, ya que en los bordes el camino a recorrer sería menor, y se produciría menos atenuación. Sin embargo, esto no ocurre así, y puede buscar una esfera "real" de cristal para comprobarlo.

¿Por qué? Es sencillo: resulta que los rayos de luz que emergen en la zona cercana al borde viajan proporcionalmente un trayecto más largo de lo que pensamos, por culpa de las leyes de la refracción. De hecho, ocurre algo interesante e insospechado: hay una parte del interior de una esfera de cristal que, al mirarla de frente, no podemos ver, debido también a la refracción. Esto es fácil de comprobar generando imágenes de esferas de vídrio con esferas opacas más pequeñas en su interior. Es muy probable que este comportamiento se aproveche en algún truco de magia. Se lo preguntaré al espíritu de Houdini.

XSight RT v1.5

2008-04-09T00:19:00.005+02:00

Nueva versión pública de XSight RT v1.5, también para .NET Framework 3.5. La descarga contiene el instalador del ejecutable, la ayuda y un puñado de escenas para pruebas. No he incluido el código fuente.

En esta versión, se incorpora la generación concurrente de escenas, con un modo dual, que reduce casi a la mitad el tiempo de generación en ordenadores con doble núcleo (algo menos en procesadores de un solo núcleo con hyperthreading). Además, ya funciona el material glass, y puede utilizarse un color para el cristal (según la ley de Beer). Hay también soporte para normales perturbadas, los pigmentos crackle y bubbles, cilindros y esferas de cuarto grado, una operación merge para materiales transparentes (equivalente a union, pero eliminando las superficies internas). Y se ha mejorado la velocidad, en general, del núcleo.

Más ligero que un bloqueo

2008-03-31T20:59:00.014+02:00

Seamos sinceros: si usted necesita un bloqueo, no va a conseguir un recurso menos costoso que el propio bloqueo. Ahora bien, es muy diferente si lo que usted necesita no es exactamente un bloqueo, sino parte de la funcionalidad del bloqueo. En tal caso, hay alternativas.

Hace poco me encontré en esta situación, añadiendo concurrencia a XSight RT. En las últimas versiones (no publicadas todavía) dos hilos pueden ocuparse de una misma escena, generando bandas disjuntas sobre un mismo objeto PixelMap (los mapas de bits internos del API de XSight RT). De este modo, los dos hilos pueden trabajar sin molestarse mutuamente. El conflicto se produce cuando hay que ejecutar un evento para avisar al cliente del API de que hay una banda nueva que se puede mostrar incrementalmente en la ventana de salida. En el código original, sin soporte de hilos, ésta era una tarea del sampler. En el nuevo código, por inercia, este código se duplicó en cada hilo: cada uno intenta notificar al cliente, cuando se ha acumulado trabajo o ha pasado suficiente tiempo.

¿Primera solución? Proteger ese código mediante un bloqueo, por supuesto:

if (SeDanLasCondiciones())
   lock
   {
      Avisar();
   }

Esto es matar gorriones a cañonazos. Un bloqueo, implementado aquí mediante la instrucción lock, que el compilador traduce en llamadas a la clase Monitor, se encarga en realidad de dos tareas que se pueden separar:

Comprobar que el código protegido no pueda ejecutarse simultáneamente por más de un hilo.
Si un hilo solicita el bloqueo mientras está concedido a otro hilo, el hilo se pone en modo de espera.

Pasar al "modo de espera" puede ser costoso, de acuerdo a la técnica con la que se haya implementado el bloqueo. En el peor de los casos, si se suspende el hilo mediante llamadas al API de Windows, esto provoca un pequeño terremoto en el planificador de tareas: tenga presente que se produce una transición al modo kernel del sistema operativo.

Para su tranquilidad, es muy poco probable que Monitor, y por consiguiente la instrucción lock, implemente la espera de esta manera. Lo más probable es que intente esperar un instante antes de tomar medidas drásticas y tomarse el somnífero.

No obstante, en mi ejemplo, ni siquiera hace falta esperar. ¿Que un hilo intenta notificar y encuentra que alguien se le ha adelantado? ¡Estupendo! ¡Ya no necesita notificar sobre nada! La única parte que necesitamos del bloqueo es la funcionalidad de exclusión mutua... y para esta tarea sencilla, existe un mejor mecanismo. Observe:

private int access;


public bool ReportProgress()
{
   int elapsed = Environment.TickCount;
   if (elapsed - lastReport > MIN_INTERVAL)
   {
      if (0 == Interlocked.Exchange(ref access, 1))
      {
         lastReport = elapsed;
         listener.Progress(progressInfo);
         Interlocked.Exchange(ref access, 0);
      }
      return !progressInfo.CancellationPending;
   }
   else
      return true;
}

Este código está ubicado en la clase Scene, y los dos hilos comparten una instancia de la misma. Por lo tanto, ambos hilos están usando el mismo campo access, declarado dentro de Scene. Este campo se utiliza en la zona resaltada del método, a través de métodos estáticos de la clase Interlocked.

Primero se ejecuta el método Exchange. Este método intercambia el valor almacenado en la variable con el valor que pasamos como parámetro, y nos devuelve el antiguo valor de la variable. Además, nos ofrece la garantía de que todo este meneo lo hará de forma atómica: no se producirán intromisiones durante su ejecución. Nosotros asumiremos que el valor "normal" del campo access es cero. ¿Qué pasa si intentamos intercambiar el cero por un uno, y descubrimos que ya tiene un uno? Simplemente, que alguien se nos ha adelantado. En tal caso, renunciamos a notificar, pues ya alguien se ha ocupado del asunto. De lo contrario, si Exchange devuelve cero, tendremos la seguridad de que nadie más ejecutará la notificación... al menos, mientras no reasignemos un cero en access. Esto es precisamente lo que hacemos al terminar con la notificación, dejando la vía libre para la próxima notificación.

Vea también: Antología del disparate I.

Superesferas

2008-03-04T08:46:00.005+01:00

El dado de la imagen está modelado mediante una "superesfera" que se puede describir mediante la ecuación x^4 + y^4 + z^4 = 1. Al tratarse de una ecuación de cuarto grado, se puede resolver algebraicamente, algo que XSight RT hace muy eficientemente. El resultado es la figura del dado: un objeto a mitad de camino entre una esfera (de las de toda la vida) y un cubo. Si en vez de elevar a la cuarta potencia, usásemos exponentes mayores, la figura iría aproximándose más al cubo... pero la ecuación dejaría de tener una solución algebraica, y tendría que resolverse mediante el método de Newton.

Las texturas del tapete y del propio dado están modeladas, naturalmente, mediante el clásico y eficiente ruido de Perlin.

Grietas

2008-03-01T00:02:00.005+01:00

Observe el cambio en el "suelo", respecto a la imagen del post anterior: he añadido un patrón que en inglés se conoce como crackle. Lo interesante es que está basado en los diagramas de Voronoi, que se definen como el conjunto de líneas equidistantes respecto a un conjunto de puntos aleatorios en el plano. Si a un robot lo situas en una habitación con objetos calientes, para evitar acercarse demasiado a ellos, tendría que calcular el diagrama de Voronoi asociado, para moverse a lo largo de las líneas del mismo.

En mi imagen, se ha utilizado el crackle para el "pigmento" del plano, pero podría utilizarse también para trucar los vectores normales, y simular que el plano está ligeramente arrugado. Esta técnica, aplicada a una superficie reflectante, puede usarse para simular la superficie del mar.

Para una versión del I King
J.L. Borges

El porvenir es tan irrevocable
Como el rígido ayer. No hay una cosa
Que no sea una letra silenciosa
De la eterna escritura indescifrable
Cuyo libro es el tiempo. Quien se aleja
De su casa ya ha vuelto. Nuestra vida
Es la senda futura y recorrida.
El rigor ha tejido la madeja.
No te arredres. La ergástula es oscura,
La firme trama es de incesante hierro,
Pero en algún recodo de tu encierro
Puede haber una luz, una hendidura.
El camino es fatal como la flecha.
Pero en las grietas está Dios, que acecha.

Físicamente imposible

2008-02-24T23:25:00.007+01:00

No es difícil verlo: ¿qué es lo que "falla" en la siguiente imagen?

No se trata de la distorsión de los mosaicos: la imagen ha sido generada con una lente cilíndrica. Este tipo de lentes permite representar ángulos mayores en una de las dos dimensiones (alto/ancho), al precio de que las líneas rectas no siempre se representan como líneas rectas en la imagen generada.

El problema está, en efecto, en la sombra bajo las esferas. Pero no se trata de que sobren las sombras... sino de que falta algo dentro de las sombras: el área donde se concentran los rayos por el efecto lenticular de las esferas. Es una paradoja: se puede lograr sombra con una esfera transparente.

La imagen ha sido generada, por supuesto, con XSight RT, y se trata de una prueba del nuevo soporte para refracción. La buena noticia: la simulación de materiales es buena. Me gusta más la apariencia del "vidrio" (la mezcla de reflexión y refracción dependiente del ángulo de incidencia) de XSight RT que la de POV Ray, al menos en el vidrio que éste ofrece por omisión. Además, no se pierde velocidad relativa.

¿Cómo habría que resolver lo de la sombra? POV Ray ofrece varias salidas: la primera, que fue probablemente la primera en soportar históricamente, consiste en tener en cuenta la presencia de materiales transparentes al efectuar las pruebas de oclusión. Es decir, se podría permitir que la luz directa atravesase la esfera. XSight RT no seguirá esa vía... porque también es físicamente incorrecta. El problema es que el algoritmo puro de raytracing no permite generar las superficies cáusticas. El raytracing consiste en generar los rayos a la inversa, partiendo de la cámara, y aquí hace falta trazar rayos directamente desde una fuente de luz.

La segunda solución de POV Ray, y que será la implementada por XSight RT, es utilizar una técnica llamada photon mapping. El reto está en hacerlo eficientemente, y que la técnica sea lo más "transparente" posible para el diseñador gráfico. Quiero decir, que no sea necesario indicar tropecientos parámetros para poder generar este tipo de imágenes.

Recursividad anónima

2008-02-19T09:53:00.022+01:00

... y hablando de raytracing, aquí tiene uno bastante exótico, planteado como una gigantesca consulta LINQ en C^# 3.0:

A Fully LINQified Ray Tracer

Eso es jiu-jitsu y lo demás, tonterías. Como advierte el propio autor, no es una técnica "práctica", pero es un logro impresionante por su complejidad conceptual... y por la elegancia, no del código en sí quizás, pero sí de las ideas teóricas que lo soportan.

El algoritmo de raytracing tiene una característica importante: es recursivo. ¿Podemos, entonces, definir consultas recursivas en LINQ? Como las consultas LINQ están basadas en expresiones lambda, podemos ser más precisos: ¿se pueden definir expresiones lambdas recursivas en C^#?

La respuesta es afirmativa, pero la técnica necesaria es complicada... y resulta difícil de leer y mantener. Mads Torgersen la explica, desde una perspectiva teórica, aquí:

Recursive lambda expressions

Existe, no obstante, una técnica alternativa y algo más sencilla para resolver el problema. Octavio Hernández la explica en la página 85 de su libro "C# 3.0 y LINQ" (que por cierto, puede adquirir a través de nosotros). Esto que sigue es una explicación ampliada de la técnica.

¿Cuál es la dificultad para definir una función lambda recursiva? De entrada, que no podemos llamar directamente a la función por tratarse de una función anónima. Lo que sí podríamos hacer es pasar un puntero a la función como parámetro de la misma, y ejecutar la función a la que hace referencia dicho puntero... o delegado, en la jerga de .NET. El primer paso, por lo tanto, es definir un tipo delegado para funciones que se ajusten a este prototipo. Para simplificar, nos limitaremos a funciones que calculan un valor entero a partir de otro entero:

delegate int Self(Self f, int n);

Construyamos ahora una función lambda que corresponda a este prototipo, y que simule el funcionamiento del factorial:

Self F = (f, n) => n == 0 ? 1 : n * f(f, n - 1);

Esta función F (en mayúsculas) se parece extraordinariamente al factorial. ¿Qué hace falta para que sea "realmente" el factorial? Simplemente, que al llamarla pasemos, en el primero de sus parámetros, la función factorial... es decir, ella misma. Por lo tanto, la función que necesitamos es:

Func<int, int> factorial = n => F(F, n);

Y ya tenemos función anónima recursiva. ¿Le cuesta todavía verlo claro? Bien, ahí va una pista:

Observe que F es realmente una variable local, no una "constante de función".
Cuando usamos F para definir factorial, en realidad estamos "capturando" la variable local F dentro del cuerpo de la función anónima.
Es esta indirección la que permite, en definitiva, que el truco funcione.
Dicho sea de paso, observe que el identificador f, usado al "inicializar" F, es en realidad un parámetro de tipo delegado.
¿Se ha dado cuenta de que he dicho "inicializar F" en vez de "definir F"?

Octavio termina su truco en este punto, y aunque se ha resuelto el problema, nos queda cierta insatisfacción, por haber utilizado el paso intermedio de la inicialización de F. Sin embargo, con muy poco esfuerzo más, se pueden mezclar las dos funciones anónimas y definir el factorial en un único paso. Esta es la expresión lambda que buscábamos:

Func<int, int> factorial = i =>
    new Self((f, j) => j == 0 ? 1 : j * f(f, j - 1))(
        (f, j) => j == 0 ? 1 : j * f(f, j - 1), i);

Es necesario utilizar explícitamente el constructor de Self, el tipo delegado, para que el compilador reconozca la expresión y pueda realizar la inferencia del resto de los tipos de parámetros. Para entender este monstruo, es mejor dividirlo en zonas:

Func<int, int> factorial = i =>
    new Self((f, j) => j == 0 ? 1 : j * f(f, j - 1))
    (
        (f, j) => j == 0 ? 1 : j * f(f, j - 1),
        i
    );

La expresión amarilla se evalúa y produce un delegado. Observe que la usamos sintácticamente del mismo modo en que usaríamos Math.Sqrt o Console.WriteLine. En cierto sentido perverso y retorcido, Sqrt es una "constante de función", mientras que nuestro monstruo es una expresión que se evalúa y produce una función.
¿Se ha dado cuenta de que la expresión verde es estructuralmente idéntica a la amarilla? No obstante, la expresión verde no se evalúa directamente, sino que la pasamos como parámetro para que se ejecute más adelante.
Finalmente, tenemos la simple y vulgar expresión azul. No hay misterio aquí, ¿verdad?

¿Complicado? Es cierto, pero la gracia de todo esto es que existe un truco alternativo, mucho más simple. Observe:

Func<int, int> factorial = null;
factorial = i => i == 0 ? 1 : i * factorial(i - 1);

Primero se declara una variable que apuntará a la función y se inicializa con un nulo. Luego se asigna el delegado definitivo... que hace referencia en su cuerpo a la variable local. Se trata de una captura de variable local, una técnica no sólo permitida por el lenguaje: es, en realidad, lo que hace que todo este rollo de las funciones anónimas tenga sentido. Lo que ahora importa es que, cuando ejecutemos el método asociado a la variable factorial, ésta ya estará debidamente inicializada.

XSight RT v1.1, para .NET v3.5

2008-02-09T17:46:00.000+01:00

Si se aburre, puede entretenerse un poco experimentando con XSight RT v1.1, para .NET Framework 3.5. La descarga contiene el instalador del ejecutable, la ayuda y un puñado de escenas para pruebas. No he incluido el código fuente.

La aplicación permite editar escenas con un lenguaje sencillo y bien documentado, y generar imágenes a partir de estas descripciones. De momento, funciona como una aplicación SDI, permitiendo trabajar con un único documento por instancia de la misma. No está conectado todavía el soporte de refracción y transparencias, ni la perturbación de normales (es una técnica con un nombre perturbador).

SILLY

2008-01-17T15:23:00.000+01:00

No, no estoy llamando "tonto" a nadie: es el nombre que se me ocurrió para el lenguaje de descripción de escenas de XSight RT, y significa, simplemente, Small Instantiation Language... claro, añadiéndole el sufijo de los adverbios ingleses.

El caso es que se trata de un lenguaje orientado a la creación de objetos; de ahí lo de Instantiation. Resulta también que hay un gran números de circunstancias en los que esa "categoría" de minilenguajes resulta útil. ¿Quiere otro ejemplo? Ahí tiene la generación de compiladores. Freya utiliza GOLD: un sistema que recibe una gramática y produce una tabla de análisis sintáctico. Pero es más común el uso de sistemas como Yacc y Bison, que permiten asociar instrucciones en C/C++/C^# a la gramática. Hace poco encontré este otro generador, de Wayne Kelly, de la Queensland University of Technology. Incluye el código fuente completo del generador, en C^#, y es un código limpio y legible.

Tengo, desde hace un tiempo, la idea de ensayar el uso de un lenguaje tipo SILLY con un generador de compiladores para .NET. Como el análisis sintáctico suele utilizarse para crear, en paralelo, un Arbol de Sintaxis Abstracta (AST), el lenguaje se especializaría en la creación de objetos. Algunas ideas sencillas:

Nada de operador new. Cuando un nombre de tipo se usa como función, significa la construcción de una instancia.
El lenguaje soportaría inicializadores de objetos... al estilo Freya, claro. Es decir, se podrían inicializar campos y propiedades del objeto creado usando una sintaxis similar a la de los parámetros con nombre.
Cada "no terminal" de la gramática tendría un tipo de datos asociado.
Cada "regla", o "producción", tendría una expresión asociada, de un tipo derivado del tipo asociado al no terminal.

Veamos un ejemplo sencillo:

<Exp> ::=          : AstExp
  <Exp> '+' <Term> : AstBinary($Exp, '+', $Term)
  <Term>           : $Term

La primera línea advierte que las expresiones van asociadas a nodos de la clase AstExp. En la segunda, cada vez que se detecta una suma, se crea un nodo AstBinary a partir de los nodos de las partes constituyentes. La tercera línea indica que se copie, simplemente, el nodo asociado al término. Este es, naturalmente, el caso más sencillo y frecuente. También es frecuente el uso de listas, por lo que esta variante de SILLY debería soportarlas:

<VarGroup> ::=         : List[AstVar]
  <VarGroup> ',' <Var> : $VarGroup + { $Var }
  <Var>                : { $Var }

Es decir, las llaves se utilizarían para delimitar literales de listas, y el signo + significaría "unión", o concatenación de listas.

Ahora mire un "invento" curioso, asociado a la regla sintáctica correspondiente al operador existencial de Freya:


<Exp> ::=      : AstExp
  '*' IN <Exp> : if $Exp is AstRange
                   then AstBin($Exp.Lo, "<=", $Exp.Hi)
                   else AstExists($Exp)

Para empezar, observe que he mostrado una expresión condicional, no una instrucción condicional. Lo interesante es lo que ocurre en la rama then de la expresión: como esa rama se evalúa cuando $Exp es un AstRange, cambiamos el tipo declarado para $Exp de esa rama para abajo (en el árbol de expresiones); por eso permitimos las referencias a las propiedades Lo y Hi (low y high), definidas para AstRange. Creo que un convenio de este tipo ahorraría mucho trabajo y sería muy útil en lenguajes de propósito general... aunque tengo que pensarlo un poco más, antes de dar el recurso por bueno.

Naturalmente, se permitiría expresiones let/where, y quizás sería necesario algún "aplicador" para actuar sobre elementos de una lista. El "compilador" tendría que encargarse también de algo que podemos clasificar como inyección de código: se supone que, a la vez que se construye el árbol sintáctico, los nodos de éste deben irse asociando a intervalos o rangos de texto dentro del código fuente. A los nodos devueltos en cada reducción, por ejemplo, se les podría asociar automáticamente al rango determinado por el texto reducido. Pero habría casos más complicados:

<Exp> ::=            : AstExp
  <Exp> IS NOT <Ref> : AstNeg(AstCast($1, $3))

El nodo AstNeg es el inmediatamente devuelto por la reducción, por lo que es fácil asignarle un rango. En cambio, el nodo AstCast se esconde dentro del nodo principal. Una solución laboriosa sería indicar explícitamente la asignación del rango:

AstNeg(AstCast($1, $3, Range := @1 + @3))

Este es un ejemplo de los inicializadores de objetos ya mencionados. Observe que @1 se refiere al rango asociado al primer nodo de la regla. Otra solución más elegante sería permitir que el compilador dedujese dicha asignación, a partir de los parámetros detectados en la llamada al constructor AstCast.

¿Qué le parece?

Estadísticas y curiosidades

2008-01-11T12:28:00.000+01:00

Me ha sorprendido que cierto artículo sobre ADO.NET 2.0, escrito casi al principio del ciclo de vida del producto, cuando aún se llamaba Whidbey, se sigue descargando de mi página el doble de las veces que Intuitive C#, el libro gratuito sobre el lenguaje. No hay nada de malo en ello, excepto que no tenía consciencia del hecho... y que me preocupa la actualidad del contenido del famoso artículo, como podrá imaginar (no he incluido el enlace para no "agravar" el fenómeno). Supongo que tendré que retocar un poco el contenido, para evitar confusiones. También empezaré a fechar los artículos: tengo algunas malas experiencias con citas, por parte de terceros, de artículos del año cataplum, con referencia a tecnología de aquellas fechas.

Por cierto, no se hemos pasado todavía la primera quincena del año, ¡y ya aparecen en mis estadísticas varias consultas sobre el principio de indeterminación de Heisenberg!

Por cierto, si aún sigue usando la versión 2005 de Visual Studio... ¡pásese ya a la 2008! Visual Studio 2008 permite configurar la versión de .NET Framework para la que compila los proyectos. De manera que, si no quiere migrar sus aplicaciones a .NET 3.5 por el motivo que sea, no está obligado a hacerlo: puede seguir usando .NET 2.0, pero con Visual Studio 2008, y postergar el cambio de versión de su aplicación per secula seculorum. ¿La ventaja?, pues que, a pesar de seguir usando esa versión de la plataforma, Visual Studio 2008 le permitirá usar buena parte de las extensiones de C^# 3.0.

Desventajas: VS2008 está todavía en inglés. Hay también un punto negro: las operaciones "Buscar todas las referencias" y el cambio de nombre de un identificador tardan más que en VS2005, o esa es la impresión que me he llevado. He leído en algún lugar que, en esta versión, el equipo de VS2008 unificó los bindings: en la jerigonza del entorno de desarrollo, eso de los "bindings" se refiere al uso de partes del compilador y del analizador lexical para asuntos como IntelliSense, la navegación por clases y miembros, etc. Es algo muy normal que, en un entorno de desarrollo como VS2008, se utilicen distintos compiladores y analizadores especializados para estas tareas, con el imaginable coste adicional del mantenimiento de los mismos. Al parecer, han hecho cambios para unificar la base de código... y mi impresión es que algunas operaciones son ahora más lentas. Pero, en general, creo que merece la pena el cambio.

Clases anidadas dentro de interfaces

2008-01-09T15:19:00.000+01:00

C^# no lo permite, pero el CLR no pone objeciones:

.class public interface abstract auto ansi MyInt
{
    .class abstract auto ansi sealed nested public MyExt
        extends [mscorlib]System.Object
    {
    }
}

El listado anterior muestra una clase estática anidada dentro de un tipo de interfaz. Naturalmente, para poder crear este "engendro" he tenido que usar el API de reflexión, porque ninguno de los lenguajes actuales acepta un tipo anidado dentro de una interfaz.

¿Para qué necesito esto? Resulta que es la forma más elegante de definir métodos de extensión para un tipo de interfaz:

IStack = interface[X]
    IsEmpty: Boolean;
    Top: X;
    method Push(Value: X);
    method Pop;

    method Clear;
    begin
        while not IsEmpty do Pop;
    end;
end;

El truco, por supuesto, consistiría en generar una clase estática adicional, con métodos de extensión. El problema es más bien estético: la proliferación de clases con nombres extraños en el espacio de nombres del programador (el mecanismo usado por C^# y compañía para "activar" las extensiones es un desastre).

La solución puede ser anidar la clase con las extensiones en el tipo de interfaz. Primera dificultad: ya hemos visto que está prohibido en los compiladores, pero no en el runtime, de Microsoft. Segunda dificultad: resulta que C^# no permite tampoco métodos de extensión dentro de una clase anidada. Esto va a complicar la compatibilidad de los métodos generados en Freya con este mecanismo: lo más que se puede hacer es ofrecer un switch de compatibilidad. Si está inactivo, porque la aplicación o el ensamblado van a ser consumidos desde Freya, los métodos de extensión asociados directamente a interfaces se generarán en una clase anidada. En caso contrario, se utilizará el horroroso sistema actualmente empleado por Microsoft.

Ocurre que existen motivos adicionales para investigar en esta dirección: Freya permite definir aserciones en un tipo de interfaz (la última vez que eché un vistazo a Chrome, éste no lo permitía). Si un tipo de interfaz representa la definición de un "contrato", ¿qué hay más natural que permitir reglas que precisen los términos de dicho contrato? Por desgracia, precondiciones y postcondiciones generan código, y de momento, Freya estaba generando ese código en clases auxiliares. Con el nuevo mecanismo, podremos encapsular este código en clases anidadas, y despejar un poco el espacio de diseño.

... y aprovecho para aclarar un poco la relación entre aserciones, interfaces y métodos de extensión. Supongamos un caso muy sencillo de interfaz con una precondición:

IStack = interface[X]
    property IsEmpty: Boolean;
    method Pop;
        requires not IsEmpty;
    // ...
end;

Ahora mismo, Freya genera una clase estática con métodos para cada aserción de la interfaz. Como se trata de miembros de una interfaz, necesariamente públicos, no hay problema con los niveles de acceso. Con la nueva idea de implementaciones en interfaces (formalmente, se puede hablar de traits o mixins, aunque no es exactamente lo mismo), lo que haríamos ahora sería equivalente a generar un método "de extensión" en la interfaz:

IStack = interface[X]
    property IsEmpty: Boolean;
    method Pop;
    // ...
    method Pop$Pre;
    begin
        if Self.IsEmpty then
            raise new Exception;
    end;
end;

En realidad, Pop$Pre sería un método estático dentro de una clase estática anidada, que recibiría un puntero de tipo IStack[X].
Observe el truco del nombre: como el dólar no es aceptado dentro de un identificador, el programador no tendría acceso directo al método. Es un truco bastante usado, incluso por el compilador de C^#.
Toda clase que implementase IStack[X], siempre que se programase en Freya, añadiría automáticamente una precondición a su implementación de Pop, que ejecutaría el método Pop$Pre sobre el objeto activo convertido en el tipo de interfaz.

¿La ventaja de anidar la clase auxiliar dentro de la interfaz? Hasta ahora, Freya generaba una clase interna independiente... y tenía que cumplir con un estricto protocolo de asignaciones de nombres para detectar estas clases al leer un ensamblado generado en otro proyecto Freya. Con esta idea, por el contrario, la asociación entre la interfaz y la clase auxiliar es inmediata.

DebuggerDisplayAttribute

2008-01-07T21:20:00.000+01:00

Un truco sencillo que acabo de descubrir. Observe la imagen:

Depurando, si paso el ratón sobre el parámetro map, que pertenece a un tipo TypeMap que he definido, se muestra el número de elementos almacenados por este contenedor. ¿Cómo se logra? Parece sencillo: basta con redefinir el método ToString en la clase TypeMap. Y es verdad que eso funciona... pero hay una alternativa que muchas veces es mejor. Se trata de decorar la clase con el atributo DebuggerDisplay:

[DebuggerDisplay("Items = {items.Count}")]
internal sealed class TypeMap

Observe que el parámetro pasado al atributo es una especie de cadena de formato que permite incluir expresiones entre llaves. En este caso, mostramos el valor de la propiedad Count de un campo de TypeMap llamado items.

¿Porque me alegra tanto tener una alternativa a la redefinición de ToString? Porque así puedo separar con más claridad la lógica de la aplicación del código auxiliar que sólo necesito durante la depuración del proyecto. En el compilador de Freya, por ejemplo, los símbolos de métodos redefinen ToString para facilitar la búsqueda en la tabla de símbolos, pero otras clases lo hacían sólo por conveniencia, para mostrar información durante la depuración. Con el listado delante, me costaba normalmente decidir si determinada reescritura de ToString era necesaria o prescindible.

UpdateBatchSize

2008-01-05T18:34:00.000+01:00

Todo programador que haya trabajado con SQL Server sabe lo importante que es empaquetar cuantas instrucciones sea posible dentro de una misma petición al servidor. El mismo programador, cuando comienza a trabajar con ADO.NET tropieza con la paradoja de que cada actualización de registros modificados en un dataset, debe viajar al servidor SQL completamente sola. Al menos, en la versión 1.1 era esto lo que ocurría...

Tinieblas

El problema, aclaro, no es grave. Típicamente, cuando se producen actualizaciones a través de modificaciones en un DataSet, estas modificaciones afectan a muy pocos registros, y el peaje a pagar es poco. Por el contrario, si usted se despierta un día actualizando centenares de registros a través de un data adapter, corra a visitar a su psicólogo de cabecera. Para actualizaciones masivas, es mejor usar directamente SQL, y si es posible, mediante procedimientos almacenados. Ese mítico escenario del feliz programador OOP que transparentemente modifica instancias de clases generadas por un ORM es una gran mentira: en una aplicación real, la mayoría de las modificaciones que no se realizan en el servidor mediante procedimientos almacenados, se generan a petición de controles enlazados a datos... a no ser que usted sienta fobia hacia el enlace de datos y los procedimientos almacenados.

De todos modos, las clases SqlDataAdapter y OracleDataAdapter de .NET 2.0 introdujeron una propiedad UpdateBatchSize, que permite agrupar varias actualizaciones en una misma petición. Si la propiedad vale 1, que es su valor por omisión, el comportamiento de los adaptadores es el de la versión anterior: una petición separada para cada registro actualizado. Un 0 en la propiedad provoca que todas las actualizaciones se sumen y se envíen en un único viaje de ida y vuelta. Y, finalmente, cualquier valor mayor que 1 sirve para crear grupos de peticiones del tamaño indicado.

Confieso, sin embargo, que hasta hace muy poco, nunca había usado esta propiedad. El motivo tiene que ver con la mecánica de las actualizaciones en ADO.NET. Suponga que tratamos con un una tabla cuya clave primaria es una columna autoincremental, y que tiene un campo de tipo rowversion/timestamp para el control optimista de concurrencia. Las inserciones en esta tabla se ejecutan mediante el siguiente grupo de instrucciones SQL:

insert into Clientes(...) values (...);
select IDCliente, TS from Clientes
where  IDCliente = SCOPE_IDENTITY()

En otras palabras: cuando se inserta un registro, inmediatamente después se pide la última identidad creada al servidor, y el valor de la versión de fila para la nueva fila. Estos dos valores se devuelven al adaptador como un recordset de una fila, y el adaptador utiliza estos valores para poner al día las correspondientes columnas en el dataset.

¿Qué ocurriría si agrupásemos varias de estas instrucciones en un mismo batch o grupo de consultas? Evidentemente, el mecanismo saltaría por los aires. El servidor respondería enviando una colección de recordsets, pero el adaptador sería incapaz de distinguir cuál correspondería a cada fila. Es natural que el programador se abstenga de usar UpdateBatchSize, pues aparentemente obligaría a utilizar otro sistema para la puesta al día de la copia local de los datos tras una actualización.

Fiat lux

Pero, ¡pobre de mí!, no sospechaba cuán listos habían sido los que añadieron esta característica a los adaptadores. Hace poco, haciendo pruebas, me di cuenta de que un adaptador con UpdateBatchSize parecía seguir enviando consultas individuales al servidor SQL. Al menos, en el SQL Profiler se mostraban las inserciones como instrucciones individuales. Intrigado, busqué más información en Internet, y así supe que la labor de UpdateBatchSize no consiste en generar una única petición formada por una gigantesca instrucción. La técnica es más sofisticada, y según lo que sé, consiste en agrupar todas las peticiones en un único paquete RPC (Remote Procedure Call). Esto ahorra un ancho de banda considerable, y lo que es más importante, disminuye los problemas de latencia provocados por la red. No se optimiza la operación, considerada por separado, al máximo, pero se logra un mejor resultado, de todos modos... y abre el camino a la esperanza.

Volví entonces a la documentación de SqlDataAdapter y descubrí un pequeño detalle: cuando BatchUpdateSize es distinto de 1, los comandos del adaptador no pueden tener los valores Both o FirstReturnedRecord en su propiedad UpdateSource. Es decir: no se puede usar un recordset para poner al día la copia local. Pero esto también significa que se admite la opción OutputParameters. Si la actualización se realiza a través de procedimientos almacenados, ¡es posible usar UpdateBatchSize y seguir actualizando la copia local en una misma operación!

En estos casos, hay que tener un procedimiento almacenado en el servidor parecido a éste:

create procedure InsertCliente
    @IdCliente int output,
    @TS timestamp output,
    @Nombre T_NOMBRE,
    @Apellidos T_APELLIDOS as
    insert into Clientes(Nombre, Apellidos)
    values (@Nombre, @Apellidos);
    select @IdCliente = IDCliente, @TS = TS
    from   Clientes
    where  IDCliente = SCOPE_IDENTITY()

Observe que esta vez no se utiliza un recordset, sino los parámetros de salida del procedimiento, para devolver los valores actualizados de las columnas modificadas en el servidor.

Evidentemente, el uso de procedimientos almacenados para estas operaciones requiere un poco más de planificación por parte del programador... pero es una tarea mecanizable, y seguramente podremos contar con la ayuda del DBA. Tenga en cuenta que el DBA no protestará si le pide que no permita actualizaciones en una tabla excepto a través de un procedimiento almacenado: estas cosas hacen feliz a un administrador de bases de datos.

Es poco probable que una aplicación en dos capas, para la que se presume poca carga, se beneficie de un mecanismo tan sofisticado de actualización. Pero en una aplicación multicapas con mucha carga, cada milisegundo (¡sí, hablo de milisegundos!) que se gane en una operación, significa más capacidad de concurrencia para la capa intermedia: el modelo de concurrencia de una capa intermedia con pooling no ofrece capacidad lineal respecto a los tiempos de respuesta. El truco de combinar UpdateBatchSize con procedimientos almacenados puede parecer excesivamente complicado a algunos, pero es bueno saber que disponemos de un arma como ésta en nuestro arsenal.

Actualización: He subido una pequeña actualización de Intuitive C#, con una nueva sección sobre métodos de extensión. Lo único interesante es que he añadido la sección al capítulo de interfaces.

El objeto activo

2008-01-03T23:34:00.000+01:00

¿Qué se supone que tiene que pasar cuando se ejecute este código?

using System;
public
    Program = class
    public
        method Test: Boolean => Self <> nil;

        static method Main;
        begin
            var Instance: Program := nil;
            Console.WriteLine(Instance.Test);
        end;
    end
end

La respuesta breve es que se imprimirá False.

La respuesta larga tiene que ver con uno de los objetivos de Freya: experimentar con la eficiencia del lenguaje, y en este caso, entra en escena el código IL que se genera para la llamada a un procedimiento. Hay dos de estos códigos: call y callvirt. El segundo de ellos se utiliza, evidentemente, para ejecutar métodos virtuales, pero curiosamente, también puede ocuparse de métodos no virtuales, como es el caso de nuestro método Test. En tal caso, la diferencia respecto a call es que, al generarse el código nativo final, callvirt añade una verificación del puntero de instancia. Si este es nulo, excepción al canto.

Resulta que callvirt es utilizado deliberadamente por C^# para casi todas las llamadas a métodos de instancia, sean virtuales o no. Esta es la forma de satisfacer la especificación del lenguaje, que exige que rueden cabezas si se pasa un nulo como objeto activo a un método de instancias. Es también interesante que, en contadas ocasiones, C^# puede optimizar la llamada si sabe a ciencia cierta que el puntero no será nulo. ¿Cuándo puede tener esta certeza? Por ejemplo, cuando el objeto pasado se acaba de construir. Un método ejecutado sobre una expresión new no necesita esta verificación.

Freya, por el contrario, siempre usa call para métodos no virtuales, con lo que logra una ganancia en velocidad mínima, pero notable, sobre C^#. Hay una ganancia también en el tamaño del código nativo, que se traduce en un uso más eficiente de la memoria, y a la larga, en más velocidad: la comprobación de no nulidad la ejecuta quien llama, por lo que se repite innumerables veces a lo largo del código. El coste: la especificación de Freya no exige que la instancia activa sea no nula. De ahí que tengan sentido ejemplos como el mostrado.

La pregunta es, naturalmente, si es peligrosa esta "relajación". No lo es, por supuesto:

Si se pasa una referencia nula como objeto activo a un método que no lo permite, la excepción se va a producir, de todos modos, en cuanto el objeto activo intente tocar algún campo o método de instancia. Es decir: el error se detectará, aunque algo más tarde.
En realidad, la no nulidad del objeto activo puede verse como una precondición en el contrato del método, en los lenguajes que la exigen: se supone que el software correctamente escrito nunca violará la precondición. Pero en ese caso, si en el software final se mantiene la verificación, ¡estaremos comprobando una y otra vez si se produce lo imposible!

A mediano plazo, Freya deberá incorporar aserciones especiales sobre la nulidad de campos y parámetros. Esto traerá algunas novedades interesantes al lenguaje. Piense un momento: si digo que el campo C, de tipo Object, no puede ser nulo, ¿cómo vamos a tratar el hecho de que el CLR lo inicialice precisamente como nulo? La clave está en añadir inicializadores de campos a los constructores, al estilo C++:

// En una clase Stack[X]...
constructor(Capacity: Integer) :
    Items(new Array[X](Capacity)),
    Inherited
begin
end;

El CLR permite que estas inicializaciones de campos se ejecuten incluso antes de la llamada al constructor de la clase base: es así, de hecho, como se ejecutan los actuales inicializadores de campos de C^# y Freya. La diferencia es que, con el nuevo recurso, los inicializadores de campos podrán utilizar los parámetros del constructor, algo que ahora mismo es imposible.

Por cierto, el último listado puede abreviarse a lo siguiente:

constructor(Capacity: Integer) :
    Items(new Array[X](Capacity));

La llamada al constructor por omisión heredado se asume, y el bloque de instrucciones, al estar vacío, se puede omitir. Un constructor paralelo, sin parámetros, se programa en Freya de este modo:

constructor : Self(128);

Las instancias especiales base y this de C^# se sustituyen en Freya por los identificadores especiales Inherited y Self.

... quien haya depurado una aplicación .NET en código nativo, se habrá encontrado con instrucciones aparentemente absurdas como ésta, justo antes de una llamada a rutina:

cmp byte ptr [rax],0

Se trata de la verificación de no nulidad, en este caso, en código de 64 bits. En un procesador de 32 bits, he visto esta variante:

cmp byte ptr [eax],eax

Al parecer, la diferencia debe estar en el tamaño de ambas instrucciones. Pero en ambos casos, el principio es el mismo: si EAX o RAX tienen un puntero no nulo, la instrucción hará una comparación rápida e inofensiva. En caso contrario, la memoria a la que apunta el registro estará en la zona prohibida, y el propio procesador levantará la liebre... quiero decir, la excepción.

Por último, la posibilidad de simular el traspaso de un objeto activo nulo la dan los métodos de extensión:

public static class StringExtender
{
    public static bool IsEmpty(this string s)
    {
        return string.IsNullOrEmpty(s);
    }
}

Si se puede lograr por medio de métodos de extensión, ¿qué hay de malo en permitirlo para los métodos de instancia?

Ornitorrinco

2007-12-31T16:49:00.000+01:00

No todo lo que camina como un pato, nada como un pato y pone huevos como un pato, tiene necesariamente que ser un pato. Podría tratarse de un ornitorrinco, ¿verdad?

Suponga que yo le digo que esto es Freya:

IStack = interface[X]
    Count: Integer;
    Top: X;
    method Push(Value: X);
    method Pop;
        requires Count > 0;

    IsEmpty: Boolean => Count = 0;
end;

Para que le resulte más fácil detectar el elemento extraño, utilizaré una sintaxis equivalente, algo más verbosa:

IStack = interface[X]
    property Count: Integer;
    property Top: X;
    method Push(Value: X);
    method Pop;
        requires Count > 0;

    property IsEmpty: Boolean;
    begin
        Result := Count = 0;
    end;
end;

Y ahora, antes de subir la otra mitad del artículo, dígame si lo anterior le parece bien o mal...

Efectivamente, como mencionaba Marto en un comentario, se supone que las interfaces no "implementan". Sin embargo, es precisamente ese efecto lo que logran los métodos de extensión de C^# 3.0:

interface IStack<X>
{
    int Count { get; }
    X Top { get; }
    void Push(X value);
    void Pop();
}

static class StackExt
{
    public static bool IsEmpty<X>(this IStack<X> s)
    {
        return s.Count == 0;
    }
}

Gracias a estos métodos, es posible escribir código como el siguiente, suponiendo que tenemos ya una clase que implementa el tipo de interfaz:

IStack<int> st = new StackImpl<int>();
if (st.IsEmpty()) { ... }

¿Es bueno, o es malo? No veo nada malo en permitir manipulaciones predefinidas sobre el estado "público" ofrecido por el contrato de la interfaz: lo mismo se puede lograr, incluso sin métodos de extensión, aunque al precio de escribir muchísimo más.

Ahora bien, mi duda va más allá. ¿Merece la pena implementar métodos de extensión (Freya ya los tiene), o sería suficiente con añadir al lenguaje implementaciones predefinidas en interfaces, como la del ejemplo de Freya? El caso es que los métodos de extensión son nada elegantes:

El mecanismo de selección es horrible: basta con introducir una cláusula using para activarlos, dándole un protagonismo inapropiado a estas cláusulas.
Estos métodos, cuando se emplean para extender una clase, plantean un grave problema de estabilidad respecto al versionado: si el implementador de la clase introduce un método de instancia en la clase extendida, dejará de funcionar la extensión, porque el método de instancia tiene la prioridad. Lo peor es que sería muy difícil detectar estos problemas.

De momento, a falta de más análisis, me inclino por sustituir este recurso por implementaciones en interfaces. Es verdad que no son recursos equivalentes, pero la suciedad de los métodos de extensión me aterra.

Vade retro, LINQ pro SQL

2007-12-30T17:35:00.000+01:00

Hágame caso, y evitará malgastar sus fuerzas: si quiere desarrollar una aplicación seria, apártese de LINQ para SQL. Al menos, de momento...

Llevo varios días descubriendo cosas que no me gustan, pero me he contenido por prudencia. El descubrimiento que ha puesto el último clavo sobre el ataúd del invento tiene que ver con la forma en que se manejan las relaciones maestro/detalles. Pongamos por caso que tenemos dos tablas relacionadas, como Clientes y Pedidos:

LINQ para SQL crea dos clases, con un formato predecible:

public partial class Customer
{
    public EntitySet<Order> Orders { ... }
}

public partial class Order
{
    public Customer Customer { ... }
}

¿En qué momento se leen los pedidos de un cliente? Por omisión, no cuando se crea el cliente; ni siquiera cuando se accede a la propiedad Orders. Hay que intentar hacer algo con el contenido de la colección para que se dispare la consulta SQL correspondiente, que se parecerá a la siguiente:

select * from orders
where CustomerID = @CustomerID

Hasta aquí, todo es esperable, predecible y aceptable... suponiendo que estamos creando una aplicación con la vetusta arquitectura cliente/servidor. Si vamos a tener cuatro gatos conectados a un servidor local de SQL Server (pues LINQ para SQL sólo soporta, de momento, SQL Server), las cosas nos irán bien. Pero para eso no hacía falta gastar dinero en una subscripción anual a la MSDN. Cómprese un Delphi 7 de segunda o tercera mano, o incluso un Visual Basic "clásico", y sea feliz.

Pero, ¿qué pasa con la programación seria? Cuando usted se trae los datos de un grupo de clientes a la capa de presentación, tiene dos opciones, teóricamente: la carga incremental, o por demanda, de sus pedidos, o traer todos los pedidos en la misma operación que trae el grupo de clientes. En mi libro particular de estilo, la carga "por demanda" no sería aceptable. Cuando alguien pide clientes y sus pedidos, es porque realmente necesita ambas entidades, y en programación multicapas, el pecado mortal de necesidad se llama round-trip; es decir, viaje de ida y vuelta al servidor de capa intermedia. Pero mantengamos las opciones abiertas, y supongamos que cada técnica tiene su uso. Pues bien:

LINQ para SQL no permite implementar la carga por demanda cuando hay una capa intermedia. Para transmitir un registro de cliente, hay que "serializarlo", y eso implica serializar sus pedidos. Adiós lectura incremental de los pedidos.
Y ahora viene lo peor: supongamos que ya estamos resignados a no usar la carga por demanda. El caso es que LINQ para SQL implementa la lectura, en esos casos, de manera asquerosamente ineficiente.

Aquí aparecerá el listo de siempre, que alegará la existencia de unas DataLoadOptions que permitirían desactivar la carga por demanda. En efecto, LINQ para SQL ofrece algo así:

DataLoadOptions dlo = new DataLoadOptions();
dlo.LoadWith<Customer>(c => c.Orders);
dataContext.LoadOptions = dlo;

Pero, si se molestase en comprobar qué es lo que realmente hace dicha opción, comprobaría que, si se leen cuatrocientos clientes, esta opción provocaría que el servidor de capa intermedia lanzase otras cuatrocientos consultas SQL para leer individualmente los pedidos de cada cliente. Sí, es verdad que esta avalancha se produciría de golpe, en vez de incrementalmente...

Las cosas son buenas o malas en comparación con otras. ¿Cómo se resuelve este problema en ADO.NET con los conjuntos de datos de toda la vida? Muy simple: usted sólo necesita lanzar dos consultas, y es ADO.NET quien se encarga de tejer la relación en memoria, una vez que dispone de todos los registros. ¿Quiere, por ejemplo, los clientes de Madrid y sus pedidos? En un mismo comando (¡para ahorrar aún más!) se incluirían dos consultas:

select * from Customers
where City = "Madrid";
select * from Orders
where CustomerID in (
    select CustomerID from Customers
    where City = "Madrid")

A SQL Server se le da muy bien responder a este tipo de consultas, a pesar de su aparente complejidad. Y no le digo nada sobre recuperar los clientes que hicieron pedidos la semana anterior: la ganancia comparativa sería escandalosa.

¿Conclusión? Pues que LINQ para SQL no está preparado para la vida real. Es un juguetito con ínfulas, que a la hora de la verdad se queda muy corto... y es lamentable que la comunidad de programadores no esté diciéndolo en voz alta. No se trata sólo del problema aquí explicado: hay que sumar los problemas que ya la propia Microsoft explica para el funcionamiento del sistema en tres capas. Por ejemplo: los valores originales de cada registro se almacenan en el contexto, y al serializar un registro se pierden, no existe una funcionalidad comparable al Merge de los conjuntos de datos...

Es cierto que Microsoft se reserva eso del ADO.NET Entity Framework para febrero o marzo (es significativo que hayan publicado Visual Studio 2008 sin esperar por él). Habrá que esperar al producto final antes pronunciarse. Pero cada vez creo menos en la bondad de los ORMs: tengo razones para esperar muy poco de este tipo de sistemas. De todos modos, seré prudente: ya veremos qué tal se comporta el nuevo invento. A lo mejor esta es la vez en que un ORM acierta por primera vez en la Historia...

... y que ahora alguien me diga cuál es la urgencia para aprender a usar LINQ. ¿Para aplicarlo al famoso LINQ para SQL?

Mucho cuidado: no estoy diciendo que no merezca pasarse a VS2008. Todo lo contrario, ¡pásese urgentemente a la nueva versión! Hay suficientes mejoras como para merecer la pena, y la principal de ellas, en mi humilde opinión, es la nueva técnica de generación de clases para conjuntos de datos, que facilita enormemente la creación de aplicaciones en tres capas.

Novedades en Visual Studio 2008

2007-12-27T16:56:00.000+01:00

Era un poco extenso para colgarlo de la bitácora:

Novedades en el acceso a datos con VS2008

Se trata, más bien, de los cambios que simplifican las aplicaciones del curso de ADO.NET. Son pocos, pero interesantes.

Por cierto, ¡qué "divertido" es programar con Java! Acabo de darme cuenta de que Java no tiene mecanismos para la solución de conflictos de nombre al implementar interfaces. En C^# se utilizan las implementaciones explícitas para este fin. Y en Delphi existía un mecanismo parecido.

En particular, me gusta usar implementaciones explícita cuando quiero evitar que alguien (casi siempre, yo mismo), accidentalmente, acceda a un método o una propiedad a través de la clase, en vez de usar el tipo de interfaz. La experiencia me dice que introduce menos dependencias el uso de interfaces que el uso de referencias de clase.

Naturalmente, he añadido el "detalle" a uno de los artículos en mi página que comparan Java con C^#.

Disponible: Volumen II, para Visual Studio 2005

2007-12-23T23:15:00.000+01:00

Pensé que iba a tardar más tiempo, pero la migración ha sido sencilla. Ya está disponible el Volumen II (antes, serie D) de nuestro curso a distancia sobre ADO.NET, para Visual Studio 2005:

Temario combinado: Volúmenes I y II

Como siempre, las actualizaciones son gratuitas, a través de descargas personalizadas. Si ha usted adquirido el Volumen I en estos días, también le enviaremos el CD "físico" con la actualización, gratis.

Con esta actualización, el curso completo está disponible para Visual Studio 2005. Seguimos incluyendo en el CD, no obstante, las versiones de las series A y D para VS2003. Son 444 páginas (566, en realidad, si se cuentan las de Intuitive C#, incluido en el CD), en formato A4, de texto y código sobre desarrollo para .NET. ¿Quién da más?

¿Y Visual Studio 2008?

Como ya anuncié, está en preparación una serie sobre LINQ for SQL. Luego se migrarán las series ya disponibles hacia la nueva versión.

Debo advertirle, sin embargo, que los dos volúmenes ya disponibles son completamente compatibles con Visual Studio 2008. De hecho, han sido muy pocos los cambios en la migración de VS2003 a VS2005: la rejilla, el sistema de menúes, y sustituir ciertos usos de DataView y BindingContext por el componente BindingSource, y las diferencias entre VS2005 y VS2008, fuera de LINQ, son muy pocas.

De todos modos, cualquier compra del curso ahora se considera, a efectos de las actualizaciones, como si se hubiese comprado ya el curso para VS2008, de manera que le queda la actualización gratuita a la versión que venga tras .NET 3.5.

Combinaciones

Aunque no he tenido tiempo aún para escribir las reseñas, estamos también comercializando tres nuevos libros sobre .NET:

Además de estar disponibles por separado en nuestro catálogo de productos, es posible también adquirirlos en combinación con cursos y libros nuestros... y beneficiarse de un suculento descuento (en nuestros cursos: la ley española prohibe descuentos a libros por encima del 5%).

Voy a tardar todavía un poco en tener disponibles las reseñas y todos los formularios de combinaciones, pero si está interesado en la posibilidad, contacte conmigo, a través de mi cuenta de correo en IntSight. También enviamos estos libros al extranjero. El coste de envío es similar al de La Cara Oculta de C#, pues cada libro pesa menos de un kilogramo.

¡Combine y ahorre!

Docking en Volumen II

2007-12-22T20:12:00.001+01:00

Incluido como "extra", al final del Volumen II, este ejercicio adapta el layout manager usado a lo largo de la serie para que, en vez de utilizar ventanas MDI, utilice los componentes de docking de Weifen Luo (que dicho sea de paso, también se usan en Blade, el IDE de Freya).

Conciliación en presencia de identidades

2007-12-18T17:33:00.000+01:00

Copio a continuación un pequeño fragmento de un ejercicio del Volumen II, para que os hagáis una idea del tipo de problemas prácticos al que se enfrenta una aplicación preparada para las tres capas, y que tienen que tratarse obligatoriamente como parte de un curso serio sobre bases de datos.

La implementación que hemos proporcionado a SaveChanges es mínima, y no es difícil encontrar casos para los que tendremos que complicarla. El primer ejemplo: la inserción de registros en tablas que contienen columnas con el atributo identity. De hecho, todas nuestras tablas tienen como clave primaria una columna con dicho atributo. Para entender en qué consiste el problema, sigamos el rastro de una inserción de registros. Supongamos que el usuario ha tecleado el siguiente registro para la tabla de países:

<  -1, 'PN', 'Polo Norte'... >

He puesto –1 como clave primaria del nuevo registro, para evitar confusiones. Supondremos que este valor ha sido asignado automáticamente en el lado cliente. No obstante, al grabar el registro, el algoritmo de grabación recupera el valor asignado a la clave por el servidor. Este sería el estado del registro una vez insertado y actualizado:

<1234, 'PN', 'Polo Norte'... >

Recuerde, sin embargo, que la grabación se ejecuta sobre un conjunto de datos auxiliar que sólo contiene las filas con algún tipo de cambio. Para que el conjunto de datos original se actualice, tenemos que ejecutar la operación Merge. Este método utiliza las claves primarias para identificar los registros originales con sus copias más recientes. Y esto es un problema, precisamente porque la clave primaria ha sido modificada durante la inserción. Después de ejecutar Merge tendríamos dos copias del mismo registro, con valores diferentes en la clave primaria:

<  -1, 'PN', 'Polo Norte'... >
<1234, 'PN', 'Polo Norte'... >

¿Se da cuenta de que nos sobra el primero de los registros? Para evitar esta duplicación de las inserciones, tendríamos que eliminar los registros añadidos al conjunto de datos original antes de mezclar el contenido de delta. Esta es una versión más completa de SaveChanges:

public virtual bool SaveChanges()
{
  DataSet delta = Data.Instance.Write(
    dataset.DataSetName, dataset.GetChanges());
  foreach (DataTable tab in dataset.Tables)
  {
    foreach (DataRow row in tab.Select(
      null, null, DataViewRowState.Added))
    {
      row.Delete();
    }
  }
  dataset.Merge(delta, false);
  dataset.AcceptChanges();
  return true;
}

No importa si alguna tabla no utiliza el atributo de identidad. Si borramos una fila añadida dentro del conjunto de datos original, de todos modos volveremos a incorporarla al mezclar el delta. Observe que, para cada tabla, detectamos los registros añadidos gracias a su estado, aplicando el método Select a la tabla.

Naturalmente, el código que hay que incluir para resolver estos problemas eminentemente prácticos no siempre es sencillo o evidente. De ahí la dificultad de escribir un curso de ADO.NET verdaderamente útil, y mi decisión de mantener la línea argumental del actual curso en su actualización.

Actualización: Para Navidad, actualización de la serie D a VS2005...

La maldita serie D

2007-12-16T17:57:00.000+01:00

Me he puesto a migrar, en paralelo con la escritura de la serie sobre LINQ for SQL, la vieja serie D. Es relativamente fácil adaptar los ejercicios, incluso a Visual Studio 2008. En tres días he adelantado tanto como el ejercicio 10 (de 24 ejercicios en total). Y entonces me he dado cuenta del problema.

La línea de razonamiento y el desarrollo del curso son estupendos, pero parten de una premisa: el estudiante está interesado en aplicaciones multicapas, y está, además, convencido de la necesidad de las mismas. Por eso, supuse yo al escribir el original, aceptaría el uso de la compleja infraestructura que se desarrolla en el curso. En la práctica, supongo que lo más frecuente es que, quien lee los ejercicios, se pregunte si todo eso tiene que ser tan complicado, por necesidad, o si se trata de fuegos de artificio del autor, que intenta demostrar lo mucho que sabe.

Para que se comprenda lo que digo, aquí va un ejemplo concreto:

Normalmente, una grabación de los cambios en un conjunto de datos se resuelve en ADO.NET con una simple llamada al método Update de un adaptador, una sucesión de llamadas de este tipo, o el código equivalente, si se usan los adaptadores de tablas.
En cambio, en mi curso se añade código para eliminar filas insertadas en el conjunto de datos. Y si no se ha seguido la línea del curso, uno de repente se pregunta: ¿y por qué? Bueno, porque en mi curso la actualización no tiene lugar directamente sobre el conjunto de datos conectado a la rejilla, sino sobre una copia del mismo enviada a un servidor de capa intermedia. La famosa y sencilla llamada a Update transcurre allí, y lo que el estudiante tiene que aprender es a sincronizar el conjunto de datos modificado con los registros originales. Es una tarea típica de la programación multicapas.

Ahora me encuentro en una encrucijada. O termino la traducción de lo que hay, o corto por lo sano y saco una serie "práctica" inicial, que no considere la posibilidad de convertir la aplicación en un sistema multicapas. Parecerá absurdo, pero me atrae más esta segunda opción. La nueva división del curso en Volumen I y Volumen II obedece, en definitiva, a un propósito original: mantener dos línea paralelas, una más "teórica" y otra completamente práctica. El Volumen II final podría contener, en su fase final, dos series: la primera, para resolver aplicaciones en dos capas, y la tercera, que se ocupase de los temas específicos de la programación remota, que no tienen que ver tanto con la técnica de remoting en sí, sino con la sincronización.

Decisión final

Ya existe un Volumen I que muestra perfectamente cómo desarrollar en dos capas, usando las técnicas más que probadas que ofrece directamente Microsoft. Por lo tanto, la serie D se actualiza tal cual, mostrando técnicas propias de la programación multicapas. ¿Que es más complicado? Bueno... eso es valor añadido. Era una decisión sencilla, ¿verdad?

Next big thing

2007-12-13T16:20:00.000+01:00

Próxima gran actualización del curso de ADO.NET: una serie dedicada a LINQ for SQL. Voy a experimentar esta vez con un formato que creo que será mejor para esta materia: el curso estará basado en el vídeo (narrado y subtitulado).

El problema que veo con LINQ para SQL es que no es tan completo como la programación con datasets para mover y actualizar datos entre capas. Por una parte, me he tropezado con la sorpresa de que los árboles de expresiones no vienen con soporte para la transmisión remota. Uno puede añadirlo por su cuenta, pero es bastante trabajo. Por lo tanto, cuando se piden datos a la capa intermedia, o regresas a la época en que pasabas una cadena, o te montas todo un tinglado para evaluar consultas remotas por tu cuenta y riesgo.

El otro problema es más sutil: hasta que no te pones a hacer un ejemplo real no tropiezas con él. El caso es que las colecciones de LINQ for SQL (los tipos genéricos Table<T> y EntitySet<T>) no ofrecen algo parecido al Merge de tablas y conjuntos de datos. Sí ofrecen la posibilidad de reasignar entidades al data context local, y de serializar las colecciones de entidades, pero eso sólo simplifica las aplicaciones que no modifican datos en la capa de presentación: vale sólo para aplicaciones básicamente de sólo lectura. Nuevamente, uno puede programar lo que falta... pero ya son dos subsistemas bastante complejos que hay que añadir por cuenta y riesgo propio.

Pero hay que contarlo todo, para verlo con perspectiva: a la actual versión de Visual Studio 2008 se le debe sumar, en relativamente poco tiempo, lo que en Microsoft llaman ADO.NET Entity Framework, que es la verdadera continuación del viejo proyecto ObjectSpaces, que sufrió un cambio radical con la aparición de LINQ. Al parecer, este sistema será mucho más completo y ambicioso que el actual.

A la espera del próximo gran invento, creo que lo mejor es ir explicando el trabajo con LINQ para SQL, que se parece bastante, sobre todo para evitar malas decisiones inducidas por las prisas. La actualización de las tres primeras series del curso deben ser también sencillas, porque son pocas las adiciones (la más notable, quizás, los nuevos coordinadores de grabación para relaciones que ahora se generan para los table adapters).

... de ahí la importancia del cambio de nombre de las series. La nueva serie sobre LINQ/SQL será la serie D, y la actual serie D se quedará en "volumen 2", como ya se refleja en los nuevos CDs del curso.

La espera

2007-12-07T15:19:00.000+01:00

The waiting is the hardest part
Every day you see one more card
You take it on faith, you take it to the heart
The waiting is the hardest part

Ya está terminado el "Volumen I" del curso de ADO.NET, que incluye las series A, B y C completamente actualizadas. La serie B finalmente se ha quedado en unos pocos pero intensos ejercicios. Queda ahora "empaquetar" todo el contenido: vídeos, ejercicios y el manual del nuevo "volumen".

Y hay una estupenda noticia: a partir de la semana que viene, la oferta de libros "físicos" de nuestra tienda en Internet se amplia dramáticamente, con una nueva hornada de libros sobre ASP.NET, LINQ/C# 3.0 y WWF. Será una sorpresa agradable, se lo prometo :)

Temario combinado (PDF)

Adelanto, sobre formas de actualizar o adquirir el curso de ADO.NET:

Si adquirió el curso en agosto del 2007 o después: escríbame un email a la cuenta de IntSight, y recibirá el nuevo CD por correo certificado (paquete azul) sin coste alguno.
Si adquirió el curso antes de esa fecha: tampoco le costará nada. Pero la forma de actualización es mediante una descarga personalizada (ocupa unos 11MB). Escríbame para darle su dirección de descarga.
Alternativamente, si prefiere tener un CD "físico" con la actualización: voy a dar la posibilidad de recibir el CD por un coste de 10 euros (dentro de España), y pago por tarjeta, transferencia o ingreso en cuenta (no reembolso).
Posibilidad interesante: vamos a vender, en nuestra tienda, nuevos libros sobre LINQ, ASP.NET y WWF. Si le interesa alguno de estos temas, compre cualquiera de estos libros, pague un euro más por el CD, y se ahorra los gastos de envío del CD (porque ya se incluyen en el coste del libro). Puedo tardar dos o tres días en crear los formularios de compra: si le urge, o quiere más información mientras tanto, deme un toque por email.

Métodos parciales y más

2007-10-25T18:33:00.000+02:00

Está disponible una actualización de Intuitive C# (28/octubre/2007). Esta versión añade secciones sobre llamadas asíncronas a través de tipos delegados y el nuevo soporte para métodos parciales y propiedades automáticas en .NET 3.5/Visual Studio 2008. Hay también una pequeña sección sobre árboles de expresiones (¡son muy importantes para comprender cómo funcionan LINQ for SQL y el futuro LINQ for Entities!), como paso previo a LINQ. El libro ha pasado de 112 a 122 páginas.

Quien avisa...

2007-10-06T23:30:00.000+02:00

Actualización 9/oct: ¡Ya está terminada la actualización de la serie A! Ha costado por el nivel de profundidad del curso: tenga en cuenta que, a pesar de tratarse de una "serie A", se metía en temas como cifrado, compresión y las interfaces de muy bajo nivel del enlace de datos.

De todas maneras, antes de dar el pistoletazo oficial de salida, me queda fundir la serie C con la serie A (ya está adelantado más de la mitad del trabajo) y añadir algún ejercicio como puente entre ambas series, sobre todo sobre DataReader's y comandos.

Lo bueno de la nueva serie A es que gran parte del material puede reciclarse para ser utilizado en la parte de enlace de datos de la próxima Cara Oculta de C# 3.0. En paralelo, estoy colaborando en un interesante proyecto de desarrollo en el que vamos a usar .NET Remoting. Como ve, las cosas se mueven en este mundo...

Noticias sobre el curso de ADO.NET/C#:

Estoy terminando la migración de la serie A a .NET v2.0.
También estoy fundiendo la serie A con la C y con un par de ejercicios de lo que sería una miniserie B.
De momento, la serie D se queda tal cuál, pero las tres series del volumen I son funcionalmente completas.
El precio del curso sube.
Pero quien compre ahora, o haya comprado en el mes de septiembre, no sólo compra al precio actual... sino que recibe gratuitamente el CD con el curso actualizado.

Quien avisa no es traidor...

Y esta es la imagen de portada del nuevo manual:

La elección no es gratuita: se trata de un objeto de tipo blob, generado con XSight RT. Los blobs del ray tracing se definen mediante campos de fuerza puntuales: ahí donde la suma de las intensidades supera cierto umbral, existe el objeto. El resultado son estos objetos con formas casi "orgánicas", muy apropiados para modelar, por ejemplo, moléculas. El modelo de la imagen contiene dos blobs: el externo está formado por ocho puntos de fuerza, y el interno está formado por campos distorsionados, para producir elipses en lugar de esferas.

Para cada rayo de luz emitido, la aplicación debe resolver una ecuación de cuarto grado; algo parecido ocurre con las rosquillas, o toros. XSight RT implementa un algoritmo optimizado al detalle para resolver estas ecuaciones, y el resultado es que resulta más rápido generar una rosquilla en XSight RT que en algún ray tracer implementado en C++ "nativo". Es todo un triunfo para C#, y uno de los motivos para elegir la imagen para la portada del manual.

Libros sobre ASP.NET

2007-09-26T15:43:00.000+02:00

Y ya puestos a recomendar libros, si necesita un buen libro para iniciarse con ASP.NET 2.0, mi libro recomendado es también de Dino Esposito: Programming Microsoft ASP.NET 2.0, Core Reference.

¿Hablamos un poco sobre ASP.NET? Esta tecnología es la "culpable" de que abandonase el desarrollo de Sonata, los componentes con los que se desarrolló el viejo Classique. Sonata y ASP.NET compartían una misma idea: la de los controles declarativos en la plantilla HTML. La alternativa que ofrecía Delphi, y que me empujó en primer lugar a crear Sonata, era el componente tradicional de Delphi que, a lo largo de varias complicadas transformaciones, creaba la página final: usted no sólo tenía que programar la plantilla, sino también un "módulo Web" en el Delphi de toda la vida (estoy hablando de WebSnap). Sonata simplificaba todo eso, porque con un mínimo de programación en Delphi, mayormente relacionada con el modelo de datos, el escenario principal se trasladaba a la plantilla.

... y, para desgracia mía, ASP.NET 1.0 simplificaba muchísimo más las cosas. Naturalmente, hay mucho más en ASP.NET que el mero concepto de control declarativo, pero muchas de esas ideas ya estaban en los planes de desarrollo de Sonata. Con lo que no podía competir, sin embargo, era con el soporte en tiempo de diseño. Ni yo ni, por lo visto, la propia Borland (Delphi.NET incorpora las superficies de diseño para .NET de Microsoft).

ASP.NET 2.0 es una bestia impresionante, incluso comparándola con la versión anterior. Y lo digo en el mejor de los sentidos. Es muchísimo más eficiente que JSP (lo dicen las pruebas, no yo), y es infinitamente más elegante que el modelo propuesto por PHP. De hecho, he intercalado lo de "modelo" para dejar claro que ASP.NET no es un lenguaje, sino una tecnología más amplia: usted puede elegir usarla con su lenguaje favorito para .NET, ya sea C^#, VB.NET o Chrome.

Si tiene que aprender ASP.NET, ¿qué libros mejores que los de Dino Esposito? Oh, sí, quizás uno mío, pero aún no lo he escrito :)

Tres artículos que comparan C^# con Java:

Libros sobre AJAX

2007-09-26T15:23:00.000+02:00

Si a estas alturas, todavía no ha oído hablar de AJAX... bueno, es que necesita un libro como éste. Introducing Microsoft ASP.NET AJAX es un libro más de Dino Esposito, en mi opinión, el autor de los mejores libros sobre ASP.NET disponibles, y un colaborador habitual de la MSDN Magazine.

AJAX, por supuesto, significa Asynchronous JavaScript And XML y, en pocas palabras, es una técnica que permite realizar peticiones concurrentes a un servidor HTML desde un browser, de manera que el resultado pueda utilizarse para actualizar la página a través de su árbol de objetos. ¿Demasiado larga la oración anterior? Bien: imagine que tiene una aplicación de bases de datos basada en HTML. Está mostrando un listado y quiere marcar y modificar un registro del listado. Con las técnicas "tradicionales", tendría que enviar un pedido al servidor y recuperar una nueva página completa. Con AJAX, podría enviar un pedido al servidor, igual que antes... pero recuperar solamente la parte de la página que ha sufrido cambios, y dejar que JavaScript combine la respuesta "parcial" con la página ya existente.

En este momento, puede utilizar ASP.NET AJAX con Visual Studio 2005, por medio de unas extensiones de Microsoft. Y, por supuesto, Visual Studio 2008 ya vendrá con soporte para AJAX incorporado. Si quiere dedicarse en serio a la programación Web con ASP.NET, necesitará este libro. Eso sí: no es un libro para aprender ASP.NET, ni mucho menos.

Tras las vacaciones

2007-08-27T18:03:00.000+02:00

Preparo un curso presencial para finales de septiembre, sobre .NET Remoting, servicios Webs y servicios corporativos (Enterprise Services = .NET sobre COM+).

Todavía tengo alguna duda sobre el formato (y por consiguiente, sobre fechas), pero lo más probable es que tenga formato de seminario de un día, en plan guerrilla (BYOL: bring your own laptop, o traiga su portátil) para abaratar precios. La documentación incluirá la "famosa" serie E, que estoy terminando ahora.

Coca Cola, cerveza y café, a cargo de IntSight...
(if you got the money, honey, we got your disease)

LINQ, Freya, Miranda

2007-08-23T22:36:00.000+02:00

El siguiente listado muestra otra de las características "experimentales" de Freya: los filtros de iteración.

for i in 2..Max div 2 : not Result[i] do
begin
    // ... etcétera...
end;

Freya

Se trata de un pequeño fragmento del algoritmo de la Criba de Eratóstenes, implementado en Freya, y muestra el uso de iteración mediante rangos y filtros. El bucle recorre valores enteros entre dos límites, pero sólo entrega aquellos números que no han sido marcados como primos todavía. El compilador traduce esta instrucción for en un bucle for numérico "clásico" con una instrucción if/then anidada. ¿Para qué tomarse entonces la molestia?

El minimalismo en lenguajes no es necesariamente bueno

Esa es una curiosa superstición, que se desenmascara mirando lo que ocurre con Java. En este lenguaje, el repertorio de constructores de tipos es muy limitados: nada de delegados, nada de enumerativos, tipos de valor los justos... ¿Traspaso de parámetros por referencia? ¡Anatema, pecador! Copie el valor a modificar en la primera entrada de un array de un solo elemento, y pase el array como parámetro. ¿Necesito seguir?

La combinación de rango más filtro aumenta mucho la expresividad

Mi teoría es que, en este caso, una simple ojeada a la cabecera del bucle deja las intenciones muy claras. Si no me cree, piense que ha escrito un for con un if anidado, y que la instrucción condicional tiene un bloque de instrucciones relativamente largo. ¿Cuánto tiempo tardaría en averiguar si existe una cláusula else o si se trata de un simple if/then? Espero que coincida conmigo en que se trata de dos patrones algorítmicos muy diferentes.

Confieso, no obstante, que llegue a lo creo un buen diseño gracias a una confusión. Freya se está diseñando, desde el primer momento, mediante un método que podríamos llamar mutación, erosión y selección, siguiendo un patrón similar al que ocurre con los lenguajes humanos. La mutación puede ocurrir deliberadamente o por error. Por ejemplo, en los primeros días, cuando Freya se parecía muchísimo más a Delphi, escribí por error una declaración de variable "global" dentro de una sección de implementación. Pero me di cuenta enseguida de que podía reinterpretar la declaración como una variable de instancia privada. Este un ejemplo de mutación. Un buen ejemplo de erosión es la omisión del nombre de la clase en el constructor. Al principio, el constructor llevaba el mismo nombre de la clase, pero un buen día olvidé escribir el nombre... y me di cuenta que era innecesario. Naturalmente, la selección es el proceso posterior a estos errores: es cuando me digo "y vio Ian que era bueno".

Miranda

¿Cuál fue mi error inicial, en este caso? Freya ya tenía rangos, que permitían tres usos: el uso trivial en instrucciones case, como operandos en el lado derecho del operador in y como iteradores en la instrucción for... sin filtros en aquel momento. Cuando me di cuenta de la frecuencia de aparición de iteración más selección en los ejemplos, pensé en introducir algo parecido a las expresiones de Zermelo-Frankel. Este ejemplo pertenece a Miranda:

[ n | n <- [1..5] ; n mod 2 = 0 ]

Una expresión ZF, o list comprehension, en la jerga funcional, permite directamente las tres operaciones más importantes soportadas por LINQ: iteración, selección y proyección. ¿Por qué no sustituir ese desagradable dialecto llamado SQL (¡sí, SQL como lenguaje es malísimo!) por un formalismo más elegante? Tenga presente que en mi ejemplo, el filtro se ha aplicado a un rango, pero en realidad, Freya permite usarlo con cualquier iterador...

En realidad, se trata de dos errores. El primero, es que la combinación de iterador más filtro no es, hablando con propiedad, una expresión de Zermelo-Frankel completa, pues necesita la variable de iteración para tener sentido. La primera consecuencia es que la idea no puede trasladarse automáticamente al operador in. Para verlo, sólo intente escribir una expresión in sobre un iterador filtrado. Es cierto que estas expresiones de pertenencia no ganan mucho cuando el iterador es un rango numérico, pero tenga presente que Freya permite usar el operador in con cualquier tipo que publique un método Contains (sí, hay que ampliarlo todavía para que maneje el tipo IEnumerable a secas).

LINQ

No se trata, sin embargo, de un error grave: a pesar de no poder aplicarse directamente a las pruebas de pertenencia, el recurso sigue siendo útil para los bucles for, como ya he explicado, por lo que mantuve la idea. El segundo error es más interesante: ¿pueden realmente las expresiones ZF reemplazar a LINQ? Con las debidas extensiones... sí. Pero estamos perdiendo de vista algo muy importante. Mi idea, realmente, era poder compilar eficientemente las expresiones de este tipo. Ahora mismo, C# 3.0 permite escribir código como el siguiente:

List<int> lista = { 1, 2, 3, 4, 5 };
if (lista.Exists(x => x % 2 == 0))
{
    // ... etcétera...
}

No se trata de LINQ directamente, por cuestiones sintácticas, pero sí es la base de la implementación de LINQ: la prueba de existencia se convierte en una llamada a un método que recibe un delegado (un puntero a método, al fin y al cabo). ¿Eficiencia de la llamada? Asquerosa. Sí, es muy expresivo, pero sería mucho más rentable expandir el bucle de búsqueda en línea... si éste no consumiese tanto espacio y no ocultase nuestras intenciones.

Imagine ahora lo que ocurrirá cuando LINQ esté disponible: en principio, le permitirá acrobacias más complicadas con la nueva sintaxis... al precio de convertir su aplicación en una lenta babosa caracolera. ¿Significa esto que LINQ es un error? ¡De ningún modo! Pero el motivo por el que LINQ tiene sentido no está siendo debidamente explicado por los evangelistas entusiastas de la idea que pululan por foros y bitácoras. Y no me di cuenta del problema hasta haber experimentado con la característica de Freya que acabo de explicar.

Code is data

El verdadero corazón y sentido de LINQ no son esas amaneradas imitaciones de la sintaxis de SQL... sino los árboles de expresiones. Seamos sinceros: si LINQ sólo se pudiese usar con estructuras en memoria como las listas, sería una porquería del tamaño de la suma de todos los libros impresos sobre Java. Sería una porquería porque no habríamos logrado nada compilando estas construcciones como llamadas a métodos de la biblioteca de clases. Excepto ineficiencia, claro...

¿Por qué hay que llamar, entonces, a métodos de la biblioteca de clases? Pues porque, en algunos casos, como deja entrever la publicidad sobre LINQ, estos métodos, en vez de recibir delegados asociados a métodos anónimos, exigirán que el compilador les pase esos misteriosos árboles de expresiones. ¿A qué tipo de datos pertenece el parámetro del método en la siguiente llamada?

sequence.Where(x => x % 2 == 0)

En la mayoría de los casos, se tratará de un tipo delegado, pero podría tratarse de un árbol de expresiones. En ese segundo caso, sería el propio compilador de C# (como muestra la beta de Orcas) quien debería crear una estructura en memoria que reflejase la estructura de la expresión lambda para pasarla como parámetro. Es un comportamiento importantísimo, pero muy poco documentado.

¿Para qué puede querer un método recibir un árbol de expresiones, en vez de un puntero a método? Motivos sobran. Por ejemplo, el método puede transformar el árbol en una cadena que represente una instrucción SQL para pasarla a un servidor SQL. O el método puede formar parte de la capa de comunicación con un servidor remoto, y enviar una versión serializada del árbol para que sea evaluado al otro lado de la red. Estos son los casos reales de uso de LINQ, no esas tonterías de manipulación de listas en memoria que muestran casi todos los ejemplos.

¿Se da cuenta que LINQ, hasta cierto punto, nos retrotrae a los tiempos en que estaba de moda considerar el código como datos? De hecho, ¡podemos convertir fácilmente un árbol de expresiones en código nativo ejecutable! Si usted guarda fórmulas para los gastos de envío en una base de datos, seguirá necesitando un pequeño analizador sintáctico para convertirlas en árboles de expresiones. Pero ya podrá delegar en el sistema la conversión del árbol en código. ¿No es estupendo?

Resumiendo: LINQ es una buena idea, pero está siendo mal explicada. El riesgo que se corre es que aparezcan aplicaciones que utilicen LINQ de forma incorrecta... como, efectivamente, sugieren la mayoría de los ejemplos disponibles, incluso de la propia Microsoft. En segundo lugar, una vez que se comprende este problema, se comprende también que existe una puerta abierta en el diseño de lenguajes para .NET. Puede que sea beneficioso aumentar la potencia expresiva de las operaciones sobre listas mediante una sintaxis especial, paralela a la de LINQ. O puede que lo indicado sea la optimización de las llamadas a determinados métodos de determinadas clases, ya sea por medio del compilador o por medio de alguna utilidad aplicada al ensamblado compilado... pues dudo que el JIT llegue a estos extremos.

Liaison

2007-08-20T20:29:00.000+02:00

¿Es Pascal un lenguaje "verboso"? Depende de con cuál lenguaje lo comparemos, por supuesto, pero en términos generales, se puede decir que sí lo es, porque introduce mucha redundancia en determinadas construcciones sintácticas.

Eche un vistazo a la siguiente, por poner un simple ejemplo:

for i := 0 to 9 do
begin
    WriteLn(i);
    WriteLn(i * i);
end;

Parece un código tan claro que casi brilla, pero ¿adivina qué es lo que sobra? Le daré una pista: localice dos palabras reservadas consecutivas...

Y esto, ¿qué le parece?:

for i := 0 to 9
begin
    WriteLn(i);
    WriteLn(i * i);
end;

Efectivamente, he eliminado la palabra clave do por estar ubicada antes de un begin. En general, la penúltima sintaxis de Freya permite, como opción, eliminar los do y los then que van antes de instrucciones que empiecen con palabras reservadas. Esta medida es parte de un esfuerzo de limpieza de la sintaxis que se ha cargado también construcciones propias de Freya como for var, que antes indicaba que estaba teniendo lugar una inferencia de tipo para una variable local.

Una aclaración: dos palabras claves consecutivas no siempre indican redundancia. Sólo es así cuando la palabra clave sólo hace de "esqueleto", es decir, cuando su papel es evitar ambigüedades sintácticas.

¡Ah!, y si se pregunta por qué me preocupan ahora los lenguajes verbosos y la redundancia innecesaria: estoy harto de pagar precios astronómicos por la puñetera tinta de impresora, el tóner y el papel. Hay más razones, pero ésta es importante y me parece incluso suficiente...

Perú

2007-08-18T18:16:00.000+02:00

Llegan malas noticias desde Perú. Si conocéis alguna forma de ayudar...

Enigma

2007-08-15T22:34:00.000+02:00

¿Qué son los números complejos? Rostros que imaginamos en la Máquina de Turing.

La frase parece un sinsentido, pero tiene que ver con la forma que esperamos que adopten las teorías físicas más básicas. ¿Se ha preguntado alguna vez si el Universo es computable? Hay físicos que ya se lo están preguntando, aunque no hay aún una respuesta definitiva, sino una esperanza: que, efectivamente, lo sea. Y si lo es, la Ultima Realidad Física podría ser un mero proceso informático, aunque de una potencia brutal. Todo algoritmo sería, en realidad, un subalgoritmo dentro de un algoritmo global (¿conoce el sentido en Física de la frase "la vista de Dios"?). Y las entidades "platónicas" como los números complejos, que tanto han atormentado a Roger Penrose, serían el resultado de intentar analizar el funcionamiento de la Máquina mediante técnicas "orientadas a objetos". Algo parecido a los rostros que el ojo humano termina por ver en cualquier nube de verano.

... y no, no he bebido ni fumado nada raro :)

Para febrero del 2008...

2007-08-15T22:07:00.001+02:00

Nueva versión de Intuitive C#

2007-08-09T01:04:00.000+02:00

Hay nueva versión de Intuitive C#. Sigue siendo un libro incompleto, aunque hay 30 páginas más que en la última versión. No he intentado disimular los huecos (sobre todo en el capítulo 2). No sé si voy a tener tiempo para seguir actualizando este libro: más prioridad tienen el nuevo libro (para febrero de 2008) y el curso de ADO.NET (para septiembre).

El fichero de ayuda de Freya

2007-07-02T11:41:00.000+02:00

Está en inglés y no está terminada, pero es la documentación más exacta respecto al estado actual de Freya:

Ayuda HTML de Freya

Ayer intenté subir el fichero compilador CHM, pero al descargarlo para probar, me daba problemas con las zonas de seguridad. La solución más rápida era generar un instalador, pero me pareció excesiva.

Lo decía en un comentario, pero lo repito aquí arriba: preparaos para un megalibro sobre C# a finales de año. Como suele ocurrir en estas cosas, va a ser el mejor libro que he escrito hasta el momento: por temática, por tratamiento, por concisión y por estilo. Sobre esto último, una de las "novedades" que he mantenido ocultas en este período es que finalmente he puesto una lanza en la escritura "de ficción"... usando un pseudónimo. No creo que me vaya a "forrar" de momento, ni a producir mucho revuelo literario... de momento, pero las consecuencias para mi trabajo de informático es que ahora escribo un poco mejor, incluyendo los libros técnicos.

... y no, no voy a mezclar lo que debe ir separado.

Y no os preocupéis, amigos, que no se trata de una depresión. La depresión es una enfermedad seria, que afecta por igual a hombres y mujeres, pero mis cabreos no van por ahí. De hecho, quienes me conocen personalmente saben que lo más frecuente es encontrarme cabreado, o por darle algo de dignidad, "justamente indignado". Se podría escribir un libro que comenzase Canta, oh diosa, la cólera del martínida Ian....

Para que no os aburráis demasiado, los que aún no estáis de vacaciones, ahí va una de las ventajas de Freya (Enrique, te debo un mensaje... y a Jaime, y a Nico, y a David...) respecto a alternativas similares: las interfaces en Freya pueden incluir aserciones:

IStack = interface[X]
    property IsEmpty: Boolean; readonly;
    property Top: X; readonly;
        requires not IsEmpty;

    method Push(Value: X);
        ensures Top.Equals(Value);
    method Pop: X;
        requires not IsEmpty;
        ensures Result.Equals(old Top);
end;

De hecho, ¡no tendría mucho sentido tener un lenguaje con interfaces y aserciones, y que estos dos recursos no se pudieran combinar! Se trata, además, de una combinación segura, no problemática: más problemas, tanto teóricos como prácticos, da la transmisión de aserciones a través de una cadena de herencia.

Un patrocinador para Freya

2007-06-24T22:46:00.001+02:00

Si trabajas en una empresa lo suficientemente grande como para que pueda asumir el reto, quizás a tu jefe... o a tí, si eres el jefe, le pueda interesar patrocinar el proyecto Freya.

¿Qué motivos puede haber para patrocinar un proyecto de este tipo?

Históricamente, muchos de los lenguajes de programación de los que ahora disponemos han surgido del mecenazgo de importantes empresas tecnológicas, que no eran exactamente consultorías especializadas en Informática. Los casos más conocidos son los de AT&T, de donde salieron C y C++, y el del Departamento de Defensa de los Estados Unidos, que fue la cuna de Ada.

Ayuntamientos de grandes ciudades, o comunidades autónomas, pueden encontrar interesante el proyecto. Por una parte, muchas veces funcionan como grandes empresas, y se suponen que apoyan la iniciativa empresarial, la creación de puestos de trabajos, etc, etc. Conozco, por ejemplo, un proyecto de entorno de desarrollo y compilador para COBOL, patrocinado en su momento por la Comunidad Valenciana, y los ejemplos de patrocinio de distros de Linux son muchos.

Para una empresa, puede ser interesante el patrocinio gracias a las ventajas fiscales de este tipo de ayudas.

Y están las ventajas obvias: publicidad, tanto en Internet como en libros y cursos, material de formación gratuito para la empresa, etc, etc.

... y observe que no entro, deliberadamente, en las ventajas técnicas: una empresa con un potente departamento de software puede beneficiarse enormemente por disponer de una tecnología como la de Freya. Incluso no se trata ya del propio lenguaje: está la experiencia en el propio entorno, la posibilidad de crear lenguajes especiales dependientes del dominio, el desarrollo de herramientas para lenguajes existentes, como verificadores estáticos, analizadores de flujo, etc. Incluso empresas que comercializan un producto de software pueden utilizar este know how para incorporar lenguajes de script en su producto principal.

Claro, todo depende de cuánto sea necesario gastar en el patrocinio. Pues bien, las cuentas pueden salirle incluso en este sentido. Objetivamente, el gasto mínimo consistiría en un apoyo salarial para un programador durante un plazo de un año (luego hablaré de plazos y objetivos). Al no ser necesaria una dedicación al 100%, ni siquiera se trata de un salario completo (con los extras de retenciones fiscales, seguridades sociales, etc, etc). No voy a hablar de cifras en público, pero tenga presente que estoy hablando de una fracción de un salario.

¿El estado del proyecto? El compilador está prácticamente terminado. Durante el año del patrocinio, el objetivo sería redondear un entorno de desarrollo propio (completando SharpBlade) o adaptar el compilador para su uso dentro de Visual Studio o SharpDevelop. Ya hay bastante trabajo hecho en esta dirección, por supuesto.

Por último, hay otra opción posible: si le interesa adquirir derechos sobre Freya, incluso sobre el producto completo. No es la opción que veo más probable, pero es posible, y sería cuestión de negociarlo.

Busco trabajo

2007-06-24T06:04:00.000+02:00

Busco trabajo como programador, analista o jefe de proyecto. 18 años de experiencia laboral demostrables. Pueden ser proyectos como freelance o a tiempo completo o parcial. Motivo: hartazgo de funcionar como empresario y que Hacienda se lleve casi todo lo que gano.

Mi nombre es Ian. Mi actual empresa es IntSight. Mi dirección de correos es mi_nombre arroba mi_empresa puntocom.

Lo pequeño y lo grande

2007-06-15T13:45:00.000+02:00

¿Ha visto ya las noticias sobre Microsoft Surface? Por si le da pereza seguir el enlace, o si no tiene ahora mismo una conexión decente a Internet, le resumo la idea: se trata de un ordenador sin teclado ni ratón. Tiene pequeñas cámaras bajo el cristal de protección que siguen los movimientos de los objetos que entran en contacto con el cristal. De esa manera distinguen los dedos de otros dispositivos con los que pueden interactuar.

Aunque no parezca complicado a simple vista, algo tan sencillo abre muchas puertas... e introduce algún que otro problema. En un ordenador convencional, hay un único cursor para el ratón. En la superficie, por el contrario, se pueden usar simultáneamente varios dedos. Es posible que dos o más personas utilicen simultáneamente la superficie, mientras que nuestros ordenadores asumen por lo general que los está manejando un único usuario.

Mientras veía el vídeo pensé en cómo estaría implementado el software del sistema. Naturalmente, bajo la superficie (nunca mejor dicho) hay un Windows Vista, pero me refiero al lenguaje en que se programan las aplicaciones especializadas para esta plataforma. Y me he dado cuenta de otra ventaja con .NET que los antiguos programadores de Delphi no teníamos:

Suponga que retrocedemos a la época anterior a .NET. ¿Cómo accederíamos a las nuevas APIs desde Delphi "clásico"? Lo más probable es que la nueva API residiese en una DLL. Por lo tanto, los programadores Delphi tendrían que esperar a una traducción de las cabeceras de C++ a Pascal para poder hincarle el diente. ¿Cuánto tiempo se tardaba, típicamente, en aquellos gloriosos años? Tenga en cuenta, además, que muchas veces estas interfaces traducidas contenían errores de traducción: ocurrió en su momento con el software de la mismísima Borland.

En claro contraste, esta traducción no es necesaria en .NET. Da igual el lenguaje con el que haya sido programado el API de la superficie: cualquier lenguaje .NET (¡sí, incluyendo Freya!) puede empezar a trabajar con el API, pues la traducción es automática, sin necesidad de intermediarios.

¿Una insignificancia? Puede. Pero sin importar lo pequeña que sea, se trata de una ventaja, o más bien, de una de las muchas pequeñas ventajas de la migración a .NET. A veces la cercanía a los árboles nos impide disfrutar del bosque.

De momento, se trata de un dispositivo caro. Al parecer, Microsoft empezará implantándolo en hoteles y bares de "alto standing". He visto también una aplicación de un dispositivo parecido, si no es el mismo, para implementar un sintetizador, en una universidad española. El punto fuerte del sintetizador era que permitía que varias personas lo "tocasen": no usaba teclas, sino que "respondía" al contacto con los dedos y con figuras geométricas predefinidas, a modo de fichas.

It's just a spring clean for the May Queen

2007-06-13T02:29:00.000+02:00

There's a feeling I get
when I look to the West,
and my spirit is crying for leaving...

LALR

2007-06-07T14:16:00.000+02:00

¿Tiene alguno de vosotros código que funcione para un generador LALR? Sí, ya sé que hay unos proyectos por ahí equivalentes a yacc/bison... pero me llevaría demasiado tiempo retocarlo y adaptarlo. El tiempo que no tengo ahora.

El caso es que tengo una idea de "producto": un generador de compiladores especialmente adaptado para .NET. ¿Cuál es el problema? Cuando se trata de compiladores .NET, o creas un compilador recursivo descendente, a mano (o con alguna ayuda de herramientas), o utilizas un analizador LALR(1), que suelen ser más potentes. Pero en este último caso, te encuentras un problema: el analizador suele llamar a un conjunto de rutinas para construir un árbol durante la compilación. Y esas rutinas por obligación reciben todos sus parámetros como valores de tipo object o de alguna clase base más o menos igual de primitiva. Como resultado, tienes que estar ejecutando conversiones dinámicas de tipos todo el tiempo. No se trata tanto de la pérdida de velocidad, que al final no es tanta, sino de la pérdida de seguridad, robustez, etc, etc. En un entorno nativo, podías realizar conversiones estáticas (arriesgándote a recibir un error en ejecución si te equivocabas), pero esto no es posible en .NET.

Hay otro problema: el modelo de desarrollo. Quien crea un compilador de esta manera tiene que programar, por una parte, la gramática "a secas". Luego de ejecutar la herramienta que la convierte en código ejecutable, tiene que ocuparse de establecer las correspondencias entre reglas de la gramática y rutinas semánticas. En sistemas más "primitivos", como el yacc, podías escribir las rutinas junto con las reglas. Sin embargo, GOLD Parser Builder, a pesar de ser una herramienta mucho más agradable de usar, sigue la filosofía de separar reglas y rutinas, en beneficio de la independencia del lenguaje.

Mi idea es crear un generador de compiladores basado en un lenguaje propio, de estilo funcional (es lo más adecuado en estos casos). Para cada no terminal de la gramática, se establecería un tipo para los nodos que generaría. Entonces, el generador podría crear pilas separadas para cada uno de los tipos asociados a las reglas. Así se evitaría el problema de las conversiones.

Por otra parte, por muy poca potencia que le des al lenguaje, se logra mucho. Como el objetivo de los "programas" es generar una estructura de datos arbórea, la mayoría de las llamadas serán a constructores. No es necesario que el lenguaje tenga "lazy evaluation", porque el algoritmo de análisis bottom-up garantiza que los parámetros de llamada a cada constructor ya estarán evaluados antes de esta llamada. Además, teniendo ya experiencia en compilar código para .NET sería extremadamente fácil que la herramienta crease directamente módulos o ensamblados, listos para utilizar, sin necesidad de pasar por un fichero intermedio con código fuente en otro lenguaje.

¿Alguien se anima?

¿Cuánto son dos más dos?

2007-06-05T14:02:00.000+02:00

... y ahora pretenderán que los que siempre respondimos "cuatro" nos alegramos de que finalmente no hayan sido cinco.

Cuando yo no trabajo, no cobro. Pretender que en España alguien dimita por un error, aunque sea por tamaño error, es ser muy inocente. Pero al menos que no cobre. Que no cobre ni un duro de salario, que vaya a La Moncloa en el metro de Aguirre y Gallardón, que se olvide de los helicópteros del ejército para ir a ver los toros o a su mujer haciendo los coros, hasta que todos aquellos con los que ha estado impúdicamente coqueteando durante estos meses estén donde siempre debían haber estado: en la cárcel, o entre las seis tablas de madera de un paralelepípedo oblongo.

Object triggers

2007-05-09T17:37:00.000+02:00

Aunque es prematuro, todo sea por concretar un poco la idea:

// Freya

Editor = class
public
    property CurrentPosition: Position;
    event PositionChanged: EventHandler;

protected
    method OnPositionChanged; virtual;
    begin
        var eh := PositionChanged;
        if eh <> nil then
            eh(Self, EventArgs.Empty);
    end;

implementation

    // Este es un trigger: se admite read, write y execute.
    // Pueden combinarse varios recursos en un mismo trigger.
    on CurrentPosition(write)
    var
        // Estas variables se convierten en campos
        flag: Integer := 0;
    begin
        flag++;
        // Esto sí es una verdadera variable local:
        var initialPosition := currentPosition;
    finally
        flag--;
        if flag = 0 then
            if initialPosition <> currentPosition then
            OnPositionChanged;
    end;

end;

He intentado no meter palabras reservadas nuevas, al menos mientras no estén más claras las ideas. Lo que quiero averiguar es si con esta simple técnica se pueden lograr todas las cosas positivas de la AOP, sin provocar, a la misma vez, todos los problemas que ahora provoca. La clase, por supuesto, tendría mucho más código, y los triggers, por llamarlos de algún modo, siempre van en la implementación de la clase (no interesan al cliente de la clase).

Importante: los campos usados por un trigger son solamente visibles para el propio trigger. Por ello puede usarse un nombre como flag sin preocupaciones, porque de existir ya un miembro con este nombre, el campo se renombraría.

Y por supuesto, la historia puede complicarse todo lo que se quiera: ¿se podrían heredar triggers para aplicarse a nuevos recursos? Probablemente sí, en la medida en que el recurso protegido pueda ser modificado en una clase derivada. ¿Tiene sentido definir triggers independientemente del recurso que protegen, para enlazarlos luego con un recurso en una implementación? Supongo que dependerá de la complejidad del código que pueda meterse en un trigger.

Observe también que, en general, podría vigilarse más de un recurso con el mismo trigger. Imagine que, en vez de tener una variable (o una propiedad) que encapsula fila y columna, tenemos dos campos separados. En tal caso, el mismo trigger se "tejería" para los métodos que modificasen uno u otro campo. ¿Tiene sentido definir triggers para que se apliquen cuando un método acceda a uno y otro campo? No lo sé: tengo que encontrar un ejemplo con sentido. De esto, de encontrar más ejemplos, se trata ahora.

NOTAS

A quien haya seguido ejemplos anteriores en Freya, le extrañará probablemente la implementación en línea del método OnPositionChanged. No hay nada extraño: Freya sigue manteniendo el viejo formato, con las declaraciones en secciones public/private y secciones implementation for para las implementaciones. Pero ahora también es posible utilizar el estilo en línea, como en Eiffel (y Java y C#). Observe, de paso, que incluso en tal caso sigue existiendo una sección implementation, aunque en ella ya no se menciona la clase, por ser innecesario. En esta sección siguen residiendo los "detalles de implementación", que sería inapropiado situar en una sección "regular". Por ejemplo: constructores de clase (estáticos), delegaciones de implementación para tipos de interfaz, implementaciones explícitas de miembros de interfaces y destructores.

Una vez aclarado este punto, observe que CurrentPosition es una propiedad sin implementación explícita. En estos casos, el compilador declara un identificador oculto y genera automáticamente los métodos de acceso necesarios. Mejor aún: cuando se hace referencia a la propiedad dentro de la misma clase, ésta se sustituye por una referencia al campo. Y si la propiedad no es virtual, el campo oculto se declara internal, y la optimización se realiza también para los usos de la propiedad dentro del propio ensamblado, con independencia de la clase. Si alguna vez se cuestiona la necesidad de Freya, recuerde que la calidad del código generado es muy superior a la media de los compiladores para .NET, a pesar de las limitaciones impuestas por la plataforma :)

Otro pequeño detalle: observo cómo copio el valor del evento PositionChanged antes de comprobar su valor y ejecutarlo. Es común ver por ahí código que no utiliza una variable temporal, pero aunque teóricamente es correcto, podemos tener problema si alguna vez accedemos al mismo objeto desde dos hilos paralelos. La técnica mostrada es la "correcta", teniendo en cuenta esta posibilidad.

¿Por qué triunfa un lenguaje?

2007-05-04T21:55:00.000+02:00

Es evidente que un lenguaje no siempre triunfa exclusivamente por sus méritos propios. De lo contrario, ¿cómo explicaríamos el larguísimo reinado de C++ y el injusto olvido de Eiffel?

En ocasiones, sin embargo, las causas del triunfo pueden ser sorprendentes, y puede que no hayan sido previstas por su autor. Lo digo porque acabo de recordar algo muy importante que influyó en mi decisión de usar Delphi como herramienta principal de programación... a pesar de conocer bien C++ y del estado más avanzado de este lenguaje y sus implementaciones por aquel entonces. No olvide que, a pesar de los méritos innegables de los genéricos de .NET, C++ tiene templates desde tiempo inmemoriales, igual que Eiffel (y no digamos ya Ada).

Me voy a callar esta causa (hay muchas más, qué duda cabe) un tiempo. Si quiere contar la suya en los comentarios, las iré añadiendo a este post (para ser más concisos, utilice negritas, si quiere, para destacar la parte que quiere que copie). Y luego diré la mía, si nadie la menciona antes...

Una vieja buena idea

2007-05-04T18:47:00.000+02:00

¿Cómo se escribe "un millón" en su lenguaje de programación favorito? En Freya, se escribe así:

1_000_000

La idea, naturalmente, no es nueva: creo que en Ada, como mínimo, hay algo parecido. Y en todo caso, la he copiado directamente de Eiffel. Sin embargo, ¿a que es útil?

Internal affaires

2007-05-03T16:11:00.000+02:00

¿Y si llevásemos la propuesta de exportación selectiva aún más lejos? Quiero decir, ¿y si permitiésemos la mención de rutinas, propiedades y eventos en la lista de entidades con acceso a un recurso? Actualmente, en la sintaxis de Freya, la exportación selectiva tiene este aspecto:

MiClase = class
internal(OtraClase, YOtraMas)
    Campo: Integer;
    // ... etcétera ...
end;

Lo que ahora digo es esto otro:

MiClase = class
internal(MiClase.Propiedad)
    Campo: Integer;
    // ... etcétera ...
end;

Sí, este es un ejemplo "extremo": sólo permito que Campo sea usado por el código de la propiedad Propiedad... de la misma clase donde se ha definido Campo. En circunstancias normales, no habría que caer en el "tremendismo", pero esto permite usar una técnica que he echado de menos en ocasiones. Por ejemplo, en el editor de código se define un campo privado para almacenar la posición del curso. En paralelo, se usa una propiedad para encapsular esta posición. El caso es que, cuando se cambia la línea activa, se producen cambios en el búfer de líneas interno. Sin embargo, es relativamente seguro modificar directamente la columna activa... y uno, que es un triste pecador, lo ha hecho en varias ocasiones. De haber tenido la disciplina suficiente, podría haber asociado un evento a las escrituras en la propiedad. Pero, ¿quién localiza, a estas alturas, todas las violaciones de esta "regla"? Con la posibilidad de reducir el uso de un campo a una propiedad, como propongo, sería muy sencillo, no ya cumplir con la regla, sino ponerla inmediatamente en conocimiento de quien lee el código.

Resumamos las bondades de mi propuesta:

Se reduce fulminantemente la cantidad absoluta de dependencias potenciales entre clases, e incluso dentro de la misma clase.
Como esta técnica afecta solamente a las declaraciones internas, no hay peligro alguno de interacción con otros lenguajes .NET. Puedo seguir utilizando desde C# un ensamblado escrito en Freya, y viceversa.
Cuando en la lista de "entidades" a las que se le permite el acceso aparece una clase, se entiende que es lo mismo que "Clase.*": se le concede acceso a todos los miembros de la clase mencionada.
Este tipo de restricciones de acceso pueden interpretarse también como una modalidad de contrato ligado a la implementación de un recurso. Este tipo de contrato ya es muy popular entre los programadores, pero no existe una forma sencilla de hacerlo explícito.

La visión reduccionista

Una reflexión al margen: otra solución al evento que falta en mi editor de código podría utilizar la Programación Orientada a Aspectos: podría indicar que, para todos los métodos que modifiquen la posición del cursor, se genere un prólogo en el que se memorice la posición inicial, y un epílogo que dispare el evento si se han producido cambios. Menciono esto porque es importante observar la gran diferencia entre la solución OOP y la solución AOP. Y la observación tiene que ver con el énfasis que pone la AOP en el texto del programa. La visión OOP monta capas y más capas de abstracciones sobre las tiras de caracteres del programa, mientras que la visión AOP, al centrarse en el texto, se podría calificar incluso de reduccionista.

Y no se trata de un mero florilegio retórico. Por una parte, está demostrado que la AOP resuelve algunos problemas (no todos) de manera más eficiente, sencilla y controlable que la OOP. Pero se trata de sustituir una cosa por la otra... porque no es ese el propósito de la AOP. Se trata de que este enfoque reduccionista puede aportar claridad a muchos debates viciados. Durante tiempo hemos intentado juzgar la OOP según sus propios reglas. ¿El resultado? Pues que cada vez es más difícil evaluar los méritos de las propuestas y novedades. Y por otra parte, vemos a autores a los que se le supone cierta seriedad defendiendo tonterías como el llamado "duck typing".

¿Una pista sobre el impacto que puede tener la visión "reduccionista" en Informática? Ahí tiene el revuelo que han traido consigo las clases parciales de .NET 2.0. En principio, se trataría de un mero "truco" de ficheros... pero resulta que el "truco" ha encontrado aplicaciones de todo tipo. Y es que, al fin y al cabo, una de las grandes justificaciones de la OOP tiene que ver con la "mera" distribución del código fuente: en la programación estructurada original, se tendería a organizar el código de acuerdo a su función, mientras que en la OOP, el código se agruparía respecto al "propietario" de cada método. Eso facilitaría la adición de nueva funcionalidad: observe que se trata de una justificación textual y reduccionista.

Bienvenido sea el reduccionismo...

Espada afilada

2007-04-30T00:33:00.000+02:00

La prima de un amigo de mi cuñada

2007-04-16T21:43:00.001+02:00

Según una popular leyenda urbana, entre usted y cualquier otra persona, sin importar el país de esta última, existe una cadena de conocidos que es sorprendentemente corta: usted conoce a Fulano, quien a su vez conoce a Mengano, el primo de Zutano, aquel que es amigo de la peluquera de Drew Barrymore. La longitud de la cadena, por supuesto, depende de quién cuente la historia. En todo caso, es una leyenda en la que creo. ¿Qué tal siete eslabones?

¿Y si este fenómeno tuviese en parte la culpa de que las bases de datos orientadas a objetos no hayan prosperado como predecía la teoría? Podrían combinarse negativamente dos factores:

Por una parte, estaría lo que acabo de explicar: que en la mayoría de los esquemas de datos, hay tanta imbricación que, un sistema de bases de datos orientado a objetos implementado ingenuamente, podría saturar en muy poco tiempo la memoria dinámica, trayendo a ésta casi todos los registros.
En principio, habría técnicas para evitar esto, utilizando carga por demanda... pero, ¿se da cuenta de que estamos hablando de clases y objetos, y por lo tanto, de encapsulación? Si enredamos demasiado con las relaciones estructurales, entraremos en conflicto con la encapsulación.

No estoy diciendo que ésta, en concreto, sea la única causa, ni la principal. Se me ha ocurrido esta posibilidad mientras pensaba en los pros y contras de un sistema como LINQ: me parece que el principal y casi seguro logro de LINQ va a ser que dispondremos de unos datasets estupendos, aunque no los llamemos así en lo sucesivo. Habrá que esperar a la implementación de los árboles de expresiones para ver qué tal se comporta la recuperación de registros desde un servidor SQL: como, de todas maneras, el servidor SQL optimizará la consulta recibida, es casi seguro que, incluso en el peor de los escenarios, funcione bien. Y todo esto es bueno y deseable. Pero nada de esto no nos acerca a las bases de datos orientadas a objetos. Y puede que esto último también sea bueno y deseable.

Corolario: Entre usted y los extraterrestres hay al menos una cadena de ocho eslabones.

Demostración: Entre usted y Drew Barrymore hay una cadena de no más de siete eslabones. Y Drew Barrymore conoce a E.T.

En el radar

2007-04-14T15:44:00.000+02:00

Próxima actualización en el radar: nueva entrega de Intuitive C#. Hay un nuevo capítulo sobre P.O.O. (el segundo), que no cuenta nada nuevo, pero lo que cuenta está más o menos bien escrito. O eso creo. Hay más información sobre reflexión, tipos de interfaz, genericidad, inferencia de tipos en llamadas a métodos genéricos, expresiones lambda (¡sí, las de C# 3.0!), qué es una restricción desnuda y cómo puede usarse para simular la covarianza en la asignación polimórfica de tipos genéricos, convirtiendo, por ejemplo, una lista de empleados en una lista de personas (y provocando una excepción cuando encuentre un abogado en ella)...

No, todavía no lo he subido a Internet. Ya avisaré, probablemente el lunes que viene.

Un comentario breve sobre C# 3.0: no me gusta la forma de "activar" los métodos de extensión. Esto ya lo tenía Delphi.NET 8.0: podías fingir que una clase ajena tenía métodos adicionales definiendo esos nuevos métodos como métodos estáticos cuyo primer parámetro tenga el tipo de la clase a extender. Así, Borland intentaba acercar el System.Object de .NET con el TObject délfico de siempre.

En Freya ya hay unas pocas extensiones predefinidas. Por ejemplo, hay dos extensiones que se expanden en línea: los "métodos" Sqr, que actúa sobre tipos numéricos, y Ord, que convierte caracteres en su valor numérico Unicode:

Console.WriteLine(2.Sqr);

El compilador genera código muy eficiente para Sqr: una instrucción de duplicación y la multiplicación. En una aplicación como XSight RT, donde hay que elevar expresiones complejas al cuadrado constantemente, no sólo queda más legible el código fuente, sino que además, se genera mejor código nativo, y el compilador JIT tiene menos carga y termina antes, al serle más sencillo identificar el patrón. Aparte de esto, se considera que todos los métodos estáticos de la clase System.Math se registran automáticamente como métodos de extensión. Así podemos escribir lo siguiente en Freya:

var L := (X.Sqr + Y.Sqr + Z.Sqr).Sqrt;
if (L - L0).Abs < epsilon then
    // ...

Lo que no me gusta es la forma en que se "activan" los métodos de extensión en C#: basta con incluir el espacio de nombres en una cláusula using, para que todos los métodos de extensión de ese espacio de nombre entren en danza. Lo malo: un espacio de nombre es una entidad sin "chicha" en .NET. Pueden definirse tipos para un espacio de nombre en más de un ensamblado. De modo que al incluir el using, estamos activando todas extensiones, sin importar en qué ensamblado vengan. Además, la cláusula using ya tiene su propia función. Pueden surgir casos en los que nos interese el uso normal y no el extendido. Por supuesto, con mucho cuidado, no tendrían que surgir problemas... pero no deja de ser chapucero.

Exportación selectiva

2007-04-10T12:03:00.000+02:00

Mientras releo el código fuente del sistema de ventanas que mencionaba hace unos días, me reafirmo en mi idea sobre cuál es la primera característica que le añadiría a los lenguajes .NET: la exportación selectiva de sus miembros.

Esta idea, como tantas otras, la conozco a través de Eiffel. En las clases de este lenguaje no existen las típicas secciones private, public o protected, popularizadas por C++. Los miembros de una clase se agrupan en secciones encabezadas por la palabra clave feature (debería tener una "s" final para estar en tercera persona del singular; lo mismo ocurre con require o ensure). Estas cabeceras de sección pueden incluir una lista de clases que pueden utilizar los miembros agrupados bajo ella:

class FULANA
feature

feature { MENGANA, ZUTANA }

feature { NONE }

end

La idea que me ronda no es eliminar el actual sistema de niveles de acceso. En principio, sólo sería necesario ampliar las posibilidades del nivel internal. Ahora mismo, cualquier miembro declarado internal está al alcance de cualquier otra clase definida en el mismo ensamblado. Barra libre, por así decirlo. Imposible saber quién está toqueteando indebidamente el método X y por qué razón lo hace. Menos mal que existe un comando Buscar todas las referencias... pero no es lo mismo.

Lo peor de todo es que existen poderosos motivos para que un programador decida declarar métodos y propiedades internas... cargándose la mantenibilidad del sistema que está programando. Usted ha comenzado a programar su sistema como una aplicación monolítica. Luego se ha dado cuenta de que puede manejar la aplicación desde otra aplicación independiente: basta con utilizar el ejecutable como si fuese una biblioteca de clases. El compilador de línea de comandos de Freya, por ejemplo, es un fichero ejecutable que implementa una aplicación de consola, pero el entorno de desarrollo carga el ejecutable como si se tratase de un ensamblado en formato DLL. El problema es que, casi siempre, las clases dentro del ejecutable habrán sido originalmente diseñadas como clases públicas. Bien, usted esconde las clases A y B pero, ¡qué mala pata!, la clase C tiene una propiedad pública que devuelve un objeto de tipo A. No podemos redeclarar esa propiedad como privada, porque medio programa la utiliza... pero tampoco nos interesa que esté al alcance de cualquier mindundi. ¿La solución? El programador redeclara la propiedad como internal... sin darse cuenta de que acaba de hundirse hasta la cintura en el fango.

Mi propuesta consiste en mantener la misma sintaxis y semántica que ahora tienen los restantes niveles de visibilidad en .NET, y además permitir que el modificador internal pueda ir acompañado por una lista de clases. Tenga presente que el efecto de internal se limita al ensamblado donde se declara. Por lo tanto, este tipo de propuesta es ideal: se logra un efecto muy beneficioso sin necesidad de afectar el funcionamiento de los lenguajes de la plataforma que decidan no secundar la idea.

Aviso: si has comprado un pack ISSE/Intuitive Delphi

2007-04-09T13:46:00.000+02:00

Si has comprado un pack IntSight's Server Explorer/Intuitive Delphi el tres de este mes, por favor, ponte en contacto conmigo por email. El mensaje de confirmación de la compra, con los datos para la zona de descargas, me está rebotando constantemente con "problemas permanentes en la cuenta".

El CD está, de todos modos, en camino, pero estando la Semana Santa por medio, puede aún tardar en llegar (este producto se envía por correo, no por mensajería).

Tres punto cinco...

2007-04-09T12:23:00.000+02:00

... y una pequeña corrección a los comentarios: será .NET 3.5.

Ese es el número de versión que aparece en la beta de Orcas (vaya nombrecito): el Visual Studio 2007, por llamarlo de algún modo. Lo cierto es que toda esta complicación es culpa de la propia Microsoft, que ha tenido que hacer filigranas con las fechas de salida del Windows Vista y el número de versión de .NET para esa familia de productos.

De todos modos, que no cunda el pánico: .NET 3.0 tiene novedades interesantes, pero ninguna que afecte "profundamente" al desarrollo de bases de datos. Al menos, ninguna que empuje a los renuentes a saltar al carro. Mi consejo es el obvio: hay que ser prudentes con la adopción de WFC. No porque tenga algún problema, sino por tratarse de una novedad ligada a una versión específica del sistema operativo (no es exactamente así, pero para abreviar...).

También sería buena la prudencia respecto a LINQ, el nuevo ADO.NET Entity Framework y esas cosas, aunque por motivos diferentes. La adopción de estas nuevas técnicas no está limitada por la base de instalaciones de un sistema operativo: afectan solamente al programador, y si funcionan bien, nada impide que salte al vagón. Mi impresión, de momento, es positiva... pero repito, hay que ser prudentes. Puede que esta vez estemos frente a la técnica que domestique, de una vez por todas, los famosos "persistency frameworks", pero me asusta ver a gente que tenía por sensata (no, no estoy regañando a ninguno de nosotros) quemar tanto incienso por las extensiones al lenguaje inspiradas por la programación funcional.

El problema consiste en que, para que toda esta historia funcione, no basta con que Anders Hejlsberg sea un monstruo de los lenguajes: hace falta que el equipo completo que tiene que escribir las clases de soporte para tiempo de ejecución haga bien las cosas. Y aunque, repito, creo que todo va a salir bien y que va a ser un producto estupendo, no puedo olvidar que la idea de los "Object Spaces" ha estado dando tumbos desorientada por todo el campus de Microsoft hasta que Hejlsberg y compañía se han atrevido a agarrar el toro por los cuernos.

Ideas para superar el famoso "impedance mismatch" existen desde que se inventó la palabreja de marras. Suelen parecer ideas sencillas y, por lo mismo, geniales... pero hasta ahora, el monstruo que pretenden matar goza de buena salud. Es muy probable, diría que casi seguro, que esta vez sea la definitiva. Pero le aconsejo que no contenga la respiración hasta entonces...

Docking

2007-03-27T15:44:00.000+02:00

... sí, estoy con el curso de ADO.NET. Uno de los problemas que tenía con la serie D, sobre todo, era la dependencia de componentes de terceros para lograr una aplicación final "presentable". Oh, sí, lo importante es el interior, bla, bla... pero lo cierto es que ver una aplicación con los componentes de .NET v1.1 a secas es bastante descorazonador.

Y no sólo eso: buena parte del contenido de la serie D está relacionado con el gestor de ventanas. ADO.NET es relativamente sencillo, pero puede resultar laborioso, especialmente para coordinar navegación y actualización... si usas conjuntos de datos, claro, porque si no, da aún más trabajo. En concreto, lo que me preocupaba era precisamente el sistema de ventanas, que era bastante primitivo. Ahora mismo, la moda son las ventanas flotantes, esas otras ventanas escurridizas, los paneles de tareas, etc, etc. Tenía dos alternativas: serie D sin pitos ni flautas, otra vez, o serie D con componentes de terceros. Otra vez.

Como el mundo no es en blanco y negro, me he decidido por una tercera posibilidad: echar mano de alguna suite gratuita para el manejo de ventanas. Y la que he elegido, si no surge algún impedimento gordo, es la de Weifen Luo. Estos componentes imitan el comportamiento de las ventanas de VS2005, son fáciles de usar, y son los que utilizan en SharpDevelop para el "ventaneo".

Eso sí: es muy probable que "congele" una versión estable, en vez de buscar siempre la última. Además, aunque los componentes son muy estables, el código fuente no es exactamente el tipo de código que prefiero. Aunque muy estructurado, "todos hablan con todos": la comunicación entre módulos se produce a través de clases, y hay montones de declaraciones internal dentro de cada clase. Es muy difícil detectar todas las dependencias y todos los canales de comunicación. Además, el autor ha usado tipos anidados y herencia... con ancestros y descendientes anidados en tipos no relacionados, con lo cuál complica mucho más entender qué demonios hace el código fuente.

Para rejillas y menúes, por supuesto, voy a usar los propios de VS2005, que funcionan muy bien. Respecto a los paneles de tareas (los famosos task panels), creo que puedo vivir sin ellos. De todos modos, he visto un par de componentes gratuitos por ahí, y en el peor de los casos, no es complicado escribir uno propio (en IntSight Controls hay un grupo de componente de ese tipo, para Windows nativo, y dibujando todo a mano).

Time break

2007-03-19T20:56:00.000+01:00

Llevo un par de días en reposo por enfermedad. Nada grave (ni siquiera contagioso, sniff), pero me han mandado al banquillo. A ver si ya puedo retomar todos los asuntos pendientes esta semana...

La importancia de llamarse Bertrand

2007-03-12T15:35:00.000+01:00

Para quienes todavía creen que hay algo oscuro, siniestro e inconfesable tras mi recomendación de .NET, he reencontrado este artículo en Internet:

The Significance of .NET

Espero que esos pocos conozcan quién es Bertrand Meyer.

Intermezzo técnico

2007-03-05T19:25:00.000+01:00

¿Me permite un pequeño descanso antes de continuar con la serie sobre ideologías? En el último post sobre Freya, en los comentarios, Daniel Alvarez me señalaba unos artículos en Internet sobre integración con Visual Studio, en la Bitwise Magazine inglesa. Me llamó la atención, merodeando por dicha página, el siguiente artículo:

The Great OOP Debate (Bitwise Magazine)

Cuidado, no estoy diciendo que esté de acuerdo con todo lo que se dice en el artículo. En realidad, creo que las opiniones de Huw y Dermot son muy diferentes, y en ocasiones incluso hablan de cosas muy diferentes sin darse cuenta.

Lo que quiero destacar es la importancia que Dermot concede al uso de interfaces... aunque en su caso, se refiere concretamente a las interfaces COM. Destaco esta opinión (basada en la práctica) porque coincide con lo que he podido comprobar por cuenta propia en estos últimos años... y que difiere radicalmente de las recomendaciones de Microsoft sobre el uso de tipos de interfaz.

En concreto, me gusta plantear la funcionalidad y arquitectura de un sistema mediante un conjunto pequeño de interfaces. Luego, las clases entran en escena, pero sólo como un recurso de implementación. Por ejemplo, el compilador de Freya está basado en unas pocas interfaces como ISymbolTable, ICodeGenerator e IParser que son luego implementadas por clases que funcionan como singletons dentro de una instancia del compilador. Luego tenemos interfaces como IAstNode, IStatement e IExpression, que son implementadas luego por una larga colección de clases. Lo importante es que toda comunicación entre módulos se especifica por medio de tipos de interfaz: el canal de comunicación que abren las interfaces es mucho más estrecho que el de las clases. Y la misma situación se da en Proteus, en XSight RT...

¿Mi consejo? Lea, analice, experimente y compare. Y luego, cuando decida, cuéntenos su decisión.

Ideologías - primera parte

2007-03-05T12:07:00.000+01:00

No es lo más sorprendente de lo que me he encontrado en esta vida, pero como mínimo es curioso. Me refiero a la supuesta asociación que ven algunos entre software e ideología. Las ideologías actúan como filtros para evitar que la gente piense... y me refiero tanto a ideologías "laicas" como a ideologías relacionadas con religiones. ¿Cree usted que los humanos buscamos la verdad? No: lo que hacemos es coleccionar ideas que nos hacen sentir bien. Es cierto que las ideas verdaderas tienen el efecto secundario de hacernos sentir bien, como el "eureka" de Arquímedes. Y desechamos, por supuesto, aquellas que nos hacen sentir mal... muchas veces simplemente porque contradicen otras ideas que nos hacen sentir bien. ¿Parece una obviedad? Dígaselo a Searle, y a Noam Chomski, y a tantos otros que se ganan la vida filosofando "seriamente" sobre la mente y la voluntad, e ignoran estas trivialidades.

Hagamos una prueba. Dígame, rápido: ¿es buena medida subir el salario mínimo interprofesional?

La respuesta, en el siguiente post de esta serie.

... y sí, al final veremos qué tiene que ver todo esto con el software y la Informática. Sea paciente.

Impuestos atenuados

2007-03-01T11:01:00.000+01:00

Ya sé que está mal visto hablar de política. Pero esta mañana me he despertado y me he preguntado dónde estoy, qué hago aquí y todas esas reacciones que suelen provocar la incredulidad y la sorpresa.

En definitiva, veamos el lado positivo del asunto: ¿creéis que, si me declaro en huelga de hambre, este gobierno me perdonará los impuestos, o me impondrá unos "impuestos atenuados"? ¿O tengo que asesinar primero a veinticinco personas?

Sí, ya sé que no debo hablar sobre política, pero pensé que más que con la política, tenía que ver con la decencia... sí, esa palabra todavía sale en el diccionario.

Me han avisado que hay concentración hoy, frente al Ministerio del Interior, en el Paseo de la Castellana nº 5, a las 8 de la noche. Si me da tiempo, que creo que sí, me pasaré. Y me vais a perdonar por mi "activismo" en este tema, pero el asunto es gravísimo, y no se trata siquiera de política. Veinticinco asesinados por un terrorista. Dos chicos ecuatorianos asesinados en la Terminal 4 de Barajas hace un mes. Esto no tiene nombre. O sí...

Citas de la vida "real":

"No es nuestro miedo ni nuestra debilidad lo que le ha salvado, es nuestro valor de luchar por lo que creemos, que es la vida". (ZP)

Fragmento de "1984", la famosa novela de Orwell:

His mind slid away into the labyrinthine world of doublethink. To know and not to know, to be conscious of complete truthfulness while telling carefully-constructed lies, to hold simultaneously two opinions which cancelled out, knowing them to be contradictory and believing in both of them; to use logic against logic, to repudiate morality while laying claim to it, to believe that democracy was impossible and that the Party was the guardian of democracy; to forget whatever it was necessary to forget, then to draw it back at the moment when it was needed, and then promptly to forget it again: and above all, to apply the same process to the process itself. That was the ultimate subtlety: consciously to induce unconsciousness, and then, once again, to become unconscious of the art of hypnosis you had just performed. Even to understand the word 'doublethink' involved using doublethink.

La debilidad es fuerza, la ignorancia es sabiduría, la cobardía es valor, la esclavitud es libertad. Bienaventurados estos pobres de espíritu. Nunca ha estado tan claro: quien te promete un futuro, es porque te está robando el presente.

for var f in foes do

2007-02-28T19:53:00.000+01:00

No está mal para el típico splash del IDE de pruebas, ¿o no?

Es verdad que la chica tiene cara de enfado. Da la impresión de estar pensando algo así como: "al próximo que me pregunte si Marteens cobra de Microsoft por recomendar .NET le rebano la cabeza"...

He hecho el dibujo aprovechando el paso del IDE de pruebas para Freya, de su primera versión SDI (Hammer, es decir, martillo) a la nueva versión MDI/tabbed pages. Había que darle un nombre, sobre todo para los proyectos no se llamen freya01, freya02 y así hasta el aburrimiento, y ya que teníamos anvil (el yunque), para el editor de código, y el ya mencionado hammer, lo lógico era usar otro artilugio relacionado con los herreros. Nombre elegido: Sharp Blade, es decir, hoja o espada afilada. No está mal... Ya sé que CodeGear nunca reconocerá que mi compilador es mejor que el de ellos, pero al menos podrían contratarme para decidir los nombres de proyectos. Mira que usar nombres de culebras, coño...

... y sí, ya sé que el dibujo tiene fallos: no pienso dedicarme a estas alturas de la vida a las artes gráficas. De todos modos, me sorprende precisamente por eso: de repente "vi" la imagen mentalmente, me senté con mi Xara Xtreme Pro una hora, aproximadamente, y hala, dibujo casi terminado. La chica está dibujada "de memoria", y se parece mucho a una amiga que hace tiempo no veo. El pelo necesita más detalles, y también el labio superior. Ya lo arreglaré cuando vuelva a tener una hora de libertad.

Recuerde: Sharp Blade...

La Cara Oculta de C++... en portugués

2007-02-27T16:00:00.000+01:00

Hay sorpresas y sorpresas, y ésta es de las agradables: Thérbio, un programador de Brasil, ha contactado conmigo para obtener el permiso y traducir al portugués mi libro sobre La Cara Oculta de C++ Builder 4. Por supuesto que he accedido: más bien considero un honor que el libro siga despertando interés, y he puesto todo lo necesario para facilitar la tarea.

El proyecto se coordina desde este foro:

DicasBCB

Como se trata de un libro de 1998/99, voy a proponerles también añadir parte del material sobre el API de Windows que he incluido en Intuitive Delphi: objetos del núcleo, manejos de hilos, etc... aunque primero tendré que traducir el código y los ejemplos de Delphi a C++ Builder. Por supuesto, cualquier adición a la versión en portugués se reflejará en la versión en castellano.

Renovación de la suscripción MSDN

2007-02-23T12:57:00.000+01:00

Me tocaba renovar este mes la suscripción anual a la MSDN, y ya lo he hecho. Me suscribí el año pasado a Visual Studio Profesional, con MSDN Profesional. No es ni remotamente la opción más cara... pero trae todo lo que necesito (por eso lo cuento aquí). El servicio de Microsoft, además, es bueno: todos los meses, religiosamente, llega un mensajero a IntSight con un mogollón de CD's y DVD's de los que, para serle sincero, sólo llego a ver luego uno o dos.

Información que le puede interesar: la compra original me costó alrededor de 1.100 o 1.200 euros. La renovación cuesta unos 800 euros. Es mucho más barato que la cantidad que gastaba anualmente en licencias de Delphi, y lo que obtengo es un producto mucho más completo: incluye toda la suite de lenguajes: Visual C++, C#, VB.NET y JScript, aparte de todo tipo de versiones de desarrollo de SQL Server. De todos modos, le advierto que existe una versión más barata: comprar solamente Visual Studio, sin la suscripción MSDN. Los precios de primer compra están en la zona de los 800 euros, y las actualizaciones salen por unos 500 euros (cito de memoria y muy aproximadamente). De todos modos, si se puede dar el pequeño "lujo" de comprar la Team Server Edition, no se prive. Lo que echo más en falta de mi vesión Profesional es el profiler que viene en las versiones superiores. Pero por suerte, .NET ofrece un API para profilers, y según los artículos que he consultdo, sería relativamente sencillo programar uno si fuese necesario.

Otro dato que le puede interesar: la renovación, al menos, se puede tramitar directamente con Microsoft España, si se quiere pagar con tarjeta. La mayoría de los distribuidores te ponen pegas si quieres pagar por esta vía, pero existe la posibilidad de comprar directamente con un comercial de Microsoft, por teléfono... que fue lo que hice.

Necesito ayuda

2007-02-15T13:51:00.000+01:00

¿Tiene instalado un Delphi.NET? Necesito que me eche una mano; no importa la versión, siempre que sea para .NET. Estoy retocando el diseño de los destructores en Freya, pero no le veo mucho sentido a la idea. Se supone que, con la ayuda de un destructor, se facilitaría la implementación de la interfaz IDisposable.

El problema está en que el patrón de implementación propuesto por Microsoft funciona a través de un método Dispose auxiliar, declarado virtual y protegido, y con un parámetro de entrada de tipo booleano. Esto sirve para distinguir entre las llamadas "explícitas" a Dispose (como las realizadas a través de una instrucción using) de las llamadas automáticas provocadas por el colector de basura. Si no se incluye esta distinción, el destructor pierde la mayor parte de su atractivo, y puede confundir más que ayudar.

¿Qué necesito, en concreto? Si tiene alguna versión de Delphi.NET (la 8, la 2005 o la 2006), me gustaría poder echarle un vistazo a un ensamblado pequeño compilado, preferiblemente como DLL. No me atrevo a escribir código fuente, porque no tengo forma de verificarlo sintácticamente, pero sólo necesito que incluya dos clases: una clase base y una clase derivada de la primera. Cada una de estas dos clases debe tener un destructor. Lo que haga el destructor no tiene importancia: un WriteLine a la consola, por ejemplo. Eso sí, que contengan al menos una instrucción, para que el compilador no haga cosas raras con el destructor.

O, por el contrario, si tiene claro cómo genera Delphi código para destructores en .NET, o ha escrito algún artículo, o conoce dónde hay uno, también me valdría. En este momento no tengo ningún Delphi.NET instalado: sólo mi viejo Delphi 7 "nativo".

... y muchas gracias por adelantado.

Actualización: Javier Bleda me ha dado la URL del blog de Hallvard Vassbotn, y ahí me he encontrado con el enlace a un viejo artículo de Brian Long, donde cuenta los detalles de la técnica.

A primera vista, es así como lo tengo ya implementado en Freya... pero no me convence la idea, para ser sincero: el trabajo que ahorra al programador no es significativo, y complica bastante la clase, al exigir la implementación de un tipo de interfaz, y por la necesidad de mantener el patrón en los descendientes potenciales de la clase. En el patrón oficial propuesto por Microsoft, además, se distingue entre recursos administrados y no administrados, y eso es (a primera vista) casi imposible de automatizar, excepto en circunstancias muy especiales y controladas. De todos modos, voy a pensármelo un poco antes de tomar una decisión.

Peephole optimization

2007-02-15T09:31:00.000+01:00

La imagen pertenece al diálogo de información sobre la compilación de Hammer, el entorno de pruebas para Freya. Como puede ver, he implementado un peephole optimizer. Esto es: un optimizador que trabaja sobre el código final generado, que en este caso, es el código intermedio de .NET. El optimizador analiza la cadena de códigos ejecutables, en pequeños fragmentos, y aplica ciertas reglas de reescritura preprogramadas. Por ejemplo, un branch to return es un salto incondicional que va a parar a un retorno de método. Estos saltos se eliminan, sustituyéndolos directamente por un retorno de método: así se ahorra espacio, y el tiempo que consumiría el salto.

Para ser justos, el compilador normalmente genera código de buena calidad, de modo que este paso de optimización no produce cambios espectaculares. Además, el código IL no permite muchas transformaciones, al tratarse de la simulación de una máquina de pila. En una máquina de pila, cada operación es, en cierto sentido, insensible a las operaciones que la siguen o preceden; sólo importa el contenido de la pila. De todos modos, ya he detectado unas cuantas oportunidades de mejorar el código en esta parte de la compilación.

En cualquier caso, este módulo era necesario: el generador de código IL que ofrece Reflection.Emit no es gran cosa, pues obliga a indicar explícitamente el tamaño de los códigos de saltos. Si un salto en IL se produce a una instrucción que queda a menos de 127 bytes, se puede usar un código de salto especial para que la instrucción, incluyendo el desplazamiento del salto, quepa en dos bytes. En caso contrario, ocuparía cinco bytes. El generador predefinido no ayuda para nada en la decisión del tamaño del salto. El módulo de optimización de Freya es el encargado de tomar estas decisiones, de manera automática.

Iteración en Freya

2007-02-10T02:40:00.000+01:00

¡Ya funcionan los iteradores en Freya! Había postergado la "conexión" del módulo correspondiente, pensando que iba a resultar más complicado, pero al final ha sido muy sencillo.

iterator Stack: X;
begin
    for var i := Count - 1 downto 0 do
        yield Items[i];
end;

El truco principal consiste en recorrer el cuerpo del método iterador buscando parámetros y variables locales. Para cada uno de ellos, se crea un campo para la clase que genera el compilador internamente, y las referencias a variables y parámetros se sustituyen por referencias a los campos correspondientes. Hay que tener cuidado, porque las referencias a campos necesitan empujar antes dentro de la pila la referencia a la instancia de la clase. Un detalle elegante: las referencias a campos de la clase donde se define el iterador son muy fáciles de traducir, porque la referencia a Self se considera también un parámetro del iterador, y como tal, se duplica en la clase enumerable generada por el compilador.

Por supuesto, quedan algunos pequeños detalles por resolver. Por ejemplo, hay que tener cuidado con los iteradores estáticos, como los que se definirían en una sección de implementación anónima, y hay que mejorar los mensajes de error del compilador cuando se escribe una instrucción yield en zonas prohibidas, como la sección finally de un try/finally.

¿Qué tal un ejemplo más complejo? Este es un iterador para recorrer en preorden los nodos de un árbol binario:

iterator PreOrder: Y;
var
    St: Stack[TreeNode];
begin
    if Root <> nil then
    begin
        St := new Stack[TreeNode];
        St.Push(Root);
        repeat
            var t := St.Pop;
            if t.Left <> nil then
                St.Push(t.Left);
            if t.Right <> nil then
                St.Push(t.Right);
            yield t.Value;
        until St.Count = 0;
    end;
end;

Es interesante ver cómo se traduce el código anterior, según Reflector. El compilador crea una clase privada y anidada dentro del árbol, que implementa la interfaz IEnumerable. Así es como Reflector traduce a C# el código IL generado por el compilador para el método MoveNext:

public sealed override bool MoveNext()
{
    switch (this.state$)
    {
        case 0:
            if (this.Self.Root == null)
                goto Label_00D1;
            this.St = new Stack<BinaryTree<Y>
              .TreeNode>();
            this.St.Push(this.Self.Root);
            break;
        case 1:
            this.state$ = -1;
            if (this.St.Count != 0)
                break;
            goto Label_00D1;
        default:
            goto Label_00D1;
    }
    this.t = this.St.Pop();
    if (this.t.Left != null)
        this.St.Push(this.t.Left);
    if (this.t.Right != null)
        this.St.Push(this.t.Right);
    this.current$ = this.t.Value;
    this.state$ = 1;
    return true;
Label_00D1:
    this.state$ = -2;
    return false;
}

Parece más complejo de lo que realmente es... cuando se intenta traducir del formato IL a un lenguaje estructurado.

El programa más largo

2007-02-08T22:22:00.000+01:00

¿Qué es esto? ¿Más noticias sobre ray tracing? Sí, pero sólo en parte. Es, efectivamente, una imagen producida por un programa de ray tracing, pero el programa ¡está escrito íntegramente en Freya!

Lo que he hecho es traducir el núcleo básico de XSight RT a Freya, buscando errores del compilador, construcciones incómodas para el programador, traducciones ineficientes, y más cosas de este estilo. Los programas que estaba usando como pruebas del compilador no pasaban de dos o tres páginas, y quería probar con un ejemplo más ajustado a la realidad.

En realidad, el programa está empaquetado en sólo 1120 líneas de código, que he agrupado por conveniencia en un único fichero fuente. Puede examinar el fichero siguiendo este enlace:

Ray tracer escrito en Freya

En la vida real, el código estaría distribuido entre varios ficheros, pero como Hammer maneja de momento sólo un documento por vez, mezclé los ficheros para simplificar la compilación. Cuando Freya esté terminado, utilizará un sistema de proyectos y soluciones muy parecido al de Visual Studio, adicional a las actuales posibilidades del compilador.

¿Qué contiene la prueba, y qué no contiene? La demo puede trabajar con esferas, cilindros y uniones. No he incluído soporte para operaciones de intersección y diferencia, y los materiales son, básicamente, plástico y metal. Claro, el modelo básico ya estaba suficientemente probado con C#, y todo este jaleo me ha llevado menos de un día para escribirlo, probarlo y darle forma definitiva.

¿Y qué tal de velocidad? Primero, una aclaración: la velocidad de XSight RT es similar a la de un ray tracer "nativo", gracias a todo tipo de optimizaciones y a un cuidadoso diseño. En el código de ejemplo en Freya he preferido utilizar construcciones del lenguaje más elegantes que eficientes. Por ejemplo, XSight RT prácticamente renuncia al uso de operadores definidos por el programador, mientras que el ejemplo los utiliza sin reparos. A pesar de ello, los tiempos de ejecución son comparables: un ejemplo que tarda de 80 a 90 milisegundos en XSight RT se genera en Freya en un tiempo que va de 110 a 120 milisegundos.

... aunque también es cierto que el compilador de Freya está especialmente preparado para que genere mejor código que el propio compilador de C#. Ya hablaremos de optimización, en su momento...

Otra libra de carne

2007-01-10T13:30:00.000+01:00

... un momento, ¡esto suena a rock!
Reverendo Lovejoy

Las SS españolas, es decir, las seguridades sociales, que aunque son una, merecen el plural mayestático, son una fuente inagotable de sorpresa y regocijo... para quien sepa tomarse estas cosas con filosofía.

Esta vez, mis azares y aventuras me han conducido a las oficinas de las SS para solicitar una "vida laboral". Esto es, una especie de certificado de buena conducta que, a pesar de encontrarnos en pleno siglo XXI, ese monstruo llamado Estado es incapaz de transmitir vía electrónica entre dos de sus ministerios (alegrémonos de ello). De modo que me he personado en el antro que corresponde a mi quartier a las 12:00 del mediodía... y me encontrado a los funcionarios con los brazos cruzados, charlando amigablemente entre ellos. ¿Una vida laboral, majete? De lunes a jueves, pero solamente entre las nueve y las once de la mañana, que es la hora en la que Saturno cruza por las antífonas del ascendente menor disminuido de Júpiter Olímpico. ¡Por el amor de Baco! ¡Santa Madre de Dionisos!

Como soy un individuo que, muy en el fondo, aún conservo algo de fe en la especie humana, cuando consiga el dichoso certificado de sangre que me acredite como cristiano viejo, les diré que me siento como Jean Valjean. Espero que esta vez sepan quién es Jean Valjean, la pequeña Cossette y el inspector Javert. ¡Tantas veces que la han pasado por la tele!

Koan de los dos hermanos

2007-01-05T17:53:00.000+01:00

Si en el Universo sólo existiesen dos hermanos, ¿cuáles serían sus nombres?

Inicializadores de colecciones

2007-01-05T13:57:00.000+01:00

Junto con los inicializadores de objetos, C# 3.0 introduce inicializadores de colecciones, para simplificar la inicialización de objetos cuyas clases implementen la interfaz genérica ICollection<T>.

Suponga que estamos trabajando con C# 2.0, y que queremos crear una lista genérica de enteros y añadirle unos cuantos elementos iniciales:

List<int> lista =
    new List<int>(new int[] { 1, 2, 3, 4 });

El ejemplo anterior utiliza uno de los constructores de la clase List, que recibe un parámetro de tipo IEnumerable, en su versión genérica. El CLR considera que todo vector implementa dicha interfaz, por lo que el compilador genera instrucciones para crear el vector para luego pasarlo al constructor de List.

¿Se da cuenta de lo ineficiente que es esta técnica? Observe el código aproximado que debe generar el compilador, con sintaxis C# para no hacerlo ilegible:

int[] temp = new int[4];
temp[0] = 1;
temp[1] = 2;
temp[2] = 3;
temp[3] = 4;
List<int> lista = new List<int>(temp);

Pero esto es sólo lo que ocurre a la vista de todos. Recuerde que el parámetro recibido por el constructor es una interfaz IEnumerable. El constructor debe ejecutar el método GetEnumerator de la referencia recibida, y llamar al método MoveNext repetidas veces sobre el resultado de la llamada.

Bienvenidos a C# 3.0. Ahora podemos usar esta sintaxis:

List<int> lista =
    new List<int>(){ 1, 2, 3, 4 };

Los cambios son sutiles, pero importantes. Ahora utilizamos el constructor sin parámetros de List, aunque tenemos la libertad de usar el constructor que mejor nos parezca, pues la lista de elementos iniciales no se pasa como parámetro del constructor. Por el contrario, la lista se yuxtapone tras el paréntesis de cierre de la lista de parámetros. Aunque parece un vector literal, no lo es: no hay indicación del tipo de los elementos... porque exigiremos que sean compatibles con el tipo de elemento de la lista. La traducción es la siguiente:

List<int> lista = new List<int>(temp);
lista.Add(1);
lista.Add(2);
lista.Add(3);
lista.Add(4);

Ya no tenemos que crear e inicializar un vector de usar y tirar. Ya no hay un bucle dentro del constructor. Ya no se crea una instancia temporal de IEnumerator para el bucle del constructor. De manera que no sólo ahorramos tiempo, de manera directa, sino que también ahorramos memoria, y aliviamos la carga del garbage collector.

Sólo nos queda un detalle por aclarar. Las llamadas al método Add tienen en realidad este aspecto:

((ICollection<int>)lista).Add(1);

Pero esto no significa una carga adicional, porque la conversión anterior no genera código adicional... al menos en lenguaje intermedio. Tengo que comprobar todavía lo que ocurre cuando se traduce a código nativo.

Como imaginará, cuento todo esto porque acabo de añadir a Freya estos inicializadores de colecciones. Eso sí, la sintaxis provisional es "fea":

List[Integer] := new List[Integer]![1,2,3,4];

No podemos yuxtaponer sin más el inicializador a la expresión new, porque Freya permite omitir los paréntesis cuando no hay parámetros, y porque usamos los corchetes para los parámetros de tipos genéricos. No podemos usar ninguno de los operadores permitidos en expresiones, porque introduciríamos ambigüedad en el lenguaje. He probado el uso de la asignación de Pascal, y aunque no causa problemas, el efecto estético es horroroso. Me he quedado con el signo de admiración porque me ha parecido el menor de los males.

A Pound of Flesh

2007-01-03T14:09:00.000+01:00

Acabo de poner en práctica un experimento que me ha revelado un hecho sorprendente: ¡en la Seguridad Social (SS en lo sucesivo) no conocen a Shakespeare! No es que no sepan qué es El Mercader de Venecia, desgraciada obra antisemita que desmerece el genio del Bardo de Avon, o incluso que no conozcan a Jeremy Irons y Al Pacino: el propio Shakespeare les suena a nombre de inmigrante chino.

Y no se trata de un experimento efectuado sobre un único y pobre desgraciado elegido al azar por un experimentador chiflado que se cree Dios: le he dicho a la funcionaria que me atendió que quería pagar mi libra de carne y cuando, tras torcer el gesto y regañarme, ha confesado desconocer de qué iba la historia, me he tomado el atrevimiento (y la molestia) de ir buró por buró (sitio donde se enquistan los burócratas de la SS española) preguntando a sus nueve compañeros si tenían alguna idea de lo que significaba una libra de carne. Unánime negativa. Incluso he preguntado si lo negaban por fastidiarme. Desconcierto y sorpresa.

Lo peor de todo, o lo mejor, según como se mire, es lo que me ocurrió al despedirme: la personita, ofendida en lo más profundo de su alma logseana, me espetó:

- ¡Nadie que venga con una Biblia en la mano tiene derecho a echarme un sermón!

Abrí los ojos como platos, hasta que comprendí a qué se refería. Entonces levante la mano con la que sostenía el libro, y le enseñé la portada de mi ejemplar encuadernado en piel de las "Lectures on Quantum Mechanics", de Paul Adrien Maurice Dirac, que yo, ateo budista, había llevado para aliviar mi espera en la larga cola de suplicantes.

Post scriptum: El incidente, en sí, es más grotesco que terrible. Tampoco pretendo que se obligue a leer a Shakespeare en la escuela pública, ni a Dirac, ni siquiera la Biblia. Lo terrible es que gente así se atribuya constantemente el poder de decidir por todos nosotros.

¡Feliz Navidad!

2006-12-23T13:13:00.000+01:00

... para ser sincero, no soy muy fan de las Navidades. Pero ahora que es políticamente incorrecto hablar de Navidades en según qué ministerios, sería una pena desaprovechar una oportunidad para dar un poco por saco.

Lo dicho: Feliz Navidad, Bon Nadal, Zorionak, Merry Christmas, Joyeux Noël, etc, etc, y aunque un poco tarde, feliz Hanukkah.

(he pasado del Kwanza, como podéis ver...)

Métodos anónimos

2006-12-21T16:37:00.000+01:00

Voy a ocuparme un poco del compilador de Freya, ahora que baja la carga de trabajo por fin de año. Quiero terminar de implementar el soporte de métodos genéricos, introducir la inferencia de tipos para argumentos genéricos en llamadas a métodos genéricos, y probablemente de los primeros pasos para implementar métodos anónimos.

Con estos últimos, voy a saltarme una versión, y los voy a implementar desde el principio como las expresiones lambda de C# 3.0:

var L: List[Integer] := [1, 2, 3, 4];
if L.Exists(x => x mod 2 = 0) then
    Console.WriteLine('Pares en la lista');

La sintaxis del ejemplo (la porción resaltada en rojo) es la del caso más simple: un método anónimo que devuelve un valor calculado con una expresión, que recibe un solo parámetro, y que el tipo de dicho es parámetro es inferible a partir del contexto.

El problema consiste en qué hacer en el caso más general: en C#, gracias a su sintaxis espartana, la versión completa de un método anónimo es aceptable. En un lenguaje pascaloide (o "algoloide"), es otra cosa. Esto sería una expresión en C#:

delegate(int x) { return x % 2 == 0; }

Y esto sería el equivalente literal en Freya:

method(x: integer) begin result := x mod 2 = 0 end

Si no ve dónde está el problema, recuerde que estas "expresiones" pueden usarse ahora como parámetros en llamadas a métodos.

En realidad, hay otro problema por el que le estoy dando tantas vueltas a la sintaxis. Me gustaría poder plasmar la idea de método anónimo = extensión de estructuras de control. Las listas genéricas en .NET tienen un método ForEach, un iterador cerrado, que acepta un parámetro de tipo delegado:

lista.ForEach(x => Console.WriteLine(x));

En este caso, C# ha considerado que la llamada a WriteLine se puede considerar, en el sentido más laxo, una función que no devuelve nada. Por lo tanto, permite eliminar las llaves que de otro modo deberían encerrar el bloque de instrucciones.

A mí me gustaría que Freya pudiera hacer esto (olvide por un momento el uso incorrecto de las palabras reservadas):

with x apply lista.ForEach do Console.WriteLine(x);

Esto es: me gustaría disponer de una instrucción de control "comodín" que pudiese simplificar el uso de métodos anónimos como parámetros de métodos... siempre que se cumpliesen algunas condiciones, como que el método sólo admitiese un parámetro de tipo delegado. Claro: esto no tendría sentido con una llamada al método Exists que mostré en el primer ejemplo, pues este método debe devolver un valor.

¿Tendría sentido una instrucción como la que imagino? ¿Tendría aplicación más allá de su evidente utilidad con iteradores cerrados? Teniendo en cuenta que ya Freya cuenta con un mecanismo útil y eficiente de iteradores abiertos, si sólo valiese para iteradores cerrados, no creo que mereciese la pena: es incluso probable que fuese mejor adaptar la sintaxis del foreach de C# para estos casos. Por último, ¿podría utilizarse una instrucción de este tipo para simplificar la conexión de manejadores anónimos a eventos? Esto es C# 2.0:

button1.Click += delegate { Console.WriteLine("Click"); };

¿No sería preferible algo así en Freya?

when button1.Click do Console.WriteLine('Click');

¡Ojo! No estoy convencido de que sea buena idea: sólo pregunto. No me gustaría añadir dos instrucciones diferentes para estos dos casos... pero tampoco estoy seguro de poder unificarlos.