Crecer en TI es posible...

Reproducción de un artículo de Juan Carlos Lucas en La Nación ("La e-República Argentina"). Juan Carlos escribe habitualmente en el diario, y representa lo que de positivo tiene Argentina hoy, en ideas e iniciativas. El futuro debería tener muchos más emprendedores como él.
Sigue su artículo, con la excepción del video que lo acompaña:

Hace un tiempo, Alec Oxenford publicó algunos artículos en su blog mencionando el caso del desarrollo de un pequeño país llamado Estonia . La sorprendente historia que mencionaba en esos artículos puede profundizarse al navegar en Internet y observar la relación entre dicho país y la creación de Skype:

• La empresa recibió sus primeros aportes de capital en el 2002, fue comprada en el 2004 en 2.4 billones de dólares por e-Bay, en el 2005 llegó a 100 millones de usuarios registrados y el año pasado lanzó su teléfono Wi-fi que permite hablar gratis sin computadora.

• El emprendimiento no se creó en Estonia pero este país brindó un servicio tecnológico importante para el desarrollo del mismo. Mucho del desarrollo de Estonia tiene relación con su posicionamiento como proveedor de los países nórdicos.

• Estonia es un país independiente desde 1991 (era parte de la extinta Unión Soviética).

• Hoy en día este pequeño país tiene un desarrollo en tecnología que hace que se le haya dando en llamar la "e-republic of Estonia".

• En la época de la URSS, Estonia fue sede de un centro de investigación en cibernética. Luego de la caída del muro y la llegada de la independencia se encontraron con gente que sabía pero sin desarrollo de infraestructura en su territorio.

• Es interesante lo que comenta Linnar Viik , el señor Internet de Estonia:

"Tuvimos la suerte de independizarnos en un momento en que aprender y usar las posibilidades de Internet era mas fácil para nosotros, no teníamos que amortizar las viejas tecnologías de mainframes como los países desarrollados".

En algún sentido una debilidad puede ser, también, una oportunidad.

Cuál es la desventaja de contar con recursos naturales. Un líder político chileno distinguido con un premio por su aporte en la inserción de su país en la era de la información y la innovación, comenta en su discurso que está angustiado por Chile: "…la angustia es positiva, que lo peor es quedarse, la complacencia, la maldición de los recursos naturales."

Esta frase puede remitir a los históricos debates en torno al desarrollo de la economía latinoamericana. De hecho, un debate blogosférico de hace varios meses ha girado en torno precisamente a este tema. En laciencia … se aportaban algunos puntos de vista sobre Chile y Argentina que permiten dar sentido a la idea de maldición de los recursos naturales.

Un artículo presentaba este punto de vista con relación a la buena fortuna de la presidente de Chile : "El índice de la suerte en Chile debe estar que explota. El boom de la soja no existe al lado del que vive el cobre. Desde el valle de los commodities en 1999, la soja subió un 20%; el cobre se cuadruplicó. Desde que Bachelet dejó su puesto de ministra de defensa para ser candidata por la Concertación, en octubre de 2004, el cobre se duplicó. En los últimos tres meses, desde que ganó el ballotage (franja rosa del gráfico) subió 25%."

En otro artículo se señalaba en relación al desarrollo del modelo económico chileno : "La bonanza del cobre está complicando a los exportadores de frutas y salmones . Toda la historia del éxito chileno en la diversificación exportadora, la elaboración de los recursos naturales, los eslabonamientos, etc. etc., y al final seguimos en el siglo diecinueve."

Al recordar estos pasajes se entiende mejor la angustia por la complacencia del político chileno. En su discurso alertaba: "necesitamos banda ancha para todos… innovaciones disruptivas… intentar un salto… para no llegar tarde como siempre."

En algún sentido una fortaleza puede ser, también, una amenaza y un lastre.

El debate en torno a las empresas de outsourcing. En su libro "La Tierra es Plana", Thomas Friedman describe las nuevas formas de colaboración que motorizan el mundo global y tecnológico. Entre estas formas mencionaba las siguientes:

• Outsourcing: tercerizar fuera de la empresa procesos que pueden ser más efectivamente realizados por otras compañías.

• Offshoring: desarrollar un proceso en aquel país donde pueda ser más efectivo (ya sea dentro o fuera de la empresa).

• Opensourcing: comunidad global de programadores de software que ponen el código de los programas que desarrollan a disposición del resto de la comunidad de manera libre y gratuita. Este fenómeno está permitiendo desarrollar una gran capacidad de innovación en redes de colaboración abiertas que está sirviendo de modelo a otras industrias.

En ese libro también se comenta el caso de India como oferente de servicios de outsourcing-offshoring para países como Estados Unidos. Este fenómeno comenzó a desarrollarse en el momento en que se enfrentó en conflicto del Y2K y las capacidades internas de las empresas colapsaban.

Por estos días, empresas argentinas han comenzado a protagonizar este mercado. Un caso para observar es el de la empresa Globant, un emprendimiento reciente, que comenzó a posicionarse en este enorme mercado del offshoring de IT outsorcing, y hoy se ha hecho un lugar compitiendo con empresas indias y de otros países. Esta compañía se define como proveedor líder de servicios de IT desde Latinoamérica hacia el Mundo. Su estrategia ha dividido opiniones de los analistas.

Quienes ven que este caso puede representar un modelo interesante a seguir para Argentina, señalan los siguientes puntos vinculados a su posicionamiento estratégico:

• Cercanía y sintonía cultural con los Estados Unidos. Mucho mayor que la que pueden tener con la India.

• Abundancia local de talento y calificación profesional.

