Kartones Blog

Modern Software Architecture: Domain Models, CQRS, and Event Sourcing is a 4.5 hours course about Domain-Driven Design (DDD) fundamentals, Command Query Responsibility Segregation (CQRS) and Event Sourcing, plus introductions to Event Storming and UX-Driven Design (Top-Down Design instead of the classic Bottom-Up).

I really liked the content and everything is very well explained, with simple diagrams and examples. Code examples are C#, which shouldn't be a problem as it's a clean easily readable language and the examples are uncluttered and direct to the point. What you should be aware of is that "spoken examples" are also mainly focused on .NET, so if you haven't worked with that stack you might not know what frameworks like LINQ or Entity Framework are. Nothing terrible, and some examples are language-agnostic, but the majority are focused for .NET developers/architects.

Recommended for anyone wanting to learn some basic DDD concepts.

Posted on 2020-04-06

I was listening to a Hanselminutes podcast episode about LEGO education's new Spike Prime set, when I heard something quite interesting: After generations of C-based firmwares for the LEGO Mindstorms family of intelligent bricks, the Spike Prime actually runs a MicroPython micro-controller. I feel joy but at the same time I feel a bit old, to think how much we've advanced so that now any kid can easily build and code a robot using Python...

When I was young, I fell in love with the original Mindstorms, and since then, I've collected all three generations (four if we count the Micro Scout). While I gifted most of robots and pieces last year to an electronics and robots lover friend, I still remember the fun weekends and nights learning how to build the robots and how to modify the firmware to code them with my language of choice. Steps that you don't need to take anymore it seems :)

If you haven't heard before about the Mindstorms LEGO family, hackeducation.com has a small but nice technical summary, and I will provide links to the Wikipedia relevant versions too below.

LEGO Mindstorms Micro Scout

Let's be honest: The Micro Scout was a glorified motor and IR receiver that came with the pieces and instructions to build a cool AT-AT with the Dark Side Developer Kit, or an even cooler R2-D2 with the Droid Developer Kit.

I don't keep decent-quality photos of it but a photo from the instructions is good enough:

LEGO Mindstorms RCX

The RCX was the first generation, and it was released in 1998 but I got mine either on 1999 or 2000, I don't remember exactly.

It was a v1.5 (there were a v1.0, v1.5 v2.0 revisions). I coded it in C at first, then in C# with LEGO.NET. It was the most entertaining one to "hack" as there was no official custom firmware support, plus initially I had to connect it via a serial port. I bought a USB IR tower later and what a difference! It also meant more portability as serial ports dissapeared long ago :)

I had all expansions I could get my hands of, from Vision Command (camera was terrible but still great to do color recognition back then) to Exploration Mars (the springs/suspensions and different sized wheels were awesome), plus some extra LEGO Technic pieces.

At the end of the instructions you could see the back of a modified R2-D2 using the RCX brick. Again I don't keep non-terrible photos of my build, but was the same as the one in the following image. Note that the R2-D2 head is turned, we're shown actually the back of the droid, it is like a V-shape seen from above, with the tip forward, not backward:

LEGO Mindstorms NXT

The second generation of Mindstorms bricks, the NXT, allowed a much easier development as if I recall correctly the specifications of the commands were published so interacting with it was very easy. I got mine the year it was released, in late 2006, during a trip to Australia.

I coded on it with C#, using NXT.NET but also directly from Microsoft Robotics Developer Studio. As you can see not only you didn't needed a custom firmware, it also provided an IDE-friendly interface, especially since you could send the data and commands via Bluetooth. You could even use a PocketPC PDA to remote-control it.

LEGO Mindstorms EV3

The EV3 is the current generation of Mindstorms, released in 2013.

Much more powerful, it is so hacker-friendly that supports booting custom firmwares via Micro-SD card (instead of overriding the built-in one), LEGO has published the full source code of the operating system, and is even compatible with the NXT sensors, so it has really very few limitations to what you can do, except of course your imagination.

