{"title":"How to Build a Slow Product in the Fast AI Era","date":"2026-10-26","language":"en-US","summary":"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.","categories":["Thought"],"url":"https://tw93.fun/en/2026-10-26/mole-product.html","markdownUrl":"https://tw93.fun/en/2026-10-26/mole-product.md","translation":{"language":"zh-CN","title":"在快 AI 时代，如何做一款慢产品？","url":"https://tw93.fun/2026-10-26/mole-product.html","markdownUrl":"https://tw93.fun/2026-10-26/mole-product.md"},"contentMarkdown":"![How to Build a Slow Product in the Fast AI Era article cover](https://cdn.tw93.fun/blog/pic/mole-product-cover-honest-en.png)\n\nIt has been a little over two months since I wrote the previous post, [From Mole CLI to Mole for Mac: What I Learned](https://tw93.fun/en/2026-08-16/mole-mac.html). 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.\n\nLooking 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.\n\nProgrammers 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.\n\n## From 100 apps to 850: software engineering has no real standard\n\nI 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.\n\nAt 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.\n\n![The real desktop during testing, with open apps, permission prompts and work windows piled on top of each other](https://cdn.tw93.fun/blog/pic/mole-product-testing-mac-apps-desktop.webp)\n\nThe 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.\n\n\n\nIt 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.\n\nThat 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.\n\nI 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](https://mole.fit/tested-apps).\n\n![The AI tools part of the tested app list](https://cdn.tw93.fun/blog/pic/mole-product-testing-mac-apps-800.webp)\n\n## You only know an AI tool once you have used it\n\nBefore 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.\n\nBut 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.\n\nUnlike 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.\n\nFor 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.\n\nThis 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.\n\nThen 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.\n\nThe 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.\n\nSomething 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.\n\nI 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.\n\nAll 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.\n\n![Mole's AI Cleanup & Care page, listed in three sections: caches and old versions, sessions and workspaces, idle tools](https://cdn.tw93.fun/blog/pic/mole-product-en-ai.webp)\n\n## System Data is the hardest part to test\n\nA 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](https://support.apple.com/102624) 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.\n\nThe 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.\n\nTake 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.\n\nAnother 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.\n\nAs 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.\n\n![Mole's Clean page during development, with System Data at the top and Other Storage read-only](https://cdn.tw93.fun/blog/pic/mole-product-mole-system-data-review.webp)\n\n## Resending 400 emails, plus a small piece of magic\n\nOver 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.\n\nInterestingly, 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.\n\nOne 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.\n\nQuite 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.\n\nIn 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.\n\nSo 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.\n\n\n\nTaken 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.\n\nLately 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.\n\nEven 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.\n\nPaul Graham wrote in [Do Things that Don't Scale](https://paulgraham.com/ds.html) 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.\n\n## A new set of icons, another round of copy\n\nThe 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.\n\n![35 pairs of icons, each with the old system icon on the left and the new icon on the right](https://cdn.tw93.fun/blog/pic/mole-product-mole-icons-before-after.webp)\n\nI 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.\n\nThen 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.\n\nSo 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.\n\n![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](https://cdn.tw93.fun/blog/pic/mole-product-mole-icons-iterations.webp)\n\nThe 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.\n\nI 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.\n\n## Accessibility helped a lot\n\nTesting 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.\n\nAccessibility 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.\n\n## One Mac, plus one ThinkPad\n\nThe 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.\n\n![The Apps page of Mole for Windows, listing installed apps and their sizes](https://cdn.tw93.fun/blog/pic/mole-product-windows-uninstall.webp)\n\nNow 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.\n\n![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](https://cdn.tw93.fun/blog/pic/mole-product-workspace.webp)\n\nHow 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](https://mole.fit/windows/blog/building-mole-for-windows-on-a-mac) on Mole's blog, and the trade-offs in choosing the stack are in [You Don't Know Client Development](https://tw93.fun/en/2026-10-22/desktop.html). Have a look if you are doing the same.\n\n## Polishing that looks like wasted effort\n\nAI 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.\n\nInstalling 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.\n\nThe 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.\n\nThe 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.\n\nNext 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](https://github.com/tw93/Mole/discussions/1604) 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.\n\nThe CLI remains open source and free on [GitHub](https://github.com/tw93/Mole), and the desktop versions for Mac and Windows are at [mole.fit](https://mole.fit). Feel free to come and complain anytime."} {"title":"You Don't Know Client Development: Stack, Native, and Leverage in the AI Era","date":"2026-10-22","language":"en-US","summary":"Quite a few folks have been curious how I build Windows software on a Mac, and what stack Windows apps are usually built with these days. As it happens, I have been doing similar work recently, so here are some casual thoughts on choosing technology across multiple clients.","categories":["Share"],"url":"https://tw93.fun/en/2026-10-22/desktop.html","markdownUrl":"https://tw93.fun/en/2026-10-22/desktop.md","translation":{"language":"zh-CN","title":"你不知道的客户端开发：AI 时代下的选型、原生与借力","url":"https://tw93.fun/2026-10-22/desktop.html","markdownUrl":"https://tw93.fun/2026-10-22/desktop.md"},"contentMarkdown":"![You Don't Know Client Development: Stack, Native, and Leverage in the AI Era article cover](https://cdn.tw93.fun/blog/pic/client-tech-cover-native6-en.png)\n\nQuite a few folks have been curious how I build Windows software on a Mac, and what stack Windows apps are usually built with these days. As it happens, I have been doing similar work recently, so here are some casual thoughts on choosing technology across multiple clients.\n\n## Web, Cross-Platform or Native\n\nAnyone who has done front-end or client work probably knows that over the years, client development has mostly taken one of three roads.\n\nThe first and simplest is to just write Web code and drop it into a browser. Early PhoneGap and Cordova were exactly that: stuff a web page into a native shell, then provide some bridge capabilities so JS can call into native features, like opening the phone camera, the kind of thing the Web is bad at.\n\nThe second is cross-platform development, the \"one codebase, many clients\" idea everyone heard about years ago. On mobile there were React Native, Weex and the like, mainly to fix the Web's poor performance, building iOS and Android from one codebase. In China, a big reason large companies heavily used cross-platform tech was dynamic delivery and hot updates; put plainly, you could skip App Store review and push new pages directly, which is a big reason cross-platform was so popular during the rapid rise of the mobile internet.\n\nOn the desktop, the one everyone knows is Electron. Plenty of AI desktop apps, VS Code and Slack are built on it. The cost is that every app ships its own copy of Chromium and Node.js, so the installer is over a hundred MB and it uses a lot of memory. The upside is that with everything rendered by the same Chromium engine, the display stays consistent across platforms, and the code is very easy to write, so a lot of quickly-built desktop apps since then use it.\n\nCross-platform later grew into more interesting approaches. Flutter implements its own rendering engine, Skia at first and now its own Impeller, to balance cross-platform consistency with performance, and the veteran desktop framework Qt likewise draws its own UI.\n\nIn the last couple of years there's also Tauri, written in Rust, and Wails, written in Go. What sets them apart from Electron is that they don't bundle a Chromium; they use the WebView that comes with the system, so packages are much smaller. But overall they still follow the Web way of building things and bridge into the corresponding implementation language. And because the system WebView differs on each platform, WebView2 on Windows, WKWebView on the Mac, WebKitGTK on Linux, cross-platform consistency is actually worse than Electron and you still write compatibility code. That's why Electron, even though it's big and memory-hungry, still gets picked more often.\n\nThe third is native development, which before AI everyone saw as the hardest road. Objective-C on Apple platforms, Java on Android, and C++ and C# on Windows all take a lot of time to study, read books, and write code by hand, digging deep into how the underlying system works to write code with better performance and stability. It's a technology with a big upfront investment that users really enjoy later. Back in 2017, not long after I started working, a big reason my career went well was that I spent half a year learning Objective-C and iOS development, which moved my front-end job toward cross-platform early, and that let me solve some hard problems that people who only knew front-end or only knew client couldn't. That was a really fun period of doing hands-on development.\n\nLater, as Swift + SwiftUI, Kotlin + Jetpack Compose and C# + WinUI 3 matured, native languages gradually moved toward the declarative style of the front end, and got easier to write; declarative code is shorter and easier to read. But in China, native has been completely overshadowed by the widespread use of React Native, Flutter and Electron. There aren't many developers, and the ecosystem moves forward only because the platform owners push it. That's why many apps ship features fast but generally feel laggy after a while, and apps like that are the majority. If you want to migrate to native and the original architecture wasn't done well, you'll most likely have to rewrite with nothing reused. If it was done well, say you pulled the business logic out long ago, something like Kotlin Multiplatform lets you share the business logic while each platform writes its own native UI. That's sort of a fourth road, and the trend of the last few years.\n\nBy now you probably get the idea: there's an impossible triangle here, dev speed, experience and performance. Web gives you more speed and less performance, native gives you more performance and experience but less speed, and cross-platform sits right in the middle. Done well, it gets a bit of everything; done badly, you end up in the awkward spot where no side really benefits.\n\n![The impossible triangle of dev speed, experience and performance: Web sits near speed, native near experience and performance, cross-platform in the middle](https://cdn.tw93.fun/blog/pic/client-tech-triangle-en.svg)\n\nSo now that writing code with AI is no longer a major bottleneck, how should we choose? A lot of the time it comes down to the scenario. If it's a content-heavy app for browsing and reading, going with Web tech is the most hassle-free choice. But if you need to deeply tap into low-level system capabilities, or want lower memory use and smoother interactions, I still recommend native tech, since you get all of the platform's own tuning right away. With AI, the cost of writing two native codebases has dropped significantly, which fills in the speed side of the triangle quite a bit. Debugging and experience verification have become the real places where people need to spend their focus.\n\nOf course, if the tech choice really doesn't matter much, the workload is huge, and business results matter far more than the technical experience, cross-platform is fine too: it's fast, iteration and releases are quick, and you can push new features to users as fast as possible.\n\n## Why Windows Still Got C# and WinUI 3\n\nOn the stack side, the Mac version of Mole is also native, Swift + SwiftUI, which lets me call system capabilities easily and gives a very good performance experience. I didn't want to settle, so on Windows I also went straight for the most direct language for writing Windows software, C# with WinUI 3, running on .NET 10. The process was rough, but compared with the Windows development vczh (known as 轮子哥 in China) used to talk about ten years ago when I first read about it, it's simpler and easier to understand.\n\nWindows actually has quite a few native UI frameworks, including Win32, WinForms, WPF and UWP that I'd looked at years ago. WPF came out in 2006 and is still maintained, but its controls and design language aren't very nice and feel very last-generation, while UWP is tied to the sandbox and the Store. What Microsoft pushes now is WinUI 3 in the Windows App SDK. The UI framework was split out of the OS and ships on its own, which has the benefit that regular Win32 programs can use it too. The base components are Windows 11's own Fluent style, which I quite like, and HiDPI scaling and ARM64 are supported natively.\n\n.NET 10 is the long-term support release that came out last November. When packaging I bundle the runtime in, so users don't need to install .NET separately, and there's a native installer for both x64 and ARM64, so Snapdragon Windows laptops don't go through emulation. Basically I try to keep things simple and hassle-free for users. Install and update use the open source Velopack framework, which makes delta updates easy and works really well.\n\nWhen engineers start writing code, they naturally want to reuse as much as possible, so at first I really wanted to reuse the Mac's Swift code. Later I had AI analyze it: of the more than 100,000 lines of Swift, less than 20% could be used without system frameworks like AppKit and SwiftUI, and the logic also deals with macOS's own path rules like `~/Library`, so basically none of it was usable. The Windows version was written almost from scratch.\n\n## Separate Code, Kept in Step\n\nThe relationship between the two is actually very simple. I keep the look and interactions as identical as I can, so that the impression many people have of Windows software not being refined or nice-looking doesn't hold here, and it stays at what I consider a good level. The underlying code is written separately for each. With AI, keeping the visuals consistent is easy: I wrote a script that turns the design tokens in the Mac app's Swift code, colors, font sizes, spacing, corner radii, into XAML resources for Windows. The copy is also converted from the Mac's localization files into the Windows format, all 11 languages at once, and even the runner animation you see in the menu bar is synced over by the same script.\n\n![On the left, the Clean page of Mole for Mac; on the right, the Windows version. Colors, font sizes, spacing and copy are generated from the same design tokens and localization files](https://cdn.tw93.fun/blog/pic/client-tech-mole-mac-windows-clean-en.webp)\n\nSyncing might sound simple, but it actually takes some effort to keep AI from drifting off course. Every sync records which Mac commit it corresponds to, so the two sides don't drift apart. For features there's a SYNC.md that works as a reconciliation table: every time the Mac adds a feature or fixes a security issue, the Windows side marks clearly whether it's implemented, intentionally different or not applicable, and why.\n\nWith these two mechanisms, the two sides' underlying code can be completely separate while features stay aligned, with no need to force a compatibility layer to smooth things over, which would only make things more complex. What actually gets reused is the design, the copy and all the rules settled after hitting problems, and those are exactly the \"capability abstraction layer\" AI likes most. In other words, as times change, so-called code abstraction matters less and less, and rule abstraction matters more.\n\n## Signing Is a Lot More Trouble Than on the Mac\n\nThere's another part of Windows development that's a lot more trouble than on the Mac: code signing. Without a signature, opening the app shows \"Windows protected your PC\", Windows 11's Smart App Control may refuse to run it at all, and many security apps in China will flag unsigned programs as suspicious. It's similar to the \"damaged\" warning for unsigned, unnotarized software on the Mac, where people can at least run a command to get past it. On Windows, if you want to distribute properly, there's no good way around this step; you just need it.\n\nAfter researching it, Microsoft's signing ecosystem really is far behind Apple's. Microsoft has its own Azure Artifact Signing, $9.99 a month and the least hassle, yet for individuals it's only open to developers in the US and Canada, so I couldn't use it. A very strange rule. On top of that, the industry has required since 2023 that signing private keys live in a hardware or cloud HSM rather than as a file on your computer, and from this year a single certificate can last at most 460 days, so you have to replace it every year or so.\n\nIn the end I bought a Certum cloud OV certificate, a bit over $300 for three years. To sign, I log in to SimplySign on the computer and then get a one-time code from the phone app, and SmartScreen reputation builds up slowly around the verified name on the certificate. For a while at the start, the signed packages were still blocked by SmartScreen on the ThinkPad, so with every release I submitted the installer to Microsoft's malware analysis portal to let the reputation build. Also, a SimplySign login session disconnects after a few hours idle and needs a new code before you can sign again, so it's really hard to turn this into automated cloud packaging.\n\n## Building Windows Software on a Mac\n\nWith the certificate sorted out, next is the dev environment. My requirement is that the code and the AI's context all stay on the Mac. I'm so used to the Mac that it's really hard to develop on Windows, so Windows only handles building, checking how things look, and all kinds of tests. So I installed Parallels Desktop on the Mac, a bit over 300 RMB a year. I've heard plenty of folks complain about it, but on my M5 Pro, Windows 11 runs quite smoothly, and I feel the money is well spent.\n\nThe best thing about it is that my Claude can drive it very easily. The repository is mounted straight into the VM as a Parallels shared folder and becomes an X drive. After changing code on the Mac, it builds right in the VM without copying files back and forth; the two sides' build outputs just need to go into different directories. Building, launching and reading logs are all scripts I wrote, run directly inside the VM through Parallels' own prlctl exec. When the program crashes on startup, Windows only gives you a 0xc000027b, so Mole writes the real exception to a log, the script prints it at the end, and Claude reads it directly. So writing code still happens in Claude Code on the Mac, while debugging and running happen in the VM. Where scripts can't help, Codex's computer use clicks through it directly, and only a few system confirmation dialogs can't be clicked. That's my job here: clicking OK on system dialogs, haha.\n\n![The code and Claude Code are on the Mac, most building and testing runs in the Parallels VM, and what the VM can't measure accurately is checked on the ThinkPad](https://cdn.tw93.fun/blog/pic/client-tech-devloop-en.svg)\n\nWhile we're here, let me share how Mole for Windows is layered. There are four layers. The bottom one, Core, depends only on .NET and touches no Windows APIs; cleanup rules, path safety checks and uninstall leftover decisions all live here, and tests use an in-memory file system that simulates Windows path rules, so they run fine on the Mac too. Above that is Platform, where the real system interfaces live: the registry, the file system and Win32 calls; with EnableWindowsTargeting turned on, it compiles on the Mac as well. Above that is the ViewModel layer for UI state, very familiar to anyone who has written apps; it maps one-to-one to the Mac version, so it can be tested on the Mac too. Only the WinUI interface at the very top has to be built on Windows.\n\n![The four layers of Mole for Windows: the lower the layer, the less it touches Windows, and the more code can be checked on the Mac](https://cdn.tw93.fun/blog/pic/client-tech-layers-en.svg)\n\nThis is what let me write over 80,000 lines of Windows code and more than 4,000 tests in one month, with almost all of it done on the Mac, which is really convenient and is the clever part of the architecture. Of course I only provided my ideas and suggestions when designing the architecture; most of it was put together by Opus 5.5, which is seriously impressive.\n\nNext, testing. I actually think that in the AI era, an engineer's biggest value, besides architecture design, is testing and verification. To make sure the product is good enough to sell, you definitely need to test in a real environment and keep finding and fixing experience issues. So I got a ThinkPad X1 Carbon, a machine that feels pretty well made, and use it as my real-hardware environment. It's set to never sleep, so my agents and I can verify, test and run regressions 24 hours a day, including reading all kinds of real system parameters and testing uninstalls, leftover cleanup, registry and startup items for more than 400 Windows apps. Most of that runs in the VM; things the VM can't measure accurately, like the x64 installer, a real HiDPI screen, the battery and SmartScreen, get checked directly on this machine. So this machine also feels very worth it to me.\n\nThen, since I didn't want to copy things back and forth between two machines, I ended up using UU Remote: open a remote terminal on the ThinkPad and operate it directly from the Mac, with an ssh connection as a backup. Most installing, uninstalling and debugging is done through command-line scripts, and for the rest that needs eyes on the UI, computer use operates it over remote desktop, which is really convenient. In the end, I'm still doing everything on the Mac.\n\n![My desk: the Mac in the middle, the ThinkPad X1 on the left](https://cdn.tw93.fun/blog/pic/mole-product-workspace.webp)\n\nAfter all this, I had a few angel users try the finished product, and their feedback confirmed it solved real pain points for them, which made the whole effort feel worthwhile. Getting Windows users onto a smooth, clean app too makes me really happy.\n\n## Mixing Several Languages in One App\n\nWith the stack chosen, let's talk about how, when building client apps, we can use the strengths of different languages to make our products better.\n\nSay you're writing a Mac app and your main language is Swift. You can absolutely bring in other languages to solve the problems Swift isn't so good at. That's what I did six years ago with [MiaoYan](https://miaoyan.app), a native Mac Markdown note app written in pure Swift. At the time I was stuck on a very hard problem: how to implement Markdown formatting in Swift, much like Prettier's Markdown formatting in VS Code.\n\nI wanted to write it by hand in Swift, but the original is written in JS and very complex, and I was close to giving up. Then in the shower I had an idea: from Swift I can call JavaScriptCore, which can run JS. So could I pass the messy md in as a string, run it there, have it output clean, normalized md, and then parse and render that? I tested it right away, and it really worked, and the result felt great. Back then, with no AI, if I'd implemented that formatting engine in Swift, who knows how long it would have taken.\n\nLater it got even more interesting. When I wrote [Pake](https://github.com/tw93/Pake), the desktop packaging tool, it was mainly written in Rust, but Rust's ecosystem was also very thin then. For example, I wanted to add downloads and pop up a toast when they finished, and there wasn't even a ready-made toast component. Since I know front-end, my idea was to have Rust call JS and let JS create a document container inside the web page. That way, when there's a notification, Rust calls JS to render it. It worked really well, without hurting performance, and it looked nicer too.\n\n![WeRead, a Chinese reading site, packaged into a desktop app with Pake](https://cdn.tw93.fun/blog/pic/client-tech-pake-weread.webp)\n\nA lot of the time, if you know a bit about many languages, when you hit a tough problem it helps you quickly think of a hacky way to solve it, and you'll even start connecting things and calling the other way around. For instance, the rendered web page needed to download files, and here it could call back into Rust's mature system capabilities to do the download, with better performance.\n\nThere's a really interesting technique in here. Put plainly, you can think of it as messaging: different languages exchange information through a middle layer and each listens and runs on its own side. The Rust and JS calls above use exactly this trick, and the bridge PhoneGap opened up for JS, mentioned at the start, is the same kind of messaging. And when you let your imagination run, you can even have several languages talk to each other. When I built MiaoYan's split editing, one side was a native Markdown editor and the other a preview rendered in a WebView. Markdown parsing used cmark-gfm, GitHub's open source C library, which is seriously impressive in both performance and capability but very low-level. It can mark each block of HTML with the line of the source it came from. Then JS in the preview reads those marks, works out which line you've scrolled to, and tells Swift through a message channel, and the editor follows to the same position. That makes scrolling between the two sides stay really in sync.\n\n![MiaoYan's split editing: the native editor on the left, the WebView preview on the right](https://cdn.tw93.fun/blog/pic/client-tech-miaoyan-split-en.webp)\n\n[Kaku](https://kaku.fun) also uses something similar. There's a feature where you type # plus a sentence of natural language right in the terminal and press Enter, and I call a fast AI to generate an executable terminal command for you. This effect is really cool.\n\n![In Kaku, ## plus a sentence offers a few commands to choose from, while # fills in one directly](https://cdn.tw93.fun/blog/pic/client-tech-kaku-commands.webp)\n\nBut it's actually hard to implement, because normally when you press Enter, zsh just throws an error and won't run it, since it doesn't understand it. I thought about it for a long time and found I could use a terminal escape sequence to send the sentence to Kaku. The Lua script inside catches it and hands it to the Rust layer to request the model, and the generated command is filled back into the command line by Lua. It feels a bit like a sleight of hand: after a short wait the command is filled in, then you can just naturally press Enter and the command generated from natural language runs. In effect, one sentence takes a lap through zsh, Lua and Rust and ends up back in the terminal.\n\n![MiaoYan's synced scrolling passes through C, JS and Swift; Kaku's sentence takes a lap through zsh, Lua and Rust](https://cdn.tw93.fun/blog/pic/client-tech-relay-en.svg)\n\nThere are quite a few scenarios like this. Solving problems like these was, before AI, what I thought was the most fun part of being an engineer. You can treat every language purely as a tool, use them without any bias, and pick the language that fits each scenario best, rather than liking one language and using it to build every feature.\n\nIn other words, when we build products, we should make full use of the strengths of each language's ecosystem to make up for the weak spots of the main language on the client, while getting the most out of its strengths in performance and interaction. That way the end result complements itself really well, which is a lot of fun.\n\n## Smooth Is No Use If You Can't Get the Ticket\n\nIn the end, technology serves the business. Take grabbing concert tickets: nobody cares how your client was written or how smooth it is, they only care whether they got a ticket; if they can't, you'll still get roasted. Picking a great stack is just icing on the cake; first you have to solve the user's most real need.\n\nIn the AI era, the cross-language hurdles we used to struggle through have shrunk; often you throw Opus 5.5 at it and it solves everything in one go. But if you know the strengths of these different languages, when it goes off track you can nudge it to try that feature or that library of some language, and it might save you a lot of detours in building the product.\n\nHaha, right now I just want to make the most of still being able to guide AI in some areas. Maybe in another six months engineers won't be needed for this either and AI will do it all for you. Will that be more interesting or more boring?\n\nAn AI optimist like me thinks coding itself will probably stop being interesting, but there will be more fun, unknown new things worth exploring, and that will be even more interesting!\n\nFeel free to reach out, and if you are doing Windows or cross-platform development, I'd love to hear your thoughts and practices."} {"title":"From Mole CLI to Mole for Mac: What I Learned","date":"2026-08-16","language":"en-US","summary":"Lately I've piled up a lot of thoughts on indie development and wanted to pull them together, so this is the story of taking Mole from an open source CLI to a paid Mac app. What I was thinking at the time, and which parts actually turned out to matter.","categories":["Share"],"url":"https://tw93.fun/en/2026-08-16/mole-mac.html","markdownUrl":"https://tw93.fun/en/2026-08-16/mole-mac.md","translation":{"language":"zh-CN","title":"Mole 出 Mac 版后，用户教会了我做产品","url":"https://tw93.fun/2026-08-16/mole-mac.html","markdownUrl":"https://tw93.fun/2026-08-16/mole-mac.md"},"contentMarkdown":"![What I Learned Shipping Mole for Mac article cover](https://cdn.tw93.fun/blog/pic/mole-mac-cover-calm-en.png)\n\nLately I've piled up a lot of thoughts on indie development and wanted to pull them together, so this is the story of taking Mole from an open source CLI to a paid Mac app. What I was thinking at the time, and which parts actually turned out to matter.\n\n> Mole lives at [mole.fit](https://mole.fit), and the CLI is open source on [GitHub](https://github.com/tw93/Mole). Feel free to play with it first.\n\nLast National Day holiday I sat by a pool in Sanya and wrote a few hundred lines of code. It became Mole CLI, a command line cleaner for the Mac, and I put it on GitHub mostly for myself and a few coworkers. Less than a year later it has 60K stars, 50-odd releases, code from 121 developers around the world, and nearly 800 feature requests and bugs closed.\n\nI honestly had no sense of how many people were using it. Then one month two images I'd hosted on Vercel from the README blew past the bandwidth allowance and left me owing them 80 dollars. That was when it clicked that a desktop version was worth building.\n\nThe most common email I got came from users outside China, and they all said roughly the same thing. My parents use a Mac. So does my sister. Neither of them will open a terminal. Could you make a version they can just click? I sat on it for a long time, mostly because the CLI itself didn't feel finished. I only started on the desktop version after the CLI had run for most of a year and I knew what was safe to delete and how far to go, and I didn't ship it until I was using it every day myself. It shipped at ten at night. Notifications kept coming in through the small hours, payments from France, Germany and elsewhere, and I turned the email alerts off so I could sleep. I kept adding to it over the months that followed. A group of people paid first and then stayed around while I finished it. Nothing changed on the CLI side, it stays open source, free and updated, and the desktop app is the only paid part.\n\n\n\n## Three Kinds of Junk AI Leaves Behind\n\nAfter the desktop version shipped, the feature I ended up using most was the cleaner, because my own Mac kept warning me it was running out of space. I have Claude Code and Codex running most of the day, and I noticed that the files AI leaves behind differ from what I used to find.\n\nIt's mostly three things. The most obvious is build output. You used to hand-write a few hundred lines a day and compile three or five times. Now you let an agent run a dozen rounds in an afternoon and every round compiles. Rust `target` directories, `.next` and `dist` on the front end, Xcode's DerivedData, they all grow fast. I once cleared 86GB in one go and it was entirely this. Second is old copies of the AI tools themselves. Claude Code and Cursor Agent self-update silently by downloading the whole new version, around 250MB each, and leave the old ones behind. After a few months there are a dozen versions sitting there. Then there are local model files pulled through Ollama or LM Studio, easily eating up tens of gigabytes.\n\n![Mole Clean completion screen showing 86.4 GB of storage reclaimed](https://mole.fit/img/en/clean.webp)\n\nCollapsing all of these into a single \"safe to delete\" list is certainly easier, but the cost is making high-risk decisions on the user's behalf. Now I handle this data based on what it costs to get it back. When a candidate is scanned, its ownership is determined before deciding whether it gets checked by default.\n\nFor build output, most logs, and HTTP and GPU caches, deleting them means recompiling or refreshing a page, and the price is a few minutes of CPU. As long as the owning app has quit, they can be checked by default. But `node_modules`, `Pods` and `venv` are different. They look like similar dependency directories, but deleting them means downloading them all over again, and on a plane or a train you're just stuck waiting. The two are easy to lump together. Mole CLI did exactly that early on, and later I pulled every download-only directory out of the Mac app's clean list. The user needs to look at those first.\n\n![Mole sorts cleanup candidates into regenerable, costly to rebuild and irreplaceable data](https://mole.fit/img/blog/cleaner-data-kinds.webp)\n\nModels are the heaviest thing in here, and redownloading tens of gigabytes takes a long time. A general purpose cleaner couldn't delete them correctly even if it wanted to. Ollama splits a model into hash-named blocks and several models can share the same block. Delete a large-looking block straight off the filesystem and you may well break a different model. Only the tool itself knows those relationships.\n\nSo `~/.ollama/models` and `~/.cache/huggingface` are hardcoded into a protected list. They never appear during a scan, they only show up in the disk analyzer as a size, and the models themselves stay under Ollama's and LM Studio's own management.\n\n![Diagram showing Models A and B sharing some SHA256 data blocks in Ollama](https://mole.fit/img/blog/ai-model-store.webp)\n\nThere's one thing even more off-limits than models, and that's AI chat history. `~/.codex/sessions`, `~/.claude/projects` and `~/.grok/sessions` hold months of full conversations, sometimes a year. Your thinking at the time, the approaches you rejected, the reason behind every change. Delete it and it's gone, and in a way it's worth more than the code. Those paths can never be cleaned in Mole, no matter how long they've sat untouched, and the same protection covers memories, plans, skills and generated images.\n\n![Mole disk analyzer treemap showing storage used by Library, projects and pictures](https://mole.fit/img/en/analyze.webp)\n\nNone of that protected list was designed up front. It was mostly learned the hard way. The dumbest one was `com.apple.e5rt.e5bundlecache`. The name says Caches, it lives in the cache directory, everything about it reads as a cache, and it's actually where Apple's Neural Engine keeps compiled models. The CLI cleared it as a cache early on, and every app using recognition features broke for those users until they rebooted. Since then I run three questions in my head whenever I see a directory with cache in the name. Who writes it? Who reads it after a reboot? If I get this wrong, how do I get it back? If I can't answer one of them, I leave it alone.\n\n## Show It Before You Delete It\n\nWhat I care about most in a tool like this isn't how much it can clear. It's whether it lets you see things first.\n\nMole scans, then lists every item with what it is, where it lives and how big it is. Anything uncertain is unchecked by default. You confirm, then it deletes, and it prefers the Trash so you can change your mind. Scanning and cleaning happen entirely on your machine, and no file or result leaves it. The cost is that it's slower, there's an extra step, and it feels fussy on the days you just want it done. I'd still rather it miss something than delete something it shouldn't.\n\n![Mole Uninstall expanding Claude to show its app, support files, logs and caches](https://mole.fit/img/en/uninstall.webp)\n\nUninstall follows the same logic. Pick an app and Mole pulls up everything it has scattered around the system, each item labelled with its path and size. In the screenshot above Claude itself is 781MB while `~/Library/Application Support/claude` is 7.67GB, which is usually the case: the app bundle is never the part taking up space. Login items and background services live on the same page, so you don't have to hunt through System Settings for them.\n\nTake macOS update payloads, the `/macOS Install Data` directory. It's often more than ten gigabytes and it looks like a perfect thing to clear. But the system may still need it to finish installing, and removing it too early can leave the machine unable to boot. So it's a review-only item in Mole, unchecked by default, behind three gates. If there's a pending system update the row is hidden. If anything in the payload was written in the last 14 days it's hidden. If an installer process is still running it's hidden. If any of those signals can't be read, it's treated as risky and doesn't show at all.\n\nAt the moment of deletion the root helper runs all of those checks again and exits nonzero if any of them fails, so you don't end up with a report claiming it freed 12GB when it didn't touch a byte.\n\nI have a crude way of judging any cleaner. Install two products from the same vendor, uninstall only one of them, and see whether the tool offers up the Application Support parent directory or the group container that both of them share. If it does, it's matching on names rather than reasoning about ownership. I'm not comfortable letting a tool batch-delete anything if it can't tell me who owns what.\n\n![Mole attributes containers, support files, caches and system extensions to an app while avoiding shared containers](https://mole.fit/img/blog/leftover-attribution.webp)\n\n## It Doesn't Come Looking for You\n\nIt looks everywhere it should, it just doesn't come looking for you.\n\nIt won't pop up every few days to remind you it's time to clean, and it won't finish a scan and announce how much danger your computer is in. Open it when you want to clean something. The rest of the time it may as well not be installed.\n\nThe interface follows the same idea. The result page doesn't appear until the scan is done, a short wait shows no spinner at all and only a longer one brings up a working animation, and the completion screen reserves its space in advance so the window doesn't jump when the result lands. Each of these rules is small, and together they're why the app feels steady.\n\nThe work underneath is unpredictable by nature, and animation doesn't fix that. What fixes it is the flow itself being reliable. I don't want a maintenance tool that needs watching. I want to start a task, let it finish, then come back to the results without a blinking light constantly asking for my attention.\n\nThe same goes for accessibility. Reading order, keyboard operation, whether focus stays put, none of that is separate from how quiet the thing looks. With Reduce Motion turned on the planets stop their decorative spin and state changes move around less, and nothing you do depends on understanding an animation.\n\n![Mole's menu bar panel stays out of the way until opened, then shows hardware status and maintenance shortcuts](https://mole.fit/img/en/menubar.webp)\n\n## Building for Someone in Their Seventies\n\nI used to build things thinking only about whether the people around me found them handy. Going from a CLI to a desktop app taught me that getting it usable for someone in their seventies takes a lot more, and it's a lot more interesting. Everything below came out of three months of user email, and it's where most of what I learned came from.\n\nA British user in his late sixties wrote to say he'd had a senior moment and bought Mole twice. \"Consider the second payment a gift. Thank you for this excellent tool, it has saved me far more pounds than CleanMyMac ever did.\" I suggested a refund, or giving the extra licence to someone. He asked around and wrote back the next day: \"None of my neighbours use a Mac, and neither do my Bluesky followers. This round is on me.\" Getting a letter like that makes you feel you have to make the thing better to deserve it.\n\nAn American user corrected something I'd had backwards about regional habits. I'd assumed Americans wanted Fahrenheit, so that's what the US default was. He wrote: \"Americans use Celsius in every technical context. Only weather and body temperature are Fahrenheit. I installed Mole, saw 110, and got a fright. Apple publishes US specs in Celsius, and fastfetch and neofetch both default to Celsius on American systems. Keep the Fahrenheit toggle, but default everyone to Celsius.\" It now defaults to Celsius with Fahrenheit available. He followed up about pricing too. The number I'd picked didn't read like a deliberate price, he said, more like something converted from another currency. Then he added: \"When I say foreign I don't mean anti-China. People want to feel the author understands them.\" Honestly, that price was something I made up on the spot. I'd never thought seriously about pricing before selling anything, and having a stranger point it out was a bit embarrassing. It hadn't occurred to me that the price number itself shapes how people decide.\n\nA user with mild vision impairment wrote: \"Looks like a very nice app. Shame I can't use it, it seems to hardcode dark mode. My system is set to light and I only use light mode apps.\" Mole being dark-only was a deliberate call. The menu bar panel floats over the wallpaper like a HUD, dark glass glares less, and it saved adding a theme switch. But that reasoning doesn't hold for him. I'd been telling myself I took accessibility seriously here, and it never occurred to me that light mode is itself an accessibility need. That email arrived a while ago. Mole is still dark-only and light mode is still sitting on the list. A product that claims to care about accessibility has left someone who told me plainly that he can't use it waiting this long, and that one bothers me.\n\nA lecturer at a German university wrote asking about an educational licence, describing it as \"not only support for me personally, but a meaningful kind of support at the educational level.\" I had no idea teachers were using this in a classroom setting. A doctor in Hungary left the most honest bad review I've had: \"To be blunt, this is a little expensive for something a free app can also do.\" That one doesn't sting at all. Purchasing power varies enormously between countries, and he wasn't complaining, he was helping me locate a problem.\n\nMy favourite features in Mole didn't originate with me. The low battery alert for AirPods came out of the battery health work, and I never hit the case myself until one afternoon it actually fired, which felt thoughtful without being noisy. Keep Screen On grew three different behaviours after a user pointed out what was missing. Now if I head out on a weekend the AI coding session keeps running, which has saved me a lot of waiting. Seeing the iPhone's battery level in the status view was hard to implement for a while, and eventually there was a way. Users told me to build all of these, and I'm the one who got the most out of them.\n\n## I Still Answer Every Email Myself\n\nSupport questions, refunds and licence resets add up to well under 1% of users. Half an hour of scripting would automate all of it, and I haven't written that script. Handling them one at a time is the only way to feel what people actually want, why they refunded, and where the thing made them uncomfortable. That's usually not what they asked in the first sentence. My bar for automating is three things holding at once: the question keeps coming up, the answer is stable, and I understand the exceptions. Until then I'd rather answer each one myself. It still works, I've spent nothing on marketing, growth is mostly word of mouth, and refunds are under 0.8%. A good number of buyers were long-time CLI users first.\n\nI also didn't build a ticketing system, a support platform or a knowledge base before launch. Engineers like standing up the support machinery first because it's familiar work, and AI compressing it into half a day makes it even easier to start too early. Building it takes half a day, maintaining it is long-term work, and nobody needs it yet. The day the inbox starts dropping requests, or response times get murky, or the same question gets two different answers, that's when a new system is actually needed. AI shrinks the building time to a few days, but talking to people isn't something you can hand off, or making a product stops being interesting. Handling every email yourself is how the trust builds up.\n\n## A Few Things That Actually Helped\n\nWriting code is actually a small part of it. The real time goes into figuring out where the pain actually is, how to make it usable without a manual, and how to get it in front of the right people. Doing every step yourself feels very different from just writing code.\n\nFor a cleaner, what you don't delete matters far more than what you do, which is where those protected lists came from. A lot of feature ideas are perfectly good, but if they don't fit what Mole is for, I keep them out. Otherwise it turns into a pile and becomes a nightmare to maintain.\n\nYou need a rough roadmap in your head so you know which requests to turn down. If a piece of software needs no manual for people to pick it up, it passes. I've declined plenty of nice suggestions the moment they threatened to make the app louder or more complex. If one Mac user in a hundred finds it useful, that's enough.\n\nA feature has to pass three gates before it reaches the roadmap now. No always-on timers, listeners or sampling cost while the user isn't in that feature. No expanding the privileged helper or adding a system permission for a small convenience. No new setting when a sensible default exists. That isn't a universal principle for all software, it's a rule Mole set for itself. Every extra bit of always-on work, privilege and configuration is one more thing users have to trust you with.\n\n![Many feature ideas pass through three filtering gates, and only a few continue toward a quiet, stable product](/images/blog/mole-product-gates.svg)\n\nI've never saved up for a big release. I aim to ship something every week, which keeps user problems moving and keeps the back and forth going. Every release, update and announcement is a good excuse to talk to people, and it gives anyone who missed the earlier ones a way to find out what you're doing.\n\nNow that AI writes code, the time it saves is exactly what you should spend figuring out what people need. Things like talking a problem through, looking properly at the data, or writing copy that makes sense on the first read. I don't mind spending tokens, as long as they make a difference users can feel.\n\nMole has been global since day one, and I publish more in English than in Chinese. What struck me is how large the world is and how far users are spread, and that they're willing to trust you from the start. People you helped in passing often become your users later, because there was something real between you. I've never paid for promotion either. Posts on X get a burst of attention that fades quickly, whereas things posted to YouTube keep getting views for much longer, and if the thing is good and someone recommends it, it stays alive there for a long time.\n\nI spent a fair amount of time looking at the data. Putting sales, traffic, comments, refund reasons and GitHub issues side by side surfaces plenty of blind spots I wouldn't have seen, and shows exactly where people walk away.\n\nThe last one is mindset. Chasing follower counts just to sell things makes you anxious. Posting the real process, the mistakes and the updates shows people you're actually building something, and trust follows naturally. With so much over-promised noise around right now, nobody pays attention if they don't trust you. Staying honest and playing the long game gets you much further.\n\n## Why Five Planets\n\nMole for Mac is five parts: Clean, Apps, Optimize, Analyze and Status. Each one has a planet in the interface. Clean is Earth, Apps is Mars, Optimize is Mercury, Analyze is Jupiter, Status is the Sun. It comes from liking planetary motion as a kid, and from WebGL being the first thing I badly wanted to learn after picking up front end work ten years ago. The two happened to meet. I swapped the planet textures more than ten times and pulled a lot of them from NASA before settling. The spin direction, the rotation speed and the flight at the end all follow how the real bodies behave.\n\n\n\nNone of this had to exist. A menu bar item with a clean button would have worked. But there's more than enough AI-generated cyber junk already, and rather than spend tokens stacking up another interface that merely runs, I'd rather make something pleasant. It doesn't waste my tokens and it doesn't pollute your timeline.\n\nI like things arriving in their own time, and I try not to rush the schedule. That's only been reinforced these past three months. Building something I enjoy using and others are willing to pay for is already a great place to be.\n\nThe CLI is free and open source on [GitHub](https://github.com/tw93/Mole), and the Mac app is at [mole.fit](https://mole.fit).\n\nThis is my first time selling something, so there are definitely things I missed, and I welcome any advice. Looking back, the changes that shaped this most all came from someone's email or an issue. Listening to people complain has honestly been the biggest help."} {"title":"You Don't Know Embodied AI: From a Tiny Robot Dog to Optimus","date":"2026-06-07","language":"en-US","summary":"In April I assembled a small robot dog. I posted a few clips on X while I was building it, so some of you probably saw the parts, the frame, and the final moment when it could hear a command, walk a couple of steps, and say a few lines back.","categories":["Share"],"url":"https://tw93.fun/en/2026-06-07/robot.html","markdownUrl":"https://tw93.fun/en/2026-06-07/robot.md","translation":{"language":"zh-CN","title":"你不知道的具身智能：从小机器狗到 Optimus","url":"https://tw93.fun/2026-06-07/robot.html","markdownUrl":"https://tw93.fun/2026-06-07/robot.md"},"contentMarkdown":"![Embodied intelligence across perception, space, action, and torque](/images/2026/robot/00-perception-space-action-torque.png)\n\n## Short Version\n\nIn April I assembled a small robot dog. I posted a few clips on X while I was building it, so some of you probably saw the parts, the frame, and the final moment when it could hear a command, walk a couple of steps, and say a few lines back.\n\nThe idea started around Chinese New Year. I had been using Opus 4.6 to write code every day, and in many places it was faster and cleaner than I was. That gave me a bit of FOMO. I wanted to try something that crossed the software and hardware boundary, where there were still a few entry barriers beyond typing prompts and shipping code.\n\nOnce I decided to build something, the question quickly became practical: how do I read sensors, drive servos, handle communication failures, power the board, mount the parts, and deal with physical faults? Those questions were more concrete than \"build a robot.\" I bought an STM32, ASRPRO, ESP32-C3, MG90S servos, an OLED display, a DHT11 sensor, a lithium battery, and a set of 3D-printed parts. The goal was a small dog that could hear speech, lie down, walk, and connect to a cloud model for conversation.\n\nThe small details took the most time. One of the four MG90S servos was always a little unstable. I plugged the OLED in while powered and burned it out, then waited several more days for replacement parts. Only after the DeepSeek conversation, temperature and humidity reading, and motion control all worked on the real device did I start to feel what \"AI entering the physical world\" meant.\n\nFrom a software point of view, embodied AI is easy to describe as a large model with a body attached. Once wires are plugged in, motors start moving, and the frame starts shaking, the feeling changes. A natural-language command has to pass through structured intent, action sequences, PWM, torque, current, and contact. Each layer has its own budget for time, energy, and error. A pile of problems appears that pure software usually never has to care about.\n\nAfter I published my article on large models, a few friends joked that I should write one on embodied AI next. This little robot dog turned out to be a useful entry point. It is a simple toy-level system, but the concepts I wanted to understand, perception, space, action, and torque, all show up on it in small form.\n\nThe first half of this piece is about building that robot dog. The second half is my study notes from public papers, official blogs, open-source projects, and third-party technical write-ups. I hope it gives people outside the robotics field one more engineer's angle on embodied AI.\n\n---\n\n## First, Make the Robot Dog Run\n\nThe robot dog ended up as a low-cost heterogeneous system. The whole thing cost a little over RMB 200. It can hear a wake word, enter a dialogue, send the user's command to a cloud LLM for semantic parsing, and convert the returned structured action into servo control commands that the STM32 can run.\n\n| Module | Model or spec | Price range | What it does |\n|--------|---------------|-------------|--------------|\n| Main controller | STM32F103C8T6 | CNY 5 to 10 | Servo control, sensor reading, basic motion logic |\n| Offline speech | ASRPRO | CNY 15 to 25 | Wake word and local keyword recognition |\n| Network module | ESP32-C3-MINI | CNY 10 to 15 | Wi-Fi, provisioning, cloud AI dialogue |\n| Backup Wi-Fi | ESP-01S | CNY 8 to 12 | Backup communication channel |\n| Servos | MG90S metal gear x 4 | CNY 40 to 60 | Angle control for the four legs |\n| Sensor | DHT11 | CNY 5 to 10 | Temperature and humidity |\n| Display | 0.96-inch OLED | CNY 10 to 15 | Status display |\n| Power | 3.7V 1000mAh lithium battery | CNY 15 to 20 | Power supply |\n| Body | 3D-printed PLA | CNY 20 to 30 | Body and four legs |\n\nBreaking it into a data flow made debugging much easier. Many of the problems turned out to involve hardware: false wake-ups, network timeouts, servo angles, unstable power. The hardware-side issues can almost be written as a troubleshooting table.\n\n| Step | Input | Output | Common problems |\n|------|-------|--------|-----------------|\n| Wake | Ambient audio | Wake event | False wake-ups, missed wake-ups, noise |\n| Network | Wake event and user speech | Cloud request | Wi-Fi provisioning, disconnection, timeout |\n| Intent parsing | Text or audio | Structured action | Parameter range, action name, context |\n| Local communication | Structured action | UART frame | Checksum, packet loss, retry |\n| Motion execution | UART frame | PWM output | Jitter, power, servo drift |\n| Status return | Sensor data and execution result | Text or speech reply | Read delay, failure-state wording |\n\nAt first I wondered whether I should replace the small chips with one stronger chip and let it handle everything. Wiring the system changed that idea. Wake-up, networking, PWM, sensor reading, and cloud requests have different latency and stability requirements.\n\n![Heterogeneous chip split: what the three chips do](/images/2026/editorial/robot-system-en.webp)\n\nThe ESP32-C3 handles Wi-Fi and cloud AI. It joins a 2.4 GHz network, forwards speech or text to the cloud model, and sends the result back to the STM32. It is a better fit for networking than the STM32, but if it also had to manage PWM, multiple UART links, network requests, and dialogue state, scheduling would quickly get heavy.\n\nASRPRO handles offline wake-up. It listens to the environment at low power, recognizes the wake word locally, and only then wakes the network path. That saves power and puts less privacy pressure on the system than uploading audio all the time.\n\nThe STM32F103 is a 72 MHz ARM Cortex-M3 with 64 KB of flash and 20 KB of SRAM. Running a model on it is unrealistic, but it is a good fit for hard real-time control. The four MG90S servos use 50 Hz PWM for angle control. A 0.5 to 2.5 ms pulse maps to 0 to 180 degrees. Hardware timers can output microsecond-level PWM steadily, so the walking motion is less likely to drift because of task scheduling.\n\nThe parts and tools all arrived on the Friday before the Qingming holiday. I started that night and spent the next few days on it. A pile of parts slowly became a wired-up little robot dog that could walk several steps and understand simple commands. It was a fun build.\n\n\n \n \n \n \n \n
\n \"Soldering\n \n \"Internal\n \n \"Assembled\n
\n\n\n\nI also used an MCP-like idea here, although in this small robot dog the implementation is much simpler. The model and the device share a list of capabilities. The device reports what it can do, and the model calls only what appears on that list.\n\nThe most useful part for me was separating local abilities from cloud abilities. The device controls local hardware such as the speaker, LED, servos, and GPIO. The cloud can extend to smart-home control, PC actions, knowledge search, email, and other higher-level tools. Once that line is drawn, the system boundary becomes easier to reason about.\n\nA complete run looks like this. The ESP32-C3 first reports its capabilities, such as `servo_control`, `sensor_read`, and `gpio_write`. I say \"Mambo, sit down.\" The cloud model generates a structured call with the target servo, target angle, and speed parameters. The ESP32-C3 translates that into a UART command for the STM32. The STM32 then adjusts PWM step by step and reports execution status.\n\n![MCP interaction sequence: from device discovery to result confirmation](/images/2026/editorial/robot-mcp-en.webp)\n\nThis small system can already understand \"sit down,\" \"stand up,\" and \"what is the temperature now.\" It has no spatial awareness. It does not know where it is, where the chair is, or whether taking two steps left will hit something. Once command intake, motor driving, and status return are working, spatial perception and action generation become much easier to think about.\n\n---\n\n## How Does a Robot Know Where It Is?\n\nMy robot dog cannot understand \"move two steps left around the chair.\" It does not know how far the chair is. It does not know where it stands in the room or which way it is facing. It does not have a 3D map that updates over time. It lacks depth perception, pose estimation, and spatial mapping.\n\nAdding spatial ability is not as simple as attaching another module. Once a depth camera, IMU, and a board capable of SLAM enter the system, the cost, power draw, and software stack all change. The STM32-based system cannot absorb that whole layer by itself.\n\nFour new chains appear. Camera calibration has to handle intrinsics, distortion, exposure, and synchronization. Pose estimation has to resolve the transforms between the camera, IMU, and body frame. Map updating has to decide when an old map becomes invalid or needs correction. Motion planning has to remember that a reachable point on the map does not guarantee that the foot can land there stably.\n\nA tabletop demo can avoid many of these problems. A room cannot. Reflective floors, table legs, cables, steps, and lighting changes all enter the system.\n\nImage models are good at answering a 2D question: what is in this image? A robot has to keep going. How far away is the object? What is occluding it? Which direction gives a more stable grasp? After moving one step, how will the viewpoint and support points change?\n\nIn a 2D image, a cup is a few hundred pixels. In a robot's world, a cup is an object with volume, weight, friction, occlusion, and contact surfaces. These are the 3D representations I kept seeing in robotics, each with a different engineering cost.\n\n| Representation | Problem it solves | Engineering cost |\n|----------------|-------------------|------------------|\n| Occupancy or voxel | Which spaces are occupied and where the robot can move | Needs multi-view input or depth estimation, with a trade-off between resolution and compute |\n| Point cloud | Native 3D geometry from sensors | Sparse and unordered, with high cost for semantic processing |\n| NeRF or 3D Gaussian Splatting | High-fidelity scene reconstruction and new-view synthesis | Training, updating, and dynamic objects are still hard |\n| 3D scene graph | Spatial memory of rooms, objects, and relationships | Depends on stable perception and semantic binding |\n\n![Four 3D representations used by robots](/images/2026/robot/08-3d-representations.png)\n\nThese representations often work together. Low-level obstacle avoidance may use occupancy or a local cost map. Grasping may use point clouds and end-effector poses. Long-running tasks may use a scene graph. Training-data augmentation may use NeRF or 3DGS. The hard part is putting them on the same timeline and in the same coordinate system. Once a 3D scene stops updating, it quickly becomes an old photo.\n\nSLAM and point clouds are good at geometry. They can provide pose and obstacles, but the semantics are weak. The system knows there is a cluster of points ahead. It may not know whether it is a chair or a cardboard box. NeRF and 3D Gaussian Splatting are strong at reconstruction and new-view generation. For robots, the useful question is whether they can bring simulation, data augmentation, and world models closer to real scenes.\n\nA 3D scene graph is closer to long-term memory. It turns rooms, tables, cups, and drawers into nodes. It turns \"the cup is on the table,\" \"the drawer belongs to the cabinet,\" and \"the keys were last seen near the entryway\" into relationships. If a home robot needs to answer \"where did I put the wrench last time,\" storing only video frames will not be enough.\n\nSpatial memory also has to preserve uncertainty. If the robot saw a cup once, it should not permanently believe the cup is still in that spot. Object names, last observation time, confidence, and visibility all have to be stored together.\n\n![Three generations of 3D perception: from point clouds to neural fields to 3D-VLMs](/images/2026/robot/09-3d-perception-timeline.png)\n\nVLA is also moving from 2D toward 3D. Early systems such as RT-2 and OpenVLA mainly connected 2D images, language, and action. That is enough for many tabletop grasping tasks. Once the instruction becomes \"take out the blocked blue block,\" pixels are not enough. The robot has to know what blocks the blue object, whether it should move the blocker first, and whether moving it will make something else fall.\n\nWork such as 3D-VLA and SpatialVLA tries to combine 3D scenes, SE(3) poses, which describe position and orientation together, and action generation. Figure's Helix series can work from monocular visual input, but it still has to learn depth, affordance, and object relationships internally. The input can be 2D. The internal representation still has to enter 3D.\n\n![3D-VLA architecture: embedding a 3D world model inside VLA](https://gw.alipayobjects.com/zos/k/m0/5.png)\n\nMonocular cameras on humanoid robots are also a trade-off. A monocular system can estimate depth from multiple views, motion parallax, and neural networks, but it needs enough data and stable movement. Active depth or LiDAR buys certainty with hardware. Tesla, Figure, Boston Dynamics, and Unitree choose different sensor setups because they trade off visual data, compute, real-time behavior, and safety redundancy in different ways.\n\nThis is the boundary of my small robot dog. It can turn language into action, but it doesn't know where that motion will take it. It has no pose, no map, and no occlusion handling. It still can't work out how to follow a command like \"take two steps left.\"\n\n---\n\n## From Hard-Coded Motions to VLA\n\nMy robot dog still runs fixed motions. When I say \"sit down,\" it loads a preset group of servo angles. It is not generating a new action from vision and language. I only added intent recognition in front of a small motion library.\n\nIn embodied AI, VLA, or Vision-Language-Action, is the direction worth studying closely. It feeds vision, language, and robot state into the same model and asks the model to output actions directly. This reduces many hand-written interfaces between visual detection, language understanding, planning, and control. Fewer interfaces also make debugging harder.\n\n| Route | Representative work | How action is represented | What happens on a real robot |\n|-------|---------------------|---------------------------|------------------------------|\n| Discrete tokens | RT-1, RT-2, OpenVLA | Continuous actions are discretized into tokens | Easy to connect to language models, but precision and sequence length are limited |\n| Action chunks | ACT | Predict the next k steps at once | Reduces accumulated error in high-frequency control |\n| Diffusion generation | Diffusion Policy, RDT-1B | Generate action trajectories from noise | Fits multimodal actions, such as going left or right around an obstacle |\n| Flow matching | pi0, pi0.5, SmolVLA | Generate a continuous action distribution | Faster sampling, better fit for low-latency control |\n| High and low-frequency systems | Helix, Gemini Robotics | High-level reasoning decomposes tasks, low-level VLA executes actions | Closer to a brain and cerebellum split |\n\n\"Output action\" can mean different things. Some models output joint angles. Some output end-effector movement for the hand or gripper. Some output gripper opening and closing. Joint angles are close to the hardware but hard to transfer across robots. End-effector poses are more general, but they need inverse kinematics.\n\n![Evolution of VLA action representations: from discrete tokens to continuous generation](/images/2026/editorial/robot-vla-en.webp)\n\nThe directions follow a rough timeline. RT-1 came first. It trained a Transformer on 130,000 demonstrations and more than 700 tasks, treating robot control as sequence learning. RT-2 then mixed in internet-scale image-text data, so the model could bring web knowledge into robot control. The cost is clear: compressing continuous joints, poses, and gripper states into tokens loses precision, and more actions make the token string longer.\n\nACT is more direct. It predicts a small block of actions at once. With ALOHA, two low-cost teleoperation arms can plug in a USB cable, zip a zipper, and fry an egg. It is still many people's first stop for imitation learning. Diffusion Policy addresses a different problem. When there are several valid ways to avoid an obstacle, ordinary regression can learn an averaged motion that goes straight into it. Diffusion starts from noise and generates actions step by step, which can preserve multiple valid paths.\n\npi0 uses flow matching. You can think of it as a close relative of diffusion with much faster sampling. pi0.5 pushes generalization into open environments by mixing high-level subtasks, spoken instructions, and web data into training. Physical Intelligence reported that more training environments improved stability in new homes, and that around 100 environments could match training directly in the target environment.\n\nSmolVLA pushes from the other side. It lowers the entry barrier to consumer hardware. It has 450M parameters, uses community data, and can run with fewer than 30,000 episodes. It may not be the strongest model, but it moves VLA out of big-company clusters.\n\nCommunity data has a practical requirement. Diversity has to cover lighting, camera angles, rooms, and demonstration quality. It is like test data in software engineering: clean data from one lab may be less useful than noisy data that covers more situations.\n\nAfter 2025, the high and low-level split became clearer. Google DeepMind's Gemini Robotics is one example. ER 1.5 handles understanding and task decomposition. 1.5 turns each step into action. Google also released an On-Device version for local low-latency use, which can adapt to new tasks with 50 to 100 demonstrations.\n\nThis split often looks good in a demo. In a real product it exposes problems. \"Organize the desk according to local recycling rules.\" The high-level model has to check the rules, split the task, and explain intent. The low-level model has to identify each object and place it in the right container. If the two layers become one black box, a failure is hard to locate.\n\nFigure's Helix also uses a layered system. In early Helix, S2 was a low-frequency VLM and S1 was a 200 Hz action policy. Helix 02 added an S0 full-body control layer at 1 kHz, putting balance, contact, and coordination into an even faster layer. My robot dog is a toy version of the same idea. A slow model can do understanding, but balance, contact, and coordination need a faster layer.\n\n![Figure Helix dual-system architecture: S2 7B brain plus S1 80M cerebellum](/images/2026/editorial/robot-helix-en.webp)\n\nBeyond speech, a robot brain also has to choose an action representation. If actions are too coarse, the robot cannot grasp accurately. If actions are too slow, control becomes unstable. Once actions become discontinuous, real motors and contact amplify the error.\n\n---\n\n## Time, Energy, and Data\n\nWhen I split a robot control system, I usually think in three parts: brain, cerebellum, and body. In engineering terms, this is a problem of different control frequencies.\n\n| Layer | What it handles | Typical time scale | Common techniques |\n|-------|-----------------|--------------------|-------------------|\n| Brain | Visual understanding, language interaction, task decomposition | 100 ms to 1 s | VLM, VLA, LLM, GPU or NPU |\n| Cerebellum | Trajectory generation, balance, motion coordination | 1 ms to 50 ms | MPC, RL, IK, real-time CPU |\n| Body | Motor current, encoder feedback, emergency stop | Microseconds to 10 ms | MCU, FPGA, EtherCAT, CAN-FD |\n\n![Three control layers: response times of the brain, cerebellum, and body](/images/2026/editorial/robot-control-en.webp)\n\nThe small robot dog has the same split in a simplified form. DeepSeek dialogue is the brain. The gait sequence inside the STM32 is the cerebellum. PWM and servos are the body. Since it does not do dynamic balance, a 1 to 2 second cloud response is acceptable. On a humanoid robot, a 1 second balance delay is enough to make it fall.\n\nThe brain can be slow. When a robot hears \"put the cup in the sink,\" it can split that into finding the cup, walking over, grasping it, and releasing it. This semantic work does not need 1 kHz. The cerebellum does. A standing and walking human is roughly an inverted pendulum. The control loop often has to run at 200 Hz to 1000 Hz. If it is too slow, a small disturbance can become a fall.\n\nThe body layer is even more real-time. Motor control reads encoders, estimates speed, limits current, and stops immediately when something is wrong. Many systems put this layer on a dedicated MCU or FPGA to avoid the scheduling uncertainty of Linux.\n\nLatency looks different depending on where it happens. If the brain is slow, the robot feels sluggish. If the cerebellum is slow, balance suffers and a small touch may knock it down. If the body layer is slow, motors jitter and heat up.\n\nA pitfall that is easy to underestimate is coordinate frames and timing. The brain and cerebellum may use different coordinate frames. Sensors also run at different speeds: IMUs at hundreds of hertz, cameras at tens of hertz, encoders at thousands of hertz. Calibration and timestamps have to align them to the same time and coordinate system. Once calibration drifts, the state seen by the model no longer matches the real world. The algorithm looks as if it suddenly became worse. Many robot debugging sessions go back to sensors, extrinsics, zero points, and timestamps.\n\n![Time synchronization and coordinate calibration for six sensor streams](/images/2026/editorial/robot-sensors-en.webp)\n\nAfter time comes energy. Robots cannot avoid actuators and batteries. A humanoid robot has dozens of motors. Motors, gearboxes, lead screws, encoders, and drivers are often the most expensive and hardest-to-scale parts of the BOM.\n\nDexterous hands are especially difficult. Motors, tendons, tactile sensing, wiring, and heat all have to fit into a palm-sized space. That is why many companies keep refining hands. A human uses about 2000 kcal a day, around 2.3 kWh, and can move for a long time. Robots do not have the same passive support from bones and ligaments. Even standing still costs energy because the motors have to hold posture.\n\nThe third piece is training data. It is much harder to collect than ordinary large-model data. Text can be crawled. Images can be labeled. Self-driving cars can collect from vehicles on the road. Robot manipulation needs real hardware, a site, people watching, and a defined safety boundary. Once all of that is ready, collection cost is already an order of magnitude higher. The data roughly comes from these places.\n\n| Data source | Strength | Weakness |\n|-------------|----------|----------|\n| Human teleoperation | High-quality actions and clear task semantics | One person usually teaches one robot at a time |\n| Autonomous robot runs | Closest to the deployment distribution | Failures have hardware and safety costs |\n| Simulation data | Parallel, reproducible, cheap | Friction, deformation, contact, and visual texture differ from reality |\n| Human video | Large scale and real objects | Lacks robot action labels and proprioceptive state |\n| Synthetic data | Easy to cover long-tail scenes | Still has to prove that it improves the real robot policy |\n\nSimulation tries to avoid the pain of collection, but the real machine is different. Lighting, friction, tolerance, wear, sensor noise, and motor heat are clean in simulation and messy on hardware. A steadier approach is to train the policy in simulation until it stops making low-level mistakes, then calibrate with a small amount of real data, feed failed samples back, and train again. A pure simulation path tends to underestimate contact and sensor error. Simulation data alone is far from enough.\n\nWhich layer can be slow? Which layer must be real-time? Which tasks can use a GPU? Which ones must stay on the MCU? Compared with pure software, there are many more layers to hold in your head.\n\n---\n\n## Tesla Optimus as an Engineering Sample\n\nI like Tesla and bought the stock early, so I am not neutral when I look at Optimus. I still want to write about it because it puts FSD transfer, vision-only sensing, end-to-end training, in-house actuators, factory trials, and large-scale manufacturing into one machine. Once you study it piece by piece, several questions become more concrete: how long does a dexterous hand take to move from demo to reliability, how failed samples add contact data, and how manufacturing turns actuators, wiring, sensors, and batteries into a maintainable product.\n\nThe numbers in the table come from Tesla AI Day, earnings calls, and third-party technical summaries. They are public statements and targets, not proof of shipped capability. I still remember how many robotics companies studied the AI Day slides and videos frame by frame. That alone says a lot.\n\n| Item | Early public statement | Gen 3 related statement | Why it matters |\n|------|------------------------|-------------------------|----------------|\n| Body DoF | AI Day 2022 disclosed 28 base DoF, excluding the hands | Still centered around 28+ body DoF | Body motion is already complex. Much of the visible change is in hands and forearms |\n| Hand DoF | 11 DoF and 6 actuators per hand | Next-generation hand and forearm were publicly described as 22 DoF. Third-party summaries mention 25 actuators per hand | More dexterous manipulation, plus harder wiring, heat, lifetime, and calibration |\n| Compute platform | A trunk-mounted computer similar to the vehicle FSD computer | AI5 has been described publicly as supporting larger on-device models and inference | Long-term cloud dependence is limiting. Edge energy efficiency constrains the product early |\n| Cost target | AI Day 2022 mentioned a long-term idea below USD 20,000 | Earnings calls continued to discuss a USD 20,000-level target at scale | This depends on actuators, magnets, wiring, and assembly yield. The model is only one part |\n| Deployment stage | First tested inside Tesla factories | Multiple earnings calls mention internal use, design iteration, and later production-line targets | The factory works like a training and validation field. External sales timing still needs caution |\n\nThe hand upgrade may look small, but in robotics it is a large change. Factory tasks such as tightening screws, plugging connectors, moving parts, and attaching labels, and home tasks such as picking up cups, opening doors, and folding clothes, cannot be solved by arm motion alone. Fingers need enough contact points. They also need to know whether an object is slipping, fragile, and where the contact surface is.\n\n![Optimus Gen 3 hand: 22 DoF, 25 actuators](/images/2026/robot/15-optimus-hand-forearm.png)\n\n## A Finger Without a Pin\n\nOn April 16, 2026, a third-party teardown discussed a set of WIPO publications for Tesla's hand and forearm. A patent is not a production design, but WO 2026/080693, \"Joint Assembly for Robotic Appendage,\" shows an interesting structural trade-off. I saw the report on X at the time and remembered it clearly.\n\nThe teardown described a design that avoids a traditional pin hinge. A flat composite element sits between two phalanges. It has elastic layers on the top and bottom, with a very thin reinforcement layer in the middle. The material candidates include Vectran and Nitinol. Vectran is a liquid-crystal polymer fiber. Nitinol is a nickel-titanium superelastic alloy. Both can help create directional stiffness.\n\n![FIG. 1: full finger cross-section, with four phalanges 20A/B/C/D connected by three joint assemblies 100A/B/C](/images/2026/robot/16-optimus-wipo-patents.png)\n\nThe design tries to control bending direction. The finger should be soft when it bends, but stiff in extension, compression, shear, torsion, and side swing. A traditional pin hinge limits extra degrees of freedom with geometry. This approach uses anisotropic stiffness. It has three possible engineering benefits. The phalanges can form something close to rolling contact, with the rotation axis moving as the angle changes, which is closer to a real finger. The elastomer provides its own return force, so a separate return spring may not be needed. The tendon can pass through the neutral plane, reducing fatigue from repeated bending.\n\nThis looks like mechanical design, but it touches a whole chain of dexterous-hand problems. A joint structure affects finger return, tendon routing, wrist layout, forearm space, assembly tolerance, and repair. Whether it can stay consistent after thousands of grasps per day cannot be read from a demo. It has to be tested in real work.\n\n## How Optimus AI May Be Built\n\nTesla keeps emphasizing that Optimus and FSD share roots. AI Day 2022 said the computer inside the robot torso came from the vehicle FSD computer, and that the software stack reused object detection, occupancy networks, indoor navigation, and motion planning from the car. Some third-party summaries describe Optimus as an end-to-end system with 8 camera inputs and 78 actuator outputs.\n\nTesla is more likely building a unified learned system than a single end-to-end neural network. Full FSD construction involves 48 networks. The engineering implementation is probably a multi-task, multi-head architecture with shared representations.\n\n| Layer | Capability often seen in public material | What it gives the robot |\n|-------|------------------------------------------|--------------------------|\n| Visual input | 8 automotive-grade cameras, vision-only route | Lower sensor cost, with depth and redundancy handled by data and models |\n| 3D representation | Occupancy Network, depth estimation, 3D reconstruction | Turn 2D views into traversable space, obstacles, and object locations |\n| Task understanding | Grok or a language layer handles instructions | Turn user language or factory tasks into executable steps |\n| Motion and manipulation | Motion planning, manipulation planning, balance control | Turn target poses into continuous body and hand motions |\n| Execution output | Third-party summaries mention 28 body actuators plus 50 hand actuators | A high-dimensional action space, with harder debugging and safety than self-driving |\n\nThe action space in self-driving is small: steering, throttle, and braking cover most of it. A humanoid robot is different. If Optimus has 78 actuators, every time step has to coordinate body, arms, fingers, balance, and contact. If a cup slips slightly, finger force, wrist motion, arm trajectory, and center of mass all need to adjust together.\n\nAn end-to-end direction can remove many hand-written interfaces between vision, language, space, and action, allowing them to influence one another through training. The cost is debugging. When the robot grabs the wrong part, was the depth estimate wrong, the object semantics wrong, the action head wrong, or did the actuator fail to track? An engineering system still needs logs, state replay, safety controllers, and interpretable intermediate signals.\n\nIf I split Optimus as an engineering system, I would start with four interfaces.\n\n| Interface | Input | Output | How to evaluate it |\n|-----------|-------|--------|--------------------|\n| Vision to 3D | Multi-camera images, body pose | Occupancy, object positions, reachable space | Stability under occlusion, reflection, narrow passages, and low-texture objects |\n| Language to task | Human instruction, factory SOP, current scene | Subtask sequence and failure recovery policy | Whether changed wording still produces a reasonable process, and whether failures can be replanned |\n| Task to action | Subtasks, end-effector targets, contact state | Body, arm, and finger trajectories | Frequency, latency, jitter, and contact force within safety bounds |\n| Action to execution | Joint targets, current limits, sensor feedback | Execution result, fault code, emergency-stop state | Drift after long repetition, and whether faults can be located |\n\nThe same four interfaces also map onto my robot dog, only at a much smaller scale. My dog only has language-to-fixed-action and action-to-PWM. It lacks vision-to-3D and contact state. Optimus has to make all four interfaces work at the same time, and any failure at one layer may be swallowed by the unified model.\n\n## Where Data Comes From, and Why Mass Production Is Hard\n\nTesla's advantage is often summarized as fleet data. That is only partly true here. Fleet data can give Optimus visual common sense, spatial understanding, lighting adaptation, dynamic-object prediction, and occupancy representations. Cars do not handle cup friction, and they do not use fingers to judge whether a cardboard box has collapsed. What robots lack most is contact data from the physical world. Based on public material, Optimus data mainly comes from four sources.\n\n| Data source | What it adds | What is still missing |\n|-------------|--------------|-----------------------|\n| Vehicle fleet | Visual common sense, spatial understanding, occupancy representations | Grasping, force control, touch, contact failures |\n| Human first-person demonstrations | Task semantics, hand details, tool use | Robot proprioception and real execution error |\n| Digital Dreams or neural world simulator | Long-tail scenes, lighting, object placement, initial-state variants | Physical consistency of generated data still needs real-robot validation |\n| Factory Optimus online feedback | Successes and failures closest to deployment | Limited by robot count, task boundary, and safety constraints |\n\nThat is why human operators wear helmets and backpack cameras to collect data on site. I also recently saw Chinese embodied-AI companies working with housekeeping companies, asking workers to clean while wearing sensors and cameras. These partnerships are all trying to capture physical-world contact data. ![Tesla data collection: helmet plus backpack camera rig at a teleoperation site](/images/2026/robot/17-optimus-data-collection.png)\n\nRobot data is much slower than self-driving data. A vehicle fleet can collect from cars all over the road every day. Teleoperation usually means one person teaching one robot at a time. Autonomous real-robot collection is even slower. Failures wear hardware, interrupt production lines, and add safety risk. This is hard, but I still like the direction.\n\nThe gap between robotics companies will gradually show up in how fast they collect samples, train, and change hardware. A company that can collect failed samples cheaply and steadily, then feed them into the next training and hardware loop, will widen its iteration lead.\n\n![Robot training cycle: real data, simulation, training, and real-robot validation](/images/2026/editorial/robot-training-en.webp)\n\nData is one barrier. Manufacturing is another.\n\nTesla discusses Optimus on almost every earnings call. As an investor, I try to separate what they say from what has been achieved. If you connect the public statements from 2024 to 2026, you can see continuous movement and the recurring bottlenecks.\n\n| Public statement | Where it gets stuck |\n|------------------|---------------------|\n| Use Optimus inside Tesla factories first | The factory is a task field, a data field, and a safety boundary |\n| The robot is not design-locked yet | Hardware finalization is still moving. Model iteration speed does not equal whole-machine iteration speed |\n| Production-line target moves from 1,000 units per month to higher scale | The bottleneck is actuators, batteries, wiring, assembly, and quality-control yield |\n| Target cost below USD 20,000 after scaling | This depends on a new supply chain. Software cost reduction is only one part |\n| Rare-earth permanent magnets were named as an Optimus constraint | Actuators are constrained by materials and supply chains |\n\nThese constraints matter more than a delivery year. Humanoid robots cannot wait for the model to finish training before the production line starts. Hardware, data, and manufacturing usually move together. If the hand design changes, the forearm structure, wiring, tactile sensors, controllers, and supply chain move with it. If actuator yield is unstable, the slowest part drags down production targets.\n\n![Optimus production roadmap: working backward from targets to engineering constraints](/images/2026/editorial/robot-production-en.webp)\n\nFrom public material, Tesla is betting on a combination of real-world data, manufacturing scale, and vertical integration. FSD gives it a visual and training-infrastructure base. Factories give it controlled tasks and feedback. Manufacturing gives it a cost-down path. If hand reliability, actuator cost, safety protection, or real workstation ROI gets stuck, those advantages will be hard to turn into product.\n\nThe next useful checks for Optimus are concrete: long-term reliability of the hand structure, how fast failed samples return to training and real-robot validation, whether the model exposes debuggable interfaces, and whether actuator and supply-chain support can match the production-line targets. For Tesla's route to work, fleet visual experience, factory tasks, world simulators, training clusters, and manufacturing have to work together.\n\n---\n\n## Different Routes Across Companies\n\nMany companies are building humanoid robots now, but their routes and bets differ a lot.\n\n| Player | Route | Main bet | What to watch |\n|--------|-------|----------|---------------|\n| Tesla Optimus | Vision-only, FSD transfer, factory trials, in-house actuators | Failed samples and manufacturing scale | Hands, actuator cost, real workstation ROI |\n| Figure | Helix and Helix 02, full-body VLA and factory tasks | On-device VLA and long-horizon loco-manipulation | Stability outside demos, maintenance cost |\n| Google DeepMind | Gemini Robotics, high-level ER plus low-level VLA | General multi-step reasoning connected to robot actions | Generalization and safety boundaries across partner hardware |\n| NVIDIA | Jetson Thor, Cosmos, Isaac, GR00T | Chips, simulation, world models, and foundation-model toolchains | Whether the stack can be reused reliably across robots |\n| Boston Dynamics | Traditional control base plus AI augmentation | Reliable motion control and industrial deployment | Cost and general manipulation ability |\n| Unitree | Cost-effective hardware, strong motion ability, developer market | Expand the hardware base through low prices | Software community and safety-task capability |\n| AGIBOT | Multiple form factors, datasets, full-stack platform | Domestic supply chain and real task data | Publicly verifiable task coverage and continuous operation |\n\nThese seven companies split into two groups. One group builds complete robots. Tesla, Figure, Unitree, and AGIBOT cover hardware and models themselves. The other group does not bind itself to a single body. Google DeepMind builds the intelligence layer that can connect to different robots. NVIDIA sells compute, simulation, world models, and foundation-model tooling to everyone. The first group bets on whether data and manufacturing can lock together. The second bets on whether its layer can transfer across robot bodies.\n\n![NVIDIA Cosmos and World Labs Marble: predictive video from world foundation models](/images/2026/robot/20-world-foundation-models.png)\n\nThe platform route sounds easier, but the interface boundary is risky. If the upper instruction is too abstract, the lower layer cannot execute it. If the lower layer fails without a clear reason, the upper layer cannot replan. It is the same problem that showed up in the VLA section.\n\nVLA is not the only route. Boston Dynamics does not lean on the large-model narrative, yet electric Atlas and years of motion-control work still get it into factory logistics. Industrial sites care about cycle time, failure rate, and safety certification more than demos. In China, the most practical signals are price and supply-chain speed. Unitree G1 officially starts at USD 13,500. That price can quickly expand the hardware base. Whether it can handle general tasks and stay reliable for long periods still needs time.\n\n![Three strategic routes: general capability, vertical ROI, and human coexistence](/images/2026/editorial/robot-routes-en.webp)\n\nBehind these routes are three trade-offs. Factories are widely treated as the first stop because the environment is controlled, ROI can be calculated, and task boundaries can be limited. Homes are the hardest. The environment is messy, users tolerate little error, and the robot has to be quiet, safe, and privacy-aware. Platform companies choose to sell the toolchain first because most robotics companies lack data, simulation, edge compute, and training frameworks.\n\n---\n\n## Moving From Software Toward Embodied AI\n\nIf you are also a software engineer and want to keep studying embodied AI, these system-level areas are hard to avoid.\n\n- Embedded and real-time systems: GPIO, PWM, I2C, UART, SPI, timers, interrupts, RTOS\n- Robot kinematics: coordinate frames, forward and inverse kinematics, Jacobian, end-effector pose\n- Control basics: PID, MPC, state estimation, sampling frequency, latency, stability\n- Perception and SLAM: camera model, depth, IMU, LiDAR, extrinsics, time synchronization\n- Imitation learning and reinforcement learning: behavior cloning, ACT, Diffusion Policy, reward, Sim2Real\n- Data engineering: teleoperation, episode format, video-state synchronization, annotation, evaluation\n\nAs a stack, it runs from chips, actuators, and sensors up to algorithms and systems. Looking only at models hides many of the hard problems. Looking at the whole stack makes it clearer where each problem sits.\n\n![Embodied AI technology stack: from chips to systems](/images/2026/editorial/robot-stack-en.webp)\n\nMy current way of connecting the material is this: start with a small hardware project like the robot dog, because it ties together cloud-edge collaboration and local action. Wake-up, networking, model calls, capability descriptions, serial protocols, action execution, and status return can all fail in one small system. The project is not large, but every part can fail in a real way. Figuring out those failures one by one is what makes it fun to explore.\n\nAfter running cloud-edge collaboration and MCP once, ACT and ALOHA become easier to read. Low-cost teleoperation and action chunking make more sense. Diffusion Policy then explains why actions sometimes need to be modeled as distributions. RT-1, RT-2, Open X-Embodiment, and OpenVLA connect VLA with cross-embodiment data. Finally, pi0, pi0.5, SmolVLA, Gemini Robotics, Helix, and GR00T N1.5 show how industry is trying to combine high-level reasoning, low-level action, and edge deployment.\n\nIf I had to compress embodied AI into four words, I would use perception, space, action, and torque. The difficulty roughly increases in that order. AI perception is already strong. Spatial ability is still catching up. We're only starting to make progress on action. Torque brings the work back to motors, structure, contact, and power. The closer AI moves to the physical world, the less the model can solve alone. More of the remaining work becomes hardware.\n\n---\n\n## References\n\n**Models and Algorithms**\n\n1. [RT-1: Robotics Transformer for Real-World Control at Scale](https://arxiv.org/abs/2212.06817), Google Robotics, 2022.\n2. [RT-2: New model translates vision and language into action](https://deepmind.google/discover/blog/rt-2-new-model-translates-vision-and-language-into-action/), Google DeepMind, 2023.\n3. [Diffusion Policy: Visuomotor Policy Learning via Action Diffusion](https://arxiv.org/abs/2303.04137), Columbia + MIT CSAIL, 2023.\n4. [Learning Fine-Grained Bimanual Manipulation with Low-Cost Hardware](https://arxiv.org/abs/2304.13705), ACT / ALOHA, 2023.\n5. [Open X-Embodiment](https://arxiv.org/abs/2310.08864), Google DeepMind + 33 institutions, 2023.\n6. [OpenVLA: An Open-Source Vision-Language-Action Model](https://arxiv.org/abs/2406.09246), Stanford + Physical Intelligence + Google DeepMind, 2024.\n7. [pi0: A Vision-Language-Action Flow Model for General Robot Control](https://arxiv.org/abs/2410.24164), Physical Intelligence, 2024.\n8. [pi0.5: a VLA with Open-World Generalization](https://www.pi.website/blog/pi05), Physical Intelligence, 2025.\n9. [SmolVLA: Efficient Vision-Language-Action Model trained on LeRobot Community Data](https://huggingface.co/blog/smolvla), Hugging Face, 2025.\n10. [Gemini Robotics](https://deepmind.google/models/gemini-robotics/), Google DeepMind.\n11. [Gemini Robotics On-Device brings AI to local robotic devices](https://deepmind.google/blog/gemini-robotics-on-device-brings-ai-to-local-robotic-devices/), Google DeepMind, 2025.\n\n**Industry, Hardware, and Toolchains**\n\n1. [Helix: A Vision-Language-Action Model for Generalist Humanoid Control](https://www.figure.ai/news/helix), Figure AI, 2025.\n2. [Introducing Helix 02: Full-Body Autonomy](https://www.figure.ai/news/helix-02), Figure AI.\n3. [NVIDIA Jetson Thor](https://www.nvidia.com/en-us/autonomous-machines/embedded-systems/jetson-thor/), NVIDIA.\n4. [Cosmos World Foundation Model Platform for Physical AI](https://research.nvidia.com/publication/2025-01_cosmos-world-foundation-model-platform-physical-ai), NVIDIA Research, 2025.\n5. [GR00T N1.5](https://research.nvidia.com/labs/gear/gr00t-n1_5/), NVIDIA GEAR.\n6. [LeRobot](https://github.com/huggingface/lerobot), Hugging Face.\n7. [SO-ARM100](https://github.com/TheRobotStudio/SO-ARM100), SO-100 / SO-101 low-cost robot-arm hardware.\n8. [xiaozhi-esp32](https://github.com/78/xiaozhi-esp32), open-source ESP32 AI voice assistant.\n9. [Genesis](https://github.com/Genesis-Embodied-AI/Genesis), open-source physics simulation platform.\n10. [NVIDIA Isaac Lab](https://isaac-sim.github.io/IsaacLab/main/index.html), robotics learning framework.\n11. [Tesla AI Day 2022 transcript](https://gist.github.com/L0rdCha0s/de22ae0c7e7a7a70b37ac9c1262e27e1), early Optimus technical disclosure.\n12. [AI Training for Tesla Optimus Explained](https://optimusk.blog/blog/ai-training-for-tesla-optimus/), third-party summary of Optimus AI training, data sources, and world simulators.\n13. [Tesla Earnings Call Transcripts](https://stockanalysis.com/stocks/tsla/transcripts/), public transcript aggregator for Optimus statements from 2024 Q2 to 2025 Q3.\n14. [The Pinless Finger: What Tesla Put Where the Hinge Should Be](https://x.com/seti_park/status/2044824259634311425), third-party WIPO patent teardown of Optimus Gen 3 hand and forearm.\n15. [Unitree G1](https://www.unitree-robot.com/shop/products/unitree-g1), Unitree official store.\n\n---\n\n## More Reading\n\nIf you want to keep reading this AI engineering series, these earlier long posts are a good order:\n\n1. [What People Miss About Claude Code: Architecture, Governance, and Engineering Practice](https://x.com/HiTw93/status/2032091246588518683)\n2. [What People Miss About Agents: Principles, Architecture, and Engineering Practice](https://x.com/HiTw93/status/2034627967926825175)\n3. [What People Miss About Large-Model Training: Principles, Paths, and New Practice](https://x.com/HiTw93/status/2040047268221608281)\n4. [What People Miss About AI Coding: Getting Started, Use Cases, and Practice for Non-Engineers](https://x.com/HiTw93/status/2048230976447557787)\n5. [What People Miss About GEO: Principles, Practice, and Trade-offs in AI Visibility](https://x.com/HiTw93/status/2049868069208768812)\n\n---\n\nThe first draft was completed in May 2026 and kept being revised in June. Embodied AI is moving quickly, so some numbers and product progress may continue to change. If you find an error, please let me know."} {"title":"You Didn't Know GEO: AI Visibility Principles, Practices, and Trade-offs","date":"2026-05-01","language":"en-US","summary":"A few friends pinged me recently saying my open source tools were showing up when they asked AI questions. I hadn't done anything deliberate, so I figured: why not spend an hour structuring things properly? After doing it, I fired off a quick tweet, but the notes were messy. People seemed genuinely interested, so I decided to write it up as a proper article for reference.","categories":["Share"],"url":"https://tw93.fun/en/2026-05-01/ai-visibility.html","markdownUrl":"https://tw93.fun/en/2026-05-01/ai-visibility.md","translation":{"language":"zh-CN","title":"你不知道的 GEO：AI 可见性的原理、实践与取舍","url":"https://tw93.fun/2026-05-01/ai-visibility.html","markdownUrl":"https://tw93.fun/2026-05-01/ai-visibility.md"},"contentMarkdown":"\"AI\n\n## One Hour to Make AI Find Your Content\n\nA few friends pinged me recently saying my open source tools were showing up when they asked AI questions. I hadn't done anything deliberate, so I figured: why not spend an hour structuring things properly? After doing it, I fired off a quick tweet, but the notes were messy. People seemed genuinely interested, so I decided to write it up as a proper article for reference.\n\nI hate gaming rankings or generating junk content. This article won't teach you shortcuts. It's about helping AI better understand the content you already have.\n\nI looked into why it happened and found that AI search runs on entirely different logic. Traditional SEO is about fighting into the top 10, but 83% of AI Overview citations come from pages outside the top 10. AI rewards clear structure and reliable sourcing, not PageRank. My projects aren't big, but the READMEs and docs are well-written enough that AI picks them up where bigger sites have thin content. That's probably why friends were seeing Pake and MiaoYan in their AI results.\n\nAI search is growing fast: 527% year-over-year in the first half of 2025, ChatGPT hit 900 million weekly active users by February 2026, and referral traffic converts at roughly 5x the rate of traditional search. But it still accounts for less than 1% of total referral traffic. This is a brand visibility strategy, not a traffic strategy. Worth an hour of setup, not a week, because your product is your real competitive advantage, not this.\n\n\"AI\n\n---\n\n## Use robots.txt to Sort Out Crawler Types\n\nMost people treat robots.txt as a switch: either block AI crawlers or allow them all. But AI crawlers come in several types, and they do different things.\n\n**Training crawlers** (GPTBot, ClaudeBot, Meta-ExternalAgent, CCBot) take your content to train models. Blocking them keeps your content out of training data but doesn't affect current AI search results.\n\n**Search and retrieval crawlers** (OAI-SearchBot, Claude-SearchBot, PerplexityBot) fetch content in real time to answer user queries. Block these and you vanish from AI search.\n\n**User-triggered fetchers** (ChatGPT-User, Claude-User, Perplexity-User, Google-Agent) only fire when someone pastes your URL into a chat window. Block them and users asking \"summarize this page\" get nothing.\n\n**Opt-out tokens** (Google-Extended, Applebot-Extended) aren't real crawlers. They're signals you declare in robots.txt to opt out of AI training.\n\n**Undeclared crawlers** (Bytespider, xAI's Grok bot) don't identify themselves and don't necessarily follow the rules.\n\n\"Five\n\nMy approach: allow search/retrieval and user-triggered crawlers, block training and undeclared ones.\n\n```\n# Search & retrieval: allow\nUser-agent: OAI-SearchBot\nAllow: /\n\nUser-agent: Claude-SearchBot\nAllow: /\n\nUser-agent: PerplexityBot\nAllow: /\n\n# User-triggered: allow\nUser-agent: ChatGPT-User\nAllow: /\n\nUser-agent: Claude-User\nAllow: /\n\n# Training: block\nUser-agent: GPTBot\nDisallow: /\n\nUser-agent: CCBot\nDisallow: /\n\n# Opt-out tokens\nUser-agent: Google-Extended\nDisallow: /\n\n# Undeclared: block\nUser-agent: Bytespider\nDisallow: /\n```\n\n\n## Write Your llms.txt and Cross-Link Your Sites\n\nllms.txt is a new standard, similar to robots.txt but written for AI tools to read. You place a Markdown file at your site root describing what your site does, its key pages, and who's behind it. AI systems prioritize this file when they crawl your content.\n\nBuiltWith tracks over 840,000 websites that have deployed llms.txt, including Anthropic, Cloudflare, Stripe, and Vercel. But in SE Ranking's survey of 300,000 domains, adoption is only 10%. It's still early, and being early is an advantage.\n\nThe format is simple:\n\n```markdown\n# Your Project Name\n\n> One-line description of what this is.\n\n## Links\n\n- [Documentation](https://yoursite.com/docs)\n- [GitHub](https://github.com/you/project)\n- [Blog](https://yoursite.com/blog)\n\n## About\n\nShort paragraph explaining the project, its purpose, \nkey features, and what makes it different.\n```\n\n\"Example\n\nAfter creating yours, submit it to directory.llmstxt.cloud, llmstxt.site, and the llms-txt-hub repository on GitHub via PR.\n\nI also did something interesting: I made each site's llms.txt reference the others. I maintain tw93.fun, weekly.tw93.fun, and yobi.tw93.fun. Each site's llms.txt links to the rest, forming a mesh. An AI crawler entering through any one site can follow the links and discover everything else.\n\n\"Four\n\nThese changes take effect after crawlers revisit your site, usually within a few days. After that, try searching for your project name in ChatGPT. The citation sources and description accuracy should improve.\n\n![](https://gw.alipayobjects.com/zos/k/ci/3bugwW.png)\n\n## Provide Full Content and Markdown Routes\n\nllms.txt is the summary. llms-full.txt is the complete version, typically 30-60KB, containing project descriptions, FAQs, usage scenarios, competitive comparisons, and README excerpts. Mintlify's CDN analysis shows llms-full.txt gets 3-4x more traffic than llms.txt. AI systems that find the summary want the full version.\n\n**Markdown routes** go further. Evil Martians recommend providing a `.md` version of every page on your site. A 15,000-token HTML page becomes a 3,000-token Markdown document, 80% less noise.\n\n\"HTML\n\nThe simplest way to tell AI you have a Markdown version is adding this to your page's ``:\n\n```html\n\n```\n\nClaude Code and Cursor already send `Accept: text/markdown` headers when fetching docs. This is standard HTTP/1.1 content negotiation, around since 1997.\n\n---\n\n## Register Your Site with Search Platforms\n\nThe robots.txt and llms.txt work from the previous sections makes your content readable to AI, but AI has to find you first. ChatGPT's search runs on Bing, Google AI Overview uses Google's own index, and Perplexity also relies on search APIs. If your pages aren't indexed by search engines, none of the structuring work above matters. So the first step is making sure Google and Bing have indexed your site.\n\nThe setup is straightforward: go to [Google Search Console](https://search.google.com/search-console), verify your domain via DNS or HTML file upload, then submit your sitemap URL (usually `yoursite.com/sitemap.xml`). Check the \"Pages\" indexing report to see which pages are indexed and which have issues. If an important page isn't indexed, use the URL Inspection tool to manually request indexing.\n\nYou might think Bing doesn't matter, but Copilot, DuckDuckGo, and Yahoo all run on Bing's index underneath. Register with Bing Webmaster Tools, submit your sitemap, and check the AI Performance panel to see how often AI cites your content. While you're there, set up IndexNow so Bing gets notified immediately when you publish new content instead of waiting for a crawler to find it.\n\nSetting up IndexNow means placing an API key file at your site root, then sending a POST request to `api.indexnow.org/indexnow` with the list of changed URLs whenever you publish. Bing picks them up within minutes. Many static site generators and CMS platforms have IndexNow plugins available.\n\n\"Bing\n\nGoogle Search Console doesn't have an AI-specific panel yet, but submitting your sitemap and monitoring indexing status is still worth doing. Google's AI Overviews pull from a wider range than traditional results, so even pages that don't rank in the top 10 can appear in AI-generated answers.\n\nPerplexity has more users than you'd expect. They run a publisher program at pplx.ai/publisher-program. Once approved, you get an 80/20 revenue share and access to citation analytics data.\n\n---\n\n## I Built a Dedicated Knowledge Site for AI\n\nInstead of waiting for AI to scrape information from scattered sources, give it a single entry point with everything organized.\n\nA knowledge site should provide three layers: an overview (llms.txt), a full version (llms-full.txt, 30-60KB), and standalone knowledge pages for each core project. Add structured JSON APIs so AI tools can fetch data programmatically. Pull data live from upstream sources like the GitHub API with caching that refreshes periodically, keeping maintenance work down.\n\nIt also helps to explain how your projects relate, rather than giving AI just a list. If you have multiple projects, write a description that connects them, how they relate, your technical direction, the overall picture. When AI answers \"who is this person\" or \"what does this team do,\" that description gives it more to work with than a list alone.\n\nMy implementation is called Yobi (from the Japanese 呼び / よび, meaning \"to call\" or \"to summon\"). It serves an llms.txt overview, a 50KB llms-full.txt, per-project pages, and four JSON endpoints (`/api/profile`, `/api/projects`, `/api/blog`, `/api/weekly`) that pull live data from the GitHub API with ISR caching that refreshes hourly. Stack: Next.js + TypeScript on Vercel.\n\n\"Yobi\n\nThe JSON API returns structured project data with live GitHub stats:\n\n\"JSON\n\n## Give Each Project Its Own Page\n\nEach project needs its own standalone page, not a row in a list, but a self-contained Markdown document with a citable summary, core features, competitive comparisons, use cases, and install commands. Ahrefs found that cited pages have titles with higher semantic similarity to user queries, and natural-language URL slugs (like /projects/pake) get cited more than opaque IDs (like /page?id=47).\n\n\"Per-project\n\nURL structure matters. `/projects/pake` tells the model what the page is about before it reads a single line. `/page?id=47` tells it nothing.\n\n## Sync Structured Data to Your Main Domain\n\nSubdomains carry less authority than root domains. AI crawlers that discover example.com won't automatically find docs.example.com or api.example.com. If your llms.txt, project pages, and API data are spread across subdomains, AI may only see part of the picture.\n\nThe fix is to mirror key structured data onto your main domain so that `example.com/llms.txt`, `example.com/projects/xxx.md`, and `example.com/api/projects.json` all live under one roof. AI crawlers discover your main site through search indexing and find everything without leaving. Implementation options include scheduled CI sync, build-time fetching, or reverse proxying. I use a GitHub Action that syncs subdomain data to the blog repo nightly.\n\n\"GitHub\n\nWhen launching a new site, use a checklist to avoid gaps. Core items: robots.txt (categorized crawler permissions), llms.txt (site summary with cross-references), sitemap (submitted to search engines), Bing Webmaster Tools (enable IndexNow), Google Search Console (monitor indexing). Each site's llms.txt should reference the others, forming a discovery mesh.\n\n---\n\nThe easiest trap when doing this work is getting carried away with every GEO technique you come across and trying to add them all, creating a mess and losing sight of what matters.\n\n## These Didn't Work\n\n**`` and ``**: no spec, no adoption by any major AI system.\n\n**`/.well-known/ai.txt`**: multiple competing proposals, no real adoption. Wait for a winner.\n\n**HTML comments with AI hints**: parsers strip comments before AI sees the content.\n\n**User-Agent sniffing to serve Markdown**: returning different content to bots versus humans is cloaking. Google will penalize you.\n\n**Unofficial AI meta tags**: unless a major AI provider explicitly documents support, it's just noise.\n\n## JSON-LD Isn't as Useful as You'd Think\n\nI initially thought JSON-LD would be powerful for AI visibility. Deeper research showed a more complicated picture. SearchVIU ran an experiment where they put data only in JSON-LD without showing it on the page. All five AI systems they tested failed to find it. Mark Williams-Cook's follow-up experiment showed that LLMs treat `\n{:/nomarkdown}\n\n### Graphics Class\n\nIn the demo above, we created a Shape, which wraps a canvas element. To actually draw onto this canvas, you interact with the Graphics class.\n\nGraphics provides rich styling and path-drawing methods. Every drawing call returns the Graphics instance, making method chaining super clean. See the [EaselJS API Documentation](https://createjs.com/docs/easeljs/classes/Graphics.html) for full details.\n\n### EaselJS Elements\n\nEaselJS handles images, shapes, sprite animations, and text — represented by `Bitmap`, `Shape`, `Sprite`, and `Text`:\n\n```js\n// Bitmap for images\nconst bitmap = new createjs.Bitmap(\"imagePath.jpg\");\n\n// Shape + Graphics for vector drawing\nconst shape = new createjs.Shape();\nshape.graphics.beginFill(\"#ff0000\").drawRect(0, 0, 100, 100);\n\n// Sprite for frame-based animations (detailed below)\nconst instance = new createjs.Sprite(spriteSheet);\ninstance.gotoAndStop(\"frameName\");\n\n// Text for typography\nconst text = new createjs.Text(\"How are you\", \"20px Arial\", \"#000000\");\n```\n\n### Sprite Animation\n\nThis is one of the most delightful features when you first try CreateJS — straightforward to wire up and visually satisfying. For example, here's an animated walking gentleman:\n\n{::nomarkdown}\n

See the Pen Sprite by Tw93 (@tw93) on CodePen.

\n\n{:/nomarkdown}\n\n**Tip**: You can use [TexturePacker](https://www.codeandweb.com/texturepacker) to generate sprite sheets. It even has an option to export directly for EaselJS — just drop the output directly into `SpriteSheet`.\n\nYou can easily define multiple animation sequences to make characters more dynamic. Check out the [SpriteSheet Class](https://createjs.com/docs/easeljs/classes/SpriteSheet.html) docs for deeper options.\n\n### Ticker Refresh\n\n#### Main Function\n\nThe movement of the characters mentioned above relies on Ticker to refresh the stage in real time. At the same time, addEventListener can be used to listen to the refresh of tick and \"do something\" inside.\n\n```js\ncreatejs.Ticker.framerate = 60;\ncreatejs.Ticker.timingMode = createjs.Ticker.RAF_SYNCHED;\nsprite.addEventListener(\"tick\", ()=>{console.log(\"doing something\"});\n```\n\n#### Focus Points\n\n**createjs.Ticker.framerate** indicates Ticker frame rate. Ideally it is 60FPS. Here it can be set to 60 during game experience optimization.\n\n**createjs.Ticker.timingMode** indicates Ticker's rendering mode (setTimeout, requestAnimationFrame). Can choose like this:\n\n- TIMEOUT: Default mode. This mode updates the next time through setTimeout. Although it provides a predictable and flexible frame rate, it is much worse than requestAnimationFrame in performance experience. Not recommended.\n- RAF: Simply use RAF. Will ignore frame rate equivalent values set by framerate. Frequency depends on the running environment and browser performance at that time.\n- RAF_SYNCHED: It will try to coordinate RAF and the set framerate frequency. Equivalent to combining the advantages of setTimeout and RAF. That is, here you can set framerate=60, optimize to let CreateJS help handle. Recommend using this mode.\n\n#### Optimization Points\n\nAt the same time, it can be combined with `Ticker.paused` for performance optimization. For example, when we pause the game, we can prevent constant refreshing like this:\n\n```js\ncreatejs.Ticker.addEventListener('tick', (e) => {\n !e.paused && stage.update();\n});\ncreatejs.Ticker.paused = true; //Calling this anywhere will pause processing inside tick\ncreatejs.Ticker.paused = false; //Calling this anywhere will resume processing inside tick\n```\n\nIn the process of performance tuning, **createjs.Ticker.getMeasuredFPS()** can be used to output the real-time frame rate to the screen. When this value is very close to the set framerate, it indicates good performance.\n\n## Usage of TweenJS\n\nFrom the above, we can see that EaselJS can actually handle many things in CreateJS development. The other three items can be used as auxiliary tools to make development more convenient.\n\nTweenJS acts as the ability of \"movement\" here. At the same time, it can also be used independently. It supports numeric object properties and CSS style properties. It is a very powerful tween animation function library.\n\n### Case\n\nFor example, the following classic animation example:\n\n{::nomarkdown}\n

See the Pen TweenJS by Tw93 (@tw93) on CodePen.

\n\n{:/nomarkdown}\n\n### Usage\n \nMethod chaining makes orchestrating sequences straightforward: grab the target element, specify delays, trigger chained animations, and handle completion callbacks.\n \nFor everyday use cases, the basics cover almost everything. For advanced requirements, consult the [TweenJS Documentation](https://www.createjs.com/docs/tweenjs/modules/TweenJS.html):\n \n- `createjs.Ease`: Animation easing curves, including linear, bounceIn, circInOut, getBackIn, quadInOut, etc.\n- `ColorPlugin`: Color tweening plugin supporting standard CSS color values.\n- `CSSPlugin`: Requires registration via `createjs.CSSPlugin.install();`, animates standard CSS styles.\n- `RotationPlugin`: Handles rotation transforms smoothly via `RotationPlugin.install(props);`.\n- `MotionGuidePlugin`: Guides elements along curved motion paths defined by vectors (`createjs.MotionGuidePlugin.install(createjs.Tween);`).\n- `Timeline`: Synchronizes and controls multiple animation groups together.\n \n ## Usage of PreloadJS\n \n PreloadJS coordinates asset loading so games can preload textures, audio, and data before gameplay starts.\n \n It centers around the `LoadQueue` class. In game development, the standard use case is preloading sprites and background tracks.\n \n ### Case\n \n Below, assets load with progress tracking while the background music begins playback:\n \n {::nomarkdown}\n

See the Pen PreloadJS by Tw93 (@tw93) on CodePen.

\n \n {:/nomarkdown}\n \n ### Usage\n \n #### Loading Method\n \n `const queue = new createjs.LoadQueue(false);`\n \n The boolean argument toggles between XHR (true) and tag-based loading (false). While true is the default, XHR often runs into CORS issues when loading from CDNs, so tag loading (`false`) is generally safer and more reliable.\n \n #### Resource Loading and Usage\n \n Using `loadManifest`, you can queue up all game assets at once — images, audio, JSON, and SVG files. Use `id` as the lookup key and retrieve assets with `queue.getResult(id)`.\n \n Listen to lifecycle events like `progress`, `fileload`, `complete`, and `error`. Combining `progress` and `complete` makes building a loading bar trivial.\n \n #### Loading Music\n \n To load audio, register the Sound plugin via `queue.installPlugin(createjs.Sound);` and specify fallback formats like `createjs.Sound.alternateExtensions = [\"mp3\"];`.\n \n There's a small catch here: older browsers might fail to play audio. You can use HTMLAudioPlugin to fix this: `createjs.Sound.registerPlugins([createjs.HTMLAudioPlugin]);`.\n \n Start playback with `createjs.Sound.play(id);`.\n \n ## Usage of SoundJS\n \n For casual web games, upbeat background music brings the experience to life. SoundJS handles audio playback with solid cross-browser compatibility.\n \n ### Sound Class\n\nAudio management mainly uses Sound class, with following functions:\n\n- Sound.registerSound: Register audio to be played. registerSounds supports multiple audios. Need to register in advance before audio playback (loading here can actually also use preload),\n- Sound.registerPlugins: Register audio playback plugins. Generally used for incompatible low browser scenarios. Can register to be compatible with WebAudioPlugin or HTMLAudioPlugin\n- Sound.play: Play audio, generally `createjs.Sound.play(id)`\n\n### AbstractSoundInstance Playback Instance Class\n\nWhen we call Sound.play API, we actually create an AbstractSoundInstance class. After creation, we can use it to directly control audio playback or other operations, and listen to its playback status:\n\n```js\nconst myInstance = createjs.Sound.play(\"myAssetPath/mySrcFile.mp3\");\n\n// Property control, select needed properties to set in practice\n// Properties can also be added to play second parameter as object\nmyInstance.volume = 0.5;\nmyInstance.paused = false; // Control music pause or not\nmyInstance.loop = true; // Loop playback\nmyInstance.duration = 30; // Playback duration\n\n// Listen to status, commonly used for error, re-play\nmyInstance.on(\"complete\", handleComplete);\nmyInstance.on(\"loop\", handleLoop);\nmyInstance.on(\"failed\", handleFailed);\n```\n\n## Performance Experience Optimization\n\n### Image Optimization\n\n- Image size affects performance more than normal H5. Try to use appropriate size and images compressed by [TinyPNG](https://tinypng.com)\n- For sprite sheets or many small image scenarios, use [TexturePacker](https://www.codeandweb.com/texturepacker) tool to synthesize them into one sprite sheet\n- For frame animation scenarios, use [gka](https://github.com/gkajs/gka) tool to compress images and directly generate animation files\n\n### Make Good Use of Recycling Mechanism\n\n- Destroy timely for those outside the screen or not in the stage\n- Use cache for complex objects to increase performance. Try not to use for simple ones, will have counter effect\n- [SpriteSheetBuilder](https://createjs.com/docs/easeljs/classes/SpriteSheetBuilder.html) way can replace cache, and effect is better\n\n### Use More Bitmaps Less Vectors\n\n- Vector operations in CreateJS affect performance relatively. Strangely Text shape are counted as vectors. Suggest directly converting text and vector images to bitmaps through tools here\n- If some projects must use vectors, filters, overlay modes, or contain very many sub-components, can optimize by using SpriteSheetBuilder for bitmap rendering\n- Mask in animateCC is equivalent to framing the whole animation sequence, vectorizing, so try to use less. If really have to use, operation method is same as handling vectors above\n\n### Filter and Animation Scene Optimization\n\n- Do not use filter effects such as (shadow filter and glow filter) to do animation, because this will consume performance very much, performance uncontrollable on mobile end\n- Can use frame-by-frame images to replace related filter effects to achieve animation effects\n\n### Reduce Nesting and Overlapping\n\n- When doing animation or other scenarios, try not to have too much container nesting, try to flatten the hierarchy (a bit like writing Weex, paying attention to flat and thin)\n- Some overlapping scenarios can be replaced directly with images\n\n### Frame Rate Optimization\n\n- Cancel frame rate listening timely if not used, such as tick\n- Use `createjs.Ticker.timingMode = createjs.Ticker.RAF_SYNCHED`\n- Set `createjs.Ticker.framerate` slightly higher than expected\n- Through `createjs.Ticker.getMeasuredFPS()` output real-time FPS to screen, perform optimization\n\n### Boost Performance with StageGL\n\n- [StageGL](https://createjs.com/docs/easeljs/classes/StageGL.html) is not included in the default minified build; import it separately.\n- Usage is identical to regular Stage, but unlocks hardware-accelerated WebGL rendering for dramatic performance gains. See [Getting Started with StageGL](http://blog.createjs.com/getting-started-with-stagegl/) for details.\n\n ```js\n // Conventional 2D scene\n const stage = new createjs.Stage(\"canvasId\");\n \n // Use WebGl\n const stage = new createjs.StageGL(\"canvasId\");\n ```\n\n### Mobile End Click Event Optimization\n\nWhen initializing our game, generally need to bind click events for it, but for mobile end adding this sentence will have much better effect\n\n```js\nvar stage = new createjs.Stage(\"canvasId\");\ncreatejs.Touch.enable(stage);\n```\n\n## End\n\nCreateJS features should be more than these. More need to be used in actual projects. Many interesting usages can be discovered through various game scenarios. If you also have insights on H5 interactive mini game development, welcome to communicate together."} {"title":"Reading Notes on \"Hackers and Painters\"","date":"2018-07-08","language":"en-US","summary":"Recently I am reading the book \"Hackers and Painters\", which mainly introduces the hobbies and motivations of hackers, i.e., excellent programmers, discusses hacker growth, hacker's contribution to the world, programming languages and hacker working methods, and other topics for everyone interested in the computer age. This article is used to record some notes and thoughts during reading.","categories":["Study"],"url":"https://tw93.fun/en/2018-07-08/hacker.html","markdownUrl":"https://tw93.fun/en/2018-07-08/hacker.md","translation":{"language":"zh-CN","title":"《黑客与画家》读书笔记","url":"https://tw93.fun/2018-07-08/hacker.html","markdownUrl":"https://tw93.fun/2018-07-08/hacker.md"},"contentMarkdown":"\n\n## Start\n\nRecently I am reading the book \"Hackers and Painters\", which mainly introduces the hobbies and motivations of hackers, i.e., excellent programmers, discusses hacker growth, hacker's contribution to the world, programming languages and hacker working methods, and other topics for everyone interested in the computer age. This article is used to record some notes and thoughts during reading.\n\n## 1. Why nerds are unpopular\n\n### Why?\n\nBecause nerds really don't want to make themselves popular. They think about other things in their minds. Their attention is on reading or observing the world to make themselves smarter, rather than pondering dressing up and socializing to make themselves popular.\n\n### Interesting Views\n\n- **For any kind of art, regardless of whether it is important, if you want to excel in that field, you must devote yourself wholeheartedly.**\n- For those highly difficult fields, only those who are in them can realize that success requires continuous (though not necessarily conscious) effort.\n\n### Places not very agreeable\n\n> Almost everyone I discussed with agreed that the worst period of life was between 11 and 14 years old.\"\n\nI don't quite agree here. It should be that the author had enough of the shadow formed by being bullied by those popular kids during that time period. At the same time, those people who communicated with him happened to be that kind of unpopular \"nerds\".\n\n> As for schools, they are nothing more than pens to keep livestock in this fake environment. Superficially, the mission of the school is to educate children. In fact, the real purpose of the school is to lock children in the same place so that adults can free their hands to finish things during the day.\n\nSeeing this sentence, it can be seen that the author really had shadows in his adolescence. Also not very agreeable. In the future, if I have children, I need to guide them well;\n\nHowever, in the whole book, most of the views still agree with the author.\n\n## 2. Hackers and Painters\n\nBefore reading this book, I always didn't want to call myself a code farmer, feeling like a repetitive laborer without thinking. More wanted to be a craftsman, make some interesting things through the tool of code, and make money by the way, getting the best of both worlds.\n\n### Relationship\n\nThe author says \"Hackers and painters are most alike\", very agreeable. **The commonality between hackers and painters is that they are both creators. Like composers, architects, and writers, hackers and painters are trying to create excellent works. They are essentially not doing research, although in the process of creation, they may discover some new technologies.**\n\nWhat hackers really want to do is design beautiful software. Assessing this kind of work is very difficult. You yourself need to have a good sense of design to assess whether other people's design is good. But, whether you think you have a \"good sense of design\" has no correlation with whether you actually have it, and may even have a negative correlation.\n\nThen an example of university computer practice was given. The school taught to figure out the program on paper first, and then type it out. This is exactly the same as writers, painters and architects. His way is regardless of right or wrong, pile up the code first, and then modify it slowly. It looks like programming is debugging.\n\n### Interesting Points\n\n- In order to avoid disasters in design, big companies chose to reduce the standard deviation of design results. But when you reject differences, you not only exclude the possibility of failure, but also exclude the possibility of high profits. This is also one of the reasons why startups can succeed.\n- The way for hackers to solve livelihood problems is to find a \"day job\" and then develop beautiful software in the rest of the time.\n- **Hackers learn programming through practice. Another way for creators to learn is through examples. You can learn programming by watching excellent source code.**\n- For programming, this actually means you can leave bugs to be solved later. Eliminating bugs is an easy job for me. Only at this time, programming becomes direct and mechanical, close to the appearance of programming in the imagination of the public.\n\n### Thinking\n\n> Among all the differences between ordinary hackers and excellent hackers, could \"empathy\" be the most important single factor?\n\nEmpathy here refers to putting oneself in the user's shoes. How to assess whether a person possesses it? **It is to see how he explains technical problems to people without technical background**. Increasingly feel that how to explain what you understand to people who don't understand certain technology very well so that they can easily understand it tests people's ability very much.\n\n> Programs are written for people to read, incidentally run on machines.\n\nVery much agree with this sentence. Programs are written to let people understand its algorithm, incidentally telling the computer how to execute. \"A good programming language should explain software easier than English. Only in those immature, prone-to-problem places, should you add comments to remind readers to pay attention there, just like warning signs only appear at sharp turns on the highway.\n\nMany people think that writing code that reflects technology very well is an experience of high level and high ability. Actually not. Solving complex problems with simple code, code that interns can easily understand is good code.\n\n## 3. Unspeakable Words\n\nThe author is relatively cautious, believing that no matter what era, \"disaster comes from the mouth\" always exists, warning readers to be careful about what they say. Remarks thought to be harmless will bring you big trouble.\n\n### Are you a conformist?\n\nIf in public, do you have any views that you are unwilling to say? If not, you should think about it carefully. It is possible **your views are heard from others. You believe whatever others tell you. You take the views instilled by others as your own views.**\n\nIn order to prevent others from copying, ancient craftsmen who made maps would deliberately draw a small place wrong on the map. If your map is the same as his map, it means it is unlikely that you made it independently.\n\nOur thoughts are almost certainly also a map with errors. If you also make the same mistakes as others, then this mistake is unlikely to come entirely from yourself.\n\n### Methods to find \"Unspeakable Words\"\n\n- **Judge the authenticity of remarks**: When words cannot be spoken, while they are correct or likely correct, worthy of further discussion.\n- **Pay attention to \"heresy\"**: Some ideas, purely because they are very special, the kind that cannot be spoken, highly controversial remarks are called \"heresy\".\n- **Review the past**. We can look for things that were considered granted in the past but are now considered incredible.\n- **Look for those solemn defenders of the faith and see what they are defending.**\n- **Observe how taboos are generated**\n\n### Why do this?\n\n- Pure curiosity, for the same reason as children turning over stones, want to see with own eyes, and then make decisions by themselves.\n- Don't like making mistakes, hope to know what things are, so that I won't be fooled.\n- Good mental training. To make excellent works, you need a brain that can think about any problem.\n\n### What to do after discovery\n\n- Don't say it, at least pick a suitable occasion to say it, only fight those battles worth fighting.\n- Draw a clear line between thought and speech. Think everything in mind, but don't necessarily say it out.\n- Keep mouth shut, smile to welcome, although cannot enjoy the benefits brought by discussion, but can find some trusted confidants, only speak freely with them.\n\n### Interesting Points\n\n- If you don't even dare to think about places where you don't agree with society, and give up your own views immediately, that will really be a problem.\n- **Excellent works often come from ideas ignored by others, and the most ignored ideas are those prohibited ideological views.**\n- The higher the intelligence, the more willing to think about those shocking ideological views. This is not only because smart people themselves actively look for loopholes in traditional concepts, but also because traditional concepts have little binding force on them and are easy to get rid of.\n\n### Thinking\n\n> Training yourself to think about those unthinkable things, the benefits you get will exceed the ideas themselves.\n\nBut generally like to do things one likes first. For things one doesn't want to do, drag as long as possible. Little do they know that they have been in the original thinking circle, cannot jump out, no innovation at all.\n\n> If you want to think clearly, you must stay away from the crowd. But the farther you go, the more difficult your situation will be, and the greater the resistance you will encounter, because you did not cater to social customs, but went against it step by step.\n\nThat is to be yourself, follow your heart, don't drift with the tide.\n\n## 4. Good Bad Habits\n\nFor programmers, the literal meaning of the word \"hacker\" is mainly \"proficient\", that is, he can dominate the computer as he wishes. \"Hack\" also has a meaning of praise. If the way you solve problems is very smart and superb, manipulating the entire system in the palm of your hand, this is also called you are very \"hack\".\n\nThen the author told an example of wanting to learn lock picking. The reason was not thinking about cracking to do bad things, but to satisfy curiosity, or hone one's intellect.\n\nThe good bad habits mentioned here, I understand should be a mentality of keeping curiosity about new things, loving freedom, and not loving control.\n\n### Interesting Points\n\n- Only by deeply understanding current technology can hackers conceive next-generation technology.\n- In the history of computer industry, new technologies are often developed by external personnel, and the proportion may be higher than internal personnel.\n- For appropriate disobedience to discipline, maintaining tolerance will not do much harm, but is very beneficial to America's national advantage. It allows America not only to attract smart people, but also to attract those who are very conceited.\n\n## 5. Another Road\n\nWhen the author started a business at that time, he originally planned to write a traditional desktop software, but thought that software could run on the server, with the browser as the operation interface. We tried to rewrite, letting all operations be done through the network.\n\nHe saw things very thoroughly, thinking that for users, in fact, many things do not need attention. Messy, frequently changing things are all placed on the server side, maintained by professionals proficient in this way. Users do not need to be \"system administrators\" themselves. This way is easier, cheaper, more mobile, more reliable, and usually more powerful than desktop software.\n\n### Victory of Users\n\nThinking in 95, death before inconvenience.\n\nInternet operations should not be restricted by geography, can be used anywhere. Actually, web pages are more convenient to use than desktop software installed on computers.\n\nThe concept of \"Your computer\" is slowly becoming past tense, replaced by \"Your data\". You should be able to get your data from any computer. Or more accurately, get your data on any terminal device. The terminal device does not necessarily have to be a computer.\n\nThe benefits of Internet software for users are: no installation needed, rapid release, smooth upgrade, rapid bug fix, can be used by multiple people at the same time, data is safer, etc.\n\n### Interesting Points\n\n- For **Internet software, no one stipulates that only certain languages can be used for development**, because all hardware is controlled in your hands. You can use whatever language you want. Different languages are suitable for different tasks. You should choose the most suitable tool according to different occasions, especially in the presence of competitors, \"can do this\" becomes \"must do this\", because if you don't use the advantage of language, you will let the opponent surpass you.\n- \"With the increase of software scale, development cost rises exponentially. This may be due to fixing old bugs. If bugs can be discovered quickly, the rising form of cost can basically remain linear.\"\n- Whenever possible, commercial companies will adopt a pricing method called \"price discrimination\", that is, giving different quotes for different customers to maximize profits.\n- Managing an enterprise is actually very simple, just remember two points: **Make products that users like, ensure expenses are less than income**.\n\n### Thinking\n\n> Users should be allowed to subscribe to the usage rights of software according to the length of use time like subscribing to newspapers.\n\nRemembering the subscription methods of software on some mac, iphone, I didn't understand before. In fact, this is good for both developers/users. Developers can continue to upgrade and bring better experience to users.\n\nFor software developers, this is an ideal source of income. There is a continuous cash flow every quarter, and at the same time can better manage people who buy software (don't pay, can't use it later...).\n\nFor buyers, I like it. Next time I can not subscribe, which is also relatively convenient.\n\n> Many farms use electric fences to prevent cows from escaping, but many electric fences are actually not electrified. However, the cows have already suffered, obviously learned not to touch the electric fence. At this time, not electrifying can also have an effect. \"Cows, act!\" he wrote, \"While the rulers are snoring, take back your freedom!\"\n\nThat is to say, why not try it? The author talks about entrepreneurship, but most hackers will have two things that deter them, dare not really start to take action. One is not knowing how to manage an enterprise, the other is fear of competition. But in fact, these two things are electric fences without electricity. Actually can try.\n\n## 6. How to Create Wealth\n\n**The author believes the best way is to start a business, or join a startup company.**\n\n### Why?\n\nEntrepreneurship is actually a compression process. All your working years are compressed into a few short years. In the high-tech field, the return is particularly generous. The higher the work efficiency, the higher the extra reward.\n\nSecondly, working time in startup is 2 times of company time. Plus concentration, output increases 3 times. Remove middle management layer, efficiency increases 2 times. At the same time, no need to complete tasks forcibly assigned by superiors, try to play smart according to own wishes, efficiency increases 3 times. That is, work efficiency is 36 times that in the company. That is, previously 80,000 dollars a year, now can be 3 million dollars a year. (Of course, the premise is a hacker...)\n\n### Component of Luck\n\nIn the success history of any company, luck is a big random factor. Those successful people you read in the newspaper are certainly smart and hard-working, but their luck is not bad either.\n\nHere cited an example of Bill Gates. The licensing agreement between IBM and Microsoft on DOS operating system was a mistake made by IBM. IBM did its best to help Microsoft control the standard of personal computers. From then on, Microsoft only needed to keep making products. It never had to make decisions with commercial risks. Microsoft only needed to hold on to the licensing agreement and quickly copy new products.\n\nThere are many ways to get rich (speculation, marriage, inheritance, theft, extortion, fraud, monopoly, bribery, lobbying, counterfeiting, mining, etc.). At that time, the above were probably getting something for nothing or illegal. Here mainly talks about **getting rich by creating valuable things and getting returns in the market**, which is both legal and simple.\n\n### Money does not equal wealth\n\nCreating valuable things is creating wealth. Before, I always thought having money means having wealth. Actually not. What we need is wealth. Food, clothing, housing, cars, daily necessities, travel, etc. are all wealth. Even if you don't have money, you can possess wealth.\n\nFor example, if you are in the interior of Antarctica, no matter how much money you have, it is useless to you, because there is nothing to buy. What you really need is wealth.\n\nThen why does everyone talk about making money? Part of the reason is that money is a convenient expression of wealth: money is a bit like liquid wealth. The two can often be transformed into each other, but not wealth, but just something we use to transfer ownership of wealth.\n\n### Craftsmen\n\nThe people most likely to understand that wealth can be created are those who are good at making things, that is, craftsmen. The things they make are sold directly in stores. However, with the advent of the industrial age, there are fewer and fewer craftsmen. **The largest group of craftsmen still existing is programmers.**\n\n### What is work\n\nWork is to cooperate with many people in an organization to make something people need.\n\n### Work Harder\n\nBig companies will average each employee's contribution. This is a problem. I think the biggest trouble for big companies is unable to accurately measure each employee's contribution.\n\nHowever, the reality is that the more energy you put into work, the more scale effect can be produced. In some industries, those employees who really work hard can create ten times or even a hundred times more wealth than ordinary employees.\n\nThis also points out a disadvantage of big companies. Your work cannot be quantified, contribution is difficult to measure, leading to many wanting to work harder, but mixed with work of many others. This creates problems. Others in the company will drag you down.\n\n### Measurability and Scalability\n\nTo get rich, you need two things: **Measurability and Scalability**. The performance produced by your position should be measurable, otherwise no matter how much you do, you won't get more pay. In addition, you must also have scalability, meaning the decisions you make can produce huge effects.\n\nHowever, if you want to possess both measurability and scalability, you don't necessarily have to be a CEO or movie star. You just need to become part of a small group tackling difficult problems.\n\nSmall group = Measurability, High tech = Scalability\n\nA very capable person who cares about returns usually performs better in a small team composed of similar people, and will feel more satisfied himself.\n\nAt the same time, most people who get rich by creating wealth are realized by developing new technologies.\n\n### Hidden Rules of Entrepreneurship\n\n- Many things are not up to you. After really starting a business, your competitors decide how hard you have to work, and the decisions they make are the same: We can endure as much hardship as you can.\n- Although the effort and return of entrepreneurship are generally proportional, they are disproportionate individually.\n\n### Interesting Points\n\n- A startup company is actually a small company that solves a certain technical problem.\n- If you want to earn 1 million dollars, you have to endure pain equivalent to 1 million dollars.\n- **Creating things people need is creating wealth.**\n- College life is very interesting, but it has passed. Why is working days so different? Don't be confused, you have now changed from a customer to a servant.\n\n### Thinking\n\n> What is technology? Technology is a certain means, the way we do things. If you discover a new way of doing things, its economic value depends on how many people use this new way.\n\nA very sensible sentence. Often, technical people will have a misunderstanding, feeling they are very powerful, but no one uses the thing at all. This is actually bad. Its value depends on how many people are using it, and whether it can solve problems.\n\n> Suppose you are a nimble little boy, with a sturdy big dog chasing you behind. You run to the stairs, should you go up or down at this time? I think should go up. If going down, the big dog might run as fast as you. Going up, the big dog's huge body will become a disadvantage. Yes, running upstairs you will be more strenuous, but the big dog will feel more strenuous.\n\nIn life and work, it should also be like this. Should **deliberately choose those very difficult technical problems**, not because this function can bring more income, but because it is relatively difficult, that is **barriers to entry**. Actually doing technology should also be like this, so it is interesting.\n\nIn general, this is also a good principle of conduct. If you have two choices, choose the harder one. If you have to choose between sitting at home watching TV or going out for a run, then go out for a run. The reason why this method is effective may be that when encountering two choices, one hard and one easy, often due to laziness, you will choose the easier option. Deep in consciousness, **you actually know that not being lazy will bring better results. This method just forces you to accept this point.**\n\n## 7. Focus on Wealth Differentiation\n\nWhen people really want to do something well, some people will do much better than others.\n\nWe say some jobs are overpaid, other jobs are underpaid. What exactly is our real thought? In a free competitive market economy, price is determined by buyer's demand. If people like baseball more than poetry, then baseball players' income is higher than poets'. If saying a certain job is underpaid, it is equivalent to saying people's demand is incorrect. Of course, people do demand incorrect things.\n\n### Interesting Points\n\n- How much value a person's work has is not determined by the government, but by the market.\n- Technology's improvement on production efficiency is not linear, but may be polynomial.\n- The only thing technology cannot make cheaper is brand.\n\n## 8. A Method to Prevent Spam\n\nThis section is not very meaningful for the current era. The author **believes that filtering spam is achievable, content-based filters will work.** But in his era, it was very meaningful.\n\nBayesian judgment on individual words can filter most spam very well. Later made a filter through statistical methods, actually a bit like current machine learning.\n\n## 9. Designer's Taste\n\nHere discusses \"How to make beautiful products\". Principles of excellent design are common principles of many disciplines, appearing repeatedly.\n\n### Many disciplines' understanding of beauty\n\n- Good design is simple design.\n- Good design is timeless design.\n- Good design is design that solves main problems.\n- Good design is inspiring design.\n- Good design is usually somewhat interesting design.\n- Good design is arduous design.\n- Good design is seemingly easy design.\n- Good design is symmetrical design.\n- Good design is design mimicking nature.\n- Good design is a redesign.\n- Good design is copyable design.\n- Good design is often strange design.\n- Good design appears in batches.\n- Good design is often bold design.\n\n### Interesting Points\n\n- Copernicus did not agree with Ptolemy's system. An extremely important reason is that he felt the equant proposed by Ptolemy had no aesthetic feeling...\n- The secret of excellent works is: very strict taste, plus the ability to realize this taste.\n\n## 10. Programming Language Parsing\n\nComputers, like other machines, have a list of operation commands. The sum of commands is the computer's machine language.\n\n### Machine Language\n\nWhen computers were just invented, all programs were lines of machine language commands. Not long after, programs changed to use assembly language, which is slightly more convenient to write than machine language. The command list is still the same, just replaced each command with a more humane name.\nThe common feature of both is: can only let most computers do some very simple things.\n\n### High-level Language\n\nThe language used by programs written in a convenient way is called high-level language, allowing you to use more powerful commands to develop programs.\nBesides being able to write code more briefly, there is another advantage, portability.\n\nHigh-level languages can be implemented using **compilers** or **interpreters**. The difference is that the former translates the entire program into machine language first, then runs it. The latter interprets code into corresponding machine language in real time, then runs line by line.\n\nHigh-level language code processed by compiler is also called source code. The machine code generated after translation is called object code.\n\n### Interesting Points\n\n- The more code required for an operation, the harder it is to avoid bugs, and the harder it is to find them.\n- **If you use a certain language for a long time, you will slowly think according to the thinking mode of this language.** So, later when you encounter any other language with significant differences, even if there is nothing wrong with that language itself, you will feel it extremely difficult to use. Inexperienced programmers' judgment on advantages and disadvantages of various languages is often misled by this mentality.\n\n#### Thinking\n\n> A small car with an aircraft engine tied to the roof might actually drive. As long as you don't try to turn, there might be no problem.\n\nThe new \"top-heavy\" programming languages mentioned here appearing later, their kernel design is not very good, but have countless powerful libraries, can be used to solve specific problems. Can imagine a small car with poor performance itself, but tied with an aircraft engine on the roof.\n\nThere are some very trivial, very common problems. Programmers originally had to spend a lot of time to solve them, but with these libraries, solving becomes very easy, so these libraries themselves may be more important than the core language.\n\nThis also better explains why hackers don't like using languages like C.\n\n## 11. Programming Language After A Hundred Years\n\nProgramming languages are like biological species, there is an evolutionary context. Many branches will eventually become evolutionary dead ends.\nThat is, languages of different branches will aggregate, because language designers always consciously borrow design ideas from other languages.\n\nThe author believes that those programming languages with the smallest and cleanest kernels will exist on the main trunk of evolution. The smaller and cleaner a language's kernel is designed, the more tenacious its vitality.\n\n### Interesting Points\n\n- A language that makes programmers do useless work can really be called lousy. Wasting programmer's time instead of machine's time is the real inefficiency. As computer speed gets faster and faster, this will become more and more obvious.\n- Programming language after a hundred years can theoretically be designed today; if such a language can really be designed today, it is likely suitable for programming now, and can produce better results.\n\n## 12. Reject Mediocrity\n\nHaha, in this section, the author is promoting Lisp language. Reminds me of SICP read before, a bit profound, need to read again to understand. He said people who really seriously take hackers as life goals should consider learning Lisp:\n\n> Lisp is worth learning. After you master it, you will feel the great inspiration it brings you. This will greatly improve your programming level, making you a better programmer. Although Lisp is rarely used in actual work.\n\n### Interesting Points\n\n- The benefit of Lisp language is not that it has some advantages only fanatical enthusiasts understand, but only that it is currently the most powerful programming language. The reason why it has not been widely used is because programming language is not only technology, but also a habitual thinking, very difficult to change. Of course, the above two sentences need further explanation.\n- Aikido is a Japanese martial art, main features are \"overcoming rigidity with softness\", \"borrowing strength to use force\", \"not attacking actively\".\n\n## 13. Revenge of the Nerds\n\n\"Conflict problem\" between product managers and programmers. One knows nothing about technology; one has strong personal views on technology.\n\nSpeaking of which, Lisp is mentioned again. Why is it special? When Lisp language was born, it contained 9 new ideas. Some of them we are accustomed to today, others just appeared in other high-level languages, and there are still 2 unique to Lisp so far.\n\n### Why Lisp language is special\n\n- Conditional structure (i.e. if-then-else structure)\n- Function is also a data type. In Lisp language, function belongs to one of data types just like integer or string. It has its own literal representation, can be stored in variables, and can also be passed as parameters. It has all the functions a data type should have.\n- Recursion. Lisp is the first high-level language supporting recursive functions.\n- Dynamic typing of variables. In Lisp language, all variables are actually pointers. Pointed values have types, but variables themselves do not. Copying variable is equivalent to copying pointer, not copying data they point to.\n- Garbage collection mechanism.\n- Program consists of expressions. Lisp program is a collection of expression trees. Each expression returns a value. This is completely different from Fortran and most later languages, whose programs consist of expressions and statements.\n- Symbol type. Symbol is actually a pointer, pointing to string stored in hash table. So, comparing whether two symbols are equal, just look if their pointers are same, no need to compare character by character.\n- Code uses tree notation composed of symbols and constants.\n- The whole language is available at any time. Lisp does not really distinguish reading period, compilation period and running period.\n\n### Interesting Points\n\n- Any C or Fortran program complicated to a certain extent will contain a temporarily developed, only half-functional, not fully compliant with specifications, buggy everywhere, slow-running Common Lisp implementation.\n\n## 14. Dream Programming Language\n\nThis language is clean and concise, with highest level of abstraction and interactivity, and very easy to equip. Can solve common problems with very little code. No matter what program, the code you really want to write is almost all related to your own specific settings. Other universal problems have ready-made libraries to call.\n\nThis language has a large number of excellent examples for learning, and is very intuitive. You only need to spend a few minutes reading examples to comprehend how to use this language.\n\nThis language is built in layers. Higher abstraction layer is transparently built on lower abstraction layer. If needed, you can directly use lower abstraction layer.\n\nAll details of this language are transparent to users. The abstraction capability it provides is only to facilitate your development, not to force you to act in its way.\n\n### Conciseness\n\n- The most important aspect of conciseness is to make language more abstract. To achieve this, first you must design a high-level language, then design it as abstract as possible.\n- Don't think considering for users is letting them use grammar as long and wordy as English.\n- Individual grammatical units should also be very short.\n\n### Hackability\n\n- When choosing programming language, there is another factor more important than conciseness, that is this language must be able to help oneself do what one wants to do.\n\n### Disposable Program\n\n- So-called disposable program refers to program written in a very short time to complete some very simple temporary tasks.\n- It must be very easy to equip. Disposable program is program you only want to write in one hour, so it shouldn't cost a lot of time to install and configure, preferably already installed on your computer. It must be usable whenever wanted.\n\n### Libraries\n\n- Library is program written by others to help you.\n- The importance of excellent libraries will exceed the language itself.\n\n### Efficiency\n\n- The key to improving code running speed when programming is to use good profilers.\n\n### Time\n\n- For a programming language to become popular, the last hurdle is to withstand the test of time. No one wants to program in a language that will be eliminated.\n\n### Redesign\n\n- As long as \"redesign\" can go on repeatedly, it is desirable.\n\n## 15. Design and Research\n\nThe difference between design and research seems to be that the former pursues \"good\", the latter pursues \"new\". Excellent design is not necessarily \"new\", but must be \"good\";\n\n### Interesting Points\n\n- To make excellent design, you must stay close to users, never leaving a step, always adjusting your ideas from user's perspective.\n- Making prototype first, then gradually processing to make finished product. This way is conducive to boosting morale, because it allows you to see the results of work at any time.\n- At any time, **code must be able to run**. If the code you are writing can see running results in an hour, this is like letting you see the reward within reach not far away, you will be motivated and inspired.\n\n## End\n\nRead this book for several weeks, finally finished reading and sorting out. Feel like taking notes in college. At the same time solved many of my confusions. Highly recommend programmers to read it when having time!"} {"title":"Weex Ui Half-Year Open Source Road","date":"2018-03-31","language":"en-US","summary":"Weex Ui was open sourced on September 30 last year. It has been exactly half a year since today. This article intends to share the Weex Ui half-year open source road from 5 parts: origin, positioning, status quo, development, and outlook.","categories":["Share"],"url":"https://tw93.fun/en/2018-03-31/weex-ui-report.html","markdownUrl":"https://tw93.fun/en/2018-03-31/weex-ui-report.md","translation":{"language":"zh-CN","title":"Weex Ui 半年开源之路","url":"https://tw93.fun/2018-03-31/weex-ui-report.html","markdownUrl":"https://tw93.fun/2018-03-31/weex-ui-report.md"},"contentMarkdown":"

\n\n

\n\n> GitHub Address: [github.com/alibaba/weex-ui](https://github.com/alibaba/weex-ui)\n\nWeex Ui was open sourced on September 30 last year. It has been exactly half a year since today. This article intends to share the Weex Ui half-year open source road from 5 parts: **origin, positioning, status quo, development, and outlook**.\n\n### Origin of Weex Ui\n\nWeex Ui originated from an internal Weex upper-layer Ui component library. After running for nearly a year, it was organized, optimized, enriched and qualified then open sourced, hoping to leverage the community to let it develop better and serve more developers.\n\n\n### Positioning of Weex Ui\n\nThe positioning of Weex Ui is **a lightweight, highly interactive, high-performance UI component library for Weex**. Components encapsulate native-level optimizations beneath intuitive Vue APIs, seamlessly supporting Weex on iOS, Android, and mobile web. It also serves as a clean, idiomatic reference for developers new to building on Weex.\n\n[QR code picture here>>>](https://gw.alipayobjects.com/zos/rmsportal/MNIgWQQFnsXFVDgmXLrr.jpeg)\n\n\n\n### Status Quo of Weex Ui\n\n- 7 major categories of components, a total of 32 mature components\n- Github **Star 2552**, Fork 333, Watch 127\n- Monthly download volume **9K/month**, cumulative use **47K** times (including CNPM 2.8K/month and 20K total)\n- Issus 168, Pull Request number is 45, a total of 11 Contributors, cumulative release 30 versions\n- Incomplete statistics of domestic companies use\n\n \n\n- Contributors who submitted code to Weex Ui\n\n \n\n### Development of Weex Ui\n\n \n\nFor more version iterations, see [Weex Ui Upgrade Log](https://alibaba.github.io/weex-ui/#/cn/CHANGELOG)\n\n### Outlook of Weex Ui\n\n- Introduce more **rich interactive** components to make Weex applications More Native\n- Continue to **lighten and simplify** Weex Ui, lowering the barrier to entry for non-frontend engineers\n- Component **performance continuous optimization**, especially low-end machine performance improvement\n- Support component **theme one-click switch**, under implementation\n- Collection of usage Demo organization, including tools, media, management, etc.\n- Ecological exploration, more Weex peripheral construction\n\n### Finally\n\n**The development of Weex Ui cannot be separated from the contribution of the community. Since open source, it has slowly removed internal-specific characteristics and developed towards community.**\n\nHuge thanks to everyone who shared suggestions and contributed code to Weex Ui, especially community contributors [@zwwill](https://github.com/zwwill), [@GJJDD](https://github.com/GJJDD), [@Yanjiie](https://github.com/Yanjiie), [@zweipix](https://github.com/zweipix), and others for their dedication.\n\nI hope more developers will join the Weex Ui community in the future — helping everyone build faster, leave work on time, and make the ecosystem better for all.\n\n> **Please feel free to use and contribute to the development.**\n\n### Other Links\n\n- [Weex Ui Official Website](https://alibaba.github.io/weex-ui/#/)"} {"title":"JS in iOS","date":"2018-03-17","language":"en-US","summary":"A deep dive into how JavaScript interacts with iOS across four areas: why frontend tech alone isn't enough on mobile, JavaScriptCore communication mechanisms, Objective-C Runtime internals, and how to patch native iOS logic dynamically from JS. Written to help frontend and mobile engineers bridge the gap.","categories":["Study"],"url":"https://tw93.fun/en/2018-03-17/js-in-ios.html","markdownUrl":"https://tw93.fun/en/2018-03-17/js-in-ios.md","translation":{"language":"zh-CN","title":"iOS 中的 JS","url":"https://tw93.fun/2018-03-17/js-in-ios.html","markdownUrl":"https://tw93.fun/2018-03-17/js-in-ios.md"},"contentMarkdown":"Recently I've been studying how JavaScript interacts with iOS across four key dimensions: **why frontend tech alone isn't enough on mobile, JavaScriptCore communication mechanisms, Objective-C Runtime internals, and how to dynamically adjust native iOS logic via JS**. My goal is to help both frontend and native engineers understand cross-platform foundations, and see what powerful capabilities unlock when combining both worlds.\n\n## Why Frontend Tech Alone Isn't Enough on Mobile\n\nSince graduating and building software across mobile web, React Native, Weex, and native iOS, one conclusion became increasingly clear:\n\n> **Relying solely on frontend web technologies cannot deliver the performance and experience that modern mobile users expect.**\n\n### Why does a pure web approach fall short on mobile?\n\nWeb developers know this pain intimately: try implementing native-feeling image uploads or camera interactions purely in mobile Safari, and performance immediately suffers. But if a native developer tells you, \"I wired up a bridge — just call `Bridge.uploadImg()` to invoke native photo selection,\" you breathe a sigh of relief and get back to building.\n\nSimilarly, switching an in-app webview from UIWebView to WKWebView does more for smoothness and scrolling performance than weeks spent fine-tuning CSS touch scrolling.\n\n### How do modern frontend engineers tackle mobile requirements?\n\nThey leverage native mobile capabilities: using frameworks like **Weex** or **React Native** to render native UI components, wrapping web applications into **Mini Programs**, or using **hybrid container optimizations** (offline caching, preheating, and native bridges) to extend web apps with native power.\n\nHere, **the bridge is the connective tissue** that unifies the web and native stacks:\n\n\n\nNext, give the above solution through **JSCore principle and communication mechanism** section.\n\n## JSCore Principle and Communication Mechanism\n\n### What is JSCore?\n\nEveryone knows that browser kernel modules are mainly composed of **rendering engine** and **JS engine**. JSCore is a kind of JS engine.\n\nApple encapsulated WebKit's JS engine with OC, **providing a set of JS running environment and bridge for conversion between Native and JS data types, commonly used for mutual calling between OC and JS code**. This also means it can execute JS independently from rendering.\n\nJSCore mainly includes the following classes, protocols, class structures:\n\n\n\n### How does JSCore run?\n\nCan understand how each module runs through the following JSCore framework structure diagram and the above description.\n\n\n\nFrom the above figure we can see such a process:\n\nIn Native applications, we can open multiple threads to asynchronously execute our different requirements, which means we can create multiple JSVirtualMachine virtual machines (runtime resource providers), independent of each other without affecting, so we **can execute different JS tasks in parallel**.\n\nIn a JSVirtualMachine, multiple JSContexts (JS execution environment context) can also be associated, and data transfer communication with Native is carried out through JSValue (value object). At the same time, through JSExport (protocol), methods and properties of classes in Native that comply with this parsing can be converted to JS interfaces for calling.\n\n### JS and OC Data Type Interchange\n\nFrom the previous section, we know JSValue can be used for barrier-free data conversion between JS and OC. Main principle is JSValue provides the following methods to facilitate conversion of various types for both sides.\n\n \n\n### Execute JS code in iOS\n\nWe can execute a piece of JS script in JSCore through `evaluateScript`. Utilizing this feature we can do some **multi-end logic unification** things.\n\n```objective-c\n // Execute a piece of JavaScript script\n -(JSValue *)evaluateScript:(NSString*)script;\n```\n\nFor example, in business, 3 ends (iOS, Android, H5) have a fairly complex but same principle price calculation logic. General practice is 3 ends write a set with their own languages. Doing so is not only troublesome, low efficiency but also logic is not necessarily unified. Meanwhile using OC to implement complex calculation logic is not as flexible and efficient as JS.\n\nHere we can use **Execute JS code** feature, extract this logic into a JS method, just pass in specific input parameters, directly return price. In this way, 3 ends can use this logic at the same time, and can also put it to remote end for dynamic update and maintenance.\n\nRoughly implemented like this:\n\n```objective-c\n // Execute JS in iOS\n JSContext *jsContext = [[JSContext alloc] init];\n [jsContext evaluateScript:@\"var num = 500\"];\n [jsContext evaluateScript:@\"var computePrice = function(value){ return value * 2 }\"];\nJSValue*value = [jsContext evaluateScript:@\"computePrice(num)\"];\n int intVal = [value toInt32];\n NSLog(@\"Calculation result is %d\", intVal);\n```\n\nOperation result is:\n\n```bash\n2018-03-16 20:20:28.006282+0800 JSCoreDemo[4858:196086] ========Execute JS code in iOS========\n2018-03-16 20:20:28.006517+0800 JSCoreDemo[4858:196086] Calculation result is 1000\n```\n\nI think it can also be used in **regular validation**, **animation functions**, **3D rendering modeling** and other data calculation aspects.\n\n### Call JS method in iOS\n\nAfter talking about executing JS code in iOS, next introduce how to call JS methods in H5 in iOS.\n\nFor example, we have a global method called nativeCallJS in H5. We can get this method through execution environment context `jsContext[@\"nativeCallJS\"]` and call it, similar to this:\n\n```html\n // Html has a JS global method\n \n```\n\n```objective-c\n // Run JS method in iOS\n JSContext *jsContext = [webView valueForKeyPath:@\"documentView.webView.mainFrame.javaScriptContext\"];\n JSValue *jsMethod = jsContext[@\"nativeCallJS\"];\n [jsMethod callWithArguments:@[ @\"Hello JS, I am iOS\" ]];\n```\n\nFinally our running result can see Native executed H5 Alter layer:\n\n\n\nUtilizing this feature we can **let iOS get some H5 information** to process something he wants to process, for example, first expose information in global, obtain **version number used, running environment information, terminal active processing logic (clear cache, control running)** and other things by calling method.\n\n### Call iOS method in JS\n\nFor frontend engineers, this is by far the most common use case: invoking native device capabilities via JS to fill the gaps in mobile web views.\n\nHere need to combine with webview related feature `@\"documentView.webView.mainFrame.javaScriptContext\"`, pass the method called by H5 to JSCore context with Block named `jsCallNative(method name)`.\n\nFor example, a button click callback in our H5 is to call a client method, and output input parameters in the method, roughly implemented like this:\n\n```html\n // Html button click calls an OC method\n \n```\n\n```objective-c\n //Block passed to JavaScript context named \"jsCallNative\"\n JSContext *jsContext = [webView valueForKeyPath:\n @\"documentView.webView.mainFrame.javaScriptContext\"];\n jsContext[@\"jsCallNative\"] = ^() {\nNSArray*args = [JSContext currentArguments];\n for (JSValue *obj in args) {\n NSLog(@\"%@\", obj);\n }\n };\n```\n\nFinal output is like this:\n\n```bash\n2018-03-16 20:51:25.590749+0800 JSCoreDemo[4970:219245] ========Call iOS method in JS========\n2018-03-16 20:51:25.591155+0800 JSCoreDemo[4970:219245] Hello iOS\n2018-03-16 20:51:25.591370+0800 JSCoreDemo[4970:219245] I am JS\n```\n\nThis feature truly **allows H5 to enjoy many terminal features**, such as **Native way jump, Native underlying capabilities (vibration, recording, photographing), scanning code, getting device information, sharing, setting navigation bar, calling Native encapsulated components** etc. Here you can relate to Hybrid development mode.\n\n### Exposing Native Methods and Properties via JSExport\n \n This capability may not be widely known among web developers, but for native iOS developers, it's remarkably powerful.\n \n JSExport lets you expose native Objective-C object properties and methods directly into the JS execution context, making them behave just like native JS objects.\n\nFor example, we have a Person class in OC, containing two properties and a method. Here expose `fullName` method using JSExport protocol, so it can be directly called in JS.\n\n```objective-c\n @protocol PersonProtocol \n -(NSString *)fullName;\n @end\n\n @interface Person : NSObject \n @property (nonatomic, copy) NSString *firstName;\n@property (nonatomic, copy) NSString*lastName;\n @end\n\n @implementation Person\n @synthesize firstName, lastName;\n (NSString *)fullName {\n return [NSString stringWithFormat:@\"%@ %@\", self.firstName, self.lastName];\n }\n @end\n```\n\n```objective-c\n // Expose iOS method properties to JS via JSExport\n Person *person = [[Person alloc] init];\n jsContext[@\"p\"] = person;\n person.firstName = @\"Fei\";\n person.lastName = @\"Zhu\";\n NSLog(@\"========Expose iOS method properties to JS via JSExport========\");\n [jsContext evaluateScript:@\"log(p.fullName());\"];\n [jsContext evaluateScript:@\"log(p.firstName);\"];\n```\n\nFinal running result is:\n\n```bash\n 2018-03-16 20:51:17.437688+0800 JSCoreDemo[4970:219193] ========Expose iOS method properties to JS via JSExport========\n 2018-03-16 20:51:17.438100+0800 JSCoreDemo[4970:219193] Fei Zhu\n 2018-03-16 20:51:17.438388+0800 JSCoreDemo[4970:219193] undefined\n```\n\nWhy is `p.firstName` `undefined` after running? Because it is not exposed to Native environment here, so it cannot be obtained.\n\nHere we can utilize more on programming convenience, allowing OC and JS to call each other directly.\n\n### Handle JS exception in iOS\n\nSlightly mature companies will have exception monitoring systems for front-end pages. Finding JS execution exceptions can directly notify development to prevent online accidents.\n\n**Through `exceptionHandler` in JSCore can solve this problem very well. When JS runs abnormally, it will callback Block set in exceptionHandler of JSContext. In this way, we can upload our errors to monitoring platform in Block callback.**\n\nFor example this example, I run a function returning `a+1`. Usually we can see error `Can't find variable: a` in Chrome console. Running here will be same:\n\n```objective-c\n // When JavaScript runtime exception occurs\n // Will callback Block set in exceptionHandler of JSContext\n JSContext *jsContext = [[JSContext alloc] init];\n\n jsContext.exceptionHandler = ^(JSContext *context, JSValue*exception) {\n NSLog(@\"JS Error: %@\", exception);\n };\n\n [jsContext evaluateScript:@\"(function errTest(){ return a+1; })();\"];\n```\n\nFinally output error is:\n\n```bash\n2018-03-17 11:28:07.248778+0800 JSCoreDemo[15007:632219] ========Handle JS exception in iOS========\n2018-03-17 11:28:07.252255+0800 JSCoreDemo[15007:632219] JS Error: ReferenceError: Can't find variable: a\n```\n\n### Bidirectional Communication Between JS and Native\n\nRecently I submitted a PR to Weex: [More enhancements for the component](https://github.com/apache/incubator-weex/pull/1047). Using the approach outlined above, it implements the W3C MessageEvent spec to allow the `` component and Weex host environment to exchange messages seamlessly, rendering passed HTML strings via `loadHTMLString`.\n\nHere is the implementation in action:\n\n
\n\nSpecific ideas visible in [[WEEX-233][iOS]](https://github.com/apache/incubator-weex/pull/1047).\n\n## JSPatch\n\nLet us think deeper about whether the above idea can be extended again. Can we directly interfere with iOS code running via JS? The answer is yes. Below I want to organize my understanding of JSPatch.\n\n### Suppose iOS wants to fix bug without releasing version\n\nSuppose online APP has a piece of code with bug causing crash. Maybe Native crash will be much more serious than H5 problem. The former can release immediately, the latter may need to be modified and submitted to Apple Store for several days to go online, and then update rate may not go up, very troublesome.\n\nHere can use JSPatch similar solution, issue a piece of code to overwrite original problematic method, so this bug can be fixed quickly.\n\nCan see the above process through a simple example.\n\nWrote a blue `Hello World` with OC. We can issue a piece of JS code to change original blue font to red and modify text. After deleting JS code issuing code, can restore original blue `Hello World`.\n\n
Before JS IssueAfter JS Issue After JS Deletion
\n\nMain code roughly as follows:\n\n```objective-c\n // A code showing blue Hello World\n @implementation ViewController\n - (void)viewDidLoad {\n [super viewDidLoad];\n [self simpleTest];\n }\n - (void)simpleTest {\n self.label.text = @\"Hello World\";\n self.label.textColor = [UIColor blueColor];\n }\n @end\n```\n\n```javascript\n // A piece of JS overwrite code complying with JSPatch rules\n require('UIColor');\n defineClass('ViewController', { simpleTest : function() {\n self.label().setText(\"Your blue Hello World was changed to red by me\");\n\n var red = UIColor.redColor();\n self.label().setTextColor(red);\n },\n })\n```\n\nHow is this done here? First need to introduce JSPatch:\n\n> JSPatch is an iOS dynamic update framework. By introducing JSCore, can use JS to call any native interface, can dynamically update modules for projects, replace native code to dynamically fix Bug.\n\nThat is JS passes string to OC, OC calls and replaces OC method via Runtime interface.\n\nWhy can call any native interface via JS? First can understand OC underlying Runtime principle.\n\n### Runtime\n\nAbout 95% of OC language is C related writing method. Why didn't Apple directly use C to write iOS at that time? One big reason is OC dynamic nature. Have a very powerful Runtime (**A set of C language API, bottom layer implemented based on it**). Core is **Message Dispatch**. Runtime will **make different reactions according to whether message receiver can respond to the message**.\n\nMaybe above is obscure. Simply put **OC method implementation and calling pointer relationship are decided at runtime, not compile time**. In this way, we can do something at runtime to change original implementation, achieving purpose of hot fix.\n\nOC method calling is not like JS language, directly `array.push(foo)` function call is ok. It is called through message mechanism. For example following insert `foo` into 5th place in array:\n\n```objective-c\n [array insertObject:foo atIndex:5];\n```\n\nAt bottom layer it is more obscure than this implementation. It sends message with selector through `objc_msgSend` method:\n\n```objective-c\n objc_msgSend(array, @selector(insertObject:atIndex:), foo, 5);\n```\n\nSend message to object at runtime, how is message mapped to method?\n\nSimply put, an object's class saves method list, is a dictionary, key is selectors, IMPs are value. An IMP points to implementation of method in memory. Relationship between selector and IMP is decided at runtime, not compile time.\n\n```objective-c\n\n- (id)doSomethingWithInt:(int)aInt{}\n id doSomethingWithInt(id self, SEL _cmd, int aInt){}\n```\n\nBy looking at [Runtime Source Code](https://opensource.apple.com/tarballs/objc4/), found following commonly used methods\n\n\n\nThrough above methods can do many unexpected things, such as **dynamic variable control, dynamically adding methods to an object, can forward message to desired object, even can dynamically exchange implementation of two methods**.\n\n### JSPatch && Runtime\n\nPrecisely because of OC language dynamic nature, all method calls/class generation above are carried out at runtime via OC Runtime. Can get class and method via string of class name and method name, and instantiate and call:\n\n```objective-c\n Class class = NSClassFromString(\"UIViewController\");\n id viewController = [[class alloc] init];\n SEL selector = NSSelectorFromString(\"viewDidLoad\");\n [viewController performSelector:selector];\n```\n\nCan also **replace** a class method with new implementation:\n\n```objective-c\n static void newViewDidLoad(id slf, SEL sel) {}\n class_replaceMethod(class, selector, newViewDidLoad, @\"\");\n```\n\nCan also register a new class, **add method** for class:\n\n```objective-c\n Class cls = objc_allocateClassPair(superCls, \"JPObject\", 0);\n objc_registerClassPair(cls);\n class_addMethod(cls, selector, implement, typedesc);\n```\n\nJSPatch utilizes exactly these good features to implement its hot fix function.\n\n### How JS calls OC in JSPatch\n\nHere how JS in JSPatch is connected with arbitrary modification of OC code? Principle roughly as follows:\n\n1. JSPatch provides `require` to create a matching proxy variable on the JS global scope. This proxy object holds `__clsName` storing the native class name. After calling `require(\"UIView\")`, you can invoke methods directly on `UIView`:\n\n```javascript\n UIView = require(\"UIView\");\n\n var _require = function(clsName) {\n if (!global[clsName]) {\n global[clsName] = {__clsName: clsName}\n }\n return global[clsName]\n }\n```\n\n1. Before JSCore execution, OC method calls are all completed through **adding Object(JS) prototype method \\_\\_c(methodName)**. If called directly, need JS to traverse all methods of current class, also loop to find parent class methods until top layer, undoubtedly very time consuming. Through uniqueness of `__c()` meta function, can forward to a specified function to execute every time it is called, very elegant.\n\n\n\n```javascript\n Object.prototype.__c = function(methodName) {\n return function(){\n var args = Array.prototype.slice.call(arguments)\n return _methodFunc(self.__obj, self.__clsName, methodName,\n args, self.__isSuper)\n }\n }\n```\n\n1. After handling JS interface problem, next only need to leverage previous JSCore knowledge to achieve message mutual transmission between JS and OC. That is **bridge function established via JSContext in \\_c function, call corresponding method using Runtime interface to complete call**:\n\n* Forwarding in JS\n\n```javascript\n var _methodFunc = function(instance, clsName, methodName, args, isSuper) {\n ....\nvar ret =_OC_callC(clsName, selectorName, args)\n return_formatOCToJS(ret)\n }\n```\n\n* Processing in OC\n\n```objective-c\n context[@\"_OC_callC\"] = ^id(NSString *className, NSString*selectorName, JSValue *arguments) {\n return callSelector(className, selectorName, arguments, nil, NO);\n };\n```\n\n### Reflections\n\nThis outlines the core mechanics behind dynamically inspecting and patching Objective-C runtime behavior via JavaScript. Even though Apple largely prohibited live JS hotpatching in production apps, the underlying architecture connecting JS to native internals is brilliant.\n\nThis post grew out of my internal tech talk [\"JS in iOS\"](http://p.tb.cn/rmsportal_7819__E3_80_90_E4_BE_91_E5_A4_95_E3_80_91iOS_20_E4_B8_AD_E7_9A_84JS.pdf){:target=\"_blank\"}. I wrote it up as a practical guide for anyone interested in cross-platform engineering, keeping explanations accessible whether your background is primarily web frontend or native iOS. You can also check out the [Demo Source Code on GitHub](https://github.com/tw93/iOSDemo){:target=\"_blank\"}.\n\nAs I'm still deepening my iOS foundation, feedback and discussions are always welcome."} {"title":"What Mentality Should Be Used to Treat Open Source?","date":"2018-02-11","language":"en-US","summary":"A Q&A record on Zhihu, `What mentality should be used to treat open source?`","categories":["Thought"],"url":"https://tw93.fun/en/2018-02-11/open-source.html","markdownUrl":"https://tw93.fun/en/2018-02-11/open-source.md","translation":{"language":"zh-CN","title":"该以怎样的心态对待开源？","url":"https://tw93.fun/2018-02-11/open-source.html","markdownUrl":"https://tw93.fun/2018-02-11/open-source.md"},"contentMarkdown":"A Q&A record on Zhihu, [What mentality should be used to treat open source?](https://www.zhihu.com/question/266954088){:target=\"_blank\"}\n\nThere are two questions in the topic. First is what mentality should be maintained when using other people's open source projects? Second is what mentality should be maintained when open sourcing a product yourself?\n\n## What mentality should be maintained when using other people's open source projects?\n\n#### 1: Curiosity and Learning Mentality\n\nThis mentality is mainly treating libraries that are **not** needed by project to solve difficult problems at hand, but things discovered accidentally. Often can see surprising things when browsing Github trending.\n\nEncountering this kind, generally Clone to local to play following Readme guidance. If like it, will go to Star (can be understood as appreciation for author's work). At the same time look at code, think if make such a thing myself, how would I do it. It is also very good to submit a PR conveniently, or whether this idea can be used in my future business work.\n\n#### 2: Cooperation and Gratitude Mentality\n\nThis mentality is more treating things related to own projects, such as Weex, Webpack etc. If it develops well, development experience for oneself will be much better. When using should be clear about one point: **The relationship between users and maintainers of open source projects is not Party A and Party B. At the same time maintainers are not customer service. When encountering problems, or unhappy, should hold the mentality of \"collaborating together to solve this problem\" more**. Any suggestions or places unhappy with use, or feel it is better to do this way, describe clearly and communicate to solve through issue or email, give maintainers more input, so as to better promote its development.\n\n## What mentality should be maintained when open sourcing a product yourself?\n\nHere intend to share some things and mentality of [Weex Ui](https://github.com/alibaba/weex-ui){:target=\"_blank\"} open source.\n\n\n\n#### 1: Open sourced things are useful to developers\n\nMany times open source is not open sourcing for the sake of open source, more is that this thing is really useful to developers, **can improve development efficiency, more implementation input, summary of best practices**. For users, can write better code, get off work earlier. Thinking of being on Github trending in the week of open source without extensive promotion, quietly very excited.\n\n![](https://gw.alipayobjects.com/zos/rmsportal/uCCNieRPMCzohonSFGGI.jpg){:class=\"img-zoom\"}\n\n#### 2: Sincere Like Mentality\n\nOwn sincere like and enthusiasm, treating it as own **work** to do will be much better than task arrangement.\n\n![](https://img.alicdn.com/tfs/TB1zUTTX1SSBuNjy0FlXXbBpVXa-1920-1080.png){:class=\"img-zoom\"}\n\nLater open source development is mainly co-constructing weex-toolkit to make it support Weex Ui better, completion of missing components + enhancement of existing components, continue to expand boundaries, introduce more rich interactive experience + accessibility optimization of components, easy usage + detailed Chinese and English documents etc. work.\n\n#### 3: Open Sharing Mentality\n\nOften, it's only when a project is widely adopted that real feedback and constructive critique roll in — drawing in more talented engineers with great ideas to push things forward. Weex Ui has already attracted contributors from NetEase, Tencent, Qianhe, Borui Cube, and beyond. My hope is for Weex Ui to belong to the entire community, not just any single company.\n\nFor an open source work, there are many things can be done, including component bugfix, function enhancement and new addition, document correction, translation and organization, and any suggestion, idea exchange, including maintenance of community, group questions, issue answers etc. things can all be done. Happily using while promoting its development is the best.\n\n**Please feel free to use and contribute to the development.**\n\n> Only the combination of Great Vision and Bad Code creates Great Communities !\n\nAbove, is some of my understanding of open source. Maybe didn't say too clearly. Welcome to discuss together."} {"title":"iOS Primer for Frontend Engineers (Part 1)","date":"2018-02-08","language":"en-US","summary":"Around Double 11 last year, I began diving into iOS to diagnose several Weex performance bottlenecks, and recently started contributing to iOS feature development. Taking this opportunity to document fundamental iOS concepts for my own reference, and to help fellow frontend engineers make sense of native iOS code and core mobile architecture.","categories":["Study"],"url":"https://tw93.fun/en/2018-02-08/ios-1.html","markdownUrl":"https://tw93.fun/en/2018-02-08/ios-1.md","translation":{"language":"zh-CN","title":"写给前端看的 iOS 梳理 (上)","url":"https://tw93.fun/2018-02-07/ios-1.html","markdownUrl":"https://tw93.fun/2018-02-07/ios-1.md"},"contentMarkdown":"![](https://img.alicdn.com/tfs/TB15vVXX7yWBuNjy0FpXXassXXa-4032-3024.jpg){:class=\"img-zoom\"}\n\n_Photographed at Hangzhou West Lake Apple Store on 20161020_\n\n## Preface\n\nAround Double 11 last year, I began diving into iOS to diagnose several Weex performance bottlenecks, and recently started contributing to iOS feature development. Taking this opportunity to document fundamental iOS concepts **for my own reference, and as a primer to help fellow frontend engineers read and understand native iOS code** when collaborating across mobile stacks.\n\n## Outline\n\n![](https://img.alicdn.com/tfs/TB1qX7SXHSYBuNjSspfXXcZCpXa-2148-1558.png){:class=\"img-zoom\"}\n\n_Part 1 covers common iOS project file types and essential Foundation framework classes. Part 2 and Part 3 cover runtime internals and project architecture._\n\n## File Format\n\n- **.h**: Header file also called interface file, providing externally accessible interface, containing declaration of class, method and property, equivalent to **User Manual** of class\n- **.m**: Implementation file, used to implement methods declared in `.h`, equivalent to **Engineering Details** of class\n- **Podflie**: Package management file, used to define third-party libraries needed by project, analogous to `package.json`\n- **Podflie.lock**: Dependency library lock file, records every installed version of pod needed to be installed, facilitating team collaboration package unification, analogous to `package-lock.json`\n- **.xib**: Visualization file, a lightweight file used to describe **Local Interface**\n- **.storyboard**: Interface layout file, carrying view controls corresponding to UIView\n- **.pch**: Precompiled header file, compile code that \"won't be modified often\" in a project in advance and put into pch, used to store **Public Macros**, store **Public Header Files**, also can **Manage Log Output**\n- **.plist**: Property list file, a file used to store serialized objects, usually used to **Store User Settings** or some bundled information, also one of data persistence solutions\n- **.lproj**: Multi-language localization folder, i.e. define a set of resources separately for each language, containing images, text, Storyboard, Xib files\n- **.xcassets**: Image resource file, used to store image resources\n- **.xcodeproj**: Xcode project file, storing various configuration parameters of Xcode project\n- **.xcworkspace**: Xcode project file, new file generated after using pod install, can see project files and pods dependency packages at the same time after opening\n\n## Foundation Framework\n\n### Brief Introduction\n\nFirst introduce Cocoa. Cocoa is a set of framework and runtime support in OS X and iOS (Cocoa Touch), i.e. API application program interface, can be analogous to MFC in VC.\n\nCocoa among which most important are **UIKit (AppKit for OSX)** and **Foundation**. Positions of two frameworks in system as shown below, meanwhile can see positions of common frameworks.\n\n\n\nAmong them UIKit is mainly used for iOS interface construction, detailed later.\n\nFoundation framework provides basic layer functions for our framework and App development, used to access basic data types, collections and operating system services, including follows:\n\n- **Data Storage and Persistence**: NSArray, NSDictionary and NSSet provide storage for OC objects of any class\n- **Text and String Processing**: NSCharacterSet used for various string operations in NSString and NSScanner classes\n- **File Processing**: NSFileManager class provides large amount of methods for file operation checking\n- **Date and Time**: NSDate, NSTimeZone and NSCalendar classes\n- **URL Operation**: Provide a set of classes and protocols to handle URL access\n- **Exception Handling**: NSException class\n\nFoundation can be imagined as a native public Util library in JS, But no...\n\n### Before Start\n\nWhat does `@` do in OC?\n\n- Usually a `@` is added before string, used to convert a C language string to string object NSString in OC\n- `@` symbol. Most keywords in OC start with `@`, such as `@interface`, `@implementation`, `@end` `@class` etc.\n\nWhat is NS prefix before many classes?\n\n- **Namespace is not supported in OC**, so can only avoid naming conflict by adding prefix this earthy method. So often use 3 uppercase letters (2 occupied by Apple), can distinguish by e.g. developer name, company name or method name etc.\n- NS stands for NeXTSTEP, operating system developed for NeXT company. NeXT is company name created by Jobs when leaving Apple in 1985. Later after being acquired back, many achievements were absorbed into OSX foundation\n- Similar ones are, CF == Core Foundation; CG == CoreGraphics.frameworks; CA == CoreAnimation.frameworks; UI == UIKit etc. representation\n\n### Object Mutability\n\nClasses in OC can be divided into **mutable** class and **immutable** class. Here immutable refers to **storage space occupied by string in memory is fixed, and stored content cannot change**, conversely mutable means occupied space can be unfixed, content can be modified; this is very different from flexible JS, but I prefer to distinguish data types into mutable and immutable, also convenient for subsequent maintenance and extension.\n\nFor classes determined not to change, it only possesses due attribute methods. Mutable classes inherit original immutable classes, then add mutable method attributes to realize mutability.\n\nMutable class is subclass of immutable class, meanwhile **instance objects of all mutable classes can be used as instance objects of immutable classes**.\n\n### NSString\n\nUse NSString to represent string in OC. Mutable NSMutableString inherits immutable NSString class, like a string linked list, can perform **Add Delete Modify** operations on it.\n\n![](https://img.alicdn.com/tfs/TB146QeXGmWBuNjy1XaXXXCbXXa-2128-1834.png){:class=\"img-zoom\"}\n\n### NSArray\n\nUse NSArray to represent array class in OC. Here need to note it is not like JS array can store any type. Only OC objects can be stored in NSArray, meanwhile also immutable. If need to change array, need to use its subclass NSMutableArray.\n\n![](https://img.alicdn.com/tfs/TB1DB3lXKuSBuNjy1XcXXcYjFXa-1702-2312.png){:class=\"img-zoom\"}\n\nArray created by `arrayWithObjects` way remember to add `nil` at the last item, so for convenience more recommend directly use `@[@\"lnj\", @\"lmj\", @\"jjj\"]` way to create, but because generated is immutable array, so do not create like this in NSMutableArray.\n\nMany array operation methods are roughly same compared with JS, but NSMutableArray provides some richer methods than JS, including swap two element positions this kind of method needing to write by self. That is often when writing can check document first to see if there is this method, often can find from inside.\n\n### NSDictionary\n\nFrontend developers encountering the word \"Dictionary\" for the first time might find it unfamiliar — think of it as an Object in JS or a Map in Java. Data is stored as key-value pairs.\n\nNSDictionary is an immutable dictionary class. It is read-only after creation; to modify keys and values dynamically, use NSMutableDictionary instead.\n\n![](https://img.alicdn.com/tfs/TB1XJwgXMmTBuNjy1XbXXaMrVXa-1738-926.png){:class=\"img-zoom\"}\n\n### NSDate\n\nNSDate can be used to represent time, used to perform some common date time processing. Its usage is also very similar to JS Date. `[NSDate date]` returns current time. But Foundation processing on formatting date time is much more elegant than js, directly call its built-in method is ok.\n\nCooperating with **NSDateFormatter class can format date**. `stringFromDate` used for NSDate to NSString, `dateFromString` used for NSString to NSData:\n\n```objective-c\n//NSDate to NSString\nNSDate *now = [NSDate date];\nNSDateFormatter*formatter = [[NSDateFormatter alloc] init];\nformatter.dateFormat = @\"yyyy-MM-dd HH:mm:ss\";\nNSString *str = [formatter stringFromDate:now];\nNSLog(@\"%@\", str);\n\n// NSString to NS\bDate\nNSString *str = @\"2018-02-08 11:53:12\";\nNSDateFormatter*formatter = [[NSDateFormatter alloc] init];\nformatter.dateFormat = @\"yyyy-MM-dd HH:mm:ss\";\nNSDate *date = [formatter dateFromString:str];\nNSLog(@\"%@\", date);\n```\n\nIf want to process more complex content on time date, also **can leverage NSCalendar class enrich our processing**:\n\n```objective-c\nNSDate *date = [NSDate date];\nNSCalendar*calendar = [NSCalendar currentCalendar];\n// Utilize calendar object to get year month day hour minute second\nNSCalendarUnit type = NSCalendarUnitYear\n | NSCalendarUnitMonth\n | NSCalendarUnitDay\n | NSCalendarUnitHour\n | NSCalendarUnitMinute\n | NSCalendarUnitSecond;\n// cmps includes year, month, day, hour, minute, second attributes\nNSDateComponents *cmps = [calendar components:type fromDate:date];\n```\n\nCompare date, can directly use following method:\n\n```objective-c\n\n- (NSDateComponents *)components:(NSCalendarUnit)unitFlags\nfromDate:(NSDate*)startingDate\n toDate:(NSDate *)resultDate\n options:(NSCalendarOptions)opts;\n```\n\nFrom above, many methods in OC are very very long, and also express meaning represented by each parameter, won't appear error correspondence situation.\n\n### NSURL\n\nWriting front-end for long will slowly feel URL is an online link H5 address. Actually not. **URL (Uniform Resource Locator) Chinese meaning is uniform resource locator. Besides http protocol, there are `https/ftp/file` protocols used to access a resource**.\n\nIn OC, when operating URL should use dedicated NSURL class, and **not recommend treating URL as string to manual parse**.\n\n![](https://img.alicdn.com/tfs/TB1kV1zX_tYBeNjy1XdXXXXyVXa-1634-1116.png){:class=\"img-zoom\"}\n\nWith subsequent upgrade, many file input output places in OS also started to use NSURL. That is slowly treating network as part of OS.\n\n### NSNumber / NSValue / NSNull Wrapper Classes\n\nCollection classes (`NSArray`, `NSDictionary`, `NSSet`) in Foundation can only hold objects. Coming from JavaScript, this can feel restrictive at first. To store primitive types like `int`, `float`, `double`, or `BOOL`, you need to box them into Objective-C objects using wrapper classes like `NSNumber`:\n\n```objective-c\n// Directly add @ in front can create a NSNumber object type\n@10;\n@10.5;\n@YES;\n@(num);\n\n// NSNumber class extract basic type\n\n- (char)charValue;\n- (int)intValue;\n- (double)doubleValue;\n- (BOOL)boolValue;\n```\n\nBut for complex data types like structure, pointer, NSNumber also cannot wrap. Here need to use NSValue class. It is parent class of NSNumber, can wrap any type into object.\n\n```objective-c\n// Structure wrapper, e.g. NSPoint, NSSize, NSRect\n\n- (NSValue *)valueWithPoint:(NSPoint)point;\n//Extract previously wrapped structure from NSValue object\n- (NSPoint)pointValue;\n```\n\n**Cannot put `nil` into array dictionary above by yourself**, because inside has meaning of `end`. But sometimes we indeed need a special object to represent null value. Here need NSNULL. Can define via class method `+(NSNull *)null`. Meanwhile can judge whether it is NSNull via `if(obj==[NSNull null])`.\n\nIn actual development rarely use NSNull, and generally habit won't judge this separately (default everyone doesn't use), so using it will also be very dangerous (mostly use nil, nil can receive any message, but NSNull can't, difference between two features may cause crash).\n\n## Summary\n\nThrough above article, at most can only let everyone have some understanding of OC programming, can't talk about depth. More hope front-end deep understanding and optimization for H5/Weex don't limit to the thinnest layer on top. Can completely connect to underlying loading, rendering, image library, network library etc. to optimize.\n\nFrom language level, OC and JS are quite interesting. Variable/method naming styles are exactly opposite. Apple encourages developers program naming try to use full English name and as detailed as possible. Through seeing method and variable know what it does. Reading well written iOS is like reading prose. For example **-(NSArray \\*) componentsSeparatedByString:(NSString )separator;** split string. In JS directly solved through str.split(). More front-end developers accustomed to short naming, because need download from network. Although compression tool will do, but everyone also accustomed to short naming to represent.\nDue to compiled language reason, many errors in writing OC process can be found in compilation process. Meanwhile running speed is fast. Also Apple did many things for developers, including engineering system. So actually writing iOS has less room to play than front-end; conversely JS is interpreted, performance relies more on engine. Plus language dynamic, writing is also cool. Many strange tricks can be used. Plus development of Node, letting it do many interesting things.\n\n**Each has advantages. Like Web's speed and openness, also love iOS's elegant experience and unification**."} {"title":"Web Computer Graphics (Part 1)","date":"2017-04-21","language":"en-US","summary":"Web front-end technologies related to graphics are roughly CSS3 animation transformation, SVG, Canvas, WebGL. However, front-end engineers mostly only stay at the upper-level API operation aspect. They may not know much about the principles of graphics, such as GPU, three-dimensional space, lighting, texture, hierarchical models. After studying the content related to SVG, I have some interest in some underlying technologies. Plus this piece belongs to a blank area, so I spent a few days learning graphics basically and recorded it here ...","categories":["Study"],"url":"https://tw93.fun/en/2017-04-21/web-and-cg.html","markdownUrl":"https://tw93.fun/en/2017-04-21/web-and-cg.md","translation":{"language":"zh-CN","title":"Web 计算机图形学(上)","url":"https://tw93.fun/2017-04-21/web-and-cg.html","markdownUrl":"https://tw93.fun/2017-04-21/web-and-cg.md"},"contentMarkdown":"## Preface\n\nAnswer from vczh to a computer graphics question:\n\n> Programmer's three major romances: operating system, graphics, compilation principle. Learning them is to broaden your horizons. These are not courses that you will be doomed if you don't learn, but if you want to become a master, you have to learn =\\_,=\n\nWeb front-end technologies related to graphics are roughly CSS3 animation transformation, SVG, Canvas, WebGL. However, front-end engineers mostly only stay at the upper-level API operation aspect. They may not know much about the principles of graphics, such as GPU, image representation, image geometric transformation principles, texture, hierarchical models, etc.\n\nAfter sorting out [SVG New Driver's Guide](https://zhuanlan.zhihu.com/p/25016633), I have some interest in some underlying technologies. Plus this piece belongs to a blank area, so I spent a few days learning graphics basically and recorded it here.\n\nThis article mainly includes the following contents:\n\n![](https://gtms02.alicdn.com/tfs/TB1YPkFQFXXXXcXXXXXXXXXXXXX-1492-974.png)\n\n## GPU\n\n### Concept and History\n\nGraphics Processing Unit (GPU) is a microprocessor specially designed to run drawing calculation work on personal computers, workstations, game consoles and some mobile devices.\n\nGPU related concepts were proposed in the late 1970s, using monolithic integrated circuits as graphics chips. At that time, they were already used in video, games, and animation, and could quickly synthesize several pictures (only this function...);\n\nBy the late 1980s, GPUs based on digital signal processor chips were developed. Compared with previous generations, they were faster and more functional, but very expensive;\n\nBy 1998, NVIDIA announced the successful development of modern GPU, marking the historic breakthrough of GPU R&D becoming a reality. Modern GPU uses transistors for calculation. In microchips, the transistors used by GPU have far exceeded CPU.\n\nAfter that, generations of modern GPUs were developed, and functions and running speeds were constantly enhanced.\n\n### GPU VS CPU\n\nSomeone may ask, we already have CPU to interpret computer instructions and process data in computer software, why use GPU? To explain this, we can start from the structure of CPU and GPU.\n\n![](https://gtms03.alicdn.com/tfs/TB1R3kTQFXXXXXbXXXXXXXXXXXX-2228-900.jpg)\n\nPicture from NVIDIA CUDA document. Green ones are computing units, orange-red ones are storage units, orange-yellow ones are control units.\n\nFrom the above figure, we can see that GPU is designed based on large throughput, adopting a large number of computing units and ultra-long pipelines, but only very simple control logic and omitting Cache. It has great advantages in computing-intensive programs and easy-to-parallel program running;\n\nCPU is based on low-latency design, has powerful ALU (Arithmetic Logic Unit). Structurally, not only Cache occupies a large amount of space, but also has complex control logic and many optimized circuits. In contrast, computing power is only a small part of CPU.\n\nCPU stands for Central Processing Unit and GPU for Graphics Processing Unit. A common analogy compares the CPU to a university professor and the GPU to a room full of elementary school students: the professor runs rings around schoolchildren on complex logic, but for massive arrays of simple, repetitive calculations, the professor simply can't outpace sheer numbers.\n\nSummarized like this:\n\n![](http://gtms03.alicdn.com/tfs/TB1BW3JQFXXXXa8XXXXXXXXXXXX-1418-764.jpg)\n\n### Hardware Acceleration in Front-end\n\nRegarding hardware acceleration in front-end, it is actually creating a Composited Layer to enable GPU hardware acceleration, rendering via GPU, liberating CPU. Creating Composited Layer specifically has the following methods:\n\n- 3D or perspective transform CSS property.\n-