db4o - OO as it is meant to be

Jease released - Java with Ease

2009-10-27T06:04:00.006+01:00

It took its time, but finally I've done it... I've released Jease - a Content-Management-Framework built on top of db4o as persistence engine and ZK as web-interface.

Jease is an open-source framework to ease the widespread pains developing content- & database-driven web-applications with Java.

Out of the box Jease provides a fully Ajax-driven Content-Management-System as a best-practice-showcase which can easily be tailored to your specific requirements.

Check it out at: http://www.jease.org/

In-Memory Databases...

2008-10-28T18:13:00.006+01:00

I've just read an announcement about "solidDB - an In-memory, relational database software for extreme speed"...

http://www-01.ibm.com/software/data/soliddb/

"As relational in-memory database software, solidDB performs up to ten times faster than conventional databases. Whether deployed as a cache for IBM DB2™ or IDS™, or standalone as the database of record, solidDB delivers performance-critical data with extreme speed."

Put a relational in-memory database as cache in front of another relational database to speed up your architecture? What a brilliant idea...;-)

Makes sence, because memory is so much faster than any harddisk... and holding all the semantic and structural business-data (I'm not talking about binary data like images or videos) in-memory of a standard server equipped with several tons of memory is absolutely no problem for the average business of today, because the real world (which our semantic and structural business-data reflects in some way or other) doesn't grow as fast as the memory-technology... most of the time it doesn't grow at all.

But the big problem with the idea of soldDB is simply "the relational database in front of another relational database". Still to much indirection exposed by your database if you're going to work with objects in your application anyway...

I'm running db4o as in-memory object-database for several years now to maintain mission critical data... and I'm a happy programmer with lots of freetime, because programming complex applications got so easy if you're doing things the right way: using db4o as the perfect Prevalayer... more to come, stay tuned...

Choose the right tools...

2007-12-21T11:33:00.000+01:00

... and don't try to be smart and use one tool as universal solution for all problems. This won't work as expected...

I'm usually wondering about people who are trying to store lots of lots of lots of lots of simple data items into an object-database like db4o and complaining about performance afterwards.

Hello?

Simple data? Even displayable in a single table? Did you hear of RDBMS lately? Nothing will beat an RDBMS in this discipline because over 30 years of investigation were spent into this technology. Just use an RDBMS and you're fine.

db4o is an OBJECT database... sure, you can define a primitve class with 3 string values and one integer and declare it as object... but that's not the point about db4o. An OBJECT database is best suited for storing and querying an rich object model with lots of interrelations between the objects, so you can navigate your whole object graph easily along the defined paths. And as soon as you start to try to model this into a RDBMS, you'll wandering the JOIN-LOTS-OF-LOTS-OF-TABLES-HELL.

So there is a simple rule of thumb:

If you have lots of lots of simple data, use an RDBMS... but if you have a complex object model with lots of lots of complex relations between your objects, go with an object database.

Cayenne is hot (as hot as a ORM can be)

2007-08-14T17:44:00.000+02:00

Today I had a look into another Object-Relational-Mapper: Apache Cayenne

I must admit that it is a very nice product... if you're walking on the relational roads. Cayenne is a little bit different than Hibernate, because you're designing the database schema first and map classes afterwards. All can be done with a little GUI-tool which simply does the job.

Cayenne uses a DataContext which is usually session-bound (whatever a session maybe, think of a web-session) and uses some caches to improve performance.

But as usual with ORM: If you're building lots of relations (every additional cross-table makes you think: who shall understand & maintain this mess in the future?) and query a whole graph of complex objects (e.g. for in memory processing), you're running into the object-relational impedance mismatch... build a prefech query via lots of inner and outer joins or run into the n+1-select-problem. Both solutions suck...

But Cayenne has a very nice concept to solve the typical caching issue. All DataContexts are registered at a controller and are synchronized automagically. So if someone is going to change an object in DataContext A, DataContext B and C and D and so on will be notified of the changed object. This solves the typical refreshing-always-kills-the-cache-problem very nicely.

I'll see if I can come up with something similar for db4o.

db4o.eases(persistence)

2007-08-13T00:17:00.000+02:00

Today I've played once again with my favorite Object-Relational-Mapper... Hibernate. Maybe there's still something I could learn from Hibernate... maybe not. At least it helps a lot to understand people who are using Hibernate and want to switch to db4o.

So I grabbed my copy of "Java Persistence with Hibernate" (this book is worth reading it if you're interested in persistence technologies), installed Oracle Express besides MySQL on my laptop and started to work...

At the end of day I've learned this lesson: Viewing from a OO-perspective Hibernate "stores" objects just as db4o does. Both store just "data", not the methods of an object (here came the Zope Object Database (ZODB) to my mind which stores data and methods together). Hibernate uses a relational database as backend whereas db4o uses its own optimized file-format.

But when Hibernate "stores" objects as db4o does, what is the reason to stick with db4o? Hibernate and RDBMS-technology is so mature compared to the newcomer db4o...

The answer is simple:

- If you have lots of spare time in your life which do you want to convert into working hours until midnight, go ahead with Hibernate and RDBMS.

- If you're interested to get the job done in a fraction of time and ride your cyclocross-bike in the afternoon: use db4o.

db4o is the ease of persistence for the programmer. db4o helps you NOT to think about persistence. db4o just works as you're expecting it. And that is what makes db4o different: It helps you to get things done in less time with less trouble. And because db4o is so simple to use it helps you to keep control over your work. Fewer lines of code, less complexity to manage.

db4o.eases(persistence)

Templating with Jamon - another piece of the puzzle...

2007-04-19T18:23:00.000+02:00

Something I really enjoy about db4o is the promise of statically type-checked code, because I don't want to worry about "refactorings" which get broken due to references of code in strings or strings referencing code.... a typical problem for SQL statements flying around in lots of XML-Mappings (or even more worse: Java code which builds SQL dynamically at runtime).

For the development of web-applications I'm using Echo2, which is a Java-only web-application- framework modeled after Swing. No need to write lots of ugly HTML, CSS, Javascript etc.pp. Just Java and statically type-checked code. What a fun to be a web-application-developer...

But I didn't solve the problem of statically type-checked (and therefore refactorable) templates (e.g. for reports or emails)... until I found Jamon. Jamon is a templating language which gets compiled into statically type-checked non-reflective Java code.

Just a little example:


<%args>
 Person person;
 ShoppingCart items;
</%args>

Hello <% person.getFullName() %>.

We're glad to send you the following books for a special prize:

<%for Item item : items %>
 <% item.getName() %> - <% item.getPrize() %>
</%for>

Save this file as ShoppingMailTemplate.jamon and it gets automatically compiled into a Java-class (via a Eclipse-plugin, Anttask is also possible). Now you can use ShoppingMailTemplate-class like this:

String result = new ShoppingMailTemplate().makeRenderer(yourCustomer, customerShoppingCart).asString()

That's so simple... and now you're safe to refactor your classes without breaking the templates.

Jamon is a really wonderful piece of software for people who love statically type-checked Java...:)

Kiss Groovy...

2007-02-27T20:53:00.000+01:00

I'm a big fan of solutions which try to keep technology simple as possible. So it is no wonder that I'm in love with db4o: No SQL, no XML, no ORM, just me and Java and Persistence which simply works. That's a deal.

Another big simplification for me (mostly developing intranet web-applications) is using the wonderful component & event-based Echo2-Ajax-framework as presentation tier. No HTML, no CSS, no JavaScript, just me and Java and a rich & responsive GUI which simply works across browsers. That's a deal too.

But the mess creeps slowly into your stack of libraries...

I've used...

Velocity as simple templating framework for plain-text reports and mails (loaded from a db4o-database);
JSPs for simple HTML-based reports (loaded from file-system);
BeanShell as script-language for evaluating dynamic business rules stored in a database (db4o of course) and as ad-hoc query-processor for db4o.

Too many different technologies with a similar focus with different pros and cons... any chance to clean up the mess?

I recently started to (re-)evaluate Groovy and come to the conclusion: Groovy solves all my templating, runtime-scripting and ad-hoc-query problems with one integrated, well-balanced and very flexible technology. So I only need to know my Groovy to create complex but clean templates (text or html or whatever), dynamic evaluations of code-snippets and ad-hoc queries against my db4o-databases (and the Groovy-Syntax make these queries looking real cool).

Groovy is just another cool KISS-technology besides db4o & Echo2. It's always nice to see when things become simpler... and to learn something new...:)

No more fakes...

2007-02-13T17:48:00.000+01:00

Something I really like about db4o is the "ease of deployment."

Drop the db4o-jars to your project, define a suitable location for your database file and just start working...

A very nice productivity factor comming along with db4o: It's so easy to work with a copy of the production database on your development machine. Just copy the original (or backuped) db4o-yap-file and start your application on the development-machine. That's it!

Simply start working with lots of data which gives you a much better impression how your application feels & works in a production environment.

This way you don't have to create amounts of sensible fake data which only partly mirrors the production data anyway.

I know that you can export / import a dump of a RDBMS... but this is not as much as simply as simply copying a file.

And that's what I really like about db4o in every aspect: It makes the life of a developer much more productive.

Not so smooth update to 6.0...

2006-12-14T19:46:00.000+01:00

Today I've switched from db4o 5.5 to 6.0 ("ready for production") in a ongoing project. I'm using db4o since 2004 and updating the db4o-jars didn't give me any surprise in the past... this changed today.

I've put the db4o-6.0-jars into my project and called a little update-script:

Db4o.configure().allowVersionUpdates(true);
com.db4o.defragment.Defragment.defrag("database.yap");

1. BIG BANG... Ugly traceback poped up which told me that my database is corrupted. Corrupted? The database works fine with older versions, so corrupted is a harsh word which I really don't like to read when updating databases...

So I told to myself: don't try to do much in one step... I fetched a fresh copy of my database (always work on backups if you're working with databases!!!!), did issue the #allowVersionUpdates(), opened and closed the database and tried defragmenting afterwards. This time all went well. Big Puuuuhhh...

