lunes, 9 de abril de 2018

Memorias de un Arquitecto .Net - Parte 1: Lenguajes

¡Hola! Antes de adentrarnos en esta serie de artículos, sólo quería aclarar que continúo siendo Arquitecto .Net y que sigo trabajando con las plataformas de desarrollo de Microsoft. Pero los tiempos cambian, las tecnologías evolucionan y el mundo toma un nuevo rumbo todos los días.

Aquellos más jóvenes o que trabajan en otras áreas, quizás no lo tengan tan presente, pero hasta hace unos pocos años atrás tener el título de “Desarrollador .Net” (o de Arquitecto .Net) estaba asociado a construir únicamente aplicaciones Windows. Alcanzaba con conocer lenguajes como C# o VB.Net, HTML, JavaScript y SQL; con poder desarrollar utilizando la IDE Visual Studio y con saber usar algunos pocos frameworks como ASP.Net, MVC, WPF, Entity Framework, Microsoft Ajax, entre otros.

Aún no estábamos en al auge de los entornos web, ni mucho menos mobile. Y generalmente, para bien o para mal, la mayor cantidad de la lógica se ejecutaba del lado del servidor, es decir en C# o VB.Net.

Pero, y especialmente en sistemas, las cosas difícilmente se mantienen constantes con el paso del tiempo. Los que trabajamos en desarrollo vemos que la línea de lo que implica ser o no ser considerado un profesional de .Net se ha desdibujado bastante. Es así que desde hace unos años pasamos a tener que saber usar un abanico mucho más amplio de herramientas.

Sin entrar en demasiados detalles al respecto, creo que es importante que repasemos algunos de los cambios más importantes que se dieron últimamente para poder entender mejor cómo se ha modificado la concepción de lo que implica construir aplicaciones:
  • Primero y, antes que nada, se ha reducido notablemente la cantidad de desarrollos de aplicaciones de escritorio tal y como las conocíamos hasta hace unas décadas atrás.
  • Esto vino de la mano del incremento en la construcción de aplicaciones web, tanto para usuarios finales como internos. Y uno de los principales motivos que generó este salto fue la evolución de los lenguajes HTML, CSS y JavaScript, los cuales originaron la creación de frameworks y bibliotecas que extendieron ampliamente su funcionalidad de base.
  • Y cuando creíamos que gozábamos de cierta “tranquilidad tecnológica”, se produce la masificación de los teléfonos móviles primero, y la irrupción en el mercado luego de dispositivos sobre los cuales jamás se nos hubiera ocurrido poder desarrollar (como las SmartTV por ejemplo). Y es acá donde surgen conceptos como Cross-Platform, Reponsive Applications, Mobile First, entre otros.
  • Desde el punto de vista de la Comunidad, hubo un aumento exponencial de las herramientas y componentes open source, se trabajó en la integración de sistemas que hasta hace un tiempo funcionaban de forma aislada, se consolidó el trabajo en equipo, se tomó conciencia de las ventajas de compartir nuestro conocimiento, e Internet permitió difundir estos temas llevándolos al alcance de la mano de cualquier desarrollador a lo largo y ancho del planeta.
  • Por su parte, del lado de Microsoft, hubo un cambio de enfoque radical que tomó mayor impulso con la llegada de Satya Nadella como CEO a la compañía en 2014. Desde entonces, la empresa se ha abierto más a la comunidad profesional y ha tomado decisiones que parecen haber cambiado para siempre el enfoque del desarrollo de aplicaciones .Net, como por ejemplo la integración con bibliotecas open source, la adquisición de Xamarin, el desarrollo de .Net Core, la capacidad de instalar SQL Server en Linux, etc.

