iPhone, MonoTouch y la insoportable levedad del ser: El comienzo

Cumplido ya el primer semestre del año 2010 puedo asegurar que el año se está desarrollando de forma excesivamente extraña para mi gusto. Bastante revuelto. Y no necesariamente tiene que ver con la crisis económica que está poniendo patas arriba todo y a todos. Un año raro. Muy raro.

Raro en el aspecto laboral también. Y esto tal vez sí se excuse en la crisis. Tal vez. Me encuentro en un constante «ahora sí, ahora no» y los proyectos que empiezo se caen con «mucha facilidad». Hoy te dicen que sí, trabajas todo un fin de semana para adelantar y el lunes a primera hora te dicen que se lo han pensado mejor y que va a ser que no. Espero que el segundo semestre sea más tranquilo y el balance anual mejore.

Una de las cosas que hice en los últimos meses de mi estancia en Madrid estuvo relacionado con un proyecto para iPhone. Por simplificar diré que las personas que tenían experiencia en desarrollo para iPhone estaban involucrados en otros proyectos que no podían abandonar de ninguna manera. Simplemente imposible e impensable. Así que, de la noche a la mañana, tres pelagatos nos vimos involucrados en un proyecto para el que, técnica y cognitivamente hablando, teníamos bastantes lagunas. Aunque no negaré que me encantaba la idea de participar en un proyecto para iPhone, algo que llevaba tiempo deseando.

No me asusta el desconocimiento en tecnología ni en lenguajes de programación. Es lo que me gusta, tengo suficiente bagaje para aprender con rapidez y mis decisiones, muchas veces fundamentadas más en la intuición, fruto de la propia experiencia, que en un análisis estricto, me han dado la razón. Aunque muchas otras me he equivocado. Es conocido el resultado del experimento del chimpancé contra los «expertos» en bolsa y cómo quedó demostrado que los «expertos» se equivocan tanto o más que los «inexpertos». Resultado o conclusión que creo firmemente aplicable a todos los ámbitos, disciplinas e industrias. Las Tecnologías de la Información incluidas. Sin embargo, esta era una de esas veces en que el margen para el error no existía. Nada de intuición, entonces.

Por curiosidad, con la mente en hacer alguna cosilla al modo homebrew [@ Wikipedia] había leído varias cosillas sobre Objective-C [@ Wikipedia], pero no tenía la experiencia suficiente con el lenguaje ni con el SDK de desarrollo para iPhone como para moverme con la rapidez suficiente y garantizar plazos y calidad, dos de los pilares fundamentales para el éxito de los proyectos. No digo que no se pudiera. Simplemente no podía hacer una estimación fiable. No me encontraba cómodo estimando con tantas incógnitas. Así que anduve buscando otras opciones. Y encontré una que me encantó: MonoTouch [Web oficial].

MonoTouch es una pequeña joya de ingeniería que te permite programar en un lenguaje orientado a objetos con tipado fuerte, expresiones lambda [@ Wikipedia] «reducidas» y con recolección de basura, tres de las cosas que más me gustan, como es C#, y compilar a código nativo de iPhone. Para lo cual expone las interioridades de las API’s del SDK de iPhone permitiendo que se usen empleando la sintaxis y semántica de C#, pero sin perder de vista cuál es la estructura ni el diseño empleados en el API subyacente. Yo soy (más o menos) experto programando con C#, así que es un lenguaje con el que podría dar más garantías, pese a seguir desconociendo buena parte del diseño del SDK. Habría que confiar en San Google para resolver las dudas que se fueran presentando al respecto.

He subrayado lo de «recolector de basura» porque Objective-C para iPhone te exige que gestiones tú la memoria. Mis recuerdos de experiencias con lenguajes como C y C++ (poca con éste último) me gritaban al oído que la acabaríamos jodiendo a base de bien con memory leaks [@ Wikipedia] y, como decía antes, no existía margen para el error. Y no exagero con esta última afirmación (o negación): No existía. Ni en plazos ni en forma. Y no doy más detalles porque entra dentro de la información privada de la compañía. Tal vez baste reseñar que el proceso de aprobación de aplicaciones y posteriores actualizaciones para publicar una aplicación en la App Store es lento y, aunque se resuelva la incidencia en tiempo récord, se debe esperar varios días hasta que en Apple den nuevamente el visto bueno y se publique la corrección. Al menos es así cómo me lo habían contado y era un factor limitativo a la hora de poner en marcha una aplicación que debía coincidir con otros eventos externos de la compañía contratante. A ver quién es el guapo que les convence de que la «culpa no es tuya» porque Apple no de el visto bueno al arreglo en tiempo límite para que salga publicada la aplicación antes del día que se prefijó. Los plazos eran justos. Demasiado justos. ¿Lo había dicho ya?

