Posts

The Best Text Editors for Beginners

What text editor should I use?

What is a text editor, and why does it matter which one I use?

Text editors are programs that type simple text without the sort of formatting a word processor will so rudely slip in. No comic sans, no forced margins, no line breaks (I just tested this with a line of Python, and yep, I can make a line of code that will wrap around the planet if I want). A text editor is just you and your ASCII, absent bells, whistles, or beauty.

As you start out programming, you’ll quickly find your text editor is your best friend. Or your frenemy, depending on how coding is going that day. It’s essential to start figuring out which text editor works best for you. Like most tools, the basics of every text editor are the same. They all have a place to interface text (because, of course), most feature syntax-based color coding, virtually all feature hot keys and intuitive text features to lighten the load of a long coding project.

As you start out programming, you’ll quickly find your text editor is your best friend. Or your frenemy, depending on how coding is going that day. It’s essential to start figuring out which text editor works best for you.

There are already plenty of blog posts on what kinds of text editors to use, but I happen to be retaking One Month’s Python course at the moment, and felt like this would be a good opportunity to test out a few different ones (despite the fact that Eric expressly tells us to work with Sublime Text; we students are rebels).

I’ll mostly be looking at Mac-based editors (or cross-platform editors that work on Mac), because that’s the type of machine I’m working on. When you’re starting out coding, it’s also best to give yourself a little flexibility in terms of the tools you use; you don’t want to limit yourself to working on one platform because you never know where you’ll be working.

I’m also going to try to focus on editors that will be good for beginners. This is because that’s where I am with coding (and that’s where we all need to start).

(A brief aside before we start: I am ethically obligated by the higher order or people who write about text editors to point out at this point that text editors aren’t the same as IDEs or Integrated Development Environments. IDEs are more like Swiss Army Knives, whereas text editors are like screwdrivers. Word screwdrivers. A couple of the text editors we look at will tread the boundary between these.)

Sublime Text: $70 (or unlimited free trial)

This is the first editor I wrote code in, and there’s a soft spot in my heart for it. It passes what I think is the most essential test for any text editor, which is that it’s intuitive to start using. You just open up a file as you would with any interface, and can begin coding.

The extra features with it are pretty bog standard things like code folding. What’s code folding, I wondered, can I make code origami? Imagine my disappointment when I found out it just hides lines of code when I’m not actively working on them. Useful, but no cranes for me.). I like the dive in and begin aspects of Sublime Text. If you’re used to typing in a word processor, Sublime Text is a pretty solid introductory text editor.

If you’re used to typing in a word processor, Sublime Text is a pretty solid introductory text editor.

There’s also an open secret with Sublime Text: While the program isn’t free, it comes with an unlimited trial period. You should absolutely buy a copy if you love using it, but I like that there’s no deadline bearing down on me to make that decision.

VIM: Free

I’ll be honest: Vim scares the crap out of me. If Sublime Text is the cozy programming home I feel comfortable putting my feet up in, Vim is an enormous mansion set high atop a hill with a heavy iron gate between it and me. even downloading and installing Vim is fairly difficult, which makes it a tough text editor to touch if you’re new to programming.

That’s not to say that Vim is bad — far from it. Vim is a great text editor; it’s free, heavily customizable, has a huge community of users and a long history of use. You can make Vim work the way you want it to. It is so useful, in fact, that it’s occasionally compared to an IDE, because it has tools aplenty. Vim just won’t hold your hand. In fact, it sort of slaps your hand away while shouting at you “Get up! Learn to walk on your own!”

If Sublime Text is the cozy programming home I feel comfortable putting my feet up in, Vim is an enormous mansion set high atop a hill with a heavy iron gate between it and me.

All those tools, all that customization means there’s a pretty steep learning curve, which makes it kind of a nonstarter for a beginning programmer. In fairness, Vim’s designers are up front about its difficulty; personally, I’ll save real play on this for when I’m writing more advanced code.

Coda: $99; One Week Trial

