Omar Gómez

Si ud. es como yo, quizás tenga problemas entendiendo y aún peor memorizando los pasos que un desarrollador de aplicaciones iOS debe seguir para instalar sus aplicaciones en los dispositivos de prueba.

Comparado con Android este proceso se siente burocrático y lento, pero este es el precio que Apple nos impone por asegurarse que hemos pagado la licencia de desarrollador y que nuestras herramientas y dispositivos de prueba sean ‘legales’.

El proceso en detalle está explicado por Gustavo Ambrozio en el popular blog de Ray Wenderlich . Básicamente el proceso tiene dos objetivos que explico simplificademente a continuación.

Trabajar desde una máquina ligada a una cuenta paga de desarrollador

Hay un intercambio de claves entre mi usuario en OSX y mi cuenta del iOS Developer Center. La instalación del certificado es obligatoria para instalar aplicaciones a dispositivos ( iPhone, iPad ) desde nuestras máquinas de desarrollo.

Autorizar dispositivos / Aplicaciones

Tan pronto nuestra máquina sea reconocida por Apple podemos crear aplicaciones e instalarlas en dispositivos reales. Pero no inmediatamente, tenemos que decirle a Apple que aplicaciones quiero instalar y en cuales dispositivos. Esta información viene empaquetada en forma de un archivo especial: El Developer Provisioning Profile.

Le decimos a Apple cual aplicación queremos desarrollar entregándole el ID de la aplicación. Este ID es una cadena de texto con una estructura similar a como se nombran los paquetes en el lenguaje de programación Java: [dominio].[empresa].[aplicación] . Por ejemplo, para Colorpedia, la primera aplicación que publiqué en el App Strore, utilizé el ID ‘com.pixagora.colorpedia’. Este ID también puede contener asteriscos, queriendo decir con esto que quiero instalar un conjunto de aplicaciones. Por ejemplo el ID ‘com.pixagora.*’ sería válido para todas las aplicaciones cuyo ID comienze por ‘com.pixagora.’ . Cuando entremos nuestro ID en la página de registro de aplicaciones Apple adiciona otra cadena más como prefijo. El ID final puede parecerse a algo como ’53YEG53RP9.com.pixagora.colorpedia’.

El(Los) dispositivo(s) en los que quiero instalar la aplicación ( durante desarrollo ) deben también identificarse contra Apple. Pueden utilizar iTunes para obtener este número de 40 caracteres, que luce como ’2b6f0cc904d137be2e1730235f5664094b831186′.

El archivo de provisioning

Tan pronto hallan adicionado la aplicación y el(los) dispositivo(s) pueden generar el archivo de provisioning. Al hacer esto también deben seleccionar el certificado que debe corresponder al que instalaron en la máquina hacia donde se desea instalar el provisioning. Para instalar el archivo de provisioning sólo deben abrirlo con XCode.

El certificado y el provisioning generado es valido por un año, si al terminar este año ya han olvidado estos pasos pueden volver a la entrada de mi Blog. También hice disponible una versión en PDF del workflow en caso que quieran mantenerla en sus máquinas de trabajo. En una próxima entrada voy a explicar el workflow para instalar aplicaciones en dispositivos de prueba. Este proceso es un poco deferente, ya que no se espera que los usuarios de prueba \tengan certificados de desarrollo instalados en sus máquinas.

Este año inició operaciones Coursera, la plataforma para educación en línea respaldada por la Universidad de Stanford. En esta entrada de mi blog quiero contarles mi experiencia tras haber realizado el curso de NLP ( procesamiento de lenguaje natural ) en ella.

Mi intención inicial era empezar con el curso de HCI ( Interfaces Humano Computador ), el cual había sido anunciado desde Enero ( arrancó mientras escribía esta entrada ), pero este se retrasó y pensé que mientras tanto podría ver el de NLP, otro de los temas que quiero aprender.

La Inscripción

(Hacer click sobre la imagen para verla en su tamaño original) Para inscribirse a Coursera sólo es necesario crear una cuenta, esta te dará tu identidad como estudiante. Sólo debes entrar tu nombre, tu correo y tu clave de seguridad.

Código de Honor

Al iniciar el curso se debe aceptar el código de honor (algo muy similar a los ‘Términos y Condiciones’ del software). Este código de honor es un acuerdo en el que se establace que es lo que significa ‘hacer trampa’. Para el curso de NLP, el código de honor implica que los estudiantes no deben copiar las respuestas de los ejercicios o manipular la ‘test data’ ( datos escondidos de prueba ).

Estructura del curso

En la imagen previa se ve la página que lista los videos del curso. Estos vienen agrupados por temas; los cuales a su vez, vienen ordenados por semana. Los videos pueden verse diractamente en línea u offline descargando el archivo correspondiente. Cada uno dura entre 4 a 20 minutos.

