As you may know One Plus One is a reasonably priced smartphone that is called a “flag ship killer”. It features awesome hardware (like quad code Qualcom processor, 16MB camera, 3GB ram and 64GB of internal memory; not to mention recording 4k videos). In case of sound reproduction it is also OK, the same goes for recording audio using internal microphone(s) (yes, it has plenty of internal microphones; three to be exact). But how it would sound with Rode SmartLav+ lavalier microphone?

Let’s start from my use case. Some time ago I’ve recorded a screencast that features over 60 Eclipse IDE shortcuts that boost Java developer productivity. For now it is only available in Polish ;). To keep costs low I’ve decided to go with build in microphone into my MacBook Check Out Your URL.

What is the effect? I would say it is OK, if you consider my knowledge about audio recording back then and room acoustics. But this means that there is a filed to improve 😉

First of all I’ve discovered that I’m more comfortable speaking (and describing things) while I’m standing. (Maybe this is because of presentations that I did…) Also my voice sounds better when I’m standing. But this has a down side, sound is kind a flat and it is getting significantly louder when I’m moving closer to laptop to press key shortcut that was recently described.

Of course one can improve both things in so called “post production” state (which I’ve learned later), but still I didn’t like the over all effect. … Yes, I’m kind of a perfectionist 😉

So I used the power of Google to find how I can improve this situation. This way I’ve learned about Rode SmartLav+.

What is Rode SmartLav+? It is a lavalier microphone. What does it mean? It is this kind of microphone that can be pinned to you (T-)shirt, or hidden under it. It will pick voice clearly. Also it is always in the same distance for your mouth. This means that you can walk and talk without any consequences to sound quality and level.

What is more it has a connector that fits all smartphones! This means, a standard 3,5mm jack with three black stripes (so called TRRS).

The idea behind it, is that you don’t need to have a special recorded to use it you smartphone is all that you need! Sounds great, isn’t it?

This also builds the cheapest wireless microphone setup! Just connect SmartLav+ to you smartphone, put it into pocket and… you’re done! Later on one need to synchronise audio and video, but this sounds like a easy task to do.

Going back to the main topic… I’ve got my SmartLav+ yesterday and immediately started testing it with my One Plus One.

First I’ve used “build in” recording app that comes stock with OPO… and you can’t imagine my disappointment while replaying the recording… voice sound war nice, full and reach… but the background nice was awful! There was a hiss and if you listen carefully enough will also hear some pops and cracks. For me this is not acceptable!

This is much worse compared to what you get on build in microphone in MacBook or in OPO.

My first guess was that recording could be somehow (don’t know how but maybe) broken. But there is plenty of recording apps in PlayStore! Lets try a different one!

Let me check another app – that was my first idea. I’ve installed maybe five different apps that had highest user rating. But on all of them effect was the same 🙁

OK, so maybe there are some interferences with build in radios (GSM and WiFi) – was my next guess. Switched OPO to airplane mode… which makes no difference. Pops, cracks and hiss were audible in the background.

So, maybe the is something wrong with SmartLav+? – another guess. First I’ve connected it to MacBook, but it was still using the build one (it is easy to test that, just scratch the left side of MacBook and observe ‘Input Level’, it shouldn’t pick this up… but it did). Thankfully I still got Nexus S and quick install of RecForge || turned it into another testing device.

Results? Not really impressive. Pops and cracks are gone but hiss is still present and even more intrusive than on OPO. Voice also sounds differently, to be honest I preferred sound of OPO. Other than that, Nexus S is much louder. That means that input level on RecForge II was lower than on OPO (-10dB compared to -5dB). Apart from that RecForge is really slow on this device. The UI has noticeable lag in response time, adjusting input level is problematic. And overall it doesn’t sound nice.

Here is sample recording done that demonstrate sound quality on both devises:

So what to do next? Go with slow and not responsive Nexus S or, use OPO with pops and cracks. Of course those distortions can be remove in post production using eb. Audacity. But this gives overhead for each recording. Video editing gives already enough overhead for me, I’m not sure if I want to become an audio expert…

So I’ve decided to go with a field recorder, Zoom H1 to be exact. I hope that this will set me for the rest of my live ;). Will spent “few” bucks (euros) more, but hope that this will save me “post production” time and the sound quality should be extraordinary!

Why Zoom H1? Because it is (kind of) cheap, it can also be used as a external USB microphone (!), is small, have good reviews and (thanks to v2.1 firmware) it can work as a USB3 device.

Unfortunately Rode SmartLav+ will not work with directly with Zoom H1 🙁 because it accepts only TRS inputs (those with two stripes). But there are adapters like Rode SC3 that will do the trick to make it working…

o now I’m waiting for Zoom H1 and SC3 connector. Hope that sound quality will be substantial!

Gerrit submit rule is a set of conditions that needs to be fulfilled before change can be submitter (read merged) to given branch. By default there are only two simple conditions:

Verified +1 (V+1)

Code Review +2 (CR+2)

First one means that change don’t break the build (or project integrity). This step can (and it should) be automated using, a continuous integration system like (jenkins with gerrit trigger plugin). Automation here will save tons of men hours spent on reviewing code that doesn’t compile and/or break unit/integration/system tests.

Second one (Core Review +2) means that somebody from the team spent some time on reviewing and understanding the change. And this particular person didn’t found issues in it and thinks that this change is ready for production.

This set of rules seams to be reasonable and will be sufficient for “most” of the projects. But it has some flows, indirectly build in.

First of all there is no condition on the person that is giving the CR+2. In this case, change author can submit his own change, because there is no condition that would block him from doing so.

Also if you would like to enforce more strict review rules for given project. eg. at least two CR+2 are required to submit a change. You will probably end up with ‘internal convention’ not something that can be enforced automatically by Gerrit.

Of course, one can say that those two cases are exotic. Yes, in a way they are. But my point here is that default Gerrit submit rules are OK for (let say) 90% of projects. Projects that fallow Android OpenSource Project review principles (they can even don’t know that they fallow them ;)).

What is with rest 10%?

No, they are not forgotten by Gerrit… but they have a bit harder live at the beginning.

Gerrit gives you a tool for defining your own Submit Rules per project. But the entry point is (I would personally say) high.

To define your own Submit Rules one need to learn Prolog programming language, then understood Gerrit Prolog API and finally define such custom Submit Rules per each project in refes/meta/config branch.

This is awesome! Show me a tool that have such flexibility build in, ready to use … and it is free? Yes, entry level is high but, come on, this is one time investment and you are set for (almost) a live time… 😉

But maybe we could do something better here? Maybe we are missing something here… maybe we are not looking abstract enough.

Let me compare code review process to standard build process. In both cases you have some steps that need to be accomplished before you move to next mile stone. In build first of all source code files need to be compiled, same goes for test source files in next step. After that tests are run, and when they pass successfully, project can be packaged and put into production.

Same goes for the review process. First of all change need to be verified (compiled and tested) then team members are looking on code and if they found issues with it, change must be reworked. If not, it can be “packaged” to “production” I mean, merged to branch.

If we use such approach, then maybe instead of writing code for review rules, we could have a configuration file. Why not put the configuration and convention over Prolog code?

Provided that we would have such configuration syntax in place, then we could define set of rules that will verify the configuration file. Then wring UI for generating such config file shouldn’t be so hard (compared to generating Prolog code).

What if…

OK, lets finish with those “what if’s” because there is noting to wishful thinking. Why? Because we already implemented such ‘configuration over Prolog code’ approach in CollabNet. This is what we called Quality Gate wizard.

Quality Gate RCP Wizard – Eclipse based desktop application (build into GitEye app) that allow you use one of 15 predefined rules, define new submit and edit existing one. Then upload that to Gerrit. Everything from your desktop, no command line, text editor or git command is involved in that process.

