Google Docs gets an API for task automation
techcrunch.com
techcrunch.com
So many dumb business processes rely on an Excel doc somewhere, or a stupid manual email somewhere else. But with Flow I've seen just a single smarty-pants able to fully streamline an entire department one rule at a time. They don't need to get permission to bring in a new logo - it's part of Office, they can just do it. And no one has to get dragged into it kicking and screaming - you want to work off of an Excel file? Fine! It's still there!
It feels like a hit of Agile steroids for an older organization.
It's like IFTTT/Zapier/Huginn, but by Microsoft. It has all the advanced scriptability you'd need, but it's still missing some of the best parts of those solutions.
Definitely cloud-centric, and reaches into on-premises data through an optional on-premises data connection agent.
You'd be surprised at how much you can do with it.
(edit: especially powerful if you're using SharePoint)
And then you get that one user who takes the collaborative document, downloads it to their desktop, then emails everyone a revision.
This is a constant struggle for me. It took about 3 years, but I had most of our company using google docs and not working locally much. Then a critical mass of newcomers came and the IT department decided we should move away from google docs and so provided a file server. A year later, a few people of us are stubbornly using google docs but 80% of our files are scattered across the fileserver and desktops. And you can be sure that whatever you find on the fileserver is not the latest version.
While I’m on a rant, the same people refuse to use commenting features and instead add red text and text boxes all over the place.
My team does analytics consulting work for large multi-agency marketing campaigns, and I used Flow and a shared mailbox to create sanity around managing the constant flood of daily/weekly/monthly data snapshots that get emailed and have to be synthesized and combined for end reporting/analysis.
I was also able to use Flow and PowerBI to duct tape together a "starter data lake" architecture for our marketing clients. It's been a wild success with clients, due in part because of it's price (in context to their expectations for traditional "data lake pitches") but even more so due to the fact that it gets rubber stamped through any IT review thanks to being all part of Microsoft. It fits most clients workflows and data volumes, and seamlessly transitions to a true data lake by pulling in Azure services as needs mature.
Most marketing departments are swimming in data but pretty lacking in their access to technical and process/operations resources to truly manage and leverage it. Flow has been a fantastic tool to introduce structured data management and automation for these clients, as it's low cost enough to slide under the radar, already implicitly allowed software as part of their Office 365 license, and gives them tangible results to show when asking for more budget to develop/mature it further. It's far from my favorite stack to use, but it's good enough to get the job done and breezes through all of the checks and objections and red tape that would make virtually any other stack dead on arrival.
I'm torn between two worlds. One side applauds the grass roots based solutions and the JFDI attitude. The other side is concerned that these solutions becomes widely used, de facto production, and problems upstream ends up breaking the output. On error, hopefully fails loudly but subtle problems could creep in. If the reports are consumed by other automation, the problem spreads rapidly.
Ideally the IT department would take a step back, assess what the users (you the stakeholder) needs are, and provide the solutions. Better Agile.
Using the successes to drive more development and operations budget is the way to go.
(in case other ppl wonder what it means... =) )
This was an example of that. We do client consulting work, but we're only about 2% of the total revenue of our Fortune 500 parent and our IT policies are not conducive to client-driven work requirements. When my manager looked for what we could use when supporting analytics-oriented aspects of client work, tools like Supermetrics[1] were explicitly denied and IT provided virtually no automation/analytics solutions short of a complete Tableau server, which is prohibitively expensive for most of our clients' needs (especially when allocating IT infrastructure & support costs in addition to the license). I'm not a fan of the fragility and monotony of repetitive manual data collection and reporting, nor do clients like to pay for the excessive hours that takes on a recurring basis compared to competing bids (because presumably our competitors can use SaaS tools for automating rote process).
I scrounged around and found a pocket of PowerBI users in our IT's SQL Server team. Connected with the director over that team and got access for myself. Created a proof of concept architecture that provided an agile platform to address the full spectrum of our potential needs from "throw in basic analytics for free and eat the cost" to "maintain a full on data lake getting a deluge of real time data streams". Client users are guests invited to our tenant, log in with their (usually) already-existing Office 365/AzureAD user, can have the $10/user/month PowerBI Pro license added to their account via their corporate IT, our corporate IT, or a credit card expense. All of their ETL and data connectors and credentials and PowerBI models are compartmentalized into their own app workspace and subject to corporate DLP policies and accessible/auditable by Office admins. It's technically unsanctioned/shadow IT, but I ran it by the director of that team in case I needed to tap his team for sporadic support needs in the future, and he was both interested in my proposed usage and perfectly fine giving it his blessing (which is great, because his team manages the permissions I need for provisioning users, adding licenses, and creating workspaces).
The alternative would have been to either lose business due to non-competitive bids, use a combination of unsanctioned SaaS tools that get expensed and subject to disruption when turnover happens and passwords don't get shared or credit card renewals don't occur (fairly common scenario I've inherited), or using development skills to create custom automation that would be unmaintainable when I left.
> Ideally the IT department would take a step back, assess what the users (you the stakeholder) needs are, and provide the solutions. Better Agile.
This works well in some cases, but falls flat on it's face just as often. It's often prohibitively expensive from a budgetary standpoint for a business team to pull in resources for a needs analysis and subsequent project. Business users are far cheaper, so the vast majority of drift between needs and systems capabilities/processes go unresolved because it's cheaper to absorb the inefficiency on the business labor for quite a while before it hits a critical point that justifies the expense of pulling in ops/dev staff. For most business teams, shadow IT is a pragmatic stopgap solution to hit their deliverables, similar to the type of tech debt you see in IT projects that gets kicked down the road until it's suddenly not something that can be kicked anymore. And the process of IT stumbling across a grass roots solution acting as a de facto production dependency is basically a litmus test for when the debt finally comes due and triggers a formal needs analysis and IT project.
As well, that type of needs analysis generally creates localized optimizations or poor user adoption. The current needs will be a reflection of the processes that evolved within the current system and constraints, and addressing the directly will usually just result in a solution that's "a faster horse". Or it goes to the other extreme, where the solution you provide is state of the art and it turns out they have no ability to transition from riding their current horse to piloting the new fighter jet you provided.
A far more effective approach is to creative a collaborative model. Grass roots based solutions exist for a multitude of reasons and won't ever go away. But the concerns of undocumented, unknown, and potentially unmaintained de facto production dependencies existing outside of the purview of IT is a very real concern. So create a migration path. Put in low friction processes, support structures, and policies that give power users on the business side the ability to create sanctioned grass roots solutions. It'll allow business teams to experiment with and build up competencies and informed opinions on newer capabilities and possibilities, allowing for more nuanced and effective needs analysis for major projects. And it also provides enough oversight and management for IT to step in when usage patterns indicate something has become de facto production and warrants a more formal transition to/evaluation by technical and operations stakeholders. And also provides valuable data to ops/IT on where people are needing to create grass root solutions in general, which can better inform their own future systems planning.
This approach was taken with Lotus Notes. The ivory tower decided who could create and control a database. All it does is throw up bureaucratic barriers people will work around. How much of your company is dependent on bespoke Excel databases? What better tools can you empower the employees with to mitigate that risk?
A given Firm should also be providing a way for Shadow IT project to brought into the light, formally adopted and supported.
I happened to be exposed to that model at one of my first professional jobs, and it was such an incredibly effective and seemingly obvious organizational structure that I presumed it was normal. Every job I've had since then has just deepened my appreciation for the brilliance and skill of whatever executive team pulled that off, as I've realized just how rare it is.
Fascinatingly enough, the organizational structure of that giant, traditional company bore a striking resemblance to how a software architect would approach designing a modern SOA on a cloud platform. And when the same principles of an SOA were applied to the design of the organization itself, the same communication structures, advantages, and trade offs emerged.
Which makes sense. Organizations and software are incredibly similar systems, and the parallels between the two allow for pretty seamless transfer of principles, best practices, pitfalls, mental frameworks, optimization opportunities, and reference architectures between organizational design and software design. Which is probably one of the hidden strengths of tech founders and the companies they create, since they'll implicitly infuse their experience at software design into the way they design all aspects of their company, even if they don't recognize they're doing it. Which is a competitive advantage over traditional business leaders that likely only have exposure to standard organizational design practices/teachings.
Plus it wont be randomly cancelled when Google decides they got bored with it after several years of neglecting it first.
I've always wondered why Google is so bad at keeping various services going. Your comment caused me to reflect that Google hires a lot of smart people. Smart people tend to get bored with working on the same thing and want to work on new shiny things. Could it be that the smart people at Google do a bang up job of creating new services, but then get bored and move on to something new, leaving the previous service to slowly die and eventually get abandoned?
I'm starting to believe that it might be simply because low quality software is hard to maintain. They have some very complex software, but nothing of great quality. They might hire a lot of smart people, but not very many that are actually good at developing quality software. It appears that being smart doesn't make you diligent in your work, or give you an eye for detail.
Examples of this bad quality are simply everywhere; cursor left and right too fast in Google Image Search and that functionality breaks until you use the mouse to select the next image. Want to reply in Gmail, you have to click the reply button twice for the reply pane to appear. This is really basic stuff, and suggests a lack of competency in developing quality software, and a lack of care.
They are huge, but they are actually not very good.
but i see where you're coming from, it's "konkurencja" in Polish :)
Not to say that every point is spot-on, but it’s true that Google in general makes their software and UIs complicated enough that outside of perhaps search or betas, they don’t update or change them all that frequently, maybe every two years at best. Apple or Microsoft could by now show them a thing or two on how to iterate user interfaces annually to evolve UI instead of making drastic changes folks might not like or sticking with the status quo forever with rollouts via obscure settings panels.
I will fight to death anyone who says different.
>Letterboxing causes burn-in on OLEDs, not exactly ideal for a screen saver.
They letterbox the portrait photos correctly. Well, sort of. They have a small gap between the top/bottom of the TV and the top/bottom of the photo. The letterbox area uses part of the photo so there's no additional risk of burn in. Even if they did just use black, I don't think black can be burned in.
This doesn't happen to me, and a quick Google (ha) isn't turning up complaint posts about it. This might just be a you thing.
Have you used Google maps? Or Google {search,photos}?
I get the feeling that they have two very different grades of software they write, and the stuff written by the varsity is so good that it's invisible to it's users.
This. They seem to hire people who are excellent Computer Scientists, but that DOESN'T make you an excellent software engineer!
The result is what we often see from Google: A product with an impressive/complex algorithm (whether it be AI or efficiency) wrapped in terrible software prone to tons of bugs and breakage.
In a deeply fundamental way, every service or software product that isn't part of the revenue stream doesn't really matter to the business and there is no incentive to maintain it.
The problem is that maintaining existing projects generally isn't considered to be a demonstration of impact (or at least, it's a MUCH harder case to make). It's much easier to make the case that greenfield projects demonstrate impact.
Additionally, engineers have a good amount of power over what they get to work on: managers generally have to convince them to join a team. It's nice in concept, but lacks a steady influx of unwitting new engineers to help support all the not-so-sexy projects (like many other companies).
…so, you tend to see a pattern of engineers building a new thing, launching it, and then moving on to the next project. Leaving a trail of poorly supported projects in their wake.
The promotion process is how you described though, PMs don't get promoted for maintaining projects, or even improvement on some metrics (that engineers are very good at), they always want new shiny stuff to brag about.
Then again, if its just a matter of cutting any project that won't make billions, the point is moot.
Google cancels stuff. A lot? Maybe but they have a lot of products.
But it's not without logic and it's much less likely to effect paid products and core services. How many parts of Docs/Drive have been cancelled? How many GCP components?
Next time someone is about to post another "Google cancels everything!" comment I hope they might pause and think whether it's plausible in this specific case. (And maybe pause to consider whether they are adding anything new to the debate or just repeating the same point that's been made a thousand times previously)
1. A group of pinned emails in one place. I can star things, and they end up in "Primary". But if I then go to the "Promotions" or "Updates" folder and select all -> archive the starred items get picked up too.
2. Same complaint as above, but for "Important" emails. Except "Important" emails aren't moved into "Primary", they are ALL left in their regular boxes.
3. Does not have an endless scroll of emails. I need to click back and forth between pages to see them all. Select all only selects my current page of emails.
4. If I choose priority inbox I lose the ability to select all documents in a given inbox. The above are fixed with priority inbox, but then I can't select all. I switch back and forth once a week because I'm honestly not sure which features are more painful to live without.
If I could have a separate box for important/ starred and display ALL of my unarchived emails on the screen I'd be happy. Inbox taught me to make heavy use of archive and keeping an empty inbox except for what's essential... And then they provided no tools for continuing to use it this way.
As a consumer of several of those products, I could not give less ducks what their problem is. That's an excuse for a Google PM to say to themselves.
Google's cancelling of products hurts me, and presumably others, and I wont trust it with business critical tasks when there's Amazon and Microsoft that have a much better developer record.
People helpers are good tech support: "I'm sure I can help you. I've done this a thousand times."
Problem solvers are not: "I'm going out of my mind. I've done this a thousand times!"
It's more complicated than that, with people falling somewhere on an X-Y graph, some skewing one way and some the other.
Also, I used to think that all the values were positive. But there are those who not only don't help, they make the situation worse. And those who can't solve the problem, but make that worse, too.
What would be nice is if Google were to have someone who scored more on the "people helper" part. "Yes, this is older and boring but it's what people are used to and we're going to maintain it."
And actually I’ve lost edits with just plain synchronization on an iPad. I was on a plane, I edited a document I had, putting a lot of effort into it, then when my plane landed and the Internet came back, my changes vanished with no history recorded.
https://www.youtube.com/watch?v=4EKWKJc4b4c
I've seen a handful of these over the last few years, but this one does look like it hit the right UI/UX spot.
The only reason they don't have more penetration into dev mindshare is because their tech stacks are generally in the dark ages (looking at you, BluePrism and Automation Anywhere!).
That said, I've been pretty happy with UiPath, both from an openness perspective and a technical one. They've got a free trial license to test drive it too, which is nice compared to the usual "Call us for a quote" sales BS.
https://www.uipath.com/developers/community-edition-download
If anyone wants to chat enterprise process automation, feel free to hit me on email. It's been my weird niche for the past few years. Username.co at gmail.
It also has capabilities that allows you to connect to any REST API - look up Custom Connectors.
Finally, if you don't have Office 365, you can sign up for a free account using your personal Outlook / Microsoft account to test the waters.
Disclaimer: I work on Microsoft Flow and am very excited to see it here on YC.
That's a sentence I never thought I would hear.
It would be so much easier, if the us finally stopped using this middle-endian date format. It's logically flawed and too prone for misinterpretation. Further the US is the only country in the world to insist on using it. yyyy-mm-dd or dd-mm-yyyy are both fine (I actually prefer the first, though my country uses the latter) and logically consistent.
While they are at it, they could also switch to the metric system.
Re: formulas, they are all in german which means that unless I know the german equivalent word that microsoft chose, I can't make any modifications or even really write new formulas.
I feel the pain with the function names. I know some in German and some in English, because I just switched to the native language at some point. But the translations are easily findable in the web [1] and there is even a built in function translator tool [2].
[1] https://www.excel-function-translation.com/index.php?page=en...
[2] https://support.office.com/en-us/article/excel-functions-tra...
Granted, Flow is still in development but I could not recommend it for production or anything of importance. They are few possibilities for backup (the browser based packaging doesn't count), nor any kind of functionality for advanced administration. I know Flow does also target non-developer audiences, but that is not an excuse to skip basic features.
I think being able to model workflows is essential for companies that do not want to spend large amounts of money on custom solutions. They can really remove a lot of busywork. The lack of real competition amazes me. Everyone would profit from a good workflow engine.
So Flow is only good, because alternatives are basically absent.
What particular use-cases can it solve? E.g. is it easy to template Word/Excel document generation with it?
Is it just that you don't have to write any code to use Flow?
"just"? that seems like a massive selling point to me. If the people that are supposed to use the tool in a company are not technical (or not technical enough) it doesn't matter how good the tool is, the first check is "does it need programming skills"
Pet peeve: it is impossible to do a wysiwyg document in Google docs, it will come out subtly different on almost every computer/browser combo and in the end will come out different again when exported as a PDF resulting in endless cycles of revisions.
then for sheets, being able to work in "apps script" is fantastic. apparently you can use typescript in excel with some third party tools but surely they all stink in some way, and won't product portable documents. and anyway, VB is ok enough and has its own strengths.
otherwise, Office completely blows away google apps.
If anything, the one character -> eight bits problem was so large huge amounts of work has been put into developing and using libraries that abstract the representation of text away from byte streams.
In fact, by conflating them you are implicitly making the assumption that one character is one byte, which is exactly what your comment is really warning against.
Hopefully I made it clear that 'one character -> one byte -> eight bits' is an assumption that can cause a lot of pain. The simplest usage of non-standard character bytes I can think of from the top of my head is in SMS (as described in that interesting article that was submitted these last few weeks sometime) where the standard used 7-bit character bytes in order to get longer messages, and then struggled to deal with international character encodings.
Maybe it's drawing a long bow, but I think this specific example is of the same class of assumptions that jacquesm was describing when they said "a byte is 8 bits", and clearly this is a problem that will not "only cause trouble in rare cases".
x86 is far from the only 1 byte = 8 bits architecture... PowerPC, SPARC, Itanium, ARM, MIPS, heck, I'm having a hard time remembering major non 8 bit-multiple architectures.
To give you one example of a non-8 bit architecture, I used to work on CSR Bluetooth devices. For a while, the third most popular architecture was a little known thing called XAP, because it was in all of the 1-2 billion chips that CSR had made. XAP is a 16 bit processor in every way you can be a 16 bit processor: both the size of a byte (minimum addressable memory size) and the size of a word (size used for compilation) was 16 bit. You couldn't sub-address any larger types to serialise data. Also, the code space was separate from data space, and so function pointers were 24 bit (2 words). This meant that a lot of casting that developers take for granted wasn't possible (e.g. store a pointer in an int).
All of these choices meant that the XAP was very low gate count, and so very power and cost efficient for a surprisingly capable little processor.
And then Google ban your account for some random reason and you're suddenly barred from participating, your voice can no longer be heard, and who knows what happens to your existing contributions. I've not seen it happen first hand, but there are enough stories of people getting frozen out.
One alternative, which the Wikimedia community use, is Etherpad. It's ok for text editing but less polished.
People talk on HN about moral decisions about Google / Facebooke employees. Should that level of scrutiny apply to 3rd party plugin authors who help consolidate market share?
Every time there's a sob story that "Google killed my business by banning my Android app" there's a strong "your fault for relying on Google". But it seems like a blind spot when it comes to e.g. email and collaboration tools. Like Google's too big to fail.
While failure at a grand scale is probably unlikely at this point, I can totally see localised failure, such as a missed credit card payment or suspicious activity on an associated account causing absolute mayhem for an organisation.
For personal accounts, what happens if you create another account? It's also a big disruption, but "your voice can no longer be heard" seems exaggerated?
Let's say we're note-gathering at a conference about metadata formats for international science collaboration. Often we get remote participants who want to join the conversation, and selection bias says that they especially come from developing countries and can't afford to travel. Those constituencies may have vital information which will help to guide a standardization process for shared metadata.
If they are blocked, for whatever reason, they may be unable to contribute to the conversation. Maybe their missing voice means that metadata systems add another piece of systematic bias against them and further excludes them.
I don't know of any specific examples where this has happened, but the underpinnings are all true.
On the one hand we have people who need lots of hand-holding to use computers at all, and on the other hand there are very capable hackers for whom getting one account blocked by Google is a minor speed bump. Most of us fall somewhere in the middle in terms of resourcefulness.
There are many other barriers to getting online, including cost, connectivity, language, and cultural barriers. We're clearly not in a state of equal access. I doubt remaining in Google's good graces is all that big a contribution?
Etherpad might look more scary, but it's designed specifically to promote inclusion and liberating data.
The thing that I find inspirational about the Wikimedia example is that they embody principles of inclusivity in their tech choices.
1.) Employee creates a GDoc in a known, shared folder
2.) Application pulls all GDocs from this shared folder
3.) Application uses GDrive API to convert the GDoc to HTML
4.) HTML is displayed to the end user.
This proved to be an easy solution to having to involve a developer to fix a typo in a release note.
1- the API keys are only used on our servers and not the device, so no new worries about the key getting out and abused
2- we cache the results of the API calls for 5-10 minutes with Redis. So there's no worries about the quota or rate limits.
We've been doing this for about a year with 15,000 daily active users. When we publish a new release note roughly half read it within the first 24 hours. No issues to report.
i am having a hard time seeing myself using anything that google puts out. i have been burned way to many times.
the biggest ones? google reader, code and inbox (happening now).
sorry but it’s really hard to bet the farm on otherwise cool technology
- visit https://myaccount.google.com/language
- click on (re-choose) English
- click on New Zealand as the 'sub-language'
should set your locale across the board, rather than doing it on a per-sheet basis. If it doesn't work, as a Canadian, I empathize with your troubles and apologize.
and setting date format there useful. Not sure if it's a universal setting like the previous, though.
I'm interested whether this change will affect other Google products, in particular whether it messes up the operation of Google Assistant on my phone (possibly that can be overridden).
Cheers!
The upside to a system like that is, the authorization flow is abstracted completely out and handled by Google. You just pick from a dropdown as far as who you want to have access to the Web App URL, and you don't have to deal at all with setting up an OAuth flow.
1. https://developers.google.com/apps-script/
For Steps 1 & 2 have you looked into generating markup and using Pandoc to convert to, e.g. Word files? https://pandoc.org/
Business-oriented releases like this need to come with a guarantee of existence for X years (some reasonable number) if Google expects anyone to use this for business purposes -- especially any paid/G-suite version (or whatever their premium version is called this week). Even then, it'd be a tough sell, as simply not shutting off the servers doesn't mean they'll actually actively update and support it.
Google, an advertising company, is competing against Microsoft, a software company with its roots in this exact type of software and thousand of companies with piles of MS-specific macros and scripts and processes they've been working with since the 90s.
Half-assing it is not going to work, even if they have a free tier available.
I use Google Drive regularly for personal documents, and even for my one-person business, but I wouldn't dream of entrenching myself in it in such a way that operations could be disrupted if they decide to switch the servers off next week with two days warning.
Search isn't going away. Maps isn't going away. But everything else Google is subject to a shut off at any second. Gmail isn't going away either, but your specific account could, with no recourse or appeal or access to your data.
The question we should all be asking at the release of ANY new Google feature shouldn't be "does Google have the engineering talent to make this good?". Of course they do. If Google wanted to start making space rockets tomorrow they could. The right question is "does Google have incentive in the form of advertising revenue to keep working on this?"
I predict this is another feature that has already been abandoned as of this writing, with no further updates to come.
But it's really interesting to see how competitors evolve over time. Now HelloSign has been acquired by Dropbox, and Google Docs has launched their own document generation API.
* You have to use server-side automation - which is unsupported, and probably even violates Microsoft's terms of use.
* It's tricky. I use a serialized message queue to generate documents.
* Microsoft was dang stupid to not support automation. Such lost opportunity. I doubt that Google's supporting automation is going to change Microsoft.
From the article:
> Some of the companies that built solutions based on the new API during the preview period include Zapier, Netflix, Mailchimp and Final Draft.
disclaimer, I work at Zapier
Google Sheets has had a reasonably good API for years.
It's like Henry Ford giving people who are looking for faster and more economical transportation an assembly line instead of a car. Here is why:
- Task automation, by definition is supposed to save time and money. By building a developer API, you still need developers (whose time costs more money!) to build and maintain your automations.
- The underlying document model itself cannot be accessed. So what they've made is some kind of HandleBarJS way of creating documents and filling them in.
I'm working on something in a similar space (https://afterclass.co) and we've had to build our own document model and automation handler to work around these two problems. Would be interesting to see how this pans out :)
[0] https://developers.google.com/apps-script/reference/document...
Once you leave the simple use cases of just replacing tags it gets quite complicated, but you can build really complex documents that way [2].
[1] http://templater.info
[2] https://github.com/ngs-doo/templaterexamplesGoogle Docs already had an HTML import/export API, which allowed you to download a document, make changes, and save those changes back again. That would allow you to implement any kind of templating you like. This API just makes it slightly easier and more visible.
Yeah that's what APIs do. You can usually work with CURL requests/scraping too, but it always feels clunky and improvised, much like the method you are describing seems to me.
Making something easier means making it more accessible, means the tech based around these tools will advance faster, and that's good for everyone. It's not just a new bauble, well, except it's Google, but it will be very useful until they inevitably abandon it.
Tiny differences in html being sent seem to result in headers working or not, tables rendering differently and more.
> Google Docs already had an HTML import/export API, which allowed you to download a document, make changes, and save those changes back again.
I found that importing an export didn't result in the same looking document.
Googledocs gets annoying.
Just seems like marketing to me.
Will the feature you need last longer than Wave? Or Inbox? Will you get a shutdown notice as bad as that for the Google+ API?
People want to derisk what they deliver, and want to keep their jobs. Microsoft delivers on that, Google does not. This isn’t about emotion, it’s about pragmatism.
Hacker News has fewer than 1 million monthly active users.
Google is a deeply polarizing HN topic, where many of any article's comments reduce to snark about longevity of Google products, or proclamations that anyone using Google services is a fool who doesn't understand privacy.
Please tell us more about your theory of Google's astroturf marketing campaign on Hacker News.
https://techcrunch.com/2017/03/09/google-drive-now-has-800m-...
Removing weight from a story: https://news.ycombinator.com/item?id=16485753
Please refrain from posting inflammatory comments that do nothing to further the conversation.
By definition, credentials.json doesn't exist yet and this throws an error. Transcript below.
creds = None
if os.path.exists('token.pickle'):
...
# If there are no (valid) credentials available, let the user log in.
if not creds or not creds.valid:
if creds and creds.expired and creds.refresh_token:
...
else:
flow = InstalledAppFlow.from_client_secrets_file(
'credentials.json', SCOPES)
creds = flow.run_local_server()
$ sudo apt install python3-pip Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: grub-pc-bin libpython-all-dev libpython-dev libpython2.7 libpython2.7-dev python-all python-all-dev python-asn1crypto python-cffi-backend python-crcmod python-crypto python-cryptography python-dbus python-dev python-enum34 python-gi python-idna python-ipaddress python-keyring python-keyrings.alt python-secretstorage python-six python-wheel python-xdg python2.7-dev Use 'sudo apt autoremove' to remove them. The following NEW packages will be installed: python3-pip 0 upgraded, 1 newly installed, 0 to remove and 11 not upgraded. Need to get 114 kB of archives. After this operation, 599 kB of additional disk space will be used. Get:1 http://us-east4-c.gce.clouds.archive.ubuntu.com/ubuntu bionic-updates/universe amd64 python3-pip all 9.0.1-2.3~ubuntu1 [114 kB] Fetched 114 kB in 1s (175 kB/s) Selecting previously unselected package python3-pip. (Reading database ... 128010 files and directories currently installed.) Preparing to unpack .../python3-pip_9.0.1-2.3~ubuntu1_all.deb ... Unpacking python3-pip (9.0.1-2.3~ubuntu1) ... Setting up python3-pip (9.0.1-2.3~ubuntu1) ... Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
$ pip3 install --upgrade google-api-python-client google-auth-httplib2 google-auth-oauthlib Collecting google-api-python-client Downloading https://files.pythonhosted.org/packages/55/e9/e8fb2e3a031cb6... (56kB) 100% || 61kB 3.1MB/s Collecting google-auth-httplib2 Using cached https://files.pythonhosted.org/packages/33/49/c814d6d438b823... Collecting google-auth-oauthlib Using cached https://files.pythonhosted.org/packages/46/df/d1f94ee2cffe5a... Collecting six<2dev,>=1.6.1 (from google-api-python-client) Using cached https://files.pythonhosted.org/packages/73/fb/00a976f728d0d1... Collecting httplib2<1dev,>=0.9.2 (from google-api-python-client) Using cached https://files.pythonhosted.org/packages/ce/ed/803905d670b52f... Collecting uritemplate<4dev,>=3.0.0 (from google-api-python-client) Downloading https://files.pythonhosted.org/packages/e5/7d/9d5a640c4f8bf2... Collecting google-auth>=1.4.1 (from google-api-python-client) Using cached https://files.pythonhosted.org/packages/4e/85/71b2dfbf5b4241... Collecting requests-oauthlib>=0.7.0 (from google-auth-oauthlib) Using cached https://files.pythonhosted.org/packages/c2/e2/9fd03d55ffb70f... Collecting cachetools>=2.0.0 (from google-auth>=1.4.1->google-api-python-client) Using cached https://files.pythonhosted.org/packages/39/2b/d87fc2369242bd... Collecting pyasn1-modules>=0.2.1 (from google-auth>=1.4.1->google-api-python-client) Using cached https://files.pythonhosted.org/packages/da/98/8ddd9fa4d84065... Collecting rsa>=3.1.4 (from google-auth>=1.4.1->google-api-python-client) Using cached https://files.pythonhosted.org/packages/02/e5/38518af393f7c2... Collecting oauthlib>=3.0.0 (from requests-oauthlib>=0.7.0->google-auth-oauthlib) Using cached https://files.pythonhosted.org/packages/16/95/699466b05b72b9... Collecting requests>=2.0.0 (from requests-oauthlib>=0.7.0->google-auth-oauthlib) Using cached https://files.pythonhosted.org/packages/7d/e3/20f3d364d6c8e5... Collecting pyasn1<0.5.0,>=0.4.1 (from pyasn1-modules>=0.2.1->google-auth>=1.4.1->google-api-python-client) Using cached https://files.pythonhosted.org/packages/7b/7c/c9386b82a25115... Collecting urllib3<1.25,>=1.21.1 (from requests>=2.0.0->requests-oauthlib>=0.7.0->google-auth-oauthlib) Using cached https://files.pythonhosted.org/packages/62/00/ee1d7de624db8b... Collecting certifi>=2017.4.17 (from requests>=2.0.0->requests-oauthlib>=0.7.0->google-auth-oauthlib) Using cached https://files.pythonhosted.org/packages/9f/e0/accfc1b56b57e9... Collecting chardet<3.1.0,>=3.0.2 (from requests>=2.0.0->requests-oauthlib>=0.7.0->google-auth-oauthlib) Using cached https://files.pythonhosted.org/packages/bc/a9/01ffebfb562e42... Collecting idna<2.9,>=2.5 (from requests>=2.0.0->requests-oauthlib>=0.7.0->google-auth-oauthlib) Using cached https://files.pythonhosted.org/packages/14/2c/cd551d81dbe152... Building wheels for collected packages: httplib2 Running setup.py bdist_wheel for httplib2 ... done Stored in directory: /home/asah/.cache/pip/wheels/6d/41/4b/2b369d6e2b7eaebcdd423516d3fb659c7658c16a2be8fd04ec Successfully built httplib2 Installing collected packages: six, httplib2, cachetools, pyasn1, pyasn1-modules, rsa, google-auth, google-auth-httplib2, uritemplate, google-api-python-client, oauthlib, urllib3, certifi, chardet, idna, requests, requests-oauthlib, google-auth-oauthlib Successfully installed cachetools-3.1.0 certifi-2018.11.29 chardet-3.0.4 google-api-python-client-1.7.8 google-auth-1.6.2 google-auth-httplib2-0.0.3 google-auth-oauthlib-0.2.0 httplib2-0.12.0 idna-2.8 oauthlib-3.0.1 pyasn1-0.4.5 pyasn1-modules-0.2.4 requests-2.21.0 requests-oauthlib-1.2.0 rsa-4.0 six-1.12.0 uritemplate-3.0.0 urllib3-1.24.1
$ python quickstart.py InstalledAppFlow.from_client_secrets_file()... Traceback (most recent call last): File "quickstart.py", line 47, in <module> main() File "quickstart.py", line 32, in main 'credentials.json', SCOPES) File "/home/asah/.local/lib/python2.7/site-packages/google_auth_oauthlib/flow.py", line 171, in from_client_secrets_file with open(client_secrets_file, 'r') as json_file: IOError: [Errno 2] No such file or directory: 'credentials.json'
$ cat quickstart.py from __future__ import print_function import pickle import os.path from googleapiclient.discovery import build from google_auth_oauthlib.flow import InstalledAppFlow from google.auth.transport.requests import Request
# If modifying these scopes, delete the file token.pickle. SCOPES = ['https://www.googleapis.com/auth/documents.readonly']
# The ID of a sample document. DOCUMENT_ID = '195j9eDD3ccgjQRttHhJPymLJUCOUjs-jmwTrekvdjFE'
def main(): """Shows basic usage of the Docs API. Prints the title of a sample document. """ creds = None # The file token.pickle stores the user's access and refresh tokens, and is # created automatically when the authorization flow completes for the first # time. if os.path.exists('token.pickle'): with open('token.pickle', 'rb') as token: creds = pickle.load(token) # If there are no (valid) credentials available, let the user log in. if not creds or not creds.valid: if creds and creds.expired and creds.refresh_token: creds.refresh(Request()) else: print("InstalledAppFlow.from_client_secrets_file()...") flow = InstalledAppFlow.from_client_secrets_file( 'credentials.json', SCOPES) creds = flow.run_local_server() # Save the credentials for the next run with open('token.pickle', 'wb') as token: pickle.dump(creds, token)
service = build('docs', 'v1', credentials=creds)
# Retrieve the documents contents from the Docs service.
document = service.documents().get(documentId=DOCUMENT_ID).execute()
print('The title of the document is: {}'.format(document.get('title')))
Read the document you linked: https://developers.google.com/docs/api/quickstart/python
Read directly above and below the giant blue "ENABLE THE GOOGLE DOCS API" button.