这是我在 MW 社区里分享的第一个开源模型。

我设计这款滑翔机的起因，是我尝试打印一些社区中的飞机模型给小柒玩，但它们很容易摔坏，尤其是机身与机翼的连接处。于是我参考了不同方案的思路，重新设计出了这架飞机。

这款滑翔机的机翼与尾翼面积更大，机身与机翼连接处更结实，耐撞耐摔。

【 打印建议 】

1. 无需调整参数，直接打印；
2. 如果修改参数，请确保第一二层的层高不大于 0.1mm，否则机翼易损坏；
3. 推荐使用 PETG 打印，我只测试过 PLA/PETG 两类耗材，PETG 效果更优；
4. 如果打印双色飞机，先选择的主体颜色为机身加强筋的颜色，选择机翼颜色时，推荐使用「高度范围」模式，在仰视图中点选最底层。

【 这款设计的特点 】

1. 更长更宽的机翼与尾翼，更大翼展面积；
2. 机身与机翼/尾翼的连接处，采用曲线连接，并用加强筋加固，落地或撞墙时，更不容易损坏；
3. 尾翼末端设计了向后延伸的膜片，一来优化空气流动，二来避免了打印过程中末端起翘的情况；
4. 整体仅为 4.4g（使用 PETG 单色打印时），但重量分布更优，滑翔姿态非常平稳。

如果你想在我这款设计上进一步优化，或者了解我的设计思路，可以下载我上传的 .zip 文件，解压缩后可以使用 Rhino 编辑。我没有 A 系列打印机，因此无法测试它在 A 系列打印机上的表现。如果你使用 A 系列打印机对打印配置进行优化，请上传分享，谢谢你！

The Department of Government Efficiency is shuttering organizations that Beijing worried about most, or actively sought to subvert.

If the Mac is to be the computer for the rest of us, it also needs to give access to more advanced controls by scripting its actions. This article traces some of the more significant attempts to bring scripting to the rest of us.

Over the last forty years there have been dozens of programming and scripting languages that have been developed for, or ported to, Mac OS. The great majority have had no pretensions of use by regular users. The first intended to be used by anyone and everyone was HyperTalk, released three years after the original Mac.

HyperTalk (1987)

Apple’s hypertext authoring environment HyperCard contained its own scripting language HyperTalk. For many of those who built brilliant HyperCard stacks, this new scripting language was the first programming language they had used. Sadly, although seriously cool in its day, HyperTalk was both limited and limiting, as most came to discover.

If you’ve written AppleScript, HyperTalk has a distinct familiarity in its informal language, often mistakenly claimed to resemble normal English. This code snippet illustrates that:
on mouseUp
put the value of card field "age" into theAge
end mouseUp

HyperTalk spawned many imitators, and some like SuperCard went on to outlive it, but by 2000 HyperCard and HyperTalk were all but dead.

UserTalk (1988-92)

In 1988, Dave Winer started developing a scripting language that became UserTalk in Frontier, released in 1992. Built around an object database, Winer took his early work to Apple. In 1988-89, Jean-Louis Gassee, then president of Apple Products Division, announced the formation of a HyperTalk Standards Committee to develop a scripting language, and Apple agreed with Winer that they would each develop their own mutually compatible scripting systems.

After Apple’s release of AppleScript, Frontier’s UserTalk declined in popularity. By 1994, Winer was burnt out, and the following year Frontier moved on to become a cross-platform Web content management system.

AppleScript (1988-93)

In some respects a successor to HyperTalk, AppleScript was released in October 1993, with System 7 Pro version 7.1.1. Despite all the odds, and several determined attempts to strangle it, it’s still supported in macOS Sequoia.

The concept behind AppleScript is simple: scripts that compile to a series of instructions for dispatch by macOS to their destination application, which in turn is controlled by those commands to perform a co-ordinated sequence of functions. At their simplest, these can open a document and print it, for instance. At their most complex, they can automate intricate and repetitive tasks that are messy in a GUI.

As a minimum, every application supports a core of commands to play clean with the Finder and macOS. Those, and the suites of additional commands that bring joy to the scripter, are documented in standard formats within each application’s dictionary, which can be browsed by the bundled Script Editor and other tools. Rather than having to locate additional documentation sets specific to each application, all a scripter should need to do is open the dictionary.

