Rubular is only for Ruby regexes. I wish somebody would make one for JavaScript. Jubular, anyone?

I have a novel idea; let’s not do that anymore!

There are undoubtedly dozens of solutions for this little problem, but I chose Ruby + Twitter for a few reasons:

• I like Ruby
• I like Twitter
• I want hassle-free SMS
• I want portability (small client-side configuration)

So, with those things in mind, here is what I’ve come up with:

1) A Special Twitter Account

Create a new account for your notifications. You’ll most likely want to protect its tweets unless you don’t mind just about anybody seeing all the notifications you’re sending to yourself. Once the account is set up, follow it from your main Twitter account and enable SMS notifications for its tweets.

2) A dead simple Ruby script

I’ve written about John Nunemaker’s Twitter gem a couple of times, and it once again makes its way into the toolbelt. Install if you don’t have it:

jerod@mbp:~$ sudo gem install twitter

This gem makes the notification script just a few lines of code:

You can name the script anything you like. I call it twitter_notify. Make it executable and ensure it is in your shell’s execution path (I symlink it so I can keep my code organized):

jerod@mbp:~$ chmod +x src/ruby/twitter/twitter_notify.rb
jerod@mbp:~$ ln -s ~/src/ruby/twitter/twitter_notify.rb /usr/local/bin/twitter_notify

3) A Call to Notify

Anytime you want to be notified that a command has completed, just follow it with the twitter_notify command. There are a couple of ways to do this, and they are slightly different:

jerod@mbp:~$ cp /tmp/bigfile.tgz /somewhere/else && twitter_notify "all done copying!"

Or:

jerod@mbp:~$ cp /tmp/bigfile.tgz /somewhere/else; twitter_notify "command complete!"

Using && will only call the second command if the first command completed successfully. Using ; will call the second command regardless of how the first command completed. Adjust usage depending on your circumstance.

4) A Deserved Break

Now that you’ve set up your tools to handle the grunt work, walk away from the computer! Go outside, watch a movie, hang with your fam, who cares! When that task is complete you’ll get an SMS and you can deal with it then.

That’s all I got.

def stop_error(message)
  puts "ERROR: #{message}"
  exit(1)
end

Which they call in their app like so:

stop_error "Oh noes, file doesn't exist!" unless File.exist?(file)

I used to write that method a lot too. Did you know Ruby has a built-in method that provides just what we’re all looking for?

Kernel::abort

So, stop writing your own little method and just abort it:

abort "Oh noes, file doesn't exist!" unless File.exist?(file)

The Bad News

“Bargain Bin with Push!” does pretty much exactly what my app was going to do. It provides push notifications when apps you’re interested in drop in price. Instead of raging against the dying of the light, I’ve decided to just user their app and let mine go gently into that good night.

The Good News

All was not lost. I learned a ton along the way and decided to open-source the module I was using to fetch app information out of Apple’s App Store.

The Goods

The code is on GitHub, of course. Clone, fork and branch to your heart’s content. Hopefully somebody will find it useful.

“provides a clean ruby syntax for defining messy cron jobs and running them Whenever.”

Whenever has become very popular for use with Rails apps and there are plenty of tutorials on how to use it. This RailsCast is a good place to get started if you’re interested in that.

However, I haven’t seen too many people writing about using the library outside of Rails (or other web frameworks).

I have a lot of Ruby scripts running on different servers all scheduled via cron and it’s quite easy to forget what script is scheduled when and how often. I decided to try using Whenever to create the cron jobs instead of creating them manually. First, I set out to just slap arbitrary Ruby code inside of an “every” block. You know, something like this:

every :hour do
  puts "this is just some ruby that will execute every hour"
end

Unfortunately, it doesn’t work like that. If it did, that would own because then we could simply wrap all our scripts inside an “every” block and call it a day. Instead the library lets you define a few different kinds of tasks inside an “every” block.

1. rake tasks
2. external commands
3. runner scripts (Rails)

So, we can use the “command” method to execute our pre-existing scripts like so:

every 1.day, :at => '4:30 am' do
  command "/scripts/daily_backup.rb"
end

So that’s cool, but now we have to create a separate file that houses our schedule definitions and manage it as well as the scripts we want to run. What would be really cool, I thought, would be to include the schedule definitions at the top of each script. The big win in this case is easily accessible & portable schedule documentation.

