SG34 (Noviembre 2011 - Enero 2012)

Novedades

WebSockets

CONOCIMIENTO EN PRﾃ，TICA Noviembre 2011-Enero 2012 www.sg.com.mx

Mﾃｩxico, $65.00

CONOCIMIENTO EN PRÁCTICA

34 .CONTENIDO Noviembre 2011-Enero 2012 |

www.sg.com.mx

Pág.

22

En Portada Cómputo Físico

22

¡El mundo es una interfaz! Hemos concentrado diversos artículos con información sobre algunos de los aspectos que consideramos más relevantes sobre el cómputo físico, desde el fenómeno provocado por Arduino y el open hardware, hasta la construcción y programación de robots.

Columnas Tejiendo Nuestra Red

06

Por Hanna Oktaba

Mejora Continua

08

Por Luis Cuellar

Tendencias en Software

11

Por Luis Daniel Soto

Columna invitada

32

Por Mark Settle

Código Innovare

46

Tecno-lógico

48

Por Jesús Arriola Villarreal

Por Mauricio Angulo

Programar es un Estilo de Vida Por Gunnar Wolf

02

50

.CONTENIDO

Herramientas y Novedades Lo que Viene

10

Social Analytics, Open Compute Project, GitHub Enterprise, Apache Sqoop

Tutorial Versionando con Git

12

Por Javier Novoa

Novedades WebSockets

16

Por Gonzalo Ayuso

Carrera

Pág.

18

Emprendiendo

Generación de modelos de negocio

Capital Humano en Software

18

Por Víctor Reyes

Especial

Reseña del evento SG Conference & Expo 2011

20

Prácticas Usabilidad 34 La Navegación y los Esquemas de Organización de la Información Por Pamela Rodríguez

Prueba de Software Un Buen Inicio para las Pruebas de Seguridad

36

Por Berenice Ruíz y Miguel Angel Cortés

Project Management Estimación de Costos

38

Por Héctor Cuesta-Arvizu y José Sergio Ruíz Castilla

Arquitectura Líneas de Productos de Software

40

Por Humberto Cervantes

Gestión de Riesgos Administración Colaborativa de Riesgos Por Leonardo G. Mrak

03

52

Por Pedro Galván

42

En Cada Número Editorial

04

Noticias

05

Publirreportaje

54

Gadgets

56

.EDITORIAL Bienvenida

.

“Gracias por todo lo compartido durante el 2011 ¡Nos vemos en el 2012 con más novedades!”.

Alcanzando a la ficción

¡E

sta es la última edición del 2011! Cumplimos un año más de generar conocimiento sobre la industria de T.I. y agradecemos a todos ustedes, nuestros lectores, que nos sigan eligiendo como el medio de preferencia de habla hispana. En ésta ocasión les tenemos como parte del tema principal, diversos artículos sobre “cómputo físico” en los cuales se demuestra que el mundo no está aún conforme con los tipos de interacción con la tecnología que existen al día de hoy. El cómputo físico fomenta nuevos estilos de interacción en los que casi cualquier artefacto se puede transformar en una interfaz. Es muy importante conocer éste tipo de tendencias, ya que la historia ha comprobado que toda ficción tarde o temprano se alcanza y en éste caso, seguramente está sucediendo más temprano que tarde. También queremos compartirles que este año constatamos, una vez más, que hemos logrado junto con ustedes formar una verdadera comunidad de especialistas de software, comunidad que durante éste año compartió momentos en la Conferencia Virtual, los espacios de aprendizaje colaborativo de SGCampus y en el evento SG Conference & Expo 2011.

››Equipo Editorial SOFTWARE GURU

DIRECTORIO SG Dirección Editorial Pedro Galván / Dirección de Operaciones Mara Ruvalcaba Coordinación Editorial Vanessa Amaya / Arte y Diseño Oscar Sámano / Suscripciones Denise Aguilar Consejo Editorial Jorge Valdés - PMI / Luis Cuéllar - Softtek / Luis D. Soto - Microsoft / Hanna Oktaba - UNAM / Emilio Osorio - Sistemas Humanos / Luis Vinicio León - e-Quallity / Mauricio Angulo - Tesseract Space

Colaboradores Antonio Toriz, Berenice Ruiz, Gonzalo Ayuso, Gunnar Wolf, Héctor Cuesta, Hugo Fernández, Humberto Cervantes, Javier Novoa, Jesús Arriola Villareal, José Sergio Ruíz Castilla, Leonardo G. Mrak, Mark Settle, Mauricio Angulo, Miguel Angel Cortés, Miguel Angel Ramírez, Pamela Rodríguez, Víctor Reyes

Ventas Claudia Perea / Alianzas Montserrat Ramírez / Webmaster Karen Rodríguez / Educación contínua Ana Karen Rosales Contacto info@sg.com.mx SG Software Guru es una publicación trimestral editada por Brainworx, S.A. de C.V., Temístocles 34 piso 3, México DF 11560. Los contenidos de esta publicación son propiedad intelectual de los autores y están licenciados bajo Creative Commons Atribución-No comercial 2.5 México. 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.

Se imprimió en noviembre de 2011 en 4Press.

04

.NOTICIAS

.El Futuro en Tus Manos 2011

.Adobe Max 2011

Adobe Max, la conferencia anual para usuarios y desarrolladores de Adobe, se realizó en Los Angeles del 2 al 5 de octubre. Entre las notas principales de este evento está el próximo lanzamiento del Adobe Creative Cloud, un espacio colaborativo en la nube donde los profesionistas pueden almacenar y organizar sus activos digitales, y compartir avances con sus clientes para que éstos puedan visualizarlos desde la nube. La agenda incluyó un buen número de sesiones relacionadas con HTML5, lo cual muestra el compromiso e interés que tiene Adobe en esta tecnología. De hecho, uno de los anuncios realizado durante estos días fue que Adobe compró a Nitobi, creadores de la plataforma PhoneGap para desarrollar aplicaciones móviles con Javascript y HTML. Los videos de los keynotes están disponibles en http://swgu.ru/adobemax2011

Estudiantes, empresarios, docentes, y público interesado en la tecnología, acudieron el 3 y 4 de noviembre al congreso “El Futuro en Tus Manos 2011” organizado por CITI Tabasco en la ciudad de Villahermosa. El evento contó con la participación de importantes figuras en el mundo de la tecnología tales como Juliano Tubino (Microsoft), Adelina Filigrana (@wera_supernova), Claudio Cossío (AppCircus), Engel Fonseca (Neurona Digital), Jorge Soto (Citivox), Andrés Barreto (OnSwipe), Juan Lozada (Microsoft) y el investigador Ruy Cervantes, quien comentó sobre el ecosistema de emprendimiento en México y su naciente industria de internet.

.Dell World

Dell compartió su visión sobre el impacto de las principales tendencias en la industria de tecnologías de información durante la primera edición de su evento Dell World, realizado en la ciudad de Austin. Entre las personas que presentaron en Dell World estuvieron los CEOs de varias de las empresas más importantes de la industria como Steve Ballmer (Microsoft), Paul Maritz (VMware), Marc Benioff (salesforce.com), Paul Otellini (Intel). Los temas que dominaron la agenda fueron el cómputo en la nube, cómputo móvil en las empresas y aprovechamiento de redes sociales en las empresas. Los videos de las sesiones están disponibles en http://swgu.ru/dellworld2011

.Gartner - The Future of IT

Gartner celebró su 14va Conferencia Anual The Future of IT del 4 al 6 de octubre en el Centro Banamex de la Ciudad de México. En dicho evento participaron 12 destacados analistas que platicaron con los asistentes sobre estrategias tecnológicas para transformar los negocios, con el objetivo de ayudar a los CIOs y altos ejecutivos de la TI a llevar sus negocios hacia nuevos niveles de expansión y rentabilidad. El evento incorporó gran variedad de sesiones, workshops, mesas redondas, casos de estudio, sesiones sobre cuadrantes mágicos, sesiones por solución de proveedor, foro de demostración de productos y las ya tradicionales one-on-one con los analistas.

Para mayor información, noticias al día y actualizaciones de la industria visita: www.sg.com.mx

05

www.sg.com.mx |

El evento “Best of the Best in Project Management 2011” fué celebrado el pasado 22 de Octubre durante el Congreso Global del PMI® en Grapevine, Texas.

Celebramos que lo mejor de lo mejor ahora se quedó en México, ya que la empresa Alpha Consultoría fue premiada como Proveedor de Capacitación del Año 2011, siendo la primera empresa latinoamericana honrada con esta distinción. El objetivo de este premio en especial, es reconocer y honrar al proveedor que hubiera demostrado capacidades excepcionales para la implementación y presentación de un programa en dirección de proyectos, en esta ocasión reconociendo los programas de capacitación de vanguardia en Administración de Proyectos impartidos por Alpha Consultoría.

Software Guru

.Alpha Consultoría reconocida como Empresa de Capacitación del Año por el PMI

.COLUMNA Tejiendo Nuestra Red

Entre Medellín, Rio de Janeiro y Miahuatlán

Hanna Oktaba, Ivar Jacobson y Magdalena Dávila

Medellín, Colombia, agosto de 2011

E La Dra. Hanna Oktaba es profesora de la UNAM, miembro del IPRC, y directora técnica del proyecto COMPATISOFT. hanna.oktaba@ ciencias.unam.mx

06

n mi columna de mayo-junio de este año les comenté sobre la iniciativa del SEMAT (Software Engineering Method and Theory) promovida por Ivar Jacobson, entre otras personalidades. En agosto tuve la oportunidad de escucharlo en persona en Medellín, Colombia. El Dr. Carlos Mario Zapata de la Universidad Nacional de Colombia logró que Ivar aceptara visitar este país. Carlos aprovechó la oportunidad para convocar a varios colegas académicos de América Latina para dos cosas. Lo primero que nos pidió fue que escribiéramos un capítulo cada quien para un libro que refleje el estado de investigación en Ingeniería de Software en esta zona geográfica y lo segundo fue para constituir el capítulo Latinoamericano del SEMAT. Así, entre el 11 y 12 de agosto de 2011 nos encontramos con Jacobson en

Medellín escuchando un llamado a evolucionar la forma en que desarrollamos software identificando lo esencial de lo que ha servido de los métodos tradicionales y agregando lo más útil de las propuestas de métodos ágiles.

Lo que deberíamos buscar es: • Hacer mejor software – útil, extensible y confiable • Hacerlo más rápido y más barato- aplicando reusabilidad a gran escala • Hacerlo con equipos más felices – gente competente y motivada Parece tan sencillo y a la vez tan difícil.

Ivar estaba acompañado de una mujer joven, de origen chino, Shihong Huang quien nos contó la experiencia de la creación del primer capítulo de apoyo al

.COLUMNA Tejiendo Nuestra Red

››“Las reservas de petróleo, por mayores que sean, un día se acaban. Las copas del SEMAT constituido en China. Su servidora y Magdalena Dávila, mi alumna de doctorado, presentamos una propuesta de la estructura de prácticas indispensables para desarrollar un proyecto de software (Software Development Project Kernel), la cual quedó incluida en el libro “Software Engineering Methods, Modeling and Teaching”, editado por la Universidad de Medellín. También quedó constituido el capítulo Latinoamericano del SEMAT (www.sematla.org), coordinado por Carlos Mario Zapata y con Ivar Jacobson como testigo de honor.

Durante el evento Ivar mencionó que está preparando un nuevo libro, que presentará la propuesta de Casos de Uso 2.0. A principio de octubre ya lo dio a conocer con mayor detalle y probablemente se publicará en forma electrónica en noviembre. A los interesados les sugiero visitar el sitio de Ivar Jacobson International.

- benito paret

de los métodos ágiles para integrar las bondades de ambos enfoques.

Encontramos un entusiasmo e interés de trabajar de manera conjunta en este tema con los brasileños.

La lección que aprendí en este evento resumo citando al Coordinador General de RIOINFO 2011, Benito Paret: “Las reservas de petróleo, por mayores que sean, un día se acaban. Las copas del mundo y las olimpiadas pasan. El conocimiento permanece.”

_

Río de Janeiro, Brasil, septiembre de 2011 RIOINFO es un evento anual en el cual se encuentran los empresarios de la industria de TI con los representantes del gobierno para discutir los temas de interés y buscar caminos para fortalecer la industria brasileña. El evento dura tres días y está más enfocado a mesas de discusión que a las conferencias técnicas. En este evento me enteré de que la industria brasileña de software y de servicios está formada por cerca de 75 mil empresas, lo que me pareció desorbitante en comparación con alrededor de 2800 de las mexicanas, mencionadas en agosto en la reunión de la constitución del Consejo Nacional de Clusters de Software y TICs. Los brasileños estiman que en sus empresas trabajan alrededor de 600 mil personas, que sumados a las 370 mil involucradas en empresas usuarias forman casi un millón.

Dos eventos de RIOINFO me llamaron mucho la atención.

Los empresarios invitaron en dos sesiones separadas a los representantes de PETROBRAS (la homóloga de PEMEX) y del Ejército y la Armada para convencerlos de que estas instituciones públicas deberían de comprar el software y sus servicios a las empresas brasileñas. El Secretario de Ciencia y Tecnología (ellos si lo tienen en ese rango) habló de convertir los resultados de estas discusiones en políticas públicas. ¿Y en México cúando?

Con Claude Laport, editor del ISO/IEC 29110, nos tocó promover el nuevo estándar internacional en este foro. Tuvimos oportunidad de discutir la necesidad de combinar el Perfil Básico con las prácticas 07

Cuando me invitaron a dar una plática en la 4ta Jornada de Informática en la Universidad de la Sierra del Sur ubicada cerca de Miahuatlán, Oax., yo ni sabía que existía una ciudad con este nombre. La encontré a medio camino (pésimo por cierto) entre la ciudad de Oaxaca y Huatulco.

Cuando me enteré de que esta universidad es la hermana de la Universidad Tecnológica de la Mixteca, sabía que me espera un viaje muy aleccionador y muy agradable. Hace años ya visité a la Mixteca fundada por el rector Modesto Seara Vázquez en un espacio rural y me impresionó su organización y el nivel académico. Uno de mis mejores alumnos de la maestría es egresado de allá. El proyecto tuvo tanto éxito que hoy el mismo rector dirige y coordina toda una red de universidades públicas estatales en Oaxaca.

En Miahuatlán me encontré con un campus muy bonito para 1500 alumnos, con áreas verdes bien cuidadas y con un grupo de jóvenes profesores de la carrera de Informática muy entusiastas y muy bien preparados.

La Ingeniería de Software no es desconocida ni para los profesores ni para los alumnos y ya están desarrollando proyectos muy interesantes. El rector me estuvo presumiendo que en los últimos años los egresados de estas universidades salen muy bien en las evaluaciones de CENEVAL, pero que normalmente tienen que migrar a grandes ciudades para conseguir trabajo.

Generar espacios de trabajo locales para elevar el nivel de aprovechamiento de TI en poblaciones marginadas podría ser una solución, ¿pero quién va a invertir? Este es un reto para todos y no sólo en Oaxaca.

››Por Hanna Oktaba

Software Guru

Minahuatlán, Oaxaca, octubre de 2011

www.sg.com.mx |

_

mundo y las olimpiadas pasan.

El conocimiento permanece.”

.COLUMNA Mejora Continua

M

La

Estrategia de Mejora de Software

e encuentro leyendo un libro en el que se define a la estrategia como: “El arte de encontrar formas de cooperar aun cuando las diferentes partes están motivadas por intereses personales”. La industria de subcontratistas de servicios de sistemas está basada precisamente en esta idea, lograr una cooperación entre diferentes compañías, a veces hasta competidoras, para lograr un fin en común que beneficie a todas las partes. Por lo que veamos si podemos aplicar la teoría de juegos a nuestros problemas.

El dilema del prisionero

Uno de los ejercicios más comunes en teoría de juegos es “el dilema del prisionero”, el ejemplo clásico de este problema es el siguiente: dos hombres son arrestados por la policía, pero esta no cuenta con información suficiente para una condena. Tras la separación de los dos hombres, la policía ofrece un trato a ambos, si uno declara en contra de su pareja y el otro permanece en silencio, el traidor queda libre y el otro hombre recibe una condena de cinco años de prisión.

Si ambos permanecen en silencio, ambos son condenados a seis meses de carcel por un cargo menor y si ambos se traicionan mutuamente, cada uno recibe una sentencia de un año de prisión. Cada prisionero debe elegir entre traicionar o permanecer en silencio, ¿qué deben hacer? Lo importante en este juego es que ambos están separados y no saben lo que el otro hará y aunque lo mejor para ambos es no decir nada, la pregunta es si confías en tu compañero lo suficiente como para no hacerlo. Este problema ilustra cómo en ocasiones estamos en circunstancias que motivan a apoyar una decisión contraproducente. ¿Qué harían ustedes?

Ahora veamos este juego desde otro punto de vista: Yo estoy contratando a un proveedor para que desarrolle una aplicación critica para mi organización, de la cual depende mi futuro en la misma. Sé que tengo que trabajar en conjunto con mi proveedor para lograr el éxito del proyecto, pero por otro lado quiero asegurarme de que el proveedor esté tan comprometido como yo, por lo que coloco en el contrato una penalización alta en caso de que los niveles de servicio no se cumplan. De esta manera, al menos si el proyecto fracasa recuperamos parte de la inversión.

El proveedor sabe que en ocasiones los niveles de servicio no se cumplen por razones ajenas a él, como: cambios de alcance, problemas con los entregables de entrada, falta de definición por parte del usuario, etc. El contrato no previene nada de esto y aunque lo hiciera no es posible pensar en todos las posibles fallas, por lo que se “infla” la propuesta y se busca hacer los objetivos más holgados.

El resultado: El proyecto está inflado y estamos más preocupados en cómo defendernos de nuestra contraparte que en sacar el proyecto exitosamente. El dilema del prisionero es un problema de confianza, en donde la duda realmente es si confío en que la otra parte hará lo correcto Luis R. Cuellar es director de calidad o no. En teoría de juegos, existen varias formas de resolver a nivel mundial de Softtek. Es recoel dilema del prisionero, estos son algunos ejemplos que he nocido por la ASQ como Certified experimentado con organizaciones exitosas.

Quality Manager, Certified Software Engineer y Six Sigma Black Belt. @lcuellar

08

Generar una relación a largo plazo

Todas las soluciones del “problema del prisionero” tienden a ser a largo plazo. Lo que se busca es generar una relación

de confianza lo cual normalmente surge a través del tiempo. Las compañías que son más exitosas con el manejo de proveedores generan una estrategia de socios con sus proveedores, se genera una selección de proveedores enfocada principalmente en las habilidades, conocimiento, valores y cultura de las organizaciones para elegir un grupo limitado que puede participar en mis licitaciones, generalmente llamados proveedores preferentes. Es cierto que esto implica que muchas compañías que pueden ayudar a problemas particulares se quedan fuera, pero la idea es que la selección está diseñada para asegurar que a largo plazo el desempeño y afinidad ayude a tener proyectos exitosos.

Aprendizaje y crecimiento mutuo

En compañías excelentes se desecha la noción de que el cliente lo sabe todo y se busca un modelo de cooperación en donde tanto cliente como proveedor están aprendiendo a hacer un mejor trabajo. La principal herramienta de aprendizaje en estos proyectos son las métricas, por lo que son de suma importancia. Estas métricas son primero utilizadas para controlar el proyecto y después para mejorar continuamente el trabajo del equipo logrando no solamente un proyecto exitoso, sino en muchas ocasiones mejor de lo esperado.

Muchos de los clientes que conozco, sí generan penalidades en los proyectos, pero estos no están ligadas a métricas u objetivos específicos sino más bien a la falta de acción y proactividad para corregir problemas. Por ejemplo, la primera vez que no se alcanza un objetivo se espera un plan de acción. Si la siguiente ocasión no se ha corregido, cliente y proveedor buscan soluciones en conjunto. Si las métricas no mejoran entonces si surge una penalización. De forma similar, si las métricas se cumplen arriba de lo esperado varios meses continuos se puede manejar un bono al proyecto.

Lo importante es que una penalización es un último recurso para asegurar que estamos en el mismo canal.

El dilema del prisionero es muy difícil de resolver pero estudios indican que las personas tienden a escoger cooperar especialmente en relaciones a largo plazo. La industria de software está en constante crecimiento y definitivamente en la era de la información necesitamos cada vez más de sistemas rápidos y de mejor calidad, por lo que la cooperación es indispensable para todos. Hagamos de la industria del software algo de que sentirnos orgullosos en nuestro país, y no una batalla campal.

“Primera llamada, primera”.

››Por Luis Cuellar

.HERRAMIENTAS Y TECNOLOGÍAS Lo Que Viene

Social Analytics

Análisis de datos sociales

1

Microsoft está experimentando un nuevo servicio llamado Social Analytics que facilitará integrar en aplicaciones de negocio la capacidad de analizar corrientes de datos (data streams) de sitios sociales como Twitter, Facebook, YouTube, y obtener inteligencia. Esto permite que las empresas puedan obtener y analizar inmediatamente la respuesta de los clientes hacia las decisiones de negocio que se toman. Microsoft provee dos mecanismos para consumir servicios de Social Analytics. El primero es por medio de una herramienta llamada “Engagement Client”, y el segundo es directamente accediendo su API basado en REST y OData. http://www.microsoft.com/en-us/sqlazurelabs/labs/socialanalytics.aspx

2

OCP es una iniciativa creada por Facebook para compartir abiertamente diseños de data centers, con el objetivo de mejorar la estandarización y eficiencia en la industria. Facebook ha abierto como parte de OCP los detalles de diseño y construcción de su nuevo data center, para el cual construyeron sus propios servidores, racks y fuentes de poder, logrando superar en 38% la eficiencia de su data center previo, a un costo de construcción 24% menor. Recientemente se formó una fundación que manejará OCP, y en ella están involucradas empresas como ASUS, Dell, Huawei, Red Hat, Cloudera, Rackspace y Netflix, por nombrar a algunas. http://opencompute.org

GitHub Enterprise Hospeda GitHub en tus servidores

2

10

Data centers abiertos

3

Como muchos de ustedes saben, GitHub es un servicio en internet para hospedar proyectos de software que utilizan el sistema de control de versiones Git, rápidamente GitHub se ha convertido en el mecanismo default entre desarrolladores para compartir código. GitHub recientemente anunció la disponibilidad de GitHub Enterprise, el cual permite que organizaciones hospeden instancias de GitHub en sus propios servidores. De esta forma, las empresas pueden fácilmente establecer repositorios de código fuente versionado para sus proyectos y empleados, manteniendo todo dentro de su firewall. http://enterprise.github.com

Apache Sqoop es una herramienta para transferir datos de forma eficiente y confiable entre clusters basados en Apache Hadoop, y fuentes de datos estructuradas tales como bases de datos relacionales, data warehouses empresariales y almacenes NoSQL. Con Scoop, puedes importar datos hacia el Hadoop Distributed File System (HDFS) o hacia sistemas relacionados como Hive y HBase. De forma similar, con Sqoop puedes extraer datos de Hadoop y exportarlos a bases de datos estructuradas. Sqoop hace todo esto de forma sencilla y eficiente, ya que a partir de los metadatos puede inferir su estructura y guardarla en un metaalmacenamiento Hive, y utilizar MapReduce para transferir los datos en paralelo. http://incubator.apache.org/sqoop

