Tag: Have Backbone

Resolute Comprehension

Resolute Comprehension

By | | Comments 1 comment

I really like New Year’s resolutions. As a lover of habit, the beginning of a year is perfect time to calibrate a new routine. This year I have two resolutions:

  1. Post on this blog at least once per month
  2. Learn a new programming language

The latter was inspired by this article, which is stupidly long but thoroughly enjoyable. As a non-fan of OOP I found myself nodding along quite frequently. He advocates pretty hard for functional languages; while I’m familiar with the paradigm having used it in Python, I haven’t done much with purer forms. In 2022 I intend to change that, probably by learning Clojure.

Erlang and Go are also on my to-learn shortlist, the former for its first-class support for concurrency, the latter because it’s the new hotness for performant APIs.

In other news, I’m working on publishing my first CDK construct, which I’ll share here when it’s ready. I do wish I didn’t have to write it in TypeScript, but sadly I’m at the mercy of the JSII compiler. Why TS doesn’t have first class support for comprehensions boggles my mind. This is the closest I could get:

Array.from(nodeProps.entries()).map(e => new HyperledgerFabricNode(scope, `Node${e[0]}`, e[1]));

Compare that with a Python equivalent:

[HyperledgerFabricNode(scope, f'Node{i}', p) for i, p in nodeProps.enumerate()]

For shame, TypeScript. For shame.

Right On The Nose

Right On The Nose

By | | Comments 0 Comment

I’ve been working on a little project here at this blog, one that’s required me to go back and re-read all my old posts. Truth be told tonight I was using it as a distraction from what I really should be doing (backlog grooming ahead of tomorrow’s new sprint).

Let’s just say this post hit a little close to home. I suppose I better press pause for now (but you’ll hear more soon, I promise, and if you’re observant, you might be able to guess what I’m doing).

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.

Don’t Judge Your Book By Its Cover

Don’t Judge Your Book By Its Cover

By | | Comments 0 Comment

It’s been said that Vincent Van Gogh didn’t like _The Starry Night_, which is crazy, because it’s one of the world’s most recognizable paintings, and an obvious masterpiece.

If some of history’s greatest artists were unable to judge the value of their work accurately, how much less so are we. Don’t be quick to disparage your creative efforts, no matter how meager they may seem.

Dirty Work

Dirty Work

By | | Comments 0 Comment

Developers like to write code, that’s what they do. But being a software professional means working on a number of other tasks, some of which are decidedly un-fun. The wise developer recognizes the importance of these tasks and approaches them with no less effort than their more enjoyable work. Grooming a task list. Writing documentation. Cleaning up repositories. Slogging through a naming refactor to improve consistency. She knows that these will all pay off in the long run.

Yesterday I spent nearly 10 hours working in JIRA, getting my head around nearly 150 tasks that need to get done in the next 3 weeks. Circumstances had forced me to be pretty heads-down in dev-world the past couple months, and my planning responsibilities had fallen by the wayside. I owe the team more than haphazard and vague requirements, and this is the first step to doing better. Here’s to a full July!

It’s All Geek To Me

It’s All Geek To Me

By | | Comments 0 Comment

One of the hallmark characteristics of a nerd is the ability to enjoy a wide variety of things without worrying about how popular they might be. On that note, I listed to this song yesterday and unashamedly enjoyed every minute of it. Wish I’d been there.

Docker Fail

Docker Fail

By | | Comments 0 Comment

One of my favorite truisms in software development is the following:

“When two things aren’t the same, then they’re different.”

I don’t care how hard you work to make development and production environments the same, I don’t care how portable you think your programming language is across operating systems, and I especially don’t care about claims made on a product’s marketing material. Case in point:

[Docker] makes for efficient, lightweight, self-contained systems and guarantees that software will always run the same, regardless of where it’s deployed.

No doubt the Docker team has worked incredibly hard to make the above statement true, but nothing in life is guaranteed with 100% certainty. Last week I discovered that the cron utility will not execute any crontab or script that has more than one hard link pointed at it (don’t ask me why not, it just doesn’t). And due to the way Docker’s overlay filesystem works, the operating system can report a regular file as having multiple links. At least it does when the container is running under Kubernetes. But not always! When running with docker-compose on my Mac the crontab only reported one hard link, and thus cron worked great.

Took me nearly a day of fiddling to determine why the container worked great locally but failed in Kubernetes. Argh.

Not Even Mostly

Not Even Mostly

By | | Comments 0 Comment

Customers are a finicky bunch (they’re human, just like everyone else). That means they’re not always right, and any business practice that assumes they are is likely to fail in the long run.

Don’t hear me wrong, I’m not saying that software engineers shouldn’t listen to customers. Nor am I saying businesses shouldn’t careful consider their customers’ demands and in certain situations give in. I’m really speaking more to an attitude of continual acquiescence. That’s not helpful for a customer who may not have the skill to evaluate what he wants, and it’s not healthy for a developer when they see their professional opinions thrown to the wayside.

If a relationship isn’t a two-way street, it’s probably not worth having.

The Fire In Which We Burn

The Fire In Which We Burn

By | | Comments 7 comments

Everything takes time.

  • Reading and responding to emails takes time
  • Checking Slack takes time
  • Updating JIRA takes time
  • Peer reviewing code takes time
  • Writing documentation takes time
  • Managing versions and branches takes time
  • Meetings and discussions take time
  • Keeping a workspace organized takes time
  • Updating a computer takes time
  • Addressing HR concerns takes time
  • Performance evaluations take time
  • Eating lunch takes time
  • Going to the bathroom takes time
  • Mental breaks take time
  • Thinking takes time

Plan accordingly (which also takes time).

Day Off

Day Off

By | | Comments 0 Comment

I’m taking a day off from writing today. See you tomorrow!

(Yes, I understand the irony of this post)