SG Software Guru #48

REVISIÓN DEL LENGUAJE SWIFT

PAG. 16

—

LA ÉTICA EN EL HACKING

PAG. 32

—

ARQUITECTURA PULL VS PUSH

PAG. 38

—

NO.48

CONOCIMIENTO EN PRÁCTICA www.sg.com.mx

REPORTAJE

INDUSTRIA DE SOFTWARE EN ARGENTINA PAG. 12

D A D I L I G A IVEL DE

N E T N E I U EL SIG

Imagen cortesía de Federation Aeronautique Internationale

SG.COM.MX

001

NO.48

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

EN PORTADA

DEVOPS 020

El movimiento DevOps estﾃ｡ impactando la forma en la que construimos y entregamos sistemas de informaciﾃｳn. Conoce quﾃｩ es, cuales son sus fundamentos y principales mitos.

002

SG.48

CONTENIDO

I

Necesitas a un CTO

T

P

INDUSTRIA Y EMPRESAS 010

HERRAMIENTAS Y TECNOLOGÍAS

Radar

006

Tutorial: Swift

016

E

ESTRATEGIA DE TI

Gestión del conocimiento

C

PRÁCTICAS

H

COLUMNAS

Arquitectura: Push vs Pull

038

Tendencias en software

007

UX: Talleres colaborativos

040

Tejiendo nuestra red

008

Prueba de software

036

Programación: Sistemas distribuidos

042 Programar es un modo de vida

050

Métodos: El algoritmo del éxito

046

Ágil: Efectividad del negocio

048

028

F

V

VOCES

Entrevista con Dr. Lino Barañao

012

Calidad no es Testing ni Certificaciones

026

Más allá del Software

030

HUMANOS DESPUÉS DE TODO

Carrera: Hacking y ética

O

O

032

EN CADA NÚMERO

Noticias y eventos

005

Hardware

054

Humor

055

Biblioteca

056

FUNDAMENTOS

Árboles binarios

052

LA INDUSTRIA DE SOFTWARE EN ARGENTINA 012

SG.COM.MX

003

O

EDITORIAL

Todo es cuestión de colaboración

DevOps esto, DevOps lo otro ... pero … ¿qué es DevOps? La verdad es que antes de hacer este número, nosotros tampoco teníamos una idea clara de lo que es DevOps, solo sabíamos que en todos lados lo escuchábamos así que teníamos que estudiarlo y compartirte nuestros hallazgos. Esperamos que el conjunto de artículos que presentamos en este reportaje de portada te ayude a también tener más claro en qué consiste este movimiento.

En este número de SG estamos retomando algo que no hacíamos desde hace mucho tiempo: reportajes sobre la industria de software en alguna región. En esta ocasión tocó Argentina, que nos sorprendió con todo lo que está haciendo, especialmente para desarrollar nuevo talento. En futuros números de SG planeamos incluir reportajes similares sobre la industria de software en otros países.

Continuando la tendencia de los últimos números de SG, seguimos expandiendo nuestro alcance editorial, incluyendo desde contenidos sobre estrategia y emprendimiento hasta artículos técnicos avanzados. Confiamos en que encontrarás contenido valioso, independientemente de si eres un directivo, un gerente, un programador o un estudiante.

El siguiente número de SG contendrá nuestra ya tradicional estudio de salarios. Te pedimos que nos ayudes participando en la encuesta. Pronto publicaremos los detalles en http://sg.com.mx

Equipo Editorial Software Guru

SG es posible gracias a la colaboración de Dirección Editorial Pedro Galván | Dirección de Operaciones Mara Ruvalcaba | Dirección Comercial Claudia Perea Coordinación Editorial Susana Tamayo | Arte y Diseño Oscar Sámano | Suscripciones Mariana Torres Consejo Editorial: Luis Daniel Soto | Gunnar Wolf | Luis Vinicio León | Hanna Oktaba Ariel Jatuff | Emilio Osorio | Gloria Quintanilla | Jorge Valdés COLABORADORES EN ESTA EDICIÓN Manuel Morato, José María Louzao, Lino Barañao, Tomás Balderas, Patrick Debois, Israel Ortega, Raúl Martínez, Víctor Hernández, Francisco Lino, Carlos Martínez, Misael León, Pedro Ramírez, Marco A. Dorantes, Masa K. Maeda, Manuel López Michelone.

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

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

004

SG.48

NOTICIAS

O

Noticias EMC FORUM MEXICO CITY 2015

1

KLOUD CAMP 2015

Kloud Camp, el evento educativo sobre Cloud Computing más importante en América Latina, se llevó a cabo por quinta ocasión en la Ciudad de México. En esta edición bajo el título “You are in the Kloud, Bring your Things”, el foro líder en Cloud se centró en cuál será el futuro del crimen y la seguridad en un mundo conectado, las ventajas competitivas que pueden tener los negocios que utilizan tecnologías Cloud, la alta seguridad con la que cuentan el cloud privado y público, cómo los emprendedores potencializan su negocio a través de cualquiera de estas dos aplicaciones y cómo la innovación y la Nube aplicada traerán consigo eficiencia gubernamental.

IBM DEVELOPER CONNECT

2

El pasado 26 de agosto se realizó la edición 2015 del EMC Forum Mexico City con más de 30 conferencias simultáneas y la participación de más de 1,500 asistentes. A lo largo del evento, EMC dio a conocer la visión que tiene con respecto a los temas de Nube, Big Data, Flash, Infraestructura Convergente y Seguridad en el marco de la Federación de empresas que la componen. Este año, la conferencia principal corrió a cargo de Vic Bhagat, Vicepresidente Ejecutivo de Enterprise Business Solutions y CIO de EMC Corporation, quien recalcó la importancia de redefinir las TI para aprovechar la era digital y potenciar los negocios.

3 DEV DAY 4 WOMEN

IBM se quitó la corbata y organizó el pasado 20 de agosto en Ciudad de México el Developer Connect @Night, un evento dirigido a audiencia técnica en el que se platicó sobre temas como cómputo cognitivo, design thinking, e internet de las cosas. Destacó la realización de un reto de internet de las cosas en el que los participantes tuvieron 2 horas para conectar una bicicleta estacionaria a una Raspberry Pi y luego a IBM Bluemix para calcular la distancia recorrida y mostrarla en un mapa.

4

Más de 180 mujeres apasionadas de la tecnología y el desarrollo de software fueron protagonistas de la segunda edición del #DevDay4W en la ciudad de México. El evento, auspiciado por Intel Software y organizado por Software Guru, logró reunir a estudiantes, emprendedoras, profesionistas y líderes de TI en un solo lugar con el objetivo de compartir experiencias, conocimiento y vinculación. “Para Software Guru es fundamental apoyar a las mujeres desarrolladoras de software y es un orgullo haber logrado reunir a tantas mujeres, así como contar con la participación de tantas comunidades, organizaciones y líderes que apoyan a mujeres desarrolladoras en México“, comentó Mara Ruvalcaba, directora de operaciones de SG.

SG.COM.MX

005

O

RADAR

2

General Electric iniciará su incursión como proveedor de servicios de cómputo en la nube con GE Predix Cloud, un servicio para almacenamiento y analítica de datos diseñado especialmente para trabajar con datos industriales (es decir, los que generan sensores y maquinaria). La información capturada y analizada por GE Predix podrá ser aprovechada por los desarrolladores para crear aplicaciones que mejoren la eficiencia y productividad de estas máquinas. GE Predix también incluye un catálogo de microservicios prehechos para escenarios comunes en industrias como la de manufactura, transporte y salud. La plataforma actualmente se encuentra disponible para usuarios selectos y en enero de 2016 estará disponible para el público en general. Que una de las empresas ícono de la industria de manufactura y bienes tangibles esté entrando con fuerza a la industria de software nos hace reflexionar sobre aquello de que “el software se está comiendo al mundo”. Como dice Jeff Immelt, CEO de GE: “Aunque anoche te hayas ido a acostar como una empresa industrial, hoy te levantas como una empresa de software y analítica.”

Desde su creación hace más de 20 años, Erlang ha sido reconocido por su alto desempeño y estabilidad. Sin embargo, su adopción se ha visto frenada por ser un lenguaje de nicho (fue originalmente creado para programar switches telefónicos), con una sintaxis poco común. Es ahí donde entra Elixir, un lenguaje de reciente creación (2012) que se ejecuta en la máquina virtual de Erlang compartiendo sus bondades de desempeño y estabilidad, pero ofrece sintaxis amigable y productiva, inspirada en el lenguaje Ruby. Por su parte, Phoenix viene a ser el Rails de Elixir, es decir un framework para desarrollo de aplicaciones basado en el patrón MVC. En resumen, Elixir+Phoenix promete el poder de Erlang con la facilidad y productividad de Ruby on Rails.

Expertos como Dave Thomas han etiquetado a Elixir como “el próximo lenguaje de desarrollo importante” así que agrégalo a tu lista de cosas por aprender.

https://www.gesoftware.com/predix

http://www.phoenixframework.org

1 GE PREDIX

3

006

ELIXIR + PHOENIX

REALSENSE

4

FACEBOOK: REACT, PARSE Y RELAY

Aunque Microsoft había sido pionero en el espacio de las cámaras con sensor 3D (ej. Kinect), hoy en día la empresa más activa en este espacio sin duda alguna es Intel, con su tecnología RealSense. Durante este año vimos los primeros usos y prototipos de estas cámaras, que permiten a las computadoras visualizar el mundo de forma similar a como lo hacemos los humanos.

Google recientemente dio a conocer Project Tango, un smartphone con RealSense que se utiliza para mapear espacios 3D. En 2016 veremos esta tecnología en laptops, tablets y dispositivos de realidad virtual. Así que es buena idea comenzar a imaginar cómo podrías sacarle provecho a esta tecnología. Por el momento, los SDK para RealSense solo están disponibles para Windows, pero antes de que termine el año se espera que también se hagan disponibles SDKs para OS X, Linux, Android e incluso Scratch.

Facebook ha estado muy activo en los últimos meses mejorando y empujando su oferta de tecnologías para desarrolladores de software. En el campo del front end, React ha tomado bastante fuerza y vemos que en 2016 podría amenazar a Angular como la tecnología “del momento” para el front end. Recordemos que además de crear front-end web, con React Native también es posible crear aplicaciones móviles nativas de alto desempeño tanto para iOS como Android (el soporte para Android fue liberado en septiembre 2015). React también se ve fortalecido con la liberación como technical preview del Relay Data Framework, un framework declarativo para manejo de datos en aplicaciones. En el backend, Facebook sigue madurando e impulsando su plataforma Parse, a la que recientemente agregó nuevos SDK para escenarios de tipo Internet de las cosas, soportando conectividad desde Arduino, Raspberry Pi, e Intel Edison, entre otros. En resumen, te recomendamos que eches un vistazo a las herramientas y plataformas que Facebook ofrece a desarrolladores, ya que traen bastante empuje y una oferta interesante.

https://software.intel.com/en-us/realsense

https://code.facebook.com

SG.48

TENDENCIAS EN SOFTWARE

C

Negocios Verdaderamente Inteligentes INTELIGENCIA DE GRAN ESCALA AL ALCANCE DE TODOS — Por Luis Daniel Soto Maldonado

“El operar un negocio a ciegas es cada vez más injustificado”.

Una cadena de restaurantes norteamericana con 500 sucursales utiliza a diario un producto de movimiento de datos para transferir las información a un data warehouse. Esa información permite conocer la realidad del negocio al instante y empujar información comparativa a cada sucursal. Están implementando modelos predictivos que reducirán costo e identifican las mejores oportunidades.

A primera impresión, este parece ser un caso de estudio innovador de inicios del 2000. Desde ese entonces muchas empresas tenían la visión de hacer algo similar, pero muy pocas tenían la capacidad para poder llevar a cabo un proyecto de esta magnitud.

Adelantemos el calendario al 2015 y veamos el sueño haciéndose realidad.

Analicemos los factores que lo hacen posible: Infraestructura elástica. Hace una década, la inversión requerida era quizás prohibitiva: La infraestructura de cómputo tendría que tener capacidad para operar por 3-5 años, implicando una inversión inicial de varias decenas de miles de dólares. En comparación, hoy un data warehouse en la nube puede iniciar a veinticinco centavos de dólar por hora [2] y crecer conforme el negocio lo requiera.

Integración de datos. Para consolidar fuentes de datos, los vendedores de herramientas ETL (Extract, transform and load) ofrecían soluciones de integración de datos igualmente costosas. Hoy es posible mover los datos a la nube de forma casi gratuita o comprar soluciones en demanda. Por ejemplo, Attunity Cloudbeam permite mantener sincronizada una copia en la nube teniendo un impacto de desempeño menor al 5%. Productos similares ofrecen la misma funcionalidad para ambientes Hadoop o mainframes.

Inteligencia de negocio. Después de una década de Business Intelligence, menos del 30% de los empleados tienen acceso a dichas capacidades. El costo de una solución de BI era típicamente de varios miles de dolares por usuario, y hoy se ha reducido en alrededor de 75%. Además de que existe una gran variedad de herramientas que permiten el autoservicio para transformar, combinar y visualizar fuentes de datos de forma visual. El uso bajo demanda para proyectos de menor duración cambia las reglas del juego.

Luis Daniel Soto (@luisdans / @luisdanielsoto) trabaja en Amazon Web Services, enfocado en el

Analítica avanzada y streaming. NoSQL y Hadoop ofrecen nuevos mecanismos de análisis y procesamiento de datos en tiempo casi real. Pero si su empresa no tiene esas habilidades, el tiempo de integración y costo podría ser tan alto o mayor que software empresarial relacional.

Software como Atigeo xPatterns integra software libre para instantáneamente implementar análisis predictivo en una variedad de modelos disponibles.

desarrollo global de negocios para Big Data e Inteligencia de negocios. sotols@amazon.com

Conclusión La calidad y captura de datos, mantenimiento de los mismos y uso efectivo de la información para desarrollar el modelo de negocio continúan siendo retos complejos; la explosión de datos apenas inicia. Con la nube y tecnología integrada a menores costos, el operar un negocio a ciegas es cada vez más injustificado.

Referencias [1] “Big Data at Dickey’s Barbecue Pit”. Forbes, junio 2015. http://swgu.ru/q4 [2] Amazon Redshift Pricing. https://aws.amazon.com/redshift/pricing/ [3] Attunity CloudBeam. http://swgu.ru/q5 [4] TIBCO Jaspersoft Reporting for AWS. http://swgu.ru/q6 [5] xPatterns Connect. http://swgu.ru/q7

SG.COM.MX

007

C

TEJIENDO NUESTRA RED

Adiós ISO/IEC JTC1 SC7 WG24 DESTRABANDO LAS ABREVIATURAS — Por Hanna Oktaba

La Dra. Hanna Oktaba es profesora de la UNAM y su objetivo principal es generar conocimiento a través de la creación y promoción de estándares.

La Organización Internacional de Estándares (ISO) y la Comisión Internacional Electrotécnica (IEC) son dos organismos dedicados a la definición de estándares internacionales. Los países miembros del grupo de ISO o IEC participan en el desarrollo de estándares internacionales a través de comités técnicos establecidos por cada una de estas organizaciones. Las propuestas de estándares internacionales que se reciben por los comités técnicos se envían a los representantes de cada país miembro para su revisión y aprobación. Una propuesta requiere tener una aprobación de al menos el 75% de los países miembros para ser publicada como estándar internacional.

@hannaoktaba

Los estándares de Tecnología de Información (TI) al ser de interés mutuo entre ISO e IEC llevaron a la creación del comité técnico conjunto Joint Technical Comeetee (JTC1) dedicado al área de TI. Dentro de éste, se formó el subcomité SC7 designado para generación de estándares para la Ingeniería de Software y Sistemas. Este subcomité está organizado por grupos de trabajo Working Group (WG) que se encargan de un estándar en particular.

En junio de 2005 ISO/IEC JTC1 SC7 Software and System Engineering reconoció que sus estándares no fueron creados para los proyectos y organizaciones pequeñas, por lo que se creó un grupo de trabajo WG 24 específico para definir procesos de software para Very Small Entities (VSE), empresas, organizaciones o proyectos de 1-25 personas. Una de las primeras tareas del grupo fue averiguar si en algún país se hizo una propuesta dirigida a este sector.

Mi aventura con WG24 Un colega brasileño, Marcelo Pessoa, miembro de la WG24, quien conoció a MoProSoft, nos preguntó si podríamos enviar la norma mexicana para ser revisada por el grupo.

008

SG.48

Coincidió que en octubre de 2005 presentamos a MoProSoft, EvalProSoft y los resultados de Pruebas Controladas en el Workshop of Process Improvement in Small Settings convocado por el Software Engineering Institute (SEI) en su sede de Pittsburgh.

En este evento coincidimos con Claude Laporte de Canadá, editor del WG24, quien volvió a insistir en que presentáramos MoProSoft ante el grupo.

En mayo de 2006 la delegación de México asistió por primera vez en Tailandia a la reunión plenaria de ISO/ IEC JTC1 SC7 Software and System Engineering para presentar MoProSoft ante el WG24. La presentación formal estuvo a cargo de Ana Isabel Vázquez Urbina y, para nuestra gran sorpresa, en votación unánime los representantes de Tailandia, EUA, India, Irlanda, Bélgica, Finlandia, Luxemburgo, Canadá, Nueva Zelanda y Corea decidieron tomar la norma mexicana como base para su trabajo. Jorge Palacios grabó un video que documenta este acontecimiento [1].

En la siguiente reunión de ISO/IEC JTC1 SC7 WG24 en Luxemburgo, en octubre de 2006, se tomó la decisión estratégica de presentar MoProSoft como estándar internacional en tres partes, es decir en grupos de procesos divididos por las tres capas del modelo. Cada una de las capas pertenecería al Grupo de Perfiles Genéricos. El primer perfil seleccionado para ser revisado y aprobado por WG24, llamado posteriormente como Perfil Básico, correspondió a los procesos de Administración de Proyectos Específicos y de Desarrollo y Mantenimiento de Software de la capa de Operación de MoProSoft.

El Perfil Básico fue una primera guía de procesos publicada dentro de la colección de documentos que conforman el nuevo estándar ISO/IEC 29110 dirigido a pequeñas organizaciones de desarrollo de software, cuyas partes se listan a continuación.

TEJIENDO NUESTRA RED

ISO/IEC 29110 Software engineering — Lifecycle profiles for Very Small Entities (VSEs): Part 1: OverviewPart 2: Framework and taxonomy Part 3: Assessment guide Part 4-1: Profile Specifications: Generic profile group Part 5-1-2: Management and engineering guide: Generic profile group: Basic profile El Perfil Básico está incluido como Parte 5-1-2, el 1 significa que pertenece al primer grupo de perfiles genéricos, basados en MoProSoft, y el 2 es su número consecutivo. Las editoras de las partes 4-1 y 5-1-2 fueron Ana Isabel Vázquez, Blanca Gil, Claudia González y Hanna Oktaba.

C

¿Por qué fue y sigue siendo importante la participación de México en la estandarización internacional?

• Se logró ubicar a MoProSoft a la cabeza de los estándares internacionales para VSEs de la industria de software.

• Se demostró que “lo hecho en México, está bien hecho” y no solo eso, sino que puede ser de calidad internacional.

• Se ha logrado una aceptación de una norma mexicana como aporte al estándar internacional lo que demuestra que estamos a la vanguardia en la Ingeniería de Software.

A los que todavía no conocen o no han entendido el valor de MoProSoft les invito a ver el video en el cual lo traté de explicar con manzanitas [3].

Mi despedida de WG24 El Perfil Básico se publicó en mayo de 2011 y para promover su uso entre las VSEs se solicitó al ISO su disponibilidad gratuita [2].

Un año más tarde se creó un perfil más elemental que el Básico, llamado Entry, el cual tiene asignado el número 1 dentro del grupo de perfiles genéricos y está dirigido a las organizaciones de reciente creación y el tamaño todavía más reducido. El estándar del Perfil Básico se recomienda para las organizaciones pequeñas que pueden ser empresas, departamentos o proyectos de hasta 25 personas. La guía se aplica en proyectos de desarrollo de software. El proyecto puede ser para cumplir un contrato externo o interno. El contrato interno no tiene que ser explícito entre el equipo del proyecto y sus clientes.

Después de casi 10 años dedicados al trabajo en WG24 llegó la hora de decir adiós. Ustedes saben que tengo un“nuevo amor” que es mi “hija” más chiquita KUALI-BEH integrada al estándar ESSENCE de OMG, la cual requiere de mi mayor atención.

El WG24 me despidió con cariño y me llevo muy gratos recuerdos de este esfuerzo y muchas relaciones con gente muy apasionada. Les deseo que tengan éxito en esa apertura de los organismos de estandarización para facilitar los negocios también a los peques y no solo a los grandes. La Delegación Mexicana ante WG24 queda en las muy buenas manos de Claudia González, Blanca Gil y Salvador Sánchez.

Referencias

La diferencia entre los procesos de Perfil Básico y los de la capa de Operación de MoProSoft es mínima. Las organizaciones que tienen implementado MoProSoft a nivel 2 están cubriendo prácticamente el Perfil Básico. Este último, como está enfocado en las prácticas de un proyecto de software aislado, tiene algunas tareas que en MoProSoft se delegan a otros procesos. Por ejemplo, a falta de la base de conocimiento de la organización se propone el uso de un repositorio local del proyecto con ciertas reglas de su manejo. Algunos productos de trabajo sufrieron modificaciones a raíz de los comentarios del grupo y su apego a otros estándares ISO/IEC ya existentes, pero en general se parecen mucho.

[1] Miembros de WG24 opinando sobre MoProSoft. https://youtu.be/wu4vBfOkSVI [2] Perfil básico gratis: http://standards.iso.org/ittf/PubliclyAvailableStandards/c051153_ ISO_IEC_29110-5-1-2_2011.zip [3] MoProSoft explicado: https://youtu.be/3Cn_2bKAV4Q

Del grupo de perfiles genéricos basados en MoProSoft se está preparando el Perfil de Gestión Organizacional que incluirá los procesos de Gestión de Negocio y los de Gestión de Procesos, Recursos y Proyectos. Por supuesto estos procesos sufrirán modificaciones con respecto a sus versiones originales debido a las lecciones aprendidas de su uso y las aportaciones de la comunidad internacional.

Además, a la comunidad de sistemas les gustó el trabajo que hemos hecho y ya se ha publicado el Perfil Básico para el desarrollo de Sistemas. Los que trabajan el estándar de servicios también están viendo la necesidad de generar una versión para VSEs y los “agilistas” están preparando la modalidad ágil del Perfil Básico.

SG.COM.MX

009

I

EMPRENDIMIENTO

Necesitas a un CTO para Emprender en Tecnología —

Por Manuel Morato

Este artículo fue originalmente publicado por Manuel en su blog personal. Fue editado y publicado en estas páginas con su permiso. La versión original está disponible en: https://medium.com/@ememorato/necesitas-a-un-cto-para-emprender-en-tecnología-cf2ec86dc312

Emprender significa muchas cosas: abrir una tintorería, una agencia de autos, una nueva marca de productos de limpieza ecológicos, una escuela, una ONG, o crear un alimento fortificado con proteína para cocodrilos (si eres tan hipster). Sin embargo, conforme continuamos sumergiéndonos en la modernidad tecnológica del siglo XXI, emprender significa cada vez más y más romper esquemas y paradigmas establecidos aprovechando precisamente eso: la tecnología.

