JT's Weblog

My Used Page, Part 2

published: October 30, 2025 estimate: 18 min read view-cnt: 2 views

In the previous article, I briefly introduced all the tools I’ve used in my previous working experience.

Here I will continue introducing the tools I’ve used in my personal space and lastly mention a few more titles that I’m currently into.

This is not supposed to be an exhaustive list—tedious items might be filtered out unless I have something to say about them.

Let’s GO!

Personal Amusement (Didn’t Use In The Previous Job)

Note: I also code my personal projects in C# and JavaScript. This list intentionally excludes items I also used in my job experience (not 100% accurate though).

Note Taking

I’ve used a lot of note-taking apps. Data becomes obsolete or gets lost every time I switch apps. But I still kept switching. It wasn’t that my data was disposable, but more like a green field/brown field problem of a long-running service. Data grows into a mess, becoming simply unmanageable. Yet each switch gives you the chance to re-implement the whole structure with the knowledge of previous failure experiences.

Over time, I’ve learned an important principle: separation of prose and data. Avoid defining rigid rules on prose—it’s fine to repeat yourself in writing. Instead, focus on the definitions of data: types, formats, and how to store them. Data should be deduplicated and kept manageable. Prose can flow naturally without over-engineering.

That’s just a brief overview of what happened in the past—the whole story would be another article for another day. Let’s start reviewing it 🤓

• Evernote: the one I used in college. At the time I hardly had any concept of data management.
• OneNote: the one I used in my first job. I started naming stuff differently, and used the extension OneTastic to compose a few macros.
  • However, the lack of a tag system and closed-source nature makes it less attractive.
• Google Keep: offered better mobile experience and a tag system. This was my first real attempt at bringing structure to the chaos. However, the closed format became a limitation.
• Pure Markdown File: After using Google Keep, I started taking notes in pure markdown—the first time I experienced the freedom of plain-text and open formats. Google Keep had tags but was closed; Markdown was open and portable.
• Spreadsheet (Google Spreadsheet, Microsoft Excel, iWork Numbers, Libre Calc):
  • I use spreadsheets for tabular data whenever I need it. The reason is that none of the note-taking apps are good at tabular inline-editing.
  • I switch platforms occasionally simply because I cannot tell which one is best—they all have their own pros and cons.
• LogSeq: the platform I thought I could stick with forever. It’s certainly feature-rich: bi-directional links, DSL query, whiteboard, plug-in system, open source, plain-text storage…
  • I switched to LogSeq from plain markdown for its rich features, privacy-first approach, and plain-text storage.
  • However, the only reason to eventually switch away was the brown field problem, combined with my desire to develop all the utilities by myself rather than relying on a complex system.
  • After quitting LogSeq, I am now back to plain-text files again.
• Apple Note: the go-to option for an iPhone user to type something fast and furious. Still need to figure out how to sync this data to my Linux machine.

Productivity Tools

I’ve tried many productivity tools over the years, but I consistently return to vanilla solutions—plain text files and simple approaches. This pattern reflects a deeper realization: complex tools often become another burden to manage.

My preference toward text file-based solutions solidified after reading “Efficient Linux at the Command Line: Boost Your Command-Line Skills.” The book demonstrated many different ways to manipulate text files with bash one-liners and advocated that one should store data as plain text files. The concept was very inspiring and aligned perfectly with my minimalism.

• Toggl: used for a while, then went back to vanilla time management (i.e. not recording it at all).
  • Might still be a useful tool if you have requirements to measure the cost of time.
• arbtt: hardcore time-tracker written in Haskell. I stumbled upon this tool from an indie researcher’s blog—I cannot tell which blog it was, but the researcher’s posts were so complete and fascinating that it made me wonder about his background. Then I found he used arbtt, and I decided to give it a try. The fact that it was written in Haskell was another fascinating detail.
  • Unfortunately, I couldn’t get it working on my MacBook. Would love to try again if I have the requirement.
• Focalboard: a well-rounded task management tool. However, I went vanilla again. For now, I use only plain-text for everything.

Failed experiments (not exhaustive):

• LogSeq for task tracking: I tried using LogSeq (mentioned in the Note Taking section) for task tracking as well, but the mix of prose, tasks, and task-like items was just a mess. Although LogSeq provides queries to extract tasks from prose, it’s still too overwhelming if used in the wrong way.
• Mandala Chart extension in LogSeq: I once tried to develop this extension, but it failed quickly. Two-dimensional note-taking plus daily/weekly status tracking are not trivial to develop—they’re power-user centric features. I could barely keep up my task tracking routine, resulting in failure.
• Affine: aimed to be a Notion replacement. The UX was good, but I’m not in the habit of making things prettier. It was still overkill for my day-to-day usage.
• Plane: even more complicated than Affine, since it also features project management. Not a fan.

