I don't think it's Alice Springs. It's probably all users that wrote "Australia" as location + Alice Springs is actually a little northern that this bar.
I wish I had your naivety; but I already sow things like a media center that counts heads and will stop the movie if the amount of people exceeds the number allowed by the purchased licence...
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 work on an app with a lot of custom UI - custom UIControls, heavily custom UIViews, etc. Storyboard is a complete no-go for us because of this. Its primary strength - the nearly-WYSIWYG preview, is completely gone, and what's left is the insane XIB system and lack of scriptability.
The app I work on also does a great deal of custom drawing instead of relying on a truckload of assets. This has given us incredible speed and flexibility where we can tweak, refine, and polish without tiresome trips to our designers for assets (perk: your designers don't hate you for the endless grunt work). None of this fits well into a Storyboard-based workflow.
There is, IMO, a lot to be said for proceduralizing your UI instead of a reliance on a massive bundle of assets. It's a topic I do not see being covered in the iOS community but confers incredible speed and flexibility (and download size, oh man the download size).
AFAIK the reason that this isn't very common in the iOS community is that loading an image is often much faster (performance wise) than drawing a custom UI. What are your experiences with this?
Depends on size of image. The file system, while much faster than a spinning disk, is still slow enough that saving/loading large files (say, nearly-full-screen-sized) has a noticeable performance impact. Especially if you do it on the main thread (as people tend to do).
If this asset is nothing more than a gradient with some trimmings, it'll be substantially faster to just draw it. Also bear in mind that manual drawing in iOS is blisteringly fast.
You are right though - blitting a 32x32 icon to screen from a cached image is substantially faster than translating it from a vector format (say, an icon font). That being said, all of the iOS devices in common use today have a large amount of CPU performance headroom that makes this rather moot. We have absolutely no trouble hitting 60fps consistently drawing all of our own UI procedurally. Your main bottleneck is in your GPU's fill rate (and even then, only on the original iPhone 4), which limits the amount of overdraw/offscreen rendering you can do.
Some things in iOS-land are still slow. CALayer shadows for example are very slow if you use them directly out of the box (where they determine the visible mask of the layer and cast a shadow based on that). But they are very, very fast if you know the magic buttons to push (e.g., setting the shadow path to a fixed shape). Proceduralizing your entire UI definitely takes a bit of experience with Core Animation and Core Graphics.
The workflow gains we make, though, are massive. All of our iconography is vector-based, and all of our UI dynamically drawn. Need that button a different shade of green? Done. Need to change the depressed state of the button? Done. Icon a bit small? Done. Shadow should be a touch lighter? Done. We do take some performance loss for this, in theory, but since there is so much headroom it doesn't actually translate to a noticeably (read: sub-60-fps) degraded experience.
In addition to the points that you made, there's the issue of source control as well. XIBs have always been a pain with source control, but if one insisted it was workable. I just haven't seen a way to make storyboards work with more than dev and not end up with someone going bald from pulling their hair out.
In many ways it saddens me that Silverlight is now passe. As Silverlight solved this problem extremely well. If you followed the MVVM pattern correctly, and kept all code out of the XAML, then a designer could fully design the UI of an app in Expression Blend and they are actually designing the app. They just call into the ViewModel when they need to hook in functionality.
RAD tools always serve a limited goal - which causes the inflexibility. When your goal changes you will be stuck with this tool and RAD turns into SAD.
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.
Source: I know a lot of Googlers and find salaries interesting