I finished this painting a while back, but didn’t put it up yet. Forgot to sign it too.. Oh well.. I’m pretty pleased with the end result anyway 🙂
Again, it’s based off real live material. (A screenshot of a documentary. I wonder who recognizes it … 🙂 )
On the photograph, the varnish looks rather blotchy. The colours are not as vibrant as I’d have liked, but this is the first painting I did where I didn’t plan the whole thing from the start. The lighting also doesn’t do it justice, because the weather balloon isn’t as bright in the painting as it looks here. So, despite the colors being a bit off in both the painting and photos of the painting, I’m very happy with the end result and the lessons learned 🙂
Suppose you’re working on a software project and you’ve tagged your release 0.1.0. It has been shipped and now you’re working on version 1.0.0. You’re reworking quite a lot. It’s a major release after all, a lot to be done 🙂
In comes someone who sees version 0.1.0 and thinks to him/herself: “Oooh, can you maybe add some functionality on top of that? I don’t want to wait for 1.0.0, that takes too long.”
Although the ‘building a house’ metaphor is a strained one when it comes to software, it can be used to abstract away from the nitty gritty detail of software development and describe things like project management and development strategies. Today, let’s discover some of the superpowers we have in software-land, and what their limitations are. And let’s use our superpowers to build a house 😉
Version control, especially Git, grants you the powers to:
- work in parallel universes (branch)
- go back in time (branch from older release or commit in the past)
- automatically replay anything you did in a parallel universe in another parallel universe (merge or rebase)
This is convenient when we’re doing things that are unrelated. Two developers could branch from trunk (or master or main stream) and work in their own branches quite comfortably, as long as they don’t do conflicting things in the code base. Or, to strain the house metaphor to its breaking point: Someone could be installing a new kitchen while another team replaces the roof.
Ahh, Christmas holidays. The perfect time to muck about with electronics and software. I never thought I’d enjoy electronics this much.
Admittedly, I didn’t make a lot of changes the LEDwall prototype, I just finished it up. I soldered the base of an Arduino Nano to a little soldering board, installed the Nano, trimmed some wires and I added proper connectors instead of twisting wires together and applying duct tape.
I got rid of the GUI and networking stuff that would allow me to set the program remotely. Instead, I added a little jumper to be able to switch the program every time the Arduino starts. Then, I wrote some code to turn the whole thing into a `Do not disturb’ / ‘I am available’ sign.
Besides the two shown above, I’ve also made a blinking display of the letters ‘O-K’ and ‘N-O’ in green and red respectively. It’s a bit painful to look at so the first option (green circle and red cross) seems most useful. If the jumper isn’t here (if I’ve lost it 😉 ) it shows a spiffy flashing raindrops thing that is sure to induce an epileptic seizure.
The past few weeks, I’m observing the appearance of a new ‘discovery’.
The discovery is this: You can describe people’s communication style / personality type with four colors!!!111one
There’s RED, for the strong-willed, fast-paced thinkers.
There’s YELLOW, for the sociable, excitable, “ooh, shiny light”-type persons.
There’s BLUE, for the detail-focused, precise analytics.
And GREEN, for the relationship/feeling-oriented person.
It’s a hype. It’s The New Thing. It’s AMAZING. Aannd… it’s really old :’)
Someone has been using EJS (or similar) and forgot to add an = sign
The WordPress plugin I wrote, Category Posts in Custom Menu, supports custom extensions. Recently, I wrote an extension for someone who wanted to show all posts from some category, say “category A” that were ALSO in “category B” AND NOT in “category C”. So, I helped out (coding, yay) figuring it would give me an idea of whether the extension possibilities I created make sense.
If you’re interested, you can now find all the source code at GitHub. This extension was aptly (ahem) named “cpcm-and-and-not-extension”.
#warning This is going to be a nitpicky post.
There was once a developer who marked his code with TODO’s.
// TODO does not handle case X
public void Handle()
// TODO clean this up
var ugly = ...
// TODO re-enable after Y is implemented
// if (bla)
Another developer used warnings.
#warning still have to write test for this
case a: i = 4; break;
case c: i = 1;
default: throw new InvalidOperationException();
I’m writing this blog post to illustrate subtle but significant differences between four mechanisms that can be used for a shared goal: To mark what still needs to be done.
A while back, I talked with someone about using the Singleton Design Pattern vs. using an IoC container and registering your class as singleton.
IoC containers are regularly bootstrapped wrongly, resulting in your product not working as it should. And you don’t discover that until you startup the product. I’d rather use the Singleton Pattern. That way, the compiler will protect against errors.
In January of this year, I invited a couple of friends for an archery workshop and dinner.
The goal was to hit the balloons taped to the target and at some point I exclaimed I’d paint a picture of the first person to hit a balloon.
I try to make good on my promises 🙂 though I had to ask her for a photo of said painting, because although I swear I took a photo for my own private collection before I gave the painting to her, I can’t find it anywhere.. whoops..
Ahh, placed it in a wrong folder somewhere, here it is: