Aptana Has Help
Eclipse is my IDE of choice. I will not argue that it is the best IDE for each of the tasks I use it for – that is not the point. I like Eclipse because it represents a one-stop-shop – I use it to edit web pages, style sheets, JavaScript, Python, PHP and Java. Eclipse also gives me access to my code repository using Subversion.
Lately, I have also been using Aptana, an Eclipse plug-in that helps me create JavaScript. It also makes some of the latest Web 2.0 cool effects available to me by helping me integrate various JavaScript libraries with my code.
Today, I discovered that the Aptana site provides some high quality help for web developers. I do not specialize in front-end development; therrefore, I find this page very useful. I am currently promoting the use of AJAX at a client site – these resources will be very useful. So will Aptana. Give it a try.
DB4O 6.2 Flies!
I had a chance to use the beta of the next version of db4o – it is fast. Using an index slows things down in 6.1 on inserts – or, it seemed to – but 6.2 is amzingly fast.
Every language has a killer app, an application that catapults a language to popularity. DB4O is my killer app – it is the tool that draws me to Java. Other than that, I am often impatient with Java because everything seems more complicated than it should be. I have been trying to learn about AspectJ – I understand the concept very well, but many of the documents I read make it seem so complicated.
In any case, db40 is a breeze. When I learn to leaverage AspectJ, I look forward to making it even easier for myself. I may write about my AspectJ experience later.
DB4O Problem Fixed!
As I reported a couple of days ago, I was having a problem with a DB4O experiment I was working on. Basically, after about a million records, my application would raise an error saying that I had run out of heap space. I could increase the heap space, but I was unhappy with that solution – it produced only margin improvements, and then I ran out of heap space again.
German Viscuso, who seems to read my blog, suggested that I post my problem to the db4o user forum. I visited the forum, and I found several possible solutions, but I found one that worked.
Early on in my code experiment, I was using an index, but I commented that line out to see how that changed performance – then, I am embarrassed to admit, I forgot to uncomment the line. Users of db4o, please note, the memory requirements and performance of db4o change dramatically if you do not use indexes. Use an index. My problems went away the moment I uncommented the line that maintains an index.
I am sorry to have written a post that suggested that there may be a problem with db4o – the problem was mine. Everybody who uses db4o needs to know: use an index. In a relational database, this affects performance only. With a db4o object cache, it can result in a fatal error.
In my last post, I mentioned that I had some code to ensure that my objects were unique, but it tended to be slow. I was looking forward to getting a chance to use version 6.2, which supports unique constraints. As it turns out, using an index speeds up my inserts as well – it is now both fast, and the repository does not allow duplicates.
In closing, conserve resources, use an index. That’s the ticket. The code to use an index looks like this:
Db4o.configure().objectClass(Person.class).objectField(“firstName”).indexed(true);