The more astute reader may have already noticed there is subtle flaw in this system resulting in a way to keep Pinky, Inky, and Clyde inside the ghost house for a very long time after eating them. The trick involves having to sacrifice a life in order to reset and enable the global dot counter, and then making sure Clyde exits the house before that counter is equal to 32. This is accomplished by avoiding eating dots and waiting for the timer limit to force Clyde out. Once Clyde is moving for the exit, start eating dots again until at least 32 dots have been consumed since the life was lost. Now head for an energizer and gobble up some ghosts. Blinky will leave the house immediately as usual, but the other three ghosts will remain “stuck” inside as long as Pac-Man continues eating dots with sufficient frequency as not to trigger the control timer. Why does this happen? The key lies in how the global dot counter works—it cannot be deactivated if Clyde is outside the house when the counter has a value of 32. By letting the timer force Clyde out before 32 dots are eaten, the global dot counter will keep counting dots instead of deactivating when it reaches 32. Now when the ghosts are eaten by Pac-Man and return home, they will still be using the global dot counter to determine when to leave. As previously described, however, this counter’s logic only checks for three values: 7, 17, and 32, and once those numbers are exceeded, the counter has no way to release the ghosts associated with them. The only control left to release the ghosts is the timer which can be easily avoided by eating a dot every so often to reset it. Click on the YouTube video below to see a demonstration of this curious behavior:

The Pac-Man Dossier

During the 1962 season, New York Mets center fielder Richie Ashburn and Venezuelan shortstop Elio Chacón found themselves colliding in the outfield. When Ashburn went for a catch, he would scream, “I got it! I got it!” only to run into Chacón, who spoke only Spanish. Ashburn learned to yell, “¡Yo la tengo! ¡Yo la tengo!” instead. In a later game, Ashburn happily saw Chacón backing off. He relaxed, positioned himself to catch the ball, and was instead run over by left fielder Frank Thomas, who understood no Spanish and had missed a team meeting that proposed using the words “¡Yo la tengo!” as a way to avoid outfield collisions. After getting up, Thomas asked Ashburn, “What the heck is a Yellow Tango?”

The same companies that spent decades telling lawmakers that they were explicitly not guardians of the morality of the young—that they could’t be held accountable for sex, drugs and rock’n’roll, for gangsta rap, for drug-fuelled dance-parties—did a complete reversal and began to beat their chests about the corrupting influence of downloading on the poor kiddies.

Cory Doctorow

(por cierto, entrada 2¹⁰, creí que nunca iba a llegar).

Mi vuelta a España me ha permitido utilizar mucho más intensamente Spotify, y probar mucha más música que anteriormente, pero también redescubrir muchos discos que no escuchaba desde hace mucho tiempo (también tengo que decir que Spotify me falla en muchos grupos, de los que solo tiene discografías parciales, normalmente cuando se cambian a una discográfica un poco más grande que la inicial. Nadie es perfecto).

Creo que estos últimos días he conseguido recopilar diez álbumes que, en mi impresión, son los más importantes de la decada (y al ser mi impresión, casi todo es música indie y nada en español, lo que no quiere decir que no haya nada bueno en esas categorías).

Sin ningún orden especial, más que alfabético:

Arcade Fire — Funeral (2004)

El booklet del disco de debut de Arcade Fire está dedicado a tres familiares fallecidos de los integrantes del grupo (que como en parte son familia, aún es más grave). Alguna vez he leído alguna crítica que insinuaba que más familiares deberían morir para que Arcade Fire puedan repetir la maravilla que es este disco. Desgraciadamente no está en Spotify, pero sí en iTunes o Amazon.

Death Cab for Cutie — Transatlanticism (2003)

El cuarto albúm de estudio de Death Cab for Cutie. Un disco mucho más completo que sus anteriores álbumes y que les abrió las puertas de Atlantic Records, a una base de fans mucho mayor… y supongo que eso llevó a que les pidieran una canción para la banda sonora de New Moon. Pensándolo bien, quizá este disco no fuera tan buena idea. No disponible en Spotify (pero sí los discos a partir de Plans). Sí está en iTunes y en Amazon.

Interpol — Turn on the bright lights (2002)

El disco de debut de Interpol, y habrá gente que diga que Antics es mejor, y que se merecería más estar en esta lista, pero como soy yo el que escribo, pues este se queda (aunque me llamen gafapasta, cosa que nunca he llevado). Venga, adivinad que viene ahora: No disponible en Spotify ni en iTunes, pero sí en Amazon (Matador no parece tener mucho interés en la distribución digital). Parte de la discografía sí está en Spotify.

LCD Soundsystem — Sound of Silver (2007)

Segundo album del proyecto de James Murphy, mucho más concentrado que su gracioso disco de debut (a todos nos encanta Daft Punk is playing in my house, pero no se la puede tomar uno en serio). Disponible, por fin, Spotify.

Radiohead — In Rainbows (2007)

Septima maravilla en salir de la cabeza de Yorke, Greenwood y compañía. El disco es uno de los mejores de Radiohead, pero además tiene el honor de ser el disco que hizo temblar a toda la industria musical, con el curioso modelo de comercialización elegido por la banda. Irónicamente no está disponible en Spotify, ni para su descarga desde la web, aunque sí en iTunes y Amazon.

Radiohead — Kid A (2000)

Y esta es la cuarta maravilla (no quería repetir grupos, pero ambos discos son demasiado importantes como para no incluirlos). Después del éxito de OK Computer, la banda da un vuelco a su estilo y se marca Kid A, que, para mí, define al Radiohead del nuevo siglo. Kid A sí está en Spotify.

Sufjan Stevens – Sufjan Stevens invites you to: Come on feel the Illinoise (2005)

Quinto disco del artista, y segundo del ambicioso proyecto de hacer un album para cada estado. Todas las pistas están relacionadas o bien con lugares del estado de Illinois, o bien con personas que “pasaban” por allí. Illinois está en Spotify.

The Avalanches — Since I Left You (2000)

El único disco de la banda australiana The Avalanches (a pesar de que Spotify se empeñe de lo contrario). Un prodigio del sampling y un ejemplo de como hacer un increible album electrónico sin dejar fuera a nadie. Seguimos esperando el segundo disco. Since I Left You en Spotify.

The Postal Service — Give Up (2003)

En su momento pensé que este album presentaba a la banda que tendría que seguir año tras año. Por desgracia sus componentes no han vuelto a tener tiempo libre de sus otros proyectos (Ben Gibbard con Death Cab For Cutie, y Jimmy Tamborello con Dntel), pero a mí me llevó a descubrirles a ellos, y a todas sus ramificaciones, influencias, e influenciados. Otra banda que nos debe una continuación. Give Up en Spotify.

Wilco — Yankee Hotel Foxtrot (2002)

Otro album que no solo está aquí por ser una pieza musical importante, si no porque demuestra, de nuevo, que las discográficas no entienden de música. Warner no quería publicar el disco porque no le parecía comercial, los componentes del grupo compraron los derechos del album y lo pusieron en Internet gratuitamente. Después se lo llevaron a otra discográfica (que para más detalles, era filial de Warner), que se lo publicó. Fue un éxito de crítica y de ventas (es el album más vendido de Wilco). Como supondréis, con tanto lío de discográfica, no se encuentra en Spotify, aunque sí en iTunes y Amazon.

Y como habéis sido buenos, y habéis llegado hasta aquí… diez enlaces a la bahía pirata:

• Arcade Fire — Funeral
• Death Cab For Cutie — Transatlanticism
• Interpol — Turn On The Bright Lights
• LCD Soundsystem — Sound Of Silver
• Radiohead — In Rainbows
• Radiohead — Kid A
• Sufjan Stevens — Illinois
• The Avalanches — Since I Left You
• The Postal Service — Give Up
• Wilco — Yankee Hotel Foxtrot

El Jueves estuve en el Google Chrome Hackathon Madrid (junto con Alberto), y por programar y presentar una extensión (Video5) me dieron una camiseta, que cambié a Alberto por su puzzle (la extensión de Alberto es YouTube Video Kit).

El puzzle tiene unas 500 piezas. Los bordes y la parte superior del puzzle fueron sencillos, pero la parte central (el código bidimensional) es más cuestión de mirar a la forma de la pieza más que al dibujo. Al final, esta mañana lo he terminado (ayudado por mi hermano y mi hermana a ratos) y descubierto el contenido: una extensión para Google Chrome, que en ciertas páginas activa un page action que te lleva a un documento de Google Docs. Desgraciadamente este documento parece que sólo es accesible a empleados de Google (o gente que tenga un correo terminado en google.com), por lo que no puedo llegar más allá.

Pensándolo así debería haberme quedado con la camiseta ¿no?

El video de la charla está disponible y el ponente ha recopilado enlaces y las transparencias.

Tras el salto, mis notas (en horrible español técnico y con enlaces).

Un servidor no es un ordenador de escritorio: necesita ser durable, mantenible y escalable.