Open Compute Project

Apache Sqoop

Mejora tu transferencia de datos a Hadoop

.COLUMNA

Tendencias en Software

Datos como Plataforma

rumbo a la auténtica economía de la información

E

››Es tal la cantidad de datos

Enriquecimiento de información. Hasta hoy, la “inteligencia de negocios” se ha centrado al interior de la organización, pero la capacidad de conectar los datos con el resto de los que existen en el mundo abre nuevas puertas a realizar preguntas más sofisticadas, que antes era imposible contestar. Seguramente veremos el nacimiento de “mercados de datos” privados como una primer etapa y la creación de un nuevo ecosistema de datos públicos enriquecidos. RealtyTrac es un ejemplo real de empresa que revende información pública enriquecida por analistas financieros sobre compra de propiedades.

Nuevas posibilidades. Para generar más utilidades, un analista desea poner a prueba un nuevo modelo con datos históricos de la bolsa de valores. Para que el modelo funcione es necesario analizar épocas de auge y de crisis, digamos 30 años. Se desea incluir mercados internacionales y por supuesto, tomar la fuente con actualizaciones en tiempo real. Hasta recientemente 11

esto era viable para organizaciones con recursos de cómputo masivos. Con tecnologías como Hadoop para Windows y el conector Hive de Excel, hoy esto es mucho más accesible.

El diluvio de datos se tendrá que enfrentar con nuevas herramientas interactivas para “explorar” cantidades masivas de información —la visualización continuará siendo muy relevante. Las plataformas de datos tendrán que evolucionar para administrar cualquier tipo de datos, gigantes o pequeños, desde cualquier lugar. La información deberá ser consumida desde cualquier dispositivo portátil y en un contexto que haga sentido al usuario. Los metadatos son fundamentales para habilitar los mercados de datos descritos.

Big Data se refiere al procesamiento de información no estructurada (video, audio) o semi-estructurada (bitácoras del web). Es tal la cantidad de datos que es impensable que un humano pueda realizar el análisis, por lo que el “aprendizaje basado en máquinas” será fundamental.

En el “nuevo mundo de datos” hay una variedad de nuevas tecnologías. Por ejemplo, hoy en día la respuesta a una búsqueda en sitios de búsqueda como Bing es distinta para cada usuario, las recomendaciones son específicas para el usuario de entre millones de combinaciones. Mediante Bing será posible extender aplicaciones de negocio, por ejemplo “obtener el sentimiento de medios sociales” de un producto en una zona geográfica. IntoNow me parece un interesante ejemplo del nuevo conjunto de tecnologías que hacen posible la magia de mejorar en tiempo real nuestro entendimiento. Sugiero leer http://swgu.ru/sg3408 En los años por delante, un área de gran acción será la de “los datos como plataforma” y tecnologías asociadas. Aunque la privacidad de datos continuará siendo tema de discusión, eventualmente las empresas explorarán la venta de datos. Emprendamos pues una conversación al rumbo de la auténtica economía de la información.

>> Por Luis Daniel Soto

Software Guru

Mashup de datos. La capacidad de mejorar el diagnóstico médico ANTES de llegar a la sala de urgencias se está volviendo una realidad en los países desarrollados y no me refiero a temas altamente relacionados con la privacidad como los productos que compramos en el supermercado y hábitos de ejercicio que podrían ser extraídos de nuestra “estela” transaccional, o el almacenamiento del registro médico en la nube. Expongo un ejemplo: Con los sensores de ubicación de las ambulancias “unido” a los patrones de tránsito en las ciudades es posible optimizar el movimiento para atender urgencias.

que el aprendizaje basado en máquinas será fundamental.

www.sg.com.mx |

l costo de la “captura manual” de un petabyte de información en la década pasada rebasaba, dependiendo de la precisión, varios millones de dólares.

Gracias a los avances tecnológicos, hoy el gran volumen de información “nace de forma digital”. Al ritmo actual de compresión y depuración automática de datos, el costo de almacenar un petabyte al final de la década será menor a cinco dólares estadounidenses.

El “valor” de la información será mayor que el “costo” de almacenarlo.

Las implicaciones son enormes. Todos debemos estar entusiasmados con las nuevas oportunidades que se abren:

Luis Daniel Soto Maldonado es Director de Technical Product Management para SQL Server en Microsoft Corporation. @luisdans

.HERRAMIENTAS Y TECNOLOGÍAS Tutorial

Versionando con Git comprendiendo los comandos básicos

E

n este artículo explico los aspectos básicos para aprender a usar el sistema de control de versiones (VCS) Git. Para explicar mejor el funcionamiento de Git, estaremos usando la línea de comandos. Mi recomendación para entender Git es entender los conceptos con los comandos asociados, y después si así se desea, buscar alguna interfaz diferente más acorde a los gustos personales.

El modo Git

Muy al contrario de como se maneja un VCS tradicional (como Subversion), Git maneja los repositorios, y los conceptos mismos de un VCS de una manera particular. Mientras que para Subversion, el control de versiones se hace archivo por archivo, sobre cada directorio que integra un proyecto, para Git el control de versiones se hace sobre los distintos ‘snapshots’ que se tomen de todo el proyecto. La diferencia radica en que para sistemas como Subversion, cada versión del proyecto incluye la versión de cada uno de los archivos del mismo. Mientras tanto, para Git cada versión del proyecto incluye solamente un manifiesto con las diferencias de cada archivo, es decir de cómo se ve el proyecto en su totalidad en determinado momento.

Entendiendo Git así, será fácil adaptarse a su modo de funcionamiento, e incluso salir de usar un VCS centralizado y comenzar a usar la genial idea que representan los VCS distribuidos.

Generando un repositorio

El primer paso para utilizar Git es tener un repositorio. El repositorio Git se representa por un directorio especial llamado .git y que reside en el directorio raíz del proyecto mismo. Git sólo genera un único directorio para todo el repositorio, en donde almacena toda la información del mismo (versiones, historial, etc.).

Hay dos maneras de generar un repositorio para trabajar con Git sobre un proyecto: a) Inicializando un directorio como repositorio Git. Suponiendo que se tiene un directorio en el que reside el proyecto a versionar, el comando git init crea el repositorio para el proyecto dado.

Esta generación del repositorio es completamente local a la máquina y el directorio donde reside el proyecto. $ cd proyecto $ git init

