Brain dump #2: How I'd implement Tesla's Autopilot feature - levels of AI

About two weeks ago, I decided to have some healthy life changes, and one of them is walking to my office. This walk takes about half an hour, so it is easy to fit this in my daily schedule. My daily walk to and from the office… pic.twitter.com/GPi3WGOPKr — Tom Janssens (@ToJans) 23 november 2015 While walking to my office, I think about my goals for the day, and on the way back, I self-reflect and think about the things I did that day.

Brain dump #1: How I'd implement Tesla's Autopilot feature

I recently saw this tweet by Elon Musk, who is looking for developers for their Autopilot feature: We are looking for hardcore software engineers. No prior experience with cars required. Please include code sample or link to your work. — Elon Musk (@elonmusk) 20 november 2015 As a long time Tesla fan, I couldn’t help but wonder what kind of solution they will come up with, so I decided to do a little brain dump myself: Requirements Trustable Above all, software should be trustable.

DDD elevator pitch

DDD elevator pitch@ToJans In business, you make fine-grained adjustments all the time, in order to stay ahead of the competition. Software tends to be rigid and hard to change. Domain-Driven Design tackles this paradox, and considers software a living thing - just like your business. By making the implicit concepts from your business explicit, DDD will give your software the ability to keep up with the agility that your business requires.

Hangman in Haskell

As I noticed a question for a more idiomatic Haskell version of the game Hangman on codereview.stackoverflow.com, I decided to give it a go; this is the result: Note This article has been posted on Reddit’s Haskell channel, and gradual improvements were made on this article based on tips in the threads, so feel free to check these. Tips Most idiomatic Haskell code I see has a very high signal to noise ratio.

How to explain dependent typing

Take an average programmer - let’s call him Joe D. - and have him talk to a fictitious academic called Alan T.: What doesn’t work Alan: Hi, Joe, what’s up? What can I help you with? Joe: Hi Alan. I heard about this thing called Idris and you are the expert; what is Idris exactly? A: It’s a dependently typed language, why are you asking? J: Well, I heard you can improve your code with it, but I haven’t got a clue how it works.

about dependent typing, Idris and the road to Valhalla

Due to my DDD background, I am constantly on a quest for the utopian domain model. Last week during the Build Stuff 2014 conference I saw a presentation by Amanda Laucher about dependent typing that spiked my interest. Here is a short interview with her: I somehow feel that dependent typing might bring us one step closer to the utopian domain model, and in this post I will try to explain you why I think this is the case.

CQRS and functional programming

So, a little while ago, while I was studying Haskell, I decided to implement Greg Young’s SimpleCQRS example in Haskell. During the last @DDDBE event, I was showing this to Mathias, and he decided to put it on the big screen. The general response was: What’s missing from Greg’s example? And my reply was that nothing was missing. As people seemed to be flabbergasted by this code, I decided to convert it into a blog post.

Growing software teams: size DOES matter

Growing software teams The problem Consider the amount of different communication channels (that relate directly to communication overhead and potential misunderstandings) on teams growing in size using the formula N*(N-1)/2: 1 person: 0 channels 2 persons: 1 channel 3 persons: 3 channels 4 persons: 6 channels 5 persons: 10 channels 6 persons: 15 channels 7 persons: 21 channels 8 persons: 28 channels 9 persons: 36 channels 10 persons: 50 channels … Having a team of 10 people creates 50 potential communication channels, and I can guarantee that, the more channels you have, the worse the communication between them gets.

DDD 101 tips

Here are my tips for getting started with DDD; they were written as a response to a question in the BE-DDD newsgroup: IMO taking a look at the domains from a different POV also helps; f.e. now you only looked from a data-oriented POV; here are some possibilities: Find the use cases that define the behavior of your system Use personas and documents Try context mapping; you will probably have f.e.

DDDBE meetup #2 - Legacy Inferno

After the great feedback of the first event, the Belgian DDD community had to do a second one, and last Thursday we did: De @dddbe meeting at @nucleus_hosting begint behoorlijk vol te lopen :) pic.twitter.com/E70TaIvQNd — Chris Ramakers (@ChrisRamakers) October 17, 2013 We would like sincerely thank @nucleus_hosting - nucleus.be for providing us a location and some food! We'd be nowhere without companies like @nucleus_hosting who provide us with a location.

DDD in a tweet

The essence of DDD: make the implicit explicit (language, boundaries, code) and evolve your model so it matches the domain /cc @julielerman — Tom Janssens (@ToJans) June 23, 2013

IDDDtour 2013 Belgium - an immersive experience

Introduction: what & how?

Implementing Domain-Driven Design is a book written by Vaughn Vernon, and you can consider it a practical guide to the blue book - a lot of people consider the blue book to be used as a reference, but it takes some persistence to read it -. Vaughn tried to solve exactly that problem with his book…

A little while ago, Vaughn Vernon was tweeting about how had given a free course about his book “Implementing domain driven design” while visiting Bogota, Columbia. This course was given for free to help start-ups there.

In the next few hours after this tweet, an idea emerged on twitter about a concept called the IDDDtour, where Vaughn would be teaching his book to larger classes and doing a tour through Europe, but at a fraction of the cost. As I am somebody who is more of a head first kind of guy, I decided to take ownership and figure out a way to make this a real thing…

Continuous thinking: CQRS explained to a 10-year old

Introduction The concept behind CQRS is neat: detach your domain implementation completely from your representation requirements. I even wrote a framework for it as a learning tool, so somebody without any prior experience should be able to boot a CQRS app in a few minutes. The main idea behind this framework is providing developers new to CQRS an operating room where they can compose their own little CQRS Frankenstein app. The whole framework is constructed in a way that it forces you to make your domain implementation completely persistence ignorant, respecting typical AR/transactional boundaries.

Continuous thinking: why a 4GL should be avoided to start a new app

Introduction As an avid member of the DDD/CQRS discussion group, somebody asked me what I meant with the following sentence: it looks a lot like a 4GL, and I assume we all know what that means… Since I tend to think my answer formulated my ideas pretty well, I decided to post it on my blog too; I hope this might help some of you to avoid the 4GL pitfall…   Why should a business avoid writing apps in a 4GL ?

Winning the game with CQRS/event sourcing and BDD

Yes !! I did it !!! I have been making a few attempts to combine BDD with CQRS/event sourcing, since they seem to make a perfect fit. After mailing to the DDD/CQRS newsgroup for a few times, I finally managed to make something presentable… this is the BDD part for the domain : And this is the resulting output after running the console runner This is the context, notice how setting up the interpreter usually only takes a single line (i.e.