Archive : March 2009

IE8: That Sinking Feeling

power dump

When a new browser comes out, like IE8, the verdict usually rolls in over the course of a few weeks as our QA testing on various web projects bumps up against its limitations. It's too early for us to render a verdict, but the signs have not been good and continue to be negative.

The evidence continues to trickle in. Louis-Rémi Babé weighs in with his grim assessment:

  • The JavaScript performance on IE8 is still lousy.
  • Useful tags such as <canvas>, <svg>, <video> are still missing.
  • CSS3 is minimally supported. (I agree that this is good news for web developers since we get to charge more money for all the extra effort that goes into IE8 work.)

To top it all off, Vector Markup Language (VML) is freshly broken. It's one of those sad and frustrating stories. Read up on it here and feel sorry for all of those framework developers who have to crowbar in several hacks for all of the garbage in IE8.

Topics: ,

Which Mobile Platforms Should You Target? (Part 2)

mobilelogos4In the first installment, we covered the simple case, where your application is really a web app, not really using any device features, without local storage, just pulling data from a web application.  This time, we’ll tackle true native applications.

Continue reading »

Again With The Cucumbers

My cucumber obsession continues unabated. I've spent a lot of the last week adding Cucumber to projects, writing about it in a very long section for the Rails Test Prescriptions book, and generally trying to figure out how to use this tool, not to mention trying to figure out why this tool has been so interesting to me this week.

Some follow-up thoughts since last week's post.
Continue reading »

Data Driven Design and the Culture at Google

A peek under the hood of google's design apparatus.

Numbers

In an interview with Newsweek magazine, Irene Au, User Experience Director at Google discusses her responsibilities, and in the process, reveals some telling things about the way design decisions are made at the multi-billion dollar internet company.  Perhaps not surprisingly, she makes it clear that Google takes a data driven approach to interface design just as it does to everything else.  The subjective opinions of art directors or visual designers don't play a key role in the design of their products.  As she states, "A lot of our design decisions are really driven by cognitive psychology research that shows that, say, people online read black text against a white background much faster than white against black, or that sans serif fonts are more easily read than serif fonts online."  No argument here.
But is a completely empirical approach to interface design desirable, or even realistic?  Isn’t it more likely that the left brain culture at google puts greater weight on the opinions of engineers, even if they are being just as subjective? One blog commenter put it this way, regarding Au’s interview with newsweek:

Continue reading »

The Costs of Building Secure Applications

Achieving Balance

'Achieving Balance' by James Jordan

Security is unlike other aspects of software in that it follows a steep value curve: either your system is secure, or it is not. Either it provides its full level of value, or it provides none at all. There is often a tendency to address security up front (even when other aspects of the system are built iteratively). What others sometimes fail to see is how this generates unneeded cost and complexity as the project matures.

Continue reading »

Topics: ,

See the Code, Be the Code

Haywards Heath Mob # 5
Creative Commons License photo credit: foxypar4

If you've every seen professional golfers drive the ball up the fairways, or putt the ball on the greens, they make it seem so easy. But for the vast army of us duffers out there, we know it is anything but.

There are many variables to consider to ensure success on every hole you play. There's the distance from the tee to the greens, the natural elements  -- wind, rain and sun --, the number of allotted strokes per hole, the vexing choice among various woods and irons, the hazards dotting the course, and the mental and physical aspect of dealing with this humbling game. But there is one answer to these challenges: practice, practice and more practice to fine tune your craft. Well, developing software is similar in many respects.

Software development has it's own thicket of variables to consider. There are the many functional and non-functional requirements that you must contend with, the different users involved (stakeholders, development team, system users, and the army of user persona's) for the project, the changing requirements, resources and time that can impact the project, and various tools, technologies and platforms thrown into the mix as well.
Continue reading »

You’re at the Software Development Finish Line! …. or are you?

finish-line2-copyThere is so much focus and investment put into developing a new software application that many people fail to see that completing the development isn’t the end of the road; it’s really just the beginning.

