taybenlor

Google Australia salaries for Mid-Level Web Developers sit around the $110-150k mark. Senior Developers, team leads etc can be earning $180-300k.

Source: I know a lot of Googlers and find salaries interesting

Yeah it seems odd that there are more people in Alice Springs than in Perth. Must just be "Australia".

I feel like you're falling trap to the Slippery Slope fallacy

Things like:

  * Scalability - you can resize a button and get the correct look
  * Simplicity - you don't need to create 1x and 2x resources

Downsides are that it can be slow and it muddies up your code base.

I've personally seen points used as an area measure, but I think you're more correct. I'll update the article later tonight.

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).