El buen desarrollador de software

Strip-Faire-payer-la-formation-650-finalenglish-1 (1)

Llevo un tiempo pensando en lo que es para mí ser un buen desarrollador de software y los puntos que nos pueden hacer ser justo lo contrario.

Desde hace bastantes años trabajo y comparto proyectos con un número variado de profesionales, bien personas o agencias a las que delego trabajo o bien que me lo delegan ellos a mí. Este texto se basa en esta experiencia.

Por otro lado debo decir que, algunas de las cosas “malas” que destaco en este texto no solo las he visto en otros profesionales, sino que también las he visto en mí mismo cuando empezaba bastantes años atrás o al cometer errores a lo largo de mi carrera profesional.

Por lo tanto es una visión muy personal de nuestro mundo y no pretendo tener la razón absoluta. Los comentarios siempre se agradecen.

No tener una actitud de gilipollas

Somos unos privilegiados al dedicarnos a desarrollar software en estos momentos. Podemos asegurar que no hay paro en nuestro sector y que siendo inquietos, actualizándonos y currándonoslo un poco podemos trabajar desde prácticamente cualquier sitio del planeta (siempre que tengamos visado y conexión a Internet).

Es posible que en un futuro esto cambie y que mucho del trabajo o tipo de proyectos que estamos realizando en estos momentos se podrán sustituir por APIs o servicios cloud. Pero el presente es el que es y se puede vivir genial desarrollando software.

Pero este privilegio no nos da derecho a comportarnos como cretinos. Chantajeando a quien nos contrata o criticando en público a quien oferta porque en Londres cobrarías en triple y te irían a buscar a casa en un taxi de esos negros molones. Hablaré de este tema más en detalle más adelante en esta misma entrada.

Dominar el framework javascript de moda no te da derecho a ir por la vida con la actitud de un House desarrollador de software. House era un payaso pero al menos salvaba vidas (en la ficción).

Mejor un trabajador responsable que un ninja

Puedes cambiar el término “ninja” por lo que desees, incluidas siglas de certificaciones oficiales.

Al final de lo que se trata es de sacar trabajo adelante. Y de poco sirven las charlas que hayas dado, los tags que uses en Twitter o las pegatinas que tengas en tu Mac.

Tener capacidad de respuesta es algo muy valioso en un desarrollador para mí, mucho más importante que sus títulos o marca personal.

Es muy habitual la decepción que puedes llevarte al comprobar como una persona que es rockstar en Twitter u otros escenarios, desaparece en mitad de un proyecto para finalmente salir del mismo porque se ha visto saturado o simplemente no le gusta que se use una tecnología o herramienta X. Me parecen actitudes de chavales de catorce años. Sin ánimo de ofender a los chavales de catorce años.

Al final lo que se desea es tener en tu equipo gente con la que puedas contar. Puede que no controlen a un nivel brutal la última versión de Angular o hayan participado en un proyecto de gran tráfico o que hayan escrito libros sobre la última librería javascript de moda que dentro de dos años no utilizará nadie, pero es que la mayoría de las ocasiones tampoco hace falta.

Lo que sí hace falta son profesionales responsables que acaben el trabajo de forma correcta y sin tonterías.

Comunicación

La comunicación es otro valor clave.

A todos nos surgen imprevistos, nos equivocamos o puede que pase algo fuera de nuestro control que nos impida hacer nuestro trabajo. Comunicar cuanto antes cualquier imprevisto ayuda a poder resolver la situación, callarse siempre es una mala opción.

Lo mismo que si una frase o acto de otra persona en el equipo te sienta mal o no estás motivado por algún problema.

Personalmente valoro mucho quien sabe comunicarse cuando las cosas van mal o hay presión en un proyecto. El coste de comunicación es un precio muy alto que se puede pagar al trabajar con un equipo o una persona equivocados.

Saber comunicar correctamente tus ideas cuando trabajas en equipo, escribir bien y expresarte bien es una habilidad que en mi opinión nos hace mejores desarrolladores.