• Estructura local de costos bajos, que produce significativos ahorros a los clientes.

• Apalancamiento en el movimiento de open-source , que permite la democratización en el acceso a tecnología para países como la Argentina.

Quienes ven a esta empresa solo como un caso aislado que no sirve de modelo, sostienen que:

• Su modelo se basa en la ventaja de costos coyuntural, por el tipo de cambio actual.

• Venden servicios "commoditizados" (software factory) que no permiten valorizar de la mejor manera el recurso humano argentino.

Al escuchar este debate parece surgir la preocupación por definir cuál es la ventaja competitiva que podría desarrollar Argentina para posicionarse en algún nicho global con una oferta relevante.

Preguntas para la agenda. De los señalamientos anteriores surgen algunas preguntas que podrían ser relevantes para una agenda de conversaciones en el camino de posicionar estratégicamente a la Argentina en un contexto mundial de cambio tecnológico acelerado:

• ¿Qué estrategias se están adoptando para no caer en la maldición de los recursos naturales una y otra vez?

• ¿Que "ventaja" existe en la Argentina y Latinoamérica, por no ser zonas desarrolladas, para subirse a la actual revolución tecnológica?

• ¿Qué esfuerzo se realiza para apropiarse de las nuevas posibilidades tecnológicas que emergen?

• ¿Qué estamos haciendo para no llegar tarde como siempre?

• ¿Qué ventajas competitivas permitirían apalancar una oferta argentina relevante para el mundo, en el dominio de las tecnologías de la información y la comunicación?

Quizás un poco de angustia sea positiva.

CM Crossroads sobre trazabilidad

La última actualización de noticias de CM Crossroads agrupa varios artículos sobre Trazabilidad publicados durante Agosto. Este concepto impacta en la calidad y confiabilidad con que se manejen los procesos de construcción de software. No está de más dedicarles un tiempo. Los artículos son:
Traceability and Auditability: Definiciones, especialmente sobre auditorías.
Traceability and Auditability: Satisfying your Customers: Más detallado sobre trazabilidad

One of the most common queries in our shop is: What went into a build? This may seem like an innocent question, or to some who know better, it may seem like a terribly complex question.

When we ask what went into a build, we ask the questions:

• What problems were fixed?
• What problems are outstanding?
• What features have been added?
• What requirements have been met?
• Which updates (i.e change packages) went into the build?
• Which files were changed?
• How have run-time data configuration files changed?

Why is this so common a query in our shop? Well first of all our ALM toolset makes it easy to do. But secondly, when something goes wrong, we want to isolate the cause as quickly as possibly. If a new delivery to a customer introduces a problem they didn't previously have, we ask: What changes went into this build as compared to the customer's previous release build? We then screen these based on the problem and more times than not isolate the cause quickly. Even more frequently, if the system integration team, or verification team, finds a problem with an internal build, we go through the same process and isolate the cause quickly. By having a sufficiently agile development environment that packages a couple of dozen or so updates into each successive build, we're able to pinpoint new problems and hopefully turn them around in a few minutes to a few hours. Finally, we need to produce release notes for our customers. This type of query is the raw data needed by the technical writer to produce release notes. It's also the raw data needed by our sales team to let prospects know what's in the new release, or what's coming down the pipe.

Traceability & Auditability: Do you really know what went into production?: La relación de la trazabilidad con la puesta en producción del software:

Change management has two main objectives. The first is to provide support for the processing of changes, typically initiated via the service desk. Such processing includes change identification, analysis, prioritizing, planning for their implementation, decisions for their rejection or postponement, and decisions for their integration in new product releases. The second objective is traceability (i.e., to make it possible to list all active and implemented changes). It should also be possible to track the modifications of different items due to a specific change. (e.g. Part of the ITIL Knowledge database.)

By extending the Service Desk into ALM, traceability will not only include configuration items (CIs) in production, but will also provide the capability to link to all application development artifacts to be able to perform end-to-end impact analysis, including the scope of the resolution of the problem under analysis.

Audit Trails, Traceability - Because Sometimes Things Go Wrong: La trazabilidad en el seguimiento de problemas

Any time we make a change to production, there is the risk that something will go wrong. Risk is a fact. The only way to eliminate risk is to never do anything. (But of course, that is not an option.) So we are left with actions we can take to mitigate those risks. Configuration Management (CM) is mainly about risk mitigation. Everything we do in CM is designed to reduce the likelihood that things will go wrong, or to reduce the adverse impact when they do go wrong. CM helps us to avoid many failures, and to recover quickly from those few that we can't avoid. But how do audit trails and traceability fit into this picture? Traceability doesn't prevent errors, and an audit trail does little to help me to recover from one. Does this mean they aren't valuable CM tools?
On the contrary, audit trails and traceability are two of our most important CM tools for learning how to mitigate risk.
Answering 6 Questions
Both auditing and traceability are mechanisms that are designed to answer the six questions: who, what, when, where, why, and how. For example:

• Who made the change? Who authorized it? Who knew about it?
• What exactly was changed? And what was not changed?
• When was the change made (especially relative to other activities)?
• Where was the change made (e.g. what platform, repository, location)?
• Why was the change made? What triggered the change or motivated the person?
• How was the change made? What precisely was done and not done? How was information about the change captured and communicated?
  

Y especialmente: The Trouble with Tracing: Traceability Dissected: Una buena descripción de su valor y aspectos negativos

Eight Reasons for Traceability

If traceability is so much work, and if the return-on-investment is so hard for so many to see, then why do we bother? Or rather, why should we bother? Other than obvious contractual obligation, legal liability, or the fact that various CM and software engineering tomes declare “thou shalt have traceability,” what real needs does it serve? What does it let me do that I couldn’t otherwise do very easily? Several reasons commonly given are:

1. Validate we built what the customer actually agreed to pay us to build, that we built the “right thing” and that we “did things right” when building it
2. Verify that we delivered every file and feature/fix that we said we would, and nothing that we said we wouldn’t
3. Identify and isolate a set of changes that were made, and be able to either back-out the change from an existing version, and/or reintroduce the change to other versions
4. Assess the impact upon the design, code, tests and other aspects of the system for a proposed change-request (this in turn helps us determine effort, risk, cost, and the other affected groups)
5. Maintain an audit trail about who did what, when, where, why and how - so we can prove what we should and shouldn’t be held accountable for when the customer, or management or some other formal authority demands to know, or claims that we didn’t something we shouldn’t have, or for invalid reasons
6. Capture everything necessary to identify exactly what was delivered and repeat the steps necessary to reproduce it again
7. Report status of our activities to the customer and to management for the features and fixes that we are currently working on, so they can evaluate the progress and risks in delivering the project
8. Retrace our steps regarding something we did poorly, or that we simply didn’t know to pay attention to before, so we can identify root causes and learn how to prevent and/or correct it in the future

Those are all some pretty good reasons. Does that really justify why some of us have to maintain a traceability matrix? Is that really the most effective way?

Even agile development is in favor of tracing tests to features, which is extremely straightforward when one is doing test-driven development (TDD). When it comes to tracing requirements through to design and code, images of manually maintained traceability matrices that are hopelessly effort-intensive and never quite up-to-date seem to spring to mind.

De ayer a hoy: Seagate podría ser china

The New York Times informa que "una compañía china" está intentando comprar Seagate, en lo que podría ser una oferta hostíl, ya que la empresa no está en venta, pero "si el valor ofrecido por la acción es alto, será casi imposible impedirlo". Las empresas chinas están hoy en posición de poder comprar compañías en el mundo desarrollado (en cualquier parte, en realidad). NY Times señala preocupación gubernamental por la entrega de alta tecnología a China:

With a booming economy and $1.33 trillion in foreign-exchange reserves, Chinese companies are in a position to acquire American companies, as Japanese and West European companies were several decades ago. While those earlier acquisitions were often opposed out of fears that they would damage American economic competitiveness, the acquisition of American companies by Chinese companies is regarded with more suspicion, particularly in the high-tech sector.

Since the Lenovo sale, the government has become increasingly concerned about technology security, according to members of federal advisory committees.

“Seagate would be extremely sensitive,” said an industry executive who participates in classified government advisory groups. “I do not think anyone in the U.S. wants the Chinese to have access to the controller chips for a disk drive. One never knows what the Chinese could do to instrument the drive.”

The transfer of advanced disk drive manufacturing technology would give the Chinese a major leg up in competing in information technologies. China, however, still lags in basic manufacturing skills like semiconductor design and manufacturing.

Una mirada crítica sobre Wikipedia

Navegando en enlaces de del.icio.us, encontré un comentario sobre Wikipedia de Jason Scott
Escrito por un colaborador de Wikipedia hace algún tiempo (noviembre de 2004), sus observaciones siguen siendo válidas. Wikipedia continúa, y probablemente continuará, pero lo que está en juego es la calidad de su contenido. Jason Scott propone algunas ideas sobre el control de la precisión de sus definiciones; algunas ya en curso. Particularmente certera es su afirmación de que el aumento explosivo de la participación no conduce a la mejora, sino a la degradación del material elaborado:

The Usenet FAQ was (and is) to me, one of the true great advantages and creations of the Internet age. Previously, it had always been the case that the same 5 or 10 questions plagued a subgroup, cultural icon, hobby or occupation. These questions, while quite valid, quite reasonable, would be asked so many times that it would eventually be the case that no-one was willing to step up for the thousandth time and explain them. This led, inevitably, to speculation, wrong information and misquoting that would come back to bite everyone later. For no good reason! But the Frequently Asked Questions list fixed that. It allowed all the common questions to be answered, and even for the common controversies to be addressed even if no firm conclusion had been reached. These things grew like crazy in the 1980s and there's massive collections of them out there, still with good information (as long as its a general subject, and not a pop star or the like), and the work of many people coming together to build something good. Like Wikipedia is supposed to be.

I would attest that the reason for the success of the FAQ was a lot of collaborators but a short list of people maintaining it. A very large amount of maintainers leads to infighting, procedural foolishness, and ultimately a very slow advancement schedule. There's an interesting book called The Mythical Man-Month that goes into this in some detail, but the basic idea is: the more people you slap into a project that's behind, the more the project will fall behind. Unintuitive, but true. Even in the case of raw horsepower, this becomes the case; you would think that if the basic job (photocopy this paper) was simple enough, the job would go faster with more people, but it doesn't. You end up with people photocopying stuff wrong, collating wrong, bending pages badly, skipping pages... and the errors increase as you smack more people on. And you fall behind.

Nuevamente, San Luis en promoción tecnológica

A la información anticipada aquí, se le deben agregar algunos detalles publicados el 13 de agosto por Infobae entre otros, comentados a raíz de la exposición San Luis Digital, organizada por la Universidad de la Punta (ULP): quiénes están, qué se hace, y un poco más:
El marco del sector:

El de las TIC es uno de los sectores de mayor expansión del país luego de la devaluación del peso en 2002. Durante el año pasado, la facturación de esta industria alcanzó en todo el país los 5.000 millones de pesos con un nivel de ocupación directa de 41.000 personas. Sus exportaciones pasaron de 60 millones de dólares en 2002 a 300 millones en 2006. En el país existen unas 900 empresas de tecnología registradas. Los indicadores en esta área muestran que creció la ocupación pasando de 14 mil a 47 mil empleos en los últimos cuatro años.

Un aspecto que más de una vez resultó algo oscuro, aquí es comentado: el alcance y aplicación de la ley de promoción del software. Según lo que aquí se afirma, el problema está claro; se trata de una ley nacional, que debe ser aprobada por las provincias:

Las provincias compiten con la Capital Federal, que contiene aun el 70 por ciento de la actividad, pese a que aun no adhirió a la ley nacional de software, que incluye beneficios fiscales para las empresas que tomen personal, certifiquen calidad de procesos y exportan parte de sus servicios o desarrollos.

Es decir, por caso, la provincia de Buenos Aires parece no haber aplicado todavía la ley. Según otra noticia, sólo a partir de marzo de este año, esta provincia adhirió a la ley.
Otro aspecto de base: las iniciativas de informatización de la administración provincial:

[La red de conectividad], denominada “Autopista de la Información”, montada entre 2001 y 2004 por la empresa NEC con una inversión gubernamental de 80 millones de pesos y que une a casi todos los pueblos sanluiseños a través de 830 kilómetros de una red de radio enlace, además de 1.050 organismos públicos que disponen de unas 5 mil PCs conectadas. La red soporta voz sobre IP, por la cual se realizan unas 12 mil llamadas en 950 internos en el Estado.
Unas 35 mil personas, además de los empleados públicos que utilizan la autopista, habían abierto a 2006 sus cuentas de e-mail gratuitas, bajo un dominio e-sanluis.net. Sin embargo, se gestiona un acuerdo con Google para que provea este servicio con su webmail Gmail pero con el dominio e-sanluis.net. A través de la red se pueden tramitar turnos en los hospitales públicos y trámites en el registro civil, como partidas de nacimiento.
Además, este mes la provincia adherirá a la ley de firma digital para procesar sus trámites, también a través de la ULP.

Sobre la orientación de la educación a la formación tecnológica (al menos en los papeles, más allá de la calidad que se pueda garantizar):

[Según explicó la rectora de la ULP, Alicia Bañuelos] El principal diferencial que dicen ofrecer respecto a otras provincias y ciudades es el énfasis en la formación de trabajadores y profesionales con los perfiles tecnológicos demandados por las empresas.
Se trata de uno de los talones de Aquiles del sector TICs argentino, que requiere unos 8 mil profesionales egresados más de los 4 mil que salen anualmente de las universidades e institutos.
La ULP adecuó la currícula de su oferta de carrera tecnológica (tecnicatura en desarrollo de software) a los perfiles reclamados por las compañías, y resolvió no crear por el momento cursadas de grado más allá de los tres años de duración. También el Estado fomenta el estudio de ciencias básicas como la astronomía desde la escuela primaria, de forma de inclinar la vocación de los alumnos hacia las carreras tecnológicas. Además, capacitarán a docentes y empresarios en el uso de aplicaciones de Google.(...)
En la universidad puntana hay 900 alumnos en total, de los cuales 200 están en el área de TICs. Tiene un presupuesto anual de 20 millones de pesos, de los cuales el 15 por ciento se destina a sueldos. Existen becas para alumnos secundarios para que cursen carreras de TICs.

Las empresas que participan, Mercado Libre.com y Unitech:

Durante la muestra [San Luis Digital]se firmó un acuerdo para la instalación de otras seis empresas: Ciliare Software (Novamens), Image Campus, Accendra Networks, Intercomgi, Grupo Tekné y Telesoft. También se anunció la llegada de Competir.com y posiblemente la española Indra radique un centro de investigación y desarrollo. (En la foto, ejecutivos de las empresas firmantes con Alicia Bañuelos).
En el caso de Mercado Libre, estiman llegar a tener unos 100 empleados dentro de un año. Bañuelos estimó a Infobaeprofesional.com que dentro de un año las empresas radicadas tendrán unos mil empleados.

Incentivos económicos:

Subsidio a la masa de salarios del 10 por ciento para los primeros dos años y del 5 por ciento para los dos siguientes.
Se financia el capital de trabajo inicial de la empresa hasta un 70 por ciento, y créditos para financiar exportaciones.
El Gobierno se encarga del 50 por ciento del costo del edificio hasta un millón de pesos. Si la empresa desea alquilar, el Estado se encarga del 10 por ciento del costo por año, con un 1 por ciento que se agrega por cada empleado nuevo, hasta alcanzar el 40 por ciento.

Existe una larga historia de utilización indebida de las promociones, particularmente en San Luis. Quizá en este caso, las reales oportunidades de negocios encaucen las acciones en el camino esperado.

Wikipedia, todavía frágil

Nuevamente, a propósito de la Wikipedia: Ricardo Galli se ocupa de un incidente que muestra la fragilidad actual de la enciclopedia, de una manera insólita: un noticiero de un canal de televisión muestra lo fácil que es participar, alterar y tergiversar información, cometiendo ellos mismos vandalismo en alguna entrada. Conocí la noticia por Barrapunto.
Sumadas a las recientes noticias de alteraciones interesadas, se evidencia que el procedimiento de certificar a los participantes deberá seguir ajustándose, así como la verificación de las notas incorporadas. Sin embargo, la enciclopedia colectiva sigue creciendo.

¿A alguien le interesa James Martin en la Wikipedia?

Internet es fugaz y veleidoso...Una página, un artículo, puede no estar mañana. Una persona puede ser importante hoy, y sumar millones de referencias, y no tener lugar mañana...Me ha pasado con Sugoi!, una página argentina que solía seguir con notas sobre oriente, que de pronto enmudeció(1). ¿Quiénes eran los editores? ¿Dónde están?. Por suerte tengo el archivo de Internet para seguirles el rastro histórico, pero eso no quita que de pronto sean tan historia como una vida común...La tecnología, más fugaz que el papel (2).
Pero la observación está destinada a James Martin, en este caso. Tenía interés en agregar al artículo anterior un enlace sobre uno o dos de sus conceptos precursores, y acudí a la Wikipedia, para encontrar un artículo bastante elemental, y sujeto a cuestionamiento por la autoridad de Wikipedia "por su falta de referencias y fuentes". No sé muy bien qué se entiende por falta de referencias, cuando se están afirmando proposiciones que definen una persona. En fin, me anoté en la versión inglesa, averiguaré qué clase de referencias se requieren, y trataré de anotarlas, o recurrir a quienes puedan hacerle justicia. Al fin, Martin y Finkelstein todavía viven, y al menos ellos pueden defenderse. El caso de Martin es el de muchos otros, como por ejemplo Bob Bemer, de quien incluso desapareciera su página y su última referencia fuera el reclamo de su host por el pago del servicio de hospedaje. Quizá incluso Yourdon siga el mismo camino en pocos años más...

(1) Sugoi! está de nuevo. Acabo de comprobarlo. Aunque no entrega nuevos comentarios desde mayo, probablemente lo hará pronto, lo que no invalida la fugacidad de la vida en Internet. En todo caso, trataré ahora de tomar contacto con sus autores, para al menos establecer una línea de comunicación más durable.
(2) Por eso acostumbro a registrar citas completas y no referencias a lo dicho por otros. Porque un enlace a un tercero está sujeto a variabilidad, y es poco confiable. Mejor es transcribir lo pertinente, y comentarlo si hace falta. En ese caso, me hago responsable de mi propia variabilidad, tampoco garantizable.

Angel "Java" López y AJGenesis

Angel López, a quien leo habitualmente con mi Google Reader, está desarrollando varios artículos sobre su emprendimiento AJGenesis, al que tipifica como generador de aplicaciones. Su idea es muy familiar para el universo de desarrollo basado en modelos, en términos generales. Ángel establece estas premisas para crear un generador de código:

¿Qué le pediríamos entonces, a un generador de código? Gran pregunta, intentemos algunas respuestas:
- Que genere código que hubiéramos generado nosotros: si genera código inentendible, estamos en mal camino. Ese es el problema de varios wizards y demás herramientas: hacen lo que ellas quieren, no lo que nosotros queremos.
- Que genere cualquier texto que nos imaginemos que necesitamos: no basta que genere lo que el generador de código decida. Debe ser lo bastante flexible, para que podamos generar lo que querramos: desde una simple entidad, a un mapeo de Hibernate, desde una página web, hasta un mensaje de Windows Communication Foundation, desde el archivo de configuración de Struts, hasta el interminable ejb-jar.xml que nos pide el JBoss versión 17.84 que tengamos el año que viene.
- Que parta de un modelo simple, o compuesto, pero libre: no que parta de una base de datos, y sólo genere entidades y mapeadores. Necesitamos más flexibilidad. Ya vimos los que nos pasa en la vida real: todo cambia, necesitamos multitud de artefactos. Cualquier inversión en un generador de código que no permita incluir un modelo libre, me parece riesgosa. Creo que como prueba ácida, le pediría a un generador, que permita, desde un modelo libre, generar todo programa "Hello, World" que se nos ocurra. Si una herramienta no puede obtener ese resultado, estamos en el horno.
- Que permita escribir los templates, plantillas que querramos, y generarlas en grupo, en serie, en paralelo, o como querramos. Tanto el orden y enumeración de artefactos a generar, como las plantillas, como la toma de decisiones (generar de tal forma o no), debe estar bajo control del utilitario, y bajo control nuestro.
- Que permita generar desde un modelo, al cambiarlo, de forma fácil: si para generar los artefactos, por un cambio en el modelo, hay que dar cuarenta pasos, de nuevo estamos en problema. Compilar hoy es una tecla. Lo mismo debe ser la generación de código.

AJGenesis no tiene por ahora documentación, pero sí se puede tener una idea de su alcance a través de los ejemplos de uso en construcción, y los comentarios a éstos:

Quisiera en este artículo, comentar cómo funciona y se construye, uno de esos ejemplos. Permítanme primero repasar algo sobre el proyecto.
Está escrito en Visual Basic .NET 1.x, y es código abierto, pues viene con una licencia tipo BSD, que permite utilizarlo en cualquier proyecto que quieran. Se puede usar como librería, invocado desde nuestro proyecto, se puede invocar desde la línea de comando, o puede ser utilizado desde el poderoso NAnt (esto último me permitió organizar mejor las tareas que realiza el generador de código).
En la página del proyecto (y en el proyecto mismo) hay varios ejemplos, que generan código desde un modelo, usando plantillas. Los ejemplos generan código PHP, Java, JSP, VB.NET, C#, ASP.NET, y hasta scripts de base de datos y procedimientos almacenados. Quisiera destacar dos puntos:
- El modelo del que parte es totalmente definible por el usuario
- Las tareas y plantillas a aplicar son totalmente programables y controlables
Esto lo diferencia de otros generadores. Podemos construirnos nuestro propio modelo, y sus propias plantillas, para generar los artefactos de texto que prefiera. Otros sistemas parten de la base de datos, y sólo generan un grupo de artefactos de textos predefinidos (por ejemplo, POJOs, plain old java objects, o DAOs, Data Access Objects). Pero con AjGenesis puede generar el artefacto de texto que se nos ocurra.

