Atomic has strong opinions about how to do projects, and we have practices that are so deeply a part of our culture that they are taken for granted internally. There’s a common way we approach all the projects we do, whether it’s embedded, desktop or web, in any of the many domains in which we work. I’ve known this for a while, but I’ve never had a good word for it. Watching one of our younger developers on a recent project gave me that word.

People at Atomic have a strong projectstance.

In the last few weeks, customers and potential clients have asked me on several occasions how Test-Driven Development relates to legacy code (incidentally, one fitting definition for legacy code is code having no test suite).

As much as we all might like to throw out legacy code (especially when it’s craptacular) and “do it right”, that’s often an entirely impractical option or just a plain dumb thing to do. Reality is that there’s no magical formula or one-size-fits-all procedure for dealing with testing and legacy code. Each case is unique and requires a thoughtful, responsible approach. That said, I offer here guidelines toward tackling the challenge in a thoughtful, responsible way.

Part of a series on Making better estimates. Estimation is frustrating: fuzzy, difficult, inexact. You can simplify the process, reduce the effort, and maybe even improve overall accuracy by trying to be less accurate at the detail level.

If you’ve spent any time doing HTML and CSS development, you know that Internet Explorer is frustrating. “Seriously?” “Yep.” One of the largest frustrations is that each version of IE has different bugs from the next.

But I have some good news. When you’ve tried everything, and you simply cannot make a site look consistent between browsers, there’s a pretty easy fix. In the header, you can put this text below your main stylesheet link. It should look something like this…

Bill Higgins draws an interesting parallel between the ideas of The Uncanny Valley in human-like robot design and user interface design. He makes an argument for why web apps should look and act like web apps and desktop apps should look and act like desktop apps. He even offers interesting thoughts on why Java never took off on the desktop.

“The Uncanny Valley of User Interface Design“

”... we must ensure that we design our applications to remain consistent with the environment in which our software runs. In more concrete terms: a Windows application should look and feel like a Windows application, a Mac application should look and feel like a Mac application, and a web application should look and feel like a web application.”

“So I’d recommend that if you’re considering or actively building Ajax/RIA applications, you should consider the Uncanny Valley of user interface design and recognize that when you build a “desktop in the web browser”-style application, you’re violating users’ unwritten expectations of how a web application should look and behave.”

Atomic Object has been providing development and consulting services for a company in the healthcare industry. We’ll refer to this company as DoctorsInc hereinafter. Our primary focus was to bring agile project management and TDD practices to DoctorsInc’s development process. The group that we worked with at DoctorsInc uses a powerful ETL tool called Ensemble.

Ensemble is a product developed by a company called InterSystems that sits on top of another product called Cache. Cache is an integrated development platform and OODB that provides a powerful set of tools for development, database management, and much more.

Part of a series on Making better estimates. Relative estimation in arbitrary units beats absolute estimates in actual time units.

Ever create a page that works fabulously in Firefox, and then you try testing in IE 6 or 7, and there’s a chunk of text that has simply disappeared? “Where is it?” you ask the computer. The computer doesn’t respond. I’d imagine that it too must be sick of all the IE questions. So then you try to highlight the content on the page, or maybe you scroll down to see if it has decided to take a vacation by the footer and…

VOILA! It appears!

When debugging a webpage for multiple browser use, it’s easy to overlook the DOCTYPE. Just the other day, I was racking my brain on a particular bug, and it didn’t dawn on me until much later that it was because the page had no DOCTYPE.

It’s an easy thing to forget about, and though we all know a DOCTYPE needs to be present, I believe it’s important to know exactly why its vacancy causes problems.

Part of a series on Making better estimates. Experiment trumps speculation when it comes to improving estimation accuracy.

Part of a series on Making better estimates. Mining data from prior projects, especially if time was formally tracked, can be an invaluable source of data for estimation efforts.

Last week I was creating a web form that generated a few emails upon submission. I was dropping my code into a client's existing site that was developed by a different company. The existing code had no tests and looked like it was being pushed right to production via Dreamweaver or something similar. It was also one of those PHP, MVC-all-in-the-View situations. Hey, it's all party though... right?

I decided to manually test the form because the scope was small, there was no professional way to deploy the entire site, and there was no suite of existing regression tests that could be run. I still needed a way to iterate quickly while conducting manual tests.

Greasemonkey saved the day! I was able to write a quick script that filled out the form with some baseline data. I could switch some of the data manually and check the results quickly. I was able to use the same script in production. The experience reminded me of writing automated Selenium or Celerity integration tests and prompted me to think more about utilizing Greasemonkey as a QA tool.

--UPDATE--

Kristofer commented that a brief example would be useful.

Using Firefox, I got the Greasemonkey add-on. Once installed, I browsed to the form I was developing and navigated the Firefox menu: Tools -> Greasemonky -> New User Script... Then I wrote the Javascript that would fill in the form. I added a listener for the window onload event and within the callback I accessed the dom and updated the form values. It looked similar to this:

1
2
3
4
5

window.addEventListener("load", function(event) {
  document.getElementById("name").value = "Name";
  document.getElementById("email_address").value = "test@example.com";
  document.getElementById("address1").value = "123 Cranberry";
}, false); 

I had to create HTML and Mouse Event objects to invoke click and change events on some of the form elements that had their own event handlers. The Greasemonkey user script manager window allowed me to associate the script with my development and production deployments.

This was some really simple stuff that proved to be very helpful.