Posts from the 'Programación' Category

Volver a empezar

No, no me refiero al hecho de que dijera que tenía que escribir más y leer menos, y luego no he escrito desde hace meses. Me refiero a que tengo que volver a empezar a programar, después de tres semanas largas de vacaciones totalmente desconectado de un teclado. Y me cuesta.

Programar es como cualquier otro trabajo / afición. Es igual que correr, o escribir en tu blog (si lo haces, claro, no como yo ahora) y supongo que será como tocar un instrumento. Cuanto más practiques, mejor sabes hacerlo. Y más sencillo te resulta, con lo que tienes más ganas de volver a ello. Y practicas otro montón. Se crea ese círculo virtuoso que habrá sentido todo el que, tras tres semanas de correr de forma regular, siente la adicción a las endorfinas. Por cierto, que esa es otra cosa que tengo que volver a empezar a hacer…

Recientemente he leído varios artículos sobre cómo aprender a hacer cosas mucho más rápido. Todos estos artículos tienen una idea común: practica mucho, «comprime» en el mínimo tiempo posible la práctica de un año de formación normal y obtendrás los resultados de un año de experiencia. Siempre he sido reacio a esta idea, y he pensado que aprender las cosas lleva su tiempo. Pero, ¿y si estoy equivocado, y con una forma distinta de ver las cosas puedo aprender un lenguaje nuevo de programación, tocar un instrumento, correr mejor o aprender un idioma más rápido? Este verano, voy a hacer algunos experimentos sobre la forma en que hasta ahora he tratado de aprender las cosas. A ver cómo me va.

Y eso me devuelve a la idea inicial: que tengo que ponerme de nuevo a programar. Pese a lo que puedan pensar los que quieren aprender a programar, a todos nos cuesta, a los que empiezan o a los que llevamos algo más de tiempo. Siempre cuesta empezar. Lo bueno, es que como dijo Pitágoras de Samos, «el principio es la mitad del todo».

¡Así que, menos llorar, y más programar! (Empecemos procastrinando viendo vídeos de la WWDC 2013, cuando vuelva a estar operativo el portal de Apple para Desarrolladores, claro 🙂 )

j j j

Mi participación en la 7ª Betabeers de Sevilla

Hablando en la Betabeers de Sevilla

Hace ya algunos días (concretamente el pasado 24 de Enero) se celebró en Sevilla la séptima Betabeers SVQ. Estas Betabeers, para quien no lo sepa (yo entre ellos no hace mucho) son reuniones de informáticos con diversos intereses, en las que se exponen temas y en los que su punto fuerte es el networking que se puede hacer. Es decir, que conoces a un montón de gente, lo cual te puede servir para que te echen una mano si estás atascado en un problema, para no sentirte solo siendo el único programador Clojure de tu ciudad, para encontrar empleo (si te sabes vender), buscar compañeros para un proyecto o, por qué no, contratar a alguien.

Los orgaizadores tuvieron la amabilidad de invitarme y brindarme la posibilidad de hablar sobre cómo iniciarse en el desarrollo iOS. Acostumbrado como estoy a estar siempre hablando de lo mismo a veces pienso si no seré un pesado y que todo el mundo ya sabe programar para iOS. Pero parece que no, así que aproveché para contar cómo empezar en esto de iOS y, ya que estaba, para promocionar la NSCoder Night de Sevilla (nuestra reunión de programadores Cocoa en Sevilla). Espero que la charla en sí gustase y fuera instructiva. Divertida, a juzgar por las risas lo fue. Si he atraído al lado correcto de la Fuerza a unos cuantos Sith me sentiré satisfecho.

Ambiente en la Betabeers

Tras las charlas (en esta ocasión también nos hablaron de cómo dar de alta bugs en Debian y de cómo realizar activismo social en Internet, charlas ambas muy interesantes y recomendables, como sus ponentes, @amayita y @edipotrebol) se retiraron las sillas y, ya todos de pie en corrillo, empezó la parte de «beers» de la reunión. Al estilo de una reunión de autoayuda, nos fuimos presentando y contando cada uno lo que hacemos. Es una buena manera de romper el hielo y conocer de un vistazo a gente con intereses similares a los tuyos.

