Heal Your Church WebSite

Teaching, rebuking, correcting & training in righteous web design.

Comments and Clarifications 1 of … many to come

I love the HYCW regulars … even those of you who lurk and are reluctant to leave a comment for fear of me returning the favor with a “thorough usability analysis” of your church’s website. First, let me reassure you, unless you are a slathering troll who abuses comments with ad hominem attacks on myself or others … or even worse … use my comments to spamvertise … then I’m not going to “publicly knit-pick” your site without you first asking me to … or without me first contacting you.

Moreover, you’ll notice, I have a category based upon Luke 6:42 … that is, being human, we do from time to time need to make sure I practice what I preach, and to correct those few times I get something not exactly right. So with that in mind, I’d like to respond to some recent comments:

In response to my post “So Many Free Web Hosts, so Little Time!Stephen Galliver writes:

I have been reading this blog for quite some time, and appreciate the time and effort that Dean takes to share his hard-earned experience with us. I am currently working on a redesign of our church’s website, which I inherited from our previous webservant [1]. I wish to offer my two cents regarding free webhosts:

1) I see little reason to sign up for a free webhost simply to create a development website. Assuming your current webhost supports what I am about to suggest (and that may be a big if, but a reseller account should do so), create a subdomain to house your development site. For example, if I manage the website at www.example.org, I would create beta.example.org, which would serve files from a directory separate from that which serves the production site. The development site can then take advantage of libraries and modules you have loaded for the production site.

2) free services are worth about what you pay for them. Don’t put mission-critical files on a free service, since it — and your files — could disappear without warning. I would be especially reluctant to put sensitive information, such as membership data you might store in a database, onto a free service, even in a back-up or mirrored capacity. And if any of your scripts contain passwords, for goodness sake, make sure the development passwords are different than the production passwords (a good practice even if you don’t use a free webhost).

That’s about it. I hope I haven’t overstepped my bounds in posting such a long comment.

– sdg

[1] The website was “state of the art” in 1998, but much has changed since then. Fortunately, my predecessor had the good taste not to include any “Jesus junk”. Still, it breaks many of today’s design rules, so it’s time for a remake.

I love this comment, and am grateful for it … and on a personal note to Stephen … no, you have NOT overstepped any boundary, in fact, it is comments like yours that make this techblog a joy for me, and informative for others. That said (sound of other shoe dropping)… I have the advantage of remembering pretty much everything I wrote … which includes an article posted September 22, 2002 entitled “Free Web Hosting Ain’t Cheap.” Which not only corroborates much of Stephen’s point #2, but offers a few more we may not have considered.

So I guess the question is, am I a hypocrite, or have I had a change in heart? No, I still insist that for your PRODUCTION web site, that you get real. After all, nothing distracts from the compelling content of your church web site like a pop-up ad for viagra.

This gets to Stephen’s point #1 … which I disagree with based on a tenant I’ve heard preached over my 20 years of programming experience … a rule which reads “If at all possible, don’t develop on a production machine.” This commandment is preached and practiced by programmers world-wide because it is just easy to destroy, cripple or impact the production site with pollution from the development. And this is what I was trying to get at in the context of my recent post about free sites. Why consume bandwidth, resources and potentially harm existing data because you’re curious about a new content manglement system or are playing with Python?

That and I’ve developed on too many “for pay” web hosts who’s backups aren’t what they should be. In other words, whether you develop on paid hosting or not, you need to take the appropriate steps to backup your data to a local machine/host to preempt disaster … or as I’ve preached in the past … those who fail to plan, plan to fail. In other words, yes, I agree, you get what you pay for … sometimes less … especially when it comes to inexpensive web hosts.

It is this very situation, that is the separation of development and production and the unreliability of both free and for-pay hosts, that I have in the past brought to your attention cool server or server-like tools such as Sokkit, Knoppix and other fun stuff such as the Home Web Server Project. That said, in those situations where such solutions are impossible or unfeasible, I think Stephen’s recommendation to create a subdomain makes for a very feasible and possible alternative. It is in fact how I’ve developed some test sites in the past.

Anyway, I wanted to bring Stephen’s comment to the forefront because I think he established the perfect model for a contrary opinion … one delivered with intelligently, respectfully and in Christian love. And while we may disagree, I hope I’ve returned his comments with the same respect and thoughtfullness. If not … you guys know what to do …


  1. Wow! I never expected to make the front page! :-)

    Dean makes a valid and very important point about taking care not to fubar your production server while messing around with a development website. There were two things I neglected to mention in my previous comment:

    1) Most of my webhosting experience is with shared hosting, so I assume (or hope) that users are prevented from adversely impacting each other or the server. Still, as Dean pointed out, it’s a good idea to keep your own backups and not rely on anyone (even for-pay webhosts) to safe-guard your website and/or data for you.

    2) The subdomain strategy works best to conduct usability studies and get feedback from your power-users regarding a new design, while keeping your current site unchanged. I agree that serious developing is definitely best done locally and offline.

    Of course, there is a flip-side to keeping development and production on separate servers: a) make sure you don’t do anything special to the development server that you can’t replicate on the production server (which might be the case in a shared hosting environment), and b) make sure that your development and production environments are similar enough that you don’t end up greying your hair when it’s time to go live, as I learned the hard way earlier this year when I tried to move a PHP/MySQL website from Mac OS X (development) to Debian (production).

    – sdg

    P.S. A show of hands, how many people checked out beta.cochranchapel.org? :-) Sorry, nothing there yet.

    P.P.S. Dean, you are more than welcome to conduct a “thorough usability analysis” of our beta website once I actually get it to the beta stage. Then we will discover just how good a student I am…

  2. Howdy… I happened upon this blog and wanted to respond to the comments made about free web hosts.

    Webs 4 Christ provides free web hosting for Christian Churches & ministries ONLY…these free accounts are hosted on the same servers and receive the same support as our paying clients. We are a ministry spin-off of a small company who has been in the Internet and on-line arena since 1990, so we aren’t going anywhere. And though we do require free hosting accounts to have a Webs 4 Christ logo and link on their pages, we do NOT have pop-ups.

    While I agree that a lot of free hosts come and go and you DO get what you pay for (we only give 20 mb with our free accounts, but do give MySQL, etc.), not every host is like that. Over 75% of our clients get free hosting or web design or both. We are not in it for the profit…LOL…there is none… Why do we offer free hosting? Because we are a technology ministry. It’s our way of serving those who serve the Lord.

    So please don’t judge ALL free hosting services by the few you have personal experience with.