For one thing most people don’t realize that over the life cycle of a good software application, more development time is expended after the initial application is developed than within the initial development effort. While it’s a cliché, it is so true that “change is the only constant over the long run”. Therefore your application, no matter how well suited for your requirements now, will have to change over the years and evolve over time.

While ongoing life cycle software development can be the subject of future blog posts, my intention was to be more myopic today. I want to focus on what you’ll need to have in place when you are ready to launch as these requirements are often not well understood. This post will also not address any data conversion, integration issues, or related steps that may be required to implement your system. These are all valid issues but not today’s subject.

In the last 25 years, having resided in both the corporate world as CFO and a couple of times as the CIO and now on the other side of the table with organizations in the consulting world, I almost always see a gap in expectations. The root cause is that most people just don’t appreciate or take for granted what all goes into supporting an application. Even in the IT field, I’ve found that network people generally don’t fully appreciate what programmers have to do and vice-versa.

Let’s break it down. You’ll need to have services that we’ll organize into the following categories: hosting services, production support services, and software maintenance.

Continue reading »

Bean of the Devil: Tally-Ho CMS

beanLast time we came this way we looked at the misuse of a getter in the java.io.File. Not that it was wrong to have a getter in File, just that it led to misuse of that information in a UI control to determine what file encoding needed to be used to store the model.

This time we are looking at the Tally-ho CMS project. This is perhaps a more pernicious example of the shortcomings of getters and setters. We're not having to remember rules about changing state here (that's for an upcoming post), but we are exposing the implementation details and thus repeating code and making our application harder to change.

There are many places where ArticleBean is unpacked in the application. Here are just two examples.
Continue reading »

Using Cucumber for Acceptance Testing

An consistent nuisance problem when testing Rails applications is the "unit test gap". This happens when the model test passes and the controller test passes, but the application as a whole fails because there's a mismatch between the output produced by the model and the input given to the controller test. In theory, Rails integration tests can solve this problem, but they aren't really designed for it, and nobody uses them much anyway.

An easy-to-use tool that solves that end-to-end testing would be great. Somebody should really write a blog post about that.

So, as I was saying. We continually run into an issue with our clients over defining requirements at the level that developers need to keep going, without getting bogged down in long stretches of design. There's a big gap between "users should be able to upload photos to their pages" and all the different details of permissions, validation and the like than need to be answered at some point. The Agile process suggests that those requirements be created as closely as possible to the code, which leads to the question of how best to keep the customer in the loop while the developers need these decisions to be made.

An easy-to-use tool that lets users read or create requirements that developers can build from and run as acceptance tests would be great. Somebody should definitely write a blog post about that.

Which brings us -- finally -- to Cucumber, a tool for creating automated acceptance tests. It's flexible enough to solve both problems. It can be used as a developer tool to drive regular TDD testing, and as a client tool for managing requirements.

Self promotion: If you want to read more about Cucumber and all kinds of Ruby testing, buy the beta version of Rails Test Prescriptions. Cucumber isn't in the book yet, but will be in the next release, schedule for the end of March. Buy now, and get all future updates free of charge.

Continue reading »

Definition of a Feature (Given … When … Then)

defining requirementsAt some point in their career, most everyone in software development has encountered the client who paints a very eloquent picture about their fantabulous idea that’s going to revolutionize the [insert industry vertical here]. However, as time goes on you realize the client’s staying at the 60,000 foot level, and while that may make for great conversation, it's less than ideal for actually developing something. The trick, then, is to get them to climb down into the trenches and define the details before you have to start writing the code.

At Pathfinder, we’ve been involving clients in creating business-driven scenarios to define a feature, i.e., what does ‘create accounts’ really mean. These scenarios walk through the different tasks of a feature and identify the expected behavior and outcome based on the user’s actions. Although they follow a specific format (context, events and outcomes), they are written in plain English that can be understood by all team members.
Continue reading »

Get A Room! – Why Campfire Rocks

