“Coffee is a way of stealing time that should by rights belong to your older self.” — Terry Pratchett via Rancilio’s newsletter (via consciousstartups)
The website was down for a little bit today. Not the blog (♥ Tumblr), but our actual website which needs to be up so people can get in touch re: work (aside: we’re looking for work).
This is not ideal. So, what gives?
Well, we’re hosted on Heroku - which is great (we ♥ Heroku also). I thought this must be some sort of mistake, so I restarted the server:
$ heroku restart
This didn’t work (site still down), so I checked the logs to find out why:
$ heroku logs
This gave me a clue:
2011-10-10T23:59:53+00:00 heroku[web.1]: Starting process with command
bundle exec rails server thin -p 209652011-10-11T00:00:54+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch 2011-10-11T00:00:54+00:00 heroku[web.1]: Stopping process with SIGKILL
Aha! The web process failed to bind to the port! Gotcha. But what does that mean? No idea. A 20 second Google later and I have the answer (the Heroku documentation is great):
A web process took longer than 60 seconds to bind to its assigned $PORT. This error is often caused by a process being unable to reach an external resource, such as a database.
So the app can’t reach the database. Interesting. A bit of background: our website is currently static (i.e. no database). As we’re planning on using one in future for client logins etc., I had added the mongoid gem to the Gemfile in anticipation of such a system. In addition, I had also added the mongohq:free add-on to our Heroku app. This was working for about a month without issue, so what gives?
To find out I logged into Heroku, navigated to our app, clicked the “Add-Ons” drop-down menu and clicked on MongoHQ. This should take me to the remote admin console to manage the database. However, it redirected me to the MongoHQ homepage. Hmmm, interesting. As there was nothing in that database anyway, I decided to go for the quick fix - remove & re-add the add-on:
$ heroku addons:remove mongohq:free $ heroku addons:add mongohq:free
Heroku found some issue with re-adding mongohq:free:
——-> Adding mongohq:free to nakedapps… failed ! Could not create resource with vendor, please try again later
So I re-added it from the heroku.com GUI Instead (Add-Ons > MongoHQ Learn More > Add Free). This yielded no error, so I thought I was all good. Onwards with the restart:
$ heroku restart
App still not working. Still getting a redirect to the MongoHQ website. Now if you are in the same bucket as I was and are hoping that I’ve got the solution to this problem for you right here, I apologise. I don’t know why this was broken, but I’ve got a theory:
Perhaps MongoHQ lets you spawn a free instance, and if you use it - great! It lets you keep it. However, if you spawn a free instance and don’t use it within a reasonable amount of time, maybe it does the smart thing and destroys it. This would explain the redirect, and why the app couldn’t connect - no database.
So where to from here? Well, as I had eluded to previously, there’s actually no current need for a database. We just wanted the website back up. So I did some looking around for how to remove the database dependency. I found a couple of solutions. This article sums things up nicely for both Rails 2 and Rails 3 apps. As the app is running Rails 3.1, I had to change the config/application.rb file from this:
require "rails/all"
To this:
require "action_controller/railtie"
require "action_mailer/railtie"
require "active_resource/railtie"
require "rails/test_unit/railtie"
As I was running Mongoid, I had already done this - and as we know, the app was still not working. So I tried a couple more things. I commented out this line in mongoid.yml:
# uri: <%= ENV['MONGOHQ_URL'] %>
And did a push to heroku:
$ git commit -am “commented out mongo URL” $ git push heroku master
Still not working. A little more Googling and I found a hint at the solution - comment out the gems in the Gemfile. So out went:
# gem 'mongoid', '>= 2.0.1'
# gem 'bson_ext', '>= 1.3.0'
# gem 'pg'
Another commit, push & restart. This time a different error, so I checked the logs:
2011-10-11T02:58:26+00:00 app[web.1]: ActionView::Template::Error (modernizr.js isn’t precompiled)
I’m using the modernizr-rails gem to provide html5 compatibility for older browsers, and it isn’t precompiled. It’s working locally, but Heroku is complaining. Apparently it needs to be precompiled. How do we do this? Add the following line to config/application.rb:
config.assets.precompile += %w( modernizr.js )
One more commit, push & restart. Everything is working once more!
Hope this helps someone.
B.
[video]
Previously blogging as Three’s a Company on Posterous, we’ve decided it made sense to blog as our “Public” persona, Naked Apps.
So welcome, friend, to Naked Thought.
We’ve all read blog posts that tell you to release your software product while you’re still embarrased. ”Ship” they say. What do they know? Once you’ve released your product, people will judge you. Surely it’s better to wait a little bit longer and release something polished. The first impression is important, and your product sure as hell isn’t ready:
The UI is average.
It’s missing “key” features.
It’s not integrated into social networks yet.
The logo needs work.
You’ll release it when all this is done - just a week longer, that’ll be all it takes. It will take the world by storm. People will love it immediately. They’ll share it. It will go viral. You’ll be on a beach somewhere smashing back Mojitos like they’re going out of fashion in no time with all the money you make from this thing.
Maybe. But, maybe not.
Since I spent all of 30 minutes solving this problem I thought it may be a useful titbit for others!
Already well documented in the iOS Human Interface Guidelines: to remove gloss from your application AND app store icons you simply set the UIPrerenderedIcon setting in the Info.plist to YES.
This week I was contracted by a local company to investigate why their windows service was getting slower and slower over time. They would start a long running process on the service which would start off processing 100 transactions a minute however after 15 minutes would only be processing 50 minute. In fact, after one hour it would be processing as little as 5 a minute.
Why the slow down? I was hired to find out!
A funny thing happened in an application I was developing today - the exact same code behaved differently between the iPhone Simulator and a real device. The application had a custom keyboard displayed on screen (for reasons I won’t get into) — on the iPhone Simulator all keys were displayed perfectly whereas on my iPhone no keyboard was displayed at all!
Why?
After spending a long time pulling out my hair trying to get GHUnit working inside XCode 4 I finally made a breakthrough! - Thanks to this helpful answer on Stackoverflow.
While the installation instructions are exactly the same as on the GHUnit site, the magic piece of information that I was missing was mentioned right down the bottom:
Your test methods should start with
test.
Thanks for that piece of information Jano! The tests are now being loaded correctly and I can let my hair grow back again now…
^PM