'Recurse Center Journal: Week 2'

Week 2 of RC is in the bag. If the theme of week 1 of RC was "Wow, meeting tons of new people online is just exhausting as it is offline" then I think the theme of week 2 is "How on earth do I stay focused on a few things and not get sidetracked by all the interesting things that are going on?" So I thought I would focus on productivity in this blog post, with some little technical tidbits at the end. Don't worry: I plan to do a midweek post on some interesting C++ stuff I learned.

Self Directed Productivity

First, let me say that I am really trying hard not to beat myself up about productivity. As I was told at the end of the week last week by one of the RC faculty: self directed learning is something that is really hard, and it requires practice. That said, I'll note my experience here and I hope that it at least assures future readers (and myself) that this happens, and not to stress it too much.

This week I had a very distracting Thursday. A bunch of personal issues I won't get in to here, stuff that just kept churning around in my head all day. It made it very difficult to get things done, but I did have one "aha!" moment about Haskell towards the end of the day that felt all the sweeter because of it. Then on Friday I had to take care of some emergency plumbing, but I did manage to get an open source contribution submitted. Still it felt like the second half of my week was wasted. I wanted to do so much more! I was very frustrated.

My first observation is that self directed learning is a bit like having a job you really care about. When you're "on" and in flow everything feels amazing. It can be, for better or worse, hard to stop. But when something interrupts you, or breaks your flow, it feels terrible. Because you want to be doing this! Contrast this with working for a company where, if your toilet breaks in the middle of the day necessitating a trip to the hardware store, you don't feel so bad. We can't be expected to go without a toilet, can we?

But at the end of the day, self directed learning is your time and for me that made it harder for me to cut myself some slack. I think that next time this happens, and I'm sure it will happen again, I'll just go for a walk and see if I can get back in to it. If not, it didn't help me stressing about it all day long. It might not help you either!

Random tech bits

All that aside, I did learn some cool stuff this week. Here are the quick hits:

Electron

I paired with someone on building an Electron app that plays sounds as certain things happen in a Super Smash Bros. game, using the Project Slippi file that is written as the game is progressing. This app needed to present a web UI and read files off of the filesystem. In order to do this we needed to understand a bit about the architecture of Electron.

Electron has two processes: the main process and the renderer process. The main process is the first process that starts and is responsible for starting all renderer processes. Hence the name! Each renderer process is essentially a Chromium tab, with full access to the native browser APIs.

The main process is a regular node.js process, with full access to the Node APIs but no access to native browser APIs. However, the renderer process also has access to all of the Node APIs. What?? This means if you shell out and do a ls / from the renderer process you'll get a list of files at root.

I'm not sure exactly how this works but I am really curious to find out. I suspect it's some sort of automatic RPC between the renderer process and the main process given some facilities of seen for doing such things in the Electron API. Maybe more to come next week!

WSL Woes

Oh WSL, we had such a good run of one week before you gave me troubles. I booted up WSL one day and one its coolest features stopped working. Luckily I fixed it and learned how it works along the way.

I use a lot of Visual Studio Code to write code these days. This has been especially useful as I attempt to do all of my development at Recurse Center on Windows. One thing you can do with VSCode on all platforms is type code . to open an instance of VSCode in the current directory. I was surprised to see that this works from inside of WSL when I started using it.

Unfortunately, that stopped working this week. After lots of fruitless googling I decided to give up, dive in, and see how it is supposed to work.

First I looked for the code binary in the WSL filesystem. I found it ... but only in the Windows filesystem that is automatically mounted in WSL at /mnt/c. And wouldn't you know it, code is write next to code.exe. On a hunch I opened powershell and tried to start code there which definitely used to work. Nothing. But now I had a hunch: something had removed code from both the Windows and Linux path. But how did it get in both places, and what removed it?

When I installed VSCode, how did it add it to both paths? It turns out, it doesn't! It adds the path that code and code.exe exist at (C:\Users\Dan Miller\AppData\Local\Programs\Microsoft VS Code\bin on my system) to the Windows path. And the Windows path gets automatically added to the Linux path when you open a WSL2 shell!

So, if you want to make a "cross-platform" tool available between WSL and native Windows, just put both the Linux and Windows binary in the same directory, add that to the Windows path and it will automatically be added to the WSL path the next time a user opens a directory. Cool!

The best of the rest

• Saw an awesome presentation about Zig this week. Definitely want to learn more about that, especially since it fits so nicely in to my quest to learn more about systems programming.
• My friend Steffi presented an OCaml and MirageOS workshop. MirageOS is a library for building unikernels, but you can use it to build any old application that you want to run on Linux. It's kind of like a Docker container. This also warrants more investigation.
• Saw another great talk by José Valim about Elixir. I did some Elixir way back when it first came out and it's cool to see how far it has come, especially the libraries and web development story. My biggest takeaway though was José's philosophy on using GitHub issues: he only puts actionable issues on GitHub. No feature requests, no discussions. This keeps the issue list short and gives the maintainers confidence that any issue in there is ready to be worked on. Feature requests and discussions are better suited for other mediums anyways. He also talked about how the bar has been raised by Go and a lot of the languages that came after it as it relates to tooling. If you're not bundling a linter, testing tool and language server you're not really being competitive. I agree, and I'd like to explore this in a future blog post.

Until next week: failure is OK! If things happen that are outside of your control, don't sweat it! :D