Posts

主要内容：【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 的默认版本都是比较低的所以需要升级。 ...

获取 Nginx 反向代理后的客户端 IP，基本是按一定顺序检测以下参数中的信息： HTTP_CLIENT_IP HTTP_X_REAL_FORWARDED_FOR HTTP_X_FORWARDED_FOR REMOTE_ADDR 在未使用 CDN 和反向代理情况下 当业务服务器直接暴露在公网上，并且未使用 CDN 和反向代理服务器时，可以直接使用 remote_addr： $_SERVER['REMOTE_ADDR'] 这时候 HTTP_X_FORWARDED_FOR 和 HTTP_X_REAL_IP 都是可以被伪造的，但 REMOTE_ADDR 是客户端和服务器的握手 IP，即 client 的出口 IP，伪造不了。 在使用 CDN 和反向代理情况下 铁律 当多层代理或使用 CDN 时，如果代理服务器不把用户的真实 IP 传递下去，那么业务服务器将永远不可能获取到用户的真实 IP。 如果 WEB 服务器上层也是使用 Nginx 做代理或负载均衡，则需要在代理层的 Nginx 配置中明确 XFF 参数，累加传递上一个请求方的 IP 到 header 请求中。以下是代理层的 Nginx 配置参数。 proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_set_header X-NginX-Proxy true; 只有一层代理的情况 我们按上面的配置发起一个伪造请求，10.100.11.25 是我电脑的 IP，链路为： ...

self:: 调用本类属性、方法；可以抑制方法多态性。 parent:: 调用父类属性、方法。 static:: 调用静态属性、方法；可以体现多态性。 $this-> 调用本实例的属性、方法；$this:: 可以调用静态属性、方法；但是无法在静态方法里使用；可以体现多态性。 -> object-operator, you always know you’re dealing with an instance. :: scope-resolution-operator, you need more information about the context. <?php class A { public static function newStaticClass() { return new static(); } public static function newSelfClass() { return new self(); } public function newThisClass() { return new $this(); } } class B extends A { public function newParentClass() { return new parent(); } } class C extends B { public static function newSelfClass() { return new self(); } } $c = new C(); var_dump($c::newStaticClass()); // C and is same C::newStaticClass() var_dump($c::newSelfClass()); // C because self now points to "C" class var_dump($c->newThisClass()); // C var_dump($c->newParentClass()); // A because parent was defined *way back* in class "B" References php - When to use self over $this? - Stack Overflow

