En mi más reciente asignación profesional me ha tocado migrar un pedómetro. El desarrollo original consiste en un conjunto de programas en Python que hacen uso de la orientación a objetos. Aunque se trata de una aplicación justificada y un muy buen ejemplo del uso de este paradigma de programación, el resultado es, la verdad, un programa complicado y difícil de mantener. El dueño ha optado por extraer una parte de este desarrollo a algo más simple y fácil de mantener (toda vez que otro algoritmos que este programa incorporaba ya han sido pasados por este proceso y el que me ha tocado es el último de ellos).
Definitivamente no es el paradigma de programación el problema en esta ocasión. El problema son malas decisiones de cómo implementar un flujo de datos y el que el programa resultante implementa todo un pipeline. Al respecto de esto último, resulta curioso lo que uno entiende por «pipeline», pues el dueño de estos programas lo ve simplemente como el flujo que se da entre varios programas y no como algo a nivel de procesos. Y no es que esté mal dicha percepción, que técnicamente es correcta, pero cuando yo escucho este término pienso más en algo orquestrado por un calendarizador de tareas, en el que se involucra una infraestructura, recursos e insumos, más de forma asíncrona. Un flujo coordinado entre una secuencia de programas es algo que implica un punto de falla muy serio. Un eslabón muy débil en una cadena de eventos que se presupone siempre saldrá bien.
De cualquier modo, esta serie de posts no es de programación ni del «procesamiento en oleoducto» (término que por primera vez leí en el libro de M. Morris Mano «Arquitectura de Computadores» que adquirí cuando cursaba la vocacional) sino que algo que no me había tocado experimentar en el desarrollo de software y que tiene que ver con el procesamiento de señales y el Internet de las Cosas.
Ya he venido escribiendo sobre la informática médica y sobre lo que escribiré está enfocada a un desarrollo destinado a procesar la salida de dispositivos de grado médico pero no es algo realmente novedoso. El uso de acelerómetros es algo muy común en muchos dispositivos desde hace mucho tiempo. Muchos discos duros (no limitados a los portátiles o externos) incorporaban aceleradores para retraer las cabezas lectoras y evitar daños a la superficie de los platos de los discos (con la consecuencia pérdida de datos) desde hace mucho (según yo desde hace unos 20 años). Similarmente cada vez son más los teléfonos que los incluyen y sacan provecho de ello para rotar las pantallas, así como los smart watches y pulseras deportivas (tanto de baratas como caras) para generar (todos ellos) datos relacionados con la salud y el acondicionamiento físico. De hecho, el uso de acelerómetros es algo tan común ya que no sólo resulta ubicuo sino también con implicaciones en materia de seguridad y privacidad1.
Referencias
- Jan Peter van Zandwijk & Abdul Boztas, «The iPhone Health App from a forensic perspective: can steps and distances registered during walking and running be used as digital evidence?«, Digital Investigation, Volume 28, Supplement, April 2019. Pages S126-S133. URL: https://www.sciencedirect.com/science/article/pii/S1742287619300313, DOI: https://doi.org/10.1016/j.diin.2019.01.021.
Dr. Edu 
Un comentario en “De pasos y andares (1)”