Autor: ecardenas

Mentores ¿dentro o fuera del proyecto?

Posted on by ecardenas

La verdad es que no habia pensado en el tema, a pesar de tener una posición clara sobre ello, hasta que hoy en la mañana vi unos twitts que remitian a este twitt: «¿Debería ser el jefe de proyecto tu mentor? ¿Q figura es la q debería acompañarte en tu desarrollo profesional?», lo cual me llevo a pensar en dos experiencias personales respecto a la figura del mentor…

Hace unos años di un cambio profesional, y con ello fue introducido a la figura de Career Manager, un profesional de rango mas avanzado en la organización, el cual debería ayudarte a identificar tus puntos de mejora para seguir avanzando, realizar la evaluación de desempeño (preguntándole a tus jefes, pues ojo a esto, el CM, salvo excepciones, no puede estar en el mismo proyecto que el supervisado), a la vez que proveerte de información de como se esta moviendo la organización, ademas de ser una figura informal de «abogado» en las relaciones con tus superiores.

Lógicamente que todo esto forma parte de un proceso mas o menos burocrático dentro de las organizaciones, pero que en el fondo tiene mucho sentido, pues gracias a mi primer CM pude aprender diversos detalles de la cultura de la organización, y conseguir apoyo para los planes de formación y sobre todo algo que siempre recordare, el como intercedió por mi cuando un responsable de proyecto quiso hacer una jugada con la imputación de horas.

Durante ese tiempo, también tuve ocasión de trabajar con colegas en las que su mentor era precisamente el Jefe de Proyecto, lo cual me intrigo haciéndome conversar informalmente con ellos a fin de saber que opinaban de la figura, sacando la conclusión de que si bien en este modelo el mentor, al ser tu jefe, tiene la información de «primera mano» sobre tu desempeño, no permite generar la suficiente confianza como para que haya una relación fluida en la que el mentorado pueda confiar totalmente sobre los problemas directos de la marcha del proyecto.

Tuve ocasión de comprobar eso directamente, pues al final se me designo sucesivamente como CM de dos programadores junior, así que ante el reto trate de ganarme la confianza de mi mentorado, explicándole lo que había visto en la organización, el enfoque de hacer las cosas y lo que se esperaba de nosotros, calculo que debí darle suficiente confianza, pues un día me llama prácticamente desesperado ¿qué había pasado? un analista se retiraba a otro modulo de su proyecto, dejandole a él parte de sus responsabilidades técnicas, lo cual le asustaba pues eran temas que solo había visto ligeramente, y claro, le asustaba decirle eso a su jefe de proyecto, por lo que luego de tranquilizarlo procedí llamar tanto al responsable de los CM como a su jefe para saber lo que había pasado, la cosa era sencilla, eran necesidades de negocio, estaban alerta de que era un reto, así que no habría tanta presión en un primer momento mientras se adecuara; así que con esa información me toco transmitirle un mensaje tranquilizador, lo cual funciono pues unos meses despues, cuando me toco proceder a la evaluación, me confeso que no era tan fiero el león como se lo pintaba.

Así que por esta experiencia directa, creo que un mentor o CM no debería (salvo coyunturas) ser directamente el jefe del mentorado, siempre queda un conjunto de cosas en la cual se necesita cierta confianza que tal vez no se pueda tener dentro del propio proyecto. Dicho esto, soy consciente de que cuando se avanza en la pirámide no hay tanto margen para asignar responsables que no sean los jefes directos, pero es algo que se debería procurar en la medida de lo posible.

¿En qué clase de empresa te gustaria trabajar y en cual no?

Posted on by ecardenas

A veces un hecho fortuito te llama a la reflexion, ayer recibi una llamada de un headhunter que me hizo un entrevista telefonica para incorporarme a su base de datos, a fin de que con suerte esto derive en un proceso de selección posterior, entre las diversas preguntas (algunas clasicas, algunas nuevas) hubo una que casi que me cogio con la guardia baja y fue la que da titulo a este post ¿En qué clase de empresa te gustaria trabajar y en cual no?, logicamente para esta clase de preguntas la respuesta tiene que ser rapida, asi que solo atine a decir que me gustaria trabajar en una empresa que da importancia a las tecnologias de la informacion como herramienta importante de sus diversos procesos de negocio, pues partiendo de esa base se ve como va a tratar a la gente de tecnologia (yo entre ellos, ejem ejem), por lo cual esto es un punto de partida para todo.

Tal vez mi improvisada respuesta puede parecer un poco obvia, pero a poco de pensar te das cuenta que en realidad «estas pidiendo mucho» pues el dia a dia te demuestra que ese enfoque no es el seguido por un buen numero de empresas, siendo el caso de que la parte de IT se ve como algo colateral, y no vinculado al core del negocio.

Una de las ideas mas claras de este «enfoque» viene dada cuando la empresa decide que los tecnologos no son «core» del negocio, por lo que si bien requieren contar con ellos, casi solo un milagro hara que se fiche a un Analista Senior (y ya no te digo un Programador), a pesar de su continuidad, lo cual deriva en las situaciones que ya comente hace un tiempo.

Esta situación ha evolucionado hacia decisiones en la que una empresa externa asume, ya no el contrato para el desarrollo/implantación de una nueva aplicación, sino la gestion total de todos los procesos de IT, a fin de que la empresa contratante se centre en el «core del negocio» pues «nuestro negocio es vender XX no hacer programas», ademas de procurarse un ahorro de costes o el convertir lo que es un gasto fijo en un gasto variable, todo bien desde el punto de vista financiero o administrativo, pero a la larga implica un debilitamiento del propio conocimiento de la organización sobre lo que ellos tienen, o como dijo una compañera hace tiempo «en cada transferencia (de conocimiento) algo de conocimiento se termina perdiendo», y ese fenomeno es lo que a la larga reduce las capacidades de la empresa para reaccionar prontamente ante los retos del mercado.

Esto no debe tenderse por ir hacia la postura de que la empresa debe de «hacerlo todo», sino en el hecho de que no se debe renunciar totalmente a la gestion de IT y al conocimiento detras de el, tanto en las operaciones del dia a dia como en la elección correcta del proveedor(*) para las necesidades que hagan falta, es que hasta en eso se dan errores como cuando hace poco se me pidio dar mi opinion para un nuevo software que se tenia que comprar (por requerimiento legal, no por necesidad de negocio), no me tardo mucho ver que la propuesta no valia la pena, pues dicho software estaba hecho en una herramienta que fue descontinuada por su proveedor hace 4 años, pero por si eso fuera poco el desarrollo estaba cerrado a un esquema que no contemplaba ciertas peculiaridades del modelo de negocio/producto de la empresa, por lo que necesariamente tendria que haber una «personalizacion» que en este caso no seria tan solo de reportes o «alguna pantalla extra» sino de la estructura basica del modelo de base de datos, con esa percepción recomende continuar con la busqueda de alguna otra oferta, pero no se me hizo caso, siendo este otro escenario de cuando las tecnologias de la informacion no son tomadas en serio por la organización.

Otro tanto puede decirse de las empresas que presumen de serias y con cierta facturacion, pero que no tienen pagina web o peor aun…. pareciera que el diseño de su site ha pasado por un proceso caotico.

Regresando a la pregunta original, tambien podria decir que seria un reto el integrar una organizacón que este dispuesta o en proceso de darle importancia a TI como herramienta para mejorar sus resultados, mejor ¿no?

Visto lo visto…. ¿Que tan en serio crees que las empresas se toman al departamento de TI en su empresa?

(*) Que al final de cuentas sabe algo de tecnologia que tu no, pero que viene a ayudarte en tu negocio, no a llevar el negocio por ti.

En defensa de Visual Basic.Net y las «buenas practicas»

Posted on by ecardenas

Primero el Disclaimer: La herramienta a la que le tengo mas cariño y con la que he sido mas productivo es Borland Delphi (ahora Embarcadero, pero la que yo conocí era de Borland), dicho esto pasemos al grano.

El titulo del post proviene a razón de la ultima sesión de Mad.Nug en la que Jorge Serrano compartió su experiencia sobre las posibles acciones a tomar cuando se tienen aplicaciones en Visual Basic 6 y existe la necesidad/presion/requerimiento de migrarlas a .Net, la sesion fue muy explicativa, recordandonos cuales son los puntos donde hay mas incompatibilidades y las posibles opciones:

– Herramienta de migración automática
– Entorno mixto (Microsoft Interop Forms Toolkit 2.1 y wrappers)
– Empezar todo desde cero.

De acuerdo a su experiencia (corrígeme si te estoy referenciando mal, Jorge) debería procurarse por la ultima opción (en ese sentido Jorge facilito un buen enfoque para acometer esos proyectos), y estar alertas ante el riesgo de que una solución puntual como un entorno mixto crezca y pierdas el control.

Si bien comparto la idea de que hay casos en que no queda otra que proceder de esa manera, creo que esa decisión tiene que ser sopesada teniendo en cuenta criterios como: cantidad de lineas de código existente, dependencia de terceros, disponibilidad de conocimiento funcional, etc… en ese sentido se sintió la falta de cubrir posibles estrategias de cuando se ha decidido ir por el camino de la migración (que igual se hace para algunas aplicaciones, dejando el resto a un rehacer desde cero).

Bueno, a lo que iba, como parte del camino de un rehacer desde 0, Jorge planteo que había que procurar migrar hacia C# en lugar de hacia VB.Net, ¿por qué? es lo que nunca me queda claro, salvo por un hecho (mencionado en la reunión) que es la mayor disponibilidad de recursos en Internet para C# que para VB.Net, pero fuera de ello el acceso hacia el Framework de .Net es básicamente el mismo (salvo excepción que contare luego), por lo que también en la conversación con los asistentes se dejo caer que con C# se es mas ordenado y se encamina hacia las buenas practicas, por lo que ya entramos a un tema de preferencias y es a donde quería llegar.

Admitamoslo, por sus propias características en Visual Basic 6 era muy muy fácil desarrollar con malas practicas y que el código spaghetti generado sea muy difícil de mantener, pero si una cosa tiene Visual Basic .Net es que significo una ruptura sin pasos intermedios con respecto a VB6 a fin de volverlo OOP y compatible con el nuevo Framework (*), y por lo tanto mucha de la laxitud inherente al viejo VB6 ya no existe, es un buen lenguaje OOP y muy valido para aprovechar los conocimientos de sintaxis propios de Basic: Dim, as, Next, End…, el problema gordo es la herencia de mala imagen que lastra el lenguaje, asi que explicar a un manager que seria menos traumatico continuar con VB.Net en vez de C#…. complicado, triste realidad.

Siendo así creo que solo hay dos razones no personales para optar por desarrollar un proyecto en C#:
– Es muy critico contar con todos los recursos de documentación disponibles para un tema en concreto, que lamentablemente en su mayoría están en C# (p.ej. hay casi tres veces mas info para Generics en C# que para Visual Basic).
– Te ha tocado acceder a una parte del Framework que expone justamente un tipo de datos existente en C# pero no en Visual Basic.Net, eso me paso con la versión 1.1, no se si lo habrán solucionado, pero … queda como alerta.

En contraparte tengo algunas razones de productividad para seguir usando VB.Net siempre que puedo:
– Detección automática de algunos errores y de su corrección, esa potencia de mostrarte un subrayado en algunos errores de sintaxis es de veras de agradecerse, y lo mismo con el hecho de que si compilas y saltan errores no tienes que recompilar para ver si has corregido bien o no, conforme vas corrigiendo tu pila de errores se reduce.
– No sensible a las mayúsculas/minúsculas, esta característica va de la mano con lo anterior, si defines bien una variable (usando Camel y Pascal case adecuadamente) y luego la invocas, el hecho de que se te auto corrijan las mayúsculas y minúsculas es una señal inmediata de que no te has equivocado al invocar el nombre de dicha variable.
– Las instrucciones (begin..end..next..) son mas claras que las llaves ({}) para poder hacerse una idea del ámbito de un bloque de código.

Dicho esto, como desarrollador he venido a conocer ambos lenguajes, pero lo fundamental es el Framework, siendo que el saber C# me ha facilitado acceder a ciertos recursos no existentes para VB.Net, pero que luego a la hora de implementar no he vacilado en aplicarlos sobre proyectos en VB.Net, así que es bueno saber ambos, pero uno no debería de inhibirse y proponer el uso de VB.Net en los proyectos.

Pero algo se me quedo dando vueltas ya desde la sesión a propósito de eso de que C# te ayuda a ser mas ordenado (o algo así), y a esto se sumo el comentario de uno de los asistentes comento que ellos tenían una aplicación grande en VB6, basada en COM+/MTS, hecha según las recomendaciones que daba Microsoft por entonces para el desarrollo en COM, lo cual me hizo retroceder a la época en que este diagrama salia en toda presentación de arquitectura y diseño de aplicaciones alla por el final de los 90s:

Pongámonos en contexto, para el lanzamiento de Visual Basic 6, ya había un gran parque de aplicaciones en VB4 y VB5, pero la fama del «DLL Hell» ya era muy fuerte, así que Microsoft emprendió una campaña muy intensiva para explicar el concepto de desarrollo de aplicaciones distribuidas, las ventajas del multicapas en la mantenibilidad de las aplicaciones, etc etc… conceptos que ahora son el pan de cada día en los objetivos de los diversos proyectos actuales, fueron recien conocidos para muchos gracias a Microsoft, y la verdad es que en ese entonces Microsoft se preocupo mucho en hacer pedagogía de las buenas practicas, tan así que en los cursos de certificación se hacia énfasis en lo que hay detras de la instanciación de objetos en COM para de esa manera impulsar formas mas ordenadas de programar, y lo bueno de todo es que esa pedagogía era de manera no agresiva, planteándola como una evolución de las aplicaciones que habia en desarrollo entonces, a fin de que los programadores mejoraran sus practicas frente a la fama de caos, o sea se pugnaba (por entonces) un cambio evolutivo en las formas de hacer las cosas apoyándose en lo que los desarrolladores ya conocían, lo cual condujo a que los partners serios si que hicieran aplicaciones buenas y solidas usando VB6.

Para bien o para mal todo cambia con la introducción de .Net, que como ya hemos indicado en este y otros posts vino a ser un ruptura muy fuerte, en la que sobrevivía el que tenia mejor las bases de OOP y/o Windows DNA. Claro, ya lo peor paso (salvo las app VB6 que se resisten a morir) y la cosa esta mas o menos estabilizada, salvo por la nueva tendencia del famoso patron SOLID, sobre el cual ya comente que tenia mis dudas sobre si facilitaban la mantenibilidad de las aplicaciones, pero que en todo caso hay que entenderlas y saber como y cuando aplicarlas, siempre sin dogmatismos.

