Alpha's Manifesto

A black and white figure's thought-hive

Productividad: no cortes la cadena

Las técnicas de John Resig y mis resultados

Calendar chainHace mes y medio (uf! cómo vuela el tiempo), Andrés Mochini compartió un artículo con la técnica de productividad del mismísimo John Resig, la famosa técnica de comenzar un hábito para los proyectos personales y no abandonarlo. Prometí probarla y ver qué tal me acomodaba, y aquí están los resultados.

(Read more →)

What-now: graficando dependencias

No se resuelve con un par de líneas

what-now-dependencies

Desde hace un par de semanas estoy trabajando en lograr que el proyecto de what-now grafique dependencias entre tareas: si  una tarea depende de otra, una línea debería conectarlos. Esta tarea básica fue muy simple, pero lo desafiante fue lograr que se graficaran de forma que las líneas se cruzaran entre ellas lo menos posible.

Aquí contaré sobre este logro y sobre lo que aprendí en el proceso.

(Read more →)

Algunas reseñas de libros

Gatos conspiradores, algoritmos, ciencia y juegos HTML5

Hay algunos libros que he leído desde mi última reseña, y al igual que con las películas, dejaré de hacer reseñas individuales. ¡Celebren, porque habrá menos spam para ustedes!

En este caso, los libros de los que voy a hablar son:

  • How to tell if your cat is plotting to kill you, por Matthew Inman
  • Algorithms in a Nutshell, por George Heineman, Gary Pollice y Stanley Selkow
  • The Grand Design, por Stephen Hawking
  • HTML5 Games, por Jacob Seidelin

(Read more →)

Programando Arkanoid – Parte 1

Cómo hacer un pequeño juego en JavaScript y HTML5 canvas

Haciendo ya mucho tiempo que no trabajaba en JavaScript sin la utilización de ningún framework, me propuse crear algo simple que a la vez fuera divertido. Pensé en algunas opciones y la ganadora fue un juego de Arkanoid (que, ahora me entero, es una de las tantas copias del Breakout, y para mi el nombre original siempre fue Arkanoid, en fin).

El resultado final lo pueden ver aquí y el código fuente está en mi repositorio de GitHub, pero no es tanto el resultado sino el viaje lo que fue interesante, y quiero describir las cosas que aprendí en ese camino.

Vengan y acompáñenme en mi viaje.

(Read more →)

jQuery Novice to Ninja

Manos a la obra desde lo más básico

jQuery Novice to Ninja

Acabo de terminar de leer el libro jQuery Novice to Ninja, de la editorial SitePoint y de los autores Earle Castledine y Craig Sharkie. Debo decir que el libro ha sido una buena elección de lectura.

Para empezar, el libro asume que el lector tiene pocos conocimientos de jQuery y de JavaScript en general, lo que hace que cualquiera, con niveles de conocimientos básicos de programación web, pueda hacer utilización de él. A pesar de eso, el libro no es lento en la forma en la que va presentando conceptos, y para aquella gente que no está divertida con la teoría y quiere poner manos a la obra: el libro está completamente planteado desde un punto de vista práctico y manos a la obra. De hecho, el libro viene con código fuente gratuito que podemos descargar para que se convierta en los ejercicios que el mismo libro propone, dándonos en los capítulos las soluciones y las explicaciones, y permitiéndonos replicar para asegurar nuestro conocimiento.

Pensé al principio que comenzar desde conceptos básicos sería un mal signo, porque seguramente estarían permitiendo malas prácticas filtrarse para explicar determinadas características, pero este libro probó que yo estaba equivocado: siempre se refuerzan las buenas prácticas (y se explica por qué) y el libro hace un esfuerzo considerable por mostrarnos la buena importancia del progressive enhancement, del cual seguramente escribiré más adelante.

