Voy a aprender Git

Git. Ese sistema de control de versiones para superdotados. Es un hijo de Linus (el creador de Linux). Por ello, la sencillez no es una de sus características. Si alguna vez has configurado y compilado un kernel de Linux, sabrás que a este señor no le gusta ningún programa sin al menos cincuenta opciones en la línea de comandos: veinticinco empezando por -y otras veinticinco por --. Y diez más que no están documentadas. Para usar Git se asume que ya tienes de antemano una serie de habilidades (manejo de la Terminal, uso de ssh, resistencia innata al desaliento ante una documentación fea como un demonio, coeficiente intelectual de 300, …)

Así que uso habitualmente Mercurial (siempre que puedo, antes que Git) por varias razones:

  • me resultó muy sencillo aprender a usar Mercurial gracias al excelente tutorial de Joel Spolsky
  • el 80% de las cosas que haces habitualmente es muy sencillo de hacer con HG
  • no necesitas configurar nada: te lo bajas, lo instalas, vas a una carpeta, escribes hg init y listo
  • tanto BitBucket como SourceTree lo soportan. Luego es perfecto para mi.
  • si funciona, no lo toques

Pero claro, no se Git. Y me siento estúpido.

Hay varias cosas que considero «la maratón mental del informático». Lo que distingue a los buenos de los que tienen que seguir esforzándose. Cosas difíciles, que te obligan a aprender y a exprimirte el cerebro. Por supuesto, no he hecho ninguna de ellas, autocolocándome en uno de los dos anteriores grupos. Estos retos son:

  • dominar el uso de expresiones regulares (sin mirar en StackOverflow)
  • escribir una pequeña aplicación o demo completamente en ensamblador
  • hacer una aplicación web en un lenguaje funcional, como Clojure
  • hacer un juego usando OpenGL
  • entender qué demonios hace git con las ramas y git flow

Pues bien, una de ellas voy a tacharla de la lista, pero ya. El uso de Git está muy extendido, y soluciones que uso habitualmente como Cocoa Pods lo utilizan de forma extensa. Tengo que aprender a usarlo, quiera o no. Además, en varios proyectos se necesita Git y aunque con SourceTree puedo ir tirando, quiero comprender qué se cuece tras la interfaz bonita y ser capaz de manejar este DCVS yo solito.

La opción de leer un libro me aterrorizaba: demasiado esfuerzo tras tanto esfuerzo con otras cosas. Así que la mejor solución va a ser asistir al curso Entendiendo Git que Alfonso Alba imparte en Las Rozas. Creo que aún estás a tiempo de conseguir un descuento por compra anticipada. Voy con muchas esperanzas puestas en el curso, para tener una base que me permita manejar en el día a día este DCVS sin problemas, y explorar por mi cuenta. Vamos, que espero entrar chapurreando un par de palabras en Git y salir hablando, con acento y poco vocabulario, Git. Pero entendiéndolo al menos.

Escribiré qué he aprendido en el curso cuando lo termine. Pero conociendo a Alfonso de las NSCoder Night de Madrid creo que la duda no está en la calidad del curso, sino en si mi mente será capaz de pasar por la maratón. Espero que si.

j j j

Especial MacWorld Mountain Lion

MacWorld Práctico Especial Mountain Lion

No es ninguna novedad y, probablemente ya no quede ninguno en los quioscos. Pero sentía que tenía una deuda conmigo mismo y quería hablar acerca de lo último que escribí para la ahora difunta MacWorld España. Concretamente, este número especial sobre cómo usar OS X Mountain Lion que se publicó en Enero. Mi legendario efecto gafe, capaz de acabar con webOS o poner en serio aprieto a Nokia, ha sido capaz de acabar con la revista para la que a veces escribía como colaborador.

El caso es que estuve dedicado a escribir este tocho durante Agosto de 2012, esperando que si me enfocaba y esforzaba lo suficiente finalmente lo acabaría para primeros de Septiembre. A punto de llegar Septiembre vi que no lo tenía listo del todo, pero sí que había reunido un tocho considerable y que no me quedaría tanto: había cumplido con el plan de trabajo. Una vez enviado el borrador, me dieron la mala noticia de que el enfoque no era el esperado: se necesitaba un tutorial paso a paso, y no una review y opinión sobre el nuevo sistema operativo de Apple. Patinazo en toda regla.

