Invariants hidden in callbacks

In this post I will discuss one of my favorite pet-peeves: callbacks. This post is programming language independent, though I guess it will shine through that I mainly work in C, C++ and Node.js. Callbacks are super nice for accomplishing a wide array of tasks: concern separation, asynchronous execution, future extension, etc. however there are several problems hidden in how callbacks can be implemented.


The first problem is to not allow for a context to be passed through to the callback. With modern languages where we have closures this is a non-problem because the function will automatically carry the extra state with it. However in C you sometimes see a callback (which is a function pointer) used like this:

// Header
// This is how we declare a function pointer with no args, returning void, called MyCallback.
typedef (void) (*MyCallback)();
void registerCallback(MyCallback *cb);

// Source
static MyCallback *g_registeredCallback = NULL;
void registerCallback(MyCallback *cb) {
  g_registeredCallback = cb;

void invokeCallback() {
  if (g_registeredCallback != NULL) {

We register our own callbacks like this:

void callbackFunction() {
  printf("callack was invoked\n");

However the API doesn’t allow me to pass any extra state to the callback, so I can't attach the callback to any "object". The solution is to always pass in an extra context parameter:

// Header
typedef (void) (*MyCallback)(void *context);
void registerCallback(MyCallback *cb, void *context);

// Source
static MyCallback *g_registeredCallback = NULL;
static MyCallback *g_registeredCallbackContext = NULL;
void registerCallback(MyCallback *cb, void *context) {
  g_registeredCallback = cb;
  g_registeredCallbackContext = context;

void invokeCallback() {
  if (g_registeredCallback != NULL) {

Now we have a state and we can connect a specific callback invocation to an object. This is automatically solved in JavaScript since a function reference contains it's closure (for non-javascript programmers here is an example of what this means):

function generateCallback() {
  var closureVariable = 32;
  return function() {
    console.log('the closure variable is', closureVariable);

let callback1 = generateCallback();
callback1(); // prints 32
callback1(); // prints 33

let callback2 = generateCallback();
callback2(); // prints 32
callback1(); // prints 34

The next problem is that when we invoke a callback we need to consider that the callback can do anything. Take following example where we store callbacks in an array and then later we will process them and clear the callback queue (this time implemented in JavaScript so the context problem from above is automatically solved).

let callbacks = [];
function registerCallback(cb) {

function processCallbacks() {
  callbacks.forEach(cb => cb());
  callbacks = [];

The implementation looks innocent, however consider following usage:

registerCallback(() => {
  registerCallback(() => {
    console.log('When is this called?')

and boom an infinite loop. This problem has many variations, for instance if we allow a callback to be unregistered, can we unregister ourselves from within the callback? The common trait for these problems is that we have some invariant that gets violated, i.e. when we wrote the functions we expected the callbacks array to not be modified while we are processing callbacks.

To ensure we don't violate the invariant we can rewrite like this:

function processCallbacks() {
  let internalCallbacks = callbacks;
  callbacks = [];

  internalCallbacks.forEach(cb => cb());

Now we first make a copy of the globally accessible object so registering a new callback while we process callbacks will not be executed.

My final point around callbacks is to always have same state when invoking the callbacks. With state I mean callstack, mutexes held, etc. Consider following example:

function doProcess(callback) {
  if (Math.rand() < 0.5) {


when the callback is invoked we will not know if the global variable has been updated or not. Common versions of this problem is to have different execution flows where the callback is invoked with different mutexes held along the different paths, or calling a callback both synchronously and asynchronously. A nice solution is to refactor the code so the callback is only ever invoked from one place. Also notice that if you ever refactor your code so the callback is invoked in a different state (for instance holding different mutexes or executing on a different thread) can lead to hard diagnosed and mysterious bugs.

To summarize, the bugs come down to breaking invariants, and when the invariants are implicit it can be hard to spot the problems. The invariants can be broken either by the callback doing things the callback invoker didn't expect, or reversely the signaller invoking the callback at times the callback didn't expect to be invoked.

In Node.js we can often get around the problems by executing the callbacks from a process.nextTick callback:

function processCallbacks() {
  callbacks.forEach(cb => process.nextTick(() => cb()));
  callbacks = [];

and then we need to accept that our callbacks always will fire asynchronously. In C and C++ there is no general solution for executing deferred callbacks, so in a future post we will look at what our options are there.

Expanding boundaries

I have been encouraged to reach beyond my boundaries ever since I started working at Edument. This has developed me, both professionally and as a person, and made me feel more confident in my workrole.

I personally do not like to stand and talk in front of other people. However calm I might seem to others, inside I am shaking. It helps knowing the material, but I have always had this feeling of not being good enough. That what I am saying does not make sense and I do not really know what I am talking about.


So, naturally, when I was first asked to give courses for EC for a total of three years I was hesitant. I doubted my ability to teach and did not feel that I knew enough to actually teach any course. However, I accepted the assignment. Why?

Because, this is something that scares me and is way outside my comfort zone. But, in order to move forward, you need to be challenged and face your fears, accepting that the outcome may not always be what you reached for.

So, I started prepping, building course material and practiced by talking in front other Edumenters and at home. And, last week, I gave my first lesson at EC. It was terrifying, but I survived. And to my surprise, I really liked it!

I think this all relates back to the fact that I really love my job. I am constantly learning new things and expanding my boundaries. I think this boils down to an inherent curiosity that I share with other Edumenters, a drive to learn new things and test them out, and then pass on the lessons learned to others. I feel this last part ties into the Edument motto: "We offer what you can't google"

- Therése

How we do agile, part 1

So, I started trying to write one single blog post about our entire agile process when working on projects. By “process” I mean all the practical stuff. What routines do we have? How do we handle issue tracking, customer demos, etc. The whole shebang. I felt like I kept skipping a lot of vital information as I cut things down though, so I’ve decided to make this a series of blog posts that I will sprinkle in between my colleagues’ posts here and there.

This initial post will simply set the scene. I’ll talk a bit about the team we had assembled for our latest project, and which conditions and circumstances we met.

Why am I writing this?

“Agile” is one of those areas that are just hard to navigate. While there’s a lot of good ideas and practices, there’s also a lot of buzzwords and bad practices. For every good way to implement an agile way of working, there’s probably ten bad ways of doing it. I remember a few years back, when I thought that the key to succeeding with agile work was knowing why you did a certain thing.

Let’s assume that you are about to use Scrum in a project. You’ve read the official Scrum guide, maybe attended a course and got one or more of the certifications. These are all good things, since you’re now hopefully in a position to know why you should be doing a retrospective, and why you should have a daily standup, and so on. It doesn’t really give you any clue on how to actually work in an agile way, day-to-day.


I personally think that one of the more obvious ways to set yourself up for failure is by implementing a framework, following it by the book, without understanding why a certain type of meeting or timebox exists. It’s going to be very hard to answer the question of whether this gives you any value or not. And that’s the core of it, right? Having the answer be “yes” to the question “Does this provide us with any value?”, and avoid doing things that doesn’t.

I actually didn’t want to discuss Scrum in this blog post (or any other framework for that matter). I simply wanted to talk about a concrete way of implementing an agile workflow. Moreover, I wanted to talk about reaching that point. I very much doubt that anyone will just say “Hey, let’s do X for agile work” and just have everything work exactly as intended. I think you need to keep working, improve, rinse and repeat until you get it right. And even then, you might have to change things around as your team changes. I could argue that we’ve “failed” at agile before at Edument, because we’ve definitely had occasions when things were running less smoothly than you’d hope for. In reality though, what we did was gather data on what worked and what didn’t.

The team

I was the architect/tech lead on a project that we recently worked on, and I felt like we finally got a lot of details right, and managed to reach that point where our agile process was just in the background like any other tool. Just like we use Git for version control, or use Jira for bug/feature tracking, this should just be part of your daily routine, and you shouldn’t have to think too hard about it.

One problem with trying to implement a framework exactly, is that you might end up in less than ideal situations. What do you do when someone points out that “Hey, we don’t have a Scrum master”, for instance? The easy answer (one that you’re likely to hear) is that you are doing it wrong, and should go find yourself a Scrum master. This doesn’t really tell you how to handle the situation practically though. From a pragmatic standpoint, I’d personally call this answer utterly useless.

So, as far as I can tell, there are a few different ways of handle this. Do we hire someone new to fill this role? Might be risky, since it’ll probably be someone you haven’t worked with before and who have zero knowledge about the project. This will always be a time investment (and obviously a monetary one too).

The reality for us was very much that we couldn’t do this. This was never an option, and what we had was a small group of programmers (3 developers full time, 1-2 developers coming in/out of the project when time allowed), sporadic access to a UX designer, plus a product owner from the customer’s side, located in Germany.

Later in the project, we also had a second team come in from our office in Prague. This was an additional 3 developers working with our team in Sweden. This also means that we now had a team spread across three countries.

The things I want to cover

In upcoming posts, I will talk about which components our work included, such as the customer demo, how to decide on what to demo, how long should an iteration/delivery cycle be, and how we handled our backlog.

I also want to talk about the process itself. What did an ordinary work week look like? How did we start an iteration after a release? How did we finish up before each release? How did we use story points? (hint: we didn’t).

Finally, I want to talk about some of our hit'n misses during other projects. Things that obviously didn’t work in one project, and how we carried that knowledge over to the next one.

Until next time!

- Eric

Fill in the details and confirm your knowledge with course developing.

I’ve always admired my colleagues work they’ve put into creating great and rewarding courses, I imagined it was a challenging and time-consuming task. I can see the meaning of that now, because all of a sudden I am developing a course.

I’ve always known the good quality of an Edument course, the great level of competence and the passion the teacher is giving, which is amazing to see.

This time it’s my turn to create something that others will value. With no clue where to start, I am now in full swing. But lucky me; I had and still have the best support. One of my colleagues threw me into it and I was shown a little about the process and the structure, and already after that time I learned new things and could put words on some of my knowledge.

But what are we here for if we cannot take our own responsibility and throw yourself at something, well I did. I was focusing on one separate chapter of the course while my colleague was focusing on another, we were working together but on different parts. And recently I jumped into another course to develop.

Here comes my infatuation for pull requests in focus. I love the way of using Git and Github, where we are collecting material and projects within the company. Here it makes it easy for me to open up for my colleagues to review what I’ve done. Get feedback, and through that feedback develop my own skills and learn. To always aim to get better and to get better with an extra push on the way with the help of competence of others.

Developing a course puts your current competence in place, like a confirmation, while new competencies come into the picture. I’ve noticed it makes it easier to put words on your knowledge, easier to explain some areas while writing the material. To be able to write down an explanation, for what you might previously worked with practically, will deepen and confirm your knowledge and understanding.

Mixing course development with a team project, I’d say gives a great learning curve, to get the big picture of some technology and then put the competence in place with words and pick up these small details that makes a big difference.

– Nelly

Meet Nelly: tea drinking vegetarian and happy web developer

Nelly Haglund developer_Edument Nelly Haglund, web developer at Edument, gets along with (almost) everyone.

The latest addition to Team Edument is also our youngest member. The opportunity to create things from scratch combined with a large portion of curiosity steered her towards web development. Say hi to Nelly Haglund, Trainee web developer at Edument; a self-described happy and positive person who likes solving problems and has a strong disdain for birds. Not afraid of trying A few things become clear quite soon upon working in the same office as Nelly. She’s devoted to her work, she’s a vegetarian among quite a few meat lovers (at Edument Helsingborg), and she is not afraid to try things that she believes in.

”When I code I like to try every little thing I think might work. I’m not afraid of trying different solutions. I don’t want to exclude anything; it might prove to be the best solution”, she explains.

Nelly says that tasks may at first seem hopeless but once you start trying different solutions and see progress the feeling is very satisfying.

”What keeps you going is that moment when you’ve climbed a little hill and you start solving the problem”, she explains the appeal of web development.

Back-end more of a challenge Nelly grew up in the rural town of Teckomatorp, a place you might pass through by train or find on a map slightly to the right of Landskrona. An interest in photography introduced Nelly to HTML and CCS when she wanted a place to showcase her photos. For someone who has always been creative, Nelly's problem solving skills are put to good use in her current role as developer.

”I always thought front-end was the most interesting. In school we focused a lot on back-end. Understanding the systems behind what meets the eye I found more of a challenge and, therefore, more fun”, Nelly explains.

Edument is the best place to grow and learn Nelly has not yet chosen a field she wants to specialize within but does not think it unlikely that the choice may fall on React JS.

”As a student I spent both internship periods at Edument. I was at a larger company in the region for four days but didn't like it. I wanted to go back to Edument so I did. This is the best place to grow and learn”, she says.

Guys say what they think Being a woman in a line of work mostly inhabited by men is not something Nelly spends time thinking about. She says she only notices the relative lack of women when she thinks about it. Nelly says she notices a difference in the way male and female developers communicate.

”Guys tend to speak their minds when coding and checking code, whereas girls generally think more before they speak up”, she says.

It is questionable however whether this applies to Nelly herself. As a vegetarian among co-workers who prefer to eat meat, Nelly is a force to be reckoned with at the office. Gets along with almost everyone At Edument Nelly is good at adapting to new situations and works well with her co-workers. It’s easy to think she gets along perfectly with everyone. Yet that is not entirely true. A kind of individuals Nelly has a very hard time with are birds.

”I am not friends with birds. I’ve had my hair pulled by a bird, one bird pecked at my leg so I fell down from a tree as a child, and I have been chased by a swan”, she summarizes her infected relationship with the animal.

We are very happy to have Nelly onboard and look forward to seeing her develop her skills with us. And we promise to do what we can to keep her safe from harassing birds. Connect with Nelly Nelly’s photography Nelly's profile

Meet Therése: the problem solving web developer

Therese Barmer_Edument Therése Barmer, web developer at Edument.

Therése Barmer has a background in customer service, a fact that hardly surprises anyone talking to her. Open, outgoing and obliging, are adjectives that describe this web developer and new Edument employee very well.

Problem solving is the common denominator Therése has held a number of different jobs prior to entering the doors of Edument. Previous employers include, among others, a café, a pizzeria and a shop. Understanding customers’ needs and wishes and solving their problems is not new to Therése, and it’s an experience that is likely to come in handy in her new role as Trainee web developer at Edument.

”Customer service is all somehow about problem solving. No days are exactly the same because different problems arise each day. Either a product is out of stock or something else has occurred and it’s your job to solve it”, she explains the overarching theme of her past employments.

The key to understanding Therése's dedication to helping others has manifested itself in different forms during the years. When studying, Therése worked part time as a private Maths tutor.

”Everyone can learn to enjoy Maths”, she says and explains; ”it’s all about finding the right key that unlocks your understanding”.

From physics to web development Born and raised in Helsingborg, Therése left her hometown for Stockholm where she lived for a few years before returning to Skåne to embark on her studies. Maths and the natural sciences are favourite subjects of this customer service specialist. Physics and some practical philosophy was what Therése focused on during her time at Lund university.

”I also had a daughter before finishing my studies”, Therése adds.

At a career fair she began to understand the demand for programming experience among employers. Many of the recruiters she spoke with were looking for people with C++ experience. Therése decided to complete her skills and applied to a 2-year program in .NET development. It was as a student of web development that she met with Edument. The program contained two internship periods and both of them were spent with us.

”The second internship period was definitely the most exciting one. We got to work on a real project for a large customer with clear requests and deadlines”, she explains.

Knitting and working out Therése is a woman with many interests. When not working in web development, spending time with her family, solving sudoku puzzles, and working out - often in front of the TV with her partner, are all things that keep Therése busy. Knitting is another one of her many hobbies. Perhaps contrary to the age group those interests might indicate, Therése is only in her mid thirties.

We are very happy that Therése has joined us at Edument and look forward to seeing her skills develop with us. Connect with her on LinkedIn.


Meet Erik Man: mindful teacher and programmer

Erik Man, teacher and consultant at Edument. Erik Man, teacher and consultant, when not working.

Since December of 2015 you find this Aikido practitioner at the Edument office in Helsingborg. Explaining complex things in understandable ways inspires and motivates him. It’s fair to say that Erik Man is a rather perfect fit as teacher, consultant, and programmer at Edument.

"I want others to shine"

From picking apart toys as a child to writing his first optimizing compiler at the age of fifteen, Erik has been on a long a quest for understanding things. However, nothing delights him more than being able to share his knowledge in ways that are understandable to other people.

"I think one of my main themes is to take complex things and making them more accessible to others. Whether it is by explaining, creating a tool or making a helper library, doesn’t really matter. I want others to shine", Erik says.

Development, literally and figuratively, is dear to this previous Senior Software Architect. Teaching helps him stay on top of the game, constantly improving and questioning. Explaining and making complex things if not easy, then at least understandable and interesting, is one of Erik’s strong suits.

Personal development is not just a buzzword

Erik found his way to Edument through the recommendation of a friend who considered him and us a perfect match.

"It’s great to be able to focus on an area of personal interest in my job and develop my skills in that particular area. Personal development is not just a buzzword here, it’s something you are in fact encouraged to spend time on", he explains and adds:

"I like the idea of feedback cycles; by evaluating my knowledge I can continue to improve, and teaching makes me reflect on my own ability to explain and make knowledge accessible to others", Erik says.

Contributing to customers' development

Erik enjoys several parts of the Edument culture, for instance the attitude towards programming — the focus on programming not for the sake of programming but for the applicability and usability of it, that prevails in the company.

"It’s important to keep in mind that what we do, teaching and consulting, is aimed at serving customers and that we, in improving their knowledge of code and programming, are contributing to the development of their products and services", Erik explains.

The many different tasks in a typical week at Edument is another side to the job that Erik is particularly happy with;

"One day you’re completely devoted to a project, the next day you’re teaching a course, often in a different country. The variety is exciting."

What is Erik up to?

Erik is currently teaching  C++ for experienced developers and Parallel and Heterogeneous Computing with Microsoft PPL & AMP.

Meet Klas Tauberman: designer and Edument consultant

Klas Tauberman_profil_Edument                 ”Curious, patient and accommodating”. That’s the three words he chooses to describe himself with. He looks forward to getting teaching experience and to start working on transforming the way Edument is perceived. We sat down for a chat with Klas.

Designing our future

We live in a world full of uncertainties. One thing, however, we can be rather certain about. Our visual identity, the presentation of our course material, and our website, are about to change. Our developers can also look forward to being supported with graphic design and the UX/UI perspective in their work. The reason we know this is because we just added a new member to the Edument team; Klas Tauberman. With experience of graphics, visual design, illustration and UX/UI design, he is sure to make a highly visible mark on our communication. ”I look forward to start working on implementing a new design for our website and developing the new visual identity. It’s the first time I get to do that from beginning to end”, Klas says about one of his first projects as an Edument employee.

A friend of CodeBuddy

Klas has previously worked at Malmö-based Tactel as well as at BlackBerry. At BlackBerry he met fellow Edument consultant Stephen Lau. Since late May of 2016 the two of them are colleagues once again. However, Klas was not a complete stranger to Edument when he joined our team. He has, in fact, produced a film for us in the past. The film is about our CodeBuddy service. A CodeBuddy is a developer that mentors you in your environment and helps you solve your particular problems; a way of learning new skills outside of the traditional classroom environment that has proven very successful.

The Lion King makes him cry

When not by his computer Klas likes to exercise. You won’t find him at the gym, however. This designer prefers using his own body as resistance and is no fan of machines, when it comes to working out, that is. Instead you may find him running in the city of Malmö where he also resides with his family.

”My job is also my hobby”, Klas explains and adds that he always has several ongoing projects that interest him. Klas gives a very calm and collected impression, like there is hardly anything that would unsettle him. When asked if he would like to share anything we don’t know about him, this is what he says:

”The Lion King film makes me cry. I always find it sad when Simba’s father dies.” We are very happy to have Klas on our team and look forward to developing with him.

Edument söker senior Javautbildare

Vi ger dig ett löfte. Vi lovar att se till att du blir det bästa du kan bli. Vi kommer att ge dig tillgång till smarta kollegor, uppdrag som tänjer gränserna, kontinuerlig utbildning och vår kreativa Edumentkultur. Ditt första uppdrag som Javalärare kommer du att genomföra i Stockholm. Kursen pågår under 12 veckor och dina studenter ska lära sig mer om:
  • Introduktion till programmering i Java
  • Objektorienterad programmering
  • Datastrukturer och algoritmer
  • JVM och Java-plattformen
  • Introduktion till Databaser och SQL
  • Introduktion till webbutveckling
På sikt ser vi gärna att du blir produktägare för vårt Javaspår och därmed tar ansvar för befintliga kurser och är med i arbetet att ta fram nya. När du kommit in i lärarrollen finns det möjlighet att jobba som konsult i något av vara projekt. Vissa projekt driver vi inhouse och andra ute på plats hos kund. På Edument ser vi en stor styrka i att mixa teori med praktik. På vår önskelista står följande:
  • Känna dig bekväm med punktlistan ovan.
  • Erfarenhet av Scrum eller andra agila metoder.
  • Van vid kundkontakt och förståelse för affärer.
  • Kreativ & engagerad med vilja att skapa innovativa lösningar.
  • Gillar att jobba i ”tech startup”-miljö.
  • Tidigare erfarenhet av utbildning är inget krav. Viktigare är känsla för att utbilda och ha förmågan att förklara komplicerade saker på ett enkelt sätt.
  • Ha ett kunskapsdriv och att ständigt vilja lära sig nya saker.
Vi har många spännande utmaningar på gång i Stockholmsområdet och du kommer att ha din bas där. Ibland kommer du att ta en tur till både Göteborg och Malmö för att ge Javakurser. Vill du jobba med oss? Vi behöver CV men det som är av störst intresse är hur du ser på framtiden. Vem kan leva på gamla meriter? Har du möjlighet att skicka GitHub-länk, portfolio eller arbetsprov så gör det också. Ansökan skickar du till och vill du prata med Björn ringer du 0733-514830. Urval sker löpande.

Edument söker skickliga och resultatdrivna säljare med sinne för affärer

Det går bra för Edument och det är vi fantastiskt stolta över! Vi har anställt närmare 15 lärare/konsulter senast året och nu är det även tid för säljavdelning att växa. Idag är det Acke, Paul, Emelie och Wiveka som drar runt säljarbetet och de vill ha sällskap av två kollegor till. Vi tror att den ena säljaren som kommer att anställas är mer junior och den andra är mer senior. Båda kommer att börja jobba med försäljning av våra utbildningar och med tiden kommer den ena, kanske både, även att jobba med försäljning av projekt/uppdrag (förutom att utbilda har vi även en hel del konsultuppdrag). I det dagliga arbetet kommer du att ha kontakt med en mängd olika roller. Du kommer att prata med VD, IT-chef, HR-chef, konsultchef, utvecklare, produktionschef m.m. Dina potentiella kunder hittar du i hela Sverige inom alla möjliga branscher. Givetvis är det är ok med internationella kunder också. Båda säljarna ska utgå från vårt Helsingborgskontor och kommer att arbeta tätt tillsammans med VD Acke Salem. Vårt erbjudande
  • Vi är ett tillväxtbolag med höga ambitioner.
  • Vi har ett starkt varumärke inom branschen.
  • Innovation är en av våra ledstjärnor.
  • Kreativ arbetsmiljö med smarta kollegor.
  • Utmanande arbete med möjlighet att göra skillnad.
  • Ett härligt säljteam där alla har stora möjligheter att vara med att påverka Eduments expansiva utveckling.
Dina egenskaper & erfarenheter
  • Drivs av att göra affärer och att arbeta självständigt med relationsförsäljning.
  • Resultatinriktad, engagerad och motiveras av att lyckas.
  • Lättlärd och strukturerad.
  • Lyhörd med förmåga att förstå kundens behov.
  • Eftergymnasial utbildning inom ekonomi, marknad eller liknande.
  • Vana av affärs och IT-system.
  • Minst två års erfarenhet från B2B försäljning.
Vill du vara en del i Eduments framgångsrik team? Urval sker löpande, hör av dig så fort du kan! Skicka CV och personligt brev till / 073-5071463

Copyright © Edument AB. All rights reserved.