作者归档:白宦成

关于白宦成

独立开发者, 自由职业者, 写作者

d2b5ca33bd970f64a6301fa75ae2eb22 6

《鞋狗》阅读书摘

  • 创办一家企业,绝不只是简简单单的生意,诚信、信誉、正气、契约,这是商业伦理的基础和要求。一家企业只顾自己活着还是不够的,还得帮助其他人活得更加充实,在这方面《鞋狗》是一个标杆。
  • 创业机会无所不在,创业成功却会有一个周期。想要成功,一方面在于企业本身能够坚持、并能正确地坚持,而另一方面则是创投资本的发展是否能够为此提供更好的支持。《
  • 《旁观者》一书中,德鲁克写到自己曾观察那些杰出领导者,发现他们都有一个共同特点,就是充满着对世界的好奇,通过洞察、把握,总是能发现出每个人、每一处与每件事儿的独特趣味。
  • 培根在《习惯论》中的观点可以很好地解释菲尔·奈特的一生:思想决定行为,行为决定习惯,习惯决定性格,性格决定命运。
  • 我们的个性、命运,甚至是我们的基因。“懦夫从不启程,”他对我说,“弱者死于路中,只剩我们前行。”
  • 每个跑者都清楚这一点。你不停地跑步,一段接着一段,却不太清楚为什么而跑。你告诉自己跑步是为了某个目标,追求某种刺激,但你跑步的真正原因却是停下来会让你感觉到对死亡的恐惧。
  • 想起《裸体午餐》作者威廉·巴勒斯的话:垃圾商人根本不是向消费者卖产品,而是把消费者卖给自己的产品。
  • 禅学认为现实不是线性的,没有未来,没有过去,有的只是现在。
  • 日本的文化不推崇直截了当。没有人会直接拒绝你,没人会直接说不,但他们也未必会说是。他们会兜着圈子说话,既不主观也不客观。你不要觉得沮丧,但也不要扬扬自得。你可能在离开时觉得自己搞砸了一切,但实际上对方已经准备进行交易;你也可能在离开时觉得这笔生意肯定跑不掉,但实际上你已经被拒绝。你根本无法猜测对方的想法。”
  • 日本伟大的诗人曾写道:“无欲无求,放下一切。”这句话似乎已经过千锤百炼,就像日本武士刀的刀刃或山川溪流之石一样散发光芒。
  • 麦克阿瑟也有不完美之处,但他清楚这一点,他曾经说过:“打破常规者,人恒敬之。”
  • 最后一天,我在爱丽舍宫闲逛,追寻自由之路,时刻想着巴顿将军,想着他那句“不要跟人们说如何做事,而是告诉他们该做什么,让他们创造你所惊叹的结果”。
  • “每个人,几乎每个人,至少会换三次工作。所以如果你现在就职于一家投资公司,你最后还是会离开的,而你的下一份工作可能就需要从头开始。
  • 传播信念,我决定。信念才是不可抵抗的。
  • 我所学到的理念就是,销售额持续增长,有赢利能力,再加上无限的上涨空间,就等于高品质的公司。
  • 人们有种错误的想法,那就是只有杰出的奥运会运动员才称得上是运动员,但他觉得每个人都是运动员。只要你身体无碍,就可以运动。
  • 智慧似乎是无形的资产,但资产都是一样的,是充分的理由值得为之冒险。创业就是唯一让生活中的其他风险——婚姻、财富、地位,变得更有可能的事情。
  • 多页,《慢跑》(Jogging)却在向全国“传道”,它是一本之前鲜见的关于身体锻炼的“福音书”。
  • “因为,”伍德尔的母亲说,“如果你对自己儿子为之奋斗的公司都无法信任,你还能信任谁呢?”
  • 我希望自己更加自信,我希望我可以借来一些自信。但自信就好比金钱,你必须有了一部分才能获得更多。人们通常都不情愿借给你。
  • “懦夫从不启程,弱者死于路中,只剩我们前行。”
  • 很明显,“恶棍”们喜欢我营造的氛围。我完全信任他们,不会严密监视他们,这就形成了一种强有力的互相信任。我的管理方式对那些每一步都需要引导的人是没有效力的,但这个团队会觉得自由和被充分授权。我让他们做真实的自己,让他们自己动手,让他们自己犯错,因为我一直就想要别人这样对待我。
  • 很显然,他们喜欢我们的故事:一群俄勒冈体育怪人的发家史。很显然,他们喜欢耐克代言人对我们产品的看法。我们不仅是个品牌,我们还是一种态度。
  • 当一名电话维修工都觉得自己有必要教训你时,我告诉自己,也许你的行为可能真的需要改正。那一天,我对自己许下承诺,我发誓从那时起我要学会冥想,深思熟虑,每晚跑20公里,尽我所能使自己不要过分情绪化。
  • 把这个叫作“生意”好像也不对。所有忙碌的日子和无眠的夜晚,所有伟大的成功和绝望的挣扎,好像无法用这个平淡无奇的词语“生意”来概括。我们实际做的要远远超出这个范畴。每当新一天到来时,都会有50个新问题出现在我们面前,50个艰难的决定需要我们立即做出。我们都十分清楚,一次轻率的举动、一个错误的决定都会让我们走到尽头。容许犯错误的余地从来都是越来越小,但利益却从来都是在慢慢增加。我们都坚信这里的“利益”不仅仅是“金钱”。
  • 懦夫从不启程,弱者死于路中,只剩我们前行。
  • 这绝不只是生意,将来也绝不会。如果这演变成只是生意的话,这说明生意真的做得很糟糕。
  • 当然,工资的问题一直都存在。第三世界国家工人的工资相较于美国人来说低得不可思议,这一点我理解。但是,我们在每个国家和经济体的范围和体系内运营,所以不能随心所欲地付薪水。在某一个国家,这里就不具体说哪里了,当我们想提高工资时,却受到了斥责,被传唤到某政府高官的办公室,要求我们停止。我们破坏了这个国家的经济系统,高官说道。这样做是不对的,他坚持道,也是不合理的,制鞋工人的工资竟然比医师的要高。
  • 能帮助人们避开一般挫折是很好的事情。我想告诉大家要按下暂停键,花时间努力思考一下要如何度过一生,想要和谁一起度过剩余的40年。我会告诉20岁左右的青年不要因为一份工作、专业甚至职业而安定下来,一定要寻求内心的冲动。即使你不知道其中的含义,也要坚持追寻。如果你追随自己内心的冲动,将会更能忍受疲惫,每一次失望都会成为你的动力,需要攀登的高峰也会变得微不足道起来。
  • 那些破除陈规者、创新者和反叛者后背上都有一个靶子,他们越是成功,就越容易受到别人攻击。这并不是一家之言,而是自然规律。
  • 相信自己,也要相信命运。不是别人的命运,不是你自己定义的命运,而是在你内心,对命运的自我定义。
selective focus photography of monk at corridor

大部分中国人没有信仰

大部分中国人是没有信仰的。

你可能会问,中国人不是也去寺庙去拜佛,也到教堂去做礼拜。为什么说中国人没有信仰呢?

d2b5ca33bd970f64a6301fa75ae2eb22 5

维基百科中,对于信仰的定义是“人事物或概念的坚定信念或信任。”,但对于那些去寺庙拜佛、去教堂礼拜的人来说,他们可能并不坚定的认为这些“神”的存在的,他们关注的也不是自己对于“神”的信仰,而是关注神到底能为自己解决多少问题?

这也是为什么我们发现,财神庙总是香火最旺。

text

到底多少个错误码才是合理的?

在对外开放 OpenAPI 的时候,错误的设计也是一个极为影响开发者开发体验的设计点。今天我们简单聊聊关于错误码和错误处理

为什么需要错误码?

由于我们不能保证系统可以完全处理用户的请求,因此我们需要通过错误码来告诉开发者发生了不符合预期的情况。不符合预期的情况可能由用户输入错误导致,也可能由内部微服务故障导致。为了建设一个健壮(Robust)的系统,我们需要通过对外暴露一批错误码,帮助开发者更好地处理各种异常情况。

避免错误码数量过少

既然我们的目的是帮助开发者解决异常情况,那么一个合理的答案是:和异常情况匹配的错误码数量是一个好的错误码数量。

如果在某个 API 接口上提供了一个错误码,则意味着我们认为这个接口只会出现一种情况导致的错误。而实际上,很可能会有多种情况导致错误发生。这种情况经常在 OpenAPI 评审过程中被提出来,也是用户在使用 OpenAPI 时常遇到的问题:为什么我找不到这个错误码?对于开发者来说,无论输入何种错误,都会得到相同的错误码,难以定位和解决问题。同一个错误码也意味着你无法提供足够的错误信息来进行排查。例如,常见的 “400 Bad Request” 错误,如果参数很多,排查错误可能是一个极其痛苦的过程。

避免错误码数量过多

