miércoles, 7 de diciembre de 2016

Novedades Connect 2016 - Overview .net


Ahí va un post más sobre las más recientes novedades en ámbito Microsoft. Como cada año esta compañía organiza el evento Connect en Nueva York donde se presentan las novedades en todos sus productos, es un evento comercial donde hay bastante postureo pero como developer que acostumbra a usar este tipo de tecnologías en su día a día no puedo evitar emocionarme con algunas mejoras y ver como cada vez 'mi código' puede correr en más plataformas y proporcionar mejor servicio. Si eres de los que trabajas por tu cuenta cada vez tendrás acceso a más público independientemente de alojamientos y demás. Si trabajas para una empresa que implementa su producto final cada vez tienes acceso a más servicios y todo está mejor integrado (...), en fin me gusta la corriente que está tomando Microsoft. Este año estoy especialmente metido en novedades porque he tenido la suerte de participar con algunos compis como developer en algunos de los ejemplos que se han visto. Así que ahí va mi resumen del evento y valoración personal de las demos que vimos sobretodo en las keynotes que podéis ver aquí a través de un enlace.

Eventos reconnect


Antes de resumir la keynote, comentarte que en España se hace un evento Reconnect en varias ciudades donde se explican estas novedades en forma de demo realizada por MVP Microsoft, mira a ver si hay un evento en tu ciudad o cerca y no te lo pierdas!

Resumen Key Note


Aquí os dejo un enlace del vídeo de channel 9, si tenéis problemas online se puede descargar y verlo. Si no tienes 4 horas para verlo completo te recomiendo leer el resumen de este post e ir directo a la demo que te interese.

  • Mejoras en Visual Studio Code (00:07 hasta 23:30)
    Es la versión ligera y multiplataforma de IDE por la que apuesta microsoft que tuvo y sigue teniendo una gran aceptación entre la comunidad de developers, incluso aquellos que no trabajan necesariamente con tecnologías microsoft. Es un producto que sin perder su sencillez y ligereza cada vez está dotado de más extensiones y utilidades que nos facilitan la vida y nos permiten automatizar aspectos del desarrollo, build y despliegue de software. No busquéis lo mismo en este IDE que en Visual Studio pero me parece un productazo y una gran demo donde nos podemos hacer una idea.

  • Visual Studio 2017 + Xamarin (00:33 hasta 49:00)
    Como sabemos el IDE por excelencia de Microsoft es Visual Studio, en los últimos años este IDE ha pasado a tener varias versiones desde una enterprise que lo peta y casi te mide hasta el pulso hasta una communitiy que es gratuita y muy completa. En Connect se hace oficial una release candidate de este IDE, en este punto de la demo ponen foco en como se integra con proyectos de tipo Xamarin (desarrollo móvil multiplataforma con .net) y como mejora la integración entre emuladores y apis backend al ver como depura el proyecto. Xamarin ya era un gran producto, aún no hace ni un año desde la compra de Xamarin y ya podemos ver como ha mejorado mucho la integración con Visual Studio.

  • Visual Studio Mobile Center (00:51 hasta 01:01)
    Es un servicio que te permite controlar tus aplicaciones móviles, versionado, plataformas, distrubuciones a beta testers, etc. En la demo se puede ver como con unos pocos clicks puedes conectar este servicio a tu repositorio de código fuente y montar fácilmente escenarios de CI, CD. Otro tema interesante que te proporciona este servicio es que el por defecto te proporciona todos los agents para hacer una build a todas las plataformas, en otras palabras, no necesitarás ya configurar el mac personal como agente para compilar la aplicación en iOS. El servicio también te proporciona analíticas de error y uso de usuarios y podemos ver como integrar fácilmente con servicios potentes de BI como power Bi...

  • Visual Studio 2017 + Docker (1:09 hasta 1:16)
    Seguimos con mejoras que nos aporta Visual Studio 2017 a mi personalmente que últimamente estoy tocando bastante docker con .net core me gusta la idea de tener las docker tools integradas y poder realizar el compose y depurar entre contenedores integrado con el propio IDE me pareció una gran mejora para facilitar y automatizar ciertos comandos en tu proceso de build o deploy sin tener que hacer scripting e incluso como comenta Donovan Brown en la demo de Keynote es ideal para aquellos developers que ni quieren saber nada de contenedores, imágenes ni linea de comando.

  • Azure Container Services (01:16 hasta el 01:25)
    Siguiendo con la tendencia de contenedores, podréis ver que ofrece Azure con Azure Container Services (ACS, preview), como encaja en escenarios de microservicios, como lo hace para depurar entre contenedores, podemos ver la integración entre ACS y release management así que no puedo decir nada más que esto tiene muy buena pinta!

  • SQL Server Linux (01:35 a 01:40)
    En realidad esto no es una novedad ya se había anunciado, lo que sí se anuncia como novedad es que Microsoft libera la imagen pública de SQL Server Linux para docker lo cual es una gran noticia. Hasta ahora si querías hacer una api con .net core y deployarla en docker tenías que usar Postgree ya que SQL todavía no soportaba docker. Ahora ya tienes la imagen oficial si haces un pull de microsoft/mssql-server-linux, yo la uso en un proyecto que estoy desarrollando y te puedo asegurar que la instalación y puesta en marcha te cuesta minutos... bastante optimo.

  • Net .core on Tizen (02:36 a 02:40)
    Por última destacar una gran novedad para los amantes de .net ya que Samsung soportará a través de Tizen código .net en sus smart devices lo cual implica que tu código .net podrá llegar a la televisión, reloj, etc.

Y hasta aquí mi resumen de la keynote, me he saltado algunas partes interesantes sobre todo en temas de bi e inteligencia que sino el post se hace eterno. Espero os guste!

sábado, 21 de mayo de 2016

Ecmascript 6 dev usando VSCode, Babel y WebPack


Esta semana me ha tocado ponerme un poco con Ecmascript 6. Si estás bastante puesto en desarrollo javascript no te aportaré nada con este post, podrías dejar de leerlo, pero si lo que quieres es tener una introducción a Ecmascript y poder montarte tu hola mundo este es el post.

Desde que me dedico a desarrollar software Ecmascript siempre ha estado ahí, mi percepción de ecmascript era como la versión avanzada de javascript que tenías que ir con cuidado al usar en combinación con código javascript porque corrías el riesgo que ese código no funcionase en todos los navegadores. Ya veréis que la cosa ha evolucionado mucho pero sigue pasando lo mismo con la diferencia que a día de hoy ya tenemos transpiladores que se encargan de hacer que nuestra aplicación pueda funcionar en todos los navegadores. La transpilación en este caso consiste en entender el código Ecmascript y saber traducirlo a versiones de javascript soportadas por todos los browsers.

Ecmascript nació en 1997, mientras algunos navegadores apostaban por javascript, otros JScript y en definitiva cada browser y plataforma hacía un poco la suya en ámbito HTML finalmente se decidió adoptar un estándar con javascript como base que se respeta por todos los navegadores. A partir de ahí javascript ha ido creciendo siempre respetando las especificaciones de Ecmascript, tras una fase donde los developers veíamos javascript como un lenguaje menor llegó de Ajax y javascript empezó a tomar relevancia. Más tarde salieron frameworks y librerías que han puesto a javascript entre uno de los lenguajes de programación más usados. Aún así hasta la llegada de Ecmascript 6 javascript no permitía usar mecanismos de los que disponemos en otros lenguajes de programación. Se podría decir que con la llegada el año pasado de Ecmascript 6 se dota a javascript de todos estos mecanismos que hacen que programar en javascriptno sea tan diferente a lo que estás acostumbrado a programar en ámbito backend con java o c#. Os dejo un link que explica a la perfección que nos aporta Ecmascript 6 respecto la versión anterior. Entre las mejoras, declaración simplificada de clases, definición de constantes, arrow functions (vendrían a ser un simil de lambda expressions), module import/export etc...

Ya vale de wikipedia XD a continuación explicaré como montarte un entorno que te permita transpilar el código Ecmascript y poder jugar un poco. Dejar claro que es un entorno para probar y desarrollar si tuviese que hacer en un proyecto para clientes y desarrollar con cara y ojos me integraría con el debugger, testing, linters y en definitiva miraría de darle una vuelta esto que propongo aquí es un entorno que te funcionará y podrás desarrollar con Ecmascript pero no digo que sea la mejor opción ni mucho menos. Lo que buscaba al montarlo era perder el mínimo tiempo posible en montar una arquitectura cliente que me permita desarrollar en Ecmascript 6 desde un IDE y ver el resultado en un browser.

Vamos con los pasos para nuestro hola mundo. Una vez tengas node, podrías abrir la carpeta con Visual Studio Code dentro crea un archivo package.json en lo que sería el root del proyecto.

package.json

{
    "name":"areatic.ecmascript.seed",
    "version":"1.0.0",
    "scripts":{},
    "devDependencies": {
        
    }, 
    "dependencies": {
        
    }
}
Lo siguiente que haremos será instalar los paquetes necesarios a través de npm. Desde vsCode Ctrl+Shift+P, esto nos lleva a command palete donde hemos de seguir los dos pasos de la imagen.



Ahora si volvemos a command palette Crl+Shift+P ya podemos usar comandos npm para instalar webpack y babel que son mis elegidos para la transpilación y servidor http de desarrollo. Insisto, he optado por esta opción aunque hay otras... Una vez estamos en la paleta de comandos escribe "npm install" y entre las opciones deplegadas selecciona "install and save dev dependency" te pedirá el nombre del paquete como muestro en la imagen, escribe "babel-core" y pulsa enter.


Ahora se trataría de repetir el mismo proceso para el resto de paquetes necesarios para este entorno:

babel-loader

babel-preset-es2015

webpack

webpack-dev-server

Al finalizar este proceso, si abres el fichero package.json deberías ver como se han añadido automáticamente a devDependencies estos paquetes. También deberías tener una nueva carpeta en la root del proyecto "node_modules". El siguiente paso es crear un archivo de configuración para webPack, pulsamos new file desde VSCode y lo llamamos webpack.config.js:

webpack.config.js

var path = require('path');
var webpack = require('webpack');
 
module.exports = {
  entry: './index.js',
  output: { path: './app', filename: 'bundle.js' },
  module: {
    loaders: [
      {
        test: /.jsx?$/,
        loader: 'babel-loader',
        exclude: /node_modules/,
        query: {
          presets: ['es2015']
        }
      }
    ]
  },
};
Ahora vamos a automatizar la tarea para hacer una build que se encargue de transpilar con babel y levantar nuestra aplicación con webpack para ello volvemos a command palete con Ctrl+Shift+P, escribimos task y seleccionamos "configure task runner", esto nos permitirá editar el archivo task.json. Aquí veremos que nos vienen comentadas una serie de opciones ya preparadas para typescript, gulp, npm, etc.. nosotros personalizaremos una task de este modo:

.vscode/task.json

{
 "version": "0.1.0",

 "command": "${workspaceRoot}/node_modules/.bin/webpack-dev-server",

 // The command is a shell script
 "isShellCommand": true,

 // Show the output window only if unrecognized errors occur.
 "showOutput": "always",

 // args is the HelloWorld program to compile.
 "args": [
        "--progress", 
        "--colors"
    ], 
    "echoCommand": true,
 "tasks": [
  {
   "args": [
    "" 
   ],
   "suppressTaskName": true,
   "taskName": "webpack dev",
   "isBuildCommand": true
  }
    ]
}

Con esto ya tendríamos el entorno de desarrollo, ahora los siguientes pasos describen como hacer una aplicación muy sencilla con Ecmascript. En primer lugar dentro de src crearemos un archivo .js que llamaremos Greeter.js

src/greeter.js

const defaultGreeter = "ola que ase amigo";

function sayHello(greeter){
    console.log('Greeter in action');
    return greeter;
}

export default {sayHello, defaultGreeter}
A continuación creamos index.js y index.html en la root del proyecto.

index.js

import HelloWorld from './src/Greeter.js'

var context = window || global;
var app = {};

var app = context.app;
if (!app) {
    app = context.app = {};
}

app.HelloWorld = HelloWorld;

export default app;

index.html

<html>
    <head>
        <script src="bundle.js"></script>
    </head>
    <body onload="javascript:document.getElementById('greeterinput').value = app.HelloWorld.defaultGreeter">
        <button onclick="javascript:(document.getElementById('myP').innerHTML = 
        app.HelloWorld.sayHello(document.getElementById('greeterinput').value))">Say Hello</button>
        <input id="greeterinput" type="text" />
        <p id="myP"></p>
    </body>
</html>
Ya tenemos la aplicación, ahora con Ctrl+Shift+B arrancas webpack.



Si abres la url http://localhost:8080/index en tu browser favorito podrás jugar con la aplicación que acabamos de crear.



Hasta aquí el post de esta semana, espero sea de utilidad a alguien, este artículo es de Mayo 2016 si te dispones a usar este entorno pasado ya un tiempo te recomiendo que eches un vistazo a ver si hay optimizaciones en cuanto a soporte de Ecmascript 6 en navegadores. Recuerda que puedes seguir areaTIC en las redes sociales y cualquier aportación, comentario, duda siempre es bienvenida!

domingo, 15 de mayo de 2016

Eventos para conocer Microsoft Hololens


En este post quiero dar repercusión a dos eventos que participa Plain Concepts en Madrid y Barcelona, los días 18 y 19 de Mayo respectivamente donde se hablará de Hololens y se harán una serie de demos del producto. Los eventos son gratuitos así que si estás esta semana que viene por Barcelona o Madrid no tienes excusa para acercarte y pasar un buen rato. Si vas al de Barcelona, por allí nos veremos!

Te dejo un enlace oficial donde puedes ver vídeos y conocer un poco más sobre el producto

Yo esta semana pasada tuve la oportunidad de probar en el trabajo las gafas Hololens de Microsoft. La verdad que la experiencia valió la pena!

Nos vemos esta semana por Barcelona!

lunes, 18 de abril de 2016

IHostingEnvironment en Asp.net Core, Environment y uso de variables


Cuando desarrollamos aplicaciones web necesitaremos 'hacer cosas' en función del entorno donde está desplegada la web. Por poner un ejemplo en desarrollo si se produce una excepción nos interesa que nos lleve a una página donde nos muestre el máximo de información sobre el fallo en cambio en pre o producción tal vez no queramos que se muestre todo el detalle sobre que ha provocado la excepción sino que enviamos el detalle a algún servicio o log y mostramos una página más bonita.

Por defecto cuando creas un proyecto web asp.net core en Visual Studio la template te proporciona la clase Startup:


Por otro lado si vais a las propiedades del proyecto web veréis que oob tenemos una variable de entorno definida en el profile por defecto.


Aquí podemos añadir variables (añado Test:Value) que luego podemos usar en código del siguiente modo:
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
   app.Run(async (context) =>
   {
      await context.Response.WriteAsync(Environment.GetEnvironmentVariable("Test") + "\r");
   }
}
El resultado será:

Value

Pero bueno lo que quería mostrar en este post es que información nos proporciona IHostingEnvironment en asp.net core, así que vamos a ello. En este fragmento de código estoy mostrando el nombre del entorno, muestro el contenido del directorio Root y por último vemos por pantalla el valor de IsDevelopment() e IsProduction(). Sí... hay modos más elegantes de concatenar strings en C# ...
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
   app.Run(async (context) =>
   {
      await context.Response.WriteAsync("Nuestra Variable Test: " + Environment.GetEnvironmentVariable("Test") + "\r");
               
      await context.Response.WriteAsync("Environment.Name: " + env.EnvironmentName.ToString() + "\r");

      IDirectoryContents directoryContent = env.WebRootFileProvider.GetDirectoryContents("");
      await context.Response.WriteAsync("Directorio Root: \r");
      foreach (var item in directoryContent) {
         await context.Response.WriteAsync(item.Name + "\r");
      }

      await context.Response.WriteAsync("isDevelopment() = " + env.IsDevelopment().ToString() + "\r");
      await context.Response.WriteAsync("isProduction() = " + env.IsProduction().ToString() + "\r");
   });
}
Si ejecutamos en IIS Express veremos los siguientes valores por pantalla:
Nuestra Variable Test: Value
Environment.Name: Development
Directorio Root: 
web.config
isDevelopment() = True
isProduction() = False
En cambio si realizo un deploy a Azure (equivaldría a producción en esta prueba de concepto), el mismo código produce el siguiente output:
Nuestra Variable Test: 
Environment.Name: Production
Directorio Root: 
ApplicationInsights.config
App_Data
bin
hostingstart.html
web.config
isDevelopment() = False
isProduction() = True
Como veis el resultado cambia, si os fijáis en la variable de entorno que he definido al principio en producción no tiene valor. En Azure si voy al sitio web que me he creado podría añadir la variable de entorno Test como veis en la imagen y con esto al volver a cargar la página vería el valor correspondiente en el output.



Hasta aquí el post de hoy, que vaya bien la semana!

viernes, 25 de marzo de 2016

Intro Angular 2 con TypeScript

Angular 2 está al caer así que hace días que quería echar un vistazo a ver que tal. He desarrollado una aplicación que comunica con una api personal (la estoy desarollando en asp.net core) que permite gestionar tu propio álbum de fotos. A continuación comparto algunas notas por si alguien se anima a empezar con la parte cliente, aunque no tengas api puedes simular lo que hago con un mock .json. Antes que sigas leyendo comentar que todo lo que explico en este post ya está explicado en la doc oficial de Angular o en otros blogs. En este post lo que hago es ir explicando paso a paso completando con enlaces que me parecen interesantes y comparto algún que otro repo e información que puede ayudar a otros a iniciarse, se podría decir que comparto mis apuntes y pruebas de concepto que puedes seguir si estás interesado.

En primer lugar mencionar TypeScript que es el lenguaje recomendado para desarrollar con Angular 2, esto no quiere decir que estés obligado a usarlo aunque es recomendable. Personalmente, visto que SPA ha venido para quedarse me gusta la idea de tener código tipado en los desarrollos front y poder beneficiarme de las ventajas de un lenguaje OOP. Otra ventaja es que IDE's que interpreten TypeScript te ofrecerán intelisense y te avisarán en tiempo de diseño sobre el código que puede dar problemas al compilar o en runtime sin necesidad de tener que ejecutar la aplicación.

Volviendo a Angular 2. Esto va de componentes, tenemos que pensar que cada elemento con lógica de la vista puede ser un componente y estos son jerárquicos. Si vienes de Angular 1.x tienes ganado el concepto SPA y que ya se usaban directivas en la versión anterior. Ya verás que en Angular 2, no hay demasiada diferencia entre un componente y una directiva.

Configuración Entorno


Yo he optado por empezar con Visual Studio Code, para configurar el entorno tenemos que seguir los pasos de este tutorial de Angular.io. Angular 5 min Quickstart ts e instalarte Node y Git.

Es recomendable leer estos tutoriales y entender lo básico sobre como crear el boostrapper, el primer componente, navegación, como funciona la compilación (o transpilación) typescript, npm, etc.

Una vez tengas esto por la mano te recomiendo usar una aplicación de seed o referencia en la que fijarte para aprender, en mi caso, me clone este repo de Github via @danwahlin que me ha ido perfecto para tener un entorno estable ya configurado y tener ejemplos en los que apoyarme.

Estructura de un "objeto" en Angular


Todo componente, directiva o servicio en Angular 2 se estructura del siguiente modo:
  • Bloque Import
    El simil en otros lenguajes vendrían a ser los using, includes, scripts en función del lenguaje y es una referencia a donde están ubicados los componentes, servicios o directivas que usaremos en el "objeto" que estamos definiendo
  • Definición de mi "objeto"
    Este bloque variará en función de si estamos creando un componente, servicio o directiva. Para crear un servicio usaremos @Injectable, un componente @Component o una directiva @Directive.
  • Implementación del objeto (export)
    Clase con la implementación de tu objeto.

Servicio de acceso a datos


Ahora veremos como crear un servicio que comunique con la Api, si has descargado el repo que te comentaba de @danwalhim estoy calcando su DataService. Vereis que en Angular 2 se usan Reactive Extensions, os dejo un buen post de @thoughtram donde podéis leer más al respecto.
import { Injectable } from 'angular2/core';
import { Http, Response } from 'angular2/http';
import {Observable} from 'rxjs/Observable';
import 'rxjs/add/operator/map'; 
import 'rxjs/add/operator/catch';

@Injectable()
export class DataService {
  
    baseUrl: string = '';

    constructor(private http: Http) { }

    getAlbums(){
      return this.http.get(this.baseUrl + 'albums.json')
                      .map((res: Response) => res.json())
                      .catch(this.handleError);               
    }
    
    handleError(error: any) {
        console.error(error);
        return Observable.throw(error.json().error || 'Server error');
    }

}
Como vemos la definición del servicio no implica definir un bloque @component sino que en este caso simplemente indicamos que será un elemento @injectable.

Componente Lista Álbumes


Ahora crearemos un componente que se encargue de mostrar una lista de álbumes usando el servicio que acabamos de crear.
import { Component } from 'angular2/core';
import { DataService } from '../shared/services/data.service';

@Component({ 
  selector: 'albums', 
  providers: [DataService],
  templateUrl: 'app/albums/albums.component.html'
})

export class AlbumsComponent {

  title: string;
  albums: any[] = [];

  constructor(private dataService: DataService) { }
  
  ngOnInit() {
    this.title = 'Albums';

    this.dataService.getAlbums()
        .subscribe((albums:any[]) => {
          this.albums = albums;
        });
  }
}
En la definición de @Component indicamos un selector, en providers indicamos los servicios que inyectamos vía constructor, le especificamos la ruta donde tendremos la vista y de momento no necesitamos nada más. En la implementación tenemos un array con los albumes y al iniciarse el componente los obtenemos usando el servicio que hemos creado en el paso anterior.

Vista Lista Álbumes


Pasamos a crear una vista minimalista que nos muestre los datos que hemos obtenido del servicio. Ya lo iremos complicando paso a paso explicando y entendiendo lo que hacemos. Al menos a mi es como me gusta aprender un nuevo framework.
<div class="row">
    <div>
        <div class="col-xs-6">Title</div>
        <div class="col-xs-6">Description</div>
     </div>
    <div *ngFor="#album of albums">
        <div class="col-xs-6">{{album.title}}</div>
        <div class="col-xs-6">{{album.description}}</div>
     </div>
<div>
Esto debería renderizarse con los datos que tengas en el servicio o mock. En los datos que devuelve mi api se puede apreciar un gran factor de postureo... no se me ocurrían otros álbumes jajajjajajaj.



Interacción entre vista y componente


Ya para acabar el post de introducción a Angular 2 veremos algunos modos de interactuar entre vista y componente. Añadiremos un campo de texto que nos sirva para filtrar el contenido que ha devuelto servidor, primero lo haremos en plan básico y en segundo lugar lo haremos creando un componente para el filtro.

Usando el mismo componente:.
<div><input #term type="text" (keyup)="filter(term.value)"></div>
El siguiente paso será añadir un método filter al componente y la propiedad filteredAlbums. Vuelvo a mostrar como quedaría el componente.
export class AlbumsComponent {

  title: string;
  albums: any[] = [];
  filteredAlbums: any[] = [];

  constructor(private dataService: DataService) { }
  
  ngOnInit() {
    this.title = 'Albums';

    this.dataService.getAlbums()
        .subscribe((albums:any[]) => {
          this.albums = this.filteredAlbums = albums;
        });
  }
  
  filter(term: string){
      this.filteredAlbums = [];
      this.albums.forEach(function(album){
          if (album.title.indexOf(term) > -1 || album.description.indexOf(term) > -1)
            this.filteredAlbums.push(album);
      }, this);
  }
}
Esto debería funcionarte, lo que hemos hecho es usar un evento del input que siempre que se produzca (keyup) llamaremos a un método. Esto no deja de ser lo que hemos hecho toda la vida con html y javascript. Ahora veremos un modo más elegante de implementar lo mismo creando otro componete para el filtrado. Llegado este punto es bueno entender que Angular 2 promueve componentes anidados que definen una jerarquía como represento en la imagen de la aplicación que tenemos hasta ahora, a ver si la imagen ayuda.



Vamos a crear entonces nuestro componente de filtrado. Es importante entender el uso de @Output, que lo usamos para indicar que el componente emite un evento de tipo "changed" (podría emitir más de uno).
import { Component, Output, EventEmitter } from 'angular2/core';

@Component({
  selector: 'filter-textbox',
  template: '<input type="text" [(ngModel)]="model.filter" (keyup)="filterChanged($event)"/>'
})
export class FilterTextboxComponent {

    model: { filter: string } = { filter: null };
    
    @Output()
    changed: EventEmitter<string> = new EventEmitter();

    filterChanged(event: any) {
        event.preventDefault();
        this.changed.emit(this.model.filter); //Raise changed event
    }
}
El siguiente paso es sustituir el input que hemos añadido anteriormente a la vista de álbumes por este, fijaros en el selector "filter-textbox".
<filter-textbox class="navbar-right" (changed)="filterChanged($event)"></filter-textbox>
Finalmente vamos al componente de lista de álbum y en el bloque @Component añadiremos la sección directives donde le indicaremos que queremos anidar FilterTextBoxComponent. No olvidéis también indicar en la sección import donde está ubicado el componente FilterTextBoxComponent.
...
import { FilterTextBoxComponent } from './filterTextbox.component';

@Component({ 
  selector: 'customers', 
  providers: [DataService],
  templateUrl: 'app/customers/customers.component.html',
  directives: [FilterTextboxComponent],
})

export ...
Hasta aquí el post de hoy, hemos visto una introducción muy básica a Angular 2. Por mi parte seguiré desarrollando tanto la aplicación en Angular 2 como la Api en asp.net Core, la idea es una vez lo tenga más definido es subirlo a un repo de Github. Como siempre a medida que vaya haciendo si veo algo interesante para un post lo iré contando en areaTIC. Si te ha gustado el post, aprovecho para comentarte que puedes seguir areaTIC en las redes sociales o bien puedes seguirme en twitter @canizarescarlos no te cortes a comentarme lo que sea o dudas... todo amigo de la tecnología es mi amigo :) Que vaya bien!

domingo, 28 de febrero de 2016

Intro TypeScript - Open Close Principle

Hoy haré una pequeña prueba de concepto para ver como funciona un poco por encima TypeScript. Me dispongo a implementar el clásico ejemplo de calculador de áreas aplicando Open Close Principle de SOLID. Me parece un buen ejemplo para ver como usar mecanismos OOP en TypeScript.

TypeScript es un lenguaje open source creado sobre el 2012 y mantenido por Microsoft. Es un lenguaje basado en javascript que permite trabajar con clases y usar mecanismos OOP que no disponemos en javascript. El código TypeScript no se compila sino que se transpila, es decir, el compilador de TypeScript se encarga de traducir el código a javascript. Existen otras opciones como EcmaScript 6 o CoffeScript, similares que no entro a comparar porque tendría trabajo solo decir que si usas Visual Studio como IDE para desarrollar javascript seguramente la mejor opción es TypeScript por esto:



En la página oficial de TypeScript podemos encontrar ejemplos y el handbook que va bien para echar un vistazo a que se puede hacer.

En primer lugar comentar que para la prueba de concepto he usado Visual Studio 2015 en un aplicación cordova, en realidad no voy a pasarla a ningún dispositivo móvil simplemente he optado por este tipo de proyecto para la prueba de concepto porque la plantilla ya te lo da todo OOB para empezar a jugar con TypeScript. Destacar que se integra perfectamente con el IDE Visual Studio.

El ejemplo que voy a implementar lo he basado en este post de CodeProject donde está explicado como aplicar el principio en C#.

En primer lugar crearé una interface, IShape con un método Area():
module AreaCalculator {
    "use strict";

    export interface IShape {
        Area();
    }
}
Como veis he creado un module, ya que nos aislará del contexto global y de paso nos permitirá separar las clases, interfaces y demás que componen el servicio en diferentes archivos lo cual facilita el mantenimiento y trabajo equipo. Ahora que tenemos la interface, crearemos 2 formas que la implementen... un circulo y un cuadrado:
module AreaCalculator {
    "use strict";    

    export class Circle implements IShape {
        protected radius: number;

        constructor(radius: number) {
            this.radius = radius;
        }

        Area() {
            return this.radius * Math.PI;
        }
    }
}
module AreaCalculator {
    "use strict";

    export class Square implements IShape {
        protected Height: number;

        constructor(Height: number) {
            this.Height = Height;
        }

        Area() {
            return this.Height * this.Height;
        }
    }
}
Ahora que tenemos las formas ya podemos implementar el calculador de área.
module AreaCalculator{
    "use strict";

    export class Calculator implements IShape {
        protected shapes: Array;

        constructor() {
            this.shapes = new Array();
        }

        AddShape(shape: IShape) {
            this.shapes.push(shape);
        }

        Area() {
            var area: number = 0;
            this.shapes.forEach(function (shape) {
                area += shape.Area();
            });

            return area;
        }
    }
}
Por último edito el fichero root/scripts/index.ts, que es el punto de entrada de la aplicación. Tenemos que añadir este fragmento de código a la función window.onload:
//Area Calculator
var calc = new AreaCalculator.Calculator();
calc.AddShape(new AreaCalculator.Circle(10));
calc.AddShape(new AreaCalculator.Square(20));
alert(calc.Area());
Esto me muestra un mensaje con el resultado de la suma del área de las dos formas que hemos añadido. Si nos creásemos una tercera forma como podría ser un triangulo no sería necesario modificar AreaCalculator, simplemente tendríamos que hacer que implemente IShape y ya podríamos sumar su area a la del resto de formas.

Hasta aquí el artículo de hoy, si no conocías TypeScript ahora ya tienes alguna noción. Recuerda que puedes seguir areaTIC en las redes sociales y cualquier comentario siempre es bienvenido. Hasta la próxima!

miércoles, 24 de febrero de 2016

Unit Testing in Javascript Visual Studio 2015

