L337 h4x0r spam

I've JUST created new mailbox... And it already got L337 amount of spam crap... :-(

Beautifully Engineered Opera 9.5

I wisited opera.com for an update for Opera browser that likely "won" Acid 3 test from Safari. The website says:

beautifully engineered
Discover the new standard in Web browsing. Download Opera today to get the fastest and most powerful Web browser available and make the most of your time online.

However, after removing fugly opera's default "Macintosh native" skin and replacing it with something that actually tries to resemble Cocoa, the real beauty looks like this:

I understand it is still better than recently released Firefox 3. But... yet, Opera, you need to try harder... Me? I am just fine with WebKit (Safari) on Mac that is fastest and gets 100/100 with no any problems (grin here).

P.S. The "winner" of Acid 3 was actually Opera 9.0 for some weird reasons...

Salute To Cisco VPN

I just ran find / -perm +00002 -ls > /tmp/world-write and among other crap I found this hilarious thing:

731350  0 drwxrwxrwx 13 root wheel 
/etc/opt/cisco-vpnclient

3731351 0 drwxrwxrwx 49 root wheel 
/etc/opt/cisco-vpnclient/Certificates

Great installation, Cisco!

*morons* :-(

Plugins In Java

I wanted to implement plugin mechanism in my applications. But the thing is, that the plugins should could be also a standalone applications with main() static function inside. This is not very that difficult in principle, just have nice way to do that. Another thing I really want to have, is a call-back mechanism that can get all the arbitrary things, implemented in the parent application. They can be a printing and reporting stuff, authentication, authorization and so on. Finally, I want to have some shared space, where all the plugins can store their arbitrary data and interoperate between each other. What I really do not want to have is a typical bloatware, built on top of some fat framework that does lots of workarounds for specific needs. The thing should be as simple as possible. 

But the challenge is, that if it would be a, let's say, Groovy or Python, then it is pretty easy to implement is: just pass a class instance. Since it is all dynamic — stuff just works. However, Java is a static language that has lots of goodness over dynamic languages, but also this is the place, where ugly shapes appears too.

I am not sure I got it completely right, but at least I could shrink entire http://jpf.sourceforge.net just up to few methods and thus throw away all the framework with no harm to the functionality.

Here above "Plugin Application" is a standalone application that is also a plugin and could be fully acquired by "Base Application". You can run your plugin app, but also you can get it's functionality in the "Base Application" by simply dropping entire JAR file into specified subfolder. That's all it is: just move the JAR and you're done.

Plugin Application has a file plugin.properties that is an XML (can not believe for the shame that there are no support for UTF-8 in plain-text properties!!!) and these props just simply describes what class is main to acquire and how. There also some additional information, like application title, some specific config paths and a menu icon to use. :-)

Base Application simply reads the folder with all the plugins that are subfolders with required libraries and properties file, finds a properties file, parses and registers the plugins. Then once user needs one, launcher actually loads it.

The most worse part of the whole story is a call-back mechanism. This should be a third external package, that is available for both main application and all the plugins. There are two things: an interface and dummy class that implements basically nothing. Real implementation is inside the main application that inherits that dummy class and implements the interface of the call-back. Base Application passes the type of the dummy class something like this:

Class paramType [] = {third.external.package.DummyCallback.class};
Class remoteObject = Class.forName("your.remote.object");
Method meth = remoteObject.getMethod("remoteMethod", paramType);

Above is how you prepare things. Now, call them, where RealCallback class is actually an instance of implemented call-back. In this example I create new one on the fly, but probably in your application it is commonly accessed field that has better constructor and does some real things:

Object params [] = {new ReallCallback()};
meth.invoke(remoteObject.newInstance(), params);

That's it. Base Application has been found remote object, a method and invoked it. Now, on the other side of the whole chain, the following thing is done:

import third.external.package.DummyCallback;
public void remoteMethod(DummyCallback callback) {
    callback.dosomething();
}

This is probably the whole idea that already works for me pretty fine.

NetBeans 6.1 on OSX

Decided to try NetBeans 6.1 Final.

Shortly: everything fine, except one very disturbing thing that makes entire IDE dead. Right after default installation, IDE runs fine. But I've decided to put all required extensions and after restart IDE refused to run, saying that some buggy Xalan version appeared in IDE's class path, sending me to the Wiki, where I've got very strange suggestion to cripple my entire JRE by removing a Xalan from there.

Since this problem appeared after modules installation, obviously, some module brought it to me in addition. Real "Bad Guy ©" appeared in my ~/.netbeans/6.1/ext/ directory. After removing it away, everything runs fine. But ugly crap remains: after this one removed, IDE's class path overall still contains few xalan.jar files, that are just different versions.

No idea where it belonged to, but was too lazy to figure out. :-)

Hacker Key

We do all remember Geek Code, that is somewhat now not updated for a long time. More neat toy for geeks appeared: a Hacker Key that looks kinda interesting. You can take a walk through generator of the Hacker Key or decrypt someone's.

Here is my hacker key:
v4sw7JUYhw4ln3pr7AOck4ma3u7BLMNOSw2m7l5ADEFRUVi63Ce4t3b4Len9a3Xs0r5g3

IBM now loves Macs

Interesting point: IBM is now researching what user impact while migrating to Macs:

A summary of the pilot program, detailed in a IBM document obtained by RoughlyDrafted, revealed that IBM is actively working to move away from its dependence upon Microsoft Windows and toward a heterogeneous cross-platform future.

Wait a second. IBM makes their laptops no more, right? So do not really cares about their future. Personally I am not very sure this move will bring value in a physical items, but this move from IBM, as a father of all PCs is very clear symbolic/spiritual/political/charismatic/call-it-whatever sign to others sign to which way corporate standard shall go.

That's pretty much it: no more IBM Lenovo laptops as corportate de-facto standard.