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 emelie.andersson@edument.se






Olof Brodén

Olof når du på: 0735-31 61 01 och olof@edument.se

Varmt välkomna!



Jenny Edument

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

Edument Intentful Testing Starter Kit + EventStore


A while ago we published our Intentful Testing Starter Kit. To persist events, it needs an implementation of the IEventStore interface. In the starter kit so far we’ve had two implementations: an in-memory event store, and one that builds a simple event store using a SQL database. However, there are many other options out there, including the wonderful EventStore!

It’s not too hard to write an implementation of IEventStore that uses EventStore, but for those not quite sure how to do it (or just too lazy!), there is now an example in the starter kit repository.

Read more










March 28, 2014 at 9:32 am Leave a comment

Git teaching in China

Lately, we at Edument have been teaching Git in different places around the world. Scandinavia, Spain, Saudi Arabia, China. Now it’s time for Shanghai for the second time.

git logo

Different parts of the world feel different to teach to. I for one, look forward to a room full of voraciously interested participants, like I had in Shanghai last time.

In some ways, it feels surprising that we spend so much effort talking about Git, and that there is such a demand for it. After all, Git is just a version control system. We’ve been version controlling stuff for decades. How different can Git be? It’s almost like someone buying a new kind of running shoe, and then spending their days convincing friends and relatives to buy it, too. “Really, you’ve got to give this running shoe a try! It’s awesome.”

Does Git really live up to the hype around it? Yes, we believe so. At Edument, we’ve been relying on Git since the company was founded, and Git operations thread through our work every day. Here are the things that we feel make Git different:

  • Git is built to support fast branching and merging from the ground up
  • Git has a few basic primitives that it uses consistently across the whole system
  • Git is very transparent and open-ended
  • Git allows you to choose your own workflows, tailored to your project
  • Where Git ends, it has various tools — hooks, scripts, custom subcommands — that you can use to make it even more useful for you
  • All of this means that you can focus on your project, not struggle with the version control itself

image of a parkour runner jumping over something

So yes, Git is clearly superior to the previous generation of version control tools we had. And it’s liberating and fun to travel around to various groups and teach this tool that we know has made our own workflows better, and can help make our clients’ lives better too.

Git gives you a certain measure of freedom. Not only is it a light and comfortable running shoe; Git is the running shoe that allows you to run along walls and do crazy jumps between buildings that you wouldn’t even have dared contemplate before.

Hoping to give a progress update by the end of the next week; not just about the week of Git teaching, but also about our future plans with Git courses.


// Carl


March 24, 2014 at 6:39 pm Leave a comment

Låt oss presentera JetBrains – vår nya partner

JetBrains har specialiserat sig på att skapa intelligent och produktivitetshöjande programvara. Företaget är en världsledande utvecklare och är bland annat känt för sin innovativa och prisvinnande integrerade Java-miljö, IntelliJ IDEA.

Genom vårt partnerskap kan vi erbjuda licenser till samtliga av JetBrains programvaror, rådgivning och utbildning på inducerande och avancerad nivå. Oavsett era behov så kan vi hjälpa er med hela kedjan, från rådgivning och försäljning till att implementation och utbildning för JetBrains produkter.


Med rätt kunskap kan JetBrains produkter göra stor skillnad för er mjukvaruutvecking. Vi hjälper er att utbilda allt från enstaka personer till hela projektgrupper, allt för att ni ska få ut maximalt av de verktyg ni väljer att använda. Vi kan anpassa utbildningen helt efter era behov.

Tillsammans med JetBrains tar vi kontinuerligt fram kurser för samtliga produkter inom JetBrains produktkatalog. Ta till exempel en titt på vår senaste kurs:

Productive development with ReSharper

En lyckad implementering gör att arbetet flyter på redan från start. Självklart kan vi hjälpa er med att komma igång med era nya JetBrains-verktyg. Vi kan sköta hela implementeringen på plats eller genom att assistera er med rådgivning och teknisk kompetens.

För mer information, besök www.jetbrains.com eller skriv till dem via www.jetbrains.com/company/contacts

Vi ser en ljus framtid med JetBrains som ny partner och hoppas att ni också ser värdet i vårt samarbete.


Jenny Edument

March 6, 2014 at 10:14 am Leave a comment

Pink Think Tank 2014

Pink Think Tank 2014 – En tankesmedja för ITSM

Under årets Pink14-konferens samlades de främsta inom ITSM för att diskutera framtiden, utmaningar samt dela med sig av sina erfarenheter och vad de kom fram till. Idén till Pink Think Tank (PTT) kom till under förra årets Pink13. “Varför inte göra något när så många av de ledande personerna inom ITSM-industrin ändå var i samma “rum”, varför inte samlas för att diskutera ITSMs utmaningar som även kan delas på konferensen och efteråt?

Initiativet leddes av Rob England ( The IT Skeptic ) och Pink Elephant. Syftet med PTT var att samla några av världens ledande ITSM-konsulter (“tänkare”) före konferensen för att diskutera några av de tuffaste utmaningarna inom ITSM idag. Ämnet som valts för PTT var “Increasing Multi-Supplier Value Streams” och vad det innebär för ITSM-industrin . Målet var att tillhandahålla pragmatiska angripbara råd. Valet av ämne drevs av det faktum att det behöver vara generellt nog att vara intressant, men ändå smalt nog att hinna med på en dag.