Hoy hablaremos de unit testing y veremos algunas herramientas que nos pueden ayudar en proyectos javascript. El articulo es un poco extenso se podría decir que os comparto mis apuntes sobre este tema y de paso explico como me lo he montado para implantar testing en proyectos javascript usando el IDE Visual Studio 2015. Antes de hablar de herramientas y ver ejemplos sobre como integrarlas en nuestros proyectos javascript me veo obligado a hablar de unit testing, consideraciones previas, beneficios, etc. Si ya conoces la teoría y quieres info sobre como integrar diferentes herramientas de unit testing para proyectos javascript en Visual Studio 2015. ves directo al caso práctico.

Un poco de teoría


El proposito que se persigue con unit testing es tener herramientas que testeen nuestra aplicación en busca de errores o comportamientos no deseados. Un test unitario consiste en testear las funcionalidades de una clase, objeto o componente. Generalmente todos en algun momento hemos trabajado en sitios y proyectos donde no hay testeo unitario. Es fácil (aunque cada vez menos) encontrarte escenarios donde se considere que el testing unitario es un coste que no aporta demasiado, que complica y hace encarecer el proyecto. La madurez y la experiencia de haber estado en proyectos que se han descontrolado me hacen dar la razón a todos aquellos defensores del unit testing y técnicas como TDD (Test driven development) o como BDD (Bevahiour Driven Development). En este post no entraré en detalle a explicar todas las técnicas de testing ni como aplicarlas en parte porque ya hay post y libros dedicados a estos escritos por la gente que realmente sabe de la materia...

Es fácil pensar en testing como un tiempo que inviertes al final del proyecto para automatizar tests de las funcionalidades importantes. Por norma general esto es un grave error. Es complicado implantar una solución de testing en un proyecto que no ha sido diseñado pensando en que todas las funciones de los objetos, clases y componentes han de ser testeables. Has de tener en cuenta que no podrás testear de manera eficiente y fácil un diseño acoplado donde unos objetos dependen de otros directamente, donde hay clases que no tienen un proposito claro, funciones que cubren más de una funcionalidad, etc.

Por tanto ya veis que pensar en una solución testeable te obliga a realizar un ejercicio previo a la implementación y tener claro el propósito de cada componente desde el inicio. Esto podría incrementar el coste inicial para desarrollar un proyecto, es evidente, pero en proyectos de largo recorrido evitarás que se descontrole y tengas un proyecto donde soluciones una cosa y se “rompan” otras siete. A nivel de costes no sólo acabarás recuperando la inversión inicial sino que está demostrado que acabarás ahorrando mucho en la fase de mantenimiento y evolución. Seguramente hayas oido hablar sobre TDD/BDD… estas técnicas consisten en implementar los test previo al desarrollo de los componentes (simplificando muchísimo). Por tanto tendremos tests que fallan y a medida que se desarrollan los componentes empezarán a superarse los test.

Qué beneficios te podrían aportar las técnicas:
  • Te asegura que sólo escribes código para cubrir las funcionalidades demandadas.
  • Te asegura que el código funciona correctamente y hace lo que esperamos que haga en todo momento.
  • Facilita el trabajo en equipo y el mantenimiento del código.

Ya para acabar con la teoría es importante hablar sobre como enfocar un test. Un test unitario sólo debe testear la lógica de un componente, por tanto, si el componente trabaja con datos de un servicio remoto se suele simular accesos al servicio usando mocks de modo que la comunicación con terceros e infrastuctura suele quedar fuera del ámbito de testeo unitario. Otro concepto que no hemos tocado es el coverage o cobertura de los test. Imagina que tienes una función con un if / else, los valores que le pasas al test hacen que siempre pase por el If y nunca por el else… En este caso habrás creado un unit test que aporta un 50 % de cobertura sobre esa funcionalidad.

¿Debo entonces optar por tdd o bdd, siempre debería buscar el 100 % de coverage?

Entiendo que no existe una verdad absoluta, podria interesarte una estrategia u otra en función del proyecto, equipo que participa, recursos, timmings, etc. Depende con quien hables te dirá que si tdd o bdd o que busca como objetivo un 70% de coverage, etc. Lo que nadie te dirá es que no cree en automatizaciones de test. Os dejo algunos hangouts interesantes donde referentes debaten sobre estos temas.

HangOuts

Testing javascript en Visual Studio 2015


Vamos ya con la parte práctica. Como comentábamos vamos a integrar una solución de testing unitario en un proyecto javascript (da igual si usas angular o react o jquery o javascript ‘nativo’) en tu IDE Visual Studio 2015..

Necesitaremos las siguientes herramientas:
  • Framework para desarrollar lost test unitarios: JasmineJS / Mocha / (…)
  • Herramienta que permita governar los test unitarios y se encargue de ejecutarlos-> Chutzpah / Karma / Protactor
  • Herramienta para determinar la cobertura de tus tests. -> Chutzpah / Instanbul / Karma-coverage
  • Gestor de tareas que permita automatizar la ejecución de test en procesos como una build. -> Grunt / Gulp.

Para ver estos ejemplos partiremos de un proyecto javascript de tipo Apache Cordova en Visual Studio 2015.. Si no tienes la template de cordova instalada puedes seguir los pasos en un proyecto web.

Ya veis que hay frameworks y opciones como para escoger. Como framework para crear los test usaré JasmineJS.

Como test runner me decanto por Chutpah dado que se integra bien con el IDE, permite ejecutar los test desde Test Explorer de Visual Studio, te facilita integración con herramientas de ALM Microsoft y es muy sencillo de configurar no hace falta gestor de tareas (grunt o gulp). Como alternativa valoro positivamente Karma. ProtactorJS no hace mala pinta pero se basa en Selenium y requiere instalar el jdk de java y como hay que decantarse por uno esto de momento haría que lo descarte en ámbito VS.

Os paso un par de videos de Channel9 que explican paso a paso como configurar Chutzpah y como configurar karma en Visual Studio 2015..

Respecto al video de Karma en mi caso, prefiero usar Grunt que también está soportado por Visual Studio. Ambos son automatizadores de tareas de ámbito cliente.

Otro tema que veo mejorable sobre como está planteado en el vídeo es que Karma lo hace correr en Chrome y por tanto siempre necesitas tener una ventana con el navegador abierto… esto se podría evitar con PhantomJS que veremos también.

Preparación del entorno, descarga paquetes y configuración


Karma:

Os recomiendo descargar este packete de nuget que ya añade a packages.json las dependencias que necesitaremos, crea los ficheros de configuración de Karma y grunt por nosotros y la carpeta donde ubicar los test del proyecto (podrías cambiar la ruta si lo deseas).

Chutzpah:

Has de seguir los pasos del video que consisten en instalar 2 extensiones, la configuración podría decirse que es más sencilla que el caso anterior debido a que no necesitas Grunt o Gulp.

Crear un compontente testeable


No seré original y usaré el clásico componente de una calculadora con 4 casos de uso muy marcados que son sumar, restar, multiplicar y dividir. Creo un nuevo archivo javascript y lo dejo en una carpeta [root]/services.
function Calculator() {

}

Calculator.prototype.Add = Add;
Calculator.prototype.Substract = Substract;
Calculator.prototype.Divide = Divide;
Calculator.prototype.Multiply = Multiply;

function Add(a, b) {
    return a + b;
}

function Substract(a, b) {
    return a - b;
}

function Divide(a, b) {
    return a / b;
}

function Multiply(a, b) {
    return a * b;
}

Crear test unitario


Ya podemos crear nuestro primer test para el componente calculadora. Creamos un nuevo archivo javascript en la carpeta DefaultTest que llamaremos CalculatorTest. Ahora entra en juego el primer framework de los que hemos descargado JasmineJS. Un test unitario para las 4 funcionalidades de la calculadora tendría esta pinta usando Jasmine:
describe("Calculator Test", function () { 
    var calculator;
    beforeEach(function () {
        calculator = new Calculator();
    });

    it("can add", function () {
        expect(calculator.Add(5, 5)).toEqual(10);
    });

    it("can substract", function () {
        expect(calculator.Substract(10, 5)).toEqual(5);
    });

    it("can divide", function () {
        expect(calculator.Divide(10, 2)).toEqual(5);
    });

    it("can multiply", function () {
        expect(calculator.Multiply(10, 5)).toEqual(50);
    });
});