Los videos mismos son bien producidos. Usan como fondo la diapositiva del tema discutido mientras que el profesor aparece en una esquina haciendo los comentarios respectivos mientras al tiempo hace anotaciones mediante un marcador virtual ( las líneas púrpuras que se alcanzan a notar ). Las diapositivas sin anotaciones también están disponibles para verlas offline.

Quizzes

Debe presentarse un quizz por semana y su nivel de dificultad depende del tema de que trate esa semana. Cada quiz puede presentarse 5 veces sin ninguna penalidad excepto la de no pasarse de las fechas límites de entrega. Hay preguntas de completación, así que no es que se pueda sacar 5 (máx nota) tán fácilmente como se piensa. Algunos ejercicios son largos, pero con el material a la mano, completarlos es bastante posible ( teniendo disponibilidad de tiempo ).

Tareas de programación

La verdadera ‘carne’ del curso son las tareas de programación. Nuevamente su nivel de dificultad depende del tema tratado en la semana, pero si se tiene algo de experiencia programando pueden realizarse. El como fueron diseñados me parece que fué una de las genialidades de los creadores de la plataforma. Existía un enunciado y un enlace a un ZIP con el código con el que el estudiante empieza su trabajo. Convenientemente se ofrecen dos opciones, Java y Python. Yo siempre escogí Python, lenguaje con el que me defiendo y me gusta programar. El ehercicio más demorado me tomó tres días de trabajo. El PA6 (  Programmig Assignment 6 ) fué el coco del curso, y de hecho en los foros se discusión había una entrada polémica en el que se planteaba acerca de si era viable que un ejercicio de esa complejidad fuera parte del programa. En lo personal creo que valió la pena, ya que en otros comentarios, estudiantes con experiencia en el campo lo comparaban con el trabajo de la vida real.

El código que se baja al principio es una especie de plantilla, que el estudiante debe completar en determinados puntos según el problema. Mietras se prueba el problema se trabaja con un conjunto de datos para desarrollo. Cuando uno cree finalizado su trabajo ejecuta un comando que envía el resultado a un servidor que lo califica. Aquí hay un giro interesante, ya que no sólo envía el resultado del algoritmo trabajando sobre los datos de desarrollo, sino que también corre el algoritmo sobre los datos de prueba, que se suponen escondidos. Esta es una forma de evaluar muy particular de los cursos que tienen que ver con creación de modelos estadísticos, ya que en el mundo real también hay una muestra con la que se diseña el modelo. Pero sólo es hasta que el modelo se corre bajo las condiciones del mundo real ( los datos test ) cuando realmente se ve que tan general es la solución.

Foros

Otro demis aspectos favoritos de Coursera fueron los foros. Se nota cuanto trabajo se tomaron en diseñarlos bien, al grado que creo que es el mejor sistema de foros que conozco.

Particularmente útiles son los foros relacionados con las tareas de programación ( que muestro arriba ). Estos fueron estratégicos para completar exitosamente las tareas. La efectividdad del foro creo que tiene que ver con las herramientas que ofrece para permitir que el foro se autorregule. Posee un sistema de votación ( muy similar al popular stio Stack Overflow ) en el que los estudiantes suben o bajan la calificación de las entradas de acuerdo a su aporte/relevancia. También las entradas se pueden etiquetar ( como en las folcsonomías de sistemas como Delicious ) así que buscar entradas por temas particulares es realmente sencillo. En general se siente muy moderno y ‘social’.

Calificación

Cada tarea de programación aporta el 9% de la nota final del curso ( 8 tareas = 72% ) mientras que los quizas suman el 3.5% ( 8 quizzes = 28% ). Con un poco más de tiempo y dedicación mis notas hubieran sido mejores que 72/100, sólo dos puntos por encima de la nota mínima que era 70/100. Al ganar el curso tengo derecho a un certificado, no de Stanford, pero si de los profesores Dan y Chris. No me imagino este certificado para que pueda servir, menos con una nota tan mediocre. Una estadística que si me gustaría conocer es el número de estudiantes inscritos vs. los ‘graduados’.

Comentarios finales

Espero haber tocado los temas que uds. querían conocer de Coursera o de este curso en particular. Tuve suerte de tener el tiempo de terminarlo, y no veo como yo pude haber accedido a un curso de esta calidad en Medellín ( aún pagando ). Lo recomiendo un 110%.

La pregunta final que yo me hago es: Al final que van a hacer las univerisidades tradicionales con toda su infraestructura de la época pre-aprendizaje-online? . Si esta es la versión Beta de la plataforma, no me imagino que esta por llegar.

Colombia fué uno de los primeros países de Suramérica en adoptar ampliamente los teléfonos celulares. Y es que según las cifras registradas para la penetración del uso de la tecnología celular en Latinoamérica, a los Colombianos nos gusta bastante este medio de comunicación, por lo menos lo suficiente para estar bastante por encima del promedio en nuestra región. Y esto es algo que se puede notar fácilmente en la calle, ya que es más fácil encontrar gente sin su cédula que sin su teléfono celular.

