一句话总结

手头积压了太多半成品任务。

亮点

• 我在寻找减少手头半成品任务数量的办法。
• 我集思广益，寻找与更多早期读者交流的方式。
• 我难以接受 Gleam 语言中的一项设计决策。

目标完成情况

每个月初，我都会定下当月想要完成的目标。以下是本月的完成情况：

为用户提供更低门槛的图书预订方式

• 结果：从 Kickstarter 预订改为 Stripe 支付链接。
• 评分：A

最初的预售是通过 Kickstarter 进行的，所以我决定后续预订也继续沿用它。过了几个月，我才意识到 Kickstarter 要求顾客必须创建账号才能购书，这带来了很大的阻碍，打消了不少人的购买意愿。

改用 Stripe 后似乎对销量产生了影响：切换后 30 天内通过 Stripe 有 22 笔预订，而之前仅用 Kickstarter 时只有 7 笔。这并非完全可比的对照，因为切换到 Stripe 后我还发布了一个新的样章。

在图书网站上发布一个新的样章

• 结果：发布了 “How to Write Compelling Software Release Announcements”
• 评分：A

这篇文章在 Lobsters 上反响不错，在 Hacker News 上表现也很好，但被管理员从首页移除了。我猜测 Hacker News 上的用户不喜欢其中对营销的强调，所以点了举报。

这一章收到的有用反馈比之前任何一章都多。很多是负面反馈，但确实很有帮助，因为我觉得那些批评都很中肯。我根据反馈修改了文章，讨论也启发我新增了两个小节（“Briefly introduce your product” 和 “Turn your numbers into graphs”）。

至少与 10 位读者进行视频通话

• 结果：与三位读者进行了视频通话。
• 评分：D

这一项远未达标。部分原因是整个月我只安排了两次通话，但另一个问题是，即便安排了通话，也没能吸引到早期读者来参加。

Refactoring English 数据一览

数据回归！

我过去常常每月公开财务状况，但卖掉 TinyPilot 之后就停了，因为没什么值得分享的数字。现在预售已经启动，又有相关数据可以分享了。

很高兴看到访客增长带来了销量增长，更高兴的是销量的增速超过了访客增速。不知道这种势头能否持续，但如果能持续，就说明读者足够喜欢这本书，愿意向他人推荐。

怎样才能同时处理的草稿更少一些？

写这本书时一个行之有效的策略是，每天至少投入一小时进行“困难”的写作。也就是说，这一小时不能用来做排版、语法检查或校对。

这个策略效果很好。六月份，我的产出可能是职业生涯中单月最高的。我为 Refactoring English 电子书新增了三章，发布了一个新样章，还在这个博客上写了三篇新文章。

这个策略的问题在于，回避那些相对轻松的写作任务，会导致积压大量只差语法检查和校对就完成的稿件。尤其是上个月，我手头有许多未完成的稿子，总要费心去记哪些已经发布、哪些还需要最后润色，感觉很耗精力。

究其根本，问题在于我一直在开新的博文。也许最简单的解决办法就是，在还有未完成的稿子时，就不要再开新坑。

怎样才能与更多早期读者交流？

边写边卖 Refactoring English 的一个好处是，愿意预订一本未完成书籍的人，相对于普通读者，往往更加热情。我的计划是经常与早期读者交流，确保这本书能解答他们的疑问，并且易于理解。

实际操作中，我很难与读者建立联系。我曾就样章发送过简短问卷，也邀请大家回复反馈，但在约 1,400 名邮件订阅者和约 250 名预订用户中，只收到了寥寥几份回复。

我开始举办线上视频活动，并尝试了多种形式，包括讲座、写作工作坊、答疑时间，以及像读书会那样讨论热门的软件类博文。这些直播很有意思，参与者也给了我非常棒的反馈，但每次只有几位读者参加，感觉触及的仍然只是极小一部分人。

另一个有效的反馈来源是购买一对一修改服务的客户。虽然目前只有三位付费客户，但与他们的合作让我更清楚目标读者希望在哪些写作问题上得到帮助。

基于这些情况，我想到了以下几个与读者多交流的办法：

• 在读者购买后单独联系，询问他们希望从书中学到什么，以及目前的内容是否符合预期。
• 优化我的写作咨询页面，让它更具吸引力。
• 为那些学习意愿强烈但负担不起原价的人提供优惠的咨询选项。
• 主动联系那些在 Hacker News 上持续投稿却始终没什么反响的用户，看看他们是否有兴趣付费请我提供反馈。
• 提供“为你的团队预约我”选项，让我可以为某个工作团队讲解写作主题并解答疑问。

怎样更好地推广这本书？

除了那些半成品博文，还有很多想做来推广这本书的简单事情，但我一直没有为它们安排时间，于是它们一直在脑海里占据空间。

以下是我想完成的那些唾手可得的任务清单：

• 改进网站。
  • 添加 favicon。
  • 调整界面，让行动号召从“订阅邮件列表”改为“购买抢先体验版”。
  • 改进抢先体验页面。
    • 我已经将其从“预订”更名为“抢先体验”。
  • 在网站上展示具体有哪些章节可用，而不只是显示数量。
• 发布一年前录制的博主访谈。
  • 这原本是为我计划重启的 Hit the Front Page of Hacker News 录制的，但后来我搁置了那个产品，一直把访谈压在手里，觉得挺对不住受访者的。
• 将网页版的节选内容移植到电子书中，并在网站上将这些章节标记为已完成。
  • 大部分已经完成了，但这件事太枯燥，我一直拖着，还有三章的网页节选尚未整合进电子书。

用 Gleam 编程，怀念朴实的 for 循环

为了今年学习一门新编程语言，我一直在尝试 Gleam。我用它来解析以前的 AOL Instant Messenger 聊天记录，格式如下：

Session Start (DumbAIMScreenName:Jane): Mon Sep 12 18:44:17 2005
[18:44] Jane: hi
[18:55] Me: hey whats up
Session Close (Jane): Mon Sep 12 18:56:02 2005

我写过一篇更长的文章谈我对 Gleam 的初步印象，此后又花了好几个小时用它编程。

在 Gleam 中最难适应的一点就是没有循环。Gleam 刻意不提供循环，取而代之的是让你使用递归函数或对列表中的每个元素调用映射函数。

当我试图将聊天记录拆分成词元以便解析时，没有循环这一点给我带来了最大的麻烦。我关心的分隔符是 [' ', '\n', '[', ']']。我也关心冒号，但仅限于后面紧跟一个空格的情况，就像这样：': '。

在 Go 这样的语言中，我会在 for 循环中遍历字符串。当遇到空格字符时，我会检查前一个字符是否是 :，以便处理 : 这种情况。

在没有循环的 Gleam 中，我最后不得不构建一个奇怪的决策树，其中许多叶子节点都重复了同样复杂的函数代码。

我觉得 Gleam 的许多设计选择都很有意思——当我按“Gleam 的方式”做事时，感觉很优雅，但一到循环，就觉得像是手头没有合适的工具在干活。

我会继续尝试 Gleam，同时也打算试试 Elixir 或 OCaml，因为它们具备我喜欢的 Gleam 的许多特性，又能解决我的一些痛点。

总结

完成了什么？

• 发布了 “How to Write Compelling Software Release Announcements”
• 发布了 “goHardDrive Leaked Personal Data for Thousands of Customers”
• 发布了 “My First Impressions of Gleam”
• 发布了 “A Simple Example of Calling an Elixir Library from Gleam”
• 为 Refactoring English 电子书撰写了三个新章节
• 将之前作为网页节选发布的三个章节整合进了电子书

经验教训

• 当已有未完成的稿子时，要抵制再开新博文的诱惑。
• 应该在行之有效的方法上加倍投入，以寻求与读者更多的交流。

下月目标

• 与至少 10 位之前未交流过的读者交谈。
• 清理积压的推广点子。
• 发布 Refactoring English 的一个新章节。