There are three forces that shape a project: domain, process and technology. Add the “-driven” suffix to any of them and you’ll perhaps recognize some of the methods used in projects you’ve been involved in and yet, as soon as one takes too much of a lead against the other two, failure will follow almost inevitably. At the intersection of these three forces we find familiar terms and concepts but first a word or two about each of them:

Technology
Back in the days of the tech bubble, tech was allmighty. Buzzwords like Java, EJBs, PHP defined entire projects. It was the time where software became accessible to a much larger audience. The new wave of enthusiastic geeks embraced everything from new languages to professional certifications to the then-nascent open source. I admit having my share of technology-driven projects back in the day…

Process
Process brings structure and pace to a project. The two complementary components of a project process are methodology and integration. We are all too familiar with methodology: waterfall, RUP or agile methods of software development are vastly documented and practiced; integration largely is defect management, testing, build, deployment and documentation. Today they all come together in what is called continuous integration where all these concepts become interrelated in a repetitive process that produces accountability and visibility into the progress of a project. Process is also the one force that tends to disappear first after a project is finished.

Domain
The domain captures entities and business logic, is driven by the business requirements and is in no way influenced by the two other forces. The most successful way to employ the domain is through Domain Driven Design where the main focus of software development is neither technology nor process but the business requirements.

There are times in the life cycle of a project where these forces have to be kept separate but most of the time they shape each other. At their confluence there are several artifacts that are paramount to a project’s success with code being at their core.

Code
Although each force is important during a project life-cycle, they all work towards producing code. No matter how many UML diagrams, software architecture documents or burn down charts are produced the most valuable and tangible value that a project creates is runnable code.

APIs
Application Programming Interfaces represent the external view of runnable software products. APIs state the intent of the software. They should be cared-for and refined during a project lifecycle, until they become the best representation of the domain they are modeling. APIs also serve for integration purposes and so they should be extended to blend into the domain of the consumers as needed.

Features
Features are defined within a project scope. They can be fully defined prior to coding in a waterfall process or, defined and/or shaped during the project development in an Agile setup. Features specify a system’s requirements (they are called user stories in an agile project).

Test, Build, Deploy, Run
Projects have to be monitored since inception to their natural end. Just like a child’s development stages, projects need to touch milestones, assess velocity and health. They do so by constant testing, building, deploying and running.

Roles
Project roles that drive each of these forces can also be mapped in the above figure. Take the Agile roles for instance:

A fine balance
Imagine any of the forces represented by circles in the picture becoming disproportionally larger than the others. As a result, one or more of the artifacts at the intersection of the forces will become disproportionally smaller than the others upsetting the equilibrium. Whether is less features, less APIs or less testing, the end result is still unbalanced.

As always, people (roles) will drive the forces. Balancing them requires skill from all parts involved and the success or failure of a project depends on giving enough power to each not to overturn the balance. If ancient romans could do it two millennia ago, so can we.

There’s an interesting story rippling the news stream these days: The New York Times is questioning the ways Techcrunch reports on news. The crux of the issue is product journalism v. process journalism, the act of producing news only after all facts have been verified versus just writing the story based on what the author best knows about an event at that moment then let the story evolve and provide rigorous updates and corrections once it does.

As I was reading, I got an epiphany. The “old media” is following the old methods, much like the waterfall process where the story (the requirements) has to be fully known before proceeding with actually breaking the story (the implementation). The new media follows a radical approach: it starts with a lead (or rumor) that is initially published in a somewhat crude form, then the story evolves based on field feedback and facts drawn from the actual reality, until it becomes accurate. Even the language of the aforementioned references use words like “iterative process”, “transparent” and “standards” the same way I’d use them when talking about developing software.

This method of early release followed by incremental improvements resembles so much the agile methods of software development, I’m calling it Agile Journalism.