另一方面,错误码数量过多也会导致问题。有些 OpenAPI 接口提供了几十个不同的错误码,看起来感觉很不错。但是仔细一看,就会发现这些错误码实际上只是针对不同的字段错误而已,导致错误码数量快速增长。而实际上,可以将参数错误放在同一个错误码中,并通过动态的参数和原因来解决,而不是返回一堆类似的错误码。大量的错误码对于开发者来说,存在记忆困难的问题,在实际编写代码的过程中,也需要编写大量的错误处理逻辑,来兼容我们对外抛出的错误处理逻辑。

换一种思路来组织错误码

如果你无法很好的掌握拆分和组织错误码的粒度,那我可以给你一个建议:按照用户处理错误的手段来拆分错误码。过去从内部视角来组织和错误码,很容易出现错误码过多或过少的情况,而从外部视角来梳理错误码,则可以帮助我们更好的厘清错误码的分类和组织。

用户并不关注我们的系统到底因为什么出现了错误,他们只关心出现了什么样的错误?我应该如何处理这些错误?那错误码可以非常快速的收敛为以下几类:

  • 本资源参数校验错误,对应的处理策略往往是开发者需要查看文档,了解资源参数的限制, 修改参数重新调用。
  • 跨资源参数校验错误,对应的处理策略往往是开发者需要通过其他 API 获取关连资源的 ID 等信息,以便于重新调用。
  • 请求频率太高,对应的处理策略是优化调用的接口和方法,调低并发量。
  • 服务端错误,对应的处理策略是重试,并在重试无效时联系官方人员。

通过上述的分类方式,我们可以快速的将错误码归类到几个大的分类,从而实现合并同类项,收敛错误码但不至于让开发者不知道下一步 Action 的情况。

错误码不重要,错误处理才重要

看到这里,相信你对于文章中提出的什么才是好的错误码设计已经有了答案。但我想说的是,错误码从来都不是核心。实际上,如果我们回看各种编程语言的范式,大多没有错误码这种设计,而是选择将更多的信息通过 exception 这样的形式暴露给开发者。错误码的设计虽然给到开发者一个可以用来做唯一判定的数据,但可以做唯一判定的不一定非要是数字。数字错误码的设计严格来说,并不是一个好的设计,因为他使得你的代码中必然会存在某些特定的 Magic Number,你需要小心的维护这些 Magic Number 来确保向开发者返回错误时不至于返回错误的错误类型和错误码。

对于一个已经存在的 OpenAPI 系统来说,错误码已经成为既定事实,则要做的是让这套系统可以更好的运转下来。但如果你要设计一套全新的错误系统,那么类似 Slack 这样的返回形式,可能是一个更好的选择,既可以规避掉 Magic Number 的问题,又可以确保每一个错误有其对应唯一的枚举值。

p3nta3

总结

好的错误码设计是适度的,你需要学会平衡错误码和对应错误信息的数量,不要太多干扰开发者,但也不可太少,不足以支撑实际的接口调用。好的错误码可以帮助我们和开发者建设更加健壮的系统,减少不必要的沟通成本,也可以让我们每一个使用这个 API 的人,都更加的幸福。

9ac4e9081f7d880526f74a5c114d3369

使用 DSL 管理你的正则表达式

最近在写 LCTT 译文的解析工具,写正则、调试正则的过程非常的痛苦。

比如,下面的这个正则表达式就是我用来提取文章的英文标题的正则。由于 LCTT 的文章元信息存储历史上出现过多次,所以我不得不写一个比较复杂的正则来匹配出想要的结果。

比如,下面的这段代码是我用来从文件路径当中提取出不同内容的正则,看起来十分复杂,对吧?

/(?<collectDate>(?<type>(?<path>\.\/)(?:published))\/(?<yearOrSeries>(?:.+)?)\/(?<month>(?<=\d+)\.(?=\d+))?)(?:⭐️|⭐️⭐️)?(?<title>.+)\.md/

相比于看起来复杂,更加麻烦的是可维护性。正则表达式的可维护性相比于正常我们熟悉的编程语言来说,是差了一大截。基本上如果要对上述这段正则表达式进行修改或者二次开发,难度极高。但借助一些工具,我们可以使用类似 DSL 的方式来管理正则表达式,则可以以一个更友好的方式来维护你的正则表达式。

d2b5ca33bd970f64a6301fa75ae2eb22

比如,以我为例,上面这张图片中的定义,便是上方正则的等价替换。虽然写了更多的代码,但确实可读性、易于理解性和易于维护性,有了显著的提升。

想要使用,也不复杂,只需要使用对应的 DSL 语法来完成定义,即可完成正则表达式的构建。以我上面的这段正则为例,我使用的是 javascript 的 magic-regexp 包,实际使用时,大概是这样的,定义出对应的正则,直接基于其进行匹配即可。

