Acelera el emulador de Android

“El Emulador de Android es lento”. Mucho. Es una de las quejas recurrentes que tenemos los que tenemos que desarrollar para Android, bien sea por afición, devoción u obligación. Comparado con el simulador de iOS, el Emulador de Android es una tortuga. Pero claro, la comparación no es justa: Android emula un teléfono completo, con su CPU, GPU, memoria, tarjeta SD, etc. Está ejecutando código real que podríamos instalar en un teléfono, compilado para una CPU de una arquitectura que no tenemos en el escritorio (como es ARM p.ej.). El simulador de iOS crea un ejecutable x86 que “simula” comportarse dentro de un teléfono, pero realmente es un programa de Mac “travesti”. La fidelidad no es la misma.

Por eso, en teoría el desarrollo con el Emulador de Android debe ser más sencillo, al tener una mejor herramienta con la que probar. Eso, si eres capaz de aguantar el tiempo insoportable que tarda en arrancar. Y si no se desconecta de adb (Android Debugger Bridge) y tienes que reiniciarlo.

HAXM

Para mejorar esto, Intel pone a nuestra disposición HAXM (Hardware Accelerated Execution Manager). Gracias a este programa, instalaremos una capa de aceleración para el Emulador de Android, que realmente se ejecuta en como una máquina virtual qEmu. qEmu es un emulador de CPUs, es decir, nos permite ejecutar en nuestros equipos basados en Intel x86 (como un Core i5 por ejemplo) S.O. que corren en Intel (como Windows, Linux, Mac) o bien otros S.O. que necesitan otras CPUs y arquitecturas (como es el caso de Android con ARM).

HAXM es un driver (o un módulo del kernel en Linux / extensión del kernel en Mac) que concede a qEmu acceso directo al hardware en el que se ejecuta. Eso sí, como es un programa de Intel, sólo funciona con las CPUs Intel. Vamos, que si tu máquina tiene una CPU AMD ya puedes ir cerrando el post. Además, la CPU debe soportar VT-x (las modernas lo soportan, no pruebes con un Pentium II). Puedes consultar los requisitos en la página detallada de Intel sobre cómo instalar HAXM.

Instalación de HAXM

Si estás usando el nuevo ADT Bundle (es decir, el Eclipse + plugin ADT + SDK Android que ha sacado hace poco Google, que ya era hora por cierto) y abres el Android SDK Manager, al final encontrarás un grupo llamado “Extras” en el que está el Intel x86 HAXM Emulator Accelerator. Si estás en Windows / Linux, bájatelo desde aquí. Si estás en OS X Mountain Lion 10.8.2 no te lo bajes desde aquí, debes ir a la página de descargas de HAXM, ya que existe un bug que hará que tu querido Mac se cuelgue. Sí, has leído bien: los Macs también se cuelgan. Cuando te lo bajes, ya sea desde el SDK Manager o a mano (por cierto, en el enlace anterior están las versiones de Linux y Windows de HAXM) debes instalarlo.

En el caso del Mac, bajas un DMG que al montar te muestra un programa de instalación. Tras instalarlo (no exige reiniciar) podemos confirmar que está en funcionamiento escribiendo en una Terminal:

$ kextstat | grep haxm

Debe aparecer algo como esto:

Tesla:~ dfreniche$ kextstat | grep haxm
115  0 0xffffff7f81e29000 0x13000 0x13000  com.intel.kext.intelhaxm (1.0.4)

Si te has bajado el paquete usando el SDK manager, puedes encontrar el programa de instalación en $SDK_HOME/extras/intel/

Uso de HAXM

Una vez instalado HAXM, debemos descargar las imágenes de Android que también nos proporciona Intel. La idea es que en lugar de acelerar un emulador ARM (que sería muy complicado) Intel nos da Android para Intel Atom. De esta manera, cuando qEmu ejecuta instrucciones en el Intel Atom emulado realmente se pasan a nuestra CPU directamente, con la consiguiente mejora en rendimiento.

Estas imágenes aparecen como “Intel x86 Atom System Image” en el SDK Manager. A bajarlas. No las tenemos para todos los API levels, pero sí para los más usados (API 10, 15 y 17 y supongo que en breve sacarán para el 18).