Efectivamente, el libro termina en las facetas más avanzadas de jQuery, incluyendo Theming y Plugins. A estos dos les dedica muy poca longitud y detalle, en comparación al resto de las temáticas. Plugins fue cubierto, de forma implícita, en el resto del libro cuando hablaba de namespacing y scoping (también buenas prácticas) y theming fue algo que básicamente no se tocó. También se cubrió ligeramente jQuery Mobile. Estas últimas parte fueron un poquito decepcionante por lo corto de las explicaciones, pero aún así estuvieron presentes.

Notesé que el libro es sobre jQuery y no sobre JavaScript, por lo que si esperaban ver patrones avanzados de JavaScript y modularización, programación funcional, currying y cosas así… este no es su libro. Aún así, para alguien que se dedica a desarrollo frontend y especialmente alguien que quiere entrenarse en esta librería, utilizando buenas prácticas y manos a la obra, es un libro esencial.

Le doy 5 zorrinitos.

$(‘#zorrinito’).soy();

Pruebas con VS11: Día dos

async y await

Continuando con mi serie de posts e investigación sobre lo que VS11 ofrece (Parte 1), quisiera tomar una aproximación separada. Si bien la exploración es interesante, es poco apropiada cuando uno quiere aprovechar el tiempo.

Es por eso que comencé con las referencias en MSDN sobre qué hay de nuevo en VS11, que seguiremos de a partes. Pero a la vez quiero cumplir con mi promesa, por lo cual, si comenzamos sobre qué hay de nuevo en el lenguaje C# (lo siento VB, lo siento C++, soy del bando de C#), nos encontramos con la excusa para cumplir lo prometido.

Características nuevas de C#: await y async

Esto, bien sabemos, no es algo propio de VS11, sino de C# 5.0, que va de la mano con VS11 y .NET 4.5. Como MSDN lo indica, una de las primeras características es la habilidad de construir fácilmente código asíncrono. “We have to go deeper…”

Cabe aclarar que ya existía la posibilidad de escribir código asíncrono. Los callbacks y el multithreading no es nada nuevo, aunque esto es ligeramente distinto, ya que simplifican un poco la idea y esconden el trabajo sucio. Sin duda se logrará que en el futuro mucha gente no sepa cómo funciona los métodos asíncronos por detrás pero esconder complejidad es un buen paso para permitir innovación.

Digamos que tenemos un programa que factoriza números grandes, porque logramos un trabajo de criptoanalista para el FBI. Nuestro método recibe un parámetro long y nos devuelve un ISet<long> con el conjunto de factores primos que conforman este número original. Dejando de lado la matemática, sabemos que este proceso toma un rato en ejecutarse y queremos que nuestro programa lo trate de forma asíncrona. ¿Cómo se haría este trabajo de la forma tradicional?

Básicamente deberíamos definir un método que sirva de callback. El callback (también llamado continuación) es un método que el thread que trabaja en la tarea llama cuando termina para avisar que su trabajo terminó. De esta forma, podemos preparar nuestra tarea, enviarla a ejecutar, hacer otras cosas en el intermedio y ejecutar código extra cuando la tarea termina, como por ejemplo, trabajar con los resultados.

Async without async

(Ejemplo del código en Gist.GitHub: Async without async)

Esta aproximación tiene un problema muy claro: la complejidad. Estamos de acuerdo con que el código de FactorNumber debería estar separado en su propio método, pero la continuación de la llamada a FactorNumber y el resto de esa lógica son parte de una misma operación. El hecho de que estén separados en el código no es más que una obligación que debemos cumplir por las restricciones del framework para la instanciación de threads.

Las palabras clave async y await resuelven este problema.

Aquí podemos notar que la estructura del código ha cambiado un poco para dar soporte a esta característica. Por un lado, tuvimos que aislar el código que interactuará con métodos asíncronos, ya que los mismos deben devolver un tipo Task. Esto es porque devuelven un identificador de la tarea que está corriendo en background. En nuestro caso en particular, este será StartWork(), pero no estamos haciendo uso de su Task.

StartWork, siendo asíncrono, se ejecutará a la vez del resto del código, ya que no será bloqueante. Por tanto, el próximo Console.WriteLine se ejecutará, muy seguramente, al mismo tiempo que el procesamiento de StartWork ocurre. Dicho procesamiento hace una llamada bloqueante a FactorNumber, es decir, espera a que FactorNumber termine (lo cual nos permitió convertir la llamada en síncrona) y una vez que tenemos el resultado, se escribirá en consola. No era realmente necesario convertir esta llamada en síncrona de esa forma, una simple llamada a FactorNumber hubiera sido suficiente, pero de esta forma demostré que si bien el sistema espera por su respuesta suspendiendo el thread actual, sigue siendo asíncrono internamente. Eso significa que está ejecutando toda la tarea de callback que vimos antes de forma interna, y ahora nuestro código se lee fácilmente de arriba a abajo.

Confieso que debo trabajar un poco más en esto para no ensuciar tanto el código, pero por ahora parecería que el uso de las keywords exige modificar los valores de retorno y por tanto las llamadas a esos métodos deben ejecutarse de forma distinta. Eso no me agrada, porque inclina un poco la complejidad innecesaria para usar esto, pero sigue siendo una ventaja sobre la solución original.

Hagakure

El Camino del Samurai

Terminé con mi lectura actual, en este caso, el Hagakure. Hagakure Kikigaki (葉隠聞書) es el libro de origen japonés que habla, desde uno de los miembros del clan Nabeshima, sobre cuál es el camino del verdadero Samurai, basándose en una recopilación de historias y anécdotas que llegaron a Yanamoto Tsunetomo, siendo él mismo un samurai.

El libro en sí no tiene una estructura particularmente fácil de seguir, pero de alguna forma deja leer entre líneas cuál es el mensaje del camino del Samurai. En muchos punto las anécdotas recavadas se contradicen una a otra, y no tiene demasiado contexto sobre ellas. Esto significa que estaríamos mejor leyendo una versión anotada, seguramente con aclaraciones culturales e históricas que provean ese contexto necesario.

Yo comentí la equivocación de leer una versión que encontré libre en internet, específicamente una que ofrece el sitio de JudoInfo en su sección de descargas. Esta versión en particular, si bien está formateada de una forma aceptable, es una muy mala traducción al inglés del texto original, y en muchos puntos es simplemente incomprensible. Como extra, se convierte en una lectura bastante cansadora, por las gramáticas raras, la mala utilización de ciertas palabras y la repitición extrema de otras, la poca separación de conceptos y los textos largos de hombres matando a otros sin razones claras. Nuevamente, todo esto puede solucionarse con una buena traducción y una buena edición.

Me agrada mucho lo que el libro tiene que decir sobre el camino del samurai. Yo sabía que el código de honor era muy estricto, pero no había imaginado que llegaba a este punto, y de hecho, si uno toma la enseñanza básica de vivir sólo el día del presente buscando ser útil a su amo, el código de honor fácilmente se desprende de esas enseñanzas. Cometiendo el pecado de sobre-simplificar el significado del camino del Samurai, el hecho de considerar la muerte como algo inminente y determinarse a obtener resultados inmediatos es una forma de vida que estos hombres seguían.

Lo encuentro como una lectura muy interesante, y esperaba que dejara en mí una marca especial. No fue tan profunda por la mala experiencia de la lectura, pero el principio fundamental ha quedado en mi persona. Ciertamente, es una lectura que recomendaría.

Le doy 4 de 5 zorrinitos.

Soy un zorrinito samurai.

VisualEvent

Bookmarklet de visualización de eventos

Muy parecido a debugCSS que alguna vez envié, VisualEvent es también un bookmarklet que nos permite trabajar con los interiores de alguna página. En este caso, nos mostrará visualmente cuáles son los eventos asignados a los distintos elementos e incluso muchas veces el código. Muy útil para debuggear y detectar problemas de interacción con código que tenemos que corregir. Además, también para considerar cuánto JavaScript estamos usando en una página (puede que sea mucho, no?)

Soy un zorrinito JavaScript.

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.