Pretty simple exercise. However, it’s presented early on and there’s nothing to guide, besides what is in the tests, on how to solve it. Almost seems like it was pushed unfinished. I have solved the old one in other languages and it was easy. This one has a few issues:
It says "if your friend likes cookies…’ and there is nothing about liking cookies in the tests.
It doesn’t give any starting point when opening the exercise for what is being passed in. Is it a friend’s name, a boolean for liking cookies? Both?
Looking at the history (for Ruby: History for exercises/practice/two-fer/two_fer.rb - exercism/ruby · GitHub) shows that there’s something about TDD in the most recent commit, but I don’t know what that is yet(search says Test-Driven Development), and as the commit says, it has no mention anywhere else.
FWIW I tried figuring out how to put together the solution using the tests, but it’s failing.
class TwoFer
def two_fer(name)
(name != nil || name != "") ? "One for #{name}, one for me" : "One for you, one for me"
end
end
The point is that you should define the module/class yourself and then solve it.
It is about that if you open up the tests locally so will only the first test runner and then you can progress by activating more and more tests until you solved the exercise.
Hi @cakeyjupiter. Thanks for opening the forum post.
Two questions:
Have you worked through the Learning exercises on the Ruby syllabus yet?
“I have solved the old one in other languages and it was easy.” This exercise hasn’t really changed in years. Could you show what you did in a different language that didn’t work here?
We can interpret this as “One (cookie) for you, one for me.” The tests do not address what the “one” is, indeed.
It doesn’t give any starting point when opening the exercise for what is being passed in. Is it a friend’s name, a boolean for liking cookies? Both?
It does not state so, for sure, but one for “Jan, Pat, Bob, and Sue” could be passed in, and it would still work. It may even be not a friend, but a neighbor, a stranger, a pet, or even “the cookie jar”. Any “name” seems to work.
Is there a potential for a lot of interpretation? Sure, but I think it would also be the same for other tracks, given the source is shared amongst them, and I do not remember doing anything special or custom for this track.
And the technicality of the situation is indeed as @Meatball describes. The tests should be failing and should be indicating the problems, though learning to read the test failures is a skill in itself, so I really am not surprised that there is difficulty there.
Also, if you do submit it, pass or fail, it is definitely an exercise that can be mentored (not just code review) as there is a lot about Ruby itself that can be learned from this exercise!
Hi. Haven’t worked through the syllabus yet, though i’m sure that’s obvious.
I decided to post precisely because i’m very new to Ruby and because in the Ruby track this exercise appears quite early alongside Hello World:
and in Go (language I have solved it in, though I may have read a book before/while doing the track, so that could have helped) it doesn’t. It just doesn’t feel like it should be there if you have to build the class from scratch with zero guidance. To me it is telling that you asked if I had completed the syllabus, though this is a Basics exercise at the start of the tree.
i think in a programming prompt context “if …” prompts one to write…an if statement, usually, so it seems unnecessarily confusing to have it in there when the tests don’t match up. it’s not really necessary to the whole setup.
also here’s the Go solution. You get a little more starter code for this exercise it seems:
// This is a "stub" file. It's a little start on your solution.
// It's not a complete solution though; you have to write some code.
// Package twofer should have a package comment that summarizes what it's about.
// https://golang.org/doc/effective_go.html#commentary
package twofer
import "fmt"
// ShareWith should have a comment documenting it.
func ShareWith(name string) string {
if(name=="") {
return "One for you, one for me."
} else {
return fmt.Sprintf("One for %s, one for me.", name)
}
}
I do not want to speak for @iHiD but the reason they are asking about the syllabus is that this tree is for the Practice mode, while the Learning syllabus has a more guided introduction to things.
If you are just learning Ruby, and not really here for the practice and know at least some Ruby, then the Learning mode is more appropriate (though still not necessarily suitable for “from scratch” learning the language.)
About the exercise:
In Ruby, the variable in the argument list with a default value assignment is functionally an “if statement”, in practice. If an argument is given assign the variable to that value, if not, use the default assignment.
In Go, providing a default argument to a function is not trivial. So having some structured code there for this exercise makes sense there. Indeed, one language’s “easy” exercise may be another language’s “difficult” exercise.
The mention of testing is in the HELP.md file that is delivered, rather than in the README.md file, but also shown in this link: Testing on the Ruby track | Exercism's Docs
No, the tree is for the Learning Mode. And I think the point is that this exercise is coming before things like defining classes etc are ready.
@Meatball is currently reworking the syllabus tree, so maybe he could add this in a more appropriate place
Wasn’t obvious really. The syllabus might literally just not teach something that’s necessary for it. Or it might just be in the wrong place. Which it clearly is now you’ve explained
I think it is resolved though… and we did spend some time synchronously, where I think a lot of questions (even more questions than were realized initially) were answered!
