Git is a program for Source Code Management (SCM) whose complexity has been blown out of proportion. This may be due to the fact that early on it was primarily used by Linux kernel hackers who, needless to say, do not represent most users of SCM tools. Regardless of its past, today the UI is quite simple and there are only a handful of techniques a user needs to manage their code base with git–in ways that are nearly impossible to do with the mainstream alternatives. These techniques, which are mentioned in the order of their suggested usage, focus on improving the overall quality of the code base throughout the life of a project.

Good patches

While developers have been managing changes to code for decades, this task is not quite as simple as it sounds. These changes, or patches, range from simple one-line fixes to features measured in hundreds of lines. However, there is one goal that all good patches share, no matter their content. The objective is to introduce positive cohesive change to the code base. In practice, this means that unrelated changes should be contained in their own patches. As projects grow there is a need to group patches into cohesive sets for both organization and maintenance.

This article is as much about using git effectively as it is about creating quality patches. Before we go any further, let’s explain the need for this coupling.

Métro, Boulot, Codo

As much as project managers (or maintainers) like to believe their releases are well-planned and will go out on-schedule, the reality is that priorities, businesses, and staffing changes often disrupt the best intentions. A disciplined approach to submitting changes goes a long way to allowing projects to react with agility to these types of challenges.

While it may not be apparent to developers in the trenches, a bit of discipline gives those in charge of integrating and releasing code the confidence to add or remove features–even if they do not have an extremely low-level understanding of the implementation. Most people tasked with releasing projects are not nearly as concerned about particular files; they are more worried about entire trees and changes over time. They want to ship feature X and yank feature Y with accuracy.

Sadly, many of the mainstream tools for managing source code are poorly set up for these kinds of tasks, and thus, they are simply ignored in the field. This can be seen in any project where a large majority of the commit messages provide vague information like “checking in my stuff”.

Let’s observe the life cycle of a typical nice-to-have patch:

1. Developer has an itch for a new feature so she downloads the project’s source
2. Several changes are made–some good, some bad
3. The feature is then tested
4. A patch is submitted to the project’s mailing list
5. People review the patch and eventually it is accepted upstream

On large projects, there often exists an arbitrarily long period of time in which the patch is simply left in limbo. This typically happens between steps 4 and 5. This can be due to many factors–often limited resources and/or time.

The main problem that patches face is that the longer they stay in limbo, the less likely they are to apply cleanly. And when patches carry the weight of several (often minor) unrelated changes, the effort needed to resolve a merge conflict can dramatically increase.

But never fear–when upstream has moved on and left a patch behind, there is still hope. Git can help a developer maintain a patchset until it is accepted upstream, and here’s how:

1. Rebasing

Rebasing is a powerful feature that greatly simplifies out-of-tree patch maintenance. The goal is to avoid the ‘weaving commits’ problem that linear SCMs suffer from. Consider the simple case of weaving between two developers working on unrelated features of the same project:

Instead of:

A1---B1---A2---A3---B2---A4---A5

It’s more readable to have this:

A1---A2---A3---A4---B1---B2

To make this work, typically there is some notion of “upstream.” In this example, A is upstream and B is a single developer.

   B1*---B2
  /
A1---A2---A3*---A4

Instead of leaving B’s patches in limbo, git-rebase can be used to stack the changes back on top of A’s.

                  B1*---B2
                 /
A1---A2---A3*---A4

* Represents a committed mistake that has no value

Should any conflicts arise, git-rebase will let you resolve them as you go and will even guide you through the process. Whenever it’s decided that B’s changes should ship, they will be ready to apply cleanly against the latest revision of A–without having to make sense of dozens of woven commits.

2. Squashing

An observant reader will notice we’re still weaving–just on a higher level. Commit-weaving is only a bad thing when it leads to an improper signal-to-noise ratio in the commit log. If these commits were all related, we would really have a situation more like:

A1`---B1`

This can be achieved when developers use a healthy dose of squashing. Git provides several tools for making this easy. After performing a rebase, all commits that do not exist upstream will be stacked on top. If they represent a cohesive change (and were authored by a single person), the simplest way to combine them is with git-merge, like so:

# Switch to the branch to merge into
git checkout master
git merge --squash <previously rebased branch>

Quite frequently the commits are arranged in more interesting ways. Another useful tool is git-cherry-pick:

git checkout master
# Using the “--no-commit” flag allows for combining the changes
git cherry-pick <hash of commit1> --no-commit
git cherry-pick <hash of commit2> --no-commit
git commit

Git also has great support for doing “reverse” squashes where a single commit is split into multiple patches. Below is an example of how to split a commit that has multiple unrelated changes in the same file. This should be familiar to anyone who has struggled merging changes from team members who use conflicting indentation. This is precisely the type of noise no one concerned with releasing code should have to deal with.

# It's a good idea to do this cleanup on another branch
git checkout -b cleanup <ref of commit to be split>

# Reverse the git history one commit but leave the working tree intact
git reset --mixed HEAD^

# Interactively add commit “chunks” in foo.py to the commit staging area (aka index)
git add --patch foo.py

# Commit change one
git commit -m “Fixing the gnarly production issue”

At this point, the changes to foo.py have been committed, and the comment notes this. Now, pretend all the remaining chunks to be committed are related, and commit them together:

git commit -a -m “minor whitespace fixes”

The above approach is useful when changes are committed poorly and we want to clean up after-the-fact. To avoid the problem in the first place, git-stash offers a great alternative. See the documentation for more information.

3. Reordering

We have already hinted at the benefits of reordering. Rebasing is just one approach. When submitting multiple patches, having a logical order can make them easier to understand. There is a big difference between scanning 100 well-ordered (and cohesive) commits and 100 stream-of-consciousness commits. More importantly, the person reviewing the commits gets no value from commit messages like “oops” or “trying again.” If there is value in expressing a failed attempt, it should be explained in the commit log. For this next example we’re going to use git-rebase’s powerful interactive mode.

# Start the rebase from the commit before things got messy
git rebase --interactive <last good commit>

From here the user will be presented with a text file. Editing the file tells git how to perform the rebase. To reorder the commits, simply reorder the lines in the text file. Removing a line will result in that commit being deleted from the history. The rest of this powerful feature is documented at the bottom of the text file. As soon as the editor is closed the rebase will begin. The beauty of it all is that whenever git cannot figure out how to merge a change, it will stop and guide the user through resolving the issue. Just remember to continue the rebase after you commit with git rebase --continue.

Once patches are in a logical order, it’s often convenient to post them somewhere for review. With git this could be a branch on a public repository
or even a few patches posted to a mailing list. Those reviewing the code will appreciate the work put into the patch order and it could result in suggestions for a different or better ordering.

4. Documenting

With all this squashing and reordering, there exists another tool that can help developers produce quality code. This is the commit log. Many developers simply do not understand the utility of the commit log. It’s the one place that can holistically document code in a particular state. What makes git different than mainstream tools is that developers are not forced to worry about documentation at the time the code is first committed. Documenting code takes serious effort. In practice, undocumented code often gets pushed to the repository for fear of the work being lost. With git, this process can be iterative and will result in high-quality documentation over time. It should be no surprise that git-rebase is the key. If you tried the interactive rebase from the last example, simply mark the commits whose messages you would like to modify with the “edit” flag.

When commits are grouped into cohesive sets of changes and are placed in a logical order, developers can better understand the code base. For example, in any average project consisting of over 100,000 lines of code there will inevitably exist a chunk of code that no one understands and everyone is afraid to touch. When production problems arise with this particular block, it’s extremely useful to be able to jump through the last 40 or 50 of its permutations (that may span several years and more than a few different developers). This is precisely why changes not applied in a logical order will be too much to comprehend as time goes on. And you never know–by looking at the changes to a fearsome block of code over time, it may become apparent that the code in question was merely a vestige of a feature that never shipped.

En Fin

As in all areas of software development, there are no silver bullets and teams should feel free to adapt these practices as they see fit. A typical project can reap the benefits of actively maintaining and improving commits within a few weeks. With a little practice, git can make these techniques feel less like a chore and more like adding a new coat of paint to your restored ‘57 Chevy–tough work but you know it’s worth it.

作者：Fenng 发布在 dbanotes.net.

下午好不容易打到车杀到音乐节现场。天可真热，晒得头晕，幸亏带了把伞过去。

洪启

第一位出场的是洪启。他在唱《美》之前说的话很有意思: "西湖很美丽，全世界人都知道，可在西湖边盖高楼就不美丽了。" 以前几乎没怎么听过他的歌，只知道他是个民谣诗人。他的那首《阿里木江，你在哪里?》让人感动，相信现场的人会对新疆小偷善意一点，问问他是不是叫做阿里木江。

虎子+王娟

在这次活动的《官方会刊》上，是王娟+虎子，实际上，还是虎子+王娟，音乐基本上是虎子主导，当然，王娟的演唱也的确是有特点。这也是今天现场效果最好的表演，好极了，相比之下，晚上的所谓腕儿都是狗屁。《爱情国度》、《六一》在现场都引起了不小的轰动，新歌《探戈》我也很喜欢，准备找一下他们的新专辑。

虎子的舞台动作看起来挺好玩的，很电子。

周云蓬

坦白的说，或许出于某种原因，今天周云蓬的演唱并不是最好的状态。演唱《买房子》的时候，可能是太能引起现场听众的共鸣，现场的观众几乎都会心一笑。虽然大家一再要求唱《中国孩子》，可最后只是用一首《沉默如迷的呼吸》作为结尾。

跑到后台去拍他的照片，问了一下他是主办方不让唱《中国孩子》么? "对，不让。公安局长在那边呢。" 要买他一张专辑，找不开钱，干脆一起买了三张。然后还跑到人堆里给他免费广告了一下。

对了，另外一件事：周云蓬经常上豆瓣他的小组更新信息的。

叶蓓

给周云蓬拍照的时候，刚好看到了叶蓓，拍照的时候很善意的配合。接下来，她就上场了。乐队开场演奏的不错，叶蓓的舞台范儿也不错，可就是歌听起来不那么...和老狼合唱的《在劫难逃》还是让在场的人蛮激动的。

到了这会儿，感觉实在没意思，有些饿了，和老婆跑出场外找地方吃饭去了。

下午大家基本上是随便坐的，好多人都坐在舞台下的草坪上。现场人不多，保安也不怎么管。这种随意很好。

(更多照片稍晚一点到我的 Yupoo 上看吧)

--EOF--

相关文章|Related Articles

• 想起了 Peter Murphy
• 再次'遇到' PETER MURPHY
• 明天, 去看周云蓬
• 子曰乐队

评论数量(0)|Add Comments

本文网址：http://www.dbanotes.net/mylife/westlake_music_festival_first_day.html
最近作者还说了什么? Follow Twitter / Fenng

dbanotes posted a photo:

dbanotes posted a photo:

dbanotes posted a photo:

一句话不说的虎子。非常电子

dbanotes posted a photo:

现场看洪启很严肃的

The 95^th edition of Log Buffer, the weekly review of database blogs, has been published by Mark Schoonover on his Mark’s IT Blog.

We can look forward to LB#98 Jeff Smith’s Jeff’s SQL Server Blog on May 23^rd. There’s always plenty of room for more editors, so don’t waste another minute — send an email to me, the Log Buffer coordinator, and get started!

Without further ado, here is Mark Schoonover’s Log Buffer #95.

