30 Most Notable WordPress Sites

WordPress is a content management system (CMS) that gives users an out-of-the-box publishing solution. In plain English? WordPress helps you make a blog really easily.  

Every WordPress site runs the same code behind the scenes (aka. the core). But on the front-end you can customize your site a million different ways with WordPress themes. You can even learn how to make your own custom themes from scratch.

Because millions of beginners are using WordPress, it’s associated with blogging for newbies. But, WordPress is way more than your best-friend’s cat blog. 

In fact, WordPress powers 28% of the Internet. That’s because both Fortune 500 Companies and basement bloggers want the same things: easy publishing, good SEO, and options for organizing content. The best blogs do this real well. Some of the top sites on the Internet are using WordPress VIP. This is the company’s enterprise CMS, for users who get regular, massive traffic and need ongoing support.

I want to show you 30 famous WordPress sites. Once you see the power, customization, and scalability of WordPress you’ll be inspired to create your own WordPress site immediately. Look, you may not be Beyonce (unless you are, then please leave a comment),  but you can share the same WordPress code used by Beyonce.

1. Beyonce

Beyonce's website runs on WordPress

Bey’s site runs on WordPress. So bow down, reader.

2. Facebook Newsroom

Facebook uses WordPress

One of the top sites on the Internet uses WordPress for their news and press statements.

3. TED

TED blog uses WordPress

The TED blog offers “Further reading on ideas worth spreading.”  You can’t help but think you can change the world after visiting.

4. BBC

BBC uses WordPress The BBC, according to its website, is on a mission “To enrich people’s lives with programmes and services that inform, educate and entertain.”

5. The Walt Disney Company

The Walt Disney Company uses WordPress

 

The official home of the world’s most famous mouse.

6. USA Today

USA Today uses WordPress

 

“Latest world & breaking news”

7. Variety Magazine

Variety Magazine uses WordPress

 

Variety’s tagline is “The Business of Entertainment.”

8. Quartz

Quartz uses WordPress

 

“News, videos, ideas, and obsessions from the new global economy”

9. Nate Silver’s FiveThirtyEight

 

Nate Silver’s FiveThirtyEight uses WordPress

 

The site “uses statistical analysis — hard numbers — to tell compelling stories about politics, sports, science, economics and culture.” It’s journalism for math geeks.

10. Lifehack

Lifehack uses WordPress

 

Lifehack is a site for “Helps, Tips, and Guidance to improve all aspects of your life.”  Read this while brushing your teeth and listening to a podcast at 2X speed in the shower.

11. Black America Web

Black America Web uses WordPress

 

This REACH media site “was formed in January 2003 to develop, acquire and partner in quality media and marketing opportunities targeting the African American community and lifestyles.”

12. Toyota (Brazil)

Toyota uses WordPress

 

The company that says “Let’s go places” uses WordPress for its Brazilian division.

13. New York Post

New York Post uses WordPress

 

“Current & Breaking News | National & World Updates”  

14. Perez Hilton

Perez Hilton uses WordPress

 

This is a site for “Hollywood’s Hottest Celebrity Gossip.” If you’re too proud to grab a tabloid on the grocery line, you can get it all here, judgement-free.

15. Blog Maverick (Mark Cuban)

Blog Maverick uses WordPress

 

Blog Maverick is “The Mark Cuban Weblog,” a place where the NBA franchise owner, Shark Tank personality, and serial entrepreneur posts his ideas about business, politics, and life.

16. Official LinkedIn Blog

Official LinkedIn Blog uses WordPress

 

This is the blog for the world’s most famous networking site.

17. VentureBeat

VentureBeat uses WordPress

 

“Tech news that matters.”

18. Gigaom

Gigaom uses WordPress

 

“The industry leader in emerging technology research”

19. Spotify News

Spotify News uses WordPress

 

Spotify promises “Music for every moment.”

20. Forbes

Forbes uses WordPress

 

Forbes is a business magazine and now a sprawling online content company.

21. The Blog of Author Tim Ferriss

The Blog of Author Tim Ferriss uses WordPress

“Tim Ferriss’s 4-Hour Workweek and Lifestyle Design Blog” houses his writing as well as his popular podcast.

22. PEOPLE.com

PEOPLE.com uses WordPress

 

“Celebrity News, Exclusives, Photos and Videos”

23. Dow Jones

Dow Jones uses WordPress

“Business & Financial News, Analysis & Insight”

24. WIRED

WIRED uses WordPress

 

The famous tech news site started by Kevin Kelly runs on WordPress.

25. Mozilla

Mozilla uses WordPress

 

The Mozilla blog is a place to get “dispatches from the Internet frontier.”

26. Fortune

Fortune uses WordPress

 

When you want to know what’s going on with your money, go to this WordPress VIP site.

27. TechCrunch

TechCrunch uses WordPress

 

“The latest technology news and information on startups”

28. Boing Boing

Boing Boing uses WordPress

 

Boing Boing is “a directory of mostly wonderful things.”

29. The Official Star Wars Blog

The Official Star Wars Blog uses WordPress

 

Well wookie here. The blog for this classic film runs on WordPress.

30. Skype

Skype uses WordPress

 

Topping off the list is the blog for the communication company Skype. Hopefully this site can tell me if I should look at my web cam or the person while on my next call.

HTML vs CSS

So you want to build a website?

Learning how to construct a website is much like learning a new language.

The fundamental languages for building a website are HTML and CSS.

Let’s break each one down individually, then see how they work together…