El problema es que hablar de teléfonos celulares es una cosa y de teléfonos inteligentes una cosa muy distinta y las altas cifras de penetración de la telefonía celular en Colombia no se corresponden con las nuevas tecnologías móviles.

El dispositivo más popular en nuestro país es la línea Blackberry (BB) de la empresa canadiense Research in Motion. Estudios informales afirman que 1 de cada 4 teléfonos inteligentes es un BB, esta cifra se puede confirmar fácilmente, ya que en cualquier sitio público los BB tienen más notoriedad que cualquier otro dispositivo. El éxito de esta marca tiene que ver en como evolucionó su uso desde su introducción hace sólo unos años, cuando se volvieron el caballito de batalla de los ejecutivos en el mundo corporativo, en dónde estar permanente conectado al correo y a la mensajería instantánea es clave. La manera en que fueron comercializados también fué muy efectiva, y no sólo en Colombia, sino en el resto de Latinoamerica y Africa, donde el costo de los equipos era subsidiado por el plan de datos que era necesario adquirir. De esta manera estos equipos dejaron de ser símbolos de estatus en las empresas, y pasaron a las manos de los consumidores de a pié.

Es verdad que el teclado del BB sea cómodo y que sus aplicaciones, sobre todo la mensajería y el correo sean casi todo lo que una persona “común” necesita, sin embargo no creo que el futuro de los teléfonos inteligentes vaya a pertenecer a BB. El primer síntoma de preocupación es que en los países del primer mundo el crecimiento de la participación de RIM esta estancado (Europa) o en retroceso (EEUU). Particularmente los aportes en la innovación que ha logrado Steve Jobs y compañía han cambiado las espectativas de los consumidores de teléfonos inteligentes. Después del iPhone los teléfonos deben ser más fáciles de usar, más interactivos (juegos, multimedia, realidad aumentada), con más funciones (sin dejar de ser fáciles de usar) y con una gran biblioteca de aplicaciones. Todas estas características las tienen los teléfonos iPhone y en cierto grado los Android (cuyo mercado es el que más ha crecido). El usuario BB nunca ha tenido estas preocupaciones y fué así como RIM, al tratar de hacer felices a su base de fans originales, se fué quedando rezagada de Apple y Google.

Sería interesante pensar que los Colombianos usáramos más iPhones y Galaxy SII que BBs, pero veo esto dificil. No sólo es el hecho de que la cultura BB ya esta fuertemente arraigada (dame tu PIN) , sino porque los tres grandes operadores ( Comcel, Movistar, Tigo ) no están interesados en subsidiar teléfonos de gama alta. Cuando se adquiere un teléfono en EEUU y Europa es común que el teléfono mismo ( independientemente de la gama ) sea gratis con una aceptable plan de datos, mientras que en nuestro país debemos pagar más de un millón de pesos por un buen teléfono.

Este no sólo limita las opciones del consumidor Colombiano, sino que tiene un efecto devastador en las jóvenes empresas locales dedicadas al desarrollo de soluciones móbiles. La mayoría de ellas tienen que sobrevivir mediante el desarrollo de soluciones para backend o web ya que la demanda local de Apps móbiles es demasiado baja. Hablando de empresas de desarrollo móbil también pienso que la falta de una sana demanda afecta el nivel (calidad) de sus Apps. La App de Bancolombia y Cinecolombia, dos gigantes en términos del tamaño de su público objetivo han fallado en crear aplicaciones que cautiven a sus usuarios.

Crucemos los dedos pues para que Colombia pase con éxito a la otra orilla del mercado móbil. Un mercado con mayor cantidad y variedad de teléfonos inteligentes, con usuarios demandando Apps que generen valor y empresas de desarrollo locales adquiriendo las habilidades que les permitan convertirse en jugadores globales.

Quiero en esta entrada de mi blog ponerle cara a uno de los mayores retos cuando se desarrollan aplicaciones para el ecosistema Android, este es, su fragmentación. Una forma de ver esta fragmentación es analizar las diferentes versiones del sistema operacional, y para esto, Google tiene una página en su sitio de desarrolladores dónde se presenta la siguiente gráfica:

Programando para Eclair (2.1) se cubre casi el 100% de la plataforma, pero vale la pena pensar si es mejor programar para Froyo, ya que sólo se sacrificaría un 8.5% más de dispositivos pero se ahorraría un porcentaje más grandes de dolores de cabeza al programar con más y mejores APIs.

Todos estos datos son muy interesantes, pero son las métricas sobre tamaños de pantallas y densidades las que más llaman mi atención:

Me importa porque es esta variabilidad la más impacta los desarrollos en Android. Sólo un diseñador de aplicaciones para Android sabe lo que implica diseñar la experiencia de usuario para una pantalla con tamaños, densidades y proporciones tan variables. Pero, Qué tanto varían realmente las pantallas de los dispositivos Android ?. Esta es la pregunta que trato de responer más adelante.

