Programadores famosos

En un interesante post aparecido en el blog grok-code, se hace una análisis de que ha convertido a 222 seres humanos en programadores famosos, para ello se uso como base la lista de programadores famosos que aparece en wikipedia, y se analizaron las razones de por qué han logrado esa posición de super-estrellas de la cultura geek.

De los 222 programadores famosos estudiados y los 400 proyectos de software que desarrollaron, se han extraído algunas interesantes conclusiones, la primera es que sólo el 23% de ellos se han hecho famosos por desarrollar un lenguaje de programación, dentro de este grupo están por ejemplo James Gosling (Java), Alan Kay (SmallTalk) y Guido van Rossum (Python). Por otro lado de los 222 programadores famosos 97.07% han sido hombres, lo cuál es un dato interesante, aunque hay mucha mujeres en el campo de las TICs, estas no han alcanzado de manera proporcional a su número el estatus de programador famoso.

Otro dato importante es en cuantos proyectos de software uno debe participar para ser famoso, la respuesta es que basta con uno, de acuerdo a las estadísticas, el 53.36% de los programadores famosos sólo han intervenido en un proyecto de software, por ejemplo ese es el caso de Bill Gates, que sólo recibe el crédito por haber co-participado junto a Paul Allen, en el desarrollo del BASIC para el Altair. Aunque los hay prolíficos también, por ejemplo Lou Montulli ha recibido el crédito por haber creado el navegador Lynx, haber inventado las cookies, el tag de blink, la tecnología de server push y client pull, el proxy HTTP, el HTTP sobre SSL, la integración de los gráficos GIF dentro de los navegadores y haber fundado el grupo de trabajo de HTML en el W3C.

La verdadera historia del Internet

Este documental realizado por Discovery Channel trata sobre como empezó la Internet, la revolución tecnológica, cultural, comercial y social que ha cambiado radicalmente nuestras vidas de hoy en día.

Cuenta las historias increíbles de los fundadores de eBay, Yahoo, Amazon, Netscape, Google y muchos otros de como en estos 10 años la Internet ha tomado un lugar muy importante en nuestras vidas.

Carta de Melinda

A mi adorado Esposo,

Te estoy enviando esta carta en un falso diskette de demostración de software para asegurarme de que la leas. Por favor perdona mi engaño, pero pensé que deberías saber lo que ha estado aconteciendo en casa desde que tu ordenador entró en nuestras vidas hace dos años.

A los niños les está yendo bien. Tomasito ya tiene siete años y es un muchachito buenmozo. Ha desarrollado gran interés por las artes. Dibujó un retrato familiar para un proyecto del colegio y todas las figuras eran buenas pero la tuya fue excelente! La silla y tu espalda son tan realistas... deberías estar orgulloso de él.

La pequeña Jennifer cumplió 3 en Septiembre. Se parece bastante a tí cuando tenías esa edad. Es una niña atractiva y bastante lista. Ella aún recuerda que tú pasaste una tarde entera con ella en su cumpleaños; qué día tan fantástico fue para Jenny, a pesar de que había tormenta y se fue la luz.

A mí tambien me está yendo bien. Me teñí el pelo de rubio el año pasado y me fascinó descubrir que las rubias en verdad se divierten más! Larry, quiero decir, el Sr. Swenson, el jefe de mi departamento, ha tomado interés personal en mi carrera y se ha convertido en un verdadero amigo para todos nosotros.

He descubierto que las tareas del hogar son más fáciles desde que me dí cuenta de que no te importa que te pase la aspiradora por encima en vez del plumero que te hace estornudar.

La casa está en buen estado. La primavera pasada hice pintar el salón y el estudio, no estoy segura si lo notaste. Antes de cubrir los muebles me aseguré de que los pintores hicieran agujeros en los trapos para que pudieras respirar y no te incomodaras.

Bueno, cariño, ya tengo que irme. Tío Larry, quiero decir el Sr. Swenson, nos va a llevar a todos a esquiar y tenemos que hacer las maletas. Contraté a un ama de llaves para que se encargue de las cosas mientras estamos fuera, y ella mantendrá todo en orden: llenará tu taza de café, y traerá tus comidas al escritorio, tal y como te gusta. Espero que tú y el ordenador lo paséis estupendamente durante nuestro viaje.

Tomacito, Jenny y yo pensaremos en tí a menudo. Trata de acordarte de nosotros entre booteos.

Te ama,

Melinda (tu esposa)

Autoría:Dan Harman.Traducido de PcNET GUIDE, (FL)

¡Abraza un programador!

Un video que plasma la cruda realidad de la mayoría de proyectos de desarrollo informático, que al final conllevan a que no se cumplan los plazos y presupuestos asignados al proyecto. Algunas de las frases que se

Ya han pasado 4 de los 5 meses del plan del proyecto y recién ayer he recibido las especificaciones finales… (y, naturalmente, ¡han cambiado de nuevo!)

Me paso media vida de reunión en reunión sobre cómo trabajar de forma más productiva (en vez de estar trabajando).

Mi jefe leyó en una revista que los desarrolladores que usan el lenguaje de programación «_______» son el doble de productivos. Así que nos compró una copia y redujo el tiempo para acabar el proyecto a la mitad.

Cada día mi jefe cambia su concepción acerca de lo que estamos construyendo.

La gente no deja de pedirme que le arregle el correo, así que no tengo tiempo para programar código.