Complexity comes because AppleScript is in fact an object-oriented language as sophisticated as Objective-C; don’t be deceived by its apparently relaxed and informal style, with examples such as
tell application "System Events"
set mailIsRunning to application process "Mail" exists
end tell
if mailIsRunning then
-- do one thing
else
-- do another thing
end if

You might use that code to set up a script that interacts with the Mail app. It first asks macOS whether it knows that Mail is running, and depending on the answer it executes the code that you insert where the comments (prefaced by ‘--‘ characters) are placed. Unlike the majority of programming languages, punctuation marks are used sparsely in AppleScript, making it considerably easier to write code that works, rather than tripping over a missing semicolon.

When ready to test your script, it compiles into intermediate code, and the editor automatically checks, formats and colours your source code, reporting any errors that it finds. When run, the intermediate code works through macOS to fire off AppleEvents (AEvents) to trigger the target applications to perform the actions.

For the more serious AppleScript coder bundled support was too limited, and it was the arrival of Mark Alldritt’s Script Debugger in late 1994 that unleashed its full power. Sadly, Script Debugger is retiring this year after over 30 years of innovative development.

Although AppleScript was integrated into Apple’s Xcode as AppleScript Studio, in recent years it has been left to languish, with occasional rumours of its demise.

Prograph (1982-89)

In 1989, the visual programming language Prograph was launched on the Mac. Sometimes described as a dataflow language, and thoroughly object-oriented, it won awards, was ported to Windows in the late 1990s, but was last seen running as Marten.

In this example method, data flows from the top to the bottom. Normally terminals on the top ‘shelf’ of the method diagram represent the inputs to that method. Data then flows from the top shelf through the intermediate processes, until it reaches the bottom. If there are outputs from the method, they are gathered by connections made to terminals on the bottom ‘shelf’ in the method. Order of execution is not prescribed, and can take place whenever data is available; this allows for inherent concurrency, and the potential to exploit multiprocessor systems without the need for language primitives.

Shell scripts (2001)

With the advent of Mac OS X 10.0 Cheetah came Terminal and shell scripts, inherited from NeXTSTEP. Although powerful and popular with those who prefer this Unix-based approach, they have predictably had limited impact on the regular user wanting to script actions on their Mac.

Automator (2002-05)

Even ‘natural’ programming languages like AppleScript have to be learned, a task that many find too verbal and mechanical. Recognising this, Apple introduced Automator in OS X 10.4 in 2005 to produce custom workflows and apps using more intuitive visual tools.

Although often assumed to be a development of AppleScript, apart from its ability to run AppleScript objects, Automator is very different. Instead of relying on AppleEvents and dictionaries, Automator’s modular actions are separate code objects installed in the Automator folder in a Library folder. macOS comes with a huge free library of actions that can accomplish tasks you might pay good money for, so familiarity can save cost.

Automator is highly extensible, as its actions can include both AppleScript code and Terminal shell scripts. Thus if you cannot find a standard action to do what you want, if it can be expressed in a suitable script, you can build that into your workflow. Nevertheless, in 2021 Apple announced that Automator was to be succeeded by Shortcuts.

Swift Playgrounds (2014-16)

From the early days of the Mac, Apple has invested in programming languages designed to make best use of its APIs. In Classic times, that was Object Pascal, and its open-source class library MacApp. In 2014, Apple released a new language intended to be the preferred choice across all its platforms, Swift. From those early days, Swift has had an interactive mode, based on the read-eval-print loop (REPL) popularised by Lisp. This versatility has been developed in Swift Playgrounds, recently renamed in the singular, both within Xcode and as a standalone app targeted at those learning to code for the first time.

As an introduction to Swift in education, this has been impressive, but it hasn’t yet proved a gateway for those who didn’t really want to learn how to use Xcode in the first place.

Shortcuts (2014-21)

Shortcuts started out in the winter of 2014-15 as Workflow by DeskConnect. Apple bought it in 2017, and it became Shortcuts the following year, when it was integrated into Siri in iOS 12. Its arrival in macOS 12 was announced at WWDC in 2021, as Automator’s intended successor.