周末看了《摔跤吧，爸爸》，也是第一次独自电影院看电影，试写一篇影评纪念下。 注意：严重剧透预警。 主角爸爸是印度全国摔跤冠军，一心想着为国家赢取一枚金牌。可自己没能实现梦想，把梦想转移给了自己还未出世的孩子。可事与愿违，想要男孩的主角爸爸的前三个孩子都是女孩，第四个还是女孩。主角爸爸近乎要放弃为国争取金牌的梦想时，却意外看的了大女儿、二女儿身上的摔跤天赋。 主角妈妈在得知主角爸爸准备将女儿们训练为拳击手时，道出了 “你不能将你的梦想施加在女儿们身上”，主角爸爸沉思片刻 “给我一年时间，其间你不要插手，如果没成功，我将有永远放弃我的梦想”。在主角爸爸说出这句话之前，我是反对父母将自己的梦想让孩子去实现的，也更没有去争取过孩子们的想法，现实中这样做的父母我是常为 Loser. 但是主角爸爸的回答让我看到的不是一个：被自己个人梦想冲昏头，用孩子的全部去成就自己的父亲。主角爸爸是讲道理的，一年后如果失败也会甘愿放弃。坚持与固执的区别也许就在此。 主角爸爸变身为女儿们的魔鬼摔跤教练，每天除了上学就是训练，跑步时衣服不合适换男生衣服，找侄子当陪练，没有力量加餐牛奶、鸡肉，长头发难清理剪成了寸头。受苦中的女儿们找妈妈求情，主角妈妈遵守承诺，不干预主角爸爸的训练。这里真的要给主角妈妈点赞，后面女儿们的成功，女儿们、主角爸爸的努力在明面放着，而主角妈妈的守诺不干预，对主角爸爸的信赖，是同样的伟大。不然那柔弱的耳边风不知乱了多少坚定的意志。 训练太辛苦的女儿们采用消极怠工对抗主角爸爸。破坏闹钟、破坏场地、假摔示弱。而旷工一天参加好友的婚礼现场被主角爸爸收拾。在与好友诉苦时，才发现了：对比其他女孩一望到底的家庭妇女人生，主角爸爸的狠心是那样让人羡慕。 观念改变的女儿们开始主动训练。大女儿首次参赛就初露锋芒，差一点将男孩对手打败。逐渐成长的大女儿愈战愈勇的直到赢得全国冠军。全国冠军都会进入国家体育学校学习，大女儿也要离开主角爸爸接受新教练的训练，备战世界大赛。从小镇走出来的大女儿，没了主角爸爸的严格管束，开始着迷于这外面多彩的世界。吃油炸食品、留起头发、逛街、电影院。假期回家的大女儿用自己新学的技巧击败了主角爸爸，更是产生自我膨胀，对主角爸爸传统技术技巧的不屑与不信任。 国际大赛上大女儿频频失利，无能教练将此归为命运。与此同时坚信主角爸爸训练方式的二儿女也获得全国冠军，进入国家队。在二儿女和主角妈妈的劝解下，一通电话化解了大女儿和主角爸爸的隔阂。主角爸爸亲自来到体育学校，为大女儿备战下次的国际大赛。 主角爸爸在仔细研究大女儿对手后，制定了针对性的战术帮助大女儿杀入决赛。无能教练为了不让主角爸爸抢了自己的功劳，在决赛开始前将主角爸爸骗入小黑屋，无法让主角爸爸指导大女儿比赛。决赛第二局大女儿没能把握赛点，让对手追平。主角爸爸继续被困，只能默默祈祷。决赛最后一局，大女儿大比分落后，最后 10 秒大女儿脑海闪现着主角爸爸的叮咛，一击 5 分绝杀翻盘，赢得世界冠军。冠军的国歌声奏起，小黑屋中的主角爸爸也被路人解救，冲入赛场的主角爸爸与大女儿四目相对，此时这已经不是大女儿或主角爸爸哪一个人的冠军，而是所有正在与命运抗战者的胜利。 主角爸爸：“你是我的骄傲” 电影的专业手法和技术自己不懂，但是自己有个感觉：影片后期有大量的摔跤比赛，时不时有种看奥运赛的感觉，但是自己并没有感到乏味。电影故事情节很寻常，但是娓娓道来，很多细节小事让节奏不拖沓。故事人物有主角爸爸的理性和坚持、主角妈妈的守诺不干预、女儿们自我的成长、侄子的酱油加醋、无能教练损人为己 电影给我也留下了几个现实问题： 父母的认识经验一定比子女高的多，主角爸爸在看到女儿们的摔跤天赋时，狠心训练与女儿本身的意愿如何选择？ 父母逐渐变老，他们真的跟不上我们了吗？ 如何辨别无能教练的瞎指挥？ – EOF –

