Google Sheets was down
sheets.google.com
sheets.google.com
data: {
error: {
code: 503,
message: 'The service is currently unavailable.',
errors: [
{
message: 'The service is currently unavailable.',
domain: 'global',
reason: 'backendError'
}
],
status: 'UNAVAILABLE'
}
}And scripts will time out and abort after just a few seconds (meaning they can only execute relatively few operations). So there is a very hard impenetrable wall blocking what you can do with scripting Google Sheets.
I particularly wish Google sheets had the tables feature.
I think the collaboration benefits of Google Sheets is high enough that it can be the default for most employees. Perhaps MS Excel should be used only by specialists, like how only a fraction of any company uses Photoshop.
EDIT: https://news.ycombinator.com/item?id=17304660 (June 2018)
> Excel is a different world and a big-big elephant that won't likely be rewritten any years soon. Think of a code that is maintained over 30 years. Literally, developers are still maintaining code written in the 90s. Trying to bring Excel to the online world made MS create an architecture of html frontend which communicates with a dll session behind the scenes. As weird as it sounds, this dll lives as long as the browser has the spreadsheet opened. Think of it as MS raising VM for every excel file that is opened over the internet. While this is not very cost effective (saying the least) and not very performance friendly (hey ma! I made an understatement) this allowed them to move forward with Excel online very quickly by having a UI communicating with the bloatware dll that runs on the background in Azure. Summarizing Excel, it probably won't also be rewritten in js.
There was zero compatibility to maintain, zero code to port, etc.
So, you can't just get rid of PhotoShop, any more than you can just get rid of Excel.
I mean, ok lack of keyboard shortcuts and all when I'm wroking on masks, but when I'm not on a deadline it's fine
In my mind, collaborative software is like git, with a clear commit history.
Is google sheets that collaborative? Or do you need to trust the people you share it with?
"size" - what?
"some of the external tools" - duh? But what on earth are using using "external tools" integrated to Excel for?
Off the top of my head: Operation Research... i.e. serious calculations to decide where to spend a lot of money, like: Where should I build my power station? I know, for this I will get my mixed integer programming suite out. Where is that in Google sheets???
// note, I adore Sheets, but it definitely definitely cannot compete with excel for serious computation suites or even modest visualisations.
But yes, add-on tools are going to be platform-dependent in both directions.
Sheets -> Great collaborative experience for simple to moderate complexity use cases.
Excel -> The heavy artillery.
The trade-off of functionality and general control isn't worth for the "Share! Collaborate! Contribute!" hype.
"For what I use it for" I guess, but after going full Linux I've been on LibreOffice [or similar] alternatives. Just not Google Sheets if I can ever, ever help it.
Now I moved to US & do not have dedicated desk, & strictly not allowed to plug anything in work pc, fireable offense. So I am back to use Google Sheets because I can access those at my phone, & Sheets is not the same. Maybe 50%, but many simple things in Excel are difficult in Sheets. The most being Calculate Formula button in Excel.
Or was that just me?
My preferred tool is python, I use javascript and/or SQL when I need to, I have dabbled in R, I have programmed in legacy applications on mainframes. Spreadsheets are more widely used than any of these, for doing computing that impacts how organizations actually run.
Though it was interesting that googling "google sheets down" and clicking News returned 3 results regarding winter weather bedding and 0 results about Google Sheets.
Surely if the problem is "the cloud disappeared", that's more a case of sunburn? ¯\_(ツ)_/¯
Currently have to download my files from Google and work on them in Excel and Word to get work done.
Did this affect gsuite as well? Either was I'm sure the TOS would never allow it. While you're at it suing google, might as well get a precedent set making TOS unenforceable.
Drive stayed up for us though
I find things break down very quickly (based on number of collaborators or file size), and I'm writing (yet again) some type of Flask-Admin server. Retool (https://retool.com) is another option I've considered.
Any others?
https://developers.google.com/apps-script
Start here for custom functions:
https://developers.google.com/apps-script/quickstart/custom-...
Array functions are weird in scripts, but just playing around with them should help understand how they work.
What kind of limits do you find you hit regarding the number of collaborators?
An exemplar to aspire to, for sure. Bravo!
Any chance of actually doing something about the response to microsoft's query about using python as a macro language?
The landing page is so "clean" it doesn't even include it as link. And I was quick scanning for links to click.
Which response was that? :)
A database.
How is that manageable or efficient and not error prone compared to a database or just csv processed with python or other code?
I know of a fair few banks that settle trades using Excel spreadsheets.
Salesforce is also a platform that lets you do practically anything without coding. Beware though: here lie dragons, a hellish programming experience... and incredible levels of career stability as a Salesforce consultant.
And Google was suppose to compete with Microsoft Azure or Office 365?
I wouldn't notice Google rerouting my search queries to a slightly stale cluster in a different data center, but they can hardly serve me someone else's spreadsheets until consistency has been restored.
Eg.: https://twitter.com/iittmee/status/1173772524573908997 https://twitter.com/cryptoITGuy/status/1173773323970523136
Not even specific to Google, but a product like Search has less outages because it doesn't require authentication / authorization checks, one search requires very little network bandwidth (unlike say YouTube) and can even work if some / most / all systems needs to go into a read only mode.
> SRE’s goal is no longer "zero outages"; rather, SREs and product developers aim to spend the error budget getting maximum feature velocity. This change makes all the difference. An outage is no longer a "bad" thing—it is an expected part of the process of innovation, and an occurrence that both development and SRE teams manage rather than fear.
I suspect Search has a lower error budget than Sheets.
[1] https://landing.google.com/sre/sre-book/chapters/introductio...
As a user, outages are always bad things. That Google's SRE team thinks otherwise is chilling.
So yeah, outages are always bad, but the alternatives can be worse.
I don't think that I would, because I don't accept the premise of that being the necessary choice. It's just the choice that the providers deign to offer for economic reasons.
But my objection isn't that there should be zero downtime. My objection is the idea that a service provider considers any downtime to be acceptable.
If you don't view any downtime to be acceptable, the logical thing to do is invest all of your resources into reducing downtime. This means solely investing in reliability infrastructure, redundancy, and making few or no changes to the system, since change introduces failure.
Since no service does that, the logical conclusion is that very few people actually consider any downtime unacceptable. Broadly speaking, I can think of literally no service that advertises "zero downtime". Cold storage gets close, but even they offer a measly 12 or 16 9s of reliability.
In other words, reliability is a business goal, much like any other business goal. Trying to achieve "perfect" reliability with limited resources isn't a good time. So looking at error budgets empowers SREs. You can go to leaders and say "hey we're exceeding our error budget, so we not making any more changes and only working on reliability until we're back within our agreed reliability."
My point was not that I expect zero downtime or perfect reliability. My point is that I expect that companies don't consider downtime to be an acceptable and normal thing.
And my point is that if a company isn't doing this, they're idiots. SRE is entirely about planning for downtime. You have incident response procedures to minimize downtime when problems happen. You have tools like error budgets to make explicit your organizational goals. But all of these are predicated on the assumption that incidents (and downtime) are a "normal" thing that will happen.
Again, if SRE's goal is solely to minimize downtime at the cost of other organizational priorities, there's a very simple way to do that: disallow all new features and maintain the same app today. That would easily cut outages for most apps by a factor of ten.
> My point is that I expect that companies don't consider downtime to be an acceptable
So you think its unacceptable to have an SLA? That's a very common way of making explicit the amount of downtime the organization feels is acceptable. This kind of error budgets is just a non-public SLA that's used to guide development, as opposed to pay people. I'm curious what companies you use that publish 100% uptime guarantees, or similar SLAs.
Perhaps we mean different things by "acceptable". SLAs are a promise that downtime won't exceed certain levels. They are not a declaration that downtime is "acceptable", only that it's inevitable and is an attempt to characterize that inevitability.
What I mean is that when downtime happens, nobody at the company should be think "this is fine". They should be very concerned and engaging in urgent and speedy resolution to the problem.
The idea that a service is expecting and accepting downtime as part of normal operation and, even worse, as part of some sort of tradeoff with regards to developing new features is just bizarre and unacceptable to me.
It indicates a level of unconcern about customer needs and experience that renders the service untrustworthy.
Being aware of that trade off is more organizationally mature than not
> What I mean is that when downtime happens, nobody at the company should be think "this is fine". They should be very concerned and engaging in urgent and speedy resolution to the problem.
If you think this, you've entirely misunderstood. Error budgets aren't about outages when they happen. Individual outages should be dealt with quickly and without delay. But when making planning decisions for the next year or quarter, that's when error budgets matter.
> Traditional operations teams and their counterparts in product development thus often end up in conflict, most visibly over how quickly software can be released to production. At their core, the development teams want to launch new features and see them adopted by users. At their core, the ops teams want to make sure the service doesn’t break while they are holding the pager. Because most outages are caused by some kind of change—a new configuration, a new feature launch, or a new type of user traffic—the two teams’ goals are fundamentally in tension.
...
> The use of an error budget resolves the structural conflict of incentives between development and SRE. SRE’s goal is no longer "zero outages"; rather, SREs and product developers aim to spend the error budget getting maximum feature velocity. This change makes all the difference.
...
> ...the decision to stop releases for the remainder of the quarter once an error budget is depleted might not be embraced by a product development team unless mandated by their management.
Examples:
Single data center outage:
Search -> load balancers handle that just fine
Cloud -> zone or sub-zone outage
Backend failure:
Search -> cache should handle that
Cloud -> outage
Data update failure:
Search -> stale search results
Cloud -> outage
Office 365 also has issues, they can be minimized but cannot be eliminated: https://twitter.com/msft365status?lang=en