blog.8-p.info

More Open Work

Apr 12, 2019

I have a bit of regret about my professional career.

While I’ve been working as a software developer for more than a decade, I was mostly doing proprietary/commercial software development full-time, and open source software development was more likely a hobby. I have convinced myself that it would be the only way to pay my bills, but I knew it wouldn’t.

I’m not saying that proprietary/commercial software development is bad, but I’d like to have more balanced life regarding the two world.

There are 2 reasons;

First, I’ve been building some proprietary applications atop of open source software and not giving back much. The entire industry is kind of doing that for years, and I’m not a big fan of that.

Second, I want to have something that I can point and say “this is my work”. I probably can become a good software developer by doing what I’ve been doing, but I cannot become a great one. Great like Matz, Tim Bray or Mike Bostock.

Squeezing them into my spare time didn’t work. So, I need to try something different.

On Languages

Mar 27, 2019

My “feelings” regarding programming languages.

Java

I’ve been using Java for years. It is showing its age.

Java is enforcing weird trade-offs such as “being safer by adding final on variables” vs. “being concise by not adding final on variables”. You really don’t have to pick one of them on other, newer languages.

Java’s class libraries are also odd. Immutable collections shouldn’t implement mutable collections’ interfaces. Throwing RuntimeException on add() means that your type-safety is a lie. Don’t do that.

But, all of them are coming from the fact that Java is backward-compatible for decades. Lambda was good, var is coming, but we cannot change the language and its libraries drastically anymore.

Kotlin

Kotlin is a good alt-Java language. I’ve been using that for a few months at a small Android project, which my friend in Tokyo started.

Being a JVM language means that all of the performance characteristics are the same, which makes the language sometimes difficult to sell. It is slow to start, can be faster, but won’t be faster than Java.

Yes. Kotlin has “Kotlin for Native” and “Kotlin for JavaScript”. I haven’t tried them yet.

Meanwhile, being a JVM language means that you can use Java’s ecosystem, which I honestly have mixed feelings. Java’s ecosystem looks sometimes largely complicated. Do you really want to carry all of the historical baggage?

Scala

I was using Scala and contributing Scala itself between 2011 to 2015. To be fair, I was mainly working on Scala’s documentation generator – Scaladoc at that time.

Scala is good, but honestly speaking, Kotlin seems good enough.

Kotlin looks simpler, while it has some magic behind the compiler, such as converting Kotlin collections to Java collections implicitly. Kotlin’s IDE experience is superior, which makes selling the language easier. Java developers tend to expect flawless IDE experience.

Rust

Rust is interesting. The language is designed to replace C/C++, which is a moonshot. Other languages partially did, but not entirely yet. The community is trying to be somewhat different - no BFDL, having annual roadmaps, no huge corporate backing. Mozilla is still contributing a lot, but some of the key contributors are leaving the company this year.

I’ve been contributing Rust itself, rbspy and some other Rust projects these days.

Rust would be lean and faster than other languages including JVM ones. Not so sure how many people actually willing to pay the cost (the difficulity of the language), but it is a better/objective pitch than “it looks good” which is subjective.

Ruby

I’ve been using Ruby for years, even before Rails. I have attended a few RubyKaigi’s. For simple-and-fast scripting, I still pick Ruby over other languages.

Python

For data science-y stuff, I use Python on Jupyter.

For scripting, I sometimes use Python, simply because I know Ruby well and want to be more proficient in different languages.

Perl

I was using Perl for years. My first job out of college is a LAMP developer. I was literally using Linux, Apache, MySQL and Perl. I know how to write a decent Perl script. I still use perl -ne and such for writing simple one-liners.

Go

Go’s growing popularity is interesting. Before Go, almost all programming languagues were becoming functional programming languages where you can write map, reduce, fold, … but Go said no.

And Go developers do like Go! I initially thought this was only in Japan, where I lived, but seems like it is not.

Go Is Unapologetically Flawed, Here’s Why We Use It (2015)

Go has an increasingly vibrant community, but it’s profoundly stubborn. My biggest gripe is not with the language itself, but with the community’s seemingly us-versus-them mentality.

I was writing some Go, including for moby (formaly known as Docker) and Go itself. I was trying to port Docker on FreeBSD out of curiosity, which I hadn’t finished, but somebody did eventually.

JavaScript

I’ve been using JavaScript for years, but not professionally these days. JavaScript or TypeScript may make sense for FaaS, where Java’s cold-start is problematic.

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.

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.

Momentum

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.