SG28 (Mayo - Julio 2010) by Revista Software Guru

Web Semántica

NOSQL

COLUMNA: INDUSTRIA Arquitectura de Software

P.16

P.30

P.34

No.

UN VISTAZO A...

HTML5

CONOCIMIENTO EN PRÁCTICA | Febrero-Abril 2010 www.sg.com.mx

Servicios Basados en Ubicación

USTED está

aquí EMPRENDIENDO México, $65.00

Emprendedores e Innovación ¿Qué, Cómo y Por Qué?

CONOCIMIENTO EN PRÁCTICA

Pág.

.CONTENIDO Mayo-Julio 2010 |

www.sg.com.mx

En Portada Servicios basados en ubicación

Un recorrido por las nuevas tecnologías satelitales de ubicación y el tipo de servicios existentes.

Columnas Tejiendo Nuestra Red

por Hanna Oktaba

Mejora Contínua

por Luis Cuellar

Tendencias en Software

por Luis Daniel Soto

Programar es un Estilo de Vida

por Gunna Wolf

Prueba de Software por Orlando Rincon

.CONTENIDO

SG 28

Pág.

Emprendiendo Productos Emprendedores e Innovación

Lo que Viene 12

Mostramos el verdadero reto al que se enfrentan las pequeñas industrias de software.

Android 2.2, Windows Azure, VMForce.

Herramientas

Web semántica. La complejidad para un internet más sencillo.

Un Vistazo A

HTML 5 El paradigma está cambiando

Prácticas, técnicas y principios que te ayudarán a la hora de programar

Gestión de Datos No SQL

Noticias

Fundamentos

Gadgets

Carrera

Principios, patrones, prácticas y tecnologías para lograr que tus aplicaciones utilicen una modularización efectiva.

Arquitectura Requerimientos y Arquitectura

Editorial

Entrando en materia sobre qué es la arquitectura de software, su importancia y el ciclo de vida de una arquitectura.

Agilidad Software y Producción Lean y Agile son muy efectivos por sí solos, pero juntos hacen una combinación fabulosa.

Pág.

www.sg.com.mx |

Programación Disciplínate

Software Guru

En Cada Número

Prácticas

.EDITORIAL Bienvenida

La localización será el “killer app” de los dispositivos mòviles.

Más vale tarde ...

espués de algunas complicaciones, retraso por el cual pedimos una disculpa a nuestros lectores y colaboradores, finalmente toca turno a la edición número 28 de SG. En esta ocasión hemos dedicado el tema principal al desarrollo de aplicaciones que utilizan información geográfica y de ubicación del usuario. De acuerdo con los analistas, la localización será el “killer app” de los dispositivos móviles. En esta serie de artículos conoceremos los servicios y tecnologías que hoy en día se encuentran a nuestro alcance, así como las diferentes opiniones y visiones sobre las múltiples oportunidades que existen en relación al desarrollo de aplicaciones de geolocalización. Por otro lado, les comentamos que debido al eminente movimiento de los medios impresos a medios digitales, y con la finalidad de mantenernos en esta ideología, en los próximos meses verán que fortalecemos mucho nuestra oferta online. De hecho es nuestra tarea durante este verano, junto con organizar el congreso SG Virtual. Siguiendo la misma línea, les recordamos que SG cuenta ya con diferentes proyectos virtuales, enfocados en resolver las principales necesidades de los profesionistas y emprendedores de TI. Entre estos proyectos queremos mencionar SG Campus www.sgcampus.com.mx, portal dirigido a la educación virtual, que hemos reorganizado en grupos de aprendizaje colaborativo. SG campus es el espacio donde la comunidad de SG se encuentra para compartir experiencias y conectar con colegas, en diferentes temas como: cómputo en la nube, gobierno de TI, mejora de procesos, métodos ágiles, java empresarial, open source, entre otros. Te invitamos a integrarte a estos grupos de aprendizaje y participar en los espacios colaborativos.

››Equipo Editorial Software Guru

DIRECTORIO SG Dirección Editorial Pedro Galván / Dirección de Operaciones Mara Ruvalcaba Coordinación de contenidos Alejandro Escamilla / Arte y Diseño Oscar Sámano, R. Alexis Ramírez Consejo Editorial Jorge Valdés - PMI / Luis Cuéllar - Softtek / Luis D. Soto - Microsoft / Hanna Oktaba - UNAM / Emilio Osorio - Sistemas Humanos / Luis Vinicio León - e-Quallity / Gloria Quintanilla

Colaboradores Oscar Ramírez, Hugo Stevens, Javier Solís, Carlos O. Ramírez, Héctor Cuesta, Agustin Ramos, Carlos Ruiz, Paco Cuevas, Erick Camacho, Humberto Cervantes, Edith Valencia, David Hussman, Masa Maeda, Ricardo Rangel, Homero Alonso Vela, Gunnar Wolf, Orlando Ezequiel Rincón, Patricio Dueñas, Adalberto Gonzalez. Ventas Claudia Perea / Circulación y Atención a Clientes Lacendi Calderón / Comunicación Montserrat Ramírez Contacto info@sg.com.mx SG Software Guru es una publicación trimestral editada por Brainworx, S.A. de C.V., Temístocles 34 piso 3, México DF 11560. Los contenidos de esta publicación son propiedad intelectual de los autores y están licenciados bajo Creative Commons Atribución-No comercial 2.5 México. Todos los artículos son responsabilidad de sus propios autores y no necesariamente reflejan el punto de vista de la editorial. Reserva de Derechos al Uso Exclusivo: En trámite. ISSN: 1870-0888. Registro Postal: PP15-5106. Distribuido por Sepomex. Se imprimió en junio de 2010 en 4Press.

.NOTICIAS

.Gartner Enterprise Integration Summit

.Lanzamiento Windows Azure

Durante el mes de abril Microsoft organizó en nuestro país diversos eventos de lanzamiento para su plataforma de cómputo en la nube, Windows Azure. Entre los eventos destacó la presencia en México de Steve Ballmer, CEO de Microsoft, quien presentó su visión sobre la nube y cómo esta generación de innovaciones tecnológicas crea oportunidades para que las personas estén más conectadas, sean más productivas y creativas en cualquier lugar, sin importar el dispositivo de acceso. Los países de América Latina donde Windows Azure y SQL Azure ya están disponibles son: Brasil, Chile, Colombia, Costa Rica, México, Perú, Puerto Rico y Trinidad y Tobago.

Del 20 al 21 de abril se llevó a cabo el Gartner 5Th Annual Enterprise Technologies Summit en la Ciudad de México, los temas principales alrededor de los cuales giraron las conferencias de este año fueron entre otros: manejo de retos en modernización y la integración heredada, evolución de SOA, servicios Web y Web 2.0, escenario de CloudComputing, redes sociales, escenario BPM, mejores prácticas de la arquitectura empresarial. La conclusión más interesantes de los expertos de Gartner fue: El uso de TIs en las empresas se ha vuelto indispensable para aumentar la productividad, pero en México no se ha dado tal adopción, pues la adquisición de esta tecnologías requieren un gasto fuerte y la mayoría de las empresas no han destinado lo necesario para implementarlas en sus procesos y negocio.

.Tendencias en la Administración Pública

Select presentó el evento “Tendencias en la Administración Pública”. Ricardo Zermeño destacó la necesidad de aumentar la competitividad dentro de la administración pública para brindar, por un lado, una mejor atención a los ciudadanos y, por otro, tener una mejor recaudación de ingresos a fin de incrementar su productividad. Para alcanzar estas metas, en Select consideran necesario formular estrategias que incluyan la formación de procesos y la adopción de la tecnología, todo centrado en la atención y necesidades de la ciudadanía. La consultora propone para ello un modelo de siete mejores prácticas: innovación, capital humano, capacidad TIC, monitoreo, colaboración, compensación y gobernabilidad.

.Día del Internet

La Asociación Mexicana de Internet (AMIPCI) celebró por quinto año consecutivo el Día Mundial de Internet. En esta ocasión se llevó a cabo en la ciudad de Monterrey, Nuevo León. Abordó el tema de la integración de las micro, pequeñas y medianas empresas a las nuevas tecnologías de la información y la comunicación. Julio César Vega, Director General de la AMIPCI, resaltó la necesidad de que la Agenda Digital Nacional incluya programas en materia de competitividad que impulsen la adopción de las TIC entre las Mipymes del país. Comentó que la adopción de las TIC entre las empresas de este sector ha sido lenta, no obstante que cada vez son más los servicios gubernamentales y financieros disponibles en línea, muchos de ellos de carácter obligatorio.

Para mayor Información, Noticias al Día y Actualizaciones de la industria visita: www.sg.com.mx

www.sg.com.mx |

IBM de México realizó por cuarto año consecutivo su Industry Forum, evento orientado a promover el aprovechamiento de TI y comentar sobre las tendencias en distintas industrias y segmentos tales como financiero, telecomunicaciones, comercialización y gobierno, entre otros. Durante el evento de 3 días se impartieron más de 50 conferencias que contaron con la participación de ponentes como el Dr. Guillermo Ortiz, ex Gobernador del Banco de México, y Leopoldo Vilchis, Director de Desarrollo Tecnológico en Conacyt. Incluso Grady Booch, Científico en Jefe en IBM Software, participó por medio de una conferencia web en vivo.

Software Guru

.IBM Industry Forum

.COLUMNA Tejiendo Nuestra Red

Certificación de Profesionales en Ingeniería de Software

una propuesta de

n los últimos años se han hecho grandes esfuerzos para que la industria de software mexicana aparezca en el mapa nacional e internacional. Esto se ha logrado gracias a los esfuerzos de individuos, empresas, regiones, gobiernos y la academia. Tenemos muy buenos ejemplos de éxito en varios rubros, sin embargo considero que todavía no debemos cantar victoria: la gran parte de la industria de software en México sigue siendo poco competitiva. Para aclarar qué significa la competitividad, revisemos la siguiente definición extraída de www.zonaeconomica. com/definicion/competitividad:

La competitividad es la capacidad que tiene una empresa o país de obtener rentabilidad en el mercado en relación a sus competidores. La competitividad depende de la relación entre el valor y la cantidad del producto ofrecido y los insumos necesarios para obtenerlo (productividad), y la productividad de los otros oferentes del mercado. El concepto de competitividad se puede aplicar tanto a una empresa como a un país. Por ejemplo, una empresa será muy competitiva si es capaz de obtener una rentabilidad elevada debido a que utiliza técnicas de producción más eficientes que las de sus competidores, que le permiten obtener ya sea más cantidad y/o calidad de productos o servicios, o tener costos de producción menores por unidad de producto.

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

Notamos que las palabras clave para lograr la competitividad son la rentabilidad y la productividad. En el ejemplo de la competitividad de una empresa se agrega la utilización de técnicas de producción más eficientes que las de sus competidores. Este último punto nos confirma que no estábamos tan equivocados tratando, desde finales de los 90s, de promover la adopción de buenas prácticas a través de modelos SW-CMM, CMMI, MoProSoft, Competisoft para incrementar la competitividad de las empresas. Sin embargo, en todos estos años hemos observado que su adopción no es ni tan fácil ni tan masiva como lo hubiéramos deseado. Actualmente existen en México alrededor de 2,500 empresas dedicadas al desarrollo de software de las cuales 41 están evaluadas en algún

estrategia

nivel de CMMI (entre ellas se encuentran áreas internas) y 183 en MoProSoft, lo que significa menos del 10% del total. Otro dato inquietante es que los diagnósticos que se aplican en México a las empresas que quieren adoptar MoProSoft –o en Iberoamérica Competisoft– muestran una brecha muy grande entre lo que la gente hace y lo que los modelos dicen que se debe de hacer.

“Ya es hora de que

pensemos en un esquema nacional de certificación de Ingenieros de Software.” Esto me lleva a la conclusión de que, tal vez, el obstáculo más de fondo para lograr la competitividad está en la baja profesionalización de los recursos humanos que están trabajando en la industria. Con esta afirmación no quiero ofender a nadie, solamente quiero que reflexionemos sobre el asunto. Para empezar, preguntémonos ¿qué es lo que distingue a una profesión reconocida? Según Starr (1982), es una profesión en la cual: El conocimiento y las competencias están validados por la comunidad de pares. El conocimiento validado de manera consensada está basado en fundamentos científicos y/o racionales. Los juicios y los consejos están basados en un conjunto de valores sustanciales. En mi opinión nos falta la consolidación y el acuerdo nacional sobre estos puntos. Preguntémonos: ¿por qué los médicos, los abogados o los contadores se han profesionalizado? Una de las razones más importantes es que su trabajo impacta direc-

.COLUMNA Tejiendo Nuestra Red

››Las palabras

clave para lograr la competitividad son la rentabilidad y la productividad.

tamente a la salud o los derechos e intereses de los ciudadanos. ¿Y en el caso de la industria de software no pasa lo mismo? Creo que ya es hora de que pensemos en un esquema nacional de certificación de Ingenieros de Software y sus perfiles, tales como Analistas, Arquitectos, Expertos en Pruebas, Programadores, entre otros. Afortunadamente, no tenemos que empezar desde cero. Ya se publicó el estándar internacional ISO/IEC 24773 Certification of Software Engineering Professional el cual define lineamientos generales para crear un esquema de certificación. Esta norma propone usar como cuerpo

de conocimiento otro estándar de ISO/ IEC 19759 Software Engineering Body of Knowledge (SWEBOK). Países como Australia y Japón ya cuentan desde hace tiempo con este tipo de esquemas. ¿Qué beneficios traería tener el esquema de certificación de profesionales en Ingeniería de Software? Para los individuos: reconocimiento nacional e internacional del nivel de conocimiento, experiencia y habilidades personales, así como una claridad en las opciones de la carrera profesional. Para la industria: mayor seguridad en la contratación de los recursos humanos

y posibilidad de la mejor clasificación de remuneraciones. Para la academia: lineamientos curriculares. Agregaría como hipótesis final, que tener profesionales de Ingeniería de Software en la industria sería una buena estrategia para aumentar su competitividad. Los recursos humanos profesionalizados ya no tendrían tanta dificultad para adoptar las buenas prácticas que los modelos sugieren. Esto ayudaría en la disminución de los costos y de la resistencia organizacional. ¿Verdad que soy soñadora?

››Por Hanna Oktaba

.COLUMNA Mejora Continua

El Camino del Cambio el

aprendizaje de un agente de cambio

urante estos meses he dedicado tiempo al desarrollo de equipos dedicados a administrar cambio. Uno de los temas que constantemente surge es: ¿Cómo debe ser el plan de carrera para estos grupos?

“Además de defender un punto de vista, también hay que saber venderlo a quienes no lo entienden o no les interesa.” En el desarrollo de software el camino más común luce algo así: inicias programando, posteriormente puedes moverte a analizar, diseñar o probar, luego pasas a ser líder de un proyecto pequeño, después diriges un proyecto grande, luego diriges un área, y así sucesivamente sin límites. Cada paso es muy claro, las actividades a desarrollar son diferentes y existen siempre cosas nuevas que aprender. En cambio, el crecimiento en las áreas de calidad no es tan claro. Los escalones no están bien definidos y en muchas ocasiones implica cambiar de forma de pensar y actuar, un cambio completo en forma de ser y percibir las cosas lo cual es un reto difícil de lograr. En estos renglones trataremos de dar un poco de luz a lo que considero se espera de un agente de cambio en cada una de sus etapas profesionales. Como dijimos anteriormente, en el plan de carrera de un administrador de cambio no está claro donde inicia un nivel y termina otro. Podríamos definir una gran cantidad de niveles con pequeñas diferencias entre ellos, pero por restricciones de espacio vamos a definir tres niveles principales: Luis R. Cuellar es director de calidad a nivel mundial de Softtek. Es reconocido por la ASQ como Certified Quality Manager, Certified Sofware Engineer y Six Sigma Black Belt. @lcuellar

• Aprendiz de Agente de Cambio, • Agente de Cambio Básico • Agente de Cambio Experimentado. Cada uno de estos niveles es importante en una organización. Obviamente el número de roles y personas depende del tamaño de la organización: si solamente se tiene un agente

de cambio, la idea es que sea experimentado; si existen dos entonces un experimentado y un básico podría ser suficiente; y así sucesivamente. A continuación defino estos niveles.

El aprendiz de agente de cambio

Este es el mejor lugar para entrar en un área de calidad, especialmente cuando no se tiene experiencia haciendo cambios organizacionales. Aquí entran normalmente personas recién egresadas o que tienen poco tiempo haciendo labores en otras áreas de la organización. Para este rol se busca principalmente gente proactiva, con mucha energía y muchas ganas de aprender nuevas cosas. En este nivel es importante empezar a conocer el modelo de mejora utilizado en la organización, ya sea CMMi, Six Sigma, Lean, etcétera, y también desarrollar conocimiento sobre la organización: cuál es el negocio principal, como la compañía genera dinero, que problemas tienen las diferentes personas con las que interactuamos, quién es quién y qué opinión tiene sobre el calidad, mejora continua, métricas, documentación, etcétera.

El agente de cambio básico

Normalmente en este nivel se encuentra gente con un fuerte dominio en términos teóricos: personas que ya entienden el modelo que se utiliza y saben aplicarlo en la organización, conocen los procesos y los procedimientos y saben trabajar con gente, pueden explicar lo que están haciendo y por qué es importante, pueden defender sus ideas y saben cuando algo se ejecuta correctamente y cuando no. Es importante en este nivel iniciar a trabajar las habilidades de manejo de grupos, habilidades de negociación y de escucha. A partir de dichos factores es que el cambio en la forma de actuar y pensar inicia, aquí se inicia la generación de empatía y el descubrimiento de que los avances se dan paso a paso. La evolución de nivel básico a nivel avanzado es posiblemente la más difícil en un agente de cambio, ya que a partir de aquí se busca un cambio total de cómo lograr las cosas. Aquí es donde empieza a ser menos importante el conocimiento técnico y más importante el conocimiento conceptual. Por ejemplo, no sólo es importante saber el método específico que utilizamos para administrar riesgos, sino por qué es que utilizamos este sobre otros, y poder evaluar si lo que se hace actualmente cubre o no con las necesidades de la organización. Como ya comenté, también se requiere aprender a manejar habilidades de escucha e influencia.

Además de defender un punto de vista, también hay que saber venderlo a quienes no lo entienden o no les interesa. En este nivel es cuando se empiezan a vislumbrar estrategias y diferentes caminos para llegar a un objetivo.

El agente de cambio experimentado

Aquí es donde finalmente se une el entendimiento conceptual y las habilidades personales. No solo se requiere conocer la tecnología, la organización y el cambio que se espera lograr, sino también planearlo, negociarlo y coordinar su ejecución. • Un agente de cambio experimentado: • Tiene habilidades para influenciar a un grupo de personas y escucharlas para lograr una solución ganar-ganar. • Puede manejar reuniones con grupos grandes de personas y lograr resultados. • Tiene fuertes habilidades de negociación y de empatía. Puede entender cómo se sienten las personas con el cambio que se está proponiendo, identifica cuáles son los principales bloqueos y buscar una forma adecuada de lograr objetivos comunes. • Conoce la organización, hacia donde va y por qué. • Se conoce a sí mismo, sus fortalezas y sus debilidades y está constantemente buscando como aprender a hacer mejor su trabajo. Yo sé que suena complicado. Adicionalmente, un agente de cambio requiere de mucha paciencia y de una gran habilidad de mantener la calma bajo presión. En muchas ocasiones lo comparo con escalar una montaña, ya que se requiere de buscar pequeños huecos en donde podemos afianzarnos para llegar a la cima. Es un trabajo difícil y extenuante, que se lleva a cabo paso a paso. Pero cuando logras un cambio positivo en una organización, es la satisfacción más grande que se pueda uno imaginar.

››Por Luis Cuellar

.INDUSTRIA

¿Por qué

México?

››Por Oscar Ramírez Vital

tendencias globales

“Singapur, país que era más pobre que México hace 20 años, posee hoy un ingreso per cápita similar al de los Estados Unidos, ¿cómo? … entendieron cómo funciona la economía del conocimiento” -Juan Enríquez Cabot (Investigador Mexicano)

esde principios del 2006, empresas de la India ubicadas en el TOP10 de la industria del software y BPO (Business Process Outsourcing) a nivel mundial, llegaron a nuestro país para instalarse y comenzar a atender a sus clientes en Estados Unidos bajo un modelo conocido como nearshore. Nearshore® es un tipo de subcontratación que se caracteriza por trasladar parte o la totalidad de las operaciones y/o tareas a un país vecino/fronterizo con todo lo que esto significa, como por ejemplo: distancia geográfica mínima entre ambos puntos, misma zona horaria, menor costo de producción, incluso mínimas diferencias culturales y de negocios. Este artículo intenta descifrar las razones o motivos de este creciente modelo en países emergentes y los retos que representa.

Antecedentes

Desde el momento en que el uso de economías de escala y la disminución de costos se convirtieron en elementos clave para sobrevivir en un mercado competitivo, muchas empresas norteamericanas comenzaron a concentrase exclusivamente en el “know how” del negocio y subcontrataron con proveedores externos aquellas tareas que no aportaban valor directamente al consumidor. Así fue como comenzaron a dejar en manos de expertos el manejo de la nómina, la administración del call center, o incluso el área de sistemas en su totalidad. Con este movimiento buscaron concentrarse exclusivamente en lo que saben hacer: vender pizzas o fabricar automóviles. India aprovecho este escenario para “levantar la mano” y mostrarse al mundo como una opción seria, respaldada por una población donde al menos 200 millones de habitantes hablan el idioma ingles (21% de la población total de aquel país), y donde las empresas de todo el mundo podían encontrar a un equipo considerable de ingenieros y expertos en software de alto nivel, a un costo difícil de resistir. Si consideramos que el salario promedio de un desarrollador de software en Estados Unidos es de 70,000 dólares anuales aproximadamente, mientras que el mismo trabajo en la India es tasado en 8,000 dólares anuales, la diferencia en los costos fue un elemento determinante para decidir mandar en 10