There were many other attempts, but there’s no point in listing them all.

Language

My programming language practice centers on minimalism: I try to find the minimal syntax for each function I implement. Bash, when it conforms to Unix philosophy, is probably the most concise solution available today. Beyond Bash, the other two languages I gravitate toward are Python and Raku—I prefer Raku because it achieves conciseness on its own without relying on tons of packages.

Learning a new DSL from scratch helps you become aware of the essential syntax of a programming language. It helps you compare syntax across different languages and discover how to code in a more succinct way.

An important shift: LLMs changed everything. LLMs are excellent at building small-scale programs in any programming language. You can kickstart projects WAY faster than before. This has fundamentally altered how I approach learning new languages and writing utilities.

• Bash: extraordinarily uncomfortable syntax for a programmer with a JS/C# background. However, after a few attempts with the help of LLMs, I started appreciating it.
  • I started appreciating how much it can achieve, and how succinct it can be thanks to the Unix Philosophy (the magical pipe).
  • I’m aware of fish and zsh, however, the current Omarchy setup already includes the necessary features, so it’s less attractive to switch.
• cmd.exe: the OG Windows shell. I once tried to make an auto punch card script that inserts a random timestamp into a Google Spreadsheet on a daily basis.
  • It was A PAIN IN THE ASS. There were so many gotchas similar to the bash scripting experience in the beginning, but hitting harder.
  • Not to mention I wrote the script in pre-LLM era… I would not recommend anyone do the same thing again.
• OneTastic Macro Language: a DSL scripting language installed as a OneNote plugin (mentioned earlier in the Note Taking section).
  • With limited resources, I soon found out that using a safeguard pattern helps you reduce nested structure (that’s a topic for another article—when NOT to use a safeguard).
  • Since I used OneNote in my first job, I still have some emotional connection to this plugin.
  • Fun story: back in 2017, the pricing model used a counter for macro execution, so it’s possible a user would never be prompted for a “Pro License” if they only used it occasionally.
• VBA: I coded a lot of VBA for office work when I was a volunteer committee member on a hospital committee.
  • Surprisingly, the skill expanded to my first job where my manager preferred the Gantt chart generated by the script I wrote (I sincerely hope they no longer use it).
  • I learned performance awareness from the difference between recording and truly scripting.
  • Also, I appreciated learning the gotchas of ByRef, ByVal, and quirky error handling which are seldom seen in modern programming languages.
• Clojure: I learned this from LogSeq advanced query. The learning curve is quite steep to be honest (again, that was pre-LLM era).
  • LogSeq is a brilliant engineering product that glues many successful components together.
  • The challenge is that you’ll never know if the syntax is allowed in the executed environment, since you are executing Clojure in a DSL scope.
  • One may spend hours just to figure out which syntax works and which doesn’t.
• AutoHotkey: AutoIt spin-off. It makes syntax extraordinarily concise. I don’t use it that much, only to tweak a few little things.

Web Front-end & JAMstack

I am a full-stack web developer, primarily using the WISA solution stack (Windows, IIS, SQL Server, ASP.NET), and also familiar with React and the modern JavaScript ecosystem.

In my spare time, I love to explore front-end technology beyond the WISA stack. However, I found out that the need for learning new things is limited by what I actually want to build in my spare time. A simple content-driven website doesn’t need too many fancy features.

One lesson learned: there’s no need to pursue platform-independent or framework-agnostic features when you’re just trying to build a dead simple blog site. YAGNI applies strongly here.

• Astro: the fancy framework that uses island architecture to run different JS frameworks on the same page.
  • The framework-agnostic part is quite promising, however, the reality is YAGNI.
  • The built-in functionality is good enough for a small website, at least that’s how I use it.
• Starlight: the documentation framework built on top of Astro. I used it once, then returned to minimalism (again, it’s just a matter of preference).
  • One does not need full-fledged documentation site features for a content-focused personal blog site.
• Bookmarklet: you can check out the previous article to see how I use it.
• Shadcn: the design-agnostic component library. The word ‘agnostic’ is just too cool to resist for a developer 🤣🤣
  • It’s also worth noting that they use a very different approach where they copy-paste the code into your codebase directly.
  • This means you can customize it as you want, and you make the node_modules folder a bit lighter at the end of the day.
• Next.js: used it once to build my website. It was ranked first on the JAMstack site generator page at the time.
  • Integrates well with Vercel. The DX was like a breeze. However, I prefer a more de-coupled or platform-independent solution (just trying to avoid the word ‘agnostic’ 🤣🤣).

Browser & Extensions

I’m a web developer, of course I’ve used more than 3 browsers! Worth noting that mobile browsers don’t simply equal desktop versions—especially iOS browsers, which are essentially wrappers of WebKit. There are many other browsers worth trying (like Polypane for web developers, or Arc for tech-savvy users), but I’ll leave those to my future self.