Tecnología: la versión 2.0 de inventar la rueda La tecnología es altamente atractiva para un emprendedor porque representa la herramienta perfecta para generar destrucción creativa. Destrucción creativa, según el economista austriaco Joseph Schumpeter, se refiere a: “el avance tecnológico que destruye lo existente para crear lo nuevo”. Es lo que hace el internet con los periódicos impresos, o lo que está haciendo Spotify con los CDs (mas no con los viniles hipsters :P), o lo que ha hecho Dropbox con las memorias USB. Es quizá lo que Uber está haciendo con los taxis (es pronto para saber qué va a pasar con eso).

Cada vez más emprendedores en todo el mundo están apostando por generar nuevas tecnologías que revolucionen la manera actual en la que se hacen las cosas. Por todo esto también es que existen lugares míticos como Silicon Valley, donde el presente y el futuro son cotidianamente reinventados por emprendedores que apuestan por innovación a través de nuevas tecnologías.

Una de las tecnologías más atractivas debido a su bajo costo y amplia versatilidad, es el software. Con software puedes tener impacto en el mundo real desde tu computadora, estés donde estés, y lo único que necesitas es una computadora conectada a internet, la actitud correcta y las habilidades necesarias para programar y hablar con cierta fluidez el lenguaje de las computadoras y el internetz.

CTO: el/la chef que necesita tu nueva empresa tecnológica Un error común de muchos emprendedores en México es crear empresas basadas en software y/o hardware que no incluyen en el equipo a un co-fundador técnico o CTO (Chief Technology Officer). El CTO típicamente es una persona con una fuerte base de conocimientos técnicos y/o científicos que ha desarrollado

ejemplar pasión y habilidades para manejar la tecnología que forma el núcleo del nuevo negocio en cuestión, y que además sirve como complemento natural al CEO o director general.

Tal como comenta Alberto Padilla, uno de los emprendedores más reconocidos en el ecosistema tecnológico en México: “arrancar una empresa de base tecnológica sin un CTO en el equipo es como arrancar un restaurante gourmet sin un chef”. Quienes caen en este error, usualmente subcontratan el desarrollo de su producto, ya sea con alguna agencia de desarrollo o con programadores freelancers.

Piensa en la analogía del restaurant nuevamente: hacer esto es como pagarle a una agencia de chefs o a un chef freelance para que cocine los platillos para los paladares exigentes de tus clientes.

Más allá del alto costo que puede significar subcontratar a un CTO o a un equipo externo para que desarrolle tu producto, el problema es que una persona o equipo externo no va a dedicar la misma atención que alguien interno. Desarrollar un producto tecnológico exitoso es un proceso sumamente complejo que supone estar ajustando detalles casi obsesivamente durante largos periodos de tiempo, buscando esa fórmula cuasi-perfecta pero sutil que logrará enamorar a los usuarios.

Si tienes a un(a) co-fundador(a) técnico(a), el equipo de desarrollo será parte de tu empresa y compartirá la visión del equipo fundador.

Conclusión Subcontratar desarrollo de software puede funcionar en ciertos casos, como cuando necesitas algo muy específico y a corto plazo. O bien cuando la parte tecnológica no es el componente central de tu propuesta de valor. Si lo que haces es vender banquetes para bodas, tener un buen sitio web es una herramienta de ventas poderosa, pero el núcleo de tu negocio siguen siendo los banquetes así que tiene sentido subcontratar a desarrolladores externos para hacer tu sitio.

Pero si tu negocio es un nuevo algoritmo de búsquedas en internet, o una red social basada en una aplicación web, o una herramienta de análisis de datos para toma de decisiones gerenciales, entonces necesitas formar un equipo fundador que contemple a una persona capaz de construir un equipo tecnológico y de guiar el proceso de poder construir esa herramienta que hará la diferencia entre el éxito o fracaso de tu empresa.

Manuel Morato (@ememorato) es cofundador de Dev.F., la más grande escuela de hackers en América Latina.

010

SG.48

CONTENIDO PATROCINADO

S

ADOPTANDO SOA DE FORMA EXITOSA

El ámbito de las arquitecturas orientadas a servicios ha crecido, evolucionado y madurado significativamente en los últimos 10 años, generando una variedad de productos de virtualización, seguridad, gobierno, intermediación, monitoreo, despliegue, aceleración, movilidad, computo en la nube, big data, entre otros.

El objetivo principal de Itehl Consulting, ha sido y seguirá siendo apoyar a nuestros clientes en la correcta selección, diseño, adopción y gobierno de estas innovaciones tecnológicas de acuerdo a sus desafíos y objetivos organizacionales para garantizar el máximo retorno de esa inversión.

De acuerdo con Jorge Heredia, CEO de Itehl Consulting, los principales desafíos que enfrentan las organizaciones para adoptar SOA son: resistencia al cambio en el paradigma de la orientación a servicios; falta de un mapa de ruta claro y alineado a los objetivos tácticos y estratégicos; ausencia de una cultura organizacional para la centralización y reutilización de los servicios. Otra situación común que comenta Jorge es que las empresas se enfoquen sólo en el aspecto tecnológico, dejando de lado temas como gobernabilidad, estandarización y diseño arquitectónico.

ITEHL Consulting ha diseñado una solución integral para gestionar estos desafíos bajo su framework “ITEHL SOA Enterprise Immersion”, el cual involucra actividades de: capacitación, valoración, planeación, modelo de gobierno, metodología, diseño de arquitectura, e implementación, todo ello soportado por monitoreo y mentoring continuo de parte de Itehl Consulting.

“El framework provee un servicio integral y especializado para que nuestros clientes adopten una cultura SOA para la correcta valoración, gobierno, adopción, diseño e implementación de las soluciones tecnológicas que impulsan el crecimiento y competitividad empresarial”, agrega Jorge Heredia.

Caso de éxito: Unipago S.A. Uno de los clientes más recientes de Itehl Consulting es Unipago S.A., empresa en República Dominicana dedicada a procesar las afiliaciones y pagos del sistema de seguridad social del país.

Unipago se planteó el objetivo de renovar la solución tecnológica que soporta el core de su operación y superar los desafíos actuales de redundancia de aplicaciones e información, costos elevados de integración y falta de agilidad organizacional. Decidieron adoptar una arquitectura SOA y contrataron los servicios de Itehl Consulting para asesorarlos de manera integral.

El primer paso fue capacitar al personal de TI. Una vez concluida la capacitación ITEHL Consulting llevó a cabo un proceso de valoración SOA para determinar el nivel de madurez actual de Unipago y definir en base a esto un mapa de ruta a 3 años con una secuencia lógica y organizada para la adopción. Posteriormente se definió el sistema de gobierno SOA e institucionalizó la oficina de gobierno responsable de mantener, controlar y medir la adopción SOA. ITEHL Consulting también apoyó en el diseño de las distintas vistas arquitectónicas, estándares y patrones de diseño, así como en la definición de la metodología para el ciclo de vida de los servicios.

En la actualidad, Unipago cuenta con 70 servicios reutilizables.

El personal de negocio y de TI han madurado significativamente la forma como especifican, analizan, construyen y reutilizan los servicios, lo cual ha agilizado y hecho más eficiente la operación de su negocio.

Itehl Consulting continúa comprometido con mejorar la productividad y eficiencia empresarial de sus clientes.

Conoce más en http://www.itehl.com

La compañía, con casa matriz en Bogotá, Colombia y oficinas en México, Ecuador y Chile, también asesora a las organizaciones en la adopción de las mejores prácticas para el diseño e implementación de arquitecturas de TI alineadas con las necesidades del negocio.

Adicionalmente, Itehl Consulting ofrece cursos certificados para el desarrollo de competencias del personal de TI en los diferentes roles SOA tales como: Analista, Arquitecto, Especialista en Gobierno, Desarrollador JAVA/.NET, Especialista en Seguridad.

Estos cursos los ofrece tanto en modalidades presenciales como online, además de tener la posibilidad de ofrecer cursos personalizados a empresas. Por medio de esta variedad de modalidades, Itehl puede satisfacer las distintas necesidades del mercado respetando siempre la calidad.

Jorge Heredia. CEO de Itehl Consulting.

SG.COM.MX

011

I

REPORTAJE

La Industria de Software en Argentina cámara específica para el sector de software (a diferencia de otros países donde el software se subordina al sector más amplio de TIC) y que existe desde hace más de 30 años. CESSI representa a más de 600 empresas de software, que en conjunto, comprenden más de 80% de los ingresos del sector y más de 80% de los empleos.

A lo largo de la última década hemos visto cómo distintos países de Latinoamérica se embarcan en iniciativas para impulsar su industria de software. Argentina es uno de estos países, y consideramos que lo están haciendo bastante bien. El sector industrial de software es uno de los que más ha crecido en Argentina durante la última década, e incluso actualmente Argentina ya exporta más software que carne. Conozcamos un poco sobre lo que se están haciendo nuestros hermanos en la tierra del Tango para desarrollar su industria.

Ley de Software Al estudiar el caso argentino, lo primero que resalta es la existencia de una “Ley de Software”. Dicha ley fue promulgada en el año 2004, con el fin de que se reconociera al software como industria (“Establécese que la actividad de producción de software debe considerarse como una actividad productiva de transformación asimilable a una actividad industrial, a los efectos de la percepción de beneficios impositivos, crediticios y de cualquier otro tipo”).

Los beneficios para las empresas del sector han sido considerables: hasta 70% de crédito fiscal, para ser utilizado para pagar impuestos nacionales, hasta 60% de desgravamen sobre el Impuesto a las ganancias, estabilidad fiscal durante el período de vigencia del régimen de promoción (por lo menos hasta el año 2019). Para optar a estos beneficios es necesario que las empresas cumplan con requisitos asociados a las actividades promovidas: contar con más de 50% de las personas empleadas y con más de 50% de la masa salarial dedicada al software, destinar más de 3% de la facturación a investigación y desarrollo de software, certificarse en estándares de calidad de software internacionales, garantizar estabilidad laboral.

CESSI Un actor fundamental es Ia Cámara de Empresas de Software y Servicios informáticos (CESSI). Resalta que CESSI es una

012

SG.48

CESSI opera distintos programas que apoyan el desarrollo de la industria, entre ellos: • EmplearTEC. Capacitación gratuita para formar personal que se pueda desempeñar en la industria de software.

• Bridge IT. Red de mentores que proporciona asesoría y vinculación a nuevos emprendedores.

• Espacio TI. Apoyo para difundir la oferta de pequeñas empresas de TI.

Fundación Sadosky Posiblemente, lo que más nos gusta del caso de Argentina, es lo que hacen por medio de la Fundación Sadosky. Este es un organismo sin fines de lucro cuyo objetivo es promover la articulación entre el sistema científico-tecnológico y la estructura productiva, con el fin de hacer llegar los beneficios de las TIC a toda la sociedad. Estas son algunas de las iniciativas en las que la Fundación actualmente está involucrada y que más nos han llamado la atención: Program.ar. Iniciativa para fomentar el aprendizaje de programación en los jóvenes. Destaca que recientemente se consiguió que el Consejo Federal de la Educación declare como estratégica la enseñanza de la programación en todas las escuelas del país.

Así que próximamente se enseñará programación de la misma manera que se enseñan otras materias básicas como matemáticas o historia.

Estudiar Computación. Es un sitio web con información dedicada a ayudar a que los jóvenes descubran las oportunidades y beneficios que implica estudiar una carrera relacionada con las TI. Además, brinda información precisa y sencilla sobre las diferencias y similitudes existentes entre las distintas disciplinas que conforman el mundo de la computación (ej. ¿cuál es la diferencia entre Ciencias de la Computación e Ingeniería de Software?, ¿en qué instituciones puedo estudiar estas carreras?).

Ciencia de Datos. El Ministerio de Ciencias y Tecnología ha reconocido que contar con capacidades locales para el manejo y análisis de grandes datos es clave para la autonomía tecnológica del país, así como para su desarrollo económico y social.

REPORTAJE

El objetivo de este programa es contribuir a que Argentina se convierta en líder regional en el campo de analítica de datos.

I

Como podemos ver, en la figura 3, el rubro de mayor actividad en el sector es el desarrollo de software, seguido por la comercialización de software ya sea propio o de terceros.

La Industria en números A continuación compartimos información quantitativa sobre la industria de software de Argentina, de acuerdo con datos del Observatorio Permanente de la Industria de Software y Servicios Informáticos (OPSSI).

Figura 3. Tipo de servicios ofrecidos.

Figura 1. Cantidad de empresas de software.

Figura 4. Clientes por tipo y tamaño.

Nos llama la atención que los organismos públicos solo representen un 7% del mercado, siendo que en otros países el sector público es uno de los principales compradores de software y servicios de informática.

Conclusión Figura 2. Evolución interanual en ventas y empleo.

En 2013 se tenía conocimiento de 4,288 empresas activas en la industria de software. De estas, el 75% reportaron tener menos de 10 empleados, otro 20% entre 10 y 50 empleados, 4% entre 50 y 200 empleados, y solo el 1% reportó tener más de 200 empleados.

En el 2014 hubo un crecimiento negativo en las ventas debido principalmente al ajuste en el tipo de cambio. Sin embargo, la industria se ha mantenido creciendo, lo cual se refleja en el empleo. En 2014 la industria de software reportó un crecimiento del empleo de 5.4%, comparado con una caída de 0.5% del empleo en la economía en general.

A pesar de la complicada situación económica por la que ha cruzado el país durante los últimos años, la industria de software en Argentina ha tenido logros significativos, y lo más importante es que no ha dejado de sembrar hacia el futuro. Reconocemos esta visión y perseverancia, que sin duda le traerá grandes frutos.

Agradecemos a José María Louzao Andrade, presidente de CESSI, por la información proporcionada para el desarrollo de este artículo.

Referencias [1] http://www.cessi.org.ar [2] http://www.empleartec.org.ar [3] http://program.ar [4] http://www.estudiarcomputacion.gob.ar

SG.COM.MX

013

I

ENTREVISTA

Entrevista con Dr. Lino Barañao MINISTRO DE CIENCIA Y TECNOLOGÍA DE ARGENTINA

(FONTAR) y el Fondo Fiduciario de Promoción de la Industria del Software (FONSOFT) de la Agencia Nacional de Promoción Científica y Tecnológica. Consiste en aportes no reembolsables y créditos blandos para que micro, pequeñas y medianas empresas puedan modernizarse incorporando software en sus productos o procesos, o a empresas de software para que hagan nuevos productos y mejoren los procesos existentes.

La cartera apoya también de manera muy contundente la promoción de vocaciones en TIC para lograr que aumente la cantidad de jóvenes que eligen carreras relacionadas y afines con el objetivo de producir los recursos humanos que demanda el sector para seguir creciendo sin restricciones y con la posibilidad de atender adecuadamente tanto el mercado interno como el externo.

El Dr. Barañao ejerce el cargo de ministro en el Ministerio de Ciencia, Tecnología e Innovación Productiva de Argentina desde el año 2007. Es Doctor en Ciencias Químicas por la Universidad de Buenos Aires (UBA), y participó en el equipo que en agosto de 2002 logró el nacimiento de Pampa, la primera ternera clonada de Iberoamérica.

A poco más de 10 años de su promulgación, ¿qué impacto ha tenido la Ley de Promoción de la Industria del Software en Argentina?

La Ley de Promoción de la Industria del Software —en combinación con otras medidas para fortalecer al sector— ha logrado excelentes resultados, siendo además un gran ejemplo de articulación entre el sector público y el privado. En solo 10 años la cantidad de empresas se ha multiplicado 240%; las exportaciones casi un 600%, y el empleo se ha cuadruplicado, llegando a alcanzar a 80,000 personas.

Hoy Argentina exporta más software que carne. Es además una industria transversal porque afecta positivamente la productividad en muchos otros sectores. ¿Hay riesgo de que un país que enfoque su industria de TI completamente a la provisión de servicios de outsourcing al extranjero olvide a su mercado interno y por lo tanto se pierda el efecto transversal de las TI en otras áreas?

Por supuesto que es un riesgo. Siempre es bueno mantener un balance entre exportaciones y mercado interno, ayudando al impacto transversal de las TIC. Por otro lado, el mercado interno muchas veces es la plataforma a partir de la cual se generan exportaciones. En el caso de Argentina las exportaciones son un poco inferiores a un tercio de la facturación, y eso por el momento muestra un buen balance entre mercado interno y externo.

Desde el Ministerio se promueve el desarrollo del mercado interno de varias formas, en general a través de líneas de financiamiento como las que ofrecen el Fondo Tecnológico Argentino

014

SG.48

Nos parece muy interesante el caso de la Fundación Sadosky. ¿A qué se debe que sea una fundación/organismo y no simplemente un departamento del MinCyT? La Fundación promueve la interacción entre el ámbito académico y el sector productivo, es decir entre investigadores y empresas. Nos pareció que una buena forma de mostrar esa voluntad de cooperación era reflejarla desde la misma conformación de la Fundación, y es por eso que quisimos hacer una institución donde ambos sectores estuvieran representados. La principal ventaja es poder contar con un órgano formal de administración donde el sector privado también está representado.

En estos primeros años de gestión de la Fundación, el financiamiento ha provenido en su mayor parte del sector público. Este escenario es razonable ya que es el Estado el que debe proponer los incentivos iniciales para lograr una vinculación exitosa y sostenida en el tiempo. A partir de este año, desde la Fundación se planificó una estrategia para conseguir, de manera gradual, atraer aumentos en la participación privada de sus aportes. Se espera que ese porcentaje siga subiendo en los próximos años en la medida en que el sector privado reconozca la importancia de la Fundación en materia de vinculación entre el sector académico y el aparato productivo.

Nos llama la atención que tengan un programa para impulsar la ciencia de datos, ¿qué nos puede comentar al respecto?

El programa de Ciencia de Datos de la Fundación Sadosky surgió justamente de un estudio, a partir del cual se elaboró una estrategia nacional alrededor de la temática de Big Data. Esta vertiente es considerada clave para la autonomía tecnológica, el desarrollo económico, social y la competitividad. El programa Ciencia de Datos tiene a su cargo la tarea de delinear, impulsar, alojar y coordinar las distintas actividades definidas a nivel estratégico, a la vez que mantiene un rol activo en la gerencia de los proyectos y la construcción de la comunidad. Este es un ejemplo sobre cómo la estructura del Ministerio reacciona de forma rápida ante nuevas tendencias. Sabemos que hay otras que debemos atender, como por ejemplo “Internet de las cosas”.

ENTREVISTA

¿Fomentan que distintas regiones geográficas del país tengan distintas especialidades de Ciencia y Tecnología?

El aporte de la generación de conocimiento al desarrollo de la economía de distintas regiones del país, surge a partir de un proceso de formulación de metas que tuvo lugar en el Plan Argentina Innovadora 2020 como producto de una cantidad de mesas de debate en las que se discutieron los potenciales y las necesidades de las distintas zonas. Esto convergió en un Plan que no está basado en el desarrollo de disciplinas sino en el de Núcleos Socio Productivos Estratégicos (NSPE). Son 36 núcleos distribuidos en todo el país en los cuales se trata de conjugar la generación de innovaciones a partir del conocimiento y el desarrollo de actividades industriales o de servicios basadas en las mismas; esto abarca desde la actividad forestal maderera en Misiones, la producción de medicamentos biotecnológicos en la Ciudad de Buenos Aires, el desarrollo de la maricultura en la Patagonia, la producción de energía a partir de residuos de la caña de azúcar en la provincia de Tucumán y la industria de los alimentos en distintas regiones del país.

El avance del Plan se monitorea a través de un proceso de seguimiento en el que se evalúan los resultados con el objetivo de efectuar las correcciones pertinentes. Como tarea pendiente queda fortalecer lo vinculado con el desarrollo de las economías regionales a los efectos de mejorar la competitividad a partir de la incorporación de innovaciones tecnológicas que el país está en condiciones de proveer actualmente. ¿Cuál es la importancia del nuevo Polo Científico? ¿Por qué lo denominan “primer centro de gestión, producción y divulgamiento de conocimiento en Latinoamérica”?

El Polo Científico Tecnológico es importante por su valor simbólico.

Podría considerarse una metáfora arquitectónica de lo que hemos tratado de hacer con la ciencia argentina; es decir, una estructura que estaba muy deteriorada pero que contaba con bases fuertes, a la que se le incorporó la última tecnología para convertirla en un ícono de la actividad científico-tecnológica del país. Es una sede única en el mundo, un lugar donde se conjugan la gestión, la investigación y la divulgación de la ciencia. La gestión a través de la actividad del Ministerio, de la Agencia Nacional de Promoción Científica y Tecnológica y, recientemente, del Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) que ya está instalado en el predio.

La investigación se aborda a partir de los Institutos Internacionales Interdisciplinarios para la Innovación (I4), que tienen como característica distintiva ser producto de cooperaciones internacionales: todos los institutos que allí se alojan trabajan en distintas disciplinas asociados a diferentes países o centros de investigación internacional, como el primer Instituto Partner de la Sociedad Max Planck en Buenos Aires o el Centro bilateral de Diseño Industrial (Argentina- Italia). El propósito de estos institutos es que haya investigadores de distintas zonas del país trabajando en el abordaje de diversas temáticas de manera interdisciplinaria.

I

El tercer componente que es el de la divulgación científica se da a través del Centro Cultural de las Ciencias (C3), que va a ser inaugurado en breve, y que contará con un auditorio para el desarrollo de tareas vinculadas con la difusión de la ciencia como conferencias, ciclos de cine, un canal propio de televisión (TEC TV) y un museo que va a ser único a nivel internacional, denominado “Lugar a dudas”. El mismo ha sido promovido por un prestigioso divulgador de la ciencia, Diego Golombek, y se destaca por la incorporación de las últimas herramientas tecnológicas y un modo de presentar los problemas básicos de la ciencia desde una perspectiva novedosa y altamente atractiva, en especial para los más jóvenes. Esta convergencia de distintas actividades es la que creemos que es sumamente original ya que permite mostrar a la sociedad cuáles son los componentes que definen a la actividad científico-tecnológica. ¿Es factible lograr que los “cerebros fugados” de un país puedan seguir contribuyendo desde el exterior?

La cuestión de los investigadores argentinos residentes en el exterior ha sido motivo de preocupación ya desde los inicios de mi gestión como presidente de la Agencia Nacional de Promoción Científica y Tecnológica en el año 2003. Es por eso que se decidió crear el programa “Raíces” que consta de diversas actividades e iniciativas. Una red para generar una base de datos que alberga a unos 5,000 investigadores que reciben información periódica sobre actividades de investigación; un componente de repatriación, que es quizá el más conocido, desarrollado específicamente para promover este proceso de reinserción de los investigadores en el país y que contiene varios mecanismos. El investigador no se presenta individualmente sino que es una entidad la que lo contrata, el repatriado recibe a su vez un subsidio para investigar y para cubrir sus gastos de traslado, y la entidad que lo contrata también recibe financiamiento para adecuar su infraestructura y para efectivizar esa contratación, lo que hace que el investigador pueda instalarse fácilmente, sin perder tiempo.

Ya llevamos repatriados 1,175 investigadores y eso tiene una alta carga afectiva para el ciudadano común pero no es el único componente importante; también existe el subsidio César Milstein destinado a los argentinos que se encuentran en el exterior interesados en realizar cursos aquí en el país o de participar en proyectos de investigación. Esto hace que puedan aportar un valor agregado a las tareas que se llevan adelante en nuestro país, con la posibilidad de acceder a equipamientos de alto porte y vinculándose con proyectos que tienen que ver con la incubación de empresas para extender este proceso de acercamiento no sólo desde el punto de vista de la investigación científica sino también desde las innovaciones productivas que conducen a emprendimientos comerciales.

