Learning Python part 4: Airport Challenge

My first-week challenge at Makers was to create an airport system using ruby over one weekend. It was tough when I first approached it but it was such a good project covering so many ideas of software design (albiet on a small scale) that I have borrowed it to learn Python.

This project involved a lot of ideas such as:

• Object oriented design (SRP, dependency injection, encapsulation)
• Test Driven Development
• Behaviour Driven Development
• Testing ideas (stubbing randomness, mocking)
• Refactoring (class extraction, encapsulation, DRY)
• Use of different types of syntax of the language
• Object interactions
• Dealing with exceptions
• Similar to technical tests offered by employers
• Use of Behaviour Driven Development, outside in testing, feature tests

I felt doing this in Python would be a good challenge to improve my command the language syntax and also strengthen my OO design and TDD. 

Here is my code.  https://github.com/hanfak/airport-python

You can look through my commits and see how I did each section of the tests and code for each user story.

A major issue was trying to stub randomness and create doubles with methods.

At first, I had issues with injecting the weather object in the airport class, so when Airport is instantiated I created a new weather object. Instead, I had to pass the Weather object as an argument in the airport's instance methods that required it. This resolved itself after some research, where I ended up injecting Weather into the Airport constructor (thus decoupling the two objects).

I have already done this project twice using Ruby and Javascript at Makers Academy, so the design ideas were not a problem just the implementation in a new language. Thus this project was definitely a good step in learning the language.

My thoughts so far...

I feel more confident with Python, but still need to do more work. I was given a test in the language Groovy, to build a twitter clone for the command line, I think doing this in Python will be a good way to cement my learning of the language. Although, I think doing another project which is totally new will be better, thus allowing me to think about design as well as review syntax of code and testing.

Generally, after this stage, I feel that syntax and testing is fairly easy to use. Any other program will be more about the design and little about the language features. 

Another task, such as building a web app (with CRUD) will also be another project on the list.

Learning Python part 3: TDD and Fizzbuzz

Now everything is setup, I can run a program and it's related test, I am familiar with the syntax, it is time to begin writing some tested programs.

I began by completing the world famous fizzbuzz kata using TDD - Test Driven Development.

This helped me learn the following 

1. get used to producing programs and tests in a systematic way via TDD
2. Writing simple code to pass a test
3. practise the syntax by solving problems
4. read the stack trace to find out where the errors are
5. apply simply refactoring to improve the design of my code
6. Construct tests and implement the syntax for the testing framework
7. Setup a project for code and tests

Fizzbuzz kata can be seen here...
https://en.wikipedia.org/wiki/Fizz_buzz

The aim is to produce a program that is passed a number and using the rules of fizzbuzz to produce the correct output.

My code is here...https://github.com/hanfak/fizzbuzz-python-tdd

If you want to see every step I made in producing the finished program and the tests, view the commit messages and start at the bottom, click on the first commit (best in new tab) and click on split view, and read the right hand side.  The only two files to read are game.py and app_game_tests.py, if you want to read the files alone go to browse file and search for them. Ignore the + or - signs, they just show all the new code and removed code.

To run the program

1. clone the repo to your hard drive, or download the zip file if you do not have access to GIT (really recommend using it)
2. Unzip and enter the folder fizzbuzz-python-tdd
3. run the tests using the commands in the read me ( I assume you have python set up, if not go to this post)
4. To see it in action for the first 100 numbers,  type python
5. load the file, type execfile('app/game.py')
6. type the following after each line press enter (dont include the >, just to show the input prompt)

               >fizzbuzz = FizzBuzz()

               >for n in range(1, 100):

              > print fizzbuzz.count(n), 

7. press enter again and you will see the first 100 numbers with the correct outputs ie fizz etc.

To run the tests:

In the folder, type nosetests -v --rednose

Refactoring