Y es justamente que ahora los dogmatismos se hacen presentes, pues en lugar de introducirnos progresivamente a las nuevas «buenas practicas» se nos pide que ya no usemos ni Windows Forms (aunque si, podríamos pasar a WPF) ni Windows Forms, diciendonos que «no es testeable» «no permite xxx principio» de buenas a primeras sin mostrar evolutivamente como mejorar el código que estamos desarrollando, de ahi a lo que dije en un twitt reciente: Si nos explicasen las pruebas unitarias con ejemplos basados en multicontroles, eventos y mantenimientos, igual las adoptariamos #digonomas (o este otro), digo eso porque la mayoría de las aplicaciones corporativas de uso interno (no portales de contenido) terminan siendo eso y no los clásicos ejemplos de calculadoras o números perfectos, así que seria bueno que los planteamientos de difusión sobre TDD o SOLID partan de un enfoque evolutivo y no rupturista (dando cobertura tanto a VB.Net como C#) a fin de lograr una mejor adopción.

A ver si no llega alguien por aquí diciendo que he «perdido el punto»… xD

(*) Y si, sigo creyendo que muchos traumas se hubieran evitado si al hacer .Net (y C#) se hubiera mirado lo que tenia VB6 a fin de hacer la ruptura menos dolorosa.

Pensando en estrategias de migración de VB6 a VB.Net

Posted on by ecardenas

Casi a hilo de lo que comentaba en el anterior post, hace poco Jorge Serrano publico Cada vez que migras una línea de código de VB6 a .NET se muere un gatito en el mundo, interesantisimo post que vale la pena leer pues resume muy bien los dilemas, actitudes,creencias erróneas y decisiones que se acometen cuando se tienen aplicaciones en Visual Basic 6 y se piensa el migrar a .Net como una opción a considerar.

Me detendré poco en el tema de la discusión de si migrar si o migrar no, pero en mi modesta opinión creo que los criterios de discusión deberían girar alrededor de (entre otras) estas preguntas:
– ¿Qué tan diferente son los procesos de negocio de la organización de como eran cuando la aplicación fue construida?
– ¿Son los algoritmos técnicos de las aplicaciones aun validos para los procesos de datos?
– ¿El esfuerzo de «entender» la aplicación actual y documentar la especificación de la nueva es mayor que el de la «simple» migración? (Cuando no queda nadie del equipo original)

Llegados a nuestro escenario «pues si, necesitamos migrar esa aplicación pues ya cada vez es mas difícil mantenerla y vamos a migrar de plataforma….. » hay que plantearse las cosas de como acometerla, no tanto desde el punto de vista técnico, que para eso hay suficiente información en Internet, sino mas bien de cuales serian los pasos razonables para lograr el objetivo de una migración exitosa.

Con esas miras puestas, la experiencia que he tenido recientemente me llevan a plantear dos pequeñas metas antes de la migración en si:
– Reducir todo lo que se pueda la cantidad de lineas a migrar.
– Reducir y aislar los comportamientos críticos no migrables.

Cuando hablo de reducir la cantidad de lineas a migrar, parto del hecho de que es mas que probable que la aplicación a migrar hay sufrido modificaciones durante su tiempo de vida, lo cual haya ocasionado que métodos o clases que antes eran invocados se hayan convertido en código muerto, y reducir ese código muerto antes de la migración deberá ser uno de los principales objetivos que debamos de plantearnos, puesto que es preferible saber de antemano que código ya no es invocado (y eliminarlo/comentarlo) que matarnos en hacer que funcione para luego saber que … sorpresa.. sorpresa… era código muerto.

El tema de los comportamientos de lenguaje no migrables («As any», redimensionamiento de arrays …) es complicado, por lo que creo que es conveniente, en la medida de lo posible tomar las acciones para reducirlos antes de la migración y si eso no es posible marcar dicho código como problemático.

Ahora bien, estos son objetivos loables, pero lamentablemente difíciles de conseguir con las herramientas de Microsoft «out of the box», que si que el Code Analysis de VS .Net nos facilitara el encontrar las referencias «muertas», pero lamentablemente el tener una información completa de este tipo solo sera posible cuando el código migrado compile sin errores, pero claro… volvemos a lo mismo podemos pasarnoslas divertidos corrigiendo código para luego descubrir que ese código no era invocado en ningún lugar.

Entonces queda claro que el análisis de dependencias es critico, y lamentablemente no queda sino recurrir a herramientas de terceros, concretamente he estado probando Project Analyzer con resultados muy interesantes pues ademas de encontrarme con la opción de encontrar todo el código muerto, me detecto todos las porciones de código que requerían migración manual.

Así pues, creo que el contar con una herramienta de ese estilo (he mencionado Project Analyzer, pero igual podría ser alguna otra) cobra un importancia muy especial en esta clase de proyectos, ya que permite cubrir los dos primeros objetivos señalados y llevando de rebote una ventaja adicional: darnos cuenta, mediante el análisis de dependencias de que porciones de código no compatible como llamadas a la API de Windows, podrían ser reemplazadas por código .Net.

Ese análisis e identificación de codigo critico seria un primer paso, de ahí vendrían los siguientes:
– Refactorización, si, se puede, y nos ayudara a tener nuestro código heredado mas legible.
– Preconversión de código no migrable a código migrable, donde sea posible y se sepa que se seguirá usando luego de la migración.
– Migración en si, ya sea usando Visual Studio o una herramienta de terceros, y de ahí las sucesivas iteraciones para estabilizar el producto hasta el nivel deseado (reemplazo de ADO por ADO.Net, eliminación de los Interop….)

Es obvio que este proceso iterativo por lo que no conviene dar un paso nuevo hasta que no se sepa que la nueva versión sigue haciendo lo que hacia antes, de ahí la importancia de tratar de acometer la mayoría de los cambios posibles antes de la migración en si.

¿Qué le hubieramos pedido a un hipotetico VB 6.5?

Posted on by ecardenas

Pues si, ya han pasado poco mas de 10 años en que .NET fue anunciado (recordemos que antes era llamado NGWS), por lo que ya tendría poco sentido hablar de su predecesor, pero la experiencia de volver a tener que lidiar con VB6 me ha hecho volver a reflexionar algunas cosas…

Primero situémonos en el contexto, VB6 fue lanzado durante 1998 he incluía mejoras como: ADO 2.0 (un enésimo santo grial en la unificación de los modelos de acceso a datos), WebClasses, mejoras en el soporte a COM e integración con MTS; con todo no fue un modelo rupturista y las empresas entusiastamente dieron el salto desde VB5 (versión que por primera vez libero a VB del p-code permitiendo compilar en modo nativo).

Todo bien excepto algunos detalles…. como la herencia, lo cual le hacia ser denostado como un lenguaje no totalmente orientado a objetos, palideciendo en ese sentido ante sus rivales: Delphi y Java. Admitamoslo, durante buen tiempo los fans de VB actuaron con la política de la zorra y las uvas, diciendo que la herencia no era totalmente necesaria, y pregonando la potencia de las interfaces para lograr el polimorfismo. Aun así Microsoft decidio explorar por el lado de una OOP sin las complicaciones del C++, y el resultado fue Visual J++ 6.0 el cual tuvo problemas con Sun, por lo que el producto no tuvo tanto éxito, aunque si que me he topado con un cliente en el cual había herencia de su uso.

Visto ese escenario, para principios del 2000 se rumoreaba sobre lo que seria el inminente ASP+ y el NGWS (Next Generation Windows Services), pero Microsoft sorprendió al mundo cuando en Julio anuncio a .NET, C# y el hecho de como el nuevo VB.Net seria un lenguaje totalmente orientado a objetos, luego vendrian las primeras versiones beta de Visual Studio .Net, sobre cuyo primer contacto ya me he explayado.

Como ya he comentado mi adaptación como desarrollador al nuevo entorno fue fácil, gracias a la base OOP proveída por Delphi, así como a las buenas practicas de los cursos de certificación, pero eso no impedia que mantuviera un ojo en los problemas que se iban a presentar en la transición de VB6 a VB.NET….

Estos cambios venian dados por dos lados: cambios en el lenguaje y cambios en el Framework (de COM a .NET) y ambos eran muy agresivos, tan asi que dos respetados gurues de la época dieron su explicación (muy acalorada por cierto) de porque VB.Net era un nuevo lenguaje (para ellos peor) y no una evolución de VB6:

Karl E. Peterson: VB Fred, A Marketeer’s Worst Nightmare
Bruce McKinney: The End of Hardcore Visual Basic

Sugiero dar un vistazo a esos artículos y a los enlaces ahí contenido para entender la magnitud de los cambios, y si bien luego las cosas no fueron tal como se pintaban en la beta, los cambios si que son muy rupturistas e intentar asumir una migración es algo de veras intimidante.

He realizado migraciones de aplicaciones .NET de la version 1.0 a 1.1 y de la 1.1 a la 2.0 y se puede decir que el camino es mas o menos controlado, pues el lenguaje siempre es compatible hacia atrás, y si bien el Framework evoluciona, dejando algunas tecnologías obsoletas (como Remoting) siempre se puede recompilar en una versión superior, siendo que los potenciales problemas están por el lado de:

– Dependencia de una librería de terceros, cayendo en esta categoría el Enterprise Library, el cual si que tuvo cambios que obligaban a modificar el codigo, problema no presentado en una libreria comercial como Dundas.
– Necesidad de apuntar a una plataforma especifica (como x64 o Itanium), lo cual sumado a lo anterior da para pruebas y comprobación de entornos.
– Alguna cosa que compile, pero que en ejecución falle, son pocas pero las hay, aunque siempre se pueden controlar añadiendo un mayor control de excepciones.
– Cambio de estructura de proyectos, como en el caso de los Servicios Windows, pero se soluciona creando el proyecto desde cero e inyectando progresivamente las clases y métodos necesarios.

En resumidas cuentas, un camino que puede ser mas o menos pesado dependiendo de cuan complejo sea el proyecto, pero en el cual siempre hay vías de hacer que la migración funcione.

Planteemoslo de otra manera, ¿para 2002 habían en producción aplicaciones en VB5 o VB4? Lo dudo sinceramente, el punto de quiebre fue VB5 y como comentaba la migración de VB5 a VB6 era totalmente transparente, salvo (como de costumbre) en la dependencia de algún control de terceros.

Osea, que para migrar dentro de versiones de VB.NET o de Visual Basic «clasico» los caminos han estado mas o menos marcados y eran controlables, pero… para migrar de VB6 a VB.Net… ahi es otra cosa.

Como mencionaba lineas arriba los cambios vinieron por dos frentes: cambios traumaticos en el lenguaje y reemplazo del framework basado en COM por uno basado en .NET. (los dos primeros capitulos de este libro pueden dar una vision de los cambios), si le sumas esto al hecho de que cuando Anders Hejlsberg acometio el desarrollo de .Net, decidió crear un nuevo lenguaje C#, e hizo muchos de los diseños del CLR y el CLI sin tomar en cuenta las particularidades (ya muy usadas por los desarrolladores) de VB, esta claro que lidiar con los cambios seria una tarea harto compleja, cito el libro arriba mencionado:

The Decision to Break Compatibility

When did Microsoft decide to break compatibility with Visual Basic 6? It was actually in early December 1999, during the development of Visual Basic .NET. Until that time, Visual Basic .NET was being developed to support the notion of “Visual Basic 6 sourced” projects that allowed you to edit and compile Visual Basic 6 projects in Visual Basic .NET. These projects would have a compatibility switch turned on, meaning that the language would be backward compatible with Visual Basic 6 and would even have access to the old Visual Basic 6 forms package.
By the end of 1999, it was obvious that this strategy wasn’t working.
Little differences were slipping through: The old forms package could not be fully integrated into .NET, and the Visual Basic 6 sourced projects could not use some of the new features of the .NET platform. At that point Microsoft made the decision to break compatibility and instead concentrate on ensuring that people could upgrade their projects from Visual Basic 6 to Visual Basic .NET.

En fin, es cierto que muchos cambios (de lenguaje) eran inevitables y demandados por la comunidad de desarrolladores: soporte de herencia, excepciones y threading, pero esta claro que Microsoft pudo haberlo hecho mejor en algunos aspectos (de hecho, parte de las criticas de los gurus arriba citados van por el lado de que algunos cambios no eran necesarios para hacer a VB un lenguaje OOP) como la gestión de los arrays, no forzando a tener que hacerlos basados-en-zero y si por el contrario permitir que su gestión de limites sea equivalente a la de VB6.

Entonces esa es la situación a la que llegamos cuando sale al mercado Visual Studio .Net 1.0, el gap del Framework y el lenguaje es tan grande que solo proyectos triviales son susceptibles de ser migrados a .NET, para lo demás muchas veces es mejor hacer el proyecto desde 0, o sino… seguir manteniendo y parchando el código en VB6 hasta que se decida tomar la decisión de migrar (pues ya se sabe lo que dicen las gerencias «Si funciona ¿para que tocarlo?», claro, es así como el COBOL no muere). La dura realidad es esa, que las organizaciones se han quedado con un parque de aplicaciones para un lenguaje/plataforma que ya no evoluciona y si bien ahora se cuenta con una buena herramienta como el Artinsoft Visual Basic Upgrade Companion, la verdad es que en todo proyecto complejo nos toparemos con situaciones como estas:

– Las inevitables llamadas a la API de Win32, ya no funcionan, y no hay forma directa de hacer un cambio que permitan la recompilacion.
– A revisar todos tus arrays para estar seguro de su comportamiento.
– Replantearte como gestiona el ciclo de vida de tus objetos.
– Los controles y clases tienen otras propiedades, no hay equivalente directo en .NET para algunas clases de terceros y la importación (wrapping) no siempre es segura.

Previo al lanzamiento de VS.Net, algunos articulistas pedían que saliera una ultima versión de VB basada en COM que facilitara la transición y/o introdujera algunas mejoras a VB6, la verdad es que mire de lejos esas peticiones, claro… estaba entusiasmado por el giro a OOP que no mire la complejidad que estoy narrando, pero ahora luego de estos 10 años de .Net (contando desde su primer anuncio y Beta) creo que si que Microsoft debió intentarlo y proveer esa herramienta a fines del 2000 o principios del 2001 a fin de que hubiera un punto intermedio en el camino desde VB6 hacia .Net, lo cual me lleva a la pregunta planteada como titulo de este post….

Personalmente yo hubiera excluido la herencia como caracteristica de un VB 6.5, implementarlo es complejo y el problema radica en como gestionar caracteristicas usadas en las aplicaciones hechas en VB 6 para que funcionen luego en .NET, siendo asi, VB 6.5 debería haber tenido (como anticipo al cambio en .Net):

– Soporte dual para arrays con limites libres y basados-en-zero. Si MS seguia terco en lo de no permitir los limites libres, la compilación debería permitirlo pero indicar que esa característica estaba «deprecada» y no soportada en futuras versiones.
– Fin de las propiedades por defecto de los objetos.
– Eliminación del tipo Variant.
– Cambio en el ámbito de la visibilidad de las variables.
– Uso obligado de paréntesis en las subrutinas.
– Ofrecer un mecanismo de llamadas a la API Win32 cercano al uso que luego tendria DLLImport, pero respetando (temporalmente) la mayoría de los hacks que se tuvieron que hacer para trabajar con dicha API.
– Opcional: soporte para try..catch..finally
– Únicos cambios en el IDE: Encontrar todas las referencias, herramienta imprescindible ahora para una adecuada inspección del código, y un compilador que devuelva una lista de errores y no uno por uno.

La idea de esto seria que los desarrolladores acometieran ciertos cambios sin retorno, sin todavía decirle adiós a COM, para de esta manera tener hechos los deberes en el grueso del lenguaje, quedando (en teoría) cambios menores en el lenguaje y «solo» adaptarse al .Net Framework.

Si Microsoft hubiera hecho esto, a estas altura no habria esas aplicaciones en VB6 que se resisten a morir, haciendo a VB6 el nuevo COBOL, pues eso es lo que esta pasando… un nicho de aplicaciones que persisten mas alla de su ciclo de vida.

Y tu ¿que característica le hubieras puesto a un VB 6.5 todavía basado en COM?.

¿Los nuevos patrones ayudan a la mantenibilidad de aplicaciones?

Posted on by ecardenas

Si tuviera que decir que funcionalidad del Visual Studio (y de VB6 ya puestos) he estado usando mas ultimante, la respuesta seria «Go to Definition» (seguida de «Find All References»).

La razón de esto es debido a que ahora me corresponde estar en mantenimiento de aplicaciones, lo cual implica que cuando hay un error tratar de encontrar que metodo o clase fallo y ver que hacer para solucionar el error, y en otras ocasiones añadirle una funcionalidad a cualquiera de las aplicaciones ya existentes (en cuya creación yo no intervine).

Como ya explique anteriormente esta es una situación en la que no se empieza de cero, y se requiere tratar de entender de manera rápida el como esta montado todo a fin de encontrar la raiz del problema, por lo cual usualmente tengo dos caminos:

– Ubicar la aplicación e ir haciendo una «depuración sin ejecutar» mediante el «Go to definition» tratando de ubicar los puntos de paso críticos que hay durante la cascada de llamadas de los sucesivos métodos involucrados en la funcionalidad.
– Buscar el texto con el mensaje de error reportado, y de esa manera mediante el «Find all references» identificar de abajo hacia arriba la posible pila de llamadas y en el camino encontrar lo que ocasiono el problema.

Pero llegados a este punto vemos que se ha incrementado la demanda por desacoplamiento y pruebas unitariasdentro de nuestros codigos, todo como parte de los patrones SOLID:

* SRP: The Single Responsibility Principle (Principio de Responsabilidad Única)
* OCP: The Open/Closed Principle (Principio Abierto / Cerrado)
* LSP: The Liskov Substitution Principle (Principio de Sustitución de Liskov)
* ISP: Interface Segregation Principle (Principio de Segregación de Interfaces)
* DIP: The Dependency Inversion Principle (Principio de Inversión de Dependencias)

Principios muy interesantes, que valen la pena revisar, pero que introducen tendencias como la Inyección de Dependencias y la Inversión de Control, para lo cual recomiendo este muy bien explicado articulo de Gisela Torres de donde extraigo esta explicacion;

Generalmente, cuando tenemos una clase que depende de otras para ciertas acciones, necesitamos inicializar instancias de las mismas para poder utilizarlas posteriormente. En ocasiones, una de las alternativas puede ser crear un objeto de dichas clases de forma privada e inicializarlas, utilizando el constructor de la clase principal.

Si vemos estas acciones desde el punto de vista de la Inyección de Dependencias y la Inversión de Control, no sería la forma más óptima debido a que la clase que sufre estas dependencias no debería ser la responsable de la creación de las mismas.

¿QUÉ CONSEGUIMOS?

  • Desacoplamiento.

  • Mejora la posibilidad de testeo de la aplicación.

  • Mejor mantenimiento a la hora de realizar cambios de los componentes, gracias a la modularidad.

  • […]

Ambos conceptos están tan ligados que, en ocasiones, no se hace distinción. Se utiliza el concepto Inversión de Control para delegar en otro componente, un framework por ejemplo, la responsabilidad de crear las instancias necesarias en lugar de crearlas nosotros mismos. Por otro lado, la Inyección de Dependencias es el término utilizado cuando una clase depende de otra y, a través del constructor generalmente acepta un parámetro del tipo del cual depende. 

Siguiendo el ejemplo, podemos ver que en lugar de el tradicional mecanismo de instanciación de la clase que necesitamos, por detras existe un interesante mecanismo de Configuración y Factoria de Objetos que nos permiten que en lugar de:
public class HomeController : Controller
{
private readonly ITwitterService _twitterService;
public HomeController()
{
_twitterService = new TwitterService();
}

public ActionResult Index()
{
return View(_twitterService.FetchTweets());
}
}

Tengamos:
public class HomeController : Controller
{
private readonly ITwitterService _twitterService;

public HomeController(ITwitterService twitterService)
{
_twitterService = twitterService;
}

public ActionResult Index()
{
return View(_twitterService.FetchTweets());
}
}

Nada mal según parece, usamos interfaces, y se logra una mayor facilidad para pruebas unitarias, lo cual es uno de los objetivos a lograr, pero oh sorpresa… si ahora le hacemos «Go To Definition» al FetchTweets notaremos que ya no vamos a la implementación del método en cuestión (definido en la clase TwitterService), sino al cuerpo de la Interfaz ITwitterService, lo cual detendría nuestra búsqueda en cascada, al no tener mucha idea de cual es la implementación real que se esta invocando, por lo cual nos quedan dos potenciales soluciones:

– Correr la aplicación y en tiempo de ejecución ver la implementación real para así tomar las medidas de análisis necesarias a fin de resolver el problema.
– Tratar de entender la configuración de las dependencias y así inferir cual es la clase que se esperaba instanciar.

Como se comprenderá esta circunstancia puede hacer complicado una tarea de mantenimiento, y la idea de que esas tendencias pueden significar un problema, no en el tiempo de desarrollo, sino en posteriores mantenimientos me han dado vueltas en la cabeza durante un buen tiempo, hasta que encontré este interesante articulo, del cual cito y traduzco:

Yo lo he experimentado de primera mano, en muchos diferentes proyectos donde he tenido que hacerme cargo de codigo despues de que un desarrollador dejo la compañia, y puede ser una experiencia exasperante. Una mejora es solicitada, o un bug es reportado, digamos que se trata de un bug. Se me puede haber dado una excepcion en la pila, y eso al menos me lleva al codigo fuente en donde empezar. Lo que usualmente encuentro es un bonito set de pruebas unitarias que puedo correr y comprobar que todas se ejecutan correctamente, lo cual no es una gran sorpresa; pero, todos los tests usan «mocks» por lo que no puedo reproducir inmediatamente el bug como no sea escribiendo un lindo mock test para simular como el código debería responder ante un particular error de entrada, puesto que yo puedo «mockear» facilmente el error. Eso esta bien, pero no es util si mi objetivo principal es evitar que el error ocurra.

¿Que clase en concreto es la responsable del bug? Aqui es donde se pone complicado, en la mayoria de los casos, la pila no te da ninguna pista. Leer el codigo y examinar la configuración puede ser una enorme perdida de tiempo y termina siendo una tediosa búsqueda en amplitud.

Como el autor apunta «la capacidad para obtener información rápidamente y entender un programa al leer el código es degradada por IoC debido al desacoplamiento», y así.. esa seria la alerta con la que nos deberíamos quedar, ver cual es el lugar de estos patrones, y si la búsqueda de objetivos en este momento como el desacoplamiento y las pruebas unitarias, no vendrían a significar un lastre en el largo plazo, cuando la aplicación tenga que ser mantenida por un equipo diferente.

El paso por mantenimiento de aplicaciones te hace tener en cuenta estas otras consideraciones.

Otro articulo interesante:
Dependency Injection makes code unintelligible

Si a mi ya me es dificil: … el PADRE de la AEAT

Posted on by ecardenas

Bueno, este mes toca entregar la declaración de la Renta aquí en España, así que como buen informático, acostumbrado a casi no ir a bancos y hacerlo todo por Internet, decidí nuevamente hacer uso del programa PADRE de la AEAT.

Ya había tenido problemas en años anteriores, pero la solución al final paso por:
– meterte al «about:config» del Firefox, y habilitar a «true» el signed.applets.codebase_principal_support
– Ya cuando toco hacer la transmisión… al final usar Internet Explorer, pues por alguna razón el paso final no podias hacerlo desde Firefox.

Eso durante los dos años anteriores, esperaba que la cosa hubiera mejorado en este periodo pero… error.. hemos ido para peor como contare:

– Lo primero y mas sangrante, es que a diferencia de años anteriores, nomas bajarse el programa se nos advierte de instalar la Java Virtual Machine, lo cual indica que la aplicación ya no era nativa de Windows, con las consiguientes perdidas de performace.
– Otro error de diseño, la instalación coloca al programa en C:AEAT en lugar de c:archivos de programa, que es como indican las practicas recomendadas para aplicaciones Windows, con los consiguientes problemas de seguridad y usabilidad que luego comentare.

Pero bueno, lo instale sospechando que esa ubicación le daría problemas a la ejecución… en todo caso me asegure de verificar que tenia a Internet Explorer marcado como browser por defecto, ya que al menos IE si que incorpora como Autoridad de Certificacion, de serie, a la FNMT, todo lo contrario que Firefox a pesar del tiempo que se lleva pidiendo esa modificación.

Arranquemos el programa, doble clic, nada… doble clic.. nada, botón derecho «Run as Administrator» ahi si!!! primer problema, ¿qué sabe un usuario común y corriente de eso de elevar privilegios? y ¿si por seguridad tu cuenta de Windows no permite el elevar privilegios a menos que tengas el password respectivo?.. bueno.. primer problema resuelto.

Bueno, la aplicación es de su padre y de su madre, no tiene ningún criterio de usabilidad basado en las experiencias conocidas de Windows, botones diferentes, tipografía diferente a la que tengas configurado tu Windows, y un pequeño detalle.. cuando entras a crear una declaración el botón/enlace para «Nueva Declaración» no funciona a menos que hayas escrito primero el nombre de la nueva declaración a crear, siendo que lo usual es que luego de dar «nuevo…» recién se te habiliten los campos de edición o bien un cuadro de dialogo te invite a llenar el dato… me pregunto si esa practica es lo usual en Mac o en Linux…

Luego de enterarme un poco de que va ello (insisto, rompe los paradigmas que solemos tener cuando usamos aplicaciones Windows) solicito que se importen mis datos de usuario, lo cual predeciblemente termina invocando a mi browser por defecto: Internet Explorer, pero…. veo que le solicita permiso para ejecutar ¡un control ActiveX!!, le doy permiso y…. nada, en eso me pregunto que si no estará lanzando la versión de 64 bits de IE (tengo Windows 7 Ultimate 64 bits), así que lanzo manualmente la versión 32 bits de IE y repito el proceso, y felizmente el PADRE decide valerse de esa sesión y ahí si… si funciona la importación de los datos que tiene la AEAT sobre, previa firma digital por parte mía, por supuesto.

Importa los datos, y como es lógico decido enviar la declaración telematicamente, me salio a pagar asi que escojo el modo de «adeudo» pues se me paso la fecha para domiciliar el pago, y descubro que:
– El IE no encuentra el archivo .100 con mi declaración, ¿que había pasado? simple, cuando le di a grabar mi declaración (desde el PADRE) escogió grabarlo en «Mis Documentos» en vez del C:AEAT, por lo que relance el proceso asegurandome esta vez de grabar el archivo .100 en la carpeta de marras.
– Hay un error de «secure channel» cuando desde el IE inicio el proceso para que se notifique a mi banco para que se pague mi deuda…
– Probamos pagarlo con tarjeta de crédito… nada, por alguna razón mi banco no aparece listado, lo cual hace la cosa aun mas bizarra, pues en todo pago que hecho con mi tarjeta de crédito, nunca se me ha pedido el banco emisor, solo el tipo (VISA/MC/AMEX) y los datos correspondientes.

También intente con Firefox para ver si podía evitar el problema del «secure channel», pero nada, y como era predecible en Firefox aun se necesita habilitar el signed.applets.codebase_principal_support, y agregar manualmente a la FNMT como Autoridad Certificadora.

Por si creían que usando Internet Explorer solo tenia el problema de los 64 bits, pues no, en algún momento (que no recuerdo) del proceso tuve que modificar mi definición de sitos de confianza, agregando manualmente a los sitios de la agenciatributaria.es, pues de otra manera las transmisiones no funcionarian.

Obviamente que todos estos trucos y workarounds los fui buscando conforme me tropezaba con los problemas, y debo decir que si siendo informático ya me resulta un poco pesado toquetear el proceso, para un usuario común ya es algo complicadisimo.

Lo ideal seria que la parte (tecnica, no tributaria) mas complicada del proceso sea instalar el certificado digital y dar la firma cuando te lo pida, pero como se puede ver lograr que el proceso sea transparente al usuario no ha estado en los objetivos de los «genios» de la Agencia Española de Administración Tributaria.

…. ya contare como lo soluciono….

Proponiendo un experimento: impostores y seguidores

Posted on by ecardenas

Hace unos días conversaba con Angela sobre el hecho de que a pesar de estar ambos fuera del Perú, existen todo un conjunto de opciones para estar «al día» con respecto a lo que pasa ahí (política, deportes, estrellas de Youtube), lo cual me llevo de vuelta a una idea que me había dado vueltas en la cabeza hace un tiempo: ¿que tan factible es tener/simular «la experiencia de vivir» (virtualmente) lo que pasa en un país que no conoces y al que no has visitado?.

En teoría debería ya ser posible, pues a estas alturas ya hemos superado la etapa en que eramos solo consumidores de información, por lo que volví sobre una idea de hacer esta experiencia un experimento universitario para un curso semestral, con variantes de acuerdo al perfil de la carrera, siendo que el curso que yo haya llevado que mas se podría aprovechar este experimento seria la Sociología(*) que lleve en EEGGCC.

En términos generales se parte de la idea que cada alumno debería asumir un rol de «impostor» y de «seguidor» simultáneamente, la duplicidad de roles viene dada a efectos de control, como ire explicando.

En el rol de «impostor» cada alumno tendría que simular vivir en un país dado al azar, y como «seguidor» hacer un seguimiento de la huella que un compañero (también al azar) va dejando, para esto al final de cada semana uno debe informar a su respectivo «seguidor» de los lugares mas relevantes por los que ha pasado. En otras palabras, cada alumno seria «impostor» sobre un país dado, seria «seguidor» de un compañero, y a la vez tendría un «seguidor» que lo monitorearia.

Se entiende que la razón de establecer el rol de «seguidor» es ver la huella que el «impostor» va dejando (para efectos de registro y elaborar un informe), pues parte del reto es hacerlo convincentemente y lograr que alguien totalmente externo pueda generar respuestas, debate y hasta controversias sin llegar a ser un troll. Este aspecto es tal vez el mas importante de mi propuesta, pues no se trata tan solo de recopilar noticias de actualidad del país elegido, sino también ser parte de los pequeños debates y trends que se van generando en cada diferente realidad.

En el estado actual los sitios destinos para simular la «experiencia de vivir» : twitter (no Facebook), Skyscrapercity, uno o los dos primeros diarios (generalistas) de circulación nacional así como uno deportivo. Por supuesto que se dejara abierto a que en clase se sugiera algún foro adicional.

¿Por que Skyscrappercity? porque es es un foro donde la gente discute urbanismo de manera coloquial y comenta sobre como eran y han ido cambiando sus ciudades, así que es un buen mecanismo de demostrar hasta que limite podemos llegar con la impersonación planteada.

Para simular mejor la idea, se cogerán los 5 mejores equipos (según el campeonato del año) de fútbol y por sorteo el alumno deberá asumir ser hincha del equipo que te haya tocado. Así que si te toca un equipo nuevito y de poca hinchada que le ha ido bien (como el San Martín) piña pues, tendrás que defenderlo en los foros o comentarios sobre las respectivas noticias.

Previo a la «identidad falsa» se dispondrán de dos o tres semanas para elaborar un informe preliminar sobre la situación del país, estableciendo (no hay que ser muy rigurosos) los 3 principales perfiles sociopoliticos urbanos.

Países: descartados los muy mediaticos, así en en el caso de Perú descartariamos: Argentina, Chile y Venezuela, pero seria muy interesante incluir Belice o Guinea Ecuatorial. Estos filtros van de cara a evitar en lo posible que un alumno que tenga asignado a Argentina tenga mucha ventaja sobre el que tiene asignado a El Salvador, p. ej.

Lo que no tengo tan claro (y quedaría abierto a la implantación del profesor):

Si el alumno deberá hacer la «impersonación» sobre el país acerca del que hizo la investigación o se le asignara el informe hecho por algún compañero, tampoco tengo claro si seria conveniente decirles que asuman alguno de los perfiles sociopoliticos identificados en el primer informe, probablemente esto dependa del tiempo y de cuan profundo se quiera que sea el análisis.

La idea es simple, comprobar la viabilidad de una posible impersonación hacia una identidad nacional que es la de uno, aparte claro esta de descubrir mas cosas sobre otra realidad. La idea esta puesta, ¿alguien se anima a montarla?

(*)Curiosamente fue en el curso de Sociología de la profesora Sandra Vallenas que tuve mi primer esbozo de lo que era Internet, gracias a la charla que nos dio Carlos Wendorff sobre lo que se empezaba a hacer: correo electrónico, conversaciones en tiempo real, boletines….

¿Que hace que una tecnologia resista mas alla de su ciclo de vida?

Posted on by ecardenas

Hace exactamente 3 años comentaba la situación en la que se encontraban muchas empresas, ancladas al pasado tecnológico con tecnologías de mas de 20 años, y de paso enlazando tecnologías que estaban muriendo o agonizando: Cobol(*), Bases de Datos no Relacionales, redes no TCP/IP, ccMail, ColdFusion, C (puro, no C++), PowerBuilder, Netware, PC network y OS/2; claro esta que a esa lista añadiria xBase (¿se acuerdan cuando casi todo pequeño negocio tenia su aplicación en Clipper o Fox para DOS?).

Ya sabemos que aun en pequeños negocios como cabinas de internet cuesta de convencer el migrar hacia tecnologías mejores y mas eficientes, pero aun así al ver la lista mencionada uno ve que el estado de estas tecnologías es mas bien dispar, algunas tecnologias estan realmente muertas o terminando de morir en sus ultimos espacios, mientras que otras a pesar de no brindar nada nuevo, siguen siendo la base para nuevos desarrollos, conviviendo con otras tecnologías.

¿Qué es lo que hace que algunas resistan y otras no? Especulare un poco y a ver si comparten mis ideas.

1)La ola es muy fuerte y no puedes sino dejarte llevar, si, en este caso estamos hablando de Internet y el efecto de arrastre que implico para la adopción del protocolo TCP/IP como la opción por defecto en las organizaciones, todo Ethernet, adiós token ring, protocolo IPX…. lo cual de rebote termino cargándose a las redes Netware de Novell, antaño bien implantadas en muchas organizaciones. Así que si todos los proveedores, incluyendo los de mainframe, deciden dar el salto al soporte de TCP/IP (como ocurrió en la segunda mitad de los 90s) el cambio ya es inevitable. Por mas que algunos digan que Internet resucito un protocolo que ya era «cadáver», al final la inercia del mercado y la demanda por conexión a Internet nos arrastro a todos, y ya no miramos atrás.