El 35% de las PCs con Vista terminan con XP

Según un estudio realizado por Devil Mountain Software, el 35% de las PCs que son compradas con Windows Vista, terminan pasandosé a Windows XP en algún momento.
Principalmente, los usuarios hacen esta des-actualización porque Windows XP es mucho más rápido y consume muchos menos recursos que el Vista, y por ende los usuarios prefieren la versión anterior, ya que la nueva no tra nada nuevo (Valga la redundancia) y consume mucho más.

Esto es un fracaso para Microsoft, pero creo que estuvo muy bien sabido desde que se lanzó el Windows Vista que todo iba a ser así...

Entrevista a Richard Stallman

Video de una entrevista al inventor del Sistema GNU y fundador de la Free Software Foundation, RICHARD M. STALLMAN, exponiendo las ventajas del Software Libre.

Historia del Linux

Linux (también conocido como GNU/Linux) es un sistema operativo tipo Unix que se distribuye bajo la Licencia Pública General de GNU (GNU GPL), es decir que es software libre. Su nombre proviene del Núcleo de Linux, desarrollado desde 1991 por Linus Torvalds.

Aqui uno de los documentales sobre GNU/Linux más vistos en los últimos años en la web via google.

¿Porqué fallan los proyectos informáticos?

La gran cantidad de proyectos cancelados todos los años nos dice que algo funciona muy mal en la ingeniería informática. ¿Qué es?

Según una encuesta del 2004, el 71 por ciento de los proyectos de sistemas terminan fracasando. ¿Cuál es el problema con el IT y cómo resolverlo?

En 1985 un grupo de profesionales de West Yarmouth, Massachussets creó el Standish Group con una visión: obtener información de los proyectos fallidos de IT. El objetivo: encontrar (y combatir) las causas de los fracasos.

Con el tiempo, la seriedad y el profesionalismo del Standish Group lo convirtieron en un referente mundial sobre los factores que inciden en el éxito o fracaso de los proyectos de IT. Sus análisis apuntan fundamentalmente a los proyectos de software y se aplican tanto a los desarrollos como a la implementación de paquetes (SAP, Oracle, Microsoft, etc.)

A lo largo del tiempo, el Standish Group relevó 50.000 proyectos fallidos. Así, sus conclusiones nos brindan interesantes pistas sobre dónde poner el foco para mejorarlos. Veamos lo que ocurrió en la última década...

En 1994, el 31 por ciento de los proyectos fueron cancelados. El 53 por ciento registró enormes desvíos en presupuesto y en cronograma. Sólo el 16 por ciento se completó en tiempo y dentro de los costos presupuestados (apenas nueve por ciento en el caso de grandes empresas). Para colmo, de la funcionalidad comprometida sólo se cumplió, en promedio, con el 61 por ciento (42 por ciento en grandes empresas).En vista de estos fracasos, durante los últimos diez años, la industria invirtió varios miles de millones de dólares en el desarrollo y perfeccionamiento de metodologías y tecnologías (CMMI, ITIL, SOA, etc.) destinadas a mejorar la administración y productividad de los proyectos de software. ¿Sirvieron estas inversiones? Veamos los resultados de la encuesta del 2004...

La buena noticia: los proyectos exitosos crecieron al 29 por ciento. La mala noticia: los proyectos fracasados representan el 71 por ciento.

¿No es aterrador? Siete de cada diez proyectos se cancelaron o registraron desvíos del 45 por ciento sobre lo presupuestado en costos y del 63 por ciento de lo previsto en tiempos. Por otro lado, apenas se cumplió con el 67 por ciento de la funcionalidad comprometida.

Según el informe de Standish las diez principales causas de los fracasos son las siguientes (por orden de importancia):

1) Escasa participación de los usuarios finales (12,8%): El usuario es quien finalmente evaluará y aprobará o desaprobará el proyecto terminado. Por eso siempre se debe siempre de involucrar al usuario en la definición del proyecto y en los subsiguientes pasos. Se deben establecer canales y vías de comunicación constante con el usuario para poder brindarle la mayor información posible del avance del proyecto, para que éste pueda valorarlo y dar su feedback, que es la base para hacer los reajustes sin algo no estuviese del todo bien.

2) Requerimientos y especificaciones incompletas (12,3%): La ingeniería de requerimientos cumple un papel primordial en el proceso de producción de software, ya que enfoca un área fundamental: la definición de lo que se desea producir. Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento del sistema; de esta manera, se pretende minimizar los problemas relacionados al desarrollo de sistemas.

La ambigüedad ayuda a generar falsas expectativas y provoca enormes pérdidas de tiempo cuando lo que se implementa es la solución equivocada.

3) Cambios frecuentes en los requerimientos y especificaciones (11,8%): Durante el proceso de construcción de un sistema de información es común encontrarse con usuarios ávidos en añadirles nuevas funcionalidades o características al mismo. Esto se constituye en un factor peligroso ya que el equipo de desarrollo podría perder días, semanas y hasta meses valiosos haciendo algo que al usuario inicialmente no especificó. Los requerimientos de los usuarios tienen contienen generalmente muchas ambigüedades, malos entendidos, inconsistencias y omisiones.

4) Falta de soporte ejecutivo (7,5%): Todo proceso de cambio tecnológico genera cierto grado de oposición en las organizaciones. En este sentido los funcionarios de mayor rango deben estar comprometidos con este proceso y este compromiso debe ser transmitido a los demás miembros de la organización.

