The Problem
In the past I’ve always used ruby-debug (or more recently debugger) to set breakpoints and debug my rails integration tests built with Capybara and Selenium. A problem I’ve continually run into is that when the debugger launches it suspends all threads, including both the thread Capybara is running on as well as the rails server thread, so when trying to do something with Capybara that requires a server response it just times out.
Just to verify this behavior of ruby-debug/debugger, you can try:
When the debugger launches, if you try something like sleep 2 to pass some time, the separate thread will stay suspended, and it’ll only actually print “done!” once you exit the debugger.
Use a REPL instead
The suspended threads issue can be avoided entirely by using a REPL (read-evaluate-print loop) instead of a breakpoint. Doing this with IRB requires some trickery to get the context right, but with Pry it’s super easy:
This allows you to run Capybara methods (visit, fill_in, etc) directly, with other threads running happily so the rails server will respond as needed.
A helpful helper
Here’s the helper I use to manage which browser is in use:
Example spec
Here’s how it looks in practice:
This assumes the helpers sign_in_as and add_comment exist, just for the sake of keeping the example short.
At first it was tempting to use a helper like “as_user(:bob)”, but each time Capybara.session_name is set to a new value it opens a new browser instance, so across a bunch of request specs opening as different user names you could end up with a lot of browsers open which can have a substantial memory footprint.
The Underlying Technology
As amazing as SproutCore is, it did not in fact invent the methods it uses to handle history for single-page applications. Applications like Gmail have been doing this for quite a while, and it basically involves setting the browser’s location with JavaScript, then monitoring the location and taking appropriate action if the user has navigated to a previous (or subsequent) location in the browser history.
In particular, these single-page applications use the location.hash that’s available in JavaScript, which provides the portion of the current URL that follows the ‘#’ character. For instance, if you’re at http://example.com#inbox, location.hash will return “#inbox”. If there is no ‘#’ in the current URL you’ll just get and empty string. Here’s how SproutCore handles history, as illustrated by the Routes sample app:
Registering a route
In order to make use of routes in SproutCore, you need to register any route changes you want to watch for. This is done by providing a route string that is matched against the browser location, along with a target object and method you want called on that object. Since route changes will often coincide with state changes, it makes sense to use responders to handle them. The Routes sample application has a superstate, Routes.states.root, that all of the other states are substates of, so this is the responder that is registered:
Now that this route has been registered, any time the browser location hash changes the route method in Routes.states.root will be called, with a hash that has a number property consisting of everything to the right of the ‘#’ character in the URL. SproutCore will now monitor the location hash for changes that match this route, either in an event-based way for browsers that support it, or by using a timer.
Setting your location
You set a route in SproutCore by setting the location property for SC.routes, for instance SC.routes.set('location', 'here'). In the Routes sample app, when a change in the location hash occurs and the route method in SC.states.root is called, that method simply passes the number property that was captured to the go method:
In the go method, the location is set to the route number that is passed in, and as a nice touch the browser title is also updated to reflect the current route number. Finally, the state is set with Routes.makeFirstResponder.
Following route and state changes
Now that they key players have been identified, it may be useful to follow the flow of events when actually interacting with the app. Assume we’re running sproutcore-samples at http://localhost:4020.
Immediately upon entering the app by browsing to http://localhost:4020/routes, the route that was set by SC.routes.set above will notice the initial URL as a “change”, call the route method in SC.states.route, and in turn enter the go method. Since the location hash starts off empty, the following code in go will default to the one route, and then set the location hash, browser title and state to one:
So the URL that we intially see once the app is done loading is http://localhost:4020/routes#one. Now let’s say we click on another button, three for instance. Looking in resources/main_page.js we can see that all of the buttons have go as their action:
Currently the state is Routes.states.one, however when we look there we see that this state doesn’t define the go method itself. Instead, all of the substates simply define Routes.states.root as the nextResponder:
This is what makes these substates of Routes.states.root, so the go call won’t be found in the first responder, causing it to go up the chain to Routes.states.root. This will in turn change the current URL to http://localhost:4020/routes#three, update the page title and set the state to three. Importantly, each time the current route is changed, those changes are reflected in the browser history. We could continue clicking buttons like this as long as we’d like, accumulating a history of being in the different locations that each button correspond to.
If we next hit the back button in our browser, that will change the browser URL back to http://localhost:4020/routes#one. Because of the route we added, this will trigger calling go in the root responder, and in turn the page title and state being updated to one.
Wrap-up
The Routes sample app provides a simple, albeit contrived, example of how routes and states allow us to use history in our apps. In order to apply this to a real app, you would need to consider what states in your app you’d like to make available in the browser history, and how you would accomplish transitioning to those states from essentially any other state in your app. I only know of one real app that uses responders and routes for history management, SproutCore Tests. There are some interesting nuances to how it works with routes, so it’s certainly worth a look if you have the time.
Signup
We’ll start by looking at a very simple example of managing state using responders, the sproutcore-samples app Signup (code here and demo here). It has just three states: START, READY and SIGNUP. Although I don’t know how the original author of the Signup sample would have drawn the statechart for this (or if he would have even bothered), here’s one way to draw it:
We’ll trace through the app and see how it goes from one state to another, and what happens in each state.
START state
The START state is *transient*, meaning that the app should exit from it to another state automatically based on an internal event. In order to get into the START state, the main() function makes it the first responder when the app loads:
Once in the START state, the didBecomeFirstResponder method is automatically invoked. Inside this method, we see that it simply looks at the hasContent property of the current account controller, and goes to the READY state if it has content or the SIGNUP state if it doesn’t. So we see that the START state doesn’t really do anything, it just serves as a switch between the two other states:
SIGNUP state
Since the currentAccountController won’t have any content when the app loads, it will go into the SIGNUP state. The didBecomeFirstResponder method will be automatically invoked, and do two things: set up a new user to edit and display the signup dialog. One interesting tidbit here is that a nested store is set up by calling Signup.store.chain(). This allows the entire user record can be committed at once when the signup dialog is submitted (or discarded if instead the user cancels).
There are two ways the application can exit the SIGNUP state, either by the Submit button or Cancel button being hit in the signup dialog. Here are those buttons:
Note that these buttons don’t have to set a ‘target’ property, since the actions will automatically go to the first responder, which is currently Signup.SIGNUP. In order for this to work though, the MainPane has to have it’s default responder set to the app’s namespace:
If the user hits submit, then the nested store with the user record is committed and assigned to the currentAccountController, and if the user hits cancel then the user record is discarded. Either way, the last step of both the ‘submit’ and ‘cancel’ methods calls ‘Signup.makeFirstResponder(Signup.READY)’. One last thing does happen though as the state is changing. The willLoseResponder method is called in Signup.SIGNUP, which clears the nested store and signupController, and displays the mainPage (effectively closing the dialog).
READY state
The READY state displays Signup.mainPage, which will show the user associated with the accounts controller, or if there’s no user it will show a message indicating that. The READY state can only be exited by the ‘signup’ action, which just transitions the app back to the SIGNUP state:
The other possible action is ‘logout’, which clears the current account controller but doesn’t affect the state.
What’s gained by using Responders?
Hopefully it’s now a bit more clear how responders can be used to manage state in this simple example, but an interesting question to ask at this point is what the app would look like without responders, and therefore what we’ve gained. Essentially, you’d have to weave all the state management in the responders into the other parts of your app, presumably the controllers. This would probably look fairly reasonable in the Signup example, but for more complex apps where you’d have multiple states that could be accessed from a single interface, you’d end up with lots of logic in your controllers to make them state-aware. SproutCore makes a good argument for making responders their own layer, beyond the standard MVC layers.
I spend most of my time using Ruby on Rails, but enjoy exploring other web application frameworks. There’s a wonderful diversity of frameworks out there, with more popping up all the time, but there are two challenges I’ve found with trying to find ones I want to investigate:
After numerous occasions of such exploration, it occurred to me that I may not be the only one who does this sort of thing. I decided to formalize my methods for turning up nuggets of web framework goodness and share the results with others. I was also inspired by The Ruby Toolbox, which beautifully does what I’m talking about for Ruby plugins/gems. But unlike Ruby, where essentially everything interesting is happening on github these days, not all (or even most) web frameworks have their source code hosted on github. This meant employing some different tactics for rating popularity.
Since github stats aren’t universally available, I decided to look at other measures of popularity. Traffic statistics seemed a reasonable approach, but these too weren’t universally available since many web frameworks don’t have their own domain (e.g. Tapestry is at a subdomain of apache.org), and traffic statistics are typically only available at the domain level. I also considered looking at things like Google search trends or Twitter mentions, but the problem with these is one of specificity. For example, I can be fairly sure that any time I see SproutCore come up on Twitter it’s referring to the framework, but Cappuccino mentions could very well just be talking about the caffeinated beverage. So the third measure I’m employing is the number of inbound links, since these are specific and can be checked against any URL.
So inbound links seem to be the lowest common denominator for measuring popularity, but it would be a shame to neglect the other popularity measures where they’re available. Plus, inbound links are sometimes biased, for instance many Django apps have a “Powered by Django” link at the bottom so Django has an enormous number of inbound links. What I decided to do is take whichever of the three popularity measures (github stats, site traffic, inbound links) are available for a framework, and average them. But since the raw statistics are on very different scales, I first put them on a 0-100 scale, and then simply average the three scores. It’s not incredibly sophisticated, but seems to get the job done.
See the results at:
HotFrameworks (http://hotframeworks.com)
Currently there are really just three components to the site: rankings charts, individual stats for each framework, and a blog. This is just the first iteration though so there’s plenty more I can envision adding.
When implementing a trivial timer application in Cappuccino, RestfulX and SproutCore, one thing that struck me was how varied their approaches were to handling interaction with a server back end. Cappuccino has the lowest level abstraction here, while RestfulX takes care of more of the process and SproutCore has a high-level and somewhat complex system for server interaction.
Cappuccino
The Cappuccino framework provides the CPURLConnection class, which handles XMLHTTPRequests, although the level of abstraction is fairly low. For instance, here’s what I use to submit a request to create a new project in Clocky/Cappuccino:
This does allow greater flexibility for any type of back end, however.
RestfulX
RestfulX has a higher level of abstraction, with Service Providers for JSON, XML and others, and models that use the service provides when they’re asked to be created/updated/etc. This allows you to use create a new project (after setting it’s properties) with something like:
Of course, the JSONHTTPServiceProvider assumes a standard Rails-style “REST” JSON API, which is great if you’re using Rails, but you’d need to roll your own service provider if you’re not using a back end that’s Rails-style or one of the other existing Service Provider types.
SproutCore
SproutCore clearly has the highest level of abstraction for server interaction, although it’s a bit complex so it may seem intimidating at first. There are actually 3 levels as I understand things: the model, the data store and the data source. Your models (e.g. projects in Clocky) are locally stored on the client in the DataStore, which is back end-agnostic. The data source layer lies between the data store and your server, so it handles putting together the right XMLHTTPRequest. What’s great is that the SproutCore actually keeps track of state on model objects, and you just have to make your application respond to these states appropriately. Unfortunately you have to roll your own data source, and for me getting SproutCore to talk with my standard Rails backend took almost as much time as doing the rest of the app (it would have been easier if I’d been willing to adopt the JSON structures to what SproutCore likes). Of course now I have a fairly generic Rails data source that I could use on future projects.
The winner: it depends
Determining which framework handles back end integration the best will depend on how you want that interaction to work. If you’re doing Rails-style REST on the back end, then RestfulX and SproutCore are going to take care of a lot of the details for you. SproutCore’s ability to track state and do local queries using the data cached on the client could save you a lot of work if you think you’d end up having to implement that yourself with the other frameworks. But if you roll your own back end or don’t plan on doing CRUD over HTTP then you won’t miss what the others have to offer by going with Cappuccino.
Now that I’ve finished implementing a trivial timer application in Cappuccino, RestfulX and SproutCore, I want to delve into and compare a few aspects of developing in these frameworks. Of course all of my comparisons will be biased by my choice of application to implement, so I’ll certainly miss exciting parts off these frameworks that I didn’t have the opportunity to explore.
One aspect of working with these client-side frameworks that I found challenging was debugging, which is particularly important when first learning them and experimenting with how to properly use their not always well documented APIs. Compared with server-centric frameworks, even ones based on dynamic languages like Ruby, there are far fewer clues when something goes wrong.
YMMV
When the client lives in the browser, your choice of browser and accompanying tools/add-ons becomes important. The two real choices seem to be either Firefox with the Firebug add-on or Safari with its developer tools. As I’m developing in Linux, I use Firefox/Firebug, so my comments may not be valid for Safari
Compiled or non-compiled
One of the best and worst things about using RestfulX is the compile step. It slows down the development cycle a bit, but does catch a lot of errors. This would be a moot point if SproutCore and Cappuccino were able to report errors, but unfortunately that’s often not the case. I found that both of these frameworks repeatedly left me either with a blank page or a semi-functional interface and no console errors to help me find where things went wrong. Of the two, SproutCore seemed to provide helpful error messages more frequently, and when it did it could show the location of the error in the source, which isn’t currently possible with Objective-J
Logging and Breakpoints
I could be wrong, but from what I understand the only way to use breakpoints with RestfulX (Flex) is to use Flex Builder. Given that it costs a bit of money and I only wanted to briefly explore RestfulX, I stuck with logging, which still took a bit of effort to set up since I needed to have the developer version of Flash. SproutCore had the best free breakpoint setup since all the code is JavaScript and you use the breakpointer in Firebug as you would with any other JavaScript code. It’s also supposed to be possible to hard code breakpoints into your code in Cappuccino and then step through the Objective-J that’s been turned into JavaScript, but I ended up sticking with just plain old logging for Cappuccino as well.
Conclusion
Overall, given that I’m using Firefox and Firebug I found the SproutCore and RestfulX debugging processes to be equal in difficulty, but for different reasons, and Cappuccino slightly harder than either.
Cappuccino is the third framework I’m including in my project to implement a trivial time tracking application in multiple client-side/rich frameworks. Cappuccino was created by the guys over at 280 North, and originally showcased by their 280 Slides application. Like the SproutCore framework I recently explored, Cappuccino has its roots in Cocoa, but while SproutCore just draws on Cocoa for inspiration, Cappuccino attempts to reproduce a subset of the Cocoa API on the web and uses the Objective-J language that is roughly Objective-C built on JavaScript.
Since Cappuccino and SproutCore are so similar, it’s perhaps worth looking at some notable similarities and differences that I ran across when implementing the trivial timer application in each:
Without any experience using Cocoa/Objective-C I didn’t have the immediate familiarity that is no doubt very enticing to developers coming from that background, however the Objective-J syntax was relatively easy to get used to and the API still seems sensible even without that experience. As with the other frameworks I’ve looked at, Cappuccino is fairly young so the documentation and tutorials are sparse as compared with more mature frameworks.
Now that I have three frameworks (Cappuccino, SproutCore and RestfulX) under my belt, it would be interesting to write more on specific aspects of developing with these frameworks, but I’ll save that for later. For now I’ll simply post a link to the source code, which tells all: http://github.com/bruz/clocky-frontend-cappuccino
You can never be completely sure of how well a Linux distribution will work on a laptop until you actually give it a whirl. I just got a new (well, refurbished) Dell Vostro 1220, crossed my fingers as I installed the latest Karmic Koala (9.10) Ubuntu release, and was extremely pleased with the results. So far I’ve verified that all the following work without any tweaks:
The wifi didn’t immediately work, but after plugging in to a wired network and doing all available Ubuntu updates, two options for wifi drivers became available. Based on what I read in a couple of forums I went with the proprietary driver from the vendor (Broadcom STA) that was reputed to work a bit better.
Performance is great with ext4—I’m seeing about 15 second to boot up. Battery life is roughly 3-4 hours with the heavy flogging I inflict upon it. Looks like this will be a great laptop for the long bus commute.
SproutCore is the second framework I’ve used in my project to implement a trivial time tracking application in multiple client-side/rich frameworks. SproutCore, the framework behind Apple’s MobileMe, is one of the heavyweight contenders in the desktop-like web application arena. Originally released last year in version 0.9.x form, it has undergone major changes over the past year+ to the currently near-release 1.0 version. Thankfully my experience with SproutCore started as it was becoming more stable towards the 1.0 release, although the documentation still hadn’t all caught up to the 1.0 changes (but has since been massively updated and is in good shape now). SproutCore is a Cocoa-inspired framework, but is implemented in JavaScript so it makes use of some of the good aspects of the language. JavaScript as the language choice comes in contrast to RestfulX which uses ActionScript 3, and Cappuccino which uses (and created) Objective-J. Since I’ve already looked at RestfulX, it’s interesting to note some similarities in the platforms. Both have: