People writing their first web app rarely do. Though in this case most of these things are covered by Rails' "Secure by Default" approach.
Also, comments like these are what turn newbies away from programming. It's really hard to start out, encouragement and a point in the right direction is what's needed.
Edit: Ahhh actually, you probably didn't realise that OP was a newbie because mods changed the title of the post. That's unfortunate. Carry on.
We've had some of our designers at work use this approach. I think it's quite good for illustrating intentions. But then building on top of the designed Storyboard doesn't quite work out.
Storyboards work well for simple apps with standard UI. Once you start building something custom or complex they are a poor tool. If you have a designer then they're likely going to be making custom UI which will need code (maybe lots of it). The Storyboard quickly becomes a crazy mess of placeholder views, implementation details, arrows and blank screens. The designer can no longer use it to demonstrate their ideas and you've probably completely ripped out their original work.
If your only intention is to make a interactive demonstration of screen progressions - then this is perfect. But don't think that this has the same reusability as making a HTML+CSS+JS mockup.
I really enjoyed this. I like the way it models the sorts of management problems one might have in the real world by interfacing with the problem in conversation and instruction.
If you go around and talk to everyone you can see what the goal is and what problems you'll face. You need to get the Radio fixed within 40 days. The engineer can fix it the fastest, however you need the rest of the team (and the fire) to support him.
As the game progresses talking to people shows different problems that could arise and how you might solve them. It's interesting as talking keeps up morale and gives you insight into how to beat the game.
You're right. I went overboard with my conclusion, the intention was to focus attention on the fact that using a single tool results in lots of similar results and to highlight the flaws in that tool. There are plenty of other tools we could use, not just the one.
Sorry, I'm not quite sure what you're saying is wrong. I understand your point about physics engines perhaps being the wrong tool here, and I can see that. But the main focus was on how the standard tooling for UI animations is incapable of modelling movement with dynamic "distances" (I put distances in quotes because you could be transitioning colour, height, scale or any other attribute of the object).
The problem isn't in timing functions. It appears whenever the "distance" involved in a transition is dynamic (rather than specified by the designer/developer).
TL;DR: If a transition changes values that are dependent on dynamic user input you get an unrealistic effect where small differences take as long to transition as large differences (because transitions usually have a fixed duration).
I got into iOS development via RubyMotion. I was a Rails developer for a few years, now I'm an iOS developer (using Objective C). I've only really started with Objective C and XCode. Objective C isn't a huge barrier, but Cocoa and XCode definitely are. That's one of the reasons I really enjoyed RubyMotion.
If I could choose (and wasn't working with other people) then I would go with RubyMotion. The toolkit is a lot less mature than XCode. But the productivity is definitely higher and there's much more room for improvement via the OSS community.
RubyMotion side-bonus: you don't have to merge (basically) binary files when you're working entirely with code for UI.
Reposting my comment from the website here (unreadable there):
I contacted support about this a while ago (was in a similar situation). Their response was "Use more than one web dyno". I didn't need more than one, but that was the only way they offered to allow my app to not "go to sleep".
Source: I know a lot of Googlers and find salaries interesting