Mudanza
Posted: enero 11th, 2012 | Author: david | Filed under: Desarrollo | No Comments »Me he mudado a blogger. Sigo en http://davidasorey.blogspot.com/
Me he mudado a blogger. Sigo en http://davidasorey.blogspot.com/
Primero fue cayó Google Wave, ahora cierran Google Buzz. En el blog oficial de Google lo comentan.
Según la entrada, en Google están centrando todos sus esfuerzos en Google+, su buque insigna en las redes sociales y están “reciclando” lo aprendido.
En muchos productos de Google se van incorporando innovaciones. Cuando se está editando un documento en Google Docs entre varias personas se muestra quién está editando cada parte, como en las conversaciones de Wave.
Otros desarrollos en Buzz presumiblemente también se están incorporando en Google+.
Se aproxima una interesante “batalla” entre Facebook y Google+
Llevaba tiempo buscando un plugin para symfony 1.4 que permitiese cachear en Memcache en vez de en ficheros.
Encontré este, sfMemcachePlugin, pero parece que no está mantenido y no me he atrevido a instalarlo.
En mi aplicación sólo necesitaba cachear los resultados de una consulta especialmente pesada (es una cartelera de cine, la consulta consiste en cruzar todas las películas con todas las poblaciones donde hay cines que la tengan en cartelera).
Mi solución ha sido un tanto rudimentaria pero funciona muy bien:
Primero defino un método estático en una clase “Utilidades” que me devuelve un objeto memcache:
class Utilidades {
public static function getMemcache() {
$objMemcache = new Memcache;
$objMemcache->addServer('servidor1',11211);
$objMemcache->addServer('servidor2',11211);
/* etc */
return $objMemcache;
}
}
Después, en la clase que hereda de Doctrine_Table, defino el método que devuelve los resultados cacheados:
class FooTable extends Doctrine_Table {
public static function getConsultaCacheada() {
$clave = "FooTable-getConsultaCacheada";
$timeout = 3600;
$memcache = Utilidades::getMemcache();
$datos = $memcache->get($clave);
if(!$datos) {
$query = Doctrine_Query::create()->from('Tabla a')->where('...');
$datos = $query->fetchArray();
$objMemcache->set($clave, $datos, null, $timeout);
}
return $datos;
}
}
Super sencillo y funcional
Haría falta código adicional para controlar errores, etc, pero la idea básica es ésta. Se puede añadir algún parámetro al método como public static function getConsultaCacheada($nocache=false) para poder hacer consultas “frescas” sin tirar de Memcache si es necesario.
Más información del uso de Memcache en PHP en php.net/manual/en/book.memcache.php
Llevo un año pendiente de esta “issue”:
| Issue 8201: | Expose Midi Streaming capability of Sonivox Synthesizer |
Y no parece que haya avances. ¿Por qué?
Por esto:
¡No se pueden hacer aplicaciones de este tipo en Android! No es posible enviar secuencias MIDI al sintetizador interno. El sistema iOS lo tiene resuelto hace mucho. Consecuencia: hay muchas aplicaciones para músicos muy buenas y bien hechas para iOS y para Android, algún afinador, caja de ritmos y poco más.
Una pena.
Con lo bonito que era el parpadeo de las webs que había en Geocities… (Ver HTML)
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8" />
<title>¡¡¡Blink!!!</title>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js"
type="text/javascript"></script>
<script type="text/javascript">
function blinkear() {
var blink = $('blink');
if (blink) blink.toggle();
}
$(document).ready(function () {
setInterval(blinkear, 700);
});
</script>
<style>
blink {color: lime; font-size: 22px;
font-family: "Comic Sans MS";
font-weight: bold;}
</style>
</head>
<body>
<blink>El parpadeo es divertido...</blink>
</body>
</html>
Busco desesperadamente un programa para gestionar tareas que me permita hacer algo como esto:

Sería muy útil
Supongo que le habrá pasado a más gente, vas importando música a la biblioteca de iTunes y de vez en cuando aparecen duplicados. Borrarlos a mano es muy tedioso, así que aquí está el script que los borra físicamente de la biblioteca.
La idea básica es que cuando iTunes duplica un archivo, lo hace añadiendo <espacio>1 al nombre del fichero. Este script en Python los detecta (y si quieres, los elimina):
import os
def f(arg,dirname,names):
print "Reading directory " + dirname
for n in names:
try:
if n[-6:] == ' 1.mp3':
fich = dirname + '/' + n
print "Removing " + fich
try:
pass
# Uncomment the line above (under your responsability)
#os.remove(fich)
except Exception as (errno, strerror):
print strerror
except Exception:
pass
startpoint = os.path.expanduser('~') + '/Music/iTunes/iTunes Music'
os.path.walk(startpoint, f, None)
Por motivos laborales estoy probando estos dos aparatos y comparando sus prestaciones, facilidad de manejo, etc. En general, me gusta más el Galaxy, aunque reconozco que para algunos usos el iPad es mejor:

Recientemente he adquirido una cuenta VIP en Grooveshark. Estoy encantado.
Tienen una aplicación para distintos terminales móviles y me he descargado la del iPhone (requiere iPhone con “jailbreak”). La aplicación tiene un “modo offline” muy útil para escuchar música sin tirar de la conexión de datos o Wifi.
El caso es que quería recuperar algunos de estos mp3 para escucharlos en el “netbook” (la aplicación de escritorio, basada en AIR) no tiene un modo offline.
Así que, cacharreando un poco, encontré dónde guardaba la aplicación Grooveshark para iPhone sus archivos offline. Se necesita el iPhone, con “jailbreak”, por supuesto y la utilidad ifuse (en Ubuntu sólo hay que instalar el paquete correspondiente).
ifuse --root ~/iphone
/private/var/mobile/Library/Grooveshark/offline
yo@ordenador:~$ file ~/iPhone/private/var/mobile/Library/Grooveshark/offline/27935561.mp3 ~/iPhone/private/var/mobile/Library/Grooveshark/offline/27935561.mp3: data
python script-que-descifra.py FICHERO_MP3_CIFRADO.mp3 FICHERO_MP3_DESCIFRADO.mp3
Y nos queda un fichero .mp3 con un nombre no muy identificativo pero con todos los tags ID3 bien puestos.
Tengo un libro electrónico (un Kindle 3) desde hace unos 6 meses, y le he dado un uso bastante intensivo. Llega el momento de sacar algunas conclusiones respecto al aparatito.
Generalmente se suelen poner ventajas de uno frente al otro, pero no me vale esta comparación, prefiero comparar según el tipo de lectura que estoy haciendo. Suelo leer tres tipos de libros: técnicos o manuales, novelas y libros de partituras (tipo Real Book).
Libros técnicos, manuales o “libros de texto”
Por mi profesión (desarrollador web) tengo que leer mucha documentación, aparte estoy estudiando una ingeniería en la UNED.
Decididamente, el libro electrónico no es cómodo para mí en este contexto. Aunque mi modelo permite hacer anotaciones, no hay nada como el subrayado con lápiz o las notas al margen tradicionales.
En un volumen de papel se ojea y rebusca con mucha facilidad y rapidez, con el “ebook” no me termino de apañar. He comprado alguno en formato electrónico y no me ha convencido, la verdad. También he intentado estudiar alguna asignatura en el “ebook” y no me siento cómodo, sigo muy aferrado a la costumbre de ir leyendo el libro, marcándolo y escribiendo en el cuaderno. A lo mejor es que ya estoy talludito
Novelas
En mi opinión, en este tipo de libros, el “ebook” tiene todas las de ganar. Puedes tener colecciones enteras en un cacharrito muy reducido, se lee muy bien, puedes poner marcadores en los pasajes más interesantes y en algunas plataformas (como la de Amazon), sincronizar el punto de lectura entre distintos dispositivos: aunque la pantalla del móvil no sea el dispositivo más idóneo para leer mucho rato, está muy bien poder retomar la lectura en la consulta del médico mientras esperas y seguir luego en casa donde lo dejaste en el móvil
Por supuesto, leer novelas en papel tiene su encanto y me gusta, pero el “ebook” es infinitamente más práctico (“El Conde de Montecristo” es un buen tocho para ir llevándolo a todas partes).
Aquí si que me he llevado un buen chasco con el “ebook”. Creía que podría prescindir al fin de los Real Book (son unos libracos de alrededor de 500 páginas), pero no puede ser: primero, mi “ebook” tiene la pantalla muy pequeña (6”), las notas casi no se ven -aunque en un modelo que tenga la pantalla más grande, tipo Kindle DX o iPad se ven bastante bien-; segundo, si ojear un libro técnico es lento, uno de partituras lo es más (suelen ser PDFs compuestos por imágenes, del orden de las decenas de megas).
Además, hacer una anotación rápida en un ensayo de un símbolo musical, cambiar notas, etc, es imposible (aunque esto ya lo sabía).
En este aspecto, tendré que seguir haciendo lo que hasta ahora: imprimir en hojas sueltas los temas que estoy montando si no quiero cargar con el volumen enterito.
Conclusión
En mi opinión, vamos a tener libros en papel mucho tiempo todavía… Es un soporte bastante fiable, duradero y fácilmente editable. Eso sí, los libros electrónicos para determinados tipos de lectura son una maravilla. A ver si las editoras se ponen las pilas, amplían catálogo y ponen precios razonables. Amazon está a la vuelta de la esquina y cada vez tiene más títulos en castellano a buen precio.