Now Firefox 3 does contain Malware protection, but apparently this plugin is delivered via other system compromises to the filesystem, and apparently Firefox doesn't question already installed plugins.

BTW, the malware registers itself as GreaseMonkey. If you care to, you can follow the Slashdot food fight on this topic.

More as I find out more...

You can see the site here. Come often as it will be updated on a regular basis.

The goal of this site is to shed more light on what is it that we do here at Pathfinder with the Flash Platform.
We would be very grateful to hear feedback about the site from any perspective.

The Site was developed using Flex Builder 3.

We were focusing on several things:

• Presenting our work in a manner that is fast and easy to consume
• Fast loading times of site and content
• Maintaining the same experience on any screen resolution, major browsers and OS’s
• Testing SEO optimization for Flash Platform
• Uniformity and reusability of interaction effects
• Ease of dynamic content maintenance

Presenting our work in a manner that is fast and easy to consume

We decided to present our work mostly using screen casts of apps being used. We thought that this would be the quickest way for our visitor to get a good taste of our work.

Fast loading times of site and content

We used Amazon's Cloud Front CDN to store streaming video content.  Setting up cross domain permissions was a little tricky.  Images loaded from Cloud Front would have a slight delay loading right after initialization of the site, otherwise they acted great. We're still looking into this issue as we think that using Cloud Front is potentially a great approach for storing content like images and videos, at a substantially lower cost than Akamai or Limelight Networks.

All content was optimized for web using Adobe Photoshop and QuickTime Pro. The Site’s interface is entirely created out of vectors, for screen resolution scalability and fast loading times. Vector content is either programatic, either imported from Adobe Illustrator as mentioned in this post.

Maintaining the same experience on any screen resolution, major browsers and OS’s

Flash does take care a lot of this business out of the box.

Though this is a Flex application, we chose to use good ol’ Flash Stage resizing method:
stage.scaleMode = StageScaleMode.SHOW_ALL .

The catch with this one is that your flash movie size (width/height) in HTML has to be 100% or the line will not work.
It turned out that this was not a bad idea at all. It allowed us to focus on one layout of known proportions that will fit any screen size the same way.
Plan B would have been to use the standard Flex constraints system for display objects, but in this case the results were so different (naturally) that the site would have had tremendously different appearance based on screen resolution.

Testing SEO for Flash Platform

As mentioned in this post Google doesn’t index Flash dynamic content. We had to go back to standard SEO techniques for Flash Platform.

To name a couple:

• We embedded a lot of text content in the Flash file itself.
• We filled the HTML wrapper as any HTML page sans the body content.

Uniformity and re-usability of interaction effects

We wanted to have standard effects for particular interactions.
For interaction effects we created various effect classes that would have two parameters in constructor:

• Targeted UIComponent
• Function to be executed at the end of effect.

All the timers and listeners for the effect are stored in the effect class.
First parameter makes the effect useful work for pretty much anything.
Second parameter proved useful for execution based on the effect timing.

Ease of dynamic content maintenance

Since there is not a whole lot of content to be maintained, we decided to have all the content catalogued in two XML files, one for the Case Studies and one for the image gallery. This has proved yet again to be the fastest and easiest way to setup and maintain small scale content.

1. QueryTrace. QueryTrace is a super simple plugin that shows exactly where SQL loads happen in your application. After an action is called you can check the log to see a backtrace after every SQL query, revealing where in your code it was referenced. Use this to find slow or unnecessary queries in your application.
2. Andand. Andand is a super simple gem that allows you to simply and easily prevent NoMethodErrors: that is, it helps you catch nil objects before you send methods to them. Its use is ridiculously simple: object.andand.method. If object is nil, then method will return nil, rather than raising a NoMethodError. This functionality is actually being included in the next version of Edge Rails under Object#try, but there will always be a special place in my heart for Andand.
3. Wirble. Wirble adds some awesome features to irb, and, therefore, to script/console. I've completely forgotten how I've managed to work with irb before I got tab completion, history, and colorized results. This should come standard with irb, in my opinion.
4. Calendar Date Select. Somehow in almost every application I'm involved in, someone ends up wanting a quick and easy way to pick a date. It doesn't get a whole lot quicker and easier than Calendar Date Select. It's simple to use and by this point I honestly should just install it in all my projects when I start them.
5. Annotate Models. Annotate Models is a very simple, small plugin that adds in a new rake task: rake annotate_models. It puts the schema for your models at the top of those models, so you don't have to use SQL queries to remember the structure of your tables. It doesn't get a whole lot simpler or more useful than this.

The beauty of small, easily digestable plugins and gems like these is that they're reusable in every application you do. Before you know it you'll be installing these before you even start serious work on a project. Got any gems and plugins you want added to the list? Throw them out in the comments!

Here's an example of how I've used it:

