Support Wikipedia Follow My Heart: 十月 2011

2011年10月27日星期四

A Visual Guide to Version Control

I found a pretty well blog from Internet. So I copied it here.

Thanks to the original author of this post! Thanks! (Original URL : A Visual Guide to Version Control

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

A Visual Guide to Version Control

Version Control (aka Revision Control aka Source Control) lets you track your files over time. Why do you care? So when you mess up you can easily get back to a previous working version.

You’ve probably cooked up your own version control system without realizing it had such a geeky name. Got any files like this? (Not these exact ones I hope).

  • KalidAzadResumeOct2006.doc
  • KalidAzadResumeMar2007.doc
  • instacalc-logo3.png
  • instacalc-logo4.png
  • logo-old.png

It’s why we use “Save As”. You want the new file without obliterating the old one. It’s a common problem, and solutions are usually like this:

  • Make a single backup copy (Document.old.txt).
  • If we’re clever, we add a version number or date: Document_V1.txt, DocumentMarch2007.txt
  • We may even use a shared folder so other people can see and edit files without sending them over email. Hopefully they relabel the file after they save it.

So Why Do We Need A Version Control System (VCS)?

Our shared folder/naming system is fine for class projects or one-time papers. But software projects? Not a chance.

Do you think the Windows source code sits in a shared folder like “Windows2007-Latest-UPDATED!!”, for anyone to edit? That every programmer just works in a different subfolder? No way.

Large, fast-changing projects with many authors need a Version Control System (geekspeak for “file database”) to track changes and avoid general chaos. A good VCS does the following:

  • Backup and Restore. Files are saved as they are edited, and you can jump to any moment in time. Need that file as it was on Feb 23, 2007? No problem.
  • Synchronization. Lets people share files and stay up-to-date with the latest version.
  • Short-term undo. Monkeying with a file and messed it up? (That’s just like you, isn’t it?). Throw away your changes and go back to the “last known good” version in the database.
  • Long-term undo. Sometimes we mess up bad. Suppose you made a change a year ago, and it had a bug. Jump back to the old version, and see what change was made that day.
  • Track Changes. As files are updated, you can leave messages explaining why the change happened (stored in the VCS, not the file). This makes it easy to see how a file is evolving over time, and why.
  • Track Ownership. A VCS tags every change with the name of the person who made it. Helpful for blamestorming giving credit.
  • Sandboxing, or insurance against yourself. Making a big change? You can make temporary changes in an isolated area, test and work out the kinks before “checking in” your changes.
  • Branching and merging. A larger sandbox. You can branch a copy of your code into a separate area and modify it in isolation (tracking changes separately). Later, you canmerge your work back into the common area.

Shared folders are quick and simple, but can’t beat these features.

 

Learn the Lingo

Most version control systems involve the following concepts, though the labels may be different.

Basic Setup

  • Repository (repo): The database storing the files.
  • Server: The computer storing the repo.
  • Client: The computer connecting to the repo.
  • Working Set/Working Copy: Your local directory of files, where you make changes.
  • Trunk/Main: The primary location for code in the repo. Think of code as a family tree — the trunk is the main line.

Basic Actions

  • Add: Put a file into the repo for the first time, i.e. begin tracking it with Version Control.
  • Revision: What version a file is on (v1, v2, v3, etc.).
  • Head: The latest revision in the repo.
  • Check out: Download a file from the repo.
  • Check in: Upload a file to the repository (if it has changed). The file gets a new revision number, and people can “check out” the latest one.
  • Checkin Message: A short message describing what was changed.
  • Changelog/History: A list of changes made to a file since it was created.
  • Update/Sync: Synchronize your files with the latest from the repository. This lets you grab the latest revisions of all files.
  • Revert: Throw away your local changes and reload the latest version from the repository.

Advanced Actions

  • Branch: Create a separate copy of a file/folder for private use (bug fixing, testing, etc). Branch is both a verb (“branch the code”) and a noun (“Which branch is it in?”).
  • Diff/Change/Delta: Finding the differences between two files. Useful for seeing what changed between revisions.
  • Merge (or patch): Apply the changes from one file to another, to bring it up-to-date. For example, you can merge features from one branch into another. (At Microsoft this was called Reverse Integrate and Forward Integrate)
  • Conflict: When pending changes to a file contradict each other (both changes cannot be applied).
  • Resolve: Fixing the changes that contradict each other and checking in the correct version.
  • Locking: Taking control of a file so nobody else can edit it until you unlock it. Some version control systems use this to avoid conflicts.
  • Breaking the lock: Forcibly unlocking a file so you can edit it. It may be needed if someone locks a file and goes on vacation (or “calls in sick” the day Halo 3 comes out).
  • Check out for edit: Checking out an “editable” version of a file. Some VCSes have editable files by default, others require an explicit command.

And a typical scenario goes like this:

Alice adds a file (list.txt) to the repository. She checks it out, makes a change (puts “milk” on the list), and checks it back in with a checkin message (“Added required item.”). The next morning, Bob updates his local working set and sees the latest revision oflist.txt, which contains “milk”. He can browse the changelog or diff to see that Alice put “milk” the day before.

Visual Examples

This guide is purposefully high-level: most tutorials throw a bunch of text commands at you. Let’s cover the high-level concepts without getting stuck in the syntax (the Subversion manual is always there, don’t worry). Sometimes it’s nice to see what’s possible.

Checkins

The simplest scenario is checking in a file (list.txt) and modifying it over time.

version control checkin

Each time we check in a new version, we get a new revision (r1, r2, r3, etc.). In Subversion you’d do:

svn add list.txt
(modify the file)
svn ci list.txt -m "Changed the list"


The -m flag is the message to use for this checkin.

Checkouts and Editing


In reality, you might not keep checking in a file. You may have to check out, edit and check in. The cycle looks like this:

version control checkout

If you don’t like your changes and want to start over, you can revert to the previous version and start again (or stop). When checking out, you get the latest revision by default. If you want, you can specify a particular revision. In Subversion, run:


svn co list.txt (get latest version)
...edit file...
svn revert list.txt (throw away changes)

svn co -r2 list.txt (check out particular version)


Diffs


The trunk has a history of changes as a file evolves. Diffs are the changes you made while editing: imagine you can “peel” them off and apply them to a file:

version control diff

For example, to go from r1 to r2, we add eggs (+Eggs). Imagine peeling off that red sticker and placing it on r1, to get r2.

And to get from r2 to r3, we add Juice (+Juice). To get from r3 to r4, we remove Juice and add Soup (-Juice, +Soup).

Most version control systems store diffs rather than full copies of the file. This saves disk space: 4 revisions of a file doesn’t mean we have 4 copies; we have 1 copy and 4 small diffs. Pretty nifty, eh? In SVN, we diff two revisions of a file like this:

svn diff -r3:4 list.txt

Diffs help us notice changes (“How did you fix that bug again?”) and even apply them from one branch to another.

Bonus question: what’s the diff from r1 to r4?

+Eggs
+Soup


Notice how “Juice” wasn’t even involved — the direct jump from r1 to r4 doesn’t need that change, since Juice was overridden by Soup.

Branching


Branches let us copy code into a separate folder so we can monkey with it separately:

version control branch

For example, we can create a branch for new, experimental ideas for our list: crazy things like Rice or Eggo waffles. Depending on the version control system, creating a branch (copy) may change the revision number.

Now that we have a branch, we can change our code and work out the kinks. (“Hrm… waffles? I don’t know what the boss will think. Rice is a safe bet.”). Since we’re in a separate branch, we can make changes and test in isolation, knowing our changes won’t hurt anyone. And our branch history is under version control.

In Subversion, you create a branch simply by copying a directory to another.

svn copy http://path/to/trunk http://path/to/branch

So branching isn’t too tough of a concept: Pretend you copied your code into a different directory. You’ve probably branched your code in school projects, making sure you have a “fail safe” version you can return to if things blow up.

Merging


Branching sounds simple, right? Well, it’s not — figuring out how to merge changes from one branch to another can be tricky.

Let’s say we want to get the “Rice” feature from our experimental branch into the mainline. How would we do this? Diff r6 and r7 and apply that to the main line?

Wrongo. We only want to apply the changes that happened in the branch!. That means we diff r5 and r6, and apply that to the main trunk:

version control merge

If we diffed r6 and r7, we would lose the “Bread” feature that was in main. This is a subtle point — imagine “peeling off” the changes from the experimental branch (+Rice) and adding that to main. Main may have had other changes, which is ok — we just want to insert the Rice feature.

In Subversion, merging is very close to diffing. Inside the main trunk, run the command:

svn merge -r5:6 http://path/to/branch

This command diffs r5-r6 in the experimental branch and applies it to the current location. Unfortunately, Subversion doesn’t have an easy way to keep track of what merges have been applied, so if you’re not careful you may apply the same changes twice. It’s a planned feature, but the current advice is to keep a changelog message reminding you that you’ve already merged r5-r6 into main.

Conflicts


Many times, the VCS can automatically merge changes to different parts of a file. Conflictscan arise when changes appear that don’t gel: Joe wants to remove eggs and replace it with cheese (-eggs, +cheese), and Sue wants to replace eggs with a hot dog (-eggs, +hot dog).

version control conflict

At this point it’s a race: if Joe checks in first, that’s the change that goes through (and Sue can’t make her change).

When changes overlap and contradict like this, the VCS may report a conflict and not let you check in — it’s up to you to check in a newer version that resolves this dilemma. A few approaches:


  • Re-apply your changes. Sync to the the latest version (r4) and re-apply your changes to this file: Add hot dog to the list that already has cheese.
  • Override their changes with yours. Check out the latest version (r4), copy over your version, and check your version in. In effect, this removes cheese and replaces it with hot dog.

Conflicts are infrequent but can be a pain. Usually I update to the latest and re-apply my changes.

Tagging


Who would have thought a version control system would be Web 2.0 compliant? Many systems let you tag (label) any revision for easy reference. This way you can refer to “Release 1.0″ instead of a particular build number:

version control tag

In Subversion, tags are just branches that you agree not to edit; they are around for posterity, so you can see exactly what your version 1.0 release contained. Hence they end in a stub — there’s nowhere to go.

(in trunk)
svn copy http://path/to/revision http://path/to/tag


Real-life example: Managing Windows Source Code


We guessed that Windows was managed out of a shared folder, but it’s not the case. Sohow’s it done?


  • There’s a main line with stable builds of Windows.
  • Each group (Networking, User Interface, Media Player, etc.) has its own branch to develop new features. These are under development and less stable than main.

You develop new features in your branch and “Reverse Integrate (RI)” to get them into Main. Later, you “Forward Integrate” and to get the latest changes from Main into your branch:

version control branch example

Let’s say we’re at Media Player 10 and IE 6. The Media Player team makes version 11 in their own branch. When it’s ready and tested, there’s a patch from 10 – 11 which is applied to Main (just like the “Rice” example, but a tad more complicated). This a reverse integration, from the branch to the trunk. The IE team can do the same thing.

Later, the Media Player team can pick up the latest code from other teams, like IE. In this case, Media Player forward integrates and gets the latest patches from main into their branch. This is like pulling in the “Bread” feature into the experimental branch, but again, more complicated.

So it’s RI and FI. Aye aye. This arrangement lets changes percolate throughout the branches, while keeping new code out of the main line. Cool, eh?

In reality, there’s many layers of branches and sub-branches, along with quality metrics that determine when you get to RI. But you get the idea: branches help manage complexity. Now you know the basics of how one of the largest software projects is organized.

Key Takeaways


My goal was to share high-level thoughts about version control systems. Here are the basics:


  • Use version control. Seriously, it’s a good thing, even if you’re not writing an OS. It’s worth it for backups alone.
  • Take it slow. I’m only now looking into branching and merging for my projects. Just get a handle on using version control and go from there. If you’re a small project, branching/merging may not be an issue. Large projects often have experienced maintainers who keep track of the branches and patches.
  • Keep Learning. There’s plenty of guides for SVN, CVS, RCS, Git, Perforce or whatever system you’re using. The important thing is to know the concepts and realize every system has its own lingo and philosophy. Eric Sink has a detailed version control guidealso.

These are the basics — as time goes on I’ll share specific lessons I’ve learned from my projects. Now that you’ve figured out a regular VCS, try an illustrated guide to distributed version control.

2011年10月20日星期四

Why ANT terminates in Eclipse

It is very convenient to use ANT to compile our projects in Eclipse.
Also Eclipse has already integrated ANT, so users do not need to install ANT independently.

But sometimes, ANT will surprisingly terminates during Compiling process.

The reason is that ANT use UTF-8 as default encoding pattern.
But Java JDK/JRE will print out Locale Error and Warning Message during COMPILING process.

So sometimes, Eclipse integrated ANT cannot deal with the error/warning feedback correctly. The underground program throws "Runtime Exception", which lead ANT be unexpectedly Terminated.

There are two simple solutions.

  1. use CMD rather than Eclipse (ANT Plugin) to run ANT. Download independent ant, deploy it in your local environment, finish path configuration and then run it through command line mode. Now you can see what error/warning message happened.
  2. Add parameters when you run ANT in Eclipse.  I forget the specific name of parameter. I remember that it redirects all error and warning message to normal system.out. Now you can also see the error message, though not in RED format.

2011年10月18日星期二

How to Use RSS in BlogSpot.com

In the bottom of the page, you will see the “订阅: 帖子 (Atom)”  hint. Click it!
Or you can use the following url : RSS Default Address

Read and Write XML in JDK1.4 with org.w3c.Dom

well, I admitted that org.w3c.dom (or DOM) is quite difficult to use than the popular dom4j (see here).

But sometimes, it might be problem for us to include new libraries in source code due to library confliction or license issues. For example, a big project is developed by various people independently. If all people use different libraries to parse xml, your product will finally turned out to be very complex to maintain.

So sometimes using the standard package in JDK (like JAXP) is the only choice, though difficult.

Here I demo some examples on how to use it for common purpose.

XMLIOUtility

With above code, it becomes easier for you to manipulate XML files.

Here is something important.
Usually, the output format of XML file by DOM is very ugly, with does not change lines or insert indent automatically. So you need to pay attention to the following lines in the method which print out xml files.

XMLIOUtility

 

OK, I will also paste an example.

XMLResourceBundle class is convinient. But it is only supported by at least JDK1.5.  Now I implemented a XMLResourceBundle class by JDK1.4 using DOM.

XMLResourceBundle

.The Class HintUtility did nothing but invoking System.out.println() to print messages.


 

2011年10月15日星期六

日本筑波宇航中心一日游

昨天是2011年10月15日,一年一度日本宇航研究中心的对外开放日。该中心位于茨城县つくば市,按照势力范围,应该属于筑波大学城的一部分。

虽然天公不作美,淅淅沥沥雨不停,但是怀着对宇宙的好奇与梦想,我们一家早上7点钟就爬起来,赶接近两个小时的地铁,在10点开门前就赶到了宇航中心。

这地方占地面积很小,建筑物看起来也很普通,门口有两个慈眉善目的老爷爷在指挥进出的车辆,并没有荷枪实弹的警察和军人,没有醒目的标语和口号,房子大多建得四四方方一个样,花园也没啥特色,乍一看怕是还不如浙江的民间工厂气派,更别提中国声明赫赫的几大“航天城”了。没办法,估计是资源贫乏吧,呵呵。

一进门就看见了这个真实的火箭。这不是模型,是真的火箭,发动机啥的都是真家伙。

IMG_4503

 

参观展览馆

我们首先去的是展览馆,这里陈列着各类航天器的实物和模型。而且都配着非常详细的解释。今天是开放日,还有工作人员义务讲解。我在这里的感觉就是极大地开阔了视野。能够如此近距离地接触这些满载人类飞天幻想的器物,并且了解到原来它们的结构和原理其实并不复杂,真是太幸运了。

IMG_4455

一进门有一个硕大的地球模型。上面立着一些卫星的航天器的小模型。生动地告诉你这些东西都在什么地方,以及他们的样子,轨道高度,和大概的数量。非常生动。

IMG_4457

这是目前正在使用中的,美,日,欧共同开发维护的太空站微缩模型,背后还有一个一比一的大家伙。讲解员很自豪地告诉我们,其中哪里哪里是在这里开发的,目前日本,美国,和欧洲每天分别管理这个太空站8个小时。日本的控制中心就在这里。

 

IMG_4464

这个是安装有排泄物处理系统的宇航员太空行走服。哈哈哈。

 

IMG_4459

大厅里陈列着各式各样的卫星实物和模型。有气象卫星,资源探测卫星,通信中继卫星,暗物质搜索卫星,甚至情报搜集卫星,等等。有的有两层楼那么高,像个巨大的长天线的包装箱,有的又圆圆的像个大垃圾筒,有个小巧玲珑,像电视机的盒子,有的黑乎乎的,里面是什么啥都看不见……

IMG_4497

 

最让我感慨的是这个巨大的一比一真实空间站模型。其实也算是半实物。因为和天上那个是作为备份一起生产的,只不过没有用上,所以一些贵重的设备就拆掉换成模型了。

先看看全貌是什么样子的。

IMG_4468

IMG_4489

(巨大的机械手)

IMG_4476

(进主舱内参观)

IMG_4480

(真实的舱内控制台和实验台,我居然在机械臂控制器旁边发现放了一台Thinkpad的电脑,哈哈,哈哈哈。)

IMG_4479

IMG_4474

(这个模型演示平时航天员的生活和工作场所及方式)

IMG_4475

(这个模型很欢乐,寓意五国共同开展空间站事业)

IMG_4493

此外,这里还展示了日本独立研发的载人航天器——希望号航天飞船的一比一模型。只不过外表实在太丑,跟神舟号一样,像个巨大的垃圾桶。

还有小的比例模型。

 IMG_4491

以及陈列在一排的日本产火箭模型。

IMG_4481

 

这里比较让我惊叹的,是真实的液体燃料火箭发动机。旁边还有原理说明图。再加上讲解员的说明,一下就明白了液体燃料喷射发动机的原理。

IMG_4496

IMG_4495

 

日本正在积极地开展探月活动,所以这里展示了完整的月球3D模型,和绕月探测器传回来的画面。

IMG_4484

IMG_4499

 

参观火箭及航天控制中心

这里据说涉及到机密数据,所以不然带相机进去。

房子里有两个控制室,都是玻璃墙,里面的情况看得很清楚。其中一个是空间站的控制室,里面的大屏幕上显示着空间站的摄像头目前观测到的景象。控制室里摆放着很多工作台,按照职责的不同分成好几个区。零散有几个人,正围着显示器在讨论着什么。房间不大,估计NASA和欧洲航天局那边也差不多。

里面的控制室稍微大一点,这里是日本自主研发的“神舟号”的控制室,感觉和外面那个没有太大区别,有几张桌子上还放着布娃娃玩偶。

因为我不是学这个的,也看不出什么名堂,就觉得有点拥挤,电脑显示器太多了点。另外,墙上没什么标语和口号,工作人员貌似都很休闲。和CCTV上看到的中国航天城控制室的紧张繁忙,“严肃认真”的感觉完全不一样。

这里很小,除了两间控制室就没别的东西了。

 

参观宇航技术研究开发中心和宇航设备测试中心

这里比较有意思,展出各类宇航用的机器人,探测器,光学电学设备,新材料新工艺等等。

IMG_4504

这是个电动模型,台子上有一排按钮,分别表示空间站可以执行的各类动作,比如开舱门太空行走,搬运货物,回收卫星,释放卫星等等。

你按下相应的按钮,里面的模型就开始活动,展示给你看到底是怎么完成的。

IMG_4507

很多宇航设备都是用液氮来冷却的。这是用液氮冰冻的棉花糖。我刚一咬,就“啪”一下四分五裂了,一口没吃到,郁闷。

IMG_4506

这个也是电动模型。航天器出厂之前要做各类抗震和抗噪声测试。这个模型演示如何进行测试。简单来说,就是把(比如)卫星绑在一个振动台上,不停地上下左右前后地使劲晃荡,看它坏不坏。还要关到一个类似保险箱的地方,用超强的噪声去考验它,看里面的实验器材和电子设备会不会有问题。

还有这个是用在航天器上的万向反射镜头。无论测距激光从哪个角度射过来,都能按原路被折射回去。我不记得本科的时候学没学过这东西,但是看见实物就放在眼前,还是由衷感叹日本光学造诣很深。

IMG_4536

(看见我的佳能Kiss5的镜头了吗?)

IMG_4535

还有这个吓人的东西,把人绑上去转圈……以前一直听说这是挑选平衡感优秀的飞行员用的。结果这里的负责人很认真的告诉我,这东西只不过是用来甄选身体有缺陷的候选人的。所有进入过太空的航天员,80%的人平衡感都一般般。最后谁能上天,跟在这椅子上的表现没关系。

 

插曲:遇见学术大牛

IMG_4509

这里演示的是在外太空中机器人是如何前进的,因为大家都飘着,不能“走路”,机器人又没有灵活的手脚,所以现在都是像蜘蛛人一样,靠绳索前进。

负责介绍的老先生非常亲切,而且看我们说英文,就用英语给我们做了非常详细介绍,发音标准,口音地道美国腔,非常厉害。后来我们在实验室外面的展板上看见,这位老先生名叫Oda Mitsushige,是日本宇航中心(JAXA)的宇宙机器人开发部负责人,刚刚参加了2011年9月在美国长滩举行的AIAA(美国航空航天学会,参见美国航空航天协会介绍)年会,获颁AIAA宇航自动化及机器人奖章,以表彰其在该领域所作出的卓越研究贡献(参见AIAA年会通信)。

啊呀呀呀,牛人啊牛人啊。只是通行的日本友人都出来了,我就不好意思再排队进去重新握手拍照签名留念。好在刚刚不知情的情况下随手拍了一张。

IMG_4508

这个级别的牛人,在国内的话应该算得上是比较牛的院士级别了,行政级别应该至少是航天某院院长级别的人了,还亲自参加旨在大众科普的开放日活动,并且这么慈眉善目地给我们这些航天小白进行细致认真的双语讲解。难得啊难得啊。

这种机会在国内上哪里找去?

发发牢骚:载人航天的大科学家王永志和袁家军同志,我,一介草民,想免费参观真实的神舟系列飞船,并且希望您能亲自给我讲解一下里面的原理和构造,答疑解惑,不知道您有没有时间和这个心情?哪怕两年一次也行,我自己出交通费……

 

 

临走以前经过JAXA主楼大厅,一大堆小朋友在工作人员的指导下拼装火箭和卫星的模型。

IMG_4537

工作人员问我们有没有兴趣参与载人航天,探索宇宙。我高举双臂,不过同行的日本小孩却表示没兴趣。工作人员让大家把理由写下来贴在宇航中心的迎宾墙上。我写下了“For curiosity and my dream, I want to visit the universe. (出于好奇心和梦想,我希望访问宇宙)”。同行的日本小孩写下了拒绝的理由“スベースシャット爆発かもしれない(太空飞船可能会爆炸)”

我很无语……

 

结束

从这里离开以后,我一直在感慨,日本这片土地上不缺乏高科技,而且作为普通的民众居然有如此之多之好的机会来接触,学习,亲身体验和实践。只要未来的日本小孩想学,愿意去学,他们取得进步将是非常容易的事情。

而我从小就想接触飞机火箭啥的,却活了26年,才有机会真正了解空间站是怎么工作的,火箭发动机是怎么工作的,太空机器人是怎么运动的。唉……

中国也有高技术,我们有更壮观宏伟气魄的科研基地和硬件设备,可是国民怎么就没有近距离接触它们的机会呢?

我们的高科技研究所为什么基本没有面对普通民众的开放活动?为什么经常让全副武装凶神恶煞的警卫守门?是要将民众拒之千里吗?普通路人连进去上卫生间都不被允许,哪里还有胆量去“窥测国家机密”?还有我们的教授们,什么时候也能够越牛的人越没有架子呢?什么时候也会觉得,将自己工作最精华的部分讲给完全不认识,嘴里还啃着棉花糖的科技小白听也是非常重要的事情呢?

唉,到底是谁缺乏资源?

我虽然还没有踏上过美国和西欧的土地,但是我感觉,这些发达社会政府对于科技和民众教育的态度应该跟日本没区别。

回家前,我对日本同事说“JAXA的研究人员科普工作做的真好!但这样的活动不影响他们自己的工作吗?”,结果日本同事很淡定地回答“是我们在交税,他们的研究和收入都源自国家的税收。他们有义务这么做。”

我再次无语……

How to get the file path of current/target class in JAVA?

Sometimes, we need to get the absolute path of some class, i.e. "D:\TestProject\bin\org\apache\....."

I recommend to use the ClassLoader.getResource() method. Because this method can also fetch back the file path even within the jar package.
Now let me show you a simple demo.
Assuming that we have the following folder in Disk D:
D:\ TestProject
        |----->   src
        |----->   bin
                      |  ------> testcase
                                         |--------> TestCase1.class
                                         |--------> TestCase2.class
                                         |--------> subfolder
                                                             |---------> TestCase3.class
so ,  actually the paths of these testcases are as follows:
Class Name Absolute Path
TestCase1.class D:\TestProject\bin\testcase\TestCase1.class
TestCase2.class D:\TestProject\bin\testcase\TestCase2.class
TestCase3.class D:\TestProject\bin\testcase\subfolder\TestCase3.class
Now, assuming that we are inside TestCase2,  so by following codes, we can get all these paths.
Reference Code

2011年10月14日星期五

How to solve Date Issues in Java

Java already provides powerful functions in dealing with Date (also Time) problems.
So you can input a String (i.e. “2001.07.04 AD at 12:08:56 PDT”), and get the Date Object by Java Methods.
In contrast, you can also provide a Date Object (or long number, etc.), and print the date as required date format easily.

What you need to done is just define the format String, i.e. “yyyy-mm-dd HH:mm:ss”. 
(Pay attention to the capticals, because they mean different format).
Here is a simple demostration.
Reference Code
The Output Result is :
test1:  Long Number is 1318252354000
test2:  Formatted Date String is 2011-10-10 22:12:34
test3:  Long Number is 481822496000
test4:  Formatted Date String is AM 12:34:56 04/09/85 JST



From Javadoc of JDK, we can easily learn how to write the format String.
Be careful on how to control the length of the items: i.e. the “yy” means here display the year, and two digits will be displayed.
Also, the “/” or “-” (or others) which are not defined in the table, will mean the separator.



sshot-33

2011年10月10日星期一

Eclipse HotKeys

Ctrl + Shift + F :   quickly format the source code
Ctrl + Shift + O :   quickly organize the import sections.
Ctrl + '/'          :   quickly note/de-node the source code
Ctrl + E           :   open source file

Ctrl + Alt+ 'up' : copy current line and insert it into current position
Ctrl + Alt + 'down' : copy current line and insert it into next line.
Ctrl + D  :  delete current line

Ctrl + 'Z'    :  undo the latest operation
Ctrl + 'Y'    :  repeat the canceled operation

Ctrl + Alt + '/'  :  in xml editor, quickly note the SELECTED lines
Ctrl + Alt+ '\'  :  in xml editor, quickly de-note the SELECTED lines



2011年10月6日星期四

Why java hang when invoking WMIC command

Today I want to invoke WMIC command from java program (through Runtim

e.getRuntime().exec(.....)).


I use the following code, but unfortunately, my java appears to "deadlock".
public void testWMIC(){
	final String command = "cmd /c wmic.exe Process get processid /format:csv";
	ProcessExecutor executor = new ProcessExecutor(command, ProcessExecutor.class);
	executor.start();
	executor.waitFor(500);
}

I search many web sites, read the instructions about how to use Runtime.exec() in Java, but there was no hint for this issue.

Finally, I found a website, which said that sometimes the program invoked by command does NOT "Stop".

Although I feel it is ridiculous, I tried the following command. This time everything works OK.

final String command = "cmd /c wmic.exe Process get processid /format:csv <NUL";



Reference Code 1

Reference Code


Reference Code 2

Reference Code