The Next Programming Paradigm? I suppose it could be. Personally I'm not even completely comfortable with Test Driven Development yet.
Ramblings of a software developer with a degree in bioinformatics. Agile development mixed with DNA sequencing - what could go wrong?
Wednesday, June 22, 2005
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.
Wednesday, May 04, 2005
Hitchhiker's Guide to the Galaxy radio show
Available online, very cool. Courtesy of Eric Gunnerson.
Monday, May 02, 2005
Book review: Getting Things Done, David Allen
I spent a few minutes before I started writing digging for the link. Doesn't it seem like anyone who makes a living as a consultant should have a blog? What a great way to get your personality across, and consultants are nothing without personality.
There was a book that came out a while ago about using Outlook as your primary organizing tool. I went to Amazon to read the reviews. Someone said that it was nothing more than "Getting Things Done" with a few tool-specific tricks. I thought at that point I should go read the original rather than the copy. I wasn't disappointed.
I wasn't knocked out of my socks either. It was a good book, and the principals seem straightforward, although to keep using the system sounds like a lot of work. For example, David recommends getting your workstation set up properly with file cabinets and in-boxes; I kept thinking to myself, yep, just as soon as I get a bigger house. But there was some useful stuff. He recommends an indirection from your Inbox, which is where everyone at my company lives, so I tried clearing out the whole Inbox to some alternate folders: "Action Items", "Read and Review", and a few others. I'm not sure how much the system will really help me, but I'm willing to give it a whirl for a while. I suppose I went into the book looking for a tie-in to XP - I figured I'd have my inbox on a set of 3x5 cards that I'd carry around with me. It does seem like you need to have some portable inbox, though, whether it's a Palm or a paper organizer, neither of which I have. Of course, my job requires just about zero travel anyway.
Anyway, my Inbox is empty now, and I have a list of things in my Actions folder, and another list of things in my Tasks, which hopefully I will remember to check every so often. So we'll see how it goes. Maybe it will revolutionize my life. Wouldn't that be nice?
There was a book that came out a while ago about using Outlook as your primary organizing tool. I went to Amazon to read the reviews. Someone said that it was nothing more than "Getting Things Done" with a few tool-specific tricks. I thought at that point I should go read the original rather than the copy. I wasn't disappointed.
I wasn't knocked out of my socks either. It was a good book, and the principals seem straightforward, although to keep using the system sounds like a lot of work. For example, David recommends getting your workstation set up properly with file cabinets and in-boxes; I kept thinking to myself, yep, just as soon as I get a bigger house. But there was some useful stuff. He recommends an indirection from your Inbox, which is where everyone at my company lives, so I tried clearing out the whole Inbox to some alternate folders: "Action Items", "Read and Review", and a few others. I'm not sure how much the system will really help me, but I'm willing to give it a whirl for a while. I suppose I went into the book looking for a tie-in to XP - I figured I'd have my inbox on a set of 3x5 cards that I'd carry around with me. It does seem like you need to have some portable inbox, though, whether it's a Palm or a paper organizer, neither of which I have. Of course, my job requires just about zero travel anyway.
Anyway, my Inbox is empty now, and I have a list of things in my Actions folder, and another list of things in my Tasks, which hopefully I will remember to check every so often. So we'll see how it goes. Maybe it will revolutionize my life. Wouldn't that be nice?
Friday, April 22, 2005
How to lose a web site
Here's some really good advice, with lots of real-life examples, on how not to create a web site.
#1. Don't choose a site that's a random sequence of letters
I was casting around for a web site last year for our church, something I'd never done before. I was doing publicity for Vacation Bible School at the time, so I thought I'd try ubcvbs.org, for University Baptist Church Vacation Bible School. It was available, which is probably not a surprise.
#2. Don't choose the first registrar that you come across
I typed that address into my browser, which of course told me, that address is not available, would you like to buy it? I clicked yes, and was sent to the default MSN registrar, some company in Australia, and they charged me $35 for the site. (Now I know that $8 or $10 is probably more reasonable.)
#3. Don't let the registration expire
When I figured out that I'd overpaid, I thought, Aha! I'll just let the domain expire from this registrar and buy it again later from somebody else. I did that, but found that the Australian company's policy was to keep their domains unavailable for 76 days. So I had to wait that long before I attempted to buy it again. Unfortunately, I got squatted on. Some company in India that specializes in buying domains that might have inbound links snapped it up before I could get to it, and now it advertises gravestones. A particularly ironic fate for a church site, I thought.
So, that site is gone. I bought a new one, http://www.universitybaptistonline.org/, which is a much cooler name anyway. I'll try not to make quite as many mistakes this time.
#1. Don't choose a site that's a random sequence of letters
I was casting around for a web site last year for our church, something I'd never done before. I was doing publicity for Vacation Bible School at the time, so I thought I'd try ubcvbs.org, for University Baptist Church Vacation Bible School. It was available, which is probably not a surprise.
#2. Don't choose the first registrar that you come across
I typed that address into my browser, which of course told me, that address is not available, would you like to buy it? I clicked yes, and was sent to the default MSN registrar, some company in Australia, and they charged me $35 for the site. (Now I know that $8 or $10 is probably more reasonable.)
#3. Don't let the registration expire
When I figured out that I'd overpaid, I thought, Aha! I'll just let the domain expire from this registrar and buy it again later from somebody else. I did that, but found that the Australian company's policy was to keep their domains unavailable for 76 days. So I had to wait that long before I attempted to buy it again. Unfortunately, I got squatted on. Some company in India that specializes in buying domains that might have inbound links snapped it up before I could get to it, and now it advertises gravestones. A particularly ironic fate for a church site, I thought.
So, that site is gone. I bought a new one, http://www.universitybaptistonline.org/, which is a much cooler name anyway. I'll try not to make quite as many mistakes this time.
Subscribe to:
Posts (Atom)