5) Incompetencia tecnológica (7,0%): La incompetencia tecnológica proviene de la resistencia, psicológica o cultural, de los usuarios para modernizar sus procedimientos de trabajo, roles y obligaciones organizacionales.

6) Falta o recorte de recursos (6,4%): La asignación de recursos humanos y materiales suele ser, en la práctica, uno de los aspectos que mas complicaciones produce en un proyecto. La definición y asignación de recursos implica de hecho prever tres elementos:

• Qué tipo de recursos se van a usar
• En qué cantidad
• Durante cuanto tiempo

La mayoría de proyectos grandes que fracasan lo hacen porque se reducen sutilmente todos los recursos necesarios para llevarlos a cabo. Cualquier albañil sabe que hay una proporción correcta entre cal y cemento y que no se puede quitar un 5% de hierro a un edificio porque los precios del acero se hayan disparado. En informática, en cambio, es normal contratar un profesional de 3 años en experiencia en el puesto de uno de 5. No importa convertir 9 meses en 8 o US$100.000 del presupuesto en US$90.000. Se van metiendo pequeños recortes por todas partes, un poco de cada lado hasta que se arruina cualquier posibilidad de éxito

7) Expectativas no realistas (5,9%): Comparta toda la información posible con sus clientes, evitando el uso de la jerga técnica, y ayude a los clientes en la descripción de sus necesidades.

Aclare las percepciones de sus clientes y explicite las limitaciones de manera frontal y honesta.

8) Objetivos poco claros (5,3%): Un principio básico en la gestión de proyectos es que los objetivos estén definidos a priori y con un grado de suficiente de claridad y precisión. Los objetivos generalmente son: el resultado , el costo y el plazo del proyecto. Estos tres objetivos son inseparables y forman un sistema en el que cada modificación de cada una de las partes afecta a las restantes. Dado que la maximización individual de los tres criterios básicos no es posible, es necesario maximizar una cierta combinación entre ellos.

9) Cronogramas irreales (4,3%): Se deben estimar plazos realistas para cada una de las etapas del proyecto teniendo en cuenta los recursos disponibles. Es frecuente que los plazos se definan sin criterios técnicos

10) Nuevas tecnologías (3,7%):

Observemos que de los diez factores mencionados, siete están referidos a factores humanos (1 a 4 y 7 a 9). Si bien algunas de las metodologías cubren temas de comunicación, manejo de conflictos y negociación, en su abordaje se pone mucho más énfasis en los elementos hard (duros) que en los suaves (soft). Así, muchas metodologías cometen el error de prestigiar el contenido procedimental por encima del conceptual. Es decir, se apunta más al COMO que al QUE.

En este marco, para incrementar los resultados de los proyectos de IT, es fundamental reformar la educación en sistemas, adoptando un enfoque original y desafiante que comprenda no sólo la difusión de metodologías, técnicas y experiencias sino también el replanteo de varios paradigmas incorporando nuevos marcos conceptuales.

¿Qué son los IDE de Programación?

A la hora de crear arte hecho código fuente, muchas veces necesitamos un buen editor para escribir nuestro codigo, un compilador a mano o interprete según corresponda a nuestro lenguaje de programación, una conección a su base de datos facil y rapida si es que utilizamos. En fin muchas veces necesitamos escoger para nuestro lenguaje un Entorno de Desarrollo Integrado (IDE).

Un entorno de desarrollo integrado o en inglés Integrated Development Environment (IDE) es un programa compuesto por un conjunto de herramientas para un programador.

Los IDEs proveen un marco de trabajo amigable para la mayoría de los lenguajes de programación.

Los componentes que deben tener los IDEs son:

* Un editor de texto.
* Un compilador.
* Un intérprete.
* Herramientas de automatización.
* Un depurador.
* Posibilidad de ofrecer un sistema de control de versiones.
* Factibilidad para ayudar en la construcción de interfaces gráficas de usuarios.

Clasificación de los lenguajes de programación

Los lenguajes de programacion se determinan según el nivel de abstracción, Según la forma de ejecución y según el paradigma de programación que poseen cada uno de ellos y esos pueden ser:

Lenguajes de Bajo Nivel
Los lenguajes de bajo nivel son lenguajes de programación que se acercan al funcionamiento de una computadora. El lenguaje de más bajo nivel es, por excelencia, el código máquina. A éste le sigue el lenguaje ensamblador, ya que al programar en ensamblador se trabajan con los registros de memoria de la computadora de forma directa.

Lenguajes de Medio Nivel
Hay lenguajes de programación que son considerados por algunos expertos como lenguajes de medio nivel (como es el caso del lenguaje C) al tener ciertas características que los acercan a los lenguajes de bajo nivel pero teniendo, al mismo tiempo, ciertas cualidades que lo hacen un lenguaje más cercano al humano y, por tanto, de alto nivel.

Lenguajes de Alto Nivel
Los lenguajes de alto nivel son normalmente fáciles de aprender porque están formados por elementos de lenguajes naturales, como el inglés. En BASIC, el lenguaje de alto nivel más conocido, los comandos como "IF CONTADOR = 10 THEN STOP" pueden utilizarse para pedir a la computadora que pare si CONTADOR es igual a 10. Por desgracia para muchas personas esta forma de trabajar es un poco frustrante, dado que a pesar de que las computadoras parecen comprender un lenguaje natural, lo hacen en realidad de una forma rígida y sistemática.

