El microformato hCalendar incrusta fechas y eventos basados en iCalendar. La BBC usaba además el patrón de diseño sobre el tag ABBR, para incluir información relevante para parsear automáticamente alrededor de información para humanos. Por ejemplo:

<p>Mi cumpleaños es el <abbr class="dtstart" title="20090814">14 de Agosto</abbr></p>

Lo anterior es un ejemplo de microformato hCalendar incrustado en un ABBR tal como usaba la BBC.

¿Por qué es malo esto y por eso dejó de usarlo la BBC?

Pues básicamente, y sorprendentemente, por cuestiones de usabilidad.

Resulta que los microformatos, al usar el atributo “title” para almacenar los metadatos, expone visiblemente los mismos al usuario como efecto secundario. El atributo “title” en algunos elementos es visible al pasar el ratón por encima en forma de “tooltip”. Por ejemplo en los enlaces <a title="Título visible">, etc. Además, resulta que los programas que leen la pantalla para personas discapacitadas como ciegos, etc, LEEN el contenido del tag title, con lo cual una persona que use un lector de pantalla a voz y pase por el ejemplo anterior diría “Mi cumpleaños es el veinte millones noventa mil ochocientos catorce catorce de agosto”.

El artículo de A List Apart es especialmente interesante porque cuestiona en cierta forma a HTML 5. Usa el caso de la BBC para exponer sus argumentos, que son los siguientes:

Semántica estricta en HTML 5

HTML 5 marca un hito en los estandares de la red, entre otros por añadir una semántica más estricta en los elementos. Aparecen tags del tipo section, nav, etc, que se pueden usar en lugar de div para añadir semántica al contenido. El artículo cuestiona dos aspectos con gran convicción:

• La compatibilidad con navegadores antiguos.
• La futura expansión semántica del lenguaje.

Es decir, se cuestiona el antes y el después de HTML 5. El problema con los navegadores antiguos es grave, aunque se limita a los navegadores de Microsoft éstos representan un amplio porcentaje de los clientes existentes.

Por ejemplo, Internet Explorer (en cualquier versión) no soporta los estilos sobre los nuevos elementos. Por ejemplo:

<style type="text/css">
    section { color: red; }
</style>
<section>
    <h1>Esto es la sección principal.</h1>
</section>

La cabecera anterior no saldrá en rojo en Internet Explorer, ya que no aplica los estilos a los elementos que no conoce. Ya hay una solución en JavaScript para esto, como no, pero evidentemente es un gran problema ¿cómo puede un estandard moderno introducir nuevos “hacks”? ¿No tenemos bastante con los hacks existentes para CSS en Explorer?

El otro punto de interés es la futura ampliación de la semántica. El autor se basa en que los elementos existentes no son suficientes para dar intención semántica en general, y el lenguaje no permite ampliar dichos elementos. Por ejemplo, HTML 5 introduce elementos como <section>, <header>, <aside>, <figure>, que amplían las posibilidades semánticas, pero el artículo se cuestiona con razón que quizá son pocos elementos y la amplitud que abarca esta apertura semántica es insuficiente.

Como ejemplo, el mismo autor plantea una posibilidad que sería ampliar la semántica del lenguaje en lugar de mediante los tags, por los atributos de éstos. Por ejemplo, mediante <ul navigation="main"> o algo por el estilo.

Os recomiento otros posts del mismo autor para saber más.

Si eres un usuario de ordenadores Mac no te preocupes, no estoy criticando el sistema. Esta petición es muy seria. Lo que pasa es lo siguiente: la forma de actuar de las teclas de edición como “Página Arriba” / “Página Abajo”, y sobre todo las teclas “Inicio” / “Fin” es completamente diferente.

