SG #45

De Chile y de Manteca

sg — Sat, 20 Sep 2014 04:47:22 +0000

De Chile y de Manteca sg Fri, 09/19/2014 - 23:47

Publicado en

SG #45

Tejiendo nuestra red

Autor

Hanna Oktaba

ESSENCE 1.0 con KUALI-BEH

En mayo de 2014 fue publicado por OMG el nuevo estándar ESSENCE 1.0, cuyo anexo B contiene una extensión del núcleo de ESSENCE llamada KUALI-BEH, desarrollada orgullosamente en México.

Ya es el segundo estándar intenacional, después de ISO/IEC 29110, dónde pusimos nuestro granito de arena apoyados, entre otros, por Software Guru.

El documento de ESSENCE 1.0 está disponible en para su descarga [1] en versión Beta2, que espera en la fila de estándares para la última “manita de gato” de los editores técnicos de OMG, pero ya no cambiará su contenido.

Les debo un artículo sobre ESSENCE y su uso en la vida diaria de los proyectos de software, que puede ser de mucha utilidad. Mientras tanto pueden buscar el libro The Essence of Software Engineering, Applying the SEMAT Kernel, de Ivar Jacobson y sus colegas.

Reunión plenaria de ISO/IEC JTC1 SC7 en Sydney, Australia

Los trabajos sobre el estándar ISO/IEC 29110 no terminan. En la reunión plenaria en la bonita ciudad de Sydney tuvimos la oportunidad de percatarnos de como la idea, que surgió en México hace12 años con MoProSoft, de enfocar el modelo de procesos a pequeñas empresas, adquiere mucha importancia internacional.

Por un lado, se nos sumaron al WG24, que trabaja el estándar 29110, los nuevos representantes de la India, Corea del Sur y Sud África. Fuimos el grupo más numeroso de todos los grupos de trabajo de SC7. Preguntando a Gargi Keeni, la consultora de nada menos que TCS (Tata Consultancy Services), porqué tanto interés en VSEs (Very Small Entities), me contestó lo siguiente: aunque TCS es una empresa grande, la mayoría de los proyectos se hacen por equipos pequeños, por eso queremos entender la propuesta que han hecho para VSEs. Por otro lado Japón ha publicado una guía para facilitar la adopción de ISO/IEC 29110 Basic profile a sus empresas (Ver Imagen 1). Ni hablar de Brasil que tiene un programa muy agresivo de adopción de ese estándar con el apoyo de fondos gubernamentales y de Microsoft. Su modelo de evaluaciones está basado en las auditorías tipo ISO 9000 con un reconocimiento internacional.

Como Delegación Mexicana logramos que los procesos de MoProSoft de la capa de Gerencia y de la Alta Dirección, actualizados, se pondrán a la revisión por los países miembros como un nuevo perfil de 29110 llamado Organizational Management. Además, nos comprometimos a trabajar en los llamados grupos de estudio para atacar el problema de estándar de servicios de TI para las VSEs y la interpretación con métodos ágiles del Basic profile para software.

Como ven esto no tiene fin. La verdad necesitamos más manos de obra calificada para abarcar todos los temas que están surgiendo.

Evento SG

No puedo terminar esta columna sin agradecer nuevamente a SG por permitirme disfrutar SG Conference & Expo en junio pasado. Me reencontré con algunos colegas y exalumnos, aprendí cosas nuevas como el manifiesto del artesano de software y me decepcioné del SWIFT como “nuevo” lenguaje de programación, que no es otra cosa que una mezcla de conceptos conocidos desde Simula-67 y Smalltalk 80.

Pero lo más importante para mí fue notar la competencia y el entusiasmo de los expositores, la excelente organización del evento y una sensación de comunidad unida gracias a la gran labor de Mara y Pedro, los fundadores de SG.

Muchas felicidades por los 10 años y que sigan muchos más.

Referencias

[1] Documento de ESSENCE 1.0 http://www.omg.org/spec/Essence/Current

Modelos de calidad

sg — Sat, 20 Sep 2014 04:40:47 +0000

Modelos de calidad sg Fri, 09/19/2014 - 23:40

Publicado en

SG #45

Mejora continua

Autor

Luis Cuellar

El artículo anterior en SG44 dialogábamos sobre productos y servicios, sobre cómo cada día los servicios se están volviendo los verdaderos diferenciadores de una propuesta de valor, conjuntando la ingeniería de software con la ingeniería de servicios.

Dentro de este nuevo mundo, ¿qué rol juegan los modelos de calidad? ¿Por qué dichos modelos se han vuelto los principales medidores de un buen servicio? Muchas veces escucho tanto a desarrolladores de software como a los mismos clientes cuestionar exactamente ¿qué me da un modelo de calidad?, ¿por qué es tan importante que la empresa con la que trabajo esté acreditada en algún modelo? ¿Cuál es el mejor modelo? ¿Que lo hace tan bueno?

La realidad es que, desde mi punto de vista, y con riesgo a que ya no me inviten a los brindis de navidad, todos los modelos de calidad, bien implementados, generan valor; el secreto está en implementar estos modelos correctamente. Yendo más lejos, con algunas salvedades la mayoría de los modelos tienen mucho más similitudes que diferencias. Algunos modelos son más genéricos y otros más específicos, algunos modelos son descriptivos lo cual los hace más fáciles de implementar y de auditar, otros son más normativos, lo cual los hace más flexibles y susceptibles a interpretación. Cada modelo de calidad tiene sus ventajas y desventajas, algunas de ellas dirigidas al cliente, otras dirigidas al implantador y otras tantas dirigidas a ambos. Al final de cuentas, los objetivos principales de cualquier modelo de calidad se enfocan a asegurar un servicio estable, eficiente, de calidad y mejorable a través del tiempo. Esto normalmente lo logran a través de los siguientes principios:

1) El servicio se debe de basar en procesos repetibles. Todos los modelos de calidad buscan definir un proceso estándar, este proceso puede ser previamente definido dentro del mismo modelo o el modelo puede simplemente generar las reglas para crearlo. Este proceso debe de incluir la mayor cantidad de planeación en cuanto al futuro, buscando democratizar el conocimiento sobre cómo se resuelve un problema específico, para volver escalable la resolución de problemas y establecer bases para poder aprender realmente de nuestros errores y validar los supuesto que hacemos en cada proyecto

2) Planeación, estimación y seguimiento. Todos los modelos de calidad piden algún tipo de planeación: el ciclo de vida puede ser iterativo o en cascada; puede ser un servicio basado en requerimientos en dónde sólo planeamos como atacar cada requerimiento o por entregables en donde tengo que planear cada fase y cada entregable; la planeación puede abarcar desde una plantación de los entregarles, hasta una planeación de cómo integrar nuevos miembros al equipo de trabajo. En el todo de la solución, la estimación realmente es poco importante es una lista de supuestos que hago en base a estadísticas pasadas, la parte realmente crítica es el seguimiento del proyecto, el cual se asegura a través de continuamente verificar los supuestos, calcular riesgos y resolver issues asegurándose que la ejecución se asemeje a lo estimado y que asimilemos nuevas variables que se requieren contemplar en el futuro.

3) Todo modelo de calidad establece métricas específicas para tanto la calidad del producto, como el logro de los objetivos del servicio. Algunos modelos de calidad definen procesos específicos de cómo se debe definir estas métricas y otros definen las métricas básicas que se deben utilizar. El primer objetivo de las métricas es correctivo para ajustar la planeación y sus supuestos. El segundo objetivo es establecer un modelo de aprendizaje con el que se puede aprender a mediano largo plazo cómo mejorar el servicio a través de análisis estadísticos y modelos de simulación.

4) Los modelos de calidad no definen cómo generar una solución. Esta labor es muy dependiente de las características específicas de servicio. La ingeniería de software se preocupa por asegurar que resolvamos correctamente el problema correcto. Lo único que algunos modelos de calidad trabajan son procesos para asegurar que se resolvieron todas las necesidades acordadas con el cliente. Eso se lleva a cabo mediante algún tipo de seguimiento a los requerimientos, mientras pasan a través de diferentes fases de la preparación del producto tratando de dejar una liga clara de cómo los requerimientos iniciales concluyeron con los resultados finales.

5) Algunos modelos de calidad cubren elementos considerados de apoyo a la operación. ¿cómo es la estrategia y ejecución de entrenamiento continuo?, ¿la administración del conocimiento?, ¿la sustentabilidad del negocio y su aportación a la sociedad? El alcance de algunos modelos es más amplio. Por ejemplo, algunos cubren elementos de seguridad de información, conceptos legales o laborales que afectan al proyecto, dando diferentes énfasis a cada elemento dependiendo del enfoque y el tipo de servicios que busca apoyar.

Estas reglas aplican a la mayoría de los modelos de calidad, y son la base para establecer una estructura de software orientada al servicio, la mayoría de las empresas que están certificadas en algún modelo de calidad pueden dar respuesta a estas inquietudes. Estos modelos son la pauta para asegurar que el servicio que estamos dando es de calidad, consistente a través del tiempo y que se revisa continuamente para buscar hacer el servicio cada vez mejor. Los modelos de calidad son la base para establecer un modelo de servicio de software.

Bio

Luis R. Cuellar (@lcuellar) es director de calidad a nivel mundial de Softtek. Es reconocido por la ASQ como Certified Quality Manager, Certified Software Engineer y Six Sigma Black Belt.

¿Por qué Todos en tu Startup Deberían Contestar Correos de Soporte?

sg — Sat, 20 Sep 2014 04:38:47 +0000

¿Por qué Todos en tu Startup Deberían Contestar Correos de Soporte? sg Fri, 09/19/2014 - 23:38

Publicado en

SG #45

Emprendiendo

Autor

Celeste North

Entre la gran cantidad de cosas que tienes que hacer cuando estás en un startup, especialmente al principio cuando el equipo es muy pequeño, es contestar a todos esos valiosos clientes que experimentan frustración, confusión y enojo con tu producto o servicio.

Sin embargo, al inicio nunca está muy bien definido quién se encarga de hacerlo. Si le toca a la persona técnica porque es un problema con la plataforma o si le toca al de negocios porque es un problema de que no se entendió el producto/servicio, etcétera.

En mi camino por distintos proyectos he notado que siempre se busca un responsable que se encargue de ello mientras el resto del equipo se encarga de sus distintas áreas. Y cuando una persona nueva entra al equipo, nunca le toca colaborar contestando correos de soporte. Hacer esto es desperdiciar una enorme oportunidad de aprendizaje; nada te hará entender mejor cuáles son las áreas de tu producto o servicio que se tienen que mejorar si no escuchas lo que tus clientes tienen que decir.

Se nos olvida que una mala experiencia con nuestra plataforma o aplicación puede generar no solo malos momentos a nuestros clientes, sino toda una serie de malas recomendaciones al grado de que ya nadie quiera intentar usar tu servicio porque todos le han dicho que no funciona. Esto se puede prevenir si entendemos mejor cuáles son los puntos donde estamos fallando y las áreas de mayor frustración para nuestros usuarios.

Organiza a tu equipo

Aunque no todos tengan la habilidad de contestar y resolver los problemas, una buena práctica es tener un sistema para monitorear los mensajes y el seguimiento que se le da a los mismos.

Esto puede ser algo tan sencillo como utilizar etiquetas de Gmail y contar con un correo grupal al que se copian los mensajes al momento de contestar (para que todos sepan que el tema se está atendiendo) o tan complicado como utilizar un sistema más avanzado de seguimiento de correos de soporte como Zendesk o Support Bee.

Una vez que definan cuál será el procedimiento para recibir y contestar los correos, lo mejor es generar un documento que contenga información sobre cómo contestar por cada tipo de casos. Este documento irá creciendo y cambiando a la vez que lo hace tu startup pero será el referente para que personas nuevas sepan cómo actuar y para tener un procedimiento claro que evite que las decisiones de cómo proceder a ciertos casos estén en manos de la persona que contesta.

Este documento puede contener por ejemplo los criterios para reembolsos ¿En qué casos se hace un reembolso parcial o total? ¿Cómo se debe contestar al cliente si no es posible reembolsarle? Si el usuario tuvo un problema con la aplicación por un bug ¿Qué le decimos?

Sobra decir que este documento deberá ser actualizado constantemente de acuerdo a los problemas nuevos que se presenten o cambios en el funcionamiento de tu plataforma.

Identifica los puntos de frustración más comunes

Tú conoces tu plataforma de arriba para abajo, conoces perfectamente a donde te lleva (o debería llevarte) cada click y la ves todos los días a toda hora. Las primeras veces que lees sobre la frustración de tus usuarios es fácil pensar que no le entienden o que no son tu tipo de cliente y que por lo tanto el problema son ellos. Este es un gravísimo error.

Si un futuro cliente no entiende cómo funciona lo que le estás vendiendo, no podrá jamás ver el valor que estás tratando de darles pero entenderlo no es responsabilidad de ellos. Piensa en todas las veces que has sentido frustración por una forma de registro que no funciona bien o una página en la que no encuentras el botón que necesitas.

Además, un cliente que se enoja con tu servicio y en lugar de descartarlo por completo, decide enviarte un mensaje, puede ser un futuro fiel usuario. El paso de uno a otro puede recaer casi enteramente a que alguien le conteste en tiempo y forma además de solucionar su problema.

Aprovecha la oportunidad de entender mejor a tus clientes y de mejorar las áreas de tu producto o servicio que están alejando a tus clientes, ellos serán más honestos que tus amigos sobre las cosas que hay que cambiar en tu plataforma o aplicación.

Bio

Celeste North es Country Manager de MUBI México, plataforma de Video on Demand de cine de arte, clásico y de culto. Activa participante del ecosistema de startups en México, anteriormente fue fundadora de NuFlick y participó en Mexican.VC y Startup Chile. Encuentrala en Twitter como @celestenorth

SG45: Lo que viene

sg — Sat, 20 Sep 2014 02:23:12 +0000

SG45: Lo que viene sg Fri, 09/19/2014 - 21:23

Publicado en

SG #45

Herramientas y Tecnologías

Yeoman: Scaffolding de apps

Yeoman es una herramienta para generar esqueletos de nuevas aplicaciones y acelerar así su desarrollo. La novedad de Yeoman es que es extensible y cualquiera puede colaborar con nuevos tipos de generadores. Actualmente hay generadores para una gran de tecnologías, incluyendo algunas de las más populares como: Angular, Backbone, Cordova, Node y Ember.

El workflow de Yeoman está compuesto por tres tipos de herramientas:

La herramienta para generación de esqueletos (se llama “yo”).
Un sistema de construcción (build automation) como Grunt.
Un gestor de paquetes como npm o Bower.

http://yeoman.io

Realm: Base de datos móvil

Realm es una base de datos para aplicaciones móviles. Se define a sí misma como un reemplazo para Core Data y SQLite. Realm tiene un API simple de usar, ofrece un desempeño rápido y puede soportar estructuras de datos complejas. Incorpora capacidades como lazy loading y multithreading.

Realm actualmente está disponible para iOS y OSX. Se espera que pronto también liberen la versión para Android.

http://realm.io

Appium: Mobile app testing

Appium es una herramienta para automatización de pruebas de aplicaciones móviles. Es open source, cross platform y se puede utilizar para probar tanto apps móviles nativas como web e híbridas. Con appium puedes probar apps para iOS, Android y FirefoxOS.

Appium viene a ser algo así como una versión de Selenium para apps móviles. De hecho, utiliza WebDriver, el protocolo de Selenium. Una de las ventajas de Appium respecto a otras herramientas para testing de apps, es que no requiere recompilar la app, ya que recurre al framework de automatización de UI de cada plataforma (UIAutomation en iOS y UIAutomator en Android). Otra ventaja es que puedes escribir tus pruebas en cualquiera de los lenguajes soportados por WebDriver como Python, Java, PHP, C# o Ruby, entre otros.

http://appium.io

Apache Spark: Cómputo de alto desempeño

Hace tiempo que no mencionamos en esta sección ningún proyecto de la fundación Apache. Posiblemente su proyecto “estrella” (y no lo decimos solo por el logo) actualmente es Spark.

Spark es un motor para procesamiento de datos distribuido de alta velocidad. Spark se basa en el sistema de archivos de Hadoop (HDFS), pero no está atado al paradigma MapReduce, y de hecho promete un desempeño entre 10 y 100 veces más rápido que MapReduce. Spark provee primitivas para cómputo en-memoria en cluster, lo cual lo hace buen candidato para procesar algoritmos de aprendizaje automático (machine learning).

http://spark.apache.org

Productos en Permanente Mejora

sg — Sat, 20 Sep 2014 02:17:15 +0000

Productos en Permanente Mejora sg Fri, 09/19/2014 - 21:17

Publicado en

SG #45

Tendencias en Software

Autor

Luis Daniel Soto Maldonado.

Aunque se debate cuando apareció el primer juego electrónico, la era de las “maquinitas” operadas con moneda inició en 1972. Durante cuatro décadas hemos vivido una permanente era de innovación. Durante este mismo periodo, hemos planeado el futuro de juegos y otros productos con artefactos y técnicas de limitado alcance. Literalmente hemos diseñado con los ojos cerrados.

“Hoy es posible predecir, en 3 días, el riesgo de que el cliente de un nuevo videojuego en línea abandone el servicio”

Identificar a los jugadores que pueden dejar de jugar permite tomar acciones para prevenir el abandono. Mantener a los clientes activos en el sistema significa mayores ingresos y utilidades. Significa también menos copias vendidas en el mercado de productos usados.

Halo recolecta información estadística de toda sesión que se juega. La información que identifica a un sistema se elimina; los datos adquiridos contienen detalle de la interacción, desempeño y aspectos sociales de cada jugador. De estos datos se producen 150 “características” que describen el comportamiento y experiencia del usuario. Ejemplos de estos son: segundos jugados, sesiones más cortas y más largas, sesiones promedio, puntos acumulados, número de juegos con otras personas, número de juegos con un mismo amigo, etc.

Con base en el uso de millones de personas y grandes cantidades de información, el aprendizaje de máquina es capaz de “descubrir el secreto” detrás de posible uso del sistema, con una muy alta probabilidad.

Si el usuario no abandonó la experiencia, los siguientes 7 días crearán un perfil más detallado y será posible conocerlo mejor y en más facetas. Además de conocer con 90% de certeza lo que sucederá, el análisis de máquina permite identificar errores en el juego, cambios de comportamiento (cheats), dificultad de los niveles y preferencias de diversos tipos.

En el pasado, cambiar un juego llevaría posiblemente meses o años, hoy es posible cambiar el juego en cuestión de horas, crear nuevas áreas en base a preferencias efímeras. De hecho, el motor de gamification que Microsoft utiliza es totalmente independiente al código del juego , este puede ser editado en tiempo real sin ningún programador. El juego emite “eventos” como un gol o un zombi eliminado. Un conjunto de eventos puede “desbloquear” reconocimientos, de hecho éstas se podrán asociar a zonas geográficas, husos horarios, etc. Con lo anterior un analista es capaz de crear nuevos retos y colocarlos a escala global en minutos.

En resumen, la era de operar “sin” instrumentos terminó. En el futuro tendremos mucho más sistemas de observación, de captar el comportamiento real y con ello tendremos el poder de actuar antes de que los eventos sucedan y de adaptar los productos como nunca antes.

Del juego al negocio

Pronóstico. ¿Qué clientes van a dejar de pagar un crédito? ¿Cuántos bienes se van a vender? ¿Cuánto voy a vender? ¿Cuál será la temperatura en un edificio dentro de 2 horas?

Detección de anomalías. Predecir cuándo el acceso a un servidor por cierto rol se sale de la norma o cuando el comportamiento de la granja de servidores cambia. Fraudes con pago de tarjeta de crédito, propagadas, etc.

Optimización. ¿Cuál es la mejor forma de efectuar cientos de envíos?, Optimizar la inversión de mercadotecnia digital con el precio de subasta de cientos de palabras clave para la mayor conversión. Predecir los ingresos con monedas internacionales de diversos mercados.

Para las grandes empresas, optimizar un proceso en un 0.001% significará generar millones incrementales de venta o ahorros. Dichos modelos no son triviales, requieren de alto poder de cómputo y semanas de experimentar con modelos. Un sistema en producción se puede implantar también en semanas o meses y va a requerir correcciones permanentes.

Esta capacidad es ahora viable, pero aún es una combinación de “arte” y ciencia que requiere, no de un individuo, sino de un equipo que combine conocimientos de programación, manipulación y modelado de datos, estadística, conocimiento de negocios y por supuesto de visualización y comunicación efectiva.

Para entender las formas en que los diferentes equipos resuelven problemas similares a los descritos visita Kaggle.com. En un reciente concurso público por crear un modelo para predecir el valor de reventa de autos, decenas de equipos de “científicos de datos” utilizaron todo tipo de parámetros y algoritmos para identificar autos que generarían mayores utilidades. El ganador produjo el mejor “modelo de elevación” en predicciones ganó consóloo “un elemento”: si el color del vehículo era no estándar, era altamente probable que los dueños lo cuidaran y mantuvieran mucho mejor, reduciendo el riesgo de adquirir autos seminuevos defectuosos.

Si contara con instrumentación similar a la descrita, conocería mejor a mis lectores, sus intereses, el futuro del consumo y aplicación de mis artículos. Mientras llegamos me conformo de saber que nuestro entorno se preparará a anticipar nuestros actos.

Habilitemos la era de la inteligencia prescriptiva y productos que se adaptan en cada instante.

Bio

Luis Daniel Soto Maldonado (@luisdans) labora en la división de negocio de servidores y herramientas de Microsoft Corp.

Desarrolla Apps con Kinect V2

sg — Fri, 19 Sep 2014 23:23:02 +0000

Desarrolla Apps con Kinect V2 sg Fri, 09/19/2014 - 18:23

Publicado en

SG #45

Tutorial

Autor

Laura Frías Carrillo

Cuando se popularizaron las computadoras personales hace cerca de 30 años, el teclado y el ratón se convirtieron en objetos cotidianos para poder trabajar con procesadores de texto, hojas de cálculo y juegos de escritorio. Con la aparición de dispositivos touch como smartphones, tabletas y computadoras el uso de esta tecnología se volvió más natural e intuitiva, sólo basta observar cómo niños y adultos son capaces de utilizarlos sin esfuerzo. Las interfaces naturales de usuario están cambiando la manera en que interactuamos con los dispositivos de cómputo.

Las interfaces naturales de usuario (natural user interfaces, NUI) son aquellas que permiten interactuar con un sistema o aplicación sin necesidad de utilizar dispositivos intermedios —como serían un ratón, teclado, lápiz óptico o touchpad. Es decir que interactuamos con el dispositivo de la misma manera que lo hacemos con otros humanos —mediante la voz y movimientos corporales.

Kinect: Innovando las NUI

Kinect ha sido parte de esta revolución, y está innovando en el uso de las NUI no solo para el entretenimiento sino en todo tipo de ámbitos.

Desde su primera versión, Kinect cuenta con las siguientes características:

Una cámara que puede ver en 3D gracias a los sensores de profundidad que recolectan la información de los rayos infrarrojos.
Una videocámara tradicional RGB.
Un arreglo de 4 micrófonos ubicados en la parte inferior para detectar la dirección de donde provienen los sonidos y reconocimiento de voz.
Un sistema que reconoce si una persona está enfrente del sensor y la posición de su cuerpo a través de la creación de un esqueleto virtual.

Kinect ha logrado mejoras en diferentes áreas como medicina, educación y sistemas de rehabilitación. Por ejemplo, los médicos pueden interactuar con radiografías mediante gestos dentro de los quirófanos (ver figura 2). También se han desarrollado terapias con el sensor para ayudar a niños a desarrollar sus capacidades motrices y de lenguaje.

Figura 1. Kinect en la medicina

Mejoras en la versión 2

Con la salida de la consola Xbox One, Microsoft liberó en julio de 2014 las nuevas herramientas de desarrollo para la versión 2 del sensor Kinect, lo que mejoró sustancialmente sus capacidades de reconocimiento. Entre las mejoras destacan:

Un campo de visión más amplio, tanto horizontal como vertical, se eliminó la necesidad de tener un motor para el ajuste de altura, ya que se modificó la tecnología de infrarrojos.
La fidelidad en los datos de profundidad se incrementó al triple. También mejoró el rango de profundidad que se puede cubrir, desde 50 cm hasta 8 metros.
La cámara de color ahora es full HD y funciona a 30 cuadros por segundo.
Ahora se cuenta con 25 uniones en el esqueleto y soporta simultáneamente el seguimiento de hasta seis personas, con correcciones especialmente en las uniones de la cadera, hombros y columna vertebral. Ver Figura 3.
Se agregó un reconocimiento especial del pulgar para saber si la mano está cerrada o abierta.

Cómo desarrollar apps con Kinect

El SDK 2.0 para el Kinect ya se encuentra disponible de forma gratuita para que puedas aprender a construir apps que aprovechen esta tecnología. Actualmente el SDK se encuentra en una versión de “preview” que todavía no permite publicar las apps en el Windows Store, pero se espera que antes de que termine el año se libere la versión final del SDK que permitirá publicar al Windows Store.

Para desarrollar aplicaciones con Kinect v2, además de contar con el sensor Kinect requieres una computadora con las siguientes características de hardware y software:

Procesador dual-core de 3.1 Ghz o más
4 GB de RAM o más
Tarjeta gráfica con soporte para DirectX 11
Puerto USB 3.0
Sistema Operativo Windows 8/8.1
Visual Studio 2012/2013
.NET Framework 4.5
SDK Kinect para Windows V2. Descargar en http://bit.ly/SDKKinect

La figura 2 muestra la arquitectura de APIs del Kinect v2.

Figura 2. Arquitectura de Kinect para Windows

El sensor Kinect compone la capa de más bajo nivel, pues es el hardware contiene los sensores y cámaras. La capa siguiente son los controladores que permiten digitalizar los datos de los sensores que posibilitan su programación.

El runtime funciona como conexión entre la información que proporciona el hardware de Kinect y las diferentes APIs. Con esto es posible soportar una gran gama de lenguajes de programación en donde sólo necesitamos interactuar con esta capa.

En el nivel más alto se construyen las APIs, por lo que se logra tener una para cada tipo de desarrollo: apps desktop nativas o con .NET, o apps para Windows Store utilizando WinRT y lenguajes de programación como C#, Visual Basic, JavaScript y C++ con XAML.

Desarrolla tu primera aplicación con Kinect utilizando C# y Visual Studio

Lo primero es crear un proyecto en Visual Studio. Se elige la plantilla en blanco de Windows Store App y le asignamos un nombre.

Una vez que se ha generado el proyecto, en el explorador de soluciones hacemos clic derecho en la solución que acabamos de crear y seleccionamos Properties. En la ventana que se abre, elegimos Configuration Properties y cambiamos la plataforma de compilación a x86. Ver Figura 3.

Figura 3. Plataforma de compilación

Ahora necesitamos agregar la referencia de Kinect a nuestro proyecto. Hacemos clic derecho sobre la carpeta de References y enseguida Add Reference. Dentro de la ventana que abre, seleccionamos en Windows 8.1 la opción de Extensions y elegimos KinectPreview.Kinect. Ver Figura 4.

Figura 4. Referencia de Kinect a nuestro proyecto

El último cambio que debemos hacer a la configuración de nuestro proyecto es habilitar las capacidades de la aplicación. Abrimos el archivo Package.appxmanifiest y en la pestaña Capabilities seleccionamos Microphone y Webcam.

Figura 5. Habilitar capacidades de micrófono y webcam

Ahora comenzaremos a programar la aplicación. Abrimos el archivo MainPage.xaml para agregar una imagen dentro del Grid donde se mostrará la información de la cámara infrarroja.

<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}"> <Image Name="image" Width="512" Height="424"></Image> </Grid>

En el MainPage.xaml.cs definimos las bibliotecas que usaremos para el manejo de la imagen y los datos de Kinect.

using Windows.UI.Xaml.Media.Imaging; using WindowsPreview.Kinect;

A continuación se declaran los objetos que utilizaremos: un objeto KinectSensor para comunicarnos con el Kinect; InfraredFrameReader y un arreglo de ushorts para leer los datos del infrarrojo y guardarlos respectivamente; un arreglo de bytes para almacenar el color de cada pixel de la imagen que pondremos en un objeto WriteableBitmap.

KinectSensor sensor; InfraredFrameReader irReader; ushort[] irData; byte[] irDataConverted; WriteableBitmap irBitmap;

Dentro del constructor, agregamos un método al evento Loaded de la clase.

public MainPage() { . . . this.Loaded += MainPage_Loaded; }

En el método MainPage_Loaded creamos una nueva instancia del sensor, una instancia para el lector de infrarrojo y un objeto FrameDescription que nos permita saber la longitud en pixeles de la información infrarroja. Con este dato, inicializamos el arreglo de ushorts y el arreglo de bytes multiplicándolo por cuatro para almacenar la información en formato RGBA.

Para la inicialización del mapa de bits usamos el ancho y el alto de la imagen que se captura con la cámara infrarroja. Ligamos la fuente de la imagen del xaml con nuestro mapa de bits para poder actualizarla con los datos del sensor. Se abre la instancia del sensor Kinect para usarse, y por último hacemos el vínculo del método al evento FrameArrived que se ejecutará cada vez que un cuadro de la imagen sea recibido.

void MainPage_Loaded(object sender, RoutedEventArgs e) { sensor = KinectSensor.GetDefault(); irReader = sensor.InfraredFrameSource.OpenReader(); FrameDescription fd = sensor.InfraredFrameSource.FrameDescription; irData = new ushort[fd.LengthInPixels]; irDataConverted = new byte[fd.LengthInPixels*4]; irBitmap = new WriteableBitmap(fd.Width, fd.Height); image.Source = irBitmap; sensor.Open(); irReader.FrameArrived +=irReader_FrameArrived; }

Dentro del nuevo método obtenemos el cuadro de la imagen del infrarrojo mediante el parámetro args utilizando FrameReference.AcquireFrame(). Verificamos si el InfraredFrame es distinto de nulo; si lo es, copiamos su información al arreglo de ushorts irData, iteramos sobre el arreglo y por cada dato realizamos un corrimiento de bits para obtener el byte más significativo. Con esto asignamos una intensidad que permitirá realizar una imagen a escala de grises dentro del arreglo irDataConverted, dejando el canal alfa en 255 para tener una imagen opaca. Finalmente, copiamos el arreglo de bytes resultante al PixelBuffer de irBitmap e invalidamos la información forzando la aplicación a redibujar la imagen en nuestra app.

void irReader_FrameArrived(InfraredFrameReader sender, InfraredFrameArrivedEventArgs args) { using (InfraredFrame irFrame = args.FrameReference.AcquireFrame()) { if (irFrame != null) { irFrame.CopyFrameDataToArray(irData); for (int i = 0; i < irData.Length; i++) { byte intensity = (byte)(irData[i] >> 8); irDataConverted[i * 4] = intensity; irDataConverted[i * 4 + 1] = intensity; irDataConverted[i * 4 + 2] = intensity; irDataConverted[i * 4 + 3] = 255;//alfa } irDataConverted.CopyTo(irBitmap.PixelBuffer); irBitmap.Invalidate(); } } }

Estamos listos para ejecutar la aplicación en la máquina local y ver nuestra aplicación. La app mostrará en pantalla el flujo de datos que el sensor infrarrojo del Kinect está obteniendo, tal como se muestra en la figura 6.

Figura 6. App ejecutándose

El proyecto completo de Visual Studio con este ejemplo y contenido extra se encuentra disponible para descarga en http://swgu.ru/tutorial-kinect

Referencias

Channel 9: Programming Kinect for Windows V2 http://channel9.msdn.com/Series/Programming-Kinect-for-Windows-v2
MSDN: Kinect for Windows SDK http://msdn.microsoft.com/en-us/library/dn772637.aspx

Bio

Laura Frias Carrillo (@lauriutz) es Technical Evangelist en el equipo de Divulgación Tecnológica en Microsoft México. Se especializa en el desarrollo de apps para Windows Phone, Windows 8 y Kinect para Windows. Laura es orgullosa egresada de la Facultad de Ciencias, UNAM. http://blogs.msdn.com/b/laurafrias

Conociendo Docker

sg — Fri, 19 Sep 2014 23:13:16 +0000

Conociendo Docker sg Fri, 09/19/2014 - 18:13

Publicado en

SG #45

Novedades

Autor

Borja Burgos

Docker, hoy en boca de todos, nació en Marzo de 2013 como un proyecto “open source” de dotCloud, startup que por aquel entonces era un proveedor de PaaS al estilo de Heroku. En tan solo 18 meses Docker se ha convertido en uno de los proyectos más populares en GitHub. El proyecto ha sido tan exitoso, que dotCloud mismo pasó a llamarse Docker, Inc. y en Junio de 2013 organizaron la primera conferencia DockerCon en San Francisco con el apoyo de compañías como Google, RedHat o Rackspace.

Pese a todo esto, todavía existe mucha confusión acerca de qué exactamente es Docker, qué aporta sobre tecnologías existentes, la razón de su éxito, y lo más importante, por qué lo necesitamos y cómo va a cambiar nuestra manera de desarrollar, construir, probar y desplegar nuestras aplicaciones de software.

Contenedores: un concepto simple

Docker es, en esencia, un intento exitoso por estandarizar la tecnología de contenedores de Linux de la que hemos gozado en los últimos años. Para explicar lo que es un contenedor de software, el equipo de marketing de Docker acostumbra usar la analogía de un contenedor de mercancías. Pero dado el perfil de la audiencia de SG, tal vez resulte más familiar para todos nosotros pensar en otra analogía: la máquina virtual. Si pensamos que el sistema operativo que se ejecuta dentro de una máquina virtual está siendo “engañado” para que piense que corre en su propio hardware, entonces la analogía resulta sencilla. Una aplicación o proceso que corre dentro de un contenedor también está siendo “engañado” para pensar que corre dentro de su propio sistema operativo. Al igual que con las máquinas virtuales, donde el hardware que el sistema operativo “ve” no tiene por qué ser el mismo que el hardware que existe en la realidad, un contenedor puede “ver” un sistema operativo distinto al del sistema operativo donde se está ejecutando. Cabe destacar que, pese que existen similitudes entre ambos, un contenedor resuelve cuellos de botella de software, mientras que una máquina virtual resuelve cuellos de botella de hardware. Ambos son complementarios, y no excluyentes.

¿Y qué tipo de problemas resuelven los contenedores? Seguro que todos en algún momento de nuestras carreras nos hemos topado con el problema de una aplicación que corre satisfactoriamente en un servidor (virtualizado o no), pero se comporta erráticamente en otro. O el código de un desarrollador, que funciona en su computadora, pero luego falla cuando lo mandamos al entorno de “staging” o producción. Esto se debe a que dos copias exactas de una misma aplicación se comportan de manera distinta en dos entornos con configuraciones distintas. La falta de una dependencia, como una librería, o que exista pero con una versión distinta, o que una variable de entorno sea distinta, o incluso que la versión del sistema operativo varíe puede ocasionar que nuestra aplicación deje de funcionar correctamente. Docker resuelve este problema de manera elegante, con Docker empaquetar aplicaciones en contenedores autosuficientes es una tarea sencilla. Una vez que tenemos la aplicación en un contenedor, desplegarla es una operación rápida y ligera, independientemente del tipo de servidor, del sistema operativo (sólo Linux, eso sí), o del proveedor de infraestructura que utilicemos. Y porque la aplicación, configuración y todas sus dependencias están “contenidas” en el contenedor, dejamos de preocuparnos por versiones y configuraciones de librerías, sistemas operativos, servidores de aplicaciones, etcétera. Se podría decir que desplegar una aplicación con Docker es análogo a instalar una aplicación móvil en un celular corriendo Android o iOS. La instalación es trivial para el usuario. Una vez desplegado el contenedor, las aplicaciones exponen servicios e interfaces al sistema operativo y a otras aplicaciones que deseen hacer uso de ellas. Las aplicaciones que corren dentro de un contenedor quedan a su vez aisladas del sistema operativo donde corren.

Un ecosistema en crecimiento

Además de las herramientas y la tecnología “open source” que facilitan a desarrolladores y administradores el empaquetar y desplegar sus propias aplicaciones, Docker, Inc. también ha lanzado un servicio online llamado Docker Hub (http://hub.docker.com). Éste se está convirtiendo en un repositorio público de aplicaciones open source. Al día de hoy cuenta con más de cien mil imágenes públicas. Por ejemplo, en Docker Hub encontraremos imágenes de aplicaciones populares como bases de datos MySQL, PostgreSQL, MongoDB, ... o aplicaciones CMS (Content Management System) como Wordpress, Drupal o Joomla. Es gracias a este repositorio de imágenes públicas que instalar una aplicación open source en nuestro servidor es tan sencillo como instalar una aplicación en nuestros celulares.

Sin lugar a dudas, el elevado número de beneficios y las casi inapreciables desventajas de utilizar contenedores para nuestras aplicaciones harán que esta tecnología se convierta en el estándar a la hora de empaquetar y desplegar nuestras aplicaciones en la nube. Conoce más sobre Docker en https://www.docker.com

Bio

Borja Burgos (@borja_burgos) es un emprendedor, ingeniero y hacker que disfruta diseñar y construir soluciones para problemas nuevos y existentes. Actualmente es CEO de Tutum, empresa proveedora de servicios de hosting para contenedores Docker. https://www.tutum.co

APIs: Construyendo una Nueva Era

sg — Fri, 19 Sep 2014 23:06:12 +0000

APIs: Construyendo una Nueva Era sg Fri, 09/19/2014 - 18:06

Publicado en

SG #45

APIs

Autor

Gustavo Alzate

Cada vez más vemos como la tendencia a exponer APIs (application programming interface) aumenta en todo tipo de organizaciones. Hoy en día el uso e implementación de APIs representa un nuevo canal de producto para llegar a muchas personas, ya que los aPIs facilitan el aprovechamiento de datos o servicios existentes. En base a esto surge una buena pregunta: ¿Sólo yo uso y expongo mi información o debería permitir que terceros externos puedan usarla? un ejemplo claro de esto pueden ser grandes compañías como Facebook y Twitter, quienes reportan un alto uso diario de sus APIs expuestas, y que sin lugar a duda se convierten en gran parte de su total difusión y uso. Y no es para menos en una era en la cual abundan gran cantidad de dispositivos que requieren consumir un API de una forma sencilla.

No solo se trata a de crear un API que exponga mi información, esto va mucho más allá. Entre otras cosas hay que definir: a qué tipo de público va dirigida, que consideraciones debo tener para diseñarla, qué consideraciones de disponibilidad debo tener y también cómo voy a promocionarla. Las organizaciones líderes ven a sus APIs como una herramienta estratégica de negocio. Y no es para menos, si según cifras de Twitter y Facebook indican que el consumo de sus APIs expuestas da cada vez más tráfico, posicionamiento e ingreso a sus marcas.

Es por esto que podemos decir que nos encontramos en el inicio de una nueva era en el Internet: “La era de las APIs”. A decir verdad podemos demarcar tres importantes eras en torno a la web, como dice uno de los más famosos bloggers del mundo Robert Scoble en uno de sus artículos [2]:

Web 1994: “Dame un dominio y una página”.
Web 2000: “Haz mis páginas interactivas y con usuarios”.
Web 2010: “Elimina las páginas y conecta a las personas por medio de APIs”.

Y es entonces en la era actual, dónde es tan importante pensar en construir un API que exponga mi información, y pensar luego: “he ahí el poder de habilitar a la comunidad para que exponga tu información y no solo seas tú quien lo haga”. Y más allá de convertirse en un valor agregado, tener un API se convierte en una necesidad, ya que si el mercado cambia y nuestros clientes cambian, nosotros debemos hacer lo mismo. Así que si tienes dudas sobre si necesitas un Api o no, te invito a que te respondas las siguientes preguntas:

¿Sus clientes o socios le han preguntado por un API?
¿Necesita usted crear una aplicación móvil en diversas plataformas?
¿Necesita usted mayor flexibilidad para exponer su contenido?
¿Tiene usted datos que pueden ser expuestos?
¿Su competencia directa usa un API?
¿Quiere usted escalar la integración e interacción con sus socios y clientes?

Son preguntas sencillas que pueden definir si se necesita de un API o no. En mi opinión en la mayoría de los casos obtendremos un sí como respuesta.

Y a pesar de ver ahora la necesidad de exponer un API e iniciar con la construcción de la misma, no es tarea fácil plantear una estrategia que ayude a que esta API tenga éxito. Hay que considerar distintos actores y puntos de vista que pueden intervenir en este proceso: el dueño del producto a nivel negocio, el equipo de desarrollado que lo construye apoyándose en tecnologías como REST, el usuario que lo utiliza para generar nuevos productos y servicios, y el equipo que soporta la infraestructura de cómputo desde donde se ofrece el API que debe asegurarse de poder soportar la carga de uso requerida, así como picos de uso, sincronización y respaldo de datos, etcétera.

REST, facilitando el uso y consumo de APIs

De acuerdo con programmableweb.com (un sitio con noticias y contenidos relacionados con las APIs), el 70% de las APIs en la actualidad usan estilo de arquitectura REST (Representational State Transfer). El papel que juega REST en la era de las APIs es fundamental, ya que en la actualidad la mayoría de APIs están basadas en esta filosofía, y por lo tanto se ha convertido en el estándar de facto (una de las alternativas es SOAP, que es mucho menos utilizado).

El estilo de arquitectura REST se basa en los siguientes principios:

Facilidad de uso.
Consumo desde múltiples dispositivos.
APIs ligeras y sencillas.

Y esto ha vuelto mucho más fácil la tarea de crear cada vez mejores APIs para exponer al público, tanto para los propietarios de las APIs como para los desarrolladores que las implementan, ya que siempre se busca garantizar las características mencionadas anteriormente en un API para lograr su éxito y adecuado uso.

Las tecnologías web mutan y cambian para suplir necesidades a los variables usuarios y tendencias, la era actual de la web está basada en el uso de las Apis, es una realidad y un presente, ¿solo tu administras y compartes tu información?, o ¿muchas personas más pueden hacerlo?

Referencias

[1] D. Jacobson, G. Brail, D. Woods. APIs: a strategy guide. O’Reilly Media.
[2] R. Scoble.”Why if you miss Siri you’ll miss the future of the web”.
[3] “Representational State Transfer”. Wikipedia.

Bio

Gustavo Alzate Sandoval trabaja en Visión Travel como Líder de Proyecto. Su especialidad es el desarrollo de software. Es conferencista, entrenador y consultor. Pertenece a la comunidad Avanet y es Microsoft Community Specialist. gustavoalzatesandoval@gmail.com @ElTavoDev http://www.eltavo.net

APIs de Redes Sociales

sg — Fri, 19 Sep 2014 22:21:21 +0000

APIs de Redes Sociales sg Fri, 09/19/2014 - 17:21

Publicado en

SG #45

APIs

Autor

Como todos sabemos, las redes sociales crecen día a día y poseen información tanto personal, como de opiniones de los usuarios que las utilizan.

Con el fin de conocer dicha información para fines específicos y de promocionar marcas y servicios, actualmente muchas aplicaciones están siendo diseñadas de tal forma que tengan la capacidad de establecer una conexión con el API (Application Programming Interface) de dichas redes.

Para establecer dicha conexión, se debe seguir un proceso de autenticación y autorización de permisos mediante la implementación del protocolo oAuth (Open Authentication). Este protocolo permite que un usuario conceda acceso a un tercero (proveedor de servicio o aplicación) para que acceda a sus datos, sin tener que proporcionarle su usuario y contraseña.

En dicho proceso y al momento en que el usuario concede permisos a la aplicación, la red social proporciona un “token” que deberá ser guardado por dicha aplicación para poder realizar peticiones en nombre del usuario, tales como leer información personal, intereses, contactos o publicar nueva información.

La interacción entre las redes sociales y la aplicación es realizada mediante peticiones enviadas sobre el protocolo HTTPS. Dependiendo de la acción que se desee realizar pueden usarse peticiones de tipo GET, POST, PUT o DELETE. Todas las peticiones, independientemente si son para leer, escribir, editar o eliminar información, deben de incluir el “token” de acceso por medio del cual se valida la petición y se acepta o se rechaza de acuerdo a los permisos otorgados por el usuario. Es recomendable que el “token” de acceso sea enviado dentro del encabezado de las peticiones, sin embargo, también puede ser enviado como parámetro en la URL, ya que es protegido por el mismo protocolo HTTPS.

En seguida mencionaremos a modo personal y de acuerdo a nuestra experiencia, algunas características que hemos notado acerca de la API de Twitter, Facebook, YouTube e Instagram.

Twitter

Twitter es una de las redes sociales que por su naturaleza no hay muchas rescricciones de privacidad, es decir, la gran mayoría de usuarios tiene público su perfil y por lo tanto también sus tuits. Por esta razón, Twitter permite el acceso a toda esta información a través de su API. Las restricciones con las que se encuentran los desarrolladores es que existen límites de peticiones en un periodo de tiempo, es decir, existen intervalos de 15 minutos en donde se puede hacer un número máximo de peticiones. Cabe mencionar que estos límites son por usuario, no por aplicación, de esta forma cada usuario es controlado de forma independiente. Dependiendo del tipo de recurso que sea solicitado, existen dos tipos de restricciones principales: 15 peticiones cada 15 minutos y 180 peticiones cada 15 minutos. Adicionalmente, no se permite recuperar información histórica, es decir, si se ejecuta una búsqueda sólo es posible obtener información generada 7 días atrás como máximo.

En caso de exceder el número máximo de peticiones en un periodo de tiempo, se obtiene un código de respuesta en donde se provee información acerca del recurso restringido temporalmente y el tiempo de espera para que el recurso se encuentre nuevamente disponible. Otra particularidad de Twitter, es que cuenta con streaming, lo que permite obtener información en tiempo real sin restringir el número de peticiones por un periodo de tiempo. La versión actual del API de Twitter es la 1.1.

Facebook

En el caso de Facebook, por todas las restricciones de privacidad que protegen la información del usuario, no es posible acceder a datos protegidos a menos que ambos usuarios tengan una relación de ‘amistad’ en la red social. En caso contrario sólo puede obtenerse acceso sin restricción al nombre y al género de los usuarios. Sin embargo, si un usuario da consentimiento explícito a que un tercero acceda a su información de perfil, correo electrónico, gustos, intereses, amigos, eventos, datos de amigos, entre otros más; entonces la aplicación prácticamente no tendrá restricciones para ese usuario en particular.

El acceso a los mensajes públicos en Facebook es mediante su Open Graph que soporta también peticiones utilizando el Facebook Query Language. Facebook no tiene documentado el número máximo de peticiones en un periodo de tiempo o si las restricciones son por usuario, aplicación, dirección IP o la combinación de estos, sin embargo, si continuamente se envían peticiones hacia un recurso específico, con el tiempo se aprecia que se empieza a obtener menos información acerca del mismo.

Facebook cuenta con actualizaciones en tiempo real, con esto es posible subscribirse a ciertos recursos, como el muro de un usuario, y recibir notificaciones si hay cambios. Esta funcionalidad evita estar haciendo peticiones de forma periódica. Actualmente el Open Graph se encuentra en la versión 2.0 y de acuerdo a la documentación oficial de la misma, ya no será posible acceder a los mensajes públicos que actualmente están disponibles en su versión 1.0.

YouTube

En el caso de YouTube el acceso a los datos por medio de su API es muy similar a Twitter dado que los videos están disponibles públicamente. Las restricciones de acceso no son medidas por intervalos cortos de tiempo donde se permite un número máximo de peticiones, sino que es controlado por día. YouTube asigna diariamente un número de ’Unidades’ para cada aplicación (no es por usuario) y cada operación que se realiza tiene un costo de esas unidades, por ejemplo, subir un video representa el uso de mil 600 unidades que son restadas del total disponible del día.

Ahora bien, cuando se requiere realizar una búsqueda de videos, YouTube tiene una restricción que permite recuperar un máximo de 500 videos por búsqueda y no tiene una restricción de temporalidad, es decir, pueden recuperarse videos que fueron subidos recientemente o de meses atrás. Si la búsqueda devuelve más de 500 videos, YouTube sugiere que se utilicen otros criterios de búsqueda para refinar los resultados y de esta forma obtener la información deseada.

YouTube hace uso principalmente de XML para compartir sus datos y para enviar respuestas o mensajes de error, sólo algunos recursos pueden ser configurados para que la respuesta sea devuelta en formato JSON. La versión actual del API de YouTube es la 3.0.

Instagram

Instagram cuenta con una API con mayores limitantes desde el punto de vista de interacción, dado que a diferencia de las redes sociales descritas anteriormente, con Instagram no es posible subir contenido, esta acción solamente es permitida mediante su aplicación oficial. De forma adicional, se tiene una restricción de 5 mil peticiones por hora por “token” de acceso.

El API de Instagram solamente permite realizar búsquedas sobre mensajes que contengan etiquetas que existan en la red social. Este tipo de búsqueda se realiza sobre los mismos mensajes y sobre sus comentarios.

Comparación

Una de las redes sociales con más flexibilidad para obtener información es Twitter, dado que la información es en su mayoría pública y su API proporciona facilidades para ejecutar sin restricciones un gran número de acciones, por ejemplo, marcar un “tuit” como favorito o retuitearlo, seguir o dejar de seguir a un usuario, ver los mensajes de cualquier usuario que no tenga privado su perfil, entre otros más. Adicionalmente su “streaming API” es una ventaja sobre las demás redes sociales dado que provee información en tiempo real sin tener que subscribirse a un recurso como lo hace Facebook.

En el caso de Facebook existe mucha más información alrededor de los usuarios, como sus gustos, intereses, edad, escolaridad, y aunque toda esta información no es pública, es usada para el envío de publicidad dirigida hacia públicos muy específicos mediante su API de anuncios. Una desventaja de Facebook es que su búsqueda no ofrece la posibilidad de utilizar operadores lógicos para realizar búsquedas, a diferencia de Twitter que soporta: OR, AND, NOT y búsqueda en cuentas específicas.

El API de YouTube cumple bien sus funciones, sin embargo, tiene limitantes muy restrictivas dado que sólo pueden recuperarse como máximo 500 videos en una búsqueda y los operadores lógicos que proporciona (AND y OR) no funcionan de forma óptima en todos los casos. De forma adicional, a diferencia de las redes sociales anteriores, es necesario renovar su “token” de acceso de forma periódica.

Por último, la red social cuya API tiene más restricciones a nuestro parecer es Instagram, dado que no es posible publicar nuevo contenido o realizar comentarios sobre los mensajes existentes, básicamente sólo es posible leer información. Las búsquedas no contemplan el uso de operadores lógicos, y el término de búsqueda tiene que ser necesariamente una etiqueta válida existente en dicha red para que se obtengan resultados exitosos.

Experiencia y uso específico

En INFOTEC hemos estado desarrollando un nuevo producto al que denominamos SWB Social, el cual se conecta a las redes sociales mediante las técnicas aquí descritas. También es posible conectarse y explotar la información de más redes sociales en un tiempo relativamente rápido.

SWB Social escucha y entiende opiniones acerca de una organización, sus productos y servicios e inclusive de su competencia, identificando en la información sentimientos, influencia, geolocalización e idioma, entre mucha más información relevante que ayuda a tomar decisiones para mejorar los productos y servicios de una organización.

SWB Social es una herramienta que INFOTEC está liberando como open source, tal como lo ha venido haciendo con otros productos, como apoyo a las organizaciones e industria de TI en México. Conoce más en http://www.semanticwebbuilder.org.mx/SWBSocial

Bio

Francisco Jiménez Hernandez es desarrollador Sr. en INFOTEC desde hace 3 años. Ha trabajado como desarrollador en la Gerencia de Nuevos Productos y Servicios, dando mantenimiento a la herramienta Open Source de SemanticWebBuilder. Actualmente sus funciones como Coordinador de Desarrollo involucran la definición de funcionalidades de un nuevo producto de la familia SemanticWebBuilder denominado SWB Social.

Jorge Alberto Jiménez Sandoval es consultor Sr. en INFOTEC con 15 años de experiencia en arquitectura y desarrollo de productos de software, basados muchos de ellos en Web Semántica, mediante modelado ontológico de datos. Arquitecto y desarrollador líder de SWB Social.

Criptografía y Seguridad: Bibliotecas y prácticas

sg — Fri, 19 Sep 2014 22:13:34 +0000

Criptografía y Seguridad: Bibliotecas y prácticas sg Fri, 09/19/2014 - 17:13

Publicado en

SG #45

Programar es un Estilo de Vida

Autor

Gunnar Wolf

El pasado mes de julio tuve nuevamente la oportunidad de participar en el congreso anual que organiza SG, presentando la conferencia Desarrollo de software y criptografía [1]. Me doy cuenta que, si bien su relevancia resulta clara y hay interés en la comunidad de desarrolladores por comprenderlo, el tema de la criptografía es visto por muchos como un tema casi mágico o místico: Hay unos pocos expertos, pero está fuera del alcance para el común de nosotros, los simples desarrolladores que carecemos de un sólido conocimiento matemático de fondo.

Y sí, no puedo negarlo: El uso correcto de la criptografía requiere de darse una pequeña zambullida en un mar de conceptos nuevos. Sin embargo, me da gusto ver que estamos cada vez más conscientes de la importancia de proteger los datos de nuestras aplicaciones, tanto como sea posible, por criptografía fuerte. Aquí aparece la primer tensión que abordo: ¿Cómo responder a las necesidades de seguridad de información sin tener un sólido conocimiento matemático en cuestiones de criptografía?

Afortunadamente, en ese punto es donde aparece el hilo conductor con el tema de la presente edición de SG: La era de las APIs: Hay varias bibliotecas criptográficas ampliamente disponibles, implementando los diferentes algoritmos y modos de operación. Y no es necesario implementar los protocolos criptográficos, sino únicamente llamar a las funciones indicadas de la biblioteca de nuestra elección.

Y, claro, el hablar de estas principales implementaciones también da pie a abordar del impacto de los no pocos ni triviales problemas que han aquejado a este campo en los últimos meses. Y sí, aunque probablemente muchos asocien en principio al término API con las interfaces presentadas por servicios en la nube como las redes sociales, en realidad toda biblioteca que empleemos para el desarrollo (incluyendo las bibliotecas estándar, parte de la definición de nuestro lenguaje) expone una interfaz de programación de aplicaciones.

Claro está, estamos viviendo en la era de las APIs — Desde hace más de 60 años.

Criptografía: ¿Para qué?

La criptografía nos brinda distintas herramientas para proteger nuestra información — Y si partimos de que la información es el activo más valioso de todos nuestros sistemas, resulta obvio que la criptografía es uno de nuestros mayores aliados.

Si bien la criptografía es casi tan vieja como la escritura misma, apenas fue abordada como una disciplina científica matemática a partir de mediados del siglo XX. El objetivo esencial de la criptografía es brindar confidencialidad a a información valiosa. Sin embargo, hoy en día la confidencialidad representa sólo una de las propiedades de la información que la criptografía nos permite asegurar.

La segunda propiedad que protege la criptografía es la integridad: Partiendo de un texto origen arbitrariamente largo, las llamadas funciones digestoras calculan su hash, una cadena de longitud fija con la propiedad fundamental de ser muy dificil encontrar otro texto que genere la misma salida. Esta definición de integridad posiblemente deje a más de uno insatisfecho. Y sí, por sí sola no sirve para garantizar gran cosa… pero la tercer propiedad hará clara su utilidad.

Hasta mediados de 1970, todos los esquemas de criptografía dependían de una llave única: el equivalente a una contraseña que permitía tanto convertir un texto claro en una representación ininteligible como manipular a dicha representación para obtener de vuelta al texto claro. Entre el breve lapso comprendido 1976 y 1980, el mundo de la criptografía cambió por completo: nació la criptografía de llave pública, con los principales protocolos que siguen siendo utilizados al día de hoy. Esencialmente, en vez de manejar una sola llave, se descubrieron varias funciones matemáticas que permiten llaves compuestas de dos mitades: una privada, que cada individuo debe custodiar celosamente, y una pública, que puede ser ampliamente distribuida. Estas dos llaves actúan como inversas: lo que se cifra con una sólo puede descifrarse con la otra.

Este hecho, que parecería una mera curiosidad, permitió la creación de mecanismos para proteger las tercera propiedad de la información: la autenticación. Si un mensaje cifrado por mi llave privada puede ser descifrado por cualquiera que conozca mi llave pública, y existen directorios de llaves públicas, este mensaje sólo puede haber sido generado por mí.

Ya con estos antecedentes, ¿qué es la cadena que aparece en todas las facturas electrónicas y ocasionalmente incluso en los correos electrónicos? Tomando un texto origen, se obtiene su hash, y se firma con la llave privada del emisor. ¡Listo! Una firma electrónica con un tamaño constante, estableciendo una relación no repudiable entre un documento y su emisor.

Partiendo de distintas formas de emplear estas tres propiedades pueden derivarse otros varios patrones de validación de documentos; este es sólo el más común y sencillo de muchos de los patrones de uso de criptografía.

Pero… ¿Se puede confiar en la criptografía?

Al hablar de la integridad, mencioné que debía ser muy difícil encontrar dos textos que produzcan el mismo resultado. A pesar de que el término puede no inspirar mucha confianza, sin embargo, debe leerse no como algo que intuitivamente (y sin ser especialista) me parezca difícil, sino definido desde la teoría de la complejidad computacional: computacionalmente difícil significa que es sumamente resistente a ser atacada por búsqueda exhaustiva (o lo que es lo mismo, por fuerza bruta); idealmente, la complejidad crece de forma exponencial con el espacio de búsqueda.

Por ejemplo: un algoritmo de cifrado simétrico ampliamente utilizado como el AES puede operar con llaves de 128 a 256 bits. Esto significa que, con una llave de 128 bits, el espacio de búsqueda es de 2128 (del orden de 1038) posibilidades. Si tuviéramos poder de cómputo suficiente para intentar decodificar un billón de llaves por segundo, una búsqueda exhaustiva tomaría sólo 719 millones de veces la edad del universo. En contraste (e ilustrando el crecimiento exponencial), una llave de 64 bits tomaría sólo 213 días.

Los algoritmos que se han desarrollado, es cierto, no son perfectos. Por ejemplo, Alex Biryukov y Dmitry Khovratovich presentaron en 2009 un artículo [2] detallando un tipo de análisis permitiendo reducir dramáticamente (a sólo unas decenas de veces la edad del universo según nuestro cálculo) el espacio de búsqueda. La búsqueda de debilidades en algoritmos criptográficos es un campo vibrante de investigación matemática, con muchos talentosos académicos buscando cómo ganarle un bit más, un pasito más. De encontrarse alguna debilidad, aparecerá sin duda publicada en las más importantes revistas académicas del ramo.

Bibliotecas criptográficas

Pero, dado que nuestro campo es el desarrollo de sistemas y no la criptografía desde un punto de partida matemático, recordemos que hay una gran regularidad entre los parámetros que requieren los diferentes algoritmos. Si empleamos una biblioteca de funciones criptográficas, como la muy conocida OpenSSL, y un algoritmo ampliamente utilizado es descubierto como vulnerable, hacer el cambio para emplear otro algoritmo resultará casi trivial.

Por otro lado, me permito citar la máxima de Adi Shamir, uno de los padres de la criptografía moderna:

La criptografía normalmente es evadida, no penetrada.

Decenas de productos han implementado soluciones criptográficas (generalmente basadas en el firmado) en los últimos años, sólo para encontrar que su mecanismo fue roto al muy poco tiempo de salir al mercado [3]. Todos estos ejemplos derivan de un uso incorrecto de la criptografía: Para hacer un jailbreak, el atacante burla la llamada a la función criptográfica, aprovechando un error de programación para secuestrar el flujo antes de que se lleve a cabo la validación.

Y antes de cerrar esta columna: mencioné a la popular biblioteca OpenSSL. A más de uno de ustedes debe haberle sonado una alarma: ¿En serio está recomendando OpenSSL? ¿Después de Heartbleed?[4] Sí, sí lo recomiendo. Vamos paso por paso.

OpenSSL es la biblioteca criptográfica por excelencia, y su principal fuerza es también su principal desgracia: es una biblioteca con 20 años de historia, y profundamente multiplataforma. Vamos, su herencia multiplataforma ha mantenido el soporte para arquitecturas que desde hace años son consideradas obsoletas, como VMS u OS/2. Además, el estilo del código es de muy difícil comprensión —los desarrolladores justifican esto puesto que, siendo la criptografía tan demandante de recursos de cómputo, se vieron orillados a tomar decisiones motivados más por el rendimiento que por la claridad.

Como sea, el fallo conocido como Heartbleed expuso lo inadecuadas que dichas prácticas son hoy en día. Sin embargo, y analizando el fenómeno desde la perspectiva de un promotor del software libre, la respuesta de la comunidad ha sido de lo más interesante: por un lado, la Linux Foundation (a través de su Core Infrastructure Initiative) está fondeando una auditoría del código de OpenSSL. Y por otro lado, surgieron dos proyectos derivados de OpenSSL, buscando corregir sus defectos de formas más radicales, aunque signifique romper la compatibilidad a nivel API: LibReSSL [5], del equipo de sistema operativo OpenBSD, y BoringSSL [6], de Google. ¿Por qué BoringSSL? En palabras de Shawn Wilden:

Los componentes fundamentales de seguridad deberían ser muy aburridos. No son el lugar para innovar y experimentar, (ni) para el código que demuestra el virtuosismo del autor. Son donde quieres implementaciones simples, directas y aburridas de los algoritmos y protocolos. Cuando se habla de seguridad, lo aburrido es bueno.

Que Heartbleed fue un fallo nefasto nadie lo pone en duda. Sin embargo, ante estos fallos siempre es interesante ver la reacción de las comunidades de desarrolladores. Al igual que cuando otros fallos severos, Heartbleed ha llevado a los desarrolladores (al menos dentro de las comunidades de software libre, cuyo código y cuyas discusiones son claramente visibles desde fuera) a iniciar auditorías y replantearse prácticas que seguramente redundarán en el avance global de la calidad del software.

Referencias

[1] http://gwolf.org/desarrollo_y_criptografia
[2] http://eprint.iacr.org/2009/317
[3] La excelente presentación Crypto won’t save you either, disponible en http://regmedia.co.uk/2014/05/16/0955_peter_gutmann.pdf, presenta más de 20 casos.
[4] ¿No supiste acerca de la vulnerabilidad de seguridad más publicitada por lo menos en este lustro? http://heartbleed.com
[5] http://www.libressl.org
[6] https://www.imperialviolet.org/2014/06/20/boringssl.html

Bio

Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM y desarrollador del proyecto Debian GNU/Linux. http://gwolf.org