Codebrag blog - code review, software quality

First things first: as of today the new 2.3 release of Codebrag is free without restrictions on time or number of users, and open source under the AGPL license. You can view & fork the code at GitHub.

Why? Startups are a hard business, and you have to know when your business model simply won’t work. In case of Codebrag we got some paid users (thank you for your support!), however not in a number which would promise future self-sustainability and prospects of growth.

However, we still believe that Codebrag is a great tool for daily code reviews! We use it ourselves, and we hope that others might find it useful. That’s why we decided to open-source the application. You can now freely extend Codebrag to your liking, or integrate with other systems that you use. You can get started by cloning the repository :).

Plus, if you are interested in the technical side, it’s a great example of a cleanly separated backend/frontend applications: Scala, Scalatra, Slick and Akka on the back-end, Angular.JS on the front-end. All code-reviewed, of course!

What's new in version 2.3? Watched branches! You can now select which branches you want to review and when you'll get notifications on new commits. Just click the bell next to the branch name.

The Codebrag team

It's sometimes necessary to commit to the repository using different author's data. For example when you commit from two different workstations where you have two separate e-mail addresses configured in your git config.

This may be even required when you have multiple repositories and you commit to each of them using separate data. That's why we introduced e-mail aliases in Codebrag.

Besides your primary e-mail provided while registering, you can define additional e-mail addresses as the so-called aliases. That way Codebrag can better discover your commits (using all the e-mails for discovery) and thus prevent itself from asking you to review your own commits (which were done from another e-mail address).

by Adam Warski

Codebrag is a code review tool written by developers, for developers. Business people may tell you that technology isn’t important, but every developer knows that choosing a technology stack is the most important thing in every project ;). 

We started Codebrag basing on Bootzooka - our open-source web-project template. Since both Codebrag and Bootzooka are our projects, there’s a strong “feedback loop” between the two - improvements from the former are applied to the latter.

So what is inside Codebrag?

First of all, Codebrag consists in fact of two apps: frontend and backend. What’s important, is that these are not just layers, but applications. (You can find out more about the subject e.g. from Michał Ostruszka’s - Codebrag’s lead developer - slides from GeeCON 2014. The apps communicate through a JSON API. 

Frontend 

The frontend app is based on Angular.JS which, basing on its popularity, is almost a standard now. Of course even using Angular you have to pay attention to structure your app properly so that it’s readable and maintainable. We have clearly separated services, resources, directives, controllers and helper methods/classes (in separate files) with well defined (of course single!) responsibilities. 

As we end up with a lot of javascript files, all of this calls for unit testing and a build! And that’s what we do - we have a dedicated frontend build, based on Grunt.JS. The same approach is present in Bootzooka; you can read more about having separate (but integrated) frontend&backend builds on our blog. Our build consists of multiple steps/extensions:

karma test runner - that’s the basis

jasmine testing framework we use

stylus to keep our CSS pretty and human-readable

jshint to make sure our javascript is as good as possible

livereload for making development smooth. Whenever a file changes it gets preprocessed (if required) and browser automatically reloads Codebrag for us

html2js for converting Angular templates to JS

plus optional concatenation (on production), cache boosting (by adding unique prefixes to assets) and so on. We use grunt-usemin to handle that work for us. 

During development we make heavy use of file watchers that check for file changes and automatically trigger test execution for us. That way we get immediate feedback as soon as we save file changes. 

Backend

The backend is entirely Scala-based. We try to keep the usage of frameworks and libraries to minimum. Too much of them and you get into a bad place.

The API is exposed via Scalatra which is also the API layer in Bootzooka; Scalatra is a “micro-web-framework”, quite simple to write in and providing most of the things you need: cookie management, simple REST endpoints definitions and resource serving.

 We don’t have a DI container; but we *do* use DI - just by expressing dependencies through constructors. The object graph is created “at the end of the world” in the main class, or through mixed-in traits. Simple, type-safe and easy to understand. 

Speaking of the end of the world, when you download Codebrag you will notice that it is a single jar. That jar contains an embedded Jetty container and all the other dependencies. If you’d like to see how easy it is to create a fat-jar deployment, head over to our blog again.

Another thing you’ll notice is that you don’t need any database - well, Codebrag of course does have a database, but it’s embedded; we are using the excellent all-java SQL H2 database. To access it and actually read and write data we are using Slick - a *functional* (not object)-relational mapper from Typesafe. I really recommend Slick, it keeps you close enough to the database so that you don’t forget that you are using an SQL DB, but hides all the nasty and boring details.

Finally, a *very* important part of Codebrag is actually getting data from Git :). For that we are using JGit, which is a very nice Java interface for accessing Git repos. Feels similar to the git command line, just from Java (or Scala).

The whole build is managed by SBT- both the backend (naturally) and frontend parts. SBT makes it quite easy to call external tools like Grunt - you just need to write some Scala code. 

