Recently a client came to me with a small project: a single new page on her site, password protected to keep out casual browsers and search engines, but not requiring a high degree of security.

When I’m very busy, as I am now, I occasionally subcontract to other American-based freelancers with whom I’ve worked closely and whom I trust to produce excellent work. Because this project was in a language I rarely work in, I decided the most efficient use of the client’s money would be to subcontract to someone with more experience in that language. I reached out to some contacts and was put in touch with someone who received enthusiastic recommendations.

Not realizing that this individual (who will remain nameless) actually ran an outsourcing firm, I sent him some instructions; the page was presented to me the next morning.

To someone not closely familiar with web technology, it might have looked perfect. You input the password. If it was incorrect, you received a warning and nothing happened. If it was correct, you were redirected to the actual page.

However, there were two major flaws in the implementation that suggested that the requirements — or the reasoning behind them — had not been understood:

1. Use of Javascript

The password verification was implemented entirely in Javascript — I recognized this immediately from the alert box that appeared when an incorrect password was input. The problem with this is that it is entirely client-side: i.e. performed in the user’s browser. A user could simply “view source” for the page to retrieve both the password and the URL of the destination page.

2. The destination page was not password protected

That is, if you visited the URL of the destination page without first going through the password page, there was no validation performed — it could be accessed without a password. This defeated both of the purposes of the password protection: the URL could be shared among users, and if a user were to put a link from another website to the page, it could be picked up by search engines.

I sent the project back to the subcontractor, explaining my disappointment with the use of client-side authentication. He agreed to have the flaws corrected, and it was at this point that I learned that he was outsourcing overseas.

When the “corrected” page was returned to me the next morning, the password authentication had indeed been moved server-side (meaning that a casual user could not retrieve the password or destination URL); but the two-page structure that permitted unauthenticated access to the destination page had not been corrected (the correct behavior would have been to use a “cookie” to create a “session” identifying the user, and to refuse to present the destination page if the session did not indicate that the user had entered the password).

Finally, disappointed, I decided to implement the page myself, and will not charge the client for the time spent by the subcontractor. Lesson learned: be certain in advance whether the subcontractor I’m hiring outsources. I could have saved myself some time and money if I had known this — I might have hired someone else, or at the very least would have been much more specific in my instructions (overseas developers will typically implement whatever takes the least thought to meet the instructions given, so you must give them very explicit instructions.)

The same caveats apply to anyone hiring for web development. If you are considering hiring an outsourcing company rather than an American-based agency or freelancer, be certain that you have someone in house with the technical savvy to both a) communicate very detailed instructions to the outsourcer, and b) evaluate the resulting product for technical flaws and adherence to specifications.

In the end, please consider hiring your friendly neighborhood freelancer, who will make the effort to understand the problem you are trying to solve; will be able to offer suggestions as to alternate and possibly more efficient solutions; and will consider it a point of pride to solve it correctly.

Development Host

For the client projects and a whole bunch of other useful functions, I’ll be using Dreamhost. Dreamhost provides what for most people’s purposes works out to unlimited space and data transfer for a very low monthly cost. Lots of space is extremely useful to have when staging multiple sites, but it’s not generally a good formula for reliability (and indeed, in my experience, Dreamhost’s servers are very slow for dynamic sites, with comparatively poor uptime), which is why I’ll be keeping my public web presence elsewhere, as I’ll describe below.

Dreamhost is by no means the only host out there offering absurd amounts of space and bandwidth for an absurdly low price, but they have other advantages over the rest of the “massively overselling” hosts, which made this a very easy choice.

For one thing, they’re reputable. They’ve been around for 10 years, and I’m pretty darn confident that they’ll neither take my money and run, nor collapse into bankruptcy tomorrow.

For another, they offer a whole lot of features besides the space and bandwidth. The most important to me as a developer are:

• Shell access
• A Subversion (SVN) repository for version control (this makes it extremely easy to synchronize one’s work across multiple computers — e.g. host, laptop, desktop — and to roll back changes if one makes a mistake)
• Support for Ruby on Rails and Django
• Sandboxed hosts and FTP accounts (i.e. I can create staging sites with completely independent user logins and root directories, and separate FTP drop-boxes for each client)
• The ability to remap directories between the filesystem and web server
• The ability to choose PHP 4 or 5 on a per-domain basis
• Unlimited domains and subdomains
• Direct access to update DNS
• Database access from outside the network
• Cron jobs
• A very powerful control panel

My Web Presence