Campfire, a group chat program, allows teams to have chat rooms, and search the old chat content.  I used campfire about a year ago, right before we were going live on a project.  I hated it. Here's why:

  • There were about 6 of us in the room, and we were all pairing on different activities.  I kept on having to check back into the room on things I really didn't care about.  I found that as soon as my pair and I finished a task, we had to scroll through pages of chat to get caught up on the details of the other pairs' activities.
  • It was a web client, so I had to actively poll for updates.
  • It seemed to detract time from my already busy schedule.
  • We were all rushing to finish up things for go live, and it was a new program to the team.  Perhaps if we had used it all along, it may have been more useful

We recently started using it on the current project that I'm managing.  I now love it.  Here's why:

Continue reading »

Topics: ,

Pairing Remotely for Fun and Profit

471300085_0fb942a10f_mLove it or hate it, pair programming is a large component of many agile development methodologies.  I've become a firm believer in the benefits of pairing, and very rarely write code nowadays without some degree of collaboration with a second (or third) developer.  The benefits have been vast.  The code is better thought out because a pairing session always starts with a discussion of the approach to be taken.  Fat-fingered mistakes are headed off at the pass because a second set of eyes is closely watching what's being typed.  Less time is wasted checking email, taking calls from the in-laws, and just generally doing things that would annoy the second member of the pair.  Above all, it allows developers to analyze and quickly debate the approach being taken,  and adjust and improve that approach throughout the development cycle.

It all sounds great doesn't it?  Well it is when executed correctly.  In my experience there are two general principals that if not adhered to, will turn a productive pairing session into a developer writing some mediocre code sitting next to a developer who might as well have taken the day off.   These principals are: developers must remain engaged, and developers like their own space.

Continue reading »

Which Mobile Platforms Should You Target? (Part 1)

Major Mobile Platforms Our company gets a lot of requests for mobile application development.  Most of the time the request is for a specific platform like the iPhone or Blackberry, but every so often we get a request for “all major mobile devices.”  That request usually changes when people realize that developing on iPhone, Blackberry, Android, Windows Mobile, Palm, etc. really means developing five or more separate applications.  The next question is usually what platform should they target first. That’s not an easy question to answer, because of the constant changes in the landscape and the type of application in question.  Here’s how we tackle it:
Continue reading »

Week in Review

Some interesting posts from around the blogosphere:

  • The GWT Plugin for Grails has been stuck in version 1.4.x of GWT for forever. Michael Galping has published a two part (one and two) series at IBM Developerworks on integrating Grails and GWT 1.5.3. Extensive, well illustrated with full source code available for download.
  • InfoQ has published an interesting conversation about Ajax and COMET versus HTML Web Sockets, i.e. hacky COMET versus real bi-directional communication mechanisms between the server and browser.
  • UXDesign.com has a concise summary of an Alan Cooper Interview video from 2008. User Experience Design, baby!
  • David Hamill has some provocative musing on the difference between usability and user experience design. Not sure I agree with everything he has to say, but it's a question that comes up often and is worth thinking about.
  • A bit older, but I just came across it: the original ScrumMaster, Jeff Sutherland, has an interesting article about ROI and incremental development. The conclusion? Incremental is better. :-) But seriously, we don't have enough rigorous thinking and writing about how good design and process reduces the cost of software in the long term (while perhaps increasing it in the short term).

These were some of the posts that I found valuable over the last week. Please share yours in the comments.

Rails Test Prescriptions is now on sale

Rails Test Prescriptions: Keeping your Application healthy is now on sale. This is a beta, partial release.

Rails Test Prescriptions is a comprehensive guide to testing your Rails application, covering both the mechanics of writing tests and the style for writing good and useful tests.

I'm excited to be publishing this electronically in a way that allows me to keep the book up to date as Rails changes over the upcoming months and years. Your $9 purchase entitles you to all updated versions for the life of the book.
Continue reading »

Launch: Pathfinder Newsletter

    Get a monthly update on best practices for delivering successful software.

    Subscribe via email


    Subscribe via RSS      RSS icon

Topics

Search

WordPress

Comments about this site: info@pathf.com