7 ms·

Show HN: Codebrag – No More Late Friday Fixes

34 points by wozmirek 12y ago

fougerejo 12y ago
Mhh, you can use it with BitBucket code.. but BitBucket provides already a nice UI for the code reviews with Pull Requests (same with GitHub?). What's the point of using CodeBrag, only the "likes"?
- adamw1pl 12y ago
  The likes - definitely - small things can make a huge difference :). But for me, the main advantage is having a clear to-do list, so that I can see at first glance what is still waiting for me. I think CB can work very well in conjunction with BitBuck or GitHub pull requests.
timtamboy63 12y ago
A quick skim over the landing page doesn't tell me why this is better than using Github Pull Requests
- lnanek2 12y ago
  Yeah, didn't see anything to make me want to change over from Crucible either. If they are going to write a tool that's been written many times already, maybe they should make it clearer what their difference is.
- warfangle 12y ago
  I kinda see the gamification point. That's pretty ... okay, I suppose. I do like how you can 'like' a given line. Might be even better if you could like a block/set of lines/function/etc. That little heart to the left is about the only thing I see about it that sets it apart from traditional pull-request-as-code-review. Unfortunately, codebrag is single-branch only, and triggers reviews on commit. That's a little ... weird. That's how a team I was on did code reviews about seven years ago. But we were also using SVN at the time. SOP these days is issue a pull request, the PR gets reviewed and when it passes muster is merged. I don't know anyone who does per-commit code reviews. I guess you could set it up to track commits on your stable branch, and when merge commits come through from topic branches you can review then. But that seems a bit backward.
  - adamw1pl 12y ago
    Well, I, for one, am doing per-commit code reviews :) And I think it is working quite well for our team. The feedback loop is very quick. Not sure what you mean by "codebrag is single-branch", as we do support multiple branches (from 2.0, maybe you tried the previous version?). Also, SVN promoted a radically different model of working (huge commits, instead of multiple, fine-grained small commits).
    - warfangle 12y ago
      Ah, I got the info in re: single branch from the comments on this blog post: http://blog.codebrag.com/post/72667221208/implementing-code-reviews-with-codebrag-first-steps http://blog.codebrag.com/post/72667221208/implementing-code-... From the comment replies it sounded like it can only be on a single branch at a time unless you want to restart the app every time you switched branches. Does each developer run their own instance? I'd assumed all of that post and the comments were about version 2.0, considering it was linked to from the 2.0 documentation "getting started," you can understand my confusion. The FAQ only says it supports branches (not a word about multiple branches, unlike previous blog articles that took me a while to dig out) -- it makes it seem like 'sure, you can set up code reviews on a branch!' The link to the blog from the docs page points to nowhere. I just found it by going back to the beginning. I was also trying to find version deltas (e.g., what's new about version 2.0 from 1.x?), and I guess some 20 second youtube videos count but... if the code reviews are there, shouldn't there be documentation, too? I haven't used the product; it looks kind of interesting... if extraordinarily light on the details. It gives me no incentive whatsoever to try it out - the only differentiating factor it has between the github pull request review cycle is the per-commit review (I still can't quite git over this) and the ability to heart a line. If you have [wip] tags for larger e.g., refactors, how do you keep your single branch in a releasable state for production hotfixes? Does every commit kick off a regression test in jenkins? If a [wip] breaks your tests but leaves it in a releasable state, how do you know? If you did know and you needed to get a hotfix out ASAP for something else, do you revert the commit, or do you rebase to a known-stable tag? That just seems ... dangerous. It doesn't seem like the most workable flow for a continuously live project. It might work fine for products that you can release a stable version of every couple of months. "Because every commit gets reviewed" doesn't quite cut it for large codebases, even with small teams. Code reviews don't catch everything.
- adamw1pl 12y ago
  I wouldn't say these two are in opposition; while CodeBrag doesn't have support for pull request, I don't see why it shouldn't in the future. It would be perfectly valid to use CB to review commits in the branch for which the PR is done, and then come back to it once more commits (with fixes) are added. Also, using PR is only one style of work, and I don't think it's the "only right choice". Code reviews of code as it is written, that is during development of a feature, can help you to spot any problems faster. Waiting until a PR is done can result in a long feedback cycle. You can use CB to track a specific branch that either your colleague is working on, or maybe you are working together.
mattmanser 12y ago
I've always wondered, do people actually like inline diffs? I personally think they're rubbish compared to side-by-side and I've always wondered if I'm a freak as the inline seems to have become popular again with github.
- lnanek2 12y ago
  I prefer inline, but I think mature code review solutions let you pick whatever you want anyway, like Crucible.
