Code for Concinnity

Archlinux — pure awesomeness (+ how to change Linux console font)

kizzx2 — Fri, 16 Jul 2010 18:57:01 +0000

Today I checked out Arch Linux. It’s just that cool. It’s a minimalistic distro that focuses on, well, minimalism, simplicity and elegance.

What’s more of a pleasant surprise is that I find the Arch Linux Wiki to be probably the most comprehensive and high quality resources of Linux in general available on the net. Among those gems, I’ve found the way to change the font at the console. I’ve been using nix environments for a couple of years and this is the question that has always bugged me but nobody seemed to have talked about. There you go, several years of research

Setting up Arch Linux was a pleasant learning experience from itself. The package manager pacman offers the same level of convenience as the famous apt, if not more. The nice thing about it is that Arch’s packages seem to be much more recent than those ancient rugs on Debian and Ubuntu.

At the same time, Arch doesn’t bog you down with lots of unnecessary stuffs. Right out of the box, Arch almost doesn’t have any packages, and you have to edit a couple of config files just to be able to download things from the repos. But it was a pleasant learning experience, largely attributable to the excellent wiki.

If you want to improve your nix-fu or just want plain, beautiful distro to play with, give Arch a try!

Restoring elegance to CakePHP — doing multiple joins The Right Way™

kizzx2 — Thu, 08 Jul 2010 12:30:40 +0000

In my last article about unit testing, I mentioned one way to do ad-hoc multiple joins in CakePHP rather succinctly. Here’s a recap:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

function tagged($tag)
{
$this->bindModel(array('hasOne'=>array(
'PostsTag'=>array(
'foreignKey'=>false,
'conditions'=>"PostsTag.post_id = Post.id"
),

'Tag'=>array(
'foreignKey'=>false,
'conditions'=>"PostsTag.tag_id = Tag.id"
)
)));

return $this->find('all', array('conditions'=>array(
'Tag.name'=>$tag)));
}

This is, of course, rather unintuitive. A hasOne relationship when in fact I’m trying to look for someone hasAndBelongsToMany? I thought more about it.

There is a Bakery article that talked about doing ad-hoc joins. It looks more technically correct but just too freaking much verbose for my liking:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

$markers = $this->Marker->find('all', array('joins' => array(
array(
'table' => 'markers_tags',
'alias' => 'MarkersTag',
'type' => 'inner',
'foreignKey' => false,
'conditions'=> array('MarkersTag.marker_id = Marker.id')
),
array(
'table' => 'tags',
'alias' => 'Tag',
'type' => 'inner',
'foreignKey' => false,
'conditions'=> array(
'Tag.id = MarkersTag.tag_id',
'Tag.tag' => explode(' ', $this->params['url']['q'])
)
)
)));
?>

Actually, a simple refactoring can make it (almost) syntactically sweet and technically more correct:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

// /app/vendors/joins.php

/**
* A new helper class to produce those join arrays just to make
* life less miserable
*/
class Joins
{
public static function left($model, $conditions)
{
return self::_makeJoin($model, $conditions, 'left');
}

public static function inner($model, $conditions)
{
return self::_makeJoin($model, $conditions, 'inner');
}

private static function _makeJoin($model, $conditions, $type)
{
return array(
'table'=>Inflector::tableize($model),
'alias'=>$model,
'type'=>$type,
'foreignKey'=>false,
'conditions'=>$conditions
);
}
}

// /app/app_model.php

App::import('Vendor', 'joins');

class AppModel extends Model
{
// ...
}

// /app/models/post.php

function tagged($tag)
{
/*
* Let's make use of our new class, this has become
* a "one-liner."
*/
return $this->find('all', array(
'conditions'=>array('Tag.name'=>$tag),
'joins'=>array(
Joins::inner('PostsTag', 'PostsTag.post_id = Post.id'),
Joins::inner('Tag', "PostsTag.tag_id = Tag.id")
)
));
}

Unit testing in CakePHP — the missing manual and a step-by-step tutorial

kizzx2 — Wed, 07 Jul 2010 16:53:40 +0000

Today I’ve finally formalized a streamlined procedure to do unit testing properly in CakePHP — without all the pain. Needless to say, The Cookbook’s chapter on this issue cover the basic grounds but is inconsistent and lack a real life feeling to it.

The Cookbook’s coverage is really basic and doesn’t hold up to more real life complicated cases. Cake seems to be particularly picky about its automagical (too clever for me to figure out for a long time) configurations and bark errors at me very often. That led to reluctance to write tests and sometimes giving it up all together :p

The steps I’ve written here should lay down a very solid framework to make you bullet proof for all your future testing needs.

(Of course, this might be coming a bit late since most people would be better off looking at Cake’s successor Lithium, anyway here we goes.)

Can’t gather up much time to make a polished article but I believe this point-form brain dump is much more effective than most documentation out there.

Testing models

First, some notes

Testing models is the most important thing. Of course, a proper MVC application should have fat models and thin controllers.
For the most part, you really should use fixtures even if you do not use fixtures to load data. If you just use the database live, chances are Cake might mess up your data and errors might pop up, just go ahead and use fixtures. Yes, you don’t need to load data with your fixtures if you don’t want, but you need to turn this feature on. Yes, this was the thing that confused me a lot.
CakePHP uses SimpleTest, you would think that you’d put your setup and teardown code in setUp() and tearDown() just like everybody else? Wrong. Cake has already invaded those spaces. You’ll need to use startTest() and endTest(). This was documented in the Cookbook but this took me quite some time to figure out since I took it for granted and didn’t RTFM.
I may cover controller testing later but IMO controller testing in Cake is mostly broken and is quite straight forward to figure out.

Testing models — the tutorial

First we’ll set up the database, install SimpleTest etc. If you don’t know how to do this step you should read the Real Manual first.

Set up our testing application database in (My)SQL.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

-- We have the title field called "name" instead of "title"
-- IMO this is idiomatic Cake because your post's title
-- will now automatically show up in Post::find('list')
CREATE TABLE `posts`
(
`id` INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
`name` VARCHAR(50) NOT NULL,
`body` TEXT
);

-- You may think that the "name" field should be primary key.
-- Wrong! Doing so will make Cake unhappy if you ever use
-- Cake's console schema or the all other Cake migration
-- plugins out there. The id field is the Creed.
CREATE TABLE `tags`
(
`id` INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
`name` VARCHAR(50) NOT NULL UNIQUE
);

-- The id field is the Creed, even for join tables
CREATE TABLE `posts_tags`
(
`id` INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT,
`post_id` INT UNSIGNED NOT NULL,
`tag_id` INT UNSIGNED NOT NULL,
UNIQUE KEY(post_id, tag_id)
);

Bake our stuffs. Bake has come a long way since the earlier versions and the bake in Cake 1.3 is genuinely useful:

1 2	$ cake bake all Post $ cake bake all Tag

Now go create some test data:

1
2
3

INSERT INTO `posts` (`id`, `name`) VALUES (1, "Lorem"), (2, "Ipsum"), (3, "Dolor"), (4, "Sit");
INSERT INTO `tags` (`id`, `name`) VALUES (1, "apple"), (2, "orange");
INSERT INTO `posts_tags` (`post_id`, `tag_id`) VALUES (1, 1), (1, 2), (2, 1), (3, 2);

Now open /app/models/post.php and /app/models/tag.php. Both look OK! And Cake has gone ahead and created the test cases for us at /app/tests/cases/model. Let’s try to run it

1 2	$ cake testsuite app all Error: Missing database table 'test_suite_posts_tags' for model 'PostsTag'

This is how broken it is! Now let’s fix it. The thing is that we haven’t baked the fixture for the join table class PostsTag. Of course, we don’t want to have to create controller, models, views just for a simple join class. Luckily we can amend it by creating all missing fixtures:

1	$ cake bake fixture all -records -count 999

This will create all the missing fixtures. The -records -count 999 part tells Cake to pull real data from our database as fixture. The -count part is needed because it defaults to 10. Might as well enter some very large number but YMMV. This will also update our existing fixtures for Post and Tag so that the new fixture data we’ve added to the database will be reflected in the fixtures. Let’s try to run the tests again:

1
2
3

$ cake testsuite app all
...
4/4 test cases complete.

Finally, we’ve got the testing architecture down. To honor TDD, let’s create (edit) our test file before we do some development. Now go to /app/tests/cases/models/post.test.php, you’ll see this line:

1	var $fixtures = array('app.tag', 'app.post', 'app.posts_tag');

This is unfortunate, because it means every time you add a new association to your model, you’ll have to manually edit this $fixtures array. Too bad there isn’t an automated way to do this. (Running bake test will overwrite your whole file. You’ve been warned!)

Anyway, let’s just write some tests for kicks in /app/tests/cases/model/post.test.php:

1
2
3
4
5
6
7
8

function testSanity()
{
$this->assertTrue(1 == 1);

// Our fixtures should be loaded with data
$posts = $this->Post->find('all');
$this->assertTrue(!empty($posts));
}

Run it, all is good:

1
2
3

$ cake testsuite app all
...
4/4 test cases complete: 2 passes.

To honor TDD, we’ll write our test first before we do any implementation. Let’s add our test function. We’re going to write a model function that will find all posts for a given tag:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

function testTagged()
{
// These are based on our testing fixture data above
$posts = $this->Post->tagged('apple');
$this->assertTrue(!empty($posts));
$this->assertTrue(Set::matches('/Post[name=Lorem]', $posts));
$this->assertTrue(Set::matches('/Post[name=Ipsum]', $posts));
$this->assertFalse(Set::matches('/Post[name=Dolor]', $posts));

$posts = $this->Post->tagged('orange');
$this->assertTrue(!empty($posts));
$this->assertTrue(Set::matches('/Post[name=Lorem]', $posts));
$this->assertTrue(Set::matches('/Post[name=Dolor]', $posts));
$this->assertFalse(Set::matches('/Post[name=Ipsum]', $posts));
}

Run the test and watch it fail:

1 2	$ cake testsuite app all ...

Do our implementation in /app/models/post.php

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

/*
* If this line seems alien to you, don't worry.
* Doing HABTM in CakePHP is a train wreck and whole another
* topic. This is probably the most elegant way to do it
* (not necessarily the shortest and cleanest) as far as
* I know.
*
* The good thing about unit test -- we can be sure
* it works even though we don't understand it lol
*/
function tagged($tag)
{
$this->bindModel(array('hasOne'=>array(
'PostsTag'=>array(
'foreignKey'=>false,
'conditions'=>"PostsTag.post_id = Post.id"
),

'Tag'=>array(
'foreignKey'=>false,
'conditions'=>"PostsTag.tag_id = Tag.id"
)
)));

return $this->find('all', array('conditions'=>array(
'Tag.name'=>$tag)));
}

The above trick was used to force CakePHP to do left joins for us. There is an article that talks about this technique on the nuts and bolts of cakephp blog.

Well, let’s add one more test. We want to make a function to get us the content of a post:

1 2	-- First, update our test database UPDATE `posts` SET `body` = "Hello World!!" WHERE `name` = "Lorem";

1
2
3
4
5
6
7
8
9
10

// /app/tests/cases/models/post.test.php
// Then write our new test
function testGetContent()
{
$post = $this->Post->findByName("Lorem");
$this->assertTrue(!empty($post));

$content = $this->Post->getContent($post['Post']['id']);
$this->assertPattern('/hello world/i', $content);
}

Run it, watch it fail. And then we add our implementation:

1
2
3
4
5
6

// /app/models/post.php
function getContent($id)
{
$post = $this->read('body', $id);
return $post['Post']['body'];
}

Great, now run it and expect it to pass….

1
2
3

$ cake testsuite app all
...
4/4 test cases complete: 11 passes, 1 fails.

Wtf!? It failed? Yeah, we forgot to update our fixtures. That’s it. Every time we update our database, we need to update the fixture. Fortunately, this is one area from Cake that is really painless:

1
2
3
4
5

$ cake bake fixture all -records -count 999
...
$ cake testsuite app all
...
4/4 test cases complete: 12 passes.

The fixture updating part was a little redundant, but it’s better than manually updating the fixture from SQL and also from *_fixture.php. I suggest you can store all your test fixtures data into an SQL file and make some bash script or ruby script to deconstruct the database and load the test SQL file for each test run. You can play around with different connection settings if you don’t want to sabotage your main table for every test run. You can package this loading of SQL file and the fixture baking into one script file so that it can be done in one click. (left as an exercise to reader)

That’s it! In retrospect, it isn’t rocket science, it’s just that I haven’t found any good piece of comprehensive tutorial that hand holds me from start to finish. I’ve been putting off a lot of unit test writing because I’ve always had Cake barking errors at me left and right. Now there’s no excuse

Composition vs. Inheritance

kizzx2 — Sun, 13 Jun 2010 07:21:22 +0000

I was thinking about composition vs. inheritance today and I wanted to make everything crystal clear. Here’s some quick brain-dump of my research and thoughts:

Use composition when possible. It delegates the dependency process to the callsite. This is a prefer composition over inheritance. Since modern programming idioms prefer composition to inheritance, most of the time using delegates and Dependency Injection to achieve composition would be a Good Thing.
Why prefer composition to inheritance? Simply because inheritance is almost the strongest coupling you can introduce between two classes (second to friend classes in C++). We all know that coupling is bad and that separation of concern is good.
Use Inheritance whenever necessary. An example of a necessary case is when the new functionality (injection point) needs to access the protected members of the base class.
When using Inheritance, prefer nonpublic inheritance to public inheritance. Use private inheritance when you need to access the protected members of the base class; use protected inheritance when you need to access the protected members of the base class, while at the same time exposing them to your derivatives.
Only use public inheritance when your derived class is a true IS-A relationship that satisfies the Liskov Substitution Principle.
There is a good quote from somewhere:

Inherit (publicly) not to reuse, but to be reused.

Is there anything that inheritance can do but composition can’t do?

Yes, when you want to access protected members of the base class.
Theoretically, this could still be done using composition by having the base class pass along the required attributes, but that often quickly degenerates into passing a chain of message.
Even if you pass an instance of the Base class to the Derived class in hope of that the Derived class can access the Base class, it’s still limited to the public interface only.

Start doing Requirement Specifications — start programming in English!

kizzx2 — Wed, 09 Jun 2010 12:41:32 +0000

As a freelance developer, I’ve always thought that formal requirements specifications are just too much overhead. Sure, big projects in big corporations will have to ensure the budget and time-frame very accurately using rigorous methods like IBM’s RUP or the ISO approved Function Point Analysis, etc. But for a one-man show, I mean, I could have got the whole project done in the time I had to prepare the specifications, right?

Wrong

Programmers have always notoriously over-estimated how fast they can write code. Of course, we enjoy writing code and time passes by just so quickly, but it doesn’t mean writing code is as really as efficient as writing English. Many small teams shy away from formal specifications because they think they could have written the damn code by the time they’ve got the specification down.

I’ve always believed that, as much as I believed I’m a programmer with adequate skill, until a recent revelation hit me:

Writing the program is, in itself, a DAMN SPECIFICATION PROCESS

That’s right. Instead of confirming with the customer what the requirements are about in clear concise English, we somehow feel better describing the problem to a computer using programming languages. We have advanced through several decades and have lived past the dark eras of Assembly programming to higher level programming languages like Ruby, Python and idioms like functional programming. Why did we choose to move away from low level languages like Assembly and C? Because higher level languages are inherently more expressive — we can say much more with fewer words in a higher level language. In other words, high level languages allow us to program faster.

And what’s the highest level language of all?

English!!

That’s right. Surprise.

But computers can’t read English, doesn’t that mean duplication? We now need to define it in two sets of languages.

Yeah, and that upsets my DRY spirit a lot.

In an ideal world, we could understand the requirements 100% accurately, code it once in the programming language of our choice (Ruby anyone?), deliver the product and bring home the bacon. Everybody is happy

But how often does that ideal scenario happen?

The ideal never happens. Let’s face it, we need to rewrite the damn code anyway.