Ejecutar los tests


Chuztpah se instala como una extensión de Visual Studio. Esta extensión añade un adaptador que busca archivos de test en la solución y los muestra en el test explorer de Visual Studio. Por tanto si instalas Chutzpa en tu Visual Studio podrías governar los tests también desde la herramienta de Visual Studio aunque uses Karma como test runner. Para activar el test Explorer has de ir a Test/Windows/Text Explorer de Visual Studio 2015.


En el caso de Karma podemos lanzarlo también desde el Task Run Explorer (View/Other Windows/Task Run Explorer) y veremos el resultado en el output console de javascript. Para ello nos vamos a Task Explorer, veremos las tareas configuradas en grunt o gulp y si pulsamos botón derecho sobre una podemos ejecutarla. En la pestaña Output veremos el resultado de la ejecución de los test.



Determinar el coverage de mis test


Karma:

Si os fijáis entre los packages que hemos descargado tenemos karma-coverage. Este paquete también conocido como istanbul nos permite generar un informe con la cobertura de los test. Para ello tendremos que configurarlo en karma.conf.js, al volver a ejectura un test veremos que nos genera un fichero html en la ruta que si lo abrimos con el navegador veremos tiene esta pinta.



Chutzpah:

Al instalar el la extensión Context menu extensión de Chutzpah podemos situarnos en el solution explorer y sobre la carpeta donde hemos creado los test unitarios pulsar botón derecho y seleccionamos la opción "Run Chutzpah with coverege".



Esto lanza los test de la solución y al finalizar abre en un ventana del explorador un informe de coverage que tiene esta pinta.



Hasta aquí el post de hoy de areaTIC, me ha gustado ver que el gran Visual Studio soporta bien la integración con herramientas de testing javascript.

lunes, 8 de febrero de 2016

asp net core y docker

Hace un tiempo estuve probando a ver si ya podía desarrollarla desde el mac con VsCode y no podía depurar asp.net desde el IDE así que lo dejé en stand-by. Este fin de semana he vuelto a la carga desde un equipo Windows para intentar hacer que mi api .net sea multiplataforma y los resultados son buenos.

En el post de hoy veremos como desarrollar una web api multiplataforma y también como publicarla en un contenedor docker en Azure (Linux). En primer lugar remarcar que estamos viendo cosas que todavía están por llegar oficialmente y puede ser que en poco tiempo cambien algunos de los pasos que describo a continuación. Para realizar el post, sobre todo para la publicación en docker me he apoyado en una serie de articulos que iré haciendo referencia.

Qué necesitas para hacer estas pruebas:
  • Visual Studio 2015
  • Cuenta en Azure (puedes obtener una subscripción temporal aquí).

Crear Api con Asp net core y Visual Studio 2015


En primer lugar en el asistente de nuevo proyecto en Visual Studio seleccionamos proyecto web de tipo asp.net y en la plantilla seleccionamos el vacío asp.net 5 (core). Por defecto si abres un proyecto asp.net con Visual Studio en Windows viene configurado para usar como host IIS Express (a Febrero 2016). Yo aquí me propongo hacer una api core “libre” de IIS, por tanto tenemos que despedirnos de IIS y el framework nativo. Para ello lo primero es eliminar todo resquicio de dnx 4.6 y IIS en el proyecto vacío de asp.net.

Propiedades del proyecto web:





Ves a project.json, elimina la configuración dnx46 de la sección frameworks y añade estas dependencias al proyecto:



El fichero project.json debería parecerse a este:
{
  "webroot": "wwwroot",
  "version": "1.0.0-*",

  "dependencies": {
    "System.Runtime": "4.0.20-beta-22816",
    "Microsoft.AspNet.Hosting": "1.0.0-beta5",
    "Microsoft.AspNet.Server.Kestrel": "1.0.0-beta5",
    "Microsoft.Framework.DependencyInjection": "1.0.0-beta5",
    "Microsoft.AspNet.Http.Extensions": "1.0.0-beta5",
    "Microsoft.AspNet.Http": "1.0.0-beta5",
    "Microsoft.AspNet.Server.WebListener": "1.0.0-beta5",
    "Microsoft.AspNet.Mvc": "6.0.0-beta5"
  },

  "commands": {
    "web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://localhost:5000",
    "kestrel": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.Kestrel --server.urls http://localhost:5001"
  },

  "frameworks": {
    "dnxcore50": { }
  },

  "publishExclude": [
    "node_modules",
    "bower_components",
    "**.xproj",
    "**.user",
    "**.vspscc"
  ],
  "exclude": [
    "wwwroot",
    "node_modules",
    "bower_components"
  ]
}

Tenemos el command web para ejecutar en local (windows) y kestrel para cuando publiquemos en Linux.

Por último, asegúrate que Startup.cs tiene esta pinta
public class Startup
{
   public Startup(IHostingEnvironment env)
   {

   }

   // This method gets called by a runtime.
   // Use this method to add services to the container
   public void ConfigureServices(IServiceCollection services)
   {
   }

   // Configure is called after ConfigureServices is called.
   public void Configure(IApplicationBuilder app, IHostingEnvironment env)
   {
      app.Run(async (context) =>
      {
          await context.Response.WriteAsync("Hello World!");
      });
    }
}    

Si todo ha ido bien ya tienes una aplicación web, multiplataforma, totalmente desacoplada de IIS y windows corriendo en dnx.



Ahora estaría bien que la aplicación haga algo más que decir hola mundo. Verás que no es complicado. Simplemente tenemos que añadir la siguiente dependencia al archivo project.json (si no la has añadido ya en el paso anterior):

"Microsoft.AspNet.Mvc": "6.0.0-beta5"

Modificamos startup.cs:
public void ConfigureServices(IServiceCollection services)
{
     services.AddMvc();
}

// Configure is called after ConfigureServices is called.
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
      app.UseMvc();
}
Por último creamos una carpeta controllers y dentro añadimos un archivo de tipo Web Api Controller. No lo edito, tal y como viene por defecto si compilas y vas a la url http://localhost:5000/api/values deberías ver el json de values.

Resumiendo hasta aquí, como ves el paquete mvc ya integra web api (antes eran paquetes separados) y ya no hay WebApiConfig ni necesidad de configurar rutas por defecto.

Publicar api en un contenedor Docker (Servicio en Azure)


En este post está bien explicado qué es Docker y el concepto DevOps en Español. Yo he seguido más o menos estos pasos para publicar. Os paso también un post de Hanselman al respecto.

Como se indica en los posts que hago referencia es necesario tener instalado el RC1 Update de Visual Studio y el cliente windows de docker.



Si ya tienes el RC1 ves a Extensions and Updates en Visual Studio y busca Docker:



Llegado este punto podemos crear la máquina virtual Ubuntu en Azure desde Visual Studio y gestionar las imagenes/contenedores donde correrán nuestras aplicaciones a través de docker.



Si todo va ok, si vas al portal de Azure o sino desde el panel de Azure en Visual Studio deberías ver la máquina.



Si te fijas verás que se han añadido una serie de archivos powerShell a tu proyecto que Visual Studio usará al publicar en la máquina que hemos configurado. Desde el asiente de publicación puedes validar la conexión al contenedor que acabas de crear en el paso anterior.



Al pulsar publish si todo va bien se publicará tu aplicación, puedes seguir los pasos de publicación en el panel de actividad de azure en Visual Studio.



