Naked Thought

"Coffee is a way of stealing time that should by rights belong to your older self."

metabren — Sat, 17 Dec 2011 11:35:21 +1300

“Coffee is a way of stealing time that should by rights belong to your older self.””

- Terry Pratchett via Rancilio’s newsletter (via consciousstartups)

Site down, SITE DOWN!

metabren — Tue, 11 Oct 2011 17:16:00 +1300

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 20965 2011-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.

This sweet little number was crafted for our latest...

metabren — Fri, 30 Sep 2011 21:30:00 +1300

This sweet little number was crafted for our latest creation, Puzzle Love. It’s a simple little Objective-C control producing a two-digit analogue counter. Retina-ready, NACounter comes with a “Do what you want as long as you don’t call it your own and re-sell it” licence. Grab it on GitHub & enjoy :)

We're here, now.

metabren — Fri, 30 Sep 2011 16:05:00 +1300

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.

All times ship

metabren — Fri, 23 Sep 2011 14:33:00 +1200

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.

Maybe or maybe not. A 50/50 chance. Pah! I’ll risk it to get the biscuit. I’ll release it when it’s done.

But it’s not really 50/50. Chances are your “week longer” will change into two, three, one month, two months, maybe more. And even after all of this:

People still might not like your product - it might not solve a stubborn enough problem for them or they might not find it enjoyable to use.

You still might not like your UI even after the redesign.

Your logo might still look crap.

Your product might be used in ways that you never thought of, requiring another redesign.

All the time you’ve taken to perfect your baby, and you’re probably going to have to spend at least that again. That’s not even the worst of it. Worst case, while you’re busy perfecting your baby, someone else has come along and taken the wind out of your sails.

They’ve built your idea.

Not all is lost though - is it? They’ve done it badly. The UI is average. It’s missing key features. The logo is crap. There’s no sharing involved. There’s still a chance you can release something that ticks all these boxes before they get around to it right?

Maybe. But there’s one huge problem with your plan. Even though this product is “inferior” to the one you’re building in almost every way, people like it. No, they love it. It’s been posted to Hacker news. People rave about it on Twitter. Even you use it and like it. They’ve tested the market. They’ve got a boat-load of users. And now they’re adding everything you thought it was missing to begin with.

But this won’t happen, right? I’m writing this blog post is because of Picahso. It was our pet project - Broken Picture Telephone for the iPhone. What’s Broken Picture Telephone? Check out Doodle or Die. It was made by Dylan Greene for Node Knockout. It’s simple, ~~it’s ugly~~ it’s looking better now and, it’s fun - so fun in fact that it won the “most fun” prize for the competition. He’s already got traction & users, and he’s now building Doodleblast as a “proper” version of his creation - for the web & mobile devices.

Picahso, is dead. Before it even hit the water.

That’s why, ladies and gentleman, you should definitely, always, ship.

p.s. This post might be crap, but at least it’s shipped :-)

^BK

The story of the App Store and the gloss

paupino — Tue, 30 Aug 2011 14:39:00 +1200

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.

Great. So why today when I uploaded my App Store icon did it apply a gloss effect automatically?

Well, funnily enough the reason was simply the order I uploaded the binary and the icon. I already had a developer rejected binary on iTunes Connect which rendered a gloss effect (from In-App Purchase testing *grumble*grumble*). Because I uploaded the new app store icon before the new application binary, the gloss effect was assumed from the original binary and applied automatically. The fix was, of course, to re-upload the new App Store icon once my new “info.plist fixed” binary version had registered.

Perhaps this will save 30 minutes of your day - lesson is to be wary of the binary that may already be present when you upload your App Store icon!

^PM

Cave Quisquiliae (Beware of Garbage!)

paupino — Sun, 28 Aug 2011 14:40:00 +1200

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!

Symptoms

The first thing I took a look at is any trends that were seen from Performance Monitor (perfmon.exe). Obviously something was going wrong - was it paging? Memory? Disk queuing? Mystical tumblbeasts gnawing at the servers?

Interestingly enough there were some noticable trends:

Allocated bytes per second on the increase
Gen 0, Gen 1 and Gen 2 Collections on the increase
% Time in GC on the increase

The interesting one to note here is the percentage time spent collecting garbage was going up and up. I think we have a clear indicator!

Diagnosis

Obviously, if the system is spending more and more time doing garbage collection, it is spending less and less time doing the work your application is designed to do. This explains the symptom that was being seen: the number of transactions being processed getting lower and lower. So what makes the system spend more and more time in garbage collection? Well, more trash!

Since I love personifying things…

Every .NET application (or Java for that matter) has a dedicated “janitor” which goes around cleaning up trash. He’s quite a clever and effective this janitor: he knows what is trash and what is still being used. If it is still being used, he’ll postpone checking it during the next quick cleanup. He is only human (!) though - if there is too much trash then he isn’t going to be able to keep up and trash is going to start piling up around the place. In this case, he is going to be spending longer and longer wading through the rubbish and throwing away what isn’t needed! I guess if this goes on and on, he’ll eventually go into early retirement - taking your app with him!

Treatment

Now we have an idea about what’s wrong, the next step is to find out what is generating all of this trash to see if we can be a little more “environmentally friendly” with our usage of objects! I’ve used a few memory profilers for .NET and one stands out from the rest: .NET Memory Profiler. After installing this I noticed a few things:

String generation was incredibly high. This was largely from:
- Cavalier use of String.Split (it was being used lazily)
- There were a lot of unnecessary character to string conversions
- String concatenations were used in some areas which were used inefficiently
Object cloning of highly linked objects in caches (i.e. one object cached would generate 1000 new objects)
Object construction was incredibly resource intensive for some object types. There was a lot of metadata which didn’t change between instantiations which was being re-generated every time
Strings were being used in places where enumerations or value types would be better suited

Luckily this was all treatable. So off to work I went fixing this up. Some interesting changes:

There were a lot of “quick wins” with strings. These were attacked first for a proof of concept. After attacking these, the transaction speed increased to 120 transactions per minute.
The object cache worked much more effectively by serializing when entering and retrieving from the cache. The overhead of serialization was minimal compared to the overhead of cloning large objects.
Static metadata made an INCREDIBLE difference, namely due to the heavy use of these objects throughout the system.

After fixing just these things I noticed the difference of generation of new objects vs removed objects go from 30,000 over a ten minute period to -200 objects. Much much nicer to see!

To cut a long story short - not only did I end up fixing the problem, but the system sped up substantially. It was processing 150 transactions per minute without slowdown. All from taking an environmentally friendly approach to trash :-)

Conclusion

For most systems, this is unlikely to be a noticable problem however for enterprise systems I think it is important to consider every time you write a line of code. Every piece of code should be considered:

What objects are being created behind the scenes?
Is this piece of code a core piece of logic?

Obviously core logic being called often is going to generate trash at a faster rate!

In closing: “Beware of Garbage” when coding… even the highest end systems will notice slow down from too much trash.

^PM

iPhone Simulator Case Sensitivity

paupino — Thu, 28 Jul 2011 14:37:00 +1200

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?

Well, it appears the the simulator is case insensitive when referring to resources whereas the devices are case sensitive. So if our resource is key-a.png then we must refer to it with that exact casing (i.e. @”key-a.png”) for it to work on both the simulator and on the device.

Why the iPhone simulator is case insensitive is beyond me, but nevertheless this is how it behaves!

^PM

Unit testing with GHUnit on the iPhone

paupino — Thu, 30 Jun 2011 14:37:00 +1200

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