La vinculación con los investigadores que migraron es una actividad central para el Ministerio y la implementación de distintos programas ha permitido que todos ellos estén contribuyendo efectivamente al desarrollo de la ciencia argentina y que sean considerados una parte integral de la comunidad científica.

SG.COM.MX

015

T

LENGUAJES

Revisión del Lenguaje Swift — Por Tomás Balderas

Swift es un lenguaje de programación creado por Apple con la finalidad de reemplazar eventualmente a Objective-C como lenguaje principal para desarrollo de aplicaciones para iOS y OS X. La intención de este artículo es describir los elementos constitutivos del lenguaje utilizando ejemplos simples y prácticos. Se asume que el lector está familiarizado con los conceptos básicos de orientación a objetos y cuenta con experiencia con algún lenguaje como Smalltalk, Java, Objective-C, C# o C++.

Clases y estructuras

consecutiva por un valor entero comenzando en cero. Swift da la opción de asignar un valor arbitrario (valor bruto) a cada miembro de una enumeración o de no asignar valores a ningún miembro. La enumeración Gender define dos miembros (Male y Female), a los que no asigna valores brutos. Es necesario especificar el tipo de los valores brutos después de dos puntos (:) en la declaración del nombre de la enumeración (en este caso, el tipo usado fue Printable).

Listado 1a. Clase Employee

En Swift, las clases (class) y estructuras (struct) comparten muchas capacidades.

Ambas pueden tener propiedades y métodos, inicializadores para definir su estado inicial, e implementar protocolos (interfases). Las clases cuentan con capacidades adicionales tales como herencia/generalización, type casting para identificar el tipo de una instancia en tiempo de ejecución, y desinicializadores para liberar recursos.

Las instancias de estructuras se almacenan por valor, mientras que las instancias de clases se almacenan por referencia.

enum Coordinate { case Cartesian(Float, Float) case Polar(Float, Int) } var aCoordinate = Coordinate.Cartesian(123.0, 180.0) aCoordinate = .Polar(120.0, 45)

Listado 1b. Estructura PersonalInformation

El listado 1a muestra la declaración de la clase Employee y el 1b la estructura PersonalInformation, empleadas respectivamente para describir empleados en una línea aérea y sus correspondientes datos personales. La clase Employee especifica un método para inicializar las propiedades de sus instancias (init()) y un método que sobrecarga el operador de igualdad (==) para definir un criterio de comparación entre instancias de la clase. La sobrecarga del operador de igualdad es necesaria para que la clase pueda implementar adecuadamente los protocolos Equatable y Hashable, la cual es una condición necesaria para construir conjuntos de instancias de Employee, como se discutirá más adelante.

Los miembros de una enumeración pueden tener datos asociados, que es un concepto distinto al de los valores brutos. Los miembros de la siguiente enumeración denotan diferentes sistemas de coordenadas:

aCoordinate es una instancia de la enumeración Coordinate que inicialmente denota una coordenada cartesiana ubicada en el punto (123,180) y posteriormente se modifica para indicar una coordenada polar localizada en el punto (120,45º).

Variables y constantes

Listado 1c. Enumeración Gender

Como podemos ver, PersonalInformation define una variable de tipo “Gender” (género). El listado 1c muestra la definición de Gender, que es una enumeración.

Las enumeraciones se utilizan para agrupar bajo un mismo identificador a un conjunto de valores relacionadosa quienes se conoce como miembros. En el lenguaje C cada miembro está enumerado de forma

Swift es un lenguaje con tipificación estricta que ordena que todas las variables y constantes deben pertenecer a un tipo de datos. Swift permite que el compilador infiera el tipo de una variable o constante de acuerdo al contexto. Como ejemplo, considere las siguientes sentencias: var aString = “Hello World!” let anInteger = 6152

Aquí se tienen una variable y una constante que no están tipificadas explícitamente pero cuyos tipos se infieren a partir

Tomás Balderas es doctor y maestro en Ciencias Computacionales por el INAOE, y licenciado en Ciencias de la Computación por la BUAP. Se ha desempeñado en distintas empresas y centros de investigación. Actualmente es consultor independiente. https://mx.linkedin.com/in/tomasbalderas

016

SG.48

LENGUAJES

de los tipos de los valores a la derecha del operador de asignación, que son String e Int, respectivamente.

Los tipos se clasifican en tipos por valor y tipos por referencia. Las variables con tipo por valor almacenan todo su contenido en el espacio en memoria reservado para ellas, por lo que la asignación de una variable a otra crea una copia del espacio en memoria de la primera variable. Los tipos numéricos, cadenas y estructuras son tipos por valor. Las variables con tipo por referencia son apuntadores al espacio en memoria que almacena su contenido.

En Swift, todas las instancias de clase son tipos por referencia.

de la función que recibe como entrada a través del parámetro test. Posteriormente se definen las funciones greaterThan() y lessThan() que comparan sus parámetros, regresan un valor de tipo booleano y se usan como entrada a getBound() posteriormente. Después, se asigna la función greaterThan() a la variable aFunction de tipo función (Int, Int) -> Bool. A continuación se invoca a getBound(), con el arreglo a inspeccionar y la función que realiza la comparación en la variable aFunction como parámetros, para encontrar el valor máximo en el arreglo de entrada.

Finalmente, las últimas dos sentencias invocan nuevamente a getBound() para obtener el valor mínimo en el arreglo.

Propiedades La sintaxis para definir propiedades dentro de una clase o estructura es idéntica a la sintaxis utilizada para declarar variables y constantes. Las propiedades declaradas por una clase se deben inicializar explícitamente, a menos que dicha clase defina un método init() para tal propósito. Swift permite declarar propiedades calculadas, cuyo estado se calcula al momento de ser consultado, es decir que no se guarda en memoria. En nuestra estructura PersonalInformation, la propiedad age (edad) es una propiedad calculada que regresa un entero, así como la propiedad hashValue en la clase Employee.

Funciones y cerraduras Swift permite definir funciones en cualquier lugar de un archivo de código, siempre y cuando sea después de haber declarado los tipos de datos de sus parámetros y variables. Además de describir las sentencias que conforman el cuerpo de una función, Swift permite definir tipos función para declarar variables que tienen funciones como valores.

El listado 2 muestra ejemplos de definición de funciones. La función getBound() regresa el valor máximo o mínimo en un arreglo de valores enteros dependiendo

Listado 2. Uso de funciones

Como mencioné anteriormente, Swift también permite que una función regrese un valor de tipo función. La función chooseFunction() en el listado 2 verifica el valor de su único parámetro y entonces decide cuál de las dos funciones definidas debe regresar. Note que el tipo devuelto por chooseFunction() es el mismo que el del parámetro test de la función getBound(), es decir (Int, Int) -> Bool.

T

Otra característica relevante es la declaración de funciones que regresan más de un valor, lo cual es posible gracias al concepto de tupla, mencionado anteriormente.

También es posible pasar cualquier tipo de tupla a una función como parámetro, declarar tuplas como variables dentro de funciones y declarar tuplas cuyos elementos sean funciones, es decir elementos de tipo función. Como ejemplo, considere las siguientes sentencias: func rearrange(input: (Int, Int, Int)) -> (Int, Int, Int) { return (input.2, input.1, input.0) } var aTuple = (23, 45, 67) var anotherTuple = rearrange(aTuple) // (67, 45, 23)

La función rearrange() recibe como entrada una tupla con tres elementos de tipo entero, intercambia el primer elemento y el último elemento en dicha tupla y regresa la tupla resultante. Las tuplas pueden tener cualquier número de elementos de cualquier tipo de datos proporcionado por Swift o definido por el desarrollador.

Otro elemento útil en Swift es la cerradura (closure) que denota un bloque de código auto-contenido que puede ser asignado a una variable, enviado como argumento a alguna función e invocado para que se ejecute. Se puede establecer un paralelismo entre éste concepto y el bloque de código en Smalltalk, que también puede ser manipulado e invocado por diferentes construcciones del lenguaje. Como ejemplo simple de la declaración de una cerradura y su uso considere las siguientes sentencias que transforman un valor entero en su representación como cadena: var aClosure = { (input: Int) -> String in return String(input) } var aString = aClosure(234) // aString = “234”

La sintaxis completa de la cerradura establece el número y los tipos de los parámetros, el tipo del valor de retorno y las sentencias que la conforman. La cerradura consta de un único parámetro entero y una única sentencia que crea una instancia de String a partir del parámetro y la

SG.COM.MX

017

T

LENGUAJES

regresa. Es posible simplificar la sintaxis de la cerradura aprovechando la inferencia de tipos, como se muestra en las siguientes sentencias: aClosure = { (input: Int) in String(input) } aString = aClosure(123) // aString = “123”

En este caso, debido a que solo hay una sentencia, el compilador infiere que la instancia de String creada a partir del parámetro entero es el valor de retorno de la cerradura. Tal inferencia permite que el compilador también determine que el tipo del valor de retorno es String, por lo que se hace innecesario declararlo explícitamente.

Métodos El listado 3 muestra la declaración de la clase Airline que complementa las clases declaradas en los listados 1a y 1b. La clase declara la propiedad corporateInformation para almacenar información general de la empresa como su razón social, dirección postal, URL e información bursátil.

Debido a que los datos almacenados en esta propiedad no varían entre instancias de Airline, la variable se declara como propiedad tipo mediante el modificador static y se inicializa explícitamente al declarar la clase. El método displayCorporateInformation() es un método tipo que despliega la información almacenada por la propiedad corporateInformation y se invoca enviando un mensaje directamente a la clase Airline, como se muestra en el listado 3.

Listado 3. Clase Airline

018

SG.48

La clase también declara el método init(), que se invoca al crear cada instancia de Airline y cuyo propósito es inicializar las propiedades de la instancia. Swift permite declarar diferentes variantes del método init() dentro de una misma clase y establece una secuencia en la ejecución de los métodos de inicialización de una clase y su superclase. En el caso de Airline, que no tiene superclase, init() únicamente asigna un valor a la propiedad employees y termina su ejecución.

Colecciones Swift permite agrupar valores mediante tres diferentes variedades de colecciones: arreglos, conjuntos y diccionarios.

Los arreglos son colecciones de valores indexados donde es posible almacenar una o más ocurrencias del mismo valor.

Los conjuntos son colecciones no indexadas de valores que son todos distintos.

Los diccionarios pueden almacenar parejas cuyos elementos son una llave y su valor correspondiente.

Considere las siguientes sentencias que realizan varias operaciones sobre un arreglo de números enteros: var anArray = [65, -123, 873, 29, -45, 704, 234, 2, -5] anArray[0] // 65 anArray[6...8] // [234, 2, -5] anArray[2..<6] // [873, 29, -45, 704] anArray.count // 9 anArray.append(-45) anArray.count // 10 anArray = anArray.filter { $0 > 0 } // [65, 873, 29, 704, 234, 2] anArray = anArray + [867, 34, 3] // [65, 873, 29, 704, 234, // 2, 867, 34, 3]

Después de la sentencia de asignación hay tres sentencias que acceden y regresan, respectivamente, el primer elemento del arreglo, el sub-arreglo delimitado por el séptimo y el noveno elementos (índices 6 a 8) del arreglo inicial y el sub-arreglo delimitado por el tercero y el sexto elementos (índices 2 a 5) del arreglo inicial. A continuación se verifica el número de elementos en el arreglo antes y después de añadir un valor entero al final del mismo y se corrobora la precisión de los valores obtenidos. La penúltima sentencia elimina los valores negativos en el arreglo inicial aplicando

una cerradura sobre cada elemento y descartando los que no cumplen la condición en la cerradura. Finalmente, la última sentencia añade tres elementos más al final del arreglo utilizando el operador de adición.

La clase Airline almacena la información de sus empleados en un conjunto para garantizar que no hay más de una ocurrencia de cada instancia de la clase Employee. La clase utiliza el método insert() para anexar una nueva instancia al conjunto y la propiedad count para obtener el número de elementos en el conjunto. Para poder construir conjuntos a partir de instancias de Employee es necesario que dicha clase siga estrictamente las reglas establecidas por los protocolos Equatable y Hashable. Primero, la clase debe implementar un criterio que determine la igualdad entre instancias de Employee mediante la sobrecarga del operador de comparación. Segundo, la clase debe proporcionar un valor a utilizar como llave (hashValue) en la tabla hash que almacena el conjunto.

En nuestro caso se establece que dos instancias de Employee son iguales cuando tienen el mismo valor en su propiedad ID y que el campo ID es la llave a utilizar para almacenar instancias en la tabla hash.

Los diccionarios en Swift se emplean para representar tablas en las que es necesario buscar un valor requerido a partir de un valor llave. Todos los elementos en un diccionario son pares del tipo [llave:valor], donde el elemento llave se utiliza para acceder al elemento correspondiente en la tabla hash que almacena el diccionario y el elemento valor puede ser de cualquier tipo. Como consecuencia de esta definición, la siguiente declaración de diccionario es válida: var anotherDictionary: [String:(Int, Int)]

mientras que la siguiente sentencia genera un error de compilación: var anotherDictionary: [(Int, Int):String]

La primera declaración es válida porque las instancias del tipo String funcionan sin problemas como llaves para una tabla hash, mientras que una tupla no sirve directamente como una llave.

LENGUAJES

Con la intención de revisar algunos rasgos de los diccionarios en Swift considere las siguientes sentencias que asignan y manipulan un diccionario cuyos elementos tienen una cadena como llave y un valor de tipo entero: var aDictionary = [“Mercury”:1, “Venus”:2, “Earth”:3, “Mars”:4] aDictionary[“Mars”] // 4 aDictionary[“Jupiter”] = 5 aDictionary[“Saturn”] = 6 aDictionary.count // 6 aDictionary.description // “[Mars: 4, Venus: 2, Earth: 3, Jupiter: 5, Saturn: 6, Mercury: 1]” aDictionary.removeValueForKey(“Earth”) aDictionary.count // 5

T

func sum(n: Int) -> Int? {

if n > 0 {

if n == 1 { return 1

} else { return n + sum(n - 1)!

} } else {

return nil

} } if var anInt = sum(10) { println(“Result: \(anInt)”)

La primera sentencia declara e inicializa un diccionario con cuatro pares no ordenados de datos. La segunda sentencia accede al diccionario para buscar el valor entero correspondiente a la llave “Mars” y lo regresa. La tercera y cuarta sentencias ingresan dos nuevos pares de datos al diccionario, lo que incrementa el número total de elementos en el diccionario a seis. La sexta sentencia regresa una representación del contenido del diccionario en forma de una cadena, lo que permite observar que los elementos no necesariamente se almacenan en el orden en el que fueron definidos o anexados. La séptima sentencia elimina el par cuya llave tiene el valor “Earth”, lo que reduce el número de elementos en el diccionario a cinco.

Opcionales Uno de los conceptos fundamentales que ofrece Swift es el de los tipos opcionales, los cuales se utilizan para manejar la ausencia de un valor. El concepto de opcional se aplica a un tipo de datos X cuando existe el riesgo de que una operación no pueda producir un valor de tipo X como se espera. En Objective-C se acostumbra usar punteros nil para este propósito. La ventaja de los opcionales es que funcionan con cualquier tipo, no solo con clases, además la sintáxis es más expresiva y clara.

Por ejemplo, es posible que la función que convierte cadenas en valores enteros transforme “456” en 456, pero no es posible que transforme la cadena “abc” en un valor entero. En este caso es conveniente que la función regrese un opcional entero (Int?) en vez de un entero (Int), de manera que cuando la función pueda transformar su argumento el resultado se considere existente y se interprete como un valor entero, mientras que cuando no sea posible hacer la transformación el resultado se considere inexistente, lo que se denota con la palabra reservada nil.

El opcional de un tipo se declara colocando un signo de interrogación (?) después del nombre del tipo. Para ilustrar el uso del opcional considere una función que calcula recursivamente la suma de los primeros n enteros y regresa un opcional entero, lo cual es necesario porque hay casos en los que la suma no tiene sentido (n £ 0). El código de la función de la función quedaría de la forma siguiente:

// “Result: 55”

} else { println(“Result: nil”) }

Cuando el valor del parámetro es menor o igual a cero la función regresa nil, pues es el caso en el que se considera que el resultado no existe. Cuando el valor es mayor que cero la función verifica si se cumple el caso base o si es necesario realizar el cálculo recursivo. El signo de exclamación (!) colocado inmediatamente después de la llamada recursiva es necesario para indicar que el opcional entero devuelto por la llamada recursiva se debe interpretar como un valor entero, pues se sabe que tal valor existe. La estructura if que sigue a la función recursiva expresa una unión opcional, la cual asigna el resultado de sum(10) a la variable anInt y compara tal variable con nil en un solo paso. Si la variable es nil entonces se ejecuta la sentencia en el bloque else, de otra forma se muestra el resultado de la variable entera anInt, como ocurre en nuestro ejemplo.

Comentarios finales Aunque aquí hemos revisado algunos rasgos relevantes del lenguaje Swift, la revisión no fue de ningún modo exhaustiva y aún queda mucho por discutir sobre este lenguaje. Les recomiendo consultar la documentación oficial de Swift para profundizar en su estudio. Los ejemplos en el libro y en este reporte se pueden verificar utilizando “playgrounds” en el ambiente de desarrollo XCode. También, se recomienda consultar la información referente al desarrollo de aplicaciones utilizando Swift y los kits de desarrollo en OS X e iOS, así como a la compatibilidad entre Swift y Objective-C. Agradezco profundamente al M.C. Ricardo Ruíz Rodríguez por sus valiosos comentarios y acertadas observaciones para el desarrollo de este artículo.

Referencias y estudio adicional [1] Swift homepage. https://developer.apple.com/swift [2] “The Swift Programming Language”. iOS Developer Library [3] “Using Swift with Cocoa and Objective-C”. iOS Developer Library

SG.COM.MX

019

P

EN PORTADA

DevOps TODO ES CUESTIÓN DE COLABORACIÓN —

Por Patrick Debois

A PESAR DE TODAS LAS METODOLOGÍAS QUE TENEMOS EN TI, ENTREGAR UN SISTEMA A PRODUCCIÓN TODAVÍA ES UN ACONTECIMIENTO DE CUIDADO. LOS DESARROLLADORES SE PONEN NERVIOSOS PORQUE TIENEN LA PRESIÓN DE ENTREGAR FUNCIONALIDAD NUEVA LO ANTES POSIBLE. POR EL OTRO LADO, EL EQUIPO DE OPERACIONES, CUYA RESPONSABILIDAD ES MANTENER LOS SISTEMAS OPERANDO EN PRODUCCIÓN SE OPONE A LOS CAMBIOS PORQUE SABE QUE ESTOS PUEDEN TRAER INESTABILIDAD Y TIRAR LOS SISTEMAS. ASÍ QUE CUANDO HAY PROBLEMAS, COMIENZA LA ASIGNACIÓN DE CULPAS: “ES UN PROBLEMA DE DESARROLLO”; “NO, ES UN PROBLEMA DE OPERACIONES.” ... ESTA ESCENA SE REPITE CON FRECUENCIA EN LA MAYORÍA DE LAS ORGANIZACIONES.

020

SG.48

EN PORTADA P

Este artículo es una versión traducida y resumida de la editorial que da inicio al reporte “DevOps: A Software Revolution in the Making” publicado por Cutter Consortium en agosto de 2011. Te recomendamos mucho el reporte completo, disponible en http://www.cutter.com/itjournal/fulltext/2011/08

E

l problema es amplificado por dos tendencias en la industria: el desarrollo ágil y el cómputo en la nube. Por naturaleza, el desarrollo ágil acoge el cambio y fomenta liberaciones pequeñas y frecuentes a producción. Esta mayor frecuencia agrega presión al equipo de operaciones, convirtiéndolo en un cuello de botella. Lo curioso es que aun cuando el desarrollo ágil fomenta la colaboración entre los interesados, la mayoría de los equipos ágiles no colaboran con el personal de operaciones.

Los equipos de integración y pruebas, que tradicionalmente han funcionado como intermediarios entre desarrollo y operaciones, también están sintiendo la presión.

A su vez, el cómputo en la nube ha obligado a los equipos de operaciones a cambiar la forma en que administran la infraestructura.

Las labores manuales ya no son posibles cuando estás lidiando con miles de máquinas. Si se va a estar liberando frecuentemente a producción, se requieren herramientas para soportarlo.

La virtualización facilita y acelera la creación de ambientes, y la nube elimina el problema de los recursos de cómputo. Lo que hace las cosas distintas es la capacidad de administrar la infraestructura y la gestión de configuración por medio de código. La infraestructura como código es el resultado de la infraestructura y plataformas como servicio (IaaS, Paas). La gestión de configuración por medio de código permite describir el estado deseado de la infraestructura por medio de lenguajes de dominio específico —utilizando herramientas como Chef y Puppet. Estos conceptos habilitan a los equipos de operaciones para automatizar gran parte de su trabajo —no solo el aprovisionamiento inicial de infraestructura, sino todo el ciclo de vida. Esto ha dado origen al concepto de “infraestructura ágil”.

Como resultado de estos factores ha surgido el concepto de DevOps, que busca eliminar las barreras entre desarrollo y operaciones. Algunos consideran que es una continuación del desarrollo ágil, ya que a fin de cuentas el software no genera valor si no está en producción.

En el contexto de DevOps, el equipo de operaciones es un miembro valioso del proceso de construcción de software. Esto permite que los requerimientos no funcionales tales como desempeño, estabilidad o respaldo sean discutidos al mismo tiempo que los requerimientos funcionales. Una vez que se logre un acuerdo,

los equipos de desarrollo y operaciones colaboran para lograrlos desde un inicio, y no hasta que el sistema ya está “terminado”.

Cuando algo es dificil, hazlo con mayor frecuencia; la práctica hace al maestro. Conforme practiquemos más la liberación a producción, lo haremos mejor. Gracias a herramientas de automatización, los equipos de operaciones pueden liberar pequeños cambios de forma rápida y con mayor frecuencia. Liberar frecuentemente a distintos ambientes (desarrollo, pruebas, preproducción, producción) y utilizando el mismo conjunto de modelos de gestión de la configuración, nos ayuda a generar resultados predecibles y repetibles.

Bajo esta visión, parte de los entregables de un sistema de software, debe ser el proceso automatizado para liberar dicho software a distintos ambientes —incluyendo producción, por supuesto.

Todos los cambios a un ambiente deben seguir el mismo proceso, independientemente de si lo que se está cambiando es código, infraestructura, o datos. Este concepto es lo que se conoce como el “deployment pipeline” y es la base de la entrega continua (continuous delivery).

Al igual que cualquier otro cambio, DevOps es un camino de descubrimiento, las personas y los procesos no se pueden cambiar de la noche a la mañana. Un patrón común en la adopción de DevOps es que los cambios organizacionales van de la mano de la introducción de nuevas herramientas. Una herramienta por sí sola no cambiará nada, lo primero que se necesita es un cambio en comportamiento, que a su vez genera un cambio de cultura. Es por ello que la adopción de DevOps requiere un fuerte apoyo del equipo directivo.

Muchos de los casos de éxito iniciales de DevOps se originaron en startups o empresas nativas de internet como Facebook o Amazon.

Habrá quienes puedan pensar que DevOps solo es factible en empresas de este tipo, ya que en corporativos tradicionales regidos por modelos como CMMI e ITIL no habría lugar para DevOps. En realidad, las empresas tradicionales son las que tienen mayor necesidad de colaboración, y DevOps es a fin de cuentas tan solo una etiqueta para invitarnos a mejorar la colaboración. Es perfectamente posible adoptar prácticas de DevOps en contextos de ITIL y CMMI, y de hecho es recomendable ya que brinda una alineación natural entre TI y el negocio.

Patrick Debois es consultor senior en Cutter Consortium para la práctica de Agile Product & Project Management. Se le reconoce por acuñar el término “DevOps” cuando organizó la conferencia DevOpsDays en 2009 para discutir sobre este concepto.

SG.COM.MX

021

P

EN PORTADA

¿Qué es esto de

DevOps? —

Por Pedro Galván

T

odos aquí sabemos que algo con lo que siempre hemos podido contar en la industria de TI es con nuestra capacidad para deformar cualquier término de moda para hacer que signifique cualquier cosa que nos convenga. DevOps actualmente se encuentra en ese punto. Así que me toca compartir mi explicación de lo que entiendo por DevOps. Más allá de pretender que usted lector lo entienda igual, espero ayudarlo a enriquecer su perspectiva al respecto. A final de cuentas, mi trabajo es fácil ya que se cumple con brindar información y explicación. El de usted es mucho más complicado porque consiste en implementar en la vida real estas cosas de las que yo platico como si fuera muy sencillo lograrlas.

partícipes —notablemente los equipos de desarrollo (Dev) y operaciones (Ops) pero no limitado a estos— a lo largo de todo el ciclo de vida de un sistema de software con el fin de entregar valor al usuario y al negocio de forma continua y consistente. Por cierto, al hablar de “operaciones” nos referimos a roles como administradores de servidores, redes, DBAs, soporte. Básicamente, las personas responsables de mantener los sistemas operando.

Ni tecnología ni metodología

Un rasgo característico de la cultura DevOps es que invita al equipo de operaciones a administrar infraestructura utilizando técnicas y herramientas similares a las que usan los desarrolladores (de ahí el término “infraestructura como código”). Ejemplos de esas técnicas es usar sistemas de control de versiones, pruebas automatizadas, scripts para instalación de ambientes, etcétera. Habiendo dicho eso, no debemos olvidar que dichas técnicas, a pesar de su utilidad, no dejan de ser meros instrumentos para expresar la cultura. En otras palabras, no sirve de nada tener herramientas si no hay cultura.

“Nosotros aplicamos una metodología DevOps”, “conoce nuestra oferta de productos para DevOps”, “se busca ingeniero DevOps”.

Este tipo de frases dan la idea de que DevOps es una tecnología y/o metodología sofisticada. En realidad, no es ninguna de las dos.

El término DevOps originalmente fue acuñado simplemente para referirse a la comunidad de gente interesada en estudiar cómo construir y operar sistemas de gran escala que evolucionen de forma rápida y continua. Lo que a Patrick Debois le interesaba cuando organizó el 1er devopsdays en 2009 era simplemente conocer a otras personas interesadas en la noción de poder manejar la infraestructura de TI de forma ágil. Es por ello que en realidad no existe un framework reconocido de DevOps, ni productos certificados para DevOps. Si quisiéramos encasillar a DevOps como algo, lo más correcto desde mi punto de vista no sería definirlo ni como una metodología ni como una tecnología, sino como una cultura. Y la cultura no es algo que se adquiere ni se aplica de forma discreta ni consciente, sino que se forma y se exuda de forma continua e inconsciente.

La cultura DevOps fomenta la colaboración entre los distintos

Pedro Galván es cofundador y director editorial de Software Guru.

022

SG.48

La cultura DevOps tiene sus orígenes en la filosofía ágil y lean.

Podemos considerar que DevOps es una extensión de ágil que se preocupa no solo por la construcción del software, sino también por su puesta en producción, uso y retroalimentación.

Conclusión DevOps es algo complicado de definir, tal como su hermano Ágil, pero no por eso debemos dejarlo de lado. Debemos estar conscientes de que DevOps es en esencia una cultura, y por lo tanto no está atada a un conjunto de actividades específicas. La cultura DevOps se termina materializando en actividades y técnicas que pueden ser distintas en cada organización.

En una cultura DevOps, los desarrolladores y operadores colaboran para no solo construir el software, sino también entregarlo exitosamente al usuario y satisfacer sus expectativas de desempeño, disponibilidad, seguridad y evolución.

EN PORTADA P

10 Mitos de DevOps —

Por Sanjeev Sharma y Bernie Coyle

Este artículo es una versión traducida y resumida del capítulo “Ten DevOps Myths” del libro “DevOps for Dummies” escrito por Sanjeev Sharma y Bernie Coyle, publicado por Wiley Sons. Puedes obtener una copia gratuita del ebook por cortesía de IBM en http://ibm.co/devopsfordummies

A

l igual que sucede con cualquier tendencia emergente, se ha generado una buena cantidad de mitos y falacias alrededor de DevOps. A continuación analizo los más comunes.

realidad, una buena cultura de DevOps fomenta el cumplimiento de normas y facilita la auditabilidad. En las empresas en industrias reguladas siempre habrá puntos de revisión manuales, pero esos elementos no son incompatibles con DevOps.

Es exclusivo de empresas nativas de internet Es cierto que empresas como Netflix, Flickr y Etsy, cuya operación está basada en el internet, son algunas de las pioneras de lo que es reconocido como el movimiento DevOps. Sin embargo, los corporativos han estado aplicando principios similares a DevOps para entregar software desde hace años, posiblemente décadas.

No es aplicable en outsourcing

Se resume en que los de operaciones aprendan a programar Los equipos de operaciones están acostumbrados a escribir scripts para administrar ambientes y tareas repetitivas. El concepto de infraestructura como código implica que para crear un ambiente de ejecución un administrador de sistemas crea una nueva versión del código que define a dicho ambiente. Esto provoca que ahora los equipos de operaciones tengan que crear y administrar grandes cantidades de código y por lo tanto requieran aplicar técnicas de ingeniería de software tales como control de versiones y rastreo de issues. Así que ahora los equipos de operaciones, más allá de programar, también construyen software y gestionan su ciclo de vida.

No hay DevOps sin la nube

Solo es para desarrolladores y operadores Aunque su nombre (dev + ops) sugiere eso, en realidad DevOps aplica a todos los involucrados en proyectos de TI.

Los equipos de outsourcing externos forman parte del flujo de trabajo. Las organizaciones deben asegurarse de que las prácticas, herramientas y procesos de estos equipos externos sean compatibles con las del resto del equipo, de tal manera que exista una comunicación y colaboración adecuada.

DevOps responde a las posibilidades y restricciones que ofrece el cómputo en la nube. Sin embargo, hacer cómputo en la nube no es un requerimiento para DevOps. Las organizaciones pueden establecer procesos eficientes para obtener y administrar recursos de cómputo independientemente de si estos se encuentran hospedados en la nube.

No aplica para sistemas grandes y complejos Los sistemas complejos requieren la disciplina y colaboración que brinda DevOps. Tales sistemas típicamente tienen grandes cantidades de componentes de software y hardware, que posiblemente sean construidos de acuerdo a ciclos de vida independientes. DevOps facilita la planeación y coordinación de estos ciclos para lograr entregas predecibles y estables.

Solo cuestión de comunicación No es compatible con ITIL Algunas personas argumentan que prácticas de DevOps tales como la entrega continua no son compatibles con los controles prescritos por ITIL. Esto no es del todo correcto. En realidad, la mayoría de los principios de ITIL se alinean bien con los principios de DevOps. El problema no es ITIL como tal, sino que ITIL es utilizado predominantemente en organizaciones con procesos lentos e inflexibles.

No es aplicable en industrias reguladas Las industrias con alta regulación (ej. financiero) tienen necesidades adicionales de controles y revisiones que aseguren el cumplimiento de normas y capacidad de ser auditadas, por lo que pueden ser vistas como no aptas para algo “tan radical” como DevOps. En

Algunas personas se refieren a DevOps como “ChatOps” argumentando que simplemente consiste en que los equipos se dediquen a chatear entre sí por medio de IRC o Slack. Es cierto que DevOps depende de una buena comunicación, pero una buena comunicación sin procesos adecuados no sirve de mucho.

DevOps requiere liberar a producción diario Algunas empresas argumentan orgullosamente que liberan cambios a producción todos los días, incluso varias veces al día. En ciertos tipos de empresas esto es posible y recomendable, pero en otro tipo de empresas no solo no es viable sino que no tiene mucho sentido. DevOps busca mejorar el proceso de liberación y alinearlo a la frecuencia que tenga más sentido para el negocio.

SG.COM.MX

023

P

EN PORTADA

La Caja de Herramientas —

DevOps?

Por Pedro Galván

A

unque ya hemos comentado que DevOps es en esencia una cultura, no por ello podemos ignorar a las herramientas que nos pueden facilitar o acelerar las actividades de los distintos involucrados. En este artículo echaremos un vistazo general a distintos tipos de herramientas típicamente asociadas con DevOps, de manera que podamos entender cuál es el propósito de cada una y cómo se relacionan entre sí.

Aprovisionamiento y configuración de ambientes Cualquier administrador de sistemas ha vivido la frustrante experiencia de que una aplicación falle en producción, y al preguntarle al desarrollador al respecto nos conteste “pues funciona en mi máquina” ... (sí, en efecto dan ganas de ahorcarlos). Las herramientas de aprovisionamiento y configuración ayudan a evitar estas situaciones, ya que nos permiten especificar a gran detalle los ambientes de ejecución, de tal manera que puedan ser replicados de forma automatizada y repetible por medio de scripts. A esto es a lo que se refiere el concepto de “administrar la infraestructura como código”.

Entre de las herramientas más conocidas para aprovisionamiento y configuración de sistemas están Chef, Puppet, Ansible y Salt.

Este es un espacio novedoso en el que han surgido varias herramientas, principalmente de software libre, donde casi no hay presencia de los jugadores tradicionales (IBM, CA, HP, Microsoft).

Integración continua La integración continua es una práctica que consiste en generar varias veces al día una versión nueva del sistema de software que un equipo está desarrollando. Dicha versión integra las copias de desarrollo de los distintos componentes en los que está trabajando cada desarrollador. Su objetivo es que los problemas de integración surjan lo antes posible y se mejore el entendimiento de las dependencias entre el código que cada quien está trabajando. Para lograr esto requerimos usar un servidor de integración continua.

Entre los servidores de integración continua más conocidos están Jenkins, Atlassian Bamboo, Travis CI y JetBrains TeamCity.

Pedro Galván es cofundador y director editorial de Software Guru.

024

SG.48

Gestión de despliegue En un ambiente efectivo de DevOps, las liberaciones a producción son frecuentes, predecibles y confiables. Las herramientas de esta categoría típicamente se dividen en dos tipos con propósitos específicos: Gestión de liberación (release management). Se enfocan en los aspectos de gestión para asegurar que un software está listo para ser liberado a producción. Destacan XebiaLabs Release, UrbanCode Release, CA Service Virtualization, Serena Release Control.

Automatización de despliegue (deployment automation). Se enfocan en mover y activar los componentes de software requeridos a los distintos nodos de cómputo. Destacan XebiaLabs Deploy, UrbanCode Deploy, CA Release Automation, Serena Deployment Automation.

Soporte al flujo de trabajo Además de las herramientas en las categorías descritas anteriormente, existe un gran número de herramientas que facilitan la comunicación, colaboración y calidad a lo largo del ciclo de desarrollo de software y que por lo tanto también se pueden considerar como parte de la “caja de herramientas para DevOps”. Ejemplos de esto son herramientas de control de versiones, pruebas (en sus distintas variantes), análisis de código, gestión de issues, e incluso comunicación entre miembros del equipo.

No he hecho mención específica a estas herramientas porque no considero que sean tan características de DevOps como las mencionadas en las categorías anteriores. Es decir, si desarrollas software profesionalmente, lo menos que puedo esperar, DevOps o no, es que uses control de versiones, tengas suites de pruebas y uses un registro de issues.

A continuación comparto una infografía creada por la empresa XebiaLabs para representar algunas de las herramientas DevOps más populares del mercado, organizadas simulando una tabla periódica de elementos. Definitivamente no es completa ni perfecta, pero no deja de ser un buen ejercicio que espero les sirva para tener una mejor perspectiva de esta caja de herramientas.

Tabla Peri贸dica de Herramientas DevOps v1. Creada por Xebian Labs.

Versi贸n original disponible en https://xebialabs.com/periodic-table-of-devops-tools

EN PORTADA P

SG.COM.MX

025

V

VOCES

Calidad no es Testing, ni Procesos, ni Certificaciones — Por Raúl Martínez

Raúl Martínez se especializa en Gestión de Proyectos de TI y calidad de productos de software. Es docente de la Facultad

de

Ingeniería

Quienes intentamos construir software y dar servicios perceptibles como de calidad por el cliente, nos preguntamos continuamente si debemos efectuar más pruebas, buscar nuevos procesos y certificaciones. Si bien estos conceptos sí tienen relación a la calidad, por sí solos no son suficientes para determinarla.

conjunto de todo un equipo, incluyendo desde quién detecta la necesidad hasta quién materializa la solución. La responsabilidad es compartida.

Si lo imagináramos como pasos secuenciales, realmente no lo son, se vería algo así:

(UBA) y socio fundador de la consultora RMyA. Se

Tomemos dos visiones típicas, y distintas, de la calidad:

interesa en la mejora de procesos, gestión de proyectos, gestión de la cali-

Calidad es conformidad a requerimientos (parte de los postulados de P. Crosby)

dad y emprendedorismo. rmartinez@rmya.com.ar

Calidad es valor para alguna persona (G. Weinberg) Ambas la definen, pero en forma diferente. La primera es la visión ingenieril, la segunda está relacionada con la experiencia del usuario.

Elaboremos un poco más sobre los conceptos de testing, procesos y certificaciones mencionados al comienzo.

• El testing nos permite validar si un producto cumple o no un requerimiento funcional y otros atributos de calidad definidos para él.

• Los procesos nos indican cuál es la forma recomendada para realizar una actividad o conjunto de ellas.

• Las certificaciones nos permiten demostrar el conocimiento y aplicación de mejores prácticas.

Todo lo mencionado concuerda bien con la visión ingenieril de la calidad. Sin embargo, de acuerdo a la segunda definición, para el cliente un producto o servicio se considerará de calidad, si cumple con sus expectativas. Y estará dispuesto a “pagar” por ello, en el sentido más amplio, si esto ocurre.

El cliente espera que nuestro producto/servicio cumpla con los requerimientos y lo haga en forma correcta, pero eso es sólo parte de sus expectativas y en general lo asume como lo mínimo necesario, asignando un valor relativo a dicho cumplimiento. Es como esperar que un reloj nos dé la hora correcta, parece obvio que lo hará. Cumplir las expectativas entonces implica mucho más que lograr conformidad con un requerimiento funcional o no funcional.

1. Encontrar un problema del cliente no resuelto y de importancia.

2. Proponer distintas soluciones y obtener retroalimentación.

3. Volver a proponer, acercándonos más a lo esperado.

4. Realizar la especificación del producto/servicio.

5. Probar de acuerdo al modelo de trabajo seguido, en base a la especificación generada.

Los puntos 1 a 3 son experimentales, más que una validación formal contra requerimientos. Es inútil esperar requerimientos formalizados en esta etapa de descubrimiento.

Conclusión Debemos seguir probando, definiendo procesos repetibles y capacitarnos u organizarnos en forma demostrable. Pero debemos estar conscientes de que no basta con esto; son condiciones deseables pero no suficientes para lograr la calidad. A todo ello debe sumársele el trabajo en equipo, la responsabilidad compartida, el espíritu investigativo, la visión del negocio y la curiosidad.

Los requerimientos implementados y operando correctamente, harán crecer nuestro producto hasta un punto; si logramos satisfacer expectativas del cliente y tenemos éxito, inevitablemente la competencia nos copiará y tendremos nuevamente un producto estándar. Ser competitivos implica pasar ese punto y sobresalir entre los iguales, con lo cual el ciclo comienza nuevamente. ¿Cómo podemos hacerlo?, ¿qué nos ayudará a encontrar esas nuevas expectativas?

Esto puede ser motivo de otra conversación.

Referencias

Ahora bien, ¿qué significa en la práctica traspasar el límite de lo estándar y tener un producto exitoso y de calidad superior? En principio, significa un trabajo

026

SG.48

[1] J. McCall. Factors in software quality. NTIS, 1977.

[2] B. Kitchenham & S. Pfleeger. Software Quality: The elusive target. IEEE, 1996.

[3] D. Garvin. “What does Product Quality really mean?” http://swgu.ru/qs

E

ESTRATEGIA DE TI

La Gestión del Conocimiento en las Organizaciones MÁS ALLÁ DEL SEGUNDO HOLOCAUSTO — Por Israel Ortega Cuevas

Tenemos que aprender a mirar cara a cara la realidad.

Inventar, si es preciso, palabras nuevas e ideas nuevas para estas nuevas y extrañas realidades que nos han salido al paso.

Pensar es el primer deber de la ‘inteligencia’. Y en ciertos casos, el único.

Octavio Paz en “El laberinto de la soledad”

Aunque el “cambio constante” es un concepto organizacional ampliamente mencionado por Peter Senge en su famosa obra La quinta disciplina [1], existe un concepto bastante similar que es un elemento filosófico de una religión ancestral: “el cambio continuo”. De acuerdo al budismo tradicional “solo existe una ley en el universo que no está sometida al cambio: esta ley es que todas las cosas cambian y que nada es permanente” [2]. Sin embargo, parece que en gran parte de las organizaciones mexicanas no presta oído a esta verdad milenaria, y sigue en boga el sentimiento de que hay que seguir realizando las cosas como siempre se han hecho y que todo permanecerá igual. A pesar del tímido inicio de la apertura neoliberal durante los ochentas y su continuación frenética en los noventas, un gran número de organizaciones no se adecuaron a la necesidad imperante de competir globalmente.

Este evento fue el primer “holocausto” de la empresa mexicana.

El segundo “holocausto” está viviéndose en este preciso momento y se está tragando a las empresas que sobrevivieron y que no están poniendo su atención en la gestión del conocimiento organizacional por medio de las TIC. Las empresas tienen que aprender continuamente utilizando ese gran monstruo tecnológico si quieren sobrevivir a este segundo gran “holocausto”.

Pero regresando a cuestiones más básicas: ¿qué entendemos por la gestión del conocimiento organizacional? Podemos suponer que uno de los ejemplos más antiguos de la aplicación de este concepto fue cuando los primeros “homo sapiens” inculcaron en sus sucesores las rutas que debían recorrer anualmente en sus inicios nómadas. La observación de los elementos del paisaje y la realización de las primeras señalizaciones rudimentarias con piedras, troncos y dibujos en muros permitió contar con el primer tipo de conocimiento que era generado y que posteriormente también era adquirido por clanes amigos. Este conocimiento de las rutas ancestrales tuvo que ser organizado para tener sentido.

Así la ubicación de un sitio de pesca o el lugar donde se podían encontrar los frutos en ciertas temporadas del año resultó fundamental para la supervivencia. En sus inicios el conocimiento era resguardado por medio de la palabra hablada, posteriormente

evolucionó hacia la utilización de elementos tallados o gráficos y finalmente conllevó a la escritura. Este resguardo en medios físicos logró la asimilación de sucesos en beneficio de los individuos que conformaban el clan y en lo que finalmente sería la consumación concreta de esta gestión: la utilización del conocimiento.

Así queda establecido que la gestión del conocimiento es una ventaja competitiva que permitió en sus inicios sobrevivir a la humanidad y que ahora es la acción que impulsa a las organizaciones a mantenerse y adaptarse exitosamente [3]. El conocimiento, que forma parte de los activos intangibles, permite a las organizaciones privadas enfrentarse a la apertura de mercados y a la competencia con empresas transnacionales. Para las organizaciones públicas significa adecuarse exitosamente a los cambios tecnológicos para responder eficientemente a los ciudadanos.

Diversos autores han tratado de establecer cuáles son los procesos involucrados en la gestión del conocimiento. Para propósitos prácticos, tales procesos se pueden resumir en los siguientes: generación, adquisición, clasificación, resguardo, utilización y aplicación. No es mi propósito ahondar en cada uno de estos procesos, sino establecer cómo puede realizarse su sistematización por medio de las TIC. Todas las organizaciones manejan estos procesos, aunque muchas veces de manera inconsciente o informal. Por otra parte, la sistematización de la gestión del conocimiento puede ser un gran esfuerzo desperdiciado si no es implementada tomando como referencia lo que la organización es, hacia donde debe dirigirse y qué es lo que realiza. Enfocarse a una solución enteramente informática para gestionar el conocimiento y poner confianza ciega en que la tecnología va a resolver las deficiencias de la organización puede ser una trampa mortal. Encargarle este proceso al departamento informático de una organización puede derivar que la sistematización se vuelva el fin y no el medio de transferencia del conocimiento.

Pero, ¿cómo se logra la sistematización de la gestión del conocimiento? La respuesta no es única y depende de cada organización.

Israel Ortega es Maestro en Administración con especialidad en Tecnología e Ingeniero en Computación por la UNAM. Miembro del grupo promotor de la Red Universitaria de Colaboración en Ingeniería de Software y Base de Datos. Ponente en el Congreso Internacional de Investigación e Innovación en Ingeniería de Software, (CONISOFT) en su edición 2015. Labora en el Departamento de Base de Datos y Servicios Web de la Dirección de Sistemas de Personal UNAM.

028

SG.48

ESTRATEGIA DE TI

E

La gestión del conocimiento es una ventaja competitiva que permitió en sus inicios sobrevivir a la humanidad.

Sin embargo existen dos rubros de referencia, el primero está orientado a la finalidad de la organización y a la alineación de objetivos con su personal. Para esto se toma en cuenta elementos tales como la misión, visión, habilidades, valores, logros; en resumen, lo que converge en lo que llamamos cultura organizacional. El segundo rubro corresponde al uso de las tecnologías informáticas y de la comunicación, en lo que puede llamarse de una forma poética: “la filosofía de la información”.

Para que el primer rubro tenga éxito, se deben tomar en cuenta las siguientes prácticas: • identificar las necesidades de recursos e información, • realizar prácticas para conocer opiniones y grados de satisfacción de los usuarios, • implementar técnicas de trabajo en equipo que inciten a compartir conocimiento, utilizar los sistemas de comunicación organizacional, establecer el reconocimiento formal de logros [4], • mantener una cultura de puertas abiertas, apoyar en la aplicación de nuevos conocimientos y la creación de una visión compartida.

En cuanto al segundo rubro, la sistematización de la gestión del conocimiento, propone que mediante la utilización de las TIC se promueva entre otros factores el intercambio de ideas, la notificación de reuniones tanto formales como informales, la transmisión del conocimiento tanto adquirido como generado, creación de un repositorio único de contenidos, etcétera; todo mediante una interfase informática única de acceso al conocimiento organizacional.

La utilización de la innovación derivada de las redes sociales en el ámbito de la distribución de las ideas, puede redundar en el reconocimiento personal por medio de las aportaciones a la base clasificada del conocimiento organizacional.

La incorporación a una organización de un Sistema de Gestión del Conocimiento tiene tres tipos de implementación: 1. La utilización de un software comercial ofrecido por un proveedor de soluciones tecnológicas para la gestión del conocimiento. El inconveniente es que frecuentemente requieren que los procesos de la gestión del conocimiento se acoplen al funcionamiento de un sistema informático y pueden resultar invasivos para la cultura organizacional.

2. La segunda forma de afrontar la sistematización es por medio de herramientas basadas en software libre. La utilización de estos instrumentos redunda en un conjunto de soluciones tecnológicas de bajo costo, pero posiblemente sin toda la funcionalidad deseada o que requieran una gran cantidad de ajustes para adecuarse a las necesidades de la organización.

3. El tercer camino consiste en elaborar una solución ad-hoc a la organización. Las principales ventajas de tomar este camino es que se pueden acoplar las herramientas tecnológicas a la cultura

