Show HN: Better code review for GitHub | Hacker News Reader

Show HN: Better code review for GitHub

omniref.com

110 pointstimr47 comments

"Code reviews become annotations" - cool feature, and it identifies a real problem. I don't think it solves it though.

We've learned many times that your source code and its history are the thing you care about. Spreading closely related information across different systems is dicey at best. It never seems to follow the same branching structure as the source code, and external systems come and go. Even for issue trackers, one of the most obviously useful tools we have for software development, it's not obviously a good idea to refer to issue ids from source code comments.

That is to say: if you believe that code reviews are an important part of the code, or at least sometime can be, then you should be getting that information back into the code itself. Show me a way to turn code review into a code comment from the review interface, that would be cool.

I agree with this, and recently learned about https://github.com/google/git-appraise which I believe stores the code reviews in the repo itself.

There's also integration with GitHub pull requests for that:

https://github.com/google/git-pull-request-mirror

This looks like a viable alternative to centralized solutions. I didn't even know git-notes[0] existed until I read that git appraise uses it.

[0]: https://git-scm.com/docs/git-notes

Hi there, author of Omniref here.

There's a substantial difference between what we're doing, and what git-appraise is doing. Git appraise is solving the problem of decentralized code review, but it doesn't solve the problem of making code reviews discoverable, after you've done them: having a directory full of JSON files doesn't make it easy to go from a line of code to the review that created it.

In other words: we're trying to make it possible to look at your code, and see every bit of historical information, in context, that made it as good (or bad) as it is at that moment.

That said, having the ability to export our annotations to a directory full of JSON files is high on the to-do list. You should absolutely be able to work with your own data.

This is a good point. In particular what happens if you fork a repository, do you lose the meta-data? What happens if you have a fork for coordination of a sub-team, are the pull-request annotations created on that fork also available with the main repository once it is merged in?

Good point! Right now it isn't fork-aware, but there's no reason, in principle, that the annotation data couldn't (or shouldn't) be forked with the repo. I'll file that as a to-do!

How is this different from emails or IRC conversations about the code?

This is beautiful and clearly very useful. Some thoughts:

* Business-wise, your main risk is that GitHub agrees how useful this is and builds much of the same features. In a sense, GitHub can improve in this manner, by taking the best features of external services and implementing them directly.

* The killer app here would be if you can integrate this into an IDE. In other words, the annotations are great for code-review, but not just code-review. In general they are essentially better comments. Wouldn't it be great if I saw those annotations whilst coding? I understand that it's not as if you personally could create plug-ins for all existing IDEs. But could you have an API to make that possible for third-parties to author said plug-ins?

* Integrated with code-analysis software could make for a very pleasing automated-code-review service. For example, with Python you could annotate the source with the output of pylint. Obviously, I'm not suggesting that this replaces manual code-review, just that it would be a nice addition. I mean you already have the automated annotations highlighting where a line was affected by a pull-request.

* The tour was really nice, but whenever I was asked to "go ahead and click on the annotation" this did not really work, mostly it just advanced the tour. On that note, it would be good if the tour suggested how far was to go.

in eclipse you can check show annotations which shows commit comment , not quite there but has possibility to be enhanced

Re 3): Ideally you'd run a linter before even getting to the code review step. Or via a CI that fails when the linter doesn't pass.

Hi, glad you like it!

Yes, an API is coming very soon. And hopefully soon after that, some open-source editor integrations based on that API. Do you have an editor/IDE you prefer?

Integrated code-analysis would be cool, but it gets into a messy, language specific area that I'd like to avoid for the time being (these tools can be...flaky...when run at at scale, on lots of strange repos). But I'd like to find a solution -- either, again, via API, or possibly by some sort of jenkins-like service that allows you to run any particular tool you want, and attach the output to the code as annotations. I'd like Omniref to really be a "universal reference" for your code -- not just code review comments, but any sort of information that is relevant to lines of code.

Regarding the tour bug: could you send me an email (tim@omniref.com) with a screenshot of what you saw before/after clicking the annotation button? It might be a client-specific bug.

We currently use Reviewable.io. It has a lot of features that I expect from a code review tool, but the UI is just very bad and slow on so many levels.

Will give omniref a try.

@timr, I think you should charge per user, not per repository + per user. In today's micro-service/library/containers age, there a lot of small repositories within companies. Your pricing suggests there's a 2:1 repos to users ratio. Our team, for example, easily has 10:1 repos to users ratio.

Thanks! The pricing structure is a bit of a guess right now. I'm flexible on the repo restriction, and amenable to removing it completely, if that's what people want.

If it's the only thing that keeps you from trying us, shoot me an email at tim@omniref.com, and we'll work it out. Not because I want give the hard-sell, but because I'd have to alter the code. ;-)

Hi there, Reviewable founder here. Can you elaborate on "very bad and slow" please? The UI can be polarizing but I'm always open to simplifications / alternatives. As for performance, I'm not aware of any regressions at the moment as long as you're running Chrome 49+ or Firefox 46+ on a decent machine (Safari and Edge have... issues), but again I'm happy to investigate every report.

I'd like to echo this comment. Piotr has been amazingly responsive to problems with bugs or performance issues that we have hit (the Mozilla Servo team).

Apart from the UI, Reviewable also handles many of the really ugly "they did an over-under rebase, force-pushed, did another, then flipped back" cases that come up with longer-lived PRs and manages to keep the review state reasonable better than any other tool I've seen. And we've tried quite a few of them :-)

Hey Piotr, there's not a single issue I can just point out. The whole experience feels lagish and slow. It is most likely there's so much JavaScript on the client. I even have animations disabled. For example:

* /reviews page takes around 5 seconds to load

* Sometimes the above page gives API rate limit exceptions

* The list of PRs on the above page are not wrapped in an anchor tag. I can't right click the links (to open in a new tab for example), I have to hold onto cmd and press a small icon instead

I love all the features you offer, but the UX is not very pleasant at all. We can set up a web session to show you more of my experience.

Here are two things I'd want from code reviews:

* Editor integration. Let the comments show up in Atom or whatever as inline editor annotations (assuming they're on the right HEAD).

* Inline editing while reviewing. Very often I have to comment on a bit of code with "this is how you should write it". When code reviews are just comments, I have to write that as Markdown, and I often have to copy/paste a chunk of the original code, and it's up to the reader to mentally diff what I changed. I'd rather edit the wrong code directly, and the target user should see it as a third diff pane.

Hi, author here.

Editor integration: Agreed. An API is soming soon, which will make it possible for anyone to write an editor integration. Because there are A Lot of Editors.

Inline editing: interesting. I'd have to think about how to do that one, but it's a cool idea. Thanks!

Oh. My. Word. This is awesome - both the UI and how it works/what it does. Well done!

Having this embedded inside JetBrains IDEs would be fab (no idea if possible via a plugin).

And a slightly-jealous programmer Q about step 10 of the tour ('Reviews stay “stuck” to their line!'): how did you make that work, when GitHub can't?

Thanks!

The smart annotations literally require computing a revision history for every line in the code. Essentially, a signature that uniquely identifies the line in time and location. It's a non-trivial thing to compute, and there are a lot of edge cases, so I can understand why GitHub hasn't done it. ;-)

Editor integrations are a super-common request, but because there are as many editors as programmers (it seems), we'll probably start with an API, and then move to creating open-source extensions for the most common editors. But your vote for JetBrains is recorded!

Hi everyone, Omniref author here.

Just want to let you know that our repo importing processes are currently being hugged to death. Oops. I'm spinning up more workers now, but we're about 100 repos behind at the moment.