Now I started my application (at least tried of)...

2. BIG BANG... lots of ClassCastExceptions were thrown. ClassCastExceptions for ClassA in a query which was definitevly constrained on ClassB? What the heck is going on?

I dived into my code. I'm using a common superclass for all my persisted classes which holds a "deleted"-attribute. I'm not deleting objects directly, I just mark them as deleted, so I can "undo" deletions if I want to. I'm using a simple "QueryWrapper" (which worked for ages without problems in 5.5 and before) which returns only undeleted objects.

public List query() {
Query query = objectContainer.query();
query.constrain(this);
// The complicated true-not is needed,
// because 'deleted' is declared as Boolean in one application,
// so the expression works regardless of Boolean or boolean
query.descend("deleted").constrain(true).not();
return query.execute();
}

I did some tests and came up with the conclusion: If I constrain my query on an indexed field of a superclass, the constrain of the class itself was ignored. This CRITICAL bug is already reported here:

http://tracker.db4o.com/jira/browse/COR-34

But why the hell did my query work with 5.5?

Because of another bug:

http://tracker.db4o.com/jira/browse/COR-57
COR-34 is no problem if you don't use an index on the field of the superclass. COR-57 describes a problem that an index isn't used properly by older versions of db4o if the number of objects to examine by the query processor exceeds a certain level. Maybe the index on the field wasn't created for other reasons, don't know for sure... bad luck, but good to know what's going on.