Entonces, para tomar conciencia de la magnitud del impacto de estos cambios en nuestros perfiles como técnicos, analicemos cuántos lenguajes y frameworks deberíamos conocer mínimamente hoy en día para considerarnos buenos profesionales .Net.
  • A nivel de lenguajes de backend, además de conocer C# y/o VB.Net, no podemos dejar de incluir a Node.JS, que hoy por hoy cuenta con un fuerte respaldo de parte de Microsoft.
  • Si nos centramos en la capa de datos y acceso a datos, tenemos que conocer tanto SQL para poder utilizar motores RDBMS (como SQL Server, MySQL, Oracle); como lenguajes para el manejo de BD no relacionales (como Mongo DB o Redis).
  • A nivel de frameworks, deberíamos tener conocimientos sobre Entity Framework, NHibernate y ADO.Net. Y además saber que contamos con extensiones, como Fluent NHibernate o AutoMapper entre otras, que nos facilitan la integración entre la base de datos y nuestra aplicación.
  • En el caso de que trabajemos con una capa web, además de HTML-CSS-JS, deberíamos mínimamente conocer algo de AngularJS, Angular, Bootstrap, React, TypeScript, Knockout.js, jQuery, y Backbone.js; por nombrar sólo a los principales actores del mercado.
  • Adicionalmente, existe un universo muy amplio de bibliotecas que se integran a las plataformas mencionadas anteriormente y permiten extender la funcionalidad de nuestras aplicaciones con un esfuerzo de desarrollo mínimo: DataTables, jQueryUI, SlideJS, jqGrid, jqPlot, Mermaid, Moment.js, KendoUI, Globalize.js, Jasmine, etc.
  • Si en cambio nuestra aplicación es de escritorio, deberíamos saber usar frameworks como WPF y UWP (Universal Windows Platform).
  • Y finalmente, si nuestra aplicación está dirigida al universo mobile, deberíamos tener el concepto de lo que implica el desarrollo para dispositivos móviles y los lenguajes propios de iOS (Swift/Objective-C) y Android (Java). Dentro de lo que corresponde al alcance de Microsoft, podemos mencionar a Xamarin y Xamarin.Forms como plataformas de desarrollo, las cuales se integran directamente a Visual Studio desde su versión 2015 y que nos permiten generar aplicaciones nativas multiplataforma utilizando como lenguaje de desarrollo C#.


Además, existen cientos de librerías open source en NuGet que podremos incorporar en nuestros desarrollos para simplificar nuestro trabajo y sumar funcionalidad estándar a nuestras aplicaciones. 

¿Y si le sumamos el hecho de que actualmente existen dos tipos Frameworks .Net? Por un lado, el Framework .Net clásico, que ya va por su versión 4.7 y, por el otro, la implementación abierta y multiplataforma .Net Core, cuya versión 2.0 fue liberada recientemente en agosto de este año.

Y no nos olvidemos que también podemos optar por tres IDE para trabajar en .Net: Visual Studio (ya está disponible la versión 2017), Visual Studio Code (la última versión liberada fue la 1.18.0) y la flamante IDE Visual Studio for Mac.

Son todos estos ingredientes los que terminan repercutiendo en nosotros como profesionales, ya que nos lleva a salir de nuestra zona de confort y explorar otras posibilidades impensadas hasta hace unos años como, por ejemplo, desarrollar una aplicación .Net que corra en Linux y/o Mac; el poder desarrollar aplicaciones para Android con C#, o construir una aplicación MVC desde una Mac y desplegarla en Docker en vez de en un IIS en Windows.

¿Interesante no? A simple vista parecen bastantes componentes los que debemos tener en nuestra caja de herramientas. El truco para no ahogarnos en un vaso de agua está en saber cuál utilizar en el contexto de cada proyecto y cómo integrar cada parte con el resto de las tecnologías que elijamos.

Mi consejo, de cara a los próximos años que se vienen, es que como profesionales debemos capacitarnos. Y no sólo haciendo un curso de C# o Visual Studio, sino formándonos sobre diferentes lenguajes, tecnologías y plataformas para ampliar nuestra mente.

Además, debemos conocer y aprender a usar una gran cantidad de frameworks y bibliotecas y tomar conciencia de que gran parte del desafío no es simplemente saber usarlas (para eso tenemos la documentación de cada una de ellas disponible en Internet), sino saber cómo integrarlas para que todas funcionen correctamente en conjunto.

Cada uno de nosotros deberíamos tomarnos el tiempo de evaluar qué nos está faltando incorporar y comprometernos a salir a buscarlo, principalmente, a través de la formación y de la experimentación.

En próximos artículos vamos a continuar debatiendo estos cambios que se están dando y que tienen un fuerte impacto para los que trabajamos vinculados a tecnologías .Net.

¡Hasta la próxima!

Autor:
Ing. Ariel Martín Bensussán
.Net Practice Manager

jueves, 5 de abril de 2018

Database Testing

Las pruebas de base de datos generalmente consisten en un proceso en capas, que incluye la capa de la interfaz de usuario (UI), la capa de negocios, la capa de acceso a los datos y la base de datos en sí misma.

La capa de UI se ocupa del diseño de la interfaz de la base de datos, mientras que la capa de negocios incluye bases de datos que soportan estrategias comerciales.



Tipos de testing en base de datos: 

Basándose en la función y la estructura de una base de datos, las pruebas pueden clasificarse en tres categorías:
  • Pruebas de bases de datos estructurales: se trata de pruebas de tablas y columnas, pruebas de esquemas, procedimientos almacenados y pruebas de vistas, comprobación de disparadores, etc.
  • Pruebas funcionales: se trata de comprobar la funcionalidad de la base de datos desde el punto de vista del usuario. 
  • Pruebas no funcionales: implica realizar pruebas de carga, pruebas de riesgo en la base de datos, pruebas de estrés, requisitos mínimos del sistema y evaluación del rendimiento de la base de datos.


Técnicas de testing en bases de datos: 

A continuación, se enlistan las técnicas de ejecución de pruebas en bases de datos.
  1. Prueba de esquema de base de datos: 
        Implica probar cada objeto en el esquema de la siguiente manera:
  • Verificación de bases de datos y dispositivos.
  • Verificación de los elementos que se indican a continuación para validar las diferencias entre el ajuste real y el aplicado: nombres y tipos de columnas de cada tabla, verificación de valores NULL, definiciones de reglas para corregir nombres de tabla y privilegios de acceso.
  • Clave e índices: comprobar la clave y los índices en cada tabla. 
     
     2. Pruebas de stored procedures

         Implica verificar si se define un stored procedure y se comparan los resultados de
         salida. En una prueba de este tipo, se deben comprobar los siguientes puntos: 
         nombre del stored procedure, parámetros, salida y funcionamiento. 

     3. Pruebas de activación: 

         En una prueba de triggers, el tester debe realizar las siguientes tareas: validar el
         nombre del trigger y la generación de valores/datos en tablas específicas, 
         actualizar un registro con datos válidos y no válidos y asegurarse de revertir las
         transacciones luego de un error. 

     4. Scripts de configuración del servidor:  
      
         Se deben realizar dos tipos de pruebas: configurar la base de datos desde cero y
         configurar una base de datos existente.

     5. Método de prueba funcional:

        Las pruebas funcionales se pueden realizar dividiendo la base de datos en módulos
        según la funcionalidad. Las funcionalidades son de dos tipos: 
  • Tipo 1: en pruebas de tipo 1, averigüe las características del proyecto. Para cada característica principal, examine el esquema, los triggers y los stored procedures responsables de implementar esa función y ponerlos en un grupo funcional. Luego pruebe cada grupo junto.
  • Tipo 2: en pruebas de tipo 2, el borde de los grupos funcionales en un back-end no es obvio. Puede comprobar el flujo de datos y ver dónde puede verificar los datos. Comience desde el front-end.

    6. Pruebas de estrés:

       La prueba de estrés consiste en obtener una lista de las principales funciones de la
       base de datos y los procedimientos almacenados correspondientes. Siga los pasos que
       se indican a continuación para realizar la prueba de estrés: escribir scripts de prueba
       para probar esas funciones y verificar al menos una vez en un ciclo completo, realizar
       los scripts de prueba durante un periodo de tiempo específico, verificar los archivos
       de registro para comprobar bloqueos, fallas de memoria o corrupción de datos. 

   7. Pruebas de referencia: 

      Si su base de datos no tiene problemas de datos o errores, se puede comprobar el
      rendimiento del sistema. Un rendimiento deficiente del sistema se puede encontrar
      en las pruebas de referencia mediante la comprobación.

   8. Prueba de una base de datos a través de front-end:

      Los errores de fondo también se pueden encontrar a veces haciendo pruebas front
      end. Puede seguir los sencillos pasos que se indican a continuación para detectar
      errores en las pruebas front-end: emitir búsquedas desde el front-end, cambiar 
      valores en campos de un registro existente, insertar un nuevo elemento y guardar el
      registro, eliminar un registro existente. Repetir los casos con datos no válidos.

