Continuous delivery is a software development practice in which a team or a company strives to keep their software in a deliverable state at all times. Closely related is continuous deployment, in which the software itself is actually released to production as often as possible. Continuous delivery is a prerequisite to continuous deployment. From a business point of view, continuous delivery allows a company to quickly adapt to changing market developments, respond to user feedback, etcetera. However, what is in my opinion a much stronger argument in favor of CD is that it enforces a large number of software development practices; it’s a core principle which can be referred to when making decisions about the practice of software development, ranging from how version control is handled, test and release automation, etcetera.

In this post I’ll go into the software development practice of version control, and discuss a number of strategies in the context of continuous delivery.

Read more →

Not too long ago, we ran into an apparent security issue at my current assignment – people could sign in with a regular account, but get the authentication and permissions of an administrator user (a privilege escalation bug). As it turned out, the impact  of the security issue was low, as the user would need to be logged in as an admin user already, but it was a very confusing issue. In this post I’ll try and explain the situation, how browsers handle wildcard subdomain cookies, and what to keep in mind when building an authentication back-end when it comes to cookies storing session information.

Read more →

When building an Angular application, we usually stick to the suggested or auto-generated solution of unit testing; the Karma test runner and server, the Jasmine testing framework, and PhantomJS as the environment to run it all in.

In this blog post I’ll explain how this is rather silly, and will provide an alternative and lightweight approach to writing and running unit tests. It will depend on having a certain way of defining your Angular components, and may not be a full 1:1 drop-in replacement, but I can say with a certainty that it’ll make your tests faster, the overhead of running them a lot smaller, and improve the quality of tests by having less to worry about.

Read more →

Every self-respecting iOS developer should know about PaintCode by now, an OSX app for drawing graphics that don’t save as images, but as lengths of code that draw graphics. The benefits of this are vastly reduced app installation size – no need to include three resolutions of the same image for every image – and seamlessly scalable graphics.

One thing that I personally struggled with for a while now was how to use them effectively in combination with Interface Builder, the UI development tool for iOS and OSX apps. In this blog I will explain an effective and simple method to draw PaintCode graphics in a way where you can see what you’re doing in Interface Builder, using the relatively new @IBDesignable annotation. I will also go into setting colors, and finally about how to deal with views that depend on dynamic runtime data to draw themselves.

Read more →

There was an article on Techcrunch a couple days ago which was linked in our internal mailing list the other day, titled The Rise And Fall Of The Full Stack Developer. I read it, and I just couldn’t figure out why the title is about “the fall” of the full-stack developer (and I said as much on the mailing list, after which I was encouraged to write this blog post). In this post I’ll try and explain why it’s not the end, but just a stage in a recurring cycle

Read more →

As promised in my previous post, I just pushed the first version of our “Angular Promise DSL” to Github. It extends AngularJS’s $q promises with a number of helpful methods to create cleaner applications.

The project is a V1, it may be a bit rough around the edges in terms of practical applicability and documentation, but that’s why it’s open source now.

The repository is at https://github.com/fwielstra/ngPromiseDsl and licensed as MIT. It’s the first OS project I’ve created, so bear with me. I am accepting pull requests and issues, of course.

Questions? Ask them on the issues page, ask me via Twitter (@frwielstra) or send me an e-mail. I’d offer you to come by my office too… if I had one.

Many large Angular applications tend to see a lot of repetition – same API endpoint, same method of dealing with and transforming data, etcetera. One technique you can use to at least alleviate that is using AngularJS’s decorate method, which allows you to extend, adjust or even fully replace any existing service.

As you’ll see in this post, using this allows you to modify and extend the framework you build your app in, which will lead to a cleaner, more legible codebase, written in a more functional style (the what, not the how).

Update 11/8: The follow-up is now live, along with the GitHub repository.

Read more →

The traditional way to deal with asynchronous tasks in Javascript are callbacks; call a method, give it a function reference to execute once that method is done.

$.get('api/gizmo/42', function(gizmo) {
  console.log(gizmo); // or whatever
});

This is pretty neat, but, it has some drawbacks; for one, combining or chaining multiple asynchronous processes is tricky; it either leads to a lot of boilerplate code, or what’s known as callback hell (nesting callbacks and calls in each other):

$.get('api/gizmo/42', function(gizmo) {
  $.get('api/foobars/' + gizmo, function(foobar) {
    $.get('api/barbaz/' + foobar, function(bazbar) {
      doSomethingWith(gizmo, foobar, bazbar);
    }, errorCallback);
  }, errorCallback);
}, errorCallback);

You get the idea. In Javascript however, there is an alternative to dealing with asynchronous code: Futures, although in Javascript they’re often referred to as Promises. The CommonJS standards committee has released a spec that defines this API called Promises.

Read more →

It should be common knowledge that for certain types of automated tests, you do not want to rely on the availability of external services for a number of reasons:

• Uptime of said service (your tests fail if the service is unavailable)
• Dynamic nature of the data (makes your assertions harder)
• Execution speed of your tests
• Excess load generated on the service
• etc

Ideally, you therefore stub out the external service. Inside your unit tests, you do that using Mock Objects, for example. This is actually harder to do for integration tests – you do not use mock objects in integration tests, because that could change the observed behavior of your application.

In one of our projects, we’ve struggled with this problem for quite some time. There are two major components in it, an iPhone app and a server-side component, which both talk to an external webservice for retrieving the data to display on the app and to work with on the server. In our integration tests, we simply used the production webservice and ran some shallow assertions on the result with varying results.

Recently though, we drew the line. Running integration / UI tests using KIF for iOS on data that changes depending on what time it is ended up in unpredictable results, or assertions that we simply couldn’t make because the data kept changing (and of course because KIF does not have any actual assertions, or is able to match on partially matching UI elements). So we said “Okay, we need predictable results – make that damn fake webservice already.”

What it needed to do was:

• Return fixed, predictable results with specific, recognised requests
• Forward the request to the currently used live webservice, so our existing tests don’t all break
• (later) Add a feature to make the data returned variable, some tests rely on the test data returned to have dates that lie in the future
• Do not compromise the security – the live webservice requires HTTP authentication.

Of course, it also needed to be done quickly. We postponed making this fake webservice for a while because it seemed like a lot of work, but once we finally decided on making it, we figured “How hard can it be?”. We’ve been waiting for an opportunity to use NodeJS for a while now, and as far as we could see, this was the ideal choice in this case – we have a REST-like webservice (readonly) that mainly does i/o (from the filesystem and the external webservice), and it should be easy and lightweight to build.

So we went to hack in a few steps. Read more for the whole article and the code.

Read more →

What is NodeJS?

The NodeJS five-word sales pitch from their own website is “Evented I/O for V8 Javascript”. We’ll get to what that means exactly in the How. NodeJS, in a few more words, is a server-side application framework with a focus on high concurrent performance. Applications written for Node run in a single-threaded, event-based process.

Node is an open source project initially conceived and developed by Ryan Dahl in early 2009, and has been in active development ever since. Joyent, Dahl’s employer, is backing and sponsoring the project.

Before we go in-depth, let’s explain what’s probably the core point of NodeJS – event-based I/O.
Read more →