¿Alguien recuerda cómo se resolvían los sistemas de ecuaciones con dos incógnitas? «Fijabas» una de ellas, la ponías en función de la otra y sustituías [@ Wikipedia], de forma que convertías el sistema en una ecuación de una única incógnita y resolvías. Siempre que fuese un sistema compatible y determinado, eso sí. Para mí poder fijar el lenguaje a uno que conocía lo suficientemente bien ya era resolver la mitad de la ecuación, por lo que propuse —con vehemencia incluso— realizar una prueba de concepto y medir.

Me costó convencer a los responsables para que me diesen la oportunidad. Siempre que hay desconocimiento hay desconfianza. Aunque nunca termino de entender qué motivos tienen para detestar todo lo que esté relacionado con .NET, pero lo cierto es que cuesta que entiendan que tampoco es tan malo. En cualquier caso conseguí que me dejaran hacer la prueba, que era lo importante. Principalmente porque para la parte de codificación no hacía falta gastarse un euro en licencias.

La prueba fue bastante bien. Diría que todo un éxito. Había lagunas al principio y quedaron lagunas tras la prueba, lógico. Pero estábamos más seguros de que podríamos hacerlo en tiempo y forma. Y eso que para la prueba dedicamos, durante tres días, el equivalente a un desarrollador y medio. Quedé encantado con MonoTouch y lo que me permitía hacer en tan poco tiempo y no teniendo apenas idea de programación para iPhone. Y todo ello incluyendo algunos tests unitarios [@ Wikipedia]. Quería introducir al equipo en las «buenas prácticas». Lástima que de momento el desarrollo ágil [@ Wikipedia] quede completamente fuera de programa.

Para ponerlo aún más complicado decidí que la programación usando las API del SDK de iPhone, la parte de interfaz vamos, la hiciera un compañero. Excelente programador, pero que desconocía .NET. Únicamente programaba en Java. Yo le iba resolviendo las dudas que le iban surgiendo con el lenguaje C#, pero no quería intervenir en el enganche C# (MonoTouch) con el SDK del iPhone. Al menos no mucho. Primero porque tampoco tenía todas las respuestas y, segundo y más importante, porque quería comprobar, medir, si el lenguaje podía ser un contratiempo o facilitar el desarrollo en tiempo límite. ¿Sería tan complejo aprender el lenguaje que ocuparía toda la atención del programador en detrimento de lo «importante», que era el SDK del iPhone? ¿O, por el contrario, y tal como yo defendía, facilitaría el centrarse en las particularidades de CocoaTouch y la suerte de API’s que acompañan el SDK de desarrollo para iPhone?

En este punto abro un inciso. Si eres de los que dicen que un lenguaje es «mejor» o «peor» que otro por el simple hecho de que te guste más o menos, aunque tú creas que tus fundamentos son objetivos, te adelanto que por mi te puedes ir a la mierda. No existe ni un solo lenguaje perfecto. Y menos para todos los ámbitos, contextos o circunstancias. De hecho todos son bastante malos porque no me permiten expresar las cosas como me gustaría (lenguaje natural) y únicamente puedo hacerlo con los artefactos sintácticos/semánticos, sintéticos a fin de cuentas, que me facilitan a tal efecto y los patrones de diseño que les apeteció aplicar a los arquitectos de los frameworks que los acompañan. A partir de ahí sí puedo decir que con unos soy más «productivo» que con otros, según los requerimientos. O que con unos me «divierto» más que con otros. Pero al final todo se reduce a lo que yo soy capaz de hacer —o quiero hacer— con un lenguaje determinado. Soy plenamente consciente de la subjetividad de la elección de un lenguaje de programación concreto, así que me la «pela» todo el que viene a evangelizarme proponiendo que su decisión es mejor. Algo parecido me pasa con los sistemas operativos, pero eso lo dejaremos para otra ocasión. Fin del inciso.

Al compañero, acostumbrado a programar en Java, le costó menos de un suspiro familiarizarse con la sintaxis de C# (que diría es en un 99% parecida a la de Java), y apenas unas horas solventar sus tropiezos con las particularidades de .NET. Cierto que es muy bueno —y creo que tendrá un gran futuro en la industria—, pero quería que alguien ajeno a la discusión sobre Java/.NET/Objective-C diese una opinión más objetiva. Argumento que quería usar para defenderme de los detractores de la «curva de aprendizaje» (sospecho que más suave que la requerida para saltar de Java a Objective-C) y que se apoyaban en el argumento «no tenemos aquí a nadie que sepa .NET». Bueno, me tienen a mí. Mientras que expertos en Objective-C, lo que se dice «expertos», no hay muchos más en la compañía. Tal vez se puedan contar con los dedos de una mano de un tipo que ha perdido tres y medio en un accidente.

De mi primera experiencia con MonoTouch y el desarrollo para iPhone con él, me quedé gratamente impresionado. Quedaba la segunda parte: gastar el dinero que costaban la licencia de desarrollador de Apple (100$) y la licencia de MonoTouch (400$), para comprobar qué rendimiento se obtenía en un terminal real. La primera parte de la prueba de concepto se hizo trabajando con el simulador únicamente.

