Gitlab-shell 1.1.0 的 SSH 访问异常

从 GitLab 4.2 升级到 5.0，虽然 步骤 有点儿繁琐，但还算是一路绿灯，但最终却遇到了不能以 ssh 方式访问库的问题。搞了几个小时，找了所有能想到的地方，都搞不清楚究竟哪里错了，于是在 github 上给提了个 issue 3578。

问题的情况简单来说就是，ssh -T 成功，但是 git clone/pull/push 却意外失败，另外 http 的方式是成功的，说明应该还是连接的问题。

唯一有可能存在疑问的地方，应该是 gitlab-shell 的版本。检查的时候会报告说需要 1.1.0，而事实根据升级指引中的操作结果是 1.2.0 的。但从 另一个 issue 的说明 看来，可以通过修改 check.rake 来实现“瞒天过海”。

暂停了 gitlab service，然后切换 gitlab-shell 的版本到 1.1.0

> cd /home/git/gitlab-shell
> git checkout v1.1.0
> git checkout -b v1.1.0

# 配置文件不需要改
> ./bin/install

重启 gitlab 后再试试 ssh -T git@mygitlab.com

结果却出错了！

/usr/local/lib/ruby/1.9.1/json/common.rb:148:in `parse': 743: unexpected token at '<html> (JSON::ParserError)
<html>
<head>
<title>Welcome to nginx!</title>
</head>
<body bgcolor="white" text="black">
<center><h1>Welcome to nginx!</h1></center>
</body>
</html>
'
     from /usr/local/lib/ruby/1.9.1/json/common.rb:148:in `parse'
     from /home/git/gitlab-shell/lib/gitlab_net.rb:24:in `discover'
     from /home/git/gitlab-shell/lib/gitlab_shell.rb:28:in `exec'
     from /home/git/gitlab-shell/bin/gitlab-shell:16:in `<main>'

为什么会出现这个错误，我没什么头绪，google 了一轮也没什么对症的答案。

要出现默认的 Nginx 页面，应该还是跟 Nginx 的配置有关，而哪个配置文件是从网上下载的，唯一就是指定了 IP 以及域名。就算直接用 IP 访问，也是可以看见 GitLab 的页面的，但是不会看见 Nginx 的默认页面。

这时，我想起之前曾经改过 /etc/hosts

127.0.0.1   mygitlab.com

如果在服务器端访问 http://mygitlab.com 的时候才会看见 Nginx 的默认页面。果断去掉这个 host 设定，然后再试，一切都正常了。

嗯嗯，具体什么原因要加这个 host 设定，不太清楚了，装 4.2 的时候的事情了。反正 gitlab-shell 1.1.0 跟它有冲突。不过应该算是 gitlab-shell 的问题，它不应该解析出域名的 IP 后直接用 IP 去访问，因为有可能一个 IP 上会挂好多个站点，默认的不一定就是 gitlab。

有时候指定 hosts 能解决一些问题，也有像这种帮倒忙的情况，能不加还是不加吧。

PS: mygitlab.com 不是一个真实的域名。

Update 17 Apr: Issue 3384: Gitlab can’t clone or push

转移 VirtualBox ubuntu.vdi 后的网络连接问题

由于磁盘空间的问题，需要迁移 vdi 文件去新的位置。关闭，转移，新建 Ubuntu 虚拟机直接引用转移后的 vdi，其它都保留原有的设置，一切都很好。

唯独启动后，ifconfig 一看就发现问题了，只有本地网络了。

一开始还是以为是 VBox 网络连接的问题，反复试了几次，问题依旧，而其它虚拟机同样的配置却可以正常运作。经过一翻 google，最终从 这里 得到启示。 

> sudo mv /etc/udev/rules.d/70-persistent-net.rules /etc/udev/rules.d/70-persistent-net.rules.bak

删掉应该也是可以的，重启之后问题就解决了。

学什么语言工资最高？

这次要标题党一回了。如果是铁了心只跟随大风向的，请忽略下面的内容。

在 V2EX 上看到这么一个标题 学什么语言工资高？…，内容我也没看，只是纳闷，为什么现在的人都肤浅到这种程度，稍微有点常识也该知道，这种问题是最不该问的。

有印象是，曾经有人做这方面的调查，语言跟工资之间的关系研究，不过貌似统计的都是国外的，而且不知道具体是哪个国家的。如果，有人根据这些调查结果去指导自己的工作，我是实在很好奇但又不忍心看结果啊。

从我个人经验来看是，初工作时，用什么语言并不是自己决定的，而是实际项目决定的。读书的时候就学那么几招，真实的经验是在项目做的过程中累积的，当然还少不了项目以外，自己心血来潮做的各种尝试。用什么语言能带来多少工资，以及能带来多少价值，是没什么关系的。因为，在整个过程中，学到的并不紧紧是编程语言，还有许多其它的行业经验，设计原则等等，如果自己能紧紧把握住这些，那么会慢慢累积成自身的经验，这样带来的价值是长久的，并不是工资所能衡量的。除了实际价值，如果还能给自己带来快乐，那就更加美妙了。

每个人起点不同，但是如果硬把起点跟工资绑上关系的话，最终收获的可能仅仅是工资。我们可以把眼界放宽一些，在起步的时候多给自己几个机会，如果对编程有兴趣，绝对可以多学几门语言，多将编程用于解决生活的具体问题上。

我一直认为语言跟工资之间的关系研究，一方面是反映供求关系，一方面在说明，某种语言在改变世界方面的能力，或者说是影响力。而调查的结果是过去一段时间的人们所做出的努力和贡献，新的时期会有新的影响力格局。无论我们选择什么语言，我们只要用好它来实现改变，就是在累积新的影响力。

我不会煮什么鸡汤，只是把实际情况描述了下。

真的免费？

最近挺忙的，都没什么时间写文章，但是却有给 blog 换个 theme 的念头，刚好看到一篇标题是 14 Free WordPress Themes… 于是就点进去看了看（其实这种坑爹的文章，已经上当很多遍了，但还是无意识啊），还看中了两个，再点进去看，哦原来都是要钱，不过方式很不同。

一个是有三种套餐让你选择，免费那个套餐只是个皮，我需要的东西是要钱的。另外一个是说“付你想付的那部分”，这个概念更加虚，但足够把我吓跑了。这个的意思是，你可以自行选择付多少钱，只要是 0+ ，也就是允许你填 0 元，不过要填个电子邮箱。其实电子邮箱也是值钱的。

其它几个都没仔细去研究了，估计是大同小异，免费只是个招徕，其实没有全部意义上的免费。不过，想想这也对，怎么说也是别人的劳动成果，是应该得到尊重的。

就换 theme 这件事情来说，如果只是让你拿到代码，套在自己的 wp 里，这个还不够的，特别是英文排版的拿到这个中文博客里，多多少少需要点调整。而且，时间长了，总会有那么些东西会慢慢的让你不满意，这也是我总想换 theme 的原因。这个需要的其实是个长期的服务，很显然是有成本的。

看中的两个都有提供这种服务，我不选择的原因在于，他们不一定能搞定比如中文排版这种事。其实，我也不算什么高级用户，只是目前这个市场（指国内）都不被看好，选择几乎为零。

为你所选择的付费是很正常的，没有选择才是可悲的。

可维护的代码？

今天被问了一个很有意思的问题：（Lisp 的）代码真的可维护么？（这里的维护，意思比较泛化，包含一般性的代码改动，甚至重写。）

缘起我在微博写道 “Noir 是个好东西”。Noir 是 Clojure 的 web 框架，而 Clojure 是 Lisp 的一种方言。看过《黑客与画家》的人应该知道 Lisp 是多么的光芒万丈，但同时又被很多人所厌恶，真是超典型的矛盾统一体。不过这里不打算讨论这个矛盾。将上面的问题转换一下之后是：

代码的可维护性跟语言有关吗？

我觉得有关，但这只是基于当前现状的。像 Lisp 这么小众的语言，应用到项目当中，技术人员一拨一拨的流动时（这也不算是一个好的现状，不利于自身的积累），如果想一直都能找到合适的人来做，这本来就已经是一个问题。在国内，许多不是技术驱动的公司里，几乎很难碰到会使用小众技术解决问题的（所以如果你遇到了没有这样的氛围却依然坚持不懈的玩各种小众玩意的，千万不能随意放手啊），技术选型的其中一项是团队里或者市面上都流行什么。但如果不存在人口基数的问题，代码的可维护性应该是跟语言没什么关系的。

代码的可维护性跟什么有关系呢？

架构。因为像可维护性，代码演进这些问题是架构设计的时候考虑的。代码书写的风格，代码的组织方式，资源布局，运行机制与策略等等这些都会有影响。除了架构，有洁癖的通常会比无洁癖的产出更容易维护的代码（写得烂不烂的问题是可以通过学习改进的），代码整洁整齐，用法一致也便于维护。

按照我的猜想，应该是可以使用 Noir 并产出可维护的项目的。

回到语言细节上，因为很多人接受不了那一连串的括号，总是第一感觉以为要人肉去数哪些个括号，特别是N多层嵌套的时候，和这个类似的，nodejs 推广过程中也好多好多个声音说 N 层回调嵌套看着头晕。

我有必要再解释这个问题么？如果反过来问，一个语言能给你带来的价值减去其缺点所造成的损失结果是多少？这不代表我承认 Lisp 或者 JavaScript 的缺陷有多大，有多招人讨厌，而是想说，我们能否正确认识其价值，放大其价值。

哪些语言被创造出来最大的幸福是其价值得到显现。当然，价值这东西很难拿出来讨论，自己心里明白就好。

也许在最大化其利益之后，那才是踏踏实实的讨论改正缺点，但是有时候，比如 Lisp 的括号（列表表达式），最大的缺点也正正就是最大的优点，最好的办法是，当没看见吧。

如果 brew install 撞墙

某强已经无厘头到一定程度了，在进行 brew install pgrep 的时候

==> Installing proctools
==> Downloading http://downloads.sourceforge.net/project/proctools/proctools/0.4pre1/proctools-0.4pre1.tar.gz

curl: (56) Recv failure: Connection reset by peer
Error: Download failed: http://downloads.sourceforge.net/project/proctools/proctools/0.4pre1/proctools-0.4pre1.tar.gz

… …

翻墙下好之后，放到 ~/Library/Caches/Homebrew/ 就可以继续了。

不过如果多的话还真是挺麻烦的

… …

====== 超级华丽的分割线 2015/7/19 ======

现在 brew 可以设置 proxy 了，更加简单直接。

比如 android-sdk，由于众所周知的原因不能直接访问，于是就需要 proxy 出马了。

ALL_PROXY=socks5://127.0.0.1:1080 brew upgrade android-sdk

参考：

栅格系统计算器

栅格系统（Grid System）的辅助工具不少，而那些工具多数让人填栏宽，间距，栏数这些。但是我在实际应用栅格系统的时候，是知道页宽并估计 12 栏会比较适合，虽然有公式去计算，都会觉得麻烦。

为什么就没有这么一个工具：输入页宽和分栏数，自动计算出所有可能的情况呢？因为不会有半个像素的情况，精准到像素的话，还是可能有几种情况的，还夹杂一些不实际的情况。那么根据具体效果去选择，会比埋头计算然后看效果要方便得多。

于是做了这个 webapp：Grid System Calculator
grid-system-calculator

参考了 Bootstrap 和 960 Grid System 两种 CSS 实现方案，感觉更加倾向于 Bootstrap 的方案，于是参照其做法，用于生成显示效果。

为了方便 Bootstrap 的用户，以其参数配置方式输出具体参数。也提供了基于 960 Grid System 的 CSS 下载服务链接（引用 grids.heroku.com 的服务）。

这个 栅格系统计算器 采用 MIT 协议开源使用。

Ubuntu VPN 连接不能同时访问内外网的问题

也许 VPN 服务器设置的原因，有些 VPN 网络在 Ubuntu 下就使用最简单的配置方式即可使用，但偏偏这个，用最简单的配置，连上之后就只能访问内网资源，不能访问外网资源。奇怪就奇怪在，在 win 下只要勾选了那个“在远程网络上使用默认网关”，就什么问题都没有了。

可能 linux 下也会有类似的关键性按钮，google 了好一阵，按照这篇 在 ubuntu 1004 的 pptp 客户端上如何建立分离的 vpn 隧道。按照文中的内容一步一步做了之后，的确可以访问外网了，但是悲剧的是，内网无法访问了。显然，Use this connection only for resources on its network 并没有起到预期中的效果。

这个现象与 这个问题 中描述的十分类似，虽然，里面没有如何描述最后如何解决。可能跟我最初的想法一样，连 VPN 的时候就不上外网就完事了。但是怎么想都觉得麻烦，而且已经感觉离解决问题不是很远了。从 那个问题的评论 中得到的提示：自动从远程网关那边得到的配置信息可能并不是正确的路由信息（至少 mask 就非常可疑：255.255.255.255），通过 route 命令可以证实这一点。
继续阅读“Ubuntu VPN 连接不能同时访问内外网的问题”

Replace [class*=”span”] in LESS

Bootstrap 里的 grid system 里面 (源代码) 有这么一段，

[class*="span"] {
  float: left;
  margin-left: @gridGutterWidth;
}

用 RECESS 去跑会看到提示：Universal selectors should be avoided。这个既可以说是 selector 的问题，也可以说是 RECESS 的问题，但可以在运行的时候加个参数忽略掉。

自己去写扩展时也会写到类似的规则，比如需要兼容某浏览器，如果不这样写，就会需要像 Bootstrap-IE6 那样写 继续阅读“Replace [class*=”span”] in LESS”