照做基本没什么问?br />
如果要用 tool bar, menu bar, scroll bar, 需要在configure的时候加 --with-x-toolkit 选项Q这个需要gtk+ >= 2.6 glib >= 2.6?br /> q个依赖我在ubuntu hardy 上一直没搞定Q反正我也不用，也就没有加?br />
如果要让emacs在终端中q行q需要安装libncurses5-devQ否则会报错Q?br /> *ERROR*: Cannot open termcap database file
新的 --daemon 真的很好用，新徏frame的速度快Q完全可以和VIM媲美Q终于可以不用在commit的时候用VIM~辑commit message了?br /> Emacs一l江湖，千秋万蝲~~~~
]]>
http://support.microsoft.com/kb/247815
比较好的中文ȝ
http://www.2maomao.com/blog/windows-console-font/
1. 安装Bitstream Vera Sans Mono
安装后貌g能直接用Q重启后才能有效Q不明白Z?br /> 2. 修改注册?br /> ?HKEY_LOCAL_MACHINE"SOFTWARE"Microsoft"Windows NT"CurrentVersion"Console"TrueTypeFont 下添加新键|
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont]
"0"="Lucida Console"
"932"=hex(7):2a,00,2d,ff,33,ff,20,00,b4,30,b7,30,c3,30,af,30,00,00,2a,00,4d,00,\
53,00,20,00,47,00,6f,00,74,00,68,00,69,00,63,00,00,00,00,00
"949"=hex(7):2a,00,74,ad,bc,b9,b4,cc,00,00,2a,00,47,00,75,00,6c,00,69,00,6d,00,\
43,00,68,00,65,00,00,00,00,00
"936"=hex(7):2a,00,b0,65,8b,5b,53,4f,00,00,2a,00,4e,00,53,00,69,00,6d,00,53,00,\
75,00,6e,00,00,00,00,00
"950"=hex(7):2a,00,30,7d,0e,66,d4,9a,00,00,2a,00,4d,00,69,00,6e,00,67,00,4c,00,\
69,00,55,00,00,00,00,00
"00"="Consolas"
"000"="Courier New"
"0000"="Bitstream Vera Sans Mono"
q段是从上面的blog中抄来的。新加键D则如下："0"="Lucida Console"
"932"=hex(7):2a,00,2d,ff,33,ff,20,00,b4,30,b7,30,c3,30,af,30,00,00,2a,00,4d,00,\
53,00,20,00,47,00,6f,00,74,00,68,00,69,00,63,00,00,00,00,00
"949"=hex(7):2a,00,74,ad,bc,b9,b4,cc,00,00,2a,00,47,00,75,00,6c,00,69,00,6d,00,\
43,00,68,00,65,00,00,00,00,00
"936"=hex(7):2a,00,b0,65,8b,5b,53,4f,00,00,2a,00,4e,00,53,00,69,00,6d,00,53,00,\
75,00,6e,00,00,00,00,00
"950"=hex(7):2a,00,30,7d,0e,66,d4,9a,00,00,2a,00,4d,00,69,00,6e,00,67,00,4c,00,\
69,00,55,00,00,00,00,00
"00"="Consolas"
"000"="Courier New"
"0000"="Bitstream Vera Sans Mono"
键名?0 开始，每新加一个字体加一?0
字体必须?monospace pȝ
3. 讄code pageQoptionalQ?br /> 新加的字体要?#8220;当前代码（code pageQ?#8221;?37时才会出现。估计是字体字符集的问题?br /> 打开CMDQ输?"chcp 437"
4. 修改CMD的属性设|?br /> 修改Z惌的字体就OK?br />
]]>
们从今年q完q就基本上在搞这个东西，期间问题无数Q可以作Z个典型的p|案例Q貌
D我进来之后参与的所有项目都没有一帆风的Q就拿这个最典型的开刀Q以醒后世?/p>
先介l一下我们这个项目：是将open source的一个实现拿到自q产品当中Q当然license
上是没问题的Q。主要的工作是移?量的升U，原来的实现只支持L的Intelq_Q我
们要这个东西移植到12个^収ͼ而且我们已经有了一套port层的APIQ也是说我们只需?br />
所有涉及到和^台相关的代码全部替换成port层中对应的API。原来的实现层次上也很清
晎ͼ大部分都是相同的代码Q少C同的地方也都攑֜了不同的文g。看h是个非常?br />
的项目，那么我们来看看q样一个简单的目是如何失败?/p>
一?个h投入q个目Q计划两个h做升U，两个人做ULQ我被分dUL?/p>
问题一
四个人都是做java的，只有一个在目中用C/C++Q其他h都只停留在学校作业的水^
如果从上面的需求看Q这L状况完全是可以接受的。只要理解了框架Q在合适的位置加点
代码可以了Q已有的代码也是个很好的参照Q移植基本就是个体力z，仔细不出错就没问
题了。事实证明，对于不熟悉的语言Q解决问题的效率明显下降Q很多我们折腾了几天了的
问题Q有l验的h可能一分钟p搞定。不q项目组里在实在是没有其他h了，q个风险?br />
该是已经计算在内了。但是许多小问题堆积h有可能就是致命的Q这只能是其中的一?br />
了?/p>
问题?/span>
没有及时的与其他模块集成
我们q个L敏捷的team在这一点上q敏h基本的尽早集成，持箋集成都没有做刎ͼ汗颜
啊。我们只是在自己的小作坊里拼命的搞呀搞，最后发现我们的东西拿给integration team
Ҏ没法buildQ然后花了大量的旉来解军_各个q_上的build问题。这旉题一凸
昑և来了Q面对不熟悉的语aQ不熟悉的工P完全陌生的^収ͼ写脚本去build一个复?br />
的工E（原来用的都是已有的东西）。由于build的问题迟q没能解冻ID后面试和我
们fix bug的时间非常有限?/p>
问题?/span>
不求甚解
我来说Q我做完UL后都不知道整个模块的q行机制Q工作原理，只是一个API译的码
工。其他h也都差不多，Ҏ体的构架和大致的程都不是很清楚。不q我们这hq是?br />
强的Q都是fix bug的高手，每天l护q大量完全不熟悉的代码，即不懂Q不太懂照样?br />
刃有余。这里的问题是我们没有责LQؓUL而移植，为升U而升U，完全不去试图理解
自己所在做的事情，D不知，q些拿进产品的代码最l还是要我们自己来维护的啊。这U情
况一直到目的最后期才有所好{Q修了那么多bugQ再不熟都说不过M。但q种从局?br />
一点点的理解不仅效率低下，而且始终对代码没有充分的自信。即使现在我们也不敢对已?br />
的代码做大的改动Q因为我们完全不知道在这里的修改是否会媄响的其他部分?/p>
我觉得在目刚开始应该首先学习已有的代码Q顺便温习C/C++的知识，寚w目整体的了解
是必要的Q也是最基本的?/p>
问题?/span>
寚w险估计不?/p>
l心的读者可能已l发CQ我们前面项目的概述中有两个重要的风险没有考虑刎ͼ已有?br />
码中的bug和我们依赖的port API的bugQ我们都假设它们是不存在的！Q就是这两个东西?br />
我们陷入了惔沼无法自拔。客观的说从open source拿的代码质量q是非常高的Q而且有一
个完整的试框架和大量的自动化测试用例，但要作ؓ产品Q显然还需要锤点{port API?br />
问题相对一些，但很隑֏玎ͼ而且一旦出问题修正的周期非帔RQ无疑对我们的进度会?br />
很大的媄响?/p>
刚过了TCK我们_TCK都过了，应该没啥问题了，可是SVT报过来一堆bugQ我们恍ӞSVT?br />
TCK牛多了，真是什么bt的测试都有。等SVT都过了，H然冒出个RADQ一下就是十几个bugQ?br />
q发C个spec没实玎ͼ一问结果h家是试 -_-!!
做最好的希望Q做最坏的打算M时候都是适用?/p>
问题?/span>
兵力分散
上一条对q个有直接的影响Q也跟我们team人太有兟뀂项目中?个h只有一个h是绝?br />
部分旉在这上面Q其他h是需要了再过来，搞着jdwpq要搞其他的东西Q严重分散了_֊?br />
期间׃没赶上SR2Q中间有一D늛对空闲的旉Q大部分人都被抽取干其他的Q务，默认
是不会再有什么问题了。。。这实际上是我们team一直存在的问题Q一人多职，每个人都?br />
法专注在一件事上，造成每g事都效率不高?/p>
问题?/span>
反馈q缓
敏捷啊，又犯了敏L大忌。从目开始的头几个月我们没有试图去获得或者争取Q何反
馈，直到试l参与进来。即使我们能够获得完整的SVT试用例我们也没有尝试主动去获取
反馈Q跑SVT试Q，我们始终都是被动的。我们虽然没办法让客户尝试还没正式发布的?br />
本，但至我们自己可以，在team内部使用q是没什么问题的。jdwp大家qx调程序都会用
刎ͼ如果我们自己使用的话Q很多显而易见的bug׃会到最后才被发现。虽然作为SDK本事
不稳定会影响大家开发的效率Q但能及时发现问题，其扼杀在摇中Q我认ؓq是非常?br />
得的?/p>
问题?/span>
基础设施QInfrastructureQ不健全
我们的code repositoryq是不能不说的。ؓ什么会变成q样我也不太清楚QM它现在的?br />
冉|q样的：我们有自qcode repository AQ每ơ做integration buildQ我们会把当?br />
最新的代码发布到另一个repository BQ这个B不仅包括了我们jdwp的代码，q有其他我们?br />
q品的代码Qintegration build会从q里拿代码去build。注意这里的发布其实是复制
A里的文g到Bq且修改所有文件头的日期信息，q个动作是由脚本完成的，commit的注释就
是load module balabala之类没啥意义的东西，如果用svn diff看某个版本的修改Q你会看
到所有的文g都被修改了，l大部分仅仅是文件头被改了。看官可能要骂了Q不是个用?br />
做integration build的时库嘛，讲这么多q嘛Q其实我们的目只能在这个时库
buildQ因Z改过的脚本都在这里。各位现在能理解我们的痛苦了吗？我们必须在B上开
发，而B除了做更新外没有M用处Q如果要查看历史Q请去AQ要提交修改Q对不v请去AQ?br />
我在B上开发竟然要去A上提交！Q！ph回的折腾啊，我们的时间就q样消耗啊。。?/p>
q样看来整个目真是一团糟Q但我们竟然真的把它放进SR3了，当然q会?br />
SR4Q?Q?Q?。。。ؓ了不让惨剧l上演还有很多需要做Q?/p>
1. 修改 repository A 上的build脚本Q以后直接在A上工?/p>
2. clean 试用例Q补充测试用例，q是保证质量的第一兟?/p>
3. l织一ơ组内sharingQshare目的整体构Ӟq行机制Q常见工L使用Q常用的?br /> 决问题的方式Q将其记录在wiki上?/p>
4. 号召大家在日常工作中使用自己开发的工具Q小白鼠从自己做赗?br />
]]>
#!/bin/sh
case "$TERM" in
msys)
CONTEXT_COLOR="[37m"
ADD_COLOR="[32m"
DELETE_COLOR="[31m"
LOCATION_COLOR="[36m"
INDEX_COLOR="[35m"
NORM_COLOR="[0m"
;;
*)
CONTEXT_COLOR=`tput setaf 7`
ADD_COLOR=`tput setaf 2`
DELETE_COLOR=`tput setaf 1`
LOCATION_COLOR=`tput setaf 6`
INDEX_COLOR=`tput setaf 5`
NORM_COLOR=`tput sgr0`
;;
esac
svn diff $* |
sed -e "s/^+.*/${ADD_COLOR}&${NORM_COLOR}/g" -e "s/^-.*/${DELETE_COLOR}&${NORM_COLOR}/g" \
-e "s/^@@.*/${LOCATION_COLOR}&${NORM_COLOR}/g" -e "s/^[iI]ndex.*/${INDEX_COLOR}&${NORM_COLOR}/g" \
-e "s/.*/${CONTEXT_COLOR}&${NORM_COLOR}/g" |
${PAGER:-less -QRS}
case "$TERM" in
msys)
CONTEXT_COLOR="[37m"
ADD_COLOR="[32m"
DELETE_COLOR="[31m"
LOCATION_COLOR="[36m"
INDEX_COLOR="[35m"
NORM_COLOR="[0m"
;;
*)
CONTEXT_COLOR=`tput setaf 7`
ADD_COLOR=`tput setaf 2`
DELETE_COLOR=`tput setaf 1`
LOCATION_COLOR=`tput setaf 6`
INDEX_COLOR=`tput setaf 5`
NORM_COLOR=`tput sgr0`
;;
esac
svn diff $* |
sed -e "s/^+.*/${ADD_COLOR}&${NORM_COLOR}/g" -e "s/^-.*/${DELETE_COLOR}&${NORM_COLOR}/g" \
-e "s/^@@.*/${LOCATION_COLOR}&${NORM_COLOR}/g" -e "s/^[iI]ndex.*/${INDEX_COLOR}&${NORM_COLOR}/g" \
-e "s/.*/${CONTEXT_COLOR}&${NORM_COLOR}/g" |
${PAGER:-less -QRS}
׃windows上没有tputҎ所以只能直接写操作字符Q上面方块的字符可以通过下面命o结果输出到文g得到
echo -e "\033[31mtest" > out
tput setbf [0-7] 可以用来讄背景颜色。这有有颜色的代?
http://www.frexx.de/xterm-256-notes/
贴上来的代码中有Ҏ字符Q貌D解析成奇怪的东西了，可以点击q里下蝲
]]>
关于 RPC is bad 的主要论点如下：
The fundamental problem of RPC, which is trying to make remote calls look local, is based on essentially trying to ignore the problems covered by the fallacies or trying to pretend they don't even existq和我在自己的硕士论文中的观Ҏ些相|完全使用消息机制q行构g间的通讯。构件可?br /> 是分布式的或在容器中的，Z消息的通讯都是完全适用的。对于网l应用同样如此。对于流?br /> 的网l协议，HTTPQFTPQLDAP {等都是消息式的Q完全经历了旉的考验?br />
严重同意Q理由如下：
Network partitions are real, timeouts are real, remote host and service
crashes are real, the need for piecemeal system upgrade and handling
version differences between systems is real, etc. The distributed
systems programmer *must* deal with these and other issues because
they affect different applications very differently.
q一炚w常赞同，也深有同感。在做FileServer的时候所有的节点都是通过RMIq行通讯Q最初用RMI的目的就?br /> 化网l部分的开发，对于一般的开发h员无ȝ解RMIQ动态代理，只需要像使用本地Ҏ一样就可以讉Kq程
节点。这U方案确实很好的隐藏了网l细节，使网l对开发h员完全透明Q但有个问题始终无法很好的处理：异常?br /> |络错误是随旉有可能发生的Q对于不同的错误需要根据环境和需要做具体的处理，比如Q多试几ơ，试下一?br /> 节点Q对于无法处理的q可以直接抛出。而这U策略的选择和用必ȝ应用逻辑层完成，可是应用层假设是不知?br /> |络存在的，它甚x法知道自p用的Ҏ中哪个是q程调用Q哪个是本地调用。这U矛盾从Ҏ上说明了|络?br /> 复杂性和多样性是开发分布式应用的程序员必须面对的，是逃不掉的Q要直面q惨淡的人生T_T
下面阐述了用类型系l的~陷Q?br /> Such systems also have problems with impedance mismatch between the
IDL and whatever languages you're translating it to. If the IDL is
minimal so that it can be used with a wide variety of programming
languages, it means advanced features of well-stocked languages like
Java and C++ can't be used. OTOH if you make the IDL more powerful so
that it's closer to such languages, then translating it to C or other
more basic languages becomes quite difficult.
On top of all that, no matter how you design the IDL type system, all
the types won't -- indeed, can't -- map cleanly into every desired
programming language.
cdpȝ一直都在进化，从弱到强到动态，你相信会有一U类型系l可以和所?br /> 的其他语aq行完美的映吗Q如果真存在Q类型系l的q化毫无意义了。定?br /> 一个新的语aQ然后映到其他语言Q最后号U?#8220;我是跨语a跨^台的Q?#8221;Q这U?br /> 解决问题的方式根本就是有问题的。WSDL使用XML描述Q有着更好的可扩展性，只是
酒瓶换新酒，根烂了，再换也没用?br />
Ultimately, RPC is a leaky abstraction. It can't hide what it tries to
hide, and because of that, it can easily make the overall problem more
difficult to deal with by adding a lot of accidental complexity.
下面对ؓ什?message queuing system 适合分布式系l做了很好的ȝQ?br /> Message queuing systems work well because (in no particular
order):
* they don't pretend to be programming language procedure or method
calls, so they avoid the associated impedance mismatch problems
* they don't try to hide distributed systems issues
* coupling is low -- drop a message into a queue here, pick up a
message from a queue there
* queues can be persistent, or more generally, delivery guarantees can
be varied as needed
* asynchrony
* payloads need not conform to some made-up IDL type system
* getting two different messaging systems to interoperate is easier
than getting two different RPC or distributed object systems to
interoperate
]]>
diff --git a/hello.git b/hello.git
index 808c280..3e60fff 100644
--- a/hello.git
+++ b/hello.git
@@ -1,2 +1,3 @@
111111
sdfsfsdf
+111
index 808c280..3e60fff 100644
--- a/hello.git
+++ b/hello.git
@@ -1,2 +1,3 @@
111111
sdfsfsdf
+111
It's different with svn diff output format which we are familiar with, although patch can work with this format, but it would be strange if we applied a patch with git format to a open source project which use SVN as source repository. That's why i wrote git2svn, which convert git diff format to svn diff format. It's very very simple, only one line:
#! /bin/sh
# convert git diff output to svn format:
# git diff like:
#
# diff --git a/hello.git b/hello.git
# index 90d2950..808c280 100644
# --- a/hello.git
# +++ b/hello.git
#
# after converting, it's our familiar svn diff format
#
# Index: hello.git
# =====================================================================
# --- hello.git
# +++ hello.git
#
# It's useful to apply patch to project using svn as their repository and
# you use git for your local work
sed -e '/^[iI]ndex/s/^index.*/=====================================================================/' -e '/^diff/s/^diff --g\
it a\//Index: /' -e '/^Index:/s/ b\/.*//' -e '/^--- a\//s/--- a\//--- /' -e '/^+++ b\//s/+++ b\//+++ /' $*
# convert git diff output to svn format:
# git diff like:
#
# diff --git a/hello.git b/hello.git
# index 90d2950..808c280 100644
# --- a/hello.git
# +++ b/hello.git
#
# after converting, it's our familiar svn diff format
#
# Index: hello.git
# =====================================================================
# --- hello.git
# +++ hello.git
#
# It's useful to apply patch to project using svn as their repository and
# you use git for your local work
sed -e '/^[iI]ndex/s/^index.*/=====================================================================/' -e '/^diff/s/^diff --g\
it a\//Index: /' -e '/^Index:/s/ b\/.*//' -e '/^--- a\//s/--- a\//--- /' -e '/^+++ b\//s/+++ b\//+++ /' $*
Another, can't call it as 'tool' exactly, I think, just a convenient way or shortcut to query which files are changed in one or between two commits and their status, like 'svn diff --summarize':
#! /bin/sh
#summary changed files which status, in one commit or between two commits
git-diff-tree -r --name-status --pretty=format:"%Cgreen%s %CblueSHA1: %H%Creset" $*
#summary changed files which status, in one commit or between two commits
git-diff-tree -r --name-status --pretty=format:"%Cgreen%s %CblueSHA1: %H%Creset" $*
You can also do it like this:
alias git-diff-tree -r --name-status --pretty=format:"%Cgreen%s %CblueSHA1: %H%Creset" git-changed-files
and add this line to your $HOME/.bashrc]]>
switch branch
checkout -b <new branch>
create new branch and switch to it
checkout <file>
checkout file in HEAD and overwrite local file (NOTE: use it carefully, maybe lost your local work)
diff
diff index and working copy
diff --cached
diff index and last commit, which is what you will commit without '-a' option
log
display commit logs
log -p
include commit diff
log --first-parent
follow only the first parent commit upon seeing a merge commit. This option gives a better overview of the evolution of a particular branch.
log -S'string'
commits which add or remove data matching the 'string'
log -r --name-status
show changed files with full path and status, just like 'svn diff --summarize'
branch
display all branches, current branch started with *
branch -r
display remote branches
merge --no-commit
not commit immediately, all changes write to index
reset --mixed
default, adjust HEAD and clear index, changes in working copy is reserved, and changes between original HEAD and current HEAD will write to working copy
reset --soft
adjust HEAD, changes between original HEAD and current HEAD will write to index
reset --hard
adjust HEAD, and clear index and working copy (NOTES: only use it when you are sure that the changes in index, working copy and changes reset in history will never be used)
]]>
发现自己真的是很懒啊QL没法坚持写些东西Q从本质上说我还是个不擅长写作的
E序员，正确的表达自己比写出正确的程序要困难许多Q表辑և能让别让共鸣的东?br /> 更是难上加难?br /> 但是Q文章还是必要是会写的Q牛皮也是必要会吹的。神啊，请允许我再一ơ许诺吧Q?br /> 试着写点东西吧?br />
]]>
ȝ发现最新的文章竟然是半q以前了Q还L“不再偷懒了”，实在惭愧啊。项目一忙v?br /> 实是顾不上了，回来q有看动ȝ的重dw自然更是无暇顾及了Q说到底自己l久不是
喜欢码字的h。不q翻M前写的东西还是蛮有意思的Q有些东西回头看看还是很有好?br /> 的，于是军_q是写写吧，哪怕下一ơ会是半q以后^_^
最q工作搞定了QFileServer也初见成果，正在整理代码Q是时候好好整理一下前D|间工作的体会了，W一ơ组l项目还是有很多感想可写的，请各位看官（如果有的话）敬请期待吧！Q！
]]>