Note that this demo only works in Chrome and Safari as required to support the Webkit capabilities.

Photo Gallery Demo

In thought, that is a great idea. However, it’s a bit of a strange paradigm. Initially, there was only a handful of languages to program in. Then, there was only a handful of languages to write server-side web applications in. Then, tons more came to the scene. Why? Because no one language fits all cases. Some are more optimized at specific use cases and make sense. As a Java guy, I’ve used several of these, but each has their place. JSF works great in form-heavy, intranet sites. Grails works great in dynamic, database-driven systems. Struts has its place. Library Xyz has its place.

If the world moves to rendering more code on the client via Javascript, in a sense, we go backward (ok, not really, but bear with me). There is only 1 language on the client side: javascript. Yes, Google exposed us to Dart, but realistically that will never mean anything because IE, Opera, Safari, etc will never support it, just as Mozilla never supported Visual Basic on the web. Javascript is the defacto “scripting” language on the web and always will be (unless someone manages to convince the entire industry and the entire world otherwise).

Yes, I know there are a ton of Javascript emulators (coffeescript, dart to a degree, objective j, etc), but it’s still javascript. There are even a ton of libraries in JS to simplify it so you don’t feel like you are using JS. In the end though, it’s all javascript and you are bound to the browser support, performance, and bottlenecks (even more so in some cases where emulators make things easy but use crazy hacks in javascript to make it work resulting in expensive operations).

Anyways, I’m not trying to advocate one way or the other (I, myself, have not really made up my mind, yet). I just found it strange how the progression of web applications was driven server side by the advancement of new languages and methodologies. To purely go client side, you are almost binding yourself to a single language: Javascript. Worse yet, there is no real progression possible other than emulators, which always scare me (I prefer having control of what something is doing rather than a cross compiler or emulator doing it for me). Maybe in a few years, emulators and javascript will advance enough that we can have different languages and libraries that are highly performant making you be able to choose the right language for the right use case and job. Only time will tell.

As an alternative, why don’t we go back to the way modems or CD drives worked. For example, modems were once 14.4, followed by 28.8, followed by 56K. You knew exactly the theoretical difference from one modem to the next. It just made sense. We could easily do the same with mobile technologies.

Another approach would be to use a system like CD drives back in the day. They all baselines off a given speed and then became 2x, 4x, 8x, etc. Again this easily makes sense what you are getting from one case to the next.

Mobile carriers should think about this type of approach rather than confusing its end users with 4G that gets tossed around with no merit or meaning. Seriously, how much faster is 4G over 3G?

• http://www.nytimes.com/2011/10/10/technology/paying-to-text-is-becoming-passe-companies-fret.html?_r=1&hp
• http://www.zdnet.com/blog/btl/the-biggest-ripoff-text-message-beats-movie-popcorn/30327
• http://gthing.net/the-true-price-of-sms-messages

It literally costs carriers next to nothing to send a message. The message piggybacks all the other packets, so those packets would be sent regardless if a text is sent. Plus, the infrastructure is already built in.

So, why in the world do they charge $.25 a text? How is that not illegal?

The “real” answer…too many of us buy into it and the carriers make billions of dollars off of it. The biggest reason I hear is “well I already have unlimited texts”. Let’s do the math though. At $10/month, that is $120/year. At $20/month, that’s $240/year. If you are on a smartphone, cancel your texting plan and you can get a new smartphone every year. That just makes sense to me, which is why I explicitly opt out of texting and save myself the money. As everyone continues to move towards smartphones, it really does not make sense to pay for texting anymore. There are too many free options.

1. Google Voice
Google Voice gives you a custom phone number to which you can send and receive text messages completely “free”. When you pair that with a smartphone, the messages are delivered to your phone directly rather than as a text message. When you text someone, again it is delivered directly via Google Voice, but it is sent to the other person as a text. Case in point, you cancel your texting plan, save $20/month, and still get free texting. Why would you not do this?

2. Google Talk
For those on Android-based devices, they come with Google Talk out of the box. Simply sign in with your Google account and you can send messages to anyone else on Google Talk including iPhone users, desktop/laptop users, iPad/iPod Touch users, etc. For example, I use the iPhone application Beejive (highly recommended) to text my android friends. Again, completely free!

