Resources For Starting A Website

02.13.2016

I’ve been helping people out with their websites recently (as well as starting HowIBuiltMyBusiness.com) and a recurring question I hear is “What do I need to start a website?”

There are two things that every website owner needs:

Domain Name

If you look up toward the top of your browser you’ll see an address bar. The first part of the address is aaronhardy.com. That’s a my domain name. Other domain names you’re likely familiar with are amazon.com, facebook.com, and google.com.

In order to make it easy for users to visit your site, you’ll want to purchase a domain name as well. They’re quite cheap at around $10/year. I use NameCheap to register my domain names. In the past I used GoDaddy but several years back moved all my domains to NameCheap because I got tired of GoDaddy’s constant up-sells and user interface quirks.

Hosting

Now that you have a domain name, you need a server connected to the internet that can host your website’s files and potentially any databases. I’ve used DreamHost to host multiple websites for over ten years. I love their management console along with its one-click install tools that allow me to install things like WordPress in a jiffy. I’ve also found their customer service to be good and they’ve kindly helped me through problems that turned out to be my fault. I’ve helped others who were using providers like Bluehost but I find DreamHost to be superior. Be sure to use the promo code aaronhardy at checkout to receive the largest discount available.

Once you have a domain name, change the domain’s settings to point to the nameservers provided by your hosting provider. If you’re using DreamHost, the nameservers will be ns1.dreamhost.com and ns2.dreamhost.com. Once that is complete, upload your website files to your hosting provider (or install something like WordPress) and you’re on your way! Good luck.


Dependency Injection And IoC Containers

05.10.2013

The dependency injection pattern is one of my all-time favorite patterns in software design. The concept, in its most simple form, is so simple yet so powerful.

In essence, it takes us from this:

var TweetStream = function() {
    this.twitter = new TwitterService();
};
 
TweetStream.prototype.streamTweets = function() {var tweets = this.twitter.getTweets();};
 
var stream = new TweetStream();
stream.streamTweets();

To this:

var TweetStream = function(twitter) {
    this.twitter = twitter;
};
 
TweetStream.prototype.streamTweets = function() {var tweets = this.twitter.getTweets();};
 
var twitter = new TwitterService();
var stream = new TweetStream(twitter);
stream.streamTweets();

So what’s the big deal?

In the first example, TweetStream creates the TwitterService instance. TweetStream is forced to have a knowledge of (1) the exact “class” it should use to communicate with Twitter, (2) where and how to access the constructor, and (3) how to create an instance and appropriately initialize the object (passing parameters to the constructor, calling methods after the fact, etc.).

In the second example, TweetStream does not need to know any of these things since TwitterService is created by a third party and later passed into TweetStream. TweetStream only needs to know how to interact with the instance it is passed.

Although seemingly benign, the additional knowledge that TweetStream is forced to have in the first example increases its coupling to its dependencies while decreasing its own cohesion. The additional coupling leads to code that can be difficult to test and less flexible at runtime. If we were to “inject” the dependencies rather than forcing TweetStream to create or find them, we can easily mock dependencies during unit tests and provide them directly to the subject being tested. At runtime, we can easily swap out the object being provided as a dependency based on rules or contexts. Continue reading »


Slides: Intro To AngularJS

05.10.2013

Here are slides from a presentation I recently gave at Adobe on May 6, 2013. The examples linked to in the slides provided the basis for most of the discussion.


Slides: JavaScript Patterns And Principles

05.10.2013

As web applications grow increasingly more dynamic, software design patterns and principles become crucial for robustness and scalability. Let’s break out of the stigma of hodgepodge, spaghetti code found in web apps of old! In this presentation, we discussed modularity, communication patterns, and patterns used within MV* frameworks with examples from Backbone.js and AngularJS.

These are slides from presentations I gave at Adobe on February 5, 2013 and April 30, 2013.


ADC & Appliness – Dependency Management with RequireJS

10.23.2012

As if you haven’t had enough dependency management bi’niss from my recent Slides – Dependency Management with RequireJS and JavaScript Architecture: RequireJS Dependency Management posts, here’s similar material I’ve authored through other outlets:

Adobe Developer Connection: Dependency Management with RequireJS
Appliness: Dependency Management with RequireJS


Slides – Dependency Management with RequireJS

10.22.2012

Presented at 360|Min 2012 in Las Vegas, NV.


JavaScript for the Flex Dev Slides

04.16.2012

Presented at 360|Flex 2012 in Denver, Colorado.


JavaScript Architecture: RequireJS Dependency Management

03.20.2012

Updated Aug 11, 2012 to reflect current library versions.

In JavaScript Architecture: Organization and Quality, we discussed the importance of breaking apps down into very small, decoupled pieces following the single responsibility principle. Small pieces are generally easier to comprehend than a mess of large peices.

Some devs coming from other languages feel like they can only build a few large, spaghetti JavaScript files for their app. I tend to think this may be caused by three reasons:

  • That’s the way JavaScript has been done in the past.
  • Loading many JavaScript files requires many HTTP requests resulting in longer load times.
  • Dependency management is hard in JavaScript.

Don’t stoop to these excuses. We can do better than that and today there are fantastic libraries and standards that can help us out. However, let’s see what the above problems mean. Continue reading »


JavaScript Architecture: Backbone.js Routers

02.29.2012

Updated Aug 11, 2012 to reflect current library versions.

In JavaScript Architecture: Backbone.js Views we discussed how to build dynamic apps that change views on the fly using JavaScript. Because view-switching is done without reloading the page or transferring control to a separate page, these are called single-page applications. Single-page applications pose a few issues we need to address:

  • When users hit their browser’s back button, they will be taken away from the app completely rather than back to a previous view within the app itself.
  • Users are only able to link to or bookmark the app itself–not a specific view within the app.
  • Deep views within the app may not be crawlable by search engines.

We want a great experience for our users. Successful apps behave as users would logically expect and users should feel like they can easily navigate back to where they were previously.

Like the topics we’ve addressed before, these issues aren’t specific to Backbone. It’s an issue that naturally arises in any single-page app. Fortunately, Backbone does a great job at addressing it and has a simple API. Continue reading »


JavaScript Architecture: Backbone.js Views

01.08.2012

Updated Aug 11, 2012 to reflect current library versions.

Tech-agnostic concepts

At this point of the series I really want to emphasize that the core concepts I’ve explained and will explain are not unique to Backbone; they’re unique to apps with state and dynamic views. I’m merely using Backbone as an illustration of a concrete tool that can be used to solve problems common to this type of app in general. The concept of “views” is no different.

What is a view?

If you’re coming from a different language or even a different library, you may be familiar with words like component, widget, or control. You can ask 10 engineers what they think those terms mean and you’ll likely get 10 different answers…or 30 if they think the terms are different from each other. The term view is just another one to throw on the pile and is equally ambiguous. It’s not all that unfortunate. Indeed, its usage can be quite flexible and its granularity disparate.

In the traditional web of requesting a new page for each section of a website, we may consider each page a view. Indeed, it is. In modern apps, it’s more common to have a single page and, as the user interacts with the page, portions of the page change. Those dynamic portions could likewise be called views. Within a dynamic portion of the page, there may be a toolbar that affects a list of customers. The toolbar could be considered a view. The list of customers could be another view. Each customer row inside the list of customers may be its own view. The row may contain a toggle button which is yet another view. The point is, in the Backbone world, the term view doesn’t necessary mean “a section of your website”. It can be, and oftentimes should be, much more granular than that. Continue reading »