1.- Yo programaba en C y Pascal cuando si no programabas en Java alguien mataba a un gatito recién nacido en Australia.
2.- Yo programaba en Javascript cuando no existía el AJAX, y lo que yo hacía se llamaba DHTML. Entonces, el JS no era un “lenguaje de programación”, era un “lenguaje de script” y estaba un escalón por encima de escribir fórmulas en Excel. Y si hacías DHTML, alguien mataba un gatito recién nacido en Australia.
3.- Yo programaba en ActionScript cuando todavía no existía el concepto de “flash developer”, y todo el mundo se pensaba que en realidad era un diseñador con ínfulas. Más gatitos muertos en Australia. Lo de las ínfulas ha sido siempre verdad.
4.- Yo programaba en C++ cuando sobrecargar un operador hacía que alguien matara un gatito en Australia.
5.- Ahora, programo en Objective-C, contribuyendo a la expansión del mal por el mundo. Gatito. Australia.
6.- Durante todo ese tiempo, además, he sido maquero. Para más inri, teniendo que esconder mi verdadera identidad en un mundo lleno de bindos y unixes.
7.- Firefox en Mac (como todas la aplicaciones desarrolladas con cualquier kit cross-platform) me parece más feo que matar a un gatito en Australia. En bindos, eso sí, donde no está fuera del tiesto, me gusta. Opera me produce desprendimientos de retina en cualquier plataforma.

Como decía un antiguo jefe: la primera vez es un accidente, la segunda es casualidad, la tercera es un patrón.

Me siento, oficialmente, como el tipo que se compró el último reproductor de vídeo Betamax.

Nota del autor. El post anterior podría resumirse en “en esto del desarrollo, como en tantas otras cosas, las modas vienen y van y siempre va a haber alguien que te diga que lo que haces está mal, y que por tu culpa alguien está matando un gatito en Australia”.

Con las honrosas excepciones de rigor, algunas de las cuales leerán esto, la situación me recuerda, en muchos aspectos, al “o estás conmigo, o estás con los terroristas” que tan buenos resultados ha venido dando a la civilización occidental durante los últimos años.

Sinceramente, al igual que entonces, la “calidad” y “profundidad” de los argumentos de muchos hacen flaco favor a los que los emiten.

Si se formatea el selector como un Outlet estándar, no debería haber mayor problema, ¿cierto? No señor, aparentemente, en algunas máquinas, sin saber porqué, el selector en cuestión sólo recibe el mensaje la segunda vez que se hace el doble click, y no la primera.

¿La solución?

Indicar al NSTableView, explícitamente, cuál es el target.

Supongamos un xib que contiene una instancia de NSArrayController, con el binding para el Managed Object Context correctamente asignado.

Imaginemos que al arrancar la aplicación, queremos obtener el número de elementos gestionados por ese array controller. Lo lógico sería hacer algo como esto (en el controlador de la aplicación, por ejemplo, y suponiendo la existencia de un outlet al arraycontroller):

Bien, pues eso va a devolver un cero como una casa de grande. ¿Por qué? Porque en el momento de completarse la carga del nib, no se ha completado la carga de las entidades gestionadas por el controlador.

Hay varias posibles soluciones. La primera, usar KVO, y observar el contenido del array controller, hasta recibir datos. La segunda, la recomendada en la documentación de Apple, forzar al controlador a cargar datos inmediatamente, haciendo un fetch con una request nula:

Para que conste. Porque el tema es útil, sobre todo cuando se pretende cargar un controlador, con datos, en un xib que se carga dinámicamente.

Me tomo la libertad de extraer una cita:

Any real developer would not in good conscience be able to support this

refiriéndose al portazo en las narices que Apple les ha pegado.

Enhorabuena, chaval, has conseguido hacerlo personal. Porque resulta que este developer (aparentemente no tan “real” o con no tan buena intención) no comparte tu indignación. Más personal todavía, por todo lo que en su día este not-real-developer le entregó a la plataforma (algo que llevo ya unos cuantos años lamentando profundamente).

