We (that is, “we” developers) all have our favorite secret weapons when it comes to making the complicated (read: RIA) applications seem easy, stuff like JQuery, YUI, Flex, mootools (hahaha, funny right?) Flash, ZK, Openlazlo, etc. But allow me to introduce a new discovery, Appcelerator.

What is it? Well, its not just a collection of javascripts and CSS snippets, its more like a fully integrated development platform with its own (very ant-like) build system and (perl-like) updating system. Appcelerator, an open source (using the more friendly, flexible and down-to-earth license of Apache) system provides developers (not so much designers) with tools to make RIA applications less of a chore.

How it works is that Appcelerator’s SDK basically “compiles” a series of templates (HTML/CSS) and Java code and creates all the appropriate JavaScripts, and a WAR file. Using a message-oriented-architecture all communications between the front-end and back end occurs through discreet “messages” which are just serialized chunks of JSON. Appcelerator handles all of the marshaling/unmarshaling for you so your only concern is making the individual pieces of functionality.

Integration is what appears to be Appcelerator’s real strong point. With the ability to fit in nicely with a Java application, it’ll be more than happy to be in your Perl, PHP, Ruby, or Python application, as well as your Google Gears application as well. With a full suite of widgets and plugins most common pieces are probably already built for you… um, so you don’t have to!

The magic of Appcelerator happens by a dynamic HTML scripting-like language where the developer simply assigns IDs to HTML elements and an “on” attribute which defines (for Appcelerator) the action to perform:

<div id="my_comment" on="r:app.my.package.response then effect[fade]“></div>

What that basically says is when the id “my_comment” receives a response (r) of app.my.package.response then it will fade in the value.

Pretty cool huh? Yes, its way more sophisticated than just this ridiculously simple example, but the idea is that everything is done through a very human-readable scripting syntax and all of the heavy lifting and tedious code of calling the server, marshaling the objects and dealing with the output is done for you.

Fast on the heels of Craig’s last post, I bring you a new tool which is currently undergoing Apache incubation, which has the potential to radically change how you think about databases. Google kick- started this by publishing a paper on their “BigTable” system, and just a short while back Facebook released Cassandra out into Google Code, but along comes CouchDB.

CouchDB, like BigTable and Cassandra (and there are others out there) thinks in terms of documents, not tables. This is pretty significant, especially for developers who spend a lot of time building complex web applications where relationships are modeled in highly inflexible table schemes, using tedious joins and look up tables in an effort to artificially create flexibility through normalization. Well CouchDB does away with that entirely. Its not a new idea (see Berkley DB) but how they do it is what makes this thing fast, efficient and very compelling. Using the “map reduce” algorithm means the databases can be distributed over a number of disparate nodes (all on commodity hardware) and the searching is very fast in that you aren’t looking at everything all at once.

Also interesting with CouchDB is that it incorporates a “view” engine, and out of the box uses javascript as the view/query language. It doesn’t get much more simple than that. Written in Erlang, CouchDB is accessible via a RESTful HTTP interface and there are language bindings for nearly every popular platform.

Check out CouchDB, and relax! We’ll be hearing more about this in the coming months and years me thinks.

Interesting article on ReadWriteWeb today, The Main Street Web.

Its an interesting spin in how the Web/Internet/Digital-whatever will save us from a recession. A lot of interesting topics covered, and perhaps a bit on the (foolishly?) optimistic side, but at the same time, the piece actually makes a considerable amount of sense. Especially for outfits like Molecular who make all that stuff (mentioned in this piece) possible.

Read the comments as well, some good discussion (so far) happening.

At some point in a complicated development project there will come a time when you need to translate a java object (assuming of course that you are working in java) into XML or back. Sure, we’ve all gone through the pain of Castor and the performance hits you take associated with that, and there are other tools, but what is now considered (by many) to be the standard is XStream. I won’t go into too much detail as to why XStream is as great as it is (two words: pull parsing), but suffice it to say it is, great.

XStream uses an aliasing feature so that you can “pretty up” your XML (by default XStream will just use the fully qualified package name for XML node names) which can be weird.

To use the aliasing feature, in your code, you simply do something like:

xstream.alias("node-name",MyClass.class);

Well, that’s all cool and all, but its very hard-coded. Wouldn’t it be cool if you could just wire something like this together in Spring?

There is a way to do this, its quite simple in fact. It just requires you to make an interface that defines a single method, something like: String:getNodeName(). Each class that must be serialized would implement said interface. Now, you just do something like the following in your Spring XML (in this case I created a configuration bean that contains a list of my “models” that must be serialized):

<bean id="config" class="com.marley.tmac.tools.Configuration">
<property id="serializableClass">
<list>
<bean class="com.marley.tmac.models.User"/>
<bean class="com.marley.tmac.models.UserElement"/>
</list>
</property>
</bean>

