Every web site that has some concept of user login also has some concept of user roles. Administrators have special editing access or behind the scenes report views. Users with different relationships have different ability to view the other user's data, and so on. In my experience, every site's requirements along this line are just different enough that a one-size-fits all plugin approach to roles never quite works.

That said, there are some common principles that I've found helpful in implementing roles and security.

When blocking entire controller actions, use filters

This one should be pretty familiar, since the restful_authentication plugin recommends placing before_filter :login_required at the top of any controller that requires the user to be logged in. Similarly, you'll want something like before_filter :admin_required, :only => [:create] for the controller actions that require administrative users.

Before filters are simple and powerful. It's also very easy to forget to add a new action to the :only list (especially for non-RESTful controllers). So, be sure and test with something like this, assuming that logged_in? and the home controller are defined.

 
should "not let regular users see the edit page" do
  login_as :normal_user
  post :create
  assert not logged_in?
  assert_redirected_to :controller => "home", :action => "index"
end
 

Note this test also asserts that a user who tries to access a forbidden page is logged out. You probably also want to test for the case where nobody is logged in -- at least where the functionality isn't already covered by restful_authentication or whatever login package you are using.

Also, the Footnotes plugin contains a tab for checking all the filters called on a given request, which is very helpful when trying to debug weird behavior.

When blocking part of a page, try a block helper

Another common role based security need is to only expose part of a page to a particular user role. For instance, only an administrator or the actual poster can edit a forum post. What I like to do here is combine partials and block helpers, with a helper that looks like this:

 
def if_current_admin
  yield if current_user.admin?
end
 

And an ERb file that looks like this:

 
<% if_current_admin %>
  <%= render :partial => admin_edit_content %>
<% end %>
 

(Alternately, if the partial is always going to be restricted, the if statement could go in the partial).

Unfortunately, if you have if/else functionality, the block helper is less pretty because you wind up with something like this:

 
<% if_current_admin %>
  <%= render :partial => admin_content %>
<% end %>
<% unless_current_admin %>
  <%= render :partial => user_content %>
<% end %>
 

Which is a lot less nice than:

 
<% if current_admin? %>
  <%= render :partial => admin_content %>
<% else %>
  <%= render :partial => user_content %>
<% end %>
 

The advantage of moving all this stuff into guarded partials it it keeps your main page somewhat clean and makes it easier to figure out what's going on.

Use negative assert_select testing

When doing a guarded view block like the ones above, you also should test to make sure that the correct content is displayed and that the incorrect content is not displayed. The assert_select function lets you assert that content is not in a result, which is helpful.

Let's say you have two tests, and assume that everything's been defined properly:

 
should "show admins the administrative content" do
  login_as users(:admin)
  get show, :id => thing(:one)
  assert_select "div#admin_only_content"
end
 
should "show users the user only content" do
  login_as users(:normal_user)
  get show, :id => thing(:one)
  assert_select "div#user_only_content"
end
 

The tests would still pass even if the user gets the admin_only_content div. You can avoid that potential problem by using the :count option of assert_select like so:

 
should "show admins the administrative content" do
  login_as users(:admin)
  get show, :id => thing(:one)
  assert_select "div#admin_only_content", :count => 1
  assert_select "div#user_only_content", :count => 0
end
 
should "show users the user only content" do
  login_as users(:normal_user)
  get show, :id => thing(:one)
  assert_select "div#admin_only_content", :count => 0
  assert_select "div#user_only_content", :count => 1
end
 

In the second batch of tests, you are explicitly asserting that the incorrect DOM element is not in the output. This is a very handy feature when testing for behavior under different roles, I use this all the time.

Put active record guards in the model

Eventually, the question of whether active record content can be saved by a particular user is a business logic question that should be handled by the model layer. I don't think this can be made totally goof-proof (you might be able to do something with callbacks, but I haven't hit on the magic words yet). However, you can promote an API that makes it easier for your development team to do the right thing:

 
def self.create_from_params_if_user_can(current_user, params = {})
  return unless self.user_can_create(current_user)
  create(params)
end
 

From the controller, this would look like:

 
def create
  Thing.create_from_params_if_user_can(current_user, params[:thing])
end
 

Putting a guard in the ActiveRecord class may seem redundant, if you have a good before filter in place, then the create method will only be called by valid users. However, as your application gets more complicated, the create method may be called by different user types, each with different rights to do different actions. Alternately, Thing objects might be created from other places. Keeping the actual model rights logic in the model makes it easier to keep the logic clear and straight.

Don't take inputs for granted

Even in cases where the user ID might be passed back via a form or URL parameter, you still should use the stored session current user to determine rights (with the obvious exception of the actual login where you are authenticating with a password). You want to prevent somebody from hijacking the session by passing in the parameter of a user with more or different rights.

Along the same lines, when checking for objects via a relationship, always check via the association proxy. That is, do this:

 
current_user.articles.find_by_active(true)
 

And not this:

 
Articles.find_by_user_id_and_active(params[:user_id], true)
 

This limits the ability of a user to URL surf.

I'm excited to announce the arrival of Blackbird, an open-source JavaScript logging and profiling utility written by G. Scott Olson, a former colleague from my days at Orbitz Worldwide.

A previous iteration of Blackbird provided no-nonsense, cross-browser logging on a variety of projects within Orbitz. Since that iteration, known as jsLogger, Scott has re-written the code from the ground up; provided tons of useful new features, including custom namespacing and a spiffy new graphical interface; and released it under an MIT license.

Why, you might ask, in the age of Firebug, would anybody need a JavaScript logging utility? Simple:

• Blackbird works in a wide variety of modern browsers. Write one style of log statement for every browser.
• Blackbird can be deployed to production. By stubbing out its public API with empty functions, you can leave your log statements in production code. (I'm not endorsing this approach to code maintenance, just pointing out that Blackbird makes it easy.)
• Blackbird does one thing and does it well. It's not a debugger, it's just a logger and profiler.
• Blackbird doesn't interfere with Firebug's console.log utility, but it does improve on its interface. You can hide or show the Blackbird modal with a single, customizable keystroke. You can also choose from four levels of logging (debug, info, warning and error) and atomically toggle their visibility within the console.

The Blackbird project now lives at Google Code, where you can download it and learn about how to contribute.

JSONValue root = JSONParser.parse(json);
JSONObject obj = root.isObject();
if (obj != null) {
    JSONValue map = obj.get("map");
    if (map != null) {
        JSONArray arr = map.isArray();
        if (arr != null) {
            if (arr.size() > 1) {
                JSONValue strval = arr.get(1);
                if (strval != null) {
                    JSONString str = strval.isString();
                    if (str != null) {
                        String s = str.stringValue();
                        // do something with the string
                    }
                }
            }
        }
    }
}

Yikes! Just to get the string in the second array item in the "map" key of the top level object. Truth is, most of the JSON I'm getting back is fairly predictable. And if it's not in that predictable form, it's an error that the client code can't recover from. I'd like to be able to write something like String result = obj.get("map").get(1).stringValue() without having to worry about NullPointerException's cropping up all over the place.

One option is to do what other developers have done, which is to use JNSI to roll out own JSON handling code. But that defeats the purpose of a framework like GWT. I'd rather leverage what's already there than come up with my own code which I'll then have to support.

So I've written up a little helper class called JSONWrapper that lets you do the above style code. It's pretty simple. As it's name suggests, it wraps a JSONValue object and lets you perform selections on it that return other JSONWrapper objects. Thus you can string together the method calls with method chaining (ala JQuery).

public class JSONWrapper {
    private JSONValue value;
 
    public JSONWrapper(JSONValue value) {
        this.value = value;
    }
 
    public JSONValue getValue() {
        return value;
    }
 
    public final static JSONWrapper NULL = new JSONWrapper(null);
 
    public boolean isValid() {
        return (value != null);
    }
    [...]
}

If at any point a request results in an invalid value, such as requesting an array index from a non-array, we return a JSONWrapper with null as its value. We reuse the NULL constant to save on some memory.

    public JSONWrapper get(int index) {
        if (index < 0) {
            return NULL;
        }
        if (value == null) {
            return NULL;
        }
 
        JSONArray arr = value.isArray();
        if (arr == null) {
            return NULL;
        }
        if (index >= arr.size()) {
            return NULL;
        }
        JSONValue retval = arr.get(index);
        if (retval == null) {
            return NULL;
        }
 
        return new JSONWrapper(retval);
    }

We want to distinguish between JSONNull and our null values, since sometimes the backend will really want to pass a JSON null.

I'll put this up on google code in a day or two. It's just one class (though one I find really useful). Perhaps this shouldn't be a module but rather find a home in another library.

Some other things I've been working on: StringReader for GWT and a simple model Observer/Observable library.

The Ajax Experience last week in Boston yielded lots of exciting developments on the Ajax history management front:

• My talk itself drew a crowd of 110 people or so despite its 8.10 a.m. start time. I received good questions from the audience and didn't notice too many people heading for the doors when they realized how deep into the nitty-gritty technical details I was getting. Instead of using Keynote or Powerpoint for my slides, I built a basic DHTML application. That way, one artifact could serve as both my content and a demo of Really Simply History, the Ajax history and back-button library I maintain. You can view the application - and the slides - at Pathfinder Labs.

• I did not meet my goal of releasing an alpha of Really Simple History 0.8 in conjunction with the conference. But I did accomplish a ton of work on the library during the build-up to my talk. I'm now hard at work finalizing the alpha and preparing updates to the project's Google Code-hosted homepage.

• The most exciting Ajax history development was the face time I enjoyed with Nathan Hammond, creator of JavaScript State Manager (JSSM), and Brad Neuberg, original creator of Really Simple History. After my talk we enjoyed an impromptu Ajax back-button summit and hammered out a shared agenda for the future of both my library and the topic in general. I'm pleased to announce that Nathan will be coming on as an RSH co-maintainer with the goal of merging RSH 0.8 and JSSM into a single, stable 1.0 library. I'm also excited that Brad, Nathan and I - plus other authors of Ajax history libraries who wish to participate - will be issuing a position paper on the current history implementation in the HTML 5 spec. Ajax history experts, please contact me via Pathfinder if you want to weigh in.

• As for the conference itself, it was my first time attending The Ajax Experience and I really enjoyed it. The topics were many, varied and well-presented. My favorites included Douglas Crockford's discussion of JavaScript's good parts, which could have been a simple book promo but turned out to be far more; the panel discussion between the leaders of YUI, Dojo, jQuery and Prototype moderated by the inimitable PPK; and my colleage Dietrich's un-sexy but vital look at how to resurface J2EE apps for Ajax using the Google Web Toolkit.

  I have to say, the crowd here felt like my tribe. The guys running around with the word "JavaScript" shaved into their hair put a smile on my face. Ajax developers are often third-class citizens at other conferences. They're either jammed together with designers and user experience folks, or thrown into the midst of Java and Ruby developers. That wasn't the case here, and I dug it highly.

  My least favorite aspect of the conference had nothing to do with the crowd or the content; it was the depressing lack of vegan food. One meal was 90% vegan, but most were 0%. Given the conference center's distance from civilization, it would have been nice if attendees' diverse dietary needs had been taken into consideration. On the plus side, I think I lost five pounds.

Many thanks to the folks from Tech Target for the awesome speaker support. My name, so amusingly misspelled on the monitor outside the ballroom where I spoke, had been corrected by the time I took the podium.

And special thanks to Ben, Dion and everyone at Ajaxian for throwing such a jam-packed event, letting me speak at it, and doing so much for the Ajax community over the years.

TankEngine

Thanks to Gregg and Jason at RailsEnvy for mentioning TankEngine on their podcast. The git repository now has 54 watchers and 3 forks. Thanks, everybody who is watching. I'm hoping for some updates soon.

Plugin testing

This is always what I'm afraid of, I write a big post on something, then a commenter points out a plugin that already does it reasonably well. In this case, the commenter mentioned the plugin_test_helper library, which allows you to pretty easily include a Rails environment inside your plugin for testing. The only problem I had with it is that if you have an actual application has this plugin installed, it seems to do odd things to the environment load -- I wound up limiting the init.rb of the plugin to only do something if the RAILS_ENV was specifically set to test plugins.

REST

After being a little cranky about REST a few weeks ago, I wound up doing some much stricter REST development on part of a new project. The one addition I'd like to make to the previous post is that REST is a very useful abstraction for determining when you need to split off functionality into another controller.

In particular, when you start adding methods to an existing controller with names like "add_subfeature" or "list_subfeature" your code is probably trying to tell you to split off to another RESTful controller, where you can call those things "create" and "index".

I should also mention, with respect to the topic of the last post, that it is possible to include Ajax features within the standard REST methods by triggering different respond_to blocks. That works to a point, but can eventually lead to the kind of bloated controller methods that REST was supposed to avoid.

Project Post-Mortem

The project that included integrated design drafts, named-scope based reporting, and aggressive markup in the helpers had it's post-mortem this week. It was interesting to see how these sort-of prototype structures worked in the context of the larger team project.

On the plus side, everybody seemed to like the integrated design materials, even with the sort of rickety implementation described in the blog post. The designers liked being able to easily integrate wireframes with actual site material, the programmers liked seeing the wireframes as they were working on the real site.

I think the named-scope stuff was basically liked, but the common Ajax controller that I created to manage it across various resources was, I think, generally understood to be "weird", "non-standard", and "probably not the best way to structure the problem".

The HTML markup in the helper files was not liked very much by the rest of the team. Everybody felt it was kind of hard to find where code was, and also that it was harder to modify than traditional ERb. I still think the mechanism has some use as a replacement for content_tag, but it probably needs to be better integrated with the existing partials system for better usage. So I guess we're still looking for the best way to untangle complicated markup.

First thing that came to my mind when I initially heard about the iPhone was the multi-touch possibilities that would start changing the way we create Flash/Flex interfaces (hopefully through SDK extension supporting multi-touch on Adobe's side triggered by iPhone release).

It looked very promising and natural to me in the beginning that this will be the route. Flash is a great part of the Internet experience and iPhone is a great mobile device for, among other things, Internet access.

Long time passed, and still all I can find on this topic is gossip.

Ranging from initial optimism:

iPhone Adobe Flash Support Coming
Mossberg: Apple working on Adobe Flash support for iPhone
Flash on iPhone is just around the corner
Adobe says Flash is coming to the iPhone

...to some doubts about the timeline:
Adobe Flash Coming To Apple's iPhone -- Maybe, Someday
Flash iPhone project stumbles: SDK insufficient

...to some doubts about the outcome:
Adobe bites its tongue after iPhone Flash jab
Steve Jobs: Flash Not Good Enough For iPhone. Is Microsoft's Silverlight?

...to advanced angles on the topic:
Flash on iPhone Political Calculus

After all this (and much more) gossip, I came up with the following conclusion: It has never been a better time to learn Objective-C.

If the Flash support ever pans out, I will be waiting and ready. In the meantime, it seams like a waiste not to apply all the interface development techniques learned through Flash/Flex development on iPhone and learn something new.

I dare to say that Flash/Flex developers should have an edge on at least the interface logic, and learning a new language should be on everybody's agenda from time to time.

Server-on-demand providers like Amazon's EC2, Joyent,
and others have reduced the capital necessary to launch scalable,
server intensive businesses. Google has just launched a similar
on-demand service, and companies like RightScale and CohesiveFT are building mature businesses around managing EC2 configurations.

...

Facebook applications are just the most extreme example of business initiatives that can be scaled on demand from $70/month on one EC2 server to $10,000/month on many dozens of servers running web, application and database server clusters and farms. Compare that with the old school of investing in a large data center with a significant fraction of the hardware and bandwidth that you might need if your business is a success. What used to cost $100k in capital can now be done with just a few hundreds of dollars.

...

And it's all possible as long as you are using a unix variant - Linux for the most part - to power your apps. So there is a whole class of companies out there using Linux that can out compete their Windows-using rivals - again, the capital they need to launch is much smaller because of cloud computing. That means Linux will win among the class of young entrepreneurial businesses that are so vital to the US economy.

It seems that Microsoft has spotted this gaping vulnerability and is seeking to close it. From the Amazon announcement on support for Windows on EC2:

Starting later this Fall, Amazon Elastic Compute Cloud (Amazon EC2) will offer you the ability to run Microsoft Windows Server or Microsoft SQL Server.

...

Customers will only pay for as much or little as they actually use; of course the actual price will be higher than Linux-based instances, due to the cost of Windows licenses. We’ll announce specific pricing when we make the service broadly available later this Fall.

Combine this with the announcement earlier this month that you could officially run Oracle on EC2 (though you still have to license it rather than pay as you go), and it's clear that commercial software vendors are feeling the preasure of SaaCS (Software as a Commodity Service).

Some of the highlights from Ted's talk:

• If you like CruiseControl, but it's too fiddly for you, you'll love Hudson, a much more user friendly continuous integration engine.
• The Selenium IDE is great for getting started or smoke testing, but use the API's (in Java, C#, Ruby, etc.) to get real, supportable unit tests done.
• YUI Test is intrusive, but it overcomes some of the shortcomings for testing asynchronous events that are present in JsUnit and Selenium. See Ted's post on YUI Test.

OK, not sexy, but if you want to develop quality software, you have to keep an eye on the non-sexy bits.

I'm posting today from Boston, where my colleague Dietrich Kappe and I are proud to be presenting at The Ajax Experience 2008.

At 5.10 p.m. tomorrow (Tuesday 30 September), Dietrich will present "Saving Your Investment: Transforming J2EE Applications into Web 2.0 Using GWT." This 90-minute session will introduce noobs to the Google Web Toolkit; school experienced GWT developers in the security implications of leaky client-side business logic; and delight business folks and bean-counters alike with the money-savings possibilities of retrofitting a legacy webapp instead of building a new one from scratch.

At 8.10 a.m. the following day (Wednesday 1 October), I will present "Making Friends with the Browser: Ajax, Back Buttons and Bookmarks." In it, I'll look at the state of Ajax history management, from new libraries such as the JavaScript State Manager and dsHistory to my own project, Really Simple History. I'll discuss the problems and tradeoffs inherent in any browser history manager. I'll also examine the impact of new browsers such as Google Chrome and Microsoft Internet Explorer 8 on this small, rapidly evolving corner of the Ajax world.

We look forward to seeing some of you there and reporting back about the rest of the conference.

Last Saturday at Windy City Rails, I had the pleasure of announcing TankEngine, a new Rails plugin for targeting iPhone and Mobile Safari. ("git" it here)

Now, I know, I've done this already, so why a brand-new version of the plugin with a new name?

Good question. The original plugin was basically a wrapper around the iUI JavaScript and CSS classes. After working with iUI for a while, it turned out that I had a few differences of opinion with iUI (which I still think is a very nice piece of work).

• iUI is effectively optimized towards a drill-down list, and especially one where all the list data is sent down as a single page. This is somewhat restrictive for a Rails application.
• iUi has a custom history mechanism for managing going backward through the list, but the mechanism causes conflicts with any other DOM-id based JavaScript on the page.
• The CSS structure for iUI makes very strong assumptions about the structure of the underlying HTML

Again, not a criticism of iUI, just an acknowledgement that it wasn't quite meeting my needs.

Which brings us to TankEngine, which offers the following.

• A jQuery-based JavaScript layer, for managing iPhone-esque look and feel.
• A more flexible mechanism for deciding which requests get the iPhone content.
• An updated CSS page, based on the iUI original, but a bit more flexible, and also using WebKit specific CSS where appropriate.
• A lot of helpers for lists and toggles and the like.

There's still work to be done on the API, and adding some other iPhone style elements, but if you've got some needs in this area, check it out.

In a project that I am currently a part of, we inherited Ruby on Rails from our client's system and project front-end was designated to be developed in Flex. RubyAMF came naturally.

I have been working with two other AMF frameworks prior to this: AMFPHP and WebOrb. My experience with both was that they are fairly hard to set up and once you go through that minefield, everything works excellent. No need to say that I am a great advocate of AMF in general. RubyAMF brings the same good old AMF but with a stunning ease and speed of development!

My colleague working on the Ruby side, Justin Ficke, introduced me to code and architecture of Ruby on Rails and I was impressed to see with what ease, precision and speed can one develop it.

Justin and I put a little test together of this architecture and here is a screen cast of it.

All the lovely custom typed objects and speed of data transfer are there. Beauty of it, appart from obvious benefits from AMF, is that the development process couldn't have been better and faster.

Jason Fried from 37Signals spoke yesterday at the ITA "Speaking of Success" event, about the history of 37Signals, their philosophy and culture, and the critical business decisions they've made to get them where they are today.

The software biz is fundamentally broken. Too many products fail because of the obsession of adding more and more, and trying to do too much.

Jason went on to say that the approach of adding more and more only works for companies that have lots of money and lots of time, but that for the average company the main goal should be to build something that is "good enough," get it out to the users, and improve the design based on their feedback. The challenge of which features to include, and which to say "No" to, is covered well in the "The Innovator's Dilemma," which he said "everyone in this room should have read." The book resonates the core philosophy of 37Signals, which is evident from their blogs, their book "Getting Real," and the design of the Rails framework. As an example of the "Good Enough" philosophy, Jason used his laptop and its basic webcam to stream the Q&A session out over justin.tv and send out a text to the 37signals Twitter group. "The quality probably isn't that great, but its good enough," and with that quick setup he had now broadened the audience by 1,000 users or so. (I searched for the video archive at justin.tv, but didn't find it yet.)

"Our products do less than the competition"

While this quote isn't new, I still find that its worth digesting, particularly as it relates to product planning and product design. I'm a big fan of Agile and iterative development, and the idea that we don't have to have the full product requirements solidified before we can get started. I like to take a product vision to market quickly, improve on the design, and add features as their necessity becomes more clear.

I found that the things that Jason mentioned that resonated with me the most were closely in line with what I liked about DHH's Q&A session at last week's WindyCityRails conference in Chicago. I think a big part of 37Signals success is due to the fact that its two primary partners are totally on the same page.

Working at a consulting company like Pathfinder presents two major challenges in this area. First, the customer most likely doesn't know anything about Agile, nor do they really care about it. They want to see results and the details of how those results come about may not be something they care to explore. Secondly, our customer cares deeply about the design of the product, and the features that absolutely HAVE to be in for the release. The idea of going to market with "less" is a difficult concept to swallow. I've found that the more the design process explicitly involves the actual end user, the easier it is to investigate the importance of a given feature, ask them about it, prototype it, and figure out if its going to make things better for them. Conversely, if the end-user isn't closely involved in the design process, feature priority is more of a guess, and out of fear and lack of certainty features are included because "yeah, we might need that too". So when the question is raised, "Which is a higher priority, feature A, or feature B?", the answer is often an unequivocal "BOTH!"

On this point Jason had two elegant explanations that I hope to draw from. First, doing "less" really means covering the "essentials" of what is needed, and doing those "fewer" things better. He mentioned their products as being like a tool, with a specific, focused purpose.

"A hammer is a tool, its very focused, and has a clean, simple interface."

It strikes me as a perfect example of clarity and focus, because no one is screaming for a hammer that measures distance, cuts wood, or tightens nuts & bolts. Its intended use is clear, it doesn't need to do more than that.

"We like to think of ourselves as curator's of the product. A curator at a museum chooses which pieces of Art should be included in the collection. They say "No" to many things. A building full of lots of Art that isn't carefully selected isn't a museum, its a warehouse"

I've certainly seen applications that were a "warehouse" of features in need of greater focus and "tasteful selection" for what should be included. My mission now is to find a better way to deliver the message that "less is more," and that in most cases, its better to get the application out to the users quickly, and leave room to iterate and improve on the design, than it is to try to build and release the perfect product all in one shot.

How do you deal with this issue in your day to day work? What effective techniques have you found for bringing clarity to the design of a product?

Photo Credit:
Darren Hester
under a Creative Commons Attribution License

DHH on Rails Performance and Winning in the Website Business

DHH did a pretty neat 30 minute Q&A session towards the beginning of the day. I'd never actually met (or seen) the guy who initially spawned the framework from which I make my day-to-day livelihood. He's very personable, awfully loud, thoroughly opinionated, and quite brilliant, just like Rails. It is my career goal to be cool enough that I can show up at a conference dedicated to software I created, with no speech in hand and no real plan, but still wing a Q&A session that ends up being one of the conference highlights, because DHH did just that.

One of the questions he answered was about the speed of the Rails framework, which got him off on a really interesting diatribe on how Rails is A) fairly speedy at doing its thing and B) not usually the problem when there are throughput difficulties on a server. Rails only takes up about 10-20% of the time a request is being processed by the server. Seriously, the biggest improvement DHH said 37signals implemented in BaseCamp was telling the server to check the browser's etags. Very handy headers that have been part of the HTTP spec for generations (like HTTP_IF_MODIFIED_SINCE) can provide huge speed improvements if implemented correctly, and that's something usually done by Apache and not Rails at all. But that said in Edge Rails we now have a request.fresh? method that lets us quickly return head :not_modified. We don't even have to hit the database. How cool!

Remember to gzip files you're sending around, and minify JS, and all that other good stuff. Seriously. The tool yslow (which I knew about before the talk because I'm a great web developer) is completely invaluable for boosting the performance of your apps. Use it. Love it.

