-
"The Passenger preference pane is a preference pane for Mac OS X, it enables you to configure a Rails or Rack application in a matter of seconds." It does. It's very good.
Links
Tagged as:
apache, deployment, osx, passenger, preferencepane, rack, ruby.
code
Tagged as:
code, deployment, development, heroku, ruby, sinatra, toybox, toys.
You can now find out what Schulze – or anyone else, for that matter – is listening to (as described in this post) on the web; just head on over to http://wotlisten.heroku.com.
The utility of the original command-line script is now diluted even farther – mainly because you now have to go to the website to scrape the web – but that wasn’t really the point of putting wotlisten online; the point was to see just how easy deploying to Heroku really was.
The answer is: remarkably so. I wrapped the original script into a little Sinatra application, with two views, and a tiny bit of error handling for convenience. Sinatra’s something I’ve been playing with for a while now: it’s really excellent for wrapping small scripts into little webapps with the bare minimum of extra code, and when combined with lightweight tools like DataMapper, and sqlite, just powerful enough for the lightweight tinkering I seem to do so much of. If you’re a Ruby developer and you haven’t played around with Sinatra, you owe it to yourself to check it out – it’s a lovely library to have in the toolbox.
With the webapp written, I installed the heroku gem, which helped me create a new remote git branch pointing at my Heroku account. Deployment is trivial – far simpler than using something like Capistrano; all that is necessary is to push my master branch to the heroku remote, and upon a successful push, Heroku notices that I’ve pushed out a Rack application – and it directs requests to it automatically.
It took about ten minutes to write the Sinatra app, and another ten to get it up and running on Heroku; the single snag I ran into was the same as Tom did – the need to unpack haml into a vendor directory.
I’m very, very impressed. It’s all very well being able to build small, trivial toys like wotlisten, but it’s often a hassle to deploy or configure them. Heroku really takes most of that pain away, and makes setting a tiny Sinatra app live a trivial task. It’s definitely going into my toolbox – or, perhaps, that should be toybox – for the near future.
Links
Tagged as:
abel, bridge, brilliant, cartoons, combo, comics, deployment, games, heroku, jumping, lightweight, pastiche, photography, programming, ruby, russia, sf4, sinatra, sport, streetfighter4, tips, video, watchmen, web.
Links
Tagged as:
defeat, deployment, development, failure, frustration, games, gerardway, mychemicalromance, performance, rails, ruby, scaling, tips, web, writing.
code
Tagged as:
capistrano, deployment, git, linux, ssh, versioncontrol.
I must have lost about six or seven hours trying to get a Rails application deploying from Git in the past week. I could push and pull from the repository, but could I get the thing to deploy via Capistrano? No, I could not.
The problem, as far as I could tell, was not with Capistrano. It was a simple SSH problem. I block port 22 for SSH on the server in question, for security reasons, and use a different port. But, no matter how I specified it, Git was insistent on trying to pull over 22. I did a lot of Googling, and found lots of conflicting answers, none of which worked.
And then I learned my lesson. That lesson is: when Linus tells you what to do, you do it:
Use the “
.ssh/config” file ;)
So I configured a hostname in .ssh/config on the server, and everything worked instantly.
A lot of problems tend to come down to SSH, it seems. After that point, everything went swimmingly.
personal
Tagged as:
brighton, deployment, me, presentation, project, skillswap, talking.
Just a quick note to say that I’ll be talking at Skillswap Brighton tonight. The talk is a re-work of a talk I gave at LRUG in London a month or two back; it’s called “Settling New Caprica“, and it’s about how to get that pet project off the ground:
Pet projects: everybody’s got them. But how many of them never see the light of day? In this talk, Tom Armitage looks at some of the obstacles that impede such projects, and how to get over them. The talk also considers some ways to streamline the process of releasing software when you’re your own client, and perhaps might give some ideas to improve not only your personal projects, but your work projects as well. There should be plenty enough time for a healthy Q&A session after the initial presentation.
The talk isn’t hugely long – about 30 minutes – but I’m hoping there’ll be some healthy discussion after it, on topics as diverse (to give you an idea of what’s coming) as personal project management, version control, deployment, and building Twitter bots for fun and profit.
Once the talk’s done and dusted, I’ll try and get a copy of it online by this weekend. Many thanks to Nat and James for the invitation to talk!