Wednesday, January 14, 2009

X11 + Gnome with Bugs = Kick For Innovation

In my Java-based backup software that I am working on now, in the GUI (Swing) I have to pop-up a history of a file that has to be restored. Everything should be very simple: you click on an icon of the file you want to restore, pop-up with a table appears. Then you select the date you need and this little window disappears, file gets restored.

Window originally was implemented as typical JFrame, undecorated, always on top. Works fine on Mac OS X with native LaF (of course! who wants that fugly Java Metal LaF to see!?).

But when it comes to X11 and Gnome... :-( For some reason "always on top" gets to be "always on bottom" or "always depends on Moon phase and Solar interference with UPS". If I call it "window.toFront()" it takes only once-per-entire-software-session, and then gets down again. To fix the thing, I had switched to JInternalFrame. But then I found that native GTK look and feel looks acceptable only on Mac OS X with native LaF or Quaqua.

But on typical Gnome, JInternalFrame looks just that nasty and horrible on several want-to-be-default themes, especially on Linux Mint and Linux Ubuntu. Borders are mangled and of course there is no shadow at all. Title bar of the window on some themes is one pixel narrower than entire window (or sometimes one pixel wider that makes entire border make a vertical gap per window). Dragging performance is usually crappy and slow, especially on Mac OS X.

Trying on OpenSolaris's default theme that looks like new Nimbus theme, overall impression is also could be quite better. Additionally, I've got some very strange errors, when I am adding a reference of the window to current working space.

Rule: if you are GUI designer/programmer, you are responsible for each pixel user see.

Change native LaF and go with Metal is "No-no-no, hell, no-no-no-no-no!!". The people, who was made Metal LaF has no taste, no understanding what style is, no feeling of beauty, use always an axe even to cut an orange and probably it's graphical design was made by a programmer at Sun that was working for Microsoft before... I've decided to make my own hack and here how it looks like (same everywhere):


It is completely glassy, translucent and smooth. I think, it looks much better, performs really fast and has no nasty bugs I faced before.

Great, time to go to sleep finally. :-)

Tuesday, January 06, 2009

Tokyo Winter


Tokyo Winter, originally uploaded by I.S.B.M..

I took this picture near my house right before New Year eve. Duh, no snow, no any feeling of a Christmas Tree and New Year celebration. And 16+ C temperature outside.

But isn't it great? :-)

Java and daemons

I have to say for Java is pretty much OK for daemons, if you want same daemon to be cross-platform out of the box and you do not mind a thing is eating like 30M of RAM or bit more. It is possible to achieve it, once some certain rules are kept strict. You have to remember: you will get entire Java VM instance for your daemon. Therefore before you go to this area, think twice: maybe C or C++ or even Digital Mars D are much better language choices for you?

You might want Java daemons in sort of cases, like:
  • You want to connect to RDBMS, but you can not use ODBC for some reasons or it is just impossible to install client on current OS. For example, you have OpenBSD but need to connect to Oracle. JDBC would work here just perfect. You will not get HotSpot on OpenBSD, but yet you can use Kaffe VM or Cacao VM or JamVM and GNU/Classpath. I tried them all, works almost great, but JamVM is just really meant to be small for embedded devices, hence performance is not that really great.
  • You have something very special inside and do not want to waste time porting your daemon separately to Solaris, to Mac OS X, to Linux, to IRIX, to AIX, to HP UX, to FreeBSD etc.
  • You do not want to waste your time banging your head into the wall, coding with C++, because you realized that library you need either does not exists yet and you have to DIY it or just very bad and you need make it good yourself, before you write your desired daemon.
  • etc.

Your daemon must be really small, simple and clean at implementation. To get that, you definitely have to throw away mostly all Java crappy design patterns. They sucks anyway. Forget about those stupid adapters, bridges, factories and other layered crap, but just do directly what you have to and think like you're coding almost in plain C.