NGNIX 有两份 fastcgi 配置文件，分别是 fastcgi_params 和 fastcgi.conf，其区别只有一点点。到目前为止，由于 package managers，他们仍然引起新用户的混淆。 在自己系统中还有份 snippets/fastcgi-php.conf，这个又是啥？ fastcgi_params vs fastcgi.conf 它们都是用于配置 NGINX 与 FastCGI 应用程序通信的参数文件。 fastcgi_params: 包含了FastCGI应用程序所需的最基本参数，如SCRIPT_FILENAME、QUERY_STRING等。这些参数通常不需要修改。 fastcgi.conf: 包含了更高级的FastCGI参数，可以用于优化FastCGI应用程序的性能，如设置连接超时时间、缓冲区大小等。 fastcgi.conf 比 fastcgi_params 多了一行 SCRIPT_FILENAME 的定义 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 注意：$document_root 和 $fastcgi_script_name 之间没有 /。 原本 NGNIX 只有 fastcgi_params，后来发现很多人在定义 SCRIPT_FILENAME 时使用了硬编码的方式，于是为了规范用法便引入了 fastcgi.conf。 不过这样的话就产生一个疑问：为什么一定要引入一个新的配置文件，而不是修改旧的配置文件？ 这是因为fastcgi_param 指令是数组型的，和普通指令相同的是：内层替换外层；和普通指令不同的是：当在同级多次使用的时候，是新增而不是替换。 换句话说，如果在同级定义两次 SCRIPT_FILENAME，那么它们都会被发送到后端，这可能会导致一些潜在的问题，为了避免此类情况，便引入了一个新的配置文件。 server { listen 80; server_name foo.com; root /path; index index.html index.htm index.php; location / { try_files $uri $uri/ /index.php$is_args$args; } location ~ \.php$ { try_files $uri =404; include fastcgi.conf; fastcgi_pass 127.0.0.1:9000; } } fastcgi-php.conf fastcgi-php.conf 是一个 Nginx 配置文件片段，用于配置 Nginx 服务器与 PHP FastCGI 进程之间的通信。它定义了 FastCGI 连接的参数和选项，以及如何处理 PHP 脚本。通常，这个文件是在 Nginx 的主配置文件中包含的，以确保 Nginx 能够正确地将请求发送到 PHP FastCGI 进程。 ...

更新 2023-03-20 提问 ChatGPT 3.5 CGI（Common Gateway Interface）是一种通用的 Web 服务器接口标准，它定义了 Web 服务器和应用程序之间进行通信的方式。CGI 程序在每次请求时都会启动一个新的进程，处理完请求后就会结束进程，因此效率较低。 FastCGI 是 CGI 的一种改进技术，它使用长连接的方式，使得多次请求可以在同一个进程中处理，从而提高了效率。 PHP-CGI 是 PHP 的 CGI 版本，它可以让 PHP 脚本在 Web 服务器上运行，但由于 CGI 的低效率，PHP-CGI 的性能也比较低。 PHP-FPM（PHP FastCGI Process Manager）是一个用于管理 PHP FastCGI 进程的工具，它可以提高 PHP 的性能和稳定性。 关联和区别： CGI 和 FastCGI 都是 Web 服务器和应用程序之间通信的方式，但 FastCGI 在性能上比 CGI 更好。 PHP-CGI 和 PHP-FPM 都是 PHP 在 Web 服务器上运行的方式，但 PHP-FPM 可以有效提高 PHP 的性能和稳定性。 作用举例： 如果使用 CGI 或 PHP-CGI 来运行 PHP 脚本，每次请求都需要启动一个新的进程，效率较低。而如果使用 FastCGI 或 PHP-FPM，则可以使用长连接的方式，提高效率。 使用 PHP-FPM 时，可以配置多个进程，通过负载均衡的方式来分担请求，从而提高稳定性。 CGI Common Gateway Interface，HTTP 服务器与你的或其它机器上的程序进行“交谈”的一种协议，其程序须运行在网络服务器上。 ...

MySQL 5.7 对比 5.6 有很多的变化。一个常见的需求：按条件分组后，取出每组中某字段最大值的那条记录。其实就是组内排序的问题，我的做法是：子查询先进行倒序排序，外层查询分组。 示例 +----+----+-------+ | id | no | name | +----+----+-------+ | 5 | 5 | Mike | | 4 | 4 | Herry | | 3 | 3 | wyett | | 2 | 2 | John | | 7 | 2 | John | | 1 | 1 | Mike | | 6 | 1 | John | | 8 | 1 | Mike | | 9 | 1 | Mike | +----+----+-------+ 要求：取出每人（按 name），最大 no 的记录。 ...