A Word of Thanks to Gleam.io

I wish to thank Gleam.io for the invaluable experience of working as a junior software development intern from August 2017 until January 2018.

When I started my internship, I had about seven months' self-study of Ruby and Rails, with a smattering of HTML, CSS, Github, etc.  During my time at Gleam.io, I got to learn the ins-and-outs of a large commercial codebase, and saw first hand how an excellent product is built, maintained, and supported with intelligence and empathy.

I navigated the choppy waters of dependencies and got a complex commercial application running on my local Linux machine.  (I also updated the README to make life a lot easier for the next person)

I got a bunch of pull requests approved.

I made mistakes, and learned from them, in using Github.

I kept on using Rubymine until it made sense to me.

I spent countless hours reading the code, hunting for clues; Google and Stack Overflow were my constant companions.

I wrote tests that failed, then passed, then failed again, then passed.

I went mountaineering on a learning curve of Ruby and Rails, especially Rails; now I understand essentially how it fits together and is used to build websites that serve the needs of customers. 

A fair representation of the ardour and the rigour of studying Rails.

I got to pair program a bit and work remotely a lot — I enjoy them both very much.

In short, I was given every opportunity to learn from seasoned veterans, the value of which is beyond measure, and was treated with tolerance and respect by everyone on the team.

Chief amongst the myriad things I am grateful for is the self-confidence I am imbued with.  When I started my journey into software development, self-belief was one part reason, two parts faith.  But now I can say that someone saw the potential in me, even though I didn't have the requisite skills and knowledge for the role, and gave me a chance to fail and succeed, fall down and pick myself up.  

The guys at Gleam.io didn't have to take me on, but they did; they didn't have to invest in me, but they did.  They allowed me to see how I measure up against people who have been working with software for half my lifetime, and what I saw (although daunting at times) gives me great hope for my own prospects as developer.

Now that I have been part of a commercial development environment, I know for a fact that I can become a genuinely good developer with a reasonable amount of study, regular practice, and some guidance.  I will apply for junior development positions confident that the requirements of the role are well within my zone of proximal development.

Every time I turn on my System76 laptop (currently running Ubuntu 16.04.1 with Gnome Shell, but I might switch to Arch), I am reminded of the countless kindnesses shown to me, and take heart that the Next Big Thing in my journey is just around the corner.

Advent of Code, Day 3: Success!

It's been a productive day of coding, although I got off to a late start.

I completed both parts of Day 3 of Advent of Code without too much difficulty.  I knew fairly well what I wanted to do for the first part and misread the instructions for the second part.  Once I understand what I had got wrong, it was simply a matter of jotting down notes and thinking the problem through.  I skimped on the testing for it, which was naughty, so I'll have to be more disciplined in the future.

Review of 'Toy Robot' by Ryan Bigg

Toy Robot by Ryan Bigg (@ryanbigg) is an excellent walkthrough for a budding Rubyist, especially one that has worked through Learn Ruby the Hard Way. (As I have!)

Bigg is a veteran Ruby developer and prominent member of the Ruby and Rails community in Melbourne, Australia.  His blog is a valuable resource for both novices and experts.  The book weighs in at just over 100 pages and strikes a balance between technical jargon and clear, simple prose.  His descriptions of the rationale for his approach shed light on the code blocks in the book, and are very helpful to a novice like me.

The book describes itself as "A Walkthrough for The Toy Robot", which is misleadingly accurate, for the term "walkthrough" conjures up images of a many happy hours spent on old-school click-and-point adventure games. (King's Quest comes to mind)

This is not a "walkthrough" in that sense.  Rather than simply prescribe the steps for building a Ruby solution to the toy robot problem, Bigg's book takes the reader on a full test-driven-development journey of writing tests, making them fail, making them work, and making them fail again, until every class, module, method, and function has been thoroughly vetted.
The book demands that you see for yourself how to outline the problem, write tests for each-and-every detail of the software and allow testing (and especially test failures) to guide you through the process.

Having spent 18 tight pomodoros (20-minute blocks), i.e. six hours on this book, I cannot now duplicate every detail of the book's solution to the problem, but whereas before it was insurmountable, it is now assailable.  My solution would not be as tight, but it would get there.  The lion's share of my learning came not from memorising what the book does, but rather from poring over the output of the failed tests to understand what went wrong, and sometimes why my test failures were different from the book's.

For this reason, I strongly recommend that you NOT copy and paste, but rather type out every line of code for yourself, and run all the tests to see the results.  I promise you will come to see the HOW and WHY of Bigg's elegant solution to the toy robot problem.

The book is available in PDF, EPUB, and Mobi formats and is available for as little as $5, although I hope you will find it in your heart to spend at least $10 in recognition of this author's fine work.

Rating: 5/5

Toy Robot Problem

Refer to Ryan Bigg's book: https://leanpub.com/toyrobot

Code problem details: Toy Robot Simulator

Description:

The application is a simulation of a toy robot moving on a square tabletop, of dimensions 5 units x 5 units. There are no other obstructions on the table surface. The robot is free to roam around the surface of the table, but must be
prevented from falling to destruction. Any movement that would result in the robot falling from the table must be prevented, however further valid movement commands must still be allowed.

Create an application that can read in commands of the following form:

PLACE X,Y,F
MOVE
LEFT
RIGHT
REPORT

• PLACE will put the toy robot on the table in position X,Y and facing NORTH, SOUTH, EAST or WEST. The origin (0,0) can be considered to be the SOUTH WEST most corner. The first valid command to the robot is a PLACE command, after that, any sequence of commands may be issued, in any order, including another PLACE command. The application should discard all commands in the sequence until a  valid PLACE command has been executed. 
• MOVE will move the toy robot one unit forward in the direction it is currently facing. 
• LEFT and RIGHT will rotate the robot 90 degrees in the specified direction without changing the position of the robot. 
• REPORT will announce the X,Y and F of the robot. This can be in any form, but standard output is sufficient.

A robot that is not on the table can choose the ignore the MOVE, LEFT, RIGHT and REPORT commands. Input can be from a file, or from standard input, as the developer chooses. Provide test data to exercise the application.

Constraints:

The toy robot must not fall off the table during movement. This also includes the initial placement of the toy robot.  Any move that would cause the robot to fall must be ignored.

Example Input and Output:

a)

