Agile Ajax

Bandwidth profiling Flex projects and more with Charles

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.

Continue reading »

iPhone SDK: UIViewController Testing & TDD

iPhone in Dock

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!

Continue reading »

Icons are evil; so are menus - unless you do them right

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.

Continue reading »

The Truth About Designing For Security

\
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:

  • All security models are idiosyncratic
  • Never underestimate the cost of being flexible

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 »

GWT, Gadgets and OpenSocial, Part 2

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:

  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

Continue reading »

Has Many has_many: A Refactoring Story

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).

Continue reading »

Topics:

The Hidden Power of Canvas

Projective TransformWhenever 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.

Topics: , ,

Review of fixture_replacement2 plugin

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.

Continue reading »

Chess Game Viewer in GWT

It's not quite done (the game notation looks like crap in IE), but I thought I'd give a taste of my latest labor of love, a chess game viewer in GWT. This is the sort of thing that is usually implemented as a Java Applet. A few others have already built chess viewers in GWT, but as they say in Full Metal Jacket, "this one is mine." :-)

As I blogged a few weeks ago, I ported the Java chess library ChessPresso into GWT, which was a blast and an example of how you can leverage existing Java libraries to write browser-based apps.

In the example, I've pulled the eleven games of the recently completed world championship between Anand and Kramnik in a single page. The GWT app identifies all of the relevant tags, reads the PGN (Portable Game Notation) in those tags, then inserts a game viewer widget into the page.

What isn't working yet:

  • Doesn't look so good in IE (a little CSS work)
  • The notation pane isn't hooked in so you can click on a move and jump to the position

Anyhow, have a look and let me know what you think.

Update: OK, the notation panel is hooked up to allow clicking on moves to navigate aroung the game. Still looks like crap in IE, though.

Update: for those interested in some of my very few games that make me look good, see here.

Update: Another set of tweaks to display a collection of games, one 41 games PGN chunk and a 250 or so chunk. See here.

Topics: , , ,

From JSP to Ruby on Rails: First thoughts on front-end coding conventions

Now that I've got a few Ruby on Rails projects under my belt, I finally feel qualified to comment on Rails front-end coding conventions. As a UI specialist coming to Rails from the JSP world, I find a lot of room for improvement in the RoR approach to view-layer code. I love working on the non-view aspects of RoR projects, but I find I've got to do tons of cleanup at the ERB layer. Expect to see some open-source components from Pathfinder to help ease this pain. In the meantime, let me articulate my pain points:

Code organization

If I'm filling a front-end role on a Rails project, most of the files I need are in /app/views and /public. I dig that. Likewise, I appreciate the underscore naming conventions for partials. However, I wish /layouts weren't just another subdirectory of /app/views. Layouts are inherently different from standard view templates. A better hierarchy within /app/views would help drive this home. Likewise, I wish partials and full templates each had their own directory within a specific controller's view folder. That would help keep directories manageable on big projects. The /public directory, on the other hand, offers just the right amount of organization.

Continue reading »

Topics: , , , , , ,

Helpers and Partials

Everybody sing! (to the tune of "Love and Marriage")

Helpers and Partials

Helpers and Partials

Go together like a

Fire and a Marshal.

Okay, that was silly. In my defense, the tune has been going through my head all day since I decided this would be my topic today.

Yes, we're back in Chapter One Zillion And Three in the ongoing epic: How Do You Write View Code Anyway?

Previously, I had tried to move as much view code as possible to helper methods. This produced some interesting code, as well as a threatened revolt on the part of the non-Ruby programming HTML designers and architects who had to look at it. Pitchforks and torches were mentioned, and there was muttering about know-it-all code monkeys. The primary complaint was that non-Rubyists couldn't easily modify the code buried in tangled Ruby gunk in helpers. At the same time, everybody agrees that ERb code running all over the place is a total mess.

What to do, what to do?

Listen to me, of course. Here are my thoughts about managing view code. This week.

Continue reading »

Topics:

Testing various roles in ruby on rails

On pretty much every project I've ever been on, there have always been various roles in the system that experience different behavior. Admins can generally do everything, end users get the least functionality, and there are always a few in between that vary based on requirements. Unfortunately, all too often all possible scenarios aren't tested, or they test only positive cases for each role.

In my current Ruby on Rails project, I am checking all roles and ensuring those who should be able to do certain things are able to, and those that shouldn't are unable to. What I have found, is that usually, the Admin and one other role can usually do a set of things, and every other role can't. So, I find that I set up my tests the following manner:

['root','hr'].each do |role_name|
    context "logged in as #{role_name}" do
      setup do
        login_as_user(role_name)
      end
 
      should 'index' do
         get :index
         assert_response :success
         # other assertions
      end
  end
end

Continue reading »

Skinning Flex with Illustrator CS3

There is many ways to skin Flex applications. To name some that I've used: Flex CSS, Programmatic AS3, Flash, Degrafa, Photoshop (JPG's, GIF's and PNG's) and Illustrator.

What usually needs to happen on a project is a combination of some or all of the above. Not having a single point of reference for skinning creates quite a bottleneck.

From different approaches, two surfaced as having the best pipeline: Illustrator CS3 and Degrafa. If we are talking speed and ease of graphic design, I would now default to Illustrator CS3. For advanced skinning and interactions Degrafa holds first place.

Continue reading »

What makes a good requirement document for an agile project

As a developer, I start from requirements. I have worn project management and business analyst 'hats' on many projects (but I am a geek, as I really enjoy the developer hat the most). My coworker, Alice Toth, has come up with a pretty awesome template and style of writing requirements that seems to be perfect for the agile development methodology. Too often, I see struggling projects struggle, because their requirements suck. I look at their "requirements" and they are nothing more than a picture with a bunch of notes. The developers have so many questions, and in general, all people involved (client, developers, BAs, IAs and testers) don't have a good understanding of the system as a whole, and what are the various personas that use the system.

I have worked on projects that have used Use Cases and Functional Specifications, but these never seem to convey all the necessary information for all involved. They tend to be very verbose, and they are really not fun to write, read or manage. A good requirement should tell each audience member exactly what the expected functionality is, and never generate a myriad of questions from all involved. It's often difficult to solicit information from a client, but documenting for developers should never be that hard. Here is a recap of what a good requirement is:

Continue reading »

Installing Edge Ferret/acts_as_ferret

If you do a gem install ferret, you will be getting 0.11.6. The latest stable version of acts_as_ferret is 0.4.3. Both of these versions were released nearly a year ago in November 2007. Since then, there have been various performance improvements and bug fixes which you'll be missing out on. In order to get the latest versions, you'll need to do a little bit of work but I would recommend it if an update is feasible for you.

Since it will be the easiest, let's begin with acts_as_ferret.
Continue reading »

About Pathfinder

  • We design and build extraordinary applications for companies looking to make the next great idea a reality.
  • learn more

Topics

WordPress

Comments about this site: info@pathf.com