Alpha's Manifesto

La madriguera de una insignificante figurita blanquinegra.

wkhtmltopdf

De HTML a PDF

Nombre complicado, pero aplicación muy útil. Hace algunos días ando trabajando con wkhtmltopdf, una aplicación basada en QT y en Webkit que renderiza páginas web y las convierte en PDFs. Lo interesante es la forma en la que se puede automatizar este proceso, generando elementos más allá del contenido en sí (como tablas de contenido, encabezados y pies de página, etc). Mejor aún, este paquete contiene wkhtmltoimage.

Por supuesto, todo esto puede ser parte de una aplicación mayor que genere PDFs o imágenes desde otro documento (luego publicaré algo sobre eso) basándose en un proceso automatizado. Parece que es muy comùn que aplicaciones utilicen esto de fondo para generar screenshots de páginas web o reportes PDF desde un HTML.

Soy un zorrinito screenshoteado.

¿Por qué HTML5?

Hace no mucho se me presentó en una conversación, en donde me encararon con la siguiente pregunta: “Si el estándar de HTML5 no está aprobado aún, por qué usarlo?”. Me abalancé con una respuesta salvaje del estilo “Por qué no?” (aunque con otras palabras) y no dije mucho más. ¿Por qué alguien querría no usarlo? Pasaron 30 segundos desde mi respuesta y me puse del otro lado, pensando en que me estaban hablando de una nueva versión de Windows y ahí creí comprender el punto de vista. Creo que no aplica a HTML5 pero… por qué habría una diferencia?

Fue entonces en donde me puse a dar una respuesta más elaborada, la cual reproduzco a continuación.


HTML5 es algo muy nuevo todavía, y eso tiene sus pros y sus contras.
El contra que todos obviamente vemos ahora es que puede cambiar hasta terminar de definirse, sumado a que tiene poca adopción y (va a tener) bugs en implementaciones en distintos browsers. Sumenlé problemas de seguridad que sin duda se van a venir, backward compatibility no-tan-suave y más temas.

Ahora, qué tiene de bueno? No voy a enumerar lo nuevo {en cuanto a capacidades} porque eso lo pueden leer en cualquier lado.
HTML5 va un poquito más allá de la tecnología que implementa. Se trata de, por un lado, una forma nueva de aproximarse a la tecnología de la web. Por otro lado, de un plan mucho mayor de lograr una mejor estandarización (que comenzó con XHTML 1.0 y siguió con Transitional HTML). Por otro lado más, el efecto que ha tenido sobre la comunidad online demuestra que estamos capaces de acelerar el proceso de estándares (que hoy por hoy, no baja de los 5 o 6 años, cuando las tecnologías nuevas aparecen cada 6 meses).

Déjenme explayarme sobre lo anterior:
- Una forma nueva de aproximarse a la tecnología de la web
HTML5 fue un poco más “democrática” que el resto de los HTMLs pasados, en donde ya la dirección no se lleva adelante por los que están experimentando en el área, sino los que además de tenerlo asimilado, ya aprendieron de los errores pasados y tienen visión del futuro. Cosas como webSockets, canvas, CSS3 3D acceleration (sé que no es HTML5 pero lo meto en el mismo paquete) no hablan tanto de algo que deba ser más fácil de programar, sino de una dirección distinta que va a empezar a tomar la web. Va a tratarse más de contenido multimedia e interacción, no más texto, imágenes y links. Abre otra forma completa en que las aplicaciones van a poder trabajar, y es un campo perfecto para la creatividad, la innovación y el avance. Cuando se asiente un poco el polvo va a venir la nueva revelación basada en esta tecnología. No estoy seguro de qué y no me las doy de visionario, pero es lo que siempre pasa, y a la velocidad que vamos, estoy seguro de que cada vez la revolución va a ser mayor.

- Forma parte de un plan mayor
Hace tiempo que la web viene “rota”, por su cualidad de “forgiving”. Cuando la web empezó había uno y luego dos navegadores. Tan poca variedad hizo que los programadores se educaran de forma terrible, y ambas partes luchaban por definir su estándar. El resultado: que cada empresa de IT tenga que tener un departamento de HTML+CSS porque algo que se suponía iba a poder hacer cualquiera se convirtió en toda una ciencia. Para sumar, el avance exponencial lo hace cada vez más difícil, con lo cual hoy hay activas 5 versiones de Internet Explorer, 4 de Firefox, 3 de Opera, 9 de Chrome, 2 de Safari y no sé cuántas más me estoy olvidando. Los renderizados y capacidades varían de SO a SO (multipliquen por todo lo que dije), y ni hablemos del mundo móvil. Cada navegador se tiene que acomodar a las 5 versiones de HTML que andan dando vueltas, más sus distintos modos. Cada navegador también implementa sus propios “extras”, que se idearon al principio para que los programadores lo eligieran y dijeran “este sitio funciona con Internet Explorer 6″ (¿ActiveX alguien?). Eso era marketing: luego la web iba a ser basada en IE. {Eso hoy es inconsistencia cross-browsing.}

Por supuesto, esto es un quilombo {lío}. Todos usaban IE hasta que FireFox y la moda open source comenzaron a tomar popularidad, luego Google Chrome y la promesa de hacer todo más liviano, más rápido y ellos “apoyando y promoviendo” los estándares, hizo que el mercado se distribuyera mucho.

Programar en HTML y hacerlo “aceptable” en todos lados es complejo también, porque los navegadores se bancan {soportan} todas las formas de hacer cosas, y nosotros tenemos que ajustarnos a ellas para que nuestra nueva página haga lo que queremos. Hoy esto es una traba a la innovación y a la mejora, porque lo que tiene que ser simple es un infierno.

El fallback de HTML5 es HTML4 y se planea en un futuro (lejano) volverlo {al HTML} tan estricto como el XML (de hecho, un schema definido por el mismo), lo cual va a significar: menor cantidad de estándares, mejor performance de los navegadores, menos ambigüedad de implementaciones, más soporte y más acogimiento de distintas plataformas y usuarios. Si piensan que HTML es una regla definida en texto, está realmente muy difícil entender por qué esto no fue así antes. (Excepto que se lean la historia de los párrafos anteriores.)

Por supuesto, proponer algo así hoy está condenado al fracaso, por algo simple: nadie lo va a hacer, y nadie va a tirar a la basura la internet que tenemos hoy. Esos pasos graduales (que cada vez van más rápido) lo van a lograr. Lo mismo se hizo con IPv4 vs IPv6, que casi llega al final de sus días (y hablamos de algo que tuvo unas buenas décadas para llevarse a cabo).

- Acelera el proceso de estándares
Ahora que el UX está en su auge, el entrepeneurship es una palabra (sí, también me sorprende), Microsoft se quiere redimir, Google está en la lucha, y la comunidad misma es la que presiona por todo esto, todo se aceleró. Cuando propusieron HTML5, Google Chrome ya soportaba cosas a la semana. {Nota: Esto no es históricamente correcto. La expresión denota la velocidad con que se adoptaron los cambios.} Si algo cambiara, ellos lo cambian al toque. Se ganaron el corazón de los desarrolladores y de a poco mercado con eso. Es la misma historia, pero ahora sin la burocracia de ir contra un estándar, sino al contrario, presionar para que el estándar se consolide.

Y esto es bueno porque todo lo que conté antes va a ocurrir más rápido. En definitiva, nuestras capacidades en la web no van a ser imposibles por la arquitectura cliente-servidor a la que estamos acostumbrados, sino que pronto van a venir cosas que nos van a permitir esa revolución.

Y si yo estoy desarrollando un producto, ¿por qué me importa todo esto?
Si sos alguien a quien le importa la tecnología y tenés tu pasión en ella, ya tuviste tu respuesta.
Si sos alguien que solo quiere vender un producto, o un cliente al que le tengo que convencer de usar tecnología nueva, la razones son las siguientes:

  1. Si tenés un target determinado, podés forzar a que usen el navegador que mejor soporten lo que quieras, y hacer uso de las nuevas capacidades. Sistemas más limpios, más seguros, y que luego solitos van a funcionar con el resto de los navegadores.
  2. Si tu target es público en general, también te genera buena reputación estar sobre la cresta de la ola. Hay un mundo de apasionados y programadores que te van a mirar por cómo hiciste las cosas y no por lo que hiciste en sí (aunque claro, son la minoría). Si tu target es técnico, más interesante aún.
  3. Si te importa la experiencia del usuario, hay cosas nuevas que podés lograr que de otra forma no podés. No todos van a poder experimentarlo hoy (por la compatibilidad), pero los que sí son visitantes ganados.
  4. Cuando esta nueva tecnología se abra paso a más caminos, la ola te lleva sola sin ningún esfuerzo extra. Ejemplo: video HTML5 hizo que quienes adoptaron HTML5 llegaran al mundo móvil con multimedia. Los que se hicieron los cancheros diciendo “ya lo hicimos en Flash” se habrán enterado que esta semana Adobe anunció que abandona Flash para los móviles. Cuántos proyectos habrá que volver a tocar. Dicho sea de paso, yo pienso que Java (en web) va por el mismo camino.
  5. Last, but not least, si alguien se va a comprar un teléfono hoy, se compra un teléfono de los nuevos. Es lo que le vende y lo que mejor le va a andar hoy y mañana. Hacer un proyecto no es tan distinto, hay que usar lo nuevo para que dure más y funcione mejor hoy y mañana. Mejor aún: no hay diferencia de costos entre HTML4 y HTML5. ¿Por qué no elegir el mejor?

