Top all-time · #2579
Google Engineering Tools
Company blog · google-engtools.blogspot.comprogrammingsystems
Google Engineering Tools is the company blog at google-engtools.blogspot.com, writing about programming and systems. Since 2011, 28 different Hacker News readers have linked it 33 times, most often “Bug Prediction at Google”. The last post was in 2011, but the archive is still widely read.
Too few sampled comments (21) to say how often HN recommends it.?
Why HN links it
HN readers link this blog for Google's internal engineering tools, especially its build system (Blaze/Bazel), monorepo and source control posts, plus its bug prediction post.
Summarised by Claude from a sample of 21 HN comments that link here. Each comment is marked recommending, critical or neutral (citing without judging); how this works.
Most-linked posts?
- Bug Prediction at Google6 people · 6 mentions · first linked 2011-12-15
- Build in the Cloud: Accessing Source Code - Google Engineering Tools6 people · 6 mentions · first linked 2011-06-27
- /5 people · 5 mentions · first linked 2012-01-13
- How Google's build system works4 people · 4 mentions · first linked 2011-08-18
- Build in the Cloud: Distributing Build Steps2 people · 2 mentions · first linked 2011-09-26
- /2011/06/build-in-cloud-accessing-source-code.html?m=12 people · 2 mentions · first linked 2020-05-09
- Testing at the speed and scale of Google2 people · 2 mentions · first linked 2011-06-10
What Hacker News says?
Google already has a FUSE layer for source control: http://google-engtools.blogspot.com/2011/06/build-in-cloud-a...
Comment linking /2011/06/build-in-cloud-accessing-source-code.html
on “The largest Git repo”- nl · 2011-12-15
Submitted Bug Prediction at Google as a story · 216 points
HN discussion There's not a white paper, but there's this series of posts: http://google-engtools.blogspot.com/2011/06/build-in-cloud-a... (and an accompanying presentation)
Comment linking /2011/06/build-in-cloud-accessing-source-code.html
on “Bazel – Correct, reproducible, fast builds for everyone”Submitted How Google's build system works as a story · 113 points
HN discussionI had asked a similar question on Quora [1] few years back. Here is the summary: - Facebook: https://www.facebook.com/Engineering?sk=notes - Google: http://google-engtools.blogspot.com/ - Twitter: http://engineering.twitter.com/ - Linkedin: http://engineering.linkedin.com/blog - Dropbox: https://tech.dropbox.com/ - Instagram: http://instagram-engineering.tumblr.com/ - Netflix: http://techblog.netflix.com/ - Flickr:…
Comment linking /
on “Ask HN: Which companies have the best blogs written by their engineering team?”Submitted Bug Prediction at Google (2011) as a story · 71 points
HN discussionWith CitC meaning all the source is instantly, "locally" available and up to date, and something like bazel.io meaning you always have a reliable and fast way to rebuild something out of cached/distributed build outputs[1], you don't need to distribute a binary in the general case. Whoever needs a tool can cd to the source of the tool, build it right then and there, and run it. [1] http://google-engtools.blogspot.co…
Comment linking /2011/10/build-in-cloud-distributing-build.html
on “Why Google Stores Billions of Lines of Code in a Single Repository”Submitted Testing at the speed and scale of Google as a story · 29 points
HN discussionAn inotify daemon could help, but it's not perfect: it needs a long time to warm up in the case of a reboot or crash So does, presumably, the cache when you use lstat. (Let's scratch presumably. It does. Bonus points if you can't use Linux and use an OS that seems to chill its caches down as soon as possible. ) I hope I'm wrong, but the proper solution to this seems to be a custom file system - not only will it allo…
Comment linking /2011/06/build-in-cloud-accessing-source-code.html
on “Facebook hit git performance issue on large repository”Submitted Bug Prediction at Google (2011) as a story · 26 points
HN discussionReply to mindcrime sibling post I've seen that before myself at other companies, and it's a shame. A healthy codebase is an investment in the future - if you're not taking the time to cultivate it you're sacrificing long term usability for short term gains. The larger the codebase the more difficult the task, of course, but for us that's just an excuse to solve the next hard problem :). One more good link on the top…
Comment linking /2011/05/c-at-google-here-be-dragons.html
on “Facebook hit git performance issue on large repository”Submitted Bug Prediction at Google (2011) as a story · 3 points
HN discussionPointing at a big company and saying "they're doing it wrong" is easy enough to do, but you have to remember that every decision comes with tradeoffs. Take Google's codebase, since it's the one I know the best. A couple of the key decisions: * Single rooted tree. Separated repositories would make it harder to share code, leading to more dupication. * Build from head. We build everything from source, statically linke…
Comment linking /
on “Facebook hit git performance issue on large repository”Submitted Build in the Cloud: Accessing Source Code - Google Engineering Tools as a story · 3 points
HN discussionThat sounds like some of the posts on this blog: http://google-engtools.blogspot.com/ Also, related to source control but not Git, a few years ago Google had a tech talk about writing a Mercurial storage system on top of BigTable: http://www.google.com/events/io/2009/sessions/MercurialBigTa...
Comment linking /
on “Why is C faster than Java: git vs JGit”Submitted Build in the Cloud (2011) as a story · 1 points
HN discussionThis is similar in aspects to http://google-engtools.blogspot.com/2011/12/bug-prediction-a... , which might be a fun set of ideas to link into future iterations.
Comment linking /2011/12/bug-prediction-at-google.html
on “Evolutionary couplings between files reveal poor software design choices”Submitted Build in the Cloud: Accessing Source Code as a story · 1 points
HN discussionI program in C++ at Google. I won't make claims about "stellar". Here are a few Google-specific reasons Go hasn't replaced C++ for me: * The long C++ build times he was complaining about are mostly gone due to distributed builds. http://google-engtools.blogspot.com/2011/09/build-in-cloud-d... Throwing resources at the problem isn't ideal, but it does work. * Google has a lot of C++ library code, including client lib…
Comment linking /2011/09/build-in-cloud-distributing-build-steps.html
on “Less is exponentially more (2012)”Submitted Testing at the speed and scale of Google as a story · 1 points
HN discussionHonestly, I've heard the majority of it before, and I have never been a Google employee. I have, however, listened to some of their talks on the internal workflows and processes that they've presented and posted on youtube. I think the only things I didn't hear before were some of the specific toolnames. edit: http://google-engtools.blogspot.com/ here's their engineering tools blog. http://www.youtube.com/watch?v=2q…
Comment linking /
on “Behind enemy lines: 3 months as an iOS developer at Google”Submitted Build in the Cloud: Distributing Build Steps as a story · 1 points
HN discussionWhat you are describing is an artifact of the old Perforce which copied everything in your client to local storage. After the conversion to srcfs and piper, which was more than a decade ago, this became unnecessary. http://google-engtools.blogspot.com/2011/06/build-in-cloud-a...
Comment linking /2011/06/build-in-cloud-accessing-source-code.html?m=1
on “Advantages of Monorepos (2015)”Not sure exactly, since I haven't used any of the dozens of similar efforts. It sounds like you're a lot more familiar with the area, so here's some resources: * Bazel's FAQ: https://bazel.build/faq.html * A description on how Blaze works: https://google-engtools.blogspot.com/2011/08/build-in-cloud-... Unfortunately the design doc for Blaze is internal and AFAIK not available publicly. I imagine they took a look at…
Comment linking /2011/08/build-in-cloud-how-build-system-works.html
on “Benefits of a Monorepo”And Google has Piper and Srcfs http://google-engtools.blogspot.com/2011/06/build-in-cloud-a...
Comment linking /2011/06/build-in-cloud-accessing-source-code.html?m=1
on “EdenSCM – A cross-platform, scalable source control management system”Google has publically described their build system here http://google-engtools.blogspot.com/2011/08/build-in-cloud-h... (low fidelity) and here https://www.youtube.com/watch?v=2qv3fcXW1mg (high fidelity)
Comment linking /2011/08/build-in-cloud-how-build-system-works.html
on “Programmers’ Build Errors: A Case Study at Google [pdf]”> You get to go on another vacation while you wait for your monorepo to update. If you care, you should read about how Google makes sure this doesn't happen. > By putting our revision history in the cloud we provide engineers with complete access to all the source, and yet almost no time is spent checking out code. http://google-engtools.blogspot.com/2011/06/build-in-cloud-a... http://google-engtools.blogspot.com/20…
Comment linking /2011/08/build-in-cloud-how-build-system-works.html
on “Advantages of Monolithic Version Control”The BUILD file format looks a lot like Python code calling some functions. http://pantsbuild.github.io/first_tutorial.html#build-files . It'd be great to have something more readable. For what it's worth, Google's been using a similar format for several years, and folks seem to find their way OK: http://google-engtools.blogspot.com/2011/08/build-in-cloud-h... The word "goal" should disappear from the command line at…
Comment linking /2011/08/build-in-cloud-how-build-system-works.html
on “Pants: Build system by Twitter, Foursquare, and Square”These are some of the top sites' engineering blogs which I collected over a period of time - I removed those which have already been posted: Google: http://googledevelopers.blogspot.com/ http://google-engtools.blogspot.com/ http://googleresearch.blogspot.com/ YouTube: http://youtube-eng.blogspot.com/ Baidu: http://usa.baidu.com/category/baidutechblog/ Yahoo: http://yahooeng.tumblr.com/ http://yahoodevelopers.tumblr.…
Comment linking /
on “GitHub's Engineering Blog”The title is a direct quote from the Google Engg. Tools blog post which was on HN recently - http://google-engtools.blogspot.com/2011/12/bug-prediction-a...
Comment linking /2011/12/bug-prediction-at-google.html
on “Development at the Speed and Scale of Google”