More information about Quality Gates can be found in our blog posts 123

It is finally there! The idea behind this book was mentioned many times during the Gerrit community meetups and finally Luca made it a reality! The Gerrit book is out there and it is pretty good read!

I had an opportunity to go through this book and I must admit that this is a fully complete guide to Gerrit. You will learn not only how to use Gerrit, how to create, publish and submit reviews, but also how to setup Gerrit from scratch, integrate it with Jenkins/Hudson, GitHub and your corporate Single Sign On mechanism. Moreover, there is even an example configuration for Apache reverse proxy! If you are not familiar with Git Version Control System, you can even find there essential information regarding this matter. In other words, this is an exhaustive introduction to Gerrit.

In the book you will find an example of a code review workflow with a detailed description how things work in Gerrit, why and where to put ‘Change-Id’ as well as why it is so important for Gerrit. Apart from that, you will learn about Gerrit’s terminology and conventions used in the community such as WIP, RFC, ‘nit’.

All in all, if you are planning to start yours journey through code reviews with Gerrit, this is the position that I can highly recommend for you.

At the beginning of May 2013 first European Gerrit Hackathon took place in London. It was quite some time ago (more then a month), but in my opinion it is always good to have summary afterwards.

So, as I mentioned it was first Gerrit Hackathon in Europe, organized by Luca Milanessio in London and kindly hosted by ITHR Consulting. Twelve participants come from variety of countries and industry areas to work together on Gerrit. We had three really productive days full with many interesting discussions, about project future and new improvements, and code sessions with interactive feedback loop (no delays or time zone differences) … just focus on task at hand and proper solution for it 😉

I think that main topic and killer feature of this hackathon was inline editing driven by Marting Fick (Qualcomm), Edwin Kempin (SAP) and Dave Borowitz (Google). As far as I know this is already available in current master branch (2.8-SNAPSHOT) and allow user edit its commit in the browser. By ‘edit’ I really mean editing files in browser and ‘commiting’ them back (of course this will create new patch set). With this functionality you can easily and quickly fix typos/white spaces/comments in code and commit message without fetching given change locally, amending and pushing back. This could save tons of time… but of course it could hit you very hard if you are not careful enough.

Another interesting topic, which actually is not often addressed during such events, was … documentation. Lets be honest, Gerrit documentation is good when you are a contributor/commiter, but for the new comers or end users it is simply unhelpful. Huge thanks to Fredric Luthander (Ericsson) who bring this topic up and did awesome work in this area! … I’m not really good in documentation, and still need to update Gerrit docs about JavaScript and GWT based plugin development hopefully will do it … in few months 😉

Next topic was statistics and some ground work around generating reports from Gerrit. AFAIR Edwin Kempin, David Pursehouse (Sony Mobile), Gustaf Lundh (Sony Mobile) and Emanuele Zattin (Switch Gears) had some discussions how stats can be collected and accessed. AFAIR there was also a (POC (?)) patch send for review that was adding REST service with some basic statistics.

I think that most of Gerrit administrators and contributors doesn’t know what term ‘capability’ means in Gerrit environment. So, ‘capability’ is ‘type of permission’ eg. ‘forge autor’ or ‘label verified’ are core Gerrit capabilities. Unfortunately plugins cannot contribute their own specific capability, this is really painful in case of replication plugin. Which uses ‘start-replicate’ capability defined in core (but not used there) to grant users permission to execute replication. Looks like this awkward situation was somehow painful for David Ostrovsky (independent) since he started working on this topic (together with Dave Borowitz). I know that there was some patches send for review and I hope that in 2.8-SNAPSHOT this problem is sorted out. Also this means that other plugins can contribute theirs own capability and extend this way Gerrit access rights.

There was also continuation of (never ending story) Gerrit multi-master configuration. As usually this topic was brought by Luca Milanesio and Deniz Türkoglu (Spotify) 😉

