Webbynode - Latest Comments

Re: Finding your BEST Customers

Rystraum — Tue, 26 Nov 2013 00:37:09 -0000

Everyone is going to (inadvertently) work with a nightmare customer (or two, or many as is my case) to be able to know exactly what it feels like.

Ideally, prevention is better than cure but once you're there, it's a hard slog to make it through the project. We've had, on one occasion, actually fire the customer and give their money back because we didn't want to have anything to do with them.

Re: Coming Soon! Webby Manager v2

Ivan Santos — Thu, 17 Jan 2013 12:26:57 -0000

When will I have access to this new version?

Re: The Power of Pair Programming

Leonardo Siqueira Rodrigues — Fri, 15 Jun 2012 11:22:18 -0000

Doing:

def self.is_fizz_buzz?(number)
is_fizz?(number) and is_buzz?(number)
end

Mantain the code more simple [IMHO].

Re: The Power of Pair Programming

Mark Wilden — Tue, 12 Jun 2012 13:14:12 -0000

I would not have chosen any of these solutions. The first solution is closest, but it's just a bit too clever in its use of concatenation.

I would have coded it exactly as it was stated - an IF statement with four clauses. That's the simplest solution that could possibly work (it's also the easiest to write, test, and understand).

Then I'd cross that item off my to-do list and find something else to do.

IF and ONLY IF there arose a need to make this game more flexible, that's when I would refactor it.

But the refactorings as shown simply obscure the actual required functionality behind unnecessary abstraction. And a statement like "return "fizz buzz" if is_fizz_buzz?(number)" shows obvious duplication that should be a tip-off that the refactoring has introduced problems that didn't exist before.

Re: The Power of Pair Programming

Yuri Albuquerque — Tue, 12 Jun 2012 11:27:14 -0000

"and" and "&&" are not the same thing on Ruby:
http://devblog.avdi.org/201...

Re: The Power of Pair Programming

Sora — Tue, 12 Jun 2012 11:09:33 -0000

IMO the code is poor :
1) is_fizz_buzz? isn't based on fizz nor buzz, so if you change one you have to change fizz_buzz (big architectural problem here considering the size of the code)
you should at least make is_fizz_buzz? into the following
is_fizz? number and is_buzz? number
2) the point Steve Holmes said : if you have to add a condition you end up with much more code and have line such as return "fizz buzz wizz"
you also have close to n^2 functions oO
3) just my thought, but a pattern strategy would be nice
4) is_xxxx? should be preferably xxxx? (or is_xxxx)

Applying everything you end up with the following :
class Game attr_accessor :condition def initialize (condition) @condition = condition end def fizzbuzz(number) ret = "" ret << "fizz " if @condition.fizz? number ret << "buzz " if @condition.buzz? number return number if ret.empty? ret end endclass Condition def fizz?(number) number % 3 == 0 end def buzz?(number) number % 5 == 0 endend

---
I didn't wanted to use an array so I simply put a space between each strings ;)

Good : -anyone can easily change fizz and buzz condition by inheriting Condition-size of fizzbuzz don't "explose" if you add others rulesCons:-one more class :/

Try it with :
game = Game.new(Condition.new)(0..30).each { |i| puts game.fizzbuzz(i)}

Re: The Power of Pair Programming

Felipe Iketani — Tue, 12 Jun 2012 10:56:12 -0000

good point ;) it is indeed!

Re: The Power of Pair Programming

No — Tue, 12 Jun 2012 10:54:26 -0000

in Ruby, the coding standard is to use fizz?
instead of is_fizz?
since the question mark already indicates you are asking a question

Re: The Power of Pair Programming

José Mota — Tue, 12 Jun 2012 09:57:32 -0000

Interesting points of view, all of them. A careful look and considering @Steve Holmes approach, I'd use the predicates on the first solution. The nature of the problem is more approachable through your example, and so it fits better.

Adding a `wizz?` method and appending `"wizz" if number.wizz?` (something alike) would be elegant IMO.

Good stuff, Felipe. A good example of how there's more than way to solve problems and how to assess them according to their nature.

Re: The Power of Pair Programming

Steve Holmes — Tue, 12 Jun 2012 09:38:44 -0000

Yes, but you haven't completed the final example. If you add the wizz for 7 then following the same style it needs a fizzbuzz method like this:

  def self.fizzbuzz(number)     return "fizz buzz wizz" if is_fizz_buzz_wizz?(number)
    return "fizz buzz" if is_fizz_buzz?(number)
    return "fizz wizz" if is_fizz_wizz?(number)     return "buzz wizz" if is_buzz_wizz?(number)
    return "fizz" if is_fizz?(number)     return "buzz" if is_buzz?(number)    return "wizz" if is_wizz?(number)    return number
