Smultron

Smultron Logo
Hace años que uso un pequeño pero potente editor de texto para Mac OS X llamado Smultron. En su día fue gratuito y ha ido pasando de equipo a equipo gracias al maravilloso asistente de migración de Mac OS X. Ya estaba achacoso, y parece que no se llevaba muy bien con los 64 bits. Buscando una actualización que resolviera los problemas (hace tiempo que dejó de hacerlo sólo, el pobre) he descubierto que ahora es de pago. Lo he comprado muy gustosamente.
No hace mucho compré NeoOffice, para mi gusto el mejor “port” de OpenOffice para Mac OS X. RECORDAD: Hay que comprar el software y/o donar dinero a sus autores. El “pirateo” de software está mal.

A veces me aburro…

En realidad no. Si me aburro hago tontunadas como generar un gráfico estadístico aleatorio usando la librería libgd.
 

Posición inicial del juego
Use para su estadística inventada

Edito: Añado el código fuente:

<?php
$padding = 10;
$width = 500;
$height = 400;
$hor_div = 10;
$ver_div = 12;
header("Content-Type: image/png");
$im = @imagecreate($width, $height)
    or die("Cannot Initialize new GD image stream");
$color_fondo = imagecolorallocate($im, 230, 230, 255);
$color_texto = imagecolorallocate($im, 0, 0, 0);
imagerectangle ($im, $padding, $padding, $width - $padding, $height - $padding, $color_texto);
$step = ($height - $padding*2) / $ver_div;
for($y=$padding; $y<$width - $padding; $y+=$step) {
	imageline($im, $padding, $y, $width - $padding, $y, $color_texto);
}
$step = ($width - $padding*2) / $hor_div;
for($x=$padding; $x<$width - $padding; $x+=$step) {
	imageline($im, $x, $padding, $x, $height - $padding, $color_texto);
}
$color_graph = imagecolorallocate($im, 255, 0, 0);
$prev = rand($padding, $height- $padding);
for($x=$padding+$step; $x<=$width - $padding; $x+=$step) {
	$curr = rand($padding, $height- $padding);
	imageline($im, $x-$step, $prev, $x, $curr, $color_graph);
	$prev = $curr;
}
imagepng($im);
imagedestroy($im);
?>

Un juego en un rato

Hace mucho tiempo vi un juego en un parque de juego que me pareció curioso. Se trata de un juego de 4 en raya, en el que cada jugador mueve una de sus fichas por turno, sin límite de cambios de dirección o distancia. El juego se llama “Vagabundo” y es así:

Juego del vagabundo
Juego del vagabundo

En la foto se ve que se puede mover cómo la rejilla por la que se mueven las bolas es de 6×6 ranuras. Sin embargo en las instrucciones dibujan una rejilla de 8×8.
Pues bien, desde el primer momento pensé que sería divertido hacer un juego para móviles así. Esto fue hace cosa de un año. Hace unas semanas hice un prototipo rápido de la interfaz para iOS. Empleé una par de horas de una tutoría en las que me aburría mucho. En principio solo se podía mover una bola. Un par de ratos más, incluido el echado esta misma tarde, y ya muevo todas las bolas evitando que colisionen y todo:
Posición inicial del juego
Posición inicial del juego

Pues bien, me he propuesto hacer el experimento de realizar el juego “en un rato” y contarlo. No parto de cero, porque ya tengo código previo que reutilizaré de otros proyectos, incluido el del servidor (porque será un juego para dos jugadores on-line) que empecé a explicar hace ya unos meses.
Algunas bolas movidas
Algunas bolas movidas

A ver cómo sale el experimento. Podéis seguirlo en mi cuenta de twitter que también tengo algo abandonada.

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 😀