- shortstuffsushi 12y ago
  I could go either way. I've used both where I work, and I haven't found that one works particularly better than the other. In most cases, inline is sufficient, you can get the gist of a change (especially a one line change) just looking at them inline instead of a full side by side window. In the case of a real big, messy, merge-y diff, you're gonna have a rough time with either style.
- thathonkey 12y ago
  Inline diffs are good for small changes here and there throughout a file. They are pretty worthless for large changes to a file (eg. heavy refactoring). Bitbucket (and probably Github, too?) uses inline by default on pull requests but has a button to show a side-by-side and another to see the actual file.
  - pawelwrzeszcz 12y ago
    Yeah, good point. We have got side-by-side diffs planned for future releases.
mikepurvis 12y ago
Given that you're in part competing directly with the free, built-in review tools in Github and Bitbucket, you need to specifically show what you're offering that they aren't.
- adamw1pl 12y ago
  I'd say that our two main differentiators are: * a clear "to do" list: you know at first glance if there are some commits to review, and the review process is made as simple as possible, not to get in the way of the development process * code likes - let the author know that some code is good, you like the design etc. Helps to make the reviews less negative, and in the future can be a great knowledge base!
  - un3n 12y ago
    So $25/mo per 5 users to 'like' a line of code, and the hassle of having another website or pice of software to use on top of my normal issue and source management tools. Not really worth it at all when I can just IM the dev and say 'good job, you didn't break the world haha'.
    - wozmirek 12y ago
      I would say the the biggest value of CodeBrag is that it is a well designed tool that does one thing well; such tools are usually worth their price - at least for the time they save not fighting other tools. Or writing on IM :) Besides, how often do you say to others that you liked their code? The simpler that is, the more often people will do it.
      - michaelmior 12y ago
        I've never found myself wanting a like button for code. It's a nice gimmick, but I don't see it providing enough value that would impact my decision to use a product providing it.
        12y ago
henryboldi 12y ago
I was actually expecting codebrag to be doing code review as a service. << that would be interesting
- adamw1pl 12y ago
  Sure, if people will be interested, we'll create an as-as-service version. Initially a lot of companies wanted to have a self-hosted version, though.
- pawelwrzeszcz 12y ago
  Do you mean having experts ready to review your code? There are services like that - e.g. http://www.paidcodereview.com/ http://www.paidcodereview.com/
  - alpeb 12y ago
    "As of April 2014, PaidCodeReview is no longer operational"
ToastyMallows 12y ago
Looks very very similar to Crucible by Atlassian[0], can you offer any reasons why Codebrag might be better? [0]: https://www.atlassian.com/software/crucible/overview https://www.atlassian.com/software/crucible/overview
- wozmirek 12y ago
  We have tried Crucible a couple of times, and it just didn't fit our style of work and process. Asking for a review and doing reviews in Crucible is a multi-step workflow. Also, there is no clear list of what's already reviewed and what's left for review. Overall the tool seems "heavy". I'm sure Crucible works great in some teams. CodeBrag is designed more for smaller teams, which want to have tools be as simple as possible (while maintaining functionality, of course), and like a simple, streamlined process.
- pawelwrzeszcz 12y ago
  Codebrag is a lightweight, simple to use tool, while Crucible is more feature-packed. For example in Crucible you need to create reviews (select commits and assign a developer who will review them), in Codebrag commits to review simply appear on the "To Review" list. It depends on the context which tool is more suitable for your team.
natejenkins 12y ago
No more late Friday fixes Am I alone in not liking this line? I don't see the correlation with code review. I initially thought this site was yet another "prevent drunken code commits" tool, which I'm not at all interested in, and not a code review tool, which I find quite interesting. Scrolling down the page, I came across: Codebrag is not about code reviews. Well, not only about that. It's about making your life easier by helping you write better code. And that means not staying late. And an empty office on Friday evenings. Because everything is "done done". Just kill the lights and enjoy your weekend. This is where I closed the site. I don't think about code review as a tool to relieve me of work duties on a Friday night, I view it as a tool to help my software development. To be honest, as someone who works at a small company trying to become a big company, there has never been a moment where everything is "done done". Just to clarify, I'm not dissing the site overall, it might be awesome, I just think the text on the homepage could be modified to tell potential users such as myself why I should be using Codebrag instead of Github for code review.
- teherr 12y ago
  Well, we see code review as a part of ensuring our code quality and squashing potential bugs process. This has quite strong correlation with "emergency production fixes" etc. Regarding Codebrag vs Github: not all companies are ok with sharing their code with GH, that's why Codebrag is self-hosted tool, you download it and install within your own, secure environment
  - lugg 12y ago
    Gerrit user here, how does it compare? Gerrit is terribly slow and pretty ugly even with a nice theme. What's it written in? (On mobile can't inspect right now)
    - pawelwrzeszcz 12y ago
      Codebrag is about completely different (lighweight, non-blocking review) philosophy than Gerrit. And yeah, it's nicer look :) Technologies under the hood: AngularJS+Scala(tra)+H2 database.
