For SEOers; developers; testers; web developers; BA's and CIO's.

REST has some tremendous benefits, but it's message is clouded. It's a message that I feel needs to be partly understood, by more than just developers.

Narrative, seemed a good enough form (I would have preferred comics). I was inspired by Dan North and friends(Simon Stewart) story about a guy buying pants from a WS-* like shop vs. a RESTful shop and How I explained REST to my wife.

In this Four part series, I'll attempt to simplify the ideas behind presented by Roy and others from his dissertation for a wider audience.

• Part 1 - Online Experiences
• Part 2 - Physical (Offline) Experiences
• Part 3 - Summary
• Part 4 - Further Technical Detail

This is tough, I will necessarily loose details, but the intent is not to mislead, only to introduce some examples and benefits of adopting a RESTful style.

If you are an SEOer; developer; tester; web developer; BA or CIO who wants to know more about REST and what the benefits and pitfalls are, then Read On.

SLAP

all code in a method live at the same level of abstraction. Nice acronym.

Aristotles Essential and Accidental Properties

Notions of Accidental Complexity have been around for a lot longer than I thought.

Dietzlers Law - 80-10-10 (classic)

you can do 80 percent of what the customer wants in a remarkably short time. The next 10 percent is possible, but takes a lot of effort. The last 10 percent is flat out impossible because you can't get "underneath" all the tooling and frameworks. And users want 100 percent of what they want, so 4GLs gave way to general-purpose languages (Visual BASIC, Java, Delphi, and eventually C#). Java and C# in particular were designed to make C++ easier and less error prone, so the developers built-in some fairly serious restrictions in the interest of keeping average developers out of trouble. They created their own versions of the "80-10-10 Rule," only this time the stuff you couldn't do was much more subtle.

• Productive Programmer

Let's do some back of the envelope costings, assume a long running build of 30+mins, with 10 devs, probably 50% want to commit during the period or during the period after the build was broken and before a rollback or fix has been committed.

A broken build has distracted atleast 5 people including the build master and they will have to wait or be careful of how they progress so on average that may be about 5hrs of lost productivity.

THAT's EXPENSIVE!!

Sure there are lot's of arguments like make your build faster, well the reality is whatever time your build is, you have disrupted the flow of your team members that has resulted in potentially significant wasted effort.

And in your rush to fix the build you may have not really addressed fundamental issues of the breakage, but just put a quick fix in to get things going.

An argument for Last In Wins, is that the user may not know why there update has failed etc. We could approach this through useful messages or improved usability.

Another would be that why build optimistic locking when the simplest thing that could possibly work should suffice in most cases.

Well the cost of building it in is not high, it has good support in most orm including hibernate.

In reality the actual number of cases where multiple user transactions may attempt to update the same row should be very rare, but that is no reason to give up on optimisitc locking.

Databases are there to provide ACID proof transactions, Atomicity, Consistency, Isolation and Durable.

If we choose Last In Wins we are at a much higher risk of corrupting the data, if updates on tables can occur that don't update all columns the way is open for inconsistent updates. It feels so wrong to have a database that provides ACID transactions yet we can partially thwart it's goodness by not using pessimistic or optimistic locking policy.

For some systems or certain areas of a domain it may be fine. eg. updating a user's profile.

If you are going to mix it up, at a minimum ensure that Aggregate Root Entities use optimistic locking since they are more likely to have concerns (state or behaviour) that depend on it's children. eg. summarised data that needs to be updated, or invariants that need to be validated before transaction completion.

In general I would prefer to standardise on optimistic locking.

After eliminating statistics as an issue, we discovered the problem was only affecting linux from either sqlplus, or jdbc using a type 4 thin driver, windows clients were ok.

So not sounding like a driver issue, we hunted further and foud that after select * from nls_session_parameters it was obvious that some we had some very important nls settings that were incorrect. For Oracle on *nix you have to ensure that an NLS_LANG environment variable is setup, like "ENGLISH_AUSTRALIA.UTF8"

Since we have been porting from sqlserver (case-insensitive) to oracle (case sensitive) there were certain nls settings that need to be set.

In Particular nls_comp=ansi and nls_sort=binary_ai. There are some articles around for doing this, just ask tom.

