March 2009 Archives

Whenever I think of cowboys, I think of free spirits, tanned, dusty loners riding their trusty steeds across the rugged vistas of the South-West. I think of self-sufficient men whose only visceral fears might be that of a warm bubble bath or a soothing MANicure. Basically, I think of The Magnificent Seven, minus the unfortunate Horst Buchholz.

When I hear the term "Cowboy Coder", I think of the smartass kid in high school who thought he knew more than the Comp. Sci. teacher and brought the whole school network down through some clever cocktail of arrogance and incompetence.

Whoah Cowboy!

While software development is one of the best careers for creative, independent thinkers (stay tuned for an upcoming blog entry on that very subject), it is not a place to exercise one's Lone Ranger sensibilities. Developing serious software is generally a team effort (just don't tell Chris Sawyer). When managing a software project and the various rough characters that make up a team of developers, it is important to put in place a development process that leverages the strengths of the many while smoothing out the inevitable friction their individual efforts will cause.

As defined in The New Dictionary of Cultural Literacy, "Too many cooks spoil the broth" means that "When too many people work together on a project, the result is inferior." (Ask Microsoft about that one.) In other words, even with the best of intentions, it is possible for a skilled developer to write code that will "break" someone else's code. In fact, you can pretty much expect it. (When one developer does this repeatedly, he's likely gone off and become a Cowboy Coder.)

So how do you give free reign to your developer's creativity while ensuring that their individual efforts don't slow down the progress of the whole?

I've been in this business for a few years now and I've been programming (in some form or other) since around 1986 (hello, BASIC!). Whereas in the past (see: University) I've been able to sit in front of a screen for 18 hours a day with only my contact lenses as protection, I've recently run into some issues that have made me re-examine how I treat my globes. Specifically: during successive business trips to a client site in Chicago, I came down with very unpleasant cases of conjunctivitis (also, see this write-up on HealthyOntario).

For starters, I've decided to look at how I've set up my development tools. I need to find the best, clearest, most ocularly soothing font for editing code in Flex Builder and elsewhere.

Eyeballing the best possible font

I've come across this fine site by Trevor Lowing which provides a collection (with clever examples) of different code-friendly "mono-spaced" fonts. It puts forward the following "good programming font criteria":

1. Crisp, clear characters
2. Extended character set
3. Good use of white space
4. 'l', '1' and 'i' are easily distinguished
5. '0', 'o' and 'O' are easily distinguished
6. Forward quotes are easily distinguished from back quotes (ideally with a "mirrored" appearance)
7. Clear punctuation characters, especially braces, parentheses and brackets

The list seems pretty complete to me, though I might add "thick enough for viewing on LCD screen", since some fonts seems downright Olsenish for my tastes...

Setting text editor fonts in FlexBuilder/Eclipse

If you're a Flex Builder/Eclipse user, here is how you change the font used for editing files:

Go to Window > Preferences
From there, go to General > Appearance > Colors and Fonts
Select Basic and double-click on "Text Font". The font settings dialog will pop up.


Make sure to have an editor open, so that when you click on "Ok" and then "Apply", you will see the font changing in the background. This will allow you to try a number of fonts until you get the settings just right.

Your take?

I plan on trying out new fonts in the coming weeks so I'd be interested in finding out what font you use for coding/scripting. What font size? What display configuration (size, single or dual display) and screen resolution?

Thanks for reading!


Taylor

"We aren't dealing with ordinary machines here. These are highly complicated pieces of equipment almost as complicated as living organisms. In some cases, they've been designed by other computers. We don't know exactly how they work." - Westworld (1973)

If there's one thing about humans, it's that we are incredibly good at making simple things complicated. A few examples come to mind. We can take simple activities and make them into highly competitive spectator sports (see: ping-pong, poker, rock-paper-scissors). Heck, Starbucks has made it a skill testing question to answer what size of coffee you want.

Inevitably, this same uncontrollable, instinctive human urge applies to software design.

Decisions, Decisions

As our Flex practice matures here at 4Point, the scale and complexity of the Flex-based projects we are developing are increasing. It's an exciting time. It's also a time for important decisions to be made.

Here are a few:

• What formal(ish?) development methodology should we adopt?
• Should we move to test-driven development?
• Would we benefit from setting up the infrastructure and process for managing continuous builds?
• What framework(s) should we use as the foundation of our Flex applications?
• What should be our preferred back-end technologies? Java? .net? Ruby?

None of these decisions are mine to make. We have some very capable and battle-hardened "Solutions Architects" here who are responsible (i.e. "on the hook") for deciding these things. My contribution is to feed information into the process and provide my own opinion.

That said, I was tasked to do some research into implementing a test-driven Flex development environment. I have looked at and tested some of the currently available unit-testing tools (FlexUnit, ASUnit, MockAS3, etc.) and have tried using Maven for continuous Flex build management. Given my background in test-driven Java, it has been quite an eye-opening experience (but that's for another post).

Enter Mate

Until now, different frameworks have been considered for use in upcoming projects. You know, the usual suspects: Caringorm, PureMVC, etc. However, since I watched a video presentation of Mate, my professional curiosity has been piqued. It seems to me to be an elegant answer to the challenges of formally structuring a Flex application. By using dependency injection and implicit invocation, code and components are decoupled and lend themselves to unit-testing. All-in-all, my sensibilities as a software designer make Mate a very attractive option.

I've read various reviews of Mate, principally Tony Hillerson's framework throwdown at InsideRIA. I've watched various videos by Laura Arguello from ASFusion. I've talked to other developers. One big question still remains.

The Big Question (tm)

As we debate the benefits of the different frameworks here at 4Point, some concerns have been raised by reports from some quarters that Mate may not be well suited for larger systems. Supposedly, Mate's use of "bubbling up" events and numerous open listeners (that may or may not be used) leads to major memory issues in larger-scale systems.

Does anyone out there have any experience building complex/large applications using Mate? If so, can you please answer this question:

"How well does Mate scale?"

Even if you're using a competing framework, I'd love to hear your 2 cents on Flex scalability best practices. Please post a comment or drop me a line. Any and all input is greatly appreciated.

Thank you.

Now back to perfecting my rock-paper-scissors technique.