jueves, 19 de marzo de 2015

DocumentDB, la base de datos NoSql de Microsoft Azure


En la actualidad las aplicaciones cada vez más demandan y consumen una gran cantidad y volúmenes de datos y requieren seguir teniendo rápidos tiempos de respuesta, es por esto que cada vez toma más fuerza el concepto de NoSql, que fue diseñado para este fin, manejar grandes volúmenes de datos sin afectar la experiencia del usuario, ofreciendo facilidades para la escalabilidad horizontal y el no uso de un esquema rígido para la base de datos (Schema less).


Como respuesta a esto Microsoft combina el concepto de NoSql con el flexible y potente concepto de Cloud, a través del cual nos ofrece un servicio de base de datos NoSql documental llamado DocumentDb alojado en su plataforma en la nube Microsoft Azure.

como mencioné anteriormente DocumentDb es una base de datos NoSql de tipo documental, es decir que almacena la información en documentos, y usa notación JSON para esto, de igual forma como lo hacen otras base de datos como MongoDb y CouchDb por ejemplo. Cabe recordar que la sombrilla de NoSql tiene los siguientes tipos: Documental, clave valor, grafos y familia de columnas, cada tipo con ventajas para diferentes escenarios, si estás interesando en conocer los conceptos básicos de NoSql te invito a darle un vistazo a la siguiente diapositiva: Introducción a las bases de datos NoSql.

Una de las ventajas de DocumentDb es que podemos realizar consultas a nuestros documentos utilizando un lenguaje de consulta muy similar a Sql, y podemos crear procedimientos almacenados, triggers, y funciones utilizando javascript, en dónde podemos realizar operaciones Crud a través de este lenguaje. Adicional otra ventaja de DocumentDb al ser una base de datos diseñada para la nube es su flexibilidad para escalabilidad y elasticidad que se ajustan a nuestras necesidades.

La estructura de recursos de una base de datos DocumentDb es la siguiente:


Como podemos ver, debemos contar con una cuenta de almacenamiento, y sobre esta cuenta podemos tener N bases de datos, las cuales tienen usuarios con permisos asociados y colecciones, que nos permiten agrupar de una manera lógica nuestro documentos, como por ejemplo podríamos tener una colección para artículos, otra para autores, otra para categorías, etc. Y en cada colección tendremos nuestros documentos Json que contendrán nuestra información y para cada colección podemos manejar procedimientos almacenados, triggers y funciones, que recordemos programaremos con JavaScript.

Ahora, para el tema de desarrollo de aplicaciones DocumentDb nos ofrece una Api Rest a través de la cual expone los recursos de la base de datos, lo cual quiere decir que podemos interactuar con la base de datos mediante cualquier lenguaje o plataforma capaz de consumir servicios de este tipo y adicional al utilizar Apis de tipo Rest podemos consumirlas muy fácilmente desde cualquier dispositivo.

Además del Api Rest que expone DocumentDb también contamos con librerías específicas para plataformas las cuales nos ayudan y facilitan la interacción con la base de datos, en la actualidad tenemos librerías para las siguientes plataformas:
  • .Net
  • Node Js
  • JavaScript
  • Pyton
Y bueno amigos eso fue todo de esta introducción sobre DocumentDb la base de datos NoSql del Microsoft Azure, espero sea de utilidad, en próximos artículos observaremos cómo crear la base de datos y sus diferentes recursos, así mismo veremos como interactuar con ella a través del SDK para .Net y también a través de las Apis Rest.

Si quieres profundizar más sobre el tema te recomiendo el sitio oficial de Microsoft Azure: https://azure.microsoft.com/es-es/services/documentdb/

Saludos y buena suerte!

Presentación: DocumentDB, la base de datos NoSql de Microsoft Azure

Hola amigos, hace un par de días tuve la oportunidad de dictar una introducción a documentDB, ya que fui invitado por parte de DevAcademy para participar en uno de sus Hangouts, aquí les comparto la presentación de mi charla y espero sea de utilidad.

domingo, 15 de marzo de 2015

Introducción a DocumentDB, la base de datos NoSql de Microsoft Azure.

Hola amigos, hace un par de días tuve la oportunidad de dictar una introducción a documentDB, ya que fui invitado por parte de DevAcademy para participar en uno de sus Hangouts, aquí les comparto la grabación de la charla y espero sea de utilidad.