DEBES utilizar RAID hardware. Una de las ventajas más grandes del RAID harware es la caché protegida por la batería (las escrituras pendientes no se pierden debido a un fallo de corriente). El RAID hardware permite además hacer write-back en vez de write-through. La diferencia entre los dos es escribir a la velocidad de la memoria frente a escribir a la velocidad del disco. También necesitas discos que se puedan cambiar “en caliente”. Si pierdes un disco no quieres tener que parar el servidor para sustituirlo.

DEBES tener una consola de gestión remota REAL (no se refiere a SSH o similares). Necesitas algo que se ejecute cuando el sistema operativo no se está ejecutando. Algo como Dell OpenManage.

DEBES tener fuentes de alimentación redundantes. Las fuentes de alimentación contienen piezas físicas, que, como los discos duros, pueden fallar. También es recomendable utilizar diferentes circuitos para las diferentes fuentes de alimentación.

NECESITAS una CPU para servidores, no para escritorios. Buena cache L2 (de segundo nivel) y gran ancho de banda para memoria. Actualmente, para servidores, Nehalem son los procesadores a instalar. Cuentan con controlador de memoria en el chip, pero no se debe llenar los canales de memoria con DIMMs porque cada uno ralentiza el canal.

Para sistema operativo no hay discusión: una distribución de Linux con soporte a largo plazo (LTS, long term support). Dos posibilidades: Red Hat Enterprise Linux (publicada en el 2007 y con soporte hasta el 2014) o Ubuntu Server LTS (publicada en el 2008 y soportada hasta el 2013). La idea es que nunca se necesita actualizar el sistema operativo de un servidor una vez instalado, únicamente aplicar las actualizaciones de seguridad.

NO instales una distribución al completo (nada de XWindows en un servidor). Instala únicamente lo que necesites. Paquetes extra significa bugs extras, problemas de seguridad extra y trabajo de mantenimiento extra.

Utiliza gestión de volumenes lógicos (LVM, Logical Volume Management), de forma que puedas añadir más discos duros físicos sin tener que crear nuevas particiones e incluyendo el nuevo espacio en las particiones ya existentes.

Utiliza ext3 como sistema de ficheros: muchos más usuarios significa que los problemas que puedas llegar a tener pueden haber sido resueltos antes. Utiliza la opción noatime cuando montes particiones, de otra forma cada lectura del disco significa una escritura para el tiempo de acceso, lo que empeorará el ancho de banda del disco y envenenará la cache.

Utiliza /etc/hosts y no dependas en el DNS. Todos los servidores (bases de datos, ficheros,…) deben poder ser resueltos sin necesidad de utilizar DNS.

Utiliza iptables incluso si tienes más líneas de defensa (como firewalls hardware) o tu servidor no esta directamente conectado a Internet.

Redirige el correo electrónico del root a un correo real. Muchos programas envian correos a root, sin la redirección los correos podrían perderse durante meses o años.

Utiliza Chef.

Para desplegar aplicaciones utiliza Apache y Passenger. La configuración del host virtual de Apache y la configuración de Passenger deben estar en archivos diferentes. Activa el GlobalQueue de Passenger (esta opción utiliza una única cola, en vez de una cola por worker, mejorando el rendimiento en el caso de peticiones largas). Modifica MaxPoolSize dependiendo de cada servidor y cada aplicación: aumentalo hasta que el servidor empiece a necesitar swapping. Establece el PoolIdleTime a 0 para que los worker no se desactiven cuando esté “ociosos” (y vigila que no existan leaks por procesos de larga duración).

En vez de utilizar el Ruby proporcionado por la distribución utiliza Ruby Enterprise Edition. La principal ventaja es un recolector de basura configurable. Evan Weaver tiene un buen wrapper optimizado para procesos de larga duración.

Comprueba tus backups (restaura desde el backup para comprobarlo). El único backup en el que puedes confiar es el que hayas comprobado que funciona más recientemente. Si no puedes permitirte perder una semana de datos, comprueba tus backups cada semana.

NECESITAS Gigabit para tu red interna, incluso si tu upstream no dispone de esa velocidad (lo más probable). Lo que pretendes es reducir la latencia dentro de tu red (cuanto más ancho de banda, menos tardará el servidor de bases de datos en proporciona la información al servidor de aplicaciones). Hay soluciones baratas por unos $100 (Linksys). El control de flujo (flow control) evita problemas cuando tu red Gigabit se encuentra con tu red Megabit (problemas de packet dropping).