3. iMessage
Apple now offers the iMessage platform that allows talking to other Apple-device users without incurring texting charges.

4. Meebo
Meebo is another Instant Messaging client that allows sending messages to other users on any instant messaging platform (Google Talk, MSN, Yahoo, AIM, etc).

5. Facebook
As much as I hate facebook, people still want to use it. That said, they also offer a messaging platform to send direct messages without using text messages.

So, I conclude with the question again? Why would anyone pay for texting? Join the Anti-SMS movement and save yourself $20/month (go enjoy a nice dinner each month instead). Let’s all IM, not Text :)

1, 1, 2, 3, 5, 8, 13, 21, 34, 55, ...

Basically, the sequence is defined as F(x) = F(x-1) + F(x-2) where F(0) = 1 and F(1) = 1. That is basically the easiest solution to code against via recursion.

public long fibonacci(int index) {
    if (index == 0 || index == 1) { return 1; }
    return fibonacci(index - 1) + fibonacci(index - 2);
}

That solution is extremely easy to write, it makes sense, and works. But how well does it work? F(20) averaged 0.1ms, F(30) averaged 8ms, and F(40) almost a second. It is obviously an exponential algorithm. The reason for this is that F(4) = F(3) + F(2), but F(3) is just F(2) + F(1). Essentially, our recursion is executing the same values over and over again since we execute each index two times. One way to avoid that duplication is to implement caching. This would result in only executing each index once at the cost of a local cache.

private Map<Integer, Long> CACHE = new HashMap<Integer, Long>();
public long fibonacci(int index) {
    if (index == 0 || index == 1) { return 1; }
 
    Integer key = Integer.valueOf(index);
    Long value = CACHE.get(key);
    if (value != null) { return value.longValue(); }
 
    long result = fibonacci(index - 1) + fibonacci(index - 2);
    CACHE.put(key, Long.valueOf(result));
    return result;
}

Using this cache-based mechanism, we now get 0.1ms at F(40). That is almost 10,000 times faster and all we did was add a caching layer. A simple change for a massive improvement. Caching can be used at any layer of an application and often times can easily improve the application stack with little effort. Further, libraries like Spring AOP or CDI interceptors can automatically add behind-the-scenes caching to any method only requiring a few lines of code for high improvements.

We can actually further improve this and without using a cache. If you again look at the sequence:

F(4) = F(3) + F(2)

We can replace F(3) with its value F(2) + F(1) resulting in:

F(4) = F(2) + F(1) + F(2)

This can be further simplified to:

F(4) = [F(2) * 2] + F(1)

Generally speaking, this is equivalent to:

F(X) = [F(X-2) * 2] + F(X-3)

We could again use recursion for X-2 and X-3, but we are back in the same exponential algorithm. Instead, we can be smart and rather than return a single value, return 2 values (the value itself and the previous value). In this way, the recursion can just take the resulting array and now has both X-2 and X-3. This results in only invoking the sequence for every other value a single time without using a cache.

public long fibonacci(int index) {
    return _fibonacci(index)[0];
}
 
protected long[] _fibonacci(int index) {
    if (index == 0) { return new long[] { 1, 0 }; }
    else if (index == 1) { return new long[] { 1, 1 }; }
 
    long[] result = _fibonacci(index - 2);
    long value = (result[0] * 2) + result[1];
 
    // result is X-2, so X-1 is just X-2 + X-3
    return new long[] { value, result[0] + result[1] };
}

Using this new algorithm, F(40) now only takes 0.005ms, another 20x improvement. Using only a few additional lines of code, we managed to simplify a standard fibonacci calculation by 200,000 times. That’s pretty significant in my book at the minimal cost of thought, analysis, and performance testing.

Other ideas to improve the calculation is using the multiple cores in modern day server hardware. For example, you could invoke F(X-1) in one thread and F(X-2) in a separate thread and then join on the results. There are also plenty of math-based solutions that may make sense.

In any sense, no matter what the algorithm or how simple it may seem, there are always multiple ways to skin the cat and those ways often lead to improved performance. Performance should always be one of the first things to consider, not the last. Minor improvements can buy you the performance sooner than later.

That being said, I think Samsung would be a good fit for four key reasons.

First, they may feel threatened by Google’s purchase of Motorola and want distancing from Android. WebOS would offer that distance and uniqueness. Rather than rely on Android and the unknown future it holds or the unknown venture Google puts Motorola in, it could adopt WebOS and have full control of its stack. They would no longer rely on Google to implement certain features or deal with custom themes. They would own the entire stack.

Second, Samsung is in legal-hell with Apple and could use a large patent portfolio that WebOS has. Apple never sued Palm/HP despite its threats and prolly because of the patent war that would have resulted. Samsung may feel better off having those patents rather than the open patents from Android. Samsung could easily ditch Android, drop the lawsuits, adopt WebOS and start fresh. Apple may still target Samsung, but at least Samsung would have more fighting power back. Today’s world seems heavy on the idea of buying up patent portfolios, so Samsung may be interested purely from that perspective while also getting a good OS (win/win).

Third, Samsung already knows how to make great quality hardware. They just need a great quality OS and WebOS could be that answer. They would hten have a true portfolio to sell to all of its carriers it already supports (almost all of them) to compete heavily with Apple on a level playing field. The issue with Palm and then HP is that they dug themselves into a hole with only supporting a single carrier and a single model. People want choices: keyboards or no keyboards, AT&T or Verizon, Spring or T-Mobile, $100 or $300, dual-core or single-core. Samsung has the manufacturing expertise to build those models and has the support of its various carriers that it could push a single platform to everyone. For example, think Galaxy S and now the upcoming Galaxy S2. Galaxy S3 could be the WebOS feature phone for all carriers.

Fourth and finally, Samsung has a complete hardware portfolio from phones, to tablets, to computers, to TVs, to home entertainment centers. If they truly want to complete with Apple, they need a consistent environment across platforms. Android is starting on that venture, but their inconsistencies continue to bite them. WebOS already works on phones and tablets, and HP/Palm was busy at work making it support computers. If Samsung added WebOS integration into its set top boxes and TVs, and did it right without sacrificing usability, it could have a full system. Push content from your phone or tablet directly to your TV, control your entertainment/HTPC from your phone, control your lighting and thermostat, the options are endless. Apple is heading this direction and its great designs and usability give them the edge. WebOS has the capability of matching and even exceeding Apple. It just needs the right partner. Samsung has the capability and WebOS could be its answers.

Ultimately, it is highly unlikely unfortunately, but it makes sense if you think about it. I’ve always thought HTC may have been a better fit for WebOS, but HTC is set of supporting everyone it seems (Android, Windows, etc). RIM may also be a fit, but RIM is in the enterprise market and will never make it in the consumer market or even the entertainment market. It’s not where they are as a company. WebOS needs a company that can be everywhere in a consumer’s life. Samsung already does that and WebOS can tie it all together.

The main reason why I bought into Google+ so quickly was that it featured Circles. Circles basically allows you to manage your relationships into groups. I had actually semi-planned out an implementation in my head as an attempt to do something similar, even though I knew I’d never finish. The concept of having ‘circles of friends’ or ‘trust circles’ just makes sense on so many levels. Not only did Google implement it, but they implemented it very well. I now have a choice over my data and where it goes. Yes, I know Facebook does this, but the fact that the Google+ implementation is built around the concept makes it incredibly easy to use. Google+ expects you to use it.

Here are the reasons why I choose Google+ over Facebook. Hopefully, these give you more insight into making your own decisions.

First of all, as a technology user/evangelist (or at least my goal), I want my information to be somewhat public. I want my blog articles to be easily accessible and directly searchable. Further, I want my name out there to credit my knowledge. However, I also want my personal information about myself, my family, etc to be private but shareable to my direct family. I also want certain information to be more or less available depending on context. Google+, via Circles, allows me this opportunity. I can easily segregate my personal/private life from my techie life. Doing that on Facebook is just a headache in the making. Doing it on Twitter is just too open. Google+ is the best of both worlds.