domingo, 8 de marzo de 2015

!Apunte semanal - De objetos inmutables, proxies inversos y otras finas hierbas

En nuestra disciplina, carrera, medio o como lo queramos llamar, existen diversas palabras técnicas las cuales suenan bastante complejas, y que pueden poner nuestra imaginación a volar cuando las escuchamos, y aunque lo más probable es que las usemos todos los días sin darnos cuenta, no sepamos su significado u objetivo, como por ejemplo, cuántos términos te son familiares de la siguiente lista?


:Pues sí, es bastante conocida y graciosa esta imagen o generador de excusas aleatorias para los informáticos, y como vemos hay muchos términos que son para dejar con la boca abierta a muchos, y otra frase que podríamos encajar perfectamente en la primera columna del generador de excusas es "Cuando logremos cambiar el valor del objeto inmutable" - "de las clases de abstracción" - "del acelerador de transacciones" o_O no suena nada mal!

Pues bien, de eso va este apunte semanal, y no se trata precisamente de enriquecer nuestro generador de excusas, si no de comprender de qué se tratan los objetos inmutables, objetos que usamos a diario en nuestra profesión como desarrolladores.


Un objeto inmutable es un objeto cuyo valor no puede cambiar una vez es creado, a diferencia de los objetos mutables, los cuales pueden sufrir cambios después de su creación.


En C# suelen manejarse muchos tipos inmutables, es por esto que debemos tener cuidado con su uso, y para comprender esto vamos a usar como ejemplo, un tipo que usamos todos los días, y que es inmutable "string" a eso me refería con que usamos todos los días objetos inmutables.

Por si no lo sabías cuando concatenamos otra cadena a una variable de tipo string, en realidad no estamos modificando directamente su contenido, si no que estamos creando otra variable la cual contiene el nuevo valor, aja! es por esto que siempre es recomendable usar en estos casos en los cuales tenemos que cambiar repetitivamente el valor inicial de la cadena, el tipo StringBuilder ya que es un tipo mutable, y debido a esto podemos cambiar su valor sin que el compilador tenga que crear nuevas cadenas.

string  mensaje = "este es el primer mensaje";
        mensaje += "(mensaje 1)";
        mensaje += "(mensaje 2)";

En el caso anterior tendríamos tres variables de tipo string, mientras que en el siguiente caso estaríamos creando una variable de tipo StringBuilder y la modificaremos en varias oportunidades.

var sb = new StringBuilder("este es ");
    sb.Append("el primer");
    sb.Append("mensaje");
    sb.Append("(mensaje 1)");
    sb.Append("(mensaje 2)");

Bueno y eso es todo de este apunte semanal, espero sea de utilidad y nos pueda servir para optimizar nuestro código.

Saludos y buena suerte!

jueves, 19 de febrero de 2015

Conceptos básicos de Asp.Net MVC

Hola amigos, hace algún tiempo dicté una charla de conceptos básicos de Asp.Net MVC, aquí les comparto la presentación, espero sea de utilidad. Saludos!

domingo, 8 de febrero de 2015

!Apunte semanal - Problemas al depurar tareas en paralelo?


Hola amigos, en anteriores artículos tuvimos una introducción al paralelismo, y mucho más enfocado en lo que Microsoft .Net nos ofrece para trabajar con él, en resumidas cuentas tenemos la TPL que es la librería que nos permite trabajar con paralelismo de una forma muy sencilla, y que nos ofrece varias formas de trabajo como lo son el trabajo con datos a través de ciclos paralelos, paralelismo a través de tareas (Task), Plinq que nos permite realizar consultas linq en paralelo, entre otras. Y entre estas formas de trabajo hay una en particular que se convierte en transversal para todas, y es la depuración de procesos en paralelo, de suma importancia y utilidad para llevar un paso a paso de las instrucciones en las cuales estemos empleando el paralelismo, ya que en este tipo de instrucciones en paralelo podemos tener problemas a la hora de depurar, ya que cuando estamos haciendo paso a paso de una instrucción en ocasiones el depurador se salta y va a otra instrucción que se está ejecutando en simultánea, y luego vuelve a anterior, con lo cual tenemos un gran problema para comprender y seguir la depuración de una tarea en específico, yo por ejemplo he tenido este problema cuando trabajo referenciando dlls de otros proyectos de los cuales no tengo los proyectos agregados en la solución que estoy depurando.


