网名，真名哪个重要？

今天在看 V2ex 的时候，发现 V2ex 有个帖子“你们的 Github 账号会用自己的真实姓名么？”，里面提到了大家大多不在互联网上使用自己的真实姓名。

刚好，今天早上我的 Boss 在一个读书会的群里也在讨论这个问题，他常年使用笔名“青润”，很多人只知道他的笔名，不知道他的真名。

这两件事情让我思考，我们是否真的有必要让别人知道自己的真名呢？

就如我 Boss 所言，名字本身只是一个代号，笔名也是一个代号，如果你一直使用一个特定的代号，那他其实和你的名字没有什么区别。对于我来说，使用 Bestony 这个 ID 也不短时间了，以后应该也会长期使用下去。不过，我在考虑后续同时扩张我的本 ID 的影响力。这样看来，似乎也没有必要。

不过，可以本名关注非技术领域，网名关注技术领域。

Reference

你们的 Github 帐号会用自己的真实姓名吗？：https://www.v2ex.com/t/538131#reply32

为什么英文互联网世界里实名比例如此之高： https://laike9m.com/blog/wei-shi-yao-ying-wen-hu-lian-wang-shi-jie-li-shi-ming-bi-li-ru-ci-zhi-gao,107/

《良质！PHP企业级系统开发》书摘

发表评论

尽我们最大的努力，开发并交付价值最大化的软件

首先，应该交付。完成交付以后，再考虑代码质量。

完成，完整，完善，完美

开发的顺序，一开始先完成，再完整，再完善，最后是完美。搞错了，就再也搞不出来了。

致力于编写容易理解的代码，专注于软件开发领域，努力创造更大的价值。

创造价值是核心，代码质量不一定是。

做事情，不要急，但要快！

快！=急

选择高起点，并始终以高标准严格要求自己

严于律己，宽以待人。

对于随时发布，我个人觉得是过于随意，缺少严谨性，所以我是不推荐的。由随时发布而产生的间接负面影响，要远大于它的直接正面收获。看似非常快速的发布方式，实际上却让我们不停在原地打转。所以，我不推荐初学者一开始就钟情并习惯于这种发布方式，更不推荐高级资深开发同学固守这种发布方式。如果你当前已经是随时发布，请不要妥协。

随时发布容易成为救火队员。

MixKit —— 免费可商用的在线视频下载网站

发表评论

MixKit 提供了可以免费商用的视频资料，如果你需要一些动态的视频的时候，可以去找找看。

https://mixkit.co/

一种运动轨迹生成算法的思路

发表评论

由于我司程序员太懒，生成轨迹算法直接取的随机数，导致生成的轨迹图变成了一个网状的结构，根本无法使用。

搜索以后，发现一个很有意思的轨迹生成算法，分享给大家。

算法思想

定义起点和终点
在起点和终点直接取中点
在起点与终点连线的垂直方向上进行变化，取得第三点
连接起点、中点、终点。

图示

1 定义起点和终点

2 取中间点

3 在中间点上取垂线

4 连接起点、中点、终点，形成轨迹图

这样，就完成了一条路径的生成，很简单，但是比较有效。

用上了自己做的翻译插件

发表评论

之前用的翻译插件cos_slug_translator 因为一些原因，并没有办法很好的和 JetPack 一起联用。导致每次发布到 Twitter 的文章链接都是失效的。为此，我前往 Github ，在 JetPack 的项目中发起了一个 Issue 。

Jeremy 给我了一些建议 , 于是，我就重新做了一个插件，并将这个插件提交到了官方的插件系统。希望可以通过审核。

后续考虑继续支持其他一些翻译平台，比如，有道翻译的新 API、搜狗、Google等一系列。特别是 Google，这样就可以支持非中文文章了，比如，日语的。

项目仓库：

https://github.com/bestony/automatic-translate-slug

轻松筹的意义

发表评论

其实苦难一直都在，从未远离过我们，轻松筹之类的平台只是将他们放在了我们的眼前罢了。

Vue 没有办法让页面高度为 100% 怎么办？

发表评论

在进行 Vue 后台开发时，一般来说，我们希望我们的应用的首页是 100% 高度，其样式大致如下

但是一开始，往往会遇到高度没有办法设置为 100%。

这是由于在 Vue 中，并没有给 html,body,#app 设置默认高度

解决方案也很简单，只需要在 App.vue 的 style 中添加如下代码

html,
body,
#app {
  height: 100%;
}
Code language: CSS (css)

能成大事者，敢背锅

发表评论

我有两个朋友，在某厂做 BaaS 服务。

在进行产品开发时，到了某个产品时，大 boss 竟然想让用户自己去买服务器来搭服务，并通官方通过的 SDK 进行转接。这让我百思不得其解。

因为在我看来， BaaS 这种业务，就是把弹性、运维、环境都从用户这里拿走，让用户只关注逻辑和业务，从而更好的关注自己的业务。这种将一部分能力拆出来，由用户自建的行为十分的奇葩，将从用户这里拿走的弹性、运维、环境问题，重新又踢回给了用户。

作为一个 BaaS 服务，如果你让用户想起来自己去搞弹性，那基本就是在提醒用户，你不要用我们的服务了，你自建吧，反正弹性什么的你还是要自己搞。没区别。

后来，我想明白了，估计是大 Boss 因为该产品之前的一些功能不稳定，总是被客户吊，所以在设计新的产品时，选择了稳妥，但是很难用的方案。这样的方案虽然难用，但不是不能用。可能想着得过且过，不背锅算了。

不过，如果同样的事情让我来做，可能会有不一样的看法。

在我看来，你可以因为业务的不稳定而被吊，这没问题，自己的技术力量不足，无法解决问题是应该被吊。但是如果你因为稳定，而不去做一些东西，这等于拱手将客户送人。我宁可被吊，但是用户要被我抓在手里。有了用户，我才能获取足够多的反馈，才能够让我以后不被吊。你把皮球都踢出去了，也把用户都踢出去了，yi以后你想要被吊，也没有机会了。

在我看来，一个 BaaS 、SaaS 层的服务，最好的三个状态是这样的：

让用户不能离开：因为你需要用户来给你反馈，来帮助你迭代，成功。你可能会做一些限制，不让用户离开。比如深度耦合的服务。
让用户不想离开：虽然有了竞品，但是因为你的好用，所以用户不愿意离开。你虽然应用户的需求，开放了数据导出等功能，但是用户还是很喜欢你的产品，不想离开。
让用户不愿离开：当用户发现，虽然有竞品，但是提供的服务依然不如你，切换过去了发现还不如你的时候，他就再也不愿意离开了。而且，当他试过一次别人家的业务，很失望以后，后续除非有什么特别大的利好，不然他不会再考虑离开你的服务。这个时候，你的业务就成功了。

此外，这个 Boss 的想法也让我觉得可笑，愿意背锅，敢于背锅是对自己开发团队、产品团队的信任，我信任你不会让我背锅。把锅甩出去了，表现了你对自己的产品、自己的团队没有信心。倘若团队离心，产品又怎么可能做好呢？