Adam Jordens@littlesquare:~/

Good talk from Emmanuel Bernard and Max Ross on the subject over at InfoQ. Both Hibernate Core and Shards are covered, as well as Hibernate Search.

Particularly interesting for me was his overview of the different mechanisms by which you can support multiple customer schemas securely and with decent performance.  The product I’m actively working on is likely headed in this direction, looks like Oracle VPD is Emmanuel’s preferred solution.  A quick search has turned up an add-on for Postgres called Veil which aims to provide row/column-level security similar to Oracle VPD.  Good to at least have a choice, but I imagine that when push comes to shove, Oracle will win out.

Shards has always looked interesting, will be nice when it finally hits GA and supports the JPA API.  Would make it slightly easier to incorporate and play around with.

Interesting thoughts on clustering Lucene/Hibernate Search.  We’re currently running it asynchronously (ie. @Asynchronous in Seam) on a single node but will likely need to look at pushing it to a second box and trying to get indexes in near real time without noticeable degradation to the front-end.

I’m happy to say that after a good 3 or 4 years of using Exchange for all our corporate email/calendaring, there is light at the end of the tunnel.

I got an invitation today to join our pilot project on Google Apps for Enterprise.  Awesome, right!?

Is it bad than I’m looking forward to the opportunity to jettison all 35 or 40k emails and start anew?  I’d honestly trade that in an instance to free up the memory and CPU cycles chewed up by Entourage. 

It’ll be interesting to see how it plays out.  It’s still a pilot project so there are a few obvious and annoying gaps that force me back to Entourage, but if we can work out those kinks I’ll sure be a happy camper. 

Given that our executives were willing to jump on the iPhone bandwagon from the Blackberry, this idea could actually fly.

I’d be curious to hear from any small to mid-sized companies (we’re in the 75-100 employee range) that have made similar transitions.

I spent a few hours tonight trying to diagnose a problem we were running into tonight with some web application code.

That was on top of the better part of a day that was spent by another developer digging into the code.

Development ain’t easy, and frameworks for all their glory strive to make the easy stuff easier and the difficult stuff… well it’s still difficult.

Take Seam for example, a couple simple @In annotations here and there, and all of a sudden you have an application up and running. 

But throw transactions and exceptions into the mix and the expected behaviour is up in the air.

Imagine the following scenario:

Component A calls Component B.update() which in turn calls EntityManager.persist(someEntity).

someEntity fails a database constraint and an EntityAlreadyExists exception is propagated from Component B.update(). 

Can Component A turn around and update someEntity and call Component B.update() again?

It depends.  In Seam there is a RollbackInterceptor behind the scenes that will rollback any transaction crossing an injection boundary (it’s slightly more complicated than that but we’ll leave that for another day). 

If Component A was a POJO Transactional Seam component, and Component B was a Seam EntityHome component, this wouldn’t work.  In this sitation, Component B throwing an exception would actually rollback the transaction before control was returned to Component A.  Component A could very well handle the exception but the underlying transaction would still be rolled back.

From the looks of the implementation, the EntityHome (Component B) is relying on the entity existing in its PersistenceContext when doing an update.  You can update() multiple times as long as the transaction remains open and long-running.

Throw an exception into the mix and that transaction is likely to get rolled back by the RollbackInterceptor and the persistence context reset.

From that point on, calling Component B.update() (equivalent to EntityHome.update()) is going to report a success but do nothing but flush an empty persistence context. 

The short term fix was to have Component B.update() re-merge in someEntity.  However, rather than perverting the framework, it likely makes sense to dig deeper into the implementations and merge Component A and Component B to prevent the RollbackInterceptor from firing and rolling back the transaction on an exception that is recoverable.

The things you learn!

Interesting little article over on InfoQ talking about Alan Cooper’s book About Face.

Few key points:

• Design for Intermediates Users
• Use Tools that Help Beginners to Become Intermediates
• Less is More
• Design for the Probable, Provide for the Possible
• Eliminate Errors or Confirmation Dialogs

There’s an interesting closing comment discussing the need (or lack there of) for error or confirmation dialogs. 

“Cooper notes that while they [error dialogs] are used to signal that something went wrong with the code, the user tends to interpret them as “I’ve done something wrong.”  When users are told that they are wrong repeatedly, they start to hate your product”

I suspect there’s some truth behind the statement, however all things being equal, if your product is blowing up, there’s a good chance that users aren’t going to be happy campers anyways.

That being said, I agree that showing an error dialog with some cryptic exception message only decipherable by the originating author, is probably not doing anyone a favor.  

Using the Java IDE IntelliJ as an example, it’s quite rare for a user to get an actual error dialog.  Instead, there’s a little status icon in the corner that will blink red whenever there’s a problem.  Clicking it will provide additional details with the option of submitting it back as a bug report. 

It’s important to remember who the user is, and considering the article’s focus on differentiating between beginner, intermediate and expert users, this status icon approach is probably best suited for intermediate/expert users, and not beginners. 

Glenn, if you’re reading this, we’re doing it again.

…

About 4 years ago, some friends and I decided to venture down to the neighborhood rib house for some an all-you-can-eat rib spectacle. 

It’s taken us awhile (years really, some even had to leave the country) to recover, but this time we’ll be 29 co-workers strong. 

The plan is to round everyone up and head to the saloon (yes, bonus points again because the place has saloon in it’s name) for a feast after work.  Should be a night to remember, everyone has been encouraged to wear a white shirt and make a mess of it. 

Food (and drink) is always a good bonding experience, so all-you-can-eat must be even better, right?

I’ll post an update after the fact, should have some better pictures this time as well.  If nothing else, ghetto iPhone photos will have to do us justice. 

There is a great article with David Kelley, the founder of Ideo, one of the most important design firms in the world, on the Fast Company site. The article touches a bit about Kelley’s life and his battle with cancer, but the article focuses on Kelley’s idea of “Design Thinking”. Designing experiences rather than objects. The read is really great and definitely inspires you to open your thought spectrum up a bit. (via surfstation)

Check out the article.