Quick note on how to configure an embedded ActiveMQ server using Spring @Configuration.


Here’s a way to quickly generate a private and public key:

In Windows openssl needs a file in which to produce random data:

Running this results in the following CLI output:

openssl cli output


And these two files will be generated:

  • dkim.pem
  • dkim.der

Since I work on a Windows pc, I have a very simple batch file that quickly generates one for me:

Quoting Smashing Magazine

You know how it works: you spend hours trying to find a workaround for a problem that you have encountered, just to realize that it doesn’t quite work in, you know, that browser. Finding little techniques and tricks to help you get to results faster can immensely improve your productivity, so you don’t have to waste time on solutions that will never see the light of day.

I love finding those little useful front-end goodies that make our lives easier. Since technologies emerge and evolve permanently, keeping track on what’s going on is often difficult, especially since specifications change and so does the browser support. For a replacement talk at SmashingConf Oxford last week, I’ve decided to collect some of the useful techniques from various articles, conversations and my workshops in a slide deck — and since it proved to be useful for many front-end developers I’ve spoken to after the talk, I’m very privileged to share it with the entire community as well. To the slides.

So off we go. A few dirty tricks from the dark corners of front-end development. Beware: the things you’ll find in the deck can not be unseen, and I do no take any responsibility for whatever happens next.

You can also download the entire slide deck on SpeakerDeck (PDF). And you’ll find slides from the other SmashingConf talks in an overview of SmashingConf Oxford slides. Happy learning!

From time to time it happens that I’m blocked out from a website by a corporate proxy, or that there’s simply a problem with HTTP traffic. Whenever that happens, you have a choice: bring your mobile network-connected phone / tablet and work on that or wait until the proxy is fixed or postpone until you’re home. Another option is to redirect the traffic yourself, using a tunnel.

This is a quick guide to setting up a HTTP proxy tunnel.


What is it

Command Query Responsibility Segregation (and Martin Fowler) or CQRS is a variation on the Command–query separation princple or CQS in short. CQS states that every method should be either an action or a query, but not both. It is a separation of responsibility where you clearly divide methods that change state from methods that report on state. CQRS is different in that it specializes in separating actions from queries for data CRUD manipulation specifically.

CQRS is an application architecture pattern or principle that is very simple in essence: split your read and write application paths.

Take a REST service for example, traditionally, you call the REST service, services goes to business layer, next integration layer and then all the way back again: synchronously the same path back. It also applies to asynchronous messaging systems such as JMS, because the application reading from a queue or topic and posting back a reply might still handle the business logic and persistence integration in a synchronous fashion using a single path.

Traditional CRUD model

Traditional CRUD model

With CQRS, the model is split up. In case of REST, there would be at least two services now: one for performing the action and one for performing the query of the result (unless you create some sort of synchronous read/writing blocking facade in front of the CQRS interface).



Why would you need it

Why would you go out of your way to split that up? To quote Microsoft’s excellent article on the subject:

The most common business benefits that you might gain from applying the CQRS pattern are enhanced scalability, the simplification of a complex aspect of your domain, increased flexibility of your solution, and greater adaptability to changing business requirements.

Because you separate these concerns, it becomes easier to maintain and understand and you can scale these concerns separately as well.

When to use it

Although we have outlined some of the reasons why you might decide to apply the CQRS pattern to some of the bounded contexts in your system, it is helpful to have some rules of thumb to help identify the bounded contexts that might benefit from applying the CQRS pattern.

In general, applying the CQRS pattern may provide the most value in those bounded contexts that are collaborative, complex, include ever-changing business rules, and deliver a significant competitive advantage to the business. Analyzing the business requirements, building a useful model, expressing it in code, and implementing it using the CQRS pattern for such a bounded context all take time and cost money. You should expect this investment to pay dividends in the medium to long term. It is probably not worth making this investment if you don’t expect to see returns such as increased adaptability and flexibility in the system, or reduced maintenance costs.

So you may have a complex domain model that is easier to understand if you separate read / write concerns. Or if you expect a lot of read / writes and you want to be more flexible in scaling these.

Martin Fowler posts a warning though:

Despite these benefits, you should be very cautious about using CQRS. Many information systems fit well with the notion of an information base that is updated in the same way that it’s read, adding CQRS to such a system can add significant complexity. I’ve certainly seen cases where it’s made a significant drag on productivity, adding an unwarranted amount of risk to the project, even in the hands of a capable team. So while CQRS is a pattern that’s good to have in the toolbox, beware that it is difficult to use well and you can easily chop off important bits if you mishandle it.

CQRS adds complexity to your application, but it removes a lot of complexity in the right situation.

Microsoft’s article quote some concerns as well:

Although you can list a number of clear benefits to adopting the CQRS pattern in specific scenarios, you may find it difficult in practice to convince your stakeholders that these benefits warrant the additional complexity of the solution.

“In my experience, the most important disadvantage of using CQRS/event sourcing and DDD is the fear of change. This model is different from the well-known three-tier layered architecture that many of our stakeholders are accustomed to.”
—Paweł Wilkosz (Customer Advisory Council)

“The learning curve of developer teams is steep. Developers usually think in terms of relational database development. From my experience, the lack of business, and therefore domain rules and specifications, became the biggest hurdle.”
—José Miguel Torres (Customer Advisory Council)

Adopting the CQRS pattern helps you to focus on the business and build task-oriented UIs.

Things to watch out for

A couple of problems arise from this pattern:

Synchronous read + write behavior becomes complex

If need to perform an action and read back the result, then you end up working around the pattern to make ends meet… literally. In this case you need a blocking mechanism that initiates the action while asynchronously waits for the result to come in to report back. The real solution is to provide a published interface that doesn’t return data from actions. CQRS system is a natural fit in an EDA landscape.

Stale data

As reading and writing to a system using CQRS becomes an asynchronous process, the problem of stale data arises. Some sort of synchronizing behavior should be present to keep up with the ever changing state of a CQRS system. Be it a blocking write/read mechanism, pulling or a batch job.

Javascript doesn’t natively support enums and it’s not included in the ECMAScript specification. Here are a couple of ways to do that in Javascript

What is an enum?

Essentially an enum is a set of unique named constants, like UP, DOWN, NORTH, WEST, LEVEL1, LEVEL2 etc. This is a great facility, because you can use the enum names as labels or flags or modes or status or whatever you like in a very readable way. Here’s an example from Java:

This is great right? Enums work because the constants get unique values in Java. You never need to know those values, because you equate the enum constants directly, not by their value:

You don’t do if (getDirection() == 0) (although this even works if UP is the first enum in the list): you compare readable names not values.

Enums in Javascript

To achieve this in Javascript, you need to emulate an enum, which is almost the same thing, except you explicitly assign the unique values initially. Observe:

The values don’t matter, as long as they are unique. They can be numbers, decimals, strings, arrays or anything else. Numbers are common, but the following pattern is often used as well:

The advantage of this is that when you print out myRocket.direction you don’t get a number, but the name of the constant. This is useful for logging and debugging.


Enums in Javascript with Lodash

I keep coming back to the awesome bag of tricks that is Lodash and I keep learning new things about it every day.

Here’s a way to create an enum, without explicitly defining their values:

What happens here? _.keyBy() creates a { key: value } object for each element in the given array and uses the function argument (second parameter) to produce the keys. _.identity simply returns the value as the key, so you end up with exactly the same as { LEFT: 'LEFT', RIGHT: 'RIGHT', UP: 'UP', DOWN: 'DOWN' }.

What do you do when you want to show someone all your skills ever? You make a tag cloud ofcourse!



I tend to stay away from more complex version control commands and workflows, as they often create more problems than they solve, especially if not everybody on board ‘gets it’. Rebasing with git however always felt natural to me: you get pull in changes from a remote and you reapply your own on top of that, instead of producing extra merge commits.

Here’s a visual explanation of what happens when you use git --rebase, especially when pulling from a different branch. Short version: don’t do it, unless you hate your colleagues. When pulling from the same branch as the one you are working on it is fine however (or if you know you are the only one working on your branch).