Database recovery testing:
Las pruebas de recuperación le permiten averiguar si la aplicación se está ejecutando correctamente y revisar el recobro de datos invaluables que se habrían perdido si su método de recuperación no estuviera configurado adecuadamente. También comprueban si varios procesos críticos se están ejecutando bien para asegurar que la recuperación de datos pasará sin problemas durante la fase de prueba. 
Es necesario ejecutar las pruebas de recuperación en la primera fase del proyecto, ya que esto le permitirá eliminar y desechar todos los tipos de errores del sistema.

Referencias: 

Autor: 
Matías Argüeso
Technical Tester.

miércoles, 28 de marzo de 2018

Arduino controlando el tránsito

Hace un tiempo que venía pensando en hacer algo con Arduino que uniera el mundo físico con el de la programación. Comúnmente, al desarrollar, sólo interactuamos con las clásicas interfaces de usuario como el teclado o el mouse (y si tenemos suerte, con una pantalla táctil), pero Arduino me resultó interesante ya que permite obtener información de diferentes sensores y generar eventos a partir de ellos. Hay muchísimos sensores, como por ejemplo de temperatura, de luz, de presencia, de movimiento, de distancia, de inclinación, de gas, de fuego, de agua, pulsadores, entre tantos otros.

Buscando información sobre cómo comenzar, encontré que siempre se empieza con el mismo ejemplo: cuando se presione un botón pulsador, que se mantenga encendido un led por algún tiempo. Aunque esto parezca algo demasiado sencillo, se puede extrapolar a diferentes conceptos. O sea,  si reemplazamos el botón por un sensor como uno de luz y el led por una lamparita, podemos definir que si detecta que la iluminación del ambiente baja de un determinado umbral, se prenda la luz. Otro ejemplo sería reemplazando el botón por un sensor de nivel de agua y el led por un motor centrífugo. De esta forma podemos hacer que el motor suba agua a un tanque si el nivel del mismo alcanza un mínimo y apagarlo después de un tiempo.

Además de conocer más sobre estos ejemplos, hice un curso en https://www.coursera.org/ que brindaba la Universidad Autónoma de México, pero me pareció extremadamente básico (creo que el público objetivo eran chicos que apenas terminan la primaria). Luego encontré otro curso en la misma página, pero brindado por el Instituto de Física y Tecnología de Moscú, que realmente me pareció muy bueno. 

En esta nota intentaré describir como fue el proceso para realizar la tarea que requería el curso. Podrán ver el código, los componentes necesarios y un video del proyecto terminado en el repositorio de Github

El desafío 

Este curso tenía como tarea crear un robot (en su definición más formal) el cual controlara un modelo que representara un cruce de las vías del tren con un camino peatonal y una vía para autos. 


Por un lado tenemos que detectar cuando se acerca el tren. Para ello utilizamos un sensor de distancia por ultrasonido y para cuando un peatón quiere cruzar, se usa un botón de presión. Por otro lado, debemos informar a los vehículos cuando pueden pasar para lo cual ponemos una barrera en el camino. De la misma forma tenemos que avisar a los peatones si pueden cruzar y para ello usamos un semáforo, o sea, un led verde y uno rojo y además, generamos sonido por medio de un buzzer.
  
Entonces, el modelo debía cumplir con las siguientes reglas: 
  • Si aparece el tren, el semáforo se tiene que poner en rojo y bajar la barrera.
  • Una vez que pasó el tren, debe mantener el semáforo en rojo y abrir la barrera.
  • Si un peatón quiere cruzar debe presionar el botón, el cual baja la barrera y pone el semáforo en verde. 
  • Si el peatón presiona el botón mientras pasa el tren, una vez que este termina de pasar el semáforo debe ponerse en verde y mantener la barrera baja. 
  • La luz verde del semáforo se mantendrá encendida durante 5 segundos y después será intermitente por los próximos 4 segundos. El sonido de la alarma deberá cambiar también al llegar a los 4 segundos. 
  • El peatón deberá esperar 18 segundos desde la última vez que se le dio paso hasta que se le permita nuevamente. Los primeros 9 segundos tendrá la luz del semáforo en verde y los siguientes serán los vehículos quienes tengan habilitado el paso. 