See for yourself!

Intrigued how two applications packaged in a single jar, with an embedded database and servlet container work? How fast does it start up? See for yourself, and take a look at Codebrag. Maybe you’ll even review a few commits? Or invite your co-workers, to let them know they did a good job?

Multiple branch support. Local & cloud repositories. Post commit review & review of features branches...

Download Codebrag 2.0 and make sure there'll be no late Friday fixes.

We'd love to hear your feedback about Codebrag 2.0 - give us a shout at uservoice, codebrag user group or tweet us @codebrag. Thanks!

The Like feature embodies our approach in Codebrag: we think that code reviews shouldn't be a chore. That's why we let you like and praise your colleagues' code!

Without further ado...

Codebrag v.2 is coming soon, so here's a sneak-peek of a micro-feature, the "review status" box:

Not only does this feature make sure that the commit gets reviewed, but also you'll see who reviewed your commit and can ask them during the coffee about their thoughts (beside their comments in Codebrag): 

by Pawel Wrzeszcz

Thanks for using Codebrag - let's get straight to business.

Thanks to you taking part in our survey, we've upgraded Codebrag to v. 1.2. This means changes:

Smoother git/svn integration (fixed bugs around commit import failing for large commits or unknown encoding)

MongoDB is no longer required (we use H2 to make the installation easier)

Codebrag automatically uses repository cloned to “repos” directory

Several other bug fixes

Check out documentation.codebrag.com - all you need to supercharge your code reviews

Plus, we're working on the branches, so stay tuned! If you've got something on your mind, just reply to this e-mail or tweet us @codebrag.

byTomek Dziurko

Dear readers,

In reply to your frequent questions, the increasing peer pressure and the growing community's concern about the avoidance of code-review, we’ve performed a short survey among programmers; the question was: “How would your work look like if you weren't doing code reviews?”.

Luckily, the results are optimistic and show that the lack of code reviews can bring many positive changes to our work. We’ve selected the three biggest advantages of not doing code reviews at work. Read on!

Unshakeable self-confidence

Nobody will tell you that you could’ve done something better. No-one will try to prove that your 200-line sorting method of the O(N4) complexity can be substituted with a ready Collections.sort().

The more years you work, the more you’re sure about your skills. And no junior developer straight out of college will try to convince you that the library they read about on that blog uses two methods to provide the functionality you’ve been working on.

During the last three months. And you’re only halfway through. Doesn't matter.

Everybody’s on holidays and you’re bored to death?

Many of your friends complain that during the holiday season it’s hard to put up with the boredom and silence at work. You don’t really get their problems - aren’t holidays the most exciting season? Be it a critical error on the production server and it’s only you to extinguish the fire in a module, whose only author is currently on a 2-week sailing trip around Cape Horn. Or you’ve got to finish a feature you’ve never heard of, because the guy who wrote it has uploaded a video of him doing a 360o snowboard trick in the Alps and has accidentally forgottten to take his company phone. All during a key moment for the firm, of course.

Bored at work? You’re in the midst of such chaos that you rarely can afford to eat something. Not to mention going to the toilet.

You spend 100% of your time on coding

Those new, hip things like pair programming or code review… they are just to distract a TRUE programmer. To prevent you from a 100% focus on stand-alone work and coding the features the client’s waiting for.

Do these code review fanatics really think that you’re going to review someone else’s code? When you’re fighting with adding a trivial thing to your friend’s module while not knowing how to connect to it or how the code works?

Give me a break.

A summary, at last

As you can clearly see, we’ve got hard proof against the code review maniacs: the rumours of “code-review-less” work are exaggerated. Working without code reviews is more effective (because you can really focus), more interesting (because there’s a lot going on) and, well, nobody will bother you with unseasoned novelties and libraries.

byPawel Wrzeszcz

Most teams at SoftwareMill do all their coding on a single git branch. No, no feature branches at all. This may sound too good to be true, but it works very well for us.

Motivation for feature branches

Don't get me wrong: feature branches have their pros. Developers don't step on each other's toes, code review before merging to master is easier (the whole feature gets reviewed at once) and comes as a natural step before calling something 'done'.

Why single branch then? Our context

Since we work in very small teams (2-4 people), managing branches would bring us more hassle than value.

Instead, our development rule is "commit (to a single branch) as often as you can" . With code being pushed and pulled all the time we don't really encounter many merge conflicts. Most of us review changes made by other members of the team 2-3 times a day. Some (addicted?) guys do it almost immediately after getting the commit notification.

That way we benefit from a short feedback loop and limiting the amount of code awaiting review. Since all of us work remotely, this is a kind of asynchronous pair programming approach.

Single branch strategy is also non-blocking (remember the difference between the optimistic and pessimistic locking?). It requires, though, a discipline to regularly review other's code and track the issues spotted during review.