protip: make your free option a bit of text with a link instead of highlighting it on an equal basis with your paid plan. People who want a free option will find it while people who are willing to pay you $50 wont think about the free option as much. Also those red buttons are very angry looking. Maybe make them green instead. I don't like clicking red buttons, red buttons usually do dangerous things like delete accounts and launch stuff in production. Green buttons are click magnets on the other hand.

It looks like a really nice tool though.

Good luck!

I feel like this could all be done with a polished up chrome extension. I don't see what I'd be paying $50/mo for, which is double what I pay for my company's GitHub account itself.

It's a bit non-obvious, but there are some smaller plans. You have to click the arrows on the sides of the box to see them.

I updated the page to make those arrows more visible for now. But it looks like I'll have to re-think this bit of "clever" UI.

I disagree that a Chrome extension is a good way to handle this. Where would the annotations get stored? There is enough complexity here that a dedicated service is warranted.

What happened to omniref for Ruby's source code? I can't seem to navigate to it from the main site anymore, I can only find it via Google search linking into the site.

It's still there, just on a subdomain:

https://docs.omniref.com

I'll add a link back to the homepage.

Awesome! The interface is great, I always found it the best option for looking into ruby source code. Wishing you guys success with your endeavors.

Thanks for the kind words!

This appears to hammer GitHub's API pretty aggressively. I attempted to import https://github.com/cockroachdb/cockroach and a few hours later my API limit is exceeded.

Seems bad.

It's pretty conservative with the API usage, but if you have thousands of pull requests, issues and branches, it will probably hit the limit of 5k requests an hour on first import. After initial import, API usage is very light.

You're the first person to have this problem, but I'll add some logic to throttle the request rate before we run through your allocation. The trade-off is that it will slow down import of pull requests and issues.

I would be interested in seeing some screenshots and preferably more details. Looks promising, though. Good work!

Don't know if you saw it, but there's a tour that walks you through the major features:

https://www.omniref.com/code_review/tour

Hmm. I'm on mobile right now, maybe it is hidden?

Anyway, thanks!

Oh, yeah. It's way too much UI information to work well on a mobile device. I hid it to prevent eyeball bleeding from cellphone users. You'll see it on a larger screen.

I'll have to add some screenshots, but it's just a hard thing to make obvious on a small screen. Thanks for the feedback!

You definitely need some screenshots at least on mobile. I skimmed the page and left cause I didn't see anything. Glad I read the comments to see why it was upvoted, now I at least know to check it out later on my main machine. If this weren't HN you'd have lost me though!

Yeah, I try to be aware of users browsing on phones, but I slip up sometimes, since, for obvious reasons, I mainly use Omniref on a desktop.

This was a forehead-slapper, though. :-/

Is there anyone using this already for a public project that I could take a look at?

There's a tour - https://www.omniref.com/code_review/tour

Yes, the entire Ruby language.

https://docs.omniref.com/ruby/2.2.3/

example annotation: https://docs.omniref.com/ruby/2.2.3/symbols/Class?#annotatio...

Hi, Omniref author here. Thanks for posting those links! Technically, this is an older version of the same software, but it does get the idea across.

The "new" Omniref does a lot of things correctly that the "old" Omniref wouldn't (like working with programming languages other than Ruby...heh.)

Great! We're exploring using it for the BioJulia project as a result of this HN post. Thanks for all your hard work.

Awesome. I am an ex-computational biologist, myself.

If you have any trouble just send me an email: tim@omniref.com

Oops! I keep forgetting to put examples on the homepage. Thanks!

I don't have any public examples of code review, but I've imported some popular open-source repos as examples (I don't know if I have these live-updating atm, so they might be a little behind their respective repos, but they're still good examples).

Here's the source for GitHub's libgit2 gem:

https://www.omniref.com/repositories/libgit2/rugged

And here's the source for reddit:

https://www.omniref.com/repositories/reddit/reddit

I'll work on getting some more of those on the homepage!

I can't see any reason why Null would break for a surname. You're expecting a string, not a null value. What's hat about?

Reply on news.ycombinator.com