Introducción a Git: repaso a los conceptos generales

Algo que como desarrolladores debemos conocer muy bien y saber manejar es el uso de repositorios de control de código fuente, garantizando que los desarrollos realizados están debidamente versionados, teniendo una trazabilidad de los cambios y del estado de la aplicación en los distintos ambientes. A día de hoy una gran parte de los repositorios de control de código fuente está usado Git, y cada vez son más los que están migrando a dicha plataforma.

Microsoft por ejemplo anunció hace unos días que Windows está sobre Git (una versión customizada por ellos mismos debido al gran tamaño de los archivos fuentes). Incluso Visual Studio Team Services ofrece Git como alternativa por defecto por sobre TFS (siendo que originalmente era la versión online de TFS). Esto son sólo algunos ejemplos, pero en líneas generales vemos que muchísimos proyectos (tanto OpenSource como no) usan Git como plataforma de versionado de código fuente.

Esto implica que en líneas generales debamos conocer los distintos conceptos asociados para poder hacer un uso correcto de la herramienta, ya que tiene mucha más potencia que las demás alternativas, pero también es más simple cometer ciertos errores con menores/mayores consecuencias en el trabajo propio y en el de los demás si no hacemos las cosas de la forma adecuada.

Lo primero que debemos saber de Git es que es un repositorio distribuido, lo que implica que tengamos dos partes involucradas: el repositorio local y el repositorio remoto. Esto es una diferencia significativa con respecto a otros sistemas de control de código fuente, como TFS por ejemplo, donde solamente existe el repositorio centralizado (el servidor) y todas las operaciones se realizan allí.

IntroGit - Distribuido.png
Esquema de las dos partes que componen un repositorio Git

Repositorio local: Este repositorio es el que está en nuestra máquina local, y es sobre el cual haremos la mayor cantidad de operaciones. Además de que es el que siempre deberá existir de forma obligatoria, ya que puedo tener un repositorio Git solamente en mi PC sin uno remoto (por ende nunca podré compartir el código asociado).

Leer más »

Anuncios

.NET Standard, una librería para dominarlos a todos

Como he comentado en uno de los posts anteriores, en una de las charlas que he dado en el #NetRaf2017 comenté el estado de la plataforma .NET en el 2017. Uno de los puntos interesantes para comentar en mayor detalle es el asociado a .NET Standard, una librería que llega para dominarlos a todos.

Estado actual

Al día de hoy tenemos 3 grandes pilares que conforman la plataforma .NET, cada uno con un propósito bien definido (y muy distinto del que tienen los demás pilares):

NetStandard - Pilares.png

Veamos cada uno en más detalle:

.NET Framework:

Es la alternativa que veníamos usando hasta el día de hoy en el desarrollo de nuestras aplicaciones, también conocida como Full Framework en la actualidad. Se distribuye con el sistema operativo (es lo que estamos acostumbrados hasta el día de hoy, para correr una aplicación .NET debíamos tener la versión correspondiente del Framework instalada en el equipo.

.NET Core:

Es la versión multiplataforma del Framework, más reducida y compacta. Tiene un énfasis muy fuerte en lo que es la optimización del rendimiento, además de dar muchas soluciones a los desarrolladores de forma nativa que antes requerían siempre instalar dependencias adicionales. Lo podemos ver como una versión aggiornada del Full Framework. Dentro de los cambios que introduce, el Framework se distribuye con la aplicación, por lo cual las aplicaciones que hagamos son 100% autocontenidas.

Xamarin:

Plataforma que nos permite hacer desarrollos que corran en gran parte de las aplicaciones móviles, basada en el runtime de Mono (más detalles en este post que escribí introduciendo a Xamarin). Al igual que con .NET Core, el Framework se distribuye con la aplicación, lo cual hace que estas aplicaciones tengan un tamaño final más alto que una equivalente hecha en Java para Android o en Swift para iOS.

Lo que pasa aquí es que cada una de estas plataformas tiene una forma diferente de implementación, particularmente en las API’s a bajo nivel que cada una implementa:

Leer más »

Rider, un IDE multiplataforma para .NET

Uno de los puntos que podemos marcar como desventaja en lo que es el desarrollo en .NET es la poca variedad de IDE’s con la que contamos, además de estar atados a Windows como sistema operativo.

Esto es algo que está cambiando en el último tiempo con el cambio de enfoque producido por la salida de .NET Core y por ende la posibilidad de usar otros IDE’s e incluso otros sistemas operativos. Una de las alternativas es ofrecidas por Microsoft es VS Code, pero al igual que las otras alternativas pueden quedarse un poco reducidas en funcionalidad en comparación a lo que es Visual Studio (aunque esto inevitablemente lo haga pesado).

Hace un tiempo terminé encontrando una alternativa interesante: Rider.

Rider es un IDE para desarrollo .NET que se puede ejecutar en Windows, macOS y Linux. Desarrollado por JetBrains, Rider toma como base IntelliJ, un IDE base muy bien logrado tanto desde el punto de vista de la usabilidad, personalización y del rendimiento. Además de que incorpora de forma nativa ReSharper. Al menos como estoy acostumbrado a usar algunos IDE’s de esa plataforma (especialmente Android Studio), la experiencia de uso me dejó muy buenas sensaciones.

En este post veremos como realizar la instalación en Ubuntu 17.04 y unos ejemplos de uso. Lo primero que haremos es proceder a su descarga desde el sito oficial a través del siguiente link.

Una vez finalizada la descarga del mismo (unos 350 MB) iremos a la carpeta donde lo descargamos y aplicaremos los siguientes comandos:

tar -xf riderRS-171.4456.199.tar.gz
chmod -R 777 Rider-171.4456.199
cd Rider-171.4456.199
cd bin
./rider.sh

Nota: los nombres de carpeta están asociados a la versión que bajé al momento de escribir este post, el cual puede variar al momento en el que lo estén usando.

Una vez finalizado esto, ya podremos comenzar con la ejecución de Rider en nuestro equipo:

Rider - Portada.png

Lo siguiente que deberemos hacer es instalar las dependencias para permitir la compilación y ejecución de las aplicaciones .NET

Leer más »

Documentación automática en ASP.NET WebApi y soporte para arquitectura en capas

Buenas!

Como vimos en el post anterior, es muy sencillo el poder tener una documentación automática y detallada de nuestras WebApi’s. Sin embargo, el enfoque propuesto solamente nos sirve cuando todas las clases involucradas están en el mismo proyecto web.

Esto muchas veces no necesariamente es así. En una arquitectura en capas normalmente tendremos un proyecto separado con las clases que representan las entidades del dominio de nuestra aplicación, las cuales formarán parte tanto de requests y responses de la API. Además de que este esquema (con las clases de entidades separadas en otro proyecto) nos permite compartirlas de forma directa (a través de la DLL resultante) a los clientes de la API, por lo cual es una alternativa más que válida para cualquier caso real de implementación.

Veamos el siguiente ejemplo, donde tenemos nuestro proyecto web (WebApi) y una biblioteca de clases con nuestras entidades que interactuan en la API (WebApi.Contracts). En la API tenemos el controlador UsersController que retorna/recibe instancias de User:

DocumentacionWebApiOtrasAssemblies - EstructuraProyecto

Donde la clase User de contratos tiene el siguiente contenido:

Al ejecutar nuestra aplicación e ir a la documentación de la API, veremos que están las propiedades de la clase pero no la documentación que nosotros le hemos agregado:

Leer más »

URL’s internacionalizadas en ASP.NET MVC

Hace algunos meses en una entrada asociada a Internacionalización vimos cómo cambiar la cultura manualmente en ASP.NET MVC. En el mismo continuamos con mejoras sobre la internacionalización de nuestra aplicación para que más allá de reconocer de forma automática la cultura del navegador del usuario le demos la posibilidad de que pueda cambiarlo.

Algo que venía quedando pendiente de los post’s anteriores sobre este tema es el poder reflejar en la URL la cultura en la que se está visualizando el contenido. Esto tiene varios propósitos:

  • SEO: Como podemos ver en la documentación de Google asociada a la internacionalización, se recomienda hacer visible la cultura de la página que se está visitando. Esto da una mejora en lo que a indexación por parte del motor de búsqueda se refiere.
  • Usabilidad: Además del propósito del punto anterior, le permitir al usuario que utiliza nuestra aplicación el poder ver la cultura correspondiente al contenido que está visualizando. Esto también aplicaría a la hora de compartir ese contenido con otros usuarios.
  • Diseño: Podemos decir que es mucho más natural en el diseño y estructura del contenido de nuestra aplicación que el acceso según cada cultura se vea reflejado en diferentes URL’s.

Para esto continuaremos con lo ya visto en el post mencionado y en toda esta serie de internacionalización, modificando y ajustando algunos aspectos.

Lo primero sobre lo que debemos trabajar es en que la cultura sea visible en la URL de nuestra aplicación, trabajando para ello en las rutas configuradas. En ASP.NET MVC esto se encuentra en el archivo App_Start/RouteConfig.cs, teniendo la ruta por defecto el esquema {controller}/{action}/{id}. Como no queremos cambiar el comportamiento de ese esquema de rutas debemos modificarlo para agregar la cultura pero sin modificar el comportamiento base con las implicancias que conlleva.

Leer más »

Implementando SignalR en ASP.NET MVC

En la entrada anterior vimos algunos puntos asociados al funcionamiento general de SignalR y el planteo que propone. Lo que veremos en este nuevo post es cómo implementarlo en una aplicación ASP.NET MVC y lograr al menos una interacción básica.

Lo primero que haremos es definir el funcionamiento de nuestra aplicación. Lo que queremos lograr es armar un check-list compartido entre distintos usuarios, donde cuando uno de ellos marque un elemento como realizado o no, a los otros también les aparezca dicho estado actualizado. Para este ejemplo haremos algo muy básico, lo cual con el correr de los post’s de esta serie iremos haciendo crecer.

Comenzaremos con una aplicación ASP.NET MVC básica, instalando el paquete Nuget asociado a SignalR:

Install-Package Microsoft.AspNet.SignalR

Una vez finalizada la instalación, deberemos crear el archivo Startup.cs dentro de la raíz de nuestro proyecto web. Es en el mismo donde mediante OWIN estableceremos la inicialización de los mapeos necesarios para la interacción con SignalR, quedando el archivo de la siguiente forma:

ImplementacionSignalR - ClaseStartup
Definición de clase Startup usando OWIN

Hasta allí está lo que es la configuración inicial del proyecto. Lo posterior a hacer será crear el Hub que se encargará de la comunicación con los clientes. Para ello crearemos la carpeta Hubs dentro de la raíz del proyecto web, y dentro de la misma el elemento “SignalR Hub Class” con nombre NotificationHub:Leer más »

Introducción: SignalR en ASP.NET MVC

En la entrada anterior vimos de forma general cómo podemos realizar aplicaciones real-time en ASP.NET MVC. En este post nos vamos a centrar en el primero de esos puntos: SignalR.

Como ya vimos, SignalR nos permite gestionar todas aquellas funcionalidades en las cuales tenemos una interacción en dos vías (conexión bidireccional) entre el servidor y sus clientes.

ASP.NET SignalR es una librería para los desarrolladores de aplicaciones ASP.NET que simplifica el proceso de agregar funcionalidad basada en interacción web en tiempo real. Cuando hablamos de interacción web en tiempo real hacemos referencia a la capacidad de poder enviar contenido desde el servidor a determinadas aplicaciones clientes que lo tendrán disponible de forma inmediata, en vez de que el servidor tenga que esperar que el cliente le solicite nueva información. Esto permite lograr un esquema de conexión bidireccional completo.

Si nuestra aplicación ASP.NET tiene alguna interacción donde necesitamos tener comunicación bidireccional, y para ello utilizamos alguna técnica alternativa (como por ejemplo long polling), quiere decir que podemos usar SignalR en la misma.

 

Vamos a ver algunas cuestiones de teoría asociada a esta interacción en tiempo real entre cliente y servidor. Básicamente existen varias técnicas para poder lograr este comportamiento, algunas mejores en su planteamiento y otras que tienen una mayor compatibilidad:Leer más »