Al parecer, estas reglas son sencillas, pero fue realmente desafiante lograrlas. 

Comiendo al elefante

En este caso los pequeños bocados fueron: 
1. Planeación: hacer un diagrama del mundo físico, la señal eléctrica y el código. 
2. Diseño: hacer un diagrama de estados 
3. Construcción: construir el código 
4. Implementación: construir el modelo físico

Planeación

Sabía que tenía ciertos requerimientos que se iban a convertir en componentes específicos y necesitaba saber si me alcanzaban los pines que tiene disponible la placa de Arduino, como por ejemplo, para el semáforo necesitaba dos led: uno rojo y otro verde, esto a nivel de la señal eléctrica requiere de un pin para cada uno. Para detectar el tren, precisaba algún tipo de sensor de presencia y decidí usar un medidor de distancia por ultrasonido (podría haber usado uno por IR, o un sensor de luz, etc.). En este caso el sensor requiere 2 pines más. También necesitaba el botón pulsador para los peatones, un servo para subir y bajar la barrera que habilita el tránsito de los autos y el buzzer para la señal sonora del aviso del tren.


Diseño

Definí una máquina para representar sus estados y sus transiciones ya que son muy marcados. Por ejemplo, no hay manera de que cuando esté habilitado el paso del tren se habilite a los peatones o los vehículos. Por otro lado, las transiciones también son muy representativas, o sea, si estaba pasando el tren y fue presionado el botón de los peatones la transición es TREN_A_PEATONES con los cual es más fácil decidir mantener baja la barrera y poner el semáforo en verde. 





Construcción

Comencé usando el IDE propio de Arduino, pero realmente no es más que un notepad con los botones de validar y subir, por lo que casi lo descarté al instante. Buscando un IDE mejor para trabajar, encontré un plugin para Visual Studio Code que integra con Arduino que me pareció bastante bueno. Este plugin permite tener en el IDE características como completador de código, descripción de las variables, ayuda sobre las funciones y la posibilidad de engancharlo con el GIT, entre otras. Todas funcionalidades que no tiene el IDE propio de Arduino, por supuesto. Además, permitir validar (Ctrl-Alt-R) y subir (Ctrl-Alt-U) el código al Arduino, ver la consola del puerto serie y hacer un debug del programa (algo que no llegué a probar). 

Una decisión de código fue separar en archivos diferentes (helpers.ino y UltraSoundSensor.ino) las funciones que no son específicas de este proyecto, por ejemplo la que hace la medición del sensor o la que sube o baja la barrera, dejando en el archivo principal (Proyecto_1.ino) las funciones que tienen lógica de negocio. 




Implementación

Comencé por poner los leds y el botón para generar el cambio de estado para habilitar a los peatones. Después puse la barrera y el estado de los vehículos y, por último, el sensor del tren con sus cambios de estados y transiciones. En ese momento me di cuenta que el sensor a veces daba un valor muy bajo y que, por lo que llegué a leer, puede deberse a la baja calidad de los componentes, la interferencia en los cables o los cambios de voltajes generados posiblemente por el servo de la barrera. Para solucionarlo, redefiní el método que mide la distancia para que devuelva el promedio entre 10 lecturas y que, de este manera, se filtren los valores extremos. 





Conclusión

Arduino permite unir el resultado de varios sensores y generar eventos en los componentes de salida de una forma sencilla y a muy bajo costo. Obviamente hay que tener ciertos conocimientos de electrónica y de programación básicos, pero la experiencia se puede ir adquiriendo a medida que uno construye. 

Con respecto al curso online, realmente fue muy bueno. Además de incrementar la complejidad módulo a módulo, me aportó técnicas para resolver situaciones comunes. 

Usar VSCode como IDE realmente me simplificó las tareas como commitear el código en el repositorio y poder volver atrás después de hacer algunas pruebas.

Al final de cuentas, encontrarme sin conocimientos, investigando y aprendiendo fue realmente muy entretenido.

Imágenes del modelo terminado
  


Link al video aqui

LINKS
  
Autor:
Marcelo Mosquera
.NET Technical Expert

miércoles, 14 de marzo de 2018

