Timo Korinth

2 Meter, 2 Mark

25.02.2015
by Timo Korinth
0 comments

Don’t Be Afraid of the Dark (AngularJS)

BASTA_SE_15_Speakerbutton

If you talk to other (.NET) developers and confess that you are doing HTML5, JavaScript and AngularJS development more than .NET and WPF by now, you’ll earn laughter and compassion. But why is that and what can we do about this? In my Session on the BASTA! Spring (26.02. @17:30h) I’ll try to answer these questions from my own experience as a former .NET developer. The one thing I can say is: Don’t be afraid of HTML5, JavaScript and Co.
I’m looking forward to see you there.
UPDATE:
Download my Flexbox demo project here: AngularJS Flexbox Demo

06.12.2014
by Timo Korinth
0 comments

UI-Framework in AngularJS

GUIDesignLogo

Next week (09. – 10. Dec) I will talk about my thoughts on an UI-Framework written for AngularJS on the GUI & Design Conference in Berlin. Based on my recent work in some huge AngularJS projects I created a structure for controls and containers which can be used to implement a custom UI-Framework based on directives and styles. What a UI-Framework is an how it can help you develop and maintain huge software products is the main goal of my session. Hope to see you there.

UPDATE:

Take a look at my slides: UI Framework AngularJS (in german)

22.09.2014
by Timo Korinth
0 comments

See you on BASTA! 2014

Today the BASTA! 2014 starts and we from MAXIMAGO will be there the whole week. If you would like to try the new Oculus DK2 or talk about UX, WPF, HTML5, JavaScript development, meet us at the MAXIMAGO stand.

Beside this, on Wednesday and Thursday I’ll talk about Cross-platform development and Control development in WPF and HTML5 (AngularJS):

I’m looking forward to meet you there ;-)
BASTA! Herbst 2014 Speakerbutton 1

15.04.2014
by Timo Korinth
0 comments

Understanding routing in Ember.js

One of the first things you will come across in Ember development is the routing mechanism. If’ve had a hard time figuring out the concept and differences to other routing approaches until I really understand the benefits of the Ember routing provider. To help you getting started with Ember development, I got some key insights to share with you:

  1. The overall concept is Convention over Configuration
    • That also means that Ember will generate classes (e.g. Controller, Routes etc…) for you, if you do not explicitly define them. That is especially true if you define routes: If you just specify the route name, Ember will automatically create an appropriate route, controller and (empty) template for you. To override the default behavior, you can create one of these objects (creating subclasses) and hook up your own code.
  2. Think of routes as application states
    • It is important that you fully understand the whole concept of ember routing. The main goal (in contrast to many other routing frameworks) is to define application states and make them additionally available through a URL.
    • Route = State + URL
  3. Use of nested routes
    • You can’t nest routes but resources. The important thing: A route nested under a resource will get (by convention) the name of its parent resource + its own name. BUT a resource nested under a resource will just get its own name.

To clarify the last point, here’s an example. Take this route / resource structure:

this.resource('IdentityManagement', function () {
    this.resource('Identities', function () {

        this.resource('Identity', { path: '/:id' }, function () {
            this.route("Edit");
        });
        this.route("New");

        this.resource('Visitors', function () {
            this.resource('Identity', { path: '/:id' }, function () {
                this.route("Edit");
            });
            this.route("New");
        });

        this.resource('Void', function () {
            this.resource('Identity', { path: '/:id' }, function () {
                this.route("Edit");
            });
            this.route("New");
        });

        this.resource('SalesTeam', function () {
            this.resource('Identity', { path: '/:id' }, function () {
                this.route("Edit");
            });
            this.route("New");
        });
    });
});

This structure will lead to the following routes (a subset of all routes that will be implicitly be created by Ember):

App.IdentityManagementRoute = Ember.Route.extend({
    model: function (param) {
        return App.Contact.find();
    }
});

App.IdentitiesRoute = Ember.Route.extend({
    model: function (param) {
        return App.Contact.find();
    }
});

