What is ChatSnapper?

ChatSnapper lets you view ChatRoulette in a dedicated window and use the Apple+S command (aka, “Save”) to save a screenshot to your computer. It will save to your ~/Desktop in the most coarse fashion you can imagine.

Next up: image upload (waiting on a YFrog API key), tweeting of links, save preferences, etc. Also, an icon and Sparkle support.

Download

Get the alpha/preview/whatever here: ChatSnapper-alpha.zip

No warranties, people. Troll at your own discretion and sue yourself if something goes wrong. This is the sum total of about 2 hours of work (while watching Olympic snowboarding), so ignore the rough edges.

Though not a new phenomenon, we think we have a solution.

If pressing a lit elevator button were to cancel the call and simply send the machine to the nearest floor in the current direction, there would be a penalty to pressing it more than once.

The interesting thing about this idea is that it need not be universal. Instead, elevator designers could follow the lead of Jeremy Bentham and create a panopticon-style system in which some small portion of elevators operate this way. It only takes the fear of looking like an idiot to regulate behavior (most of the time).

ChatRoulette Weirdos

As ChatRoulette takes off, it’s becoming plagued by pervs flashing their junk or otherwise being slimy. It’s certainly expected, as the anonymity provided by the web brings out that side of people. It’s just a fact of life on the Internet: if there is an opportunity for a guy to flash his weiner anonymously, he will.

And that’s fine. It’s the way of the world. It’s the way of the web.

But so, my friends, is community moderation.

Enter ChatSnapper

Let’s try an experiment.

1. Follow @ChatSnapper on Twitter.
2. DM or @reply to @ChatSnapper with a link to a screenshot from ChatRoulette (or other online chats) showing offensive (or just weird) behavior.
3. Check posted links and help shine a light on the offenders.

Let’s see if the existence of a rogues’ gallery has any effect on the actions of folks.

If this works, I’ll start calling elevator companies.

ADDENDUM

Alex Bisceglie alerted me to a similar effort: ChatRoulette Cock Map. It includes an app that can track the IP of offenders as well.

The very moment that Alex sent that, I was working on a WebKit browser with screencap and yfrog upload. For now, grab a build at: ChatSnapper – Alpha.

Check it out: Cartilage.

Add it to your Monk set up with the monk command.

monk add cartilage git://github.com/tobyjoe/cartilage.git

Once it’s added, create a new project with the monk init command.

monk init --skeleton=cartilage myapp

Once that is done, freeze all the dependencies.

dep vendor --all

Easy as pie, right?

Contributions

I want to add optional memcached support to both Cartilage and Lazybones.

If you see anything wonky, fork it and let me know, or just leave a comment or file an issue at the GitHub issue tracker.

Cartilage is based on the original skeleton that ships with Monk, by the way.

You can find the project over at GitHub.

Check it out: Lazybones.

Add it to your Monk set up with the monk command.

monk add lazybones git://github.com/tobyjoe/lazybones.git

Once it’s added, create a new project with the monk init command.

monk init --skeleton=lazybones myapp

Once that is done, freeze all the dependencies.

dep vendor --all

Easy as pie, right?

Contributions

I am working on skeletons for Postgres and MySQL as well, and adding optional memcached support to all of them.

If you see anything wonky, fork it and let me know, or just leave a comment or file an issue at the GitHub issue tracker.

It’s based on the original skeleton that ships with Monk, by the way.

Yes, creating cross-browser experiences can be painful when support for Internet Explorer 6 (IE6) is required. There are dozens of hacks to get around certain issues, and it is possible to design experiences that are functionally identical on IE6 and more modern browsers. It may mean designers don’t have carte blanche, but that should be fine if their companies or clients mandate full IE6 support. Any good experience designer can work within constraints and still kick ass.

Still, a lot of folks are lobbying their companies, clients, and partners to drop support for IE 6.

My issue is how they’re doing it. The more dickish folks are throwing up an insulting roadblock, patronizing IE 6 users.