Esto me parece especialmente importante cuando se trabaja en remoto. Cuando no ves la cara del otro ni escuchar su voz, el texto lo es todo. Es crítico en estos contextos cuidar mucho cómo escribimos.

Comunicar también es escuchar.

Algunos podemos tener carácter, prejuicios por falta de perspectiva o simple cabezonería, somos humanos. Muchas veces incluso teniendo experiencia caemos en estas cosas. Y muchas veces, debatimos con ímpetu aun estando equivocados.

Creo que tanto si eres el que argumenta estando o no equivocado como si eres el receptor, debes escuchar lo que esa persona te está diciendo, sobre todo si tiene experiencia. Las lecciones más valiosas las aprendemos cuando estamos equivocados y cuando nos argumentan el por qué. Y son doblemente valiosas cuando el/la que nos alecciona tiene menos experiencia que nosotros.

Y aunque en ese momento no lo veamos, sin duda quedará en nuestra mente y será un recurso muy valioso cuando toque darse cuenta de nuestro error.

Pragmatismo VS curriculum oriented development

No es “sexy” (y madre mía con lo de “sexy” para hablar de frameworks y lenguajes…) desarrollar una API REST en php y mysql, teniendo Go, lenguajes como Erlang y OTP que existen desde los 80 pero que las hemos descubierto hace cuatro años o bases de datos como MongoDB que “escalan”, “son rápidas” (porque sí y ya está) y que las usan en esa empresa que tiene un “CEOfounder” de 24 años.

Estás desarrollando un producto y lo que importa es el valor. Entregar el máximo valor, con la calidad mínima necesaria consumiendo la menor cantidad de recursos de tiempo y dinero.

La tecnología es algo crítico pero no es lo más importante. Son nuestras herramientas, pero ya está. Nuestro recurso más valioso es la capacidad de crear con ellas usando nuestro criterio. El dominio de las mismas es importante, entrenar con ellas es importante, pero no tan importante como el entregar y entender lo que estamos desarrollando.

Creo que un desarrollador orientado a la herramienta no es un buen desarrollador, es mi opinión personal y mi opinión como cliente.

Por otro lado valoro también mucho el pragmatismo.

Está muy bien que la plataforma web tenga una arquitectura basada en servicios con una implementación de Inyección de dependencias muy currada y que también, se haya tenido en cuenta la separación de orígenes de datos para poder distribuir la carga entre varios frontales web, varios servidores de lectura y escritura a nivel de base de datos y las operaciones pesadas gestionadas por sistemas de colas asíncronas. Todo esto está muy bien. Pero al final si el proyecto es nuevo y va a tener un crecimiento natural, es posible que no se vaya a necesitar orquestar una arquitectura de ese tipo en seis máquinas o instancias virtuales en la nube de turno y puede que con un servidor en un hosting tradicional vayamos sobrados.

No necesitamos añadir coste al cliente de mantenimiento de sistemas o coste extra de servicios cloud porque a nosotros nos ponga cachondos tener una arquitectura de las que salen en blogs como High Scalability.

Y por último: el pasar de frameworks, ORMs y complicar el mantenimiento por trucos de rendimiento cuando no tienes este tipo de problemas, personalmente me parece condenar al proyecto a tener que reescribirse en un futuro por la cantidad de esfuerzo que puede suponer hacer cambios mínimos y el terror también de subirlos a producción.

Trabajando por cuenta ajena y las ofertas de trabajo

“El águila con talento esconde sus garras”

Muchas veces me quedo atónito al escuchar las experiencias que han tenido empresarios con su equipo técnico en ciudades como Madrid, Londres o San Francisco.

Cretinos sin ningún tipo de escrúpulos que hacen chantaje a sus empleadores amenazando con irse de la empresa porque han recibido en el último mes un montón de peticiones de amistad de recluiters en linkedin.

