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.
I can't recommend that book enough. It's extremely well written and approaches advanced concepts in an approachable way. The book is worth the price on the basis of fizzbuzz in lambda calculus alone.
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.
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.
Thanks for linking, I enjoyed the talk. I'm currently in the middle of the "go back to school for CS" route into software development, and it was heartening to hear your success story. Between starting on CS a few years late and spending too much time on Hacker News, it's easy to feel discouraged at how little I know.
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)...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.
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?
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.
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.
If you are talking about ActiveRecord methods, `find_by_id(123)` or
`find_by("id", 123)` are a little bit wrong both, you should use a simple `find(123)`
Talks are a ridiculously awesome way to learn new things. They're low effort. They have someone else summarizing/breaking down concepts for you in digestible pieces which allow you to form your own (and hopefully not your only) base of understanding about the concept. From start to finish, the viewer is undergoing their own personal synthesis of some thing. Granted, one needs to further apply them for the concept to really solidify, but I think talks are as good as any other resource for taking that first step in learning about something.
I think it's a combination of people liking Ruby, as you said, and also just slow work day for folks in US.
I agree with the 2nd ed of Metaprogramming being a great addition to the shelf. I feel like it's been a solid year for Ruby, especially with 2.2 coming out with inc GC and symbol GC. Good times!
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.
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.
> 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.
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.
[0] https://www.youtube.com/watch?v=J1jYlPtkrqQ