很好的 C语言入门教程(中文)

豆瓣上备受好评的 《Linux C 编程一站式学习》 网上几大书店都无货了,淘宝有,但是贵,然后竟然在 Github 上找到它的在线版本 http://akaedu.github.io/book/,真心要点赞啊。

linux-c-on-github

这个书还有个新版本,叫《一站式学习 C 编程》,也是无货的。具体内容我没有比较过,但是基础知识应该是差不多的。新版书名中把 Linux 去掉了,也是可以理解的,毕竟 C 不局限于 Linux,特别是现在多种平台,还有逐步升温的各式嵌入式设备,在可以 预见的未来 C 语言还将继续扛大旗

program-language-trends

这样看趋势还不明显,不过相信很快大家都会感受到的了。

如何生成唯一且不可预测的 ID

通常数据库可以生成唯一的 ID,最多的就是数字序列,也有像 MongoDB 这样产生组合序列的,不过这种形式的 ID 由于是序列,是可以预测的。如果想得到不可预测且唯一的 ID,方法还是有的。

下面主要以 Node.js 的环境为例。

Node-uuid

Github 上有个 node-uuid 项目,它可以快速地生成符合 RFC4122 规范 version 1 或者 version 4 的 UUID。

安装,既可以通过 npm install node-uuid ,也可以在 package.json 中定义。使用方式:

var uuid = require('node-uuid');

// 产生一个 v1 (基于时间的) id
uuid.v1(); // -> '6c84fb90-12c4-11e1-840d-7b25c5ee775a'

// 产生一个 v4 (随机) id
uuid.v4(); // -> '110ec58a-a0f2-4ac4-8393-c866d813b8d1’

听起来很有保证,只是……有点太长了。

坊间也有一些在 UUID 基础上随机截取几位的办法来组成一个新的短一点的字符串,只不过唯一性就又重新成为一个问号了。

Hashids

另外一个方法,来自 hashids,它的原理就是从数字经过一个加盐(salted)算法产生一个哈希(hash)字符串。这样算法就是通过混淆使结果具有不可预测性,而唯一性依然由数字本身来达成,从而得到(类似 youtube 里的)足够短,不可预测且唯一的 ID。

安装方式类似,只是 hashids 建议使用一个固定的版本。比如在 package.json 中

"dependencies": {
  "hashids": "0.3.3"
}

使用方法也很简单。先设定一个字符串作为 salt。