[AJGenesis]Se basa en:

- Tener un modelo totalmente libre, que hoy está serializado en archivos XML.

- Plantillas que generan artefactos de texto

- Tareas programables, que cargan los modelos, ejecutan lo que uno quiera, y son invocables desde programas nuestros, desde la línea de comando, o desde un utilitario como el NAnt.

Entonces, se arma uno o varios modelos, que expresan lo que Uds quieran de su sistema, de forma independiente de la plataforma, y luego, adosándole modelos (uno o varios, de nuevo libres), que indican la tecnología a usar, y escribiendo las plantillas que Uds. quieran, generan lo que se les ocurra.

Ángel también explica su concepto a través de lo que No desea de un generador:

Primero: el generador sólo genera lo que él quiere. Típico de generadores "profesionales", que sólo producen lo que los creadores del generador imaginaron. Es difícil, y en algunos casos, imposible, extenderlo más allá de lo que hacen actualmente. Variante de esto: sólo genera código para entidades, o sólo para una tecnología, o sólo para EJB, o sólo para.... y puedo seguir. Claro, la herramienta soluciona el problema, y al comienzo estamos chochos de haberla encontrado. Pero advertiría desde ahora, que encontrarán limitaciones.
Segundo: el generador sólo parte de un modelo predeterminado (típicamente de una estructura de tablas de base de datos). Creo haberlos convencido que hay más bajo el sol que generar entidades y mapeadores. Hay colecciones inmensas de artefactos que tenemos que generar en cualquier sistema no trivial. Y seguirán apareciendo, por lo menos, en el futuro cercano. Si el generador sólo está pensado para partir de un modelo determinado, nos limita en lo que podemos pedirle. La historia nos ha mostrado, que siempre necesitamos algo más.
Tercero: el generador es cerrado, no se puede aprovechar e integrar en sistemas nuestros, o no entrega el código de base, o no permite armar plantillas y demás auxiliares.
Puedo seguir enumerando problemas. Mencionemos uno más: hay quien menciona que utilizó generadores de código, pero sólo lo usa para generar el código inicial de un sistema, y luego ya modifica el código generado, y no puede regenerar sin perder los cambios que hizo. Sugerencia: pongan en claro qué artefactos se generan automáticamente, y cuáles son los generados manualmente. Cuando Uds compilan un ejecutable, y necesitan cambiar un algoritmo, no van y cambian los bits del .exe. No: van al modelo, al lenguaje de programación, lo cambian y compilan de nuevo. Lo mismo deberíamos conseguir algún día, con generación de código. Como no podemos generar todo, debemos tener la disciplina de decidir cuáles artefactos son generados por el utilitario, y cuáles son los artefactos nuestros. En algunos casos, en los repositorios de código, en un CVS, cuando se trabaja en grupo, NO SE GUARDA lo generado automáticamente: solamente se guarda el modelo, y lo generado manualmente. Esto refuerza la responsabilidad de no tocar ese código automático: cualquier cambio manual que hagamos sobre ellos, no se guardará en el repositorio común.

(...) De alguna forma, un generador de código ideal no estará atado a una tecnología. Siempre habrá alguna "better mousetrap", siempre alguien inventará alguna nueva forma de hacer algo, siempre habrá un ruso con insomnio, o un hindú sin novia, que no tiene otra cosa que hacer que crear algo nuevo, ya sea en forma de librería, framework, patrón, o estilo arquitectónico. Un generador de código debe ser agnóstico de la tecnología, de las modas, de las soluciones actuales y futuras.

El generador de código que adoptemos, debe poder adaptarse a lo que querramos hoy y mañana y pasado mañana. La estrategia es: no importa la tecnología, el patrón o el framework que aparezca, nuestro generador deberá aprovecharse de lo que surja.

