Thursday, November 11, 2010

SpringOne 2010: Harnessing the Power of HTML5

I spent the second-last week of October at SpringOne 2GX 2010 in Chicago and I thought some of you might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Harnessing the Power of HTML5
presented by Scott Andrews (@scothis)and Jeremy Grelle (@jeremyg484)

First up, the guys cleared up some confusion by explaining that the term HTML5 is currently being used to encompass much more than just the latest W3C HTML spec, but also all of the related sets of technologies that are now being standardised in an attempt to ease the creation of dynamic webapps. It really means HTML 5 + CSS 3 + new JavaScript APIs like WebSockets and WebWorkers.

They demonstrated a lot of the upcoming technologies through the rest of the talk by showing a presentation from html5rocks.com, a site Google has put together to promote the stuff.

Web storage (which, ironically, means storing data on the client) is coming. Local storage – a basic key/value store – is pretty much standardised. Another idea for a client-side database is still being discussed, but has been implemented in WebKit and hence is available on many mobile devices. Note that the data in this database would, like cookies, not be accessible by scripts from other sites, but would be unsecured on the local machine. Likely uses are things like data storage for offline access of cloud data. (That's cloud computing data, not meterological readings.)

There is now an application cache manifest that allows the server to instruct the browser about cacheable resources and allows the browser to skip checking the last modified date/time of these resources as long as the date/time of the manifest hasn’t changed.

Web Workers allow JavaScript code to execute something in a separate process. They mentioned that this is specifically a process and not a thread, the implication being that the spawned process doesn’t have access to the memory of the parent.

Web Sockets are being billed as the new XHR and the new Comet.

Javascript Notifications will allow the application to request the browser to show a Growl-style status popup, but only if the user has already given permission for the site to show these.

Drag and drop is being supported at the browser level.

There is a proposal to provide access to a user’s current latitude and longitude.

Scott and Jeremy recommended that people not try to use these new features directly, but continue to use the various existing JavaScript libraries that already do the same thing, with the hope being that these libraries will, over time, be upgraded to use (and abstract) the native support where it is available (assuming the native support will be better than the current methods).

There are new semantic tags in HTML 5 for <header>, <nav>, <section>, <article>, <aside>

HTML 5 includes new link/rel types include ‘pingback’ which will allow a page to provide a URL for the browser to call if the user leaves the site, and ‘prefetch’ to specify other pages for the browser to load into the cache in anticipation of where the user might go next.

There are new HTML form input types that restrict the type of data that can be entered as well as providing some visual, optimisation and input hints, which is especially useful on mobile devices. New input types include date, email, range, search, tel, color and number.

There is also the ability to provide basic client-side authentication (without JavaScript) by specifying constraints such as required or a regular expression pattern. A new CSS :invalid pseudo-class can be styled to change the appearance of invalid fields declaratively.

There are new tags for defining ‘meter’ and ‘progress’ elements (the latter for both indeterminate and % complete).

There are plans to support embedded audio and video in HTML 5 without the need for any plugins, although there are currently arguments going on about what codec should be the standard.

There’s a Canvas element for just drawing pretty much anything using Java2D-like shape, line and fill constructs. There is a pretty impressive example in the Google slides where photos can be dragged, rotated and scaled. JavaScript is required to change the contents of the canvas, but the API as a concept looks pretty neat.

There is support for JavaScript events coming out of SVG objects using native HTML tags.

CSS 2 selectors like ‘first-child’ are being more widely supported and new ones like ‘not’ are coming in as well.

CSS is introducing font downloading, allowing everyone visiting you site to see the same font without having to use image replacement. (As someone who's had to do a bit of this in the past, I have to say 'yay!')

There are STILL experiments with having CSS manage column-based layouts (link from 2005!), although this is only implemented in WebKit at the moment.

CSS3 will support HSL (Hue/Saturation/Luminance) colour definitions.

border-radius for rounded corners is becoming standard, except in IE 9!!! Says the speaker: “So IE will be square.” (I've since tracked down an announcement on msdn.com that seems to suggest that border-radius will be in IE9.)

Gradients, shadows and animations are all getting some standardised support in CSS3.

It will be possible to intercept changes to the history (e.g. capture the back button) within an Ajax app and load data rather than allowing a whole-page refresh.

There is a library called Atmosphere that provides a server-side abstraction over Comet and WebSockets to allow these protocols to be handled on any Java web server (many of which currently support this stuff but through proprietary APIs).

They showed a pretty cool example where they were using Canvas and WebSockets on the client side with Spring Batch and Spring Integration on the server side to parse a large file, stream interesting data to the client through an Integration channel and visualise that data in the browser.

I've found this funky little website callled caniuse.com that allows you to specify browser names and versions along with HTML 5 features that you would like to use and it will show you the level of support in each browser & version for that technology.

Want to learn more?


From Amazon...


From Book Depository...


Saturday, November 6, 2010

SpringOne 2010: Concurrent and Distributed Applications with Spring

I spent the second-last week of October at SpringOne 2GX 2010 in Chicago and I thought some of you might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Concurrent and Distributed Applications with Spring
presented by Dave Syer

My favourite quote from this talk, and possibly from the whole conference, is one which I want to take back to my workplace and put into practice with avengeance:

Using single-threaded algorithms on 32-core machines is a waste of money

Dave also presented a really simple but useful definition of thread-safety:

Thread safety = properly managing concurrent access to shared, mutable state

Applying this definition, you can see there are three ways to tackle thread-safety: you can either eliminate mutability, or you can eliminate sharing or you can eliminate concurrency. Eliminating concurrency is the core aim of mutexs and locks, e.g. synchronized blocks. Eliminating mutability is one of the chief design idioms of functional programming.

On the topic of eliminating shared resources, Dave pointed towards the frequent use of ThreadLocal within the Spring Framework to associate unshared resources to individual threads. He made note of the potential for memory leaks with ThreadLocal, highlighting that, with the long-running threads in most servers, you have to ensure you clean each ThreadLocal up when you’re finished otherwise your data will hang around forever. (Sounds like going back to pairing new & delete!)

Dave talked about a method on ExecutorService that I've never used before called invokeAny() that will execute every task in a given list of tasks concurrently (assuming a multi-threaded ExecutorService implementation) and return the result of the first one to complete. The remainder of the tasks are interrupted. I imagine where you might use this is if you have a situation where you have two or three different algorithms, each of which can outperform the other two for certain structures of data, but where the most efficient algorithm for a given individual input can't be (easily) determined before execution. So, on a many-multi-core machine, you have the option of just running all three against the same data, taking the result from the first algorithm to complete and killing the others.

Dave briefly discussed an emerging (I think?) pattern for concurrency called Staged Event-Driven Architecture or SEDA.

He mentioned that Spring Integration 2.0 (RC1 released Oct 29) includes support for transactional, persistent message queues.

He highlighted the difference between between a distributed Applications (running the same binary on multiple nodes) and a distributed Systems (running related, communicating applications across multiple nodes). He said that it was wise to prefer looser coupled messaging architectures for distributed Systems because of the likelihood of unsynchronised release cycles.

Want to learn more?

From Amazon...

From Book Depository...

Friday, October 29, 2010

SpringOne 2010: Groovy and Concurrency

I spent the second-last week of October at SpringOne 2GX 2010 in Chicago and I thought some of you might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Groovy and Concurrency
presented by Paul King

Paul by started by mentioning a library called Functional Java which, to me, looks like an attempt at porting a bunch of ideas present in Scala over to Java, and another one called Kilim, which is an Actors library for Java.

Paul said that his main argument for why you should use Groovy, rather than Scala or Clojure, is that Groovy is closer to the Java syntax and, hence, is more easily integrated with Java. (In my personal experience, I can’t say I’ve ever had any problems integrating Java with Scala. Going the other way (using Scala in Java) has some gotchas, but wouldn't be described as hard.)

Groovy supports a very nifty pipe (‘|’) operator extension to the java.lang.Process class, allowing you to easily pipe stdout to stdin between two or more processes, just like in a shell.

I've now heard Google Collections (now part of the Guava libraries) mentioned for about the 5th time this week. I really should check out what these are because they’re very popular!

Groovy supports adding functions to classes, and even individual objects, at runtime. That is, your code can contain statements that add members to an existing type. This is not creating an inline definition of a new type, but actually changing the type at runtime, as you might do in JavaScript. They call this Dynamic Groovy. I've never really got my head around why meta-programming - programs that write programs (and then run them) - is a good idea, but I've also read Paul Graham saying that this feature gave him a major competitive advantage, so there must be something mind-bending about it. Perhaps I just need to give it a try?

Groovy has an @Immutable annotation that, as well as making the contained fields final (without you declaring them so), is also shorthand for adding getters, toString(), hashCode() and equals() to a class based on just the field names and types. Case classes in Scala provide the same functionality along with the added bonus of making pattern matching simple.

He mentioned two Java concurrency libraries, one called Jetlang for message-based concurrency (the Jetlang site itself refers to Jetlang being similar to Scala's Actors) and JPPF, a grid-computation library. The JPPF intro uses domain language similar to that of Spring Batch, with regards to jobs and tasks.

He talked a bit about GPars (short for Groovy Parallel Systems), a concurrency library specifcally for Groovy.

He also said that shared transactional memory looked interesting but didn’t go into it much beyond mentioning the Multiverse library. I have seen this term bandied around a little, in particular due to a couple of people attempting to implement it in Scala, but I've never looked into it - it's frequency hasn't yet punched through my signal/noise filter.

He gave a little preview of what the GPars guys are trying to achieve with a “Dataflows” library. You use a DSL to describe a dependency graph between steps in your (complex, but parallelisable) algorithm and Dataflows will automatically run in parallel those parts of the algorithm that are not dependent, synchronising at the points where multiple asynchronous outputs are required to enter the next step.

Want to learn more?

From Amazon...



From Book Depository...


SpringOne 2010: How to Build Business Applications using Google Web Toolkit and Spring Roo

I spent the second-last week of October at SpringOne 2GX 2010 in Chicago and I thought some of you might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

How to Build Business Applications using Google Web Toolkit and Spring Roo
presented by Amit Manjhi

Amit works at Google on the GWT (Google Web Toolkit) team. In this session, he showed the ease of creating a GWT app with Spring Roo and then talked through a a whole swathe of GWT best practices.

Roo supports the addition of JSR-303 constraints [PDF] as part of adding a field to an entity.

Creating a GWT webapp from an existing Roo domain model is as simple as typing gwt setup (and hitting enter) in the Roo console.

The default webapp generated by Roo automatically handles validation on the server side. I have to say that the default rendering for errors was pretty poor. The error he showed as an example just appeared at the top of the form and said something like "this field is required", without any reference to which field had caused the error. Room for improvement there, but you certainly get a lot of webapp for doing nothing much at all.

Bookmarkable URLs work out of the box, although I'm not sure if this meant that all URLs are bookmarkable by default or whether it's just easy to make URLs bookmarkable when you need them.

Amit showed a version of the same UI that some Google guys had jazzed-up with some nicer CSS and a few changes to the layout components. It was using some kind of slide transition where, when an item was selected from a list, the list would slide off to the left and the item detail slide in from the right, then vice versa when you went back. Looked very neat.

The Spring Roo addon for GWT generates the site using a whole bunch of best practices as learned by the Google Engineers who’ve been using GWT to develop the AdWords site.

The Model-View-Presenter pattern was presented as a suitable pattern for client-side GWT. This decoupling pattern allows different view implementations to be attached to the same Presenter.

Using DTOs (Data Transfer Objects) (as opposed to sending entities to the webapp) was recommended, though he did note that, coded manually, DTOs typically violate the DRY (don’t repeat yourself) principle. This downside is overcome by creating an empty interface for the DTO, annotated with a @ProxyFor annotation. GWT then automagically creates a proxy object for the entity class named in the annotation and this proxy acts as a DTO. The Google guys call this an Entity Proxy. From what I could tell, the proxy automatically proxies all value fields of the entity. You can provide annotated methods on the DTO interface that allow lazy navigation of entity relationships.

The default Roo project doesn'’t use GWT-RPC, chiefly because of the bandwidth implications when mobile devices are involved. Instead, they use an object on the client called a RequestFactory that talks JSON to a generic RequestFactoryServlet on the server.

RequestFactory receives notifications of the side-effects of its server-side calls and posts these as events on an event bus in the client.

They’ve replaced the Presenter with something they call an Activity that abstracts away a lot of the boilerplate normally required in a Presenter. The common parts of Activities are themselves abstracted out into a generic ActiviyManager.

He highlighted a proposed method for allowing search engine web crawlers to follow Ajax bookmarkable URLs by using #! to prefix the anchor rather than just #. Google have published an article called 'Making AJAX Applications Crawlable' where they discuss the details.

The talk became quite confusing past about half-way when it stopped being obvious (to me at least, having never written a GWT app) which code samples were part of the server and which were run on the client. My kind request to any GWT talk presenters: please introduce each code-sample slide by saying “This code runs on the {server|client}”.

GWT has a nice SafeHtmlUtils class for escaping HTML entered by users to avoid cross-site scripting (XSS) attacks.

GWT 2.1 contains a client-side logging library in the vein of the JDK logging. Spring Roo-generated GWT apps come with a handler that allows client events to be logged on the server. You can also use a GWT <property-provider> element to enable and disable logging at runtime on a per-user scope. (There's some information about property-provider here under the heading 'Elements for Deferred Binding'.)

Want to learn more?

From Amazon...


From Book Depository...


Wednesday, October 27, 2010

SpringOne 2010: Creating the Next Generation of Online Transaction Authorization

I spent the second-last week of October at SpringOne 2GX 2010 in Chicago and I thought some of you might get something useful out of my notes. These aren’t my complete reinterpretations of every slide, but just things I jotted down that I thought were interesting enough to remember or look into further.

Creating the Next Generation of Online Transaction Authorization
presented by Maudrit Martinez, Anatoly Polinsky and Vipul Savjani

These three guys from Accenture presented patterns of architecture with Spring Batch and Spring Integration that they have used in production systems for both online and batch processing of financial transactions.

Their diagram showed two technologies – Pacemaker and Corosync – that I hadn’t heard of before. Apparently Corosync is the clustering technology recommended by the Rabbit guys. They also used a product called Hazelcast for a distributed cache and Grid Gain for a compute grid.

They combined Spring Batch with Grid Gain in order to partition the processing of a batch of transactions across multiple nodes. The presenter was fairly impressed with GridGain’s over-the-wire classloading. (To be fair, this idea has been around at least since RMI was released in '97.)

Rather than passing the transaction data around their whole integration network, they instead placed the data in the distributed cache and passed around only the keys to the items in the cache.

They made use of a library called ScalaR, which is a DSL for using GridGain in Scala. They used Scala to process the transactions chiefly because of the availability of the ScalaR DSL and also due to its provision of Actors for simplified concurrent programming. and because, due to the need for performance, they didn’t want to use an interpreted language like Groovy.

They mentioned that parts of GridGain (though perhaps only the DSL) have reportedly been re-written in Scala, and that the GridGain team chose Scala over Groovy because of its compiled, static typing providing better performance than interpreted languages.

They showed where their code was calling Hazelcast and I noted that there wasn’t any attempt at decoupling the cache implementation – a Hazelcast instance was retrieved by calling a static method. Perhaps it was just some demo code they'd thrown together.

I noticed a cool way of converting a Scala list to a Java list that I hadn’t seen before:
new ArrayList ++ myScalaList
From what I can tell, this ++ operator isn't standard (at least you can't use it in the Scala 2.8 REPL), but it was an interesting, succinct syntax that caught my eye.

They mentioned the STOMP protocol, which is a text-based protocol for message broker interoperability supported by Rabbit MQ, among others.

The Spring Integration config they used to send a message to Rabbit didn’t have any implementation, but just an interface they had defined which was then proxied by Spring to send a payload onto the channel.

They mentioned a couple of times that the advantage of Rabbit MQ over JMS is that Rabbit's AMQP is an on-the-wire protocol whereas JMS is a Java API. They didn’t elaborate on why this was an advantage, but I suppose the protocol easily allows other programming languages to integrate with the messaging, where as a Java interface doesn’t offer any standard way to do that.

Their implementation for processing transactions used a chain of three actors: #1 for coordinating the authorisation of the transaction (I think – it may have been for coordinating the authorisation of multiple transactions?), #2 for performing the authorisation, which chiefly meant looking up a collection of rules and then passing these rules off to Actor #3, which was an executor for the Rules.

While searching for an online profile for Anatoly Polinsky, I found this great presentation on Spring Batch that he apparently authored. It also looks like he has released some of the code from the presentation in a project called 'gridy-batch' on github.

Want to learn more?

From Amazon...

From Book Depository...