To sum up:

My query did work with old versions of db4o, because the index on the field wasn't used properly.
My query was messed with db4o 6.0, because COR-57 hit me right into the face because of using the index.

I've now introduced the proposed instanceof-check (and additionally I'm checking even the status of the 'deleted'-field on my own now).

Now one of my application works fine again... but my confidence in the db4o-query-mechanism is a little bit smaller than before.

I'm already using lots of custom indices and caches for complicated comparisons to speed up queries which would take to much time for the db4o-query-processor. And now I'm using just another "workaround" for the db4o-query-processor for even a simple query. Maybe I'm going to use db4o as a "simple and reliable" persistence machinery in the future which gives me all instances of class with a query-by-example. For all the complicated evaluations I'm using my specialised data structures, which are fast and reliable.

After this not-so-nice-experience, I started to migrate a second application from 5.2 to 6.0... remember what I've said about db4o as a "simple and reliable persistence machinery"?

3. BIG BANG... after migrating the database file, all my java.util.Date-fields which were formerly set to null (denoting that a workflow wasn't activated at all) , became suddenly Sun Aug 17 08:12:55 CET 292278994. I'll guess that java, db4o or my application won't run until this year, but who knows.

There are good chances to run into real trouble if your application relies on checks like this (and my application does):

if(workflowDate==null) {
...doSomeSeriousWork...
}

And to be honest: your Unit-Test won't catch this problem, because newly created java.util.Date-fields will be stored correct again in the database.

Don't get me wrong: db4o rocks! And 6.0 is declared as "production", not as "stable", so its kind of my own fault to try to migrate applications at this "early" stage (for luck I'm only running in a sandbox).

