In Learn Ruby The Hard Way book on exercise 19, it says one should take the provided function:
def cheese_and_crackers(cheese_count, boxes_of_crackers)
puts "You have #{cheese_count} cheeses!"
puts "You have #{boxes_of_crackers} boxes of crackers!"
puts "Man that's enough for a party!"
puts "Get a blanket.\n"
end
and explore different approaches with it. I tried to explore the function's arguments and write a text with it:
file = ARGV.first
puts "Let's make a test?"
puts "Does the output file exist? #{File.exist?(arquivo)} "
puts "Ready, hit RETURN to continue, CTRL-C to abort."
$stdin.gets
def success(price, recipe)
puts """Text goes on like this:
In order to become a coder, You must dedicate yourself.\n
For that, you must pay a price, such as #{price}\n
Becoming a coder also requires #{recipe}\n"""
end
puts "What is the price to pay in order to become a coder?"
price = $stdin.gets
puts "What are the fundamental components in order to become a coder?"
recipe = $stdin.gets
coder = success(price, recipe)
motivational = File.open(file, 'w')
motivational.write(coder)
puts "Read this every day."
But I can't seem to make it write the function into a new test.txt file. The test.txt file comes out empty.
When calling puts, you're writing to stdout, but the return value will be empty.
Change this:
def success(price, recipe)
return """Text goes on like this:
In order to become a coder, You must dedicate yourself.\n
For that, you must pay a price, such as #{price}\n
Becoming a coder also requires #{recipe}\n"""
end
Then also:
motivational.close()
EDIT: Here's an extended explanation: when calling puts, you're just writing the string to stdout, which is the default output for programs. Methods (functions) can have a return value. For your success method, you need to return the string, so that you can write it in your file. If you call puts instead of return, the success method will not return any value, therefore leaving the file empty.
As for the close() call, it is advisable to close the file stream before your script ends.
Take a look at these references for more information:
https://www.ruby-lang.org/en/documentation/quickstart/2/
http://ruby-doc.org/core-2.2.3/IO.html
Related
I want to recall the case until user writes a or b. I do not want to use "case"
particularly.
I just want to get input from user but not geting something else. If he writes something else, he should need to write until he writes a or b.
str = gets.chomp.to_s
case str
when "a"
print "nice a"
when "b"
puts "nice b"
else
puts "please do it again"
end
class person
attr_accessor :name , :surname #and other attributes
end
#There will be a method here and it will run when the program is opened.
#The method will create the first object as soon as the program is opened.
#The new object that the user will enter will actually be the 2nd object.
puts "What do you want to do?
add
list
out"
process = gets.chomp.to_s
case process
when "add"
#in here user will add new objects of my class
when "list"
#in here user will show my objects
when "out"
puts "Have a nice day"
else
puts "please do it again"
end
In fact, if you look at it, many actions will be taken as a result of the user entering the correct input. what I want to tell is more detailed in this example. According to the input of the user, there will be actions such as calling methods, adding objects, etc.
I wrote most of the code on my computer. But still I couldn't solve my first problem.
Use Kernel#loop
There are a lot of ways to solve this problem, but let's start with a simple Kernel#loop wrapper around your existing code, as that's probably the easiest path forward for you.
loop do
str = gets.chomp.to_s
case str
when "a"
print "nice a"
when "b"
puts "nice b"
else
puts "please do it again"
# restart your loop when not "a" or "b"
next
end
# exit the loop if else clause wasn't triggered
break
end
Use until Control Expression
The loop construct above is pretty straightforward, but it requires you to think about where you need next and break statements for flow control. My own instinct would be to simply call a block until it's truthy. For example, the core logic could be shortened to:
str = nil; until str =~ /a|b/i do str = gets.chomp end; p str
This is a lot shorter, but it's not particularly user-friendly. To leverage this approach while making the solution more communicative and error-resistant, I'd refactor the original code this way:
# enable single-character input from console
require 'io/console'
# make sure you don't already have a value,
# especially in a REPL like irb
str = nil
until str =~ /a|b/ do
printf "\nLetter (a, b): "
str = STDIN.getch.downcase
end
puts "\nYou entered: #{str}"
While not much shorter than your original code, it handles more edge cases and avoids branching. It also seems less cluttered to me, but that's more a question of style. This approach and its semantic intent also seem more readable to me, but your mileage may legitimately vary.
See Also
IO::Console
Control Expressions
"I just want to do something until something else happens" is when you use some sort of while loop.
You can do this:
while true
str = gets.chomp
break unless str == 'a' || str == 'b'
puts "please do it again"
end
You can also use loop do:
loop do
str = gets.chomp
break unless ['a', 'b'].include?(str)
puts "please do it again"
end
puts "Nice #{str}."
Rubyists tend to prefer loop do over while true. They do pretty much the same thing.
One more thing. There's a simpler way to write out arrays of strings:
loop do
str = gets.chomp
break unless %w(a b).include?(str)
puts "please do it again"
end
puts "Nice #{str}."
It doesn't look a whole lot simpler, but if you have, say, 10 strings, it's definitely quicker to type in when you don't have to use all those quotation marks.
As your intuition was telling you, you don't need to use the case statement at all. Like trying to kill a flea with a sledgehammer. The most concise way to do your check is to check whether the input character is included in an array of the desired characters.
How do I execute Ruby files from another Ruby file?
class Launch
def get_program
begin
files = ["sum_of_digits", "compressed_sequence",
"shortest_repetition"]
(0...files.length).each_with_index do |index|
puts "#{index} . #{ files[index]}"
end
begin
puts "Enter program number to execute: "
puts program_number = gets.chomp.to_i
puts "loading program #{files[program_number]}"
begin
load(`ruby #{files[program_number]}.rb
#{files[program_number]}.txt`)
rescue
puts "loading error"
end
puts "do you want to continue Y/N"
answer = gets.chomp
end until answer == 'N'
rescue
puts "the file cannot be loaded ,it may be moved or not exist "
end
end
end
launch = Launch.new
launch.get_program
launch = Launch.new
launch.get_program
While executing, I am getting the output, but for only one program, and the loop is terminating. I want to execute files in a loop until the user enters "N".
In general your code isn't written in the Ruby way. This is untested but it looks about right:
class Launch
FILES = ['sum_of_digits', 'compressed_sequence', 'shortest_repetition']
def get_program
FILES.each_with_index do |fname, i|
puts "#{i} . #{fname}"
end
loop do
puts "Enter program number to execute: "
program_number = gets.to_i
file_to_load = FILES[program_number]
puts "loading program #{file_to_load}"
begin
system("ruby #{file_to_load}.rb #{file_to_load}.txt")
rescue => e
puts "loading error: #{e}"
puts "'#{file_to_load}' cannot be loaded, it may have been moved or not exist."
end
puts 'Do you want to continue Y/N'
break if gets.chomp.strip.upcase == 'N'
end
end
end
launch = Launch.new
launch.get_program
Some things to study:
block and end are used to start exception handling, not to define control loops. Well, they can, but there are better, more idiomatic, ways. loop is recommended by Matz.
You used load but I don't think that's really what you'd want to do. Instead, you should tell the OS to load and run the code in a sub-shell using system, not in the context of your currently running code.
Instead of using a bare rescue, your code should at least capture the exception using rescue => e so you can output what occurred. In "real life", AKA, production, you should be even more discerning and capture only the exceptions you expect, but that's a different discussion.
When using a begin/rescue/end, try to keep them as small as possible, at least until you're more familiar with how they work. rescue is a great way to shoot yourself in the foot, and debugging raised exceptions that could be generated by many lines of code can be a pain.
In general, when you have a list of things that's likely to change, or any variable that's more likely to change than the rest of the code, put that definition at the top of the script, or the top of the class or module definition, then reference it as a constant. That helps avoid magical dust being sprinkled through the code that has to be searched for if you want to add or delete things. Like files. Or magical dust.
I am having trouble outputting the contents of my hash to a file. The program is one that manages a list of student records, including their StudentID, first name, last name, Major, and catalog year. Once the user is finished adding records, it is then added to the hash.
Everything in the program works perfectly, except when I try running the quit_program function, it doesn't save the contents in the file. Additionally, i am not getting any errors, any ideas?
could it potentially not be working because it is having trouble with converting the text in my hash, which is alphanumeric, into the text file?
def quit_program()
puts "Save Changes? y/n"
#changes = gets().chomp
if #changes=="y"
#fh=File.open(#file_name, 'w')
#this_string=""
#sDB.each do |key, store_account_data| #line 50
puts "#{key}: #{store_account_data.join(',')}"
end
end
#fh.puts(#this_string)
#fh.close()
end
You're not writing anything to the file. The string #this_string is empty. You should do
#sDB.each do |key, store_account_data|
#fh.puts "#{key}: #{store_account_data.join(',')}"
end
it doesn't save the contents in the file.
The following is NOT how you write to a file:
puts "#{key}: #{store_account_data.join(',')}"
That is how you write to your terminal/console window.
And this code:
#this_string=""
#fh.puts(#this_string)
writes a blank string to the file.
Here is how you write to a file:
class Student
def initialize(sDB, filename)
#sDB = sDB
#filename = filename
end
def save_changes()
puts "Save Changes? y/n"
user_answer = gets().chomp
if user_answer == "y"
File.open(#file_name, 'w') do |f|
#sDB.each do |key, store_account_data| #line 50
f.puts "#{key}: #{store_account_data.join(',')}"
end
end
end
end
could it potentially not be working because it is having trouble with
converting the text in my hash, which is alphanumeric, into the text
file?
No. Here is a concrete example you can try:
data = {
"John" => ['a', 123, 'b', 456],
"Sally" => ['c', 789, 'b', 0]
}
File.open('data.txt', 'w') do |f|
data.each do |name, data|
f.puts "#{name}: #{data.join(',')}"
end
end
$ ruby myprog.rb
$ cat data.txt
John: a,123,b,456
Sally: c,789,b,0
Also, ruby indenting is 2 spaces--not 0 spaces or 3 spaces, or anything else.
The answer is given in the error message: undefined local variable or method 'sDB'. (Which you have since removed from your question making the edited version next to impossible to answer.) Where and when is sDB defined in your program? You are evidently attempting to quit before initializing it.
In any case it is not a good thing to be accessing instance variables directly inside other methods. You should use accessor (getter and setter) methods instead. That would have probably prevented this situation from biting you in the first place.
def sdb
#sDB ||= Hash.new
end
def sdb=( key, value )
sdb
#sDB[ key ] = value
end
. . .
You are not properly writing to a file even if #sDB is defined. See Ruby - Printing a hash to txt file for an example.
Your question is missing essential input data, so there's no way to test our suggested changes.
Here's untested code I'd work from:
def quit_program
puts "Save Changes? y/n"
if gets.chomp.downcase == 'y'
File.write(
#file_name,
#s_db.map{ |k, v| "#{ k }: #{ v.join(',') }" }.join("\n")
)
end
end
Note:
#sDB isn't a proper variable name in Ruby. We use snake_case, not camelCase for variables and method names. ItsAMatterOfReadability. Follow the convention or suffer the wrath of your team members the first time you have a code review.
Don't add empty parenthesis to method names (quit_program()) or calls (gets()) unless it's essential to tell the difference between a variable and a method invocation. You should also never name a variable the same as a method because it'll confuse everyone working on the code, so that should never be a consideration.
Don't create a variable (#changes) you use once and throw away, unless what you're doing is so complex you need to break down the operation into smaller chunks. And, if you're doing that, it'd be a really good candidate for refactoring into separate methods, so again, just don't.
When comparing user-input to something you expect, fold the case of their input to match what you expect. (gets.chomp.downcase == 'y'). It really irritates users to enter "y" and fail because you insisted on "Y".
While you can use File.open to create or write to a file, there's less visual noise to use File.write. open is great when you need to use various options for the mode but for plain text write is sufficient.
The whole block used for writing looks like it can be cleaned up to a single map and join, which coerces the data into an array of strings then into a single string.
I'm currently trying to test a basic method that receives some input from the user (gets) and outputs it (puts). After a bit of research I found a good way to test the standard output stream which is the below:
def capture_standard_output(&block)
original_stream = $stdout
$stdout = mock = StringIO.new
yield
mock.string.chomp
ensure
$stdout = original_stream
end
The method I'm testing is the one below, output and input refer to ivars which I initialize in the beginning and point to the equivalent $stdout & $stdin:
def ask_for_mark
ouput.puts 'What shall I call you today?'
answer = input.gets.chomp.capitalize
answer
end
Now I've seen some solutions for STDIN but haven't really understood any of them and I definitely don't want to copy & paste. The only one I got to "work" is the one below, but it's not really working since when I run rspec it pauses and waits for input and by simply pressing enter, it passes:
it "takes user's name and returns it" do
output = capture_standard_output { game.ask_for_name }
expect(output).to eq "What shall I call you today?"
game.input.stub(:gets) { 'joe' }
expect(game.ask_for_name).to eq 'Joe'
end
What would be a good way to test STDIN? I've been staring at a screen for most of the day (not good, I know) so a fresh perspective and some help would be greatly appreciated :-)
Update
For anyone facing similar issues, I followed different (simpler) approaches. First, I would separate the IO operations in their own methods.
In the case of input, in the tests it can be pre-populated with the desired data so when the gets message is send, it will return that data which are separated by the newline character \n like so:
input = StringIO.new("one\ntwo\n")
=> #<StringIO:0x007f88152f3510>
input.gets
=> "one\n"
input.gets
=> "two\n"
input.gets
=> nil
This helps with keep the internals of the method under test, private without coupling the tests to the implementation details.
Another approach is to simply use polymorphism and pass in a Fake or a Spy object that conforms to the same api but instead of making a call to stdin or stdout, it returns canned data instead or in the case of the Spy, it registers the call.
class SpyIO
def initialize
was_called? = false
end
...
def ask_for_name
# call to stdout would normally take place
was_called? = true
end
...
end
class FakeIO
def initialize(data = [some, data])
#data = data
end
def get_user_input
# call to stdin would normally happen
#data.shift
end
...
end
There's tradeoffs in each approach but I thought I'd put these here in case anyone was having similar issues or considering options.
You can simply stub STDIN:
it "takes user's name and returns it" do
output = capture_standard_output { game.ask_for_name }
expect(output).to eq "What shall I call you today?"
allow(STDIN).to receive(:gets) { 'joe' }
expect(game.ask_for_name).to eq 'Joe'
end
Actually, you can do the same with STDOUT, without needing to change $stdout:
it "takes user's name and returns it" do
expect(STDOUT).to receive(:puts).with("What shall I call you today?")
allow(STDIN).to receive(:gets) { 'joe' }
expect(game.ask_for_name).to eq 'Joe'
end
Well I can't really be sure, but one problem I had (still have) when working with $stdin / $stdout / StringIO is making sure to run #rewind on them. Are you doing that?
input = StringIO.new
input.puts "joe"
input.rewind
input.gets #=> "joe\n"
I am new to ruby! And i am trying to learn the use of "!" .
I am aware that ! is included to so that the user's string is modified in-place; otherwise, Ruby will create a copy of user_input and modify that instead.
But in the following case for both the programs i am getting the same output.Why?
print "Please Enter your Input"
user_input = gets.chomp
user_input.downcase!
print "Please Enter your Input"
user_input = gets.chomp
user_input.downcase
In Ruby, bangs (!) are used to inform the programmer that the method they are calling is destructive. It's Ruby's way of saying "Hey! This method is going to change the object it is called on!". A number of safe methods in the String, Array,Enumerable`, etc classes have destructive counterparts.
Example:
my_str = "Hello, World!"
my_str.downcase # => "hello, world!"
my_str # => "Hello, World!"
my_str = "Goodbye, World!"
my_str.downcase! # => "goodbye, world!"
my_str #> "goodbye, world!"
As you can see, while both methods return the string's lower case variant, downcase! actually changes my_str permanently.
It's a very convenient aspect of Ruby that I wish more languages offered.
I think it's also worth mentioning that, because destructive methods work in-place, they are generally faster and more memory efficient than their safe counterparts who have to return new objects. Therefore, my_string.downcase! should be preferred to my_string = my_string.downcase whenever possible.
print "Please Enter your Input"
user_input = gets.chomp
user_input.downcase!
user_input value is what the user entered, in lowercase
print "Please Enter your Input"
user_input = gets.chomp
user_input.downcase
user_input value is what the user entered
The difference resides in the value of user_input, not in what gets printed.
Both methods behave the same, but the returned objects are different.
downcasereturns a modified copy of user_input. In other words, user_input stays the same.
downcase! returns user_input modified. Note that this can be more memory efficient, since you don't generate a copy of user_input.
In both cases, they return a downcase version of user_input. That's why you have the same output.
To learn more about bang methods in Ruby, see this blog post.
hth