Montar un servidor REST (I)

BLA, BLA, BLA, …

Cuando uno se quiere a poner a programar un juego para móviles, social, con partidas para varios jugadores y de mucho éxito (¡ja¡), lo primero que uno quiere hacer es ponerse a programar la lógica del juego, el tablero, la interacción con este, etc. Apetece algo menos desarrollar el flujo entre pantallas, la pantalla de configuración, el login,… es decir, la fontanería. No es tan “cool”. En lo último que un se piensa meter es el alcantarillado sucio y oscuro del servidor que dará servicio a nuestro juego de éxito. Si uno busca en el diccionario de la programación de juegos en antónimo de “cool”, aparece la palabra “servidor”.

Pero en seguida que uno se pone a programar ese gran éxito, te das cuenta que apenas puedes avanzar si no tienes un servidor contra el que validar usuarios, crear partidas, retar adversarios, configurar notificaciones PUSH, … Un auténtica lata. Así que aquí me encuentro, abandonando la chachi-interfaz de mi super-exito para buscar la mejor forma de escribir un servidor, de la forma más rápida posible y, ya que estamos, que me sirva para cualquier plataforma del mundo-mundial (™) y que pueda reaprovechar para futuros hits. Puedo uno inventarse una personalísima interfaz, con un protocolo propio, o puedo uno aprovechar que ya existe la rueda y montar un servidor REST(casiful). El problema es que puede que usted, como yo, se encuentre con que no tiene ni paj pueñetera idea de cómo montar eso. Después de curiosear por los blogs de otros, ver librerías, framework y más frameworks, uno decide la tontería de escribirse a pelo un mini-framework (o mini-plantilla en realidad) en PHP desde cero; ¡como un machote! Evidentemente como novato habré cometido mil barbaridades, estoy abierto a correcciones y estoy deseando que me las hagan.

Lo primero es explicar rápidamente y sin aburrir de que va eso del REST. Representational State Transfer es un conjunto de convenciones que nos permite interactuar con recursos (Datos, entidades, objetos, …) por medio del protocolo HTTP en un entorno cliente servidor. Es un protocolo no basado en estados por lo que no hay que gestionar sesiones y en el que cada recurso individual o conjunto de recursos puede ser accedido mediante una URI. Para que no entendamos, si quiero leer un conjunto de partidas en mi super-juego, tendré algo así:

http://api.superhitdelamuerte.com/partida

Y si quiero obtener los datos de la partida cuyo ID es 3454, accedería  a la dirección:

http://api.superhitdelamuerte.com/partida/3454

En función de la operación a la que quiera acceder, enviaremos los parámetros en la URL o en el cuerpo de la petición y haremos esta por unos de los métodos contemplado en el protocolo HTTP. Más adelante veremos de nuevo esto.

La respuesta de un servidor REST normalmente es dada en JSON, XML, HTML o algo similar. El cliente debe conocer el formato de la respuesta para poder manejarla.

Hasta aquí una explicación simple y probablemente insuficiente para tus ansias de conocimiento. Te invito a leer más sobre el tema

DÓNDE CARJ PUÑETAS ESTÁ EL CÓDIGO.

Bueno, vamos a la implementación que para eso estamos aquí. Lo primero que vamos a necesitar es escribir un .htaccess (lo siento, no me he puesto a mirarlo para IIS) que haga que toda las peticiones a nuestro servidor sean redirigidas hacia nuestro index.php. Desde allí iremos contruyendo toda nuestra infraestructura. Yo voy a crear subdominios específicos para las api de cada mega-hit que escriba del tipo api.mega-hit.com, de modo que tenga bien separado la API del resto de la web del proyecto, en una carpeta física separada, con sus reglas mod-rewrite particulares. Mi .htaccess tiene este aspecto:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase / 
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php [QSA]
RewriteRule .* - [E=HTTP_CONTENT_TYPE:%{HTTP:Content-Type},L] 
</IfModule>

Las primeras 5 reglas se encargan de decirle a Apache que redirija todas las peticiones HTTP al index.php. La última regla nos permite acceder al campo de cabecera “Content-Type” desde PHP mediante $_SERVER[‘HTTP_CONTENT_TYPE’].

Una vez que toda petición llega a index.php, debemos analizar la URL de estas para saber que recurso nos están solicitando y si nos están pidiendo una en concreto o un conjunto (recibimos un ID, aunque la desición de hacer una cosa u otra no la tomamos aquí). Debemos averiguar también que tipo de petición es (GET, POST, SET, DELETE) y el formato (content-type) en el que debemos devolver la respuesta, si decidimos que vamos a aceptar más de uno. Yo he escrito mi código para responder con datos en JSON o XML, ya que solo está pensado para que estos sean consumidos por programas y no por humanos.

<?php
// Separamos la URI de los parámetros
$uri= explode('?', $_SERVER['REQUEST_URI']);
// Troceamos la URI: [0] => dominio, [1] => Recurso, [2] => ID
$parts = explode('/', $uri[0]);

// Tipo de petición: GET, POST, PUT, DELETE
$request_method = strtolower($_SERVER['REQUEST_METHOD']);
// Respuesta que vamos a dar.
$content_type = (strpos($_SERVER['HTTP_CONTENT_TYPE'], 'json')) ? 'json' : 'xml';
$data = array();
// Si la petición ha sido de tipo PUT o POST, los datos vienen
// en el cuerpo de la petición. En caso contrario vinen en la
// misma URI.
if ($request_method == "post" || $request_method == "put") 
{
   $values = file_get_contents('php://input');
   parse_str($values, $data);
} 
else 
{
   $data = $_GET;
}

// Si hemos recibido un nombre de recurso...
if(count($parts)>1) {
   // Creamos un objeto de la clase "recursoController"
   // (Ya veremos cómo es esta clase y qué cosas hace)
   $classname = $parts[1]."Controller"; 
   $object = new $classname();

   // Si hemos recibido el ID, lo pasamos al objeto.
   // En caso contrario le pasamos NULL
   $object->ID = isset($parts[2])?$parts[2]:NULL;
   // Pedimos al objeto que procese la petición
   $object->processRequest($request_method, $content_type, $data);
} // No hacemos nada en caso contrario (else)
?>

Así de simple. La parte más dura del trabajo la realiza los objetos de las clases “recursoController” y “recursoModel”. De eso nos ocuparemos en próximas entregas. Lo breve, si bueno, dos veces breve.

Una reflexión sobre la Universidad en España

Estoy leyendo las memorias de un conocido autor que durante un tiempo fue investigador y profesor universitario. En un par de capítulos describen sendas situaciones que les serán muy familiares a todo aquel que pertenezca la mundo docente e investigador universitario. El primer párrafo que reproduzco tiene que ver sobre la financiación de la investigación:

Cada vez más, la investigación universitaria era financiada por becas del gobierno. Estas becas, por lo general, duraban un año. Cada año, si se deseaba que la financiación continuara, el profesor que dirigía la investigación tenía que solicitar su renovación y presentar una justificación para ello.

Siempre he pensado que las consecuencias de esto eran perniciosas. En primer lugar, el profesor que deseaba una beca gubernamental debía elegir un tema que pareciera digno de interesar al gobierno hasta el punto de que éste invirtiera fondos en él. Los científicos, por tanto, se concentraban en los campos que eran rentables y dejaban las demás áreas sin estudiar. Esto significaba que dichos campos estaban sobrefinanciados, de manera que se perdía mucho dinero, mientras que las partes olvidadas de la ciencia podrían haber producido algún descubrimiento importante si no se hubieran dejado de lado.

Además, la dura competición por los fondos gubernamentales aumentaba las probabilidades de fraude, ya que los científicos (seres humanos al fin y al cabo) intentaban mejorar o incluso inventar los resultados de los experimentos a fin de poder hacerse con el dinero.

Otra consecuencia del sistema de becas es que se dedica el segundo semestre de cada año a la preparación de documentos relacionados con la renovación de la beca, en vez de centrarse en la propia investigación.

Para terminar, los escalones inferiores de los grupos de investigación, cuyos salarios son pagados con las becas en vez de con los fondos de la universidad, viven en un continuo estado de inseguridad. Nunca saben cuándo se interrumpirá la renovación y les pondrán de patitas en la calle.

Esta situación provoca en la actualidad que la producción científica esté afectada por los vaivenes, de la moda, como si los científicos fueran adolescentes. Cuando a la Unión Europea le da por apoyar la investigación de temas relacionados con la salud, todos nos volcamos en producir artículos que rocen la salud aunque sea de manera forzada (Es un ejemplo, la UE apoya diversas áreas simultáneamente). Cuando la moda sea el grafeno, todos nos volcaremos con él.

En otro capítulo del libro se habla sobre la “articulitis” o afección que aqueja a los profesores universitarios en busca de currículum, cuyo síntoma principal es la secreción compulsiva y febril de artículos científicos (muchas veces intrascendentes):

Un función importante, incluso la principal, de un investigador era escribir artículos sobre el trabajo que estaba haciendo y conseguir que se publicaran en las revistas apropiadas. Cada uno de lestos artículos es una “publicación” y las esperanzas de un científico para ascender y adquirir prestigio se basan en la calidad y cantidad de sus publicaciones.

Por desgracias, la calidad de una publicación es algo difícil de valorar, mientras que el número es muy fácil de determinar. Por tanto, se tendía a juzgar sólo por el número y esto hizo que los científicos escribieran muchas publicaciones preocupándose muy poco de la calidad.

Aparecían publicaciones con apenas nuevos datos que merecieran ser considerados una novedad. Algunas se dividían en partes y cada una se publicaba por separado. Otras eran firmadas por cualquiera que hubiera tenido algo que ver con el trabajo, por muy de refilón que fuera, ya que contarían como una publicación para cada uno de los autores citados. Algunos científicos de categoría superior insistían en poner su nombre en todos los artículos que producían sus departamentos, aunque no hubiesen tenido nada que ver con el trabajo.

Para evitar valorar la cantidad frente a la calidad, se han creado los índices de impacto, las clasificaciones de publicaciones, etc. Ultimamente incluso se ha ligado el número de clases que le corresponde dar a un profesor a la calidad y cantidad de su producción científica.

Parece que los problemas vienen de lejos. ¿Pero desde cuán lejos? Bueno, el autor de estos textos tan actuales no es otro que Isaac Asimov. Aparecen en sus Memorias, escritas a finales de los 80. Los acontecimientos que narran son de hace más de 60 años, de alrededor de 1949-1951. Si en 60 años el sistema no ha cambiado y tiene alguno de los mismos problemas, algo estamos haciendo mal.

Casio VZ-8M

La semana pasada me llegó un nuevo “chismito” para hacer sonidos raros con la guitarra. Se trata de un sintetizador digital de finales de los 80 del siglo pasado en formato rack: Casio VZ-8M. Pertenece a la serie de sintetizadores VZ de Casio, que sustituía a la serie CZ. Todos estos sintetizadores utilizaban la tecnología desarrollada por Casio llamada síntesis por distorsión de fase, su respuesta a la síntesis por modulación de frecuencias desarrollada por Yamaha, con su famosa serie DX.

Unpacking Casio VZ-8M

El módulo que he comprado es el menor de la serie en cuanto a prestaciones, pero tiene un modo de funcionamiento especialmente pensado para ser usado con guitarras MIDI. Se puede asignar una “capa” de sonido de las 8 disponibles (operadores) a un canal MIDI diferente. Las guitarras MIDI normalmente pueden configurarse de forma que cada cuerda envíe las notas por un canal diferente. Un ejemplo de uso lo he encontrado en este vídeo.

Unpacking Casio VZ-8M

Unpacking Casio VZ-8M

Unpacking Casio VZ-8M

Y aquí una primera prueba rápida pasando la salida del Casio VZ-8M por un Yamaha REV100. Algún día aprenderé a tocar un teclado. Estoy deseando poder probarlo con la guitarra.

Usar FCB1010 como teclado MIDI de pie

Para controlar mi Boss GX-700, un Roland GR-9 y un Tube Works Real Tube II utilizo una “pedalera” MIDI FCB1010 de Behringer. Con cada uno de los pulsadores de pie se pueden enviar hasta 5 cambios de programa, dos comandos de control y una nota MIDI, además de poder asignar cambios de control a los dos pedales de expresión y poder conmutar dos relés (ideal para cambiar de canal un amplificador o mi previo Real Tube). Desde que lo compré me preguntaba si era posible emitir notas para que el sintetizador GR-9 sonase de fondo mientras tocaba algo con la guitarra. Es posible y no demasiado complicado.

