Sin miedos

Primero, lo más importante: si te interesa el desarrollo con tu Mac, en Cocoa, usando Xcode y Objective C ya eres miembro de esta comunidad. No ha sido tan difícil entrar, ¿no?. Como en cualquier comunidad, sólo hace falta que tengas interés, o curiosidad, o conocimientos, y que quieras compartirlos. No hay que hacer pactos con el Anticristo, ni con los bancos, ni firmar contratos con la sangre de un gallo. Cosa asquerosa, por cierto.

Puedes disfrutar de esta comunidad a distancia, usando tu ordenador e Internet, pero yo siempre recomiendo el contacto cara a cara, personal. El periodo más productivo de mi vida como programador fue cuando estudiaba la carrera de Informática. Y así lo recuerdo por el grupo de personas con las que me reunía a programar y a hablar sobre programación. Probablemente es más la sensación de que «cualquier tiempo pasado fue mejor» que algo objetivo (probablemente, no, seguro, mi código era una abominación), pero hablar con gente que sabe mucho más que tú es algo que estimula mucho, motiva y te fuerza a mejorar para no sentir que haces el ridículo entre ellos.

Aunque eso nunca pasa: nadie, nunca, se va a reír del que no sabe. Lo que hará es ayudarle. Así que destierra ese miedo de tu mente, esa pesadilla que alguna vez has tenido: nadie se va a levantar, en medio del bar señalándote y gritando «mirad al pardillo este, que no sabe nada de nada». Si alguien actuara así es causa objetiva para que te tatúen tonto en la frente, y de no ser parte de esta comunidad.

Blogs

Pongo aquí una lista de los mejores blogs de programación Cocoa en Español que conozco y leo. Debe haber más: apórtalos en los comentarios. Siempre son bienvenidos. Van sin un orden concreto, salvo Objective-C.es, el blog de Rafa, claro ejemplo de superación personal y, como se que al final acabará en Apple, le voy haciendo ya la pelota para que pase mi CV cuando llegue el momento.

• Objective-C.es
• Blog de Miguel Díaz Rubio
• Cocoa Mental

Reuniones periódicas

Aquí tenemos las reuniones que se tienen en distintas ciudades de España, con distintas periodicidades. Si no tienes ninguna cerca siempre puedes animarte y fundar la tuya propia. Sólo necesitas a una segunda persona interesada en lo mismo.

• NSCoder Night Madrid
• NSXperience BCN
• NSCoder Night Sevilla NSCoder Night Valencia
• NSCoder Night Córdoba

Todas estas reuniones tienen su propio Twitter. Busca y ponte en contacto con ellos.

«La» Conferencia

La conferencia de la comunidad Cocoa Española, el sitio al que hay que ir es la NSSPain. Es una conferencia internacional (luego es en Inglés), pero es la que más cerca vas a encontrar con mejor contenido. Yo me he hecho fijo en el primer año.

Twitter

Hay montones de gente interesante a la que seguir. Te recomiendo que sigas por twitter a los blogueros anteriores y que mires a quiénes siguen. Es la forma más rápida.

Preguntas y respuestas

El portal NSCoderCenter es lo que buscas

Pull request

Si quieres que incluya un apartado, o quieres completar todo esto con más información, usa los comentarios más abajo. Gracias.

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.

NSCoders Apple Conference 2001

¿Cómo? ¿Que aún no te has apuntado a la NSCoders Apple Conference 2011? ¡Pues ya estás tardando! Podrás ver allí a lo más granado de las distintas NSCoder Nights de toda España. Yo voy a impartir una de las sesiones. Así que ya sabes: no hay excusa para no invitarme a un café, o a un MacBook Air, lo que te venga mejor.

Por si esto de la NSCoder te deja frío y no sabes de qué te hablo, te recuerdo que las NSCoder Nights son reuniones de programadores, diseñadores, gente interesada en el desarrollo en plataforma Apple, que se juntan en un bar a charlar, tomar unas copas, e incluso programar. En Sevilla tenemos una muy animada, a la que te invito a venir, si te pasas por la ciudad. Incluso puedes montar la tuya propia.

El caso es que la idea ha cuajado, y han surgido como setas las NSCoders. Y claro, todos queremos más. Realmente nos da envidia la WWDC, pero es que es una pasta ir a San Francisco :-D. Y aquí va a ir gente de auténtico nivel. Yo voy de relleno.

No le des más vueltas y reserva ya. ¡Es gratis!. Vente en barco, en avión o en burro, pero vente con tu Mac.

Keep coding!