viernes, 22 de junio de 2018

Testing en el Internet de las cosas

Fuente: https://www.itsitio.com/us/seguridad-camaras-ip-segun-av-test/

¿Qué es Internet de las cosas?

Cada vez se habla más de internet de las cosas (Internet of things - IoT), pero ¿qué significa realmente? Básicamente, es un concepto que se refiere a la digitalización de los objetos cotidianos, la manera en la que se comunican con nosotros, entre ellos mismos y por supuesto con internet. 

Un ejemplo sencillo de esto es que, al sonar el despertador, se encienda la cafetera y empiece a preparar el café al comenzar la mañana. 

En este contexto, se calcula que para el 2020 entre 22 mil y 50 mil millones de dispositivos estarán preparados para conectarse a internet. Sin embargo, como un punto negativo, podemos mencionar las vulnerabilidades a las que estamos expuestos en este nuevo mundo. 

Estos dispositivos, no ofrecen gran seguridad y pueden ser de fácil acceso para alguien mal intencionado. En 2014, un estudio de HP estimó que el 70% de los dispositivos de IoT son vulnerables a ataques.

¿Cómo se testean estos dispositivos?

IoT plantea nuevos desafíos a los desarrolladores y testers de software, ya que debemos ampliar nuestras habilidades para lanzar software de calidad.

Además, implica grandes innovaciones en términos de requisitos de prueba, incluyendo un mayor énfasis en tipos de dispositivos inusuales, tales como electrodomésticos, interfaces de termostato y sensores de reloj.

Con un conjunto diverso de productos que ingresan al mercado de IoT, los equipos de QA deben diseñar cuidadosamente la mejor estrategia de administración de pruebas para cumplir con los estándares de calidad de estos productos. 

Veamos entonces qué puede deparar el futuro de las pruebas IoT para los equipos de prueba de software:

La importancia de probar escenarios de conectividad inalámbrica

La conectividad depende de muchos estándares inalámbricos diferentes. Por ejemplo, Wi-Fi, Bluetooth, ZigBee y/o 4G LTE. 

Para los desarrolladores de software, los potenciales problemas con la conectividad y la infraestructura, inevitablemente darán forma al diseño de sus aplicaciones. Las pruebas de software deberán cubrir bases como:

¿Qué sucede con los datos cuándo se cae una conexión inesperadamente?
¿Se guardan y se almacenan correctamente?
¿Dónde se recuperará una vez que se restaure el servicio?

 Para verificar esto, serán esenciales muchas pruebas en el mundo real.


Fuente: https://sistemasumma.com/

Virtualización de servicios para la simulación de hogares inteligentes

Uno de los casos de uso de IoT más promocionados es la domótica (conjunto de técnicas orientadas a automatizar una vivienda, que integran la tecnología en los sistemas de seguridad, gestión energética, bienestar o comunicaciones). Para los testers, sin embargo, esta práctica puede ser un entorno difícil y desconocido de simular. Por ello, deberemos tener en cuenta ciertos aspectos:

Compatibilidad: ¿Qué otros dispositivos están presentes?
Cobertura: ¿Cuál es el diseño de la casa? 
Conectividad: ¿Qué sucede en condiciones de baja conectividad? 
Ambiental: ¿Cómo afectan las condiciones climáticas a los dispositivos? 

La virtualización de servicios ofrece un posible camino a seguir. Los equipos de desarrollo/prueba pueden modelar muchos tipos diferentes de casas, sensores y estados del dispositivo. Asimismo Los testers pueden tener una buena idea de las condiciones que enfrentarán sus servicios en el mundo real.


Doblando la seguridad en el IoT

Asegurar la privacidad de datos en IoT es crucial. Las autorizaciones son apoyos importantes para asegurar transferencias y transmisión de datos de IoT. Por ejemplo, para evitar la vulnerabilidad de los datos, el puerto del dispositivo IoT se cierra a la comunicación de Internet cuando no está en uso. Además, el cifrado de extremo a extremo entre dispositivos o dispositivos y servidores codifica de forma segura las transferencias de datos.

Los equipos de QA deben investigar una amplia gama de posibles vulnerabilidades en los productos y servicios de IoT. Dependiendo del elemento en cuestión, podría tratarse de:

Aplicar estrictas reglas de contraseña
Proteger la interfaz de acceso no autorizado
Garantizar el uso del cifrado cuando corresponda

¿Qué sigue?

El reto actual es aumentar el alcance de las pruebas IoT. Las pruebas automatizadas son cruciales para diseñar, planificar e implementarse en IoT.

Los entornos en tiempo real en los que los dispositivos IoT deben operar los expone al clima, los elementos y el impacto físico. En consecuencia, los equipos de control de calidad deben evaluar toda la gama de vulnerabilidades ambientales y funcionales de la IoT, incluida la medida en que la exposición afecta las funcionalidades. 

