miércoles, 23 de mayo de 2018

Las claves de SQL que pueden mejorar tus consultas

Cuando uno piensa en consultas en SQL surgen ciertas incertidumbres ¿Traerá los datos que quiero? ¿La consulta será performante? A medida que uno se inmerge en el mundo SQL va descubriendo pequeños tips o reglas que le pueden salvar la vida o por lo menos tiempo de trabajo.

Al comenzar a realizar consultas reiterativas aprendimos que una de las mejores opciones que uno puede aplicar a esto es generar Stored Procedures (SP). Estas son consultas ejecutables, las cuales, a través de una invocación se puede iniciar una consulta pre diseñada. Esto ahorra horas de generar código, si es que siempre se requiere la misma query. 

Cuando comenzamos a diseñar SP vemos las ventajas del uso de variables. Pero cuidado, estas pueden ser un arma de doble filo y por eso hay que tratar de usar la mínima e indispensable cantidad. Esta recomendación aplica también a las tablas temporales, ya que su uso excesivo puede generar problemas en la performance.

Una muy buena práctica dentro de los SP es inicializar todas las variables que vayamos a utilizar, es decir, definir bien su tipo de dato y tamaño. Esto permite evitar que luego surjan problemas por el tamaño de dato que acepte una columna y se generen errores al momento de ejecutar la consulta.

Por otro lado, al momento de realizar joins en los SP entre columnas de tablas diferentes, es útil que los campos por los cuales joineeamos contengan índices, ya que éstos mejoran la performance del SP. Los índices permiten optimizar el acceso a datos, ya que a medida que las tablas se van extendiendo estos se vuelven altamente necesarios para mantener buenos niveles de performance. Pero a la hora de utilizarlos hay que tener en cuenta que sean los correctos, debido a que no es una buena práctica crear índices sobre todas las columnas ya que, como consecuencia, esto impactaría en la búsqueda que realiza el motor de base de datos, y afectaría negativamente su rendimiento.

Otra situación que afecta directamente a los tiempos de consulta es el uso de los favoritos ORDER BY y SELECT DISTINCT. Estos polémicos personajes generan ventajas y desventajas al utilizarlos. Al decidir cuál utilizar hay que prestarle atención a la funcionalidad del SP. Siendo el SELECT DISTINCT un gran actor al traer datos diferentes, este está enfocado a optimizar el uso de memoria. Mientras que el ORDER BY está centrado en la velocidad de ejecución, y en el uso de memoria suele ser deplorable…

De las grandes ventajas que nos ofrecen los Procedures, la más importante es el hecho que puedan interpretar parámetros y devolver otros, y eso los hace excesivamente útiles. Otra de las ventajas de usar SP es la rapidez que se obtiene al procesar datos en el servidor. Una de las razones por la que sucede esto, se debe a que los datos se procesan en memoria, en el mismo servidor de la base de datos; y sólo se retornan los datos realmente necesarios. Por el otro lado, si esto se tuviera que hacer en el Web Server, o App Server, tendríamos que traernos todos los datos por red, para luego terminar filtrando solo unos pocos.

Concluyendo la nota, nuestra intención no es imponer el uso de los Stored Procedures, ya que todo lo que podés realizar dentro de ellos, también lo podés hacer utilizando querys. Igualmente los recomendamos, solamente mencionamos algunas de sus ventajas, pero vastas en cantidad. Por ejemplo, la seguridad que ellos nos brindan pudiendo encontrar errores en tiempo de compilación y no en tiempo de ejecución.  

Otro dato importante para tener en cuenta es que su uso va a depender de la funcionalidad que se le dé, para consultas gigantescas y que utilizan varias tablas son muy útiles, la query va a ser mucho más rápida en comparación con consultas que se realizan desde NHibernate.  En cambio, si tu objetivo va a ser realizar consultas simples, otros métodos van a ser más eficaces.

Autores:
Mara Guerrera - Tomas Borodowski 
Desarrolladores .Net en Baufest

miércoles, 16 de mayo de 2018

El arte de liderar un equipo

El Arte de la Guerra de Sun Tzu es tan antiguo como famoso. ¿No lo conocés? No pasa nada, podés leerlo, ¡justo después de terminar este artículo! 