Link del día: debugCSS

Como todo elemento del desarrollo web, los CSS también pueden tener errores, y nuestra forma de utilizarlo puede no ser la óptima. Hay muchas herramientas que nos permiten ver cómo podríamos mejorarlo, pero hasta ahora no había visto ninguna que se enfocara directamente en corregir las buenas prácticas (junto con los errores, claro).

Entonces me crucé on debugCSS, un proyecto en forma de bookmarklet que nos da feedback sobre la página que estamos viendo. Al ser un bookmarklet, no toma más que un click y una arrastrada para instalarlo, y lo podemos usar tanto en páginas web como locales. Estuve probando varias páginas y de verdad que aunque no tenga errores graves, siempre estará dando sugerencias de como hacer el CSS y el HTML, más acorde, y no mancharlo con JavaScript inline.

En fin, otra de las herramientas útiles al momento de hacer desarrollo web.

Soy un zorrinito criticón.

Link del día: BuiltWith

BuiltWith es un servicio web que nos proporciona información sobre las tecnologías que soportan un determinado sitio. Más allá de sólo describir los módulos básicos de Apache y el tipo de servidor sobre el que se encuentre dicho sitio, nos comenta sobre varios tipos de utilización de contenido, como CDN, codificación, qué tipo de frameworks se están utilizando, qué tipo de CMS si se puede reconocer, librerías JavaScript, información sobre HTML si se encuentra disponible, y un poco más.

Nos dejan investigar también sobre otros sitios que usen la misma tecnología, pero no lo veo realmente útil a menos que queramos comparar determinados sitios que usen plataformas algo raras. Por ejempo, una búsqueda entre qué sitios usan WordPress no aportará nada interesante, una búsqueda entre qué sitios utilizan codificación UTF8 creo que no sirve de mucho. De todos modos, este tipo de reportes son pagos, pero la información general no lo es.

Soy un zorrinito curioso.

Link del día: Combres, optimización ASP.NET

Justo ayer, rondando la medianoche, JH me envió por email un link a este proyecto llamado Combres 2.0, una librería para optimización de sitios ASP.NET. Recuerdan el caso de Minify para PHP o mod_pagespeed para Apache, este es el turno de ASP.NET.

Esta librería nos permite incluir recursos haciendo uso de ella, de forma que al momento de generar los links también se hacen referentes a una dirección que esta librería manejará, y se encarga del cacheo, compresión y minimizado de los documentos. La reducción de HTTP requests es, por lejos, una de las ganancias más útiles y menos costosas de lograr que nos ofrece.

En el sitio de CodeProject (en donde se encuentra alojado) se pueden ver varias de las aplicaciones y usos que tiene. Veré si prontamente puedo comenzar a utilizarla.

Soy un zorrinito optimizado.

Link del día: Presentaciones JavaScript

Muchos me felicitaron por cómo se veía mi presentación sobre una pequeña encuesta sobre redes sociales, aunque la verdad los créditos no me los debo llevar yo sino Prezi… pero lo bueno es que todos podemos tener algo así en nuestros sitios sin usar ningún servicio de terceros. Deck.js (lo encontré en CSS Tricks) es una librería JavaScript que utilizando HTML5 nos permite crear presentaciones con una visualización muy atractiva (lo cual también ayuda a llamar la atención y transmitir nuestro mensaje).

Deck.js nos permite crear una variedad de animaciones y formatos de presentación, y lo bueno es que nos ofrecen distintos downloads dependiendo de nuestro nivel de habilidad con HTML/CSS/JavaScript, para que estemos cómodos utilizándolo.

A ver quién me muestra la primera implementación que hayan hecho con deck.js así lo coloco aquí!

Soy un zorrinito animado.

Link del día: HTML Code Quality

Sabemos que medir numéricamente la calidad de cierto código no es nada fácil, tratesé del lenguaje que se trate. Siempre hay muchos factores que no afectan en nada a lo funcional, pero que sí afectan a qué tan legible es el código, qué tan mantenible es, y qué tanto puede evolucionar de forma “grácil” sin ser un peso para el futuro de los programadores.

HTML y CSS son un caso particular, porque a diferencia de otros lenguajes, no son lenguajes de programación, pero sí se hacen aplicaciones con ellos. Alguna vez alguien me dijo que sí deberían considerarse lenguajes de programación porque aunque no fueran instrucciones, de alguna forma estábamos trabajando con datos, su procesamiento, y su salida… pero esa es otra historia.

Al momento de medir la calidad de estos lenguajes, existe un problema extra: ya no hay funcionalidad que medir, sólo el código en sí (porque no tienen interacción directa como un lenguaje que se ejecuta). Entonces el desafío se pone más interesante. Google ha atacado este problema y ha escrito sobre como validar y trackear la calidad del código de sus páginas. El artículo en sí no es ni extenso ni detallado, pero despierta algunas ideas que pueden ser útiles para profundizar en este tema. Un punto muy importante es, cualquiera sea el criterio que se tome, trackearlo. De esa forma podemos ver si hay mejora o no… o si el criterio realmente nos dice algo o no.

Soy un zorrinito de calidad.

Link del día: HTML5 Front End Framework

Para todos aquellos que necesitábamos una forma de fácilmente comenzar con trabajos en HTML5, tenemos la opción de comenzar con algo ya estructurado sobre lo que podemos hacer nuestras modificaciones a gusto.

Me he encontrado principalmente con dos opciones muy interesantes. La primera de ellas es HTML5 BoilerPlate, del cual habíamos hablado algún momento en el pasado. Básicamente es un template que podemos utilizar para arrancar rápidamente con la configuración básica de una aplicación HTML5. Ya incluye un poco de configuraciones para cacheo, optimizaciones para mobile, un framework de testing y varias cosas más.

La segunda opción es G5 Framework, que bajo el mismo concepto tiene también varios elementos sobre los que podemos pararnos para impulsar nuestro proyecto. Este además ya tiene una buena cantidad de librerías incluidas con lo que podemos inmediatamente comenzar a constriur sobre ellas, y sobre un framework CSS, útil como siempre.

Quisiera ver qué trabajos se logran con estos frameworks.

Soy un zorrinito HTML5.

Link del día: En defensa de los hacks CSS

Para mi sorpresa, me encontré con un artículo de Mathias Bynens llamado In defense of CSS hacks – introducing “safe CSS hacks”. Él habla e introduce el concepto de los hacks CSS. Permítanme hablar un poco sobre su idea.

Él menciona que los CSS hacks son básicamente comportamiento especial que podemos invocar en cada navegador, algo que a veces es totalmente deseado, y no tiene por qué ser un problema o una mala práctica, sino que puede ser usado para muchas cosas. El uso más común que se le ha dado hoy en día es hacer “tweaks” específicos para la forma de renderización de cada navegador/versión y entonces lograr una visión consistente a lo largo de todos los navegadores.

Sin embargo, decir que tenemos control sobre el estilo de cada navegador y/o versión no necesariamente quiere decir que lo utilicemos sólo para lograr una vista homogénea. De hecho, gracias a ellas podemos utilizar determinadas características que hacen la exploración en un determinado navegador más natural dentro de las capacidades del mismo.

Esto, combinado con sentencias condicionales, hace que podamos tener mucho control sobre lo que el navegador utiliza de nuestro código.

Los dejo con el último ejemplo que el artículo plantea:

<!--[if lt IE 9]><html class="lte-ie8"><![endif]-->
<!--[if gt IE 8]><!--><html><!--<![endif]-->
.foo {
  color: black;
}

.lte-ie8 .foo {
  color: green; /* IE8 and older */
  *color: blue; /* IE7 and older */
  _color: red; /* IE6 and older */
}

Personalmente no me encuentro de acuerdo con esta propuesta, pero veo que tiene sus fundamentos. ¿Ideas? ¿Críticas?

Soy un zorrinito hackeado.

Link del día: Mockups iPhone, funcionales!

Acordándome de cuando hablé de Create Free iPhone Apps, quería charlar sobre esta aplicación web llamada Mokk.me, una aplicación que nos permite visualmente construir elementos de un diseño gráfico para iPhone y personalizar esos elementos a gusto.

Cabe aclarar que todo este sistema funciona en nuestra máquina, quizá la única funcionalidad del servidor es guardar URLs de diseños en particular para luego poder modificarlos. El UI es bastante completo y fácil de utilizar, prácticamente todo se puede hacer con un click, así que es una experiencia muy intuitiva.

Mejor aún, del resultado que tengamos, sólo tenemos que visitar un link para verificar en nuestro iPhone cómo se ve, y luego de eso ya podemos guardar ese HTML para utilizarlo en nuestro producto. Más simple, quizá sólo sea la otra aplicación, que hace todo por nosotros.

Soy un zorrinito mobile.