Two days of Event Store

Event Store 

What is an Event Store?

It is a database for supporting the concept of Event Sourcing. Event Store stores your data as a series of immutable events over time, making it easy to build event-sourced applications.
Projections allow you to react to events as they are written, and to create new events when interesting combinations occur. You can use the same model for writing temporal correlation queries that run over historical data and on into the future.

Event Store Workshop

If you want to learn more about Event Store, we are hosting a workshop in Malmö 2-3 October. During this two-day workshop Greg Young will teach how to use the Event Store as a stream database, both by using the native Atom-based API and .NET client API.

You will also learn to use the built in projections library to do complex event processing and write temporal correlation queries using JavaScript.
To find booking and more information, see our event Event Store Workshop with Greg Young

August 28, 2014 at 3:06 pm Leave a comment

A few Edument C# Master Class updates

The C# Master Class has been one of our most popular and well-rated courses ever since its advent almost 3 years ago. In that time it has seen a number of tweaks in response to feedback, along with a more serious update when C# 5 was released.




By now, I’ve done dozens of deliveries of the C# Master Class, and it has reached hundreds of developers. It’s been a great journey so far, and it has been especially rewarding to meet some course attendees a few months down the line and hear how the course helped. C# has grown into a larger and richer language than it once was. Some wonder if we really need all these features, but I strongly believe the sum of the features is greater than the features individually, and it’s been wonderful to have an opportunity to share that perspective with so many.

Equally, I’ve been growing and learning too. One of the nice things about working at Edument is that it’s simply OK to spend time learning new things. And after 3 years of the C# Master Class, I felt it was time to incorporate some of that learning back into it. Therefore, this summer, I’ve invested a bunch of time into improving the course. Of note, the OO coverage is now a lot deeper and richer, the parallelism section has been streamlined and refocused, and there’s an awesome new walk-through on implementing the event aggregator pattern from scratch by effectively fusing higher order programming, generic programming, and reflective programming.

There’s one other change I’d like to take a moment to mention. To date, I’ve been the only teacher for the C# Master Class. As our range of courses has grown, along with demand for consulting and mentoring, scheduling enough C# Master Class deliveries to meet demand has become challening. Happily, this summer the course has gained a second teacher. Edument’s Eric Lavesson has been working with me on the course updates, and will now also be teaching the class. Eric has great taste in code, and I know he’ll do a great job of teaching this course. All the same, I’m excited about the latest changes too, and look forward to my next chance to deliver a C# Master Class with them!

By the way, for those who took the C# Master Class and are looking to go further, don’t miss our Parallel and Asynchronous C# 5 course! I’ve had a lot of fun teaching it so far all over Sweden – from Malmö to Skellefteå – and we’ll be offering it some more times this autumn. It’s also available through our partner Glasspaper in Norway too – or anywhere in the world you want it, direct from Edument.

// Jonathan


August 19, 2014 at 10:51 am Leave a comment

JavaScript has taken over the world; long live TypeScript!

a picture of Darth Vader in front of some other toys

JavaScript has taught me this: if I were an evil overlord whose plans for world domination included getting everyone to download my programming language, I would put it in browsers.

Brendan Eich did just that, in 1995. He put this weird Java-Scheme-Self-HyperCard hybrid of his into browsers, and now all the king’s horses and all the king’s men can’t take it out again. I’m not saying Eich is an evil overlord; I’m saying if he were, this would have been a very clever move indeed on his part. Witness me clapping slowly.

JavaScript is here to stay

Let’s face it. We’re really, really stuck with JavaScript. In two ways, actually.

  • The first, that if you’re a web developer, you have to relate to JavaScript in some way. Because the web runs on JavaScript.
  • The second is Atwood’s Law: “any application that can be written in JavaScript, will eventually be written in JavaScript.”

(Someone may disagree with that last point… but only by failing to notice that nowadays people write office suitesIDEs3D first-person shootersemulators of mostly everything including JavaScript itself in JavaScript!)

Three stages of grief

Once we realize that JavaScript is here to stay, how do we choose to relate to it? We have a couple of options:

  1. Learn the language extremely well, so we can use it well.
  2. Improve the language step by step (without breaking anything).
  3. Wrap the language in a nicer language and use that instead.

Option 1 has become popular in the last few years. The two most earnest efforts I know about to teach JavaScript to the people are JavaScript: the good parts by Douglas Crockford and You Don’t Know JS by Kyle Simpson.

Option 2 is also underway, and seems to be picking up speed. Not only do we have a mostly-complete transition to EcmaScript 5 behind us, but EcmaScript 6 is looking good and more stable every day. Sometimes when the weather is just right, you even hear soft whispers of EcmaScript 7 in the wind. Evergreen browsers are becoming more common and help speed up adoption of newer features. All in all, given that we’re stuck with this language, it feels like we’re doing a very decent job of fixing it.

Option 3… now there’s a Cambrian explosion for you.

I can’t believe it’s not JavaScript

Seriously, check out the list of languages that compile to JavaScript. In that list, you are witnessing what happens when the reality of today’s web locks people into a de-facto development language: people find a way to compile from their own language to JavaScript. (True to form, half of those people geek out and neologize about “transpiling”, while the other half mumbles about kids today and nothing new under the sun, etc.)

On that list, you’ll find existing languages, original languages, languages with interesting ideas, and languages that won’t ever have 10 simultaneous users. There are behemoths like CoffeeScript and GWT on there. Even Perl 6 is on that list. It’s a long list.


Summer Glau and a tear

Let’s be clear about why that list is so long: JavaScript may be the industry standard, but as a language, it’s clearly lacking in useful abstractions: classes, interfaces, modules. There’s no way to declare the type of a variable. There’s no built-in namespace mechanism, and no way for one JavaScript file to include another. JavaScript is not only unfit for its current role as Overlord language of the web, but laughably unfit. Or, let’s say, we’re almost sure the tears in our eyes are from laughter.

Everyone is helping. The people from option 1 have shown us, across the years, how to emulate classes and interfaces and modules, how to fake it without strong typing, and how to hack the DOM in various ways to emulate features. The result is a lot of so-called “boilerplate” code: a lot of code with a low oomph-per-character ratio. You’re not paid to like it, you’re paid to make it work across all browsers, kiddo.

The people from option 2 are busy putting classes and modules and other nice stuff into your JavaScript. You go, TC39! (You can even run ES6 today, in your browser. It’s pretty cool, but it has to be compiled down to ES5 for now.)

The people from option 3 are basically scouting ahead, seeing what options we have for making JavaScript nicer. That long list of languages is like an ongoing evolutionary experiment in working language designs. What will stick and what won’t.


It’s here that TypeScript comes in. It’s another language that compiles to JavaScript, but compared to the changes many languages on that list make, TypeScript’s are fairly modest, and the language sticks close to JavaScript. In short, TypeScript gives you optional typing and classes, interfaces, and modules/exporting — allowing you to write code with high-level abstractions, while the compiler translates it back to boilerplate.

A bit more in detail:

  • Syntactically, it’s a strict superset of JavaScript, so every JavaScript program is already a valid TypeScript program by definition.
  • It’s almost as if TypeScript’s mission is not to change JavaScript into something it isn’t, but to take what’s already there and describe it on its own terms, allowing us to talk about relations that were always present, implicit in our JavaScript code. I find that rather charming.
  • The boilerplate that comes out the far end of the compiler is described as “how you would have written responsible JavaScript anyway”.
  • What we put in as additional types and classes and interfaces to describe our code, we get back as static type-checking and term completion in our favorite IDE. That kind of safety and convenience is not possible with today’s dynamic-to-the-hilt JavaScript.
  • But what about all the JavaScript library code that’s already out there? Wouldn’t the TypeScript code you’re writing be like a tiny type-safe island in the middle of a vast ocean of untyped JavaScript library code? Yes, but… there’s a community project where people are adding TypeScript types to all the big JavaScript libraries out there, so we can TypeScript while we TypeScript! Gotta love open source.

These are some of the reasons I’m excited about TypeScript. I used to write mid-sized to big projects in pure JavaScript; nowadays, my first choice is TypeScript.

Try it now

You can play around with TypeScript code and the JavaScript it renders in your browser. Oh, and the project hit 1.0 a month ago, which is just what it sounds like: this is ready for production.

One last thing: Edument provides a JavaScript course, which we’re constantly keeping up-to-date to reflect the latest best practices in web development. If the topics in this blog post interest you, consider taking the course, which is two days’ worth of similar material.




Carl Mäsak på Edument

June 24, 2014 at 12:47 pm Leave a comment

Video of my invokedynamic talk is online!

Several Edumenters attended Build Stuff 2013, and two of us gave talks. All of them were recorded by InfoQ, and they’re now starting to appear online! The first one to appear is my invokedynamic talk. The invokedynamic instruction was introduced in JDK7, and was aimed at helping compiler developers targeting the JVM to more efficiently implement a wide range of language features. While the name suggests a role mainly for the things we like to call dynamic languages, invokedynamic has in fact been used as part of implementing lambda expressions in Java 8.

My own application of invokedynamic was implementing JVM support for the Rakudo Perl 6 compiler. While the talk is not just about that – it covers invokedynamic in a much more general sense – I was able to draw on my concrete experiences of using it, which is something I always like to be able to do in a presentation. Also it was nice to do a talk on compiler-related things – an area I greatly enjoy working in.










Recorded at

May 23, 2014 at 11:33 am Leave a comment

Teaching Git in SH: a summary

Carl reports about his week-long Git teaching in China, and the various thoughts he had along the way.



While here in China, I’ve been thinking of traffic.

Compared to Sweden, there’s a proliferation of vehicle types. In Sweden you’d see cars, trucks, and bikes on the road. Here you see that and more: mopeds of different sizes, bikes and motorcycles with flatbeds on them, mopeds that pretend they are cars, cars that look like half a car, and various hybrid types between these. It’s as if China has already experienced the traffic equivalent of polyglot persistence.

Not only that, but everyone seems to get by with lots fewer traffic rules. That’s my impression at least, as a safety-minded Swede. Pedestrians crossing the street everywhere, dodging in front of or between cars. Bikes and mopeds going against traffic. Oh, and apparently one of the few traffic rules here says that you’re free to turn right any time, regardless of what the lights say.

But the amazing this is, it works. There are very few accidents. I haven’t seen one, at least. The whole system seems to work through honking. Whereas in Sweden, a car honk would mean something very much like “Pay attention, you’re doing something quite wrong!”, in China it means something much more like “Oh hey, I’m here! Hi! Got space for me in this jam?”

image of traffic in shanghai

Optimistic concurrency

Anyway, Git.

A Git conflict is a bit like a traffic jam: two developers wanted to occupy the same piece of source code at the same time, and now they’re honking at each other, waiting for a solution to present itself. In traditional (centralized) version control systems, the tendency has been to introduce traffic lights everywhere, to make it clear who gets to modify the source code, and who has to wait. It’s a sensible model, and it certainly has safety to speak for it.

But Git (among other contemporary distributed systems) offers an interesting alternative: let’s ditch the traffic lights, and just handle conflicts as they occur. Does your change conflict with someone else’s? Well, then it’s your mess to clear up, go right ahead and write yourself out of that tangle. If you’re of the old centralized school, or a Swede, this sounds like madness at first — who in their right mind would want to give up the safety conferred by traffic lights in favor of… anarchy?

But it does work, and there are even some hidden advantages. In the literature, the traditional model of providing traffic lights everywhere is called pessimistic concurrency, whereas Git’s laissez-faire model is called optimistic concurrency. Interestingly enough, processor manufacturers and developers of concurrent algorithms face the exact same choice, between pessimistic and optimistic concurrency. And their conclusion is largely the same: optimistic concurrency scales better.

Basically, the old centralized version control systems give you safety whether you need it or not, at the cost of slowing everything down a little. The new distributed systems have an attitude of “OK, there will be conflicts on the way, but we’ll handle them when we get to them”. Since usually there aren’t conflicts, normal work progresses faster, with fewer distractions. Most cars meeting on the road do not head straight for each other and start honking.


All of this makes for a cute analogy, I guess, and it was something that struck me at the beginning of the teaching week in Shanghai. I even told the first group about it. If someone else had made the comparison, I would probably have nodded and said “yeah, sounds about right”.

The teaching week itself went fine. There’s something about Chinese audiences that makes them a little extra rewarding to teach to. I think they simply pay a lot of attention. Any teacher will tell you that that in itself makes a big difference.

Besides which, the questions were interesting, and showed that people were following along.

On the Friday, we had a Q&A session for people who were interested enough to come ask Git questions outside of the curriculum. Now, it turns out that when you arrange such a session, the people who turn up tend to be the people who are not based in Shanghai — likely because they are away from their daily work anyway, and don’t have competing priorities. But we were a cozy gang of about ten people, and filled a morning of discussion about the different bits of Git.


After doing Git for a week like this, I experienced another insight, one I hadn’t had before. Git (and distributed version control) mirrors the way the Internet works. The Web is a big tangle of servers and clients, all talking to each other without any central authority. Peer-to-peer services like Bittorrent have disrupted the way we think about content distribution. Cryptocurrencies like Bitcoin are beginning to do the same thing with money. Git belongs in this bucket of fast-moving, fluent, net-enabled technologies.

…weirdly enough, since one of the big selling points of distributed systems is that you don’t need a network connection.

Git is the technological enabler of meritocracy within a project. In a real meritocracy, it doesn’t matter who you are, only what your contributions are. I just accepted a contribution in a Git project from a person I’ve never met and whose name I can’t recall. I chose to accept the contribution because the content looked good. In Git, the one who pens the contribution is called the author and the one who accepts it into a project is called the committer. Before I had started using Git, it hadn’t even occurred to me that author and committer could be different roles. Every time the author and committer are different people, a contribution happens to a project that likely wouldn’t have happened before.

Git encourages this kind of distributed collaboration. It does it very well. The whole branching model is geared towards giving everyone equal status. By default, there’s no privileged central repository, there’s no privileged developer, and no-one tells you which workflows you have to pick. (The last point is kind of disorienting for people who come from one of the old systems, where there’s usually One True Way to do things. Entering into the world of Git where there’s lots of possibilities tends to lead to a feeling of vertigo.)

Perhaps the best example of this kind of meritocracy is Github. Github doesn’t really add much new on top of Git, it just exposes it in ways that tend make people contribute to each others’ projects. Whereas on Facebook you “like” people’s posts, and on Twitter you “retweet” them, on Github you “fork” someone else’s project, make a contribution, and then ask them to reintegrate it into theirs. Again, I don’t really think of Github as something more than Git. They did a remarkably good job of creating a web interface for the things you normally want to do with Git, and adding wikis and issues and web pages around each project… but in the end, what they are doing is harnessing Git’s powers, not extending them.

All this explains to me a bit better why I like Git so much, and why I want to invest time in learning it well. Because Git is essentially version control’s reply to the Internet. It’s the way we should be working if we’re aware that the net is becoming more and more of a natural part of our lives.

Even on this social level, what we’re harnessing is a kind of anarchy. The occasional motto in an early open-source project I was a part of was “Trust the anarchy”. In other words, lots of chaotic contributions will mix together, and if we just do some minimal guidance, then the sum of all those contributions will be greater than each individual one. In this sense, Git inherently trusts the anarchy.

What’s next for Edument and Git? We’re going to be doing a deep dive into our Elite Git course, for people who want to implement Git workflows inside an organization.




April 11, 2014 at 3:41 pm Leave a comment

The parallel and async C# course takes off!

It was around a year ago that I first suggested to my colleagues at Edument that we might want to build a C# course focused on parallel, asynchronous and concurrent programming. The inspiration came from teaching the final two modules of our popular C# Masterclass, which provide a little coverage of these areas. I noticed it was one area of the course that participants particularly enjoyed – despite it being at the end of 3 information-dense days. And I found myself often jokingly pointing out that it’s a big enough area that we could spend 3 days on this area alone.

Turns out, the joke has become a sales pitch: we now really do have a 3-day course on those topics. It’s already been run twice, and already it’s confirmed that we will be running it twice more, in Stockholm in April and then in Malmo in May. Given this initial level of interest, I’m hopeful of many future deliveries – including some beyond Sweden.

For me, this is an enormously fun course to teach. I had the fortune of being lectured in concurrency by one of the leading experts in lock-free data structures back in my university days, and it created a curiosity for the topic that has never gone away. Since then, languages and libraries have evolved enormously. The .Net framework’s offerings these days are a huge improvement over what was available in the early days. However, there’s now a heck of a lot of choice:

  • Traditional threads and locks
  • Tasks
  • async/await
  • Concurrent collections
  • Rx
  • Parallel iteration
  • Parallel Linq
  • TPL Dataflow

What do they do? How do you know when to use what? What sorts of problems do they solve? The course looks at all of the above, covering the basic theory before moving on to practical examples of how they are applied. Participants get to take away my sample applications for all of them, as well as being able to try them out in exercises (which also come with sample solutions).


The prerequisites for the course are set fairly high: participants need not have experience in the areas covered, but should most certainly have up-to-date C# skills. That means being comfortable with generics, lambda expressions and Linq – key ingredients of elegant C# code. These are used quite heavily in the .Net framework’s parallel, async and concurrent programming features, and therefore are relied upon heavily in the course. Thankfully, for anybody who feels they aren’t really up on these topics, we’ve other courses to get you there.

Anyway, I look forward to bringing the course to Stockholm later this month, and doing it on home turf at Edument’s Malmo teaching center in May. There are certainly some spots left in Malmo, and probably some in Stockholm too. And, as with all of our courses, we’re happy to offer it on-site at your company too!




April 10, 2014 at 10:47 am Leave a comment

Ny årstid, nya medarbetare!

Edument fortsätter att växa. Vi har därför förstärkt vårt team med ytterligare två Account Managers till kontoren i Malmö och Helsingborg.

Låt oss presentera Emelie Andersson, en positiv tjej med många års säljerfarenhet från både utbildnings- och mediebranschen. Samt Olof Brodén, som tidigare har drivit sin egen e-handelssite och arbetat som säljare med projektledningsansvar inom media.






Emelie Andersson

Emelie når du på: 0763- 05 14 93  och






Olof Brodén

Olof når du på: 0735-31 61 01 och

Varmt välkomna!



Jenny Edument

April 8, 2014 at 10:13 am Leave a comment

Older Posts


Get every new post delivered to your Inbox.