Lenguajes compilados e interpretados

Este es un concepto muy claro que marca muchas veces diferencia entre los lenguajes de programación que normalmente utilizamos y es un punto clave a la hora de elegir uno para llevar a cabo nuestras aplicaciones. Como corresponde en este blog probaremos tanto lenguajes compilados como también lenguajes interpretados ...

Lenguajes compilados
Naturalmente, un programa que se escribe en un lenguaje de alto nivel también tiene que traducirse a un código que pueda utilizar la máquina (lenguaje de máquina). Los programas traductores que pueden realizar esta operación se llaman compiladores. Éstos, como los programas ensambladores avanzados, pueden generar muchas líneas de código de máquina por cada proposición del programa fuente. Se requiere una corrida de compilación antes de procesar los datos de un problema.

Los compiladores son aquellos cuya función es traducir un programa escrito en un determinado lenguaje a un idioma que la computadora entienda (lenguaje máquina con código binario).

Al usar un lenguaje compilado (como lo son los lenguajes del popular Visual Studio de Microsoft), el programa desarrollado nunca se ejecuta mientras haya errores, sino hasta que luego de haber compilado el programa, ya no aparecen errores en el código.

Lenguajes Interpretados
Se puede también utilizar una alternativa diferente de los compiladores para traducir lenguajes de alto nivel. En vez de traducir el programa fuente y grabar en forma permanente el código objeto que se produce durante la corrida de compilación para utilizarlo en una corrida de producción futura, el programador sólo carga el programa fuente en la computadora junto con los datos que se van a procesar. A continuación, un programa intérprete, almacenado en el sistema operativo del disco, o incluido de manera permanente dentro de la máquina, convierte cada proposición del programa fuente en lenguaje de máquina conforme vaya siendo necesario durante el proceso de los datos. No se graba el código objeto para utilizarlo posteriormente.

La siguiente vez que se utilice una instrucción, se le debe interpretar otra vez y traducir a lenguaje máquina. Por ejemplo, durante el procesamiento repetitivo de los pasos de un ciclo, cada instrucción del ciclo tendrá que volver a ser interpretado cada vez que se ejecute el ciclo, lo cual hace que el programa sea más lento en tiempo de ejecución (porque se va revisando el código fuente en tiempo de ejecución) pero más rápido en tiempo de diseño (porque no se tiene que estar compilando a cada momento el código completo). El intérprete elimina la necesidad de realizar una corrida de compilación después de cada modificación del programa cuando se quiere agregar funciones o corregir errores; pero es obvio que un programa objeto compilado con antelación deberá ejecutarse con mucha mayor rapidez que uno que se debe interpretar a cada paso durante una corrida de producción.

Base de datos

Uno de los conceptos básicos en el mundo de la informática de hoy es el de las Bases de datos. Este concepto es muy importante a la hora de la construcción de aplicaciones, es tan importante como la elección del lenguaje de programación y muchas cuestiones relacionadas con el mismo.

Una base de datos o banco de datos es un conjunto de datos que pertenecen al mismo contexto almacenados sistemáticamente para su posterior uso. En este sentido, una biblioteca puede considerarse una base de datos compuesta en su mayoría por documentos y textos impresos en papel e indexados para su consulta. En la actualidad, y debido al desarrollo tecnológico de campos como la informática y la electrónica, la mayoría de las bases de datos tienen formato electrónico, que ofrece un amplio rango de soluciones al problema de almacenar datos.

En informática existen los sistemas gestores de bases de datos (SGBD), que permiten almacenar y posteriormente acceder a los datos de forma rápida y estructurada. Las propiedades de los sistemas gestores de bases de datos se estudian en informática.

Las aplicaciones más usuales son para la gestión de empresas e instituciones públicas. También son ampliamente utilizadas en entornos cientí­ficos con el objeto de almacenar la información experimental.

Aunque las bases de datos pueden contener muchos tipos de datos, algunos de ellos se encuentran protegidos por las leyes de varios paí­ses.

Al igual que contamos con leguajes de programación de código libre o privativos con la adquisición de su licencia, también contamos con sistemas gestores de bases de datos, tanto libres como así­ también privativas.

¿Qué es SQL?

El Lenguaje de Consulta Estructurado (Structured Query Language o SQL) es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones sobre las mismas. Una de sus características es el manejo del álgebra y el cálculo relacional permitiendo lanzar consultas con el fin de recuperar información de interés de una base de datos, de una forma sencilla. Es un lenguaje de cuarta generación (4GL).

Con respecto a las caracteristicas podemos decir que el SQL es un lenguaje de acceso a bases de datos que explota la flexibilidad y potencia de los sistemas relacionales permitiendo gran variedad de operaciones sobre los mismos. Es un lenguaje declarativo de alto nivel o de no procedimiento, que gracias a su fuerte base teórica y su orientación al manejo de conjuntos de registros, y no a registros individuales, permite una alta productividad en codificación. De esta forma una sola sentencia puede equivaler a uno o más programas que utilizasen un lenguaje de bajo nivel orientado a registro.

Optimización de código

