Hey Matt,

Lean Domain Search is really neat – thanks for making it available.

Just wanted to let you know that it’s a really bad idea to run Ruby web apps with Webrick in production – you should be using something like nginx and either Unicorn or Passenger. Those are battle-hardened and production-ready, whereas Webrick’s sole purpose is for development environments, and, as such, is not heavily tested (if at all) for security issues and whatnot.

Just a friendly heads up. :) Thanks again.

Heroku’s Rails 3 docs are also pretty clear on this and I remember reading it during my initial upgrade, but never got around to actually doing it.

Thin is a recommended app server over Webrick (the default for rails).

Switching to Thin is pretty easy:

1. Add gem 'thin' to your Gemfile:

I added it to the production group because I want to keep using Webrick in development for now.

2. Make sure that you run bundle install to update your Gemfile otherwise you’ll receive a warning like this when you push to Heroku:

You are trying to install in deployment mode after changing
your Gemfile. Run `bundle install` elsewhere and add the
updated Gemfile.lock to version control.
You have added to the Gemfile:
* thin

3. Add a Procfile to your root directory to instruct Heroku to use Thin instead of Webrick:

4. Commit and push your updated app to Heroku.

If all went well, you should see something like this in your logs:

2012-01-18T12:44:33+00:00 app[web.1]: >> Using rack adapter
2012-01-18T12:44:33+00:00 app[web.1]: >> Thin web server (v1.3.1 codename Triple Espresso)
2012-01-18T12:44:33+00:00 app[web.1]: >> Listening on 0.0.0.0:38951, CTRL+C to stop
2012-01-18T12:44:33+00:00 app[web.1]: >> Maximum connections set to 1024
2012-01-18T12:44:34+00:00 heroku[web.1]: State changed from starting to up

Too easy.

One thing confused me though: How did Cody know that I was using Webrick? I emailed him and asked.

His response:

I mistakenly typed some bogus characters in at the end of my address bar while I was on your site…something like this: http://www.leandomainsearch.com/search?q=up^jf

Sure enough, Webrick fails loudly when the URL includes a caret:

Touché.

The first step is to sign up for an API key which takes less than a minute. The API is free up to 10,000 requests per day and cheap if you need more than that.

After you fill out the required information the site will generate an API key for you which you can use to access the API.

Here’s a simplified example of how I’m using it with in Lean Domain Search via jQuery:

$.ajax({
  url : "http://words.bighugelabs.com/api/2/youapikey/" + word + "/json?callback=?",
  dataType : 'json',
  complete : function(jqXHR, textStatus) {
    if (textStatus == 'parsererror') {
      // Did not find any synonyms
    }
  },
  success : function(data) {
    // Found synonyms
    alert(data);
  }
});

(View Gist)

Here’s an example of the returned JSON data for the word “open”:

Note that the results are broken up by part of speech (noun, adjective, etc) and are further broken up into groups (“ant” for antonyms, “rel” for related terms, “sim” for similar terms, “syn” for synonyms).

All in all it took about two hours to integrate the Big Huge Thesaurus API into Lean Domain Search and only because I added some extra functionality (sorting and filtering the synonym list, tracking what % of the searches are discovered via the synonym list, etc).

Here’s what Lean Domain Search looks like now — note the synonym list in the right column:

Click here to check out the results for “open”.

At a high level, here’s how it works:

1) Each night at 11pm, a cron job executes a Ruby script that tells Heroku to create a bundle of your site

2) At midnight, the same script downloads the bundle and moves it to your backup folder, which can either be a local directory or your Dropbox folder

Creating and Downloading a Heroku Bundle

The following Ruby script does one of things depending on whether a bundle exists or not.

If a bundle does not exist, the script tells Heroku to create one. If one does exist, the script will download it and move it to your backup location.

Creating a bundle can take some time depending on how large your site is, so you should wait a while before running the script again to download it, which is why we’re going to tell the cron job to wait an hour before downloading it.

The script takes two arguments:

1. The full path to your local Heroku application
2. The full path of your backup folder

For example, here’s how I would have the script back up jMockups:

ruby heroku_backup.rb /Users/Matt/jmockups /Users/Matt/Dropbox/Backups/

This tells the script that my app is located in /Users/Matt/jmockups and I want to save the bundle to /Users/Matt/Dropbox/Backups/.

The code:

APP_DIR = ARGV[0]
BACKUP_DIR = ARGV[1]

# run a command from your app's root directory
def cmd(str)
  return `cd #{APP_DIR}; #{str}`.sub(10.chr, '')
end

puts('* Determining bundle status...')
status = cmd('heroku bundles')

unless status.index("has no bundles.").nil?
  # No bundle currently exists, so have Heroku create one
  puts('*** Capturing bundle because none exist...')
  capture = cmd('heroku bundles:capture')
else

  bundle_name = status.split.first

  unless status.index('complete').nil?
    puts('*** Bundle was captured successfully')
    puts('* Downloading bundle...')

    download = cmd('heroku bundles:download')

    puts("*** Moving #{bundle_name} to backup location...")
    filename = download.split.last
    newname = "#{bundle_name} (#{Time.now.strftime('%Y-%m-%d %H%M%S')}).tar.gz"

    move = `mv #{APP_DIR}/#{filename} "#{BACKUP_DIR}/#{newname}"`

    puts('*** Destroying remote bundle...')
    destroy = cmd("heroku bundles:destroy #{bundle_name}")

    puts('* Done')

  end

  unless status.index('capturing').nil?
    puts('*** Still capturing. Try again in a bit...')
  end

end

Automating the Backup Process with Cron

Once you’re convinced this works as advertised, you can automate this process with cron:

1. Delete any existing bundles using the heroku bundles:destroy command. If you don’t the script will download the bundle at 11pm and capture it at midnight, which will work, but is probably opposite of what you intend
2. At the command line, type crontab -e
3. Add the following line to the crontab file, replacing the paths with your own:

0 0,23 * * * /usr/bin/ruby /Users/Matt/Documents/Backups/heroku_backup.rb /Users/Matt/jmockups /Users/Matt/Dropbox/Backups

This basically says “When the minute value of the current time is 0 and the hour is 0 or 23 (midnight or 11pm), use Ruby to run heroku_backup.rb with these parameters.”

With automatic daily backups, you can rest easier by knowing that if your site gets obliterated things will suck a little bit less. And if you have additional sites, you can simply add multiple lines to the crontab file with the information for your other apps.

Plus, it beats paying $20/month for unlimited bundles with the Heroku addon. :)

(I’m going to start going over the major projects I’ve worked on over the years.)

This project, dubbed Revolution, was my first major programming endeavor. I worked on it heavily in late 1998 and distinctly remember sending it to my friends in middle school and watching with pride as they used it to scroll massive amounts of text in random AOL chat rooms.

This was the reason I got into programming in the first place. My friend Jake sent me an AOL prog (program) and curious, I set out to learn how to build one.

The code is absolutely terrible and the only thing uglier is the design. It was a start.

Here’s some screen shots:

And here’s the menu hierarchy which shows all the exciting features:

I almost forgot about this program until I was going through some old 3.5″ disks and came upon it. I’m glad I did… I haven’t seen the words “Lagger” or “Punter” or “Fader” in many years.

Gotta love it.

So, I coded up a registration and password reset system for Domain Pigeon without setting a time limit on reset password links.

Last night, somewhat randomly, it hit me why this is a bad idea. It’s so obvious now that I don’t know why I didn’t think of it sooner.

If you reset your password in a public place, such as a library computer, the reset password URL will probably be stored in the browser navigation history. The next person who uses the computer might accidentally come across the “www.whatever.com/reset/…” URL and click it to see what happens. Surprise: it still works.

So how do you prevent this? You guessed it: a time limit.

Here’s how I implemented it for Domain Pigeon. When the customer requests a password reset email, store the time they requested it and then, to generate the URL, use a hash of the user’s email concatenated with the time they requested it. This’ll ensure that the URL is unique based on that specific request (aka a salt).

Then, when the customer clicks the link to reset his password, compare the current time to the time the link was sent and if it’s less than a specific amount of time, allow him to change his password. In pseudocode, this looks something like:

if hash(user.email + user.forgot_sent_at) = params[:hash] and user.forgot_sent_at + 2.hours > Time.now then
... yada yada yada
end

[Update: Note that the has function used here is a SHA-1 hash of the input concatenated with a secret key, so that the final product here = SHA(user.email + user.forgot_sent_at + long_random_string). Thank you to Artem for pointing out it needed to be clarified]

Lastly, after the password is changed, reset the stored time. That will prevent someone from changing the password twice using the same reset password link.

The only flaw I see with this method is for the person who clicks the link to reset his password and abandons it, because that’ll allow someone else to access the page and reset his password. Fortunately, this should be rare enough that it’s not a major problem. For extra security, set the time limit to five or ten minutes. After all, how many people request a reset password link and don’t access it within the next few minutes? For the few that do, they probably won’t mind the small annoyance in return for the extra security.

If anyone has any thoughts on this method or password reset algorithms in particular, please let me know.

I began working today with the intention of integrating a test Heroku site with Paypal’s Instant Notification System. Didn’t get there quite yet, but I’m getting there. Here’s a few things I worked on this evening:

Modifying the Terminal Prompt