PLACE 0,0,NORTH
MOVE
REPORT
Output: 0,1,NORTH

b)

PLACE 0,0,NORTH
LEFT
REPORT
Output: 0,0,WEST

c)

PLACE 1,2,EAST
MOVE
MOVE
LEFT
MOVE
REPORT
Output: 3,3,NORTH

Deliverables:

The source files, the test data and any test code.
It is not required to provide any graphical output showing the movement of the
toy robot.

First Small Step Into Testing

I am working on Exercise 28 of Learn Ruby the Hard Way and this is my first concrete example of using testing in the course of coding.

The exercise is a test of boolean logic: I am given a statement e.g.

true == true

And must work out whether it is "true" or "false".

As you can see, I have organised the statements in a two-dimensional array in which each sub-array is composed of three elements: a string denoting the statement, the statement itself, and my prediction.

# List of boolean statements to test my knowledge thereof, organised in a two-dimensional array
booleanTest = [
  ["true && true", true && true, true],
  ["false && true", false && true, false],
  ["1 == 1 && 2 == 1", 1 == 1 && 2 == 1, false],
  ['"test" == "test"', "test" == "test", true],
  ["1 == 1 || 2 != 1", 1 == 1 || 2 != 1, true],
  ["true && 1 == 1", true && 1 == 1, true],
  ["false && 0 != 0", false && 0 != 0, false],
  ["true || 1 == 1", true || 1 == 1, true],
  ['"test" == "testing"', "test" == "testing", false],
  ["1 != 0 && 2 == 1", 1 != 0 && 2 == 1, false],
  ['"test" != "testing"', "test" != "testing", true],
  ['"test" == 1', "test" == 1, false],
  ["!(true && false)", !(true && false), true],
  ["!(1 == 1 && 0 != 1)", !(1 == 1 && 0 != 1), false],
  ["!(10 == 1 || 1000 == 1000)", !(10 == 1 || 1000 == 1000), false],
  ["!(1 != 10 || 3 == 4)", !(1 != 10 || 3 == 4), true]
]

I test my prediction by running the following testing loop, and in keeping with the practice of "green" for good and "red" for error, I installed the colorize gem and applied it to the output of the testing loop.

# Required in order to highlight the text in the testing loop green or red.

# Colorize gem to mark the result green or red.
require 'colorize'

# Testing loop
puts "Here are the results of my test:\n\n"
booleanTest.each do|description,result,prediction|
  puts "PREDICTION: #{description} GIVES #{prediction}, RESULT: #{result}"
  if prediction == result
    puts "Correct!".colorize(:green)
  else
    puts "Incorrect!".colorize(:red)
  end
end

And here are the results:

Thoughts on My First Code Retreat

When I turned up at the annual Melbourne Coderetreat, I was nervous and reticent.  I am not a professional programmer -- yet -- and I had no illusions of keeping pace with people who do this for a living.  Nevertheless, I stuck it out and learned an awful lot.  The organisers Tomasz and Ilya did a fine job of running the event, and I appreciate their encouragement.

Conclusions and Ideas:

1. Do puzzle programming.
2. Make code kata a regular practice.
3. Focus on one language, either Python or Ruby and learn programming concepts thoroughly.
4. Attend programming meet-ups, preferably for Python or Ruby, and seek out a mentor.
5. Attend a DevOps meet-up, at least once.
6. Make code dojos and retreats a priority.
7. Learn TDD. (Test-driven development)
8. Familiarise myself with a testing framework.  Using a text editor and the terminal is all well and good when starting out, but using a properly kitted out IDE is essential.

I will return to this post and add more.  Feel free to leave suggestions in the comments.

UPDATE: Some useful comments

• 8: Pick one and get settled: 10 reviews of python ides

• Choose one that supports multiple languages: python, ruby,

• Eventually you'll want to learn emacs or vim, buth these can wait

• Many of these are combinable: 1 + 2 + 3 + 7

• http://www.codekatas.org/

• https://programmingpraxis.com/

• https://www.google.com.au/search?q=python+online+courses