Estas premisas son familiares. Ángel propone una vía de trabajo que es la preocupación de la actual generación de creadores e investigadores de herramientas para el desarrollo de software "industrial". (Otra vez habrá que explicar qué significa esto?). Me interesa, y aunque mi disponibilidad de tiempo es menor que cero, trataré de seguirlo. Me interesa en la medida que escucho "plantillas", "scripts", "modelos"...
Diría que es importante no perder de vista que cuando hablamos de generadores hoy, no debe pensarse en las herramientas de la década del 80, rígidas y de alcance limitado. Tanto en el propósito como en la existencia real de las múltiples herramientas existentes, es posible ser expresivo, tener control, y soportar un ciclo de desarrollo más o menos completo.
Construír una herramienta es tarea de un equipo de desarrollo, probablemente más o menos numeroso. Seguiré con interés su propuesta.
Con Ángel hemos hablado, en cierta forma. Esta es mi primera nota sobre su trabajo, porque, si bien hace varios días me dedicó dos palabras, esta mañana de sábado es mi primera disponible (esto no le importa a nadie excepto a Ángel en todo caso). Le escribiré este fin de semana, porque debo agradecerle su elogio, y porque quiero conocer más su proyecto.
Quisiera decir que un aspecto importante de su trabajo, como es el caso de otros que trato de seguir, es el interés en progresar en la elaboración de herramientas de mayor flexibilidad y alcance en la generación de código.
En uno de sus artículos, Emilio, un desarrollador español, le apunta que le falta a Ángel referirse a MDA como sustento de su elaboración. El apunte es pertinente en términos generales, si queremos hablar de fundamentación de las condiciones de desarrollo de un generador. Pero muy en parte, porque MDA implica un estándar más o menos determinado (UML, OCL, un esquema definido de transformaciones). AJGenesis no parece estar en este marco. Y por lo demás, el estándar de la OMG está abierto y en evolución, y tiene sus puntos débiles: la expresividad de UML para desarrollar el detalle del comportamiento de un modelo quizá alcance, pero quizá también requiera un trabajo excesivo. En este sentido, siempre me pareció mejor la vieja solución de James Martin (diagramas de acción), que es la que empleo con Plex: un metalenguaje que describa en términos abstractos las acciones, suficientemente flexible y suficientemente detallable como para expresar en un párrafo lo que de otra manera puede significar trabajar duro en diagramas de actividad y de estados. Otro aspecto que no veo todavía manejado, y que es un desafío en muchos casos, es el versionamiento. MDA trata bien la variación por plataforma, pero no veo muy bien expresado el manejo de versión, salvo que no sea el abrir un nuevo modelo para cada versión requerida. Y otro aspecto, puntualizado correctamente por Greenfield con su Software Factory, es el seguimiento y mantenimiento del conjunto de dependencias de un proyecto.
En fin, el problema está abierto, y muchos, como Ángel, lo atacan con nuevas y mejoradas ideas y herramientas. Quiero mencionar de nuevo a Emilio, miembro desconocido para mí de una empresa española (que tampoco conocía) que trabaja con MDA: es interesante seguir el laboratorio que existe en algunas universidades españolas sobre este tipo de proyectos, tanto en Málaga, como en Alicante, como en Valencia, para mencionar a quienes sigo más de cerca.

TI: China e India crecen...

Clarín informa hoy que Lenovo, la compañia china que adquiriera la división de computadores personales de IBM, formalizó un preacuerdo para la compra de Packard Bell. Así, la penetración de China continúa creciendo en el mercado de hardware. En software, todavía débil presencia:
En Clarín:

El comunicado que el fabricante chino de ordenadores personales remitió a la Bolsa de Hong Kong reconocía haber alcanzado un acuerdo de intenciones con "un tercero independiente" en relación a la compra del fabricante europeo de ordenadores Packard Bell.
Lenovo actualmente está realizando las investigaciones necesarias con terceros y entidades gubernamentales en preparación para celebrar acuerdos definitivos. La empresa recordó a sus accionistas y a los potenciales inversores que "la adquisición propuesta podría o no materializarse".
Lenovo se formó tras la adquisición de la División de Informática Personal de IBM por parte de Lenovo Group. Tiene centros de investigación en Yamato, Japón; Pekín, Shangai y Censen, China y Raleigh, Carolina del Norte.

Mientras tanto, India crece también, pero en el área de software y servicios. Aquí, la noticia viene de Wipro, que elimina un competidor en outsourcing, y pone un pie en Estados Unidos. La noticia en New York Times:

The Indian outsourcing company Wipro said that it was buying Infocrossing, an outsourcing company based in New Jersey, in a deal that values Infocrossing at about $600 million. Wipro will pay $18.70 a share for Infocrossing, which provides information technology services to midsize companies in the United States and had sales of $229 million last year. The price represents a premium of about 6 percent over the closing price Friday for Infocrossing. The company operates five data centers and employs about 900 people. Wipro is based in Bangalore.

Penetración de Internet en Latinoamérica, según ComScore

Noticia tomada de América Economía, comentando un estudio de ComScore:

Bob Ivins, vicepresidente ejecutivo de Mercados Internacionales de comScore, señala en un comunicado que "debido a su tamaño y su rápido desarrollo, la industria de internet en América Latina es un campo estimulante para su seguimiento y análisis. Hace años que desde comScore informamos sobre los datos de navegación específicos por país, pero esta es la primera vez que comparamos mediciones de toda la región".
La investigación está basada en datos recopilados mediante el servicio de evaluación de audiencia comScore World Metrix. Los resultados contemplan la conducta en línea de los usuarios latinoamericanos de internet de 15 años de edad o más que accedieron a la web desde el hogar o el trabajo en junio del 2007.
Entre sus datos más destacados se encuentran que Brasil registra la mayor cantidad de población en línea, con 15,8 millones de usuarios. A su vez, Chile con el 45% de su población en línea, tuvo la mayor penetración de internet. Otro dato relevante es que el usuario latinoamericano promedio pasó 29 horas en línea en el mes, más que el promedio global de 25 horas.
En Argentina fueron los más activos de toda la región, con un acceso promedio a internet de 17,7 días al mes, casi un día más que el promedio mundial. Mientras tanto, el usuario brasileño visualizó, en promedio, 3,371 páginas durante el mes, 40% más que el promedio latinoamericano de 2,338.

AméricaEconomía reproduce y comenta tres cuadros publicados por ComScore.
Loa dos más significativos se ven arriba.
AmericaEconomía compara estos datos con los resultantes de un estudio similar de ComScore en Europa y Estados Unidos:

Para dimensionar estos datos y aunque siempre resulten odiosas las comparaciones, los resultados de esta investigación se pueden analizar con otro estudio de esta misma consultora, con datos de Europa y Estados Unidos. La única diferencia es que dicha investigación se realizó durante el mes de abril. En ella se establece que Europa tiene un promedio de accesos diarios a internet de 122 millones, mientras que en Estados Unidos llega a 114 millones. Aún cifras muy lejanas a la realidad latinoamericana.
El europeo medio accede a la red desde casa y desde la oficina una media de 15,5 días y pasa 24 horas viendo 2662 páginas al mes. A su vez, se determina que Holanda y los países escandinavos tienen el mayor porcentaje de población que accede a internet, entre un 68% y un 83%. Por su parte, Alemania tiene la mayor cantidad de personas accediendo a la red con 32,6 millones, mientras que Reino Unido tiene los internautas más activos con el mayor numero de navegantes diarios, 21,8 millones, el mayor número de días al mes de uso, 21 por usuario, y el mayor número de horas al mes por usuario, 34,4 horas.
Los países que están por debajo de la media de uso europeo de 16,5 días al mes son: Rusia (11,4 días), Austria (12,0), Italia (12,9), Irlanda (13,0), Portugal (13,4), Noruega y Dinamarca (14,7), Suiza (15,1), Bélgica (15,5) y Finlandia (16,4).

El tercer cuadro lista las empresas o dominios con mayor acceso: en los cuatro primeros sitios aparecen, en ese orden, Microsoft, Google, Yahoo, y Terra. Como la revista acota, esto implica un uso preferente de Internet como red social. Queda todavía un largo camino por recorrer.

Nuevo sitio del foro de usuarios de Plex

Esta noticia tiene ya algunas semanas...De interés para quienes sean usuarios de Plex: El foro de Plex tiene nuevo alojamiento, y volverá a cambiar en algún momento en el futuro. Ahora volvió a su viejo servidor de Pugmarks, y fundamentalmente, no perdió su repositorio. Al menos en mi caso, las distintas búsquedas que hice sobre varios tópicos, trajeron resultados antiguos, hasta su orígen posterior a Synposium. Se puede encontrar la dirección en la wiki de Plex, pero lo recuerdo para quienes usan la vieja dirección, y encuentran sólo el foro de Gen. En realidad, allí ahora también hay una guía al nuevo sitio, y podemos esperar que cuando se produzca nuevamente un cambio, allí se podrá saber dónde ir.

Dos actualizaciones sobre Plex

Esta semana, dos noticias sobre Plex (finalmente, CA renombró Plex como siempre se debió llamar (al menos desde que dejó de ser Obsydian): una, de interés general, que es el lanzamiento de la versión 6.0. De la noticia oficial:

CA Plex r6 is Now GA
The highly anticipated CA Plex r6 is now available.

Building on the evolution of the Windows Server environment, CA Plex r6 enables the development of .NET applications in addition to the existing supported platforms: J2EE and the IBM System i. Some of the new features available include:

C# Server Generator: CA Plex generates 100% of the required code for the .NET platform utilizing technologies such as OLE DB for data access. Rich interoperability with other
CA Plex-supported platforms is provided via remote calls to Java and System i enabling applications to be deployed in a variety of n-tier configurations.
.NET Management Console: This provides a quick and simple way to configure the .NET server to interact with all other CA Plex-supported server platforms. The XML-based configuration files synonymous with .NET can be managed from a single, easy-to-use interface.
Visual Studio 2005 Support: The CA Plex .NET Runtime exploits .NET Datasets to enable easy integration with systems coded in Visual Studio 2005.
ANT and MSBUILD Support: Furthering support for mainstream technology in CA Plex, this release features the ability to use the open source Apache ANT tool for Java builds, or Microsoft MSBuild for .NET. This results in a single build environment that is extensible and provides higher levels of performance.
Code Libraries: This provides a model-based approach to the creation and deployment of Java JAR or .NET Assembly DLL files. A default code library is created by CA Plex automatically which is especially useful for unit testing. For deployment, specific code libraries can be designed and a new Code Library Wizard automates their creation.
System i Updates: CA Plex continues to provide support for the IBM System i (formerly iSeries, AS/400) server, adding support for long and mixed-case passwords. Connections to the System i from other CA Plex-supported platforms (Java or Windows/.NET) fully support this new feature.

La noticia fue publicada, entre otros, por The Server Side, y por IT Jungle. Esta última se extiende algo más sobre Plex y 2E, en particular sobre la utilización en la construcción de servicios web:

[Bill Hunt, Gerente de Producto] sees Plex (and 2E to a lesser extent) playing more important roles as organizations begin developing and using Web services and the service oriented architecture (SOA) concept. "Plex and 2E are model-driven tools. As the concept, the methodology of SOA becomes more important, the importance of being able to reuse data is more prevalent, and an excellent and effective way to do that is through model-driven development," he says.
One CA customer that has already made use of Plex's Web service capabilities is CCH, a division of the Wolters Kluwer company that develops tax, accounting, and audit software that runs on i5/OS and Windows. CCH obtained outstanding productivity gains and cost savings by using CA Plex r6 as the primary tool to build its CertiTAX and ZipSales Returns solutions, says CCH development manager Victor Herr.
"With CA Plex, we were able to leverage existing client/server and System i-based skill sets to deliver award-winning solutions with next-generation Web services," Herr says. "We have such confidence in CA Plex that we used the beta version of r6 to build our next-generation sales tax application, which we plan to launch later this fall."
Hunt says the flexibility Plex afforded to CCH is typical. "This is not about, 'Hey get off the AS/400,'" he says. "They continue to sell the AS/400 product, because they have customers that need it."

La segunda noticia de la semana: CA fija fecha para el retiro de soporte de la versión 5.1 de Plex. Será el 27 de mayo de 2008. Un año por delante para programar una actualización, a 5.50 si se tiene un criterio conservador, o a 6.0 si se desea sacar provecho de las nuevas características de esta versión. Esta es una noticia importante porque existe un numero apreciable de empresas que aún mantienen sus aplicaciones en 5.1.