Ya para acabar con el post, tras varios intentos fallidos esta fue mi expresión al conseguir publicar sin errores jajjajaja.



Bueno, espero que esto que comparto le sea útil a alguien. También podrías montar un docker en local y publicar contra este entorno, a mi me gustaría sacar tiempo para montarlo y así entrar con un poco más de detalle... Ahora ya puedo empezar a pasar mi api asp.net 4.5 y ver que soporta core y que no, por ejemplo tengo claro que de momento tendré que prescindir de funcionalidades SignalR. Otro punto que me tocará adaptar es como persistir la información porque mi api usar EF 6 code first y SQL Server que yo sepa todavía no corre en todas las plataformas ni está previsto que así sea. Como siempre espero ir sacando tiempo para publicar las pruebas de concepto, recordar que podéis seguir areaTIC en las redes sociales y colaborar en forma de comentarios, matices, aportaciones, insultos (sin pasarse) en definitiva feel free para participar!.

viernes, 5 de febrero de 2016

iOS Journey, UI en XCode

Hoy seguiremos con la serie de iOS journey que empecé a principios de año. En el post anterior tratamos un poco la sintaxi de Swift. La conclusión a la que llegué es que el lenguaje no es tan diferente a lo que estoy acostumbrado (C#, javascript, java..). En el siguiente enlace encontrarás un libro gratuito sobre Swift.

Hoy mostraré como trabajar con la UI y moverse un poco por XCode. Crearemos una aplicación vacía, añadiremos una escena, y arrastraremos 4 campos a las vista para ir viendo un poco.

En primer lugar una pequeña guía para moverse por Xcode, estos son los botones que te ayudarán a moverte por las secciones de Xcode que necesitamos ver en este mini tutorial.

Secciones principales de Xcode

Assistant editor: Divide la sección principal de Xcode diseño/código, de modo que muestra el código asociado a la pantalla en la que estamos situados.
Debug console: Muestra/Oculta la consola de depuración en la parte inferior de Xcode.
Project Navigator: Permite ver el arbol con los contenidos del proyecto.
Utility Panel: Muestra/Oculta el panel de utilidades. Dentro del panel de utilidades encontramos varias s


Apartados en Utility Panel

Identity Inspector: (sección superior) Permite modificar propiedades relacionadas con el objeto seleccionado en el story board.
Attribute Inspector: (sección superior) Permite modificar propiedades relacionadas con el objeto seleccionado en el story board.
Size Inspector: (sección superior) Permite modificar propiedades relacionadas con el objeto seleccionado en el story board.
Add File: (sección inferior) Permite añadir archivos al proyecto.
Object Library: (sección inferior) Set de componentes de UI que podemos arrastrar a los story boards.
En el post anterior ya comenté que el desarrollo iOS actual tiende hacía aplicar un pattern MVC. En iOS, tenemos los Story Boards que no dejan de ser un conjunto de escenas que representan el flujo que puede seguir el usuario cuando lanza tu aplicación. Por norma general una aplicación tiene un Story Board, pero podrías tener más de uno si la aplicación lo requiere. Por ejemplo la template de proyecto de XCode de saque viene con dos StoryBoards uno que se activa al ejecutar la aplicación (Launch) y otro para el contenido de la aplicación.

Al situarnos sobre un story board XCode nos muestra un canvas con las escenas. Sobre este editor podremos añadir nuevas escenas, añadir componentes a las escenas, controlar la navegación entre escenas…


Una escena generalmente está compuesta por una vista principal. Para añadir una escena a un Canvas has de pulsar en el botón Utility Panel para desplegar el panel de utilidades, localizar en la parte inferior el botón Object Library y arrastrar un ViewController al canvas (hay más tipos de controladores que ya veremos más adelante).



El siguiente paso será crear una clase que ejercerá el rol de controlador de la vista principal de la nueva escena que hemos creado. Vamos a File -> Add y seleccionamos un archivo de tipo File o CocoaTouchClass y lo editamos para que tenga el siguiente aspecto:
//
//  areaTICViewController.swift
//  iOS.journey
//
//  Created by Carlos Cañizares on 31/1/16.
//  Copyright © 2016 Carlos Cañizares. All rights reserved.
//

import UIKit

class areaTICViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view, typically from a nib.
    }

    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
        // Dispose of any resources that can be recreated.
    }


}

Para vincular la clase que acabamos de crear a la escena, hemos de situarnos en la escena y abrimos el identity panel. En el campo class informamos el nombre del controller que acabamos de crear.


El siguiente paso será situarnos en la vista y arrastrar desde el Object Library un label mismo… en el momento de arrastrar te pedirá introducir un texto por defecto.

¿Cómo podríamos interactuar con los componentes de la vista desde el controlador? La respuesta es creando un outlet. Siempre que necesitemos interactuar con un componente tendremos que previamente crear un outlet. Crearlo es sencillo, nos situamos en la vista y pulsamos en el botón Assistant Editor.

Esto hará que XCode muestre pantalla divida con la vista y con el código asociado (deberíamos ver el código controller que hemos creado). El siguiente paso es situarnos sobre el label, arrastrar con botón derecho al punto donde queremos definir el outlet en código (normalmente donde estén el resto de variables del controlador) y ya lo tendríamos.


Para modificar el valor del label una vez la vista haya cargado podríamos hacerlo del siguiente modo:

class areaTICViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view, typically from a nib.
    }
    @IBOutlet weak var MainLabel: UILabel!

    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
        // Dispose of any resources that can be recreated.
        
        MainLabel.text = "iOS Journey"
    }
}

Con esto ya podrías acceder a un objeto de la UI desde el controller. En este caso un label no tiene acciones como por ejemplo un botón… Si arrastramos un botón a la vista y luego repetimos el mismo proceso que hemos realizado para el Outlet veremos que tenemos más opciones en el contextual que aparece… podemos crear un Action que a diferencia del outlet se usa para subscribirnos a una acción del botón desde el controller.

Como prueba de concepto podríamos hacer que al pulsar el botón cambie el texto del label. Hasta aquí habríamos visto como empezar a trabajar con la UI, moverse por XCode y como asociar controladores a las vistas. Hasta aquí el articulo de hoy, recuerda que puedes seguir areaTIC en las principales redes sociales!

jueves, 28 de enero de 2016

Asp.net Web Api en Mac - VsCode - DNX - net Core

Hace unas semanas estuve probando a ver si se ya podía crear una web api con asp.net y Visual Studio Code alias VsCode en un mac y tras un rato de ponerme al día comparto las conclusiones.

¿Qué es VsCode?


IDE open source enfocado aplicaciones web y cloud disponible para Mac, Windows y Linux. Producto de la familia de Visual Studio. Soporta gran variedad de lenguajes, permite depurar javascript, intelisense.. Hay un set de extensiones y plugins considerable y a día de hoy ya es un producto interesante aunque el soporte concreto que yo busco en asp.net core todavía está en fase beta (ha cambiado el nombre de asp.net hace poco días de asp.net 5 a asp.net core).

Puedes desarrollar una web o web api y subirla a Azure con asp.net y net core pero están en modo preview y todavía no soporta depuración de asp.net. Sin embargo ya podrías depurar una aplicación de consola con net core y vscode. No creo que tarden demasiado dado que voy siguiendo las novedades y esto va como un tiro. También puedes hacer correr la web en local con kestrel. Si quieres montar el proyecto asp.net en Visual Studio Code y la instalación de Yeoman da problemas prueba a lanzar el comando con privilegios.
sudo npm install -g yo --allow-root
A raíz de esta incursión comparto algunas lecturas que me han ayudado a aclarar algunos conceptos y dudas sobre el futuro que nos depara a los desarrolladores que usamos frameworks de Microsoft.

¿Que es net core?