I really liked playing around with Coda. This is another tool that feels more like it’s leaning toward an IDE than a text editor; in fact, despite what they say on their website, I’d go so far as to call it an IDE. It’s heavy on features like a built in Terminal interface, SSH connectivity, controls for pushing code automatically to a hub. It’s not exactly bells and whistles-free, but a lot of the features are easy enough to figure out and are essential tools for developing a web app.

I’d go so far as to call Coda an IDE. It’s not exactly bells and whistles-free, but a lot of the features are easy enough to figure out and are essential tools for developing a web app.

My favorite aspect of Coda, which you won’t find in almost any text editor, is a preview button that lets you see what the code you’re writing will look like live. This is a major time saver compared to pushing code, running it on a server, failing, pushing again, etc.

There’s definitely a bit of a learning curve for using Coda. So, if you’re just looking for a tool that lets you dive in and start writing some code, this is probably not the way to go. But with a little experimenting, it has some pretty powerful features you’ll want anyway. Worth the investment if you’re an intermediate coder who’s going to be sticking with it for a while.

Atom: Free

Basically, it’s like getting a knife that you can later turn into a scalpel and then into a LASIK tool.

Atom is a groovy text editor to work with. Its interface has a similar feel to Sublime Text’s, but the iconography of their file structure is ever so slightly more intuitive. It also has a convenient hotkey to list all available command functions. What makes Atom so cool to use, though, is that it’s open source, completely (and easily) hackable, and entirely user friendly. There isn’t any learning curve with it. You can dive right in and start entering code — but as you become more advanced as a programmer, you can make Atom a more complex text editor for your needs. Basically, it’s like getting a knife that you can later turn into a scalpel and then into a LASIK tool.

So which of these is the best?

From my perspective, which is to say the perspective of a novice, a good text editor is one that allows me to dive in and start coding, while also giving me room to grow and get more experience as part of a broader community. It’s what I like to call the bike shop problem. When you walk into a bike shop for the first time, odds are pretty good it’ll be a bit intimidating with all the experts walking around talking the talk. Odds are good you just want to get on a bike and go. The rest of the stuff you can learn later as you become more of an expert, but if you need all that expertise just to get on the bike, you’ll never get started.

It’s what I like to call the bike shop problem. When you walk into a bike shop for the first time, it’ll be intimidating with all the experts walking around talking the talk. If you need all that expertise just to get on the bike, you’ll never get started.

With this criteria, Atom is the best program on this list for letting you get started. It also gives you room to grow. Atom has a large community of users, just like a more intimidating program like Vim, but it also gives me room to start working with it right away. It’s intuitive and easy-to-use, but also expansive and flexible to the needs of its programmer.

To me, this is a great feature of any program. Especially one that I know I need to use as a long-term tool. Part of the frustration of working with a tool is the FOMO of it all. Am I really getting the maximum functionality out of my text editor? Is this the best possible tool I could be using? Atom clears that up by letting me build from a simple text editor to a more complex one.

Takeaway recommendation: if you’re a beginner, start with Sublime as your text editor. The unlimited trial is free, it’s easy to learn, and you can use it across multiple operating systems.

What is iOS Development?

Key Takeaways

  • Swift is the language used to make apps for iPhone, iPad, and Mac OSX (desktop) apps.
  • Why Swift? Well, You don’t really have a choice. Apple decided that part for you. The rule is: if you want to make an iPhone app, and get it into the Apple Store, then you’re going to have to develop it using Apple’s Swift programming language.
  • Before you start learning Swift, ask yourself: do you really need your project to be an iPhone app? If not, a prototyping tool might be the quickest way for you to develop a Minimum Viable Product. My first choice for iPhone prototyping would be Keynotopia, but also there are some great questions to check out over at Quora.

What is iOS? How to Learn Get Started Today

  1. Read Swift vs. Objective-C (5 minutes)
  2. Download Xcode from Apple’s App Store. Note: you’ll need an Apple computer to develop iOS apps. Windows won’t work (20 minutes).
  3. Browse the additional resources below, and choose the one that’s best for your next step!