const magicRegxp = require('magic-regexp');
const { createRegExp, exactly, oneOrMore, char, anyOf, carriageReturn, global, multiline, linefeed, maybe, digit } = magicRegxp;

const regExp = createRegExp(
            exactly("./").groupedAs("path")
            .and(anyOf("published")).groupedAs("type")
            .and(exactly("/"))
            .and(maybe(oneOrMore(char)).groupedAs("yearOrSeries"))
            .and(exactly("/"))
            .and(maybe(
           exactly(".").after(oneOrMore(digit)).before(oneOrMore(digit)).groupedAs("month")
            )).as("collectDate")
            .and(maybe(
                exactly("⭐️").or(exactly("⭐️⭐️"))
            ))
            .and(exactly(oneOrMore(char)).groupedAs("title"))
            .and(exactly(".md")
        ));
let result = regExp.exec(file_content);
console.log(result.groups.title);
Code language: JavaScript (javascript)

当然,这样的维护方式,在不同的语言下有着类似的实现,如果你使用 Golang ,那么 Rex,也是一个不错的选择。

d2b5ca33bd970f64a6301fa75ae2eb22 2

推荐一个最近发现的好东西 — Save To Notion

这个工具是我在研究别人的的 Notion 工作流时发现的,一个支持从网页中提取核心数据的 Notion Saver 插件 —— Save To Notion官网

d2b5ca33bd970f64a6301fa75ae2eb22 2
d2b5ca33bd970f64a6301fa75ae2eb22 1

和绝大多数 Notion Saver 类似,Save To Notion 也支持直接存储一个书签到 Notion 当中,对于平时需要大量阅读的人来说,这是一个和其他产品无法形成差异化的 Feature。

但 Save To Notion 一个非常厉害的功能,是你可以在你的保存表单中,设置从网页中提取数据,它应该是采用了 XPath 来实现这个 Feature,你可以根据自己的需求,从页面中选择数据来提取,从而可以基于 Notion 完全实现一套自己的数据库。相比于其他 Saver,多了一步解析数据的能力,而这个能力,可以帮助你节约许多的时间。

d2b5ca33bd970f64a6301fa75ae2eb22 3

Just Use IT!

red and blue light streaks

复盘:买好资产和好价格

我的美股持仓里有两支股票,MSFT 和 AAPL,应该说是互联网人常买的了。而正是这两支股票,让我真正理解了买好资产和好价格

从资产的视角来看,这两家企业都是值得购买的,至少 5 年内,微软不会崩盘(Windows/Office 的实力你一无所知),苹果得益于其订阅生态,也不是那么容易被干掉的公司。因此,至少在我的认知内,他们都还算是好公司。

而好价格,在我购买的这两家公司的过程中,则体现出了不同的风格。这两支股票我都几乎购买在了顶点。苹果的平均持仓价格为 $156,而微软的平均持仓价格则是 295 美元。

4yydfo
4uc7pu

从 K 线图上可以看到,我几乎是都买在了山顶,但因为实际购买的时机来看,距离山顶的距离又有所差异,苹果是左侧购买,而 MSFT 则是右侧购买。

我购买的价格平心而论,都不算是特别好的价格,MSFT 的52周最高价格是 312 美元,距离我的价格只有 10 美元左右的空间,可以预测到,这一笔投资我大概率没有什么收益。AAPL 类似,52 周最高价格为 177 美元,稍微好点有大概 20 美元的空间,盈利的机会相比于 MSFT 都要更高一点,但相对也有限。

好在是美股当中投的钱本来对我来说,也属于闲钱,不太依赖他求生,所以这笔钱大概率我可以等到它回本以后卖出,甚至是重新涨回到高点卖出,我的实际损失可能不多。

但这两笔投资还是值得复盘:

  1. 这两家公司是好公司
  2. 但我购买的价格不一定是个好价格

如何选择一个好的价格?这个就需要我们心中对其有个定价。之前我关注的主要是愿景,但确实没有仔细算过这个到底是不是一个值得购买的价格,从而导致这两笔不成功的投资。

如果基于现在我的认知,再买股票我应该做的:

  1. 计算估值:一个企业的估值的具体数值是比较难算的,但其长期的量级是相对明确的。所以我需要关注的是他到他应该有的量级的空间还有多大,这个空间便是留给我的盈利空间。
  2. 关注 52 周最高价格和最低价格:关注最近一年的价格未必是一个好的参考,但至少是一个参考。如果当时关注了 52 周最高价格和最低价格,可以看到,我其实离最高点没有多远,留给我的盈利空间非常的少,后续在实际购买时,还是应当注意我自己的盈利空间。

