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.
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!
All that aside, I did learn some cool stuff this week. Here are the quick hits:
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!
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.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!
Until next week: failure is OK! If things happen that are outside of your control, don't sweat it! :D