Additional Resources to Keep You Learning

  1. “The Swift Programming Language” (iBook): published by Apple
  2. “Start Developing iOS Apps Today” (website): some programming experience will be helpful to understand these two resources.
  3. One Month YouTube tutorials for iOS

What is Web Security?

Key Takeaways

Web security is 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. They’re an international nonprofit that puts out lots of documentation, events, news, and web security projects. This is 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.  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. This will significantly lower the risk and cost associated with deploying new applications.

Front-end vs. Back-end Developers

.

Do you have an interest in programming, website development, and application development? If so, then becoming a developer is a career move you may want to research. When it comes to developers, there are typically two groups to choose from: front-end developers and back-end developers. In this post, we’re going to look at the differences of each in terms of description, skills, programming languages, and earnings to help you in your decision.

Front-end vs. Back-end Developers

If you are either wondering what the difference is between a front-end developer and a back-end developer, or looking for an explanation that you can easily give your friends when they ask you what you do, here are a few ways of describing the two.

  • Think of your head. Your face would be the front-end that interacts with others using input from the eyes, ears, and nose and producing output through the mouth. Your brain would be the back-end where information from your eyes, ears, and nose is stored and where information to the mouth is sent from.
  • Think of your house. Things like the interior design, furniture, shingles, siding, windows, doors, etc. would be the front-end. The framing, insulation, beams, and foundation would be the back-end.
  • Think of your car. The engine, computer system, oil, gas, lights, etc. are a part of the back-end. Everything else is the front-end.

A front-end developer is someone who creates the front-end of a website or other application. Or the part that users engage with to get to the information in the back-end. A back-end developer is someone who creates the storage and output capabilities of said information.

Let’s say that a client wanted a custom WordPress website developed for their business. The front-end developer would work on the website that is shown to visitors on the web, plus anything that the client would see and use in their day-to-day business. This includes the WordPress theme itself and any customizations needed to the WordPress admin panel / dashboard.

The back-end developer, on the other hand, would work on optimizing the database, customizing the WordPress software itself, and creating the plugins needed to create the overall functionality of the client website, whether it is a simple blog or an ecommerce store.

Skills

So what kind of skills does a front-end developer need versus a back-end developer? Both are required to do some heavy lifting in the programming department. But front-end developers need a better eye for user interface design and visual appeal than back-end developers.

While front-end developers are not always the actual designers for the user interface of a website or application, they do have to know how to make the user interface aesthetically pleasing as well as functional. They will likely work closely with a designer if they are not designing the website or application themselves.

Additional skills that front-end website developers will need beyond programming include the ability to wireframe a website layout and design, create website designs in PSD or take PSD designs and turn them into functional websites, and deploy the website to the customer or employer’s hosting company.

Back-end developers, on the other hand, have little to do with the design of a website or application. Their job is to focus on what makes everything work behind the scenes. Hence, if you are not interested in design, then back-end development should be your focus.

Additional back-end developers skills needed beyond programming include the ability to integrate the user interface created by front-end developers with the server side logic, creating reusable code and libraries for future use, application optimization for speed and scalability, design of data storage solutions, and implementation of data security.

If you know what type of developer you want to be, the best way to determine the skills you will need is to look at profiles of other freelancer developers or job listings for specific types of developers.

Browse several different freelancer profiles or job listings (preferably ones that are at the income rate you desire to make).  There you can see the full range of skills. This is what you should be developing or highlighting when you approach customers or employers for work.

Programming Languages

Want to base your decision on whether you should be a front-end developer or back-end developer based on the programming languages you will need to be proficient in? Here’s what you need to know.

Front-end: There are only three front-end languages HTML, CSS, jQuery and Javascript.

Back-end developers need to be proficient in programming languages that render on the server side of a website or application. The most popular back-end programming languages are PHP, Ruby, Python, Ruby on Rails and Java. Others include .NET, C, and Perl. Back-end developers also need to proficient in working with databases like MySQL, Oracle, and SQL Server.

