2025-12-03 16:50:09
Kanban เป็นแนวทางที่ง่ายและปฏิบัติได้จริงในการจัดการกระบวนการและงานที่ยังไม่ได้ทำอย่างเป็นรูปธรรม โดยการย้ายบัตรงานจากคอลัมน์หนึ่งไปอีกคอลัมน์หนึ่ง โตโยต้าได้คิดค้นแนวคิดนี้ขึ้นมาเพื่อติดตามสายการผลิตของพวกเขาในช่วงกลางศตวรรษที่ 20 แต่ในปัจจุบันมันถูกนำไปใช้ในอุตสาหกรรมต่างๆ ได้อย่างมีประสิทธิภาพ รวมถึง Fizzy ซึ่งเป็นรูปแบบดิจิทัลที่สนุกสนานและทันสมัยของเรา
แน่นอนว่าเราไม่ใช่คนแรกที่พยายามทำสิ่งนี้ ไม่ใช่แค่ในด้านการพัฒนาซอฟต์แวร์เท่านั้น ตั้งแต่ช่วงต้นทศวรรษ 2000 มีการเคลื่อนไหวที่ใช้แนวคิด Kanban เพื่อติดตามข้อบกพร่อง ปัญหา และแนวคิดต่างๆ ในอุตสาหกรรมของเรา รวมถึงการพยายามนำแนวคิดนี้ไปใช้ในรูปแบบดิจิทัลมาตั้งแต่หลายปีแล้ว
แต่เช่นเดียวกับซอฟต์แวร์อื่นๆ มากมาย แนวคิดที่ดีสามารถกลายเป็นสิ่งที่ยุ่งยากและไม่สะดวกได้อย่างรวดเร็ว Fizzy คือการรีเซ็ตใหม่ของแนวคิดดั้งเดิม
เราต้องการสิ่งแบบนี้มากขึ้น
ซอฟต์แวร์แทบไม่มีอย่างใดอย่างหนึ่งที่เป็นคำตอบสุดท้ายสำหรับปัญหาที่น่าสนใจเลย แม้ผลิตภัณฑ์ที่เริ่มต้นด้วยความมุ่งมั่นและความเรียบง่ายจะมักมีการสะสมความซับซ้อนและสิ่งที่ไม่จำเป็นมากขึ้นตามเวลาผ่านไป ระบบนิเวศที่แข็งแรงต้องการวงจรการฟื้นฟูที่เกิดขึ้นอย่างสม่ำเสมอ
เราได้รับมิชชันนี้ไว้ในใจไม่เพียงแค่ด้วยการนำแนวคิด Kanban ไปใช้ในรูปแบบที่สนุก สดใส และทันสมัยของ Fizzy แต่ยังรวมถึงการแจกจ่ายด้วย
Fizzy สามารถใช้งานได้โดยเป็นบริการที่เราดำเนินการ ซึ่งคุณจะได้รับบัตร 1,000 ใบฟรี และหลังจากนั้นค่าบริการคือ 20 ดอลลาร์ต่อเดือนสำหรับการใช้งานไม่จำกัด แต่เราได้ให้คุณเข้าถึงทั้งหมดของโค้ดที่อยู่เบื้องหลัง รวมถึงเชิญชวนบุคคลหรือองค์กรที่มีความกระตือรือร้นให้สามารถรันตัวอย่างของตนเองได้โดยไม่มีค่าใช้จ่ายใดๆ ทั้งสิ้น
นี่คือการดำเนินการภายใต้ License O'Saasy ซึ่งเป็นรูปแบบของ License MIT ที่คุณสามารถทำอะไรก็ได้เพียงไม่ได้ร้องเรียน แต่มีข้อยกเว้นที่รักษาสิทธิ์ในการดำเนินการ Fizzy แบบ SaaS ให้กับเราในฐานะผู้สร้าง นั่นหมายความว่า Fizzy ไม่ใช่ Open Source™ อย่างแท้จริง แต่โค้ดยังเปิดเผยอยู่ และคุณสามารถหาได้ที่ GitHub สาธารณะของเรา
นี่คือ Open Source ที่เราใช้ด้วย ดังนั้นฟีเจอร์ใหม่หรือการแก้ไขข้อบกพร่องที่ได้รับการยอมรับใน GitHub จะถูกนำไปใช้ทั้งใน Fizzy SaaS ของเรา และในรูปแบบที่ผู้ใช้สามารถรันได้บนฮาร์ดแวร์ของตนเอง จนถึงตอนนี้เราได้รับการมีส่วนร่วมจากผู้ใช้หลายคนแล้ว!
ในท้ายที่สุด เราตั้งใจที่จะให้ข้อมูลไหลเวียนอย่างอิสระระหว่าง SaaS และการติดตั้งท้องถิ่น คุณจะสามารถสร้างบัญชีได้บนตัวอย่างของคุณเอง และจากนั้นหากคุณต้องการให้เราจัดการแทนคุณ คุณสามารถนำข้อมูลไปใช้ในระบบที่เราจัดการได้ หรือในทางกลับกัน!
ในยุคที่บริษัท SaaS หลายแห่งเกิดขึ้นและหายไป หรือเปลี่ยนทิศทางไปในทางอื่น ฉันคิดว่ามันเป็นการรับประกันที่ดีมากที่ว่าโค้ดแหล่งที่มาถูกเปิดเผยอย่างเสรี และงานที่คุณลงทุนในบัญชี SaaS สามารถนำไปใช้ในตัวอย่างของคุณเองได้ในภายหลัง
ฉันยังเป็นแฟนตัวยงของการดูโค้ดแหล่งที่มา ทั้งแบบดั้งเดิมที่เคยถูกจำกัดไว้เฉพาะส่วนหน้า (และแม้กระทั่งส่วนหน้าก็กำลังถูกทำลายไปเนื่องจากปัญหาของ minimization, transpiling และ bundling) แต่ฉันมักสนใจมากกว่านั้นในการดูว่าสิ่งต่างๆ ถูกสร้างขึ้นอย่างไรในส่วนหลังบ้าน Fizzy ช่วยให้คุณสามารถตรวจสอบทุกส่วนได้อย่างเต็มที่ รวมถึงประวัติการพัฒนาทั้งหมดของผลิตภัณฑ์ ทีละการอัปเดต pull request นั่นคือวิธีที่ดีในการเรียนรู้วิธีการสร้างแอปพลิเคชัน Rails สมัยใหม่!
ดังนั้น กรุณาลองใช้ Fizzy ดูสักหน่อย ไม่ว่าคุณจะทำงานด้านซอฟต์แวร์ ต้องการติดตามข้อบกพร่องและคำขอฟีเจอร์ หรือคุณอยู่ในธุรกิจอื่นที่ต้องการพื้นที่สำหรับปัญหาและแนวคิดเฉพาะของคุณ Fizzy เป็นวิธีที่สดใสและใหม่ในการจัดการทั้งหมด แบบ Kanban อย่างแท้จริง ขอให้คุณสนุกกับการใช้งาน!
---------------
Kanban is a simple, practical approach to visually managing processes and backlogs by moving work cards from one progress column to another. Toyota came up with it to track their production lines back in the middle of the 20th century, but it's since been applied to all sorts of industries with great effect. And Fizzy is our new fun, modern take on it in digital form.
We're certainly not the first to take a swing at this, not even for software development. Since the early 2000s, there's been a movement to use the Kanban concept to track bugs, issues, and ideas in our industry. And countless attempts to digitize the concept over the years.
But as with so much other software, good ideas can grow cumbersome and unwieldy surprisingly quickly. Fizzy is a fresh reset of an old idea.
We need more of that.
Very little software is ever the final word on solving interesting problems. Even products that start out with great promise and simplicity tend to accumulate cruft and complexity over time. A healthy ecosystem needs a recurring cycle of renewal.
We've taken this mission to heart not just with Fizzy's fun, colorful, and modern implementation of the Kanban concept, but also in its distribution.
Fizzy is available as a service we run where you get 1,000 cards for free, and then it's $20/month for unlimited usage. But we're also giving you access to the entire code base, and invite enterprising individuals and companies to run their own instance totally free of charge.
This is done under the O'Saasy License, which is basically the do-whatever-you-want-just-don't-sue MIT License, but with a carve-out that reserves the commercialization rights to run Fizzy as SaaS for us as the creators. That means it's not technically Open Source™, but the source sure is open, and you can find it on our public GitHub repository.
That open source is what we run too. So new features or bugs fixes accepted on GitHub will make it into both our Fizzy SaaS offering and what anyone can run on their own hardware. We've already had a handful of contributions go live like this!
Ultimately, it's our plan to let data flow freely between the SaaS and the local installations. You'll be able to start an account on your own instance, and then, if you'd rather we just run it for you, take that data with you into the managed setup. Or the other way around!
In an age where SaaS companies come and go, pivot one way or the other, I think it's a great reassurance that the source code is freely available, and that any work put into a SaaS account is portable to your own installation later.
I'm also just a huge fan of being able to View Source. Traditionally, that's been reserved to the front end (and even that has been disappearing due to the scourge of minimization, transpiling, and bundling), but I'm usually even more interested in seeing how things are built on the backend. Fizzy allows you full introspection into that. Including the entire history of how the product was built, pull request by pull request. It's a great way to learn how modern Rails applications are put together!
So please give Fizzy a spin. Whether you're working on software, with a need to track those bugs and feature requests, or you're in an entirely different business and need a place for your particular issues and ideas. Fizzy is a fresh, fun way to manage it all, Kanban style. Enjoy!
2025-12-01 16:32:41
黑色星期五通常是电子商务创下单项新纪录的时候。这在Shopify的大部分发展历程中都是如此。因此，该公司会提前数月为“大日子”做准备。然而，尽管有二十多年的经验，你可能会认为事情已经趋于平稳。但你错了。
今年，商家通过Shopify在黑色星期五售出了令人难以置信的62亿美元的商品。这比去年的50亿美元记录增长了25%。在如此庞大的基础上，这种疯狂的增长速度确实令人惊讶。显然，大数定律在这里还没有发挥作用！
如此大量的订单意味着Shopify的庞大系统被推向了极限。后端API的请求峰值达到了每分钟3100万次。数据库每秒处理了5300万次读取和200万次写入。真是疯狂。
正是这种前沿的负载和关键性，使得Shopify成为Rails框架和Ruby编程语言的理想守护者。
很少有公司能像Shopify这样，由一位仍然活跃的程序员领导，拥有辉煌的贡献历史，持续取得巨大成功，不断面对全新的技术挑战，并愿意将所学和所建的一切回馈给开源社区。但这就是Shopify。
归根结底，这一切都源于Shopify是一家由创始人领导的公司。Tobi Lütke不仅在Rails的早期阶段参与了核心团队，而且至今仍然以程序员特有的细致和探索精神掌舵Shopify。最新的Omarchy版本甚至包含了他新推出的Try工具。有多少价值两百亿美元的公司CEO还会像他一样亲自编程呢？
尽管如此，Ruby世界中偶尔仍有一些边缘的担忧，认为Shopify的主导地位令人不安。在Rails中，Shopify雇佣了几乎一半的核心贡献者。在Ruby语言中，他们也有几位核心团队成员。认为这并非一种祝福，显然是不合理的。
如果没有Shopify在框架前沿运行生产环境，我们不会拥有如此经过实战检验的Rails版本。如果没有他们多年来对Ruby核心性能的持续投入，我们也不会拥有YJIT。同样，如果没有他们对Ractors的生产验证，我们也不会看到这一成果。任何编程社区都应该如此幸运地拥有一个Shopify！
当然，我在这里显然有偏见。我不仅与Tobi相识超过二十年，而且还是这家公司的董事会成员。我从社会和经济两个层面都有动力为这家非凡的公司欢呼。但这并不意味着这些话不真实！
Shopify确实是Ruby on Rails的守护者。其基础设施团队是我们的生态系统支柱，而他们持续的成功则是这一框架和语言能走多远的最佳案例。他们所做的一切都值得一场该死的游行来庆祝。
因此，在这个网络星期一，我向Tobi致敬，向成千上万的Shopifolk致敬。你们为商家、消费者以及所有使用Ruby on Rails的人们带来了巨大的价值。精彩绝伦！
---------------
Black Friday is usually when ecommerce sets new records. This has certainly been true for Shopify through most of its existence. So much so that the company spends months in advance preparing for The Big Day(s). You'd think after more than twenty years, though, that things would have leveled out. But you'd be wrong.
This year, merchants sold an astounding $6.2 billion worth of wares through Shopify on Black Friday. That's up 25% from last year, when the record was ~$5 billion. Just crazy high growth on a crazy big base. The law of big numbers clearly hasn't found a way to apply itself here yet!
That volume of orders means the Shopify monolith gets put through its paces. The backend API peaked at 31 million requests per minute. The databases carried 53 million reads and 2 million writes per second. Bonkers.
It's this kind of frontier load and criticality that makes Shopify the ideal patron saint of the Rails framework and the Ruby programming language.
Rarely do the stars align to shine so brightly that a single company is stewarded by a still-active programmer with a stellar pedigree of core contributions, saddled with such unceasing success, faced with a constant barrage of novel technical challenges, and willing to contribute everything they learn and build back into the open-source base pillars. But that's Shopify.
Ultimately, this is all downstream from being a founder-led business. Tobi Lütke not only served on the Rails core team in the early days, but continues to steer the Shopify ship with a programmer's eye for detail and exploration. The latest release of Omarchy even features his new Try tool. How many CEOs of companies worth two hundred billion dollars still program like that?
Despite all this, there's occasionally still some fringe consternation in the Ruby world about Shopify's dominance. In Rails, Shopify employs almost half the core contributors. In Ruby, they have several people on the core team too. Seeing this as anything but a blessing is silly, though.
We wouldn't have such battle-tested releases of Rails without Shopify running production on the framework's edge. We wouldn't have gotten YJIT without the years of effort they sunk into improving Ruby's core performance. And we wouldn't have seen the recent production-proving of Ractors without them either. Any programming community should be so lucky as to have a Shopify!
Now I'm obviously biased here. Not only have I been friends with Tobi for over twenty years, but I also serve on the board of directors for the company. I'm both socially and economically incentivized to cheer for this extraordinary company. But that doesn't mean it isn't all true too!
Shopify is indeed the patron saint of Ruby on Rails. Its infrastructure team is the backbone of our ecosystem, and its continued success the best case study of how far you can take this framework and language. They deserve a gawd damn parade for all they do.
So on this Cyber Monday, I say cheers to Tobi, cheers to the thousands of Shopifolk. You're killing it for merchants, shoppers, and all of us working with Ruby on Rails. Bravo.
2025-11-25 16:29:01
我们现在能够用自己的硬件运行这些出色的AI模型，这真的很了不起。从DeepSeek的精简版本到gpt-oss-20b，有许多选项适用于各种类型的电脑。但让我们现实一点：它们都远远落后于可以租用的前沿模型，因此对于大多数开发者来说，它们最多只能算是一种好奇。
这并不影响技术上的成就。它也不影响小模型正在不断改进的事实，也不影响也许有一天它们真的足够好，让开发者在日常工作中依赖它们。
但那一天并不是今天。
因此，我听到开发者们以他们电脑能否良好运行本地模型来评估下一台电脑，这在我看来是毫无根据的。因为它们全都表现糟糕！无论哪一款表现稍微好一点，其实差别并不大。一旦你意识到这一点，你就会重新回到使用租用模型来完成你大部分的工作。
这其实是个好消息！这意味着你真的不需要一台配备128GB显存的电脑放在办公桌上。现在内存价格飞涨，正是由于AI对更多资源的贪婪需求，这应该会让人感到如释重负。
如今大多数开发者其实只需要很少的资源，尤其是使用Linux系统的时候。
因此，作为一个实验，我暂时停用了我那台可爱的2000美元Framework台式机。这是一台了不起的机器，但在日常使用中，我发现它与Beelink（或Minisforum）的500美元迷你电脑相比，几乎感觉不到差别。
我打赌你可能也需要比你想象的少得多。
It's pretty incredible that we're able to run all these awesome AI models on our own hardware now. From downscaled versions of DeepSeek to gpt-oss-20b, there are many options for many types of computers. But let's get real here: they're all vastly behind the frontier models available for rent, and thus for most developers a curiosity at best.
This doesn't take anything away from the technical accomplishment. It doesn't take anything away from the fact that small models are improving, and that maybe one day they'll indeed be good enough for developers to rely on them in their daily work.
But that day is not today.
Thus, I find it spurious to hear developers evaluate their next computer on the prospect of how well it's capable of running local models. Because they all suck! Whether one sucks a little less than the other doesn't really matter. And as soon as you discover this, you'll be back to using the rented models for the vast majority of the work you're doing.
This is actually great news! It means you really don't need a 128GB VRAM computer on your desk. Which should come as a relief now that RAM prices are skyrocketing, exactly because of AI's insatiable demand for more resources. Most developers these days can get by with very little, especially if they're running Linux.
So as an experiment, I've parked my lovely $2,000 Framework Desktop for a while. It's an incredible machine, but in the day-to-day, I've actually found I barely notice the difference compared to a $500 mini PC from Beelink (or Minisforum).
I bet you likely need way less than you think too.
2025-11-24 18:40:13
我从使用Dropbox和Git之前的老时代起就没有做过完整的系统备份。我现在拥有的每一台机器都被视为一个无状态、可丢弃的单元，即使被偷走、丢失或损坏也不会产生什么后果。全盘加密和所有重要数据的分布式副本意味着，如果电脑发生任何不好的事情，我都不必担心。
但不要把这误解为只是“一切都在云端”的论点。是的，我使用Dropbox和GitHub来保存所有重要的数据，但这些系统的美妙之处在于它们与本地数据副本协同工作，因此即使同步服务出现故障，我也可以随时在几台电脑中找到最新的版本。
要让这种制度有效运作，关键在于坚持。这一点在Dropbox上尤为明显。所有重要的东西都必须放在Dropbox里：文档、图片，等等。它会即时地在所有我使用的机器上进行同步。而Dropbox之外的所有内容则基本上被视为临时目录，可以完全丢弃。
正是基于这个原则，我创建了Omarchy。既然我已经有了一个方法，可以在短时间内将所有数据和代码恢复到新机器上，那么为什么一个完整功能系统的配置仍然需要数小时呢？这看起来非常不合理。现在，一切都编码在ISO设置中，可以在快速的电脑上两分钟内完成安装。
现在确实，这种方法依赖于多台电脑和快速的互联网连接。如果你被困在荒野中，而且还没有发现Starlink的荣耀，也许还是坚持你传统的全盘备份方式比较好。但如果你生活在现代世界，那么一台损坏的电脑不应该成为数据丢失的灾难，或者漫长的恢复过程。
I haven't done a full-system backup since back in the olden days before Dropbox and Git. Every machine I now own is treated as a stateless, disposable unit that can be stolen, lost, or corrupted without consequences. The combination of full-disk encryption and distributed copies of all important data means there's just no stress if anything bad happens to the computer.
But don't mistake this for just a "everything is in the cloud" argument. Yes, I use Dropbox and GitHub to hold all the data that I care about, but the beauty of these systems is that they work with local copies of that data, so with a couple of computers here and there, I always have a recent version of everything, in case either syncing service should go offline (or away!).
The trick to making this regime work is to stick with it. This is especially true for Dropbox. It's where everything of importance needs to go: documents, images, whatever. And it's instantly distributed on all the machines I run. Everything outside of Dropbox is essentially treated as a temporary directory that's fully disposable.
It's from this principle that I built Omarchy too. Given that I already had a way to restore all data and code onto a new machine in no time at all, it seemed so unreasonable that the configuration needed for a fully functional system still took hours on end. Now it's all encoded in an ISO setup that installs in two minutes on a fast computer.
Now it's true that this method relies on both multiple computers and a fast internet connection. If you're stuck on a rock in the middle of nowhere, and you somehow haven't discovered the glory of Starlink, maybe just stick to your old full-disk backup ways. But if you live in the modern world, there ought to be no reason why a busted computer is a calamity of data loss or a long restore process.
2025-10-29 17:23:31
在美国，许多科技从业者要获得长时间的休息，唯一的办法就是辞职。因此，他们每隔几年就会这么做，这在一定程度上解释了我们行业平均任职时间令人难以接受的18个月。但这种糟糕的人员流动率往往可以通过一个简单的福利策略来避免：带薪休假。
我们已经给37signals的每一位员工提供了一个为期六周的带薪休假，每隔三年一次，持续了大约十五年。这种休息方式对员工留存非常有效，因为一次长达六周的休息能让大脑重置，而两周的假期则无法做到。当员工渴望这样的重置时，通常的选项往往是辞职。
对于许多欧洲人来说，六周的带薪休假这个概念可能听起来有些奇怪，他们可能会被原谅地认为“这不就是八月吗？”他们其实也不完全错。欧洲人通常享有更多的带薪假期，但在科技行业，这也伴随着薪水大幅降低。薪水可能低至一半甚至三分之二。
我认为完全有可能实现两全其美：在美国科技公司工作，享受美国水平的薪资，同时也能定期获得完整的休息，而无需辞职。
对老板的说服也不必是关于长期幸福的人文主义诉求。它只需简单地从留存角度出发：看到聪明、受过训练的人离开公司，成本非常高。
我甚至认为，无论是创始人还是职业经理人，老板们同样能从定期的带薪休假中获益。每当Jason或我休完一次假回来，总是带着新的想法和视角，这些想法和目标往往不会在没有休假的情况下出现。
六周的休假时间也足够让疲惫的创始人意识到，出售公司未必是他们想象中的美好。莫吉托岛很快就会变得无聊。到第五周时，他们可能已经迫不及待想回到工作中了。有很多关于创始人后悔出售公司的真实故事，而他们真正需要的只是从创业冲刺中休息六周。
总之，我们每个人偶尔都需要一次长时间的休息。不仅仅是马略卡岛的两周假期，而是足够长的时间去感到无聊。去渴望工作的智力刺激和同事间的社会联系。带薪休假是实现这一点并让创始人不急于出售公司、员工不急于辞职的绝佳方式。
The only way many tech workers in the US can get a long break is by quitting their job. So lots of them do that every few years, which is partly why the average tenure in our industry is at an atrocious 18 months. But this terrible rate of churn is often avoidable by one simple benefit trick: Sabbaticals.
We've been giving everyone at 37signals a six-week sabbatical every three years for the last fifteen years or so. It's been magical for retention because a break like that allows the mind to reset in a way a two-week vacation never could. And when employees yearn for such a reset, the typical option is usually just to quit.
I know the idea of a six-week sabbatical might sound strange to many Europeans who'd be forgiven for thinking "isn't that just August"? And they're not exactly wrong. Europeans usually do enjoy more vacation time, but in the tech industry, that also comes with much lower pay. Easily half to two-thirds less.
I think it's entirely possible to have it both ways: Work for an American tech company with American pay levels, but also enjoy a regular full reset, without having to quit to get it.
And the argument for the boss doesn't even have to be some humanistic plea about long-term happiness. It can simply be about retention: it's very expensive to see smart, trained people walk out the door.
I'd even argue that bosses — be they founders or professional executives — benefit just as much from a regular sabbatical like anyone else. Whenever Jason or I have taken one, we've always come back with fresh ideas and perspectives that invariably lead to positive changes or new ambitions that wouldn't have come otherwise.
Six weeks is also just long enough to remind tired founders that selling their company isn't likely to be the bliss they imagine. That mojito island gets boring quickly. That by week five, they're probably already antsy to get back to the action. There are endless stories of founders who regret selling their business when all they needed was a six-week break from the startup sprint.
Bottom line is that we all need a long break every now and then. Not just two weeks on Mallorca, but time enough to get bored. To get hungry for the intellectual stimulation of work and the social connection of colleagues. The sabbatical is a great way to deliver that and keep founders from wanting to sell and employees from wanting to quit.
2025-10-26 01:44:28
当Omarchy今年夏天起飞时，成千上万的快乐用户开始表达他们对这个系统的喜爱，我一直在等待宇宙来平衡激情的天平。在这个世界上，任何有分量的事物要取得成功，都会引发一群反对者的反作用力。而现在，他们终于来了。
二十年前，Ruby on Rails也发生了同样的事情，但当时我还以为你可以通过逻辑论证来获得理解。我认为只要你能有力地反驳任何提出的反对意见，就能说服大多数反对者改变他们的看法。多么天真。
是Kathy Sierra改变了我对这一点的看法。从一开始对稻草人谬误和无关论证的烦恼，转变为接受它们以及反对者作为成功的自然结果。如果你想让人们爱你的作品，你就必须接受对立的力量。阴阳相生。
Kathy 是这样呈现这个选择的：
在灰色中间地带是安全的。没有人会因为你而生气，也没有人会提出任何恶意的论点，但同样，也没有人真正关心。这个区域存在着大量工作。这也没关系。我们并不需要每一个项目都去登月！但一旦达到逃逸速度，你就无法避免从两方面汲取能量。
这并不是说所有的反对意见、怀疑或批评都来自反对者。远非如此。但一旦取得足够的成功，很大一部分就会来自他们。正如Jim Rohn所说，这就是这个星球的性质。
关键在于，将这种现象视为整体上必要的里程碑。甚至值得庆祝！你有没有创造过值得欢呼的东西，如果没有人来为你喝倒彩，可能也并不值得欢呼。
因此，你要像拥抱欢呼声一样拥抱喝倒彩的声音。它们总是成对出现。
As Omarchy was taking off this summer, and thousands of happy users started expressing their delight with the system, I kept waiting for the universe to balance the scales of passion. Nothing of note in this world is allowed to succeed without spawning a counteracting force of haters. And now they're finally here.
The same happened twenty years ago with Ruby on Rails, but back then I still thought you could argue your way to understanding. That if you just made a logical case to counter whatever objections were raised, you'd be able to persuade most haters to change their perspective. How naive.
It was Kathy Sierra who changed my perspective on this. From being annoyed by straw men and non sequiturs to accepting them and the haters as a natural consequence of success. That if you want people to love your creation, you have to accept the opposing force. Yin and yang.
Here's how Kathy presented the choice:
It's safe there in the gray middle. Nobody is mad at you, nobody is making any bad-faith arguments, but also, nobody cares. Lots of work exists in this zone. And that's fine. We don't need every project to reach the moon! But when escape velocity is achieved, you can't avoid drawing energy from both sides.
All this isn't to say that all objections, skepticism, or criticisms come from haters. Far from it. But once sufficient success is secured, a large portion will. It's just that kind of planet, as Jim Rohn would say.
The trick is to see this in aggregate as a necessary milestone. One that's even worth celebrating! Have you even made something worth cheering for, if there isn't a contingent there to boo at it too? Probably not.
So embrace the boos as you embrace the cheers. They come as a pair.
