How to Build a Slow Product in the Fast AI Era
It has been a little over two months since I wrote the previous post, From Mole CLI to Mole for Mac: What I Learned. In that time Mole went from 1.13 all the way to 1.18, added AI tool cleanup and System Data cleanup, the Windows version shipped on the evening of October 14, and the GitHub repository quietly passed 72.9K stars.
Looking back, most of my time did not go into new features. It went into things that look like a poor trade to an engineer: installing 850 Mac apps from China and abroad one by one, using each a little, then uninstalling it; resending more than 400 unactivated license emails one at a time; redrawing dozens of icons over three rounds; and rewriting the interface copy line by line until someone opening Mole for the first time could follow it.
Programmers naturally like work that scales. Whatever the task, we look for a way to turn it into a tool, a script or an AI call so we can be lazy. These two months left me feeling a bit differently. Code keeps getting cheaper and anyone can quickly build something that runs, so what sets products apart is more and more the details you only learn by doing the work yourself. The good news is that with AI, these chores that used to take a lot of people can now be finished by one.
From 100 apps to 850: software engineering has no real standard
I am a bit obsessive and keep my own Mac at around 30 apps. To make Mole's uninstall more thorough and its leftover cleanup stronger, the first round collected more than 300 Mac apps from China and abroad, about 100 GB of downloads, split into 30 groups of 10. An agent used computer use to download each from its official site, install it on my Mac, check its folders, update bundles and login items, uninstall it, look for what was left behind, and add the missing rules to Mole.
At first I thought 100 mainstream apps would be plenty. When those were done I thought, why not another 100, and at 200 I thought the same again. Later I added App Store versions and extensions, and the count went to 549, 709, 824, and now 850. My Mac suddenly turned into the very messy desktop below. Have a look.
!The real desktop during testing, with open apps, permission prompts and work windows piled on top of each other
The process looks extremely boring. Many apps start popping up permission requests the moment they are installed, nudge you to buy a membership, and some insist on an administrator password. The agent handled most of it on its own and I stepped in for the rest. What surprised me most was that the AI wrote its own scripts to automate installing, uninstalling and checking leftovers, to make its job easier. Quite clever. I was mostly its assistant.
It also changed some of my assumptions. I thought software engineering was orderly and followed conventions, and that after 100 apps there would be few rules left to add, since the conventions of mainstream apps should be enumerable. The further I went, the clearer it became that this was wrong. Many leftovers cannot be found by any general rule, and some bundle IDs are not even reverse domain names. A convention that looks tidy may just be what some programmer typed years ago, with no theory behind it, so the only way is to install one and check one.
That first round of more than 300 apps gave Mole 13 kinds of reusable general rules and more than 90 precise cleanup paths. Along the way it also fixed more than 30 places I had thought should be cleaned but should actually be left alone, and added more than 100 unit tests. Those places to leave alone were as valuable to me as the new leftovers: a cache can be rebuilt, the user's own files cannot, and data several apps share should never go just because one of them was uninstalled.
I also wrote up the leftover paths and uninstall steps for every app as guides in Chinese and English on the site. All 850 are free to read, so even without any tools you can follow them by hand. See whether the apps on your Mac are in this list.
!The AI tools part of the tested app list
You only know an AI tool once you have used it
Before Mole had AI cleanup, many people had asked to clean up the data AI tools leave behind. I used to see AI coding session history as a valuable asset, so Mole only cleaned real caches and old versions there.
But using AI every day, I had piled up plenty of old artifacts, old sessions and worktrees I no longer needed, and one user's single opencode.db had grown to 62 GB and they urgently asked how to clean it. So I tested more than 30 AI tools one by one: 13 desktop apps, 13 command line tools, plus the folders OpenClaw, Hermes and Pi leave behind after uninstall.
Unlike the earlier install-and-uninstall rounds, this time I signed in to every tool I could and really used it once in a real project: asking questions, running agents, building code indexes, setting scheduled tasks. A lot of the data only appears after real use, and an app you install but never open will not show it.
For each tool, the AI compared against the state before install, measured what it wrote into the home folder, ~/Library, /usr/local/bin and the shell configuration, and recorded it in a ledger. Then it checked how many processes and how much memory the tool used, uninstalled it with Mole, and scanned the whole home folder by name for anything unlisted. Whatever was missing went into the code that night and was tested again.
This round was more surprising than ordinary apps. The most visible part was memory: the 13 desktop apps open together took about 23 GB, and one tool from a big Chinese company started 41 processes and 4.49 GB of memory on launch. Most of these tools are built on VS Code or Electron, so each window brings a string of helpers. That is why, when I built status monitoring, I gave each app one row and added up all of its child processes; in Activity Monitor alone it is hard to see who is actually eating the memory.
Then there were the small changes they made to the system. Some tools, on first launch, put a root-owned command link in /usr/local/bin, which becomes a dead link once the app is deleted. One put a python3.12 into ~/.local/bin, so typing python3.12 in the terminal afterwards ran its bundled copy. The worst was a Chinese command line tool: I ran it once, it told me it was no longer maintained, and then, without asking, downloaded and installed its new version, edited .zshrc, and renamed the old command to legacy.
The sizes were wild too. One desktop app downloaded a roughly 1 GB toolkit the first time I used its Work mode, 3.1 GB unpacked, carrying its own LibreOffice, FFmpeg and OpenJDK. My own ~/.codex, which I use every day, was already 24 GB, 17 GB of it sessions, and 12 GB of the Claude desktop app's 14 GB was the Cowork virtual machine. Many skill installers also write a skills/ folder into every agent's directory whether or not you have that agent, so I had config folders for Qwen Code, iFlow and Droid without ever using them. Mole's first version even treated them as 2.4 MB of tool leftovers and nearly cleaned out my installed skills as junk.
Something else I did not expect was processes. The morning after an uninstall, two command line tools had their folders deleted and grown back. The terminal sessions from the night before were still alive: the program files were already in the Trash, but the background processes kept writing logs into the folders. A command line tool has no window, and closing the terminal tab does not necessarily end it.
I also saw plenty of mess. Some installers quietly write something to your clipboard while downloading, to track the install channel. Some pop up endless prompts to join campaigns and claim tokens, ads plastered everywhere, the kind of tool you hold your nose to use. By comparison, Claude, Codex and Cursor stayed fairly restrained, and in China the one that pleasantly surprised me was Qoder: a clean interface, good taste, nothing pushy.
All this changed one of my earlier judgments. Sessions really are valuable, but old sessions and worktrees you are done with really do take space. Today's AI cleanup lists sessions by the retention period you choose, 15, 30, 90 or 120 days, each with its title and time, and keeps a recovery copy before deleting. A worktree only shows up when git can prove it has no uncommitted changes. opencode.db gets database compaction, which only returns the freed pages to the disk and never deletes the user's conversations.
!Mole's AI Cleanup & Care page, listed in three sections: caches and old versions, sessions and workspaces, idle tools
System Data is the hardest part to test
A while ago I was browsing Reddit and saw many people complaining that System Data in macOS settings often reaches one or two hundred GB, asking what it is and whether it can be deleted. That number is only the result of a classification. Apple's own explanation also counts every file the other categories did not take, so it is not a list you can delete from. Mole's System Data group therefore only states how much it measured and can handle, and does not try to match the total in System Settings.
The hard part is that you cannot install one thing and check one thing on your own machine here. Every Mac's System Data is different, and many cases can only wait for a user report and then be traced layer by layer.
Take purgeable space. The number the system reports mixes iCloud files that can be reclaimed with caches the system will release on its own. Even a Mac with no local snapshots shows around 142 GB. Early Mole used that number to estimate how much snapshots could free, estimated 50.7 GB, and after cleaning the free space only grew by a few GB. Now the snapshot row no longer shows an estimated size; after cleaning, Mole measures how much free space actually changed, and since APFS does not return space all at once after a delete, it waits until the number stops growing. Along the way I caught a bug: reading free space always returned a stale cached value, so cleaning always showed 0 freed.
Another user's System Data held 179.53 GB of wallpaper render cache, 6644 files in all, an uncompressed BMP for every wallpaper at every screen size, never deleted by the system. The first version could find it but could not delete a single byte, because the wallpaper process is always running in the background, and the command that checks whether a file is in use reported errors on single files, which were treated as uncertain. In the end it only lists the ones older than a week that are not currently on screen, for the user to confirm, and this shipped in 1.17.
As for things like the 119 GB iPhone backup and the 79.5 GB Parallels virtual machine on my own Mac, they are big but should never sit behind a select-all delete button. Mole only shows their size and where to manage them, they cannot be ticked, and they do not count toward the space that can be cleaned, so people go back to the right place and make sure before doing anything.
!Mole's Clean page during development, with System Data at the top and Other Storage read-only
Resending 400 emails, plus a small piece of magic
Over the National Day holiday I spent a day on something I had put off for a long time. I went through every Mole order from the May launch to the end of September that was bought but never activated, about 400, had AI write a simple local script to list the emails and keys, and resent them one by one, grouped by purchase month, country and language. Not a promotion, and not a push to activate, more like sending a message to a friend: a reminder not to forget it, and no rush if they are not using it yet.
Interestingly, replies kept coming in from users in many countries, and they meant much more than I expected. Some said they bought it just to support the development and actually preferred the Terminal version, and some had forgotten about the GUI and had been using the CLI all along. One user had bought two, one for themselves and one for family as a Christmas present, so it was still unactivated, the key already saved in their password manager. It made the world feel like a lovely place.
One user could use it on a work computer at first, until the company banned software outside its approved list, and was waiting for a new Mac of their own to start using it. Another bought during a discount and still had no MacBook, planning to activate as soon as the new machine arrived. Someone replied with just "Prefect!", and someone else said during the holiday that it was time to slack off properly, a pun on mole that only works in Chinese. These replies were a joy to read.
Quite a few, though, had simply typed their email wrong, probably in a hurry, gmai.com, gmail.con, cloud.com and so on, and never came to me. Others never got the first email and bought again to start using it sooner.
In the back-end data, all of these people have the same status: not activated. Sending everyone the same activation reminder would have meant getting the problem wrong. People who bought to support Mole, kept it as a gift or were waiting for a new computer had nothing to be reminded about; the ones with a mistyped email or a lost message were the ones who never got their key. The dashboard numbers cannot tell these cases apart. Only reading the replies one by one can.
So I filled in a piece of the post-purchase flow: after payment, the user is taken back to the site, which displays the Key right away, so even with a mistyped email or a blocked message they see it immediately. There is also a neat little detail: clicking activate on the web page invokes the installed client through a custom protocol and automatically fills in the Key, leaving the user to just press confirm without copying and pasting.
Taken apart, this small piece of magic is just the web page handing the system a link Mole recognizes, the system handing it to the app, and the app only placing the key in the input field. It never confirms the activation for the user; it still goes through the original license check, and the last step stays with the user. An engineer who has built clients or front ends may find this trivial, but to most users it feels like wow, how did it do that, this product did a little extra for me. Maybe that is what I keep chasing in products: a few fun touches that give users that sense of magic, a little of the hackers and painters feeling.
Lately I have been doing something similar: writing to the early users who bought Mole right after its launch in May, with versions in Simplified Chinese, Traditional Chinese, English, Spanish and French. The letter mostly thanks them for supporting it so early, mentions that the Mac version has added System Data and AI cleanup these months and that checking for updates in Mole brings them in, and ends by asking them to reply directly with anything that feels off or any feature they want.
Even a short letter like that went through several drafts. The first few always read a bit like a sales pitch, like a marketing email. I rewrote it line by line in the tone I use with friends, simple, clear, not wordy, until it read like a letter I would actually send myself.
Paul Graham wrote in Do Things that Don't Scale that Wufoo sent handwritten thank-you notes to early users and that the Stripe founders would take a user's laptop and set them up on the spot. Now that code is hardly a moat anymore, this kind of unscalable, patient work is worth even more.
A new set of icons, another round of copy
The detail that took the most time these two months was replacing every icon in Mole. Before, I used system icons, which are fine for simple cases but lack a bit of soul up close. After looking around, Remix Icon, which I use a lot for the web, did not look right in an app. I settled on Phosphor: about 70% could be used directly, and the other 30% I drew as SVGs with Opus 5.5 so the line width and style would stay consistent.
!35 pairs of icons, each with the old system icon on the left and the new icon on the right
I have always wanted what I make to feel alive, with some spirit, so people using it can tell that care went into it, and small details like icons are a good place to start. For Keep Screen On I used a cup of coffee, a nod to Caffeine, as if the computer drank coffee and could not sleep. About usually gets a circled i, but I thought it should say hello, so I used a waving hand. Diagnostics would normally get a troubleshooting mark; I used a stethoscope, more like giving the computer a checkup.
Then the feedback after release made me realize some of the icons could still be better. Some icons I liked, users found unclear. Check for Updates used a download icon, so people read it as download. The little square for the GPU did not read as a graphics card, the archive icon was confusing, and two stacked memory sticks did not look much like memory. Some said the sponge for Clean Screen and the waving hand for About made no sense. Thinking about it, they were right: an icon first has to be understood, and looking nice comes second.
So I reworked all of these as people suggested. Check for Updates became a clockwise arrow, the GPU became a dual-fan graphics card, the archive became a storage box, audio went from a music note to headphones, Clean Screen went back to its original brush, memory went back to a chip, and About ended up as the most orthodox ⓘ, just redrawn to the line width of its column. Quite a few were changed three times before they finally felt right.
!The same piece of interface side by side, each row from left to right: the system icon, the first version, and what it looks like now
The copy took the same kind of fiddling. I had used up most of my Claude and Codex quota writing code, so I dug out Gemini, which had been gathering dust for a while, switched to 3.8 Flash High and asked it to look at the copy. It pleasantly surprised me: it may not be the very best at code, but it writes plain language very well. I put almost all of Mole's settings, cleanup item descriptions and site content through it. The brief was simple: talk like a person, simple, clear, easy to grasp, so someone using it for the first time gets it instantly, nothing stilted and no AI tone.
I had it output before and after versions with the reason for each change, then went through them one by one. It really felt like having a very patient language teacher sitting beside me, turning a lot of programmer-pleasing phrasing into words normal people can follow. For example, the cache deletion item used to be easy to misread as the way the whole app gets deleted; now it says clearly that it only covers ordinary caches on the Clean page and does not affect uninstall.
Accessibility helped a lot
Testing hundreds of apps brought an unexpected bonus. In its first few versions Mole already supported blind and low-vision users with many accessibility attributes, and this time they helped a lot: with them, the AI could find every button and element very precisely, and testing went much more smoothly.
Accessibility attributes give more than a coordinate. They say what a control is called, what kind it is and what state it is in, so when the interface shifts a little, a script still finds the same button. Relying only on screenshots and coordinates, a changed dialog or a moved window easily makes the click miss. From the start Apple wanted everyone to be able to use a computer equally, so much of the system can be read by VoiceOver, and I love that. Fellow indie developers, when you build apps and web pages, let your AI coding tool add accessibility along the way. Once blind users can really use it, it often comes back to help you in automated testing later.
One Mac, plus one ThinkPad
The Windows version was tested the same way, one app at a time. Windows was not starting from zero: Mole's Windows CLI has been maintained since early this year with contributions from the community, and the CLI is quite mature now. That groundwork is what made this desktop version possible. The desktop version uses native C# and WinUI 3 on Windows, and the Swift code of the Mac version is almost no use there. It took close to a month of back and forth, 78,000 lines of code and more than 4,000 test cases. The 486 Windows apps tested so far ran mostly in a Parallels virtual machine on the Mac. I also bought a ThinkPad X1 that stays on 24 hours a day, and the Mac connects to it through UU Remote and ssh, letting the AI operate this real computer directly for install, uninstall and cleanup acceptance.
!The Apps page of Mole for Windows, listing installed apps and their sizes
Now my Mac is the main machine for all of development. It runs the Parallels virtual machine, connects to the ThinkPad X1 beside it, and has a small Android tablet on a cable; with adb debugging on, the AI can operate some services that have no API, and there is also the iPhone simulator in Xcode. All the AI context lives on this one Mac. Usually 7 to 10 terminal tabs of agents are running tasks, suggestions and feedback collected on social platforms go into Notion, and the AI marks them done once handled. That is how I can clear so many GitHub issues one by one on my own.
!My workspace: the Mac in the middle, the ThinkPad X1 on the left, the Android tablet plugged in on the right, with Mole open on every screen
How exactly to build Windows software on a Mac, for example how to layer the code so the tests run on the Mac and how to drive the virtual machine with scripts, I wrote up separately in this post on Mole's blog, and the trade-offs in choosing the stack are in You Don't Know Client Development. Have a look if you are doing the same.
Polishing that looks like wasted effort
AI makes code faster to write and makes a passable interface much easier to build. It can look as if people have nothing left to do but talk. My experience these months is that the human part matters even more now, and the time AI saves us is exactly what we can spend on this polishing that looks like wasted effort.
Installing and uninstalling 850 apps one by one, reading every reply, redrawing dozens of icons three times: AI will not decide to do these for you. But once they are done, if 1% of your users now and then get that instant understanding, that wow, that feeling of a magic trick while using your product, it is very much worth it.
The pitfalls turned into cleanup rules, more than 100 new unit tests and public guides, so next time I do not start from scratch. That is what keeps this patient work from going to waste.
The more apps I test, the more I want Mole to keep its current restraint: no uploading of users' local files or session content, no usage analytics of any kind, and no new switch where a default will do.
Next on the Mac side I want to reach 1,000 apps first, and the Windows side will keep filling in too. If your computer has an app that is especially hard to uninstall or leaves deep leftovers, tell me in the GitHub discussion and I will put it on the next round's list. Steadily making a tool I enjoy using and others find reliable is what makes me happy.
The CLI remains open source and free on GitHub, and the desktop versions for Mac and Windows are at mole.fit. Feel free to come and complain anytime.
1 reaction
Mentions
Kami 1.20 is out. Your AI writes the words, Kami gives them good paper. From the last three releases: charts drawn from data and checked before delivery, product sites in the product's own color, and Chinese and Korean pages that read well on iPhone. tw93/kami t.co
Kaku shipped 9 releases in October, mostly on remote access. Run kaku remote and your Mac's terminals, running Claude Code sessions included, open in a browser on another device, and it now works with touch, on the web page and over remote desktop. tw93/Kaku t.co
How to Build a Slow Product in the Fast AI Era It has been a little over two months since I wrote the previous post, From Mole CLI to Mole for Mac: What I Learned. In that time Mole went from 1.13 all the way to 1.18, added AI tool cleanup and System Data cleanup, the Windows version shipped on the evening of October 14, and the GitHub repository quietly passed 72.9K stars. Looking back, most of my time did not go into new features. It went into things that look like a poor trade to an engineer: installing 850 Mac apps from China and abroad one by one, using each a little, then uninstalling it; resending more than 400 unactivated license emails one at a time; redrawing dozens of icons over three rounds; and rewriting the interface copy line by line until someone opening Mole for the first time could follow it. Programmers naturally like work that scales. Whatever the task, we look for a way to turn it into a tool, a script or an AI call so we can be lazy. These two months left me feeling a bit differently. Code keeps getting cheaper and anyone can quickly build something that runs, so what sets products apart is more and more the details you only learn by doing the work yourself. The good news is that with AI, these chores that used to take a lot of people can now be finished by one. From 100 apps to 850: software engineering has no real standard I am a bit obsessive and keep my own Mac at around 30 apps. To make Mole's uninstall more thorough and its leftover cleanup stronger, the first round collected more than 300 Mac apps from China and abroad, about 100 GB of downloads, split into 30 groups of 10. An agent used computer use to download each from its official site, install it on my Mac, check its folders, update bundles and login items, uninstall it, look for what was left behind, and add the missing rules to Mole. At first I thought 100 mainstream apps would be plenty. When those were done I thought, why not another 100, and at 200 I thought the same again. Later I added App Store versions and extensions, and the count went to 549, 709, 824, and now 850. My Mac suddenly turned into the very messy desktop below. Have a look. !The real desktop during testing, with open apps, permission prompts and work windows piled on top of each other The process looks extremely boring. Many apps start popping up permission requests the moment they are installed, nudge you to buy a membership, and some insist on an administrator password. The agent handled most of it on its own and I stepped in for the rest. What surprised me most was that the AI wrote its own scripts to automate installing, uninstalling and checking leftovers, to make its job easier. Quite clever. I was mostly its assistant.  It also changed some of my assumptions. I thought software engineering was orderly and followed conventions, and that after 100 apps there would be few rules left to add, since the conventions of mainstream apps should be enumerable. The further I went, the clearer it became that this was wrong. Many leftovers cannot be found by any general rule, and some bundle IDs are not even reverse domain names. A convention that looks tidy may just be what some programmer typed years ago, with no theory behind it, so the only way is to install one and check one. That first round of more than 300 apps gave Mole 13 kinds of reusable general rules and more than 90 precise cleanup paths. Along the way it also fixed more than 30 places I had thought should be cleaned but should actually be left alone, and added more than 100 unit tests. Those places to leave alone were as valuable to me as the new leftovers: a cache can be rebuilt, the user's own files cannot, and data several apps share should never go just because one of them was uninstalled. I also wrote up the leftover paths and uninstall steps for every app as guides in Chinese and English on the site. All 850 are free to read, so even without any tools you can follow them by hand. See whether the apps on your Mac are in this list. !The AI tools part of the tested app list You only know an AI tool once you have used it Before Mole had AI cleanup, many people had asked to clean up the data AI tools leave behind. I used to see AI coding session history as a valuable asset, so Mole only cleaned real caches and old versions there. But using AI every day, I had piled up plenty of old artifacts, old sessions and worktrees I no longer needed, and one user's single opencode.db had grown to 62 GB and they urgently asked how to clean it. So I tested more than 30 AI tools one by one: 13 desktop apps, 13 command line tools, plus the folders OpenClaw, Hermes and Pi leave behind after uninstall. Unlike the earlier install-and-uninstall rounds, this time I signed in to every tool I could and really used it once in a real project: asking questions, running agents, building code indexes, setting scheduled tasks. A lot of the data only appears after real use, and an app you install but never open will not show it. For each tool, the AI compared against the state before install, measured what it wrote into the home folder, ~/Library, /usr/local/bin and the shell configuration, and recorded it in a ledger. Then it checked how many processes and how much memory the tool used, uninstalled it with Mole, and scanned the whole home folder by name for anything unlisted. Whatever was missing went into the code that night and was tested again. This round was more surprising than ordinary apps. The most visible part was memory: the 13 desktop apps open together took about 23 GB, and one tool from a big Chinese company started 41 processes and 4.49 GB of memory on launch. Most of these tools are built on VS Code or Electron, so each window brings a string of helpers. That is why, when I built status monitoring, I gave each app one row and added up all of its child processes; in Activity Monitor alone it is hard to see who is actually eating the memory. Then there were the small changes they made to the system. Some tools, on first launch, put a root-owned command link in /usr/local/bin, which becomes a dead link once the app is deleted. One put a python3.12 into ~/.local/bin, so typing python3.12 in the terminal afterwards ran its bundled copy. The worst was a Chinese command line tool: I ran it once, it told me it was no longer maintained, and then, without asking, downloaded and installed its new version, edited .zshrc, and renamed the old command to legacy. The sizes were wild too. One desktop app downloaded a roughly 1 GB toolkit the first time I used its Work mode, 3.1 GB unpacked, carrying its own LibreOffice, FFmpeg and OpenJDK. My own ~/.codex, which I use every day, was already 24 GB, 17 GB of it sessions, and 12 GB of the Claude desktop app's 14 GB was the Cowork virtual machine. Many skill installers also write a skills/ folder into every agent's directory whether or not you have that agent, so I had config folders for Qwen Code, iFlow and Droid without ever using them. Mole's first version even treated them as 2.4 MB of tool leftovers and nearly cleaned out my installed skills as junk. Something else I did not expect was processes. The morning after an uninstall, two command line tools had their folders deleted and grown back. The terminal sessions from the night before were still alive: the program files were already in the Trash, but the background processes kept writing logs into the folders. A command line tool has no window, and closing the terminal tab does not necessarily end it. I also saw plenty of mess. Some installers quietly write something to your clipboard while downloading, to track the install channel. Some pop up endless prompts to join campaigns and claim tokens, ads plastered everywhere, the kind of tool you hold your nose to use. By comparison, Claude, Codex and Cursor stayed fairly restrained, and in China the one that pleasantly surprised me was Qoder: a clean interface, good taste, nothing pushy. All this changed one of my earlier judgments. Sessions really are valuable, but old sessions and worktrees you are done with really do take space. Today's AI cleanup lists sessions by the retention period you choose, 15, 30, 90 or 120 days, each with its title and time, and keeps a recovery copy before deleting. A worktree only shows up when git can prove it has no uncommitted changes. opencode.db gets database compaction, which only returns the freed pages to the disk and never deletes the user's conversations. !Mole's AI Cleanup & Care page, listed in three sections: caches and old versions, sessions and workspaces, idle tools System Data is the hardest part to test A while ago I was browsing Reddit and saw many people complaining that System Data in macOS settings often reaches one or two hundred GB, asking what it is and whether it can be deleted. That number is only the result of a classification. Apple's own explanation also counts every file the other categories did not take, so it is not a list you can delete from. Mole's System Data group therefore only states how much it measured and can handle, and does not try to match the total in System Settings. The hard part is that you cannot install one thing and check one thing on your own machine here. Every Mac's System Data is different, and many cases can only wait for a user report and then be traced layer by layer. Take purgeable space. The number the system reports mixes iCloud files that can be reclaimed with caches the system will release on its own. Even a Mac with no local snapshots shows around 142 GB. Early Mole used that number to estimate how much snapshots could free, estimated 50.7 GB, and after cleaning the free space only grew by a few GB. Now the snapshot row no longer shows an estimated size; after cleaning, Mole measures how much free space actually changed, and since APFS does not return space all at once after a delete, it waits until the number stops growing. Along the way I caught a bug: reading free space always returned a stale cached value, so cleaning always showed 0 freed. Another user's System Data held 179.53 GB of wallpaper render cache, 6644 files in all, an uncompressed BMP for every wallpaper at every screen size, never deleted by the system. The first version could find it but could not delete a single byte, because the wallpaper process is always running in the background, and the command that checks whether a file is in use reported errors on single files, which were treated as uncertain. In the end it only lists the ones older than a week that are not currently on screen, for the user to confirm, and this shipped in 1.17. As for things like the 119 GB iPhone backup and the 79.5 GB Parallels virtual machine on my own Mac, they are big but should never sit behind a select-all delete button. Mole only shows their size and where to manage them, they cannot be ticked, and they do not count toward the space that can be cleaned, so people go back to the right place and make sure before doing anything. !Mole's Clean page during development, with System Data at the top and Other Storage read-only Resending 400 emails, plus a small piece of magic Over the National Day holiday I spent a day on something I had put off for a long time. I went through every Mole order from the May launch to the end of September that was bought but never activated, about 400, had AI write a simple local script to list the emails and keys, and resent them one by one, grouped by purchase month, country and language. Not a promotion, and not a push to activate, more like sending a message to a friend: a reminder not to forget it, and no rush if they are not using it yet. Interestingly, replies kept coming in from users in many countries, and they meant much more than I expected. Some said they bought it just to support the development and actually preferred the Terminal version, and some had forgotten about the GUI and had been using the CLI all along. One user had bought two, one for themselves and one for family as a Christmas present, so it was still unactivated, the key already saved in their password manager. It made the world feel like a lovely place. One user could use it on a work computer at first, until the company banned software outside its approved list, and was waiting for a new Mac of their own to start using it. Another bought during a discount and still had no MacBook, planning to activate as soon as the new machine arrived. Someone replied with just "Prefect!", and someone else said during the holiday that it was time to slack off properly, a pun on mole that only works in Chinese. These replies were a joy to read. Quite a few, though, had simply typed their email wrong, probably in a hurry, gmai.com, gmail.con, cloud.com and so on, and never came to me. Others never got the first email and bought again to start using it sooner. In the back-end data, all of these people have the same status: not activated. Sending everyone the same activation reminder would have meant getting the problem wrong. People who bought to support Mole, kept it as a gift or were waiting for a new computer had nothing to be reminded about; the ones with a mistyped email or a lost message were the ones who never got their key. The dashboard numbers cannot tell these cases apart. Only reading the replies one by one can. So I filled in a piece of the post-purchase flow: after payment, the user is taken back to the site, which displays the Key right away, so even with a mistyped email or a blocked message they see it immediately. There is also a neat little detail: clicking activate on the web page invokes the installed client through a custom protocol and automatically fills in the Key, leaving the user to just press confirm without copying and pasting.  Taken apart, this small piece of magic is just the web page handing the system a link Mole recognizes, the system handing it to the app, and the app only placing the key in the input field. It never confirms the activation for the user; it still goes through the original license check, and the last step stays with the user. An engineer who has built clients or front ends may find this trivial, but to most users it feels like wow, how did it do that, this product did a little extra for me. Maybe that is what I keep chasing in products: a few fun touches that give users that sense of magic, a little of the hackers and painters feeling. Lately I have been doing something similar: writing to the early users who bought Mole right after its launch in May, with versions in Simplified Chinese, Traditional Chinese, English, Spanish and French. The letter mostly thanks them for supporting it so early, mentions that the Mac version has added System Data and AI cleanup these months and that checking for updates in Mole brings them in, and ends by asking them to reply directly with anything that feels off or any feature they want. Even a short letter like that went through several drafts. The first few always read a bit like a sales pitch, like a marketing email. I rewrote it line by line in the tone I use with friends, simple, clear, not wordy, until it read like a letter I would actually send myself. Paul Graham wrote in Do Things that Don't Scale that Wufoo sent handwritten thank-you notes to early users and that the Stripe founders would take a user's laptop and set them up on the spot. Now that code is hardly a moat anymore, this kind of unscalable, patient work is worth even more. A new set of icons, another round of copy The detail that took the most time these two months was replacing every icon in Mole. Before, I used system icons, which are fine for simple cases but lack a bit of soul up close. After looking around, Remix Icon, which I use a lot for the web, did not look right in an app. I settled on Phosphor: about 70% could be used directly, and the other 30% I drew as SVGs with Opus 5.5 so the line width and style would stay consistent. !35 pairs of icons, each with the old system icon on the left and the new icon on the right I have always wanted what I make to feel alive, with some spirit, so people using it can tell that care went into it, and small details like icons are a good place to start. For Keep Screen On I used a cup of coffee, a nod to Caffeine, as if the computer drank coffee and could not sleep. About usually gets a circled i, but I thought it should say hello, so I used a waving hand. Diagnostics would normally get a troubleshooting mark; I used a stethoscope, more like giving the computer a checkup. Then the feedback after release made me realize some of the icons could still be better. Some icons I liked, users found unclear. Check for Updates used a download icon, so people read it as download. The little square for the GPU did not read as a graphics card, the archive icon was confusing, and two stacked memory sticks did not look much like memory. Some said the sponge for Clean Screen and the waving hand for About made no sense. Thinking about it, they were right: an icon first has to be understood, and looking nice comes second. So I reworked all of these as people suggested. Check for Updates became a clockwise arrow, the GPU became a dual-fan graphics card, the archive became a storage box, audio went from a music note to headphones, Clean Screen went back to its original brush, memory went back to a chip, and About ended up as the most orthodox ⓘ, just redrawn to the line width of its column. Quite a few were changed three times before they finally felt right. !The same piece of interface side by side, each row from left to right: the system icon, the first version, and what it looks like now The copy took the same kind of fiddling. I had used up most of my Claude and Codex quota writing code, so I dug out Gemini, which had been gathering dust for a while, switched to 3.8 Flash High and asked it to look at the copy. It pleasantly surprised me: it may not be the very best at code, but it writes plain language very well. I put almost all of Mole's settings, cleanup item descriptions and site content through it. The brief was simple: talk like a person, simple, clear, easy to grasp, so someone using it for the first time gets it instantly, nothing stilted and no AI tone. I had it output before and after versions with the reason for each change, then went through them one by one. It really felt like having a very patient language teacher sitting beside me, turning a lot of programmer-pleasing phrasing into words normal people can follow. For example, the cache deletion item used to be easy to misread as the way the whole app gets deleted; now it says clearly that it only covers ordinary caches on the Clean page and does not affect uninstall. Accessibility helped a lot Testing hundreds of apps brought an unexpected bonus. In its first few versions Mole already supported blind and low-vision users with many accessibility attributes, and this time they helped a lot: with them, the AI could find every button and element very precisely, and testing went much more smoothly. Accessibility attributes give more than a coordinate. They say what a control is called, what kind it is and what state it is in, so when the interface shifts a little, a script still finds the same button. Relying only on screenshots and coordinates, a changed dialog or a moved window easily makes the click miss. From the start Apple wanted everyone to be able to use a computer equally, so much of the system can be read by VoiceOver, and I love that. Fellow indie developers, when you build apps and web pages, let your AI coding tool add accessibility along the way. Once blind users can really use it, it often comes back to help you in automated testing later. One Mac, plus one ThinkPad The Windows version was tested the same way, one app at a time. Windows was not starting from zero: Mole's Windows CLI has been maintained since early this year with contributions from the community, and the CLI is quite mature now. That groundwork is what made this desktop version possible. The desktop version uses native C# and WinUI 3 on Windows, and the Swift code of the Mac version is almost no use there. It took close to a month of back and forth, 78,000 lines of code and more than 4,000 test cases. The 486 Windows apps tested so far ran mostly in a Parallels virtual machine on the Mac. I also bought a ThinkPad X1 that stays on 24 hours a day, and the Mac connects to it through UU Remote and ssh, letting the AI operate this real computer directly for install, uninstall and cleanup acceptance. !The Apps page of Mole for Windows, listing installed apps and their sizes Now my Mac is the main machine for all of development. It runs the Parallels virtual machine, connects to the ThinkPad X1 beside it, and has a small Android tablet on a cable; with adb debugging on, the AI can operate some services that have no API, and there is also the iPhone simulator in Xcode. All the AI context lives on this one Mac. Usually 7 to 10 terminal tabs of agents are running tasks, suggestions and feedback collected on social platforms go into Notion, and the AI marks them done once handled. That is how I can clear so many GitHub issues one by one on my own. !My workspace: the Mac in the middle, the ThinkPad X1 on the left, the Android tablet plugged in on the right, with Mole open on every screen How exactly to build Windows software on a Mac, for example how to layer the code so the tests run on the Mac and how to drive the virtual machine with scripts, I wrote up separately in this post on Mole's blog, and the trade-offs in choosing the stack are in You Don't Know Client Development. Have a look if you are doing the same. Polishing that looks like wasted effort AI makes code faster to write and makes a passable interface much easier to build. It can look as if people have nothing left to do but talk. My experience these months is that the human part matters even more now, and the time AI saves us is exactly what we can spend on this polishing that looks like wasted effort. Installing and uninstalling 850 apps one by one, reading every reply, redrawing dozens of icons three times: AI will not decide to do these for you. But once they are done, if 1% of your users now and then get that instant understanding, that wow, that feeling of a magic trick while using your product, it is very much worth it. The pitfalls turned into cleanup rules, more than 100 new unit tests and public guides, so next time I do not start from scratch. That is what keeps this patient work from going to waste. The more apps I test, the more I want Mole to keep its current restraint: no uploading of users' local files or session content, no usage analytics of any kind, and no new switch where a default will do. Next on the Mac side I want to reach 1,000 apps first, and the Windows side will keep filling in too. If your computer has an app that is especially hard to uninstall or leaves deep leftovers, tell me in the GitHub discussion and I will put it on the next round's list. Steadily making a tool I enjoy using and others find reliable is what makes me happy. The CLI remains open source and free on GitHub, and the desktop versions for Mac and Windows are at mole.fit. Feel free to come and complain anytime.
YAMLResume v0.17 更新：全新的 kami HTML 模板、全引擎支持主题色、Docker 镜像瘦身 80% 各位好， [YAMLResume]( yamlresume.dev) 最近发布了 v0.17 ，在这里简单分享一下。 1. 支持主题色（ accent color ） YAMLResume 里所有的排版引擎（[docx]( yamlresume.dev)、[html]( yamlresume.dev) 、[latex]( yamlresume.dev)）现在都支持主题色（ accent color ），目前内置 9 个枚举值，也支持任意合法的十六进制颜色，比如 #RRGGBB。 写法大概是这样： layouts: - engine: latex theme: colors: accent: burgundy 下面是几个自定义主题色的示例：   2. 全新的 HTML kami 模板 我们新增了一个 kami HTML 模板，灵感来自 [tw93/kami]( tw93/kami) 这个项目。 这是在 Safari 浏览器里的效果：  代码非常简单，只要把 layouts.[].template 改成 kami 就行： layouts: - engine: html template: kami 前面提到过，我们的 HTML 模板也支持主题色，下面是绿色主题色的 kami 模板：  3. Docker 镜像体积缩小 80% 原来的 [yamlresume Docker 镜像]( hub.docker.com)（ Node.js 、CLI 、XeTeX 以及全部字体），从磁盘占用约 4GB （下载 1.77GB ），优化到了磁盘 866MB （下载 321MB ）。做法是用精选过的 TinyTeX 替代完整的 TeX Live 安装，并裁掉 XeLaTeX 根本不会读取的内容。 | 镜像 | 下载大小 | 磁盘占用 | | --- | --- | --- | | v0.16.x （更新前） | 1.77 GB | ~4 GB | | v0.17.0 （更新后） | 321 MB | 866 MB | 希望有用哈！ - 博客： yamlresume.dev - Kami 模板： yamlresume.dev - 主题色支持： yamlresume.dev - last update: v2ex.com
你不知道的客户端开发：选型、原生、多端与借力  发现不少小伙伴很好奇我是怎么用 Mac 来开发 [Mole Windows]( mole.fit) 软件的，以及 Windows 软件现在一般用什么技术栈来实现，刚好有空，来和大伙随便聊聊关于多客户端下技术选择的思考以及我的一些想法。 Web 、跨端还是原生 做过前端客户端的小伙伴应该都知道，这些年端的开发一般是这三条路。 第一种最简单方便的是，直接写 Web 代码，塞到浏览器就能跑，包括早年的 PhoneGap 、Cordova 就是把网页塞进一个原生壳里，然后提供一些 bridge 的能力让 JS 可以调用到一些原生的能力，比如唤起手机摄像头这类的 Web 不好做的事情。 第二种是跨端开发，也就是好多年前大家经常听到的一码多端，当时移动端有 React Native 、Weex 这一类技术，当时主要是为了解决 Web 性能差的问题，一份代码同时打包出 iOS 和 Android ，这里国内大厂使用跨端技术还有一个非常大的原因就是动态化和热更新，讲的土一点就是可以绕过商店审核直接下发新页面，这也是国内跨端在当时移动互联网高速发展时特别流行的重要原因。 桌面端大家熟悉的就是 Electron ，大家熟知的现在不少 AI 桌面端、VS Code 、Slack 是用这个做的，代价是相当于每个应用都自带一份 Chromium 和 Node.js ，安装包一百多 MB ，内存也占得多。但好处是在 Chromium 渲染引擎的统一下能够很好地保持多端的展示一致性，加上里面写的代码非常好写，后续不少桌面的速成就会用这个技术。 跨端后面也慢慢延伸出更多有趣的解决方案，类似 Flutter 自己实现一套渲染引擎，早期靠 Skia ，现在换成了自研的 Impeller 渲染引擎来保障多端一致和性能效率的均衡，包括桌面端上老牌的 Qt ，和 Flutter 一样自己画界面。 这两年桌面跨端也出现了用 Rust 写的 Tauri 、Go 写的 Wails ，它们和 Electron 不一样的地方就是，没有塞一个 Chromium 进去，而是使用的系统自带的 WebView ，包会小非常多，但是整体还是基于 Web 这一套研发思路和对应实现语言去进行桥接交互，但是由于系统 WebView 每个平台不一样，Windows 上是 WebView2 ，Mac 上是 WKWebView ，Linux 上是 WebKitGTK ，所以多端显示的一致性反而不如 Electron ，还是要写兼容代码。所以这种情况下，即使 Electron 很大内存占用也不低，还是会被选择更多。 第三种是原生开发，也是没有 AI 之前，大家觉得开发难度很大的一种方式，特别是之前的苹果系使用的 Objective-C ，Android 系使用的 Java 、Windows 系 C++、C#，均是我认为需要科班花非常多时间去学习、看书、手编代码，要想做得好，需要花大量时间研究对应的系统底层原理，能够方便你写出相比普通研发性能更好更稳定的代码，在我看来是前期投入大，后期用户很享受的技术。我 17 年那会儿刚工作不久，职业发展比较爽的一个很大原因，是抽了半年时间学习 Objective-C 和 iOS 研发，让本职是前端的工作提前往跨端方向走了，刚好可以解决一些只懂前端或只懂客户端都搞不定的难题，那也是我做一线开发非常快乐有趣的一段时间。 等到后面 Swift + SwiftUI 、Kotlin + Jetpack Compose 、C# + WinUI 3 慢慢出来成熟后，这些原生端语言的写法也慢慢向前端的声明式写法靠齐，也更易写了，声明式代码更短、更好读了。但是在国内，原生完全被 React Native 、Flutter 、Electron 的广泛使用盖过去了，开发者不多，生态发展完全靠官方推动，这也是为什么很多 App 出活很快，但大家普遍觉得用久了卡卡的，而且这类 App 还占了大头。想迁移到原生的话，假如之前架构实现得不好，大概率只能重写，完全不能复用，实现得好，比如你早就把业务逻辑抽出来了，类似 Kotlin Multiplatform 这类方案把业务逻辑共享、界面各写各的原生，算是第四条路，也是最近几年的趋势。 聊到这里大家应该大概明白了，这里也有一个不可能三角，就是研发效率、体验、性能这三者，选择 Web 是多效率少性能，选原生是多性能体验少效率，选跨端就是刚好是这三者取一个中间，做得好容易都占，做得不好，容易没有一边占到好处的尴尬局面。  那么在 AI Coding 写代码已经不是问题的情况下，我们应该选择啥技术呢？很多时候也取决于你的场景，比如你就是一个 Web 场景的浏览、点点按钮、阅读这一类 Web1.0 阶段的东西，那还是非常建议直接 Web 技术来弄；假如你需要调用到系统底层的能力，或者需要操作更顺手更好分发，以及本身就是一个应用的场景，我还是非常建议使用原生技术来实现，这样可以第一时间享受到系统官方本身的众多调优，以及最原生的交互效果、最低的内存占用，加上 AI 让写两份原生代码的成本大幅下降，三角形的效率那一边被补上了，只是两个平台的调试和验证变成了新的成本，这里正是人需要重点做的事情了。 当然假如实在技术选型不那么重要，工作量非常之大，以及业务效果远大于技术体验选择，选择跨端技术也是可以的，这样快，迭代发布也快，可以第一时间让你的用户收到你的最新的特性更新。 Windows 版为啥还是选了 C# 和 WinUI 3 技术栈上，Mac 版本的 Mole 使用的也是原生的 Swift + SwiftUI ，能够让我很好调用系统能力以及非常好的性能体验，想着不将就，所以在 Windows 上我也是想着直接用本身写 Windows 软件最直接的语言，C# 加 WinUI 3 ，跑在 .NET 10 上，过程虽然难搞，但是相比十年前我了解轮子哥谈的 Windows 开发要简单好理解一些了。 Windows 上的原生界面框架其实挺多的，包括很多年前了解过的 Win32 、WinForms 、WPF 、UWP 这一波，WPF 是 2006 年出的，到现在还在维护，但控件和设计语言不是很好看，非常上一代的感觉，然后 UWP 又被沙盒和应用商店给绑定住，现在微软主推的是 Windows App SDK 里的 WinUI 3 ，界面框架从系统里面拆出来单独发版，这样就有一个好处，普通的 Win32 程序也能用，基础组件就是 Windows 11 自己的 Fluent 风格，我还挺喜欢，高分屏缩放和 ARM64 都是原生支持。 然后这里 .NET 10 是去年 11 月发的长期支持版本，打包时我把运行时一起打进去，用户不需要另外装 .NET ，x64 和 ARM64 这里各出了一个原生安装包，骁龙的 Windows 笔记本就不要走转译了，相当于尽量让用户使用简单不折腾。这里安装和更新用的是开源的 Velopack 框架，可以很方便做增量更新，也很好用。 工程师开始写代码时候肯定会想到能复用尽量复用，所以我开始写的时候也非常想复用 Mac 的 Swift 代码，后面让 AI 分析了一下，十几万行 Swift 代码可以脱离 AppKit 、SwiftUI 这些系统框架使用的 20% 都没有，处理的逻辑也是 ~/Library 这类 macOS 自己的路径规则，基本用不上，所以 Windows 版几乎是从零开始写的。 代码各写各的，两边怎么保持一致 Mole Mac 版本：<mole.fit> Mole Windows 版本：<mole.fit> 两边的关系其实非常简单，外观和交互我尽量完全一致，尽可能让大家意识里面认为的 Windows 软件不那么精致美观的感觉在这里也保持我认为好的水平，然后底层代码各写各的，关于视觉的一致性还原有了 AI 以后很简单，我把原本的 Mac 版写在 Swift 里的颜色、字号、间距、圆角这些设计 token ，直接写了一个脚本生成为 Windows 里面 XAML 资源，文案也是从 Mac 的多语言文件转成 Windows 的格式，11 种语言一起转过来，甚至大家看到的菜单栏里面的那个 runner 动画也是用的同一个脚本同步来的。  虽说同步，可能大家会觉得很简单，其实这里需要花点精力防止 AI 直接给你跑偏了，每次同步其实我会记录对应的是 Mac 的哪一个提交，这样两边就不会走偏去，然后功能上会有一份 SYNC.md 当做对账表，Mac 每加一个功能、修一个安全问题，Windows 这边都会标清楚哪些是已经实现、哪些是刻意不同还是不适用，以及为什么这样判断。 通过这两个机制，我可以很好的让两边的底层完全各写各的，但是又能很好地保持功能对齐，完全不需要刻意去硬写一层兼容去磨平，反而会变复杂，这里能复用的反而是设计、文案以及踩坑后定下来的各种规则，反而这些是 AI 非常喜欢的“能力抽象层”，也就是说随着时代发展，慢慢所谓的代码抽象没有那么重要了，反而是规则抽象更重要。 签名比 Mac 麻烦不少 另外 Windows 开发还有一块比 Mac 要麻烦不少，就是证书签名，没有签名的，一打开会出现「 Windows 已保护你的电脑」，甚至 Windows 11 的智能应用控制会直接不让运行，国内不少安全软件也会把没签名的程序当成可疑报毒，这和 Mac 上没签名、没公证的软件提示「已损坏」差不多，平时 Mac 上大家还可以跑一条命令解掉，Windows 上想正规分发，这一步没有啥好办法，就是需要。 调研下来微软的签名生态的确比苹果差太多了，微软有自己的 Azure Artifact Signing ，一个月 9.99 美元最省事，居然个人只开放给美国和加拿大的开发者，没办法使用，很奇葩的规定，然后行业还规定从 2023 年起签名私钥必须放在硬件或者云端 HSM 里，不能再是电脑上的一个文件，今年起单张证书最长只能用 460 天，差不多一年多就得换一次证书。 最后我买的是 Certum 的云端 OV 证书，3 年 3 百多美元，签名时登录电脑上的 SimplySign ，再用手机上的 App 给一个动态码，SmartScreen 的信誉也跟着证书上审核过的名字慢慢积累。刚开始一段时间的签名包在 ThinkPad 上也会一样被 SmartScreen 拦了下来，后来我每次发版都把安装包提交到微软的恶意软件分析门户，让信誉慢慢积累起来，而且 SimplySign 的登录会话闲置几个小时就会断开，需要再次输入动态码才能继续签名，所以这里其实很难做成云端自动打包。 怎么用 Mac 开发 Windows 软件 证书搞定后，就是开发环境的事情了，我的研发要求是代码和 AI 的上下文必须全留在 Mac 上，Mac 用习惯了，真的很难使用 Windows 去研发，这里 Windows 只负责编译和验证效果和各种测试，所以我在 Mac 上装了 Parallels Desktop ，大概 3 百多块一年，之前也听不少小伙伴吐槽过这个软件，不过在我的 M5 Pro 上跑 Windows 11 还挺顺滑，让我感觉这个钱花得很值。 它最好用的一点是我的 Claude 能很顺手地操作它，仓库直接作为 Parallels 的共享文件夹挂进虚拟机，变成一个 X 盘，Mac 上改完代码，虚拟机里直接编译，不需要来回 Copy 文件，只是两边的编译产物要分到不同的目录，对于编译、启动、看日志的工作都被我写成了脚本，通过 Parallels 自带的 prlctl exec 直接在虚拟机里执行，程序启动就崩的时候 Windows 只给一个 0xc000027b ，Mole 会把真正的异常写进日志，脚本跑完顺手打印出来，Claude 直接就能读到。相当于写代码还是在 Mac 上的 Claude Code 里，调试和运行都在虚拟机里，脚本不能解决的地方，直接用 Codex 的 computer use 去点，只有少部分那种系统确定弹框点不了，我在这里就是这个职责，点点系统弹框确定，哈哈。  说到这里，可以和大伙分享一下 Mole Windows 的架构分层，一共四层，最底下的 Core 只依赖 .NET ，不碰任何 Windows 接口，清理规则、路径安全检查、卸载残留的判断都放到这里，测试用的是一个按 Windows 路径规则模拟出来的内存文件系统，这样在 Mac 上也可以很好的跑；往上是 Platform 层，注册表、文件系统、Win32 调用这些真正的系统接口都放在这一层，打开 EnableWindowsTargeting 以后，Mac 上也能编译通过；再往上就是写过应用同学非常熟悉的界面状态的 ViewModel 层，这里和 Mac 版本会一一对应，这样也能够在 Mac 上测，只有最上面这一层的 WinUI 界面必须去 Windows 里编译。  这也是让我一个月时间可以写 8 万多行 Windows 代码、4000 多个测试，但是几乎大部分可以在 Mac 上完成的一个很方便的地方，也是架构设计的巧妙处，当然这里我只提供之前做架构时候的想法建议，大部分是 Opus 5.5 去帮我整的，很牛逼。 接着可以聊测试了，我反而认为在 AI 时代，工程师最大的价值，除了架构设计外就是这个测试验证了，所以为了保证产品是可以售卖的，肯定需要在真实环境测试验证，反复找体验问题去修复的，所以我整了一台 ThinkPad X1 Carbon ，这个机器质感还不错的，我把它当成真机环境，设置永不休眠，可以让我和我的 Agent 24 小时去验证测试回归，包括获取各种真实系统环境的参数验证，400 多款 Windows 软件的卸载、残留清理、注册表、启动项测试，大部分在虚拟机里跑，x64 安装包、真实的高分屏、电池、SmartScreen 这些虚拟机看得不准确的，就直接放到这台机器上验，所以这台机器让我感觉也非常值。 然后为了不想在两台机器拷来拷去，最后还是用了 UU 远程，直接在 ThinkPad 那边开一个远程终端，我这边在 Mac 上直接操作，然后还把 ssh 连接当做备用，大部分软件的安装、卸载和调试，都是通过命令行脚本去完成的，剩下需要看界面的，直接通过远程桌面让 computer use 去操作，非常方便，最终相当于我还是在 Mac 上做的所有的事情。  这个过程下来，到最后成品让几个 Mole 天使用户去试用，大伙用着很爽，感觉这个过程的开发非常值，很有意思，而且可以帮助大家解决不少痛点，加上 Windows 上小白用户应该比 Mac 要多不少，让他们也享受到好软件的体验其实很值得开心。 一个应用里混着用好几种语言 技术栈选好以后，再来聊聊我们在进行客户端应用研发的时候，如何利用各种技术语言的特性来帮助我们产品做得更好。 比如说写 Mac 应用你的主语言是 Swift ，其实你完全可以融入一些其他的语言来帮助你解决这个语言不那么擅长的某些地方的问题，当时 6 年前做[妙言]( miaoyan.app)的时候就是这样，这是一个原生的 Mac Markdown 笔记应用，使用纯 Swift 实现，当时有一个非常难解决的问题卡住我，就是如何用 Swift 来实现一个 Markdown 的格式化能力，很像我们在 VS Code 里面使用 Prettier 的 Markdown 格式化那个能力的效果。 当时想用 Swift 手写实现这个能力，原本的就是用 JS 实现的，非常复杂差不多快要放弃了，洗澡的时候突然想到一个点子，其实在 Swift 里面我完全可以去调用一个 JavaScriptCore 的能力，它是可以执行 JS 的，那我是不是可以把杂乱的 md 当做一个字符串传到这个里面去运行，然后帮我输出非常清晰规范化的 md 字符串，我再解析渲染出来，立马去测试验证，真的可以，效果感觉非常不错，在当时没有 AI 的时代，假如我用 Swift 去实现这个格式化引擎，不知道要多久才搞得出。 再到后面，就更有意思了，当时写 [Pake]( tw93/Pake) 这个桌面打包工具的时候，主要是 Rust 写的，但是 Rust 的生态在当时也非常差，比如我想写一些下载的能力，完成后弹出一个 Toast 的能力，它甚至都没有成型的 Toast 组件，既然我会前端，当时想到的点是，可以通过 Rust 去调用 JS ，让 JS 生成一个 document 容器塞到 Web 里面去，这样在有消息通知的时候，我可以让 Rust 去调 JS ，把这个东西渲染出来，效果也非常好，同时不会影响原有的性能，还能够更美观。  其实很多时候，假如你对各种语言都了解一点，碰到难搞问题的时候可以帮助你很快想到一些 Hack 的办法去解决，甚至你还会融会贯通，反过来调用，比如当时在渲染的 Web 里面，需要去调用下载的能力，这个时候还可以反向去调用 Rust 的成型的系统能力帮我去下载，性能就更高。 这个里面有一个很有意思的技术，讲土一点，你可以把它理解成通信，相当于不同语言之间可以通过一个中间层去交换信息，然后监听各自执行，刚刚上面 Rust 和 JS 相互调用这里就使用了这种技巧，开头说的 PhoneGap 给 JS 开的 bridge 也是这种通信。甚至当你脑洞大开的时候，你甚至可以多个语言相互通信，当时做妙言的分栏编辑功能时候，一边是原生的 Markdown 编辑器，一边是 WebView 渲染的预览效果，Markdown 解析用的是 GitHub 开源的 C 语言库 cmark-gfm ，性能和能力都非常牛逼，但是很底层，它可以在每一块 HTML 上标出对应原文的第几行，然后我用预览里的 JS 读这些标记，算出当前滚到了第几行，再通过消息通道告诉 Swift ，编辑区同步跟着到这个位置，这样就很好实现了两边滚动预览效果是非常同步的。  当时 [Kaku]( kaku.fun) 里面也有用过类似的能力，有一个功能是你直接在终端里面输入 # 加一句自然语言回车，我可以帮你去调用一个快速的 AI 帮你生成一个终端可执行命令，这个效果非常酷。  但是实现起来其实也很难，因为正常时候你直接回车，你的 zsh 就报错了，不会执行这一块，因为它不认识，当时也想了很久，发现我可以用终端的转义序列把这句话发给 Kaku ，里面的 Lua 脚本接到后交给 Rust 这一层去请求模型，生成的命令再用 Lua 回填到命令行，有一种偷梁换柱的感觉，等一小会儿命令就填好了，然后他可以很自然的回车，这条自然语言生成的命令就执行了，相当于一句话在 zsh 、Lua 、Rust 走了一圈，最后回到终端上了。  类似这样的场景还挺多的，这种难题的解决是在前 AI 时代，我认为作为工程师最有意思的地方，你可以完全把各种语言当做一个工具，没有任何偏见的去使用，只基于场景选择最合适它的语言，而非我喜欢这个语言，就用这个语言去实现所有的功能。 也即我们做产品的时候，需要充分去利用各个语言生态的特性，来弥补做客户端时候本身语言的一些短板，同时把原本的高性能、交互不错的优势发挥到最好，这样最终效果就非常互补，很有意思。 抢不到票，做得再顺也没用 不过说到底，技术是给业务服务的，最终还是需要往解决问题方向走，好比抢演唱会门票，大家不会关注你这个客户端怎么这么卡，只会关注我用你能不能抢到票，即使你做得十分顺畅，但是抢不到票也是会被骂得很惨，技术栈的选择在这里选得好只是锦上添花，最终还是需要优先保障用户的最真实需求的解决，然后做好这里，再去想，我如何让用户体验更好，接下来才是考虑我是否需要使用原生技术来实现。 只不过到了现在的 AI 时代，原本很有意思的编码解决难题的场景变少了，直接上来一个 Opus 5.5 全部一把梭就帮你解决了，不过假如你了解这些各种语言的特性，你可以在它跑偏的时候，提醒一下它去试试那个语言的那个特性或者那个库，说不定可以帮助你做产品少走不少弯路。 哈哈，我现在就想着好好珍惜还能够在某些方面指导 AI 干活，说不定再过半年，这个活也不需要工程师干了，AI 可以完全帮你做了，那会更有趣还是更无趣呢？ 我这种 AI 乐观派会认为编码这个事情应该就没意思了，不过还会有更多有趣未知的新东西值得我们去探索，那会更有意思些！ 欢迎交流，有在做 Windows 开发的小伙伴也可以一起聊聊你们的最佳实践。
YAMLResume v0.17 update: new kami HTML template, with accent color support for all engines and slimmed docker image. Hey guys, Been a while for YAMLResume's last update. Recently we've released v0.17, which brings some new things that may be useful for some people here. 1. Accent color Support All theme engines (docx, html and latex) now support accent colors in YAMLResume, for now it support 9 builtin enum values and any random valid hex color like #RRGGBB The code looks like this: layouts: - engine: latex theme: colors: accent: burgundy Here is some examples with accent color customized: yamlresume latex jake's template with burgundy color yamlresume latex jake's template with cerulean color 2. New HTML Kami template We've added a new kami html template which is inspired by tw93/kami project. Here is how it looks like in a Safari browser: yamlresume html kami template The code is very simple, just change `layouts.[].template` to `kami` like this: layouts: - engine: html template: kami As mentioned earlier, our html template also support accent color, here is kami template with green color: yamlresume html kami template with green accent color 3. 80% slimmed docker image size The original yamlresume's Docker image that ships the full yamlresume build pipeline—Node.js, the CLI, XeTeX, and all fonts—went from about 4GB on disk (1.77GB download) to 866MB on disk (321MB download), by replacing the full TeX Live installation with a curated TinyTeX install and pruning everything XeLaTeX never reads. |Image|Download|On disk| |:-|:-|:-| |v0.16.x (before)|1.77 GB|~4 GB| |v0.17.0 (after)|321 MB|866 MB| Hopefully somebody in r/selfhosted would like these. Thank you! - Blog: yamlresume.dev - Kami template: yamlresume.dev - Accent color support: yamlresume.dev
Mole CLI just passed 72.8K stars, and October is its busiest month yet: 18 releases across Mac and Windows. The Windows CLI now matches the Mac one, any AI agent can drive it with the official skill, and mo slim strips Intel code from universal apps. tw93/Mole t.co
Mole GitHub Overview: macOS Cleanup, Uninstall, Disk Analysis, and Monitoring mole by tw93: tw93/mole Mole is an open-source command-line toolkit for macOS system maintenance. This overview covers its Homebrew prerequisite, protection configuration, and preview-first cleanup workflow, including whitelist rules, dry runs, file-identity deduplication, Docker and Time Machine boundaries, and history logs. It also introduces the `mo uninstall`, `mo analyze`, and `mo status` modules for application cleanup, disk-space exploration, and live hardware and network visibility. The repository documents Windows PowerShell and NixOS-related paths as well. TimeStamps: 0:00 What Mole Combines in One Terminal Toolkit 0:19 macOS Requirements and the Protection Model 0:53 Homebrew Installation and Version Verification 1:19 Whitelist Rules and Closed Protection Boundaries 2:07 Dry Runs, Deduplication, and Detailed Logs 2:52 Docker Volumes and Time Machine Space Trade-Offs 3:32 Application Uninstall and Personal Data Choices 4:50 Disk Analysis and the macOS Trash Recovery Path 5:26 Live Hardware and VPN Network Monitoring 5:46 Maintenance History and the Repository’s Platform Paths 6:12 Audit Logs, Windows, NixOS, and Agent Integrations 🧹 Cleanup previews, whitelist boundaries, and file-identity deduplication 🗑️ Application removal, personal-data choices, and a recovery path 📊 Disk analysis, hardware status, and audit history Mole brings cleanup, application removal, disk analysis, and status monitoring into one terminal surface, with visible boundaries around what each module handles. It suits macOS users who want command-line maintenance with previews, configurable protection rules, and an audit trail; check the repository for platform-specific details and current command syntax. #Mole #macOS #SystemMaintenance [de-DE] YNAS ynp_7f5dbabbae4e8889 Cinematic Privater automatisierter Staging-Upload. Paketidentität: ynp_7f5dbabbae4e8889; Ausgabe: cinematic. [es-US] YNAS ynp_7f5dbabbae4e8889 cinemático Carga de entorno de prueba de automatización privada. Identidad del paquete: ynp_7f5dbabbae4e8889; salida: cinematográfica. [fr-FR] YNAS ynp_7f5dbabbae4e8889 cinématique Téléchargement de l'environnement de test d'automatisation privé. Identifiant du package : ynp_7f5dbabbae4e8889 ; sortie : cinématique. [hi] YNAS ynp_7f5dbabbae4e8889 सिनेमैटिक निजी स्वचालन स्टेजिंग अपलोड। पैकेज पहचान: ynp_7f5dbabbae4e8889; आउटपुट: सिनेमाई। [id] YNAS ynp_7f5dbabbae4e8889 sinematik Unggahan staging otomatisasi pribadi. Identitas paket: ynp_7f5dbabbae4e8889; output: sinematik. [it] YNAS ynp_7f5dbabbae4e8889 cinematografico Caricamento di automazione privata. Identità del pacchetto: ynp_7f5dbabbae4e8889; output: cinematico. [pt-BR] YNAS ynp_7f5dbabbae4e8889 cinematográfico Upload de teste de automação privada. Identificação do pacote: ynp_7f5dbabbae4e8889; saída: cinemática.
On macOS, Mole can clear out your .venv and venv dirs, in case you have old certifi. tw93/mole $ brew install mole $ mo purge ... Estimated space freed: 13.33GB | Items: 399 It also cleans out things like .tox .ruff_cache node_modules #Python #Mole #venv #certifi #eMudhra #macOS
Mac cleaning, finally simple. Mole bundles deep cleaning, smart uninstalls and live system monitoring into one CLI. Run ‘mo clean’ to wipe caches and leftovers, or ‘mo analyze’ for an interactive TUI view of disk hogs. 🍒 Built by Tw93 tw93/Mole #opensource #macos