Another solution to The Gilded Rose Code Kata

162 views
Skip to first unread message

ThirtySixthSpan

unread,
Dec 8, 2011, 10:40:15 PM12/8/11
to Oklahoma Ruby Users Group
For what it is worth, here is my very different solution that took me
a bit longer than the meeting to finish up.
https://gist.github.com/1450033

Patrick Hogan

unread,
Dec 9, 2011, 8:57:14 AM12/9/11
to ok...@googlegroups.com
Haha, nice one. :)
--
You received this message because you are subscribed to the Google Groups "Oklahoma Ruby Users Group" group.
To post to this group, send email to ok...@googlegroups.com.
To unsubscribe from this group, send email to okrb+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/okrb?hl=en.

James Gray

unread,
Dec 9, 2011, 9:42:15 AM12/9/11
to ok...@googlegroups.com
Neat.  Thanks for sharing.

James Edward Gray II 

Jonathan Camenisch

unread,
Dec 9, 2011, 9:56:20 AM12/9/11
to ok...@googlegroups.com
Had to stare at that one for a while, but I've gotta love the short length. :)


--

James Gray

unread,
Dec 9, 2011, 10:04:12 AM12/9/11
to ok...@googlegroups.com
On Fri, Dec 9, 2011 at 8:56 AM, Jonathan Camenisch <jona...@camenisch.net> wrote:
Had to stare at that one for a while, but I've gotta love the short length. :)

Sure, as long as you don't run into an item that has any special behavior outside the 11 year range.  :)

James Edward Gray II 

derrick parkhurst

unread,
Dec 9, 2011, 11:42:39 AM12/9/11
to ok...@googlegroups.com
Heh :)

I specifically aimed to sacrifice extensibility to see how far I could minimize the code base.

I've been on this kick lately to minimize the amount of code that I must write to solve a problem by avoiding over complex designs that will never be needed in actual application. Tackle the problem at hand, not the problems that _might_ arise.

Derrick

--
You received this message because you are subscribed to the Google Groups "Oklahoma Ruby Users Group" group.
To post to this group, send email to ok...@googlegroups.com.
To unsubscribe from this group, send email to okrb+uns...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/okrb?hl=en.



--

--
Derrick Parkhurst, Ph.D.
@thirtysixthspan
(405) 596-4697
derrick....@gmail.com
----------------------------------------------------------------------------------------------------------
Need video of your next event? http://videoforconferences.com
----------------------------------------------------------------------------------------------------------
Oklahoma City Coworking Collaborative - http://okcCoCo.com
----------------------------------------------------------------------------------------------------------
OpenBeta - Where Ideas meet Opportunity - http://openbeta.extendedbeta.com
----------------------------------------------------------------------------------------------------------
Thirty Sixth Span Internet Technologies - http://thirtysixthspan.com
----------------------------------------------------------------------------------------------------------

James Gray

unread,
Dec 9, 2011, 11:55:03 AM12/9/11
to ok...@googlegroups.com
On Fri, Dec 9, 2011 at 10:42 AM, derrick parkhurst <derrick....@gmail.com> wrote:
Heh :)

I specifically aimed to sacrifice extensibility to see how far I could minimize the code base.

I've been on this kick lately to minimize the amount of code that I must write to solve a problem by avoiding over complex designs that will never be needed in actual application. Tackle the problem at hand, not the problems that _might_ arise.

I think that goal is admirable.  We did discuss YAGNI last night, after all.

However, I would grade the code produced by the class last night higher on the "avoiding over complex designs" scale.  There is more code, sure, but it's extremely an straightforward OO 101 design.  That makes it super easy to understand and digest, in my opinion.  I had to twist my brain a bit to puzzle out what your version was doing in comparison.

I think it's also worth noting that your criteria favor the unrefactored version of the kata over what the class produced last night:  you can't get less complex that if/else and it's less code.  Hopefully you don't prefer that version.  ;)

James Edward Gray II

derrick parkhurst

unread,
Dec 9, 2011, 12:41:25 PM12/9/11
to ok...@googlegroups.com
On Fri, Dec 9, 2011 at 10:55 AM, James Gray <ja...@graysoftinc.com> wrote:
However, I would grade the code produced by the class last night higher on the "avoiding over complex designs" scale.  There is more code, sure, but it's extremely an straightforward OO 101 design.  That makes it super easy to understand and digest, in my opinion.  I had to twist my brain a bit to puzzle out what your version was doing in comparison.

Readability of the code for other programmers was also not a goal, so I am not surprised that your brain was twisted. :) My brain seems to work a bit differently anyway :)

I think it's also worth noting that your criteria favor the unrefactored version of the kata over what the class produced last night:  you can't get less complex that if/else and it's less code.  Hopefully you don't prefer that version.  ;)

It seems the original has many more operations in the code, and thus more chances for introducing errors when writing the code.

The other issue that pulled me towards that solution was the complexity of the rules in the problem. I get confused easily. So, the strategy I used to solve the problem was to first build a rule set before tackling any code. Once the rule set was established, it was straight forward to apply the rules.



James Gray

unread,
Dec 9, 2011, 1:01:25 PM12/9/11
to ok...@googlegroups.com
On Fri, Dec 9, 2011 at 11:41 AM, derrick parkhurst <derrick....@gmail.com> wrote:

The other issue that pulled me towards that solution was the complexity of the rules in the problem. I get confused easily. So, the strategy I used to solve the problem was to first build a rule set before tackling any code. Once the rule set was established, it was straight forward to apply the rules.

This is an interesting point.

The group did the same last night, with each rule being a new module (originally a class).  I definitely see that you're list of rules is more compact and easier to visual scan though.  I'm trying to think of how something like that could be tied into the development we did.  Perhaps "Fit" testing:


Just a thought.

James Edward Gray II

Ryan Rauh

unread,
Dec 9, 2011, 1:03:21 PM12/9/11
to ok...@googlegroups.com
could someone post the original problem for the exercise and the source code of the groups solution?

-Ryan

--

James Gray

unread,
Dec 9, 2011, 1:07:08 PM12/9/11
to ok...@googlegroups.com
On Fri, Dec 9, 2011 at 12:03 PM, Ryan Rauh <rauh...@gmail.com> wrote:
could someone post the original problem for the exercise and the source code of the groups solution?

The problem we worked is here:


Jonathan, do you still have the code "stashed" somewhere?

James Edward Gray II 

Ryan Rauh

unread,
Dec 9, 2011, 1:11:33 PM12/9/11
to ok...@googlegroups.com
thank you!

this look like an awesome exercise

-Ryan

--

Jonathan Camenisch

unread,
Dec 9, 2011, 1:44:25 PM12/9/11
to ok...@googlegroups.com
Oops. No, I purged the whole thing.

I'm sure we could type it back out without too much trouble--but it was much like your solution.


--

Jonathan Camenisch

unread,
Dec 9, 2011, 1:46:57 PM12/9/11
to ok...@googlegroups.com
Oddly enough, my first thought when approaching the problem was to do something a lot like Derrick's list of rules. Except I would have made each rule a lambda instead of an array of values.

But I've been buried in Javascript for a while. Passing callbacks around can be effective sometimes.

James Gray

unread,
Dec 9, 2011, 2:21:08 PM12/9/11
to ok...@googlegroups.com
On Fri, Dec 9, 2011 at 12:44 PM, Jonathan Camenisch <jona...@camenisch.net> wrote:
I'm sure we could type it back out without too much trouble--but it was much like your solution.

Yeah Ryan, it was really similar to this code:


James Edward Gray II 
Reply all
Reply to author
Forward
0 new messages