HNTrends was a fun little side project I worked on in 2009 to learn Flash and how to work with JSON data. You can read the original HackerNews post here, the second discussion here, and Fenin’s JavaScript port here.
Even though I haven’t worked on it for a long time, the site has been up and running (albiet a bit slowly due to the giant database).
Sadly, I need to use the hosting plan attached to it for something jMockups-related, so HNTrends will be no more.
Adios, amigo.
Yesterday I launched jMockups! You should check it out: http://www.jmockups.com
It was thrilling. I was talking to Chris and Mike on Skype yesterday evening and my wife came over and wrote on my notebook, “You are HYPER“. That describes how I was the entire day. Launching is a drug.
Some links:
You should follow me on Twitter here.
This post will explain how you can configure your machine to automatically back up your Heroku site each night and save the bundle to your Dropbox folder.
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:
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:
[ruby]
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
[/ruby]
Automating the Backup Process with Cron
Once you’re convinced this works as advertised, you can automate this process with cron:
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 intendcrontab -e0 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 taking Sebastian Marshal’s advice and making a public commitment right now to launch jMockups, the web-based high fidelity mockup tool I’ve been working on since June, by November 3rd.
The jMockups editor – the part of the app where you actually create the mockups – works pretty well. There are a few bugs, but they’re relatively minor and should be easy to resolve. That’s not to say that I am done with its development – far, far from it – but I don’t plan on making any major changes to the editor between now and the launch. It’s a decent minimum viable product.
So why not launch? Two words: billing integration.
After talking with a bunch of folks, I decided to charge for jMockups from the start. I’ve went back and forth on this, but ultimately I think it does go a long way towards defining the product and it eliminates the need for a transition down the road, which was a major headache when I did it for Preceden.
When I first started integrating billing I came up with a multi-tired pricing model that went something like this:
The problem is that I have no data to base either the prices or the limits on. It’s all just guessing on my part. I don’t know how heavily people are going to use it or how much they are willing pay for that ability. Hell, I don’t even know IF people will use it.
I could change the limits and the prices down the road, but then I could be in a situation where some customers are paying different prices than other customers for the same product. There are ways around this, but they’re all complicated and I’d rather just wait and see what happens.
And who knows, maybe there’s some other way to structure the premium plan other than by the number of mockups a person can create. Maybe, for example, the tiers are based on customized shared pages or the ability to collaborate. If I start with a model based on the number of mockups and then decide I want to change it completely, I’m going to be in a tough spot.
My current plan is to let customers create up to five mockups for free and unlimited mockups for $19.95/month after that (a freemium model). By limiting it to two plans right now, I’ll be able to expand it to four or five down the road once I have more data.
Additionally, anyone who signs up for the $19.95/mo plan, which I’m calling jMockups Pro, will automatically be upgraded to whatever the highest plan is down the road without incurring additional charges. So if I do eventually introduce a $149.95/mo plan with a killer feature set, anyone who signs up for the jMockups Pro plan will get those same features for the same $19.95/mo. This helps keep it simple right now and it rewards the early adopters who take risk by signing up for a new, unproven product.
Anyway, recurring billing integration is new to me so it’s taking a while to set it all up correctly. More on this in another post.
Meanwhile, I’m currently waiting for the paperwork to go through for jMockups LLC so I can set up a business checking account which I can tie to a merchant account to use with Authorize.net, the payment gateway. If I don’t launch by November 3rd its going to be because one of these steps is taking longer than I anticipated.
And with that, it’s off to work.
Matt Mazur 