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.
Just noticed this article on an Italian poker website which provides a pretty good summary of my poker bot work.
Here’s a rough translation courtesy of Google Translate:
Recently the problem has come back into favor the use of bots, automated programs that are included in the Poker Room to play, we propose in this regard the story of a player, Matt Mazor, who between 2007 and 2008 he developed and used a of these programs to play on PokerStars.
Matt Mazur was discovered in 2008 by Pokerstars and your account blocked because it used a SNG bot, the player said to have used for about 2 years in the low stakes of the room and then Matt Mazur has described in his blog all the details of ‘experience passing through the actual development of software.
His bot has played SNG from $ 2 to $ 11, Matt does not provide financial details of its program, but speaks only examples of gaps and partial information, the last month of practice states that it had a profit of $ 480 Heads-Up on 500, also states that the results have been improving during the development and upgrades made to his Bot.
Mazur present its findings by analyzing what your program has done from a technical point of view / information and presents a series of graphs which illustrates the behavior of the program over time depending on the actual size of the stack, for example, we can see the chart on the first phase of the sit when the stacks are between 50 and 75 times the BB (You can view graphs of the behavior of the bot to follow link ).
Mazur has never forced the use of his bot, taking it to multi-table up to three tables at a time, for two main reasons: the first is being able to personally monitor and analyze performance data in real time and the second to intervene in the chat when the words were mentioned and computer bots or you can write one of the first alarm bells for the bots and what not engaged in chat discussions. (Matt had developed a mechanism by which the software indicated the presence of words in chat bots, or computer).
Bot developed contrary to what one can not imagine using the SAGE system based on the balance of Nash and commonly recognized as valid in the low stakes, but an EV based system and other logic conditions developed by Mazur.
In ‘October 2008 his PokerStars account has been locked, Matt received an email from the room warned him that his account was blocked for using a poker bot, but Matt took it philosophically and unlike any other, has also gave some advice to the technical room for improving the system of defense against Bot: Matt has shown what he believes points to work on to improve the research techniques of bots on the network (You can see the correspondence he had with the Pokerstars link below ).
Matt Mazur has continued to work on programs that could improve the performance in the game starting to deal with online tracking and odds calculators.
Matt Mazur 