SDK Manager mostrando las imágenes Intel ya instaladas

Ahora tendremos que crear una definición de AVD que utilice esta imagen de Intel. En lugar de un emulador con CPU ARM, vamos a escoger uno con CPU Intel Atom. De cara a nuestros programas da igual, ya que a fin de cuentas se van a ejecutar en la máquina virtual Dalvik. Si vamos a probar código Android nativo (escrito en C con el NDK) entonces lo mejor es leer la documentación de HAXM.

Creando un AVD con CPU Intel seleccionada

Cuando arranquemos nuestro AVD notaremos dos cosas. En la consola debe aparecer un mensaje que indique que “HAX is working” y casi sin darnos cuenta nuestro Emulador estará operativo. Se acabó el arrastrarse. Yo ni marco que arranque de un snapshot porque es tan rápido que no me merece la pena.

Bonus level

Si usas API level 15 ó 17 puedes usar la aceleración de hardware de la GPU, lo que hará que todavía sea más rápido. Avisado quedas de que puede no funcionar (el emulador se vería en negro y tendrías que cerrarlo). Consulta el apartado de aceleración de la GPU de la documentación Emulador para más detalles. Para activarla, marca el checkbox “Use host GPU” en la definición del AVD.

Ultra bonus level

Y si necesitas un emulador de Android “en la nube”, para probar algo o mostrar en una visita a un cliente, y no tienes tu máquina pero te puedes bajar el APK de Dropbox, mira Manymo. Si con esto no te pones palote

j j j

Cómo crear un entorno de desarrollo Android portable

Logo de Android

Logo de Android

Algún día me tenía que pasar. Después de ver tanto backend Java en cursos de todos los colores y de coleccionar certificaciones Java, después de desarrollar para iOS y webOS, alguna vez me tenía que poner en serio con Android. De hecho, siempre me han preguntado que por qué no era esta mi plataforma de desarrollo móvil “de cabecera”. Quizás porque estaba saturado de Java. O porque, como comentaba en We.Developers, Java es un lenguaje que no me genera excesivas alegrías (sobre todo cuando lees la mayoría del código que hay por ahí, que es bastante feo, fruto del desconocimiento del lenguaje).

El caso es que estoy actualmente desarrollando una App para Android (de la que daré más datos cuando se suba a Google Play) y me ha surgido la oportunidad de impartir un curso a los programadores de RTVA. Como en todo curso, me gusta instalar el entorno de desarrollo. Y si vas a desarrollar para Android, sabes que tienes que instalarte:

  • un JDK para poder compilar todo el código Java que escribimos como parte de nuestras Apps Android
  • un JRE, necesario para ejecutar Eclipse
  • Eclipse, como IDE para escribir nuestros programas
  • el SDK de Android, que pone a nuestra disposición las bibliotecas necesarias para crear los programas Android, así como el Emulador, herramientas e imágenes para ejecutar ese emulador.
  • el plug-in ADT para Eclipse, que nos permite gestionar el SDK cómodamente desde Eclipse

Este curso se imparte en dos semanas, dejando varios días por medio. Y el tiempo que se tarda en descargar las distintas partes del SDK de Android y el plugin ADT (ambos hay que descargarlos para instalarlos) no es despreciable cuando lo intentamos hacer con 10 portátiles todos conectados a la misma Wifi. Además de la limitación inherente a compartir la conexión HTTP, el medio físico (el canal de radio usado por el punto de acceso WiFi) es el mismo para todos los portátiles. Luego hay colisiones. Y cuantos más portátiles, peor para todos.

En una primera opción, llevaba el JDK, Eclipse y el paquete de instalación del SDK en un pendrive, para irlo instalando todo. Pero de estas dos últimas descargas no me podía librar… ¿o si? Y mi miedo es volver la segunda semana y encontrarme los portátiles formateados…

Cómo crear un entorno de desarrollo Android Portable

