Alpha's Manifesto

A black and white figure's thought-hive

My time tracker: Google Calendar

Boxes and colors, what's left to ask?

Calendar chain

Long time ago I wrote about a proposal from a StackExchange user about how to use Google Calendar for task planning across projects and activities. The idea seemed good, and after months of making it my bread and butter, I think I have perfected it to address most of the problems I had with my workflow in Trello. It’s  not the holy grail of productivity, but it has helped me a lot.

Let me explain it to you, because if you use Google Apps or GMail, you’re most likely to benefit from this.

(Read more →)

Google Inbox and Inbox Zero

I'm so on board, this is why

Google Inbox

I recently received a Google Inbox invitation, after requesting it three weeks ago. And after trying it out… boy, I love it.

Here I’m going to tell you why I love it so much, why it suits perfectly into my inbox management technique, and why I think it’d be useful for other people too. Also, a little bit of what it could have to make it even better.

(Read more →)

Blockly

Un lenguaje de programación visual

Blockly es una apuesta de Google para enseñar programación desde los bloques más básicos con esa misma aproximación: bloques.

Gracias a la novedad visual (y la autogeneración de código que ocurre por detrás) se puede programar fácilmente con encajar piezas de rompecabezas, de forma muy intuitiva. Lo que nos demuestra es que se ahorraron la complejidad de la sintaxis de un sistema reemplazándola por un rompecabezas, que vuelve el conocimiento de sintaxis en un juego.

Existen tres demos para Blockly actualmente:

  • Maze, nos impone el desafío de resolver un laberinto con instrucciones simples
  • Code, nos permite ver un poco detrás de la cortina y observar como Blockly puede generar código en otros lenguajes.
  • RTL es un demo de cómo se vería la interfaz de derecha a izquierda.

Parecería por estas características no se trata sólo de un intento de educación, sino también la capacidad de extender aplicaciones propias de una forma visual y fácil de comprender. Imaginen permitirle a los usuarios de un sistema “programar” cómo debe comportarse el sistema en determinados casos. Realmente es una opción muy poderosa de extensibilidad, sin requerir la complejidad de saber programar.

Soy un zorrinito en bloques.

¿Por qué distintos dominios para recursos estáticos?

La razón detrás de las URLs raras...

Sabemos que el nombre no es más que un nombre y que no importa cuál sea el servidor actual en donde se están alojando los datos, pero parecería que es una práctica común de muchos sitios grandes (léase: Facebook, Twitter, Google, etc.) hacer referencia a muchos de sus recursos en dominios externos. Por ejemplo, las imágenes de Facebook se encuentran alojadas debajo de http://static.ak.fbcdn.net/ y no debajo de http://www.facebook.com/, ni siquiera debajo de http://imgs.facebook.com/. ¿Por qué?

Alguien ya hizo esa pregunta y la respuesta fue nueva para mí: hay una limitación en varios browsers (y hastas donde yo sabía, algunos sistemas operativos) que previene hacer más de dos, tres o cuatro conexiones simultáneas a un mismo hostname. De hecho, es parte de la especificación HTTP 1.1 (parece que cumplir el estándar no siempre está tan bueno, ¿no?). Ahora, si notaron, la limitación es por hostname, ¿por qué entonces utilizar distintos dominios? La razón es evitar cookies que pueden estar yendo y volviendo en cada uno de los pedidos, y para evitar eso, se puede usar un dominio extra que nunca devuelva cookies. De esa forma, sitios grandes como estos se ahorran mucho bandwidth.

UPDATE: Gracias a Exos, que claramente estaba más informado que yo en este tema, las limitaciones exactas son de tres conexiones por cada dominio y cinco para cada IP. Los distintos dominios/subdominios ayudan a utilizar CDNs para distribución de contenido con mayor velocidad. Exos está en desacuerdo (y demuestra por qué, miren los comentarios) con que las cookies sean una gran carga respecto del bandwidth. Entonces el por qué de los dominios vs. subdominios queda en duda, pero suponemos que debe estar relacionado con políticas de administración interna de cada empresa.

Soy un zorrinito performante.

Schema.org

Repositorio público de esquemas de markup

En el punto intermedio entre estándares y SEO está Schema.org, un sitio que haciendo uso de los estándares de microdata permitiría mejorar la meta-información que un sitio está aportando, específicamente para hacerlo más apropiado a los motores de búsqueda. La página de Getting Started nos da una buena idea de qué trata esto.

Según cuentan, Google y otros proveedores de búsqueda están teniendo mucho en cuenta estos formatos de metadatos, llamados micro-formatos, y justamente podemos apreciar muchos de ellos y su estado de aprobación en Microformats.org.

Soy un zorrinito micro-formateado.

GoMo

La iniciativa mobile de Google

Gracias a i.MicroSiervos me enteré de GoMo, una aplicación web que toma nuestro sitio y nos analiza de forma personalizada las características del mismo y nos da sugerencias para pasar al mundo mobile. Cosas como la visibilidad de la página, los links, las tecnologías utilizadas y demás, está todo disponible en un reporte de forma gratuita.

Cabe destacar que este sitio es en realidad una iniciativa de Google, con lo cual gana un poco más de renombre.

Les recomiendo también visitar el mismo sitio desde un dispositivo movil, la enorme diferencia con el sitio original realmente habla de tomar una aproximación diferente al momento de pensar en mobile.

Soy un zorrinito móvil.

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: G+ y los nombres

Este es el último comentario que veo hasta hoy (gracias Ligre!) del tema de los nombres en Google Plus.

En pocas palabras, Google no admitiría que para sus servicios estemos usando alias que no sean nuestros nombres reales, cuando se esperaba que Google, uno de los grandes en la innovación de nuestra experiencia con internet, entendiera que muchas veces la identidad digital no tiene los mismos campos de tablas que los de la identidad legal.

Sin embargo, y para hacer las cosas más interesantes, en las políticas de los servicios de Google, se define al “nombre real” como “el nombre por el que generalmente somos más reconocidos”. Cabe destacar que para mucha gente, este nombre no es el que los hace más conocidos (al punto de llegar a los pseudónimos de distintas personalidades famosas). O aún, que para muchos aún no revelar sus nombres es una forma de mantener su seguridad.

Pero lo que hace esto más interesante todavía, es que como ya Google integra todos sus servicios, esto significa que deberíamos actualizar nuestro nombre en todos los demás servicios. Un poco invasivo para el usuario, no?

¿Ustedes qué opinan?

Soy un zorrinito pseudonimado.

Link del día: HTML5 Speech input

Esta noticia la vengo guardando desde Marzo, así que ya de nueva no tiene demasiado. Pero no deja de ser interesante. Resulta que para una de las versiones beta de Google Chrome (que de hecho, ya no es más beta), hay un nuevo attributo para los elementos input de HTML5 que básicamente permite obtener reconocimiento de voz. Este atributo, debería hacer que el navegador automáticamente reconozca nuestra vos como para rellenar un campo de texto, permitiendo búsquedas más rápidas o entrada de datos más correctas (si es que el usuario tiene problemas con la ortografía).

Por supuesto, como con todo reconocimiento de voz, hay que ver qué tal funciona. Yo estuve jugando un poco con el que ya está disponible en Google y parece funcionar bastante bien (en inglés). Por supuesto que con palabras raras tampoco funciona bien, parece estar muy basado en un diccionario… pero es una muy buena aproximación. Además de innovador, es en cierta forma divertido.

Soy un zorrinito reconocido por voz.