Chapter 16 - Stuff You Should Know About

So there is a good chance you've been reading this entire book on a Windows machine. Not that there is anything wrong with that, but to be honest, the majority of devs I know work on Linux or Macs. I'm sure there is a way to do all of the stuff we're about to cover below on a Windows machine in one way or another, but my suggestion to you is that if you're on a Windows machine, download and install Linux (Ubuntu is a common distribution and is free) and it can live alongside your Windows. That way you will have Linux on your computer for all your dev needs without giving up MS Word.

If you have a Mac then you're good to go as is. Macs are Unix based and therefore already have most of the stuff you need.


The Terminal is that cool thing you see hackers use in film. Where they type random commands and the computer does crazy stuff. Only it's really not that crazy. If you have a Mac, I suggest downloading ITerm2 (IMO it is better than the built-in Terminal), and if you have Linux, the built-in Terminal should have all you need. Configure your Terminal to look just like that of a badass hacker (white or green font and black background) and you're good to go.

You can use your Terminal to do everything you can do from the GUI and in much simpler ways. The command to copy a file is cp, the command to delete a file is rm, the command to find some file is find. Those commands are just applications we simply run by typing their name. It is the equivalent of double-clicking them, just more intuitive. Those commands normally take arguments (just like our functions did before) and flags (preceded by dashes -). For example if I want to remove all the files in a directory called /Users/peleg/pron, I would type:

$ rm -rf /Users/peleg/pron/*

All that means is this: use the rm command and pass it the flags r and f. r stands for recursive and all it means is "call rm on all sub-directories as well (so we remove them too)". And f means force so the command removes directories that have files in them as well (the different behavior is to abort directory deletion when there are files in it) The only argument we had in our case was the path to the directory including the wildcard character * meaning "match all" to get all the files and directories inside the pron directory: /Users/peleg/pron/*

Looking for how to copy files from one of the computers in your network to another? Look it up! It's easy. Once you have the name of the command to do so, you could use the man command. The man command gives you the manual to how you can use other commands. So for example: man rm will give you all the deets you need to know for the rm command. If the man command just confuses you more, you could install (bro-pages)[] and use the bro command which just gives you direct examples instead of detailed explanations.

Now let's say you want to find and extract all of the email addresses in a directory called /Users/peleg/contacts on your computer which contains a bunch of text files with your friends' contact info. We could use the grep command to do so:

$ grep -ronE '\[email protected]\w+\.\w+' /Users/peleg/contacts/

This is a bit more complex, but just to pique your interest, let's try to see what we have here:

Try it for yourself! Create a directory called contacts and populate it with a bunch of text files with some random text and hide some emails inside of it.

$ cd ~/          # Change directory to your home directory
$ pwd            # See what directory we are in
$ mkdir contacts # Create a "contacts" directory
$ cd contacts    # Change directory to "contacts"
$ touch file.txt # Create an empty text file
$ open file.txt  # Open the file in the default app for txt files

Now enter a bunch of random text in your text file and hide a few email addresses in it. The only requirement is for you to separate the email addresses from the rest of the text with a non-word character (meaning space, period, comma, new line, etc.).

And then execute our grep command:

$ grep -ronE '\[email protected]\w+\.\w+' ./

The period (./) we pass in to grep as the second argument simply means "search in the current directory" which happens to be ~/contacts if you followed the instructions above.

Hit Enter, and you should get yourself a list of all the email addresses from inside your file (or files if you created more than one)!

Now what if you wanna save this output to some file? Easy:

$ grep -ronE '\[email protected]\w+\.\w+' ./ > output.txt

The > (angle bracket) redirects the output of our grep command to the output.txt file (it will create it if it doesn't exist).

So as you can see, your Terminal, along with the built-in commands, is a pretty powerful tool. So next time you need to do something on a large scale like parsing emails out of a bunch of files and saving them to a CSV file or what not, put the time required to learn how to do it from your Terminal. At first it may be faster and easier to just do it by hand, but it's a worthwhile investment which will serve you well.

Git (is not GitHub)

Now Git is a bit advanced, and you are not expected to use it right away, but it is good that you are exposed to what it is so later when you say "Gawd, I wish I had a tool which could keep track of all the changes I make in my code so that I could revert changes easily," you'll know to look up Git.

Git is what's called a version control management tool, and all it really is is a command line application which allows you to keep track of changes you make to files. For example, if I were to change something in our Weather App that I later learn introduced a bug, I could easily revert to the commit (like a snapshot in history) before that. This way I have a lot less to worry about.

There are other version control tools out there like Mercurial, or Subversion, but they aren't as common (at least at startups in the US) and I don't know enough about them so I should probably stop here.


Well now you're writing code. So we need to make it more convenient for you to do so. Sure you can write code in your built-in, run of the mill, Notepad/Textmate editor like we've done so far. But that will soon become harder on you as it won't check for simple syntax mistakes you may have, it won't highlight code syntax for you to make for easy debugging, and it won't have all the nifty plugins that make software development a breeze (like find and replace, word completion, find function declarations, etc.)

IDE vs text editor

Your options as far as the right tool for writing code are either an IDE or a simpler text editor.

IDE stands for Integrated Development Environment and is normally used with compiled languages. IDEs offer a lot more than just a text editor and can help you with debugging your code, compiling it directly from within the editor, and much more. The reason they are used mostly with compiled languages, is that compiling an application has some more overhead than non-compiled, interpreted languages do. For example, with a compiled language, you would have to compile the entire application before you'd know if there are any errors or not. Whereas an interpreted language would just run w/out checking anything before it would hit the error at runtime.

So IDEs make it a lot easier for you to work with compiled languages. They check your code as you type. They tell you immediately if you have errors so you don't have to go through the entire process of compiling an app before discovering that you've just missed a semicolon.

The downside with IDEs is that they are heavy, use a lot of memory, and are very opinionated about the way you do things. Your alternative is just using a text editor.

Text editors are just that. They are your Notepad or Textmate, or they are a bit more advanced and include some features like syntax highlighting. Text editors are normally used with interpreted languages (or languages that are normally interpreted) like Ruby, JS, or Python and are a lot simpler to debug. Why? Because you can just run the application, w/out having to compile it, in order to see if there's an error. For example, if you think about our Weather App, you could very quickly just run it and see if it has any errors. You wouldn't have to compile and wait to see if it errors, which could take some time on a computer with limited resources.

What editor you choose depends vastly on the technology you're going to be developing for. If you make native apps for iPhone, most people use Apple's Xcode. It is a full-blown IDE that was meant for that kind of application development. It will show you where you are wrong immediately and it will allow you to compile ObjC or Swift code directly from within it.

If you want to do Java, you should probably check out the IDEs Eclipse or IntelliJ. They are pretty common in that sphere.

Alternatively, if you're planning on developing with an interpreted language (for web or anything else), I would suggest ditching the IDE for it's unnecessarily clumsy, in my opinion. Instead, you can pick up a buffed-up text editor like Sublime Text, Atom, Emacs, or Vim (last two are more advanced) and customize it to your likings.

Personally I use Vim. I used to work with Sublime (which was great), but decided it was worth it to learn how to use Vim. I don't think you should do so right away, as you have more important things to waste your brain power on ATM, but keep it in mind for the future. Vim offers you such advanced keyboard shortcuts and scripting that it makes typing anything a breeze. Also, Vim can be run directly from your Terminal so you can use it from most servers without having to run any GUI application. I am writing this book in Vim!

A new alternative which is great for beginners is a web-based IDE like Cloud9 ( It allows you to write JS, Ruby, or other code directly from your browser and run it on their VMs (Virtual Machine). That means you can access your code from anywhere as long as you have an Internet connection. It also means you don't have to set up your environment (installing stuff like Ruby or Node, and running servers locally) before developing your application, Cloud9 sets it all up for you, in the cloud!

Table of Contents