All businesses have policies and rules embedded in their IT systems, but not all businesses require a Business Rule Management System (BRMS) implementation. Though incorrect business rules in BRMS can easily be fixed, it is more complex to rectify a BRMS that was not needed in the first place. Thus, to fully reap the benefits of business rules, first, it is crucial to precisely identify the need of a BRMS in the enterprise – recognize the aspects of the business which validly require a BRMS and distinguish it from other decision management technologies, such as Business Process Management (BPM) software.

Enterprises could highly benefit from a BRMS if it is characterized by the following conditions (IBM):

• Frequent Business Rule Changes. Rule changes originate from evolving business conditions (e.g. competitive pricing), regulatory amendments (e.g. government compliance laws), and varying organizational practices and policies (e.g. validation and feasibility checks). Organizations with frequent business rule changes are fortunate if modifications to their business policies and/or rules are foreseen and scheduled. However, in reality, this rarely happens. Oftentimes, the necessary changes are not implemented in the required IT systems correctly and/or on-time, risking missed opportunities or regulatory violations. Enabling the LOB to change the rules themselves through a BRMS shortens the release cycle for these changes and helps decrease the risks.
• Highly Variable Decision-Making. Certain business models require customized and/or personalized decisions, specific to locality, product, process or the customer itself (e.g. verification and pricing rules). When embedded in an application, the decision logic for these requirements is complex and even more complex to change and validate. With a BRMS, the organization is equipped with flexible and standard mechanisms for expressing and validating these complex rules.
• Enterprise Logic Sharing. Without a BRMS, business logic that is shared in different applications throughout the organization is either duplicated or embedded in the database. This model works well, until the logic needs to be modified. Logic changes are cumbersome to propagate or are implemented inconsistently. The shared repository and versioning capabilities of a BRMS reduce or eliminate these challenges.

Another pitfall to properly recognizing the need for a business rule management system is confusing its need for other decision management technologies. Sometimes the business problem requires a BRMS in combination with other systems. Other times, the solution may not need to involve a BRMS at all.

Decision management is a “practice of combining software and expertise to automate and improve decision-making within critical business systems”. The core purpose is to “make the best possible decision at the current moment based on data and situational context” (Wilson & Stineman, 2010). Not all decision management scenarios are necessarily a call to action by a business rule management system.

The fundamental distinctions of a BRMS from other decision management technologies are determining the decision based on what is “known” (e.g. corporate policies, regulations) and providing the tools to manage and govern those decisions. A BRMS does the following well: (1) standardizing of operational decisions; (2) straight through processing; and (3) decision brokerage (FICO, 2006).

However, it does not perform well when the problem involves waiting for human intervention, making asynchronous calls to remote systems or gracefully handling errors and exceptions to other services (Sparkling Logic, 2010). In those instances, look to other decision management technologies:

Business rule management systems can undeniably benefit enterprises with real business problems associated with highly variable and complex decision logic. Validate the need of the tool in the enterprise before getting caught up in the “hype”. Know the needs of the organization and how a BRMS can fulfill the requirements. Explore other decision management technologies and ensure that a BRMS is the right system for the organization. And reap the benefits of a much needed BRMS implementation!

References

Dixon, J., & Jones, T. (2011, July 25) Hype Cycle for Business Process Management, 2011.

FICO. (2006, February 9). Are BPMS and BRMS complementary or not? Retrieved February 17, 2011, from FICO Decision Management Blog: http://www.edmblog.com/weblog/2006/02/are_bpms_and_br.html

Gartner. (n.d.). Gartner Hype Cycle. Retrieved February 21, 2011, from Gartner:http://www.gartner.com/technology/research/methodologies/hype-cycle.jsp

IBM. (n.d.). What is a BRMS? Retrieved February 17, 2011, from IBM: http://www-01.ibm.com/software/websphere/products/business-rule-management/whatis/

Sparkling Logic. (2010, February 16). #1 Pitfall in Decision Management. Retrieved February 18, 2011, from Everything Decision Management, Technically Speaking: http://techondec.wordpress.com/2010/02/16/1-pitfall-in-decision-management/

Sparkling Logic. (2010, August 24). Business Rules in or out of BPM? Retrieved February 17, 2011, from Everything Decision Management, Technically Speaking: http://techondec.wordpress.com/2010/08/24/business-rules-in-or-out-of-bpm/

Wilson, C., & Stineman, B. (2010, November). Clear up confusion over BRMS, BEP, BA & BPM. Retrieved February 17, 2011, from IBM: http://www-01.ibm.com/software/solutions/soa/newsletter/nov10/brms.html

©2012 Summa Blog. All Rights Reserved.

As the release approaches we’ve hit thebutton on five of the top features. This list is written from a user and administrator perspective for people who both use and configure Salesforce systems on a daily basis. Be sure to add the features you’re looking forward to most in the comments section. Enjoy and happy Spring ‘12!

5. Chatter Messenger

If your organization uses a chat client such as gchat, yahoo messenger, msn messenger, etc… for interoffice communication this feature will be of great interest to you. Chatter users will now be able to have live chats with each other using Chatter Messenger from within the Salesforce application. This could be used as another way to make Salesforce the go to application for your users, driving faster adoption across the organization. This feature will also be available to Chatter Plus and Chatter Free users, so truly anyone at your organization would be able to use this feature. It will be interesting to check this out with customer groups to see if chatting with customer Chatter users is also an option.

As you can see in the screenshot below, the interface is very similar to a popular social network we all love and/or hate:

A few things to consider when implementing this feature:

• For Spring ‘12 this is being released as a Pilot Program, so you may need to contact Salesforce to have Chatter Messenger turned on
• Chatter must be enabled for Chatter Messenger to be enabled
• A user must follow another user to chat with them
• Chatter Messenger can be disabled without disabling Chatter

4. Case Feed

In Service Cloud engagements in the past we’ve been asked to customize the Case entry, update and detail screens to maximize screen real estate and have had to replace these screens entirely with custom VisualForce screens that use APEX do AJAX updates. A number of those customizations will now be taken care of using the Case Feed feature in Spring ‘12.

This feature gives agents the ability to create, review and update Cases from a screen that gives them relevant Case details, Chatter feeds and also allows responses through multiple channels without navigating to another screen. The sidebar on this screen lets agents quickly switch between activities such as logging calls, Case notes, Case details as well as responding directly to the customer.

To use this feature Chatter must be enabled as well as Chatter tracking on Cases. For high-volume call centers that best utilize Chatter, this feature will be high impact and much easier to use and maintain than custom VisualForce solutions of the past.

3. Analytics Edition

Analytics Edition brings the advanced, BI-like reporting so many have wanted from Salesforce for so long. This is an “Edition” feature which means you will need to add this edition to your org for an additional fee (available for Professional, Enterprise and Unlimited Editions). Contact your Salesforce rep for pricing The major new types of reports are:

• Joined Reports: Create and run reports pulling data from multiple objects. (EX: Report on an Account’s Opportunities and Products associated with those Opportunities)
• Cross filters: Filter across multiple objects. ( EX:  Filter to see Cases from Organizations in a certain Region that also have Opportunities open that are greater than $100k)
• Bucketing: Segment your data on the fly without changing your data model. ( EX: report on open Opportunities by deal size, and group them into custom “Large”, “Medium” and “Small” groupings you create within the report.)

2. Console Push Notifications

A major concern our customers have raised is the issue of two agents or sales reps updating the same record simultaneously. This creates what in the programming world is called a “race condition” where the users are unknowingly in a race to get to the Save button last so that their changes are the changes ultimately saved on the record. This is especially a problem for high-volume call centers, both on Sales and Service Cloud. Now users will be able to see real-time push notification of field and record updates in the Salesforce Consoles.

As a user is viewing a queue or list view, or even updating a record on its detail screen, they will see changes being made by other users in real-time. Administrators can configure colors and bold text to be used to alert users of ongoing changes to a record, and the live notifications can be activated for the following objects (all fields):

• Custom Objects
• Cases
• Accounts
• Contacts
• Leads
• Campaigns
• Opportunities

1. Schema Builder

From an administrator or developer point of view, this is almost undoubtedly the most anticipated feature of Spring ‘12. Schema Builder has been available in a limited beta version that allowed users to read-only views of their org’s schema since Winter ‘12.

Schema Builder in Spring ‘12 (still in beta release, available in All Editions) can now be used to create custom objects, fields and relationships in an extremely fast manner. Custom objects can be created by dragging and dropping, fields and relationships created without the tedious clicking from screen to screen ways of the past. This feature should speed up creation of these objects, fields and relationships by an order of magnitude over the old way admins were forced to click from screen to screen.

Another advantage is the views of your database schema available to you to use for documentation, testing out new schema changes in the sandbox and to see the true data relationships that underlie your Salesforce instance.

The Schema Builder feature is probably best described through a demo, so I’ve included the following Spring ‘12 release preview below. Hit the 4:20 mark to go right to the Schema Builder demo.

©2012 Summa Blog. All Rights Reserved.

The framework as-packaged includes facilities to help with many common aspects of contemporary application development, from a Model-View-Controller (MVC) framework to  integration with persistence managers and elegant transaction management. But it doesn’t necessarily cover every need. One example of a gap is batch processing.

The idea behind batch processing is to allow a program to run without the need for human intervention - this may involve solving a problem that takes a lengthy amount of time, processing a large input set, or just automating some business process that doesn’t necessarily need to be triggered by a human. The batch paradigm was far more dominant in years past than it is in contemporary business computing, but that doesn’t mean valid batch use cases don’t continue to crop up. The operating system you’re using right now likely uses a batch approach to do all sorts of things for you without bugging you about it. Enjoying those automatic backups?

So what if you’ve got a problem that calls for a batch style solution but you’d still like to use Spring? On a recent project, we realized that much of the business logic we’d just finished writing within a web service framed with Spring could be reused for an upcoming batch component (which involved processing a potentially very large XML document that would be uploaded by a business partner). We briefly considered rolling a separate application that reused some of the same code, but before we went down that road someone mentioned hearing of “Spring Batch” - something that was not a part of Spring proper, but an auxiliary framework meant to complement it.

As you can read on its home page,

Spring Batch builds upon the productivity, POJO-based development approach, and general ease of use capabilities people have come to know from the Spring Framework, while making it easy for developers to access and leverage more advanced enterprise services when necessary.

Sounds great! So I dove in and started learning more about it. As I read the documentation, however, I have to admit I got a little overwhelmed by the complexity and amount of configuration needed for even a simple example. Unlike your average Spring application context, the context of a Spring Batch application grows pretty quick and involves configuring a lot of stuff that, at the outset, it just doesn’t seem like you should need to configure. A “job repository” to track the status and history of job executions, which itself requires a data source - just to get started? Wow, that’s a bit heavy handed. Worried that I might be misunderstanding what I’d found, I did some searching and found that I wasn’t alone in thinking the API left something to be desired.

But I’m not going to get as down on Spring Batch as the author of the article I just linked to. The reason being - once I determined what we had to configure in order to get a functional batch job running, I discussed the components involved with my team members and our client and we realized we would appreciate having all of those things. Logged history of batch runs in a database would be good, especially if there were ever a problem or failure. Then our client asked - will we have a UI to control it if we need to?

Enter Spring Batch Admin. It’s unfortunate that the Admin capability is distributed separately from Spring Batch itself - because unless you hear about it or search with the right query, you might wind up rolling your own administrative UI unnecessarily. Of course you can write your own if you’d like - especially if you need to fit in with some pre-existing administrative app you may already have in place - but chances are you have better things to do and batch processing is just one portion of your project.

I’ve got a very important time-saving tip if you think you’d like to use the Admin UI, though: decide if you need it first before starting to develop your batch capability. I made the mistake of thinking it would be easier to get our batch capability working headlessly first, then bolt the Admin app onto the project, in an attempt to reduce complexity and break things down. Instead I wound up having to redo some of the POJOs and configuration involved in kicking off jobs to make what I’d done compatible with the Admin framework. In fact, starting with the Admin framework, and getting it up and running with its ability to run abstract jobs first, then customizing the jobs to meet your needs, would be the path of least resistance.

Once I had everything together, though, what a sweet capability this added up to! Using Spring Batch plus Spring Batch Admin gave my team a relatively low-overhead solution that allowed us to easily hand batch testing duties over to our client - all they had to know how to do was access a web page and click a button. Plus, we’ve given them a framework and a concrete example that is now easily repeatable - given a few POJOs and some copy/paste/modify of the application context XML, they could easily add new batch job types in the future.

That’s it for now - check back for a follow-up article in which I’ll dive into some example configurations and cover specific problems I encountered in my batch app and how I overcame them.

©2012 Summa Blog. All Rights Reserved.

(click to expand)

Step 1: Plan for the Test

Preparation is the trickiest part of usability testing. If good users are not found, relevant tasks not defined, or environments not set-up, the results of the test will be specious at best, or non-existent at worst! It is crucial, therefore, to develop the right foundation for test:

Find the Users: For the typical B2C web site, representative users can be found at any street corner or coffee shop. For many enterprise projects, however, users are not so easily located or accessed. Because users of enterprise software may have specific domain knowledge, work in different departments, or reside in different geographic offices, procuring access to them or aligning schedules can be a significant challenge. If possible, it is important to surmount these obstacles - real users will give more accurate feedback, and will be generally more receptive of the system when it is eventually rolled out, becoming advocates of it rather than opponents to it.

When it is not possible to find real users, representative users (e.g. mapping to defined personas), or even non-representative users, can be substituted with some success; many usability issues can be uncovered by users with no domain experience, a fresh set of eyes the most salient requirement.

It is well documented that usability testing requires no more than 4-6 users per round. Usability issues are typically universal and so are found early - there are diminishing returns for testing with any more than 6 users (i.e. they all tell you about the same problems!).