Y tras estas primeras cervezas «de fogueo» nos fuimos a una cervecería donde, por un precio muy bueno salimos ciegos de comer y beber. En mi caso, Coca-Cola, que tenía que conducir. Soy un triste, ya lo sé…

Si quieres ver el ambiente, aquí hay un montón de fotos del evento.

Cosas que me han sorprendido

No tenía expectativas creadas, ya que era la primera Betabeers a la que iba en mi vida. Pero me esperaba una reunión pequeñita de programadores locales. Todos hombres. Varias sorpresas:

  • de pequeñita, nada. 70 personas es una reunión con nombre y apellidos. Esto no lo «juntamos» en una NSCoder Night ni pagando.
  • de local, nada. Allí había gente que ahora vivirá en Sevilla, pero que era de toda España. Esto me lo esperaría en Madrid o Barcelona, pero uno tiende a seguir pensando en Sevilla como un pueblo… el más bonito del mundo, eso sí 😀
  • multinacional. Había gente de otros países. Los había incluso que no hablaban Español, lo cual siempre da pie a una charla en Inglés. Esto es muy bueno, porque nos aporta la experiencia y puntos de vista de fuera.
  • había mujeres. Sin ir más lejos, Amaya que habló de Debian. Quien me conoce sabe que me da igual cómo seas, siempre que sepas hacer bien tu trabajo. Pero es raro encontrarse con mujeres en nuestro sector (una pena, esto parece un seminario). ¡Pero con mujeres que hablen de Debian!. Eso es para nota. Si llega a abrir una bash entro en shock… Aunque esto cada vez me pasa menos: en las últimas conferencias en las que he estado (especialmente en el iOSDevUK) he conocido a cada «mónstrua» que te deja pensando: «¿y ésta de dónde saca tiempo para meterse todo eso en el cerebro?».
  • muy, muy bien organizado todo. El sitio, la división en tiempo, la forma de facilitar el networking

Resumiendo este rollo: volveré, como dijo Schwarzenegger en Terminator.

j j j

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

Mi nueva máquina y por qué no me he comprado un rMBP

Foto de mi MBP 13 pulgadas abierto, con Safari corriendo Hace ya un tiempo que estoy por esas carreteras llevando mi nueva máquina, entre curso de iOS y Android. Lo anunciaba en Noviembre, mientras lo esperaba. Es un MBP 13″ no retina. Y para colmo con la CPU menos potente que vende Apple, un Core i5 dual core a 2,5 Ghz. «¿Cómo?», se preguntarán algunos, «¿todo el día hablando de tecnología y te compras eso?». Pues sí. Os cuento qué máquina me he comprado, las razones que me llevaron a ella y cómo la uso.

La máquina

Ventana Acerca de Este Mac abierta, mostrando las características del MBP

El equipo en sí es un MBP 13″ no retina, de Julio 2012. Por ello, tiene una resolución de pantalla infame (1280×800) pero a cambio tiene otras cosas muy interesantes dentro de su cuerpo unibody de aluminio: USB 3, una CPU que al tener dos núcleos con hiperthreading, se convierten en cuatro núcleos de ejecución, una tarjeta gráfica HD 4000 (no demasiado buena, pero es lo que hay) y un HD de 500 GB bastante lento. Dado que la máquina es capaz de direccionar hasta 16 GB RAM, pensé que en lugar de poner una CPU enorme era mejor equilibrar el rendimiento global del equipo. Así que compré un par de módulos de 8 GB y un SSD de 256 GB. En cuanto me llegó, le monté el SSD y la memoria y el rendimiento global es bastante impresionante. Evidentemente, un rMBP de 15″ tendrá el mismo rendimiento o más. Entonces ¿porqué esta?

Mis razones