Increíble: Adobe, haciéndose la víctima de todo este asunto, intentando venderse como el paladín de las plataformas abiertas, y super-preocupados por los usuarios de iPhone. Lo que hay que ver…

Por cierto, yo sí que dejo los comentarios abiertos para los spam-bots de Adobe. Obviamente, nadie va a comentar, fundamentalmente porque nadie lee esto, pero eso me da una altura moral que te cagas. La que no me dan ni mi condición de not-real-developer ni mi turbia conciencia.

El desarrollo para iPhone tiene dos grandes problemas. En primer lugar, el propio éxito del aparato, favorito entre adolescentes y postadolescentes, ha, por un lado, tirado de los precios hacia abajo, y por otro, hecho de la App Store una lotería. Lo que lleva al segundo de los grandes problemas del desarrollo para iPhone: es muy complicado conseguir mantenerse a medio plazo.

Imagino que hoy habrá ya quien esté berreando a los cuatro vientos que el desarrollo para escritorio está muerto, y después del iPad más que muerto. Déjenme decirles que quien diga eso no tiene ni puñetera idea de lo que está hablando.

Hacer marketing, hacer que la gente sepa que tu aplicación de escritorio existe es muy complicado, cierto. Pero hacer lo mismo para una aplicación de iPhone es como jugar a la ruleta rusa. En escritorio, con paciencia, cuidando a los usuarios, lanzando actualizaciones de forma regular, e intentando no cagarla mucho, se puede ir, poco a poco, consiguiendo una cantidad de usuarios que pueden llegar a hacer un proyecto sostenible a largo plazo. La historia de siempre: vende algo construido lo mejor posible, sé honesto, y con el tiempo y paciencia las cosas irán saliendo bien.

En iPhone no es posible hacer eso. El mercado pega bandazos de moda en moda (las linternas, los pedos, los chistes, etc…), modas todas ellas efímeras y sin mucho fundamento detrás. Los que estaban al principio de la App Store pueden estar saliendo adelante perfectamente, pero para el resto, para el que sube la trigésima aplicación para pintar bigotes encima de la foto de la suegra, lo más probable es que todo termine en batacazo.

La otra opción es tirar por algo más “serio”. Llamemos serio a una aplicación datacéntrica, que resuelve algún tipo de problema concreto, no algo que sirva para vacilar a los amigos con lo que mola mi teléfono. Gestión de tareas, editor de audio, cosas en esa línea.

Bien, desarrollar algo más complejo lleva tiempo, y mucho. Y pese a que los frameworks sobre los que se trabaja son muy sólidos, hay que vencer una serie de limitaciones muy importantes, sobre todo la falta de espacio en pantalla. Lo que hace que lleve aún más tiempo desarrollar algo complejo.

Y ahí es donde está el problema. ¿A qué precio puedes vender una aplicación así? Hay algunos, los cuatro grandes nombres, que pueden apuntar a los 8 USD, pero lo cierto es que lanzar una aplicación a ese precio va a hacer que no la compre mucha gente, por lo que no va a estar en los tops, por lo que nadie va a saber que existe, por lo que no la va a comprar mucha gente. Resumiendo, me parece mucho más sencillo, pese a lo complicado que es, conseguir que tu tiempo de desarrollo se vea recompensado económicamente en escritorio que en iPhone.

Pero ahora llega el iPad. A priori, es menos cool que un iPhone, por lo que podría suponerse que sus usuarios van a estar más en el rango de los que quieren hacer tareas de computación ligeras cuando salen por ahí, que en el rango de los que quieren vacilar a sus amigos con el cacharro.

Por lo que, también a priori, el mercado debería ser más parecido al de escritorio que al de iPhone. Puede pensarse que primarán las necesidades de productividad, sobre las de “mira lo que tengo en mi paratín”.

