Notación Húngara: contrapost

¿A quién no le gusta una buena polémica?

Polémica Tuitera

Esta semana en Twitter Sendoa Portuondo planteó una conversación bastante interesante sobre si era conveniente (o estaba de moda) usar prefijos en las variables de nuestros programas Objective-C. Mi respuesta fue que, a veces los usaba. Especialmente uso los prefijos para los IBOutlets, de forma que puedo completar el código rápidamente (o encontrar un Outlet sin tener que hacer un viaje al@interface correspondiente.

Fernando Rodríguez (Cocoa Mental, Big Nerd Ranch, super Bad-Ass Master of the Universe) argumentaba totalmente en contra y ha escrito un artículo en Cocoa Mental al respecto. Normalmente estoy de acuerdo con las cosas que publica Fernando, más que nada porque voy al blog a leer para aprender y puedo aportar poco. Pero en este tema concreto (el uso o no de prefijos para identificar qué es una variable), no estoy de acuerdo.

Sus argumentos, que he visto esgrimidos en muchos sitios, se basan en la horrenda interpretación que se hizo de la Notación Húngara propuesta por Charles Simonyi. Nadie lo explica mejor que Joel Spolsky en el artículo Doing it wrong, pero por si no tenéis ganas de leerlo (mal!, dejad en este momento todo esto y leed el blog de Joel de cabo a rabo), voy a intentar explicarlo.

Notación Húngara

Si lees el paper original de Simonyi, encontrarás que la idea que presenta es: «pongamos el qué es de una variable en el prefijo, de forma que sepamos de qué estamos hablando al usarlo luego». Probablemente por no ser el Inglés su lengua materna Simonyi usó la palabra type. Pero no se refiere al tipo que el compilador asigna a una variable, sino a su forma, características, esencia, chi o como lo llames. Su Kind. En un párrafo hablando de cómo prefijar cantidades (índices, filas, etc.) podemos leer:

Quantities are named by their type possibly followed by a qualifier. A convenient (and legal) punctuation is recommended to separate the type and qualifier part of a name. (In C, we use a capital initial for the qualifier as in rowFirst: row is the type; First is the qualifier.)

Si os fijáis atentamente, para dar nombre aquí a una variable que representa una fila, la llama *row_First, y no longFirst o intFirst. Es decir, usa _qué_ es esa variable y no el _tipo_ de nuestro lenguaje elegido para representar a ese elemento. Los grandes detractores de la notación húngara han visto código escritos por otros que no la han entendido y que les obligaban a hacer tonterías como:

int *ptrFirstNumber;        // ¡ya sabemos que el tipo es un puntero a int!
char *strName;              // con leer la declaración, basta...
NSString stringAddress;     // esto es de nota

Apple Will Never Do That

Por cierto y como nota inocente. Dado que esto lo extendió Microsoft y dado que Apple nunca se equivoca, Cocoa es elegante, etc. etc. en Cocoa no encontraremos nunca esta horrible notación, ¿no?. Bueno, no esta, sino notación húngara a la inversa (HungarianNotation^-1): usando sufijos en los tipos. Por ejemplo estas cositas:

AboutViewController *vc;    // ¡ejem! Ya sabemos que vc es de tipo "Pantalla About". 

¿Pero realmente es necesario poner «ViewController» al final de un tipo que extiende de UIViewController? Ya puesto así, que se llame AboutViewControllerUIResponderNSObject, y vemos todas las clases de las que hereda, ¿no?. ¡Error!.

Aquí Apple está marcando en el nombre de la clase qué es, y no su tipo. Para Apple, un ViewController es una pantalla en un programa iOS. Fijáos que el sufijo no es UIViewController, que sería el tipo. Además, sólo leyendo AboutViewController no sabes si es un UIViewController, un UITableViewController, … lo que sí entiendes es que es una pantalla.

Hungarian Notation at its best!

Un ejemplo, que me duermo

Quiero cerrar con un pequeño ejemplo. Supongamos que tenemos una clase que nos devuelve Usuarios (de un servicio web o una BD). Es la clase Users. Esta clase dispone de dos métodos:

+ (NSDictionary *)allUsers;
+ (NSDictionary *)allUsersOrderedByName;

Los nombres de los métodos son autoexplicativos. Usamos un diccionario en el que buscaremos usando una clave (en este caso, el nº de usuario).

Si en mi código, más adelante, quiero guardar estos dos diccionarios (uno está ordenado por los valores de sus claves, que ya que estamos es la forma de ordenar un diccionario, el otro no) podría usar Hungarian Notation Dark Side Style, la criticada por Fernando:

NSDictionary *dictionaryAllUsers = [Users allUsers];
NSDictionary *dictionaryAllUsersOrdered = [Users allUsersOrderedByName];

Aquí, el ver que son un NSDictionary no me aporta nada. Es una tontería redundante poner estos prefijos. Mucho mejor usando Hungarian Notation Luke Style:

NSDictionary *listUsers;
NSDictionary *orderedListUsers;

Aquí usamos qué es para nosotros estas variables, qué representan en el flujo del programa. Son listas de usuarios. Que utilizaremos para mostrar en pantalla, buscar o lo que sea. Me da igual su tipo. Pueden ser NSDictionary, NSArray, un tipo propio, un B-Tree… Lo que me interesa es comprender de un vistazo que a) son listas y b) una de ellas viene ordenada.

