Kazu's Log

A software developer, Japanese and Seattle transplant

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.

Testing

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.

Latency

#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.

Microservices

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.

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.

Weak Linkage in Rust

Aug 13, 2018

reqwest, Rust’s HTTP crate doesn’t support HTTP/2 yet. There might be multiple missing pieces, but one of them is the lack of ALPN support. So, I’m working on that these days.

ALPN – Application-Layer Protocol Negotiation is TLS’ extention, and standardnized as RFC 7301. Basically speaking, the negotiation is happening by sending a short string over TLS’ initial packets to indicate that the protocol over TLS is HTTP/2. request is using native-tls to support TLS. This crate builds an abstraction layer over three platform-TLS crates - schannel on Windows, security-framework on macOS and openssl on Linux.

Initially I opened a pull request against native-tls to support ALPN, then Steven Fackler, the author of the crate told that;

My current thinking on how we would deal with ALPN on unsupported platforms (e.g. OSX 10.12, OpenSSL 1.0.1, Windows Vista) is that the APIs would always be present, but ALPN would just not run when it isn’t supported.

For Security.framework we’ll probably have to implement this by not actually using the security-framework but by instead using dlsym to dynamically load the symbols at runtime if present.

But there is a rabbit hole…

#[linkage]

Rust itself supports weak linkage, however the whole linkage feature hasn’t been stabilized yet. On this GitHub issue, Alex Crichton wrote that

I personally consider this a perma-unstable issue for now.

So, it may not be stabilized soon-ish.

dlopen

There are multiple dlopen wrappers in Rust’s crates. dlopen is one of them, and I fixed its minor issue. dlopen works, but it is a bit odd to see that Security.framework is loaded and dlopen opens the framework once again.

weak!

Then I realized that Rust’s libstd is having the same issue – pipe2() is available on some Unix OS-es. And the issue has been resolved by having a small macro called weak!. Interestingly this macro is copied over mio as dlsym!.

Conclusion

To have weak linkage, there are three options;

  1. #[linkage] — Good to have zero dependencies, but it hasn’t been stabilized yet.
  2. dlopen and other dlopen wrappers – Good to have a crate to solve the issue, but may be overkill for having a few functions
  3. weak!, dlsym! or the equivalent

I have picked #3 and now I have a new pull request against security-framework. It may be merged, soon, I hope.