The Rich Web Experience

Community Liaison

Pete Muir — Mon, 15 Mar 2010 08:00:11 CDT

Lovely Review of Manage Your Project Portfolio

Johanna Rothman — Sun, 14 Mar 2010 13:00:09 CDT

Steve Berczuk has a lovely discussion of Manage Your Project Portfolio. You can see his review here.

Tweet This Post

Open Source Your Project (with Jasig)

John Lewis — Sun, 14 Mar 2010 11:00:15 CDT

Here is the full screencast from my Jasig 2010 Conference Session on "Open Sourcing Your Project (with Jasig)". Enjoy!

Live from DrupalCamp Nashville

Cal Evans — Sun, 14 Mar 2010 08:00:13 CDT

Dear Reader, I’m sitting here in a session at DrupalCamp Nashville on the Vandy campus. The day has been great and the Nashville Drupelars should be commended for running such a great camp. From a conference organizer PoV, this camp has run smoothly. The Wi-Fi is rock solid, the sessions start on time and the [...]

JBoss Tools 3.1 is now out

Max Katz — Sat, 13 Mar 2010 16:00:04 CST

JBoss Tools team released JBoss Tools version 3.1 this week. It’s the best IDE for doing enterprise Java development with JSF, RichFaces, Seam, JPA, Hibernate more. You now get JSF2 as well as CDI support. You may or may not have known but over 50% of code in JBoss Tools is being written by Exadel team. I want to thank them for doing an amazing job! It’s an excellent set of tools that really makes enterprise Java development much easier.

Open Source Update: jQuery PeriodicalUpdater, TestingLabs, GPars, etc.

Robert Fischer — Sat, 13 Mar 2010 13:00:07 CST

I’ve done a fair bit of fairly small open source updates recently.

jQuery PeriodicalUpdater: The main function now returns a handle that can be used to call stop(), thereby ignoring any updates that may come back and preventing future updates from being sent.
TestingLabs: I released TestingLabs 0.4 to work with Grails 1.2.0. Had a bug with versioning under Grails: More info on JIRA.
Presentations: I’m now storing the slides for my presentations on GitHub. They’re under a Creative Commons License.
ClosureBridge: This is a tiny library (up on the repo.smokejumperit.com Maven repo) that provides a link between Groovy’s Closures and Callable/Runnable/Java code.
Fun with GPars: A small library where I was experimenting with GPars
GPars: Submitted a fix and generally been discussing things with the GPars community (and by that, I mean Vacalv Pech)

See my GitHub page for more info.

This post was by Robert Fischer, written on March 12, 2010.
Comment on this post: http://enfranchisedmind.com/blog/posts/os-update-march2010/#respond
Public Permalink: http://enfranchisedmind.com/blog/posts/os-update-march2010/

This article was a post on the EnfranchisedMind blog. EnfranchisedMind Blog by Robert Fischer, Brian Hurt, and Other Authors is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

I have moved to a new blog

Matthew Taylor — Sat, 13 Mar 2010 11:00:06 CST

I am tired of maintaining blog software on my own, so I’ve created a new blog here. This site will stick around indefinitely, but I won’t be posting here, and I probably won’t be very responsive to comments.

Links for 2010-03-12 [del.icio.us]

Aaron Gustafson — Sat, 13 Mar 2010 08:00:04 CST

A List Apart: Issue 302
Format wars: HTML5 vs. Flash, ePub HTML vs. proprietary technologies.

RichFaces rich:isUserInRole function

Max Katz — Fri, 12 Mar 2010 16:00:07 CST

I blogged earlier about four built-in RichFaces functions that come in very handy, especially the rich:component(id) one. Many rich components (from rich;* tag library) provide client-side JavaScript API. To access this API, you need to use rich:component(id) and add the JavaScript method name, such as: #{rich:component(‘id’)}.someMethod(). For example, go to rich:listShuttle component in RichFaces Developers Guide and scroll to ReferenceData/JavaScript API section. That’s the JavaScript API you can call on this component.

There is one more, less known function available in RichFaces. It’s called rich:isUserInRole(role). It lets you define security roles in web.xml file and then use the role on a page. For example, suppose only the administrator should see some part of a page:

<rich:panel header="Admin panel" rendered="#{rich:isUserInRole('admin')}">
  Very sensitive information
</rich:panel>
 
<rich:panel header="User panel">
   General information
</rich:panel>

In the above example, unless you were authenticated as ‘amdin’, you will not see the top panel. Of course you need the security role in web.xml file. It’s a nice and handy feature to have available.

Live Service Reloading in Tapestry 5.2

Howard Lewis Ship — Fri, 12 Mar 2010 13:00:11 CST

A common question I get during Tapestry training sessions is: Why can't Tapestry reload my services as well as my pages and components?. It does seem odd that I talk about how agile Tapestry is, with the live class reloading, and how nicely OO it is, what with services ... but when you move common logic to a service, you lose the agility because services do not live reload.

This came up yet again, during my latest training session, in London.

I've considered this before, and I've been opposed to live service reloading for a couple of reasons. First, live reloading requires creating new class loaders, and that causes conflicts with other frameworks and libraries. You get those crazy ClassCastExceptions even though the class name is correct (same name, different class loader, different class). Further, in Tapestry IoC, services can be utilized to make contributions to other services ... changing one service implementation, or one module, can cause a ripple effect across an untraceable number of other services. How do you know what needs to be reloaded or re-initialized?

When I last really considered this, back in the HiveMind days, my conclusion was that it was not possible to create a perfect reloading process: one that would ensure that the live-reloaded Registry (and all of its services with all their internal state) would be an exact match for what configuration you'd get by doing a cold restart.

So I shelved the idea, thinking that simply redeploying the WAR containing the application (and the services and modules) would accomplish the desired effect.

But as they say, The Perfect Is The Enemy Of The Good. One very sharp student, Andreas Pardeike, asked: Why not just reload the service implementations?.

Why not indeed? Why not limit the behavior to something understandable, trackable, and not very expensive. Most of the infrastructure was already present, used for reloading of component classes. What about ClassCastExceptions? In Tapestry, service implementations are already buried under multiple layers of dynamically generated proxies that implement the service interface. The underlying service implementation is never automatically exposed.

A few hours of work later ... and we have live service reloading. Each reloadable service gets its own class loader, just to load the service interface class. When Tapestry is periodically checking for updated files, it checks each reloadable service. If necessary, the existing instance, class and class loader is discarded and a new class loader created for the updated .class file.

This is going to make a big difference for me, and for most Tapestry developers. Both applications I'm working on have enough Hibernate entities and other clutter to take some time (20 - 30 seconds) to restart, and most functionality is hidden past a login page. Being able to change a service, for example to tweak a Hibernate query, with the same speed with which I can tweak a template or component class, is just one more thing to keep me in the flow and super productive.

Give it a try ... it's one more step towards making Tapestry so compelling, you wouldn't think of using anything else!

Testing Java EE the JBoss way

Pete Muir — Fri, 12 Mar 2010 11:00:10 CST

Why Eclipse leaves me wanting

Howard Lewis Ship — Fri, 12 Mar 2010 08:00:04 CST

I think I've come to understand why Eclipse leaves me always feeling a bit frustrated. Yes, it is more stable than IDEA, uses less memory, has some documentation, and a lot of acceptance ... but even so, it just leaves me cold (and I was an early adopter, signed up for the beta way back in 2000!).

Keystrokes are not modal

The fact that I can type a common keystroke into an Eclipse window and not know what it will do is painful. How a keystroke is interpreted depends on what perspective is active, what view or editor has focus, and what kind of data is being edited in the editor. That's dead wrong; keystrokes are about muscle memory, and muscle memory remembers motion, not context. The end result is that I get frustrated hitting keystrokes and seeing nothing happening. It doesn't help that I cycle between Mac and a PC on most days.

You can't have it your way

A tool as powerful and extensible as Eclipse walks the tightrope of offering lots of features and customizations without overwhelming the user. Alas, Eclipse is lying in a broken heap fifty feet below that tightrope. Eclipse has an unending set of options and defaults for things I don't care about, but anything I do care about seems to never be presents. Here's a few ideas of the top of my head:

Stop running launches when I close the project (I often have to kill them from the command line)
Give me a quick way to stop all running launches
Why so many steps to implement an interface? It's the second most common thing I do!
How about a button to quickly relaunch the current running launch?
Why are the available refactorings so paltry and where are the 3rd party ones?

Who's eating their own dog food?

When I used IDEA, I was constantly struck by little details that showed that the IDE developers were also its prime users. For example, it has open-type and open-resource dialogs much like Eclipse ... but each recognizes the keystroke for the other, so that if you mistakenly activate the open-type dialog, you just hit the normal keystroke to switch over to open-resource. Eclipse makes you cancel the dialog first.

Another example: in IDEA if you rename a field, it notices the getter and setter and will offer to rename those as well.

IDEA also has lots of quick fixes everywhere, such as "implement this interface" and lots of other tiny, cool things I miss every single day I use Eclipse. It's been about a year since I gave up on IDEA and I still miss it.

Is it cultural or organizational? Eclipse gives me the impression that day-to-day developers either have no concept of how the IDE gets used (and what rough spots are causing some serious chafing) OR they are somehow prohibited from fixing things that are obviously wrong.

If you love IDEA so much why don't you marry it?

So why don't I use IDEA anymore? Two main reasons: first, it's become very bloated, to the point that unless you go in and shut off a ton of features, it's unusable on my hardware. Merlyn has the same problem doing GWT work on his MacBook Pro ... all the help it gives you comes at a cost in terms of CPU and memory utilization and some instability.

Secondly, I tried (even before IDEA went open source) to use IDEA in my training labs and I hit a stone wall of non-acceptance. Switching to Eclipse was a benefit to my students since, even running in Ubuntu instead of Windows, it was familiar and easy to navigate. It also out-performs IDEA inside my Ubuntu Virtual Machine. I simply lack the ability to switch between the two on a constant basis without getting completely confused and frustrated. I had to choose one, and I chose Eclipse: stable and accepted, even if it is brain dead.

Why call it Ugly?

One thing I don't get is how many people claim Eclipse is "ugly" and IDEA "beautiful". I found IDEA to be overly chock-full of modal dialogs and a number of improperly resized (or non-resizable) dialogs and windows. It's a real dog's breakfast in terms of UI, and has the classically ugly Swing look and feel.

I've always found Eclipse to look sharp and somewhat elegant. You can have a debate about the technical merits of SWT vs. AWT and Swing, or the ability to tune Swing to look like SWT ... but SWT out of the box is simply a better L&F visually.

On a Mac they both suck at keyboard navigation, though.

There, I've vented. See what going cold-turkey from Twitter can do?

Weld extensions alpha available

Pete Muir — Thu, 11 Mar 2010 16:00:11 CST

simplejson 2.1.0

Bob Ippolito — Thu, 11 Mar 2010 13:00:10 CST

simplejson (documentation) is a simple, fast, complete, correct and extensible JSON (RFC 4627) encoder/decoder for Python 2.5+. It is pure Python code with no dependencies, but features an optional C extension for speed-ups.

simplejson 2.1.0 is a major update with several new features and bug-fixes:

Decimal serialization officially supported for encoding with use_decimal=True. For encoding this encodes Decimal objects and for decoding it implies parse_float=Decimal
Python 2.4 no longer supported (may still work, but no longer tested)
Decoding performance and memory utilization enhancements http://bugs.python.org/issue7451
JSONEncoderForHTML class for escaping &, <, > http://code.google.com/p/simplejson/issues/detail?id=66
Memoization of object keys during encoding (when using speedups)
Encoder changed to use PyIter_Next for list iteration to avoid potential threading issues
Encoder changed to use iteritems rather than PyDict_Next in order to support dict subclasses that have a well defined ordering http://bugs.python.org/issue6105
indent encoding parameter changed to be a string rather than an integer (integer use still supported for backwards compatibility) http://code.google.com/p/simplejson/issues/detail?id=56
Test suite (python setup.py test) now automatically runs with and without speedups http://code.google.com/p/simplejson/issues/detail?id=55
Fixed support for older versions of easy_install (e.g. stock Mac OS X config) http://code.google.com/p/simplejson/issues/detail?id=54
Fixed str/unicode mismatches when using ensure_ascii=False http://code.google.com/p/simplejson/issues/detail?id=48
Fixed error message when parsing an array with trailing comma with speedups http://code.google.com/p/simplejson/issues/detail?id=46
Refactor decoder errors to raise JSONDecodeError instead of ValueError http://code.google.com/p/simplejson/issues/detail?id=45
New ordered_pairs_hook feature in decoder which makes it possible to preserve key order. http://bugs.python.org/issue5381
Fixed containerless unicode float decoding (same bug as 2.0.4, oops!) http://code.google.com/p/simplejson/issues/detail?id=43
Share PosInf definition between encoder and decoder
Minor reformatting to make it easier to backport simplejson changes to Python 2.7/3.1 json module

Charter for Compassion [Flickr]

Aaron Gustafson — Thu, 11 Mar 2010 11:00:11 CST

Aaron Gustafson posted a photo:

ar.charterforcompassion.org/share/the-charter/

PyCon 2010, Analysis: The Other Kind of Testing

Bob Ippolito — Thu, 11 Mar 2010 08:00:13 CST

I gave a talk at PyCon 2010 in Atlanta last month called Analysis: The Other Kind of Testing (video). It's a very simple overview of techniques such as split testing (AB testing) and a call to action to improve django-lean.

Atlanta was a fantastic location for PyCon 2010, and I look forward to returning next year. Hopefully if I give another talk I'll be able to put a little more time into it :)

As per usual, I've been incredibly lazy about updating this blog, so you're much better off following @etrepum on Twitter.

The Community Manager

Pete Muir — Wed, 10 Mar 2010 16:00:09 CST

Using BIRT and Actuate with JSF, RichFaces

Max Katz — Wed, 10 Mar 2010 13:00:24 CST

Virgil Dodson from Actuate posted a great tutorial on how to use BIRT and Actuate with JSF. RichFaces is used as well. The tutorial uses jsf4birt library developed by Exadel.

jsf4birt can be downloaded here.

Actor style messaging and honey do lists

Andrew Glover — Wed, 10 Mar 2010 11:00:27 CST

As I previously mentioned in “Free lunches, mousetraps and the Actor model“, Edward A. Lee wrote an interesting article entitled “The Problem with Threads” in which he advocates leveraging the actor model in popular languages (such as in Java) as opposed to adopting an entire new paradigm (like Erlang). He states:

We should not replace established languages. We should instead build on them.

It appears that more than a few hip people agree with his line of thinking. It turns out there are quite a few options available for leveraging the actor model in Java. That is, aside from alternative languages like Scala, which supports actors and Groovy with GPars, there’s framework’s like Kilim, ActorFoundry, Actors Guild, and jetlang.

I ended up employing Kilim at a client side over a year ago to replace a thread based computational model. At the time, GPars was in its early stages and I was specifically looking for a speed up in application performance. The multi-threaded application was taking roughly 5 hours to complete.

In the end, the speed up attributed to Kilim (or indirectly leveraging its actor model) was hardly noticeable (some aspects of Kilim were noticeably faster though — such as spawning a task was quite fast as opposed to spawning a normal threads) as the real performance gain was leveraged by reducing and improving database queries (as usual, performance issues were essentially IO bound); nevertheless, the prime benefit of Kilim, which at the time I had overlooked, was the notion of a mailbox. That is, in the actor model, processes can share data more safely.

There are quite a few different implementations and ways to facilitate message passing in various languages and platforms, but to me, the actor model’s mailbox notion is quite intuitive. In Kilim’s actor model, messages are passed between processes via a Mailbox — in many ways, you can think of it as a queue. Processes can put items into a mailbox and also pull items from a mailbox in both a blocking and non-blocking manner (blocking of the underlying process not a thread).

As an example of leveraging mailboxes in Kilim, I wrote two actors (a Husband and a Wife) that extend from Kilim’s Task type. Previous versions of Kilim had an Actor type; however, as of version 0.6, Task is the way to go.

import kilim.Mailbox;
import kilim.Pausable;
import kilim.Task;

public class Husband extends Task {
 private Mailbox<Message> mailbox;

 public Husband(Mailbox<Message> mailbox) {
  super();
  this.mailbox = mailbox;
 }

 @Override
 public void execute() throws Pausable, Exception {
  while (true) {
   System.out.println("Husband listening...");
   Message msg = mailbox.get(); // blocks
   if (msg.getReceipient() == Message.HUSBAND) {
    System.out.println("Husband hears: " + msg.getMessage());
    Message reply = new Message(Message.WIFE, "Yes, dear");
    mailbox.putnb(reply);
   }
   Task.sleep(1000);
  }
 }
}

Under the covers, Kilim works by weaving bytecode so as to control Task types and facilitate their safe interaction — specifically, Kilim’s weaver is looking for methods that throw the Pausable type (previous versions used the @Pausable annotation).

In the Husband class, a few things are going on — first, the instance waits for a message from a shared mailbox. In this case, I used a blocking get call (as in reality, a husband really doesn’t do anything else but waits for orders (I mean requests) from his wife). When a message is picked up, the instance checks to see if it was intended for it (in many cases, wife instances can communicate with children types sending messages like “clean your room” or “brush your hair”).

Once a Message type (which, in this case, is not a Kilim type) is determined to be sent to a Husband instance, the Husband type replies appropriately by creating a Message and placing it into the mailbox instance. Finally, the sleep call is just placed to facilitate reading console output.

The Wife class is similar (expect that she doesn’t wait to listen…). Like the Husband instance, this class creates a Message (in the form of a Honey Do) and sends it off via the shared MailBox; however, she doesn’t wait around — that is, the instance uses the putnb call, which is non-blocking. What’s more, she’ll also attempt to see if anything is in the mailbox for her, but in her case, she also uses a non-blocking call (getnb) like so:

import kilim.Mailbox;
import kilim.Pausable;
import kilim.Task;

public class Wife extends Task {

 private Mailbox<Message> mailbox;

 public Wife(Mailbox<Message> mailbox) {
  super();
  this.mailbox = mailbox;
 }

 @Override
 public void execute() throws Pausable, Exception {
  while (true) {
   Message request = new Message(Message.HUSBAND,
    "Please do x, y, and z today, husband.");

   mailbox.putnb(request);
   Task.sleep(1000);
   Message msg = mailbox.getnb(); // no block

   if (msg != null && msg.getReceipient() == Message.WIFE) {
    System.out.println("Wife hears: " + msg.getMessage());
   }
  }
 }
}

As you can see, if there is a message waiting for her, she’ll hear it, otherwise, she moves on and requests her husband to do something else.

Lastly, everything is coordinated by a simple driver class containing a main method like so:

import kilim.Mailbox;
import kilim.Task;

public class HoneyDo {

 public static void main(String[] args) {

  Mailbox<Message> sharedMailbox = new Mailbox<Message>();

  Task wife = new Wife(sharedMailbox);
  Task husband = new Husband(sharedMailbox);

  husband.start();
  wife.start();
 }
}

Note how a Mailbox instance is created for my custom Message type; what’s more, the sharedMailbox is then shared between both the wife and husband instances. Lastly, things are started via the start method.

Running this hip example yields the following output (remember, your exact output will most likely look different; however, the logic sequence of activities will line up. That is, the wife requests things be done and the husband responds with “yes, dear”, which the wife hears).

 Husband listening...
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear
 Husband listening...
 Wife hears: Yes, dear
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear
 Husband listening...
 Wife hears: Yes, dear
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear
 Wife hears: Yes, dear
 Husband listening...
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear
 Husband listening...
 Wife hears: Yes, dear
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear
 Wife hears: Yes, dear
 Husband listening...
 Husband hears: Please do x, y, and z today, husband.
 Husband says: Yes, dear

The actor model facilitates concurrent programming by allowing a safer mechanism for message passing between processes (or actors). Implementations of this model vary between languages and frameworks — I suggest checking out Erlang’s actors followed by Scala’s as each implementation is quite neat given their respective syntax.

In the end, if you want to leverage plain Jane Java actors, then have a look at Kilim (or one of the other frameworks available) — just make sure you’ve finished your honey do list first, man.

Looking to spin up Continuous Integration quickly? Check out www.ciinabox.com.

Links for 2010-03-09 [del.icio.us]

Aaron Gustafson — Wed, 10 Mar 2010 08:00:50 CST

Google Responds To Privacy Concerns With Unsettlingly Specific Apology
The Onion... brilliant as always.
Using Git for SVN Repositories Workflow
Great overview of using Git with standard SVN repository layouts.