El resumen sin spoilers, cuenta que el libro trata sobre estrategias militares para la guerra, pero la realidad es que sus enseñanzas se pueden aplicar en cualquier ámbito, incluso en la vida misma. Si no me crees, te invito a que te quedes un rato más leyendo mi experiencia liderando equipos ágiles y cómo encontré por las buenas, o incluso en ocasiones por las malas, que las enseñanzas del libro son universales. 

¡Alerta, ahora sí vienen spoilers! Trabajé en ciertos proyectos en los cuales reinaba el caos y cada día la situación nos consumía un poco más como equipo, al punto de sentir que no íbamos a llegar al final del mismo. Seguro te pasó lo mismo, igual que a Sun Tzu. Él afirmaba: “El arte de la estrategia es vital, es el terreno de la vida y la muerte, el camino a la seguridad o la ruina”. Así aprendí a tropezones que, la estrategia que definas para tu equipo en momentos de tranquilidad es esencial y, en momentos de dificultad, aún más. 

Como líderes de equipo se espera que no caigamos en la vorágine del contexto y tengamos la lucidez de determinar la estrategia que revierta la situación. Ésta debe contemplar las personas que integran nuestro equipo, los procesos que hayamos adoptado y la tecnología aplicada.

Es muy fácil decirlo ¿no? Bueno, es verdad que en la práctica es más complejo. No es que podamos tatuarnos todo el cuerpo con el plan a seguir para lograr nuestro objetivo. 

¿Cuál es la receta entonces? Lamento decir que, si la hay, no la tengo, por lo que nuevamente recurro a lo que aprendí de este libro. Adaptando una de sus mayores premisas, podemos decir que, si conocés a tu equipo y te conocés a vos mismo, ni en cien proyectos correrán peligro. Si no conocés a tu equipo, pero te conocés a vos mismo, fallarás en un proyecto y tendrás éxito en el otro; pero si no conocés a tu equipo ni te conocés a vos mismo, correrán peligro en cada proyecto que afronten.

Personalmente me resultó difícil entender que, si bien hay tareas que no son obligatorias, pero sí indispensables para alcanzar el objetivo, gran parte del equipo pueda no estar dispuesto a completarlas por no ser de su agrado o interés. Mi error fue creer que, a pesar de ello, serían completadas por el simple hecho de existir la necesidad.

El desafío como líder, es encontrar qué motiva a cada uno, qué les apasiona, arengarlos a que exploren de manera creativa nuevos aspectos y que aborden temas innovadores para aplicarlos en nuestra área. En resumidas cuentas, ser capaces de utilizar el ingenio para convertir temas rutinarios en algo nuevo y tentador.

¿Cuántas veces leyeron en las redes artículos titulados “los 5 hábitos de las personas exitosas”, ¿O, “los 10 secretos de grandes emprendedores”? o notas similares, tan atractivas como engañosas? Sí, yo también caí en la trampa. La realidad es que ninguno de ellos inventó estos hábitos o secretos, que son tan antiguos como este comandante chino. Si no me creés, te comparto un fragmento: “el punto final de la formación de un ejército es llegar a la no forma. Así pues, un ejército no tiene formación constante, lo mismo que el agua no tiene forma constante: se llama genio a la capacidad de obtener la victoria cambiando y adaptándose”.

El mundo está en constante evolución, transformándose a cada minuto. Por eso es indispensable aceptar este hecho y ser parte del cambio. Nuestro gran enemigo es la zona de confort, por eso hay que vencer el miedo, dejar los prejuicios de lado y animarnos a crecer en equipo desafiándonos día a día. El cómo hacerlo será un ejercicio personal y colectivo para descubrir el método que mejor se adapta al grupo. 

Para cerrar, quisiera dejar un consejo que tomé del autor y que, no sólo me ha servido profesionalmente, sino para la vida en general: “Si puedes recordar siempre el peligro cuando estás a salvo y el caos en tiempos de orden, permanece atento al peligro y al caos mientras no tengan todavía forma, y evítalos antes de que se presenten; ésta es la mejor estrategia de todas.”

Autor:
Axel Labruna
Baufest DevOps Technical Specialist

miércoles, 9 de mayo de 2018

Memorias de un Arquitecto .Net - Parte 3: Herramientas