After DHH finished his talk, there was a small collection of people out in the hallway sponging around him, and being a mindless sheep I stuck around too and learned that DHH has a secret hatred of migrations. They're really great to build iteratively and allow seamless database support, but he was definitely of the opinion that they should be thrown away with great regularity and replaced with the overall schema. Certainly they were never intended for use in production environments (which should be obvious from the existence of the rake db:schema:load task).

And finally, I spoke with him myself, which was kind of awkward since I had absolutely nothing to say. I mean, after you thank him for creating the thing that makes you money, what conversational gambits are left? Discussions of the weather? I ended kind of lamely and ended up kicking myself through the rest of the conference for it. Next time, I'm going to have some emergency questions prepared in case I get a one-on-one with him or another luminary of he Rails world.

What I took away most from his talk was something just of general inspiration and not Rails-related at all, though. In answering someone's question about how to succeed in creating web applications, he stated two things: A) be marginally better than your competition, and B) have greater longevity. Seriously, if you're only 2% better, you'll win in the long run because most companies die and your competitor's will before yours, if you play your cards right. Ultimately, he stated that having a market of millions is nearly impossible; be satisfied with thousands, or even a few dozen thousands.

Think about this: a mere 2,000 customers paying $40 a month leaves your company with a revenue stream approaching a million dollars. That is certainly nothing to sneeze at, and only goes to show that web business models do not require 100,000 users before they become profitable. A lot of people fall into the trap of believing that they'll be the next Google or YouTube and their company will have a market capitalization of a billion dollars overnight. It won't happen. It's more likely you'll win the lottery. Aim modestly, and your chances of success increase exponentially.

Jake Scruggs and Code Metrics that Matter

Of course, our own John McCaffery delivered an immensely popular talk about JavaScript testing, highlighting JavaScript-unfriendly browsers like everyone's favorite Internet Explorer. But since I had heard it already, I went to Jake Scruggs' presentation, 'Using Metrics to Take a Hard Look at Your Code.'

Everyone knows the big code metric: code coverage. It's kind of the old standby of the code numbers world. But Jake Scruggs was pretty dismissive towards it, which is perfectly correct of him. Rcov in particular is not a complicated tool; it checks code coverage only by seeing that particular lines are called. It does not check complicated conditional logic, nor does it check for weird failing cases, and it doesn't tell you when your methods are crazy and overwrought. It is a good metric because you want tests, but it is not a good metric because it doesn't really tell you how good your code actually is.

For that, he recommended a tool I had never heard of: flog. Flog determines the complexity of your methods and lets you know when your code should be refactored into more sensible, bite-sized chunks. This isn't to say that you can't have a hundred-line-long method; but testing is easier and more sensible when code is atomic, and flog really encourages refactoring with an eyes towards atomization.

Also he talked about Saikuro, which is a cyclomatic complexity analyzer. In human speak that means it counts the number of branches in your code for you, which is probably as many tests as that method should have. If you have 5 paths through a method, you want to test them all, am I right? Even if Rcov, the lying but wonderful tool it is, says you have 100% coverage, you almost certainly don't unless you have those 5 paths as 5 different tests.