My browser journey: Chrome → Edge → Brave → Firefox

• Chrome: the OG browser (I intentionally exclude IE here 💔). However, ever since I started considering RAM consumption, I switched to Edge.
• Edge: I heard good things about how the Edge team improved the DX (devtools) of Edge, as well as tons of built-in utilities. Sadly, I didn’t follow through on trying out these devtools improvements. However, I was aware it lacked a built-in ad-blocker, which became important to me at the time.
• Brave: the one with built-in ad-blocker! I used it for a while.
  • I probably just wanted to play nice in a world where some content creators rely on ads for their living.
• Safari: the one that iPhone or macOS users cannot skip. I don’t have many complaints against it.
  • If I must name one it would be the extensions ecosystem—it’s WAY smaller than other browsers.
• Firefox: the one I am currently using, mainly for the open source ethos. I know that Firefox doesn’t always keep up with web standards.
  • But hey, I can wait (it would not be the same case if I was a dedicated front-end developer).
• Cake (discontinued): Used once when I was in my first web developer job. The mobile-first approach (swipe-based UX) was quite refreshing at the time.

Extensions

• UBlock, AdBlock: almost the same thing, good thing is that I can turn it off anytime I want. I am currently using uBlock.
• SurfingKeys: another must-install extension. I’ve developed muscle memory for its basic shortcut setup. I just can’t get rid of it.
  • I strongly recommend it to people who have tried and failed multiple times to adapt to VIM-based shortcut layouts.
  • This extension helped me get into the VIM world in one go (true story).
• Tampermonkey: the advanced tool for those who were fascinated by the concept of optimizing personal browsing experience.
  • I try to keep everything default nowadays, but I still keep a few Bookmarklets in my toolbar.
  • Probably someday I will migrate them into Tampermonkey.
• Tree-Style-Tabs: Used for a small period when I was deeply into the hyperlink graph while reading academic Wikipedia pages.
  • It was feature-rich. If one could figure out how to combine SurfingKeys with Tree-Style-Tabs or simply customize its shortcuts, it would be awesome.
  • However, I seldom browse the web that deeply these days.

Keyboard Layout & IME

I’ve experimented with various keyboard layouts and input methods to solve ergonomic problems and improve typing speed. The challenge with Chinese input is particularly interesting—Chinese homophones are extremely wild in comparison to English. There are edge cases where phonetic input methods are just not good enough, which is why graphological input methods exist.

There have been tons of different graphological Chinese input methods invented over the years, but none were popular enough to last for decades. I feel these inventions should be treated as cultural heritage conservation—a record that Chinese users, developers, and researchers all came together, trying to find solutions for wild homophones and hieroglyphs.

All typing speeds were measured as an average based on my observation. I used Monkeytype (English basic) to practice typing. (I type directly on my laptop, I don’t use any extra keyboard, minimalism FTW!)

• Qwerty Layout: I can reach 80-90 WPM.
  • However, my left wrist hurts if I practice too long, particularly when intentionally trying to reach 100 WPM on typing contest games. It’s not a problem during normal typing.
• Dvorak: I can reach 50 WPM.
  • I practiced this in order to solve the wrist problem, however, I soon found out that I cannot simply adapt to the alternating hands design baked into the layout.
• Colemak: I can reach 40 WPM.
  • I tried this for the same reason—to solve my wrist problem. I switched to this layout because it uses less alternating hands compared to Dvorak.
  • However, I had already gotten used to Dvorak, which held me back from learning Colemak. The conflicting muscle memory made progress slow.
• Bopomofo (Chinese Input Method): I am an OG Bopomofo typer. However, it’s quite hard to measure the speed due to the time spent on word selection being quite random.
  • In a perfectly controlled environment, I believe I can reach 160+ WPM which is way faster than my English typing.
  • If I figure out how to mix phonetic and graphological input methods together, I will try measuring my average speed.
• Array30 (Chinese Input Method): I chose this one as my first graphological input method and soon stopped practicing due to the learning curve.
  • It’s the same situation as Colemak—I already type really fast using the layouts I’ve skillfully mastered (Qwerty for English, Bopomofo for Chinese).
  • The ROI of learning yet another layout is just too low.
  • That said, Array30 is the only graphological input method I’ve tried, and I’m glad I attempted it to understand the alternative approach to Chinese input.

IDE & Editor

These are the tools where I’ve invested time customizing workflows and building personal utilities.

• Vim: I used it briefly, but enough to create some VIM scripts by myself. I also installed a few plugins, customized a few shortcuts, and built up my muscle memory.
• Emmet: This is basically HTML code snippets using very concise syntax. In other words, it’s templating and macroing via shortcuts—a power-user feature I would like to extend to other areas that I’m familiar with. I have an emotional connection to this elegant solution for generating complex structural text.
• VSCode Extension: back when I first started writing things in Markdown format, I built a VSCode extension to solve my own problems (sorting hierarchical lists, HTML headings/list conversion).
  • This was my first Electron-based project. However, VSCode made plugin development so smooth that I could hardly tell what Electron was doing behind the scenes.
  • I tried my very first TDD (Test-Driven Development) in this project.
  • However, it felt kind of weird—I felt that unit tests should not be entangled with any GUI-related functions.
  • The tool is still quite useful IMHO, but it was built in the pre-LLM era. I’m not convinced it’s worth using again, and besides, I no longer maintain the project.

Hardware

These devices represent personal milestones—each tied to a specific phase of my development journey.

• Asus Zenfone 2 (2015): my first smartphone. It helped me ship the first (developed from scratch) application to a client in my life. That’s something remarkable.
• Android Pixel 3XL (2018): my second smartphone. Nothing to complain about. I still play Rogue Adventure occasionally on this device (whenever there’s a major patch).
  • However, the price was a bit high in comparison with the sequels. And most important of all, OS patches discontinued in 2021.
  • I thought it would last longer since Android is maintained by Google.
• Surface 3 Tablet (2015): my first device that could run .NET SDK. I used this device to ship a few utility tools. It was pleasant to use back in the day.
• MacBook Pro (2018, 15inch): my first laptop that I originally planned to use for developing applications on as many platforms as possible.
  • The reality is that I only code in C# doing the web stuff I am used to. It was truly YAGNI whenever I think of it.
  • The device still works like a charm, however, it is kind of a brown field after 6+ years of usage.
• iPhone SE 2022: my first iPhone. I chose this one to get rid of mobile gaming and binge-watching (because the screen is just too small compared with Pixel 3 XL).
  • However, the strategy failed. The reality is that humans adapt. After a few months of discomfort, I can do all the same things I did on the previous phone 🤣🤣
  • Except for incompatible applications or the occasional use of the magnifier utility.

Back-end

I don’t do fancy backend stuff in my spare time. JAMstack websites don’t require a backend server by definition. If I want to make something complicated, I normally go straight to C# console apps. That’s why my knowledge in the NodeJS ecosystem is quite limited. Most of the backend tools I use are C#/.NET based, which were mentioned in the previous article.

• NodeJS: the go-to JavaScript runtime for every regular developer. NodeJS is popular, and vite-based solutions require you to have Node installed. Vite is a superb tool for scaffolding front-end projects.
  • I would love to try Deno or Bun if I had the chance, just to breathe some fresh air and keep those awesome logos (mascots) around.
• Prisma: an ORM framework that includes tons of utilities. I don’t see Entity Framework heading in the same direction.
  • One thing I appreciate about Prisma is the free GUI client tool that comes with it.
  • EF developers normally need to install their RDBMS client of choice, such as SSMS or DBeaver.
  • However, that’s just the way we appreciate things from different backgrounds. 💕

Database

My philosophy on data storage: I prefer to defer the data storage decision until the last moment. Usually, plain text files are sufficient for my needs. For example, I use a database only for view counts on my blog posts—which is obviously overkill. This reluctance to commit early to database choices reflects my minimalist approach.

• SQLite: the go-to option whenever you want to start something small and you need a relational database to manage state and transactional stuff.
• Turso: I used it in a POC project. It just works.
• PlanetScale: yet another DB I used in a POC project. Equally charming as Turso. The most notable feature is that you can branch and merge a database just like you manage code branches in git.

DevOps

I occasionally experiment with modern DevOps tooling, though this isn’t my primary focus in personal projects.

• Codecov: used once just to try out the CI/CD trends.
• Google Cloud Platform: used once for my personal OCR project. The background story: I spent a lot of time on a tower defense game called Infinitode. At the time, I was fascinated by the built-in statistics after each game where you could see an overview of how much damage was dealt by each tower. The stats were all good, however, the game skipped the part where players might want to calculate damage dealt divided by money invested—which is crucial if you wish to estimate the cost-efficiency of a tower. My solution was to take a screenshot of the stats, send it to the GCP OCR API to parse all the numbers from the image, do the math, then store the numbers into a spreadsheet (also using Google API).

Operating System

Note: This article records things I’ve used in the past, not necessarily what I’m currently using or learning.

• macOS: the one that works out of the box. Synchronizes stuff between Apple devices like a breeze. Top-tier consistent UI look and shortcut management.
  • I’d still recommend a developer get one if budget isn’t a concern and you don’t have time for all the configuration.

Closing Thoughts

The pattern is clear: complexity promises more but delivers maintenance debt. Plain text, minimal syntax, and vanilla solutions consistently win. The brown field problem taught me that starting fresh isn’t about tools failing—it’s about learning what truly matters.

If you’re curious about my work-related tools, check out Part 1.