El primer paso consiste en conocer cuales son los dispositivos más populares en el Android Market. Por suerte encontré la página de AppBrain Android Stats, dónde diferentes métricas del Market son graficadas, entre ellas, la de los dispositivos más populares del mercado ( dejé por fuera la Galaxy Tab ya que quiero analizar sólo teléfonos ):

1. Samsung Galaxy S2
2. Samsung Galaxy S
3. HTC Evo 4G
4. HTC Desire HD
5. HTC Desire
6. Motorola Droid X
7. Samsung Galaxy Ace
8. Samsung Galaxy Mini
9. Samsung Galaxy Note
10. Samsung Galaxy Y
11. Galaxy Nexus
12. LG Optimus S
13. Sanyo Zio
14. HTC Droid Incredible
15. Sony Ericsson Xperia X10
16. HTC Wildfire
17. HTC Evo 3D
18. HTC Sensation
19. Samsung Epic 4G

No hay muchas sorpresas aquí, es muy claro que Samsung y HTC son los que dominan el mercado, sólo sorprende la poca presencia de Sony en esta lista.

El siguiente paso fue el relacionar estos teléfonos con las métricas de sus pantallas y crear una gráfica donde pueda apreciarse que tanto cambian las dos variables que nos interesan como desarrolladores: el tamaño y la densidad:

Como puede verse el panorama no es muy alentador. El tamaño varía entre las 3.1″ de un Samsung Galaxy Mini hasta las impresionantes 5.3″ de un Galaxy Note. La gráfica tiene en cuenta la resolución en pixeles y la proporción (aspect ratio). Decidí incluir la proporción en la gráfica ya que a veces se subestima el esfuerzo que implica hacer diseños compatibles tanto con dispositivos “gorditos” ( como el Samsung Galaxy Y ) como con dispositivos “larguitos” ( como el HTC Sensation ). En cuanto a la densidad, encontramos dispositivos de pixeles tan gruesos como el HTC Wildfire ( 125 ppi ) como el Galaxy Nexus, que con sus 316 ppi es casi igual de fino a la pantalla retina del iPhone 4S ( 326 ppi ).

La fragmentación del ecosistema Android es una dura realidad. Su lado positivo es darle a los consumidores mayores opciones al elegir el tipo de dispositivo móvil que desean tener. En una entrada futura, mostraré algunas técnicas para afrontar la problemática del diseño y la implementación de aplicaciones que sean adaptables a la diversidad en tamaños y densidades.

Adobe se rindió en su lucha para hacer que Flash fuera aceptado en los dispositivos móbiles. Nunca sabremos que pasó. No sabremos si los ingenieros no lograron optimizar el runtime para que corriera eficientemente en el limitado hardware de los dispositivos (lo que no creo), o que más bien la posibilidad de portar todo el ecosistema de aplicaciones Flash existentes no servía a los interesas de Apple y su App Store ( lo que encuentro más posible ). Sea como fuere, Adobe de todos modos no hace plata vendiendo el runtime de Flash, lo hace vendiendo las herramientas que crean los contenidos que corren allí. La realidad que tiene que enfrentar Adobe ahora es tratar de generar contenidos para HTML5, y delegar sobre este estándar, lo que antes podía controlar a través de su propio runtime.

Adobe respaldando HTML5 va a ser el empujón final que HTML5 necesitaba, ya que HTML5 siempre ha tenido suficientes méritos técnicos para reemplazar a Flash (sin la necesidad de que Flash se extinguiera), lo que no quiere decir que HTML5 también tenga sus problemas. La especificación se siente un poco cruda en algunas partes (todo lo que tiene que ver con almacenamiento local) y las implementaciones en los navegadores aún no están completamente optimizadas ( Canvas sólo usa la GPU en iOS ). Pero en definitiva el principal problema para su adopción en masa es la falta de buenas herramientas de creación. Los creadores de contenidos profesionales son por lo general diseñadores hábiles técnicamente, pero trabajar “en código” no ayuda a mantener la visión holística que el trabajo creativo necesita. Ellos prefieren el entorno integrado de Adobe para crear las imágenes y las animaciones que las aplicaciones interactivas para internet demandan. Adobe ya presentó Edge, la herramienta que pretende posicionar como el Flash Builder para HTML5. Si esta es su idea creo que le falta mucho por recorrer, ya que Edge todavía usa elementos más propios de HTML4 (divs y CSS) que de HTML5 (Canvas y SVG). El problema con Adobe es que es el guardían del status-quo, así que quizás no sea el lider más indicado para proponer algo innovador en la nueva frontera HTML5. Quizás Sencha, con Sencha Animator, o Tumult Hype, tengan una visión más fresca y creen la “Killer App” de creación que los diseñadores web estén esperando.

