From author's notes:
Let’s get this straight: The effort to host Google web fonts on your own server is immense! First of all you need to download all
.svgfiles, then copy them onto your server and finally paste a CSS snippet.
Sounds easy? Well it could be, if Google would actually provide any direct links to download these files and a customized CSS for self-hosting them. To fix this problem without using font generation services like Font Squirrel, I decided to publish a little service called google-webfonts-helper.
Prior to 2017, all W3C standards were free for anyone to implement, allowing free/open browser developers to create their own rivals to the big companies' offerings. But now, a key W3C standard requires a proprietary component to be functional, and that component is under Google's control, and the company will not authorize free/open source developers to use that component.
Uninstall tracking exploits a core element of Apple Inc.’s and Google’s mobile operating systems: push notifications. Developers have always been able to use so-called silent push notifications to ping installed apps at regular intervals without alerting the user—to refresh an inbox or social media feed while the app is running in the background, for example. But if the app doesn’t ping the developer back, the app is logged as uninstalled, and the uninstall tracking tools add those changes to the file associated with the given mobile device’s unique advertising ID, details that make it easy to identify just who’s holding the phone and advertise the app to them wherever they go.
The tools violate Apple and Google policies against using silent push notifications to build advertising audiences, says Alex Austin, CEO of Branch Metrics Inc., which makes software for developers but chose not to create an uninstall tracker. “It’s just generally sketchy to track people around the internet after they’ve opted out of using your product,” he says, adding that he expects Apple and Google to crack down on the practice soon. Apple and Google didn’t respond to requests for comment.
E-mail was once the pillar of the Internet as a truly distributed, standards-based and non-centralized means to communication with people across the planet. Today, an increasing number of services people rely on are losing federation and interoperability by companies who need to keep people engaged on their for-profit services. Much of the Internetâs communication is moving to these walled gardens, leaving those who want to run their own services in an increasingly hostile communication landscape.
The fact that Google advertises their servers as supporting CardDAV is an insult to anyone who does try to be standards compliant.
The Google CardDAV server has similarities to what we call CardDAV. For very simple, controlled stuff, it may be possible to pretend it is.
For anything advanced, avoid it at all cost.
This article outlines the scale of that codebase and details Google's custom-built monolithic source repository and the reasons the model was chosen. Google uses a homegrown version-control system to host one large codebase visible to, and used by, most of the software developers in the company. This centralized system is the foundation of many of Google's developer workflows. Here, we provide background on the systems and workflows that make feasible managing and working productively with such a large repository. We explain Google's "trunk-based development" strategy and the support systems that structure workflow and keep Google's codebase healthy, including software for static analysis, code cleanup, and streamlined code review.
Ashish Kumar presents how Google manages to keep the source code of all its projects, over 2000, in a single code trunk containing hundreds of millions of code lines, with more than 5,000 developers accessing the same repository.
Gmail represents a dying class of products that, like Google Reader, puts control in the hands of users, not signal-harvesting algorithms.
matt-welsh.blogspot.se/2013/08/rewriting-large-production-system-in-go.html, posted 2013 by peter in development golang google toread
My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.