miércoles, 14 de febrero de 2018

TypeScript a producción: primeros pasos


Desde hace tiempo, especialmente desde que la lógica de negocio se comenzó a desarrollar a nivel de UI, escribir código JavaScript no ha sido fácil. Esto se debe a que dicho código suele ser difícil de leer, mantener, siendo engorroso hacerlo prolijo (habría que utilizar prototypes, closures, IIFEs, etc.) y, sobre todo, casi imposible de testear.
Para solucionarnos los problemas anteriormente mencionados, salió al mercado un lenguaje llamado TypeScript. Sin entrar en detalles técnicos, quiero mencionar dos de las principales ventajas que nos provee:
  • Funciona en todos los browsers y sistemas operativos
  • Es puramente orientado a objetos.

Si analizamos la situación, fácilmente nos damos cuenta de que nuestro código backend es prolijo y fácil de leer, mantenible, extensible, orientado a objetos y testeable. Esto nos hace pensar, ¿utilizando TypeScript, será posible programar como en backend? ¿Cómo llevamos esto a la práctica?

En esta serie de artículos vamos a ver cómo incluir TypeScript en nuestros proyectos, cómo tenerlo testeado y bajo control y, finalmente, cómo pasar código JavaScript a código TypeScript, o como me gusta decirle: código sucio a código limpio.
Para todo aquel que no sepa mucho acerca del lenguaje TypeScript, puede ingresar al siguiente link y, de esta manera, obtener una base de conocimiento más homogénea: https://www.typescriptlang.org/.

