El lamentable estado de las herramientas de desarrollo iOS

Apelando a Murphy, voy a escribir esto justo antes de la WWDC, a ver si Apple me deja por tonto cambiando todo de lo que me voy a quejar aquí. Por desgracia no lo espero. Espero que presenten “otras 1000 APIs” que realmente no necesito. Lo que necesito es que eliminen los bugs que existen en las que ya hay. Y que las herramientas funcionen. No que añadan cosas. Que arreglen bugs.

Hace tres años escribí sobre El lamentable estado de las herramientas de desarrollo Android. En aquella época, lo que existía para desarrollo Android (oficial) era el plugin ADT para Eclipse. Y, como relato en el post, no funcionaba algo que era un simple ZIP. Eclipse, Java 6, fallos en las herramientas, un Android Studio que estaba en Alpha, una documentación horrorosa, una API discutible (ver p.ej. el método isUserAGoat en UserManager), la lentitud de Gradle si probabas AS… Esto era la muerte por mil cortes, comparado con el mundo iOS, con esas APIs Cocoa tan consistentes, un Xcode tan bonito y que entonces no fallaba tanto…

Y encima Apple presentó Swift en Junio de 2014. La promesa de un nuevo lenguaje, compatible con Objective-C, con C, C++, pero funcional, con inmutabilidad, Opcionales, genéricos, … Todo se veía de color de rosa desde el mundo iOS, comparado con el cenagal que era el desarrollo Android.

Apple: Non-Pro Macs

Apple ya no hace ordenadores para desarrolladores. Y me parece muy bien, si así gana más dinero. Pero debe entonces afrontar las cosecuencias, que van a ser (porque esto ya ha lo he visto antes en otras plataformas):

  • los desarrolladores se compran otras máquinas y se montan un Hackintosh para seguir desarrollando en iOS / Mac. MacOS se convierte en “ese sistema operativo que te ves obligado a usar por el trabajo”. Apple no gana dinero con las máquinas. Tienes dual-boot y cada vez usas más Windows. Peligro.
  • los desarrolladores directamente se pasan a Windows 10 / Linux con mejores portátiles (y a mejores precios, que no todos tenemos una mina de oro en el sótano de casa) y usan MacOS en una máquina virtual (cosa que prohíbe la licencia, como el Hackintosh, pero ponle puertas a ese campo…). Goto 1
  • algunos desarrolladores se cabrean tanto con el poco aprecio que sienten desde Apple que directamente abandonan la plataforma, algo que a dia de hoy se puede hacer ya que el mercado de trabajo tiene ofertas casi para todo tipo de perfiles de desarrollo.

Si los programadores se van de una plataforma, esta se muere. Lo he visto con OS/2, con Amiga, con Linux (¿este es el año de Linux en el escritorio? Y sí, ya se que se usa mucho Linux en Android, que es Linux, y en la RaspberryPi, y que llevo usando Linux desde el 93, que no me cuentes de qué va eso que yo voté porque Tux fuera la mascota de Linux y tú no).

Casi le pasa a Microsoft. El rechazo que generó con sus Internet Explorers le ha llevado a ceder casi toda la cuota de mercado a Chrome. Y no hablemos del patinazo Vista, que enmendó con Windows 7. Es por eso el titánico esfuerzo que está haciendo ahora mismo Microsoft, permitiéndote ejecutar Linux en Windows de forma nativa, o dándote la bash. Atraer programadores que son los que riegan este campo con sus aplicaciones.

2017

Es 2017. Swift va a sacar la versión 4, con nuevos cambios que te obliguen a actualizar tu código, o no compila. Con ese asistente que tiene Xcode tan bueno. Si no tenías listo el lenguaje en 2014… ¿para qué sacarlo? ¿Porque Chris Latter estaba harto y se quería ir? Pero bueno, era 2014 y podíamos entenderlo, Apple. Pasamos por Swift 1, 1.1, 1.2, y los cambios a Swift 2. Y Swift 3. Contínuamente cambiando una base de código que funciona para hacer que siga funcionando. Es decir, gastar horas para seguir en el mismo punto. No añadir nuevas funcionalidades. Que compile. Coding is fun.

Al menos el compilador de Swift es rápido. Tanto, que cuando ejecuto Gradle en Android me parece instantáneo. Gradle, quiero decir. Pero en cada WWDC nos dicen que “ahora el compilador de Swift es un 20% más rápido”. Con tantos avances en velocidad mi código debería terminar de compilar… en 1984. De lo rápido que compila. Pero la realidad es la realidad, y Swift es horriblemente más lento compilando que su equivalente en Objective C. Y es una pena, porque el lenguaje es muy bonito. Apple ha hecho un Sherlock de Kotlin con Swift, lo que está bien. Si ahora hiciese un Sherlock de IntelliJ, todos contentos.