Chantajes que van desde imponer el uso de una tecnología/frameworks “o se van”, irse sin avisar ni decir nada una tarde de la oficina porque tenían un partido de fútbol o simplemente porque había un evento en la oficina molona de turno de Madrid.

La verdad me sorprende el aguante de sus jefes por miedo a perder “talento” o capacidad de ejecución, reteniendo un equipo tóxico a ese nivel.

“Que cierre su empresa si no sabe llevarla” He llegado a leer esto cuando un empleador anuncia una oferta de trabajo por debajo de los 32000 euros anuales a un desarrollador, sin entrar a valorar su nivel.

“En Londres me pagarían X” Pues ve a Londres y disfruta de este sueldo. Es posible que al irte, la gente que contrata a programadores en este país se de cuenta del vacío que has dejado, la gente que organiza eventos deje de hacerlo porque ya no merece la pena y el mercado del desarrollo y de Internet en España se colapse. Que se jodan, por no valorar el talento que alguien que va a comisión ha visto en tus aptitudes de Linkedin.

Pero desde luego yo no quiero trabajar con gente así. De hecho no quiero personas así a mi lado.

Montar un negocio se ha convertido en un espectáculo en el que cualquiera puede opinar sin vivir la experiencia de hacerlo. Pero la realidad es que los ataques a empresarios que están empezando y ofrecen sueldos humildes, no mejora el mercado.

Me parece muy respetable buscar el mayor sueldo posible, pero la mayoría de los lugares en los que te van a ofrecer trabajar no van a poder competir con otras empresas en eso. Y es respetable que no quieras trabajar por menos de lo que vales o creas que vales, pero montar un espectáculo en Twitter o en foros me parece bastante infantil y tóxico.

Al mundo real le dan igual las pataletas y la gente realmente competente habla poco y hace más.

Los programadores que realmente pueden elegir dónde trabajar lo hacen sin montar espectáculos. Si no les interesa lo que se oferta, se van a otro sitio sin montar un drama.

Todo lo demás

Y en último lugar es importante todo lo demás. Escribir buen software, mejorar como desarrollador día a día, mejorar nuestro nivel de inglés para comunicarnos y aprender de otros desarrolladores, aplicar calidad y entrega continua, autoformarnos en nuevas herramientas para que con criterio, las podamos utilizar cuando sea el momento y contexto adecuado.

Personalmente, algo que últimamente me parece importante es volver a repasar conceptos y mejorar mi nivel de matemáticas. Al margen de todo el postureo relacionado con algoritmos (otra moda-pesadilla), mejorar en esto viene muy bien para comprender cómo funcionan algunos sistemas y tras años de experiencia programando se ven de otra forma los conceptos que cuando los estudiábamos no los veíamos para nada útiles. También es útil para delegar trabajo en matemáticos que se encarguen de idear los algoritmos que implementemos en nuestras aplicaciones o software.

Considero también importante dominar otros campos y tener hobbies. Nos dan perspectiva, conocemos a gente distinta y salimos de nuestra zona de confort.

De hecho veo importante conocer otras personas muy distintas del mundo del software, creo que nos pueden dar puntos de vista e inspiración que nos hacen mejores desarrolladores aunque no seamos plenamente conscientes de ello.

Lo que vi en el Build 2015 y el nuevo Microsoft

Hace casi un mes estuve en San Francisco y gracias a Microsoft, acudí a su evento más importante para desarrolladores, el Build.

11193070_503361936494064_1696561452_n

Lo primero que me impactó de este evento antes de ir es que costando la entrada 2000$ se agotasen el mismo día. Más de 5000 desarrolladores de nivel internacional acudieron al evento. Siendo español y organizador de eventos técnicos, esto me llama poderosamente la atención ya que en España hay poca costumbre de asumir inversiones de mucha más baja cuantía independientemente de la calidad del evento al que queramos acudir.

