Como el año pasado, me quedé en casa de Rafa. Y he pasado la semana con Luis Ascorbe, Pedro Muñoz y el resto de cracks del capítulo Cocoa de Barcelona (lo siento, sois muchos ) y de otras partes de España que estaban allí para el MWC.

Del MWC en sí he visto poco. Cada vez me interesa menos: mucho móvil, mucha tableta, ves cosas muy chulas pero tienen poco impacto en mi día a día. En cambio, en la WIPJam he podido aprender sobre desarrollo con Google Glass, trucos de Android e iOS, … Creo que prefiero las conferencias de desarrollo, y cuanto más hardcore mejor.

Es esto, la WIPJam debe mejorar. Creo que a todos nos gustó que fueran más días, pero hacía falta más contenido, y si hay que vender los productos de los espónsors, siempre se puede hacer de forma que de rebote aprendas cosas. Es decir, eché en falta más talleres de remangarse y hacer cosas. He enviado mis sugerencias al personal de la WIPJam (que, por cierto, son tan buena gente que parecen de Cádiz) y espero que a) me dejen aplicar algún cambio el año que viene y b) me dejen entrar el año que viene, pese a las críticas

El caso es que estuve de Lunes a Miércoles en la WIPJam (en Plaza de España, no en la Nou Fira, que es donde está el MWC de verdad) y el Jueves me eché un paseo por el MWC. Que duelen los pies un montón: es muy grande y las moquetas del suelo muy duras, o algo pasa. Y vi cosas chulas, como el Galaxy Note 3 de Samsung, o los Nokia X, o los teléfonos Firefox OS. Pero poco más.

Lo mejor: las cervezas, las charlas con @Pepito, las cenas, el humor de Carles, las Google Glass, los iBeacons…

Material del taller de Core Data de la WIPJam

En la charla de Core Data

Lo más importante para mi fue el poder impartir la charla sobre Core Data del Lunes y luego poder programar con un grupito una pequeña App usando mogenerator y Magical Record. Como prometí poner todo el material online, aquí está:

• la presentación sobre Core Data, en SlideShare
• un ejemplo de código, usando mi Core Data Stack
• un segundo ejemplo, con mogenerator y Magical Record

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.

Por cierto, si programas con Cocoa y no conocías este blog, ya puedes ir leyendo: te va a encantar.

Más vale tarde que nunca, ¿no?

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.

Chris Price en la Radio de Gales

Mi balance de la conferencia, como el de otros años, es: awesome.

Pero este año se han añadido varios factores que me han hecho disfrutar de la estancia como nunca.

• Debido a los cambios que estoy realizando en múltiples aspectos de mi vida, este año he venido muy relajado y con una clara mentalidad: aprovechar el momento al máximo. Suena a cliché barato, pero la realidad es que muchas veces sale uno de viaje y en lugar de disfrutar las cosas buenas del viaje te dedicas a quejarte por las inevitables incomodidades y, por un lado a recordar lo bien que estabas en casa y por otro a estresarte por todo el trabajo que te espera a la vuelta. La verdad, para tener este estrés, casi mejor no viajar ¿no?. Pues este año no ha sido así: he podido hacer muchas cosas, y en cada momento he estado completamente presente y disfrutando de lo que hacía, ya fuera conversando con otros compañeros, comiendo, paseando, bebiendo cerveza o corriendo.
• he venido con un viaje mucho mejor organizado. Para mi, la mejor ruta es avión Málaga – Birmingham y desde el aeropuerto tren directo a Aberystwyth. Nada de conducir desde Londres como el primer año con Fernando Rodríguez o de pasarme la noche vagando por Nottigham como el segundo año tras llegar al East Midlands Airport. Si el viaje es más descansado, lo tienes claro y la ruta es conocida todo va bastante mejor. Además, me he dado montones de tiempo entre las conexiones tren – avión. Tiempo en teoría muerto (aunque el tiempo es el que es, todo depende de lo que tú haces con el; es decir, que lo matamos nosotros, no viene muerto de serie). Esta vez me he dedicado a leer y escribir. Well done.

Compañeros de carreras

Más corredores

• ha sido la primera vez que he podido / querido hacer deporte. Además, he podido contar con compañeros que me han ayudado en los momentos difíciles, cuando ves que tu barriga te impide subir la colina. Gracias a Sebastián, Pedro y Raimón he podido correr por bosques de cuento viendo a los conejos correr a esconderse, y trepar a acantilados a ver el pueblo desde arriba. O perdernos por caminos en los que los helechos me llegaban a los hombros (lo que es fácil con mi altura por otra parte, pero aún así…)
• he disfrutado las noches en el pub mucho más que nunca. Tanto en el Varsity como en el Pier Royal, han caído muchas pintas de Carling y varias de sidra Strongbow. Y muchas conversaciones muy interesantes sobre trabajo, programación, tecnología, chistes, la forma de vida de cada uno… La culpa de esto ha sido el rat pack que hemos formado, con gente como Fernando Rodríguez, Antonio, Pedro, Javier, Sebastián, Raimón, René, Petteri, …

Comer fruta en una conferencia: achievent unlocked

• he dormido algo menos, pero no lo he echado tanto de menos. Y quitando el último día, en el que he prescindido de dietas, he comido bastante bien y de forma muy razonable.
• las charlas a las que he asistido me han inspirado, ayudado, enseñado, me han hecho pensar y tomar decisiones. El taller de Core Data fue de una calidad y nivel espectacular. iOSDevUK es un evento especialmente enfocado en los desarrolladores indie (entre los que no me encuentro, ya que no vendo mis productos, hago cosas para otros como freelance) y me ha vuelto a entrar el gusanillo de publicar mis Apps y volver a intentar vender mis ideas. Tengo miedo al rechazo, a crear aplicaciones feas y horribles que nadie quiera. La única forma de vencer esto es escribir código, construir cosas y publicarlas. Y ver qué pasa entonces.
• He conocido a gente increíblemente inteligente, brillante, divertida, humilde. En estos sitios siempre eres el retrasado de la clase. Lo cual es muy bueno: tienes ganas casi de llorar cuando ves a Alan Cannistraro preguntando cosas a Marcus Zarra. Pero esta impotencia y sentimiento de soy tonto es lo que nos anima a continuar aprendiendo.
• he visto algo más de esta maravillosa ciudad. Creo que ya casi se pronunciar su nombre correctamente. He ido en el tren de vapor al Valle de Rheidol, he vuelto a pasear por sus calles y he visitado el museo de Gales. Y me he comprado un libro del Canal Historia sobre la Primera Guerra Mundial como autoregalo. No se puede pedir más.

En mi caso tras el iOSDevUK 2013 vuelvo aún más motivado a seguir aprendiendo, pero sobre todo, quiero escribir líneas de código. Tengo ganas de programar.

Y en una semana me voy a Logroño, a disfrutar del Evento iOS internacional que desesperadamente necesitamos en España: NSSPain. ¿Te lo vas a perder?

La NSSpain va a tener lugar en Logroño (La Rioja – España), aunque es una conferencia internacional. Viene gente de diferentes países y los ponentes son nacionales (los menos) y muchos extranjeros. La lista de ponentes es excepcional (dado que yo soy la excepción que confirma la regla) y van maestros como Fernando Rodríguez, de AGBO (el gran Jedi Master Cocoa) o Alfonso Alba (mi maestro Git, que me hizo abrir los ojos y cuyo curso de Git no deberías perderte si en 12 h quieres enterarte al fin de qué va Git). Por el precio que tiene la NSSpain es un regalo, viendo la gente que viene.

Se desarrolla íntegra en Inglés (por aquello de que es internacional).

<English-fear-rant>

Acabo de sentir una conmoción en la parte cateta de la fuerza «¡oh, Dios, mi Inglés no es lo suficientemente bueno para enterarme de las ponencias! Es más, todos se van a dar cuenta y se van reír de mi. Me sacarán al escenario desnudo a leer trabalenguas, y finalmente vendrá Godzilla y me arrancará la cabeza». Vamos a ver, que se va a estar hablando de punteros, bucles, bloques, objetos… que nadie se va a poner a declamar a Shakespeare. Que con un vocabulario mínimo puedes perfectamente seguir una de estas charlas. Hay que perderle definitivamente el miedo al Inglés: es el primer lenguaje que debes aprender si quieres programar.

</English-fear-rant>

Así que este Septiembre nos veremos allí (del 16 al 19). Yo acudo como ponente (tras varios intercambios de correo, logré engañarles y hacerles creer que podía impartir una charla con cierto criterio; ahora lo malo es que hay que impartirla). En mi caso, voy a actuar dos veces: el día previo a la conferencia, con un taller de Core Data fundamentos, para explicar lo necesario (y algo más) para funcionar con Core Data. El primer día de la conferencia, vuelvo hablando de Core Data con algunos trucos avanzados, librerías y utilidades que suelo usar para mis proyectos.