Resumiendo. Nadie sabe, yo el primero, en lo que va a derivar todo esto. Pero lo que sí sé es que para mí al menos, ha llegado el momento de replantearme la viabilidad de un par de ideas que había dejado aparcadas. Tal vez, parece que a lo mejor lo mismo puede que, sea el momento de dedicar un mes a desarrollar un producto lo más sólido posible para iPad. O no, pero por lo menos lo voy a considerar, algo que no pensaba hacer en iPhone.

Para los que hayan estado debajo de una piedra en los últimos años, el tablet es una cosa de lo que todo el mundo, menos Apple, lleva hablando meses, y que todo el mundo, menos Apple, ha dicho que se va a anunciar mañana.

Bien, pues vamos con la secuencia de acontecimientos. Como es una secuencia, el lector puede suponer que se va a producir, secuencialmente, en el orden descrito.

1. Todos los makeros andamos hoy como pollos sin cabeza. Sin comer en todo el día, tomando café por litros, sin llegarnos la camisa al cuerpo.
2. Cadena de leaks (todos de mentira), con supuestas fotos/vídeos robados del aparatín en la factoría de Cantón.
3. Algún que otro leak con visos de realidad.
4. Excitación máxima minutos antes del comienzo de la Stevenote.
5. Decepción máxima para unos, minutos después del final de la Stevenote, histeria incontrolable en otros.
6. El más decepcionado es ése que en su vida ha tocado un Mac, pero que lleva camisetas de Panic, que se siente estafado porque el cacharrín no le va a bajar a hacer la compra, o porque sólo sale en USA, o porque no lo van a sacar a la venta hasta dentro de tres meses*.
7. Analistas que no saben ni cambiar una bombilla, se lian la manta a la cabeza y lanzan previsiones sobre las astronómicas cifras de ventas.
8. Los que siempre protestan, protestan porque la batería del cacharro no es reemplazable. O porque no corre Firefox. O por las dos cosas. O por que no se puede usar un stylus. O porque se va a rallar la pantalla. O porque se les ha colado una señora en la cola del súper.
9. Algún analista, por aquello de marcar diferencias, se lanza a la piscina y predice el fracaso del aparatín. ¿No veis que no tiene batería reemplazable?
10. Se cae twitter.
11. Al mismo tiempo, los makeros nos hemos quedado sin adjetivos épicos, y empezamos a sentir el golpe del bajón de adrenalina.

He dicho.

*Nota: Reality bite.

El proceso de actualización en sí está siendo bastante tranquilo, al menos bastante más tranquilo de lo que me temía. Y es que, como todo programador / técnico de sistemas / persona de bien, creo firmemente que si algo no está roto, no hay necesidad de arreglarlo. O mejor aún, si algo funciona, lo mejor es ni acercarse a ello, no se vaya a enfadar.

Todo esto viene a que Keep Your Word 2 (fabuloso organizador de vocabulario y flashcards para Mac e iPhone, hagamos un poco de SEO), es una actualización de pago. Lo que tiene su importancia si tenemos en consideración los

Antecedentes

Hace ya año y medio, cuando lancé la primera versión pública de la aplicación, lo hice apoyándome en Kagi para procesar las ventas. La razón principal de usar Kagi, y no otros procesadores de cobros, fue que era lo más fácil de montar. Preparar una tienda con un producto es bastante rápido, y ellos mismos proporcionan la generación del número de serie, y el código necesario para comprobar los números de serie en la propia aplicación.

Para un primerizo en estas lides del shareware, era la solución más sencilla, que menos tiempo me quitaba de aquello en lo que realmente necesitaba invertir más tiempo: la aplicación en sí. Resumiendo, con Kagi podía tener cupones de descuento, generación de número de serie y comprobación en cliente en unas tres horas.