A revolution is happening in the media. Old methods are swiftly pushed aside; the emergence of the Internet as the news dissemination medium is fundamentally changing the ways the reality is reported upon. Who wants to read a story that is already obsolete or wrong altogether and impossible to be corrected/evolved until a new paper edition is off the press? The new media not only breaks news faster (release early) but gets the stories right eventually, simply because the new rules (standards) are clearly stating that until confirmed, the product -otherwise useful- is still a beta representation of the reality and the consumers already know how to consume such product.

From blogs to real time news streams, the new media’s aspiration is to bring the most accurate information yet to the consumers. It can and will do it by revolutionizing the way the stories are iteratively discovered based on constant feedback, the same way agile methods are revolutionizing the software industry.

Image courtesy hirefrank

Level 2 cache is one of the most powerful features of the JPA spec. It’s a transparent layer that manages out-of-session data access and cranks-up the performance of the data access tier. To my knowledge it has been first seen in Hibernate and was later adopted by the then-emerging JPA spec (driven mostly by the Hibernate guys back in the day).
As annotations gained strength and adoption, L2 caching that was initially configured through XML or properties files, was brought closer to the source code, alas in different forms and shapes. This becomes apparent if you ever have to deploy your webapp across a multitude of containers as you have to painfully recode the cache configuration (or worse, hand-coded cache access). Why not standardizing the cache control in JPA? This seems to be simple enough to achieve and yet it isn’t there. Now that JPA 2.0 is standardizing on Level 2 cache access (See JSR 317 section 6.10) it is the natural thing to do.
Every JPA provider has its own way of specifying cache access (both Entity and query cache).
To grasp the extent of the various ways cache is configured, here are some examples:

Hibernate:
Cache control for entities

