软件维护有两种截然不同的思路，一种所有的依赖都追踪最新版，一旦出最新版立即开始试用，出问题马上反馈社区或者解决，这样虽然经常需要适配新版，但每次都是小问题，很快就能解决。这是活着的软件，虽然每天都要吃饭很麻烦，但你能看见它的新陈代谢。

另一种所有的依赖都选择一个不会变的固定版本，能不升级就不升级，旧版本的bug想办法workaround，这种软件的开发者害怕改变，能推到明天的工作绝对不在今天做，并且喜欢以“项目规模太大，客户要求严格，风险太高”为理由，得过且过，这种是死掉的项目，只是还没有埋而已，在这种项目上你会发现做变更也特别困难，许多现代项目里非常常见的功能根本加不进去（因为依赖库不支持）

活着的项目可能会死，死掉的项目是几乎不可能再活过来的，落后太多版本，一旦升到最新版就发现到处都是问题修不过来了，因为没有跟踪过依赖的版本变更，也搞不清楚可能是什么问题。像JDK这种已经算好的了，不兼容的情况一般比较少，但JDK都不肯升，依赖库肯定也全是JDK6版本的了，要把依赖库直接升到10，只能选择死亡了。

作者：灵剑
链接：https://www.zhihu.com/question/30137699/answer/476916096

以上为知乎上的一个回答. 个人觉得如果对于自己非常熟悉的第三方依赖, 并可以把握风险的话, 还是会不断的去追求最新版本. 毕竟对于新事物的好奇心是活在一个优秀程序员血液里的东西.

本文简单记录了Hexo Next主题升级版本(v6.3.0 → v6.4.0)的完整过程.

效果图, 太 cool 了, 可惜只有新加的文章才能开启:

在我们的项目中, 每次 push 代码后, gitlab 的 runner 会自动执行一次 flake8 代码静态检查. 当然在本地也可以在终端中手动触发, 但缺点是如果检查出 10 个问题, 我要重复 10 次复制粘贴文件路径在 Pycharm 中修改的操作.

今天突然发现可以在 Pycharm 中利用 External Tools 集成 flake8 检查, 点点鼠标就能到具体的代码位置。

有时候走在路上, 总会觉得来来往往的人群就像一只只没有思想的僵尸. 慢慢的自己也被欲望和忙碌的工作剥去了自己的思考, 决定每年都开一篇博客, 记录生活中零零散散的思考.

和女朋友的日常:

我: 哇, iOS12 正式版终于出来了, 太酷了!!! 我帮你的手机升级吧.
cc: 我不要

我: iOS12 很棒的哟, 流畅的一 b! 你手机上乱七八糟的消息都被折叠了, 并可以一键永久关闭推送. 多了防沉迷的功能, 统计你每天玩了多久的消消乐. 还能自动填充验证码呢!
cc: 哦

我: 你听我说, 这次和之前 iOS11 不一样了, 升级系统手机不会变卡的.
cc: 我不听我不听, 就是骗人换手机的.

我: 要不这样, 我帮你手机升级, 我带你吃好吃的怎么样?
cc: (思考 ing...) 好呀!!

所以有个勇士一个月前就加入了公测(Public Beta), 总结了 iOS12 中的一些新特性, 用来说服女朋友升级系统!

最近我们的Django项目供Java Sofa应用进行tr调用时, 经常会出现一个异常: django.db.utils.OperationalError: (2006, 'MySQL server has gone away'). 本文记录了分析, 本地重现与解决此问题的全过程.

原因分析:

Django在1.6引入长链接(Persistent connections)的概念, 可以在一个HTTP请求中一直用同一个连接对数据库进行读写操作.
但我们的应用对数据库的操作太不频繁了, 两次操作数据库的间隔大于MySQL配置的超时时间(默认为8个小时), 导致下一次操作数据库时的connection过期失效.

Our databases have a 300-second (5-minute) timeout on inactive connections. That means, if you open a connection to the database, and then you don't do anything with it for 5 minutes, then the server will disconnect, and the next time you try to execute a query, it will fail.

MWeb2.0 一直是我写博客的主力编辑器, 因为它真的很优秀, 为我写博客带来了无数的便利. 所以看完 MWeb3.0 的新特性(特别是新的 UI 设计和快速搜索的功能), 就原价在 Apple Store 拔草了. 但有一句说一句, 对此次的更新个人表示有一丝失望, 因为用了 MWeb3.0 几个小时后, 我又退回了 MWeb2.0, 233333...

接上篇博客, 尝试在GCP的OSS上部署静态博客受挫之后, 痛定思痛, 决定先做一个小小的调查, 再敲定最终的部署方案. 这时候搜到一篇非常棒的文章: 静态网站托管服务平台的横向方案比较. 正是在这篇文章中, 我第一次了解到了Netlify. 并一见钟情了, 因为在Net整个部署过程中, 你只需要提交代码, 其余的master部署预览(包括MR的预览), HTTPS证书, 静态资源的优化与CDN加速, 部署消息通知, 等等都不用再操心. 真的是太优雅了XD