Tiny Post – Configurando Bash en la terminal integrada de Visual Studio Code

Desde hace un tiempo que vengo trabajando cada más seguido con la consola utilizando Bash – ya sea desde entornos Linux como en Windows -.

Cuando trabajo en Windows uso Git Bash – herramienta que me permite correr Git desde la consola utilizando un emulador de Bash -. Ahora bien, ¿por qué no usarlo directamente desde la terminal integrada que nos ofrece Visual Studio Code?.

La configuración es muy sencilla, lo primero que tenemos que hacer es ir a configuración de las preferencias de usuario: “Archivo > Preferencias > Configuración de usuario” y acto seguido editar la property “terminal.integrated.shell.windows” que se encuentra en la sección “Terminal Integrado”.

A esta propiedad vamos a setearle el path donde se encuentra el ejecutable bash.exe:

"terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe"

El resultado debería ser similar al siguiente:

Configurando la terminal integrada

Configurando la terminal integrada

Reiniciamos Visual Studio Code y ya podemos trabajar con la terminal integrada:

Running bash!

Running bash!

A disfrutar de la consola 🙂

Anuncios

.NET Core – Cuando Sí y cuando NO

En esta “primera edición oficial” del ASP.NET Community Standup LATAM – del cual les voy a hablar más adelante – comenté acerca de cuales son los escenarios en donde conviene arrancar con .NET Core y en los cuales hay que evaluar con mayor cuidado su implementación y tal vez optar por alguno de sus frameworks “hermanos”.

.NET Family

Voy aprovechar este post para resumir estos escenarios y les comparto documentación donde se explica en mayor detalle los motivos de cada uno.

Sigue leyendo

Creando alias y swicheando entre DNX Rutimes [Linux]

En este mini-post simplemente voy a explicarles como crear alias y “swichear” entre los diferentes runtimes de .NET que tengamos en nuestro equipo utilizando dnvm.

DNVM nos proporciona un conjunto de utilidades de línea de comandos que nos permiten configurar nuestro entorno de ejecución .NET (DNX) posibilitándonos el desarrollo de aplicaciones .NET Core en otro tipo de plataformas (en nuestro caso Linux).

Veamos la lista de runtimes disponibles en mi equipo (podemos ver que el runtime activo corresponde a la versión 1.0.0-rc2-16357 de Mono):

dnvm list

Si quiero swichear al DNX correspondiente a la versión 1.0.0-rc1 del rutime .NET Core debo utilizar el siguiente comando:

dnvm use 1.0.0-rc1-update1 -r coreclr -arch x64

Luego de ejecutar el comando podemos validar que efectivamente haya cambiado el DNX Runtime activo:

swiching-runtimes

Ahora bien, si queremos simplificar la cosa podemos usar “alias”, en nuestro caso vamos a crear el alias “default-coreclr” para el DNX Rutime de .NET Core utilizando el siguiente comando:

dnvm alias default-coreclr 1.0.0-rc1-update1 -r coreclr -arch x64

Resultado:

dnvm-alias Finalmente podemos swichear usando el alias:

dnvm use default-coreclr

Espero que les sea de utilidad. 🙂

Nuevo blog! Microsoft Dev Blog

Es para mi un gusto compartir con toda la comunidad el blog Microsoft Dev Blog que comenzamos recientemente con mi gran compañero y amigo @diegobersano. Hace ya un tiempo que venimos con la idea de armar este blog en conjunto, pero por distintos motivos y falta de tiempo se venia postergando.

Microsoft Dev Blog tiene como fin poder compartir los conocimientos y experiencias  que vamos adquiriendo en tecnologías .NET, en principio arrancaremos con Azure pero tenemos pensado ir escribiendo sobre Windows Phone y ASP.NET entre otras novedades tecnológicas.

Microsoft Dev Blog

Microsoft Dev Blog

Espero que les sea útil y desde ya estamos a disposición de todos!

Diego Bersano – Nuevo blog de .NET

Quiero compartirles el nuevo blog de programación de mi amigo y compañero Diego Bersano. Con “Diegote” hace mucho tiempo que venimos trabajando en proyectos bajo tecnologías .NET – sobre todo con ASP.NET MVC y Windows Phone – y es una excelente noticia que haya decidido compartir sus conocimientos en un blog.

Diego Bersano Blog

Diego Bersano Blog

Realmente me pone feliz que mis compañeros contribuyan de este forma con la comunidad y desde ya que les recomiendo seguirlo!

Routing en WebAPI [quickly post]

Hace unos días, un colega me comentó acerca de un problema que tenía con el mecanismo de routing de WebAPI en un proyecto ASP.NET MVC 4. Me comento que se había basado en el primer post que escribí de la serie Web API, en el cual había utilizado un proyecto ASP.NET MVC 3.

Revisando el código generado en ambos proyecto, descubrí que dicho mecanismo había cambiado de una versión a la otra (sobre todo la ubicación en donde se definen las reglas de ruteo).

En proyectos ASP.NET MVC 4 la definición de dichas reglas esta a cargo de la clase WebApiConfig:

WebApiConfig

WebApiConfig

 Esta clase posee el método Register(HttpConfiguration config) el cual es utilizado para definir las reglas de routing que son especificas de Web API:

Agregando una nueva regla de ruteo.

Agregando una nueva regla de ruteo.

Por lo tanto, si necesito generar una nueva regla para los servicios expuestos con Web API, el lugar indicado es este. Hagamos un ejemplo sencillo para que quede claro. Vamos a agregar una nueva entrada llamada “NameApi” que permite al usuario utilizar URIs con el siguiente formato:

http://localhost:301283/api/values/1/sebis

Hecho esto, vayamos al controlador ValuesController (el cual hereda de ApiController) y  agreguemos un nuevo método GET (el hace provecho de esta nueva regla):

Get Method

Get Method

Ahora ejecutemos e invoquemos la URI (escrita unas líneas mas arriba) para corroborar que el servicio nos retorna el valor correcto:

Resultado obtenido del servicio

Resultado obtenido del servicio

Espero que les sea de utilidad.

Implementando características de OData con ASP.NET WebAPI

En esta nueva entrega sobre ASP.NET Web API vamos a hablar sobre las características que este soporta del protocolo Open Data Protocol (de ahora en mas OData).

Open Data Protocol

Open Data Protocol

Antes de comenzar, vamos a realizar una pequeñísima introducción a Open Data Protocol.

OData es un protocolo abierto – open protocol – creado por Microsoft para exponer datos como servicio. Este se basa en estándares conocidos de Internet como HTTP, Atom (AtomPub) y JSON. Como todo protocolo de servicios, uno de los fines principales es poder independizar los datos de la aplicación o sitio web que los utiliza. Los clientes que consumen servicios a través el protocolo OData pueden hacerlo bajo formatos como Atom, JSON o XML plano, pero además incluyendo características como paginación, ordenación y filtrosquerys -.

Otra característica interesante de OData es que nos permite exponer y acceder a información de una gran variedad de fuentes, incluyendo, bases de datos relacionales, sistemas de archivos, sistemas de gestión de contenidos y sitios web tradicionales.

Escenarios de despliegue de OData

Escenarios de despliegue de OData

Ahora bien, de todas las características que ofrece OData, la que nos interesa en este momento es la utilización de convenciones URI que nos permitirán, entre otras cosas, realizar operaciones como navegación, filtrado, orden y paginación de datos en la solicitud de un recurso.

URI Components

URI Components

La utilización de estas convenciones nos permiten, desde la misma URI del recurso, especificar query options que serán aplicadas al momento de obtener un recurso. Podemos ver en el gráfico anterior – URI Components – que las opciones de consultas se especifican al final de la URI.

Ejemplos de query options son:

  • $filter : permite aplicar filtros sobre el resultado.
  • $orderby : permite ordenar por alguna condición el resultado
  • $top : permite recuperar un cierto número de resultados.
  • $skip : permite saltear un cierto número de resultados.

Vayamos a un ejemplo, si quisiera obtener la lista de clientes ordenadas por nombre, debería invocar al servicio utilizando la siguiente URI:

http://localhost:[port]/api/clientes?$orderby=Nombre

Ahora bien, ASP.NET Web API trae soporte para un subconjunto de características del protocolo OData. Una de ellas es que podemos trabajar con las convenciones URI que trabajaran en la interacción con los controladores de nuestra API.

Para trabajar con ellas simplemente debemos modificar el tipo de datos de la respuesta de nuestro método. Recordaran que en post anteriores el método retornaba un objeto IEnumerable:

Método de acción Get() retornando un IEnumerable

Método de acción Get() retornando un IEnumerable

En este caso debemos vamos a modificar la firma y el cuerpo del método para que retorne un objeto IQueryable:

Método de acción Get() retornando un IQueryable

Método de acción Get() retornando un IQueryable

Tal como menciona MSDN, el motivo de esta cambio es que la interfaz IQueryable hereda la interfaz IEnumerable, por lo que si representa una consulta, se pueden enumerar los resultados de esa consulta (la enumeración provoca la ejecución del árbol de expresión asociado a un objeto IQueryable). Es tarea del framework armar la consultas correctamente a partir de las query options enviadas en la URI.

Realizado el cambio, vamos a consumir el servicio como lo veníamos haciendo normalmente utilizando la siguiente URI:

http://localhost:[port]/api/clientes
Datos obtenidos del servicio

Datos obtenidos del servicio

Podemos observar que los resultados vienen en el mismo orden que los habíamos agregamos en el array (es decir, sin estar ordenados por alguna condición). Ahora solicitemos el mismo recurso, especificando que vengan ordenados por el atributo nombre:

http://localhost:[port]/api/clientes?$orderby=Nombre
Datos obtenidos del servicio utilizando las convenciones de URL

Datos obtenidos del servicio utilizando las convenciones de URL

Como vemos, utilizando las convenciones URI, es muy simple establecer condiciones-acciones-funciones en la obtención de los recursos! 🙂

Pero eso no es todo, también podríamos trabajar con paginación y filtros. Simplemente debemos agregar en la URI la query correspondiente de acuerdo a nuestras necesidades, algunos ejemplos:

http://localhost:[port]/api/clientes?$filter=Nombre eq ‘Jous’
  • Filtrar utilizando operadores lógicos:
http://localhost:[port]/api/clientes?$filter=Nombre eq ‘Sebis’ or Nombre eq ‘Jous’
http://localhost:[port]/api/clientes?$top=3&$skip=0

También tenemos disponibles un gran conjunto de opciones de query dentro de las cuales podemos encontrar: Select, Top, OrderBy, Expand, Format, DateTime Functions, Math Functions, Type Functions y muchísimas otras más.

Para finalizar, quería comentarles que OData dispone de un conjunto de API’s de creación y consumo de Servicios OData para trabajar desde el lado del cliente con dispositivos mobiles (WP7, Android, iOS), app webs (Silverligth, ASP.NET, HTML 5 + Javascript, Java, PHP, Ruby) y web CMS (Joomla, Drupal). Y también desde el lado del servidor con custom servers (.NET Server, Java, PHP, Node.JS),  databases (SQL Server, MySql, Azure Data) y cloud app (App Engine, Azure).

Espero que les sea de utilidad.

Nos vemos pronto!