The program is very simple, but can be refactored to make it much clearer and easier to read, as well as keeping the code clean. I applied encapsulation to the logic in the conditionals by creating a new private method (__divisible_by), this helped DRY out my code.

Extra

This was a simpe kata to get used to testing. If I was not very confident, I feel I would have taken another simple kata from here and implemented TDD. 

Also doing these katas is also good way of practising for technical tests set by employers for prospective candidates. 

Next...

Next on the list is doing more advanced TDD (mocks, stubbing), using more python syntax and apply a few more design principles (SRP, injection).

Learning Python part 2: The syntax

To write programs I needed to learn the language, the syntax to implement any programming ideas (ie algorithms).

Here are the following topics I wanted to learn:

1. Variables (create, change, delete, use), data types and their operations
2. Comments in code
3. Numbers(integers, floats), expressions, their methods
4. Strings, print, interpolation, command line input, their methods
5. Booleans, conditionals, logic, expressions
6. Conversion between data types ie string to integer
7. Lists/arrays, and their methods
8. Dictionaries/hashes, and their methods
9. Control statements (if-else/ if-else-if/ ternary, case-switch)
10. For loops, ranges
11. While loops, break, exit
12. Functions/methods, parameters, creating, calling, arguments, return
13. Classes, initialize, instantiating, instance variables, composition, instance methods, class methods, self, 
14. Date/time library
15. Importing, modules/libraries

The following topics I will cover when I need to, as they are not necessary for the majority of code I will build at the moment.

1. Errors
2. File input/output 
3. Lambdas
4. Bitwise operators
5. Inheritance

Plus being able to run the code, using a REPL that you can type code in directly and play around with it.

The above ideas will allow me to create code and learn how to implement testing and object oriented design later on.

As I have already done some coding in ruby and javaascript the fundamentals are going to be the same, i.e. if statements, loops, etc. But every language has different ways of writing them down for the computer to run them (for the compiler or interpreter to turn into computer language for the computer to run).

So I went back to basics and started the track on codecdemy.

I did not complete all of it, I skipped the file input and output section, I can always come back to this when I need to use it, but I managed to cover all the core ideas that I needed to know. Also, I was taking notes on some of the syntax differences to ruby. This I felt would make a good 'help me guide' to refer to when stuck on how to write an idea/algorithm in python.

As I have prior experience in coding, I did not bother reading the descriptions for each lesson, instead, I completed the tasks and went back to the examples in the description to help me if I was stuck. This helped me speed through the python track in around 3 hours, instead of the recommended 13 hours.

NOTE: If learning as a beginner to programming, I would suggest, to take your time learning the syntax, play around with each idea by creating similar examples. Maybe create a summary guide with your own explanations and examples for each part of the codecademy. 

Learning syntax can be very tricky at first, so I would advise using another resource, as a different explanation might prove useful, try Zed Shaws Learn the Hard Way. A google search for resources will yield some books and links. 

NOTE: Avoid reading just cause you have not got it. Focusing on reading, typing (no copy and paste) and playing around with it. Only when you have issues with certain ideas, then look for an explanation.

Testing I can use the language!

How do you know that you understand or can do something? 

Well, you don't ask that question and answer yes. As a newbie, you are not in the position to assess yourself as such. You don't know what you don't know! Instead, you need to test yourself. Can you code using the ideas with out any help or explain the ideas clearly without errors??

To truly know I could use the syntax, I did some Katas (coding problems). Normally, I would use codewars, but codecdemy had a section in the Python track with quite a few katas. Doing katas is a great way of letting go of the hand holding of a tutorial and apply some problem solving together with revising the syntax.

Solving problems with code is very hard for beginners, as you have to think in a logical and algorithmic way. Being able to change a worded or even a mathematical problem into and algorithm requires a lot of practise. Having a background in maths (or any mathematical background) does help with this, but I still need to practice. Will make a post on solving katas later.

Test syntax

