Try to sit in the middle of the carriage. I don't get motion sickness on trains, but I find doing that makes a meaningful difference to how comfortable it is to type on a laptop on a commuter train.

In terms of a concrete example of what we actually use it for, http://www.nature.com/srep/ is using Shunter, as is http://www.nature.com/search?journal=srep&q=physics&subject=. Behind the scenes they're completely different apps, but they use the same implementation of the visual language so there's a consistent UI.

Develop a sense of curiosity, get into the habit of asking yourself why things are they way they are, even if you don't need to know the answer. Read widely about technology and follow the threads to new topics. Try things just to see how/if they work. Go's a great start - it'll get you thinking about programming language design, concurrency, networking, etc., and all of those will lead to something else.

You'll also need to be comfortable thinking about things you don't understand. If everything you do is familiar to you you're not thinking broadly enough.

Yes, I've experienced this exact problem in the past.

From the article: "To be clear, Malik isn’t talking about Kickstarter where funders make a donation that acts like a pre-order. He’s talking about the public buying stock in private companies, something that may soon be legal thanks to the JOBS Act..."

I think breckinloggins's point was that people may be willing to make equity investments for reasons other than profit.

(Now I'm wondering whether startups will be allowed to offer rewards in exchange for funding, leading to more "X is not a store" backlash.)

I think the total energy available at ground level is something closer to 250W/m^2.

It's 1kW/m^2, which, given cell efficiencies of ~25% gives you your 250W/m^2 value. I goofed saying 1W/m^2.

It's even called stereolithography :-)

This doesn't seem that bad to me, what problems is it causing?

The only changes I'd make would be to wrap it up in a script so you have one-click deploys, and possibly implement the 'copy and symlink' strategy that Capistrano uses so you have minimal downtime during deploys and instant roll-backs if necessary.

It isn't causing any problems! But in a recent thread on git deployment, there was a tonne of hate for this method

... one other thing though. With a bit of practice you can remove the need to develop on feature branches; break things down into really small chunks and get into the habit of making half-done features unobtrusive (e.g. hiding UI elements until they're ready). That way you can push to master often and have confidence it'll always be safe to deploy, which simplifies your tooling and reduces the scope for merge conflicts etc.

I personally find branching a lot better than the method you described. Master is always safe to deploy in my current setup and I don't usually get merge conflicts :-)

Don't worry about it then - there are more important things to spend your time doing.

That should never be necessary; if you invest in the appropriate automation you can get your regular deployment process down to a few minutes and then even emergency fixes can go through the normal channels. The benefit is of course mainly the ease of day to day deployment, but it does mean that in those emergency cases you don't need to worry about what you've forgotten to do, or how your changes might mess up the assumptions baked into the automated system.

So, obvious question... why do you not have tests in this set up?

I answered this above.

The code base doesn't have unit tests. It was built by a hobbiest 4 years ago. The current version supports legacy features from a previous version. It is mainly procedural with a smattering of random classes. There is a lot of code duplication. It is the definition of spaghetti code.

Honestly I wouldn't know where to begin with unit tests in this code base.