- Det ger en tydlig riktning för att säkerställa att IT-investeringar stödjer verksamheten
- Det är ett effektivt sätt att hantera förändringar
- Det skapar värde för verksamheten i linje med företagets mål
- Och det adresserar hela livscykeln för IT-investeringar
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.
To find booking and more information, see our event Event Store Workshop with Greg Young
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.
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.
Three stages of grief
- Learn the language extremely well, so we can use it well.
- Improve the language step by step (without breaking anything).
- Wrap the language in a nicer language and use that instead.
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.
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.
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.
A bit more in detail:
Try it now
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.
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?”
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.