Otro camino que será interesante saber hasta donde puede llegar es el que Google esta proponiendo. Swiffy es una herramienta que lee contenidos Flash y los traduce a una representación JSON la cual luego es transmitida al navegador que la reproduce mediante una combinación de SVG, CSS3 y algo de Javascript. Los ejemplos son impresionantes (incluye juegos!) y demuestran la calidad de lo que se puede lograr si contáramos con herramientas de creación adecuadas.

HTML5 a venido evolucionando lentamente, pero pareciera que sus piezas finalmente empiezan a encajar y por lo menospara mí, esta va a ser la tecnología a vigilar en el 2012.

Mi trabajo actual me ha dado la privilegiada oportunidad de desarrollar aplicaciones no triviales tanto para Android como para iOS. Con el beneficio adicional de que en algunas ocasiones se ha escrito la misma aplicación bajo ambas plataformas. En esta entrada de mi Blog quiero escribir algunas observaciones sobre mi experiencia trabajando en estas dos plataformas.

Lo bueno

Android y iOS se reparten casi por partes iguales la mayoría del mercado de Smartphones, así que, desde el punto de vista comercial, desarrollar para cualquiera de ellas es buena idea. Muchas de las aplicaciones móviles más populares se encuentran disponibles tanto para Android como para iOS.

iOS tuvo un gran éxito desde su inicio y la información en línea o impresa orientada a principiantes es algo más abundante para la plataforma de Cupertino, sin embargo Android no se queda atrás. Un programador novato no va a tener problemas en encontrar información de referencia que lo soporte en los críticos primeros pasos como desarrolador de Apps.

Otro aspecto a resaltar de iOS es la calidad de sus SDKs. Las APIs son consistentes, aún bajo un lenguaje con una sintaxis tan inusual como la de Objective-C. También ayuda el hecho de que sea compatible con C; con ello usted podrá optimizar su aplicación hasta el último ciclo de la CPU. Todos esto ayuda a producir Apps de excelentísima calidad, una de las marcas característica de iOS como plataforma.

Al ser basado en Java, Android también tiene una ventaja, y es el hecho de aprovechar la base de código más popular que existe. Es posible encontrar casi cualquier librería o algoritmo escrito en Java.

Lo malo

Si vienes del mundo Windows y quieres desarrollar para iOS empieza por revisar tu billetera. Todo el stack de desarrollo para iOS corre sólo bajo OSX así que es necesario adquirir un equipo Mac para poder crear aplicaciones. Aunque existen versiones emuladas de OSX que corren bajo PCs ( Hackintosh ) son complicadas de instalar y se rompen fácilmente con las actualizaciones del sistema. Recomiendo seriamente una Mac como la máquina de desarrollo para iOS.

Una aspecto negativo del mundo Android es la fragmentación, entendida esta como tener que soportar diversidad de versiones del sistema operacional así como diversas capacidades en los dispositivos ( como diferentes resoluciones, tamaños y formatos de pantalla ). Apple hace las cosas fáciles al controlar el hardware y las versiones de iOS. Android demanda crear apps que se ajusten a los diferentes formatos, y si se quiere publicar una App recomendaría probar en diferentes dispositivos que permitan ver como esta se adapta a sus particularidades. Un equipo de prueba serio para Android debería contar con al menos dos dispositivos (gama baja y alta) de cada una de las principales marcas ( Nexus, HTC, Samsung, Sony, LG ), y las empresas de desarrollo para Android deberían incluir actualizaciones a estos equipos en su presupuesto anual.

Lo ridículo

Cuando uno escucha sobre Java y su máquina virtual uno piensa en unas vacaciones lejos del manejo de la memoria, pero la triste realidad en Android es que el SDK esta lleno de huecos por los que se filtran fugas de memoria. Algunas de estas fugas son errores obvios en el diseño del SDK pero otras son pequeñas sutilezas que escapan fácilmente al programador. Mi grupo de trabajo ha invertido demasiado tiempo tratando de detectar y corregir problemas de memoria que no tienen porque ocurrir en primer lugar.

El mundo iOS también tiene sus sorpresas, siendo la más obvia el proceso de distribución de Apps. Todo esta completamente centralizado alrededor del App Store. Con Android sólo basta generar un archivo APK el cual se puede enviar por correo para su instalación. En iOS sin embargo es necesario un juego de certificados y permisos para generar un archivo IPA; un archivo que el cliente puede instalar mediante iTunes ( en un dispositivo que haya sido previamente autorizado ). Recuerde tambien reservar mínimo una semana del cronograma de su proyecto para el tiempo que toma la aprobación de la aplicación en App Store. También rece para que la aplicación no sea rechazada y el cliente tenga que esperar aún más.

Otra sorpresa de iOS es la calidad de XCode, su herramienta de desarrollo. Aunque la última reencarnacion 4.x mejoró bastante el entorno, este no está al mismo nivel de Eclipse en términos de calidad. Son muchas las veces que en Kogi nos hemos arrancado el pelo reconstruyendo proyectos que XCode daña de manera espontánea ( o por settings que no hacen lo que se espera de ellos ). El editor mismo deja mucho que desear para personas acostumbradas a editores potentes como Vim, Emacs o Textmate. Olvídese de macros o aún cosas tan simples como bookmarks. XCode tampoco permite ser extendido con plugins, quizás la fortaleza más grande de Eclipse. Esto es una pena, ya que para estas alturas muchas de las debilidades de XCode hubiesen sido mejoradas por la comunidad.

Lo sublime

A pesar de la sintaxis obtusa de Objective-C se esconde un lenguaje de programación excepcional. Su inusual dualidad estático-dinámico da un tipo de versatilidad que muy pocos lenguajes tienen y con el es posible crear Frameworks como Cocoa, quizás el conjunto de componentes para aplicaciones mejor concebido para cualquier sistema operacional.

Dentro de las deficiencias de XCode también hay una característica que brilla, los “Code Snippets”, que son básicamente plantillas de código reutilizables, que si bien existen en otros entornos de desarrollo, no creo que estén tan bien implementados como en XCode.

Si eres ingeniero de corazón es muy probable que tengas un Android. Al tener un kernel Linux, Android comparte la misma filosofía abierta de “mejóralo como quieras”. Al desarrollador esta filosofía le permite tener acceso a todos los aspectos internos del dispositvo, no sólo mediante las herramientes oficiales de desarrollo, sino también otras más avanzadas creadas por terceros.

Con la ayuda de WPtouch, mi blog ya tiene una presentación aceptable desde dispositivos móviles.

No recuerdo haber visto ninguna renuncia a cualquier cargo en una empresa, tecnológica o de cualquier otra clase, que haya causado más revuelo en los medios que la realizada por Steve Jobs. El tono de los comentarios hechos por periodistas o en las redes sociales también eran muy particulares, ya que se sentía más como un fallecimiento que como una salida corporativa.

Apple como empresa hizo trascender las computadores desde su estado original de calculadoras glorificadas hasta artefactos sobre los que se podía proyectar sincero aprecio. Las dignificó. Hay que entender además que esto no es ninguna tarea fácil, ya que en este sector tecnológico impera la ley del ingeniero y la utilidad. De la mano de Steve Jobs (excepto en el período 85′-97′) Apple creo artilugios tecnológicos empacados como pequeñas obras de arte [1]. Cualquier ingeniero competente puede hacer funcionar algo, pero Steve Jobs sabe realmente como juntar todos esos miles de componentes para impregnarlos de … no sé … grandeza?.[2]

Pero más allá de todos artefactos que Apple logró crear a lo largo de todos estos años, más allá de haber logrado crear la compañia de tecnología más valiosa del mundo, creo que el verdadero legado de Steve Jobs, y la verdadera razón por la cual es universalmente admirado es por su contribución espiritual. Esto no tiene nada que ver con las reacciones de la asistencia en sus apariciones públicas, que pueden ser comparadas fácilmente con conciertos de rock o espectáculos de fé. Cuando se mira de cerca la vida de Steve Jobs puede apreciarse el afán desmedido, la dedicación total y el compromiso para transformar su visión interna en algo que toque a millones de personas. La avalancha de exitosos productos que salen de Cupertino nacen primero en la mente de Steve, y para mí, ese es el último acto metafísico.

Al principio de esta entrada mencioné la nota funesta con la que la salida de Steve jobs fué recibida. Pienso que en parte tiene que ver con el sentimiento de miedo que causa pensar en la salud de Steve Jobs. El ha presentado casi todos los últimos lanzamientos de los productos de Apple, y su estado de ánimo es inmejorable, pero es claro como su apariencia física se ve progresivamente más deteriorada. La salida de Apple pareciera la antesala de lo innevitable.

Y es que va a ser muy dificil que Apple siga siendo la misma empresa sin Steve Jobs, creo que su toque era esencial, no sólo por su imágen icónica, sino porque en las organizaciones con miles de empleados, es dificil lograr el grado de cohesión que Steve Jobs alcanzó a darle a Apple. Tim Cook podrá ser un genió de la logística, pero al final del día, los productos de Apple poseían la grandeza de Steve.

[1] Y hubo al menos una vez dónde estas obras tuvieron la firma de sus artistas ( Incluída la Andy Hertzfeld, que este año diseñó los círculos de Google Plus ).

[2] Uno de los grandes ídolos de Steve Jobs es el francés Gustave Eiffel, el lejendario arquitecto de la torre que lleva su nombre.

La ingeniería aeroespacial es el pináculo de las ingenierías. Ninguna otra ingeniería tienen que lidiar con variables tan complejas o ser probada bajo condiciones tan extremas. Podría decirse que para que un país pueda graduarse como potencia mundial debe crear primero artefactos que pueda lanzar (exitosamente) al espacio. Para el que desarrolla software la complejidad y las condiciones extremas también son algo familiar, y quizás esta es la razón por la cual las leyes en diseño de naves espaciales, 40 leyes promulgadas por el profesor Dave Akin , han tenido tanto eco en nuestra comunidad.