With this brick I coded mostly using the bricks UI, as it is so powerful it was handy to just drag & drop blocks and change a few parameters (by the way, you can code programs just with the own brick on its own!). But for a change I started building a NodeJS library to program it. I didn't went too far with the project, but what I built worked nicely and was a fun exercise in reading the operating system's source code and adapting it to Javascript.

Although I skipped trying to do it with the NXT version, my beloved R2-D2 was due for an update, so my last project before deciding to stop playing with the Mindstorms family is an EV3-based R2-D2:

The front is missing some panel or cover, but I wanted easy access to the steering wheel/leg until was finished, and it was missing also the famous beep sounds (which you can add to the EV3 too), but is mostly functional and moves forward, backwards and rotates (plus can be controlled remotely via Bluetooth).

I never got to build real sumo or racing robots, but I feel that with Mindstorms, I've spent two decades doing almost the same, just forgetting about the hardware and solding aspects. Thank you LEGO for providing such great tools and being so developer-friendly.

Posted on 2020-04-05

Review

Title: Infinite Game Universe: Mathematical Techniques

Author: Guy W. Lecky-Thompson

I don't even remember since when I had this 2001 book, only that I bought it second hand because I read it was really interesting and procedural generation of content is something that always has intrigued me. Not having found a digital version or scan anywhere, I decided to read it in paper before gifting it to somebody.

It's a ~300 pages hardcover book with a CD-ROM, which sadly was in such bad shape I couldn't read it, although I'm probably not going to miss the source codes as I've been able to code my versions of some algorithms and examples.

As the title hints, most of the book is about procedural generation of content for videogame universes. No matter if we're talking about planet or character names, lore texts, polygonal trees, complex shapes like a human face or a full universe composed of galaxies, stars and planets, we're taught multiple techniques to generate random numbers and, most important, sequences of those numbers. We're also explained how controlling the values of the numbers is as important as at least knowing that any non-purely random algorithm will tend to reach a pattern, where numbers will start repeating. Combined with statistics, probability and different algorithms, we'll learn to generate content for our games and even improve the storage of the data (e.g. we're explained how the RLE compression algorithm works), and what makes fractals interesting for pseudo-random number generators.

In general the book is well explained, detailed and with abundant examples, some carried over through multiple chapters, up to the point that a few chapters contain almost no theory and instead two or three applications of the topic with the examples (images included). I like it because it helps consolidate what you're learning, but at the same time you can skip a few pages if you already understood it. A big chunk of the examples encompass adjacency tables (via words), line-art (via tree behaviour) and (coordinate systems (via images) as sources of data. Also the final block of chapters are a "full" example of a space exploration game, applying a few of the concepts explained before. It really doesn't apply everything (at least in the book, maybe the source code did) but still makes up for a decent example of object serial numbers and seeding.

Not having the original source code CD I had to reimplement in Python (instead of the book's C) some of the formulas and found a typo or two (my book it's a 1st edition), but where pretty simple to correct.

While most of the contents are clear to understand, a few of the examples are not very detailed and confusing on how to achieve them; for example, after talking about affine transformations we see some formulas and an image of a generated fern plant. We see two formulas and a table of affine transformation values, but no clue of how do you actually paint it, because the description of how the affine transformations are applied is incomplete. In the end it is just explaining Barnsley Fern fractals but a) curiously without giving the exact name and b) not properly explaining the formula and steps, just throwing a bunch of formulas and values and saying "if you input this and feed last values arrive to this fern drawing". It feels nice to learn not only how they are drawn but why they are so cool, but I should have to go to Wikipedia when in theory I have a bunch of pages detailing it.

I felt that the whole block about fractals contains much theory and not so much practical use, feels a bit incomplete. Talks here and there about subjects but without almost any specific example, like "Pac-man ghosts can share same movement behaviour" (of course, but how does this relates with fractals?). We are indeed shown how to modify object adjacency tables with a Mandelbrot fractal, but I feel there are too many pages on the topic for such few applicable results.

Despite my small complaints, overall a great resource for learning the basics of procedural content generation, and it opened my mind of how important is choosing the data set and/or the algorithms, and that even "bad" things (like repeating patterns) can be controlled and put to good use.