En informática, la optimización de código es el proceso de modificar un sistema para hacer que algún aspecto de su trabajo sea más eficiente o se utilicen menos recursos. Por ejemplo, un programa de computador puede ser optimizado de modo que este se ejecute más rápidamente, o que sea capaz de operar con menos memoria de almacenamiento u otros recursos.

Aunque la palabra optimización comparte la misma raíz que la palabra óptimo, es raro que en un proceso de optimización se obtenga un sistema verdaderamente óptimo. Típicamente, el sistema optimizado solo será óptimo en una aplicación o en un cierto ámbito. Uno podría reducir la cantidad de tiempo que un programa toma para ejecutar cierta tarea pero el precio de hacerlo consume más memoria.

Frecuentemente no hay "un tamaño que se ajusta para todo" esto es, un diseño que trabaje en todos los casos. Así los ingenieros hacen trade-offs para optimizar los atributos de mayor interés. Adicionalmente, el esfuerzo requerido para hacer una pieza de software completamente óptimo - incapaz de alguna mejora adicional - es casi siempre más razonable para los beneficios que serán logrados; así el proceso de optimización podría ser detenido antes que una solución óptima completa haya sido alcanzado. Afortunadamente, es frecuente el caso de que las más grandes mejoras vienen rápido en el proceso.

La optimización puede ocurrir en un número de niveles. En el más alto nivel, el diseño puede ser optimizado para hacer mejor uso de los recursos disponibles. La implementación de este diseño se beneficiará del uso de algoritmos eficientes y la implementación de estos algoritmos beneficiará con la escritura de código de buena calidad.

Trade-off
La optimización generalmente se enfocará en mejorar solo uno o dos aspectos de la performance: tiempo de ejecución, uso de memoria, espacio en disco, ancho de banda, potencia de consumo o algún otro recurso. Esto usualmente requerirá un trade-off: donde un factor es optimizado en expensas de otros. Por ejemplo, incrementando el tamaño del caché mejora la performance en tiempo de ejecución, pero también incrementa el consumo de memoria. Otros comunes trade-offs incluye código claro y conciso.

Cuellos de botella
La optimización requiere determinar un cuello de botella: la parte crítica del código es el consumidor primario de los recursos necesarios. Como una regla de oro, la mejora de un 20% del código es responsable del 80% de los resultados (Principio de Pareto).

El principio de Pareto (también conocido como la regla 80-20) dice que para muchos fenómenos, el 80% de las consecuencias se derivan de un 20% de las causas.

En ciencia del computador, el Principio de Pareto puede ser aplicado para optimización de recursos observando que el 80% de los recursos son típicamente usados por el 20% de las operaciones. En ingeniería de software, es frecuente una mejor aproximación que el 90% del tiempo de ejecución de un programa de computadora es gastado ejecutando el 10% del código (conocida como la ley 90/10 en este contexto).

El diseño de la arquitectura de un sistema abrumadoramente afecta a su rendimiento. La elección del algoritmo afecta la eficiencia más que cualquier otro ítem de diseño. Algoritmos más complejos y estructuras de datos se ejecutan bien con muchos ítems, mientras que algoritmos más simples son más convenientes para pequeñas cantidades de datos.

En algunos casos, añadir más memoria puede ayudar a hacer un programa más rápido.

¿Cuando optimizar?
La optimización puede reducir la legibilidad del código fuente (facilidad con que se puede comprender el propósito, flujo y la operación de una sección de código fuente) que es usado para mejorar la performance. Esto puede complicar programas o sistemas haciéndolos más duros de mantener o debuggear. Como resultado de esto, la optimización o afinamiento de performance es frecuentemente ejecutado al final de la etapa de desarrollo.

Automatización manual y automatizada
La optimización de un sistema completo es usualmente realizado por humanos porque el sistema es demasiado complejo para optimizaciones automáticas. En esta técnica, los programadores o administradores del sistema cambian explícitamente código de modo tal que el sistema mejora. Aunque esto podría conducir a una mejor eficiencia, este es más caro que las optimizaciones automáticas.

Primero que todo, es extremadamente importante usar una herramienta de análisis de performance (profiler) para encontrar la secciones del programa que están tomando la mayor parte de los recursos (el cuello de botella). Los programadores usualmente piensan que ellos tienen una idea clara de donde esta el cuello de botella, pero la intuición falla frecuentemente. Optimizando una pieza insignificante de código típicamente hará poco para ayudar a la performance total.

Cuando el cuello de botella es localizado, la optimización usualmente se inicia rediseñando el algoritmo utilizado en el programa: la mayoría de las veces, un algoritmo particular puede ser adaptado específicamente a un problema particular, produciendo un mejor rendimiento que un algoritmo genérico. Por ejemplo, la tarea de ordenar una enorme lista de ítems se realiza habitualmente con un algoritmo quicksort, que es uno de los algoritmos genéricos más eficientes. Pero si algunos de las características de los ítems son aprovechables (si por ejemplo, ellos ya están ordenados en algún orden particular), un método diferente puede ser usado, o incluso una rutina de ordenamiento hecho a la medida.

Después que se está razonablemente seguro que el mejor algoritmo es seleccionado, la optimización de código puede comenzar: bucles pueden ser desenrollados (para disminuir la sobrecarga del bucle, aunque a menudo esto puede conducir a disminuir la velocidad si esto sobrecarga el caché del CPU), tipos de dato tan pequeños como sea posible usar, aritmética de enteros puede ser usado en lugar de punto-flotante, y así sucesivamente.

