Click download

The perfect local development domain

Many website developers work locally on their laptops or personal computers before posting code to a centralized web server.

When running a website locally, you use http://127.0.0.1/ (or the common alias http://localhost/ )

However, these URLs are not especially elegant or descriptive.  So, developers typically edit their hosts file to provide a more descriptive domain, like mysite.dev or customersite.com.local

There are some dangers with this approach so well discuss the common approaches and suggest the best option:

*.dev

The problem with creating your own made-up top-level-domain (TLD) is that you run the risk of that imaginary TLD becoming an actual TLD.  For example, lets say you run a company called ACME and a decade ago your IT team standardized on using *.website for all your local websites.  So, http://acme.com/ would load your public Internet site and http://acme.website/ would load your private internal company intranet site (for all machines on the network whose hosts file was configured appropriately).  This worked great...until 2014 when *.website became a generic top-level-domain (gTLD).  What if the person that reserved acme.website was a hacker or competitor?  If a new employee didnt have the hosts file configured yet (or someone was using their mobile device, etc.), they would inadvertently load a different site controlled by that external entity.  Bad news!  Youre probably thinking, "Well, Ill just pick a domain suffix that no one will ever really think to register".  The reality is, with the proliferation of new gTLDs, its just not a safe bet to create your own.

*.local

You may be thinking, "Isnt there any domain I could use for local offline sites?!"  Well, there are -- theyre called reserved domains and they were built for that very purpose: example, invalid, localhost, test, and local.  None of these are particularly attractive except for the obvious choice: *.local.  Problem solved, right?  Not so fast.  Unfortunately a particular company (*cough*Apple*cough*) decided to abuse that domain for its own purpose so they ruined it for the rest of us and its no longer recommended for use.  Note: technically, *.test might be an acceptable alternative, but most companies already have a dedicated test environment so using *.test for a local site would be confusing.

Purchase your own dedicated-purpose domain

The safest way to ensure a particular domain suffix wont become official or be used by others is to simply buy it.  The downside to this approach is that it costs money (unless you use a free service [1, 2, 3]) and theres a slight risk of someone forgetting to renew the domain at some point and a squatter claims it, thus introducing the potential issue described in *.dev above.

*.dd

This country code top-level-domain (ccTLD) was originally reserved for for East Germany but never implemented (due to the reunification of Germany).  Importantly, it was never added to the root nameservers so browsers wont recognize it as an Internet address.  Equally important, it was used internally by a couple universities so that historic precedence means *.dd wont be revoked and reassigned to a different country in the future.  Its also easy to type and nondescript -- perfect for local development.

*.local.dd

My recommendation is to use *.local.dd because its more descriptive and allows more flexibility -- for example, you cant whitelist *.dd in Ghostery but you can whitelist local.dd (which then whitelists all its subdomains).

Available link for download

The first pillars of application development

When creating an application, you need to do first things first.  But...what are the "first" things?  Architecturally speaking, which are the "load bearing beams" that must absolutely be taken into account upfront and, conversely, which are the flexible items that you can safely incur technical debt in order to meet deadlines, management expectations, cost constraints, etc.?  If you are truly serious about building a robust, practical, maintainable, and praiseworthy enterprise-grade product, I argue the following are critical pillars of success that must be designed into the solution first:

Available link for download