Showing posts with label methods. Show all posts
Showing posts with label methods. Show all posts

Tuesday, February 7, 2017

Rails 4 in Action, Chapter One (Notes)


Not much to say, just wrapping my head around the basic functionality afforded by the scaffold in the examples of Chapter One.






Monday, January 23, 2017

Project Complete!


I have finished re-writing my text adventure game, Tree House Prince, available here: (https://github.com/clockworkpc/tree-house-prince)

It is a very simple game, but I am proud of all the things I learned to get it into this shape.

The game demonstrates my grasp of conditionals, classes, inheritance, and automation testing.  Every scene in the game has full module testing in Rakefile; the integration testing has to be done manually at this stage.  (I will learn about that soon!)

Tuesday, January 17, 2017

User Testing Update



I've had to hit the books again to improve my understanding of variables, classes, and methods.

I've been re-writing my text adventure game so that every aspect of it is tested by the Rakefile.  This means that I have had to extrapolate the logic of the enter() method in each class, so that a test can be written for it.

The most interesting parts of the game involve somewhat complex conditionals, written as case conditionals, and for some reason it took me a while to understand how to pass on a variable to the method containing a case conditional.  Now that I look at it again, it's very simple, but c'est la vie.

Anyway, the re-written game is nearing completion and the latest code is up on Github.

Monday, December 26, 2016

Ruby Project Skeleton Generator on Gist!

Exercise 46 of Learn Ruby the Hard Way gives instructions for manually creating a project skeleton.  So I decided to do what I have done many times before in BASH and Python, and automate this task with a pretty Ruby script.

A few thoughts:
  1. Ruby's handling of files and folders is delightfully straightforward.
  2. Ruby handles strings elegantly.
  3. This was originally written as a straight script, but then I refactored it with object-oriented programming in mind:
    1. One Class (Project)
    2. The main components of the class broken down into methods.
    3. Names of folders and files are stored in an array and a hash.
    4. Blocks of text are stored using Squiggly HEREDOC

Using a string as a class variable

My script relies on a single argument in the form $stdin user input:

class Project
  def initialize()
    puts "What do you want to call this project?\n"
    print "> "

    $user_input = $stdin.gets.chomp


The script is organised into a single class that contains consecutive methods.

The simplest way I have found to utilise the user input is to declare it in each method.

  def define_folders()
    project_name = $user_input


  def create_gemfile()
    project_name = $user_input

However, this is repetitive.

What would be a better way?


Saturday, December 24, 2016

Defining Scenes in a Text Adventure Game

In my text adventure game, the user starts outside in meadow, and eventually gets inside a six-storey tree castle with a staircase that runs from the ground floor to the fifth.

Here is a map of the world:


The scene of greatest interest here is the Staircase, for it is actually not a scene at all, but rather a method within the HouseScene subclass of Scene.  That is, the user can leave any room and go back to the landing of the staircase on the floor of that room.

For example, the bedroom is on the fourth floor, and if the user elects to leave the bedroom, she will return to the fourth floor landing of the staircase.

Using 'relative_require' to separate functions, classes, instantiation

My goal is to create a main.rb file that does nothing but instantiate the classes and execute their methods.  As you can see below, this is possible, at least in a simple application, but is this good practice?

It feels neater to separate classes, functions, etc; but then again, this might be akin to separating vocabulary sheets by parts of speech -- tidy, but impracticable.

It might be better practice to group blocks of code that work on the same portion of the program.  Please let me know what works in your experience.

A simple function:

## demo_function.rb

def hello_world()
  puts "Hello world!"
end

A class that uses this function as a method:

## demo_class.rb

require_relative 'demo_function.rb'

class Demo
  def enter()
    hello_world()
  end
end

Finally, an instance of the class that executes its method:

## demo_main.rb
require_relative 'demo_class'

a_class = Demo.new()
a_class.enter()

Output:

Hello World! 


1,050 hours

It took me 13 working days to complete my first 100 "work" pomodoros as a Junior Software Tester at Profectus Group.  Much of ...