Apart from the syntax of a language, I needed to understand the structure of tests. This took a while and I needed to find some examples. This lead me to searching GitHub for example code (by typing 'python tdd' in the search box), and reading the documentation to understand what was going on when I was stuck. Although, Zed Shaws Learn the Hard Way had some info on testing which was useful.

I also had ipython (a REPL) installed (similar to pry for Ruby) so I can play around with the new syntax. Plus lots of colours and probably other features that could come in handy.

I am not to fussed about memorising everything, as I will be creating programs and recalling the syntax from memory first (see testing effect). If that does not work or I forget, I can alway check my code notes or the internet, which will also help make that idea stick.

Another great place to ask for help is stack overflow, it is a great way of formulating the problem that you are stuck on. Which in a lot of cases solves the problem. I would  suggest looking for previously asked questions via Google like typing 'Stack overflow <key words or problem you have>'. If all else fails, ask the question, but be specific, write the code you have issues with and follow the rules. 

One thing that is bugging me are the indent errors, because of the difference between a space and tab in the editor causing several breakdowns in myself and the python interpreter. At least I do not have to deal with missing semi colons, looking at you Javascript!

Learning Python part 1: The why and the setup

This week I have decided to learn how to use Python. 

Python is a popular language, with lots of libraries and has become one the leading languages used for data science and machine learning. 

I felt this would be a great way to show people that I could learn a new language and be able to do some programming and apply design techniques to it. 

I am not perfect at the other languages I know, ruby and javascript, but I feel comfortable in using them, so doing this is also proving to myself that I can learn a language independently. 

After Makers, I already have a framework of how to go about this and have a plan which I will document my progress here.

So far the plan I have set myself is:

1. Setup 
2. Learn the syntax
3. Create a test driven Fizzbuzz program
4. Create a test driven tech test program and apply object-oriented design 
5. Creating another program, something new like a game using the terminal.
6. Create a web app or game (any sort of project that uses libraries and/or frameworks)

The setup

Aim: Setup system to run a basic test driven 'hello world' program.

To use python I needed to install the necessary files to create and run python scripts and tests.

NOTE: This is based on using MacOS and with homebrew installed

I installed Python using brew install python3 in the terminal.

NOTE: There are two versions of Python, version 2  and version 3. I would suggest going for version 3 (as done above) as this generally used with web framework Django (and I believe helps if using Windows).

Next, I created a project skeleton, using this tutorial, I would follow this and run the tests.

NOTE: A project skeleton, is just how your files and folders are setup. It is always good to separate your tests from the source code via different folders. This does help with big projects with lots of files.

I used an extra library, to add colour to my tests (I miss RSpec): pip install rednos

NOTE: 'Pip' is a library manager just like bundler for ruby, or Maven for Java. Pip comes installed with the latest version of Python.

So to check everything is running fine, I would enter the project skeleton directory ( ie ' cd <project name>' ) and run tests with this command

nosetests --rednose -v

The '-v'  add information, ie a description of the test, to show what tests were passed.

This will produce the following output:

$ nosetests -v --rednose

tests.NAME_tests.test_basic ... passed
-----------------------------------------------------------------------------
1 test run in 0.003 seconds (1 test passed)

NOTE: You can just run tests using nosetests if you want a simple output, just a series of dots for passing dots.

NOTE: Adding '--with-coverage' at the end of the above statement, you can get the test coverage of your code. Focus only on the files that you have created rather than any extra files displayed. Doing TDD means getting 100% coverage!!!

Note: This is such a common command  I added this as an alias so I could just type in pt (short for python test). Check this tutorial if you want to do this, I have created quite a few aliases for common git commands too.  A really useful one I found is to create a new folder and enter it

So to create a new project,  I need to copy the project skeleton and rename the folder as the name of the project. Then change all instances of 'NAME' in the files and filenames and I am good to go.

NOTE: Before going on to creating a simple program with tests, I learned some of the syntax first.

