转移 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

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

可维护的代码?

今天被问了一个很有意思的问题:(Lisp 的)代码真的可维护么?(这里的维护,意思比较泛化,包含一般性的代码改动,甚至重写。)

缘起我在微博写道 “Noir 是个好东西”。NoirClojure 的 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

参考了 Bootstrap960 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 命令可以证实这一点。
Continue reading

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 那样写 Continue reading

不错的 JavaScript 格式

在重制 在线密码生成器 这个单页工具时,尝试的一种交互方式需要 tooltip (来自 Bootstrap) 作为操作提示的载体,动态修改 tooltip 的内容。于是查阅了其 源代码,虽然没发现有这样的功能支持(后来小改了一行之后就可以了),但是却发现其代码格式有些有趣的地方。

Tooltip.prototype = {

  constructor: Tooltip

, init: function (type, element, options) {
    var eventIn
      , eventOut

    this.type = type
    // ...
    this.options.selector ?
      (this._options = $.extend({}, this.options, { trigger: 'manual', selector: '' })) :
      this.fixTitle()
    }
// ...
}

可以注意到下面几点: Continue reading

@符号在 Chrome 里的奇怪显示

在处理首页一些细节的时候发现,在 Windows 上的 Chrome 显示 @ 符号的时候有些异常:

通过和上面一个 @ 对比即可发现下面一个更加窄一些。

为什么会有这么一个奇怪的现象呢?

想起前几天看的一篇博文 浏览器如何渲染文本,里面说到,在进行文字排版之前,会有个 text run 的过程,会根据一些语言规则,产生出一些 shaper,然后才是交给后续排版。 Continue reading