App.VoidRoute = Ember.Route.extend({
    model: function (param) {
        return App.Contact.find();
    }
});

App.IdentityEditRoute = Ember.Route.extend({
    model: function (param) {
        return App.Contact.find();
    }
});

29.03.2014
by Timo Korinth
0 comments

Change WebAPI REST output format from XML to JSON

The default output format of a WebAPI webservice is XML. To change this to JSON format, you have to manually remove the media type “application/xml” from the configuration of the supported media types. Otherwise it will always use the default xml media output format.

Default xml service output:

<ArrayOfContact xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/Siemens.SiveillanceShellServer.Model">
<Contact>
<Id>1</Id>
<Name>Timo Korinth</Name>
</Contact>
<Contact>
<Id>2</Id>
<Name>Han Solo</Name>
</Contact>
<Contact>
</ArrayOfContact>

JSON output format:

[{"Id":1,"Name":"Timo Korinth"},{"Id":2,"Name":"Han Solo"}]

To change this, add these two lines to your server configuration:

var appXmlType = config.Formatters.XmlFormatter.SupportedMediaTypes.FirstOrDefault(t => t.MediaType == "application/xml");
config.Formatters.XmlFormatter.SupportedMediaTypes.Remove(appXmlType);

The complete server code could look like this:

class Program
{
    static readonly Uri _baseAddress = new Uri("http://localhost:60064/");
 
    static void Main(string[] args)
    {
        // Set up server configuration
        HttpSelfHostConfiguration config = new HttpSelfHostConfiguration(_baseAddress);
 
        config.Routes.MapHttpRoute(
            name: "DefaultApi",
            routeTemplate: "api/{controller}/{id}",
            defaults: new { id = RouteParameter.Optional }
        );
 
        var appXmlType = config.Formatters.XmlFormatter.SupportedMediaTypes.FirstOrDefault(t => t.MediaType == "application/xml");
        config.Formatters.XmlFormatter.SupportedMediaTypes.Remove(appXmlType);
 
        // Create server
        var server = new HttpSelfHostServer(config);
 
        // Start listening
        server.OpenAsync().Wait();
        Console.WriteLine("Web API Self hosted on " + _baseAddress + " Hit ENTER to exit...");
        Console.ReadLine();
        server.CloseAsync().Wait();
    }
}

15.02.2014
by Timo Korinth
0 comments

Build a WebAPI Self-hosting server

If you don’t want to host your WebAPI services in an IIS Webserver, you can create your own small webserver and run it without installation of any 3rd party applications.

To demonstrate this, you should create a new Console Application first:

NewConsoleApplicationSelfHostServer

On the next step you have to install a set of additional assemblies. To simplify this task, you can search for the NuGet package “Microsoft WebAPI Self Host” on the NuGet Package Manager and install it:

NuGetPackageWebAPISelfHost1NuGetPackageWebAPISelfHost2

All you have to do now is to write a few lines of code and start your console application to get a fully functional webserver for your WebAPI services up and running:

class Program
{
    static readonly Uri _baseAddress = new Uri("http://localhost:60064/");

    static void Main(string[] args)
    {
        // Set up server configuration
        HttpSelfHostConfiguration config = new HttpSelfHostConfiguration(_baseAddress);

        config.Routes.MapHttpRoute(
            name: "DefaultApi",
            routeTemplate: "api/{controller}/{id}",
            defaults: new { id = RouteParameter.Optional }
        );

        // Create server
        var server = new HttpSelfHostServer(config);

        // Start listening
        server.OpenAsync().Wait();
        Console.WriteLine("Web API Self hosted on " + _baseAddress + " Hit ENTER to exit...");
        Console.ReadLine();
        server.CloseAsync().Wait();
    }
}

ATTENTION: Be sure to start your Visual Studio (or the .exe application) as Administrator. Otherwise it can’t register the appropriate services for you and your webserver will not work!

21.01.2014
by Timo Korinth
0 comments

Toolchain in HTML5

In der modernen Webentwicklung kommt es mehr denn je darauf an, gut verzahnte Tools zu haben, die sich automatisiert und zuverlässig um alle wiederkehrenden Aufgaben kümmern. In der schnelllebigen Welt der JavaScript-Entwicklung entstehen neue Frameworks fast im Minutentakt und doch kristallisieren sich einige Tools aus diesem fast unerschöpflichen Universum heraus, die nach und nach zu einem De facto Standard in der Webentwicklung werden. Diese Kombination von verschiedenen Tools und deren Integration in den Build Prozess möchte ich hier kurz vorstellen.

Build Prozess

Manch ein Leser wird sich jetzt vielleicht fragen, wofür ein Webentwickler überhaupt Build-Tools benötigt. HTML und JavaScript müssen schließlich nicht kompiliert oder umgewandelt werden und können direkt im Browser laufen. Generell ist das auch richtig. Allerdings gehe ich nicht von typischer Website-Entwicklung aus, wenn ich von Webentwicklung spreche, sondern viel mehr von moderner Single-Page-App-Entwicklung. Mehr noch: Ich spreche von komplexen Business Anwendungen, die im Browser laufen und sich möglichst wie Desktop Applikationen anfühlen sollen.

Diese Anwendungen können schnell sehr komplex werden. Aus diesem Grund muss eine saubere Code-Struktur geschaffen werden, die skalierbar ist und auch in großen Projekten eine übersichtliche und wartbare Entwicklung erlaubt.

Ausgehend von dieser Definition können folgende Anforderungen an einen Build Prozess abgeleitet werden:

  • Integration in ein sicheres Versionskontrollsystem
  • Automatisiertes Auflösen von Abhängigkeiten
  • Automatisiertes Zusammenfassen von Source Code
  • Automatisiertes Deployment

Tools

Um den oben beschrieben Prozess sauber abbilden zu können, sind mehrere Tools notwendig, die jeweils ihre dedizierten Funktionen haben und in dem gesamten Prozess zusammenarbeiten. Diese Tools und ihre Integration haben sich in vielen Projekten bewährt:

  • Git
  • Node.js / NPM
  • Bower
  • Grunt
  • Git

In den letzten Jahren hat das Versionskontrollsystem Git mehr und mehr Einzug in Entwicklungsprojekte gehalten. Das liegt wohl auch an der kompromisslosen Ausrichtung auf dezentral arbeitende Entwickler und der Fokus auf verteiltes Arbeiten. So ist beispielsweise das Konzept von mehreren, parallelen Branches („Entwicklungszweigen“) fester Bestandteil von Git und unterstützt das parallele Entwickeln an der gleichen Code Basis.

Wir sind vor einiger Zeit für HTML5-/JS-Projekte von Microsofts Versionskontrollsystem TFS (Team Foundation Server) erfolgreich auf Git umgestiegen. Für uns hatte das u.a. folgende primären Gründe:

  • Der TFS hat Probleme mit Pfadnamen länger als 255 Zeichen. In der Webentwicklung kann es aber vorkommen, dass diese Grenze schnell erreicht ist, gerade wenn noch zusätzliche Pakete nachgeladen werden (die wiederrum abhängige Pakete nachladen usw…).
  • Der TFS bietet keine (oder nur sehr eingeschränkte) Möglichkeiten offline zu arbeiten. Mit Git hat jeder Entwickler sein eigenes lokales Repository, egal ob er offline, unterwegs arbeitet oder im Firmennetz ist.
  • Der TFS ist sehr stark an Microsofts IDE Visual Studio gebunden und lebt von der Integration in den Editor. Wir wollten uns allerdings die Unabhängigkeit bei der Auswahl der IDE bewahren.
  • Andere Build Tools, wie beispielsweise der Build Server „Jenkins“, arbeiten problemlos mit Git zusammen und bieten dafür zahlreiche Plugins an. Die Integration mit dem TFS ist, wenn überhaupt, meist weitaus schwieriger zu erreichen.