Lo segundo que me impactó fue Microsoft. Bueno realmente no Microsoft, sino la comunidad y todo el cambio que se está dando en torno a sus productos y que dista muchísimo con lo que conocí cuando trabajaba administrando sistemas basados en Windows Server y Exchange 2003, antes de dedicarme al mundo de producto y desarrollo de soluciones de software con tecnologías open source.

Os voy a contar un resumen de lo que vi allí esos días y algunas reflexiones personales desde mi punto de vista.

El día antes de comenzar el evento, tras acreditarnos, acudimos a una fiesta privada organizada por la gente de Xamarin y allí nos encontramos a gente muy crack del desarrollo mobile como Josue Yeray. En la fiesta había un catering de calidad, barra libre y una concentración de talento increíble.

Para el que no lo sepa, Xamarin es una solución para desarrollar de forma nativa (realmente nativa) aplicaciones para Android, iOS, Mac, Windows Phone, Windows y wearables que usen estas tecnologías. Es un proyecto que tiene detrás a la gente del proyecto open source Mono y al creador de Gnome, Miguel de Icaza.

Para desarrollar en Xamarin, debes tener conocimientos de Android e iOS así como de C#, lenguaje de programación estándar de Microsoft.

No sorprende entonces que en un evento de Xamarin no encuentres sólo a gente pro-Microsoft, sino también a desarrolladores de nivel internacional enfocados en Android e iOS.

Al día siguiente acudimos al evento a primera hora para asistir a la primera keynote del evento.

Lo primero que me sorprendió y que fue recurrente en la segunda keynote que tuvo lugar al día siguiente, fue la presentación de aplicaciones profesionales como StaffPad para componer música. Esta aplicación fue creada por el músico David William Hearn, quien escribió una pieza en directo durante la keynote.

Más tarde, la gente de Docker comentó su visión y estrategia de integración con el servicio de cloud Azure y se hizo una demo con Visual Studio y un plugin de docker para gestionar contenedores Linux desde el IDE.

La impresión 3D también tuvo su hueco. Para presentar nuevas tecnologías en Web, crearon una plataforma y caso de éxito ficticio llamado Fabrikam. Me sorprendió cómo tenían desarrollador a nivel de web responsive todos los flujos de diseño de las piezas en 3D y su posterior pedido a través de la web, con la gestión de negocio. Esta demo seguramente se vea en más presentaciones de Microsoft y la verdad si estás en el mundo de impresión 3D, deberías echar un ojo.

Algo que era sutil pero no dejaba de sorprender es que los ponentes hacían todas las demos de la keynote en teléfonos Android e iPhone junto a tablets iPad, no sólo con dispositivos con Windows Phone o Windows.

Pero la sorpresa de verdad fue sin duda cuando se presentó Visual Studio Code. Un editor de código que Microsoft publicó ese mismo día para desarrollar bajo Linux, Mac y Windows.

Posteriormente acudí a una charla donde se presentaron features avanzadas de este editor, especialmente relacionadas con el trabajo con c#, asp.net y javascript. En este último se han volcado en dar muy buen soporte en general.

Es un editor que da lo que puede dar Atom de Github, pero se ha añadido buen soporte de intellisense y debug, sobre todo ahora mismo para Javascript y C#. Se rumorea que podría acabar siendo OpenSource, pero no está confirmado aún.

Yo he sustituido Brackets para editar archivos simples de php. Aunque se me queda corto para programar aplicaciones php y no me sustituye a phpStorm, para desarrolladores Javascript o Asp.net bajo entornos linux o mac creo que puede ser una opción más que interesante.

También fue increíble cuando se anunció que Objective C se incluía dentro del catalogo de lenguajes .net. Se mostraron juegos de iOS programados en este lenguaje, corriendo nativamente en Windows10 e integrados con XBox.

Estos dos anuncios ya dejaron ver que Microsoft estaba apostando por un cambio de visión en la que en lugar de cerrarse, parecía que se abría a otras plataformas.

Otro anuncio ya esperado fue el de Microsoft Edge, que sustituirá a Internet Explorer como navegador.