Porque cansa ver cómo se arrastra el compilador. Cómo haces Cmd+click en un símbolo y no lo encuentra (es una función de ámbito global y no la encuentra). O cómo el autocompletado es totalmente random. O cómo pones un punto de ruptura dentro de una clausura y no puedes depurar el valor de las variables de la clausura. Bueno, sí puedes… usando println. NSlog oriented debugging FTW!

Al menos podemos refactorizar nuestro código. Esto significa que puedes cambiar el nombre a una clase. Fin de los refactors. Y en Objective-C. En Swift nada. Zero. Nil. Y de generar código ni hablamos. Últimamente Xcode no es capaz ni de comentar líneas de código con Cmd + / o acertar y autocompletarte los nombres de las librerías en los imports.

O cómo la comunidad ha tenido que solucionar problemas básicos que Apple se niega a ver. ¿Resolución de dependencias y librerías de terceros? En Android: Gradle. Soportado. En iOS: CocoaPods, Carthage, o a mano. Todos proyectos de la comunidad. ¿Plugins? En Android: Android Studio tiene de todo. En iOS: han metido un sistema de plugins tan restringido que, la verdad, no conozco a nadie que esté usando algún plugin que merezca la pena (indicadme por Twitter los mejores, por favor). Y de paso se han cargado un proyecto como Alcatraz, que sí que ofrecía un montón de plugins, temas y plantillas de ficheros porque, ¿quién quiere algo mejor cuando mi versión inferior patentada por Apple ya viene con Xcode? Y sí, entiendo los problemas de seguridad de los plugins, y que Xcode viene firmado y todo eso. Pero digo yo que habrá alguna solución intermedia colocando los plugins en otro proceso fuera del sandbox de Xcode…

WWDC

Así que, en esta próxima Developers Conference, vamos a abrir la Keynote hablando de lo mucho que vendemos, de lo buenos que son los portátiles con la ToyBar, de lo chulos que son los auriculares Beats, de todas esas cosas que nos interesan muchísimo a los programadores, que es a los que debe ir dirigida la Keynote. Nuevos colores para las correas del reloj. Nuevas animaciones en macOS para organizar tus ventanas en 15 espacios para que nadie lo use nunca, porque todos usamos un monitor externo. Y Apple Music, que todo programador necesita música de fondo y eso. Pagando.

Pues no. Este año no renové mi Apple Membership por primera vez en 6 años. Y cada vez me cuesta más y me duele más abrir Xcode. Porque veo lo que podría ser, lo comparo con un excelente IDE (con sus problemas, pero mucho mejor para escribir código) como IntelliJ y me sangra el corazón. Quiero seguir programando en un Mac en 2027. No me eches de tu jardín, Apple.

j j j

Cómo ver los vídeos de la WWDC 2015

…y no dejar que Twitter, y los sobrehumanos que por allí pululan, me machaquen con sus capacidades heroicas de ver en una semana todas las sesiones.

Terminó la WWDC 2015, y como todos los años, me he echo un firme propósito: ver todos los vídeos antes de que llegue la WWDC 2016. Si miro mi track record en este tema, no es para ser optimista: siempre he fracasado. Esto es mi voy a dejar de fumar o tengo que aprender alemán. Lo de los kilos, es evidente a simple vista que tampoco lo llevo bien del todo.

Sí, lo confieso, voy por el mundo desarrollando para iOS y a veces enseñando sobre ello y no he visto todos los vídeos de todas las WWDCs. Una vergüenza, ya lo se. Últimamente, mi síndrome del impostor está súper-desarrollado y tengo muy asumido que soy una estafa con patas, pero eso es tema para otro post. Así que esta vez va a ser diferente. Tiene que ser diferente. Me voy a organizar de manera diferente y quizás alguna de estas ideas os sirva para algo. O no.

Good Ol’ Streaming

El streaming y todas estas cosas modernas están muy bien y tal. Hasta que tienes que ver un vídeo y se ha caído tu conexión. O quieres copiar unas cuantas sesiones a tu iPad para estar entretenido en un vuelo, y necesitas tenerlas en tu Mac primero. Y en cualquier caso, porque mañana puede estar caído el servidor de Apple o pueden retirar los vídeos a voluntad. Mi estrategia es sencilla: aquellas cosas de Internet que de verdad me interesan van a mi Drobo o a cualquiera de mis HDs externos. Al coste por GB actual, ni me lo pienso. Para bajar los vídeos os recomiendo este script, que además se baja los PDFs con las presentaciones y el código fuente de los ejemplos. Todo lo necesario para explorar las sesiones. Es bastante configurable y puede bajarse los vídeos de otros años, grabar en la carpeta que le indiques, descargar en calidad SD o HD…