To complete the setup, I created a basic hello app, which takes a name and returns "Hello <name>" and tested it.  To view this and see how the project skeleton was altered check the code and browse through the files here:

https://github.com/hanfak/hello-world-python

Issues

I had a lot of issues setting up a project. I like to separate my tests and program scripts into separate folders, but running the tests caused so many issues with finding the program for the test to run against. Eventually, I found Python the hard way which had a very easy to follow tutorial that helped me setup a project skeleton. It is also a great way of learning the syntax too.

Using nose to run my tests, solved so many issues that running 'unittest' or the script using python command, were giving me.

Naming the descriptions of tests were not great, so I decided to use a naming convention so the tests appear in order on the terminal to the order on the test script, rather than alphabetically.

For example

test_1_description 

test_2_description

I also added doc strings """description in here""" at the start of each test, which gave a nice description of what was happening, kind of like an 'it block' in RSpec. This would show when running nosetests with -v flag in terminal.

Summary of my time at Makers Part 1

Unfortunately, I have been unable to regularly chronicle my time during the past 8 weeks or so. Time was precious and I needed to focus on the course rather than this blog. 

Sorry.

Instead, I will write a summary of my time in general. As I start my final week and the work load dropping considerably I feel I can get a few posts out that will give an account of my time here at Makers. 

For a real short summary....

If you want a challenge, DO IT.

If you want to create something really cool, DO IT.

If you want to learn a bunch of coding stuff, DO IT.

If you want to make great friends, DO IT.

If you want to change as person and learn life skills, DO IT.

If you want to be comfortable failing, DO IT. 

If you want to be in an environment which supports you, DO IT.

If you want to surpass your own expectations, DO IT.

If you don't mind giving up your life and time everyday, DO IT.

Typos

Monday has become a sort of chilled out day, half the time is spent on code reviews and lectures, and the other half learning new terminology and starting on the weekly challenge. It is nice to start the week in a slow way, but at times I just want to power through the new work. 

I was with Chris today, the musician/contract killer (his viola case looks like a sniper case). We spent an age trying to solve a problem that has never happened to us before...rspec not recognising it's own method (i.e. 'feature'). We went up the chain of help. Google failed. Our peers failed. The Alumni Helpers failed. The coaches failed. We were pissed.

In the end, an Alumni Helper, William, decided to look at our code after hours and spot the mistake. It was writing the wrong type of '-' which proved the problem. Sometimes the simplest things are the cause of our problems, but being simple makes them hard to spot. 

Lesson learned: Be cool when stuck.

Also managed to get some free homous and bread, which were left over from a weekend event at Makers.

It was good, but the houmous was very acidic, which I found out later, was a sign the food was off. So I spent the whole day waitin for my stomach to explode.

Also free cookies and possibly free football.

In my opinion, the start of week four has been good!

MA Week Two Summary

General summary

More Ruby, More TDD

The main challenge this week was to learn more about applying Ruby using a test driven methodology  (rspec) to create a functional piece of software for the London Oyster Card system. The new skill we learned was all about dependency injection (DI). This gave practically everyone headaches and stress!

DI is just a way of reducing coupling (dependency of one object relying on another). Low coupling is the aim of good design, objects knows very little about other objects that it sends messages to. No coupling can never happen, as the object cannot be used by any other object. High coupling is bad, it makes changing one object harder to do, as it will affect the implementation of another object. The lower the coupling the easier it is to change or add to code.

Group session

Had a great group session with Dana (will talk more about her, but she is great) on Tuesday, involving sharing our thoughts so far on our experiences with the course. It was a real eye opener. We had to express our agreement  with the current speaker by showing 'jazz hands'.

We spent around 90 minutes doing this but despite my feelings of regret at not coding, I felt this was a great idea to really connect and learn more about my cohort and myself. There were a lot of emotions being shared around, a few personal stories of overcoming setbacks, a few tears, a few people overcoming their fears to talk in public but most importantly a lot freedom to say what you want and be heard with out being judged or threatened.