Al observar el ataque innovador de Internet de las cosas, uno ve el avance de la tecnología hacia la movilidad y la diversidad. Con la integración y la automatización de pruebas, los equipos de QA ya están bien preparados para diseñar procedimientos de prueba que garantizarán una mayor expansión de la tecnología IoT.

Referencias:
https://hipertextual.com/2015/06/internet-of-things
https://testingbaires.com/debemos-pensar-en-armar-estrategias-de-prueba-para-iot/
https://www.getzephyr.com/insights/future-iot-testing

Links útiles:
https://riunet.upv.es/bitstream/handle/10251/71683/MART%C3%8DNEZ%20-%20TESTAR%20para%20testing%20IoT.pdf?sequence=2


¿Sos desarrollador?
https://bbvaopen4u.com/es/actualidad/en-que-lenguaje-se-programara-el-internet-de-las-cosas

Autor: 
Santiago Sosa Montiel.
Tester QA.

viernes, 15 de junio de 2018

Docker y sus contenedores: una nueva forma de desplegar tus ambientes

"¡En mi máquina funciona, en el cliente no!  #!$#%&##"

¿Cuántas veces nos ha pasado de desarrollar un sistema, probarlo y ver que funciona, pero al momento de desplegarlo, todo se rompe? ¿Qué hacemos? ¿Redesplegamos? ¿Debugeamos? 

En el presente artículo se describe una herramienta que ayuda a evitar este incómodo momento que ha sufrido alguna vez todo desarrollador. 

A continuación, presentamos una introducción al uso de contenedores, sus ventajas y desventajas y algunos comandos simples para probar.

¿Qué es un contenedor?

Los contenedores de software son un conjunto de elementos que permiten ejecutar una aplicación determinada en cualquier sistema operativo, permitiendo garantizar que una aplicación se ejecute correctamente cuando cambie su entorno. 

La idea general es, que al desarrollar un sistema en un entorno específico se puede ejecutar en otros entornos con características diferentes, sin tener que cambiar frameworks o configuraciones. 

Debido a su utilidad y agilidad para migrar cualquier desarrollo de una plataforma a otra, el uso de los contenedores de software ha crecido en los últimos años.

Contenedor VS Máquina Virtual



Dado que cada herramienta tiene sus propias ventajas y desventajas, es común preguntarse cuál de estas opciones es conveniente usar y la respuesta es que dependerá de lo que uno quiera lograr. Si se quieren correr diferentes tipos de aplicaciones que insuman varios y distintos recursos, probablemente se elegirá la opción de una VM. En cambio, si la idea es ejecutar varias copias de la misma aplicación, tal vez lo mejor sea un contenedor. También se puede recurrir a una solución que use tanto VM como contenedores y, de esta manera, aprovechar las ventajas de ambas herramientas. El desafío en este caso consistirá en cómo manejar/administrar ambas arquitecturas al mismo tiempo. 

¿Qué es Docker?

Docker es un proyecto de código abierto que automatiza el despliegue de aplicaciones dentro de contenedores de software, proporcionando una capa adicional de abstracción y automatización de virtualización a nivel de sistema operativo. 

Con esta herramienta se puede empaquetar una aplicación y sus dependencias en un contenedor virtual, que puede ejecutarse en cualquier servidor. Asimismo, permite la flexibilidad y portabilidad en dónde la aplicación se puede ejecutar, ya sea en las instalaciones físicas, en la nube pública, en la nube privada, etc. 

Docker utiliza características de aislamiento de recursos del kernel, tales como cgroups y namespaces, para permitir que "contenedores" independientes se ejecuten dentro de una sola instancia, evitando la sobrecarga de iniciar y mantener máquinas virtuales. 

El soporte del kernel de Linux para los espacios de nombres, aísla la vista que tiene una aplicación de su entorno operativo, incluyendo árboles de proceso, red, ID de usuario y sistemas de archivos montados. Por su parte, los cgroups del kernel proporcionan aislamiento de recursos, incluyendo la CPU, la memoria, el bloque de E / S y de la red. 

En la versión 0.9, Docker incluye la biblioteca libcontainer como su propia manera de utilizar directamente las facilidades de virtualización que ofrece el kernel de Linux, además de utilizar las interfaces abstraídas de virtualización.

Comandería básica Docker

Para listar nuestros contenedores activos utilizamos el comando:

docker ps 
Para crear un contenedor se usa el comando: 
docker run -it imagen(se puede poner el -it para que corra de modo iterativo)
Para ver los contenedores creados, pero que no se están ejecutando, usamos el comando:
docker ps -a
Para que se ejecute nuestro contenedor ya creado: 
docker start <id>
Para eliminar el contenedor hay que detenerlo con el comando stop:
docker stop <id>
Luego podremos borrarlo con el comando: 
docker rm <nombre_contenedor>
Se puede borrar en ejecución si se usa el flag f:
docker rm <nombre_contenedor> -f 

Otros comandos de Docker son:


Links útiles:
https://docs.docker.com/get-started/
https://www.codeschool.com/courses/try-docker

Autores:
Javier Horacio Campa - Desarrollador .NET
Gregorio Michalopulos - Desarrollador .NET
José María Virgili - Desarrollador .NET

miércoles, 13 de junio de 2018

Breves enseñanzas de la vida cotidiana

Este artículo presenta una serie de anécdotas de la vida personal, fuera del aspecto laboral, que sirven para ejemplificar la sinergia entre lo cotidiano y el desarrollo de software, o cómo podemos generar sinergia entre dos aspectos tan diferentes de nuestras experiencias.

La herramienta correcta

Mi hijo mayor tenía un año cuando, al ver el precio de los bloques de madera, decidí hacerle yo mismo un juego de bloques.

Vivía a una cuadra y media del Easy de Caballito, una gran tienda de artículos para el hogar, así que compré unos cuantos listones de madera de pino (hay que buscar los más rectos, porque suelen estar bastante torcidos) y unas varillas de 1 cm.

Ese fin de semana hice las cuentas: 20 rectángulos de 5x10 y 30 cuadrados de 5X5. Los rectángulos tendrían dos agujeros para pasar las varillas y los cuadrados uno solo. Entonces me puse a trabajar con la sierra caladora. Hice los cortes en media hora y la cosa venía bien. Continué con los agujeros, cargué una mecha de 1cm (que decía en el empaque que era para acero y madera) en el taladro eléctrico y arranqué. 

Hacer el primer agujero en el pino de 2.5 cm me llevó casi una hora. Estaba exhausto, me dolía la espalda y traspiraba, no paraba de repetirme “Por dios, son 70 agujeros, a este paso le compro los bloques y me dejo de molestar…” (digamos que la frase fue un poco más vehemente).

Mientras almorzaba ese día, pensaba: “no es razonable, no puede ser que hacer un agujerito en madera me lleve tanto, hay algo mal… ¿no será que la mecha no es la adecuada?”.

Busqué en internet y efectivamente las mechas solo para madera son bastante distintas, veámoslas:
   
Madera, punta de tres picos y acanalado grueso

Acero, punta sin pico y acanalado suave
Volví a Easy y me compré la mecha para madera y nuevamente me puse manos a la obra. En la próxima hora y un poco más pude hacer todos los agujeros que faltaban.

Cuando una tarea es tediosamente larga o insufrible (digamos ni eficiente ni eficaz), lo más factible es que se esté usando la herramienta inadecuada y que, la herramienta correcta, seguramente esté al alcance de nuestras manos. 

La mandíbula de tiburón

Contrariamente a lo que se cree, el nombre en inglés de la conocida película Tiburón(1975), no es “Shark” sino “Jaws”, un ejemplo más (y un ejemplo grosero) de eso tan odioso para los no iniciados que es el cambio de nombre de las películas por parte de los distribuidores. Incluso una vez dicho esto, el nombre en español pareciera tener más sentido.





La verdad es que jaws se traduce mejor como quijada, ya que en inglés existe la palabra mandible con el mismo significado y etimología que mandíbula. Si bien quijada y mandíbula son prácticamente sinónimos, en el uso cotidiano se reserva el nombre de quijada para los animales de granja (caballo, reses, cerdos, etc.) dejando mandíbula como nombre más formal, casi médico. La palabra técnica es maxilar. Otros han propuesto fauces como traducción, pero esto se refiere al fondo de la boca y no es sinónimo de las anteriores, lo cual en mi opinión es incorrecto.

Entonces acá tenemos el primer problema, los distribuidores no podían usar quijada porque se usa en otro contexto, pero ¿por qué no usaron “Mandíbulas” o “Maxilar” o “Fauces”?  En realidad, ninguna tiene el gancho suficiente como nombre para una película de terror/suspenso.

Volviendo al principio, sobre los no iniciados: son varias las veces que escuché tararear la tonada de la película y luego acotar “Shark, ¡que peli!”. Con semejante declaración entendía que esas personas jamás la habían visto en su idioma original, jamás habían visto un cartel ni nada y que solo fingían al usar palabras en inglés.

¿Y por qué digo que es odioso para los no iniciados? Y obviamente que yo lo fui. Porque la traducción literal es la más fácil, la más rápida. Los nombres de las películas no solo no necesitan decir lo mismo, sino que necesitan transmitir el mismo mensaje, aún a costa de decir algo que apenas se parece o incluso decir otra cosa.

