Posts

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.

Swift Tutorial: Optionals for Beginners

Swift Optionals

Optionals are a powerful feature of the Swift programming language, but they can be difficult to understand and use effectively. Let’s review the essentials.

At a high level, what are Optionals?

Let’s say a mutual friend is throwing a Halloween party. The invitation outlines the pertinent details (e.g. time and location) and among other things it says, “bring a beverage, costumes optional.” Now if we wanted to represent this party and its guests in code, we might create a Party object and a Guest object, and we might translate the above details into properties on these classes. However, in order to accurately represent this Halloween party we want to express the fact that costumes are optional. We do this like so:

class Party{var time: NSDatevar location: CGPointvar guests: Array // …} class Guest {var beverage: String // Each guest must have a beveragevar costume: String? // Each guest can choose to come in costume or plain clothes (i.e. costumes optional)// …}

view rawswift-optionals-1.swift hosted with ❤ by GitHub

In Swift, the ? is how we designate a variable as Optional. And this just means that it’s okay for the variable to have a value costume = "Frankenstein" or to not have a value costume = nil. In contrast, every guest must have a beverage, this is expressed by the absence of a ?, and the compiler will enforce this for us.

A little background

Optionals work in tandem with variables. A variable is a construct that we use to hold onto a piece of data. At a minimum we usually give a variable a name, type and value.

// Here we explicitly specify the typevar beverage: String = “Leffe” // But the type can also be inferred from the fact that we’re assigning it a String valuevar name = “Leffe”

view rawswift-optionals-2.swift hosted with ❤ by GitHub

vars and lets

Swift offers us two distinctly different kinds of variables: vars and lets. In order to understand Optionals we must first understand vars and lets.

The primary distinction between vars and lets is that vars are mutable and lets are immutable. In other words, we can change the value of a var as many times as we want, but once we set the value of a let, we can never change it. Let’s look at some examples.

// varsvar mutableBeverage = “Leffe”println(mutableBeverage) // “Leffe”mutableBeverage = “Bud”println(mutableBeverage) // “Bud”mutableBeverage = mutableBeverage + “weiser”println(mutableBeverage) // “Budweiser”// letslet immutableBeverage = “Bud”println(immutableBeverage) // “Bud”immutableBeverage = “Leffe” // Compiler errorimmutableBeverage = immutableBeverage + “weiser” // Compiler error

view rawswift-optionals-3.swift hosted with ❤ by GitHub

Test these out in a Swift Playground and you’ll see that the compiler enforces these mutability rules for us. And in doing so it forces us to be explicit about our intentions. If we used vars alone we’d be wandering into a lawless land. Mad Max territory. Variables that we intend to be immutable might unintentionally be mutated. But in this day and age we can elect to use vars and lets where appropriate, and proceed with confidence.

Something and Nothing

Optionals add a layer of complexity to vars and lets. They modify vars and lets to make a distinction between variables whose value can be either something or nothing, and variables whose value can be something but never nothing. In the context of Swift, nothing is expressed with nil, the absence of a value. Let’s look at some examples.

// Non-optional varsvar mutableBeverage = “Leffe”println(mutableBeverage) // “Leffe”mutableBeverage = “Bud”println(mutableBeverage) // “Bud”mutableBeverage = mutableBeverage + “weiser”println(mutableBeverage) // “Budweiser”mutableBeverage = nil // Compiler error// Optional varsvar mutableCostume: String? = “Dracula”println(mutableCostume) // Optional(“Dracula”)mutableCostume = “Frankenstein”println(mutableCostume) // Optional(“Frankenstein”)mutableCostume = “Bride of “ + mutableCostume!println(mutableCostume) // Optional(“Bride of Frankenstein”)mutableCostume = nil // nil// Non-optional letslet immutableBeverage = “Bud”println(immutableBeverage) // “Bud”immutableBeverage = “Leffe” // Compiler errorimmutableBeverage = immutableBeverage + “weiser” // Compiler errorimmutableBeverage = nil // Compiler error// Optional letslet immutableCostume: String? = “Dracula”println(immutableCostume) // Optional(“Dracula”)immutableCostume = “Frankenstein” // Compiler errorimmutableCostume = “Bride of “ + immutableName! // Compiler errorimmutableCostume = nil // Compiler errorlet anotherCostume: String? = nil println(anotherCostume) // nil

view rawswift-optionals-4.swift hosted with ❤ by GitHub

Note the addition of a question mark to our variable declaration. The question mark signifies that the variable is an Optional, a variable that can be something (a value) or nothing (nil). Without the question mark these variables can never be nil. Note that declaring a variable as Optional does not effect its mutability. vars remain mutable and letsremain immutable.

Also note the use of an exclamation mark in select locations. The exclamation mark is a heavy-handed way to unwrapi.e. gain access to the value that an optional variable holds.

Unwrapping Optionals

Allowing variables to be either something or nothing injects risk into our programs. If we assume a variable is something and it turns out to be nothing, our program might behave unpredictably or worse yet crash. To mitigate this risk and avoid having to make assumptions, we want to know definitively whether a variable is something or nothing before working with it. Anyone who has worked with Objective-c is familiar with this upfront runtime check.

NSString *costume = @”Dracula”; // …if (costume == nil) {// Do something for this plain clothes guest} else {// Do something else for this costumed guest}

view rawswift-optionals-5.swift hosted with ❤ by GitHub

Swift Optionals allow this check to happen at compile-time. If we attempt to use an optional variable withoutunwrapping it, the compiler will throw an error instructing us to first unwrap the value. Which means that the compiler will never let us use an optional value without first being certain that it is something or nothing.

We can safely unwrap optionals like this:

var costume: String? = “Werewolf”println(costume) // Optional(“Werewolf”)costume = costume + “ dressed as Michael J Fox” // Compiler Errorif let something = costume {// The value is not nil, use it with confidencesomething = something + “ dressed as Michael J Fox”println(something) // “Werewolf dressed as Michael J Fox”} else {// The value is nil}

view rawswift-optionals-6.swift hosted with ❤ by GitHub

A heavy-handed way to unwrap an optional is to make use of the exclamation mark. This is called force unwrapping:

var costume: String? = “Werewolf”println(costume) // Optional(“Werewolf”)costume = costume! + “ dressed as Michael J Fox” println(costume) // Optional(“Werewolf dressed as Michael J Fox”)

view rawswift-optionals-7.swift hosted with ❤ by GitHub

The former is greatly preferred to the latter. By force unwrapping the optional we’re asserting that we’re positive the variable is not nil. But if we’re wrong our program will crash. Force unwrapping puts the onus back on us humans to keep track of what is nil and what is not, and in doing so brings all of the risk and assumptions back into our code.

Optionals in Practice

So when do we use Optionals? We use Optionals when a nil value is meaningful.

Consider the case of a model object in our iOS app that represents a video on our server. If the video’s image_urlproperty is non-nil we know it has a thumbnail image that we can use. And if it’s nil we know it doesn’t.

Or consider the case of an NSError object passed as an argument to a network call’s completion handler. Not every network call will return an error, so it makes sense for this error object to be Optional.

On the other hand, our program might make use of a Person object. And it might require that every Person have anage. In this scenario age would be non-optional, passed into the Person constructor and never allowed to be nil.

In Summary

In Swift, we have four different kinds of variables at our disposal:

  • vars (mutable, never nil)
  • Optional vars (mutable, nilable)
  • lets (immutable, never nil)
  • Optional lets (immutable, nilable)

This simple toolset empowers us to write clearer code and more stable programs. And it allows the compiler to be a better partner in helping us achieve these goals.

Coding Challenge: 3 Ways to Make Sure You Finish Every Course You Start

Listen, I’ll be the first to admit I can be incredibly lazy.

If you give me five minutes to finish a project, I’ll do it in exactly five minutes.

But if you give me five months to finish the same project, I’ll take the full five months!

I’m not alone in this. Most people are not self-starters for everything they do. But people do finish certain things. Most people finish high school. Most people finish college classes. But other things we don’t finish.

Why is that? These are things that can get challenging at times, and make you wanna go:

However… I believe I’ve identified the reason for most people finishing. It’s these three things:

Social Pressure
+
Financial Pressure
+
Super Clear Goals

If you have these three things in place, there’s an enormously large chance you will finish something.

For example, if you were enrolled in some college classes, here’s the breakdown of what keeps you going:

Social Pressure:

You are EXPECTED to finish the class because your parents, your professor, your friends all expect you to. It would be embarrassing and sort of shameful to not finish. So even when things get tough, you don’t just quit… you push through.

Financial Pressure:

Someone is paying for this! Maybe it’s your parents, maybe it’s you… but someone is shelling out money for you to learn, so you have to make sure you get your value out of it. People value things far more when they pay for them.

Super Clear Goals:

This one is a huge. By simply having an exact start date, check in times, and end date… you are far more likely to finish something.

In a college class the professor will tell you:

  • WHEN the first day of class is, and the exact time.
  • WHEN the quiz is.
  • WHEN the test is, and when it takes place.
  • WHEN the final exam is, and when it takes place.

These are all super clear goals you need to hit, or else suffer in some way.

However when people undertake something like One Month Rails, they make no specific end dates, forget to add in accountability, and maybe let it slide for a while. Meaning they don’t have all three elements for completion:

  • Social Pressure
  • Financial Pressure
  • Super Clear Goals

Without these three elements, most people won’t get things done! And if your goal is to learn rails, then you need to set yourself up for success.

So how does this help us learn from One Month?

Well, I originally started One Month Rails with no luck. I actually got to Video 2 then stopped because I had other stuff happening.

(In my real life I teach people how to become copywriters, which means I’m by no means a natural coder. It also means I’ve got TONS OF OTHER THINGS that constantly require my attention.)

You probably do too.

So when I get stuck on a video explaining how to upload to GitHub, or push to Heroku, and something goes wrong… I’d immediately give up!

So let’s apply these three factors for success and create our own Coding Challenge!

This is something fun you can do with your friends — here’s how you can create your own coding challenge!

1: Social Pressure

To create social pressure you need to involve some friends. This means you can go to Facebook and type it in real quick that you want to do a Coding Challenge, like this:

You can invite people from your school, family members, blog readers, whoever. I invited my friends and email list from my copywriting business. I got a total of 29 people who signed up.

Because of those 29 people, I now felt socially pressured to finish the course on time.

I also linked them to a Google Spreadsheet where they could enter their name and track daily progress like this:

So now there’s a tracking chart we can all use to publicly keep each other accountable.

The next step was communicating with each other, which was simply done through a free Slack chat group. It was pretty simple, and people could ask questions or publicly rouse each other if we were falling behind (people were cool with it).

2: FINANCIAL PRESSURE

The financial pressure comes from when people signup to One Month Rails. Of course you have to pay some money, so you now have skin in the game!

People grumble and moan about paying for stuff… but people value things far more when they pay for them.

One of the crazy things about this challenge was that I sent people who joined a referral link from One Month. You can signup for the referral program here: http://refer.onemonth.com

I actually made over $1,000 from the people I signed up! That was a bonus side-effect of the challenge ($1,082 to be precise):

I also charged people from my email list $100 to join the challenge. This resulted in more extra income (29 people X $100 = $2,900).

Making money was never an intent for this challenge, but it sure was a nice little bonus.

3: SUPER CLEAR GOALS

I looked at the One Month Rails schedule, and realized it was exactly 30 days.

So I set the date of the challenge as April 1st — April 30th. Exactly 30 days.

I decided that dedicating just one hour a day to learning Ruby On Rails would be doable. In fact it ended up being less than that, because some of the lessons can be completed in a few minutes.

So now everything was in place!

Social Pressure : Friends and others had joined the challenge. We had a tracking document. We had a chat group.

+

Financial Pressure : Everyone paid for One Month Rails.

+

Super Clear Goals: The starting date would be April 1st. The ending date would be April 30th.

And guess what… I ACTUALLY FINISHED IT ON APRIL 30th!!!

I had successfully built an app called NevTrest (like Pintrest) that actually worked! You can even upload Pins and Photos and Descriptions.

Even though it was pretty basic, I was immensely proud 🙂

And of course a lot of the people who did The Coding Challenge with me finished the course too. Check out one of the members emails to me after:

Hi Neville,

I got through the Coding Challenge last month. Thanks for putting it together. I’d been meaning to learn RoR for some time, but until the Challenge I kept putting it off. While I’m no expert yet, I feel like last month gave me a good foundation. Thanks again. — John Y.

Anyhow, I sincerely hope you take this advice to try and form your own Coding Challenge with your friends.

I sincerely think with the right mixture of Social Pressure, Financial Pressure, and Super Clear Goals you will set yourself up for success with One Month!

What is Web Security?

Key Takeaways

Web security means protecting your website from hackers before it gets broken into.

If you’re a web security expert, you have the following skills:

  • You know how to code.
  • Can review your code for vulnerabilities.
  • You help fix the vulnerabilities you find.

How to Learn Web Security Today

  1. Read about OWASP. It stands for Open Web Application Security Project, and they’re an international nonprofit that puts out lots of documentation, events, news, and web security projects — all in an effort to improve software security across the world. Start here: https://www.owasp.org/index.php/Main_Page (15 minutes).
  2. Read the OWASP Top 10 Vulnerabilities. This is a dense read. Here’s how to succeed in 5 minutes: browse through the list, and read it aloud. Think of it as jumping in over your head! This will plant a seed for getting you on the right path. Start here: https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet (5 minutes).
  3. One Month Web Security — By the end of One Month Web Security, you will be able to review your own applications for security issues and ensure the code is properly hardened against malicious attacks. You will also be able to design new applications with security in mind, significantly lowering the risk and cost associated with deploying new applications.