Anyway I'm totally giving his talk short shrift. It was really fascinating and you can read more about the individual bits of it on his blog.

Locking Down Rails with Aaron Bedra

Aaron Bedra gave a really cool talk on Rails security. Really I don't think developers pay enough attention to this (and I am just as guilty as the rest of us). We take for granted the amazing tools Rails provides to protect against malicious users. SQL injection is rendered useless by sensible finders, cross-site request forgery is foiled by authenticity tokens, and the small little h tag nullifies most cross-site scripting attacks. These are so easy to use and require so little thought on our part that we don't test them, which is clearly the wrong thing to do.

So Aaron suggested a cool new tool that I intend to use from now on called tarantula. Tarantula by default crawls your app and puts bad form data into it to see if your application bombs out. That's fun but kind of yawn-inducing (you're testing your model validations already, right?). Where it gets really cool is that you can set it to perform XSS, CSRF, and SQL injection attacks on your site.

You might get lots and lots of failures.

In that case, it's best to install a plugin that helps audit your code. I recommend xss_sniper, which wraps all of your strings and texts in little h tags so you don't need to remember to whitelist them yourself. But Aaron also suggested SafeERB and xss_shield. Check 'em out and install one! It can't hurt to secure your app even more.

Noel Rappin's Test Last Development