El retina MBP es una máquina impresionante. Es como mirar al futuro y ver cómo serán los ordenadores dentro de cinco años. Pero mi equipo, además de mirarlo, tengo que usarlo. Y mucho. Y lo uso para dos tareas muy concretas: programar en el sofá o llevarlo a los cursos de programación que imparto. Así que casi todo el tiempo es acerca de programar. Una mayor resolución siempre es bienvenida (y ya me he quejado antes de la triste resolución máxima del MBP 13″, máxime cuando el MBA 13″ tiene 1440×900), pero entre la resolución retina y todo lo que pierdes a cambio, preferí el resto. ¿Y qué pierdes?

  • sensor de infrarrojos. No está en el rMBP. Ya no puedo usar mi mando a distancia Apple de aluminio para controlar KeyNote. Que sí, que puedo comprar uno BlueTooth, pero ya que tengo este y es sencillo de manejar…
  • indicador de batería. En el lateral del MBP 13″ hay una línea de LEDs y un botón. Lo pulsas y sin encender el equipo ves si tiene o no batería suficiente. Lo uso mucho.
  • puertos. Tengo discos FireWire que me gusta usar. Al igual que me gusta conectarme a la red con un cable Ethernet. Llámame viejo, o bien que 1Gbps siempre es más que 300 Mbps. Como tres veces más rápido y fiable. Ethernet no se «cae». O funciona bien, o se te ha quemado el switch. No hay otras calidades de servicio. Y se que tengo la posibilidad de usar el puerto Thunderbolt, en ambos equipos, pero no me gusta llevar adaptadores colgando, si puedo evitarlo.
  • posibilidad de ampliación sin hipotecarme. He podido ponerle un HD SSD y ampliar la memoria a mi MBP 13″. Al rMBP no se le puede ampliar, porque todo viene soldado.
  • mi mujer tiene un venerable MacBook blanquito de 2007. Su cargador es compatible con el mío. Nada de MagSafe2 ni historias: si pierdo el mío o explota, tengo un reemplazo de emergencia cerca.
  • pasta. El rMBP cuesta bastante más que el MBP 13″ y en mi opinión, salvo la pantalla y que pesa algo menos, no me aporta demasiado por su coste. Prefiero buscar ese MBP 13″, ampliarlo y comprar Apple Care. Y ya, para rematar el ahorro, he comprado el equipo Refurbished, con lo que te ahorras unos buenos euros.

El equipo que pienso es el que más prestaciones te da actualmente a un precio razonable es un MBP 15″ con resolución extra (1.680 por 1.050) y pantalla mate y con 16 GB RAM + SSD. Al tener una gráfica discreta, es la mejor opción. Pero quería renovar mi viejo MBP 15″ del 2008 por lo mínimo posible, y además quería cambiar de factor de forma y pasar a algo más compacto.

El rMBP 13″ me parece una buena idea, pero esperaría a una segunda o tercera versión. No tiene sentido que lleve la misma gráfica y CPU que el no retina y que por esa resolución extra tengas que pagar 498 Eur.

Cómo lo uso

Mi MBP es el equipo que uso para los cursos y salidas varias: a Conferencias, Hackathones, reuniones de la NSCoder Night de Sevilla, etc. Es muy compacto y me transmite una sensación de solidez. Arranca en muy pocos segundos (menos de 10) y todo es instantáneo. Con los 16 GB de RAM, nada hace swap y todos los procesos tienen más memoria de la que puedan necesitar. Y el acceso a disco es muy rápido gracias al SSD. El S.O. está instalado en el SSD y los datos en el HD. Todo como la seda.

Además de para los cursos, cuando puedo levantarme temprano lo uso para escribir código en Xcode / Eclipse. Y probar las Apps. Para eso, es perfecto.

Pero no todo es perfecto. Alguien pensará qué pasa cuando necesito más resolución, para trabajar cómodamente o usando Pixelmator o similares. Respuesta sencilla: para esos casos tengo mi iMac 27″ con su segundo monitor de 24″. Creo que con 2560×1440 + 1920×1080 (5.760.000 pixeles) tengo de sobra. Y pensar que mi primer AMSTRAD, en su modo de máxima resolución (MODE 2) alcanzaba 640*200 (128.000 pixeles). Eso sí, en blanco y negro, o en mi caso, en fósforo verde encendido o fósforo verde apagado 😀

j j j

Charla sobre «El estado de la nación móvil»

Hablando del estado de la nación móvil

Este pasado Miércoles 12, estuve en Sevilla impartiendo una charla sobre cómo está ahora mismo el mundo móvil, de la mano de Avante. Fueron cuatro horas (con un pequeño descanso) en el que apenas tuve tiempo de hablar de iOS y Android, y algunas cuestiones generales. Me lo pasé muy bien, relatando mis batallitas. Supongo que los asistentes (que me tenían que aguantar), no tanto.

