Archive for 八月, 2007

It’s not a bug. It’s a …

Hey, I have to blog about this one. It’s so funny it’s classic!

What does a native tab control on Windows look like, anyway?

I came across an article on EclipseZone today that got me to really wonder what a native tab on Windows should look like.

The article takes the tab control of Eclipse for an example.

Eclipse’s editor and view tabs have a gradient-based rendering with the colors drawn from the system primary and secondary colors.

, whereas Eclipse’s tabs will always stand out a bit from the surrounding native widgets.

This actually is a good point. I myself find the curved un-anti-aliased zig-zag looking tabs very funny to look at. But is it actually anything related to non-native-ness?

Think about all the tabbed applications you have used on Windows. Firefox, Internet Explorer, MS Word, Live Messenger, Google Talk, UltraEdit, Notepad++, … God! I can’t even find two of them which have the same looking tab controls! Isn’t that so obvious that it’s funny?

So the only thing wrong with Eclipse tabs may be the geekish looks. People don’t complain about those glossy IE7 tabs anyway…

Eclipse RCP and desktop Java - are we there yet?

I’m currently working on an Eclipse RCP project, which is supposed to be mostly used by non-technical people. Actually in my company today, Eclipse RCP is the de facto technology for building all desktop applications - from developer workbench to everyday necessities. There are RCPs built for programmers, testers, and everyone else. It looks like Eclipse RCP is hitting its prime time. But, is it?

Eclipse RCP, since it was first introduced with Eclipse 3.0 back in 2004, has come a long way through 3 whole years of evolution. With RCP, the Eclipse technology is becoming ubiquitous, rather than merely a development environment. From a developer’s perspective, it’s really a great technology. It virtually saved Java in the desktop battle. It’s well architected, standardized, robust, incredibly powerful to be extended, and like all Java applications, it runs on most platforms.

But with the wider acceptance of RCP and developers going great lengths to exploit its extendability, its shortcomings are being more and more exposed. To name a few, performance and user experience.

To take an example, the next major release of Lotus Notes, release 8, is completely built with Eclipse RCP. Despite its fantastic features, beta testers are unanimously complaining about its sluggish performance and lack of stability. Notes 8 is just going GA today. It’ll be interesting to see how the first batch of end users say about the next generation monster RCP that’s supposed to be lived with on a daily basis.

Another example is Lotus Sametime 7.5. I’ve been using it for quite a while now. Though I love to write interesting plugins for it, I can’t deny that the 3 minute plus load time (on my previous old Thinkpad T41 laptop) I sit through every time I launch Sametime is nothing but like killing myself slowly. It’s a nightmare. Anyway, it’s a chat program, isn’t it?

Another big issue is the very existence of RCP applications on client desktops. First, to run an RCP, you need a JRE, of course. That’s 70 megs for Sun JRE 5.0. Then, various JRE quirks drive developers nuts and some larger RCPs come shipped with bundled JREs in the packages. That’s an extra tens of megs added to the package. Then that’s the RCP platform itself which is over 10 megs. So even without any useful code, the prerequisites account for more than 100 megs!

Today, Rational ships most of the super mega RCP products on earth. A complete Rational Software Architect bundle comes with more than a handful of DVDs. That’s even more than many of the super cool PC games today!

Imagine that you need to run a bunch of RCP desktops at the same time. Each one consumes several hundred megs of your precious memory. More than a few of them refuse to use your system JRE and stick with their own shipped instance. So you even have more than a few JREs running simultaneously. That’s not a happy future definitely.

So what’s wrong with today’s Eclipse RCP? What’s the cure? I’m thinking about a few.

First, great platforms can’t cook the dinner for you! It’s still the developers’ responsibility to control the RCP’s performance and usability! Take great efforts to cut down unnecessary weights. Pay extreme attention to avoid memory leaks. There’s no magic in it!

