我的博客能够保持日更，主要来说，是有两方面因素：
很多时候，我的写作都是要先取悦自己。所以我对于一篇博客的要求没有那么高，达到最低标准，300 字即可（这个也是微信公众号原创文章的要求），所以我不会有太多的心理压力，担心一篇文章是否足够完美。
我每天会看到大量的文章内容，这些文章内容可以激发我自己思考，并产生出新的灵感，通过这些新的摄入诞生的很多灵感都不够深刻，但确实可以写下我对这个问题的思考，并在后续的时间沉淀下，不断的重新思考、再次思考。
我常用的信息输入的平台：
如果你发现自己没有灵感，不妨试一试。
最近重读《番茄工作法》和《番茄工作法图解》，有一种预感，大家可能都用错了。大部分人用番茄工作法关注的是 25 分钟工作 5 分钟休息。但在我看来，这个可能是整个番茄工作法中最不重要的了，不同的人不同。你应该根据自己的实际情况来调整你的工作时长和休息时长。倒是背后的几张表格可能更重要。
番茄工作法中，包括三张表：「今日待办」、「活动清单」、「记录表」。
今日待办记录了今天要做的事情和突发的紧急事项，用于指导你在一天中的工作；活动清单则类似于 GTD 当中的 Inbox，收集了所有要做的事情；记录表则是存储了任务的元数据，可以用来对自己进行分析和指导。目前市面上大部分的工具都集中在如何做好定时器。对于记录表、今日待办和活动清单都没有做的特别好。 Session 算是比较好的，对于这些任务的数据有了展示。但在我看来，这个依然不够有效。主要是这里的数据其实是最基础的，对于形成反馈优化我们的时间和工作没有太多的帮助。
在我看来，番茄钟的基础是 25 + 5 的模式，来让你集中 & 放松。但想要保证 25 ，是需要「今日待办」中的「计划外和紧急活动」来保障的。不然待来的结果是要么 25 分钟费了，中间干别的了；要么是你 25 分钟倒是用好了，但计划外事项和紧急活动丢了。
至于活动清单，倒是相对简单一些，是 Inbox 以及进行任务的预估。Inbox 无需多说。任务的预估对于构建番茄钟的系统来说非常重要，你的精力是有限的，将精力用在有限的事情上需要你明确自己的精力状态和能做的事情，以及对要做的事情有明确的预估，才不会出现大面积 Delay 的情况。
记录表则用来追踪这些原始数据，并搭配着「今日待办」和「活动清单」一起来构建一个反馈系统，得出优化的结论。
上述的这些是现在的番茄钟工具大多没有关注到的。这些工具更加关注 25 分钟这个时间，但其实这是最没用的。
这也是为什么我现在又回到了纸笔的方式来使用番茄钟。不过我的做法可能过于原教旨主义了。明明这些事情用工具可以更好的解决，但我确实找不到更好的工具了。所以回归纸笔了。
Contact Form 7在实际使用过程中，有些人为了简化表单的设计和使用，会选择直接在多个地方使用同一个表单，并通过页面选择器来实现不同的样式（常见于基于 Elementor 构建的页面）。
但这样会造成长期的可维护性问题：
如果想要解决这个问题，有两个方式：
.blueBtn和.yellowBtn）；
收到了一封钓鱼邮件，刚好最近没有什么内容要写，就聊聊这一封钓鱼邮件。
我收到的这一封钓鱼邮件是这样的
接下来看看里面的钓鱼邮件设计的三个巧妙之处：
我的对外的邮箱目前使用的是 bestony@linux.com 的邮件，而由于 Linux.com 邮箱设计，实际上并不会有一个邮箱给你使用，而是你可以选择一个邮箱地址，系统会将发送到这个地址的邮件自动转发给你，我将邮件转发到了我自己的 Google 邮箱当中。
所以实际上我收到的邮件有两种：以 gmail 地址收到的邮件和以 linux.com 地址收到的邮件。
可以看到，上面的这个邮件当中我的收信地址是 linux.com 的地址，而不是我的 gmail 地址。
这正是这封邮件设计的巧妙之处：为特定人群发送特定内容的钓鱼邮件。试问自己：如果你的 QQ 邮箱收到了上述的邮件，你会把他当成是企业给你发送的安全邮件么？显然不会，因为你知道， QQ 不会给你发送这样的邮件。
但如果你的邮箱刚好是一个自定义域名，且刚好你所在的企业的 IT 并没有拦截到这封邮件，那么这封邮件对于那些安全意识不高的人来说，马上就会中招。
对于绝大多数人来说，可能对于内网地址和外网地址没感知。可能直接就点击进去了。但对于一些对于计算机网络略有耳闻的人来说，可能会熟记的一个地址是 192.168.0.1，这个地址被不少的路由器作为默认的地址和网关地址来使用，从而成为不少人的心中的安全地址。
邮箱中的 192.168.22.23 这个地址就会让一些人放下警惕，然后点击进去查看内容 —— 然后成功的掉进陷阱中。实际上邮件只是用内网地址来作为一个表面展示的文字，真正的链接地址是 http://szfdxled.com/function/uploadfile/20220412/20220412000529_78464.html#bestony@linux.com 。
这提醒了我们，如果邮件当中有链接，最好复制出来，而不是直接点进去（说不定别人替换了呢？）
我点击链接进去以后注意到，他在顶部加入了对应的邮箱域展示和 Icon 的展示。设计的挺巧妙。
如果点击进去展示的是无关的域信息，可能你也不会点击进去查看。但如果展示的是你自己的邮件域，会进一步放松警惕（特别是你以为你点击进去的其实是 192.168.xxx.xxx 时）。
对于意识不太强，或者平时不常使用网页版的人来说，可能真的就直接输入账号密码登录了。我还试了试，如果把 URL 后缀的邮箱域修改了，还会自动替换邮箱域和对应的 icon（应该是抓的 favicon，但不知道为啥抓到的是这个。
不过，也有一些设计的比较蠢的地方
在看这封邮件的时候，我注意到他设定了 Reply To 字段。Reply To 当中暴露了自己的 QQ 邮箱。
然后我搜了一下，发现能搜到这个人，看起来似乎还像是正常使用的 QQ 号。。。如果是一个经验丰富的 Cracker ，可能会选择使用一个更加安全的沟通方式。
这封钓鱼邮件中给我不少的启发，里面的一些设计也很有意思。但对于有充足安全意识的人来说，这些问题确实都可以规避掉，从而不受诈骗的影响。此外，Cracker 的产品设计值得我们学习，一些好的设计，确实可以帮助用户更省事。
我在听《知行小酒馆》第 35 期《E35 信用卡是危险的陷阱，还是好玩的工具？》时，听到了傅少爷的信用卡表单，突然有了一个灵感 —— 一个给个人的场景化信用卡助手。
其实有很多不同的信用卡助手，比如 51用卡助手、微信自带的信用卡提醒等常见的信用卡管理软件。但大多核心关注几个功能：
通过上面的功能，来实现尽可能的晚还款 & 尽可能的享受免息期。
我自己过去用这些信用卡助手是非常方便的，因为对我来说，我只关注是否是在还款日期还款就行，对于免息期等没那么在意。在我看来，计算那些优惠属实是太麻烦了。但在听了这一期节目后，确实让我打开眼界。主卡副卡、不同场景下使用不同场景的卡，这些点确实是我之前没有考虑过的。
所以，能不能有一个按照场景来做卡片管理的信用卡管理工具？
回到我的问题，那就推导出这个工具应该具备以下一些特性：
剩下的这些特性，就属于不是那么的重要，但可以有的功能：
商业模式很重要，决定了这个事情能不能长期做下去。这个功能一看就不是一个小事 & 涉及到了长期更新数据。因此，一个合理的商业模式可以让这件事持续的做下去。
答案是「否」，钉钉账号表面上是你自己的账号，但在企业的逻辑当中，这是「企业授权给你使用的」，本质上，这些都是企业的资产，企业是有权处置这些资源的。你所说的、所看的、所做的，都是企业提供的资产，企业可以根据自己的需求来调整这些资源的所在位置。
这是钉钉的不同的一点，在钉钉当中，任何一个账号，都是有对应的租户的（除了你的个人租户）。租户才是资源的所有者，我们只不过是使用者。 而我们使用的微信、QQ 其实也不是我们的，在微信的用户协议当中写明了，我们所拥有的不过是微信账号的使用权。只不过，因为腾讯离我们很远，我们可以认为不会对我们执行任何操作（当然，实际上如果你发一些不和谐的内容，也会被设置为内容自见），但在钉钉中，租户的管理员可能就是我们身边的同事，在这种情况会更有「隐私」和企业所有的对比。
7.1.2 微信帐号的所有权归腾讯公司所有，用户完成申请注册手续后，仅获得微信帐号的使用权，且该使用权仅属于初始申请注册人。同时，初始申请注册人不得赠与、借用、租用、转让或售卖微信帐号或者以其他方式许可非初始申请注册人使用微信帐号。非初始申请注册人不得通过受赠、继承、承租、受让或者其他任何方式使用微信帐号。
综上所述，你的账号，并不属于你。
一直以来，创业圈都有 To B 和 To C 的两个赛道。而对于我目前所从事的事情来说，我愿意将之称之为 To Dev 业务（简称 To D）。
为什么是 To D？
在过去，很多时候企业的产品要么是针对 C 端用户，直接卖用户给广告商，我们称之为 To C；也有很多企业是通过为其他企业提供资源，来获取收益，我们称之为 To B 。
To Dev 的业务本质上都是 To B 的生意，因为 To Dev 本质上是在要求开发者背后的企业来进行相应的费用支付。
但 To B 往往会让人误以为这个场景很大，所以我常说 To Dev（或者是 To 小B）。
To B 走的是上层建设的路线，产品往往是由上层确认，下发至业务团队，业务团队直接使用。举个例子来说，小米使用的是阿里云，原因是从集团层面看到阿里云很好用，所以我们批量采购，大家直接使用。
To Dev（To 小B）则是一个相反的路线，走的是农村包围城市。通过提供优质的产品，来促使开发者使用产品、离不开产品、为产品付费。
为什么会是这个路线？
过去，我们看到大量的大企业在使用 To B 产品。但随着 To B 时长的不断发展，越来越多的企业已经完成了 To B 的业务的采购，在这个时候，再想通过 To B 的方式来完成资源的购买，是十分困难的，因为已经被占位了。
在这种情况下，我们就要开始去观察那些还在成长的市场，比如初创团队、新产品团队。对于这些团队来说，他们一方面依然可以采用之前采购的资源。但同时，之前采购的资源可能有着这样或者那样的问题，让团队成员困扰。而新的解决方案可以更加简单的解决问题之时，这样的团队便有动力去试用这样的产品。
而这样的团队注定是如繁星一遍，遍布各个地区，传统 To B 场景下的销售就不适用了， ROI 太高。则需要在产品体验方面做到极致，让开发者可以更愿意选择自己的产品。
我因为 NESHouse 为不少人所知，而我播客主播的身份让不少人找我问，你怎么看 ClubHouse？
我的一贯观点是，这种临场感很好，但也是一种限制，要求我必须在特定的时间点到达特定的地点。
而之前在飞聊中沟通过，我不认为 ClubHouse 模式是可以与播客之类的相对抗，核心原因是其中的内容没有经过精心设计，在制作上很难产出精良的作品。
今天刚好看到了一个明确的案例：
知乎会将站内的信息组织成一个知乎周刊，而下面的截图就是知乎的一个周刊的截图。整个周刊看起来组织的井然有序，但当你真正的点开周刊的内容，却充满了不适。
比如说，「我比较同意李楠的看法」，那「李楠的看法」在哪里？读者看到这句话，丈二和尚摸不着头脑，又如何很好的读下去呢？
在做软件产品时，我们会无限的追求极致，希望将产品的体验、用法等各个方面全部做到最好，因为软件的交付成本低于硬件的交付成本，我们只需要一个命令，就可以将旧版的软件升级到新版。因此，我们可以通过不断的软件迭代，来将一个不完美的软件，迭代到完美的状态下。 而硬件则不同，硬件涉及到两个问题：
上述两个原因，导致我们永远不可能买到完美的硬件产品。
我以产品经理的角色参加了一个 Hackthon，整体下来体验一般。
我并不是一个一般意义上的产品经理，可以帮助你把产品细节做到极致（毕竟研发出身，满脑子都是代码）。我更擅长的是产品的流程的确定和推进。这些优势在 Hackathon 其实没有用，原因是 Hackathon 对于这个并不在意。
Hackathon 更在意的是产品的创意以及创意最终的实现。前者需要的是创意的提出者，由他来进行进一步的头脑风暴，推广。后者需要项目经理和全体团队的配合，快速推进。
唯独不需要一个单独的产品经理，来进行具体的产品需求策划。