Deniz Türkoglu during hackathon was also working on ‘blame plugin’ for Gerrit. The idea is to send mails to code-line-authors when somebody changes specific line or code section. AFAIR there was serious problems with Gerrit API that disallow accessing DB out of RequestSope. Hope that this problem will be solved in nearest future and we could enjoy this plugin in community 😉

And finally, last but not least, my main focus area in Gerrit… the WebUI extendability. Together with Luca Milanesion, Emanuele Zattin and David Ostrovsky we tried to make Gerrit more extendable. David was pushing to server side UI extensions and already did some ground work for this, so I’ve picked up this idea and implemented server side extension port for contributing links to Gerrit top menu (code example), then Luca comes and integrated it with GitBlit plugin. But my main goal is to have native UI plugins in Gerrit either in JavaSript, GWT or ClojureScript (everything that compiles down to JavaScript) so few hours later I’ve proposed event based JavaScript API. Right now this is only a concept and I’m looking for feedback about it, currently it only allows to add rows into patch info table (code example).

Last few hours of hackathon I’ve spent on investigating GWT replacements for Gerrit WebUI. After investigating some possibilities I’ve chosen AngularJS and did initial hacking. There is not much to share right now, I can just say that implementing project list page in Angular was really fun and straightforward. But playing with new JavaScript ecosystem was quite pain for me … maybe I’m to Java-ish ;). Currently I have replacement for current GWT based project list page in Angular, but this was the easy part (I think) more difficult would be to integrate this with current Gerrit GWT UI and build system.

As we are in ‘build system’ topic… during hackathon decision was made that Gerrit will give a try to Buck (ant-like, developed in Facebook, similar to Google’s) build system. In Gerrit 2.8 you will not find pom.xml but BUCK file, this transition should make Gerrit development and releasing easier. Gerrit’s Buck srripts can generate Eclipse project configuration files, also use maven repositories for fetching dependencies. I can confirm that with without tons of Maven projects in Eclipse, IDE is more responsible, GWT development is faster and easier… also build time is shorter … but … there are the down sides as well. Buck is only supporting unix like systems and it is not (yet :)) an industry standard.

OK, I think thats it… I had a great time during this event also during my morning runs in Kensington Gardens. Hope to visit London again. See you all on next Gerrit Hackathon/User Summit 😉

During my git trainings I often say that Git is land of freedom, and this is really true. Not many version control system would allow you to change something in history or permanently delete branch or tag. Git some times will prevent you from doing bad stuff, but you can easily say “shut up, I know what I’m doing” just by passing “force” flag (-f). Here I’m thinking about “force push” (aka “history rewrite”) when you can change something in repository history.

Local history rewrite is really useful when you are crafting yours commits. You can easily rearrange them, edit theirs content and commit message by using “rebase interactive”. I’m using this functionality on daily basis and cannot image working without freedom which it gives!

When we are talking about ability to rewrite remote history some people get really scared, especially in large organizations or those that needs to fallow some strict rules like banks and government orgs. From one hand Git and its “SHA-1 checksumming” ensures them that repository wasn’t changed … but from other hand Git allows changing something in past, of curse such change would be quickly spotted and can be fixed. Simple thought about occurrence of such event scares many enterprise companies, especially when they somehow find out about incident in Eclipse Foundation where almost all branches was accidentally deleted.

One of my first tasks in CollabNet was to provides a safety net against force pushes and branch deletion in Git. Our idea was to provide mechanism that could be easily activated and deactivated, will be accessible for regular users and administrators (regular user can resurrect rewritten history and deleted branch, administrators also can do that but also can permanently remove those entries) and protect whole (even deleted and rewritten history) against Git garbage collection. Base on those assumptions we come up with History Protection mechanism. If you want know more about it you can watch our short movie or read my other blog post. There is lots more cool Git Enterprise features coming from my CollabNet’s team in Potsdam 😉