从我接触计算机开始到现在 Sublime 一直是我的主力编辑器,现代化的 UI、流畅的速度以及众多的插件,特别是各种开箱即用的特性,让他一直默默成为我的生产力助手。
我尽量避免使用各种 IDE,除非万不得以,有些工作不使用配套的工具十分麻烦,比如苹果的 XCode 和谷歌的 Android Studio。如果做 Android/iOS 开发,不用这些工具当然可以,但是绝对是不推荐的方案。第三方工具永远不会有官方的工具更新的快,同时,各种教程资料也不会针对第三方工具,一旦遇到问题只能靠自己解决,这个时间投入,是非常不值得的。
幸好我的主要技术栈都不需要 IDE,JS/HTML/CSS, C, Go 这些语言 IDE 当然可以有些帮助,但是和 IDE 的臃肿卡顿比起来,这些帮助就显得不重要了。
1976 年以前,所有的加密都是如下方式:
- A 使用某种规则对信息进行处理
- B 使用同样的规则对处理过的信息进行复原
这个方式很好理解,不论是非常简单的 ROT13 还是目前广泛使用的 AES,都是这种对称加密方式。
但是这种方式有一个巨大的缺点,那就是 A 需要将对信息进行处理的规则(也就是秘钥)告诉给 B。怎样安全地传输秘钥就成了一个非常棘手的问题。
那么存不存在一种方式,加密和解密使用不同的秘钥,彻底规避掉传输秘钥的问题?
答案是存在的,感谢数学家和计算机科学家,RSA 就是这样一种非对称加密方式,也就是:
- 使用算法可以生成两把钥匙 A 和 B
- 使用 A 加密的信息,使用 B 可以解开
- 使用 B 加密的信息,使用 A 可以解开
日常使用中,我们把一把作为公钥,公开发布。一把作为私钥,自己保留。这样,任何人都可以使用我们的公钥加密信息发给我们,我们则可以使用自己的私钥解开。
只要把私钥保存好,这个通信系统就非常安全。
之前用 Go 编写过一个简单的服务器和客户端,用来测试 Go 的 HTTP 性能,无意中发现了一个奇怪的问题。
在我的 Mac 上客户端程序会非常稳定地遇到 Connection Reset 的错误,让人一头雾水。
图片是大部分网页的重要组成部分,一般情况下,我们不会太关注这方面的问题,需要显示图片直接一个 img
标签搞定。
但实际上,无论是对于提高加载速度,还是对于优化用户体验,优化图片都是一个重要的手段。
图片优化分成两个方面:
第一,图片压缩。在保证视觉效果的情况下,减少图片的体积。这个很有效,1M 和 100K 的图片,肉眼看起来几乎差不多,但却省了 90% 的流量,大大提高了加载速度。
第二,响应式图片。根据客户端的情况,选择最合适的图片返回给用户。用户是一个 500px 的设备,那么返回 1000px 的图给他就是浪费。
我们先来看图片压缩。
代理的英文叫做 Proxy,是计算机中的常用软件。
简单来说,代理的功能犹如它的名字所示:代替某人来处理某事。
常见的代理分两种,正向代理和反向代理。不管哪种代理,它们都位于客户端和服务器之间,将我们传统的 客户端 <-> 服务器
通信变成了 客户端 <-> 代理 <-> 服务器
通信。
字符串是任何一个编程语言中的重要概念,同时也是一个非常复杂的问题。
日常编码中可能并不一定能见到它的复杂性,下面是几个字符串操作,使用你最熟悉的编程语言,看看结果如何。
- 逆转字符串
"noël"
,正确结果应该是"lëon"
- 获取字符串
"noël"
前三个字符,正确结果应该是"noë"
- 获取字符串
"😸😾"
的长度,正确答案应该是 2 - 字符串
"noël"
和字符串"noël"
规整化以后应该相等(他们看起来一样,但是内部表示不一样,一个 6 字节,一个 5 字节,这里涉及到 Unicode 的规整化)
对于大部分编程语言,包括 Ruby,Python,JS,C#,Java 等,上面的问题都无法全部返回正确结果(但是,拥有超强 Unicode 支持的 Elixir 可以)。
DNS 全称 Domain Name System
,是我们每天都在使用的基础互联网设施。
它被发明出来的原因很简单,计算机之间的通信用的是 IP 地址,是一串数字,人类记忆起来十分不方便,因此,我们给地址起个名字,然后将名字和 IP 之间的关系记录起来,这样,我们只用记住名字就行了。
从上面可以看出,DNS 系统类似我们日常使用的电话本,只不过里面存储的是域名和 IP 之间的关系。和人与电话之间的关系一样,一个域名可以有多个 IP,一个 IP 也可以有多个域名。
HTTP Basic Auth
是 HTTP 提供的一种验证方式,因为明文传输用户名和密码,非 HTTPS 环境下很不安全,一般用的非常少。但是在某些情况下用一用还是非常方便的,比如,一些静态站点例如文档系统可以使用 HTTP Basic Auth 进行简单的权限验证。
最近这段时间一直在忙着迁移博客,把原本基于 Jekyll 的博客迁移到了 Hugo 上。
之所以从 Jekyll 迁移的原因并不复杂,就是一个字:慢。Jekyll 的速度实在是太慢了,我只有几十篇文章,在 Watch 模式下,每次改动,重新生成都要花费 3 秒钟,实在是太慢了。
Regenerating: 1 file(s) changed at 2017-05-14 10:37:16 ...done in 3.085089 seconds.
Regenerating: 1 file(s) changed at 2017-05-14 10:37:20 ...done in 3.121783 seconds.
diff 是我们每天都要使用的一个功能,每次提交时,我都习惯先用 git diff --cached
看看这次提交更改了些什么,确定没问题,然后再 git commit
。git 生成的 diff 非常直观,直观到我从来都没有去思考过 diff 是怎么生成的,觉得这应该是很简单的一件事,两个文件做个对比,不就行了。