Columna invitada

De event-stream, npm, y Arquitecturas que Invitan al Desastre

Ivett Sanchez — Tue, 15 Jan 2019 18:48:07 +0000

De event-stream, npm, y Arquitecturas que Invitan al Desastre

Ivett Sanchez Tue, 01/15/2019 - 12:48

Publicado en

SG #58

Columna invitada

Autor

Gunnar Wolf

En los últimos días de noviembre pasado se dio a conocer una noticia que armó revuelo — Y cuya intersección me atañe e interesa mucho en lo personal: Seguridad informática, software libre, integración de proyectos libres, arquitecturas de gestión de paquetes, mecanismos de compilación y distribución… Cuando me invitaron a participar con este texto adicionalmente a mi columna habitual, lo primero que pensé es, "¿cómo no escribí mi columna con ese tema? ¿Será que ya lo anticipábamos tanto que no me resultó de suficiente importancia?"

Y es que tiene mucho, muchísimo tiempo que venimos anticipando que esto ocurra. Y ha ocurrido, aunque de formas menos graves.

¿Qué pasó con event-stream?

Con este texto no busco reportar de forma ágil y oportuna, sino que hacer un pequeño análisis sobre las causas, y algunas recomendaciones para evitar que casos como este se repitan. El tema fue ya cubierto oportunamente por SG Buzz [1] al muy poco tiempo de reportarse. Hay, además, un análisis mucho más completo en LWN.net [2]. Para quien quiera ver detalles mucho más finos, Zach Schneider presentó en su blog personal otro artículo [3] incluyendo un desglose técnico de cómo se realizó el ataque. Me salto, pues, tanto de los detalles como me es posible.

Así que, resumiendo tremendamente: event-stream es una biblioteca de Javascript, muy frecuentemente utilizada para la manipulación de flujos (streams) de datos en aplicaciones basadas en Node. Si bien es una biblioteca que goza de muy alta popularidad, como frecuentemente pasa, su desarrollador original fue perdiendo motivación para desarrollarla, indicando que "ya ni siquiera la utilizaba". Esto es muy comprensible: A lo largo de los ocho años de vida que tiene este proyecto, ¿cómo se le puede exigir a una persona comprometerse a mantener los mismos intereses y proyectos de vida?

En septiembre de 2018, un usuario con alias right9ctrl solicitó al autor de event-stream el convertirse en su nuevo mantenedor. Esto ocurre todo el tiempo en distintos proyectos. Este nuevo mantenedor inició con un muy buen ritmo de actividad, subió nuevas versiones. Como es frecuente, una de esas nuevas versiones incluía una dependencia sobre una nueva biblioteca — flatmap-stream. Esta biblioteca contiene código legítimo y válido, lo único que podría llamar la atención al respecto es que no tenía ninguna instalación previa a su inclusión — Pero no resulta incomprensible que un desarrollador intente modularizar más su código, separando alguna funcionalidad para poderla utilizar sin depender de todo el código…

Hasta aquí todo bien. Ahora, flatmap-stream se distribuía tanto en el formato fuente, como minificada. ¿Qué es esto? Dado que el código Javascript muy frecuentemente se transmite a clientes Web (sean éstos navegadores, aplicaciones celulares, o incluso aplicaciones nativas en diversos entornos de escritorio), se busca que la descarga sea tan corta y ágil como sea posible. La minificación es, a fines prácticos, una compilación hacia el mismo lenguaje: Elimina todos los comentarios, todo el espacio en blanco, y reemplaza los nombres descriptivos de funciones y variables por el más corto posible. El código minificado, si bien semánticamente idéntico al código fuente, no puede considerarse modificable o, siquiera, legible por otra persona.

La estrategia de nuestro inteligente atacante, pues, fue no incluir nada malicioso en el código fuente, pero sí lo hizo en la versión minificada. Y otro punto importante: ¿Qué es lo que buscaba atacar? No era al grueso de usuarios de event-stream… Su uso es demasiado genérico. Sin embargo, identificó a una aplicación en particular que tiene a event-stream entre sus dependencias: copay-dash, un gestor de billeteras de criptomonedas.

Habiendo leído esto último, estoy seguro de que, como decimos en México, ya les cayó el veinte respecto el efecto de este ataque: Lo que logra es transferir el control de la billetera que tenga el desafortunado usuario que corra el código malicioso a right9ctrl.

¡Ah! Y un punto importante, específico a la cultura de desarrollo de npm: La búsqueda de un punto vulnerable en una aplicación relacionada con manejo de billeteras… Puede no haber sido tan difícil. El La cultura de npm apunta a que se empaqueten como biblioteca independientes pedacitos incluso triviales de cinco o diez líneas de código. Es imposible que un sólo desarrollador controle el conjunto de dependencias de ese proyecto: copay-dash incluye… ¡1277 dependencias de 378 mantenedores diferentes!4

¿Cómo podría haberse evitado?

Los usuarios afectados no pidieron actualizar manualmente las dependencias de sus sistemas. Esto se debe a la cultura de moverse rápido y romper cosas que ha sido conscientemente adoptada por la comunidad de desarrolladores de Node, particularmente por conducto de su gestor de paquetes, npm. Este gestor busca ofrecerle a los desarrolladores siempre las últimas versiones disponibles de todas sus bibliotecas, actualizándolas automáticamente desde fuentes sin relación explícita de confianza entre sí, hospedadas en cualquier lugar de la red, y bastando con el mero hecho de listarlos en un registro central. La página de npm5 dice ser el registro de software más grande del mundo, con más de 800,000 bloques de construcción (módulos independientes).

El blog de Schneider sugiere como primer medida de mitigación a este tipo de ataques el uso de lock-files. Estos no son archivos de bloqueo en el sentido del control de escritura concurrente a archivos — Son archivos que, en vez de permitir que npm actualice automáticamente, especifiquen la versión específica que requieren de cada biblioteca. Esta estrategia es frecuentemente utilizada con gestores de paquetes específicos a lenguaje, e incluso tiene soporte en npm mismo, pero relativamente poca gente lo usa al ser antitético a la citada cultura de moverse rápido.