Pues bueno para solucionar este problema si es que se nos presenta, podemos usar la clase Debugger del NameSpace System.Diagnostics, la cual nos permitirá hacer un punto de ruptura a través del método Break(), veamos cómo lo podemos hacer:

Primero vamos a crear en una aplicación de consola con una ejecución de tareas que invoquen diferentes métodos, tal como vemos a continuación:

        static void Main(string[] args)
        {
            Task t = new Task(TareaA);
            t.Start();
 
            Task t2 = new Task(TareaB);
            t2.Start();
 
            Task t3 = new Task(TareaC);
            t3.Start();
 
            Task.WaitAll(new Task[] { t, t2, t3 });
            Console.Write("Terminó la ejecución de las tareas A, B y C.");
        }

 Y ahora vamos usar un punto de ruptura en alguna de las tareas:

        private static void TareaA()
        {
            Debugger.Break();
            Thread.Sleep(2000);
            Console.Write("Se ejecutó la tárea A");
        }

Con este Debugger.Break() ahora podemos depurar el contenido de la tarea A, sin tener problemas de con las otras tareas que se ejecutan en paralelo, adicional también nos podría ser de utilidad cuando tenemos instrucciones muy tediosas de depurar, por ejemplo si estamos recorriendo una lista de 10000 ítems y tenemos un error que solo se genera con alguno de los ítems, podríamos realizar una condicional y usar el Debugger.Break para capturar con mayor facilidad el problema (aunque también lo podríamos hacer con las condicionales que nos ofrecen los puntos de interrupción de Visual Studio).

Bueno y eso es todo de este apunte semanal, espero sea de utilidad.

Saludos y buena suerte!

sábado, 31 de enero de 2015

!Apunte semanal - Configurando el pool de conexiones de Entity Framework.


Sin lugar a dudas uno de los aspectos más importantes y que pueden afectar favorablemente o desfavorablemente el rendimiento de nuestras aplicaciones, es el acceso a fuentes de datos, ya que implica un costo considerable establecer conexión con dichas fuentes. Es por eso que una técnica muy utilizada para lidiar con este problema es el connection pooling o pool de conexiones, el cual permite mantener un número definido de conexiones abiertas  y disponibles para que la aplicación o aplicaciones puedan usarlas sin tener que esperar a abrir una conexión, y es el pool quien se encarga de mantener estas conexiones y distribuirlas según se requiera.


Entity Framework a diferencia de otros ORM's no maneja directamente el pool de sesiones, sino que lo hace a través de ADO.Net, quien se encarga de manejar los pool para los diferentes Data Providers.

¿Y cómo puedo configurar este pool de Ado.Net?

ADO.Net maneja un pool de conexiones por cada cadena de conexión que tengamos en nuestra aplicación, quiere decir que si nos conectamos a dos bases de datos diferentes habrá un pool para cada una de ellas, o si generamos cadenas de conexión dinámicamente en tiempo de ejecución tendremos N pools de conexiones dependiendo de las que generemos (Esto de generar cadenas de conexión en tiempo de ejecución, es muy contraproducente para el manejo del pool), es por esto que si queremos configurar el pool de conexiones debemos hacerlo modificando los siguientes parámetros:

Parámetros a modificar en la cadena de conexión:

<add name="ConnectioName" connectionString="data source=TAVOPC;initial catalog=PoolDemo;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework;
Connection Lifetime=120; Max Pool Size=20; Min Pool Size = 1; Pooling=True;" providerName="System.Data.SqlClient" />

Como podemos ver hacemos uso de cuatro parámetros en la cadena de conexión que corresponden a la configuración del pool, aunque sus nombres son muy dicientes veamos de que se trata cada uno:

Connection LifeTime: Define el tiempo de duración de las conexiones abiertas, se compara la hora en que se creó la conexión con el tiempo actual, para determinar según esta variable si se destruye la conexión o si permanece en pool, su valor esta dado en segundos y su valor por defecto es 0 que indica configurar el mayor tiempo de duración permitido.

Max Pool Size: Define el número máximo de conexiones gestionadas por el pool.

Min Pool Size: Define el número mínimo de conexiones gestionadas por el pool.

Pooling: Define si se va a utilizar el pool para gestionar las conexiones o no.

Bueno y eso es todo de este apunte semanal, espero sea de utilidad.

Saludos y buena suerte!