发现一个对Developer使用laptop的好方法,在你的屏幕背面粘上尼龙搭扣(毛茸茸的那边),然后在你的移动硬盘上也粘上(带很多小钩子那边),这样在移动办公的时候你就可以把它们粘在一起了!这样就可以把你的巨型iTunes、iPhoto library外置了。
而且在你把它们放在包里面的时候你还可以方便的把它们分开。好点子。这个点子来自这里:Screen pairing
you are coming a long way…
发现一个对Developer使用laptop的好方法,在你的屏幕背面粘上尼龙搭扣(毛茸茸的那边),然后在你的移动硬盘上也粘上(带很多小钩子那边),这样在移动办公的时候你就可以把它们粘在一起了!这样就可以把你的巨型iTunes、iPhoto library外置了。
而且在你把它们放在包里面的时候你还可以方便的把它们分开。好点子。这个点子来自这里:Screen pairing
我的硬盘总是不够用,因为以前有集图的习惯,也有收集音乐的习惯,再加上现在高清电影的泛滥,还有吃空间的TimeMachine,所以硬盘吃紧是没办法的事情。正巧赶上硬盘再一次降价,1.5T的Seagate 7200.11系列单碟375G的硬盘只要899,所以赶快再上一块(小插曲是,老婆说这个算是生日礼物,sigh~)。配合3个月前入手的1T那块,基本解决现在的硬盘不够的问题了。
我家两块外置硬盘,一块被命名为DeepForrest (1.5T, USB),也就是现在这块。令一块被命名为BlueRay (1T, USB+1394a)。上图:
一块儿到来的还有一个Tp-Link的WL-841N的802.11n路由器,300Mbps的无限连接,评测的数据是可以达到100Mbps也就是我家有线网的速率。
型号是ST31500341AS,就是1500GB空间,375G单碟,4碟装,台式机硬盘。听说CC1G这个固件版本不是很好,我做外置硬盘倒是无所谓。
现在的Seagate使用了和WD一样的反装电路板,两年以来这个技术已经普及了。
装到盒子里面去。我使用的是WD的硬盘盒,实际上是拆机货。WD的外置盒子其实质量很好,没有访问的时候会自动断电休眠,还有个好处就是便宜。
控制芯片是目前高端盒子常见的Oxford semiconductors出的OX921S,这个盒子是三个里面最简单的,单USB。
他们叠放在我的桌子上就是这么个效果,就是那个破音箱上面的三个发光的小家伙。这个照片是上周日的,实际上硬盘还不是1.5T的,不过意思是一样的。
现在正在迁移数据中(mv -v)。以前很喜欢玩硬件,常去Q3ACN雷神硬派玩,也经常写评测,但是现在已经没有那个闲心了。但是我依然喜欢玩硬件,我依然对它们充满好奇心。^___^
看到Fenng同学共享了自己的书柜的照片,我也想把我的书柜照个像放上去。
这几年买书也上万了,当然不都是计算机的书,还有很多闲书
经典的技术书籍占了我的书柜的绝大部分区域。还有一些漫画书,大都是大学时代留下来的。
一些放不下的书就随手放在转角的书柜里。
为书花钱大都值得,不过技术书容易过时,处理的时候又舍不得。即使是好书,它也会对你的移动性产生不良的影响,搬家的时候这些东西可是太沉了。
我们招聘美工的过程中,有一道题:“一个UI的Hifi prototype,客户感觉系统有些压抑,希望修改一下这个设计”。前面两个面试者我们都让他当场做,可是结果不理想,主要原因是他们不习惯Mac下的Photoshop或者Fireworks。所以第三个面试的时候,我们让她回家试试。结果让我很失望,主要原因是美工的思路不对。她修改了不少细节,修改了几个按钮的设计,加上了水晶的反光,修改了Tab设计,加上了玻璃的风格,可是她无视了对比度过低造成的界面太灰的问题,也无视了排版的一些基本的禁忌(比如一致性)。
我非常认同的一句话是对于美工的日常设计90%都是排版工作。那么我列出我对这个作业的考察点:
它们的优先级是60%,30%,10%,也就是说排版和颜色最为重要。
这不是一个系统的想法,并不适用于美工的日常工作,我主要强调做这样事情的一个思路,美工需要用自己的工具来引导客户。
代码重构(Code Refactoring)是一个编程的术语:在保留原有的功能的情况下改变计算机程序代码让其容易被修改为适应变化、增加可读性或者简化结构。这个实践对于产生高质量程序非常重要,而且这种想法不仅限于编程概念,也完全可以用在生活上。我的blog里面也会经常用到这个词(重构我人生),所以今天我决定就把生活的记录工具blog给重构一下
对于程序员朋友,这里插播一个问题,我发现中文的wikipedia对于代码重构(Code Refactoring)的定义非常的不准确,摘抄如下:
代码重构指对软件代码做任何更动以增加可读性或者简化结构而不影响输出结果。软件重构需要借助工具完成,重构工具能够修改代码同时修改所有引用该代码的地方。在极限编程的方法学中,重构需要单元测试来支持。
为什么呢?因为martin folwer使用的定义和英文wikipedia这个一致:
Code refactoring is the process of changing a computer program’s code to make it amenable to change, improve its readability, or simplify its structure, while preserving its existing functionality.
中文解释里面所说的重构需要借助工具完成支持纯属放屁。而且遗忘了重构的一个目的是为了让代码易于维护那么就没有说明重构的经济意义。所以,大家看看我上面那个翻译如何?一起修改一下我去修改一下wikipedia的条目。
回到我要说的blog重构的话题。我现在的blog使用的是Wordpress,但是再往前推我还在Live Space和BlogJava写Blog。但是那个时候没有使用Tag来管理blog post,所以都使用了很复杂的分类(Directory),再后来我把Live Space的blog通过MSN Space mover迁移到了现在你阅读的这里,所以那些目录也就都被迁移过来了。
所以多分类Category是我第一个要重构的地方。原因在于分类最早的设计是一个严格的树形结构,也就是分类是一个逐级缩小范围的概念,它适合于自上而下的查找。比较常见的就是传统电子商务网站的目录和网站的树形导航。但是这两年大家发现很多人的阅读习惯并不是这样的,尤其对于blog这样的形式。blog我们分成两种场景来分析分类的使用:
啰嗦了半天,其实行动很简单。我需要把现在复杂的Category转换为Tags,还有添加新的简单分类“Tech.技术”和“NoneTech.非技术”。在Wordpress里面这个很简单,因为在wordpress里面Tag和Category实际上是同样的东西,但支持不同的显示方式。在wordpress的后台的Manage->Categories下面有一个category to tag converter的链接进去选择你想要转换的Category然后转换一下就OK了。一个简单的操作以后这些Category就都不见了。那么所有的文章就都跑到Uncategoires下面了。我好需要重新做一下分类,这是个体力活……不过我使用了Wordpress的客户端来实现。
那么下一步就是重构blog的下一个话题,选择一个客户端工具来更新你的blog。我试用了ecto和MarsEdit,它们是mac下两个有名的blog客户端,它们对blog的管理功能都差不多,但是编辑方式不一样,其中ecto的编辑器是所见即所得的,而MarsEdit是一个直接写HTML源码然后预览的界面。我对HTML烂熟,所以用MarsEdit没有困难。大家可以根据自己的需求选择,它们都是需要交注册费的。试用客户端的好处就是不用忍受浏览器的崩溃,不用忍受网络闪断造成的提交失败,不用因为写post时间太久而session过期,可以方便的存在本地,可以在离线的方式下修改/添加blog post,这些功能可以帮助你频繁的写blog,而不是每次都需要准备很久来登陆->新建post。我其实已经试用了几天Ecto了,比较满意,但是Ecto的试用版不能选择取回条目的数量(不知道注册以后是否可以?),所以对于修改分类这样的任务来说MarsEdit才可以修改我全部的项目。
在整理blog post的时候,我发现我这里有很多以前留下的Twitter聚合内容,我把它们都删掉了。以前我曾经想把micro blogging(微博客)的内容也放到blog里面,可是我发现有了FriendsFeed这样的工具以后我就不需要用blog来聚合了,这样是一种明显的Bad smell-重复。冰云同学批评过我聚合Twitter,他说的很对,现在我本人也很反感聚合Twitter,有这种行为的人的blog一律退订。
上面说的这些就是今天重构的实践,之前我还做过几个实践:保持只有一个blog服务(不需要同时使用Space和blogjava),如果不满意BSP(Blog service provider),那就自己买空间架一个Wordpress。定时备份你的Blog,并且最好有工具让你的blog可以转移成中立的源文件(如SQL、XML),方便以后迁移,选择BSP也可以以这个为标准。
最后总结一下我提到的重构blog的几个实践:
如果以后还有其它重构行为我还会更新这个post。今天已经好累了 -。。-
工具就是进行生产劳动时所使用的器具。工具的目的在于提高生产劳动的效率。感慨于一些真正的Geek的blog,我也想了一些工具对于我的重要意义,用来作为下一段的目标。
人家说工欲善其事必先利其器,还有磨刀不误砍柴工,实际上在说明工具对提高工作效率真的非常有意义。
今年的我,上游离于前端开发和后端开发之间,同时我还要在两个不同的团队(ThoughtWorks Studio的Cruise和Mingle两个产品开发团队)之间切换,所以对于我来说频繁的需要Context Switch(工作环境切换)。两个团队所使用的技术也不同。
我想对于一个强悍的程序员(最近比较崇拜的delphij、hdcola、云风等神人)来说做这样的环境切换也许还是可以的。可是对于我这个不善于multi-task工作的人来说,马上让脑子适应不同环境,熟练使用不同的工具就成为了一个挑战。
所以,结果是,这一年中,我基本上对于这些工具很少深入学习,基本上就是凑合着使用,如果没有通用的快捷键我就懒得去翻手册学习了。结果就是使用HG的queue功能(超级有用的qnew、qrm、qpop、qpush系列)的时候经常把自己搞崩溃(今年居然有和李彦辉教授在pair的时候搞丢了2个小时内的修改,相当丢人),所以后来在使用HG的时候异常小心,生活在心理阴影下面。而对于Git,我居然完全没有使用过stash功能(和HG的queue类似)。昨天胡凯还问我是否用过bisect,是一个折半查找坏提交的功能(在HG和Git里面有等价的功能),我完全没有使用过。因为这些精巧的基于命令行的源代码控制工具对于程序员来说非常之重要,从这个角度体现了我对于工具的不求甚解达到了什么程度。突然想到梅兰芳里面十三燕那个很棒的台词“输不丢人,怕才丢人”,用不好工具没事,但是害怕学习用工具那就是很丢人的问题了。
那么自我分析的结果就是,由于环境切换,我缺少了专注,形成了对学习环境中的工具的恐惧,最后影响了我的工作效率。
下面的内容用来自勉,分析一下工具对于我到底有多么的重要(也就是说这个是我使用和学习工具中比较Happy的部分)。对于还没有注意到工具重要性的朋友,可以关注一下,看看是否有所借鉴。
下面要分析一下我做的不好的地方,迎来跟踪我的改进:
暂时先准备写到这里,其它的关于工具的话题我会另开post来总结。(最后更新于2008年12越21日)
因为是feedburner的feeds,所以我就转过来。
Concurrency is a Myth in Ruby
Concurrency introduces parallelism into our applications, and threading is, of course, one way to achieve concurrency. But it turns out that in Ruby, this relation is not transitive: execution parallelism is not the same thing as threading. In fact, if you’re looking for parallelism in your Ruby application, you should be looking at process parallelism instead. So why is that?Ruby under the covers: Global Interpreter Lock
To understand what’s going on, we need to take a closer look at the Ruby runtime. Whenever you launch a Ruby application, an instance of a Ruby interpreter is launched to parse your code, build an AST tree, and then execute the application you’ve requested – thankfully, all of this is transparent to the user. However, as part of this runtime, the interpreter also instantiates an instance of a Global Interpreter Lock (or more affectionately known as GIL), which is the culprit of our lack of concurrency:
Global Interpreter Lock is a mutual exclusion lock held by a programming language interpreter thread to avoid sharing code that is not thread-safe with other threads. There is always one GIL for one interpreter process.Usage of a Global Interpreter Lock in a language effectively limits concurrency of a single interpreter process with multiple threads — there is no or very little increase in speed when running the process on a multiprocessor machine.
Deciphering the Global Interpreter Lock
To make this a little less abstract, let’s first look at Ruby 1.8. First, a single OS thread is allocated for the Ruby interpreter, a GIL lock is instantiated, and Ruby threads (‘Green Threads‘), are spooled up by our program. As you may have guessed, there is no way for this Ruby process to take advantage of multiple cores: there is only one kernel thread available, hence only one Ruby thread can execute at a time.
Ruby 1.9 looks much more promising! Now we have many native threads attached to our Ruby interpreter, but now the GIL is the bottleneck. The interpreter guards itself against non thread-safe code (your code, and native extensions) by only allowing a single thread to execute at a time. End effect: Ruby MRI process, or any other language which has a Global Interpreter Lock (Python, for example, has a very similar threading model to Ruby 1.9) will never take advantage of multiple cores! If you have a dual core CPU, you’ll have to run two separate processes.
JRuby is, in fact, the only Ruby implementation that will allow you to natively scale your Ruby code across multiple cores. By compiling Ruby to bytecode and executing it on the JVM, Ruby threads are mapped to OS threads without a GIL in between – that’s at least one reason to look into JRuby.
Process parallelism
The implications of the GIL are surprising at first, but it turns out the solution to this problem is not all that complex: instead of thinking in threads, think how you could split the workload between different processes. Not only will you bypass an entire class of problems associated with concurrent programming (it’s hard!), but you are also much more likely to end up with a horizontally scalable architecture for your application. Here are the steps:
- Partition the work, or decompose your application
- Add a communications / work queue (Starling, Beanstalkd, RabbitMQ)
- Fork, or run multiple instances of you application
- Not surprisingly, many of the Ruby applications have already adopted this strategy: a typical Rails deployments is powered by a cluster of app servers (Mongrel, Ebb, Thin), and alternative strategies like EventMachine, and Revactor (equivalents of Twisted in Python) are gaining ground as a simple way to defer and parallelize your network IO without introducing threads into your application.
虽然本文是介绍Ruby1.8、1.9和JRuby对线程的不同实现。但是却清晰的解释了线程安全的意义,还有为什么MRI(或者同样使用GIL的CPython)需要使用多进程模型部署。再延伸我们可以知道Apach上面的Mod_rails(Passenger和Ruby Enterprise Edition)还有Mod_python的神奇之处,他们都hack并实现了使用fork让进程共享内存。最后本文还同样引出了为什么传统Ruby和Python应用只有使用多进程才可以利用多个CPU,还有为什么Twisted和EventMachine使用了单进程单线程+event IO的模型。
最近很迷陈绮贞,买了国内能买到的几张正版专辑。
前一段时间把Mingle的svn用git-svn在本地clone了一个git repository,不过后来非常奇怪的是git svn的时候提示命令找不到了。没有在意。
今天需要用git svn rebase一下这个repository,所以到处搜索为什么?最后发现了问题在于我使用macports安装的git-svn,但是升级的时候却使用了git install,结果造成了系统中安装了两个配置不同的git-core包,而包含git-svn的却没有被激活。
执行
tin@tw-dell:git_mingle >port installed The following ports are currently installed: … git-core @1.6.0.2_0+bash_completion+doc+svn git-core @1.6.0.2_0+doc (active) …
就是说+svn的git-core目前没有激活,那么好办了。
tin@tw-dell:git_mingle >sudo port deactivate git-core @1.6.0.2_0+doc —> Deactivating git-core 1.6.0.2_0+doc tin@tw-dell:git_mingle >sudo port activate git-core @1.6.0.2_0+bash_completion+doc+svn —> Activating git-core 1.6.0.2_0+bash_completion+doc+svn
其中先deactivate现在激活的git-core,再activate+svn版本的git就OK了。 如果你还没有安装,这样安装:
sudo port install git-core+svn+bash_completion+doc
–EOM–
托同事从香港给带了iPod touch 2,好兴奋的拿到了这个iPhone的替代品。因为我一直以来很像有一个像样的掌上设备可以有空做做开发,而iPhone/touch可以说是不二之选,因为从艺术的眼光上看他们很完美(起码我这么看)。而且多点触摸带来的交互革命激发了我作为UE边缘认识的兴趣。
iPod touch 2多了录音功能,所以也可以配合fring实现skype通话,不过前提是你需要购买带mic的耳机,目前似乎只有Apple原装的,要220港元,好贵,所以暂时还没有出手买这个。但是机身先下手了。是从国美(香港)买的,因为很多retail的地方都售空了。
现在的iPod包装实在是简单,连说明书都没有,只有一个简单的开箱指南,还有一个基本的连接iTunes的说明,仅此而已,不过倒是这样就够了,因为可以把你的眼球固定在touch上,让你自己好奇的去探索。我觉得激发用户的探索意识是很好的一种让用户产生沉浸感的营销方式,而且从苹果一向的交互设计理念上来说,他们非常注重启发式探索,并且尽量让你本能的达到自己所期待的结果,这个正是交互设计的重点所在。
那么不废话这么多,上图。图是上周一晚上照的,最近生活节奏太快,现在才抽空出来显摆^____^