La tecla “Ins” (insertar) carga sobre sus hombros un triste récord: nadie nunca jamás la presionó a voluntad, sólo por error.

Ha llegado la hora de deshacernos de la tecla Ins, que tanto mal nos ha causado. Basta de robar tecleos que inocentemente apuntamos a otro objetivo realmente útil. NO! a la tecla Ins.

Muchas veces el uso que se hace de los formatos de imagen no es coherente con la finalidad para la cual esos formatos se crearon. El desconocimiento (o el apuro) a la hora de generar la imagen final que, por ejemplo, debemos publicar en una web nos lleva a cometer errores que pueden tener malas consecuencias:

• La imagen se degrada tanto que resulta desagradable.
• La imagen se degrada o no, pero queda con un tamaño que multiplicado por los visitantes que tenga nuestra web resulta en más costos de hosting («queda muy pesada»).
• La imagen queda perfecta, pero el usuario tarda mucho tiempo en acceder al contenido y se va.

Es necesario conocer que los formatos tienen cada uno un objetivo, y que no existe un formato «mejor» en todos los casos. Exploremos los tres más utilizados actualmente en la web.

El famoso JPEG

Este formato es tal vez el más usado y no siempre es la mejor elección. Fue creado en la década de los ’80 por el «Joint Photographic Experts Group» (Grupo de expertos en fotografía). De allí su sigla, aunque normalmente se lo nombre como «JPG» debido a que en sistemas Microsoft DOS se utilizaban extensiones de tres caracteres.

Este formato de imagen tuvo gran aceptación gracias a su mecanismo de compresión. Es necesario distinguir aquí dos términos:

• formato: es la manera en la cual la información de la imagen debe ser organizada en un archivo de computadora para que pueda ser leída posteriormente. La «información» de la imagen no es nada más que todos sus pixeles, teniendo éstos información de color y de opacidad, que serán almacenados como bytes.
• algoritmo de compresión: es, básicamente, una serie de cálculos que se realizan con la información de los pixeles para reducir el conjunto de datos y lograr un tamaño de archivo menor.

Volviendo a JPEG, el éxito de su algoritmo de compresión está determinado por la posibilidad de elegir la «fuerza» de esta compresión. Al comprimir más la imagen, reduciendo su tamaño, (y esto lo sabemos todos) generamos una imagen con peor calidad. Esto se denomina «algoritmo con pérdida», ya que estamos literalmente perdiendo información de la imagen en haras de reducir también el tamaño en bytes. El usuario tiene entonces la posibilidad de elegir cuánto desea perder, dependiendo de sus propias necesidades.

Pero esta compresión tiene a su vez un comportamiento que depende del objetivo para el cual fue diseñada. Como dijimos, este algoritmo proviene del mundo de la fotografía. Al comprimir imagenes fotográficas (por ejemplo, un paisaje) el algoritmo JPEG es muy eficiente, en el sentido de que logra reducir mucho el tamaño del archivo final sin generar defectos visibles al ojo humano. Dicho de otro modo: hay que comprimir mucho una foto para empezar a notar los defectos generados por este algoritmo.

Cuando se trata de imágenes que poseen planos de color y líneas con cambios abruptos de un pixel al siguiente (una obra de Piet Mondrian, por ejemplo) el algoritmo de JPEG es muy deficiente y se generan los llamados «artifacts»: esos conocidos ruidos en la imagen, generados durante la compresión.

Artifacts generados por la compresión. Izquierda: original; derecha: comprimido con jpeg.

Cuando estemos ante imágenes de estas características «Mondrianescas» no elegiremos el formato JPEG. Los mismos artifacts también afectan notoriamente a la tipografía.

GIF, el animado

El formato GIF también fue ideado a fines de la década del ’80. Su sigla proviene de «Graphics Interchange Format» (Formato para intercambio de gráficos) y fue creado por la empresa Compuserve.

Existen diferencias fundamentales entre GIF y JPEG. GIF es un formato que se caracteriza por trabajar con una paleta de colores. Al guardar una imagen, se elige una cantidad de colores (entre 2 y 256) y se representa toda la imagen con esa paleta. Esta «normalización» de la paleta a utilizar es la que permite que el archivo final contenga menos información que el original, resultando de menor tamaño. Este tipo de formato se denomina «color indexado».

Por supuesto, esta reducción en la cantidad de colores también implica una peor calidad debido a la pérdida de la información de color original, por lo que el formato GIF no puede utilizarse en fotografías como JPEG a menos que querramos lograr algún efecto (como el «posterizado» de Adobe Photoshop).

Fotografía original a la izquierda, indexada con GIF a 64 colores a la derecha.

Una vez que la imagen ha sido reducida en colores se realiza una operación muy parecida a la que usan los populares formatos ZIP o RAR. Este paso es «sin pérdida» porque al descomprimirse se obtiene un archivo idéntico al original. Este segundo paso le permite a GIF perder aún más peso de archivo.

Dos características interesantes de GIF son el soporte para «canal alfa» y para animaciones. El canal alfa es un dato adicional, que indica qué pixeles deben ser opacos y cuáles transparentes, posibilitando de esta manera imágenes con porciones que dejan ver lo que haya por detrás, algo imposible en JPEG. Las animaciones GIF son posibles ya que este formato puede almacenar varias imágenes en un mismo archivo, mostrándolas secuencialmente para formar una animación. Esto lo convirtió en el formato por defecto para banners en la web, antes de Adobe Flash. Es de destacar que el formato GIF no crea artifacts en la imagen.

El moderno PNG

PNG está siendo cada vez más usado. Muchos profesionales que trabajamos en web tenemos alguna reticencia todavía, debido a los problemas que tenían los navegadores antiguos para mostrarlo. Fuera de esta cuestión emocional, la verdad es que los actuales navegadores grado «A» trabajan perfectamente con este formato.

PNG («Portable Network Graphics»: Gráfico portable en redes) se inventó a mediados de los ’90 como alternativa a GIF. Los bytes que componen las primeras partes de los png están diseñadas para poder detectar distintos sistemas operativos. El hecho de que los sistemas operativos (DOS, Mac, Unix) históricamente hayan tratado ciertos caracteres de diferente modo es lo que lleva a este diseño. De allí la denominación de “portable”.

PNG posee canal alfa al igual que su antecesor GIF. Pero mientras que los canales alfa de GIF son de 1 bit (es decir, un pixel será opaco o transparente, sin intermedios), los de PNG permiten mayor «profundidad de bits». Resumiendo: los pixeles de una imagen en formato PNG pueden tener un porcentaje de opacidad, de más a menos transparente.

Una imagen PNG (un círculo verde degradado) en una página web, vista sobre dos fondos. Demostración de transparencias intermedias.

Respecto de la compresión debe tenerse en cuenta que PNG se puede utilizar en color indexado o en color verdadero. «Color indexado» es la utilización de una paleta de colores preseleccionada, idéntico a GIF. «Color verdadero» es la utilización de tres canales de color (RGB) por lo cual pueden representarse todos los colores. Estas dos formas de trabajo están identificadas en Adobe Photoshop como sigue:

• PNG-8: creará una imagen con color indexado, igual que GIF, con una paleta de la cantidad de colores que seleccionemos (como GIF, entre 2 y 256 colores).
• PNG-24: trabajara con RGB, creando una imagen sin pérdida.

Debemos notar que al trabajar con PNG-24 es probable que generemos un archivo de mayor peso que un JPEG aún de máxima calidad. Debe compararse en una vista previa para decidir cuál es la mejor opción en este caso. Esto depende de cómo sea la imagen y no se puede determinar de antemano.

Es de destacar que en algunos casos la compresión nula de JPEG (o sea, máxima calidad) modifica igualmente las imágenes de un modo que las inutiliza. Esto es muy común en degradados. En ese caso la solución es utilizar PNG-24, un formato que tampoco genera artifacts en la imagen.

Tanto en PNG-8 como PNG-24 se puede utilizar (o no) la característica de transparencia. A diferencia de GIF, PNG no soporta imágenes animadas en un mismo archivo.

Conclusiones

GIF y JPEG son dos formatos bien arraigados. Cada uno tiene sus pros y contras, debido a que fueron diseñados para situaciones diferentes, hace 30 años.

Utilizaremos JPEG cuando estemos ante fotografías que no tienen características vectoriales o geométricas, por decirlo de algún modo. JPEG es muy propenso a crear artifacts -ruido- cuando comprimimos demasiado y tenemos planos de color o líneas.

Preferiremos GIF cuando aparezcan estas cualidades que llamo «Mondrianescas»: líneas, diagonales, planos de color puro, imágenes a dos colores. Cuando la cantidad de colores sea fija (imaginen un tablero de ajedrez), GIF es la mejor opción dada su paleta de colores indexada.

Si conocemos el manejo de PNG, éste sea tal vez el mejor formato. Es el más moderno y nos permite trabajar con una paleta reducida, al igual que GIF, o con todos los colores, al igual que JPEG. Entre JPEG y PNG la decisión será tomada basándonos en el tamaño de archivo final y por los ruidos que genere JPEG, inutilizando o no nuestra imagen.

Como pensamiento final debo recalcar: no existe un formato mejor para todos los casos.

Imágenes originales en la columna izquierda. Al centro luego de comprimirse a JPEG en 90%. A la derecha luego de convertirse a GIF en 32 colores.

Copyright 2012 Mauro Gullino – Material de libre distribución bajo Licencia Creative Commons Atribución-CompartirDerivadasIgual 2.5 Argentina.

Hace dos meses comenzó en UTN FRBA el curso de desarrollo de aplicaciones para Facebook. Este curso está orientado a personas que conocen de desarrollo web y quieren apuntar sus conocimientos existentes a un nuevo campo, como es el mundo de las aplicaciones dentro de Facebook.

¿Qué se puede hacer dentro de Facebook? En sentido general lo que lograremos es una aplicación integrada con el flujo social de información de la plataforma. Uno de los objetivos principales suele ser lograr la “viralización”, es decir, que un contenido se “propague” entre los contactos de distintas personas para ser difundido y comunicado con eficacia. Para lograr esto, las aplicaciones buscan generar contenido interesante para el usuario y que éste lo publique o recomiende. Esto se logra integrando estas acciones del usuario con lo que los demás ven sobre su actividad (el news feed, o muro).

Desde el punto de vista del desarrollo web, las aplicaciones para Facebook son, básicamente, aplicaciones web, pero que funcionan dentro de un ámbito particular y conviviendo con otros desarrollos de Facebook. Nos estamos refiriendo a las aplicaciones tipo Canvas. Este Canvas no es más que un iframe que queda contenido dentro de la interfaz de Facebook.

Pero las cosas no son tan sencillas o, dicho de otro modo, las cosas son mucho más profundas y poderosas. Además del flujo de información (o sea, HTTP, web) entre el navegador del usuario y Facebook, tendremos comunicación entre nuestro servidor (donde hosteo mi aplicación) y los servidores de Facebook, para lo cual necesitamos conocer desde mecanismos de seguridad (HTTPS, desafíos, algoritmos de hash) hasta la forma de dialogar con Facebook (las Facebook APIs).

El acceso a la información social del usuario, además, está mediada por el sistema de permisos (OAuth) y autorizaciones, de manera que tenemos un acceso limitado según las preferencias de cada persona. Este sistema de permisos es bastante complejo y tiene una evolución rápida en el tiempo, por lo que es necesario comprender las bases conceptuales para poder actualizarnos rápidamente.

En esta oportunidad, comparto con ustedes el material utilizado en la clase 3, referido al sistema de autorización de aplicaciones. ¡Espero que les sea de utilidad!

Aplicaciones para Facebook, material clase 3: autorización de aplicaciones

Estos últimos días sucedió una oleada de posteos en distintos blogs tecnológicos acerca del lenguaje de programación Go. La idea rápida es: “Google dejó de usar Python y se pasó a Go, que es lo que se viene porque es mucho mejor”.

Espero que mensajes como estos ayuden a mitigar las declaraciones de que tal lenguaje es absolutamente preferible a otro por tal o cual característica, sin tener en cuenta para qué problemas se va a aplicar. No estudien un lenguaje de programación porque las noticias hablan de él.

