«Developer Survey»: recopilando la opinión de los desarrolladores

Imagina la escena: vas conduciendo por una carretera infinita a máxima velocidad. El indicador de la gasolina lleva desde hace varios kilómetros atrás avisando, pero no puedes parar a repostar. Tienes que llegar cuanto antes a tu destino y no hay tiempo para otro asunto. El final: tarde o temprano te quedarás sin combustible, el motor se romperá y tendrás que abandonar ese coche. 

Esta analogía podría servir para ilustrar la apisonadora del día a día de muchas startups, solo centradas en sacar nuevas funcionalidades a cualquier coste. Sin dedicar tiempo y pararse a preguntar a sus desarrolladores de software lo que necesitan para trabajar más eficientemente o qué partes técnicamente les producen mayores de dolores de cabeza.

Sigue leyendo

Charla para IronHack sobre el «Mobile Backend» de la app de idealista

Hace unos días hicimos una pequeña introducción en formato charla en el curso de desarrollo de aplicaciones iOS de Ironhack sobre el desarrollo de la aplicación móvil de idealista.

Una de las partes fundamentales de una aplicación es el backend, así que con unas breves pinceladas explicamos el mobile backend actual de idealista (Android e iOS) (fueron tan sólo 20 minutos más preguntas). Por una parte hablamos de nuestra API usada por las aplicaciones móviles y, por otra, sobre el sistema de notificaciones push que creamos adhoc para enviar a aplicaciones iOS y Android. El objetivo era dar a conocer la problemática que representa para un desarrollador de móviles toda esa parte «oscura» del backend de su app.

Sigue leyendo

Los errores técnicos de BiciMad: fallos de la plataforma y mal planteamiento sin API pública

API-BICIMAD

Según BiciMad, el éxito de su lanzamiento en el primer día tumbó sus sistemas informáticos. ¿En serio que 1.000 usuarios no concurrentes a lo largo de un día fueron capaces de hacerlo? Recordemos que es un sistema que debería estar planteado para dar servicio a 123 estaciones con 1.580 bicicletas de forma ininterrumpida 24 horas.

Fallos técnicos y mal planteamiento de la plataforma

Hay que distinguir el apelativo de fallos informáticos de un mal planteamiento técnico de la plataforma. En el primero podemos asumir que durante un tiempo tengan problemas con la carga de los servidores, fallos de conectividad o algun bug descubierto. Pero después de ver los errores, agujeros de seguridad y la pobre implementación del sistema informático de BiciMad está claro que no se hizo un análisis de lo que suponía el despliegue técnico de este proyecto en el que la tecnología forma un papel fundamental.Parece que el estándar de calidad de la administración es mucho más bajo de lo que podríamos pensar.

Sigue leyendo

Consolidar una API como producto

API-we-trust

¿Cómo suele crearse una API? Hace un par de años con el auge de las apps móviles muchas empresas se lanzaban a crear una API con el simple propósito de comunicar y obtener datos entre la web y las aplicaciones móviles (iPhone y Android). Esta API era muy básica, creada a partir de una serie de objetos sencillos con información limitada de lo que se veía en la web (el único producto para los consumers durante esos años).

Nuestro primitivo servicio de acceso API, pensado para un reducido número de dispositivos, crece y es la base de esas aplicaciones móviles, por lo tanto, tiene que evolucionar. Pasa durante un tiempo por un lavado de cara, una refactorización y algún que otro versionados. Cada vez va incorporando más funcionalidades, es la base central sobre la que se sustenta el desarrollo móvil de la compañía. Sin ella difícilmente se puede crear una aplicación integrada al ecosistema de negocio de la compañía.

La dependencia de las apps móviles hacia la API es tal que, que empieza a evolucionar a conceptos más cercanos al backend específico de las aplicaciones, como el acuñado recientemente MBaaS que reflejan la necesidad de servicios en la nube que proveen notificaciones push, almacenamiento de datos, gestión de sesiones y autenticación de usuarios.

Sigue leyendo

Los animales de los libros de O’Reilly

Portadas libros O'Reilly

Me traen entrañables recuerdos esos animales en las portadas de los libros de O’Reilly. He sido mucho de libros: comprarme un libro y devorarlo para aprender algún lenguaje, tecnología, etc… o algunas veces sólo por tenerlo, debo reconocerlo. De los que tengo, y son unos cuantos de O’Reilly, siempre me han acompañado algunos de ellos reposados en la mesa o en la pila de libros.

¿Pero de dónde vienen esos animales? ¿Qué tienen que ver con Javascript, Perl, Apache, Tomcat, etc…? Pues bien, tenía pendiente un post en evernote hablando de los orígenes de esas portadas de O’Reilly que he publicado en Genbeta Dev.

A mediados de los años ochenta, Edie Freedman, una de las primeras diseñadores de las portadas de los libros de O’Reilly, presentó una curiosa idea que serviría para diferenciar a los libros de la editorial del resto en las estanterías. A partir de una láminas de animales empezó a crear los primeros bocetos. Una relación entre el sentimiento de una dibujante de la portada, que poco sabía de lo que se hablaba en el libro, las características del animal y el sonido de los títulos o términos empleados cuyo sonido al pronunciarlos le recordaba a la tecnología.

Podéis ver un listado de los animales de todas las portadas usadas en los libros de O’Reilly.

Hace unos años se creó un herramienta para generar portadas curiosas con el mismo formato, una pena que parece que ya no está disponible. ¿alguien lo recupera?