Los cuellos de botella de performance pueden ser debidos a limitaciones del lenguaje de programción antes que algoritmos o estructuras de datos usadas en el programa. A veces, una parte crítica del programa puede ser re-escrita en un lenguaje diferente que da acceso más directo a la máquina subyacente. Por ejemplo, es común para lenguajes de muy alto nivel como Pitón tener módulos escritos en C para mayor velocidad. Programas ya escritos en C pueden tener módulos escritos en ensamblador.

La reescritura vale la pena debido a una regla general conocida como la ley 90/10, que dice que el 90% del tiempo es gastado en el 10% del código, y solo el 10% del tiempo en el restante 90% del código. Así poniendo esfuerzo intelectual en optimizar solo una parte pequeña del programa puede tener un enorme efecto en la velocidad total si la parte(s) correcta(s) puede(n) ser localizada(s).

Tiempo tomado para la optimización
En algunos casos, el tiempo tomado para la optimización en si mismo puede ser un problema.

En un proyecto de software, la optimización de código usualmente no añade un nuevas características, y peor aún, esto podría romper ciertas funcionalidades. Debido a que código optimizado tiene menos legibilidad que un código sencillo, la optimización puede bien afectar la legibilidad del programa. En resumen, la optimización se convierte en un costo y es importante estar seguro que la inversión vale la pena.

Historia de la evolución del Hypatia - Sistema Financiero Contable

Antecedentes
Hace 12 años (1996), y por encargo de la Asociación de Cajas Rurales, se inició el proyecto de desarrollo del Sistema de Información Financiero Contable de Cajas Rurales denominado en forma abreviada Siscarul (Sistema de Cajas Rurales). La empresa GMD (Graña & Montero Digital) fue la empresa seleccionada para llevar adelante dicho proyecto.

Durante la etapa previa al inicio del proyecto el equipo técnico de la Asociación seleccionó el entorno de desarrollo IDE y el sistema gestor de base de datos o DBMS a ser usado. Se eligió como herramienta de desarrollo al PowerBuilder® y como sistema gestor de base de datos (motor de base de datos) al Anywhere®, ambos productos de la corporación internacional Sybase®.

Consideramos que esta elección fue acertada ya que el PowerBuilder es una herramienta que permite un ciclo de desarrollo de productos más rápido comparado con otras herramientas similares, y el Anywhere (Adaptive Server Anywhere o ASA) porque se requería de un motor pequeño (fácil de administrar y mantener), relativamente barato y con capacidad de escalar a otro de mayor envergadura y con mayores prestaciones cuando las circunstancias así lo requieran.

Luego de una serie de problemas sobretodo de índole administrativo que surgieron durante el proceso de desarrollo, el proyecto se culminó a mediados del año 1998 y posteriormente fue implantado en las siguientes Cajas Rurales: NorPeru (año 1998), Sipan (año 1999), Sr. de Luren (2000), Los Libertadores (año 2001) y Cajamarca (año 2002). La implantación en la Caja NorPerú la realizó la empresa GMD y posteriormente el mismo sistema fue implantado en las demás Cajas por terceros con el nombre de Hypatia. La implantación en las Cajas Sipan, Sr. de Luren y Los Libertadores fue realizada por un equipo técnico conformado en la Asociación y se tomó en promedio 1 año en cada una. La implantación en la Caja Cajamarca fue realizada por una empresa independiente y se tomó aproximadamente 3 meses.

A mediados del año 1999 (un año después de haber sido implantado) se inicia la primera adecuación del sistema de información Hypatia. La Caja NorPerú convoca a nuestra empresa http-peru para realizar la adecuación del módulo de contabilidad de su sistema de información al nuevo plan de cuentas especificado por la SBS. La estrategia que se siguió para tal efecto fue rediseñar completamente dicho módulo y convertirlo en una aplicación independiente del Hypatia con el objetivo de no solo ajustarlo a las especificaciones dadas por la SBS sino sobretodo de mejorar su performance. Este proyecto culminó exitosamente dentro del presupuesto y del cronograma especificados previamente y con la completa satisfacción de los usuarios de su área de contabilidad.

Esquema de base de datos centralizado

En el año 2001 la Caja NorPerú nos encarga realizar la segunda adecuación a su sistema de información: rediseñar su sistema para que trabaje bajo un esquema de base de datos centralizado, esto es que las agencias remotas accedan a una misma base de datos centralizada. Es importante señalar que originalmente el Hypatia se había diseñado para que trabaje bajo un esquema cliente/servidor clásico existiendo en cada una de sus agencias no-conectadas una base de datos local en donde se registran las transacciones realizadas diariamente y que periódicamente se integra en la base de datos central solo la mínima información requerida posible (la requerida para efectos contables y de envió de información consolidada).

Por aquel año las grandes interrogantes eran: ¿Soportará dicho motor de base de datos (Adaptive Server Anywhere: ASA) el acceso concurrente de clientes locales y remotos? Y si esto es así ¿Los tiempos de respuesta serán aceptables o se necesitará optimizar los programas cliente para mejorar los tiempos de respuesta de la aplicación en su conjunto y así evitar los accesos innecesarios al servidor de BD?

Después de algunas pruebas de laboratorio, realizadas en la Caja NorPerú y en la Caja San Martín, llegamos a la conclusión de que efectivamente el ASA, administra aceptablemente bien el acceso de clientes remotos pero que tiende a "enchancharse" conforme aumenta el número de conexiones concurrentes.