Since Java sucks hard at system programming, because it's VM is almost like an OS itself, there is no such things as .fork(), unfortunately. Therefore, for plain Unix you might use init.d, using shell script with regular running in background task technique would do the trick. For Mac OS X you definitely want to use launchd and it is opposite: your script should not detach, otherwise launchd will think your daemon is dead. For Windows... well, there is daemon stuff from Apache Commons. They also have wrapper for Java on Linux, but as much as I tried, it works horrible and unstable, in my opinion. Additionally, you want to read this article.

The Windows thing... Well, honestly I dunno much what else you can use for Windows, since I am not big fan of this strange OS and have no one around: my servers are all Unix and for desktop I still prefer Mac. But there are must be some wrappers, registry keys for automatically booting it up on start-up or so and other things though...

Happy coding! :-)

Monday, January 05, 2009

Embedded Databases in Java

As I am developing "Better Time Machine :-) ©", I am looking for various embedded databases. Each database has good and bad sides. I even tried JDBM (ripped off from W3C Jigsaw and bit fixed inside — it is just few classes). All I need is very fast and embeddable engine (means, very small at footprint and memory consumption).

Here is a list of what I've tried (since software is written in Java, so I tried pure 100% Java solutions):
  • Apache Derby (AKA JavaDB)
  • Oracle Berkeley DB for Java
  • db4o for Java (sort of ZODB for Python, but much better)
  • W3C JDBM (ripped off from Jigsaw)
  • Some JNI wrappers around GDBM (JDBM and JavaDBM).
  • HSQLDB
  • H2
So shortly, you want to play with these rubber toys only in the case when your database is no more than just a storage for reasonable amount of data that is used by desktop application or a daemon or a server software (here be careful with concurrent access for write). In any other situation, you definitely want to go with a solid server database solution. Use PostgreSQL if you want good stuff for free, MySQL if you want to screw yourself or Oracle if you can buy.

If you want objects, use db4o. Very neat database. But footprint is not any small: about 30M. Think about it. You can also go with W3C JDBM, store entry key as a string and entire object as a byte array of serialized object. Crappy, but works well in some certain cases, if you do not need funky searches (otherwise go back to db4o).

If you want embedded SQL, then definitely H2. It is RDBMS from the same author of HSQLDB, just simply faster and better. It has lots of features and very nicely coded. Performance is very high, it supports very large databases, in-memory databases and works in server mode. Footprint is very small and it is 100% pure Java open source software. It also supports ORMs, if you need this thing. But I am not sure how you could install 120M of ORM, then make cumbersome XML mappings, then use weird HQL (as for Hibernate, for example) and stay happy because your database engine footprint is just 500K library... Go real stuff: use plain JDBC with few more codelines and plain SQL that you can write best! It will reduce size of your application hundred times and increase performance at least as twice, no mention perfect maintainability of code, since it is small, easy, simple and very well understandable to anybody.

Apache Derby is the last thing you need. It is actually IBM Cloudscape, if you remember one. Amount of bugs is so big and it coded so nasty, that to open source and change its name is the only way to hope someone will use it. At performance it is slowest and footprint is twice bigger than H2. Additionally, database might get easily corrupted or just suddenly stop booting. Apache Derby is "No Go" for you and you want to avoid it.

Happy New Year! :)

Update: Hooray, I have an alpha version of my "Better Time Machine © :-)" working! And it works really amazing for me: saves disk space, fast, customizable, yet very simple in use. I am going to put it on public domain, once I am sure it will not break your backups. :-)

Some more update: db4o is not 30Mb footprint, sorry. So do not think about it. :-)

Friday, January 02, 2009

Better Time Machine

I was very upset by an Apple Time Machine. Looks like Apple has no idea how to be loser-friendly. Suppose, you have a Mac and all your data Time Machine put in your external USB hard drive. Now your Mac is very dead. What you suppose to do with your hard drive?.. Your friend with Windows will not be able to read the drive. Your another friend with OpenSolaris installed with shrug and ask "You want me format this thing?". Well, yes, you can mount HFS+ in Linux if support of this file system is in certain distribution or if you install MacDrive third-party software on Windows. After that you will find something very same what rsnapshot does for years to everyone over the world. That's great, but still: how to backup my Linux desktop? How about those, who on Windows? — see, rsync is not very good idea and is not meant to work on Windows, although there is cwRsync thing.