I need my own public-facing site to load quickly and be up as close to “always” as possible. As I’ve mentioned, Dreamhost’s servers aren’t the world’s snappiest or most reliable, especially for dynamic sites. Worse, their support is not particularly responsive. So the plan is to host my main site elsewhere.

I’ve had experience with a number of pretty decent hosts over the past few years. While my inclination is to lean towards the slightly more expensive hosts, with somewhat better uptime and support (there are exceptions, but in hosting you often do get what you pay for), I’m on a pretty strict budget.

My hosting requirements are pretty simple, and very straightforward: around 500MB of space and 10GB bandwidth; PHP/MySQL (preferably PHP 5); email; cron jobs; at least two domains (preferably more); good support; great uptime and performance. More features would be great, but aren’t necessary.

I’ve narrowed down the field to three candidates for the moment Verve Hosting, Fluid Hosting, and A Small Orange. Each of these has a pretty inexpensive hosting package that meets my needs. I currently have personal domains hosted with Verve and Fluid, and I’m very happy with both. I’ve also used ASO for a client site in the past. Here’s my take on the pros and cons of each:

Verve Hosting

I am very fond of Verve, and have hosted with them for around 5 years now. They’re my first personal host, and have hosted friends’ sites and an online community that I’m active in. As far as I can tell, they’re a very small operation, possibly even a one-woman show (and although I would never choose a host based solely on such a criterion, I do feel a sort of solidarity with any woman involved in a technical, male-dominated field). Support is very personal and very responsive, and they’ve saved my butt on a couple of occasions when I’ve done supremely stupid things like asking them to delete my account because the domain the invoice mentioned an old domain. They are, however, a basic cPanel host, with no additional services as far as I can tell.

Pro:

Good support; fast-enough servers; 5 domains, with unlimited subdomains and parked domains; already have one of my domains there, which helps minimize setup effort

Con:

CPanel control panel (user-friendly for less technical types, but I find it a bit limiting); no shell access; no information on site about software versions; uptime has occasionally been spotty (although generally good)

Fluid Hosting

Fluid is a very professional outfit with a long history in the industry and a great reputation, with a slightly more businessy target audience, as far as I can tell. When I was at Sanky, we moved several of our clients there and were very pleased with the service. Their servers and network are extremely zippy, and support is very good. On the other hand, they very strictly limit server access, which is great from a security standpoint but a potential pain in the rear for a developer.

Pro:

Excellent support (includes phone support option); extremely fast servers for dynamic sites; H-Sphere control panel (more capable than cPanel and with a much better layout for virtual host document root directories); shell access can be had; take security seriously

Con:

Require a justification for shell access; PHP 4 only; only two domains on the account level I’m considering; access from outside network severely limited

A Small Orange

ASO has also been around for several years at this point, and generally has a positive reputation. Sanky had a client hosted with them briefly. That did not work out particularly well, but I hear so much more positive than negative about them that it may just have been bad luck. I’m under the impression that they’ve grown fairly quickly, but the founder is still involved in a somewhat hands-on capacity, and they have a sort of “family” feel, and an excellent user community.

Pro:

Good support; unlimited domains; shell access available upon request; support for SVN, Ruby on Rails, and Django; excellent user community with tutorials on setting up various services; PHP 5 available

Con:

CPanel; spotty performance and uptime in previous experience (granted, a very small sample)

Conclusion

You know, the word “conclusion” makes me feel like I’m typing up an 8th grade lab report, but anyway… right now, the balance seems to be tipping towards ASO, knowing that if performance isn’t up to my standards, I have a couple of alternatives available.

I very recently left my job at Sanky Communications to pursue a career as a freelance web developer.

I have to say that I learned a lot in my time at Sanky, and I already miss the people there. The organization does a lot of great projects for some really wonderful non-profit clients, and I’m especially proud of some of the projects we launched towards the end of my time there (I’m not certain whether Sanky’s agreements with the clients allow me to mention them specifically — something to ask them about, I suppose). In the end, I was simply ready for a new challenge — working more hands-on and on a greater variety of projects.

In any case, I’m really looking forward to this as a brave new adventure and a chance to work on some different types of projects, develop new skills, and maybe work a bit more on the cutting edge of web development. I’m also going to try to set aside some time for some fun side projects. Oh, and maybe even slap a real design on this blog!

I’m taking a couple weeks off to relax a bit and pull everything together. There’s going to be a lot of annoying administrative details to take care of before I really get going. It’s surprising in a way that there’s no good central resource out ther for freelancers who need things like contract templates, time tracking and invoicing software, contact management and financial solutions, etc. I’ll probably end up writing about a few of those in this blog. In the meantime, any suggestions are appreciated!