organizacional, se toma en cuenta el reconocimiento personal, logra la participación fluida de los integrantes de la organización, etc. La desventaja es que se requiere un grupo informático dedicado al entendimiento de la organización, así como la ejecución de un proceso de ingeniería de software: análisis, diseño, implementación y mantenimiento de aplicaciones.

Para una organización con ejecutivos que no tengan una visión de la importancia de la gestión del conocimiento, esta puede parecer un derroche de recursos organizacionales para un fin diferente al objeto y razón de ser de una empresa. El apoyo de la dirección es de vital importancia para la ejecución de la sistematización de la gestión del conocimiento. La aceptación de tal proyecto, de forma que el personal no lo considere un trabajo añadido a sus actividades laborales, dependerá también del éxito de la dirección para fomentar y hacer sentir la importancia de cada integrante como generador del conocimiento.

Conclusión Parafraseando a Octavio Paz, tenemos que inventar ideas y palabras nuevas para enfrentar las nuevas realidades que nos salen al paso. El “cambio continuo” se está acrecentando y las organizaciones deben poner especial atención: la sistematización de la gestión del conocimiento permite que las organizaciones nacionales enfrenten e ideen la investigación, la innovación y el desarrollo de productos, servicios y procesos que se adecuen a los “nuevos tiempos” con los recursos con que ya se cuenta. Nosotros, con un propósito práctico ya establecimos la importancia de la gestión del conocimiento y su desglose en sus procesos —generar, adquirir, clasificar, resguardar, transmitir y aplicar—; se estableció la relación de la sistematización de la gestión de este activo con la cultura organizacional y la importancia de la utilización de las TIC. Tomar conciencia de la importancia de estos puntos mediante la sistematización y llevar el conocimiento a la “acción” es lo que permitirá a las organizaciones mexicanas evadir el segundo “gran holocausto” y mantenerse en competitividad.

Referencias [1] P. Senge. La quinta disciplina. Editorial Granica, 2011. http://swgu.ru/qo [2] S. Rimpoché. El libro tibetano de la vida y la muerte. Ediciones Urano, 2006. http://swgu.ru/qp [3] Y. Altamirano, I. Ortega. Propuesta de un modelo de gestión del conocimiento: ejemplo de aplicación en una PyME. Congreso Internacional de Investigación e Innovación en Ingeniería de Software 2015. http://swgu.ru/qm [4] D. Palacios, F. Garrigós. Propuesta de una escala de medida de la gestión del conocimiento en la industrias de biotecnología y telecomunicaciones. Investigaciones Europeas de Dirección y Economía de la Empresa. Vol. 12, No. 1, 2006. http://swgu.ru/qn

SG.COM.MX

029

V

VOCES

Más Allá del Software PARTE 3. DESARROLLO DE SERVICIOS ALREDEDOR DE UN PRODUCTO DE SOFTWARE — Por Víctor Hernández

Victor Jesús Hernández Salinas es Coordinador de Servicios de Productos en INFOTEC. Desde 2003 colabora en INFOTEC en el equipo de Desarrollo de Nuevos Productos y Servicios. Fue creador y Coordinador del área de

Cuando un cliente adquiere una solución tecnológica, el producto de software como tal es tan solo una pequeña parte de la solución. La infraestructura y servicios asociados cada vez forman un componente de mayor importancia. Por ejemplo, ¿en qué infraestructura operará el software?, ¿cómo se capacitará a los usuarios?, ¿cómo podemos configurar o extender el software para incluir particularidades de nuestro proceso de negocio?

servicios a producto y su normatividad. Es además coordinador

del

pro-

grama de certificaciones para SWB.

Es así que al crear un negocio basado en productos de software, debemos estar conscientes de que requerimos establecer una infraestructura de servicios alrededor de dicho software para resolver las necesidades de los clientes. Asimismo, también requerimos servicios que nos permitirán mercadear dicho software.

Desde un inicio debemos considerar este tipo de servicios dentro de nuestro modelo de negocio. El desarrollo de servicios comienza desde las etapas de definición y planeación de lo que será el producto tecnológico, al describir la misión y objetivos de éste, así como las funcionalidades que contendrá y el público objetivo al que atenderá. Para los servicios se incluirán una serie de disciplinas diversas para cubrir aspectos que van desde publicidad, capacitación, soporte técnico, gestión de redes sociales, entre otros.

Es importante definir qué tipo de servicios se otorgarán para poder armar no solo una estrategia comercial, sino una estrategia técnico-operativa para dar soporte a los clientes y asegurar que saquen provecho de nuestro software (ya que solo así nos seguirán comprando).

Al igual que a un producto le definimos metas y objetivos, los servicios también deberán contar con su propia visión y misión. Lo importante es definir los mecanismos que permitan lograr la atracción, preferencia y lealtad de los clientes. Los servicios deben enfocarse en cuatro aspectos fundamentales: 1. Entender los requerimientos del cliente.

2. Conocer los costos de servir al cliente.

3. Entender la oferta y costo de la competencia.

4. Potencializar el desarrollo de cadenas integradas con clientes y aliados.

030

SG.48

Valor estratégico y económico El término valor estratégico refiere a la posición de una empresa en el mercado para captar y defender demanda frente a sus competidores, mientras que el valor económico habla de la rentabilidad en términos de retorno sobre el capital invertido y valor de capitalización en el mercado. Por lo que es de suma importancia que al planear los servicios que acompañen a un producto, la empresa debe evolucionar integralmente para lograr un mejor posicionamiento en el mercado y entendiendo que las marcas no son razón suficiente de compra, mientras no estén respaldadas por un valor real para el cliente.

Es importante también analizar a la competencia, lo que implica que debemos comparar su oferta de productos y servicios contra la nuestra. Una estrategia cada vez más efectiva es aprovechar el desarrollo de cadenas integradas con clientes y aliados para identificar el valor de cada participante (recuerda que la percepción de valor del fabricante es distinta a la del mercado, puesto que la primera se basa en el costo del desarrollo, mientras la segunda radica en el valor de tener el producto y los beneficios que se obtendrán), además de establecer incentivos acordes con la integración pretendida.

Por último, se deben involucrar los procesos, decisiones, información y alianzas o convenios en la consecución de estrategias ganar-ganar. Es necesario el gestionar algunos aspectos que le darán fuerza al medio ambiente donde vivirá el producto, para ello se considera el promover acciones para diseñar cuál debe ser la experiencia de uso del producto y así centrarse en el cliente y no en el producto o servicio.

De igual manera, deberemos tomar en cuenta el desarrollo de capacidades, combinando aspectos humanos, tecnológicos y procesos de negocio, recurriendo a convenios o alianzas cuando sea conveniente. El punto es poder concentrarse en el desarrollo y mantenimiento del producto y mejorar la experiencia de usuario de los clientes. Esto nos llevará a pensar en los procesos para la ejecución de los servicios, de los cuales hablaremos la próxima ocasión…

H

CARRERA

La Ética en el Hacking — Por Francisco Lino

Hablar de “Ethical Hacking” es una tarea complicada, principalmente debido a malas interpretaciones del término “hacker”.

Esto ha resultado en la creación de términos como “white hat hacker”, “grey hat hacker” y “black hat hacker”, los cuales han sido creados para tratar de explicar algo que la mayoría de las personas no logran entender del todo: el hacking y los hackers.

Actualmente nos encontramos inmersos en una sociedad que lentamente ha comenzado a integrarse a un mundo tecnológico, la cual se caracteriza por facilitar el acceso a dicha información en cualquier momento y casi en cualquier lugar. Sin embargo, dicha conectividad no implica de ninguna manera el conocimiento y sabiduría de los usuarios. De esta manera, hemos llegado vivir en una sociedad, que si bien cuenta con múltiples facilidades para mantenerse conectado e informado en todo momento, carece del conocimiento, madurez para utilizarlo y principalmente el interés para hacerlo.

Bajo esta perspectiva, resulta peculiar el intento por parte de los medios de comunicación, de explicar un concepto que resulta totalmente nuevo para ellos. Si bien los hackers existen desde el principio de la era digital, no es sino hasta fechas recientes cuando se puede observar la imperante necesidad de explicar — mas no entender— una cultura que ha comenzado a deformarse olvidando sus raíces y que poco a poco ha comenzado a perder una de sus principales características: la ética.

Debido a que la cultura hacker se encuentra en auge, es posible encontrar cursos y escuelas que pretenden enseñar el arte del hacking a sus alumnos. Sin embargo, para lograr esto es imperante conocer las bases sobre las que esta cultura fue cimentada.

Este documento pretende describir los fundamentos para la comprensión y enseñanza del Ethical Hacking y de esta manera evitar el mal uso e implicaciones que esto puede causar.

Hacking, orígenes y términos Existen múltiples teorías respecto al origen de la palabra “Hacker”, no obstante la mayoría relaciona la aparición de esta palabra con uno de los inventos que ha permitido la existencia de lo que actualmente conocemos como internet: el teléfono. Adicionalmente, este término ha sido relacionado continuamente con el Instituto Tecnológico de Massachusetts (MIT) enfocándose en las décadas de 1950 y 1960.

De entre la enorme cantidad de teorías existentes, destacan particularmente tres de ellas que describen una de las características fundamentales del hacking: el espíritu.

La primer teoría describe que durante dichas épocas, en el MIT era utilizada la palabra “hack” para definir una solución simple, creativa y elegante para un problema, sin embargo muchos de estos hacks eran en realidad bromas pesadas, las cuales fueron evolucionando hasta convertirse en hazañas debido principalmente a la combinación de conocimientos especializados e instinto creativo. De esta manera, dentro del campo de la informática, dichos hacks se convirtieron poco a poco en proezas dentro del campo de la programación [1].

Otra de las teorías se enfoca nuevamente en el MIT, específicamente en el club de maquetas de trenes, los cuales al recibir una donación de componentes, en su mayoría equipo telefónico, desarrollaron un sistema que permitía a múltiples operarios controlar diferentes tramos de las vías utilizando el teléfono para comunicarse con las secciones adecuadas. Este uso del equipo telefónico seria denominado hacking [2].

Finalmente, la tercer teoría se enfoca en la compañía AT&T, la cual en 1878, durante los primeros años de la telefonía, contrató a un grupo de adolescentes para fungir como operadores telefónicos del sistema Bell, lo cual resultó ser un desastre ya que estos preferían curiosear que hacer su trabajo, y entre otras cosas comenzaron a hacer bromas a los clientes, desconectando llamadas o bien cruzando líneas, por lo que los clientes terminaban hablando con desconocidos. Si bien esta teoría no involucra directamente el término hacker, es posible apreciar ciertas semejanzas con las dos teorías anteriores, específicamente en el detalle en común que comparten: el espíritu adolecente, aventurero e inquisitivo, el cual daría forma a las primeras generaciones de hackers [3].

Con el paso del tiempo, el término hacker ha ido sufriendo modificaciones con la finalidad de hacerlo más comprensible para la sociedad. Sin embargo, desde sus orígenes dicho término ha sido utilizado para definir a los individuos que forman parte de una subcultura enfocada en el conocimiento, el descubrimiento, el aprendizaje y el funcionamiento de las cosas, específicamente todas aquellas relacionadas con la computación [4].

En este punto es sumamente importante destacar que si bien la cultura hacker se enfoca en las características mencionadas con anterioridad, también se trata de una cultura altamente competitiva y llena de desafíos, por lo que el término “Hacker” es considerado prácticamente un título honorifico y solamente puede ser otorgado por la propia comunidad, única y exclusivamente a personajes que hayan contribuido de manera notable en el desarrollo de

Francisco Lino (@f3r3nczy) es Ingeniero en Computación egresado del IPN, en proceso de titulación de maestría en Seguridad de TI y actualmente miembro de la 10° Generación de becarios de Seguridad de TI del CERT UNAM. Repudia estereotipos como geek, gamer, principalmente a los autodenominados “hackers” y el uso indiscriminado de esta palabra.

032

SG.48

CARRERA

la misma. Motivo por el cual, cualquier persona que se autodenomine “hacker” únicamente demuestra su propia ignorancia.

La ética del hacker surge entonces, a partir del uso del conocimiento obtenido, múltiples autores han intentado definir dicha ética, por lo que es posible encontrar perspectivas, como los principios definidos por Levy [5]: • El acceso a las computadoras —y a todo lo que te pueda enseñar alguna cosa sobre cómo funciona el mundo— debe ser ilimitado y total.

• Toda la información debería ser libre.

• Desconfía de la autoridad —promueve la descentralización.

• Los hackers deberían ser juzgados por su hacking, sin importar sus títulos, edad, raza o posición económica.

• Puedes crear arte y belleza con una computadora.

• Las computadoras pueden mejorar tu vida.

H

hacker maliciosos, sino también aquellos personajes que se dedican a realizar procesos de ingeniería inversa con la finalidad de encontrar vulnerabilidades en el software [8].

Es posible apreciar que incluso con el término cracking existen malinterpretaciones ya que afirmar que todos los crackers o hackers son criminales es similar a afirmar que todos los creyentes del Islam son terroristas o que todos los colombianos son narcotraficantes, por lo que es necesario considerar que en cuanto al bien y el mal no existen absolutos y que en general cualquier persona actuará en determinado momento en base a las necesidades y a la situación a la que se enfrente. De esta forma, considerar como un canon que los hackers son buenos y los crackers son malos o viceversa es algo erróneo, simplemente es una interpretación de la situación en la que dicho personaje fue conocido.

Ethical hacking De manera similar, Himanen aporta su perspectiva [6]: “La ética hacker es heredera de la ética científica, que conlleva un modelo donde las teorías se desarrollan colectivamente y los fallos son percibidos por la potencia crítica de la comunidad. Además, no implica derechos de autor, sólo se pide que se mencionen las fuentes y que las nuevas investigaciones sean publicadas, para beneficio de la comunidad.”

Muy a pesar de estas definiciones, muchas personas consideran que los hackers son personajes oscuros y malignos que solo buscan dañar a las personas, empresas o gobiernos. Lamentablemente en varias ocasiones tuvieron razón, motivo por el cual, el hacking ha sido considerado como una actividad ilegal y perseguido por la justicia de diferentes países.

Bajo este entorno es posible discernir una idea un poco más elaborada de lo que es un hacker, sin embargo, si se desea una definición en el estricto sentido de la palabra, esta podría ser: “Una persona que se deleita en tener un conocimiento íntimo del funcionamiento interno de un sistema, las computadoras y las redes informáticas, en particular. El término es a menudo mal utilizado en un contexto peyorativo, donde cracker sería el término correcto.” [7] Como se puede apreciar, esta definición incluye un término adicional que es utilizado de forma despectiva, es decir “cracker”, el cual era utilizado originalmente para definir a aquellos hackers que utilizaban su conocimiento y habilidades con fines ajenos a la ética y principios originales del hacking.

El glosario de usuarios de internet (RFC 1392), define a un cracker como: “una persona que intenta acceder a los sistemas informáticos sin autorización. Estos individuos suelen ser malicioso, en contraposición a los hackers, y tienen muchos medios a su disposición para irrumpir en un sistema.”

No obstante, dicho término también era utilizado para definir un conjunto de técnicas empleadas para codificar, analizar y estudiar los principios de un programa, sin disponer de su código fuente, por lo que los crackers no solo son miembros de la comunidad

Con el paso de los años, la tecnología ha ido integrándose a la sociedad de manera progresiva. Actualmente la mayor parte del mundo tiene acceso a internet, ya sea desde una computadora casera, una laptop o incluso un teléfono móvil. De manera similar, es posible encontrar una ingente cantidad de sistemas de información, no solo en las empresas privadas sino también en el sector público y gubernamental.

Dicha situación ha tenido repercusiones a nivel mundial, teniendo como ejemplo el impacto económico generado en países como Chile, Republica Dominicana y Panamá, no obstante, uno de los mayores impactos se aprecia dentro de la comunidad hacker, la cual ha saltado a la fama nuevamente. Si bien ya se había presentado ante la sociedad mediante películas, en la actualidad es muy frecuente escuchar sobre algún “ataque” o “hacker” famoso en los noticieros, situación que una vez más ha afectado la reputación de la comunidad, generando nuevamente una perspectiva errónea de la misma.

Bajo este entorno, surge el ethical hacking, el cual propone una nueva visión de una cultura que ha comenzado a devenir, eliminando conceptos como cracking, propone una escala de colores y los define mediante sombreros como si se tratara de vaqueros, entonces tenemos al sombre blanco o White Hat, el cual representa todo lo bueno, el Grey Hat Hacker que no es bueno ni malo simplemente actúa de una manera u otra dependiendo de la situación en la que se encuentre y el Black Hat Hacker, que son los malos del cuento que deberán ser detenidos a toda costa por los buenos.

Y es de esta manera como obtenemos una nueva moda en la que nuevamente el cine distorsiona la realidad del hacking, mostrando la eterna batalla entre el bien y el mal. Lamentablemente, esta situación solo empeora las cosas y es posible observar la degradación de la cultura hacker de mano de las nuevas generaciones, ya que actualmente tenemos hackers trabajando para el gobierno, atacando a otros grupos de hackers de otros países, siguiendo órdenes y apoyando pensamientos que se encuentran totalmente ajenos a la ética original.

SG.COM.MX

033

H

CARRERA

Existimos sin color, sin nacionalidad, sin prejuicios religiosos ... y nos llaman criminales.

Basta con recordar el Manifiesto Hacker [9] para comprender que algo malo está ocurriendo: ... Nosotros hacemos uso de un servicio ya existente sin pagar por lo que podría ser barato como el polvo si no estuviera en manos de glotones hambrientos de ganancias, y ustedes nos llaman criminales. Nosotros exploramos … y ustedes nos llaman criminales. Buscamos conocimiento … y nos llaman criminales.

Existimos sin color, sin nacionalidad, sin prejuicios religiosos … y nos llaman criminales. Ustedes construyen bombas atómicas, hacen la guerra, asesinan, engañan, mienten y tratan de hacernos creer que es por nuestro propio bien, y aún así nosotros somos los criminales. … Sí, soy un criminal. Mi crimen es el de la curiosidad. Mi crimen es el de juzgar a otros por lo que dicen y piensan, no por cómo se ven. Mi crimen es ser más inteligente que ustedes, algo que jamás me perdonarán.

Tristemente, es posible observar que la mentalidad de las primeras generaciones de hackers se encuentra en declive. Si bien el ethical hacking propone una nueva mentalidad respecto al hacking, el término se encuentra mal acuñado y debería limitarse al profesionalismo en la seguridad de la información, ya que en realidad no se trata de hackers en el estricto sentido de la palabra, sino más bien de personas con conocimientos de hacking que brindan su servicio a empresas y/o gobiernos de manera legítima a cambio de una remuneración económica.

La enseñanza del ethical hacking Existen múltiples similitudes entre el hacking y las artes marciales: ambas requieren de esfuerzo, práctica constante y disciplina.

De la misma manera, ambas enseñan a sus adeptos técnicas que pueden infringir un grave daño a sus contrincantes y finalmente, cuentan con una filosofía y ética estrictas. Sin embargo, un practicante de artes marciales no es considerado un criminal por la justicia de un país, si bien es claro que las artes marciales son consideradas “arma blanca” por múltiples sistemas judiciales, el hacking por el contrario es considerado inmediatamente un crimen cuando se enfrenta a la justicia.

El ethical hacking es la medida en la que se pretende reformar esta situación, por lo que su enseñanza debería apegarse a lineamientos similares a los de las artes marciales. Tomemos por ejemplo el Wude Shaolin, es decir los principios del comportamiento virtuoso en las artes marciales, los cuales se dividen en dos aspectos: las obligaciones de la mente y las obligaciones de la acción [10]. En donde las obligaciones de la mente son: • Respeto: para los demás y para uno mismo.

• Humildad: la disposición a ser humildes.

• Justicia: adhesión a los principios morales.

• Confianza: facultad de confiar no solo en uno mismo sino también en los demás • Lealtad: la cualidad de ser leal, la raíz de la confianza.

034

SG.48

Mientras que las obligaciones de la acción son: • Hacer o querer: la capacidad de elección consciente y de la decisión e intención.

• Resistencia: la facultad de soportar condiciones de vida difíciles.

• Perseverancia: la persistencia constante en la adhesión a un curso de acción, una creencia o un propósito.

• Paciencia: la paciencia hace hincapié en la calma, autocontrol, y la voluntad o la capacidad de tolerar.

• Coraje: el estado o cualidad de la mente o el espíritu que le permite a uno enfrentar al peligro, el miedo, o vicisitudes con aplomo, confianza y resolución.

De manera similar a las artes marciales, la primeras enseñanzas del ethical hacking deberían enfocarse en la parte ética–filosófica, recordando los orígenes del hacking, los personajes famosos de esta cultura, las causas y efectos de dicha fama y principalmente la responsabilidad para utilizar el conocimiento correctamente.

Existe un dicho en las artes marciales chinas: Un estudiante buscara a un profesor durante tres años, y un profesor probará a un estudiante durante tres años [11].

Tal como ocurre frecuentemente en la filosofía, especialmente la oriental, esta frase puede interpretarse de múltiples maneras.

Sin embargo, lo que es claro es que en la enseñanza del ethical hacking al igual que en las artes marciales destaca la participación del maestro, el cual transferirá no solo su conocimiento a sus alumnos, sino además en muchas ocasiones sus creencias. Es así que un maestro deberá evitar transmitir valores negativos a sus estudiantes, así como una mentalidad conflictiva, ya que en un futuro dicho alumno podría convertirse en maestro y sus enseñanzas estarán orientadas al fracaso y a ignorar la ética generada por toda una comunidad a lo largo del tiempo.

Por esta razón, con la finalidad de mantener la ética del hacking, los maestros deberán de vigilar constantemente a sus alumnos, saber qué deben enseñarles, cuándo y principalmente a quién hacerlo.

Mediante la observación de sus alumnos y de una definición de diferentes etapas o niveles de conocimiento, destinando los conocimientos avanzados únicamente a aquellos alumnos de mayor confianza.

No obstante, vivimos en una época diferente, en la que el conocimiento se encuentra a la mano de quien sepa y se empeñe en buscarlo, motivo por el cual la figura del maestro podría quedar anulada. Si bien esta situación es altamente probable, llegado a este punto los maestros deberán fungir como guía de los aprendices, algo que puede resultar si la confianza entre ambos ha sido fundamentada y desarrollada correctamente. Por el contrario, si dicha relación de confianza no existe, el maestro deberá advertir al aprendiz respecto al camino que está tomando y en caso de necesidad extrema detenerlo antes de que dañe a alguien.

CARRERA

H

Palabras finales El ethical hacking es una actividad que está teniendo un gran auge, sin embargo la perspectiva que se tiene de él, por lo general es completamente errónea. Si bien ha sido desarrollado con las mejores intenciones, esto no significa que sea lo mejor para la cultura del hacking. Considerando los orígenes de esta actividad, su filosofía, ética y conceptos que la han caracterizado desde sus orígenes hasta la época actual, es posible apreciar su decadencia. A pesar de esto, las raíces son fuertes, las mejores características del hacking se encuentran ahí, debajo de una tonelada de términos erróneos y omisiones.

Si en algún momento se tiene la posibilidad de fungir como maestro de ethical hacking se debe tener cuidado de no cometer los mismos errores y convertirlo en un producto comercial, es necesario contar con una ética bien cimentada, no solo respecto a lo que se debe enseñar o no, sino también en la comprensión de los orígenes, la filosofía y cómo ha evolucionado con el paso del tiempo.

Si bien mucha gente consideraría que un curso o la enseñanza del ethical hacking debe basarse únicamente en una serie de técnicas enseñadas como receta de cocina, esta perspectiva es complemente errónea, ya que el hacking no es únicamente eso, es también una mentalidad, una serie de creencias y valores éticos y filosóficos que no deben dejarse de lado.