modelo offshore diversas tareas o incluso departamentos enteros hacia empresas en la India. En la actualidad es muy común que una empresa de servicios en Estados Unidos ofrezca un número 1-800 para atender a sus clientes y que la llamada en realidad sea atendida por algún joven en la India, Singapur o Filipinas. Este es tan solo un ejemplo de las relaciones de negocio que hoy podemos ver a nuestro alrededor. Pero la distancia es un factor que juega en contra de la India, sin contar la diferencia horaria de aproximadamente 12 horas. Estos factores han provocado que algunas empresas norteamericanas se abstengan de subcontratar operaciones en este país, al menos parcialmente. Y es que aun sin contar el “fenómeno del nacionalismo americano”, resulta difícil imaginar que las aplicaciones críticas serán soportadas por un agente externo ubicado a más de 24 horas de vuelo (y eso si el volcán de Islandia no tiene actividad). Esta es la principal razón por la que empresas como TCS, Infosys, Patni, Wipro, iGate o Mindtree, hayan decidido buscar una ubicación cercana a Estados Unidos para atender a sus clientes de forma más directa. Pero ¿por qué México? Por sentido común pensaríamos que solo tiene que ver con ser el país frontera con Estados Unidos y todo lo que ello implica: misma zona horaria o la posibilidad de viajar por asuntos de negocio y regresar en un mismo día sin ningún problema. Pero sin duda existen más elementos que influyeron en la decisión de instalarse en nuestro país. De acuerdo con Gartner [1], hay al menos 9 factores claves que han influido en esta decisión: • Idioma • Apoyo del gobierno • Talento competente • Infraestructura • Sistema educativo • Costo de operación • Ambiente económico y político • Compatibilidad cultural • Madurez global y legal

››México representa un ahorro de casi 40% en el área de TI en comparación con Estados Unidos. Por otra parte, según algunos análisis de competitividad en países emergentes [2], México representa un ahorro de casi 40% en el área de TI en comparación con Estados Unidos, mientras que Canadá solo representa un 9.8%. Estos datos son contundentes en mostrar a México como una opción competitiva en cuanto a los costos directos e indirectos de operación. Pero no todo es un tema de salarios y costos, México en Latinoamérica es el principal país con talento competente en TI, lo cual es un factor de peso que inclina la balanza hacia nuestro país en comparación con países como Costa Rica, Colombia o Argentina.

Retos en el presente y el futuro

Siempre es tentador tratar de hacer comparaciones entre México y la India, incluso llegar a plantear que vamos en el mismo camino, pero es un intento que puede desviarnos de lo verdaderamente importante. Esto lo entendí después de platicar al respecto con el director de outsourcing para norteamérica en Tata Consulting Services (TCS), quien me explicó las enormes diferencias entre ambos países y fue enfático: “México nunca será como la India”. Partiendo de una expectativa aterrizada en nuestra realidad, debemos esforzarnos por ser un destino de inversión atractiva no solo para la India sino para Estados Unidos directamente, Europa, y el resto de los países de Asia Pacífico. Podemos aspirar a ser una opción a la hora de invertir en un centro de desarrollo de tecnología en todos sus ámbitos, pero para llegar a ese punto y competir codo a codo con otros destinos como Singapur, Filipinas o Chile, debemos acudir a la cita con los retos del hoy. 11

Los grandes retos son visibles, y necesitamos trabajar juntos iniciativa privada, gobierno y la academia, en eliminar del horizonte aquellos factores que nos restan competitividad año tras año. Estos son algunos de los que yo considero de mayor importancia: • Adopción del idioma ingles como segunda lengua obligatoria en las escuelas públicas y privadas. • Mayor apoyo del gobierno en todos sus niveles a programas de investigación, creación de nuevas empresas tecnológicas o landing de empresas extranjeras de TI. • Desarrollo de infraestructura tecnológica que alcance a más mexicanos desde la ciudad hasta las comunidades rurales. • Un mejor sistema educativo, donde la “meritocracia” sea el mecanismo que active las posibilidades e incremente la creatividad de nuestras generaciones. • Tasas de impuestos atractivas para invertir en México. • Aprobación de las reformas estructurales que el país necesita. • Erradicar los altos índices de violencia en las principales ciudades del país. • Erradicar la corrupción como un modus vivendi. Finalmente, para los profesionales del área de TI, la llegada de estas empresas ha representado enormes posibilidades de .BIO crecimiento en todo sentido. Oscar Ramírez Vital es egresado de UPIICSA-IPN. Actualmente labora Hoy día quienes trabajan para para Patni Computer Systems como Senior Software Engineer en la alguna de estas compañías son ciudad de Querétaro. Oscar tiene llamados a trabajar en ambienmás de 5 años de experiencia como desarrollador en ambientes J2EE. tes multiculturales con clientes oscar.ramirez@patni.com globales, en ambientes altamente colaborativos. Sin duda es un ecosistema más demandante Referencias: [1] Donald Feinberg, Latin America pero al mismo tiempo ofrece a Trends Scenario. Gartner Enterprise los participantes la adopción de Integration Summit. [2] Competitive Alternatives. KPMG’s habilidades técnicas y de negoGuide to International Business Location, edición 2010. cio que quizá el mercado local no pueda ofrecer.

www.sg.com.mx |

Al reflexionar en la lista anterior, y comparar el salario promedio anual de un desarrollador de software en Canadá (37,500 dólares) contra la misma posición en México (20,500 dólares) podemos entender porqué las empresas de la India no eligieron al país de la hoja de maple como plataforma para iniciar sus operaciones nearshore.

Software Guru

.INDUSTRIA

.EMPRENDIENDO

››El mayor

problema que puede tener un startup es crear algo que nadie quiera.

Emprendedores e Innovación Qué, Cómo y Por qué ››Por Hugo Stevens 12

.EMPRENDIENDO

A. ¿Qué hace un emprendedor? 1. Un emprendedor crea algo nuevo.

Peter Drucker comenta que la definición original de emprendedor (creada hace 200 años) se refiere a alguien que cambia un recurso de un área a otra de mayor productividad, alguien que crea más con lo mismo. De la misma manera, un startup no es sólo una compañía de reciente creación; es una compañía que crea algo nuevo. Para crear algo nuevo, un emprendedor busca aprovechar el cambio para crear un producto o servicio diferente. Un emprendedor necesita estar identificando cambios y los síntomas que indican que hay una oportunidad de crear una innovación exitosa. Dicho de otra manera, uno puede decidir actuar de manera emprendedora. Esto significa que ser emprendedor es realmente un comportamiento, no una característica de personalidad, y que cualquiera que esté dispuesto a dedicar el esfuerzo requerido puede aprender a ser un emprendedor.

B. Cómo emprender (o cómo crear un startup)

¿Cómo crear algo nuevo? La manera más eficiente de lograrlo es a través de un startup. Según Paul Graham, hay tres ingredientes indispensables para crear un startup exitoso: tener ideas de algo que los clientes deseen, contar con la gente adecuada, gastar el menor dinero posible.

1. Ideas. El mayor problema que puede tener un startup es

crear algo que nadie quiera. Crear algo que alguien quiera significa hacer algo de manera diferente de la manera en como los demás lo hacen. Algunos puntos de partida para generar ideas son: algo que la gente usa pero que no funciona muy bien; tomar un lujo y convertirlo en algo común; hacer algo más fácil/más fácil de usar; pensar en lo que debería hacer alguna compañía grande y hacerlo uno mismo; construir algo que uno usaría pero que no existe. Sin embargo, la mejor manera de saber lo que los clientes quieren es observándolos y estando atento a nuevas oportunidades.

.BIO Hugo Stevens es Ingeniero en Electrónica y Comunicaciones por el Tec de Monterrey. Tiene una maestría en Desarrollo de Nuevas Empresas por la Universidad de Stanford y un MBA por la Universidad de Pforzheim en Alemania. Cuenta con experiencia en múltiples industrias, países y proyectos de implementación de tecnología. Es fundador de Startup University y AspireLabs (aspirelabs.net), un fondo para startups de tecnología en México. @hugostevens

Referencias: [1] P. Drucker, Innovation and Entrepreneurship. Collins, 1993. [2] P. Graham, “How to start a startup”. http://bit.ly/sg28r3 [3] P. Graham, “Six principles for making new things”. http://bit.ly/sg28r4 [4] J. Mullins & R. Komisar, Getting to Plan B. Harvard Business Press, 2009.

www.sg.com.mx |

No hay tal cosa como un recurso hasta que alguien encuentra un uso para algo y al hacerlo crea algo con valor económico. La innovación es el proceso que da a un recurso la capacidad de crear riqueza. Por ejemplo, antes de que tuviera un uso, el petróleo crudo que salía del suelo no era un recurso; era un problema que hacía que la tierra fuera infértil. Los bacteriólogos trataban de evitar el hongo de la penicilina hasta que Alexander Fleming se dio cuenta de que podía matar bacterias y entonces se volvió un recurso valioso. De la misma manera, combinar recursos existentes de manera que sea más valiosa que combinaciones existentes de los mismos recursos también es innovación. Es por esto que la innovación puede verse tanto como la creación de un nuevo recurso que no existía antes (crear una nueva fuente de oferta) o generar algo más valioso con los mismos recursos (crear una nueva fuente de demanda). Cuál sea la más adecuada depende del objetivo que se quiera lograr. Por ejemplo, MySQL produce el mismo producto con los mismos usos para los mismos clientes que otras bases de datos relacionales pero a un costo mucho menor. Esta es una nueva fuente de oferta. Por otro lado, el iPhone creó un nuevo producto con nuevos usos para nuevos clientes en base a recursos existentes (creando una nueva fuente de demanda).

Software Guru

2. El emprendedor busca crear nuevas fuentes de oferta o de demanda

.EMPRENDIENDO

››La razón por la que se necesitan varias iteraciones es porque hasta los mejores planes normalmente están equivocados.

2. Gente. El tipo adecuado de gente para un startup es aquella

que no sólo quiere hacer bien las cosas, sino que va más allá de lo que se requiere para ser “profesional”; su comportamiento casi raya en lo obsesivo. Es gente inteligente (en el sentido de ser suficientemente inteligente para saber cuando uno está equivocado), que puede hacer las cosas, y con quien se pueda convivir. En la práctica esto significa un grupo de amigos, ya que tienen intereses similares y ya se conocen mucho mejor de lo que cualquier entrevista podría decir sobre alguien. Por último, debe haber roles claramente definidos – alguien que se enfoque en entender las necesidades de los clientes mientras que alguien más se enfoca en construir el producto (Steve Jobs & Steve Wozniak, Bill Gates & Paul Allen).

3. Minimizar gastos. Para gastar lo menos posible, lo

mejor es crecer lentamente al principio mientras todavía se puedan hacer cambios y hasta que el producto sea el correcto. Esto significa enfocar los recursos disponibles en mejorar el producto y tener un crecimiento sólido, y buscar usuarios que puedan contribuir con ideas para mejorar el producto. También significa no hacer contrataciones en un inicio, ya que los salarios son un gasto recurrente que pronto puede volverse mucho para un startup con ingresos limitados, además de que más empleados necesitan espacio adicional, más reuniones y coordinación. La única razón para contratar a alguien es cuando algo que es absolutamente necesario ya no puede lograrse con el equipo original. En resumen, trabajar en ‘modo startup’ es como ser estudiante, trabajando donde sea que es más fácil (normalmente en un departamento, no en una oficina – hay una razón por la cual HP, Apple y hasta Google trabajaron en un garage) con un amigo en el que puedas confiar. Además de estos ingredientes, es importante entender el proceso para crear un producto que la gente quiera. Dicho proceso consiste en: crear una versión 1.0, mostrarlo a los usuarios para ver cómo funciona en el mundo real y entonces iterar rápidamente para mejorarlo basado en sus reacciones (como ejemplo, en la página de Wikipedia de Facebook se puede ver la versión 1.0 del sitio y cómo fue evolucionando; igual con Windows 1.0). La razón por la cual se necesitan varias iteraciones es porque hasta los mejores planes normalmente están equivocados, y la única manera de saber cómo mejorarlos es implementándolos. En las palabras del general McArthur dijo, “Ningún plan sobrevive el contacto con el enemigo.” 14

Randy Komisar y John Mullins mencionan que es muy poco probable que un nuevo producto o un nuevo modelo de negocio funcione correctamente desde la primera vez (Paypal empezó como software para encriptar información en PDAs, y Google no tuvo un modelo de negocios por varios años), por lo que un startup debe continuamente estar probando sus hipótesis y haciendo cambios cuando resultan estar equivocadas. Esto requiere un proceso diseñado para aprender y seguir descubriendo –en lugar de simplemente enfocarse en la ejecución– para reconocer la dura realidad y eventualmente llegar al plan que funcione.

C. ¿Por qué emprender?

Crear un startup es difícil, ¿así que por qué hacerlo? Un emprendedor ve al cambio como algo saludable. No siempre crea los cambios él mismo, pero siempre los busca y trata de encontrar maneras de aprovechar las oportunidades que traen. Después de todo, ésta es la definición de ser emprendedor. El emprendedor ve su rol en la sociedad como alguien que hace algo diferente –a diferencia de hacer lo mismo pero un poco mejor. Esto lo logra a través de alterar y desorganizar. En las palabras de Joseph Schumpeter, a través de la “destrucción creativa”, remplazando lo que ya existe con algo nuevo. Esta es la manera en la que las cosas que hoy damos por hechas fueron creadas: Google remplazó horas de estar en la biblioteca, el procesador de texto remplazó a la máquina de escribir, el teléfono remplazó al telégrafo (y Skype está remplazando el teléfono), las microfinanzas ofrecieron crédito a millones de personas que no podían tenerlo antes, y los teléfonos celulares ahora permiten que cualquier persona pueda estar comunicada con el resto del mundo. ¿Qué vas a crear tú que reemplazará lo que tenemos hoy?

Resumen Qué: Crear algo nuevo. Cómo: Crear la versión 1.0 e iterar. Por qué: Para remplazar lo que existe con algo mejor.

.productos Lo Que Viene

Windows Azure

Llega a América Latina

Durante el mes de abril, Microsoft hizo disponible en México y otros países de Latinoamérica su plataforma de cómputo en la nube Windows Azure así como el servicio de base de datos en la nube SQL Azure. Dichos servicios habían estado accesibles de forma previa desde el año pasado, pero ahora ya están disponibles de forma comercial y oficialmente soportada. Uno de los principales diferenciadores a los que apuesta Microsoft en la nube es la amplitud de su oferta, ya que proveen soluciones en los 3 segmentos de la nube (software como servicio, infraestructura como servicio, y plataforma como servicio). Un aspecto muy grato de Azure es que no te restringe a tener que utilizar tecnologías de Microsoft, sino que permite desarrollar aplicaciones en lenguajes como PHP o Java. El ambiente de desarrollo Visual Studio 2010 también fue liberado durante abril, e incorpora capacidades para el fácil desarrollo e instalación de aplicaciones en la nube con la plataforma Windows Azure. Los países de América Latina donde Windows Azure y SQL Azure ya están disponibles comercialmente son: Brasil, Chile, Colombia, Costa Rica, México, Perú, Puerto Rico y Trinidad y Tobago. En los próximos meses se ampliará la disponibilidad al resto de los países de la región. Más información en http://windowsazure.com

Durante la conferencia Google I/O se dió a conocer la versión 2.2 de Android, con nombre clave Froyo. Ésta es la séptima versión de la plataforma abierta para dispositivos móviles. Las mejoras en Froyo se concentran en cinco áreas: Velocidad. El nuevo compilador JIT Dalvik provee mejoras de 2 a 5 veces en velocidad comparado con Android 2.1. Capacidades empresariales. Mejoras en el soporte a Exchange y calendarios, así como capacidades para gestionar la seguridad del dispositivo. Mejoras en el navegador. Android 2.2 incorpora el motor de JavaScript V8, el cual provee mejoras significativas en velocidad. Nuevos APIs y servicios. Nuevos APIs para multimedia, gráficos y respaldo de datos, entre otros. Las aplicaciones pueden enviar alertas y mensajes directo de la nube hacia el aparato. Mejoras al Android Market. Destaca el nuevo servicio para reporte de bugs que permite que los desarrolladores de aplicaciones puedan acceder los reportes de falla de los usuarios.

Android 2.2

Ya se asoma Froyo

Junto con Froyo también se dieron a conocer nuevas versiones de las herramientas para el SDK, el plugin para Eclipse, y Android NDK, que permite desarrollar componentes que usen código nativo en lugar de la máquina virtual, para obtener mejor desempeño en puntos clave. Más información en http://android.com

VMForce

VMWare y salesforce unen fuerzas en la nube

VMware y salesforce.com dieron a conocer una alianza para ofrecer en conjunto una nueva plataforma para aplicaciones Java en la nube denominada VMforce. VMforce busca brindar a los desarrolladores de java algo que actualmente carecen: un camino a la nube para aplicaciones empresariales de misión crítica. Entre las capacidades de VMforce destacan: Spring Framework. VMforce utilizará el Spring Framework y la suite de herramientas de SpringSource. SpringSource tc server. tc Server es un servidor de aplicaciones ligero basado en Apache Tomcat y optimizado para ambientes en la nube. Base de datos Force.com. Una base de datos relacional de alta disponibilidad y escalabilidad. Servicios de la plataforma Force.com. Dado que VMforce estará sobre la plataforma Force.com, los desarrolladores tendrán acceso a servicios de negocio preconstruidos que se pueden integrar a sus aplicaciones. Entre ellos destacan servicios para búsqueda, identidad, reporteo, workflow e instalación en dispositivos móviles. Force.com Chatter. Chatter provee servicios preconstruidos para incorporar funcionalidad de redes sociales a las aplicaciones. Más información en http://vmforce.com

.productos Herramientas

Web Semántica

complejidad para un internet más sencillo

››Por Javier Solís González y Carlos O. Ramírez

oy en día, Internet, la red mundial de información, es plana. Dentro de algún tiempo, no lo será más. Esta es la promesa de la web 3.0, internet con significado o simplemente web semántica. A continuación, vamos a explicar en qué consiste esta tendencia, los retos a los que se enfrenta y su trascendencia para el futuro de Internet.

Pasado y presente de Internet

Rastrear todas las raíces de Internet nos llevaría por distintos caminos y a diferentes épocas del siglo pasado; sin embargo no hay duda de que la invención del lenguaje HTML y del protocolo HTTP fueron determinantes en su vertiginoso desarrollo. Detrás de estos y otros avances tecnológicos ha estado quien es mundialmente reconocido como el “padre de Internet”, el científico inglés Tim Berners-Lee, quien ideó los principios de lo que sería la World Wide Web (WWW), apenas iniciada la década de 1990. De entonces a la fecha, Internet ha dado lugar a una proliferación inaudita de documentos disponibles a través de la red. El legado es indudable: los seres humanos tenemos acceso a millones y millones de recursos de información, así como una comunicación prácticamente con todo el mundo, en cualquier momento y a un bajo costo.

1… 2… 3… Web

Quienes han estudiado a detalle el proceso evolutivo de Internet separan las etapas de su desarrollo en tres periodos no necesariamente fijos en el tiempo sino caracterizados por el potencial de que son capaces cada uno de ellos. La llamada Web 1.0 o primera versión de internet se refiere a una red “informativa”, es decir aquella que permite a los internautas la lectura de documentos electrónicos. Al menos hasta su primera década de vida, así era Internet: un medio unidireccional de comunicación virtual, enfocado en la digitalización de textos para su lectura desde navegadores en computadoras personales. A medida que las necesidades de los usuarios aumentaron y los avances tecnológicos lo permitieron, Internet se transformó en una red bidireccional o “colaborativa”, que también es conocida como web social o Web 2.0. En ella, la verticalidad en los flujos de información le está cediendo el paso a retroalimentaciones directas de los lectores con respecto a los contenidos de los sitios. Si la red anterior era una red para leer, ésta otra es para leer y escribir, porque en ella los usuarios ya no juegan un rol pasivo como simples receptores de información, sino uno activo que los convierte también en autores y agregadores de información. La filosofía 18

detrás de este paradigma es que la inteligencia colectiva es mucho más robusta y eficiente que el conocimiento individual. La web que seguirá, en cambio, se propone un salto cualitativamente distinto. La web 3.0 pretende ser “inteligente” y saber qué hacer con tanta información. El Internet, que primero fue informativo y luego colaborativo, se prepara ahora para ser semántico y entender el significado de sitios, páginas, documentos y todo recurso de información disponible en la red.

Cantidad que no es calidad

Internet crece día con día pero aún no es capaz de tomar sus propias decisiones. Es todavía un menor de edad que no sabe qué sabe. Además es obeso, desorganizado y, si nos ponemos exigentes, bastante tonto. Es cierto que nos ha dado muchas satisfacciones y ninguna otra tecnología se le compara en alcance y potencial de transformación social, pero ya va siendo hora de que aprenda a hacer algo más. Lo que al principio era una bondad de Internet, empieza a revertirse, y si no hacemos algo nos caerá encima cual torre de Babel. Nos referimos a la facilidad para publicar información en la web y a su contraparte para buscarla y encontrarla rápida y eficientemente. Ya se percibe una sobrecarga de información electrónica, prevalece una heterogeneidad enorme de las fuentes de información y, en consecuencia, hay brechas de interoperabilidad casi infranqueables. No hay capacidad humana que salga bien librada de esta problemáti-

Figura 1. Ejemplo de un modelo RDF.

.productos

Herramientas

››Internet crece

“data web”, que es una fase previa durante la cual se pretende homologar los formatos de publicación en internet y, por lo tanto, permitir un nuevo nivel de integración de datos y aplicaciones interoperables.

La web con significado

Componentes de la web semántica

El principal impulsor y conceptualizador de la web semántica es el mismo “padre de internet”, Tim Berners-Lee, de quien ya hablamos líneas arriba. Él define a la web semántica como: “una red extendida, dotada de mayor significado, en la que cualquier usuario en Internet podrá encontrar respuestas a sus preguntas de forma más rápida y sencilla, gracias a una información mejor definida. Al dotar a la web de más significado y, por lo tanto, de más semántica, se pueden obtener soluciones a problemas habituales en la búsqueda de información”.[1] La propuesta consiste en facultar a la próxima generación de sistemas de información para procesar el contenido de las páginas web, así como razonar, deducir e inferir sobre ellas en forma automática, ya sea para resolver problemas o contestar preguntas cotidianas de los seres humanos. Para que esto sea posible, resulta imprescindible construir una web con contenido estructurado, que incorpore metadatos semánticos para su descripción, así como una ontología que establezca su significado y determine sus relaciones involucradas. Vale la pena comentar que un primer paso en la vía de la web semántica es precisamente el desarrollo de lo que se ha dado en llamar la

