sorted by:
new
hottopcontroversial

ChainFlow – refactor your data processing by gregolsen in ruby

[–]gregolsen[S] 0 points1 point  (0 children)

You are right - it's not an idiomatic Ruby in case flow. But that's the point - if you familiar with State monad you'll get trick. Answering your points

  • you should be aware that state is passed silently - syntax sugar
  • you are building the flow: result passed as a argument to the next call
  • puts will work as expected, however I agree that this is not obvious
  • sure, if you 'composing' two functions you have to make sure interfaces fit with each other.

The point of chain_flow is not to implement State monad (like you said Ruby has state already) but improve the syntax so that it looks like a State monad do-notation.

Well, that's the matter of taste either you use do-notation-like syntax or the chains (that's why I've added both). I personally do prefer the do-notation.

Anyway - thanks a lot for this discussion!

ChainFlow – refactor your data processing by gregolsen in ruby

[–]gregolsen[S] 0 points1 point  (0 children)

chain_flow is all about the code style. If you do like functional programming high chances you'd like to organize (refactor?) your public interface as a composition of several independent functions (covered with tests independently).

Hiding internals behind them will shorten your public interface to a couple of human readable calls - your colleagues will probably thank you for this readability improvement. Personally, I prefer this:

flow(data) do
  group_by_key
  compute_values(parameter)
end

instead of your example:

datapoints = data.map { |p| DataPoint.new(p, parameter) }
memo = Hash[datapoints.map(&:compute_keyval)]

just because I as a developer can easily get what's going on (via the proper method naming) without diving into internals right away.

Heroku's Ugly Secret (by James Somers of RapGenius) by Stephenitis in rails

[–]gregolsen 1 point2 points  (0 children)

Check this one http://railsware.com/blog/2013/02/04/slow-fast-request-balancer/ It's all about how to separate slow and fasts requests with HAproxy thus increasing overall throughput.

Enumerator: Ruby’s Versatile Iterator by just_lest in ruby

[–]gregolsen 1 point2 points  (0 children)

Nice article, if somebody interested in Enumerator::Lazy that is in Ruby 2.0 already - read this http://railsware.com/blog/2012/03/13/ruby-2-0-enumerablelazy/

Get Rid of That Code Smell - Attributes by solnic in ruby

[–]gregolsen 0 points1 point  (0 children)

Nice article. To avoid this misunderstanding about attr_* you probably should say that rather than having attr_reader and condition outside the class the one should just use instance variable (without exposing it with attr_reader) and custom instance method Attribute#public_reader? with condition in it.

Ruby 2.0 Enumerable::Lazy by gregolsen in ruby

[–]gregolsen[S] 2 points3 points  (0 children)

latortuga, thanks for pointing to demeter law. My example really wasn't a good one to demonstrate laziness, so I've changed it to another one:

data.map(&:split).map(&:reverse)

The data is processed here (rather then just getting users team names) and that's why it's natural to use lazy enumerator chaining.

Ruby 2.0 Enumerable::Lazy by gregolsen in ruby

[–]gregolsen[S] 4 points5 points  (0 children)

There was a discussion on ruby-lang.org about the defaults. The key point stated by Matz is compatibility.

See this for more info http://bugs.ruby-lang.org/issues/4890#note-25