One way of accomplishing this is to prepend all your Ruby scripts with a snippet similar to this:

# filename: /scripts/weekly_backup.rb
every :sunday, :at => '12pm' do
    command "/scripts/weekly_backup.rb"
end if defined?(Whenever)
 
return unless __FILE__ == $PROGRAM_NAME
 
puts "this is the start of my backup script"

When this script is executed using the “whenever” command (which you use to actually generate and install the cron jobs), the first “every” block will be used and everything after the “return” line will be ignored. When this script is executed directly, the “every” block will be ignored and everything after the “return” line will be executed.

Writing the crontab with this script will look like this:

whenever -w -f /scripts/weekly_backup.rb

Which will install a cron job that looks like this:

0 12 * * 0 /scripts/weekly_backup.rb

The major drawback to this method is we have to hard code the full path to the script instead of using the __FILE__ variable, which hurts portability. This is because Whenever “evals” the content of the file read in and in this case __FILE__ is useless. There is access to the calling file path via “Whenever::CommandLine.default_identifier” but this is currently a protected method.

This is just my first attempt at embedding scheduling information inside the script being scheduled, so there are probably easier/better ways of getting this done. Know any?

In Summary

If you are an intermediate-to-expert Ruby programmer you should absolutely read this book. Beginners may want to start elsewhere and work their way up. Where To Get It

In Detail

The beauty and power of Ruby is its dynamism which leads to freedom. The problem with freedom is it means TMTOWTDI. The problem with TMTOWTDI is best summarized by me, in a quote of myself:

“There is more than one way to do it but most of them are really, really bad.”

Thankfully, we can combat these bad coding methods by resorting to helpful idioms and best practices, and Ruby has these in spades. The purpose of RBP is stated plainly on the front cover:

“Increase Your Productivity — Write Better Code”

With that in mind, here is a breakdown of what it offers:

The first thing I noticed when reading RBP is that it uses real-world code samples. None of that “let’s make a tic-tac-toe game” type of stuff. Gregory uses a couple of his own projects (Prawn & Ruport) as well as other popular libraries (Haml, flexmock, XML Builder, Gibberish, faker). This is beyond awesome.

He also steps through a lot of code using IRB, which means you can follow right along in your favorite shell. Gregory highly recommends you get your hands dirty with the code he presents and I agree with him. However, I also like to read physical books in places not my computer, since the opportunity so rarely presents itself.

The book starts, aptly, with a chapter on testing. The following two chapters are (for me) the highlights:

Designing Beautiful APIs and Mastering the Dynamic Toolkit.

The value found in these two sections alone cover the cost of the entire book. A few of the topics discussed include: flexible argument handling, code blocks, implementing per-object behavior, building classes and modules programatically and registering hooks and callbacks. Gregory released a free section of Mastering the Dynamic Toolkit so you don’t have to take my word for it, have a taste for yourself.

I need to wrap this up or I’ll be forced to remove the “Mini” from the post title. You’ll also find sections on File & Text processing, functional programming, debugging, project maintenance (much of which is obsolete if you use the wonderful Jeweler gem), and internationalization.

Tips, tricks and suggestions abound. Even expert-level Rubyists should learn something. RBP left me wanting more of Gregory’s teaching. He really does a good job of explaining concepts and walking through code. Thankfully, he started up a Ruby Best Practices blog with more content!

Where to Buy

RBP is an O’Reilly publication and they have it on sale at their web site for $34.99.

However, I don’t know why you’d do that because Amazon has it for $23.10 and eligible for free shipping with Amazon Prime. Booyah!

If you go that route, use this link to pitch me a little something for the effort, or just buy directly via this link.

If you want to be able to toggle your development log between the default Rails logger and the console, just add this method to your ~/.irbrc:

def rails_log_to_console(toggle)
  ActiveRecord::Base.logger = toggle == true ? Logger.new(STDOUT) : RAILS_DEFAULT_LOGGER
  reload!
end

Now, you can start logging to the console at any time by doing:

>> rails_log_to_console true
Reloading...
=> true

And turn it back off as simply as:

>> rails_log_to_console false
Reloading...
=> true

Really, passing any argument except true to the method will switch the logging back to the default.

Are there any better ways to achieve this (like without having to call reload!)? If you know of one, holler back in the comments.

Hopefully this can be of use to others. YMMV:

The mixin definition:

=dead-center(!height,!width)
  :height= !height
  :margin-top= -(!height / 2)
  :top 50%
  :width= !width
  :margin-left= -(!width / 2)
  :left 50%
  :position absolute
  :text-align center

To use it on an element:

#centered
  +dead-center(200px,500px)

Now I’ll never forget how. Thanks Sass!

1) Microwavesque Deployment

When Heroku claims that you can deploy your Ruby app instantly, they’re pretty much not exaggerating. Seriously, you should try it. It’s so fast I had to ignore my spell-checker and describe it as microwavesque. Remember when microwaves first hit the scene and people couldn’t believe how fast they could “deploy” a meal? Yah me either, but the microwave changed the game big time.

If you haven’t tried deploying a Rails app to Heroku, just go do it. Here are the steps from start to finish:

rails myapp
 cd myapp
 git init
 git add .
 git commit -m "my new app"
 heroku create myapp
 git push heroku master

If that looks like too much work for you, have Remi walk you through it in this nice screencast.

2) Drag To Scale

Scaling is a problem we all want to have, but few of us do. The rest of us spend way too much time thinking about it. With Heroku’s architecture, you don’t have to think about scaling. You just do it. If you’re fortunate enough to have your app featured on TechCrunch, Slashdot, Digg, HN, Reddit, etc, etc, you simply log in to the Heroku admin panel and “crank your dynos” (love that term) to handle the load. How do you do that? By dragging a little bar vertically. How’s that for a learning curve?

Note: This isn’t the only way to ensure your app scales. You should still optimize your code for performance, but Heroku takes care of all the server configuration (compression, caching, memory allocation, etc) and you just ask for more power when you need it.

3) Rack Support

Heroku isn’t just a Rails platform, it’s a Ruby platform. They support any Rack-enabled Ruby app. Check out how many Ruby web frameworks have Rack adapters:

• Camping
• Coset
• Halcyon
• Mack
• Maveric
• Merb
• Racktools::SimpleApplication
• Ramaze
• Ruby on Rails
• Rum
• Sinatra
• Sin
• Vintage
• Waves
• Wee

That’s a long frickin’ list! Developers can pick the right tool for their need (or write their own Rack-enabled app) and not have to worry about deployment gotchas.

For example, I wanted a way to quickly resolve the public IP address of any machine I’m using (including servers) so I wrote and deployed this trivial Sinatra app in less than 5 minutes.

# public_ip.rb
require 'rubygems'
require 'sinatra'
 
get '/' do
  raw = @request.env["REMOTE_ADDR"]
  raw.match(/^(\d+\.\d+\.\d+\.\d+),?/)
  @ip = $1
  haml '=@ip'
end

# config.ru
require 'public_ip.rb'
run Sinatra::Application

The rackup file (config.ru) tells Heroku to use Sinatra to run my application. Rails would have been overkill for this, don’t you think? (Heck, Sinatra may be overkill too. You could probably write a raw Rack application in even fewer LOC, post in the comments if you have a better solution).

UPDATE: Blake Mizerany provided a few shorter examples here.

So

What Heroku offers Ruby web developers is instant deployment, fast & easy scaling, and vast tool selection. Now we can concentrate on building our applications and forget the tedious deployment and server administration tasks that used to strangle our productivity. We can deploy fast, scale quickly, and adjust to circumstance as needs arise. The game is changing, and Heroku (and others like them) are changing it.

**disclaimer**
I am only affiliated with Heroku as a customer, and receive no recompense from the ridiculous amount of props I’m throwing their way. They do have a few drawbacks, one that is a show stopper for many apps, which I will detail in a future post.

Sometimes you just need a 1GB file. Or a 350MB file. Or a 1MB file. It doesn’t matter what is in that file, but size does matter (heh).

With this little Ruby script, you can arbitrarily generate files of any size (using 1MB increments).

The Script:

The resulting file will be named “[X]MB” where X is the size you requested.

A Note:

This script is derived from one I found awhile ago somewhere on the internet (don’t remember where). It didn’t work correctly (file sizes were off) and was much more verbose.

Enjoy!