Mac Resources

九月 18, 2007

购买Mac

九月 12, 2007

最近正在筹划如何比较合算的购买一台Mac,购买Apple的东西的方法比较多,在线购买或者线下购买,Apple自己的商店或者第三方的商店,都有一些不同的讲究。

使用Education Discount实际购买者现身说法:

结论就是:
对于Apple Online Store上面使用Education Discount进行购买的话,Apple可能会进行随机的检查。而且照回复的情况来看,随机检查的概率还是比较高的。如果被发现是欺骗的话,会要求退款。如果不理会这一退款请求的话,可能会收到律师信…因为省的不多,100刀也就800RMB不到,比较起来还是不值得冒这个险。如果你在美国有认识学生的话就很好办了,直接叫其帮忙代买一下,这个似乎完全没有什么问题。而且如果是能够通过学校内的Apple Store进行购买的话,可能会更加便宜。

如果你是在Apple的零售店里面购买的话,则完全看你人品好不好,碰到个好的服务员的话就ok了…

Rails的file_column插件是一个简单但是功能比较完备的文件上传插件。这一插件已经有很长时间没有更新了(最后一次更新是在2005年),但是就其功能和兼容性来说,一般的使用似乎没有什么问题。其用法也相当简单,大致的看看网站上面的文档即可。但是如果要做一些自定义的工作的话,就需要直接看它的源代码了。代码量不多,包括测试代码也就10多个文件。

最容易碰到的自定义需求应该就是定制上传文件存储的位置了,默认是在public目录下根据不同的模型名称来建立目录,明显的,这很容易造成“污染”,导致public目录下面生成大量的子目录。在看了其源码之后,注释中说明是可以通过给file_column这一方法传入参数:root_path来覆盖默认值的。我将root_path设置到public目录的file子目录下,试了之后在开发模式下上传文件确实没有问题,但是进行functional testing的时候发现并不正确。我在模型中设置了对文件大小进行验证的validates_filesize_of。这一方法在测试运行时验证查找的路径是在public目录下查找,这明显是不正确的,也即,仅仅覆盖root_path参数虽然能够在开发模式下正常工作,但是functional testing有些不同,按照其注释中的说法以及源代码,进行单元测试时file_column会把RAILS_ROOT/test/tmp/file_column这一目录作为根目录,而不是RAILS_ROOT/public/。单元测试时应该在setup方法中调用setup_fixture_files,在teardown中调用teardown_fixture_files,这两个方法会把文件fixtures复制到RAILS_ROOT/test/tmp/file_column目录下测试,测试结束后就移除。但由于根目录被我们传入的参数root_path覆盖,导致测试时的代码无法通过。解决的办法有两个,一个是按照不同的运行h环境来设置根目录,代码如下: 

if RAILS_ENV != "test"
  file_column :image, {:root_path => File.join(RAILS_ROOT, "public", "files")}
end
if RAILS_ENV == "test"
  file_column :image, {
  :root_path => File.join(RAILS_ROOT, "test", "tmp", "file_column", "files")
  }
end

但是这样做也有一个缺点,那就是如果在测试模式下进行集成测试的话(如使用selenium进行测试),file_column又会到test/tmp/file_column下查找文件。这也是明显不正确的,会导致文件无法访问。另外一个做法,可以做到万无一失的–直接修改file_column这一插件的代码:-)

用Eclipse习惯了,切换到Visual Studio之后发现有很多不顺手的地方。Eclipse中有一个功能,使用Ctrl+Shift+R就能够快速根据文件名打开任意的文件资源。在IntelliJ IDEA中也有这一功能,Ctrl+Shift+N就可以搞定。但是Visual Studio中却没有,每每要到目录树中查找一个文件,十分耗时。

今天偶然间发现了可以利用Eclipse来“帮助”Visual Studio实现这一功能。做法十分简单,把Visual Studio中的项目导入到Eclipse中。比如这是一个C++的项目(VS中最经常遇到的),因此就需要经常打开*.cxx,*.cpp,*.h等类型的文件。在Eclipse中文件关联中将这些类型的文件设置为使用VS打开,这样就可以在Eclipse中使用Ctrl+Shift+R迅速定位文件,然后一按回车,文件就在VS中打开了:)

