What are you going to use instead?
5,464 karma · joined January 20, 2010
I finished my PhD at UC Santa Cruz.
http://www.cflewis.com
If it's host maintenance (the machine your database is on needs to be brought down) then you should "see" the same results as Google Compute Engine live migration, which is that you hopefully see nothing :) This was one of the most common reasons a first gen instance would require restarting, alongside us pushing updates. So nixing that one, alongside the other non-restarting updates we can do now, is good stuff.
If a whole zone goes down, we start the failover process automatically for you. This is order minutes. It won't be seamless, but zones going down is hopefully a very rare occurrence.
Please email cloud-sql@google.com with your instance names and the error message, and I'll get someone to look into it for you.
Second Gen is indeed always on. Crunch the numbers for your use case, I've been told by the pricing mavens that for many use cases Second Gen ends up cheaper. And yeah, Second Gen doesn't follow your AppEngine app the way it used to. This will be a call you need to make based on your use case. If you are low-traffic and highly latency-bound and your app runs on App Engine, first gen may (may) be quicker. For other bounds (I/O, RAM, CPU) you should expect better performance from Second Gen.
What's different is that if we needed to make a change that required only querying MySQL, such as listing your databases in the UI, we would still need to bounce your instance for that functionality to come up with First Gen. With Second Gen we don't need to, so we can add many new features without restarting MySQL. I don't want to speak out of turn lest the lawyercats that come up with SLA numbers and such find me, but I am personally confident that once we exit beta, most customers should generally experience better than the 99.95% uptime we have SLA for First Gen.
We hear you. We know this is a problem. Unfortunately, there are non-trivial infrastructure changes that need to happen before we can make progress, but it's high on our list of priorities. Once we can make it happen, we will.
Right now, the proxy linked below is a good solution, particularity for Managed VMs.
Cloud SQL isn't a compatible reimplementation, it's the same vanilla MySQL that you know and love, but with a few tweaks (such as removal of SUPER privileges so you can't bork your backups, which is rather important as a managed service).
Second Generation instances should have better uptime than First Generation, as we now have live migration ala GCE if the host machine requires maintenance, and we can upgrade much of the infrastructure without restarting MySQL as we used to.
We do have failover capabilities for Second Generation instances if a zone goes down, so we're hoping between failover between zones and host migration we should have some really good uptime.
Disclaimer: I'm from Google, obvs, but I've been on HN longer than my tenure here :)
It seems like companies have the processes in place to not use styrofoam if compelled to.
They couldn't pay me enough to go back there, and I think anyone worth their time won't either. It's a mistake to build their technology building there and not near London or at least a major city like Bristol/Manchester/Edinburgh. I don't think they realize that really good programmers are worth 10 bad ones (and at least when I was there, they really didn't have the best ones to put it mildly).
When we're not talking about the sensitive stuff, there's not much magic to what many engineers write every day, it's the same "glue technology X to technology Y" stuff you see everywhere, so I don't think there's any value to hiding that in the name of secrecy.
Mercurial was pushed internally as being the "better" (for some dimension of better) between it and Git back in 2010, but I think even the most hardline Mercurial fans have realized that in order to meet developers in the middle in 2015, we need to use Git for our open-source releases. We have a large investment in Gerrit [1] and Github [2] now.
So the Mercurial comment is probably entirely based on scaling and replacement for the Piper Perforce API, rather than anything externally facing.
[1] https://www.gerritcodereview.com/ [2] https://github.com/google
TBH, this comment reads a lot like "No wireless. Less space than a nomad. Lame." [1] I'm not sure why you would buy an OnHub if you wanted to put your own distro on it (that's clearly not the target audience), USB is only disabled for now (why have it there if there were no plans to use it?) and The Verge notes that the connectivity is very good, which is what I think the target audience very much does care about.
[1] http://slashdot.org/story/01/10/23/1816257/apple-releases-ip...
All software tends to unmaintainability, even if you don't touch it (libraries change/deprecate etc). Given enough time, the problems that you are experiencing, say, memory allocation in C, get solved by something else, such as garbage collectors, and the amount of time it takes to solve the headache in what you've got is longer than just rewriting into the new language.
Often perceived NIH at large companies for this sort of thing is simply a byproduct of scale that is unreasonable for external companies to have to worry about supporting.
App Engine is very far from dead, either in the "time to turn off the service" or the "it's destaffed but the servers still run" use of the term. App Engine is well-staffed and, AFAICT, is actually growing. They're working extremely hard on getting system reliability to a place where they want it to be. [1] seems to indicate the fruits of that labor, paying off in the last month or so. Now, reliability means reliable for _all_ their customers, from the one person bedroom coder to SnapChat. They have had a big task meeting the requirements of everyone.
I can't talk to the bug triaging system of App Engine nor their future plans. That said, work continues apace to get Managed VMs [2] out of beta, and it seems like a pretty exciting new road which may be a custom better fit for larger companies.
[1] https://status.cloud.google.com/summary [2] https://cloud.google.com/appengine/docs/managed-vms/
I'm now taking Prozac which is way way better for me.
The important thing is that you have to keep trying at it; finding the right medicine and right dose will take time, but at least in my case (and it seems like others here too), there is a right formula. It's rough going for a while, but like I said before, I just feel more like the normal me, not like the angry, irritated, anxious me. And I have to believe that would have ended up a net positive productivity wise.
The wrong medicine will dull your focus (I had a very bad sedative reaction to Lexapro) but the right ones will make you feel more normal. My work is the same as it was before, except I am happier now.
In the UK, as stated for other countries, I would just use Pay As You Earn, where all taxes were extracted at the time of pay check, and would owe 0GBP at the end of the year. My Californian wife was astounded by this. "How do you know they've not got it wrong and screwed you?!" "Because I trust they got it right." "Why would you do that?!"
My read of the British is that they might not like the government or politicians, but they generally believe that government agencies get things to the letter of the law more often than not. You can disagree with the tax law, but you assume that the tax man is taking the right amount as governed by that law.
You can't pass tax reform in the US because enough of the citizenship wouldn't accept it.
TL;DR is that developers just didn't find it useful. Sometimes they knew the code was a hot spot, sometimes they didn't. But knowing that the code was a hot spot didn't provide them with any means of effecting change for the better. Imagine a compiler that just said "Hey, I think this code you just wrote is probably buggy" but then didn't tell you where, and even if you knew and fixed it, would still say it due to the fact it was maybe buggy recently. That's what TWR essentially does. That became understandably frustrating, and we have many other signals that developers can act on (e.g. FindBugs), and we risked drowning out those useful signals with this one.
Some teams did find it useful for getting individual team reports so they could focus on places for refactoring efforts, but from a global perspective, it just seemed to frustrate, so it was turned down.
From an academic perspective, I consider the paper one of my most impactful contributions, because it highlights to the bug prediction community some harsh realities that need to be overcome for bug prediction to be useful to humans. So I think the whole project was quite successful... Note that the Rahman algorithm that TWR was based on did pretty well in developer reviews at finding bad code, so it's possible it could be used for automated tools effectively, e.g. test case prioritization so you can find failures earlier in the test suite. I think automated uses are probably the most fruitful area for bug prediction efforts to focus on in the near-to-mid future.
[1] http://www.cflewis.com/publications/google.pdf?attredirects=...
We don't run the code any more and I would have to go back to the source to check, but I think that it handles renames OK, but it doesn't have any handling for splitting two files up that way.
It's a somewhat by-the-by issue, as my intuition are that the files that actually can be broken up and successfully refactored are not the same ones that are going to get flagged. The flagged files are the ones that are churning because no-one really knows how to write them any better.
OP doesn't really know what the product is himself, so cannot begin to differentiate.