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.