Algunos problemas éticos del posicionamiento en interiores

Hace algunos meses hablamos del posicionamiento en interiores (aquí), más popularmente conocido por su nombre en inglés (posicionamiento indoor). Allí nos centrábamos en el posicionamiento basado en fingerprinting, ya que ése era el tema del simposio de que se hizo por aquellas fechas Barcelona. En esta entrada, hablaremos de un tema que salió en el simposio de Barcelona y que plantea algunos problemas que, a menudo, se olvidan cuando uno está inmerso en los objetivos técnicos: los problemas éticos y de privacidad. Si miráis en algún proveedor de mapas o ortofotos, veréis que, a menudo, hay zonas vacías o donde aparecen “nubes”, a pesar de estar el cielo despejado. Normalmente estas nubes se han puesto artificialmente para tapar instalaciones sensibles (sí, ya sabemos dónde están, pero al menos no se ve cómo están distribuidas por dentro).  Otras veces, hay países enteros que no están en el mapa (dejo a vuestra imaginación adivinar alguno). Este problema se presenta también en el posicionamiento en interiores. Lo primero que hay que tener en cuenta es que para conseguir la posición en un edificio es imprescindible disponer del plano del edificio o, al menos, de la planta del edificio donde queramos el posicionamiento. Además si lo que queremos es que los usuarios puedan orientarse y navegar por el edificio, tendrán que tener información del plano en el dispositivo que usen para ello (bueno, también se les podrían dar las indicaciones sin distribuirles el plano, al estilo de cómo guía Morpheo a Neo al principio de Matrix, pero no queda tan bonito). Este plano es relativamente fácil de conseguir en centros comerciales públicos, pero...

La evolución de la Inteligencia de Negocio (BI) en la empresa y la academia

En la UOC llevamos tiempo impartiendo cursos sobre Business Intelligence, Business Analytics y Big Data. ¡Ya más de 10 años! Esto nos da una visión de cómo han evolucionado las necesidades de las organizaciones respecto al análisis de los datos y las competencias que necesitan los profesionales. En la última década, hemos pasado de sólo disponer de la inteligencia de negocio y el data warehouse como las herramientas fundamentales para entender el rendimiento de nuestra organización a un nuevo escenario flexible, políglota, complejo, escalable y automatizado que busca empujar la transformación digital de la organización. Todas estas estrategias y tecnologías buscan, en definitiva, capacitar a todo el mundo para tomar decisiones informadas y competir de forma diferente (como ya comentamos en dos entradas anteriores: La nueva forma de competir (I) y La nueva forma de competir (y II)). Hagamos un poco de retrospectiva. Parafraseando a Donald Rumsfeld, There are things we know that we know and things we know that we don’t know. Es decir, el punto de partida de una organización (para con el dato, claro) es validar hechos y responder preguntas conocidas para la gestión de la empresa o institución. Estamos hablando, por ejemplo, de poder responder: qué hemos vendido, cuál es nuestro beneficio, quiénes son nuestros clientes, cómo nos compran, etc. Para este tipo de preguntas la inteligencia de negocio ha sido la pieza angular sobre la que nos hemos apoyado. En este tipo de análisis, tradicionalmente, se ha empleado la combinación de un data warehouse para el almacenamiento de la información con fines análiticos y una herramienta para el análisis de dichos datos, como por ejemplo...

Inteligencia Artificial: Colonias de hormigas

Este verano he tenido (y tengo) una plaga de hormigas en casa (no es broma). Es curioso el comportamiento comunitario de estos seres, que no dependen de un individuo en concreto, sino que basan su existencia en el funcionamiento coordinado de todo el equipo. Así, “acabar” con unos cuantos individuos no es, ni mucho menos, algo que afecte al día a día del grupo. Curiosamente, a la vez, he estado programando -en Prolog- (soy de los que piensan que “real men/women program Prolog”) una metaheurística basada en el comportamiento de las hormigas para la optimización de problemas combinatorios. Por si alguien quiere curiosear un poco, podéis encontrar, criticar, contribuir, hacer seguimiento, etc. de lo que llevo hasta ahora (ya funciona, parcialmente), que forma parte de un proyecto más ambicioso, aquí. El código se ejecuta sobre un lenguaje de programación lógica con restricciones llamado ECLiPSe y que podéis descargar aquí. Hace poco os hablé de la existencia de algoritmos bioinspirados, basados en el “conocimiento” observado en ciertos procesos naturales a la hora de resolver problemas concretos. En dicha entrada, uno de los que os comentaba era el basado en colonias de hormigas. Pero, ¿qué hacen las hormigas que nos pueda interesar a los informáticos/as? y ¿cómo lo trasladamos a un algoritmo? Pues bien, el interés que podemos tener en dichos seres viene de su manera de construir colaborativamente soluciones a partir de agentes muy simples. Así, la gracia de las hormigas no es que una sola sea capaz de encontrar el camino más corto entre dos puntos. La gracia, de hecho, es que es totalmente incapaz. Pero en cambio, un...

¿Qué debería aprender un desarrollador de motores de videojuegos?

En el pasado GameLab, y más allá de las charlas de grandes gurús explicando sus batallitas, también fue posible asistir a ponencias más de tipo orientación para aquellos interesados en dedicarse al mundo del desarrollo de videojuegos. Todas eran muy interesantes, pero quizá la que más me llamó la atención  por su título fue la ofrecida por Mike Acton, director de motores (Engine Director) en Insomniac Games, creadores de sagas con tanta solera como Spyro o Ratchet & Clank (de éste último hay hasta una película de animación relativamente reciente). La ponencia llevaba el título “Process I wish they taught engine programmers in school” (Procesos que desearía que enseñaran a programadores de motores en la escuela). Un tema interesante no solo para los estudiantes, sino toda una llamada a los propios docentes. Su punto de partida era el hecho que, una vez tras otra, se encontraba que desde que un nuevo miembro se incorporaba a su equipo hasta que estaba listo para valerse por si mismo pasaban al menos dos años en los que debía ser formado. Desde su punto de vista, este problema venía dado por algunas costumbres o prácticas de programación que se enseñan en las escuelas técnicas o de ingenierías, que si bien sobre el papel o en una gran cantidad de proyectos funcionan, para la programación de  motores de videojuegos deben ser corregidas. El meollo del asunto según su punto de vista es que a menudo tendemos a sobrecomplicar las cosas bajo la justificación de la escalabilidad. Se nos plantea un problema y enseguida hacemos API’s o capas de abstracción que permitan resolver ese problema…...