Software Development on ilikeorangutans

Notes on Working Effectively With Legacy Code

Mon, 02 Jul 2018 12:02:03 -0400

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.

Book Arrival: Working Effectivly With Legacy Code

Mon, 18 Jun 2018 22:58:46 -0400

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:

null, Software Design, and Scala's Option

Sat, 26 May 2018 12:13:10 -0400

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.

Inspiration and Action

Fri, 30 Mar 2018 11:27:01 -0400

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.

Using Golang and Graphviz to Visualize Complex Grails Applications

Sat, 03 May 2014 13:59:40 -0400

At work we are maintaining several large and complex grails applications. In order to improve stability and reliability, we’re trying to increase test coverage. But as with all projects, time and resources are limited. In order to get a better understanding of what parts of the application are more important than others, I decided to use Graphviz to help me get a better overview of our applications.

Meet Graphviz

I discovered my love for the dot language when I used it years ago to analyze template hierarchies in a proprietary CMS system I worked on. In a nutshell, it lets you specify a graph with nodes and edges plus some extra attributes for labels, shapes etc. It’s really a concise little language:

The Case for Continuous Integration

Sat, 01 Jun 2013 13:59:40 -0400

In my career as a software developer, I’ve come to appreciate the principles of Continuous Integration (CI). It forces you to do the hard things early and often and thus helps you reduce risk during development. It forces you to write tests, and be responsible about what you check in. All in all, good qualities and something that every development team should aspire to. Or so I thought. Reality is different, and so far almost every development team I have interacted with is deadly afraid of doing CI. So much, that there’s been near-mutinies because CI and what it means for team, causes so many problems. This is something that puzzles me, and I realize it might be because the teams in question don’t fully understand what CI is or only realize a subset of what it means. This is my attempt to demystify and explain CI.

On Developer Happiness and Productivity

Wed, 03 Apr 2013 13:59:40 -0400

I’ve had the idea for this blog post in my mind for a long time. It is based on all my personal experiences and observations over the past years and is in no way scientific. It is my personal opinion, and even though this is how I perceive the world, it might not be true for other people. With that said, let’s jump to the core of things.

A happy developer is a productive developer.