Second, Google+ allows you to follow others without requiring a direct consensus (ala Twitter). On Facebook, you more or less have to be joint friends to follow each other. Google+ went the Twitter style so that I may follow others such as other techies without them first approving me. This works because of the Circle relationships. If I choose to follow someone, then I will have access to their public information (techie blog posts), but will not have access to their private info (unless, they of course add me themselves and put me in an associated circle). The other cool part of Circles is that you do not know if or what circle someone else put you in…nor do you care really unless you are stalking in which case you prolly have other issues :) Your circles are your circles and private to you as they should be.

Third, Google+ breaks down the notion of ‘friends’. Let’s be honest, the term ‘friend’ has been completely broken by Facebook. Your boss is not your friend. Your friend’s friend’s acquaintance is also not your friend. A ‘friend’ is someone who you trust and confide in. Facebook used that term way too loosely. Google+ took circles and defines a set of default circles that make very good sense: Family, Friends, Acquaintance , Following, etc. You simply add users to one or more groups where they make sense. You can even add your own groups such as Workplace, Book Club, etc. Users now have direct understandable relationships to you and it makes it easy when selecting which groups to share content with.

Fourth, streams, news feeds, call it what you want, become much more manageable. I often times do not want to know that some person I know is eating a burger. However, I do want to know what the tech community is doing more often. Circles makes this completely easy. I can view the entire stream (ala Facebook), or I can view specific streams, or I can view a specific user’s stream. This way I can see just my techie stream and occasionally check other streams. It is entirely up to you on how you manage that data, which is the real point here: it is up to you, not Google, not someone else.

Fifth, Google+ allows me to control my sharing capabilities. For public information, I want to directly share it and allow others to re-share it. For private information, however, I only want those in my circles to see my content without allowing them to re-share it. On every post, you can edit it via the drop down and select Disable Reshare. This basically removes the ‘Share’ link from other users. Yes, I know they can simply copy and paste, but it at least makes it semi-harder.

Hopefully you can see how Google+ and in particular Circles makes extreme sense. Google+ did not just take Facebook and Twitter and mash them together. They created a real solution that directly correlates to managing relationships in life. That is what defines usability: software that provides a direct association to life in order for a user to directly apply its natural association.

I know I have discussed all the good things, so how about some bad things to even the playing field.

First, Google+ is still in the market of acquiring user information to create large graphs in order to better their company as is Facebook and Twitter. Google+ was not created solely to allow you to talk to your relationships…it was created so that Google would have that social data that companies desperately desire. So, if you are paranoid about your data being locked up in some big corporation, then you may have issues. That being said, I do believe that Google is the lesser of the two evils (and I am to an extent semi-paranoid which is why I despise Facebook). Facebook is willing to abuse their power to make themselves richer, regardless of its impact on users. Google is held to a higher standard, IMO. That may not be completely true, but I believe there is some validity to it. Google has shown this by making privacy more straighforward and easier to access. They also provide more insight into your data including allowing you to backup your data or transfer it to another service. Finally, they allow you to delete your entire profile, unlike Facebook which refuses to relinquish control of your information more or less.

Second, Google+ is still in beta and a work in progress. Because of that it is clumsy and not completely apparent at all times. For example, there is no good way to message a user directly. However, Google Chat does allow you to easily do that so there are options. Google is continually integrating their entire product line, so it will come, just not there quite yet. That being said, it is very usable and works. I use it often to include my blog articles, family pictures, etc. I have had no major issues as of yet.

Third, Google+ is still in limited beta meaning you have to have an invitation (ping me if you want one). As a result, not all of your friends or family will be on there…odds are they won’t. But hey, don’t you want to lead the revolution, not sit back and watch it? Convince your friends and family to join and they will be there :) I believe that as Google+ begins to stabilize and more feature rich that users will realize the impact of Circles and all the other features and jump ship, so don’t let the absence of your buddies hold you back.

Fourth, device support is still limited. Google+ is supposed on iOS and Android, but IMO, its support is not all that well. They allow you to upload pictures (although limited number) and post updates, but editing, disabling resharing, etc are all missing. Those features are coming and the mobile apps are very usable. They are just not as rich as they could be. Again, though, don’t let that hold you back. Time will tell the real story.