Hablar de un dominio con honestidad intelectual, debería implicar un mínimo de estudio, de relevamiento, de cotejar diversas fuentes y de ir a las fuentes de las fuentes y por supuesto, mucho análisis. 
Un CD con contenido multimedia

Había comprado una amoladora eléctrica para hacer algunos arreglos en un departamento recién comprado.  Fui al mismo negocio de siempre y compré un modelo acorde a mis necesidades y presupuesto (mas de ocho años después aún lo uso, así que fue una buena compra).

Contento como niño con regalo nuevo, desempaco y reviso el contenido. Dejé el manual para el final y empecé acomodando las partes en el piso: la amoladora, la llave ajustadora, un sobre blanco con un cd con contenido multimedia, “¡Qué interesante! Lo veo luego” dije en voz alta, a sabiendas que nunca lo vería. Finalmente tomé el manual, lo abrí en su primera página “Partes” y lo repasé con ellas dispersas por el piso.

“Pero ¿dónde están los discos? Miserables, no vinieron los discos, ahora tengo que volver para reclamar…” En eso veo nuevamente el sobre blanco: por supuesto, los dos discos, ¿qué va a tener este sobre, acaso un cd con contenido multimedia? ¿A quién se le ocurriría incluir un cd con contenido multimedia que nadie vería? , hay que estar loco.

Hay una forma natural de abordar los problemas, obviamente debemos empezar siempre por el principio y buscarlo y mantenernos firmes en la naturaleza de los problemas. Es fácil divagar y perdernos, dejarnos llevar por nuestros propios afectos e intereses, o fetiches tecnológicos. La solución a problemas técnicos no necesariamente es más tecnología.

La construcción de mi casa

Hace poco tiempo compré un terreno e hice mi casa, con aportes míos y préstamos familiares. Tengo el enorme orgullo de poder decir que tuvo apenas un 6% de desvío de presupuesto y solo dos meses fuera del plan, que para los que conocen los guarismos de la construcción, sabrán que esto es un logro extraordinario.

La verdad que hablar de este tema podría llevarme infinito, o como mínimo saldría del espíritu de brevedad que ilustran estas anécdotas. Así que decidí enfocarme en un solo punto: algo que haría distinto…

Uno está acostumbrado a hacer de “contratista”. Nos pagan por hacer una tarea y es otro el que finalmente termina utilizando (quisiera decir disfrutando, pero dejémoslo ahí) nuestra labor. La cuestión es que cuando es el cliente, el tiempo vuela y el presupuesto se evapora. La gestión fue buena y el equipo cumplió, no hubo problema de integración con otros especialistas (que hay muchísimos) y como dije ut supra, se terminó en tiempo y forma.

Resulta que la construcción húmeda (ladrillos, cemento y yeso) tiene sus tiempos de fraguado (secado y endurecimiento). Es absolutamente normal que durante un tiempo inicial aparezcan leves grietas en puertas y ventanas; incluso si el terreno es virgen, hay un periodo de asentamiento por el peso de la obra. Lo habitual en construcción (con los tiempos que se extienden) es que se permitan buenos fraguados y que, cuando se pinta, con el enduido se cubran sin problemas estas rajaduras.

Debo confesar que cumplir el plan fue mí objetivo absoluto y, aunque lo logré, ahora sé que si hubiese respetado los tiempos de los materiales hubiese tenido un resultado mejor.  El proveedor forzó sus capacidades técnicas para cumplir con mi necesidades de negocio…

¡Que novedad! Como cliente descubrí que sí, efectivamente “Good cooking takes time”.

Conclusiones 

Estas anécdotas fueron elegidas por un motivo, ilustran aprendizajes de mi vida que luego apliqué a disciplinas concretas de la Ingeniería de Software. 

“La herramienta correcta”, lo aplique en muchas actividades ligadas al desarrollo, estimando primero el esfuerzo de la tarea y valorizándolo contra el objetivo. Y más de una vez cambié de herramienta cuando se evidenciaba que a ese paso íbamos a quemar medio proyecto, o si no había otras opciones, dejándome guiar por el costo-beneficio.

“La mandíbula del tiburón”, es un ejemplo de lo que un buen análisis funcional puede lograr, puede parecer una verdad de perogrullo, pero la gente de sistemas no tiene especialidad en los negocios sobre los que construimos software, y por eso, debemos dar un esfuerzo adicional en investigar los temas del dominio que queremos abordar.

“Un CD con contenido multimedia”, habla del diseño natural que deben tener los desarrollos y como las distintas partes de una solución deben estar naturalmente integradas.