Durante Septiembre y Octubre estuve muchas horas, muchas, dedicado a ir avanzando el libro. Finalmente lo entregué. Parir cualquier cosa escrita siempre es más duro de lo que uno espera. Pero cuando hablamos de un documento de este tamaño (más de 140 páginas de revista escrita casi sin publicidad, lo que haría un librito de unas 200 páginas o más) cualquier previsión que hago siempre se me cae al suelo. Y debería tener experiencia: en 2011 estuve escribiendo unos manuales para cursos de teleformación, he escritos algunos artículos para MacWorld y PCWorld y hace mucho se publicó un especial sobre Linux (era mi época Linuxera) que tecleé enterito.

Con una suerte digna de mejor causa, en Enero me encontré al pasar por un kiosko, en Madrid, con la revista. Iba a impartir una de las jornadas del curso a medida avanzado de iOS que tuve el gusto de dar a la gente de Redsys junto con Mobile Business School. Cuando tuve la revista en las manos, no la reconocía. Claro, yo sólo la había visto en la pantalla de mi iMac dentro de Pages, pero no había visto la versión final. Supe que era la mía por el artículo sobre accesibilidad que Jonathan Chacón tuvo la deferencia de escribirme para que apareciera en el especial (¡gracias, Jonathan!). Y ahora, aquí la tengo.

Es un recordatorio de varias cosas, y con el ansia de automachaque que define a todo buen informático, para empezar todas las que me recuerda son malas:

  • la próxima vez no uses Pages para escribir un libro. Si tienes una licencia de Scrivener, aprende a usarlo. Es la aplicación definitiva para escritores. Ahora me he dado cuenta, tarde, pero mejor que nunca.
  • si te encargan escribir sobre algo, pregunta antes de empezar por el enfoque. Define los requisitos, como con un programa. Si al cliente no le gusta lo que has hecho, vas a tener que empezar de nuevo y no va a ser divertido.
  • se pesimista con las estimaciones, y después de eso, aplica un factor de corrección de +50% del tiempo que has estimado. Y aún así ni te acercarás. Escribir lleva mucho tiempo, y por mucho que invoque mis capacidades super heroicas, luego no se avanza al ritmo que se quiere, sino al que se puede.

Pero también he aprendido mucho sobre mí mismo y sobre las herramientas que he usado. Vamos, que algunas cosas he hecho bien:

  • ya que tenía que escribir sobre OS X Mountain Lion, he aprendido mucho sobre el OS. Ahora hay un montón de cosas más que se hacer.
  • he mantenido un ritmo constante de escritura. He sido bastante disciplinado y todos los días escribía un par de horas. Ni yo me lo creo.
  • me he agobiado, pero dentro de un límite. Cuando me dieron la mala noticia, en lugar de cabrearme y gritar saqué mi libreta y me hice un mapa mental para comerme ese marrón. Y convertí el problema amorfo en una lista de tareas que podía ir resolviendo.
  • tengo a mi lado un recordatorio en papel, algo físico, de que soy capaz de escribir un librito si me pongo a ello. No me he dado el tiempo para disfrutar de esto, quizás es ahora la primera vez que estoy reflexionando sobre ello.
  • he aprendido a usar algo más de Pixelmator, para editar las imagenes de las capturas. Mola.

Así que ya está. El libro está en mi mesa. El trabajo terminado. Pero MacWorld ha cerrado, mucha gente ha perdido su trabajo y probablemente nadie lea este número, al que he dedicado tantas horas. Al no estar en edición digital (en Zinio, por ejemplo) poca gente lo va a leer. Y eso me deja un poco triste.

Ahora tendré que matar el gusanillo de escribir de alguna manera. Probablemente escribiendo un libro para enseñar a desarrollar Apps para iOS. ¿Alguien interesado? Acepto ideas y sugerencias. Luego haré lo que me de la gana, pero prometo tenerlas en cuenta 😀

j j j

Preparando el MWC 2013: First World Problems

Hay problemas importantes. Luego están las chorradas. Y por último, en orden de importancia los problemas que nos crea en el primer mundo la «sobreabundancia». Que si estamos muy gordos (porque tenemos para comer en exceso), que si pagamos muchos impuestos al comprar una segunda vivienda (pero ya tenemos más de una), etc. Pese a no ser problemas de vida o muerte, y sabiendo que gran parte de la población mundial nos cambiaría sus problemas, reales y auténticos por los nuestros, no dejan de ser nuestros problemas. Los que nos molestan, nos enojan o nos quitan el sueño.

