So I finally slogged my way through Chapter 10 in Beginning Ruby. It wasn't nearly as helpful or interesting as I thought it would be. I mostly got hung up on MySql for a few days and had a hard time working through it.
I don't think I need to learn how to interact with databases just yet, so I moved on to Chapter 11: Advanced Ruby Features. Aha! Now we're talking. I spent some time working with class_eval, which allows you to add methods to a class dynamically, and exec, which allows a script to run another script.
Here are some questions I've got, though.
What's the benefit of using class_eval to add methods to a class instead of just defining those methods within the class itself? This isn't a temporary definition, right? So it seems like you'd end up writing about the same amount of code, but defining methods within the class instead of adding them later would keep the code more organized.
And when it comes to exec and fork, what's the benefit of using these commands to spread the functionality between scripts? I'm seeing this as similar to using mix-ins. For example, you could have a script that checks the time on the user's system, then either does or does not do something based on that time. It might be useful to run this script from various parts of your overall program and that's why you would want to do it. Am I thinking about this in the right way?
I'm also starting to wonder where I should go once I'm done with Beginning Ruby. The book is already warning me the last section is mostly just appendices and reference, so any recommendations are welcome.
You're right about class_eval and friends, it's a permanent definition, and it is seemingly easier to do it without class_eval. Occasionally though, you have no idea where a bit of code will be used, so you need to make the class it can reside in dynamic, similar to modules. These *_eval methods are usually used when the maximum amount of metaprogramming magic needs to be used to achieve a goal.
ReplyDeleteTo be honest, fork and exec are rarely used, but they are quite useful. Mainly they are used as an easy way to avoid threaded programming, and to spread normally single-processor Ruby code across more than one cpu. It's good that you're trying to get a grasp on these, but be aware that it is a rarely used feature for most Ruby programmers.
As far as next resources, if you feel like jumping straight into Rails, the Rails Guides [1] are an excellent resource. You could also do some of the Ruby programming challenges, but while mind-bending and fun, these are often not very useful and can lead you down roads that lead to very little that is productive.
[1] http://guides.rubyonrails.org/
I just did some work with threads while finishing up that chapter. So threads work similarly to fork and exec? That's the feeling I got, but it seems more like forking splits the program into two programs that run concurrently, whereas threads divides a process into smaller processes that run at the same time.
ReplyDeleteI've bookmarked that site, but it'll probably be a while before I'm ready for something new. The next chapter in Beginning Ruby is about tying everything together into a larger project and the chapter after that is about Ruby on Rails.
I get the feeling you showed me how little there was to Ruby so I wouldn't feel intimidated, but I'm really enjoying what I've been learning and I'm hungry for more!
RE: threads vs forking, you are absolutely correct. Forking is about duplicating processes, threading is about splitting a single process.
ReplyDeleteRE: very little to Ruby, yes that is exactly what I did. Everything else in Ruby is just more of the same, layered on to let you handle more complex things.
So which is it, are you excited to learn more or will it be a while before you're ready for something new? Those were to conflicting statements!