“La construcción de mi casa”, es un ejemplo de gestión de proyectos, de cómo visualicé a todos los miembros como parte de un mismo equipo con un objetivo común con sus roles y especialidades, buscando en todo momento el éxito del proyecto, con planificación, gestión de riesgos, seguimiento y tablero de control. Pero al final del día, el detalle está en los temas técnicos. 

Autor: 
Santiago Seijas Cao
.NET Technical Expert

viernes, 8 de junio de 2018

Mi experiencia con realidad aumentada, de la mano de HoloLens

Hace poco tuve la posibilidad de dialogar con un participante de Net Conf AR 2017, una conferencia internacional organizada por Microsoft en donde los principales partners del país anfitrión presentan las distintas tecnologías y productos de dicha empresa.

De las diferentes disertaciones que se brindaron, una de las que más me llamó la atención fue la de realidad aumentada de Microsoft, basada en el producto HoloLens. Durante la jornada, se llevó a cabo una pequeña demostración donde se aplicó dicha tecnología en un juego desarrollado bajo la plataforma Unity3D, en el cual surgían arañas en el mismo ambiente en el que se encontraban los participantes y debían ser eliminadas con un insecticida. 

A grandes rasgos, los principales pasos para realizar la demo fueron, en principio, realizar un mapeo del ambiente teniendo en cuenta profundidad, alto y distancia de los distintos objetos del lugar, todo esto realizado con la herramienta de HoloLens. Luego, en la plataforma de desarrollo, se agregaron diversos obstáculos, algunos enemigos (las arañas) y nuestro elemento de defensa (el insecticida).

Terminado el desarrollo del videojuego, el cual se hizo de una manera sorprendentemente rápida y ágil, demostrando la madurez de la plataforma y la facilidad con la cual hoy en día se pueden desarrollar este tipo de juegos y aplicaciones en general; se procedió a realizar el deploy del mismo en los HoloLens y… comenzó el juego.

Algo que ha captado mi curiosidad en este relato fue el término “mixed reality”. Pero, ¿de qué se trata este concepto que está tan de moda? La realidad mixta es la mezcla entre el mundo real y el mundo digital, es decir, entre la realidad virtual y la realidad física, permitiendo la interacción entre elementos de estos dos universos. La realidad mixta se diferencia de la realidad aumentada ya que esta última genera los estímulos a tiempo real para la interacción del usuario, los cuales se superponen sobre el entorno físico de este. Por su parte, la realidad mixta no sólo permite la interacción del usuario con el entorno virtual sino que también permite que objetos físicos del entorno inmediato del usuario sirvan como elementos de interacción con el entorno virtual. (1)

Más allá de su utilidad en el ámbito lúdico, esta tecnología tiene hoy por hoy grandes chances de aplicación en otros rubros más cercanos a nuestra realidad, como por ejemplo:

  • En la ingeniería y la arquitectura, facilitando el diseño de infraestructuras, hogar y decoración.
  • En el campo de la medicina, para aplicarlo de forma pedagógica y práctica.
  • Y, ¿por qué no también? en el campo del marketing.

A modo de conclusión, y desde un punto de vista más personal, puedo decir que esta tecnología posee una gran versatilidad y utilidad en diferentes aspectos de la vida, tanto laboral como personal. Me arriesgo a decir que el futuro del desarrollo apunta a esto y nos acerca más a un futuro que hasta hace poco era solamente imaginado. 

Referencias:



Autor: 
Iván E. Pighin.
Dev .NET

jueves, 7 de junio de 2018

TypeScript: ¿Cómo escribir código front-end sin arrancarse los pelos?

Todos los que trabajamos desde hace ya varios años en el desarrollo de back-ends, estamos acostumbrados a desarrollar en .NET disfrutando las bondades de un lenguaje orientado a objetos y tipado como es C#. Nos esforzamos por hacer código prolijo, mantenible, modularizable y altamente testeable, por lo cual nuestra aplicación de back-end es performante, robusta y escalable. Sin embargo, ahora nos enfrentamos a un nuevo desafío: nos toca, además, desarrollar código de front-end. 

Hoy en día el mercado le da mucho valor a aquellos que llamaremos Full Stack Developers y, si queremos convertirnos en tales, debemos aprender otras tecnologías y lenguajes como HTML, JavaScript, NodeJs, entre otros. Entonces, ¿qué pasa con todas esas cualidades a las que estamos acostumbrados cuando cambiamos C# por JavaScript?

En C# solemos usar tipos de datos tales como string, int y bool. Si declaramos una variable, sabemos que la misma siempre contendrá un dato de ese tipo. Instanciamos objetos que comparten atributos y comportamientos; declaramos clases que nos definen cómo construir cada uno de esos objetos; usamos interfaces para definir un contrato a implementar; tenemos conceptos como la herencia y la composición para vincular los objetos; podemos definir fácilmente si algo es público o privado y ordenar nuestras implementaciones en namespaces.