Vereis, llevo más de 20 años usando un teclado de PC. Desde el comienzo de los tiempos, la tecla “Home” siempre ha llevado el cursor al principio de la línea, al igual que la tecla “End” ha llevado el cursor al final de la línea. El proceso es muy sencillo, y funciona de maravilla. No se a quién se le ocurrió que pulsando “Home” se tenga que ir al principio del DOCUMENTO, no de la línea actual ni siquiera de la página. Ahora mismo estoy editando este post en el WordPress y me veo a mi mismo una y otra vez usando el ratón para volver la página a donde estaba porque pulso mecánicamente “Home” queriendo volver al principio de la línea.

Lo que me gustaría, y desde aquí pido humildemente a algún usuario de Mac una solución, es que hubiera alguna opción, algo que pudiera cambiar para hacer que el comportamiento de las teclas de edición funcionase como en PC, pero para todo el sistema. Osea, no valen soluciones temporales para un programa como por ejemplo: “En TextMate entra en tal sitio y configura las teclas”. No. Tiene que ser “System Wide”, para todos los programas.

Editado: Bueno, después de leer esta entrada meses después, tengo que deciros que uso habitualmente casi el 100% del tiempo un ordenador Mac. Desde el trabajo hasta casa (me compré un MacBook Pro). La edición de texto en mac la he solucionado con un programa que se llama “Key Fixer”, o algo parecido. Si teneis interés, dejadme un comentario en el blog y publico la dirección donde podeis conseguirlo. (Es que si no, no me dejais ningún comentario, que sois unos perezosos)

Estaba dándole vueltas hoy a una técnica de optimización que se usa mucho en C++ llamada COW (Copy-on-write), o como la llama QT “Implicitly Shared Classes“. La esencia de esta técnica es que basándose en que una asignación de un objeto complejo ocupa tanto recursos de memoria como CPU, utiliza en lo posible copias compartidas (shared) en memoria y sólo se duplica la memoria del objeto cuando una instancia en concreto va a cambiar (va a escribirse en ella). Esta técnica no es propiedad exclusiva de C++, se usa tanto en memoria virtual de los sistemas operativos como en implementaciones de sistemas de ficheros (Ej. Ext3). En C++ los ejemplos clásicos son la clase “string” de la STL o los objetos de Qt. Se puede implementar fácilmente un objeto COW con un smart pointer, como la clase “auto_ptr” de la STL.

Toda esta discusión viene porque un smart pointer, como un “auto_ptr” es la forma que tiene C++ de atar, de encapsular el uso de la memoria para que, por una parte, no hayan errores con los punteros (memory leak) y por otra llevar un conteo de referencias para liberar la memoria cuando sea necesario (cuando ningún objeto “apunta” a un auto_ptr, éste libera la memoria automáticamente). Básicamente es un garbage collection, mejor bajo mi punto de vista. Con un auto_ptr sabes exactamente cuando se va a liberar la memoria: cuando el objeto pierde todas las referencias, ni antes ni después. Con un garbage collection como creo que usa C# y si no estoy equivocado también ObjectiveC, no tienes control sobre cuando se libera esa memoria. Usemos un ejemplo diferente, supongamos que el objeto que instanciamos usando un auto_ptr no es memoria, sino un recurso como un handle de fichero o un semáforo: a través de los constructores y destructores tenemos perfectamente controlado este recurso. Lo que quiero decir, y si algún “gurú” de ObjectiveC me lee por algún casual, es que me es extraño confiar en el mecanismo de [[obj alloc] init]  /  [obj dealloc]  para la construcción y destrucción de objetos.

1
2
3
4

SELECT *
    FROM tabla1 t1, tabla2 t2
    LEFT JOIN tabla3 t3 ON t3.id = t1.id
    WHERE t1.id = t2.id

Funcionaba bien hasta la versión 5.0.12 de MySQL. A partir de la versión 5.0.12, ha cambiado la precedencia de los operadores “coma” (,) y JOIN, de tal forma que se produce un error “Unknown column ‘t1.id’ in ‘on clause’”. Esto rompe de manera definitiva algunos programas, osCommerce por ejemplo.

La solución es poner paréntesis para forzar la precedencia de los operadores “coma” y JOIN, o también cambiar la coma por un INNER JOIN, de tal forma que el anterior query quedaría de la siguiente forma:

1
2
3
4

SELECT *
    FROM tabla1 t1
    INNER JOIN tabla2 t2 ON t2.id = t1.id
    LEFT JOIN tabla3 t3 ON t3.id = t1.id

O también:

1
2
3
4

SELECT *
    FROM (tabla1 t1, tabla2 t2)
    LEFT JOIN tabla3 t3 ON t3.id = t1.id
    WHERE t1.id = t2.id

Personalmente prefiero la primera, considero que es mucho más correcto ya que todas las uniones de las tablas se hacen directamente en cláusulas ON dejando el WHERE libre para las restricciones de los datos, no las uniones.

Generalmente en todo proyecto de software hay un momento en que se produce una onda de choque, antes o después, y además no importa el tamaño de éste.

El efecto onda de choque es lo siguiente: Siempre hay pequeños bugs, fallos o mejoras que vistos individualmente no contribuyen mucho al fallo del sistema. Son los típicos “ya lo haré” o “déjalo que ahora funciona así”. Lo más tipico son los “TODO:” en el código, algo que dejas para después. También puede ser algo que en determinado momento funcionaba bien pero llega un momento en que frena el desarrollo (sin llegar a pararlo, esto es importante).

En fin, imagínate todas estas cosas como “ondas” de sonido. Al igual que un avión supersónico que va generando estas ondas, a medida que acelera estas ondas cada vez están más cerca hasta que se produce la onda de choque: todas las ondas se van juntando hasta que la diferencia de presión hace que se produzca la explosión sónica.

Es decir, llega un momento en la vida útil de un proyecto de software en el que se produce esta explosión sónica y todos los pequeños bugs arrastrados hacen que no merezca la pena seguir con el desarrollo como se venía haciendo y merece más la pena empezar de nuevo, quizá con otro análisis y aprovechando el know-how del proyecto rehacerlo paar eliminar todas estas ondas.

En C++ todo es más “estático” en el sentido de que el mecanismo de construcción y destrucción forma parte del lenguaje: sabes exactamente cuando y como se llamarán a los constructores y destructores (inicializadores en terminología ObjectiveC). El puntero “this” existe siempre y es omnipresente, pero eso no parece ser el caso con ObjectiveC, en el que “self” es más manejable y voluble.

Por ejemplo, hay discusiones sobre cual es la mejor manera de inicializar un objeto, y por lo que puedo leer, tiene mucho más que ver que uses una librería (Foundation) u otra, como por ejemplo que los descendientes de NSManagedObject tengan siempre que asignar “self” mediante la llamada a [super init]. Esto también está relacionado con que se pueden instanciar clases, no sólo objetos con lo que se lía aún más la cosa…

Ya veremos si termino comprendiendo todo esto o tiro por la ventana todo lo relacionado con ObjectiveC… Keep in touch.

Ahora he vuelto a verlo por el iPhone. La verdad es que es la primera vez que me acerco en serio a la programación para OSX. No me acordaba desde mis tiempos de universidad, y de eso ha llovido un poco. Lo más que me acuerdo es que era en C y con un Classic… cuando era actual, jajaja.

Odio la programación en ObjectiveC. Puedo comprender las razones de Apple por elegir un lenguaje así en su época, pero no para mantenerlo. Es cierto que usar C/C++ para programación de entornos de usuario hay malos ejemplos, aunque se puede hacer bien, o hacer muy bien. También podía haber hecho su propio lenguaje, o ampliar uno ya existente. Ya puestos, por qué no usar directamente SmallTalk.

Dejemoslo claro, esto es una opinión personal. Si alguien lee esto que es defensor a ultranza de ObjectiveC le daré la razón. Simplemente quiero decir que no se piense que es una opinión de “Newbe”, llevo programando en entornos de usuario desde que me compré el número 1 del MSJ (Microsoft System Journal).

De hecho, lo malo no es el entorno de desarrollo, el Xcode lo considero fenomenal, un entorno de desarrollo que ya quisiera en Windows. No. Lo malo es con el lenguaje.