Fifth, feature X on Facebook or Twitter does not exist. Remember, Google+ is still in beta and those features are more or less coming (where they make sense obviously). Google+ is not going to add a feature just because…it has to make sense. The best part though is that Google+ is listening to its users and as users voice their opinions, priorities most likely will change. If enough users want a feature, Google will prolly investigate the time and effort. So, if you really want feature X, just drop the Google+ team feedback and let them know. They are listening. Google+ wants to be successful and not operate in a complete vacuum.

With all that being said, I definitely encourage you to try it out. It won’t be without its issues, but neither is Facebook, Twitter, or [put your favorite other platform here]. As users begin to switch and Google implements features, the platform will become better and better. Hopefully the pros and cons listed here will help to encourage your adoption.

If you want more information or need an invite, just let me know.

Enjoy!

grails create-app test
cd test
grails install-plugin jaxrs
grails create-resource com.znet.test.api.Users
grails create-domain-class com.znet.test.domain.User
grails create-domain-class com.znet.test.domain.Address

At this point you can modify the grails-app/domain/com/znet/test/domain/User.groovy file to add a few properties:

class User {
	int id;
	String firstName;
	String lastName;
	Address address;
}

Also, edit grails-app/domain/com/znet/test/domain/Address.groovy to add its properties:

class Address {
	static belongsTo = [user:User]
 
	int id;
	String city;
	String state;
}

Now, edit the grails-app/resources/com/znet/test/api/UsersResource.groovy

import com.znet.test.domain.*;
 
@Path('/api/users')
public class UsersResource {
	@GET
	@Produces(['application/xml', 'application/json'])
	List<User> getUser() {
		User.list()
	}
}

This class will basically intercept any URL request going to /api/users and invoke the getUser method. That method uses standard GORM to return a list of users.

Before we test though, we need to get some initial content in our development database, add the following to the grails-app/conf/BootStrap.groovy file:

import com.znet.test.domain.*;
 
class Bootstrap {
	def init = { servletContext ->
		Address addr1 = new Address(id:1,city:'New York', state:'NY')
		addr1.save()
 
		User user1 = new User(id:1,firstName:'John',lastName:'Doe',address:addr1)
		user1.save()
 
		Address addr2 = new Address(id:2,city:'Los Angeles',state:'CA')
		addr2.save()
 
		User user2 = new User(id:2,firstName:'Jane',lastName:'Doe',address:addr2)
		user2.save()
	}
}

Running grails run-app should launch the server at which point the following URL should bring up an XML list with both users: http://127.0.0.1:8080/test/api/users

All that work with only a handful of code. It could not get much more easier than that. Add another property to the user object and wallah, it shows up. This model really allows you to quickly build up an API with little effort. Further, using the power and simplicity of the GORM domain model, you can map a database model into a composite domain model into an API model. The best part is you only have one set of classes to do so and Grails/JAXRS takes care of the mappings to/from the database and to/from the API. Further, you get both JSON/XML out of the box. For example, simply configure your browser to support application/json, it would render the output in JSON rather than XML. This is one of the downfalls of the JAXRS plugin however in that you have to tweak your browser manually. I actually created a simple mime-type filter that intercepts requests and sets the Accept header mime-type accordingly. This allows you to suffix a URL with .json or .xml or set a query param such as format=json. Drop me a comment if you are interested in learning more about that filter.

The JAXRS documentation has much more information on other cool facets. One of those is the ability to generate scaffolding of domain-based resources including lists, gets, puts, and posts via the generate-resource command. This truly provides the complete database to API modeling.

That is the simple method. My case, however, did not use GORM or databases, but instead JMX. So what does JAXRS offer us here? The JAXRS actually handles domain classes differently from plain POJOs or POGOs. In fact, out of the box, you cannot simply create a POGO and expose it automatically. However, doing so only involves a few lines of code to expose a custom provider. Create a new directory in grails-app called providers. Within that directory, create a new Groovy class (creating any associated subdirectories per the package name).

@Provider
@Produces(['text/xml', 'application/xml', 'text/x-json', 'application/json'])
class DomainObjectWriter extends DomainObjectWriterSupport {
 