Supongo que a mediano plazo tendremos una batalla por el liderazgo en programación funcional y en programación concurrente. Estimo que los participantes podrían ser Haskell, F# y Erlang (que viene con ventaja en popularidad gracias al empuje de CouchDB).

Acerca de las modas, les dejo un párrafo del libro “Análisis y diseño orientado a objetos de sistemas”, de Bennett:

“Cualquier empresa resulta muy vulnerable [a las modas] si la mayoría de los directivos tiene poco conocimiento de las teconologías de la información y, por tanto, carecen de base racional para evaluar las afirmaciones exageradas que algunos fabricantes están dispuestos a realizar sobre sus productos más novedosos”.

PD: si buscan alguna intro a Go, está aquí.

Hace unos días, investigando sobre programación concurrente, sistemas operativos de tiempo real y sistemas de alta confiabilidad, me encontré con este supuesto white paper: Linux in Defense: An Urgent Threat to National Security.

Para extraer rápidamente las ideas más importantes:

• Linux es un sistema operativo que jóvenes delincuentes (algo así como crackers) hackean en su tiempo libre.
• Si eso pueden hacerlo unos adolescentes aburridos, imagínense lo que pueden hacer organizaciones de gobierno enemigas o terroristas.
• Siempre hay una lista de vulnerabilidades pendientes, porque el sistema siempre tiene errores.
• Gente mal intencionada puede insertar troyanos en el código fuente de Linux ya que es de código abierto.
• La CIA insertó troyanos en software que luego utilizaron los soviéticos, así que bien pueden nuestros enemigos estar insertando troyanos en estos sistemas de desarrollo colaborativo y open source.
• La solución es utilizar el sistema operativo de esta compañía, closed source, seguro y que nunca fallará.

Mis anotaciones al supuesto white paper:

• No es un white paper: es una publinota. El artículo está escrito por el CEO de la empresa que lo publica, fabricante del sistema operativo Integrity.
• Linux no es hackeado por adolescentes rusos en su tiempo libre, ese es Microsoft Windows, sistema closed source. Y por adolescentes americanos también, entre otros muchos países.
• Si en los sistemas colaborativos se pueden insertar troyanos, ¿por qué no en el closed source? Con más razón un troyano insertado en software closed source será más difícil, o imposible, de detectar. El mismo ejemplo que pone el autor acerca de la CIA lo demuestra.
• La solución no es desconfiar del software open source, sino controlarlo de cerca, al igual que se haría con una solución closed source de un contratista privado y nacional. Incluso controlar la seguridad de un sistema open source será más sencilla, ya que muchos problemas habrán sido descubiertos por la comunidad de desarrollo.
• Si siempre hay una lista de vulnerabilidades es porque el sistema evoluciona constantemente. Para hacer decrecer la lista se debe detener la incorporación de nuevas características. Esto sucede en el mundo open source y en cualquier otro, nada más que resulta visible en mayor o menor medida para el público.
• Todo sistema tendrá fallas y nunca será perfecto. Nunca existirá un sistema 100% seguro, y esto es algo que sabe casi todo el mundo, por lo que no se puede proponer una solución porque es perfecta.

Está bien demostrado que lo mejor que se puede hacer por la seguridad y estabilidad de una pieza de software es la utilización del esquema open source.

Dos cerebros suelen pensar más que uno. No digo mejor sino más, y eso es esencial para descubrir problemas en el software, donde se deben descubrir problemas en lugar de las soluciones.

¿Cómo se puede sostener, por ejemplo, que un compilador de C desarrollado por 20 programadores es mejor que GCC, desarrollado por miles? Suponiendo que se parten de los mismos objetivos, siempre será mejor que el código sea visto/desarrollado/revisado por la mayor cantidad de programadores posible.

En ASP existen las variables “Application”, parecidas en funcionamiento a las sesiones, pero que son compartidas por todos los usuarios. Es decir, como variables de sesión pero visibles en todas las sesiones del servidor.

Este tipo de variables tiene algunos usos interesantes, siendo el ejemplo clásico el del contador de usuarios. Como la variable es compartida por todos los scripts, es muy fácil registrar la cantidad de hits de un sitio, o las sesiones creadas para intentar contabilizar los usuarios distintos.

