Posts Tagged ‘ javascript

一段小脚本,将 MongoDB 中所有 DB 的 Collection 按大小排序。

最近接到的一个遗留项目,数据库用的是 MongoDB,年久(?)失修,磁盘满了运维报怨。

实例里面有多个库,每个库中又有很多 collection
于是想要看看哪个 collection 占用的空间比较大,想 remove 掉一些过期数据。

发现 pymongo 取出 collection 之后,无法像 mongo 客户端一样可以直接用 collection.stats() 的方式获取状态。
于是很郁闷。

登上 mongo 查看了一下:

?View Code JAVASCRIPT
// db.col.stats
function ( scale ){
return this._db.runCommand( { collstats : this._shortName , scale : scale } )
}
 
// db.stats
function (scale){
return this.runCommand( { dbstats : 1 , scale : scale } );
}

这才发现,原来 db.state 和 collection.state 都是通过 mongodb 的内部命令实现的。

所以就有了如下代码:

?View Code PYTHON
from pymongo import Connection
db = Connection(HOST, PORT)</code>
 
print sorted(
    [(
        "%s -&gt; %s" % (dbn, coln),
        db[dbn].command('collstats', coln)['storageSize']
    )
    for dbn in db.database_names()
    for coln in db[dbn].collection_names()
    ],
    key=lambda x:x[1])

PS:这篇日志是 惰性的 Blade 大大两年之后头一次在这个布珞阁更新,大家鼓励他一下吧。

火星程序员带人指南

本来我是想写一本JavaScript方面的书,介绍一些这个领域内关于编程方法学和整体生态环境进展的书。但是去年与图灵的编辑们探讨过后,他们一致认为我应该先写出来一点,看看市场的反应。虽然建议不怎么好听,但毕竟只有真心说实话的人才会赢得我的尊敬。他们的担心体现在了两点,第一就是我作为一个在JavaScript领域并没有什么影响的人写出来的东西到底能不能卖,第二考虑到我妻子临产,我是否有充足的时间完成所规划的内容。至于内容方面我也是有些担心的,主要是貌似国人关心语言生态圈的并不多,他们把语言简单地当做一门工具,无论是赚钱的工具还是娱乐的工具,所以几乎看不到人谈论一门编程语言的流派,演进,思潮,展望。这些字眼儿也许过于风花雪月,但我觉得其实并没有那么地不切实际。在大家都在谈论某一具体的库,某一个具体的网站,某一种具体的新技术时,我总是感觉缺少些什么。似乎在这些疯狂逐利的群氓中,我更希望看到的是一个能沉静下来,多问几个为什么的人。

我最近带了两个新人,他们不是初学编程,基础也比较好。带的过程中我一直在想如何才能不误人子弟,如何能让他们获得内心的平静与强大。考虑再三,我决定让他们通过阅读一些经典代码,然后我提问题和演示的方式展开一开始的学习。理由如下:

第一,阅读源码是绝对必要的。虽然编程是创造性工作,但实际所有创造性工作的绝大部分都不怎么有创造性。这和艺术创作是类似的,大部分艺术家要数十年如一日地修炼自己的各种基本技巧,而这类基本技巧的训练经常是极度乏味,毫无创造性可言的。但是程序员往往以为自己跟别人不一样,想当然地认为大部分工作都是创造性的。说句实在话,我看到的大部分程序员都是缺少基本技巧的训练的,有的甚至说极度缺乏也不为过。最令人不解的是,很多人不愿承认这一点,或者即便承认也对此丝毫不以为意。其中我觉得代码阅读就是基础中的基础,一个看不懂别人写的代码的人,自己的写代码水平也必定有限。这个道理很好证明,一个人可以读懂自己写的任何代码,所以说他对代码的理解力一定大于自身的创造力,反过来说一个人的创造力的上限也就是他的理解力了。写代码和写文章非常类似,我以前也说过,就不罗嗦了。这里只是再一次重申代码阅读能力的重要性非常之高。所以我看程序员好坏,除了让他写一段程序,还可以让他读一段程序,甚至我更倾向于后者。读这个基础打好了,才能为写做一个良好的基础。

