Poesía binaria

Hace años tuve entre manos un gran proyecto web, en el que invertí 8 meses de mi vida y funcionó bastante bien durante un tiempo. En su desarrollo recuerdo que tuve que desarrollar cerca 50 formularios diferentes, comprobar los valores de cada uno de los campos, hacer lecturas y escrituras en base de datos con los datos obtenidos, y opcionalmente realizar alguna tarea extra una vez enviado y validado el formulario. Además, tenía que ser capaz de listar la información, modificarla y eliminarla. Por aquel entonces, aunque había partes en común y aproveché para realizar código, no lo hice de la forma más efectiva; podría haber ahorrado muchísimo trabajo.
En los últimos años, para mis proyectos web decidí fabricarme una biblioteca para hacer este tipo de tareas de forma más rápida (con menos esfuerzo, y al fin y al cabo de forma más depurada y segura). Para eso me fabriqué una biblioteca CRUD.

Es cierto que perdemos eficiencia, es más rápida por lo general una herramienta específica, que haga justo lo que se le pide en un momento dado, que una herramienta configurable y flexible (tendremos muchas más sentencias de control y a veces se ejecutarán procesos innecesarios), pero por otro lado hay que tener en cuenta que no podemos echar un mes en un proyecto que generalmente requiere unos días, y por otra parte, seguro seguro que tenemos que hacer modificaciones antes de entregarlo, y éstas no deben llevarnos otro mes más. En definitiva, nos compensa perder algo de eficiencia en favor de un tiempo de desarrollo más corto y generar un código más fácilmente mantenible.

Lo importante de un CRUD, es la posibilidad de Crear, Ver, Actualizar, Borrar (y listar información), si lo pensamos es simple, lo ideal sería tener una clase (o una función) que simplemente llamándola nos hiciera esta complicada tarea; aunque también es verdad, si lo pensamos un poco más, que podemos complicar todo esto de mil formas, y todo lo que queramos. Además, tenemos que crear una herramienta que sea lo más flexible posible para todo tipo de bases de datos y tablas, y además, sería interesante manejar los errores que puedan surgir en el proceso, para poder generar una salida acorde.

Aunque podemos encontrar bibliotecas por Internet que hacen esta tarea, yo siempre prefiero una solución DIY (Do it yourself) (Hazlo tú mismo), de esta forma, el código será 100% mío y yo controlaré el proceso por completo, además de que como materia de aprendizaje es bastante efectivo. Dejo por aquí algunas instrucciones para empezar a fabricarnos un CRUD un tanto sencillo (y que a medida que vayamos haciendo proyectos podemos ir completándolo con las necesidades que nos vayan surgiendo):