Our very own Noel Rappin also gave a really cool talk on some common pitfalls in test driven development. I'll be brutally honest here. For all my strengths, I am not the best test driven developer in existence. It is hard work to remember to be test driven, especially when you tell yourself, "Oh, I'll just whip this up really quickly and get to the tests later." Good self-auditing techniques are completely required to keep on the testing straight and narrow... and it's very, very easy to stumble.

Noel talked a lot about those stumbles and what they show us about test driven development. I'll leave it for him to discuss the details since I hate stealing others' thunder, and anyway if I tried I certainly wouldn't cover the topic nearly as well as him. Suffice it to say that all of us have been guilty of stumbling into potholes on the road to completely test driven development, and that actually analyzing those roadbumps helps us figure out when some can actually be useful, and how to avoid them in the future.

So, all in all, Windy City Rails rocked! The energy level was high, the food was completely bearable, there were lots of people there, a fair amount of swag was given away (but in a grotesque oversight I did not win any), and here's my strange anecdote from the conference: I was standing in line for lunch and the guy behind me struck up a conversation with me. He said that he's a .Net developer and doesn't know the first thing about Rails. He just wants to learn more about our development processes and what we're doing.

How cool is that?

Monopsony - the market condition that exists when there is only one buyer.

We all have heard the term "monopoly" and even know a little bit of what it means - a market where there is only one seller. But the related term "monopsony," a market where there is only one buyer, is not as well known and it's dangers not as well understood.

Certainly both monopolies and monopsonies will reduce competition, innovation and consumer choice, but they further constitute a big risk for the sellers. For businesses on the seller side a monopsony can be the kiss of death. Just ask Walmart's suppliers how good it's been for them.

Not all monopsonies are as obvious or as overtly damaging to suppliers as that of Walmart, but Apple's iPhone and iTunes appstore looks like a benign monopsony. A monopsony in that although the iphone consumer is the ultimate buyer, Apple determines what is permitted in it's appstore, and benign in the fact that Apple hasn't flexed that restrictive muscle more than a few times.

But for the business launching an iPhone app this monopsony - benign or not - presents a real concern, a real business risk. What happens if Apple decides to compete in your space? The evidence on what happens right now is not encouraging. Take the recent example of the podcasting application that was excluded from the AppStore. The reason for it's exclusion?

Since Podcaster assists in the distribution of podcasts, it duplicates the functionality of the Podcast section of iTunes.

That's the desktop version of iTunes versus an application on the iPhone that you can use without a PC or Mac. Presumably, if people don't have to use iTunes to get their podcasts, then there's less reason to use iTunes and consequently less chance that they'll actually spend money with Apple.

Since you only find out whether your application will be approved in the last step, i.e. after all of the hard development work has been done, that's a lot of risk to take. How to minimize it? One approach to minimizing risk might go as follows:

• Distribute an application with an initial pretty minimal set of functionality. Quick to produce and get the yes/no appstore answer.
• Design your application so that it supports and embedded language runtime, such as Ruby or JavaScript, and a capability to push additional modules of functionality to the application independent of the appstore.
• Extend your application using the above distribution mechanism. The only time you'll have to push a new version of the app is when the underlying iPhone platform changes and you'd like your embedded layer to take advantage of new features.