b) Copiando un repositorio Git. Ahora supongamos que deseamos colaborar en algún proyecto (o simplemente queremos ob12

››Por Javier Novoa

tener su código fuente para compilarlo y usarlo, o para mirarlo - y admirarlo. Para esto, lo que debemos hacer es clonar el repositorio origen del proyecto para así tenerlo como un repositorio local. Los repositorios git tienen una URL, y con ella se utiliza el comando: git clone [url] para clonar el repositorio remoto a un repositorio local sobre el cual trabajar.

Para los ejercicios de este artículo utilizaremos un repositorio que ya he creado, así que para clonarlo hay que ejecutar lo siguiente desde línea de comandos: $ git clone git://github.com/jstitch/masterm.git

Esto clonará el repositorio remoto y creará un repositorio local bajo el directorio masterm. De tal forma que ahora podemos entrar a nuestro directorio local y ver los archivos. Si se observa el contenido de los archivos ocultos de este directorio, se podrá notar un directorio .git.

Si no se ha hecho aún, es necesario indicarle a Git los datos que utilizará el sistema para saber qué usuario será el responsable de los cambios hechos. De otra manera no tendría sentido usar un VCS, sin tener a quién echarle la culpa, perdón digo darle gracias, por los cambios hechos al código. Esto se logra con los siguientes comandos: $ git config --global user.name ‘Tu nombre’ $ git config --global user.email tu@dominio.com

Usando el repositorio local

El funcionamiento básico de Git consiste en trabajar de forma local lo más posible: modificando archivos, generando branches, haciendo merges entre branches, agregando los archivos con cambios que se deseen versionar, versionándolos y así sucesivamente. Solamente cuando ya se tiene un conjunto de código y cambios hechos y probados se procede a mandarlos al repositorio origen desde el cuál se clonó (o a solicitar que se integren los cambios hechos al mismo en caso de no tener los permisos adecuados).

En resumen, se utiliza git add para agregar los cambios a los archivos que se desea que Git tome en cuenta para la siguiente versión del código, git status y git diff para observar los cambios puntuales que se realizarán para la siguiente versión y git commit para almacenar dicha versión en el historial del repositorio. Este es el flujo principal que se sigue al trabajar con Git, y hay que destacar que todo se hace de manera local, sin interacción con repositorios remotos: recuérdese que se está trabajando sobre un repositorio local y que precisamente éste es el sentido de los VCS distribuidos.

.HERRAMIENTAS Y TECNOLOGÍAS Tutorial

$ touch new_file $ echo “” >> README.md $ git status

$ echo “hola mundo” >> new_file $ git diff

El mensaje de resultado nos indica que Git detecta cambios que no han sido marcados para versionarse en el archivo new_file. Si se deseara ver las diferencias que Git detecta tomando en cuenta los cambios en los archivos que ya fueron marcados para versionar, aunque todavía no se les haya hecho commit, se utiliza el parámetro --cached.

Por último, si lo que se desea es ver todos los cambios, tanto de lo marcado para versionar como lo que no, se le pasa a git diff como parámetro la versión contra la cual se quiere comparar el código actual. El nombre HEAD se refiere a justamente la última versión que se tiene almacenada el repositorio. $ git diff HEAD

git commit. Finalmente, una vez hechos los cambios deseados y agregando a los archivos que se desea sean incluidos en esta versión, se realiza el commit al repositorio (recuérdese: es local, ¡no hay necesidad de conexión a la red todavía!): $ git commit -m “cambios al README y creando new_file”

El resultado que obtendremos será el estatus de git, reconociendo que se modificó un archivo existente (README.md) y se agregó uno nuevo (new_file), pero ninguno de los dos está contemplado para incluirse en el próximo commit. Para que sean considerados debemos agregarlos:

Como se puede observar, con el argumento -m indicamos un mensaje descriptivo de esta versión. Este es obligatorio.

Si ahora verificamos el estatus con git status, veremos que sólo queda un cambio detectado por Git: aquel que hicimos posterior al git add, y por lo tanto no está marcado todavía para ser versionado.

$ git add README new_file $ git status

Branches y Merges

Y ahora sí, Git sabe que ambos archivos deben ser versionados. git status. El comando git status, que ya utilizamos, nos permite conocer el estatus con el que Git tiene identificado a los archivos del proyecto. Se puede agregar la opción -s para que nos entregue una respuesta resumida. En dicho caso, el estatus aparece en dos columnas: la primer columna indica los cambios que hará Git en la siguiente versión del código, y la segunda columna indica cambios que Git reconoce como tales pero que no versionará. git diff. Otra operación muy común al trabajar con archivos versionados es la de observar y analizar los cambios hechos, así como las diferencias entre la nueva versión y la que se tiene en una versión anterior.

13

Para los provenientes de VCS centralizados como SVN, muy probablemente el nombre ‘Branch’ ya dibujó en su mente la idea de una pesadilla dantesca. La realidad es que el manejo de branches en versionadores centralizados suele convertirse en una molestia más que en una herramienta útil. Tan es así que muchos proyectos renuncian a su uso y se dedican únicamente a versionar sobre un árbol principal de código, dejando de lado una de las ventajas esenciales que proporciona un versionador. Pero la buena noticia es que en los versionadores distribuidos, y en Git en particular, el manejo de branches es, dicho llanamente, maravilloso.

Una manera de entender los branches en Git es verlos como contextos en los que se trabaja una versión específica del código. Digamos que bajamos el código fuente de un software que utilizamos mucho y detectamos un bug. El modo Git de afrontarlo sería, luego de clonar el repositorio, crear un branch y ahí trabajar la corrección del bug.

Software Guru

Por ejemplo:

Git utiliza diff para esto mismo, como puede verse en el siguiente ejemplo:

www.sg.com.mx |

git add. Inicialmente, ningún cambio a ningún archivo sobre el que trabajemos, es considerado por Git para versionar. Es necesario hacer un git add para que Git sepa en particular qué archivos con cambios serán versionados. Esto proporciona un control muy fino del proceso de versionado. En sistemas como SVN si un archivo es considerado para versionar, lo es desde que es agregado al repositorio y hasta siempre. Si deseamos modificar este archivo aún cuando esa modificación no tenga nada que ver con las modificaciones a otros archivos, el proceso de commit se llevará de una sola vez a todos los archivos versionados. En Git sin embargo tenemos la opción de elegir puntualmente qué archivos con cambios se van a versionar.

Así, si hacemos una modificación que sea una corrección de un bug en varios archivos, y a la vez modificamos otros archivos para corregir errores de tipografía en la documentación, Git nos permite versionar cada una de estas modificaciones por separado, permitiendo identificar más fácilmente qué archivos cambiaron como parte de qué modificación, sin confundir con otros archivos relacionados a otras modificaciones.

.HERRAMIENTAS Y TECNOLOGÍAS Tutorial

Si además resulta que tenemos una propuesta de mejora al software, lo correcto desde el punto de vista del modo Git de trabajarlo sería crear otro branch a partir del original (o maestro) y ahí trabajar los cambios. Finalmente cuando el bug esté corregido, se integran (vía merge) con el branch maestro. Y cuando nuestros cambios estén hechos y probados también, se hace lo mismo desde aquel otro branch al maestro de nuevo. Así, al final, se tiene un código limpio, probado y bien versionado, todo gracias al uso de branches.

Los comandos principales para el manejo de branches son: • git branch para crear branches • git checkout para hacer cambio de contextos • git merge para unir branches

Si hacemos un git status, nos indica que los cambios que no se han marcado para versionar (recuerden que new_file aún tiene cambios sin marcar) pasan entre contextos de manera transparente. Si ahora marcamos algún cambio para versionar en uno de los contextos:

Otra característica notable del manejo de branches de Git es que los branches no se creados como subdirectorios separados como en SVN. Más bien, el directorio .git contiene toda la información (en forma de snapshots o diferencias entre cada archivo y sus branches), y así en un sólo directorio de trabajo del proyecto, al cambiar de contexto, todo el código del mismo directorio pasa a ese nuevo estado. Se puede cambiar entre contextos libremente y sin pérdida de información, y sin el estorbo de un directorio dedicado a cada branch del proyecto.

$ git commit -m “agrego texto a new_file, como prueba”

git branch y git checkout. Al crear un nuevo repositorio en Git, por defecto se tiene un único branch, el inicial o principal del proyecto.

Se le llama master por default. El comando git branch lista todos los branches existentes actualmente en un proyecto. En caso de haber varios, uno de ellos será marcado con un asterisco, para indicar cual es el branch o contexto actual. Para crear un nuevo branch, se utiliza el comando git branch [nombre_del_branch]. $ git branch testing $ git branch

Como se puede observar, ya existe un nuevo branch en el proyecto (testing). Este branch está hecho a partir del código en su último estado: tanto los últimos commits como los archivos con cambios que han y no han sido añadidos para versionar. Y para pasar a ese nuevo contexto y trabajar sobre él, se utiliza git checkout [nombre_ del_branch]: $ git checkout testing $ git branch

Ahora es testing el contexto actual sobre el que se trabajará en el proyecto. Si hacemos algunos cambios en un archivo, y luego regresamos al contexto original (masterm_lang), como no se le indicó a Git que los cambios se irían a versionar en ese contexto, los cambios pasan transparentes entre contextos: $ echo “hola README” >> README.md $ git checkout masterm_lang

14

$ git add new_file $ git status -s $ git checkout testing $ git status -s

Como se puede observar, aquí también los cambios marcados para versionar pasan transparentes entre contextos. Git no puede saber si la marca agregada para versionar es para uno u otro contexto, y sólo sabrá información más concreta hasta hacer un commit:

Y ahora sí, los cambios hechos a new_file quedan en el branch testing, no en la rama principal. Si vemos el contenido de new_file, veremos que tiene el texto “hola mundo” que agregamos. Pero si nos regresamos al branch masterm_lang, veremos que new_file aquí no tiene el texto “hola mundo”. Solamente está en el branch testing, que es donde se hizo el commit de ese cambio. $ git checkout masterm_lang $ cat new_file

git merge. Supongamos que ahora deseamos que el cambio en testing quede reflejado también en masterm_lang. Lo que debe hacerse es un merge, una operación que la mayoría de las veces Git puede hacer por su propia cuenta. $ git branch $ git merge testing $ cat new_file

¿Pero qué pasaría si otro usuario hubiera hecho cambios a new_ file sobre masterm_lang antes que nosotros hubiéramos hecho el commit? Entonces Git generaría lo que se conoce como un conflicto, que no es otra cosa sino la forma en que Git indica que no sabe como hacer el merge por sí solo y necesita de la ayuda externa de los usuarios. Los conflictos no ocurren siempre, incluso aunque muchos usuarios hagan cambios al mismo archivo muchas veces. Básicamente si los cambios se hacen sobre líneas diferentes del dicho archivo, Git sabrá hacer el merge sin problemas. Es cuando se hacen cambios que inmiscuyen líneas iguales en el archivo cuando Git puede verse en problemas... veámoslo con un ejemplo, recordando que aún hay un cambio sin versionar en README: $ git checkout testing $ git add README.md $ git commit -m “agrego cambio a README esperando generar conflicto en master”

.HERRAMIENTAS Y TECNOLOGÍAS Tutorial

$ git merge testing $ git status -s $ tail README.md

¿Qué sucedió? Pues que Git no supo qué hacer y generó un conflicto al hacer el merge. Este conflicto queda marcado para Git (según el resultado de git status -s, y también dentro del mismo archivo README, como puede verse por los marcadores que se agregaron automáticamente al archivo en los lugares en donde ocurrió el conflicto. Para resolver el conflicto, se necesita la intervención humana. Normalmente aquí es donde los desarrolladores responsables de los cambios que ocasionaron el conflicto se baten en duelo y se ponen de acuerdo para decidir cómo resolver el conflicto. Al final, uno de los desarrolladores deberá editar el archivo con conflicto, dejar el cambio adecuado y retirar las marcas de conflicto (<<<< y >>>>) que colocó Git. Esto lo puede hacer editando manualmente el archivo o con alguna herramienta de resolución de conflictos, invocando git mergetool. git log. Un sistema que maneja tan eficientemente tanta información como Git no sería nada útil si no permitiera también mostrar de manera ordenada dicha información al usuario, de forma que él pueda saber con exactitud algún pedazo que le sea realmente útil. Para eso existe git log.

Este comando tiene en realidad muchos usos y muchas formas diferentes de generar y reportar la información con que cuenta Git, por lo que veremos solamente algunos ejemplos que podrían ser útiles: $ git log

git log muestra en bloques cada uno de los commits que se han hecho dentro del branch actual. Se puede observar que entre la información mostrada para cada commit, además del mensaje, autor y fecha, se da una cadena de identificación. Este identificador de los commit se puede usar como parámetro a comandos como git diff para comparar el estado actual del proyecto contra alguna versión específica. git log puede usar algunos parametros opcionales. Con el parámetro --oneline se muestra solamente el identificador corto y la descripción del mismo, para un resumen breve. Con el parámetro --graph se puede ver incluso de manera visual cómo han evoluciona15

git tag. Para terminar con este asunto de los branches, vamos a mencionar los tags. Casi cualquier versionador permite manejar este concepto (unos más fácilmente que otros). La idea detrás de un tag es tener una especie de fotografía fija del proyecto en cierto momento.

De esa forma, cuando se quiera tener el código del proyecto justo como se tuvo en el momento de tomar la ‘fotografía’, simplemente uno va al tag y lo recupera.

Esto es sumamente útil cuando, por ejemplo, se tiene el proyecto en un estado listo para liberar a un entorno de producción, digamos que ya tenemos la versión 1.1.2 y queremos liberarla. Entonces se genera un tag del momento del proyecto deseado, se le etiqueta como ‘versión 1.1.2’ y listo. Git tiene la información que nosotros podemos usar cuando deseemos, por ejemplo regresamos el código al estado de ese tag y luego empaquetamos o compilamos o lo que fuera necesario... $ git tag -a v1.1.2 $ git log --oneline --decorate --graph

Como se puede observar, al usar el parámetro --decorate de git log (que muestra más información sobre los branches), también se muestra ahora el tag que acabamos de generar para el HEAD del repositorio. Obviamente, también se puede dar tag a alguna versión diferente al HEAD, para lo cual al comando git tag simplemente se le agregaría el identificador del commit al que deseemos ponerle el tag.

Para pasar el código de un tag a otro, se puede usar el mismo comando git checkout, pero en lugar de usar el nombre de un branch como parámetro, se usa el nombre dado al tag (también se puede usar el identificador de un commit cualquiera). El parámetro -l nos informa de todos los tags que tenga creados el repositorio: $ git tag -l

Conclusión

En este tutorial aprendimos los aspectos básicos para manejar un repositorio git local. El siguiente paso es aprender a interactuar con un repositorio remoto. Por razones de espacio no se ha incluido esa sección aquí, pero pueden consultarlo en la versión original y completa de este artículo, que está disponible en http://swgu.ru/sg3407 .BIO Javier Novoa es ingeniero en sistemas con maestría en ciencias de la computación con preferencia por la administración de servidores GNU/Linux y el desarrollo en Python/PHP/Java/C++. Radica en la Ciudad de México y es fanático de la literatura fantástica, la astronomía amateur, el ajedrez y la música rock. jstitch@gmail.com @JaviStitch

Software Guru

Ahora regresamos a masterm_lang y ahí hicimos un cambio diferente sobre el mismo archivo, en la misma línea (la última) que el cambio que se versionó en testing. Todo eso antes del merge. Y ahora a ver que pasa:

do los branches y los posibles merge hechos entre ellos.

www.sg.com.mx |

Hasta aquí versionamos el cambio al branch testing... $ git checkout masterm_lang $ echo “hello README” >> README.md $ git add README.md $ git commit -m “agrego cambio a README esperando conflicto en merge”

.HERRAMIENTAS Y TECNOLOGÍAS Novedades

WebSockets eventos a tiempo real en nuestro navegador

HTML5

ha llegado. La quinta revisión de HTML nos trae muchas novedades y los WebSockets es una de ellas, que tendrá un gran impacto en la forma en que desarrollamos aplicaciones web. Los WebSockets son dos estándares en uno: el estándar del protocolo de comunicaciones desarrollado por el IETF; y el estándar de la API JavaScript para utilizarlos en nuestras páginas Web. En este artículo vamos a ver qué son y cómo funcionan.

Antecedentes

Antes de comenzar, hagamos un poco de historia y remontemos unos años atrás. Imaginemos que queremos hacer una aplicación con comunicación a tiempo real, como por ejemplo un chat. La aplicación es muy simple. Un cuadro de texto donde el usuario introduce un mensaje, un botón para enviar y un listado con los mensajes del chat.

Si nos planteamos hacer esta aplicación en un cliente pesado, el desarrollo es trivial. Abrimos un puerto y lo ponemos a la escucha para que actualice la lista de mensajes cuando alguien crea un mensaje nuevo.

El problema está cuando queremos hacer esta misma aplicación en el navegador web. Básicamente, el dilema está en que no podemos abrir un puerto en el navegador y ponerlo a la escucha, tal y como lo haríamos con una aplicación de escritorio. Podemos hacer algo usando tecnologías como Flash o Java Applets, pero no es el escenario ideal y es muy probable que tengamos problemas con firewalls.

Si nos centramos en el protocolo HTTP, vemos que podemos mantener abierta la conexión e ir enviado información poco a poco usando tecnología Push, este nuevo modelo de aplicación Web se denomina COMET. En teoría es perfecto, pero en la práctica tiene algunos inconvenientes: • En el servidor. Los servidores web tradicionales no están diseñados para este tipo de cosas. Nos encontramos directivas del tipo keep-alive y MaxClients. Los servidores Web, en sus configuraciones por default, interpretan que estas conexiones que mantenemos abiertas mucho tiempo, son scripts que se nos han quedado colgados, y las cierran.

16

››Por Gonzalo Ayuso

• En el navegador. Los navegadores tampoco están preparados para mantener conexiones abiertas con el servidor durante un tiempo indefinido. En teoría funciona, pero en la práctica las conexiones terminan muriendo.

En resumen, tenemos un modelo de aplicación web llamado COMET que en teoría nos permite hacer notificaciones a tiempo real en el navegador, pero en la práctica tenemos problemas con los servidores y con los navegadores.

Para resolver los problemas en el lado del servidor podemos usar servidores alternativos a los tradicionales. Por ejemplo, un servidor hecho con Node (node.js) puede funcionar muy bien para manejar conexiones de este tipo, gracias a la naturaleza no-bloqueante de Node.

Resolviendo el problema del servidor, ahora enfoquémonos en el navegador. Aquí normalmente usamos técnicas para simular eventos en tiempo real. Lo más común es hacer ShortPolling, que básicamente consiste en preguntar al servidor cada x segundos si ha habido algún evento, para ello se usa un timer con JavaScript (setInterval o setTimeout) o la histórica etiqueta meta http-equiv=”refresh”. Es como cuando viajamos con niños en coche y nos preguntan cada 5 segundos si falta mucho para llegar. Esta técnica cumple el propósito, pero no es escalable.

Por otro lado tenemos el Long-Polling que consiste en dejar abierta una conexión hasta que haya información nueva para enviar al navegador. Tampoco es una solución ideal porque sobrecargamos los recursos de nuestro servidor, y podemos encontrarnos con timeouts.

WebSockets

Afortunadamente, con la llegada de HTML5 nos llegan los flamantes WebSockets. Básicamente es la solución a todos los problemas mencionados con anterioridad. Los nuevos WebSockets nos dan una interface JavaScript para manejar conexiones no bloqueantes con el servidor.

El listado 1 muestra un ejemplo de uso de WebSockets en el navegador.

.HERRAMIENTAS Y TECNOLOGÍAS Novedades

Como podemos ver, el interface es similar al de los WebSocket.

Esto viene acompañado de la parte del servidor, que socket.io la implementa por medio de node.js:

var ws = new WebSocket(url); ws.onopen = function() { // When the connection opens }; ws.onmessage = function() { // When the server sends data }; ws.onclose = function() { // When the connection is closed }; ws.send(‘Hi all’); // later... ws.close();

var io = require(‘socket.io’).listen(80); io.sockets.on(‘connection’, function (socket) { socket.emit(‘news’, { hello: ‘world’ }); socket.on(‘my other event’, function (data) { console.log(data); }); }); Listado 3. Implementación de servidor en Socket IO.

Listado 1. Uso directo de WebSockets en el navegador.

Entonces ¿Podemos usar WebSockets hoy? Pues la respuesta es sí. Y digo sí con rotundidad gracias a una gran libreria llamada Socket IO (socket.io). Socket IO es, por decirlo de alguna manera, el jQuery de los WebSockets.

La gracia de esta genial librería es que no necesita un navegador que soporte WebSockets. Si nuestro navegador los soporta, los usará.

Si por lo contrario usamos un navegador más viejo, socket.io emulará el comportamiento de los WebSockets usando el mejor modo de transporte soportado por ese navegador, y todo esto de una forma transparente para nosotros.

El listado 2 contiene un código en javascript que ejemplifica como podemos usar socket.io en el navegador. <script src=”/socket.io/socket.io.js”></script> <script> var socket = io.connect(‘http://localhost’); socket.on(‘news’, function (data) { console.log(data); socket.emit(‘my other event’, { my: ‘data’ }); }); </script> Listado 2. Código para cliente con Socket IO.

17

• WebSocket • Adobe® Flash® Socket • AJAX long polling • AJAX multipart streaming • Forever Iframe • JSONP Polling Esto le permite soportar una amplia lista de navegadores y versiones, que incluye: Internet Explorer 5.5+, Safari 3+, Google Chrome 4+, Firefox 3+, Opera 10.61+, iPhone Safari, Android WebKit. Así es, incluso IE 5.5 es soportado, y todo esto usando el mismo interface para el desarrollador.

Por donde empezar

Gracias a Socket IO podemos tener notificaciones a tiempo real de forma sencilla y soportada por prácticamente todos los navegadores.

Un sueño imposible hace unos años, al alcance de nuestra mano a día de hoy. Merece la pena echarle un vistazo.

Referencias [1] Socket IO. http://socket.io [2] WebSocket. http://websocket.org [3] D. Zavala. “Introducción a Node.js”. http://swgu.ru/intro_node

.BIO Gonzalo Ayuso es Desarrollador y arquitecto web con más de 10 años de experiencia, especializado en tecnologías open source. Puedes leerle en su blog http://gonzalo123.wordpress.com y seguirle en @gonzalo123.

Software Guru

Socket IO al rescate

Socket IO soporta los siguientes modos de transporte:

www.sg.com.mx |

¿Genial, no? Entonces, del lado del servidor resolvemos nuestros problemas implementando un servidor en Node y del lado del cliente utilizamos WebSockets. Asunto resuelto ... bueno, no en realidad, no cantemos victoria todavía. Desgraciadamente, los WebSockets no están soportados en todos los navegadores. Nuestro gozo en un pozo.

Tenemos la tecnología, pero tenemos que esperar a que todos nuestros usuarios usen navegadores de última generación (incluso que los navegadores incorporen esta nueva especificación a sus versiones estables).

Fotografía cortesía de Santiago Zavala.

Generación de Modelos de Negocio pilar del emprendimiento

››Por Víctor Reyes

C

onstantemente le pregunto a mis alumnos de la Maestría de Negocios del ITESO en Guadalajara, a los participantes del Bootcamp en TechBA Silicon Valley y en los Startup Weekends ¿qué es más importante: un excelente producto o un excelente modelo de negocio? Y normalmente llegamos a la misma conclusión, es más importante tener un buen modelo de negocio. Tal y como menciona Henry Chesbrough: “A mediocre technology pursued with a great Business Model may be more valuable that a great technology exploited via a mediocre Business Model.”

Del artículo de “Reinventing your Business Model” de Harvard Business Review [1] destacaré dos cifras que dan una idea de la importancia del concepto.

1. 11 de las 27 compañías nacidas en los últimos 25 años y que han crecido hasta estar dentro de las Fortune 500 en los últimos diez años, lo hicieron a través de la innovación en sus modelos de negocio.

2. Una encuesta del 2005 practicada por la Unidad de Inteligencia de The Economist, reportó que más del 50% de los ejecutivos creen que la innovación en el Modelo de Negocio llegará a ser más importante para el éxito que la innovación en productos y servicios.

Con el propósito de generar un entendimiento común sobre el concepto de Modelo de Negocio les pido hacer una reflexión, pregunten a la gente que tengan alrededor, ¿qué es un Modelo de Negocio? Apuesto a que una gran parte de ustedes obtuvieron la siguiente respuesta… “es la 18

manera en que hacemos dinero”. Esta respuesta es parcialmente correcta, ya que la corriente de ingresos es uno de los nueve elementos del modelo, al igual que la fórmula de rentabilidad, pero no lo es todo.

El Modelo de Negocio es cómo la compañía crea, entrega y captura valor.

Alexander Osterwalder es un renombrado consultor en innovación y modelos de negocio que se dio a la tarea de crear algo que hacía mucha falta: un texto metodológico completo sobre modelos de negocio. Es así que en 2010 en conjunto con Yves Pigneur publicó el libro “Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers” [2].

La metodología planteada por Osterwalder plantea de forma simple y puntual los elementos básicos pero suficientes para integrar el negocio. No se necesita un extenso documento con decenas o cientos de páginas que diga cómo se quieren generar los ingresos para la compañía. Debemos ser capaces de mostrar en una sola imagen todos los elementos que le dan viabilidad y sustentabilidad a nuestro negocio.

Los nueve bloques constructores

El modelo se describe a través de nueve dimensiones o bloques que muestran la lógica de cómo una compañía pretende ganar dinero y la interacción entre cada uno de los bloques. Dichos bloques se ilustran en la figura 1.

Obviamente, la definición de modelo tendrá que ver con la necesaria interconexión o interrelación entre todos los bloques, los cuales

.EMPRENDIENDO Industria

“El Modelo de Negocio es cómo la compañía crea, entrega y captura valor.”

ingresos llegarán a la compañía si esta entiende bien cuál es el valor por el cual los clientes realmente están dispuestos a pagar. Aquí encontramos varias maneras en cómo se pueden generar esos ingresos: por la venta de un producto, cobrar suscripciones, renta, licenciar propiedad intelectual, publicidad, etc.

Actividades clave. Este bloque describe las actividades más importantes que una compañía debe hacer para que su modelo de negocio funcione. Dichas actividades pueden ser divididas en producción, que tiene que ver con la entrega física de un producto; de solución de problemas o de creación de una plataforma.

Segmento de clientes. Este es el primero de los bloques con el cual se debe iniciar la lógica del modelo, debiendo entender cuál es el racional en base al cuál vamos a segmentar al grupo de personas u organizaciones que vamos a servir, cuál es su necesidad a satisfacer y una vez entendida, se puede diseñar el modelo de negocio.

Propuesta de valor. Describe cuál es el paquete de productos y servicios que crean valor para esos segmentos específicos de clientes.

Es lo que hace a las compañías únicas y diferentes y por lo cual sus clientes van a preferirlos por sobre otras empresas. Se basa en la satisfacción de problemas o necesidades de los clientes entregándoles beneficios valiosos. Algunos de los elementos que crean valor para los clientes pueden ser la novedad, la mejora en desempeño, la individualización, el precio, la reducción de riesgos, la conveniencia, etc.

Canales. Cómo una compañía se comunica y llega a sus segmentos de clientes para entregar la propuesta de valor. Son los puntos de contacto que juegan un papel importante en la experiencia de usuario del cliente.

Aquí la principal definición es si los canales serán directos o indirectos, lo que obviamente tiene una afectación en margen pero puede potenciar el alcance. El balance adecuado será el que maximice los ingresos.

Relaciones con clientes. El tipo de relaciones que se mantengan con los clientes es fundamental para la adquisición, retención y crecimiento de los clientes y obviamente tendrá una relación directa con el canal que se haya elegido.

Flujos de ingresos. Representa el efectivo que la empresa genera de cada segmento de clientes. Básicamente los ingresos pueden ser de dos tipos, transaccionales, de única ocasión, o recurrentes. Los 19

Recursos clave. Este bloque incluye a los recursos o activos que se requieren para desempeñar dichas actividades clave. Los recursos pueden ser materiales, financieros, humanos y más importante aún, intelectuales como patentes, marcas, etc.

Alianzas clave. Describe la red de proveedores y socios que se requieren para que el modelo funcione adecuadamente, creando dichas alianzas sobre todo para optimizar el modelo por economías de escala, la reducción de riesgo e incertidumbre o la adquisición de recursos para el desempeño de ciertas actividades. Pueden ir desde una simple relación proveedor-comprador hasta una alianza estratégica.

Estructura de costos. Cuáles son los costos que se generan a propósito de las actividades y los recursos necesarios para desempeñarlos.

Las estructuras de costos se pueden basar en dos enfoques principalmente: aquellos guiados por el costo y aquellos guiados por el valor.

El primer enfoque se basa en minimizar el costo al máximo posible, mientras que el segundo se centra en el costo que sea necesario para crear el valor necesario para entregar.

La expresión gráfica del modelo se lleva a cabo en lo que se llama el Business Model Canvas que proviene y recuerda al lienzo de un pintor. Normalmente lo desarrollamos a través de talleres con expertos en los temas dentro de una empresa, y es una actividad colaborativa que busca fomentar el entendimiento, discusión, creatividad y análisis. Se puede desarrollar de manera física en un poster en donde podemos pintar o pegar notas o de manera electrónica en donde ya existe la aplicación para iPad creada por el propio Osterwalder.

.BIO Víctor Reyes ha tenido una trayectoria de más de 20 años en puestos gerenciales y directivos en los sectores privado y público. Es ex Director de Negocios de Innovación del CONACYT y actualmente es fundador, cofundador y/o participante activo de varias iniciativas que buscan impulsar el emprendimiento e innovación tecnológica como MexicoInnova, INPROTEC, Startup Dojo, Mexican VC, Startup Weekend, TechBA Silicon Valley. @vmreyesp

Referencias: [1] M. W. Johnson, et al. “Reinventing your Business Model”. Harvard Business Review, December 2008. http://swgu.ru/sg3405 [2] A. Osterwalder & Y. Pigneur. “Business Model Generation”. http://swgu.ru/r3406

Software Guru

no se pueden ver de manera aislada; unos son consecuencia de otros y por lo tanto se trata de poder construir un flujo basado en ellos. En el centro está la propuesta de valor, hacia el lado derecho a quién se entrega y cuánto nos genera y en el lado izquierdo cómo se construye y cuánto nos cuesta.

Siguiendo la lógica anterior explicaremos brevemente a qué se refiere cada bloque.

www.sg.com.mx |

Figura 1. Los 9 bloques del modelo de negocio.

SG Conference & Expo 2011

Integrando la comunidad de Profesionistas de TI

››Por Equipo organizador

L

a sexta edición del evento insignia de Software Gurú se llevó a cabo exitosamente el pasado 7 y 8 de septiembre en la Cd. de México. A lo largo de dos días, el evento logró reunir a más de 800 dignos representantes de la industria de TI, así como a reconocidos ponentes nacionales e internacionales, contando con la participación de prestigiadas empresas de la industria de software a nivel global.

Como ya es costumbre este evento fué el punto de reunión de los más destacados profesionistas, hackers y emprendedores de TI, que compartieron su experiencia y conocimiento fomentando una excelente dinámica de networking.

Con gran gusto nos encontramos con asistentes que nos acompañan y colaboran con SG desde el primer congreso, y es un orgullo saber que de alguna manera hemos apoyado al desarrollo de estos profesionistas.

20

.ESPECIAL Reseña

La entrada

Alcanza para todos: La Feria de Reclutamiento

La inauguración se llevó a cabo por el Director y socio fundador de Software Gurú, Pedro Galván, quien además de reconocer el esfuerzo de los participantes por asistir al evento, compartió con la audiencia el futuro y visión de SG, presentando nuevos productos como SG Talento y Nearshore Link. El evento fué moderado por la coordinadora editorial de la Revista SG, Vanessa Amaya, y contó con la participación de Elizabeth Argüello, Directora de Economía Digital de la Secretaría de Economía, quien nos compartió su visión de la industria de TI, así como los avances que han tenido los diversos Programas que la apoyan.

Acompañando al lanzamiento de SG Talento, se realizó la feria de reclutamiento “Buscando Talento”, organizada en conjunto con la empresa Empleos TI, durante la cual las empresas participantes contactaron con diversos profesionistas. Las empresas participantes fueron: Kelly IT Resources, 4thSource, Neoris, Porto Mx, Adecco, Congnizant, Tacit Knowledge, Softtek, IDS, Hildebrando, ABS, ScreenIT, Randstad, e-global Consultores, Nearsoft, IBM, Oracle, Alpha Consultoria, App Studios, Global Lynx, Extend Solutions, Infotec, Ironbit y Ultrasist.

El plato fuerte

La cereza del pastel: AppCircus

Y de la entrada nos fuimos directo al plato fuerte, ya que los conferencistas magistrales nos compartieron una diversa gama de interesantes temas. Iniciamos con el keynote “Fact and Fallacies of Software Development” presentado por Venkat Subramaniam, fundador de Agile Developer, Inc. quien demostró su experiencia de haber entrenado y asesorado a miles de desarrolladores de software y con una ponencia sumamente amena logró la participación activa de la audiencia.

Finalizando el primer día, contamos con la plática de Brad Hipps, Gerente de Soluciones de software en HP, quien compartió su experiencia en el ciclo de vida de las aplicaciones, y su implementación en diversas organizaciones a nivel mundial.

No podía faltar la participación de expertos y apasionados desarrolladores de software Mexicanos, como fué el caso de Raúl Guerrero, quien nos platicó sobre la Gestión del Proceso de Desarrollo utilizando Scrum, donde compartió experiencias de su trabajo actual en Microsoft como Especialista en Herramientas de Desarrollo, así como recomendaciones gracias a su participación activa en Comunidades.

Ash Maurya inició las conferencias del segundo día, con el tema “Running Lead”, creador del libro que lleva el mismo nombre, material de referencia esencial para los emprendedores en la web, demostrando la razón por la cual es una de las figuras más reconocidas en el ámbito de los nuevos emprendimientos basados en tecnología.

Gustavo Garnica, fue el encargado de dar el toque final al plato fuerte, quien gracias a su amplia experiencia como Arquitecto Senior de Middleware, en proyectos para clientes en México y LA, nos compartió la visión altamente esperada sobre el futuro de la plataforma Java.

AppCircus es una feria itinerante, escaparate de las aplicaciones móviles más creativas e innovadoras, que en esta ocasión se presentó en SG Conference & Expo. Durante esta dinámica 10 emprendedores presentaron sus aplicaciones. El ganador fue José Balcázar de la empresa Huawei, quien ahora tiene la oportunidad de pertenecer a las apps nominadas para los Mobile Premiere Awards (MPA) 2012 en Barcelona. AppCircus fue patrocinado por BlueVia.

Una variada ensalada: Ignite sobre emprendimiento Con una combinación de múltiples ponentes, quienes en 5 minutos nos compartieron sus ideas, perspectivas, propuestas relacionadas a la creación y ejecución de startups en México, se presentó el Ignite dedicado al emprendimiento tecnológico.

Para acompañar: Más de 20 sesiones Para compartir el conocimiento y la práctica real, contamos con la participación de los expertos locales, combinando una interesante agenda de conferencias.

21

La Charla Todo momento fue aprovechado para networking, visitas a Expo, las comidas, y los deliciosos “startup-waffles”, que fomentaron la convivencia entre los participantes, quienes crearon nuevas relaciones y se reencontraron con colegas.

El Postre: La Expo La Expo contó con la participación de diversas empresas y organismos, a quienes reconocemos su compromiso con la industria y agradecemos su apoyo: Oracle, HP, Infotec, Pronatura, Microsoft, Global Lynx, México First, Blackberry, Qualtop, Alpha Consultoría, Vinkos, Fumec, Ironbit, Ultrasist, AppStudios, CIAPEM, CANIETI, AMITI, emprende.la, CITI Tabasco, IJALTI y al Consejo de Software de Nuevo León. En especial agradecemos a Secretaría de Economía por apoyar al evento mediante el programa Prosoft 2.0.

El Digestivo: La Noche de casino Siendo un evento tan esperado, quisimos celebrarlo en grande jugando y apostando, donde los asistentes vivieron una noche divertida, con baile, bocadillos y brindis. Y para los que no les late el casino, jugaron como niños con el Kinect. El ambiente era de total algarabía y esta se agrandó al participar en la subasta de grandes premios.

La preparación y realización del evento fueron una ardua labor, que finalmente gracias a la mezcla de contenidos de alta calidad, entusiastas asistentes, y una logística excepcional, logramos un delicioso menú, consolidando una vez más a SG Conference & Expo como un evento de clase mundial.

El Despertar del

Cómputo Físico

La mayoría de nosotros, los profesionistas de software contemporáneos, llevamos toda nuestra vida profesional programando software cuya interacción con el mundo físico se limita a recibir comandos de un teclado o mouse y entregar resultados desplegándolos en una pantalla. Ciertamente, esta modalidad de cómputo ha generado un mercado muy grande, y nos ha dado empleo, alegrías, tristezas y muchas anécdotas.

Sin embargo, no debemos olvidar que “hay un mundo allá afuera”, un mundo físico con distancia, peso, luz, sonido, tacto.

Y en ese mundo también hay infinidad de oportunidades donde los sistemas de cómputo pueden aportar valor.

El cómputo físico se refiere a la utilización de dispositivos electrónicos para crear objetos interactivos que pueden interactuar con el mundo físico utilizando sensores y accionadores controlados por el comportamiento programado en un microcontrolador.

Anteriormente, crear sistemas de cómputo físico era algo reservado para unos cuantos, no solo por la complejidad y diversidad de conocimientos requeridos, sino por la poca accesibilidad y alto precio de los materiales necesarios, así como la falta de estandarización. Pero en los últimos años esta situación ha mejorado

22

significativamente, y hoy en día contamos con herramientas más sencillas, materiales accesibles, mayor estandarización y mucho mayor apertura. Todo esto ha provocado que el interés y popularidad del cómputo físico esté explotando.

En las siguientes páginas hemos concentrado diversos artículos con información sobre algunos de los aspectos que consideramos más relevantes sobre el cómputo físico, desde el fenómeno provocado por Arduino y el open hardware, hasta la construcción y programación de robots.

Pero antes de continuar, les recordamos un pasaje del libro “The Tao of Programming” the Geoffrey James.

“Sin el viento, el pasto no se mueve. Sin software, el hardware es inútil.”

www.sg.com.mx |

Software Guru

.PRINCIPAL

23

.PRINCIPAL

El ABC de la Programación de un

Robot Humanoide

más fácil de lo que crees

››Por Miguel Ángel Ramírez

Abrir la puerta, jugar futbol, recordarle a una persona que tiene que tomar sus medicinas, leer correos electrónicos o bailar, son algunas de las funciones que los robots humanoides pueden realizar actualmente. Para lograrlo, existe software que permite simular comportamientos en un robot, aplicaciones para programar actividades complejas y herramientas de monitoreo. Esto se hace por medio de los ambientes de desarrollo y Kits de Desarrollo de Software (SDK) de los robots.

La finalidad es tener bien claro qué quieres que tu robot haga, porque no sólo para movimientos está hecho, sino también para sentir, interactuar, e incluso pensar por medio de inteligencia artificial.

Los robots

Existen distintas opciones de robots humanoides en el mercado. Posiblemente el más popular es el robot NAO fabricado por la empresa francesa Aldebaran Robotics, y que es el utilizado en la competencia internacional Robocup, donde equipos de todo el mundo programan equipos de robot autónomos que compiten jugando futbol.

Herramientas y tecnologías de programación

Antes, programar un robot era una tarea complicada. Sin embargo, hoy en día se cuenta con herramientas poderosas y bastante amigables.

Generalmente, la programación de robots se clasifica en varios niveles de complejidad con la finalidad de que los usuarios puedan ir escalando sus conocimientos y cada vez tener un mayor control sobre el comportamiento del robot y realizar actividades más avanzadas.

En el nivel básico está la programación visual utilizando ambientes de desarrollo como Choregraphe. En estas herramientas se cuenta con librerías de bloques de comportamiento predefinidos y se programa visualmente el comportamiento del robot al arrastrar y conectar dichos bloques, creando así una secuencia de actividades o coreografía. La figura 1 muestra una pantalla de Choreographe.

como su nombre lo indica es un lenguaje tipo Basic, pero especializado y orientado a robots. Este lenguaje te proporcionará comandos específicos para controlar al humanoide. Por medio de los simuladores de los ambientes de desarrollo, puedes probar fácilmente los nuevos comportamientos y comprobar que haces correctamente tu trabajo.

Otra posibilidad consiste en crear nueva funcionalidad utilizando información de lo que el robot está viendo y sintiendo por medio de sus sensores. Este tipo de programación típicamente se hace en lenguajes como Python o C++, y aprovecha los SDKs que ofrecen los robots (la gran mayoría de los robots actuales cuenta con SDKs).

Quienes estén acostumbrados a desarrollar aplicaciones con tecnologías de Microsoft tal vez se sientan en casa usando Microsoft Robotics Developer Studio, la cual aprovecha las plataformas .NET y XNA además de soportar el sensor Kinect. Adicionalmente, ya hay quienes están experimentando con programar y controlar robots en tiempo real. Por ejemplo, la Universidad del Norte de Carolina lo está haciendo con éxito, y han logrado que un robot NAO sirva azúcar en una taza de café con una cuchara, incluso sorteando obstáculos inesperados. El campo de la programación de robots humanoides se está desarrollando muchísimo. Tan es así, que la competencia RoboCup tiene como objetivo que para el año 2050 un equipo de robots pueda competir en un juego de futbol contra los campeones de la FIFA. Por otro lado, algunas empresas ya han comenzado a crear app stores para aplicaciones robóticas, de forma que usuarios de todo el mundo puedan descargar los desarrollos de otros.

Robótica humanoide en México

En México también se realiza investigación en el campo de la robótica. Universidades como el ITAM, UNAM, INAOE e ITESM cuenta con humanoides para que los alumnos puedan programarlos. En el caso del ITAM, cuentan con robots NAO desde el 2008 que participaron en RoboCup en la Liga de Plataforma Estándar (esta primera versión se entregó únicamente a 20 instituciones del mundo). Una excelente noticia es que la edición 2012 de RoboCup se llevará a cabo en la ciudad de México en junio del 2012. Esto seguramente impulsará el interés en nuestro país por la robótica.

Referencias:

[1] “Configuración de NAO”. http://www.naomexico.mx/html/config.html [2] Canal de videos de Aldebaran Robotics. http://www.youtube.com/aldebaranrobotics [3] RoboCup. http://www.robocup.org

Figura 1. El ambiente de desarrollo Choreographe

El siguiente paso es poder programar tus propios bloques de comportamiento, para integrarlos en tus coreografías. Esto típicamente se hace un lenguaje de programación de alto nivel. En el caso de Choregraphe, se puede hacer en Python o urbiscript (un lenguaje de scripting para robótica). Otras herramientas utilizan el lenguaje RoboBasic, que 24

.BIO Miguel Ángel Ramírez es Director de Tecnología en GRE, empresa mexicana dedicada a la comercialización de soluciones robóticas.

Miguel es egresado de la Universidad La Salle como Ingeniero en Cibernética. www.naomexico.mx

.PRINCIPAL

Open Hardware el hardware también puede ser libre ››Por Antonio Toriz

Para tener hardware reconfigurable debemos usar algún lenguaje de programación con licencia GPL (General Public License). La licencia GPL, al ser un documento que cede ciertos derechos al usuario, asume la forma de un contrato, por lo que usualmente se la denomina contrato de licencia o acuerdo de licencia. La Organización Europea para la investigación Nuclear (CERN) publicó el 8 de julio de 2011 la versión 1.1 de la Licencia de Hardware Abierto.

Existen programas para diseñar circuitos electrónicos y aprender de la electrónica como EDA (Electronic Design Automation) y GEDA (GPL Electronic Design Automation), son aplicaciones de software libre que permitan poner en práctica las ideas basadas en electrónica.

Es posible realizar el ciclo completo de diseño de hardware re25

configurable desde una máquina con GNU/Linux, realizándose la compilación, simulación, síntesis y descarga en una FPGA. Para la compilación y simulación se puede usar GHDL (http://ghdl.free. fr) junto con GTKWave (http://gtkwave.sourceforge.net), y para la síntesis el entorno ISE de Xilinx. Este último es software comercial pero existe una versión gratuita con algunas restricciones.

Sabemos que tanto en el caso del software como el hardware, libre no es lo mismo que gratis. Específicamente, en el caso del hardware, como estamos hablando de componentes físicos que son fabricados, la adquisición de componentes electrónicos puede ser costosa.

Aun así, es un campo que no solo es apasionante sino que también tiene mucho futuro y representa grandes oportunidades.

Evolución digital

La idea del open hardware no solo es importante en la aplicación del modelo comunitario y colaborativo para el crecimiento intelectual libre sobre los sistemas electrónicos digitales, sino también para impulsar a nuevos talentos y desarrollo tecnológico en México, evitar la fuga de cerebros e incentivar la creación de empresas de hardware para no depender tanto de tecnologías extranjeras.

El principal desafío es lograr que más gente se interese en el Open Hardware para crear grupos de trabajo y pasar del primer problema que es la iniciativa, para posteriormente interesarse por la investigación y fabricación de los componentes. Sabemos que esto no será fácil, pero confío plenamente en que poco a poco podremos lograrlo. .BIO Antonio Toriz Cureño (@ingbruxo) es egresado de la Universidad Autónoma del Estado de México, Campus Valle de Chalco. Actualmente trabaja como profesor de Preparatoria. Sus áreas de especialidad incluyen ingeniería inversa de computadoras, hardware libre y seguridad informática. Lee su blog en http://antoniotoriz.blogspot.com

www.sg.com.mx |

El movimiento de hardware abierto o libre, busca crear una gran librería accesible para todo el mundo, lo que ayudaría a las compañías a reducir en millones de dólares en trabajos de diseño redundantes. Ya que es más fácil tener una lluvia de ideas propuesta por miles o millones de personas, que por solo una compañía propietaria del hardware, tratando así de que la gente interesada entienda cómo funciona un dispositivo electrónico, pueda fabricarlo, programarlo y poner en práctica esas ideas en alianza con las empresas fabricantes, además se reduciría considerablemente la obsolencia programada y en consecuencia evitaríamos tanta basura electrónica que contamina el medio ambiente. Al hablar de open hardware hay que especificar de qué tipo de hardware se está hablando, ya que está clasificado en dos tipos; • Hardware estático. Se refiere al conjunto de elementos materiales de los sistemas electrónicos (tarjetas de circuito impreso, resistencias, capacitores, LEDs, sensores, etcétera).

• Hardware reconfigurable. Es aquél que es descrito mediante un HDL (Hardware Description Language). Se desarrolla de manera similar a como se hace software. Los diseños son archivos de texto que contienen el código fuente.

Software Guru

El término open hardware, u open source hardware, se refiere al hardware cuyo diseño se hace publicamente disponible para que cualquiera pueda estudiarlo, modificarlo y distribuirlo, además de poder producir y vender hardware basado en ese diseño. Tanto el hardware como el software que lo habilita, siguen la filosofía del software libre. Hoy en día, el término “hágalo usted mismo” (DIY por sus siglas en inglés) se está popularizando en el hardware gracias a proyectos como Arduino que es una fuente abierta de prototipos electrónicos, una plataforma basada en hardware flexible y fácil de utilizar que nació en Italia en el año 2005.

.PRINCIPAL

Hola Mundo

Kinect

obteniendo datos de las cámaras de kinect

››Por Hugo Fernández

Como muchos de ustedes saben, Kinect es un accesorio para el Microsoft XBox 360 que consiste en una cámara sensible a la profundidad, lo que le permite identificar lo que ve en un contexto de 3 dimensiones. En principio fue pensado como accesorio para videojuegos, pero sus capacidades permiten que también sea un dispositivo útil para otros fines. De hecho, apenas algunos días después de su lanzamiento, comenzaron a aparecer drivers de Kinect creados por desarrolladores independientes. Reconociendo este potencial, Microsoft liberó posteriormente un SDK oficial.

En este artículo vamos a explicar como utilizar el SDK de Kinect para inicializar y mostrar las diferentes cámaras y funciones de reconocimiento de gestos.

la parte superior de nuestro código donde están los “using” y agregamos Microsoft.Research.Kinect.Nui. using Microsoft.Research.Kinect.Nui;

Prerrequisitos

Para poder realizar este tutorial es necesario contar con lo siguiente: • Sensor Microsoft Kinect.

• Cable conversor de puerto KINECT a USB (este cable esta incluido cuando compras el KINECT por separado, para la versión que viene con el Xbox 360 no viene con esta extensión, pero se puede conseguir fácilmente en tiendas de electrónicos).

• Computadora con Microsoft Windows 7 (en sus diferentes versiones) compatible con tarjetas gráficas con Direct X 9.0c • Microsoft Visual Studio 2010 Express o cualquier edición • Microsoft .NET Framework 4.

Adicionalmente necesitamos instalar el Kinect SDK, el cual se puede descargar en http://swgu.ru/r3401

Comencemos

Para poder manejar el dispositivo, haremos referencia a este desde una variable de tipo Runtime. Así que debemos declarar dicha variable.

Runtime runtime = new Runtime();

A continuación registramos métodos para manejar los eventos Loaded y Unloaded del control MainWindow, y también registramos métodos para manejar la señal de las dos cámaras de Kinect: la de video y la de profundidad. El listado 1 muestra esto.

public MainWindow() { InitializeComponent();

Lo primero que hacemos es crear un nuevo proyecto en Visual Studio, el tipo de proyecto que necesitamos es “Aplicación WPF”, nombraremos este proyecto “HelloWorldKinect”.

Posteriormente, en la vista de diseño nos situamos en el código XAML y colocamos dos controles de tipo imagen. El primer control, de preferencia que abarque toda la ventana, lo llamaremos depthImagen y lo utilizaremos para la cámara de profundidad. El segundo control, que llamaremos videoImage, mostrará el contenido de la cámara de video. Éste último podemos hacerlo más pequeño y será más pequeño y lo posicionaremos en la esquina superior derecha.

this.Loaded += new RoutedEventHandler(MainWindow_Loaded); this.Unloaded += new RoutedEventHandler(MainWindow_Unloaded); runtime.VideoFrameReady += new EventHandler <Microsoft.Research.Kinect.Nui.ImageFrameReadyEventArgs> (runtime_VideoFrameReady); runtime.DepthFrameReady += new EventHandler <ImageFrameReadyEventArgs>(runtime_DepthFrameReady); }

Para poder utilizar las librerías de Kinect en nuestro proyecto debemos agregar la referencia correspondiente. Para ello, en la pestaña del Explorador de Soluciones hacemos click derecho en la carpeta References, seleccionamos Add Reference y seleccionamos la referencia Microsoft.Research.Kinect.

El código

Para agregar la referencia desde el código de nuestro formulario, vamos a 26

Listado 1.

En el método MainWindow_Loaded que es la que llamamos cuando se carga el dispositivo, vamos a inicializar el dispositivo y llamar dos rutinas, una para el stream de video (cámara RGB) y otra para el stream de profundidad. El listado 2 muestra esto.

.PRINCIPAL

void MainWindow_Loaded(object sender, RoutedEventArgs e) { runtime.Initialize(Microsoft.Research.Kinect.Nui.RuntimeOptions.UseColor | Microsoft.Research.Kinect.Nui.RuntimeOptions.UseDepth); runtime.VideoStream.Open(ImageStreamType.Video, 2, ImageResolution.Resolution640x480, ImageType.Color);

PlanarImage image = e.ImageFrame.Image; BitmapSource source = BitmapSource.Create(image.Width, image.Height, 96, 96, PixelFormats.Bgr32, null, image.Bits, image.Width * image.BytesPerPixel); videoImage.Source = source; }

runtime.DepthStream.Open(ImageStreamType.Depth, 2, ImageResolution.Resolution640x480, ImageType.Depth);

void runtime_DepthFrameReady(object sender, ImageFrameReadyEventArgs e) {

} Listado 2.

PlanarImage image = e.ImageFrame.Image;

En el método para manejar el evento unloaded, simplemente nos limitamos a cerrar el dispositivo.

void MainWindow_Unloaded(object sender, RoutedEventArgs e) {

BitmapSource source = BitmapSource.Create(image.Width, image.Height, 96, 96, PixelFormats.Gray16, null, image.Bits, image.Width * image.BytesPerPixel);

runtime.Uninitialize();

depthImage.Source = source;

Listado 4. Métodos VideoFrameReady y DepthFrameReady.

Listado 3. Código para cerrar el dispositivo.

Como último código vamos definir los métodos VideoFrameReady y DepthFrameReady que manejan la recepción del video y la profundidad respectivamente. El contenido de ambos métodos es muy similar, con muy ligeras variaciones.

Comenzamos creando una variable de tipo PlanarImage y asignándole el valor del atributo ImageFrame.Image de nuestro argumento, el cual siempre tiene la imagen que está tomando la cámara en ese momento.

Después definimos una variable de tipo BitmapSource cuyo valor es construido a partir del stream correspondiente, pasándole como parámetros, el ancho, el alto, los DPI de cada imagen (por defecto son 96), el formato de sus pixeles en lo que la diferencia de que una es RGB o BGR32 para el video y para profundidad daré una paleta de colores gris de 16 bits o Gray16, luego los bits en memoria a partir de la variable image. Por último, en cada método se asigna el BitmapSource que definimos, como valor del atributo del control de imágen que definimos en un inicio, videoImage para el control de video y depthImage para el control de profundidad.

Nuestro código está listo, ahora solo corremos la aplicación presionando F5 y podremos ver en nuestra pantalla la señal capturada por el Kinect.

No se incluye aquí el screenshot de la imagen generada por el sensor de profundidad porque son tonalidades muy obscuras que no se distinguen en la revista impresa, pero te invito a que lo intentes, es algo bastante sencillo.

El código utilizado en este artículo está disponible en http://swgu.ru/ sg3400 Este código prácticamente es el mínimo esencial preestablecido por Microsoft para comenzar a trabajar con el Kinect.

La versión original de este artículo se encuentra publicada en http://swgu.ru/ sg3403 Fue editada y publicada en Software Guru con permiso del autor.

Referencias: [1] “Kinect for Windows SDK”. http://swgu.ru/sg3402 [2] “The Kinnect Effect”. http://swgu.ru/sg3404

.BIO Hugo Fernández es cofundador y director de CIACOM Systems en Venezuela. Es Microsoft Certified Technology Specialist y se especializa en el desarrollo de aplicaciones web. @hughfernandez

void runtime_VideoFrameReady(object sender, Microsoft.Research.Kinect.Nui.ImageFrameReadyEventArgs e) {

27

www.sg.com.mx |

}

Software Guru

}

.PRINCIPAL

Diseño de un Robot Compatible con

RDS

conoce a

››Por Pedro Galván

MARK

Microsoft Robotics Developer Studio (RDS) es una plataforma para el desarrollo de aplicaciones robóticas. RDS provee un framework de programación, ambiente de ejecución (runtime), herramientas para creación y simulación de aplicaciones, ejemplos de código, plantillas y tutoriales entre otras cosas. En este artículo veremos los aspectos fundamentales de un robot diseñado para operar aplicaciones creadas con RDS. Las personas que desean construir aplicaciones robóticas se encuentran con que existe una gran variedad de robots disponibles en el mercado, con poca estandarización entre ellos y gran variedad en capacidades y precios. Ante esta problemática, el equipo de Microsoft Robotics se dio a la tarea de definir las características esenciales de un robot que aproveche los servicios de RDS. El objetivo es que las personas puedan facilmente construir su propio robot, o que terceros construyan y vendan robots “listos para usarse”, de manera que los desarrolladores pueden concentrarse más en construir las aplicaciones del robot, que en construir el robot en sí. El resultado de este esfuerzo es la “RDS Reference Platform”. Esta plataforma de referencia es una guía que describe el diseño recomendado para crear un robot “real” (es decir, un robot físico) que pueda operarse con RDS.

Arquitectura de hardware.

La figura 1 muestra el ejemplo de una implementación de un robot MARK.

MARK

El diseño robótico de referencia utiliza al sensor Microsoft Kinect, el cual provee una cámara de video, sensor de profundidad 3D y micrófono. Este diseño fue bautizado como MARK (Mobile Autonomous Robot using Kinect). El diseño del MARK se basa en cuatro principios: mobilidad, autonomía, interactividad y extensibilidad.

La mobilidad es provista por una tracción diferencial, la cual es fácil de controlar y permite que el robot gire en su mismo lugar.

Para ser autónomo, el robot recurre a una computadora a bordo. Las capacidades avanzadas como visión computarizada, reconocimiento de voz, o conectividad a redes, requieren capacidad de procesamiento mucho mayor a la que proveen los microcontroladores de bajo rango. Incorporar una PC en el diseño también permite comunicación inalámbrica con otras PCS y/o robots por medio de WiFi. La interactividad considera dos aspectos: la interacción humano-robot, y la interacción del robot con el ambiente. El campo de la robótica personal tiene la necesidad de interfaces de usuario sencillas y confiables. La interactividad es facilitada por la inclusión del sensor Kinect, lo cual puede simplificar dramáticamente la programación de la interfaz de usuario, proporcionando datos 3D e información esqueletal. Los datos 3D también son muy útiles para que el robot pueda desplazarse exitosamente a través de obstáculos.

La extensibilidad es inherente al diseño de referencia ya que no especifica detalles de bajo nivel, por lo que no está restringido a una construcción en particular. Este permite que los usuarios y partners de Microsoft Robotics puedan cambiar piezas o variar el diseño siempre y cuando se respeten los aspectos fundamentales.

28

Figura 1. Ejemplo de implementación de un robot MARK.

A continuación se describe de forma general el hardware de este robot.

Bases. Se requiere un mínimo de dos bases o plataformas en el robot. En la base inferior va el sistema de tracción y en la superior va la computadora y el Kinect. La base de mayor tamaño (típicamente la inferior) debe ser circular y ningún componente debe rebasar su circunferencia, esto permitirá que el robot pueda girar en su lugar sin golpear objetos externos. Se recomienda que las bases tengan un diámetro menor a 60 cm para que puedan pasar por las puertas de una casa. La base superior debe tener un soporte para montar la cámara del Kinect. Para maximizar el campo de visión del Kinect, la altura ideal a la que se debe montar es a 60 centímetros del suelo.

Sistema de tracción. La tracción diferencial consiste en dos ruedas cuya velocidad puede variar de manera independiente. Los motores típicamente se controlan utilizando circuitos de tipo puente H (H-brid-

.PRINCIPAL ge). El sistema de tracción considera: las ruedas, el eje de las ruedas, los motores que las mueven, los sensores de rotación de las ruedas (wheel encoder), los puentes H, y los accesorios de montaje. Se recomienda utilizar motores silenciosos, no solo para evitar la molestia del ruido, sino también porque afecta la capacidad de reconocimiento de voz. Dado que la tracción diferencial consiste de solamente dos ruedas, para que el robot tenga estabilidad se recomienda agregar ruedas (una al frente y otra atrás) para que den estabilidad. Estas ruedas deben ser giratorias para no obstruir el desplazamiento y rotación del robot.

En la capa superior tenemos servicios de alto nivel que pueden ser provistos por RDS, terceros, o creados por el desarrollador.

Un servicio en esta capa que ya está incluido como parte del RDS es el Robot Dashboard, un aplicativo que funciona como consola maestra para permitir al usuario controlar al robot y consultar su estatus. Otro servicio de esta capa que ya es provisto por RDS es el de evasión de obstáculos.

Los servicios de bajo nivel son una capa de abstracción de hardware. Proveen servicios para interactuar con el hardware (Kinect, sistema de tracción, sensores) mediante el controlador de I/O. Los servicios de esta capa son programados por el fabricante del robot, o el usuario en caso de estar construyendo su propio robot.

El CCR (Concurrency and Coordination Runtime) y DSS (Decentralized Software Services) son componentes de RDS. Todos los servicios se ejecutan en el contexto de un nodo DSS, y varios nodos DSS se pueden comunicar entre sí a través de una red.

RDS está basado en .NET, el cual a su vez opera sobre el sistema operativo Windows.

En la capa más baja está el hardware. Algunos dispositivos, como el control de Xbox están directamente soportados por drivers para Windows. El controlador de I/O contiene firmware que se comunica via Windows utilizando un puerto serial, USB, red u otro medio.

Para crear aplicaciones robóticas que funcionen con RDS se requiere una computadora con el siguiente software: Windows 7 (32bit o 64-bit), Visual Studio 2010 Express o superior, Kinect for Windows SDK (y prerrequisitos asociados), Robotics Developer Studio 4 (y prerrequisitos asociados).

Sensores de proximidad. A pesar de que podríamos utilizar el sensor de profundidad del Kinect para detectar obstáculos y evadirlos, se recomienda tener sensores de proximidad dedicados para la evasión de obstáculos. Se debe incluir al menos dos tipos distintos de sensores, ya que combinar distintos tipos incrementa la probabilidad de detectar obstáculos. Por ejemplo los sensores infrarrojos no detectan vidrio pero los de sonar sí, asímismo hay objetos que no son bien detectados por los de sonar pero sí por los infrarrojos.

Controlador de I/O. El controlador de I/O, conocido como brick (ladrillo) es una tarjeta de circuitos que actúa como interfaz entre el hardware del robot y la PC. Sistema de energía. La energía para el robot debe ser provista por una o más baterías recargables. Se recomienda utilizar baterías de 12V tipo SLA (Sealed Lead Acid). Los componentes del robot que requieren energía incluyen: Kinect (12V a 1.1A), motores y controladores, sensores de proximidad, controlador IO. Por simplicidad, la computadora a bordo puede utilizarse con su batería por lo que no es necesario contemplarla en la lista de componentes soportados por el sistema de energía.

Hemos visto algunos aspectos fundamentales para el diseño de un robot con RDS. Te invito a que consultes la especificación completa [2] y que comiences a desarrollar aplicaciones robóticas. Te comento que RDS incluye una versión simulada de esta plataforma de referencia, de modo que puedes comenzar a desarrollar aplicaciones robóticas en un ambiente simulado sin necesidad de contar con el robot físico. La figura 3 muestra este ambiente de simulación.

Arquitectura de software

www.sg.com.mx |

La figura 2 ilustra a grandes rasgos la arquitectura de software de la plataforma de referencia del RDS.

Software Guru

Conclusión

Figura 3. Ambiente de simulación de RDS.

Referencias: [1] Microsoft Robotics. http://www.microsoft.com/robotics

Figura 2. Arquitectura de software de la plataforma de referencia.

[2] “RDS: Reference Platform Design Specification”. http://swgu.ru/sg3409

29

.PRINCIPAL

Conociendo a

Arduino

hola mundo con

››Por Pedro Galván

LEDs

Arduino es una plataforma abierta para cómputo físico que se basa en hardware y software sencillo y libre. Los sistemas Arduino pueden sondear el ambiente al recibir información de una gran variedad de sensores, y pueden afectar al ambiente al controlar luces, motores u otros actores.

En este artículo veremos como se hace un “Hola Mundo” en Arduino.

El hardware

Dado que Arduino es open hardware, tú mismo puedes construir tarjetas guiándote en los esquemas de diseño, o puedes comprar tarjetas preconstruidas. Para este ejercicio nos basaremos en una tarjeta Arduino Uno, que es la más básica y se puede adquirir por alrededor de 40 dólares. La figura 1 muestra una imagen.

Nota: La pata larga es el ánodo, el cual va al pin, y la pata corta es el cátodo que va a tierra.

El listado 1 muestra el código que necesitamos.

const int LED = 13; void setup() { pinMode(LED, OUTPUT); } void loop() { digitalWrite(LED, HIGH); delay(1000); digitalWrite(LED, LOW); delay(1000); } Listado 1. Código para prender y apagar LED

Figura 1. Una tarjeta Arduino Uno

El software

Las tarjetas Arduino se programan en un ambiente de desarrollo (IDE) basado en el lenguaje Processing, que es un lenguaje bastante sencillo. Ya que tienes tu programa listo, el IDE lo convierte a C, compila un binario y lo carga al microprocesador. El ciclo de programación es básicamente el siguiente: 1. Conecta la tarjeta a tu computadora via USB 2. Escribe el programa en el IDE. 3. Envía el programa a la tarjeta y espera a que se reinicie.

4. La tarjeta ejecuta el programa.

El código es bastante sencillo. Primero definimos una constante para indicar el número de pin donde tenemos el LED. Luego tenemos el método obligatorio setup() que es donde hacemos las configuraciones necesarias para ejecutar un programa. En nuestro caso, estamos indicando que queremos usar el pin 13 como salida (los pines digitales pueden usarse ya sea como entrada o salida).

Posteriormente tenemos el método obligatorio loop() el cual ejecuta el ciclo maestro del programa. En nuestro ciclo lo que estamos haciendo es prender el voltaje del LED al enviarle una señal HIGH, esperar mil milisegundos, bajar el voltaje del LED al enviar una señal LOW, y esperar. Este ciclo se ejecutará de forma continua mientras el sistema se encuentre encendido.

Como has podido constatar, Arduino es muy sencillo. Te recomiendo que le hagas caso a ese gusanito curioso dentro de ti y consigas cuanto antes una tarjeta y empieces a jugar.

El código

Nuestro hola mundo consistirá en hacer que un LED (diodo de luz) se prenda y apague. Para ello, conectamos nuestra tarjeta a la computadora, y conectamos un LED en el pin digital #13.

30

Referencias: [1] Arduino Homepage. http://www.arduino.cc [2] M. Banzi. “Getting Started with Arduino”, 2nd edition. Make Books, 2011.

.COLUMNA Columna Invitada

Cómputo en la

Nube

retrospectiva desde el

H

Mark Settle es CIO en BMC Software, y anteriormente fue CIO en cuatro compañías de la lista de las Fortune 300: Corporate Express, Arrow Electronics, Visa International, y Occidental Petroleum.

oy que estoy en el año 2015 y miro hacia atrás, me pregunto como es que yo —al igual que la mayoría de los CIOs— vivimos durante tantos años bajo la falsa noción de que el hardware era barato. En ese entonces permitíamos que la mayoría de las aplicaciones corrieran sobre hardware dedicado. Adicionalmente, acostumbrábamos comprar hardware con capacidad de sobra, para disminuir el riesgo de problemas de desempeño. Para ser francos, tampoco hacíamos planeación de la capacidad, porque no queríamos conocer la respuesta.

Cuando los proveedores de nubes públicas comenzaron a ofrecer infraestructura de TI bajo demanda en un esquema de “paga lo que usas”, todos despertamos y nos dimos cuenta de que estas opciones desplazarían nuestros centros de datos internos. Fue así que comenzamos a actuar como proveedores de cómputo en la nube dentro de nuestra propia organización, estableciendo las llamadas nubes privadas. Metimos en cintura a nuestros clientes y les dijimos que solo soportaríamos determinadas arquitecturas y middleware. Convencimos a nuestros CFOs de que si nos permitían hacer grandes adquisiciones de infraestructura anticipando demanda futura, y de esta forma eliminar las compras incrementales, podríamos lograr mayores tasas de retorno sobre el hardware. Para que esta política fuera aceptada, aceptamos comenzar a medir y reportar el nivel de utilización del hardware. Y llego entonces el día en que tuvimos que rendir cuentas ante los CFOs, admitiendo que todo el hardware que nos habían permitido comprar en los últimos años, estaba sentado en el data center con utilizaciones menores al 50%.

Es increible cuantas excusas pusimos en ese entonces sobre la seguridad en nubes públicas. Ahora, continuamente seleccionamos a proveedores de nube pública para manejar tipos específicos de cargas de trabajo. Definimos los requerimientos de seguridad de cada carga y utilizamos las técnicas apropiadas de encripción y aliasing para asegurar la confidencialidad de los datos enviados a proveedores externos.

Aunque algunos tipos de información son muy sensibles y no pueden salir de nuestro data center, esta decisión ya se toma por un proceso automatizado. Ya no tenemos debates filosóficos sobre que sí puede o no pasar por el firewall.

Hace diez años, el simple hecho de aprovisionar un servidor podía tomar de 3 a 6 semanas de juntas, emails, evaluaciones de hardware y negociaciones de precio. En el 2010, gracias a la utilización de configuraciones estándar y scripts de automatización en ambientes virtualizados, esta tarea se redujo a medio día. Hoy, podemos hacerlo en minutos. Esto no solo nos ahorra costo de staff, sino que 32

2015

sustenta la agilidad que requiere el negocio.

Qué bueno que en el 2011 tomamos la decisión de comenzar a adoptar agresivamente el cómputo en la nube. De no haberlo hecho no hubieramos tenido la flexibilidad y recursos requeridos para soportar la explosión que han tenido las aplicaciones móviles en los últimos años.

Antes, si en un año lograbamos poner en producción 2 o 3 aplicaciones de negocio importantes, además de sostener los sistemas legados, era todo un logro. Para nuestros clientes internos, que nos comparaban con las app stores de Apple y Android donde tenían miles de aplicaciones nuevas cada trimestre, eramos demasiado lentos. Entre el 2005 y el 2010 aumentamos significativamente el uso de versiones SaaS de varias de nuestras aplicaciones y servicios de comunicación. Los usuarios estaban fascinados por la rápida introducción de nueva funcionalidad provista por los proveedores Saas, mientras que nosotros notamos que el costo era menor en comparación de mantener sistemas legados internos. A través de los últimos años, nosotros mismos nos hemos convertido en proveedores SaaS para la empresa. La mayoría de las aplicaciones que ofrecemos en realidad solo son “mash-ups” que combinan servicios de negocio granulares. La mayoría de nuestros usuarios no sabe si un servicio está siendo provisto por un ERP, el sistema de comercio electrónico o una fuente de datos externa. Simplemente se suscriben a los servicios que necesitan para hacer su trabajo.

Otro de los grandes beneficios del cómputo en la nube en nuestra organización es que liberó mucho del tiempo que usabamos para administrar la infraestructura. Hemos redireccionado ese tiempo a administrar la información y alimentarla a nuestras aplicaciones, lo cual ha tenido un gran impacto en el negocio.

Vivimos en un mundo radicalmente diferente al que existía en el 2010. Ya no dedicamos el 60% de nuestro presupuesto a simplemente mantener funcionando los sistemas legados. Ahora dedicamos ese mismo porcentaje a entregar nuevos servicios aplicativos y “datos limpios” a nuestros usuarios. El staff está mucho más contento ya que están conscientes de que generan valor real para el negocio.

También estamos mucho más cerca de ese estado mítico de “alineación de TI y negocio”.

Este artículo fue originalmente publicado en Cloudbook.net y se encuentra disponible en http://swgu. ru/sg3410. Esta versión fue traducida y editada por SG con el permiso del autor.

››Por Mark Settle

.PRÁCTICAS Usabilidad

La Navegación y los Esquemas de Organización de la Información ›› Por Pamela Rodríguez

L

encuentre lo que busca con el menor esfuerzo posible. Este método de organización es el de flujo conversacional que se asegura de que la información se presente respondiendo a tiempo las preguntas que el usuario puede ir generando a través de su experiencia.

El sitio de Mint.com lleva a cabo esta clasificación de manera muy efectiva. Al entrar al sitio, la primera opción del menú responde a una pregunta que cualquier lector que no haya escuchado hablar de Mint antes debe estar haciéndose en este momento, y está etiquetada como tal: ¿Qué es Mint? Una vez que ya se conoce esto, la siguiente interrogante es ¿Cómo funciona?, la cual corresponde a la segunda opción del menú.

Existen otras maneras de clasificar la información cuando se manejan grandes volúmenes de la misma, las cuales resultan más objetivas. El esquema alfabético, por ejemplo, debe ser utilizado con cuidado pues no siempre resulta efectivo. Funciona cuando, por ejemplo, se presenta un listado de autores de novelas mas no funciona para un listado de países de nacionalidad de un usuario, puesto que un estudio de mercado podría arrojar que el mayor porcentaje de usuarios es proveniente de México y por ello poner este país al principio resultaría más congruente. Otro ejemplo de organización objetiva es el esquema cronológico, utilizado comúnmente para archivar los artículos de un blog, presentados por orden de publicación del más reciente al más antiguo.

a definición de una arquitectura de información sólida es quizá el paso más importante a realizar en cualquier proyecto. Una vez que ha sido establecida, es momento de pasar a otros aspectos estructurales como lo son la navegación y la organización de la información, dos factores muy importantes de los cuales dependerá el que la arquitectura previamente definida sea asimilada por el usuario.

La arquitectura establecida ya define las principales rutas de navegación que se manejarán, mas no define la manera en la que estas serán presentadas para el usuario. También es importante mantener en mente que no existe una única manera de llegar a un destino dentro del proyecto, sobre todo si su contenido es de alta relevancia.

Organización del contenido

Antes de comenzar a pensar en los tipos de navegación y en las presentaciones de los mismos, es necesario establecer los esquemas para organizar el contenido que, aunque puede no estar completado en su totalidad, ya fue definido de manera general en la arquitectura de información.

El mayor seccionamiento de la información se lleva a cabo por medio de esquemas de navegación subjetivos, los cuales dependen de la índole del proyecto. Uno de estos esquemas comprende una organización por temas o categorías definidos con base en características o clasificaciones en común del contenido. Un ejemplo claro de este esquema es prácticamente cualquier sitio web de comercio electrónico asociado a una tienda departamental. La amplia gama de productos es clasificada por categorías (libros, discos, ropa, accesorios, entre otros).

Otra manera de organizar contenido es por tareas, es decir, actividades posibles a realizar por el usuario dentro del sistema. Google Docs, la aplicación web de manejo de documentos auspiciada por Google, tiene un menú de opciones dividiendo la creación de los diferentes tipos de documentos existentes (crear hoja de estilo, crear documento de texto, entre otros).

Sin embargo, y aunque los métodos anteriores son de gran utilidad, también es importante tener en cuenta que la presentación de la información (sobre todo en web, donde la atención del usuario es limitada) debe seguir un flujo común al usuario, de modo que este

Los distintos tipos de navegación

Trabajando en conjunto con los esquemas de organización de la información, existen distintas maneras de manejar la navegación dentro de un proyecto de desarrollo, considerando la relevancia de los destinos comprendidos por cada sistema de navegación a utilizar.

En primera instancia está el sistema global de navegación, el cual no solo es el más relevante si no también el más sencillo de comprender. Esta navegación incluye las ligas que estarán presentes en todas las páginas o pantallas dentro de nuestro proyecto. Por esta razón se encuentra siempre claramente separado del resto del contenido, formando parte de la plantilla general del diseño de las pantallas.

Adicionalmente está el sistema de navegación local, el cual también suele formar parte de la plantilla de diseño (es decir, visualmen34

“A veces los sistemas de navegación son como los armarios. Hay cosas colgando dentro que no nos sirven y nunca encontramos lo que estamos buscando.”

te separado del contenido cambiante de la página o pantalla), pero las ligas que lo conforman varían dependiendo de la sección. Ilustrando este punto, las opciones locales dentro de la sección de ¿Quiénes Somos? dentro de un sitio web (Historia, Visión, Misión, entre otras similares) no serán las mismas que aquellas de la sección de ¿Qué Hacemos? (Proceso, Metodología, Herramientas, entre otras).

Es importante definir qué secciones necesitarán manejar navegación local por su complejidad o robustez y qué ligas comprenderá esta navegación en cada una de ellas.

Otro sistema de navegación de apoyo es el sistema de navegación de cortesía, cuya representación es fácil de localizar dentro de los sitios web existentes en la actualidad. Se trata del conjunto de ligas que aparece en la parte inferior de todas las pantallas, comúnmente fijo en todo el sitio al igual que la navegación global. Comprende ligas a información adicional o ‘de cortesía’ como lo son los términos y condiciones de uso, contacto de la empresa, avisos legales, etcétera.

Por otra parte, todas las ligas dentro del resto del contenido (entre los párrafos, botones, etc.) forman parte del sistema de navegación contextual. Y existen también los sistemas de navegación adicionales, que proveen alternativas organizacionales del contenido de un proyecto. Estos son los mapas de sitio, los glosarios y los índices de conceptos, dependiendo del tipo de contenido que se esté manejando.

Posteriormente, al avanzar más en el proceso de diseño de una interfaz, la navegación traerá a la mesa consideraciones que involucrarán principalmente la correcta aplicación de la primera heurística de Nielsen que tiene que ver con la visibilidad de estado del sistema: en todo momento, el usuario debe tener muy claro qué camino fue el que siguió para llegar hasta donde se encuentra y saber exactamente dónde se encuentra.

Resumiendo

Existen muchos argumentos que ayudarían a resumir la importancia real de tener un buen diseño de navegación, pero quizá uno de los más efectivos se resume en una actualización reciente de Twitter del consultor estadounidense Jared M. Spool: “A veces los sistemas de navegación son como los armarios. Hay cosas colgando dentro que no nos sirven y nunca encontramos lo que estamos buscando.”

Lo principal de trabajar a conciencia en el diseño de la navegación de un proyecto es, precisamente, hacer todo lo posible por no terminar diseñando un armario convencional. .BIO Pamela Rodríguez es egresada de la Universidad de Monterrey de la carrera de Ingeniería en sistemas computacionales con estudios avanzados en diseño web. Actualmente es Diseñadora de interfaces para aplicaciones móviles en Naranya Apphouse, docente, conferencista y autora de artículos relacionados. @thepam http://thepam.blogspot.com

.PRÁCTICAS Prueba de Software

Un Buen Inicio para las

Pruebas de Seguridad

uso de nslookup para extracción de información inicial del

E

l rápido crecimiento que en años recientes ha tenido el uso de las aplicaciones web, ha traído como consecuencia que cada vez más información de vital importancia sea almacenada y procesada por dichos sistemas. Las transacciones a través de Internet que hoy en día se realizan dentro de estas aplicaciones pueden incluir desde información personal, datos laborales, números de tarjetas de crédito hasta información empresarial o gubernamental de carácter confidencial. En este contexto, la realización de pruebas seguridad a estas aplicaciones adquiere una gran relevancia, ya que nos ayudan a identificar vulnerabilidades en las mismas y que en un momento dado pudieran permitir la explotación de información de manera malintencionada, como por ejemplo SQL Injection, Crosssite Scripting –XSS-, Directory Traversal, software con versiones no actualizadas, desbordamientos de búfer, ataque de denegación de servicio, páginas con información técnica sensible/datos sensibles sin cifrar, etc. Si no se atienden dichas vulnerabilidades pueden derivar en accesos no autorizados, filtraciones no deseadas de datos confidenciales o incluso pérdida en la integridad de los mismos, entre otras implicaciones mayores.

Una de las actividades que se recomienda llevar a cabo en primera instancia cuando nos es asignado un proyecto de Pruebas de Seguridad, es recabar la mayor cantidad de información posible sobre los .BIO objetivos con que estaremos trabaSandra Berenice Ruiz Eguino es Directora de Operaciones de jando. Esta recopilación inicial nos e-Quallity, además ha participado como Consultora Senior en proyecayuda a tener datos más concisos sotos de mejora de organizaciones bre el SUT (System Under Test) con de Prueba de Software. Cuenta con certificación internacional en Prueel cual interactuaremos. En otras pabas por el ASTQB. Se ha desempeñado también como Ingeniero de labras, entre más información tenPruebas Senior, Líder de Proyectos, gamos sobre el sistema o aplicación Administradora de Proyectos nacionales e internacionales, analista que estaremos probando, mejor será y desarrolladora. Ha sido profesora de la Universidad Autónoma de la estrategia que definamos para Guadalajara (UAG), donde realizó sus estudios de Maestría en Ciendiseñar y ejecutar nuestras Pruebas cias Computacionales. de Seguridad. Como resultado de lo anterior, se incrementarán susMiguel Ángel Cortés Dueñas es tancialmente las probabilidades de Líder Técnico de Proyectos de encontrar un mayor número de vulPruebas y Consultor Especialista en Pruebas de Seguridad en enerabilidades en el SUT. La era de Quallity. Cuenta con certificación internacional en Pruebas por el Internet en la que actualmente viviASTQB, así como certificación CEH (Certified Ethical Hacker) por el EC mos nos otorga la facilidad de obteCouncil. En su trayectoria profesioner pequeños trozos de información nal ha participado también en proyectos nacionales y en el extranjero sobre casi cualquier cosa, desde difecomo Ingeniero de Pruebas Senior, realizando pruebas funcionales rentes y muchas veces insospechadas manuales y automatizadas. fuentes. Es posible que en un principio, dichos trozos de información

SUT

››Por Sandra Berenice Ruiz Eguino y Miguel Ángel Cortés Dueñas

carezcan de sentido pero, al igual que en un rompecabezas, conforme se van juntando pueden ir adquiriendo relevancia como un todo.

Por ejemplo, una muy buena herramienta con la que podemos iniciar recabando información sobre el sistema objetivo, es “Nslookup” (Name Server Lookup), técnicamente es una herramienta administrativa que permite diagnosticar y solucionar problemas que se pueden presentar con los servidores DNS. Es por lo anterior, que “nslookup” puede ser una muy buena fuente de información inicial sobre un objetivo ya que, como veremos a continuación, nos permite resolver nombres de host o dominios a direcciones IP y viceversa, pero además nos ayuda a identificar otros elementos importantes dentro de una red como lo son servidores de correo, servidores de nombres de dominio, etc. En los entornos Windows, Unix y Linux, “nslookup” normalmente se encuentra disponible a través de la línea de comando, ya que se instala por defecto junto con la pila de protocolos TCP / IP. Esto nos facilita un poco más las cosas, ya que no es necesario realizar la descarga e instalación de ningún software adicional al que ya tenemos instalado en nuestra computadora.

Cuando lo usamos sin ningún parámetro, “nslookup” nos devuelve en primera instancia tanto el nombre como la dirección IP del servidor DNS al que nos encontramos conectados localmente.

Después de que nos muestra dicha información, se despliega en pantalla el “prompt” del programa, representado por el signo de “mayor que (>)”. Cuando este “prompt” aparece, nos indica que estamos en el modo de ejecución interactivo de “nslookup”.

Si deseáramos trabajar con el modo no interactivo, bastaría solamente con utilizar el comando acompañado de los parámetros correspondientes, por ejemplo: “nslookup [- opciones] [nombre_de_ host] [nombre_de_servidor]”. Esto, sólo nos regresaría la respuesta a dicha solicitud. Sin embargo, para mayor comodidad y conveniencia, normalmente se usa el modo interactivo.

Una vez que estamos en el modo interactivo, podemos simplemente teclear después del “prompt”, el nombre del host o dominio sobre el cual queremos solicitar información. Por ejemplo, www.dominiodeprueba.com, como se muestra a continuación: > www.dominiodeprueba.com Servidor: UnKnown Address: 192.168.1.254 Respuesta no autoritativa: Nombre: www.l.dominiodeprueba.com Addresses: 192.168.1.99, 192.168.1.104, 192.168.1.103, 192.168.1.147, 192.168.1.106, 192.168.1.105 Aliases: www.dominiodeprueba.com

36

.PRÁCTICAS

Prueba de Software

Como podemos ver, “nslookup” nos devuelve las distintas direcciones IP asociadas al host o dominio capturado, en este caso www. dominiodeprueba.com. En otras palabras, se realiza una sencilla resolución de nombre a dirección IP. De esta manera, contando solamente con la URL del sistema, podemos resolver su IP o rango de direcciones.

De manera inversa, si al comando “nslookup” lo acompañamos con una dirección IP en lugar del nombre del host o un dominio, nos devolverá como resultado el nombre del host o dominio asociado a la dirección IP ingresada.

Ahora bien, en el resultado obtenido, el servidor DNS local (192.168.1.254) es el servidor que por defecto nos está respondiendo nuestras solicitudes. Esto debido a que no hemos realizado ninguna modificación a la configuración inicial del programa. Sin embargo, esto puede ser modificado de manera muy sencilla utilizando el comando “server” como lo muestra el siguiente extracto en el cual asignamos como nuevo servidor DNS, al ubicado en la dirección 192.168.100.1 para que sea él quien ahora atienda nuestras solicitudes de información:

Adicional a los registros de recursos DNS con valor “MX” existen más valores que pueden ser asignados con los comandos “set type” que nos permiten obtener información específica sobre otros elementos tal y como lo muestra la siguiente tabla: Valor Modo de Uso Descripción

A >set type=A Obtiene Información de un host de la red.

Es el modo de búsqueda que viene predeterminado en “nslookup”.

ANY >set type=ANY Especifica que se regresan resultados de todos los tipos de datos, no de uno en particular.

CNAME >set type=CNAME Permite obtener información relacionada con los nombres canónicos de un alias.

MX >set type=MX Como se explicó arriba, permite obtener

> server 192.168.100.1 Servidor predeterminado: dns-publico-prueba.com Address: 192.168.100.1

información relacionada con él o los servidores de correo de un dominio.

NS >set type=NS Especifica que se regresen resultados sobre

>set type=MX Las búsquedas que se lleven a cabo después de que se estableció el valor “MX”, retornarán solamente los servidores de correo (si es que existen) que se localicen en el dominio ingresado. Por ejemplo, la siguiente combinación de comandos, devolverá los servidores de correo que existan dentro del dominio “dominiodeprueba.com” como se muestra a continuación: >set type=MX >dominiodeprueba.com dominiodeprueba.com MX preference m1.mx.dominiodeprueba.com dominiodeprueba.com MX preference m2.mx.dominiodeprueba.com dominiodeprueba.com MX preference m3.mx.dominiodeprueba.com dominiodeprueba.com MX preference mx.dominiodeprueba.com

= 20, mail exchanger = = 30, mail exchanger = = 40, mail exchanger =

al dominio seleccionado.

SOA >set type=SOA Especifica que se obtengan resultados relacionados con el campo “SOA” (Start of Authority) de un dominio.

Una vez obtenida la información anterior, estaremos en posibilidades de definir con mayor claridad los objetivos sobre los cuales enfocaremos nuestro mayor esfuerzo de pruebas.

A pesar de ser una herramienta que ha estado disponible desde hace un tiempo considerable, de carecer de una interfaz gráfica que haga más amigable su uso y de la existencia de muchas nuevas aplicaciones que pueden reemplazarla fácilmente, “nslookup” cumple su cometido de ayudar, en muy buena manera, a obtener información inicial importante que puede ser empleada para la planeación y posterior ejecución de nuestras Pruebas de Seguridad. Después de todo, es muy probable que muchas de las aplicaciones que actualmente están en el mercado destinadas al escaneo de vulnerabilidades o pruebas de penetración, en algún punto de su estructura interna contengan la funcionalidad del discreto pero efectivo “nslookup”.

= 10, mail exchanger =

37

Software Guru

él o los servidores de nombres relacionados

www.sg.com.mx |

A pesar de lo anterior, las funciones que nos ofrece “nslookup” no se limitan a la resolución de dominios. Las combinaciones de comandos “set type” nos permiten realizar búsquedas sobre ciertos registros de recursos DNS en específico. Por ejemplo, un registro de recursos DNS que puede ser de particular interés, es el representado por el valor “MX” el cual corresponde a un servidor de correo (Mail eXchange). La sintaxis de uso es la siguiente:

.PRÁCTICAS Project Management

Estimación de Costos: un vistazo a

COCOMO II

E

l Cliente dice: “¡Te damos tiempos límite razonables! ¿Por qué no puedes cumplirlos?”

Ese argumento es muy común en el desarrollo de software y el hecho de fijar la fecha de entrega antes de establecer los requisitos, es el problema más antiguo de la ingeniería de software, pero si ya estamos consientes de todo esto ¿por qué la improvisación parece ser el estándar? y ¿por qué no se tienen procesos de estimación bien definidos?

Hoy en día existen diversas herramientas y metodologías que nos permiten estimar costos como SPR KnowledgePlan de Capers Jones o COCOMO II de Barry Boehm, por comentar algunos. Sin embargo fenómenos como el “Proyecto interminable” y la “Marcha de la muerte” siguen siendo comunes en muchos desarrollos. Existen muchos factores que afectan las estimaciones de costo como: • Incertidumbre en los requerimientos.

• Términos contractuales rígidos.

• Salud financiera (ganar licitaciones sacrificando costo y tiempo).

• Falta de experiencia con “X” tecnología.

No existe una forma simple de calcular el esfuerzo requerido para desarrollar un proyecto de software. Las estimaciones iniciales se hacen bajo la base a la definición de requisitos que el cliente provee a un alto nivel (funcionalidades o pantallas). Los pasos típicos en una estimación son: 1.Análisis de los requisitos.

2.Predicción del tamaño.

3.Descripción de las Actividades.

4.Estimación de fallas potenciales y métodos de eliminación de defectos en el software.

5.Estimación de requisitos del personal.

6.Ajuste de suposiciones basadas en capacidades y experiencia.

7.Estimación del esfuerzo y fechas límite.

8.Estimación de costos del desarrollo.

9.Estimación de costos de mantenimiento y mejora.

A medida de que los proyectos de software aumentan en complejidad, se observa que no existe una relación simple entre el precio de software al cliente y los costos involucrados en el desarrollo, así como la falsa creencia que hay una relación entre el número de desarrolladores contra el número de funcionalidades del proyecto.

Por eso y para facilitar el proceso de estimación se han establecido a lo largo del tiempo, métricas que ayudan a dar una idea aproximada del tamaño del software:

›› Por Héctor Cuesta-Arvizu y José Sergio Ruíz Castilla

Medidas relacionadas con el tamaño del código ( LOC - Lines of code). Esta forma de medir el tamaño de un software era utilizado cuando los lenguajes de programación, patrones de desarrollo y entornos de desarrollo (IDE), no estaban ampliamente desarrollados.

Hoy en día es impráctico tratar de estimar el software a través de sus líneas de código ya que depende de la experiencia de los programadores o si hablamos de lenguajes de programación dinámicos como Ruby, Scala y Groovy o herramientas e IDEs que facilitan gran parte del trabajo de programación.

Medidas relacionadas con la función (UFC – Puntos de Función). El total de puntos de función no es una característica simple sino que es una combinación de características del software a las cuales se les asigna un valor que cambia dependiendo de su complejidad.UFC es igual a la suma de los “n” elementos evaluados por el peso asignado al tipo de función.

Sin embargo a lo largo del proyecto las funciones cambian, las métricas de puntos de función tienen en cuenta esto y multiplican los UFC iniciales por un factor de complejidad (asignándoles un factor de peso que va desde 3 a 15 puntos). Una desventaja de los puntos de función se presenta cuando el sistema está orientado por eventos. Por eso algunos autores piensan que UFC no es muy útil para medir productividad.

Los Puntos de Objeto (PO). Los PO se utilizan en el modelo de estimación Cocomo II con el nombre de Puntos de Aplicación. Estos son una alternativa a los UFC, y son usados en los lenguajes orientados a objetos y de scripts. Dan valor a cada pantalla dependiendo de su complejidad: simples = 1, medianamente complejas = 2, muy complejas = 3. Los reportes van de 2 a 8 dependiendo del nivel de complejidad, y los módulos en lenguaje imperativo como Java o C++ se contabilizan como 10. Esto puede ser relacionado directamente a las historias de usuario de algunas metodologías agiles con lo cual facilita la estimación de la iteración.

Modelo Constructivo de Costo: COCOMO II

Uno de los modelos de estimación más usados es COCOMO (Constructive Cost Model) creado por el Dr. Barry Boehm. COCOMO apareció por primera vez en su libro Software Engineering Economics [1] en 1981. En 1999 se definió la segunda versión del modelo que toma en cuenta el proyecto, el producto, el hardware y la experiencia del equipo de desarrollo en sus fórmulas de estimación de costo, incluyendo mecanismos de predicción de tiempo.

Cocomo II provee niveles que nos permiten hacer estimaciones en diferentes momentos del desarrollo ya que la estimación de costos debe 38

.PRÁCTICAS Project Management

“…el

software tiene una tasa de crecimiento de los requerimientos del sistema entre el 2 y el 5 por ciento mensual …”

2. Diseño inicial. Está basado en los requerimientos originales del sistema a un alto nivel (pantallas, reportes, procesos, transacciones) lo que son traducidos a puntos de aplicación, esto nos sirve para hacer una predicción temprana del costo.

3. Reutilización. Este nivel se utiliza para calcular el esfuerzo requerido para integrar el código generado por los IDE’s o herramientas de generación de código reutilizable como Spring Roo o Genexus por ejemplo, tomando en cuenta componentes reutilizables que facilitan el desarrollo como Apache Commons.

4. Post-arquitectura. Ya diseñado el sistema se pueden hacer estimaciones más precisas del tamaño del software, aquí es importante señalar que el software tiene una tasa de crecimiento de los requerimientos del sistema entre el 2 y el 5 por ciento mensual, por lo cual no es posible hacer una estimación exacta pero las predicciones de costo se pueden acercar mucho a la realidad gracias a la aplicación de métricas que nos permiten tener una variación muy pequeña con respecto al producto final.

Cocomo está basado en fórmulas para hacer las estimaciones, véase la figura 1 donde se estima el esfuerzo del personal por mes (PM), después se hace la estimación del tamaño del proyecto (SIZE) y finalmente se obtiene una proyección del esfuerzo requerido (B) contemplando los factores involucrados (SF).

Conclusión

La estimación de costos es una actividad muy importante en el desarrollo de software. Esta actividad no es estática sino que cambia en diferentes puntos del ciclo de vida del desarrollo. Se tienen que hacer estimaciones desde diferentes puntos de vista, desde la predicción de costos hasta la retrospectiva de comportamiento del costo, para lo cual las herramientas de estimación nos ayudan a agilizar la tarea. Sin duda el poder hacer predicciones con respecto al costo del software nos da ventajas que facilitan el éxito de un proyecto, sin embargo esto no debe de ser exhaustivo ya que se tienen variables que el modelo no contempla totalmente como la incertidumbre, la complejidad o factores humanos de los cuales no se puede tener control, por lo cual se deben tomar en cuenta los riesgos del proceso de desarrollo de software.

Una de las ventajas de COCOMO es el poder medir el comportamiento de costo de un proyecto de software de forma interna para la empresa de desarrollo. Lo que nos permite tener un referente en diferentes puntos del proyecto y así poder comprobar que las proyecciones de costo originales se cumplan.

Referencias: [1] B. Boehm. “Software Engineering Economics”. Prentice Hall, 1981.

[2] C. Jones. “Estimating Software Costs”. McGraw-Hill, 2007.

[3] “COCOMO II Model Definition Manual”. Center for Software Engineering, USC. [4] B. Boehm, C. Abts, et al. “Software Cost Estimation with COCOMO II”.

Prentice Hall, 2000.

.BIO Héctor Cuesta-Arvizu es Lic. en Informática y actualmente cursa la maestría en ciencias de la computación en la UAEM Texcoco. Cuenta con seis años de experiencia desarrollando y administrando proyectos de software en el ámbito de manufactura y recursos humanos. Adicionalmente se desempeña como instructor de TI para Nyce en el área de base de datos e ingeniería de software. @hmcuesta M. en C. José Sergio Ruíz Castilla es Profesor Investigador de la Universidad Autónoma del Estado de México, estudia el Doctorado en Ingeniería de Software y trabaja en proyectos de Ingeniería de Software y Sistemas de Gestión del Conocimiento.

Figura 1 Estimación de esfuerzo [3]

39

Software Guru

1. Construcción de prototipos. Las estimaciones de tamaño están basadas en puntos de aplicación con base en componentes reutilizables, prototipos y la fórmula para estimar el esfuerzo requerido es muy simple: tamaño / productividad.

Obviamente el realizar los cálculos manualmente es una tarea lenta y tediosa por lo cual existen muchas aplicaciones que se encargan de realizar todas las fórmulas, como USC COCOMO II que es la aplicación de la página oficial de COCOMO. Podemos descargar gratuitamente el software en http://swgu.ru/sg3414

www.sg.com.mx |

de ser un proceso dinámico a lo largo del desarrollo, actualizando constantemente las variables, la evolución del equipo de desarrollo, las herramientas y lenguajes involucrados. Los distintos niveles son:

.PRÁCTICAS Arquitectura

Líneas de Productos de Software

L

››Por Humberto Cervantes

a arquitectura de software es el resultado de un esfuerzo importante y su desarrollo puede representar una parte considerable del trabajo que se realiza en un proyecto de desarrollo. De lo anterior surge la pregunta, ¿habrá manera de aprovechar el esfuerzo que se hace respecto al desarrollo de la arquitectura de un sistema en el desarrollo de otros sistemas similares? Las líneas de productos de software buscan justamente lograr promover la reutilización sistemática de artefactos de los cuales la arquitectura es uno de los más importantes. Este enfoque busca tener distintos beneficios asociados a la reutilización como pueden ser la reducción del tiempo de desarrollo (pues ya no se tienen que desarrollar ciertas partes del sistema), y la mejora de la calidad (pues se incorporan partes que ya han sido verificadas previamente). En esta ocasión hablaremos al respecto de éste tema.

Reutilización

En el desarrollo de software, la reutilización se refiere a tomar uno o más artefactos realizados como parte de un desarrollo y utilizarlos nuevamente en el desarrollo de otro sistema. La reutilización no es un concepto nuevo y a lo largo de la historia del desarrollo de sistemas, han aparecido distintas técnicas que han facilitado de alguna manera la reutilización de artefactos de desarrollo de granularidad cada vez mayor, como lo muestra la figura 1:

temática. Dada su naturaleza, la reutilización oportunista presenta beneficios muy variables, pues todo depende de que en un momento dado se identifiquen posibles artefactos que puedan ser reutilizados. A nivel de una organización, lo deseable es lograr un enfoque de reutilización sistemática con el fin de lograr diversos beneficios asociados con retomar artefactos previamente construidos en cada desarrollo nuevo que se realiza.

Líneas de productos

El concepto de líneas de productos busca justamente lograr un enfoque de reutilización sistemático dentro de una organización de desarrollo. Éste es un concepto que se originó, y que se usa frecuentemente, en industrias distintas al software. En la industria automotriz, por ejemplo, es común que un fabricante produzca distintas variantes de un vehículo (o productos) a partir de una base común que se reutiliza en todas estas variantes.

De acuerdo al SEI (Software Engineer Institute), una línea de productos de software se refiere a un conjunto de sistemas de software que comparten características y que son desarrollados a partir de un conjunto común de bienes núcleo (core assets). De la anterior definición es importante subrayar que los productos dentro de la línea de productos son los distintos sistemas y que los bienes núcleo son las partes reutilizables que permitirán desarrollar los productos. Los bienes núcleo son la base de la línea de productos e incluyen entre otros la arquitectura, componentes reutilizables, modelos de dominio, requerimientos, documentación, planes de prueba, etc. Un aspecto importante a considerar dentro de la línea de productos es que se debe establecer un alcance en donde se describe qué productos son parte de la línea.

Actividades del desarrollo de líneas de producto

También de acuerdo al SEI, el desarrollo de líneas de productos involucra tres actividades principales: el desarrollo de los bienes núcleo, el desarrollo de los productos y la administración, y estas actividades están íntimamente ligadas entre ellas, como se muestra en la figura 2:

Figura1.

.BIO El Dr. Humberto Cervantes es profesor-investigador en la UAM-Iztapalapa. Ha realizado investigación en temas relacionados con arquitectura de software desde el año 2000 y en años recientes se ha enfocado en el estudio y la aplicación de métodos que apoyen al desarrollo de arquitectura de software dentro de la industria Mexicana. www.humbertocervantes.net

Aún con las técnicas antes mencionadas, de manera general, la reutilización frecuentemente se realiza de manera oportunista, esto es que si durante el desarrollo los miembros del equipo de desarrollo ven la posibilidad de reutilizar algún artefacto entonces lo hacen, pero eso no ocurre de manera sis-

Figura 2.

40

.PRÁCTICAS

Arquitectura

“¿habrá

manera de aprovechar el esfuerzo que se hace respecto al desarrollo de la arquitectura de un sistema en el desarrollo de otros sistemas similares?”

• El desarrollo de productos cubre el objetivo último de la línea de producto: producir sistemas específicos dentro del alcance definido a partir de los bienes núcleo. Los insumos para esta actividad son los bienes núcleo, los procesos asociados a los bienes, los planes de producción y los requerimientos específicos a cada producto.

• La administración juega un papel fundamental en la implantación de una línea de productos. La administración ocurre a un nivel técnico y organizacional. A nivel técnico, cubre tanto la supervisión del desarrollo de bienes núcleo como de productos específicos. A nivel organizacional orquesta el esfuerzo general de la línea de productos.

Arquitectura y líneas de producto

La arquitectura es un elemento clave dentro de la colección de bienes núcleo pues será compartida por los distintos productos de una línea particular. La arquitectura de una línea de productos es distinta a una arquitectura ‘típica’ pues para permitir la construcción de distintos productos por encima de ella, debe definirse una serie de puntos de variación que son necesarios para poder crear los distintos productos. En este tipo de arquitecturas, uno de los atributos de calidad más influyentes es entonces el que sea modificable.

Un ejemplo

Un ejemplo práctico de línea de productos puede observarse en la plataforma Eclipse que sirve de base al popular entorno de desarrollo (IDE) del mismo nombre (http://www.eclipse.org/platform/). La plataforma Eclipse está basada en una arquitectura extensible a base de plug-ins y la plataforma establece una serie de puntos de extensión en los cuales se conectan dichos plug-ins.

Los puntos de extensión que provee la plataforma representan los puntos de variación de la arquitectura. Los bienes núcleo son los distintos elementos que conforman a la plataforma Eclipse y son

En conclusión

En Ingeniería de Software frecuentemente se habla de reutilización y los avances tecnológicos de las últimas décadas indudablemente han logrado que hoy en día se reutilicen partes con un nivel de granularidad cada vez mayor. Lograr realizar una reutilización sistemática dentro de una organización requiere un enfoque específico y es ahí donde las líneas de productos pueden ser de mucha ayuda. La implantación de un esquema de línea de productos dentro de una organización requiere de un esfuerzo importante, sin embargo los beneficios que puede aportar pueden hacer que realmente valga la pena.

Un aspecto central de las líneas de productos es la arquitectura que soporta los distintos productos y ésta debe ser realizada tomando en cuenta las posibles variaciones que permitirán generar los productos específicos. Por último, es importante recalcar que al desarrollar una arquitectura para una línea de producto, es muy conveniente aplicar todas las actividades de desarrollo de arquitectura que hemos tratado en ediciones previas de ésta columna.

Referencias [1] P. Clements y L. Northrop, “Software Product Lines: Practices and Patterns”, SEI Series in Software Engineering, 2002.

41

Software Guru

• El desarrollo de bienes núcleo se refiere al establecimiento de las partes que serán reutilizadas. Cada uno de estos bienes debe ir acompañado de un proceso que explique la manera en que cada parte se usa al momento de incorporarla en un producto específico. Por otra parte, se establecen planes de producción que describen la manera en que los productos específicos son generados a partir de los bienes núcleo.

retomados para construir una gran variedad de productos específicos. Los productos específicos se construyen a partir de plug-ins que son conectados a la plataforma. Un aspecto interesante de Eclipse es que los plug-ins pueden, a su vez, definir puntos de extensión por lo cual un producto específico, conformado por la plataforma Eclipse y una serie de plug-ins, puede volverse a su vez un conjunto de bienes núcleo para una línea de productos más especializada. Un ejemplo de esto se puede observar en un producto como EclipseUML, una herramienta UML construida por encima de la plataforma Eclipse (http://www.ejb3.org/). De la línea de producto particular de EclipseUML se derivan dos productos específicos: el “Viewer” y el Editor. La parte administrativa de la línea de producto que establece la plataforma Eclipse se puede apreciar en la administración individual tanto del proyecto, que corresponde al desarrollo de la plataforma Eclipse, como la administración de los productos específicos que se producen por encima de la plataforma. La enorme variedad de aplicaciones sofisticadas construidas sobre la plataforma Eclipse que existen hoy en día sirven de testimonio del éxito de este enfoque.

www.sg.com.mx |

A continuación se describen estas actividades en mayor detalle:

.PRÁCTICAS Gestión de Riesgos

Administración Colaborativa de Riesgos

››Por Leonardo G. Mrak

Introducción

Después de varios años trabajando y dando consultoría en empresas de diferentes giros, llego a la conclusión de que la administración de los riesgos es un asunto únicamente de los Project Managers. Son los únicos preocupados por la detección y seguimiento de los riesgos de sus proyectos. Esta situación crea una falta de preocupación por parte del resto del equipo respecto a los riesgos de su proyecto e imposibilita el análisis colaborativo y las ventajas que con éste podemos lograr.

Esta técnica surge enfocada en atender esta problemática, la cual consiste en administrar los riesgos de una manera Colaborativa para que de esta forma todos los miembros del equipo se sientan involucrados y puedan aportar a la identificación y monitoreo de los riesgos de su proyecto.

Administración Colaborativa de Riesgos

Es necesario que el Project Manager coordine la dinámica asumiendo el rol de “Facilitador”. Él será el encargado de definir los asistentes para las sesiones de identificación y seguimiento de los riesgos, establecer un lugar con el tamaño adecuado para las sesiones, enviar las invitaciones y obtener los recursos necesarios para las sesiones (tarjetas, marcadores, plumas, proyector, etc.). Si existieran asistentes virtuales, ocuparse de que las herramientas de teleconferencia estén disponibles al momento de las sesiones.

1.Identificando Riesgos Propósito: detectar los riesgos por el EQUIPO del proyecto y otros invitados. Consiste en los siguientes pasos: a. Dividir a la audiencia en grupos (si es menor a 6 personas, consi.BIO derar a cada uno de los asistentes Leonardo G. Mrak es consultor en Qualtop, tiene más de 12 años de por separado), según el contexto experiencia dirigiendo proyectos de distinta índole y apoyando a empresas invitar a otros stakeholders como a mejorar sus procesos de entrega de por ejemplo: gerentes del área servicios e ingeniería de software. Logró acreditar a la primer empresa en técnica, representantes del área México en CMMI for Services Nivel 3 de Madurez. Es ITIL, PMP®, formó parusuaria, directores y/o gerentes te del primer grupo de habla hispana del área usuaria, etc. certificado como Kanban Professional y tiene un MBA realizado en Madrid b. Entregar tarjetas a cada uno y España. lmrak@qualtop.com pedir que escriban los riesgos que

Figura 1.

Figura 2.

detectan, uno por tarjeta. c. Pedir a cada miembro o grupo que peguen los riesgos en una pizarra y los expliquen (ver figura 1). A través de este ejercicio obtendremos una mayor participación, una mejor cobertura y una comprensión compartida de las preocupaciones de todos.

2. Agrupando Riesgos Propósito: evitar tener riesgos repetidos o muy parecidos, para eso se utilizará la técnica de Agrupación por Afinidad. a. El facilitador leerá cada uno de los riesgos y los asistentes indicarán si está relacionado con algún otro colocando la tarjeta del riesgo junto con la del que se relaciona. b. Repetir éste paso con cada uno de los riesgos y lograr el consenso de la agrupación de ellos.

3. Categorizando Riesgos Propósito: priorizar los riesgos identificados, tener una representación gráfica que proporcione información visual clara de los riesgos identificados y evaluados colectivamente por el equipo. a. Dibujar los ejes de Probabilidad/Impacto, considerando en el eje de las “y” la Probabilidad de ocurrencia del riesgo y en el eje de las “x” el Impacto del mismo (ver figura 2). b. Pedir a uno de los grupos o asistentes que coloque un riesgo entre los ejes y pasarle la posibilidad de ocurrencia al siguiente.

Los riesgos más graves quedarán en el extremo superior derecho, los riesgos menos críticos en el extremo inferior izquierdo, probablemente no vale la pena preocuparse por ellos (ver figura 3).

42

Figura 3.

c. Los siguientes pueden mover el riesgo anterior, colocar un nuevo riesgo o no hacer nada. d. Repetir éste paso hasta que todos hayan participado y no se necesiten más movimientos de los riesgos.

4. Monitoreando Riesgos a. Una vez categorizados los riesgos, establecer en conjunto con los asistentes un responsable para cada uno. b. Cada uno de los responsables tomará su riesgo y lo colocará en el “Tablero de Amenazas” (ver figura 3) según la estrategia de respuesta que seleccione. c. Cada uno de los responsables establecerá en una tarjeta las acciones que se llevarán a cabo de acuerdo a la estrategia de respuesta seleccionada. d. Los riesgos podrán ser cambiados de lugar y sus actividades podrán ser tachadas o alteradas por el responsable de ellos. e. El tablero deberá estar en una parte donde mínimamente el equipo pueda observarlo (si existieran miembros que participan de manera remota, utilizar algún software que permita establecer el tablero y el eje cartesiano, para poder administrar los riesgos de manera virtual).

.PRÁCTICAS Gestión de Riesgos

“ los

project managers son los úni cos preocupados por la detección y seguimiento de los riesgos de sus proyectos .”

f. Establecer reuniones regulares en las que se monitorearán los riesgos con el grupo que participó en la identificación inicial. Durante este monitoreo se revisarán los riesgos que fueron detectados anteriormente y quedaron en el eje de Prioridad/ Impacto como no críticos, ya que pueden cambiar su prioridad en el transcurso del proyecto. Luego se comienza con el paso 1 nuevamente.

las acciones a realizar se utilizan las rosadas y para registrar las acciones que se fueron realizando las verdes. b. Establecer las secciones que contendrán cada una de ellas por ejemplo: Considerar escribir las reglas a un costado del tablero para que estén siempre visibles y cualquiera que vea el tablero lo pueda entender.

Recomendaciones sobre el uso del Tablero de Amenazas

•Si hay una gran cantidad de movimiento que puede tomar un tiempo para que los riesgos se estabilicen, sea paciente, deje que el equipo sienta la divergencia en el grupo y permítales decidir cuándo es hora de dejar de mover los riesgos.

•Si hay participantes remotos, dividir los ejes (ver figura 2) en una rejilla de 4x4 y enumere cada celda, pida a cada participante remoto que le diga en qué celda colocar los riesgos. Lo mejor es que lo visual sea compartido, considere el uso de una herramienta de conferencia web y una herramienta que pueda mostrar los ejes de riesgos.

•Es bueno permitir debates sobre el movimiento que se realizan de los riesgos, siempre que contribuyan a comprender mejor el riesgo y su respuesta. Evite discusiones que no tengan este espíritu y obstruyan la dinámica.

•Busque que todos los participantes colaboren, en grupos grandes preste atención a los debates internos de los grupos y considere las expresiones de los miembros.

El Tablero de Amenazas (ver figura 3) consiste en dos filas horizontales aparte de la de Títulos, una de “Por Hacer” y otra de “Hecho”.

También contiene una columna por cada estrategia de respuesta a riesgos: •Evitar: realizar acciones para remover por completo el riesgo.

•Transferir: realizar acciones para traspasar el riesgo a otra persona o entidad. Esta estrategia presupone una inversión importante para poder hacer esta transferencia, obviamente que este gasto debería ser mucho menor al que se incurriría si el riesgo se transformara en problema.

Uno de los ejemplos más claros de acciones para esta estrategia es la contratación de seguros.

•Aceptar/Contener: el responsable del riesgo no ha identificado otra estrategia adecuada, esto se debe a que no siempre se pueden eliminar todas las amenazas de un proyecto. Esta estrategia de aceptación puede ser Activa o Pasiva, para el caso de la primera estrategia se establecen actividades de contingencia, mientras que para la segunda el riesgo directamente puede pasar a la fila de “Hecho” ya que no se llevarán a cabo actividades.

•Mitigar/Contener: se establecen actividades para disminuir la probabilidad de ocurrencia y/o el impacto del riesgo. También se pueden establecer actividades para la Contingencia, es por eso que en el riesgo 4 de la figura 3 (ver rectángulo con línea de punto) existen dos tarjetas de acciones asociadas al riesgo, uno relacionada a las actividades de Mitigación (marcada con una M en el extremo superior derecho) y otro relacionada a las actividades de Contingencia (marcada con una C en el extremo superior derecho).

Establecer reglas básicas: a. El color de las tarjetas pueden indicar algo, por ejemplo para identificar los riesgos se utilizan las amarillas, para establecer

Consideraciones para el facilitador

Conclusiones

Para terminar me gustaría recordar el significado de la palabra Riesgo, “es un evento incierto que puede provocar una pérdida, daño o perjuicio”. Esto quiere decir que un riesgo no es un problema, ya que el problema es un evento cierto, algo que ya sucedió y que tenemos que solucionar. Esto es lo que hace tan importante desde mi punto de vista a la administración de riesgos y es por eso que si la ejecutamos de manera correcta y oportuna, nos puede evitar grandes dolores de cabeza.

Para lograr esto es necesario que todos los involucrados en el proyecto tengan las capacidades necesarias para realizar una administración de riesgos eficiente. El contar con diferentes puntos de vista debido a la colaboración de involucrados con diferentes habilidades, nos permitirá aportar mayor valor, construyendo equipos de proyectos altamente proactivos.

44

.COLUMNA Código Innovare

Desarrollando un Sistema operativo

GNU/Linux

D

Ing. Jesús Arriola Villarreal Coordinador de la Unidad de Desarrollo de Software Libre de INFOTEC. Licenciado en Sistemas de Computación Administrativa por la UVM titulado con el trabajo “Desarrollo Integral Bajo Estándares de Calidad”. Cuenta con Certificación en Foundations ITIL. Desde 2003 colabora en el equipo de Desarrollo y Generación de Modelos Tecnológicos elaborando Servicios alrededor de los mismos. jesus.arriola@ infotec.com.mx jesus.arriola@ beakos.org.mx

entro de mi experiencia como especialista y arquitecto en soluciones de seguridad, centro de datos con base tecnológica en Software libre y GNU/Linux, he conocido diversas distribuciones con muy variadas ideologías y esquemas de negocio. He recorrido desde RedHat desde los años 90s, pasando por Fedora, Mandrake, Mandriva, Debian, Suse, Slackware, Puppy. He observado maravillosas funcionalidades, ventajas, así como el aprendizaje que un sistema basado en GNU, cobijado por las cuatro libertades del software libre tiene. La simple idea de tener disponible miles de proyectos basados en Software Libre de los cuales he aprendido lo inimaginable me motivo a pensar en la idea de crear una distribución con sabor propio.

Desde que instalé mi primer sistema GNU en una computadora he observado que de forma predeterminada mucho software es instalado sin consentimiento del usuario, lo cual pienso que es muy útil, ejecutando un simple comando “top” se puede observar gran número de procesos que se están ejecutando, pero ¿Por qué, qué hacen, se necesitan realmente? Y de aquí se derivan algunas preguntas más. ¿Cómo está construido el sistema?, ¿con qué soportes se incorpora?, ¿Por qué no puedo tener un sistema que yo mismo construya desde sus herramientas más indispensables?

Aunado a lo anterior ha existido siempre la posibilidad de crear una distribucion “tropicalizada”, es decir basándose en una distribución ya hecha, modificar los componentes adecuándolos y dándoles un toque personal. Lo anterior es un debate fuerte, ya que desde un principio supe que el desarrollar una distribución desde cero, involucra un fuerte trabajo posterior debido al mantenimiento que se debe dar a todos los paquetes que integran el sistema.

Buscando dentro de internet existe un proyecto llamado Linux From Scratch el cual consiste en una serie de documentos en formato html o pdf. Contiene una metodología para desarrollar un sistema gnu/linux desde cero. El resultado de esto es un sistema muy perso-

nalizado a la computadora donde se desarrolló, sin embargo, cuando se intenta instalar este sistema en otros equipos (laptops, pcs, servidores), se pueden descubrir multitud de problemas que nunca se pensaron encontrar derivado de las siguientes razones: • LFS no proporciona desde un principio un mecanismo de administración de paquetes (rpm, deb, tgz, etc), esto provoca que el mantenimiento del software resulte sumamente complicado de gestionar.

• La compilación de los paquetes base del sistema sólo incluyen la incorporación de los soportes mas esenciales del sistema, por lo que posteriormente es probable que se requiera recompilar algún software.

• Se sugiere en LFS el mecanismo de “kernel huge”, esto hace que la imagen del núcleo contenga todos los soportes que son requeridos para bootear un sistema, lo anterior resulta práctico para que el sistema “bootee” rápidamente, pero para distribuir el sistema en otras computadoras no es lo más recomendable.

• Se sugiere un ambiente para construir el sistema, pero dicho modelo puede ser mejorado para asegurar el éxito de la construcción.

Estas son algunas razones de las más poderosas que me orillaron a diseñar una metodología que permita construir un sistema basado en GNU/Linux distribuible , término que obedece a la idea de que forme parte de los Sistemas GNU, que pueda ser instalado en una gran variedad de Sistemas y también con amplia variedad de Hardware. El resultado de este proceso además de tener un sistema distribuible hecho desde cero, es tener un sistema igual de confiable que otras distribuciones e incluso con mayor rendimiento en tiempos de respuesta.

Retomando parte del método de LFS, el sistema GNU se desarrollará en las siguientes fases, donde se está agregando y modificando la metodología original de LFS con la experiencia propia para lograr que el sistema sea distribuible: 46

.COLUMNA Código Innovare

››El resultado de este

Las metodologías de desarrollo que han utilizado los desarrolladores de sistemas operativos no ha sido publicado en su mayoría. Infotec como participe activo en la Sociedad del Conocimiento ha proporcionado los medios necesarios para que se desarrolle por mi parte esta metodología con el apoyo de otros ingenieros Mexicanos muy talentosos. El resultado es crear sistemas basados en GNU/Linux con funcionalidades equivalentes a otros sistemas y de excelente calidad.

Considero que esta metodología debe ser tomada en cuenta como parte de la formación de los profesionales en TI, ya que es una carencia que existe dentro de algunas instituciones de educación superior y esto reforzara fuertemente la preparación académica. Esta metodología genera un conocimiento impresionante dentro del lector al conocer la forma en la cual un sistema se integra, las funciones de cada uno de sus componentes, las etapas por las cuales una simple llamada del sistema es procesada, y un amplio campo de áreas de oportunidad para otros proyectos de Software Libre.

El sistema que se genera con esta metodología es básico, se describe como “Un sistema base, con las herramientas de espacio de usuario básicas, y con las herramientas más importantes para el desarrollador”, en este momento se puede considerar al sistema obtenido como una metadistribución porque es una plataforma base, que posteriormente puede ser utilizada como un sistema para usuario final (con ambiente gráfico), un sistema de servidor u otro tipo de sistema.

Lo que sugiero a partir de este momento es continuar con el desarrollo o construcción de aplicativos de Software Libre, pequeños, de los cuales existe documentación muy desarrollada, sin olvidar la gestión de paquetes con el método seleccionado.

››Por Ing. Jesús Arriola Villarreal

47

www.sg.com.mx |

1. Implementar el ambiente de desarrollo, donde se prepara un sistema ideal para parchar, adecuar y compilar diversos paquetes de software libre. Este incluye un Sistema anfitrión, o un ambiente virtualizado con un kit de software para desarrollo, una partición, la obtención de Software y la adecuación de las variables del sistema.

2. Preparación de las herramientas indispensables para construcción, lo cual involucra: la biblioteca de Desarrollo GlibC, el compilador GCC, las herramientas GNU bintutils y la incorporación de los headers del kernel.

3. La construcción de un árbol de dependencias, el cual resultará muy útil para la siguiente etapa y para el usuario final.

4. La incorporación de un sistema de administración de paquetes, la cual es sumamente importante. Este paso resulta complejo e involucra trabajo extra que al final del desarrollo genera documentación y un repositorio de software.

5. Se procederá posteriormente a la preparación (parches/adecuaciones), configuración, compilación, creación de paquetes y su instalación correspondiente, esto genera al final un sistema base con las herramientas de espacio de usuario más indispensables.

6. Instalación de los Scripts de Arranque. En este punto se decidirá el tipo de sistema: System V o BSD. Dichos scripts son necesarios para el arranque del sistema.

7. Hacer el sistema booteable, en esta etapa se incorpora el esquema para agregar el mecanismo “Disco en RAM” así como la configuración correcta del kernel, esto es importante porque asegura que el sistema pueda ser instalado en una mayor cantidad de computadoras sin necesidad de hacer adecuaciones sumamente complejas a los componentes del sistema.

8. Se implementa un programa hecho en Script Bash y un conjunto de Scripts del mismo lenguaje, para que el sistema pueda recuperarse creando un LiveCD y un sistema “Setup” para instalar la distribución GNU/Linux en otras computadoras.

Software Guru

proceso es tener un sistema igual de confiable que otras distribuciones e incluso con mayor rendimiento en tiempos de respuesta.

.COLUMNA Tecno-lógico

La Muerte del

Botón

D

iseñar interfaces gráficas requiere más trabajo de lo que los desarrolladores y líderes de proyecto les gusta pensar, no únicamente por el tiempo que requiere la producción de estas interfaces sino porque también necesitan pasar un proceso de revisión y pruebas de manera similar al software, pero con criterios y lineamientos completamente diferentes a los que los ingenieros y arquitectos de software están acostumbrados. Adicional a esto, las formas y maneras en que los usuarios utilizan tanto software como la tecnología están cambiando y se están diversificando: lejos están los días en que los botones y las teclas eran los puntos focales de interacción humano-máquina y hoy en día podemos afirmar sin duda que el botón, como concepto, es una especie en peligro de extinción.

Tres tipos de interacción

Mauricio Angulo es programador desde 1989 divulgador, ávido escritor y emprendedor. Actualmente es CEO y fundador de Tesseract Space donde realiza funciones de asesor y consultor de innovación tecnológica, mercadotecnia digital y experiencia de usuario.

El término interfaz se utiliza para describir los instrumentos de comunicación e interacción entre un sistema y los usuarios que los manejan.

El ratón, el teclado y el monitor de una PC son interfaces físicas, y los elementos que están en la pantalla, desde ventanas, cajas de diálogo o de texto, iconos y demás son interfaces visuales. Los programas y servicios que corren en una computadora, un móvil o en la web realmente no necesitan interfaces, éstas existen para hacer el trabajo de sus usuarios más sencillo y para que no tengan que invertir demasiado tiempo aprendiendo comandos o realizando operaciones mecánicas una y otra vez.

La interfaz es un puente que comunica al sistema con su usuario. Las interfaces de sistemas se han hecho más sofisticadas con el tiempo, pasando de las incomprensibles tarjetas perforadas de los setentas a las sofisticados ambientes gráficos que utilizamos hoy en día, no sólo en las computadoras personales sino también en las televisiones, en dispositivos móviles y prácticamente en cualquier otro dispositivo digital.

En la historia de la computación hemos visto tres tipos de modelos generales de interacción conforme la técnica evoluciona y los usuarios no tecnológicos se vuelven más relevantes para la industria: el primero fue aquel de las Interfaces de Línea de Comando (Command Line Interface o CLI) donde el modelo de interacción estaba basado en la escritura de comandos en una consola que disparaban acciones en una aplicación. Este modelo es eficiente pero completamente desconectado del usuario y su buen funcionamiento depende de que tan bien el usuario conozca los comandos o “palabras mágicas” que lo hacen funcionar. Aunque es un entorno útil para un usuario con experiencia técnica, no es un buen punto de entrada a la tecnología en términos de una experiencia positiva o lúdica y es percibido más como una barrera que como una ayuda en la adopción tecnológica.

El siguiente modelo fue el de las Interfaces de Usuario Grá-

ficas (Graphical User Interface o GUI), en el que imágenes y metáforas del mundo offline como un escritorio, carpetas, archiveros y documentos sustituyen los comandos por un acercamiento más humano e intuitivo. Los sistemas gráficos se basan en el reconocimiento de estas metáforas por parte del usuario y de la interacción basada en suposiciones, en prueba y error así como también de controles virtuales como menús, botones y ventanas. El problema con los entornos gráficos es que no hay consenso sobre su diseño e implementación y el usuario se ve forzado a aprender los cambios entre diferentes sistemas, aplicaciones e incluso en las diferentes versiones de los mismos.

En los últimos años las llamadas Interfaces Naturales (NUI: Natural User Interfaces) se han colocado como las preferidas de la industria de tecnologías de información porque favorecen la interacción de un usuario con la tecnología sin intermediarios físicos, como el mouse o el teclado. La idea es hacer la interacción con la tecnología lo más natural y simple posible, reemplazando los acercamientos tradicionales que vienen de las GUI como lo es la idea del botón.

Controles Naturales y No-Naturales

El botón, como lo conocemos, es una abstracción humana desarrollada durante la revolución industrial que representa el disparo o ejecución de una acción: al presionar el botón se activa un proceso y diferentes botones están asociados con distintos procesos. En las interfaces digitales, desde teléfonos inteligentes hasta páginas web, los botones son representados por gráficas de diferentes formas para que el usuario tenga opciones de navegación y acción.

El problema con el botón es que, por común que se haya vuelto, ¡no es un control natural! Los botones y todos sus parientes, los íconos, los switches, los links y los banners son solo una aproximación mental para resolver un problema pero por mucho no es la solución más óptima. La enorme cantidad de sistemas, dispositivos y herramientas que usamos hoy en día nos exigen mayor atención a las interfaces y entre más botones haya que tocar más difícil de manejar es un sistema.

Un experimento interesante al respecto es el que propone el Institute for Interactive Research con su sitio Don’t Click It (www.dontclick.it) en el que se proponen diferentes acercamientos acerca de cómo sustituir el clic en el ratón con gestos y movimientos simples sobre objetivos gráficos. El sitio ya tiene buen tiempo publicado -unos 7 años- y se ha ido enriqueciendo con la interacción y prueba de miles de usuarios que han experimentado con las interfaces del sitio.

Las nuevas interfaces táctiles en computadoras touch y en móviles inteligentes reemplazan el “clic” por el “tap”, el “flicking”, el “pinch” y otras maneras de interacción que resultan más naturales para las personas.

48

El Usuario y su Experiencia Digital

El diseño de interfaces digitales es un punto crucial en la aceptación o rechazo de un sistema, ya que si este es muy complicado de manejar, lo más probable es que sus usuarios no lo utilicen porque desde su punto de vista les ocasiona más problemas que soluciones.

La búsqueda de esta experiencia positiva es el motor principal detrás de la evolución de las interfaces como las conocemos, conforme la tecnología se democratiza y cada vez más usuarios que no son ‘expertos’ en computación la adoptan, la industria siempre está buscando crear interfaces más simples, intuitivas y sencillas de utilizar.

Llevando el concepto de interfaces naturales al extremo, el usuario ya no necesitará tocar siquiera sus computadoras: estas responderán a la presencia del usuario, a su voz y a sus movimientos. Este tipo de interacción irá eliminando otros conceptos de las interfaces como las conocemos hoy tales como las contraseñas alfanuméricas, las identidades basadas en correo electrónico o el uso de múltiples identidades en la Red, volviendo nuestra interacción con nuestros dispositivos y también con la información, software y servicios en la Nube mucho más dinámica y personal.

La finalidad del desarrollo de NUI es, por un lado, volver más accesible la tecnología a las personas que las están conociendo por primera vez (personas muy jóvenes, mayores o muy pobres) para cerrar la Brecha Digital y por otro lado, eliminar de nuestros procesos mentales la complejidad asociada con utilizar un sistema y permitirnos concentrarnos en simplemente utilizarlos.

La siguiente gran brecha digital existirá entre los Power Users que tienen años usando interfaces mecánicas basadas en palancas o botones y las personas que, siendo nativos digitales, aprendieron a utilizar las herramientas tecnológicas del siglo XXI de manera natural.

El reto está, evidentemente, en que las empresas y personas que desarrollan software y sitios web puedan conocer e integrar los elementos de NUI a sus desarrollos para acercarnos cada vez má a una auténtica vida digital.

››Por Mauricio Angulo

.COLUMNA Programar es un Estilo de Vida

Repensando las

D

Certificaciones

iversas personas me han preguntado qué certificaciones deberían buscar para afianzar su carrera o posición o cuál conviene a una empresa buscar en un prospecto de contratación. Me llama la atención principalmente el que asuman la respuesta a un cuestionamiento previo y condicionante a éste: ¿Vale la pena buscar certificaciones? Esta pregunta me puso a pensar en lo relativo a quién las pide (tanto desde el punto de vista del individuo que las persigue como del contratante que las valúa), dado el público alcanzado por esta revista, creo que puede ser de interés enfocar la columna hacia este tema.

››Quien busca contratar a un profesional con trayectoria no puede limitarse a evaluar en base a los certificados presentados. ¿Qué es una certificación?

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

Para el presente análisis me centro en las certificaciones como un documento emitido por una entidad comercial no dedicada principalmente a la educación superior, validando que el sustentante posee el dominio de un conjunto específico de herramientas o tecnologías (típicamente, aunque no necesariamente, limitadas a las generadas por la organización certificadora).

Las certificaciones difieren de otros métodos de calificación en que normalmente son otorgadas ante la presentación y aprobación de un examen; comúnmente no requieren que el sustentante siga un curso.

Además de lo anterior, las certificaciones frecuentemente tienen –a diferencia de prácticamente cualquier programa académico– una validez determinada, ya sea por un tiempo preestablecido, o por estar atadas a tecnologías específicas, con un ciclo de vida y obsolescencia planificado.

Y un punto adicional: Las certificaciones, si bien se presentan a sus clientes potenciales como una oportunidad de obtener mejores calificaciones para aumentar sus evaluaciones (redundando directamente en beneficios económicos), en ningún momento buscan ocultar que son para sus promotores un negocio antes que ninguna otra

cosa. Lo cual, claro, no es ningún pecado, pero sí es un punto a considerar al evaluarlas. Consideremos dos perfiles en particular — Los dos antiperfiles donde, a mi forma de ver, las certificaciones juegan en contra de la mayor parte tanto de individuos como de empresas.

Antiperfil 1: El recién egresado

El argumento para buscar certificaciones es simple: Si cuando un postulante es evaluado para un puesto laboral, el entrevistador de primer contacto no tiene un perfil técnico, sino que busca descartar a quien no cumpla con las características básicas que busca la empresa, en realidad la primer entrevista “real” se presenta una vez pasado ese filtro. El Can Cerbero corporativo no permitirá el paso del postulante si no cuenta con el altero completo de papeles.

Este punto de vista apunta a un postulante novato, probablemente recién egresado de la universidad, sin experiencia laboral en el mundo real, que no ha tejido aún redes profesionales y no encuentra una mejor vía de acceso. Este punto crece especialmente cuando estos nuevos integrantes de la fuerza laboral buscan emplearse en una de las relativamente pocas grandes empresas consultoras de desarrollo que hay en nuestro país.

Las certificaciones que están al alcance de un recién egresado, sin experiencia en el campo, son relativamente pocas — Y el peso económico de perseguirlas resulta respectivamente elevado. Muchas universidades han incorporado a los servicios que ofrecen a los alumnos el prepararlos para alguna certificación básica y reducir el precio a pagar por ella. Esto, en mi opinión, equivale a que dicha universidad se reconozca incapaz de ofrecer una formación suficiente para que sus egresados encuentren un puesto de trabajo adecuado y –al impulsar una tecnología específica– demerita la universalidad de la formación que dio nombre a las universidades desde un principio.

Antiperfil 2: El experto en certificaciones

Un perfil que nace como consecuencia lógica del anterior es el del experto en certificaciones. Si por cada examen que presento crece mi elegibilidad laboral, ¿por qué no acumularlos? Aprender el material necesario para presentar un examen es, a fin de cuentas, una habilidad que puede ser aprendida y dominada. Si bien muchas certificaciones incluyen la resolución de problemas prácticos, siguen presentándose en un entorno donde, hasta cierto punto, las situaciones son muy distintas a las de la vida real.

50

.COLUMNA

Alternativas

Y pasando de la crítica a la propuesta, ¿qué puedo aportar tras mi crítica a este modelo?

Para un recién egresado, enfrentarse al monstruo corporativo sin experiencia real previa no da espacio a la negociación. Mientras las empresas sigan imponiendo estos filtros previos a la entrevista real, ¿qué puede hacer quien inicia su carrera profesional?

Ser recién egresado no significa no tener experiencia real. Entrar a estudiar una carrera relacionada con la computación debería indicar una genuina afición al pensamiento analítico. En nuestro campo, tenemos la gran fortuna de que un aficionado sin estudios, sin equipo profesional y sin cualificaciones formales, puede desarrollar proyectos en casi cualquier ámbito del campo. En el cómputo, todos ustedes podrán citar numerosos ejemplos que han contribuido al campo de forma decisiva, sin formación profesional.

Claro, sería iluso pensar que todos coordináramos proyectos de gran envergadura siendo aún adolescentes o que impulsar una idea exitosa nos lleve a abandonar los estudios profesionales y saltar a la fama como estrellas de la programación. Sí podemos, sin embargo, ir haciendo públicos los pequeños proyectitos que hacemos, los retos interesantes que vamos resolviendo, los programas que escribimos por gusto. Publicar código, especialmente como software libre, es una muy buena manera de demostrar capacidad profesional, compromiso, capacidad de documentar y de brindar soporte a los usuarios. Es más, si nuestro proyecto juguete fue adoptado por una distribución de Linux, esto resulta clara muestra de que otros expertos juzgan nuestro trabajo digno de ser promovido.

Respecto al segundo antiperfil, el caso presentado ilustra que las competencias laborales de un profesional con trayectoria no pueden ser juzgadas de manera meramente cuantitativa — Los diversos campos relacionados con el cómputo requieren de una gran creatividad, y no pueden ser juzgados como una materia de la escuela, en que el desarrollo del resultado debe ser idéntico al que nos fue impartido en clase.

Quien busca contratar a un profesional con trayectoria no puede limitarse a evaluar en base a los certificados presentados. En mi experiencia, las veces que mi recomendación ha sido requerida para un proceso de selección de personal, coloco en último lugar todos los currículos que presentan certificaciones de forma destacada. Nunca me he arrepentido de hacerlo ya que estos tienden a ser los que menos conocimiento real tienen del campo.

El que una entrevista laboral para un puesto que requiere conocimientos especializados (sean de un estudiante recién graduado o de un experto) tenga que pasar por un filtro no conocedor de la materia es síntoma de un problema estructural: La tercerización a los corporativos de desarrollo de software ha crecido en detrimento de la capacidad de las entidades que las contratan. No con esto digo que deban desaparecer — Si bien debe ampliarse la capacidad de respuesta de los departamentos de sistemas de quienes típicamente contratan a estas empresas (entiéndase: Ampliarse su tamaño, sus áreas de especialización y la seguridad laboral brindada a sus integrantes), muchos de los proyectos podrían perfectamente ser encargados ya sea a empresas de escala más humana (PyMEs) o contratar a grandes empresas verdaderamente especializadas en un ramo específico. Esto, claro, reduciría el tamaño de las consultoras — Pero aumentaría su calidad así como también las oportunidades laborales con una justa comparación basada en méritos reales, más cerca de quien verdaderamente requiera del servicio.

Por otro lado, no todos los proyectos en que participamos –por hobby o por encargo– puede ser publicado. Sin embargo, permítanme insistir en que la mejor carta de presentación es el trabajo realizado. En otras áreas laborales es común –incluso en algunos países, obligatoria– la pertenencia a colegios de profesionales — Cuerpos que establecen las normas mínimas de operación, calidad y cobro en el campo, y guardan registro de la actividad de sus agremiados. De tal suerte, en vez de requerir un certificado emitido por una empresa claramente parcial y con innegables intereses económicos en el área, habría una entidad a la cual preguntar acerca de la experiencia comprobable de un postulante.

Los colegios citados nacieron dada la necesidad de una entidad que validara, y asumiera responsabilidad ante dicha validación, a profesiones en las que puede haber amplia responsabilidad civil, como la medicina o la arquitectura. La importancia que van adquiriendo los desarrollos hoy en día nos lleva a plantear si no es momento de una reglamentación similar en nuestra área.

Hay lugar para las certificaciones. Hay trabajos en que hace falta contratar a alguien que domine una tecnología específica, aún sin ser un experto en el ramo entero. La distorsión, a mi opinión, está más en la escala que han adquirido. No pueden ser requeridas como carta de presentación, no puede dárselas un peso comparable al de un estudio prolongado y general (como un título universitario) o al de las capacidades demostradas con trabajo.

››Por Gunnar Wolf 51

www.sg.com.mx |

Por otro lado, una persona altamente calificada no necesariamente sabrá presentar un examen, cosa que a ninguno de ustedes debe sorprender — los ejemplos abundan, traigo ante ustedes a uno en particular, aunque sea sólo como evidencia anecdótica: He tenido oportunidad de trabajar con algunas personas verdaderamente talentosas, referencia en el campo de la seguridad y administración de sistemas, que frecuentemente asesoran a los técnicos de empresas transnacionales. Uno de ellos intentó certificarse en uno de los temas en que es pionero en nuestro país y no logró aprobarlo. ¿Significa esto acaso que su conocimiento de la tecnología, las herramientas y los procesos es menor que el de quien sí aprobó el curso? Definitivamente no. Solamente significa que los procesos mentales que ésta persona sigue no se alinean con los que la empresa certificadora sugiere.

Y es precisamente esto lo que le ha permitido convertirse en su asesor: El seguir procesos creativos, no buscar dentro de lo predecible y tener un verdadero conocimiento profundo del sistema como un todo.

Software Guru

Programar es un Estilo de Vida

.PERSONAS Carrera

Capital Humano en Software reflexiones y perspectivas ››Por Pedro Galván

E

n SG tenemos ya 7 años contribuyendo al desarrollo de capital humano de software por medio de la revista, eventos y SG Campus. Conforme estuvimos desarrollando nuestro nuevo servicio llamado SG Talento, he estado reflexionando sobre este tema y considero pertinente compartir con ustedes algunas perspectivas. Las he dividido en secciones dependiendo de a quién van dirigidas.

Profesionistas

La revaloración del desarrollador Tradicionalmente en nuestra región los desarrolladores han sido obligados a moverse a otros roles para poder mejorar su compensación económica. Todos hemos conocido excelentes programadores que se hicieron malos gerentes. Sin embargo, hoy la profesión del desarrollador se está revalorando y cada vez más los desarrolladores se pueden mantener en su rol sin necesidad de renunciar a sus expectativas económicas. Para crecer no necesitan cambiar de rol, sino ser mejores desarrolladores profundizando sus conocimientos, aprendiendo nuevas herramientas e incorporando una mayor variedad de skills (por ejemplo DevOps). Uno de los factores que ha contribuido a esta tendencia es el renacimiento de los lenguajes de programación, sobre el cual reportamos en la edición de Mayo 2008 de SG. Otro factor es la popularidad de los métodos ágiles, donde la estructura organizacional es más plana y por lo tanto los miembros del equipo tienen mayor responsabilidad y visibilidad.

Desarrolladores independientes Otra tendencia es la creciente inclinación de los profesionistas por ser independientes. Antes, freelancer era sinónimo de desempleado. Hoy cada vez me encuentro con más personas que son independientes no por necesidad sino por elección, porque quieren poder escoger los proyectos, clientes, tecnologías, tiempos y tarifas con los que trabajan. Si te interesa tomar este camino debes construir una buena reputación.

Algunas formas de lograr esto incluyen escribir artículos (ya sea para alguna publicación externa o tu propio blog), participar en foros especializados y participar en proyectos de software libre (o crear el tuyo propio). Adicionalmente, github cada vez se posiciona más como herramienta no solo para guardar sino para “presumir” tu código.

Estudiantes

El valor de la educación universitaria ¿Para qué estudiar? Después de todo ni Steve Jobs, ni Bill Gates ni Mark Zuckerberg terminaron la escuela.

Mi recomendación es que si tienes la posibilidad de estudiar una carrera universitaria –sin endeudarte significativamente–, lo hagas.

El periodo universitario es una experiencia formativa en muchos sentidos más allá de los “conocimientos duros”. Una buena educación

universitaria te ayudará a conocerte mejor a ti mismo, relacionarte con otras personas, y sobre todo te enseñará a aprender. Lo más importante no son los conocimientos duros que obtengas, sino el desarrollar la habilidad de aprender.

En el caso de países como Estados Unidos donde el costo de una carrera de cuatro años fácilmente supera los 150 mil dólares en colegiatura, es comprensible que cada vez sea más popular la recomendación de no estudiar y mejor utilizar ese dinero para emprender.

Incluso, Peter Thiel está dando 100 mil dólares a jóvenes para que dejen la escuela [1]. Pero en el caso de países como México donde el costo de la educación universitaria es mucho menor, recomiendo que si tienes la posibilidad de estudiar, no la desaproveches.

En el caso particular de México hay otro beneficio de graduarte de una carrera universitaria: la visa TN. Esta es una visa de trabajo temporal en Estados Unidos especial para ciudadanos mexicanos que se desempeñan en profesiones especializadas. Es la forma más rápida y sencilla de conseguir visa de trabajo en EU, pero requiere que estés titulado y tengas tu cédula profesional.

Conocimientos requeridos Una queja común de los alumnos es que en sus universidades les enseñan tecnologías muy viejas. Yo creo que en la universidad es más importante que aprendas bien los principios a que aprendas las tecnologías más modernas. Por ejemplo, si te enseñan Lisp, que es un lenguaje de 1958, te permitirá entender la programación funcional y así utilizar bien lenguajes modernos como Clojure o F#. Habiendo dicho esto, es necesario que sí conozcas lenguajes y tecnologías modernas, ya que cuando busques trabajo dudo mucho que les interese que sepas Lisp. Mi recomendación de los 10 lenguajes/tecnologías que un buen desarrollador debe conocer actualmente son: Python, C#, Scala, Javascript, Node, HTML5+CSS3, git, gradle, NoSQL (Couch o Mongo), Hadoop. Lo más probable es que en la escuela te enseñen muy poco, o nada de ellos, así que tú tendrás que aprenderlos por tu lado. No te preocupes, si entiendes los principios será fácil. Adicionalmente, tu conocimiento con estas tecnologías debe ser comprobable con aplicaciones publicadas en algún lado. Ya te darás cuenta de que tener una aplicación publicada en un app store te servirá mucho más para conseguir empleo que un 10 final en el curso de compiladores. ¿Y entonces para qué aprender algebra lineal o compiladores, si no sirven para conseguir empleo? Los aprendes por dos razones: 1) Para desarrollar tu cerebro, y 2) Porque aunque lo más probable es que no te ayudarán a conseguir tu primer empleo, definitivamente son herramientas que te ayudarán a hacer mejor las cosas y por lo tanto potenciarán tu carrera profesional.

52

.PERSONAS Carrera

“Los desarrolladores son curiosos por naturaleza.

Si no dejas que alimenten su curiosidad, dejarán tu empresa.”

Prepara ingenieros de software, no IT Pros

Alimenta la curiosidad de tus devs

Un problema común que encuentro en los planes de estudio de las universidades en nuestra región es que están orientados a formar “técnicos en informática” (IT Pros) en lugar de ingenieros de software. El trabajo del IT Pro consiste en administrar infraestructura de TI tal como computadoras y redes; pero su preparación dista mucho de lo que se requiere para desarrollar software profesionalmente, y es para esto último para lo que hay trabajo. Entonces, no es ninguna sorpresa que anualmente miles de graduados salen a buscar trabajo y se dan cuenta que no saben hacer lo que la industria demanda —desarrollar aplicaciones.

Recomiendo a las universidades que busquen formar ingenieros de software a que obliguen a sus alumnos a desarrollar aplicaciones desde los primeros semestres. Existen universidades donde se pasan 4 años estudiando teoría pero sin haber construido una aplicación de software de principio a fin. Creo que es mucho mejor que los alumnos comiencen a desarrollar aplicaciones completas (sencillas, pero completas) desde los primeros semestres y conforme vayan avanzando en su carrera vayan aprendiendo aspectos como configuration management, testing, distintos paradigmas de programación, que apliquen en sus proyectos para hacer mejor software. El objetivo es que cuando se gradúen lleven 4 años desarrollando software, no 4 años estudiando técnicas que nunca han aplicado.

Los desarrolladores son curiosos por naturaleza. Si no dejas que alimenten su curiosidad, dejarán tu empresa. Hay distintas cosas que puedes hacer, por ejemplo hay empresas donde por política los empleados deben dedicar cierto porcentaje de su tiempo a actividades que no estén relacionadas con el proyecto al que están asignados. Otra práctica que un colega de India me comentó que aplicaban en su empresa era que las personas no podían durar más de 12 meses en el mismo proyecto, y que al terminar un proyecto debían tomar 2 semanas de entrenamiento en nuevas tecnologías antes de entrar a un nuevo proyecto. Otra posibilidad es la de “donar” tiempo de nuestros empleados para participar en proyectos de software libre. De esta forma, pueden estar dedicando tiempo a algo que los apasione, al mismo tiempo que aprenden, contribuyen a la comunidad y dan un buen nombre a tu empresa.

Empresas

La situación no es sencilla. El reto de los candidatos es desarrollar los conocimientos prácticos que busca la industria, sin descuidar las habilidades y aptitudes fundamentales que lo ayudarán a ser un mejor profesionista a lo largo de su carrera. Por su parte, las empresas requieren poder atraer y retener al capital humano que necesitan, y para ello necesitan cambiar muchas de sus prácticas actuales de RH. En SG estamos conscientes de las necesidades en este rubro, es por ello que creamos un nuevo servicio llamado SG Talento [4] con el que buscamos que los profesionistas de software puedan evaluar y reflejar sus habilidades de forma sencilla, facilitando así a los reclutadores encontrar el talento que buscan.

Menos tweets y más branding No importa cuantos tweets envíes con “urge” y “please RT”, si tu empresa no tiene un “buen nombre” entre los profesionistas de software no vas a atraer talento. Y si logras atraer talento, solo lo vas a lograr a billetazos, y así como llegó, se va a ir al próximo mejor postor.

Una de las cosas que puedes hacer para mejorar tu branding hacia desarrolladores es participar en eventos dirigidos a esta audiencia. Dependiendo del tipo de evento, así como presupuesto que tengas, hay distintas opciones desde poner un stand hasta patrocinar las cervezas o rifar libros.

Algo más que te recomiendo es fomentar que tus empleados compartan conocimiento con el exterior, ya sea escribiendo artículos, dando pláticas en eventos, o simplemente blogueando. No se trata de que explícitamente promuevan tu empresa, sino que compartan con colegas conocimiento técnico adquirido en proyectos reales de la empresa. El efecto que buscas es que la gente piense “aquí hacen proyectos interesantes y valoran el talento.”

Los profesionistas cada vez valoran más su libertad, incluso sobre el dinero. Un estudio recientemente realizado por Cisco [3] entre estudiantes y jóvenes profesionistas arrojó que este segmento valora la libertad más que el salario. ¿Libertad de qué? Principalmente la libertad de usar redes sociales, escoger tu computadora/teléfono o de trabajar fuera de la oficina.

Conclusión

Referencias: [1] S. Ludwig. “Peter Thiel pays kids to drop out of college”, Venture Beat. http://swgu.ru/sg3411 [2] E. Camacho. “¿Y dónde está el talento?”. http://swgu.ru/sg3412 [3] “Cisco Connected World Technology Report”. http://swgu.ru/sg3413 [4] SG Talento. http://talento.sg.com.mx

.BIO Pedro Galván Kondo es director y socio fundador de Software Guru, y es un apasionado del desarrollo de capital humano. @pedrogk

53

Software Guru

Como bien comenta Erick Camacho en su post “¿Y donde está el talento?”[2], los desarrolladores de software experimentados no están buscando ofertas de empleo en bolsas de trabajo. Las bolsas de trabajo tradicionales son un buen mecanismo para promover posiciones “entry level” donde buscas recién graduados, o personas que buscan un cambio de carrera, pero si buscas perfiles con mayor especialización, debes utilizar otras herramientas.

Sé Flexibe

www.sg.com.mx |

Universidades

.CONTENIDO PATROCINADO

SoftMTY 2011 se lleva a cabo con gran éxito

C

on el tema central de: “TI como habilitador de la Agilidad Empresarial”, los días 26 y 27 de octubre se llevó a cabo con gran éxito el congreso SoftMty 2011 en la ciudad de Monterrey, Nuevo León. Este fue un evento dirigido a directivos de áreas de Tecnologías de Información, con el objetivo de difundir tendencias y mejores prácticas internacionales para mejorar la competitividad tanto de los corporativos “usuarios” de tecnologías de información, como de las empresas locales “proveedoras” de estos servicios.

SoftMty 2011 fue presentado por el Consejo de Software de Nuevo León (CSoftMty) y coorganizado por Software Guru. CsoftMty es una alianza entre universidades, empresas y gobierno, que busca el crecimiento económico con calidad de vida vía la innovación.

Los participantes de SoftMty 2011 tuvieron oportunidad de asistir a pláticas de destacados conferencistas y analistas internacionales, tales como: Khalid Kark, Director de Investigación en Forrester Research, Gabe Piccoli, Consultor Senior en Cutter Consortium; Bob Benson, Fellow en Cutter Consortium; y David Chappell, uno de los conferencistas independientes más reconocidos en el ámbito de las TI. Los paneles de discusión brindaron una excelente oportunidad para que algunos de los CIOs más experimentados y respetados de nuestro país pudieran compartir su experiencia y perspectiva. En estos páneles se contó con la participación de: Claudio Vivián (Grupo ICA), Felipe Villegas (DHL Express), Daniel Ortega (Merck), Alejandro Ramos (Actinver), Guillermo Güémez (Banorte), Víctor López (Homex) quienes fueron complementados con moderadores y analistas de lujo: Ricardo Zermeño, Director de Select; Edgar Fierro, Director en México de IDC; y Luke Bujarski, Analista Sr. en Nearshore Americas.

Además de los valiosos contenidos de las conferencias, SoftMty 2011 contribuyó a generar relaciones de negocios entre los asistentes que potenciarán el crecimiento de nuestra industria, ya que reunió tanto a CIOs y líderes de organizaciones de TI, como a importantes proveedores y representantes clave de la industria.

En SoftMty estuvieron presentes como patrocinadores algunas de las empresas más importantes del ecosistema de las TI en esta región, tales como: • Softtek • Grupo Assa • Huawei • IBM • Mexico IT • EISEI • MexicoFirst • Protektnet • NYCE • Consiss • RedIT • Dimtec También quedó claro el compromiso con el desarrollo de capital humano que tienen las principales instituciones educativas de Monterrey, tales como: • Universidad Regiomontana • Universidad Autónoma de Nuevo León • Tecnológico de Monterrey SoftMty 2011 fue posible gracias al apoyo de Secretaría de Economía, por medio del programa Prosoft, así como al apoyo del Gobierno del Estado de Nuevo León.

El Consejo de Software de Nuevo León ya está planeando la edición 2012 de este congreso, el cual sin duda continuará con el éxito obtenido en esta ocasión.

Encuentra mayor información sobre el Consejo de Software de Nuevo León en www.csoftmty.org 54

Directorio Alpha Consultoría

http://www.alpha-consultoria.com

Pág. 43

App Studios

Pág. 33

http://appstudios.mx

CsoftMty

Pág. 54

http://www.csoftmty.org

Extend Solutions

http://www.extend.com.mx

Pág. 49

Huawei

Pág. 4F

http://www.huawei.com/enterprise

Infotec

Pág. 09

http://infotec.com.mx

Microsoft

http://msdn.microsoft.com/es-mx

Pág. 2F

ProNatura

Pág. 3F

http://www.pronatura.org.mx

Qualtop

Pág. 35

http://www.qualtop.com

SG Talento

Pág. 01

http://talento.sg.com.mx

SG Campus

Pág. 31

http://www.sgcampus.com.mx

TENEMOS UN ESPACIO RESERVADO PARA TI SG se distribuye de manera impresa en la República Mexicana, y de manera digital llega a más de 25mil lectores de habla hispana. El anuncio en la revista digital cuenta con hiperliga directa a tu sitio web, lo que te dará la oportunidad de acercarte a nuevos clientes.

“Es una gran oportunidad participar con Software Guru, pues comprobamos que es un medio efectivo.”

-Novalys Latinoamérica Contáctanos en el (55) 5239.5502 o en publicidad@sg.com.mx

.TECNOLOGÍA Gadgets

SPHERO

LIBRATONE LIVE

Para continuar con la temática de esta edición de SG les presentamos Sphero, una pelota robótica que puedes controlar desde tu smartphone. Así es, simplemente lo prendes y puedes jugar con el desde apps en tu smartphone. Entre las opciones de juegos está un simulador de manejo y un juego de golf virtual.

Próximamente también se abrirá la posibilidad a terceros de desarrollar apps que interactúen con Sphero. Un buen detalle es que el Sphero puede cambiar de color, lo cual es útil cuando estás jugando con varias personas. Se puede controlar desde iPhone, iPod touch y Android. http://gosphero.com

La compañía danesa Libratone lanzó la línea de bocinas Live. Éstas son bocinas portátiles e inalámbricas que funcionan con la tecnología AirPlay. Además de su elegante y vistoso diseño, estas bocinas ofrecen un gran desempeño en sonido. Utilizan una tecnología denominada FullRoom para que el sonido no rebote en las paredes. Adicionalmente, por medio de una app para iPhone/iPod puedes proveer información sobre la ubicación de las bocinas y la app las calibra vía AirPlay para optimizar el sonido. http://libratone.com/live

Pelota robótica

Sonido con estilo

JAWBONE UP

Asistente para mejorar tu salud UP es un sistema que consiste de una pulsera acompañada de una app para iPhone, que registra tu actividad física, patrones de sueño y hábitos alimenticios para ayudarte a tener una vida más saludable. El sensor de movimiento está en la pulsera, que es resistente al agua, así que puedes traerla puesta todo el día, incluso para bañarte. UP monitorea tu actividad física (pasos, distancia recorrida, ritmo de movimiento), patrones de sueño (horas dormidas, profundidad del sueño, calidad del descanso) y alimentación registrando qué y cuando comes. http://jawbone.com/up

SONY

Nuevos modelos VAIO Para cerrar el año, Sony VAIO actualiza su línea de computadoras personales, con modelos dirigidos a distintas audiencias.

A los lectores de SG posiblemente les atraigan los modelos de la serie S que está dirigida a profesionistas, brindando alto desempeño y confiabilidad. O si lo que buscas es una laptop muy ligera sin escatimar desempeño, está la serie Z con pantalla de 13.1 pulgadas, procesador i5-2410M, 6 GB de RAM y disco de estado sólido. www.sonystyle.com.mx

56