No puede usar su nuevo iPhone 5 en su Audi, así que tiene que aguantarse con su iPhone 4s

El caso es que la semana que viene me voy al Mobile World Congress 2013 que tiene lugar en Barcelona. El año pasado estuve y me lo pasé bien, pese a que llegué enfermo y me tuve que curar una gripe «en pie» para no perderme el espectáculo. Este año, además de pasarlo bien, como ya se de qué va esto del MWC voy a procurar no pagar la novatada. Por ejemplo, este año no voy a estar allí a las 9 de la mañana, que está todo cerrado y te miran como lo que eres: un friki ansioso. Y voy a enfocarme más en las reuniones y en los contactos. Fem negoci, que dicen los locales.

Y claro, puestos a ir, surge la pregunta de todo geek bien equipado: ¿qué me llevo?. Esta pregunta es el equivalente del «¿Qué me pongo?» de nuestras novias / esposas, pero trasladado a cacharros. Porque, ya que tengo una serie de chismes, quiero aprovecharlos y sacarlos a que les de el aire.

La primera cuestión es si llevar el portátil o no. Y creo que va a ser no. Pese a que me encanta mi MBP 13″, del que ya escribí hace no mucho, no acabo de ver el sentido de llevármelo. Salgo de Sevilla el Lunes a las 8:30 en AVE y llego a BCN a las 14:30. Y dudo que me ponga a programar al llegar. Y una vez te metes en la locura del MWC, no creo que escriba una línea de código. Dentro del recinto, es seguro que no voy a hacer nada de eso. Y fuera, siempre habrá alguna reunión a la que ir, un rato para dormir o comer, o estar con gente. Y el Jueves a las 16:00 me vuelvo. Vamos, que no me lo llevo. Ya escribiré código el Viernes. El problema es que veré a otra gente con sus portátiles y me entrará morriña

Luego viene el asunto de la cámara. Teniendo una flamante Nikon D5100, quiero llevármela. Pero el chisme pesa lo suyo, y no voy como periodista (al final no pude conseguir una entrada de prensa por detalles sin importancia, como el cierre de MacWorld 🙂 ). Así que estoy pensando en usar los móviles / tabletas y una compacta Sony que apenas uso (no la uso porque hace fotos aceptables a la luz del sol, pero en interiores es directamente una basura, la compré con los puntos de la gasolina). Venga, segundo tema liquidado: la compacta y el resto de móviles / tabletas harán de cámaras oficiales.

Siendo el Mobile World Congress, hay que llevarse móviles y tabletas. En este apartado lo tengo casi claro. El iPhone 3Gs (que hasta ahora está siendo mi móvil principal) se viene conmigo, sin SIM, o con una de repuesto que tengo por ahí. Mi BlackBerry Alpha Device se viene, probablemente con la microSIM que tiene ahora el iPhone. Y la duda es si llevarme o no el Lumia 800, para ir cambiando. El iPad 3 en el que estoy escribiendo ahora mismo esto con iAWriter se viene seguro, junto con un teclado Apple BT inalábrico. Será mi portátil de guardia, en el que leer el correo, consultar Evernote, escribir, subir posts a WordPress. Vamos, que va a llevarse la parte importante de la paliza. Y claro, hablando de tabletas, me llevo también la Nexus 7, mi ojito derecho que me acabo de comprar, por si pruebo cosas de NFC. No me había dado cuenta hasta ahora, pero voy a llevar un dispositivo de cada S.O. principal: iOS, BlanckBerry 10, Windows Phone y Android. Geek Achievement Unlocked

Además de esto me llevaré cargadores y cables varios, algún pendrive por si hay que transferir un fichero en el último momento y creo que nada más. Ya tengo pensada la bolsa que me voy a llevar, una muy ligera que me regaló Migue Terrón y que él define «de los chinos» pero que parece cortada para este evento. O eso, o me llevo una que tengo por ahí de BlackBerry.

Y ahora paso a preguntar ¿qué te llevarías tú?. ¿Hago bien dejando el portátil detrás?. ¿Me llevo la cámara? Me gustaría contrastar opiniones en los comentarios.

j j j

Escribir en lugar de leer

Leer el correo. Los feeds. Consultar Twitter. Mirar mi grupo de Amiga and friends en Facebook. Ver un vídeo en Youtube. Consumir. Leer. No reflexionar.

Sin pretenderlo, a lo largo de los años he terminado escribiendo bastante. No sólo en el blog, ni en el correo, que eso lo hacemos todos. En revistas, como PCWorld o MacWorld (un minuto de silencio por esta última). O preparando material para algún curso. El caso es que es algo que me gusta, además de tener que hacerlo para ganarme la vida.

Cuando era adolescente, además de leer mucho escribía algunas cosas. Y es algo que me gustaría volver a hacer. Por eso, me voy a proponer lo siguiente: escribir antes de leer. Escribir el mismo tiempo que dedico a consumir información. Aprovechar los huecos del día escribiendo algo, lo que sea, para fomentar el hábito. Hacer eso, en lugar de dejar a mi mente vagabundear por Twitter y Youtube. Y si lo que sale es basura, borrarlo, pero si es aceptable publicarlo. Creo que dedicamos mucho tiempo a anestesiarnos el cerebro haciendo lo sencillo. Leer en lugar de escribir, escuchar en vez de pensar, dudar en lugar de tomar decisiones. Así que voy a centrarme y escribir más.

Dejad de leerme y haced lo mismo.

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

La BcnDevCon

Acabo de volver de Barcelona de la BcnDevCon, una conferencia de desarrollo en la que he participado como desarrollador aprendiz (siempre hay que estar aprendiendo algo) y como ponente. Al paso de visitas que llevo a Barcelona me voy a tener que acabar empadronando allí. Aunque me gustaría variar un poco la zona de la ciudad, porque siempre me toca aproximadamente por El paralel y me gustaría hacer algo de turismo.

En esta ocasión he estado hablando de como integrar la biblioteca de pagos móviles de PayPal en una App nativa iOS. Quizás no sea lo más apasionante de mundo, pero hay que pagar facturas. Y ya que estábamos en ello, intentamos pasarlo bien. Con Hernán Rodríguez y Jesús Arias, de PayPal montamos un pequeño teatrillo en el que Hernán era un cliente con una web de venta de canagers que me contrataba para hacerle una App iOS de venta de sus figuritas. Yo hacia de programador Friki desbordado (es decir, me interpretaba a mi mismo, como Antonio Resines en todas sus películas) que contactaba con Paypal y creaba la App. Nos echamos unas risas en el escenario con las típicas coñas(quien halla asistido a uno de mis cursos sabe a lo que me refiero) y mostramos un ejemplo casi real. Que además he subido a Bitbucket y puedes bajar para verlo y usarlo. Es un ejemplo sencillo de cómo usar JSON, leyendo en un hilo en paralelo para mostrar los caganers en un UITableView. Nos quedó una sesión creo que entretenida, aunque el tema (pagos móviles) no parece a priori el más divertido.

Así que mi experiencia ha tenido tres partes: el Jueves, antes de actuar, el Viernes con la actuación y el Sábado de relax.

El Jueves

Viaje con un madrugón mortal (me levanté a las 5 de la mañana, y lo pongo aquí porque creo que a Hernán no le quedó claro del todo ;-)). En el avión, roncando desde antes de despegar. Llegué en taxi a la conferencia y dejé la maleta en el «cuarto» donde la organización tenía las cosas. Y me senté en una de las mesas donde luego tuvo lugar el hackathon a terminar la App de demostración del Viernes.

Además de programar, me dio tiempo a asistir al taller de introducción a OpenGL que impartió Fernando Rodríguez. Ahora OpenGL ya me suena a Inglés, no a Chino. Seguiré intentándolo, porque no tengo ni idea y es una asignatura pendiente (como el dominar las expresiones regulares, o ser dueño de una isla en el Caribe).

En la comida coincidimos muchos y con gente que ya conocía de la NSCoder Night de BCN y de verlos en Vilanova i La Geltrú, especialmente @acuarioverde y @risalba. Buena charla, geek como corresponde, y una paliza de comer: pedimos menú para dos en un chino y éramos dos. Resultado: sobró comida. En un chino, si pides menú siempre debe ser: (número de comensales)-1.

Me encontré también (la pena es que fue de pasada) con Pedro Santos, crack Agile y con mis ex-alumnos de Code D’Azur, Tamara y Gerardo, que son para comérselos a besos. Ya han superado al maestro. Se iban a su cena de navidad, a Holanda. Ventajas de estar en una empresa como Dios manda. Saludé de pasada a David Bonilla, pero no pude fagocitar su tiempo, primero porque tenía cosas que hacer y segundo porque estaba rodeado de gente que lo querían todo para ellos.