JQgrid- Como cambiar el color de las filas de forma dinámica

Antes que nada, quiero comentarles que la solución empleada es una de las tantas que pueden encontrarse en internet. Pero a veces, estoy seguro que al menos alguna vez les ha pasado, la solución encontrada no se ajusta al problema que queremos resolver o, directamente, no funciona.  Es en esos momentos donde siempre recuerdo la frase para estas situaciones: “No es como en las películas”.

A continuación, les doy una solución que realmente sirvió en mi caso y que quería compartir para que, aquellos que se encuentren con este problema, sumen otra alternativa más en su lista de soluciones posibles.

El pedido

Para un proyecto en el cual estaba dando mantenimiento, se pidió implementar una funcionalidad donde poder identificar en una grilla por medio de colores, las filas que generaron diferencias en las compensaciones. No voy adentrarme mucho en detalle sobre las reglas de negocio de la aplicación, sino que quiero poner foco en cómo llegué a poder resolver el problema de una forma rápida, sencilla y correcta. En principio, lo único que deben recordar es que es una grilla con compensaciones, donde algunas filas tienen diferencias y otras no.

Se optó, para este caso en particular, resaltar en rojo aquellas filas que tuvieran diferencias, y en verde las que no.

Ya planteado el problema, pasemos entonces a evaluar la solución.

La solución que tuvo éxito

Teniendo en cuenta los eventos que posee JQgrid, se tomó específicamente el evento .onLoadComplete(). El mismo permite ejecutar acciones posteriores al momento de finalizarse la carga de la grilla en la vista.

Entonces se procedió a agregar una Función JavaScript al evento llamada loadComplete() [figura 1]