A mediados del año 2001 este proyecto culminó exitosamente logrando que aplicaciones cliente de una agencia remota accedan a una única base de datos ubicada en la sede principal de dicha Caja. Cabe señalar que esta interconexión fue operativa y contable, es decir cada una de las agencias trabajaba como una oficina independiente y los usuarios involucrados (áreas de operaciones y de contabilidad) quedaron satisfechos bajo este nuevo esquema de trabajo.

Debido a que se percibía cierta latencia cuando se realizaban transacciones de créditos desde las agencias remotas nos embarcamos en otro proyecto con el objetivo de que las agencias más remotas accedan de una manera más eficiente a la base de datos central. En coordinación con el área de sistemas de la Caja NorPerú, se fijaron los siguientes objetivos para esta nueva etapa del proyecto:

1) En el corto plazo, optimizar la aplicación cliente para evitar accesos innecesarios a la BD o reemplazar bloques de código por algoritmos de acceso más eficientes.

2) En el mediano o largo plazo, considerar migrar su limitado motor de base de datos a uno corporativo. El candidato natural era el Adaptive Server Enterprice, también conocido con el nombre de ASE, de la misma empresa Sybase®.

A finales del año 2001 comenzamos a trabajar en la optimización de código de su sistema de información y en la creación de Objetos de Usuario No-Visuales (Non Visual Objects: NVO) que permiten encapsular las reglas de negocio de la empresa y más adelante colocarlos en un Servidor de Transacciones. Unos meses después este proyecto fue abortado por decisión de los funcionarios de la Caja NorPerú. Al parecer surgió un corriente de opinión de que con ese motor de base de datos (ASA) sería imposible interconectar sus agencias más remotas.

Años más tarde, y previa optimización de código como lo habíamos propuesto, su propia área de sistemas logró que agencias bastante remotas accedieran simultáneamente a única base de datos ASA centralizada usando conexión de línea dedicada.

Migrando de motor de base de datos

En el año 2004 la Caja Señor de Luren inició un proyecto de interconexión de agencias, tal como lo había hecho la Caja NorPerú en años anteriores, pero que implicaba además un cambio de motor de base de datos y la optimización de bloques de código de sus programas cliente.

En realidad había 3 proyectos en uno:

1) El proyecto de preparar los programas fuente de su sistema de información (plataforma cliente) y los objetos de la BD (plataforma servidor) para cada una de las estaciones cliente acceda en forma independiente a una misma BD centralizada.

2) El proyecto de migrar la data y absolutamente todos los objetos de BD de ASA (Adaptive Server Anywhere) a ASE (Adaptive Server Enterprice).

3) El proyecto de optimización de bloques de código de sus programas cliente para encapsular los accesos a la base de datos en objetos de usuario denominados NVO (Non Visual Objects) que a su vez accedían a la BD mediante Procedimientos Almacenados (Store Procedures).

Desde nuestro punto de vista, esto último es lo que causo los mayores retrasos en el proyecto. La razón de crear NVO 's es preparar su sistema de información para que en un futuro funcione bajo un esquema de 3 capas usando un Servidor de Transacciones como capa intermedia. Actualmente, según tenemos entendido, su sistema de información sigue trabajando bajo un esquema de 2 capas como inicialmente se diseñó.

Este proyecto lo llevó a cabo la empresa Sybase Perú y la duración de este proyecto fue de 1,5 años y su costo fue de US$150,000 dólares americanos (equipos, licencias y servicios). Estos son valores aproximados proporcionados por fuentes cercanas.

En el año 2005 la Caja NorPeru optó también por migrar de motor de base de datos (de ASA a ASE) pero solo haciendo los cambios mínimos necesarios a su sistema de información. Concentraron su esfuerzo solo en hacer upsizing de su base de datos, esto es migrar su motor de base de datos de pequeña escala ASA al motor de base de datos corporativo de la misma empresa ASE. No distrajeron su atención en otras consideraciones, y consideramos que fue una decisión acertada. Es importante recordar que por aquella época su sistema de información, en la parte Cliente y en la parte Servidor, ya trabajaba bajo un esquema de base de datos centralizado (esta adecuación se realizó en el años 2001). Solo requerían de un motor de base de datos de misión crítica que soporte una cantidad grande de conexiones concurrentes locales y remotas.

El proyecto lo llevó a cabo su propia área de sistemas lo que permitió un ahorro sustantivo de costos.

El costo aproximado de este proyecto fue de US$100,000 dólares americanos (equipos y licencias) y su duración fue de aproximadamente 9 meses.

Actualmente son las dos únicas Cajas Rurales en el Perú que poseen el sistema de información Hypatia trabajando con un motor de base de datos corporativo ASE en un esquema de base de datos centralizado. Actualmente la Caja NorPeru posee 12 agencias y la Caja Sr. de Luren 8, todas interconectadas (según su propio website), aunque al parecer esta última aún no soluciona hasta ahora su problema de contabilización automática bajo este nuevo esquema de interconexión.

Las otras 3 Cajas que poseen el sistema de información Hypatia trabajan con el motor de base de datos originario ASA.

Panorama de las demás Cajas Rurales