Posted on 2020-03-29

In order to stop spamming with so many English course reviews (2 weekly hours ain't bad), I've decided to aggregate as a single monthly post all of my reviews of finished courses.

50 English Phrases, Idioms, and Expressions for ESL Students (Udemy course): Free course, around 1h long. Very nicely split in either a single or a pair of sentences per lesson, so you can ingest it either in short bursts or in a single session. Well organized and recorded, and I gladly found a few new idioms I didn't knew, so considering the cost, more than recommended.

English for IT Professionals (Udemy course): Quality and audio volume varies with each lesson, nothing terrible but it is annoying to have to be turning up and down the volume between different videos, or seeing Mac brightness controls pop-up, etc.

It has a good list of terms, vocabulary and even a few IT slang sentences (e.g. "blamestorming" or "hamster wheel"), plus the grammar part is always exemplified with IT-related topics and sentences. It is interesting but it felt to me lacking more content.

Business English: Easy English for Meetings (Udemy course): This course has abundant speaking mistakes, of which I'm normally not against, but here you will notice them quite often. Also, when you provide a "sample text" and say "I'm going to read it", you expect to exactly read it, not summarize it. And finally, slides go way too fast, when the teacher wants you to read them just mentions it and moves to the next slide, so it's hard to even pause before it goes away.

Despite those complaints about things that could be improved, it is an interesting and topic-focused albeit short course.

Posted on 2020-02-28

World War Z is an amazing zombies book with a terrible and unique movie adaptation. As far as I know, it is the only zombies film not featuring a single drop of blood or seen zombie bite, I guess because they spent all the budget on both Brad Pitt's salary and the marketing campaign. But there are learnings even in bad things, and this scenario is no less. In one scene, a character describes the 10th Man Rule (also known as devil’s advocate), which proposes:

Produce a range of explanations and assessments of events that avoid relying on a single concept [...].
If ten people are in a room, and nine agree on how to interpret and respond to a situation, the tenth man must disagree. His duty is to find the best possible argument for why the decision of the group is flawed.

Now, this rule can be real or can be fictional, but anyway I like it and sometimes apply it. Usually in the context of everyone saying the pros and I focusing on the cons, but the opposite can also happen.

I think this rule is relevant in discussions because in a perfect world we would gather different experts and stakeholders and spend as much as needed thinking and talking about approaches, choices and trade-offs about any proposal or technical requirements specification, but the reality usually goes more along the lines of:

• If the proposal comes from Product, usually speaks little of trade-offs and difficulties (other than listing existing ones as justification for the proposal itself)
• If the proposal or tech spec comes from Engineering, my general feeling is that, with all this "perversion of agile" we can now mostly say "I wanna do X" and just jump into building it, losing that phase of properly researching or simply giving some thoughts to how to achieve your goal; what I sometimes call "think before you code". I am not a fan of endless documentation, but writing a tech spec forces you to think about your action plan at least once [1].

Circling back to the main point, we can say we usually attend a meeting or review a proposal which many times lacks depth. Now, ignorance is bliss they say, and sometimes that is good because if you don't know you can't do X because it's impossible, you might find a way to actually do it [2]. But often those meetings are either echo chamber or an environment where there's some aversion to voice concerns (to "say no"). I'm pretty sure everyone has at least once been in a situation of being faced with everyone else thinking "A is best" while we think "Are you all blind? B is clearly best!".

The purpose of this rule is not be an excuse to become the grumpy person who always points out the flaws, but to enable discussions that challenge the main approach and avoid group thinking (which usually impedes individual thinking). Note that this does not mean you can be disrespectful or impolite, of course.

It is nice to do positive thinking and generally seek a "how yes", but we must not forget to also think about the "why not" at some point.

[1]: I view it the same as explaining a subject to somebody else helps you study it. Forcing to explain or detail something enforces retaining what you learn.

[2]: Wasn't some quote along the lines of "Nobody told me it was impossible, so I did it"?

Posted on 2020-02-16