That’s right. Unless you are an uber skillz haxx0r incarnate, I believe you don’t expect your program to work totally correctly the first time you run it, right? For any programs that more than 10 lines long, I’m it takes at least a couple of retries at least to get it compile without errors. Even if you get it to work correctly, how many times have you written a program and say to yourself “Yeah, this is the perfect solution to the problem”?

That is, even after you get it to work technically correctly, you’ll realize there are some ways to improve it, some quirks that really shouldn’t be there. It’s called “I know it when I see it.”

See? So much for DRY, we need to rewrite it over and over. It’s our damn fate.

If you have to throw away “code,” would you rather throw away a couple of English descriptions plus some wireframes, or a full set of engineered objects?

Many Agile proponents advocate writing code as soon as possible. Ironically, it’s pretty stupid once you think about the pseudo-math behind it:

Let the total number of iterations needed be R
Let the amount of time needed for each English iteration be E
Let the amount of time needed for each Coding iteration be C

Obviously,
    R ≥ 1
    C ≥ 1

For total amount of time needed T:
    T = (R - 1)C + RN
        where N is either E or C

For example, in an ideal case, we do no specification,
just code it once and everything goes fine:
    T = C

Scenario 2: the first version gets rejected by client since we
misunderstood the requirements (or they think we
misunderstood, whatever). It took 3 times of coding:
    T = 3C

Scenario 3: we made a detailed specification, client realized
they mispresented the requirements (notice how the client seem
to understand their own faults when you just tell them in English
instead of code). It still took 3 iterations:
    T = 2E + C

Obviously, E < C. Which means we've saved time!

You see, the only case where writing the detailed specification would “waste” time is when you get everything right the first time. Honestly, how often does that happen?

So what should I do?

Should I go out and read on all rigorous processes out there? Probably, I went down that route and it was quite fun to learn each of them. But ultimately, I must also acknowledge the huge overheads those processes incur. And enforcing the client to go through rigid processes don’t always work without a full team of experienced lawyers and contract writers.

After a lot of trial and errors, the approach I’m adopting now is to have as detailed specification as possible before writing any code. It doesn’t necessarily have to be 100% accurate UML diagrams with spell-checked use cases. I find that just a set of PowerPoint slides, annotated wireframes along with some rough use case scenarios seem to work fine. I try to avoid having charts because people tend to misinterpret quite often. It’s the right mix of flexibility and details that maximizes my productivity.

Some great bash command line tricks I learned lately

kizzx2 — Wed, 21 Apr 2010 18:34:07 +0000

Many adopted from Peteris Krumins’ blog post

Display mounted file systems nicely

The main point here is really about the column command:

1
2
3
4
5
6
7
8
9
10
11

$ mount
/dev/root on / type ext3 (rw)
/proc on /proc type proc (rw)
/dev/mapper/lvmraid-home on /home type ext3 (rw,noatime)

$ mount | column -t
/dev/root on / type ext3 (rw)
/proc on /proc type proc (rw)
/dev/mapper/lvmraid-home on /home type ext3 (rw,noatime)

# woot, now it's printing out nicely!

Repeat arguments of the most recent command

Alt + .

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

$ echo hello world
hello world

$ echo (Alt + .) # this becomes...
$ echo world

# Cool, but what if I wanted "hello"?

$ echo hello world
hello world

$ echo (Alt + 1)(Alt + .)
$ echo hello # here you go!

# Doing the same thing with history expansion
$ echo hello world
$ echo !!:1
echo hello
hello

# There's a shorthand for the last argument in history expansion
$ echo hello world
$ echo !$
echo world
world

Edit the whole command line in $EDITOR

This one is extremely huge. Ever got tired of doing those multiple lines long ffmpeg command lines? Here’s your salvation (and his name is vi)

1 2	$ ffmpeg -i my-input-file.avi <Ctrl+x><Ctrl+e> # You can specify multiple command lines in your $EDITOR and they'll be executed one by one, cool!

Firefox vs. Chrome — is Mozilla going down?

kizzx2 — Sun, 18 Apr 2010 17:13:18 +0000

Just read an article on Tom’s Hardware: Why Mozilla Needs to go into Survival Mode. Woflgang Gruener said that “Google’s royalties account for 80-90% of Mozilla’s entire revenues.” If that’s true, then when Google’s got their own browser, Mozilla would surely go down.