在老婆一再倡议和要求下，今天我们全家去了生存岛度假。生存岛位于北京红螺寺附近3公里左右的山里，是一个集新概念旅游、生存拓展培训、集体休闲三种方式于一体新型周末度假场所。可在旅游观光的同时完成多种多样的生存拓展训练，也可参与多种休闲娱乐活动。

生存岛整体园区分六大活动区域：山地训练营、生存拓展培训、工艺园、农事区、军体活动区和餐饮住宿区。

山地训练营：有独木桥、臂力通道、爬网、旋梯、松林飞降、岛顶秘洞等，植被茂盛、物种丰实、松林郁郁、峡谷幽幽。

生存拓展：背摔、过电网、空中抓杠、断桥、合力过桥、过沼泽、孤岛求生、绝壁、天梯、空方阵、逃生等。

工艺园：集陶艺、染织、木工、石膏、蜡型等多种工艺为一体，是艺术创造、艺术休闲的理想天地。

农事区：有无土栽培、标本制作、绳艺、冰激淋、豆腐、蛋糕的制作等，是传统技艺与现代高科技的完美组合。

军体活动区：有攀岩、飞降、射箭、机动车驾驶等具有吸引力的运动项目。

生存岛成人门票80元，小孩40元，以上活动的费用全部包含在门票中，如果你体力足够，所有的项目都可以参与。由于项目多，建议早上一定要早到，过程中需要及时补充体力，否则根本无法完成全程。

只恨自己太胖，好多项目根本无法参与，只好拍几张照片供大家欣赏。

1、门口的花丛。

2、山中风景

3、山中风景

4、路边草丛中的四脚蛇

5、磨豆腐

6、我努力向上攀！！！可惜才上了5米，就因为双臂无力掉了下来。

7、呵呵，她还差50cm才到五米。

8、爬绳洞

9，走钢丝

10、过浮桥

11、翻墙。
唉，当年晚上翻墙出学校去看电影的风采一去不复返了。

12、在绳网上。

13、浮桥和铁索桥

14、杂技–顶花盆。

15、花闭美人。

• 河北乐亭新戴河浅水湾、菩提岛 (0)
• 大唐芙蓉园–西安 (3)
• 卡丁车之生死狂飙–鹅和鸭农庄秋游记（四） (5)
• 十一 北京 双龙峡 京郊周末旅游 (1)
• 北京大山子798 艺术家的天堂 (0)
• 高尔夫、射箭、沙壶球、水球–鹅和鸭农庄秋游记（三） (3)
• 风景篇–鹅和鸭农庄秋游记（一） (1)
• 美女图片帅哥图片–鹅和鸭农庄秋游记（二） (0)

2001 年新年过的很忙碌。我想从大学里毕业出来的学生，第一个新年都是如此。从学校迈入社会，什么都很新奇，想和人分享自己对这个世界新的看法。大多数老同学不会太快结婚，日后离开祖国的也大多没走。所以新年里，那些儿时的玩伴、少年的同学，都会回到老家。只需要有人说声，“我们聚聚吧”，那么一定是和声一片。那个时候，女生们还不够花枝招展，男生们也没人挺着啤酒肚。

狂欢之后，各自散去。在本地工作的，也开始忙忙碌碌，留下我一人。有时候可以去一下老同学读研的校园，跟他们吃吃食堂，打打台球，听他们聊一下自己的老板，还有一些八卦。我觉得我还存在于这个社会。

我想许多人在年老之前，很难有这么一段时光。脑子里什么都没有，没有想做的事情，没有应负的责任，没有什么人什么事让你必须去做点什么。哦，那段时间还发生过点事情。我对追求了很多年的那段恋情绝望了。除了心口的绞痛，不记得什么细节。

有那么一瞬间，我了解到什么是空虚。人在虚空中，四周什么都没有，无所触及。声音也传不出去。不喜欢这种感觉，然后我开始读书。