end

then you need to define all the new methods.
Also if you implement these as in the example you have something like

def self.is_fizz_wizz(number)
number % 21 == 0
end

And if you want to change the value of buzz from 3 to something else you have to go and edit multiple methods - violating the DRY principle. Also not only do you have to edit all the places where 3 is used you have to go and work out all the places as it's hidden in the magic numbers of 15 and 21.
It's not just a code smell it's a code stink bomb ;)

Surely you can't think all of that is better than that one line edit for the original version.

Re: The Power of Pair Programming

Caike Souza — Tue, 12 Jun 2012 09:15:14 -0000

Nice, Felipe!

@Steve Holmes , what I understand as being a benefit is that in the first version of the code, he would have to add a line with the implementation that checks for 'wizz', like so:

return "wizz" if number % 7 == 0
Although this works, I think they were going for something more expressive, which is:

return "wizz" if is_wizz?(number)

This would encapsulate the logic behind 'what is a wizz?' behind another method, rather than expose it to the Game.fizzbuzz method.

Re: The Power of Pair Programming

Steve Holmes — Mon, 11 Jun 2012 23:37:23 -0000

I disagree with your conclusion.
Your original code is far better to me.

Let's say we get so good at the game we no longer make mistakes, so we need to add another number. So if you could go back to the code and add "wizz" whenever it's a multiple of 7, you'll see yours is much much easier to amend and the second is not.

(I like pair programming but I don't think the above is a good example of it)

Re: Use Dependency Injection, Your Tests will Thank You

iconara — Mon, 11 Jun 2012 03:42:19 -0000

Um, if you set @power to "off" I assume you would also use "on" for the opposite case, and that means it would fail too.

Re: Use Dependency Injection, Your Tests will Thank You

Felipe Iketani — Sun, 10 Jun 2012 21:49:53 -0000

The issue about !!@power or only @power is that if I set @power = 'off', both of then would fail for example.
in my opinion, any method finishing with '?' should be careful. that's why i enjoy @power == true

Re: Use Dependency Injection, Your Tests will Thank You

iconara — Sun, 10 Jun 2012 16:07:19 -0000

Not sure if it can be considered idiomatic, but it's common to write `!!@power` if you want to make sure you're returning a boolean. The single negation will make sure it's a boolean, and the double makes sure it's not negated.

Re: Use Dependency Injection, Your Tests will Thank You

Ray — Sat, 02 Jun 2012 11:10:40 -0000

Nice one

Re: Use Dependency Injection, Your Tests will Thank You

Jarmo Pertman — Sat, 02 Jun 2012 10:19:29 -0000

And using RSpec you can do like this:
subject.should be_on

instead of
subject.on?.should be_true

Re: Use Dependency Injection, Your Tests will Thank You

Kreimer Georg — Fri, 01 Jun 2012 12:57:35 -0000

Agree, once @power would be set more complex it makes sense :)

Re: Use Dependency Injection, Your Tests will Thank You

Felipe Iketani — Fri, 01 Jun 2012 10:27:20 -0000

personal taste :)

@power == true can return only true of false.

@power just can return anything.. i just follow this convention

this is a really small class, so @power == true may seem silly. but i think it's still readable and understandable.

just a personal taste

Re: Use Dependency Injection, Your Tests will Thank You

Kreimer Georg — Fri, 01 Jun 2012 10:16:20 -0000

Why not just?

def on? @power end

Re: Use Dependency Injection, Your Tests will Thank You

Felipe Iketani — Fri, 01 Jun 2012 09:54:52 -0000

Objects on Rails is very good indeed. I also suggest every one to read it!

The purpose of this post is not about using DI and Outside in development in Rails, but in any kind of project/test.

Good approaches are framework agnostics.

Re: Use Dependency Injection, Your Tests will Thank You

Felipe Iketani — Fri, 01 Jun 2012 09:52:13 -0000

yeah, really ugly, it was the kind of stuff that i forgot to refactor before publishing.. but you're right!

thanks for the feedback

Re: Use Dependency Injection, Your Tests will Thank You

Felipe Iketani — Fri, 01 Jun 2012 09:50:50 -0000

thanks, this was new to me :)

Re: Use Dependency Injection, Your Tests will Thank You

krisleech — Fri, 01 Jun 2012 06:47:04 -0000

Nice example and thoughts. To add to @nmk `@power == true ? true : false` should be `!!@power`, the double !! will ensure false is returned if `@power` is nil.

Re: Use Dependency Injection, Your Tests will Thank You

nmk — Fri, 01 Jun 2012 05:47:47 -0000

Lecturing on DI and writing abominations like

@power == true ? true : false

don't mix well.