PTT  presenterade sina resultat på första konferensdagen. Sista konferensdagen var det en paneldiskussion för konferensdeltagarna där vi kunde ställa frågor.

PTT genererade många intressanta utmaningar och frågeställningar som naturligtvis blir föremål för ytterligare diskussioner och utveckling framöver. Nedan följer en sammanfattning av några av de viktigaste diskussionerna och det som presenterades för oss deltagare. Det första PTT gjorde var att definiera problemet.

IT pressas allt hårdare. Verksamheten kringgår IT och söker lösningar på annat håll s.k. “Shadow IT”. Leverantörer och verksamheten pressar på från båda håll, då de uppfattar det som att “IT” reagerar långsamt. Samtidigt har verksamheten fler möjligheter från allt fler leverantörer som gör det möjligt att “gå runt” den interna IT-leveransen. Det är tuff konkurrens och det går fort, både verksamheten och tekniken utvecklas i ett rasande tempo.

Verksamheten tvingas till förändring och måste minska ledtiden till marknaden för att möta konkurrensen. PTT tror att den traditionella IT-verksamheten inte är redo att ta itu med denna förändring. Leverantörerna har nu blivit väldigt bra på att hantera standardiserade miljöer. Slutresultatet blir att det kommer vara nödvändigt att på ett dynamiskt sätt hantera en komplex miljö, där många leverantörer agerar.

Allt som vi har gjort tidigare är inte längre tillräckligt. IT blir mer “känslig” i en multi-sourcing strategi eftersom vi har en tuff utmaning när det gäller snabba och växande behov, vilket i sin tur lätt leder till “Shadow IT”.

Hur ska det hanteras? Det är ett växande problem och det är komplicerat och inte lätt att hantera. Kommer “IT” att bli mera av en “mäklare” för leverantörer och flervalstjänster?



När produktifieringen ökar, förflyttas den traditionella IT-rollen till att bli en tjänsteleverantörer.

Företagens innovation kommer att accelerera med hjälp av framväxande teknologier och “bädda in” dem i sina affärsmetoder.

  • Allt som inte visar en tydlig skillnad (av ökat värde) är en möjlig för någon annan (extern part) att ta hand om.
  • En tjänst (eller specifikt resultat)  kan idag tillhandahållas av många leverantörer och leverantörerna är duktiga på att driva denna “marknad” framåt.
  • Leverantörer kommer att utveckla tjänstelösningar och verktyg för att stödja det en enskild organisation inte kan göra på egen hand.
  • Leverantörsskiktet kommer att utvecklas och kontraktstiden förkortas.
  • Förändringarna på denna marknad, “fler-leverantörsmiljön”, kommer att driva förändringar i hur IT organiseras och förvaltas.

Framtiden är IT-styrning (Var finns Enterprise Governance?), service management.

Organisationer bör titta på följande:

  • Bygga en stark policy i hur verksamheten ska styras samt hur Supplier Management i form av processer, roller och “garantier” ska hanteras.
  • Lära känna sin verksamhet – Bedöm hur väl du förstår din bransch och hur IT: s värde kan fylla detta utrymme.
  • IT behöver definiera en värdedriven verksamhetsmodell och verksamhetssätt som spänner över hela företaget.
  • Definiera vilka operativa modeller som ska tillhöra kärnverksamheten.
  • Service Management (och ITIL) bör fortsätta att användas, men med förändrad tyngdpunkt och andra prioriteringar, t.ex. Supplier Management, Demand Management, Service Portfolio Management and Business Relationship Management.
  • Utveckla “IT Supplier Management” till att vara en del av företagets kärnverksamheten.
  • Ha en plan för multi-leverantör som stödjer en balans mellan organisatorisk innovation och produktifiering.

Det vill säga börja jobba med det som står i boken Service Strategy, det blir tydligare att just den boken blir viktigare och viktigare.

Vilka val har du?
Vänta inte börja nu innan det är försent.

  • Förstå hur dina tjänster kan skapa mervärde för verksamheten.
  • Fundera över hur det framväxande alternativet av en multi sourcing-miljö kommer att förändra din roll eller jobbet i framtiden .
  • Förstå vad DU kan göra och prioritera efter det.
  • För Supplier Management:
    • Utvärdera dina befintliga metoder för att hantera avtal och leverantörer
    • Inventera befintliga avtal , ägande och relationer
    • Kartlägg kontrakten till affärsresultat och/eller SLA
    • Utvärdera befintliga leverantörers möjligheter och kunskaper
    • Omprioritera Supplier Management , Service Portfolio Management , Demand Management och Business Relationship Management
    • Ta hjälp där det behövs

PTT – Nästa steg
Detta varken började eller slutade i Las Vegas. PTT kommer att fortsätta under året med att ta fram “white paper”, skapa en “online-närvaro” för att leverera innehåll och ge möjlighet till dialog. Ytterligare evenemang såsom webbseminarier och planeringen för en ytterligare PTT nästa år med ett annat ämne och deltagare är givetvis också att vänta.

Källa, Referenser och läs mer:




Johan-web  Pink14-200x100

March 5, 2014 at 10:01 am Leave a comment

Older Posts


Get every new post delivered to your Inbox.