第二,要读经典才能学得更多。这简直就是废话。听音乐的要听经典的,读书也要名家名作,临摹字帖得是千古流传的……但程序员大部分时间都在读质量并不怎么高的代码。就好比我们读到的和我们息息相关的文字多数也没有什么美感一样。一定要刻意地找寻经典,话又说回来了,这就需要对一门语言的生态圈十分了解才可以。不但要知道那些产品非常有名,而且要知道为什么有名,谁在用这个产品,怎么用的。经典的代码和经典的音乐有点不一样,经典的代码一般还都处于活跃的维护期,不像音乐好多已经上百年没人更新了(呵呵,有点大不敬啊)。所以经典代码是活的范例,解决的是具体问题,不但可以学到编程的各种规范和技巧,也能学习到比人是如何思考改进代码的。好的代码更易于读懂,更清晰,有利于学习清晰的设计思想。这些都是普通教科书或者一般技术书籍所无法比拟的。学会跟踪趋势,知道流行也是程序员基本技能,况且额外的还可以通过读代码知道很多圈内八卦,这个是一般人不知道的乐趣。

第三,问题可以查看细节的理解是否到位。首先要说明的是无论是提问还是回答问题都是非常鼓励的。我一般会事先布置一些问题,然后让他们一起去研究,然后回答也可以问我新的问题。这种方式经过实践证明是非常有效的。学徒能够更集中精力,对问题的理解也会更加深入。透过他们的回答,我还能更清楚地判断哪些细节掌握的欠佳,我会毫不留情地抛出更多的问题。回答出所有问题只能得到及格,要提出问题才能获得高分。鼓励他们在提问的同时设计实验来检验自己的命题。这种苏格拉底式的修炼,一开始着实让新同学吃不消。因为我的问题无处不在,他们似乎第一次面对一个如此不会掩饰自己无知的家伙。这种方式使得他们渐渐抛弃了那些我们习以为常,却丝毫经不起验证的各种假设和误解。他们渐渐试着怀疑权威的观点,他们也会主动去验证自己的观点。编程是门实用艺术,一定要经得起别人问。

第四,演示促进理解和沟通。我发现大部分人对于把问题说明白这件事儿看得并不是很重要,尤其是工作经验比较少的同学。作为训练的一个科目,我要求不能只讲给我听,要演示给我看,要让我不经意间就能相信你说的都是对的。一开始有的同学觉得我比较扯,什么都演示多浪费时间啊。但如果你看过《完美软件》或者《人月神话》就会明白,就留沟通不行,问题都说不清楚,项目的失败只是时间问题,并没有回天的余地。程序员都觉得以“宅”为美,这就是狗屁好莱坞大片看多了的结果。我们不能相信好莱坞大片中的技术宅男,就好比我们不能相信国产电视剧中的八路军一样。我接触过很多大牛程序员,没见过哪个宅的。在一个团队,就是不能有信息的孤岛。在这个过程中我也发现了新手的一些常见问题,列举一些:

  • 倾向于说服,而不是证明。如果你要说明别人是错的,最好的办法就是举一个反例。如果你要说明你是对的,请回忆一下中学老师关于说明文的各种技巧。其中包括举例子,作类比,打比方等等。记住重复阐述自己的观点对理解几乎没有任何帮助。
  • 证明过程跳跃不完整。你说这两个对象是同一个的时候,就要演示一下是否全等,长得一样是远远不行的。
  • 思路不清晰,经常把自己绕进去了。课下的功夫做得不够。
  • 不cool。很多人说什么?!这也算是缺点!?当然,记得大学里上过的那些死气沉沉政治课吧。很多人上学的时候都对乏味的课程大放厥词,但是轮到自己演示的时候却是一个模样。我为什么要听你讲?你得有趣,人要有趣,讲的东西要有趣,要酷才行。
  • 不能即兴演示。对于观众提出的突发问题,没有即刻的反应。互动效果差。

好了,这些就是我对带人的一些实践。今后我会写一个专题,把我和他们之间讨论的问题记录下来(对,有可能是那种《论语》风格的),名字就暂定为《火星人JavaScript问题集锦》。起初几期讨论一下underscore和backbone的源码,之后会讨论jquery,coffeescript,less,欢迎大家参与讨论。

新玩具_1289266510

不错的Js Chart图工具:
http://www.highcharts.com/
还有一个什么来着??
http://raphaeljs.com/

这个配合node.js使用,兼容IE5.5。
http://socket.io

这个其实并非新玩具,Javascript实现的Scheme:
http://tryscheme.sourceforge.net/

另外发现YAML是一种很好的配置文件格式,可以比INI表现更丰富的层次关系和更明确的属性类型。
另外JSON是YAML的一个子集。

祝大家玩得开心,用着舒心~