大学毕业以前，我是不读历史的。高中会考，九门课，8 A 1 B ，就是历史那一科得的 B 。我痛恨一切要求背诵的课程，顺带厌恶了历史。当然我数的出夏商周，春秋战国秦汉，分的清六朝五代唐宋元明清。这归功于小时候爱看各种历史演义小说。三国演义就读了四五遍，以至于中学老师还没教到出师表时，已经背的朗朗上口了。不过演义不是历史，对吧 :) 。

我想，给我上历史启蒙课的是柏杨（老人在前几天去世，让我感慨了好久）。我倒是先读的《中国人史纲》再看的《丑陋的中国人》。后来又读了《皇后之死》等等很多很多。还有，在网上追看着的潇水的《青铜时代的恐龙战争》。

第一次发现，其实历史这样的有趣。不是因为有趣的故事，而是人性，以及人性促成的社会。历史总是在重复自己，又总也不会呈现相同的面貌；人总以为自己了解过去，可以回避那些前人犯下的错误，可他们总是掉进同一个坑中。这是为什么呢？

读大学时，我玩过一个游戏《恺撒 3》，更早的版本中学时也玩过，不过没有深入。那天夜里，是一门重要科目考试的前夜。躺在寝室的床上，瞧着他们几个人围在电脑边不亦乐乎。终于，有一关他们犯了些错误，引起了恺撒军团的大规模进攻，无法收拾残局。时间很晚了，因为第二天有考试，人就散了。

我觉得有趣，就试着载入存档，看看能不能扭转乾坤。一个晚上过后，我成功了，白天的考试却挂了。满不在乎的我，爱上了这个游戏。

特别喜欢这个游戏系列，胜过《文明》和《模拟城市》。从这里面，让人体验到了古罗马人到底怎样在生活。虽然只是游戏，许多设定是为了游戏的娱乐性而设，但是就是让人觉得，那种生活方式是合理的，恰如其份的，真实的。罗马城里那些高悬在空中的输水管道，街头的公共浴池，给了我无限遐想。

在家的那段日子，我买了份正版的《法老王》，在家里盖金字塔。看着那些小人在尼罗河泛滥后留下的肥沃的河床上耕种，农闲时大量的人力被调配去盖金字塔。哦，奇迹原来是这么诞生的。这就是文化呀，游戏是多么好的文化载体。

我想做一个承载中国古文化的游戏。

所以我开始啃史记，读资治通鉴，还有一些学术研究方面的书，比如人口，风俗方面的专著。很多大部头虽然只是翻翻，但也觉得自己似乎不那么无知了。不过成天读书，人也显得疲惫不堪，没有人和事管着，一天要睡 12 小时才够。白天也总是睡眼惺忪的。我想，长期这样下去也不行，得有个计划。

古月打来一个电话，先是很神秘的说他们找到了投资，说对方是个大公司，暂时还没谈完，需要保密。吱吱唔唔了一下，忍不住告诉我，那家公司正是网易。

聊起网易，倒是让我有了一些兴趣。我的第一个 email 就是网易提供的服务。大多数志同道合的朋友，都是在网易的服务器上建立个人主页之后才陆续认识的。那时觉得网易是中国最大的网络公司，嗯，大公司，据说还在 nasdaq 上了市。

不过我对古月说的网络游戏，没有丝毫兴趣。mud 我怎么都没玩进去，UO 显然不如 diablo 有趣，EQ 就是一群傻鸟在那里围着几个多边形按鼠标，隔一会儿还要坐地板。据说丁磊眼红上了《石器时代》，这个游戏我没玩过，不过看起来也是日式 RPG 的末流产品吧。

我说，现在全中国都在做网游呢，才开始做是不是晚了点？

真的，的确全中国那个时候都在做网游，后来那么多人给《天下》和《大话西游》带上了首款国产网游的桂冠，让我唏嘘不已，真的是成王败寇啊。