En el año 2005 la Caja Sipán convoca a nuestra empresa http-peru para realizar la adecuación de la versión del Hypatia que tenía hasta ese momento para que sus agencias accedan a una única base de datos centralizada (ASA). Se realizó un trabajo similar al que se realizó en años anteriores en la Caja NorPerú con el mismo resultado: la satisfacción total de los usuarios del sistema. A la fecha su sistema de información se encuentra trabajando bajo este esquema y realiza la contabilización de sus operaciones de forma automática, incluso las operaciones interagencias, pero no se priorizó el tema de optimización de código de los programas cliente, fundamental para el acceso concurrentemente masivo de clientes remotos.

A la fecha dicha Caja sigue usando el motor de base de datos Anywhere® (ASA) y no vemos que exista necesidad de cambiar de motor de base de datos en el corto plazo.

Otras experiencias
A finales del año 2005, la Caja Los Libertadores contrató a la empresa LogicCenter para resolver su necesidad de interconexión de sus agencias remotas. El objetivo inicial era permitir la interconexión de sus oficinas remotas y más adelante realizar operaciones de transferencias o remesas de efectivo con otras Cajas Rurales.

La solución propuesta implicaba el uso de su producto TransLink Transaction Services (TTS), un midleware que se constituirá en una plataforma de codificación intermedia entre las agencias remotas y la oficina principal.

Esta plataforma intermedia hará las veces de un Servidor de Transacciones, esto es, los requerimientos de las estaciones cliente de las agencias remotas serán procesadas por los componentes (programas) construidos sobre el TTS.

Algunas observaciones que hicimos a esta solución fueron las siguientes:

1) El costo de US$10,500.00 dólares por la adquisición del producto midleware TTS NO es el costo total de la solución. Se incurre en una serie de gastos adicionales, como por ejemplo el costo de contratar a las personas que van a programar los componentes que serán alojados en el TTS.

2) Las personas que van a programar los componentes no solo deben conocer detalles técnicos de la creación y publicación de componentes en el TTS sino conocer en detalle el sistema de información de la empresa y su dinámica de trabajo. Esto implica que no cualquier programador puede realizar esta delicada labor, sino que esta debe ser realizada por un especialista calificado que conozca las reglas de negocio de la empresa y sobretodo la dinámica de actualización de la BD implementada por su sistema de información, en este caso el Hypatia.

3) Se van a duplicar los esfuerzos de codificación ya que cuando se requiera agregar una nueva funcionalidad, o actualizar una ya existente, se deberá codificar en el sistema de información actual y hacer lo mismo en los componentes hospedados en el TTS.

4) Los tiempos de respuesta de los sistemas en .net, que al parecer es la plataforma tecnológica elegida, son notoriamente mayores que las soluciones en un entorno más abierto (php por ejemplo).

Meses después de haberse iniciado este proyecto, y producto de un estudio realizado por una tercera empresa, este iniciativa fue abortada.

Conclusiones Finales
El motor de base de datos ASA en un buen servidor de base de datos (multiprocesador, buena cantidad de memoria RAM y discos rápidos) administra aceptablemente bien el acceso de clientes locales y remotos. Soporta aceptablemente el acceso de hasta 120 conexiones concurrentes, 30% de las cuales pueden provenir de conexiones remotas (aproximadamente 6 oficinas). Para un número mayor de conexiones se debe considerar cambiar de motor de base de datos y/o optimizar la forma en que los programas clientes acceden a la base de datos (optimización de código).

Por la forma en que fue inicialmente diseñada, el sistema Hypatia realiza una gran cantidad de accesos a la BD saturando de requerimientos al servidor de base de datos. Esto se vuelve dramático cuando crece el número de conexiones concurrentes.

Para superar esto se debe rediseñar los programas Cliente para que realicen accesos optimizados a la BD y para que la información más frecuentemente consultada se encuentre permanentemente en los buffers de cada estación de trabajo.

Una muestra de lo que puede ocurrir cuando un motor de base de datos ASA recibe una gran cantidad de requerimientos de clientes locales y remotos, se produjo a mediados del año 2005 en la Caja NorPeru, cuando ya tenían 9 agencias y aún no cambiaban de motor de BD. No obstante tener un servidor de base de datos de última generación, su motor de base de datos ASA se constituyó en un cuello de botella ya que en horas punta este se saturaba y se degradaban los tiempos de respuesta del servidor. En aquel momento su sistema de información se constituyó en una debilidad para la consecución de sus planes de crecimiento empresariales.

Para superar esta coyuntura optaron por hacer uso de la fibra óptica como medio físico de comunicación entre su oficina principal y sus principales agencias pero no se consiguieron resultados espectaculares ya que lo que originaba el problema no era el medio sino el limitado motor de base de datos que en horas punta se "estrangulaba" y no se bastaba para satisfacer los requerimientos de clientes locales y remotos aceptablemente.

Migrar del ASA al ASE es una buena solución para esta clase de problemas pero los inconvenientes son los siguientes:

1) Es muy oneroso: Los costos directos (licencias) e indirectos involucrados lo hacen inaccesibles a la mayoría de las Cajas.

2) Soporte técnico: El soporte técnico en nuestro medio es escaso.

3) Mantenimiento: Este motor requiere de un dba con experiencia en este DBMS.

Las ventajas es que es un motor bastante sólido y estable y que es multiplataforma, es decir que puede correr bajo diferentes sistemas operativos: Windows, Unix, Linux, OS2, etc.