¡Hola! En esta tercera y última entrega de la serie “Memorias de…” vamos a enfocarnos en otra de las evoluciones que se vienen dando en el mundo Microsoft. En esta oportunidad, vamos a analizar qué pasó con las herramientas de apoyo a la construcción de aplicaciones que nos ofrece la compañía y cómo esto ha alterado el tablero de juego de quienes desarrollamos SW.

Trabajemos o no con .Net, no podemos dejar de reconocerle sus méritos a Visual Studio como una muy buena IDE para el desarrollo de soluciones de SW. Es cierto, como toda aplicación tiene sus aspectos a mejorar, pero la realidad es que funciona bastante bien.

Sin desmerecer las versiones previas, podemos decir que la historia de Visual Studio comenzó a pisar con fuerza con la llegada de la versión 2003, lanzada al mercado en abril de ese mismo año. Si bien era modesta, incluía varios features interesantes para la época. Desde entonces, no paró de crecer a pasos agigantados y con cada nueva versión se incluían más y mejores características que nos facilitaban el trabajo a los desarrolladores. Así siguió evolucionando, pasando por las versiones 2005, 2008, 2010, 2012, 2013 y 2015.

Finalmente llegamos al presente. Y es aquí donde quiero que prestemos atención a algo interesante: además de liberar al mercado la versión 2017, recientemente surgieron dos versiones en paralelo. Estas fueron construidas totalmente desde cero, para dos sectores de la comunidad que anteriormente no encontraban en VS un espacio de trabajo acorde a sus necesidades, y por qué no, a sus propios gustos.

En primer lugar, quiero mencionar a Visual Studio Code, la interfaz de desarrollo Open Source de Microsoft. Gracias a un sinfín de extensiones permite desarrollar prácticamente en cualquier lenguaje moderno que podamos imaginar. Está destinada a la comunidad en general, tanto a aquellos que trabajamos con .Net, como a quienes utilizan otras tecnologías: Java, PHP, Ruby, Node.JS, y la lista sigue.

Y en segundo lugar quería comentar que a comienzos del 2017 Microsoft ha lanzado al mercado Visual Studio for Mac, destinada a todas aquellas personas que desde sus Mac quieran desarrollar aplicaciones tanto para este sistema, como para los dispositivos móviles (a través de Xamarin) y para Linux y Windows. Lo mejor de todo, viene con C# y .Net Core integrado nativamente.

¿Visual Studio es la única IDE disponible hoy en día en el mercado? ¡No! Hay un montón más. Las hay propietarias e independientes. Cada una tiene sus ventajas y desventajas, y conviene usarlas o no, de acuerdo al contexto de cada proyecto. Pero no podemos negar la fuerte apuesta que está haciendo Microsoft al respecto: ofrecer plataformas de desarrollo para diferentes grupos de profesionales.

Pasemos a otro grupo de herramientas: los repositorios de código fuente. Mientras escribo me pregunto, ¿cuántos de ustedes llegaron a usar Visual SourceSafe? Yo recuerdo que fue el primer repositorio que utilicé de la mano de la tecnología .Net, y no tengo muy gratos recuerdos al respecto. Seamos objetivos, la herramienta no era mala, pero tampoco era buena. Ahora bien, en el contexto de aquella época, funcionaba y con eso nos alcanzaba.
Ya ha pasado bastante tiempo desde que Microsoft decidió discontinuar VSS en favor de Team Foundation Server (más conocido como TFS). Esta herramienta es una suite completa que permite gestionar tanto código fuente como otros artefactos relacionados con los proyectos de desarrollo. En lo que respecta al almacenamiento de código fuente, el módulo que se encarga de gestionar esta funcionalidad se llama Team Foundation Version Control (TFVC). La primera versión de TFS fue liberada en 2005, y siguió creciendo a lo largo de los años, pasando por las versiones 2008, 2010 y 2012.

Sin embargo, en línea con los cambios que se vienen debatiendo, desde la versión 2013, tenemos la oportunidad de contar con una alternativa a TFVC: ni más ni menos que la posibilidad de poder elegir Git como repositorio a la hora de generar un nuevo proyecto en el TFS. Lo interesante es que no se trata de una implementación particular de Microsoft, sino de la implementación estándar de la herramienta (la misma que utiliza GitHub).