那几天，另一个朋友也在和我联系，王华奎（音）。

认识王的时候他在金字塔做程序员，书生气质。我那时还在上学，假期里去深圳找他玩儿。金字塔对员工管的挺严，我进了金字塔的办公室的时候，他跟我说老板不在，还没下班，等下班我们出去边吃边聊，现在得坐岗。我看了他先前做的一个网络俄罗斯方块，据说在他们办公室里很流行。甚至因为大家上班打游戏，而被老周给禁了。当时他在做一个网游：《人在江湖》。我想，这是我知道的第一款图形 mud ，至少比《天下》早上许多。只不过更 mud 一些，一个个的小区域场景，正如 mud 中的文字被图形化出来。client 是 3d 的，很早期的 3d ，技术不太成熟，打斗的时候有些简易的动作，但主要还是靠文字拓展玩家的想象力。之前的《江湖》这款游戏很糟糕，所以我对人在江湖也没什么特别好的印象。

晚饭时我们聊了许多，王华奎还叫了几个朋友一起。有一个据说是江湖的程序员，已经离开金字塔了。明显他自己也觉得自己在程序方面没什么造诣，说了一些很搞笑和低级的程序 bug 。反正，江湖这个产品没做好是应该的，卖的很好，不是吗？老周应该挺满意。好象还有个做游戏网站的朋友，说起网站的流量之类的事情，我那个时候的个人主页的流量相对还不错的呢。

因为只有我一个人是学生，大家讨论了一下关于毕业生最喜爱的几个南方热门的公司的情况，比如华为的待遇。我饶有兴趣的听着，没有什么想法。

晚上，窝在金字塔的办公室里看动画片。一个胖子的电脑在放《攻壳机动队》，片子和人都给我留下了深刻的印象，胖子说他叫陈重，人如其名，一下就记住了。他还给我看了他画的《江湖》里的大侠，动作很帅。这个人后来负责了天下二的美术，世界真小。

夜里很晚了，我被带去员工宿舍睡觉。全是上下铺，天气很热，没有空调。桌上的电风扇呜呜的吹着，我觉得比学校的寝室好，因为不熄灯。

上铺是个新毕业的大学生，说是找工作找过来的，没想过做游戏，只是找工作而已，目前试用期，1500 一个月。我随口提了些技术方面的话头，感觉对方很茫然，就把话题绕过去了。心里想，这个世界真奇妙。好多有志于游戏开发的热血青年不得门而入，觉得国内做游戏的公司都是些神圣的地方，很难进入。而另一边，人才市场上随便摆个摊，收几份简历，会写几行程序就来做游戏了。有些游戏产品做不好，还真不是什么奇怪的事。

王华奎说他现在东莞有个公司，正在开发游戏。还有，给游戏写剧本的是个名人呢，我跟他提过我喜欢《悟空传》，正是今何在在那里。冲者猴子的名头，我说好吧，我去你那看看，散散心。

南下的第一站是广州，下了飞机是古月接的机，我第一次见到真人，大家很开心的聊着到了公司，micro 执意给我报销了机票。我倒真的没点积蓄，有人报销路费自然是高兴的，不过有点困扰的是该让广州的公司买单还是东莞的。

网易的办公室在广州最豪华的地段。狭窄的街道，高耸的大楼，橱窗里玲珑满目的商品，墙壁的装潢有点陈旧，我觉得我处在电视剧中的香港。办公室就在那个川流不息的十字路口边的楼顶，36 楼，我们一直称呼这个办公点。

透过落地玻璃看那楼下的小车，火柴盒似的，感觉很奇妙。

许多人拥挤在不大的办公区里，micro 给我一一介绍。他们一伙人已经确定并入网易，然后新招了许多人，主要是美术。不过在文件上，大多数人暂时还不算网易的正式员工。大家似乎和老网易的人有点隔膜，我想刚合并的公司就是这样。

