Leopard发布的那段时间,看到最多的消息就是批评Leopard没有对Java 6的支持,但是没有想到它对Java 5的支持也倒退了一步.
在升级到Leopard之前,在Tiger上一直使用jVi + Netbeans 6 Beta 1,用着感觉非常爽,比Eclilpse下面那些vim的集成或者插件都感觉要好.但是在升级到Leopard之后,使用了Netbeans Beta 2,发现有一个最基本的功能失效了–用”:”切换到命令模式下无法使用回车键执行.开始还以为是jVi对Netbeans Beta2的支持有问题.等了一段时间,直到jVi和Netbeans 6都发布了新版本之后,发现用最新版本还是不行,这才到jVi的论坛上面去看,结果发现有其他人也遇到了相同的问题,是Leopard的Java 5问题导致的.还不知道有什么work around或者Apple什么时候才能完全支持Java 5,只能天天用Command+S来保存文件了,真是郁闷.
唯一值得欣慰的是Apple还没有把Java给完全抛弃,希望猜测是对的.
Update: 有人高兴有人愁。可惜我不喜欢all in one的一站式采购。
自己编的一个小故事:
话说有一家企业有些业务上的需求需要使用软件系统来解决,于是邀请了一家软件咨询公司来做咨询分析.这一咨询公司开展了一段时间的咨询活动之后,告诉这一企业:我也不清楚你们需要上什么样的系统才能满足你们的业务需求,不如这样吧,你们先上个SAP看看是不是可以解决问题.我估计可能不行解决,不过先试试看吧.当然咨询费用和实施费用还是要全额付清的.如果不行解决问题的话,你可以再来找我做一个咨询,我帮你再想办法.
真实的故事:
今天带女朋友去医院看病,医生看了半天,在病历上写了:发热,原因待查.开了点药,要打一针,然后说去吊盐水,顺便还补上一句:先试试看,我估计不管用.付了钱后打针加吊盐水,回来又吃了药,果然没用,到了晚上继续发烧到39度.
医生这行真是太赖了~
最近正在筹划如何比较合算的购买一台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.
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.
今天看到一篇文章, 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是瓶颈). 不知道这个数值算达到了什么程度, 感觉还是比较高的吧.
参考文献:
- The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
- multi-core may be bad for java
- Amdahl定律@wikipedia
上帝有一点对每个人都很公平–每个人每天都是24小时.时间每个人都有,但是还是有很多事情”没有”时间做.
我的wish list已经很长了:
- 很认真的写论文,用latex
- 把我想做的reader做好
- 带领team做一个成功的项目
- 旅游
- 其他的一大堆
好像都没有时间做,是我的时间管理上出了什么问题,还是其他的原因?Google一下time management,有一堆的文章教授你如何进行时间管理的,原来也看过不少,但是很难执行,没有看到什么效果,最后一直忙于其他的琐事(当然,有的也不是,比如找工作),但是想做的事情确一直没有开始,真是要好好反省一下了.
Update:
让你的个人效率翻三倍
订阅
阅读列表