En cuanto a la sintaxis es lo de menos, al final te acostumbras aunque duramente por tantos años llamando a las funciones.con().parentesis(). Lo malo de la sintaxis de ObjectiveC es justamente lo lioso de leer y de entender para los no iniciados. Te [puedes [perder facilmente:@"en la" [maraña init]]]

Para mi lo peor es que es un lenguaje orientado a objetos sobre uno que no lo es, como C. Aunque en ObjectiveC++ se pueden mezclar clases de C++ con ObjectiveC, esto no arregla el problema. Esta diferencia de conceptos ha llevado a un lenguaje que no tiene constructores y destructores, no tiene sobrecarga de operadores ni polimorfismo, entre otras cosas.

Ahora que hay más movimiento en la programación ObjectiveC por el iPhone, se oyen voces de programadores contra el sistema, y se necesitan posts como este simplemente para decir cómo se tiene que construir un puto objeto en cocoa! Simplemente esto no me parece serio, y voy a dar una razón que creo de peso: no es de recibo que un lenguaje orientado a objetos, por mucho recolector de basura que tenga, sea tan propenso a equivocaciones.

El ejemplo de los constructores. En ObjectiveC no hay constructores ni destructores. Punto. Los objetos se inicializan si el programador se acuerda de hacerlo. Todo esto sin contar que toda la jerarquía de objetos que estás construyendo depende de que tu llames a [objeto init]. Me suena a tremendo WTF!. Si hablamos de destructores, la cosa se complica. Es el programador el que tiene que llamar a “dealloc” para destruir un objeto. No, espera, ¿o mejor llamar a “release”? Mmhh… Depende. Es a estas cosas a las que me refiero, el lenguaje no permite una construcción robusta de librerías. No basta con poner en negrita en rojo con fondo fosforito en la documentación: “Llama al puto release cuando quieras liberarme”, es la clase la que debería asegurarse de liberar sus recursos.

Me recuerdo ahora un post que leí en un blog, no recuerdo el nombre si no lo pondría, que venía a decir algo así con respecto a los destructores:

“En ObjectiveC no hace falta destruir un objeto, normalmente es más sencillo y mejor que el sistema operativo libere la memoria cuando sale del programa, excepto si el objeto tiene recursos ocupados como ficheros abiertos.”.

En resumiendo venía a decir algo así. Para mi mente tan Stroustruptiana, simplemente no cabe en la cabeza que algún programador (quizás yo mismo) me deje recursos sin liberar. Llamalo memoria, en tal caso viene la basura y me la recoje, pero llámalo fichero abierto, llámalo socket conectado o peor aún, llámalo semáforo activo y verás el problema.

Este es uno de los posts que iré poniendo conforme vaya descubriendo ObjectiveC, quizá los siguientes sean más compasivos, pero mientras tanto, y si vas a escribir un comentario negativo, resuelve esta cuestión:

¿Cual es la forma más correcta de inicializar un objeto?

Forma número 1:

1
2
3
4
5
6

- (id)init {
    if ((self = [super init])) {
        // inicializar el objeto.
    }
    return self;
}

Forma número 2:

1
2
3
4
5

- (id)init {
    if (![self init]) return nil;
 
    // Inicializar el objeto
}

Os dejo un fichero PDF súmamente interesante si estás iniciándote en la programación del iPhone, o en la programación en OSX en general, mediante ObjectiveC. Si es la primera vez que programas en ObjectiveC sin referencias de C/C++ igual te sirve la documentación de Apple, pero si como yo eres un die hard de C++, estarás más perdido que un pulpo en un garaje (“¿!!Donde están los putos constructores!!?”).

Descarga: From C++ to Objective-C (706Kb más o menos).

Supongo que también lo dejaré en una futura sección de descargas, si algún día me pongo. (Que haga un post al día no supone que tenga que estar programando el WordPress)…

Se me olvidaba… Los créditos están en el PDF.