Conclusión

Así que, sí, estoy de acuerdo con Fernando en que poner el tipo del compilador al identificador de una variable es una chorrada. Pero eso no es Notación Húngara. Es la mala interpretación que se hizo de ella. La Notación Húngara tal y como se definió es valiosa.

Vale, pero al final, ¿tú lo usas?

Pues creo que sí. Pero no de una manera consciente. Este tipo de discusiones, que algunos obsesionados por «hacer que funcione» verán como una pérdida de tiempo son las que nos permiten aprender y entender por qué hacemos las cosas como las hacemos. Es lo que nos hace Informáticos. Que no Ingenieros. Los Ingenieros no entenderían esto :-D. Pero esta polémica la dejo para otro post.

j j j

Resumiendo 2011

Reloj. No marques las horas. Que el 2011 se acaba... Foto de Flickr. Click para ver original

Reloj. No marques las horas. Que el 2011 se acaba... Foto de Flickr. Click para ver original

El otro día, mientras buscaba siguientes acciones y repasaba tareas en mi sistema GTD (en el que uso Things e iCal entre otros) me encontré con una tarea titulada: «Escribir post resumen año». Era del año pasado. GTD, pese a lo que mucha gente piense te hace ser más productivo pero no te permite «hacerlo todo». Te centras en acabar aquello que es realmente importante. Y hay cosas que pueden quedar aparcadas. Estas cosas aparecen en las revisiones, que para eso están. Lo importante: hacer primero las cosas importantes. Las otras, a veces no son ni necesarias.

El caso es que este año sí que quiero cumplir e instaurar una costumbre. Cada año quiero, en Enero, plantearme una serie de retos, de objetivos, de propósitos, de cosas a cumplir. Revisarlas durante el año, para ver si voy cumpliendo, y luego, en Diciembre, echar la vista atrás. Para mortificarme con las cosas no conseguidas (que será lo más normal, dada la tendencia que tenemos a autoflagelarnos), pero para disfrutar igualmente con aquello que nos planteamos hacer y hemos hecho. Nos merecemos una auto-palmadita en la espalda cada vez que hacemos algo bien. Y muchas veces, cuando conseguimos algo que nos ha costado sangre, sudor y lágrimas no dedicamos ni cinco minutos a sentarnos, reflexionar y disfrutar de ese pequeño triunfo. Así que escribiré posts resumen de cada año a partir de ahora.

Nota: además, me empujó a ello que Xelecto había escrito el suyo.

Este año realicé la revisión del 2010 en Febrero del 2011, un poco tarde. Pero los propósitos de año nuevo los llevo apuntando en una libreta desde Navidades de 2009. Así que este año es la tercera vez que los preparo. Y, al menos a mí, me funcionan. Me ayudan a saber por qué me levanto cada mañana, qué quiero conseguir, qué es realmente importante. No apunto cosas como «ser feliz». Si considero que para ser feliz tengo que visitar, al menos una vez en la vida la India, entonces el objetivo será hacer un viaje. Que se descompondrá en tareas, claro: conseguir pasta, actualizar el pasaporte, buscar vuelos… Pero todo empieza con plantearte qué quieres. Que no es fácil. Si te preguntan «¿qué necesitas para sentirte mejor?» veréis que no es sencillo responder a esta pregunta.

Resumen del 2010 2011

2011 ha sido un año «montaña rusa». Comencé el año publicando dos mini aplicaciones en la App Store (que, por cierto, tengo abandonadas; ahora les toca). Y con muchas dudas. Dudas sobre si debía volver a trabajar por cuenta ajena, sobre si me había equivocado, sobre si daba la talla, sobre si podría aprender. Cocoa no me entraba en la cabeza. Problemas de salud de mi padre. Estaba amargado. Enero y Febrero. Malos tiempos.

Como estaba pensando demasiado y programando poco, me lancé a una «orgía» de impartir formación: cursos de Java de todos los colores: básicos, avanzados, de Java EE, de preparación para las certificaciones, de frameworks (Struts2, JSF). Hasta impartí un curso de programación en C (que, por cierto, disfruté como un enano). Me metí una sobredosis de trabajo, para sacudirme las tonterías de encima. Y funcionó. Incluso pude desarrollar una App para iPad (la primera). Y volví a escribir para una revista, con pequeñas colaboraciones en forma de columna (iPhone World). Lógicamente, se cumplió la Ley DFreniche del agobio en el trabajo: «las mejores ideas para programas se te ocurren justo cuando no tienes tiempo para programar» (Citation needed).

Llegó el verano. Me fui de vacaciones. Y me picó el bicho del freelancing de nuevo. No quería trabajar para nadie. Esto iba a funcionar. Era capaz de todo. ¡Voy a ponerme la capa y los leotardos, puedo volar!. Me ayudaron varias cosas a volver a tener ganas. Primero, facturar, que siempre se nota. Sentirme útil. Ser capaz de hacer la App de iPad. Y ser contactado por varias empresas que querían contratarme, en base a mi perfil en LinkedIn. Muchas de ellas, muy interesantes. Que alguien considere contratarte, tal y como están las cosas, es señal de que algo estás haciendo bien. O eso, o mientes maravillosamente 🙂

Encima en Agosto pude comenzar a programar para WebOS y aprender JavaScript. He disfrutado / sufrido con el desarrollo, pero he aprendido mucho. Y en Septiembre acudí al iOSDevUK, una experiencia fantástica. Lo mejor: conocer un trocito de Gales y estar con Fernando y Bernardo. Y luego vino la conferencia NSCoder ES en Vilanova i la Geltrú. Y empecé a grabar Café y Cocoa. Y ahora José Antonio Blanco me deja hablar con él y otros cracks como él de vez en cuando en We.Developers. Y me entrevistó Luis-Philippe. Y estoy preparando varias Apps para iOS. Y he escrito dos artículos para MacWorld. Y…

Muchos proyectos, muchas cosas terminadas en lo profesional. Y en lo personal. Me planteé este año acostumbrarme a hacer deporte, y se ha convertido en un hábito. Si paso 3 días sin correr / caminar me siento mal. Ya lo que me cuesta es no hacer nada. Me planteé perder peso, y eso lo he conseguido a medias (he recuperado parte del peso, los mantecados). Pero no me preocupa, mientras siga haciendo deporte. Me fijé como meta correr la nocturna del Guadalquivir y lo hice, aunque acabé bastante mal :-D. Y de propina, me caminé 23 Km. en el Homenaje a la 101 de Ronda, que repetiré en 2012.

Y claro, otras muchas cosas no las he conseguido. Hay defectos personales en los que tengo que trabajar. Y un proyecto se convirtió en una pesadilla horrible, de lo peor del año. Este año me gustaría leer libros no de informática, para variar. E insistir en hacer lo que sea preciso para conseguir cumplir mis sueños. Tengo suerte de tener la mujer y la familia que tengo, de ganarme la vida con una profesión que me apasiona, de tener amigos de verdad y conocer a un montón de gente interesante. Es hora de devolver, en forma de trabajo bien hecho, de esfuerzo y de responsabilidad. Y de alegría.

Feliz 2012. Puedes hacer que este año sea como tú quieras. No te resignes. Yo no lo voy a hacer.

j j j

ClockRing y la Hermenéutica de las Apple Review Guidelines

ClockRing rechazada :-)

ClockRing rechazada 🙂

ClockRing ha sido rechazada. No se por qué, pero me lo olía. Bueno, realmente no ha sido rechazada. Me explico. La App es correcta, pero no la pueden subir al App Store porque los materiales de márketing (los textos, imágenes, iconos, etc. que aparecen luego en iTunes) no pasan el filtro. Me esperaba algún problema con la licencia, que es GPL, pero como eso no aparece de entrada, no hay bronca (el problema lo tienen aplicaciones que, nada más abrirlas, te informan de su licencia y otras historias).