Cuando empezamos a programar en JavaScript, asignamos un número entero a una variable. Unas líneas de código más tarde, le asignamos por error un string. Nada nos alerta de ningún problema y nuestro código llega a la aplicación funcionando, pero al presionar el botón, nada sucede. Sorprendidos, miramos la consola del browser y encontramos unas intimidantes letras rojas: “NaN”. El código quiso realizar una operación con el string esperando que fuera un número.

Una vez que encontramos la asignación errónea y la arreglamos, seguimos adelante. Escribimos una función que recibe dos parámetros (por ejemplo: “unaFuncion(a, b)”) y la olvidamos varias líneas después. Llamamos a la función olvidada y le pasamos un argumento (“unaFuncion(a)”). Guardamos el progreso, vamos a la aplicación web y aparece la frase “b is not defined”. Esto se debe a que en JavaScript, una función puede ser llamada con cualquier cantidad de argumentos. Si tiene de más, usa los que necesita, y, si se le pasan menos, toma el resto como undefined.

Luego creamos una “clase” (en realidad, JavaScript no conoce el concepto de clase) mediante una función, más o menos así:

function Objeto(argumento1, argumento2){

propiedad1 = argumento1;
propiedad2 = argumento2;

funcion1 = function(){
        return argumento1 + argumento2;
    }
}

También creamos dos objetos con esta clase. Uno haciendo Objeto (1,2) y el otro haciendo Objeto (3,4). De esta forma, cuando ejecutemos nuestro código y evaluemos al primer objeto, descubriremos que su objeto.Metodo1() devuelve 7 (3 + 4), no 3. ¿Qué ocurrió?  

Las propiedades de los objetos fueron creadas en lo que se llama el scope global. Allí, son accesibles desde cualquier función o código que esté corriendo en la página web. Es decir, ambos objetos estaban apuntando a las mismas variables. Y no sólo eso, sino que cualquier otro objeto puede llamar a la función “Funcion1”. En JavaScript, una función puede acceder sólo a las funciones y variables que estén declaradas en sí mismas, las funciones que la engloban, o el scope global.

Modificamos la función Objeto, agregamos var delante de cada propiedad y función para hacerlas privadas y volvemos a ejecutar el código. En este momento nos aparece un mensaje diciendo “objeto.Funcion1 is not defined”. Ahora la función “Funcion1” no es visible hacia afuera. Esto lo podemos arreglar escribiendo “this.” delante de la misma. 

Una función no puede acceder al scope de otra declarada dentro, salvo que tenga una referencia a la otra función y que la propiedad o función a la que queremos acceder esté declarada como “this.funcion”.

Supongamos que queremos aplicar herencia de un objeto a otro. Primero tenemos que crear la “clase” padre en una expresión de función Inmediatamente Invocada (IIFE en inglés) en el scope global:

var Vehiculo = (function()
{
    function Vehiculo (año, modelo, fabricante)
    {
        this.modelo = modelo;
        this.Año = año;
        this.fabricante = fabricante;
    };
    Vehiculo.prototype.retornarInfo() = function()
    {
        return this.año + ' ' + this.fabricante + ' ' + this.modelo;
    };
    return Vehiculo;
})()

Para implementar la clase hija, agregándole propiedades y funciones propias, debemos hacer lo siguiente:

var Auto = (function (padre)
{
    Auto.prototype = new Vehiculo();
    Auto.prototype.constructor = Auto;
    function Auto (año, modelo, fabricante)
    {
        parent.call(this, año, modelo, fabricante);
        this.cantidadDeRuedas = 4;
    };
    Auto.prototype.retornarInfo = function ()
    {
        return 'Tipo de Vehiculo: Auto ' + parent.prototype.retornarInfo.call(this);
    }
    return Auto;
})(Vehiculo)

TypeScript surge para solucionar estos inconvenientes, y otros tantos más que no hemos enumerado.

TypeScript es un lenguaje tipado, es decir, podemos decirle a una variable, o a los parámetros de una función, que deben aceptar un solo tipo de dato. Hacer esto es tan fácil como:

function helloWorld(persona : string)
{
    return "Hello " + (persona || "world") + "!";
}

También es un lenguaje que hay que compilar antes de usar. Esto nos facilitará la tarea de encontrar variables mal asignadas en tiempo de compilación, antes de poner el código a funcionar en la página o aplicación. Además, nos avisa cuando una función es llamada con un número de argumentos distinto al original.