Sin embargo, desde el primer momento me quedó claro que el sistema tenía varios puntos débiles, el principal de todos ellos, la integración con el resto de mi web. La tienda podía llegar a integrarse visualmente con el resto de mi web, pero no sin dedicarle mucho tiempo y esfuerzo.

Al irse acercando el momento de empezar a pensar en lanzar el upgrade a la versión 2.0, se hizo evidente otro problema con Kagi: ¿cómo gestionar las actualizaciones? Lo normal es ofrecer la actualización a los que compraron una licencia para la versión 1.x a un precio reducido (en mi caso, con un 40% de descuento).

Hay que tener en cuenta que la tienda que ofrece Kagi no permite añadir ninguna lógica personalizada. El flujo está prefijado, y no es configurable: primero página de productos, después entrada de datos del comprador, terminando con página con confirmación del pedido y entrega del número de serie. No hay forma de hacer algo como esto, hacer al usuario introducir su número de serie actual (de la 1.x), comprobar su validez, y abrir una venta al precio con descuento. Tampoco era posible ofrecer la actualización gratis a los que hubieran comprado la 1.x en los últimos 90 días.

El soporte de Kagi me ofreció una solución un poco pintoresca: crear un descuento del 40%, y asignarle tantos cupones de descuento como usuarios hubiera de la 1.x, haciendo que cada uno de esos cupones fuera uno de los números de serie válidos. Así, al ofrecer el update, comunicar a los usuarios que tenían que introducir su número de serie actual como cupón de descuento para comprar el nuevo serial.

Obviamente, la solución, aunque técnicamente posible, rechina malamente: y es que nadie lee lo que sale en pantalla, y punto pelota. Así que me temía a) tener que explicar 300 veces que para comprar el serial nuevo hay que meter el viejo como cupón de descuento y b) tener que devolver el dinero a muchos que iban a hacer la compra del serial nuevo sin meter el viejo, y por tanto sin descuento.

Total, que se mire como se mire, la solución era más bien mala.

Si a eso le añadimos que Kagi no proporciona una forma de recuperar el número de serie a los usuarios que lo hayan olvidado/perdido, cada vez se iba haciendo más claro que la solución a todos los problemas tenía que pasar por…

Tienda a medida

Si necesito poder comprobar que un número de serie es válido y existe en mi base de datos antes de proceder a la venta, si quiero hacer cosas como promociones puntuales cuando saque el siguiente producto de pago, si quiero dar un formulario donde la gente se pueda recuperar el número de serie por sí misma, si quiero control total sobre lo que sale y cómo sale en mi tienda, tengo que hacerme yo la tienda. Punto.

Obviamente, la primera opción que consideré fue instalar Potion Store, pero ni tengo cuenta Website Payments Pro, ni es que sea muy leído y escribido en Rails, ni puede decirse que me guste lidiar con Paypal.

Como en el momento en el que estaba buscando la solución para la tienda me acababa de quedar colgado con un proyecto terminado pero no entregado que había desarrollado en CakePHP, y la verdad es que el framework me había hecho bastante gracia, aproveché la inercia, y me decidí a hacer una gestor muy sencillo para la nueva tienda de bambooapps.

El problema, no obstante, era el procesador de pagos. Podía hacer que fuera Paypal, pero al no poder tener cuenta Payments Pro, la única opción es lanzar al comprador fuera de mi web, hacia Paypal, y esperar que la compra se cierre correctamente, para que al volver a mi servidor, pueda generar el número de serie. Además, Paypal oscurece cada vez más la posibilidad de pagar sin tener cuenta de usuario en su servicio, lo que me hacía temer que podía perder alguna que otra venta. Y no estamos para regalar el dinero.

Y aquí es cuando llegamos a…

FastSpring

FastSpring tiene buenas reviews, y fama de ofrecer un servicio al usuario de primera. Y sobre todo, el haber visto tiendas de otros desarrolladores perfectamente integradas con el resto de sus sitios web.

