Category: Programming

  • If you want to cut a bolt, use a bolt cutter

    I saw an EDS ad in Forbes today which had what I thought was an interesting tagline:

    You can talk about it.
    You can think about it.
    You can hope for it.
    But if you actually want to cut a bolt, use a bolt cutter.

    This is so true. Yet as a software developer, this is something I tend to forget. I can blog all day about how wonderful Ruby is, but if I really want to prove its worth I should be willing to do something with it. Likewise, if I haven’t actually created something in C#, I have no basis for commenting on the language, either negatively or positively. Experience breeds credibility and authority.

    Don’t just talk about cutting a bolt. Get out that bolt cutter and use it!

  • Cleaning up on the web with AJAX

    Forbes.com hops on the AJAX bandwagon with a brief overview of what some new businesses are using it for. I found the point at the end about AJAX impacting Nielsen/NetRatings statistics particularly interesting.

  • Decoding COM HRESULT error codes

    As I mentioned in a previous post, I’m currently slogging through the melancholic mire of testing .NET/C# code. In the process, I’ve been receiving exceptions which give an HRESULT code in hex (i.e. 8×80020005) and not much else. That got me to wondering what these HRESULTs are and how to decode them. This wondering led me in turn to this page which has an excellent overview of what HRESULTs are and why they matter. I also uncovered a link to a freeware tool called HR Plus which can decode HRESULTs and give you a (usually helpful, sometimes vague) idea of what they mean. Both the page and the tool have been extremely handy to have around. I hope they prove handy for you too.

  • Eclipse, Visual Studio, and Ward Cunningham

    As Rich Main blogged in mid-October, Ward Cunningham recently left Microsoft for a job at the Eclipse Foundation. I found this especially fascinating considering that, after over 4 years of developing with Java, a job change recently required me to begin using C# for automated testing. The pain of doing so has surprised me.

    For some odd reason, I assumed that a product like Visual Studio made by a giant like Microsoft (and with a whopping $350+ price tag) would be at least comparable to, if not superior to, Eclipse (which, of course, is free). I was woefully incorrect. Some of the best features of Eclipse, such as auto-refactoring, are just not available. Other features have been implemented, but in a castrated form. It’s almost as if Visual Studio tries too hard to make things easy to do, and in the process destroys a great deal of the flexibility which made Eclipse so pleasant to use.

    After using Visual Studio for a week or so, I gave up on it and have switched back to Eclipse and an open-source C# plugin which I found. The plugin offers syntax highlighting and not much else, so I’m essentially writing C# in a souped-up version of Notepad, but it’s still better than trying to make my way around VS. Maybe I just haven’t inculcated the Microsoft way of doing things yet, but I’ll take Eclipse and Java back any day. I’m sure Visual Studio is useful in many cases, but for writing automated tests against APIs it just stinks.

    Ward must feel the same way.

  • Pair Programming at SAS

    What is pair programming? PairProgramming.com defines it as:

    Two programmers working side-by-side, collaborating on the same design, algorithm, code or test. One programmer, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects and also thinks strategically about the direction of the work. On demand, the two programmers can brainstorm any challenging problem. Because the two programmers periodically switch roles, they work together as equals to develop software.

    Pair programming has traditionally been a practice of XP (eXtreme Programming). That doesn’t mean you have to do XP to pair program, however. Developers seem to fall into several camps on pair programming:

    • Some swear by it and feel naked when they’re not with a pair
    • Some are comfortable with it, but would prefer not to do it constantly
    • Some hate it with a vengeance and wouldn’t be caught near a pair

    Each camp has its own strengths and weaknesses, just like the practice of pair programming itself. My preference, though, falls somewhere between loving it and liking it. I don’t think constant pairing is either productive or enjoyable, but there are times when pairing can be quite beneficial.

    My formative years as a developer were spent in an XP studio which practiced pair programming 24/7. Being in such an environment taught me the value of collaborative development and good communication. Pair programming supports (one might even say forces) both of these goals.

    It goes without saying that moving from an XP shop to SAS was somewhat of a shock for me initially. I was used to a work environment in which all of the developers on a team shared a common work space. Now I was isolated, not in a lab or a cubicle, but in an office with a thick, heavy door!

    In my next post, I’ll discuss how I was able to work out getting a monitor splitter and a second monitor, keyboard, and mouse in my office and I’ll give some examples of how my fellow developers and I have used pair programming to our advantage on several recent development projects. Don’t touch that remote.

  • Innovation isn’t just about the future

    Wired News ran an article last month talking about the recent phenomenon of warez traders and illegal music downloaders flocking back to Usenet to ply their trade. I find this fascinating considering the number of “modern” file sharing applications like Kazaa and BitTorrent which are easily available. The article cited anonymity as the primary force behind the shift, but it also cited speed as a factor.

    Uh, excuse me. Speed? Usenet’s reputation as a sluggish maiasaur when it comes to file downloads is uncontested, right? Well, not exactly. A new XML-based open source technology called the NZB file is allowing pirates to search for and download files at rates faster than traditional peer-to-peer file sharing apps. Add to that the nifty fact that files uploaded to Usenet are always there (at least until they scroll off the list) and you see the benefit.

    What does this mean for us as software developers, though? Simply that no matter how old or antiquated a technology may seem to be, there is usually always a new, different, and better way to use it. The trick, of course, is finding it. The warez traders are motivated to innovate by their apparent addiction to circumventing the law. Where does our motivation come from?

    I suggest that our motivation shouldn’t come exclusively through the vehicle of exciting new technologies and methodologies, the latest craze, or the slickest new toolset. The technologies of today were built upon the achievements of the past. I suggest that we should also dedicate a portion of our time to examining what’s been done before, even if it may not be popular right now.

    There may be value hidden where we least expect to find it.

  • Automating mundane tasks with Expect

    Expect is a UNIX program based on the Tcl programming language. It allows for quick and easy automation of interaction with other programs. For example, Expect can be used to write a script which launches FTP, enters a password when prompted, navigates to a directory, downloads a file, and finally quits.

    My current development work requires me to login to a remote server quite frequently, launch a session of SAS, and execute a program to connect to an Oracle database. Prior to Expect, it took me 30 to 45 seconds to login. Now that I have the login and SAS startup processes automated via Expect, it takes mere seconds to do the same thing.

    Expect isn’t for everyone, but if you need to automate an interactive UNIX program it can be a lifesaver. Visit the Expect web site for more information, including a number of useful example scripts.