En fin, hace unos días estoy desarrollando una extensión para PHP 5, justamente para tener este tipo de variables Application. Se trata de un módulo de PHP como cualquier otro. La magia de las variables compartidas se realiza con shared memory de la biblioteca libmm.

Actualmente tengo funcionando una versión prototipo en Debian Lenny, Apache 2.2.12 y PHP 5.3.0. Por funcionar con shared memory se precisa tener PHP como módulo de Apache (no CGI)  y a éste funcionando en modo worker (no prefork). Además, PHP debe haber sido compilado con –with-mm, lo que hace que no funcione en entornos thread safe si usamos además el módulo session…

En realidad este es un llamado a la solidaridad, para quienes estén más familiarizados con las distintas variedades MPM de Apache y también para realizar algo de testing en alguna plataforma Windows. ¿Interesados?

He llamado al módulo “appvar” y las funciones que provee esta ínfima versión 0.1 son:

• appvar_set(“mi_variable”,”mi_valor”);
• appvar_get(“otra_variable”); //se conserva en memoria, y visible por todos los scripts!
• appvar_unset(“cual_variable”);

Además cuenta con lock y unlock, todavía no implementado.

Hace unas semanas se me ocurrió hacer un experimento. Durante 15 días recolecté las palabras más usadas en el feed RSS del diario Clarín. Las palabras relevadas corresponden a los títulos y bajadas de las noticias en Clarín Digital.

Si les interesa, estos son los números que muestran las palabras más utilizadas por este diario:

[gobierno] => 73
[gripe] => 53
[presidente] => 34
[policia] => 33
[ministro] => 29
[dialogo] => 29
[jefe] => 24
[clarin] => 21
[moreno] => 20
[cristina] => 19
[oposicion] => 19
[ciudad] => 18
[muertos] => 18
[indec] => 17
[honduras] => 17
[moyano] => 16

La cifra que se muestra es la cantidad de veces que se utilizó la palabra en los últimos 15 días, contando desde hoy. Se eliminaron las palabras comunes de nuestro idioma.

Esta nueva entrega de mi lenguaje de scripting favorito tiene un soporte rudimentario de “goto”.

No quiero imaginarme las malas ideas que mucha gente va a tener con esto.

En la otra hand, llegaron los namespaces prometidos para la versión 6. ¡Enhorabuena!

Hace mucho tiempo que trabajo en web y un poco más que mi vida tiene que ver con la programación. Los últimos años han sido los años de popularización de WAMP, a tal nivel que está casi estandarizada la forma de aprender a programar para web. Esto es por el paso del tiempo y porque cierta arquitectura de aplicaciones se afirmó como la más confiable, esto es, PHP y MySQL.

Me da la sensación, hace un tiempo más bien corto, de que mucha gente está volviendo a preguntarse las cuestiones iniciales y estamos repensando las cosas que dábamos por absolutamente definidas. Adobe Air le dio un interesante empuje a SQLite, librería que existe hace bastante tiempo, pero que es más bien desconocida. Lo mismo con YAML, una interesantísimo formato como alternativa a XML.

Tenemos que volver a las bases, agarrar la navaja de Occam y replantearnos el diseño de las aplicaciones. De aquí el título de este artículo. Me parece importantísimo que en las facultades, donde se enseña a producir software, se sigan tocando los temas esenciales a la computación: los bytes y los ciclos de máquina.

Incluso desde el punto de vista del ahorro de energía: tenemos miles, sino millones, de sitios web trabajando con motores de bases de datos preparados para soportar cantidades inimaginables de información, cuando una pequeñísima librería como SQLite  sería más que suficiente. Estamos desperdiciando CPU y complicándola innecesariamente.

La popularización del desarrollo agile, en detrimento del RUP, está abriendo paso a una nueva forma de pensar.

Hoy estuve actualizando varias instalaciones de WordPress. Qué fácil es actualizarlo… hasta que te topás con algún problema.

Actualizar desde versiones muy anteriores a la última es mucho más difícil que de una inmediata anterior. Habrá que acostumbrarse a hacerlo más seguido.