Ramblings of a software developer with a degree in bioinformatics. Agile development mixed with DNA sequencing - what could go wrong?
Saturday, July 02, 2005
Change is good
After 4 1/2 years, it's time for me to leave Interactive Intelligence. It's still a great company to work for, but I'm ready to move on and try some new things. In a couple of weeks, I'll start work at Pro-Solv, a medical imaging and reporting software company. I'll be looking forward to it!
Wednesday, June 29, 2005
Book review: Hat Full Of Sky, Terry Pratchett
Last year at this time I mentioned to Mr. Pratchett that I was ready for another of his youth books. It took him until now to deliver; at least the paperback version, which I paid my $7 for. (BTW, my book trading site is gone now. I don't think they managed to build a community. Social software post another day!) The further adventures of Tiffany Aching are available, and it's quite a good book. Tiffany, now 11, goes off her home land to be apprenticed to a witch, but unbeknownst to her she is being tracked by a mysterious being who wants to eat her soul!
Boy, that summary makes it sound kind of iffy, doesn't it? It really isn't. The Nac Mac Feegle are back and as feisty as ever, although I think their dialect is significantly easier to understand than in the earlier books. I'm guessing you can't make major characters out of folks no one can understand. Tiffany's interactions with the other apprentices are nicely done, and Granny Weatherwax is fascinating as the other characters now talk about her the way she once spoke of Black Aliss Demurrage. Tiffany's progress as a witch is brought forth nicely, and Rob Anybody really comes across as a personality rather than a caricature like most of the Mac Feegle.
The ending is a bit nicey-nice, which I suppose is appropriate for a book theoretically targeted at younger readers. To me it came across a bit like when one of the great villains of all time, Darth Vader, decided he was really a nice guy after all and was redeemed in a single swoop. C'mon now, bad folks are a lot more fun when they're bad, now aren't they? The Mac Feegle queen was a bit wishy-washy too, and I didn't really buy into her mood swings. Finally, the climax of the book takes place at something called the Witch Trials, which appears to be sort of a renaissance festival for witches. Odd, but again maybe appropriate for the younger reader.
And for all of that, it's classic Pratchett and you can't complain. Most comedy writers, take Piers Anthony or Douglas Adams, get steadily sillier as they reach the later books in a series and have to try to wring one more gag out of the same scenario. But the great ones, like Pratchett and Wodehouse, just keep on kicking out one or two new terrific stories every year. This is one of those. Read it.
Boy, that summary makes it sound kind of iffy, doesn't it? It really isn't. The Nac Mac Feegle are back and as feisty as ever, although I think their dialect is significantly easier to understand than in the earlier books. I'm guessing you can't make major characters out of folks no one can understand. Tiffany's interactions with the other apprentices are nicely done, and Granny Weatherwax is fascinating as the other characters now talk about her the way she once spoke of Black Aliss Demurrage. Tiffany's progress as a witch is brought forth nicely, and Rob Anybody really comes across as a personality rather than a caricature like most of the Mac Feegle.
The ending is a bit nicey-nice, which I suppose is appropriate for a book theoretically targeted at younger readers. To me it came across a bit like when one of the great villains of all time, Darth Vader, decided he was really a nice guy after all and was redeemed in a single swoop. C'mon now, bad folks are a lot more fun when they're bad, now aren't they? The Mac Feegle queen was a bit wishy-washy too, and I didn't really buy into her mood swings. Finally, the climax of the book takes place at something called the Witch Trials, which appears to be sort of a renaissance festival for witches. Odd, but again maybe appropriate for the younger reader.
And for all of that, it's classic Pratchett and you can't complain. Most comedy writers, take Piers Anthony or Douglas Adams, get steadily sillier as they reach the later books in a series and have to try to wring one more gag out of the same scenario. But the great ones, like Pratchett and Wodehouse, just keep on kicking out one or two new terrific stories every year. This is one of those. Read it.
Wednesday, June 22, 2005
Living in the blurbs
Doug Jonstone comments on blurbs. (link from the idiosyncratic mind.) I'm intrigued by the correspondences between old-fashioned marketing and blurbs. As Doug says,
when such effusive hyperbole declares everything "brilliant", "superb" and "amazing" it all ceases to mean anything
which is more or less the problem with marketing - that is, the lack of credibility of the source. Are you going to read a book because it says "A real tour de force!" on the back, or are you going to read it because your buddy says it's pretty good? I would be a lot more likely to read a book if it was making the rounds in the blogosphere than for any other reason. So I guess book publishers are another on the list of people who need to learn to make blogs work for them. I know there are a few publisher-bloggers - wonder how effectively they use them to push books?
when such effusive hyperbole declares everything "brilliant", "superb" and "amazing" it all ceases to mean anything
which is more or less the problem with marketing - that is, the lack of credibility of the source. Are you going to read a book because it says "A real tour de force!" on the back, or are you going to read it because your buddy says it's pretty good? I would be a lot more likely to read a book if it was making the rounds in the blogosphere than for any other reason. So I guess book publishers are another on the list of people who need to learn to make blogs work for them. I know there are a few publisher-bloggers - wonder how effectively they use them to push books?
JetBrains onBoard Online Magazine :: Language Oriented Programming: The Next Programming Paradigm
The Next Programming Paradigm? I suppose it could be. Personally I'm not even completely comfortable with Test Driven Development yet.
Wednesday, June 15, 2005
VBS week
Getting Vacation Bible School organized has been taking all my time this week - when I haven't been doing that I've been stress-reading crime novels. So I have about six books on my list of reviews to write, but I doubt I'll do anything before next Sunday, the closing ceremony. I've been getting up at 5 in order to get to Indianapolis, put in a full day's work, and drive back again by 5:15 so I can pick up kids who need rides. So I'm pretty beat :) After VBS is done I'm just not going to know what to do with all my free time!
Saturday, June 11, 2005
So you wanna be a programmer?
Hazygrin links to Joel saying he agrees that you should start learning programming at a level as close to the metal as possible, i.e., C. I disagree, and I suspect that generally the people who are in this camp are the people who learned C first. (I'm not one of those; I learned Pascal before C, although a one-credit course in college in C might have been the most valuable class I ever took, practically speaking.)
Joel's alternate suggestion is a straw man, of course. No, obviously learning HTML or copy-and-pasting Javascripts is not quite the ideal learning experience. But I see absolutely nothing holy about C as being just exactly the right level to learn at, and I firmly disagree that learning the technical details about why strings are hard to manage is important for a beginner. That may be the single reason that more people aren't interested in programming, which is a shame considering the myriad of good string implementations that are out there.
But if you must get fairly close to the machine, why not start with a managed language? Being able to move from Java or C# to byte code is going to get you a long way to understanding how your source code is translated to something the machine understands, without having to really bury yourself under a load of machine code manuals.
I would replace this recommendation with Stroustrup's The C++ Programming Language, 3rd edition, which replaces all the stuff about byte copying with good object-oriented design. Going all the way back to C is, to my mind, no more necessary to a programmer starting out today than a recipe for bread has to start with "Grind down enough wheat to produce three cups of flour..."
Joel's alternate suggestion is a straw man, of course. No, obviously learning HTML or copy-and-pasting Javascripts is not quite the ideal learning experience. But I see absolutely nothing holy about C as being just exactly the right level to learn at, and I firmly disagree that learning the technical details about why strings are hard to manage is important for a beginner. That may be the single reason that more people aren't interested in programming, which is a shame considering the myriad of good string implementations that are out there.
But if you must get fairly close to the machine, why not start with a managed language? Being able to move from Java or C# to byte code is going to get you a long way to understanding how your source code is translated to something the machine understands, without having to really bury yourself under a load of machine code manuals.
I would replace this recommendation with Stroustrup's The C++ Programming Language, 3rd edition, which replaces all the stuff about byte copying with good object-oriented design. Going all the way back to C is, to my mind, no more necessary to a programmer starting out today than a recipe for bread has to start with "Grind down enough wheat to produce three cups of flour..."
Sunday, June 05, 2005
Book review: A Great Deliverance, Elizabeth George
I bought this first-of-the-series based on a newspaper review of the last. I'm a big fan of Elizabeth Peters' Amelia Peabody novels, and from the article I thought that it might be a similar sort of book. I was pretty much, well, wrong. About the only similarity is that Amelia and Thomas Lynley are well-off and English. Nevertheless, a good read. Lynley and sidekick Barbara Havers, members of Scotland Yard, have been sent off to York to investigate a teenager found near her father's decapitated body. As they investigate the possibility that she was not the murderer, they both have to come to terms with their own pasts, which they see reflected among the many dysfunctional characters that wander across the stage: the obligatory horrible American tourists, the drunken artist in love with the older, lonely spinster, the family man with the nympho wife who use their fights as an excuse for making up. But the murdered man's family wins the prize for "most dysfunctional", as they seem to be in the habit of simply wandering off and never being heard from again. As Lynley and Havers put the pieces together, they come to a gruesome conclusion that is not at all suitable for the genteel reader of Elizabeth Peters!
Luckily, my stomach is a little stronger than that. But I don't think I'll put this one on my wife's reading list.
Luckily, my stomach is a little stronger than that. But I don't think I'll put this one on my wife's reading list.
Thursday, June 02, 2005
"It seems more complicated now"
A lot of programmers still believe in procedural programming even if they use an object-oriented language like C++ or C#. When you eliminate duplicate code, you can do it quite often by taking a big long procedure and replacing it with some objects. Consider this code:
for (i = 0; i<things.count; ++i)
{
Initialize( thing[i] );
}
for (i = 0; i<things.count; ++i)
{
Continue( thing[i] );
}
for (i = 0; i<things.count; ++i)
{
Finish( thing[i] );
}
There is clearly duplicate code here. Three times we run a loop over things. You can't just refactor all three calls into one loop, since the processing of the latter loops might depend on the first loop being finished.
So how do we remove the duplication? Let's create an abstract object, AThingProcessor, and use it to do all of the looping:
class AThingProcessor
{
void Run()
{
for (i = 0; i<things.count; ++i)
{
ProcessThing( thing[i] );
}
}
abstract void ProcessThing( thing t );
}
Now we can replace each loop with an instance of a class, for example:
class Initializor : AThingProcessor
{
virtual void ProcessThing( thing t )
{
Initialize(t);
}
}
And now the original code can be replaced with:
new Initializor().Run();
new Continuor().Run();
new Finisher().Run();
So what is the result? Our original code is now much more object-oriented and flexible. But without knowing the definitions of Initializor, Continuor, and Finisher, you don't know exactly what is happening here. The result is, some programmers will look at this code and say "It seems more complicated now". But it really isn't. It's just more object-oriented.
for (i = 0; i<things.count; ++i)
{
Initialize( thing[i] );
}
for (i = 0; i<things.count; ++i)
{
Continue( thing[i] );
}
for (i = 0; i<things.count; ++i)
{
Finish( thing[i] );
}
There is clearly duplicate code here. Three times we run a loop over things. You can't just refactor all three calls into one loop, since the processing of the latter loops might depend on the first loop being finished.
So how do we remove the duplication? Let's create an abstract object, AThingProcessor, and use it to do all of the looping:
class AThingProcessor
{
void Run()
{
for (i = 0; i<things.count; ++i)
{
ProcessThing( thing[i] );
}
}
abstract void ProcessThing( thing t );
}
Now we can replace each loop with an instance of a class, for example:
class Initializor : AThingProcessor
{
virtual void ProcessThing( thing t )
{
Initialize(t);
}
}
And now the original code can be replaced with:
new Initializor().Run();
new Continuor().Run();
new Finisher().Run();
So what is the result? Our original code is now much more object-oriented and flexible. But without knowing the definitions of Initializor, Continuor, and Finisher, you don't know exactly what is happening here. The result is, some programmers will look at this code and say "It seems more complicated now". But it really isn't. It's just more object-oriented.
Tuesday, May 31, 2005
SmugMug
Someone left a comment on my OurMedia post suggesting that I check out SmugMug. It seems like a nice enough site, but I wouldn't use it right now, for a few reasons - primarily, there is a huge commitment difference between a site that asks for a credit card and a site that doesn't. I have no idea how much time I want to spend on uploading photos in the next year; it could be hours or days, but it also could be minutes, so I don't want to lay out the cash up front. If I were them, I would offer either a free or advertising-supported basic site for simple users like me, with an opportunity to upgrade to their cooler features after they've hooked me in. My web hosting company, M6, has done this to me quite neatly - their basic package sells for $5 a month which I thought was pretty good for what was offered, so I signed up for a year. I'm sure I've put another $60 just in add-ons to what the original deal was though, and I'm already considering upping to their next service level.
Of course, the other reason I signed up with OurMedia is that Scoble told me about it first :)
Of course, the other reason I signed up with OurMedia is that Scoble told me about it first :)
Weekend family reunion
We drove from Bloomington to Penn State this weekend. I took Friday off work and drove two hours to my dad's house, piled into his van and drove four hours to Cleveland, picked up his sister and drove four hours to my cousin's house. Sort of a college road trip, with less beer and more three-year-old. But it was a good time, and there was a pretty good turnout for the "Descendants of Jesse Fulton". That's my grandfather who died a few years ago. If he'd been there, he would have seen all three of his kids, four grandkids, and four great-grandkids. Maybe he was there in spirit.
With all the driving, we didn't really have much time to visit. But we wandered around campus, and discovered that the reason there were no hotels was the big high school volleyball tournament that was going on. My brother is in theory deciding what college he's going to - in reality he'll be going to Indiana - but he gave PSU a thumbs-up as a solid backup choice. He was noncommital, though, as to the part played by all the volleyball players running around in that decision...
With all the driving, we didn't really have much time to visit. But we wandered around campus, and discovered that the reason there were no hotels was the big high school volleyball tournament that was going on. My brother is in theory deciding what college he's going to - in reality he'll be going to Indiana - but he gave PSU a thumbs-up as a solid backup choice. He was noncommital, though, as to the part played by all the volleyball players running around in that decision...
Getting Things Done
Mike Stall comments on how not to organize your mail. I recently read David Allen's Getting Things Done, after reading a recommendation for Take Back Your Life by Sally McGhee, visiting the Amazon site, and reading a review that said it was almost the same as GTD. I decided at that point to take the reviewer's advice and go to the original. It was definitely a good read, and I subscribed to the blog. The main thing I took away from the book about email organization was to keep your Inbox empty. The auther recommends creating three folders: Actions, To Read, and Reference. As you go through your Inbox, determine whether you can take care of the message in two minutes; if so, do it. Otherwise, move the message to the To Read folder if it is something you need to look at when you have time; move the message to the Reference folder if it's something you might need to check back with someday; and otherwise move it to the Actions folder.
This is a huge oversimplification of course, and the book recommends a few other tricks. I am deficient in that I don't carry a personal organizer of any kind, for example. But I'm slowly working towards full organization!
This is a huge oversimplification of course, and the book recommends a few other tricks. I am deficient in that I don't carry a personal organizer of any kind, for example. But I'm slowly working towards full organization!
Monday, May 23, 2005
ISO 9000 is good
If you use it correctly, ISO 9000 can be a positive thing for your software company. Here's the secret: Observe the procedure, don't dictate it.
There are two ways of looking at software development. Some people like to look at developers as artisans. They spend a lot of time on a single application, but when it's finished, it's like a really high-quality chair - it's really pretty to look at and works really well. Other people look at developers as assembly-line workers. They kick out a piece of software according to spec, and pass it on down the line to the next worker to glue in. This software is like a chair you can get at Wal-Mart - cheap and quick and does the job.
The truth, as is so often the case, lies in between, but there are a couple of undeniable facts: Not every software developer is an artisan that can make a really great chair. And even if they were, once the original developer moves on to something else, who knows what uses his chair will be put to? So whether or not software is craftmanship or assembly work, procedures are probably going to be necessary for making changes. And in the software world, if you're not making changes, you're dead.
The true raison d'etre for ISO 9000 is that processes can be improved. But you can't improve your process until you know what it is. So observe. Find out what your developers are doing, how they spend their time. (Ask them how it could be better, too. You won't always get a useful answer, but software developers are usually pretty darned opinionated and will have something to say.)
Now you know what your process is, you can document it, and you're most of the way there to your certification. And you'll be even further along once you document how you're going to accept suggestions for improving the process.
Once all that is done, you can change the process. You might see a lot of improvements in front of your nose, right after you write everything down. If your developers tell you they have to get 17 signatures in triplicate before they can issue a fix, you've got room for improvement.
But it all comes down to knowing the procedures. The easiest way to know them is to write them down. And once you have them written down, you're most of the way to your ISO 9000 certification.
There are two ways of looking at software development. Some people like to look at developers as artisans. They spend a lot of time on a single application, but when it's finished, it's like a really high-quality chair - it's really pretty to look at and works really well. Other people look at developers as assembly-line workers. They kick out a piece of software according to spec, and pass it on down the line to the next worker to glue in. This software is like a chair you can get at Wal-Mart - cheap and quick and does the job.
The truth, as is so often the case, lies in between, but there are a couple of undeniable facts: Not every software developer is an artisan that can make a really great chair. And even if they were, once the original developer moves on to something else, who knows what uses his chair will be put to? So whether or not software is craftmanship or assembly work, procedures are probably going to be necessary for making changes. And in the software world, if you're not making changes, you're dead.
The true raison d'etre for ISO 9000 is that processes can be improved. But you can't improve your process until you know what it is. So observe. Find out what your developers are doing, how they spend their time. (Ask them how it could be better, too. You won't always get a useful answer, but software developers are usually pretty darned opinionated and will have something to say.)
Now you know what your process is, you can document it, and you're most of the way there to your certification. And you'll be even further along once you document how you're going to accept suggestions for improving the process.
Once all that is done, you can change the process. You might see a lot of improvements in front of your nose, right after you write everything down. If your developers tell you they have to get 17 signatures in triplicate before they can issue a fix, you've got room for improvement.
But it all comes down to knowing the procedures. The easiest way to know them is to write them down. And once you have them written down, you're most of the way to your ISO 9000 certification.
Saturday, May 21, 2005
OurMedia
This looks to be a really interesting project. They claim that they will archive your digital media forever, basically. Sounds nice, but I registered and took a shot at uploading a few files. What I'm really looking for is an online photo album - just someplace that will store my pictures for me so I don't have to worry about archiving CD's or making sure hard drives are backed up. People who are interested in archiving have to worry about a lot of things like making sure their images are dated, sourced, and described, and I bet quite a few people are doing that and then having a hard drive go south and losing all their work. So before I got onto that part I wanted to be sure I had a good file archiving system, and this site looks like it could be that. What I found was that it was pretty difficult to upload a picture. I uploaded a snapshot of my son and I had to fill in my copyrights, image information, approximate size, resolution, and a lot of stuff like that. It's not a problem for an individual pic, but if I have a couple of hundred it starts to get old fast. The site seemed pretty slow, too, but that might have been my connection. So I guess my next area of research will be image collection formats :) Wonder how they'd deal with a ten-page TIFF if I uploaded it?
Friday, May 20, 2005
Coding principles
* Avoid duplicate code. Anywhere there is duplicate code there is the potential for bugs. Code must always be changed, and anytime you leave the same code in two places, you run the risk of changing it in once place and not in the other, thus introducing a bug. This is the value of Simplicity.
* Don't go too long without soliciting input. You need to get input from users, to make sure that the application is doing the right things. You need to get input from programmers, to make sure your design and architecture doesn't overlook flaws. These are the values of Communication and Feedback.
* Make changes when changes need to be made. Don't fall into the trap of avoiding making changes because "it might break something somewhere." Ideally, of course, you have enough unit tests running to verify that things don't break when you change code, or at least that if they do, you know it quickly. But once the code is so complicated you are afraid to make changes, you can't respond to customer input quickly enough to keep up with your competition. This is the value of Courage.
It's interesting that these principles feed off each other. If your code has Simplicity, you are more likely to have Courage to change, which allows you to respond to Feedback more quickly.
* Don't go too long without soliciting input. You need to get input from users, to make sure that the application is doing the right things. You need to get input from programmers, to make sure your design and architecture doesn't overlook flaws. These are the values of Communication and Feedback.
* Make changes when changes need to be made. Don't fall into the trap of avoiding making changes because "it might break something somewhere." Ideally, of course, you have enough unit tests running to verify that things don't break when you change code, or at least that if they do, you know it quickly. But once the code is so complicated you are afraid to make changes, you can't respond to customer input quickly enough to keep up with your competition. This is the value of Courage.
It's interesting that these principles feed off each other. If your code has Simplicity, you are more likely to have Courage to change, which allows you to respond to Feedback more quickly.
Sunday, May 15, 2005
One's virus grammar must be impeccable
Quote from this article in ComputerWorld: "Another recent variant, Sober.M, which surfaced back in April, deliberately used incorrect grammar within the subject line, thereby attempting to convince recipients that the e-mail wasn't a virus and make them more likely to open the infected attachment." Why on earth would people be more likely to assume that viruses have correct grammar? Since I tend to communicate primarily with intelligent people, seeing bad grammar in an email subject automatically makes it suspect in my book. But now I know better. If I ever write a virus, I'll be sure to have this in the body.
Terribly sorry to disturb you, old chap. Here's those jolly enticing pictures I told you about earlier. Just open the attachment and Bob's your uncle. Cheerio for now!
Will that help?
Terribly sorry to disturb you, old chap. Here's those jolly enticing pictures I told you about earlier. Just open the attachment and Bob's your uncle. Cheerio for now!
Will that help?
Thursday, May 12, 2005
Indy NDA and VS 2005 Beta
Went to the local .Net users group meeting tonight. They showed off some of the new features of VS 2005, including refactoring and unit testing - two of my particular interests, of course. I think if they become generally adopted I'll have to find some new cause to evangelize :)
The main thing that occurred to me during the presentation was how similar the refactoring support looked to Resharper, and how similar the testing stuff was to NUnit. I hope one or both of these companies is getting a cut. (I asked the presenter to compare VS and NUnit but he wasn't familiar enough with it to say.) The refactoring support for VB was pretty jazzy, though. They're also bringing back Edit and Continue, which everyone was grumpy about being left out of earlier versions. It's just one more tool to help people write bad code, IMO. Much better to write well-tested classes instead of changing a couple of lines on the fly for each run.
Another presenter showed off Master Page support for ASP.Net 2.0, which did look pretty nice. I'm still behind in the Web world, but luckily I wasn't one of the six people tonight who went home with no door prize - I picked up a new book on XHTML and CSS. Worlds enough and time!
The main thing that occurred to me during the presentation was how similar the refactoring support looked to Resharper, and how similar the testing stuff was to NUnit. I hope one or both of these companies is getting a cut. (I asked the presenter to compare VS and NUnit but he wasn't familiar enough with it to say.) The refactoring support for VB was pretty jazzy, though. They're also bringing back Edit and Continue, which everyone was grumpy about being left out of earlier versions. It's just one more tool to help people write bad code, IMO. Much better to write well-tested classes instead of changing a couple of lines on the fly for each run.
Another presenter showed off Master Page support for ASP.Net 2.0, which did look pretty nice. I'm still behind in the Web world, but luckily I wasn't one of the six people tonight who went home with no door prize - I picked up a new book on XHTML and CSS. Worlds enough and time!
Wednesday, May 11, 2005
Vacation Bible School
VBS is coming up quick! My responsibilities are getting things written and printed, and handling the closing ceremony. I've written up a letter to parents and a letter to kids, and a registration sheet. The closing ceremony will be a bit scary; I'm sure I can get a couple of kids to sing, and maybe a couple to read Bible verses. But I'm thinking there's going to be plenty of time to sing some hymns and take an offering and all that good stuff :) So I guess the question is - do I start a separate blog for it? I guess the answer has got to be yes - at the end of VBS I'll shut down the blog and copy all the entries to the church site. That should be fun!
Monday, May 09, 2005
Friday, May 06, 2005
ASP.NET
I'm taking the plunge into learning ASP.NET now. I have a couple of minor things I want to do for my first application: allow posting comments on the sermon at my church site, www.universitybaptistonline.org, and read scheduling information in from an XML file. The code for each of these items ought to be pretty simple, but I'm having trouble grasping the relationship between FrontPage, which the site is primarily written with, and ASPX. Like, I have a theme defined for the site in FrontPage, and it isn't being picked up by the ASPX pages. It appears that the only difference is a meta comment, and I added that to the ASPX, but it didn't make a difference as far as I can see. Also, I wonder if you can bounce the ASPX pages around to make the addresses consistent. Like, the page you get scheduling information from is http://www.universitybaptistonline.org/worship_schedule.htm now - note the navigation bar and the yellow styling - but in my .Net project the page would be http://www.universitybaptistonline.org/worshipschedule/webform1.aspx . No navbar, no styling, and an address that's rather more complicated. I suspect it's one of those things you just pick up with experience, and eventually I'll realize either that it's not working because something's wrong, or it's not working because there's no way to make it work. But I'd sure like to know the answer now.
Subscribe to:
Posts (Atom)