Second, the consumer JRE is really a late comer. But better late than never. Today the desktop RIA war has already begun. Consumer desktops are being invaded with a bunch of runtimes. JRE, one of the oldest runtimes, really needs to get itself lean to have a chance. Sorry, but 70 megs of installation is simply insane.

Third, great tools can be bad if you put it to the wrong use. Eclipse RCP can build anything. That’s right. But does it have to?

I’m kind of concerned with what the 2007 Eclipse Roadmap has put it for RCP. IMHO, it’s definitely not more functionality, or frameworks that RCP lacks today. There’s still lots of work to do to make RCP and Java desktop truly usable for everyone.

Downloading YouTube Videos with a Groovy one-liner, and convert it to mpeg4

Today I used LiveHTTPHeaders to take a closer look at how the youtube video streams are directed to the browser. And I found that my previous attempt actually has some redundency in it. To get the flv video stream, simply request the URL:

http://cache.googlevideo.com/get_video?video_id=${vid}

where vid is simply the v string in the original URL. e.g. http://www.youtube.com/watch?v=5C0I7Ef4gQI

So the simplified version is one line of code even shorter now.

def vid = (args[0] =~ (/(? new URL("http://cache.googlevideo.com/get_video?video_id=${vid}").openStream().eachByte{it -> os.write(it)}}

And now here’s a bonus. Grab ffmpeg and put the ffmpeg executable to your system path. Then add the following line to the Groovy script above, and the downloaded flv file will be converted to an mpeg4 format mpg file immediately. You can also play with many ffmpeg parameters to fine tune your convertion.

For Windows

Runtime.getRuntime().exec(['cmd', '/c', "ffmpeg -i ${vid}.flv ${vid}.mpg"] as String)

For Linux

Runtime.getRuntime().exec(['sh', '-c', "ffmpeg -i ${vid}.flv ${vid}.mpg"] as String)

准备搬新服务器了

2个礼拜没有更新了。

现在blog的服务器空间是和朋友一起办的另外一个网站autoers.org合用的,一年前在上海服务器合租网买的。说起来autoers.org已经换了好几个国内服务器空间了,也受够了国内服务器商的低劣质量和服务。最惨的一次,由于共享服务器上有其他未知的“非法网站”,流量还很大,服务器资源被大量占用导致我们的网站速度很慢而且不稳定。最后服务器整个被公安端走了,来不及备份的数据全部丢失。

所以这次决定搬到国外服务器了。最近调查了一下国外web hosting服务商的情况,在web hosting unleashed上对比了几家最热门的服务商,最后选定了hostgator,因为是100%好评的。月付每月9.95美元的baby方案,100G空间每月1T流量,在用了coupon以后,第一个月只要1美分。国内哪里找的到这么好的条件!其实用国外服务器的最大担心一个是IP被和谐,一个是速度比国内慢。但是目前试用下来这两点都不是问题。

不过买了hostgator后才看到讨论说,他们现在对中国用户审查的很严,这点在注册的时候已经体会到了;另外服务质量似乎也有下降趋势。lunarpages似乎是个不错的备选。对中国用户支持十分全面,访问速度也不比hostgator慢,Basic hosting方案350G空间每月3.5T流量,最低3月付每月9.95美元,还有coupon可以打72折。另外,media temple是个比较小众化的选择。很多名站酷站都是放在mt,比如我的rss必读techcrunch,所以服务质量应该是不错的。不过讲性价比的话肯定就不那么高了。

最后,希望搬到国外服务器以后IP坚持住不要被和谐掉吧。

用Launchy发消息到饭否

Launchy真是个用了舍不得放下的小东西,可以双手不离键盘的打开电脑上几乎任何东西。而且,hack一番的话你还可以让Launchy干更多更有趣的事情。

image

比如,今天尝试成功了用Launchy发消息到SHARETHIS.addEntry({ title: "用Launchy发消息到饭否", url: "http://damienh.org/2007/08/02/%e7%94%a8launchy%e5%8f%91%e6%b6%88%e6%81%af%e5%88%b0%e9%a5%ad%e5%90%a6/" });