Saturday, April 18, 2015

Weekend Reader, Week 16

You Might Have Too Many Developers

An argument in favor of small teams and small incremental projects.

Why are we still talking about scaling agile with things like SAFe when the root problem is you might have too many developers?

There are no unicorns: forget about “better developers”, address organizational dysfunctions

(in response to the article above)

Size may be the symptom of organizational dysfunction.

It goes wrong when we try to make management easier by treating knowledge work as if it were physical work.

Industrial-age management is a really bad system for managing software development.

Sidenote: questioning the 10x developer productivity myth: The Leprechauns of Software Engineering, Fact and folklore in software engineering, StackExchange Question, Quora Question

Don’t use Microservices

As in my previous Weekend Reader, here is another article that has a good discussions about challenges and problems when trying to adopt microservices.

Classes: A bad Idea?

The next version of JavaScript (EcmaScript 6) will add classes to the language. Classes are available in many object-oritented languages, and most developers who learned object-orientation the traditional way (C++, Java, C#) might be wondering how object-orientation is even possible without classes.

However Douglas Crockford, the author of “JavaScript the Good Parts“, thinks that the introduction of classes in JavScript might not be a good idea:

Classes in EcmaScript 6 are gonna be a bad part. (direct link)
The gift of JavaScript to humanity is class-free object-oriented programming. (direct link)

In the “The Two Pillars of JavaScript” we get a similar opinion from Eric Elliott, the author of “Programming JavaScript Applications” who argues also against classes:

You never need classes in JavaScript, and I have never seen a situation where class is a better approach than the alternatives.

Angular Tidbits

Toptal has published some nice short videos, each describing a advanced concept of Angular. Perfect fill-ins for a short break.

A processor simulator written in JavaScript

Geeky. But never underestimate what you can do with JavaScript …


SwissJS 2015 (formely SwissJeese) is announced for July 18th 2015 in Bern. Last year the conference was my highlight of tech events. Make sure to get a ticket early, the first batch of “Blind Bird” tickets is already sold out …

SoCraTes Day
The first SoCraTes Day Switzerland takes place on Friday, June 19th in Zurich. This software craftsmanship conference is organized as an unconference, where the participants define the agenda on the day of the conference.

Funny Advertisement

Everybody complains about the ever more aggressive advertisement on YouTube, however if YouTube presents me advertisement like this, I gladly watch it to the end … and I then search for the clip on YouTube to watch it again:

Saturday, April 11, 2015

Weekend Reader, Week 15

Don’t use Microservices

The hype curve for microservices seems to have reached a plateau. The article suggests that a microservices architecture might not be a good fit for new (greefield) applications. Actually. there seem to be quite some reasons why not to use micorservices. I like the dicussion, however I think it’s not specific to microservices, but applies to any decoubled service-oriented architecture … any many failed SOA projects have probably suffered from the pitfalls described.

The Salary of Programmers

It was a topic already in my last weekend reader. This week we get more information about that topic from the Stackoverflow Developer Survey 2015. There are many interesting/surprising insights:
- Developers in the US are much better paid than in Western Europe
- Objective-C and Node.js development pays best.
- You should not be a Java developer if you are in it for the money.
- Developers who work remotely earn significantly more than non-remote workers (probably this is a symptom not a cause: good developers are hired for remote work)
- Mobile developers are more satisfied with their job than other developers.
- Product manager and quality assurance are among the least satisfying jobs

The Rise of TypeScript

The decision of the Angular team to build Angular 2 with TypeScript and to treat TypeScript as the best way to write Angular applications puts a lot of momentum behind the TypeScript language. With this step TypeScript will almost certainly leave its current Microsoft-centric niche and be more widely adopted among web developers.

JavaScript for Desktop Application Development

Many developers will cringe at that notion. But the “reuse-story” is actually compelling. For example with Angular, Atom Shell and Ionic you have a development stack that is applicable for Web, Desktop and Mobile.

More links for that topis:
- Atom Shell Starter (base application skeleton)
- Alternative: NW.js (formely known as node-webkit)
- The State of Desktop Applications in Node.js

There is Hope for Java

Traditional Java development has grown old and cumbersome compared with many other platforms/languages and it has a hard time keeping up with many current software developement trends.

But there is hope (ok the article series is already a year old):
- An Opinionated Guide to Modern Java Development, Part 1
- An Opinionated Guide to Modern Java Development, Part 2
- An Opinionated Guide to Modern Java Development, Part 3

On the same topic:
- Java Doesn’t Suck – You’re Just Using it Wrong

Geek Sarcasm: Could it be that programmers have been human all along?

An nice tale from Christin Gorman (watch her hilarious-all-time-highlight lightning talk) about a project far away from the idiocy of enterprise application development.

On the same topic:
- It Takes 6 Days to Change 1 Line of Code
- The story about Ashton from Joel Spolsky

And finally the wait is over:

I am especially curious about the upcoming season, since I stopped reading the series at book 4 (I wanted to wait until the end ... haha, that was 10 years ago) … will they even go further than the books?

Friday, April 3, 2015

Weekend Reader 14

Scrum Critics

Gilles Bowkett is quite provocative, but his points in Why Scrum Should Basically Just Die In A Fire are interesting:

Scrum covers up the inability to recruit (or even recognize) engineering talent, which is currently one of the most valuable things in the world, with a process for managing engineers as if they were cogs in a machine, all of equal value.

“Velocity” is really too stupid to examine in much further detail, because it very obviously disregards this whole notion of “working software as a measure of progress” in favor of completely unreliable numbers based on almost nothing.

Scrum gives you demeaning rituals to dumb down your work so that people who will never understand it can pretend to understand it. Meanwhile, work which is genuinely difficult to track doesn’t have to deal with this shit.

I don’t think that these critics are all inherently valid for Scrum, but I think they are valid for most adoptions of Scrum today. James Shore has blogged about the Decline and Fall of Agile several years ago:

These teams say they’re Agile, but they’re just planning (and replanning) frequently. Short cycles and the ability to re-plan are the benefit that Agile gives you. It’s the reward, not the method. These psuedo-Agile teams are having dessert every night and skipping their vegetables.

The Salary of Programmers

I find it hard to believe that there are “celebrity programmers” that make over $2 millon a year just for programming … But the Quora answers have are some interesting discussions about what drives the salary of a job on the market.

Anguar 2.0 is taking shape

The biggest news for me from ng-conf 2015 is that Angular 2 is developed in TypeScript, and that the suggested way to develop Angular 2 apps will be to use TypeScript. I guess this finally motivates me to learn this language …
To get an overview of whats coming and the design and motivation behind Angular 2 I suggest watching the Keynote from Misko Hevery. Angular 2 makes a much cleaner impression, neatly designed around some consistent concepts, compared to the organically grown first version of Angular.

Wat? - Geek Humor

The original WAT talk from Gary Bernhard is a classic. If you have not seen it, you should watch it now.

At ng-conf 2015 Shai Reznik did an adaption to Angular (the actual talk starts at 4:20):

The workforce crisis

According to that prediction the future for companies looks not so bright, the power-balance between workers and employers will shift. It will become a mayor issue for companies to attract and retain employees. As a freshly baked freelancer I think I should be happy about these predictions…

Frameworks as a recruiting investment

The article is primarily a rant about React and how the design of React is bad and that it is basically an unnessecary framework. Instead on investing on “proprietary” frameworks, we should focus on technologies that make the web better as a whole.

But the rant contains an interesting theory: Angular and React are actually a recruiting investment for Google respective Facebook:

So why release an open source Web framework at all? Because Facebook is battling Google for engineers. So you’ve got a big fight between two companies over which company is the coolest place to work, and both of them are companies that your grandparents love. How are you going to win this fight? One way is to have the hippest Web framework.

I find that theory very interesting, and it is one reasonable explanation why companies are investing in developing open-source frameworks.

Relay: Yet another Facebook framework

Speaking of companies releasing frameworks: After React and Flux and the announcement of React Native the next announced open-source framework out of Facebook is Relay.
Relay is an interesting proposition how to solve a classical “mash-up” problem: UI-elements and backend are inherently coupled, since the UI-elements render data that is provided by the backend. In a “componentized” UI the UI-elements should be decoupled from each other, so it is easy to add or remove elements from the UI. However with the traditional separation between frontend and backend, each change in the UI composition leads to changes in the backend, since the UI needs different data. Relay and GraphQL tries to solve the problem with a generic server that can serve any data requests and a protocol that allows UI-elements to delclare what data they need.
Looks intersting, however I am always afraid of generic solutions …

Versioning is Hard

I have been in many projects, where there were endless discussions about versioning and there was never a really satisfactory solution. I am relieved that it seems that there really is no good solution as the recent discussions about semver (semantic versioning) are showing:

Amazon vs. Google vs. Facebook vs. Apple

(via fime’s weekend reader)

An impresseive analysis of the leading four digital companies. A lot of information in 15 min, but if I understand the prediction correctly, we should not bet on Amazon and Google…

Friday, February 6, 2015

Weekend Reader 6

Agile Critics

The current state of agile is critizised by some more prominent figures:
Martin Fowler: Not Just Code Monkeys

Developers should not just be passive receivers of product backlog items. This is where most Agile transitions fail.

Dave Thomas: The Death of Agile
The first ten minutes are hilarious, where Dave is mocking the commercialisation of Scrum in the past and the new trend of selling “Enterprise Agile”.

Facebook announces React Native

With React Native Facebook invented yet another approach to program mobile applications in JavaScript. They promise to combine the best of native apps and the web. As far as I understood they use native components of iOS/Android (no HTML, no browser, no WebView), but they wrap them in JavaScript/JSX and use the JavaScript runtime on iOS/Android to orchestrate the application including the rendering. A very interesting approach …
However they are not chasing the “pipe dream of write once - run everywhere”. You will write apps dedicated for iOS or Android, however the programming environment will be the same. They call it “learn once, write anywhere”.

On a side note, the React Native presentation comes with a strong statement in favour of native app development and against web/hybrid mobile apps.

Yet Another JavaScript Framework with big Ambitions

Aurelia is a next generation JavaScript client framework, created by Rob Eisenberg, the creator of Durandal. Rob was for a short time part of the Angular team, but he changed his mind and decided to go his own way … the result is a modern framework that builds on ES6 and WebComponents. Sounds interesting, but sceptics might say:

The JavaScript ecosystem is broken

In the interesting article Generation Javascript the desolate state of the JavaScript ecosystem is revealed.

Not every week-end project should be made public and available through Bower. The Javascript community needs to learn to filter itself.

In the same direction goes: Why we should stop using Grunt & Gulp or my own post: Gulp is the Wild West

Client Side Templating: Good or Bad?

There has been some recent discussion about client side templating (like it is done by most modern JavaScript frameworks like Angular, Ember and also React):

The challenge was
- The problem with Angular
- Angular and templating

It reminded me of a debate from some years ago:
- Progressive Enhancement is Dead
- Progressive Enhancement: Still Not Dead,
- Progressive enhancement is faster

This time there was a very interesting reaction:
- Experimentally verified: “Why client-side templating is wrong” .
I like the conclusion that is backed up by data: For typical (line of business) web applications the advantages of the client-side rendering approach outweight the disadvantages by far. For public facing sites, where displaying initial content matters and functionality is only a second aspect, client-side rendering can be slower and optimizations with server-side rendering can be worth the effort.

You should start looking into ES6

ES6 will bring a lot of changes. JavaScript codebases will not look the same once ES6 catches on. Features like the arrow functions, template string and especially generators will change the face of JavaScript substantially.

The following videos give a good introduction to what is coming in ES6.

ES6 the future is now:

Netflix JavaScript Talks - Version 7: The Evolution of JavaScript:

To get started quickly with using ES6 now, this is a good tutorial: Javascript in 2015

Learning Promises

Promises in JavaScript are not the easiest concept to grasp. However due to the asynchronous nature of JavaScript they are a very important concept, that can and should have a major impact on the architecture and structure of JavaScript applications. I learned a lot from the following presentation: Promise-Based Architecture

Tuesday, February 3, 2015

Angular 2.0

When I am teaching my AngularJS workshops, there is usually a question about the future of AngularJS.

The Angular team announced Angular 2.0 at ng-conf Europe . There was quite some buzz after that announcement.

I think most of those reactions were premature. I am pretty sure there will be a sensible migration scenario from Angular 1.x to Angular 2. The Angular team at Google themselves will come up with a migration path as soon as Angular 2 will be better defined. And there is such a big community around Angular, that I am pretty confident that this migration will be pretty well supported and documented.

For current projects, I therefore recommend to use Angular 1.3. I would not wait for Angular 2.0, since it’s future is still pretty unclear and it will take a while until it is released. I would not recommend evaluating another framework just because of the announcement of Angular 2. As I said above, I strongly believe that there will be a viable migration path once Angular 2 is released. Also the concepts that build the fundamament of Angular (like databinding, directives, dependency-injection …) are not changing from Angular 1.x to 2. Therefore if a team learns to write Angular apps now with 1.3, this will be a good investment also for Angular 2.

I recommend to listen to episode 16 of Adventures in Angular for more information and assurance about the future of Angular and the topic of migration.

Saturday, January 3, 2015

My Year 2014

My year 2014 was interesting and brought many changes from a professional and personal perspective.

From the personal perspective …

I had two great vacations: I was literally beginning the year under water on a great dive trip in Raja Ampat. Diving with oceanic mantas was something I will never forget:

And my mountainbiking vacation in Colorado/Utah was another extraordinary experience:

However the probably much more profound event in my personal life came in October with the birth of our first child:

From the professional perspective …

I started to do much more teaching in 2014. My engagement at the Berner Fachhochschule was expanded and I am teaching a mayor part in the new CAS (Course of Advanced Studies) “Multiplatform Development with HTML5” and a smaller part in the CAS Mobile Application Development.

During the year I was giving quite a lot of inhouse courses for JavaScript development and AngularJS. These courses range from 1 day bootcamps to 4 day workshops. I held courses for UBS, BIT, Puzzle ITC, Glue, IMS AG, ESGroup and I could again give my JavaScript Bootcamp twice at the ch/open Workshoptage.

I enjoy working in the emerging space of “JavaScript as a serious application platform” so much, that I quit my job as a architect at my former employer. I am now working as a freelance developer and trainer with my own company.
The adoption of JavaScript in enterprise application development is the area I am currently focusing on.

In the typical educational institutions JavaScript is still pinned to the space of “Web-Design”. Apart from that there are almost no public courses to learn professional JavaScript development. Thats where I try to offer my inhouse courses: I specifically target typical enterprise environments and enterprise developers (Java or .NET) and I try to show the similarities between the modern JavaScript ecosystem and the traditional enterprise plaforms and also the pitfalls of JavaScript. I am offering courses for professional JavaScript development, for AngularJS, for React and for architecting modern html5 based frontends for enterprise systems. But I always tailor my courses to the specific needs of the individual team.

For the coming months I have already engagements for courses at Postfinance and at Mobiliar and I am looking forward to work with more teams. If you are interested in setting up a JavaScript/AngularJS/React course or coaching for a development team, please contact me.

There are also public courses scheduled, where I will be teaching:

Starting from April I will also be looking for opportunities to work hands-on in interesting projects. Of course my preference would be to work in projects where JavaScript and enterprise systems intersect.

Wednesday, December 31, 2014

Gulp is the Wild West

TL;DR This post described how I implemented asset processing with Gulp in a .NET project.

enter image description here

I am working on a .NET web application using Nancy in the backend and AngularJS in the frontend.
I decided to use a frontend-build based on Gulp. Frontend builds based on Grunt or Gulp have a lot of momentum right now, and this seems a better option for me than some .NET based tools like Cassette or SquishIt

By the way: if you have a node based frontend build you can run it on each Azure deployment like described here.

My requirements were the following:

  • For development the project should be runnable from VisualStudio without having to trigger a frontend build. That means that all the frontend assets have to be present at development time and referenced from my .cshtml files.
  • For release the frontend assets should be processed (concatenated, minified, revisioned …) by a frontend build. This build also needed to manipulate the .cshtml files, since they must reference the processed assets.

I started with gulp-usemin:

gulp.task("usemin", function() {
    return gulp.src("./Views/*.cshtml")
            js: [ngAnnotate(), uglify(), rev()]


This was nice and easy and worked well … until I had some more requirements …

The problem:
With gulp-usemin you have not access to the stream in a pipeline. So you are limited to list some tasks that should be performed. If you want to do something more fancy, you are out of luck. In my case I wanted to add the output of angular template cache to my main js file after it has been concatenated and minified…
In my case I wanted to append another JavaScript file that contains my angular templates (generated with gulp-angular-templatecache)

So I started looking for another solution… thats where I discovered that I am in the Wild Wild West: gulp-usemin2, gulp-spa, gulp-asset-transform, gulp-inject, gulp-rev-replace, gulp-useref, gulp-rev-all, gulp-rev-collector … all seem somehow to do something similar, documentation is minimalistic and you can waste a big amount of time to find the right plugin combination that works for you.

I ended up with the following combination of plugins:

var gulp = require("gulp");
var ngAnnotate = require("gulp-ng-annotate");
var templateCache = require("gulp-angular-templatecache");
var uglify = require("gulp-uglify");
var addsrc = require("gulp-add-src");
var concat = require("gulp-concat");
var rev = require("gulp-rev");
var minifyCSS = require("gulp-minify-css");
var useref = require("gulp-useref");
var filter = require("gulp-filter");
var revReplace = require("gulp-rev-replace");
var order = require("gulp-order");

gulp.task("angular-templates", function(){
    return gulp.src(TEMPLATES_SOURCES)
        .pipe(templateCache(TEMPLATES_JS, {module: "moonwalk", root: TEMPLATES_ROOT}))

gulp.task("release-assets", ["angular-templates"], function() {
    var assets = useref.assets();
    var jsFilter = filter("**/*.js");
    var moonwalkFilter = filter("**/" + MOONWALK_JS);
    var cssFilter = filter("**/*.css");

    return gulp.src("./Content/**/*.cshtml")
        .pipe(assets)               // Concatenate with gulp-useref
        .pipe(ngAnnotate())         // Process javascript sources to add dependency injection annotations
        .pipe(uglify())             // Minify javascript sources
        .pipe(minifyCSS())          // Minify CSS sources
        .pipe(moonwalkFilter)       // Filter the moonwalk.js source file, which is generated above by useref
        .pipe(addsrc("Temp/" + TEMPLATES_JS))// Add the templates.js to the stream, which is generated by a seperate task
        .pipe(order(["**/" + MOONWALK_JS, "*.js"]))// Order stream, so that templates.js is appended to moonwalk.js (needed, since templates depend on the angular module)
        .pipe(concat(MOONWALK_JS))// Concat the existing moonwalk.js and the templates.js into moonwalk.js
        .pipe(rev())                // Rename the concatenated files
        .pipe(useref())             // Replace the original references in the cshtml with the concatenated and processed resources by usemin
        .pipe(revReplace({replaceInExtensions:[".cshtml"]}))         // Replace the usemin generated resources with the reved resources

And by the way: This thread about running tasks synchronously is representative for Gulp (final verdict: “This will be fixed in gulp 4”) … welcome in the wild wild west!

Related Posts Plugin for WordPress, Blogger...