Plan the Tasks: Not every feature of an application can or should be usability tested. As noted above, it is important, therefore, to identify for usability testing only those features which are prominent, complex, or have a high cost of user error. Once these features are identified, a script of user tasks can be created. Note that tasks should clear, concise, and worded in a way that is independent of the design of the application (e.g. not “click ‘add item to cart’ and click the ‘purchase’ button” but rather “buy a widget”). Lastly, it is important both to run through the script yourself, and also ask another team member to do the same, and ensure that the script takes no more than 15-30 minutes to execute (with the assumption that a user unfamiliar with the application could take 3x this long).

Write the Post-Test Questionnaire: Depending on the application it may be useful to learn about not only the user’s performance (i.e. can they use the system) but also their preference (i.e. do they like it). Surprisingly, it has been found that the two do not always correlate - users may have problems using the application but say the like it, or use it fine but say they hate it. For this reason, it is important to supplement the observational data (i.e. notes from watching the user) with data from a post-test questionnaire. Note that demographic, qualitative, and quantitative data are important - so ask both open-ended questions like “how did you feel about XYZ?” and “on a scale of 1-5, was the system usable?”. Lastly, the late usability expert Randy Pausch advocated always asking at least one question after a usability test: “what were the two worst things about the system?”, guaranteeing that the user will be forced to shed light on at least two tangible usability flaws (and not try to avoid hurting your feelings).

Set up the Environment, Data, and Access: Finally, a stable and perhaps isolated version of the system must be available for the test participants to use. In many cases this will be the normal QA environment, but depending on the frequency of builds or transiency of the data, this may or may not be adequate. If it is not, alternatives may be either to deploy the system on your local machine or to create a special, temporary environment specifically for usability testing. The feasibility of these options obviously depends on the complexity of the application and dependent sub-systems, serivces, or data stores - a simple single web-app to single database may be easy to configure and deploy, whereas a complex system that leverages LDAP, multiple databases, an ERP, and a handful of external web-services would not be.

Additionally, for some usability test scripts, it will be necessary to have each user test with a fresh, pre-configured, non-confidential set of data (for example, maybe a user is asked to find the user with an outstanding balance, and so such a user must exist). If this is the case, a set of SQL set-up and tear-down scripts may be necessary, or perhaps just a script for manually re-creating the data via the user interface. In any case, it is imperative to understand the data dependencies for the test up-front, to ensure that tests go smoothly, and users find issues related to usability and not bad data conditions.

Lastly, in many cases the test subject will log in as a pre-configured, sample user, however in some cases it will be helpful for the user to log in as himself and see “his” data during the test. In this case, it is important to ensure the user has appropriate access control for the QA environment - and it’s not until he tries to log in that you discover that he doesn’t have authorization.

Step 2: Perform the Test

If planning is done correctly, actually performing the usability test should be a snap - your job is simply to make the subject feel comfortable, stand back, and watch what they do! Here are a few things to keep in mind.

Introduce Yourself and the Test: When meeting the user, it’s important to set a very informal, relaxed, and open atmosphere early, so that the user feels comfortable sharing how they feel about the system. To that end, be sure to mention the following simple points:

• It is the system that is being tested, not them.
• The system has issues, but it’s difficult for developers to see them because we are too close to the problem. This is why their help is so important.
• Negative feedback is actually more helpful than positive. No feelings will be hurt if they are frustrated or don’t like something.
• Their help is greatly appreciated, and will contribute to a better product.
• If they get stuck you can jump in and help, but otherwise you’ll stay quiet and let them drive.

After introductions, give them the test script and have them briefly skim the tasks. Convey to them that although the tasks should only take 30-45 minutes, they should feel comfortable taking their time.

Observe, Ask Questions, but Don’t Help: Once the user has begun, it’s important to let them use the system as they wish, even if it means them navigating down false paths (the whole point is to see how they would use it if you weren’t there!). As they complete the tasks, encourage them to talk, and be sure to ask probing, but non-revealing, questions, like “I saw that you clicked the ‘filter’ button but were surprised with the result - what did you expect would happen there?”. If the user is hopelessly stuck, then it may be necessary to give them hints, but otherwise remain an observer.

Take Notes: As the user completes the tasks, take copious notes of their actions, comments, and frustrations - these notes will trigger your memory later and fuel the Usability Observations list that you assemble. Many would argue that it is necessary to also video record usability test sessions, however, the benefit is rarely worth the cost in my opionion (even though it is relatively cheap): project stakeholders seldom take the time to actually view a usability test video session, users may be apprehensive and less honest when being recorded, and the set-up and storage of the recordings can be frustrating and time-consuming.

Step 3: Analyze the Results

Once the tests have been completed, the data must be analyzed and then synthesized into a set of actionable recommendations. To do so, two artifacts can be created, an objective Usability Observations List and a subjective Usability Analysis & Recommendation document.

Create a Usability Observations list: Go back through your notes, and record discrete usability issues that users encountered in a simple spreadsheet. The list should be objectively and tactfully worded, stating, for example, that the user “did not know what the word ‘invoice’ meant” and not “‘invoices’ should be called ‘bills’”. Consensus should be noted for each item (e.g. “3 out 6 users”), and each should be classified either as a “usability bug” (which would later be entered in an issue tracking system to be implemented during the current sprint) or as a “feature request” (which would be added to the product backlog, to be prioritized for a future sprint).

Create a Usability Analysis & Recommendation document: Finally, it will be helpful for project stakeholders to receive a high-level analysis of the usability test, summing up overall impression of the site’s usability (using both quantitative and qualitative data as useful), the areas of the system that were most and least usable, and a set of recommendations for future action (e.g. new features to the backlog, additional rounds of usability testing, etc.). This document may captured in a Wiki, stored in document control (e.g. SharePoint), or just sent via email.

That’s it! Again, I’d like to hear your thoughts on usability testing on enterprise projects. Please share!

©2012 Summa Blog. All Rights Reserved.

Take Down Your Task Board

If you really believe in eliminating waste, and your team is not co-located, the scrum board in your war room is nothing but waste.  The original purpose was for information to be accessible to the team.  You should be able to look at it and know immediately what your comrades are up to.  If you are co-located, you’d have to ask someone to go update the board for you.  That slows both of you down, which isn’t so lean.  This leads me to my next point.

Invest in an online storyboard and make it your homepage

There are a lot of good ones out there.  I prefer Rally (shameless plug for our new partner).  It gives us all the basics — stories, defects, test cases, a burndown chart, as well as a lot of really helpful plugins.

I know what you’re thinking — this is starting to feel like the old project management style.  What’s to keep Rally from becoming the new rigid project plan?  Like any tool, it can be abused, but consider the benefits:

• One story board for everyone to see, even if they’re in your Maui office.
• Team views that show you what your teammates are working on, so you can offer to help if someone is falling behind
• Sprint burndown and velocities to help you plan for the future

And heck, if you’re only happy with a story board on the wall, you could adapt what these guys are doing.

Invest in collaboration software

So we’ve got iteration tracking covered; how do we collaborate?  We’ve all been there when the guy you need to look at your broken code is working from home or sits at the other office.  Checking in questionable code is never a good idea, and you may be using centralized source control so you can’t use the wonders of Git and Mercurial to let your buddy pull in your changes and show you where you you went wrong with your NHibernate cascade.

Every distributed team needs, at a minimum:

• Screen sharing software — Webex, Join.Me, Skype, take your pick.  You need to be able to share your screen so you can see what’s going on.  Encourage pair programming over the wire to get people comfortable with the tool and getting to know each other’s style.
• Chat software (no investment there) — It’s quick, easy, simple, and most of all, quiet.  Nothing disturbs the development room more than a noisy phone conversation.
• Reliable internet access — It seems obvious, make sure all your guys have a strong connection.  Nothing slows collaboration down more than a code review Webex that keeps flaking out.
• Phone conferencing lines available to anyone, at the ready.  There are even some free ones out there — my team has used FreeConferenceCall with a lot of success.

Stick to the Agile Basics

If your team sticks to the agile basics, they are 90% of the way there to a strong development experience, even if they aren’t co-located.  A few things to remember:

• The team owns the code — collaborate and work together to find the best solution.
• Communicate progress and blocks — no one benefits if you don’t ask for help when you’re stumped, when you don’t want to be pushy about a block, or when you hide progress for fear of being assigned more work.  Communicate more and you’ll do more.  Just don’t communicate so much that no one else gets anything done…  :)
• Eliminate waste and ask questions about process — if you think something doesn’t have much benefit, speak up.  Maybe you’re right, or maybe you’ll learn something in the process.  Many of you are familiar with Seth Godin’s TED talk on this subject.  If you aren’t, go watch it.  You’ll like it.

©2012 Summa Blog. All Rights Reserved.

The Holidays are here! Soon snow will be falling, presents will be wrapped, and kids will be in line for Santa at the mall. I thought to myself, in this stressful/wonderful time of the year I would write a little light reading for the blog! I know that sometimes technical blogging can be a little on the strenuous side, so sit back, relax, and hum the tune with me! I know that you know it!

On the first day of Christmas the consultants gave to me, an Agile Project Using, Rally!

On September 26th 2011, Summa announced that it was now a partner with Rally Software! Rally, current leader in Agile application lifecycle management. Recognized Summa’s ability to provide solutions and services that help development teams adopt Agile methodologies. Therefore Summa is now considered a Rally Enablement Partner! See the full article here.

On the second day of Christmas the consultants gave to me, two PTC Awards…

and an Agile Project using, Rally

This year Summa was nominated for two Pittsburgh Technical Council Awards. The first of which was for Technology Accelerator of the Year! The Second of which was for a video that we created that explained why we should win this award. The Video titled “Summa Dogs” can be viewed here!

On the third day of Christmas the consultants gave to me, three UI Designs…

Two PTC Awards and an Agile Project using Rally!

It has been a busy year for us here at Summa! Along with all of the other things going on, we announced on November 8th, 2011 that we had acquired LotterShelly. LotterShelly is a strategic design consultancy that has partnered with Summa on several of our projects. Delivering high end prototypes, designing user interfaces for complex software-intensive products. Our acquisition will provide Summa with the vital component of User Experience Design and will allow them to deliver new value to our customers. See the full article here!

On the fourth day of Christmas the consultants gave to me, four Healthcare Solutions…

Three UI Designs, Two PTC Awards, and an Agile Project using Rally!

On November, 19th 2011 IBM announced that Summa was one of nine Business Partners to achieve IBM Software Value Plus Industry Authorization. We were selected for our focus and track record in the Healthcare Industry. Our Healthcare Solutions Practice allows us to concentrate on systems interoperability, clinical and administrative workflow, user experience, data management and middleware implementation. Read the entire Press Release here

On the fifth day of Christmas the consultants gave to me, five Closed Bells Ringing…

Four Healthcare Solutions, Three UI Designs, Two PTC Awards, and an Agile Project using Rally!

Ah the sound of bells around the Holidays. It always makes me think of The Grinch who Stole Christmas! Around the Summa office it is a well known fact that when you hear a bell (there is a real bell outside of one of our offices) that we have successfully gained a new engagement! Sometimes we just #Ring on SalesForce Chatter too, but that is not nearly as fun! If Summa’s consultants can get 5 rings this season it would put a smile on all our faces!

On the sixth day of Christmas the consultants gave to me, six CRM Solutions…

Five Closed Bells Ringing, Four Healthcare Solutions, Three UI Designs, Two PTC Awards, and an Agile Project using Rally!

With last year’s acquisition of HarvestGold, Summa can now offer Salesforce.com solutions to over 150 customers! We have a wide range from start-up complaints to large enterprise corporations across many industries! In our 10+ years of application development and integration expertise coupled with a long-time partnership with Salesforce.com, we have a long list of satisfied customers who continue to work with us! Learn more about our CRM Solutions here!<

On the seventh day of Christmas the consultants gave to me, seven Summanoids-a-blogging…

Six CRM Solutions, Five Closed Bells Ringing, Four Healthcare Solutions, Three UI Designs, Two PTC Awards, and an Agile Project using Rally!

So if you are reading this you are already well aware of the Summa Blog. Now let me ask if you are aware of all the areas of the blog! Summa has several categories that you can choose from. If you are interested in Agile and Development, to Cloud Applications, maybe it is just some Summa related topics, or you can venture into the great unknown with Uncategorized! Each area, and blogger have their own style and topics they enjoy writing about. So kick back, relax, and take in some light reading! Check out the Summa blog home page!

On the eighth day of Christmas the consultants gave to me, eight Teams-a-Scrumming…

Seven Summanoids-a-blogging, Six CRM Solutions, Five Closed Bells Ringing, Four Healthcare Solutions, Three UI Designs, Two PTC Awards, and an Agile Project using Rally!

I know that Scrum sounds like some sort of rugby term, and it still is. It is also a project management style used in Agile Software development. It is an iterative, incremental framework that Summa utilizes in a large number of our projects. It would take me an entire blog post to write about all the ins and outs of Scrum, and maybe someday I will! Summa has had a large amount of success using Scrum. To add to the power of the Scrum, Summa is now partnered with Rally. Using the right Agile tools, with the right Agile methodology can be a formula for continued successes!

On the ninth day of Christmas the consultants gave to me, nine Client Partners…

Eight Teams-a-Scrumming, Seven Summanoids-a-blogging, Six CRM Solutions, Five Closed Bells Ringing, Four Healthcare Solutions, Three UI Designs, Two PTC Awards, and an Agile Project using Rally!

Summa provides a large range of comprehensive solutions for our customers! To provide these solutions we partner with leading technology companions and complementary service providers!

• IBM Corporation
• Cast Iron Systems
• Salesforce.com
• Microsoft Corporation
• Rally
• Rockwell Automation
• Java.net
• Summa Brazil
• TheNavigatorGroup

For full details about the partnership between Summa and these companies check out more information here!

On the tenth day of Christmas the consultants gave to me, ten Team Members-a-leading…

Nine Client Partners, Eight Teams-a-Scrumming, Seven Summanoids-a-blogging, Six CRM Solutions, Five Closed Bells Ringing, Four Healthcare Solutions, Three UI Designs, Two PTC Awards, and an Agile Project using Rally!

A corner stone to the Success of Summa has always been its leadership team! Each one plays a key role in our long term goals, strategic planning, and day to day lives! The following is a list of our leadership team, for full bios on each check it out on our website here!

• Edward Engler :: Chairman and Founder
• Audrey Dunning :: Chief Executive Officer
• Pedro Barelli :: Chief Operating Officer
• Rick Kotermanski :: Chief Technology Officer
• Dan McDermott :: Chief Delivery Officer
• Jeremy Smith :: Practice Manager, Healthcare Solutions
• Jason Armstrong :: Practice Director, Business Transformation Solutions
• Mike Ripple :: VP of CRM Solutions
• Steve Lippock :: VP, CRM Sales and Business Development
• Betty George :: Director of Business Development

On the eleventh day of Christmas the consultants gave to me, eleven Performance Solutions…

Ten Team Members-a-Leading, Nine Client Partners, Eight Teams-a-Scrumming, Seven Summanoids-a-blogging, Six CRM Solutions, Five Closed Bells Ringing, Four Healthcare Solutions, Three UI Designs, Two PTC Awards, and an Agile Project using Rally!

Users expect more from applications today then they have ever done before. Speed, reliability, and usability are all things in today’s world that are a must. Summa provides the expertise to help clients improve performance without just throwing hardware at the problem.  Application performance engineering is a possibility that is often over looked, but shouldn’t be.  We will lay out a comprehensive road map for the client starting with a baseline performance reading, a report on where issue resides (network or application-related), and outline a plan for addressing the issue. From there the client can decide on what route they want to take. Don’t get left stuck in the mud, check out the entire write-up on our Performance Solutions!

On the twelfth day of Christmas the consultants gave to me, twelve Applications Modernizing…

Eleven Performance Solutions, Ten Team Members-a-Leading, Nine Client Partners, Eight Teams-a-Scrumming, Seven Summanoids-a-blogging, Six CRM Solutions, Five Closed Bells Ringing, Four Healthcare Solutions, Three UI Designs, Two PTC Awards, and an Agile Project using Rally!

So we have come to the end of the road…. And I can’t … wait wrong song! Let’s get back on track. Application Modernization, nine syllables that can change the way your business or product can be preserved.  In the fast paced world of technology a state of the art application five years ago can be obsolete tomorrow. Summa understands this, and knows that clients sometimes need help keeping their applications up-to-date. We are here to help you take advantage of the latest technology advances. It is hard to find a cost-effective solution that takes into account all the variables that a company has to deal with. With 15 years of experience Summa has a niche for helping clients find the right solution(s) that fit their needs! Check out the full summary here!

Happy Holidays!
–Zack

©2012 Summa Blog. All Rights Reserved.

1. Polymorphism and Generics

Polymorphism doesn’t work the way you might expect with generics. For example, consider subtype polymorphism. Even though B is a subtype of A, and it is perfectly valid to say:

A a = new B();

…the following, however, would give a compiler error:

List<A> aListOfA = new ArrayList<B>();

The reason is that a List of B is not considered a subtype of List of A, even though B is a subtype of A. So how do we declare a collection that can store subtypes of a given class? Here it is:

Collection<? extends A>  aListOfA;

This says that aListOfA holds elements of an “unknown” subtype of A. Now, it is perfectly valid to assign a List of B to aListOfA, for example:

List<B> aListOfB =  new ArrayList<B>();
aListOfA  = aListOfB ;

Of course, you can only retrieve elements from aListOfA, and expect them to be of type A. Adding an element to this List would still give you a compiler error though. This is a downside of using bounded widlcards.

2. BigDecimal and primative doubles

Most of us would agree that the BigDecimal class is probably one of the best classes to use when performing financial calculations. A word of caution here is to not use the constructor of BigDecimal that takes the primative double as a parameter. The reason is that the result from this constructor is unpredictable, especially for values involving decimals (remember that Java, or any programming language for that matter, cannot store the decimal fractions exactly when using a double and a float). The other constructor that takes a String is generally recommended and performs much better.

Also, note that equals method in BigDecimal compares not only the value of the two objects, it also compares the scale, and returns true only if both are equal.

3. StringBuffer and the equals() method

You might assume that the equals() method is overridden in the StringBuffer (just like the String class), because IT IS NOT! StringBuffer does not behave like String when it comes to “equality”. For example, if you run the following code, you will get false for the first S.O.P and true for the second S.O.P.

public class Test{
  public static void main(String[] args) {
    StringBuffer aStringBuffer = new StringBuffer("StringBuffer");
    StringBuffer anotherStringBuffer = new StringBuffer("StringBuffer");
    System.out.println(aStringBuffer.equals(anotherStringBuffer));
    System.out.println(aStringBuffer.toString().equals(anotherStringBuffer.toString()));
  }
}

This is not very intuitive, but there is an explanation (here and here).

4. Object heap size and OutOfMemoryError

Generally, the first thing that we do when we see an OutOfMemoryError is increase the Object heap size using “-Xmx/-Xms” options on JVM. In most cases it should (and it does!) fix the problem but don’t be surprised if you continue to see this error. Here is the explanation:

JVM needs memory not just for the object heap, the place where objects are stored, but also for storing classes and other metadata. This space in memory is called Permanent Space and when JVM runs out of this space, a familiar OutOfMEmoryError is thrown which needs to be fixed differently. So how do we differentiate between the two errors, one that occurs when Object heap runs out of memory and the other one when Permanent space runs out of memory? In the case of the former you will see something like “java.lang.OutOfMemoryError: Java heap space” and for the latter one you will see something like “java.lang.OutOfMemoryError: PermGen space”. You can fix the object heap problem by increasing the heap size, but doing the same would not help in fixing the Permanent Space error. In fact, it might make the problem worse as an increase in object heap size would result in even less memory available for Permanent Space. Use “-XX:PermSize” to set the new initial permanent space size and “-XX:MaxPermSize” to set the new max permanent space size instead.

©2012 Summa Blog. All Rights Reserved.

There is an episode of the sitcom Friends where Joey is approached by a travelling encyclopedia salesman, offering to peddle him the entire collection of his wares, the complete Encyclopedia Britannica. Being a struggling actor and lacking the money, Joey opts to simply buy a single volume of the collection: the book focusing on the letter V. Joey, thinking back, realizes that there are many instances throughout his life where he sits dumbfounded as the other friends carry on conversations on subjects about which Joey has no knowledge. So, instead, he nods convincingly, pretending he understands. This V volume will allow him to participate intelligently, he thinks. However, much to his dismay, the first time he gets to exhibit his new knowledge, the conversation swings from a proposed topic of Joey’s (Vietnam) to something related, but starting with another letter: the Korean War. Since Joey doesn’t own the K volume, he again has to sit there, crestfallen, while the conversation carries on without him.

Admittedly, functional programming has been my K volume. I spent years learning the ins and outs of object-oriented programming, stammering through explanations of polymorphism and encapsulation, regurgitating the Gang of Four design patterns whenever applicable. I was ready, I thought. When that conversation eventually started in Central Perk, I was going to be prepared. But, just when I thought I knew all there was to know, everyone went and shifted the damn letter on me.

Now, instead of people talking about Vietnam and Object Oriented Programming, they were discussing Korea and Functional Programming. So, I set about to learn what this new approach was (turns out its not a new approach at all) and just what made it so important.

When I first heard about aspect-oriented programming, the one thing that was stressed in all the descriptions was that ‘this is NOT a replacement for object-oriented programming’. AOP was merely meant as a complement to it. It is something to assist you in easily developing logic that covers the crosscutting concerns you shouldn’t have to worry about in an application. It was basically seasoning for the tried-and-true approach of OOP.

But, if AOP is a seasoning, then Functional Programming is a totally different entrée in a new restaurant. It is a paradigm shift. Functional Programming IS a replacement for OOP. Where OOP focuses on objects and the encapsulation of concerns and behavior, functional programming focuses instead on the actions done to those objects. Where OOP seeks to make it easier to add more nouns to your application, functional programming seeks to make it easier to add more verbs. Where OOP focuses on changes in state, functional programming focuses on changes in actions.

But, what really attracted me to functional programming was its elegant conciseness. I admire its focus on purity, eliminating the verbose, and the mathematical roots from which it proudly inherits.

Functional programming derives its name from the notion of functions in mathematics. Because of its focus on immutability, it can guarantee side-effect free calculation. You pass in arguments to a function, you are returned a result and nothing has changed in the process. This allows for great reuse across many scenarios since external dependencies and state remain consistent.

But its more than that. There are certain tenets that make functional programming unique. The list of items are what make it not just another entree, but a minimalist delicacy that could replace the nine-course Roman orgies you’re used to consuming.

So, in an effort to clarify this for those of you who, like me at one point, are wondering what the fuss is all about, look no further. We’ll get through this together. Following is the dogma of functional programming:

Immutability

The first thing that concurrency experts preach is immutability. If your state cannot change, then thread-safety is not an issue. The problem with this is that immutability in Java is HARD to accomplish. Its not a natural thing. It takes time and preparation.

In functional programming languages immutability is the status quo. In languages such as Clojure, EVERYTHING is immutable except the references to objects, which allows you to maintain a history of changes over time. When you can operate on the base assumption that state is immutable, there are certain leaps of faith that are easy to take.

For example, take the following tree. It is possible to completely change the structure of tree by simply pointing a new reference to different left and right nodes. This is through sharing of certain elements that are not changing. This would not be possible if the elements were mutable because changing a shared element would affect all structures everywhere the element was shared.

High Order Functions (Closures)

Closures are the buzzword of the minute. Everyone is throwing them around, but not because they’re the latest and greatest feature. Javascript has had them for years and Scheme first implemented them in when Steely Dan was still topping the billboard charts. No, mostly they are the talk of the town because Java doesn’t have them. They’ve become a focus in the programming world because of the epic struggle to shoehorn them into the JDK.

In a nutshell, a closure is basically a high-order function. It allows a function or a method to be treated as a first-class citizen of the language and passed as a parameter to other functions. It also allows for this function to be used in algorithmic approaches to problem-solving, such as Map and Fold which will be discussed later.

One argument that many have is that Java has a bastardized form of closures now. This may be true to an extent, but there are two problems with this: 1) the implementation now is a verbose mess and 2) scope. It is getting better in Java 8, but gauging by the long, arduous and litigious morass that begat Java 7, I’m guessing we’ll see Java 8 just in time for the nuclear winter.

First, verbosity. Following is how you would implement an anonymous inner class in Java for an actionListener:

Button b = new Button();
b.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
// Code here
}
});

Yikes, that is a whole lot of nonsense and I mercifully left out the actionPerformed code. Not to mention that we are creating a class here, lugging around all the overhead that comes with it.

Secondly, and most importantly, is the idea of scope. An anonymous inner class can refer to variables outside the class, but since the class could technically live long after the enclosing class falls out of scope, the variables must be final. So, something like this is legal:

final int outerVar = 0;
Button b = new Button();
b.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
int counter = outerVar + 1;
}
});

However, because the ‘outerVar’ variable is final, this prevents modification to immutable reference types and primitives, which at times can be limiting. This runs counter to a true closure in other languages that binds itself to the enclosing environment and allows for unfettered access to these variables.

Recursion

The idea of recursion is a calling card of functional programming. The reason it is the de rigueur approach to iteration is because of immutability. Maintaining a loop counter or a hasNext boolean requires mutable state. Yeah, I wasn’t kidding when I said functional programming focused on immutability, was I?

Matters are made easier when we consider the above point about Lists and Maps. Lists and Maps are easily implemented with recursion and it just so happens they are the central focus of functional programming.

The one problem with recursion is that performance is not very good. It is also susceptible to stack overflows if not properly implemented. Luckily, certain languages such as Haskell and Scala can generate code that represents a loop or eliminate the necessity to produce a new stack frame with every recursion. This is known as tail call optimization and can be employed when the recursive call is the last statement in the function. Java, alas, does not support tail call optimization. Do I hear Kid Charlemagne playing in the background?

Combinators / Concepts

In addition to recursion, there are certain functions and algorithms that are endemic to functional programming. Algorithms such as Fold, Map, Filter, and Reduce are functions that can be performed on all elements in a collection to produce a new collection of results. For example, Fold will ‘fold’ each element on top of the one next to it to produce a new value. The resultant value is then folded again onto the next element in the same direction to produce yet another value. This approach can be used for example to sum up the numbers in a list.

Map can apply a defined function to each element in a list, such as squaring the element it finds. So, a function is defined as say ‘x * x’ and then it is ‘mapped’ to a collection. The result is a collection of the same size with each element squared.

Other functions such as Filter and Reduce apply a function to elements, returning a collection of equal or lesser size with elements inside that were returned as a result of the Filter function.

Concurrency

So, OK, immutability can only get you so far. Scenarios are bound to occur where you uhhh, actually need to CHANGE something. Fear not, compadre, functional programming again has you covered. Two main approaches to concurrency to which functional programming subscribes are the actor model and the software transactional model.

The actor model relies on the idea of an actor of change that serves as your representative to changing data. Need to increment an integer, send a message to the actor. Need to change an address, send the actor a message. Its up to him to coordinate the changes to the data. Rather than have a multitude of callers all banging away at a certain state, they all must coordinate change through the actor.

The astute of you out there will cry foul and say that the actor is going to be a bottleneck in the process. And yes, I would say, that was my impression also. Thankfully, there are whole frameworks built around the actor model that handle this for you. For example, Akka, which is representative of the Scala concurrency framework, is an implementation of the actor model.

Another such functional programming approach to concurrency is the software transaction model. STM deserves its own blog post, but just know that it involves tracking state changes over time. Only references to values are changes and even then, through strict synchronization techniques. STM is akin to database locking in that other transactions cannot view the data in an intermediate state. Some functional languages employ STM and Clojure even has it built into the core language.

