录制 GIF 推荐使用 LICEcap 小巧好用。 GIF 查看方法 在 Mac 上双击 GIF 将是按帧查看一幅一幅的图片，按住 空格 可以动起来。也可以选择 GIF 图片直接点击空格预览。 GIF 编辑 预览 在 Mac 中可以直接使用 预览 对 GIF 进行删除帧的操作。但是发现再次保存的 GIF 只播放一次，不会循环播放。 Photoshop 使用 Photoshop 打开 GIF，点击 窗口 -> 时间轴，可在时间轴中对图片进行编辑。文件 -> 导出 -> 存储为 Web 所用格式 然后在 循环选项 选择 永久。 在这里也可以降低 图像大小 对图片进行压缩。 点击 存储 导出新的 GIF。 – EOF –
遇到的问题 在编写 GitHub 的 README.md 后，其中引用的网络图片无法正常显示，点击 alt 的文字提示：Content length exceeded。 分析 根据 About anonymized image URLs 这篇文章：上传的图片 URL 将被修改，所以个人信息将不会被跟踪。GitHub 将使用 开源项目 Camo。Camo 将为每一个图片生成一个以 https://camo.githubusercontent.com/ 匿名代理 URL 同时隐藏来自其他用户的浏览器详细信息和相关信息。 我引用的 GIF 图片有 7MB 多，那么图片大小的限制是多少？ camo - server.coffee#L18 content_length_limit = parseInt(process.env.CAMO_LENGTH_LIMIT || 5242880, 10) 换算后大小正好是 5MB。 References 关于 GitHub 无法图片加载的问题
Ubuntu ssh -oProxyCommand="nc -x 127.0.0.1:1080 %h %p" ubuntu@111.111.1.1 Mac ssh -o "ProxyCommand nc -X 5 -x 127.0.0.1:1080 %h %p" ubuntu@111.111.1.1 SecoureCRT Session Options - Connection - SSH2 - Firewall，创建、选择代理。 参数 -o ProxyCommand：SSH 命令选项，你可以理解成使用 “在 SSH 中使用代理”。 nc：netcat 命令。 127.0.0.1:1080：本地 Shadowsocks 的监听地址和监听端口。 命令行 HTTP 代理 export http_proxy=http://127.0.0.1:1087;export https_proxy=http://127.0.0.1:1087; 鉴别自己是否真的使用了代理来登陆服务器 root@ubuntu:~# who root pts/2 2017-05-13 18:13 (xxx.xxx.xxx.xxx) References Mac OS 使用 shadowsock 来代理 ssh 访问服务器 – EOF –
现在自己的开发主力机是：2015 版的 MacBook Pro。对于工程师来讲，MacBook 绝对是用来提高生产力的，不是装杯的。如果条件允许十分推荐，反正我是回不来了。 一些感受 购买型号选择：15 寸 i7 Pro 没的说，屏大看的很爽。 F1… 等键并有没有原来想象的那么重要，游览器刷新什么的都有代替的键。我感觉 F 系列的键默认为功能键挺好的。Filco 键盘开始吃灰。 续航时间是真的长，待机功耗很小，不用关机。扣上盖子装包带走，不拿充电线。 触控板真的好用。原来都是没鼠标时不得已才用触控板。(后来发现老司机们都爱触控板) 鼠标 - 滚动方向：自然，需要适应。 Chrome Tab 随便开。 很安静。 装包时边沿有些割手。 软件推荐 2020-03-25 更新： My MacBook | Yifans_Z。 – EOF –
在代码合并时遇到 conflict 是常有的事情，有些内容是自动生成的资源文件，手工处理起来很麻烦，某一文件如何全部以某一分支的内容为准？ 使用 checkout --theirs . checkout --ours .。 场景实例 Engineer A、B 同时从 master checkout 自己的功能分支： # Engineer A git checkout -b feature-a # Engineer B git checkout -b feature-b Engineer A 开发比较快先进行了 push： git add . git commit -m "feat: feature-a" git checkout master git merge feature-a git push Engineer B 再 push 前需要拉最新的 master，因为改到了同一行代码，出现代码冲突。 merge 合并代码 使用 merge 命令导致的代码冲突。 git checkout master git pull git merge feature-a 在处理冲突的过程中： ...
主要内容：【Git 基本操作】 Git 基本操作 先来合个影 在 Git 里，“留影”用的命令叫做 tag，更加专业的术语叫做“里程碑”（打 tag，或打标签）。 git tag -m "Say bye-bye to all previous practice." old_practice 里程碑无非也是一个引用，通过记录提交 ID（或者创建 Tag 对象）来为当前版本库状态进行“留影”。 git rev-parse refs/tags/old_practice 41bd4e2cce0f8baa9bb4cdda62927b408c846cd6 git describe 显示当前版本库的最新提交的版本号。格式：最近的 tag - 距离此 tag 的个数 - 该提交的 SHA1 git describe old_practice # .. commit something git describe old_practice-2-g8861c65 删除文件 rm *.txt 针对的是 工作区，对 暂存区 和 版本库 没有任何影响。 git rm detached-commit.txt hack-1.txt new-commit.txt welcome.txt 删除动作加入了暂存区，commit 后在版本库罪行提交中删除了，在历史提交中尚在。 ...
主要内容：【Git 重置】、【Git 检出】、【恢复进度】 Git 重置 分支游标 master 的探秘 git log --graph --oneline * e695606 which version checked in? * a0c641e who does commit? * 9e8a761 initialized. 引用 refs/heads/master 就好像是一个游标，在有新的提交发生的时候指向了新的提交。 Git 提供了 git reset 命令，可以将“游标”指向任意一个存在的提交 ID。注意下面的命令中使用了 --hard 参数，会破坏工作区未提交的改动，慎用。 git reset --hard HEAD^ HEAD is now at e695606 which version checked in? 用 reflog 挽救错误的重置 通过 .git/logs 目录下日志文件记录了分支的变更。默认非裸版本库（带有工作区）都提供分支日志功能，这是因为带有工作区的版本库都有如下设置： git config core.logallrefupdates true 查看一下 master 分支的日志文件 .git/logs/refs/heads/master 中的内容。 tail -5 .git/logs/refs/heads/master Git 提供了一个 git reflog 命令，对这个文件进行操作。 ...
主要内容：【Git 初始化】、【Git 暂存区】、【Git 对象】 Git 初始化 设置一下 Git 的环境变量，这个设置是一次性的工作。即这些设置会在全局文件（用户主目录下的 ~/.gitconfig）或系统文件（/etc/gitconfig）中做永久的记录。 配置的用户名和邮件地址将在版本库提交时作为提交者的用户名和邮件地址。 git config --global user.name "Jiang Xin" git config --global user.email jiangxin@ossxp.com 设置一些 Git 别名，以便可以使用更为简洁的子命令 只在本用户的全局配置中添加 Git 命令别名： git config --global alias.br branch git config --global alias.ci "commit -s" git config --global alias.co checkout git config --global alias.st "-p status" 版本库的初始化 mkdir demo cd demo git init 初始化空的 Git 版本库于 /path/to/my/workspace/demo/.git/ git init 命令的后面直接输入目录名称 cd /path/to/my/workspace git init demo ls -aF ./ ../ .git/ 这个隐藏的 .git 目录就是 Git 版本库（又叫仓库，repository）。 ...
Git 是一款分布式版本控制系统，有别于 CVS 和 SVN 等集中式版本控制系统，Git 可以让研发团队更加高效地协同工作、提高生产率。使用 Git，开发人员的工作不会因为频繁地遭遇提交冲突而中断，管理人员也无须为数据的备份而担心。经过 Linux 这样庞大的项目的考验之后，Git 被证明可以胜任任何规模的团队，即便这个团队的成员分布于世界各地。 Git 是开源社区奉献给每一个人的宝贝，用好它可以实现个人的知识积累、保护好自己的数据，而且还能与他人分享自己的成果。 版本控制的前世和今生 即便是在 CVS 出现之前的“史前时代”，也已经有了非常好用的源码比较和打补丁的工具：diff 和 patch，他们今天生命力依然顽强。 对这 hello world 两个文件执行 diff 命令，查看两个文件的差异。如下所示： diff -u hello world | less -N 上面执行 diff 命令的 -u 参数很重要，使得差异输出中带有上下文。管道后面带有 -N 参数的 less 命令（按字母 q 退出）会在输出的每一行前面添加行号，便于对输出结果进行说明。 命令 patch 相当于 diff 的反向操作 分布式版本控制系统最大的反传统之处在于，可以不需要集中式的版本库，每个人都工作在通过克隆操作建立的本地版本库中，也就是说每个人都拥有一个完整的版本库。分布式版本控制系统的几乎所有操作包括查看提交日志、提交、创建里程碑和分支、合并分支、回退等都直接在本地完成而不需要网络连接。每个人都是本地版本库的主人，不再有谁能提交谁不能提交的限制，加之多样的协同工作模型（版本库间推送、拉回，及补丁文件传送等）让开源项目的参与度有爆发式增长。 爱上 Git 的理由 每日的工作备份。鸡蛋不全放在一个篮子里。 异地协同工作。通过一个远程版本库，同步数据。 现场版本控制。在部署的现场，进行源代码的修改，能够将修改结果甚至修改过程一并带走，并能够将修改结果合并至项目对应的代码库中。 避免引入辅助目录。只在工作区的顶级目录下创建名为 .git 的目录（版本库目录），如果认为唯一的一个 .git 目录也过于碍眼，可以将其放到工作区之外的任意目录。一旦这么做了，你在执行 Git 命令时，要通过命令行 --git-dir 或环境变量 GIT_DIR 为工作区指定版本库目录，甚至还要指定工作区目录。 重写提交说明。这个命令如果不带 -m 参数，会进入提交说明编辑界面。 git commit --amend 想吃后悔药。假如提交的数据中不小心包含了一个不应该检入的虚拟机文件——大约有 1 个 GB。 git rm --cached winxp.img git commit --amend 更好用的提交列表。正确的版本控制系统的使用方法是：一次提交只干一件事。而不要在下班时才想起来要提交，那样的话版本控制系统就被降格为文件备份系统了。 更好的差异比较。git diff 工作进度保存。 git stash git checkout <new_branch> # do something git checkout <orignal_branch> git stash pop 代理 SVN 提交实现移动式办公。 无处不在的分页器。-p 快。Git 作为分布式版本控制系统几乎所有的操作都在本地进行。 安装 Git sudo aptitude install git sudo aptitude install git-doc git-svn git-email gitk 软件包 git-svn、git-email、gitk 本来也是 Git 软件包的一部分，但是因为有着不一样的软件包依赖（如更多 perl 模组，tk 等），所以单独作为软件包发布。 ...
2015 年 5 月 14 日 HTTP/2 协议正式版的发布，越来越多的网站开始部署 HTTP/2 了。 HTTP/2 协议是从 SPDY 演变而来，SPDY 已经完成了使命并很快就会退出历史舞台（例如 Chrome 在 2016 年初结束对 SPDY 的支持；Nginx 在 15 年年底正式支持 HTTP/2 后，也不再支持 SPDY）。 HTTP/2: the Future of the Internet | Akamai 提供了 HTTP/1 和 HTTP/2 的加载速度对比。 HTTP/2 中的特性 多路复用：通过多个请求 stream 共享一个 TCP 连接的方式，解决了 HTTP1.x holb (head of line blocking) 的问题，降低了延迟同时提高了带宽的利用率。 压缩头部：HTTP/2 规定了在客户端和服务器端会使用并且维护“首部表”，来跟踪和存储之前发送的键值对，对于相同的头部，不必再通过请求发送，只需发送一次。 二进制分帧：在应用层与传输层之间增加一个二进制分帧层，以此达到：在不改动 HTTP 的语义，HTTP 方法、状态码、URI 及首部字段的情况下，突破 HTTP1.1 的性能限制，改进传输性能，实现低延迟和高吞吐量。 以下配置是在 Ubuntu 14.04 LTS 下。Ubuntu 14.04 LTS 中 Nginx、OpenSSL 的默认版本都是比较低的所以需要升级。 ...