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.

It has not been a terrible experience (High-end dual-core with 8 gigs of ram does help) but I’ve been looking for more.

I’ve heard good things about Win7, and with the recent release of the RC, decided to upgrade.

I must say the process was quite painless and almost everything worked out of the box.  We just got a new SonicWALL Firewall/VPN at work and the client had to be re-installed.  Other than that, a minor tweak to the command-line parameters for Chrome and I was off to the races.

YMMV but I’ve seen a noticeable improvement in my day-to-day activities on the machine. 

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.

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!

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. 

…

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. 

I was looking for a suitable publishing tool for Windows and was directed towards Windows Live Writer.

Short answer, it’s nice.  I’ve installed the 2009: Release Candidate and published to WordPress with no problems whatsoever. 

It’s the Christmas break and I’ve taken a bit of time to create an Ubuntu VM with Rails 2.2 installed in it.  Rails has come a long ways since I last was working (playing is probably a more appropriate descriptor) with it.  I’ve got a couple ideas to perhaps flush out, but before that, I need to re-learn a few things and come back up to speed.

Installation was simple and straight forward enough, there are a number of decent guides for getting Ruby and Rails installed in Ubuntu.  Since I’m working in Ubuntu and not on my work MacBook Pro, there will be no TextMate for me.  Fortunately, the guys from JetBrains have released early access versions of their new Ruby IDE RubyMine.  I’m a long time user of their Java IDE and if the Ruby equivalent is anywhere near as good, it’ll be a real winner.

RubyMine is nice in that it seems to largely delegate to the command-line Rails generators.  No magic and if you spot an error (it’s still beta software), you can still execute the respective command-line tools and continue working.

Don’t have much else to say, I hope everyone is enjoying their respective holiday seasons. 

Happy New Year!

We are approaching the 6 week and it’s about time I reflect on what we’ve accomplished and tease out a handful of lessons learned.

I’ll be using the terms iteration and sprint more or less interchangeably in what follows.

Lesson #1 : Be Agile

Being agile is a pretty generic goal these days. To be specific, we’ve found a lot of value in developing rhythm within the team; things like regularly sized iterations, scheduled kick offs, test days, retrospectives, etc.

Shorter iterations (we’re doing 2 week) have forced us to decompose tasks at a sufficiently granular level. Borrowing some thoughts from Joel Spolsky, we’ve set an upper bound of task size at 2 days to help drive the necessary design aspects. On the flip side, we generally don’t go smaller than .5 day estimates. Estimates are done as a team using planning poker. There are still surprises but we’re finding out about them after a day or two which makes the response that much easier to make.

Like any project, an iteration must have a well defined beginning and end. In our case, we spend a couple hours on the Monday morning doing the necessary breakdowns for the sprint. The sprint concludes with an all hands test day on the Friday (2 weeks later) with a quick planning meeting the afternoon before. Iteration retrospectives are held on either Friday or Monday as scheduling permits.

Focusing on having working software (and being able to demo it) at the end of an iteration is important. I’ll admit failure in this (so far) but we’re committed to regular iteration demos starting next week. In our case, the product manager has expressed an interesting in giving these demos which should help drive home the customer problems we’re addressing.

Test days are critical to the success of an iteration. In my opinion, you shouldn’t be coding features on the last day of an iteration. You should be testing. If you’ve been regularly testing throughout the iteration than you likely won’t need an entire day but the distinction is vital.

Resist the temptation to focus solely on feature development, fallout from test day needs to be included in the next iteration.

Lastly, it’s important to take time to reflect on the iteration. Grab a few beers and take the last hour of an iteration to discuss the good and bad with your team. Document the feedback and be prepared to incorporate it into the next iteration.

Lesson #2 : Communication

Nothing new here, a team must communicate in order to be successful. For us, we’ve found value in regular 15 minutes morning scrums to discuss current tasks and blockers. Even though we all sit together in the same pod, IM is a significant inter-team communication tool for us.

As the project lead, I’ve got regular weekly opportunities to share status with other project stakeholders. There are weekly meetings with requirements analysts to discuss two things.

1. Acceptance criteria for a feature currently under development.
2. Sign-off for completed features.

In week one of an iteration, we’re focused on specifying acceptance criteria for the features we will be implementing. In week two we’re getting sign-off for the features that we did complete. Rinse and repeat.

These meetings are quick (1hr) and should stay that way.

Lesson #3: Adequate Tooling

We work in an environment that has embraced the Atlassian product suite (JIRA, Confluence, FishEye, Crucible and Bamboo are all heavily used).

It’s important to track the status of both an iteration and project. Stakeholders need this information regularly and you need to be able to provide it regularly (with minimal effort to boot).

There are a number of perfectly acceptable ways to track the status of a project, some manual and some electronic.

Our typical approach to task management involves using physical cards. A team would do a breakdown and the outcome would be a series of task cards (including an estimate). The developer would be assigned 1..* cards and expended effort would be recorded directly on the card. When work was completed, test suggestions were written on the card and then handed off to QA.

The project lead would look at the stack of tasks and produce a burn down chart to share progress with stakeholders.

I had a few problems with the manual nature of this process. There are three inputs to an iteration: bugs, user stories/tasks, and general to-do items. My pet peeve was in the general duplication of information. Bugs and general to-do items are already tracked in JIRA, and having to also track them on task cards seemed counter-intuitive. Not to mention the effort required to manually manage burn-down charts.

Fortunately for us, there is an extension (GreenHopper) available for JIRA that essentially duplicates what we were previously doing manually. We’re now consistently tracking bugs, user stories/sub-tasks, and general purpose to-do’s. GreenHopper leverages existing JIRA functionality around time tracking and reporting to provide a series of planning and task-oriented views. Everything is interactive and moving a task from one iteration to another is a simple drag and drop operation. GreenHopper can generate burn-down charts for particular iterations and JIRA is able to track estimation accuracy (amongst a slew of other things).

To summarize, I’ve still got time to write code which equates to me being a pretty happy camper.

Process is important as much as it enables you to consistently move forward. Too little and you won’t know where you’re going, too much and you’ll never get there.