So, yes, functional programming can be a dry topic, but if you are truly interested in learning new things and new approaches to solving problems, it is a veritable gold mine of concepts. It takes a bit to grasp, and probably a lifetime to master, but as Steve Jobs colloquialized, ‘the journey is the reward’. And its probably best to begin the journey before the letter switches again and you need a whole new encyclopedia.

©2012 Summa Blog. All Rights Reserved.

On most enterprise applications, in my experience, usability is promoted via a number of low-cost methods: following usability standards, deferring to user interface specialists, trusting our intuitions, or simply conferring with customers and business owners. And while these methods are sufficient in most cases, when usability is a high priority, there is simply no substitute for actually watching people, without interference, use the software we build. This is the practice of usability testing.

In particular, I believe that usability testing should be strongly considered on projects where…

1. The user base of the system is numerous, not technically-savvy, or external to the customer.
2. The cost of user error is high (e.g. software for managing financial transactions, medical procedures, etc.) and features are complex.
3. The UI framework or paradigm is nascent or highly flexible (e.g. RIA, iPhone, etc.) and a consensus on usability patterns or best practices has not yet been reached.

In addition to making our products easier to use, usability testing can also be of great benefit to us, the developers of the software, by improving our usability intuitions, educating us on the functional domain and application of the software we build, and re-enforcing for us that what we create has a tangible impact on real people.

In this post I’ll describe usability testing within agile projects from a project management perspective, describing how to estimate, prioritize, and “burn-down” the usability test. In a follow-on post, I’ll dig into the actual activity of usability testing, breaking down some best practices within the framework of a simple 3-step process: (1) plan for the test, (2) perform the test, and (3) analyze the results. Let’s get started…

Managing Usability Testing with Scrum

Effective usability testing can be easy, quick, cheap, and, as the diagram below shows, can fit seamlessly within the Scrum methodology. Here are some tips, given my experiences with usability testing on Agile projects, on how this can be achieved:

(click to expand)

Usability Test as Backlog Item: Unlike other development best practices (like code reviews or unit testing), usability testing should, in my opinion, not be “built-in” as a part of normal development tasks, but rather should be treated as a separate backlog item - given an estimate by the development team, a priority by the business owners, and is assigned to a sprint for completion. Unlike other backlog user stories or tasks, however, usability testing has the property that it is never truly “done” - there are cases when (indeterminately) many rounds should be performed, and so the task of usability testing should never really be permanently plucked from the backlog.

Estimation: Although the amount of time it takes to perform a usability test depends on many project factors (e.g. scope or complexity of the application, availability of users, etc.), in my experience (using the methodology to be laid out in the next post) effective usability testing can usually be completed with roughly 30 man-hours of work: 15 for the preparation, 10 for the test itself, and 5 for the analysis and communication of results.

Prioritization: Oftentimes, even when usability testing should be performed (see above), business owners or other project stakeholders will still be reluctant or apprehensive to do so - especially when other methods (like just trusting intuitions) are cheaper and seem just as effective. It is important in these cases to stress that (a) usability is important, (b) we are notoriously bad judges of what is usable (too technical, too close to the system, etc.) and (c) usability testing can be cheap and extremely fruitful. Further, it is crucial to note that the earlier in the lifecycle that usability issues are identified, the easier they are to resolve - for example, redesigning a system’s confusing navigation structure once it is in production can be extremely costly and risky. In the end, however, usability testing should be prioritized along side all other user stories on the backlog, and this prioritization should be driven by the product or business owner.

Usability Testing as a Burndown Task: Once usability testing has been selected for inclusion in a sprint, it should be assigned to one developer (where in agile teams, “developer” can mean tester, programmer, UI designer, etc.). Note that all activities of usability testing (planning, testing, and analysis) should fit within one sprint, and the task should be “burned-down” like any other development task. The practice of usability testing does not require an “expert”. Anyone is capable of performing one, and in fact, should if given the opportunity - it can be a rewarding and broadening experience.

Incorporating Feedback: Once the usability test is performed, observations from the test will be analyzed and discussed (see next post), and eventually some consensus will be achieved regarding how the application should change to improve user experience or efficiency. This feedback can flow back through the Scrum development process in one of two forms: either as (1) new user stories added to the backlog (e.g. “as a customer, I want to be able to use wild cards in text searches”) or, when improvements are simple, as (2) bugs managed by the defect tracking system (e.g. “error messages should be red, not yellow”).

As always, I’d be happy to hear about your experiences with usability testing on Agile projects. How often do you usability test? How do you track it from a project management perspective? Please share!

Also, check back in a few weeks for part 2 where I’ll dig in to the actual practice of usability testing in more detail.

©2012 Summa Blog. All Rights Reserved.

A business rule management system (BRMS) is a software system used to define, deploy, execute, monitor and maintain variable and complex decision logic used by operational systems in an enterprise (Stineman, 2009). At a minimum, a BRMS is composed of the following components:

• Repository. It encapsulates the decision logic or rules, external to the core application code, such that it can be shared and reused across the organization.
• User Tools. Tooling allows the Line of Business (LOB) and Information Technology (IT) groups to define and manage decision logic.
• Runtime Environment. The runtime engine allows production systems to access and execute decision logic overseen by the BRMS.

References

Dixon, J., & Jones, T. (2011, July 25) Hype Cycle for Business Process Management, 2011.

Gartner. (n.d.). Gartner Hype Cycle. Retrieved February 21, 2011, from Gartner: http://www.gartner.com/technology/research/methodologies/hype-cycle.jsp

Stineman, B. (2009, November). IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and Developers. Retrieved February 18, 2011, from IBM: ftp://ftp.software.ibm.com/common/ssi/sa/wh/n/wsw14072usen/WSW14072USEN.PDF

©2012 Summa Blog. All Rights Reserved.

The Page Objects design pattern is outlined in the Selenium wiki, but to summarize, Page Objects are meant to encapsulate the messy internal state of a page. Changes in the presentation code should only require changes only to the Page Objects, not to the actual test code. Using a Page Object promotes consistency; there may be five different ways to legitimately determine that you are on the login page, but adhering to the one definition in the Page Object will prevent you from having to maintain the other variants.

Page Objects should be ignorant of an application’s business logic, they should only be aware of page state and how to interact with it. By clearly delineating the test code from the page objects, you will be able to use the same page objects in a variety of tests cases and achieve code re-use.

The Sample Code

The application that we will be using is the Spring Security Contact Example that I deployed locally in a Tomcat 6 container. No modifications of the web archive are necessary.

The first two classes are Page Objects: the Login Page and the Home Page. Both pages validate that the page is currently loaded by checking the current page’s title. A Page Object’s validation code may execute before the page has been loaded in the browser, so we will leverage the WebDriver asynchronous validation mechanism. Both Pages will wait up to thirty seconds, polling every two seconds to see if the expected title is present before giving up. WebDriver used to have a somewhat klunky way of doing this, but the new FluentWait and ExpectedConditions makes this code much more concise and readable.

LoginPage.java

public class LoginPage {

	private final WebDriver driver;

	public LoginPage(WebDriver driver) {
		super();
		this.driver = driver;

		Wait wait = new FluentWait(driver)
	       .withTimeout(30, SECONDS)
	       .pollingEvery(2, SECONDS);

	     wait.until(ExpectedConditions.titleIs("Login"));
	}

	public HomePage loginAs(String username, String password) {

		executeLogin(username, password);
		return new HomePage(driver);
	}

	public void failLoginAs(String username, String password) {
		executeLogin(username, password);
	}

	private void executeLogin(String username, String password) {

		driver.findElement(By.name("j_username")).sendKeys(username);
		driver.findElement(By.name("j_password")).sendKeys(password);
		driver.findElement(By.name("submit")).submit();
	}

	public String getErrorMessage() {

		return driver.findElement(By.xpath("/html/body/p/font[@color='red']")).getText();
	}

}

HomePage.java

public class HomePage {

	private final WebDriver driver;

	private final static Logger logger = LoggerFactory
	.getLogger(HomePage.class);

	public HomePage(WebDriver driver) {
		super();
		this.driver = driver;

		Wait wait = new FluentWait(driver)
	       .withTimeout(30, SECONDS)
	       .pollingEvery(2, SECONDS);

	     wait.until(ExpectedConditions.titleIs("Your Contacts"));

	}

	public String getHomePageWelcomeMessage() throws Exception{

		return driver.findElement(By.xpath("/html/body/h1")).getText();

	}

}

Each Page Object also contains an additional method that checks for the presence or content of an element. The Page Object only locates and retrieves these values. We will let the test case interpret the correctness of these values.

I’ve created a single junit test that will test a successful and unsuccessful login attempt. The test instantiates a Firefox WebDriver to pass to the Page Objects. In a more sophisticated test suite you would inject the WebDriver implementation class to leverage the same test against different browsers. To start each test, we navigate to a protected URI. This should trigger the authentication process and bring the user to the login page. After each test we make an attempt to clean up by accessing the logout URI and cleaning up any session cookies that remain in the browser. Finally, after all of the tests are completed, we gracefully shutdown the WebDriver.

LoginTest.java

public class LoginTest {

	private final static Logger logger = LoggerFactory.getLogger(LoginTest.class);
	private final static WebDriver driver = new FirefoxDriver();
	private final static String hostAndPortAndContext = "http://localhost:8081/spring-security-samples-contacts-3.0.8.CI-20110909.121734-1";
	private final static String securedURI = "/secure/index.htm";
	private final static String logoutURI = "/j_spring_security_logout";

	 @AfterClass public static void afterAllIsSaidAndDone() {
		 driver.quit();
	 }

	@After
	public void after() {
		driver.get(hostAndPortAndContext+logoutURI);
		driver.manage().deleteAllCookies();
	}

	@Before
	public void before() {
		driver.get(hostAndPortAndContext+securedURI);
	}

	@Test
	public void testLogin() throws Exception {

		LoginPage loginPage = new LoginPage(driver);
		HomePage homePage = loginPage.loginAs("rod", "koala");
		assertEquals("rod's Contacts",homePage.getHomePageWelcomeMessage());

	}

	@Test
	public void testFailedLogin() throws Exception {

		LoginPage loginPage = new LoginPage(driver);
		loginPage.failLoginAs("nobody", "WRONG");
		assertTrue(loginPage.getErrorMessage().contains("Reason: Bad credentials."));
	}

}

Running the JUnit test will spawn an instance of Firefox to run the two test cases. The browser will use a unique profile, so your tests will not be affected by your current browser cache or configuration.

Shortcomings of Page Objects and Web Driver

If you change the password of the valid user and re-run the test, you will need to wait the entire duration of the timeout period (currently thirty seconds) before moving onto the next test. This is because the Home Page is only checking to see if the Home Page has loaded, not if the login page is being re-displayed with an error. The problem with this is twofold

• it is unclear as to why a test failed. You are only given a stack trace that indicates the expected Home Page element could not be loaded within the timeout period. But what happened? Was the account locked, was the server not up, or did the application blow up? If you are watching the tests run, the underlying cause of failure may be obvious, but if you are running the tests on a CI server, or executing them remotely with Selenium Grid. it may be difficult to diagnose.
• it takes a long time for the test to fail. If the failure is on a main navigation path (e.g. Login) it will take a long time for all of the tests to fail. Automated test suites that used to take 10 minutes to run on the CI server may now take several hours to complete before you are notified that something is wrong.

Another concern is that we are now coupling page state/interaction with page flow. The Login page executes the same login logic twice, once for failed logins, the other for successful logins. Both methods do the same thing, but have different return types as the expected navigation outcome will be different. So despite our best intentions, the validation of the business logic has leaked into the page objects.

We could code the page flow into a page builder class that can detect unexpected navigation flow. This class could detect a failed user login due to a bad password. But this solution quickly increases the complexity of the code. The tidy one liner check now becomes a complicated check for the presence of a login error message in a try catch block. Using a builder for main navigation flows (e.g. login) may have merit, but it becomes overkill to use as the default pattern.

Such a page builder class would not catch all unexpected navigation errors. Unless you’ve defined custom error pages, the container can also render error pages. These error pages are container specific; Tomcat will generate a different 404 page than Websphere. Browsers can also render error pages. For example, if the browser is unable to connect to a host the browser will render a page indicating the failure. The list of possible unexpected pages is quickly growing.

It would be nice if the actual Driver implementation could identify browser generated error pages. It would also be possible to expose the HTTP Response code to identify server side errors. Unfortunately, it does not appear that this functionality will be appearing in Web Driver any time soon.

It might be difficult to detect errors, but when they happen you can at least get the current content of the page.  This can be done by logging the contents of the frame with driver.getPageSource() or grabbing a screenshot with  getScreenshotAs().  The thought of associating screen shots to a test sound appealing and all of the major drivers (IE, Chrome and Firefox) support the getScreenShotAs method. But it’s difficult to a harvest screenshots for inspection after a remote test run. For the most part, taking a current page source dump should be sufficient to indicate current page state.

Conclusions

Page Objects do a good job of encapsulating the underlying page source, but not as well at modeling navigation flow. Web Driver 2.0 and Selenium are continually improving. Hopefully they will continue to do so by adding some of the missing features.

If you are not yet using PageObjects, consider doing so.  If you are not yet using Selenium, what are you waiting for?

©2012 Summa Blog. All Rights Reserved.

The problem is: time management, even on a small scale is hard. We spend a lot of time learning how to get good at macro time management and very carefully lay out our project priorities for the release and the iteration. But that means little if day to day the developers don’t have a good system to find the right balance of focus on those priorities versus just the right amount of focus on email, meetings, last-minute feature requests, needs from other projects, helping others on the team, etc.

I do not profess to have a solution — I thought I would share three strategies that I have tried over my career (I am sure there have been others).  If you want to try one of these, great! Let me know how it goes! If you have another approach, please share or email!

Cowboy Style

