Kazu's Log

Kazuyoshi Kato is a Japanese software developer in Seattle, Washington. He is interested in programming languages, data visualization and prototyping.

I finished reading “Software Design X-Rays”. The book is about “behavioral” code analysis. While traditional static code analysis treats source code as a set of files, behavioral code analysis focuses the files’ history inside a version control system such as Git, which shows developers’ behaviors in addition to the artifacts.

I was actually trying to find something interesting from Git repos before;

Those were fun and looked good, but I haven’t compiled these to something actionable. I would say it wasn’t my focus, but I also thought it would be difficult.

The author, Adam Tornhill was combining both static and behavioral analysis, and providing valuable insights to fight against engineering problems, which is quite fascinating. There are a bunch of Unix one-liners and a quote lot of references to the research papers regarding this domain inside the book. In addition to that, he funded a company that provides behavioral code analysis as a service – CodeScene.

I am going to try some of the analyses at work, and/or open source projects to see how they work.

Links for Code Reviews

Nov 11, 2018

I have a bunch of links which I often cite during code reviews. It might sound pedantic, but simply, there are a lot of good writings about software development, and some of them are freely available on the internet. Why do I keep them secret?

Or, probably due to the fact that English is my second language, I just let others explain my thoughts. But laziness is one of the three great virtues of a programmer. Why don’t I?

Code Reviews

On Code Review – I don’t say I’m doing that all the time, but I’m trying to.

  1. Code review should probably always be your top priority, and you should figure out the best way to work it into your event loop.
  2. Make your code review requests a pleasure to read.

Error Handling

Error Handling in Node.js – While the main target is Node.js, operational errors vs. programmer errors is widely applicable and good to think about.

People use the term “errors” to talk about both operational and programmer errors, but they’re really quite different.

The Trouble with Checked Exceptions – Checked exceptions are difficiult and even controversial. People are sometimes not aware that post-Java languages don’t have that.

By implementing checked exceptions the way it’s done in Java, for example, I think you just take one set of problems and trade them for another set of problems.


Test Coverage

Test coverage is a useful tool for finding untested parts of a codebase. Test coverage is of little use as a numeric statement of how good your tests are.

Test Pyramid

The test pyramid is a way of thinking about different kinds of automated tests should be used to create a balanced portfolio.

Test Sizes – I haven’t used the definition as is at work though.


#LatencyTipOfTheDay: Q: What’s wrong with this picture? A: Everything!

And stop looking at feel good charts. Start asking for pretty charts of data that actually matters to your operations…

“How NOT to Measure Latency” by Gil Tene [Video]

Java gotchas

Log4j 2 API Messages – Don’t do string concatenation for logging.

In addition, when using the methods that accept Strings and parameters, the underlying Message object will only be created if any configured global filters or the Logger’s log level allow the message to be processed.

PowerMock – Don’t use PowerMock unless you really need to.

Please note that PowerMock is mainly intended for people with expert knowledge in unit testing. Putting it in the hands of junior developers may cause more harm than good.

Testing on the Toilet: Cleanly Create Test Data

Instead, use the test data builder pattern: create a helper method that returns a partially-built object (e.g., a Builder in languages such as Java, or a mutable object) whose state can be overridden in tests.


Okay. I haven’t discussed about “microservices or not” on code reviews, but I have discussed about that at other occasions.

Monolith First – It has been written in 2015, but I think the assertion is still valid.

This pattern has led many of my colleagues to argue that you shouldn’t start a new project with microservices, even if you’re sure your application will be big enough to make it worthwhile.

Don’t Build a Distributed Monolith [Video]

In pursuit of ease and obedience to the DRY (“don’t repeat yourself”) axiom, it is common to build a distributed monolith instead of the intended decoupled microservice architecture.

Kill “Microservices” before its too late [Video] – This is a bit extreme but thought provoking.


Nov 9, 2018

While I have another blog in Japanese where I write about more random thoughts, I wanted to make this blog “themed”. It was visualiation from January to Februray, then Rust from July to August, but then I haven’t posted for more than two months…

So, I’m going to make this blog less themed to have some momentum going. It might look less professional and wouldn’t make any “brand”. But at this stage, I probably don’t have to worry about such a thing much.

A few months back, I read Andrew Chen’s 10 years of professional blogging – what I’ve learned;

Nevertheless, because initially no one will read your work, the key is just to get started. Your initial topics and format should be whatever you can do easily and maintain some sort of frequency. Maybe that’s 500 words a month on a new product you’ve tried, and whether you hate or it not. Just get started, find out what you like, and you’ll have a lot of time to figure out the intersection of what you want to write, and what others want to read.

This advice is for me – “no one will read my work”. Well, I think I have a few readers here (thanks!) but I don’t have a lot.

Until the end of this year, I will write some relatively random but probably tech stuff here to get some momentum. Let’s see how it goes.