What if my tasks are bigger?

Sometimes, when there is a larger task or refactoring to do, it's hard to apply our "commit often" rule with the finished chunks. In such cases we try to commit frequently anyway and include a "[wip]" tag in the commit message, e.g.:

[wip] Introducing FooBar feature

What's beautiful about this is that as soon someone starts doing even a HUGE thing, they may get an advice from other team members whether it's a good approach or not.

Of course, such "wip" changes may lead to build failures, so some attention to keep the build green is necessary.

Other commit message tags we use include: - [minor] - might be a typo or something like that, not necesary requiring a thorough review, - [review] - fix/improvement for something spotted during the code review.

As mentioned earlier, following this workflow requires developing the habit of frequent reviews. To make this happen most of us sit down to review as a first thing in the morning and later on treat it like a break in coding (visiting Codebrag instead of Facebook ;)).

We've already  worked this way for over 3 years and we're happy with the simplicity of this approach. What is your workflow? Do you go by the book and use branches? Or are you a rebel like us? Share your flow!

byPawel Wrzeszcz

How many bugs have you and your team fixed recently? A couple, a group or maybe even a horde? Well, stop then. Really. At least for a while. Just start preventing the bugs with code review instead.

This blog post will show you how to implement a very simple code review process in your team. Codebrag does that and nothing more, so don’t worry about bogging down your workflow.

1. Setup

First things first. Grab a copy of Codebrag and install it on your server.

Should you need any help with the setup, do ping us at [email protected].

2. Review

After creating an account and logging in you are immediately ready to review your colleagues recent commits:

Codebrag auto-imports the last 10 commits and puts any new ones on the ‘TO REVIEW’ list.

Now it’s your turn. Share your passion for beautiful, bug-free code. Go and comment:

and recognize good practices with in-line ‘likes’:

Once you're done with the commit, mark it as reviewed:

The commit will disappear from your 'TO REVIEW' list. You can always access it from the 'ALL' view.

We've got a small surprise for you after you clear the list:

3. Invite

But hey... code review isn't something to be done alone. Invite your team members to get reviews and less bugs in the future:

That’s it! You and your team now have a simple, yet effective process for preventing bugs and sharing knowledge through code reviews.

We'd love to hear how this works out for you. Let us know at [email protected] or @codebrag to share your feedback or ask questions.

We are excited to release the first public version of Codebrag!

v1.0 features:

dead-simple code review workflow

inline comments and 'likes'

all discussions on code and changes in one place (follow-ups)

smart email notifications

git and svn support (single branch at the moment :))

All this to make code reviews simple, fun and functional.

You can try Codebrag here:

We support both local repositories and those hosted in the cloud.

Obviously, we love Codebrag. But that doesn't mean it's perfect. Praise us, criticise us, say hello - we'd love to hear from you! You can drop us a line at [email protected].

Thanks!

- The Codebrag team

byPawel Wrzeszcz

Hello,

I have prepared a short introduction explaining how code review flow looks like in Codebrag.

Enjoy!

by Łukasz Żuchowski