Of course Apple is known to have a "kill switch" to turn off apps that have already been downloaded to a phone, so even the above approach may not insulate you from risk. So, if you are developing for the iPhone, have a care on whether your application will run into competition from Apple. You may find your application unceremoniously rejected or killed.

Update: Looks like Apple has  banned another application, MailWrangler, that competes with it's own email application.

The basic idea here is that while the browser is the View and the server side is the Model and Controller in MVC, you really should structure your browser side code as an MVC itself where only the Model interacts with the server.

Well worth a read.

CSS 2.1 is more like a Swiss Army knife than a fully stocked toolbox. We can accomplish a lot, but we have to get creative with the standard attachments. Floats, relative positioning, the box model - each tool must performs double or triple duty because they're the only ones we've got.

When we do discover a clever way to accomplish a common task using these limited tools, we're likely to employ that technique over and over. I'm not talking about CSS frameworks here; those help out more at the macro level. I'm talking about repeatable techniques that can be applied at the micro level. When done right, these simple techniques can feel like entirely new Swiss Army attachments rather than intelligent application of existing blades.

Whenever I start out on a new client project, I start off with the following plug-and-play components:

1. A reset stylesheet: Sometimes I plug Eric Meyer's latest reset in wholesale, while sometimes I pick and choose which parts make sense for my project. Regardless, it's absolutely essential to erase default styling and provide a common, cross-browser foundation on which to build.

2. Semantic, cross-browser float-clearing: I posted about this topic a year ago, generating plenty of debate. Whether you're using my Orbitz-inspired grocery-list-of-selectors approach or a generic clearfix class, you've got to tackle this problem if you employ float-based layout - until, that is, some future CSS spec implements a float-clear property.

3. Standard-issue pipe-delimited lists: If you're representing lists as paragraphs full of text punctuated by hard-coded pipe characters (|), you're probably not paying much attention to web standards. A set of CSS rules like the following makes it dead simple accomplish the same effect semantically with borders. True, Internet Explorer 6/7's lack of support for the first-child pseudo-class means you'll have to create an actual class called first-child and apply it to your initial list element. Still, once you adjust border colors and spacing to fit your site design, this solution works anywhere. Variations can even allow for pipe-delimited definition lists.

   /*
   	standard pipe-delimited list: add a class
   	of "first-child" to the first element
   	for IE either via script or in the markup
   */
   
   /*
   	- the 0 margin and padding are unnecessary if
   	  you're using a standard reset stylesheet
   	- you'll need to clear floats inside of ul.piped
   	  using whatever your preferred method is
   */
   ul.piped {
   	margin: 0;
   	padding: 0;
   }
   ul.piped li {
   	float: left;
   	margin-left: 8px;
   	padding-left: 8px;
   	border-left: 1px solid #000;
   	list-style: none;
   }
   ul.piped li:first-child,
   ul.piped li.first-child{
   	margin-left: 0;
   	padding-left: 0;
   	border-left: 0;
   }
   

4. Simple hide/show utility classes: Unless you're using an effects library to create visual transitions, it's easier to toggle classes on hide/show elements than to manipulate their style properties directly. The only problem is differentiating between block and inline elements when you're ready to show them again. That's where the block, inline, noneBlock and noneInline classes come in. Your JavaScript code just needs to know that elements with a class of block get toggled to noneBlock and vice-versa; same for elements with a class of inline and noneInline.

   /* classes to hide and show elements programmatically*/
   
   .inline {
   	display: inline;
   }
   .block {
   	display: block;
   }
   .noneInline,
   .noneBlock {
   	display: none;
   }
   

5. A style-as-link class for JavaScript actions: It's easier - not to mention more semantic - to trigger JavaScript code from click events on divs, spans or other non-anchor elements. That way, you don't have to deal with a dummy href value or cancel out the link's default action. Besides, the <a href=""></a> tag is for taking you to new pages, not performing an action within the existing page.

   Some JavaScript coders ignore these advantages because they want the built-in styling shortcut of the a tag: cursors and hover states. As the code below demonstrates, however, it's dead simple to achieve the same visual effects with some simple CSS. Modern browsers can apply the hover pseudo-class to most any element. Ditto custom cursors.

   a,
   .styleAsLink{
   	color: #08c;
   	text-decoration: none;
   }
   a:hover,
   .styleAsLink:hover{
   	color: #444;
   	text-decoration: underline;
   	cursor: pointer;
   }
   

   Once you've created a styleAsLink class, you can replace this type of code:

   <a href="#"
   onclick="alert('Isn't it annoying to have to return
   false every time?'); return false;">
   	this is an actual link
   </a>
   

   ... with this:

   <div class="styleAsLink"
   onclick="alert('In the real world the click event
   should be applied unobtrusively!');">
   	this is a pseudo-link
   </div>
   

   One caveat: This technique is useful for links that serve no other function than to trigger JavaScript code. Don't employ it in the case of a progressively enhanced link that triggers a script when JavaScript is available but takes you to a new page when it's not. A simple rule of thumb: If the link exists in your actual markup, it should remain a link. If it's inserted into the DOM wholesale by JavaScipt, it should be a pseudo-link.

Enough about my own personal Swiss Army attachments. How do you get all MacGyver with your CSS? Let us know in the comments.

A quick plug for the WindyCityRails conference being held tomorrow here in Chicagoland. I guess it's technically not a "plug" since the conference is all sold out, but it does promise to be a fun day. So think of this post as a promise against a longer post on Monday with a round up.

