We are a user experience design and software development firm
Hire us to design your site, build your application, serve billions of users and solve real problems.
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.
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.
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).
Definately ActiveRecord. Particularly associations and association methods, and named scopes (because they feel like association methods but on one model).
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.
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
Thorough implementation of Regular expressions throughout ruby and rails.
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.
Topics: Ruby on Rails

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.
Topics: iPhone, textmate, unit testing, xcode
Many times open source projects are mute -- they have insufficient documentation. Good technical blogs can function as a sort of ad-hoc documentation. That's what I've tried to do, most recently with my series of posts on GWT and OpenSocial. Vinay, over at Web Technology I/O, often does the same. He's got a great post about Ray Cromwell's GwtQuery (JQuery-like syntax in GWT) and how to make it work.
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've been pairing with my colleague Noel Rappin on a cool Rails project lately, which has helped me turn a bunch of conceptual knowledge into real-world experience. I'm writing Ruby code, doing things the Rails way, and hewing faithfully to test-driven development.
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?
Topics: Javascript, jQuery, Prototype, rails, ruby
Two major bits of news from this week:
If you've got any news that you'd like to announce, ping us at ajax@pathf.com.
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!
Topics: Ruby on Rails
I have been a developer for many moons, and have taken many systems to production. I must say that production deployments were never on my list of things that make me warm and fuzzy. This was due to the fact that they weren't automated, or the automation was poor. On a recent java project, we had a series of simple sh scripts that did the work of deployment. We deployed war files to 12 application servers and to about 60 JBoss nodes. Before the automated scripts, a developer who typed wicked fast did all of the deployments. Without him, deployments would have been a nightmare.
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.
Continue reading »
Topics: capistrano, deployment
Adobe Flash comes with a very useful feature for bandwidth profiling. It allows you to see how will your site/app act under certain network conditions.
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.
Topics: amf, bandwidth, bandwidth profiling, caching, Charles, Flash, Flex, throttling
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!
Menus and dropdowns seem like attractive design choices because they conserve screen real estate while providing users access to a potentially large number of commands. But if you resist the easy out of menus and dropdowns, you may find that your applications become far more usable.
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.
Topics: Confluence, Firefox, Flock, User Experience, user interface, UXD

Security is an area of concern where value and cost are often difficult to estimate. While big mistakes made early on in many areas of an application may prove difficult to correct, this is especially true for security, since its specifications often model a direct reflection of an organizational structure.
And all too often, dysfunctional organizations create dysfunctional security requirements.
It is common knowledge then that a failure to account for security from the start can prove much more costly in the end. However, over-engineering security needs can require so much effort that your team may not have enough time left over to actually build the very features you are trying to secure.
I find the following two points very useful to keep in mind when participating in discussions concerning security regardless of the application, but especially when working under the assumption that a new application needs the same kind of security model as the old application:
These two items work as polar opposites of each other: a flexible system can accommodate many types of organizations, but not without the added cost of training, installation, documentation or maintenance. On the other hand, a static model is cheap to build, but rarely captures the nuances of an organization's structure, particularly as business needs evolve over time.
Continue reading »
Topics: architecture, Design, Security
Note: It is assumed that you know your way around GWT and Eclipse for purposes of this tutorial.
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:
Topics: Google Gadgets, GWT, iGoogle, OpenSocial
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).
Topics: refactoring, Ruby on Rails
Whenever we have Flash versus DHTML discussions in the office, someone usually utters the words "you probably can't do it, unless you used Canvas and some fancy JavaScript..."
At times that can seem like a cop out, an admission of defeat in the face of the Flash arsenal of graphic effects. Somtimes, like today, it seems more like a visionary declaration of the power of Canvas. Check out Steven Wittens' use of Canvas for projective texturing. Maybe there is a little bit more coolness left in these Ajax bones.
We have been using fixture_replacement2 on some of our Ruby on Rails projects. I am writing an internal application and finally switched over from using fixtures. It took a bit of time to get the tests that I had written modified to stop using the fixture data, but now I am completely fixture free. The tests are a lot easier to write, and I created a few helper methods that setup common datasets. This way, I can call a setup method to configure my data, and then - it's all good. At first I called the method test_data_blah, and was wondering why I was getting an error running any test, so now it's called data_blah. Doh!
At first I didn't like the fact that I needed to explicitly create the data for what I was working on, but then I realized that (especially for unit tests) you don't need much dependent data; usually it's one or two records. For functional tests, I found that the data setup methods rocked, as I could quickly get the data set up that I needed.I could quickly assert the content of the response, based on the data in my setup. I missed fixtures at first, but now realize that over time, they are a pain.
Topics: fixture replacement, fixtures, plugin, plugins, Ruby on Rails, Testing
Hire us to design your site, build your application, serve billions of users and solve real problems.