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

Creando un servidor NuGet propio para distribuir nuestras librerías

Algo que nos puede pasar de forma habitual cuando llevamos un tiempo desarrollando aplicaciones es que tenemos nuestras propias librerías para solucionar problemáticas comunes que se repiten de forma periódica. Básicamente lo que tendremos como resultados son DLLs que estaremos exportando de las librerías y referenciándolas desde los proyectos que las necesiten.

Por supuesto que esto es muchísimo mejor que tener la lógica común duplicada en todas las aplicaciones, pero también tiene sus desventajas, las cuales estarán en mayor o menor medida dependiendo de las características de las librerías y la cantidad de aplicaciones que la usen.

La principal es la distribución manual que debemos hacer de ese archivo para todas las aplicaciones clientes que deban usarlo. Normalmente lo que hacemos es copiarla desde otro proyecto que ya la esté usando. Además hay más problemas, ya que al hacer esto vamos a estar subiendo al repositorio de control de código fuente este archivo binario lo cual no deberíamos hacer. Más problemas tendremos cuando nuestra librería evolucione y tenga distintas versiones: ¿cómo sabemos cuál es la que tiene cada aplicación, la que necesitamos nosotros, si hay una nueva versión disponible, las dependencias que tiene cada una de esas versiones?

Está claro que la solución de todo esto es conocida desde hace tiempo, que es tener un paquete Nuget que encapsule todo esto. Pero necesitamos un servidor que nos provea los paquetes y en determinados casos (sobre todo en entornos empresariales) no podemos subir las librerías que se desarrollen en el repositorio público nuget.org

¿Entonces que hacemos? Sencillo, creemos nuestro servidor Nuget propio.

Básicamente es un sitio ASP.NET corriendo en algún entorno al que podamos acceder (puede estar expuesto a internet, en una intranet o hasta en nuestro equipo) con algunas particularidades. Veamos cómo crearlo:

Leer más »

.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 »

#NETRAF2017, un evento que la rompió!!

Buenas!

Les comento que tuve la suerte de participar como speaker en el #NETRAF2017, un evento de tecnologías .NET que se hizo en la ciudad de Rafaela el pasado sábado 20 de mayo. Un lujo todos los speakers de primer nivel que participaron, tanto de la ciudad como a nivel nacional.

En el mismo participé con dos charlas:

La plataforma .NET en el 2017:

En estos últimos tiempos ha habido varios cambios en la plataforma, por lo que es interesante hacer una revisión de dónde estamos parados como desarrolladores y qué alternativas tenemos disponibles. Por ello hice un repaso en general del estado actual de la plataforma y sus particularidades.

Las diapositivas utilizadas son las siguientes:

Chat multiplataforma con reconocimiento de voz:

A modo de cierre del evento, con Ezequiel aplicamos distintos conceptos que se vieron en el evento para desarrollar un chat multiplataforma (sitio web, app Android y app iOS). Para ello, utilizamos las siguientes tecnologías / plataformas:

Leer más »

Elementos comunes en Xamarin.Forms: Páginas

Buenas!

Como hemos comentado en el post donde introducimos Xamarin.Forms, esta plataforma nos permite escribir solamente una vez el diseño y comportamiento de nuestras pantallas para que luego podamos ejecutarlas en distintos sistemas operativos. Para lograr este cometido nos ofrece un conjunto de elementos predefinidos y de cierta forma generales, es decir que tienen un equivalente similar en todas las plataformas.

La documentación oficial de Xamarin.Forms establece los distintos tipos de controles:

  • Páginas
  • Layouts
  • Vistas
  • Celdas

En este post veremos las páginas, el elemento inicial que nos permitirá definir la estructura general de nuestras pantallas y su flujo de navegación.

Páginas

Son el elemento de más alto nivel en Xamarin.Forms y define el comportamiento general que tendrá una pantalla o un conjunto de ellas.

Las alternativas que tenemos disponibles son las siguientes:

XamarinFormsControles - Pages.png

Como podemos ver por los iconos de cada una de ellas, tienen un comportamiento característico. Lo muy bueno de esto es que todas ellas tienen un equivalente en todas las plataformas que Xamarin.Forms soporta y nos abstrae de cómo se implementa en cada una. Nosotros solo definiremos que use esquema con sus propiedades generales,

El más básico es el ContentPage, el cual es una pantalla básica donde podremos agregar cualquier tipo de contenido pero sin ningún comportamiento particular del mismo como si sucederá con los demás. En el ejemplo que vimos en el post inicial de Xamarin.Forms estamos usando este tipo de página:

Leer más »