El correo que he recibido del equipo de revisión me parece perfecto, en serio. Muy educado, te dan las gracias por enviar Apps al App Store y te explican exactamente cual es el problema (en mi caso una de las capturas de pantalla que había enviado) y cómo solucionarlo. Acabo de crear una nueva captura y la he enviado ya para que me la revisen, a ver si ahora todo funciona OK. No entiendo los programadores que se quejan todo el rato del proceso de revisión. Yo hasta ahora he tenido dos problemas, y en ambos casos me han indicado qué pasaba y cómo arreglarlo. Y todo como la seda, oiga.

Lo que me hace gracia es la razón exacta del rechazo:

3.2   Apps with placeholder text will be rejected

Bueno, mi captura de pantalla inicial lo que mostraba era un anuncio vacío (un iAd sin nada, ya que estaba probando la App). Y yo tenía que interpretar que un texto de relleno (placeholder text) es lo mismo que un iAd sin anuncios. Es por eso que habría que crear una hermenéutica de las reglas de Apple, de forma que mentes ilustradas nos expliquen a los más torpes exactamente qué puedes y qué no puedes hacer 🙂

En resumen, que si mandas esto, te rechazan:

Captura de ClockRing App que NO cumple las reglas :-)

Captura de ClockRing App que NO cumple las reglas 🙂

Pero si mandas esto otro, todo es perfecto:

Esta es la buena

Esta es la buena

Nunca me había alegrado tanto de tener mi licencia de Pixelmator. Problema solucionado en 5 min. Bueno, eso si te acuerdas de cambiar las imágenes promocionales en todas las App Stores. Si no, te mandan otro amable correo rebosante de paciencia pidiéndote que cambies los screenshots de la App española 🙂

Por cierto, ClockRing ya está disponible en el App Store. Y su código fuente está aquí.

j j j

ClockRing, Mi tercera App es Software Libre

Pues eso, que he mandado a revisión por parte de Apple mi tercera App. Actualmente ya tengo dos subidas: MyEvents, para gestionar tus eventos importantes y saber cuántos días quedan hasta ellos, y FXPlayer, una App escrita a cuatro manos con la ayuda de @jnhidalgo @jnhernandez, y que te permite superponer efectos de sonido a una canción que tengas sonando en el iPod. Puedes verlas en la web de Femtocoders (Inglés) o en la sección iOS Apps del blog.

Esta tercera se llama ClockRing, y la idea es muy sencilla: hace que suene un pitido de señal horaria en tu iPhone, como los relojes Casio de toda la vida. Con la particularidad que te permite escoger qué quieres que suene: una campana de iglesia, un reloj de cuco, un pitido típico de la radio…

ClockRing App

ClockRing App

Se me ocurrió la idea tras enterarme a través de José Mª Ortiz, un compañero de Jonathan Chacón (primer desarrollador ciego en el mundo que ha publicado una App en el App Store, bromitas pocas), de que MyEvents era accesible. Empecé entonces a pensar en los temas de accesibilidad y se me planteé “¿bueno, y un ciego cómo sabe de un vistazo que son las dos de la tarde y tiene que irse a comer?”. Evidentemente no “de un vistazo”, tienen que estar activando el iPhone, y VoiceOver te canta la hora. Pero se me ocurrió la idea de clockRing y pensé que podría ser útil. Además, José Mª, me pidió que implementase «para ayer» la posibilidad de programar alarmas en MyEvents (cosa que empiezo a preparar ya para la v1.2). Así que ClockRing era la oportunidad perfecta para practicar con la API de LocalNotifications.

La App es gratis, e incluye iAds para ver si me puedo pagar alguna cerveza a su costa. Pero hace tiempo que estoy con ganas de liberar algo de código. Así que ClockRing es Software Libre, según establece la licencia GPL v2. Vamos, que puedes ver el código, compilarlo, usarlo en tus proyectos, o para aprender, o para reírte, o para lo que quieras. Pero los trabajos derivados deben ser también libres. Si quieres una copia del código, pásate por la Wiki de la App ClockRing que tengo en FogBugz (otro día  hablaré de FogBugz y su increíble sistema de Bug Tracking, predicción del tiempo de entregas, Wikis, repositorios de código, etc.)

ClockRing aún no está disponible para su descarga desde el App Store, ya que está en el proceso de aprobación (cruzad los dedos). En el momento en que esté disponible lo anunciaré aquí (actualizando esta entrada) y en Twitter.

Actualización: ya puedes bajarte ClockRing gratis.

Happy coding!

j j j

Cómo crear tu propia NSCoder Night

Foto de Felipe Vieria

Foto de Felipe Vieria