Esta jugada de Microsoft permite que cualquier IDE que tenga soporte para Git, aunque no sea de “la familia .Net”, pueda utilizar TFS + Git como repositorio. Podemos estar desarrollando en VS Code, Android Studio o Eclipse, tanto desde Windows como desde Linux o desde una Mac, y tener nuestro código fuente (en el lenguaje que fuera) en un TFS.

En el mundo .Net no sólo usamos TFS como herramienta para gestionar el código fuente sino también para gestionar los proyectos en los cuales participamos. Tal como comentaba más arriba, TFS es una suite por lo que posee muchas otras utilidades además de TFVC y Git, por ejemplo: Reporting, Team Building, Release Management, etc.

La cuestión, desde mi punto de vista, se da en que desde hace un tiempo las metodologías de desarrollo han evolucionado y en los equipos hoy se busca ser más agiles, adoptando las nuevas tendencias. Metodologías como Scrum y Kanban hicieron que TFS tenga que salir a adaptarse para sobrevivir.

Con la llegada de DevOps y Cloud el panorama terminó de cambiar y Microsoft no perdió el tiempo. Es así que lanzó oportunamente al mercado una nueva plataforma: Visual Studio Team Services (VSTS). Esta herramienta vendría a ser como un TFS en la nube, pero con muchas más funcionalidades y el soporte continuo del equipo de Microsoft que la mantiene al día.

Más allá de no tener que instalar y mantener un TFS on premise, VSTS permite gestionar cualquier proyecto de desarrollo de SW, independientemente del lenguaje y la IDE que estemos utilizando. Permite configurar diferentes tableros, de acuerdo a si deseamos trabajar con el esquema clásico, Kanban o Scrum. Además, incluye features de CI & CD con pasos pre-configurados que permiten agilizar el despliegue de nuevas versiones de las aplicaciones que estemos construyendo con un esfuerzo mínimo. También, permite integrar todo el ciclo de vida del SW de punta a punta: desde el relevamiento y documentación de la funcionalidad a construir hasta la planificación del testing y el despliegue automático.

Es cierto, para usar VSTS profesionalmente se requiere contar con licencias para cada miembro del equipo, pero ¿cuánto nos ahorramos respecto a no tener que mantener esta infraestructura por nosotros mismos? ¿qué ventajas puedo sacar de todas las utilidades que me ofrece? ¿qué tareas me facilita o ya me provee resueltas out of the box? Estas consideraciones, entre otras, son las que debemos preguntarnos antes de optar por usarla o descartarla en nuestros proyectos.

En los últimos años hemos vivido una gran cantidad de cambios: algunos se originaron dentro de la comunidad de quienes construimos aplicaciones, otros en las nuevas tecnologías, metodologías, herramientas, procesos, etc., y otros tantos en quienes son los principales actores del mercado de SW.

Para quienes siempre trabajamos vinculados a .Net, al principio nos sorprendió el cambio de enfoque que impulsó Microsoft pero luego, con el correr de los años nos fuimos acostumbrando y hasta alegrando por las oportunidades que surgían. Ahora podemos contar con mejores herramientas y que se adaptan mejor a la forma en la que se construye SW hoy en día. También podemos desarrollar en y para la plataforma que más nos guste (Linux, Mac, Andorid, entre otras). Además podemos usar componentes open source en nuestras soluciones, guardar nuestro código en Git, etc. ¿No es acaso un panorama mucho más abierto, interesante y desafiante? Yo, al menos, creo que sí.

¿Y para quienes no trabajan directamente con .Net? Bueno, hoy cuentan con la oportunidad de poder utilizar desarrollos de Microsoft en sus proyectos, como es el caso de VSTS, TypeScript, o VS Code, entre muchos otros más. 

Es cierto, los más escépticos se siguen preguntando qué tan real o hipócrita es el cambio que viene impulsando la empresa de las ventanitas en estos últimos años. A mi entender, sólo el tiempo nos dirá si esta apuesta fue sincera y honesta, o no.

Hemos llegado ya al final de esta serie, y sólo me resta agradecerles que me hayan acompañado en la lectura y reflexión a lo largo de estos tres artículos acerca de cómo ha evolucionado el trabajo de Desarrollador .Net en los últimos años.