But my experience in other open-source-projects is: If you fall too far behind the current "production" builds, you'll run into even more trouble. And if noone is going to stress current builds with "production" data, some errors won't be detected.

I'll know that the db4o-team is going to fix the issues soon... and I'll hope that "detecting critical errors" is helpful...

The Need for Speed - db4o tops my expectations again...

2006-11-04T21:07:00.000+01:00

I'm currently migrating a web-application to manage internships of students at my university. Each semester approximately 1000 students in different progammes of study need to be distributed over 600 schools in the area according to lots of complex criteria.

The application was formerly build with Zope / Python using the builtin Zope Object Database (ZODB), but became a little bit slow (sort of "unusable" if you would ask the users) over the years because of lots of complex queries and calculations.

The new web-application is completely build on top of Ajax with the wonderful Echo2-framework, so responsiveness of the underlying database-layer was one of the first priorities to give my users the fastest possible graphical user interface delivered via the net.

I choosed db4o as database-technology and this was the best choice (besides Echo2) I could have made for this project regarding the performance: my database-queries return in a few milliseconds, so updates of the GUI are almost instantly. Working with the application is now almost fun (besides the work to be done), because no-one has to wait for anything anymore... thanks to Echo2 and db4o.

Additional to that: Coding an application completly in Java (no XHTML, CSS, JavaScript nor ANY SQL) makes me so productive that I'm wondering how people can still build & maintain complex applications with page-oriented frameworks like Struts and RDBMS-technology... maybe these people have to much time to loose.

Of course I've taken some additional measures in this need for speed... I will write about them when I've finished the application.

db4o... a matter of trust!

2006-09-26T19:54:00.000+02:00

Today several guests (dVPs) were allowed to join the first semi-public db4o-developer-skypecast... a very enlightening event for db4o-hard-core users like me and hopefully not the last one!

It makes me feel good to listen to the people who are developing the database of my choice, because a database isn't just software, a database is trustware!

And it needs a big amount of trust to drop data into such an "exotic" and "small" object-database like db4o (compared to mainstream RDBMS).

But db4o seems to take the right approach (compared to other object-database-vendors): By open-sourcing their database and their development-model db4o gains lots of trust. And that's what really counts in database-driven business.

db4o - your object-data-based on trust!

Making the transition easier...

2006-08-21T14:26:00.000+02:00

There are lots of people in the db4o-forums who are still thinking in the "relational paradigm" and who are trying to work with db4o. And they are constantly hitting the db4o-wall, because db4o is not another RDBMS-solution. db4o is a completely different persistence solution based on the notion of objects.

There's an easy rule of thumb making the transition from RDBMS-world to db4o-OO-world lots of easier:

Forget anything you've learned about relational databases!

Forget about primary keys...
Forget about foreign keys...
Forget about joining tables...
Forget about SQL...
Forget about tables...
...

Best thing to do: Just start developing an OO-Application without persistence in mind!

Develop your domain model along the domain with interrelated classes inheriting from base-classes and so on. Use all the features of your OO-language to create a rich domain model. Think of the instantiated objects living in the memory of the virtual machine. Think of what happens if you'll create new objects or update/delete already existing ones.

As an example for maintaining a consistent object-graph in the memory of the VM (often referred to as "referential integrity" in RDBMS-terms): As long as some objects refering another object, you cannot "delete" this object. You'll have to release all the references to this object first and then this object can be garbage collected by the VM. So your application needs to control or prepare the "deletion" of an object. If your applications is working properly this way, you'll can start to think about persistence.

Persistence with db4o is something like "extending" the memory of your virtual machine to the size of your hard-disk.

Think of db4o as an swap-partition for objects.

If your application works properly without such a swap-space in mind, it will be easy to plug in db4o. db4o helps you to swap objects from memory to disk and back and gives you lots of handles to already stored objects via the different query-mechanisms. Think of db4o as a little helper who breathes live into objects by swapping them from disk to memory (and back) on the command of the programmer.

db4o will be your best friend when you'll start to be a "real" friend of object-orientation...

db4o rocks!

2006-07-27T18:15:00.000+02:00

Today I've halfway finished working on an web-application to create diplomas for Master-Of-Education-Students at my university. Depending on the varying programes of study taken by the students there are lots of lots of really weird business rules to calculate the different grades. And these weird business rules (invented by academic people who never thought or heard about a database at all) need to be maintained in a database via a web-application-interface. And I'm the guy who... you know the story.