Es una versión “ligera”, basada en el .net framework de tipo open source promocionado por Microsoft.

¿Está net core basado en mono?


No, mono es una implementación también basada en .net framework, también open source pero promocionado por Xamarin. Por decirlo de algun modo vendrían a ser competencia (sana y colaborativa…)

¿Entonces para desarrollar proyectos c# en un mac con visual studio code tengo que usar Net Core?


No, también podrías usar mono con Visual Studio Code para desarrollar un proyecto C# en un mac o linux.

¿asp.net pasa a ser cross platform?


Sí, Microsoft abre net core y asp.net core como proyectos open source pero mantiene el framework nativo .net (el de toda la vida). Un proyecto asp.net core soporta o soportará ambos (y también mono). No tengo claro si .net core se alineará con el framework nativo, es decir, si podrás usar todas las clases y utilidades que dispones en nativo en multiplataforma o dependiendo del dispositivo donde corra no podrás usar según qué características (a día de hoy en mutiplataforma encontrarás limitaciones respecto a nativo). Entiendo que hay partes del .net framework que no se pasarán a core aunque no lo sé seguro. De echo tengo que confesar que este articulo lo escribí hace tres semanas y desde entonces han cambiado el nombre del producto asp.net 5 asp.net core así que hay que ver como evoluciona, lo mejor es seguir el github del proyecto.

¿Cómo es posible que un proyecto asp.net core pueda correr en nativo .net y en core (cross platform)?


Aquí entra en juego DNX. Resumiendo mucho, DNX es el nuevo entorno de ejecución de .net. El futuro enfoque del .net framework (tanto net core como “el clásico”) es que sea modular. En un fichero Project.json especificaremos los frameworks sobre los que puede correr la aplicación (dnxcore50, dnx451, …), las librerías que usamos de cada plataforma y sus dependencias. DNX tiene mecanismos para restaurar los paquetes vía nuget, gestionar sus dependencias y hacer la build del proyecto. (Dnu restore, dnx web..). Con esto se podrán hacer aplicaciones portables ya que DNX contiene el CLR. También resumiendo mucho, no será necesario instalar el framework en la máquina.

En estas páginas puedes encontrar más información sobre DNX, DNX Core…
Asp.net - choosing the right dot net
Asp.net - dnx overview
Simple Talk: What is DNX

¿Dónde podría obtener más info sobre la evolución de core y asp.net?


Puedes seguir el GitHub oficial de net core y asp.net.

¿Hay alguna página oficial donde se resuma todo de forma clara en una especie de tabla donde digan que características soportará cada framework, y sobre que plataformas puede correr?


No la he encontrado, posiblemente esté al caer. De momento si te has quedado con más ganas de leer te recomiendo echar un ojo a estos posts:

Oren Codes: Pcls net core dnx and uwp
Oren Codes: Desmitifying pcls net core dnx and uwp redux
Oren Codes: Targeting net core

Si aún tienes más ganas de leer, en msdn encontrarás información sobre uwp el cual no he mencionado en el post y ya es una realidad en Windows 10.

Hasta aquí el artículo de hoy, más y mejor en breve en areaTIC. Recuerda que puedes seguirnos en las redes sociales y participar en la medida que te apetezca (comentarios, propuesta de post, contenido..., etc). Que vaya bien!

martes, 5 de enero de 2016

iOS Journey, breve introducción a Swift

Hasta ahora en areaTIC hemos tocado muchos “palos”, desde consejos SEO, bases de datos, javascript, post relacionados con tecnologías Microsoft, algo de app’s crossplatfform con Phonegap, etc. Hace unos días que me he metido en desarrollo para IOS nativo, un tema que hasta ahora no habíamos tratado. El lenguaje de programación que sigue predominando es Objective-C, pero desde IOS 7 aparece Swift y apple lo está impulsando. En mi caso domino lenguajes de programación como C#, javascript, java y me cuesta acostumbrarme a la sintaxi de Objective-C sin embargo con Swift la cosa cambia.

Comentar que he quedado gratamente sorprendido con el desarrollo en IOS en general. A día de hoy se podría decir que no hay demasiada diferencia a nivel conceptual en como desarrollarías una aplicación para otras plataformas, verás que se tiende a usar el pattern MVC que es ampliamente conocido por la mayoría de desarrolladores.

Esta es una serie de artículos que hago para consolidar lo que he ido practicando estos días, que opino puede ser interesante y evitar algunas horas a aquellos que quieren iniciarse a desarrollar en esta plataforma. Iremos viendo lo típico… como es el lenguaje, como moverse por XCode, como trabajar con la UI, como navegar entre pantallas, como enlazar los controladores, como acceder a una api remota, algo de controles específicos que me llamen la atención de UI…

Introducción a Swift

Swift es un lenguaje de programación creado por apple que puede combinarse en un mismo proyecto con Objective-C. Hace pocos días apple ha anunciado que Swift pasa a ser open source. A continuación veremos muy por encima como realizar lo básico con Swift para hacernos una ligera idea de la sintaxi.

Constantes, Variables, Tipos

let constante:String = “A”
var variable:String = “B”
Usa constantes cuando no vayas a modificar el valor.

Funciones y Closures

Esta es la pinta que tienen las funciones.
func nombreFuncion()->Void{
      //haz algo…
}
func diHola(nombrePersona: String)-> String{
          return “Hola” + nombrePersona
}
Los closures vendrían a ser el simil de las expresiones lampdba en C#. Más info en apple developer

Protocol

Protocol vendría a ser una mezcla de lo que llamamos interface y clase abstracta en otros lenguajes de programación. Es importante dominarlo si quieres hacer un código decente.
protocol IBookingService{
   func Book()
}

class MyBookingService:IBookingService{

}
Este código no compila, recibiremos el siguiente mensaje: 'MyBookingService' does not conform to protocol 'IBookingService'. Para que compile necesitaríamos implementar la función Book() en MyBookingService. A diferencia de las interfaces en java o .net, los protocols permiten definir propiedades que están obligadas a implementar las clases que implementan el protocol. Otra diferencia es que los protocols no son instanciables en Swift.

Herencia, Polimorfismo y Casteos

Al igual que en otros lenguajes de programación puedes implementar herencias y poliformismo. Ahí un va un ejemplo:
class Vehiculo{
//…
 var color:String
 init(color: String){
   self.color = color
 }
}
    
class Coche{
 var diametroVolante:Int
 init(color: String, diametroVolante:Int){
     super.init(color)
     self. diametroVolante = diametroVolante
 }
}

class Moto{
 var medidaManillar:Int
 init(color: String, medidaManillar:Int){
     super.init(color)
     self.medidaManillar = medidaManillar
 }
}

var vehiculos [Vehiculo] = [Coche("Rojo",50),Coche("Azul",60),Moto("Verde",80)]
var coche = vehiculos[0] as Coche
print(coche.medidaManillar)
print(vehiculos[0].color)

Singleton

También puedes aplicar patterns populares, hay varios modos de crear un singleton, este valdría por ejemplo:
class SomeManager {
    static let sharedInstance = SomeManager()
}

//uso
SomeManager.sharedInstance
Bueno, creo que con este post os podéis hacer una ligera idea de la sintaxi de Swift y ya veis que tampoco es Klingon jajaja más o menos se entiende de un vistazo. Si dispones de un Mac con Xcode puedes abrir un proyecto de tipo PlayGround y como ya indica su nombre jugar un poco. Si no dispones de mac o quieres hacer alguna prueba rápida desde Windows podrías jugar online en este site.

El siguiente post empezaremos a ver como usar Swift en un Xcode para un proyecto IOS 9. Hasta la próxima, recordad que podéis seguir areaTIC en las redes sociales, no os cortéis a opinar!