I have wrote previously how github is missing a very important feature - code review. This led me to a decision to use gerrit in our development team. I am very intrigued by the fact that it has a Java based version of Git (JGit) integrated in it. So, basically, when you want to submit a code for review, you just push it to gerrit, like to any other git repository. Then reviewer pulls changes reviews them and inserts her comments through gerrit web ui. If review is positive, the you merge your changes into origin/upstream repository. All this seems exactly what we need, so I decided to give it a shot.
The latest stable version available at the moment is 2.4. You can grab it here.
Official documentation is quite ok for an open source tool - that means that you will have to bend your brains a little bit. Here is a couple of more links about using and installing gerrit: awesome guide by unethicalblogger and installation guide by Greg Meiste.
I started my installation with a desire to run gerrit from a JEE container, as we already have an Apache Tomcat running on our server and embedded H2 database. But had no luck - during deployment gerrit crashed with an exception that I couldn’t even see. Official documentation says nothing about configuring logging and surfing through source code didn’t help me much. So, I had to go with a standalone installation.
I am not good at configuring httpd - configuring access to gerrit through reverse proxy together with ssl and authentication was a bit tricky, since I didn’t want to break access to other apps working through mod_jk. In the end simple copy paste from the guide and correct ordering of various parts in site configration did the job.
The next step was to configure gerrit itself: projects, permissions, public keys and ssh access to the gerrit shell. Configuring public key is very simple and other steps are described by unethicalblogger very well. Though, I must say, that ended up with a little different set of permissions than unethicalblogger:
I had to add “Forge Identity” permission on the range +2 since emails that we use to loggin to gerrit do not 100% coincide with emails/names that we have in our public/private keys. Also I have forbidden access to both anonymous and registered users - only developers (the group I have created myself) and administrators can use gerrit.
I haven’t yet tried using gerrit in our projects, but now I am ready to do that :)
If you are going to use gerrit and you are having troubles with installation - ping me as I may have some ready solutions for you! :)
Skype is a best tool out there for having team-wide conversations voice, video and text. But, it has some deficiencies that make it almost unusable for developers throughout the day. Let me elaborate on that.
While I am writing software I usually don’t like to be disturbed - it is not easy for me get into the flow and loosing it doesn’t make me feel better. For each part of the day I’d love to have at least couple of hours of uninterrupted work - I want to be able to manage my level of focus and time by myself.
Now, that’s a lot to wish for :). I am responsible for architecture and design of our products, so, it is natural that my teammates want to discuss or consult with me about their solutions. And I am ok with that - that’s a huge inefficiency if a colleague is not able to move on with her task and is waiting for me. But, on the other hand there are people whose messages I’d like to postpone until I am having a pause.
So, how Skype can be better for developers? It is simply, I need to able to configure statuses by myself. In other words, I need to have a status somewhere in between of “do not disturb” and “online”. A status where I can tell “do not disturb” for 98% of my contact list and have all the messages delivered for remaining 2%.
Do you have similar experience with Skype? Or maybe you know some tips, how can I configure it to be less intrusive?
P.S. I can’t understand developers who have all sorts of Twitter, Skype, email and other notifications popping out all the time. I think such notifications should be kept to a reasonable minimum - I agree that there is information that needs to be delivered right away, but definitely notifications about somebody coming online or going offline are not part of that :)
Every developer loves to start a new project. (Sometimes) You can choose all the latest exciting technologies; usually there is no legacy code involved, so everything is clean, elegant and neat - is there anything more elegant and neater than a empty sheet of paper? ;) I doubt it! Start of the project is the time when everybody is super excited, there are no deadlines yet, everybody is pumped with enthusiasm! But as the time goes on people feel less and less attracted to project - vows are forgotten (“we will have 90% coverage by unit tests”, “no copy-pasting”, “no hacks”), stupid requirements get into the way, project manager is pushing deadlines… and all the love has gone…
But this period of enthusiasm doesn’t happen for nothing - it actually plays very important role in the project! First of all, this is the time during which developers are the most productive and enthusiastic, so good manager knows, that this is the time for most complex and risky requirements.
Secondly, experienced developers recognize that exactly at this time they create the basis for the whole project. It is like a DNA of the person - all goods and bads will be copied all over the code based, either directly (copy-paste) or indirectly - show a bad example for a junior developer and you can be sure, that she will do exactly the same somewhere else. Tell me how many times have you settled for a ‘not so good’ solution only because you have seen ‘not so good’ pieces of code already there in the project? And how many times have you checked in such solution, when the code otherwise was clean and neat? I think to my self that the moment you lower the bar to anything other than excellent, you open the gate to the enemy :) It is just a matter of time when he gets in!
So, next time you start something from a clean sheet - remember about DNA and don’t rush too much - try to start with good and elegant examples for your teammates and they will be ashamed to contribute anything worse. This is how you set up the culture in your team! This is how you choose the route to great products loved by your customers!
I need to setup code review procedures for products that we develop. We tried Review Board while we were using SVN. Although it is a nice tool, the fact that your code remains unversioned for the whole procedure seems kind of a strange to me. So, I hoped that distributed revision control system would suit best for this.
First I saw Kiln and in my opinion it sets up standards in modern code review processes: you can accept and decline changes + assign code reviews to teammates. One thing is very appealing to me: you create a blessed repository and then fork it for integration purposes. Developers commit code to integration fork, then code review takes place and if everything is cool - code is pushed into the blessed repository. During all this process code stays under version control - very neat. But I don’t like 2 things about Kiln: a) 25$ per user per month seems too expensive for “on demand” version b) and if you decide to host it yourself the it requires a Windows server.
Since Kiln is too expensive for us and github is sort of a de-facto standard for git hosting, we decided to go with it. Thanks to git itself and awesome documentation on github, using it as a revision control system is a breeze! Unfortunately, code review workflow supported by github is not that cool - it stands nowhere near to what Kiln offers. And that’s very sad.
First of all, everybody has to have a fork of the blessed repository. This sounds like a lot of routine overhead: to push something one needs to push it to her fork and then request pull from the fork. So, whenever my teammate needs to push something quick required for all of us to sprint on - it takes too much effort. I thought to overcome this by creating a blessed repo and then forking it inside the same account to create an integration repo. But github doesn’t support this - one can fork only into her own account (i.e. I cannot fork devpulse/devpulse-blessed into devpulse/devpulse-integration).
Secondly, there is no central place to handle pull request - I would like to be able to establish process where everybody is reviewing everybody’s code and I cannot create and assign code review tasks within github.
Now, to be honest, there are some feature that support reviewing code in github: you can see diff of the commit and add comments to it, but I cannot figure out how to use those without to much routine. So, at the moment, seems like github works quite well for open source projects with a “gatekeeper” organizational pattern (i.e. one particular person is responsible for letting code in or not and everybody send her pull requests). But, it doesn’t support setting up code review for privater repositories where peer review is required.
My next option is to setup gerrit somewhere on our servers or go back to using Review Board again, which doesn’t make me happy at all…
How have you established code review process? Can it be used on github?
Nowadays not only people talk to each other - having an application that is not able to communicate with other applications grew out to be a huge “minus” during last couple of years.
Even though many applications are developed for certain niche - either based on customer requirements (e.g. Atlassian toolkit vs IBM’s) or target applicability (bug trackers vs time management vs code management), they still are generalizations. This means that customers either bend their processes to suit the tool or move on to use another ones. So, from the customer’s perspective good API is a possibility to fine tune the application to fit her requirements.
Another way of using API is pulling the data out of the tool and feeding it into another one to perform data mining tasks on it. For instance, Jira is an awesome tool for tracking defects, tasks and planning iterations, but it is not the best tool analyze trends and metrics, that could be derived from tracking data. Or consider devPulse which puts streams of events from different data sources into one single feed - even if each specific tool that you use has such a feed, aggregating them all together without API-s is very difficult.
If we look at this topic from the software vendor’s point of view, then enabling customer to extend functionality of the tool is a way to ensure that customer would continue to be happy with it even if her requirements or position in the niche changes. Also having an API makes you more open and trustworthy. This may sound stupid at first: you give your customer a possibility to switch to your competitor and take all the data with her, but it actually works vice versa - the openness wins you whists in eyes of your customer. E.g. my thoughts usually go along lines: “why not to try this tool - if I don’t like it I just move to another without loosing my data”. It sort of a lowers entrance barrier for you.
What are your thoughts on this topic? What mechanisms you use to let your customers extend your apps?
What are usual places that you (as a developer) search for solution to a problem or task with a particular technology or library?
I remember, that when I started to develop software, my first to sources of solutions were manuals/guides and google :). Guides were “no brainer” right from the beginning and google became very obvious with popularity of blogs - chances are that some other developer has faced the same problem and posted solution on her blog or somewhere in a public wiki.
Later, I found out that, it is even more rewarding to search through mailing lists of framework/library users, as these lists are devoted exactly for the purpose of asking and sharing solutions to problems. And some of them are not even posted anywhere else besides the user list. My favorite tool for digging in mailing lists is nabble.com - sometimes it is slow, but other than that it is an awesome tool (at least for lists of open source libraries).
Finally, I think that every developer should have source codes of all libraries/frameworks that she uses attached to a project in IDE. Source code is a fantastic source of all kind of knowledge about framework - you can always put a break point and check out for yourself how the particular functionality works. Also seeing a source code helps me to decide if particular library is really worth using - it is quite easy to see if code is too rigid or is not clean. Having such opportunity is a huge advantage of open source! I remember times, when I had to decompile JDBC drivers of a famous DBMS vendor in order to understand why my application didn’t work with particular configuration and even taking into account that the code was decompiled, one could easily see that source code is a mess.
Probably, for all more or less experienced developers all this is no secret, but I hope that at least for some of you this could be a good reminder, so you would try one place more before breaking the flow of your colleague ;).
While making move from privately hosted svn to github, I also had to import existing code base. Firstly, it seemed like a difficult operation - a lot of resources focus on using svn and git simultaneously and very few talk about actually migrating from one to another. Fortunately, I found couple of guides on github and it went like a charm. Here I’d like to share steps I’ve performed.
I started with installing a svn2git tool:
sudo gem install svn2git —source http://gemcutter.org
Then I created an empty directory, navigated to it and initialized an empty git repository:
mkdir devpulse
cd devpulse
git init
After that I executed the svn2git giving it path of our svn repository as argument.
svn2git https://url.to.our.server/devpulse —trunk trunk —tags tags —nobranches
Our svn repository almost follows the convention - somehow we ended up having an extra directory in the root (besides trunk and tags). I was affraid that this directory could get into the way, but that didn’t happen :). Devpulse is quite young, so there weren’t any branches - probably that made importing very easy for the svn2git.
Next step - I checked the status, added remote git repository to the list of remotely tracked repositories and pushed contents of my new local git repository to it:
ls -la
git status
git remote add origin git@github.com:xxx/xxx.git
git push origin master
At the moment everything seems to be working. The single trouble I had so far is that I decided to put my keys not into the .ssh directory and when I executed “ssh-add ~/Keys/my.key” mac osx didn’t add the identity to keyring. So, I had to execute that command everytime I re-started the mac. Luckily, after some googling, I’ve found that I can add my identity manually to the keyring using “ssh-add -K ~/Keys/my.key” command and everything works like a charm :).
Many thanks to guys who created svn2git!
Edit: Thanks to Martin Villig, I fixed names of two startups and added the one that I’ve previously forgotten - Living Canvas.
Yesterday I made a 3 min pitch of devPulse at summer of startups pitching contest. The event itself was little bit too much ‘low profile’ - almost felt that it happened ad-hoc :). Nevertheless it was a good time for us to revise our devPulse materials and test our message on people who havent heard of us before.
My pitch was last and I’d say that overall I did ‘ok’ (neither ‘good’ nor ‘great’) and there are at least couple of things I need to improve. First of all, I only managed to present only 66% of the pitch - I clearly lacked practicing with a clock. Secondly, I had one idea how to demonstrate a particular devPulse feature, but while I was pitching I missed the correct moment to do that and then I didn’t have time anymore to go back to it. And most of all I understood that our message is not clear enough, at least for business people - we need to work hard on that too.
Overall, there were 11 pitches. Out of those I’d say about 4 were in the niche of enterprise/organisation/team stream/feed/chat: devPulse - aggregated stream for software developers, flowdock - online team chat, dealmachine - feed for sales teams, incspark - friendfeed for enterprises. Each tool with its own ‘kick’, but all of those about a stream of events/messages.
One more observation - 2 startups (Pamoja and SMS IT) targeted African markets. I am not sure yet if it’s cool or not, but definitely sounds as an interesting way to stand out :)
Also couple of other startups: HomeView - is basically fits.me for home electronics and furniture; eXperQ - which is customer satisfaction surveying on cell phones; Kratid - a winner of garage48 - virtual and real life pet; Octarine - which creates content out of feeds similarly to recent Flipboard app for iPad. I was surprised to see that I actually know the whole team of Octarine - our ways crossed at Tartu University - I was giving object-oriented programming labs to these guys :). Last, but not least, Living Canvas who create “green” walls with plants growing out of them.
Also, thanks to organizers for giving us a chance to test our pitch!
Today, after 4 years of using Subversion as source code management system, we moved our code to github. This choice didn’t come easy, but it wasn’t difficult too.
Why we chose git/github and what we expect from it?
First of all, good feeling for our developers - using best available tools is something that gives us a warm feeling in the stomach; something that keeps us up at nights.
Secondly, better infrastructure for organizing code reviews: it is not needed to perform a commit (to master repository) in order to request a code review - simply send a pull request and start working on the next feature while your peer reviews changes. I plan to cover our setup more detailed as soon as we try it out on couple of first sprints.
Thirdly, we have a plan to use SaaS solutions as much as possible to lessen the administration burden - every minute we spend on administrative IT tasks we don’t do development of our products - something that we simply cannot afford :). So, natural choices were cvsdude, kiln and github. In the beginning, kiln sounded more favorable as some of our friends started to use it, but in the end we turned it down due to pricing and probable need to migrate to Fogbugz as well (and we already use Jira and we love it). I think github came as a winner due to 2 reasons: a) there is a huge and friendly community behind it b) it has a good feeling - everything seems to be right, all required documentation is there and it is easy to follow. Though, github had one disadvantage: there were no organization accounts and hence setting up a private repository was not natural, but recently it was fixed with introduction of plans for organizations.
So, putting all this together - we are very positive and optimistic about our move. Let’s see what will come out of it.
Do you have any experience or tips about using github with private repositories?
devPulse is a realtime activity stream that includes events from code repositories, task managers, issue trackers and other relevant info in the daily software development ecosystem.
