Month: May 2009

Ya tenía rato queriendo probar Android, pero por una cosa o por otra no podía. Sin embargo, ahora que la empresa de telefonía celular Docomo va a sacar un modelo que lo incluye, pensé que es buen momento para comenzar a estudiarlo y ver qué se puede hacer con él.

Creí que sería más difícil, pero no me tomó ni 20 minutos tener el SDK listo y Eclipse con todo lo necesario para hacer un ¡hola mundo! Fácil, rápido, y lo mejor: es Java.

Como se pueden dar cuenta, el japonés se muestra a la perfección (ya tiene por default todo en UTF-8). Sin embargo, había un problema: no viene con ningún método para escribir en japonés, lo cual merma mucho lo que se puede hacer con el emulador por estos lares.

Después de estar buscando un rato, me encontré con Simeji, un programa que hace precisamente lo que necesito. Lo único que hay que hacer es bajar el archivo. apk, instalarlo en algún device creado previamente (el emulador) y listo. Ahora sí se puede comenzar a pensar en aplicaciones dirigidas al público japonés.

Como es un emulador, no tiene acceso al market, pero si hay forma de bajar el .apk a la computadora, la instalación es sencilla gracias al programa adb.

Hay versión para Linux, Mac y Windows. Si tienen un poco de tiempo, valdría la pena que lo prueben, para que se den una idea de lo que se puede (y podrá) hacer con Android.

Por cierto, Android está causando revuelo porque ha podido ser instalado en netbooks con éxito. La que se menciona más es la EeePC 701 (que tengo justo al lado, je), pero he visto videos en donde lo tienen instalado con Dell también. Obviamente no funciona todo todavía, pero la comunidad de desarrolladores ha logrado un excelente avance con los drivers de red (ya funciona). Falta pulir un buen, pero de concretarse, será muy interesante ver la batalla en netbooks: Linux, Android, y Windows 7, que ya se dijo que la versión starter podrá ser instalada en ellas.

En donde JD = Javadoc. Una adaptación del famoso RTFM! (y no salgan con TL. DR por favor :P).

Si uno hace una clase en Java y se toma la molestia de escribir la documentación como se debe y de hacer el Javadoc, lo mínimo que esperas al momento de que le haces un cambio al código es que quien usa tu clase lea la documentación para ver qué cambió, sobre todo si le dijiste en persona que los cambios estaban hechos y documentados debidamente.

Una de las principales clases que he creado en mi trabajo (casi desde que entré, y de la que estoy 100% a cargo) ha sufrido cambios considerables. Y como en la empresa no conocían el concepto de “versión de software”, decidí levantar un servidor de svn en mi máquina. Así ha sido más fácil que el jefe baje el código nuevo una vez que ha sido modificado. También subí al svn el Javadoc. Total: esta clase de la que hablo regresaba, hasta el momento, un array de 2 LinkedList<String>. Bien pude haber regresado algo como LinkedList<LinkedList<String>>, pero como eran 2 listas máximo, preferí un arreglo. Sin embargo, en el cambio más reciente que me pidieron, ahora regreso un arreglo de 4 listas ligadas de strings. Termino la modificación de código, hago pruebas, veo que todo funciona, documento código, subo al svn la modificación.

Varias horas después, cuando el jefe tiene tiempo de probar el nuevo código, me dice “me da error, revisa qué pasa”. Y yo con cara de “¿eh? ¿En dónde le da error?” Al mostrarme su código, me di cuenta de que nunca escuchó que ahora el arreglo contenía 4 listas ligadas, y, por tanto, donde él usa mi código mandaba una ArrayIndexOutOfBoundsException.

Quizá de lo que más me puedo quejar de mi trabajo es que me exigen todo bien documentado… y no leen la documentación. No sé por qué me recuerda a cierto sensei en cierto laboratorio en cierta universidad (de la que me gradué); pero no digo nombres, porque si no yo mismo me enojo 😛

Ahora que me he puesto de lleno la meta de sacar algunas herramientas sencillas para procesamiento de lenguaje natural, estoy puliendo, y en algunas partes rehaciendo, una parte del código que creé durante mi estancia en la universidad por acá.

Haber escogido Java no suena tan lógico, sobre todo cuando existen lenguajes como Perl, Ruby e incluso Python, que hacen la vida más tranquila en cuanto a procesamiento de texto. ¿Entonces? La verdad, no hay una razón definida; simplemente recuerdo que cuando comencé a programar la idea que tenía en mente recordé que quería practicar Java porque tenía rato que no lo usaba… y el resultado fue que terminé haciendo gran parte del código en ese lenguaje.

Una vez, creo que hace como 3 años, comencé a portar código a Ruby y recuerdo que obtuve buenos resultados, pero como nunca le di seguimiento en serio, el código se perdió y me quedé de nuevo en Java. No es malo del todo, ya que he aprendido muchos trucos del lenguaje. Sin embargo, con todo y que tengo mucho tiempo de no hacer nada en serio en él, me sigue gustando más C++.

Precisamente para practicar un poco en C, C++, Python y, en menor medida, LUA, estoy tratando de instalar el psptoolchain; de esta manera, puedo continuar con el algoritmo del jueguito de PSP que quería sacar hace ya tiempo (y del cual sí terminé de codificar el “esqueleto”). El problema es que siempre truena en la parte final de la compilada. Necesito sentarme a revisar el error y buscar información.

Ciertamente es diferente sentarte a programar con un monitor de 19″ (wide) enfrente. La computadora de la casa siempre ha estado conectada al monitor de 32″ que funge también como televisión, pero con la mudanza el escritorio quedó en el mismo cuarto que el monitorzote, así que opté por usar el de 19″ para cosas más serias, y el de 32″ para cuando quiero ver alguna película, serie o similares. La tarjeta de video que tengo es una nVidia Corporation G70 [GeForce 7600 GS] (gracias a lspci -v); la tengo con la opción “TwinView” en true y como “Clone”. Cierto es que podría usarla como extensión de un solo escritorio (como queda configurada originalmente en Windows), pero para fines prácticos, en Linux la tengo como clon.

Necesito ponerme a hacer limpieza de discos duros. Tengo muy poco espacio libre y hay muchas cosas que bien pueden estar en DVD sin mayor problema (como videos musicales). Me llama la atención comprar una unidad de BluRay, pero nunca termino de convencerme, incluso con el hecho de que ya bajó de precio (y seguro bajará más). Lo que sí urge comprar es un armazón nuevo, porque el que tengo de plano no funciona: es de esos “sin tornillos”, y gracias a eso tengo la unidad lectora de tarjetas “bailando”… la tengo que detener con las 2 manos cuando pongo una SD Card o una Memory Stick, si no, se va hasta adentro y tengo que abrir la máquina nada más para empujarla hacia afuera.

Por lo pronto, a dormir… De verdad que los días se pasan volando.

Las 2 barras laterales comienzan a estar muy pobladas. Me percaté de que la sección “Categorías” ocupaba mucho espacio vertical, así que opté por moverle al código para que quedara todo más compactado.

Los cambios se realizaron, como siempre, en wp-includes/classes.php:

• Todo es dentro de la clase Walker_Category
• En start_el, dejo la variable catimg como la tenía originalmente en el hack, esto es, $catimg = “<img src = \”caticons/” . $cat_name . “.jpg\”>”;
• Cambio la asignación de la variable $link para que solo tenga la imagen de la categoría después de la liga, es decir, omito los nombres de categorías:
  $link .= $catimg . ‘</a>’;
• Omito la primera asignación a la variable $output, que es en donde se designa a cada elemento como miembro de una lista.
• Cambio la asignación de la variable $output para que solo contenga lo que la variable $link contiene.
• En end_el, simplemente omito la asignación del tag de fin de elemento de lista </li> a $output.

El resultado es notable. Estuve tratando de poner la liga a los feeds en la primera barra, pero por alguna razón la primera imagen nunca aparece. No me quise pelear más por hoy.