在Snow Leopard的Terminal里面用sudo的时候总是需要输入密码，而在单位的FreeBSD服务器上则不需要。我觉得从安全角度来说这个密码用处不大，有了反而会浪费时间。
搜索了一下，发现要这样做：
修改/etc/sudoers文件（记得sudo vi它，存的时候要w!），去掉这一行前面的#号：
%wheel ALL=(ALL) NOPASSWD: ALL
然后执行下面命令，记得将your_username替换为你的用户名：
sudo dscl . append /Groups/wheel GroupMembership your_username
从此就不需要在sudo的时候输入密码了。
今天要做一个python里面内存效率的测试，所以需要查看当前运行的python unittest的内存占用情况，查了一下发现psutil可以帮助你做这个事情，这样的代码就可以工作，需要安装psutil，我用的sudo pip install psutil：
class MemoryInfo(object):
def __init__(self):
self.current_process_id = os.getpid()
self.current_process = Process(self.current_process_id)
def usage(self):
return self.current_process.get_memory_info()
def print_usage(self):
usage = self.usage()
print '物理内存: %sKB, 虚拟内存: %sKB' % (usage[0]/1024, usage[1]/1024)
用的时候你可以实例化一个MemoryInfo()然后分多次调用它的print_usage方法。结绳记事。
Matin fowler 大师在这篇文章 《Richardson Maturity Model: steps toward the glory of REST》，用一种伪成熟度模型的方式为我们揭示简单的Rest如何让Web成为未来软件开发的一个通用平台。其实我以前就职的ThoughtWorks里面的同事早就在研究Web as platform这个Buzz，因为这是一种通过成熟的标准让我们日常的开发更简单更容易被Mashup的好方法。其核心思想就是利用Rest和Atom让应用程序API变成Plain web应用，这样所有现有的Web应用api就很容易被你的应用Mash up进来，这样我们的世界就真的成为了一个网。所以，坚持Rest best practice，争取早点让你的系统建在Web平台上。
Atom在让Rest api连接起来，让你的应用变为以资源为中心很重要：
刚才实验了一下，发现Python里面声明类的时候是否选择继承objects还是有很大区别的。只有继承了objects，才可以使用钩子方法如’__get__’, ‘__set__’, ‘__getattr__’, ‘__getattribute__’这些方法。也就是说这些有用的钩子方法是所谓的new object里面的东西。今天我在项目的代码里面尝试了一下类似Ruby method_missing的写法，实验在Python里面加点元编程的东西。发现很相似的三个方法’__get__’, ‘__getattr__’, ‘__getattribute__’方法区别挺大。注意，一定要继承object才可以享用三个钩子方法。
我目前还没有调用方法的method_missing，目前只是访问一些属性。我们实际处理的是一个可以直接用属性名读取/修改对象里面的持久化json属性的方法，就是类持有一个{‘property’: ‘value’}的json文本属性，我们就可以直接用Model.property访问和修改里面的方法，而不用特别的去生命json结构过来。是一个在Python中做meta programming的尝试。
测试刚才说的几个*get*方法的测试如下:
# -*- coding: utf8 -*-
import unittest
class A(object):
def __init__(self):
print 'init A'
def __get__(self, *args):
print '__get__ A', args
def __set__(self, *args):
print '__set__ A', args
class B(object):
a = A()
def __init__(self):
print 'init B'
def __getattr__(self, *args):
print '__getattr__ B', args
def __getattribute__(self, *args):
print '__getattribute__ B', args
raise AttributeError
def __get__(self, *args):
print '__get__ B', args
def __set__(self, *args):
print '__set__ B', args
class MeTest(unittest.TestCase):
def test_simple(self):
b = B()
print b.a
b.a = A()
b.c
hasattr(b, 'e')
Mac下对网络设备使用proxy自动配置脚本可以透明使用代理穿墙（可以配合ssh tunnel和tor）。但是我一直不知道如何用脚本让系统重新载入pac文件（在更新了pac的规则时我们需要重载配置）。昨天一位叫做Dylan的网友留言告诉了我如何做，我在此记录一下。在命令行下面：
networksetup listallnetworkservices
然后会会返回一个网络连接服务的列表：
An asterisk (*) denotes that a network service is disabled.
Bluetooth DUN
ADSL
Ethernet
FireWire
AirPort
Bluetooth PAN
我一般需要配置pac文件的是Ethernet和AirPort，那么相应的重载命令是：
sudo networksetup -setautoproxystate 'AirPort' off
sudo networksetup -setautoproxyurl 'AirPort' 'file://localhost/Users/tin/pac/tin.pac'
sudo networksetup -setautoproxystate 'AirPort' on
sudo networksetup -setautoproxystate 'Ethernet' off
sudo networksetup -setautoproxyurl 'Ethernet' 'file://localhost/Users/tin/pac/tin.pac'
sudo networksetup -setautoproxystate 'Ethernet' on
然后pac文件就已经被重载完毕啦！在此感谢Dylan。
顺便共享一下我在bash下的alias：
alias px='ssh -qTfnNC -D 7777 tin@zztin.com'
alias rpx="sudo networksetup -setautoproxystate 'AirPort' off;sudo networksetup -setautoproxyurl 'AirPort' 'file://localhost/Users/tin/pac/tin .pac';sudo networksetup -setautoproxystate 'AirPort' on;sudo networksetup -setautoproxystate 'Ethernet' off;sudo networksetup -setautoproxyurl 'Ethernet' 'file://localhost/Users/tin/pac/tin.pac';sudo networksetup -setautoproxystate 'Ethernet' on"
比较奇怪的是safari不能通过proxy查询dns,现在只好用ff+foxproxy.
不知有什么诡异的设定能搞定safari吗?
用privoxy把socks代理转变为http代理，浏览器就可以使用代理做dns查询了。
博主能否提供一个编译好的for mac osX 10.6.2的privoxy，我去下载，似乎都只有源码，编译这种事情对我等菜鸟来说，难度太高，搞不定。要是有空的话，打包个有图形界面的app那就太完美了。谢谢。另外，pac文件我写来写去都不能工作，博主能提供一个在mac osx 10.6 下可用的pac文件范本么？
所做的系统是一个连接到外部信息发送和搜索引擎调用服务的Web前端系统。系统与外部的接口使用的是一层Service外观进行包装，原先的设计目的是使用服务层剥离对外部系统的强依赖──解耦，同时还希望使用Service将系统的商业逻辑集中存放──提高复用的可能。但是实际上我们发现Service这样的抽取方法并没有提高代码的复用度，反而造成数据结构和其算法的大量重复。经过分析，发现由于使用了大量的Hash结构存放接口间的返回结果，造成数据与其Service内部的行为分离，传递后商业逻辑就出现了重复（这样的结果是引入大量Quick but dirty的解决方案所欠下的技术债造成的）。所以我和我的Pair绝对对其进行DDD（领域模型驱动设计）的重构。
领域模型驱动设计和面向对象设计在代码的抽象上很相似，它们都推荐让数据结构（状态）与商业逻辑（行为）统一管理。这样数据的状态与行为就不会分离，这样可以很大的减少由于商业逻辑分散造成的代码重复。这可以让我们实现我们非常重视的DRY（Don’t repeat yourself）。
一开始我们尝试的是找到重复的商业逻辑和其对应的数据结构，然后尝试让它们映射到我们的领域模型。这样的效果还不错，但是经过了一天的工作，我们发现我们对领域模型的理解有问题，我们居然抽取出了重复的领域模型类。这个时候暴露的问题是我们对系统的领域模型没有统一和深入的认识。
所以下一步我们计划进行领域模型语言的讨论会，目的就是使用自己的“领域语言”描述系统的所有行为，从这样的领域故事中找到我们的领域模型（领域概念模型，不是具体编程的时候的类）。
领域模型讨论会最好由最熟悉领域模型的人起草，可以由这个人把它写在白板上。领域的故事最好能够涵盖系统的主要行为，描述要使用简练的语言。一般来说IT系统的内部行为可能很复杂，但是到了领域高度还是可以用比较简单的语言描述的，如果遇到一块白板不够的话最好首先考虑提高观察的高度，让领域的描述简练一些，其次再考虑扩展到第二块白板。在这个过程中我们要注意消除歧义，比如同样一个“术语”在两个功能区域中出现，那我们就要妥善的给他们各自取一个容易区分的“领域术语”作为名字。还有就是我们应该在写领域故事的时候考虑领域模型（或者理解为系统模块的抽象）之间的交互关系，最好在写领域故事的时候对行为的归属（它会指导行为到底会被建模在哪个领域模型中，可以体现为类的调用关系，哪个类持有交互逻辑）达成共识，这个时候达成的共识比在做具体的OO设计时候分辨商业逻辑归属要更体现商业价值。完成领域故事后我们要找到其中的所有领域模型（也就是前面说的领域对象和领域中的术语）。然后团队最好一起通读这个用户故事，一起讨论是否通顺（行为是否完备，抽象是否合理），是否有遗漏（遗失的领域模型或行为）。对于有外部系统的情况下，即使外部系统是面向消息的（或者说是没有使用领域模型驱动的SOA接口），那么团队最好对消息的内容有一个讨论，对其中设计到本系统和外不系统的领域模型进行认领，然后使用一个适配器来保证数据到达系统后就使用领域模型表示，外不系统的数据（一般没有行为）最好也使用一个领域模型进行约定。
完成了上面这一步后，DDD最重要的一部分就完成了，它可以实现系统领域模型自顶向下的“名正言顺”，减少在自底向上的重构过程中产生的大量重复领域模型。下面的重构过程就是给领域模型写测试，使用TDD（或者也可以用BDD的方式提早对行为做验收测试，用它们来驱动对领域模型的实现，其实对领域模型的TDD和BDD是殊路同归）的方式逐一实现领域模型。而后争取给系统写一些验收测试或者高级别的集成测试，再逐一替换这些领域模型。这样就达到了DDD重构的效果。
看完老赵精彩的两篇“可测试性驱动开发（上）”，“可测试性驱动开发（下）”。
写了篇回复
老赵，我觉得你说的“可测试性驱动开发”和“测试驱动开发”的结果是非常接近的，可是实际观察下来我觉得不是一样的。我觉得测试驱动开发的一个好处就是从外界向内部逐渐迫近，逐渐的暴露的你意图。意图其实是更接近你的商业流程和商业价值的。所以更接近与“意图驱动开发”。因为TDD鼓励从系统的外部行为向内部行为逐步细化，逐步测试－通过，循环。这样产生的结果就是方法小，方法名考究，高层的代码非常容易读懂（经常达到看起来就像文档）。
可是在“可测试性驱动开发”中，我觉得随时考虑的还是“可测试性”，但是“可测试性”本身与商业价值无关。所以驱动开发的东西就转变为程序员自己的一些“修养”问题了，你可能会倾向于使用模式来解决一些微观问题，让代码具有“可测试性”。这种做法可以产生组织良好的代码，它对于程序员来说易读（容易理解算法细节），但是这样的代码在被维护更久以后容易产生与商业价值的偏离。还有就是“测试性驱动”的经济问题，如果一个测试是纯技术意图驱动的，那么就是追本逐末了。
测试驱动开发中的ATDD（验收测试驱动开发）鼓励你将系统的流程Spec在实现前写出来作为驱动，而BDD则从微观行为上将你的领域模型的行为Spec写出来驱动，这两种方式我想才是经典TDD的“新外衣”，因为他们都继承了“意图驱动”并进化为“商业意图（价值）驱动”。
此文甚好，只是我觉得上面问题是个关键，”目标“最好还是在产生”策略“之前找到比较好，所以才写这个评论，冒犯了 ^___^
在ThoughtWorks就要两年了，相比进来之前的自己，现在做事可以抱有更低调的态度了。因为当你和众多聪明的人做事情的时候，你不得不谦虚，逐渐的你就会形成“开放性格”，这是我从ThoughtWorks收获的最有价值的东西。
今天反思一下自己在开发中遇到的一些问题和TW的答案（只是一个Check list，没有逻辑顺序），有如下地方需要考虑：
困了，下次继续。
写的很好，#1，#5，#7 很受用。
回应hax大牛在“em or px“的讨论：
上次看到你在我分享的friendfeed上面的评论我就想好好讨论一下这个问题了。’em’是从字体设计上面继承的一个概念，是指字模的高度，一般书上会说em能够保证不同字体的大写X的高度保持一致。那么大写X的高度就是这个字体的em。
你说的px是相对单位不仅在你说的显示器尺寸上是相对的，而且由于大部分的矢量元素的渲染来说比较先进的浏览器都支持“半像素平滑”，连像素内的颜色的投影也可以是相对的（渲染引擎会进行像素平滑的计算）。
在网页渲染的布局上来说它要转化em到px这个单位，就是说在一定的zoom下两者是等价的。
但是为什么我还是很支持使用em作为首选的字体和布局单位呢？当然这不是用来保证一行到底可以显示多少文字，因为px也可以保证。主要目的是区分布局中“缩放友好”的矢量元素（如字体，布局相关的所有html元素）和“缩放不友好”的标量元素（如很多“替换元素”是不友好的，典型的如图片，还有在使用某些Windows主题以后的input元素）。在使用webkit的浏览器，缩放会更加友好，文字和布局会随缩放变化，但是图片等却保持原有的最佳尺寸。Firefox3以后所使用的全部缩放我觉得在有些时候是有用的，可是总有它让你不爽的地方⋯⋯
比如如果你在某些设计场合希望容器变大文字尺寸不变，从而在缩放显示更多内容。另外一些地方你希望容器和文字尺寸一起变化。px和em的配合让两种需求可以比较容易的在同一个页面出现。
从设计为内容服务的角度考虑，使用em作为基本单位可以让你更集中于“内容驱动”，避免过分的”设计驱动“。我的工作范畴内前者更常见，也更符合客户的需求。
em是大写X高度这个我倒没听说过。我只知道ex是小写x高度，并且x-height是字体排版中的非常重要的概念。
针对屏幕的浏览器中，网页样式计算出来的最后结果（computed value或used value），都是以px为单位，而且是允许小数的。“半像素平滑”带来的区别，可以认为是在actual value上，原本必须取整，即渲染引擎只支持整数，现在渲染引擎支持了小数——虽然屏幕上的物理像素总是离散的。
你后面说的意思我反复考虑了2个小时，觉得值得深入探讨。你提出的将em用来标示“缩放友好”（实际我觉得是“文字缩放友好，text zoom friendly”，具体我们再讨论）这个问题，不仅涉及页面的设计，也涉及浏览器的设计。它还暗示了引入css新长度单位rem的必要性。有机会和你当面聊，然后再做总结。
btw，偶属羊不属牛。。。
BTW，这个页面的默认字体好像小了一点。comment的字都看不清了。不过倒是正好做你的zoom friendly的样本。。。
关于计算值的你说的很详细，现代浏览器都可以在actual value里面使用小数。不过我观察IE6/7好像并不支持半像素，因为之前我fix一些半像素造成的bug的时候发现IE并不受影响。
css3里面的rem这个单位感觉只是一个更方便的（不继承）的em。现在的情况下em已经工作的不错了，起码对于我比较喜欢的safari来说。你所说的ex和em（还有百分比）很相似，都是相对单位（Relative length units），他们都是相对于绝对单位（如px和gd）所言，我认为css设计的本意就是解决不同的缩放效果（和不同的设备映射关系）的。
从《写给大家的设计书》这样的从设计角度考虑内容的书里面推荐字体尽量一致，如果不一致则尽量不一致，基于这样的理念，使用em比较流畅。当然这个和使用的字体有关，中文字体一般不能保证缩放平滑（尤其是linux和windows），所以倾向使用px是合理的。可惜我目前所做的英文应用比较多，英文字体缩放相对平滑（尤其是放大），所以我们选择em就比较流畅。
FF3和IE8里面那样的缩放并非我所希望的样子，这个角度如你所说em/rem可能是个很重要的单位了。
BTW：我太懒了，用的wp的默认主题，这个字号绝对是为英文设计的。待我老婆批准时间我修改个theme出来……
redoasis, 
xyb, and 
Dylan are discussing. 
电脑知识 3:19 pm on August 3, 2010 Permalink
Hen Hao Hen Qiang Da,yeah~