#if TARGET_CPU_ARM
	// Device will hit external server over cell network
	NSString const *ROOT_URL = @"http://www.external-site.com";
#else
	// Simulator will hit local server over LAN
	NSString const *ROOT_URL = @"http://localhost:8667";
#endif

This kind of tweaking is particularly important when the device itself can not participate on the local network, but needs to access some kind of external environment (or proxy server). Conversely, targeting the simulator to use a local 'development' server is often faster when deploying and debugging issues in your application, particularly if you are developing the server component in tandem.

Another example involved certain audio playback features which work fine on the device, but run into hiccups running on the simulator. Since in this case the functionality is not critical to test, I ignore it in the simulator.

If you are deploying to the iPhone simulator instead of to a device, you can get away with not loading the identity matrix for the projection matrix so long as you do not want to draw over any bound textures which are drawn.  However, on an iPhone device, you will notice some serious artifacting if you attempt this.  The artifacts will be related to the last drawn textures, even if they were drawn from a different application (except if the phone was turned off in the interim, in which case you will get a black strobe effect).

This implies that the simulator loads the identity matrix automatically for GL_PROJECTION when loading your application, where as the iPhone itself will maintain the matrix's state between applications.

Sound like a requirement you've heard before? How did you handle it?

In an earlier post, I stated that all security models are idiosyncratic, and that the way you go about designing for security must reflect the nuances and -isms of your organization. You might mistake the form used to express the model (HR records, existing databases, or some XML schema) as your security model, but you risk an uphill battle getting your organization (and I mean the people here, not boxes and circles on an org chart) to accept the result.

All of this has less to do with how we design software and everything to do with the way people organize into groups..

Groups and hierarchies are never fixed-- fluctuations occur, even if the rate of change varies from organization to organization. We see this all the time in our everyday interactions-- associations can be temporal in nature, two groups may need to work together on occasion (but only, say, within a certain context). Ownership can cut across hierarchies, and influence can shift from one group to another based on other environmental factors.

A well designed security model needs to accommodate for these kinds of factors (even if it means fluidity in some areas, and stringency in others). Handling exceptions to the original security model are key, and the sooner people discuss it while building a piece of software, the better.

The bad news is that your IT department has chosen to see your company through a fixed lens, and will attempt to enforce the same level of stringency across the organization as a whole. But can you blame them? Two department heads suddenly decide to pool their resources for a period of time to make a deadline, requiring a temporary loosening of security restrictions, and suddenly the onus is on IT to work late hours dealing with the fallout. Something which might have started as a simple conversation between two managers inadvertently puts an otherwise stable security model at risk.

So why do we expect rigid specifications when solving the problem of security in the first place? After all, these specifications often reflect only a snapshot of the structure of an organization, and rarely its propensity for change.

Colleagues of mine cite external factors as the driving force behind the need for stringent security models in the enterprise (identity theft, liability, or a third party requirement). I don't mean to discount the importance of these types of requirements, but the big risk here is mistaking contractual specifications (e.g. "PCI compliance" or "HIPAA compliance") for a security model. The two are not the same thing.

All of this leads me to the conclusion that a contractual specification is not a substitute for a security model.

The former specifies an agreement between organizations in how to handle certain business transactions, while the latter dictates user roles and access rights and even more importantly, the process by which authorization can change based on fluctuations within the organization.

Before you choose a security model for your application(s), you have to understand how the organization can change. It may be useful to look at an org chart to build a vocabulary, but in most cases you are just as well served by tossing it aside.

Ajax pros, especially in the Rails world, often know the Prototype and Scriptaculous JavaScript libraries inside and out. When faced with the prospect of writing on top of the competing jQuery framework, they may quickly stumble upon seemingly missing features.

The culprit? jQuery's less-is-more approach, in which advanced or specialized features come via plugins instead of the core library. The greater reliance on single-purpose plugins gives jQuery a lean footprint and a vibrant ecosystem, but they come at a cost. You often must rope in several plugins to accomplish things Prototype and Scriptaculous can do out of the box.

If you want to encourage your team to step out of the Prototaculous mindset, it helps to have a readymade list of plugins that approximate those libraries' core features. At this point jQuery and Prototype approach feature parity, but once Scriptaculous is in the mix, jQuery relies on multiple plugins to keep up with the Joneses. Here's a quick stab at how to trick out jQuery:

• jQuery UI: jQuery's user-interface library. Some components offer effects functionality similar to Scriptaculous's, while others offer prefab UI components like the ones that are starting to roll out from Prototype UI. If you're looking for tried-and-true effects such as drag-and-drop, this is where you'll find them.
• jQuery FxQueues 2.0: The latest version of Luciano German Panaro's effects-queue plugin. It rewires jQuery's native global effects queue with fine-grained effects queues like the ones that ship with Scriptaculous.
• jEditable: In-place editing for the jQuery crowd. When coupled with other plugins, it offers in-place versions of utilities ranging from time pickers to character counters.
• jQuery Autocomplete: Dylan Verheul's much-revised solution to the original killer app of the Ajax era.
• jQuery Easing 1.3: Advanced animation tweening algorithms for jQuery visual effects.

It's worth noting one additional feature that Scriptaculous offers: A built-in unit-testing library that can be utilized for your outside JavaScript code. Of course, several standalone JS unit-testing solutions exist out in the wild, including the well-known jsUnit. Michael Grosser also offers jqUnit, a jsUnit-compatible testrunner for jQuery code.

What about you, readers? What jQuery plugins give you the most seamless transition from Prototype and Scriptaculous?

Since it's Thanksgiving and all, I asked our Rails developers to briefly mention something in Rails that they are thankful for. You'll notice some common threads -- nobody consulted with anybody else as far as I know.

Anthony Caliendo

I'm thankful for the "convention over configuration" mindset, as it saves me so much time and removes all the plumbing and wiring I needed to do when developing java apps just to get it running.

Jason Sendelbach

I am thankful that Ruby on Rails has conventions and code that reads like prose. Because of this, I can join an existing project and be an effective resource immediately. If I am fixing a bug, I simply look at the URL to figure out where to start. If the code is good (most of the code in Models and Helpers and not in the Controller), there are few bugs (did I mention the code was generated with TDD) and I can quickly start coding without much overview from any of the other developers. The entire project and code is self explaining. There is almost zero ramp up time. Thanks Rails (and Ruby).

Josh Symonds

Definately ActiveRecord. Particularly associations and association methods, and named scopes (because they feel like association methods but on one model).

Sharad Jain

I am sure ActiveRecord is the crownjewel. Outside of that, support for testing (unit, funcational) and supporting classes inside of rails are great.
Standardization of how libraries are installed (gems, plugins) etc. and convention of configuration in general is also something that I am thankful for.

Karthik Muthupalaniappan

I think the best thing for me about Rails is it lets me worry only about how I should/can code a functional requirement of an application by taking care of most of the other configurational/operational aspects of the application

John McCaffrey

Thorough implementation of Regular expressions throughout ruby and rails.

Noel Rappin

I get to go last, so I won't repeat anybody else...

I honestly love the ActiveSupport library, with all its 2.days.ago and 10.kilobytes and even array.second. I'm thankful for the attitude encapsulated by all these methods -- "if I needed to this, a lot of other people probably will, and I want to make sure they don't have to write it again". It's DRY at the community level, and it's part of what makes working in Rails so satisfying.

Have a great holiday weekend, everybody. Thanks to all of you that read and comment.

Developing in Xcode, I keep my project default "SDKROOT" and Target set to the default for the iPhone device and 'Release', respectively.

That said, I have been trying out TextMate as an alternative to Xcode, thanks to all of the great things TextMate provides (I won't go into all that here, since there are already many great resources on the web). For those iPhone developers who are new to the Mac platform, or to TextMate for that matter, here's a quick tip (and be sure to check install Xcode bundle first).

First, as always, an obligatory shout-out to Google Toolbox for Mac. I am testing my code with GTM, and set the following environment variables so that Xcode plugin for TextMate could run a build / tests accordingly.

  TM_BUILDSTYLE = "Debug"
  TM_TARGET = "Test SDKROOT=Test SDKROOT=iphonesimulator2.1"

This presumes you followed the GTM directions by creating a 'Test' target to run your tests, and also that you are targeting the 2.1 version of the iPhone simulator's firmware. Replace that last argument with 'iphonesimulator2.2' if you are targeting the recently released 2.2 firmware.

With these two settings, everything works great. I can write a bit of code, and run the build. Xcode definitely does a lot, and has its place in development, but I feel that the ease of use in TextMate outweighs the code completion of editing files in Xcode in cases where the code that I am working with is familiar to me.

Wherever I am working with new API's or need to constantly refer to documentation, Xcode is still worth it, particularly after you map some essential keyboard shortcuts (but that's another post). For familiar API's however, you can't beat the productivity gains of just coding in TextMate.

I've been tinkering with this tool as well and am going to do my own writeup, but thought I'd give you all the heads up. BTW, according to Vinay, the compiled GWT JavaScript for GwtQuery clocks in at 712 bytes!! So much for GWT bloat.

I'm also returning to Prototype for my JavaScript needs after almost 15 months of daily jQuery use. The framework has matured nicely while I've been away. One surprise popped up today, however: Prototype 1.6 lacks the ability to simulate native browser events. jQuery offers this in the form of jQuery.trigger, which can simulate both native and custom events. But Prototype's Element#fire supports only namespaced custom events. (Read this mailing-list thread for more analysis.)

I did a couple hours of digging around today - including a trip to Scripteka - and haven't really found a canned, cross-browser solution to this issue. I'm looking for something that offers jQuery's native event firing in a tidy little Prototype extension. Anyone know of such a tool?

