missing you

小葛儿转眼安排好纽约面试就登飞机了。因为GPS的缘故，在机场周围转了好几圈，结果弄的再见都匆匆忙忙。送完她回到寝室——是的，没有了她，这里还是叫寝室合适——空荡荡的，安安静静。一分钟都不想多停留，背着书包就去了实验室。

晚上也不想回去，因为想到又是空空的房间就不自在。

一个人在这里。忽然一下安静了。多出了好多时间来想你，似乎一切记忆瞬间无比清晰，触手可及。你的肩膀软软的，抱在怀里的时候，还要告诉自己小心别把你弄疼了。你哭的时候，撅着嘴，鼻子里些许呜哝呜哝的声音，眼泪扑簌扑簌就落下来了。你笑的时候，眼睛眉毛嘴角都弯弯的，咯咯咯的，清脆悦耳。每到这个样的时候，我都在反问自己，为什么要和你吵架啊，有什么气好生呢。

可无论怎么吵架，我都还是爱你的，比每一次吵架前还要爱你，比每一次生气之前还要更想和你在一起。有时候会想，也许我太把你说的每句话当回事儿了，才会又好多的弄巧成拙。但翻回头来，我仍就欠你好多在一起的时光。

小葛儿啊。你的一举一动，一颦一笑，我都记在心里呢。欠你的那些时光，我也一定要都好好还你。快回来吧。有你在的地方，我就认为是家了。

我想你。

My August and a new beginning

八月份，是个开始的月份，来到了一个小屯子里，没有公交，没有市集，只是明晃晃的阳光，会照的人发晕。当真是个修行的地方。有关这里，想法都有关不要虚度光阴，要快些离开这里。

月中，和大瀾、乌龟、聪哥、温总一起去了黄石，西雅图，以及波特兰。这次旅行，如同酿酒发酵一般，越到后来越是留恋。

刚到Bozman的时候，大瀾看着大山都激动的手舞足蹈。然后进入黄石以后，各种臭泉以及异常干燥的气候弄的大家都越发烦躁起来。大瀾背着手，像居委会大妈一样视察颜色异常的泉水；也会二劲儿大发，摘下花来给每个人带上，拍个大头贴。大乌龟在走trail时候，被路上唯一的一个钉子扎破了后背。甩着舌头奔跑的牦牛，成群在树林里休息的大鹿，elk or moose。在大峡谷的晚上，八月间，大家竟然都被冻醒了，我迷迷糊糊间，看着大瀾给我盖被子，感动了好久。

三日后的大提顿满是惊喜。前一天晚上大瀾肚子疼的没吃好晚饭，扶她回房间后，我连吃饭的心思都没有了，更不要说后一天的提顿之旅。第二天早晨，大家也是有懒床的，有睡回笼觉的。只有唯一想去的温总，一肚子郁闷说不出口。而且刚启程，就发现没带门票，又折回。我开着车都能想到留守的聪哥似笑非笑的的得意样子。最终正午才进入大提顿，就遇见了满眼惊喜。厚厚的草甸，飘满小花的湖泊。大瀾拄着两人多长的树枝照相。在Jackson Lake租船的时候，旁边的小孩儿们兴奋的举着水瓶，炫耀捉住的水蛭。大瀾在船上，看不出任何身体异样，兴奋的拍水，尝试各种怪异的划船方法，几次都殃及到了坐在后面的我。但不管怎样，我俩划起船来，左右开工，还喊着号子，小船乘风破浪的指那儿打哪儿，相比而言，乌龟和温总的另一艘船大多就是在原地打转了。上岸之后，我们还在岸边的饭馆儿吃了进黄石以来最丰盛的一顿饭。在Jenny Lake，看着一湖清水，我和温总都脱到只剩内裤，跳进去玩水，结果上岸时候悲剧了，小石子们就像是锥子一样，走向岸边每一步都钻心的疼。。。大瀾在岸边，一边叹息着想游泳啊想游泳，一边带着乌龟和温总的俩单反，不断练习摄影技术。傍晚看日落，所有的山峰都一览无余，感慨自然壮丽。然后在把车开到山间处，再看一遍日落，再感慨一遍。晚上回程，看到了过马路的小狐狸，也许是被车灯照迷糊了，久久不离去，真想把它抱回来养。

晚上回到酒店，又出门，和大瀾并排躺在码头上，我第一次清楚看到了银河，像棉絮一样一团一团的，还看到了流星。拉着大瀾的手，看着奇妙的景色，时间就静止了。

到西雅图的第一天晚上，还有更多的惊喜。从倾斜的街道看到大海，身旁小酒馆门庭若市。城市真好。也是在这个时候，我们发现Yelp的预算对我们不适用。$的我们可以吃成$$$，$$的我们能吃成$$$$的。几个难民坐在日式料理最靠窗的桌子，烤肉、寿司、炒饭、拌面...，我们狼吞虎咽的样子，就是这家店最好的活体广告了。酒馆、小肥羊、牛逼的图书馆、大麻公园、面海公寓、满是鲜花的阳台，这就是我对西雅图的印象。

去波特兰是因为Grimm。精致的block，友好的大瀾校友，以及玫瑰花园。我们在市区停留只有半日。然后就是一个小时的公车，从二十几街坐到了245街。。作为这座庄园里唯一一队乘坐公车前来的客人，我们受到了主人的热情接待，安排我们住宿在一个墙上画着这个庄园某位109岁员工的房间里。庄园的晚饭不错，温总一时兴起喝了六七杯或者十来杯红酒，结果把大乌龟给喝醉了，嚷嚷着要脱衣服去游泳，又把聪哥紧张的如同被非礼了一样。。晚饭后我们还视察了庄园的绿化状况，并亲切会见了酒馆里的各种奇怪大叔大妈。

转眼相聚就要分离，回家的回家，旅行的继续上路，确实舍不得另外三位。昨天在豆瓣上读到马克吐温的一句话，“好友、好书，不轻易判断是非，这就是理想生活”。一路上颠簸，没读什么书，这生活却以足以让我留恋了。

在这里，开始学习工作快满一月了。老板人不错，几次问他有关研究的问题，他都很耐心的回答，给的方法也足够有操作性。今天一个师兄作报告被骂，也从另一个侧面证明老板足够聪明，不能唬弄。组里大家关系也很融洽，实验室、图书馆，资源也算充裕。新车也用的顺手。还是开始时的那个想法，不要浪费时间，早些离开这里。

Valve recruiting sidenotes

    
• Would I want this person to be my boss?
• Would I learn a significant amount from him or her?
• What if this person went to work for our competition?

Across the board, we value highly collaborative people. That means people who are skilled in all the things that are integral to high-bandwidth collaboration—people who can deconstruct problems on the fly, and talk to others as they do so, simultaneously being inventive, iterative, creative, talkative, and reactive. These things actually matter far more than deep domain-specific knowledge or highly developed skills in narrow areas. This is why we’ll often pass on candidates who, narrowly defined, are the “best” at their chosen discipline.

We value “T-shaped” people. That is, people who are both generalists (highly skilled at a broad set of valuable things—the top of the T) and also experts (among the best in their field within a narrow discipline—the vertical leg of the T).

This recipe is important for success at Valve. We often have to pass on people who are very strong generalists without expertise, or vice versa. An expert who is too narrow has difficulty collaborating. A generalist who doesn’t go deep enough in a single area ends up on the margins, not really contributing as an individual.

reference: Valve handbook

General posts about Lisp

    
Paul Graham: The Roots of Lisp (ps), What Made Lisp Different (Chinese translation), and his collection.
The Lisp Curse by Rudolf Winestock
Why Lisp macros are cool, a Perl perspective
The Nature of Lisp
Lisp: Good News, Bad News, How to Win Big (pdf)
The Bipolar Lisp Programmer
Natural Language Processing in Lisp (book)
Tips for using Scheme and debugging your code
Lisp的永恒之道 (Chinese)


A great explanation from ITA Software about why and how to use different languages, including Lisp (CL), Python, Java, and C/C++.

Lisp is a programmable programming language, and one of the few languages that can be used for a wide range of applications. At ITA we have projects with vastly different focus, and it's precisely Lisp's versatility that makes it so useful to us. Lisp allows us to define a wide variety of abstractions to manage the complexity, and at the same time we get the speed we want - and our customers demand.

While most of ITA's algorithm-intensive code is implemented in high-level languages like Lisp, we use C/C++ to provide system support to our Lisp-based applications where the Common Lisp runtime support is inadequate. For instance, we represent large static datasets as densely packed arrays stored in files. We use C++ to make the mmap() calls and fetch pointers into these mappings for Lisp to access.

Once in a while, we have had a hard time fooling the Lisp compiler into generating sufficiently fast machine code for a given function. When that happens, we can usually just rewrite the function in C++ and call it from Lisp.

and... quote from an email of Carl de Marcken from Paul:

A lot of our Lisp is designed to compile into very efficient assembly. We make a lot of use of Lisp's macro capabilities, but shy away from many other Lisp features like closures, generic functions, complex sequence functions and garbage collection. We're doing an incredible amount of computation - getting 10 seconds on a modern machine is an incredible gift - but if we're sloppy at all 10 seconds can turn into ten minutes, not adequate for a travel agent or web site. We disassemble most every Lisp function looking for inefficiencies and have had both CMUCL and Franz enhanced to compile our code better.

We've had very little trouble getting non-Lisp programmers to read and understand and extend our Lisp code. The only real problem is that the training most programmers have in Lisp has taught them to code very inefficiently, without paying any attention to the compiler. Of course, with things like STL and Java, I think programmers of other languages are also becoming pretty ignorant.

HD and SICP

    
Humming Identification.

已然经历了两次较大的重建，现在的中段程序应该算是稳定了，前段程序接近黔驴技穷了，后段程序最后一次大修改后还在服务器里面跑着。出结果之后再用一两天时间整理，然后再看看清唱部分的阈值应该如何处理。不出意外的话，这就接近世界先进水平了:)

现在回头看来，其实真正值得研究的部分还是在最初的参数提取。SIFT里面对于图像的各种锥形不变、边框加深、棱角过滤，对于音频信号都是不适用的。而语音信号的频谱重复或者音乐信号的长时重复在哼唱识别中又是不适用的。所以现在只能使用较为原始的 local maximum cascade filtering。若是频谱图能如图像般的直观，有些经验总结的东西在里面，就好了。


SICP

思考过一段时间的结果，因为有了电据就少用到电钻，于是熟练了Py也就先放放ruby了。转过身来硬着头皮读这本书。而第一天读过前言，我就知道这决不会是个令我后悔的决定。无数人的推荐，自然是有其中道理的。而把读过的几本经典书籍横向比较，会发现它们都会刻意避开很多fancy的概念，着力强调着那些在设计程序过程中永恒不变的东西。K&R把C的很多基本库函数都重建了一遍，而SICP更是从加减乘除开始重构。

开始读书之前，我也刻意找了一下CL和Scheme的对比。记得有个人说，如果想用Lisp做项目，CL更合适；想体会编程的乐趣，Scheme更合适，只是，它的核实在是太简单了。几个月看下来，其对于Scheme的评价当真实字字珠玑。这是一个无比强大的语言，data abstraction & procedure abstraction，之后再抹去两者的差别，都只是当作object处理。看到这里，我会有错觉，认为自己都可以来设计Clojure了，这简直就是顺理成章的事情！tail recursion，比循环更加直观易懂，而更牛逼的是这竟然不会按照stack的模式迭代后增加内存的占用。至于enclosure和lambda calculus，在Python里面也有借鉴，但是我是直到这里才真正学会了如何使用它们⋯⋯当然，我很清楚这些词汇推砌起来的仍然仅仅是些皮毛。里面很多在程序设计时的考虑，才是更需要我好好体会的。


BTW, 今天的时间累计到2800了~

cheers,

Install MIT/Scheme with Vim

    
After wondering around for a while, I finally found this was quite foolproof...

It could be divided into five steps:
1. $ brew install mit-scheme. (Its version is usually a little bit older than the latest MIT/GNU Scheme)
2. Install GNU screen if it was not installed before.
3. Install Screen Vim plug-in according the steps in that webpage.
4. $ vim ~/.vimrc
"For screen.vim send block
"to SendScreen function
"(eg Scheme interpreter)
vmap :ScreenSend
nmap vip
5. Launch Vim and write ":ScreenShell mit-scheme". It is all set for the fun:)

References: [1], [2]

cheers,

Reading digest 03/16/12

Smart and Gets things done
What should you look for during the open-ended questions?
One: look for passion. Smart people are passionate about the projects they work on. They get very excited talking about the subject. They talk quickly and get animated. There are far too many people around who can work on something and not really care one way or the other. It’s hard to get people like this motivated about anything.
Two: good candidates are careful to explain things well, at whatever level. You don’t want to hire some one, basically, because he is not smart enough to comprehend what it takes to make other people understand their ideas.

No Designer's Design Book
When several items are in close proximity to each other, they become one visual unit rather than several separate units. As in life, the proximity, or the closeness, implies a relationship.
By grouping similar elements into one unit, several things instantly happen: The page becomes more organized. You understand where to begin reading the message, and you know when you are finished. And the “white space” (the space around the letters) automatically becomes more organized as well.