

Ruby talks of 2014 - lackoftactics
http://przemekmroczek.com/post/106717411075/5-killer-ruby-talks-of-2014

======
potomak
In my opinion one of the best Ruby talks of 2014 is "Refactoring Ruby with
Monads"[0] by Tom Stuart held at Barcelona Ruby Conference.

[0]
[https://www.youtube.com/watch?v=J1jYlPtkrqQ](https://www.youtube.com/watch?v=J1jYlPtkrqQ)

~~~
hackerboos
This talk is really, really good. It is complex though so you might want to
pause/play or rewatch to really get it.

It made me nearly buy Tom's book but the only reason I didn't was because I
already owned it! I hope the book is similar to the talk.

Unicorn unix magic tricks is really good at explaining some of Unicorn's
advanced features. It shows how Unicorn uses Unix signals and forking in
detail.

~~~
wasd
The book sounds really good. Thanks for the suggestion. In case anyone is
wondering, you can learn more here:

[http://computationbook.com/](http://computationbook.com/)

~~~
marcamillion
Every once in a while, I will stumble across a thread on HN that turns out to
have been perfectly crafted for me.

I would like to thank the original poster for posting this talk and all the
other HNers for posting the follow-up info (including a link to his book).

This info came to me at the perfect time.

I figured I would make my first post on HN for the year, be a positive and
thankful one.

Thanks again :)

------
tcopeland
Here's my list of (mostly) Ruby-related good talks from this year:

[http://thomasleecopeland.com/2014/10/18/good-technical-
video...](http://thomasleecopeland.com/2014/10/18/good-technical-videos.html)

Andrew Turley's "What we can learn from COBOL" talk is probably my favorite.

------
llamataboot
I'll put a humble plug in for my talk "Care and Feeding of your Junior
Developer" from Nickel City Ruby. It was on top of Confreaks for a few weeks
and people seemed to like it, so if you are a junior, or you mentor juniors,
check it out.

[http://confreaks.com/videos/4659-nickelcityruby2014-how-
to-b...](http://confreaks.com/videos/4659-nickelcityruby2014-how-to-be-an-
awesome-junior-developer-and-why-to-hire-them)

~~~
mbrameld
This is great, thanks. I'm a senior dev who received very little mentoring
coming up. I'm now in a position where I have several junior devs working on
projects that I'm leading and I don't want to fail them the same way. I'm very
guilty of taking the keyboard and writing the code for them, that's something
I'll definitely stop right away.

------
danso
That this list got upvoted to the top spot must be some sign that the HN
audience is still enthused about Ruby-related stories (I say that has a Ruby
fan myself)...It's a good list and I'll bookmark all of its items, but it is
pretty brief, both in items (5) and in the summarization (and the use of the
overexcited cliché "killer" in the original title makes me extra curmudgeonly
about it).

Or are people really enthused about talks as a way to learn things? I haven't
been to a talk in awhile and I just can't get into video learning. So FWIW,
I'll throw in the Ruby-related-infothing that I was most excited about this
year: the publishing of "Metaprogramming Ruby 2:"
([https://pragprog.com/book/ppmetr2/metaprogramming-
ruby-2](https://pragprog.com/book/ppmetr2/metaprogramming-ruby-2))...The
original version was one of the most helpful books to me as a Ruby beginner in
2010, both in learning the language and learning new ways to think about
programming.

~~~
MichaelGG
What do you find so fantastic? I'm starting to think I'm broken, because I
just don't understand what's so amazing.

I read Metaprogramming Ruby. It seems very excited to show you how you can do
"myrow.columnname" instead of something like "myrow[" columnname"]. Likewise,
I see people absolutely tickled that they can do "find_by_id(123)" without
codegen vs "find_by("id", 123)". OK that saves a bit of syntax, but it's
hardly breakthrough. And it's more elegantly solved with a specific dynamic
lookup operator. It doesn't seem like it's worth the performance overhead or
the pitfalls of a dynamic environment (thinking of the fun Rails had in the
simple task of serializing HTTP bodies).

The only benefit I've found in Ruby that's not easily accessible in say, F#,
is having reflection easily accessible. The .Net reflection libraries are
clunkily designed. When you need it, being able to eval and such is handy. All
the pieces are there, but they don't just expose an " eval" call or whatnot.
But that's mainly a stdlib shortcoming, and wouldn't require giving up static
analysis.

Do you have any pointers to examples where metaprogramming is really useful,
to the point of paying the cost of Ruby?

~~~
asattarmd

      class Blog < ActiveRecord::Base
      end
    

Ever wonder how that works? Metaprogramming.

    
    
      enum status: [ :active, :archived ].
      validates :status, presence: true
    

Ever wonder how that works? Metaprogramming.

Used the awesome debugger, pry? Ever wonder how that works? Metaprogramming.

`find_by_id` isn't the only thing that's implemented using Metaprogramming.
Practically, everything within ActiveModel is achieved through
Metaprogramming. It is one very important reason that allows Ruby to be so
expressive.

~~~
MichaelGG
You can expose the same functionality in, say, C# or F# if you want to give up
static type checking. (Actually with F# type providers or a language with good
macros, you can keep static analysis if you're willing to bind yourself to the
database at build time.) This is just a use of dynamic binding. That's fine, I
just thought there was more to it, something that requires a lack of static
analysis, multi threading, etc.

------
meesterdude
Wow, sandi's talk was really interesting. She's working on a rails book so
i'll be interested to see her approach to rails.

I'm pretty good with "small methods" but her refactor from that to "small
objects", while more flexible, seems like its more complicated in the end. I
mean if you're going to have a lot of those it makes sense, but I feel like it
could equally be called premature; but I respect that it is more tolerant to
future unknown changes. "small methods" is also easier for a junior developer
to support, and i think that should be taken into consideration.

~~~
mbell
I really enjoyed her talk but I found some parts of it slightly contradictory,
although I think it's mostly due to a difference in opinion as to what what is
or isn't easier to reason about.

A point she made earlier in the talk is the piece that I have become more and
more in agreement with over time. Paraphrasing: 'bad abstractions are worse
than code duplication'. I would go farther and say that in the modern coding
world, premature optimization isn't the root of all evil, premature
abstraction is.

The part that I find contradictory is that breaking larger classes into tons
of little classes is, to me, a form of abstraction and carries implicit
complexicty. She does hit on this point a bit, but it's easier to dodge the
issue with simple examples than it is in the wild. Certainly there is a
'cutoff' where a class is too big, but I find that trying to make every method
1 line long and every class completely contained creates huge nested layers of
abstractions that are often difficult to follow and hard to reason about for
anyone other than the author or someone who has been working on the codebase
for a long time.

~~~
meesterdude
> trying to make every method 1 line long and every class completely contained
> creates huge nested layers of abstractions that are often difficult to
> follow and hard to reason

I agree a lot with this, and have worked on such codebases. It becomes very
difficult to tell whats actually going on, or how. or why! I think like
everything else, it's subject to abuse and misuse.

------
Aeolus98
It's interesting to note just how applicable these talks are to other
languages. That database one is something i'd recommend a high schooler listen
to for their next hackathon.