Since it’s launch last year, Chrome’s been iterating extremely rapidly. Chrome v5 is about to launch, that’s five freaking versions in a year! Firefox on the other hard, pretty much (seemingly) got stuck since 3.6. This is probably the weakness of open source software — changes are so damn slow!

I would be very sad to see Firefox go down, because the market really needs more open source sofware instead of giving more personal information to Google.

Strangely enough, my personally experience with Chrome isn’t particularly spectacular. Yes, it launches (way) faster than Firefox and I use it in my eee PC 1000H, but it’s not that much more stable. Ironically with its tab-process separation thing, I’ve had Chrome crashed on me several times bringing down the whole system. Another thing is that I’ve never managed to install any extensions to Chrome, every time I bothered to try, it crashed and would possibly bring my system together with it.

Iterating Bash arrays with spaces

kizzx2 — Fri, 09 Apr 2010 17:27:35 +0000

The problem

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

#!/bin/sh

$ a=(hello world foo bar)
$ for i in #{a[*]}; do echo $i; done

# Expected output:
# hello
# world
# foo
# bar

# so far so good:
# hello
# world
# foo
# bar

$ a=("hello world" "foo bar")
$ for i in #{a[*]}; do echo $i; done

# Expected output:
# hello world
# foo bar

# omg:
# hello
# world
# foo
# bar

The problem is caused by the affect that Bash uses space as array element separator internally.

Failed attempt

1
2
3
4
5
6
7
8
9
10
11

#!/bin/sh

$ a=("hello world" "foo bar")
$ for i in "#{a[*]}"; do echo $i; done

# Expected output:
# hello world
# foo bar

# zomg!
# hello world foo bar

The solution

The solution lies in the magical $@ expansion. When the $@ expansion is put in a quote, the shell automatically expands each element properly quoted:

1
2
3
4
5
6
7
8
9
10
11
12

#!/bin/sh

a=("hello world" "foo bar")
for i in "#{a

# Expected output:
# hello world
# foo bar

# yay!
# hello world
# foo bar

Muxing audio and video with ffmpeg

kizzx2 — Thu, 08 Apr 2010 10:10:20 +0000

ffmpeg is a great codec converter, but it’s wide array of options is really daunting. I just figured out it can also be used to mux video and audio together into a file, here’s how to do it

1
2
3
4
5
6

# Simple example: mux an audio with a video file without audio track
$ ffmpeg -i audio.mp3 -i video.avi -acodec copy -vcodec copy output.avi

# Daily usage example: mux an audio with a video file _with_ an existing audio track.
# This will replace the AVI file's audio track with the MP3
$ ffmpeg -i audio.mp3 -i video-with-audio.avi -acodec copy -vcodec copy output.avi -map 0.0 -map 1.0

The key to the second command is the -map parameter. Typically, the output file would contain two streams: one audio and one video. The numbers 0.0 and 1.0 refers to the first input file and the second input file respectively.

The -map parameter is used to spell out the streams. What the above said was “use input stream 0.0 for your first output stream (which is an audio stream) and input stream 1.0 for your second output stream (which is the video stream)”.

You can see a list of stream numbers by

1	$ ffmpeg -i audio.mp3 -i video-with-audio.avi

You can add additional streams to the output file with the -newaudio and -newvideo parameters. Two audio streams make sense when you’re making a DVD rip with two sound tracks. I didn’t try it myself but it’s nice to know

Cheers

Vrapper: open source vim plugin for eclipse

kizzx2 — Thu, 08 Apr 2010 09:49:12 +0000

Found out Vrapper recently. The fact that it is open source deserves a lot of merits. For years eclipse users only had the commercial option ViPlugin which didn’t work quite well for something that charges money, considering the NetBeans folks have the excellent jVi which is also open source.

Considering eclipse is free and open source, Vrapper only seems more fitting than ViPlugin. I’ve tried it for a week and it seems most essential functions are there, and I’ve been using vi for a couple of years so I think my set of “essential functions” shouldn’t be too narrow :p