Lo primero que hay hacer es planificar que notas queremos que suene en cada pedal. Yo elegí la siguiente configuración:

Los números que se muestran sobre las teclas corresponden a la numeración MIDI de las notas. Yo he escogido una octava algo baja, más o menos en la tesitura de un bajo, para poder sacar sonidos gruesos de sintetizador con la GR-09.

A continuación tenemos que escoger un banco que no usemos del FCB1010, pues lo vamos a ocupar entero. Yo elegí el banco 9. Una vez situados en el banco que vamos a programar, pulsamos el pedal 1 y seguimos los siguientes pasos:

  1. Pulsamos durante unos 3 segundos el pedal DOWN (el de bajar un banco). Veremos que se apagan los dígitos de la pantalla y se encienden los led SWITCH1 Y SWITCH2.
  2. Pulsamos el pedal UP (el de subir un banco). Ahora podemos configurar las funciones MIDI asignadas a ese pedal. Nosotros desactivaremos todos los cambios de programa y comandos de control y activaremos el envío de nota, como explico en los siguientes pasos.
  3. Si el led del pedal 1 está encendido, hay que pisarlo y mantenerlo así hasta que se apague. Si está apagado no tenemos que hacer nada.
  4. Repetimos el proceso (apagado) para los pedales 2 a 9.
  5. Si el led del pedal 10/0 está APAGADO, hay que encenderlo. Al revés que los anteriores. Para hacerlo lo pisaremos y mantendremos pulsados hasta que se encienda.
  6. Pulsamos brevemente el pedal 10/0 para que se ponga a parpadear su led. Eso significa que podemos editar el parámetro del comando. En este caso es la nota que ha de enviar. Veremos que también se ha encendido la pantalla numérica.
  7. Con el pedal de expresión A buscamos el valor que hemos elegido para el pedal. En este caso debemos buscar el valor 36. También podemos “escribirlo” pulsando los pedales 3 y 6 sucesivamente.
  8. Pulsamos el pedal UP.
  9. Pulsamos el pedal DOWN durante unos segundos hasta que volvamos al modo de funcionamiento normal. Veremos que vuelve a mostrarse el número de programa en la pantalla numérica (el 99).
  10. Repetimos el proceso para cada “tecla” de nuestro pedal, variando únicamente el valor asignado al evento NOTE-ON (36,37, 38, …)

Al pulsar cada uno de los pedales configurados así, le FCB1010 envía un evento MIDI NOTE-ON. Cuando levantamos el pie se envía un evento NOTE-OFF.

Hay que asegurarse de que los eventos de nota se envían por el mismo canal MIDI del dispositivo que va a generar el sonido. Si no recuerdo mal yo tengo configurado el GR-09 para recibir por el canal MIDI 6, para poder diferenciar los mensajes de cambio de programa que envío a este de los que envío al GX-700. En la configuración global del FCB1010 tenemos que indicar que los cambios de nota van por el canal 6 (en mi caso). Esto se hace así:

  1. Con el FCB1010 APAGADO, pulsamos el pedal DOWN. Sin soltarlo, encendemos el aparato. Con esto entramos el modo de configuración global.
  2. Pulsamos el pedal UP para pasar a la edición de canales MIDI.
  3. Pulsamos el pedal 10/0 para programar el canal de los eventos NOTE-ON y NOTE-OFF. El led del pedal se pondrá a parpadear.
  4. Pulsamos de nuevo el pedal UP. Se iluminan de nuevo los dígitos, y se enciende el led MIDI CHAN.
  5. Con el pedal de expresión A o “escribiendo” con los pedales numéricos, seleccionamos el canal midi (1-16). En mi caso escribo 6.
  6. Pulsamos de nuevo el pedal UP.
  7. Pisamos el pedal DOWN y lo mantenemos pulsado hasta que volvamos al modo normal, grabando así el cambio de canal MIDI.
Espero no haberme dejado nada. Os dejo un video algo malo de una prueba rápida en la que he usado algunos sintetizadores software incluidos en el GarageBand de Apple.

Hornillo DIY

Este es mi primer intento de hacer un hornillo de camping con los fondos de dos latas de cervezas de aluminio. En el interior he puesto lana de vidrio como recomiendan algunos que lo han construído. Lo más trabajoso es conseguir que encaje un fondo dentro de otro. Ahora me tengo que construir un soporte para el cazo con un alambre grueso.

En esta prueba he usado alcohol de 96º. El de 70º no sirve. Creo que me voy a hacerme alguna herramienta para facilitar la construcción y así fabricar hornillos en serie 😀

Trabajar duro “offline”

En eso estamos señor Bonilla:

A lo mejor, en vez de tanto Twitter, blog y demás sandeces online, salir ahí fuera y rompernos el culo offline por nuestro proyecto debería ser una de nuestras primeras opciones, no la última. Al fin y al cabo, las historias de startups con final feliz, sin que hayan tenido que luchar en las trincheras, sólo pasan en las películas y en los artículos de Techcrunch.

Señores: me declaro en guerra

Cuando alguien dice las cosas tan claras y uno está tan completamente de acuerdo, lo mejor es no añadir nada:

Estamos en guerra contra una clase política que nos defrauda día sí y día también, que no gobierna para nosotros sino para los intereses de otros, y unos medios de comunicación cómplices y sumisos que generan una sensación de alarma general que empeora la situación.

Estamos en guerra contra una falsa Industria de la informática dirigida por botarates que siguen intentando competir con precio y comidas de tres platos, copa, café y puro en vez de con originalidad e innovación.

Estamos en guerra contra esa inmensa masa de técnicos mansos y adormecidos, que se quejan de la situación y no hacen nada por remediarlo.

Estamos en guerra contra esa comunidad de voceros de medio pelo, falsos gurús, ninjas del social media, aceleradoras que desaceleran, venture capitalists que no saben que significa venture y mucho menos pronunciarlo,entrepeneurs de salón y parásitos subvencionados y de subvenciones.

Pero, por encima de todo, estamos en guerra con nosotros mismos. Por distraernos todos los días con lo que otros dicen, pero no hacen.  Por tener miedo de hacer lo que queremos hacer y por haber tardado un par de años en reunir el valor para hacerlo.

Por primera vez, uno de nuestros referentes, uno de nuestros ejemplos a seguir, alguien que lleva generando riqueza desde este país y para este país desde hace muchos años, nos ha confesado que se plantea dejar una España estropeada por unos y empeorada por otros. Esto nos ha abierto los ojos: estamos en guerra.

hemos decidido luchar.

Luchar de la única forma que sabemos: trabajando. Y no trabajando en cualquier cosa, sino en proyectos que nos permitan ganar terreno al enemigo, aumentando la productividad de nuestra gente o exportando fuera.

Nos da igual lo que digan las noticias, los periódicos, los telediarios, Standard & Poors y los blogs de expertos y agoreros. No leemos ninguno.

Programamos. Diseñamos. Trabajamos.

Todas las semanas contribuiremos a la lucha con un post, una utilidad web o un avance en nuestros proyectos.

Luchar hackeando el sistema. Un sistema donde no se puede entrar en política y alcanzar un puesto de decisión sin perder la inocencia por el camino y deber demasiados favores.

Participaremos en Abredatos este año. Porque no es una opción, es nuestra obligación como ciudadanos. Porque tenemos el conocimiento y la tecnología para hacerlo. Porque hay demasiados indultos del Gobierno y empresas públicas con Directores Generales puestos a dedo que nadie conoce.

España no son ellos, ni los seguidores de la doctrina del “que cada palo aguante su vela”, ni los Poceros, ni los que dicen que para hacer algo hay que irse a Silicon Valley, ni el que justifica el fraude o lo aplaude.

Nosotros creemos que nuestro país es otra cosa y lucharemos por recuperarlo. Sin chovinismo ni nacionalismo. Con humildad y respeto.

Somos parte de la resistencia. ¿Y tú?

Fuente: http://www.bonillaware.com/weareatwar