La primera impresión al abrir una cuenta fue muy buena. Nada más pedir el alta, recibí un email pidiéndome unos cuantos datos básicos sobre mi producto (nombre, precio, icono…) y en unas dos horas ya tenía una tienda funcional, con la que ya podría haber empezado a vender KYWs como rosquillas.

La personalización de sus páginas es muy sencilla (básicamente una plantilla que envuelve a la de ellos), y aunque el proceso de venta en sí también es bastante rígido (presentación de producto-> confirmación de pedido -> entrega serial), el sistema permite varios grados de flexibilidad más que Kagi. Para empezar, pueden embeberse cupones de descuento y otra información en la url, lo que me permite lanzar desde mi tienda en CakePHP todo tipo de ofertas, cross-selling, upselling, etc.

Otra cosa que me ha gustado de FastSpring, y de la que no me di cuenta hasta no empezar a trastear con su sistema, es lo fácil que es integrar la tienda con un generador de números de serie en mi servidor. Al contrario que Kagi, que aunque también permite generar el serial en tu servidor, requiere de un proceso administrativo de casi una semana para dar de alta la opción, basta con introducir la url de tu generador en la administración de FastSpring, asignar user y password para securizar la comunicación, y decidir qué quieres enviar a tu servidor, y qué quieres que éste conteste al suyo.

De esa forma, yo controlo qué quiero cobrar y cómo, paso el control a FastSpring, que en un interfaz completamente integrado con el mío, gestiona el cargo a la tarjeta, pide a mi servidor el serial, y se lo entrega al usuario. Obviamente, yo también aprovecho ese momento para automatizar una serie de cosas en mi lado, como el registro del nombre, email y serial del usuario en mi base de datos, alta en mi lista de correo, o la emisión de un email con la licencia.

El sistema sigue sin ser perfecto, sigue habiendo un punto del proceso donde pierdo el control del mismo, y hay un punto en el que todo depende de que dos servidores se entiendan sin problemas, así que sigue habiendo fricciones. No obstante, los riesgos son mucho menores que las ganancias con el nuevo sistema.

Y alguno se preguntará… ¿por qué cuentas todo esto? La verdad es que no lo sé. Imagino que por enfatizar un aspecto del desarrollo de software que siempre me ha parecido el más importante: el refinamiento sucesivo, el intentar montar algo que funcione adecuadamente con el mínimo de recursos aceptables, hacerlo público, sacarlo por la puerta, y a partir de ese momento, ir mejorándolo, ir engordándolo, de forma constante, añadiendo mejoras cuando sea necesario añadirlas, y refactorizando procesos cuando sea necesario hacerlo.

O dicho de otra forma, es muy probable que si hubiera tenido que montar mi propia tienda, con mi propio generador de números de serie, integrado con una tercera parte para procesar los pagos, no hubiera sacado la 1.0 nunca.

Los motivos de la elección de ese framework en concreto son múltiples, y al contrario de lo que suele ocurrir en estos casos, y una vez terminado el proyecto, debo reconocer que la elección ha sido un acierto, y que cada día me gusta más el framework.

Una de las soluciones que me han parecido más elegantes es la que han adoptado para el envío de correos electrónicos. Configuración cero, y separación de la presentación del email en dos capas: por un lado, el layout general y por otro la vista del mensaje.

Enviar un mensaje es muy sencillo. Por ejemplo:

Este método es un método privado de un controlador encargado de gestionar los usuarios registrados, y que envía el típico email de recuperación de número de serie.

La presentación del email a enviar está separada en dos partes. Por un lado el layout general, se encuentra en app/layouts/email/html/default.ctp, en el caso del mensaje en formato html, y en app/layouts/email/text/default.ctp para el mensaje de sólo texto. El layout podría ser algo como:

El contenido real del mensaje, las dos vistas, html y texto, están en app/views/email/html/simple_message.ctp y app/views/email/text/simple_message.ctp

Por ejemplo, la vista para el mensaje html podría ser algo como:

Y ya está. Separación perfecta de lógica, datos y presentación. Solución elegante.

Hoy vamos a fijarnos en otro tipo de usuarios, los que no han licenciado la aplicación. Pero, primero, vamos con una explicación de cómo se han realizado las estimaciones que han llevado a los resultados finales.

Keep Your Word puede sincronizar datos con un cliente para iPhone e iPod Touch, que se distribuye de forma gratuita, y que no sirve para nada sin la aplicación de escritorio. Dicho de otra forma, no tiene mucho sentido descargarse el cliente iPhone si no se tiene la aplicación de escritorio, por un lado, y por otro, si se consigue la aplicación para Mac por canales de distribución alternativos, cualquiera puede hacerse con la parte para iPhone desde la AppStore sin problemas.

En la descripción de la aplicación en la AppStore se deja claro que no sirve de nada sin su acompañamiento de escritorio. No obstante, como todos sabemos perfectamente, en internet no se lee nada. Sé, por tanto, que habrá quien se la instale simplemente porque es gratis, sin mirar si le puede servir para algo o no.

También hay que tener en cuenta que, al tener la aplicación para Mac un período de prueba de 30 días, habrá quien se instale el cliente iPhone aunque posteriormente no compre la licencia.

No obstante, eso no es un problema para realizar unas cuantas estimaciones de la forma siguiente:

1. Calculamos el total de descargas, por países, del cliente iPhone.
2. Multiplicamos por 10 el total de licencias por países de la aplicación para Mac (para tener más cifras significativas).
3. Dividimos el número de descargas del cliente iPhone por el número de licencias vendidas para cada país.
4. Normalizamos los resultados, haciendo que el valor obtenido para Alemania (donde el resultado es menor), equivalga a un valor de 10 en la Escala de Piratines (que va de 1 a 100).

El resultado final es el siguiente:

He eliminado del gráfico todos los valores intermedios, por aquello de hacer sangre y fijarnos sólo en los países com mayor Piratina.

Un breve análisis de los resultados nos arroja las siguientes conclusiones:

• La mayoría de los países están o en el rango del 80-100, o en el de 10-50, con muy pocos en el 50-80. Podría concluirse que hay sitios en los que la Piratina es alta, otros en los que la Piratina es muy baja, y muy pocos en los que no la Piratina ni es ni alta ni baja.
• Nótese la posición de España. Sin más comentarios.
• El valor real de la Piratina para China debería ser de infinito, no 100 (los que sepan lo que pasa cuando de divide un número por cero, y que hayan seguido la explicación lo entenderán). Pero como había que meterla en el gráfico…

Por favor, que nadie se tome esto más en serio de lo que es: un mero ejercicio numérico. Creo firmemente que la posible categorización de los usuarios de aparatos de computación en relación con la Piratina no es vertical (por países) sino trasversal, en dos grupos: los que compran software, y los que no lo compran. El que compra software revisa sus opciones, considera alternativas open source, sopesa precios y funcionalidades, o simplemente compra lo que le parece cool, y el que no compra, se niega a comprar, en ocasiones justificando su negativa en argumentos épicos, y acude siempre a las mismas fuentes cuando una aplicación llama su atención.

Eso es un hecho inevitable, que hay que tomarse como la muerte, los impuestos o Gran Hermano: como algo que sabemos que está ahí, que antes o después va a llegar, pero contra lo que no merece la pena hacer nada, porque no hay nada que se pueda hacer.

Mi opinión respecto a este tema no ha cambiado. Prefiero dedicar mi tiempo (o dicho de otra forma, invertir mi dinero) en amasar la aplicación que en intentar que nadie se la lleve del horno.

Pero eso no quita para que, de vez en cuando, también sea divertido jugar con los números.