I'm so thrilled that I can use db4o on this project!!!

If I had to use a RBDMS I would need to create approximately 100 tables, with db4o I just need to maintain 15 domain classes and that's it. And the domain classes are simply representing the domain as it is. No mismatch, just OO as it was meant to be with some proper philosophical abstraction.

db4o really rocks. I'll never go back to the relational world... if there's any wall I'm going to hit with db4o in the future, I will do everything to tear down this wall...

Why Cobol still matters... Viewing the World from an OO-Perspective.

2006-07-19T20:45:00.000+02:00

Many people claim that data is the most valuable factor for any business today. That's right, no doubt. The same people argue that you have to go with a mature RDBMS like Oracle (or Postgres if you cannot pay Oracle) to store your valuable data. Maybe that's right, too...

But: Why are there so many Cobol-applications running in the wild dating back to the 1970s?

Simply because they are running for 30 years using a simple flat file storage...

It is running and well tested code that matters besides data.

Working code is a value for itself. Data without an business-application full of domain logic which creates, reads, updates, deletes the data according the constraints dictated by the domain is nearly worthless... give Joe User access to SQLPlus and see where your valuable data will go...

If code matters as well (and who hasn't done a quick&dirty-project which is running for years because it just works), then I come to the conclusion:

Data and Code are both valuable factors in any business today, they are different sides of the same medal: a working application which gets things done... and that's the thing that matters.

Of course, you often cannot recreate data which is lost, so a secured and backedup database is a must. But recreating whole applications with lots of grown and proven business logic isn't cheap... most times it is expensive, very expensive, so people are still running Cobol on outdated mainframes.

But how does Cobol and a RDBMS relate to Object-Orientation?

The central theme behind OO is bringing data and code together. Create classes which encapsulate data and are controlling access to this data via methods, which are refering to lots of other classes, build up on the same principles. If OO is done properly, you'll end up with a nice and well done domain model which speaks for itself and allows awesome productivity developing the application running your business.

If you've ever seen a domain model which abstracted the main aspects of the real world to a programming language like Java, you'll end up and must say: Programming is so easy, just call some methods on my objects and things work out for itself. But this kind of abstraction is a philosophical task, so maybe we should have more philosophers among the senior-consultants...

db4o is the vehicle for rethinking object-orientation. db4o brings life back to Plain old Java Objects. db4o allows you to think along the domain and you don't have to worry about persistence. db4o is the way to go in the future, because data and code matters. db4o is a database for objects. Thanks db4o!

SQL for an Object-Database?

2006-07-18T15:50:00.000+02:00

The db4o-community sees a regular request in the forums: How can I use SQL with db4o?

Hey, db4o is an Object-Database which is focused around the OO-programming language of your choice (Java / C#), so why do you constantly ask about a query language dating back to the 1970s?

What might be the use-case for SQL in an OO-database?

Forget about the argument that people are used to SQL and therefore wants to see it as a "must-have"-feature of a "real" database... best to choose an RDBMS if you'll lost in SQL.

Another use-case might be ad-hoc-queries? Just use a simple BeanShell-interpreter (or something similar) connected to your db4o and you can reuse all the features of your domain-model to construct queries in your native programming language (e.g. Java) at runtime of your application. What's the need of flattening your nice domain-model to an SQL-like expression which isn't real SQL anyway? Simply a waste of time...

Reporting? Using Cry*Reports to get nice reports of your SQL-database? db4o has recently published the Db4o Replication System (drs), which allows you to replicate your data to an RDBMS via Hibernate. Just replicate and connect your reporting tool. So there's no more need for "more" SQL to create reports. Maybe we have to think about a possibility for "real-time"-replication. But maybe we are reporting against POJOs in the future anyway...

Another use-case? Manipulating your objects via SQL (insert, update, delete)? Yeah... create an OO-model with nice encapsulation of private data and allow people to work around by firing misbehaving SQL against your objects... not me.

One central vision of db4o: Avoid string-based queries by all means (e.g. the invention of Native Queries compared to former SODA-Queries). And that's one reason developers love db4o: No more strings which will break your nice compile-time-checks and refactoring-tools...

So please, dear db4o-developers: Don't waste time on "integrating" SQL into db4o beyond the DRS. There's simply no use-case for it, it's just a bad marketing for db4o overall, because a possible "db4oSQL" isn't the Standard-SQL people are used to... claiming to support a standard like SQL which cannot be supported properly will result in bad reputation. So stay on the real standard: the programming language of your choice.

From Python to Java

2006-07-16T10:55:00.000+02:00

I did lots of web-application development with Zope in the last years. Zope is an mature web-application-developing environment scripted in Python and backbased by an Object-Database called ZODB (Zope Object Database).

At some point in time I came to the conclusion that scripting languages like Python are a nightmare to be used for developing and maintaining bigger applications over years. There's no useful IDE, no type-safety, no refactorability, lots of strings referencing lots of other strings etc.pp.

So I switched to Java, because Java promised all the things I've missed... cool IDEs, Refactorability without worries, Type-Safety, Compile-Time-checks, no more strings referencing code, etc.pp...

But I was very disappointed about the "best practices" developing web-applications in Java: So much XML, so litte Java...

Using view-technologies like Struts/JSP or JSF gives you lots of XML and templates, which are not aware of the Java-code and vice versa. Refactor a bit and it breaks down the whole thing...

Using a RDBMS with an fullblown OR-Mapper like Hibernate or a lightweight SQL-externalizer like IBATIS gives you lots of XML-files for maintaining the mappings. You change A for B in Java and have to repeat this in the XML-mappings to keep things going...

I felt, that Java (as language) was the right choice, but the stack of mainstream-technologies for developing web-applications was not. I wanted to think and model in objects along the domain and did not want to fight with technology stacks which enforced me to think in technological categories.

I tried to remember what I really liked about Zope: awesome productivity and the object-database which allows you to express complicated "relations" between objects in a more natural way than joining 17 cross-tables in SQL...

So I've searched and finally found two of the most promising technologies, which allow me to concentrate on the problems of the domain: db4o as a real object-database which simply works and Echo as component orientated view-technology modeled after Swing.

Combining db4o and Echo gives me so more productivity than anything I've tried before (and I've even tried Ruby on Rails which falls far behind): Create a bunch of objects for a selection, feed it to the model of the view, get notified that the user selected an object, persist this object to the database and you're done. Just two lines of code. From now on I can concentrate on the domain and I don't have to worry about technologies...

Thanks to Java, thanks to db4o, thanks to Echo...

Ted Neward at DUC 2006: "Objects, All the Way Down"

2006-07-13T22:11:00.000+02:00

Ted Neward gave a nice talk at the DUC 2006. He made lots of good points, but I have to disagree at least on one.

Ted assumes that productivity is one of the most important factors in software development.

Yeah, that's so right!!!

Scientific research has shown that a programmer can only write a certain amount of code-lines per day, mostly independent of the programming language.

Probably this is correct, too...

So a programming language which translates to more resulting assembly code per line of programming code is more productive. One line of Ruby-code translates to hundreds of lines of assembly code whereas one line of Java-code translates only up to ten. So using Ruby is far more productive than using Java.

This argument is completely nonsense! I can start a web-application server like Jetty in three lines of Java-Code which results in thousands of thousands lines of assembly code. Printing "Hello World" onto the screen in Ruby results in thousands of thousands lines of assembly code too, because the lines needs to be interpreted by the Ruby-Interpreter at runtime... So what does the argument show at all about productivity? Nothing...

And I don't think that this kind of argument works for the "average line of code". Maybe you can do a list-comprehension in one line of Ruby-Code and you'll need two or three lines of Java-Code for this. Are you three times more productive with Ruby than with Java? Yeah... if your whole application consists of list-comprehensions, if you don't count the typos you've made and which bubble up at runtime, if you don't want to refactor your application, if you don't want to be supported by an IDE and so on.

To make a long story short: I've used lots of Python for years (and used even some Ruby), but switching to statically-typed Java made me so more productive that I don't believe in the "scripting languages will save our ass"-refrain no more... more to come on this topic.

db4o User Conference 2006

2006-07-13T20:01:00.000+02:00

I just arrived back from the DUC 2006. It was a very, very nice event meeting lots of very nice people... thanks to the db4o-team (esp. Christof) for bringing the die-hard-db4o-users together in London.

The biggest problem for me: Talking to so much people in English is hard if you're not used to it... Hopefully not too much people will think that I'm totally brain-dead. I'll promise: I'm not (at least most of the time).

To be continued...