En este caso, me centro en cómo crear el entorno portable para Windows 32 bits, que corre en XP y Windows 7. Al final comento las diferencias con Mac.

  • Lo primero es bajar todo lo que necesitamos a una carpeta:
  • Java JDK para Windows es un ejecutable, y escogeremos, de la versión 6, el saber que nos interese: 32 bits (i586) o 64 (x64).
  • De Eclipse nos interesa la última versión de la distribución Eclipse IDE for Java developers. No la versión para Java EE, ya que no vamos a usar servets ni nada de eso. A fecha de escritura de este post, la última versión es la Indigo.
  • La última versión del SDK de Android. Nos bajamos la versión en ZIP, no la instalable.
  • Una vez que tenemos todo esto bajado, debemos instalar el JDK en la máquina. Realmente queremos las carpetas que van dentro, pero al no disponer de un ZIP no tenemos más remedio que instalar. Lo dejará en C:\Archivos de Programa\Java
  • Una vez termine la instalación del JDK, nos crearemos una carpeta en el escritorio que podemos llamar Android-Portable, o como más nos guste.
  • Debemos descomprimir dentro de esta carpeta el ZIP de Eclipse.
  • Ahora, copiaremos la carpeta JRE que está en C:\Archivos de Programa\Java\Jre6\ dentro de la carpeta de Eclipse, justo donde está Elipse.exe. Así, al arrancar Eclipse usará ese JRE que le hemos instalado “tan a mano”
  • Igualmente descomprimiremos el SDK de Android dentro de Android-Portable.
  • Como necesitaremos el JDK para compilar, vamos a copiarnos en Android-portable la carpeta C:\Archivos de programa\Java\jdk1.6.0_31
  • Ahora debemos tener dentro de Android-Portable: una carpeta con Eclipse, otra con el JDK y el SDK de Android.
  • Ya podemos arrancar Eclipse. Necesitamos instalar el plugin ADT, para lo cual iremos a Help > Install Software e instalaremos ADT indicando como repositorio https://dl-ssl.google.com/android/eclipse/
  • Tras reiniciar Eclipse, nos pedirá que instalemos un SDK de Android, o que le indiquemos dónde tenemos uno instalado. Le indicamos que dentro de Android-Portable tenemos uno. Nos muestra el Android SDK Manager para descargar las imágenes de los emuladores para las versiones de Android que nos interesen, así como los SDKs propiamente dichos. Yo me los bajaría todos.
Eclipse nos pide un SDK de Android (click para agrandar)

Eclipse nos pide un SDK de Android (click para agrandar)

  • ¡Listo! Ahora podemos copiar la carpeta Android-Portable y todo lo que necesitamos lo llevamos dentro. Para arrancar Eclipse bastará con entrar en su carpeta y hacer doble click en Eclipse.exe. Si quieres, siempre te puedes crear un acceso directo, pero que sepas que al mover la carpeta tendrás que volver a crearlo.
Así debe quedar la carpeta Android-Portable

Así debe quedar la carpeta Android-Portable

Esta carpeta ya la podemos poner en un pendrive, comprimirla, copiarla de un equipo a otro, etc. Funcionará con los distintos Windows.

Si tienes un Mac el proceso es el mismo, salvo que:

  • no tienes que instalarte Java, ya que el JDK viene instalado con OS X (es una instalación opcional del S.O.). No puedes “bajarlo” de la página de Oracle.
  • debes bajar el Eclipse de Mac
  • debes bajar el SDK de Android de Mac

Ahora, a ver alguien compra las Apps que hagamos :-)

j j j

Instalar el plugin de Mercurial en Eclipse

Los sistemas de control de versiones son adictivos. No puedes probarlos, porque luego no puedes vivir sin ellos. Aunque sea un pequeño ejemplo el que vas a programar, te sientes perdido sin tu repositorio y empiezas a pensar “¿y si se me ocurre cambiar esto o lo otro, y luego me arrepiento?”. Ese tipo de “problemas” se solucionan casi en el acto con un VCS. Y si es distribuido (Git o Mercurial), mejor que mejor.

Antes de seguir, quiero dejar claro que no entro en las guerras religiosas entre los DCVS Git o Mercurial. Yo uso Mercurial porque Joel Spolsky lo explica de forma increíblemente sencilla. Aunque ahora que Git viene integrado con XCode4, probablemente es una buena alternativa… bueno, no :-). En fin, usa el que te de la gana, pero usa uno.

Para casi todos mis proyectos uso Mercurial. No lo uso para los ejemplos que escribo para mis cursos. Y estaba pensando “¿porqué no usarlo?”. Por pereza mental, y por hacer siempre las cosas de la misma forma. Mi padre dice que “si un burro tira de una noria para un lado y le das la vuelta, ya no sabe tirar de ella”. Y es que nos acostumbramos a hacer siempre lo mismo, de la misma forma, y nos estancamos. De vez en cuando hay que revisarlo todo con una mirada fresca y en lugar de pensar “¿hay una manera de optimizar esto que estoy haciendo?” debemos plantearnos “¿en serio tengo que seguir haciendo esto?”.

El caso es que un sistema de control de versiones es casi perfecto para dar clases. Puedes tener una primera versión, sencilla, y luego ir promoviendo a las distintas versiones más avanzadas, que pueden ser changesets o bien nuevas ramas. Los cambios que hagas durante la clase para demostrar algo siempre puedes revertirlos sin problemas. Para eso está el DCVS. Y distribuir el código es más sencillo: compartes tu repo, y los alumnos se clonan los repositorios y punto. No hay que andar con historias de copiar los Workspaces de Eclipse y que luego falle (los WS de Eclipse dependen del sistema en el que los uses, hay que cambiar luego los Build Paths, etc.). Como se puede ver, todo son ventajas. La pregunta es porqué no lo he usado hasta ahora…

Instalar Mercurial

Evidentemente, antes de nada lo primero es instalar Mercurial, ya sea para Linux, Windows o Mac, o para donde vayas a usar el DCVS. Si no, el plugin de Eclipse no podrá usar Mercurial porque no lo encontrará en tu sistema. Te lo bajas de su sitio web oficial.

Instalando hgEclipse

HgEclipse es un plugin para Eclipse que añade soporte Mercurial a tus proyectos. Una vez instalado, en el menú contextual del proyecto encontrarás en la opción Team > Share la parte de Mercurial. Para instalarlo, iremos a Help > Install New Software e introduciremos el repositorio http://cbes.javaforge.com/update. En mi caso (instalándolo en Mac) no necesito los binarios de Mercurial para Windows, así que no los marco para instalar.

Instalando hgEclipse: repositorios

Instalando hgEclipse: repositorios

Cuando pulsemos Next, pasaremos a descargar e instalar el plugin. Al final no hay más remedio que reiniciar Eclipse. Así que hazlo :-)

hgEclipse instalándose

hgEclipse instalándose

Usando HgEclipse

Una vez con todo instalado, lo primero es crear el repositorio Mercurial en nuestro proyecto. Eso lo prepara todo para poder gestionar las versiones de tu codigo fuente. Equivale a un “hg init”. Para ello, pulsaremos con el botón derecho del ratón en el nombre de nuestro proyecto y seleccionaremos Team > Share Project. Si todo está correctamente instalado nos aparecerá una ventana como la siguiente:

Share > Project

Share > Project

Como queremos crear un repo Mercurial, basta con pulsar siguiente. Nos mostrará dónde va a crear el repositorio (que es una carpeta llamada .hg, dentro de nuestra carpeta de proyecto). Aparecerán unos nuevos iconos en las carpetas y ficheros de nuestro proyecto y la palabra [new] indicando que el repo es nuevo, pero aún no se ha realizado el primer commit.

Repositorio tras el init

Repositorio tras el init

¡Vamos a añadir ficheros a nuestro repositorio! Botón derecho en el proyecto > Share Project, pero ahora aparece un menú con un montón de opciones. Seleccionamos Add. Esto añade los ficheros del proyecto al repositorio. Yo suelo añadir únicamente el código fuente, pero no los ajustes del proyecto, ni las carpetas propias de Eclipse, como muestro a continuación:

Añadamos ficheros al repo!

Añadamos ficheros al repo!

Ahora que hemos añadido, los iconos de los ficheros fuente cambian y tienen un “+” azul al lado. Están ya controlados por el repositorio, pero no hemos subido este cambio, que en este caso es subir la primera versión. Para ello, Team > Share Project > Commit y añadimos un mensaje de commit. HgEclipse nos muestra los ficheros que va a subir, y los que no tiene “controlados”, por si queremos añadirlos.

Commit

Commit

Al pulsar OK, ¡listo!. Ya tenemos control de versiones funcionando. Ahora, si modificamos un fichero se nos mostrará como cambiado y podremos hacer un commit con esos cambios. O podremos compartir el código fuente del proyecto por la red con la opción Serve. Cualquiera en la red podrá hacer un Pull del repo y bajarse este código fuente. Mucho más rápido que compartir el proyecto en una carpeta SMB y encima evitas problemas con las configuraciones de Eclipse (yo lo uso en Mac y mis alumnos, normalmente, en Windows)

Las opciones del menú de Share Project son muy amplias. Os animo a irlas probando y a aprender Mercurial entre todos. El que tenga un truco especial de cómo usa Mercurial, ya sabe, que use los comentarios.

hg commit -m "post acabado"
hg tag -m "v1.0"
j j j

Una mañana de trabajo cualquiera

Me paro un momento y miro en lo que estaba trabajando, y los programas que tengo abiertos ahora mismo, y no puedo evitar pensar que soy lo más alejado del minimalismo. Al menos en lo que se refiere al ordenador. Era minimalista cuando no tenía dinero más que para mi querido Amstrad CPC 464 con el monitor fósforo verde, con su unidad de casetes. El único periférico que tenía era un Joystick. Y a usarlo. Pero veía en las películas a gente en países lejanos y extraños, en salas llenas de ordenadores.

Como el programador de Parque Jurásico (que, por supuesto, además de ser el malo, cobarde y torpe, estaba mal pagado y era gordo y feo). Por cierto, si veis de nuevo JP os llamarán la atención dos cosas: una, que están programando fumando, algo impensable en cualquier entorno de hoy en día. La otra, que el sistema de “bug tracking” que usan es una libreta donde van anotando los errores :-)

Volviendo al tema que me traía aquí, en esta mañana he comenzado programando en C, en el IDE Eclipse corriendo sobre Windows 7. Ese Windows 7 está instalado en mi MBP. Por si fuera poco frikismo, he usado el escritorio remoto de Windows para programar esos ejemplos en una ventana del iMac de 27″, que para eso tengo una pantalla grande. Mientras programaba iba actualizando la presentación de Keynote que acompaña al curso, en el iMac. Sonaba la música desde iTunes, donde estaba restaurando mi iPhone 3Gs con una copia de seguridad de ayer: mis niños han borrado algunas fotos en un descuido.

He terminado con C y me he pasado a WordPress. Arrancando una máquina virtual VMWare de Bitnami, que ya tiene un entorno WP completo sobre Linux, me he dedicado a crear un nuevo sitio para migrar una vieja web que hice hace ya la tira en Typo3. Es decir, instala plugins, widgets, temas, escribe posts, importa información, etc.

Ahora toca pensar en el próximo curso de Java EE que tengo que impartir a finales de mes. Java, Servlets, EJBs, JBoss, Eclipse de nuevo (aunque ahora en su “sabor” Java). Tendré que ojear un libro, que tengo en formato CHM (formato típico de Windows en otra época). Y luego, un poco de Objective C para comenzar un proyecto iPad que me han encargado. Tengo cosas que leer de UML…

Es por este desbarajuste de trabajo que tengo, con tantas tecnologías, frameworks, lenguajes, herramientas y entornos distintos por lo que amo a mis dos Macs. Necesito ser anti-minimalista, ya que si lo fuera no podría hacer la mitad de las cosas que hago. Esta es la razón de haber ampliado mi iMac a 12 GB de RAM. Aún así, procuro no instalar nada si ya tengo una aplicación que hace más o menos lo mismo, que si no acabas con un montón de aplicaciones similares que no acabas de dominar en profundidad.

Bueno, sigo, que quiero ir terminando. Que no hace mucho me comentaron que a lo mejor tengo que aprender CLIPS:-)

j j j

SCWCD aprobado!

Un poco (más) de autobombo. Comentaba hace unos días que me iba a presentar al examen de certifiación de Java Sun Certified Web Component Developer. Hoy, tras un par de semanas intensas y más sufrimiento del que esperaba, lo he aprobado con un 79%. Un poco raspado, ya que el aprobado está en el 70%, pero… está aprobado, ¿no?

Esta certificación se une al Sun Certified Java Programmer 1.5 y Sun Certified Business Component Developer 1.3 que ya tenía. Y, si todo va bien, a finales de Julio me presentaré al SCJP 1.6, para así tener estas cuatro certificaciones y poder cobrar mis horas a precio de Gurú :-). No, ahora en serio, voy a intentar aplicar estas certificaciones en algo que quiero preparar en los próximos meses. Permanezcan atentos a sus receptores…

j j j

Leyendo para emprender

Cuando el año pasado en Octubre, decidí dejar Isotrol e iniciar una nueva etapa en solitario programando apps para el iOS (el S.O. del iPhone, iPod Touch e iPad) tenía claro que no quería cometer viejos errores de mis anteriores etapas como empresario. Quería crecer y mejorar, como persona, como profesional y como emprendedor. Por ello me metí en Amazon y compré un conjunto de libros que tocan estos tres temas.

Pero claro, comprar los libros no es lo mismo que leerlos. Y leerlos no es lo mismo que comprenderlos. Y, en cualquier caso, lo importante, lo único importante de toda preparación, es aplicar lo aprendido. Leer, comprender, aceptar e interiorizar no son nada comparados con hacer. La parte más importante del Getting Thing Done es, precisamente, el Done.

De momento, llevo leídos:

  • Gestiona mejor tu vida, de Berto Pena, librazo que recomiendo a cualquiera que sienta que no le llegan las horas al final del día.
  • The 4 hour workweek, un libro revolucionario por lo simple que te plantea cómo cambiar las cosas. Hay que leerlo dejándose retar por las nuevas ideas de Tim Ferriss y ser capaz de ser flexibles y responder al reto. Me lo recomendó Jaime Gallo y ha sido una revelación.
  • Beginning iPhone 3 Development ha sido mi primer libro de iPhone SDK, y me ha ayudado a preparar mis primeras Apps. He necesitado leerme también (en formato electrónico, no aparece en la foto) Learn Objective-C on the Mac, para tener una idea del lenguaje que está detrás de Cocoa Touch y no perderme. Este último me ha encantado, porque es muy académico y directo. Si sabes C, o Java, te explica las cosas con profundidad y sin mitos. Pero no te lleva de la manita, ni trata de suavizar según que cosas.

Estoy ahora mismo con:

Y luego vendrán:

  • En Julio, SCJP 1.6 Study Guide.
  • Y en Agosto – Septiembre, mezclaré los libros de Joel Spolsky y Micro ISV con el segundo del iPhone, iPhone SDK 3 Programming.

Por supuesto, seguiremos leyendo en blogs, en PDFs (algo del iPad habrá que mirar), etc. Es fundamental el estar permanentemente formándonos, revisando, mejorando (o intentándolo). Tener curiosidad y ganas de aprender es uno de los ingredientes de la salsa de la vida.

¿Y tú? ¿Con qué libros andas ahora? ¿Me recomiendas alguno?

j j j

Preparando el SCWCD

Pulsa en la foto para ver al autor.

El Sun Certified Web Component Developer es el examen de certificación de Sun sobre las tecnologías Servlet y JSP de Java EE. Me apetecía tenerlo, tras aprobar en 2008 el SCJP y el año pasado el SCBCD. Y en ello estoy ahora, estudiando de cara al día 25, cuando tendré que hacer el examen.

Para pasarlo, estoy usando el libro de Kathy Sierra, Bryan Basham y Bert Bates (de nuevo, esta gente sólo escribe libros) Head First Servlets & JSP. No se si lo he comentado antes por aquí, pero me encantan los libros de la serie Head First. Con tantos dibujitos, fotos y chorradas, aprendes casi sin darte cuenta. Son efectivos, y ayudan a prepararse este examen con el mínimo sufrimiento. Un poco lo que siempre digo al empezar mis cursos: “aquí os vais a reír mucho e igual aprendéis algo”.

Además del libro (y de tener los Vouchers para acceder al examen y apuntarte en la web de Prometric), es necesario probar con pequeños programitas Java los conceptos que aparecen en el libro. En mi caso, estoy abusando de mi pequeño Netbook con Ubuntu Netbook Remix, al que le he instalado una versión portable de Java JDK 6 y Tomcat y que llevo a todas partes para repasar. Otra de las herramientas importantes que estoy usando es un mapa mental de la certificación SCWCD creado con XMind, que retoco en Linux y en mi MacBook Pro. Es un work-in-progress, pero podéis verlo en:

http://www.xmind.net/share/dfreniche/

Y, por supuesto, ya me he comprado el simulador del examen de Enthuware. Espero que, como en las dos anteriores ocasiones, me ayude a aprobar.

Ya os contaré si apruebo. Si no, me callaré como una pu…erta :-)

j j j

Problemas con XMind: workaround encontrado

Ya he comentado por aquí antes que uso los mapas mentales a menudo para organizar mis ideas. Y los uso para todo. Uno de ellos, que se está volviendo enorme, es el que uso para organizar mis proyectos de “retro-informática”. Que si comprar una compact-flash para usarla como disco duro en un Amiga 600, que si montar una disquetera de 5″1/4, esas cosas.

Pues XMind me ha dejado de funcionar en mi Mac. Y no me preguntéis porqué, porque no tengo ni idea de la causa raíz del problema. No se si será haber instalado el SDK para el iPhone, o haber trasteado cosas para prepararme el SCJP / SCBCD, el caso es que XMind ahora no me funciona. Al ser un programa Java, he buscado si dejaba algún log y el error que me aparece es: “No application id has been found”. Después de Googlear un rato, parece que este problema se origina cuando Eclipse (o alguna de sus bibliotecas) no está bien instalado.

Sea como sea, necesito que XMind funcione, y he localizado una solución temporal válida. En la web de XMind podemos descargar una versión Mac (un DMG) y una versión “portable”. Me he bajado la versión portable y he copiado en la carpeta Aplicaciones de mi Mac las carpetas “XMind for Mac OS X”, donde está el ejecutable, y “Commons”, que es donde están las bibliotecas de Eclipse que antes no se encontraban. Mano de Santo. Ahora puedo seguir con mis mapas, que es lo que me urge. La solución definitiva, la publicaré si la encuentro.

Os dejo con el mapa de mis retro-máquinas, que está en constante cambio :-)

Mapa mental de mis máquinas

j j j

Ya ha pasado el mes de descanso mental

Cuando aprobé el SCBCD, el pasado Enero, terminé con el cerebro como si tuviera a Bob Esponja en lugar de meninges. Decidí darme un mes para recuperar la temperatura de funcionamiento normal de mi cabeza. Ese mes ha pasado, y hoy voy a empezar con el SCWCD. Otra sopa de letras. Esta es la certificación de Java EE sobre Servlets y JSP, y alguna tecnología web más.

No tengo ni idea de cuándo me voy a presentar. Esta vez quiero dedicar un mes a leerme el libro y, cuando lo tenga visto, hacer exámenes de prueba tranquilamente. Y luego presentarme.

j j j

SCBCD aprobado, también

Ya comenté en Diciembre que había aprobado el SCJP (Certificación de Sun como Programador Java, v1.5). Pues bien, hace una semana aprobé la SCBCD, la certificación de desarrollador de componentes de negocio, v1.3.

¿Bueno, y qué es ésto?. Una manera de demostrar que medio empiezo a entender qué es un Enterprise Java Bean (EJB), que es, explicado muy llanamente, un componente (un conjunto de clases java, archivos de configuración XML y otras muchas cositas y reglas) que se comprime en formato ZIP y que permite representar datos, tratar mensajes o bien gestionar los procesos de una web. Supongo que los puristas se estarán removiendo en su silla por esta explicación, pero es que no quiero extenderme ni largar un rollo sobre EJBs.

Este año, 2009, me quiero dedicar a “coleccionar” certificaciones. Me explico. Durante unos años he sido profesor errante de diversas materias. Desde Java básico a gestión de proyectos. Y he tenido que leer un par de libros. Creo que ahora es tiempo de recoger y plasmar en titulitos del fabricante lo que se supone que medio controlo.

Algunos de los libros frikis que poseo

Algunos de los libros frikis que poseo

La siguiente certificación va a ser el Desarrollador de Componentes Web (SCWCD). Probablemente después venga el SCJD y a lo mejor alguna certificación Linux, como la LPI-1 (la sencillita).

Pero antes, me voy a dar un mes de reposo mental, que falta me hace, mientras espero el suspenso en la certificación de ITIL Service Manager :-)

j j j