En TypeScript sí se pueden crear clases e interfaces. Esto nos brinda un grado de abstracción mayor y el poder implementar herencia o composición de una forma mucho más cómoda.

Las interfaces se implementan así:

interface Persona 
{
    Nombre : string;
    Apellido : string;
}

De ahí podemos llamar a la interface “Persona” en una función así:

function nombrePersona (persona : Persona)
{
    return persona.Nombre;
}

Y crear las clases de esta forma:

class Persona
{
    Nombre : string;
    Apellido : string;
    constructor (unNombre : string, unApellido : string)
    {
        this.Nombre = unNombre;
        this.Apellido = unApellido;
    }

    retornarNombre()
    {
        return Nombre + '' + Apellido;
    }
};

TypeScript tiene los modificadores public, private y protected, que en esta clase no fueron usados. El lenguaje interpretará las funciones y propiedades como públicas por defecto.

Para implementar una interfaz sobre una clase, simplemente debemos escribir:

class Estudiante implements Persona
{
    ...
}

Y para implementar herencia:

class Estudiante extends Persona
{
    retornarNombre()
    {
        super.retornarNombre() + " el estudiante";
    }
}

Con estos ejemplos podemos notar que TypeScript hace menos engorroso el programar en front-end, brindándonos herramientas que ya conocemos para hacerlo. Si sólo desarrollamos en back-end, este lenguaje hace que nuestros primeros pasos para convertirnos en desarrolladores full-stack sean mucho menos amargos.

Autor:
Tec. Daniel Panelo
.NET Developer

miércoles, 30 de mayo de 2018

Estudiante de sistemas en busca su primer trabajo: qué esperar, experiencia y conclusiones

La realidad es que la gran mayoría de los estudiantes de sistemas comienzan a trabajar antes de recibirse. Esto sucede por una obvia razón económica, pero también para empezar a aplicar y perfeccionarse en los conceptos y prácticas que se van adquiriendo con el estudio de una manera más teórica o alejada de la realidad.

Al encontrarme yo ante esta situación se me generaron ciertas dudas: ¿qué lleva a un estudiante de sistemas a decidir en dónde va a iniciar su carrera laboral? ¿Qué cosas son las que tenemos que tener en cuenta?

Cuando llega el momento de elegir dónde realizar las tareas, hay una oferta enorme tanto en rubros como en modalidades. Es decir, ejercer algún cargo en el área de sistemas es algo bastante amplio: podés ser desarrollador, analista o tester, o trabajar en soporte, en BI o en infraestructura.

En mi caso, me gusta mucho el lugar de trabajo y el rol en el que empecé, pero tengo amigos que comenzaron hace dos meses como yo en otros lugares y ya están pensando cómo irse. Entonces, ¿cómo podemos asegurarnos que nuestra elección es la mejor para nosotros?

Lo primero es estar seguro de lo que uno quiere hacer. Cuando se tiene experiencia, tal vez sea más fácil saber en qué tecnología uno se quiere desempeñar, incluso siendo estudiante uno conoce qué es lo que se le da con mayor facilidad. Pero no hay que buscar lo más cómodo, si el fin es un buen sueldo. Hay oportunidades, pero la realidad es que, si no se encuentra un cierto nivel de conformidad y satisfacción con lo que uno hace, ¿cuánto se puede durar, o qué tan feliz te puede hacer ese sueldo?

Un consejo para nuestra generación, que se caracteriza por su rapidez -y lo pienso como algo bueno- es no dejarse caer en el frenesí de decir que sí a cualquier cosa, como por ejemplo, una capacitación en una tecnología nueva y muy demandada. Es cierto, hay empresas muy buenas que las dan, pero también compañías que buscan personas con ciertas habilidades para intentar retenerlas sin posibilidad de crecimiento a futuro. 

Actualmente estamos acostumbrados a aprender de internet y hay muy pocas cosas relacionadas con una tecnología nueva y popular que no se puedan adquirir por ese medio. Si la empresa no pareciera comprometida con lo que va a venir después, o los que son designados como encargados en las capacitaciones no tienen las herramientas o saberes necesarios para dejarte satisfecho, muestra que la compañía no está realmente interesada en el desarrollo a largo plazo de sus empleados.

Hay que tener en cuenta entonces que, por un lado, la empresa tiene que ser clara con sus expectativas, sus beneficios, las tareas del rol que se busca, el salario, pero, a su vez, quién empieza su primer trabajo debe ser claro y expresarle al responsable de la empresa cuáles son sus expectativas, sus anhelos, sus objetivos, sus miedos, qué desafíos espera y cuáles son sus necesidades. Ese sinceramiento mutuo es el primer paso para construir una relación a largo plazo en donde, tanto la persona como el empleador, puedan ganar al trabajar juntos. Es decir, la seriedad de la empresa y las expectativas de uno son lo que determinan los parámetros para tomar la mejor decisión posible.