La web semántica se apoya en tecnologías y estándares que le permiten avanzar en el objetivo de integrar una infraestructura global que permita compartir y reutilizar datos y documentos entre diferentes aplicaciones y usuarios. Dichos componentes son los siguientes: • RDF (Resource Description Framework). Es un modelo de datos que representa recursos y las relaciones que se puedan establecer entre ellos, proporcionando información descriptiva simple sobre cada recurso. El elemento de construcción básica en RDF es el “triple” o sentencia, que consiste en dos nodos (sujeto y objeto) unidos por un arco (predicado), donde los nodos representan recursos y los arcos propiedades. • SPARQL (Protocol and RDF Query Language). Es un lenguaje de consulta sobre RDF que permite hacer búsquedas sobre los recursos de la web semántica utilizando distintas fuentes de datos. • OWL (Ontology Web Language). Es un mecanismo para desarrollar temas o vocabularios específicos en los cuales se asocian los recursos. Lo que hace OWL es proporcionar un lenguaje para definir ontologías estructuradas que pueden ser utilizadas a través de diferentes sistemas. Las ontologías incluyen definiciones de conceptos básicos en un campo determinado y la relación entre ellos. .BIO Javier Solís González es Gerente de Nuevos Productos y Servicios en Infotec. Es ingeniero en Sistemas Computacionales por el Unitec y cuenta con un posgrado en Redes Computacionales. Desde 2002, investiga y desarrolla con tecnologías semánticas, resultando en productos como SemanticWebBuilder. Carlos O. Ramírez es Consultor en Gobierno Electrónico y Sociedad de la Información en Infotec. Estudió la Licenciatura en Ciencia Política y Administración Pública en la UNAM y ha sido editor y reportero en diferentes medios de comunicación impresos y electrónicos.

Figura 2. Web de documentos vs web de conceptos.

Referencias: [1] “Guía breve de Web Semántica”, W3C oficina española. http://bit.ly/ sg28r5 [2] “Semantic Web Builder”, Infotec. http://semanticwebbuilder.org.mx

www.sg.com.mx |

ca y es por ello que, desde la disciplina de la inteligencia artificial, ha salido en nuestra ayuda este novedoso concepto de web semántica, que a continuación exploramos con mayor detalle.

Software Guru

día con día pero aún no es capaz de tomar sus propias decisiones. Es todavía un menor de edad que no sabe qué sabe.

.productos Herramientas

››Un primer paso en la vía de la

web semántica es precisamente el desarrollo de lo que se ha dado en llamar la “data web”.

Perspectiva futura

El modelo de web semántica está pensado para transitar de la red actual a la de significado. Mientras que actualmente internet es una red plana, que relaciona indiscriminadamente a sitios y páginas de internet; con el nuevo modelo podemos avanzar hacia una web estructurada, donde cada página estará organizada coherentemente en función de relaciones u ontologías y contará con datos sobre los datos e información sobre la información almacenada. En pocas palabras, pasaremos de una web de documentos y palabras a una de conceptos y sus relaciones. Teóricamente es posible y hacerla realidad requiere cambiar paulatinamente la fisonomía de la red, a partir del modelo semántico propuesto. Hoy en día, en todo el mundo hay iniciativas desde los sectores público, privado y académico para avanzar en ese sentido. Por un lado, hace falta construir y estandarizar diferentes ontologías que den coherencia lógica a los contenidos publicados y por publicar en Internet. Por otro lado, las páginas planas tendrán que sustituirse por otras apegadas al estándar RDF y que incorporen metadatos que, a manera de fichas temáticas, clasifiquen y organicen los contenidos de Internet Otro esfuerzo adicional es el desarrollo de un conjunto de aplicaciones de nueva generación, aplicaciones semánticas, que exploten en todo su potencial la nueva arquitectura y funcionalidad de la plataforma semántica; es decir, los sistemas que se conectarán con otros sistemas y los entenderán gracias a ese marco común de referencia que resulta de la combinación de RDF, SPARQL y OWL.

Contribución mexicana a la web semántica

El tema de la web semántica no es nuevo en México, aunque ciertamente su difusión se concentra casi exclusivamente en universidades y centros de investigación relacionados con tecnologías de información. Una de estas instituciones que investiga y trabaja en el desarrollo de aplicaciones semánticas es Infotec, uno de los principales centros públicos de innovación y desarrollo tecnológico en el país. Infotec forma parte de la red de centros públicos del Consejo Nacional de Ciencia y Tecnología (Conacyt) y es un organismo que desde hace 10 años experimenta en el ámbito de la web semántica con resultados palpables. Su principal aportación en la materia es la plataforma de desarrollo de portales y contenidos semánticos, denominada Web20

Builder, cuya cuarta y más reciente versión (SemanticWebBuilder) permite la construcción de portales de internet con incorporación de atributos semánticos: metadatos, redes semánticas y, fundamentalmente, especificaciones ontológicas dentro de los sitios. Con esta plataforma tecnológica, Infotec lleva a cabo diferentes proyectos en el sector público que, en diferente medida, exploran las posibilidades semánticas de la web. Tal es el caso del Programa de Gobiernos Locales Digitales, mediante el cual los municipios de México tienen a su disposición una solución que los dota de un portal de gobierno electrónico y un sitio tipo “ciudad digital”, ambos preparados para funcionar con semántica dentro de sus contenidos. Otro proyecto similar tiene que ver con una oferta de solución para micro, pequeñas y medianas empresas del sector turismo. Este proyecto construirá un extenso catálogo de productos, servicios, organizaciones y demás información relacionada con el turismo, para cuyo desarrollo se ha considerado precisamente la elaboración de una ontología apropiada al tema en cuestión.

Conclusiones

La web semántica es un concepto emergente en el ámbito de la evolución de Internet. Sin embargo, no se trata de un tema pasajero, sino de una tendencia que claramente se hará realidad paulatinamente. Los sitios y páginas de internet, tal como los conocemos en la actualidad, tienen sus días contados. Así como sucedió en la evolución de las especies con la supervivencia del más apto, en algunos años los sitios –y en consecuencia las organizaciones de las que dependen– mejor preparados serán aquellos que puedan transmitirle a otros sistemas los significados que contienen. Por lo que respecta a México, la existencia de iniciativas en la materia es importante, pero aún falta extender y generalizar su uso en toda la sociedad. La preocupación por transitar lo antes posible al futuro semántico debería ser una prioridad de todos: por supuesto la academia y el sector de investigación, pero también de los tres órdenes de gobierno (federal, estatal y municipal), del sector privado (grandes, medianas y pequeñas empresas) y desde luego del sector social (organizaciones civiles e individuos). No avanzaremos hacia una web estructurada si no nos organizamos antes como sociedad para lograrlo.

.productos Un Vistazo

HTML 5 el

››Por Héctor Cuesta

paradigma está cambiando

“¿Sigues teniendo el mismo barco, a pesar de haber reemplazado cada una de sus partes?”

-Paradoja de Teseo

sta es una paradoja que se preguntaban los antiguos griegos, que actualmente podríamos aplicar a las tecnologías que evolucionan hasta el punto de solo conservar su nombre original. Tal es el caso del HTML, una de las tecnologías fundamentales de Internet, creada por Tim Berners Lee en 1991. A través del paso de los años, la limitada funcionalidad del HTML ha tenido que ser ampliada con diversas tecnologías como javascript, flash, applets, css, etcétera. En general, el propósito de estas tecnologías ha girado alrededor de habilitar a los usuarios para que no solo seamos espectadores de la red, sino también generadores de contenido, además de brindarnos una experiencia con mayor interactividad. Con la explosión de Internet y con cada vez más gente generando contenido, la tendencia se inclinó por aplicaciones tipo “Web 2.0” donde los usuarios pueden desarrollar contenidos de forma colaborativa, además de incluir elementos como audio y videos. Para lograr este tipo de aplicaciones se ha tenido que estirar al máximo las capacidades de HTML y el protocolo HTTP. Ejemplo claro de esto es la tecnología Ajax, la cual surgió de una interface denominada XMLHttpRequest que Microsoft integró en IE5 para soportar funcionalidad de su cliente de correo web. HTML 5 promete un nuevo nivel de interactividad. Si bien conserva las bases de la versión actual, también incorpora una gran cantidad de mejoras que a continuación describo, y que se vislumbran como una gran competencia para tecnologías que han venido a llenar los huecos de HTML a lo largo de los años. .BIO

Héctor Cuesta Arvizu es Lic. en Informática y en los ultimos 4 años ha estado a cargo del area de sistemas de Kimpack Mfg., donde desarrollo proyectos JEE aplicados a procesos de manufactura. También se desempeña como instructor para Tecnologico Nyce en el area de base de datos e ingenieria de software. @hmcuesta

Referencias: [1] “HTML 5: A Vocabulary and associated APIs for HTML and XHTML”, W3C. http://bit.ly/sg28r1 [2] “HTML 5 Tag Reference”, w3schools. com. http://bit.ly/sg28r2

Rendereo de imágenes

Uno de los elementos más prometedores es la capacidad de crear y renderizar imágenes dinámicas sin necesidad de plugins externos. Esto se logra por medio del tag <canvas>, y es posible manipularlo con javascript. El listado 1 muestra un ejemplo de cómo se dibuja con javascript un rectángulo en HTML5 usando el tag canvas. 22

<canvas id=”miGrafico”></canvas> <script type=”text/javascript”> var grafico=document.getElementById(‘miGrafico’); var contexto=grafico.getContext(‘2d’); contexto.fillRect(0,10,50,100); contexto.fillStyle=’#FFEE00’; </script> Listado 1. Dibujando un rectángulo en el tag <canvas>

Nuevos tipos de campos en formularios

Hasta antes de HTML 5 hemos tenido que recurrir a funciones de javascript para simular el comportamiento en formularios de campos como calendarios, correos electrónicos y urls. Sin embargo, gracias a los nuevos tipos de <input> en HTML 5 esto ya no será necesario. Algunos de estos nuevos tipos son: color, date, month, week, time, email, image, number, range, search, tel, url.

Manejo de audio y video

Y por último la joya de la corona, el manejo de audio y video con sus respectivos tags <audio> y <video>. En HTML 5, incluir un video en una página es tan sencillo como: <video src=”video.ogg” controls=”controls”></video> Esto abre la puerta a que audios y videos sean soportados nativamente en el navegador de dispositivos móviles como blackberry y iphone, que no soportan Flash.

Conclusión

Además de las capacidades que ya revisamos, HTML 5 provee otras mejoras como “drag and drop” nativo, tags para la descripción de artículos (<article>), generación de llaves criptográficas (<keygen>). Diversas empresas entre las que destaca Google están respaldando fuertemente HTML 5, con la ilusión de que algún día no se necesite sistema operativo o aplicaciones de escritorio, sino que todo lo que necesite el usuario sea un navegador. Entonces nos haremos la misma pregunta: ¿si cambiamos todas las partes sigue siendo el mismo barco?

La nube empresarial ya está disponible

análisis de implicaciones

Aspectos significativos

Estos son algunos de los aspectos más significativos de la nube empresarial: • Hardware. El cambio del mainframe a cliente/servidor fue una mejora 10X en costos de hardware. Una magnitud similar se obtendrá del uso de centros de datos compartidos. Para que esto suceda, la operación de TI tendrá que evolucionar. • Cargas de trabajo. En términos económicos, las ofertas de cómputo en la nube son altamente atractivas para grandes cargas de trabajo pero todavía son demasiado caras para cargas pequeñas, como el web hosting básico. En un futuro cercano también se podrá ofrecer costos atractivos en la nube para cargas pequeñas gracias a la utilización de máquinas virtuales ligeras. • Base de datos en la nube. La “plataforma como servicio” se refiere a un sistema operativo que es administrado por un tercero… nunca más instalar actualizaciones los martes o respaldar el sistema. La “base de datos como servicio” no solo resuelve necesidades urgentes de almacenamiento de grandes volúmenes, sino que permite resolver nuevos escenarios. Por ejemplo, es la mejor forma de compartir selectivamente una base de datos entre solo algunos clientes y proveedores. • Ambiente para aplicaciones “no oficiales”. La preocupación principal de los departamentos centrales de TI es mantener los sistemas empresariales, por lo que los desarrollos departamentales no son administrados adecuadamente lo cual resulta en malos niveles de servicio. ¿Por qué no estandarizar que todos los desarrollos departamentales se envíen a una nube dedicada? Esto daría flexibilidad a que cada quien resuelva problemas específicos en un ambiente seguro y administrado. • Actualización de infraestructura. La nube empresarial resuelve el problema de la instalación de actualizaciones de infraestructura. Las actualizaciones del software serán transparentes, y solo se paga por el software que realmente se usa.

Diferenciadores entre ofertas

La batalla por ganar la “nube empresarial” ha dado inicio. Algu23

››¿Por qué no estandarizar que todos los desarrollos departamentales se envíen a una nube dedicada? nos aspectos a considerar al analizar las ofertas existentes son: • Completo. La nube empresarial requiere que un mismo proveedor satisfaga los tres niveles: infraestructura como servicio, plataforma como servicio y software como servicio. De otra forma se contará con aplicaciones desconectadas entre sí y con acuerdos de uso independientes. Imagine una empresa de virtualización 1.0 que adquiere por separado plataforma y software como servicio; además de los retos de integración, tampoco tendrá experiencia en operar servicios masivos en Internet. Aunque la percepción no es contundente, Microsoft es hoy el mejor posicionado en esta dimensión. • Interoperable. La virtualización 1.0 permite ejecutar cualquier sistema operativo y aplicación en la nube, pero las empresas van a requerir integración con sistemas internos existentes, sistemas en centros de datos privados y servicios web públicos. No todos los proveedores de cómputo en la nube soportan esto. Idealmente el modelo aplicativo deberá ser simétrico al interior de la empresa o en el centro de datos público o dedicado. • Confiable. Los servicios de software empresarial van a requerir de: un licenciamiento que combine el software tradicional con el software como servicio; niveles de servicio garantizado que en casos de incumplimiento paguen penalización económica; que los centros de datos sean auditados por un tercero. Curiosamente una de las mayores empresas de “nube para el consumidor” en el mundo no ofrece ninguna de estas características. • A la medida. Las ofertas de nube empresarial deben ser flexibles y a la medida, permitiendo que el cliente decida si quiere utilizar infraestructura compartida o dedicada. • Nativo. Diversas empresas como IBM, Oracle y SAP permiten aprovisionar su software en Amazon, con lo cual obtienen escalabilidad pero difícilmente competirán en costo con soluciones creadas nativamente en una “plataforma como servicio”. La nube empresarial ya está disponible. La pelea por el liderazgo de la “nube empresarial” ha iniciado, y no todas las nubes son iguales. Encuentre la forma de ser un pionero y no un seguidor, la transformación sucederá. Presionemos para que los gobiernos en América Latina desafíen la historia y lleguen pronto a la completa materialización de lo prometido por la nube.

››Por Luis Daniel Soto

Software Guru

nalicemos la evolución de la virtualización y el cómputo en la nube: 1. La virtualización 1.0, mejora el uso del hardware pero depende de un “operador”. 2. La “nube privada” o virtualización 2.0, es conducida por un sistema administrador que le permite a un departamento central de TI resolver necesidades de los diversos departamentos mediante un “pago por uso”. 3. La “nube empresarial” se consolida. El impacto de la nube inició en el consumidor, pero su ruta de adopción será similar a la de otras tecnologías emergentes: adoptada por pioneros, posteriormente por empresas privadas y eventualmente aprovechada por los gobiernos.

www.sg.com.mx |

.COLUMNA

Tendencias en Software

Luis Daniel Soto es Director de Divulgación Tecnológica en América Latina para Microsoft. @luisdans

Servicios Basados en

Ubicación Un vistazo a las posibilidades ››Por Agustín Ramos

Supongamos que te encuentras con tu familia en un fin de semana, acaban de salir de un restaurante y a alguien se le ocurre que podrían ir todos juntos al cine, pero ¿a cuál y a qué película?. Bueno, para decidir hay que saber en primer lugar qué cines se encuentran cerca, las películas ahí exhibidas y los horarios de las mismas; es decir, se requiere la cartelera local. Después de eso vendrá ya el debate y la elección familiar. Pero, ¿qué pasa si no se cuenta con toda esta información concentrada? Lo más probable es que visiten el cine más cercano que algún miembro familiar recomiende, muy probablemente demoren algún tiempo tratando de encontrar estacionamiento, y bien se podrían encontrar con la eventualidad de que las funciones de su interés se encuentran agotadas o mucho más tarde de lo que están dispuestos a esperar. ¿Qué sigue? ¿visitar otro cine? Quizá la familia decida ya no ir al cine.

.BIO Agustín T. Ramos Fonseca se desempeña como ingeniero de software en Certum. Tiene 7 años de experiencia en el desarrollo de aplicaciones corporativas y es miembro de la IEEE y ACM. Sus intereses se centran en servicios internet altamente escalables, plataformas para sistemas transaccionales masivamente distribuidos, servicios móviles y geoposicionales, así como líneas de productos y arqueología de software. @MachinesAreUs

.EN PORTada

La situación descrita es un ejemplo de situaciones donde, por no contar con suficiente información contextualizada dentro de una ubicación geográfica, terminamos tomando decisiones no óptimas. ¿No sería mucho mejor poder consultar en el celular y en todo momento la cartelera de los cines que se encuentran cercanos a mi ubicación? OK, tal vez tú nunca vas al cine en familia y mucho menos de manera improvisada, pero seguramente puedes pensar en una situación similar en la que sí tendrías un enorme beneficio: accesibilidad a información relevante dependiendo de tus intereses y ubicación física. Otro tipo de situación: Asistes a una conferencia y te gustaría saber si antiguos colaboradores, compañeros o miembros de cierto grupo de interés asistieron también, para intercambiar experiencias y establecer nuevos contactos. Hacer broadcasting de la entrada en tu agenda incluyendo una larga lista de personas en el campo FYI tiene varios inconvenientes: a mucha gente le puede resultar un tanto molesto que le lleguen tantos FYI sobre a dónde vas y qué haces, y en primer lugar, estar generando esas listas puede consu-

mir mucho tiempo. Además, es cuando menos una gran inversión de tiempo el agendar citas particulares en momentos específicos de la conferencia. ¿Qué otra alternativa tienes? Seguramente cualquiera de ellas requiere una inversión importante de tiempo. ¿Qué vas a hacer?, ¿resignarte a “ver si los encuentras”? ¿Y si es un evento con miles de personas?. Piensa móvil. Piensa dinámico. Si los asistentes al evento pueden avisar a un sistema dónde están, y mejor aún, si lo pueden hacer de manera automática digamos cada 5 minutos, y tú como miembro de esa comunidad puedes consultar desde tu celular quién está cerca, y más aún, a cuantos metros de ti y en qué dirección se encuentra... las posibilidades son tremendas!. Además, te permitiría establecer primer contacto de una manera mucho más dinámica y efectiva con asistentes que aún no conoces en persona: “ey!, ¿dónde anda Scott Davis? me gustaría intercambiar ideas sobre la presentación que dio hace un par de horas pero de la que tuve que salir corriendo para alcanzar lugar en la de Grady Booch... ah!, junto a la Sala D”.

Todo esto (y aún mucho más) es posible con la combinación de 2 tecnologías, las cuales cada vez tienen mayor adopción en el mercado: conexión de datos en equipos de telefonía celular y GPS. De acuerdo, en realidad ninguna de las anteriores es absolutamente indispensable, pero la combinación de ambas garantiza la mejor experiencia posible. Por un lado, uno bien puede notificar su ubicación manualmente enviando un mensaje de texto a cierto número telefónico designado para eso: “Centro Banamex, Palacio de Iturbide”. Sí, esto supone que tras ese número telefónico se esconde un sistema capaz de decodificar tal mensaje en una posición geográfica (una región, un punto), y proporcionarte contenido adecuado para tu posición e intereses (otro mensaje de texto en el caso más primitivo). Otra manera de determinar tu ubicación de manera automática es a través de triangulaciones entre antenas de la red celular, posiblemente en combinación con antenas WiFi. Combinar los tres métodos (GPS, red celular y WiFi) da resultados asombrosos: llega una llamada a la extensión de tu compañero de a lado pero él no está en su lugar, contestas el teléfono y ¿qué le dices? ¿que le vuelva a marcar o que en unos segundos atiende la llamada? Bueno, si pudieras consultar un mapa

posicional de los miembros de tu organización (donde se encuentra cada uno dentro de tu edificio), ya no habría falla, siempre podrías contestar acertadamente. Ver Figura 1. Me he concentrado en ejemplos de servicios muy simples (¿triviales?) y de uso personal, y no sin razón: la ubicación física y la relevancia de la información son un asunto en última instancia muy personal. Pero estos mismos conceptos tienen un potencial tremendo dentro de las organizaciones y plantean un terreno fértil sobre el cual crear nuevos tipos de servicios y extender los que ya se ofrecen. Es momento de innovación. Al estar en sus primeras etapas, los servicios basados en ubicación plantean algunos inconvenientes a los pioneros y usuarios tempranos. Por ejemplo, ¿debo estar notificando mi ubicación a cada diferente proveedor de contenido o servicios? Sí es asi, prefiero no “gozar” de sus beneficios. Pero estas dificultades se irán resolviendo conforme maduran la tecnología, los proveedores y los usuarios. Piensa en Fire Eagle de Yahoo: un broker de información posicional. Es un servicio gratuito que tiene la finalidad de centralizar el dónde actualizar esta información y desde dónde consultarla. De esta manera desacopla a los proveedores de la

Figura 1. Combinaciones tecnológicas de conectividad y posicionamiento geo-

Figura 2. Fire Eagle: Un broker de información posicional para servicios basados

gráfico, ejemplificado con las plataformas más comunes.

en ubicación.

.EN PORTada

Combinar los métodos GPS, red celular y WiFi,

información posicional y las tecnologías utilizadas para recolectarla de los servicios que la consumen, explotan y se adaptan para ofrecer al usuario una experiencia geoposicional. Así, un usuario elige el mecanismo (manual, GPS, red celular, etc) y la aplicación (web, aplicación en el celular, SMS) que más le convenga para notificar su ubicación, esta almacena en Fire Eagle esta información, y una nube de servicios autorizados debidamente por el usuario consulta la información posicional para personalizar servicios y contenido, cuya entrega a dicho usuario o sus colaboradores depende de la naturaleza del servicio y de la tecnología con la que se cuenta. Ver Figura 2. ¿Qué tipo de servicios ya existen y se conectan con Fire Eagle? Uno muy popular es BrightKite, que traducido de su FAQ: “... conecta gente basado en los lugares que visitan en el mundo real. Con BrightKite puedes ver dónde están tus amigos, que están haciendo, que sucede a tu alrededor y conocer amigos en el mundo real. Funciona de la siguiente manera: cuando estás fuera de casa, informas a BrightKite dónde estás ‘registrándote’ en lugares (a través de werv, o tu teléfono), entonces BrightKite puede informarte quién más está ahí, que está sucediendo, quién está cerca, etc. Además puedes enviar notas y fotos relacionadas con los lugares que visitas

para que otros que se encuentran cerca las vean. En todo momento, el usuario puede ajustar quién y cómo ve su contenido mediante la configuración de su perfil de privacidad.” Ver Figura 3. Por otro lado, la seguridad de tu familia puede ser un tema muy importante para tí. Puedes conectar servicios de rastreo (tracking) a Fire Eagle, independientemente de si le das un GPS o un teléfono más económico a cada miembro de la familia. Navizon, por ejemplo, ofrece el servicio de tracking; además permite crear grupos de usuarios para saber la ubicación de cada uno. Ver Figura 4. Fire Eagle es el primero en su género. No debe sorprender que pronto surjan nuevos servicios que ofrezcan esta funcionalidad por parte de los otros gigantes de internet. Adicionalmente, hoy en día es un tanto problemático seleccionar una aplicación adecuada para actualizar tu ubicación: hay N proveedores de donde escoger, y no todos soportan todas las plataformas, sin mencionar que algunas de las opciones automatizadas suelen drenar la batería de tu celular. A eso tendríamos que agregar la escasez de servicios disponibles en este momento. Pero vamos, lo más probable es que tú, como yo, te dediques a alguna rama de las tecnologías de información. El potencial está ahí. Explótalo.

genera resultados asombrosos.

Figura 4. Despliegue de una ruta en Navizon. Las marcas se generan a partir de las notificaciones que se hacen desde tu celular cada n minutos. Las marcas amarillas se determinaron por GPS, cuando no hay cobertura de GPS se recurre a la triangulación con las anteFigura 3. Una anotación dentro de BrightKite. Otros usuarios pueden verla,

nas de la red celular y se

comentarla, etc. También es posible agregar fotos.

indican con marcas rojas.

Aplicaciones

Geoespaciales Definición y oportunidades

››Por Carlos Fernando Ruiz Chávez

Hoy en día se encuentran a nuestro alcance tecnologías y aplicaciones que han cambiado nuestra forma de vida al integrarse en nuestras actividades diarias en un menor o mayor grado.

.BIO Carlos Fernando Ruiz Chávez es Ingeniero en Computación egresado por la Universidad de Guadalajara. Trabaja actualmente como coordinador del proyecto Sistema de Información Territorial Estatal en Línea en el Instituto de Información Territorial del Estado de Jalisco y como consultor independiente en tecnologías de información. cruizch@gmail.com

.EN PORTada

Existe un mundo,

Tanto Google como Yahoo, con Google Maps y Yahoo Maps respectivamente, han dejado al alcance de todos los internautas la capacidad de visualizar e interactuar con mapas en nuestros navegadores de Internet. El conocer la ubicación de una determinada dirección sobre un mapa y obtener la ruta más corta entre dos puntos son tareas simples que tienen bastante utilidad. Sin embargo, las aplicaciones geoespaciales pueden realizar tareas mucho más complejas. La planificación urbana, el análisis de redes hidrológicas, la detección de recursos naturales, el monitoreo ambiental y la delimitación de áreas de riesgo, son ejemplos de algunas de estas tareas que pueden realizar.

literalmente hablando, de oportunidades para las aplicaciones geoespaciales.

rutas sobre las vías de comunicación existentes y la elaboración de mapas temáticos, entre otros.

Lo que hay a nuestro alcance

Actualmente se encuentran disponibles en Internet aplicaciones de Google, Yahoo y OpenLayers, conocidas como mapplets, las cuales pueden insertarse dentro de aplicaciones en Internet para mostrar nuestra información sobre mapas con el uso de interfaces para programación de aplicaciones en Javascript. Existen manejadores de bases de datos como MySQL, PostgreSQL con la extensión PostGIS y SQLite con la extensión SpatiaLite, las cuales no solo permiten el almacenamiento de datos espaciales, sino que también proporcionan funciones de geoprocesamiento y análisis. En cuanto a los sistemas de información geográfica, se encuentran aplicaciones como JUMP, gvSIG y Quantum GIS, las cuales permiten visualizar información de diferentes fuentes de datos, ofrecen herramientas de edición cartográfica, georreferenciación, análisis, geoprocesamiento y de diseño de impresión de mapas.

¿ Qué son las aplicaciones geoespaciales ?

Cuando hablamos de este tipo de aplicaciones, hacemos referencia a las aplicaciones informáticas que se encargan de la obtención, almacenamiento, procesamiento, representación y análisis de los datos espaciales. Estos datos espaciales son abstracciones de la realidad, como un predio, un río o un poste de luz, las cuales cuentan con una representación geométrica con un sistema de coordenadas terrestre. Dentro de las aplicaciones geoespaciales se encuentran la percepción remota o teledetección, el sistema de posicionamiento global (GPS) y los sistemas de información geográfica (GIS). La percepción remota es un método indirecto por el cual, mediante el uso de sensores incorporados a satélites y otros dispositivos no tripulados, es posible obtener las radiaciones electromagnéticas en la corteza terrestre, las cuales son plasmadas en imágenes digitales. Dentro de los usos que se le dan a la teledetección se encuentran la identificación y distribución de vegetación, el análisis de cambios y usos del suelo, el monitoreo de ecosistemas y el seguimiento de deforestaciones, incendios e inundaciones, entre otros. El sistema de posicionamiento global es una tecnología de localización basada en una red de satélites, la cual permite determinar por el método de triangulación la posición precisa de cualquier objeto sobre la superficie terrestre así como su altitud y su velocidad de desplazamiento. Dentro de los usos que se le dan al sistema de posicionamiento global se encuentran el levantamiento de datos en campo como la ubicación de alcantarillas o casetas telefónicas, la delimitación de polígonos de zonas de desastre y el seguimiento de vehículos de transporte de valores, entre otros. Los denominados sistemas de información geográfica son sistemas que tienen como insumo datos espaciales que son procesados para generar resultados presentados en forma de mapas, gráficas y tablas. Dentro de los usos que se le dan a estos sistemas de información geográfica se encuentran la obtención de cartografía sobre fotogrametría, la elaboración de modelos digitales de terreno, el análisis de

Oportunidades

Existe un mundo, literalmente hablando, de oportunidades para las aplicaciones geoespaciales, tanto en la iniciativa privada como en cualquiera de los tres niveles de gobierno. La primera oportunidad se encuentra en georreferenciar los datos contenidos en los sistemas de información tradicionales, lo que no solo representaría un cambio de tecnologías, sino un cambio trascendental en la concepción de las soluciones que se le ofrecen a los usuarios. Como ejemplo, se ha manejado la versión de que una importante cadena de supermercados en los Estados Unidos llegó a descubrir mediante técnicas de minería de datos, que los clientes que van a comprar pañales los jueves y los sábados también compran cerveza. Si suponemos que esto es cierto, lo que no se puede descubrir con esta información no georreferenciada, es que estos clientes que compran pañales son hombres y mujeres entre los 30 y los 35 años, recién casados, que habitan en fraccionamientos de nivel medio alto. Siguiendo este mismo ejemplo, una embotelladora local puede realizar estudios de mercado con un sistema de información geográfica, localizando sobre un mapa socioeconómico a los distribuidores de sus productos y a los distribuidores de la competencia, para conocer más acerca del perfil de las personas que residen cerca de los sitios de distribución. Sin duda, esta información sería de gran utilidad ya que tanto la embotelladora local como la cadena de supermercados, en vez de basar sus ofertas en simples tendencias de compra, se basarían en los perfiles de sus clientes, ya que el objetivo de las aplicaciones geoespaciales es el ser una herramienta de apoyo para sustentar la toma de decisiones. 29

Mapping APIs Los mapas son útiles si los hacemos todos ››Por Paco Cuevas

Los mapas existen desde que el hombre tuvo la necesidad de recordar una ubicación geográfica y la capacidad de plasmar esta información en algún medio, sin embargo durante muchos años la cartografía actualizada de un país o ciudad estaba restringida a un selecto grupo de profesionales, gobiernos o corporaciones que podían pagar un costo elevado por su creación, actualización y utilización. En los tiempos del web 2.0 los mapas digitales (Google Maps, Yahoo Maps, Bing Maps, etc.) ya formaban parte de los recursos globales en internet y jugaron un papel clave para crear lo que se conoce como mashups o aplicaciones web que extienden su funcionalidad central utilizando aspectos de geolocalización, a través del uso de API´s (Application Programming Interface).

Los jugadores principales de APIs para mapas

Centraremos este artículo en un par Google Maps y Bing Maps, sin embargo cabe mencionar que existen muchos más jugadores o proveedores de plataformas para mapas tanto en modalidades de código abierto, como orientados a nichos específicos dependiendo el uso, pero por la relevancia del número de aplicaciones utilizan.BIO do estas API´s Microsoft y GooPaco Cuevas es ingeniero en sistemas, fundador y director de gle están dictando el camino que empresas de desarrollo web como Extend y Web Studios, también es seguirá en los próximos años este emprendedor de servicios como tipo de tecnología. Las figuras 1 MapsandNumbers.com el cual involucra tecnologías como Windows y 2 muestran un panorama de Azure, Google Maps y iPhone, actualmente colabora como Director los principales APIs provistos por de Desarrollo de Negocios en la Google y Bing. empresa emLink y apoya a Microsoft como Windows Azure Evangelist. @pacocuevas

Como transformar un simple mapa en una aplicación útil (Mashup)

Alrededor del concepto crowdsourcing se comienzan a fincar aplicaciones que hacen uso de la ilimitada y gratuita colaboración de los usuarios de internet para enriquecer ciertas dimensiones de un mapa, crear nuevas capas (layers) con información relevante a un contexto o nicho, anexar metadatos a puntos específicos dentro de un mapa tomando en cuenta que estos datos complementarios se encuentran almacenados en diversas fuentes y a su vez provienen de diversos dispositivos (embeded GPS, teléfonos celulares, cámaras digitales, sensores, etc.), esta interacción y colaboración es la que hace que nuestro mapa tome sentido y nos sea útil, por lo que es importante conocer las herramientas que nos pueden ayudar a desarrollar este tipo de aplicaciones.

.EN PORTada

Decidiendo que API´s utilizar

Existen 3 aspectos clave a considerar inicialmente al elegir una o más de una API para nuestra aplicación, y estos aspectos son: 1. Experiencia de Uso (UX). La mayoría de las aplicaciones que utilizan mapas hoy día son web based, sin embargo debemos tomar en cuenta si alguna característica clave que estamos buscando del API requiere algún plugin como por ejemplo Flash, Air, ó Silverlight, tomar en cuenta estos aspectos será muy importante para determinar la usabilidad y el desempeño de nuestra aplicación. Lo sorprendente de un mapa no es tanto el mapa en si, sino la serie de experiencias de uso con las cuales podemos explorarlo como por ejemplo tener una vista en perspectiva (bird´s eye), realizar zoom in o zoom out con cierta fluidez, tener a la mano herramientas emergentes para colocar puntos de interés, zonas o visualizar información del contexto que estamos explorando, superponer fotografías e incluso visualizar mapas en 3D. También es necesario considerar el tipo de dispositivo desde el cual se realizará la exploración, ya sea una laptop, utilizando un mouse o un dispositivo móvil como iPhone o Windows Phone o un dispositivo multitouch como iPad. 2. Cobertura Geográfica. Los mapas ofrecidos tanto por Google Maps como por Microsoft Bing Maps son actualizados con cierta periodicidad no especificada, más aún no cubren en su totalidad el planeta entero ya sea a nivel países, ciudades o calles, este aspecto puede limitar el nicho de mercado al que necesitamos atender ya que algunas características de cada API solo están disponibles en ciertas latitudes y longitudes. 3. Licenciamiento. Uno de los aspectos más olvidados al considerar el uso de una API son los términos de licenciamiento y los acuerdos de nivel de servicio de cada una; La pregunta clave es ¿Puedo usar el API gratis?, la respuesta rápida es sí, siempre y cuando no la uses mucho y no cobres por su uso, entre muchos más aspectos. Otra pregunta rápida es ¿Cuándo pago el licenciamiento del API obtengo mejores imágenes de los mapas o un servicio más rápido?, la respuesta rápida es no en ambas opciones analizadas, tanto la versión gratuita como la comercial utilizan el mismo servicio, la opción comercial básicamente esta soportada por un acuerdo de nivel de servicio SLA. Finalmente cabe aclarar que la mayoría de las API´s no fueron diseñadas para soportar un modelo de negocio, pero en estas opciones

Figura 1. Panorama de los APIs geospaciales de Google

analizadas las versiones gratuitas Google y Microsoft pueden colocar publicidad en los mapas. Para todo desarrollador de aplicaciones web ya es una necesidad competitiva el contar con habilidades para el consumo de API´s de geolocalización, siendo así el aspecto de lenguaje de programación un factor secundario ya que uno de los fundamentos de un API es el de permitir interoperabilidad entre plataformas, haciendo uso de estándares y protocolos de comunicación como JavaScript Object Notation (JSON) que es un formato basado en un subset de JavaScript y se utiliza en aplicaciones con AJAX, Extended Markup Language (XML) mayormente utilizado cuando se trabaja con Flash o Silverlight, con la limitante de la longitud máxima de una petición a través de HTTP GET, SOAP (Simple Object Access Protocol) se recomienda para peticiones más complejas que requieran ser desarrolladas en lenguajes como C# o Java ya sea para aplicaciones de escritorio o en el servidor y finalmente REST (Representational State Transfer) para arquitecturas desacopladas o sin estado.

Mapas y realidad aumentada

Dentro de las implementaciones más futuristas pero a la vez reales, podemos encontrar aquellas que incorporan elementos de realidad aumentada, es decir agregan videos a través de dispositivos móviles en tiempo real sobreponiéndolo a una capa del mapa o extienden los mapas más allá de un solo plano o dimensión como por ejemplo a la visualización de estrellas, constelaciones o planetas dependiendo la ubicación geográfica del usuario, también a los océanos o incluso dentro de estructuras o edificios en una ciudad; una de las demostraciones mejor logradas de este tipo de implementaciones se puede ver en este link: http://www.ted.com/talks/ lang/eng/blaise_aguera.html Contamos con la capacidad de procesamiento y almacenamiento ilimitado (Cloud Computing), contamos con API´s potentes alrededor de mapas y servicios de geolocalización, así como con dispositivos móviles habilitados con GPS y conectividad GPRS o WiFi y lo más importante es que contamos con un inmenso número de usuarios de internet dispuestos a colaborar con pequeñas tareas alrededor de una red social, grupo de trabajo o grupo de interés, por lo que solo es cuestión de tiempo para decir “este mapa me es muy útil”.

Figura 2. Panorama de los APIs geospaciales de Bing

.Pr谩cticas Programaci贸n

Referencias: [1] M. Fowler, K. Beck, et. al. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999. [2] J. Kerievsky. Refactoring to Patterns. Addison-Wesley, 2004.

.Prácticas

Programación

Disciplínate aplica prácticas de

programación ágil

Nota del Editor: Este texto es una versión traducida y condensada del artículo “Programming Practices” disponible en http://www.versionone.com/Agile101/ Programmer_Practices.asp. Ha sido traducido y reproducido por SG con el permiso de VersionOne, Inc.

n un proyecto ágil, los programadores tienen una misión: entregar periódicamente (cada 2, 3 o 4 semanas dependiendo de la duración de las iteraciones) software que funcione y esté probado. Para lograr esto, los programadores requieren mantenerse ágiles tanto a sí mismos, como al código que generan. Esto requiere mucha disciplina. El código ágil es aquel que solamente implementa los requerimientos actuales, tiene pocos defectos y se basa en un diseño robusto que permite extenderlo fácilmente para incorporar requerimientos adicionales en futuras iteraciones. Un código ágil está factorizado adecuadamente, y bien protegido por pruebas unitarias. Entre los métodos ágiles, Extreme Programming (XP) es posiblemente el que entre en mayor detalle acerca de como los programadores pueden hacer código ágil. Cada vez es más común encontrar equipos ágiles que aunque no apliquen XP en su totalidad, sí apliquen al menos algunas prácticas de XP que tienen que ver con la forma de trabajar de los programadores. Dichas prácticas son: • Desarrollo dirigido por pruebas • Refactorización rigurosa y constante • Integración continua • Diseño simple • Programación en pares • Compartir una base de código entre los programadores • Adherirse a un estándar de programación • Un área de trabajo común

Estudiémoslas en mayor detalle.

Desarrollo dirigido por pruebas

Tener pruebas unitarias para solamente algunas partes de nues-