Mi intención está lejos de inclinar la balanza a favor o en contra de alguien; en definitiva, cada uno puede desarrollar con los lenguajes, plataformas y herramientas que más le guste. Y es ahí donde creo que al abrirse el juego de Microsoft y presentar alternativas, nos está dando la oportunidad de elegir cómo queremos hacer nuestro trabajo.

Como siempre, ¡hasta la próxima!

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

jueves, 26 de abril de 2018

Memorias de un Arquitecto .Net - Parte 2: Plataformas

¡Hola! En esta segunda entrega de la serie “Memorias de…” vamos a analizar cómo ha cambiado nuestro enfoque al construir aplicaciones .Net, pero desde el punto de vista de las plataformas hacia las cuales están dirigidos nuestros desarrollos.

Creo que todos aquellos que llevamos ya algunos años en la profesión vamos a recordar fácilmente el siguiente preconcepto: “si construimos aplicaciones .Net, es porque las vamos a desplegar en Windows”. ¿Quién hubiera imaginado en ese entonces que esto iba a cambiar rotundamente y en tan poco tiempo?

Microsoft viene modificando su forma de hacer negocios, y no hablamos sólo desde el aspecto tecnológico, sino también desde el aspecto socio-cultural interno como compañía y desde el aporte para la comunidad de desarrolladores en general.

En esa línea ha modificado la dirección de su estrategia y su sentido como organización, orientándose más hacia los servicios y no tanto hacia los commodities. En este aspecto podríamos pensar, si me permiten la analogía, que C# + Windows era un commodity, mientras que favorecer el desarrollo de aplicaciones multiplataforma construidas con el Framework .Net es un diferencial como servicio.

Es interesante detenerse a analizar algunas de estas situaciones disruptivas, y lo que esto implica para nosotros como profesionales de IT.

Por ejemplo, analicemos la postura de Microsoft con respecto a los componentes open source. Hace unos años atrás desde Redmond los veían como competencia: herramientas, lenguajes, plataformas a eliminar del mercado (quizás los más veteranos recordemos los Documentos Halloween y el impacto que tuvieron en la comunidad). Para cumplir con esto invertían tiempo y esfuerzo en desarrollar alternativas propias, las cuales luego intentaban imponer en el mercado. Con algunas les fue bien, pero con otras no tanto. 

En cambio, hoy en día pareciera que Microsoft está abrazando a las iniciativas de código abierto. No sólo las respeta, sino que también las protege y hasta las apadrina, como es el caso de TypeScript, o el hecho de haber desarrollado Visual Studio Code, PowerShell y el motor JavaScript del browser Edge bajo la filosofía Open Source.

Y, como si esto fuera poco, para reforzar esta comunión, recientemente se ha unido a la Open Source Initiative (OSI) como Premium Sponsor de la que ya formaban parte Facebook, GitHub, Google, HP, IBM, entre otras grandes empresas del mercado tecnológico.

Otro de los cambios de paradigmas que no podemos dejar pasar es la visión respecto el sistema operativo Linux. La mayoría recordarán las desafortunadas palabras del CEO Steve Ballmer allá por junio de 2001, cuando se refirió a este sistema operativo y al software open source en general, como un cáncer. Afortunadamente, parecen haber quedado atrás y actualmente Microsoft ha cambiado su postura.

“Microsoft ♥ Linux” es un slogan que hoy por hoy resuena bastante en internet, pero a su vez es una movida desde donde se vienen articulando una serie de iniciativas que intentan acercar ambos mundos. Por ejemplo, podemos mencionar la posibilidad de elegir a Linux como SO en los servidores de Azure, el hecho de que Microsoft se haya unido a la Linux Foundation en 2016, la factibilidad de contar con SQL Server en Linux o la capacidad de instalar Linux como subsistema en Windows 10, entre otros.

¿Y qué pasa con Mac? En línea con lo anterior, Microsoft viene realizando esfuerzos para poder integrarse con este otro sistema operativo. Un claro ejemplo de esto es el lanzamiento oficial de Visual Studio for Mac a comienzos del 2017.

Finalmente, otra de las evoluciones que se han dado viene del lado de las plataformas mobile. Es ampliamente sabido que Microsoft realizó intentos tardíos y fallidos para poder subirse a la ola de los sistemas operativos para los dispositivos móviles, especialmente haciendo foco en los smartphones.

