Showing posts with label methods. Show all posts
Showing posts with label methods. Show all posts
Tuesday, February 7, 2017
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:
A few thoughts:
- Ruby's handling of files and folders is delightfully straightforward.
- Ruby handles strings elegantly.
- This was originally written as a straight script, but then I refactored it with object-oriented programming in mind:
- One Class (Project)
- The main components of the class broken down into methods.
- Names of folders and files are stored in an array and a hash.
- 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:
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.
However, this is repetitive.
What would be a better way?
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.
Here is a map of the world:
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:
A class that uses this function as a method:
Finally, an instance of the class that executes its method:
Output:
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!
Subscribe to:
Posts (Atom)
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 ...
-
I have finished re-writing my text adventure game, Tree House Prince, available here: ( https://github.com/clockworkpc/tree-house-prince...
-
NOTE: My fiancée wishes to stay out of the online limelight, and neither her real name nor her image shall appear in this or future posts. ...
-
It's 03:08 and I am finally starting to make sense of object-oriented programming. It's not that I didn't understand it concep...