tro código puede resultar en código de baja calidad. Por otro lado, cubrir el 100% no es muy práctico y resulta en baja productividad. Una cobertura de pruebas unitarias de entre 75% y 85% del código es típicamente considerada como óptima. Una excelente forma de lograr tener estos niveles de cobertura es aplicar el Test-First programming. Esta técnica consiste en que antes de que creemos el código para satisfacer un requerimiento, primero generemos pruebas unitarias automatizadas que validen dicho código. Tal acercamiento puede sentirse extraño en un principio, sin embargo es de gran utilidad. Pensemos en los escaladores de montañas que crean caminos al ir dejando anclas; hacer esto es mucho más tardado que simplemente escalar, pero será de gran utilidad para los próximas veces que se tome este camino. Para implementar esta técnica, típicamente se utiliza algun framework de la familia xUnit (Junit para Java, Nunit para C#, etcétera). Dichos frameworks facilitan la creación, ejecución y organización de pruebas unitarias. Otra ventaja es que la mayoría de los IDEs soportan estos frameworks. El desarrollo dirigido por pruebas (test driven development, TDD) es un caso especial de test-first programming que agrega el elemento del diseño continuo. Con TDD, el diseño del sistema no es restringido por un diseño estático en papel, sino que el diseño es continuamente retroalimentado por el proceso de creación de pruebas y código de producción. Conforme el código se refactoriza para simplificarlo y clarificarlo, es posible encontrar mejores métodos, clases y modelos que los que establece el diseño original. TDD se basa en la premisa de que no puedes determinar cual será el mejor diseño, hasta que estés implementando el código. Conforme te vas dando cuenta de qué funciona, y qué no, estás en el mejor momento para ajustar el diseño, mientras tienes las ideas frescas. Y para protegerte de que pudieras realizar cambios que afecten elementos ya implementados, estás protegido por tu conjunto de pruebas unitarias automatizadas. 33

.Prácticas Programación

Refactorización

que “rompe” un build al hacer check-in es al que le toca arreglarlo, lo cual genera un incentivo natural para que los programadores hagan check-in frecuentemente durante el día.

La refactorización (refactoring) es el proceso de clarificar y simplificar el diseño de un código existente, sin cambiar su comportamiento. Esta actividad se realiza de forma continua. El código que no es continuamente refactorizado, se pudre. Dicha putrefacción se puede notar de distintas formas: demasiadas dependencias entre clases o paquetes, asignación incorrecta de responsabilidades en clases, duplicación de código, tan solo por nombrar algunas. Cada vez que cambiamos un código existente y no intentamos refactorizar, la putrefacción aumenta. Sin embargo, hay que estar conscientes de que la única forma de que sea sano y viable refactorizar de forma continua, es que contemos con una buena base de pruebas unitarias automatizadas. Si no somos capaces de ejecutar dichas pruebas cada que refactorizamos código, corremos el riesgo de estar introduciendo defectos sin darnos cuenta. El libro “Refactoring: Improving the Design of Existing Code” de Martin Fowler es una excelente guía que describe oportunidades de refactorización comunes, y distintas formas de resolverlas. Pero la refactorización no solo ocurre a nivel de código, sino que se puede llevar al nivel de patrones de diseño. En su libro “Refactoring to Patterns”, Joshua Kerievsky explica cómo hacer esto, así como su utilidad.

Diseño simple

Los equipos ágiles ponen gran valor en la extensibilidad de su código. Esto se refiere a qué tan fácil es mantenerlo y extenderlo. Ya discutimos lo importante que es la refactorización continua para tener código extendible. El otro elemento clave para esto es la simplicidad del diseño. La extensibilidad del código es inversamente proporcional a la complejidad del diseño. Parafraseando al poeta Wallace Stevens, un diseño simple significa: “el arte de lo que es suficiente”. Esto se traduce en programar para los requerimientos de hoy, y nada más. Sin embargo, esta no es una inclinación natural de nosotros los programadores. Es común que por querer utilizar las herramientas y tecnologías más novedosas, terminemos complicando nuestro diseño más de lo que deberíamos. Cualquier elemento extra que agregamos, es un lastre que debemos cargar a lo largo del proyecto. In Extreme Programming, se utiliza el término “You aren’t gonna need it” (YAGNI) para detectar esta situación. Las empresas que trabajan de forma ágil tienden a preferir contratar gente con experiencia en el arte de la extensibilidad y el diseño simple, por encima de aquellas con mayor conocimiento de las tecnologías.

››En un contexto ágil, la productividad se

mide en base a características implementadas por iteración.

Programación en pares

La programación en pares es claramente la más controversial de las técnicas de programación ágil. Esta técnica consiste en tener dos programadores trabajando en una sola computadora. Un programador “conduce” operando el teclado, mientras el otro “navega” observerando, aprendiendo, preguntando, y haciendo sugerencias. En teoría, el conductor se enfoca en el código que está haciendo (la sintáxis, semántica y algoritmos), y el navegador se enfoca en mayores niveles de abstracción (la prueba que están tratando de hacer pasar, los próximos pasos, la calidad del diseño en general). La teoría es que la programación en pares resulta en un mejor diseño, menos defectos, y una mayor difusión del conocimiento a través del equipo de trabajo. Los resultados de investigación reportan que al usar programación en pares la productividad puede disminuir en un 15% al corto plazo, pero como el código es mejor, la productividad al largo plazo se incrementa. Todo depende de cómo se mida la productividad, y en qué marco de tiempo. En un contexto ágil, la productividad típicamente se mide en base a características implementadas (y probadas) por iteración. Por otro lado, alguien que mida la productividad en base a líneas de código por semana, seguramente encontrará que se disminuye drásticamente con la programación en pares.

Integración continua

Los métodos tradicionales de desarrollo de software no indican cada cuando se debe integrar todo el código fuente de un proyecto y generar una versión ejecutable. Los programadores pueden trabajar por separado por horas, días o incluso semanas en un código sin darse cuenta de cuantos conflictos y defectos están generando. Como comentamos en un principio, los equipos ágiles requieren producir código ejecutable y robusto en cada iteración, por lo que si dejan la integración del código hasta el final de la iteración, se encuentran con un arduo proceso de resolución de conflictos y depuración de código. Ante esto, los equipos ágiles comúnmente escogen aplicar la integración continua. La integración continua involucra construir un ejecutable (build) del sistema varias veces al día, apoyándose en herramientas de gestión de la configuración (software configuration management). Los equipos ágiles típicamente configuran la integración continua para incluir compilación automática, ejecución de pruebas unitarias e integración de código fuente. Una regla popular de la integración continua establece que los programadores no dejen elementos sin integrar al final del día, es decir que no se pueden dejar builds rotos para el siguiente día. Adicionalmente se puede combinar esta regla con la de que el programador 34

Los beneficios de la programación en pares se incrementan si se considera un plazo suficientemente largo como para incluir la rotación de staff. Esto es porque la programación en pares mitiga el problema de que haya personas que sean “islas de conocimiento”, y que al abandonar un proyecto lo afecten significativamente. Al estar continuamente compartiendo el conocimiento dentro de un equipo, se reduce el impacto de la rotación. En Extreme Programming se utiliza el término “número de camiones” (truck number) para referirse al número de personas que tendrían que ser atropellados por un camión para que el proyecto tuviera que cancelarse, y XP busca que dicho número sea lo más cercano al número total de personas en el equipo. No es que no haya especialización entre los miembros del equipo, es solo que todos están enterados de qué es lo que está pasando, y por qué se hizo así.

Adherirse a un estándar de programación

Si los programadores se adhieren a un mismo estándar de programación (incluyendo detalles como tabuladores vs. espacios, posicionamiento de corchetes, y nomenclatura de elementos), todo funciona mejor. Es más sencillo mantener y extender código, refactorizarlo, y reconciliar conflictos de integración, cuando se utiliza un mismo estándar a través de todo el código de un proyecto. No importa cual estándar se utilice, lo importante es adherirse a él.

Base de código común

Esta técnica se refiere a que todos, o al menos la mayoría, de los miembros del equipo compartan la misma base de código fuente. Esto solo es viable si se están aplicando otras técnicas como la integración continua y la adherencia a un estándar de programación. También sirve de mucho aplicar programación en pares. La principal ventaja de utilizar una base de código común es minimizar el impacto de la rotación de personal. Si todo el equipo utiliza una misma base de código y tiene una buena idea de en qué está trabajando cada quién, entonces es más fácil tanto quitar como agregar programadores al equipo. Esta práctica también facilita el tener un diseño consistente a lo largo de todo el proyecto.

Un área de trabajo común

Durante la segunda guerra mundial, cuando Inglaterra se convenció de que necesitaba poder romper los complicados algoritmos criptográficos de los Nazis, ensamblaron un grupo con los mejores matemáticos y criptógrafos. Al hacer esto, no los pusieron en oficinas separadas para que trabajaran aislados, sino que los juntaron lo más posible, fomentando la interacción entre ellos. Este grupo estaba aislado del resto del mundo. Trabajaban, comían y dormían juntos. Fue de esta tumultuosa convergencia que surgieron ideas brillantes que los llevaron a construir las máquinas (computadoras) que hicieron posible descifrar los códigos Nazis. Se ha demostrado en repetidas ocasiones que los espacios de trabajo abiertos facilitan la comunicación en el equipo. Cuando un programador tiene una pregunta técnica, duda sobre algún requerimiento, o encuentra un conflicto de integración, cuenta con ayuda a la mano. Cuando las personas hablan entre sí exactamente en el momento que lo necesitan (en lugar de esperar a la próxima junta), los problemas se resuelven más rápido y mejor.

Conclusión

Invitamos a los equipos de desarrollo de software a adoptar las prácticas descritas en este artículo. Sin duda encontrarán que les permiten desarrollar mejor software de forma consistente.

.Prácticas Gestión de

Datos

NoSQL la

evolución de las bases de datos

››Por Erick Camacho

tico. No se pueden hacer consultas avanzadas sobre un cache, y no se puede interactuar con él de la misma forma con que se haría con una RDBMS. Entonces, ¿para qué eliminar el poder de un RDBMS y usar un simple cache para almacenar datos?

n un mundo de constantes cambios a nivel de sistemas, es necesario volver a pensar acerca de los paradigmas que manejan la industria. Necesitamos ajustar nuestras herramientas a las necesidades reales que tenemos hoy en día con el fin de tener sistemas a la altura de nuestros requerimientos. En el campo de los datos, este cambio se había detenido. Desde que en 1970 Edgar F. Codd publicó su artículo seminal sobre bases de datos relacionales, este paradigma ha dominado el panorama de los datos en los sistemas. Su longevidad es debido en gran parte a que es un modelo bien fundado en bases matemáticas que puede representarse fácilmente usando algoritmos computacionales. Gracias a esto existe una oferta amplia de sistemas de bases de datos relacionales (RDBMS), hecho que a su vez ha llevado a los desarrolladores a usarlos en prácticamente todas sus aplicaciones. Aún así, hemos llegado a un punto en que seguir usando bases de datos relacionales para todos los casos es simplemente inviable. Existen varios problemas con los RDBMS actuales que pueden suponer una seria limitante para la construcción de aplicaciones. Estos problemas son en gran medida el motivo por el que surgió el movimiento NoSQL.

Problema 2: ¿Realmente necesitamos transacciones para todo?

El modelo relacional tiene escrituras de datos rápidas y eficientes. Sin embargo, si se hace uso de transacciones para preservar la integridad de los datos, habrá una penalización en el rendimiento por el uso de locks (bloqueos) a nivel de datos que decrementarán el desempeño. Lamentablemente, los RDBMS actuales por lo general hacen uso de transacciones aún si el desarrollador no las necesita. Recuerda que el principal objetivo de las transacciones es asegurar la integridad de los datos guardados con el fin de mantener la consistencia de estos datos si se hacen consultas concurrentes. Sin embargo, no siempre es necesario este comportamiento. Piensa por ejemplo en un sistema de conteo de votos para unas elecciones. Seguramente en un sistema así, las transacciones son muy importantes ya que no se pueden presentar datos que no son consistentes. Se debe mostrar el número exacto de votos para cada candidato. En una aplicación como la descrita, es más importante la consistencia de la información que el tiempo que se tarde en inserción y consulta de los datos. Por lo que un RDBMS se ajusta muy bien a este caso. Sin embargo, piensa que además tu aplicación contendrá un sistema de conteo rápido cuya finalidad es solamente mostrar las tendencias, sin dar números exactos, en el menor tiempo posible. En estos casos, la transaccionalidad de un RDBMS sería un estorbo porque lo más importante es mostrar tendencias en tiempo real (o cercano al tiempo real). Así que si las transacciones no son importantes para nuestro modelo de negocios, ¿para qué usar un RDBMS ?

Problema 1: Leer datos es costoso.

En el modelo relacional los datos se representan mediante conjuntos (tablas) relacionados entre sí. Es así que realizar una consulta por lo general involucra unir estos conjuntos (operación join) lo cual es costoso en términos de recursos de cómputo. Obviamente, hay estrategias para evitar dichos joins basadas en la desnormalización de los datos (tener pocas tablas y pocas relaciones entre ellas); pero si esa es la estrategia a seguir, ¿para qué necesitamos una base de datos relacional? Otra opción que se ha usado para evitar el costo de lectura es utilizar un cache en memoria RAM donde se guardan los resultados de consultas comunes. Esto funciona hasta cierto punto, pero una vez que se han guardado los datos en un cache, éste se vuelve está.BIO Erick Camacho es Maestro en Tecnologías de la Información con especialidad en Ingeniería de Software por la Universitat Politècnica de Catalunya. Cofundador de TidySlice empresa dedicada a la formación y a la consultoría. @ecamacho

Referencias: [1] N. Hurst, “Visual Guide to NoSQL Systems”. http://bit.ly/sg28r6

Figura 1. Estructura de datos tradicional

.Prácticas

Gestión de Datos

Problema 4: ¿Todo dominio se representa bien en un modelo relacional?

Si bien es posible representar la mayoría de modelos de dominio usando el paradigma relacional, no siempre resulta la mejor opción. En el mundo de la programación domina el paradigma orientado a objetos, lo que ya de entrada involucra el problema de traducir los objetos a un modelo relacional. Existen herramientas ORM (Object Relational Mapping) que ayudan a facilitar esta traducción. Sin embargo, como sucede en el mundo de la literatura, traducción es traición. Esto se refiere a que al final tendrás que perder algo de algún lado, o tu modelo orientado a objetos no será totalmente orientado a objetos o tu modelo relacional no será 100% ajustado a las normas de este paradigma. ¿Por qué usar un traductor objeto-relacional cuando puedes tener una base de datos que maneje objetos de forma natural? Otro tema es que el dominio de un sistema no siempre se ajustará sencillamente a un modelo relacional. Claro que podremos ajustarlo, pero es un típico ejemplo de que cuando se tiene un martillo, todo problema parece un clavo.

Figura 2. Estructura de datos columnar

Not Only SQL

Como respuesta a estos problemas surgió el paradigma NoSQL. NoSQL no es un sustituto a las bases de datos relacionales, es solo un movimiento que busca otras opciones para escenarios específicos como los que mencionamos, “No uses sólo SQL”. Históricamente, el término fue primero usado en los 90’s para nombrar una base de datos relacional open source. Sin embargo, como denominador de el conjunto de bases de datos alternativas al modelo relacional, fue primero usado en 2009 por Eric Evans para nombrar una serie de conferencias sobre este tipo de bases de datos. Aunque el término más correcto sería NoREL (Not Only Relational), como varios han señalado, el término NoSQL ya tiene gran aceptación. Es solo una forma de decir que no todos los problemas son clavos que pueden ser atacados con un RDBMS. Más aún, NoSQL no es una solución única, su fortaleza está en su diversidad. El desarrollador cuenta con un abanico de soluciones y puede elegir la mejor para su problema en específico. Existen varias formas de NoSQL, que atacan los problema del escalamiento, performance y modelado de los datos de formas distintas. No hay una bala de plata, esta vez tendrás que pensar qué opción es la mejor para tu problema. Repasaremos las categorías de bases de datos NoSQL más usadas. • Almacenes Key-Value Estas son las bases de datos más simples en cuanto su uso (la implementación puede ser muy complicada), ya que simplemente almacena valores identificados por una clave. Normalmente, el valor guardado se almacena como un arreglo de bytes (BLOB) y es todo. De esta forma el tipo de contenido no es importante para la base de datos, solo la clave y el valor que tiene asociado. La capacidad de almacenar cualquier tipo de valor se denomin schema-less, ya que a diferencia de un RDBMS no necesita definir un esquema (columnas, tipos de datos) para almacenar la información. Los almacenes key-value son muy eficientes para lecturas y escrituras, además de que pueden escalar fácilmente particionando los valores de acuerdo a su clave; por ejemplo aquellos cuya clave está entre 1 y 1000 van a un server, los de 1001 a 2000 a otro, etc. Esto los hace ideales para entornos altamente distribuidos y aplicaciones que necesitan escalar horizontalmente. Su limitante está en que no permiten realmente un modelo de datos, todo lo que guardan es un valor binario; aunque algunas implementaciones como Redis modifican este comportamiento permitiendo otro tipo de valores como Listas. Su API es bastante simple y no es más que una variación de 3 operaciones: Put, Get, Delete. Este tipo de base de datos son muy útiles para almacenar sesiones de usuario (usando su username como clave). Recuerda que los almacenes key/ value son extremadamente rápidos pero no permiten consultas complejas más allá de buscar por su clave. Por lo que si tu aplicación necesita consultas complejas, este tipo de base de datos no se ajusta a tus necesidades. 37

Software Guru

Los RDBMS no escalan fácilmente. Si usamos un modelo de escalamiento vertical, lo que hacemos es inflar con más recursos (CPU, RAM, espacio en disco, etc.) a nuestro servidor de bases de datos. Este tipo de escalamiento está sujeto a los límites del hardware, y su costo aumenta exponencialmente. Llegará un punto en que ya no podamos seguir escalando. Es muy complicado escalar horizontalmente un RDBMS. El escalamiento horizontal involucra usar más servidores de forma paralela. Pero como el modelo relacional se basa en tener relaciones entre tablas, ¿cómo dividir los datos entre servidores si al final corremos el riesgo de que al hacer un join tengamos que traer los datos de varios servidores a la vez, con el costo que una operación así involucra? Para este tipo de problemas surgió la técnica sharding, del término share-nothing (compartir nada). Esto quiere decir que tendremos tablas sin relaciones con las tablas que estén en otro servidor, evitando hacer joins entre servidores. Pero si no tenemos relaciones, ¿para qué seguir usando un modelo relacional?

Un ejemplo muy relevante hoy en día de este problema son la redes sociales. En una red social tenemos muchos nodos conectados entre sí de muchas formas. Creando un grafo con millones de nodos y relaciones de diverso orden. En estos casos, una base de datos relacional no alcanza para expresar este tipo de dominios de forma eficiente ¿Por qué usar un RDBMS en un caso así, si solo te complicará más el problema?

www.sg.com.mx |

Problema 3: ¿Cómo escalamos?

.Prácticas Gestión de

Datos

Existen implementaciones de estos almacenes solo en memoria, tales como: memcached, Oracle Coherence, JBoss Cache y WebSphere eXtreme Scale. Estas soluciones normalmente funcionan junto a un RDBMS actuando solo como un cache complementario. Además existen otras implementaciones que sí son persistentes, es decir que realmente guardan datos en filesystem y no sólo en memoria por lo que se les puede usar sin un RDBMS. Las más usadas son VMWare Redis, Amazon SimpleDB, Oracle BerkeleyDB y Tokyo Cabinet. • Bases de datos columnares Como su nombre lo indica, guardan los datos en columnas en lugar de renglones. Por ejemplo, en una RDBMS tradicional tendríamos una tabla como la que se muestra en la figura 1, mientras que en una base orientada a columnas tendríamos las tablas que muestra la figura 2. Con este cambio ganamos mucha velocidad en lecturas, ya que si queremos consultar un número reducido de columnas, es muy rápido hacerlo. Al final tenemos una base muy parecida a las key-value. Por otro lado, este paradigma no es muy eficiente para realizar escrituras. Por ello este tipo de soluciones es usado en aplicaciones con un índice bajo de escrituras pero muchas lecturas. Típicamente en data warehouses y sistemas de Business Intelligence, donde además resultan ideales para calcular datos agregados.

Bases de datos orientadas a documentos

Este tipo de bases de datos son en esencia un almacen key-value con la excepción de que el valor no se guarda sólo como un campo binario, sino con un formato definido de forma tal que el servidor pueda entenderlo. Esto no quiere decir que tengan un esquema, siguen siendo schema-less, seguimos teniendo solo 2 campos y uno de ellos binario. La diferencia es que el campo binario puede ser entendido por la base de datos. Dicho formato a menudo es JSON, pero puede ser XML o cualquier otra cosa. Si el servidor entiende los datos, puede hacer operaciones con ellos. De hecho varias de las implementaciones de este tipo de bases de datos permiten consultas muy avanzadas sobre los datos, e incluso establecer relaciones entre ellos, aunque siguen sin permitir joins por cuestiones de performance. Todo esto sin perder de vista que sigue siendo un key-value con todas las ventajas que nos dan estos almacenes. Por ello este tipo de bases de datos son en gran medida los responsables del hype actual de NoSQL. Ofrecen un gran performance y escalabilidad sin perder del todo los beneficios del modelo relacional. Entre las bases de datos de este tipo, están los más famosos ejemplos de la familia NoSQL: Google BigTable, MongoDB, Apache CouchDB y Apache Cassandra. Cabe resaltar que parte del ruido que está provocando NoSQL se debe a la adopción de Cassandra (originalmente desarrollada por y para Facebook, luego donada a la fundación Apache) por parte de Twitter y Digg.

Bases de datos orientadas a grafos

Como su nombre lo indica, estas bases de datos almacenan los datos en forma de grafo. Esto permite darle importancia no solo a los datos, sino a las relaciones entre ellos. De hecho, las relaciones también pueden tener atributos y puedes hacer consultas directas a relaciones, en vez de a los

nodos. Además, al estar almacenadas de esta forma, es mucho más eficiente navegar entre relaciones que en un modelo relacional. Obviamente, este tipo de bases de datos sólo son aprovechables si tu información se puede representar fácilmente como una red. Algo que ocurre mucho en redes sociales o sistemas de recomendación de productos, donde además se tiene la ventaja de poder aplicar algoritmos estadísticos para determinar recomendaciones que se basan en recorrer grafos. Entre las implementaciones más usadas está Neo4J, HyperbaseDB e InfoGrid.

Bases de datos orientadas a objetos

Desde 1980, se ha hablado de que el remplazo natural de las RDBMS son las bases orientadas a objetos. Como su nombre lo indican, este tipo de bases se basan en el paradigma orientado a objetos y no en el modelo relacional. Por ello, a pesar de seguir basándose en tablas, tienen diferencias. Por ejemplo: pueden representar relaciones jerárquicas (generalización/ especialización), no se basan en claves primarias sino en OID (identificadores únicos de objetos calculados por la base de datos), las relaciones entre tablas son a través de punteros a objetos. Las bases orientadas a objetos nunca tuvieron el impacto esperado, pero tienen varios nichos específicos como algunas aplicaciones de carácter científico y en los últimos años aplicaciones móviles. Más aún, influenciaron positivamente al estándar SQL 1999 que incluyó algunas de sus mejoras; además de que varios vendors como Oracle y Postgres también adoptaron algunas de sus funcionalidades en sus RDBMS. Entre las bases de datos orientadas a objetos más populares están db4o, Versant y Objectivity/DB.

¿Cuál elegir?

Cómo hemos visto, cada base de datos tiene utilidades y ventajas específicas para cierto tipo de casos de uso. Las basadas en key-value son sin duda las de mejor performance pero ofrecen la funcionalidad más limitada. Las basadas en columnas son muy buenas si trabajas con datos agregados. Las basadas en documentos son una gran opción si quieres tener consultas complejas pero sin perder la velocidad de los almacenes key-value. Lo mismo con las basadas en objetos, que permiten realizar consultas muy complejas pero ofrecen poca mejora en el rendimiento. Por último no se debe de descartar a las RDBMS. De estas bases, su gran fuerte es la transaccionalidad. Si necesitas preservar la integridad de la información –y la mayoría de las aplicaciones lo necesitan–, un RDBMS sigue siendo la mejor opción. Existe un teorema para sistemas distribuidos llamado CAP, cuyo autor es Eric Brewer. Dicho teorema explica que hay 3 requerimientos básicos en los sistemas distribuidos: • Consistencia. Se refiere a la integridad de la información. Todos los nodos del sistema ven la misma información en todo momento. • Disponibilidad. Que tu aplicación esté disponible siempre. Si falla algún nodo los demás pueden seguir operando sin problemas. • Tolerancia al particionamiento. El sistema continúa funcionando a pesar de que se pierdan mensajes de forma arbitraria. El teorema CAP establece que es imposible que un sistema satisfaga 38

los 3 requerimientos de forma simultánea, por lo que debes elegir 2 y enfocarte en ellos. En el caso de los RDBMS, le dan más importancia a la consistencia y a la disponibilidad, en detrimento de la tolerancia al particionamiento. Por otro lado, las diferentes opciones de NoSQL dan mayor prioridad a la tolerancia y en ocasiones la disponibilidad. Así que además de revisar la funcionalidad de tu aplicación y elegir una base de datos adecuada, debes de tener en cuenta el teorema CAP para revisar cual de estos 3 elementos estás dispuesto a sacrificar para favorecer a los otros. Natahan Hurst ha publicado en su blog [1] una guía visual que diagrama a las bases de datos contra el triángulo formado por los 3 elementos de CAP. De tal forma que sepas de antemano las debilidades y fortalezas de cada solución en el contexto del teorema CAP.

Conclusión

Las bases de datos NoSQL son ya una opción más en la cartera de alternativas para almacenar los datos de tus aplicaciones. Existen varios tipos de ellas, pero en general su objetivo principal es resolver los problemas de performance y de escalabilidad de las RDBMS. Por otro lado, las RDBMS no desaparecerán ni mucho menos. Sus capacidades transaccionales las hacen perfectas para la mayoría de las aplicaciones existentes. Sin embargo, seguramente sufrirán cambios. Así como en el pasado las bases orientadas a objetos influenciaron la evolución de las RDBMS, veremos en el futuro muchas de las ideas de las NoSQL aplicadas a las bases relacionales. En el futuro, usarás más de un solo tipo de bases de datos. Aquella que se adapte a tu aplicación y más aún, aquella que se adapte a cierto caso de uso de tu aplicación. Por lo que no será raro ver desarrollos que usen más de un solo tipo de base de datos. El punto es que debes seguir adaptándote, perderle el miedo a salir de la seguridad de un RDBMS y empezar a usar otras alternativas. Muchas de las bases de datos NoSQL tienen ya calidad de producción, algunas incluso tienen soporte comercial disponible y están respaldadas por empresas importantes. Recuerda que no se trata de usar la mejor herramienta, sino de usar la mejor herramienta para tu problema específico.

.Prácticas Arquitectura

Requerimientos y Arquitectura los requerimimentos guían las

omo mencionamos en el número anterior (SG27), la arquitectura de software se enfoca en aspectos de diseño estructural del sistema con el fin de satisfacer ciertos requerimientos clave para el sistema, además de guiar el desarrollo del mismo. En este artículo nos enfocaremos en describir la relación que existe entre los requerimientos y la arquitectura de software.

Recordando requerimientos

Recordemos un poco sobre qué son los requerimientos. Generalmente se considera que los requerimientos de un sistema se pueden dividir en dos categorías: Requerimientos Funcionales (RFs) y Requerimientos No Funcionales (RNFs). De acuerdo a Wiegers [1], los RFs engloban los distintos tipos de requerimientos que se reflejan en los comportamientos de la aplicación y que incluyen: • Requerimientos de negocio. Motivación de negocio para que exista un sistema. • Requerimientos de usuario. Comportamiento del sistema, frecuentemente se expresan en forma de casos de uso. • Requerimientos funcionales detallados. Complementan a los casos de uso (generalmente se describen usando el verbo “deber”). • Requerimientos de sistema. Describen el mínimo hardware y software para que un sistema de información pueda funcionar. Por otra parte, los RNFs tienen que ver con la manera en que el sistema soporta a los RFs. Estos incluyen: • Reglas de negocio. expresan reglas de la organización que deben ser soportadas por el sistema. • Atributos de calidad. se describen más adelante. • Restricciones. Expresan aspectos que deben considerarse al realizar el diseño y limitan las decisiones que se pueden tomar. • Interfaces externas. Especificaciones de interfaces de otros sistemas con los que se interactúa.

Requerimientos de negocio

Los requerimientos de negocio deben identificarse al inicio del desarrollo de un sistema. Dichos requerimientos permiten comprender, desde una perspectiva de negocio, la motivación que existe de realizar un sistema. Para ejemplificar este concepto, imaginemos a la compañía “xyz” que se dedica a la comercialización de productos de diversos fabricantes. Actualmente cuenta con sucursales en varias localidades de la zona sur de la República Mexicana y desea expandir su negocio a través de la venta de productos por Internet. Un objetivo de negocio para esta compañía es “Ofrecer los productos de la empresa a través de un portal en dos etapas: el primer año será dirigido al mercado Mexicano y el siguiente año al mercado internacional.”

decisiones arquitectónicas ››Por Humberto Cervantes y Edith Valencia

Drivers de la arquitectura

Dentro de los requerimientos que se consideran para el desarrollo de un sistema y que se derivan de los objetivos de negocio, existe un subconjunto que tiene una gran importancia relativa a la arquitectura. Estos requerimientos se conocen en inglés como drivers de la arquitectura. El término “drivers” puede traducirse como “guías”, ya que estos requerimientos “guían” el diseño de la arquitectura del sistema. Una estructuración correcta del sistema permitirá satisfacer la mayoría de estos drivers. Los drivers de la arquitectura incluyen principalmente a los atributos de calidad. Además de esto, incluyen a un subconjunto de los casos de uso que se consideran como primarios. Los casos de uso primarios son aquellos de mayor importancia o de mayor complejidad para el negocio. Por último, las restricciones también son consideradas como drivers arquitecturales. El hecho de que los drivers sean un subconjunto de todos los requerimientos del sistema puede verse como una ventaja pues es posible comenzar a realizar el diseño de la arquitectura antes de haber terminado de documentar todos los requerimientos. Ciertas metodologías de desarrollo como por ejemplo el Rational Unified Process recomiendan, de hecho, que se siga este enfoque. Retomando el ejemplo anterior, un caso de uso primario podría ser el realizar consultas del catálogo de productos. El criterio para elegir este caso de uso como primario es su importancia relativa a la satisfacción del objetivo de negocio y el hecho de que la consulta de catálogos involucra realizar conexiones hacia los sistemas de los fabricantes. Una restricción para dicho sistema podría ser que se usen librerías y herramientas open source.

Atributos de calidad

Como se mencionó previamente, los atributos de calidad forman parte de los RNF del sistema. Son características medibles que permiten expresar y evaluar el grado de satisfacción de los usuarios y/o diseñadores (es decir la calidad) con respecto al sistema. Cabe señalar que no son la única métrica de calidad de un sistema, la ausencia de defectos es otra métrica clave en este rubro. Existen distintas categorías de atributos de calidad y éstas se clasifican con respecto a la importancia que tienen ya sea para los clientes o para la organización de desarrollo. Entre las más comunes están: • Desempeño. Tiempo de respuesta del sistema con respecto a un estímulo. • Seguridad. La facultad del sistema de resistir a ataques. • Modificabilidad. Costo de realizar cambios en el sistema. • Usabilidad. Qué tan fácil es para el usuario realizar una tarea particular y el tipo de soporte que el sistema provee al usuario. • Facilidad de prueba. Sencillez con la cual se pueden identificar defectos 40

.Prácticas

Arquitectura

Como se puede apreciar, el atributo de calidad es medible, se alinea con el objetivo de negocio (ventas en el mercado internacional) y la métrica se justifica con base en los datos históricos de tiempo de la empresa de desarrollo.

››Una estructuración correcta del sistema permitirá satisfacer la mayoría de estos requerimientos.

Para terminar

Dada la importancia que tienen los drivers arquitecturales en relación con el diseño de la arquitectura, se debe tener especial cuidado de capturarlos antes de comenzar a realizar el diseño. Algunas recomendaciones .BIO al respecto son las siguientes: El Dr. Humberto Cervantes es profesor-investigador en la UAM-Iz• Comenzar por la tapalapa. Ha realizado investigación en temas relacionados con arquitecidentificación de los objetivos tura de software desde el año 2000 de negocio del sistema. y en años recientes se ha enfocado en el estudio y la aplicación de • Enfocarse inicialmente en métodos que apoyen al desarrollo de arquitectura de software dentro la documentación de los casos de la industria Mexicana. de uso primarios. www.humbertocervantes.net • Identificar restricciones. La MSc. Edith Valencia es arqui• Incluir dentro de las tecto de software en la empresa QuarkSoft. Cuenta con más de 10 entrevistas de requerimientos años de experiencia en la industria preguntas enfocadas a obtener de software en México. Obtuvo la maestría con honores en Ingeniería información relacionada con de Software en la Universidad de York en El Reino Unido. Sus áreas los atributos de calidad. de interés incluyen arquitecturas • Identificar métricas para los de software, ingeniería de procesos de software y metodologías ágiles. atributos de calidad y revisar evalencia@quarksoft.net si dichas métricas tienen un sustento, es decir, se alinean Referencias: [1] K. Wiegers, “Software Requirements”, con los objetivos de negocio. 2nd Edition, Microsoft Press, 2003 • Priorizar y verificar los [2] L. Bass, P. Clements, R. Kazman, “Software Architecture in Practice”, atributos de calidad 2nd Edition, Addison Wesley, 2003 involucrando al cliente. 41

Software Guru

Una vez definidos, los drivers son la entrada para el proceso de diseño de la arquitectura (que será descrito en próximas entregas de esta serie). Los atributos de calidad juegan un papel especialmente importante en este sentido y como se mencionó previamente, el satisfacerlos requerirá tomar decisiones de diseño particulares. Por ejemplo, para satisfacer el driver de modificabilidad expresado previamente una posible solución será concentrar todo el texto de la aplicación en un archivo de propiedades separado del código que pueda ser fácilmente cambiado y que no requiera de recompilar el sistema.

www.sg.com.mx |

Conviene señalar que no existen definiciones universales en cuanto a las distintas categorías de atributos de calidad. En ese sentido, lo más conveniente es definir una categoría en el contexto del sistema que se está desarrollando. Por otro lado, un aspecto esencial con respecto a los atributos de calidad es que se debe procurar, en la medida de lo posible, expresarlos de manera cuantitativa. No tiene sentido, por ejemplo, decir que las respuestas del sistema deben ser “rápidas” ya que no es posible evaluar esto de manera objetiva. A pesar de que los atributos de calidad deben ser expresados de manera cuantitativa, no existe una métrica única asociada con cada una de las categorías de atributo de calidad; es tarea del arquitecto identificar la mejor manera de expresar este tipo de requerimientos. Por otro lado, se debe tener especial cuidado de no imponer métricas arbitrarias (y excesivas) tan sólo con el fin de satisfacer la necesidad de expresar los atributos de calidad de manera cuantitativa. Por ejemplo, exigir un tiempo de respuesta demasiado corto provocará que se tomen decisiones de diseño que pueden resultar complejas y costosas. Una disponibilidad muy elevada igualmente va a requerir de ciertas decisiones con un costo elevado (por ejemplo: sistemas redundantes). De forma general, al momento de identificar una métrica, es necesario asegurarse que el valor que se le asocia se justifica y está alineado con los objetivos de negocio del sistema y que no es simplemente una ocurrencia. El Software Engineering Institute propone que los atributos de calidad sean especificados usando “escenarios” [2]. Un escenario expresa una respuesta medible del sistema ante un estímulo en un contexto particular. El escenario se expresa como una frase que contiene seis partes que incluyen el estímulo, la fuente del estímulo, el artefacto que recibe el estímulo, el entorno al momento de recibir el estímulo, la respuesta del sistema al estímulo y la métrica para evaluar la respuesta. Una ventaja de esta técnica de especificación es que un escenario es, automáticamente, un caso de prueba para el sistema. Regresando a nuestro ejemplo, podemos considerar un atributo de calidad que se refiera a “la facilidad para agregar un nuevo idioma al sistema”. Dicho atributo pertenecería a la categoría de modificabilidad, y esta sería la forma de documentarlo como escenario. 1. Fuente: Un desarrollador 2. Estímulo: Desea portar la aplicación al idioma inglés 3. Artefacto: Código 4. Entorno: En etapa de producción 5. Respuesta: La modificación es realizada sin necesidad de recompilar 6. Métrica: En menos de 16 horas hombre

.Prácticas Ágil

Coaching y Producción

una aventura en el estudio de

Qué tienen en común los Beatles, Nirvana, y la Orquesta Sinfónica de Minnesota? Cada uno de ellos tuvo la suficiente suerte de trabajar con un productor que les ayudó guiándoles durante la creación de una gran grabación. Los productores exitosos de música entienden que la colaboración iterativa es un ingrediente clave para la producción de grandes grabaciones. Los mejores productores aprendieron que el balance de la creatividad, las habilidades, el tiempo y el dinero son esenciales para lanzar grabaciones valiosas. Al igual que produciendo música, me doy cuenta que coachear proyectos agile (ágiles) es una artesanía que involucra llegar a conocer a la comunidad del proyecto, el producto que se está construyendo, las herramientas y las tecnologías. Los coaches exitosos balancean el desarrollo de habilidades, peticiones para el producto, tiempo y presupuesto, como una manera de lanzar software que es oportuno y valioso.

El proceso de producción de música

Cada canción sigue un proceso similar de grabación, mezclado, generación del master, y lanzamiento. Dentro del proceso cada canción sigue una jornada única. (Ver Figura 1) El productor ayuda a que las canciones sobrevivan el proceso de grabación guiando a los artistas a través del proceso de grabación similarmente a como un coach ayuda a un equipo a lanzar un producto de software. Existen dos categorías de productores: productores prescriptivos, empujan a la gente a seguir el proceso y las técnicas que ellos han utilizado exitosamente; y productores descriptivos quienes tienden a guiar y enseñar con anécdotas. En lugar de decirle a la gente qué hacer, ellos sugieren ideas y motivan a los artistas a tomar riesgos y decisiones sobre la mejor manera de capturar su música.

Preproducción

El tiempo dedicado en la preparación, antes del primer día en el estudio, vale mucho la pena para crear una sesión de grabación relajada y exitosa. La preproducción no debe prescribir el resultado de ninguna sesión de grabación, sino ayudar a aprender más sobre los artistas y la manera en que tocan como grupo. Si crees que un proyecto de software es mas difícil que un proyecto de grabación, entonces unos días en el estudio te podrán enseñar que el monto de emoción, miedo y volatilidad en el estudio, .BIO es normalmente mayor. David Hussman es fundador y director de DevJam, empresa norteamericana que se dedica a enseñar y coachear equipos interesados en adoptar métodos ágiles. David ha coacheado a cientos de equipos ágiles en todo el mundo. Previamente, David se dedicó a construir software para diversos dominios tales como audio digital, biométricos, salud y educación, por nombrar algunos. @davidhussman

grabación

››Por David Hussman con traducción de Masa K. Maeda

Las sesiones de grabación

Las sesiones de grabación es donde las canciones son cantadas y las pistas son cortadas. El proceso es absolutamente iterativo e incremental. Ayudando a la banda a enfocarse en cada

canción, así como en la colección entera de canciones, el productor agrega continuidad. El productor trabaja con uno o más artistas, grabando y re-grabando partes separadas; y con el ingeniero de grabación de manera que la tecnología sea utilizada para ayudar a los artistas conforme su ejecución es capturada con fidelidad. El productor puede ayudar a asegurar que los artistas y la canción sean atendidos por la tecnología, en lugar de hacerse sirvientes de la tecnología.

Coaches de desarrollo de software como productores

Mi primera oportunidad para la creación de software fue en una pequeña compañía exitosa. Nuestra compañía trabajaba muy parecido a lo que hoy se entiende como ágil: teníamos juntas informales cortas, éramos dirigidos por resultados, y programábamos en pares aunque tan solo le llamábamos “trabajar juntos”. Conforme cambié a empresas más grandes se me pedía que siguiera diversos procesos que tan solo parecían frustrar a la gente. Como un acto de autopreservación le presté atención a los procesos ágiles que estaban emergiendo, éstos parecían proveer el monto de estructura al que me había acostumbrado durante mis primeras experiencias de software, y la experiencia era en mucho como el estudio de grabación.

El proceso de producción de software

Creo que me hice coach de manera más bien descriptiva que predictiva. Después de varios años de ofrecer coaching, busqué maneras de mejorarlo y aprender qué parte de cada proyecto exitoso tuvo que ver con el coaching y qué parte tuvo que ver con la comunidad o nuestro uso de métodos ágiles. Fue rápidamente claro que muchas de mis habilidades como productor habían sido transferidas a mi coaching. Mientras que los medios difieren, la labor del coach y del productor son muy similares. Ambos ayudan a la gente a crear su mejor producto con el tiempo, dinero, y tecnología disponibles. Donde el productor ayuda a los artistas a hacer grabaciones de las canciones, el coach ayuda a las comunidades de proyecto a hacer de los sueños del Product Owner un software funcional. (Ver Figura 2)

Preproducción

Muchos proyectos comienzan con algún tipo de preproducción a fin de crear el tiempo y espacio para que una comunidad esté lista para producir. Esto ofrece el mismo beneficio que en el mundo de la música. Usualmente agrego cuatro prácticas de preproducción al coaching: • Estatutos del proyecto • Crear un backlog de producto inicial • Espacio informativo de trabajo • Iteración 0 42

.Prácticas Ágil

››Mientras que los medios difieren, la labor del coach y del productor son muy similares. Ambos ayudan a la gente a crear su mejor producto con el tiempo, dinero, y tecnología disponibles.

Para ver mejor el valor del coach tomemos los estatutos de proyecto desde el punto de vista del coach. Muchos gerentes crean estatutos de proyecto, pero tristemente poca gente los lee porque probablemente son enterrados, no son compartidos, o la gente no toma pertenencia. La comunidad ágil tomó una herramienta existente y la hizo mejor mediante su transformación en una herramienta colaborativa. Los estatutos son creados por la comunidad para la comunidad. Son una forma para que se conozca la comunidad entre ella, el propósito del proyecto, la gente en la comunidad inmediata y extendida del proyecto, así como las fortalezas y riesgos que están por delante.

Las iteraciones tempranas

En el estudio, el corte de buenas pistas de soporte es esencial para producir un gran producto final. Conforme la banda graba y regraba cada canción comienzan a crear un buen estado de ánimo. En ocasiones ese estado crece orgánicamente, con intervención limitada del productor. Las iteraciones tempranas son un tiempo importante para generar vínculos y hábitos sanos. Cada iteración reta a la comunidad a reunirse en una forma tal que se entregue software funcional y una base de código sana de manera sostenible. Describo un par de ejemplos: • Ayudando a la Gente a Aprender. En lugar de meterse y tocar una parte para un músico que esta luchando por lograr algo, el productor utiliza sus habilidades y ve la manera de entender porqué el músico está teniendo

Figura 1. El proceso de producción de música

Afinamiento continuo

Tanto el productor como el coach tienen trabajos difíciles que requieren de gran paciencia y liderazgo continuamente respetuoso. Coachear es un proceso continuo y no un evento. Cambios gracias al coaching suceden en una serie de pequeños momentos que incrementalmente se suman de manera sutil en pequeños eventos, que le ayudan a la comunidad a experimentar, examinar, y mejorar de pedacito en pedacito.

Conclusión

Ya sea que estés produciendo discos o software, decir historias es una de las herramientas más poderosas. Tú puedes decirle a la gente qué hacer, el estilo prescriptivo, pero puede que no te escuchen. En su lugar, diciéndoles lo que has hecho, el estilo descriptivo, inicia una discusión significativa. Una vez que las personas están metidas en el tema, el estilo descriptivo les permite aprender qué parte de tu experiencia puede ser útil.

Figura 2. El proceso de producción de software

Software Guru

Estatutos de proyecto

dificultades. Un coach hábil encuentra el momento adecuado para ofrecer palabras de apoyo y el momento adecuado para dar un empujoncito. • Liderando y enseñando. Mientras que tu coach puede dirigir las primeras juntas o las sesiones de planeación de iteración, los mejores coaches saben que la ruta hacia el éxito sostenible se pavimenta permitiendo que la comunidad se encargue lo antes posible. • Explicando porqué más que diciendo cómo. Ayudar a los artistas en el estudio a utilizar el proceso para capturar su música es mucho más importante que enseñarles a utilizar los aparatos. Agilidad sostenible es más común cuando la gente ve el valor de la práctica, en lugar de que tan solo se les diga cómo hacer la práctica. • La importancia de dejarlo hecho. Mientras que el coach hace el trabajo con individuos, en otras ocasiones el trabajo es con la comunidad. El couching de éxito sostenible significa dejar que la comunidad tome posesión y crezca su uso compartido.

www.sg.com.mx |

Intento asegurarme de que el monto de rigor de preproducción es apropiado para la comunidad que estoy coacheando. Por ejemplo, un equipo muy adaptivo puede completar estas cuatro fases en unos cuantos días. Contrariamente, un grupo grande y distribuido que está reemplazando un sistema complejo puede necesitar más tiempo de preproducción.

.Fundamentos

Desarrollo de Aplicaciones Web de Alto

Performance

mejores prácticas

››Por Ricardo Rangel

nte la importancia que han cobrado las aplicaciones web, es necesario que los desarrolladores web adquieran una cultura orientada al performance, ya que en el entorno web las aplicaciones son muy sensibles a factores incontrolables tales como el ancho de banda del cliente, ubicación geográfica, número de usuarios concurrentes, etcétera. El performance, hablando de desarrollo web, se refiere al grado de agilidad y respuesta con que se desempeña un sitio web. En este artículo veremos algunas buenas prácticas para mejorar el performance de las aplicaciones web. En algunos casos utilizo referencias a .Net porque es la plataforma que mejor conozco, pero quienes utilicen otras tecnologías seguramente encontrarán analogías que correspondan.

Evitar el uso de imágenes pesadas.

Internet es un entorno multimedia por excelencia: video, música, imágenes, animaciones web. Los elementos básicos de una página web son texto e imágenes, pero no es recomendable manejar imágenes muy pesadas ya que la página puede llegar a tardarse bastante en cargar. Los formatos adecuados de imágenes en ambiente web son: • GIF. Es el único formato que permite realizar animaciones. Soporta imágenes de pocos colores (hasta 256). Es bueno para imágenes sencillas (no fotografías). • PNG. Es un formato mejorado de GIF, ya que presenta un algoritmo de compresión sin perdida de calidad en la imagen. IE6 no lo soportaba pero prácticamente todos los navegadores modernos ya lo soportan. • JPEG. El rey de las imágenes ligeras. Al contrario de GIF, su algoritmo de compresión elimina información y por ende decrece la calidad de la imágenes (en muchas ocasiones esto no importa porque la pérdida de información no es perceptible para el ojo humano). Los formatos de imágenes inadecuados para ambiente web son: • BMP. El BitMaP es el formato nativo del sistema operativo Windows de Microsoft. Define los valores de cada pixel, uno a uno, de abajo a arriba y barriendo las líneas de izquierda a derecha. Su gran problema es que genera archivos enormes. • TIFF. Formato propiedad de Adobe Systems empleado para intercambiar fotografias entre distintas aplicaciones y plataformas. Comprime las imágenes sin pérdida de calidad pero el peso sigue siendo grande en comparación a otros formatos.

• PSD. Formato utilizado por el popular editor de imágenes Photoshop. No utiliza compresión y se emplea para guardar la imagen durante el proceso de edición, pues mantiene toda la información sobre capas sin acoplar. Nota: HTML 5 soportará formatos de imagen vectoriales, que son una excelente opción para diagramas y trazos ya que son muy ligeros y no pierden calidad al aumentar sus dimensiones.

Tener cuidado con controles y wizards

.Net proporciona una seria de controles para “facilitar” la vida al programador, por ejemplo el control SQLDataSource. Son controles muy sencillos ya que al solo requerir un comando SQL, cualquier persona podría establecer una conexión a base de datos y traer datos. El problema con este tipo de controles es que son pesados, sin mencionar que hay que introducir la instrucción SQL dentro del control dando origen a una mala practica de programación: el código embebido. Al tener nuestras paginas hechas con este tipo de controles quedan ocultas todas las instrucciones SQL y al darle mantenimiento hay que entrar a cada control a averiguar qué instrucción SQL se esta ejecutando, lo cual hace que el mantenimiento se vuelva complicado, sin mencionar que el performance de la pagina se ve afectado.

Arquitectura basada en capas

La arquitectura en capas nos permite reutilizar código, y por ende, mejorar el performance. He llegado a ver aplicaciones que repiten una y otra vez el mismo código en cada pagina encargado de abrir la conexión a la base de datos y de proporcionar los comandos necesarios para obtener, actualizar, insertar o eliminar datos en vez de establecer toda esta estructura en capas que sean utilizadas una y otra vez en forma genérica para cualquier página. De esta manera nos ahorraremos bastante codificación, sin mencionar toda la carga de texto que le quitamos a las páginas. No es de sorprender que este tipo de técnicas se refleje en una página mucho más ágil y responsiva.

Programar eficazmente

Existen muchos ejemplos de cómo una mala programación puede 44

.Fundamentos

››El performance, hablando de desarrollo

web, se refiere al grado de agilidad y respuesta con que se desempeña un sitio web.

Aligerar la carga de trabajo

La mayoría de las plataformas y lenguajes modernos para desarrollo web nos permiten manipular los objetos como deseemos, desde conversiones a tipos de datos hasta colecciones de objetos, matrices, sobrecarga, polimorfismo, etcétera. Pero en muchas ocasiones es innecesario hacer esto en el nivel de lenguaje de programación, cuando ciertas cosas se pueden manejar desde origen, es decir desde la base de datos. Imaginemos que necesitamos mostrar información sobre cálculos monetarios relacionados con el Afore de una persona. Para SQL es más natural y sencillo hacer los cálculos de un solo golpe sumando, multiplicando o restando columnas porque toda la información que necesita la tiene a su disposición, mientras que si lo hacemos a nivel de programas hay que pasarles la información para que se vaya procesando una por una.

Modularizar

Imaginemos que estamos desarrollando una página donde se manejan cotizaciones, remesas y comisiones. Sin duda que sería una pagina llena de controles y con bastante código. Es mejor separar las funcionalidades y crear una pagina para el manejo de las cotizaciones, otra pagina para las remesas y otra para las comisiones. O como se diría en lenguaje coloquial: divide y vencerás. A esta técnica se le conoce como modularizacion y hay que tomarla en cuenta no solo para separar páginas, sino también funciones, procesos y módulos en aras de un mejor performance.

Cuando definimos una tabla, variable o constante debemos asignar un tipo de dato que indica los posibles valores que podrá almacenar. Los desarrolladores principiantes pueden verse abrumados por todos los tipos de datos que los manejadores de bases de datos ofrecen y verse tentados a simplemente utilizar dos tipos de datos, el integer para números y varchar para texto. Por ejemplo, si tuviéramos que almacenar valores numéricos del 1 al 10 y utilizáramos el tipo de datos integer, seria como usar la caja de un trailer para almacenar un arete o un anillo. No hay nada más dañino para una aplicación que hacer esto. Si existen diversos tipos de datos es porque cada uno tiene su razón de ser y aplicar los tipos de datos adecuados nos asegurara un mejor rendimiento en nuestra aplicación. Cada RDBMS tiene sus propios tipos de datos, por lo que se recomienda revisar que tipos de datos maneja la base de datos con la que nos toque .BIO trabajar en ese momento. Ricardo Rangel Ramírez es Licenciado

Controlar el uso de flash

Una de las características más molestas de las páginas web es el “flasheo” o “pantallazo” cada vez que sucede algún evento como dar clic en un botón por ejemplo. Los controles de flash solo deben usarse cuando realmente tengan sean necesarios y no haya mejor opción. 45

en Informática egresado de la Universidad de Ecatepec. Ha desarrollado software en plataforma .Net para diferentes empresas. Actualmente labora en el Departamento de Sistemas de Stanhome de México y en proyectos independientes. Sus principales habilidades son la gestión y explotación de información, y el análisis, diseño y desarrollo de sistemas.

Referencias: [1] C. Darie & K. Watson, Beginning ASP. Net 2.0 E-Commerce in C#, Apress, 2006.

Software Guru

Usar tipos de datos adecuados

www.sg.com.mx |

afectar al performance de un sitio web. Imaginemos que estamos desarrollando un carrito de compras. Una mala estrategia seria que por cada producto que agregue el usuario al carrito, lo guardáramos en la base de datos. Esto implicaría obtener una conexión a la base de datos y realizar INSERTs una y otra vez. Ahora multipliquemos esta tarea por decenas o cientos de usuarios que estarían en nuestro sitio al mismo tiempo. Sin duda que el performance de nuestra pagina se vería muy afectado. Una mejor aproximación seria almacenar cada producto que introdujo el usuario en un XML. De esta forma una vez que el usuario confirma la compra, entonces mandamos la cadena XML con todos los productos a un store procedure en SQL que se encargue de leer el XML mediante un cursor e introducir los productos a nuestra tabla, uno a la vez. Para SQL esto implica una sola tarea: ejecutar un store procedure. De esta forma introducimos todos los productos de un solo golpe. Finalmente, volviendo a la estrategia inadecuada: ¿Qué pasa si el usuario se arrepiente y cancela el pedido? Tendríamos que eliminar de la base de datos la información que introdujo. No tiene sentido introducir información para después eliminarla. Además, ¿que pasaría si el usuario simplemente abandona el carrito de compras y nunca le da cancelar? Lo que pasaría es que nos quedaríamos con basura en nuestra base. Por eso es mejor auxiliarse de un XML en estos casos, para manejar de manera elegante y efectiva este tipo de situaciones.

.Fundamentos

››Debido a que las aplicaciones web son muy sensibles a factores externos, debemos prestar atención en el cuidado del performance.

Usar controles ligeros

Si estás usando ASP.Net para desarrollar tus aplicaciones web, dispones de una serie de controles muy buenos para mostrar datos tales como el Gridview, DataList y FormView, pero estos generan bastante código HTML tras bambalinas. El control Repeater es mucho más ligero y en la mayoría de los casos suficiente en términos de funcionalidad.

Limpiar lo que ya no se usa

Cada vez que creemos la instancia de un objeto, después de que lo hayamos usado, hay que especificarle que ya no lo vamos a necesitar. En ASP .Net esto se hace mediante la instrucción objeto = nothing. De esta forma el Garbage Collector se dará cuenta de que ese espacio de memoria que estaba usando el objeto ya no se usa y lo liberara. Un buen lugar para poner esta instrucción es después de la instrucción Finally, la cual garantiza que siempre pasara la ejecución de código por ahí.

Validación del lado del cliente

Siempre será más ligero validar datos del lado del cliente con Javascript que validar datos del lado del servidor, aunque es mas seguro hacerlo del lado del servidor. Quizás podríamos dejar las validaciones del lado del servidor para cuestiones críticas como un número de tarjeta de crédito.

Enviar datos entre páginas con SERVER.TRANSFER

Asp.Net presenta las siguientes instrucciones para navegar y enviar datos entre paginas: Response.Redirect y Server.Transfer. Response. Redirect deberá usarse cuando: • Queramos redirecccionar la petición a paginas HTML en nuestro servidor o algún otro servidor web. • No nos preocupe hacer vueltas adicionales en cada petición al servidor. • No necesitemos preservar la cadena de consulta (Query string) ni las valores de las variables de la petición original. • Queramos que nuestros usuarios puedan ver la URL a donde redireccionemos en su navegador. Server.Transfer deberá usarse cuando: • Queramos transferir una petición de la pagina actual a otro componente en el mismo servidor.

• Queramos evitar innecesarias vueltas al servidor. • Queramos mantener la cadena de consulta (Query string) y las variables. • No necesitemos mostrar la URL verdadera a donde estamos direccionando la petición. Es evidente que Server.Transfer es más eficaz al no dar vueltas innecesarias al servidor, mientras que response.redirect se debe usar solo en ciertas situaciones.

Concatenar cadenas efectivamente

La instrucción para concatenar cadenas de ASP.Net StringBuillder es mas rápida que las técnicas mas rudimentarias como string + string.

Cerrar dentro de finally

Si abrimos una cadena de conexión o algún archivo debemos asegurarnos de volver a cerrarlo al final del método después de la instrucción Finally.

Controlar el uso de try ... catch

La instrucción try-catch es muy buena ya que nos permite atrapar situaciones de excepción. Sin embargo esto no quiere decir que debamos usarlas en todos los métodos. Solo deben de usarse en aquellas situaciones que puedan ser susceptibles de error como al intentar abrir algún archivo o al intentar ejecutar algún comando relacionado con la base de datos. También debemos evitar ser repetitivos a pesar de que la situación lo justifique, por ejemplo si usamos un try-catch en un método, y este método manda llamar a otro, ya no será necesario volver a poner el try-catch de nuevo en el segundo método.

Conclusión

Debido a que las aplicaciones web son muy sensibles a factores externos, debemos prestar atención en el cuidado del performance. En un principio las mejoras pueden parecer imperceptibles, pero conforme aumenta la cantidad de usuarios concurrentes, es donde se ve si la aplicación sigue siendo ágil o se vuelve pesada. Cualquier cosa que descubramos que ayude a mejorar el rendimiento y respuesta de nuestra aplicación siempre será bienvenida.

.PM CORNER

Georeferenciación y Dirección de ››Por Homero Alonso Vela García

eoreferenciar algo es definir su existencia en un espacio físico, es decir su localización bajo la proyección de un mapa mediante un sistema de coordenadas. Existen diversos Sistemas de Información Geográfica (GIS, Geographic Information Systems) tales como ArcMap, PCI Geomática o ERDAS Imagine, los cuales permiten colocar puntos, imágenes, figuras geométricas, y prácticamente cualquier artefacto digital en forma de capas sobre un mapa. En años recientes las APIs de Google, Yahoo y Microsoft para mapeo y geolocalización facilitan la creación de aplicaciones que puedan incorporar estas funcionalidades.

Aplicaciones

Ante la posibilidad de proyectar sobre un mapa con latitudes y longitudes geoespaciales cualquiera de estos objetos, sólo la imaginación es el límite para identificar la gran cantidad de aplicaciones que éstas herramientas pueden tener. Uno de las aplicaciones más populares es la localización de direcciones y el cálculo de distancias entre 2 o más puntos, así como la sugerencia de caminos a tomar para llegar de uno a otro. Sin embargo, hay muchas otras posibilidades, a continuación menciono tan solo algunas: • Distribución y logística. En el ámbito comercial, con estas herramientas se pueden crear rutas de distribución georeferenciando clientes, almacenes, bodegas etc., • Investigación y desarrollo científico. Si hablamos de geociencias podemos plasmar en un mapa las cuadrillas de líneas y puntos a explorar habiendo sido recabada los datos de localización mediantes aparatos de GPS, o bien se pueden georeferenciar los yacimientos de hidrocarburos. • Estudios socioeconómicos. Representar en un mapa las áreas con alto índice de pobreza, o bajo nivel cultural y en función de ello diseñar proyectos para establecer centros educativos, hospitales, etc. • Desarrollo de infraestructura. Imagina visualizar en tomas satelitales la geografía de territorios acrestes para complementar estudios de factibilidad para el desarrollo de carreteras o puentes. • Desarrollo de negocios. Realizar análisis de negocio que permitan obtener información estadística poblacional para identificar dónde conviene más establecer algún punto de venta para un determinado producto. • Localización de recursos estratégicos. No me podría faltar mencionar la localización de autos, tractocamiones, barcos e inclusive personas en un mapa mediante la integración de GPS a un sistema de información geográfica con fines de mejorar el tiempo de respuesta a emergencias o anticipar la entrega de productos y servicios.

Proyectos 8 aplicaciones prácticas

En fin, estos son solo algunos ejemplos y me imagino que ustedes ya habrán pensado en muchas otras áreas de aplicación.

Dirección de Proyectos

Como último punto pero no por ello menos importante, me gustaría centrar su atención del uso de la georeferenciación como herramienta dentro de algunas fases de la dirección de proyectos: Planeación. Sin lugar a dudas en la fase de planeación es una fuerte fuente de información para determinar los riesgos que debemos considerar en el desarrollo y estimaciones de proyectos por ejemplo imaginemos que trabajamos en la planeación de la construcción de un hotel, mediante la georeferenciación podemos deducir las vías de acceso de maquinarias de construcción, la planeación de contratación de mano de obra en esa área, visualizar las características geográficas del lugar para así poder estimar los recursos, tiempos y costos del proyecto entre otras cosas. Monitoreo y control. Durante los procesos de monitoreo podemos combinar la georeferenciación con otros sistemas o tecnologías tales como cámaras de video IP con acceso por internet, para ir supervisando el avance real del proyecto. Por ejemplo: actualmente en varias dependencias gubernamentales se utiliza el monitoreo georeferencial de construcciones tales como presas, acueductos, puentes, etc. mediante cámaras vía IP accedidas desde el mapa de Google o Yahoo. Dando un clic sobre la zona donde se realiza la construcción, fácilmente se pueden identificar los avances sin necesidad de trasladarse.

Conclusión

En mi experiencia les puedo comentar que al aplicar estas herramientas de georeferenciación en diferentes partes de los procesos y/o áreas de una empresa otorga a esta una ventaja competitiva considerable, espero este articulo les haya despertado el interés por conocer más sobre la georeferenciación y las herramientas disponibles para aplicarlas en sus empresas o como servicio a sus clientes. Por cierto voy a ver en el mapa en mi celular donde queda la gasolinera más cercana, y la pizzería que ya hace hambre.

.BIO Homero Alonso Vela García es Ing. en Sistemas Computacionales egresado del Instituto Tecnológico de Nuevo León con más de 13 años en puestos gerenciales. Actualmente se desempeña como gerente de negocios en la representación en México de la compañía americana G&W Systems Corporation. Es miembro del PMI en Houston desde hace 3 años y dentro de sus logros ha fungido como director en la realización de sistemas de georeferenciación, administración de proyectos, administración de contratos, workflows, BPM´s, entre otros. gwhvela@yahoo.com

.COLUMNA Programar es un Estilo de Vida

Arquitecturas de paquetes al rescate convirtiendo a la

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

hidra en nuestra aliada

n el número anterior de SG (SG #27), Agustín Ramos presentó un artículo acerca de estrategias para lograr una modularización efectiva en Java. Varios de los puntos de su artículo me llevaron a dedicar la presente columna a explicar a qué llamamos una distribución de Linux, y cuál es su relación –y la solución que ofrece– a los problemas derivados de la complejidad derivada de la modularización, que bien describió Agustín. Como deben ya saberlo, a diferencia de otros sistemas operativos, el entorno operativo completo al que nos referimos como Linux no es desarrollado por un sólo grupo, ni sigue un roadmap, criterios o visión en común. Mucho se ha argumentado acerca de las características que diferencían a los proyectos de software libre, pero no abordaré dicha discusión en este momento. Simplemente no quiero dejar pasar la oportunidad que abrió el artículo de Agustín, para ilustrar cómo abordamos la relación entre proyectos independientes en el software libre, por qué enfatizamos tanto en lo prevalente que resulta dicha modularización, y cómo nos enfrentamos a su inherente complejidad. Los sistemas basados en Linux son estructurados, pues, en distribuciones. Una distribución es un conjunto de programas –típicamente miles de ellos– que, entre todos, presentan la funcionalidad que un usuario espera ya no sólo de un sistema operativo sino que de todo un entorno operativo integrado. Además, se encargan de gestionar las relaciones de dependencia entre dichos programas, y resolver dichas dependencias, para facilitar al usuario la instalación, remoción y actualización de software. Una instalación mínima de cualquier distribución de Linux no tiene menos de un par de centenares de paquetes individuales. El núcleo Linux, por sí mismo, no representa más que la interfaz más básica para presentar una abstracción del hardware ante los programas que corren sobre él. Formalmente, al mencionar Linux ni siquiera nos referimos a la interfaz de línea de comandos (misma que generalmente es provista por los paquetes bash, dash o sash, dependiendo de

las necesidades del administrador). Son en realidad contados los paquetes que no dependen más que de paquetes esenciales. Toda distribución define un pequeño conjunto (decenas) de programas que es fundamental tener instalados como base para cualquier otro, conjunto mínimo que asumimos que siempre estará ahí para asegurarnos la funcionalidad mínima. Si bien las primeras distribuciones tuvieron por objetivo facilitar la instalación de un sistema basado en Linux a usuarios con menor involucramiento técnico, y fueron instrumentales en la primer ola expansiva de usuarios que fuimos adoptando Linux hacia mediados de los 1990, han trascendido ya a éste rol para dar respuesta al infierno de dependencias al que se refiere en su texto Agustín Ramos: Hacia fines de los 1990, aproximadamente cuando todas las distribuciones comenzaban a contar en miles los paquetes independientes que ofrecían, comenzó a hacerse obvio que no bastaba con que cada paquete indicara de qué otros paquetes y versiones dependía, sino que era necesario contar con una arquitectura de paquetes: un esquema orientado a depósitos y no a paquetes individuales, que se encargara de resolver las dependencias cada que el administrador instalara o eliminara un paquete. La primera arquitectura fue introducida por la distribución Debian, bajo el nombre de apt (A Package Tool). Es gracias a apt que al día de hoy la versión de desarrollo de Debian cuenta con 15640 paquetes fuente independientes, que resultan en 27886 paquetes binarios, cubriendo prácticamente todas las áreas de necesidad en cómputo, tanto a nivel de aplicaciones como de bibliotecas. A diferencia de otras arquitecturas previas, como los ports de los Unixes BSD, apt está además construido basado en el manejo de depósitos múltiples. Esto significa que, además de servirme para instalar los paquetes oficiales de la distribución, nos permite definir depósitos adicionales con el software que desarrollemos localmente, así como de paquetes adicionales que preparemos localmente para uso en nuestra organización. Con esto como introducción, veamos cómo se aplica al texto de Agustín. Por razones de espacio, me enfoco a 48

.COLUMNA

Programar es un Estilo de Vida

“Manejar una

producto de calidad con todas las actualizaciones necesarias para asegurar su seguridad (cuidando no comprometer su estabilidad) durante su ciclo de vida. Este puede ser un punto fundamental al elegir qué distribución vamos a usar para determinado proyecto: Hay distribuciones principalmente orientadas al perfil de usuario de escritorio, para el cual es fundamental tener siempre soporte completo para el último hardware, aceleración gráfica completa y demás bondades. Sin embargo, para basar nuestros desarrollos empresariales, típicamente preferiremos las distribuciones con ciclos de vida más largos, con un mayor soporte a largo plazo. Como pueden ver, manejar una arquitectura de paquetes simplifica algunas de las tareas más complicadas (y más ingratas) del desarrollo de software, el manejo de toda la talacha creada por los componentes que, a fin de cuentas, incluimos para ahorrarnos trabajo. Cuando veo los instaladores típicos, que crean enormes amasijos (típicamente en forma de enormes instaladores .msi o archivos .jar que incluyen copia de todas las dependencias para evitar estos problemas), no exagero: me dan ganas de llorar. Porque además, al tener varias copias de una misma biblioteca en el sistema, tengo la certeza de que en caso de aparecer algún defecto en alguna de ellas, habrá componentes de mi sistema que reciban la corrección en cuestión — pero habrá otros que no. Acostumbrarse al manejo de dependencias externas nos reduce la tentación de acudir al tan temido ligado estático, reduce el peso de nuestras imágenes de instalación (y de nuestros sistemas ya instalados), y contribuye significativamente a mantener un mayor control de calidad en nuestros procesos. Mucha gente evita aprovechar la modularización como medida preventiva para no perder la razón resolviendo dependencias y bugs creados por compatibilidad incompleta entre versiones. Sin embargo, dejar de usar buen software, ya existente y probado por terceros, sólo por no contar con las herramientas de seguimiento correctas es un triste error en el que debemos evitar caer. La hidra de la modularización a la que se refiere Agustín puede ser un mounstro mortal, pero si aprendemos a hablar con ella puede ser nuestro mayor aliado. Porque si dos cabezas piensan mejor que una, ¿qué decir de decenas de cabezas?

››Por Gunnar Wolf 49

www.sg.com.mx |

cómo éste esquema reduce fuertemente los efectos negativos de la modularización, permitiendo a los desarrolladores crear software más robusto y temer menos a esta fuente de dolores de cabeza. Demasiadas dependencias. El argumento principal mencionado en el texto al que hago referencia en contra de tener demasiadas dependencias es la posterior dificultad de instalación de nuestros sistemas. Sin embargo, al crear paquetes que contienen toda la información de las dependencias, convertimos el fastidioso proceso de instalación (y todo el tiempo que requiere documentarlo) en una sóla instrucción al sistema. Dependencias cíclicas. Coordinar el trabajo de cientos de voluntarios en todo el mundo, sin más factores de cohesión que su voluntad por crear un sistema de calidad trae como resultado natural el que parte importante de sus esfuerzos estén encaminados a la creación de documentos de políticas comprehensivos — y a que su comunidad de desarrolladores comprenda la importancia de dichos documentos. Una política esencial es la de prohibir dependencias cíclicas entre paquetes. Sin embargo, conforme la complejidad de cada uno de los paquetes aumenta, es posible que aparezcan dependencias cíclicas indirectas. Para evitar problemas como este, se hacen revisiones periódicas de todos los procesos imaginables. En este aspecto, si bien no hay balas de plata para evitar las dependencias cíclicas, contamos con una comunidad de desarrolladores verificando que estos problemas se mantengan al mínimo. Largas cadenas de dependencias. Este fue precisamente el punto que motivó al desarrollo de las arquitecturas de paquetes. Podemos confiar en que la arquitectura que elijamos, empleando los depósitos del sistema y de nuestra organización, sepan resolver este punto sin que represente problemática alguna. Además, no tenemos por qué limitarnos al uso de este esquema para las dependencias de los componentes externos que empleemos. Si dentro de nuestra organización nos acostumbramos a empaquetar nuestro código en componentes, la reutilización de código que podamos hacer será mucho más simple y natural. Dependencias en conflicto. Nuevamente, aquí acudimos a la sabiduría de las masas, a la fuerza de la multitud. Una distribución basada en Linux no es sólo un conjunto de programas disponibles a través de un mismo depósito, la mayor parte del trabajo de sus creadores es asegurarse que todos los componentes sean mutuamente compatibles y asegurar a los usuarios un

Software Guru

arquitectura de paquetes simplifica algunas de las tareas más complicadas”

.COLUMNA Prueba de Software

Profile Testing

mejorando el

desempeño

no de los requisitos no funcionales más importantes en la actualidad es aquel que se relaciona con el desempeño (performance) de la aplicación en desarrollo. Este tópico ha cobrado aún más relevancia con la creciente tendencia hacia las soluciones web, las aplicaciones distribuidas y el procesamiento en la nube (cloud computing). Sistemas que antes operaban frente a escenarios de algunas decenas de usuarios esporádicos, ahora están expuestos a un uso mucho más intensivo, de varios cientos o miles de usuarios concurrentes.

››El éxito de la prueba estará regido por la pericia en la interpretación de los

resultados obtenidos. Monitoreo del desempeño en diferentes entornos

Mucho se habla de los parámetros que se pueden o deben medir cuando se desea caracterizar el desempeño de una aplicación, ante una carga específica (load testing) o extrema (stress testing); algunos de los más comunes son[1]: • Cantidad de usuarios concurrentes que soporta la aplicación. • Tiempo promedio de respuesta del servidor. • Tiempo promedio de dibujado de una página web (render). • Tasa de ejecución de transacciones. Orlando Ezequiel Rincón es ingeniero de pruebas de caja blanca en e-Quallity. Ha participado como tester senior y líder de proyectos de prueba en proyectos nacionales e internacionales. Orlando tiene Maestría en Ciencias por el CINVESTAV Guadalajara y es profesor de asignatura en el ITESO.

Sin embargo, la mayoría de las veces es insuficiente identificar los escenarios bajo los cuales la aplicación no se comporta dentro de los umbrales deseados; es necesario además aislar el problema para resolverlo de manera apropiada. Ahora bien, realizar esta tarea de manera manual puede llevar días, quizá semanas, y el nivel de certeza sobre dónde corregir es por lo regular muy bajo. Peor aún, imaginemos que nuestra aplicación no está siendo probada en un entorno controlado sino que el desempeño se degrada principalmente en las horas pico en un ambiente de producción que opera 24/7 y el problema requiere solución inmediata.

del software

Pruebas de perfilado – Profile testing

Las pruebas de perfilado (profile testing) se centran precisamente en analizar mediante una herramienta apropiada conocida como profiler, el comportamiento de una aplicación en tiempo de ejecución. La información que se rastrea durante una prueba de perfilado es muy variada, pero suele incluir lo siguiente[2]: • Secuencia, duración y frecuencia de las llamadas a uno o varios métodos dentro del sistema. • Utilización del CPU en un intervalo de medición. • Utilización de memoria: º Cantidad de objetos creados/sección del código don de nacieron. º Instancias vivas, destruidas, y su tiempo promedio de vida. • Utilización de recursos adicionales: º Accesos a disco duro. º Accesos a bases de datos (consultas, procedimientos almacenados, duración de la ejecución). Las herramientas que se utilizan en este tipo de pruebas facilitan la identificación semiautomática de defectos que sería muy complicado encontrar mediante una depuración manual del código fuente o pruebas de caja blanca pues rastrean en todo el código, incluso donde los humanos no revisaríamos en primera instancia. En contraparte, la principal desventaja de las pruebas de perfilado es la sobrecarga que puede llegar a producir, principalmente cuando se aplica a un sistema que se está ejecutando en un ambiente de producción, en el cual el desempeño se verá aún más afectado, al menos mientras se realiza el conjunto de pruebas diseñadas.

Tecnologías apropiadas

Por lo regular este tipo de prueba se aplica a sistemas desarrollados en plataformas de código administrado (aquel que no se ejecuta directamente sobre el sistema operativo, sino que lo hace a través de un ambiente de ejecución, como el bytecode de Java)[3], lo que facilita que el profiler identifique con precisión cuáles secciones del código son potencialmente grandes consumidoras de recursos y, en consecuencia, deben representar un foco de alerta para el equipo de desarrollo. 50

Existe en el mercado una considerable cantidad de herramientas enfocadas al profiling, desde las de código abierto (Netbeans Profiler, JBoss Profiler o SQL Server 2005/2008 Express Profiler), hasta las comerciales de las casas más reconocidas (IBM Rational PurifyPlus, dynaTrace de dynaTrace Software, y HP Diagnostics Software entre otros). Ante la gran variedad de tecnologías disponibles (servidores de aplicaciones, bases de datos, sistemas operativos, arquitecturas de hardware, etc.) la elección de una de estas opciones dependerá en buena medida de las particularidades del sistema que se esté probando y el éxito de la prueba estará regido por la pericia en la interpretación de los resultados obtenidos.

El ingeniero de pruebas de perfilado

Aunque hasta ahora nos hemos enfocado principalmente en las herramientas, la intervención humana respecto a la administración y ejecución de las pruebas de perfilado es determinante. Quien se encuentre a cargo de la prueba deberá ser capaz de realizar las siguientes actividades como parte del proyecto: • Elaborar y dar seguimiento a planes de prueba. • Diseñar y preparar escenarios de prueba. • Identificar las herramientas adecuadas de acuerdo a las necesidades del interesado y del proyecto. • Implementar scripts que ejerciten el sistema simulando cargas de cientos o miles de usuarios. • Listar las zonas susceptibles de ser optimizadas, considerando los recursos disponibles y las prioridades del proyecto.

stress, sistemas operativos, servidores de aplicaciones, servidores de bases de datos. • Desarrollo de software. Todo lo anterior, para cubrir de manera adecuada las expectativas de la prueba de perfilado y entregar resultados apropiados de acuerdo a la complejidad de la misma.

Conclusiones

En esta ocasión hemos hablado sobre un tipo de prueba que, aunque no es del todo nueva, ha sido poco difundida en el mercado mexicano: el profiling o prueba de perfilado, que permite identificar debilidades que serían muy difíciles de encontrar eficientemente con otros métodos, a través del análisis de porciones del código fuente que eventualmente representan cuellos de botella en la aplicación. Asimismo, el profiling es susceptible de ser aplicado tanto a sistemas en producción como a sistemas en fase de desarrollo, lo cual incrementa su utilidad, especialmente cuando el desempeño del sistema es un requerimiento crítico. En la actualidad, es viable considerar este tipo de prueba, para ser aplicada en desarrollos sobre plataformas recientes, se cuenta con herramientas de costos variados y dentro de ellas se cubre la mayoría de las tecnologías más usadas.

››Por Orlando Ezequiel Rincón

Referencias [1] “Software Performance Testing”. Wikipedia. http:// bit.ly/Y0CNT [2] V. Popescu. “Java Application Profiling using TPTP”. Eclipse Organization. http://bit.ly/V1KOS [3] O. Esqueda. “Código Administrado y No Adminis-

Para ello, el ingeniero de pruebas involucrado en este proyecto deberá estar capacitado en las siguientes áreas: • Administración de proyectos. • Metodologías de prueba. • Herramientas: simulación de carga y/o

trado. Una Visión General”. Software Guru, Año 3, No. 6. http://bit.ly/9sx60Z [4] S.Gupta. “Need for speed. Eliminating performance bottlenecks”. IBM Developerworks. http://bit. ly/9SMgUV [5] Eclipse Profiler Plugin. http://bit.ly/awE6fd

.TECNOLOGÍA Infraestructura

Manual Sobre Cloudbursting ››Por Patricio Dueñas

l término cloudbursting fue acuñado por Jeff Barr, evangelista de Amazon Web Services, para describir el uso del “cloud computing” para sortear solicitudes de desbordamiento, como los que ocurren en temporadas de máxima actividad en las tiendas en línea. En lugar de invertir en hardware, software y personal adicionales para escalar y manejar el sinnúmero de piezas de infraestructura necesarias para incrementar la capacidad para aplicaciones Web, el enfoque cloudbursting le permite aprovechar la nube para incrementar la capacidad bajo demanda.

El enfoque cloudbursting permite efectivamente a las organizaciones tratar la nube como un centro de datos secundario. Mantienen y controlan su infraestructura y sus aplicaciones al tiempo de aprovechar la capacidad de las nubes de expandirse y contraerse de forma dinámica, lo que hace financieramente viable utilizar recursos adicionales de manera periódica sin una inversión cuantiosa.

más bien simple, pero como suele ser el caso, problemas con las aplicaciones como la replicación y la duplicación de datos hacen que todo el proceso sea más difícil, sino es que imposible, para algunas aplicaciones. Aunque las bases de datos se pueden replicar en tiempo real a través de Internet, esto sólo es viable si tiene un enlace de alta velocidad y baja latencia entre el centro de datos y el proveedor de la nube. Esto significa que la mayoría de las organizaciones no podrán aprovechar la replicación en tiempo real, o configuración espejo, para atender problemas de replicación y duplicación de datos. Un escenario más probable es que se necesitará mantener la versión de los datos en la nube lo más actualizados que sea posible y replicarlos con regularidad. Cuando ya no se necesite la instancia de la aplicación en la nube, los datos se necesitarán combinar con la base de datos local a través de la importación o reproducción de registros de transacciones. Algunos desarrolladores han resuelto este problema implementando aplicaciones de replicación propias que desencadenan actividad en la base de datos y utilizan servicios Web para replicar los datos de vuelta al centro de datos local. Estas soluciones no son perfectas y presentan el riesgo de incurrir en intervención manual para borrar los datos cuando éstos se reintroducen. La integración con otras aplicaciones está plagada también de dificultades. Una regla general es que cuanto más integrada es una aplicación, menos probable es que sea candidata para cloudbursting. Las aplicaciones más adecuadas para cloudbursting son aquellas con muy poca integración con otras aplicaciones y cuyos datos no provienen de transacciones.

¿Cuál es la recompensa?

¿Cómo funciona?

El enfoque “cloudbursting” contempla dos problemas básicos: 1. Las compañías requieren periódicamente de capacidad adicional, pero el retorno de la inversión en infraestructura para el manejo de cargas máximas es excesivamente largo porque la capacidad extra sólo se utiliza en ocasiones. 2. Las compañías dudan trasladar toda la infraestructura a un proveedor de computación en nube por razones de seguridad y estabilidad. Aunque el enfoque “cloudbursting” no elimina dicha exposición, si hay un problema con la nube no se desencadena el desastre que ocurriría si la nube se encargara de todo.

Los requisitos reales de la red y de la infraestructura de entrega de aplicaciones son bastante directos y están basados en métodos existentes bien entendidos para la implementación del balance de carga global. Esto hace que el enfoque cloudbursting parezca

Siempre que tenga una aplicación que se adapte a los requisitos, el enfoque cloudbursting funciona como un sistema de balanceo de la carga global, distribuyendo solicitudes a través de múltiples instalaciones de centros de datos. El sistema de balance de 52

.TECNOLOGÍA

Infraestructura

››El

¿Cómo lo hacen?

Aunque esto suena muy simple, existen varias piezas de la infraestructura que necesitan estar en su sitio para poder implementar con éxito una estrategia de cloudbursting: 1. Debe tener la aplicación implementada y disponible dentro de la nube. Quizá sea posible implementar aplicaciones on-demand con el proveedor de computación en nube, pero es probable que la mayoría de los proveedores requieran que la aplicación haya sido implementada antes de que se necesite. 2. Debe tener un sistema de balanceo de tráfico global (Global Traffic Manager) capaz de decidir cuándo dirigir solicitudes a uno o mas sitios alternos. 3. Debe tener una forma de determinar cuándo se acerca a su máxima capacidad su infraestructura de aplicaciones. Un controlador de entrega de aplicaciones (Application Delivery Controller) es el mecanismo más eficiente para llegar a esta determinación.

Conclusión

El cloudbursting es un nuevo giro en una arquitectura bastante conocida. La diferencia entre cloudbursting y el balanceo global de tráfico tradicional a través de múltiples centros de datos está en el uso de la nube y en los ahorros que logran las organizaciones que aprovechan el enfoque de cloudbursting en vez de construir su propia infraestructura. Esta estrategia también puede ser un método eficiente de ayudar a la escalada de sitios de rápido crecimiento en los que la tasa de aumento del tráfico supera la capacidad de la organización de TI de obtener, preparar e imple.BIO mentar una infraestructura. Y el Patricio Dueñas es Country Manager de F5 Networks enfoque cloudbursting se puede extender también como un plan de recuperación de desastres Más información en: [1] “Cloud Balancing, Cloud Bursting para reducir los costos asociados and Intercloud”, Dev F5 Central. con la construcción y el mantehttp://bit.ly/sg28r7 nimiento de un centro de datos secundario inactivo. 53

Software Guru

El punto al que me refiero con “en la máxima capacidad o cerca de ésta” para su organización podría basarse en una métrica como el tiempo de respuesta de la aplicación, conexiones concurrentes o carga agregada en el servidor, o bien pudiera ser una combinación de factores. Básicamente, usted determina el umbral en el cual desea que sus visitantes y clientes accedan a la nube y no la instancia local de su aplicación. Esta información es necesaria para configurar correctamente su controlador de entrega de aplicaciones de modo que se pueda comunicar con el sistema de balanceo de tráfico global de manera oportuna y comenzar a redirigir el tráfico antes de que la transaccionalidad se torne crítica.

www.sg.com.mx |

la carga tiene la tarea de monitorear el centro de datos local y determinar cuándo se aproxima a su uso máximo; entonces debe turnar solicitudes a un centro de datos secundario que es, en este caso, un proveedor de computación en nube. La instancia de la aplicación Web en la nube se pone entonces en línea y comienza a atender a los visitantes. La forma en que la nube realiza esta tarea depende ampliamente del modelo de implementación que utilice el proveedor; pero suponemos para los fines de esta exposición que la aplicación está implementada y disponible en el sitio del proveedor de la nube. El sistema de balanceo de carga continúa monitoreando el centro de datos local y redirige solicitudes en tanto que el volumen sea lo suficientemente elevado para llevar a la aplicación local por arriba de su capacidad. Cuando el tráfico disminuye, el sistema de balanceo de carga deja de remitir visitantes a la nube, la aplicación en ésta entra en inactividad y eventualmente se pone fuera de línea.

enfoque cloudbursting permite efectivamente a las organizaciones tratar la nube como un centro de datos secundario.

.TECNOLOGÍA Gadgets

Bravia 3D Sony

La moda de la tercera dimensión comienza a entrar en su máximo auge y por ello Sony ha diseñado una plataforma completa de entretenimiento que explota la nueva tecnología de imagen. Creada para desplegar video de alta definición (1080p) en 3D, la nueva línea de televisiones Bravia será lanzada en nuestro país en el transcurso de julio. Esta tecnología muestra imágenes de 1920x1080 pixeles para cada ojo y es completamente compatible con el resto de productos Sony con capacidad 3D, como reproductores Bluray y videojuegos de PlayStation 3, entre los que se incluyen WipeOut HD y MotorStorm: Pacific Rift, disponibles también en tercera dimensión. Además de las acostumbradas funciones de navegación en internet que incluyen estas pantallas, la serie KDL-NX y KDL-HX dispondrá de conexión Wi-Fi además de sensores de luz y movimiento para una experiencia más completa. Estos equipos estarán disponibles en dimensiones de 40 a 55 pulgadas.

Proyector de bolsillo

M150

Si estás cansado de estar cargando con un pesado proyector cada que visitas a un cliente, te dará enorme gusto saber que la categoría de los proyectores de bolsillo, o pico projectors como son llamados en norteamérica, está madurando rápidamente y ya cuenta con opciones muy atractivas. Una de ellas es el nuevo proyector portatil MPro 150 de la empresa 3M. El MPro 150 ofrece un conjunto de funcionalidad bastante robusto, combinando diversas aplicaciones en un dispositivo compacto y sencillo de usar. El MPro 150 incluye 1 GB de memoria interna, ranura para tarjetas micro SD, y entrada USB para transferir archivos desde una computadora. Puede abrir y proyectar archivos de Microsoft Office (Word, Power Point y Excel), así como PDF, fotos y video en distintos formatos. Mide poco más de 12 centímetros de largo y tienen un peso cercano a los 2.5 kg. Sus 15 lúmenes no le permiten proyectar a gran distancia, pero para una presentación con pocas personas es más que suficiente.

MIT

Guantes de licra Posiblemente te preguntes que tienen de especial estos guantes, si están hechos a base de algún polímero conductor, contienen sensores especiales, o qué. La realidad es que son unos guantes de licra comunes y corrientes. No tienen nada especial más allá de su colorido diseño, el cual facilita el reconocimiento de gestos (gestures) por medio de una webcam. El reconocimimento de gestos con las manos por medio de web cams no es nada nuevo. Sin embargo, la clave aquí es que gracias a que los guantes usan colores distintivos para las diferentes zonas de las manos y dedos, es posible hacer reconocimiento de alta precisión en tiempo real sin necesidad de mucho poder de cómputo. La tecnología está siendo desarrollada por investigadores del MIT. Esta institución se está convirtiendo en líder en el campo de reconocimiento de gestos (gestural computing). Hace unos meses, otro investigador de MIT llamó la atención con un dispositivo llamado “SixthSense” que reconoce gestos sencillos y en base a éstos despliega información por medio de un proyector portátil. Si no eres fan de la psicodelia y crees que te costaría trabajo ponerte algo tan colorido, no te preocupes. Este concepto también se puede aplicar utilizando materiales que contengan patrones fácilmente reconocibles por computadoras pero que para el ojo humano parezcan uniformes. 54

Directorio Cutter

Pág.51

www.cutter.com.mx

Embarcadero

Pág.09

www.embarcadero.com

Gameworkshop

Pág.3F

www.gameworkshop.com.mx

IDC

Pág.39

Itera www.iteraprocess.com

Pág.07

Roca Sistemas www.roca-sistemas.com

Pág.35

Servetia

Pág.15

www.idc.com

www.servetia.com

TENEMOS UN ESPACIO RESERVADO PARA TI SG se distribuye de manera impresa en la República Mexicana, y de manera digital llega a más de 25mil lectores de habla hispana. El anuncio en la revista digital cuenta con hiperliga directa a tu sitio web, lo que te dará la oportunidad de acercarte a nuevos clientes. “Es una gran oportunidad participar con Software Guru, pues comprobamos que es un medio efectivo.” Novalys Latinoamérica Contáctanos en el (55) 5239.5502 o en publicidad@sg.com.mx

.CARRERA

La Práctica Adecuada hace al Joven Maestro

la experiencia esta en el practicar ››Por Adalberto González

eguramente habrán escuchado frases como: “¡cuento con 40 años de experiencia!”, comentadas con el propósito de sugerir que alguien con menos años no está en el mismo nivel, pues se cree que el tiempo es lo que distingue entre un joven “Padawan” y un buen “Jedi”. Pero esto no es precisamente una verdad absoluta. Por ejemplo, podemos presenciar a 2 jugadores de ajedrez, un veterano con 20 años en la materia y otro con 5 años en su haber, lo que aparentaría ser una desventaja en el tablero. Sin embargo la diferencia en su habilidad como jugador es prácticamente nula. ¿Es esto posible?, ¡seguro que sí! Hay quien diría que es obra de la casualidad encontrar a profesionales en toda la extensión de la palabra con relativa poca experiencia, pero no es así, no hay nada mágico. Así pues la creencia de que la experiencia solo se obtiene con los años parece ser un error de concepto que contrasta con la realidad, dado que una acción fundamental para la experiencia no está solo en el paso del tiempo si no en practicar. Pero no todas las prácticas devuelven resultados que valgan la pena, se requiere practicar escenarios concretos que generen enseñanzas de valor, con la finalidad de incrementar las posibilidades de lograr aciertos al momento de tomar decisiones. Un futbolista de elite, practica las habilidades que necesita afinar; un jugador semi-profesional en contraste, practica las habilidades que ya domina. Mientras que los jugadores “llaneros” tienden a pasar gran parte del tiempo de juego socializando. Pon a los tres a practicar el mismo intervalo de tiempo y obtendrás diferentes resultados puesto que cada uno practicó de un modo distinto. Usar el tiempo sabiamente, adicional al cómo practicar es lo que logrará mejores resultados. .BIO Adalberto Gonzalez Ayala es consulCuando Jimy Hendrix apator Six Sigma Black Belt en Softtek. Entre sus funciones se encuentra el reció en la escena musical se creía mentoreo y ejecución de mejoras de negocio para proyectos especiales. que su habilidad seria insuperable. adalberto.gonzalez@softtek.com Hoy día muchas bandas de garage tienen guitarristas con incluso mejores destrezas (esto por supuesto

no demerita el lugar de Hendrix en la historia). Lo mismo sucede en los negocios, los deportes, la política o la programación: se trata de practicar, pero no todo el día, si no el tiempo correcto y en lo que es fundamental.

››Se requiere

practicar escenarios concretos que generen enseñanzas de valor. Me refiero a que, es más importante el recibir constante e inmediata retroalimentación que guíe nuestro desempeño, a estar practicando sin estar seguros de que lo que hacemos nos traerá buenos resultados. Tal vez para cuando te enteres del “cómo vas” será algo tarde. Un modelo de práctica notable lo encontramos en el ajedrez, donde los jugadores con miras a volverse profesionales pasan unas cuatro horas comparando sus jugadas con aquellas publicadas de los mejores jugadores en el mundo. El jugador principiante ejecuta su mejor movimiento y luego lo compara con lo que hizo el experto. Cuando el movimiento del principiante es distinto al del experto, el principiante toma una pausa para analizar y determinar qué es lo que no vio (aquí es muy importante el analizar, no se trata de copiar, si no de aprender a entender el porqué del experto). Como resultado de compararse así mismo con el mejor jugador, este principiante mejora sus habilidades muchísimo más rápido de lo que le tomaría el esperar que la vida le presente el escenario adecuado o simplemente al practicar de otra manera. Las personas aprenden rápido cuando por retroalimentación descubren donde están fallando y por su puesto, de sus propios aciertos (y errores) en la vida. Aquí la diferencia radica en que una tomará menos tiempo. Algo así como ser un profesional con habilidades en “concentrado” o “diluido”. Ayuda a tu equipo. Ayuda a aquellos jóvenes a desarrollar sus habilidades lo más rápido posible y de la mejor manera. Comparte con ellos el porqué de tus decisiones, y trabaja con ellos escenarios concretos que permitan que tu equipo sea capaz de aprovechar esas habilidades en el trabajo. Muchos de nosotros no vamos como el llanero solitario, siempre trabajamos en equipo, y estoy seguro de que nuestro trabajo será mejor si contamos con buenas prácticas. 56