__xtrimsky 12y ago
I find it a bit too expensive. It's the same price as the github "bronze" organization plan. And more expensive than their Medium personal plan. I mean it does look nice, but you should probably create a cheaper plan to attract new customers. Example: 25$ 5 users, unlimited plan 5$ 2 users, 1 project plan And if possible I would even through a coupon code for 6 months on the 25$ plan.
- pawelwrzeszcz 12y ago
  Thanks for feedback! 1 project plan sounds like something to consider.
  - __xtrimsky 12y ago
    Just be careful with people abusing it. For example at my work we technically have only one project, but our project root folder is over 4Gb.
jheriko 12y ago
i can't really tell what service is being offered. or maybe i am being naive and missing the point... i guess work on the page so is clearer. imo there is a very strong sell and not enough information on the product for me to determine what it does, if i need it and esp. if its worth forking out for.
tjdetwiler 12y ago
Post-commit review It sounds like this means post-merge code review too? After getting used to a pre-merge code review tool that does hard-gating (gerrit), I have trouble with other tools.
jasonlotito 12y ago
We use Gerrit at work, and having tried numerous tools in the past, we've settled on Gerrit because it's efficient with our time and is focused on doing CRs well. Things that I enjoy: * Keyboard shortcuts. * Inline or side-by-side comparisons * Patchsets from changes * Makes it easy to check the change locally * Easy inbox/dashboard for CRs * Provides structure to passing code reviews (not everyone should be able to +2 a CR) * It actually has an interface that is useful
Ysx 12y ago
I like the look of it - unfortunately I'm not a Java developer, and gave up after 30 minutes trying to get the 1.7 JDK running on Ubuntu 12.04.

34 points by wozmirek 12y ago

Mhh, you can use it with BitBucket code.. but BitBucket provides already a nice UI for the code reviews with Pull Requests (same with GitHub?). What's the point of using CodeBrag, only the "likes"?

adamw1pl 12y ago
The likes - definitely - small things can make a huge difference :). But for me, the main advantage is having a clear to-do list, so that I can see at first glance what is still waiting for me. I think CB can work very well in conjunction with BitBuck or GitHub pull requests.

timtamboy63 12y ago

A quick skim over the landing page doesn't tell me why this is better than using Github Pull Requests

lnanek2 12y ago
Yeah, didn't see anything to make me want to change over from Crucible either. If they are going to write a tool that's been written many times already, maybe they should make it clearer what their difference is.
warfangle 12y ago
I kinda see the gamification point. That's pretty ... okay, I suppose. I do like how you can 'like' a given line. Might be even better if you could like a block/set of lines/function/etc. That little heart to the left is about the only thing I see about it that sets it apart from traditional pull-request-as-code-review. Unfortunately, codebrag is single-branch only, and triggers reviews on commit. That's a little ... weird. That's how a team I was on did code reviews about seven years ago. But we were also using SVN at the time. SOP these days is issue a pull request, the PR gets reviewed and when it passes muster is merged. I don't know anyone who does per-commit code reviews. I guess you could set it up to track commits on your stable branch, and when merge commits come through from topic branches you can review then. But that seems a bit backward.
- adamw1pl 12y ago
  Well, I, for one, am doing per-commit code reviews :) And I think it is working quite well for our team. The feedback loop is very quick. Not sure what you mean by "codebrag is single-branch", as we do support multiple branches (from 2.0, maybe you tried the previous version?). Also, SVN promoted a radically different model of working (huge commits, instead of multiple, fine-grained small commits).
  - warfangle 12y ago
    Ah, I got the info in re: single branch from the comments on this blog post: http://blog.codebrag.com/post/72667221208/implementing-code-reviews-with-codebrag-first-steps http://blog.codebrag.com/post/72667221208/implementing-code-... From the comment replies it sounded like it can only be on a single branch at a time unless you want to restart the app every time you switched branches. Does each developer run their own instance? I'd assumed all of that post and the comments were about version 2.0, considering it was linked to from the 2.0 documentation "getting started," you can understand my confusion. The FAQ only says it supports branches (not a word about multiple branches, unlike previous blog articles that took me a while to dig out) -- it makes it seem like 'sure, you can set up code reviews on a branch!' The link to the blog from the docs page points to nowhere. I just found it by going back to the beginning. I was also trying to find version deltas (e.g., what's new about version 2.0 from 1.x?), and I guess some 20 second youtube videos count but... if the code reviews are there, shouldn't there be documentation, too? I haven't used the product; it looks kind of interesting... if extraordinarily light on the details. It gives me no incentive whatsoever to try it out - the only differentiating factor it has between the github pull request review cycle is the per-commit review (I still can't quite git over this) and the ability to heart a line. If you have [wip] tags for larger e.g., refactors, how do you keep your single branch in a releasable state for production hotfixes? Does every commit kick off a regression test in jenkins? If a [wip] breaks your tests but leaves it in a releasable state, how do you know? If you did know and you needed to get a hotfix out ASAP for something else, do you revert the commit, or do you rebase to a known-stable tag? That just seems ... dangerous. It doesn't seem like the most workable flow for a continuously live project. It might work fine for products that you can release a stable version of every couple of months. "Because every commit gets reviewed" doesn't quite cut it for large codebases, even with small teams. Code reviews don't catch everything.