var Hashids = require("hashids"),
    hashids = new Hashids("this is my salt”);

然后对数字(准确来说是数字数组)进行编码

var hash = hashids.encrypt(12345);
// Nkk9

var hash = hashids.encrypt(683, 94108, 123, 5);
// aBMswoO2UB3Sj

对数组编码可以有很有趣的用法,比如需要在一个分布式的环境里使用,可以使用机器编号 + 序列数字组合数组然后再编码。

有编码就有解码

var numbers = hashids.decrypt("NkK9”);
// [12345]

编码的输出会随着数字的增大而变长,为了达到足够混淆,它可以指定最少长度。

hashids = new Hashids("this is my salt", 8);

var hash = hashids.encrypt(1);
// gB0NV05e

还有其它选项,比如控制输出所使用的字符,编码 MongoDB 的 ObjectId 等等。

上面介绍的两个项目,各有各优缺点,不过目的是一致的,可以根据实际情况选用。两个项目在其它语言上也有类似的实现。

如何在命令行中使用 proxy

国内的网络形势你懂的,要翻墙,无法是 VPN 或者 proxy。我个人还是用 proxy 比较多,浏览器里装个插件就能自动适应。但是那只是针对浏览器,命令行也很常用,遇墙就会卡着不动了。

有一个软件可以帮助你在 Command Line 里使用 proxy,叫 ProxyChains-NG (new generation)

在 Mac 上安装超简单(只要你机器上装好了 brew

brew install proxychains-ng

==> Downloading https://downloads.sourceforge.net/project/proxychains-ng/proxychains-4.7.tar.bz2
 ######################################################################## 100.0%
==> ./configure --prefix=/usr/local/Cellar/proxychains-ng/4.7 --sysconfdir=/usr/local/Cellar/proxychains-ng/4.7/etc
==> make
==> make install
==> make install-config
==> /usr/local/Cellar/proxychains-ng/4.7: 9 files, 92K, built in 10 seconds

其它平台的安装大同小异,先找找有没有一个命令能搞掂的,没有的话参考一下其文档的 Installation 部分。

然后,做一个简单配置,打开配置文件

vi /usr/local/etc/proxychains.conf

视乎你的安装方式不同,配置文件的地方略有不同,但会遵从平台的一般规范,例如在 Linux 上安装,配置文件的位置可能在 /etc/proxychains.conf

打开配置文件之后,略过前面所有,直奔最后一行,默认配置是使用 tor 的,根据你机器上 proxy 的种类配置好就可以了。常见的配置

http    127.0.0.1  8080
socks5  127.0.0.1  1080

其实上面几行就有 example ,找到合适的照抄就是了。

最后,使用也非常简单,只要在命令前面加个 proxychains4,比如

proxychains4 telnet targethost.com

PS. 还有个名字接近但更加老牌的同类软件, ProxyChains ,使用方法几乎一样。

Linux 20 周年纪念活动在苏州

2011年8月28日 星期日下午,我第一次参加 linux 周年聚会。这次是 linux 20 周年,网上已经煲得比较多有什么历史渊源,特别有纪念意义之类的文字,让人无比期待这次活动。

我是个 linux 爱好者,看好的并不是 linux OS 本身,而是这种社区驱动的发展模式,潜藏在背后的伟大理想,由此而衍生出来的就不仅仅是一个操作系统,而是一套生态系统,时刻启发着参与者,给予丰富多彩的希望。通过这次活动,我不知道大家是不是能感觉到希望就在眼前了。

回到会场内容上。由于小小的误会,迟到了一点。一位身穿 linux20 纪念 T-shirt 的演讲者已经开始了,讲Intel 的历史包袱,Atom 和 ARM 的前世今生,Intel 与 AMD、Nvidia 打得火热的日子,中间还间插了许多名人轶事,N 个名词解释,科普了 Intel 芯片制片工艺(保持领先六个月),冷笑话 N 个,还推荐了一本书,后面终于扯到 linux 了,介绍了 Intel 怎么和软件厂商合作,介绍了大神和来自 http://www.lesswatts.org/ 等地方的可以省电的工具和技术。前前后后两页 PPT,有才吧。

揸水之后,上场的是来自龙芯的童鞋。我一开始不怎么喜欢,他嘴里冒的词都很官腔,讲龙芯的历史也不知道是真是假,但奇怪的是,他不忌讳,也没有避重就轻,兜圈子,那段历史再愚蠢再不堪,依然是历史。只要 Continue reading

从分享文档的角度观察开源社区

国内的开源社区环境不咋地,朦朦胧胧的问题困扰着各个开源项目,而这个绝不是因为怀着开放理想的开源人做不出好的东西。

LOVE OPEN SOURCE尴尬的状态在持续着,脾气再好的人时间长了也会忍不住发发牢骚。

我也很费解,到底是为什么,我们到底应该怎么做?

有人说就算不参与提交代码,写些文字分享一下总可以的吧?有人就说没什么好分享的。
类似的争论总有发生的时候。这里不具体讨论这些观点,就从分享文档的角度来看看事情。

相信有许多人都有这样的经历,在使用某开源项目时遇到困难就 google,搜索结果中排名靠前的并不一定是官方的,特别是各种细致的问题,从摘要都可以看出来那个 post 所描述的问题正好就是自己遇到的,心中一乐,点开链接之后数秒,问题解决。

假设没有搜索引擎(天哪!),但是你只是知道有官方文档,然后你去查,发现写这个项目的文档写得非常特别,可能项目比较新,或者开发者就是这么特别,你只好开始刨那些文档。运气好的,能从 FAQ 里面找到你想要的,运气不好的,不太会觉得是自己运气不好,会认为这个项目开始不靠谱了,但是问题,还是得解决,于是想着既然开源的,就看看代码吧,正好自己也会哪门语言,强大的你下载了源码,不管 3721,连上调试尝试快速寻找突破口,经过 N ( >=1 ) 个循环之后,终于找到了问题,原来只是自己理解的问题,修改一下自己的代码即可轻松绕过。为了掩饰自己的“无知”,你可能选择了什么事情都没有发生。

另一个“强大的你”在地球的另外一个角度重温了一下刚才那一幕,也许太忙了,就忘了~~
还有另一个“强大的你”也遇到了,但是你也很特别,不会码字,然后就忘了~~
……
第 M 个人同样遇到个类似的问题,就会有 M 种理由当什么事情都没有发生过,就会有 M 个人开始对这个项目产生坏印象。使用的人开始减少,项目维护的热情在消减。

但情况非常之容易改善,只要中间有一个人为此记录下来,发布到网上,就会产生 P ( < M ) 个开心秒杀的情况。当中微妙的差别可以影响很多。这 M + 1 ( 1 是开发者 )个人是不是就可以形成开源社区,只要每个问题循环中有一人提交解决结果,其它人都可以直接读取这个缓存,看上去是不是非常简单而美妙。 现实中,情况可能复杂得多,只是可能,因为相对于每一个使用开源项目的个体,所要付出的和最大收益是不成比例的。整理成文字发表出去的成本非常低,网上有大量的免费服务可供选择。 开源社区可能不是以这种方式建立起来的。 只是开源社区对于开源项目是非常重要的,缺乏社区的支持,项目很难得到全面发展。 开源社区并不意味这固定的组织,任何人都可以作出贡献,比如只是一篇简单的分享,任何人都可以分享当中的喜悦。 非常简单的自然法则。

开源软件在军事领域的应用

五角大楼在年初推出了专门为军方服务的开源代码托管平台Forge.mil,这只是一个开始。

现在美国国防部将和一些开源厂商于8月12日到13日在乔治亚理工大学举行工作组会议,与会者包括了一位驻伊拉克的美国海军陆战队远征军的少校

参与会议讨论的开源项目有

转自:Solidot

Jscombiner

为自己写个工具 Jscombiner,除了帮助自己高效完成任务,可以自娱自乐,还可以开源,和别人分享。

这个工具前一个版本是命令行方式的,一方面技术所限,另一方面是一直坚持认为前台和后台开发是可以而且应该分开进行的。

当然思考的结果是会变的,该分开的还是分开,但有时后台也应该为前台开发提供一些帮助,而单纯的apache httpd提供不了,也有想过用asp, php,但是按照目前的态势,java应该更熟手一点。而且我主要是想和公司的其它同事分享这种开发方式,他们的机器上大多有tomcat而没有apache。

Jscombiner 的基本目标就是减少程序员开发 javascript 项目时所需要投入的管理成本。让 javascript 脚本采取自描述的方式来方便进行管理。因此,开发者可以在开发过程中,随心所欲地更新脚本,而无需担心重构或者脚本规模增长所带来的管理成本。是不是已经有同样的东西存在,我不确定,有是正常的,多个选择,多个竞争,才会有进步的。也许是有开发者像我这样不善推广的。

现在的状况是基本功能以及有了,自己一直在用,我期望的使用感受是感觉不到它的存在。

不过,不是为了做这个东西而做的,还有其它的目标任务,而且只有我一个人在瞎搞,而且主要的更新都是针对自己的实际应用需求的(我相信我所遇到的问题,其它人也会在某个时刻遇到),所以更新会比较慢。

等当前任务完成了,再做一个example出来。不过其实想想也很简单的,mvn archetype:generate一个项目出来,加入依赖,将脚本丢进去,然后mvn jetty:run,立马就可以着手开发了。

关于这个项目的改进计划会在Issue里面发起。目前想到的一个就是先实现前一版本中的一个功能,合并大脚本,这个应该不难,只是怎么提供出来,会更实用,更有趣呢?敬请期待啦!