When I first started at Summa, I did not have a system for how to manage my time. I let tasks come in and go out — mostly just remembering what I had promised to get done and when it was due. To help, I would star or label emails and maintain a few lists.  I am organized and careful so this worked out for a while, but it did not take long for the system to start buckling with the weight of what I was asking it to do.

Within my first year, I had a 2 or 3 week period where I was helping out on three different projects — and keeping emails straight was not going to cut it. Thankfully, approach #2 entered my life soon after…

Scrum Method

Scrum is an agile technique for managing teams and projects. It’s goal is not to be prescriptive about anything, let alone my day, but I found that it’s philosophies were having a radical impact on the way I organized myself.

It’s hard to explain how without a deep understanding of what being on a Scrum team feels really feels like. I don’t know who you are — maybe you’ve been on Scrum teams maybe not. I don’t want to teach you the basics, but I do want to explain how they revolutionized my day.

One thing a Scrum team does is have a daily stand-up meeting. During this meeting, each team member announces what they did since the previous stand-up, what they will do before the next, and any impediments in their way. At first, I just went through the motions, but as I understood what it was about, it really started to change things. Here are some important points:

• I talk about what I will do before the next meeting. I was used to saying, “I will continue work on the User DAO.” But my friendly compatriots would not let that slide. The stand-up is about making commitments to the team, and breaking your tasks into day-size (or smaller) chunks. Set a goal for what you will (and can) accomplish before the next meeting. Lofty endless goals do not cut it.
• It is also an exercise in focus. Because I made that commitment to the team, it is that same team I need to face if I have not achieved one of those goals. This is not scary — they understand when it takes longer than expected or I ran into trouble. But if I got distracted by a feature someone stopped in to ask about, or a bug I found, they are there to put me back on track.
• I also now have a list of tasks — done and to do — and I am writing them each day in a growing OneNote list. Each time I run out, I can go back to the Sprint backlog, whether it lives in a spreadsheet or (preferably) Rally to pull out my next story.
• Scrum also gives us a win-win solution to the daily issues that come up. If a last minute defect or request comes up, I used to have to choose between fixing it now (at the expense of my current work and context) or adding it to a list and potentially forgetting it. Now, we can safely add it to the product backlog. While it is outside of the Sprint scope, the product owners know it will be there for them to prioritize at the next Sprint planning and I can continue on developing happily!

Pomodoro Technique

After a handful of years, the Scrum method was still leaving something to be desired. Mainly:

• I would still find myself with days where I had accomplished none or few of my committed tasks
• I would occasionally be thrown back in the Wild West — multiple projects, multiple demands, no backlogs of any kind. Scrum method doesn’t really help you out there.

I was then fortunate enough to hear a lightning talk about the Pomodoro Technique. There are many parts to the technique, but the part that most interested me was the focus on micro-micro time management. Here are some highlights:

• Break down your daily tasks into subtasks that can be performed in ~25 minutes.
• Choose a task and set your pomodoro timer (pictured at the left, looks like a tomato — or pomodoro, in Italian) for 25 mins.
• This is an intensive period. Some pomodoros can be focused on checking email or following up with someone on a debugging problem, but otherwise you disregard all distraction from the task at hand.
• Each second the mechanical timer ticks, reminding you to focus on the task in front of you.
• At 25 mins, the timer rings, and you take a break.

When I heard about it, I was excited. It sounded fantastic. In practice, I find I can only do it in short bursts. I often find the focus amazingly helpful. But it is hard to get much done in 25 mins. Many of my tasks are “continue on from the last task.” The biggest help is that every 25 mins I am reminded of my progress throughout the day, and my progress against my original plan. When I start to veer off course, I can see it early, even when I can’t help it.

©2012 Summa Blog. All Rights Reserved.

In August, Summa was ranked on the Inc 500|5000 list. We were recognized for our sales growth over the past three years of 75%. We were also ranked on the Pittsburgh 100, a list of the fastest-growing, privately held companies in Pittsburgh. In addition to our sales growth, we’ve experienced employee growth of 66%.

Adam Menzies, a Solution Architect at Summa, was recognized by Sheetz at their Annual Vendors Days. Adam was given the “Sheetz IT Vendor of the Year” Award, acknowledging the work he did on several key initiatives for Sheetz.

Last week at the Consol Energy Center, we attended the Pittsburgh Technology Council’s Tech 50 Event, where we were named as a finalist for the Technology Accelerator of the Year.

In October, we will be recognized by the Pittsburgh Business Times as one of the Best Places to Work in Western Pennsylvania. We are thrilled to be named to this list for the fifth year in a row.

As I said, great things are happening at Summa.  It’s been an exciting 15 years and we look forward to all the opportunities ahead.

©2012 Summa Blog. All Rights Reserved.

Well, neither really, faithful reader. Our hero is neither smitten nor inflamed with that finicky ORM. There are still times when he hears of Hibernate arrogantly committing data merely because it felt like it, while other times, he simply joins two tables through a simple line in XML. It’s a slippery slope. Who said true love was easy?

But, friends, today, we gather to praise Hibernate, not to bury it. For today, we will discuss in detail one of the characteristics which truly makes Hibernate a worthwhile comrade. That something is Caching.

Hibernate operates on three levels of caching, First-Level (or Session), Second-Level (or Object), and Query Caching. Each has their own jurisdiction and each has their own advantages. They even work together to provide a powerful and flexible approach to application performance. So, today, we’ll go through each to paint a clearer picture about an area in which Hibernate shines.

But, the Intergoogles is rife with information about caching: how to configure it, how it works, why it’s awesome. I won’t belabor the point. Instead, I will focus on what you need to know about the three levels of caching. I’ll illustrate the Gotchas, the AHA!’s, and the Sha Na Na’s.

I will assume that by now you know what caching is and why it is important. If not, here’s a sentence you can cut out and keep in your wallet or purse the next time your grandmother asks you to explain the benefits of caching (right after she figures out her answering machine):

There, Gramma, that is caching. Caching. CACHING! No, I didn’t sneeze, gramma. No, I’m not sick. [sigh] Yes, I’ll have the chicken soup.

Anyway, now you know what caching is. So, why should you care?

FIRST LEVEL CACHE

First-Level caching in Hibernate is otherwise known as the session cache. What this means is that Hibernate maintains a separate cache of objects as long as the same session is open.

As I mentioned in my last verbose and rambling blog post, this means that:

Session.load(MyObject.class, 123);
// Other logic here
Session.load(MyObject.class, 123);

will produce the same result, but only hit the database once. Hibernate’s first level cache realizes that you’ve already asked for this information in this session so it can merely pull what you retrieved previously. Since this is the same session, then surely nothing has changed. So, why make yet another round trip to the database only to return you information you already have?

But, this is oversimplifying the matter, a practice that is commonplace on the internet when looking for guidance in technology. ‘Just drop the JAR in your classpath and it all just works!’. Sure it does, bud. You forgot to mention I need nine other JARs, three XML files, and the moon must be a waxing gibbous.

To truly understand the first level cache, it is important to understand the duration and lifecycle of a Hibernate session. I think that grasping this is critical to understanding this cache level because inherent in all this is a fundamental question that is integral to all caching approaches, which is the concept of cache invalidation. You need to invalidate data in the cache when the real data in the database changes. I don’t think it takes a rocket scientist to know that even though we are operating within our own session, there could be a multitude of other sessions alive. All of which could be updating the very data sitting in your precious session.

So, how long is this session alive anyway? If it’s open for any substantial length of time, the odds of stale data in the cache grow exponentially. One would hope the session doesn’t live for very long. Good news, it doesn’t.

There is a pattern that Hibernate suggests to make efficient use of the Session Cache called Open Session In View. In a nutshell, this means keeping the session open just long enough to render the view of the JSP. The session is instantiated upon the HTTP request and then destroyed when the view is fully rendered. Not bad, right? So, now that we know how the session cache works and how long the session lives, lets look at some things to keep in mind:

• The Session Cache has no built-in invalidation when data changes

  So, even though it is short-lived, it is still possible that another session has modified the data from the time you first requested it and the time you requested it again. To make matters worse, Open Session In View actually keeps the session open LONGER than usual.

• It could be YOU updating the data behind the scenes

  Wait, what? I’m READING table ABC, but I’m UPDATING XYZ.
  True, smart guy, but remember one of the banes of every developer’s existence: legacy databases. Some of these databases contain business logic nestled deep within the friendly confines of those normalized monsters. So while you think you’re innocently updating table XYZ, there are triggers or procedures going on behind the scenes that are changing table ABC right out from under your nose. I’ve seen it happen.

  

  So, as you can see, a simple update to the BAZBING table caused the evil, repugnant database business logic to fire off some legacy code which updated the FOOBAR table. Now, your cache says you have five FooBars, when in reality, you just inadvertently removed one.

• Isolation Level and Performance

  Part of administrating the Hibernate session involves tying it to a transaction manager. However, one thing to keep in mind is that the behavior of the session cache depends on the isolation level used in that underlying connection. The more conservative the isolation level, the highest impact on performance since the chances and implications of locking become more prevalent.

  For example, using an isolation level of serializable (which is default on some databases) prevents all database anomalies such as repeatable reads and phantom reads because it locks all tables within the transaction. As a result, performance will be greatly impacted. Using a less- strict isolation level such as READ UNCOMMITTED will improve performance, but will in turn open up your database transactions to see uncommitted changes. It is a difficult balance sometimes between performance and protection.

SECOND LEVEL CACHE

The second level cache has a more broad scope and is one that can greatly improve performance in applications. It has a few differences.

1. It can live across sessions
2. It can be distributed
3. It is not managed internally by Hibernate. Instead, you have the ability to define a cache provider

These points are all very important for one main reason: because the data can now be distributed and can live across sessions, you have to be very careful about what is cached and how long that data stays cached. Further, you now have to integrate another cache provider into Hibernate’s inner sanctum to help you do so.

So now we have data that is living across sessions. Other servers, other users can all benefit from this cache rather than the selfish, session cache. The problem is that by doing this, your sheltered world just got more complicated.

The second level cache is also known as the object cache, but it doesn’t actually store the instances of the objects. Instead it stores the values for the members of the object with an identifier as the key in the cache. So, for example, let’s suppose we have the following table:

TEACHER

ID	NAME	SUBJECT
123	Mr. Garrison	English
456	Mr. Mackey	Math

The second level cache will store cached data as:

{123, [Mr. Garrison, English]}
{456, [Mr. Mackey, Math]}

So, asking for teacher 456 will simply use that ID to pull from the cache. Now suppose we also have this table:

STUDENT

ID	NAME	TEACHER (FK)	GRADE
2009	Stan	123	5
2010	Kyle	456	5
2011	Eric	456	5
2012	Kenny	123	5

Now, things get a bit more involved. There is a one-to-many relationship now of teacher to student. Your persistence-mapping file will most likely have three mappings to show this relationship:

1. The Teacher class
2. The one-to-many relationship in the Teacher mapping to a set of Students, using Teacher ID as the key
3. The Student class

Now, the reason I bring this up is related to my first item of interest for the second level cache:

• Caching Hibernate Associations

  In the above scenario, you will have the ability to cache the Teacher mapping as well as the Teacher relationship to Student. So, in that instance, two caches will be created to store the Teacher info as well as the IDs of the Students to which it’s related:

  Teacher Cache
{123, [Mr. Garrison, English]}
{456, [Mr. Mackey, Math]}

  Teacher.student Cache
{123, [2009, 2012]}
{456, [2010, 2011]}

  Ah, but here’s the rub. Assuming the relationship between teacher and student is a typical fetch of ‘select’, you would expect then, that the following code would only run two queries: one for the teachers and one for the students and then only upon the first invocation of ‘load’.

  Session.load(Teacher.class, 456);
Session.clear();
Session.load(Teacher.class, 456);

  Instead, it runs 3 queries: two for the students and teachers in the first invocation and then one for the students in the second. Adding another call to Session.load will run yet another query and so on.

  This is because you also have to cache the Student mapping. What the cache logic does is as follows:

1. Check the Teacher cache. If ID exists, get the info.
2. Check the Teacher.student cache. If Teacher ID exists, get the Student IDs related to it
3. Retrieve the Students based on IDs

Since there is no Student cache, a retrieval is done for Student info every time. So, to cache associations, make sure you cache the parent class, the relationship, and the child class (even if the child class is never explicitly retrieved on its own)

• Not every Hibernate method invokes the cache

  One would think that any retrieval for an object would invoke the second-level cache. One would think. That is not the case, however. It turns out that it’s specific to the method you are using to retrieve your data. For example:

  Session.load(Teacher.class, 456)
Session.get(Teacher.class, 456)

  Will both cause Hibernate to check the second level cache first for any existence of those IDs. However doing something like the following will not:

  Criteria crit = session.createCriteria(Teacher.class)
crit.add(Restrictions.eq(“name”, “Mr. Garrison”);
crit.list();

  Because you are using a criteria object and querying for a list, Hibernate will not first check the second level cache for the existence of your objects. OK, that sort of makes sense. But what about these?

  Crit.add(Restrictions.eq(“id”, 456L);
Critieria.list();

  OR

  Crit.add(Restrictions.eq(“id”, 456L);
Critieria.uniqueResult();

  I am querying by the ID in both examples. Plus, in the second one, I’m even asking for a unique result. Will Hibernate at least check the cache on the second snippet? Nope. In both, though, the cache will be populated, which is important because this means more memory being utilized for no real purpose.

The takeaway here is that not only do certain methods not invoke the cache, but certain approaches to retrieval also do not. More specifically, retrievals by a parameter other than the ID of the record will not check the second level cache. This means that retrieving a codes table by the code name repeatedly will not get any better if you decide to cache it. Since you are retrieving by name and not the designated ID, the second-level cache does not come into play. Remember, in our teacher-student example, the keys in the cache were the IDs. Likewise with the associations.
So, how can we always guarantee a retrieval by ID so that we can make use of the second-level cache? Is there a way to dummy that up? Glad you asked. And don’t call me a dummy.

QUERY CACHE

The query cache is the third style of caching at your disposal. Think of this one as Robin the Boy Wonder of caching. By itself, it’s sort of useless. However, with the second-level cache, it becomes a worthy companion and trusted sidekick.

What the query cache stores is basically a where clause and its bound parameters as a key, which is paired to the IDs that said where clause returns. For example:

{[‘Where Teacher.Name = ?’, ‘Mr. Garrison’], 123}
{[‘Where Teacher.Name = ?’, ‘Mr. Mackey], 456}

As you can see, it is sort of useless by itself. The query cache provides you means to an end. It is a powerful complement to the second-level cache when IDs are not used for retrieval.
The query cache also requires a high amount of analysis before just using willy-nilly. There are many points to consider when making use of it. Alex Miller wrote a great blog post on whether query caching is a good idea. So, check it out if you’re interested. If not, I’ll sum up some points of his here as well as one I’ve come across in my experiences:

• The query cache can get big

  Take a gander at the above example I wrote of the query cache. Look at how verbose it looks already. Now realize that this is my dopey scenario with ONE column in our where clause and one parameter. Obviously, queries and where clauses can get to be enormous. Query caching these behemoths will result in all that information just sitting around in memory. So, while you’re making every effort to improve performance, you’re actually jamming a lot more into memory.

• On frequently updated tables, the query cache is worthless

  The query cache is managed by the caching provider through the use of a separate cache called the UpdateTimestampsCache. The UpdateTimestampsCache maintains the last updated timestamp of particular tables. When a table is updated or inserted, the last updated value is modified for that table in the timestamp cache. Any entries in the query cache that correspond to that table are then invalidated. Put simply, if the table you are caching in the query cache is updated or inserted FOR ANY REASON, your cache entry will become invalidated. This means that updates or inserts completely unrelated to you or your data can still invalidate your entries.

  So, caching tables that are updating frequently in the system in the query cache is generally not a good idea. The entries will become invalidated quite often, resulting in cache misses constantly.

• Query caching is ineffective on frequently changing parameters in Hibernate queries

  As you see in my example, the key to the query cache is composed of the where clause itself as well as the values of the bound parameters. The astute programmer will realize that if either of these changes, we have a new entry in the cache. In our example, the information is static, but suppose you have this:

  {[‘Where Teacher.ModificationDate < ?’, (some long representing a date)], 123}

  Now suppose the query is invoked by passing in the current system time in milliseconds. Since obviously the current time changes every (wait for it) millisecond, each repeated invocation of this query will result in a new parameter being passed in for Teacher.ModificationDate. This means that there will be a cache miss each time this query is run, which will subsequently result in ANOTHER cache entry being created. So, taking the first point about verbosity and this point into consideration, imagine an enormous where clause in which a constantly-changing parameter is passed in, such as the current time. We will have unintended cache misses, resulting in unintended extraneous cache entries, which further results in an insane amount of data in memory.

So, that is caching as far as my on-again, off-again love Hibernate is concerned. The number one thing to take away from this post is to always consider the inherent implications. On the surface, the three levels of caching that Hibernate provides are very powerful and are a useful way to improve performance. But, deep down in the seedy underbelly lurk caveats at every turn. Caching is not an easy process to manage or to even understand. Just ask your grandmother. And remember to eat the chicken soup.

©2012 Summa Blog. All Rights Reserved.

.]]> http://www.summa-tech.com/blog/2011/09/12/chicken-soup-for-the-caching-soul/feed/ http://www.summa-tech.com/blog/2011/09/12/chicken-soup-for-the-caching-soul/ http://feedproxy.google.com/~r/summa-tech/LoQU/~3/LWfKn5sG3gM/ http://www.summa-tech.com/blog/2011/09/06/five-oracle-functions-you-might-find-useful/#comments Tue, 06 Sep 2011 18:18:24 +0000 Prem Nagrath http://www.summa-tech.com/blog/?p=3613 DDL, CRUD operations and occasional SQL tuning. So when I recently got a chance to use some not-so-common Oracle functions/statements in a data-migration project, I thought they might be worth sharing. ]]> Most of an enterprise application developer’s exposure to the database is primarily restricted to basic DDL, CRUD operations and occasional SQL tuning. So when I recently got a chance to use some not-so-common Oracle functions/statements in a data-migration project, I thought they might be worth sharing. Here they are:

1. Merge

Also referred to as UPSERT, this Oracle PL/SQL statement can be used when it is not sure if you need to make an update or insert into the table. With Merge statement, you can insert into a table when the row does not exist or update it if it does. The syntax is:

MERGE 
INTO

USING

ON ( )
WHEN MATCHED THEN 
WHEN NOT MATCHED THEN 

So, the following Merge statement will add 1000 dollars to pending payment to the employee, if there is a payment already due for that employee in the Pending_Payments table. And if there is no payment due to the employee, it will create one for 1000 dollars for him/her.

Merge into PENDING_PAYMENTS p
using (select employee_id from employee) e
on (e.employee_id = p.employee_id)
When Matched then
  update set p.payment_due = p.payment_due + 1000
When not matched
  then insert (p.employee_id, p.amount)
  values (e.employee_id, 1000);

2. Delete multiple rows from a table that has a composite primary key

This is a bit confusing and I will try my best to explain it with an example. Assume, you have two tables and you have to delete multiple rows from one of them using data from the other. So that is easy and the SQL statement would be:

Delete from A
where id in (select a_id from B where )

Now assume table A has a composite primary key and we have to achieve the same result. Would the following work?

Delete from A where id_col1 in
  (select a_id_col1 from B where )
and id_col2 in
  (select a_id_col2 from B where )

No, but the desired result could be achieved with following statement:

Delete from A where (id_col1, id_col2)
in (select a_id_col1, a_id_col2 from B where id in ( ))

3. Minus Vs. “not in”

Even though following statements give the same result, Oracle processes them differently:

Select col1 from table1
minus select col1 from table2
select col1 from table1
where col1 not in (select col1 from table2)

Minus does a full scan on both tables and removes the result from table2 from table1. “not in”, however, compares each row from table1 result with result from table2, resulting in far more reads than minus. So in most cases, it is preferred to use minus over “not in” for this performance reason.

4. NVL

The NVL function is used to substitute null values with a value. The following query would substiute a null middle_name with the literal ‘not available’ in the result rows:

Select first_name,
  NVL(middle_name, ‘not availabale’),
  last_name from employee

5. Decode

The decode is like an “if-then-else” statement, and the syntax is:

decode(expression, search, result [,search, result]….[,default])

So following statement would add an appropriate honorific while giving out the full names of all the employees.

Select decode (gender, ‘M’, ‘Mr.’, ‘F’, ‘Ms.’)
  || ‘ ‘ || full_name from employee

©2012 Summa Blog. All Rights Reserved.

.]]> http://www.summa-tech.com/blog/2011/09/06/five-oracle-functions-you-might-find-useful/feed/ http://www.summa-tech.com/blog/2011/09/06/five-oracle-functions-you-might-find-useful/ http://feedproxy.google.com/~r/summa-tech/LoQU/~3/RgtnNUJcYfw/ http://www.summa-tech.com/blog/2011/07/29/setting-up-sequential-ids-using-jpa-tablegenerator/#comments Fri, 29 Jul 2011 18:24:43 +0000 Mitch Goldstein http://www.summa-tech.com/blog/?p=3483 @TableGenerator annotation is used to facilitate this feature.]]> Introduction

When using the Java Persistence Architecture (JPA) to perform object-relational mapping, it can become difficult to manage entities with complex keys.  Having a unique identifier is a keystone of the mapping approach, and complex keys can make coding awkward and difficult.  An alternative is to create entities with sequential unique numeric keys, and use the capabilities of the query facility to identify unique entities within the relational store.

JPA has several techniques to generate unique keys for entity objects.  This article focuses on one technique: using a database table to keep track of an incremental ID.  The @TableGenerator annotation is used to facilitate this feature.

Database Setup

In order to use @TableGenerator, we will need a database table that is accessible by JPA. Here is a sample script of how to create such a table in SQLServer:

CREATE TABLE dbo.SEQUENCES (
	SEQ_NAME char(10) NOT NULL,
	SEQ_NUMBER int NOT NULL
) ON [PRIMARY]
GO

This will create a table called dbo.SEQUENCES in your current database with two columns:

• The first column is a sequence name and can be used to manage multiple sequences within your object architecture. In most cases, a single sequence can be used to create incremental unique keys for all entities.
• The second column is the sequence number itself. It is vitally important that this value not be externally editable or modified in any way.  If this value is changed, you might find yourself in a situation where you inadvertently re-use ID numbers, and this can wreak havoc in your code, especially if the generated ID is the primary key of your entity.

You will need to insert at least one row into this table to make it useful. We will assume a single generator will be used for all key values:

INSERT INTO dbo.SEQUENCES (SEQ_NAME, SEQ_NUMBER)
        VALUES('SEQUENCE', 100)
GO

This will create a sequence name of ‘SEQUENCE’ with an initial value of 100. The sequence name is used in the annotation to identify which value is to be used if there are multiple sequences being maintained. Lastly, we will create a table to map a simple entity:

CREATE TABLE dbo.EVENTS(
	[ID] int NOT NULL,
	[DESCRIPTION] varchar(200) NOT NULL,
        CONSTRAINT [PK_PRICING_EVENTS] PRIMARY KEY CLUSTERED
        ( [ID] ASC )    /* make ID the primary key */
) ON [PRIMARY]
GO

Creating the Mapping

Now we can create our mapping in our Java class. We will create an entity mapping and use field mapping for it’s two properties. The first one will be mapped as the unique ID and the second as the value of the DESCRIPTION column in the table we have created.

@Entity
@Table(name = "EVENTS")
public class SequentialEvent implements Serializable
{
    private static final long serialVersionUID = 3107897896655094094L;

     @Id
     @TableGenerator(name = "EVENT_GEN",
                table = "SEQUENCES",
		pkColumnName = "SEQ_NAME",
                valueColumnName = "SEQ_NUMBER",
		pkColumnValue = "SEQUENCE",
                allocationSize=1)
    @GeneratedValue(strategy = GenerationType.TABLE, generator = "EVENT_GEN")
    @Column(name = "ID")
    protected int _id;
    @Column(name = "DESCRIPTION")
    protected String _description;

    // REMAINDER OF CLASS OMITTED
}

Here is an explanation of the annotations in this class:

• @Entity - marks this class as a JPA persistable entity
• @Table - denotes the name of the table in which this entity is stored
• @Id - declares the field it refers to as the unique identifier for this entity
• @TableGenerator - informs JPA how to generate unique values for this entity’s identifier.  It has several parameters:
  • name - identifier for the generator binding. This value must match the parameter in the @GeneratedValue annotation as described below.
  • table - must match the name of the table created to store the sequence values.
  • pkColumnName - the primary key column name that contains the name of the sequence we are using.
  • valueColumnName - the name of the column that contains the numeric sequence value
  • pkColumnValue - the value of the primary key column that identifies the sequence
  • allocationSize - the amount by which this sequence should be incremented each time a new entity is created.  The default value for this is fifty (50).
• @GeneratedValue - marks the field as having a generated value, either from the database or from some other ID generation strategy.  This has two important parameters:
  • strategy - a value from the GenerationType enumeration that declares the the way in which values will be generated.  In this example GenerationType.TABLE is appropriate since we are letting the value be managed in the relational store.
  • generator- must match the name of the @TableGenerator tag to provide the specifics on how the value is to be generated.
• @Column - declares the field to be mapped to a database column.

It is important to note that when employing this particular strategy, the ID of the entity that you are creating will be undefined until the object is persisted.  This must be a consideration when determining how to architect your application code.

For more information on @TableGenerator and other key generation techniques, please refer to JPA documentation.

©2012 Summa Blog. All Rights Reserved.

.]]> http://www.summa-tech.com/blog/2011/07/29/setting-up-sequential-ids-using-jpa-tablegenerator/feed/ http://www.summa-tech.com/blog/2011/07/29/setting-up-sequential-ids-using-jpa-tablegenerator/ http://feedproxy.google.com/~r/summa-tech/LoQU/~3/DcZGgarbZhk/ http://www.summa-tech.com/blog/2011/07/25/reference-data-in-the-application-tier/#comments Mon, 25 Jul 2011 17:34:19 +0000 Ben Northrop http://www.summa-tech.com/blog/?p=3497 reference data - those simple entities that live on the periphery of your data model, and are used to classify your master data. We often know these entities by other names (depending on our point of view), for instance "lookup tables", "configuration data", etc. - examples being "State", "CustomerType", or "ProductType". Now there are some strong reasons to model these entities in separate tables in your relational database, and there is generally not much debate here. Where things get a little tricky is when this reference data propagates up into the application tier. In my experience, developers employ a number of different strategies to solve this problem, and so in this post I'll define some of the more popular approaches and describe the pros and cons of each. As always, I'd love to hear your thoughts, so please share. Here goes...]]> In every enterprise application, there exists reference data - those simple entities that live on the periphery of your data model, and are used to classify your master data. We often know these entities by other names (depending on our point of view), for instance “lookup tables”, “configuration data”, etc. - examples being “State”, “CustomerType”, or “ProductType”.

Now there are some strong reasons to model these entities in separate tables in your relational database, and there is generally not much debate here. Where things get a little tricky is when this reference data propagates up into the application tier. In my experience, developers employ a number of different strategies to solve this problem, and so in this post I’ll define some of the more popular approaches and describe the pros and cons of each. As always, I’d love to hear your thoughts, so please share. Here goes…

Types of Reference Data

Let’s first start with an example. Imagine your system has customers, and every customer has some loyalty level (e.g. “Gold”, “Silver”, etc.”). The tables could be designed simply as follows:









…and the data in the LOYALTY_LEVEL table might be…




id	name
G	Gold
S	Silver
B	Bronze