@(Html.jqGrid("Grilla")
.onLoadComplete("loadComplete()")

Figura 1 –se agrega la función al evento 

Dentro de esta función se llama a la propiedad “jqGrid('getDataIDs')” de la grilla, la cual nos permite obtener los ID de cada una de las filas de la grilla. Una vez que los tenemos, entonces se puede acceder a la celda que se necesita evaluar, por medio de la propiedad getCell(), especificando el ID de la fila y el nombre de la columna que se desea verificar.

var rowIds = $("#Grilla").jqGrid('getDataIDs');                  
rowData = $("#Grilla").getCell(rowIds[i], 'Diferencia');
Luego se toma como referencia algún valor que determine la condición que debe tener en cuenta para aplicar el criterio de los colores. En nuestro ejemplo, vamos a evaluar si contiene a la letra ‘N’.

Este es un caso muy específico, pero puede aplicarse a otro tipo de condiciones, no tiene por qué ser solo una columna, ni tampoco un solo valor. Hasta puede ser una ecuación entre varios datos de distintas columnas. Pero mi consejo es que en lo posible busquemos resolver esta cuestión antes de que llegue a la grilla, es decir, en el backend de la aplicación. De este modo, con sólo agregar una columna más a la grilla y ocultarla será más sencillo de evaluar la condición del lado del cliente. 

Veamos cómo quedó el código completo.

var rowIds = $("#Grilla").jqGrid('getDataIDs');
  
  //recorre todos los id de la grilla
for (i = 0; i <= rowIds.length; i++) {

//obtiene el valor de la celda y lo evalúa
rowData = $("#Grilla").getCell(rowIds[i], 'Diferencia');
     if (rowData != 'N') {
        //aplica la clase  ‘ConDiferencias’ de css  a toda la fila     
$("#Grilla").jqGrid('setRowData', rowIds[i],true,     'ConDiferencias');
     }
else
{
   //aplica la clase  ‘SinDiferencias’ de css  a toda la fila
$("#Grilla").setRowData(rowIds[i], false, 'SinDiferencias');
     }
 }//fin for

Podemos notar que, en primera instancia, luego de obtener los ID de la grilla necesitaremos recorrerlos para acceder a cada propiedad de la fila.

Luego obtenemos el valor de la celda y se evalúa el criterio para aplicar los colores. Para este caso usamos la propiedad setRowData() para modificar el estilo de la fila.  

En esta propiedad se debe indicar en qué fila (rowIds[i]) y cuál estilo debe aplicar. Como se puede ver hay dos maneras de invocarla:

$("#Grilla").jqGrid('setRowData',rowIds[i],true,'ConDiferencias');
ó
$("#Grilla").setRowData(rowIds[i], false, 'SinDiferencias');

El parámetro que se pasa como “false” en la segunda forma, indica que va a afectar a toda la fila.

Un punto muy importante a tener en cuenta para que esto funcione, es que el campo que se quiere evaluar debe estar configurado como ID en la grilla jqgrid.

Esta solución fue muy útil y rápida al no tener que modificar ninguna configuración de la grilla y sirvió como ejemplo para otras pantallas e, incluso, para otros proyectos.

Autor
Marcos Guaymas – 
Técnico superior en Sistemas – 
Desarrollador .Net en Baufest

miércoles, 28 de febrero de 2018

Xamarin, una alternativa emergente en el mundo del desarrollo mobile

Para quienes estamos acostumbrados a utilizar Visual Studio como entorno de desarrollo para la tecnología .NET y C# como lenguaje de programación, Xamarin y Xamarin.Forms resultan herramientas llamativas y poderosas que nos permiten generar aplicaciones Mobile multiplataforma en un ambiente conocido y, además, nos da la ventaja de poder mantener el mismo lenguaje.

Una de las principales características de Xamarin es que, si bien desarrollamos en un lenguaje que nos es familiar, la compilación se realiza nativamente en los lenguajes utilizados en los dispositivos destino. De esta forma, es una alternativa muy performante en comparación a otras herramientas como Apache Cordova, que ejecuta la aplicación en un browser resultando costoso en cuanto a recursos del dispositivo. 

Otro punto fuerte es la posibilidad de generar código reutilizable, centralizando toda la lógica de negocio en un solo lugar, ahorrando código y tiempo al momento de desarrollar. 

Además, esto nos permite mantener el código de una manera más sencilla, ya que haremos las modificaciones en un único lugar y afectará por igual a todas las plataformas.

En el caso de Xamarin.Forms, nos encontramos con una herramienta que nos permite crear la interfaz de usuario con un único código que será interpretado por cada sistema operativo y renderizado de la manera más adecuada para cada uno de ellos. Esto se logra mediante un lenguaje denominado XAML, que resulta ser una variación del lenguaje XML con etiquetas propias de Xamarin.Forms. 

Un aspecto negativo es la falta de una vista previa (designer) en Visual Studio, debiendo ejecutar el emulador para poder visualizar el resultado del código en la UI. 


Esta característica de XAML se vuelve una desventaja al momento de querer realizar aplicaciones customizadas de acuerdo a cada sistema operativo. En estos casos es donde Xamarin resulta una mejor propuesta a la hora de diseñar una interfaz de usuario más personalizada para cada tipo de dispositivo.


Uno de los problemas más frecuentes con el cual uno se puede encontrar al comenzar a trabajar con esta herramienta en Visual Studio es un asunto de referencias. Nuget nos ofrece actualizaciones constantemente, lo cual a simple vista es una característica muy eficiente. Sin embargo, en este caso puede jugarnos en contra. Por ejemplo, si en el proyecto de Android tenemos configurada la versión de destino en 6.0 (API 23),  Xamarin.Forms tendrá ciertas dependencias específicas para los packages de Android Support y si actualizamos todos los packages, lo más probable es que estas referencias nos arrojen algún error de incompatibilidad.

Una manera sencilla de resolver esto es borrar manualmente todos los packages del Nuget en el proyecto de Android y luego volver a agregar aquel de Xamarin.Forms. Esto va a causar que se descarguen automáticamente todas las dependencias compatibles para el tipo de proyecto, quitando la posibilidad de errores de incompatibilidad.

Ejemplo de código con controles básicos como Label, Input y Button

Emulador de Android corriendo con el código mostrado anteriormente

En conclusión, gracias a la fuerte apuesta de Microsoft sobre Xamarin, podemos decir que finalmente se ha abierto el mercado de aplicaciones Mobile a aquellos que nos encontramos en el ambiente de tecnologías .NET, pudiendo utilizar cualquiera de estas dos herramientas dependiendo el tipo de aplicación que necesitemos crear y el alcance de plataformas que deseemos tener.

Autores
Javier Ledesma, .NET Developer. 
Nicolás Ramírez, .NET Developer.