Starting With Angular 2 Development

Starting With Angular 2 Development

If you just started with Angular 2 as I do and somewhat you also new in Javascript stacks, I’m sure we’re all confused about which approach that is more suitable for our project. After trying all (Yeoman) generators for Angular 2 from different developers, most of their stacks is almost suitable to my requirement, but unfortunately not 100% fit in. 😁

So what is my requirement?

  1. Initially I want to have full-stack application, but I finally decided that I want to separate Frontend and API project.
  2. I will host this application on Azure Web App Service and because this is a managed service, I don’t need to deal with setup the environment for deployment, no need to setup dedicated VM, just focus on development.

Where do I start?

For API project I don’t really mind whether I should use Node.js or ASP.NET Core. But again, since I don’t want to write everything from scratch, so I end up using LoopBack. LoopBack is more than sufficient to my scenario. So for the API part… it’s settled.

And here’s come the troublesome part, The Frontend part that using Angular 2. 😁

I’ve been using Angular 2 for couples of months now and in general, I’m pretty much like it. It was not the same impression I had when I was trying Angular 1. I like it because it feels familiar for those who already using Handlebars.js and TypeScript.

Forget the Generator!

Even though some of them gives you option to choose which stacks that you want to include in your project, but again, it feels like they put a lot of things inside whether you like it or not. So I recommend you to use angular-cli to generate your project. Wait, did I just read “generate”? Isn’t just another generator? Well, at least it’s official, meaning, whatever they put it there, it’s their recommended best practice.

Here’s some of my struggle before I discover angular-cli. Should I use Grunt or gulp? Should I use systemjs or webpack? Should I use TypeScript or Babel? This is all just matter of preference and angular-cli also comes up with their own “preference”. But the difference is, this is come from them as in “officially” recommended. 😊

To create Angular 2 project using angular-cli simply use this command:

ng serve

I’m using –style=scss options when creating this project since I want to use SCSS. More details about the command on this link:

Azure Web App Service Deployment

This is another pain in the *ss process, not because it’s hard, it’s because it takes time to figure it out the best practise to deploy our Angular 2 (generated by angular-cli) project to Azure.

I tested to wrap it on ASP.NET Core Application, but the continuous deployment process took longer time to satisfied dependencies for both stacks (Node.js and ASP.NET Core). This practise works when you’re deploying your application through Visual Studio IDE. Because all dependencies already satisfied in your development machine, and what you need to do it’s just publishing the project.

After spending two days of research and trial, I found out that the most convenient approach is to serve Angular 2 project using Express. Hold on, why would I serve my Angular 2 project using another “server”. Can I just use “ng serve”? Node application on Azure Web App Service is running on IIS and your application main entrance is server.js from your node-express app. The scenario would be different if you host your app in your own VM.

Let’s See The Recipe

To work with my scenario, I need to configure my project as follow:Generate Custom Deployment ScriptGenerate custom deployment script using azure-cli. Specifically for Node.js deployment, run this comment on your project root:

$ azure site deploymentscript --node

This command will generate two files: .deployment and (or deployment.cmd). We can ignore the first file, but we need to edit (or deployment.cmd) to include this line just after this line:

eval $NPM_CMD install --production

So the codes become:

eval $NPM_CMD install --production
eval $NPM_CMD run build:prodbuild:prod is a script in package.json that is basically run angular-cli equivalent to: ng build -prod

Deployment Configuration

This is one of the most important thing when developing Node.js app as Azure Web App Service. For most of the cases, we don’t need to create the custom web.config because KuduScript will generate default web.config for you based on default Node.js application template where the entry point to your application is the server.js file in your application project root. Here is what our custom web.config and server.js for Node.js application looks like:

<?xml version="1.0" encoding="utf-8"?>

    <webSocket enabled="false" />
      <!-- Indicates that the server.js file is a node.js site to be handled by the iisnode module -->
      <add name="iisnode" path="server.js" verb="*" modules="iisnode"/>

        <!-- Do not interfere with requests for node-inspector debugging -->
        <rule name="NodeInspector" patternSyntax="ECMAScript" stopProcessing="true">
          <match url="^server.js/debug[/]?" />

        <!-- Consider whether the incoming URL matches a physical file in the /public folder -->
        <rule name="StaticContent">
          <action type="Rewrite" url="public{REQUEST_URI}"/>

        <!-- All other URLs are mapped to the node.js site entry point -->
        <rule name="DynamicContent">
            <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="True"/>
          <action type="Rewrite" url="server.js"/>

    <!-- 'bin' directory has no special meaning in node.js and apps can be placed in it -->
          <remove segment="bin"/>

    <!-- Make sure error responses are left untouched -->
    <httpErrors existingResponse="PassThrough" />

var express = require('express'),
    path = require('path'),
    fs = require('fs');

var app = express();
var staticRoot = __dirname + '/'; // this is you app root

app.set('port', (process.env.PORT || 3000));
app.use(function(req, res, next){

    // if the request is not html then move along
    var accept = req.accepts('html', 'json', 'xml');
    if(accept !== 'html'){
        return next();

    // if the request has a '.' assume that it's for a file, move along
    var ext = path.extname(req.path);
    if (ext !== ''){
        return next();

    fs.createReadStream(staticRoot + 'index.html').pipe(res);

app.listen(app.get('port'), function() {
    console.log('app running on port', app.get('port'));

In my case I change the app root to ‘/wwwroot/’ instead of ‘/’. If you are using angular-cli default output folder, you need to change this to ‘/dist/’. You can configure angular-cli output folder in angular-cli.json file.

Azure App Service – Application Settings

Last but not least, we need to configure Azure Application Settings. After few times trial, for my scenario, this configuration is the one that successfully deployed my application.

I use Python version 2.7 (required for node-sass and node-gyp) and although it’s not relevant, I turned off PHP since I don’t use it and I turned on Web sockets.

This is the most important of the configuration steps, make sure we didn’t use old version of Node.js and in this case, I’m using version 6.5.0 to match my development machine.

For deployment process, I’m connecting my Visual Studio Team Services account to my Azure Account so everytime I have a git push to specific branch, the auto deployment will be triggered. If you guys interested to see how it’s done, write on comments below …

Happy Coding !!!


TeamCity – Continuous Integration for Everybody

TeamCity – Continuous Integration for Everybody

TeamCity - Continuous Integration for Everybody

TeamCity – Continuous Integration for Everybody

I’m writing this article in English, even my English is not that good :p. The main reason is because the audience of this article is supposed to be my colleague. I will write the article on my blog first to share with the world ^_^ and then I will copy the article to our company’s forum for our internal documentation. For several article ahead, we will discuss about how can we use a “Continuous Integration” system in to support our SDLC.

If you came from Java (Programming not Island :D), maybe you are familiar with Jenkins (Jenkins-CI). Both are similar tools, written in Java, and available for Linux, Windows and Mac OS X.But how does Continous Integration (CI) works? Here is the figure:

Continuous Integration - Summary of Steps

Continuous Integration – Summary of Steps

  1. Developers work to transform the requirements or stories into source code using the programming language of choice.
  2. They periodically check-in (commit) their work into a version control system (VCS)
  3. The CI server is polling the VCS for changes. It initiates the build process when it encounters a change. The build is executed using a dedicated tool for the job such as Maven, Ant or Rake etc. Depending upon the language used, the source code may need to be compiled.
  4. Static analysis is performed on the source code, to ensure compliance with coding standards and to avoid common causes of bugs.
  5. Automated unit tests are executed.
  6. The percentage of the production code exercised by the unit tests is measured using a coverage analysis tool.
  7. A binary artefact package is created. At this point we might want to assist derivation and provenence by including some additional metadata with the artefact e.g. a build timestamp, or the source code repository revision that was used to produce it.
  8. Prepare for functional testing by setting up the test fixtures. For example, create the development database schema and populate it with some data.
  9. Prepare for functional testing by provisioning a test environment and deploying the built artefact.
  10. Functional tests are executed. Post-execution, tear down any fixtures or environment established in 8 and 9.
  11. Generate reports to display the relevant metrics for the build. E.g. How many tests passed? What is the number and severity of coding standard violations?
  12. The process is continuous of course! So rinse…and repeat….

Source Article

For the next series of this tutorial, first of all we will define the scope by using real case example. Maybe not all of the step we’re implemented right now but most of them will done.

To Be Continued …

VideoBank | Video Management System

VideoBank | Video Management System

Akhir-akhir ini blog jadi kurang diperhatiin gara-gara sibuk research bikin Video Server. Dan setelah seluruh referensi terkumpul, dua hari kemaren istri dan anak sedikit dicuekin di rumah gara-gara melototin komputer terus. Alhasil, jadilah prototipe the next project after Restobiz.

VideoBank | Video Management System

Sesuai dengan judulnya, aplikasi ini dikembangkan untuk memanage koleksi video anda secara lokal. Lokal? tetep sih aplikasi ini jalan di Webserver, cuma maksudnya bisa dipake di jaringan internal seperti di kantor atau di perusahaan yang butuh menyimpan koleksi videonya.

Aplikasi ini dikembangkan dengan bahasa HTML, CSS dan PHP menggunakan Aptana IDE. Kedepannya akan digunakan juga database MySQL untuk fasilitas penyimpanan informasi video (rating, recomended video by viewers, etc.) serta penelusuran katalog.

Cara kerja prototipe aplikasi ini adalah mengupload video anda ke server, kemudian mengkonversi ke format FLV secara otomatis dan memberikan link untuk menonton video yang telah anda upload untuk dibagikan ke orang lain.

Untuk sementara format video yang didukung oleh aplikasi ini adalah: WMV, MPG, AVI dan FLV. Jika anda berminat untuk mendapatkan aplikasi ini, anda dapat menghubungi saya via email.