La keynote se cerró con la presentación de las gafas de visión holográfica HoloLens, lo más alucinante y esperado del evento. Hubo desarrolladores que fueron al evento sólo por este anuncio.

 

Las aplicaciones y objetos holográficos de ese mundo de realidad aumentada se programan como si fuesen juegos pero se puede intuir que las aplicaciones para el mundo de los negocios, I+D, ingeniería y medicina no tienen prácticamente límites.

Algunos afortunados tuvieron la oportunidad de probarlas y recibir formación para desarrollar software para ellas, uno de ellos fue Josue Yeray y escribió un resumen sobre las mismas en su blog.

El resto del evento estuvo cargado de charlas sobre productos más en detalle.

El segundo día empezó con la segunda keynote del evento. Antes de empezar, un Deejay amenizó el ambiente con un set en directo haciendo uso de software bajo Windows10. De hecho la keynote empezó también con las experiencias de Muzik y Propellerhead.

Yo soy muy fan de Propellerhead, a finales de los 90 me flipaba componer con su Rebirth338 y no me esperaba verles presentar en ese evento.

Para mí fue una sorpresa la importancia que Microsoft le está dando a la producción musical.

Otra cosa que me llamó la atención fue el trabajo que están haciendo para emular la escritura con tinta en pantallas táctiles. Esto puede dar mucho juego para software relacionado con diseño o dibujo.

Otra noticia que dejó en silencio a toda la sala fue el proyecto Astoria. Lo que promete este proyecto es la posibilidad de ejecutar aplicaciones en Windows escritas en código Android nativo.

Este anuncio ha provocado polémica y también escepticismo en la comunidad .net de desarrollo Mobile, pero sin duda alguna es otra señal de que Microsoft ha cambiado totalmente su estrategia y forma de ver las cosas.

Hubo más cosas interesantes como el SDK para Microsoft Band (es una pena que este producto no haya llegado a España) y las posibilidades de extensión de Office e integraciones del mismo con Android/iOS.

Además de Cortana, el “siri” de Microsoft, se habló del proyecto Continuum para Windows10. Básicamente han logrado que los dispositivos Windows Phone se integren totalmente con Windows10 de tal forma que las aplicaciones con las que trabajas en el móvil, al conectar el terminal al pc, puedas seguir utilizándolas con los recursos y pantalla del equipo de escritorio. Esto sin interrumpir la experiencia de uso.

En la keynote también se mostró una demo de una aplicación web que se convirtió sin querer en trending topic y que calculaba la edad de una persona en base a su foto de avatar. La demo se usó para mostrar las APIs de análisis y monitorización disponibles en servicios Azure.

Esta última keynote finalizó con la temática Big Data y su aplicación en el mundo de la salud.

Durante el resto del evento acudí a charlas sobre novedades en ASP.net, servicios de búsqueda de Azure (que están basados en Elastic Search) y una charla de negocio sobre Office 365 Online.

El día final no hubo keynote pero sí charlas tecnológicas muy interesantes, en especial la de Azure Media Services, en la que Ming Feiy dio un repaso sobre todas las nuevas características y opciones para gestionar el reto de servir vídeo desde servicios cloud.

Conclusiones

Microsoft no está cambiando, ha cambiado ya y dicho cambio es tan real como evidente.

Mis opciones tecnológicas principales actualmente son Symfony2 para desarrollar aplicaciones web bajo linux y Xamarin para desarrollar aplicaciones nativas en iOS/Android. Por ello, mi interés principal de acudir al evento era el descubrir opciones tanto tecnológicas como de negocio, para desarrollar proyectos open source y servicios de Internet con herramientas Microsoft como c# y Azure que no me atasen a nada.

Me volví del evento con ganas de investigar las opciones que vi en allí y es algo que ya he empezado a hacer y muy en serio.

Por un lado hay herramientas muy maduras a nivel de desarrollo que es interesante tenerlas disponibles ahora de forma abierta bajo entornos linux. Por otro, hay APIs y herramientas cloud de Azure que pueden ahorrar mucho dinero e incluso hacer viables proyectos que antes requerirían una inversión de desarrollo e infraestructura importante.

Poco a poco, Microsoft se está abriendo y facilitando la vida a los desarrolladores para integrarse con otras plataformas como Android y Apple. Algo impensable hace unos años de Microsoft y algo impensable actualmente de empresas como Apple.

Me queda agradecer a la gente de Microsoft que me acompañó en el evento, Jose y Alex. También fue un placer conocer a Pablo Iglesias y Jorge del Casar.

 

Desarrollo de aplicaciones móviles multiplataforma

Con este artículo pretendo recoger mi punto de vista, resumiendo lo que he comentado en mis charlas sobre estas temáticas y también las conclusiones tras invertir casi dos años en investigar sobre cómo afrontar este tipo de desarrollos y proyectos.

Desde hace ya unos años, cuando desarrollamos proyectos web de gran envergadura como plataformas SaaS (software como servicio), marketplaces, redes sociales o portales de otro tipo, debemos tener en cuenta la experiencia del usuario que accede a estos servicios web desde el móvil.

Desde el punto de vista del cliente, las preocupaciones u objetivos que más destacan en su feedback suelen ser estos tres:

  • El servicio debe ser accesible desde el móvil
  • Nuestro servicio debe poder ser consumido desde un canal móvil
  • Nuestro servicio debe tener una buena experiencia desde el móvil

Hasta ahora, los desarrolladores web contábamos con la ventaja de poder desarrollar nuestra plataforma y mantenerla de forma centralizada en nuestros servidores, preocupándonos únicamente en la parte frontal de los detalles o soportes de diferentes navegadores.

Habíamos huido del trabajo que suponía el mantener y dar soporte a instalaciones de nuestro software en distintos entornos o sistemas operativos que controlaba el cliente. Esta sensación que creíamos olvidada, ha retornado con la revolución de las aplicaciones móviles que suponen una oportunidad para los negocios que construimos: la oportunidad de estar en el bolsillo del cliente vaya donde vaya.

Los usuarios pueden acceder a nuestro servicio mientras van en el metro o consumen los últimos minutos del día antes de dormir.

Sin embargo, aprovechar esta oportunidad, aumenta el coste del desarrollo y de su posterior mantenimiento ya que supone desarrollar una aplicación para cada uno de los sistemas implantados en los teléfonos disponibles, teniendo en cuenta versiones del sistema y la experiencia de uso.

Por lo tanto, un desarrollador web o un equipo de desarrollo web tiene que tener en cuenta:

Las cosas que no son programación

Aunque un desarrollador delegue la parte de definición del producto o el diseño de la interfaz, es imperativo ser consciente de que una aplicación móvil se utiliza de forma distinta a un sitio web y la arquitectura de información junto a la navegación deben cumplir las expectativas de un usuario.

La idea es que no se trata de que nuestra aplicación se “parezca” a una aplicación móvil sino de que lo sea y se comporte como tal.

Al margen del diseño, importan cosas como la estrategia de notificaciones, la cantidad de información a mostrar o pedir, el comportamiento táctil, las reducción de features a ofrecer en comparación a la plataforma web y sobre todo, las integraciones con el dispositivo móvil y las implicaciones del hacerlo (consumo de batería, tipo de conexiones a hardware externo etc.)

Lo que sí es programación

Y en lo referente a la programación, aquí debemos tomar decisiones importantes:

  • Si nuestra aplicación debe instalarse en el dispositivo o no
  • Si nuestra aplicación debe ser nativa o no
  • En el caso de que optemos por desarrollar en nativo, si utilizamos una solución multiplataforma o no
  • Si requerimos un acceso web
  • Si en la parte web de nuestro servicio tiene sentido ejecutar una aproximación responsive Mobile First o por el contrario ser Tablet First y crear una webapp

Voy a dar mi opinión sobre estos puntos comentando algunas de las herramientas que he probado empezando por el último punto.

Responsive sigue sin ser opcional pero el ‘mobile first’ es muy del 2011

A menos que tu servicio sea extremadamente simple, atacar una estrategia teniendo en cuenta la adaptación del diseño en la resolución móvil bajo mi punto de vista puede aportar mayor coste de desarrollo, diseño y mantenimiento sin llegar a cumplir las expectativas del usuario.

Hay excepciones, como los sitios web de contenido que no vayan a crecer en otros aspectos de negocio. Sin embargo, en una plataforma en la que tenemos mucha problemática de interacción, intentar llegar a la vista móvil a base de adaptar el diseño puede conllevar:

  • Aumentar el peso de la página. Normalmente la técnica principal a la hora de hacer responsive es ocultar o mostrar elementos del HTML en base a la resolución de la pantalla, por lo que si nuestra plataforma crece también crecerá la cantidad de código a servir que tiene implicaciones como el tiempo de carga del sitio web.
  • Aumentar la complejidad en el front. Si para evitar aumentar el peso, decidimos aplicar o crear soluciones de carga bajo demanda, estaremos aumentando la complejidad del código en el frontal que realmente no está aportando valor de negocio y encarece el mantenimiento.
  • Mezclar problemáticas de experiencia de usuario. En ambos casos, estamos mezclando dos experiencias de uso totalmente distintas e intentando resolverlas prácticamente con calzador en el peor de los casos o intentando “parecer una aplicación móvil” en el mejor de ellos.

En mi opinión, si la plataforma es grande y planea crecer en requisitos de interfaz ya no es opcional el crear un acceso móvil separado con su propia experiencia de usuario.

Crear una webapp mobile

Como he comentado anteriormente, cuando atacamos el problema de desarrollar una aplicación móvil, aunque sea basada en web, tenemos que aprender a enfocar el diseño del servicio de una forma totalmente distinta a como lo platearíamos para una solución web en otras resoluciones y sobre todo, si estamos hablando de pantallas no táctiles.

En algunos servicios como Facebook, Badoo o Soundcloud tenemos buenos ejemplos de webapps.

IMG_0645Aunque el desarrollo sea web, no nos libramos de comprender cómo funciona cada plataforma, qué tipo de menús e interacciones el usuario espera encontrar y qué herramientas tiene el navegador para dotar a nuestra aplicación web de navegador de un comportamiento nativo.

Por ejemplo en iOS podemos hacer uso de los Smart Banners, las Safari notifications que permite enviar notificaciones al móvil aunque no este el navegador abierto o mejorar el rendimiento del scroll con un sencillo hack de CSS.

Para afrontar este tipo de desarrollos podemos optar por utilizar algún framework que nos facilite la tarea que ya implementan algunas de estos hacks a nivel de CSS.

Existen buenas opciones, algunas incluso adaptan el diseño dependiendo de la plataforma con la cual se acceda. Entre las más utilizadas están ionic, onsen uichocolat chip ui, ratchet y app.js.

Personalmente echo en falta una opción que no implemente javascript y sea una solución potente a nivel de css y html compatible con navegadores que no tengan que ser los más modernos.

Crear una aplicación instalable híbrida

Si queremos instalar nuestra aplicación en el dispositivo móvil la opción más socorrida por desarrolladores con experiencia web es la utilizar tecnologías como Phonegap/Cordova.

Básicamente estas aplicaciones se desarrollan de forma similar a una aplicación web móvil de navegador pero teniendo acceso a recursos del sistema como los sensores, cámara y almacenamiento.

Aunque parece la solución perfecta ya que el desarrollador puede aprovechar su experiencia en desarrollo web para ser productivo y crear aplicaciones con muy poca curva de aprendizaje inicial, disponemos de limitaciones con respecto a las aplicaciones nativas.

Al ser desarrolladas en HTML/CSS/Javascript es menos costoso también lograr implementar diseños con cierta complejidad o incluso imposibles de realizar en una aplicación nativa.

Simplificando mucho, una aplicación híbrida no es más una web en HTML y programación en javascript que funciona dentro de un navegador que el usuario no ve.

Sin embargo, si queremos realizar operaciones pesadas con el móvil (procesar video, componer música, mover mapas con gran cantidad de información) el rendimiento puede verse comprometido o incluso no poder hacerse con HTML o Javascript, teniendo que crear algún plugin nativo para cada una de las plataformas.

Normalmente, prácticamente el 90% de las aplicaciones que se desarrollan para un servicio online no requieren realizar tareas tan pesadas y una aplicación híbrida puede reducir mucho el coste de desarrollo.

Crear una aplicación instalable nativa

Esta es la opción que nos permite aprovechar todo el potencial del hardware del usuario.

Tenemos dos opciones cuando afrontamos un desarrollo de este tipo: desarrollar una aplicación por cada una de las plataformas (android, iOS, windows phone..) o utilizar una solución que nos quite el mayor trabajo posible de mantenimiento en cada una de ellas.

Hay que tener en cuenta que aunque desarrollemos para una plataforma en concreto podemos tener versiones que no tengan nada que ver. Por ejemplo en Android, una versión 3 difiere en tantas cosas de una versión 4 que podríamos tener que plantearnos tratar esas versiones como dos plataformas distintas y dos apps distintas. Es un problema que no afecta sólo a aplicaciones nativas sino también a webapps híbridas o incluso de navegador.

Si optamos por una solución que nos permita compartir código entre plataformas, las opciones más visibles en la actualidad son Appcelerator Titanium y Xamarin, la opción que más he investigado.

En mi caso descarté Titanium en favor de Xamarin porque todo el conocimiento que adquiría con la herramienta me ataba a ella. La forma de trabajar en Titanium no se parece ni se puede llevar al desarrollo de la plataforma en concreto.

Esto es especialmente importante en la parte de las vistas ya que sin lugar a dudas, la implementación del diseño es la parte más costosa en un desarrollo móvil nativo. En Xamarin puedes copiar y pegar todo el trabajo realizado en las vistas de una aplicación Android a una aplicación Xamarin.Android y funciona sin tocar absolutamente nada. Esto para mí significa no perder ni dinero ni conocimiento en el caso de que la herramienta en un futuro cambie de rumbo o desaparezca.

Otro punto en contra de Titanium es que aunque el código del framework es nativo, el código de tu aplicación en javascript es interpretado, perdiendo rendimiento en comparación al desarrollo nativo de cada plataforma o el desarrollo con Xamarin.

Xamarin tiene muchas más ventajas adicionales, por ejemplo se comprometen a dar soporte en el mismo día de las nuevas funcionalidades que salgan en las actualizaciones de los sistemas operativos soportados. También disponen de un framework (Xamarin.Forms) para construir vistas convencionales con una sola base de código.

Aunque no todo es maravilloso ya que tanto el IDE Xamarin Studio y las extensiones para Visual Studio deben mejorar muchísimo todavía. Tampoco te libra de conocer las particularidades de cada plataforma pero sí que te evita tener que dominar lenguajes específicos permitiendo centrarte en c#

Aunque sea de pago, merece mucho la pena evaluar el desarrollo con esta herramienta, sobre todo si no quieres mantener desarrollos en tecnologías distintas o tener en tu equipo desarrolladores especializados en cada lenguaje concreto de cada plataforma.

Conclusión

El camino para desarrollar aplicaciones móviles viniendo del desarrollo web, que es naturalmente multiplataforma, no es para nada trivial.

No sólo requiere que tomemos decisiones en cuanto a herramientas a utilizar para crearlas sino también pensar en su posterior mantenimiento.

También debemos cambiar la forma en la que diseñamos nuestros servicios para tener en cuenta las expectativas de nuestros usuarios fuera de su portátil o equipo de sobremesa.