SG Software Guru #49

SG SOFTWARE GURU

TUTORIAL

DEPURACIÓN CON ANDROID WEAR PAG. 12

—

MAKER ZONE

NO.49

GUÍA PARA MAKERS PRIMERIZOS CONOCIMIENTO EN PRÁCTICA www.sg.com.mx

STARTUPS EN LATINOAMÉRICA PAG. 08

—

ESTIMACIÓN DE SOFTWARE PAG. 28

—

USER EXPERIENCE DESIGN

48 | DICIEMBRE 49 OCTUBRE 2015 2015 - ENERO 2016

PAG. 38

ENCUESTA DE SALARIOS 2015

PAG. 48

SG.COM.MX

001

NO.49

CONOCIMIENTO EN PRﾃ，TICA www.sg.com.mx

EN PORTADA

ESTUDIO DE SALARIOS 014

Conoce cuﾃ｡nto gana un desarrollador de software en nuestra regiﾃｳn y cuﾃ｡les son las habilidades mejor pagadas.

002

SG.49

CONTENIDO

I

¿Cuál es el Camino para el Éxito de las Startups en Latinoamérica?

T

P

INDUSTRIA Y EMPRESAS 008

HERRAMIENTAS Y TECNOLOGÍAS

Radar Depuración con Android Wear Guía para Makers Primerizos

010

C

PRÁCTICAS

H

COLUMNAS

Estimación de software con COSMIC

028

Tendencias en Software

Site Reliability Engineering

030

Prueba de software

044 046

Arquitectura: Smart Decisions

034

Programar es un Modo de Vida

Actividades UX para Disolver Controversias

038

Cuadrados Mágicos y Recursión

042

V

012

011

Más allá del Software

R

FUNDAMENTOS

Pura Felicidad con Funciones Puras

053

022

La Fuerza de los Bootcamps

024

EN CADA NÚMERO

Noticias y eventos

005

Hardware

054

Humor

055

Biblioteca

056

026

048

F

HUMANOS DESPUÉS DE TODO

La Paradoja del Software y los Malditos Programadores

O

VOCES

O

REPORTAJE

Tendencias sobre Talento en TI

023

EMPRENDIMIENTO 008

SG.COM.MX

003

O

EDITORIAL

Lo mejor para el 2016

Conforme cerramos este año, en SG estamos contentos por haber enfrentado nuevos retos con éxito. Como parte de nuestro continuo esfuerzo por apoyar el talento en México, este año realizamos distintas actividades y concursos para desarrolladores y makers. De la mano de marcas como Intel y Cisco trabajamos en conjunto para convocar, desarrollar procesos, reglas y premiación para estas actividades que sin duda ayudan a conectar a la industria con talento, grandes ideas y proyectos.

Para el próximo año continuaremos con nuestros eventos: Mobile Day, SG Virtual Conference, CTO Forum, y además se suma Data Day. SG Conference & Expo cambiará de formato y pronto tendremos más noticias al respecto.

En este número encontrarán el estudio de salarios anual, que ya es un referente para el análisis de salarios en nuestra región.

Además es un gran indicador de la oferta y demanda laboral alrededor de distintos perfiles y tecnologías.

Así mismo, este año vimos nacer la nueva etapa de SG Talento, nuestra plataforma para acercar talento y oportunidades. Nuestro objetivo es ayudar a las personas a encontrar las oportunidades donde mejor se pueda aprovechar su talento, y ayudar a las empresas a encontrar ese talento especializado que es tan difícil de encontrar en otros lados.

Solo nos resta desearles felices fiestas y agradecerles por un gran año. Nos vemos en 2016.

El equipo de Software Guru

SG es posible gracias a la colaboración de Dirección Editorial Pedro Galván | Dirección de Operaciones Mara Ruvalcaba | Dirección Comercial Claudia Perea Coordinación Editorial Susana Tamayo | Arte y Diseño Oscar Sámano | Suscripciones Mariana Torres Consejo Editorial: Luis Daniel Soto | Gunnar Wolf | Luis Vinicio León | Hanna Oktaba Ariel Jatuff | Emilio Osorio | Gloria Quintanilla | Jorge Valdés COLABORADORES EN ESTA EDICIÓN José Miguel Benavente, David Bonilla, Gabriela Rocha, Macha Bertrand, Víctor Hernández, Carlos Eduardo Vázquez, Martín Ferrari, Humberto Cervantes, Misael León, Manuel López Michelone, Andrés Sabas, Brian Lonsdorf, . .

EQUIPO SG Coordinación de servicio Yoloxochitl Juárez | Marketing y Alianzas Fernando Hernández Developer Relations Luis Sánchez e Hilda Ramírez | SG Campus Jorge Osuna y Ariel García Contacto: info@sg.com.mx SG Software Guru es una publicación trimestral editada por Brainworx, S.A. de C.V., San Francisco 238 Altos. Col. Del Valle. Los contenidos de esta publicación son propiedad intelectual de los autores y se hacen disponibles bajo licencia Creative Commons Attribution-NonCommercial 4.0 International. Todos los artículos son responsabilidad de sus propios autores y no necesariamente reflejan el punto de vista de la editorial.

Reserva de Derechos al Uso Exclusivo: En trámite. ISSN: 1870-0888. Registro Postal: PP15-5106. Distribuido por Sepomex.

004

SG.49

NOTICIAS

Noticias STARTUP WEEKEND GLOBAL BATTLE

IOT ROADSHOW

1

En noviembre de 2015 se realizó una edición más del Global Startup Battle, que involucró la organización de más de 250 eventos de Startup Weekend realizados en distintas ciudades del mundo durante los fines de semana del 13 al 15 y 20 al 22 de noviembre. 32 de estos eventos se llevaron a cabo en Latinoamérica, siendo Brasil y México los países con más actividad (12 y 6 respectivamente). Destacó el Global Startup Battle Guadalajara que contó con más de 400 participantes que compitieron en distintas categorías como makers, fintech, gaming, drones, innovación social y salud. También fue notable la edición SW Mega Centroamérica realizada en San Pedro Sula, Honduras que reunió a más de 300 participantes de países como Guatemala, Costa Rica, y El Salvador, entre otros.

O 2

Software Guru organizó el Intel IoT Roadshow Guadalajara el pasado 22 y 23 de octubre. Más de 100 makers provenientes de distintas ciudades de la República Mexicana se reunieron para construir soluciones de internet de las cosas. El IoT Roadshow es una iniciativa global de Intel Software que consiste en un hackathon en el cual los participantes construyen proyectos de internet de las cosas utilizando la plataforma Intel Edison. Durante 2015, el IoT Roadshow se realizó en diversos países tales como Estados Unidos, Canadá, China, Francia, India, Japón, Rusia, Reino Unido, Brasil y por supuesto México.

De hecho, México fue el único país de habla hispana en el que se realizó el IoT Roadshow en 2015. Esperamos que esto aumente para 2016, y aquí estaremos para invitarlos.

Fotografía de SW Mega Centroamérica cortesía de María José Martínez.

DRUPALCAMP MX 2015

3

El DrupalCamp Mx 2015 se llevó a cabo del 5 al 7 de noviembre en la Torre de Ingeniería en la UNAM. La organización estuvo a cargo de Indava, empresa consultora en Tecnologías de la Información y DrupalShop. En el evento participaron representantes de Perú, Costa Rica, Bolivia, Guatemala, Panamá, Cuba, Estados Unidos, Austria y México. Destacó la participación de la conferencista Nicole Lind, de Phase2, quien ha estado involucrada en la construcción de multimillonarios proyectos del gobierno de los Estados Unidos. Esta edición tuvo especial relevancia ya que coincidió con el lanzamiento de Drupal 8, que significa un hito muy importante para este plataforma y su comunidad.

DEVNET HACKATHON / CISCO LIVE LA JSCONF COLOMBIA

5

4

Medellín fue sede de la edición 2015 de JSConf Colombia, realizada el pasado 16 y 17 de octubre. El evento contó con la participación de conferencistas internacionales como Brendan Eich, Raquel Vélez, Jenn Schiffer, entre otros, y atrajo a participantes de diversos países de Latinoamérica.

Como parte de las actividades de Cisco Live Latinoamérica realizado del 2 al 5 de noviembre en el Moon Palace Resort de Cancún, Software Guru organizó la competencia DevNet Hackathon en la cual durante 24 horas continuas los participantes construyeron soluciones innovadoras utilizando tecnología Cisco y compitieron por una bolsa de 4,500 dólares de premios. El equipo de la empresa Altus en Costa Rica fue el ganador y se llevó a casa el premio de 3,000 dólares en efectivo. El segundo lugar lo obtuvo un equipo formado por colaboradores de la empresa Segunda Mano en México, quienes acordaron donar el premio de 1,500 dólares a la institución “Casa de la Amistad” que apoya a niños y jóvenes en su lucha contra el cáncer.

SG.COM.MX

005

006

SG.49

SG.COM.MX

007

I

EMPRENDIMIENTO

¿Cuál es el Camino para el Éxito de las Startups en América Latina?

—

Por José Miguel Benavente

Las startups como modelo de emprendimiento son un fenómeno que da muestras de éxito alrededor del mundo. Pero para que esta oportunidad rinda su máximo potencial en América Latina, es necesaria una transformación en la que la región incorpore una cultura emprendedora.

Algo está cambiando en el modelo de negocios a nivel mundial, y para comprenderlo, debemos comenzar por entender qué es hoy una startup. Se trata de un emprendimiento que surge como oportunidad, no como necesidad.

Este modelo apuesta a ofrecer una solución o servicio que, al menos en la región, no existe. Tradicionalmente, el capital inicial o capital semilla de un emprendimiento no es provisto por la banca, sino por capitalistas de riesgo. Pero, actualmente, es cada vez mayor el acompañamiento

financiero formal desde los inicios del proyecto. Hoy sabemos que lo fundamental no es solo el tema de financiamiento sino de la “inteligencia” que puede venir vinculado a dichos recursos.

En términos generales, el capital inicial de los emprendimientos suele haber estado ligado a lo que se llama friends, family and fools, es decir, que un familiar, un amigo o, como indica el último de los términos, “un loco” sea quien arriesga su dinero. En otros casos los emprendedores se endeudaban sacando un crédito de consumo como particulares. La clave del nuevo modelo está en encontrar un financiamiento colaborativo e inteligente, donde muchas veces se requiere apoyo desde las políticas públicas.

Las claves de un proyecto exitoso A nivel individual, para que triunfe un determinado emprendimiento,

José Miguel Benavente es jefe de la División de Competitividad e Innovación en el Banco Interamericano de Desarrollo (BID). Antes de unirse al BID en 2014, fue director del Centro de Productividad de la Universidad Adolfo Ibáñez y profesor en la Universidad de Chile por más de 15 años.

008

SG.49

EMPRENDIMIENTO

la primera clave es identificar el modelo de negocios que sustenta la idea detrás del emprendimiento. Las etapas tempranas de las start ups se tratan de un “descubrimiento” de la forma en que se van a generando las rentas o se va a crear el valor.

Una vez determinado el mercado, en seguida se hace necesario evaluar entre miles de ideas para desarrollar aquella que tiene mayores posibilidades. Lo que la experiencia demuestra es que el éxito de la evaluación de las ideas suele ser mayor cuando es realizado por emprendedores. Esto tiene que ver con que un proyecto cambia mucho desde que comienza hasta que sale al mercado. Muchas veces lo importante no es evaluar el producto o idea en sí, sino al equipo. Y son los pares que ya han pasado por un proceso similar los que mejor pueden diagnosticar a potenciales equipos de trabajo.

En este sentido, lo conveniente en regiones en crecimiento como América Latina es enfocarse, probablemente, en aquellos emprendimientos que están destinados a dar soluciones a aquellos de recursos más bajos, a la base de la pirámide: lo que se conoce como startup social. Estas empresas tienen una gran aceptación en la región y han tenido grandes resultados.

Muchos de los emprendimientos con estas características han sido intermediados por incubadores especialmente orientados a esta área como es el caso de Socialab que tiene oficinas en Argentina, Chile, Colombia y Uruguay.

Otra clave de los emprendimientos exitosos es la participación del evaluador en los riesgos y en el retorno. Un ejemplo extremo es el del caso Israelí: las startups importantes, de capital intensivo, inversiones de 500 mil dólares, en las que participa el sector público, se realizan con un modelo en el que 350 dólares son públicos y 150 de la incubadora o quien financia en la etapa temprana. De este modo, quien hace la selección tiene incentivo para hacer una buena selección, porque su bolsillo está afectado.

Hacia un ecosistema emprendedor para América Latina El foco de una política pública orientada al modelo startup debe enfocarse no en financiar proyectos individuales, sino especialmente en generar un espacio, un ecosistema de innovación y emprendimiento, en el que se encuentren las ideas, los inversores, los técnicos, y el mercado. A nivel mundial, Silicon Valley fue eso: un espacio geográfico de encuentro. A nivel regional el ejemplo más avanzado es el chileno, con el proyecto Startup Chile.

Un dato alentador para el mercado latinoamericano es que por una parte el sector público ha apostado a estos emprendimientos, y por otro, se han desarrollado modelos más colaborativos y de repartición de la inversión, de los riesgos y de las ganancias.

I

Uno de los problemas que enfrenta la región tiene que ver con el flujo de ideas. De mil ideas se analizan cien; se financian diez y va bien en dos. Por eso, quizás la región no está aún lista para que, en cada país, se presenten mil ideas para cada industria. Esto puede resolverse con el apoyo recíproco entre países de la región.

Desde el Banco Interamericano del Desarrollo promovemos esta cooperación, por ejemplo con la Alianza del Pacífico, que reúne a Chile, Perú, Colombia y México. La idea es que cada país pueda especializarse —Chile en industria minera, México en biotecnología, Colombia en industria creativa— y que el costo de transacción entre los países sea cero. Que se apoye la creación de puntos de encuentro geográficos, que se financie la movilidad. Esto ocurre, por ejemplo, en Estados Unidos, con Silicon Valley o el camino de Boston; pero, al ser un solo país, con las mismas reglas, no se nota, no hay costos.

Cuatro desafíos para la región La región tiene un gran potencial para este modelo, sin embargo, debe enfrentar cuatro desafíos clave. Por un lado, hay una falta de cultura de la inversión. En muchos casos se trata del peligro de una zona de confort, en la cual arriesgarse no es contemplado como una opción, y esto bloquea el crecimiento. En la evaluación de la política pública chilena, se ve que cuando llegan ideas y talentos extranjeros, los chilenos aprenden mucho. Se trata de un cambio cultural.

Otra dimensión, muy ligada a la anterior, es la de las competencias técnicas. Algunas industrias, como las que tienen que ver con las TIC, o las biotecnologías, pueden tener un gran potencial en la región pero las competencias técnicas que requieren aún son escasas en nuestras sociedades y debemos generarlas.

El tercer obstáculo es la dificultad de sobrevivir y expandirse.

Una característica de nuestras sociedades es que vivimos en una cultura más bien rentista. El espacio está limitado. Hay “falta de competencia”, esto quiere decir, desde un punto de vista más economista, que las barreras de entrada a nuevas ideas son extremadamente altas. Por último, la cultura startup es una cultura del éxito basado en los fracasos. Y en nuestra cultura el fracaso es mal visto, no se ve como mecanismo de aprendizaje sino como mala utilización de recursos.

Todos estos desafíos están ligados, y probablemente el más importante sea el cultural. Se trata de un proceso de cambio.

Debemos pensar a futuro, y pensar, por ejemplo, que los programas incluso pueden influir en los procesos de aprendizaje, para que ser emprendedor sea un valor codiciado; como en nuestra generación fueron otros, como ser un empleado asalariado, prolijo, eficiente. El mundo ya nos ha iluminado con las claves para que este modelo sea exitoso, ahora debemos complementar este aprendizaje con lo propio de nuestra región, para aprovechar estas oportunidades.

SG.COM.MX

009

O

RADAR

2

BI SOBRE HADOOP CON APACHE KYLIN

1

Netflix continúa publicando como open source algunas de las herramientas y plataformas que ha desarrollado internamente para operar su infraestructura de TI. Caso en cuestión es Spinnaker, una plataforma open source para gestionar la instalación de aplicaciones en la nube. El principal atractivo de Spinnaker es que está diseñado para ser multi-nube, es decir que puede operar con nubes de distintos proveedores, y ser extendido para poder operar con cualquier nube pública o privada. De esta forma, Spinnaker habilita un modelo de instalación agnóstico del proveedor, y facilita la portabilidad. Actualmente Spinnaker soporta la gestión e instalación de aplicaciones en Amazon Web Services, Google Cloud Platform y Pivotal. Próximamente se agregará soporte para Microsoft Azure.

La Fundación de Software Apache anunció que el Apache Kylin se graduó de la incubadora y pasó a ser un proyecto de primer nivel. Kylin es un motor distribuido de analítica que provee análisis OLAP multidimensional y una interfaz SQL para Apache Hadoop, soportando conjuntos de datos de gran escala.

Kylin permite que los analistas de información y usuarios finales puedan realizar análisis interactivo de información sobre conjuntos de datos masivos. En pocas palabras, Kylin habilita business intelligence sobre Hadoop. Kylin fue originalmente creado por eBay y cedido a Apache en noviembre de 2014 para que gestione su evolución.

http://spinnaker.io

http://kylin.apache.org

MANEJA INSTALACIÓN MULTI-NUBE CON SPINNAKER

3

ANDROID STUDIO 2 SERÁ MUCHO MÁS RÁPIDO

Android Studio 2.0 ya se encuentra disponible como versión previa. Las nuevas capacidades que incorpora se enfocan principalmente en acelerar el flujo de trabajo.

Destaca una nueva característica llamada “Instant Run” que básicamente permite hacer “hot swapping” de cambios; es decir que un cambio en el código de una aplicación se refleja inmediatamente (menos de 2 segundos) en un dispositivo físico conectado o un emulador, y se ejecuta sin necesidad de reconstruir e instalar el APK completo. La velocidad del emulador también ha mejorado drásticamente (los reportes preliminares indican mejoras de más de 10x). El nuevo analizador de desempeño de GPU también será útil para encontrar cuellos de botellas en el desempeño gráfico de aplicaciones y optimizarlas para un rendimiento óptimo. http://android-developers.blogspot.com/2015/11/android-studio-20-preview.html

010

SG.49

4

NUEVAS HERRAMIENTAS

En las últimas semanas Microsoft publicó varias herramientas y servicios para desarrolladores. Entre las que más atención generaron están Visual Studio Code (editor de código para Linux, Mac y Win), Visual Studio Team Services (desarrollo colaborativo en la nube) e incluso el proyecto open source Dockercraft (gestión de contenedores Docker desde Minecraft). Otros proyectos o lanzamientos que no generaron tanta atención, pero que nos parecen relevantes son: Microsoft Graph (https://graph.microsoft.io) - API unificado para acceder a datos y servicios de Microsoft en la nube, como por ejemplo Office 365.

CodePush (http://microsoft.github.io/code-push) - Servicio en la nube para actualizar aplicaciones móviles directamente en el dispositivo móvil del usuario, sin necesidad de pasar por app store. Limitado a apps hechas con Cordova o React Native.

Windows Store for Business - App store administrada por el departamento de TI de una empresa para hacer disponibles las aplicaciones de negocio aprobadas para uso de los empleados y colaboradores.

TENDENCIAS EN SOFTWARE

C

Algoritmos Inteligentes Por Luis Daniel Soto Maldonado

20 años atrás. En 1995 se embarcaron 60 millones de computadoras en todo el mundo. Internet se desarrollaba en paralelo desde fines de los sesenta y su impacto ya era claro. En 1999 salesforce.com se instituyó como una alternativa del cómputo cliente-servidor basado en Internet o “Software-as-a-service”.

A fines del 2004 el término “Web 2.0” se usó para enfatizar el contenido creado por usuario y mejoras a la usabilidad e interoperabilidad de la red. Desde ese entonces se especulaba de un Internet que sería primariamente procesado por máquinas.

Tribu Orígenes Algoritmo principal

Hace una década. Fue en agosto 25 del 2006 que Amazon anunció el primer beta del cómputo elástico en Internet. Por primera vez fue posible obtener recursos de cómputo de forma abstracta equivalentes a un procesador Intel Xeon 1.7GHz del 2006, y así nació el cómputo en la nube. Hace una década también nació Hadoop, para el procesamiento de cada vez mayores volúmenes de datos. En mi opinión, el libro “The Big Switch” de Nicholas G. Carr [1], explica con claridad la actual revolución de cómputo.

Independientemente de que pueda existir un solo algoritmo para que una máquina pueda aprender cualquier cosa, presentando una gran cantidad de “ejemplos”, los fundamentos relacionados y la reciente disponibilidad de la tecnología permite integrarla hasta en las más sencilla aplicación. En décadas pasadas nos hemos hechos dependientes del software, pero en la siguiente etapa dependeremos de un nivel de automatización sin precedente: algoritmos que aprenden y máquinas que se programan a sí mismas, que mejoran gradualmente, que conocen mejor al usuario que cualquier que otros humanos.

Fines del 2015. Desde hace dos años las tabletas y celulares han mantenido en declive su participación contra computadoras personales embarcadas a nivel mundial. La migración a la nube se está acelerando, cada vez son menos los que piensan que nunca abandonaran los centros de datos propios, aún en las industrias más reguladas. Las tecnologías relacionadas a la nube y movilidad —como seguridad, contenedores y analítica— continuarán con gran demanda (leer “50 enterprise startups to bet your careers on in 2016” [2]).

El internet inteligente. Recientemente he descrito en esta columna el Internet de las cosas. Resulta claro que el destino requiere de mejores decisiones tomadas por las máquinas mismas. El verdadero cambio que puedo ver en las propiedades mayores de internet así como en los círculos de emprendimiento es una “fiebre de oro” por el aprendizaje automatizado (machine learning).

El último trimestre del 2015 se caracterizó por una variedad de tecnologías de código abiertas para predicción. Pedro Domingos ha expuesto en “The Master Algorithm” [3] cinco distintas “tribus” con aproximaciones distintas a la nueva inteligencia artificial:

Simbolistas Lógica, Filosofía Deducción inversa Conexionistas Neurociencia Retropropagación Evolucionarios Evolución biológica Programación genética Bayesianos Estadísticas Inferencia probabilística Análogos Psicología Máquinas basadas en un Kernel

Luis Daniel Soto (@luisdans / @luisdanielsoto) trabaja en Amazon Web Services, enfocado en el desarrollo global de negocios para Big Data e

Solo recordemos que la inteligencia de máquina no tiene por qué comportarse como la inteligencia humana.

Inteligencia de negocios. sotols@amazon.com

Referencias [1] N. Carr. “The Big Switch: Rewiring the world, from Edison to Google”.

W. W. Norton & Company, 2008. http://swgu.ru/r0 [2] J. Bort, E. Kim & M. Weinberger. “50 enterprise startups to bet your career on in 2016”. Business Insider, Nov 2015. http://swgu.ru/r1 [3] P. Domingos. “The Master Algorithm: How the Quest for the Ultimate Learning Machine Will Remake Our World”. Basic Books, 2015. http://swgu.ru/r2 [4] D. Hofstadter. “Gödel, Escher, Bach: An Eternal Golden Braid”. Basic Books, 1979. http://swgu.ru/r3

SG.COM.MX

011

T

TUTORIAL

Guía para Depuración con Android Wear — Por Intel Software

Depurar (debugging) es un proceso inherente a todo ciclo de desarrollo, y el caso de las aplicaciones de Android Wear no escapa a esa regla. En este artículo mostramos cómo depurar aplicaciones para prendas inteligentes.

Para depurar aplicaciones en prendas inteligentes necesitamos de lo siguiente: • Prenda inteligente (wearable) en cuestión.

• Dispositivo móvil Android (teléfono o tableta) que se conecta a la prenda inteligente.

• Computadora personal con el Android SDK instalado, incluyendo las “platform-tools”.

Al realizar esta guía utilizamos como referencia un reloj LG G Watch R conectado a un Nexus 4, pero esto se podría hacer con cualquier otra combinación de prendas inteligentes y dispositivos Android modernos.

Activar opciones de desarrollo Para realizar la depuración, necesitamos activar opciones que están dentro del menú de “Opciones de desarrollo” (Developer options) en la sección de Ajustes (Settings). Si no tienes visible este menú, por favor actívalo tanto en el dispositivo móvil como en el wearable (ver figura 1).

Para activarlo requieres realizar los siguientes pasos: 1. Ir a Ajustes.

2. Entrar a “Acerca del teléfono”

3. (About phone).

4. Tocar el siete veces en el Número de compilación (Build number). Después de la séptima vez verás un mensaje indicando que ya eres desarrollador y podrás encontrar el menú de Opciones de desarrollo dentro de la sección de Ajustes.

Conexión directa de wearable a PC Si el wearable tiene conectividad por USB, esta es la opción más sencilla. Ya que basta con realizar los siguientes pasos en el wearable: 1. En el wearable, ir a “Ajustes” —> “Opciones de desarrollo” y habilitar “Depuración ADB” (ADB Debugging). Ver figura 2.

2. Conectar el wearable a la computadora con un cable USB. 3. En el dispositivo móvil aparecerá una ventana de confirmación para permitir depuración del wearable.

4. Para verificar la conectividad, desde la terminal de comandos de la computadora puedes teclear el comando “adb devices” y debes ver listado el wearable. Recuerda que el comando adb está en la carpeta platform-tools de tu Android SDK, así que agrega esa carpeta a tu PATH o ejecuta el comando indicando la ruta a la carpeta.

Conexión con puente por Bluetooth Otra opción de conexión es utilizar el dispositivo móvil como puente entre el wearable y la computadora. En este caso, conectamos el wearable con el dispositivo móvil por Bluetooth y luego conectamos el dispositivo móvil a la computadora por USB. Esto requiere que ajustemos la configuración tanto en el wearable como el dispositivo móvil para permitir depuración y que configuremos ADB para que se conecte al wearable.

1. En el wearable, ir a “Ajustes” —> “Depuración sobre Bluetooth” (Debug over Bluetooth).

Figura 1. Habilitar Opciones de desarrollo.

012

SG.49

Figura 2. Habilitar depuración en wearable.

TUTORIAL

Figura 4. Autorizar depuración de dispositivo.

T

Figura 5. Autorizar depuración de wearable..

Figura 3. Configuración de Android Wear en dispositivo móvil.

2. En el dispositivo móvil, ir a “Ajustes” —> “Opciones de desarrollo” y habilitar “Depuración de USB” (USB Debugging).

3. Otra vez en el dispositivo móvil, en la companion app de Android Wear habilitar “Depuración sobre Bluetooth” (Debugging over Bluetooth). En esta sección podemos ver el estatus de conexión hacia el target (wearable) y el host/ computadora (ver figura 3).

4. Conectar el dispositivo móvil a la computadora por USB. Si es la primera vez que conectamos este dispositivo móvil con esta computadora para depuración, aparecerá una ventana pidiendo que autoricemos la depuración desde esta computadora (ver figura 4).

5. En la computadora personal, escoger un puerto de comunicación libre (en este caso usaremos el 4444) y configurar adb para que se conecte al wearable usando este puerto. Esto se logra escribiendo los siguientes comandos desde la terminal de comandos. adb forward tcp:4444 localabstract:/adb-hub adb connect localhost:4444

6. Posiblemente el dispositivo móvil ahora nos pida también autorización

para depurar desde la computadora hacia el wearable (ver figura 5).

7. Una vez hecho esto, en la companion app de Android Wear desde el dispositivo móvil veremos que el estatus de depuración por Bluetooth mostrará que está conectado (ver figura 6).

Una vez que la conexión es exitosa, si desde la computadora tecleamos “adb devices”, veremos listados dos dispositivos: uno es el dispositivo móvil conectado por USB, y otro que aparecería como “localhost:4444” sería el wearable.

Podemos enviar comandos de depuración al wearable de la siguiente forma: adb -s localhost:4444 <comando>

o si este es el único dispositivo conectado por TCP/IP o emulador activo, entonces simplemente podemos usar: adb -e <comando>

Conclusión Dado los recursos de cómputo limitados que hay en los wearables, es importante que tengamos perfectamente controlada la actividad de nuestras apps al ejecutarse en wearables. Poder hacer depuración directamente en el wearable nos permite

Figura 6. Estatus de conexión.

tener este control y nos ayuda a construir apps de mejor calidad. Te recomendamos visitar la Zona de Desarrolladores Intel en: http://software.intel.com/es-es/android donde encontrarás artículos y guías para el desarrollo de wearables Android.

Referencias [1] “Android Wear por ADB”. Intel Software. https://software.intel.com/es-es/android/articles/ android-wear-through-adb

SG.COM.MX

013

014

SG.49

Durante octubre y noviembre de 2015 realizamos una edición más de la Encuesta de Salarios de SG. Compartimos aquí los principales resultados.

Consideraciones para interpretar las cifras Las cifras y estadísticas que mostraremos en este artículo se generaron en base a una muestra de 2,252 respuestas obtenidas entre octubre y noviembre de 2015 en una encuesta abierta realizada por medio de internet. Todos los datos se refieren a salario bruto mensual.

92% de los participantes indicaron radicar en México. Es por ello que el grueso de las estadísticas están acotadas a este segmento y expresadas en pesos mexicanos.

En el caso de estadísticas donde se haya considerado respuestas internacionales, están expresadas en dólares.

En la mayoría de los casos incluimos 3 datos: mediana, media (promedio) y desviación estándar. Le damos prioridad a la mediana porque nos ayuda a suavizar el efecto de valores extremos. En el caso de la desviación estándar, la incluimos para dar una idea de la dispersión de los datos.

Estamos conscientes de que la magnitud de la desviación estándar de los datos presentados aquí es elevada. Esto se debe principalmente a que en las estadísticas que mostramos solo se está usando una variable al mismo tiempo (ej. geografía, experiencia, skill). Pero si combinamos múltiples variables (ej. programador Java en Jalisco con entre 5 y 10 años de

experiencia e profesional o avanzado) la desviación estándar se reduce significativamente y por lo tanto arroja resultados más confiables. Hacer ese tipo de análisis multivariable está fuera del alcance de este reportaje, pero es un ejercicio que ustedes o su empresa puede realizar a partir de los datos fuente.

Salario promedio De acuerdo a los datos recopilados este año, el salario bruto de un profesionista de software en México tiene una mediana de $26,000 pesos mensuales. La tabla 1 muestra los principales datos estadísticos para el salario en México.

Aunque este es el primer dato que presentamos por ser el que engloba en una sola cifra el estado general de salarios en nuestra profesión, la realidad es que hay tanta varianza entre los datos (debida a la variedad de perfiles que contestan la encuesta), que no recomendamos darle mucha importancia a este valor. Tal vez sirva a un estudiante que quiera darse una idea muy general de cuánto podría ganar estudiando una carrera de TIC, pero hasta ahí. Es mejor utilizar los resultados que mostramos en el resto de este reportaje, desglosados por regiones, perfiles y habilidades.

La tabla 2 muestra estadísticas descriptivas del salario a través de distintos países.

Solamente se incluyen aquellos países de donde obtuvimos al menos 10 resultados, lo cual es un número bastante bajo como para dar datos confiables, pero esperamos sirva para brindar un panorama general de lo que sucede en cada país.

Tabla 1. Salario bruto de profesionistas de software en México.

SG.COM.MX

015

Geografía La tabla 4 muestra el desglose de acuerdo al estado de la República Mexicana donde radican los participantes. Solo se muestran aquellos estados de donde obtuvimos 15 o más respuestas.

Tabla 2. Comparación de salario por país.

Actividades y roles Nuestra profesión tiene una gran variedad de perfiles y career paths posibles. La tabla 3 muestra algunos de los principales.

Tabla 4. Salario por entidad federativa.

Confirmando la tendencia que habíamos visto en años anteriores, donde Jalisco recortaba distancia con Distrito Federal y Monterrey, este es el año en que por fin los rebasó. La apertura de tantos startups y centros de desarrollo global en esta región sin duda ha tenido un gran impacto en los salarios de los profesionistas de software en esta región.

Tipo de empresa y esquema

Tabla 3. Salario por rol.

Cada participante podía escoger hasta tres roles, por ello la suma de los porcentajes es mayor a 100%. Comparando estos datos con 2014, podemos ver que el porcentaje de directivos bajó (de 4.2% a 3%), al igual que su salario (de $48,500 a $45,000). En contraste, el porcentaje de programadores subió —back-end de 18.7% a 20.5% y front-end de 11.1 a 13.3%— y también su salario —back-end de 23,000 a 25,000 y front-end de 22,000 a 25,000. ¿Será esto una tendencia particular entre la audiencia de SG o un fenómeno generalizado en la industria? Posiblemente tenga que ver con lo que comenta David Bonilla sobre “Los malditos programadores” (ver artículo “La paradoja del software y los malditos programadores” en este número de SG).

016

SG.49

La tabla 5 muestra la descomposición de los participantes de acuerdo al tipo de organización donde laboran. Los proveedores de servicios son típicamente empresas de outsourcing, los ISV son empresas que desarrollan software comercial, y las organizaciones usuarias son aquellas de sectores que no sean TI (ej. banca, retail, gobierno, etc). Continúa la tendencia de tercerización (outsourcing). Cuando comenzamos a realizar esta encuesta en SG hace más de 6 años, más del 50% de los profesionistas de TI laboraban en organizaciones usuarias. A través de los años ese porcentaje ha ido bajando, y hoy nos sorprende que ya esté cercano al 25%. En resumen, cada vez hay menos empleo de TI en los corporativos y más en las empresas proveedoras.

Un punto a considerar es que aunque las empresas proveedoras y los startups arrojan los salarios más altos, típicamente también son las que ofrecen las menores prestaciones, además de que son pocas las empresas de este tipo que pagan el 100% en nómina.

Tabla 7. Desglose por género.

Habilidades y conocimientos Tabla 5. Tipo de empresa.

La tabla 6 muestra los esquemas de compensación más populares entre los participantes. El esquema mixto o híbrido, donde una parte se paga en nómina y otra en honorarios, sigue aumentando en uso, y casi se ha convertido en el esquema de facto en las empresas proveedoras de servicios de TI. La cantidad de freelancers también sigue aumentando respecto a años anteriores. Todavía es un porcentaje pequeño, pero vale la pena notar que cada vez más personas prefieren su independencia; parecer ser la influencia millenial.

Las tablas 8a a 8i muestren el desglose de salarios a través de distintas categorías de herramientas y tecnologías utilizadas por los profesionistas de software. La mayoría se explican por sí solas, pero para otras es necesario dar cierto contexto. Por ejemplo, en el caso de la tabla 8f, muestra plataformas utilizadas para procesar y administrar datos. Estas van desde herramientas tradicionales de Business Intelligence, hasta ETLs y plataformas de big data y stream processing. Aunque en la encuesta se incluyeron varias herramientas adicionales (ej. Cloudera, Splunk, Teradata), no aparecen en la tabla porque tuvieron menos de 10 respuestas.

En la tabla 8g se muestra la categoría de infraestructura, que engloba middleware, servidores de aplicaciones, plataformas de virtualización, contenedores y PaaS. Sí, lo sabemos, es una categoría demasiado amplia. En años futuros la desglosaremos.

Género

La tabla 8h muestra aplicaciones empresariales. Alguna vez este fue el grueso del trabajo que se hacía en TI (implantación de ERP), sobre todo en México. Pero conforme el software cada vez se usa para mucho más cosas que automatizar procesos administrativos, la categoría de aplicaciones empresariales poco a poco pierde representación respecto al software en general. Es por ello que en este caso decidimos dejar incluso los resultados de aquellas opciones que tuvieron menos de 10 respuestas.

La tabla 7 muestra el desglose entre hombres y mujeres en nuestra profesión. Todos hemos visto los esfuerzos que ha hecho la industria por tratar de atraer y retener a más mujeres, pero definitivamente falta hacer mucho más.

Por último, en la tabla 8i tenemos el desglose a través de certificaciones. Sabemos que hay una gran variedad de certificaciones en nuestra industria, pero aquí hemos incluido a las más populares.

Tabla 6. Esquema de contratación.

SG.COM.MX

017

Tabla 8a. Desglose por nivel de inglés

Tabla 8d. Desglose por tecnología front-end.

Tabla 8e. Desglose por base de datos.

Tabla 8f. Desglose por plataforma de datos.

Tabla 8b. Desglose por lenguaje de programación.

Tabla 8c. Desglose por plataforma aplicativa.

018

SG.49

Tabla 8g. Desglose por infraestructura (middleware, PaaS).

Tabla 9. Salario por nivel de estudios.

Tabla 8h. Desglose por aplicación empresarial.

Experiencia La tabla 10 muestra los resultados del análisis de correlación con salario. La experiencia es la variable que tiene mayor impacto en el salario, seguida por el nivel de inglés.

Tabla 10. Correlación con salario.

Teniendo esto en cuenta, hicimos un segundo análisis para desglosar el salario de los participantes agrupados por años de experiencia. Para aumentar la efectividad del experimento eliminamos algunas de las variables con mayor impacto: nivel de inglés y región. Así que seleccionamos el segmento de personas que radican en el Distrito Federal y con nivel de inglés avanzado. La tabla 11 muestra los resultados. En ella se puede ver claramente el impacto que tiene la experiencia en el salario.

Tabla 8i. Desglose por certificación.

Nivel de estudios La tabla 9 muestra el salario a través de distintos niveles de estudios terminados. Al igual que en 2014, se repite que los que tienen educación técnica, en promedio perciben mayores ingresos incluso que quienes tienen estudios universitarios. La muestra es pequeña, y no concluyente, pero sin duda nos da qué pensar. ¿Tendrá que ver con el bajo nivel de los egresados de el grueso de las universidades?, ¿es que para desarrollar software está de más ir a la universidad?, ¿será un efecto de las hacker schools?

Tabla 11. Desglose por años de experiencia.

Casos específicos La gran mayoría de las vacantes en nuestra industria buscan a desarrolladores que dominen tecnologías de alta demanda, tengan por lo menos 3 años de experiencia, y que sepan inglés. ¿Cuál es el salario de alguien con ese perfil?

SG.COM.MX

019

Tabla 12. Ejemplos de casos de alta demanda.

La tabla 12 muestra 3 casos comunes, mezclando tecnologías y mercados laborales con alta demanda. En todos los casos está acotado a personas con 3+ años de experiencia e inglés profesional o avanzado.

Entonces, como podemos ver, el salario medio de un desarrollador Java en Guadalajara es de $40,000 pesos, y el 50% gana entre $34,000 y $46,000 pesos. Si estás buscando a alguien con ese perfil, deberías estar preparado para poder pagar ese salario.

empleo actual. Hemos agregado una columna con el salario medio (mediana) que reciben las personas en cada categoría. Como podemos ver, hay una clara relación entre el nivel de satisfacción y el sueldo recibido. La buena noticia es que la gran mayoría de los profesionistas de software están satisfechos. Adicionalmente, la tabla 15 presenta las principales razones que los participantes indicaron por las que cambiarían de empleo.

Tabla 14. Satisfacción con empleo actual.

Prestaciones y motivación La tabla 13 muestra las prestaciones que los participantes indicaron recibir. Como es de esperarse, el seguro de gastos médicos mayores es el más común. Nos llama la atención que casi una tercera parte indicó que puede trabajar de forma remota; en comparación, en la encuesta de SG en 2010 este porcentaje era del 18%. Por otro lado, la cantidad de personas que recibe acciones (equity) de la empresa donde colabora, sigue siendo bastante baja.

La tabla 14 muestra el nivel de satisfacción que indicaron tener los participantes con su

020

SG.49

Tabla 15. Razón por la que cambiaría de empleo.

Eso es todo por esta edición del estudio de salarios SG 2015. Agradecemos a todos los participantes y empresas que nos apoyaron con su participación y difusión, esperando que esta información les sea útil.

Tabla 13. Prestaciones.

Mejores Empresas para Trabajar

Un elemento importante de la información que obtenemos durante la encuesta para el estudio de salarios SG, es saber qué tan satisfechas están las personas con su trabajo actual, y cuáles son las empresas que tienen a los empleados más satisfechos. En otras palabras, cuáles son las mejores empresas para trabajar en TI en nuestra región.

Metodología Los participantes en el estudio de salarios indican opcionalmente la empresa donde laboran, y evalúan su satisfacción laboral en cada uno de los siguientes rubros: • El trabajo que realizo es un buen reto intelectual.

• Trabajo con gente muy capaz, de la que aprendo.

• La empresa me apoya para capacitarme.

• La empresa ofrece facilidades para participar en eventos de la industria.

• Sé hacia donde voy con esta empresa, confío en que puedo crecer mucho en ella.

• Mi trabajo me ayuda a vincularme con personas fuera de mi empresa.

• Cuento con el equipo y herramientas (hardware y software) adecuado para realizar mi trabajo.

• La empresa tiene finanzas estables y paga puntualmente.

• Me agrada mi estación e inmobiliario de trabajo (oficina, escritorio, silla, etcétera).

• Estoy satisfecho(a) con la ubicación donde se encuentra la empresa/oficina.

• Me gustan las opciones que tengo para comer.

• Estoy satisfecho(a) con el horario de trabajo (o flexibilidad).

• Me siento valorado(a) por mis superiores.

• Laborar en esta empresa me facilita estar saludable.

Con esto se obtiene una calificación total de parte de cada participante y luego se promedian las evaluaciones de participantes de la misma empresa para obtener la evaluación de cada empresa.

Cabe mencionar que previamente analizamos los datos para filtrar y descartar posibles casos de fraude. Adicionalmente, solamente tomamos en cuenta a empresas de donde obtuvimos respuestas de un mínimo de 5 participantes distintos. Así que si tu empresa no aparece, puede ser porque o no fue lo suficientemente bien evaluada, o no se recibieron suficientes evaluaciones de personal de esa empresa.

Ganadores Presentamos la lista de las 20 mejores empresas para trabajar de acuerdo a los participantes en la encuesta de salarios SG 2015.

1. Unosquare 2. Luxoft 3. Base22 4. Tacit Knowledge 5. Definity First 6. Smart Byte 7. Nearsoft 8. Magma Labs 9. Globant 10. Segundamano 11. Tiempo Development 12. Extend Solutions 13. InnovaWeb 14. IDS Comercial 15. DotNET Desarrollo de Sistemas 16. IBM 17. Oracle 18. Scio Consulting 19. Accenture 20. Indigo Smart Software Development Nos llama la atención que a excepción de Segundamano, todas estas son empresas cuyo negocio principal consiste en construir soluciones y productos de tecnología. Tradicionalmente, las empresas de consultoría en TI habían sido las menos apreciadas por su gente. Pero la batalla por el capital humano ha obligado a estas empresas a cambiar su cultura y poner un mucho mayor énfasis en la satisfacción de sus colaboradores.

Felicitamos a todas las empresas, pero especialmente a las que repiten de 2014 a 2015. Estas son: Tacit Knowledge, Definity First, Nearsoft, Magma Labs (antes Crowd Interactive), Globant, Tiempo Development, Extend Solutions, InnovaWeb, IDS Comercial, DotNet Desarrollo de Sistemas, IBM, Oracle, Scio Consulting e Indigo Smart Software Development.

Invitamos a todas las empresas que quieran aparecer en este ranking el próximo año a que se ocupen en mejorar la satisfacción de sus empleados y en noviembre de 2015 se aseguren de invitarlos a que contesten el estudio de salarios de SG.

SG.COM.MX

021

H

CARRERA

La Paradoja del Software y los Malditos Programadores Por David Bonilla

Hay gente que no acepta que un programador pueda ganarse bien la vida haciendo simplemente su trabajo: programar.

Suele ser gente sin conocimientos técnicos, pero que sí piensan tenerlos porque leen artículos de tecnología “ya digeridos” para consumidores habituales de prensa financiera; o —peor aún— son entrepreneurs que creen que fundar una empresa “de Internet” los convierte, inmediatamente, en gurús tecnológicos.

Es fácil identificarlos porque dicen que es “imposible” encontrar buenos programadores y, cuando les explicas que lo único que tienen que hacer para encontrarlos es salir a buscarlos y pagarles un salario de mercado, se quejan amargamente de que los malditos programadores cobran mucho. Demasiado para poder crear negocios rentables.

Creen que están en la onda porque leen TechCrunch, no dejan de coleccionar contactos en angel.co, en LinkedIn y no se pierden ni un solo guateque estartupero; pero no se están enterando de lo que está pasando y, sobre todo, POR QUÉ.

Hace un par de meses, se publicó The Software Paradox (http:// amzn.com/B0118ANTCQ), un libro en el que Stephen O’Grady intenta explicar durante 62 páginas lo que él llama Paradoja del Software o cómo, en un mundo donde el software es cada vez más importante, su valor tiende a ser cero. No es que O’Grady haya descubierto petróleo, pero ha documentado a la perfección la profunda transformación que ha sufrido la industria del software en los últimos 10 años, que le ha llevado a dejar de vender licencias para centrarse en vender servicios.

Pero eso no quiere decir que se gaste menos dinero en software —al contrario— quiere decir que se gasta de otra manera.

Los que se escandalizan por el salario de los malditos programadores deberían recordar la época en la que las empresas adquirían tecnología a golpe de compra de licencias. Antes, era normal que una PYME montara su propio data center, haciendo una inversión importante en servidores y en acondicionar una sala donde colocarlos, mucho antes de poder rentabilizarlos. 99% de esas empresas hoy despliegan sus aplicaciones en máquinas virtuales que escalan según sus necesidades reales.

Antes, era normal pagar cientos de miles de dólares en licencias de uso de un ERP o un CRM que no servían para nada hasta que la empresa gastaba dos o tres veces más en la consultoría necesaria para parametrizarlos y adaptarlos a sus necesidades. 99% de esas soluciones se pueden disfrutar hoy como servicio, pagando una cuota mensual.

En ese contexto, la labor principal del CIO consistía en negociar con los vendedores de soluciones, mientras que el personal de TI se rompía la cabeza averiguando cómo encajar en su proyecto la solución por la que se había pagado un dineral antes de comprobar si realmente solucionaba algo … ¿de verdad alguien echa de menos esto?

Hoy esa misma tecnología se adquiere por una fracción de su antiguo precio, gracias a productos open source y servicios de Software as a Service (SaaS). Y son esos malditos programadores con un salario desorbitado los que lo hacen posible.

El open source y el SaaS han democratizado el acceso a la tecnología y han permitido que los técnicos hoy sean los que tienen el poder —y la responsabilidad— de decisión sobre qué arquitectura se usará en cada proyecto para montar pilotos o MVPs, mucho antes de que estos lleguen al CIO. Por eso, la industria del software cada vez contrata más evangelistas técnicos y menos vendedores de traje impecable, ahorrando millones de dólares a las empresas en el proceso.

En informática, el centro de gravedad —y de inversión— se ha trasladado del software a los programadores. El software es un activo, pero se paga por un servicio. Si aún no lo has entendido, ya vas tarde.

Los proyectos informáticos hoy son más baratos que nunca. Lo que pasa es que el dinero ya no se mueve en comidas de café, copa y puro, sino en las madrigueras y sótanos donde se solía colocar a los malditos programadores.

Si no quieres aceptarlo, busca otro trabajo con el mismo futuro que tus ideas. Por ejemplo, vender software en cajas. Suerte.

[Este artículo fue originalmente publicado en la Bonilista en agosto del 2015 y se encuentra disponible en http://swgu.ru/qu .

Fue republicado en SG con permiso del autor.]

David Bonilla se dedica a crear cosas y tratar de hacer dinero con ellas, más que nada por medio de Internet. Radica en Madrid, España y es cofundador de Otogami, un servicio de búsqueda y comparación de ofertas de videojuegos. Es autor de la “bonilista”, una lista de correo con artículos para profesionistas de software.

022

SG.49

REPORTAJE

R

Tendencias sobre Talento en TI

La industria de TI ha tomado un papel protagónico en la economía Mexicana en la última década. Hoy las empresas no sólo ven al país como potencia manufacturera, sino también como un importante mercado para instalar centros de conocimiento e innovación, lo cual demanda talento calificado con habilidades y especialidades propias de la industria.

Ante este reto, Kelly Services en alianza con Software Guru, organizó una reunión con líderes de capital humano de algunas de las empresas más importantes de la industria de TI, para compartir experiencias y puntos de vista buscando enfrentar juntos el reto del desarrollo de talento tecnológico en nuestra región.

La mesa redonda contó con la participación de: • Judith Vila, Directora de Beneficios y Compensaciones en IBM México.

• Elsa Aguilar, Directora de Recursos Humanos en SAP México.

• Elba Figueroa, Directora de Recursos Humanos en Cisco México.

• María del Mar Valadez, Directora de Generación de Capacidades en Softtek.

• Miguel Ángel Pérez, Líder de Recursos Humanos en Dell México.

• Susana Segura, Gerente de Recursos Humanos en Ricoh México.

• Juan Saldívar, Director Nacional de MexicoFIRST.

Ideas y conclusiones A continuación compartimos algunas de las ideas y conclusiones más importantes que se alcanzaron durante la reunión ...

Las nuevas generaciones están más interesadas en la flexibilidad y movilidad que en una larga carrera en una misma empresa. Esto presenta un reto para las áreas de recursos humanos que deben adaptarse a este contexto.

El alto grado de especialización de conocimientos en el área de TI hace cada vez más complicado que los recién graduados posean los conocimientos necesarios para desempeñarse

laboralmente. Por un lado, esto se puede mejorar acercando más a la industria e instituciones educativas. Sin embargo, las empresas también deben estar conscientes en que ellas deben invertir en la formación de talento que tenga conocimientos en sus herramientas específicas.

La cantidad de personas que ingresa a carreras de tecnología de información no es suficiente, y especialmente el porcentaje de mujeres es muy bajo. La industria debe trabajar en conjunto para fomentar que los jóvenes de preparatoria se inclinen por estudiar carreras de tecnologías de información.

Las nuevas generaciones no tienen ningún problema con estarse moviendo de un proyecto a otro, o de una empresa a otra, y luego incluso regresar. Las empresas deben estar conscientes de esto, y mantener la comunicación con sus ex-colaboradores de manera que puedan seguir colaborando en el futuro.

Ante el interés que tienen los jóvenes por emprender, las empresas deben apoyarlos con recursos y empoderamiento para que puedan emprender internamente dentro de la misma empresa, proponiendo y dirigiendo iniciativas, proyectos y productos. De esta manera, los jóvenes podrán satisfacer su interés por emprender, sin necesidad de abandonar la empresa.

Es muy importante invertir en la cultura de la empresa, ya que es lo que puede ayudar a atraer y retener al talento. Adicionalmente, es vital que al reclutar talento se evalúe que sus intereses y valores sean compatibles con la cultura de la empresa, ya que de otra manera la relación será corta y con malos resultados.

Software Guru y Kelly Services agradecen a los participantes de esta mesa redonda, y esperamos seguir contribuyendo a potenciar a México y Latinoamérica como una gran fuente de talento tecnológico.

SG.COM.MX

023

H

CARRERA

La Fuerza de los Bootcamps — Por Gabriela Rocha y Macha Bertrand

En los últimos años se ha visto un cambio en el perfil de las personas que trabajan en la industria tecnológica. Del godínez al geek, el sector atrae cada vez menos estudiantes de carreras tradicionales de computación, y cada vez más personas que buscan aprender las habilidades específicas requeridas por el sector, de manera rápida e independiente.

Algunos datos confirman esta tendencia. En Estados Unidos, por ejemplo, las carreras de ciencias de la computación e ingeniería de sistemas han sufrido una caída en el número de egresados.

En 2002, 4.5% de los títulos de licenciatura en el país eran en ciencias de la computación. En 2012, ese número bajó 2.2% [1].

Al mismo tiempo, se ha visto un aumento significativo en la popularidad de los coding bootcamps, cursos intensivos de programación, de corta duración, que no requieren conocimiento técnico previo ni un título universitario. El concepto nació en Estados Unidos y el número de egresados creció en 138% en solamente un año, y la tendencia es que siga creciendo de acuerdo a información del Course Report 2015 Bootcamp Market Size Study [2]. ¿Cómo se explica este fenómeno? Lo primero es el crecimiento exponencial que está teniendo el sector digital; llas empresas buscan talento y no lo encuentran. Las carreras tradicionales no brindan al mercado el número de profesionales que requieren con la misma rapidez con la que crece la industria; tampoco logran adaptarse a los cambios constantes que en cuestión de meses ya no utiliza las mismas herramientas o tecnologías.

Por otro lado, y de cierta manera por las mismas razones, las necesidades de la industria hoy no requieren una formación tradicional.

Las empresas buscan personas que sepan programar, independientemente de lo que hayan estudiado en la universidad (o si fueron a la universidad); debido a que es una habilidad técnica que se puede aprender rápido y que se puede perfeccionar con el tiempo de manera autodidacta por medio de recursos en línea.

En Latinoamérica, la situación no es diferente. Actualmente, la demanda insatisfecha de talento en el sector es de 35%. Se estima que para 2025, habrá una demanda de 1.2 millones, y las empresas no encontrarán talento para cubrir 40% de esos puestos de trabajo.

remunerado, contribuyendo con el crecimiento de empresas del sector, y por ende la economía de la región. Esta coyuntura presenta una oportunidad interesante para la región, donde hay 20 millones de jóvenes que no estudian ni trabajan. La existencia de un sector que no requiere educación formal abre puertas para una población por lo general excluida de las oportunidades laborales tradicionales.

En Laboratoria, encontramos el potencial que existía al conectar a estos jóvenes con una industria que no requiere títulos universitarios y que brinda una oportunidad de inserción laboral rápida, y decidimos probar nuestra teoría. Iniciamos en Perú en 2013 con un bootcamp para 15 alumnas, mujeres que no habían tenido acceso a educación superior y vivían en zonas marginadas de Lima se formaron como desarrolladoras web en tan solo 5 meses, y luego empezaron su carrera profesional con trabajo en diversas empresas del sector digital. El éxito de la iniciativa y la demanda creciente de talento permitió la expansión del programa que hoy está también en México y Chile, formando a 130 mujeres y con una red de más de 100 empresas contratistas.

La experiencia de Laboratoria, así como la de los diversos bootcamps en la región, demuestra la fuerza que tiene el sector para brindar oportunidades de educación y laborales que rompen con los paradigmas comunes de lo que significa ser una persona “preparada”, “educada”, con “potencial de crecimiento profesional”.

Para una región sufriendo con la falta de personal calificado los bootcamps nos permiten respirar y arrojar luz sobre una alternativa viable de educación para el trabajo. Hay pocas oportunidades tan empoderadoras, con impactos tan significativos para la economía.

Referencias y estudio adicional

Como resultado, también se ha observado un aumento en la popularidad de los coding bootcamps en la región. Bootcamps como Dev.f, Codeacamp y Laboratoria ya forman a cientos de personas al año. Más de 70% de sus estudiantes salen con un trabajo bien

[1] “Coding bootcamps are replacing computer science degrees”. Venturebeat. http://swgu.ru/r4 [2] “2015 Bootcamp Market Size Study”. Course Report. http://swgu.ru/r5

Gabriela Rocha y Macha Bertrand son co-fundadoras de Laboratoria México. http://laboratoria.mx

024

SG.49

SG.COM.MX

025

V

VOCES

Más Allá del Software PARTE 4. IMPLEMENTANDO SERVICIOS PARA PRODUCTOS DE SOFTWARE — Por Víctor Hernández

Víctor Jesús Hernández Salinas es Coordinador de Vinculación y Transferencia de Productos en INFOTEC, donde colabora desde 2003 en la Gerencia de Desarrollo de Nuevos Productos y Servicios. Fue creador y coordinador del área de Servicios de Producto y su

En ocasiones anteriores hemos conversado sobre la dinámica de generar un modelo de negocio alrededor de un desarrollo software, sus esquemas de financiamiento y los servicios alrededor del mismo a fin de darle sustento; por lo que en esta ocasión nos centraremos en las dinámicas de la ejecución de los servicios que se ofrecerán junto con el producto. Es necesario entender que los servicios también tienen un ciclo de vida y que para asegurar su correcto desarrollo y funcionamiento, es necesario hacer énfasis y mantener el enfoque en los siguientes aspectos que son a la vez un proceso cíclico:

con un adecuado esquema de mejora continua prestando atención en actividades como: identificar cuellos de botella, analizar el rendimiento de los servicios, asegurar balance entre funciones, realizar simulaciones de procesos basadas en la información de operación, realizar simulaciones de escenarios críticos y ensayos de planes alternativos de acción, detectar desviaciones y mejores prácticas, promover la innovación a través de los procesos, analizar las tendencias basándose en los indicadores de desempeño, crear mejores prácticas.

Definición de los procesos Es básico contar con indicadores de desempeño que ayuden a medir la efectividad de los servicios y determinar un escalamiento en caso de no cumplir los objetivos. Se debe definir de manera puntual todos los roles de los involucrados y actividades con calendarios de tiempos absolutos, naturales y de negocio. Se deberá contar además con herramientas y aplicaciones internas para el registro de las operaciones y la incorporación de reglas de ejecución de acciones para el inicio y término de cada actividad, así como los insumos y entregables que se implican en cada una de ellas.

Por supuesto que todo esto no se centra solo en los procesos y definiciones, sino que también se deberá contar con suficiente personal capacitado para dar respuesta en tiempo y forma a los requerimientos de todo tipo y generar modelos de transferencia de conocimiento eficientes que permitan preparar expertos en plazos cortos, a fin de generar mano de obra y necesidades en el mercado para mantener la operación de los servicios otorgados a clientes de versiones anteriores y/o presentes del producto, pues aun cuando se liberen nuevas versiones, no se debe olvidar que la mayor parte de los clientes no migrarán de manera inmediata.

Ejecución de los servicios Se debe contar con un orquestador de procesos que controle la ejecución de las actividades y que sirva de motor para el cumplimiento de reglas de negocio y de los flujos definidos para la operación de los servicios. Se debe generar una base de conocimientos institucional, de forma que no se pierda la experiencia adquirida. Es importante resaltar que todo debe basarse en estándares de información, operación e interfaces de comunicación para futuras actualizaciones y ajustes. Además, siempre debe mantenerse vigilado el cumplimiento de los candados de seguridad que se hayan impuesto para el resguardo de la información y por supuesto, la constante vigilancia de los posibles riesgos detectados.

Conclusión La finalidad de toda empresa es ganar dinero, pero la realidad empresarial ha rebasado esta concepción estrecha sobre la empresa, ya que así como es indispensable generar valor para los accionistas, también debe considerarse a los empleados, clientes, incluso a la comunidad con la que se convive. Tal concepción empresarial que solo pone el acento en las ganancias corresponde a una visión de corto plazo en donde incluso vive en constante riesgo de desaparecer. Sin embargo toda empresa que desee crecer y permanecer en el tiempo necesita asumir una visión de largo plazo.

normatividad. Es además coordinador del programa de Certificación en los productos SWB y forma parte de la Red de Mentores en habilidades suaves para cuerpo Gerencial.

Monitoreo de los servicios Aun con todo lo anterior, siempre se debe ser un poco psicótico al respecto de la adecuada implementación y ejecución de los servicios para asegurar que se realicen de acuerdo al plan y que se cuenta

026

SG.49

Pensar solo en ventas no es suficiente hoy en día, se debe pensar en experiencias. Mientras más poderosa sea la experiencia que entregamos a un cliente, más probable es que nos recomiende a sus amigos, conocidos y familiares como un episodio extraordinario.

Recuerda que los “fanáticos” son mucho más valiosos que los clientes.

SG.COM.MX

027

P

PROJECT MANAGEMENT

Estimación de Software con COSMIC — Por Carlos Eduardo Vázquez

Hacer una estimación “bottom-up” es inviable cuando no está disponible la estructura de proyecto, y hacer una estimación solamente basada en una analogía es muy subjetivo. Además, no se puede aprender de los errores cometidos. El objetivo de este artículo es introducir el método de medición de COSMIC y presentar una propuesta para derivar unidades de producto a partir de los requerimientos funcionales del usuario en diferentes representaciones.

La problemática de la estimación Cuando se solicita una medición a un desarrollador para entregar un programa y él provee una estimación de 12 horas, lo más probable es que esté correcto porque se trata de una pieza cuya dificultad o probabilidad de error es pequeña.

Es así que para estimar proyectos de software típicamente se aplica una estrategia bottom-up que consiste en descomponer el proyecto en sus partes constituyentes, estimar cada una de las partes y sumar los resultados para una estimación total.

La falla en esta lógica es que al inicio no se conocen todos los programas y algunas actividades no están en función de esta cantidad, como por ejemplo la ingeniería de requerimientos y el diseño de arquitectura, cuyos productos son los insumos para la programación usada en el ejemplo de apertura. En otras palabras, el nivel de información disponible no permite usar la lógica de la estimación bottom-up como solución para los desafíos de la estimación. ¿Tiene caso estimar?

Ante esta problemática, hay quienes argumentan que este tipo de estimación bottom-up cuando no se conocen los programas requeridos es un esfuerzo inútil, y que es preferible mejor aplicar ese esfuerzo a ejecutar iteraciones de entre 15 y 30 días que nos permitan resolver los aspectos desconocidos, y entonces ya poder “saber” en lugar de simplemente creer.

El problema es que a nivel directivo se requiere tener estimaciones para poder tomar decisiones. La estimación permite tomar decisiones respecto al desarrollo o mejora de sistemas. ¿Tiene caso hacer este proyecto?, ¿su beneficio será mayor que su costo?, ¿cuándo es el momento para hacerlo?, ¿cuál es el 20% de los proyectos que ejecutaremos para atender el 80% de las demandas?

Contar con estimaciones previas también facilita que los equipos sean auto-administrados y que su desempeño sea planeado y monitoreado de acuerdo con las exigencias de transparencia y eficiencia del gobierno corporativo.

Unidad de producto de software Algunos argumentan que el proceso de software es único y está más allá de cualquier medición. Sin embargo, existen similitudes de éste con la construcción civil en escala industrial. Cada edificio es único, a pesar de que pueda compartir los elementos arquitectónicos comunes en mayor o menor medida. El proceso de entrega de un inmueble involucra desde la concepción de un proyecto arquitectónico, pasando por varios proyectos de ingeniería, construcción y pruebas específicas, hasta la aceptación final por parte del propietario y la garantía por un periodo de transición.

Cuando se construye un edificio, es necesario tener un presupuesto disponible para su construcción. Una información clave en ese momento es el valor del costo por metro cuadrado de construcción. En base a eso podemos tomar varias decisiones: qué tan grande va a ser, cómo vamos a fondear su desarrollo, etc. En esta etapa no lidiamos con el costo detallado de cada componente del edificio. Después de todo, es mucho más costoso (proporcionalmente) construir un baño que una habitación, ya que el baño tiene un costo mayor de mano de obra y materiales. Posteriormente cuando sea necesario hacer la estimación de costo específica del baño, ya contaremos con suficiente información para hacer una estimación bottom-up.

En este punto surge un importante concepto: la productividad.

Esta puede ser definida como la razón entre la cantidad de bienes o servicios producidos y las unidades de tiempo o costo para su entrega.

En el caso citado del edificio, la planeación de productividad se hace en dólares por metro cuadrado (USD/m2). Es decir que medimos nuestro producto en términos de metros cuadrados, y observamos el costo generado por cada unidad de producto.

En el caso del desarrollo de software, necesitamos identificar una unidad que nos permita medir el producto durante la planeación.

Dicha unidad debe permitir aproximar el tamaño del software a

Carlos Eduardo Vázquez es fundador y responsable de investigación y desarrollo en Fatto Consultoría, empresa de origen brasileño especializada en consultoría para la estimación de proyectos de software. Tiene más de 20 años de experiencia en investigación, consultoría y entrenamiento en estimación con puntos de función. Fue uno de los tres primeros brasileños certificados expertos en puntos de función por el IFPUG en 1996 y uno de los primeros brasileños certificados por COSMIC en 2012. carlos.vazquez@fattocs.com

028

SG.49

PROJECT MANAGEMENT

partir de sus requerimientos, y debe ser independiente del desarrollo técnico y decisiones de implementación.

Este tipo de unidad no elimina la necesidad de otras métricas que permitan cuantificar el desempeño técnico de productos y servicios a partir de su implementación, como por ejemplo: análisis de eficiencia del diseño, apoyo a la ingeniería de requerimientos, apoyo a la verificación y validación. Un ejemplo de métricas de este tipo son las que define ISO/IEC 25.000 (SQuaRE).

Considerando las características deseadas para esta unidad de producto, se deben tener como objetivo de medición los requerimientos funcionales del usuario, ya que están específicamente asociados a una tarea o servicio del usuario y describen lo que el software debe hacer independientemente de cómo sea desarrollado.

Contar los requerimientos funcionales parece ser una buena alternativa para representar las unidades de producto del software. Sin embargo, no todos los requerimientos son iguales y se corre el riesgo de no diferenciarlos. Para eso, la ISO/IEC definió un estándar para ese tipo de medición, denominado Medición del Tamaño Funcional, y cuyo método más moderno es supervisado por el Consorcio Internacional de Medición de Software en General o COSMIC. COSMIC es la segunda generación de métodos de medición de tamaño funcional. Es aplicable a todo tipo de software, compatible con la ingeniería de software moderna, es de dominio público, su documentación no tiene costo, y es reconocido por ISO/IEC. Proceso COSMIC El método de medición consiste en un conjunto de modelos, principios, reglas y procedimientos que se aplican para determinar el valor de una magnitud para la funcionalidad entregada por el software. Dicha magnitud de la funcionalidad del software es expresada en puntos de función COSMIC. A muy grandes rasgos, el proceso consiste en: 1. Establecer la frontera entre el sistema y los actores con los que interactúa (que pueden ser personas u otros sistemas).

2. Identificar los procesos funcionales que los actores reciben del sistema.

3. Para cada proceso funcional, identificar los movimientos de datos que genera. Cada que el usuario provee al sistema un conjunto de datos para realizar un proceso, hay un movimiento de datos. También es un movimiento de datos cuando el sistema provee grupos de datos al usuario, y cuando se acceden o almacenan grupos de datos en almacenamiento.

Cada movimiento de datos contribuye con el equivalente a un punto de función COSMIC.

P

Medición vs aproximación del tamaño Debemos recordar que en las primeras etapas del proyecto no es factible hacer estimaciones detalladas. El alcance estará definido en términos de macroprocesos de negocio y áreas funcionales. Estos elementos pueden ser contados y comparados con su correlación con el software entregado y medido en puntos de función COSMIC. En los momentos posteriores en el ciclo de vida, cuando ya existe un alcance definido en términos de cuáles tareas el usuario deben ser parcialmente o totalmente transferidos para el software, es posible identificar procesos y aplicar la misma lógica en la extrapolación de la cantidad de puntos de función COSMIC a partir de la cantidad de procesos.

Al final del proyecto, una vez que se tiene el sistema implementado, se hace una medición (ya no es una estimación) del producto terminado. Esto se hace para: • Evaluar el desempeño mediante la relación entre la cantidad de horas invertidas y la cantidad de puntos función COSMIC medidos.

• Revaluar los indicadores de productividad para que pasen a incluir el desempeño del proyecto que acaba de terminar.

• Revaluar la cantidad de puntos función COSMIC que corresponden en promedio a los procesos y a los conceptos de negocio conforme al nivel de información disponible en los diferentes puntos que se desea estimar.

Benchmarking Los resultados reales del proyecto (tamaño, tiempo, esfuerzo y costo) nos sirven para compararlos con nuestra estimación inicial y en base a eso ajustar nuestro proceso de estimación para próximas estimaciones. De manera similar, debemos calcular cuál fue la productividad real (ej. horas hombre por punto de función) y tomarla en cuenta para futuras decisiones.

Con datos históricos de proyectos en la empresa podemos hacer benchmarking para comparar nuestra estimación. Por ejemplo, si estimamos un proyecto para el desarrollo en Java como si tuviera 150 puntos de función COSMIC y un esfuerzo de 1,050 horas hombre esto equivale a una tasa de entrega de 7 horas hombre por punto función (hh/cfp). Si tenemos una base de datos histórica de proyectos podríamos determinar qué tan factible es lograr una productividad de 7 hh/cfp.

Si no contamos con datos internos, podemos apoyarnos en bases de datos de la industria. Por ejemplo, el ISBSG (International Software Benchmarking Standards Group) provee herramientas y bases de datos para la estimación de proyectos de software.

SG.COM.MX

029

P

DEVOPS

Site Reliability Engineering — Por Martín Ferrari Este artículo es una adaptación y traducción de la serie de notas “Tales from the SRE trenches” que el autor publicó en su blog.

Puedes consultar las notas originales en https://blog.tincho.org

Hace poco más de 12 años, en Google se gestó una iniciativa denominada “Site Reliability Engineering (SRE)” —que en español sería Ingeniería de Confiabilidad de Sitios.

Hoy en día, SRE es fundamental para la operación de los servicios en línea de esta empresa, y el concepto se está extendiendo al resto de la industria, tanto así que ya puedes decir que te dedicas a hacer SRE, y las personas —al menos, las adecuadas— te entenderán.

Yo tuve oportunidad de colaborar unos años en Google como parte del equipo de SRE, y actualmente me desempeño como consultor independiente en el rol de SRE. En el siguiente artículo comparto mi perspectiva de en qué consiste este concepto, cuáles son sus beneficios, y algunos tips para incorporarlo en tu forma de trabajo. ¿Por qué debe interesarme SRE? Recientemente fui invitado a dar una plática sobre SRE en la Asociación Rumana para Mejor Software [1]. Dado que esta es audiencia principalmente dedicada al desarrollo de software y no a la operación o administración de sistemas, posiblemente parezca raro que ellos se interesen en SRE. Es decir, ¿por qué le interesaría a un desarrollador aprender de SRE? o más aún, ¿por qué debería un desarrollador interesarse en facilitar la vida de la gente de operaciones?

El hecho de que el equipo de operaciones soporte adecuadamente tu trabajo como desarrollador, te beneficia. No se trata de abrir la puerta para que los de operaciones te echen la culpa cuando las cosas salgan mal, sino de hacer una alianza; una alianza que hará que tu software opere sin problemas en producción y por lo tanto puedas enfocarte en construir funcionalidad innovadora.

Tal vez tengas la noción de que los desarrolladores solo deben enfocarse en agregar funcionalidad al software para atraer más usuarios, y dejar en manos de operaciones la confiabilidad de este. Pero un servicio poco confiable es difícil que pueda retener usuarios, independientemente de qué tan atractiva sea su funcionalidad. ¿Y qué mejor que tener como aliado a un equipo que tenga “confiabilidad” en su nombre? ¿Qué es la ingeniería de la confiabilidad?

La ingeniería de la confiabilidad es la rama de la ingeniería que se preocupa porque los productos diseñados funcionen como se espera, aun cuando sus componentes no sean confiables por naturaleza. Se enfoca en mejorar la confiabilidad de los componentes, establecer requerimientos mínimos, y hace un uso intensivo de estadística para predecir fallas y entender los problemas.

Ben Treynor es quien inició esta práctica en Google hace poco más de 12 años, y él define SRE de la siguiente forma: “Fundamentalmente, es lo que sucede cuando le pides a un ingeniero de software que diseñe funcionalidad de operación”.

La primera recomendación al crear un equipo de SRE es contratar solamente a personas que puedan programar. Escribir software es una de las principales actividades de SRE. Esto es porque la visión de SRE consiste en tratar a la operación como un problema de ingeniería de software, es decir que se usa software para resolver problemas tradicionalmente resueltos a mano, implementando pruebas rigurosas, revisiones de código, y tomando decisiones basadas en datos, no en corazonadas.

También implica que SRE puede entender el producto al que está dando soporte y que hay respeto entre los ingenieros de desarrollo y operación.

Martín Ferrari (@TinchoFerrari) ha trabajado en la industria por más de 18 años. Algunas veces como programador, otras como administrador de sistemas, y la mayor parte del tiempo como ambas cosas. Luego de dos años cumpliendo el sueño de trabajar en Google como SRE, decidió dejar la vida de oficinista para volverse un nómada digital. Actualmente realiza trabajos de consultoría para empresas mientras viaja por el mundo. Es también desarrollador del proyecto Debian y activista del Software Libre. Aspira a visitar todos los pubs del mundo. tincho@ tincho.org https://tincho.org

030

SG.49

DEVOPS

Posiblemente, algunas de las recomendaciones que hago aquí solo tienen sentido en el contexto de una empresa con las características de Google: varios equipos de desarrollo y operaciones, un crecimiento mayor a la velocidad con la que se puede contratar gente, y un compromiso de la alta dirección para implementar reglas drásticas. Así que mi interés no es pregonar sobre por qué todos deben adoptar SRE, sino extraer algunas de las ideas más útiles que pueden aplicarse en un amplio rango de situaciones.

¿A qué se dedica SRE? El equipo de SRE se dedica principalmente a mantener tu servicio en línea, realizando las tareas tradicionales de sysadmin como aprovisionamiento de infraestructura, configuración, monitoreo y asignación de recursos de cómputo, etcétera. Utilizan herramientas especializadas para monitorear servicios y obtener alertas en cuanto se detecta un problema. A ellos les toca despertarse a media noche para levantar un sistema caído o corregir una falla.

Pero eso no es todo: la confiabilidad no solo es impactada por nuevos lanzamientos. Puede que de pronto aumente la utilización de un sistema, falle el hardware, haya problemas de conectividad. Al trabajar a gran escala, todo tipo de fallas pueden darse. El objetivo de SRE es que dichas fallas afecten la disponibilidad del sistema lo menos posible. Para ello, SRE trabaja continuamente en 3 grandes estrategias: minimizar el impacto de las fallas, disminuir el tiempo requerido para recuperarse, evitar reincidencias. A continuación entro en más detalle de cada una de estas estrategias.

Minimizar el impacto de fallas Hay que buscar que una falla no pueda provocar la caída de un servicio entero. Una de las tácticas que SRE utiliza es fragmentar y distribuir un servicio a través de varios “dominios de falla”. Un ejemplo sería distribuir los datos de un sistema a través de varios centros de datos, de manera que si un centro de datos en particular se incendia, solo una fracción de los usuarios se vean afectados. El equipo de SRE dedica gran parte de su tiempo a planear y habilitar sistemas que abarquen distintas regiones geográficas para maximizar redundancia y mantener la latencia de comunicación en niveles razonables.

P

Recuperarse rapidamente Comúnmente, la forma más efectiva de reestablecer un sistema que falla es reiniciándolo. Así que otra estrategia es instrumentar los sistemas para que reinicien automáticamente milisegundos después de que se detecta una falla. Si se requiere intervención humana, es crucial que se notifique lo antes posible a las personas adecuadas y que tengan acceso rápido a la información que necesitan para resolver el problema tal como: documentación del ambiente de producción, guías de soporte, reportes de monitoreo, etcétera. Después de todo, es muy probable que a las 2 de la mañana te cueste trabajo recordar en qué país está ubicado cierto segmento de la base de datos, o cuál es la serie de comandos que necesitas para redireccionar el tráfico.

El equipo de SRE dedica bastante tiempo a implementar alertas automatizadas, escribir documentación y guías de soporte, e implementar otros preparativos para recuperación de desastres.

Evitar reincidencias Cuando un incidente provoca una falla en el sistema, la primera prioridad es restablecer el sistema; pero también es muy importante estudiar la falla, con el objetivo de encontrar la causa raíz y resolverla. Así que otra actividad importante de SRE consiste en redactar reportes de postmortem. Cada incidente debe tener un postmortem, y estos deben usarse con fines de aprendizaje, no de echar culpa.

Prevenir fallas Por supuesto, otra estrategia más, consiste en evitar que se den fallas en primer lugar. Claro que nadie puede evitar que un disco duro falle, pero hay otros tipos de fallas que se pueden prever.

Por ejemplo, un aumento súbito en la carga de uso de un sistema puede tirarlo, por lo que el equipo de SRE debe asegurar que los sistemas sean probados con cargas de trabajo mayores a lo normal. También deben estar preparados para poder escalar rápidamente un servicio (por ejemplo: habilitar más nodos de procesamiento) en caso de que el sistema de monitoreo detecte que se ha alcanzado cierto umbral.

El equipo de SRE puede evitar fallas provocadas por situaciones como que se agote el espacio de almacenamiento o se degraden los componentes físicos. El monitoreo es el elemento clave: captar métricas relevantes y seguir su tendencia a lo largo del tiempo.

SG.COM.MX

031

P

DEVOPS

Mejorando la relación entre SWE y SRE La lucha entre el equipo de desarrollo (Software Engineering, SWE) y el de operaciones comienza porque ambos tienen metas distintas. Llega el fin de semana y los desarrolladores quieren liberar una nueva versión a producción, pero los de operaciones quieren tener un fin de semana tranquilo. Cuando las liberaciones son problemáticas, lo que típicamente se hace es agregar burocracia para minimizar los riesgos: revisiones, checklists, ventanas de cambio, etcétera. El resultado es que los desarrolladores continuamente buscan formas de saltarse estos controles, y se generan problemas mayores. Uno de los principales aspectos de SRE es evitar esto por completo, a través de un cambio en los incentivos para eliminar las presiones entre los equipos de desarrollo y operaciones. A continuación menciono algunas de las estrategias que se aplican en Google para lograrlo: Tener acuerdos de servicio Antes de que un servicio pueda ser soportado, se debe determinar el nivel de disponibilidad que debe mantener para que los usuarios y la empresa estén contentos: esto es lo que se conoce como Service Level Agreement (SLA). El SLA define cómo se mide la disponibilidad (por ejemplo: porcentaje de queries completados exitosamente en menos de 50 ms) y cual es el mínimo valor aceptable o SLO (el valor objetivo de nivel de servicio). Esta es una decisión de producto, no técnica. Es un número muy importante para un equipo de SRE y su relación con desarrolladores. No se toma a la ligera, y debe cumplirse de forma rigurosa.

Un objetivo de disponibilidad 100% rara vez es una buena idea, y en la mayoría de los casos es imposible conseguirlo. En empresas como Google, una meta común de disponibilidad en los servicios online es de cinco nueves (99.999%); esto significa que un servicio no puede estar caído más de 5 minutos durante todo un año.

Son muy pocas las cosas que realmente requieren una disponibilidad de 100% (por ejemplo: un marcapasos), y lograrla es muy costoso.

032

SG.49

Medir y reportar el desempeño Una vez que hayas definido el SLA y SLO, es muy importante que estos sean monitoreados y reportados continuamente. Si esperas para el fin del trimestre para producir un reporte manual, el SLA no sirve de nada, ya que no nos sirve enterarnos tan tarde de los problemas.

Este es un aspecto clave de SRE, ya que permite ver el avance de un servicio a lo largo del tiempo, detectando problemas de capacidad antes de que provoquen la caída del sistema, y al mismo tiempo mostrando qué tanto se puede tener el sistema abajo sin romper el SLA. Esto último nos lleva a la siguiente recomendación…

Administrar el presupuesto de falla Si el SLO es el tiempo mínimo de disponibilidad, entonces al restar 1 - SLO obtenemos la fracción de tiempo que nuestro servicio puede fallar y todavía cumplir el SLA. Esto es lo que llamamos nuestro presupuesto de falla, y debemos aprovecharlo.

En el caso de servicios inestables que acostumbran tener errores, la mayoría de nuestro presupuesto de falla se desperdicia en fallas del sistema, lo cual no nos deja margen para intentar lanzar cambios. Por otro lado, cuando tenemos servicios estables que no usan el presupuesto de falla, tenemos la libertad de apostar parte de ese presupuesto para liberar nueva funcionalidad al usuario con mayor frecuencia.

Una vez que el presupuesto de falla se ha agotado, no se permite hacer nuevos lanzamientos hasta que transcurra suficiente tiempo sin fallas para darnos nuevo saldo.

Al darle visibilidad a todos sobre el comportamiento del presupuesto de falla, se ayuda a reducir conflictos entre los equipos de desarrollo y operaciones. Si el servicio está funcionando adecuadamente, entonces el equipo de operaciones no necesita interferir para oponerse a lanzamientos; se cuenta con evidencia cuantitativa para justificar las decisiones. Esto contribuye a evitar resentimiento y desconfianza entre desarrollo y operaciones. No es que los de operaciones quieran hacerle la vida difícil a los desarrolladores, es que simplemente no tienen presupuesto de falla disponible.

DEVOPS

Al mismo tiempo, esto provee un incentivo al equipo de desarrollo para evitar malgastar el presupuesto de falla con versiones que contengan errores o estén mal preparadas para liberación.

Dar visibilidad al trabajo de otros Si el equipo de operaciones es visto por los desarrolladores como un grupo de bomberos cuyo trabajo consiste en apagar incendios 24X7, tienen menos incentivos a hacer buen software. De forma similar, si el equipo de desarrollo no tiene visibilidad a lo que sucede en el ambiente de producción, difícilmente podrán establecer confianza. Por ello es buena práctica que el equipo de desarrollo ocasionalmente haga algo de trabajo de operaciones por ejemplo: atender tickets, gestionar servidores, hacer liberaciones a producción. Lo que resultará en mejor comunicación entre equipos, y un entendimiento común de las prioridades.

Balancear el personal Un mecanismo que se utiliza en Google es tener un límite de personal unificado entre desarrollo y operaciones. De esta forma, mientras necesites más personas para mantener el servicio en línea, contarás con menos desarrolladores para construir nueva funcionalidad. Combinado con esto, en Google los SRE se pueden mover libremente entre equipos, o incluso moverse a desarrollo.

De esta forma, un servicio que es latoso de soportar solo tendrá acceso a los ingenieros menos experimentados.

P

Otras lecciones aprendidas Además de los lineamientos que he descrito aquí, hay otras prácticas que creo que serían útiles para cualquier equipo de operaciones e incluso de desarrollo.

Automatiza todo. No es sustentable hacer todo manualmente.

No solo es un tema de tiempo ni de dinero, sino de disponibilidad de talento en el mercado laboral.

Involucra a operaciones en el diseño de sistemas. Nadie conoce mejor los retos de un ambiente de producción que el equipo de operaciones. Su retroalimentación te puede ayudar a ver riesgos de escalabilidad, planeación de capacidad, redundancia, y tomar acciones para evitarlos desde el diseño del sistema.

Documenta el diseño. Documentar los detalles de un sistema previo a su construcción es una gran forma de detectar problemas temprano, además es muy útil para comunicar a tu equipo qué es lo que se está construyendo, y convencerlos de que es una gran idea.

Limitar la carga operativa En Google, los SREs no deben dedicar más de la mitad de su tiempo a “trabajo operativo”. El resto de su tiempo deben ocuparlo en tareas de automatización, monitoreo, planeación de crecimiento … y no en continuamente arreglar de forma manual problemas derivados de sistemas mal hechos.

Revisa tu código y versiona los cambios. Todo debe estar sujeto a código de versiones: código, scripts de instalación, archivos de configuración. Puede parecer que no valga la pena, pero tener una historia completa de tu ambiente de producción es invaluable. Y al tener control de versiones, entra otra regla: ningún cambio se acepta sino es revisado por un colega. Puede ser frustrante tener que encontrar a un revisor y esperar aprobación por cada cambio, pero una vez que te acostumbres te darás cuenta que los beneficios superan por mucho las inconveniencias.

Si se encuentra que un equipo de SRE está dedicando demasiado tiempo a trabajo operativo, esa carga extra se reasigna al equipo de desarrollo. En casos extremos, un servicio puede ser considerado demasiado inestable para mantener, y entonces el equipo de SRE elimina su soporte por completo. Esto implica que el equipo de desarrollo ahora debe realizar todo el trabajo operativo y de soporte.

Antes de modificar, mide. El monitoreo no solo sirve para enviar alertas, sino que es una parte esencial de SRE. Te permite sensar tu disponibilidad, evaluar tendencias, predecir crecimiento, y realizar análisis forense. El monitoreo debe proporcionarte los datos que necesitas para tomar decisiones basadas en hechos. Antes de optimizar o hacer un cambio, encuentra donde está realmente el cuello de botella.

SG.COM.MX

033

P

ARQUITECTURA

Smart Decisions UN JUEGO PARA APRENDER ARQUITECTURA Y BIG DATA — Por Humberto Cervantes (UAM-I)

En esta ocasión les hablaré de Smart Decisions, un juego que he desarrollado junto con mis colegas Rick Kazman del Software Engineering Institute (SEI) así como Serge Haziyev y Olha Hrytsay de la empresa Softserve. El objetivo del juego es ilustrar la manera en que se realiza el diseño de la arquitectura mediante el método de diseño Attribute Driven Design (ADD). Como parte del juego, se simula el diseño de un sistema de Big Data.

Comenzaremos recordando el método de diseño ADD y después hablaremos acerca de los detalles del juego incluyendo un enlace para descargar los materiales y jugarlo.

Repaso: diseño de arquitectura La actividad de diseño de la arquitectura (ver SG29) se enfoca en la traducción de drivers, hacia un conjunto de estructuras que conforman la arquitectura. Recordemos que los drivers incluyen requerimientos funcionales primarios, atributos de calidad y restricciones (ver SG28).

Attribute Driven Design La transformación antes mencionada se puede realizar de manera sistemática usando el método de diseño Attribute Driven Design (ADD).

ADD es un método iterativo de diseño de arquitecturas de software. El método consta de siete pasos que se muestran en la figura 1.

Las actividades son las siguientes: 1. El arquitecto se asegura de que tiene una buena comprensión acerca de los drivers que se usan como entradas al proceso de diseño.

2. Se elige el subconjunto de drivers que serán tratados en la iteración.

3. El diseño procede mediante el refinamiento de uno o más elementos que son elegidos en este paso. El refinamiento puede involucrar la descomposición de un elemento en subelementos y sus relaciones, o bien puede involucrar diseño adicional de elementos previamente identificados. Al inicio del proceso de diseño de sistemas ‘greenfield’ (desde cero), el único elemento que puede ser elegido es el sistema mismo, que es concebido como un único elemento. En iteraciones subsecuentes, o en el diseño de cambios a un sistema existente, se eligen uno o más elementos previamente definidos.

4. Este paso involucra la identificación y selección de conceptos de diseño, que describiremos a continuación, que permitirán satisfacer los drivers elegidos para la iteración 5. Una vez que los conceptos de diseño han sido elegidos, los elementos que se derivan son identificados y conectados. En este paso es donde nuevas estructuras se crean o estructuras existentes se refinan. Adicionalmente, las responsabilidades de los elementos se establecen y las interfaces expuestas por los elementos se definen.

6. A pesar de que la documentación formal ocurre después del proceso de diseño, cierta información debe registrarse durante el diseño, cuando aún se encuentra fresca en la mente del arquitecto y hay menos probabilidad de que la olvide. En este paso se registra dicha información que incluye bosquejos de las estructuras creadas en el paso previo junto con decisiones de diseño y su justificación (rationale).

7. En este paso, el arquitecto realiza un análisis de las decisiones de diseño que fueron realizadas durante la iteración y también del proceso de diseño en su conjunto. Como resultado, se toma la decisión de seguir realizando más iteraciones o de parar el diseño y de proceder a la implementación.

Figura 1. Pasos del método de diseño ADD.

034

SG.49

ARQUITECTURA

P

Conceptos de diseño En el paso 4 del método ADD se eligen conceptos de diseño, que son los “bloques de construcción” del diseño de la arquitectura (ver SG46). Estos bloques son soluciones probadas a problemas recurrentes de diseño y pueden ser de naturaleza conceptual o concreta. Los tipos de conceptos de diseño que se consideran incluyen: arquitecturas de referencia, patrones, tácticas, familias tecnológicas y productos o frameworks.

• Las decisiones de diseño tienen consecuencias: algunas decisiones son mejores (de ahí que el juego se llame “Smart Decisions”) y algunas no lo son tanto. Por otro lado, las decisiones que se hacen en una iteración pueden tener consecuencias en iteraciones posteriores.

Una de las dificultades que existen al momento de diseñar una arquitectura de software es la selección de conceptos de diseño. Existen cientos de patrones y tecnologías de dónde escoger y, además, la selección es complicada pues frecuentemente no es sencillo entender la influencia que puede tener un concepto de diseño particular sobre los atributos de calidad del sistema. Por ejemplo, cierta tecnología, ¿impacta o favorece el desempeño?

Smart Decisions requiere un mínimo de dos jugadores y un máximo de seis. Los jugadores pueden ser individuos o grupos de individuos. Adicionalmente, requiere de un facilitador que explique el contexto y la mecánica del juego. El juego se juega en una serie de rondas que representan distintas iteraciones del proceso de diseño de un sistema nuevo (greenfield).

Como se puede apreciar, el diseño de arquitecturas de software no es una tarea sencilla, sin embargo, el uso de un método como ADD permite realizar esta actividad de manera sistemática lo cual aumenta las posibilidades de obtener un mejor resultado.

Smart Decisions Dada la importancia de diseñar arquitectura siguiendo un método como ADD, decidimos desarrollar un juego cuyo objetivo es ilustrar conceptos importantes asociados con el diseño de arquitectura. Está diseñado para jugarse tanto por estudiantes como por practicantes que no tengan mucha experiencia en el diseño de arquitecturas. Cabe señalar que el juego no busca sustituir a los cursos de diseño de arquitectura, sino más bien, busca ser un complemento a los mismos.

Algunos de los conceptos principales que son ilustrados en el juego son los siguientes: • El diseño arquitectural se desarrolla de manera iterativa y puede realizarse de manera sistemática usando un método como ADD. • El diseño arquitectural comienza con drivers e involucra realizar decisiones de diseño. Algunas de estas decisiones incluyen elegir conceptos de diseño, lo cual generalmente es complicado, sobre todo para los diseñadores que se enfrentan con una “página en blanco” al iniciar el diseño.

• Todo concepto de diseño tiene una influencia sobre los drivers y, más específicamente, sobre los atributos de calidad.

• Las decisiones de diseño deben ser registradas y analizadas como parte del proceso de diseño.

En la primer iteración, el facilitador describe la manera en que los pasos de ADD se llevan a cabo en el juego. Como parte de la explicación inicial, el facilitador presenta también el contexto del juego, es decir, la descripción de los drivers del sistema que se va a diseñar. Actualmente, Smart Decisions cuenta con un contexto de juego de un sistema de Big Data, sin embargo, está diseñado para ser extensible y que en el futuro se puedan agregar contextos de juego relacionados con otros dominios aplicativos.

Para cada iteración, el juego proporciona la siguiente información, que equivale a lo que se obtendría de los pasos 2 y 3 de ADD: • • • •

Objetivo de la iteración.

Drivers a considerar.

Elemento a refinar.

Alternativas de conceptos de diseño a considerar.

A continuación, los jugadores deben elegir conceptos de diseño a partir de las alternativas que se les proponen. Esto representa la actividad que se realiza en el paso 4 de ADD y es la parte medular del juego. Los conceptos de diseño se presentan como un conjunto de cartas y cada una de estas cartas contiene información acerca de un concepto de diseño particular (ver figura 2).

La información que se presenta en la carta incluye un nombre, un diagrama (si aplica), una descripción y una lista de drivers así como la influencia del concepto de diseño sobre los mismos. La influencia se mide mediante puntos, que están representados como estrellas. Un punto significa que el concepto de diseño no contribuye mucho a satisfacer el driver mientras que tres puntos significa que el concepto de diseño contribuye en gran medida para satisfacer el driver.

SG.COM.MX

035

P

ARQUITECTURA

reciben puntos adicionales o bien son penalizados. Para cada iteración se calcula un puntaje total que combina los puntos de las cartas elegidas, el resultado de tirar los dados y los bonos o penalizaciones resultantes del análisis. Al final del juego, se suman los puntos recibidos en las distintas iteraciones y se calcula un total. El jugador con el total más alto gana.

Una vez que termina el juego, el facilitador promueve una discusión con los participantes con el fin de intercambiar experiencias y opiniones relativas al juego y al proceso de diseño de arquitecturas en general. Esta discusión es un aspecto fundamental dentro de las sesiones de juego.

Conclusión Smart Decisions es un juego que busca ilustrar el proceso que se sigue para diseñar arquitecturas de software usando ADD. Actualmente, el juego dispone de contenido enfocado al diseño de un sistema de Big Data, pero en el futuro esperamos disponer de otros contextos de juego. Hemos tenido la oportunidad de realizar sesiones de juego con diversas poblaciones que incluyen arquitectos de software, profesores y también con estudiantes(1). A raíz de estas sesiones, hemos recibido retroalimentación muy positiva acerca del juego.

Por último, cabe señalar que el juego está disponible de forma gratuita en la siguiente dirección : http://www.smartdecisionsgame.com

Figura 2. Tarjeta de un concepto de diseño relacionado con Big Data.

Los invitamos a que lo descarguen, lo jueguen y nos den su opinión al respecto. Adicionalmente, estamos buscando contribuciones de la comunidad para generar otros contenidos en áreas distintas a Big Data.

Una vez que los jugadores han elegido una carta, calculan un total en base a la influencia del concepto de diseño seleccionado sobre los drivers asociados a la iteración. Después de eso, simulan el paso 5 de ADD tirando dos dados. Respecto al paso 6 de ADD, como parte del juego no se realizan bosquejos del diseño, pero sí se documentan las decisiones de diseño, es decir los conceptos de diseño elegidos.

Referencias

El paso 7 de ADD es guiado por el facilitador quien describe cuáles eran las opciones más apropiadas a elegir como parte de las iteraciones. Dependiendo de lo elegido, los jugadores

[1] Cervantes, H., Haziyev, S., Hrytsay, O., Kazman, R. “Smart Decisions: An Architecture Design Game”, (http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=436542), SATURN Conference 2015.

El Dr. Humberto Cervantes es profesor-investigador en la UAM-Iztapalapa. Además de realizar docencia e investigación dentro de la academia en temas relacionados con arquitectura de software, realiza consultoría y tiene experiencia en la implantación de métodos de arquitectura dentro de la industria. Ha recibido diversos cursos de especialización en el tema de arquitectura de software en el SEI, y está certificado como ATAM Evaluator y Software Architecture Professional por parte del mismo. http://humbertocervantes.net

036

SG.49

SG.COM.MX

037

P

UX

4 Actividades UX Para Disolver Controversias de Desarrollo —

Por Misael León

Uno de los momentos claves en el trabajo de un UX Designer es presentar sus hallazgos de investigación y comunicar las soluciones propuestas. De su éxito depende que no se generen malos entendidos respecto a cómo debe funcionar el producto de software a desarrollar. Pero, ¿por qué esa habilidad es crucial y cómo afecta al resto del equipo? ¿Cómo podemos unificar esfuerzos y evitar confusiones?

¿Qué está sucediendo?

Comunmente Developers, QA Testers y Product Managers precisan un punto central de discusión del cual se desprendan las tareas individuales. Presumiblemente todos ellos trabajan bajo el mismo objetivo: crear el mejor producto y la experiencia más placentera para el usuario. Es fácil ver que esa pieza central puede ser el prototipo a desarrollar. El prototipo debe

convertirse en el punto de partida para alcanzar un acuerdo común. De no hacerlo así se corre el riesgo de crear un monstruo sin pies ni cabeza.

Cuando los desarrolladores no conocen las razones detrás de las decisiones de diseño a menudo son reacios a implementar los cambios y solución planteada. Si el UX Designer falla en comunicar efectivamente su trabajo, enfrentará objeciones como “eso tardará varios meses”, “eso no es posible”. Si este es tu caso hay una manera sencilla de lograr el efecto opuesto.

La solución Para pasar del “no se puede” al “sí, creo que esto traerá valor” simplemente debemos involucrar a todo el equipo desde el inicio. Desde la generación temprana de prototipos hasta las

Misael León (@misaello) es UX Design Researcher en Nearsoft, Inc. una empresa de cultura democrática que desarrolla software y produce clientes felices. Es colaborador del UX Clinic, una iniciativa dedicada a difundir las mejores prácticas de UX. Es fanático de los libros, el cine, los chocolates. Promotor de la filosofía del asombro.

038

SG.49

UX

pruebas de usabilidad. De esta manera entenderán por sí mismos que las decisiones de diseño son soluciones a problemas reales de gente real.

Ver a los usuarios frustrarse con un software pobremente desarrollado y diseñado es la mejor manera de subir a todos al mismo barco. El problema adquiere rostro y es validado por observación propia. Presenciar cómo el producto en el que has trabajado arduamente pierde su valor por una característica mal implementada es un golpe psicológico contundente. Después de presenciarlo el equipo sentirá el impulso de corregirlo de inmediato.

1. Crear el prototipo Un prototipo efectivo puede variar en sus niveles de fidelidad al producto real. Desde un dibujo hecho a mano, wireframes hechos en software de prototipado rápido, hasta prototipos de alta fidelidad ricos en color e interacciones.

Es altamente recomendado que el prototipo esté fundamentado en investigación previa sobre hábitos y expectativas de los usuarios. Para esto existen varias metodologías de UX que podemos aplicar. Hay que recordar que hacer investigación es salir a la defensa de los usuarios [1].

P

El nivel de fidelidad de tu prototipo depende de la etapa de desarrollo en la que se encuentre el producto. Aquí una guía rápida: Es una buena práctica incluir a todo el equipo desde el primer día en que comiences a prototipar. Así nuestra solución irá creciendo siendo validada desde todas las perspectivas: la de negocios, la técnica y la de los usuarios.

Con prototipo en mano, el equipo ahora está listo para verlo en acción. Someterlo a pruebas tempranas nos permitirá: • detectar errores críticos de conceptualización, • corregir inmediatamente antes de gastar horas de producción, • aprender más sobre el problema a resolver.

Al tener contacto directo con los usuarios notaremos que nuestro entendimiento del problema irá modificándose. Esto es absolutamente normal, se le conoce como la paradoja del problema/ solución [2].

2. Reclutar usuarios Ha llegado el momento esperado. Tienes un prototipo listo y estás ansioso por probarlo. Pero, ¿con quién y cómo?

Algunas recomendaciones para reclutar usuarios: • Definir un perfil deseado en caso que el producto no tenga usuarios activos todavía.

• Ofrecer siempre una recompensa por el uso de tiempo que nos concederán.

• Brindar opciones de horarios previamente definidos, que ellos elijan.

• Hacerles saber que es una invitación abierta sujeta a quien responda primero.

• Usualmente de 5 a 8 usuarios por prototipo es suficiente [3].

• Pedir ayuda al departamento que ya tiene contacto con ellos, como ventas o soporte.

3. Probar prototipo Estas son algunas recomendaciones básicas:

SG.COM.MX

039

P

UX

Preparar un guión. Hay ciertas consideraciones que los usuarios deben saber antes de iniciar la prueba. Por ejemplo: que hable en voz alta todo lo que piensa, que no recibirá ayuda durante la prueba, que no se le está evaluando a él/ella, que todas las preguntas serán resueltas eventualmente. En http://swgu.ru/qz hay una plantilla que puede ser útil. Es indispensable que el guión puntualice las tareas que el usuario ejecutará. Esta es la parte esencial de las pruebas de usabilidad: observar las maneras en que los usuarios se las arreglan sin ayuda para completar una tarea específica.

Grabar la sesión. Estamos en el entendido que los integrantes del equipo nos acompañarán como observadores durante las sesiones. Sin embargo es buena idea grabar en video la acción, o al menos la acción en pantalla. Esto servirá en el futuro cuando se necesite o alguien más quiera referenciar o recordar ciertos aspectos clave de la interacción.

Sesiones remotas. No descartar la posibilidad de probar el prototipo con usuarios no presenciales. Podemos hacer una videollamada y grabar la acción de la pantalla. Algunas herramientas como InVision nos permiten ver claramente los clics que realiza el usuario.

Aprovecha la oportunidad. Tener a un usuario que no tiene idea de todas las discusiones acaloradas en las juntas de equipo es invaluable. Es nuestra oportunidad de salir de cualquier duda y desechar supuestos. Los usuarios son despiadados y nunca quieren esforzarse de más. Es solo una interfase, ¿por qué habrían de meditar más de lo necesario en encontrar una opción?

Simplemente guardemos silencio y observemos la ejecución de la tarea solicitada.

Prepararse para lo inesperado. Ley de Murphy. Todo aquello que pueda salir mal, saldrá mal. Se caerá la red, fallará la herramienta de prototipado, cancelará un usuario, nos daremos cuenta que el prototipo no contempla una parte esencial, etcétera. Todo puede pasar y hay que estar listo. Conservar la calma y ser honesto con lo que está sucediendo. No pasa nada.

4. Analizar resultados La pregunta del millón es: ¿qué tan detallado debe ser un reporte de usabilidad? La respuesta es dependiendo de a quién va dirigido:

• Si es para nuestro propio registro de documentación, puede ser tan extenso como el tiempo nos lo permita.

En todos los casos anteriores entre más visual sea la información es mejor. Nadie tiene tiempo de leer exhaustivos reportes. Al final es útil ser organizado, llegará el día en que cuestionen las razones detrás de una decisión de producto y es mejor estar preparado.

Ningún reporte de usabilidad es suficiente si solamente se queda en documento. Hay que transformarlo en un prototipo corregido y mejorado con las oportunidades encontradas. El reporte de usabilidad es siempre el inicio de la siguiente iteración.

Conclusiones El prototipo es la pieza estratégica ideal de discusión del equipo de desarrollo. El prototipo es “tangible” porque es un artefacto concreto con ideas estructuradas. También representa la solución más aproximada en términos técnicos, de limitaciones de negocio, y de deseabilidad por parte de los usuarios, a problemas reales de los cuales se tiene evidencia.

La presencia del equipo de desarrollo como observadores durante las pruebas de usabilidad es una estrategia sabia para sintonizar los esfuerzos de todos hacia un mismo objetivo y agilizar el proceso mismo de desarrollo.

La aprobación de las soluciones de diseño propuestas no solamente depende de la efectividad del UX Designer para comunicarlas, sino también del entendimiento que todo el equipo tenga sobre el problema a resolver.

En Nearsoft tenemos una filosofía central. La mejor manera de hacer software es comenzar lento y avanzar rápido hacia el final [4]. Esto nos evita deshacer, rehacer, borrar y desechar código y esfuerzos.

Referencias [1] M. León. “A La Defensa De Los Usuarios: Siete Técnicas UX Para Cambiar El Mundo” SG #47. http://swgu.ru/qk [2] T. Wendt. “Design for Dasein: Understanding the Design of Experiences”.

• Si es para nuestro equipo, un prototipo anotado, una lista de user stories, y clips de video es suficiente.

• Si es para top level executives debemos incluir la metodología utilizada, los descubrimientos, y los errores a corregir. En un formato muy puntual, no más de dos cuartillas.

040

SG.49

CreateSpace, 2015. http://swgu.ru/qw [3] J. Nielsen. “How Many Test Users in a Usability Study?” NN Group, 2012.

[4] http://swgu.ru/qx [5] J. González. “Three Reasons Your Project Is Late and What You Can Do About It”. http://swgu.ru/qy

SG.COM.MX

041

P

PROGRAMACIÓN

Cuadrados Mágicos y Recursión —

Por Manuel López Michelone

En las matemáticas hay muchos problemas que son básicamente recreativos.

Uno de ellos es el de los cuadrados mágicos, en donde se trata de colocar números en una matriz de celdas de n x n, de forma tal que la suma de los números por columnas, filas y diagonales principales sea la misma, la constante mágica. Usualmente los números empleados para rellenar las casillas son consecutivos, de 1 a n2, siendo n el número de columnas y filas del cuadrado mágico.

Estos cuadrados se conocen ya en la antigua China, desde el III milenio A.C. Hay también referencias a los mismos en las culturas india, egipcia, árabe y griega. Y aunque muchas veces se han asociado con cuestiones astrológicas o de índole mágico, la realidad es que es una simple recreación matemática que es interesante por sí misma.

El artista renacentista Alberto Durero, en su obra Melancolía I, incluye un cuadrado mágico de orden 4 (4x4 celdas), en donde la constante mágica es 34. La figura 1 tiene los valores de dicho cuadrado.

Fig 1. El cuadrado mágico de Durero.

Existen una serie de procedimientos para crear cuadrados mágicos de orden par o impar. Un ejercicio interesante es escribir un programa que siga estos procedimientos para generar cualquier cuadrado mágico. No obstante esto, la pregunta que surge es si se puede generar un cuadrado mágico a prueba y error, sin necesidad de

conocer algoritmo alguno. La respuesta es: sí, y para ello lo mejor que podemos hacer es usar un lenguaje de programación al que se le den los datos correspondientes y el programa resuelva automáticamente lo que buscamos. Este tipo de lenguajes declarativos forman un paradigma diferente al de los lenguajes imperativos y Prolog es uno de los mejores ejemplos del mismo.

Prolog nació en los años 70 del siglo pasado, en la Universidad de Aix-Marseille I (Francia), ideado por dos estudiantes, Alain Colmerauer y Philippe Roussel. La primera versión del lenguaje se escribió en Algol 60 y era interpretado. Más tarde (1983), llegaría David H.D. Warren, quien habría desarrollado un compilador que traducía Prolog en una serie de instrucciones de una máquina virtual, la cual se denominó a la postre la Máquina Abstracta de Warren (también conocida como WAM - Warren Abstract Machine).

Manuel López Michelone (@morsa) es Físico por la UNAM y maestro en Ciencias por la Universidad de Essex en el tema de Inteligencia Artificial. Ha sido columnista por muchos años en publicaciones de la industria del cómputo y ávido programador. Actualmente realiza su doctorado en ciencias de la computación en la UNAM. morsa@la-morsa.com

042

SG.49

PROGRAMACIÓN

P

Los programas en Prolog se componen de cláusulas de Horn que constituyen reglas del tipo “modus ponendo ponens”, es decir, “si es verdad el antecedente, entonces es verdad el consecuente”.

Básicamente Prolog usa hechos y reglas. Los hechos son verdades que son ciertas en el entorno de un programa y las reglas definen verdades cuando se cumplen una serie de hechos. Prolog se basa así, en inferencias lógicas. A manera de ejemplo, si me presentan a alguien que se llama Jorge Flores y yo encuentro un parecido con un amigo mío llamado Luis Flores, quizá mi cerebro haga automáticamente una inferencia y me nazca preguntarle a Jorge: “¿no tienes un hermano llamado Luis?”. Ese tipo de inferencias las puede hacer Prolog, como en el siguiente ejemplo: padre(juan, manuel). /* el padre de juan es manuel */ padre(pedro, manuel). /* el padre de pedro es manuel */ hermanos(X,Y) :- /* X y Y son hermanos si tienen el mismo padre */ padre(X,Z), padre(Y,Z), X<>Y,

Listado 1. Encontrar cuadrados mágicos con Prolog. http://swgu.ru/qv

write(X, “es hermano de “, Y).

La regla se lee de la siguiente manera: “X y Y son hermanos si: el padre de X es Z, y el padre de Y es Z, y X no es Y”. Nótese que no se dice en ninguna parte que pedro y juan son hermanos. Prolog, a través de la regla definida, llega a esa conclusión. Es importante hacer la aclaración de que X no es Y, sino el programa reportaría que X es hermano de sí mismo.

Prolog resuelve todo a través de un motor de inferencias, también reconocido como algoritmo de Robinson (en honor al autor que publicó por primera vez el mecanismo en 1968). De esta manera y abreviando el asunto, en Prolog describimos el problema y el lenguaje nos da las soluciones a través de dos mecanismos: la recursión y el backtrack.

La recursión es simplemente llamarse a sí mismo. En términos de programación significa que una rutina se llame a sí misma hasta que cierta condición impida que se cicle eternamente.

El backtrack consiste en regresar sobre nuestros pasos si resulta que la solución hallada no cumple con nuestras expectativas. Un ejemplo simple de backtrack puede verse en el recorrer un laberinto. Caminamos dentro de éste hasta que topamos con pared. Si esto ocurre, entonces retrocedemos sobre nuestros pasos hasta encontrar la primera bifurcación posible. Seguimos este procedimiento hasta hallar la salida.

Regresando a los cuadrados mágicos, veamos la creación de un cuadrado mágico de orden 3. El listado 1 muestra código en Prolog que resuelve este problema. Todo consiste en describir las condiciones iniciales y las de frontera. Luego le pedimos a Prolog que nos dé las soluciones a través de probar todas las posibilidades exhaustivamente (el árbol solución).

El código del listado 1 básicamente hace lo siguiente: • Elegir 9 números (todos diferentes).

• Hacer las combinaciones de dichos números —en las ecuaciones correspondientes— que entreguen un resultado R. Este resultado debe ser igual en todas las ecuaciones.

• Si se logra esto, escríbase la solución.

• Búsquese una nueva solución a través de backtrack (aplicando la instrucción fail).

El algoritmo es no determinista, es decir, no sabemos de antemano cuál será el resultado de la ejecución y el sistema, a las mismas entradas, puede dar muchos resultados posibles.

La forma más sencilla de ejecutar este código es por medio de SWISH, que es un ambiente de ejecución de Prolog que funciona en el navegador web. Simplemente entra a http://swish.swi-prolog.org, crea un programa nuevo, pega el código fuente y en la sección donde pones tu query teclea “cuadrado” y da clic a “Run”. El sistema comenzará a calcular e irá desplegando matrices conforme las encuentre.

Como verás, el programa en Prolog es relativamente compacto y simple de entender. Intenta hacer esto en otro lenguaje y verás que tendrás código más grande y complejo. Por otro lado, un inconveniente es que Prolog dista de ser un lenguaje eficiente. En este caso hicimos el cálculo de un cuadrado de un orden relativamente pequeño (3), pero conforme vayamos aumentando el orden, el consumo de memoria aumentará significativamente y podríamos agotarla. Sin embargo, lo importante en este caso es la posibilidad de que, dando solamente los hechos y reglas relevantes, el programa busque con el algoritmo de Robinson, todas las posibles soluciones.

SG.COM.MX

043

C

PRUEBA DE SOFTWARE

Special Purpose Languages PARTE 2. ALGUNAS DEFINICIONES — Por Luis Vinicio León Carrillo

En el número anterior hice alusión a la plática que ofrecí en el pasado SG Conference & Expo. Durante ella analizamos brevemente la problemática que dio origen a la llamada “Crisis del software” (a partir de la cual se acuñó por cierto el término “Ingeniería de Software” en los 60), y describimos algunos enfoques que se han aplicado para abatirla, entre ellos los métodos formales, los cuales definimos y describimos brevemente en el número anterior y vimos que utilizan lenguajes formales (que definimos de manera no-formal) procesados por compiladores.

Como pueden observar, este pequeño patrón, descrito con esa sencilla y única regla, parece describir el crecimiento de una planta (solo en 2 dimensiones). Lenguajes en los que las reglas se aplican en paralelo, se han utilizado para describir fenómenos de este tipo, y han dado lugar a toda una jerarquía de lenguajes conocida como Sistemas Lindenmayer (L-Systems), los cuales a su vez tienen relación con los fractales (el todo contenido en cada parte). Este enfoque viene de la biología (su creadora, Aristid Lindenmayer, era bióloga).

El “estado del arte” de nuestra industria ha estado fuertemente influenciado por el desarrollo de los que llamo: “lenguajes de computación”, que incluyen tanto los lenguajes de programación (de bajo y alto nivel; de primera, segunda, tercera, cuarta y quinta generación; procedurales, funcionales y lógicos, etc.), como los lenguajes de documentación, de especificación, y de arquitectura, entre otros.

Por otro lado, los lenguajes que utilizamos en la computación utilizan reglas que se aplican no tanto en paralelo, sino más bien secuencialmente, y se definen con un marco conceptual que proviene de la Lingüística (Chomsky es lingüista).

En general, dichos lenguajes nos sirven para formalizar patrones que posibilitan la automatización.

Un caso un tanto distinto es el que comenzamos a revisar en el número pasado, en el que les pedí aplicar 3 veces la siguiente regla/patrón haciendo las sustituciones siempre en paralelo.

Por cuestión de espacio expongo aquí solo las primeras 2 transformaciones, en las que los colores tienen la intención de ayudar al seguimiento de las sustituciones (noten que hay ligeras variaciones en algunas inclinaciones de las figuras; finalmente las plantas son sistemas adaptativos).

Pero antes de entrar más en detalle con este último enfoque, déjenme abordar algunas cuestiones fundamentales utilizando el enfoque de conjuntos. Por favor, no pierdan de vista que estamos haciendo esto porque queremos describir cómo construir special purpose languages propietarios para incrementar la productividad y la calidad de nuestros procesos de desarrollo (y prueba) de software.

Definiciones Un alfabeto es un conjunto finito de letras. En el caso del Español, ese conjunto tiene 30 letras (contando la ch, ll y la ü), con las cuales podemos construir palabras, oraciones y textos “correctos” en ese idioma, pero también frases que no se consideran parte del mismo (como “añu is morgen”). Podemos decir entonces que el Español es un conjunto de frases consideradas “correctas”, el cual a su vez es un subconjunto del de todas las frases que pueden escribirse con su alfabeto.

Generalicemos un poco y definamos el alfabeto B = {b1, b2, …, bn}, un conjunto finito que contiene n caracteres. Diremos que tiene una cardinalidad de n, y lo escribiremos |B| = n.

Definamos ahora la concatenación entre caracteres de un alfabeto B como sigue: bi · bj = bibj bi · λ = λ · bi = bi (λ es la “cadena vacía: una cadena sin letras) ( bi · bj ) · bk = bi · (bj · bk ) = bibjbk

Luis Vinicio León Carrillo es socio director y fundador de e-Quallity. Fue profesor-investigador en la universidad ITESO, y realizó una estancia de posgrado en Alemania, donde se dedicó a la investigación del testing y los métodos formales.

044

SG.49

PRUEBA DE SOFTWARE

C

Los sistemas Lindenmayer describen fenómenos en los que las reglas se aplican en paralelo.

Adicionalmente, definamos el alfabeto C = {c1, c2, …, cm}; C es también finito, con |C| = m.

cualquier dispositivo para procesar información) es infinita, pero es contable.

Definamos la concatenación entre conjuntos de caracteres:

Finalmente: dado el conjunto A, ɚ(A) (“el conjunto potencia del conjunto A”) denota el conjunto conformado por los subconjuntos de A. Algunos ejemplos:

B · C = { b1c1 , b1c2 , …, b1cm ,

b2c1 , b2c2 , …, b2cm , …,

bnc1 , bnc2 , …, bncm }

B · C es también un conjunto finito, con cardinalidad |B·C | = n * m.

Definamos ahora la exponenciación de la concatenación aplicada a un conjunto de caracteres: Bx = B · Bx-1 B0 = { λ } (El conjunto que tiene un solo elemento, que es la cadena vacía.)

Bx es un conjunto finito, de cardinalidad |Bx | = |B |x + 1 (por la cadena vacía).

Si A = { }, entonces ɚ(A) = {{}}, y |ɚ(A)| = 1.

Si A = { a1 }, entonces ɚ(A) = {{}, {a1 }}, y |ɚ(A)| = 2.

Si A = { a1, a2 }, entonces ɚ(A) = {{}, {a1 }, {a1 }, {a1, a2} }, y |ɚ(A)| = 4.

Podemos demostrar que en general, |ɚ(A)| = 2|A|.

Ahora estamos en posición de definir con mucha precisión qué es un lenguaje en términos de conjuntos: Dado un alfabeto finito B, un lenguaje formal sobre B es cualquier subconjunto de B*. (Dado un código ASCII extendido de 256 caracteres, Java es un subconjunto especial de cadenas escritas utilizando ese ASCII.)

Ahora definamos la operación conocida como Cerradura de Kleene: B*

= U∞i=0 Bi = B0 U B1 U B2 U B3 U ... = { λ, (λ cadena de tamaño 0) b1, b2, …, bn , (n cadenas de tamaño 1) b1b1 , b1b2 , …, b1bn , (n2 cadenas de tamaño 2), b2b1 , b2b2 , …, b2bn , …, bnb1 , bnb2 , …, bnbn , }

Ciertamente, B* es un conjunto infinito, pero de los que llamamos “contable”, pues podemos utilizar los números naturales IN (IN = {0, 1, 2, …}) para listar todos sus elementos en orden: para i = 0 (un número natural) sabemos que hay 1 cadena (otro número natural), para i = 1 sabemos que hay n cadenas, para i = 2 hay n2, y así sucesivamente. Esto permite decir que la cardinalidad de B* es la misma que la de IN. En otras palabras: dado el alfabeto finito B, podemos construir tantas cadenas con sus caracteres como números naturales hay.

Lo anterior es cierto independientemente de la cantidad de elementos de B. Si B fuera la más grande extensión del código ASCII, esto implica que la cantidad de cadenas de caracteres que podemos escribir en una computadora (o en

Preguntas Regresaremos al punto anterior más adelante, pero antes, quisiera hacer notar que a partir de lo descrito anteriormente se desprenden varias preguntas interesantes: • Dado un alfabeto B, ¿cuántos lenguajes podemos construir con sus caracteres?

• ¿Podríamos procesarlos todos? (v.gr. mediante compiladores o intérpretes) • ¿Qué tan complejo y eficiente sería ese procesamiento? (en términos computacionales) Piensen sus respuestas; continuaremos abordando este tema en el siguiente número.

Referencias [1] L. León. “Los Special Purpose Languages, parte 1”. Revista Software Guru #48. http://sg.com.mx/revista/48/los-special-purpose-languages-0

SG.COM.MX

045

C

PROGRAMAR ES UN MODO DE VIDA

La Ardua Tarea de Asegurar la Identidad Por Gunnar Wolf

Gunnar Wolf es administrador de sistemas para el Instituto de Investigaciones Económicas de la UNAM y desarrollador del proyecto

Una de las tareas que realizo dentro del Proyecto Debian es la de actuar como curador de los llaveros de identidad criptográfica que identifican a los participantes del proyecto, y con que realizamos prácticamente cualquier acción (desde mandar un mensaje a las listas moderadas hasta subir nuevos paquetes) con verificación automática de identidad.

Debian GNU/Linux. http://gwolf.org

A últimas fechas tuve la oportunidad de participar en el Congreso de Seguridad en Cómputo que organiza UNAM desde hace más de quince años [1], presentando algunas de las experiencias y aprendizajes derivados de esta tarea [2]. Dicho trabajo me lleva a algunas reflexiones que considero que pueden ser de interés para los lectores de SG. ¿Por qué no contraseñas?

El uso de pares usuario-contraseña para validar la identidad de un usuario y determinar si tiene permiso de utilizar determinado recurso se ha utilizado en el cómputo por lo menos desde la década de los sesenta, y en el desarrollo cultural humano, hay documentos que confirman su uso por lo menos desde la época del Imperio Romano. Nuestros usuarios las conocen y comprenden su funcionamiento, y nadie dirá que vamos contra las prácticas más comunes al emplearlas.

Sin embargo, tenemos que estar conscientes de la relativa fuerza (o debilidad) de este esquema: ya desde 1979 hay estudios que demuestran que son un mecanismo débil y muy falible de autenticación [3]. ¿Vamos a exigir a nuestros usuarios “contraseñas fuertes”? Esto es, ¿tenemos una política que requiera que toda contraseña sea (por ejemplo) una cadena de 10 o más caracteres, que no formen palabras, incluyendo mayúsculas, minúsculas, números y caracteres especiales? Malas noticias: si la tenemos, estamos básicamente asegurando que la contraseña será escrita en un papelito que seguramente vivirá pegado al monitor o debajo del teclado — Mucho menos seguro que una contraseña “sencillita” y memorizable.

Pero, por otro lado, ¿qué tanta expectativa de seguridad tenemos si permitimos contraseñas memorizables? La imagen que acompaña este artículo muestra las contraseñas más frecuentemente utilizadas, con tamaños asignados según su frecuencia relativa, tomadas de una

046

SG.49

muestra de un millón de cuentas (Mark Burnett, 2011).

Uno de los puntos más preocupantes: Las 10,000 contraseñas más comunes corresponden al 98.8% del millón de cuentas. ¿Qué tan impredecibles esperamos que sean nuestros usuarios, o nosotros mismos?

En el caso particular de Debian, los recursos a que tendrán acceso los desarrolladores una vez autenticados son enormes. Por poner un simple ejemplo, al subir una nueva versión de un paquete, éste puede instalarse en millones de computadoras, ejecutando con privilegios de administración. Las contraseñas simplemente no son suficiente protección.

Más allá de las contraseñas Podemos encontrar numerosos esquemas de autenticación que nos llevan más allá de las contraseñas. Casi todos los esquemas siguen los lineamientos de la autenticación multifactorial: si la contraseña es “algo que yo sé”, debo combinarla con “algo que yo tengo” y/o con “algo que yo soy” para obtener una autenticación fuerte.

Un ejemplo con el que seguro han interactuado son los tokens (pequeños dispositivos que presentan un número de seis u ocho dígitos que cambia típicamente cada minuto). Estos dispositivos son claramente “algo que tengo” físicamente, con todo lo bueno y malo que esto conlleva: siendo un objeto físico, no puedo copiarlos. Siendo un objeto que cambia dinámicamente, no puedo memorizarlo ni predecirlo. Si dejé el token en casa o lo perdí junto con mis llaves, no podré identificarme ante el recurso en cuestión.

Por otro lado, se ha popularizado el confiar en los datos biométricos: presentar a la computadora una prueba inherente a mi cuerpo, “algo que yo soy”.

Ejemplos de esto son lectores de huellas digitales, sistemas de reconocimiento de voz, escáneres de retina —e incluso el reconocimiento fotográfico que podría hacerse con una webcam cualquiera. Los datos biométricos sobreviven a largo plazo (no necesariamente de por vida, pero sí a largo plazo; mi envejecimiento o un cambio radical de estilo podrían causar que una foto de mi webcam no me reconozca), no puedo olvidar traerlos conmigo, no puedo copiarlos, pero por otro lado resulta imposible pedirle a otra persona que haga

PROGRAMAR ES UN MODO DE VIDA

algo a mi nombre. Y claro, de los ejemplos presentados, el reconocimiento por webcam sería el más débil. Una persona muy parecida a mí podría pasar bajo el umbral de decisión y reemplazarme.

Autenticación por criptografía de llave pública En el caso de Debian (y de la gran mayoría de las comunicaciones cifradas del mundo) hemos optado por una versión ligeramente debilitada de emplear “algo que tengo”: para interactuar con el proyecto, mi interacción debe ir firmada criptográficamente por una llave que forme parte de uno de los llaveros del proyecto —que uno de los curadores haya aceptado.

Un par de llaves criptográficas es, a fin de cuentas, un par de archivos (uno para la llave pública, otro para la llave privada) en mi computadora, y de ahí que sea únicamente una versión débil de “algo que tengo”: un archivo puede ser copiado, lo que se traduce en la imperiosa necesidad de ser muy diligente protegiendo el medio en el que éste se almacena; si este par de archivos cayera en manos de terceros, quien lo tuviera podría firmar cualquier archivo de forma indistinguible de lo que haría yo. Claro, un certificado siempre debe estar protegido por una contraseña como primerísima línea de defensa —pero la seguridad de la llave privada sencillamente no puede tomarse a la ligera.

Además de Debian, el uso de certificados para autenticación es muy común en los principales proyectos de software libre. Pero su uso no permanece únicamente en este ámbito: La Firma Electrónica empleada por el Servicio de Administración Tributaria (Hacienda) en México, e incluso por el Sistema Integral de Administración Escolar de la UNAM, ambos ejemplos de sistemas donde el riesgo de mal uso por una insuficiente identificación es demasiado grande.

Aquí puede comenzar a apreciarse por qué se elige este factor “algo que tengo” debilitado. Por la distribución de material. Si Debian, el SAT o la UNAM operarán con tokens hardware, tendrían que repartir un dispositivo a cada participante, lo cual conlleva un costo nada trivial. Tendrían que establecerse mecanismos de restablecimiento ante tokens perdidos o dañados. Y si la tecnología avanza y hace obsoleta a una generación de tokens, hay que reemplazar a todos aquellos que sigan en uso. Manejando un par de llaves, este gasto se mitiga fuertemente. ¿Y qué es esto del par de llaves? Muy en resumen, la criptografía de llave pública se basa en funciones matemáticas unidireccionales (esto es, relativamente fáciles de calcular en un sentido, pero muy difíciles de calcular en sentido contrario) para las que existen parejas de valores. Por ejemplo, una operación que podemos realizar a ojo es multiplicar dos números primos de dos dígitos:

C

familia de algoritmos más ampliamente utilizada, RSA — Aunque, claro, no con números de dos dígitos, sino de cerca de mil (entre \(2^{2048}\) y \(2^{4096}\)). De estos números se puede derivar una llave pública, que puede ser presentada públicamente para que cualquiera pueda comunicarse de forma segura con su propietario, y una llave privada, que debe ser bien resguardada y jamás debe caer en manos de terceros (y en caso de hacerlo, debe revocarse inmediatamente).

Certificados e identidad Tener este par de números no asegura, sin embargo, la identidad. ¿Cómo he de saber que la llave pública que estoy empleando corresponde realmente a la contraparte con que deseo comunicarme y no a un impostor? Agreguemos restricciones: yo no tengo trato directo con mi contraparte.

Aquí es donde entran en juego los certificados. Un certificado es un archivo que contiene la información necesaria de una llave pública junto con la firma de uno o varios (dependiendo del modelo empleado) proveedores de confianza, aseverando que verificaron la identidad del poseedor de esta llave, y asegurando que corresponde con quien dice ser.

El modelo de confianza más difundido en Internet es PKI (Public Key Infrastructure), en que una serie de empresas dedicadas a la creación de certificados goza de nuestra confianza universal. Este modelo es de fácil adopción, y no en balde sobre él se construyeron los modelos de cifrado SSL y TLS; prácticamente todo el tráfico cifrado comercial de Internet los maneja, pero su naturaleza centralizada lo ha llevado a una serie de graves fallos de confianza [4].

El proyecto Debian, entre otros muchos, emplea un modelo descentralizado, par-a-par, llamado llavero de confianza (Web of Trust).

En este caso, en vez de depender de una autoridad central, cada uno de los participantes del llavero puede certificar y ser certificado por quien conozca. De este modo, sin que dos personas se conozcan, pueden establecer qué tan fuerte es el camino de confianza que los une dentro de un universo determinado.

El espacio me impide entrar más a detalle sobre este tema. Les refiero a un análisis estadístico, automático y actualizado periódicamente, del comportamiento del principal directorio de llaves PGP [5], que al día de hoy cuenta con más de 4 millones, y me comprometo a abordar algunos aspectos interesantes de la gestión de estos llaveros en números siguientes de SG. Referencias [1] Congreso en Seguridad de Cómputo. UNAM. http://congreso.seguridad.unam.mx [2] G. Wolf. “Fortalecimiento del llavero de confianza en un proyecto geográficamente

23 x 47 = 1081

distribuido”. http://gwolf.org/node/4055 [3] R. Morris & K. Thompson. “Password Security: A Case History”. Communications of the

Sin embargo, si queremos factorizar 1081, la tarea resulta mucho más dificil —se vuelve un ataque de fuerza bruta. Esto es, en resumen y de forma un tanto simplificado, el funcionamiento de la

ACM, November 1979. http://www.cs.yale.edu/homes/arvind/cs422/doc/unix-sec.pdf [4] “Changes in the TLS certificate ecosystem”, LWN.net. https://lwn.net/Articles/663875 [5] “Analysis of the strong set in the PGP web of trust”. http://pgp.cs.uu.nl/plot/

SG.COM.MX

047

T

MAKER ZONE

Guía para Makers Primerizos — Por Andrés Sabas

Desde hace tiempo tienes pendiente entrarle al “mundo maker” pero no estás seguro de qué herramientas y accesorios necesitas tener para iniciar, y la variedad existente intimida más de lo que ayuda. No te preocupes, sabemos cómo te sientes y estamos aquí para ayudarte.

Debemos aclarar que saber electrónica no implica ser maker, hay makers de distintas áreas como carpintería, metal o biología, para ser maker no es necesario saber manejar electrónica pero ayudará mucho a que tus proyectos se vean más vistosos y tengan nuevas funcionalidades.

Microcontroladores y tabletas (boards) Un componente esencial de un proyecto es una tableta con microcontrolador. El microcontrolador es el cerebro de nuestro proyecto que programamos para lograr el comportamiento deseado.

Arduino. Las tabletas Arduino son la referencia del mundo maker por su facilidad de uso, bajo costo y amplio ecosistema. El modelo más popular es la tableta Arduino UNO (ver figura 1), que utiliza un microcontrolador ATmega328P que opera a una frecuencia de 16 MHz e incluye 32KB de memoria. Sí, como te podrás dar cuenta, no es un procesador muy poderoso, pero es más que suficiente para la mayoría de los proyectos (por ejemplo: detectar la señal de un sensor y disparar una acción). Cabe mencionar que estos son microcontroladores que se programan directamente, es decir que no ejecutan un sistema operativo (a excepción de modelos específicos como el Yun).

A raíz de su éxito, se han diseñado distintos modelos de tabletas Arduino para atender necesidades específicas. Algunas de las más conocidas son: • Mega: hermano mayor del Arduino UNO. Cuenta con un mayor número de entradas y salidas digitales, analógicas y puertos de comunicación.

048

SG.49

• Lilipad: una edición creada en exclusiva para wearables, su forma es circular y tiene conectores especialmente diseñados para hilo conductivo. La tienda Adafruit cuenta con una versión similar llamada FLORA que ya tiene un adaptador para baterías recargables y pequeñas. Es excelente para colocarlo en gorras, playeras o zapatos.

• Yun: versión diseñada para escenarios de internet de las cosas.

Incluye nativamente comunicación WiFi, puerto USB OTG para conectar dispositivos USB, un puerto ethernet y un sistema embebido Linux en el que puedes almacenar una página web y datos de sensores o actuadores.

• 101: la más reciente creación de Arduino en conjunto con Intel. Utiliza un sistema en chip Quark de 32-bit (“Intel Curie”) que le da bastante poder con un bajo uso de energía. Además incluye conectividad Bluetooth 4.0, acelerómetro de 6 ejes, circuito de carga de baterías y procesador de señales.

• Nano: una versión más pequeña del Arduino UNO, cuenta con prácticamente las mismas características que éste pero es mucho más pequeño lo que permite desarrollar proyectos a una menor escala.

• ATTiny85: ideal para la miniaturización de proyectos, el ATTiny85 es un microcontrolador del tamaño de una uña, comparable con el circuito integrado 555 por sus 8 patillas.

Dado que Arduino es hardware abierto, es posible comprar tabletas similares hechas por distintos fabricantes. No es que sean copias “piratas”, sino que simplemente cada fabricante puede hacer su propia implementación, siempre y cuando respete las especificaciones del hardware y de uso de la marca Arduino.

Dependiendo del modelo y fabricante, una tableta Arduino típicamente se puede adquirir por entre 10 y 40 dólares.

MAKER ZONE

T

Figura 2. Raspberry Pi 2.

Figura 1. Arduino UNO.

Raspberry Pi. Otro producto con gran popularidad es la Raspberry Pi. A diferencia de Arduino, que es un “single-board microcontroller”, Raspberry Pi es un “single-board computer”, es decir una computadora completa (con procesador, memoria, almacenamiento, soporte para monitor externo, entrada para teclado y mouse, etcétera) integrada en una tableta casi del tamaño de una tarjeta de crédito. Cuenta con procesador de hasta 1 GHz y hasta 1GB de RAM de capacidad, así que no es tan poderosa como tu computadora personal, pero sí tiene el poder suficiente para correr versiones optimizadas de Linux y funcionar como servidor de propósito específico. Otra diferencia de Raspberry Pi con tu computadora personal es que tienes a tu disposición sus pines digitales (GPIO) para controlar leds, motores, sensores y comunicarte con otros dispositivos usando los programas que regularmente encuentras en tu computadora con Linux. Actualmente existen tres modelos: • B+: cuenta con un procesador a 700MHz y 512MB en RAM. Tiene un precio de lista en Estados Unidos de 30 dólares y en México se puede conseguir por alrededor de 800 pesos.

• Pi 2: el modelo más poderoso, con procesador Dual Core a 1GHz y 1GB de RAM. 40 dolaritos en EUA o alrededor de 900 pesos en tiendas locales.

• Zero: el modelo más reciente, compacto y económico.

Procesador a 1GHz y 512MB en RAM, puerto mini USB y mini HDMI. Su tamaño es tal que la puedes llevar en tu bolsillo o de llavero. Pero lo mejor es su precio, tan solo 5 dólares.

Viene para hacer realidad que todos tengamos una computadora en nuestro bolsillo.

La Raspberry Pi es ideal para montar centros de entretenimiento, así como servidores con Asterisk o NodeJS. Otro uso común es en kioscos o computadoras de propósito específico.

Dada la popularidad tanto de Arduino como de Raspberry Pi, es común encontrarse con la pregunta ¿cuál es mejor? o ¿cuál debo usar para empezar? La respuesta es que no hay punto de comparación, ya que Arduino UNO es un microcontrolador de 8 bits enfocado a funciones sencillas y de bajo consumo de energía, mientras que Raspberry Pi es una computadora completa con sistema operativo. No se pueden comparar porque no tienen las mismas funciones, al contrario se complementan y podrás encontrar varios proyectos en la red donde se usan ambas.

Intel Edison. Otro producto notable es Intel Edison, un módulo de cómputo miniatura (alrededor de una estampilla postal) que contiene un procesador Atom dual core a 500MHz, 1GB de RAM y 4GB de memoria flash, conectividad WiFi y Bluetooth 4, USB OTG y 40 pines GPIO. Dado que solo es un módulo de cómputo, es necesario empotrarlo en una tarjeta (breakout board) para poder darle energía e interacción con periféricos. Edison es compatible con Arduino por lo que puedes programarlo con el mismo IDE, y utilizar los mismos periféricos.

ESP8266. Es un “system-on-a-chip” para conectividad WiFi (802.11 b/g/n). Su gran atractivo es su precio, de tan solo 7 dólares. También es compatible con Arduino así que puede integrarse fácilmente con tabletas y periféricos para este sistema. Se puede utilizar en escenarios stand-alone o como módulo auxiliar para brindar conectividad WiFi a otros dispositivos.

Periféricos Ya vimos qué necesitamos para construir el cerebro y cuerpo de nuestra creación, pero ahora necesitamos que pueda interactuar con el exterior.

Sensores. Los sensores son pequeños dispositivos que dotan de “sentidos” a nuestras creaciones para que puedan ver, escuchar, sentir y medir lo que sucede en el mundo físico.

SG.COM.MX

049

T

MAKER ZONE

Figura 3. Edison es un módulo pequeño pero poderoso.

Figura 4. Los shields se apilan sobre la tableta y brindan nuevas capacidades.

Entre los sensores más comunes están los de temperatura, luz, movimiento (acelerómetro), ubicación (GPS), peso, humedad, gas, fuego, acidez, etcétera. Los sensores pueden ser digitales (la señal que entregan es 1s y 0s) o analógicos. La mayoría tienen librerías para controlarlos de manera sencilla.

Fuentes. Nuestras creaciones requieren energía para operar.

Existen distintas opciones dependiendo de las necesidades. Para proyectos que pueden estar en un lugar fijo y tienen acceso a una toma de corriente, se puede usar una fuente con un adaptador que típicamente alimenta a nuestra tableta por medio de un puerto microUSB o una entrada dedicada para energía; solo hay que tener cuidado de que el voltaje sea el adecuado y que puede entregar el amperaje requerido. Para proyectos portátiles típicamente se utilizan baterías; solo ten cuidado porque algunas son flamables e incluso puede llegar a explotar. Un buen maker también busca reciclar baterías existentes de otros dispositivos que ya no se utilicen, como tabletas, celulares y laptops; solo ten mucho cuidado al experimentar y fíjate bien en las especificaciones. En internet puedes encontrar cargadores genéricos para cargar baterias LiPo. Otra posibilidad más es la de utilizar celdas solares; también se pueden usar en complemento con baterías.

Actuadores. Una vez que nuestra creación conoce el entorno que lo rodea por medio de los sensores, típicamente queremos realizar alguna actividad dependiendo de ciertos eventos. Por ejemplo, “si se elevó la temperatura entonces activa un ventilador”, “si hay demasiada humedad entonces enciende el foco”. Modificamos nuestro entorno por medio de actuadores que son los “brazos” de nuestra creación. Algunos de los más comunes son: LEDs, pantallas LCD, motores (servomotores, motores a pasos, brushless o de corriente directa), relevadores, ventiladores, timbres (buzzer). Existe una gran variedad de actuadores, pero ten cuidado porque algunos no se pueden conectar directamente a tu tarjeta y tendrás que usar algun circuito de control o acoplamiento para no dañar el circuito. Siempre lee antes la documentación de tu sensor o actuador.

Shields. Si soldar cables no es tu fuerte, no temas. La comunidad ha desarrollado para Arduino lo que se llaman shields, que son módulos compatibles con Arduino que se conectan fácilmente y expanden sus funcionalidades. En el mercado hay una gran cantidad de shields compatibles con Arduino que fácilmente dan capacidades como: GPS, Ethernet, WiFi, motores, comunicación por red celular.

HATs. Los hats (sombreros) son como los shields pero para Raspberry Pi. Se pueden encontrar en dos variedades: con memoria o sin memoria. Los que tienen memoria permiten que la Raspberry Pi reconozca por medio de device tree el tipo de HAT que es, el fabricante, configuración inicial e información adicional para facilitar su interoperación.

050

SG.49

littleBits. Si tienes miedo a todo lo mencionado anteriormente, o estás buscando algo para los más pequeños de la familia, litteBits puede ser una excelente opción (ver figura 5). Estos pequeños bloques electrónicos incluyen imanes para simplificar al máximo la conexión de componentes (no queremos que tu primera experiencia sea un corto). Hay bloques con sensores, motores, leds e incluso de Arduino, todos lo módulos son open source y la compañía ya cuenta con una gran comunidad que está generando tutoriales de como iniciar y crear cosas geniales.

Lenguajes y herramientas de programación ¿Qué lenguajes y herramientas utilizamos para programar? A continuación listo las principales opciones.

C. El lenguaje C es la base de la programación para sistemas embebidos debido a su alto desempeño y eficiencia, además de que permite llegar a bajo nivel para acceder al hardware.

MAKER ZONE

T

Figura 5. littleBits es muy amigable.

IDE Arduino. No es un lenguaje de programación como tal, pero es una excelente opción para nuevos makers. El lenguaje que utiliza se llama Processing, y es muy similar a C pero más sencillo. Es software libre, multiplataforma y tiene un gran soporte por la comunidad.

Python. Es un lenguaje excelente para enseñar a programar por su limpia sintaxis. La mayoría de los ejemplos y librerías de Raspberry Pi utilizan este lenguaje por default.

Javascript. Hoy en día encontramos javascript en todos lados, incluyendo los dispositivos embebidos. Esto se logra por medio herramientas como johnny five o directamente podemos utilizarlo en sistemas con sistema operativo Linux con nodejs con bibliotecas como MRAA que soporta tarjetas como Intel Edison, Galileo, Banana Pi, Beagle Bone o Raspberry Pi, si eres programador de web esto te facilitará la curva de aprendizaje y es una buena opción para iniciar.

Scratch. Es un ambiente de programación visual con bloques creado para enseñar a los niños la logica de programacion con una interfaz divertida. Tiene soporte oficial en Raspberry Pi y hay herramientas para adaptarlo a Arduino.

TouchOSC. Es una aplicación que trabaja con el protocolo OSC (Open Sound Control). Este protocolo permite la comunicación por WiFi entre dispositivos como Arduino, Raspberry Pi, BeagleBone o incluso con la computadora, por medio de un smartphone o tablet. Ideal para el control de carritos, drones, robots, leds, secuencias, etcétera. Si buscas integrarlo con Arduino, busca información en la web sobre cómo hacer esto con una aplicación en Processing; necesitarás la librería osc5, que puedes encontrar fácilmente en internet. La conexión con

Raspberry Pi es más sencilla, pero requiere saber programar en Python y usar el módulo pyOSC. Processing. Para proyectos que requieren de interfaces controladas desde la computadora, te lo recomiendo. Su IDE es sumamente parecido al IDE de Arduino por lo que no te será muy complicado de entender. Para el control de dispositivos se requiere de una librería llamada controlP5, que también puedes encontrar muy fácil en internet. Como nota adicional, existe un protocolo llamado Firmata, el cual puedes cargar a tu tableta desde el IDE de Arduino y te servirá para controlar tu Arduino desde Processing.

Donde comprar Algunas tiendas geniales con productos para tus proyectos, tutoriales, buen soporte y que hacen envíos a México, son: • • • • • • •

330 ohms (México) 5Hertz (México) Talos Electronics (México) Banshee (México) Adafruit (EUA) SparkFun (EUA) SeedStudio (China)

Por último, si tienes dudas acércate a tu hackerspace o makerspace más cercano. Vía internet también puedes hacerlo a través del grupo de facebook “Makers México” donde encontrarás una gran comunidad con gente dispuesta a ayudarte, e información sobre eventos y charlas relacionadas al DIY. ¡Hasta la proxima, makers!

Andrés Sabas (@sabasacustico) es un maker apasionado y cofundador de The Inventor’s House Hackerspace y Coworking en Aguascalientes.

SG.COM.MX

051

F

FUNDAMENTOS

Pura Felicidad con Funciones Puras — Por Brian Lonsdorf. Adaptación y traducción por Pedro Galván.

Este artículo es una adaptación del capítulo 3 del libro digital: “Professor Frisby’s Mostly Adequate Guide to Functional Programming” [1] escrito por Brian Lonsdorf.

Hasta hace unos años, la programación funcional se utilizaba más que nada en ámbitos académicos y de investigación. Sin embargo, en los últimos años ha cobrado gran popularidad en el desarrollo de aplicaciones debido a los beneficios de desempeño que otorga al generar código altamente paralelizable. Así que cualquier desarrollador que pretenda destacar, requiere saber programación funcional.

En la programación funcional, evitamos a funciones como splice que mutan datos. Lo que buscamos son funciones limpias y confiables que regresen el mismo resultado siempre, no funciones que dejen un desastre.

Veamos otro ejemplo: // impura

Una de las primeras cosas que hay que entender para hacer programación funcional es el concepto de una función pura.

var minimo = 18;

Una función pura es aquella que, dada una misma entrada, siempre regresa el mismo valor de salida y no tiene otro efecto secundario observable.

};

var checarEdad = function(edad) { return edad >= minimo;

// pura var checarEdad = function(edad) {

Por ejemplo, consideremos las funciones slice y splice de javascript. Podríamos decir que ambas hacen lo mismo —de una forma muy distinta. Decimos que slice es pura porque regresa el mismo valor siempre. En cambio, splice modifica el arreglo sobre el que opera, alterándolo de forma permanente. var xs = [1,2,3,4,5]; // pura xs.slice(0,3); //=> [1,2,3]

var minimo = 18; return edad >= minimo; }; Listado 2. Dependencia de estado.

En la versión impura, checarEdad depende de la variable mutable minimo para determinar el resultado. Es decir que una misma entrada podría dar resultados distintos, dependiendo del estado.

xs.slice(0,3); //=> [1,2,3] xs.slice(0,3); //=> [1,2,3] // impura xs.splice(0,3); //=> [1,2,3] xs.splice(0,3); //=> [4,5]

Depender del estado del sistema no es deseable porque al introducir el ambiente externo aumentamos la carga cognitiva (el contexto que debemos monitorear para ejecutar nuestra función) lo cual le agrega puntos posibles de falla a nuestro código además de hacerlo menos portable.

xs.splice(0,3); //=> [] Listado 1. Mutación de datos.

052

SG.49

Este sencillo ejemplo parece inofensivo, pero la dependencia en el estado es una de las causas principales de complejidad en los componentes de software [2].

FUNDAMENTOS

F

La dependencia en el estado es una de las principales causas de complejidad en los componentes de software.

Efectos secundarios Al definir lo que es una función pura, mencionamos que no debe tener efectos secundarios observables. Con esto nos referimos a cualquier cambio de estado en el sistema o interacción observable con el exterior, que ocurre durante el cálculo del resultado de una función.

Portabilidad. Las funciones puras son completamente autosuficientes; disponen internamente de todo lo que necesitan para operar. ¿Cómo nos beneficia esto? Por lo pronto, sus dependencias están explícitas y por lo tanto es más sencilla de entender.

En el caso de javascript, la portabilidad permite serializar y enviar funciones por medio de un socket.

Algunos ejemplos comunes de efectos secundarios serían: • mutar datos, • modificar archivos, • insertar un registro en una base de datos, • hacer una llamada http.

Testeabilidad. La utilización de funciones puras facilita el testing significativamente ya que no necesitamos simular gateways o estados que requiere nuestro código para operar. Simplemente invocamos la función y evaluamos su resultado.

En esencia, cualquier interacción con el mundo exterior a una función, es un efecto secundario. Viéndolo de esta forma, programar funciones sin efectos secundarios parece poco práctico y poco útil.

En realidad no es que nuestras funciones no puedan interactuar con el exterior, sino que deben hacerlo de manera específica y controlada. Un mecanismo para hacer esto es apoyándose en mónadas y functors, que no revisaremos en este artículo pero el lector puede investigar por su lado [2].

Beneficios de la pureza Entre las razones para justificar el tener funciones puras, destacan las siguientes: Transparencia. Una de las consecuencias de utilizar funciones puras es que nos dan transparencia referencial. Un pedazo de código tiene transparencia referencial cuando puede ser sustituido por el resultado de su evaluación sin alterar el comportamiento del programa. El beneficio de la transparencia es que hace el código sea más fácil de comprender y razonar.

Cacheabilidad. Cuando ejecutamos una función por primera vez con cierto argumento, podemos guardar su resultado en caché y la próxima vez que se invoque la misma función con el mismo argumento, ya no es necesario ejecutarla sino que podemos regresar el valor almacenado en caché.

Paralelismo. Dado que las funciones puras no requieren acceder memoria compartida, se pueden procesar de forma paralela, lo cual abre la posibilidad de tener un mejor desempeño.

Conclusión Hemos visto en qué consisten las funciones puras y cuáles son sus beneficios. Te recomiendo que al escribir código estés consciente de esto y busques escribir funciones puras.

En la práctica, escribir programas solamente con funciones puras es una tarea laboriosa y que tiene sus propias complicaciones.

Por ejemplo, dado que no podemos depender de estado foráneo a nuestras funciones, necesitamos estar malabareando datos para pasarlos como argumentos de un lado a otro. Sin embargo, esto es viable aplicando técnicas y herramientas adecuadas. Una de estas técnicas es lo que se conoce como “currying”. En próximos artículos platicaremos al respecto.

Referencias [1] B. Lonsdorf. “Professor Frisby’s Mostly Adequate Guide to Functional Programming”. http://swgu.ru/r6 [2] B. Moseley, P. Marks. “Out of the Tar Pit”. Software Practice Advancement (SPA), 2006. http://swgu.ru/r7

SG.COM.MX

053

O

HARDWARE

1

POWERUP FPV

PowerUp Toys nos trae el FPV, un avión de papel que puedes controlar desde un visor de realidad virtual con Google Cardboard. ¿Cómo es eso? Sí, imagina que tomas un avión de papel, lo equipas con una cámara de streaming y motores controlables desde una app de smartphone; puedes controlar la app de forma tradicional (con tus dedos) o montarla en un visor de Google Cardboard y controlar el vuelo con movimientos de tu cabeza mientras visualizas en el visor el video que envía la cámara en el avión. Suena divertido, ¿no?

El FPV se encuentra como proyecto en Kickstarter, y ha superado por mucho su meta inicial de fondeo. El FPV se está desarrollando con el apoyo de la empresa francesa Parrot, creadora de drones populares como el Bebop y el AR.Drone. http://www.poweruptoys.com

2

TAG HEUER CONNECTED Visto en @geek_mx

Con toda la apariencia de un reloj de lujo en el exterior, y toda la tecnología de Android Wear por dentro, el Tag Heuer Connected es el primer smartwatch fabricado por la empresa suiza, el cual esperan posicionar en el segmento de relojería fina. Con un precio de $1,500 dólares, luce totalmente como un reloj TAG, gracias a su carátula de titanio, display de zafiro reflectivo y correas disponibles en una gran variedad de colores. Sin embargo, al incorporar el sistema operativo Android Wear, el reloj se asemeja a un Moto 360 o cualquier otro smartwatch pues incluye apps y conectividad con smartphones. El reloj cuenta con 1 GB de memoria RAM, 4 GB de almacenamiento interno y un procesador de doble núcleo a 1.6GHz. Obviamente, gracias a Android Wear, TAG Heuer Connected es compatible con todo tipo de equipos Android, sin embargo, también puede usarse con iPhone para responder llamadas, revisar mensajes y operar otras funciones. http://www.tagheuerconnected.com

054

SG.49

3

WINK

Wink es un robot mascota de bajo costo basado en Arduino y diseñado para enseñar robótica a los niños. Cuenta con dos motores independientes de velocidad variable, así como sensores de luz ambiental y detección de líneas y objetos. Esto lo hace ideal para programar ejercicios como seguimiento de luz, recorrer caminos o recorrer laberintos. Wink se programa desde el IDE de Arduino, e incluye librerías amigables que facilitan tareas básicas de movimiento y detección. El propósito es ayudar a que niños familiarizados con ambientes de programación visual como Scratch, puedan dar el salto y comenzar a escribir código ellos mismos para controlar al robot. Los creadores también están por publicar una guía con ejercicios y código fuente para realizar tareas básicas con el Wink. Dicha guía será gratuita y abierta. Wink fue fondeado exitosamente en Kickstarter y ya comenzó a entregarse. Se espera que durante el primer trimestre del 2016 se haga disponible comercialmente. http://kck.st/1ihy07Q

HARDWARE

4

O

21 BITCOIN COMPUTER

La 21 es una computadora diseñada para soportar el protocolo bitcoin. Su principal objetivo es permitir que los emprendedores y desarrolladores puedan fácilmente habilitar aplicaciones o dispositivos para soportar el manejo de bitcoins de forma automatizada.

Es decir, habilitar tu propia tienda en línea que soporte micropagos. Esto habilitaría escenarios como por ejemplo poder cobrar por la descarga o acceso a archivos digitales sin necesidad de recurrir a un gateway de pago.

La 21 incluye un chip para minería de bitcoins y un sistema operativo basado en Linux

denominado “Bitcoin OS” que incluye un servidor de micropagos, entre otras herramientas y utilerías. Como podrás imaginarte, la 21 se puede utilizar para minar bitcoins, y de hecho es bastante sencillo, simplemente tecleas “21 mine” desde la línea de comandos, pero en realidad la 21 no es un dispositivo muy eficiente para ese propósito. El hardware no es muy poderoso (en esencia es una Raspberry Pi) y da un rendimiento de apenas 50 Gigahash por segundo. Así que su valor no va por ahí. Por el momento, la 21 solo está disponible en Amazon Estados

Unidos, por un precio de 400 dólares. http://21.co

El Último Programador

Este comic fue originalmente publicado en http://www.commitstrip.com/en/2015/11/04/the-last-of-the-coders/ Fue traducido al español y compartido por Software Guru con el permiso del autor.

SG.COM.MX

055

O

BIBLIOTECA

X: THE EXPERIENCE WHEN BUSINESS MEETS DESIGN Brian Solis. Wiley, 2015.

1

La experiencia brindada a sus clientes, es el aspecto más importante en los negocios modernos. A pesar de ello, la mayoría de los emprendedores y ejecutivos desprecian el valor de diseñar experiencias desde un inicio. Con este libro, comprenderás la importancia de la experiencia y cómo diseñarla. ¿Por qué? Porque hoy en día la experiencia lo es todo.

Brian Solis es uno de los autores más reconocidos en el ámbito de transformación y estrategia digital. En su último libro, Brian explica de forma detallada y ejemplificada a lo que llama el factor “X”, que es la experiencia que surge cuando las empresas se preocupan por el diseño.

A través de ‘X’, Brian explica por qué y cómo colocar la experiencia de los clientes en el centro de cualquier negocio. El libro comienza abordando conceptos desde un punto de vista estratégico, explicando qué es la transformación digital y cómo es que la experiencia impacta en el éxito de las empresas, y gradualmente pasa del qué al cómo, compartiendo ejemplos y herramientas para el diseño de experiencia de usuario tanto para productos como servicios. El libro es rico en ejemplos, citas y casos de estudio de empresas y personajes altamente reconocidos, que son de gran valor para ilustrar los distintos conceptos.

‘X’ es un clásico instantáneo y seguramente dará ideas y herramientas útiles a cualquier persona involucrada en el diseño de productos y servicios.

FUNDAMENTOS DE SISTEMAS OPERATIVOS Gunnar Wolf, Esteban Ruiz, Federico Bergero, Erwin Meza.

Instituto de Investigaciones Económicas / Facultad de Ingeniería UNAM, 2015.

Este libro, en el que colaboró uno de nuestros columnistas, Gunnar Wolf, ha sido diseñado para servir como bibliografía para un curso de Sistemas Operativos para licenciatura.

Fundamentos de sistemas operativos está escrito nativamente en español, salvando las inconveniencias en que muchas veces incurren las traducciones þécnicas. Los autores (uno mexicano, dos argentinos y uno colombiano) procuraron que el lenguaje y los términos empleados resulten lo más neutros y universales a la región latinoamericana.

A pesar de que menos de una decena es conocida por la población en general, hay cientos de sistemas operativos en uso y bajo un desarrollo activo. Cada uno de ellos persigue distintos fines, sea por la

056

SG.49

2

arquitectura o la capacidad de los equipos en que se ejecutará, características específicas que implementa, o persigue atraer un segmento distinto de la población. Todos ellos, sin embargo, realizan las mismas operaciones básicas, parten de los mismos fundamentos. En este libro se presentan las principales áreas en que se divide el trabajo de un sistema operativo.

Este libro fue escrito con el apoyo de la Iniciativa Latinoamericana de Libros de Texto Abiertos «LATIn», por lo que se permite su libre redistribución y modificación bajo los términos de la licencia Creative Commons Reconocimiento-CompartirIgual (CC BY-SA) versión 4.0.

En http://sistop.org podrás encontrar enlaces con el repositorio en github, así como una versión PDF para descarga.