Debugging DFC实在是很痛苦的一件事情,因为DFC类库十分庞大,API的层次很深,很多层次都是非常薄的对下层的一个封装。如果是DFC的使用者,只要考虑其外部接口还比较容易,但是作为API的开发者来说的话,尤其是作为一个刚入门还不太了解其内部结构的新手来说,每次都要花费很多时间在debugger上,仅仅是为了看一下一次访问的整个层次结构是什么样的。于是利用前段空下来的时间,写了一个小工具(InvokeVis)来进行Java的Call Stack的一个可视化。

目前这个工具支持四种可视化的输出格式:

普通文本格式
很简单的格式,仅仅使用缩进来表示不同层次的调用。
GraphViz Dot格式
这一格式可以使用GraphViz中的dot工具来进行转换,可以输出为gif, jpg, png, post script等多种格式。
HTML格式
这是基于Yahoo的YUI的一个HTML格式,Call Stack被可视化的表示为一颗HTML树。
XML格式
这一格式可以使用SpringGraph来进行浏览,用户可以通过Flash来交互式的浏览Call Stack。目前的代码库中自带了一个定制的SpringGraph的flash,可以查看InvokeVis输出的XML格式。

最开始我考虑支持的最主要的格式其实是Dot格式,只希望能够输出为一般的图片就可以了。但是后来发现Dot格式输出的图片的可扩展性不是很好,尤其是对于DFC这种超级巨大的类库而言,一个简单的小程序就会输出几千个节点的图片(在用GraphViz Dot工具转化成jpg时甚至因为节点过多无法输出,只能转化成gif),要想看清图片的细节,只能局限与整个图片的很小一部分,仅仅是窥豹一斑。于是就考虑输出为HTML树这种可以动态变化的方式来进行浏览,扩展性确实得到了很大提高,基本不管多大的节点数都不会有什么扩展性问题。但是又觉得HTML树看起来的时候的可视化效果不如dot格式转化出的图片出色,最后转而想到flash格式的输出,应该来说最后得到的flash的效果还是不错的,但是有部分功能还需要进一步完善,尤其是对现在这一flash中输出的是无向图而不是有向图(方向表示方法调用的发向, caller method -> callee method)这一点很不满意,如果有时间的话会把这点先改进一下。
输出效果图:

Dot format, converted by GraphViz? into gif format:

HTML format:

XML format, visualzed with SpringGraph? flash:

EMC acquired lots of companies during these years. And one picture is worth thousands of words.

EMC Acquisition Visualization

And I got the inspiration from this article, a visualization about Microsoft’s evolution, to create such a timeline to visualize EMC’s evolution in the past 10 years.

SIMILE Timeline is used to visualize the data. After some searching, I found something similar(In China, you have to work around GWF to view this page), which incorprates Google, Microsoft, Yahoo’s acquisitions.

多核对java的影响

十一月 23, 2006

今天看到一篇文章, Multi-core may be bad for Java, 里面讲到:

The trend towards multicore is moving along at a fast pace. Architectures like Suns Niagara seem to be getting copied by the other CPU vendors. The architecture is basically lots of cores but low clock speed per core.

This is a problem for Java as:

  • Java likely has a longer path length than languages like C and clock speeds won’t help with this.
  • JavaEE promotes a simple threading model for applications
  • Garbage collection remains heavily dependant on clock speed for small pauses.

对与第三点,其实早有大牛Amdahl定律在前头.按照前文的评论中的数值,垃圾回收一般占CPU时间的5%.根据Amdahl定律,s = n/((b*n) + (1-b)),如果处理器的数目足够多(n>100),基本可以认为满足Amadahl定律的极限值,也即s = 1/b, 所以,大概估算的话, 100核的处理器大概可以提高Java平台20倍的性能(这里仅考虑gc是瓶颈). 不知道这个数值算达到了什么程度, 感觉还是比较高的吧.