The headline session is a Q&A with David Heinemeier Hansson. David Chelimsky, lead developer of RSpec is also speaking. And we have three talks from Pathfinder as well.

John McCaffery will be doing a presentation on JavaScript practices including testing and debugging.

I'll be doing a talk on iPhone web development, and a talk on testing that I hope will also be fun.

Expect some round ups early next week. If you can't wait that long, I'll probably be updating my twitter feed all day with any interesting info.

• Comet server push
• Customization of look and feel
• Performance monitoring

Server push via polling has been available in ZK for a while, and Comet in the ZK "Enterprise Edition," but now it is available to everyone. And it is pretty easy to use: "The implementation of server push is transparent to developers. ZK chooses which implementation to use according to the edition of ZK automatically, but it is configurable."

Customization of look and feel has gotten much easier. ZK has followed the example of a number of other frameworks in styling its widgets with predictably named CSS styles. Changing the look and feel of an application is now as easy as changing the ZK widget style sheet. Styles can further be overridden on a widget instance-by-instance basis.

Performance monitoring is perhaps the most exciting new feature. Client-side tools such as YSlow can guide optimization efforts and give you point in time performance snapshots. But critical applications need to be monitored and tracked end to end over their lifespan. With ZK 3.5, you now have the plumbing to instrument your application to capture five data points for each request:

• T1, the time browser sends a request to server
• T2, the time server receives a request
• T3, the time server sends a request to browser
• T4, the time browser receives a request from server
• T5, the time the browser finishes processing a request

ZKStudio 0.8.2

There's also a new version of ZKStudio for Eclipse out. The major change is that it now supports auto update via http://studioupdate.zkoss.org/studio/update

A big issue that was overlooked is support for mouse wheel event on Mac OSX. A pretty basic functionality you would think. If your interface is heavily relying on mouse scrolling, your audience on Mac's will probably have a "so how does this work" blank stare.

Google didn't overlook this in their implementation of Maps, but most apps I've seen online did.

There is a very nice and simple solution to this issue coming from hasseg.org and I find it very important to put this little effort in to maintain same look and feel of application interface across platforms.

Solution is executed with help from JavaScript. Mouse wheel events get passed to Flash player and parsed to simulate regular functionality.

A lot of praise to hasseg.org for coming up with and publishing working source code of this solution.

You can find the full explenation on this blog post.

Consider this my somewhat belated follow up to Brian's post about iPhone usability.

First, one pure follow-up. If you are so inclined, you can join an online petition calling for Apple to allow iPhone users or developers to disable keyboard auto correct if they so desire.

Here are my usability notes. I should say, I'm not a complete mobile warrior or anything, so there are probably other users a lot more dependent on, say, mobile email than I am. Also, the iPhone is my first smartphone, so I don't have any residual BlackBerry or Window Mobile experiences to compare it to.

Phone Usability

For all that everybody focuses on the fancy stuff, an iPhone still needs to allow you to make and receive phone calls. I have to say, the basic phone interface is perhaps my favorite of the built in Apple applications. The basic set of in-call options (speaker, mute, etc...) are clearly and cleanly presented with large buttons, reducing the need to remember how to trigger different features. The visual voice mail interface is outstanding -- almost making it pleasant to deal with voice mail.

One More Thing...

The iPhone 2.x OS features an unusual password entry field, in that the most recent character typed is displayed plain while all the other characters are masked. The idea, presumably is to make it easier to catch password typos, and it's (I guess?) not all that likely that somebody would look over your shoulder to catch a password.

Still, the behavior feels weird. I thought it was a bug the first time I saw it. I opened this up on my twitter feed and got exactly two responses. One in favor, one against. Obviously the masses have spoken. What do you think?

There's an interesting User Experience issue here -- certain basic phone actions take more steps on the iPhone then they would have on my non-smart LG flip phone. The clearest example of this is dialing a known favorite contact. On the LG, up to 8 contacts are associated with numbers, and they can be dialed just by holding down the appropriate number -- one step. On the iPhone I have to open the phone app, open the favorites tab, and select my contact -- three steps (although you can set the phone to go directly to favorites from a double-tap on the home button).

The tradeoff here is user cognitive load versus steps. The downsides of the LG method are that a) it's limited to a small number of contacts, and b) it requires me to keep in my head who each number refers to. On the iPhone, I can have as many favorites as I want, and I can actually see who they are. Overall, that makes the iPhone feel more user-friendly even if making the call takes an extra second.

The iPhone interface is also more flexible, finding an arbitrary contact is much faster on the iPhone (because scrolling is faster), even though there are clear limitations to searching for contacts (recommended: using the Google Mobile App, which searches your local contacts..)

The point here is not that the iPhone is better designed than a regular non-smart phone, that would hardly be surprising. The point is that the iPhone uses it's best hardware asset -- the screen, to advantage in making using basic features easier to manage. (To a lesser extent, the same thing happens for, say, accessing the keypad during a call -- an extra step, but clearer options and more flexibility)

Oh, and while I'm here, I have to point out a little feature that I like. I have several contacts where two people have the same home number. If the two people have different last names, then a call from the number shows up as "Fred Flintstone or Barney Rubble". That's nice, but even better is if the two people have the same last names, and the caller ID shows "Fred or Wilma Flintstone". Minor point, but it shows that some thought went into the display.

iPod Usability Nit

I use the phone for iPod functionality pretty frequently, and I have a couple of annoying nits.

On a traditional iPod, the music display shows the time remaining in the song, and it's a button click to show the volume. This makes sense, because the time remaining is what is changing at, at least for me, is checked more frequently. The volume dis