Es increíble lo mucho que cambia esta parte del sector informático en meses. En Julio estuve en Zafra realizando este taller, pero con más profundidad, para ayudar a una empresa a elegir su estrategia móvil para desarrollo. Como eran programas in house y ya sabían Java finalmente vimos que lo mejor era la ruta Android. Pero desde entonces Samsung ha sido condenada por copiona, ha salido el Kindle Fire HD, el Nexus 7, se han anunciado los nuevos Lumias… Esto va a velocidad de vértigo y son tantas las plataformas y hay tanto ruido que es normal que el que no esté al tanto quiera alguna indicación.

Al fondo, inasequible al desaliento
La pena es que no pudimos hacer casi ni un hola mundo con Xcode. Quería hacer algo también con Android, pero fue imposible. O haber enseñado alguna aplicación webOS, o Windows Phone. Pero cuatro horas se van volando, cuando hablas de algo que te apasiona 😀

P.D.: Avante ha convocado un máster de desarrollo iOS, Android y Windows Phone. Tienes la oportunidad de aguantarme enseñando a programar en  iOS y Android si te apuntas 😉

P.P.D.: ya a finales de 2010 estuve hablando en un encuentro e-Tic de Avante sobre iOS. Hay vídeo para recordarlo.

j j j

BlackBerry Jam en Barcelona

El pasado Jueves 31 de Mayo estuve en la BlackBerry Jam que se celebró en Barcelona. Un evento en el que RIM está mostrando a los desarrolladores de todo el mundo su nueva plataforma, BlackBerry 10. Me invitaron a ir y no pude evitar aparecer. Encima, como bonus a todo un día viendo esta nueva tecnología, a los desarrolladores que nos registrábamos nos entregaban un dispositivo para hacer pruebas, un prototipo. El BlackBerry 10 Alpha Device.

Entre lo poco que dormí la noche anterior, el viaje ida y vuelta desde Sevilla a Barcelona, la alergia y alimentarme casi exclusivamente de azúcar y cafeína (dieta sana) la experiencia fue extenuante, pero muy, muy interesante. En el MWC acudí a las presentaciones del App Planet, que estuvieron bien. Pero aquí pude ver y probar código. Y preguntar cosas. Y eso sube el nivel de adicción de la sesión muchos puntos (al menos para mí).

Estuve con un montón de gente muy interesante. A algunos, como a Serantes, ya lo conocía del EBE. Con Hernán, de Aecomo he trabajado y da gusto tener un jefe que sabe tanto de programar como tú. Pude conocer fugazmente a NeuroFlip. La rabia es que, con el atontamiento que tenía encima no pude hablar con él de lo que de verdad me interesa: los Amiga :-).  Y otro montón de gente como @rallat, @jorgecasar, @ClaraCorretge, Pilar Bernat…

Reunión de cracks

Reunión de cracks

El día comenzó con las típicas charlas para mostrarte lo comprometida que está RIM, y cómo se está volcando con los desarrolladores. Y debo decir que me ha sorprendido mucho su cambio de actitud. Cualquiera que me halla escuchado en los últimos años sabe que no tengo demasiado cariño por BB7. Incluso me mofé de la PlayBook antes de que saliera, llamándola en el evento eTic «PlaySmoke». No me gusta que se hable de algo que no se puede tocar, y compararlo con un producto que se puede comprar en una tienda me parece ridículo. Toda idea que no se ha llevado a cabo tiene una posibilidad no finita de no hacerse nunca. Y luego estaba la actitud de RIM hacia los desarrolladores: o eras una gran empresa, o eras escoria. Ningún cariño hacia los desarrolladores indies e independientes. ¿Quieres un certificado para subir Apps a su tienda? ¡Paga 20 $ por él!. ¿Lo pierdes?. Pagas otros 20 $. Y el SDK ni te cuento… Muchas barreras puestas a los programadores. La guinda es que encima sólo se podía programar en Java… No demasiado excitante, vamos.

Pero el 2007 lo cambió todo. Y ahora lo importante de una plataforma no es su hardware, ni la marca. Lo importante es lo que las personas pueden hacer con ella. Y para ello, se usan Apps. Luego es algo central en la estrategia de cualquier plataforma el tener a cuantos más desarrolladores de tu parte, en tu ecosistema. Cierto es que todas quieren a los Rovio (Angry Birds) de turno, a los desarrolladores RockStar. Pero también hace falta crear comunidad, y tener a los menos importantes y torpes como yo, porque hacemos preguntas en StackOverflow, o subimos código a GitHub, o usamos la plataforma porque nos gusta y hablamos de ella. Todas las gotas cuentan para llenar un vaso.

Y debo decir que RIM se ha dado cuenta. Y ha creado una plataforma, usando QNX como base, que tiene una pinta increíble, tanto para el usuario como para el programador. Para el usuario, espero que BB10 sea la primera plataforma móvil mainstream que lleve los gestos de webOS o Meego a las masas. La multitarea real de QNX funciona muy bien, y el cambio de tareas mediante gestos (copiado de webOS) hace que sea muy sencillo e intuitivo. Y es algo que engancha, además de ser algo distinto: al final acabas haciendo gestos en el iPad. Al que esté aburrido de iOS o Android y de ver las filas de iconos típicas en la pantalla, BB10 le va a encantar. Luego está el teclado predictivo, que te permite rellenar las palabras según escribes con un swipe del dedo. O las notificaciones, implementadas de manera muy visual y sencilla de usar.

Y para los programadores, BB10 es una maravilla. Es la plataforma para el desarrollador inquieto. Puedes hacer aplicaciones nativas con C/C++. Si quieres construir los interfaces de usuario de manera más rápida, puedes usar Qt y Qml/Cascades, una implementación propia de RIM de Qt. O puedes desarrollar en HTML5 usando WebWorks, el framework HTML5 de BB10. Yo, por ejemplo, he portado las Apps que hice para webOS de manera muy rápida y sencilla. O si vienes de Android puedes empaquetar tu App para BB10 sin tocar una línea de código. Lo que va a permitir que muchas Apps de Android aparezcan en BB10. RIM se ha volcado y ha puesto los diferentes SDKs al alcance de la mano. Ya no te cobra por nada. Y hay montones de ejemplos de código fuente en su repositorio de GitHub.

Pero todo no puede ser de color de rosa, por desgracia. Como programador y geek, la plataforma me atrae y me tiene genuinamente excitado ante las cosas que se pueden hacer. Eso de volver a C++ para el desarrollo nativo, y poder escribir JavaScript dentro de los ficheros Qml que describen las vistas de los programas me encanta. Pero aprender cualquier plataforma supone una inversión. En tiempo, esfuerzo y, lo más importante, en ilusión. El año pasado empecé con webOS y, gracias a mi aura gafe, la plataforma se hundió, por mucho que Enyo siga avanzando como proyecto Software Libre. Ahora RIM dispone de la tecnología adecuada, y la usabilidad correcta. Y puede disponer de aplicaciones para su ecosistema, ya que BB10 va a correr casi cualquier cosa. La pregunta es ¿demasiado tarde?. Los primeros dispositivos BB10 aparecerán en el mercado probablemente para la campaña navideña. Y se van a encontrar con nuevos Android Nexus, creados por Google y Motorola mobile, ahora que ya autorizaron la compra. Y con Windows Phone 8 y las nuevas tabletas con Windows 8. Y, claro, el nuevo iPhone con iOS 6… Va a ser muy duro. Muy, muy complicado. Por eso mismo me gusta. Por lo mismo que sigo usando un Amiga 1200 o intento programar para MorphOS.

Porque me gustan las causas perdidas.

Aquí o consigues triunfar, o te hundes. Sin riesgo no hay gloria. Steve tampoco lo tenía fácil en el 97 cuando volvió a Apple, ¿no?. Nadie daba un duro por Apple. Así que yo voy a usar las plataformas que más me atraigan. Porque esto es cuestión de conocimiento y vocación. Y porque soy gilipollas.

 Actualización 4 de Junio

Otras reacciones a la BBJam que he leído son las de Serantes y Pilar Bernat.  Y en el lado más técnico, las de Android.es y Jorge del Casar.

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.

<

div class=»mceTemp mceIEcenter»>

<

dl id=»attachment_1707″ class=»wp-caption aligncenter» style=»width: 470px;»>

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 🙂