The Ruby Way
I've wanted to tackle Ruby for quite some time. Luckily, Addison-Wesley just sent me a copy of The Ruby Way, Second Edition by Hal Fulton. This is one of those books that makes me think publishers feel the need to sell books by the pound. The sad part about that is that, in many cases, books printed by the pound contain tons of fluff and useless information. Not so with The Ruby Way. Every page contains gems valuable for anyone who wants to program with Ruby.
But this isn't a book review, per se. If it were, I'd recommend The Ruby Way without reservation. Anyone even remotely interested in Ruby should get this book, now. It's worth every penny of $39.99 US.
But here's what really inspired me to write about this book. There are pages upon pages devoted to the unintuitive twists in the Ruby language. There are so many quirks that I'm almost afraid to tackle my first Ruby program.
To cite one example from the book, in the following code, x ends up equal to "false".
y = false
z = true
x = y or z
The reason for this is that Ruby evaluates = before it evaluates the "or". I imagine this would be terribly unintuitive to a Ruby newcomer, and would lead to a lot of wasted debugging time. Even now that I know this juicy tidbit, I'm sure I'd make the above mistake at least a few times before I could consistently remember how Ruby works.
Obviously, you can force Ruby to evaluate the "or" expression this way:
y = false
z = true
x = (y or z)
If this was a rare quirk of Ruby, I wouldn't give it much thought. But, as I said, there are pages upon pages of explanation on how Ruby deviates from traditional programming practices.
Granted, I'm new to Ruby. Maybe you Ruby programmers out there are keenly aware of the various oddities in Ruby and take them for granted. In some cases I can see how the quirks aren't quirks at all, but necessary decisions on the part of Ruby designers in order to give Ruby more power. I'm still at the point where I'm asking, "Why on earth would anyone design a lanaguage to do that?" Maybe if I programmed in Ruby for six months, I'd find out why all of these design decisions make sense. My first impression, however, was that I'd never remember all these oddities when tackling my first Ruby programs, and I'd spend the first month trying to figure out why nothing works the way I expect it to work.
Nevertheless, it would be foolish to take this as a launching point for a Ruby rant. The overwhelming success of Ruby speaks for itself. There must be an ultimate payoff for learning it.
So here's my question to you Ruby aficianados. Did you have trouble adjusting to The Ruby Way of doing things? How long did it take for you to get used to Ruby's approach to objects, classes, instances, and the various oddities? How long was it before you started to feel like you really began tapping the power inherent in the language, and how much of that power do you attribute to Ruby's unique approach?
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Google's SwiftShader Released
- Interview with Patrick Volkerding
- Tech Tip: Really Simple HTTP Server with Python
- My +1 Sword of Productivity
- SUSE LLC's SUSE Manager
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
- Returning Values from Bash Functions
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide