SYWTLTC: (AB) Chapter 2: Your Development Environment
Go here if you want the prolog and table of contents to the SYWTLTC series!
The largest difference between what you do in Code Combat and what you’ll be doing in the rest of these chapters is about developing on your local box. To do that, we’ll need to get a slew of tools set up.
For the most part, you can probably just install some off the shelf version of Python and get cracking. But these chapters are about proper engineering. This means, what do you need to learn to code complex systems in large teams. Simple scripts aren’t going to cut it – you’re going to need tooling.
Many of the tools below are how you build high-quality complex systems, and rarely are they taught in school! They’re always learned on the job, and people struggle with the problems that these tools solve – sometimes their entire career. Not you, you’re going to learn how to do things right, right from the beginning.
Shaving The Yak
This also will be an exercise in configuration and probably a little frustration. Every time someone starts a new job, they have to get the code building on their box – get all the right tools, libraries and everything else downloaded and configured in precisely the right way.
Every time you screw up your box, which is probably a few times a year as a coder, you might have to rebuild it from scratch. Which again, means configuration work. Every time you want to try out a new tool or library to see if it solves a problem you have, you’ll have configuration work. This isn’t covered in Code Combat, but it’s something that you’ll hit throughout your career as a coder.
Might as well jump in.
While this isn’t the only time this phenomenon occurs, it may be the first time it occurs in your coding career so you need to get used to this too: Yak Shaving.
Watch the above Gif. Seriously.
Yak shaving is when you set out to do a thing – you want to write a script that does X. And to do that, you need to install a library. To do that, you need to update your dependencies. To do that, you need to update your compiler. Before you know it, you’re shaving a yak and you’re not quite sure how you got that far down the rabbit hole.
In the following instructions, you’re almost sure to screw up something or run into a path I didn’t anticipate. You’ll have to attempt to find out what’s wrong and find a workaround that gets you to the end.
This will probably require some googling, which is good practice to figure out what to search for, as well as some experimentation. You may also want to read help documents on the sites I’ll be sending you.
As a last resort, if you can’t get a certain thing installed, contact your mentor – but don’t do that first. Use it as a challenge to see if you can get your environment working!
In addition to practicing your research skills, we’ll also begin challenging your project management skills. The key to successfully shaving a yak is to – when you’re stuck – remember the following options:
- Use google or other resources to see if others are having your issue
- Experiment to see if you can find a workaround
- Take the smallest steps possible from known working system to known working system
- Be willing to step backward – maybe the problem you’re trying to solve is impossible because you screwed up something earlier. Be willing to start over from scratch. (That means you need to know how to UNDO what you’ve previously DONE)
- Be willing to make compromises that ultimately get you to the end goal but maybe not using the same method or process you originally set out to do, or the method or process you thought you were supposed to follow.
Without further ado, please complete the following:
2. Install Anaconda
Anaconda is a great Python distribution – it comes with the runtime, the IPython replacement REPL, and virtually every library you might want.
Find it here
. Keep in mind the differences between Python 2.7 and 3.5 – some textbooks require 3.5, though your mentor may be familiar with another one. In future debugging, remember that material you’re using to debug may be designed for another version.
3. Introduction to IPython, the super Python REPL
Python can run .py files you’ve already written, but also works as a read-evaluate-print-loop interpreter if you don’t give it a file. This is what makes it look like an interactive calculator.
IPython wraps Python’s REPL with all sorts of nice bells and whistles and is the main REPL I use when doing Python. IPython comes with Anaconda. While I can’t supervise and make sure you always use IPython rather than the built in Python REPL, I’d highly advise you make the switch. If your mentor sees you using the old REPL when IPython is available, she’s given permission to give you a solid knock on the head with a cane.
Since it’s already installed, you’ll want to walk through the tutorial here
. In addition, watch this video here
– forgive the accent.
IPython has a feature called ‘Notebooks’ that you may find online in your googling. We won’t be using those right now.
4. Introduction to py.test, the awesome testing suite
Py.test is a really super convenient current best-of-breed testing tool we’ll use in our Python code. One thing I really like about it is it will automatically discover our tests – we simply write .py files, put the word ‘test’ in our function definitions, and py.test will find them, run them and report results.
Ignore the installation steps as you should have py.test already installed from Anaconda, but finish out this
For all future work, I may either give you a test case you need to pass or alternatively expect you to write tests for your code. Py.test makes it super easy to run these tests.
5. Introduction to pip, the Python Package manager
Programming is half algorithms/code, and half libraries. Code combat has focused a lot on the code side, so some of the library aspects of programming may seem unfamiliar to you. Don’t fret, it’s just a new vocabulary you’ll get in time.
Pip makes it very easy to install python libraries that are publically available. It comes bundled with Anaconda. We’re lucky that virtually every library you might need also
comes bundled with Anaconda, so you may not need to install one. Still, you should go through some pip examples (you’ll see some with the py.test install instructions) at least reading them since you don’t need to actually physically do them. Follow along here
The above also has good coverage of virtualenv. Read this too to be familiar with some of the hard parts of library based code (conflicts, versioning, etc). But again, you don’t actually have to do do this tutorial in your own console. Just read over it so you’re familiar with the lingo and problems, and moreover, so you’re confident enough in pip that you can install something in the future if you needed to.
The tutorial uses bash, the Linux, and Mac OSX shell, but windows shell is very similar at least in the use of pip.
6. Introduction to pdb/ipdb, the python debuggers
In addition to testing, debuggers are another fantastic tool to help speed you along in figuring out why your code won’t work.
One of the best patterns of work with a debugger, especially compatible with testing, is to use a trace or breakpoint in your code. Finish out this
tutorial on how to place breakpoints.
Testing can tell you ‘hey this test doesn’t pass!’, verbose testing can even tell you what exactly failed. But often you’ll have to put breakpoints either in your code or tests so that you can interactively explore the state of the program and see what’s wrong.
No debug print statements! Learn to use the debugger! Every breakpoint is worth a thousand print statements 🙂
7. Git and Github
Git is how you’ll be sharing code with your mentor from here on out. Some future tests will still involve pairing with your mentor. But we’re going to get more and more to the point of just communicating via code.
Sign up on Github
for an account.
You already have a GitHub username, so now it’s time to start using it to create code repositories, add files, and the rest. Finish out the appropriate tutorial below:
That will show you how to use the GUI (on Windows) and set up your SSH keys. SSH keys are similar to passwords in that they provide authentication between two computers talking to each other – but they’re far more secure.
Since git primarily command line based, you’ll want to finish out with this
to know how to set things up, commit, push, etc…, from the command line.
We’ll have two parts to the challenge for this chapter, a code part and a pairing part.
You’ll create a new repository and put a single .py file in there. That .py file will be a test py.test can run, and it should check that 1 equals 0. This test should fail and I should be able to clone this repository and immediately run the tests and see that it fails. I want you to have the following two lines in the test:
variable_1 = 1
variable_2 = 0
Then check that the two variables equal each other – they should not.
When you’re finished with the code test, pair with your mentor to demonstrate you can do the following tasks. Open that .py file from above, set a breakpoint below the setting of your variables but above the test. Interactively explore the value of the variables and show that they aren’t actually equal.
Then you’ll fix your test – set both variables equal to 1 – and run py.test and show that the tests now all pass.
Next, you’ll add this change to the repo and push it up so that your mentor can see it on Github.
Finally, I’ll want to see you use IPython to do the following:
- Navigate and list directories
- Tab completion
- Historical completion
- Use the ? and ?? commands, as well as the help and dir functions.