	boolean isWriteable(Class type, Type genericType,
	                    Annotation[] annotations, MediaType mediaType) {
		return true;
	}
 
	protected Object writeToXml(Object obj, OutputStream entityStream, String charset) {
		def xml = obj as XML;
		xml.render(new OutputStreamWriter(entityStream));
	}
 
	protected Object writeToJson(Object obj, OutputStream entityStream, String charset) {
		def json = obj as JSON;
		json.render(new OutputStreamWriter(entityStream));
	}
}

This basically tells the Jersey and JAXRS environment to load the provider class and use it for handling marshaling to JSON and/or XML. The actual implementation only involves delegation to the great built in support exposed by Grails and the XML and JSON converters. Those converters have built-in support for POJOs, POGOs, as well as any other custom registration schemes. For example, to register a custom handler, create a new Groovy class (ie: within src/groovy):

class CustomObjectMarshaller implements ObjectMarshaller<JSON> {
 
	public boolean supports(Object object) {
		// check if this marshaller can handle the specified object
		return true;
	}
 
	public void marshalObject(Object object, JSON json) {
		// render object
		JSONWriter writer = json.getWriter();
		writer.object();
		writer.key('hello');
		json.convertAnother(object.toString());
	}
}

This is a really simple example, but you essentially register a marshaller per mime type (JSON, XML, etc) and then use the custom writers to write out properties and values. Ideally, you would invoke convertAnother using a sub-property of object which would find the associated marshaller for that object.

Going back to our example JMX use case, I can now create composite domain models in src/groovy such as:

class JmxNode {
	String name;
	String description;
	String objectName;
	List<JmxAttribute> attributes;
}
 
class JmxAttribute {
	String name;
	String description;
	String dataType;
}

If I were to build that domain model and expose it to a resource, it would render out the complete domain graph. Note that you will end up with other properties such as class and version which are part of the POJO/POGO. If you want to remove those, simply create a custom handler/marshaller to not render those properties.

These examples are fairly trivial, but as you begin to add business logic, they will begin to become more complex. As resources are grails artifacts and as such spring beans, you can inject them as any other controller. This allows me to keep resources clean and delegate to services. As such I inject services as such:

@Path('…')
class JmxNodeResource {
	// inject the associated service
	def jmxNodeService;
	..
}

The actual service is responsible for building up each part of the domain part. A given service may delegate to other services to build up the composite model. For example;

class JmxNodeService {
	// inject the attribute service
	def jmxAttributeService;
 
	JmxNode getJmxNode(…) {
		JmxNode node = new JmxNode();
		// build up node
		// get list of JMX attributes
		node.attributes = attrs.collect { attr ->
			delegate building of JmxAttribute to the attribute service
			jmxAttributeService.getJmxAttribute(attr)
		}
	}
}
 
class JmxAttributeService {
	JmxAttribute getJmxAttribute(…) {
		…
	}
}

Now, we have clean separation from marshaling, resources, services, and domain. In a sense, MVC for RESTful applications. So far, though, we have only hit the tip of the iceberg, so let’s take one more example and dig a bit deeper.

My API example allows me to specify the JMX host as part of the URL for which I want information on. The API basically acts as a JMX router allowing JMX properties over a common XML/JSON format. We saw earlier on that we use @Path to define the URL. Does that mean I have to have a resource for every single JMX host? Of course not…we use substitution params and inject the values into our methods. For example:

@Path('/api/jmx/{service}/mbeans/{node}')
class JmxMBeanResource { … }

This path basically allows me to specify a service as well as an MBean node. For example, the following URL would invoke this resource class:

/api/jmx/serverB:5555/mbeans/java.lang.Management

To actually perform the lookup and handling, I delegate the resource to a JmxMBeanService class:

@Path('/api/jmx/{service}/mbeans{node}')
class JMXMBeanResource {
	def jmxMBeanService; // inject service bean
 
	@GET
	JmxNode getJmxNode(…) {
		return jmxMBeanService.getJmxNode(…);
	}
}