Now, in the class that handles setting up XStream, you would simply have something like:

for (YourInterface model : listFromSpring) {
xstream.alias(model.getNodeName(), model.getClass());
}

As a good follow-up to Don’s piece, comes a new (Java) library that can make many of your security nightmares go away (with respect to all of those wonderful JDBC properties files with usernames and passwords for production systems, just sitting there, out in the open, just waiting to be discovered).

Jasypt, a library that supports encrypting properties files for Spring, Hibernate (and any other properties files you want to protect) will keep curious eyes confused when all they see are RSA encoded strings for what represents actual configuration data.

Red Hat’s non-profit arm, project Fedora just released Core 8, Fedora’s/Red Hat’s distribution of Linux. Fedora has long been a very developer-friendly operating system (unlike Ubuntu which lacks any developer tools out of the box) has taken further steps to embrace Java development.

Included with FC8 is OpenJDK and IcedTea, the open source version of the JDK /JVM and build tools. With Sun setting Java “free” OpenJDK and the IcedTea projects have become the de-facto open source Java environment.

Also included with FC8 is Eclipse, Maven, Ant, Tomcat5 (this should probably be 6) and Jetty. So we are talking major hardcore Java development right out of the box.

While Java 1.4 promised hot deploy, many implementations of application servers have fallen quite flat on their collective faces in delivering on this promise. Then along comes JavaRebel. A nice little library that actually makes this time consuming and frustrating problem a non-issue. Check out some of the features:

• Changing, adding and removing class/interface methods
• Changing, adding and removing class fields
• Changing, adding and removing class constructors
• Overriding existing methods
• Creating new classes or renaming old ones (as long as some other class superclass doesn’t change)
• Changing method parameter or return types or field type without changing its name
• Changing, adding and removing class/interface constant fields is supported, but will not get reinitialized and thus is only useful for primitive types and Strings

(taken, liberally, from their page here)

Yes, there is a performance penalty with this, so DO NOT EVER use something like this is a production environment, but it can make your life as a java developer, especially in a local environment, a bit more productive and a lot less infuriating (but, er, we never get mad at Java, because Java is infallible!)

With the recent release of Alfresco 2.1, this relatively new entry to the “enterprise-class” open source content management system is beginning to show some very real signs of being a major go-to tool for organizations who need all of the enterprise features of your Documentums, or Teamsites or Vignettes, but being completely open source.

Alfresco’s features are impressive, fully customizable workflow, document management, user roles, remote publishing features, as well as easily integrating other applications to create mashups. Built on a JEE platform, and runs in JBoss, Tomcat, Geronimo, it has real promising of being a mainstay in an Java open source enterprise stack.

While OpenCMS is the old timer in the enterprise-class open source CMS, Alfresco is showing remarkable maturity, in particular to documentation (if you’ve worked with OpenCMS I’m sure you know about the weakness in the documentation) and its feature set. There is also a well established organization backing up Alfresco, providing professional services and support, as well “enterprise” versions of their product, while maintaining a “community” edition.

I’m currently giving it a spin, and am incorporating it into our “home intranet” to publish web content to our various project sites, so the back-end content management is completely decoupled from the front-end content delivery (web) tier. So far, it seems to be working like a champ.

Scripting languages, or “toy” languages I’ve heard some say, are quite the rage today (and most likely tomorrow). We’ve (at least in the Java community) been inundated with a deluge of scripting languages, so many that Apache’s BSF was built (Bean Scripting Framework) to help us make sense of all of them.

There’s a relatively new upstart on the block, goes by the name of Groovy. Groovy, completely based on pure java, incorporates enclosures, code as data, completely OO, completely and transparently embeddable has really started to take off. Think of it as the best of the Ruby and Java worlds, mixed up together in a single JVM, running as either a stand-alone system or embedded in an existing application. Its that cool.

Why are scripting languages cool? Think of it this way. Imagine having a mountain of messy dirty “if/else” statements in your code, and that code constantly changes, needs to be re-compiled, re-deployed and on and on. Imagine taking (decoupling) that code from your application, dropping it into a script, and letting the script handle that stuff for you? Pretty cool eh? Yeah, I think so.

Yes, this is short on detail, I would urge those interested to simply download the Groovy distro, takes about 2 minutes to get it up and running and begin to discover why Groovy is just that.

Well, after, what? 8 years? Looks like the powers that be have decided to brush off the dust of HTML 4 and give our old and dear friend a much needed (?) face lift.

The article on IBM’s Developer Works site is actually long on details, but the question is, will HTML 5 actually look like what is outlined? The W3C and those crazy browser makers can do the darndest things.

Things like <aside>, <nav>, <dialog> and the new embedable objects (audio/video) looks pretty interesting. Also the new structural tags looks like they are finally going to pay more than lip service to a real structure to HTML. That’d be nice.