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 .

Pero por suerte, cualquier codigo publicado bajo la GPL no puede “cerrarse” retroactivamente, así que he decidido publicar la última versión del código de la que disponía. Como extra he decidio también añadir el parche que proporcioné al desarrollador en su día y crear una rama con mi código de reverse geocoding integrado.

Obviamente mi elección para compartir el código era GitHub, pero antes de hacerlo me he decidido a hacer una búsqueda rápida a ver si alguien tenía revisiones más modernas o más antiguas que la revisión que yo tuve la suerte de descargar del repositorio (maldita la hora que decidí descargarlo con el cliente de Subversion en vez de utilizar git-svn), y para mi sorpresa he encontrado que en el mismo GitHub había una persona que tiene una copia de todo el repositorio hasta más o menos Enero de este año (una pena que no siguiera actualizandolo). Así que ha sido forkear, clonar en local, copiar mi versión encima, y reenviar. No es la mejor historia del código, pero al menos está una de las revisiones más recientes del código (revisión 1726, del 15 de Marzo).

Personalmente no me voy a dedicar a mantenerlo, aunque quizá le haga el par de cambios que le propuse al desarrollador hace unos meses, pero si alguién tiene interés, sería un gran punto de partida para el infinitésimo cliente de Twitter en la App Store (o quizá modificarlo para que sea utilizable en identi.ca y otros sitios basados en Laconica).

PD: No se lo digaís al desarrollador del TwitterFon oficial, pero si algún día decide aplicarle el parche que le envié (y que debe tener en el correo), me da la impresión que su código quedaría manchado de GPL y tendría que al menos liberar esa versión ¿no creéis?

PD: Por si alguien quiere ayudar, las propuestas que le hice al desarrollador era permitir utilizar el texto de la localización (sobre todo la versión textual que se consigue con el reverse geocoding) como texto del tweet en sí; y la segunda era que en vez de recoger todos los tweets hasta el último conocido por Twitterfon se detuviera en el primer tweet del usuario (suponiendo que ha leído todos hasta el punto en el qué envió algo por última vez).

Gravity es un pequeño no-juego para el iPhone con física realista gracias a Chipmuck utilizando los acelerómetros para determinar dónde es “abajo”.

Código disponible en mi repositorio en GitHub.

Funciona perfectamente. La aplicación funciona perfectamente… y además es la radio de mi facultad!! =P

abustamante (España)

Más. Buena app me gustaría con mas estaciones

Youtubero (México)

No es un buen canal. Una sola cadena y no noruega. [interpretación basada en la traducción de Google]

Hoolo (Noruega)

Ace!! Very useful! And first review woop-woop!!

StarsAreBlind (Reino Unido)

Cool Hgggggggggg

~*Steve*~ (Estados Unidos)

No Worst ever

Z g (Estados Unidos)

Pathetic It’s freekin Spanish their are english people too horrible they should pay u for it

Tejdjrjhrjgijejrjdjjjj (Estados Unidos)

needs improvement it doesn’t let you chose different genres of music and there’s no next button pandora is much better

nkarls (Estados Unidos)

No It’s gay

Drmmer (Estados Unidos)