• Amazon has gone live with their new CDN (Content Delivery Network), CloudFront. Think Akamai for the rest of us. Pay as you go, hooks into S3. If you want to get a jump start on this, get yourself the latest version (0.4.5) of S3Fox, the S3 addon for FireFox. Getting started is easy: sign up for CloudFront (or sign up for Amazon Web Services if you haven't already, then sign up for CloudFront), create a bucket, put content in it, make it publicly readable, create a 'distribution', enable it and map a CNAME to the cloudfront.net hostname that corresponds to the distribution. We'll be doing some testing of the Amazon CDN over the next few weeks and do a review.
• Adobe AIR 1.5 has been released. Among the improvements: encrypted local database, Flash Player 10 support (no H.264 for Flash 10, though :-(), and an update to the WebKit bundled with Air. InfoQ has a nice summary of the Adobe MAX Air 1.5 buzz.

If you've got any news that you'd like to announce, ping us at ajax@pathf.com.

Sorry, Mr. Colbert

It may help to read this one in a Stephen Colbert deadpan voice...

You want Fear, Uncertainty, and Doubt. I'm just the fuddy-duddy for the job...

This is the ThreatDown!

Threat #5: Terse Partial Declarations!

The number five threat to the Rails community this week is this commit, reducing the amount of typing it takes to invoke a partial. You can now type this:

<%= render @article %>

Instead of this:

<%= render :partial => "article", :locals => {:article => @article} %>

The old way, with it's triple repetition of "article" gave me a comforting Java feeling, making me want to go and write some strongly typed getters and setters.

The new way reduces the need for the locals -- this lack of caring for locals and local conditions can only lead to greater federal control over our templates and partials. Can the Department of Partial Partials be far behind?

As you know, I'm not a fan of unneeded, useless, content-free, windblown verbosity. In this case, though, are we not all locals? And if we don't stand up for the locals, who will stand up for us?

Threat #4: Automated Testing!

The number four threat to Rails this week is automated testing. As Jay Fields points out on his blog, testing tools across different languages suffer from a distressing lack of consistency in how they express expectations, leading to confusion on the part of test writers and maintainers.

I think there's one clear solution to this problem: abolish testing. Only by eliminating tests can we ensure perfect consistency. Only by removing expectations can we fulfill them. It's time to liberate our code from the constraints of our constraints and let it run free, without expectations or burdens, across the functionality landscape. Run free, code!

Threat #3: Rake and Generate!

Threat number three is this innocent command:

rake generate controller tasks

It sure looks like that should work, right? But no... Rake comes back to me with some guff that it doesn't "know how to build task 'generate'". Hey Rake -- how hard can it be to generate -- just look a couple of directories over to your immediate right. No, not the tmp directory, that's too far. There, the script directory.

Figure it out, Rake, just because have a temporary brain freeze doesn't mean I like to start my day with lip from a program named after a gardening implement.

Threat #2: Mythbusting!

DHH has been writing a series of blog posts busting Rails myths. This is a huge threat to the Rails community.

Look, we had a nice little gig going here -- all kinds of people were sure that Rails just wouldn't work for anything larger than a breadbox, while those of us working on Rails just sat back and giggled.

Sure, there was the occasional difficulty dealing with clients who said things like "we've heard Rails can't scale", or "is it true that Rails eats puppies?". But back then, when you found a client willing to take on Rails, that had real value.

But now, if these myths get busted, well then, anybody will be willing and able to use Rails on all sorts of projects. Who needs that kind of headache?

Threat #1: Syntactic Sugar!

Clearly, the biggest threat facing Rails this week are the methods Array#second through Array#tenth. Added to Rails core back in June, it took until this week for the shock to wear off the Rails community so that we could let our outrage be known. Show your outrage on the commit thread.

This is just another example of the programmer-coddling, readability-at-all-costs, complexity-for-the-sake-of-complexity mentality that makes Rails so much harder to use than Enterprise Java Beans.

Hey, DHH, if I wanted my programs to read like English, I'd write in AppleScript. Or Lisp. Or Wasabi, like Joel Spolsky. Or I'd just write them in English and wait for artificial intelligence to catch up.

My proposal: remove all these methods. And remove the bracket syntax. If you want a value from an array, you need to ask it politely and provide the memory address in hex. I think this will do:

array(ff98).pretty_please_with_sugar_on_top

Late breaking update: DHH has removed sixth, seventh, eighth, ninth, and tenth. He has, however, added forty_two.

(You think somebody is going to take this all seriously? Sigh.)

I learned Ruby on Rails last year, and was delighted when I found Capistarno. I wanted to share the things I love and hate about capistrano.

Nice things:

• The deployment script is the same for each environment with a configuration file for each environment. It's really easy to see what's different in each environment.
• The deployment can specify a SVN tag/branch. Our configurations usually fail if you don't specify a branch to avoid the old "oops i just deployed trunk to production...." type errors. (Let's just say that I almost made that mistake, and added that configuration the next day)
• Copies a system maintenance page out, which our apache configuration uses to halt traffic to the application servers during deployment
• We actually build our apache configuration file in our deployment script. We can then test out new redirects and other apache specific changes. We point apache to these conf files with symbolic links, and our last deployment step is to restart apache. We also configure our mongrel cluster with configuration parameters, so we can easily modify these parameters by simply changing the configuration and deploying. Of course on the projects that we have moved to passenger don't need this.
• We have a development deployment target, so we can deploy locally, and get as close to the production environment as possible. A coworker who develops on Windows (yuck) has had some issues matching production, as he can't run passenger (and apparently support for windows is not on the road map). Luckily he runs VMware, so he has a Linux VM that he uses as a local development environment that alleviates most of his windows "issues." Another nifty feature with that approach is that his rake runs like a hundred thousand times faster in linux compared to windows.
• Symlinks are great. If you need to rollback, you can manually switch some symlinks until you figure out what the hell happened.
• Keeps the last n deployments. We keep 5, and unless you do a number of screwed up deployments in a row, this usually suffices.
• At first I hated the fact that there really is no rollback support, but after doing a few tests in staging to make sure I trusted capistrano, I found that adding rollback functionality isn't possible, as you wouldn't really be able to tell what went wrong, and programatically determine how to fix it. What I like about capistrano, is that it leaves the maintenance page up, and gives you a log of the problem. From there you can figure out what needs to be done to fix the deployment, or you can quickly change some symlinks to revert the deployment. This is the only reason the deployment to production needs to be done by a developer and not some non-technical resource.
• The deployment directories are standardized, so it's not difficult to go find an installation on a new project.
• It is pretty quick to add a new application server or get a deployment to a new server in the event of hardware failure. This helps with growth.
• As the scripts are pretty easy to run, we can have our QA team actually do the deployments. This keeps our developers free to geek out and not need to be nagged to deploy releases all the time.

! Nice things:

• Capistrano exports from SVN, tars the export, copies it to each application server, and then does its fun symlink magic (and anything else you configure). Luckily, it sends the system maintenance page out before it starts any of this. So my site is down during export, tar and copy over the network. Before I had a central deployment server, I would deploy from my laptop, and this would often be from home at night. Luckily my crappy DSL is limited on its upload bandwidth, so deployments would take almost 3 times as long from home. I looked into changing this, but I was getting deep into capistrano, so decided to just deal with it and use a deployment server at the office with the nice big interweb tubes.
• The documentation is good, but the formatting on the site makes me curse it every time I find myself on their site.
• Looking at a few of the configuration files for some of our production systems, I have noticed that the before and after configurations can be quite difficult to read through and figure out exactly what is happening and when.

I must say that capistrano is not perfect, but it rocks. In general any automation of deployment tasks is worth their weight in gold.

Flex Builder unfortunately does not have that option so we have to look somewhere else for a solution for testing.

While there are many applications that simulate various network conditions, Charles stud up as the most practical for Flex developers, in my opinion.

First thing that I liked about Charles is the ease of configuration. And you can configure a few things that are precious when developing a Flex app.

1. Charles supports No Caching per location. This means that you can block caching for your app that you are testing while keeping it on for other internet content that you as a Flex developer are always searching for reference. When does this comes in handy? Anytime your is loading dynamic content and especially for multimedia projects.

2. Charles supports Throttling. Works the same as Flash bandwidth profiler but also enables you to throttle specific locations. So you can set your network bandwidth to a desired speed and see if your user experience holds up.

3. As Charles shows you HTTP headers and AMF0 & AMF3 content being sent back and forward, it is extremely useful for checking data integrity. Basically, it shows you content of any data being passed through the network that has to do with your application and more. I am a great fan of AMF3 and this feature is a life saver when you are trying to debug AMF3 related issues.

Having all these wonderful features, it is also easy to use and takes about a minute to install and start using.

There is also a fully featured free version that is limited only by you being able to use it 30 min at a time. Not that it is too much of a trouble, but for convinience of developing I recomend getting the licence that is moderately priced.

Unfortunately there are not enough examples out there on how to test view controllers with the iPhone SDK. My hope is to remedy that a bit by sharing some techniques I have been using to tackle the problem, particularly in keeping with the spirit of TDD along the way.

First, If you have not already done so, configure your project to use GTM. This is a bit of a no-brainer as it currently stands. Until Apple comes up with something better, GTM is the way to go. It works as advertised, and is a credit to the folks at Google for providing this toolkit.

Now then, many tutorials on the web seem to imply that one should test somewhere in the middle by suggesting to add a few outlets to your controller, fire up IB and wire up your view to your view controller before you even start to think about testing any of it.

Testing controller logic means working under the assumption that you have wired up your view components correctly to match the controller's actions and outlets. Wire up an element to the wrong action (or worse, forget to wire it up at all) and you can easily learn to rely too heavily on manual testing. While this might be acceptable for small one-off applications, within a team of developers practicing collective code ownership, this kind of error can cost real money over time. "Thanks for caring, but I'd rather have a unit test."

Now then, let's take a look at some code!

I have been taking an alternate approach to creating my views and view controllers by writing the test first and then wiring up my components to pass the test. As a result, I'm starting to see other cool ways of tackling the problem while minimizing the amount of code required to get the system under test.

The following is a short method from one of my controller tests which allows me to assert that a UIButton is properly wired up to the right action on a controller (sorry for the screenshots, I'm having problem with syntax highlighting today):

The controller in the above code snippet is an instance variable referencing the controller under test. While it's possible to move this logic into a macro, I liked keeping it as a method. See "actionsForTarget:forControlEvent:" for more information on the second assertion-- this should work with any UIControl as long as you understand which UIControlEvents to accept. Here's a sample unit test which uses the helper method above:

This varies from other examples I have seen on the web in that I don't actually 'fire' an event through the UIButton at all. Technically that approach exercises more of the system, but in this case, if I am confident that the button is wired up to the correct action, that's good enough for me. I would rather invoke the controller logic directly within the test than make the test code longer than it needs to be.

This approach to unit testing avoids mocking, or creating custom categories to get at, say, the internals of UIEvent. Surely there is a time and place for mocks, but so far I have found the SDK to allow me just enough in most cases without requiring me to be too clever. And while I think other approaches are worthwhile in their own way, in a team environment I am less apt to mock out the internals of a system if it means making the tests harder for others to read or follow along. Clean tests are their own reward!

Let me know if you find this approach useful, or how you go about testing that your view and view controllers play nicely. I'm still looking for better ways, and plan to talk a lot more about iPhone SDK testing in the future.

Survey the software you use for yourself, both browser- and desktop-based. Think about which applications provide the most invisible, effortless interfaces. I doubt it will be the ones that hide commands in complex menus and dropdown systems.

For some negative examples, let's look at Firefox and its more social cousin, Flock. Each app offers an advanced bookmark management mechanism, but the usability of that mechanism suffers in each due to over-reliance on cryptic menus.

Here's Firefox:

Can you guess which bookmark management options are going to appear under each menu? Where, for example, would the command for adding a separator live? What about sorting your bookmarks? Can't figure it out? Welcome to the world of evil icons.

For comparison, here's Flock, the social browser derived from Firefox:

Clearly, Flock provides friendlier menus; at least they've got text labels. With enough trial-and-error training, you'll probably be able to teach yourself which command lives under which menu.

Here's another example, this time from the webapp world: Confluence, the popular enterprise wiki package. Older versions of Confluence offered the by-now-familiar star icon. Click it, and a page would be added to your favorites. More recent versions, however, hide the "add favorite" option in one of several dropdown menus. Can you guess which?

If you guessed the "Add" menu, for "add to favorites," you're wrong. It's under the "Tools" menu. Welcome to the world of evil menus.

So where does that leave us? Must every single command available in an interface exist as an always-visible text link within the browser viewport? Of course not. But there are some best practices in choosing how to build our menus:

• Icons are great, but they should either be universally recognizable (such as a star or trash can) or paired with a text label.
• Menu groupings should be intuitive. Use care in choosing the top-level labels and don't group disparate items under the same menu.
• For frequently accessed functionality, consider leaving it as a dedicated clickable item on the page. There's nothing wrong with a mixture of icons and menus, the former for the most popular features and the latter for everything else.

While developing OpenSocial applications can be a bit tricky, getting set up to develop can be a real pain in the neck. For this installment of OpenSocial and GWT, I'm going to go through the basics of setting up a simple Hello World gadget with iGoogle. We'll get into the details of signing up for other OpenSocial containers, testing, and so on, later. Right now we're just going to do the basics.

So, what do you need to build a Google Gadget with GWT for iGoogle? You need the following:

1. The Google Web Toolkit
2. The GWT Google Gadget API
3. An account on iGoogle
4. Access to the iGoogle sandbox
5. Some public server space so you can serve up your gadget to iGoogle

Pretty much everything else is self explanatory, but the sandbox can be a little bit confusing. Let's talk a little bit about the iGoogle sandbox. It's an experimental space where you can test things out without polluting your regular iGoogle account. Eventually you'll want several accounts in order to test. But every journey starts with a single step.

First, you need to sign up for iGoogle. I'll assume this isn't your first rodeo and you've done this before. Once you've got your iGoogle access, you'll want to go over to this page to sign up for the developer sandbox and add the developer tools to your space.

When developing, make sure that there's a message towards the top left of the page that says "Welcome to the iGoogle Developer sandbox." If you don't see that message, you're not in the sandbox. If you have to, navigate to http://www.google.com/ig/sandbox. You may have to "sign up" again to drop into the sandbox.

Once there, you can add those developer tools. Just clicking this link will get you started.

The developer widgets are:

• My Gadgets: let's you set inlining and caching on the Gadgets on your page from a handy interface
• Sandbox Profile Editor: let's you modify your profile in the sandbox so you can test a few things out.
• Sadbox Friends: lets you view and edit who your friends are. Important for OpenSocial applications.
• Updates:shows activities posted to your friends while interacting with the gadget.

The Hello World Gadget

In this part we're not doing anything OpenSocial related. We're just setting up a Google Gadget. That's a necessary first step for the OpenSocial stuff.

Let's get started. In my example I'll be working in ~/src/HelloGadget. Create a lib directory and put the gwt-gadgets.jar library file from the GWT Gadgets API project in it. Next, we run the GWT projectCreator to create our ant and Eclipse files:

./projectCreator -ant HelloGadget -eclipse HelloGadget -out ~/src/HelloGadget/ -addToClassPath ~/src/HelloGadget/lib/gwt-gadgets.jar
Created directory /Users/dkappe/src/HelloGadget/src
Created directory /Users/dkappe/src/HelloGadget/test
Created file /Users/dkappe/src/HelloGadget/HelloGadget.ant.xml
Created file /Users/dkappe/src/HelloGadget/.project
Created file /Users/dkappe/src/HelloGadget/.classpath

Now we create a simple sample application using the applicationCreator tool:

./applicationCreator -eclipse HelloGadget -out ~/src/HelloGadget/ -addToClassPath ~/src/HelloGadget/lib/gwt-gadgets.jar com.pathf.demo.app.gwt.client.HelloGadget
Created directory /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt
Created directory /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/client
Created directory /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/public
Created file /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/HelloGadget.gwt.xml
Created file /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/public/HelloGadget.html
Created file /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/public/HelloGadget.css
Created file /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/client/HelloGadget.java
Created file /Users/dkappe/src/HelloGadget/HelloGadget.launch
Created file /Users/dkappe/src/HelloGadget/HelloGadget-shell
Created file /Users/dkappe/src/HelloGadget/HelloGadget-compile

You now have a nice little application that you can run using the hosted mode script HelloGadget-shell in the src/HelloGadget directory. Congratulations, you have a sample GWT application.

But we want a Google Gadget. In order to make it a gadget, we have to change the code a bit. First, import the project into Eclipse. Then open the HelloGadget.gwt.xml and add the following inherit statement.

<!-- Other module inherits                                      -->
	  <!-- Inherit Google Gadgets API -->
	  <inherits name="com.google.gwt.gadgets.Gadgets" />

Now let's open up the HelloGadget.java file. We're going to change it around a bit so it can be a gadget. The critical part of the original looks like this.

public class HelloGadget implements EntryPoint {
 
  /**
   * This is the entry point method.
   */
  public void onModuleLoad() {

We change our class to extend Gadget and change the onModuleLoad method to init.

@ModulePrefs(title = "HelloGadget", author = "Dietrich Kappe", author_email = "dkappe@gmail.com", height = 300, description = "A simple gadget.")
public class HelloGadget extends Gadget<UserPreferences> {
 
	/**
	 * This is the entry point method.
	 */
	@Override
	protected void init(UserPreferences preferences) {

You have to also import the following three classes:

import com.google.gwt.gadgets.client.Gadget;
import com.google.gwt.gadgets.client.UserPreferences;
import com.google.gwt.gadgets.client.Gadget.ModulePrefs;

Running the Darned Thing

Done! Well, not quite. While changing the EntryPoint to a Gadget was pretty straightforward, we now need a container to run the thing. Mind you, it will still run in it's current form in hosted mode, but all of those things it's expecting from iGoogle are not going to happen. So it's time to inject it into iGoogle.

Go ahead and compile the code using the shell command HelloGadget-compile. The resulting compiled JavaScript and sundries is under the www directory in your projects home. If you take a look, you'll see a new file that you likely haven't seen before, namely com.pathf.demo.app.gwt.client.HelloGadget.gadget.xml. This is the gadget manifest. Essentially, this is what your gadget container needs to load to display the app. Many of the parameters are set by the parameters to the @ModulePrefs annotation.

Bundle this app up and upload it to your publicly available server. In my case, I've uploaded the app here. This is the link to the XML file. You can now go to the sandbox and, using the My Gadgets gadget, add it to your sandbox.

You can tweak some of the settings having to do with caching of he Gadget resources with the MyGadgets gadgets, but more on that later. Next time we'll set up our simple Gadget in various other containers and perform something a little bit more useful with it (but only a little).

As always, comments and questions are welcome.

Lately I've been working on a revision of one of my first Pathfinder projects, an internal agile management tool. Along with adding and rearranging some features, I'm also taking the opportunity to modernize some of the Rails 1.2 era code up to new Rails 2.1 and 2.2 features.

Note 1: I don't always (or often) recommend a wholesale update of working code when updating features. But this was a large enough feature change that cleaning up the code is worth the effort.

Note 2: When the time comes for you to perform a major refactoring like this remember that your tests have all the institutional memory about how the application should work. What I actually did was create a new blank project, and copy test files one by one. For each file, I commented all the tests, then uncomment them one at a time, rearranging the test as needed to match the new data model. Sometimes I take the new code directly from the previous version, sometimes I rewrite using a newer or better idiom. This gives me the benefits of test-driven design in my big refactor, while still preserving all the functional specification in my tests. (This seems to work better on models than controller/views, I'll probably have a fuller report next week).

There was one particular design decision in the original code that had always bothered me, but I could never think of a better solution.

In this system, the basic unit is the story. A story can belong to several other different entities in the system -- one or more users, an application, a specific iteration, and so on. Each of those entities, obviously has a has_many relationship with stories, and each one has a mostly-common set of functionality needed from that relationship -- how many stories have been done, how many are left, how many stories were done last week, and so on.

My original design placed all those common methods in a StoryGroup module. Each class that used stories had a declaration like this:

class Application < ActiveRecord::Base
  include StoryGroup
  has_many :stories
  ## and so on
end

Within the story group, there were a lot of methods that performed calculations and called back to class methods of Story, in part, that might look like this...

Module StoryGroup
  def remaining_expected_hours
    Story.expected_hour_total(remaining_stories)
  end 

  def remaining_tasks
    stories.select{ |each| !each.complete? }
  end
end

Class Story
  def self.expected_hour_total(story_list)
    if story_list.blank? then return 0 end
    story_list.to_a.sum(&:expected_hours)
  end
end

Honestly, I can't quite recreate the rationale for having the expected_hour_total method as a class method of Story. I think it's because there was a usage within the Story class before there was a need for it among the StoryGroup classes.

I have two main problems with the structure of the old code. First, having to include the module and declare the has_many relationship always struck me as kind of dodgy. Second, calling back to a class method of Story that takes a list of stories as an argument is really ugly looking, and the class methods kind of gunk up the Story class with a lot of calculations that don't necessarily belong there.

Everything works in the old version, but I was pretty sure there was a cleaner way. In the new version I solve both problems (I think). The first problem is solved by taking a page from your basic acts_as plugin. The second problem is solved with named scopes. Named scopes are particularly helpful here, since they apply to both Story as a class and to any has_many :stories associations. As a result, all the common story functionality is easier and clearer to describe.

The new StoryGroup functionality is a module, now placed in the config/initializers directory. This seems a bit verbose, but most of it is the standard boilerplate for an ActiveRecord plugin -- the main functionality will be in the InstanceMethods submodule

module ActiveRecord
  module HasManyStories

    def self.included(base)
      base.extend(ClassMethods)
    end

    module ClassMethods
      def has_many_stories
        has_many :stories
        include ActiveRecord::HasManyStories::InstanceMethods
      end
    end

    module InstanceMethods
      def remaining_expected_hours
        stories.uncompleted.sum(:expected_hours)
      end
    end

  end
end
ActiveRecord::Base.send(:include, ActiveRecord::HasManyStories)

On initialization, the has_many_stories method is added to ActiveRecord::Base. Any ActiveRecord class that calls the method, then gets all the instance methods included within it (I've left out common class methods, because they are not needed for this example)

Adding the story relationship and the common methods is now down to a single line within the class:

class Application < ActiveRecord::Base
  has_many_stories
end

In the new module, the remaining_expected_hours method has changed, now calling the named scope stories.uncompleted rather than a class method. The scope definition itself is straightforward.

class Stories
  named_scope :uncompleted,
      :conditions => {:state => ["new", "in_progress", "blocked"]}
end

As an added bonus, using the scope and appending sum to the scope now does the calculation in the database, which should be faster than the earlier version, which was calculating the sum in Ruby.

I like this cleanup. The individual methods within StoryGroup are now significantly simpler. The named scopes they depend on are also simpler and less distracting in the class then the previous class methods. Because the scopes are compossible, it's much easier to add calculations to the various slices of stories that the system needs.

UPDATE: to clarify something pointed out in comments. Yes, it would be possible to put all the instance methods in the HasManyStories module as class methods of Story. They would be polymorphic with associations in the same way that named scopes are. I admit I didn't really consider that option in my refactor. I'm conflicted about it -- it's clearly simpler, since it avoids the tricksy module load, but a lot of the methods in HasManyStories seem odd if placed as class methods of Story, that's part of why I wanted to move them in the first place...

What do you think? Have you had a similar problem? Is there a better way to solve it?