A more practical approach is to encourage users to upgrade with prominent, consistent notices. This angle isn’t terrible, but still alienates users and disrupts the experience for those users almost as much as a modified or “broken” IE6 experience. It’s just not friendly, or consistent with the brand message that usually mandates an identical UI across target browsers.

Another Option: Boring but Practical

My suggestion is to take this to the contracts. Redefine the word “support” as it applies to user agents (like browsers). Look at the cost/benefit of all types of support for all types of user agents. This should be a part of your business modeling.

Instead of refusing content to IE6 users or breaking brand guidelines by disrupting their experience with a patronizing notice, why not relegate them into a tier of Content-Level Support as opposed to Design Support?

Good sites already do this with a stylesheet for print: we don’t penalize printers for their lack of a good box model. The same is true of screen readers and most RSS readers. Maybe you can think of IE6 as a perfectly viable user agent for consuming content, but cost prohibitive for rendering top-tier experience design. Serve your print styles to IE6 if you don’t want to offer design support. Or serve a basic white-on-black stylesheet. Or no stylesheet. Pretend IE6 is the Googlebot or JAWS or any other non-graphical user agent. Just don’t punish people or talk down to them.

Channel Your Frustration Properly

You don’t have to be a dick to your less-endowed users. Shift them, officially, to a tier you, your clients, your company, and your partners agree upon and move on. Just make sure you’ve built an economic model that includes the IE6 users and estimates the cost of all possible decisions. Look at the realities of IE6 users of Digg to understand the complexities facing the people your cocky designers and lazy developers want to patronize or abandon.

Justify relegating IE6 with real numbers or choose to give it design support and force your designers to work within the constraints. They do get paid to work, after all. If they can’t create great experience design that doesn’t fuck over the people coding those experiences, fire them. Hire designers who understand browsers.

No matter what you do, keep your users’ needs first. They’re the ones you can’t replace.

A Great Resource

A few months back, I started up a GitHub project to create a baseline CSS file for all legacy browsers. Around the time I got contributions from folks at work, I found out about similar (but completed) projects out in the wild. One such project can be found here: http://code.google.com/p/universal-ie6-css/.

Generally, the presence of brands and their representatives on social sites is well-tolerated. Everyone is used to the fact that brands are jumping in. We consumers have large, high-res displays and we’re great at building selective blindness. When brands participate in social media, though, we don’t necessarily need that blindness. They’re automatically invisible unless we want to see them.

The Honeypot

A honeypot is an attractive trap used to embargo a threat. In information security, a dummy server might be placed on the periphery of a network and left somewhat hackable. The dumber crooks break into the honeypot, thinking they’ve silently compromised a network, only to be kept at arm’s length and watched. A thriving, sensitive network might exist right behind the honeypot, but the attacker never knows. He’s satisfied with himself for breaking in and stealing (what he thinks are) the keys to the castle.

On social sites, we only engage with brands if and when we want to. We don’t bother following @zappos if we don’t want to interact with Zappos. The model keeps the power dynamic shifted the way it should be: in the favor of the consumer.

In a way, a brand presence on Twitter is the antithesis of display advertising. Rather than covering every visible surface in a shotgun effort to sneak into the minds of consumers, social media advertising is more passive.

Twitter and Facebook are honeypots for brands, keeping consumers protected from the annoying noise we see everywhere else. We reach in and pull them out when we want, but otherwise keep them at bay.

Twitter is better at this role than Facebook because Twitter lacks display ads. I think that fact alone makes us love Twitter, where we simply tolerate Facebook.

An Olive Branch

So, to brands, I say, welcome. Don’t screw it up, and don’t speak unless you’re spoken to. You’re not “going where the conversation is happening” – you’re going where people are, and letting them talk to you if, when, and how they prefer. Play by the rules and you will, over time, build a community. You’ll earn a voice. Just don’t be insulted if we tune in and out at will. It’s better for all involved.

An Example

Ok, so R/GA is about to bring Taco Bell all up in our grills on Facebook and Twitter. God save us from the chalupa and volcano nachos.

Luckily, I can opt out by not opting in. We all can.

It feels good, doesn’t it?

Strategists everywhere are pushing companies to add APIs to their online properties. Job postings for web developers and architects invariably require experience working with and developing APIs. It comes up in sales meetings, pitches, and casual conversations with industry folks all the time. I’m often left wondering if the term “API” has lost its real meaning and become sort of a stand-in for a handful of fuzzy concepts.

REST APIs are Buzzworthy

In the API chatter, there’s a huge focus on RESTful APIs. Everyone wants a RESTful API. Web developers love REST architectures because the fixed semantics and stateless mapping of resources to URIs lowers the barrier to entry for integration tasks. Devs no longer have to struggle to understand proprietary architectural touches. No WSDL files need to be parsed. No expensive, scale-resistant state-managing caches need to be added. The URI we use in the browser is the same URI our apps use to read JSON or XML, etc. It’s a glorious thing, REST. I absolutely love the style, and preach the benefits to clients whenever possible.

Another thing I peach, when I can, sounds scandalous at first. That message: If you’re adding a REST API to your site, you’re probably doing something wrong. Maybe.

REST APIs are Everywhere. Right?

All the big sites are exposing REST APIs. Twitter has on. Flickr has one. Netflix. Microsoft SharePoint. Everyone, man. Everyone.

But how many are as RESTful as they could be?

If you see the value in a REST API, the last thing you want to do is create something separate from your “main” site or service. Your site is your “API” if you’re being RESTful. If you force a separation or bolt on a separate chunk of URIs meant for API clients you’re probably wasting resources and muddying your domain.

With REST, you should have a distinct, stateless URI for each conceptual resource you provide and should respond to the appropriate HTTP verbs (most commonly, GET, PUT, POST, DELETE, HEAD, TRACE, and OPTIONS).

For example, if you have the concept of a user profile for someone named “TobyJoe” you should have a single URI that represents that profile and that URI should serve any supported format a client application requests. It doesn’t matter what the URI looks like, but there should only be one way of accessing that conceptual resource. You can serve up XML, JSON, HTML, plain text, SVG, or any combination of formats you want. HTTP and the REST style already accommodate for this using certain HTTP request headers. This problem has been solved since the Web existed (basically). And yet, we see a lot of big sites offering two distinct sets of URIs: one for their “site” traffic and one for their “API” traffic.

Really, it shouldn’t matter if someone is requesting the resource at a URI from Safari, Tweetie, cURL, a Flash RIA, or any other HTTP client. The REST style can cover all the content switching and access management you need and you can have a single set of URIs, a single set of semantics, a single engineering team, and a single set of resources to support. The user experience for your third-party development partners will be improved as well.

Twitter: An Easy Example

So why are there two URIs for my Twitter status feed? One for the Twitter-branded HTML (with great microformat support!) at http://twitter.com/tobyjoe and one for XML at http://twitter.com/statuses/user_timeline/tobyjoe.xml?

It’s the same data, in different formats. It’s the same concept: status messages for tobyjoe. Most of the formats Twitter supports are available at the http://twitter.com/statuses/user_timeline/tobyjoe.{EXTENSION} address. Why not the HTML version with the sweet microformats?

Note: I’m sure Twitter has many reasons for this separation. Legacy clients, their ever-changing architecture and unprecedented growth, organizational investment in this style. They have an amazing team over there. I’m only using Twitter as an example because so many developers are familiar with their API.

Still, as both a user and client developer, I’d prefer to see a single URI (or at least one URI template) for each conceptual resource rather than one URI for “people” and one URI template for “machines”.

It’s Not Always That Easy

I know that there are lots of hurdles with development around live products. I don’t discount the operational challenges. I don’t necessarily chastise folks who stray from REST. I would love to see the concept of the RESTful API default to a slightly different meaning that what I see on the web today. Instead of saying, “We are going to add a REST API to our site!” I’d love to see companies say, “We are expanding the choice of representation formats and verbs for some of our URLs!” Not as sexy sounding, but way sexier.

near ")": syntax error

Check to see if you have any models declaring themselves as DataMapper::Resource but WITHOUT any property declarations.

No meaningful error is reported for this case at the moment (with HEAD as of last night) so it’s a weird one to debug – especially if you generate a bunch of model classes ahead of defining their behavior.

I understand the irony of complaining impotently about an impotent complainer, naturally. Hey, that’s what blogs are for, right?

Please, dear God, let Frontline start releasing content under iTunes U. And MIT Media Lab, and…

All I can hope is that they don’t kill the series before I can download it all.

The write-safety mechanism provided by attr_accessible doesn’t help in this situation, but having to write a custom to_xml method that steps through each of these already-whitelisted attributes is a bit silly and not very DRY.

My solution is to do something like:

def to_xml(options = {})
    super({:only => self.class.accessible_attributes}.merge(options))
end

Breaking that out, as I do, into a SecureModel mix-in seems like a good move.

For a living, I program computers. I use a dozen or so made-up, unspeakable (well, except for Ruby) languages to write stories that tell electricity how to flow across networks, through processors and from one magnetic point to another. Because I work in advertising, the last page of each of these fairy tales is (hopefully) a swarm of consumers choosing one breakfast cereal or male body spray over another.

I also dress poorly, by most non-nerd standards. No, I’m not fat. Nor am I especially thin. My clothes aren’t dirty. But aside from those clichés, I have an Aspbergers-like lack of comprehension of fashion. My ideal outfit is a plain black t-shirt, slim jeans, and the least-memorable sneakers available. On its own, my fashion sense doesn’t make me sound especially nerdy – just boring. It’s more than the choices, though – it’s the driver behind them. I dress myself by way of negation. I imagine everyone I see in a typical day, and I reduce and reduce by eliminating anything that stands out from one person to the next. Dressing seems to be, for me, a passive act of nihilism.

In fact, I am downright angered by the ironic trendwhores and hypebeasts and whatever other terms you want to use for idiots who spend good money on overpriced haircuts and clothing in order to eschew sincerity. It drives me wild. And yes, somehow I still manage to live in Greenpoint. But I digress…

What else makes me a nerd? Hrm. We have computers, we have lack of fashion passion.

Growing up, I was in gifted classes from second grade on. I competed in Olympics of the Mind (later Odyssey of the Mind due to a litigious IOC) and usually won on the conceptual events and never on the performance-based events. Yeah, that’s right: I was the kid with stage fright AT THE NERD OLYMPICS.

Other nerdlies:

• One of my better friends releases software under the name Bytes of Spring and I will never, ever stop chuckling proudly about that fact.

• I have a brass bell on my bike. Ding-a-ling.

• I have Robert Frost poetry tattooed on my arms.

• I’ve never danced, and, in fact, can’t watch people dance without burying my head in a pillow for shame.

Pretty nerdy stuff.

Non-Nerd by Omission

The subject of this post, really, is about the things that make me a bad nerd. The truth is, I have very few items on any of the requisite cultural consumption lists: the nerd list, the indy list, the political conscience list.
In my younger days, I might have obscured this fact in order to seem cooler. You know – the way you grimace dismissively when someone mentions a band you don’t know, implying something along the lines of, “Meh.” but really meaning, “Meh. I don’t even know what that is, but all ‘Mehs’ are the same to you, ya idiot.”

Well, I’m gonna fess up. Slightly. It would take forever to list the consumables I’ve not yet consumed. The meat is here. The exposed truth of the matter. The details are unimportant.

So let’s have a list, yeah?

Missing from the Geek Checklist

• 2001: A Space Odyssey
• Gremlins
• ET before the re-release in 2002(ish)
• Anything Star Trek
• Any Star Wars OTHER than Episode 1, which I saw in a theater a few years ago
• Most every video game ever made. I love games, but am non-committal. I own last-gen systems and like one game for each.
• Commodore 64 and other classic computer systems. I began “doing computers” in like 1997. What can I say? I was a poor kid growing up…
• Thinking 9/11 was a government conspiracy
• Like the item above, visiting digg.com
• Using Quicksilver for the Mac
• Ever liking They Might Be Giants
• Buying stuff from ThinkGeek
• Being a fanboy of any type
• Going to a LAN party
• Reading a graphic novel
• Collecting anything at all
• Playing any MMORPG, any RPG, or Zelda
• Reading Douglas Adams, Tolkien, Vonnegut, or Heinlein
• Ever seeing an episode of Dr. Who
• Being able to quote any Monty Python (movie, show, book, actor)
• Ever seeing an episode of Freaks and Geeks
• So very, very, very many more.

The Road to Recovery

I received Freaks and Geeks, Season 1, disc 1 in the mail recently from Netflix. I can’t stop reliving every moment of all three of the episodes I’ve seen thus far. I can’t believe how awesomely funny and perfectly tuned that show was.
Freaks and Geeks has joined The Wire and Dexter in my Best Stuff Ever on TV list.

I’m inspired, folks.

I’m gonna watch the rest of Freaks and Geeks. When I’m done I’m gonna start exploring some of the other omissions. Maybe I’ve found the tip of an iceberg here.

This must be what it feels like to get sucked into a cult, like Scientology or Reagan Republicanism.

It feels mighty fine.

In this installment, I’ll give a bit of insight into some of the publishing/blog software out there. I’ll focus only on the ones I’ve used, of course.

Before discussing specific packages, though, I guess I should touch on what software is, how it relates to resources (like pages), and where a database fits into everything.

I’ll also tell you how to set up the very cool Mint stats package on a host running PHP and MySQL.

The Server

Remember in Part 1 when I described a server as a computer that sends information out in response to requests from a Web browser? I was totally telling the truth. I was also totally skipping an important, yet confusing distinction.

The actual hardware is called a “server” but so is a piece of software running on that computer. Maybe it’s best to say that the combination of the two is really what constitutes a server versus a normal computer. A server is a computer running server software, in other words.

Most Web servers are running the Apache HTTP server. Apache is great. It’s a classic. It’s a workhorse. There are alternatives, of course, but Apache is sort of king.

Static vs. Dynamic

Generally, there are two ways in which a given resource (like a blog entry) can be served: statically and dynamically.

A static resource is a file living inside a folder. When the Web server software receives a request for a file (represented by a URI, like “tobyjoe.com/about/index.html”) it looks inside of a given folder, finds the file, and sends it to the browser that requested it.

Dynamic resources are the results of programs and are often recreated every time a user sends a request. Leaving a comment on a blog or performing other operations that add information to a page is a good example of a dynamic request.

Databases

You may wonder what happens when you add a comment to a blog and where the comment is stored so that other folks can see it. The answer is that most dynamic content is stored in a database.

A database is any collection of persisted, or stored, data. A text file can be considered a database, though most folks prefer to use a more complex system for storing their data.

On most Web servers, the database of choice is a special software package called MySQL. There are lots of different database types and systems out there, though. Another excellent database system is called PostgreSQL. It’s not quite as popular as MySQL, but it’s catching up. A few others you may have heard of are Oracle, MSSQL, Sybase, SQLite, and Access (yuck!)

In all likelihood, your shared hosting account will use Apache, MySQL, and a scripting language.

Scripting

When a dynamic request hits a server, the server software needs to know how to respond. The most common and essential functionality, like sending an image file, is usually handled by Apache. It’s excellent at doing the cookie-cutter stuff that all sites need to do: sending files, recording a log message for every hit to your site, and deciding what type of resource is needed by a given request.

Because Apache is so solid, we developers don’t like to go fiddling with its insides. It’s just not that fun. Or safe.

So how do we write programs that can do whatever we want if we aren’t modifying Apache? As you may have deduced from the title of this section (you’re so clever!), the answer is to use server scripting.

The most popular scripting language for the Web is PHP. It’s so popular, in fact, I decided to write a book about it.

You can think of PHP (or server scripting in general) as a simple way to write a custom application for processing Web requests. When Apache sees a request for a PHP script (usually ending in “.php”) it will use its PHP interpreter to read the script and perform whatever actions are inside before sending the result back to the browser.

Common tasks of PHP are to do things like connect to a database system, retrieve all the blog posts that mention pizza, create a page that shows a list of links to those posts, and send the resulting dynamically-generated page back to the browser.

I know, it’s daunting.

Some of the common languages used to write Web applications are: PHP, Ruby, Python, Java, C#, and perl. There are, of course, more – but who cares?

Publishing and/or Blog Software

Now that I’ve described all that semi-technical crap, we can get to the point: Unless you’re a developer with an itch to scratch, you should consider using established and respected software written by other folks and reviewed by endless smarties before writing your own. That isn’t true for everything, but this also isn’t an article for developers, so I’ll digress.

I’ve installed and used a few of the popular self-publishing packages and can speak fondly of a couple of them.

Most of them are fairly similar to a newbie, and you will probably be fine with whichever you choose.

The big players are:

• Mephisto
• MovableType
• TextPattern
• WordPress

I’ve had experience with each of these. Honestly, they’re all just fine and have active development communities adding plug-ins and enhancements.
I used TextPattern back when Ian Kennedy and I were running FiftyMillimeter. It worked fine, but the UI wasn’t great.

I personally use Mephisto, but that’s in large part because it’s written in Rails and I’m a pretty active Rails developer.

Check out the sites for each, peep the screenshots, and check around on sites that you enjoy to see what tools they use. It’s often mentioned somewhere in a footer or sidebar.

Stats

I work in advertising, and build sites for giant brands, small hip brands, and have done just about every-damn-type of project on the Web. One consistent desire, naturally, is to monitor stats: how many people visit, how many come back, where they’re from, how they found you, etc.

There are too many reporting packages out there. Most of them were ‘designed’ by developers and are clunky and geared towards information you probably won’t care about.

Enter Mint.

Mint was developed and designed by Shaun Inman and reflects his interests (and yours, I bet): good UI, good usability and good info design. The code is pretty solid and the plugin architecture is nice. I have a few nitpicks, but what geek doesn’t nitpick EVERYTHING under the sun?

I wholeheartedly endorse the use of Mint if you have access to a server that runs PHP and MySQL. It’s $30 for a license, but worth it.

Next

As you can see, there are so many options at every turn that writing a general tutorial is daunting if not impossible. I think the next steps are to cover Google Adsense. What else?

Holler.

So here I am, giving away some GEMS of knowledge for nothing at all. The trade-off is that I don’t know what format to use here and will probably edit and refine this a bit to impart some grace. Take a moment now to screen-cap anything you want to hold against me in the future.

Oh, and for the geeks – I know this shit inside and out, and am taking some liberties with simplification for the sake of clarity here.

(Much thanks to Jon Vanasco for helping me see that my narrative for DNS queries by browsers was kind of obtuse!)

The Domain

Here’s the scoop on how domain names work. Consider these two statements.

• Every site lives on a server. A server is a computer. Every computer has a number used to reach it.
• TobyJoe has a phone. A phone is a computer. Every phone has a number used to reach it.

Much like the numbers we use for our phones, computers use IP addresses. An IP address is a set of numbers with some dots tossed in to make it techy-looking.

Because it’s tough to remember IP addresses, people create nicknames for them. The domain name ‘tobyjoe.com’ is a nickname for an IP address. You already use nicknames in the phonebook of your cell phone. Domain names are just like those entries in your phonebook.

STEP 1: Find yourself a domain name. Think something up. Make it good.

Registrars

Now that you have an awesome domain name picked out, I’ll tell you how to find out that it’s already taken and that you’ll have to find a less-awesome replacement.

To check on the availability of a domain name, the easiest thing to do is go to a registrar.

You might ask, “What is a registrar?”

Registrars are companies that overcharge you for something that actually costs fifty cents. Seriously. Registrars can seem kind of sleazy (and some are) but there are a few out there worthy of your trust and cash.

For no great reason, I use GoDaddy. They have a few downsides, sure. They’re far too aggressive in trying to trick folks into buying stupid options and upgrades. Their site is cluttered and tacky as hell. But you know what? They’ve never done me wrong.

Use whomever you want, of course. Try to stick with someone you’ve heard good things about.

Just keep this in mind: skip all the bull. Don’t go for multiple years. Don’t go for anonymous registration. Don’t go for adding .net, .org, .blah to the order. Don’t add site hosting. Just get the domain. That’s all. Seriously.

STEP 2: Register your domain with a registrar.

Hosting

Remember all that stuff above that you read entirely and comprehended completely? Well, the server living at a certain IP address and pointed to by a domain name has to exist or your site is nothing. Nada. A blog.

To get access to a server, you have to pay. I recommend a shared hosting plan from TextDrive. There are lots of good hosts out there. These two are recommended by me, so they’re better than others, obviously.

STEP 3: Set up a hosting account. Use RailsMachine if you’re doing a Rails site (like a Mephisto blog). Use TextDrive otherwise. Or whatever. You’ll need a credit card, your domain name, and email address. Pick a Linux hosting plan. Stay away from Windows. It’s just trash, IMO.

Setting Your Nameservers

Nameservers, or DNS servers, confuse a lot of people at first. Hell, a lot of people have had sites for years and still have no idea what DNS servers do. It isn’t really required knowledge, but it’s good to have.

DNS servers are where you set up an entry saying “The computer address for ‘tobyjoe.com’ is (209.59.180.50).”

To stick with the metaphor above, a DNS server is the phone book on your cutsie-wootsie wittle blinged-out Sidekick. You pick a name, it knows the number. You never have to know the number. You become dumber. It’s awesome.

Your browser and mail client and most every other networked app refer to DNS servers when they don’t already know the address for a domain. For new domains, like yours, most machines will have to grab the entry from a DNS server the first time a user tries to visit. This all happens behind the scenes and usually takes only a few milliseconds. Neat, eh?

The way the DNS (aka, global domain phonebook) system was designed allows for changes on one server to propagate to all DNS servers within a day or two. This is good because it means everyone will have a DNS server nearby that can be used to find the addresses for a given domain name. If there were only a small number of DNS servers, they would be overwhelmed immediately.

When you set up your hosting plan, you will receive one or more (usually two) DNS server names. They might be something like “ns1.blahblah.com” or “192.168.1.3″

You will need to use your registrar’s site (like GoDaddy) to set the nameservers for your domain to whatever your new host sent you. Each registrar is different, but it’s usually pretty clear. Often, you’ll select your domain, and click something like ‘Edit Nameservers’ or ‘Add Nameservers’ and just paste in the “ns1.blahblah.com” or “192.168.1.3″ bits.

STEP 4: Set the nameservers for your new domain at your registrar.

Waiting

The world-wide domain name system will have to be updated to reflect this new domain-to-IP address relationship you’ve created. To stick with the cell phone metaphor, all the phonebooks in all the cell phones in the world will automatically receive your name and number combo. You’re gonna be SO POPULAR!

This process takes around 24-72 hours. It takes roughly the same amount of time to die from acetaminophen toxicity, btw.

STEP 5: Wait. Every few hours, anxiously type your domain name into a browser and see if you get something other than ‘not found’ in response. When you do, come back here for part two of this enthralling series.