adamw1pl 12y ago
I wouldn't say these two are in opposition; while CodeBrag doesn't have support for pull request, I don't see why it shouldn't in the future. It would be perfectly valid to use CB to review commits in the branch for which the PR is done, and then come back to it once more commits (with fixes) are added. Also, using PR is only one style of work, and I don't think it's the "only right choice". Code reviews of code as it is written, that is during development of a feature, can help you to spot any problems faster. Waiting until a PR is done can result in a long feedback cycle. You can use CB to track a specific branch that either your colleague is working on, or maybe you are working together.

mattmanser 12y ago

I've always wondered, do people actually like inline diffs? I personally think they're rubbish compared to side-by-side and I've always wondered if I'm a freak as the inline seems to have become popular again with github.

lnanek2 12y ago
I prefer inline, but I think mature code review solutions let you pick whatever you want anyway, like Crucible.
shortstuffsushi 12y ago
I could go either way. I've used both where I work, and I haven't found that one works particularly better than the other. In most cases, inline is sufficient, you can get the gist of a change (especially a one line change) just looking at them inline instead of a full side by side window. In the case of a real big, messy, merge-y diff, you're gonna have a rough time with either style.
thathonkey 12y ago
Inline diffs are good for small changes here and there throughout a file. They are pretty worthless for large changes to a file (eg. heavy refactoring). Bitbucket (and probably Github, too?) uses inline by default on pull requests but has a button to show a side-by-side and another to see the actual file.
- pawelwrzeszcz 12y ago
  Yeah, good point. We have got side-by-side diffs planned for future releases.

mikepurvis 12y ago

Given that you're in part competing directly with the free, built-in review tools in Github and Bitbucket, you need to specifically show what you're offering that they aren't.

adamw1pl 12y ago
I'd say that our two main differentiators are: * a clear "to do" list: you know at first glance if there are some commits to review, and the review process is made as simple as possible, not to get in the way of the development process * code likes - let the author know that some code is good, you like the design etc. Helps to make the reviews less negative, and in the future can be a great knowledge base!
- un3n 12y ago
  So $25/mo per 5 users to 'like' a line of code, and the hassle of having another website or pice of software to use on top of my normal issue and source management tools. Not really worth it at all when I can just IM the dev and say 'good job, you didn't break the world haha'.
  - wozmirek 12y ago
    I would say the the biggest value of CodeBrag is that it is a well designed tool that does one thing well; such tools are usually worth their price - at least for the time they save not fighting other tools. Or writing on IM :) Besides, how often do you say to others that you liked their code? The simpler that is, the more often people will do it.
    - michaelmior 12y ago
      I've never found myself wanting a like button for code. It's a nice gimmick, but I don't see it providing enough value that would impact my decision to use a product providing it.
      - 12y ago

henryboldi 12y ago

I was actually expecting codebrag to be doing code review as a service. << that would be interesting

