This will be (I think) the last post in the exploration of LED pattern control. I’m going to build on the previous post to explore how we might include brightness in the design, as this was one of the features that would have been delivered if we had used “The Electrical Engineer Way”. There are two main designs that spring to mind here (nevermind there are many ways to achieve them):

Just a quick post with an example sketch for how to setup timer 3 on an Arduino Yun to control the brightness of an LED. I had to go through figuring this out while experimenting with brightness and flash patterns. Anyway…. It’s just a simple sketch. I’m not really sure why a prescaler of 1 doesn’t work (I guess the LED switches on and off too quickly). I’m not going to explain the ins and outs of a PWM for LED control (there are lot of good examples on the web).

The last post ended just before the real deal…patterns with colours. However, this post is hot on its heals because adding colour support is straightforward…it is entirely controlled by the “application space” code. That’s right…all of the “Led Manager” stuff can be used unchanged…as can all of the code that changes the states. The only code that needs to be adjusted is the code that registers the patterns. It needs to be updated to:

So where to next? The code from the end of the last post is a long way from anything useful, but the point is to illustrate an idea more than deliver a library. We should, however, have the goal of some sort of “Led Manager” in mind, that can encapsulate some of this behaviour around managing LEDs and the patterns we want them to show. A LED Manager, how it might look One of my favourite Eric Evans quotes is (paraphased) “client code ignores the implementation, developers do not”.

Every embedded product since the first Blinky program has had its own variety of LED flash patterns. You know the ones I mean, flash green once every two seconds if everything is ok, and once every half a second if something bad has happened. But it never stays that simple. There’s always someone who says “that’s great…but for serious errors can you flash like this, and for warnings like that”, and before long you have a plethora of patterns that make the POST beep patterns look paltry.

TL;DR I made a demo project of how to use Golang to produce the map tiles for use in LeafletJS’s tile layer. I did it mainly to catalog how I managed to solve a few of the issues I had faced in a real-world project, just in case it would be useful to someone (future me included). Some of the things I had to solve were: How to tile map images on the fly in Go How to cope with updating the image for a given area (e.

Overview I found that my Golang port of the SimpleCQRS project had a) a few errors that I really should fix, and b) should probably be refactored to be non-blocking on the command submission (up for debate I guess). While fixing them I discovered a new way to look at eventual consistency (and learned to be ok with it). First, the fix I decided one day to run Go’s race detector on the code from the original port, only to find that there was a data race!

TL;DR I ported Greg Young’s Simple CQRS Example to Go. Check it out here: Golang Version. Why Mainly because I wanted to see if I could implement something very similar in Go. In particular, I wanted to see if I could find a way to implement the functionality of the AggregateRoot abstract class (without using the method overloading that it relies on). Interesting bits The C# example uses subclassing and method overloading to make sure the correct logic is called on the aggregate root objects for both commands and events.

TL;DR The Repository pattern is commonly used in DDD / Clean Architecture / Hexagonal Architecture projects. However, porting a Java/C# reference implementation of this pattern to Golang is not as straightforward as it seems. By forcing ourselves to avoid the ‘questionable choices’ common in many examples of this pattern in Golang, we can arrive at an interesting variant of the pattern. Intro I stumbled across a dodgy hybrid technique for implementing the repository pattern in Golang that I think it quite useful and practical, especially for smaller projects.

TL;DR Thinking about deleting objects and records can often lead to good modelling insights. However, most patterns, guides, prototypes etc focus on creating, updating and persisting items, and gloss over the issues presented by thinking about delete. I recommend putting “delete” into the early use cases and/or repository-style interfaces, as it forces you to address assumptions about the lifetime of objects and what it means for their relationships. How I came upon this Most prototyping is about getting something to demonstrate.