Node.js und NPM

Node.js ist eine Plattform basierend auf der V8 JavaScript-Laufzeitumgebung und wurde entwickelt, um schnelle und ressourcensparende Netzwerkanwendungen wie Webserver zu entwickeln. Node.js bietet darüber hinaus diverse Module und eine API, um eigene Anwendungen (Module) zu entwickeln.

Diese Module können über den zentralen Paketmanager NPM (Node packaged modules) bereitgestellt und bezogen werden. Die meisten aktuellen Tools zur Webentwicklung basieren bereits auf Node.js und stehen daher als Module über NPM zur Verfügung.

Das bietet den entscheidenden Vorteil, dass Node.js als einziges Tool auf einem Entwicklerrechner vorinstalliert sein muss und alle anderen notwendigen Anwendungen nachträglich über NPM nachgeladen werden können. Zusätzlich können verschiedene Webprojekte gleichzeitig andere Tools (oder sogar verschiedene Versionen der gleichen Tools) verwenden, da pro Projekt eine Liste mit abhängigen Anwendungen erstellt und zu jedem Zeitpunkt im Projekt nachgeladen werden können. Diese Anwendungen werden dann nur lokal in dem jeweiligen Projekt installiert und verwendet.

Über NPM werden typischerweise die folgenden zwei Anwendungen installiert: Bower und Grunt.

Bower

Wenn NPM ein Paketmanager für Anwendungen oder Module basierend auf Node.js ist, dann ist Bower ein Paketmanager für Webprojekte. Webprojekte können beispielsweise UI Frameworks wie Twitter Bootstrap (CSS Framework) oder Sammlungen von Schriften sein, aber in den meisten Fällen handelt es sich um JavaScript-Frameworks oder -Libraries.

Über Bower können die abhängigen Webprojekte (in spezifischen Versionen) definiert und über den Bower Paketmanager nachgeladen werden. Diese werden dann wiederrum von den registrierten GitHub Seiten in der jeweils spezifizierten Version automatisiert heruntergeladen und im eigenen Projekt entpackt.

Typischerweise werden so alle abhängigen Libraries wie beispielsweise AngularJS, Twitter Bootstrap oder auch jQuery in das eigene Projekt integriert. Ähnlich wie bei der Verwendung von NPM bietet Bower damit den Vorteil, dass nur eine Konfigurationsdatei mit den abhängigen Libraries gepflegt werden muss. Das Initiale Herunterladen oder Aktualisieren der Pakete in den richtigen Versionen wird dann automatisch durch Bower durchgeführt.

Grunt

Grunt ist ein Command-line Tool zur automatisierten Ausführung von Tasks und basiert ebenfalls auf Node.js und NPM. Grunt ist das Herzstück des Build Prozesses und kümmert sich um alle automatisierten, wiederkehrenden Aufgaben.

Über NPM sind unzählige Grunt-Tasks für die verschiedensten Anforderungen verfügbar. Zu den typischen Build Tasks zählen u.a. folgende Aufgaben, die automatisiert bei jedem Build ausgeführt werden:

  • Zusammenführen aller JavaScript-Dateien zu einer großen JavaScript-Datei
  • Komprimieren der JavaScript-Dateien (Minifying)
  • JavaScript-Dateien unleserlich machen (Uglifying)
  • Code-Qualität prüfen
  • Unit Tests ausführen
  • Less-Dateien in CSS Stylesheets kompilieren
  • Kopieren der Ergebnisse in die entsprechenden Build-Verzeichnisse
  • U.v.m…

Während Node.js, NPM und Bower nach dem Initialen Aufsetzen des Projektes nur noch selten genutzt werden müssen, ist Grunt das alltägliche (Build-)Tool für jeden Webentwickler.

Originally posted on: http://channel.maximago.de/node/19