This is a pretty vanilla example, so it would be tempting to jump right in and translate this into the application tier, but before we do it’s important to stop and ask a few questions first:

1. Does the reference data need to be retrieved independent of the master data (e.g. display all loyalty levels in a drop-down, etc.)?
2. Are there other attributes beyond just the normal id-name pair? For example, “description”, “abbreviation”, or something with more business meaning like “percentage discount”, etc.?
3. Do specific values need to be hard-coded into the business logic? For example, could there be logic if (cust.loyaltyLevel == "Gold") { sendOvernightMail() } …or something similar?
4. Is the reference data at all dynamic? For example, could there be a new loyalty level at some point (e.g. “Diamond” or maybe “Coal”!)? Further, is this reference data very dynamic in that it could be added by a user via some UI, or would a new value be a configuration change?

Now I can hear the objections already: “hey, not all of these types of ‘reference data’ are really reference data!”. And that’s actually the point. Oftentimes, in my experience, we fail to appreciate these four distinctions, and we shoe-horn all entities that even roughly resemble reference data into the same solution, to sometimes pernicious consequences. For example, we may treat States the same as Loyalty Levels in the application tier, even though the former is probably static, not used in business logic, and will only ever have two-attributes, while the latter could be the exact opposite.

To best understand how to design for different types of reference data, it’s helpful to lay out a few common solutions…

1. Flatten in Model Class

An unsophisticated (but not uncommon) approach is to flatten the reference data in the containing model object. For example, the customer class could look like this:

  public class Customer {
    private String name;
    private String loyaltyCode;
    private String loyaltyName;  // optional
  }

Obviously this will work, until a new attribute needs to be added to a Loyalty Level (e.g. “description”)…or Loyalty Codes need to be retrieved independent of Customers (e.g. to populate some drop-down), in which case you’ll probably want to define a…

2. Custom Class

A custom LoyaltyLevel class could be created with the two attributes “code” and “name”…

  public class LoyaltyLevel {
    private String code;
    private String name;
  }

…and then composed within the Customer class:

  public class Customer {
    private String name;
    private LoyaltyLevel level;
  }

On the up side, the LoyaltyLevel class could be fetched independent of Customers (e.g. to populate a drop-down, etc.), and attributes could easily be added to the LoyaltyLevel class without adding unnecessary bloat to the Customer class.

The problem comes when you want to create some business logic that refers to some specific loyalty level. Using the example above, it’s possible that some business rule should be written such that customers at the “Gold” level are treated in special manner.

  if("G".equals(customer.getLoyaltyLevel().getCode())) {
    sendOvernightMail();
  }
  else {
    sendViaHorseAndBuggy();
  }

Again, this works, but there are a few problems. First, the “code” attribute in LoyaltyLevel is not type-safe, since it’s just a String in the LoyaltyLevel class, and so there’s not guarantee that an invalid value (e.g. “X”) couldn’t creep in. Second, we’re hard-coding the level, “G”, into our business logic, and while this could be ameliorated with a simple String constant, again, this is not type-safe (and a general anti-pattern). And finally, it’s very easy to forget to write bugs where “G” is compared with the LoyaltyLevel object itself and not it’s String code. For example:

  if("G".equals(customer.getLoyaltyLevel()) { // forgot .getCode()!
    sendOvernightMail()
  }

In other words, if specific LoyaltyLevels are to be used in the business logic, it’s much preferable to keep them typesafe in an…

3. Enum

A LoyaltyLevel enum could be created in the application tier:

  public enum LoyaltyLevel {
    Gold("G", "Gold"),
    Silver("S", "Silver"),
    Bronze("B", "Bronze");

    ...
  }

…and a type handler construct in your ORM tool (like Hibernate’s or IBatis, etc.) can be used to easily load this into the Customer object on retrieval from the database:

  public class Customer {
    private String name;
    private LoyaltyLevel level;
  }

Voila! This solves our problems, right? LoyaltyLevels can be retrieved independent of Customers, new attributes can be easily added without affecting the master data, and specific instances can be easily (and type-safely) referred to in business logic (e.g. “LoyaltyLevel.Gold == cust.getLoyaltyLevel()”).

Not so fast! What happens when the business wants to add a “Diamond” level? Or wants to get rid of their “Bronze” level and replace it with an “Aluminum”? In either case, both the enum and the database need to change (since both redundantly define the Loyalty Levels), which obviously necessitates a code/configuration change (i.e. not something that could happen via some UI). In cases where the reference data is very static, this may be fine, but if Loyalty Levels are to be added with any fluidity, encapsulating the different values in Enums won’t work.

Analysis and Recommendations

So I’ve presented 3 solutions, and as the table below shows, each solution has its drawbacks. Things are less clear now than before! What gives?




	Independent?	+2 Attributes?	Business Logic?	Dynamic?
1. Flatten in Model Class	Bad	Bad	Bad	Good
2. Custom Class	Good	Good	Bad	Good
3. Enum	Good	Bad	Good	Bad




In the end, is there an good answer? Well, I’ve found the following two heuristics to be helpful:

1. If the reference data is static, has few attributes, and is used in business logic, use an Enum. The redundancy of reference data defined both in both an enum and a table in the database is relatively harmless (since the data is static!), and worth the cost for gaining the benefit of type safety, clarity, and ease of use (in my opinion).

2. In all other cases, use a Custom Class. In cases where the business logic seems to reference a specific value, rather than hard-code (e.g. “G”.equals(code)), try to refactor this such that the data makes the decision rather than the code. For example, in the example of Loyalty Levels and shipping methods, a new column added to the Loyalty Level table…

id	name	ship_overnight
G	Gold	true
S	Silver	false
B	Bronze	false

…and this would effectively eliminate the dependency on a specific reference data value in the code and move it to the database.

3. If you absolutely need to hard-code the “code” values of the reference data for business logic, then do so with constants in one place and as close to the reference data class as possible (preferably in it). Do not sprinkle hard-coded values (e.g. “G”, “S”, etc.) around your business logic. (I know…duh!)

Anyway, I’d love to hear your thoughts. Am I missing something? How do you manage reference data in the application tier?

©2012 Summa Blog. All Rights Reserved.

.]]> http://www.summa-tech.com/blog/2011/07/25/reference-data-in-the-application-tier/feed/ http://www.summa-tech.com/blog/2011/07/25/reference-data-in-the-application-tier/ http://feedproxy.google.com/~r/summa-tech/LoQU/~3/XVxY8xz_av4/ http://www.summa-tech.com/blog/2011/06/29/mvp4g-multiple-presenters-part-3/#comments Wed, 29 Jun 2011 16:58:16 +0000 Javier Ochoa http://www.summa-tech.com/blog/?p=3449 part 1 and part 2). In this post I will demonstrate how to use the GWT generator to differentiate events that are to be filtered by an event group. This gives you more freedom when defining your events and gets rid of the "$" that we used to define the event name. Plus in this post I will also remove the presenter registry and enhance the event filtering by overriding the isActivated() method. ]]> This entry is part 9 of 9 in the series Developing GWT Applications

This is the third in the Mvp4g Multiple Presenters series (part 1 and part 2). In this post I will demonstrate how to use the GWT generator to differentiate events that are to be filtered by an event group. This gives you more freedom when defining your events and gets rid of the “$” that we used to define the event name. Plus in this post I will also remove the presenter registry and enhance the event filtering by overriding the isActivated() method.

So here are the steps I’ll be following:

1. Split the event bus interface by moving the event group methods to a different compile unit: GroupEventBus.
2. Define the GWT generator which will read and add the methods defined in the GroupEventBus interface to create the list of group events.
3. Remove the event registry from PresenterHandler and override the isActivated method to filter the event for specific presenters.

Split EventBus interface

All we need to do is move the “setSelectedItem$” method from MultiPresentersEventBus to a new interface GroupEventBus:

public interface GroupEventBus {
	@Event(handlers = ReceiverPresenter.class)
	void setSelectedItem(String group, String value);
}

And have MultiPresentersEventBus extend GroupEventBus to include the methods as events in our event bus:

public interface MultiPresentersEventBus extends EventBus, GroupEventBus {
...
}

Write GWT generator

Reflection does not exist in Javascript, but the way to overcome this in GWT is by using Generators. My goal here is to have a new class that extends List and will contain a simple constructor with a list of “add(”xyz”);” calls for each and every event found in the new GroupEventBus. Make sense?

a. Ok, first we write an empty marker interface that we later can call GWT.create on.

public interface GroupEventList extends List<String>{
}

b. Next we write the generator class that extends Generator and carefully generates every single line needed to create GroupEventListImpl class. To keep my post short look here for the source.

c. Now in our GWT module we specify that this Generator is used to get the implementation of GroupEventList.

<generate-with class="com.summatech.gwt.mvp.server.util.GroupEventListGenerator">
  <when-type-assignable class="com.summatech.gwt.mvp.client.GroupEventList" />
</generate-with>

d. And as last point rework our MultiPresentersEventFilter to instantiate our newly created class and get a hold on the Group Event List.

    /** Get the list of grouped events from the generated GroupEventList class */
    private List<String> groupedEvents = GWT.create(GroupEventList.class);

and re-write our logic in the event filter to use this list:

public boolean filterEvent(String eventName, Object[] params, MultiPresentersEventBus eventBus) {
  // Deactivate presenters registered for a group in the list
  if (groupedEvents.contains(eventName)) {
    presenterHandler.activateGroup((String) params[0]);
  }
  return true;
}

Remove presenter registry using isActivated method

And the last change to our project is to get rid of our Map of presenters created in the PresenterHandler singleton. Instead we use a method from Mvp4g which gets called on every event triggered to find out if the presenter is active and if so forward the event. This method returns a boolean, and all we need to do is overwrite it and check whether the presenter is in the “active” event group.

First we get rid of the map registry in Presenter handler and modify the activateGroup method to simply register the current active group and its public getter:

public void activateGroup(String groupToActivate) {
    this.activeEventGroup=groupToActivate;
}

public String getActiveEventGroup(){
    return activeEventGroup;
}

Now we go back to the AbstractGroupPresenter from which our multiple presenters are extending and override the isActivated method as this:

@Override
public boolean isActivated(boolean passive) {
  if (group!=null && !group.equals("")) {
    return group.equals(presenterHandler.getActiveEventGroup()) && super.isActivated(passive);
  } else {
    return super.isActivated(passive);
  }
}

and use Guice to inject the PresenterHandler singleton:

  @Inject
  PresenterHandler presenterHandler;

And this is it. The same magic as in the previous post still happens but with cleaner and more optimized code. Neat, isn’t it? I really think this is a good use of the GWT generator and a good way of using Mvp4g to accomodate this use case of multiple presenters.

Now, in Mvp4g 1.4.0 I believe will have the isActivated method with the event name and event parameters in which case you can now think of a different way to access the triggered event group and get rid of the Event Filter altogether. That might be subject for an extra post in this series if time and energy permits.

I migrated my code to this new repository, feel free to check it out and play with it.

©2012 Summa Blog. All Rights Reserved.

.]]> http://www.summa-tech.com/blog/2011/06/29/mvp4g-multiple-presenters-part-3/feed/ http://www.summa-tech.com/blog/2011/06/29/mvp4g-multiple-presenters-part-3/ http://feedproxy.google.com/~r/summa-tech/LoQU/~3/fQfBj_Gpzek/ http://www.summa-tech.com/blog/2011/06/13/tweaking-persistence-with-prepersist/#comments Mon, 13 Jun 2011 14:00:06 +0000 Mitch Goldstein http://www.summa-tech.com/blog/?p=3433 double type has plenty of precision, math operations using this type can prove problematic when it comes to using them for precision calculations.  Due to the nature of how floating point numbers are stored, they are by definition inaccurate.  This is a consequence of trying to store decimals - especially fractional decimals - in a binary format. To address some of these issues, the Java development team released the java.math.BigDecimal class.  This is an immutable class that extends the abstract class java.lang.Number, which serves as the superclass of  the primitive wrapper classes such as java.lang.Double and java.lang.Integer.  The primary purpose of this base class is to provide methods that allow conversion among different number types. ]]> It is an interesting problem: even though the Java primitive double type has plenty of precision, math operations using this type can prove problematic when it comes to using them for precision calculations.  Due to the nature of how floating point numbers are stored, they are by definition inaccurate.  This is a consequence of trying to store decimals - especially fractional decimals - in a binary format.

To address some of these issues, the Java development team released the java.math.BigDecimal class.  This is an immutable class that extends the abstract class java.lang.Number, which serves as the superclass of  the primitive wrapper classes such as java.lang.Double and java.lang.Integer.  The primary purpose of this base class is to provide methods that allow conversion among different number types.

BigDecimal is supported by the Java Persistence API (JPA), which uses Java Annotations to integrate Java objects with relational entities.  This makes BigDecimal very tempting to use in lieu of floating-point primitives, since the JPA code, in conjunction with the JDBC driver, automatically converts persisted numeric values to BigDecimal when they are mapped to numeric table columns.  However, this can be problematic depending on the type of database you happen to be connecting to.

The Problem

I encountered a problem where an object I wanted to persist was throwing a JDBC exception.  It turned out that the problem was caused by the way the JDBC driver handles BigDecimal properties. This code illustrates this peculiarity:

BigDecimal bd = new BigDecimal(48.28);
System.out.println("toString()    = " + bd.toString());
System.out.println("doubleValue() = " + bd.doubleValue());


Output:
toString()    = 48.280000000000001136868377216160297393798828125
doubleValue() = 48.28

Was this what you might have expected? It looks like the interpretation of the value is correct, but the string representation seems to have several decimal places of precision followed by random junk! Little did I know that this would wreak havoc in my code. Apparently, my JDBC driver converts the value to a string, which can usually, but not always, be digested. I would get a sporadic exception such as this when I tried to persist this data:

JDBCExceptionReporter:234 - Error converting data type nvarchar to decimal.

