El costo de desaparecer

Todo empieza con el malestar que me produce el celular. Definitivamente es el aparato más esclavizante que existe. Llamada que recibo es por algún tipo de problema y da lo mismo el interlocutor. Si es tan urgente mándeme un mail, asi lo dejamos por escrito y nadie se arrepiente o desdice de sus dichos.

Entonces decidí no contestar el celular. Resultado: CAOS.
Y espérense el resultado de explicar mi decisión de incomunicación voluntaria, CAOS³
Entonces decidí eliminar la explicación y comentarios afines, de manera de ser consuecuente con mi decisión inicial, así nadie pregunta, así nadie comenta, así no respondo, así no hay "daño colateral" (muertos, heridos o insultados en la zona de fuego).

Hace 10 años atrás yo no tenía celular, y estaba lejos más tranquilo, o menos inquieto. Era una cosa menos de la que preocuparme:

• Que esté cargado
• Que tenga saldo
• Que no me lo vayan a robar
• Que esté en silencio
• Que tengo que responderlo

Al menos yo considero que NO NECESITO estar siempre ubicable.

Empiezo a evaluar desaparecer incluso de la red de mensajería instantánea y correos (eso es más difícil). En mi caso la soledad, y más puntualmente la incomunicación favorece mi tranquilidad, cada día más escasa.

¿Qué pierdo? En realidad subjetivamente no es tanto.
¿Qué gano? Supuestamente tranquilidad, pero empiezo a dudar de ello.

Javascript vs Flash

Por más que le busco no hay caso, Flash no me termina de convencer. A mis ojos sigue siendo la herramienta con que los diseñadores (algunos) convencen a sus clientes que un sitio web mal hecho, no administrable, no indexable, no buscable, escasamente navegable y lleno de accesorios sonoros, visuales y normalmente innecesarios, es la mejor opción.

Estoy claro que en su justa medida es LA opción a usar, incluso por sobre los applets en Java, que eventualmente podría defender con mi vida (exagero...).

Tiempo atrás hice una especie de demostración de un sitio con olor a Flash, pero desarrollado solamente con JavaScript y HTML. El resultado era solamente ilustrativo, pero al menos dejaba clara mi posición: http://www.santa.cl/test/indice4.htm
En ese entonces usé una librería cross-browser que me permitía compatibilidad hacia atrás con buena parte de los navegadores existentes: http://www.cross-browser.com/ De hecho años más tarde me hice "famoso" en ese sitio :-D
(Recien encontré la referencia y de este experimento hacen 5 años)

Bastante más reciente ha sido mi conocimiento de JQuery, una librería JavaScript que permite más o menos lo mismo . Pierde en compatibilidad con varios navegadores ahora obsoletos, pero permite tener lo que llamamos JavaScript no-obstrusivo, es decir código absolutamente limpio. Y lo otro es que permite tener un sitio 100% "W3 compliant" con animaciones y otras chorezas.
Un ejemplo de lo que he hecho con esto es la portada del sitio de la empresa donde trabajo actualmente: Core Technologies, si navegan un poco en ella verá una que otra animación. Y si desactivaran las hojas de estilo los contenidos son igual visibles, lo mismo si usan navegadores no compatibles.

Es decir que desde hace al menos 5 años que he estado de una u otra manera (unas mejores que otras) demostrando que se pueden tener contenidos Y animaciones sin la necesidad de Flash.

Hoy vi un par de experimentos que ha hecho el equipo de Google Chrome con JavaScript, cosas realmente sorprendentes, y recorde un sitio que ví unas semanas antes: Project Miso Ya el sitio completo resulta sorprendentemente atractivo, y el área de juegos es una muestra de lo que se puede hacer.

No en vano Project Miso fue nominado entre los finalistas de los SXSW Web Awards 2009, y ganó en su categoría (CSS).

No discuto que con Flash probablemente (y casi de seguro) hacer más o menos lo mismo debe resutar lejos más fácil, pero siempre objetaré las capacidades de gestión de los contenidos, así como la de buscar y encontrar información.

No cuesta nada hacer un sitio web bien hecho, lo principal siempre son y serán los contenidos, después viene la diagramación y finalmente todos los efectos especiales que uno quiera. En ese orden.

PDFs con Java

Advertencia: Artículo técnico, aburrido y poco relevante para el lector casual. Acepto, a modo de compensación, saludos, abrazos e invitaciones a tomar cervezas.

El problema de armar un PDF con Java en realidad está resuelto hace bastante tiempo. Las opciones son medianamente claras, Apache FOP, iText, y otro par que se me escapa.

Personalmente siento que iText, a pesar de ser una herramienta muy poderosa, no es la mejor de las soluciones pués en realidad dibujas el PDF (como un dibujo), más que armarlo como un archivo de contenidos (texto e imágenes).
En ese sentido FOP me resulta mucho más natural, por cierto ayuda bastante tener conocimiento y entendimiento de HTML, pero también es cosa de preferencias y del contexto que abordemos.

JavaWorld ha publicado un artículo que habla de como hacer una aplicación para Twitter (plataforma que estoy evitando a toda costa). De este artículo rescato el siguiente segmento de código:

response.setHeader("Expires", "0");
response.setHeader("Cache-Control",
   "must-revalidate, post-check=0, pre-check=0");
response.setHeader("Pragma", "public");
response.setContentType("application/pdf");
response.setContentLength(pdf.size());
ServletOutputStream out = response.getOutputStream();
pdf.writeTo(out);
out.flush();

Esto corresponde a los headers para realizar una descarga de un PDF desde un servlet o un JSP.

Donde:

    public void writeTo(OutputStream os) throws IOException {
       if (document.isOpen()) return;
       baos.writeTo(os);
       os.close();
   }

Lo ideal en este contexto hubiera sido:

PdfWriter.getInstance(document, response.getOutputStream());

(el PdfWriter es del iText...) pero muchos navegadores no soportan descargas donde se le entrega el arreglo de bytes de manera dinámica, ie es como si necesitaran a priori saber cuanto pesa el archivo.