HTML stands for Hypertext Markup Language. Think of HTML as the skeleton or tree of the document. It’s what gives structure to the site in its most basic form. We do this by tags, elements, and attributes. Whether you want headings, lists, images, or links, HTML can do all of that.

We can start with a basic HTML document.

<!DOCTYPE html>
 <html>
 <head>
     <title>Welcome to One Month</title>
 </head>
 <body>
     <h1>Big Willie Style</h1>
     <img src=https://i.imgur.com/Vr37Ac3.jpg>
 </body>
 </html>
HTML vs. CSS

HTML code example

Lets dissect this a bit further. The !DOCTYPE tells the browser what type of document it is. In this case, HTML. In the head section you can see the title tag. This is where you would put the title of your website. Inside the body, you could add an H1 tag. Think of a newspaper headline such as Hello World!. This would be inside the H1 tags like so <H1>Hello World!</H1> which would translate to the largest heading tag there is.

Tag, you’re it!

HTML is the structure of a website. In order to give your website form you’re going to need to use some HTML tags (also referred to as HTML elements).

<h1>, <h2>, <h3>, <h4>, <h5>, <h6>
These tags are for headings, much like a newspaper. h1 being the largest.

<p>
Paragraph

<br>
Line break

<img>
The img tag is for inserting images into your site.

<video>
The video tag is for adding videos, of course.

<a href>
We use this for adding links, stands for anchor.

<strong>
Bold

<em>
Italic

<ul>
unordered lists

<ol>
ordered lists

Note: Both <ul> and <ol> have children tags <li>

If you are writing a list either unordered <ul> (bulleted) or ordered <ol> (numbered) they will surely need items in the list. To do this we use the list <li> tag. The <li> is a child of either the <ul> or <ol> tags. So an example of favorite 90’s sitcoms would look something like this…

<ul>
  <li>Seinfeld</li>
  <li>Friends</li>
  <li>Frasier</li>
  <li>Growing Pains</li>
</ul>
HTML vs. CSS

HTML code example

CSS

CSS stands for Cascading Style Sheet.

If HTML is the structure of your page, CSS is the style. It’s not one or the other, rather they work together at all times.

Without CSS, your websites would look rather boring and dull. In CSS there is a property and a value. Property is what you want to change, property value is what you want to change it to.

Let’s look at our example again…just with HTML.

CSS code example #1

CSS code example #1

Remember the <body> tag in HTML? We can correspond the same body with CSS. Let’s say we want to change the color of the body. It would look something like this…

HTML with CSS code together

HTML with CSS code together

body {
 background: red;
 }

Gettin’ jiggy wit it.

Or lets say we want to change the color and size of just the text in the body.

It would look like this…

body {
 font-size: 25px; background: blue; color: orange;
}

Learn HTML vs. CSS with a blue background Or suppose you just wanted to hone in on the H1 tag. You could do something like this…

H1 {
 color: blue; font-size: 100px
}
 Learn HTML vs. CSS with a blue background
 

With color, we can do it simply such as the examples above. Another option is to use hexadecimals (#RRGGBB).

In order for us to take advantage of CSS, our HTML needs to be linked to it. We do this by…

<link rel=”stylesheet” type=”text/css” href=”main.css”/>

As you can see, there is a relationship (rel) between HTML and CSS.

Another way we can implement CSS is using the font-family property. This is the same thing as using a text editor to change the font.

We do this by…

h1 {
 font-family: Arial
 }
 HTML vs. CSS 
 

Case Study: CSS Zen Garden

A wonderful showcase of the relationship between the two languages is CSS Zen Garden.

CSS examples with CSS Zen Garden

CSS Zen Garden demonstrates the power of CSS. Clicking the links to the right will load the same exact page with one discernible difference, the CSS. This clearly highlight what CSS can do by changing the look and feel of the page.

Here are some examples from the garden…

CSS Zen Garden examples

CSS Zen Garden examples

CSS Zen Garden examples

Tutorial highlights

So what have we learned?

  • We’ve learned how to construct a barebones website using HTML.
  • HTML can exist on its own, CSS cannot, but together is where the magic happens.
  • The more we learn about each language, the more creative we can be with our design. This is the fun part. With the structure in place, the choices are endless when it comes to what we see.
  • HTML is the noun, CSS is the verb. Let’s make sentences!

Learn more HTML and CSS now! 

If you would like to continue your journey with HTML and CSS here are a few resources:

What is Coding?

print “Hello, World!”

We’re going to talk today a little bit about coding. Specifically we’ll answer the question, What is Coding? and also cover a little of what happens when we code. Before you begin, though, I want you to right click on your browser window and choose the View Page Source option. What you just got was a view of that web page’s code. Which is to say, you got a glimpse of the language that tells your computer how to make that webpage look the way it looks.

The first time I actually looked at the code in a browser window was a revelation to me. Here was the internet in the internet’s own voice. Sure I didn’t understand most of it, but I could pick out snippets of words and phrases I understood. I knew a font name or two, understood pixel sizes more or less. It was alien to me, but I could understand how it worked. Here was the language that my computer spoke. Or so I thought.

If you’re planning on learning to code at all, it’s worthwhile thinking through what exactly is happening when you code, what exactly it means when we say someone is coding, what the difference is between coding vs. programming, what languages you might end up coding in, and how to get started coding.

<style type=awesome_sauce.css>

So let’s start briefly with what coding isn’t. I mentioned above that when I first saw the source code of a web page, I thought that I was looking at the language my computer spoke. This is one of the common ways of talking about what coding is. It’s not exactly true, though.

Your computer doesn’t really understand the nuances of language. In fact, the only terms your computer understands well at all are “Yes” or “No.” Imagine talking to a group of engineers, but your phone has gone out and your radio only works one way. You can only communicate with a flashlight. One flash for yes, two for no. It might take a while, but eventually, the bridge will get built and all will be happy.

This is how a computer communicates with people. The language the computer speaks is binary code, a mathematical language that looks like a line of ones and zeros. Essentially the computer understands “Turn this function on. Turn this other one off,” and nothing else. So unless you’re typing strings of ones and zeros into your text editor (which, you’re not…just no), you’re not really writing code in a computer language.

OK, so if writing code doesn’t amount to writing in the computer’s own language, what are you doing?

Well, think about it like this. You don’t speak binary and the machine can’t come close to understanding human languages. So in order for you to tell the machine what to do, you have to have a translator who can act as an intermediary. This is code. It’s a form of writing that isn’t binary, but that the computer can understand.

For most of the programs you’re likely to write, the code is actually several steps removed from the binary code. You write in a high-level code that’s closer to human language, and programs built into your computer translate them down into binary. It’s like if you needed to speak to someone who knew Mandarin, but the only translator you could find spoke only French. You would need another translator to translate from English to French and then they can translate to Mandarin.

What sort of blows my mind about all of this is that it works somehow. We have programs translating programs to a machine that only speaks binary, which is an insanely complicated prospect. Yet here I am typing human words on my binary speaking computer.

Luckily, when you start coding, it’s not really important to understand how this all works as long as you understand what programming is you’re headed in the right direction. The important takeaway is that coding is writing in an intermediary language that both you and your computer can communicate in.

<{Coding=Programming} YES>

When I was growing up, my dad was a computer programmer and all the people he worked with were programmers. This was how I understood people who wrote for computers for a long time. They were programmers.

Then it seemed like there was a shift in either terminology or industry, and suddenly people who wrote for computers were coders. Which has prompted me to wonder whether there is a difference between the two activities.

A little research shows me that it depends greatly on what school of thought you subscribe to. Several forums I have looked through say that there really isn’t a difference between a coder and a programmer. It’s a difference in terminology rather than activity.

The egalitarian in me likes this way of looking at things. However, Jonah Bitautas makes an interesting argument that there is a real difference that amounts to a matter of scale. Essentially, a coder is someone who writes language for computers. A programmer is someone who oversees the writing of a whole program — that is to say, a whole project’s worth of code writing.

It’s the difference, I think, between calling someone literate and calling someone a writer. A literate person can write and read words, but doesn’t necessarily see how they work together into elegant paragraphs and sentences. A writer, on the other hand, understands how those words work together in a larger, more complex structure and can maneuver through that structure with intelligence and choice.

Like I said, I love the egalitarian quality of the first definition, but I’m all for preserving a sense of difference between the activities, if for no other reason than it gives people something to reach for. I have written code, but I am not yet a coder. When I am a coder, I think I’d love to be able to look forward to the day when I can call myself a programmer.

Languages

There are literally dozens of languages a person can learn to code in. Although a few languages are all-purpose (or multipurpose), most serve a specific function. CSS, for example, functions primarily to make things look pretty on the web. JavaScript, a relatively old language, exists to make web pages more functional. Depending on what you want to accomplish, you’re going to have to choose a specific language. There are a few common ones that you might want to work with, especially if you’re just learning to code.

HTML

When I asked you a minute ago to open the source code for this web page a minute ago, it took you to lines of code written in HTML. Short for Hypertext Markup Language, HTML works as sort of the bones of the Internet. It tells web pages what should be displayed where and how they’ll fit within a given style sheet. It also tells your browser where to look for content like images and videos that you might want to include, as well as where to find the style sheet you’re working off of.

CSS

CSS is the stylesheet. If you open up a CSS file, you’ll see a lot of references to font families, colors, bold or not, etc. When your browser loads a page, the HTML tells it “Hey. Make this part of the page look like a header. OK?” It also says “Here’s where to look to understand what a header should look like.” This will always be a CSS file.

Javascript

Javascript is a language that brings interactivity to the web. It’s a language that makes things happen on a web page. When you click a button on a web site, for example, it’s JavaScript that makes the button seem to click. The controls for video players on the web, animations, etc. Most of these are JavaScript of some other dynamic programming language. In a later post, I’m going to be writing about front-end versus back-end work using Javascript and PHP. Which is to say, programming for the user of the website versus programming for the server of the web site. More on that to come.

Ruby on Rails and Python with Django

We actually already have a baller post on the differences between these two framework languages, which is worth ducking away to read when you’re done here. The short version is that Ruby on Rails (Rails to its friends) and Python (named for Monty Python) are both programs that are used to develop web applications. Which is to say they create programs that allow web pages to do things at a high level of interactivity. If you want to, for example, build a bot to automatically create an automatic payment system for your clients, you’ll probably use one of these. They’re great programs to learn to work with because they are extraordinarily versatile and there is a lot of extant code for you on the web to begin playing with this.

Learning to Code

There are actually a lot of parallels between learning to code and learning to write well (as there should be, since coding is just writing in computer languages). I think the most frustrating of these is that, as with learning any language, you have to be willing to spend time practicing it and doing it poorly.

There are some people who are just natural coders, sure, just as there are people who can speak Italian after listening to a couple of operas. For the vast majority of us, though, learning to code is a process that involves trying to tell the computer to do something, having the computer come back with an error message (which is its way of shrugging its shoulders and saying “Qua?”), and then trying a new way of doing the same thing.

The most successful self-taught coders I know are people who regularly take on coding challenges just to see what they can make. I know a guy who writes Python bots for Twitter as a sort of hobby. He’s made some things that are pretty awesome to behold.

Coding languages now are dynamic and complex enough that often times if you can conceive of a thing you want to have happen on the web, you can do, and probably there’s a web site that can help you work out how.

There are also many ways to find classes that can get you started on the basics of whatever program you want to make. That means there’s really no reason to not start playing a bit. There’s no risk to trying something (you can’t break the web; Kim Kardashian already did that), and the gains are huge. So go for it. Conceive a bot, conceive a web page, conceive a font family, and get started.

Understanding HTTP Basics

One thing that always surprises me when teaching a security class to developers is how little they understand about HTTP. Sure, everyone knows that a HTTP 500 error is a problem on the server, and 404 means the file is missing, but few actually understand how HTTP works at a lower level. This is critical to understanding most web application vulnerabilities and will help you be a much better web developer, so lets dive in!

Skip this if you have a decent understanding of HTTP. Otherwise, it will be a great refresher. First, let’s start with the super-basic before we quickly move into more advanced topics — HTTP. HTTP is the protocol that is used by web servers and browsers to communicate. HTTP is based on a request and a response.

When the you type in a webpage URL in the browser and hit Enter, the browser makes an HTTP GET request. Here is an example of what that looks like:

There are a few things worth noting in the screenshot above. Let’s take a look at the first line. First, the HTTP “verb” is GET, which is generally used to retrieve a document, image, or other internet resource. We will look at the other verbs in a minute. Next, the webpage being requested is “/home”. Anything after the “?” are parameters, which come in key/value pairs. Finally, the HTTP version is provided, which in this case is 1.1.

The rest of the lines are HTTP headers, which do things like: tell the webserver what website to retrieve, based on the domain (Host:); report the user-agent and acceptable encoding and language; and other browser-specific options.

From a security perspective, we need to be aware that parameters in the querystring get logged all over the place, so we want to make sure nothing sensitive or important goes there (think passwords, email addresses, or API keys).

Another HTTP request is the POST, which works almost exactly like the GET request except the parameters are sent in the body of the request instead of on the first line. This is good for security since these values are generally not logged by default on webservers, proxies, or other software as the request is transmitted over the internet.

Other request types are OPTIONS, HEAD, PUT, DELETE, and a few other more obscure values, however GET and POST are the most common. Let’s take a look at the HTTP response:

HTTP responses are similar to HTTP requests in that they are text based and contain HTTP headers. On the first line above, the HTTP response returns the HTTP status code. When everything is going right, this will be 200 OK. Below are the list of status codes which can be returned:

After the status code, some server headers are sent, including information about the type of server and software it’s running. Next, the body of the response contains the data we requested, which is generally HTML, CSS, Javascript, or binary data like an image or PDF.

Since HTTP is a text-based protocol, it’s easy to make HTTP requests. You can try this by running telnet and connecting to an HTTP server and then manually making a HTTP GET request. Try it yourself by typing “telnet google.com 80”.

Then, when telnet connects to the webserver, you can manually make an HTTP request by typing:

“GET / HTTP/1.0 (return, return)”

This should return the HTTP response for the homepage.

That’s it, now you know the basics of HTTP. Here are the important parts:

  • HTTP is a text based protocol
  • HTTP is made up of requests and responses
  • HTTP responses have a status code

Now that you have that covered, check out some hacking tools in the blog post Web Hacking Tools: Proxies.

What People Really Mean When They Say “I Want To Learn How To Code”

There are two important things to know about coding education:

  1. Most people don’t actually want to learn to code
  2. Learning to code doesn’t mean one thing anymore

It’s important to know these two things because otherwise the way we teach people about coding is wrong, and people won’t learn.

The first point I’ve seen over and over again. People who tell me they’re going to learn how to code, then they start learning, and they think it’s boring as hell.

I call it the coding fallacy. People think they want to learn to code but what they really want to do is build a product.

When we think about it, this should be fairly obvious. Knowledge of code in and of itself is not valuable if you can’t do anything with it. So for most people the biggest motivation for learning to code is building something (although a close second is getting a higher paying job).

That brings me to point number two. Learning to code doesn’t mean the same thing anymore.

It used to be that in order to code you had to know almost everything about computers (hence the term “Computer Science”). Then things were abstracted to the point where you didn’t really have to dive into certain topics unless you really needed to. For example, as a web application developer at this point I need to know very little about system administration because it’s mostly done for me by tools like Heroku and Amazon Web Services.

So when people say they want to learn how to code, most teachers start where they assume they should (where they always have), with data types, the various structures of a language, and help students develop a deeper understanding of computers.

The problem is that’s not what people want. They want to build something. And we should no longer take for granted that in order to build something you have to learn everything about computers or even coding in general.

For example, if someone is already working with a great back-end developer, it would make sense to just teach them the front-end, because that’s going to be the most useful thing for them. They will actually get what they want done faster, and they will be able to learn the back-end at a later point in time. By doing so we reduce the cognitive load on the student and enable him or her to learn faster.

There’s so much that could possibly be taught about coding that we need to start identifying at least semi-complete subsets that someone could learn. At the very least I want to pose the following important distinction I’ve learned:

  1. Web development
  2. Non-web development

When you’re developing for the web you specifically have to deal with:

  • HTML
  •  CSS
  •  Routing
  • Databases
  • Hosting/DNS
  • Application structure

There’s a lot here to learn. And most of it is pretty irrelevant to non-web development (except databases and application structure obviously).

The way I see it, most coding education involves a bait and switch. It goes like this:

Student: “I want to learn how to code.” (But what they really — but don’t know enough to ask — is I want to build a web or mobile application.)

Teacher: “Okay let’s start with data types.”

Student: “…”

(2 weeks later)

Teacher: “Now we can design efficient algorithms.”

Student: “But I just wanted to make a cool-looking website!”

As teachers, we need to recognize that when people say they want to learn how to code, they often really mean that they want to build a web or mobile application.

That’s because to them, that’s what coding IS. It’s all they’ve ever been exposed to about coding. The problem is that they don’t know how to ask for it! So we shouldn’t just be taking everything they say at face value. It’s our job as educators to read between the lines.

I remember watching a play a few years ago in which a priest says that you have to tell the truth even in difficult circumstances. The person he’s talking to asks: “but what if someone asks you a question and you know the truth will hurt them?” The priest responds: “When someone asks you a question, answer the question they are REALLY asking.”

In education as well, you have to read between the lines to figure out what people really want. If they’re asking some specific thing, you have to guide the person towards what’s going to lead them towards their ideal learning experience.

So it’s up to us as educators and as experts to guide people in the right direction and not just let them flounder. If we can do this, then we can empower a lot more people to do amazing things.

As a student: learn what you want to learn.

One of the best things you can do in your own learning adventures is learn a little bit about a lot of things — so you know what you want to dive deeper into later. Here at One Month, we’re launching a Learning Library in the new year, a free resource of videos, essays, and information on topics related to coding, design, and entrepreneurship. It is your first 1 minute, 1 day and 1 week of content for any subject.

Some People Say Ruby Is Too Complex for Beginners…

Is Ruby the right programming language for beginners?

One of the biggest criticisms I hear lobbed against learning Ruby as a beginner language is that Ruby has so many different ways of doing things. People say that these different ways of doing the same thing makes it hard for beginners to learn.

To be specific, here’s one example of this argument that I read on reddit recently in response to my earlier post, Why Beginners Should Learn Ruby on Rails:

“Ruby almost always has 100 ways of doing any problem, and frequently the user-submitted examples on Stack Overflow are meant to dazzle rather than instruct.”

or

“So much shorthand and so many options that when I’m trying to learn one particular function, I get 100 different users telling me to do the problem 100 different ways, none of which helps me understand the thing I’m trying to learn.”

This is true.

Ruby in particular has lots of instances where there are multiple, equally good (and sometimes not equally good), ways of solving the same problem. But rather than that being a weakness of Ruby, I actually think the flexibility of the language is an incredible strength, especially for beginners.

But rather than that being a weakness of Ruby, I actually think the flexibility of the language is an incredible strength, especially for beginners.”

You see, there’s no one way that you learn something, and whichever way sticks is usually the best for a beginner.

Here’s an example.

In Ruby, there’s the select method (in Ruby, functions are called “methods”), which lets you take a list of things and pull out a sub-set of that list.

It looks like this:

list_of_numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
list_of_numbers.select { |number| number.even? }

Even if you’ve never coded in Ruby in your life, read that second line and take a guess at what you’re going to get. That’s right, you’re going to get the sub-set of even numbers: [2, 4, 6, 8, 10]

There’s a second way to do the same thing. It’s called the find_all method.

So instead, you could write:

list_of_numbers.find_all { |number| number.even? }

What do you think you’ll get here?

Right! It’s exactly the same result as the select method.

So why does Ruby have at least two ways of doing exactly the same thing?

It’s because the people who created Ruby were inspired by a few other programming languages — Perl, Smalltalk, and Lisp are a few — and they borrowed the different names for doing things from those languages. Also, it happens to be really easy to write a method once in Ruby and just point other methods to it. That’s not as easy to do in other languages.

So why is this an advantage?

Well, because you don’t have to remember both of these ways of doing things! You just have to remember the one that works for you. I almost always use select.

Doesn’t this get confusing? Maybe, if you’re looking at lots of different people’s code. But by that point you’ve already learned that select and find_all are the same, and it’s not so hard to figure out. Language is a lot like this. There are many ways to say the same thing in English:

Language is a lot like this. There are many ways to say the same thing in English, which enables creativity.

I’m happy, I’m cheerful, I’m pleased, I’m delighted, I’m jolly, I’m beatific, I’m glad, … do I needto keep going?

The flexibility actually opens up creativity, which I think is one of the coolest parts about a language like Ruby. Meanwhile, in most other languages when there’s only one way of doing something, if you don’t remember that way then you’re screwed.

Another clear example that people like to hate on all the time: parentheses.

In Ruby, parenthesis are optional in methods. So are brackets { } a lot of the times, and you can basically use either single quotes or double quotes interchangeably.

Take that same list from before:

list_of_numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

What if you wanted to see if it included a particular number?

You could use the include? method:

list_of_numbers.include?(2)

But you could also leave out the parentheses in this case (and lots of Rubyists do) because it’s prettier and easier to read:

list_of_numbers.include? 2

Sure, there’s a few rules about this. You have to put a space beforehand instead of parenthesis (otherwise Ruby would think you were trying to run a method called include?2 which doesn’t exist).

The point is, you can try many different ways of getting at the same issue, and get an answer to your question in many ways. Rather than get stuck on needing to know the exact way to write something, you can solve your problem in more than one way.

The same is true for software applications, like AutoCAD. As a user, you can type into the command line, navigate towards a button, or use drop-down menus. In addition, you can choose to draw a line with at least eight different tools (line edit, polyline, arc, points, etc). One way isn’t better than the other — they’re just all different tools for drawing. Having many different ways to get shit done makes it easier for people to remember the technique that works best for them.

Flexibility! It’s a beautiful thing.

I’ve never understood why people thought that having multiple ways of doing something was a bad thing. When you’re first learning, you have to grasp and understand whatever concepts you can, as a starting point.

Meanwhile, a language like JavaScript is a truly hard language for beginners to learn, because there are so many specifics that don’t come naturally to a beginner, and you have to do them that way. I’m not saying you can’t learn it, but the amount of times I’ve heard beginners so frustrated they were ready to give up because they’ve forgotten a “;” somewhere and have no idea where.

If you’re interested in reading more about why Ruby is a great language for beginners, check out Why’s (Poignant) Guide to Ruby. It’s one of the most beautifully and interestingly written pieces about programming, and is one of the biggest reasons I fell in love with Ruby in the first place.

And then, if you want to learn more about Rails, watch our free one-minute video or check out our Rails course to go build your first app.

Refactoring: Stop Worrying and Code, You Can Fix It Later

Do you write perfect code on the first try?

When a writer decides to produce a novel they don’t sit down and plunk out perfect copy in one go — rather, first comes an outline, then a draft, then revisions, refinements, and finally, a publishable final draft. This process works because it lets a writer begin with big vague ideas and work through them, ironing out all the details as they surface.

Software engineers have a similar technique to editing, and it’s called refactoring. Refactoring is where a coder changes the structure of a piece of code without changing it’s function. It’s a very useful way to clean things up once your code is actually working. Most importantly, knowing how to refactor allows you to get down to coding faster, and without fear of “screwing it up.”

Lets take a look at how the writer’s pattern can be applied to converting your ideas into code.

Start With Pseudocode

Pseudocode just means “shorthand that describes code,” and it looks like plain English. I begin by writing in comments that describe the code I’m about to create, as much for my current benefit as for future documentation needs. Don’t think, just pseudocode the first approach that comes to you. The nice thing about pseudocode is that if it’s bad you haven’t wasted any time writing actual code. Once you have something that looks halfway decent, move on.

Stub It Out

Bits of code usually have an input, an output and some main variables; writing these around the pseudocode forms a sort of a skeleton called a stub.

Fill It In

Write actual code!

Iterate Until It Works

In this case, the above code didn’t work, but don’t be discouraged. Even for the most experienced coders, 90% of the job is debugging, just keep pushing until it works.

Clean It Up

Now that it works, look at your code. What’s ugly? What could be simpler? What is running slowly? Because your code is functional you can fearlessly modify it to make it better as long as you test it after each change. If it doesn’t work after a change, just undo it and try again!

Refactoring is your friend

The important lesson here is that you, like a writer, should not worry too much about the quality of your first draft because it can always be made better later. What’s great about this approach is that it works just as well for tiny snippets of code as it does for whole scripts or huge projects.

What’s great about this approach is that it works just as well for tiny snippets of code as it does for whole scripts or huge projects.

All software is made of little simple bits of code that all build up to a big complex whole. In the world of coding, we have a thing called a function or method that lets you draw a box around a bit of code, define it’s input and output, and re-use it as a black box that performs that some action.

One of the many reasons it’s good practice to write code using functions instead of copy-pasting is that if you want to change code later you only have to do it in one place (the function). Another benefit is that it’s much easier to think about small pieces of code. Once your code is working, you may notice that some functions work, but aren’t very good.

Refactoring means freedom!

Understanding refactoring means freedom from the worry of “writing it wrong”. When you sit down to solve a problem, don’t stress, remember no one writes perfect code the first time.

So focus instead on writing something that works, and remember that you can always refactor later!

Let’s Change How We Think About Learning to Code

Before I ever had my first paid job as a programmer, I spent a lot of time contemplating what it means to get paid as a programmer. I was a hobbyist, teaching myself to code in grade school and high school.

When I became a freshman in college studying Computer Science, I began thinking about the future. I was being asked to commit to being a programmer for the rest of my life. I had no idea what it meant to work with programmers or even work as one on a team.

I’m sure anyone looking to dive into software will have the same questions.

  • How do I start learning to code?
  • What language should I use?
  • What kind of computer should I have?
  • What operating system do I need?
  • What books should I read?
  • Should I go to a bootcamp?

The trouble is that all these are surface level questions. You feel frustrated because every time you ask these questions, you don’t feel like the answers satisfy you. Someone can write a post telling you the differences between Ruby vs Python and yet at the end you still can’t make a decision between the two.

That’s because there is a laundry list of meta-questions you might not even be aware of yet. What you’re really trying to answer are questions like these:

  • Why do we have so many programming languages?
  • How do I know if I’m on the right path, using the right technologies, and working with the right people?
  • What is the difference between a bad programmer and a good one?
  • How can I tell if other people are good or bad programmers?
  • How will I know when I’m a good programmer?

These are just scratching the surface of the underlying questions you probably have.

You will have this intense feeling of discomfort for a while. You know there are lots of important questions you should be asking, but you don’t know what they are yet or how to articulate them.

This experience shouldn’t be unfamiliar to you. Remember in high school when they tried to prepare you for college? You took these career quizzes, teachers gave you advice, your parents pushed you in different directions. It was a huge decision to make and you didn’t even know where to begin.

It’s the same thing when you start programming. The fundamentals of computers have always been the same.

It is called a programming *language* for a reason.

The most obvious purpose of a programming language is to tell the computer to do what you want. I type some code, it reads it, and adds two numbers together and gives me the result just like I expected it to. Perfect.

The hidden purpose of a programming language is to talk with other human beings.

The hidden purpose of a programming language is to talk with other human beings. We have many natural languages like English, Spanish, German, Chinese, the list goes on. There are many ways we can communicate with other human beings. The same thing applies to programming and this is why we have so many different programming languages.

There are a thousand ways to explain an idea. The computer can understand all of them, but humans can’t. When you write code, you have to express your ideas in the clearest ways. Code that you wrote six months ago looks like gibberish because you think differently now. There is so much difference in human thinking due to learning, culture, and experience. That means that great code emphasizes human understanding first and computers second.

Great code emphasizes human understanding first and computers second.

There is a broad spectrum here and each programming language falls somewhere on it.

Some programming languages are designed more for computers than they are for humans. In fact, the most computer-focused programming language would actually be 1s and 0s. Something that, as humans, we wouldn’t even consider a language at all.

As you move up the chain, you can see things shift more towards humans.

Assembly is introduced to make the 1s and 0s more memorable for us.

C is designed to be an easier level than assembly but you still have to heavily think about how the internals of a computer works.

C++ begins to introduce some human concepts into the language so we can represent ideas better in code.

Java builds upon the ideas of C++ but abstracts away the internals of the computer as best it can. You don’t need to care about how things inside your computer like RAM is used as much.

Python takes another step towards humans and focuses on a syntax that’s more readable for humans but still has a lot of the structure inside it.

Ruby is focused on flexibility. They want your code to be like writing a story or a poem. Sure, you still have to worry about how the computer works somewhat, but even less so than Python.

Every programming language fits on this scale somewhere.

The trouble is that it’s hard to even understand what this means as a beginner programmer. If you don’t know how the computer works, then Assembly is going to sound scary. At the same time, if you only ever learn Python then you will feel something is missing because you’ve never learned how the internals of the computer actually work.

The trouble is that it’s hard to even understand what this means as a beginner programmer.

The internals of the computer are the building blocks of programming that you’re taught in college. The problem is that college is on one end of a spectrum that we didn’t realize existed until recently.

In a college computer science degree, you’re put in a world of heavy theory and concepts. There is little practical application of these ideas, but you dive deep into these topics. You learn about algorithms and data structures and how the electricity flows through the computer to make it work. Yet, you learn all this without seeing its value applied to problems that make money in the business world. At the end of the day it feels very disconnected.

Bootcamps tend to be the opposite end of the spectrum. You learn how to type code without ever learning how a computer works. The stuff you learn is built upon a fragile foundation because you’ve been quickly pushed through a system designed to get you a job after just three months (or less).

Until the recent rise of bootcamps and online learning, I don’t think it has been obvious this spectrum even existed in education. As you read this, 5 more bootcamps are getting started and 5 more colleges are committing to teaching old technology for another year (not really, but basically).

The value of programming and tech is becoming apparent to the entire world and it’s becoming cool.

The value of programming and tech is becoming apparent to the entire world and it’s becoming cool. Being a programmer used to be considered unattainable if you weren’t trained in it. With the rise of popularity in startups and the financial success of tech companies, learning programming and investing in technology is becoming the cool thing to do. The barrier to entry isn’t as high as it has been in the past and the average person is able to hop online and start learning Rails in 30 seconds.

The value of having skills in tech are becoming increasingly obvious as well. Being a programmer means you can work from home, remotely, and still take home a six figure salary. Print designers are looking to add web design to their skill set because they know they can advance their careers that way. Corporate managers are looking to start a startup because they feel like they would get more value out of it. The list goes on and on.

The important piece of all this is that these are all people without a technical background.

They come from careers where software was not a large part of their job. The need for learning software from a more human focused vantage point is clear.

It is likely that college will persist as the place to learn deeply technical things and bootcamps will be the place to dip your toes in the water.

There is a middle ground though that is largely unfulfilled — and what online education startups are beginning to address. A place where you can go to dip your toes in, but shows you that going deeper isn’t scary.

The reality is that everything about computers that exists today was created by humans. It’s all a product of our imaginations and hard work. We have the tools for anyone to learn it.

The path to becoming a programmer is simple. You start at a point on the spectrum where you feel most comfortable and you work your way towards the middle.

The path to becoming a programmer is simple. You start at a point on the spectrum where you feel most comfortable and you work your way towards the middle. The middle ground is a place where people are equally comfortable with people and computers. It’s the future we’ve dreamed about where most people are able to write their own software to solve their problems.

If you start on the deeply technical side of the spectrum, you’ll be best served by figuring out how to apply your technical skills to solve human problems. All the hard work and innovative software you create can be used by thousands of people to solve their problems in unique ways.

If you start on the human side, learning technical skills and programming will give you a tremendous advantage in solving those human problems you work on every day. Maybe that nagging issue you can’t seem to fix is solvable by writing your own tool to improve communication.

The important thing to realize is that there’s no one way to start and no one direction to go. If there were, everyone would be doing this and it would be easy. But you should keep trying because coding is one of the most valuable and creative things you could ever do. You can literally build things out of thin air that don’t exist yet.

And one day you’ll step back from the computer and realize you finally get it. There’s no feeling like it. As Neil Gaiman says, “Perfection is like chasing the horizon. Keep moving.”

Responsive vs. Adaptive vs. Fluid Design

The world of web design has changed quite a bit over the years and continues to evolve as mobile-friendly design becomes more of the rule rather than the exception. When it comes to choosing the right layout for your website, there are a number of factors to keep in mind including style, typography, imagery, user experience, performance and online ranking just to name a few.

It used to be that sites were built with fixed dimensions — that were meant to be viewed on a desktop screen only. Now there are variations based off this original idea to make room for the influx of mobile users. Your users are demanding to view your site — not only on a computer screen — but on a tablet or a mobile phone. As a result, three popular considerations for web page layout are: responsive, adaptive, and fluid design. While each of these web designs has similar features, they each have their sets of pros and cons.

Defining The Different Types of Design Types

Responsive: websites are built with media queries that target more general break points that scale images, wrap text and adjust layout accordingly. This is my prefered strategy when building websites.

Adaptive: websites are built with media queries that target specific device sizes (e.g. iPhone, iPad, Android, etc). One of the problems with an adaptive layout, is that as new devices get introduced your code will need to be updated. Which isn’t ideal.

Fluid: websites are built using percentages for widths. The concept of fluid design was being used way before Ethon Marcotte coined the term “responsive design.” It’s pretty safe to say, that fluid design evolved into responsive design.

Fixed: websites are built using fixed pixel widths. While a design with fixed dimensions can sometimes be the quickest way to get up and running, it’ll provide a less user friendly across multiple devices.

Diving in: Responsive vs. Adaptive Design

Responsive web design (RWD) is what is recommended and rewarded by Google. The search engine continues to change its algorithm to include the growing number of mobile users and take into consideration how a mobile-friendly site should and does rank higher than those that are not responsive. A responsive design can help ensure that your website provides both a good user experience and adequate load time when viewing on a phone, tablet, or other mobile devices.

However, many web designers and developers have debated whether adaptive web design (AWD) edges out responsive, especially for older sites that already have a strong domain and web history. Think about it: it wasn’t that long ago that we designed solely for desktop. As new mobile devices are created and different screen widths and resolutions become a factor, it’s important to be able to go back and make an existing site mobile-friendly rather than starting over from the beginning. Adaptive design allows for this.

AWD uses a series of static layouts and detects the screen size to load the layout to fit however it’s being viewed. Typically, there are six common screen widths that cover the different ways that a user might view a website. Although creating multiple widths for the design of one website might seem like extra work, in some cases, in can be better for the overall performance and display.

The benefits of an adaptive site is that you can measure which views and resolution options are performing best and alter design and development for the sizes that are getting the most online traffic. For example, if your site drives the majority of its traffic through desktop, than you’ll want to make sure that you’ve addressed all constraints such as site speed, usability, aesthetics, and media load time (when applicable) that a desktop user might experience. You can still add views for different types of mobile devices, but with adaptive design, efforts can be based on what is top priority.

Alternatively, the benefits of responsive design are that it takes far less work to build and maintain. It’s applicable for all screen sizes and will adjust accordingly. While responsive design is fluid and will adapt to the screen no matter what device you’re viewing the website on, this type of design is far more complex and can create issues depending on the amount of content and media on the site. This may slow load time and ultimately, hinders the user experience.

The designer must keep in mind the widths of images and different features that will appear differently when automatically “resized” as a person changes their view from mobile to tablet to desktop. In each case, it’s important to perform testing and QA on multiple devices. For new sites, responsive would be the easiest way to go, but for sites that already have a desktop build, adaptive would most likely be a better option due to its ability to retrofit.

How Fluid Design Compares

A third option is a fluid design, which has the same adaptability as both a responsive site and an adaptive site. Fluid design doesn’t use fixed units, as with static sites, but rather uses the same percentage of space no matter what screen you’re viewing the site on. It’s able to fill the width of a page, but this can create challenges depending on the size of the browser.

Say for instance you’re viewing a multi-column web layout on a smaller screen, like a mobile phone or a tablet, the content may seem to be crowded within the page. Or, on the opposite end of the spectrum, if you’re viewing on a large desktop or a smart TV for a presentation, the content can look stretched. The styles and features of a website will affect fluid design and may affect the amount of whitespace seen depending on what size screen you’re viewing the website on.

The benefits of fluid design are that it’s user-friendly because it adjusts to whatever device the viewer is looking at, same as responsive design. It’s definitely an improvement over a static design; although some designers might still argue that it doesn’t allow for as much control.

What to Consider When Choosing a Website Design

With so many similarities between these three types of design, how do you know which is best? In today’s business world, a person’s website might be the first point of contact that a consumer has with your product, business, and/or brand. This means that if the user experience is poor, it doesn’t leave a good impression to continue the business-to-consumer relationship. That’s why when deciding on which design is the best fit, your audience is the most important factor. Who’s viewing your site? Who do you want to view your site? And, what kind of device are they viewing your site on? These are some of the questions that you and your team need to analyze and then strategize for when developing a new site or altering your current one.

This information can be found through Google Analytics or even through basic focus group testing. If your analytics show a high bounce rate, your site might be loading too slowly, may not be aesthetically pleasing, or it may not have resized to their screen size. This way you can see which areas cause a person to leave your site.

The second thing to consider is whether you will be building a brand new site or working with an existing site. Most new sites are being built with responsive design, which is advantageous, again because of the increase in mobile traffic. Older sites can still transition to mobile, but may best do so by choosing an adaptive design.

Third, it’s a good idea to project your goals. The time it takes to launch or re-launch a website depends on the amount of design time and optimization necessary to make your site fully functional across all mediums. It also requires the strength of a good development team who can code accordingly and across multiple layouts.

Then, of course, there’s the importance of considering how a site design will affect your search engine optimization goals. How much content will you be placing on the home page? How will the navigation be designed to benefit user experience? What resolution do images need to be? Will there be video?

No matter which design you choose, know that every designer will have a slightly different take on why responsive is better than adaptive or why fluid is equal to either of the two. The key goals to keep in mind are: desired functionality, adaptability to mobile, and the overall user experience.