Monitoriza. Dos tipos: disponibilidad y eficiencia. Nagios es código abierto. Pingdom es barato ($10/mes, con push notifications para el iPhone). Tiene la ventaja de ejecutarse en una red diferente a la tuya y comprobar la disponibilidad “al mundo” de tu aplicación. New Relic RPM tiene versión gratuita y versión de pago (cara), pero es muy buena herramienta.

¿Por qué no Nginx?
Es menos estable y “peor” soportado. Frente a Apache, Nginx sirve con mucho menos gasto de CPU contenido estático, pero si el problema es este, posiblemente deberías estar sirviendo el contenido estático desde Amazon S3.

¿Capistrano sí o Capistrano no?
Capistrano no es abandonware pero si doneware y posiblemente no se actualice. Se debe utilizar un sistema de despliege automatizado mediante scripts. Capistrano sigue siendo una opción muy buena, pero no es la única y existen muchas alternativas.

¿Seguridad e iptables?
Sí es la última línea de defensa y tienes firewalls hardware delante, trata de hacerlo simple: cierra todos los puertos, abre HTTP, abre SSH para algunos rangos, y cosas como DNS… Si no puedes restringir SSH a ciertos rangos, limita el número de conexiones desde una subred para evitar ataques de diccionario.

¿No es el controlador RAID un punto de fallo único?
Sí, es un punto de fallo único (single point of failure). Si necesitas evitar esto, será necesario un NAS o similar.

¿Se debe utilizar Monit o God?
No es necesario para Passenger, pero es necesario para cosas como BackgroundJob, Workling,… También es necesario rotar los archivos de registro (log), de otra forma crecerán hasta llenar el disco duro y harán fallar al servidor. Haz que el servidor no requiera intervención humana.

¿Se debe aplicar todo esto a hostings gestionados?
La parte de hardware es irrelevante, pero se debe aplicar la parte de software siempre que se pueda. Mantén tus propios backups, a pesar de que el hosting realice backups de tus datos. Para tu propio servidor no utilices virtualización, proporciona mucha flexibilidad, pero el precio en eficiencia no lo vale.

¿Se debe compilar desde código fuente?
Utiliza siempre que puedas soluciones estándares proporcionadas con la distribución. Compila desde código únicamente cuando sea necesario (Ruby Enterprise Edition, versiones modernas de Git). Deberias “paquetizar” tus productos para desplegar nuevos servidor más rápido y más estandarizadamente. Muchas veces puedes elegir paquetes de la distribución más moderna y re-compilarlos tu mismo para una versión anterior.

¿Por qué Long Term Support?
Quieres construir el servidor, lanzar tu producto, y no volver a tocar el servidor de nuevo.

¿Se debería utilizar JRuby?
En principio no. No es tan estándar y tan utilizado como el Ruby de Matz. Además consume más memoria. En la práctica no es competición para Ruby en entornos de producción.

Hace unos días me decidí a limpiar el repositorio que yo utilizaba para el desarrollo (el repositorio compartido por Javier era Subversion, y yo utilizaba git-svn para manejarlo) y publicarlo en GitHub como código abierto, esperando que a alguién le sea útil (al menos como herramienta educativa de cómo no escribir código). Tras el salto describiré algo más el contenido del código y las ausencias.

Primero una disculpa, el código no es el código completo del que dispongo, y la historia contiene algunos saltos (sobre todo al principio). La razón es sencilla: el código de RNE Radio paso a ser propiedad de RTVE, y, aunque nosotros tenemos aún la propiedad de todo el código anterior al contrato (o al menos así lo entiendo yo), he preferido no publicarlo, por si los abogados se ponen nerviosos. De forma que no encontrareis el código o el artwork de RNE Radio en el repositorio (o eso espero). También me he cargado cosas como la web y las versiones archivadas de los productos que enviamos a la App Store, porque principalmente sólo ocupan espacio. A parte de eso, creo que está el resto (un poco modificado para que siga compilando y funcionando como el primer día).

¿Qué podemos encontrar? Pues como primer destacado, RRQAudioPlayer.[hm], RRQM3UParser.[hm], RRQPLSParser.[hm] y RRQShoutcastAudioPlayer.[hm] son los que hacían sonar a todos los programas (técnicamente se podrían haber reutilizado parte de los controlodares, pero según las aplicaciones empezaron a divergir, tener diferentes controladores fue una facilidad, en vez de un incordio, aunque aún hay bastante copia-pega entre ellos). RRQM3UParser y RRQPLSParser son simples parsers para los formator M3U y PLS, que obtienen la lista de archivos a reproducir (normalmente MP3), mientras que RRQAudioPlayer y RRQShoutcastAudioPlayer son los que descargan el stream, lo decodifican y lo envían al sistema de sonido del dispositivo. El primero está basado en uno de los ejemplos de Apple y muchas otras referencias desperdigadas por Internet. El segundo es una ampliación del primero para escuchar streams Shoutcast con meta-información incluida en el stream (como por ejemplo el de Radio FI). A este último, lo único que le quedaría por hacer es conseguir “sincronizar” la aparición de la meta-información con el sonido en sí (algo que busqué y rebusqué, y que creo que sigue sin ser posible).

Para Radio FI-FM necesitabamos una implementación de (parte) de la API de Last.fm, que está contenida en los archivos FILastFMDataProvider.[hm], FIImageProvider.[hm] y FI*Info.[hm]. Todo porque pensabamos que una aplicación en la que únicamente sonara sonido iba a quedar sosa (aunque siempre supimos que la gente únicamente miraría a la pantalla de vez en cuando… en el caso de que alguien utilizase la aplicación). Luego descubrimos que puedes poner a volar unas notas musicales que calientan el dispositivo a más no poder, y la gente no protestaba.

En el repositorio también está el código de COPE Radio, que nunca fue publicada, y que tiene una característica que me divertí mucho programándola: la selección de la cadena con un botón que se puede arrastrar con el dedo y rebota. Es una tontería, pero me gusta (la implementación está en COPENeedleView.[hm]).

Luego tenemos algunas clases de utilidad, como RRQFileLogger.[hm] para almacenar los logs en un archivo en el dispositivo, RRQNSString+Version.[hm], para comprobar si una versión es mayor, menor, igual o compatible con otra (aunque creo que este código finalmente no fue utilizado), y RRQVolumeView.[hm] que se encargaba de modificar el slider de volumen por defecto del sistema operativo en algo que nos gustaba más (y en un principio a hacer que ese slider proporcionando por el sistema operativo mostrara los cambios de volumen realizados con los botones físicos del dispositivo, bug que Apple eliminó en algún momento posterior). Finalmente encontramos a isArrrrr.m, que nunca entró en producción (estaba pensado para France Radio 2.0), un intento de un sistema antipiratería recopilado de comentarios en foros y páginas de Internet, mezclado con un poco de paranoia.

Hay, además de master, otras dos ramas con algún código interesante de France Radio 1.5 (en el cuál se incluían todas las cadenas de Radio France Bleu) y France Radio 2.0 (nunca publicado, y que iba a incluir muchas más cadenas francesas, una semilla para un posible “Ñ” Radio). En estos dos, según el número de cadenas aumentaba, vimos que la solución del archivo plist empezaba a ser un impedimento, y empezamos a utilizar SQLite mediante SQLitePersistentObjects (proyecto abandonado a su suerte desde la aparición de Core Data en el iPhoneOS 3.0, pero muy útil para los días del 2.0). Seguramente no son los controladores más limpios basados en una base de datos, pero hay algunas ideas ahí dentro que quizá merezca la pena mirar (como el timeout para volver al controlador anterior).

Pues creo que eso es un resumen del código presente (que muy posiblemente sea todo el código que existirá relacionado, por mi parte). Si alguien quiere y puede hacer algo con él, al menos seguirá teniendo utilidad.

Aún no he visto la película (que promete), pero si podéis echar una mano a la banda sonora la recomiendo (y si la compráis por iTunes tiene bonus tracks, entre ellos una cantada por de Zooey y una versión de Here Comes Your Man cantada por Joseph Gordon-Levitt).

Y como homenaje postumo, una pregunta sencilla, ¿en qué dos películas de John Hughes aparecia la canción en cuestión?

Esta mañana me he cruzado con Cheat for iPhone/iPod touch, una aplicación para acceder a los cheat sheets de cheat.

Hace meses (Enero-Febrero) me puse a programar una aplicación de similares características, pero nunca saqué tiempo para terminarla (de hecho, casi no se puede decir que esté “empezada”) y se quedó en el limbo. Como ya no tiene mucho sentido seguir desarrollandola (el poco mercado que tuviese la aplicación acaba de ser ocupado) la publico como código abierto (siempre me rondó la idea por la cabeza, pero también quería tenerla más avanzada).

El código está en GitHub (aunque no se porqué aún no aparece), y tendréis que admitirme que el icono de mi versión es (al menos) infinitamente superior .