While Shortcuts on macOS can run AppleScript and shell scripts, the mechanisms involved in Shortcuts’ actions are completely different from AppleScript and Automator. For an app to support all three well requires it to present four different interfaces: one for the user in the GUI, AppleEvents for AppleScript, Automator actions, and now Shortcuts actions.

While Shortcuts has attracted quite a following, particularly in iOS and iPadOS where it’s the first real scripting environment, its impact in macOS has so far been limited. Like all its predecessors, it still hasn’t brought scripting to the rest of us.

Credits

HyperTalk: Dan Winkler
UserTalk: Dave Winer and Doug Baron
AppleScript: William R Cook and many others
Script Debugger: Mark Alldritt and Shane Stanley
Prograph: Tomasz Pietrzykowski, Jim Laskey and others
Automator: Sal Soghoian and other Apple engineers
Swift Playgrounds: Chris Lattner, Doug Gregor, John McCall, Ted Kremenek, Joe Groff and others
Shortcuts: Ari Weinstein, Conrad Kramer and Nick Frey

Selected references

HyperCard Pantechnicon, in the Internet Archive
Dave Winer’s Story of Frontier and AppleScript
Apple’s AppleScript Overview, last revised 31 October 2007
Apple’s Mac Automation Scripting Guide from 7 June 2018
Script Debugger history from Mark Alldritt
Wikipedia on Prograph
Automator and other automation
Apple’s Swift Playground page
Apple’s Shortcuts User Guide for macOS

英国金融时报FT（Financial Times）有一篇关于圣诞餐通货膨胀（Christmas Dinner […]

昨晚送儿子去舞蹈室的路上，我们俩聊起他前段时间在 Minecraft 国际服务器里玩小游戏的体会。因为他暑假时很痴迷蛋仔派对，我就问他，觉得 Minecraft 服务器里的小游戏和蛋仔里的游戏相比，你更喜欢玩哪个。

他果断选择了 Minecraft，毫不迟疑，这令我有一点点吃惊。

因为他前段时间痴迷蛋仔的样子，让我不得不重新制定了游戏时间的管理规则。在我原本的观念里，蛋仔其实就是一个集合了各种小游戏的游戏启动器，当下流行什么他们就塞什么进去。例如把狼人杀做成密室形式，一群小孩在里面聊天，或者把王者荣耀简化成一条直路对冲的地图，两队就卯着劲儿地打对方，或者更原始的跑酷地图，本质上跟 Minecraft 里的跑酷地图都没什么本质区别，就是画面元素都是圆滚滚的，外加一些美术做得很糊弄的障碍。加上孩子之间的社交属性，蛋仔还是蛮上瘾的。

但儿子说，Minecraft 更好玩。

他说，蛋仔里的游戏你要玩好，不取决你的操作技术，而是角色和技能。换言之，只要你拿着厉害的角色，过程中抽一两个绝杀的技能（我平时都有跟着看他玩，多少还是了解这个游戏的）就能在游戏里大杀四方。他说这样很没有成就感，尽管他原本认为可以通过技巧来打败对手，但遇到氪金的玩家，你根本就没有什么可玩的余地。

相反，Minecraft 虽然看着画面比绝大多数游戏都简陋，但在这个游戏世界里，大家的所有基础参数和可拥有的工具都是完全一样的。儿子这段时间最爱和我分享的就是他自己发现的一些操作，怎么可以快速搭路，某个工具有什么我不知道的用法，组队游戏里怎么配合怎么打败对手。在我们俩人的小服务器里，他还常常是保护我的那个人。

这是他可以通过自己的努力获得成就感的游戏机制。

「对！成就感！」他说。

人生的绝大部分时候，其实都是在游戏：学说话学走路是游戏，和朋友合作堆沙堡是游戏，上学念书考试升级是游戏，工作完成任务获得奖励也是游戏。游戏是一种机制，让我们愿意主动付出，换取成就感的机制。

好游戏和坏游戏的区别，就在于这个机制中掌握主动权的是哪一方。