Para esta entrada de mi blog me he tomado la libertad de traducir estas leyes al español y al contexto del desarrollo de software. Abajo encontrarán la misma lista, con sólo algunas leyes ausentes, clasificadas por temas y acompañadas del número de la ley en su fuente original. También he resaltado ( con una estrella ) las leyes con las que más me identifico. Me encantaría conocer sus opiniones, tanto si las leyes son de su gusto, como si no. Disfruten!

Métricas

• La ingeniería de software es hecha con métricas. Análisis sin métricas son sólo opiniones (#1)
• Si tiene dudas, estime. En una emergencia, adivine. Pero recuerde limpiar el desorden cuando aparezcan las métricas reales.(#10)
• (Ley Tiesenhausen del costeo de proyectos) Para obtener el costo estimado preciso del proyecto, multiplique el tiempo estimado inicial por PI y corra el punto decimal del valor resultante un espacio a la derecha.(#29)
• (Ley de Ranger) Nadie da algo por nada. (#28)

Calidad

• El diseño de un sistema perfecto requiere un esfuerzo infinito. Por ello es conveniente diseñarlos para que los usuarios los utilicen aún cuando sepamos que el código se encuentra no-probado/incompleto/no-documentado. (#2)
• Sus mejores análisis/diseños/programas resultarán inevitablemente inútiles en el producto final. Aprenda a vivir con con las decepciones. (#4)
• En la naturaleza, el óptimo siempre es un punto intermedio. Desconfíe de las opiniones que afirman que el óptimo es un punto extremo. (#8)
• El diseño se basa en requisitos. No hay justificación para diseñar algo “un poco mejor” que lo indicado por los requisitos.(#13)
• (Ley de Edison) Lo “mejor” es enemigo de lo “bueno” (#14)
• Las prácticas pasadas son muy útiles para aterrizar las ideas. Aterrizar demasiado las ideas sin embargo puede arruinar un buen diseño.(#18)
• (Ley de Montemerlo) No haga estupideces.(#26)
• (Ley Saint-Exupery del diseño) Un diseñador sabe que ha alcanzado la perfección no cuando no hay nada más por agregar, sino cuando no quede nada más por eliminar. (#35)
• Un programador promedio escribe código elegante. Un buen programador hace algoritmos eficientes. Un gran programador hace algoritmos efectivos. (#36)
• La ingeniería de software es una disciplina implacable. Si ud. hace mala ingeniería, alguien morirá ( Y no se aminora la culpa si el análisis/diseño/programación había quedado bien hecho ) ( OK, En software no siempre es así, pero deberíamos considerarlo ) (#40)

Iteraciones

• El diseño es un proceso iterativo. El número necesario de iteraciones es uno más que el número de iteraciones que ud. ha hecho. Esto es cierto en cualquier momento dado del proyecto.(#3)
• (Ley Mo del desarrollo iterativo) Ud. no puede llegar a la Luna saltando sucesivamente entre árboles más altos. (#31)

Incertidumbre

• El hecho que el cliente no le halla dado toda la información nunca es una buena excusa para no comenzar la fase de análisis. (#9)
• Un problema nunca es resuelto por un único algoritmo. Sin embargo, hay muchos algoritmos que no resuelven el problema.(#12)
• Los posibilidades están en contra de que ud. sea inmensamente más listo que cualquier otro en su campo. Si ud. logra crear un algoritmo para quebrar el sistema de criptografía pública de Internet en tiempo polinomial, quizás halla resuelto el problema P vs. NP, pero las probabilidades están a favor de que simplemente halla metido la pata. (#19)
• (Ley Atkins de las demostraciones ) Cuando la demostración funcione a la perfección, no habrá cliente que lo presencie.(#32)

GUI/UX

• (Ley de Shea) La interfaz de usuario da buenas oportunidades de mejora. También puede ser la causa de los descalabros más grandes.(#15)
• Un sistema mal diseñado pero con una buena interfaz de usuario fallará eventualmente. Un buen sistema con una interfaz de usuario pobre fallará de inmediato. (#20)
• (Ley Tiesenhausen del diseño en la ingeniería) Si ud. desea generar el mayor impacto posible como ingeniero, aprenda los principios universales del diseño y como manejar Photoshop, de esta manera nunca estará limitado por la apariencia del prototipo que el diseñador gráfico creo al principio del proyecto.(#30)

Planeación

• Al inicio de un proyecto, la persona quien más desea ser el líder es la que menos está capacitada para hacerlo. (#7)
• Algunas veces, la manera más rápida de terminar un proyecto, es desechar todo el código y empezar de nuevo.(#11)
• Su cronograma parecerá una completa obra de ficción justo hasta el momento que su cliente lo despide por no cumplirlo. (#23)
• (Ley de Varsi) Los cronogramas sólo se mueven en una dirección. (#27)
• (Ley Patton de la planeación ) Un buen plan ejecutado enérgicamente ahora es mejor que un plan perfecto ejecutado la semana entrante.(#33)
• (Ley Roosevelt de la planeación ) Haga lo que pueda, en donde está, con le que tiene a mano.(#34)
• (Ley de Henshaw) Un aspecto clave en el éxito de un proyecto es predefinir claros canales de culpabilidad.(#37)
• Las capacidades de los programadores (y no las necesidades del cliente) conducen los requisitos, sin importar lo que digan los textos de ingeniería de software.(#38)
• Los tres aspectos claves para mantener un proyecto de software costeable y a tiempo:
  1. No planee nuevas versiones.
  2. No planee nuevas versiones.
  3. Haga lo que haga, no decida desarrollar nuevas versiones.(#39)

Otras

• (Ley de Larrabee) La mitad de lo que ud. escucha en el aula de clase es basura. La educación es descubrir cual mitad es esa. (#21)
• Si duda, documente. (Los requisitos de documentación alcanzarán su máximo al final de un proyecto) (#22)

La primera pieza de Software que me gustó fue CorelDRAW 3.0. Era el programa que más utilizaba en aquellos tiempos de Windows 3.1. Aún hoy aquel CorelDRAW me sigue pareciendo una de las aplicaciones mejor concebidas. Cuando la empecé a usar pude terminar de entender todos los elementos que la interfaz gráfica de Windows me ofrecía: sus menús, botones, tipos de letra TrueType y hasta el ratón. Todas esas piezas encajaban perfectamente y en armonía para cumplir una sóla misión: hacer gráficas. Nada sobraba.

Muchos años y programas después, me encuentro con otro programa que me parece alucinante. Esta vez al programa se le une el dispositivo en el que corre, el iPad. Los dos son inseparables. Y la razón por la cual este dúo me trajo recuerdos de CorelDRAW es que fué sólo hasta que usé el Flipboard que pude terminar de entender lo que Steve Jobs pretendía con el iPad, quiźas uno de los dispositivos más polémicos y subvalorados de Apple en su lanzamiento.

A pesar que sus especificaciones técnicas dejaban entrever un dispositivo computacionalmente capaz, el iPad dejó boquiabiertos a todos aquellos que descubrieron que no podían realizar en él ni siquiera las tareas más básicas que un simple Netbook les permitía. Su teclado no es lo suficientemente cómodo para editar documentos, y de poderse, éstos no pueden copiarse en una memoria USB. Tampoco tiene cámara, así que no es posible realizar videoconferencias. A muchos les pareció la versión eunuca de un computador portátil. Algunos todavía conservan esa impresión.

Las ventaja más obvias del iPad son su formato y la durabilidad de su batería. Es como cargar un cuaderno de notas (aunque algo más pesado) y puede llevarse de viaje sin preocuparse demasiado de mantener un cargador a la mano. Pero nadie va a pagar US$ 500 por eso. Es más, los consumidores están comprando el iPad no por lo que les dá, sino por lo que les quita: las distracciones. Cuando me siento a usar el iPad toda mi atención se centra en una sóla actividad, y esa actividad es consumir información. El iPad es un dispositivo optimizado para consumir información, no producirla. Todo lo que estorbe en esta actividad sobra, y Steve Jobs se dió cuenta de ello.

Lo que más me recuerda el espíritu del iPad es un libro, y yo no quiero que me molesten cuando leo un libro. Pero qué tal algo mejor que un libro?. Qué tal un libro con contenidos dinámicos?. Es decir como una revista. Pero una revista que nunca envejezca (aunque esto ponga en aprietos las peluquerías y los consultorios médicos), una revista que se alimente con lo que los usuarios de las redes sociales consideren relevante. Con lo que mis amigos consideren relevante. En el Flipboard yo leo a la Revista Semana y a The Economist sin tener que pagar un peso. Flipboard convierte cualquier fuente de información que fluya a través de Twitter o las listas RSS de Google Reader en encabezados similares a los de una revista. Algunas veces falla, pero sus aciertos hacen que todo el producto valga la pena.

Flipboard fué seleccionada como la aplicación del año por Apple por la misma razón que el CorelDRAW llevó a Windows al escritorio de muchos hogares y oficinas; Flipboard hizo que el iPad valiera la pena. Todo el empeño que puso Steve Job en crear un dispositivo restringido sólo al consumo de información, su formato, su batería, su interfaz táctil, su hermosa pantalla, todas esas características son parte del ADN de Flipboard. Gracias a Flipboard yo no pienso en trabajo cuando veo mi iPad, eso sólo lo convierte, de lejos, en el mejor producto tecnológico del 2010.