Tag: Frugality

Put A Bow On It

Put A Bow On It

By | | Comments 0 Comment

Despite writing a bit about CDK nearly two years ago, it’s taken me some time to get a chance to really lean into it. Having now built out a couple real projects, I can confidently say that like it has its rough edges, like any technology, but overall it’s both powerful and fun.

If you’re so inclined, feel free to check out my most recent creation, a construct for deploying a Hyperledger Fabric network on Amazon Managed Blockchain. 

# Easy as pie!
HyperledgerFabricNetwork(
    self, 'MyNetwork',
    network_name='MyNetwork',
    member_name='MyMember',
)

For my next trick post I’ll go through one of the aforementioned rough edges I discovered, and how it can hopefully be fixed.

Putting Pen To Paper

Putting Pen To Paper

By | | Comments 0 Comment

I spent some time today chatting with an early career colleague who’s looking towards a future career in the dark arts software development. Being the kind of person that enjoys the sound of my own voice, I enjoy these opportunities to pontificate. One piece of advice I routinely give is that good engineers write well, and developing this skill will pay itself back with copious dividends.

However, that shouldn’t be read to mean that quantity trumps quality. Far from it, keeping things brief is usually more difficult than not (I know I’m bad at rambling, kinda like I am now). Which is why I found this little article on the value of the humble readme such valuable advice.

The other day I published a blockchain solution on Github, and while I’m pretty proud of the code, the readme is in bad shape (as of today at least). For my next project (a refactoring of the core of this solution into a reusable CDK construct) I think I’m going to write the readme first, as the above article suggests. We’ll see how it goes!

Hodgepodge Advice

Hodgepodge Advice

By | | Comments 0 Comment

I’m a sucker for lists that contain pithy nuggets of truth. Here’s two great ones I found this week:

Some of my favorite statements, in no particular order:

If you don’t have a good grasp of the universe of what’s possible, you can’t design a good system

Every system eventually sucks, get over it

Software engineers should write regularly

Always strive to build a smaller system

KISS, don’t be afraid, and boring > cool

The bottleneck is almost always the database

Whatcha Been Up To?

Whatcha Been Up To?

By | | Comments 0 Comment

I’m naming this truism in honor of the co-inventor of the spreadsheet:

Bricklin’s Law

The probability of a project’s success is inversely proportional to the number of status tracking tools used by its team members.

Also, I think this is the first time I’ve used “pull quote” formatting on this blog. Neat!

A Rose By Any Other Name

A Rose By Any Other Name

By | | Comments 0 Comment

In all my time thinking about how naming is hard, I’ve never come across a concise set of practical suggestions for choosing variable names in software. Until now. I’ve used the A/HC/LC Pattern my whole career, but never had a term for it. Honestly it could use a better name (naming is hard!) but the concept is solid.

There isn’t a single piece of advice in the above that I disagree with, and a few I absolutely love (my goodness do I hate context duplication in namespaced variables).

No Silver Bullets

No Silver Bullets

By | | Comments 0 Comment

I thoroughly enjoyed the advice given in Scaling with common sense, probably because I’ve violated each of those principles at various times in my career, and are (hopefully) wiser for doing so.

But the real gem was a link to the following sketch:

I’ve been in that meeting, both as the speaker, and as the listener. Whenever I hear someone say “just move to microservices” like it’s some kind of magic spell that instantly fixes all problems, I want to go full-on Andy Bernard and punch a hole in the wall.

The Dark Side Of Reuse

The Dark Side Of Reuse

By | | Comments 0 Comment

Every branch that bears fruit, he prunes it so that it may bear more fruit.
– John 15:2

Deleting code feels so good, especially when it’s code I’ve written. It’s an emotion predicted by the Creator’s Curse, and it also make sense under the lens of this article, which challenges developers to write code that’s “easy to delete”.

Too often, especially in academic settings, or with inexperienced engineers who don’t have the experience of the dirty hacks required to keep an actual real-life system running, there’s a view that good software engineering practices are like the Ten Commandments, never to be violated. But for every rule, there’s any number of exceptions, and I loved the way the author laid out these tensions.

OOPs I Did It Again

OOPs I Did It Again

By | | Comments 0 Comment

Have you ever looked at a heavily object-oriented codebase (Java, I’m looking at you) and immediately felt dumber? Did the design patterns touted as the ultimate in software craftsmanship sound amazing when you studied them in school, but now every time you see them in real projects they result in layer upon layer of confusion?

You are not alone.

There is no one approach to rule them all when it comes to software development, and while I wouldn’t be quite as hard on object-oriented programming as the articles linked above (yes, there are multiple ones), it’s not the only, best, or even appropriate pattern to use in all circumstances.

Truth And Consequences

Truth And Consequences

By | | Comments 1 comment

Yesterday I was in an all day meeting preparing for a large customer demonstration. Ran into a bug that turned out to be a misunderstanding of how JavaScript handles truthiness. Consider the following code:

if (person.address) {
  console.log('Address is ' + person.address);
}
else {
  console.log('No address.');
}

Seems clean enough right? Not so fast. If person.address is null, no problem. However, if person.address is an empty object, that evaluates to true, and the code fails to do the right thing. To me at least, this is non-intuitive behavior.

I started this blog with a discussion of why I love Python, and once again it behaves more intuitively. Empty dictionary, empty list, None, and empty string all evaluate to False. So the code works in a broader-variety of cases:

if person['address']:
    logging.info('Address is ' + person['address'])
else:
    logging.info('No address.')

Isn’t that nice and clean?

As an aside, most developers have become so accustomed to bracketing punctuation (e.g. braces, semicolons) that they assume there’s no other way. Personally I’ve come to love the lack of noise in Python syntax, and I think you will too.