原本被通知早上要和客戶開會，騎到平時停車的地方時卻被臨時告知先不開了。因為起來得比平時早一些，所以覺得有一點睏睏的。於是，就在店裡坐著冥想了五分鐘，借倆口咖啡因下肚先回點血。

I was originally notified that I had to meet with a client in the morning, but when I rode to the place where I usually park, I was told that it was not going to happen. Because I got up earlier than usual, I felt a little sleepy. So, I sat in the shop and meditated for five minutes, and took a couple of sips of caffeine to get some blood back.

元々は朝にクライアントと会うことになっていたのですが、いつも駐車する場所に着いたら、やめることになったと急に言われました。普段よりも早く起きたので、少し眠気がありました。そこで、店の中で座って5分間瞑想し、カフェインを2口飲んで血が回るようにしました。

在最近幾次冥想的過程中發現，Apple Watch 的這個呼吸頻率對我來說已經偏快了，如果完全按照我自己的節奏來控制，起碼得是 3 次，或者 2.5 次這個頻率，但 Apple Watch 已經不能設置更慢的呼吸節奏了。

I found out in the last few meditations that this breathing rate of Apple Watch is too fast for me. If I completely control it according to my own rhythm, it should be at least 3 times, or 2.5 times this frequency, but Apple Watch can no longer set a slower breathing rhythm.

最近の瞑想の過程で分かったのですが、Apple Watchのこの呼吸頻度は私にとっては早すぎます。自分のリズムに完全に合わせてコントロールするなら、少なくとも3回、あるいは2.5回この頻度でなければなりませんが、Apple Watchではもう遅い呼吸リズムを設定できません。

剛才測了一下時間，我三次呼吸（一呼一吸）的總時長是 2:03 （兩分零三秒）。這樣的話，換成 AW 的呼吸頻率計算方式應該是「每分鐘呼吸 1.5 次」。

I just measured the time and found that the total duration of my three breaths (one inhale and one exhale) was 2:03 (two minutes and three seconds). In this case, using AW’s breathing frequency calculation method, it should be “1.5 breaths per minute”.

さっき時間を測ってみたら、私の3回の呼吸（一呼吸）の合計時間は2:03（2分3秒）でした。この場合、AWの呼吸頻度の計算方法に換算すると、「1分間に1.5回呼吸」となります。

*以上英語和日語翻譯採用 New Bing 的 AI 完成。

*The English and Japanese translations are done by New Bing’s AI.

*以上の英語と日本語の翻訳は、New Bing の AI によって行われました。

但是，翻譯完之後，它居然一直反問我新的問題，是對我和我的行為感到好奇嗎？

But after translating, it kept asking me new questions. Is it curious about me and my behavior?

しかし、翻訳した後、新しい質問をずっと聞いてきました。私と私の行動に興味があるのでしょうか？

不是的。據我所知，它只是一個根據字詞關係來生成對話的超大模型，這種對話其實非常可能來自人類語庫中不要讓話掉在地上的社交禮貌用例。所以，這種反問並不能證明這個對話 AI 已經具備了意識。

No. As far as I know, it is just a huge model that generates dialogue based on word relationships. This kind of dialogue is very likely to come from human language libraries that do not want to let the conversation fall to the ground. Therefore, this kind of rhetorical question cannot prove that this dialogue AI already has consciousness.

いいえ。私の知る限り、それは単に単語の関係に基づいて対話を生成する巨大なモデルです。このような対話は、会話を地面に落とさないようにする人間の言語ライブラリから非常に可能性が高く来ています。したがって、このような反語的な質問は、この対話 AI がすでに意識を持っていることを証明できません。

昨晚吃饭前跟儿子一起画画，我随便画了一下我们在 Minecarft 里的第二个家，和随便画的一个岩浆包围的高堡：

后来想说看看 Midjourney 能模仿成怎么程度，就丢进去试了一下：

emmm，画得还行……

就是画风不太相关，它有它的训练痕迹，哈哈哈哈哈哈哈～

测试所使用的 prompt：

Tree house, jungle, rainforest, simple little house –sref+空格+两张手绘图的地址 –ar 9:16 –s 50 –v 6.0 –style raw