Esa recomendación, me parece, es una buena mitigación — Pero no previene ni cura el problema. Mi recomendación se aleja un par de pasos de la gratificación instantántea que brindan los gestores de paquetes específicos a lenguaje (npm para Node/Javascript, Gems para Ruby, Pip para Python, etcétera.

Una visión consistente, coherente, completa del sistema

En lo particular, abrevo mis prácticas de la cultura de las distribuciones de Linux, en particular de Debian. Desde hace varios años he defendido las ventajas de la filosofía de empaquetamiento a nivel sistema: Si bien tiene sentido que un desarrollador tenga las últimas versiones de las bibliotecas que emplea y conozca los detalles de su funcionamiento, no puede esperarse lo mismo de los usuarios finales de una herramienta.

Si estoy instalando un paquete determinado para gestionar mi billetera Bitcoin (o para cualquier otra cosa), no debería siquiera importarme en qué lenguaje está escrito, y mucho menos si la voy a instalar utilizando una u otra infraestructuras de empaquetamiento. La mayor parte de los usuarios están intersados en resolver su problema desde una única interfaz de gestión de software. De acuerdo, en el caso deNode, muchas de sus aplicaciones están pensadas para instalarse de forma centralizada, en un servidor, por un administrador de sistemas y no un usuario final. Aún así — Si se espera que dicho administrador emplee el desarrollo (en contraposición a utilizarlo como base para un desarrollo adicional), ¿para qué obligarlo a aprender otra idiosincracia más, otra manera más de gestionar un pequeño pedacito del sistema?

Por el trabajo que realizo con Debian, desde hace más de una década he venido lamentando el abandono de la consistencia y coherencia a nivel sistema que caracteriza a dicha distribución, y al uso de Linux en general. Uno de los principales puntos que me atrajo hacia Debian hace ya muchos ayeres es conocer y enamorarme de su documento de políticas del sistema: Todos los paquetes que forman parte del sistema siguen una lógica común; el usuario sabe de antemano dónde está cada archivo de configuración, datos, programas, y se cumple un conjunto de expectativas que permiten el uso de un entorno operativo plenamente integrado.

Insisto — Un sistema empaquetado como lo presenta una distribución completa no busca reemplazar, ni lograría hacerlo con la oportunidad y agilidad necesarias, a los sistemas de paquetes por lenguaje. Éstos son el vehículo correcto para el desarrollador, para quien tiene que estar permanentemente en lo último — y sin filtros que exijan un nivel mínimo de madurez en cada uno de los componentes. Pero no podemos esperar que la respuesta sea la misma para los usuarios finales de nuestros desarrollos: Para ellos, estabilidad y predictibilidad valen muchísimo más.

A lo largo de las décadas en que se ha desarrollado el movimiento de software libre, han existido unos cuantos casos de software "troyanizado" de diferentes maneras, como event-stream, el caso que aquí nos ocupa. Afortunadamente, han sido pocos, y su impacto negativo mayormente ha logrado contenerse. Sin embargo, con la masificación del uso de los sistemas de empaquetamiento de modelos más ágiles y orientados naturalmente a desarrolladores más que a usuarios, como npm, muchos usuarios están quedando expuestos a este tipo de ataques.

Está en todos nosotros, como profesionales del ramo, racionalizar el uso de estas herramientas y contribuir con una cultura de seguridad informática en todo el mundo.

Referencias

SG Buzz: Crónica de la inyección de código malicioso a biblioteca de JavaScript https://sg.com.mx/buzz/cronica-de-la-inyeccion-de-codigo-malicioso-biblioteca-de-javascript
LWN.net: event-stream, npm, and trust https://lwn.net/Articles/773121/
Zach Schneider: event-stream vulnerability explained https://schneid.io/blog/event-stream-vulnerability-explained/
NPMGraph, http://npm.broofa.com/?q=copay-dash

Competencias Digitales

sg — Mon, 03 Sep 2018 01:05:57 +0000

Competencias Digitales

sg Sun, 09/02/2018 - 20:05

Publicado en

SG #57

Columna invitada

Autor

Antonio Toriz

El uso de Internet en este siglo es primordial, muchas carreras dependientes de la computadora no existirían, al menos como las conocemos si esta jamás hubiera sido inventada.

Antes de la aparición de Internet los aprendizajes se dieron por mucho tiempo de manera redundante. Los docentes casi en su totalidad eran considerados dueños del conocimiento casi estático, absoluto e irrevocable; los alumnos difícilmente podían cuestionar dicho conocimiento, y en muchos casos era casi imposible aportar información nueva para fortalecer sus aprendizajes.

¿Pero cómo las generaciones previas a el uso de Internet aprendieron a usar esta tecnología, si sus docentes y ellos mismos no tenían idea de que este drástico cambio tecnológico que se avecinaba?

En el siglo pasado María Montessori mencionó que para que la educación sea provechosa, debe ser interactiva y personalizada. ¿Pero cómo podría serlo en un México del siglo XX donde las familias tenían muchos hijos, y en consecuencia las escuelas contaban con muchos alumnos?

En 1985 México implantó a nivel nacional el proyecto denominado Computación Electrónica en la Educación Básica (COEEBA), orientado a utilizar la computadora en el aula y para familiarizar a los maestros en su uso como instrumento didáctico. En esa época ya se tenía idea de lo que sería el futuro y se creía que, con el simple hecho de poner una computadora en el aula, casi por arte de magia mejoraría la educación; pero no fue así, y hoy en día aún no lo es del todo.

¿Cómo tener una educación provechosa si proyectos como Aprende.MX, México Conectado y @aprende2.0 no han logrado este objetivo?

¿El poner tecnología en el aula… realmente resuelve el problema de la brecha digital, o será que el problema de origen es la adaptación?

A finales del siglo XX, muchas escuelas adquirieron computadoras de escritorio, proyectores, pizarrones interactivos, enciclopedias virtuales y escáneres. Iniciaron la “digitalización de contenidos”, pero muchos equipos jamás se usaron (incluso algunos jamás se abrieron de su caja por distintas razones), aquellos que sí, ayudaron a la digitalización de documentos, los cuales eran tan malos en papel que no se ganó nada con ponerlos en otro formato.

En Internet circula una historia que relata que cuando la NASA empezó a enviar astronautas al espacio se dieron cuenta que los bolígrafos no funcionaban en ausencia de gravedad. Así que invirtieron millones de dólares y años de pruebas para desarrollar un bolígrafo que pudiera escribir en el espacio, bocabajo, en casi cualquier superficie y a temperaturas que iban de los -80 a los 65 grados Celsius. En comparación, cuando los rusos se enfrentaron al mismo problema, ellos usaron un lápiz.

En realidad, la historia es tan solo un mito [1], pero aun así ayuda a ilustrar un punto: siempre debemos cuestionar si la tecnología realmente nos está ayudando en el área educativa y laboral.

El problema de fondo es que se confunde el “fin” con “los medios”. Con poner tecnología en el aula no se tiene educación digital instantánea ni conocimientos si el docente no tiene la habilidad de transmitirlos; caso claro es el profesor de Informática Owura Kwadwo Hottish de Ghana, que enseñó a usar un procesador de textos a sus alumnos con tan solo un gis y un pizarrón [2].

Como docente les puedo decir que nuestro “fin” debe ser preparar a los alumnos para que su trabajo futuro pueda ser elaborado de la mejor manera posible. Quienes tenemos esto claro no nos quedamos con los brazos cruzados, sabemos que venimos de un mundo donde no existían computadoras e Internet, en el pasado los temarios educativos cambiaban cada 20 años o más, pero aprendimos a usar nueva tecnología. Así como nosotros fuimos preparados con habilidades y competencias para resolver problemas, ser creativos, comunicarnos, innovar o hacer trabajo colaborativo debemos hacer lo propio con nuestros estudiantes.

La tecnología no va a desaparecer a los docentes, solo los convertirá en guías, no en conocedores absolutos. Vivimos en la era dorada del tutorial, pero al mismo tiempo estamos en la era del analfabetismo digital (cualquier cosa que se publica en Internet se cree sin verificar la veracidad).

El mundo laboral está cambiando drásticamente con las nuevas generaciones, muchas empresas comienzan a reinventarse para no extinguirse. Los docentes deben crear contenido atractivo para que cada alumno pueda aprender a su ritmo como María Montessori mencionó y se puedan detonar las inteligencias múltiples, inspiración y motivación. Docentes y empresas tendrán que desarrollar líderes donde todavía no los hay.

La tecnología no debe verse como un gasto, es una inversión, es un componente importante en el progreso si se usa adecuadamente, el problema de las competencias digitales no está en la tecnología, está en la mentalidad de cada persona, y cada persona debe cambiar. Solo así se evitará que padres de familia vuelvan a vender las tablets que les dieron a sus hijos en las primarias.

Referencias

C. Curtin. “Fact or Fiction?: NASA Spent Millions to Develop a Pen …”, Scientific American. http://swgu.ru/ws
M. Gharib. “Computer Teacher With No Computers Chalks Up Clever Classroom Plan”, NPR. http://swgu.ru/wt

Bio

Antonio Toriz Cureño (@elingbruxo) egresó de la UAEMEX Valle de Chalco como Ingeniero en Computación; es conferencista y docente en el área de Tecnologías, actualmente labora dando clases a Nivel Preparatoria y Licenciatura.

La Historia de Sun Microsystems

sg — Fri, 23 Mar 2018 16:08:36 +0000

La Historia de Sun Microsystems

sg Fri, 03/23/2018 - 10:08

Publicado en

SG #56

Columna invitada

Autor

David Bonilla

La versión original de este artículo fue publicada en dos partes en la lista de correos semanal “Bonilista”, a la que te recomendamos te inscribas. Los originales están disponibles en http://eepurl.com/diV341 y http://eepurl.com/djEeTn . La versión presentada aquí fue editada por SG con permiso del autor.

Parte 1. The Network is the Computer

[19 de septiembre de 2010. JavaOne Conference. San Francisco.]

“Next slide, please”. Mientras contemplaba a Larry Ellison gustarse en el escenario del Moscone Center, no podía evitar tener la sensación de ser testigo del fin de una época.

Hace apenas un año en ese mismo lugar, James Gosling, el “padre de Java”, lanzaba camisetas al enfervorecido público. Ahora, el CEO de Oracle —un tipo que prefería que un esbirro le pasara las diapositivas antes que hacerlo él mismo— nos hablaba del futuro de nuestro lenguaje de programación favorito con la misma pasión que un lenguado. Sun Microsystems había muerto. “Next slide, please”.

Sun ha sido una de las pocas compañías que realmente ha transformado la industria del software. Una revolución que sólo fue posible gracias a la osadía cercana a la locura de algunos de sus técnicos. Esta es su historia.

En 1982, Andy Bechtolsheim, William Joy, Vinod Khosla y Scott McNealy fundaron Sun con el objetivo de construir “estaciones de trabajo”, es decir ordenadores personales de alto rendimiento y precio comedido, gestionadas con UNIX. El plan de negocios original [1] escrito por Khosla, primer CEO de la compañía, sigue siendo una joya.

En 1984, Khosla dejó la compañía para convertirse en inversionista de capital riesgo. McNealy toma el relevo. John Gage —el quinto empleado de Sun— acuña la frase “Network is the computer” que se convierte en un mantra de la empresa, 25 años antes de que se empiece a hablar siquiera del concepto de cloud.

En 1986 la compañía salió a bolsa con éxito y se extiende por Europa, Asia y Oceanía. Ese mismo año cierra un acuerdo con la Agencia Nacional de Seguridad para venderle equipos por valor de 500 millones de dólares.

En 1989 lanzan la Sun SparcStation 1, la primera estación de trabajo basada en procesadores con arquitectura SPARC —una especificación que ellos mismos desarrollaron y que, al contrario de la arquitectura x86, era completamente abierta y cualquier fabricante podía implementar, pero eso sólo fue posible gracias a que… Bechtolsheim se rebeló.

Bechtolsheim pensaba que los procesadores SPARC eran perfectos para usarse en estaciones de trabajo de gama media, pero esta idea no tuvo eco en la compañía. Bechtolshein abandonó la compañía que él mismo había fundado para crear su propia startup y hacer realidad esta idea. El inversionista detrás de esta nueva empresa fue justamente Vinod Khosla, cofundador y antiguo CEO de Sun.

Khosla y Bechtolsheim no querían dañar a Sun, sino salvarla de sí misma. Reconocieron que básicamente estaban copiando su tecnología y avisaron a su Consejo que lo harían con o sin su consentimiento, pero también que les permitirían comprar la nueva compañía al costo, por la misma cantidad que habían invertido en ella. Sun compró la startup y Bechtolsheim volvió a casa por la puerta grande. El resultado de esta telenovela fue la Sun SparcStation 1, que fue la estación de trabajo más vendida de la historia de Sun.

En 1990, Patrick Naughton —un ingeniero de 25 años que apenas llevaba 3 años en la compañía— decide aceptar una oferta de NeXT —la nueva startup de Steve Jobs— frustrado por los politiqueos y complejos procesos propios de una empresa cotizada en bolsa, que habían transformado a Sun en un dinosaurio.

Naughton solía jugar al hockey con Scott McNealy y otros empleados, así que un día mientras tomaban unas cervezas, decidió comunicarle personalmente a McNealy su decisión. McNealy le pidió un insólito favor, que escribiera un correo con todos los problemas con los que se había encontrado y cómo los solucionaría si pudiera hacer lo que quisiera. Naughton invirtió varias horas en escribir un largo y brutalmente sincero email que envió a la mañana siguiente.

La respuesta de McNealy sólo contenía 7 palabras: “Espera. Me voy a ocupar de esto”, y reenvió el correo a los principales ejecutivos de la compañía que a su vez lo hicieron llegar a los distintos gerentes. La respuesta general fue un “es exactamente lo que pensaba, pero no sabía cómo decirlo”. En Sun acababa de desatarse una tormenta.

Una de las sugerencias de Naughton fue crear un entorno de desarrollo sencillo, que simplificara trabajar con los 108 stacks tecnológicos que coexistían en Sun. Algunos ejecutivos invitaron al joven ingeniero a cenar en un restaurante de Palo Alto, para que les explicara cómo pretendía hacer realidad su idea. Este escribió en la parte trasera de un mantel de papel sus principales demandas: lo desarrollaría un equipo pequeño —tanto como para poder reunirse alrededor de la mesa de un restaurante—, trabajarían en una ubicación física externa, y el objetivo del proyecto sería secreto y sólo lo conocerían algunos altos ejecutivos, los diseños de hardware y software no tendrían que ser retrocompatibles con ninguno de los productos de la compañía y, por último, contarían con un presupuesto de un millón de dólares para gastar el primer año. Sorprendentemente, Sun accedió a las demandas de Naughton y, en 1991, el equipo que había formado junto a James Gosling y Mike Sheridan se mudó a una pequeña oficina encima de una sucursal de Bank of America en Sand Hill Road. Lo primero que hicieron fue desconectarse de la Intranet de Sun. Para bien o para mal, estaban sólos.

El proyecto pasó por muchas vicisitudes, incluyendo la marcha de Naughton en 1994, pero finalmente la primera implementación pública de Java vio la luz en 1995, prometiendo que su código podría ejecutarse en cualquier lado (Write Once, Run Anywhere).

Java alcanzó rápidamente una gran popularidad y se convirtió en el “lenguaje para programación de la Web”, iniciando la época dorada de Sun y, también, provocando su caída …

Parte 2. Write Once. Run Everywhere

El lanzamiento de Java convirtió de sopetón a Sun, una empresa de hardware, en un actor principal de la industria del software.

En 1996, Scott McNealy se convence de que Sun debe competir de tú a tú con Microsoft y eso requiere que cuenten con su propio Office. Por eso compran Lighthouse Design, compañía que desarrollaba una suite ofimática para ordenadores NeXT, fundada entre otros por Jonathan Schwartz.

Schwartz es uno de los pocos altos directivos de la compañía con experiencia en software y por eso, en 1997, es nombrado Responsable de Marketing de Producto de Java. Él aún no lo sabía, pero se acababa de subir a un cohete. Java era considerado “el lenguaje de programación de la Web”, y en 1997 la burbuja punto com [1] estaba a punto de entrar en ebullición.

Durante la época de vacas gordas, Sun se hincha a vender hierro, pero aunque su arquitectura SPARC/Solaris es mucho más rápida y estable que la de los sistemas Wintel, también es mucho más costosa y complicada de mantener, por lo que la industria está pivotando hacia servidores con chips x86. Para intentar no perder ese tren, Sun compra Cobalt, un fabricante de servidores gestionados con Linux, por 2 mil millones de dólares, en septiembre de 2000. A finales de ese mismo año, la burbuja empieza a desinflarse y, a principios de 2001, estalla por completo. Sun, que había venido viviendo “la vida loca”, entra en caída libre.

En el año 2000 Sun había obtenido ganancias netas por 1,850 millones de dólares. Al año siguiente bajaron a 927 millones y en 2002 ya eran pérdidas por 628 millones. En 2003 los números rojos llegan a 2,400 millones de dólares.

Lo único que sigue creciendo es Java, así que McNealy asume que el futuro de Sun pasa por el software y los servicios. Se hace a un lado y da paso al hombre que ha ido ascendiendo por la escalera corporativa hasta convertirse en COO de la misma. En 2006, Jonathan Schwartz es nombrado CEO.

La primera gran apuesta de Schwartz es abrazar decididamente el open source. En noviembre, apenas seis meses después de su nombramiento, Sun libera todo el código de Java, que adopta la licencia GPLv2. Pero la apertura de Schwartz va más allá del código. Publica frecuentemente anuncios y datos relevantes en su blog corporativo y anima a los empleados a hacer lo mismo.

Desgraciadamente, en una época donde las grandes compañías estaban más acostumbradas a pagar por licencias que por servicios, que la plataforma de programación más popular de la industria sea open source no ayuda a generar ingresos. Strike uno.

A pesar de todo, en 2007 la compañía presenta utilidad positiva. Pero a finales de año, estalla la crisis hipotecaria que deja en graves condiciones al sector financiero, que representaba un tercio de los ingresos de Sun. Strike dos.

En 2008 Sun adquiere MySQL, pagando 1,000 millones de dólares por una empresa que apenas vende 75 millones al año. Es la enésima compra que sale mal y no consigue relanzar las ventas de una compañía con telarañas en la tesorería. Strike tres, ponchado.

En 2009, Oracle anuncia que ha llegado a un acuerdo para comprar Sun por 7 mil 400 millones de dólares. Para entender la dimensión del desastre, sólo hay que recordar que hacía menos de diez años el valor de la compañía en el mercado bursátil había superado los 200 mil millones de dólares.

Larry Ellison, fundador y CEO de Oracle, fue muy duro con Schwartz y su gestión. En una entrevista afirmó que “los equipos de ingeniería son buenísimos, pero la Dirección era sorprendentemente mala” y, hasta cierto punto, tenía razón. Por ejemplo, en Sun los vendedores obtenían su comisión en base a la facturación, independientemente de si la venta dejaba ganancia o pérdida. Sun llegó a perder un millón de dólares en una sola venta.

Pero la inquina de Ellison contra Schwarz iba más allá de los simples números. El antiguo CEO de Sun representaba todo lo que Larry odiaba. Frente a la opacidad de Oracle, Sun proponía transparencia. Frente a una organización que se cuadraba ante los vendedores en Porsche y traje a medida, otra donde los ingenieros eran los reyes. Frente a un negocio basado en el vendor lock-in, otro basado en la libertad y la venta de servicios.

Schwartz y Sun nos dejaron algo más que un simple blog. Nos dieron el primer stack tecnológico completo –desde el silicio al usuario final- completamente abierto y enterprise-ready. Podías programar tus aplicaciones Java con un IDE como NetBeans, usando MySQL como base de datos, y ejecutar las mismas en un sistema SPARC gestionado por OpenSolaris, sin pagar una sola licencia y disponiendo del código fuente de todos ellos. Esta es una revolución que la compra de Oracle no pudo parar. Una revolución en la que Sun, con sus miserias y sus grandezas, se acabó inmolando al mismo tiempo que transformaba la industria para siempre. Su apuesta por el open source ayudó a cambiar el centro de gravedad del desarrollo de software. Al contrario de lo que muchos creen, Sun no dio herramientas a los programadores sino algo mucho más importante. Les dio poder. Ese es su legado.

Referencias

[1] http://swgu.ru/vg

[2] https://en.wikipedia.org/wiki/Dot-com_bubble

Bio

David Bonilla es CEO en Comalatech y autor de la “bonilista”, una lista de correo con artículos para profesionistas de software.

Kung Fu Analítico: Las tres disciplinas mentales de los líderes de analítica y ciencia de datos

sg — Tue, 20 Mar 2018 05:15:55 +0000

Kung Fu Analítico: Las tres disciplinas mentales de los líderes de analítica y ciencia de datos

sg Mon, 03/19/2018 - 23:15

Publicado en

SG #56

Columna invitada

Autor

Eduardo H. Ramírez

La ciencia de datos y analítica de negocios se cuentan entre las áreas con mayores retos intelectuales de la actualidad. El campo de trabajo es novedoso y apasionante pero también puede imponer un alto nivel de estrés. La actividad cotidiana del científico de datos demanda largas horas de concentración para limpiar y convertir los datos en una representación usable, plantear e iterar hipótesis, consultar referencias teóricas e implementar nuevos métodos, siempre con la sensación de estar a punto de encontrar un “insight” que cambie la historia del negocio … o de tener que comenzar de nuevo con otro enfoque, sólo que esta vez un poco más cerca del “deadline”.

Para los líderes de los equipos de analítica el reto no es menor. Se tiene la responsabilidad de producir iniciativas de alto impacto para el negocio además del desarrollo de propuestas técnicas, presupuestos, negociación con stakeholders, comunicación de resultados y liderear a un equipo de especialistas de alto desempeño. Por si fuera poco, conforme las responsabilidades del científico o líder aumentan, el tiempo disponible para el aprendizaje formal es cada vez más limitado, lo que vuelve más relevante la cuestión de cómo dirigir el esfuerzo intelectual.

A partir de un cierto nivel de competencia técnica, el mayor reto del científico o líder se encuentra en el desarrollo de una mentalidad que facilite navegar la complejidad de la profesión y lograr resultados manteniendo el enfoque y el equilibrio entre la vida personal y profesional. Esta mentalidad se construye mediante la práctica constante de hábitos o disciplinas y por ello la llamamos: el kung-fu analítico.

El significado original del término kung-fu es “habilidad”, que en chino puede referirse a cualquier actividad cuya maestría se adquiere con la práctica. Así, el kung-fu analítico se domina a través del perfeccionamiento de tres disciplinas mentales o tipos de pensamiento:

Crítico-cuantitativo
Estadístico
Científico

Pensamiento crítico cuantitativo

Para muchas personas el término “pensamiento crítico” se relaciona con el escepticismo o la desconfianza, típicamente en el análisis de las falacias y argumentos en las noticias o discursos políticos, pero el concepto va más allá. De acuerdo a la a Fundación para el Pensamiento Crítico [1], este se define como el arte de analizar y cultivar el pensamiento para mejorarlo continuamente, es decir, la práctica de un pensamiento auto-dirigido y auto-correctivo, sujeto a estándares de excelencia.

La disciplina del pensamiento crítico aspira a lograr un pensamiento con atributos de alta calidad, a los que podemos acercarnos al plantear las preguntas correctas. Estos son: la objetividad (¿Cuáles son los supuestos?), claridad (¿Puedes darme un ejemplo?), exactitud (¿Cómo podemos verificar eso?), precisión (¿Puedes ser más específico?), relevancia (¿Cómo se relaciona con el problema?), profundidad (¿Puedes darme más detalles?) y amplitud (¿De qué otra forma podemos abordar este problema?). Citando a Robert Rubin, podemos juzgar una decisión por su resultado, pero también por el proceso por cómo fue tomada.

Aquí agregamos el enfoque “cuantitativo” para enfatizar que la gran mayoría de la información a la cual se enfrenta un científico o analista de datos es de tipo numérico y para distinguir las formas concretas de aplicar el pensamiento crítico a problemas de datos. También es de interés resaltar una brecha formativa ya que los proponentes del pensamiento crítico usualmente tienen una formación humanística, mientras que los profesionales de los datos usualmente provienen de una formación técnica.

La escritora Laura Miller explica en un artículo [2] la relación que existe entre el pensamiento crítico y la estadística. Indica que tradicionalmente, el pensamiento crítico se ha enfocado a la identificación de falacias en el razonamiento o del uso de lenguaje manipulativo, sin embargo actualmente gran parte de la persuasión y las agendas políticas se presenta en forma de cifras. El valor de la disciplina del pensamiento crítico en el mundo de los datos nos lleva a cuestionar los supuestos, la calidad o el origen de los mismos y a ser conservadores para establecer conclusiones. Por lo tanto, para mejorar en el kung-fu analítico podemos refinar nuestra batería de preguntas con algunas cuantitativas como: ¿Es confiable la medición? ¿Es consistente el uso de las unidades? ¿Es válido el uso de porcentajes?. Y así como es necesario cuestionar los datos, también es fundamental cuestionar los propios supuestos cuando los datos apuntan hacia una dirección diferente.

Pensamiento estadístico

Pensar estadísticamente no significa memorizar las fórmulas de la probabilidad y estadística, sino más bien profundizar el uso cotidiano de sus conceptos fundamentales para identificar los sesgos y los errores más comunes. Las ideas estadísticas son abstracciones de la realidad y por lo tanto esconden información.

Una idea aparentemente simple como el promedio es la fuente de muchas conclusiones erróneas al asumir que las condiciones promedio ocurrirán o que un individuo es similar al promedio de su población (se cuenta del estadístico que se ahogó en un lago que tenía una profundidad promedio de 50 centímetros). Un ejemplo de esta falacia: Si el promedio de calificación de un grupo fue de 75, en escala de 0 a 100, y se aprueba con 70: ¿Podemos aseverar que hubo más alumnos aprobados que reprobados? La respuesta es no, porque no conocemos la forma de la distribución y erróneamente asumimos que es “normal”, es decir, que hay aproximadamente la misma cantidad arriba y abajo del promedio. Es posible que unos cuantos alumnos hayan aprobado con muy alta calificación y la mayoría hayan reprobado.

Otro fenómeno estadístico que es fuente común de errores es la llamada “Paradoja de Simpson”. En términos simples es la paradoja que resulta cuando un resultado agrupado apunta a una conclusión, pero al evaluar en subgrupos se percibe un patrón distinto. Recientemente se habló de esta paradoja en relación a un posible caso de discriminación en las admisiones entre hombres y mujeres en la UCSB, ya que la tasa de admisión de los hombres fue de 44% mientras que la de mujeres fue de 35%. ¿Hubo discriminación en la universidad? La respuesta se esclareció al agregar una tercer variable al análisis: el departamento de aplicación. La tasa de aceptación de las mujeres era aparentemente menor porque las mujeres aplicaron en mayor proporción a los departamentos con menores tasas de aceptación. Al analizar las tasas de aceptación por departamento, no se encontró una diferencia atribuible al género.

Consideramos al pensamiento estadístico como una disciplina mental al requerir de una constante alerta para identificar las fuentes de sesgo y error. También nos requiere practicar la identificación y cuantificación de las fuentes de nuestra incertidumbre. Citando una vez más Robert Rubin: “todas las decisiones que tomamos están sujetas a incertidumbre, pero a pesar de ella hay que decidir y hay que actuar”.

Pensamiento científico

El pensamiento científico es la disciplina mental que nos aporta una metodología para establecer la validez de nuestro conocimiento y avanzar con solidez en el entendimiento de los fenómenos.

Del método científico aprendemos que establecer causalidad no es trivial y que las variables pueden estar relacionadas de formas diversas que nos pueden engañar con facilidad. Una conclusión aceptada actualmente: que el fumar causa cáncer de pulmón fue difícil de establecer en su momento. Se recuerda a Sir Ronald Fisher, considerado uno de los padres de la estadística, por cuestionar severamente los estudios que apuntaban a esta conclusión: ¿Cómo se podía aseverar que no existía una causa común para la propensión a fumar y a tener cáncer de pulmón? Eventualmente, la forma de probar esta relación causa-efecto fue a través de establecer una relación basada en la dosificación: las personas que fumaban mucho tenían más incidencias de cáncer que las que fumaban poco.

Recientemente Judea Pearl (pionero del enfoque probabilístico a la inteligencia artificial) lanzó una aguda crítica al modus operandi de la ciencia de datos popular, donde se favorece la generación de modelos predictivos como “cajas negras”, sin profundizar en el entendimiento de las relaciones causales entre las variables. ¿Podemos avanzar en el entendimiento de los fenómenos sin entender las relaciones causales entre los inputs y los outputs de un modelo predictivo?

Adicional a los atributos de calidad buscados por la primer disciplina, la tercer disciplina mental agrega los atributos del conocimiento científico: replicabilidad, refutabilidad y la necesidad de evidencia empírica.

Conclusión: El rol del líder analítico

La aportación clave de un líder que conoce el kung-fu analitico es generar la discusión necesaria con apego a los principios del pensamiento crítico, estadístico y científico para evitar invertir en iniciativas analíticas que no entregaran resultados al negocio y encontrar las que sí lo harán, anticipándose a las objeciones y necesidades de los usuarios que se verán impactados por la nueva tecnología. En el gran esquema de las cosas es más fácil crear modelos predictivos que transformar el funcionamiento de las organizaciones.

Sun-Tzu asevera que los mejores guerreros son los que primero ganan y luego van a la guerra. Así, con las tres disciplinas del kung-fu analítico, los líderes pueden avanzar sistemáticamente en su entendimiento de las distintas decisiones y procesos que se pueden impactar, para posteriormente definir los modelos y sistemas que se deben de construir para mejorarlos confiando que el proceso de análisis tuvo la claridad, amplitud y profundidad necesaria. Así los líderes pueden escoger sus batallas y ganarlas antes de empezar.

Referencias

“The Foundation for Critical Thinking”. https://criticalthinking.org
L. Miller. “What are the odds?” Slate, agosto 2015. http://swgu.ru/v0

Bio

Eduardo H. Ramirez, Ph.D. Doctorado en Sistemas Inteligentes con tesis en aprendizaje no-supervisado. Ex-colaborador en Microsoft y Yahoo! Fundador y organizador de la comunidad de Data Science en Monterrey desde 2015. Actualmente es Director de Analytics y Cloud Operations en Ensitech.

Re-Educación versus Rezagos

sg — Mon, 12 Mar 2018 03:39:53 +0000

Re-Educación versus Rezagos

sg Sun, 03/11/2018 - 21:39

Publicado en

SG #56

Columna invitada

Autor

Marco A. Dorantes

Hace unos meses leí una nota periodística titulada: “México, rezagado en el uso de robots financieros” [1] y recordé que lograr ganancias financieras significativas por medio del comercio electrónico automático de alta frecuencia (HFT, por sus siglas del inglés «High-Frequency Trading») puede ser un objetivo muy difícil de lograr según he escuchado decir a expertos en la materia. ¿Por qué? El desafío implica combinar una alta especialización técnica en varios campos tanto del ámbito del problema como de la solución. Por ejemplo, se requiere dominar los detalles relevantes de la regulación comercial vigente. De otro modo se corre el riesgo de provocar sobresaltos injustificados en los mercados bursátiles. Desde la pasada crisis financiera mundial, a partir de 2008, tales espejismos bursátiles pueden tener consecuencias penales de mayor gravedad. Además, como cualquier otra solución de negocio basada en software, igualmente aquí se requiere un señorío sobre cómo administrar la complejidad inherente al diseño y desarrollo del software involucrado; es decir, una deficiente atención a las propiedades esenciales de un software no-trivial puede provocar que la complejidad se desborde e impida alcanzar los objetivos esperados del proyecto en cuanto a ventana temporal de oportunidad, completitud y presupuesto. Asimismo, los defectos en este tipo de soluciones de negocio pueden provocar, como ha ocurrido, sobresaltos indeseables como los ya aludidos; por lo que la calidad y el nivel de exactitud requerido en el software son especialmente importantes.

Con base en lo que dice la nota: “El HFT realiza cientos de operaciones en milisegundos y en el país muy pocos activos tienen la liquidez y profundidad necesaria” —el énfasis es mío—, me pregunto: ¿quizá el rezago aludido en el título de la nota proviene, por tanto, de que no hay más activos? ¿O acaso con más “tecnología necesaria, la inversión realizada y los software y hardware (sic)” —como dice la nota— sería suficiente para disminuir el rezago de marras?

La causa raíz del rezago quizá es múltiple y más compleja que la planteada en esa nota periodística. Sigamos pues indagando las causas de nuestra rezagada situación colectiva local.

El diagnóstico de tal rezago no podría distanciarse mucho del diagnóstico general para esta nuestra cultura colectiva mexicana. Por lo que el rasgo del cortoplacismo en dicho diagnóstico general también estaría presente en este caso particular. Rasgo por el cual no hay ni barbecho ni sembrado ni esmero en el cuidado ni de las semillas socioculturales ni económico-políticas, sino consumismo rampante y apego malsano a la gratificación inmediata. De ahí que suele haber muy poco para cosechar en el mediano y largo plazo; en otras palabras, hay poco cultivo de talento en diseño de soluciones de negocio basadas en software. Sin ese tipo de talento, la “teoría de la dependencia” se mantiene, de manera indefinida, acumulando evidencia a favor de su veracidad.

«La culpa la tiene “el sistema”» –dice una frecuente consigna; la cual, cuando se repite acríticamente, tan sólo resulta ser una cantaleta pseudo-intelectual. Por supuesto que sí: muchos sistemas socioculturales están involucrados en las causas de nuestro rezago colectivo. Sin embargo, todos somos una parte de esos mismos sistemas socioculturales con frecuencia señalados en lo general. Por eso es tan relevante la autocrítica; en la autocrítica individual podría gestarse el inicio de cambios sistémicos.

La complicación es que los sistemas educativos imperantes no suelen cultivar individuos con los valores, principios, prácticas y hábitos intelectuales para ejercer la autocrítica. Un problema con eso —entre muchos otros— es que esos sistemas socioculturales cultivan individuos incapaces de alcanzar una mayor conciencia de sí mismos y de lo que la cultura a su alrededor ha hecho de ellos. Ese problema es otro rasgo por el cual los sistemas socioculturales tienen propiedades básicas revolventes que resultan muy problemáticas; es decir, que generan otras propiedades problemáticas de orden superior, emergentes.

Hay quienes afirman que los sistemas socioculturales funcionan muy bien porque funcionan para ellos. Pero difícilmente un sistema sociocultural realmente funciona si sólo funciona para unos pocos. Los rezagos colectivos apoyan la conclusión de que esos sistemas dejaron de funcionar —si alguna vez lo hicieron— para el bien común (¿«bien común»? –frecuentemente me sorprendo de mi propia candidez). Por lo que hay quienes buscan alternativas a los sistemas actuales y afirman que tales alternativas llegarán como “reformas estructurales” a los mismos sistemas imperantes (¿quién, ahora, resulta ser el cándido?).

Desarrollar la capacidad de autocrítica, personal y profesional, es una semilla con potencial de transformación sistémica. Aquí propongo que ese desarrollo debe estar enteramente en las manos del individuo. El individuo adulto debe tener en claro que su educación en adelante debe estar en manos propias y no en las manos de los sistemas socioculturales que han estado a cargo de su cultivo y lo han formado a favor de los objetivos de esos sistemas. Si la cultura local mantiene y protege un estado de inconsciencia de sus procesos propios de culturización colectiva, entonces la frase «La cultura local no es tu amiga» podría ser un tipo de mantra útil para no olvidar los efectos de repetir lo tradicional de manera acrítica. Por el contrario, la idea de una cultura cosmopolita resulta prometedora para aproximarse más a una concepción amplia de —y que valga la pena llamar— «educación».

Con la autocrítica, para retomar un inicio, sería posible identificar cada vez más rezagos y deficiencias conceptuales a nivel individual. Conviene empezar, por ejemplo, por conceptos muy relevantes: ¿qué es un dato?, ¿qué es información?, ¿qué es conocimiento?, ¿cómo se distingue uno de otro?, ¿cuál es la estructura cognitiva de cada uno?, etcétera.

Tomar conciencia de nuestros rezagos y deficiencias conceptuales a nivel individual sería un primer paso para poder cerrar poco a poco esas brechas que provocan alucinaciones intelectuales: tomar como entendido por completo algo de lo que apenas entendemos lo meramente superficial. Por eso es tan relevante la retrodidáctica. Propongo que la retrodidáctica sea el arte de auto-reeducarse; es decir, es el cultivo de la conciencia de que muchos aspectos básicos realmente no los dominamos tan bien como nos empeñamos en querer creer.

En la categoría de diseño y arquitectura aplicativa, por ejemplo, no sólo es necesario adquirir productos que resultan de la técnica o destreza de otros —e.g., adquisición de productos tecnológicos—, sino también se requiere desarrollar conocimiento. No digo adquirir sólo datos ni digo sólo adquirir información, sino cultivar conocimiento; es decir, nivel de conciencia. En otras palabras, y con relación al tema de la nota periodística, me refiero a cultivar preguntas como ¿qué es un algoritmo computacional?, ¿qué es un sistema operativo, qué es un hardware thread, y un software thread, qué es un Windows/Linux Process? ¿Qué es concurrency, qué es parallelism —estas dos últimas son cosas distintas entre sí—, qué es almacenamiento RAM, y almacenamiento persistente, qué es una red computacional de teleproceso, etc.?

"La transformación llega más de explorar cuestiones profundas que de buscar respuestas prácticas" —Peter Block [2]

Rezagos conceptuales ocurren en otras categorías de la creación de soluciones de negocio basadas en software; por lo que también se requiere autocrítica y retrodidáctica en categorías, por ejemplo, como «Persona/Grupo de Trabajo» o en la categoría de «Procesos», entre otras categorías que agrupan diversos factores críticos del éxito en la creación de este tipo de soluciones.

Por lo que una remediación cultural exige, también, el desarrollo de las destrezas de las personas y no sólo la adquisición y el consumo de productos. Eso significa el desarrollo de sus facultades más básicas a nivel individual; por ejemplo, el pensamiento crítico, el pensamiento creativo, el pensamiento solidario, la retrodidáctica, etcétera. O dicho de otro modo: exige el desarrollo de su profesión; es decir, de la acción y el efecto de su profesar en el contexto de un profesionalismo que de manera justificada pueda llamarse más «maduro».

Si lo colectivo aporta algo al individuo —como lo que hay a la mano en los sistemas escolarizados locales— pues hay que agradecerlo y aprovecharlo. Pero, ahora más que nunca, en esta época de la revolución de la información, el individuo ya no necesita por fuerza quedarse sólo con lo provisto por lo colectivo, sino que tiene la posibilidad de no sólo ser autodidacta sino, además, retrodidacta [3].

Referencias

R. Rivera. “México, rezagado en el uso de robots financieros”. El Financiero, 13-nov-2017. http://swgu.ru/uz
P. Block. The Answer to How is Yes: Acting on what matters. Berrett-Koehler Publishers, 2003. http://swgu.ru/u-
http://retrodidacta.blogspot.mx

Bio

Marco A. Dorantes es un consultor en el desarrollo reflexivo y cooperativo de sistemas computacionales que retornan ganancias. Practica el diseño de 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

CDO: Se buscan líderes digitales

sg — Mon, 21 Aug 2017 20:19:37 +0000

CDO: Se buscan líderes digitales

sg Mon, 08/21/2017 - 15:19

Publicado en

SG #55

Columna invitada

Autor

Olivia Salas

Una de las preguntas clave que la alta dirección se hace al emprender una iniciativa de transformación digital es: ¿quién debe liderar el viaje hacia la innovación? En muchas organizaciones, la respuesta se ha materializado en un nuevo rol corporativo: el director de Digitalización, o Chief Digital Officer (CDO), a quien se le encomienda concretar la evolución innovadora del negocio.

Por la sustancia digital del cargo, que exige una sólida competencia tecnológica en temas como IoT, Big Data, movilidad, entre otras, se asume que el CIO es un candidato ideal para dirigir una iniciativa de transformación digital. Sin embargo, de acuerdo con encuestas entre corporaciones globales, sólo el 35% de los CIO dirigirá la transformación digital de sus organizaciones. Estos especialistas también deben afrontar una pregunta, al parecer, sin respuesta sencilla: “¿Y por qué yo no?”.

CDO: una evolución posible para el experto TI

En la elección de un líder para dirigir la transformación digital, según los expertos, la mayoría de los CIO pierde la oportunidad por la misma razón: no logran demostrar de forma contundente que su habilidad tecnológica está firmemente alineada a los valores de negocio. Por ejemplo, los CIO pueden proyectar un gran conocimiento sobre IoT, pero pierden confianza ante cuestionamientos que un CDO debería responder: ¿qué significará IoT para la experiencia del cliente?, ¿esta innovación generará nuevas oportunidades o líneas de negocio?, ¿tendrá un efecto negativo en una oferta?, ¿cómo influirá IoT en la estrategia de ventas y mercadotecnia?

En ese sentido, en el marco de una transformación digital, el CDO entiende qué necesita cambiar, por qué debe hacerlo y cuál será la repercusión de negocio, mientras que el CIO se concentra en cómo realizar la modificación.

No obstante, un líder del área de Tecnología o Sistemas puede tomar las riendas de una iniciativa digital si cambia su enfoque y desarrolla nuevas capacidades. Entre otros aspectos, debería poner atención a:

Mejorar la comunicación con los líderes de negocio. En sus diálogos con otros gerentes y directivos es necesario reducir el uso de palabras como “algoritmo”, “protocolo” o “zettabytes”, y privilegiar conceptos como “trayecto del cliente”, “ventas multicanal” y “experiencia del usuario”, entre otros. Esto implica una nueva actitud y enfoque: no sólo pensar en el costo, la implementación y la gestión de la innovación, sino en cómo utilizarla para alcanzar metas de negocio que generan valor a la empresa.
Definir nuevos parámetros de colaboración. Dado su foco y experiencia en la operación, los CIO tienden a hablar y pensar en escala de “proyectos”. Hoy, la prioridad es interactuar con los distintos departamentos empresariales, entender sus objetivos y plantear “resultados de negocios”. El CDO es un habilitador de capacidades, no un gestor de tareas. Los mejores CDO detectan las necesidades de las áreas corporativas, incluso antes de que éstas las reconozcan.
Nueva escala de valores. En la dinámica de su equipo de trabajo original, el departamento de Sistemas o Tecnología, el CIO debe inculcar una cultura de la velocidad, la agilidad y el foco en el cliente. Esto creará una mentalidad “de CDO” entre los especialistas técnicos, lo que enriquecerá su visión de la empresa, la toma de decisión y el liderazgo.
Colaboración multidisciplinaria. En su camino a la posición de CDO, un líder tecnológico hará bien en acostumbrarse a trabajar con especialistas en ventas, mercadotecnia, logística, administración, producción, redes sociales, atención al cliente, etc. Sumar la perspectiva de estos colaboradores, en las metas de TI, fortalece la capacidad de análisis y ejecución de un CDO.

Más allá de estos aspectos, para asumir el timón de una transformación digital, los CIO deben superar un gran desafío. En muchas ocasiones, abrumados por las tareas operativas de TI que deben atender todos los días, los CIO no tienen tiempo para desarrollar la visión, la creatividad y las capacidades que exige el rol de CDO.

En este aspecto,soluciones de software para infraestructura, automatización, desarrollo y gestión de nube entre mucha más, facilitan la administración y operación de la infraestructura de TI existente, y habilitan el camino a tecnologías emergentes. Ambas capacidades, permiten que el líder de TI se concentre en la transformación innovadora del negocio, y tome mucho menos tiempo en tareas operativas.

Un CIO que se compromete con una nueva visión y el desarrollo de nuevas habilidades, sin lugar a dudas, puede ponerse al frente de una transformación digital, la transformación de la organización hacia el futuro de un negocio que evoluciona.

Bio

Olivia Salas es Directora de Marketing de Red Hat México.

El Desarrollo de Software y la Dinámica del Miedo

sg — Mon, 21 Aug 2017 20:15:54 +0000

El Desarrollo de Software y la Dinámica del Miedo

sg Mon, 08/21/2017 - 15:15

Publicado en

SG #55

Columna invitada

Autor

Raúl Guerrero

El síntoma más cotidiano en los equipos de desarrollo de software con problemas de desempeño es el caos. Este caos frecuentemente tiene una causa raíz en común, para ilustrarlo imaginemos la siguiente historia ...

Todo inicia en la reunión de dos compañías, el cliente “Somos Grandes Inc” y un proveedor de TI “Monkeys Devs”. En la reunión un gerente de línea de negocio quiere resolver un problema por medio de una solución tecnológica pero no sabe realmente cómo hacerlo, así que el director comercial de Monkeys Devs toma nota de la información que puede para entonces crear una propuesta comercial.

El director comercial está consciente de que la única forma de crear una propuesta adecuada es primero haciendo un análisis detallado, o proponiendo un modelo iterativo que permita ir descubriendo la solución por fases. Pero sabe que su principal competidor está dispuesto a dar una propuesta comercial sin dicho análisis, aun cuando el riesgo de desviarse sea amplio. Así que entrega una propuesta basada en supuestos.

Durante las juntas de revisión de la propuesta inicia el estire y afloje debido a que la propuesta rebasa el presupuesto del cliente, y al final, después de mucha magia y decisiones que desafían las leyes del tiempo y la materia, se aprueba el proyecto. Así que se da inicio al proyecto, y el equipo de trabajo no tiene acceso al contrato acordado (no vaya a ser que los desarrolladores se enteren cuánto se cobra por ellos), y por lo tanto no se tiene todo el detalle del compromiso adquirido.

-----

Este sería un buen momento para hacer un alto en el camino y cuestionar todas las malas decisiones que se han ido tomando, tal como los cambios sin sentido en el plan de trabajo, o cotizar una tarifa fija sin tener un análisis, pero cortaríamos el suspenso de esta historia.

-----

Una vez iniciado el proyecto, se inicia el análisis real. Se crea una nueva lista de requerimientos distinta a la del contrato, pero no se cuestiona porque los analistas no tienen acceso a éste. Se llenan documentos y minutas sin ton ni son y empieza la vorágine de los compromisos adquiridos durante las juntas, en donde el miedo a decir “eso no estaba en el alcance” hace su aparición. Por lo tanto, al final del análisis se cuenta con un nuevo compromiso.

Lo triste es que no importa cuánto te hayas tardado en el análisis, una vez terminado empiezan los cambios. Y por supuesto nadie quiere documentarlos; como si negar su existencia nos fuera a permitir ignorarlos. Así que empiezan los malos entendidos y juntas interminables en las que se habla de los cambios y todos se quedan callados; nadie quiere exponerse y entonces en muchas ocasiones se asume que el cambio se realizará.

La historia podría continuar y continuar, y si has llegado hasta esta parte de la historia es probable que recuerdes la sensación que tuviste alguna vez que te pasó lo mismo en un proyecto. Pero, ¿sabes algo? No estás solo, está es la vida de miles de personas que se dedican al desarrollo de aplicaciones. Y si nunca te ha pasado es probable que todavía no te haya tocado estar en un proyecto lo suficientemente complejo.

Ahora, si analizamos esta historia veremos que la mayoría de estas pesadillas se resuelven atendiendo la enfermedad.

¿Cuál es esa enfermedad? El miedo. Miedo a perder el proyecto por hacer el análisis, miedo a compartir el contrato con los desarrolladores, miedo a ser honestos y entregar el plan de trabajo con la estimación de los desarrolladores, miedo a administrar los cambios, miedo a reconocer que las cosas se tienen que hacer diferentes.

Es por ello que veo con esperanza cuando las compañías implementan prácticas ágiles y son capaces de sobreponerse al miedo, reconociendo que: el cliente quiere obtener valor continuo aún cuando no sabe de manera detallada lo que quiere, que es imposible planear de forma detallada lo que hará un desarrollador en 6 meses, ni siquiera se tiene dominio de las tecnologías requeridas para crear la solución. Es por ello que la entrega continua de compromisos de 3 a 4 semanas me parece tan adecuada y facilita las conversaciones cuando los cambios se solicitan, porque simplemente cada ciclo empezamos de nuevo.

La forma más tangible de encontrar la solución al problema es enfrentándonos nosotros mismos a romper el miedo de perder nuestra área de confort. Y en el camino encontraremos nuevos miedos y retos a enfrentar.

Así que estimado lector, ¿cuál es su primer miedo a romper?

Internet para Cerrar Brechas

ana2lp — Wed, 03 May 2017 05:36:33 +0000

Internet para Cerrar Brechas

ana2lp Wed, 05/03/2017 - 00:36

Publicado en

SG #54

Columna invitada

Autor

Alejandra Lagunes

El 17 de mayo se celebra a nivel mundial el Día de Internet. Una fecha para recordar la poderosa herramienta que es Internet; un gran espacio de interacción que está transformando sociedades en todos los sectores: la producción, las relaciones, el acceso a la información y al conocimiento.

La digitalización impacta positivamente el crecimiento del Producto Interno Bruto (PIB), la innovación y la oferta de servicios públicos [1]. Por otra parte, Internet permite acceder a contenidos a los que hace pocos años no teníamos acceso. Tan sólo 90% de la información disponible hoy en día se generó los últimos 2 años.

Es cierto, entonces, que la red más grande del mundo ofrece múltiples oportunidades y beneficios; sin embargo, también es cierto que nuevos retos aparecen. Uno de los más importantes es lograr que Internet y las nuevas herramientas tecnológicas se conviertan en mecanismos igualadores, que permitan mejorar la calidad de vida de todas las personas. Alcanzar este objetivo se ha convertido en prioridad para los gobiernos y sociedades de todo el mundo.

En septiembre de 2015 la Asamblea General de la ONU adoptó la Agenda 2030 para el Desarrollo Sostenible. Se trata del documento que establece los objetivos de la humanidad para 2030 y que buscan erradicar la pobreza, fomentar la prosperidad y lograr mayor igualdad. No sólo eso, la Agenda 2030 reconoce a las TIC como un habilitador esencial para hacer frente a los grandes desafíos de la humanidad.

En México, el potencial de Internet para cerrar brechas es un tema que ha tomado cada vez más importancia y hoy, como nunca antes, está en la agenda de gobierno, sector privado y academia. En junio de 2013, se promulgó una Reforma en materia de Telecomunicaciones con la que el acceso a Internet se convirtió en un derecho constitucional y se definió el marco legal que establece mayor competitividad en la oferta de servicios de telecomunicaciones. El avance en el sector en los últimos tres años ha sido importante. Los precios de servicios de telecomunicaciones se han reducido más de 20%; mientras que los usuarios de Internet en nuestro país ya son cerca de 70 millones, lo que representa un incremento de cerca de 70% respecto a 2012.

Por otra parte, para fomentar la adopción y desarrollo de las TIC, bajo el marco de la Estrategia Digital Nacional, se han puesto en marcha diversos proyectos que fomentan que cualquier persona, sin importar condición social, edad o género, aproveche el potencial de Internet y las nuevas tecnologías. En primer lugar, se encuentra el Programa de Inclusión Digital, denominado @prende 2.0, que la Secretaría de Educación Pública puso en marcha. Este programa tiene 4 pilares: capacitación docente; una plataforma en línea con miles de materiales educativos; equipamiento y conectividad; y monitoreo y evaluación continúa. El objetivo final del @prende 2.0 es que la tecnología esté al servicio de profesores y estudiantes para que desarrollen habilidades digitales, sean creativos, colaborativos; que tengan las herramientas necesarias para ser competitivos en la sociedad del siglo XXI. Otro proyecto es CódigoX, cuyo propósito es impulsar que cada vez más mujeres y niñas se involucren en el área de las TIC, desde diversos ámbitos. Uno de sus componentes más relevantes es un programa de mentorías que acerca a mujeres líderes en áreas de ciencia y tecnología con jóvenes interesadas en acumular experiencia y aprendizaje en estas áreas. Además, por medio de CódigoX se han organizado talleres, conferencias y cursos, logrando que más de 800 niñas y mujeres sean parte de este proyecto. Por otra parte, desde 2015 se puso en marcha la Red Nacional de Puntos México Conectado. Esta Red se conforma por 32 Centros de Inclusión Digital, en los que se ofrecen talleres y cursos para fomentar la innovación, el emprendimiento tecnológico y el uso de las nuevas tecnologías.

Las acciones y programas mencionados son sólo algunos ejemplos de lo que que sucede cuando Internet se convierte en aliado del gobierno y de la sociedad para generar espacios de inclusión. Es una transformación que está empezando y que ya ha permitido que México mejore en diversos indicadores del mundo digital. De 2014 a 2016 avanzamos 16 lugares en el Índice de Servicios en Línea, al pasar de la posición 35 a la 19; avanzamos también 31 lugares en el Índice de Participación en Línea, pasando del lugar 45 al 14 de entre 193 países. En ambos casos, somos también líderes en América Latina.

Es claro que Internet permite construir mejores realidades; nuestro país vive un momento único en el que todos los sectores están sumando a la construcción de un México más moderno e incluyente. Es tarea de todos continuar con esa labor.

Referencias

R. Katz. El ecosistema y la economía digital en América Latina. Fundación Telefónica, Editorial Ariel, CEPAL. Enero, 2015. http://swgu.ru/st

Bio

Alejandra Lagunes Soto Ruiz es Coordinadora de Estrategia Digital Nacional. Elabora, da seguimiento y evalúa periódicamente la Estrategia Digital Nacional; fomenta la adopción y el desarrollo de tecnologías de la información y comunicación; impulsa el gobierno digital; promueve la innovación, apertura, transparencia, colaboración y participación ciudadana para insertar a México a la sociedad del conocimiento.

El Caso de PHP y los Salarios

ana2lp — Fri, 23 Dec 2016 01:35:01 +0000

El Caso de PHP y los Salarios

ana2lp Thu, 12/22/2016 - 19:35

Publicado en

SG #53

Columna invitada

Autor

Basilio Briceño

Como programador uno se pregunta ¿en qué lenguaje debo invertir mi tiempo? es cierto que no existe el lenguaje perfecto y que la elección usualmente es basada en preferencias personales o en el tipo de problema a resolver, sin embargo, existe otro punto a tomar en cuenta: el financiero, o en términos simples, ¿en qué lenguaje debo especializarme para ser mejor pagado?

Y es donde nos preguntamos ¿por qué muchos empleadores pagan más a programadores especializados en ciertos lenguajes que en otros? ¿qué es más importante a ser tomado en cuenta a la hora de establecer tabuladores salariales: la experiencia del programador, lo complejo de la tarea a realizar, o el lenguaje de programación a usar? Si se contrata a un carpintero, no se le contrata debido a que utiliza martillos Stanley o destornilladores Craftsman, se le contrata porque sabe hacer bien su trabajo y da resultados. Si lo mismo aplícase a los programadores, entonces ¿por qué muchas empresas en México aún insisten en pagar tarifas basadas en el lenguaje de programación?

Y ¿qué tiene que ver PHP en lo anterior? pues resulta que es uno de los lenguajes con el que los programadores salen más afectados en términos financieros. PHP es un lenguaje interpretado fácil de aprender, flexible y se puede desarrollar con él en tiempos muy cortos, además es genial para utilizarse como pegamento entre aplicaciones. Siendo así, ¿por qué es prácticamente considerado inferior?

Técnicamente el lenguaje nació para desarrollo web, fue creciendo y adaptándose a las necesidades de los desarrolladores. Muchos desarrolladores expertos en otros lenguajes lo critican por haberse vuelto popular muy rápido sin tener una base tan sólida y reglas estrictas como en los lenguajes de uso general, solo que en su afán por establecer que PHP está mal olvidan no fue planeado como un lenguaje de uso general, sino para facilitar el desarrollo web.

Entonces ¿PHP es técnicamente inferior? No, el motivo por el que es criticado está principalmente basado en un círculo vicioso generado por los programadores novatos. ¿Cómo es esto?, cuando un novato generalmente no presta atención en la calidad de sus entregables, se enfoca únicamente en terminar lo que le piden sin añadir ningún valor agregado a su trabajo, ¿el resultado? programas en estilo código spaghetti, estructuras mal aplicadas, carencia de optimizacion, entradas de datos inseguras, y un sinfín de “características” más.

Lo anterior obviamente repercutirá en el desempeño del programa y en el costo de mantenerlo. Sin embargo, curiosamente el enfoque no es dirigido hacía el programador novato, sino sobre el lenguaje.

Así entonces mientras más novato el programador peor calidad de código, ante inferior calidad más desconfianza se genera en el lenguaje, al existir desconfianza en el lenguaje menor es la apuesta en términos salariales, a menores salarios los programadores con experiencia y enfoque en la calidad se interesan menos en el lenguaje, a menor cantidad de programadores con experiencia mayor contratación de programadores novatos, a mayor cantidad de programadores novatos peor calidad de código y de ese modo el ciclo va degradando el valor salarial sobre el uso del lenguaje.

Por si fuera poco, el programador novato llega a creer que lo que hace es todo lo que se puede hacer con PHP, incluso hay quienes colocan en su currículo el adjetivo “experto en PHP” o “nivel avanzado en PHP”, y al considerarse a sí mismos expertos no se esfuerzan en aprender más, ni en mejorar la calidad de su trabajo. Sin embargo más allá de sólo exponer el problema ¿cómo se pudiera convertir el círculo vicioso en uno virtuoso?

Mientras mayor calidad y valor agregado ofrezca el programador, mejores resultados verá el empleador, a mejores resultados el empleador debe ofrecer un mejor salario, con mejores salarios en el mercado, más programadores con experiencia y enfoque en calidad se verán interesados, así como los programadores novatos en mejorar la calidad de su trabajo para llegar obtener dichos salarios, a mayor cantidad de programadores con experiencia, mayor calidad en el código y mayor valor agregado, y de ese modo el ciclo va enriqueciendo la calidad de los entregables y el valor salarial.

Un buen punto de arranque para comenzar a cambiar el ciclo es reconocer en donde se encuentra actualmente el programador y fijar metas para mejorar. Basado en lo anterior surgió en el grupo de programadores de “PHP México” una iniciativa para definir un tabulador sencillo basado en los conocimientos y capacidades de los programadores, lo presento a continuación.

Novato. Generalmente escribe PHP, SQL y HTML/JS/CSS en el mismo archivo y acostumbra a copiar y pegar cualquier cosa que se encuentra en internet que parecer hacer lo que se le pidió entregar y que según dicen los foros es la solución.
Aprendiz. Ha aceptado que necesita mejorar y decide aprender mejores prácticas y aplicarlas. Consulta en foros no para buscar codigo para copiar y pegar, sino para analizarlo y pregunta después de haber investigado por cuenta propia.
Junior. Sabe qué son los patrones de diseño y los utiliza, entiende qué es MVC, REST, CRUD, ORM, SQL Injection, XSS, I/O Sanitization, etcétera, y usa estas y otras técnicas, así como mejores prácticas; es excelente aprendiendo y usando APIs de terceros.
Senior. Es capaz de desarrollar sus propias herramientas y APIs; es consciente de cómo funciona PHP internamente, está sumamente interesado en el desempeño de las aplicaciones más allá de su facilidad de desarrollo; no está satisfecho con el funcionamiento de todas las herramientas y APIs de terceros tal cual vienen y siempre busca innovar y crear cosas que mejoren el desempeño, faciliten su trabajo y la velocidad de sus entregables; contribuye con código en diferentes proyectos y comunidades; entiende la frase “PHP es el frontend de su backend”.
Master. Es capaz de desarrollar sus propias extensiones para PHP en C, contribuye a PECL y normalmente se dedica a mejorar el desempeño de aplicaciones de alto rendimiento. Conoce bien el lenguaje Hack, su origen y diferencias respecto a PHP.
Core. Contribuye al desarrollo del core de PHP o el motor de Zend; contribuye en algunas extensiones y herramientas públicas; es un ponente frecuente en conferencias internacionales y es usual ver su nombre en PECL y en los créditos en cambios de versión de PHP.

Respecto de los salarios, estos pueden variar dependiendo la zona, los siguientes son sugeridos con base a los costos de vida de las principales ciudades de México en Diciembre de 2016:

Novato - hasta 10 mil pesos.
Aprendiz - de 10 a 18 mil pesos.
Junior - de 18 a 30 mil pesos.
Senior - de 30 a 50 mil pesos.
Master - de 50 mil en adelante.

Ahora bien, no todo recae en el programador. El empleador debe ser consciente de este tabulador y aplicarlo o mejorarlo con base a los resultados de sus programadores, así como participar en la implementación de medidas que contribuyan a la mejora continua de las habilidades de sus programadores. De hacerse así es muy probable que se logren mejorar la calidad del software desarrollado con PHP y que se incrementen los beneficios mutuos.

Bio

Basilio ha contribuido por más de 15 años con diversas organizaciones como desarrollador, líder técnico, administrador de sistemas, líder de operaciones web, Jefe de Departamento, entre otras responsabilidades. Desde hace 4 años colabora con empresas de venta al detalle en Estados Unidos como GAP, Kohls, LVMH, entre otras automatizando procesos para reducir el tiempo de liberación al mercado de soluciones de comercio electrónico bajo un esquema DevOps utilizando diversas herramientas de integración y entrega continuas.

5 Puntos Clave Para Construir una Comunidad en Línea

ana2lp — Fri, 23 Dec 2016 01:23:21 +0000

5 Puntos Clave Para Construir una Comunidad en Línea

ana2lp Thu, 12/22/2016 - 19:23

Publicado en

SG #53

Columna invitada

Autor

Juan Lombana

Crear una comunidad en línea desde cero es todo un reto. La buena noticia es que si estás en la etapa del inicio puedes construirla de la manera correcta desde un principio.

Mi nombre es Juan Lombana y fui parte del equipo responsable de crear la comunidad en línea de Google Partners para varios países de Latinoamérica. Aunque esta tarea nos llevó mucho tiempo y esfuerzo, terminamos por construir una comunidad gigantesca.

Al usar el adjetivo “gigantesca” para referirme a la comunidad de Google Partners, no únicamente me refiero a su tamaño por número de miembros, sino que a las muchas interacciones entre estos miembros, que en mi opinión, son el punto más importante sobre una comunidad.

Así que después de esta grata experiencia comparto aquí los que considero son 5 puntos clave para construir una comunidad en línea.

Define tu identidad con la comunidad

El primer punto que necesitas entender es: ¿Quién serás tú en esa comunidad? Puedes ser identificado como una marca o usar un acercamiento más personal y escribir en nombre de ti mismo. Me parece que la primera opción es mucho mejor para grandes marcas y la segunda para expertos en determinados temas.

Enfócate en ayudar

La gran mayoría de las personas que están construyendo una comunidad en línea lo hacen con el fin de crecer su negocio, lo sé, lo sé. Sin embargo tienes que pensar en tu comunidad como una manera de ayudar a la gente, cuando los ayudes sin pedirles nada a cambio, algunos te comprarán y algunos no lo harán, pero lo importante es que estarás ahí para ellos de manera incondicional.

Las comunidades son para ayudar, no para vender. Si quieres hacer alguna actividad de marketing que esté orientada a ventas, el SEO o el SEM son una mejor opción para ti.

Se proactivo, no reactivo

Seguramente tú mismo sigues alguna página o eres miembro de alguna comunidad en línea. A cualquier persona le gusta seguir páginas que publican contenido interesante, responden rápido a los comentarios y usan cada aspecto de las redes como las encuestas, concursos y diferentes tipos de contenido.

Si quieres construir una comunidad que participe y esté altamente enganchada, tú tienes que ser el primero en poner ese ejemplo.

Sé original

Cualquier persona, de verdad cualquiera, puede abrir una página de Facebook y compartir contenido que viene de otras fuentes, o usar Twitter únicamente para retwittear. Ese tipo de estrategia no te va a llevar muy lejos a la hora de crear una comunidad, no añade valor y te convierte en un ladrón de ideas.

Para realmente añadir valor tienes que compartir contenido que nadie más haya compartido nunca, contenido producido por ti, con esto no quiero decir que este contenido tiene que ser de compleja producción, simplemente original.

La agenda es la reina

Aunque la frase original es “El contenido es rey” realmente pienso que lo segundo más importante es tener un plan de contenidos y fechas. Al hacer esto siempre estás interactuando con tu comunidad y además lo haces de manera que las personas se acostumbran a la frecuencia con la que compartes contenido, ya sea una vez al día, a la semana o al mes…una agenda crea orden para ti y para todos los que son parte de la comunidad.

Necesitas tener un plan de al menos un mes de contenido antes de abrir tu comunidad, siempre es bueno tener un equipo con reservas.

Conclusión

Si bien, estos cinco puntos te deberían ayudar bastante a la hora de crear tu comunidad en línea, me encantaría advertirte que esto requiere mucho más dedicación de lo que parece.

Tienes que estar muy comprometido con la meta y el motivo de esta comunidad por un largo tiempo y ser sumamente paciente, asegúrate de que tu agenda te permite este tiempo.

Por otro lado, si realmente estás comprometido, no dejes que nada ni nadie te detenga ya que cuando logras crear una comunidad enganchada en línea, el sentimiento es invaluable.

Si tienes alguna pregunta, por favor contáctame en @Juan_Lombana.

Bio

Juan Lombana (@juan_lombana) es Google Expert en Marketing y Google Regional Trainer para México y escribe en su blog sobre marketing digital Mercatitlán. www.mercatitlan.com

Columna invitada

De event-stream, npm, y Arquitecturas que Invitan al Desastre

Publicado en

Autor

¿Qué pasó con event-stream?

¿Cómo podría haberse evitado?

Una visión consistente, coherente, completa del sistema

Competencias Digitales

Publicado en

Autor

La Historia de Sun Microsystems

Publicado en

Autor

Parte 1. The Network is the Computer

Parte 2. Write Once. Run Everywhere

Kung Fu Analítico: Las tres disciplinas mentales de los líderes de analítica y ciencia de datos

Publicado en

Autor

Pensamiento crítico cuantitativo

Pensamiento estadístico

Pensamiento científico

Conclusión: El rol del líder analítico

Re-Educación versus Rezagos

Publicado en

Autor

CDO: Se buscan líderes digitales

Publicado en

Autor

CDO: una evolución posible para el experto TI

El Desarrollo de Software y la Dinámica del Miedo

Publicado en

Autor

Internet para Cerrar Brechas

Publicado en

Autor

Tags

El Caso de PHP y los Salarios

Publicado en

Autor

Tags

5 Puntos Clave Para Construir una Comunidad en Línea

Publicado en

Autor

Define tu identidad con la comunidad

Enfócate en ayudar

Se proactivo, no reactivo

Sé original

La agenda es la reina

Conclusión

Tags