Warning

It should be stated however that this will only allow case insensitive searching for relational operators like '=', '<', and '>'. LIKE searches will still be sensitive, so for many cases you will still need to do standard uppercasing of literal search value and creation of function based index.

Back to our problem, why was asp working and the good guys not, well there was an existing after logon trigger that was setting up a single nls_sort=binary_ai.

Now we were getting this setting on connection, but asp were not, other regional settings must have been interfering and the nls_sort value was the standard "binary". So asp was still working fast due to the use of a standard NOT CASE INSENSITIVE index.

Meanwhile the cost based optimizer had no index to choose for us, because the creation of a function based index with that nls_sort setting had been missed. If you had a need to create one yourself it would be something like this:
create index blah on tbl (nlssort(columnName, 'NLS_SORT=BINARY_AI'))

BTW, when adjusting some of these parameters you may need to spend time on checking the order, as there are implicit dependencies with no apparent documentation on which order you should override them.

So if you are working in a multilingual db, make sure you check out nls_session_parameters to confirm your changes. The other tables nls_instance_parameters or nls_database_parameters are only relevant for checking the character set(s) of your database since that isn't session specific.

The Test

So you may be wondering how this was tested, well there was a test, it was very simple, using the explain plan feature of oracle asserting that there was an index scan present. Here are the interesting bits:

    public void testOracleWillUseIndexForQuery() throws SQLException {
        String problemQuery = "select * from test where name = '2423423'";
        assertQueryUsesIndex(problemQuery);
    }

    private void assertQueryUsesIndex(String problemQuery) throws SQLException {
        assertTrue(explainPlan(problemQuery).indexOf("INDEX (RANGE SCAN") > 0);
    }

    private String explainPlan(final String query) throws SQLException {
        String queryPlan = "explain plan for ";
        getConnection().createStatement().execute(queryPlan + query);
        return explainPlan;
    }

    private String getExplainPlan() throws SQLException {
        String queryPlan = "select n" +
        "  substr (lpad(' ', level-1) || operation || ' (' || options ||')',1,30 ) "Operation", n" +
           "  object_name "Object"n" +
           "from n" +
           "  plan_table n" +
           "start with id = 0 n" +
           "connect by prior id=parent_id";
        ResultSet rs = getConnection().createStatement().executeQuery(queryPlan);
        return accumulateColumn1(rs);
    }

    private String accumulateColumn1(ResultSet rs) throws SQLException {
        StringBuffer result = new StringBuffer();
        while (rs.next()) {
            result.append(rs.getString(1));
            result.append("n");
        }
        return result.toString();
    }

But now in 10g you have alot more freedom, for starters the expression list is now limited to 1000 plus you can have multiple "IN" conditions in the query to extend that and if you want something less smelly, create a collection and use the CAST and TABLE commands to join an in memory collection of predefined type to real tables.

When I first tried the latter method in 8i it was too unreliable to use, but now it seems better, thanks to Gary Mandelkow for doing the leg work and testing 10g, we can reliably do this with atleast a 3000 member collection.

Further analysis was needed and later it was confirmed that initial estimates were pretty close to the mark.

It reminded me of a good book that is probably not on alot of programmer's reading list. Programming Pearls is an old style book of computer science articles from the 80's. Column 7 about "Back of the Envelope" estimation, using very rough order of magnitude guesses to arrive at an approximate value for an amount, or response time. I originally read this from following some of the references from Code Complete. It is an Addison-Wesley book, but not available on safari , which is exactly the sort of book that should be provided

I had a superficial look mainly from a scripting point of view and it looks great, I might never have to write another awk script again!

Here is the socketcount program from a recent post rewritten in ruby.

#!/usr/bin/ruby
#socketcount in ruby
if $*.size > 0
regex = $*[0]
else
regex = '^..p'
end
result = %x{sudo netstat -tpa | grep #{regex} | grep -v LISTEN }
# All Socket connections counted (originating and terminating)
h = {}
result.each() { |s|
service = s.split(' ')[4]
h[service] = h[service].to_i + 1
}
h.each { | key, value | print key, " ",value, "n" }


It suits my purposes for scripting and seems to be pretty impressive in other aspects.