adamw1pl 12y ago
Sure, if people will be interested, we'll create an as-as-service version. Initially a lot of companies wanted to have a self-hosted version, though.
pawelwrzeszcz 12y ago
Do you mean having experts ready to review your code? There are services like that - e.g. http://www.paidcodereview.com/ http://www.paidcodereview.com/
- alpeb 12y ago
  "As of April 2014, PaidCodeReview is no longer operational"

ToastyMallows 12y ago

Looks very very similar to Crucible by Atlassian[0], can you offer any reasons why Codebrag might be better? [0]: https://www.atlassian.com/software/crucible/overview https://www.atlassian.com/software/crucible/overview

wozmirek 12y ago
We have tried Crucible a couple of times, and it just didn't fit our style of work and process. Asking for a review and doing reviews in Crucible is a multi-step workflow. Also, there is no clear list of what's already reviewed and what's left for review. Overall the tool seems "heavy". I'm sure Crucible works great in some teams. CodeBrag is designed more for smaller teams, which want to have tools be as simple as possible (while maintaining functionality, of course), and like a simple, streamlined process.
pawelwrzeszcz 12y ago
Codebrag is a lightweight, simple to use tool, while Crucible is more feature-packed. For example in Crucible you need to create reviews (select commits and assign a developer who will review them), in Codebrag commits to review simply appear on the "To Review" list. It depends on the context which tool is more suitable for your team.

natejenkins 12y ago

No more late Friday fixes Am I alone in not liking this line? I don't see the correlation with code review. I initially thought this site was yet another "prevent drunken code commits" tool, which I'm not at all interested in, and not a code review tool, which I find quite interesting. Scrolling down the page, I came across: Codebrag is not about code reviews. Well, not only about that. It's about making your life easier by helping you write better code. And that means not staying late. And an empty office on Friday evenings. Because everything is "done done". Just kill the lights and enjoy your weekend. This is where I closed the site. I don't think about code review as a tool to relieve me of work duties on a Friday night, I view it as a tool to help my software development. To be honest, as someone who works at a small company trying to become a big company, there has never been a moment where everything is "done done". Just to clarify, I'm not dissing the site overall, it might be awesome, I just think the text on the homepage could be modified to tell potential users such as myself why I should be using Codebrag instead of Github for code review.

teherr 12y ago
Well, we see code review as a part of ensuring our code quality and squashing potential bugs process. This has quite strong correlation with "emergency production fixes" etc. Regarding Codebrag vs Github: not all companies are ok with sharing their code with GH, that's why Codebrag is self-hosted tool, you download it and install within your own, secure environment
- lugg 12y ago
  Gerrit user here, how does it compare? Gerrit is terribly slow and pretty ugly even with a nice theme. What's it written in? (On mobile can't inspect right now)
  - pawelwrzeszcz 12y ago
    Codebrag is about completely different (lighweight, non-blocking review) philosophy than Gerrit. And yeah, it's nicer look :) Technologies under the hood: AngularJS+Scala(tra)+H2 database.

__xtrimsky 12y ago

I find it a bit too expensive. It's the same price as the github "bronze" organization plan. And more expensive than their Medium personal plan. I mean it does look nice, but you should probably create a cheaper plan to attract new customers. Example: 25$ 5 users, unlimited plan 5$ 2 users, 1 project plan And if possible I would even through a coupon code for 6 months on the 25$ plan.

pawelwrzeszcz 12y ago
Thanks for feedback! 1 project plan sounds like something to consider.
- __xtrimsky 12y ago
  Just be careful with people abusing it. For example at my work we technically have only one project, but our project root folder is over 4Gb.

jheriko 12y ago

i can't really tell what service is being offered. or maybe i am being naive and missing the point... i guess work on the page so is clearer. imo there is a very strong sell and not enough information on the product for me to determine what it does, if i need it and esp. if its worth forking out for.

tjdetwiler 12y ago

Post-commit review It sounds like this means post-merge code review too? After getting used to a pre-merge code review tool that does hard-gating (gerrit), I have trouble with other tools.

jasonlotito 12y ago

We use Gerrit at work, and having tried numerous tools in the past, we've settled on Gerrit because it's efficient with our time and is focused on doing CRs well. Things that I enjoy: * Keyboard shortcuts. * Inline or side-by-side comparisons * Patchsets from changes * Makes it easy to check the change locally * Easy inbox/dashboard for CRs * Provides structure to passing code reviews (not everyone should be able to +2 a CR) * It actually has an interface that is useful

Ysx 12y ago

I like the look of it - unfortunately I'm not a Java developer, and gave up after 30 minutes trying to get the 1.7 JDK running on Ubuntu 12.04.