Con el ambiente de elección acotado por el tipo de función que uno va a querer realizar, hay que estar atentos a que el empleador cumpla con las condiciones que uno presenta. Es importante hacer una averiguación del qué, el cómo y el porqué del lugar al que se va a ir. Debemos ser más conscientes de lo que implica entrar a trabajar a una empresa y en un proyecto que va a tener sus particularidades: desde el equipo de trabajo hasta como se van a utilizar la tecnología y las metodologías. 

Debemos identificar qué es lo que esperamos de la incorporación al proyecto y analizar a costa de qué conseguiremos un mejor salario. ¿Es suficiente un trabajo en el que no haya mucho espacio para el crecimiento si paga bien? 

Un lugar que esté dispuesto a acompañarte y dejarte crecer dentro de un proyecto desafiante es lo que yo encontré en Baufest. Un apoyo conjunto y continuo para poder hacer el mejor trabajo para cada historia tanto en mi equipo, como en los que no comparten nada conmigo.

Lo cierto es que, aunque nos guste sentirnos demandados y libres de ataduras, empezar a trabajar es una responsabilidad que corre para ambos lados. Ingresar a una empresa y esperar que todo el aprendizaje suceda dentro de ese edificio, para luego salir y no buscar formas de mantener o ahondar en el conocimiento diario que se va a ir adquiriendo, es en alguna forma aprovecharse de la situación, dado que la empresa, al contratar a alguien sin (o con poca) experiencia, está poniendo en la persona la expectativa de un crecimiento.

No está de más decir que hay situaciones en las que no nos es posible mirar con todo detalle la decisión antes de tomarla. Pero encontrar un espacio y planteo que tenga lógica y acompañe el crecimiento que uno quiere para su desarrollo profesional es importantísimo, dado que va a marcar nuestra rutina y ritmo de vida por una cantidad de tiempo considerable.

En nuestro rubro hay que estar pendiente de los cambios para permanecer al día, por esto el estudio es algo que siempre va a estar presente y es imperativo incorporarlo como algo, no sólo indispensable, sino como algo placentero, un momento de la semana en el cual la preocupación sea únicamente saber qué aprendí y qué me falta por aprender. Es una costumbre adquirible que, de ser ignorada, eventualmente producirá un estancamiento en el desarrollo del profesional que está en formación. 

Cada persona tiene diferentes técnicas para sentirse relajado y afrontar lo mejor posible la inmensidad que se vuelve el hecho de empezar a trabajar y ser consciente de todo lo que se va a tener que poder abarcar. En mi caso, considero importante la idea de que no es tiempo lo que falta, sino organización ante una serie de ideas difíciles de separar u ordenar. Esta situación puede resultar asfixiante en casos donde llegue a grandes niveles tareas. Para no llegar al punto en que se vuelva inmanejable, es simple, pero de gran importancia dividir tiempos para las distintas actividades que se van a tener: en qué medida se va a estudiar, pensando en no quedarse atrás en el trabajo y considerando también momentos de ocio, sin los cuales todo lo anterior no tendría sentido.

Bajo esta idea cae el concepto de lo que uno quiere llegar a ser. No está mal soñar, pero es poco realista pensar que desde el momento en que se empieza la carrera laboral uno va a estar preparado en tan sólo uno o dos años para liderar un equipo de manera integral y habiendo adquirido todas las habilidades para responder a las responsabilidades que ese puesto demanda. En el sueño, como algo banal que puede amoldarse, no habría problema, pero sobre exigirse para obtener resultados poco posibles, es la receta ideal para la frustración y el resentimiento. 

Hay que hacer las cosas a su tiempo, a sabiendas de que si las hacemos bien, eventualmente lo que esperamos va a llegar. Una buena idea -que a mí me resulta- es generar expectativas que uno vaya sobrepasando en el corto plazo, así no se pierden de vista las herramientas y saberes que uno quiere adquirir.

A fin de cuentas, podemos concluir que todas las experiencias son distintas y dependen de lo que la persona espere y lo que esté dispuesta a ceder para lograrlo. Por eso hay que dedicarle un tiempo serio y reflexivo a la realidad de empezar a trabajar. Cuanto más pensada sea la decisión , menos sorpresas uno se va a llevar y más predispuesto se encontrará a dar lo que ya se esperaba como necesario en el día a día. Así se podrían lograr, en mi opinión, las condiciones más óptimas para explotar el potencial de cada uno, realizando las tareas diarias con el fin de obtener el mejor provecho posible, alcanzando cada día un poco más que el anterior.

Autor:
Fiona Lewis
Baufest .Net Developer 

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