![\"soft\"](\"http:\/\/silice.biz\/wp-content\/uploads\/2014\/10\/soft.jpg\")
<\/p>\n<\/p>\n
1) La Web ya no es s\u00f3lo la Web del navegador, sino que ahora es un h\u00edbrido de HTML y apps. Las startups tienden bien a ignorar la web m\u00f3vil, bien a estar demasidado centradas en ellas. Hay algunos casos en los que se justifica que el modelo de negocio gravite alrededor del m\u00f3vil, Hailo, probablemente, ha sido una de las startups m\u00e1s llamativas en 2013, y est\u00e1 justificado. Pero en la mayor\u00eda de las ocasiones es m\u00e1s bien entre un 60\u219270% web cl\u00e1sica y un 30\u219240% m\u00f3vil. La movilidad afecta no s\u00f3lo a la tecnolog\u00eda base en si misma (que tiende hacia HTML5 y Open GL para evitar en la medida de lo posible desarrollar dos veces para iOS y Android) sino que tambi\u00e9n tiene mucho que ver con el marketing debido a que en los m\u00f3viles las app stores imperan sobre la b\u00fasqueda en Google para encontrar determinados usos a la tecnolog\u00eda. Varios frameworks se han ido popularizando para el desarrollo multiplataforma en m\u00f3viles: Corona SDK, Xamarian C#, Appcelerator Titanium, PhoneGap, MoSync o RhoMobile entre otros.<\/p>\n
Cuotas mercado m\u00f3viles 2013<\/p>\n
2) El inter\u00e9s por la mayor integraci\u00f3n de redes sociales en el negocio y en las aplicaciones va a continuar siendo muy fuerte. La moda es intentar identificar y agrupar a los consumidores por sus gustos en lugar de por su perfil sociodemogr\u00e1fico. Adem\u00e1s, existen intentos de explotar la intencionalidad temporal de compra. Es decir, no s\u00f3lo saber qu\u00e9 gustos tiene un consumidor potencial sino en qu\u00e9 momento preciso del tiempo pasar\u00e1 de ser s\u00f3lo cliente potencial a estar realmente interesado en comprar algo a corto plazo. No es para nada raro que lo que m\u00e1s est\u00e9 proliferando sean las aplicaciones de marketing para Twitter estilo SocialBro. Twitter tiene aproximadamente la mitad de usuarios registrados que Facebook, 500 millones frente a 1.100 millones, y de esos 500 millones s\u00f3lo 200 est\u00e1n activos, sin embargo, en utilidad de promoci\u00f3n empresarial y de causas sociales, Twitter bien puede superar con creces a Facebook, y en seguida explicar\u00e9 mis motivos para afirmar tal cosa. Facebook, en teor\u00eda, permite identificar mucho m\u00e1s f\u00e1cilmente los gustos de la gente gracias a los Like. Esto en teor\u00eda, porque en la pr\u00e1ctica yo tengo tendencia a hacer Like sobre cosas que no me apasionan realmente (las voto porque me las sugieren los amigos) o Like sobre cosas que son muy dif\u00edcilmente monetizables, como el escote de la cantatriz de moda. Esta distorsi\u00f3n en los Like rebaja el grado de eficiencia publicitaria de Facebook m\u00e1s o menos hasta el de un medio sociodemogr\u00e1fico como la televisi\u00f3n, o incluso peor, puesto que Facebook parece ignorar mi perfil personal para ofrecerme s\u00f3lo recomendaciones basadas en hip\u00f3tesis err\u00f3neas sobre mis gustos. Por ahora, Facebook ignora la temporalidad y la estacionalidad, es incapaz, por ejemplo de tomar la fecha de cumplea\u00f1os de mis amigos y sus gustos para recomendarme con anticipaci\u00f3n algo que regalarles. Adem\u00e1s, Facebook tiene menos uso en el m\u00f3vil y es una red de redes de amigos en vez de una red abierta de todos con todos, como Twitter, por consiguiente la viralidad se propaga a menor velocidad en Facebook que en Twitter. Esta por otro lado LinkedIn, con 225 millones de usuarios, que, en mi opini\u00f3n, est\u00e1 sobrevalorada como canal de marketing. Pr\u00e1cticamente todos los geeks estamos en LinkedIn con un perfil bastante completo a modo de CV, pero, en mi experiencia, no es posible encontrar como usuarios registrados en LinkedIn a m\u00e1s del 7% del total de cualquier base de datos de clientes reales. Por \u00faltimo, los otros tres servicios que es imprescindible tener en cuenta en cualquier estrategia en redes sociales son YouTube, Instagram y Tumblr.<\/p>\n
3) Hay un buen batiburro de desarrollo en torno a JavaScript debido fundamentalmente a que lo que se dise\u00f1\u00f3 inicialmente como un lenguaje de scripting multiparadigma para programadores no profesionales se ha extendido a usos complejos tanto en el cliente como en el servidor. Hay decenas de frameworks: JQuery, Dojo y YUI como librer\u00edas dominantes, sistemas MVC como Angular.js o Backbone.js, e incluso reemplazamientos completos del lenguaje como CoffeScript o Dart. Adem\u00e1s del resucitado JavaScript de lado servidor con Node.js o el pol\u00edglota Vert.x.<\/p>\n
4) Los programadores Java estan evolucionando hacia Scala. Scala corre sobre la JVM y es muy compatible e interoperable con Java. Incorpora el paradigma de programaci\u00f3n funcional as\u00ed como extensiones al modelo de objetos de Java y la librer\u00eda Akka para programaci\u00f3n concurrente con Actores. Como programador, Scala se siente en la sintaxis compacta como si fuese Python, pero en realidad es un Java con esteroides. Las principales desventajas, a mi juicio, es que el lenguaje es complejo de aprender, su sintaxis puede llegar a ser muy poco intuitiva y est\u00e1 claro que los que lo dise\u00f1aron no estaban pensando en los desaf\u00edos espec\u00edficos que presenta el software para la web sino en solucionar otros problemas de programaci\u00f3n funcional, orientada a objeto y concurrente.<\/p>\n
5) Las startups de base tecnol\u00f3gica se implementar\u00e1n mayormente sobre Python o Ruby On Rails. No sabr\u00eda decir cual en mayor cantidad. Tampoco creo que entre esos dos entornos ninguno sea claramente mejor que el otro. Ya he escrito anteriormente una comparativa sobre plataformas de desarrollo web. Aqu\u00ed simplemente a\u00f1adir\u00e9 que basar la startup en Python o RoR es perfecto siempre y cuando se tenga en cuenta que no es conveniente empe\u00f1arse en programarlo absolutamente todo en Python o RoR. Por poner un ejemplo concreto, justo actualmente estoy programando un sistema de env\u00edo de emails para un cliente que necesita enviar 850.000 mensajes cada semana los cuales dif\u00edcilmente se pueden enviar y trazar eficientemente s\u00f3lo con Python o RoR y una base de datos MySQL.<\/p>\n
5) Se encuentra \u201cBig Data\u201d hasta en la sopa, y, en mi opini\u00f3n, no es para tanto. Todas las herramientas \u201cBig Data\u201d Open Source son funcionalmente bastante limitadas. Hadoop, en concreto es un sistema de almacenamiento distribuido atributo-valor (HBase) con una implementaci\u00f3n de MapReduce por encima y eso sirve s\u00f3lo para algunos usos muy concretos, ni siquiera proporciona \u00edndices secundarios de serie excepto por el mecanismo de los coprocesadores que no es en absoluto trivial de manejar. Cassandra escala muy bien y permite a\u00f1adir columnas din\u00e1micamente y de forma pr\u00e1cticamente ilimitada a un modelo de datos pero carece de ning\u00fan tipo de funcionalidad nativa para hacer una simple ordenaci\u00f3n de datos.<\/p>\n
5) La memoria es el nuevo almacenamiento. Comprar una m\u00e1quina con 1Tb de RAM ya no es nada descabelllado. Con tal cantidad de RAM se pueden poner muchas bases de datos directamente en memoria y usar el disco s\u00f3lo como backup. Cualqier nuevo dise\u00f1o de software de gesti\u00f3n de datos deber\u00eda tener en cuenta este hecho.<\/p>\n
6) Se ha producido un exceso de virtualizaci\u00f3n. En 2008 ya escrib\u00ed sobre el middleclouding. Ahora los llaman clouds h\u00edbridos. Las \u00e1reas problem\u00e1ticas con la virtualizaci\u00f3n son que: a) es demasiado f\u00e1cil clonar una m\u00e1quina virtual, y b) el software no tiene ning\u00fan conocimiento sobre el hardware sobre el que se ejecutar\u00e1. Es muy f\u00e1cil caer en una proliferaci\u00f3n descontrolada de m\u00e1quinas virtuales, y, cuando se desea optimizar al m\u00e1ximo el rendimiento, es necesario saber sobre qu\u00e9 hardware se est\u00e1 ejecutando la aplicaci\u00f3n. Yo personalmente para un SGBDR sigo prefiriendo un buen array de discos SCSI montados en RAID antes que cualquier soporte virtual porque s\u00e9 realmente lo que hay por debajo y por tanto el rendimiento real que se puede esperar del sistema en condiciones de m\u00e1xima carga. Usar Amazon S3 para olvidarse para siempre del almacenamiento de archivos esta muy bien para aplicaciones que son el yonki de los gigas, pero si se trata de garantizar tiempos m\u00e1ximos de respuesta a cada transacci\u00f3n, mi postura es que, a\u00fan siendo mucho m\u00e1s caro un cloud privado estilo Stackscale o Stackops o incluso servidores dedicados, son mejores opciones que los proveedores de servidores 100% virtuales donde nada se sabe acerca de la infraestructura f\u00edsica que soporta el servicio.<\/p>\n
7) Los programadores seguir\u00e1n ganando poder, quiz\u00e1 demasiado poder. En el mundo anglosaj\u00f3n la tendencia es hacia substituir al gerente de cuenta por un \u201clead developer\u201d. La idea es que los gerentes de cuenta son malos, porque se trata (es un suponer) de licenciados en empresariales con un master en marketing que no hacen otra cosa que liarla en los proyectos. Entonces aparece un programador iluminado y exclama: \u201c\u00a1Hey! Agile es la soluci\u00f3n para que los proyectos se cumplan en plazo, funcionalidad y rendimiento\u201d. Y, como nadie excepto el programador entiende realmente la tecnolog\u00eda pues todos aceptan esa nueva concepci\u00f3n del desarrollo programador-c\u00e9ntrica. La consecuencia de lo anterior es que se hacen desarrollos por el programador y para el programador en detrimento del usuario final representado por el (inexistente) gerente de cuenta. Creo que la cura para esta zona gris de Agile es una evoluci\u00f3n de Agile hacia una filosof\u00eda m\u00e1s usuario-c\u00e9ntrica y menos c\u00f3digo-c\u00e9ntrica. Algo en la l\u00ednea de Dragon Dreaming que le escuch\u00e9 por primera vez a \u00c1ngel Mar\u00eda y sobre la que escribir\u00e9 otro post en un futuro pr\u00f3ximo.<\/p>\n