参考文献:

  1. The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
  2. multi-core may be bad for java
  3. Amdahl定律@wikipedia

时间管理

十一月 4, 2006

上帝有一点对每个人都很公平–每个人每天都是24小时.时间每个人都有,但是还是有很多事情”没有”时间做.
我的wish list已经很长了:

  • 很认真的写论文,用latex
  • 把我想做的reader做好
  • 带领team做一个成功的项目
  • 旅游
  • 其他的一大堆

好像都没有时间做,是我的时间管理上出了什么问题,还是其他的原因?Google一下time management,有一堆的文章教授你如何进行时间管理的,原来也看过不少,但是很难执行,没有看到什么效果,最后一直忙于其他的琐事(当然,有的也不是,比如找工作),但是想做的事情确一直没有开始,真是要好好反省一下了.

Update:

让你的个人效率翻三倍

CJK-Lyx @ Ubuntu

十月 25, 2006

最近准备开始写论文了,正所谓”工欲善其事,必先利其器”,一个好的编辑器当然很重要(Word直接被排除在外:-p).早就听说了LaTex的大名,不过一直觉得学起来太困难没有下手,不过它有一个图形化的前端Lyx,原来稍微用过一阵,感觉很不错,唯一没有解决的问题就是中文的编辑问题,这两天终于决定把它给解决掉.

我的系统是Ubuntu Dapper 6.0.6,上面安装Latex和cjk-latex都是轻而易举的事情(sudo apt-get latex cjk-latex),但是后面的中文化工作连续折腾了我两天时间还是没有完全解决.主要有下面的几个困难:

  • 给LaTex添加中文字体,比如Windows下的simsun.ttf。添加字体的时候涉及到需要修改的文件夹和文件太多了,网上的一些文档又大多过时或者不符合Ubuntu系统上的实际,很难派上用场,自己琢磨试验了好久时间。
  • 在Ubuntu上编译并安装CJK-Lyx。这个工作也是很困难的,因为Ubuntu的软件库里面只有Lyx,但是没有CJK-Lyx,而且CJK-Lyx的binary distribution又没有debian系统上可用的,只有rpm,所以只好从源代码开始编译,结果configure,make,make install三部曲我就搞了一个下午时间,而且在自己的机器上死都找不到zlib库,明明有啊,只好到其他的机器上面(也是Ubuntu dapper)编译好了再拷贝过来。
  • CJK-Lyx的配置使用。这个问题也是很麻烦的,网上的资料就两三篇,绝大多数都是转贴,而且就那两三篇还是过时的,现在的1.4版也有出入。又是一阵琢磨。

直到现在这个CJK-Lyx还是有问题,编辑的每部分文字最后几个字虽然能够正常保存,但是在Lyx编辑器里面看不到,存在乱码问题。虽然可以用latex转换成其他格式再看,但是总是不是很很爽,还不如直接用LaTex呢。sigh,现在只能在Windows上面试着编译看看了,等问题解决了有时间我会把它整理出来,相关文档实在太少了。

参考文献:

  1. TeX和LaTeX中的字体
  2. TeX Font Guide
  3. 用LaTeX写漂亮学位论文

Update: Windows上的编译也失败了,懒得在Windows上再看一遍原因了,先考虑直接Vim+LaTex了。

Update2:有用的LaTex模板

  1. Tex/LaTex模板
  2. thuthesis@gforge

语义网技术用例

十月 7, 2006

什么时候能够恰如其分的应用语义网技术、什么时候应该应用语义网技术,这一直是个困扰我的问题。John Black给出了他的答案

In cases where the data needed to operate effectively is distributed widely, changes rapidly, and can not or must not be combined in any way that would allow it to be controlled, semantic web technologies are essential. In such circumstances, all of the data needed must be created and maintained by the separate parties involved. But the most valuable results will be obtained by combining it all together, in real time. Problems of this sort are what the semantic web vision addresses.

« 上一页下一页 »