The whole idea of backups is to restore your data AS SOON AS POSSIBLE WITH ANY DEVICE YOU HAVE. It might be Nokia Tablet or that useless Asus Eee PC with custom Linux or very limited Windows XP inside, it might be an OpenSolaris laptop (hell, why not?) etc.

So when I wanted to setup some backup solution for my heterogeneous desktops at my home to make same backups to one standard place, I did not find anything good on freshmeat.net and sourceforge.net as well. These things are usually too complicated and over-engineered or they're just closed source freeware with free licence. To buy a proprietary software by a geek with more than 10 computers at home?.. WTF?..

Shortly, it took for me 5 hours to write a core for my own thing, like Apple Time Machine, from very scratch. It supports any sort of Network Attached Storages without any nasty hacks (iTimeMachine comes in mind) as well as support flash memory cards, USB drives etc. It supports anything anywhere, because it is, simply saying, stores files into a folder you choose. Simply mount your writable share (or "map to a drive" in windozers language) and point software to it.

Backups are just regular ZIP files. Every more-less useful OS has unzip thing, even already dead BeOS or not-yet-born Haiku OS. So as long as you've mounted your drive or flash card to any device (let's say it is FAT32, readable by mostly everything on this planet), you're completely safe to read it by something else at any time with standard tools.

To save your space in storage, it makes incremental backups, of course. First time it makes full backup, storing everything to ZIP file. Compression is optional, but preferred to save your disk space, since smallest ZIP file with few bytes file inside takes nearly 4Kb. However, you may turn compression off, in the case if your machine does not really likes CPU load and you want just to store your files in one file, like a Tar. Again, on my MacBook 2.16GHz Intel Core 2 Duo it performs very nice with full compression and saves lots of space (unlike Apple Time Machine). Next backups contains only new or changed files. To restore all your environment, once your Mac died and you have none of pimp GUI, just simply unzip base ZIP file, then take latest update ZIP file and unzip on top of it, overwriting previous files from base ZIP. You're done!

I am going to put GUI on top of it and make it more fancy and easy to use for users. Basically, it will ask you what to backup where and that's pretty it. Everything else it will decide by itself automatically. To restore files, users will see something very similar to Mac OS X Finder and simply point to the missing file. I do not have finished concept of the GUI for file restore, but I want to do it very intuitive and simple.

Since all stuff is written in Java, it is already working on Linux, Windows and OpenSolaris as well. So for those, who needs personal backup system on other desktop — this stuff might be useful. I am going to keep it very tiny, throwing all the bloatware, that is very typical for Java programs. Will see what we will get finally... :-)

Ugghh... Apple... :-(

Thursday, January 01, 2009

Apple Safari is a disaster browser

Well, after long time trying to use Apple Safari exclusively (WebKit too), trying to love it as much as possible etc, I've concluded finally: this is a disaster browser, if we talk about memory management. It will eat all your memory available and will constantly read your hard drive (I guess, for swap space). The more you use it, the less memory you have. In my case, if I open 20 or more tabs and try see output of fs_usage, almost only Safari process is seen and it is doing something by accessing my disk for some strange reasons. Sometimes hard drive is going so mad that everything is "frozen" and Safari desperatively reading and writing something.

I've took Firefox 3 and it is much much better in this aspect. Additionally, I can not normally make a posting to this blog, using Safari anyway.

P.S. iChat is also disaster chat, so I use Adium instead. And IRC, recently...

Tuesday, December 23, 2008

Tokyo Winter


Tokyo Winter, originally uploaded by I.S.B.M..

That's how Winter in Tokyo looks like. No snow, no ice, no trembling dogs near metro stations.