Si aún no sabes de qué estoy hablando, en este post ya hablé de qué eran y para qué servían las NSCoder Nights. Resumiendo mucho, son reuniones de gente interesada en desarrollar aplicaciones Cocoa. Así que los asistentes pueden ser programadores para el Mac, para el iPhone (y cualquier otro dispositivo iOS), diseñadores, empresarios buscando algún programador que les ayude, curiosos… Si te interesa, puedes también leer el post de Javier Rodríguez sobre cómo comenzar el desarrollo con iOS. MacWorld también se hace eco de las NSCoder Nights.

Hoy tenemos nuestra segunda reunión en Sevilla, y ya hay otros capítulos en Madrid, Barcelona, Gijón, Valencia, Almería, Málaga, … Bueno, pero ¿qué hacer si te gusta la idea, pero en tu ciudad no hay aún una NSCoder Night? Esa fue básicamente la duda que surgió en los comentarios que comenzó David en el post sobre cómo estaba aprendiendo a programar para iOS. Tras algunos correos, quedó inaugurado NSCoder_zgz, y pronto tendrán su primera reunión. Así que se me ocurrió listar la serie de pasos que debes ejecutar para localizar tu NSCoder Night más cercana, o bien crear la tuya propia.

  1. [Twitter getTwitterHandle]; Si no tienes usuario en Twitter, lo primero es creártelo. Te servirá para estar al día de las NSCoder Nights. No todas tienen sitio web, pero todas tienen Twitter.
  2. [NSCoderNight listAll] consulta la lista de NSCoder Nights que tenemos en el capítulo de Sevilla. Procuramos mantenerlas actualizadas. Si dudas de si hay alguna cercana, pregunta, que para eso estamos.
  3. if ([NSCoderNight isNear]) exit(0); Si encuentras alguna cerca / en tu ciudad, has terminado. Sigue a su usuario en Twitter y listo.
  4. else … Bueno, si no hay ninguna cerca, la solución es fácil: la creas tú. ¿Cómo? sigue leyendo
    1. Crea un usuario en Twitter para esa NSCoder Night. El nombre debe ser: NSCoder_xxx, donde xxx será una abreviatura del nombre de tu ciudad, como sev, zgz, mlg, bcn, etc. (etc no lo uses)
    2. Copia la bio de otro NSCoder Night. Así somos más homogéneos.
    3. Copia el icono de otra NSCoder Night
    4. [Opcional] Crea un sitio web para tu NSCoder Night. En tumblr, también por ser homogéneos.
    5. Añade a tu nuevo sitio web las FAQ que magistralmente escribió Vicente Vicens.
    6. Pon un enlace en el perfil de la cuenta de Twitter al nuevo sitio web.
  5. Una vez que has terminado con la parte técnica, ahora viene lo mejor. Busca un sitio que te guste, un bar, cafetería, restaurante, tu casa, una iglesia o un gimnasio. Un sitio donde quepáis de cinco a diez personas, con sus portátiles. ¿Lo tienes?
  6. Publica la primera reunión. Ponle fecha, y hora. La mayoría empezamos sobre las 19:00, pero puede ser a cualquier hora. Aunque el apellido de las reuniones «Nights» igual te da una pista sobre el horario.
  7. Apóyate en la promoción de las otras NSCoder Nights. Siempre te haremos un RT 🙂
  8. Ve a la primera reunión. Si va alguien, fantástico. Si no, persevera. Tendrás ese tiempo para tí, para programar / leer fuera de tus tareas habituales. Sigue el ejemplo de José Vázquez en su inigualable «Hazte Indie«.
  9. Sube fotos y cuéntanos cómo te va 🙂
j j j

Usando XCode 3.2.5 con dispositivos iOS 4.2.1

Hace unos días salió la 4.2.1 de iOS para iPhone y iPod Touch. Sin pensarlo demasiado, actualicé mi iPhone 3Gs, que es la máquina que uso en el día a día, pero también la uso como máquina de desarrollo y pruebas. Pero no caí en el posible problema: tener en mi dispositivo instalado una versión de iOS no soportada por XCode.

Pero salió la 3.2.5 de XCode y me la bajé e instalé. Bueno, problema solucionado ¿no?. Veamos, esta versión soporta… ¿iOS 4.2? ¿Y qué pasa con iOS 4.2.1? Un sudor frío me recorrió la espalda. Y se confirmaron mis miedos con este tweet de @jdortiz:

Lógicamente, estoy en fase de pruebas para lanzar la v1.1 de MyEvents. Esto sólo te pasa cuando estás probando. Murphy es cruel.

Esta mañana, me remangué y me senté frente a XCode. Al abrir el proyecto, un solitario error:

Mi XCode no entiende qué es eso de iOS 4.2.1 🙁

Abrí el Organizer (para ver mis dispositivos), y nada más abrirlo me apareció la siguiente ventana:

Vamos, que XCode me estaba diciendo: «esto de iOS 4.2.1 no tengo ni idea de qué es, pero si quieres me leo unos cuantos ficheros del iOS de este iPhone y trato de ver si soy capaz de manejarlo». Evidentemente, pulsé en Collect. Una barra de progreso me indicaba que se importaban los ficheros de iOS de mi iPhone. En segundo plano, XCode «desimbolicaba», es decir, desensamblaba el código de iOS 4.2.1 y lo preparaba para poder depurar con él. Al finalizar, supe que había triunfado porque el Organizer me mostraba la versión correcta en mi dispositivo:

Ahora ya sólo me quedaba actualizar la información del proyecto (para que se compilase usando el SDK correcto) y del target (el ejecutable que genera XCode) para se enlazase con las bibliotecas de la versión correcta. Pulsamos sobre el proyecto, ? + I (obtener información) y en la pestaña Build, cambiamos Base SDK. En mi caso ponía 4.1 (missing) y le he puesto la última. Luego repetimos, pero en el Target, ? + I, build y ponemos el Base SDK a 4.2.

¡Listo! Graba (? + S) y cambia entre dispositivo y simulador un par de veces. Parece que XCode no refresca bien el cambio. Ahora, ya puedes probar con la 4.2.1 en el Simulador y en tus dispositivos.

P.D.: Jorge me avisó en este Tweet de que alguien ya había escrito algo sobre este problema, pero 1) está en Inglés y 2) no está tan mascadito. ¡Espero que os sirva!

j j j

Cómo estoy aprendiendo a programar en Cocoa Touch para iOS

En el post en el que anunciaba que mi primera App para iOS, MyEvents, ya estaba disponible en el App Store, David me pedía en un comentario que escribiera algo de cómo me he ido preparando para programar en Cocoa. Este post ya me estaba rondando por mi Things desde hacía tiempo, y un par de correos pidiendo lo mismo, unido a que en las NSCoder Nights mucha gente va a preguntarlo (y es una lata repetir siempre lo mismo ;-)) me han llevado a escribir mi experiencia.

No esperes aquí un camino formativo «de academia», con unos objetivos, etc. Es mi experiencia. Y por ello mismo, está en contínuo cambio. Os agradecería que, si habéis leído otros libros, consultáis otras webs, tenéis otros ejemplos, etc. los pongáis en los comentarios de forma que todos los programadores que lean el post se beneficien de las experiencias de todos.

Antes de empezar, disclaimer al canto. Probablemente son los años, o el haber estado alejado de los teclados unos años, o el tener mis neuronas seriamente perjudicadas por el abuso de alcohol en mi juventud y cafeína en la actualidad, pero a mí Cocoa / ObjectiveC / XCode no me han resultado «un juego de niños». He tenido que esforzarme, leer mucho, probar cosas, equivocarme, frustrarme, volver a empezar, ver vídeos, etc. Lo digo, porque he leído en muchos sitios por Internet que la gente se pone a toda máquina con Cocoa Touch en dos/tres meses. Pues yo tengo que ser tonto de remate. Si tú tampoco eres capaz de saberte toda la API (incluyendo la parte privada) de iOS en dos meses, que sepas que tienes mi solidaridad.

El comienzo

Cuando me planteé meterme en Cocoa Touch, yo partía con tres grandes ventajas. Por un lado, en mi juventud programé mucho en C y C++, y C siempre ha sido mi lenguaje favorito. Sobre todo, porque fue el primero con el que hice cosas. Por otra parte, tras el intensivo machaque con las certificaciones Java e impartir un montón de cursos tenía bastante claro el patrón MVC. Ambas cosas son básicas: C + MVC, así que, si no tienes claro C te recomiendo lo primero que te mires el libro clásico de Kerninghan y Ritchie «The C Programming Language» para tener claro qué es un #define, un puntero, los tipos de datos que hay, estructuras de control (if, switch), el operador ternario ?, etc. MVC lo explican fantásticamente bien en los vídeos de iTunes U de la Universidad de Stanford, «Developing Apps for iOS», capítulos 1 y 2. El cap. 2 es un ejemplo de cómo aplicar MVC.

