8 ms·
> Many years ago, I did a brief stint at Google. A lot has changed since then, but even that brief exposure to Google's internal developer tools left a lasting
by tdeck 6y ago
> Many years ago, I did a brief stint at Google. A lot has changed since then, but even that brief exposure to Google's internal developer tools left a lasting impression on me.
Perhaps the operative phrase being "Many years ago". I currently work at Google, previously I worked at Square. Of the two, I generally prefer the OSS and off-the-shelf tooling at Square. Some things really are better at Google (code search and Blaze are definitely a big improvement over what we had), but many of our monitoring and CI tools feel antiquated and cluttered with inscrutable debris. Or take Gerrit, where each change has 3 different IDs and the developers decided that every workflow status should be expressed as an integer in the range [-2, 2] for some reason [1].
They were probably amazing (and much simpler) tools back in the day, but the world has moved and we're somewhat constrained by what's familiar.
[1]: https://gerrit-review.googlesource.com/Documentation/images/user-review-ui-change-complex-reply-dialogue.png https://gerrit-review.googlesource.com/Documentation/images/...
- ma2rten 6y agoNote that Critique (Google's main code review UI) doesn't have the same issues that Gerrit apparently has.
- corentin88 6y agoCritique seems a well-guarded secret inside Google. Can't find more information on it. No images. Interesting
- Sesse__ 6y agoIt's a reimplementation of an earlier system called Mondrian, which you can find some information on.
- cmrdporcupine 6y agoI used Mondrian for the last couple months it existed, and I recall critique being fairly different. I think they kept the same keystrokes, though. That is one nice thing about Critique is although it's a webapp you can drive it pretty much entirely by keyboard. It has the feel of an old usenet newsreader like nn, in a way.
- ikiris 6y agoHere I'm sitting here thinking could I draw it from memory?
- antoinealb 6y agoIt went through a re-design recently. I don't think I would call it a well-guarded secret though, if you look at Phabricator's Differential, it is very similar [0]. [0] https://www.phacility.com/phabricator/differential/ https://www.phacility.com/phabricator/differential/
- jonhohle 6y agoReading through that page it seems like every single component is an unrelated, seemingly random, “cute” name. Are cli, triggers/actions, and rules too generic? Out of context, what meaning do Arcanist, Maniphest, or Herald have?
- chrizel 6y agoRelated answer from one of the developers: https://www.quora.com/Phabricator/Phabricator-Why-is-the-Browse-feature-called-Diffusion-and-not-just-Browse https://www.quora.com/Phabricator/Phabricator-Why-is-the-Bro... But yeah... even I find the names difficult to handle and remember, even after using Phabricator for more than 4 years now. Nevertheless, it is a great piece of software, especially the code review process is top-notch.
- lima 6y agoNot really. The "Software Engineering at Google" book[1] has a whole chapter on it with screenshots. Gerrit, Reviewable and Phabricator are very similar, except that Critique is much more polished. Having used all three, Gerrit works best and the new UI is starting to look pretty good. Reviewable has great UX, but inherits some of the disadvantages of GitHub PRs. [1]: https://books.google.de/books/about/Software_Engineering_at_Google.html https://books.google.de/books/about/Software_Engineering_at_...
- cmrdporcupine 6y agoI work at Google and mainly use Gerrit because of the products I work on and yes, Critique is miles better.
- lima 6y agoGerrit is configurable and it is common to use it like Critique with blocking comments and LGTMs. It's still a big step up from, say, GitHub PRs, and the UX has improved significantly.
- herodoturtle 6y agoI read a beautiful comment like this, and I think to myself, a) Am I just old? I have no idea what's cool these days. b) #Wow that sounds #epic! I best get #hodling. c) The GitHub PRs team were a nice bunch. I wonder what they're doing now? d) > Gerrit is configurable\n> with blocking comments and LGTMs\n\nShow us an example please? - herodoturtle #486dx2 #zerocool #gorilla.bas #mode13h #nehe #0x5f3759df #lamp #vi
- raverbashing 6y agoYes please, Github PRs are much, much better than Gerrit or Ritveld (urgh), and the +1/+2 quirks of it No, I'll take Github PRs any day. They could be better, of course.
- u801e 6y agoGithub PRs (at least on the enterprise version) still have the problem of collapsing comments where the associated line of code changed in some way that had nothing to do with the comment. They also require a lot of scrolling if the overall diff is rather long. And, they still don't provide a way to comment on commit messages themselves.
- raverbashing 6y agoAgreed on the comment collapse, about comment on the commit message I'd say it's a commit on the main PR (since by the time the PR is done the commit msgs are pretty much not changeable, except for the last one)
- u801e 6y ago> about comment on the commit message I'd say it's a commit on the main PR Except that if the overall diff line I choose to comment on about the commit message changes in some way, then the comment is collapsed, which makes it difficult to keep track of what needs to change. > since by the time the PR is done the commit msgs are pretty much not changeable, except for the last one They can be changed via a git rebase.
- plorkyeran 6y agoCollapsing comments when the code changes is the correct thing to do 90% of the time in my experience, and for that other 10% you can manually mark is as unresolved. It's the correct default IMO.
- u801e 6y ago> Collapsing comments when the code changes is the correct thing to do 90% of the time in my experience Why not just leave them uncollapsed and allow one to mark them as resolved when the change is actually resolved. The other problem is that it's difficult to see what actually changed when a line is marked out of date without having to scan through the entire updated diff and then jump back and forth between the diff and conversation view. Collapsing them by default makes it difficult to find the comment by scanning. If they were uncollapsed until I marked them as resolved, then I could at least use the find feature in the browser and search for my username to find my comments.
- rockwotj 6y agoI agree - grafana is wayyy better than viceroy and the other monitoring dashboards that were available when I worked at Google.
- jeffbee 6y agoInteresting. Viceroy can put way more pixels on the screen than grafana with the same cpu and memory usage, and panopticon is specifically written to send little traffic over the wire, so it’s useful to an oncall engineer over a poor mobile backhaul like GPRS. Grafana is a massive resource hog in all dimensions.
- rockwotj 6y agoHasn't pcon been deprecated for a year and a half now? :P More pixels != to more information. The visuals and varieties in ways to present data in grafana always seemed more intuitive for me, being able to lay stuff out in different ways was great. I worked on a G-on-G project at Google and used both grafana and viceroy. I never had an issue with grafana on mobile, but I was never was able to see viceroy on a mobile browser because of the Corp network.
- jeffbee 6y agoOn viceroy if you unintentionally put 2000 lines on a graph, you get a visual mess. If you do that on grafana your tab will hang for ten minutes. Big difference.
- rockwotj 6y agoTrue, but that only happens when setting up graphs. Graphs are not changed as often as they are viewed. I'm sure viceroy is more performant, and I'm not denying that, I may also be scarred a bit because I found writing mash queries an arcane nightmare, and those are related to viceroy. The default (rpc latencies and etc) views and metrics you get are amazing however.
- 6y ago
- daralthus 6y ago> They were probably amazing (and much simpler) tools back in the day, but the world has moved and we're somewhat constrained by what's familiar. Exactly my feelings about Phabricator. GitLab simply runs circles around it if you consider the issue tracking, CI etc. as part of the problem.
- Cthulhu_ 6y agoI would've loved to have Gitlab at our company, but unfortunately we're on a tight budget so they didn't want to go for anything paid.
- JeremyNT 6y agoGitlab CE would be perfect, then, since it's free. If you're on a tight budget it actually seems like one of the best options available.
- paulryanrogers 6y agoTried self hosting once and it was challenging just to get setup. That said their free hosted solution is feature such enough for most of my projects.
- djeiasbsbo 6y agoI self host it at home. Haven't had problems but probably only because of how small my instance is (10 people). The omnibus installer makes it relatively simple to maintain!
- wheaties 6y agoWe moved from Phabricator to JIRA, Github and CircleCI. We couldn't be happier. It's one thing to have a single tool with 70% of the functionality you need, it's another to have 90%+. That 20% makes such a huge gulf it's not even funny. We were able to ditch several thousands of lines of cobbled together glue that moved us 10% forward but added overhead for any new project which set us back a week or more.
- dboreham 6y ago> integer in the range [-2, 2] for some reason This sounded awesome to me (imagining some Fortran code behind it), but disappointingly the cited screen shot only has the range [-1,0,1] which is hardly the same.
- broeng 6y ago-2 and 2 can be disabled, which I guess is the case on the screenshot you saw.
- sershe 6y agoI think this might come from a typical feedback on patches in Apache (or all of OSS) - -1 rejected as is, +1 approved. I've also seen -0 (don't approve but won't block/reject) and +0 (ok with it but didn't review/won't approve)
- kortilla 6y ago> in the range [-2, 2] for some reason [1]. This was actually pretty useful in OpenStack back in the day. The reviewers who couldn’t yet approve code could only put +1s on there (and there were a lot of low quality reviewers who slapped these everywhere) so it was very obvious when a patch still needed attention from a commit-privileged dev. Then -1 was standard review feedback of stuff that needed improving and -2 would come from commit-privileged devs when the patch fundamentally didn’t fit with the project direction.
- jdbernard 6y agoThe system makes sense but it feels like there is probably a more intuitive easy to express those than with numbers. Naming is hard, of course, but off the top of my head maybe something like -1: Changes Requested -2: Declined 1: Approved 2: Accepted
- antonvs 6y agoWhy would that matter? This is for developers, not English majors.
- jdbernard 6y agoI didn't down vote you, and your question deserves a serious reply because the same principle is broadly useful. Communication is hard. People actively in the team probably have the context to understand the differences, but that implied context is what tribal knowledge is made of. OP indicated that there were non-trivial "non-linear" differences going from 1 to 2 and -1 to -2. The use of numbers implies a relationship that doesn't really exist. The use of accurate language makes the actual meaning immediately obvious without the need for implied context. For example, I had no idea that only privileged devs could give 2s. "Accepted" and "Declined" do imply a finality that more accurately mirrors the intended usage. This may seem overly analytical for something that is easy to just explain, but this kind of thing build up in layers.
- tdeck 6y ago
- matt_o 6y ago> I currently work at Google, previously I worked at Square. Of the two, I generally prefer the OSS and off-the-shelf tooling at Square. I wrapped a 2-year stint at Facebook recently and my experience was similar to yours. Some tools were amazing and cool and I really appreciated how they evolved over time to manage huge amounts of resources. But most were subpar when compared to OSS tooling - outdated, deprecated functionality, very little documentation, very few people working on them. The common approach was to learn about "the duct tape" way to make something work, then pass it on to new engineers. An example would be tool X for working with diffs (PRs). It's the latest and greatest, except that it only covers 75% of its predecessor's, tool Y's, functionality, so you end up learning both. Tool Y has been "deprecated" for the past 3-4 years. Some of its features don't work, but you'll only know when you try and execute them.
- hinkley 6y agoYou have to make some allowances for first movers. The designs of new tools are often ill conceived because they have no templates to steal ideas from. But the emotional investment often keeps them from switching to better tools because We’ve Always Done Things This Way. The thing that bugs me most about my company’s tools are the ones that are enough younger than OSS solutions that someone either didn’t look very hard, or didn’t want to find anything (so they could write their own). Other priorities come along and those tools eventually can’t keep up with OSS alternatives, but the apologists take over. You will not continue to get accolades for tools you wrote three years ago. The only “value” you derive is the time and effort it saves, offset my the effort expended. The time and effort expense of external tools are often lower. And, when the tools are annoying, you can commiserate with your coworkers instead of being the target of their criticisms. Which is often under-appreciated.