Monday, October 12, 2015

AngularJS + Karma - Loading JSON Files for Mocking HTTP Responses

In order to kick-off AngularJS projects, I have been looking at generator-gulp-angular lately, which you can find at:

When doing your unit tests, it is quite convenient to mock HTTP responses using JSON files. However, having your unit tests load additional (JSON) files may not be super obvious using the Karma test runner.


For the task at hand, I am using jasmine-jquery which provides “jQuery matchers and fixture loader for Jasmine framework”. Add that dependency to your bower.json file:

"devDependencies": {
  "jasmine-jquery": "2.1.1"


Now we need to do some additional configuration for Karma. By default, generator-gulp-angular wires the needed files up with:

return wiredep(wiredepOptions).js
    path.join(conf.paths.tmp, '/serve/app/index.module.js'),
    path.join(conf.paths.src, '/**/*.spec.js'),
    path.join(conf.paths.src, '/**/*.mock.js'),
    path.join(conf.paths.src, '/**/*.html'),
    {pattern: path.join(conf.paths.src, '../mocks/**/*.json'), watched: false, included: false, served: true}

In order to make your JSON file available, add

  pattern: path.join(conf.paths.src, '../mocks/**/*.json'),
  watched: false,
  included: false,
  served: true

So that it becomes:

return wiredep(wiredepOptions).js
    path.join(conf.paths.tmp, '/serve/app/index.module.js'),
    path.join(conf.paths.src, '/**/*.spec.js'),
    path.join(conf.paths.src, '/**/*.mock.js'),
    path.join(conf.paths.src, '/**/*.html'),
    {pattern: path.join(conf.paths.src, '../mocks/**/*.json'), watched: false, included: false, served: true}]);

Mocks is a directory in my project’s root folder. Customize as needed. For further details see:

Now, you're ready for testing. In your spec aka unit test file, in the beforeEach:

beforeEach(inject(function (_$httpBackend_, _$rootScope_, $controller) {

you can now mock up the $httpBackend:



Saturday, October 3, 2015

AngularJS Best Practices - Style Guide

Looks like the place du-jour for THE AngularJS style guide is here:

The author, John Papa, also provides the HotTowel Yeoman generator, that implements this style-guide:

If you're a TypeScript aficionado, you may want to keep an eye on the following GitHub issue:

In the meantime - checkout:

And all this came up, as I was looking, for some good explanation for the advice to use AngularJS’
“Controller as” syntax and to avoid $scope as much as possible.

A really good explanation is also here:

Friday, October 2, 2015

TypeScript versus ES6

A good question is: Why would you want to use TypeScript versus ES6?

A few reasons for me:

  • I have to use a transpiler anyway in order to support older browsers such as Babel
  • TypeScript gives me types
  • You can still use JavaScript as valid TypeScript (TS being a superset of JS)
  • It seems to be a more natural fit for Java developers
  • Tooling support seems pretty good
  • AngularJS 2.0 will use it natively - as such you have Google and Microsoft supporting it


Will ES6 make Typescript irrelevant?

TypeScript vs ECMAScript 2015/2016

TypeScript and ES6 Dan Wahlin & Andrew Connell

Angular Air Episode 25: TypeScript or ES6 with Babel?

Thursday, October 1, 2015

AngularJS 1.x and TypeScript

I did a bit of research today on TypeScript. As it is favored (but not required) for the upcoming AngularJS 2.0 release, I wanted to dig a bit deeper. Keep in mind that as of Oct 2015, AngularJS 2.0 is still a pure alpha version and even new projects shall continue using AngularJS 1.4.

Nonetheless, it looks like TypeScript is a viable option even for the latest 1.4 version. In fact, Yeoman now provides an Angular starter (generator-gulp-angular) that gives you the option to use TypeScript as your language of choice.

Here are some resources that I thought were helpful:

I believe, that particularly for Java Developers, TypeScript could be quite interesting - as you have much better type-safety compared to using plain JavaScript. See the following blog entry by Veit Weber:

Why Java Developers might love TypeScript

There is a good presentation by Sander Mak from JavaOne: "TypeScript for Java Developers: Coding JavaScript Without the Pain" on that subject as well:

A longer version:

As you can have a much better OO experience with TypeScript, I think it will be also quite interesting to use rich domain objects with AngularJS rather than using JSON structures directly when retrieving data from your REST endpoints.

There is a great presentation by Gert Hengeveld from NG-NL 2015.


Blog Post:

Convert JSON Structure to TypeScript Classes

If you create TypeScript classes that need to handle JSON, the follow online tool to generate TypeScript interfaces from JSON might be of interest:

TypeScript type definitions

I still need to wrap my head around TypeScript type definitions. They basically bolt on type definition for libraries that are not inherently based on TypeScript. There is a repository for them:

Monday, March 2, 2015

Still want to go to DevNexus 2015 (for free)? Room Volunteers Needed!

We are still looking for a few more room volunteers to help us with the monitoring and basic quality control of the breakout session rooms at DevNexus 2015 next week.

In total we need 24 volunteers (12 tracks x 2 days) for the 2 main conference days (March 11 and 12)  It will be first come, first serve - So please apply ASAP. We will be accepting room monitors from now and up until Thursday, March 5th.

The room monitor will be responsible for:

  • Getting a copy of the presentation slides from speakers right after each session
  • Making sure speakers don't go over their allotted time
  • Communication of any room related issues (power, sound , temp... etc).
  • Count the attendees in each session
  • Provide some feedback in regards to the observed sessions

A volunteer will be in charge of a single track room for one full day. Then s(he) will be free all day on the alternate conference day. For example, you monitor the Agile session room on Wednesday, then you are free to attend any session on Thursday.

Please contact info at ajug dot org if you are interested with the following info:

  • Day and Track
  • Alternative Day and Track 
  • Name
  • Email
  • Phone

Also, let us know if you have any further questions.


Saturday, January 10, 2015

DevNexus 2015 at BMW's Car Hackathon

Thanks to my colleague Sabby Anandan, DevNexus 2015 is getting some mentioning at BMW's Car Hackathon - Hack The Drive in San Francisco. The event takes place this weekend January 11-12.

Details at:

Here are some photos:

Thursday, January 8, 2015

DevNexus 2015 - Early Bird pricing ends Jan 9

The countdown for DEVNEXUS 2015 (Workshop day March 10, main conference March 11-12) is on! The AJUG team has been working hard to secure speakers, build the new event site and make this year's event the best one ever:

  • 3 days (1 workshop day and 2 conference days) 
  • 12 tracks 
  • 120 sessions 
  • expected attendance of 1500 

You can see the accepted list of speakers and sessions at

Please note that the Early Bird pricing ends this Friday Jan 9th!! So if you want to take advantage of the super low event price of $250 (other developer conferences of this scale cost $1000-$1800 to attend) then register this week.

Also don’t forget that we have a whole day of workshops on March 10th. This conference has sold out every year for the last 6 years so be sure to register now at:

A big THANK YOU to all of our sponsors that help make this event possible:






See you all in March!!!

Tuesday, December 2, 2014

Npm, Bower, CI and the Network

Ok, I accepted the reality that building single-page applications (SPA) is better done using the tooling options embraced by the JavaScript community, rather than building those apps using purely Gradle or Maven (and respective plugins). The reason being that building a complete web-UI is rather involved and tools like Yeoman, Grunt (Gulp) and Bower provide quite a bit of useful tooling while also having a much larger user-base than the (less complete) options in the Java world.

So life was good. Everything builds. Of course we still need to integrate the app with our backend that provides the REST endpoints. Personally, I prefer it that developers can build the entire stack at once. Also, can we assume that every (Java) developer has Node/Npm intalled?

Luckily, there are some plugins available for Maven and Gradle that provide useful wrappers around Npm and Node:
Thus, with some trial and error you get a fairly portable build (Linux, Mac and Windows) that not only executes the Grunt build but also downloads and installs Node and its dependencies, Grunt, Bower etc.

You think you finally arrived...Things run mostly okay on the continuous integration (CI) server...mmh, wait... "Mostly" is causing some headaches. This is actually an area where I have some frustrations lately. Looks like the Maven Central in the node world is a tad more volatile than Maven central itself.

In the Java world you have 2 layers of protection that ensure that the CI server build process is fairly resilient to internet hick-ups. Heck, it would even build off-line (assuming no library dependency changes were done). First, you have your local repository of course, which in the case of Maven is typically ${user.home}/.m2/

Second, any serious CI environment would also use a dedicated repository manager that serves as a proxy to the outside world, so that for already retrieved dependencies you would not need to hit Maven Central or other 3rd party repositories.

With NPM you all of a sudden realize you are a tad back into the wild west. Not only do you have to consider NPM (Managing tooling dependencies) but Bower (managing JS/CSS dependencies) as well.

NPM actually provides npm-cache - and you see dependencies being cached in your home directory under ~/.npm/. But try to disable your network card...the eternal spinner is yours. It does not even seem to timeout.

You can go offline - kind of - using “npm install --cache-min 9999999 --no-registry” but it does not seem to support things the way Maven/Gradle does: Check the cache first, and only if the dependency does not exist fetch it remotely. See also:

Another issue I encountered is with using Protractor for the E2E testing of my AngularJS application. You will usually use webdriver-manager to retrieve the necessary Selenium files/driver for your targeted Browser, e.g. Chrome. Since, I like to make the build as portable as possible, I do a post-install of the web-driver manager, which requires direct network access in package.json:

"scripts": {
  "postinstall": "node_modules/protractor/bin/webdriver-manager update"

Bower unfortunately, does its own caching approach which is configured in .bowerrc, e.g.:

"storage": {
"packages": ".bower_cache"

So what about using dedicated repository managers as proxy for NPM and Bower?

Artifactory provides support for NPM but not Bower. There is a feature request to support Bower in Artifactory, though. Nexus also has support for NPM. For Bower an open ticket exists.

Maybe people should start rallying behind web-jars more broadly ;-(

Monday, October 13, 2014

Digging Deeper - RequireJS and ES6 Modules

I was exploring RequireJS and ES6 Modules some more this weekend. Originally I started to explore how I can use richer domain objects (classes) as part of our AngularJS application that uses RequireJS for modularization. As part of that endeavor, using RequireJS looks like an interesting approach to inject classes into the application (Remember that AngularJS injects class instances ;-)

Here is a list of interesting resources that I came across.

RequireJS Basics

In order to get a refresher/introduction to RequireJS, I found Rob Dodson's RequireJS -- Embracing the Awesomeness of Asynchronous Modules quite nice:
Integrating AngularJS and RequireJS

Thomas Burleson's Angular and RequireJS from ng-conf 2014 was high on my consumption list. I think his explanation of how RequireJS relates to AngularJS was perfect.
I thought his code example was a tad on the complex side, though (Meaning I may need to revisit it ;-). For practical purposes, I then discovered Burke Holland's Requiring vs Browserifying Angular which I think is the nicest tutorial I came across:
The tutorial also underlines the point that using AngularJS and RequireJS is not for the faint of heart. It has its challenges. Maybe I need to look at Browserify?

One challenge I came across this morning for example,  is to make angular-masonry work with RequireJS. I was able to solve that challenge using this Stackoverflow posting:
Whats is coming with ES6 Modules

When looking at modules, it does not take long to come across ES6 Modules, the next hot thing coming our way as part of ECMAScript 6 (see Using ECMAScript 6 today)

First I watched Browser Package Management (by Guy Bedford):
He also has a nice blog post:

Another good video was Guy Bedford's talk: Package Management for ES6 Modules from JSConf2014:
What was interesting to learn, is that with SPDY, the bundling of web-resources won't be necessary anymore (eventually). See Multiplexing with SPDY and HTTP/2 for explanations:
So here is what is next for me...I need to look at the following projects and see how all this is usable today. Certainly looks fascinating being to use ES6 features right now, also keeping in mind that AngularJS 2.0 will use ES6 modules.

Monday, October 6, 2014

Java Template Engines Revisited Part 1

Over the past week, I spent some time looking at Java based template engines. Typically I need templating support for two areas:

  • View Templates (For rendering views in your browser)
  • Email Templates - with support for both HTML and Text emails

For email templates I had used the usual suspects such as Velocity and Freemarker in the past but both feel a tad heavy and old these days - Velocity's last release was in 2010! Eventually I settled for a simpler option a while back: StringTemplate, which as a library worked fairly okay.

As I had done some client-side templating using Mustache and Handlebars, I was intrigued in seeing Java implementations for both:

The nice thing about Mustache is that implementations are available for almost any programming language imaginable, which could be nice in case you have the need to maintain browser-bound and backend (Java) templates or in case you have multiple Java and non-Java application with templating needs.

For now I have chosen Looks like it is heavily used at Twitter. Depending on how willing you are towards enduring any type of logic in your templates, you may also want to check out Handlebars and the corresponding Java implementation. It is basically a super-set of Mustache, providing additional built-in helpers.

Lastly, for both Mustache and Handlebars there is support available for Spring MVC.

I have not used either support for Spring MVC, yet, though. In case you have used any of the mentioned options, please leave feedback to this blog.