其实我也希望遵守 80 字符，但是 Django 官方的配置文件中就存在超过 80 个字符的行，这就没办法了，只好扩大要求。
我的 VSCode 使用的是 Pylint，所以可以通过在编辑器设置中，添加如下代码实现。
"python.linting.pylintArgs": [
"--max-line-length=100"
],将限制放宽到 100 个字符，不会太影响视觉，也能很好的符合规范。
前段时间承接了 李长太老师的博客，由于我惯用 PHP 7 ，所以李老师的博客也被我放在了 PHP 7 的站点上，但是由于使用的主题是第三方仿的，在使用中出现了非常多的问题。
比如：无法正常加载主题设置项、开启 Debug 后显示非常多的报错。在这里记录一下，以备后用。
这是因为使用的函数调用的是传统的 1，2，3来表示权限，但是用户等级早已弃用，将其中的用户等级修改为权限名即可。
add_menu_page("主题设置", "主题设置", '10', 'sevenstar_theme', array(&$this,'sevenStar_Theme_Options_Form'),'dashicons-carrot','777');
// 改为
add_menu_page("主题设置", "主题设置", 'manage_options', 'sevenstar_theme', array(&$this,'sevenStar_Theme_Options_Form'),'dashicons-carrot','777');
这一块主要是渲染表单出了问题，所以这里就只需要将对应的用法改为 php7 的即可。
$this->$option['type']( $option )
// 改为
{$option['type']}( $option );这个更为简单，只需将类名对应的构造函数改为 __construct即可
最近几天，由于看电脑太多（16h+/day），所以眼睛痛、流泪，无法直视屏幕。
今天早上起来，从房间出来，一看外面，流泪。原来眼睛已经连强光都受不了了。休息了好一会，才反应过来。
然后我去发了条朋友圈。
我不知道有多少人和我一样，出现了问题，会第一时间发朋友圈。
发完以后，自我检讨，我这种不分事态严重程度，先发朋友圈，难道不是「娱乐至死」么？
不过好在，我并不完全「娱乐至死」，在发朋友圈之前，我先到丁香医生中，找了位眼科的医生，先咨询了一下。总归是有些正常的点。
有些时候，一句话就能让我推翻之前下的所有决定。
今天 GitChat 被攻击，上了高防以后，发现无法进行微信支付。
进行简单的排查后，发现问题出在后端，导致无法进行排错。
我们在创业前期时，可能会大量的 try…catch,来确保我们的代码可以顺利走通，但是 catch 到的 error 往往直接抛掉，不做记录。
这在前期创业时，非常有用，因为我们需要将业务快速上线；但是一旦遇见问题，这种操作的危害就暴露出来。调试极为不方便。
这就是欠下的技术债。我推荐他们使用 ELK 来做日志的记录和分析。不做日志，后端真的很难排错。估计要 review 一遍代码
GTD 工具的使用是循序渐进的。我最早用 奇妙清单，太卡，换了。然后用的滴答清单，功能很强大，但是过于复杂，让我有点想逃离。后来买了 Things 3 ，用着还不错。最近换成了 Todoist，工具很重要，但也不重要。找到合适自己的。
我在写博客之余，会去运营微信公众号和今日头条的头条号。
和很多同行不同，我很能写，甚至可以说，比大多数同行都要能写一些。这得益于我自孩童时期而来的阅读习惯，如今虽然读书比当年少了很多，但依然会大量的去阅读，获取大量的信息。
在我看来，想要写一篇推文，关键是你要有文章内容的输入，有了输入，输出自然不是难事。
我的写作也基本遵循「采集信息」——「挖掘灵感」——「收集相关素材」——「动手实践」——「归纳整理」——「形成文章」。
只需要这几步，我的推文大体上就形成了， 剩下的就是花精力对文章的内容、细节进行调整，输出一篇合格的文章。
不过，在写博客时，就显得随意一些，因为博客更多来说，是我吐槽的地方，所以，你不太可能会在这里看到一些特别正经的文章，除非技术类（对技术的尊重我还是有的），随笔类型的内容就真的只是随笔了。