Becomin' Charles

Electronic Frontier Foundation 简称 EFF，是一个具有领导地位的非盈利组织，致力于在数字世界捍卫公民自由。建立于 1990 年，EFF 通过影响诉讼，政策分析，基层行动以及技术研发，捍卫用户隐私，言论自由以及创新。该基金会的试图通过努力保障，在技术进步的前提下，人们的自由和权力也受到相应的保护。

在 Mac 系统下开发 PHP 的话，使用 MAMP Pro 来搭建环境是一个不错的选择，主要还是因为方便，一口气就可以拥有 PHP + MySQL + Nginx + Apache + PostgreSQL + Memcached + Ruby + Python + Perl，可以说 Web 开发的全部组件基本都涉及到了。

我想，我使用 NetBeans 已经有很多年的历史了，但是比较遗憾的是，这些年来，也没有把 NetBeans 的功能用到极致。这点挺令人遗憾的，但是我还是坚持使用 NetBeans，主要我信奉一点，就是用什么 IDE 不重要，重要的是你能把它用到多高的效率。

什么是 HSTS？

HSTS 是 HTTP Strict Transport Security 的缩写，字面意思就是“HTTP 严格传输安全”。在 2012 年 11 月发布了 RFC 文件。其实质，是通过服务器和浏览器配合起来，强制用户使用安全连接来访问服务器。

哪怕到了最近几年，数据库被黑客完整下载的安全事件，也是层出不穷，程序员世界戏称为“脱裤”，好像光屁股一样羞耻。比如，刚过去不久的 CSDN，小米，多玩，等等事件都还历历在目。所以，程序员写代码决不能抱有侥幸心里，用户的密码，是最最隐私的东西，一定要妥善处理，一旦泄露，会给用户和服务网站都带来不可估量的损失。

今天下午，我在 Yii 框架 1.x 下，写一个数据处理脚本，脚本的功能主要是把一个超过百万行的表中的两个字段，同步到一个新表中。按照一般的想法，我写了如下的代码。

以前，用 Windows 系统的时候，我学会了“粘滞键”这个专有名词，其含义，就是当按下一个键盘按键，并且保持不动的时候，系统应有的表现。

比如，一般来说，我们期望系统的行为是连续打出多个按键的字符。 我初始安装 Mac 系统的时候，按下一个按键，在 Terminal 等原生的 App 上，其行为是符合我们的预期的。但是，因为我是程序员，我使用 NetBeans 作为开发环境，当我连续按下一个键的时候，我发现，在 NetBeans 里面，只能出现一个字符。

经过咨询同事，问到了一个系统设置：

1
2

defaults write -g ApplePressAndHoldEnabled -bool false
defaults write com.microsoft.VSCode ApplePressAndHoldEnabled -bool false

这个设置项，需要使用命令行来执行，类似一个隐藏设置，其含义是，是否由 Apple 系统来接管 按下并保持 这个行为，如果由系统来接管这个行为，则在某些应用中，系统会比较智能地处理这个行为，比如，在 NeaBeans，其判定为只打出来一个字母。如果，使用如上的设置项，则关闭此行为，系统不要插手这个行为的响应，由相应的 App 来处理这个行为，则可以出现我所预期的结果。

我个人入行以来，最早接触软件包的概念，是从 Java 开始的，Java 所有的代码，都必须属于一个软件包。如果要调用某个现成的类库，就要 import 一个软件包，就可以使用那个软件包里的所有代码了。

然后，又在操作系统层面接触了包管理器，那是最初使用 Linux 的时候，我接触的第一个发行版是 RedHat，非付费版本的 RedHat 没有包管理器，只能自己解决类库依赖，简直就是地狱。直到遇到了 Ubuntu 的 apt-get，又瞬间来到了天堂。

其实很早就听说了 Docker 了，这正是现在世界上最炙手可热的容器技术。直到去年 2015 年，我们公司才有小伙，尝试使用 Docker，当时，我们公司是全 Mac 办公，而 Docker 只支持 Linux，于是各种非官方爱好者，做出了各种方案，比如当时，如果要在 Mac 上用 Docker，就必须安装一个 boot2docker 的组件，是一个在 Mac 上使用 Docker 的封装，同时还要依托 VirtualBox 才行，当然也有 VmWare 的版本，但是又是收费的。

关于编码规范，每个程序员都有自己的看法，他们通常相信自己所奉行的规范是好的并且早已养成习惯，有些看法的意念特别强大，以至于上升到了一种信仰层面。
我个人觉得，编码规范不是个人习惯，比较好的态度是，信奉编码规范可以提升大家的效率，而坚守一个团队的编码规范，而不是，坚守某种固有的做法。至于
某种规范的条例是不是“很奇怪”，“不合理”，我们都可以讨论，但是讨论不代表不遵守，这才是比较职业化的态度。或者说，即便通过讨论，认定某个规范不合理，
我个人觉得，也应遵守这条不合理的规范，直到整个团队一致变更编码规范。