I was born and raised in Texas. Attended Rice, the Naval Academy, and Stanford, BSEE and MSEE, worked in product marketing management in silicon valley before starting and running companies, and have enjoyed two IPOs.
The downvotes are overzealous in this case. A comment like this offers useful additional info/context about other languages that offer comparable capability, since many developers keep more than one type of screwdriver in their toolbox (or at least like to stay abreast of how their screwdriver du jour compares with other tools).
It looks to me like the tabular data is inconsistent with the visualization - the tables showed 0 perished from first or second class or crew, the visualization showed something entirely different.
We do something similar, but a little simpler. Each object in our database has a short guid. (In our case, the guids have a type-identifier so by inspection we can tell if a guid is for a user, or text message, or whatever.) We pass the guid to the worker.
However, it requires giving an app 'try-git' access to your private and public repositories... so afterwards, probably a good idea to edit your profile, click Applications, then remove the try_git app.
Sometimes, when you apply real-world numbers, a single forcing function overwhelms any other subtleties in the analysis. The analysis in this case fails to address the extraordinarily high cost of nagging John must endure when Marsha is inconvenienced N(J) as opposed to the other way around. Since N(J) = K * N(M), and K is never less than 50 IMO, strategy M will be the winner. Always.
I'm pretty sure nothing qualifies as "always the best" solution. "The cloud" can be an imperfect solution yet still be the best solution for certain apps.
Yep. So I think the more general advice is also simpler: work on problems you find interesting.
Sometimes the ones that seem small lead to big things (I got an IPO out of one such). Often - ouch! - the ones that initially seem like they will be Important turn out to be ho-hum. But regardless of ultimate Importance (however you choose to measure that), it is a RUSH every time you find an elegant solution.
That's why even as an 'old guy' I still love developing so much... even a relatively modest app provides daily doses of interesting sub-problems to crack.
You say "pass the buck" I say "tell the truth." Heroku's current message says it's an "application error" even when it is not an application error. It is incorrect. And I suggested one simple way to correct it. They could word the message as they see fit, but platform_problem != application_error. What percent of customer grok/care about the difference is irrelevant... an incorrect error message should be corrected.
IMO for purposes of a demand letter on a small matter like this you could almost pick an attorney at random. Call a couple of solo lawyers who have small ads the yellow pages, explain what you want, ask for a quote for the initial demand letter. Also, instruct them to take NO further billable action after sending the letter w/o your express permission (to avoid them racking up another hour's fee to "review the reply" if your former employer sends them a reply). If they get a reply instead of a check, they should simply forward it to you. At THAT point contact your state labor board.
I doubt it requires anywhere near 10 dynos, normally I just run 1, and I suspect 2 or 3 dynos would work fine today... but since 10 dynos only costs 45 cents per hour, and it's presumably just for an hour or two, I simply threw two handfuls at the problem and went back to my actual work. Handling a one-time spike didn't seem like something worth optimizing when I could throw the price of a cup of coffee at the problem.
Actually I do not disagree.... I make the platform choices, so i live with the results. However, IMO an error message that distinguishes between an "hosting" issue and an "app" issue is not only fair, it is in fact, meaningful data to (at least some) customers.
re your second point: Yeah I pondered that, and they could make the "ooops" more generic. However, we freely talk about being on Heroku since by and large it seems to engender customer confidence. And it's exactly a secret since the dns will point to proxy.heroku.com after all.
Assuming the check is more than a couple hundred bucks, hire an attorney for $100 to $200 to send a demand letter for the paycheck plus your attorney costs to date. (Don't let the attorney do a lot of 'research' make it clear that initially you just want a demand letter. This establishes that the expense goes up the longer they delay. Or, file a small claims action.
I agree. There is a very simple way to do this which I just posted (since it apparently hasn't occurred to Heroku). All they need to do is change the default app error message once they have confirmed they have a platform issue. So within a few minutes of an outage, a better message is displayed to our customers that does NOT make it look like we screwed up. http://blog.pardner.com/2012/06/dear-heroku-dammit-quit-blam...
Around 1980, while still a Stanford student, I used Laboratory Microsystems' PCForth to write a editing/publishing system for SAT math preparation, complete with embedded figures and equations and animated answers. The 'aha' at the time was to store the graphics not as bitmaps, but as a stream of parameters that were interpreted, allowing my system to save hundreds of quiz questions on a single floppy. That vector approach also made editing objects and layers trivially simple. Got the attention of ETS and Addison Wesley, both of whom flew me out to demonstrate how I did it.
But when I started building my own software product to sell and support, adding things like one of the first networked learning management systems and a homemade graphics windowing system (schools were MSDOS or Apple II in the day, if you wanted a GUI you built one) I switched everything over to C even though that meant teaching myself C and re-architecting everything from scratch.
Creating and working with abstraction layers was critical to that project's success, and simply not doable in Forth. So I've always thought of Forth as kind of like a first girlfriend - maybe not "The One" but a delightful and important phase that helped me learn what was important to me.
We are extremely happy with Zerigo. Great UX, with things like import/export of records, and ready-to-go snippets for email hosted at Godaddy etc and Heroku-hosted domains. They have a free plan (3 domains, 50k queries/mo). IMO their $19/year (20 domains, 1M queries/mo) and $39/year plan (45 domains, 2M queries/mo) are "pretty close" to free.
We have a rather high threshold for pain if it leads to better customer service and relationships. (Eg, what's feasible depends on the perceived benefit.)
Because in our app, if there are bounce-backs or deliverability issues we want them to come to us, not to our user who is trying to send an email blast.
That makes sense. If my app was dealing with, say, medical records info, we would assuredly not want to forward mis-replies... in that case it would make more sense to use an auto responder that might say something like "To protect the security of your personal info ..."
While the article is a useful comparison of straight EC2 vs dedicated servers, it doesn't touch on the cloud PaaS options such as Heroku that eliminate so many complications of installing and tuning and maintaining your frameworks. IMO comparing "cloud vs dedicated" without reference to PaaS options is akin to comparing "combustion engines to bicycles" without mentioning motorcycles.
Sendgrid supports this and we have used it to allow our users to have our system send emails on their behalf. The caveats are: (1) your email will contain info in the header that indicates it's on behalf of, which probably affects deliverability somewhat (we got very good results nonetheless) and (2) to get good deliverability your account probably needs to be at least "silver" level service which gives you dedicated IP address and some associated whitelabeling DNS entries. In other words, the more trustwoorthy your mailer domain is, the better deliverability you will experience.