The service is a standard service (i.e.: grails create-service) that uses JMX (check out the GroovyMBean helper class) to lookup the MBean information and returns it as a JmxNode with a list of its JmxAttributes. It’s as easy as that and the resource stays very clean. However, we are still missing one part…the injection of the path parameters. Here is where Jersey and its annotations come into play. We inject them into the method signature:

@GET
JmxNode getJmxNode(@PathParam('service') JmxService service, @PathParam('node') String node, 
	           @QueryParam('user') String user, @QueryParam('pass') String pass) {
	return jmxMBeanService.getJmxNode(service, node, user, pass);
}

The first parameter injects a portion of the path as denoted by the ‘service’ substitution variable. In our test URL above that would be ‘serverB:5555‘. However, notice that we are injecting a value of type JmxService rather than String. Jersey accepts any primitive type or pre-defined type (String, Date, etc). If you need a custom type, just make sure that the custom type supports a public constructor taking a single String parameter or supports a static Type valueOf(String) method similar to Integer.valueOf(String).

The third and fourth parameters allow injection of custom query parameters to allow values to be passed in other than via standard path parameters. Jersey actually supports quite a few injectable values including cookies, headers, etc. Jersey will perform type validation and you can even specify formats and regular expressions within the substitution params to add further validation logic.

As you can see we have written only a handful of code, most being the business logic aspect, and have a full defined API. If you would like a complete sample of the code, just let me know. I will most likely be open sourcing the API portion to GitHub later this month.

Thanks and as always enjoy. If you have any questions, drop me a comment below.

Nick

I’m not sure the new method makes entire sense though. On iOS and touch-based devices, it completely makes sense as you are literally dragging the screen with your finger. It’s a natural interaction as if you are actually pulling a piece of paper up to further read the document. Before the introduction of multi-touch trackpads, scroll bars were the primary way to perform scrolling. Scroll bars naturally pull down to scroll down. As a result, you are actually dragging from top to bottom. Scroll bars were never meant to interact directly with the viewport, but rather was meant to specify where within the viewport the content should be viewed. It was like a range widget, for example. Both of these cases were extremely natural. Then, multi-touch trackpads came on the scene with two-finger scrolling to be able to ditch the scroll bars. In this scenario, Apple maintained the top to bottom equals scroll down mentality to make it similar to as if you were literally dragging the scroll bar. In essence, two finger scrolling was just a quick and easy way to drag the scroll bar. Now, that logic has been completely flip-flopped and Apple wants you to think in terms of literally dragging the content rather than interacting with a scroll bar. The problem I have with this is that you are not literally dragging and touching the document. You are interacting with a physical touchpad. Further, it is inherent to the brain that you pull down to drag down and pull up to drag up. For example, a mouse with a scroll wheel would still scroll properly as it just makes sense. You want to scroll down, scroll the mouse down. The same should prolly hold true for the touchpad. Otherwise, it is like trying to trick your natural brain impression. It’s like trying to pat your head and rub your stomach…sure it can be done but you have to trick your brain to do so.

Here is a test to perform for yourself. Imagine you have a touch screen macbook. Without thinking try to scroll this article up and down with your finger. You will prolly notice you tried to literally drag it from top to bottom to scroll down or vice-versa. It just makes sense which is why it makes sense on iOS. Now try to do the same experiment from the touchpad and you’ll almost certainly want to do the opposite because you are now thinking in terms of scroll bars, not windows (after all you are interacting with the scroll, not the window). The only question I have is whether that rationale is because we have become used to scrolling in that sense from trackpads or whether it truly is natural. Apple is betting on the former and expecting over time that the natural expectation will change to better align with iOS. I will play with their little experiment for now, but I’m guessing I may switch back at some point.

How are others handling the change in Lion? Switched yet? Think the new way makes natural sense?

[UPDATE Aug 8, 2011]

It has been a few weeks now using the new scrolling behavior and honestly I have got used to it (most of the time at least). I still find myself at times reverting to the old system and I’m still convinced it is due to the inherent expectation of using a scroll pad to do so. The biggest issue, however, is that my brain is now really confused since at home on my Mac I use one method and then at work on my PC I use the opposite method via the scroll wheel on the mouse. I keep going back and forth in my brain.