Luego de un último intento con Windows Phone, el cual parece haber sido abandonado finalmente por Microsoft, los esfuerzos de la compañía se están direccionado hacia una alternativa: salir a ofrecer la posibilidad de desarrollar aplicaciones nativas para iOS y Android a través de Xamarin utilizando C# como lenguaje de desarrollo.

Xamarin es una empresa fundada por Miguel de Icaza (sí, el mismo que creo Mono en 2001) y Nat Friedman (cofundador de Ximian en 1999 junto a Miguel), que fue adquirida por Microsoft en 2016 y donde desde entonces viene invirtiendo recursos para potenciar la plataforma e integrarla con Visual Studio, tanto en Windows como en Mac, para que se transforme en una alternativa viable para la construcción de aplicaciones móviles multiplataforma.

Creo entonces, desde mi humilde opinión, que tenemos que terminar de sacarnos el chip de que .Net es Windows y de que Microsoft es la misma empresa de los 90’s.

Hoy en día contamos con diversas plataformas sobre las cuales podemos implementar nuestros desarrollos. Y si bien es verdad que en algunas tendremos ciertas restricciones, la realidad es que la brecha continúa achicándose más y más. Sólo a modo de ejemplo, quiero citar algunos escenarios que nos ayudarán a tomar conciencia de las posibilidades con las que contamos actualmente al pensar en una solución técnica:

  • Si debemos construir una aplicación web, tengamos en cuenta que no necesariamente luego la vamos a correr en IIS. Quizás queramos ejecutarla en Linux a través de Apache utilizando el mod_mono. ¿O por qué no en Nginx o XSP?
  • ¿Y si la misma aplicación web la desarrollamos con .Net Core? Bueno, ahí podremos desplegarla además en Kestrel o a través de Apache con un Reverse Proxy a Kestrel.
  • Si necesitamos desarrollar una aplicación mobile nativa para iOS y Android, seguramente se nos venga a nuestras mentes el poder utilizar Xamarin, o Xamarin.Forms. Lo interesante es que vamos a estar desarrollando con C# una aplicación que luego se va a compilar nativamente y correr en ambas plataformas, tan distintas de Windows.
  • ¿Y si mi cliente tiene toda su infraestructura en Linux? No hay ningún problema, con .Net Core podemos resolver el desarrollo de la aplicación propiamente dicha y con SQL Server 2017 podemos desplegar la base de datos en dicha plataforma.
  • Tengo una Mac y quiero desarrollar una aplicación en .Net. ¿Por qué no le damos la chance a Visual Studio for Mac y vemos qué tiene para ofrecernos?
  • Trabajo con otros lenguajes que no son propiamente del mundo .Net ¿me puede ser útil Visual Studio Code? Bueno, la respuesta depende mucho de los gustos de cada desarrollador, pero me parece interesante mencionar que esta IDE brinda soporte para desarrollar, además de en los lenguajes de la familia .Net y web, en lenguajes como TypeScript, Node.JS, PHP, Phyton, PowerShell, Ruby, Java, Docker, Angular, Arduino, entre tantos otros.


Puedo continuar con la lista de ejemplos, pero quisiera que evalúen ustedes también qué otras posibilidades tenemos hoy por hoy. Y también a qué responsabilidades nos conllevan nuestras decisiones: el impacto de cómo diseñamos una arquitectura.

Si hoy encaramos un nuevo desarrollo, las opciones con las que contamos son de las más variadas. No sólo tendremos que elegir un lenguaje de desarrollo (para ser más precisos, en el mejor de los casos sólo debamos trabajar con 4 a 5 lenguajes distintos), sino que también podremos tener en cuenta la plataforma y el IDE que más se acerque a nuestras necesidades (o por qué no, a nuestro estilo).

Una vez definidos estos primeros puntos, recién pasaremos a poder seleccionar e integrar cerca de una docena de bibliotecas, de las cuales seguramente la mayoría de ellas sean open source, para dotar a nuestra nueva aplicación de funcionalidad estándar y validada por la comunidad.

¡Y finalmente estaremos en condiciones de empezar a escribir código!
Bien, hasta acá hemos compartido qué cambios se dieron en el último tiempo desde dos puntos de vista: Lenguajes y Plataformas. Nos queda un punto más para debatir, Herramientas, el cual será el tema principal del siguiente y último artículo de esta serie.

¡Hasta la próxima!

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

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