La última ventaja, algo que me sigue sorprendiendo que sorprenda, es que hablo Inglés. Dominar el Inglés te da acceso a un montón de información escrita, vídeos, podcasts, y la posibilidad de charlar con gente si vas a la WWDC (de momento, un sueño para mi, pero ya veremos en 2011). Hay muchas formas de aprender Inglés, y distintos métodos. Escoge el que quieras, pero ponte ya. Sin excusas. Lee comics, ve las películas subtituladas en Inglés y con la pista de audio en Inglés, mira videos en Youtube, lo que sea. Pero practica. Ya. Deja de leer estas líneas, en serio: el impacto en tu vida de aprender Inglés será más importante que cualquier cosa que yo pueda contar.

Los primeros libros

Para arrancar, lo tenía muy claro: iba a leerme de cabo a rabo un par de libros, uno para principiantes y de estilo tutorial, y otro avanzado que se metiera a más bajo nivel con Cocoa Touch. Los comenté en este post. Pero como soy así de bueno, listo los cuatro que he leído para que los tengáis a mano:

Beginning iPhone 3 Development, de Dave Mark y Jeff LaMarche. El primero por el que empecé. Te explica todo paso a paso, y trata un montón de temas. En un punto tuve que parar, porque no tenía clara la base de ObjectiveC, y cosas como el KVC, las categorías o la gestión de memoria se me escapaban. Así que lo aparqué y me leí:

Learn Objective C on the Mac, de Mark Dalrymple y Scott Knaster. Este libro me gusta mucho porque es muy directo, si sabes de lo que te está hablando. No es tan tutorial como el otro, va al grano y te da una base imprescindible para programar. Debería haber empezado con este 🙂

Tras estos dos, he leído algunos capítulos de More iPhone 3 Development, también de Dave Mark y Jeff LaMarche. No lo he leído completo, sino los capítulos que iba necesitando, de forma ad-hoc.

El último con el que estoy es iPhone SDK Programming, de Maher Ali. Más avanzado, prescinde de Interface Builder y lo construye todo a mano. Ideal, para saber qué pasa «detrás del telón» de IB. Y su introducción a Objective-C es muy buena, compacta, pero un poco densa.

Vídeo y audio

Mientras estaba leyendo esos libros he ido alternando con los vídeos de la Universidad de Stanford (que están disponibles en iTunes) sobre cómo programar para el iPhone. Son gratuítos y la única pega que se les puede buscar es que están en Inglés. El enlace para la versión en HD es este. También hay una versión en SD. Me parece casi perfecto ir leyendo y viendo un vídeo de vez de cuando, de forma que una cosa se apoya en la otra. Yo no tengo iPad donde verlo, pero se me ocurre que la forma perfecta es por la noche, en el sofá, con los auriculares puestos mientras tu media naranja ve otra cosa. El problema es que es mi media naranja la que lee en el iPad. Es suyo 🙂

En audio sólo he escuchado un podcast de Cocoa: 85% cocoa. Súper recomendable, tanto por el contenido como por la estructura. Y no sólo se tratan temas de programación estrictamente: se hablan de otros detalles necesarios para el desarrollo. Un gran trabajo de José A. Lobato, culpable junto con otros de la comunidad NSCodeCenter y de las iniciativas NSCoder Night en España.

Webs

Además de los recursos de Apple (el Developer Center), uso mucho StackOverflow y ahora me estoy animando a entrar en NSCodeCenter. Con estos tres cubro prácticamente cualquier pregunta, además de blogs de programadores en Cocoa y otras cosas que me encuentro por Internet y guardo en Delicious.

Programar

Al final, a programar sólo se aprende programando. Por mucho que leas, por mucho que creas que sepas, la única forma de aprender a programar es haciendo programas. Puede parecer una perogrullada, pero no lo es. Así que ya sabes: programa. Aunque tu código sea feo, aunque no te apetezca enseñarlo (eso siempre pasa, somos muy pudorosos con nuestro código), sigue adelante. Ya aprenderás formas de hacerlo más bonito. Yo hasta que no me planteé algo propio no empecé a encontrarme con cosas que quería hacer y no sabía cómo.

Un compañero

Yo me he buscado recientemente un compi para hacer Apps a cuatro manos. De esta forma, puedo ver cómo programan otras personas, tengo que esforzarme en «hacerlo bonito», ya que van a leer mi código, y avanzo mucho más rápido. Y me motiva mucho. Otra opción son las NSCoder Nights. Y si no lo hay en tu ciudad, monta tu la tuya. No necesitas más que una cuenta en Twitter y un bar. De ambas cosas hay abundancia en España.

Así que ya sabes: happy coding!

j j j

NSCoder Nights Sevilla

Me ha tocado organizar el capítulo de Sevilla de las NSCoder Nights, y en ello estamos. El próximo Lunes 15, a las 19:00 estaremos en la ETSII Facultad de Matemáticas de Reina Mercedes. El aula aún está por confirmar, pero si después de leer esto te interesa venir, toda la información se va a ir publicando de dos formas:

– Bueno, ¡ya está bien con los anuncios!. ¿Pero qué es esto de los NSCoder Nights? ¿Algo porno? ¿Y porqué el nombre en Inglés, pedantes, que sois unos pedantes?

Las dudas se resuelven en las FAQ, que puedes consultar aquí. Por responder rápido a tus tres preguntas:

  • es una reunión periódica de programadores para tomar café / cerveza / whatever y hablar de nuestras cosas
  • no, no es nada porno, ni ilegal. Pero si alguien se trae un disco duro lleno de pelis, seguro que le encontramos utilidad
  • somos unos pedantes, pero es que estas reuniones las inventaron en EE.UU. y queremos montar algo similar en España (ya ha empezado en Valencia, pronto en Málaga, Barcelona, Gijón y Madrid) de forma que si viajas a una ciudad con NSCoder Night y te apetece, te pases. Sí, es una secta.

Pero ahora, de mi cosecha, te explico de qué va esto.

La informática es una profesión vocacional. Cierto, hay gente que no ha estudiado esto y programa (o lo intenta), o que trabaja en el sector sin ser Informático. Pero es algo vocacional. De otra manera nadie aguantaría unos estudios en los que no hay nadie del otro sexo, sólo tíos raros y feos y frikis (¡horror, que yo soy otro de esos!). Y encima, cada 10 años ¡vuelta a empezar!. ¿O alguien usa el S.O. de hace 10 años? ¿Windows 98, alguien se acuerda? Con XP (que salió en 2001) parecía que se iba a romper esta tendencia de cambiarlo todo cada 10 años, al personal empieza a gustarle lo vintage. ¡Cambiad ya a Windows 7 por lo menos y tened un S.O. moderno!

En fin, que me pierdo. Una vocación, decía. Un ritmo de aprendizaje muy alto. Y algo en lo que no trabajas, es algo que vives. Porque luego llegas a casa y te pones con los chismes. A hacer lo que sea, pero con tus ordenadores de casa. ¡Después de haber estado 10 h en el trabajo delante de una pantalla!. No tenemos arreglo. Yo digo que  hay dos tipos de informáticos: los que van 8 horas al días a su trabajo y luego quieren tener «su vida social» y los que no podemos evitarlo y seguimos en casa 🙂

Pues bien, si tienes pasión por esto, si de verdad te gusta ¿has notado lo que te frustra no poderle contar tus frikadas a nadie? Vale, que le cuento a mi mujer que la arquitectura MVC y la delegación en Cocoa son la leche, y que el KVC es brutal. Pero como que me mira como si le hablase en Chino, y me sonríe por apoyarme, pero no porque le interese. Esa es la razón de que tantos informáticos tengamos blogs: tenemos una necesidad reprimida de enseñar nuestros juguetes y nadie nos entiende. Echamos de menos esas charlas de café, en la facultad, cuando alguna eminencia de compañero te enseñaba cómo programar en Pascal orientado a objetos (era el 92-93, ¿verdad Antonio?), u otro friki extremo te hablaba de su Commodore 64 y te enseñaba a taladrar placas y a quemar circuitos para hacernos conversores analógico-digitales caseros con los que escuchar MODs a través de un radio-cassette (era el 93-94, una Sound Blaster costaba 30.000 pelas de la época, ¿verdad Migue?)

Bueno, voy a dejar las loving memories que me pongo tontorrón y se me salta una lágrima. El caso es que los informáticos precisamos de una terapia de grupo, donde poder curarnos de todo eso que queremos contar y no podemos. Queremos ver que alguien se «pone bruto» cuando le enseñamos nuestro código, o sentir envidia sana cuando llega otro que sabe 10 lenguajes más que tú. Y ver los portátiles, qué herramientas llevas instaladas, qué trucos sabes, etc.

Pues nada, que si sabes mucho Cocoa o no sabes nada. Si quieres empezar a programar tus apps para iOS o si eres diseñador gráfico y quieres ver qué se necesita para hacer tus trabajos para el iPhone. O si buscas contratar a un programador iOS. O si te apetece hablar de programación en general, te esperamos el Lunes. Tengo confirmada al menos a otra persona, así que ya tengo charla garantizada. ¡Nos vemos!

j j j