2)El costo de mantener la compatibilidad es muy alto comparado con la migración, aquí ya entro un poco en la especulación basándome en lo que he visto en las pymes, quieras que no el mercado de aplicaciones para pymes es muy dinámico y llega un momento en que ya no se pueden mantener las aplicaciones existentes por: no se pueden encontrar profesionales, o porque eventos como la introducción de Windows 95 o el problema del año 2000 te hacen sacar la calculadora y ver que mas barato te sale migrar que seguir manteniendo tu querido Clipper.

3)Lo que elegiste no era tan masivo y cada vez te costara mas encontrar soporte, aquí caen dos tecnologías al margen de sus méritos: Delphi y PowerBuilder, efectivamente ofrecían una buena respuesta tecnológica a las necesidades de desarrollo en Windows de esa época (mejor que VB en el caso de Delphi, p. ej), pero la presión introducida por el desarrollo de aplicaciones Web, así como la pujanza de .NET y Java, hizo que el nicho de mercado que se había construido alrededor de estas tecnología se debilitara impulsando su migración. Lo bueno en este caso es que la arquitectura modular de estas tecnologías (el entorno de desarrollo de la aplicación no esta amarrado a la BD como en xBase) permite migraciones menos traumaticas y mas progresivas.

4)Es mas caro migrar que mantener la compatibilidad si, al revés que el caso 2) y en este caso nos topamos con los engreídos de la industria: el mainframe ya sea en sus variantes PL/1 o COBOL, están ahí, las empresas se resisten con uñas y dientes al cambio, por la sencilla razón de que debido al volumen y trafico de información, el riesgo de tener la producción caída es algo que no se puede asumir, punto. Es curioso que cuando hubo el problema del años 2000 en algunos casos se haya optado por una huida hacia adelante, parchando la infraestructura en vez de aprovechar la oportunidad de reemplazo. Y así como están las cosas, se requerirá mucho valor y cabeza fría para que una organización decida migrar sus aplicaciones, pero la verdad…. ¿de veras tiene sentido basar lógica de negocio en la posición de un carácter en un texto plano?

5)Entenderlo es mas complicado que parcharlo esta es la peor situación de todas, pues la limitación viene dada no por las características de la tecnología, si no por como esta tecnología no te coloca restricciones para hacer mal código, concretamente Visual Basic 6 cae en esta categoría, ya que como comente antes es perfectamente posible construir aplicaciones en VB6 con una arquitectura robusta y buenas practicas (y he visto buenas aplicaciones de este tipo), pero la propia filosofía del lenguaje no te impulsa a ello, recayendo totalmente en el desarrollador y la organización el montar algo ordenado, siendo que una vez empezado el trabajo esa reorganización es tarea imposible. Resultado: que esas aplicaciones se mantengan, crezcan y crezcan a golpe de parches, haciendo la migración algo temido por la organización, haciendo que VB6 ya sea considerado como el nuevo COBOL, con la diferencia de que el soporte y evolución quedo cerrado hace rato, así que solo resta esperar una nueva revolución que nos fuerce a dejarlo.

Esto es, dentro de mi experiencia, lo que creo que establece diferencias entre los destinos de diversas aplicaciones, me quedo con la curiosidad de saber cual ha sido el proceso por el que pasaron tecnologías como ADABAS, mainframes NCR y AS/400.

(*)Aunque yo lo consideraría de la mano de su hermano en mainframe: PL/1.

No siempre empezaras desde cero

Posted on by ecardenas

Como desarrolladores generalmente esperamos estar desde el arranque de un proyecto, con la idea de que asi «esta vez hacer las cosas bien» usando una buena arquitectura y claro, con lo ultimo de la tecnología, al final terminamos llegando al estado de «parecia una buena idea en su momento» y que hay que terminar el proyecto «como sea», bueno… exagero un poco, pero debe quedar claro que estar en el proyecto desde un inicio no es una garantia para que todo vaya como una seda todo el tiempo.

Pero para bien o para mal, si uno es un desarrollador «desde las trincheras» y no un «guru», no sera rara la situación en que nos veamos en la necesidad de dar mantenimiento a un programa que alguien mas haya hecho o empezado (en cualquier grado de avance), y ahí es donde empieza nuestra historia…..

Antes de proseguir, debo decir que cuando he estado una buena temporada en un proyecto, trato de pensar (sobre todo en las ultimas etapas) en «como hacerle mas simple la vida al pobre tipo que se hara cargo de esto» para lo cual opto por un enfoque realista, dejar comentarios en las secciones de código que se que pueden ser mas crípticas, y de ser el caso dejar documentación útil, ¿y cuando una documentación es útil? ¿no se supone que lo útil es documentar todo lo posible? ¡Error! una documentación es util cuando uno honestamente sabe que leyéndola proveerá una idea para entender la lógica detras de la implementación de un código.

Entonces como decia, nos encontramos en la situación de que hay una aplicación existente, en cuya creación no hemos intervenido, y se nos pide ver porque ha dejado de funcionar o que le agreguemos una nueva funcionalidad, la documentación es escasa y con suerte tenemos las referencias de los servidores involucrados.

Asi que con esta premisa vamos tras el codigo fuente a ver que podemos sacar en claro (*), con lo que nuestra rutina es mas o menos como sigue:
– Ubicar el punto de entrada de la aplicacion, o sino, los controles y sus eventos respectivos que desencadenan la accion a investigar.
– Ubicado el punto de entrada o el evento deseado (capa de Interfaz de Usuario), ir viendo como se van creando las sucesivas instancias de las capas de Negocio, Fachada, Datos y los métodos involucrados.
– De ser necesario ir depurando para evaluar los valores que van tomando las variables criticas…

En fin, este es el mundo real y creo que alguna vez todos habremos pasado por este lió, siendo nuestros dilemas el saber a que clase/metodo se esta invocando desde un punto del código, así que me he sentido afortunado cuando he podido hacerme una idea del código usando las herramientas para encontrar la «Definicion» de un método invocado.

Es que así es el código típico:

– Método f1 de la clase A necesita llamar al método f2b de la Clase D.
– Método f1 instancia un objeto «miD» de la Clase D.
– Método f1 ejecuta el método miD.f2b.
– Método f2b de la clase D necesita……

Si el código esta mas o menos estructurado (y no es un spagetti por supuesto), esa es la lógica que uno busca, con las debidas excepciones de cuando se tienen que ejecutar instancias remotas y/o usando Interfaces en vez de clases directas.

Una de las cosas que tienen de bueno los entornos RAD como Delphi y .NET (WebForms y Winforms) es que brindan un mecanismo comprensible para empezar a depurar, sabes el control y quieres ver que hace, pues entonces… a ver los eventos vinculados y de ahi para adelante, de capa en capa. Quienes hemos trabajado con ASP Clasico recordamos la pesadilla que eran los puntos de entrada de las paginas, revisando todas las posibles combinaciones de parametros que venia en el Request razon por la que la introducción de WebForms fue la respuesta a nuestros problemas, y para mi lo sigue siendo.

Pero la evolución del desarrollo de software es imparable, y asi hemos visto como han surgido tendencias que han procurado añadir valor a nuestros ciclos de desarrollo como: WebServices, Refactorizacion, SOA y varios intentos de mecanismos para construir una arquitectura distribuida: DCOM, COM+, .Net Remoting, WCF….

Pero al margen de como vayan evolucionando las tendencias, una cosa que siempre procuro en mis desarrollos, es dejar el camino mas o menos despejado para que el que venga luego pueda entender el código que esta leyendo, procurando tener las inevitables sofisticaciones bajo control. Teniendo esto en cuenta… cabe preguntarse si tendencias como el «desacoplamiento» y la necesidad de «pruebas unitarias» facilitan o no la vida del que luego tiene que enfrentarse a mantener tu código, pero ese análisis lo dejo para un posterior post.

De momento quiero dejar la reflexión de que a veces estamos tentados a emplear unos patrones novedosos, potentes, pero… también debemos pensar que no todos los desarrolladores siempre desarrollan desde cero, que se llega a proyectos ya empezados, a código terminado en producción que hay que mantener, y que no hay que complicarle la vida en aras de lucirte con lo mas novedoso en metodologias y arquitecturas si es que no es de veras necesario, ya que estas no solo deben prometerte mas facilidades para ti, si no para el que luego tendra que mantener tu codigo.

(*)Aunque alguna vez no contamos ni siquiera con el código fuente, como me paso en un cliente hace 3 años, por lo que toca ver si podemos desensamblar el código, pero eso ya es otra historia y mas bien un extremo de irresponsabilidad por parte del cliente.