In SML we do code reviews. We do them on daily basis. Actually the point that we are now is a result of long journey that we made. We try different strategies and tools until we went to the place that we are now (but it doesn't mean that we are going to end up here).

During this journey we found may risks and traps that are waiting for a newcomer. That's what this post is all about, traps & misconceptions on code review.

Code control: many organizations uses CR for controlling codebase. Most of them are using pre-commit strategy. In many cases its because those projects are open-source with hundred of commiters. In real life this is quite rare scenario, so if you hired someone it means that you trust him enough to let him commit code to repository. I know that in some organizations there will be temptation to make procedure that will force developers to "review" and "approve" every commit, but it will not guarantee the quality. Moreover people will soon treat code review as "stupid" corporate procedure and will try to hack-it (such changing password every month e.g. people are using passwords like: mypass1, mypass2 etc.).

Hall of blame: Don't user CR for finding scape goats or guilty ones. Let's assume that there was a failure and you found a person who "reviewed" the "bad code" and blame him for not pointing it out. I will cause that development in your company will drastically slow down. People will be pointing out every semicolon not at the right place, because they will be afraid of being scape goat. Your team members will start feeling unconfident and the lack of trust.

"Code" of duty: Don't push on your developers to much. If you force them to make review every day for an hour, soon they will hate it and treat as unfunny duty. Code review is about learning, praising others and giving feedback so it's very social activity. CR could be fun, don't spoil it.

I'm not my code: If your code was reviewed by someone and he left some comment (sometimes even not too nice), don't get angry. He isn't saying that you are a poor developer. That wasn't his intention nor code review is about that. All he did, was criticizing some piece of code (not the author). Code review is all about code, not about you. Don't treat code review tool as forum with "trolls" and people fighting each other. When you will be writing comments try not to be rude or too strict. Try to imagine that your are on the other side reading it.

To sum it up, there is plenty of ways to make code review wrong. Those 4 are the one that I experienced or anticipated, so beware. I promise to write post about "what code review is about". If you wan't to try out code review tool (fruit of our experience & practices) visit codebrag.com

Post was originally published at http://blog.zuchos.com/

    Used photos:

 "The Puppet Master" by Henk

"ready for duty" by Leonard John Matthews

byAleksandra Puchta

Yes, it’s today and it’s time to celebrate

We wish you lots of beautiful code every day that brings you joy and satisfaction from what you do!

About the day For those, who are not familiar with, Programmers’ Day is celebrated on the 256th day of each year.

#ProudOfMyCode We think it’s also a great occasion to mention #ProudOfMyCode philosophy, which is the idea of delivering great code, and being proud of it. Thank you all for being great programmers and special thanks to those, who help others in this matter. Let’s celebrate!

byMichał Ostruszka

Let’s stay close to HTTP request/response cycle in AngularJS for a while. In my previous post I showed how we use config object populated with custom properties to control which HTTP requests are invoked and which are not. This time I’ll show you how to use the same config object but for playing with HTTP response.

Sometimes you may want for example to process different responses in different ways. Let’s take HTTP errors for example. When you receive response with HTTP code different that 2xx in most applications you probably want to let user know that something wrong happened, so you may decide to display some popup with error message. This can be easily achieved with response interceptors in AngularJS. Simply write and enable interceptor that handles all failed responses and does something (e.g. broadcasts an event with error details which is then handled by specialized directive that displays message to user). In the simplest form such interceptor may look as follows:

angular.module('app').factory('httpErrorsInterceptor', function ($q, $rootScope, EventsDict) { function successHandler(response) { return response; } function errorHandler(response) { $rootScope.$broadcast(EventsDict.httpError, response.data.cause); return $q.reject(response); } return function(httpPromise) { return httpPromise.then(success, error); }; });

It simply passes successful responses through and for error responses it broadcasts custom event (EventsDict.httpError) and then rejects it as it would be done normally. That’s cool, but suppose you have a feature in your application that has its own way of handling errors? In Codebrag we have “Invite others” form that after sending should display to user whether his invitation was sent or whether there was something wrong with it on the server side. Besides that we have general “error bubble” that is displayed when any error (including HTTP ones) occurs. As long as our “Invite others” form handles this case on its own we don’t need to display this standard bubble anymore for those requests.

Ideally we’d like to have a way to tell which requests should be even considered by our interceptor when processing response and which should be left alone and just passed through. So here is what we did. In Angular every HTTP response has configobject attached to it and this is exactly the same config object as the one from corresponding request. Let’s make use of it again. When sending HTTP request let’s define custom property in its config object:

var data = { invitationMsg: 'Hey! Come and join Codebrag', newUserEmail: '[email protected]' }; $http.post('/invitation', data, {bypassErrorsInterceptor: true});

And here it is. Custom bypassErrorsInterceptor property will be set for each requests of this type. Now the core stuff - let’s modify our simple interceptor to leave responses for those requests alone. Just let them be rejected without any other work, but keep watching and reacting on any other requests that don’t have this property set.

angular.module('app').factory('httpErrorsInterceptor', function ($q, $rootScope, EventsDict) { function successHandler(response) { return response; } function errorHandler(response) { var config = response.config; if(config.bypassErrorInterceptor) { return $q.reject(response); } $rootScope.$broadcast(EventsDict.httpError, response.data.cause); return $q.reject(response); } return function (promise) { return promise.then(success, error); }; });

Done. Now every HTTP request with bypassErrorsInterceptor property set will be passed through and the rest will result with event broadcasting.

byAleksandra Puchta

At Codebrag we are deeply devoted to the idea of delivering great code, and being proud of it.

This, ultimately, is the goal of our lives as developers, as great code means self-development and most importantly – satisfaction from what you’re doing.

We know it’s demanding and not that easy.

  That’s why we came up with this approach:

Reach out to others

Ask people to do a code review for you – colleagues, teachers and even gurus. Ask them for help. Their knowledge is immense and by having them go over your code you will enormously accelerate your learning.

Read other people’s code

Look for the best practices and most elegant solutions. This is how you build up your super-duper developer’s skill set.  

Praise awesome code

Don’t be aloof. When you see a nice part of code – just say or write so! People love getting praise and there is nothing wrong with appreciating their skills.

  It’s a really simple approach that works perfectly for us.

As we want more and more people to be proud of their code, we’ve prepared something special for you.

Here are banners that you could use on your blog or website. They explicitly say that the owner is proud of their code.

Linking to this post would make it clear to others what exactly that means, plus Codebrag would be sooooo happy to have new visitors ;)  The decision is yours.