La enseñanza debe de ser un proceso meticuloso y que requerirá una inversión de tiempo, tanto por parte del alumno como por parte del maestro, así como un compromiso mutuo que requiere invariablemente de una relación de confianza entre ambos.

Referencias [1] M. Ward, “Breve historia de los hackers y sus andanzas”, BBC Mundo, 2011. http://swgu.ru/q8 [2] J. Erickson. “Hacking: The Art of Exploitation”. No Starch Press, 2008. http://swgu.ru/q9 [3] B. Sterling. “The Hacker Crackdown: Law and Disorder on the Electronic Frontier”. http://swgu.ru/qa [4] F. Pacheco y H. Jara. “Ethical Hacking: Las técnicas de los hackers al servicio de la seguridad”, Manuales Users, 2009. http://swgu.ru/qb [5] S. Levy. “Hackers: Heroes of the computer revolution” . O’Reilly, 2010. http://swgu.ru/qc [6] P. Himanen. “La ética del hacker y el espíritu de la era de la información”. http://swgu.ru/qd [7] G. Malkin, “RFC 1392: Internet Users’ Glossary”. http://swgu.ru/qe [8] J. Zemanék. “Cracking sin secretos, ataque y defensa de software”. Ra-Ma Editorial, 2004. http://swgu.ru/qf [9] L. Blankenship. “The Conscience of a Hacker”. http://swgu.ru/qg [10] “La moral en las artes marciales de Shaolin”. Shaolin Cultural Center Spain. http://swgu.ru/qh [11] S. González, “Wude: El sentido ético de las artes marciales chinas”. http://swgu.ru/qi

SG.COM.MX

035

C

PRUEBA DE SOFTWARE

Los Special Purpose Languages COMO ÉSTOS PUEDEN INCREMENTAR TU PRODUCTIVIDAD — Por Luis Vinicio León Carrillo

Me da gusto estar retomando esta columna, luego de un receso de varios años en los que estuvo a cargo de Berenice Ruiz.

Luis Vinicio León Carrillo es socio director y fundador de e-Quallity. Fue

En el pasado SG Conference & Expo ofrecí la plática “La prueba de software y los special purpose languages”. Dado que al terminar varias personas me sugirieron abundar en el tema, aprovecharé este espacio para hacerlo durante esta y varias entregas más de esta columna.

profesor-investigador en la universidad ITESO, y realizó una estancia de posgrado en Alemania, donde se dedicó a la investigación del Testing y los métodos formales.

A través de los años, el “estado del arte” de la disciplina del software ha estado fuertemente influenciado por el desarrollo de los lenguajes de programación. Es así que hemos pasado por lenguajes con distintos niveles de abstracción, distintos paradigmas (procedural, orientado a objetos, funcional), y ahora también con lenguajes de documentación, de especificación, y de arquitectura, entre otros. Una de las vertientes del estado del arte tiene que ver con lo que desde hace décadas se denomina como “Métodos Formales” (MF).

En términos generales, los MF son una tecnología mediante la cual: 1. Se escribe la especificación del sistema a desarrollar utilizando un lenguaje formal1 (L1) probablemente del paradigma declarativo2, que luego es verificada con intervención humana y procesada mediante un compilador para así generar el código en otro lenguaje formal L2 , el cual representa un diseño de alto nivel.

2. Este diseño a su vez es verificado con intervención humana y procesado mediante un compilador que genera el código en otro lenguaje formal L3 (usualmente del paradigma imperativo).

3. Este código se procesa mediante un compilador para obtener finalmente el sistema ejecutable.

Las verificaciones mencionadas suelen ser

demostraciones matemáticas de que el código escrito en L1 o L2 tiene ciertas propiedades, por ejemplo que los requerimientos en L1 son consistentes (no existen contradicciones entre ellos) y completos (no quedan “huecos” en los requerimientos).

Podríamos decir que en el desarrollo de software siempre se utiliza un tipo de MF, pues finalmente se escribe el código en algún lenguaje Lx, que es procesado por un compilador Cx, el cual usualmente genera código ejecutable en un Ly. Sin embargo, esta transformación suele realizarse solamente para la fase final de las arriba descritas, la generación del código ejecutable a partir del programa escrito en un lenguaje de programación (usualmente imperativo), no para todo el ciclo de desarrollo Requerimientos->Diseño>Programación. Los métodos formales pueden abordar el ciclo completo, y se han utilizado principalmente para desarrollar sistemas críticos (aquellos en los que literalmente, si el software falla, hay personas que mueren), pues permiten entregar software que se demuestra que es libre de defectos.

Como ustedes sabrán, en e-Quallity nos especializamos en la prueba de software. Sin embargo ya desde el primer artículo que escribimos en SG hace 10 años (mayo de 2005) [1] escribíamos que es muy importante estar al tanto del desarrollo de la disciplina de los métodos formales, pues eso puede tener un enorme impacto en la manera no solo en la que realizamos pruebas, sino también en la que desarrollamos software.

La aplicación de métodos formales nos abre la posibilidad de desarrollar lenguajes propietarios para incrementar la productividad y la calidad en el desarrollo de software, pues vemos que el diseño y la implementación de lenguajes han sido muy poco explotados en nuestro país, aun cuando es algo que puede tener un gran impacto en nuestra competitividad.

Los lenguajes formales tienen una definición precisa de su gramática, usualmente utilizando nomenclaturas como la Backus- Naur Form (BNF) o los Grafos de Sintaxis.

2 Los lenguajes de programación de este paradigma ofrecen tanto construcciones que ayudan a especificar la estructura del problema, como mecanismos internos que facilitan su solución. Un caso prototípico es el lenguaje PROLOG. 1

036

SG.48

PRUEBA DE SOFTWARE

En las siguientes entregas de esta columna veremos con más detalle “con qué se come” eso de desarrollar lenguajes propietarios, pero en general estaremos hablando de aplicar dos conceptos muy generales pero bastante poderosos: lenguajes y patrones. La ciencia puede verse como el descubrimiento y/o la invención de patrones que explican o describen cosas.

Para el siguiente lenguaje/patrón, consideren la sustitución planteada en la figura 1.

C

Lo que está a la izquierda del símbolo “=>” debe sustituirse por lo que está a su derecha. La sustitución ocurre siempre “en paralelo”; es decir: que todas las apariciones de lo que está a la izquierda de “=>” deben sustituirse por lo que está a la derecha simultáneamente. Partiendo de “|”, realicen 3 ciclos de sustituciones y piensen qué podría representar ese patrón/lenguaje.

En el siguiente número platicaremos más sobre este tipo de lenguajes/patrones y cómo se relacionan con los métodos formales.

Referencias [1] L. León. “El Contexto de la Prueba de Software”. SG Software Guru #03, Mayo-Junio Figura 1. Ejemplo de patrón de sustitución

2005. http://sg.com.mx/revista/03/el-contexto-la-prueba-software

SG.COM.MX

037

P

ARQUITECTURA

Arquitectura Pull vs. Push en Aplicaciones Móviles CONSIDERACIONES AL ELEGIR — Por Carlos Martinez

Prácticamente todas las empresas tienen la necesidad de brindar acceso a sus sistemas empresariales desde dispositivos móviles. Los desarrolladores de estas aplicaciones móviles requieren construir soluciones que no solo provean la funcionalidad deseada, sino que también brinden la mejor experiencia posible al usuario, optimizando aspectos como el desempeño y consumo de energía.

Una estrategia comúnmente utilizada para brindar acceso a sistemas empresariales desde aplicaciones móviles es exponer servicios web por medio de los cuales podamos interactuar con la información en el servidor. Sin embargo, al hacer esto es importante que analicemos las implicaciones de concurrencia, rendimiento y consumo de energía.

Para resolver esta necesidad, típicamente se recurre a una de estas dos estrategias: utilizar una arquitectura pull o una arquitectura push.

Arquitectura pull Este tipo de arquitectura consiste en que el cliente móvil periódicamente está preguntando al servidor si hay actualizaciones de información, y en caso de ser así descarga la información y actualiza su vista correspondiente. Pull significa “jalar”, y justamente eso es lo que estamos haciendo, jalar información desde el cliente móvil. Este tipo de arquitectura es sencillo, pero tiene un consumo de recursos elevados del lado del cliente ya que involucra tener un proceso persistente que continuamente esté preguntando al servidor si hay cambios.

Arquitectura push En este caso la comunicación es iniciada por el servidor, y de ahí se deriva su nombre ya que el servidor está

“empujando” información hacia los clientes cada que hay un cambio. Esto es realizado por medio de una suscripción que hace el dispositivo cliente hacia el servidor, el siguiente paso es el establecimiento de una comunicación constante con la creación de un socket de comunicación que es gestionado totalmente por el servidor, y de este modo, es éste quien por medio de la suscripción realizada con anterioridad envía la información necesaria al cliente en cuestión cada que existan datos nuevos. La arquitectura push no solamente es utilizada para el envío de notificaciones, puede ser también utilizada para el envío de información del sistema para optimizar el rendimiento de una aplicación determinada. Es aquí donde debemos explotar al máximo las bondades de este tipo de arquitectura dentro de la fase de diseño arquitectónico de un sistema informático.

Figura 1. Arquitectura pull

¿Cuál es mejor?

Entonces, ¿nunca deberíamos utilizar arquitectura pull? No podemos decir eso, en realidad todo depende de las necesidades y contexto. Antes de decidir cuál arquitectura utilizar debemos tomar en cuenta distintos factores tales como: • Volumen de información que se enviará al cliente.

• Frecuencia de actualización de información en la nube.

• Consumo de datos.

• Relación de rendimiento vs costo.

Estos factores nos ayudarán en la toma de la decisión más adecuada para el sistema que se está diseñando. Debemos tomar en cuenta que una arquitectura no reemplaza a la otra, sino que ambas son complementarias e incluso pueden usarse en conjunto.

Figura 1. Arquitectura push

Conclusión Al construir aplicaciones móviles es muy importante poner énfasis en la experiencia que tendrá el usuario final. No solo debemos asegurarnos de que el sistema funcione correctamente, sino que también ofrezca un rendimiento y consumo de recursos adecuados para el volumen de información que maneja. No importa si eres un desarrollador o un arquitecto de sistemas, en cualquier caso es crucial dedicar tiempo suficiente al diseño, ya sea de componente para los desarrolladores o de sistema para los arquitectos. Dedicar tiempo a estas decisiones arquitectónicas podrá ahorrarnos muchos dolores de cabeza cuando el sistema sea implementado.

Carlos Martinez actualmente se desempeña como consultor de entrenamiento en DW Software especializado en tecnologías móviles. Sigue en contacto, suscríbete a: http://dwsoftware.mx/blog

038

SG.48

SG.COM.MX

039

P

UX

Cómo Generar Ideas Junto a tus Usuarios APLIQUEMOS EL UX COLABORATIVO — Por Misael León

Imagina la situación: estás diseñado un complejo sistema digital y buscando la mejor manera de que un usuario interactúe con él.

Debes tener presentes varios detalles: el código de color, la tipografía correcta, las animaciones, transiciones, diálogos, texto, navegación, arquitectura del sistema, etcétera. En ese mar de detalles es fácil perder la cabeza y tener dudas. El momento en que piensas si lo que estás diseñado realmente resolverá problemas reales de tus usuarios está por llegar. También cuestionarás si el contenido de cada feature y sección tiene sentido en un todo integrado.

Si estas dudas rondan tu cabeza, has llegado a la parte medular del diseño como profesión. De repente, te percatarás de que no estás diseñando pantallas aisladas, sino un producto completo que provocará experiencias subjetivas a sus usuarios. No es posible diseñar ese momento íntimo, la experiencia como tal es personal e interna. Depende de factores emocionales que difícilmente están bajo nuestro control. Lo que sí es posible, es preparar el terreno para que el usuario logre sus objetivos con la herramienta que estamos diseñando y ésta se integre fácilmente a su vida. Pero, ¿cómo hacerlo?, ¿cómo saber qué es lo que las personas sienten y lo que esperan?, ¿cuál es la naturaleza de esos problemas que buscamos resolver con nuestro diseño? Con tantas preguntas y opiniones al aire será difícil; más no imposible.

Existe un enfoque de investigación que te guiará en ese confuso proceso de descubrir las particularidades del público para el cual estás diseñando. Es tan flexible que te permitirá crear tu propio método. Lo que aquí presento son meramente los lineamientos que te permitirán “extraer” de tus usuarios toda esa información difícil de expresar con simples preguntas.

Problemas complejos Los problemas que los diseñadores resuelven no son triviales. Las limitaciones de presupuesto, de negocio, y restricciones técnicas complican tanto el marco de acción, que pedirle a una una sola persona que los resuelva es imposible. Cuando exploramos estas complicaciones y resolvemos solamente un aspecto de ellas, creamos más problemas [1]; cavamos un hoyo para tapar otro.

Esto se debe a la interdependencia de los factores que los crearon en primer lugar. Por ejemplo, si una pizzería quiere introducir la capacidad para ordenar mediante su app oficial, esto crearía nuevas situaciones para los encargados de reparto, cocina, marketing, planeación de compras, e incluso, para los usuarios será algo complicado: ¿Podrán estos crear sus propias combinaciones de sabores? ¿Podrán cancelar el pedido en línea también?

¿Qué sucede si el usuario no tiene efectivo al momento de pagar?

Repentinamente no es tan sencillo desarrollar la idea de ordenar pizzas en línea, ¿verdad? La experiencia se complica para todos. ¿Qué se puede hacer entonces?

Para resolver efectivamente estos problemas complejos se requiere la participación de varios colaboradores de distintas disciplinas.

Entre ellos, desarrolladores, product managers, mercadólogos, ejecutivos de atención a clientes, arquitectos de información, QA testers, e incluso gente común, vamos, los usuarios finales. ¡Sí! Sí es posible juntarlos a todos y en conjunto explorar y resolver estos llamados «wicked problems». Es posible mediante el enfoque de investigación generativo. Y es menos complejo de lo que suena.

Colaborando para entender El objetivo de este tipo de investigación es generar un entendimiento más amplio sobre el problema a resolver. Aquí buscamos entender a las personas para las cuales diseñamos nuestro producto.

Queremos conocer su estilo de vida, qué piensan, cómo viven, sus emociones, sus frustraciones, su modelo mental, sus expectativas, etc. Sin embargo, inherentemente a todas las personas se nos dificulta externar y comunicar con palabras este rango emocional que experimentamos en nuestro interior. Entonces, ¿cómo hacemos que las personas verbalicen estos sentimientos y actitudes?

Las actividades de enfoque generativo se caracterizan por ser una serie de talleres colaborativos en el cual los participantes generan algo tangible con sus propias manos (de ahí su nombre). Puede ser un artefacto, un prototipo, collage, dibujo, mapa, maqueta, etcétera. Este atributo de manos-a-la-obra es debido a que a todas las personas se nos facilita expresar nuestros sentimientos, emociones e ideas cuando tenemos objetos físicos en nuestras manos. Los objetos (llamados tokens) nos sirven como representación de aspectos de nuestra vida diaria. Con ellos es posible ejemplificar fácilmente las interacciones con nuestro entorno, la tecnología y otras personas.

El enfoque generativo y colaborativo supone que las personas no son meramente consumidores pasivos de un producto, sino que reconoce que los seres humanos son instintivamente creativos y buscan tener experiencias significativas con los productos con los que interactúan. Es decir, las personas son los expertos reales en describir su propia experiencia y estilo de vida. Lo complejo es lograr que estos matices se verbalicen mediante una historia coherente sobre lo que perciben y necesitan.

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

040

SG.48

UX

P

Un diseñador como facilitador Un cambio semántico es requerido, los usuarios son ahora los expertos, lo saben. Los diseñadores ya no pueden pretender saber las soluciones de antemano. Un buen diseñador busca primero asegurarse de entender bien el problema antes de pensar en diseñar soluciones. El entendimiento se logra con la metodología adecuada, aplicada a los usuarios correctos.

Veamos a continuación los pasos clave para facilitar un taller de investigación generativa: 1. El primer paso de toda investigación es tomarla en serio. Debes ponerte en un estado mental de curiosidad y alerta. Tener la capacidad de hacer preguntas abiertas y no juzgar las respuestas e ideas de los participantes.

Figura 1. El kit de materiales puede variar dependiendo de cada actividad.

2. Formula una hipótesis sobre problema que estás tratando de explorar y resolver. En este punto no sabemos exactamente las causas de nuestro problema, queremos descubrir qué está sucediendo. Pensar en soluciones solamente entorpece este proceso de descubrimiento.

3. Basado en tu hipótesis, planea las actividades que tus participantes harán durante el taller. Asigna tiempos a cada actividad y define los resultados que esperas lograr. No hay una formula maestra, el único factor a tomar en cuenta es que utilices objetos para ayudar a los participantes a expresar sus ideas. Pueden ser figuras de plástico, post-it, cuerpos geométricos, etcétera. Saca provecho de que las personas son naturalmente creativas y, que en general, son dados a contar sus experiencias cuando tienen objetos para representar lo que les resulte complejo expresar con palabras simples. ¡Haz la prueba!, es como jugar con juguetes de nuevo.

4. Conduce el taller. Tú puedes ser el moderador, pero asegúrate de tener ayudantes durante el proceso. Ellos te ayudarán a manejar a la gente, resolver sus dudas y tomar notas. Regularmente la duración es de máxima de 3 a 4 horas. Dado que son talleres de trabajo exhaustivo, recuerda asignar recesos de 5 minutos de vez en cuando para dejar descansar a los participantes.

• Utiliza tus habilidades de comunicación • Explica las instrucciones y luego guarda silencio; escucha y observa activamente • Siente empatía por los participantes • Identifica los líderes de opinión y a los opositores en el grupo • Captura todo lo que sucede en la sesión, con video si es posible.

5. Interpreta resultados utilizando un diagrama de afinidad. Aquí te digo cómo: • Anota las observaciones en hojas tipo post-it.

• Pégalas en una pared amplia • Invita a colaboradores de otras disciplinas, ¡los usuarios también pueden colaborar!

• Desechen los descubrimientos irrelevantes • Escojan las ideas sobresalientes y descubrimientos inesperados • Juntos agrupen las ideas similares • Busquen patrones de comportamiento y problemas emergentes

6. Para todos los problemas que encontraste trata de responder la pregunta, ¿cómo podríamos resolverlo? Realiza una lluvia de ideas en equipo y generen todas las conexiones posibles. Estas ideas informarán tu diseño y te darán seguridad para tomar decisiones importantes. Documenta los hallazgos en forma de historia, en un storyboard, por ejemplo.

De la duda a la certeza El entendimiento que lograrás con este tipo de interacciones con tus usuarios y los involucrados en la solución del problema será enorme. Es conocimiento que vendrá directamente de la fuente, sin intermediarios. El reto es saber interpretarlo y traducirlo a soluciones efectivas. La investigación de usuarios es un trabajo arduo, pero enriquecedor. En el momento que estés diseñando te darás cuenta que tus decisiones son las apropiadas y que las dudas se han ido. Recuerda que es imposible hablar de UX sin investigar a los usuarios primeramente [2].

Después de todo, las personas son las expertas en vivir su propia vida. Nosotros, como diseñadores, solamente somos facilitadores de herramientas y creadores de significados. Nuestro deber es entender, luego crear.

En el episodio dedicado a Generative Research en The UX Clinic

by Nearsoft [3] puedes ver un caso de estudio donde aplicamos este enfoque de investigación y los resultados que obtuvimos.

Referencias [1] E. Sanders, P. J. Stappers. “Convivial Toolbox: Generative Research for the Front End of Design”. BIS Publishers, 2013. http://swgu.ru/qj [2] M. León. “A La Defensa De Los Usuarios: Siete Técnicas UX Para Cambiar El Mundo”. SG Software Guru No. 47. http://swgu.ru/qk [3] “Generative research: Building Trust To Increase Conversions”. The UX Clinic. http://swgu.ru/ql

SG.COM.MX

041

P

PROGRAMACIÓN

Desarrollo de Sistemas Distribuidos CONSTRUYENDO UN MOTOR DE BÚSQUEDA CON C# — Por Pedro Ramírez

Los buscadores de Google, World of Warcraft, Seti@Home, Bitcoin, Windows Azure tienen algo en común: son sistemas distribuidos. A pesar de utilizarse en sistemas con propósitos tan distintos, comparten ciertas características. En este artículo veremos la teoría y las bases para construir un sencillo motor de búsqueda distribuido.

Antes de entrar de lleno a nuestro buscador, necesitamos conocer un poco de teoría para entender las características de este tipo de sistemas, así como lo necesario para construirlos. ¿Qué es un sistema distribuido?

Un sistema distribuido es un sistema de software cuyos componentes están separados físicamente y conectados entre sí por una red de computadoras, se comunican y coordinan entre ellos pasando mensajes. Dichos componentes interactúan entre ellos para lograr una meta común.

Las tres características principales de un sistema distribuido son: 1. Concurrencia de componentes: Los componentes pueden ejecutar sus acciones de manera concurrente e independiente.

2. No hay un reloj global: Los componentes (nodos) de un sistema distribuido no dependen de un reloj que sincronice o indique las acciones de los distintos nodos.

3. Falla independiente de componentes: La falla de un componente no afecta al resto de los componentes.

Para comunicar los nodos de un sistema distribuido es necesario un middleware; es decir, un software que proporciona un enlace entre programas independientes. Hay distintos tipos de middleware, pero en este caso nos enfocaremos en middleware orientado a mensajes (MOM). Los dos modelos de mensajeo más comunes y soportados por la mayoría de los sistemas de mensajeo son:

Publish-Subscribe (pub/sub) – Los emisores (publishers) no envían mensajes directamente a receptores (suscriptores) específicos, sino que simplemente etiquetan su mensaje con una o más categorías y lo publican, ignorando si hay o no suscriptores recibiendo los mensajes de dicha(s) categoría(s). De manera similar, los suscriptores se suscriben a categorías ignorando si hay emisores publicando mensajes en ellas.

Cola de Mensajes: El publicador envía mensajes a una cola donde son guardados hasta que el receptor los recibe, los mensajes pueden expirar después de cierto tiempo. A diferencia de publish–subscribe, en la cola de mensajes el receptor del mensaje activamente tiene que ir a la cola y buscar por nuevos mensajes.

Nuestro motor de búsqueda usará el patrón publish–subscribe. La principal ventaja de este modelo es que genera bajo acoplamiento, ya que los publicadores y suscriptores no necesitan conocer la existencia unos de otros, y por lo tanto pueden operar independientemente. Al tener bajo acoplamiento, este modelo es más fácil de escalar horizontalmente. En cuanto a las desventajas del modelo, hay que tener en cuenta que nos obliga a tener bien definida la estructura de datos a publicar, y que los suscriptores tengan conocimiento de ella. Es así que si cambia la estructura de datos, hay que modificar tanto al publicador como al subscriptor. Mantener compatibilidad con distintas versiones no es fácil, es más sencillo lanzar nuevos eventos que usen las nuevas versiones de la estructura de datos y crear nuevos subscriptores que escuchen a dichos eventos. Otro inconveniente a tener en cuenta es que dado que el publicador no sabe si hay o no subscriptores, el middleware que distribuye los mensajes debe tener mecanismos que garanticen, en la medida de lo posible, la entrega de dichos mensajes.

El motor de búsqueda El objetivo de este artículo es plantear y resolver un escenario sencillo que pueda ser usado como base para desarrollar un buscador más robusto o incluso cualquier sistema distribuido.

Chief Architect en Scio Consulting, líder y colaborador en varios proyectos open source en distintos lenguajes, siempre aprendiendo y buscando nuevas formas de usar la tecnología. https://github.com/pedro-ramirez-suarez pramirez@sciodev.com

042

SG.48

PROGRAMACIÓN

P

La principal ventaja del patrón publish-subscribe es su bajo acoplamiento.

Siendo así, nuestro motor de búsqueda se encargará de buscar una palabra en archivos de texto que estén localizados en distintas computadoras. Desde una aplicación web publicaremos eventos para lanzar la búsqueda, distintos nodos estarán escuchando por esos eventos y buscarán dicha palabra en el contenido de todos los archivos de texto en una ruta específica; como resultado, los nodos regresarán el nombre del archivo donde encontró la palabra y el número de línea donde fue encontrado.

La figura 1 ilustra el comportamiento del buscador.

RabbitMQ, Websphere MQ, Microsoft Message Queue Server, todos ellos muy conocidos y estables pero basados en colas (queues). Nosotros queremos queremos usar el patrón publish– subscribe por lo que usaremos un servicio que aún está en fase alpha llamado DiPS (Distributed Publish Subscribe), que se puede descargar en http://pedro-ramirez-suarez.github.io/DiPS/ Otra razón por la que usaremos DiPS, es porque hay clientes disponibles para .Net (100% compatible con Mono), Javascript y Ruby. Desarrollaremos nodos buscadores en .Net y en Ruby.

Conectarse con DiPS es muy sencillo. El listado 1 muestra lo que tenemos que hacer.

Listado 1. Conexión a DiPS

Figura 1. Comportamiento del buscador.

Desarrollando el buscador Habiendo elegido el middleware a usar, necesitamos definir los distintos componentes que debemos implementar como parte de nuestra solución.

El proceso es el siguiente: 1. El browser publica un evento de búsqueda con el término a buscar.

2. El middleware informa a los suscriptores el evento de búsqueda les envía el término a buscar.

3. Cada suscriptor itera sobre los archivos de texto locales buscando el término.

4. Cada suscriptor publica un evento con los resultados de su búsqueda.

5. El browser a su vez, es suscriptor del evento “resultados”, así que por cada conjunto de resultados el middleware le avisa al browser y le provee dichos resultados.

Lo primero que necesitamos es definir las entidades que representen los datos de nuestro término de búsqueda, así como los resultados de dicha búsqueda. El listado 2 muestra las clases SearchWord y SearchWordResult. La primera representa el término de búsqueda y la segunda representa una ocurrencia encontrada del término en cuestión, indicando en qué documento y línea se encontró la palabra, así como el texto de dicha línea. Un agente de búsqueda regresaría una lista con 0 a n elementos de esta entidad.

Siendo que cada nodo es independiente, que no necesitan sincronizarse entre ellos con un reloj y que las búsquedas en cada nodo pueden ejecutarse de manera simultánea, nuestro motor de búsqueda cumple con las tres características principales de un sistema distribuido.

DiPS como middleware Antes de empezar a desarrollar el motor de búsqueda debemos escoger el middleware que usaremos. Hay varias opciones como