Every line had been displaying “matthew-mazurs-macbook: Matt $” or something long and annoying like that, so I looked into how to change it. Some helpful individual on #rubyonrails told me to look up PS1 and surely enough, changing it is pretty easy. This site teaches you how to change it, though this method only works for the current terminal. When you reload the terminal the name reverts to its previous state. To change it permantely, you have to close down termal and edit /etc/bashrc in some text editor. Change the PS1 name to whatever you want and it’ll be changed permantently for future terminal windows. There’s probably an easier way to do this but hey, it worked.

Using VI

As nerdy readers have probably realized by now, I suck at the command prompt. I regret not taking more opportunities during my college compsci classes to gain more experience with it. Anyway, this tutorial is a pretty good introduction to what you need to know in order to navigate vi.

Ruby Gems

Up until this point in my app’s development I haven’t had to use any gems so I was pretty lost when I read I should install a Paypal gem to interact with Paypal’s Instant Payment Notification system. For the unenlightened, IPN is an alert that Paypal sends to your site when someone has made a purchase. You can use this notification to enable a user’s account, for example. Thankfully, rubygems.org offers an excellent tutorial which quickly brought me up to speed. I worked my way through their progressbar example, which as stupid as it is, was a nice thing to get working.

Fortunately, while developing ALL IN Expert (more to come on that — I promise), I spent a lot of time learning how to do IPN with PHP. Things are slightly different now, but the prior experience is helpful.

Accordingly, I made two major changes today that should:

News. A few months back, per Marc Andreessen’s advice, I subscribed to the Wall Street Journal. At first I attempted to read it on a daily basis. Now, I’m lucky if I scan it through twice a week. The problem is twofold: 1) I don’t understand a lot of it and 2) It takes time. The original purpose was to learn the important things going on in the world and in the tech industry. I think a combination of Hacker News, Inc magazine, and a few of the major blogs take care of the tech half of that goal. Usually, when my time was limited, I would just flip to the Business section and see if there were any internet related articles. For the news half, I’m going to subscribe to Time, which I think is excellent. Since they’re a weekly publication they generally avoid a lot of the irrelevent news, and they write less in one issue than the WSJ writes in a day. Starting tomorrow, I’m putting the WSJ on hold. There will hopefully come a time when I have the time and the need of reading it on a daily basis, but that time is not right now.

Computer Usage. I’ve been using InstantRails on Windows Vista in conjunction with UltraEdit for learning and programming Rails. InstantRails, as far as I can tell, is a hack that let’s Windows developers work with Rails. It gets the job done, but it just doesn’t feel natural. And so, today, I took the plunge and bought a Macbook, which I’m currently writing on. It is a breadth of fresh air; I wish I had made the switch earlier. It’s taking a bit of getting used to (I didn’t know what the traffic lights at the top of the windows were), but it’s incredibly straightforward. Usability was clearly a focus for the Mac developers, which is why it’s been such an easy transition. The plan is to do all my web development on this computer from now on.

My goal is to launch Domain Pigeon by the end of the year.

I’m going to try to write more often, as I find that it helps me to write things down.

Thanks for reading.

The last week has been very busy so I haven’t been able to make much progress, but with a full day to work I got a lot done. The site now has a registration system and a semi-well done home page. One of the designs that I put together two weeks ago (that took several hours) I completely scrapped today in favor of another. I get this feel like I’ll scrape this one in time too, but, hey, the more I iterations I go over the more I learn what doesn’t work.

After spending a lot of time playing with different layouts and color schemes I’ve come to two conclusions: 1) It isn’t very hard to make a site that looks OK. 2) It’s a lot harder to design something that looks great. I base this on the fact that the majority of websites are designed with very little attention for usability, color schemes, overall layout, navigation. Most are, well, ugly. But every now and then you stumble upon a site that just flows. You get the feeling that if you asked the designer what the padding is between two adjacent elements, he or she will be able to tell you off the top of his head. Quality matters.

Esquire has an amazingly well designed magazine. Everything just seems to fit. Inc and FastCompany too. I’ve been perusing them looking for ideas and I suggest anyone who is stuck just pay the magazine section at the local book store a visit for some inspiration.

With the limited amount of time I have to work on it, I’m trying to allocate my time better than my last project. With ALL IN Expert, I spent wayyyy too much time in the beginning worrying about the design of the website and the software. I literally spent like 10 hours one day experimenting with icons I was creating with Photoshop. This was probably a good sign that it was going to fail. I spent too much time initially deciding on nitpicky design details that really weren’t important.

On the other hand, there is value in spending small amounts of time working on the interface. Ideally, design should be driven by function. However, in my case I’m still working out the details on some of the functionality, so creating a basic site has helped narrow my focus in a lot of areas. Also, by designing the site as Igo, I’m starting to see what the final product is going to look like. It’s a pleasure watching beautiful things grow.

On an unrelated note, I’m removing the “Recommended Books” from the side bar. My original intent was just to share books that I liked, but it now strikes me as arrogant so I’m just going to nix the entire section. Also added Mark Cuban to the blogroll and removed some of the shittier ones.