聊起美术部门里那些五颜六色的头发，听说还有一段趣闻。丁磊起初很不高兴电梯里有人指指点点，不知道顶楼的公司正在做什么，都是些奇装异服的人。曾经“下令”说，你们把头发剪掉、颜色洗掉，再来上班，结果却不了了之。因为有个白发的哥们道，要么我们都不过来上班算了，一呼百应。

这天我认识了刘琪和周云，都与我同年，小我几个月份。我很奇怪为什么美术部会有两个头儿，不过没问。周云的性格我很喜欢，为人很讲义气，长的很帅，一看就是很得女人缘的那种。多年之后他和我讲他的故事，居然他女朋友最后因为迷上大话而最终分手，网游啊，祸兮福兮 。

晚上我住在古月家，他刚买的新房（我猜是因为天夏卖给了网易，股东都得了些好处吧）。他的女朋友正在武汉读大学，学文的。时值寒假，也住在他那。我随便聊了两句，提到想读读范文澜的《中国通史》，她说她正好在学校图书馆里借了一本，就拿给我去看了。

micro 和 ten 说想一道去拜访同行，他们在国内游戏圈里没什么人脉，随我一起去多交一些朋友。ten 是天夏服务器部分的主程，挺有想法的一个人，是天夏工作室的元老了。聊起来就知道是个 mud 迷。我猜想天夏的几个人就是因为 mud 走到一起去的吧，我不玩 mud ，这方面没什么共同语言。

我们乘火车去的东莞樟木头。micro 提了个很奇怪的要求，让我别跟王华奎说他是谁，只说是个朋友。我说，讲了也没关系吧，最后还是从了他的意思。或许 micro 当时觉得，被网易收购的事情还需要保密，不方便说。只是最后让王猜出了他们的身份，好不尴尬。

在樟木头我倒是如愿见到了今何在。只是一面之缘，打了个招呼，没有聊什么。他们在做《不灭传说》，剧本是今何在的《若星汉天空下》。这是个网络游戏，据说主打欧美市场，首先做的英文版。

王倒是风光了许多，两年前他陪着我乘公交逛深圳，与我一起挤火车站的售票厅，陪我买车票。如今他只需要打个电话叫来司机，乘上公司的小车带我们转悠。去到当地一个新开的楼盘，谈起来，说是公司的员工工作满十年都能得到一套房子。从小到大一直住在一排排火柴盒一样死板的社区里。我第一次见到公园般的小区，欧式的花园，清澈的池水，从狮子头样的雕塑里喷出来。环绕着花园的房间，明亮的落地窗。我想，以后一定要让父母住进这样的地方，享受生活。

聊到《不灭传说》这个游戏，我从自己老本行的角度提了些技术问题，想知道他们怎么解决的。国产游戏到那个时候还没有什么成功之作，大多数卡在技术上。比如内存占用的问题，王说的很轻松，我们打的是欧美市场，人家早已经普及 128M 内存，不用太考虑这些。我心里笑笑，国内 64M 内存已经挺奢侈了。毕竟那个时候我刚从学校出来，烂机器用惯了。

华奎在饭桌上私下里跟我说，过来一起干吧，一个月工资 7k ，另外再算别的待遇。我说，我考虑一下，但自己知道那只是礼貌。条件挺好，但不是我想要的。

晚上，华奎让公司的行政帮我们在一家四星酒店开了房间休息。我和 micro 一间标间。micro 跟我说，他们想了好久新项目做什么。最后考虑到西游记的 mud 挺有人气，一些做西游记 mud 的巫师也过来了。可能会做一个西游题材的网游。

我说我可以帮忙，但还是想在家里自由一些。反正我主要也只是做引擎，稳定了后就没多少事了。不如给你们再做次网络兼职吧。

就这样，第二天我去了深圳转了转，见了几个老朋友，然后就回家了。

谢绝转载 :)