Quinientos dólares no es dinero para una empresa de la envergadura que tiene en la que trabajo. De hecho es apenas dinero para muchas empresas. Haya crisis o no. Dicen que sin riesgo no hay recompensa. Quinientos dólares es un gasto (en realidad una inversión) ridícula si te permite entrar de lleno en la App Store y en el mundo del desarrollo rápido de aplicaciones para iPhone/iPad/iPod Touch. Ya «veía» un futuro cercano con decenas de aplicaciones (más o menos) tontas dispuestas en la App Store avalando nuestro buen hacer como compañía. Un curriculum inmejorable cuando se presentan presupuestos y ofertas con esta tecnología. Tan convencido estaba de mi propuesta (la intuición, una vez más), que no me importó enfrentarme abiertamente a aquellos en la compañía que sienten, digámoslo suavemente, poco aprecio hacia mis opiniones o propuestas. Mi argumentación era sencilla: si sale bien, ganaremos dinero; si sale mal, únicamente perderemos quinientos dólares. Lo que, sinceramente, no es dinero cuando tienes más de cien empleados.

Y, entonces, llegó Apple y me «dio por culo». Y a muchos más. En su batalla contra Adobe nos regaló la cláusula 3.3.1 [Nueva licencia para los desarrolladores de la App Store, Apple cierra el cerco a Adobe @ Applesfera; Apple prohibe a los desarrolladores de iPhone crear aplicaciones con Flash, entre otros @ Appleismo] y todo se vino abajo. Me tuve que tragar mis argumentos porque Apple había decidido convertirme en un «daño colateral». Y los que opinaban que era más fácil/seguro con Objective-C dieron saltos de alegría. Y tanto saltaron que a uno lo han ascendido. Así es la vida.

Mi experiencia con MonoTouch fue hace unos cuatro/cinco meses. Sigo convencido que es una alternativa genial para desarrollar para iPhone, y ahora para iPad también. Aunque sigo teniendo dudas acerca del rendimiento final sobre un terminal. He seguido los avances en relación a la sección maldita y veo que siguen apareciendo aplicaciones desarrolladas con la plataforma .NET [@ MonoTouch Apps]. Se supone que esto no debería estar sucediendo, pero las aplicaciones pasan el control de exigencia y se publican en la App Store. Además, parece que las autoridades estadounidenses no se han tomado muy a bien la redacción de las exigencias [La sección 3.3.1 de Apple, al borde de una investigación de defensa de la competencia @ Appleismo]. No creo que sea para celebrarlo. Todo lo contrario. Creo que Apple es una de las empresas que más y mejor miman a sus consumidores con productos muy fáciles de usar. Una investigación gubernamental no sería buena, supongo. Pero si lo que realmente persiguen es un verdadero control de calidad de los productos que llegan a la App Store tienen muchas formas de hacerlo más allá de determinar qué herramientas usar para ello. Intentaré exponer mi pensamiento a la forma bruta y tradicional con la que suelo expresarme. Para pergeñar una cagada únicamente hace falta un culo. Todos tenemos uno. Los programadores también. Y da igual si cagas detrás de una tabaiba [@ Wikipedia] a plena luz del día o si lo haces en un inodoro fabricado en oro en una suite de lujo del hotel más caro del mundo. La calidad de la mierda está más relacionada con lo que ingiera el programador la persona, que sobre la superficie sobre la qué la deposita cuando caga. Si Apple quiere saber si un mojón será un buen abono para hacer crecer sus beneficios, que al final es lo que les preocupa, que analice la mierda, no el retrete sobre el que se cagó. Y, por suerte, para analizarla existen herramientas y técnicas. Y, si no, las crean, que para eso tienen un departamento de I+D que da envidia a todo cristo viviente. ¿Vale la metáfora?

Mientras espero a que se aclaren las cosas, he tenido la oportunidad de enfrentarme al desarrollo de una aplicación usando Objective-C (a lo que me ayudó haber peleado primero con MonoTouch). Aunque no de la que se hizo un prototipo en MonoTouch, ya que esa al final se «cayó». Quería aprovechar esta experiencia para señalar, en modo de una serie de articulillos, las diferencias que he apreciado. Además, estoy haciendo algunas pruebas con PhoneGap [Web oficial] que también espero poder reflejar en un futuro no muy lejano. Tengo en mente hacer la misma aplicación usando las tres tecnologías y hacer una serie de artículos narrando los toletazos que me vaya dando con cada una:

1. MonoTouch (cliente) / ASP.NET (servidor)
2. Objective-C (cliente) / Java (servidor)
3. JavaScript (cliente) / ? (servidor)

Pero me temo que, para eso, ya empiezo mañana. O pasado. Esta entrada ya ha sido larga en exceso. Así que no la voy a estirar más.