Para instalar el script, debes mostrarlo en formato “raw”, es decir, en texto plano (pulsando en este enlace lo tienes, de nada, soy así de majo), seleccionar todo el texto y copiar y pegarlo en un fichero de solo texto. En mi caso, uno que me creado con vi. Lo llamas como quieras, pero download-wwdc-videos.sh no es mal nombre. Te quedaría por darle permisos de ejecución con la orden: $ chmod a+x download-wwdc-videos.sh.

Para bajar los vídeos la orden que he usado es:

./download-videos.sh -f HD -o ./

que significa: “baja los vídeos de la WWDC 2015 (por defecto), en calidad HD (caballo grande, ande o no ande) y me los pones en la carpeta actual”. Previamente me había creado esa carpeta en el Drobo y había ido en iTerm con cd /Volumes/Video-Drobo/WWWDC-2015 hasta la carpeta en cuestión.

Separar la paja del grano

No todas las sesiones me interesan. Y a ti tampoco deberían. Hay que tener foco y empezar por aquellas que realmente te van a aportar más. Por ejemplo, la entrega de los Apple Design Awards es algo que no me va a hacer más feliz. Las nuevas características de Swift 2.0, sí. Así que hay sesiones que me interesan seguro, otras que ya habré visto y otras que, o seguro no quiero ver o estoy en duda. Primera criba resuelta: si dudas, es que no quieres verlo. No pasa nada, no borres el vídeo (yo no lo hago), no se va a ir de ahí. Pero si no tienes claro de entrada si te sirve para algo, es que no te sirve verlo ahora.

Videos WWDC 2015 con etiquetas

Videos WWDC 2015 con etiquetas

Para distinguirlos he usado las etiquetas del Finder, que puedes cambiar y crear en preferencias del Finder. Me he creado tres nuevas: Ya vistos, en color verde, pendientes, en color naranja (que destaque) y en gris no me interesan. Marco todas en gris y a partir de ahí selecciono con mucho cuidado las que quiero ver. Es mejor marcar sólo cinco vídeos, verlos, y tener la sensación de he cumplido esta etapa y poder volver y añadir más vídeos luego para subir nota. Mucho mejor que marcar cincuenta vídeos y cargarte con una obligación más todo un año. Además de todas las otras cosas imprescindibles que ya tienes que hacer: leer todos los feeds RSS, leer completo tu timeline de Twitter, leer las noticias diarias, etc.

Pista: no lo hagas. Sobrecarga de información inútil == ruido.

Preferencias del Finder para gestionar las etiquetas

Preferencias del Finder para gestionar las etiquetas

Ver los vídeos

En mi caso, si puedo, los veo en el iMac. Porque estos vídeos no basta con “verlos”. A mi me gusta tener abierto Xcode y los ejemplos de código, y cuando veo algo que me llama la atención pauso el vídeo, tomo notas, pruebo código, etc. Sin hacer esto, a los dos minutos de terminar el vídeo no recuerdo nada. Si no intento repetir la demo que estoy viendo, no voy a aprender nada.

Así que en mi caso, nada de verlos a 2x para marcarlos como vistos. A mi me interesa marcarlos como aprovechados, que es distinto. Lo otro es como visitar 10 ciudades en 7 días e ir de Turista. Yo prefiero ver una y vivir 10 días en ella.

Para verlos, los añado a iTunes. Pero con cuidado. Si arrastras la carpeta de los vídeos a iTunes se van a copiar dentro de la biblioteca, duplicando el número de GB. Que puede ser que sea lo que quieres. O no. Siempre puedes borrarlos. En mi caso, los vídeos se quedan en su carpeta del Drobo y sólo enlazo el contenido. Para ello, en las preferencias de iTunes debemos desmarcar la opción Avanzado > Copiar en iTunes Medio los archivos añadidos a la biblioteca que copia por defecto los ficheros dentro de nuestra biblioteca. Ahora podemos arrastrar los ficheros y no se copiarán. Pero podremos sincronizarlos con nuestros dispositivos (en mi caso, mi iPad), para verlos sin conexión. Win!

Programar y tomar notas

No te quedes sólo con los vídeos. Crea tus proyectos de prueba, escribe código usando los Playgrounds de Xcode. Usa las betas de Xcode 7. Y si encuentras errores file a radar. En mi caso, por cada vídeo que voy a ver, creo una tarea en Things, que es lo que uso para llevar un sistema más o menos GTD. En esta tarea anoto cosas que me llaman la atención, de forma que siempre puedo volver y buscar esta tarea para revisar las notas. Si las notas crecen mucho, o van a un Playground junto con código de ejemplo, o a un fichero de texto markdown que luego presento con Deckset.

End

Y esto es todo. Espero esta vez no sentirme culpable cuando compruebe que es Junio de 2016 de nuevo y no he visto más que tres vídeos. Pero una cosa es segura: tampoco voy a poder verlos en una semana. Hay muchas cosas que aprender, y una vida que vivir.

j j j