If you don’t have experience in any of these just yet, you may want to start by taking some beginner courses in a few different programming languages to see which ones you are most comfortable working with. Alternatively, you may want to determine what types of projects you would ultimately want to work on, then find out what would be necessary to know to work on them.

Education

Fortunately, there are lots of different ways to learn both front-end and back-end skills and programming languages. The route you take in education may depend on the type of employment you seek. If you want to work for a company full-time, you may want to browse job listings to see the requirements they have. Some will require specific degrees from universities to apply.

If you want to be a freelancer or start your own company, you may be able to forgo the format university route and self-educate through online courses. So long as you can deliver proven, you do not need to show a degree to make a living. If you are starting completely from scratch, you may need to develop a few projects on your own. This way your portfolio can demonstrate your experience to your first couple of clients. A strong portfolio is especially important for front-end developers.

Earnings

What you will make as a developer will depend on a lot of factors. These include the following:

  • Whether you are a freelance developer, contractor, part time, or full time employee.
  • Your specialties as a developer — the programming languages you are most proficient in, the tools you are most familiar with, etc.
  • Whether you are able to interact directly with the customer, have project management skills, and are able to manage a team.
  • If you are a freelance developer or contractor, the network you use to offer your services through.
  • Where you live and where you work from (telecommute or in-house).
  • How much education you have in your specialty.
  • The amount of experience you have working in your field.
  • How long you have worked at a particular company as a part time or full time employee.

Salary

While there are averages you can expect in terms of salary, all of the above will factor in on whether your earnings are closer to the lower end or upper end of the echelon. Indeed.com, for example, shows the following as average earnings for specific types of full time back-end developers. Note that some of the related job titles cross over into front-end development for comparison.

You can compare these to averages for full time front-end developers. Note that some of the related job titles cross over into back-end development for comparison purposes.

As you can see, the salaries can vary dramatically based on your experience (noted by junior, lead, and senior titles) and based on your specialties. Specialties also have an effect on salary, as noted by the difference in salary between a senior Javascript web developer who outearns the senior front-end developer.

For freelancers and contractors, what you will earn will be affected by the network you market yourself through, your reviews and ratings on that network, and your competition. Here’s a quick look at what the top back-end developers are charging on networks like UpWork (formerly oDesk).

These networks appeal to customers who are looking for developers who meet their budgets. They allow customers to find developers who charge anywhere from $10 per hour and to over $100 per hour. If you market yourself on these networks, you will have to compete with people across the gamut in terms of rates. Increasing what you charge on these networks will require you to demonstrate your skills. Through testing on the networks themselves, having a complete portfolio, and having great ratings and reviews.

Full Stack Developers

People who have skill in both front-end and back-end development are often referred to as full stack developers. In other words, they have a full range of skills that can be applied to the user interface and everything that makes it work in the background.

Some people consider a full stack developer not as good as a front-end or back-end developer. Often refer to the saying, “Jack of all trades, master of none.” But it’s also worth noting that the full phrase is “Jack of all trades, master of none, though oftentimes better than a master of one.”

As a developer, having both front-end and back-end proficiency means more opportunities. You will be able to apply to more contract, part time, or full time employment positions. As a freelancer, you will be able to take on more projects without being limited to front-end only or back-end only.

From the customer or employer perspective, you will be able to understand projects as a whole. Both how it needs to work for the user and how it needs to work in the background. You will give them one point of contact for all of their needs. And you will be able to support them when things go wrong on either side. This makes you even more valuable over the long term.

Demand for both front-end developers and back-end developers is continuously growing. Therefore, choosing either can help you create the career or business you have always wanted. Be sure to explore both worlds of development to determine which one is the best fit for you!

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?

Becoming a translator

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.

Start learning now!

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.

If you want me to help you find exactly which skills to start learning, our programming profiler is just the thing.

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).

Post

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
  • It is made up of requests and responses
  • Its’ 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 , ways of solving the same problem. But rather than that being a weakness of Ruby, the flexibility of the language is an incredible strength 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 need to keep going?

Flexibility=Creativity

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 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. This is 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. It is also 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.

3 Ways to Know If A Developer Is Good

If you don’t necessarily have a technical background and you’re thinking about bringing in a developer, how do you assess them? How do you even know if they have the very particular set of skills your site or application needs?

On this Founder Friday, Mattan and Chris tackle how to win devs, and make an exciting announcement for all you geeks on the comic book side of the spectrum.

Programming is its own language. Or rather, it’s a language with lots and lots and lots of different languages that different developers speak. But as a non-speaker, there are several ways you can break through all the C++ and CSS to get an honest, accurate picture of a potential developer.

1: Master The Phrasebook

The hard truth is if you’re hiring someone to code for you, you should learn at least a little bit of code. That takes time, and some effort, but it’s worth it for a couple of reasons.

The first is that you need to know what you’re talking about, at least at the surface level, because that’s going to inspire confidence and trust in your developer that they’re working for someone who knows what they’re doing; that they’re working for someone who values their contribution.

But beyond that, you need to, at least on the surface level, know what they’re talking about, and the basics of the argument they’re making for themselves. There are many places all over the internet you can get access to an hour of code, just to start you off.

But rather than leaning only a little bit of HTML, or a little bit of Java, the best play is for you to develop (ha) a holistic sense of what code is and how it’s useful to your business/startup/site. More about that at the bottom.

2: Check The Portfolio

It’s not your job to know everything, however. The best lens into a developer’s skills and experience is through a portfolio of their work.

Whether it’s just screenshots or whether they’re able to bring in an application they worked on, actually being able to see examples of their work can give you a sense of what they’re capable of.

But you can’t just look at webpage. You need to be strategic in how you’re ask a potential developer to describe their experience, and drill down on their portfolios. Find out what their personal contributions were. Push for the reasoning behind why they make that choice and not a different one. Get them to describe how they worked on their projects, whether it was remote and freelance or leading a team.

Look not only for their expertise, but how engaged they are in telling those stories. It’s worth taking at least 5 minutes on each example to really get a candidate talking. People will reveal themselves once they’re put in the position of having to relate their experience.

You want someone who’s thoughtful and excited about what they do, not disengaged, condescending to a non-programmer, or talking over your head.

3: Ask For Recommendations — From the Candidate

The other way to get a thorough, but thoroughly non-technical, sense of a good developer is to ask for recommendations. Before you make a call or shoot off an email, ask the candidate what they think their references are going to say.

Before you actually call and contact the references, ask the candidate what they think their references will say. This will tell you a lot.

Again, pay attention to the language they use — whether they’re hesistant or dismissive or really eager to talk about their old team.

Don’t worry about the imagined imposition of reaching out to someone who’s worked with a candidate. It isn’t one.

Talking to someone on that person’s team can give you a whole other window into not only what that person’s skills are, but how effective they are in accomplishing projects and collaborating.

Whatever you need a developer for, you’re going to need them to keep you in the loop. So, just keep the “no jerks” rule in mind. No jerks. Don’t do it. You want someone on your team to be on your team.

And lastly… Should you require a developer test or not? Some specific questions to ask if you do:

There are a few additional ways to judge a developer.

A trial period, or beginning a working relationship with someone on a project basis, is almost never a bad idea. It gives you a chance to test their ability to contribute effectively to your team — and see the progress they make with their code — without the full commitment of a salary and benefits.

Ask them what their experience with and how open they are to regular check-ins. Again, good developers won’t just be able to code. They’ll also be open to feedback and willing to present their ideas to non-technical teammates.

Some specific questions that can help you gauge a developer: ask them what their favorite stack is, what language do they like to code in and why? Do they do any testing, and if so, what kind of system? Do they use version control, like Git? Just because someone’s been coding for a while, that doesn’t mean they’re good.

Look for someone who’s open to trying new things, and who seems like they can adapt to the constantly changing methods and technology.

It’s really that willingness to communicate, and the ability to explain themselves and be held accountable, which separates good developers from just developers.

Even if you only need some one-off help, you’re bringing someone into your team’s locker room. It’s not enough that they can code. They also have to communicate.