昨天在宜家买了个钟表，仔细研究后发现，这个产品的设计非常的有意思，完美的表现出在已有设备加，加入一些小巧的传感器，从而实现一个非常有意思的产品。这也是我觉得当下，我们的互联网产品、软件产品、硬件产品在设计方面所缺乏的。
我买的产品是宜家的 LÖTTORP 洛托普，我买了个百搭的白色表。
初次看到这个表，其实有点其貌不扬，常规的显示屏和四个莫名其妙的 Icon。
背面倒是不错，只有电池仓和两个按钮，十分的简洁。
这个表设计的有意思的点在于他在内部嵌入了一个传感器，通过这个传感器来感知钟表此时的方向，从而实现控制展示不同的功能。通过这样的方式，来实现了在一个钟表当中，集成了多个钟表的能力。
下面的视频，是我自己录制的视频，可以帮助你直观的看到这个设备的操作方式。
作为公司内的员工，你可能会被激励员工的“内部创业”所打动。但你要知道的是，你可以做内部创新、可以在螺狮壳里造道场，切不可在其中投入你的感情和心力。
这里的矛盾在于，你使用公司的资源做内部创业，你所有的产出，其实是归属一公司所有的。你可以用公司内部创业的路子去做所有你不那么看重的事情。但如果你真的看重一件事，且愿意为之付出极大的心力、劳力，那么一定要跳出来自己做。
跳出来，还有生的可能，留在企业内部，一定会死。
原因很简单，随着业务的高速发展、团队的扩大，创始人提供的价值会越来越少，慢慢跟不上自己的团队的迭代。这个时候公司有几个选择：
这种变化，如果不是你心爱的产品还好，但如果是你心心念念的产品，一次就够你万念俱灰了。
既然都是风险，干嘛不出来做呢？
从另外一个角度来看，因为你是「内部创业」，那么你就必须遵循企业的大规范。如果企业的战略有调整，作为企业战略当中的一份子，你的业务必须被砍掉的时候，你应当如何自处？自然是跟随企业的战略调整，不然还能怎么办？
最后的结论你会发现，还是自己出来干最省心。
今天，我想和你聊聊我从 2020 年开始加入生财有术，到 2021 年续费，再到 2022 年决定停止续费的心路历程。
在 2020 年之前，我其实是对生财有术不感冒的。和大多数人一样，我的理解是「既然有赚钱的事情，你为什么不留着自己做，而要分享出来」。
这也是生财有术在很长一个周期上在面对的外界的指责。
加入生财有术源自于一个契机，我朋友圈的老朋友，工程师，技术总监 —— 朱鹏飞同学在朋友圈发了生财有术的推广，于是乎我想了想，基于对他的信任，加入了生财有术。
我的目的也非常明确：我自己是一个工程师，是一个创造者。我擅长的是创造一个东西，而不是把一个东西推广的更好。生财有术中的经验贴可以帮助我看到别人是怎么思考同一个问题的，可以为我补充更多的信息。
于是乎，我在生财有术开始疯狂的了解信息，还参与了深圳和北京的活动，还因为一次轻享，获得了一颗龙珠，加入了龙珠群。
生财有术提供了我想要的信息，帮助我理解了不一样的世界，看到了不一样的选择。
在这个阶段，我也领悟出为什么有的人愿意分享自己的心得给别人，总的来说，其实是「我知道这个东西能赚钱，但是这个钱太少了，我懒得做，顺手发给你也行」
基于这个思路，我还启发了一个人做了保罗 · 格雷厄姆的中文站点
但到了 2022 年，我为什么开始选择离开？其实核心点在于我意识到，生财有术提供的价值对于我来说，开始逐渐发生了变化。以及价格的上涨对于我来说，意味着 ROI 不符合预期。
一方面，生财有术开始从提供信息，到提供更加丰富的活动和交互转变。虽然依然会有提供信息，但对于我来说，活动所带来的溢价对我没什么价值，我并不太需要持续参与一个活动。
另一方面，得益于知识星球的机制，即使我不再续费，我依然可以看到之前我买的内容。现有的 3000 多篇精华我都没看完，完全不着急续费。
从这个角度来看，知识星球真的不错。
在写这篇文章的时候，我也在想，既然不适合我了，那适合谁？毕竟，生财有术是一个社群，不可能适合所有人。
先说说为什么不适合我：我自己是有一些明确的标签的「工程师」、「创作者」，本身有在做个人品牌影响力方面的事情。对于我来说，我需要的是补充信息，丰富自己的品牌。当现有的信息已经无法处理的情况下，那么我完全没必要马上获得更多的新信息来满足自己 FOMO 的情绪。我需要的不是去发展更多的横向业务，而是让自己在纵向业务上发展的尽可能好。所以短时间来看，生财有术并不能提供我所需要的东西。
再说说适合谁：
唠唠叨叨这么多，总体来说，就是一句话 —— 不匹配了。但不匹配我，不意味着不匹配你，如果说上面我描述的这些你觉得符合你的诉求，那生财有术依然是一个符合你预期的社群。
在进行互联网产品设计时，常常会说，「我们要关注用户价值」，但似乎落实到现实中，大家都默认选择了一个更短时间的价值 —— 用户走过我的摊位，我要产生多大的交易额？用户访问了我的网站，给我产生了多少的收入？
多年「羊毛出在狗身上」的免费互联网模式，让我们下意识以为，我们只有「羊毛出在狗身上」才能够赚钱，我们不得不从流量大潮中分流出一部分，经过过滤，再将其回归到流量的大潮里。
这个思维有一个最大的问题是：我们提供给用户的价值是短暂的，是会停止的。但实际上，一个用户可能是会持续的使用你的产品的，在这个过程中，你是完全有可能在一个更长的周期产生出更大的价值。
不过这里也有一些问题在于，为什么过去的产品不会太过于关注这个问题？一方面是品牌建设并非绝大多数产品会考虑到的，甚至很多产品直到产品火了，才开始关注到品牌建设。另一方面是更长期的模式需要损失短期的收益，对于企业和产品来说，能否扛到看到长期收益是个问题。
不过，对于独立开发者而言，完全可以猥琐发育，直到看到产品的长期价值。
很抱歉，虽然我年纪稍长，对于很多人来说，都还是一个小朋友，但依然要用一个非常老气横秋的口气来和你讨论关于「竞争」这个话题。因为有太多的人来问我关于竞争的问题。我不得不选择将我的观点和建议整理成一篇文章，以减少我重复介绍自己观点的次数。
在竞争中，常常被大部分人忽略的是，竞争并非是静态的。实际上，由于竞争中存在的软门槛和硬门槛的不同，使得竞争往往是动态的。
竞争中最常见到的是硬门槛，也是我们一般而言，给到新人的建议 —— 你必须去做某些事情，不然你就会付出极大的代价。比如，最常见的是，我们给到每一个年轻人的建议是你应该读完本科。如果你是专科，那就努力专升本。或者想办法走成人高考，获得一个本科的文凭。
硬门槛的意义在于它真的可能在关键问题上，阻止你进行下一步。比如说，对于航天科技的核心工程师来说，相关专业的文凭就是硬门槛，如果没有对应的文凭，相关的企业和单位是不敢录用你的，因为你完全可能为航天事业埋下后患。
除了硬门槛，被很多人忽视的就是软门槛，以及，很多人会把软门槛认知为硬门槛。和硬门槛不同，软门槛不会成为你能够完成某个职位工作的阻拦，但软门槛会成为别人筛选你时的重要标准。在你求职时，你有没有某个证书、你有没有某个认证，都只是你求职过程中的软门槛。不要将软门槛看作是硬门槛。硬门槛是用来筛掉不适合的 60% 的人的，而软门槛则是用来选出想要的 20 % 的人。剩下的 20% 的人，就是那些符合了硬门槛，但无法跨过软门槛的人。
对于绝大多数的人来说，面对的竞争往往都是全方位的。你并没有什么异于常人的特点，你和你的竞争者并没有什么不同。这个时候，你们并没有太大的差距。但倘若你拥有一个和其他人不同的优势， 这个优势就会成为提升你综合评分而获得选中的重要因素。
绝大多数的时候，竞争即会看你的所有竞争条件，希望尽可能选择一个足够好的候选人。另一方面，如果你在某些点上特别的突出，就能够让你自己成为被选中的佼佼者。
如果你的某个技能超出统一领域的其他人一个数量级的水平，那么即使你的其他能力不够强，依然可以获得青睐。但作为普通人的我们，应当有这样的自知之明，是否是这样的人。
对于一般来说，我们都认为高学历带来的是更大的竞争优势。但是，高学历也会为你的选择来到沉没成本。这些沉没成本会让我们失去一些可能性和选择。
当然，失去的可能性未必是坏事，也可能是一件好事。但作为选择的人来说，确实会有可能担心庙小容不下大佛而不愿意选择，将你从当前的选择中踢出。换句话说，高学历意味着某些事情，你再也做不了了。
我自己是一个很喜欢看书的人，所以买了很多平台的电子书会员（Kindle、微信读书、华章书院），但一直以来，都有一个问题在困扰我，就是如何确认一本书在哪个平台上有？。
虽然下意识上我们认为不同的电子书平台上的书籍应该是相同的，但在实际的操作层面，确实是有所不同的。受限于版权、出版社合作关系等等，有些书可以在微信读书上找到，但无法在 Kindle 上找到；有些书可以在图灵社区找到而无法在 Kindle 找到。
这使得作为读者的我十分困扰，如何才能更加明确的知道我想看的那本书在那个电子书平台上能找到。
终于，现在有了这个工具 —— eBooks Assistant 油猴脚本
这个脚本通过自己实现的爬虫，爬取了各平台拥有的电子书数据，从而实现在你访问某个豆瓣电子书页面时，告诉你那些平台有对应的电子书，一键跳转到对应的平台进行阅读，降低搜寻电子书的成本。
脚本地址：https://greasyfork.org/en/scripts/412479-ebooks-assistant
一直以来，我其实对于人工智能赋能于个人十分关注。
信息流算法帮助我们获取到了更多的信息。但在体验信息流算法的时候， 也看到了算法推荐的另一个反面 —— 我们被算法控制，算法让我们相信它希望我们相信的东西。
为此，我开始抗拒算法推荐，开始使用一些更加传统的方式来完成我的信息获取 —— 使用 RSS 来阅读新闻；使用 Apple Music 来收听信息。实际上，近几年的 Newsletter 的复兴，也是一种对于算法推荐的对抗。
但这不过是我在时代的洪流之下的微弱的抵抗，并不能从根本上解决信息茧房的问题。也很难让自己得到满意的结果。究其原因，是因为现有的算法代表的是企业的利益，而不是个人的利益。现有的算法推荐都是由企业定义的，而非个人定义的。所以无法让算法真正意义上为个人服务。
我们的算法和 AI ，还需要更加的普适。
最近在 V2ex 上看到一个「8 万变80 万」的帖子，描述了作者作为独立开发者，希望借助独立开发获得自由，但最终负债累累的故事。我将作者的犯下的错，进行了梳理，得到了以下的结果，将其分享给你，帮助你来梳理自己在做的事情。
在你读下面的内容之前，我建议你先读一读作者的两个帖子，这样让你对于作者有更多的理解。
做外包开发和做独立开发是不一样的，独立开发你没有甲方帮你托底，你所面对的需求也是不明确的。而在这样的一个大背景之下，在尚未完成产品的原型和需求验证的情况下，投入数年来开发一个产品，可以说是非常愚蠢了。当然，我知道很多研发同学出来做东西都是这个问题。切忌不可闭门造车。有些东西没人做不是因为只有你慧眼识珠，也可能是你碰上了一个假需求。
ALL IN 如果成了，固然很漂亮。但 ALL IN 在绝大多数的时候是在悬崖上走钢丝。现实生活中并没有那么多故事给你听。很多时候为什么一些创业者去找 VC 投资？还不是为了给自己增加一些保护，不要让自己的创业影响到自己的生活。ALL IN 对于独立开发者而言，不可取。
前期没有现金流的情况下，低成本运作，小步快跑。
作者在一开始就学了 WordPress、Angular、Unity 等一系列技术，严重的分散了其精力。
任何人进入新的领域都应该做的是专攻一门，快速建立自己的能力和影响力，站稳再研究另外的领域。
短板的问题短期可以通过外包来解决。特别是发现自己耗费很长的时间都不能做好一件事，这个时候就应该花钱让别人来解决这个问题。不然只会让自己的时间一直浪费下去，失去了重要的机会。
在作者的另外一个帖子你会发现，很早就上了杠杆。而且是在没有现金流的情况下上杠杆，那除了利滚利，还有其他的选择？
杠杆适合放大你的收益，而不是放大你的错误。
在作者的两个帖子里你可以发现，他有不少的精力都放在了注册美国公司，办理相关的事情上了。一方面，信息差让他以为只能这么干。另一方面，推出一个产品的时候并不一定需要先有收款选项。
用户如果真的需要你的产品，他会比你还想要付款给你，因为怕你死了。
Milestone 是给自己的一个压力。此外，也是给自己一个休止符。如果时间足够，我们总是能发现自己还有各种 Bug 和 Feature，但是无休止的开发会让你失去自己的状态，也可能会让你在错误的道路上越走越远。
产品还没有 release 就开始「微服务」，典型的被技术公众号和大厂忽悠瘸了。你什么业务规模啊，就上微服务。微服务的好处和代价思考过适合你么？
资本不仅仅能帮助你提供金钱的支撑，还可以给你提供更多的视角，比如你这个业务是否值得做？你的这个业务的发展是否还有别的点是你没关注到的？资本公司
就像我们说，跳槽不是为了从当前的火坑逃出去，而应该是看到了更好的机会。
他创业的原因是看不惯现有的工作单位。初心不对，意味着全凭运气。初心不对，心态不对，一旦遇到问题，可能就会给自己造成很大的压力。
首先，在文章的开始，我先要强调，我并不是绝对不使用社会化读书软件（如：微信读书），但我使用微信读书有自己的方式。
接下来是具体的观点内容
在各种购买推荐的时候，你都会发现，所有针对 Kindle 的推荐都会提到 「无打扰」，这同样是我推荐你看纸质书/Kindle的原因。
作为手机不离身的一代人，我们现在已经习惯了「被打扰」，但不意味着这是对的，不断的被打扰，让我们无法集中精力去做应该做的事情。当我们不断被打断，我们就更应该去寻找稀缺的集中。
而在这件事上，无论是纸质书还是 Kindle ，都可以实现类似的效果。你可以沏一杯茶（或者是煮一壶咖啡），将手机关静音，放在另外的房间里，拿着一本书，或者是你的 Kindle ，在桌前仔细的阅读。
你可能会担心自己看不到消息。但这世界上有多少事情是「你一个小时不看手机」就会产生问题的。
借助一个和通讯设备分类的工具，我们可以很好的实现想要的「宁静」、「专注」的效果。
但这些，社会化读书软件是无法实现的。
几乎所有的企业都希望开发出一款拥有「网络效应」的应用。
网络外部性（network externality），又称网络效应（network effect）或需求方规模经济（demand-side economies of scale），指在经济学或商业中，消费者选用某项商品或服务，其所获得的效用与“使用该商品或服务的其他用户人数”具有相关性时，此商品或服务即被称为具有网络外部性。 最常见的例子是电话或社交网络服务：采用某一种社交媒体的用户人数越多，每一位用户获得越高的使用价值。
对于企业来说，网络效应是一个很好的工具，可以帮助留下用户，但对于用户来说，一方面它的工具性随着网络效应而获得提升，但另一方面，我们也会因为网络效应而被限制在应用当中。
微信读书等一系列社会化软件会通过产品功能的设计，让你不断的被触发，不断接入其中，让你读书也不会那么的纯粹和集中。评论、弹幕，都不断的把你从阅读中拉扯出来，进入到一个社会化的环境当中。
包括从某种角度来看，我在 B 站/ Youtube 上看视频的时候，也很少会开启弹幕（除非我看的内容本来就是很无厘头的内容），我会希望能够静下心来安安静静的欣赏一个作品，而不是不断被拖走，不断的被打断。
我在前面提到过，我其实并不是完全不使用微信读书。我自己使用微信读书的场景是这样的：
我最近开始日更博客，开始逐渐捡起我的写作的习惯，并尝试以此维持生计。
不过，我自己写文章有个坏毛病，比较意识流，这使得我的文章当中会出现很多的错别字。由于心流作用的存在，写作时我自己无法发现这些问题。
所以，我会在写完文章后，将其复制到微信公众号后台，并使用微信公众号后台自带的语法检查工具，来完成中文的基本信息的检查，降低我的错误率。
当然，除了微信公众号，你还可以有很多选择，比如 飞书文档、石墨文档等。
只是我为了让自己能够用的更爽，自己做了个插件 —— https://wordpress.org/plugins/wpstoreapp-spellcheck/
在大型企业当中，往往会有各种各样的 CI & CD 工作流来完成项目的部署，而对于我自己的项目而言，我也希望能够有这样顺畅的交付体验，因此，我也为自己的业务加上了类似的方案，以实现顺滑的开发体验。
不过，我没有做的那么重，没有上 Ansible，也没有封装 Docker，就是标准的 LNMP 环境。只不过，我在标准的环境上加入了 Laravel Envoy — 一个快速部署工具。
Envoy 是 Laravel 团队开发的一个在远程服务器上执行某些命令的工具，因为他同样使用 Blade 语法，因此在 Laravel 项目中接入非常方便。
Envoy 有多种使用方式，一种是跟随项目的使用方式，即使用 composer require laravel/envoy --dev 来安装，并使用 php vendor/bin/envoy 的方式来运作，这样的好处是你无需污染顶级目录，只在项目层面使用 Envoy 来进行部署。
不过我因为有很多项目，所以我会更加倾向于直接在全局安装 envoy，执行 composer global requre laravel/envoy 实现在全局安装 Enovy。全局安装完成后，当你需要执行命令，只需要执行 envoy run deploy，就能执行当前目录下所定义的命令。
除了全局安装，你也可以考虑使用 Bash alias 来实现类似的效果，将
envoyalias 给php vendor/bin/envoy就可以实现即使没有全局安装，也可以实现不需要手动输入前缀的特性。
当你需要配置时，你要做的很简单，只需要执行 envoy init 服务器地址/昵称就可以获得一个 Envoy.blade.php 文件，你可以通过修改这个文件的内容，来实现定义不同的工作。同样的，你可以将这个文件纳入到版本控制系统当中，从而实现部署脚本的跟踪和定义，对于后续的持续维护比较有帮助。
因为 Envoy.blade.php 也是采用了 Blade 的后缀，所以也同样适用了 Blade 引擎，你可以通过一个语意更加友好的方式来定义你的脚本。
@servers(['web' => '127.0.0.1'])
@task('deploy')
cd /path/to/site
git pull origin master
@endtask比如，上面的脚本就是一个最基础的脚本，首先定义了这个脚本的命令会在名为 web 的服务器上执行，而这个服务器的地址是 127.0.0.1；并定义了一个任务 deploy。
当你完成代码的编写，并提交了 Git 之后。执行命令 envoy run deploy ，就会自动的在 web 这个服务器上执行在 deploy 当中执行的命令。
deploy 的命令只要是正常的 bash 命令即可。
因为 Envoy 使用 Blade 语法来编写，你也可以使用 Blade 语法中的命令来引入其他文件的中的任务。因此，你可以将自己常用的命令定义出来，并将其通过 Packagist 发布出去，并在实际应用过程中，引入对应的文件来使用。
@import('vendor/package/Envoy.blade.php')Envoy 支持定义多个服务器以及并行执行，对于架构相对复杂的业务，你可以定义不同的 servers ，并在对应的 task 当中来设定需要在哪些 Server 上执行。定义任务时，如果你传入了 parallel 参数，则可以控制命令同时在多个服务器上并行（该属性为 false 时则是串行（
@servers(['web-1' => '192.168.1.1', 'web-2' => '192.168.1.2'])
@task('deploy', ['on' => ['web-1', 'web-2'], 'parallel' => true])
cd /home/user/example.com
git pull origin {{ $branch }}
php artisan migrate --force
@endtask你可以在 Envoy.blade.php 中加入 @setup 来完成变量的定义，并在后续的代码中使用。
@setup
$now = new DateTime;
@endsetup也可以直接使用 @include 来引入文件
@include('vendor/autoload.php')
@task('restart-queues')
# ...
@endtask在启动时，如果你使用诸如 --param=value这样的参数来调用，则可以在你的代码中直接读取对应的变量，从而实现执行时带入不同的参数。
Envoy 当中还有更多的用法，这里不再一一列举，如果你感兴趣，可以直接参考其官方文档，了解如何使用 Envoy 达成你的部署目标。
在你不是很着急使用 Ansible 或 更重的部署工具的时候， Envoy 是一个不错的选择。特别是你使用 Laravel 进行开发时，Envoy 就是一个有效的工具。
多年来，我一直是 PHP 的拥趸，不论中间我写过多少编程语言，但我始终觉得，PHP 能从 2000 年活到现在，是有其意义和价值的。
而到了现在，我终于可以回答这个价值和意义到底是什么 —— 什么样的业务，使用什么样的架构。
作为技术创业者，我们最常遇见的问题，便是过度设计技术方案：我的项目是不是应该做个数据库主从备份？我的项目是不是应该做 Kuberentes 集群来处理弹性？
但实际上，对于绝大多数的业务而言，这些问题都是根本不重要的 —— 如果没有 Kubernetes，我们能否保证我们的业务的稳定性？如果没有主动备份，我们能否保障我们的业务可以平稳运转？
技术在绝大多数的业务中，都是一个成本中心，是一个保障业务正常运转的基石。他应该被重视，但不应该被过度重视。一个创业公司可能会因为业务不够稳定而失去用户，但绝不会因为业务非常稳定而留住用户。用户在乎的是你为用户解决了什么样的问题，而不是用了什么样的架构。
过度（提前）优化是万恶之源。