About this site

What this site is

This is a site where I publish notes on “How do I write this in that language again?”.

There’s a lot of explanation further down, but in short it’s a self-indulgent collection of notes for my own use.

I’m putting it online because it might be useful to someone, and it sounded fun to publish it and maybe get some feedback.

Trial and error

When I write code and switch back and forth between languages depending on the task, I often run into questions like:

• In that language, how do I write this again?
• For lowercasing, was it to_lower, tolower, or lowercased?
• For else if, was it elif in Python and elsif in Ruby?

I get similar questions even when I’m not switching languages.

• I feel like I write the same kind of thing over and over.
• In the end, which style was the “good” one again?

This has bugged me for a long time, and I kept trying similar things over and over. For example:

• Summarizing things in Excel
• Putting them in a database and making a web app
• Doing the same but storing the data in JSON instead of a DB
• Writing per-language versions using each xUnit framework
• Splitting everything into small Markdown files and editing those
• Integrating it into a static site generator (VuePress, Docusaurus)
• Using grid components for display (Wijmo, AgGrid)
• Turning the whole thing into an iPhone app for editing / viewing / searching

None of these really felt right. I’d end up with too many tiny files, get tired of hunting for them, or of keeping names and granularity consistent, and eventually stop.

I go off on tangents like this every time, but this time I managed to put together a workflow that feels like it might stick, so I decided to make it public. (I’ll probably keep tweaking it forever and it will never be “finished”.)

Workflow

1. Write unit tests in each language using its xUnit framework.
2. While doing that, organize and align method names as follows:
   • Folder: category (strings, arrays, etc.)
   • Test suite (file): subcategory of operations (for strings: conversions, substring operations, etc.)
   • Test case (method): the specific thing I want to do (lowercasing, uppercasing, etc.)
3. Run a script that parses the test cases and generates the HTML overview pages.

What I think is working well this time

1. Once the tooling is in place, all I have to edit is the xUnit code.
2. Anything published here is guaranteed to have passing tests.
3. Even if I change the classification manually, the generated overview helps me spot missing updates in other languages.
4. Folder names vs. display names / sort order are split out into localization config files.
5. Looking across multiple languages forces me to think about the categories from a slightly higher-level perspective.
6. Because everything is closed within my own simple tooling, I don’t have to care about static site generator or app SDK versions.

Extra