So what is the problem? Here we have a monetary value with two decimal places of precision.  We want to use BigDecimal to eliminate rounding errors, and we can’t get it into the database?

The Solution

Regrettably, we don’t have control over the internal workings of JPA or the associated JDBC drivers, so we have to work with what we have. What we really need to do is to figure out how to modify the precision of the BigDecimal so it still behaves the way we want, but doesn’t cause the code in the driver to break.

Since BigDecimal is  immutable, we really can’t fiddle with the values themselves.  Much like the analogous String class, operations which alter values all return a fresh String object with the desired changes.  There are operations that can be used to adjust the scale of the BigDecimal so that its raw string representation is not quite so cumbersome.
BigDecimal bd = new BigDecimal(48.28);
bd = bd.setScale(10, RoundingMode.HALF_EVEN);
System.out.println("toString() = " + bd.toString());
System.out.println("doubleValue() = " + bd.doubleValue());


Output:
toString()    = 48.2800000000
doubleValue() = 48.28

Even so - if you are using JPA to it’s fullest extent, it is quite likely that your mappings are applied not to your class’s methods, but directly to a class field, such as this declaration:
@Column (name = "PRICE")
protected BigDecimal _price;
This basically means you cannot ‘trap’ the update of this field in a method call when JPA uses reflection to update this value - how can we ensure our values are persistable if we can’t interrupt the persistance process?

The @PrePersist Annotation

The developers of JPA anticipated this issue and provided a very useful way to invoke code when an object is just about to be persisted. Using reflection, the persistence engine will look for any methods within the entity that is annotated with the @PrePersist annotation.  This provides an excellent hook to either examine or modify entity values before they are persisted by JPA.  In the case of the ‘price’ field above, we could add a method to tweak the value of the price to a more reasonable value before we try to insert the value in a table.

    @PrePersist
    protected void prePersist()
    {
        _price = _price.setScale(10, RoundingMode.HALF_EVEN);
    }

This method will get invoked just prior to our object getting persisted, and will replace the ‘price’ value with its equivalent value, adjusting it’s scale so that it is still very precise, but will not cause problems due to string length when it is persisted to a relational store.

The second parameter of the setScale() method gives the rounding strategy that is used for the conversion.  Any time the scale of a BigDecimal is modified, the user must provide the rule by which the scale will be reduced.  Here I chose the ‘half-even’ method, which is also the one used by applications that support numeric analysis (such as Excel) since it provides a more even distribution of discrepancies over larger sets of data.  For more information, have a look at the documentation for the java.math.RoundingMode enumeration.

Further study of the Java Persistence API will uncover many other ‘callback’ annotations that can be used to provide finer control over entity life-cycle without having to write large amounts of custom code.

©2012 Summa Blog. All Rights Reserved.

.]]> http://www.summa-tech.com/blog/2011/06/13/tweaking-persistence-with-prepersist/feed/ http://www.summa-tech.com/blog/2011/06/13/tweaking-persistence-with-prepersist/ http://feedproxy.google.com/~r/summa-tech/LoQU/~3/Pv2eTNURxfQ/ http://www.summa-tech.com/blog/2011/06/07/dr-mindbender-or-how-i-learned-to-stop-worrying-and-love-hibernate/#comments Tue, 07 Jun 2011 11:51:08 +0000 Steve Ayers http://www.summa-tech.com/blog/?p=3414 Hibernate. I told everyone that would listen what my opinions were. ‘It only gets in the way’, I said. ‘Its too much of a black box’. And while some of those notions still hold true, I am here today to admit I was wrong in that Hibernate is not a total obstacle of a framework. In the right situations and circumstances, it actually is very nice to have on your side. In the wrong situations, however, it is a nightmare. It is not something that can be forcefed into every situation and while it has its benefits, using it in the wrong project will provide nothing but heartache. Trust me, I know from experience. It is the Dr. Mindbender of frameworks: use it where it should be and it’s a peace-loving orthodontist. Misuse it and you have a hateful, deceitful villain with a proclivity for cybernetics and brain-scrambling. ]]> I’ll admit I was wrong.

For years, I have been beating the drum about town, proselytizing my distaste for Hibernate. I told everyone that would listen what my opinions were. ‘It only gets in the way’, I said. ‘Its too much of a black box’.

And while some of those notions still hold true, I am here today to admit I was wrong in that Hibernate is not a total obstacle of a framework. In the right situations and circumstances, it actually is very nice to have on your side. In the wrong situations, however, it is a nightmare. It is not something that can be forcefed into every situation and while it has its benefits, using it in the wrong project will provide nothing but heartache. Trust me, I know from experience. It is the Dr. Mindbender of frameworks: use it where it should be and it’s a peace-loving orthodontist. Misuse it and you have a hateful, deceitful villain with a proclivity for cybernetics and brain-scrambling.

I spent a decent amount of time on a project that flouted tried-and-true Hibernate conventions. Admittedly, this was my first proper working experience on a major project with it, so naturally, I became prejudiced against it. ‘THIS is what all the Hibernate fuss is about?’, I said, the platform for my future drum-beating beginning to take hold. ‘I know how to write my own database queries, no thanks’.
So from then on, I became a zealot, proudly jutting out my chest in interviews and on projects about how it was worthless, how I’d rather just use easier approaches like Spring and JDBC.

Then, something unexpected happened.

I worked on a project that actually made sensible use of Hibernate. I got to see how a proper persistence-mapping file was created. I saw first-hand some of the benefits of Hibernate that I didn’t even know existed; benefits that weren’t in my egotistical arsenal of query-writing and transactional coding.

But, old habits die hard. In technology, you learn as you go, so it makes no sense to completely flip-flop from one side to another. To be a good developer (to go from journeyman to master, if you will), you should be an amalgam of your experiences. Draw from what you learned and make informed decisions.

So, to prove my point, I will outline the good and the bad of Hibernate. I will tell you when to use it, when not to, and some practices to avoid. And hopefully, you’ll recognize when you should make use of it and when you should avoid it like the plague. After all, there’s a time and place for everything.

The Good

No Query Writing

Probably the biggest and highly-touted feature of Hibernate is that it abstracts the database layer away from the developer. No more fiddling around with DB queries and getting your hands unnecessarily dirty with database connections. Through simple methods such as Session.load() and Session.get(), retrieving an object is simple. In addition, Hibernate’s Criteria API makes complex joins relatively simple and easy to create.

For example, suppose your system has an Order object which has a many-to-one association to a Customer object and the association is by Customer ID. Further suppose that the query to retrieve both orders and customers pits up against two brutally large and inefficiently constructed tables. If you have not specified a fetch strategy on the relationship, the default behavior for Hibernate is SELECT, which means to retrieve an order, two queries will be run: one for the Order and one to populate the Customer association. Normally, what you’d do in plain JDBC world is to simply join these two queries together on the Customer ID, which is a process that can be a pain, especially if the queries are large, the join columns are complex, or the queries are stored in code (requiring a recompile).
However, in Hibernate, you simply change the fetch strategy to JOIN in the mapping file and voila, Hibernate joins the queries together and retrieving an Order runs one query, bringing back Order details and Customer details in one shot.

Caching

Caching is an item that could be its own blog post (I smell sequel!), but I will touch on it here. There are three areas of caching involved with Hibernate: 1st-level, or session-caching, 2nd-level caching, and query caching.

In a nutshell, session caching involves the ability of Hibernate to store objects in cache scoped to the current Hibernate session. What this means in layman’s terms is that the following code:

  Session.load(MyObject.class, 123);
  // Other logic here
  Session.load(MyObject.class, 123);

will only invoke one query for MyObject. The initial invocation hit the database and stored the information in Hibernate’s session cache. Since we are still in the same session, another request for that object will simply retrieve it from the session cache and not pull it from the database.

The second-level cache and query cache work together and are scoped across Hibernate sessions. The 2nd level-cache stores IDs of objects keyed to the respective object values (not the objects themselves). The query cache stores WHERE clauses and their bound parameters keyed to object IDs. Used together they represent a powerful way to improve performance by storing oft-requested information in a cache and minimizing the hits on the database over time. If your application is easily cacheable, then Hibernate could be a good choice for you. It can really speed up response time by eliminating all that expensive database interaction.

So, how do you know if your application has good cache candidates? Well, stay tuned for the sequel. You didn’t learn the back story of Don Corleone in Godfather I did you?

DB From Scratch

One such area that begs for Hibernate is when the database is being designed from scratch. This is not an existing database you are trying to shoehorn Hibernate in front of, this is one that can be designed with an ORM solution in mind. It is one that can be designed for abstractions.

As a result, you can take a more object-oriented approach to fashioning the database and its relationships. You can assure that tables are created that are easily modeled to objects and that the relationships that are defined are properly mapped. If you think in terms of the system and how Hibernate functions, designing the database will be easy and as a result, Hibernate will be a seamless integration into your system.

Lower DB Learning Curve

From a consultant’s point-of-view, it makes it far easier to learn the database and its relationships when a proper and well-documented implementation of Hibernate is in place. Learning database tables and their structures is simple just by scanning the persistence-mapping file. No need looking at cryptic table names and columns where you have to first parse the English translation of them before you can even think of how they all relate together.

Further, the Hibernate entity objects make a developer-friendly way to look at the business model. Everything is laid out into handy Java objects, enabling you to take a more code-centered approach towards learning the domain. In addition, learning data types of fields is extremely easy and all of this makes onboarding that much faster. Which would you rather spend your time learning:

ORD_MASTER

ORD_ID
ORD_NM
CST_ID
QTY
TTL
STS

Or this:

public class Order {
    	private String orderId;

    	private String orderName;

    	private Long customerId;

    	private Integer quantity;

    	private Integer total;

    	private String status;
}

So, while this may not be necessarily a reason to implement Hibernate, it is one positive aspect of it. As a consultant, anything that enables you to learn the client domain faster is a good thing.

The Bad

Query Writing

OK, so maybe I was wrong when I said there’s NO query writing. Sometimes there is. Hibernate has its own query language called the (wait for it) Hibernate Query Language, or HQL. In addition, its syntax is not completely identical to SQL, which I’m guessing is the database language in which you spent a few years dabbling.

Well, they say to learn to new a language once a year, so here’s your newest one. Luckily, you shouldn’t need to use this that often, especially if you have a well-crafted mapping file and make efficient use of the Criteria API. Any ORM worth its salt and that prides itself on database layer abstraction should not force the developer to rely on query-writing, even if it is relatively object-oriented.

Unwieldy Legacy Databases

Legacy databases pose a problem for Hibernate. There are many aspects of a database that can creep in over time and most of them do not react well when an ORM pokes its nose in on their business.

One such sign that Hibernate is a bad idea is business logic in the database, such as in PL/SQL packages and procedures. This type of logic works behind Hibernate’s back and provides nothing but headaches to attached entity objects in your code. For example:

MyObject is retrieved from the database. While it is hydrated, a procedure is invoked in the database that updates a few tables, including the table to which MyObject is connected. Now, your object has stale data inside that it thinks is valid. You now have to flush your object and get the up-to-date data. This kind of thing can be difficult to fix and even more difficult to diagnose.

In addition, with legacy databases, often times developers tend to know the schema and inner workings extremely well. They become intimately familiar with the poor performing tables, where the indices are, and how the relationships work. As such, sticking Hibernate in front of them makes for an extremely problematic transition. They will see Hibernate as a black box obstacle that they have to defer to regarding the database. When you have a group of developers who are used to getting their hands dirty with the data, sticking an ORM framework in their way is going to cause problems.

Unnecessary Information

This item was one of my talking points during my Great Anti-Hibernate Crusade. I’ve grown less vitriolic with this concern in my old age, but its still something I have a bit of trouble with and have never really received a complete and acceptable answer.

Modeling data to objects using an ORM like Hibernate simply returns more data than needed. Period. There are going to be times when you need the values of five columns from a fifty-column table. In addition, this table could have a plethora of one-to-many associations which are fetched eagerly. So, for your five columns you are returning back 47+ values you don’t need and running who knows how many queries needlessly. Sure, you could turn off the eager-loading, but that affects any other logic that needs these associations at the time they’re loaded.

The explanations or resolutions for this I’ve been proposed over the years are that you should design your system in a way where model objects can be used throughout all layers. In a perfect world, that seems reasonable. But user demands are not always reasonable. So, what happens when they request to see a popup on screen showing only those five values from that fifty-column behemoth? Should I tell them I can’t because it doesn’t work well with model objects?

Designing with a model object approach in mind is a great idea with new development, but applying this to legacy code is a headache.

The way I see it, you have three options in the above scenario:

1. Just retrieve the object as its modeled and send the mounds of information back even if its not needed
2. Use a Data Transfer Object
3. Consider a refactoring of the modeling / relationships.

All have tradeoffs and none seem like a silver bullet approach. The last object is probably not going to happen. This is especially true if this is a legacy system with rotting design.

The first option is most likely, but as I said will result in needless data and/or queries being run, but admittedly this is something that could be mitigated with caching strategies.

The second option is sort of like throwing in the towel. Its like admitting you were beaten by requirements. The second you let DTOs creep into the mix, things start to get infected and you’re losing the very foundation on which you built your Hibernate architecture in the first place.

So, that is what I’ve learned so far in my love-hate relationship with Hibernate. I suspect many developers have a love-hate relationship with a lot of tools and mine just happens to be this one. I think it benefits a developer to see the good and bad of each and not just develop unfounded opinions based on one bad experience. That way, they can make an informed decision in any circumstance. Learning to do this allows you to have an open-mind and grow in your knowledge, eventually becoming an evil genius capable of mind control and dentistry, like Dr. Mindbender.

©2012 Summa Blog. All Rights Reserved.

.]]> http://www.summa-tech.com/blog/2011/06/07/dr-mindbender-or-how-i-learned-to-stop-worrying-and-love-hibernate/feed/ http://www.summa-tech.com/blog/2011/06/07/dr-mindbender-or-how-i-learned-to-stop-worrying-and-love-hibernate/