La cena con BB10

El jueves tuve una cena de lujo en la Barceloneta. Con Hernán, John Murray y Jorge del Casar, dos developer evangelists de RIM estuvimos hablando de muchas cosas, todas muy frikis, pero sobre todo de BB10. Cada vez me gusta más esta plataforma. Tengo que meterme a fondo y en serio y empezar a parir Apps con Cascades. El caso es que al lado de estos de RIM te sientes un enano mental: saben muuuucho y son «developers, developers, developers» hardcore como el resto. Nada de encorbatados. Que la imagen que yo tenía de RIM se está revelando muy equivocada. Y que tengo que leerme mucho libros y comerme muchos bollicaos para ponerme al nivel de estos tres.

Nos tomamos dos botellas de Albariño mientras John nos explicaba las bases de NFC. Alucinante. La copa posterior me dejó en malas condiciones para la charla del Viernes.

Viernes y Sábado

Scumm Bar de Attlasian. Las cosas de David Bonilla

El Viernes apelé a mis superpoderes de conferenciante y feriante para que no se notara la resaca. Y creo que conseguí engañar al auditorio. Ayudado por la cafeína y un bocata de atún que compré en el stand de Attlasian (por cierto, unos cachondos estos con el nombre del bar) aguanté hasta la una. Luego nos fuimos al apartamento, comimos por el camino y me regalé una tarde en pijama trabajando con el portátil en el sofá tras una siesta de tres horas. Luego una carrerita de 7 Km para mover el barrigón y a cenar.

El Sábado acudí a dos talleres muy buenos. El de Unity, donde me enteré de qué va el motor y el de Cocos 2D, donde aprendí sobre la versión 2 del framework, de la mano del crack Alberto González. Luego la comida en Can Eusebio (excelente) y ya de vuelta a la BcnDevCon a continuar con el café y la charla política.

Conclusión

La conferencia en sí me ha gustado, pero como todas las cosas, se puede hacer mejor. La Wifi ha dado bastantes problemas y ha sido una queja constante. No disponer de badges para identificarnos era un rollo. Con unas pegatinas para poner el nombre y tu Twitter hubiera bastado. Y la insonorización del Museo era nula (aunque esto se entiende que era muy difícil de conseguir). Pero tras haber estado en las instalaciones del CCCB veo que hay otras alternativas en BCN. Otra cosa son los precios, claro. Otra sugerencia: un «muro» para que gente que busca y ofrece empleo se encuentre, dejando sus tarjetas de visita.

Ya se que es muy fácil criticar y más difícil hacer, crear y currar. Por eso propongo mejoras, para que sea una mejor conferencia el año que viene. En cualquier caso: gracias.

j j j

La dulce espera

No, no estoy esperando un bebé. No estoy «embarazado»‘, como se suele decir en estos casos. No, espero un «niño», pero de otro tipo. Me he comprado un ordenador nuevo. Y, de nuevo, como cada vez desde que me compraron mis padres mi primer Amstrad CPC 464, cuento las horas y fantaseo pensando en lo rápido que va a funcionar el nuevo equipo, la de cosas que voy a poder hacer con el, lo feliz que me va a hacer…

Así somos los informáticos. Tontos hasta decir basta. No conozco otras profesiones en las que pase esto. No me imagino un albañil llegando por la noche a casa excitado porque en el trabajo le han puesto una hormigonera nueva y contándole a su mujer: «no veas lo bien que hace el hormigón, no hace apenas ruido, está limpita y con la pintura aún sin ensuciar, me voy a pasar toda la noche haciendo hormigón y mañana voy a grabar una comparativa con las otras hormigoneras…». Vamos, que no lo veo. En lo nuestro el salario es algo importante, pero los chismes también. Nos gustan demasiado los gadgets. Es también lo que nos ayuda a no volvernos locos, con tantos cambios (y tan rápidos).

Material para la ampliación del nuevo MBP

El Jueves, cuando  llegue el equipo, le voy a instalar algunas ampliaciones, que podéis ver en la foto. Los detalles del «mini-bicho», cuando esté montado 😀

La única «pena» que tengo: he tenido que vender mi viejo y queridísimo MBP 15″. Ha sido mi primer Mac, y ahora me está dando realmente pena deshacerme de el. Pero las cosas cambian, y hay que cambiar con ellas. Al menos se que estará en buenas manos.

j j j