This was reverse-engineered from Wei-Chuan brand dumpling sauce. It’s not an exact replica but should provide a similar taste profile.

Makes approximately 200 mL.

Ingredients

If you don’t know about this already, then file it under your collection of “One Simple Trick articles”…

git add -p (AKA git add --patch) will interactively show you each change in your repo and ask you if you want to stage it.

Do you ever use git commit --all? Have you ever accidentally committed more than you meant to?

By using git add -p, you get a chance to review each change. That helps you catch mistakes, like leaving in debugging printlns that you don’t need anymore, or other temporary hacks. Since git add -p will present each change separately, you can even include some changes and exclude others within the same file.

And, it’s not uncommon for me to fix small, unrelated issues while working on a major feature. I’d like for those fixes to go into a separate commit, and git add -p gives me a chance to catch those fixes if I haven’t committed them already.

The other major benefit is that it gives you a refresher on what all you changed before you need to write your commit message. If I work on a big changeset, sometimes it’s hard for me to remember all the important changes that I should write about in my commit message. Quickly running through the changes interactively means that, instead of writing “Add feature X”, I can write more detailed commit messages that list the major areas that have been touched.

Overall, it’s made my commits cleaner and me a more thoughtful programmer.

Don’t blindly commit files. Try git add -p.

P.S. Even though I now mostly use VS Code, I still prefer to review changes in the built-in terminal instead of the Source Control pane. Since git add‘s interactive mode uses single-character commands, I can quickly step through the changes without fiddling with the mouse.

There’s a large and thriving community of English speakers learning Japanese, in which they swap tips and trivia amongst themselves as they seek to improve their Japanese skills.

The corollary is that there’s a large and thriving community of Japanese speakers swapping tips and trivia about English, and I’ve found a bunch on Twitter. So, what are they talking about?

There’s practical advice on what they teach you in school vs. the real world:

Summary: By taking advantage of AWS spot instances and only running when you need to, you can have a powerful Minecraft server for as little as a couple dollars per month.

I’m happy to share a set of tools we’ve created to run a cheap, personal Minecraft server on AWS! It works like this:

• When you want to play, go to the server status webpage and launch the server.
• Wait for it to start up.
• Connect to the server from Minecraft.
• After you disconnect, the server will automatically shut down after a period of inactivity.

This way, you only pay for the time you play (along with storage costs for your world data). How cheap is it? Based on prices as I’m writing this:

It can feel overwhelming to be a new software engineer, but many “noob” things are actually “everybody” things. If any of these things happen to you, know that you’re in good company!

Forget basic syntax and need to Google it

Here’s what my recent search history looks like…

I went to a boarding school for part of high school. (It was actually a public boarding school—weird, huh?) We lived in an old college dorm that had four floors. I lived on the 4th floor and one particular friend lived on the 1st floor.

Our Internet connection on the 4th floor (and actually most of the building) was pretty bad. We’d usually get around 110 KB/s and sometimes during busy hours it could drop to 30 KB/s with some bad jitter.

My 1st-floor friend, though, consistently got 4 MB/s down and would be playing low-latency Urban Terror while the rest of us upstairs were cursing the school’s IT department. Rumor is that part of the first floor flooded a few years back causing a lot of the wiring and networking to be replaced.

However, a little bit of experimenting showed something promising: I could connect to my friend’s computer downstairs at high speeds, even though at the same time I would have trouble watching YouTube. So, we did what any normal high schoolers would do: we set up OpenVPN, using one of the school-issue laptops as the server downstairs in my friend’s room, and installing the OpenVPN client on my own laptop upstairs. All of a sudden, I could stream videos at 4 MB/s while my next-door neighbors were stuck at 100 KB/s or worse. The only downside was increasing my friend’s latency while he was gaming.

We never did figure out the networking topology of the building, but I doubt it’s gotten much better since.

We have a Bluetooth speaker in our office that we often use to play music through. My Linux machine, however, didn’t automatically connect to the Bluetooth speaker, and even after connecting it, I’d have to switch the output to be that speaker.

I ended up creating a shortcut on my menu bar that would connect to the Bluetooth speaker and set it as the default audio output, all in one click.

First, I went and set up the audio like I normally would, making sure to note the Mac address of the device: (more…)

Wikimedia Commons holds a few remarkable maps of San Francisco from the 1850s. These maps, done as part of the US Coast Survey (now the National Geodetic Survey) were made a half century before the 1906 earthquakes and show a San Francisco that was largely limited to the Northeast part of the current city.

I went ahead and matched up an 1853 map and an 1859 map to today’s map of San Francisco using the amazing Map Warper tool. Shown below are mostly the 1853 maps. All modern-day street maps are copyrighted by the OpenStreetMap contributors. (See bottom of post for links to this map on Map Warper.)

We see a city that doesn’t extend much past 3rd Street. (more…)

Heroku is trialling new pricing levels for their dynos. Here’s the verbatim text they gave:

Free – Experiment in your own dev or demo app with a web and a worker dyno for free. Sleeps after 1 hr of inactivity. Active up to 12 hours a day. No custom domains. 512 MB RAM.

Hobby – Run a small app 24×7 with the Heroku developer experience for $7/dyno/mo. Custom domains. Run a maximum of one dyno per Procfile entry. 512 MB RAM.

Standard 1X, 2X: Build production apps of any size or complexity. Run multiple dynos per Procfile entry to scale out. App metrics, faster builds and preboot. All Hobby features. 512MB or 1GB RAM. $25 or $50/dyno/mo.
?
Performance – Isolated dynos for your large-scale, high-performance apps. All Standard features. Compose your app with performance and standard dynos. 6GB RAM. $500/dyno/mo.

(more…)

We had a hardware unit that was Ethernet enabled. To configure and manage it, the vendor provided us with a Windows program that, given the unit’s IP, could establish a TCP connection to the unit’s port 3300 and do all of its fancy management things.

The only problem was, the hardware unit was a hundred miles away on a private subnet at a client’s building, and the only thing that could directly talk to it was Linux computer A that we installed alongside the unit. We had the foresight to install Hamachi on computer A, and my own Linux computer B here also had Hamachi. My clunker Windows laptop C that could actually run the software was hooked up directly to computer B via Ethernet.

So, computer C had the Windows program and could talk to computer B via direct Ethernet. Computer B could talk to computer A via the Internet using Hamachi. And computer A could talk to the hardware unit via its local VLAN.

C -> B -> A -> hardware unit

The transitive property of hooking-up-computers states that if C can talk to B and B can talk to A, then C can talk to A. But how?

Well, when you only have SSH, every problem looks like an SSH connection.

1. Computer B connected to computer A and established an SSH tunnel. The SSH tunnel forwarded B’s localhost:5000 port to A’s hardwareunit.local:3300. computer-b$ ssh -L5000:hardwareunit.local:3300 computer-a.local
2. Computer C connected to computer B and established an SSH tunnel. The tunnel forwarded C’s localhost:3300 to B’s localhost:5000. computer-c$ ssh -L 3300:localhost:5000 computer-b.local
3. Windows program on C connected to C’s localhost:3300, which actually goes to B’s localhost:5000, which actually goes to the hardware unit’s port 3300 via A.

Yes, everything was passed along via two SSH connections in a row, but it worked quite well, and it will save us from driving down to the client in the rare case that we need to do this again.