I recently had the need to quickly visualize some data and none of the systems I usually work with had the data. Initially I dumped the data in Google Sheets and created a chart there, but that was slow and didn’t really scale well. The data had to be cleaned, brought into the right format, columns had to be selected and charts created. At this point I faintly recalled reading about gnuplot which, despite its name, has no affiliation with the GNU project.

I recently received my copy of Working Effectivly With Legacy Code and have been busy reading it. The book, as a product of its time, has examples of not only Java, but also C++, probably to show concepts and techniques that apply to languages that behave differently in terms of linking and building. But regardless of its examples not really applying to what I work with, it was full of useful vocabulary and techniques to work with not only legacy systems, but really, any kind of system.

Google recently announced availability of 1.0 preview of Flutter, a new framework for building mobile apps, written from scratch with performance and beautiful UIs in mind. I’ve always been interested in building apps for mobile devices in general and Android in particular thanks to the number of Android devices I own, but was always discouraged by the complexity of building Android apps. I have one on the Android store that got too unwieldy to work on and I eventually had to cease development due to time constraints. Now with flutter closing in on its first release build I got interested, not only because it is a new beginning to building mobile apps – and we all know that developers love newly built things – but also because it uses Dart, Googles attempt to create a language to replace JavaScript that, sadly, went not far.

I had this book on my wishlist for quite a while, but never thought I needed it. But then it was warmly recommended to me during a fantastic OOP Workshop with Sandi Metz. If Sandi recommends it, it must be good. Excited to dive into this one:

A coding exercise I do once in a while is writing Battleship. It’s a fun little exercise, comes with a slew of interesting decisions, and every once in a while I do this exercise with a candidate as part of the interview process. It’s always exciting to see what other developers come up with. Today I was doing the exercise and I contemplated on the primitive obsession code smell that always seems to creep into my code and saw a beautiful way to apply the extract class refactoring that very succinctly shows how nice object oriented programming can be.

For the past year or so I’ve been writing a lot of Scala and fallen in love with its Option type and how it allows me to avoid nulls. I reflected on null, why they are bad, and how optional types allow you to write more expressive code.

What is null?

Most programming languages have the concept of null (or nil) that represents the absence of a given value or object. At it’s surface the absence of a value probably just translates into a pointer of value 0x0 or in languages that do not zero variables, a pointer anywhere into the memory. But aside from the implementation details the more interesting question is how null fits into a language’s type system.

After toying around with the really nice Temple theme I decided there was no better way to spend my afternoon than building my own, new theme for my blog.

If you haven’t notice, I recently switched my blog from Jekyll to Hugo. The upgrade path from the really old version of Jekyll to the latest version wasn’t quite working as expected, and having to mess around with Gemfiles isn’t really something I enjoy. Hugo on the other hand is written in Go and comes as a single, standalone binary. That seemed really appealing and I’ve had good experiences when trying to build a little photo gallery builder with it a while ago before Hugo had actual photo support. Moving the content over from the Jekyll frontmatter to the Hugo frontmatter was done easy enough, I even moved some of the good posts from my really old blog on here. I was almost perfectly happy, exception for the theme. The Temple theme is nice, but it wasn’t quite what I wanted. So this weekend I built my own (yeah, you’re looking at it).

I’m currently re-reading Growing Object-Oriented Software, Guided by Tests, and this quote really spoke to me:

We should be taught not to wait for inspiration to start a thing. Action always generates inspiration. Inspiration seldom generates action.

– Frank Tibolt

I think of myself as a perfectionist, the kind of person that hates to produce anything short of flawless. And while this is great quality to have because it drives me to improve and progress, it’s also incredibly crippling and frustrating. I’ve often noticed that while I had great ideas, I would often fail to implement them because I would try to over engineer my approach so it would solve everything perfectly. Obviously, many of these ideas and projects never went anywhere. But then on the contrary, ideas where I just started hacking something together often went much further and produced something usable and new.

Recently I’ve been feeling… unaccomplished. Despite all my achievements, acquired skills, and successes I’ve had a thought gnawing at the back of my mind. I realized, after looking at my extensive list of side and toy projects, that none of them are making any progress. In some of them I invested lots of time, others are just ideas, barely sketches. But they all have in common that I grew tired of working on them. Either because after a day at work my brain is tired, or because other things are taking precedence. I’ve moved into a house that requires constant upkeep. Things break or wear out and before your know it you’ve spent an afternoon fixing something. And then I’ve finally picked up a regular workout routine. Generally I’m proud of that, and because these things take time, I had no time for my side projects. Or at least that’s what I thought and told myself.

I’m working on a small app running on Google App engine using Go and upgraded to the latest version of the GAE SDK. The latest version uses Go 1.6 instead of 1.4 like the older version I had. Upgrading was mostly straightforward, but once I started using vendoring I got strange build errors like this:

2016/05/22 13:26:47 go-app-builder: Failed parsing input: parser: bad import "syscall" in vendor/golang.org/x/net/ipv4/dgramopt_posix.go

I got different variations of this, but all came down to the same problem: some code was importing packages that GAE doesn’t want you tu use. Sadly these errors don’t show up during normal goapp build or goapp test cycles, but only when you want to deploy or start a local devserver.