When you receive an invitation to dinner, is it polite to save your host money by leaving before dessert? No. By default it will be rude and it would be up to you to find a nice way to do so.
Likewise I feel if an interview is scheduled for all day and you accept the invitation, then it's up to you to apologise if you want to leave early. So long as you explain that you don't want to waste their time, then no one should be narkey about it. But if you make it sound like you don't want to waste your time, then I think they have a right to be a little miffed at you.
Probably depends on your application. You may also see slower construction time if you are creating thousands of objects.
I think which to use depends on whether you believe private methods/variables are helpful or not. Some argue they are unnecessary and it's better to keep everything public. Some like to use a naming convention like an underscore prefix on private items, but declare them publicly.
You could also argue that private items are problematic if you start composing classes from other classes by extending. Then the new methods can't access the private state because they're in a different scope, whereas if they were on the prototype they could find it through `this`.
I've used both approaches but nowadays tend towards the prototype style as that seems to be the more accepted.
That's called a "privileged method". The advantage of those is that they can access any private variables from the constructor, and they keep those variables in scope for their lifetime.
The disadvantage however, is that the method is re-created once for each instance when the constructor runs, so they are not as memory-efficient as the prototype style.
Also, when you add methods to the prototype you affect all instances from the past and the future. So for example if you add a method to String.prototype, all current and future strings get it.
For ref, the heroku app is rails, 2x dynos and a shared DB with minimal traffic. The others are PHP/apache apps, one using RDS, on plain EC2.
Heroku is at least 5 layers extra to go wrong on top of EC2. On the one hand I feel that each layer adds to the probability of failure. But I'd hope that one of the benefits of Heroku would be extra redundancy and failure handling, though my limited personal experience hasn't been that way so far.
EDIT: Regarding openness, I certainly feel that every single outage is admitted by Heroku, whereas I feel Amazon's status page has not listed a few outages I've suffered. Again personal feeling, not evidence.
Instead of trying to make the native copy/paste work, can anyone think of a way to set up key bindings in OSX to mimic copy/paste but store the text in /tmp/mypasteboard or something?
Would AppleScript do it and would that work in any application?
I initially wanted Wallboardr to be a fairly free-form board that wasn't specific to any industry, but as it developed I thought that approach was lacking in power for my primary audience which was definitely developers.
But it's very interesting to see what Joel and the guys/girls have done because I think they are hitting a sweet spot between power, simplicity and industry-neutrality.
Thanks! Well customising columns is the obvious next step and is on the top of the list, so that won't be far away.
To be fair they also have comments and todo lists per card, like Pivotal, so Wallboardr is a bit behind at the moment. I've been wondering how essential sub-card todo lists are for a while, I've found myself wanting them, but MVP ideals have avoided so far.
[1] http://en.wikipedia.org/wiki/Motion_sickness#Simulation_sick...