• Listar información de base de datos: Debemos tener la posibilidad de elegir los campos a listar
• Crear entrada: Debemos tener la posibilidad de introducir campos que concuerden con entradas en una base de datos, y también la posibilidad de generar datos automáticamente (fecha de introducción, identificadores únicos, etc):
  • Necesitaremos un generador de formularios y la posibilidad de elegir el mejor tipo de campo para cada campo de la tabla que vamos a modificar
  • Debemos tener la posibilidad de verificar, vía servidor (PHP) o cliente (Javascript), mejor hacerlo de las dos formas, que los datos estén bien formados (números máximos de caracteres, formato de introducción (por ejemplo, de una fecha, un teléfono, una dirección e-mail…)
  • Inserción en tabla, y muestra de la salida, para que el usuario vea si todo ha ido bien o mal. Sería conveniente también, que esto fuera una redirección, para que, si se refresca la página, no se reenvíen los formularios.
• Modificar entrada:
  • Podemos aprovechar mucho código de la creación de entrada (muestra de formulario, verificación…)
  • Debemos modificar la tabla de datos, a lo mejor actualizar fechas de modificación, logs, etc
• Eliminar entrada:
  • Idealmente, debemos presentar un diálogo tipo: “¿Está seguro?” para confirmar que no se hace por accidente, tal vez los datos no siempre interese eliminarlos, sólo hacer una marca de que no se visualicen.
• Ver información:
  • Necesitamos hacer un sistema de visualización flexible, automático y tener la posibilidad de seleccionar los campos a mostrar (los identificadores únicos, fechas internas, IDs, no le suelen interesar al usuario), por otra parte, a veces para visualizar un dato es necesario hacer varias consultas a base de datos y tenemos que estar preparados.

Pero como dije antes, esto lo podemos complicar hasta la saciedad, aumentando el número de campos que podemos introducir (por ejemplo inserción de ficheros, Javascripts para introducir la fecha de forma fácil, o inclusión de áreas de texto HTML (como TinyMCE).

En cuanto al listado podemos implementar paginación automática (para el caso de que haya muchos elementos a listar) y ordenación de los elementos por columna (tal vez por nombre, por fecha, etc)

Por otra parte, tenemos que tener muy en cuenta el diseño, éste suele ser diferente para cada página (quitando esas páginas que parece que están hechas todas con el mismo molde), así que tenemos que hacer que nuestra salida en (x)HTML sea lo más flexible posible, que nos deje introducir código adicional, cambiar las imágenes utilizadas (iconos de insertar, eliminar…)

Y como colofón, podemos implementar soporte para relaciones, puede que echemos unos días desarrollando nuestro CRUD, pero  nos va a ahorrar mucho tiempo de desarrollo si lo utilizamos en nuestros proyectos.

Hace mucho tiempo leí en anieto2k una función muy interesante para twittear sin necesidad de incluir APIs tremendas. Es decir, si en mi aplicación, sólo quiero enviar twits, ¿para qué incluir algo demasiado grande? Con una pequeña función estaría todo resuelto.

El tema es que hace poco inicié un proyecto que periódicamente envía twits y necesité echar mano de esa función. Descubrí que Twitter había cambiado un poco su forma de interactuar.

Antes, podíamos enviar por GET (en la URL) el parámetro del mensaje que íbamos a postear, aunque ahora devuelve un error extraño: 413 Request Entity Too Large, más o menos es cuando la consulta que enviamos al servidor es muy grande; aunque el error nos lo da porque no encuentra el post que queremos publicar.

Para solucionarlo, tenemos que enviarlo con el método post, de la siguiente forma:

Con esta versión modificada del script ya podemos twitear

Y para llamar a esta función:

postToTwitter(’usuario’, ‘contraseña’, ‘140 letras de lo que queremos twitear’);

Foto: Free Twitter Bird Icon Set

Es la primera entrada de mi editor de texto favorito.

Cuando pasas gran parte del día editando archivos, es muy útil que al empezar un fichero nuevo haya algo escrito, algo que siempre toca escribir a mano, unos pocos comentarios donde dices más o menos de qué va lo que hay en el fichero y poco más.

Casi todos los editores modernos disponen de esa característica y emacs no iba a ser menos, sólo que hay que instalar una extensión (se puede hacer sin necesidad de extensiones, pero hace falta programar un poco y lo que queremos es una solución rápida que nos permita seguir trabajando en lo realmente importante), después de probar dos o tres, me quedo con emacs-template, es fácil de instalar y de configurar. Sólo hay que hacer lo siguiente:

1. Descargar de la página oficial de emacs-template.
2. Descomprimir en un directorio (yo lo hice en ~/.emacs_loadpath/
3. Compilar template.el (recomendable), para ello dentro de emacs hacemos: M-x byte-compile-file y luego buscamos el archivo template.el; generaremos template.elc
4. Copiamos template.elc a ~/.emacs_loadpath/
5. Copiamos el contenido de templates a ~/.templates/ ; al descomprimir el archivo habrá un directorio templates con algunos archivos, tendremos que copiarlas al nuevo directorio.
6. Editar .emacs para cargar la extensión:

Dentro de ~/.emacs debemos escribir lo siguiente:

(add-to-list ‘load-path “~/.emacs_loadpath/”)

Para buscar en el directorio donde hemos copiado template.elc

(template-initialize)

Para cargar la extensión. A partir de este punto, cuando creemos un archivo: C-x C-f archivo.c (por ejemplo) habrá algunas líneas pre-escritas.

Las plantillas las encontramos en ~/.templates/ y aunque vienen pocas, podemos crear todas las que queramos situándolas en ese directorio. Por otra parte, tenemos la posibilidad de introducir palabras clave dentro de la plantilla que se traducirán por el valor correspondiente como por ejemplo:

• (>>>DATE<<<) : La fecha actual
• (>>>AUTHOR<<<) : Tu nombre e email
• (>>>FILE<<<) : El fichero que estamos editando
• (>>>POINT<<<) : El punto donde el usuario empezará a editar, muy útil por ejemplo para archivos HTML donde escribimos todas las cabeceras, los pies, y tenemos que situarnos en medio para empezar; aunque lo podemos extender a todos los lenguajes.
• Y muchos más. Ver documentación.

Os dejo aquí una pequeña plantilla para PHP.

Pero aún hay más, podemos definir puntos en los que movernos rápidamente para editar, tal vez campos en los que debamos introducir texto y en los que queramos entrar de forma fácil, para ello se definen puntos (>>>0<<<) al (>>>9<<<) y nos podremos ir ahí rápidamente con el comando M-x jump-to-register ( ). (C-x r j), aunque el atajo de teclado no ataja mucho y es algo complicado, yo lo he cambiado por C-a (a porque es una tecla que pilla muy cerca de Control) editando .emacs:

(global-set-key (kbd “C-a”) ‘jump-to-register)

Un detalle más, emacs no cogía bien mi nombre y dirección de correo para usar (>>>AUTHOR<<<), por lo que tuve que hacer una pequeña modificación más a .emacs:

(setq user-mail-address “Gaspar Fernández “)

De esta forma, además, puedo personalizar la dirección de correo, para que a la hora de publicar mis trabajos no me llegue demasiado spam.
Foto: hoyasmeg (Flickr)

El objetivo de la programación, además de escribir poco (ya sabemos que todos los que programamos no queremos dejarnos las manos escribiendo), es hacer nuestro código mantenible, y para eso es necesario que nuestras funciones y métodos tengan nombres descriptivos.
Es decir, podemos definir 20 funciones: a(), b(), c(),… y mientras hacemos el programa tener un mapa mental de todas ellas, y utilizarlas, pero dentro de 6 meses, cuando vayamos a hacer la versión 2.0 de nuestro programa, ¿nos acordaremos de para qué valía cada función? Seguramente no; pero siempre que hacemos un for, lo más normal es escribir: “for (i=0;….”, “for (j=0;……)”, etc, eso sí que sale automático

Podemos, por ejemplo, tener nombres descriptivos, pero tal vez sean demasiado largos y muchos de ellos empezarán por las mismas letras, lo cual podemos considerarlo improductivo.

Si habéis curioseado prototype o JQuery, veréis cómo hay una llamada que se repite: $() y ella sola, con lo corta que es, hace maravillas para obtener objetos en Javascript. Los que hayan curioseado gettext recordarán la función _(), que sirve para traducir un mensaje. Estas funciones tienen en común que no vamos a parar de llamarlas en nuestros programas, sabemos lo que hacen y necesitamos una forma corta de llamarlas, ya que si desde nuestro programa llamamos a la función gettext() unas 2000 veces, estaríamos escribiendo 12000 caracteres de más, y en Javascript, si por ejemplo queremos llamar a document.getElementById(), con $() (no es lo único que hace) unas 60 veces, estaremos escribiendo unas 1320letras de más (y en Javascript eso se traduce en más transferencia por nuestra parte).

Pero cuando vamos a hacer una aplicación, todo se utiliza más o menos a un ritmo similar, aunque encontraremos tal vez funciones de formateo que llamemos constantemente, y esas funciones podrán tener un nombre raro que puede ser un símbolo. Pero con lo caprichosos que son los lenguajes de programación, ¿qué símbolos podemos utilizar? Deben ser caracteres con los que podamos empezar una función.
Aquí van algunos ejemplos para funciones PHP:

• €();
• ¡();
• ç();
• º();
• ½();
• _(); Pertenece a gettext
• ł();
• ¶();
• ŧ();
• ←();

C sólo permite el uso de _()

En Javascript, tenemos por ejemplo los siguientes:

• $() Ojo con jquery y prototype
• _()
• º()
• ª()
• ß()
• ð()
• ŋ()
• ħ()
• ł()

Hay algunos más, pero no es plan de abusar, y no quiere decir que tenemos que usarlos, sólo que tenemos esa posibilidad; también muchos caracteres dependen de la codificación que utilicemos, por lo tanto pueden darnos ciertos problemas en el futuro (sobre todo en Javascript).

Cuando queremos representar un directorio; podemos obtenerlo de varias formas: /home/usuario/documentos en *nix o C:\Document and Settings\Usuario\Mis Documentos en Windows. Aunque lo mismo podemos representarlo /home/usuario/documentos/ y C:\Document and Settings\Usuario\Mis Documentos\ (es lo mismo, pero con una barra al final).

El problema en PHP, viene a la hora de llamar archivos de ese directorio, hay ocasiones en las que no sabemos si la variable en donde tenemos almacenado el directorio tiene barra al final o no; entonces debemos hacer alguna función que incluya la barra correspondiente si hace falta.

Estos dos primeros script los he sacado de Jonas John Code Snippets:

Para este último, tenemos que hacer antes:

Otras dos alternativas:

La última no es muy elegante, pero ahí queda. Las dos últimas son muy parecidas entre sí. Y es una función interesante para nuestra biblioteca de funciones particular.

Hace unos meses hice un post sobre la publicación en los perfiles del usuario en Facebook desde nuestras aplicaciones. Bien, desde el día de hoy (20/12/2009) han cambiado los métodos.

Llevan amenazando ya un tiempo, pero hasta ayer no les hice caso, y es que los nuevos métodos (aunque prometen unificar todo el sistema de publicaciones de Facebook, autopublicaciones en perfiles, para los amigos, metadatos y lectura desde nuestras aplicaciones (más info. aquí), tienen detalles que no a todo el mundo le gustan. Como por ejemplo las publicaciones multi línea, el uso de palabras clave {*actor*}, {*mensaje*}, {*palabraquemeacabodeinventar*} dentro de todos los campos de publicación y la limitación de los action links a 1 !!!!!!!

Lo que sí han hecho es simplificarlo todo: no tenemos que crear un template para luego utilizarlo, y el hecho de que podamos definirlo todo por código y llamarlo cuando queramos, además, no tenemos límite de publicaciones distintas, ya que como las tenemos que crear cada vez que publiquemos, podemos hacer lo que queramos (antiguamente había un límite de 100 templates por usuario, suficientes, pero a lo mejor alguien necesitaba más).

Se potencia el uso de JSON (como los arrays en Javascript), y es que si es desde Javascript desde donde llamamos a la función, lo vamos a necesitar.

Aquí incluyo un fragmento de código para una publicación (he acompañado cadenas largas y palabras clave en todas partes para ver el comportamiento de Facebook con ellas, observar qué límites tenemos y demás):

Nos aparece algo así:

En donde nos damos cuenta que:

• Sólo caption acepta la palabra clave {*actor*} y según la documentación, sólo esa palabra clave
• No se aceptan retornos de carro en description, sólo se aceptarán en name.
• Nuestra publicación puede ser un enlace (pinchando en el nombre)
• Description no acepta fbml, es texto plano, aunque resalta los enlaces

Más adelante, cuando publicamos, nos damos cuenta de que sólo se permite un action link (enlaces que acompañan a Comentar y Me gusta), en Facebook llevaban reduciendo los action links unos días para todas las publicaciones.

Aunque un detalle importante es la inclusión de las propiedades (properties), es un array que puede contener textos y enlaces que los acompañen, y se publican, he podido hacer una publicación con 12 propiedades sin problemas.

El código superior puede servir como plantilla para vuestras publicaciones.

Pero, ¿qué pasa si quiero incluir el nombre del usuario que publica en name o description? debemos recurrir a la API de Facebook, podríamos pensar que desde fbml podemos hacerlo, pero no lo permiten en estos nuevos métodos, por lo que tendremos que recurrir a un lenguaje de servidor como PHP; de la siguiente forma:

$user_id tiene que estar previamente definida y ser la id del usuario actual (para ello, sólo hay que seguir el ejemplo que te da Facebook para crear una aplicación, copiado y pegado).
El dato que queremos, es decir el nombre, lo encontraremos en $yo[0]['first_name'], por lo que, en mitad del código fbjs anterior, si nos encontramos en un archivo PHP podemos hacer lo siguiente:

Probablemente cuando hacemos nuestra aplicación para Facebook queremos personalizar el mensaje hacia el usuario; es decir, escribir estimado o estimada, ya sea hombre o mujer nuestro usuario; en lugar de estimad@ (que quedaba muy bien hace una década, pero ahora deja que desear).

Facebook, desde su plataforma nos da opciones para conseguir esa información, pero hay un problema: están localizadas (es decir, que para español devolverá masculino o femenino; en inglés, male o female y en otros idiomas ya ni os cuento. Pero hay una forma para obtener siempre la información en el mismo idioma (ejemplo en PHP):

Con esto en $userinfo tendremos la información de uid, nombre, avatar y sexo del usuario con id $user_id y si un campo permite localización (como sex), lo dará en inglés de EEUU. Podemos estar seguros de que sex tendrá como valor male o female (o ninguno, si el usuario ha puesto como privado ese dato).
Podemos ver el resultado en esta aplicación: Qué Malo es Pensar:

http://apps.facebook.com/quemaloespensar

A veces, nos es de bastante utilidad geolocalizar a un visitante, bien puede ser para mostrarle una publicidad relevante o porque prestamos un servicio que sólo existe en determinados países, para escoger automáticamente el idioma de nuestra web, o por motivos estadísticos, para saber de dónde provienen nuestras visitas, como medida en una red social para detectar automáticamente dónde estás… en fin, hay un sinfín de utilidades.

Lo más común para geolocalizar a los visitantes es verificar su dirección IP y consultar en una base de datos a qué país pertenece. Hay empresas que comercializan estas bases de datos, y las hay con mucha precisión (algunas pueden decirnos hasta la ciudad donde está conectada la persona con esa dirección IP). Aunque vengo a hablaros de un servicio gratuito: Ip to Country de Webhosting.info.

En las web citada viene mucha información de cómo utilizar la base de datos y código de ejemplo, por lo que no me extenderé mucho.

En resumen, tenemos que decargar el fichero CSV, que contiene la tabla que debemos incluir en nuestra base de datos (por ejemplo, PhpMyAdmin tiene la posibilidad de importar ficheros CSV). Seguidamente, hay que tener en cuenta que en esta tabla, la IP no está en el formato que estamos acostumbrados (4 números de 8bits separados por puntos), está en formato long, lo que es los 32bits (en PHP podemos hacer la conversión con ip2long()). Para hacer nuestro programa hemos de saber que la IP que queremos geolocalizar tiene que estar comprendida entre ip_from (primera ip que viene en la tabla) e ip_to (segunda ip).

Os dejo el código:

Con este script intentamos evitar que se detecte como la IP del usuario la de un proxy intermedio recorriendo todas las variables que podemos encontrar en $metodos.

Nuevo mensaje en Mozilla Thunderbird

Me pareció casi increíble que Mozilla Thunderbird no pudiera incluir plantilas en los e-mails automáticamente de serie. (Es cierto que soporta plantillas, pero tienes que pulsar en la plantilla antes de crear el mail).

Afortunadamente, encontré hace tiempo la extensión ExternalTemplateLoader de Kaosmos. Nos introducir una plantilla que se cargará automáticamente cuando redactemos/respondamos/reenviemos un mensaje.  Pero además, esa plantilla podemos cargarla desde un archivo local o alojada en un servidor de Internet. Con lo cual podremos también, crear plantillas dinámicas.

Para hacer plantillas dinámicas, tenemos varias posibilidades:

• Si lo que queremos hacer dinámico es cambiar una frase, un texto, una foto que cambie cada cierto tiempo, podemos crear un cron job que genere el archivo html de plantilla cada cierto tiempo, eso nos ahorraría tener que generar la plantilla cada vez que vamos a escribir un mail.
• Si queremos monitorizar algo, crear un identificador por cada email que vayamos a enviar, escribir un informe, contabilizar los mails, etc; no queda más remedio que generar la plantilla cada vez que vayamos a redatar un mail.

En futuros posts incluiré ejemplos de cada uno de los métodos.