FORCÉN

a.k.a. el turista accidental

Apps simples

Viernes
27.jun.14

Los tres gatos que me conocen me han oído repetir más de una vez un mini-mantra: una app hace una única cosa y la hace bien. Y cada vez hay menos excusas. La versión 8 de iOS incluye mecanismos de comunicación entre aplicaciones que superan la funcionalidad de los Intents en Android. Ya tiene las dos plataformas mayoritarias la capacidad de crear aplicaciones que ofrecen servicios a otras aplicaciones.

Así que se acabó el hacer apps llenas de poyaques y de “por si alguien la necesita”. De hacer apps monolíticas con distintas “secciones” que intentan cubrir todo lo que un usuario pueda necesitar de un tema concreto. Si tu idea de producto cubre distintos aspectos crea una app por cada uno de ellos. Y, si esos aspectos/secciones/negociados necesitan intecomunicarse hazlo, pero usando el sistema. No creando una única mega app.

El usuario que no necesita cargar con todo no se perderá o no dirá “buff, yo busco algo más simple”. El soporte y actualización de cada app será más simple. Sobre todo la actualización en cierta App Store que no se caracteriza por sus tiempos de reacción.

Apps simples, que hagan una única cosa y la hagan bien. No mareeis a los usuarios.

  • Comentarios desactivados
  • Monday Rants

    Lunes
    16.jun.14

    No me digas que el programa está haciendo algo raro. Es tu programa. No se ha escrito solo. Únicamente hace lo que le has pedido que haga. Que no siempre es lo que pretendes que haga. Tampoco me digas que no sabes lo que está pasando en un momento dado. Es tu obligación saber depurar tu propio código. De hecho, deberías ejecutarlo con el depurador al menos una vez. Es tu código. No es dificil de leer. Si sabes programar.

    No te obsesiones por blindar tu trabajo. Es tentador tener lo que se conoce técnicamente como “seguridad laboral”, ser el dueño de ese trozo de código que nadie entiende. El problema es que, colega, siempre habrá gente que lo entienda. O que lo consiga duplicar sin tener que suplicar audiencia para que arregles lo que sabes que falla. La seguridad laboral a través de la oscuridad es algo muy español pero tiende a desaparecer.

    Responsabilízate de tu código. Del bueno y del malo. Lo de “esto lo ha hecho otro” cuela las tres primeras veces. Al igual que se puede determinar quien ha escrito un texto por los trazos, se puede identificar a un programador por su estilo. Sobre todo si está lleno de errores de diseño. Incluso siendo código limpio es fácil identificar, en una empresa, el estilo personal de cada programador.

    No pienses en que esa automatización la dejas mejor para el que venga después. No la haces únicamente para facilitar tu trabajo. Piensa de manera egoista: lo haces para aprender algo nuevo. Oblígate a aprender cosas nuevas. No a diario, pero sí cada poco. Tampoco interpretes esto como un “vamos a cambiar el framework que usamos por este otro que está de moda”. Haz que tu código evolucione sin romperlo. Es posible.

    El refactoring no es un equipo de la liga inglesa. Es otra herramienta en tu arsenal de herramientas intangibles. Úsalo con prudencia y criterio. Aprende a pensar en las implicaciones de tus cambios y a hacerlos sin temor al fin de la civilización. Y, cuando rompas algo, hazte responsable.

     

  • Comentarios desactivados
  • Un usuario. En la biblioteca. Con un tablet.

    Lunes
    09.jun.14

    En Internet hay miles de artículos sobre optimización de código y mejoras de escalabilidad para que tu super servicio soporte más de 10.000 peticiones por segundo. Y miles de programadores, en este momento, están leyendo esos artículos. Solía decir que de esos miles de ávidos lectores, en un momento dado, sólo dos realmente necesitan la información. Es decir, está bien optimizar pero cuando sabes que lo vas a necesitar, no por practicar otro deporte de riesgo. Sigo pensando así. Mi webapp, mi site, mi servicio de alquiler de mascotas por horas, no va a necesitar grandes alharacas en el terreno de la escalabilidad.

    Hasta que descubres un nuevo problema de escalabilidad: el Señor Verde. En la biblioteca. Con un tablet. Traduciendo para los que no conocen el Cluedo: un único usuario con una tableta. Y su aplicación de CRM. O de cualquier otro sistema que tenga que machacar datos. Muchos datos. Un único usuario, no 10.000.

    Independientemente de si la estructura de datos es de nueva planta o es una adaptación de un megadatawarehouse mantenido por tres ingenieros nucleares y dos consultores de la NASA lo que está claro es que, en algún momento, esa estructura va a dar problemas. De complejidad y, por lo tanto, de velocidad. La velocidad. El talón de Aquiles de cualquier tableta. Y el talón, el femur, la rabadilla y el brazo izquierdo de Aquiles de cualquier webapp en una tableta.

    SQLite puede ejecutar los mismos queries que tu app contra un servidor Oracle. En una aplicación de escritorio la diferencia de velocidad no llega a afectar a la experiencia del usuario. Es en una tableta donde esta diferencia si se nota. No en el uso normal, buscando, mostrando resultados (donde si se mira el profiler con atención se ve que aún hay mucho por optimizar en el dibujado antes de meterse con los datos), sino en algunos momentos delicados. Por ejemplo, preparando una vista que muestra información de distintas subentidades. O en el, cada vez más requerido, dashboard o panel de control. Un sitio donde se tiende a obtener KPIs agrupando datos dispares. Ejecutando queries complejos. A veces muy complejos. Que puede que no tarden más de 1500ms en ejecutarse pero… uno detrás de otro + ejecutados en un entorno síncrono + uniendo el resultado de subqueries para obtener una cifra x cada vez que se redibuja el dashboard = lentitud percibida por el usuario.

    Uno de los remedios típicos en web ha sido desnormalizar los datos, tunearlos para que los resultados sean lo más rápido posibles, a costa de aumentar el espacio que ocupan los datos. En un entorno donde el espacio es “barato” y la velocidad “cara” es normal que, por ejemplo, las relaciones de un usuario de un site social no se calculen a la hora de mostrarlas, sino que estén precalculadas y que lo que se muestra es el resultado de dicho cálculo.

    ¿Cómo podemos aprovecharnos de este truco en una aplicación (mixta o nativa) que usa SQLite o algún otro motor de datos en una tableta? Exactamente de la misma manera. Siguiendo con el ejemplo del CRM y del dashboard que muestra, por ejemplo, la desviación a la hora de conseguir un objetivo el sistema tradicional nos dicta que hemos de ejecutar uno o varios queries hasta obtener el número de elementos que se desvían del objetivo previsto en tal o cual grado. Siguiendo con ese sistema tradicional se ejecutan dichos queries contra todas las tablas implicadas en el cálculo de los KPIs. Para ponerlo claro: quiero el total de todos los pedidos que contengan líneas de productos que están en una tabla de promociones que se basan en la fecha y la situación geográfica del comprador que no lleguen a un mínimo de unidades y lo quiero agrupado por medio: presencial, teléfono o fax. Este sencillo query se ejecuta cada vez que se actualiza el dashboard como resultado de un cambio en los datos.

    La opción no-tradicional puede ser tener una o más tablas específicas para el cálculo del resultado final. A la hora de crear o modificar un registro que afecta a la desviación, se calcula el valor para cada línea de pedido y, con el cálculo de estas, para el pedido. Se asigna, por ejemplo, un valor tipo y un valor si/no. Cuando se actualiza el dashboard ya no se ejecutan los queries para calcular el total de pedidos, sino que el query es sencillo y rápido. El “peso” del cálculo se ha llevado a un punto de la ejecución del programa, la grabación, donde el usuario puede esperar medio segundo más. Sólo se calculan las filas necesarias en la estructura de datos, no se ejecuta un query que busca determinadas líneas de los pedidos y luego cruza con los tipos de los pedidos.

    Es un breve ejemplo de cómo luchar contra el problema definitivo de optimización y escalabilidad: Un usuario. En la biblioteca. Con un tablet.

  • Comentarios desactivados
  • The mandatory Swift entry

    Jueves
    05.jun.14

    I won’t be able to write something interesting (or not) about Swift until I write, compile and maintain a project with it.

    In the meantime, where’s my prize for joining the fuzz?

  • Comentarios desactivados
  • Back to the basics

    Lunes
    02.jun.14

    My latest “weekend project” (weep for short) has two objectives: first and more important, help me forget the hideous code I’ve been forced to clean for the last two weeks (and counting). Secondly, as any weep worth of its name, force me to learn something new. And what am I learning, would you ask? Apart from a new tool, I’m learning to un-jQuery myself.

    In more simply worlds, I’m coding JavaScript without any lib. Do you remember the reasons for the existence of jQuery? Do you remember the browser wars of the nineties? Do you even remember the nineties? That was the time when, if you were doing some web development, you needed to write everything twice. One for each DOM. So, when jQuery and other libs, such as Prototype, arised we were released from the chains of rewriting and retesting for that SOB browser everyone has grown to hate.

    But now we’re in the “HTML5 era”, that happy time when there’s not a single browser that can reach more than 85% of compliance with this not-so-standard standard. But they’re trying. And browser makers are implementing DOM related functionalities that don’t compete against each other.

    So, instead of relying on the tried and trusted jQuery selectors I’m using pure JavaScript methods such as document.querySelector(), or even coding some small methods for AJAXing and (gasp) XML handling.

    And then you look straight into my eyes and ask “why, oh why, are you working so much without need or reward”? Because I can. Because I want to learn some new skills, such as the new DOM and File APIs available in any self-respecting A-class browser. Because I’m afraid that, when the zombycalipse arrives, all jQuery will be banned from earth’s face… Pick one reason. I have more. Seriously.

    It’s important to learn how to do something without clutches. In this world where self-appointed experts cannot code without IntelliSense or a full-fledged IDE we’re forgetting that all that crap relies on code and features that we don’t know how to use. Or even understand. Keep your skills fresh, my brother. Of course it will be useless for getting you a better job or even a raise. But your soul will thank you.

  • Comentarios desactivados