Posts

2017 关键词：Birds、离职、狼人杀、白洋淀、iOS、自如。 Birds Birds 是自己编写时间最长的一个 Web 项目。项目接手、改版、重构、迭代、盈利，上半年每天工作都是面对它。 Birds 良好的表现与需求互相推动，这点很重要，假如有需求而项目没有成长，或项目成长没了需求，对工程来说都只能是纸上谈兵、无事可做。项目中的规范的重要性，无论是代码还是数据库，只要项目不是夭折终将显现，对于规范性我绝不会开倒车，做任何妥协，种种经历只说明：这里欠的东西总会还。如何应对需求的千变万化，小结几点：模块化、组件化思想，功能多可配置，功能可拔插，功能方法粒度要小；不要对程序肆意进行打补丁式的修改，减少对流程入侵；当某一处的逻辑增加时要及时重新修改、定义流程；对需求目的的正确理解更是能高效开发。 对前端重新认识的一年。现在的前端和大学时刚刚接触时，已经大不一样了。前端能做的事情越来越多，很多业务逻辑都在前端处理，服务端只需要提供接口，分工合作更容易。浅尝 React Vue Webpack 后，也许前端才是自己的归宿。 离职 离职的不是我。老人走，新人来，新人走。离职一词在我身边跟了一年都没有停下来。同事离职的原因很多，离开北京、公司发展、自我发展… 马云说离职的原因就两个：1. 钱没给够。2. 受了委屈。我起初是认同这一说法的，但是后来觉得 “人” 或者说 “人的思想” 或者说 “人性” 在其中影响作用非常的大。相同的事情不同的角度看，结果相去甚远，如果基本的理念不同，那事情基本是无法调和的。 对做的事情的认同感，对自我的定位与认识，对现实情况的冷静思考，这几点需要反复咀嚼。 分享一篇文章：公司没大牛带，需要离职么？。对于刚入门的我们，这是一个很有代表性的问题。太多时候我们期待别人，忘了自己。公司有大牛，能跟着学是幸运，没有是常态。先接受了这个设定，会更容易找提高自己的方法。有没有大牛并不重要，我们是为了那个更好的自己。 狼人杀 2017 火的游戏很多：狼人杀、守望先锋、王者荣耀、吃鸡。狼人杀这一杀，好像杀到了毕业前和同学舍友在一起臭 high 的日子。可说骚话、互相 diss、互相吹捧，真真假假其乐无穷。最赤鸡的是鱼炸出了个女盆友，各路同学亲上加亲，无法克说。 白洋淀 我想 你说 你不要在孤单 让我做你的伴 白洋淀去过四次，那里的温泉过去两次，年中 Team Building 再喜加一，而这一次让这里有了美丽故事。喷泉、沙发，出现了对的人。 iOS React Native 的一波尝试后，走上了移动开发的道。Swift 让上 iOS 车的门槛降低不少，Swift API 趋向稳定，可以说这是最好的时候。GitHub 应该是再也放不下了，外文的书籍、文档确实靠谱啊，推荐一个教程网站 iOS Tutorials - Ray Wenderlich 真的零基础入门。 我相信：一个人语言的界限，就是他世界的边界。 自如 一场大火让无数人无家可归，年末换房也受牵连。被自如圈粉，其他中介的房子真的太 low 了。自如订房子居然也要抢，一波三折、失而复得。在没抢到房子时，真的想走，想离开这里了，很凄凉。最终是在公司对面住下了，过上了在家吃中饭晚饭的日子。 2018 Happy New Year 2017 自己是幸运的，2018 猥琐发育，不要浪，胜利属于伏地魔。 ...

主要内容：【历史穿梭】、【改变历史】、【Git 克隆】 历史穿梭 查看条件个数： git rev-list HEAD | wc -l 版本表示法：git rev-parse git rev-parse pick out and massage parameters for other git commands. --git-dir 可以显示 Git 版本库的位置 --show-cdup 当前工作区目录的深度 --parseopt 可以用于被 Git 无关应用用于解析命令行参数 # 显示分支，tag git rev-parse --symbolic --branches git rev-parse --symbolic --branches # 显示定义的所有引用 git rev-parse --symbolic --glob=refs/* # 显示多个表达式的 SHA1 哈希值： git rev-parse master refs/heads/master 6652a0dce6a5067732c00ef0a220810a7230655e 6652a0dce6a5067732c00ef0a220810a7230655e ^后面的数字代表该提交的第几个父提交，~<n>就相当于连续<n>个符号^ git rev-parse A~3 A^^^ e80aa7481beda65ae00e35afc4bc4b171f9b0ebf e80aa7481beda65ae00e35afc4bc4b171f9b0ebf # 暂存区里的文件和HEAD中的文件相同 git rev-parse :gitg.png HEAD:gitg.png fc58966ccc1e5af24c2c9746196550241bc01c50 fc58966ccc1e5af24c2c9746196550241bc01c50 # 在提交日志中查找字串的方式显示提交 git rev-parse :/"Commit A" 81993234fc12a325d303eccea20f6fd629412712 版本范围表示法：git rev-list git rev-list 可以帮助研究 Git 的各种版本范围语法。 ...

录制 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 无法图片加载的问题

在 Git 合并冲突时，git checkout --ours 和 git checkout --theirs 用于选择保留哪一方的文件版本，特别适合处理自动生成的资源文件等不需要手动逐行解决的冲突。 基本用法 # 保留当前分支的版本（丢弃对方的修改） git checkout --ours <file> # 保留传入分支的版本（丢弃当前分支的修改） git checkout --theirs <file> # 解决冲突后需要 add git add <file> 批量处理所有冲突文件： git checkout --theirs . git add . 场景实例 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，因为改到了同一行代码，出现代码冲突。以下两种方式 Engineer B 都在 feature-b 分支上操作： ...

主要内容：【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 等），所以单独作为软件包发布。 ...

简介 HTTP/2（RFC 7540，2015 年发布）是自 1999 年 HTTP/1.1 以来的第一次重大升级，目标是在 不改变应用语义 的前提下，改善延迟、并发和网络效率。浏览器端基本只在 TLS 上启用（h2），明文版本 h2c 仅用于内部服务间通信。 h2：HTTP/2 over TLS（最常见，浏览器只支持这一种） h2c：HTTP/2 over TCP（无加密） 设计背景 移动端和富媒体时代，请求量激增，HTTP/1.1 的队头阻塞、多个 TCP 连接并行带来的 慢启动/拥塞竞争 成为瓶颈。 谷歌的 SPDY 原型验证了“单连接、多路复用、压缩头部”等思路；IETF 在 SPDY 3.1 基础上标准化为 HTTP/2。 核心特性 特性 作用 二进制分帧 (Binary Framing) 把 HTTP 报文拆成小型 Frame；机器易解析、可并行 多路复用 (Multiplexing) 多个请求/响应 共享一个 TCP 连接，互不阻塞 流与优先级 (Stream & Priority) 每个请求是双向 Stream，可指定权重与依赖 头部压缩 (HPACK) 静态 Huffman + 动态表，大幅减少重复的 Header 字节 服务器推送 (Server Push) 服务器可在请求外预送资源 (已被多数浏览器弱化/关闭) 流量控制 端到端窗口，避免单个大文件占满带宽 开始实验 启用 HTTP/2 需要使用 HTTPS，请先参考 在本地环境使用 HTTPS ｜ ZYF.IM。 ...