《无人知晓》《知行小酒馆》给我带来的反思还是挺多的。至于关于「好资产和好价格」,我推荐你看看有知有行的投资第一课,在第 9 课中的:好公司等于好股票,就提出过类似的话题。

d2b5ca33bd970f64a6301fa75ae2eb22 4
Investment

复盘:别急着上牌桌

我的美股里常年放着一些闲钱,在上一轮大的暴涨、暴跌的时候,我做了一把韭菜,把这些钱全部都投入到了股市当中。

现在回看起来,我觉得最大的问题还是当时犯了 FOMO(Fear of Missing Out) 的毛病,导致自己盲目出手,买了一些不是好价格的好资产。

但实际上,现金是最重要的,我不应该因为担心没有及时将钱投入到股市当中而带来的货币贬值,而选择盲目的购买资产。虽然通过购买资产,让我短暂的心安,但实际上可能带来更加长期的亏损。

作为持有现金的人,一方面要警惕现金的贬值(但贬值其实没有那么快),另一方面,也是更加重要的,便是不要将现金投入到错误的资产当中,带给自己更加长期的贬值的可能。

a person stacking coins on top of a table

Flomo 收购幕布 – Win-Win Game

Flomo 收购了幕布,这是个我难以相信的事情。但仔细想想,其实很合理,也很有价值。

作为幕布的原持有方,字节跳动面临着业务需要收缩,战略需要聚焦的现状,养着一个幕布团队没有太大的意义,只不过是因为之前和用户的协议所迫,不得不继续维护。能过将幕布卖出去,对于字节跳动来说,是利大于弊的。且字节跳动收购产品一般是来收购团队的,而在字节跳动的产品飞书当中,已经实现了类似幕布的能力,对于字节跳动来说,幕布的历史使命已经完成,继续留着只不过是鸡肋,刚好 Flomo 要收购幕布,就可以顺利成章的将其出售出去。

而作为幕布的收购方 Flomo,则更是一个好的选择,Flomo 本身的调性和幕布十分匹配,对于 Flomo 的用户来说是利好,对于幕布的用户来说,也不算差。而对于 Flomo 团队来说,Flomo + 幕布的组合,可以让其在知识管理上进一步拓展,挺好。

一个难得的 Win-Win 的收购。当然,对于我来说还是难以想象的,毕竟,都是字节收购别人家的产品,第一次碰到从字节收购产品的。

少楠厉害!👍。

photo of silhouette photo of man standing on rock

2023, 松弛

2022 年,为了保持对自己的压力,我保持了为期一年的高密度更新。回过头去看,我觉得这些更新有价值,将我思维中的碎片都展现出来了。但同样的,这些碎片过于简单和不集中,可能对于绝大多数人来说,其实很难有比较大的帮助。对于我自己来说,也只是将我的思维碎片提前拿出来,而不是在我自己的脑海里发酵一下。

在 2023 年,我对自己的定位是松弛,不再逼自己去做一些事情(即使这些事情的确很好),而是更加随性,不强求,看命,看运。

MacBook Pro on brown wooden table

ChatGPT-FeiShu 为什么能火?

复盘 – ChatGPT-Feishu 项目 之后,我的项目也经历了一些迭代,OpenAI 也将最新的 ChatGPT 所使用的 API 版本进行了开放,对于我们开发者来说,无疑是一场狂欢。

而在这个过程中,ChatGPT-Feishu 也收获到了不少的关注,用户越来越多,在这个时候,我开始思考 Why?

一方面,是 ChatGPT 本来就很热,毕竟是一个 AI 新物种,看起来比过去的各种 NLP 产品都更有意思。再加上各种媒体的渲染, ChatGPT 成功的出圈了。

另一方面,是 ChatGPT 在注册和使用上存在限制,大部分的普通人是无法直接使用的,所以使得 ChatGPT 又有了一些神秘感。这种限制使得我们这些能够将 ChatGPT 的能力提供出来的项目得到了更多的关注。

而最后,则是 ChatGPT 和企业协作场景的契合,如果你将 ChatGPT 接入到企业的聊天工具中(如飞书、企业微信),就可以让一个企业的人用起来 ChatGPT,且可以在不损失企业上下文的场景下使用,可以达到非常好的日常使用的效果。

说起企业协作的场景契合,让我想起了多年前的 ChatOps。我前几天去看,Hubot 项目已经被 Archive 掉了,真的是时代的眼泪💧。