I started first, and shared my feelings of feeling stupid, not being good enough, being an imposter, letting my pair partners down. Too my surprise nearly everyone felt the same. Personally, I felt this has held me back a lot in my life, but I am starting to believe that I am good enough and thats alright and all I need to be. Not knowing everything, or feeling stupid or forgetting does not make me rubbish. Class is permanent, form is temporary.

What was surprising was my pair partner for the day, Andrew, felt the same way. Although I felt he was far better at solving the problem, more confident and learning so much more than me. So it was great to hear he felt the same about me and feel that it is alright to be struggling, it is normal. After the session, we had a hug and managed to finish off the task  for the day.  Then a huge group ended up at the bar, with friendships further strengthened.

I feel this group of people I am working with now, are going to be in my life for a long time.

Code review of my weekend challenge

• Spent the morning with my mentor Jonny going through the weekend challenge (the airport). He was tasked with reviewing my code and helping me improve the style and quality. 
• Spent time implementing the  changes suggested by my mentor to my code. Spent a lot of time on this, when I felt I should have been doing more pairing on this weeks work. 

Played football for the first time in years

Football is organised for every Monday on the five a side pitch located at the back of the offices. I have not played football in ages, so I knew I would stuggle. I did. I was out of breath after 10 minutes and we still had 50 minutes left to play. Yet despite the struggle ( I am seeing similarites with Makers), I loved it. It was like being back at school on the playground kicking the ball around, kicking it over the fence and having to retrieve it (think most were glad for this as it gave us time to rest).

There was only me, Paul and Si from our cohort, and the rest were seniors and a couple of Alumni playing. It was great game, competitive and friendly. Although we gave up counting goals after 15 minutes, think everyone was too busy gasping for breath to remember.

Big consequence of playing football and walking for commute are that my legs are like jelly and aching like mad!


A visit to the POO DR

As a consequence of a breakout session, we were told to read POO DR by Sandi Metz. This is the bible of good design (SOLID and TDD) with a particular reference to Ruby and bicycle gears. It is a great read, and the topics are well discussed. The big problem is being able to apply them while working through the problems.

I decided on Thursday to stay late, and implement some of the ideas on dependency injection in chapter 3 to my code, to reduce the coupling. Well worth the time spent, code much cleaner.

Pair partners for the week

Monday

My partner was Yasmin (no J), unfortunately we did not have much time together as we had our code reviews and refactoring (improving our code) to get on with. We did sit next to each other and help each other out. We spent around an hour working on the challenge, but did not get very far, although I felt we did some good review of the basics  that were learned last week.

Tuesday

My partner was Andrew and we managed to get through a lot of work together. After the group session, I realised we were at very similar levels and that it was great working together. We had an almighty struggle with problem 12 and I just shouted out in ecstasy when we solved it, which I think disturbed a lot of people (well not many, most had already left).

This was also my first time that I have had to go and see the Alumni Helpers for help. We have been told to see the AH if Google or one of cohort cannot help us. I have always been one to focus on solving problems myself, regardless how long they took. This is a big mistake. I am wasting time, but I guess my ego is involved. So I was glad to admit that I did not know and get some ideas on solving a problem.

Wednesday

My partner was Murilio, from Brazil, and it was a good session partner wise, but we did not exactly do as the question asked and it feels like I have missed out on pushing my learning further.

Worked late at night, trying to understand what was going on with DI.

Thursday

My partner was Junyuan (spelt correctly, which I did not when I was set up GIT, sorry) and it was a tough day. I was so confused by the material, I felt that I did not give as much contribution to the code.

Friday

My partner was Erika. We both finished this week's work, so we decided to redo it again from scratch and see how we got on. Due to being Friday, we finished the day at 4pm when the drinks came out.

Quotes

"You are not your code"