Listado 2. Entidades para e término de búsqueda y un resultado (C#).

SG.COM.MX

043

P

PROGRAMACIÓN

Ahora necesitamos un mecanismo para disparar la búsqueda de un término. El listado 3 muestra código en javascript que se podría ejecutar en un navegador web para disparar la búsqueda de un término.

Listado 3. Petición de búsqueda desde el navegador (javascript)

A continuación, requerimos definir el código de los suscriptores.

Es decir, los agentes que reciben una petición de búsqueda, la ejecutan y regresan una lista de resultados. El listado 4 muestra el esqueleto del código que usaría un suscriptor para recibir una petición de búsqueda y realizarla localmente.

Listado 5. Despliegue de resultados de búsqueda en el navegador (ASP con C#)

DiPS está bien para experimentar y aprender, pero aún no es un servicio maduro, no recomendaría usarlo en aplicaciones críticas.

Listado 4. Ejecución local de la búsqueda (C#)

El último paso es desplegar los resultados en un navegador web los resultados de los distintos suscriptores (que al enviar resultados se convierten en publicadores). El listado 5 muestra un ejemplo en ASP.Net de cómo se podrían recibir y desplegar dichos resultados.

Puntos a mejorar Los resultados de cada nodo podrían primero preprocesarse antes de ser enviados al proceso que lanzó la búsqueda. De esta manera podríamos hacer cosas como ordenarlos alfabéticamente o por alguna otra clasificación. El motor de búsqueda tampoco implementa un modelo de programación MapReduce, ni organiza, mantiene o busca el contenido de los archivos de texto de manera que las búsquedas sean más eficientes.

044

SG.48

Lo que aprendimos aquí, podemos aplicarlo a cualquier tipo de sistema distribuido, solo es cuestión de separar la funcionalidad en componentes que puedan correr de manera independiente, por ejemplo, podríamos desarrollar un PaaS creando componentes que administren y monitoreen bases de datos, otros para administrar y monitorear servidores web, dns, etc., para resolver problemas científicos que requieran mucho poder de cálculo, podríamos separar los datos y los cálculos necesarios en distintos procesos que correrían en distintos nodos. Una vez que aprendemos las bases y empezamos a pensar desde el punto de vista de un sistema distribuido, empezamos a ver muchas oportunidades de aplicación.

Todo el código fuente del motor de búsqueda, así como otros ejemplos de cómo usar DiPS para desarrollar un chat o el back end de una aplicación web pueden encontrarse en https://github.com/ pedro-ramirez-suarez/DiPSClientSample Adicionalmente, puedes ver una demostración de cómo funciona en https://www.youtube.com/watch?v=2rrBOsE61ZE

SG.COM.MX

045

P

MÉTODOS

¿Cuál es el Algoritmo del Éxito?

UNA REFLEXIÓN SOBRE LA METODOLOGÍA EN EL DESARROLLO DE SOFTWARE — Por Marco A. Dorantes

Crear una solución basada en software es algo que puede conseguirse sin necesidad de poner mucho énfasis en la metodología ejercida; hay casos así. Pero también hay casos en que el éxito de una solución previa provoca el aumento de la demanda por mayor funcionalidad y más soluciones a una mayor diversidad de problemas.

La complejidad aumenta conforme se incrementa la funcionalidad de los sistemas así como el número de proyectos simultáneos. La dificultad para repetir los logros previos aumenta en la medida en que se encuentran situaciones distintas y nuevas. El costo, tiempo y esfuerzo para mantener una pauta constante de entregas exitosas suelen aumentar con relativa rapidez si la complejidad no es administrada. Además, la calidad empieza a disminuir o verse afectada debido a los atajos que suelen tomarse en los intentos por lograr más entregas. A menor calidad, más defectos; por lo que aumenta el tiempo, costo y esfuerzo para entregar, y se entra en una espiral descendente hacia posibles cancelaciones de proyectos y pérdida de clientes y personal interno.

En algún punto en tal travesía, tarde o temprano suele mencionarse la necesidad de “una metodología” que supuestamente ayude a aliviar o evitar tanto los dolores de parto de entregas futuras como también los crecientes dolores de sustentabilidad en producción de entregas previas. En ese punto, incluso, suele mencionarse la necesidad de estrategias para lograr una cultura de “ingeniería de software”. Muy bien por tan buenas intenciones en tanto no se pierda de vista que muchos otros proyectos en muchas partes del mundo, a lo largo de muchos años, han hecho múltiples recorridos de ida y vuelta a partir de las mismas intenciones. No podemos ignorar las lecciones aprendidas y reportadas acerca de las “metodologías” para desarrollo de software. Además, tampoco se justifica ignorar los esfuerzos metodológicos en otras disciplinas análogas a la creación de software; por ejemplo las ciencias o la literatura creativa que también han evolucionado sus metodologías.

Antes de continuar, es pertinente aclarar algo para evitar que las buenas intenciones descarrilen: una cosa es el esfuerzo metodológico —el estudio de los métodos— y otra muy distinta, es la aplicación de un método en particular. Si se confunde un método particular como si fuese metodología entonces aumenta el riesgo de intentar aplicar el mismo método a toda posible situación sin considerar los problemas relacionados con potenciales incompatibilidades entre el método y el objetivo general que se intenta lograr.

Un esfuerzo metodológico suele identificar el esquema subyacente que guarda un conjunto de métodos. En el caso de la creación de software se ha identificado, por ejemplo, que algunas

familias de métodos se componen de los siguientes elementos: un conjunto de conceptos interdependientes, un proceso de desarrollo y un conjunto mínimo de herramientas necesarias que soporten a dicho proceso.

Los métodos con estas características se denominan “métodos sistemáticos”; es decir, se derivan de una conceptualización de la creación de software como un conjunto de elementos interrelacionados (valores, principios, prácticas y patrones) que siempre estarían presentes en todo proyecto exitoso. La breve historia de aproximadamente 70 años de programación de computadoras ha visto varias familias de esos métodos sistemáticos que han gravitado alrededor de distintos paradigmas de desarrollo —estructurado, orientado a objetos, adaptativo, etcétera.

Todo bien, pero ¿cuál método es el más adecuado para un proyecto en particular? ¿Quién está en posición para prescribir los valores, principios, prácticas y patrones a observar por parte de los integrantes de ese grupo particular de proyecto, que tienen en sus manos la encomienda de resolver un tipo de problema en específico? El esfuerzo metodológico es muy importante para un proyecto de desarrollo de software a gran escala, eso no está en duda. Sin embargo, la dimensión de su importancia es tal que ese esfuerzo no debe dejarse principalmente en manos de alguien externo al proyecto. Pretender normar y prescribir desde fuera lo que debe pensar y hacer un equipo de proyecto es una receta para el fracaso.

Los grupos de proyecto que ejercen por sí mismos el pensamiento metodológico suelen auto-gestionarse e interactuar con sus clientes y usuarios en términos del valor de negocio entregado en producción con una pauta continua y con un nivel de calidad sostenido; es decir, el patrón de confianza construido sobre los hechos de la experiencia de clientes y usuarios habla de la calidad de lo entregado. Para tales grupos de proyecto no hay necesidad de intentar una prescripción desde el exterior acerca de sus métodos internos y sus procedimientos de interacción con sus clientes y usuarios, sino que ellos mismos practican la autocrítica de manera habitual y adaptan su mentalidad y su proceder con base en la retroalimentación tanto interna como externa, que ellos mismos buscan con interés propio.

Pero, ¿cómo ayudar a un grupo de proyecto que no ejerce ni cultiva el pensamiento metodológico sino que pretende basar su proceder en la mera obediencia a prescripciones externas? Por otro lado, ¿qué ayuda sería efectiva para un grupo de proyecto que no piensa de manera metódica pero tampoco ofrece mecanismos de visibilidad, gobierno y predictibilidad para sus esfuerzos?

Marco A. Dorantes es un consultor en el desarrollo reflexivo y cooperativo de sistemas computacionales que retornan ganancias. Diseña sistemas de cómputo desde 1987. Su principal interés profesional es la aplicación tanto de las teorías como de las prácticas del pensamiento sistémico para la creación de soluciones de negocio basadas en software. http://agilidad.blogspot.mx

046

SG.48

MÉTODOS

P

Desechar la noción de que una sola metodología es la solución a todo tipo de proyecto.

Así como no hay un camino seguro hacia la madurez profesional, tampoco hay una respuesta segura a tales preguntas. Aun así, ante tales casos se podría intentar diseñar un conjunto de métodos para su propio éxito. A continuación listo seis recomendaciones para quienes planeen diseñar su propio conjunto de métodos.

Aprender a ejercer por sí mismos el pensamiento metodológico.

Indagar diversidad de métodos para entender sus esquemas subyacentes y su relación con el tipo de problemas para el cual es más adecuado cada método. Aprender a distinguir entre la descripción de un método y la prescripción del mismo. Aprender cómo pensar de manera metódica y sistémica: no sólo aprender qué pensar, sino cómo pensar. Aprender a realizar examen crítico de las ideas, con independencia de quién las haya dicho; es decir, reconocer que las ideas son algo distinto que las personas —las personas merecen respeto, pero las ideas merecen evaluación crítica.

Evitar el pensamiento ilusorio (wishful thinking). Desechar la noción de que una sola “metodología” es la solución a todo tipo de proyecto. Si se cuenta con un algoritmo o un procedimiento preciso para resolver problemas o lograr objetivos de negocio entonces no se requiere un proyecto con humanos para la solución sino basta que algunas computadoras ejecuten tal algoritmo una y otra vez para resolver cada problema. Para los casos en que no se cuente con tal “algoritmo del éxito”, entonces cada proyecto requiere su propia combinación de métodos que sean adecuados para el tipo de problema a resolver. Cada método conlleva un esquema subyacente de valores, principios, prácticas y patrones, si tales no están presentes el método simplemente no funciona.

Por ejemplo, si un método requiere la práctica constante para examinar las ideas y las conductas, pero un grupo de proyecto carece del valor humano de la autocrítica, entonces tal método simplemente no funcionará para dicho grupo de proyecto. No tiene ningún sentido efectivo intentar un método sin antes reflexionar si los valores humanos y principios profesionales requeridos están realmente presentes. En tal caso sería pertinente empezar no por el método sino por los valores y los principios profesionales. Dar el ejemplo sigue siendo una buena manera para enseñar valores y principios profesionales.

Aprender de la evolución de los métodos sistemáticos del pasado.

Las familias de métodos conocidos como sistemáticos se componen, decíamos, de conceptos, proceso y herramientas. La evolución a la fecha de tales métodos incluye: 1. preferir una notación ejecutable para representar los conceptos del método en lugar de sólo documentos estáticos con narrativas en lenguaje natural, 2. preferir el control empírico del proceso con estrategias y tácticas «a posteriori» ejecutadas continuamente y en lotes pequeños en lugar de intentar controlar el proceso sólo con racionalizaciones «a priori», 3. preferir herramientas que procesen automática y directamente la notación ejecutable mencionada en el primer punto.

Distinguir entre el uso de métodos diseñados para tareas repetitivas (ej. manufactura) y métodos diseñados para tareas creativas (ej. crear software). Las computadoras son adecuadas para la ejecución de tareas repetitivas y mecánicas, de ahí que la automatización computarizada de procesos en la manufactura moderna de productos físicos tiene un lugar preponderante en la fábrica contemporánea. Se requiere de humanos para diseñar esa fábrica automatizada, pero cada vez menos para actuar como máquinas dentro de la misma; un buen diseño de fábrica evita colocar humanos en tareas repetitivas y mecánicas. Asimismo, se requiere de humanos para diseñar una fábrica de software, pero un buen diseño también evita colocar humanos en tareas repetitivas y mecánicas. El producto final efectivo en software es la ejecución productiva de las instrucciones dadas a la computadora del usuario final, y la fábrica de ese producto final es el sistema operativo mismo. Los planos de fabricación de ese producto final son los artefactos ejecutables que se copian a dichas computadoras cuando se hace una liberación. En otras palabras, lo que hace un programador es diseñar los planos de construcción que serán tomados por la fábrica de software; es decir, el sistema operativo para construir el producto final cada vez que es ejecutado en la computadora del usuario.

Considerar métodos centrados en la premisa de que el código fuente es el diseño. Como implicación directa del punto anterior, un enfoque realista de calidad en desarrollo de software hace girar el esfuerzo metodológico en torno al diseño de los mejores planos de construcción posibles para el software, pues ahí, en dichos planos, y en las propiedades emergentes de los mismos, debe concretarse todo requerimiento, toda especificación, todo esfuerzo de pruebas, todo análisis tanto del problema como de la solución y, en fin, toda metodología realista. De otro modo, los esfuerzos que no tienen una relación con dichos planos, con esa forma de documentos técnicos también llamados «código fuente», permanecen sin materializarse. Por tanto, en el ejercicio metodológico conviene distinguir a los métodos que ayudan a lograr mejor código fuente de aquellos que tan sólo están centrados en otros tipos de documentación no ejecutable.

Preferir métodos de aproximación a la realidad. No hay método infalible, pero son preferibles aquellos que ayudan a explorar y descubrir aspectos de la realidad del caso entre manos, con independencia de cómo quisiéramos que fuese esa realidad, que aquellos métodos que sólo mantienen ilusiones, como la ilusión de control, o la ilusión de avance, sin escrúpulo alguno sobre cuál podría ser la realidad subyacente. Por ejemplo, hay métodos que prescriben gráficas de Gantt para varios meses por delante en un proyecto con condiciones nunca antes combinadas, y a eso lo llaman “gobierno de proyecto”, pero con frecuencia eso tan solo persigue una ilusión de control. Por otro lado, son preferibles los métodos que ayuden a evaluar de continuo la dirección del proyecto con respecto a la realidad productiva desde una perspectiva de valor de negocio entregado por unidad de tiempo.

SG.COM.MX

047

P

AGIL

Agilismo y Efectividad del Negocio — Por Masa K. Maeda

Durante los siete años que llevo ayudando a empresas como coach en Lean y Ágil y más de una década practicándolas he tenido la oportunidad de ver avances fabulosos y también, desafortunadamente, degradación en la práctica ágil. En este artículo comparto parte de estas experiencias, así como el punto de vista que doy a mis clientes para ayudarlos a mantenerse en el camino exitoso.

En toda práctica suele suceder que emergen tres corrientes de aplicación. La primera corriente es la canónica, en la cual se lleva a cabo la práctica siguiendo su definición línea por línea. Las personas que siguen esta ruta suelen ser grandes defensoras de la práctica y consideran que la forma de ser exitoso es apegándose a los lineamientos. Esto en principio tiene sentido porque minimiza la posibilidad de mala práctica. Sin embargo, tiene la desventaja de distanciarse de la realidad. En el mundo real, toda empresa, proyecto y equipo de trabajo es distinto. Aún más, la realidad cambia con el tiempo y las circunstancias por lo que un mismo proyecto podría ejecutarse de forma distinta incluso en la misma empresa y con el mismo equipo, dependiendo de cuándo se ejecute y las circunstancias de ese momento. Es prácticamente imposible contar con una metodología o universal que aplicada de manera canónica nos conlleve al resultado deseado. He visto muchas personas apegarse a la práctica canónica y tener una práctica muy bonita pero fallando miserablemente a nivel de negocio.

La segunda corriente es aquella en la que las personas llevan la práctica solamente en nombre. Es decir, siguen haciendo otras cosas de la misma forma pero con un nuevo nombre, por lo que en realidad no están llevando a cabo esta práctica. Esto garantiza desastre y desafortunadamente el desprestigio de la práctica original. Conforme la práctica lean y ágil se ha popularizado, esta corriente se hace mas y más frecuente porque mucha gente adopta el término porque está de moda pero no se preocupa por aprender y entender la práctica.

La tercer corriente es en la que los practicantes se preocupan por adquirir un entendimiento profundo y se enfocan en adaptar su práctica a la situación de la organización. De las tres corrientes, esta es la menos frecuente, simple y sencillamente porque es la más difícil. Requiere de un mayor esfuerzo tanto de los practicantes como de la organización. Es mucho más fácil simplemente ejecutar una receta que pensar en cuál es la mejor manera de hacer las cosas y adaptar la práctica para mejorar gradualmente.

Por otra parte, la efectividad del agilismo en los negocios requiere de un componente esencial que es el acoplamiento. Existe la frase

popular “ningún hombre es una isla” que se aplica igualmente a industrias, organizaciones, equipos de trabajo y proyectos.

Independientemente de si es Lean, Ágil o cualquier otra práctica, esta se realizará en el contexto de otras prácticas y procesos del negocio, por lo que es indispensable descifrar cómo hacerlas coexistir. He conocido coaches y practicantes ágiles que desaprueban y rechazan otras prácticas y sus practicantes de una manera obtusa tal que llega a generar conflicto en las organizaciones resultando en grandes pérdidas económicas y caos en la relación humana.

Dos de los aspectos que más he enfatizado a través de los años han sido la flexibilidad-adaptabilidad de la práctica y la cohesión con otras prácticas. Una consecuencia de esto ha sido y sigue siendo que algunas personas en las comunidades Lean y Agile me han criticado de manera negativa. No tengo problema con eso desde el punto de vista de libertad de expresión, pero los invito a que reflexionen al respecto. Poco tiempo después de ser coach Agile adopté también Lean y lo fusioné para ofrecer un mejor servicio a mis clientes. En aquel entonces Alan Shalloway y yo éramos las únicas personas aplicando el término lean-agile. Muchos me atacaron pero no me importó pues yo sabía que la combinación de ambos beneficiaba a mis clientes. Cinco años después la comunidad ágil comenzó a prestarle atención a Lean y ha llegado a un nivel tal que casi todo evento ágil en el mundo incluye temas Lean.

A diferencia de muchos consultores que ignoran o atacan directamente las prácticas tradicionales, yo siempre he buscado ayudar a las organizaciones a madurar de forma que sus prácticas tradicionales se lleven a cabo de manera conjunta con las prácticas Lean y Ágil. Mi enfoque ha sido altamente exitoso, mientras que he sabido directamente de clientes el daño tremendo que sus empresas sufrieron como resultado de intentar adoptar ágil con un coach que llegó con espada en mano a atacar todo lo demás. De hecho, durante el último año y medio he notado que ha aumentado en la comunidad ágil la discusión sobre la coexistencia de prácticas ágiles y tradicionales. No estoy proclamando ser un visionario, pero sí considero que mediante un entendimiento profundo de Lean y Agile aunado a mi interés de hacer que mis clientes sean altamente exitosos he logrado tener la claridad mental para ser adaptativo.

A final de cuentas, lo que más importa no es el apego a una corriente metodológica, sino el lograr que nuestros clientes sean exitosos, y el camino para ello típicamente nos lleva a combinar elementos de distintas prácticas. Yo considero que esta adaptabilidad y flexibilidad es lo que en realidad pregona el agilismo.

Masa K. Maeda es el CEO y fundador de Valueinnova LLC USA y el creador del modelo Serious LeAP cuyo libro está próximo a su publicación. Es también consultor senior del Cutter Consortium y miembro del comité de dirección del Agile Testing Alliance. Previamente fue miembro de los equipos fundadores de 4 empresas en USA e hizo investigación y desarrollo en Apple Inc.

048

SG.48

9a. edici贸n

21 de octubre 2015

Mayores informes

eventos@sg.com.mx Tel: +52(55) 5239-5502

SG.COM.MX

049

C

PROGRAMAR ES UN MODO DE VIDA

Los Contenedores AISLAMIENTO, SÍ, PERO… ¿DISTRIBUCIÓN? — Por Gunnar Wolf

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

Discutir acerca de mecanismos de virtualización implica cubrir una gran cantidad de tecnologías distintas. Y no me refiero con esto a diferentes proveedores que ofrecen productos con funcionalidad similar, sino que a herramientas de muy distinta naturaleza, que a veces incluso no parecen tener nada que ver entre sí.

exactamente la misma velocidad que en el hardware nativo) y menor impacto en el resto del sistema (cuando los procesos que forman parte del contenedor no tienen trabajo por realizar, su consumo de recursos es verdaderamente cero, a diferencia de un sistema virtualizado, que debe seguir pendiente a posibles eventos).

La primera acepción que vendrá a la mente de muchos, es la virtualización asistida por hardware, donde una computadora con ciertas capacidades de hardware (disponibles en la arquitectura x86 desde hace ya diez años, y hoy presentes incluso en los CPUs de más baja gama) ejecuta un hipervisor, software específico que se ubica por debajo del sistema operativo y permite que la computadora sea compartida entre distintos sistemas operativos (o distintas instancias del mismo), aparentando ante cada uno de ellos ser una computadora independiente. Como apéndice de esta categoría entrarían los paravirtualizadores, que corren versiones de dichos sistemas operativos que saben que se ejecutarán dentro de una máquina virtual, con lo cual delegan algunos procesos al sistema anfitrión, muchas veces aumentando la estabilidad o reduciendo la penalización de velocidad.

La reducción de flexibilidad referida consiste en que, dado que el núcleo del sistema operativo en ejecución es uno solo, todos los procesos que sean ejecutados empleando esta técnica deben estar compilados para la misma arquitectura y sistema operativo —esto significa que por ejemplo, en un sistema anfitrión x86 con Linux, todos los contenedores deberán ser también x86 con Linux. Esta tecnología hereda directamente de la llamada al sistema chroot(), en 1982. Claro está, a esta simple llamada se tuvieron que agregar numerosas funciones implementando una separación más limpia y completa entre los distintos espacios de nombres. Poco a poco se desarrollaron mecanismos para limitar el uso total de memoria o de CPU de cada contenedor, y aislar la vista de la red que cada uno de ellos puede tener. El primer sistema en implementar lo que hoy conocemos con contenedores fue FreeBSD, en el año 2000; dado que están construidos alrededor de la llamada chroot(), resulta natural que casi todos los sistemas operativos en implementar contenedores sean tipo Unix; en el mundo Windows, hoy en día se tiene la promesa de que la versión 10 incluirá esta característica.

Por otro lado, la emulación de hardware completamente distinto del sistema primario puede también considerarse virtualización. Podemos encontrarla como parte de los kits de desarrollo para dispositivos móviles, en que el código generado se compila para procesadores típicamente de arquitectura ARM, mientras que el desarrollo se efectúa sobre computadoras x86. La emulación incluso cubre a las máquinas virtuales empleadas nativamente, como la JVM (Java) o CIL (.NET): El bytecode compilado para estas arquitecturas no corre nativamente en ningún procesador, son arquitecturas diseñadas para ser siempre emuladas.

Una modalidad más de virtualización es el uso de contenedores. Esta modalidad puede comprenderse mejor si se contrasta con las anteriores dónde está el engaño —o (más bonito) dónde está la magia. En vez de proveer una computadora virtual a los sistemas operativos huéspedes, los contenedores buscan proveer un sistema operativo virtual a conjuntos de programas. ¿Qué significa esto? Que a cambio de reducir la flexibilidad, esta modalidad de virtualización provee un mucho mejor rendimiento (las aplicaciones virtualizadas tienen

050

SG.48

En Linux hay distintas implementaciones disponibles, y que han logrado madurar cada cual a su ritmo. Durante muchos años, la más fuerte fue VServer, pero requería de cambios demasiado invasivos, que nunca fueron aceptados por Linus Torvalds para la rama principal del kernel. Posteriormente se popularizó OpenVZ, la versión libre de Virtuozzo, pero sufrió del mismo problema. Sin embargo, a partir de la incorporación de los grupos de contexto (cgroups) al kernel de Linux 2007, el proyecto Linux Containers (lxc) logró una implementación suficientemente eficaz y sencilla, y es hoy en día la más popular y consolidada.

Distribución basada en contenedores A principios de 2013, se anunció la liberación de un innovador programa que ha cambiado en gran medida las reglas del juego para el despliegue de aplicaciones: Docker. Su principal contribución es que cambia

PROGRAMAR ES UN MODO DE VIDA

C

Docker nos invita a olvidarnos de la seguridad que debe mantenerse como parte de la gestión de cada sistema instalado.

el enfoque: presenta a cada contenedor ya no como una máquina virtual, como una instalación completa de una computadora, sino que como el entorno completo de ejecución de una aplicación.

Esto tiene aspectos muy positivos, pero también tiene otros francamente dignos de cuidado. Pero antes de abordarlos, permítanme explicar un poco.

de los demás que tenga instalado el sistema, se ha optado por – de facto– reconvertir las bibliotecas dinámicas en objetos ligados estáticamente. Claro, esto obliga a que ante la actualización de una biblioteca compartida, cada una de las aplicaciones que la usa sea actualizada también —pero en una era de conexión permanente a Internet, esta idea ha resultado del favor del mercado.

Originalmente, instalar o aprovisionar un contenedor implicaba como paso necesario la instalación del software de sistema tal como si se tratara de una computadora real. La delgada capa de virtualización de los contenedores permitían tomar a un conjunto de máquinas virtuales como si fuera una granja de servidores — Y el trabajo del administrador de sistemas es, a fin de cuentas, gestionar a cada una de las máquinas virtuales cual si fuera un servidor completo — Que si bien es mucho menos complejo que si se tratara de una sola instalación con todo el software bajo el mismo espacio, implica una innegable complejidad. El principal cambio que introduce Docker es que permite generar un contenedor por aplicación, y gestionarlo directamente como si fuera una unidad — ya no una colección de paquetes relacionados.

Distribución y servidores virtuales

Bibliotecas, versiones, infiernos y apps Demos un brinco conceptual a un tema, aparentemente, sin relación. Prometo pronto explicar a qué viene esto.

El desarrollo de los sistemas operativos que empleamos hoy en día cruzó hace unos treinta años por un punto crucial en lo concerniente a su flexibilidad: la introducción de formatos estándar de bibliotecas compartidas, que pueden ser utilizadas entre diversas aplicaciones.

Gracias a ellas, el tamaño de cada uno de los programas se redujo fuertemente (puesto que éstos no tenían que incluir expresamente todas las definiciones que emplean), se estandarizaron interfaces (puesto que diversos programas aprovecharían las mismas bibliotecas ampliamente conocidas), y —muy importante— dado que redujo fuertemente la duplicación de código, mejoró significativamente la seguridad de los sistemas operativos: Ante un error o vulnerabilidad, basta con actualizar una copia del código vulnerable para que todos los programas afectados reciban la corrección.

Uniendo, pues, los dos temas expuestos: La principal contribución de Docker es que convierte el engorroso despliegue de servidores virtuales en un sencillo despliegue de aplicaciones — Y, claro está, de aplicaciones empaquetadas a la moda, con el mínimo de dependencias.

Desde una perspectiva meramente de DevOps, esto suena muy bien.

Sin embargo, también involucra grandes riesgos, como lo ilustran entre otros muchos los textos que han escrito al respecto dos de los desarrolladores de Debian GNU/Linux: Joey Hess [1] y Erich Schubert [2].

En primer lugar, un uso irresponsable de Docker (aunque sea el recomendado por sus desarrolladores) nos puede llevar a confiar en software cuyo origen no necesariamente es el que esperamos, sin saber en qué consisten los cambios y cómo éstos nos afectarán. Los paquetes que dicen ser oficiales de determinadas distribuciones han demostrado haber sido alterados, lo cual debe poner a pensar mal a cualquier administrador de sistemas.

En segundo lugar, y esto me parece más complicado y peligroso aún, el modelo que impulsa Docker nos invita a olvidarnos de la seguridad que debe mantenerse como parte de la gestión de cada sistema instalado. Un contenedor no puede ser creado una única vez y visto, a partir de ese momento, como una app, como un objeto estático e independiente. Y no, cada sistema debe integrar las correcciones a las vulnerabilidades (o simples bugs) que constantemente van apareciendo y siendo corregidas, y un administrador de sistemas siempre debe estar familiarizado con la tecnología que tiene instalada. Resulta inexcusable poner al mismo nivel a un sistema operativo completo y a aplicaciones como Wordpress, pero eso es precisamente lo que ocurre [3].

Claro, surge complejidad del manejo de los cientos de bibliotecas compartidas que se instalan en un sistema típico, de la cual se deriva la expresión “DLL hell” (el infierno de los DLLs). Sin embargo, este es un problema en el que se ha invertido una gran cantidad de trabajo, y la situación hoy en día es radicalmente diferente a la de hace veinte años, cuando se acuñó dicho término.

Obviamente, la tecnología no es mala, y la adopción que ha tenido habla de sus virtudes técnicas. Sin embargo, el uso y crecimiento que ha tenido dejando de lado las buenas prácticas de administración de sistemas, y el impacto que esto puede tener en nuestro campo, merecen ser consideradas.

Ahora bien, ante la popularización de las apps en dispositivos móviles y el abaratamiento del almacenamiento, se impuso el concepto inverso: El empaquetamiento de todas las dependencias dentro de un mismo binario. Para evitar que el usuario final tenga que descargar todas las dependencias que empleó cada desarrollador, y asegurar que cada paquete funcionará independientemente

Referencias [1] “What does docker.io run -it debian sh run?”, https://joeyh.name/blog/entry/ docker_run_debian/ [2] “The sad state of sysadmin in the age of containers”, http://www.vitavonni.de/blog/201503/2015031201-the-sad-state-of-sysadmin-in-the-age-of-containers.html [3] Repositorios oficiales de Docker: https://registry.hub.docker.com/search?q=library&f=official

SG.COM.MX

051

F

FUNDAMENTOS

¿Cuáles son las Palabras Diferentes en el Quijote?

UN EJERCICIO CON ÁRBOLES BINARIOS — Por Manuel López Michelone

El Quijote, de Cervantes Saavedra, es uno de los libros más importantes de la literatura mundial. Pensando sobre el Quijote recientemente, se me ocurrió preguntarme ¿cuántas palabras distintas tendrá y cuáles son? El reto por sí mismo es interesante y en el camino se pueden aprender muchas cosas. Veamos a continuación cómo podríamos resolverlo.

La problemática se centra en la estructura de datos a usar. Por ejemplo, imaginemos que queremos usar un arreglo de palabras para irlas acomodando conforme las vamos leyendo. El primero problema con esto es que no sabemos el total de palabras que hay por lo cual ¿de qué tamaño haremos el arreglo? Bueno, si el Quijote (como está en el Proyecto Gutenberg) tiene unas 2 millones de letras, es razonable pensar que un 20% máximo serán palabras, más o menos 400 mil palabras. Podemos crear un arreglo de 400,000 palabras y esperar que esto sea suficiente, pero definitivamente esta no es una solución ideal.

números que están en este árbol de manera que queden ordenados de menor a mayor, lo que hacemos es muy simple: Partimos del nodo raíz y nos movemos hasta la última rama izquierda posible. Esto nos dará, de acuerdo a la imagen que hemos puesto, en el número 16. Entonces vemos si este nodo tiene rama derecha. Sí, la tiene, y es el 25. Entonces ponemos como primer número el 16 y después el 25. Nos hacemos un nodo atrás y hallamos el 41. Lo ponemos. Vemos si tiene rama derecha. Sí, la tiene, es el 53, pero éste tiene una rama izquierda, que es el 46 y este nodo a su vez tiene la rama izquierda con el valor 42. Entonces ponemos el 42, 46, 53 y ahora revisamos la rama derecha y hallamos que hay un 55. Por lo tanto la lista va quedando así: 16, 25, 41, 42, 46, 53, 55...

Y ahora ya no hay más ramas izquierdas que revisar. Pasamos a la rama derecha del nodo raíz y hallamos que hay un 74. Pero éste tiene un nodo izquierdo, el 65, que a su vez tiene otro, el 63, que a su vez tiene otro más, el 62, por lo que pondremos, 62, 63 y ahora vemos si hay nodo derecho. Y sí, lo hay, el 64. Ponemos ahora el 65 y como tiene rama derecha, ponemos el 70 y finalmente el 74.

Una mejor opción es usar estructuras de datos dinámicas, que van creciendo conforme lo vamos requiriendo. Dicho de otra manera, si necesitamos una nueva variable para alojar un dato, creamos esa variable en tiempo de ejecución.

Una estructura de datos dinámica muy poderosa, es la de los árboles binarios. En una estructura de esta naturaleza tenemos un nodo y dos ramas. En el nodo tenemos la información y en las ramas tenemos apuntadores a otros nodos o bien a nulo.

Para explicar cómo funciona una estructura de árbol binario, imaginemos que tenemos la siguiente lista de números desordenada: 60, 41, 74, 16, 53, 65, 25, 46, 55, 63, 70.

Comenzamos tomando el primer valor (60) y usándolo como nodo raíz. Ahora tomamos el siguiente número (41) y lo comparamos al raíz. Dado que es menor que el raíz, y el raíz todavía no tiene rama izquierda, colocamos el 41 en la rama izquierda del 60 (si hubiera sido mayor lo colocaríamos en la rama derecha). El siguiente número es el 74, así que lo ponemos en la rama derecha del 60. A continuación tenemos el 16, dado que el nodo 60 ya tiene rama izquierda (41), entonces ahora bajamos al nodo 41 y comparamos contra este. 16 es menor que 41, y 41 todavía no tiene rama izquierda así que ahí ponemos al 16. De esta forma generamos nuestro árbol, como se muestra en la figura 1.

Nótese que un árbol de esta naturaleza además nos da una manera intrínseca de ordenar información. Si queremos desplegar los

Figura 1. Ejemplo de un árbol binario.

Si queremos ordenar el árbol de los números mayores a los menores, lo que tenemos que hacer es recorrer el árbol al revés, primero empezar por la rama derecha. Esto es increíble. La misma estructura nos permite ya dejar ordenados literalmente los datos sin necesidad de otras estructuras.

Pues bien, una vez que tenemos esto aclarado, podemos crear un árbol binario con las palabras del Quijote. Si es una nueva palabra, creamos el primer nodo. Si es una palabra que es menor que la palabra que está en el nodo raíz, la ponemos en un nuevo nodo, que cuelga de la rama de la izquierda, en caso contrario, de la rama derecha.

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

052

SG.48

FUNDAMENTOS

F

Un árbol de esta naturaleza nos da una manera intrínseca de ordenar información.

Pero ¿cómo puedo crear una estructura de un árbol binario? La manera más simple es crear una estructura dinámica, que crece en la medida que lo necesitamos. El listado 1 muestra el código para hacerlo. El código está en Delphi (Pascal) que yo sé que ya no es común ver, pero sirve bien para este propósito.

Listado 1. Estructura de un árbol binario.

Esta definición siempre parece costar trabajo leerla, y la razón es que es la única vez que Pascal permite usar algo que aún no hemos definido. Así, nodoptr = ^nodo; pero node no ha sido aún definido. De hecho, se define inmediatamente después.

Una vez teniendo la estructura dinámica, Delphi (Pascal), nos permite crear una nueva instancia de la misma si la necesitamos.

Por ejemplo, definamos var arbol : nodoptr;

Esto es precisamente el árbol en donde iremos colocando las palabras que vayamos leyendo del Quijote. Necesitamos para ello, un procedimiento para insertar nuevos nodos y poner los valores en los mismos.

Listado 3. Leemos el archivo e insertamos palabras al arbol

Ejecutar este programa nos arroja que el Quijote tiene 384,123 palabras en total, aunque muchas de ellas se repiten a lo largo de la obra (¿diferentes? unas 30 mil). El programa crea un archivo con todas las palabras (una por línea) y las despliega en orden alfabético. La rutina que crea este archivo se muestra en el listado 4.

Listado 4. Desplegar contenidos del árbol.

Nótese que esta es una rutina recursiva (se llama a sí misma), que permite imprimir todas las palabras diferentes del Quijote en un archivo.

Listado 2. Rutina para insertar nodos en el arbol

Esa es la rutina imprescindible para ir creando los nodos (con sus respectivas ramas izquierda y derecha). Ahora hagamos la tarea: leamos el archivo del Quijote. Cada línea puede contener un número finito de palabras. El listado 3 tiene el código que abre el archivo de texto a analizar e itera sobre su contenido, línea por línea.

Siguientes pasos No basta con saber cuáles son las palabras diferentes en total que tiene el Quijote, sino también su frecuencia. Aquí necesitamos entonces hacer dos cosas. La primera es que el nodo contenga no sólo la palabra del texto, sino las veces que la vamos encontrando, algo así como una variable que vaya incrementándose cada vez que encontremos dicha palabra. Por ello, requerimos de un procedimiento más: uno que busque un nodo y pueda modificar los valores del mismo. No lo voy a hacer aquí. Si el amable lector me ha seguido hasta este punto, seguro puede hacer fácilmente esta rutina ¿verdad?

SG.COM.MX

053

O

HARDWARE

2 1

SMARTHALO OSVR HACKER DEV KIT 1.3

Todo parece indicar que 2016 será el año en que explote el uso de visores de realidad virtual. Como buen lector de SG, sabemos que más allá de tener un visor para consumir contenidos, te interesa también explorar la posibilidad de desarrollar. Ante esto, nuestra recomendación es que pongas tus ojos —literalmente— en el OSVR (Open Source Virtual Reality) de Razer. A diferencia de los visores dirigidos a consumidor como Oculus Rift o Samsung Gear VR, OSVR está principalmente dirigido a desarrolladores. Su objetivo es brindar una plataforma abierta y de bajo costo para desarrolladores. Es open source, tanto en software como hardware (puedes comprar el kit que incluye el hardware de Razer o descargar los esquemas y tú mismo fabricar el tuyo). En octubre se hará disponible la versión 1.3 del Hacker Development Kit de OSVR que incluye una versión actualizada del visor con óptica mejorada (Full HD a 120 Hz) y rastreo de movimiento en 360 grados, entre otras cosas. El kit tiene un precio de 299 dólares.

En esta época en la que andar en bicicleta es algo más que una moda pasajera, nos encontramos en Kickstarter con el proyecto SmartHalo, un dispositivo que se coloca en el manubrio de la bicicleta para ofrecer al ciclista urbano las mejores rutas así como las más seguras gracias a su sistema inteligente de navegación conectado al smartphone.

Es tan sencillo como seleccionar tu destino, comenzar a pedalear y seguir las instrucciones luminosas para llegar.

Cuenta con una potente luz con sensor que ilumina el camino cuando comienza a oscurecer; sistema de métricas que automáticamente registra tiempo, distancia, velocidad promedio, calorías, elevación y destinos; y sistema de seguridad contra robos que dispara una alarma cuando algún amante de lo ajeno pretende robársela. SmartHalo fue fondeado exitosamente en Kickstarter y llegará a los primeros clientes en el segundo trimestre del 2016.

3

RAZER DIAMONDBACK Visto en @geek_mx

El legendario mouse Diamondback de razer está de regreso y ahora está equipado con el sensor más preciso del mundo, iluminación LED Chroma y ergonomía mejorada. Con una distancia de levantamiento y corte ajustable de hasta 0.1 mm, ahora los jugadores pueden desplazarse y reiniciar con más confianza que nunca, porque un desvío accidental no afectará su desempeño. Este ratón diseñado para hardcore gamers tiene además iluminación Chroma personalizable con una gama de 16.8 millones de colores de los cuales elegir, con ello se logra un entorno de juego totalmente personalizado.

Destaca también su factor de forma ambidiestra, ultrapolling de 1,000 Hz, ajuste de la sensibilidad instantánea, 9 botones Hyperesponse programables y cable de de fibra trenzado de 2.1 metros. Tiene un costo de 90 dólares.

054

SG.48

4

MISFIT FLASH LINK

Uno de los usos que más se le está dando a los wearables hasta ahora es como monitores de actividad física, dando seguimiento a aspectos como qué tanto has caminado cada día, si llevas demasiado tiempo sentado y debes moverte un poco, qué tan bien dormiste, etcétera. Entre los productos más populares para este propósito están las pulseras de Fitbit, Polar y Garmin. Si has estado esperando a que surja una opción económica para este tipo de productos, te recomendamos el Misfit Flash Link. Es un sensor del tamaño de la carátula de un reloj que puedes fijar a tu ropa o accesorios. Esto le permite dar un mejor seguimiento que los monitores de pulsera, ya que por ejemplo para andar en bicicleta lo colocas en tu tenis y puede contar revoluciones. Pero lo mejor del Flash Link es su precio, 20 dolares. El Link tiene app compañera para iOS y Android, y adicionalmente Misfit expone un API de datos en la nube, así como SDK para que puedas crear apps que interactúen con el Flash Link u otros productos de Misfit.

HARDWARE

5

O

GOOGLE ONHUB

El más reciente producto de hardware de Google es … *redoble de tambor* … un ruteador WiFi. Sí, lo sabemos, estando acostumbrados con Google a hablar de lentes de realidad aumentada y automóviles sin conductor como que hablar de ruteadores no es muy estimulante. Aún así, el OnHub es notable porque es caballo de troya de Google para adueñarse del hogar ...

El OnHub tiene un lindo diseño, lo cual es importante ya que el objetivo es que puedas ponerlo en un lugar central de tu casa

(por ejemplo la sala), de manera que la señal pueda llegar sin problemas a todos los rincones. Cuenta con arreglos de seis antenas tanto para frecuencias de 2.4 GHz como 5 GHz, y adicionalmente tiene una antena dedicada exclusivamente a estar monitoreando redes alrededor para continuamente escoger el canal que brinde mejor recepción. En resumen, la conectividad es buena, muy buena. OnHub también incluye antenas para conectividad por Bluetooth y Zigbee, y aquí está la clave ya que muestra que la intención de Google

es utilizarlo como centro de comando para automatización del hogar (aprovechando que Google también es dueño de Nest y Dropcam).

El inconveniente con OnHub es que es un producto relativamente cerrado y con pocas opciones de configuración a pesar de su poder. Ojalá y pronto sea soportado por firmware modificado como OpenWRT.

La Historia del Programador que No Sabía Inglés Platiquemos en nuestro idioma, pero programemos en inglés.

Este comic fue originalmente publicado en http://www.commitstrip.com/en/2015/08/21/the-story-of-a-coder-who-doesnt-speak-english Fue traducido al español y compartido por Software Guru con el permiso del autor.

SG.COM.MX

055

O

BIBLIOTECA

THE PHOENIX PROJECT: A novel about IT, DevOps, and helping your business win.

Por Gene Kim, Kevin Behr & George Spafford. IT Revolution Press, 2013.

1

Bill es un gerente de TI en una empresa. Un día recibe una llamada del director general. Un importante proyecto de TI está significativamente retrasado y sobre presupuesto. El director le da a Bill 90 días para resolver el problema o outsourceará al departamento entero de proyectos de TI. Con ayuda de un miembro del consejo y su misteriosa filosofía de “Los 3 caminos”, Bill comienza a darse cuenta que las actividades de TI tienen más similitudes con una planta de manufactura de lo que imaginaba. Con el tiempo encima, Bill debe reorganizar el flujo de trabajo para mejorar la comunicación entre departamentos y generar valor para el negocio.

Si alguna vez leíste “The Deadline” de Tom DeMarco, “The Phoenix Project” viene a ser algo similar, pero en un contexto moderno de TI, enfocado en la filosofía Lean y el movimiento DevOps. Consúltalo en http://swgu.ru/qq

THE SPARKFUN GUIDE TO PROCESSING Por Derek Runberg. No Starch Press, 2015.

2

“The SparkFun Guide to Processing” es el primer libro en la nueva serie de SparkFun Electronics publicado por No Starch Press. Enseña como comenzar a hacer proyectos artísticos e interactivos con el lenguaje Processing.

El libro está formado por tutoriales con un nivel de dificultad progresivo, que enseñan cómo aprovechar distintas librerias de Processing para manejar gráficos, audio, comunicación con dispositivos electrónicos, entre otras.

Consideramos que The SparkFun Guide to Processing es ideal para niños y niñas de entre 9 y 15 años, que posiblemente ya hayan hecho cosas básicas con ambientes como Scratch y estén listos para el siguiente paso.

Nuestra única queja de este libro es que apenas toca brevemente el tema de integración con Arduino. Pero este se debe principalmente a que justamente el próximo libro de esta serie (“The Sparkfun Guide to Arduino”) se enfocará de lleno en ese tema, así que estaremos al pendiente.

Consúltalo en http://swgu.ru/qr

056

SG.48