两个多月前，我重构了支付服务苹果IAP部分代码，完善了苹果支付逻辑；大半个月前，以加强可维护性为目的重构了用户服务的代码；上周三开始，以同样的理由，重构了支付服务剩余的代码。这三次重构工作，前前后后加起来得有一个月工作量，这里进行总结：到底重构了什么。

为什么需要学习iptables ?
Linux防火墙、NAT、Kubernetes等很多地方都用到iptables，了解它很重要。

本文主要信息来源是netfilter官网推荐的iptables教程。

本文目的：了解iptables原理；了解iptables配置方法，看懂iptables配置脚本

三方登录常需要客户端和服务端共同完成，对OAuth2，客户端获取授权码，服务端用授权码换取访问凭证；对OIDC，客户端获取ID Token，服务端验证其正确性用以登录之类的场景。但两端又常非同一个开发人员，服务端逻辑写好后需要客户端配合获取授权码或ID Token作为输入进行调试验证。这样效率太过低下，协调上会有困难。

最好是服务端能够自己获取输入参数，这里介绍常见的四种登录方式的简单调试方法：微信登录、Apple ID登录、Google登录、Facebook登录。

我每篇博客的书写都是有动机的，它们或是对一段时间的工作总结、或是对某个事物的感悟。这次要写X.509的博客，是因接入IAP时，从网上搜索的各种问题发现一个惊人的事实：很多人不知道X.509证书的验证方式，当然也包括我。

灰度发布、蓝绿发布、金丝雀发布等，本质上没有区别，都是版本渐进式发布+流量管理，所以也不要去纠结自己的发布方式到底算哪一种。硬要说，灰度发布是渐进式发布的统称，蓝绿发布和金丝雀发布是渐进式发布的具体方式，详细区别，在于蓝绿发布强调蓝绿环境（即新版和旧版服务）的平等性，流量拆分粒度较粗；金丝雀发布拥有更细粒度的流量拆分。

问题

我们到底应该如何测试？

TDD的想法是非常美好的；单元测试、集成测试、系统测试、验收测试等构成的测试金字塔是非常美好的；通过测试，尽早地将问题暴露出来的想法也是非常美好的。但测试带来的收益和成本应该如何衡量呢？大团队应该如何测试？两三个人的小团队又应该如何测试？

如果你所在的团队已经有明确的测试规范，那不用操心这些问题；但如果是专注业务的小团队，各方面尚未有明确规范，测试应该做到什么程度，会是一个值得思考的问题。

记一个卡了两天的问题

TL;DR;

2021年10月，苹果发布了StoreKit2。新API和流程看起来更加简化，但是苹果官方文档并没有让开发者接入变得简单，调试起来也是各种问题，这方面和StoreKit1一样做的不好。梳理是必要的。

文章描述由一个问题引起的解决方案思路的探究以及最终的实践，具有借鉴参考意义。

记一记k3s+rancher搭建遇到的问题，使用感受。

Infrastructure as Code，将基础设施以代码的形式管理起来，放在git仓库中。Kubernetes的清单文件就是一种
gitops = Infrastructure as Code + version control + Pull/Push Request + CI/CD流水线。即，将维护在git仓库中的基础设施代码，以git仓库的方式进行开发、权限管理，再在CI中做正确性检查，然后CD交付到具体基础设施。
此处，需要维护的基础设施，即Kubernetes。

项目开发时，会将整个项目各生命周期工作一一列出，总体规划，使得进度可控。

对个人而言，是一样的道理。凡是预则立，不预则废。想做的事很多，东一榔头西一锤子不是办法，得有规划。

最近发现之前基于notion构建的计划模板已经不够用了，于是又折腾个新版本。

总的来看，我的个人任务管理大概分为三个阶段

• 阶段零：使用有道云笔记做简单记录，列举近期要做的事项，极其简单，相当于没有规划
• 阶段一：使用notion做了一个年度计划、月计划、周计划模板，预先填好一周要做的事，做完后勾掉
• 阶段二：使用notion一年半后，根据新需求基于notion的database重新构建的任务模板

Kotlin与Java百分百互操作，顺理成章，Spring开发也可以用Kotlin。可以享受到Kotlin的简洁语法。二者结合的大部分特点，在尝试之后都能体会。本文列举一些实际开发中最容易遇到的问题。

是不是最佳不知道，反正它是个实践！

工欲善其事，必先利其器。写单元测试，需要三类工具

• 测试平台：JUnit、TestNG
• Mock框架：Mockito、MockK
• 断言框架：AssertJ、Assertk

当开发语言为kotlin时，推荐JUnit5 + MockK + Assertk的组合。