SG #28

La Práctica Adecuada hace al Joven Maestro

Anonymous — Wed, 16 Jun 2010 01:10:01 +0000

La Práctica Adecuada hace al Joven Maestro

Anonymous Tue, 06/15/2010 - 20:10

Publicado en

SG #28

Carrera

Autor

Adalberto González

Seguramente 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. Cuando Jimy Hendrix apareció en la escena musical se creía que su habilidad seria insuperable.

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. 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.

Bio

Adalberto Gonzalez Ayala es consultor Six Sigma Black Belt en Softtek. Entre sus funciones se encuentra el mentoreo y ejecución de mejoras de negocio para proyectos especiales. adalberto.gonzalez@softtek.com

Manual Sobre Cloudbursting

Anonymous — Wed, 16 Jun 2010 01:09:33 +0000

Manual Sobre Cloudbursting Anonymous Tue, 06/15/2010 - 20:09

Publicado en

SG #28

Infraestructura

Autor

Patricio Dueñas

El 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” 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.

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.

¿Cuál es la recompensa?

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 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.

¿Cómo funciona?

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 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.

¿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.

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.

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 implementar una infraestructura. Y el enfoque cloudbursting se puede extender también como un plan de recuperación de desastres para reducir los costos asociados con la construcción y el mantenimiento de un centro de datos secundario inactivo.

Más información en:

[1] “Cloud Balancing, Cloud Bursting and Intercloud”, Dev F5 Central. http://bit.ly/sg28r7

Bio

Patricio Dueñas es Country Manager de F5 Networks

Desarrollo de Aplicaciones Web de Alto Performance

Anonymous — Wed, 16 Jun 2010 00:50:16 +0000

Desarrollo de Aplicaciones Web de Alto Performance Anonymous Tue, 06/15/2010 - 19:50

Publicado en

SG #28

Fundamentos

Autor

Ricardo Rangel

Ante 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 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.

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.

Usar tipos de datos adecuados

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 trabajar en ese momento.

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.

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

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

Bio

Ricardo Rangel Ramírez es Licenciado 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

Georeferenciación y Dirección de Proyectos

Anonymous — Wed, 16 Jun 2010 00:06:39 +0000

Georeferenciación y Dirección de Proyectos Anonymous Tue, 06/15/2010 - 19:06

Publicado en

SG #28

Autor

Homero Alonso Vela

Georeferenciar 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. 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

Alonso Vela 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[at]yahoo.com

Emprendedores e Innovación: Qué, cómo y por qué

Anonymous — Wed, 16 Jun 2010 00:06:21 +0000

Emprendedores e Innovación: Qué, cómo y por qué Anonymous Tue, 06/15/2010 - 19:06

Publicado en

SG #28

Emprendiendo

Autor

Hugo Stevens

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.

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

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).

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.

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.”

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.

Referencias:

P. Drucker, Innovation and Entrepreneurship. Collins, 1993.
P. Graham, “How to start a startup”. http://www.paulgraham.com/start.html
P. Graham, “Six principles for making new things”. http://www.paulgraham.com/newthings.html
J. Mullins & R. Komisar, Getting to Plan B. Harvard Business Press, 2009.

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

Profile Testing

Anonymous — Tue, 15 Jun 2010 23:11:47 +0000

Profile Testing Anonymous Tue, 06/15/2010 - 18:11

Publicado en

SG #28

Prueba de Software

Autor

Uno 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.

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.

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.

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.

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.

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 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.

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 Administrado. 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

Bio

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.

Arquitecturas de paquetes al rescate

Anonymous — Tue, 15 Jun 2010 22:32:29 +0000

Arquitecturas de paquetes al rescate Anonymous Tue, 06/15/2010 - 17:32

Publicado en

SG #28

Programar es un Estilo de Vida

Autor

Gunnar Wolf

En 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 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 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?

Bio

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

La nube empresarial ya está disponible

Anonymous — Tue, 15 Jun 2010 21:52:55 +0000

La nube empresarial ya está disponible Anonymous Tue, 06/15/2010 - 16:52

Publicado en

SG #28

Autor

Luis Daniel Soto Maldonado.

Analicemos 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.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. Algunos 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.

Bio

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

El Camino del Cambio

Anonymous — Tue, 15 Jun 2010 21:15:14 +0000

El Camino del Cambio Anonymous Tue, 06/15/2010 - 16:15

Publicado en

SG #28

Mejora continua

Autor

Luis Cuellar

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:

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 dependedel 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.

Bio

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

Certificación de Profesionales en Ingeniería de Software

Anonymous — Tue, 15 Jun 2010 20:54:50 +0000

Certificación de Profesionales en Ingeniería de Software Anonymous Tue, 06/15/2010 - 15:54

Publicado en

SG #28

Tejiendo nuestra red

Autor

Hanna Oktaba

En 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.

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 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. 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-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?

Bio

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