Y claro, como en toda conferencia, además de los ponentes lo mejor suele ser la gente, la comunidad Cocoa. Gente que conozco físicamente o sólo por Twitter, pero que aprecio y respeto, de la que siempre aprendes y con la que quieres estar. No me voy a poner a nombrarlos uno a uno, porque sería una pesadez y de todas formas les voy a ver allí.

Lo que me lleva al último punto: que nunca he estado en Logroño. Así que este viaje me va a permitir ver algo (supongo que no mucho, que yo se cómo son estas cosas luego) pero al menos darme un paseo por la ciudad y tomarme un café en el centro, que es lo que me gusta.

Ya sabes: Logroño está cerca de todos lados (al menos, más cerca que Cupertino para muchos), el precio es de risa comparado con lo que vas a aprender, conocerás a gente alucinante y te lo pasarás pipa con personas que te entienden cuando les hablas excitado de programación. No como tu pareja, que te escucha y asiente, pero que realmente no sabe de qué le hablas.

Nos vemos en la NSSpain.

Aún no se si realmente alguien aprendió algo de mi charla. Yo me lo pasé muy bien, aunque no las tenía todas conmigo. El Viernes anterior había estado toda la mañana programando con JavaScript y el framework Enyo para la HP TouchPad. Y por la tarde había estado viendo detalles intrincados de Java en un curso de preparación para el OCP Java SE 6 que estoy impartiendo. Y Cocoa ya no me cabía en mis maltrechas neuronas. Al final parece que Cocoa fluyó (con ayuda de muchos cafés) y me pude escapar sin demasiados tomatazos. Y aquí es donde empezó realmente lo bueno.

Este año he ido a otra conferencia, el iOSDevUK en Gales, que me encantó. Pero comparando ambas, en la NSConf11 he escrito código. No sólo he escuchado, aprendido y charlado de código. He trabajado el código. Como en el increíble taller de TDD que impartió Pedro Santos, tras su charla sobre Behaviour Driven Development. Aquí tuve el privilegio de picar código mientras hacíamos pair programming aplicando el proceso paso a paso de TDD. O la charla sobre Chipmunk de Óscar Cardona, que nos dejó a todos atontados y pensando «esto no puede ser así de simple, o hay más código o este tío explica muy bien esto». O el taller de Core Plot, donde vimos cómo hacer gráficas complejas con esta librería, gracias a la demo de Víctor Jalencas. Y tantas y tantas ponencias interesantes. La única pena: las que me perdí mientras yo hablaba, y las que tuve que elegir, perdiendo la que se presentaba en paralelo.

Lo mejor, la gente que he conocido. Gente con muchas ganas de aprender, compartir y enseñar. Gente encantadora y que, como los miembros de la NSCoder_bcn que han organizado el evento, se han matado para que todo estuviera perfecto, como al final ha sido. Creo que nadie pensaba que en una primera conferencia íbamos a tener tanto público. Esto puede llegar a ser una WWDC hispana. Trabajaremos por ello. Gracias a José Juan, nuestro presidente, o a Guillem o Leandro, o Xabi, o… por la paliza enorme que se han dado.

He podido conocer en persona (yo no «desvirtualizo» a las personas: las conozco) a José Lobato, ídolo de masas Geeks y gran bebedor de cerveza :-D. El tío en persona es para comérselo, y gran parte de la «culpa» de que todo esto se originara es la semilla plantada desde 85% Cocoa con las NSCoder Nights. Otro que me ha impresionado y he podido escuchar con respeto reverencial es Iván Leider. Él es un Maestro Jedi del desarrollo. Yo, ni Padawan…

Y demostrando que el mundo geek también es un pañuelo, conocí a Daniel García, el programador de la App de Minube para la TouchPad. Creo que allí estábamos los dos únicos programadores Enyo de toda España :-). Bueno, alguno más habrá, pero no creo que más de 10…

Y claro, me he hinchado a comer, he visto algo de Vilanova i La Geltrú (principalmente de noche) y no he parado de hablar. La experiencia no merece la pena: es imprescindible si desarrollas en Cocoa. Yo el año que viene, repito. Espero que alguien recapacite y no me dejen hablar.

Os dejo con un Vídeo de Vilanova Digital en la que «el presi» de la Asociación explica (en Catalán, pero se entiende perfectamente) qué es la NSConf11

Y el que quiera el código del RSS Reader que utilicé de ejemplo, lo tiene en: https://github.com/dfreniche/SimpleRSSReader

]]> /2011/11/04/la-nsconf11-de-vilanova-i-la-geltru/feed/ 1 /2011/10/20/conferencia-nscoders-apple-conference-2011-ya-casi-esta-aqui/ /2011/10/20/conferencia-nscoders-apple-conference-2011-ya-casi-esta-aqui/#comments Thu, 20 Oct 2011 18:04:15 +0000 /?p=1626

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!

Mi App para iPad en funcionamiento

Con esta App he aprendido muchas cosas:

• cómo desarrollar pensando en la resolución del iPad
• cómo hacer pruebas con el iPad de mi mujer cuando ella no lo está usando
• cómo usar a fondo UIScrollView
• cómo encontrar trozos de código en Internet que me resuelvan problemas
• cómo distribuir una App de forma sencilla para que el cliente la pruebe sin tener que ir yo a instalarla en sus dispositivos (gracias @xelecto por enseñarme BetaBuilder)
• a hacer un MVC del que me sienta contento
• a comenzar un proyecto pensando en cómo voy a reutilizar el código
• que el iPad no tiene motor de vibración
• que desarrollar para un estudio de diseñadores te abre los ojos sobre muchos aspectos de diseño, pero también a ratos te hace odiar a la raza humana.

Cambiando de evento

Increíblemente he cumplido «casi» perfectamente en tiempo, pese a estar con mil cosas a la vez. Y me he vendido muy barato, debo decirlo, porque el proyecto me atraía mucho.

Tengo ahora una buena base para plantearme una App que cuente cuentos, o explique cosas (al estilo de aquellos estupendos libros de «Cómo funcionan las cosas»).

Así que ya sabes: si tienes una App interesante para desarrollar, dinero en el bolsillo y las ideas claras, siempre puedes contactar conmigo para contratarme como desarrollador Freelance. O directamente puedes donarme el dinero y ya yo voy haciendo algo «magical»

Batalla de Trafalgar

85% Cocoa Podcast. Pulsa para ir al podcast. Imagen usada sin consentimiento de nadie. Espero que no me denuncien

Que escucho 85% Cocoa habitualmente es algo que cualquiera que se lea mi timeline de Twitter verá en un rato. Es un podcast que te anima a seguir aprendiendo cosas en el mundo del desarrollo Mac con Cocoa, y que trata también temas extrapolables al desarrollo con cualquier lenguaje. ¡Jose Antonio Lobato hasta habla de cómo correr en su podcast!. Te lo recomiendo si programas en cualquier lenguaje. Bueno, si lo haces en Haskell o BrainFuck estás más allá de toda ayuda o tratamiento…

En el episodio 19 Jose tuvo a bien invitarme a hablar, junto con su socio en Binary Tricks, Jesús Fidalgo (@jfid), sobre los sistemas de gestión de bugs, tareas, tickets o asuntos (issues) que usamos. En mi caso, hablé de FogBugz, que es el que actualmente uso. Me he dado cuenta de que en esta entrada prometía hablar de FogBugz en el blog. Bueno, considero mi cuenta saldada conmigo mismo

La charla me resultó muy, muy agradable. Me la pasé rebién, que dicen los argentinos. La hora que estuvimos hablando se fue en un momento, y tratamos muchos temas. Quiero dejar aquí el enlace al artículo en el que Joel Spolsky explica su «Evidence Based Scheduling», es decir, su sistema de «predicción» estadística de la probabilidad real que tienes de lanzar tu producto en las fechas que tú propones. Es lectura obligada.

Curiosamente ha levantado cierto revuelo la frase «el terrible complejo de sentirse inútil», que es lo que cada informático siente todos los días de su vida cuando se levanta de la cama. Con el ritmo de cambio habitual, siempre tienes la sensación de no saber nada. Pero eso no es real. Voy a dedicar algún post a este tema, ya que creo que necesitamos mucha terapia de grupo.

Y nada más. Que espero que lo disfrutéis y que, si no conocíais el podcast os apuntéis a el. Y, por cierto, es harto desagradable la experiencia de escucharte a ti mismo durante una hora. Nadie debería tener una voz que suene distinta fuera de su cabeza.

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

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!

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

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!

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!

]]> /2010/11/14/como-estoy-aprendiendo-a-programar-en-cocoa-touch-para-ios/feed/ 13