Category: Programming

  • NFJS in RTP this weekend

    Two acronyms in one title! How much wilder can it get?

    I’ll be attending the No Fluff, Just Stuff conference in RTP this coming weekend (June 9th, 10th, and 11th). I attended my first NFJS last year and it was a truly memorable experience. I’m seriously looking forward to attending again this year. Aside from being packed with great speakers, NFJS events are always a fantastic way to hobnob with fellow geeks. I mean, these folks are passionate about what they do. Who else would give up their weekends to go talk about computer software?

    If you read my blog, I’d love to chat with you in person. I can’t read minds, though, so if you see a guy with my name on his tag by all means walk up and introduce yourself! I’m not mean. Really, I’m not.

  • Excerpts from NFJS Anthology

    No Fluff, Just Stuff (NFJS for short) is a symposium / conference / geekfest that began touring a few years ago. This year, an NFJS Anthology containing articles from many of the top speakers is being published by the Prag Prog guys. A couple of sample articles have been published as free PDFs.

    The first article is by Stuart Halloway and covers how Spring uses Dependency Injection and Aspect Oriented Programming in a delightful marriage of DRY-bashing goodness.

    The second article is by Glenn Vanderburg and is called “Buried Treasure.” Why is the software development field going backwards? Glenn explains why in this excellent treatise on why old is not bad.

    I highly recommend reading both of these samplers because they contain a lot of useful information in their own right. Not having reviewed the entire Anthology yet I can’t vouch for the other articles, but given some of the names listed here (Eitan Suez, Venkat Subramaniam, Neal Ford, Jared Richardson) there probably isn’t much of a question over whether it’s good material or not!

  • The Dreyfus Model

    I’ve been reviewing an old PowerPoint slide deck I have from Andy Hunt’s “Refactoring Your Wetware” talk. One of the slides covers the Dreyfus Model of Skill Aquisition, something that Andy and Dave Thomas also discuss in their “Herding Racehorses, Racing Sheep” talk (which you can see when the No Fluff, Just Stuff conference comes to your town, by the way).

    The whole concept is just fascinating to me. The model is made up of several “layers” or levels of proficiency in a given skill:

    1. Beginner
    2. Advanced Beginner
    3. Competent
    4. Proficient
    5. Expert

    Each level represents a different pattern of behavior, a different way of thinking. A learner will perceive the world differently at each level. For example, at the “Beginner” level, the learner is preoccupied not necessarily with learning something, but with simply accomplishing a task. Compare that to an “Expect” learner, who relies on intuition, not reason, to accomplish his goals.

    Forcing an expert to fit into a rules-based structure designed for a beginner ultimately makes the expert less productive and even downright miserable. On the flip side, placing a beginner in the intuitive environment that an expert thrives in can render the beginner incapable of doing anything. Yet both of these actions occur continually in the corporate world. Why is that?

    I don’t have any good answers yet, but Dreyfus surfaces some fascinating ideas. For a more thorough explanation of the model, read this entry from Dave’s blog or Google for “dreyfus model.”

  • Krugle: The Search Engine for Software Developers

    I received my access code for the Krugle beta by e-mail last night. I immediately tried it out, of course. Here are my initial impressions.

    The goal of Krugle is to make it easy for software developers to search for technical articles and code samples. Let’s face it: Google is a fantastic search engine, but it’s sometimes difficult to locate good code samples with it. Krugle changes all of that by allowing visitors to search specifically for source code, not just across web pages, but within project files from sites like Sourceforge as well.

    After executing a code search, two panes open up on your screen. The left pane contains the source code you selected. The right pane shows other source code files in the same project. As you open new files, Krugle places them in tabs across the top of the page, very similar to Firefox. The difference is that Krugle uses Ajax goodness to drive its user-friendly interface. Searching with Krugle is a real treat.

    If you’re interested in trying Krugle for yourself, visit the web site to sign up for the beta. Alternately, you could just wait a few more months for the production version of the engine to be released. If Krugle proves as useful to other developers as it has to me, I would be expecting Google to aquire yet another search engine a few months after Krugle goes live.

  • dnrTV features Venkat on .NET Generics

    dnrTV’s March 9th episode featured Venkat Subramaniam giving an interactive demonstration of .NET Generics. The entire video tutorial is about an hour long. I thought it was quite useful. It’s fantastic being able to watch an expert in this area as he writes code and explains what he’s doing while he’s writing it. It’s almost as good as pair programming with a master developer.

    I may have to check out some of the other shows on dnrTV this week. .NET Gotchas and Databinding in .NET 2.0 in particular look like they would be interesting.

  • Ruby crashes the next Java User’s Group

    So what in the world is Ruby on Rails? Where does it make sense to use it? How do you get started developing with it? And why would I forsake the established Java community for the wild ravages of a “new” technology, and love every minute of it?

    The next Java User’s Group meeting will feature a talk by my friend and former co-worker, Nathaniel Talbott, on why he prefers Ruby on Rails over Java. It’s sure to be an educational (and controversial!) presentation. For more information, visit the JUG web site.

  • Restarting Windows services in C#

    It’s dead simple to restart a Windows service in C#. I’m a little shocked at how easy it is actually, given some of the other things I’ve found to be so ugly about the language.

    public void RestartService(string name)
{
    ServiceController service = new ServiceController(name);
    service.Stop();
    Thread.Sleep(2500);
    service.Start();
    Thread.Sleep(2500);
}

    You guessed it: “name” is the name of the service to restart. It must exactly match the actual service name or bad things will happen. I added the sleeps for good measure. They may or may not be needed depending on how responsive you want the service to be immediately after restarting.

    Now if only C# made it this easy to restart a UNIX process…

  • My Job Went to India

    My Job Went to India“You might not know it, but you’ve already lost your job.”

    Thus begins the back cover of Chad Fowler’s new book, My Job Went to India (And All I Got Was This Lousy Book). Hey, it caught my attention too! I recently finished tearing through Chad’s 185-page book and have to say that it was one of the best work-related reads I’ve had in quite a while. The writing was clear, chapter organization made sense, and the content was nothing short of phenomenal.

    Have you ever questioned how much value you’re bringing to your company? Have you ever wondered when… or if… the outsourcing will stop? Have you ever brainstormed about ways to make your existing job more secure? If you’re a typical American programmer, the answer to these questions is probably, “Yep, sure have.” If this is true for you, Chad’s book will answer many of the questions you have, and give you a radically different perspective on the outsourcing movement… a perspective that will change how you treat your job.

    This book is structured very much like the upcoming Practices of an Agile Developer. It’s split up into 52 bite-sized chunks of information that can be read in a matter of minutes. Each chunk, however, brings fresh ideas to bear on the problem of outsourcing and explains steps you can take today to ensure that you remain competitive in tomorrow’s job market.

    I found Part IV, “Marketing… Not Just For Suits,” to be especially relevant. As a developer, I have a tendency to consider personal marketing as being a useless exercise, when in fact it’s a vital part of participating in the software development community. Marketing isn’t just about advertising, as Chad explains in the book. It involves engaging the community. It’s about blogging, writing for magazines, contributing to open source projects, speaking at conferences, and mentoring co-workers. In short, thinking more about what you can give to the community than what you can get from it. When an employer can see that you love the art of software development so much that you’re willing to spend your own time on it, they’ll be impressed. As Chad writes, “If you’re not actively trying to make your mark, you’re probably not making it.”

    If you’ve ever worried about the coder next door (or on the other side of the world) who is threatening your job, this is the first book you should read. A wonderful side effect of the book is that it will encourage you to be more passionate about your work, and to strive to give 110% every single day.

  • The DMV and continuous integration

    My father recently had an experience which bitterly proves that minor details can have major consequences. Last week, his insurance company mistakenly reported to the DMV that the coverage on his auto had lapsed. The DMV responded by revoking his tags within the space of 48 hours (quite speedy for them). To resolve the matter, he had to take proof of insurance to a local DMV office (in someone else’s vehicle, of course).

    Here’s how the process went, in his own words:

    1. Go to the DMV office on Academy St.
    2. Find out they only do driver’s licenses there.
    3. Go to the DMV office at Walnut and US-1. Walk up to the desk.
    4. Find out that the FS-1 form the insurance company faxed me has an effective insurance date of 3/34/05 rather than 3/24/05. It’s not acceptable.
    5. Find a pay phone to call the insurance company for a corrected form. Seems I left my cell phone at home.
    6. Get the insurance company to fax the corrected form to the DMV office I’m standing outside of.
    7. Go back into the DMV office and finish the transaction.
    8. Walk out with my sticker, new registration, and the confidence that comes with obeying our state laws.

    Suprisingly, aside from the nuisance of having to physically go to a DMV office, most of the blame for the mistake lies with his insurance company. First, their computers reported him as uninsured, which was, of course, incorrect. Second, when proof of insurance was faxed to him, the date on it wasn’t just off by a day or two… the date wasn’t even valid!

    If we assume that the insurance company used a computer to generate the form (a safe assumption), this means that one of the following must be true:

    1. Their processing is so antiquated that they’re simply filling out word processor templates; the incorrect date was human error
    2. The software they’re using isn’t smart enough to catch invalid dates
    3. The software they’re using has a good, ol’ fashioned bug

    If #1, they really should consider upgrading their systems to minimize the impact of human error. If #2, they need to consider investing in a more sophisticated software package. In my book, date validation is a fairly important feature! If #3, they were either sold lousy software or their in-house development group needs to do a better job of testing.

    Minor details can have major consequences. The best way to ensure the integrity of minor details is to test them. The best way to test something is to always run tests. The best way to always run tests is to use a continuous integration system!

    Now if only someone at my father’s insurance company would read this…

  • Practices of an Agile Developer

    Practices of an Agile DeveloperI recently had the honor of reviewing the Pragmatic Programmers’ latest work of art, Venkat Subramaniam and Andy Hunt’s Practices of an Agile Developer. The book doesn’t ship until March 1st, but I would certainly consider adding it to my Amazon.com wish list now, especially if I were new to agile programming or wanted to promote agile practices within my team. It was refreshing to read such a concise, yet comprehensive overview of what agility is.

    The book covers all the major agile practices (and several of the not-so-major ones) including minimizing up-front design, being honest even when it hurts, practicing iterative development, writing tests, letting customers make business decisions, integrating continuously, and being a mentor. The focus is not on a single agile methodology like eXtreme Programming or Scrum, but on the practices common to all of these methodologies.

    One thing I really liked about this book was that it was split up into 2 to 3 page “chunks” of information. (If you’ve read Chad Fowler’s My Job Went to India, you’ll know what I’m talking about.) Such “iterative” writing makes it much easier for busy geeks to digest. I’m not forced to maintain an excessive amount of context between reads.

    Another thing I liked about this book was that it wasn’t dogmatic in its approach to agility. While reading, I didn’t feel that the practices were being crammed down my throat. Venkat and Andy did a good job of espousing the benefits of the practices without becoming preachy. This is an exceptionally good thing considering how difficult it can be to explain to “traditionalists” that agility can actually help, not hinder, the craft of software development.

    Venkat and Andy’s creativity really shows with their “angel and demon” motif which is used throughout the book. At the beginning of each section, a demon tells you what the typical response to a common software development problem is. At the end of the section, an angel gives you a brief overview of the agile practice which was covered and why it’s so much better than what the demon tempted you to do.

    If you’re new to agile development and want a good overview of what it’s all about, I highly recommend this book. If you’re an experienced agile developer and want a handy dictionary of common practices to refer to or push into the hands of a fellow developer who comes knocking, I highly recommend this book. If you’re fed up with the way software development is done and want to know some practical steps you can take today to begin programming more intelligently, I highly recommend this book.

    Most importantly, if you’re passionate about creating software and want to be encouraged to continue striving for excellence in everything that relates to it, this book will give you the boost you need.