This Week I Learned (June 2019 — w2)

Alright! In a similar vein to last week: more Kotlin, more trees. See also: file formats, and build systems!

Here’s what I learned this week.

2019/06/08: ⚔️ Defy physics! ⚔️

Recently I’ve been facing some serious competition from friends in Super Smash Bros. Ultimate, and I figured that today was the day that I sat down and learned how to play for real.

In the past, I’ve mostly played Smash Bros. by just — well — smashing buttons, and while I’m generally okay at landing hits, I fall off the stage a lot.

TIL: If your fighter is headed on a path off screen, tap your left or right bumper while you’re in the air to defy physics and change your trajectory left or right. I’ve done this by accident before, but now I know! 😯

2019/06/09: 🍁 Japanese maples make for good bonsai trees 🍁

I’ve been more than slightly interested in bonsai trees since I was first exposed to them by a friend last week. There is something zen and beautiful about sculpting nature over a really really long time (like 12 years!) to have a tiny piece of the world.

Japanese maple bonsai, by Walter Paul. More here.

As it turns out, Japanese maple trees make for good bonsai trees! I happen to have a red Japanese maple growing in my front yard which is dropping seeds like crazy right now, so we’ll see how growing one of these things goes!

Most people buy bonsais when they are already established, but I’m cheap and growing one feels kind of like a science project.

2019/06/10: 🤢 There exists a toxic af social network — for employes of major tech companies — called Blind. 🤢

Here’s all I have to say: if the posts on this network are at all indicative of the state of affairs in our industry, our tech communities needs to do much better. The “techbro” image is old and crappy and it sucks.

I fell in love with technology at an early age because I felt it was a powerful tool to make positive differences in people’s lives, improve access to information, and abstract away complex processes to increase productivity at a global scale.

Noble mission lead by people complaining (or boasting!) about their $400k USD total compensation? 🤮

2019/06/11: 🗜📁Zip files are not good at random access! 🗜📁

If you’re going to process a zip file in memory and (e.g.) care about categorizing the entries by file type, better to do it in one pass than several.

ZIP file structure, courtesy of Wikipedia.

You don’t want to be iterating over all the entries to get the set of files you’re looking for randomly: ZIP doesn’t support this kind of access. Instead, it’s better to just process the whole ZIP (e.g. with a Visitor) picking out the bits you care about as you visit the File Entries.

TIL: Look at how a file is formatted before you start using a platform API to parse it. Performance might surprise you.

2019/06/12: 🤯 okiomakes Java I/O ok. 🤯

I used to be afraid of InputStreams because (compared to Files) they are so clunky to work with.

Using plainjava.io :

fun readStream(stream: InputStream) : ByteArray {
  val buffer = ByteArray(2048)
  val output = ByteArrayOutputStream()
  while(true) {
    val bytesRead = stream.read(buffer, 0, buf.size)
    if (bytesRead == -1) break
    output.write(buf, 0, bytesRead)
  }
  return output.toByteArray()
}

Not really ok with me.

Using okio:

fun readStream(stream: InputStream) : ByteArray = 
    Buffer().readFrom(stream).readByteArray()

Major kudos to the folks at Square that made this nice API!

TIL: There is so much more than the standard library. You don’t have to be stuck with a language designer’s sometimes less than favourable decisions.

2019/06/13: 🐘 Gradle (kind of?) supports external projects. 🐘

In the Gradle 4+ (at least?) world, everything is about subprojects and modules. You’re probably familair with file structures like:

project/
\_subproject1/
| \_src/
| \_build.gradle
\_subproject2/
\_build.gradle

where you typically coordinate the builds of the subprojects from the top-level project build.gradle file.

You can also do something like this:

task buildExternal(type: GradleBuild) {
  // This will pick up the build.gradle file for you.
  dir = "path/to/external/project"
  // List of task names to run in the project.
  tasks = ["clean", "jar"]
}

⚠️ This is super lame because the task outputs are lost.

For additional suckiness: if you use an IDE like IntelliJ Idea, the tasks = line is going to complain at you with a useless warning. Gradle doesn’t actually care, and it doesn’t trigger any deprecated features or warnings with Gradle 5.1. Maybe it goes away if you use the Kotlin Gradle DSL?

TIL: If you have parts of a project (e.g. test resources) that can be built from sources, you don’t have to commit them as proper projects. Only interesting stuff deserves that distinction.

2019/06/14: 📄 A little copying doesn’t hurt. 📄

Software is supposed to be DRY. (That is, don’t repeat yourself!)

I’d argue that software tests are supposed to be similarly DRY.

Today I found myself needing to write a test that reproduced a failure for a feature that I had zero familiarity with, but my instinct was to build the test from first principles.

I struggled for hours trying to figure out how to set it up correctly, staring at different examples of similar (yet very different) code across projects, trying to pick pieces from them to inform how to use this feature.

A test was staring me in the face that set up 95% of what I needed.

TIL: Look at tests close to the feature that you’re dealing with, and if you don’t 100% understand them, copy the most useful looking set of tests and distill them to the essence you’re trying to deal with… Then make the test fail in the way you expect it to… Then write the fix.