@Entity
@org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)
public class Employee {...

Cache control for named queries:

@javax.persistence.NamedQuery(name="findEmployeesInDept",
query="select emp from Employee emp where emp.department = ?1",
hints={@QueryHint(name="org.hibernate.cacheable",value="true")})

or

@org.hibernate.annotations.NamedQuery(cacheable=true, cacheRegion="employeeRegion")

OpenJPA
Cache control for entities

@Entity
@org.apache.openjpa.persistence.DataCache(timeout=10000)
public class Employee {...

Query cache requires hand coded cache access:

OpenJPAEntityManagerFactory oemf = OpenJPAPersistence.cast(emf);
QueryResultCache qcache = oemf.getQueryResultCache();

EclipseLink
Cache control for entities

@Entity
@org.eclipse.persistence.annotations.Cache(expiry=10000,
    type=org.eclipse.persistence.annotations.CacheType.FULL)
public class Employee {...

Query cache is hand coded (example from here):

ReadObjectQuery query = new ReadObjectQuery(Employee.class);

// Instruct the ReadQuery to cache its query results
query.cacheQueryResults();

// The first time you invoke it, the ReadQuery reads from the database, session
// cache, or both and stores the result set in its internal query cache
Employee employeeFirst = (Employee) session.executeQuery(query);

Another JPA provider, DataNucleus is used by Google AppEngine for Java and they have thir own way of defining the cache access.
Entity cache control in DataNucleus:

@javax.jdo.annotations.Extension(vendorName="datanucleus", key="cacheable", value="false")
@Entity
public class Employee {...

Query caching is again manual:

query.setHint("datanucleus.query.resultCacheType", "weak");

Looking at the above examples it looks to me that caching was an afterthought for most of the JPA providers. Let’s remember that the cache should be transparent and pluggable and the value that a cache provider delivers stays in performance and not in configuration.
JPA cache configuration is in need of standardization and in my opinion the closest to a standard is (again) Hibernate.

A great addition to the JPA2 spec is the introduction of @Cacheable that controls entity caching but there’s still no standard on how to control query caching.
Here are some enhancements that I’m proposing:

1. An enhancement to @NamedQuery and @NamedNativeQuery to allow explicit cache enablement through a boolean attribute called cacheable, the same way @org.hibernate.annotations.NamedQuery is defined.

@NamedQuery(name="findEmployeesInDept", query="...", cacheable=true)
...
@Entity
public class Employee {...

2. Both @javax.persistence.Cacheable and @NamedQuery to support optional attributes: timeout (in sec.) and a cacheRegion attribute that in turn, will point to a cache policy where a more complex configuration can be used (to add the cache concurrency strategy and eviction policy for instance).

@NamedQuery(name="findEmployeesInDepartment", query="...",
   cacheRegion="DepartmentEmployeesCacheRegion")
@Entity
@javax.persistence.Cacheable(cacheRegion="EmployeeCacheRegion")
public class Employee {...

Cache regions can be configured through a new annotation, @java.persistence.annotation.CacheRegion.

@Target({ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
public @interface Cacheable {
    boolean value() default true;
    int timeout();
    String cacheRegion();  //takes precedence if used
}

package java.persistence.annotation;
@Target({TYPE, PACKAGE}) @Retention(RUNTIME)
public @interface CacheRegion {
    int timeout();   //i.e. 300 s
    javax.cache.EvictionStrategy evictionStrategy(); //EvictionPolicy.LRU, FIFO, etc
    String name();  //region name
    ConcurrencyStrategy concurrencyStrategy();
    String hints();  //vendor extensions
}

If specified, a @CacheRegion exists either in-place along with the entity definition or separately through a new annotation @java.persistence.annotation.CacheRegions:

package java.persistence.annotation;
@Target({TYPE, PACKAGE}) @Retention(RUNTIME)
public @interface CacheRegions {
	CacheRegion[] value();
}

example:
@CacheRegions ({
  CacheRegion(name="EmployeeCacheRegion", timeout=300, evictionPolicy=
EvictionStrategy.LRU, ConcurrencyStrategy.TRANSACTIONAL),
  CacheRegion(name="OfficeLocationsCacheRegion", timeout=-1, evictionPolicy=
EvictionStrategy.LRU, ConcurrencyStrategy.READ_ONLY),
})
public class OrganizationStructureDAO {...

4. Sensible and well-defined defaults if some of the values are nor specified: default timeout, default eviction policy and default concurrency.

Vendor extensions of cache configurations will still be able to be deployed through the hints attribute both for @NamedQuery and @CacheRegion.

In the end, configuring the cache should be executed the same way across containers given that the cache providers that will be used will likely be the same. At least that’s what I’m hoping to see in JPA 2.0.

		“Thinking in…” anything has been a marketing quirk for a while now, being used and abused from the field of language learning to computer science. Thinking in Java is the title of a well known book written by Bruce Eckel. I am passing a “Think in Spanish” course flyer ad every time I stroll on Bloor Street West here in Toronto. Funny, thinking within the rigors of a discipline is the very definition of thinking inside the box. With respect to programming languages, it encourages one to think within the limits of a single language which is the exact opposite of what one should do when developing software.

The hegemony of agile methodologies inflicted a disruptive change on the face of the software industry and amongst the established roles within a team. The legions of “coders” bred by the tech bubble of 2000 are facing extinction; the roles of the software designer and Technical Architect are fuzzier than ever. Thinking inside of the language box makes a better coder but not a better software engineer.

Modern software design methodologies shatter that box. Domain Driven Design disconnects the developer from the technology and places domain rules before the intricacies of a language. Test Driven Development brings the Domain in the software realm and it does it by forcing to write the tests first, then write the actual code. Test-first forces you to think behavior and APIs first then perform the act of coding which is nothing more than implementing that behavior.
Eric Evans’s DDD: Strategic Design is an eye opener. And while you’re at it, check his other presentation about domain modeling.

So instead of “Thinking in Java”, think Domain and APIs first then act. In Java.

Since I went back from vacation (Easter with family back home in Romania) I got quite interested in the mobile internet. This was the first time I wasn’t going to internet cafes or asking buddies to let me use their internet (and their PCs).
I have a beaten Nokia 3100 that works both in RO and here in Toronto. I was playing with it in my first vacation days back home, exploring the features of my romanian mobile carrier (I love the *…# service commands, they remind me of dumb terminals) and I noticed that they had a new offering, mobile internet. Configuration was a breeze and I found myself browsing the internet a few minutes later. Email, news, even checking if my websites are still up and running; they were all there where I left them.
Needless to say that from that day I didn’t step into an internet cafe anymore to get my fix.

I also got a lovely gift from Corina around the same time, an iPod Touch. Since I’m a fan of Apple’s products I couldn’t be happier and since I started using it I realized that I use my regular laptop less and less. I’m using the iPod Touch more to check Email, news, weather, live TV (gotta love France24) and play the occasional game, than to listen to music. The experience is more condensed and focused and so I spend less time to find what I’m looking for. Mobile internet experience achieved the goal that it’s parent couldn’t: ease of use.

Funny that I had to go back home to find it out.

I decided to enable my web properties for the mobile internet. Firstly I made this blog mobile-friendly. I installed Wptouch for WordPress. It’s an excellent plugin that just works on iPod Touch and iPhone. I also installed WordPress Mobile Edition that should do the trick for the rest of the mobile devices so go ahead and give the Newsplore Blog a spin on a mobile browser. Actually WordPress should render for mobile browsers natively, it will only accelerate the shift.

Next I’m going to make spincloud.com mobile; not that there aren’t any mobile weather websites but it won’t be long until mobile browsers will generate more traffic than their desktop counterparts. I’m merely getting ready for the inevitable. Eventually there will be websites made only for mobile consumption (if there aren’t already) just like these days newspapers are becoming -ironically- paperless.
Interestingly many high traffic websites and and blogs (techcrunch, gigaom) don’t work yet on mobile phones (the iPhone situation is better but still not there yet). On the other hand Google is awesome on small browsers. Mail (attachments included, I could read PDFs too!), Reader, search, News, everything just worked. It even translated the search result links for the mobile experience. Kudos Google!
This is not the beginning of the mobile internet (WML anyone?) but with the advance on the devices front, the critical mass has been reached. And for those of you reading this on a cell phone, Q.E.D.

As I’m using the ubiquitous Hibernate 3.3 as the JPA 1.0 provider for Spincloud, I decided to try out another one. I had tried OpenJPA (spawned from Kodo JDO) when they only supported build-time bytecode enhancement and it was a pain to make it work. It worked all right but boy what a pain. There’s now an agent to provide on-the-fly enhancement but I’ll take transparent enhancement anytime.
I’ve heard about EclipseLink before. The project started when Oracle donated the respectable TopLink project to the Eclipse foundation. If the solid reputation behind TopLink was a good enough argument for me to try it, the announcement that it will be the JPA 2.0 reference implementation convinced me that I should try it out.
My goal is to evaluate if EclipseLink is production-ready. I’m applying a complex set of evaluation criteria (joking): if it can run Spincloud then it is (I was inspired by Seifer’s interview on Infoq about Ruby VMs; when asked what was the criteria for qualifying if a Ruby VM is production ready, he answered: if it runs Rails).

I have the following JPA requirements:
- column mappings, one-to-one, one-to-many
- supports BLOB fields
- supports NamedQueries and NamedNativeQueries
- support for object cache and query cache
- deployment/operational nice to have: ease of maintaining compatibility with both EclipseLink and Hibernate in the source code and runtime. Ideally I should plug-in any JPA provider without changing a single line of code. This was not attainable as I’ll explain below.

I started by downloading the binaries. I’m using Maven to bring the jars so I’ve followed the instructions here. I only changed the version since I wanted to use v1.1.0:

  <dependency>
    <groupId>org.eclipse.persistence</groupId>
    <artifactId>eclipselink</artifactId>
    <version>1.1.0</version>
    <scope>provided</scope>
  </dependency>

There’s a single jar file called eclipselink-1.1.0.jar downloaded which is a nice change from the multitude of Hibernate jars I was accustomed with.

Next, I created a new persistence.xml file since I didn’t know how different it would be from the one tied to Hibernate. Initially I just changed the JPA provider to:

  <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>

as the documentation stated.
Then I had a look at my current NamedQueries and NamedNativeQueries that looked like this:

@org.hibernate.annotations.NamedQueries({
	@org.hibernate.annotations.NamedQuery(name="findStationByPK",
	        query="select station from Station station where station.id=:stationPK"
	        , cacheable=true, cacheRegion="weatherStationsRegion"),
...

and I recalled that I did this in order to make use of Hibernate’s Query cache facility, alas a non-standard way of cache enablement (not until JPA 2.0 anyway). I had to put query caching to rest and switched all my Named*Queries to standard JPA:

@javax.persistence.NamedQueries({
	@javax.persistence.NamedQuery(name="findStationByPK",
	        query="select station from Station where id=:stationPK"),
...

I’m not using the integration unit tests I have due to the issues I had with the Spring integration test framework I’m using after switching to Spring 3.0 so I’m using ad-hoc testing for now. After rebuilding/deploying the project I didn’t notice any error on Tomcat start-up so I just tried the GUI, displaying the weather in a map area. I hit the first error:

Exception [EclipseLink-7060] (Eclipse Persistence Services - 1.1.0.r3639-SNAPSHOT):
org.eclipse.persistence.exceptions.ValidationException
Exception Description: Cannot acquire data source [java:comp/env/ds/MeteoDS].
Internal Exception: javax.naming.NamingException: This context must be accessed
throughout a java: URL

I dug through the documentation (what’s with this documentation and what does “No dynamic weaving (instrumentation) – static weaving of entities is still available via EclipseLink” means, why JPAEclipseLinkSessionCustomizer example is broken and finally why use teh deprecated SessionCustomizer?) and found that I have to use a session customizer to make it work in Tomcat. I didn’t like this one bit (it just works in Hibernate) but I followed the instructions and EclipseLink could establish the connection with the Tomcat-configured data source as expected. This was the first duly noted turn-off.
I redeployed and browsed the weather map just to hit another problem:

  Exception Description: Syntax error parsing the query [findStationByPK:
    select station from   Station where id=:stationPK], line 1, column 28:
    syntax error at [where].
 Internal Exception: MismatchedTokenException(65!=66)

Hmm, no compile-time JPA query check. Not good. I checked the JPA query, it was:

  @javax.persistence.NamedQuery(name="findStationByPK",
       query="select station from Station where id=:stationPK"),
...

which looked OK but looking closely I realized that it was not. The correct syntax is (notice the station. indirection:

@javax.persistence.NamedQueries({
	@javax.persistence.NamedQuery(name="findStationByPK",
	        query="select station from Station station where station.id=:stationPK"),
	@javax.persistence.NamedQuery(name="findByStationId",
...

Hibernate was happy with the “non-standard” syntax while EclipseLink is not. No big deal, it wasn’t in many places anyway. I scanned all my queries and fixed them. Redeployed and hit this:

  Exception Description: Syntax error parsing the query [findByStationId: from
    Station station where station.stationId=:stationId], line 1, column 0:
    unexpected token [from].

My JPA query is:

	@javax.persistence.NamedQuery(name="findByStationId",
	        query="from Station station where station.stationId=:stationId")

Again a Hibernate artifact. H3 supports the convenience of using queries that start with “from entity…” if they return entities (single or lists). The fix was simply to add “select station” in front of the JPA QL:

	@javax.persistence.NamedQuery(name="findByStationId",
	        query="select station from Station station where
                station.stationId=:stationId")

Not a biggie either, standard is better and Hibernate can parse this kind of query. Again, rebuilt/redeployed and queried the map again. This time the error was this:

[EL Warning]: 2009-03-21 19:02:42.135--UnitOfWork(2001070194)--Exception [EclipseLink-4002]
(Eclipse Persistence Services -
 1.1.0.r3639-SNAPSHOT): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException:
You have an error in your SQL syntax; check
the manual that corresponds to your MySQL server version for the right syntax to use
near ':area) , LOCATION) and obs_time
> :minSynopDateToConsiderStr UNION select distin' at line 1
Error Code: 1064
Call: select distinct STATION_FK as STATION_IDENTIFIER, LOCATION,
obs_time as REPORT_TIME  from SYNOP where Contains(GeomFromText(:area) , LOCATION) and
obs_time > :minSynopDateToConsiderStr UNION
select distinct STATION_FK as STATION_IDENTIFIER,
LOCATION, REPORT_TIME as REPORT_TIME from METAR where
Contains(GeomFromText(:area) , LOCATION) and REPORT_TIME > :minMetarDateToConsiderStr

I couldn’t find anything at first in the documentation (getting really pissed at the documentation style, can’t find anything useful) but I finally found this:

Support for the EclipseLink # convention is helpful if you are already familiar with
EclipseLink queries or if you are migrating EclipseLink queries to a JPA application.

I’m not “already familiar with EclipseLink queries” and no, it’s not helpful. So now I have to use #area instead of :area named parameter. This is really smart. Why in the world would one want to change the column with sharp? I’m starting to suspect clumsiness or plain careless coding. I still want to maintain Hibernate/EclipseLink pluggability so I have no choice but creating a static class that holds all NamedNativeQueries and parametrizes the named parameter prefix:

class NativeQueries {
public final static String WEATHER_SNAPSHOT_IN_AREA_NATIVE_QUERY ="select distinct
STATION_FK as STATION_IDENTIFIER, LOCATION, obs_time as REPORT_TIME from SYNOP where
Contains (GeomFromText(@named-param-prefix@area) " +
 ", LOCATION) and obs_time > @named-param-prefix@minSynopDateToConsiderStr UNION " +
"select distinct STATION_FK as STATION_IDENTIFIER, LOCATION, REPORT_TIME
as REPORT_TIME from METAR where Contains(GeomFromText(@named-param-prefix@area) " +
", LOCATION) and REPORT_TIME > @named-param-prefix@minMetarDateToConsiderStr";
...
}

Then I have to use ant to perform a pre-compilation task that replaces @named-param-prefix@ with either : or #. This really got the best of me as I’ve hit a Java compilation quirk too: you have to delete all classes that rely on the NativeQueries class since they will not recompile if the values of the public static final String values change; you have to delete all .class files and force a full compilation for them.
After I did this build change it all started working. Victory at last. Or was it? Well, no; I still have to add query caching as I heavily use spatial queries to fetch area weather (activated every time the map is dragged/zoomed). There’s the @Cache but it’s for entity caching which is good but what I also need is query caching à la Hibernate:

 @org.hibernate.annotations.NamedQuery(name="qName", query="<query>",
    cacheable=true, cacheRegion="some-cache-region")

After another round of thorough search of the documentation I found what I needed but it wasn’t what I expected. EclipseLink doesn’t support annotation-level query cache configuration. Instead you have to code-in (or use AOP to) cache writes after the queries are executed, via its ReadQuery class.
Needless to say I didn’t do it. I gave up on it right there.
On a whole this felt a lot like my (undocumented) evaluation I did over a year ago with OpenJPA (no dice too). Poor documentation (worse than EL’s) and lack of (then) runtime weaving made it a nightmare to deploy. I haven’t tried it ever since.

Prognosis: negative

This is really a shame, EclipseLink seems to be quite fast and has a footprint similar to Hibernate but:
- the documentation is awful. Guys, look at Hibernate and follow their lead. I badly need a single page HTML up-to-date documentation that I can freely browse. I can find almost anything in a matter of seconds using Hibernate’s single page HTML doc and Ctrl-F. I feel so strongly about this, I’d make an addition to the Software Craftsmanship Manifesto: “Maintain top-notch documentation”. Spring and Hibernate projects got it right and this is one of the secrets of their success. Take note.
- Use : (column) for named parameters in NamedNativeQuery; it is consistent with NamedQuery syntax (and hopefully standardized in JPA 2.0).
- Use compile-time Named*Query syntax check. It adds a great deal to predictability.
- Add the Session Customizer fix into of the base platform and make it transparent to the user. Nobody wants to write integration code to fix oddities of popular containers. “Out of the box” is valuable.
- Work on a better query caching support or push hard for a JPA 2.0 beta since there’s standardized second-level caching.

Oh and guys, some documentation pages don’t render properly on Safari, the TOCs overlap the content. Unacceptable.

Until then I’m sticking with Hibernate 3.3. It just works.

I couldn’t miss this one. It didn’t take long  after Google released its seafloor imagery to its Earth and Maps products for someone to claim the discovery of nothing less than Atlantis itself! Ah, and again it wasn’t me…

Take a closer look at the Atlantic Ocean floor area:

On the left, a grid-like structure is clearly visible. I also spotted a similar “grid” east of the main one (yes, I called it!) and some more off the west coast of Ireland.

However, it may all be a false alarm. Google said that:

 “Bathymetric (or sea floor terrain) data is often collected from boats using sonar to take measurements of the sea floor [...] The lines reflect the path of the boat as it gathers the data.”

I’m keeping my fingers crossed though. I’m waiting for Discovery Channel, bounty hunters and reality showmen to swarm the place now as I think this patch of open ocean is international waters. Finders keepers!

I love Hollywood movies. They project a surreal world that in which all stories have a happy ending. Whenever the hero seems to be cornered and rapidly heading to his doom, a last-second turn of events allows him to escape. This is deus ex machina. God from the machine. To the rescue.

I’m thinking back at many movies I so enjoyed. Terminator, Die Hard (yeah, right), Batman, Ironman, Indiana. Deus ex machina all over. I denounce them.

Think of a Hollywood movie, any of them. Chances are it’s a Deus one.

I like Rocky 1 and Trainspotting. And Sex Traffic.

I know why I like the cheesy Deus’ movies. I know the ending, no surprises there. Shameless happiness at the end, the hero survives all impossible circumstances. Satisfaction guaranteed.

No more of this nonsense. Realism rocks. I’m not going to go watch any of these other movies anymore!

And yet I can’t look away.

I like RESTful URLs. They clearly express the intent of the provided resource. We humans speak a language close to REST when we talk to The Internet. 

Take a look at Google’s RESTful search query, probably the most used RESTful URL ever:

http://www.google.com/search?q=your-terms-of-choice

in freeform language this translates to: “Google, search for this term.”

How about the Flickr RESTful tag cluster search service:

http://api.flickr.com/services/rest/?method=flickr.tags.getClusters&
api_key=a6f11b67ae348a7b3f2da0d865b8bc1d&tag=Berlin

In Flickr lingo this means: “Fetch all tag clusters for the ‘Berlin’ tag”.

It doesn’t take much to understand RESTful URLs. They speak the language of the domain they represent and therefore in the Web Services provider-consumer world:

The collection of all RESTful services provided by a domain represents its web-oriented Domain Specific Language.  

DSLs have been around for a long time. For more information check Martin Fowler’s talk on the subject.

Oh, that “I’m a Mac” commercial is on the TV again. Then some ugly new ad where some webcam people defend the PCs on behalf of Microsoft: “I’m a PC”. While my brain was tricked into an attempted wash, I realized that I’m not any of it.

I’m a human being.

I’m not trying to help you here Redmond but voila, here’s one good ad slogan:

I am not a machine. I’m a human being. And I use a PC.^®