Y ahora sí, vayamos al “kit” de la cuestión. ¿Cómo agregamos TypeScript a nuestro proyecto productivo? En primer lugar, sugiero utilizar Visual Studio 2013 o posterior, donde la integración con TypeScript ya viene resuelta por la misma IDE. Es probable que los que están utilizando frameworks o Visual Studio viejos hayan dejado escapar alguna palabra de más. Pero no se preocupen, también pueden instalar TypeScript en sus IDEs:
  • Visual Studio 2010 (http://www.c-sharpcorner.com/UploadFile/SamTomato/typescript-with-visual-studio-2010)

  • Visual Studio 2012 (https://www.microsoft.com/en-us/download/details.aspx?id=34790)

No obstante, recomiendo ampliamente que traten de utilizar los Visual Studio más modernos, ya que además de incluir TypeScript, cuentan con muchísimas otras ventajas y tienen una mejor performance a la hora de tener que desarrollar aplicaciones complejas.

Antes de agregar el primer archivo TypeScript es muy importante pensar dos cosas:

1- ¿Para qué? Es una pregunta que se debe responder con un nuevo requerimiento o funcionalidad que anteriormente involucraba crear nuevos archivos JavaScript. Entonces ahora es el momento de crear nuestro primer archivo TypeScript.

2- ¿De qué manera? Esta pregunta apunta a pensar un poco la arquitectura. ¿Dónde voy a dejar los archivos TypeScript? ¿Dónde voy a querer que se generen los archivos JavaScript luego de transpilar? ¿A qué versión de JavaScript queremos que transpile? ¿Cómo voy a estructurar el código?

Veamos cómo crear un nuevo archivo TypeScript en un proyecto Web (Figuras 1 y 2) (Los ejemplos y capturas son desde el Visual Studio 2013.)


Figura 1

Figura 2

En este caso el archivo se crea a nivel del proyecto Web. Si deseáramos agregarlo a una carpeta específica, tendríamos que hacer “click” sobre la misma y a partir de ahí seguir las Figuras 1 y 2.

En las Figuras 3 y 4 se puede observar como configurar en dónde guardar los archivos transpilados, en qué versión de JavaScript, entre otras configuraciones posibles.
Figura 3

Figura 4

En la Figura 4 se ven las posibles configuraciones, pero quiero centrarme en ECMAScript Version y Redirect JavaScript output to directory, que son las más importantes.
ECMAScript Version sirve para configurar a qué versión de JavaScript se quiere transpilar. 

Esto es importante, sobre todo, por si los usuarios están usando versiones de browsers más viejas.

Redirect JavaScript output to directory es importante para saber dónde localizar el JavaScript que se transpila. Recuerden que en nuestro HTML hacemos referencia al JavaScript generado, por lo tanto, es muy importante definir una ruta propicia.

Desde mi experiencia, todo esto lo logré sin un tutorial, es decir, fue a prueba y error. Es por eso que quería compartirles los pasos que fui haciendo y los problemas con los que me fui encontrando, para lograr que mi JavaScript sea de calidad, y siempre manteniendo el foco en “diseñar una aplicación testeable”.

Espero haber aportado mi granito de arena para que cada uno de ustedes pueda comenzar a implementar TypeScript en sus proyectos.

No se pierdan los próximos posts en donde vamos a estar viendo cómo testear el código TypeScript generado y cómo migrar nuestro código JS a TS.


Autor:
Leandro Goldin 
.NET Technical Expert.



miércoles, 31 de enero de 2018

Los libros en tiempos de internet

Puede que resulte sorprendente para muchos, pero todavía hoy, en la era digital, hay gente que sigue imprimiendo letras en papel e incluso los considera indispensables para su trabajo.

Es por esto que en la sede Roosevelt de Baufest, se erige una “Biblioteca” donde se pueden encontrar ejemplares de variados temas de interés para los empleados de todas las áreas (Recursos Humanos, Administración, Finanzas, Tecnología y Marketing, entre otros). 

Existen tanto materiales tradicionales que contienen información histórica sobre los primeros avances de las computadoras, como material tan actual que describe los avances del mañana.

Además, para aquellos Baufesianos que prefieren las versiones digitalizadas, existe un repositorio online, donde pueden acceder y descargarlas desde la intranet de Baufest en cualquier momento. Dicha intranet posee un índice de todos los materiales catalogados tanto física como digitalmente, en una ficha donde se encuentra la información esencial para permitir ajustar la búsqueda a las necesidades del usuario.

Los préstamos se gestionan con un sistema de autoservicio, donde cada usuario puede buscar lo que necesita en el catálogo digital, retirarlo luego de la biblioteca y devolverlo al mes. Aquellas personas que trabajan remotamente también tienen acceso a la bibliografía, ya sean los digitales o los físicos. Para estos últimos se realiza una revisión del catálogo, se selecciona el material deseado y éste es enviado a donde se encuentre trabajando el interesado.

La biblioteca crece continuamente, ya sea por compras realizadas por Baufest o por donaciones de los Baufesianos. Además, mensualmente se actualizan las suscripciones a revistas, tales como, Information Technology, Apertura y Mercado.



Lo más importante para destacar, es que la biblioteca no es un artículo de anticuario, sino una gran herramienta que constantemente se cambia y actualiza para poder servir a las necesidades de todos los usuarios. Los libros, incluso en tiempos de internet, son más relevantes que nunca.

Autor
Luciano Cascio
Operaciones y Calidad

miércoles, 17 de enero de 2018

Principios SOLID en tu día a día

Durante los primeros años de mi carrera profesional, tanto en la facultad como en el trabajo, me encontré en algunas ocasiones con las palabras “buenas prácticas” o “principios de desarrollo”. La primera vez que las oí, pensé que eran consejos precisos sobre cómo afrontar un desarrollo en particular, es decir, para un caso concreto. Uno también podría pensar o asociar la idea a un tema que estudiamos en alguna materia de diseño de sistemas: los patrones; pero en este caso no, ya que sabemos que estos son soluciones reutilizables para problemas puntuales. Entonces, ¿a qué se referían con estos con términos?

Cuando comencé mi primer trabajo como programador, me encontré frente a un proyecto de mantenimiento y mejoras donde hallé documentos de buenas prácticas o estándares de desarrollo del proyecto y nuevamente me crucé con estas palabras.

Finalmente, gracias a un estudio que realicé sobre los principios SOLID, logré entender de que se tratan. ¿Y qué son? Son justamente eso, buenas prácticas o consejos que descienden de la misma esencia que plantea y engloba el paradigma de objetos. Esto nos lleva a tener en cuenta los conceptos que caracterizan al modelo, es decir, abstracción, composición, encapsulamiento, herencia y polimorfismo, que son los que nos permitirán llegar a una solución con buenas prácticas.

Si queremos demostrar que utilizamos estos principios en nuestro día a día, debemos explicar brevemente cómo están compuestos.

La sigla SOLID (por sus iniciales en inglés) proviene de una serie de principios:
  • Single Responsability Principle
  • Open Close Principle
  • Liskov Substitution Principle
  • Interface Segregation Principle
  • Dependency Inversion Principle

Single Responsability Principle o Principio de Responsabilidad Única: establece que una clase debe tener una única responsabilidad. Esto quiere decir que las clases definidas en nuestro código fuente deben ser cohesivas, tener un único fin para el cual fueron definidas y nada más.

Open Close Principle o Principio Abierto Cerrado: aconseja que una clase debe permitir la extensión y prohibir una modificación. Si se define de una forma es por una razón y debe estar dedicada a lo que se definió.

Liskov Substitution Principle o Principio de Sustitución Liskov: establece que los subtipos deben ser capaces de ser sustituibles por sus tipos base. En pocas palabras, los programas deben referenciar a las abstracciones y no a las implementaciones.

Interface Segregation Principle o Principio de Segregación en Interfaces: establece que los implementadores de interfaces no deben estar obligados a implementar métodos que no usan, es decir, que deben ser cohesivas.

Dependency Inversion Principle o Principio de Dependencia en Inversión: aconseja que las abstracciones no deben depender de los detalles, sino viceversa, lo que significa que las dependencias entre clases deben cambiarse por abstracciones.

Y ahora es donde surge la pregunta ¿fui capaz de aplicar un principio sin conocerlo? A lo cual respondo, , es muy posible.

Estos principios le muestran perfectamente a una persona que recién entra en el mundo de la programación, (aprendiendo de forma autodidacta, con un profesor o de forma virtual), cómo se manifiestan los distintos tipos de paradigmas y lo orientan en la selección personal del primer lenguaje a aprender.

Los principios SOLID se encuentran tan presentes en nuestro trabajo, que muchas veces los utilizamos sin darnos cuenta.

Si son de los que modularizan absolutamente todo en la solución del proyecto, entonces el primer principio lo tienen en el bolsillo. Permitir que una clase tenga una única responsabilidad se debe a la sencillez del programador, mientras menos presión se ejerce en un funcionamiento, menos margen de error se maneja.

Ahora bien, ¿son prácticas o principios obligatorios? No, claro que no lo son. Son consejos que podemos tomar o dejar. Siempre dependemos del contexto en el que estamos; no por querer trabajar con buenas prácticas deberíamos refactorizar una aplicación entera para poder aplicarlos. Muchas veces estamos restringidos por los requerimientos y por uno de los factores más críticos, el tiempo.

En conclusión, es importante conocerlos, entenderlos y dependiendo del contexto en el que trabajemos, evaluar la factibilidad de aplicarlos.

Autor: 
Anibal Ezequiel Montalti
Desarrollador .NET

miércoles, 3 de enero de 2018

¡Guerra entre librerías Javascript del cliente!

Hoy en día, en las aplicaciones web está tomando cada vez mayor relevancia la lógica del front-end, es decir, la programación que en ella se haga. Entonces, surge casi naturalmente la pregunta sobre qué framework o librería usar para desarrollar. 

A continuación exponemos una comparativa entre los distintos tipos de frameworks o librerías front-end como, por ejemplo: AndularJS, Angular2 y Knockout, React. 

Existe una amplia variedad de herramientas en el mercado. Grandes empresas han decidido poner foco en estas tecnologías dado que el futuro del desarrollo de aplicaciones web y móviles pasará más por el front-end que por el back-end. En este sentido, podemos mencionar a Microsoft con TypeScript, desarrollado por el arquitecto principal del proyecto C#; o a Google con AngularJS y su nueva versión Angular2 desarrollada incluso sobre TypeScript. Y no olvidemos la participación de Facebook con React, o plataformas independientes como Knockout, entre otros.

¿En qué nos ayudan estas herramientas?

Cómo síntesis, podemos decir que estas herramientas nos ayudan a simplificar el manejo de la lógica del lado del cliente. Nos permiten tener una estructura de código mucho más organizada, facilitando el desarrollo , mantenimiento y testing de nuestras aplicaciones.

Tantas tecnologías, ¿con cuál me quedo?

Parecería trivial decir “¿y… depende?”, pero la verdad es que hay que analizar cada caso en particular, siendo el equipo y el proyecto determinantes para tomar la decisión. Por ejemplo, si tu equipo tiene poca experiencia en aplicaciones front-end, pero sí conoce de POO, parecería ser que Angular2 es el camino. Por otra parte, si necesitás un proyecto de alta concurrencia y velocidad de respuesta, tal vez ReactJS es la alternativa. Por eso, para poder decidir te contamos cuales son las principales características de algunas herramientas para que puedas enfocar tu elección.

Angular2 está orientado a POO a través de TypeScript, aunque además soporta otros lenguajes, y posee un enfoque de “componentes”. Esto le permite, al desarrollador, asimilar más fácilmente la programación, ya que en el back-end se usa generalmente el paradigma POO.

Como contraparte de POO se encuentra el paradigma funcional (¿más aceptado por la comunidad?)(1), que permite un código más legible en cuanto a su sintaxis, como son las versiones AngularJS, ReactJS o KnockoutJS, entre otros. Este paradigma brinda la posibilidad de utilizar los conceptos “deferred” y “promises” que ayudan a lograr este aspecto.

Por otro lado, respecto a los modos de bindings que nos ofrecen cada uno de ellos, AngularJS y Angular2 soportan el modo two-way, ReactJS sólo cuenta con el modo one-way y en el caso de Knockout, contamos con las propiedades observables para suscribir a los objetos que necesitamos.

En cuanto a la mantenibilidad de cada plataforma o framework, React, al ser one-way, solamente se encarga de mostrar datos en la vista, mientras que Angular, al ser un framework, exige su utilización constante y requiere de mayor estructura y configuración. React y Knockout son mucho más flexibles en su uso, e incluso se pueden combinar con Angular.

Respecto a la participación de la comunidad, Angular en general cuenta con mayor soporte, en comparación a React y Knockout que son frameworks más chicos. Por otro lado, Angular, al ser producto de Google, cuenta con mayor marketing y mejor posicionamiento general en el mercado.

Evaluando la performance de cada uno, dejamos un link a un Benchmarck(2) muy interesante que compara los diferentes frameworks que estamos evaluando con un excelente grado de detalle.

Entonces, ante tantas tecnologías… ¿cuál nos conviene utilizar?

No tenemos una respuesta certera para eso. La elección de una u otra tecnología dependerá más bien del contexto y del proyecto que tengamos en frente, incluso también de los conocimientos y habilidades del equipo de desarrollo.

Lo que podemos asegurar, es que tendremos muchas opciones para elegir, y siempre será mejor eso que no tener ninguna opción, o sólo una.

Referencias:

(1) http://blog.wolksoftware.com/the-rise-of-functional-programming-and-the-death-of-angularjs  
(2) http://www.stefankrause.net/js-frameworks-benchmark5/webdriver-ts/table.html

Autores:
Manuel Acosta
Gonzalo Moares

miércoles, 20 de diciembre de 2017

Del PEI a Baufest, la inserción al ámbito laboral

En esta nota queremos compartir nuestra experiencia en el Programa de Entrenamiento Intensivo (PEI), la capacitación brindada por Baufest a estudiantes de sistemas en donde quienes te enseñan y forman, son los mismos profesionales de la empresa.

Todo comenzó cuando vimos un aviso en Internet convocando jóvenes para capacitarse en desarrollo .NET. Nos pareció una gran oportunidad y no dudamos en mandar nuestro CV.

Luego de ser preseleccionados, llegó el día de la entrevista, ¡y estábamos muy nerviosos! Cuando llegamos nos encontramos con otros postulantes, algunos de los cuales, tiempo después, iban a convertirse en nuestros compañeros. Finalizada la misma, esperamos con ansias la llamada, que unos días después recibimos, avisándonos que habíamos sido seleccionados.

Emocionados, el primer día del curso nos encontramos con todos nuestros nuevos compañeros, ¡y desde ese momento nos llevamos bien! Con el pasar de los días las amistades empezaron a crecer, convirtiéndonos en un grupo de amigos, lo que nos hacía despertarnos cada día con muchas ganas de venir a la empresa a seguir capacitándonos.

A lo largo del proceso de aprendizaje, no solo incorporamos nuevos conocimientos, sino que obtuvimos amigos.

Hubo momentos difíciles donde creíamos que no lo íbamos a lograr, pero con perseverancia, la ayuda de nuestros compañeros y profesores, alcanzamos la meta: llegar al último día y rendir el examen final.

Todos hicimos nuestro mejor esfuerzo y con un poco de tristeza dimos fin al curso.
Nuevamente comenzó la espera, esta vez, para saber si trabajaríamos en Baufest.  Ahora no estábamos solos, la amistad, que hasta hoy nos une, nos hizo compañía hasta conocer la decisión.

En los días que siguieron comenzaron a llamarnos, y emocionados ¡festejamos! No solo habíamos adquirido conocimientos y amistades, sino también un trabajo en el que queríamos estar.

Nuestro primer día laboral no fue aterrador, como suelen ser, ya que conocíamos el lugar y a las personas. Al momento de ingresar, nos ubicamos en nuestros nuevos puestos de trabajo, y nos presentaron a los que serían nuestros compañeros de proyecto, con los cuales transcurriríamos el día a día. Enseguida nos adaptamos al buen clima laboral y todo se volvió más fácil de lo que creíamos.

Fue un arduo camino, pero mirando atrás, ninguno se arrepiente de haber aprovechado esta gran oportunidad y hoy, podemos decir que estamos felices trabajando de lo que realmente nos gusta.

Autores:
Rocío Farcy
Lucas Giani

miércoles, 6 de diciembre de 2017

App desktop: editar app.config en tiempo de ejecución

Para un proyecto, se nos pidió implementar la funcionalidad de click- once. Esta aplicación operaba para 4 regiones: Córdoba, Buenos Aires, Mendoza y Tucumán. Para saber cuál era la  región con la que se debía operar, la misma utilizaba un archivo de configuración (.ini) que establecía el entorno de la aplicación, indicando las conexiones a DBs y varios parámetros más utilizados para determinadas funcionalidades dentro de la misma.

Cada archivo (.ini) tenía diferentes variables configuradas dependiendo de la región en la que se operaba, para lo cual utilizaba accesos con parámetros de entrada.

¿Qué se quería resolver?

Lo que se necesitaba era eliminar los accesos directos ya que, por medio de click- once, no se podía generar un ejecutable parametrizado por cada región donde se debía instalar la aplicación. Dicha región, debía configurarse de forma tal que permitiera que el usuario no la vuelva a seleccionar cada vez que reiniciaba la aplicación. De esta forma, era necesario que la configuración se guardara para los inicios posteriores; pudiendo cambiarla las veces que fuera requerido. 

Si bien el problema parece sencillo, siempre hay que tener en cuenta el entorno donde se debe aplicar la solución. No es lo mismo una aplicación web que una de escritorio, más aun cuando hablamos de tecnología antigua.
Sólo a modo de resumen, estos son los principales limitantes que tuvimos que tener presente al momento de resolver este acertijo:

- Framework 2.0 (si, todavía hay aplicaciones que los usan)
- Lenguaje: Visual Basic .NET (VB6 con traje)
- IDE: Visual Studio 2005 SP1 (podría ser peor, Fox por ejemplo)
- No respeta ninguna arquitectura. 
- No se encontraba optimizado para test unitarios (si compila funciona).
- Aplicación WinForm

La solución

Se propuso crear un selector de regiones utilizando el app.config, generando una clave que se edite en tiempo de ejecución para que guarde la región seleccionada.

La búsqueda no fue sencilla. Navegando por internet encontramos muchas soluciones, pero ninguna de ellas era apta para nuestro problema debido a la tecnología con la que estábamos lidiando. Pero finalmente, la solución apareció.

Se agregó un nuevo proyecto en la solución, siendo necesario que estuviera referenciado en todos los proyectos de la aplicación  y se creó la clase cAppConfig.vb, que contenía el siguiente código: 

Imports System.Configuration
Imports System.Reflection
Public Class cAppConfig
    Private _config As Configuration
    Private _settings As AppSettingsSection

    Public Function GetProperty(ByVal propertyName As String) As String
        Return _settings.Settings.Item(propertyName).Value
    End Function

    Public Sub SetProperty(ByVal propertyName As String, ByVal propertyValue As String)
        If Not IsNothing(_settings.Settings.Item(propertyName).Value) Then
            _settings.Settings.Item(propertyName).Value = propertyValue
            _config.Save(ConfigurationSaveMode.Modified)
        Else
            _settings.Settings.Add(propertyName, propertyValue)
            _config.Save(ConfigurationSaveMode.Modified)
        End If
    End Sub

    Public Sub New()
        _config = ConfigurationManager.OpenExeConfiguration(Assembly.GetEntryAssembly().Location)
        _settings = _config.AppSettings
    End Sub
End Class

En esta clase se encontraba la función GetProperty, que obtenía el valor de la clave del app. SetProperty permitía asignar el valor a la clave si ésta existía, en el caso contrario la creaba con el valor asignado por parámetro. Luego permitía guardar los cambios.
(_config.Save(ConfigurationSaveMode.Modified)).

Y por último, se encontraba el constructor de la clase. Este guardaba en una variable del tipo AppSettingsSection el app.config.

_config = ConfigurationManager.OpenExeConfiguration(Assembly.GetEntryAssembly().Location)
 _settings = _config.AppSettings

En el mismo proyecto se agregó además otra clase llamada cRegion con el siguiente código:

Imports System.Configuration
Public Class cRegion

    Private Shared mRegion As cRegion

    Private Sub New()
        Try
            If Not IsNothing(System.Configuration.ConfigurationManager.AppSettings("RegionDefault")) Then
                RegionDefault = System.Configuration.ConfigurationManager.AppSettings("RegionDefault").ToString
            Else
                Dim cConfig As New cAppConfig
                cConfig.SetProperty("RegionDefault", "")
                RegionDefault = System.Configuration.ConfigurationManager.AppSettings("RegionDefault").ToString
            End If
        Catch ex As Exception
            MsgBox(ex.StackTrace.ToString & "cRegion")
        End Try
    End Sub

    Private cRegion As String
    Public Property RegionDefault() As String
        Get
            Return cRegion
        End Get
        Set(ByVal value As String)
            cRegion = value
        End Set
    End Property

    Public Shared Property Instance() As cRegion
        Get
            If IsNothing(mRegion) Then
                mRegion = New cRegion
            End If

            Return mRegion
        End Get
        Set(ByVal value As cRegion)

        End Set

    End Property

En esta clase el constructor permitía obtener la región configurada en el app.config; si no existía, la creaba y le asignaba un valor por defecto, en este caso un string vacío. 

Además, se implementó el patrón Singleton Instance(), utilizándose  una única instancia de dicha clase.

Se creó también una propiedad RegionDefault para obtener la región y poder cambiar su valor.

En la clase que inicializaba la aplicación (frmInicio) se creó un método para cargar la región (CargarRegion()), el cual era llamado desde el constructor por defecto.

Public Class frmInicio
Inherits System.Windows.Forms.Form

    Public Sub New()
        MyBase.New()
        Try
       'ESTO ES COMO SE OBTENIA LA REGION ANTERIORMENTE A TRAVEZ DEL PARAMETRO DEL ACCESO DIRECTO'

            'Dim sCd = Environment.GetCommandLineArgs(1)
            'Dim sCd = "Sys.xml"

          CargarRegion()

            'This call is required by the Windows Form Designer.
            InitializeComponent()
            'Add any initialization after the InitializeComponent() call
        Catch ex As Exception
            MsgBox("Se debe ingresar el parametro de inicio")
            Me.Dispose()
            Me.Close()
        End Try
    End Sub
    Private Sub CargarRegion(Optional ByVal sregion As Integer = 0)
        Dim sXml As String
        Try
            If (cRegion.Instance.RegionDefault) = vbNullString Then
                Dim frmRegion As New frmRegion
                frmRegion.ShowDialog()
            End If
        Catch ex As Exception
            oEntorno.Trazar(ex.ToString & ex.StackTrace, "SUA-CargarRegion")
        End Try
    End Sub


El método “cargar región”, es el que se encargaba de verificar si en el app.config la clave "RegionDefault" tenía un valor asociado. Si no contenía ninguna región cargada, creaba la instancia de un nuevo formulario (frmRegion) que le permitiera al usuario elegir entre las 4 regiones disponibles (Buenos Aires, Córdoba, Tucumán y Mendoza).

En el formulario frmRegion, una vez confirmada la región, se procedía a guardar el valor en el app.config:

Public Class frmRegion
 …
    ''' <summary>
    ''' Graba en nombre Archivo de Configuracion Según la Región Seleccionada
    ''' </summary>
    ''' <remarks></remarks>
    Private Sub AsignarRegion()
        Dim sRegion As String
        Dim sAppConfig As New cAppConfig
        Select Case ObtenerRegion()
            Case "BA"
                sRegion = "SysBA.ini"
            Case "CBA"
                sRegion = "SysCBA.ini"
            Case "MZA"
                sRegion = "SysMZA.ini"
            Case "TUC"
                sRegion = "SysTUC.ini"
            Case Else
                sRegion = ""
        End Select
        sAppConfig.SetProperty("RegionDefault", sRegion)
        cRegion.Instance.RegionDefault = sAppConfig.GetProperty("RegionDefault")
    End Sub


End Class

Una vez realizada la elección de la región, solo bastaba con llamar a la función que devolvía la ubicación del archivo de configuración para la región correspondiente: cRegion.Instance.ObtenerRegion

Si bien esta no es la única resolución, esperamos que les sirva y que nuestro aporte pueda ayudarlos a resolver su problema o, al menos, a orientarlos en el camino de diseñar e implementar una solución a la medida de sus necesidades.

Autores: 

Marcos Guaymas 
Técnico superior en Sistemas.

Marco Paredes Reccio 
Técnico en computación e Informática.