Devoxx 2010 impressions – day 2

My second and (unfortunately) last day at Devoxx i visited two completely different talks.

The first talk was about Cassandra, one of the many nosql databases that have emerged in the last years. Nosql was definitely one of the biggest topics on Devoxx. Four university slots were reserved for it. Apart from the Cassandra talk, there was a talk on Hadoop, MongoDB and HBase.

The second talk discussed two of the most used JavaScript libraries today, Prototype and jQuery.

Cassandra by Example

by Jonathan Ellis

Cassandra is one of the many nosql databases around. It offers scalability, reliability and high availability. It has good clustering and failover capabilities. It also integrates some Hadoop functionality for analyzing its datastore. Currently it has support for Pig and Hive. The scalability and reliability comes at price though. Cassandra doesn’t support ACID transactions and has only limited support for ad-hoc queries (hence the name nosql). This makes it especially suitable for very large internet applications where ACID isn’t that big a deal. Applications like Twitter and Facebook come to mind.

The idea behind Cassandra (and other nosql databases) is that IO should be optimized. Data closely related to each other is stored (often redundantly) close together on disk, thus significantly reducing IO overhead. Compared to relational databases, where scaling is accomplished predominantly by increasing cpus and memory, Cassandra scales by optimizing IO which comes at the cost of increased disk space. But since disk space had become relatively cheap these days, as compared to memory and processor units, this is a fair price to pay.

There is a another price to pay however. As mentioned, Cassandra stores a lot of data redundantly. Data related to a particular query eg. is stored in one row. This highly increases complexity. Since Cassandra doesn’t support referential integrity, so there’s no such thing as a cascaded delete for example, it’s up to the application (hence the programmer) to make sure that the stored data remains consistent with the datamodel. And as mentioned before there is limited support for ad-hoc querying

A good deal of the talk showed some examples on Cassandra’s shell client and Cassandra’s java api Hector. The examples were pretty complex, and coding against the API comes with a lot of boilerplating. Jonathan made and interesting comparison. He compared Hector with JDBC (for relational databases) and foresaw a JPA-like API in the near future. Now this would be really interesting from a JEE programmer point of view. JPA could abstract away the fact that you’re programming against a nosql database! All the examples Jonathan showed,  belonged to an online example Twitter-like application called Twissandra. The example project regarding Hector is called Twissjava.

At the end Jonathan mentioned some more advanced features of Cassandra

  • Batch insertions;
  • Secundary indexes, i.e. the ability to add indexes on additional columns in a row;
  • SuperColumns, which are basically maps of columns, used to denormalize data to avoid extra queries;
  • RipCord, a management suite for Cassandra;
  • JMX monitoring.

All in all, a very interesting talk. I’m definitely going to dive in in this topic in the near future.

And here’s a link to the slides.

Ajax Library Smack down: Prototype vs. jQuery

by Nathaniel Schutta

In the first half of his very inspiring talk Nathaniel Schutta compared two of the most used JavaScript libraries, i.e. Prototype and jQuery. Both have their pros and cons and which one is best suited for the job is mostly a matter of taste.

Both libraries offer a lot of the same goodies:

  • cross browser abstractions;
  • simplified AJAX;
  • CSS selectors;
  • event handling;
  • widgets, effects, animations;
  • javascript utilities.

Both have excellent online documentation available, are widely used, have good community support and are very small libraries.

Apart from the similarities, there are also a lot of differences between the two. According to Nathaniel Prototype has been developed from a programmer’s viewpoint (API centric), whereas jQuery is more focussed on HTML elements. Here’s a list of the pro’s and con’s.

Prototype pros:

  • adds useful functions to core elements (on very very large pages this can cause a significant memory footprint);
  • widgets and effects available via script.aculo.us;
  • ruby flavored javascript;
  • widely used.

Prototype cons:

  • no minified version;
  • performance not always a priority;
  • pollutes the global namespace.

jQuery pros:

  • focussed on HTML elements;
  • doesn’t pollute global namespace;
  • dom traversal is a snap;
  • extensive array of plugins available.

jQuery cons:

  • parameter ordering in apis not alway intuitive;
  • plugins required for a variety of functionality;
  • some functions reassign this.

I’m definitely not an expert on using either one of these libraries but after Nathaniel compared both libraries i think jQuery has a slight advantage. This is because it had plugins in mind when it was first designed. There are a lot of plugin libraries available and you can pick the ones you need and omit the ones you don’t need. In Prototype you only have two options: with or without script.acul.us.

In the second half of his talk he showed some nice examples on using jQuery. One of the points he made is that contrary to public opinion JavaScript isn’t that hard a language. And indeed all his examples where pretty simple. He also stressed the point that code should be self explanatory, so the name of a method for example is very important and should clearly and without any reason for debate state what the method actually does. And of course on more than one occasion he made a case that the question of using one of the open-source JavaScript libraries or not is a no-brainer.
All probably very open doors to most programmers, but still i honestly believe that in practice a lot of these rules are violated.

Here’s a link to the slides.

Advertisements

Seam-gen and groovy

I recently added a groovy action class to my seam-gen project. After a while eclipse’s auto-build kept giving me these misleading ant errors in the groovy.compilemodel task:

groovyc doesn't support the "srcdir" attribute

It took me a while to fix this issue. When i ran the compile target manually there was no problem, so eventually i figured it had to do with the explode launcher that was generated by seam-gen. You need to let it run in a separate JVM.
First, right-click on the project and select “Properties”.

Properties for open18

Next, select “Builders” and Edit the explode builder.


Edit Configuration

Edit configuration

Finally, click the “JRE” tab en select “Separate JRE” as the runtime JRE.

After this the auto-build error should be gone.

%d bloggers like this: