Author Archives → Dariusz Łuksza

How to run multiple WordPress installations on one NGINX?

If you ever would like to run multiple WordPress installations on one NGINX server and sharing one domain name. Also you would like to have nice urls like /%catetgory%/%postnname%/ on both of them. You better do not do it in the root configuration block like this:

location / {
  try_files $uri $uri/ /index.php?$args /another-nestetd-wp/index.php?$args;
}

Of course this will work… but as a side effect posts from /another-nested-wp/ will be leaking into main blog RSS feed. Trust me 🙂 I’ve only found out about this thanks to JVM Bloggers and my colleagues asking me wether my site was hacked 😀

Some things one need to learn the hard way.

Nevertheless, proper NGNIX, configuration should be done for /another-nested-wp/ (not root node):

location /another-nested-wp/ {
  try_files $uri $uri/ /another-nested-wp/index.php?$args;
}

This way both blogs shouldn’t interfere with each other. And both can use nice urls 😉

One again many thanks to the community from JVM Bloggers for quick information about this (self)hack 😉

Gerrit Hackathon at Google HQ… next one is coming

Gerrit Hackathon 2015Gerrit Hackathon 2015

As always after the Gerrit User Summit, a Gerrit hackathon took place.
This time it was a five days event (9-11 November 2015), where members of the Gerrit community could work together, fully focused on making Gerrit a better software.
2015 edition gathered 15 participants from various companies like Google, SAP, Sony Mobile, Qualcomm, OpenStack, Axis Communications, Gerritforge and of course CollabNet.
Hackathons are really intensive periods of time for Gerrit project: over 400 patches were merged, three releases (2.11.5 and two release candidates of 2.12) were performed, countless number of open changes and patchsets were pushed for review.
This blog post summarizes work done during that period of time, showcasing new features upcomming in 2.13 and 3.0 release.

Gerrit metrics

Gerrit Metrics in Grafana2Gerrit Metrics in Grafana2

If you are responsible for running mission critical software for your organization, you must know how important monitoring and metrics are. How important it is to get fine grained information about the application performance. It is simply not enough to know whether it is up and running but also what is the overall shape of it.
This kind of information is especially critical when users start complaining “Gerrit is slow”.
From time to time such complaints arrive also to our team in Potsdam, then we use Splunk to analyze the load based on Gerrit logs and give our recommendations how to tweak Gerrit. Based on such cases our Gerrit Performance Cheatsheet was composed meuh7iu.
Starting from Gerrit 2.13 we will have a new tool in our toolbox! Internal Gerrit metrics!
DropWizard Metrics library is used as internal engine. Gerrit exposes over 1300 metrics about crucial internals e.g. http server response time, git receive pack, git counting objects, cache sizes, etc….
What is even more awesome, plugins can report their own metrics using the core API. This way replication plugin for 2.13 will report time taken to replicate repository data to various locations.
One thing is to collect metrics, the other is to store them. For this purpose three new plugins were created: metrics-reporter-elasticsearch, metrics-reporter-graphite and metrics-reporter-jmx. This gives possibility to plug Gerrit in into already existing infrastructure.

Hooks as plugins for core events

There are two ways in Gerrit how one can be notified about git operation related events. One is via event mechanism and another via Gerrit hooks. Both provide almost identical functionality making deciding on implementing one of them harder.

During our hackathon work was started to extract hooks mechanism into plugins that would listen to core Gerrit events.

This work is still ongoing, but once it gets finished one that want to run server side hooks must install the Gerrit hook plugin.

gwtorm can be used from plugins

You may be wondering what is the gwtorm. This is a library written for Gerrit project to access relational databases. It is a lightweight method of connecting your Java application to multiple different DB backends. Initially it was meant to be used only by GWT based applications (hence gwt prefix in its name), but currently it can be used by any Java application.

Why to use gwtorm in plugin? Well if you don’t want to modify Gerrit schema (which is highly discouraged) to store your plugin data and want to support many SQL dialects out of the box, gwtorm is the way to go.

The first plugin that will use this library is gerrit-ci-plugin.

Gerrit 2.11.5 and 2.12-rc

Gerrit releases don’t happen too often. Some time we had to wait long months (and over 1000 commits) to get new stable version of Gerrit. Usually just before the hackathon a release candidate of new stable version is cut from the master branch.

During this year’s hackathon we got three releases! One was a service release for 2.11 (updated release notes) branch containing fixes for javascript clipboard, styling, commit validation error handling.

Apart from service release two release candidates were published for Gerrit 2.12.

Submit whole topic dialog

Gerrit 2.12 changes how patches are submitted to the repository after code review. In all previous versions there was so called “merge queue” which was responsible for submitting patches in the right order. If particular change was submitted but its ancestors were still under review it ended up in a special state “submitted, merge pending”.

In 2.12 changes arranged in a branch (one change depending on the other) can be submitted at once by single click on the submit button on the topmost change.

Additionally new feature called ‘submit whole topic’ was added. It enables submission of changes that share the same topic. This can be done across multiple projects and branches.

One thing that struck us when this feature was presented during Gerrit User Summit was change in the semantic of Gerrit ‘topic’. Before 2.12 topics were only metadata that could have been freely added and removed. Plus there was possibility to search for changes that share the same topic. Starting from  2.12 setting a topic on changes will change how they are submitted. In some rare cases one can submit changes of others or block them because of a change not visible to all is still waiting for being reviewed.

To make submitting more verbose during the transition period, a submit dialog was proposed. It pops up after clicking on the submit button only when changes from the same topic would be submitted. It presents the list of changes submitted in a topic and without it, so that the submitter can choose whether to just merge the change in question or all changes of the same topic.

CI verification

Some time ago a Diffy build bot was introduced to verify changes pushed to gerrit-review.googlesource.com, but after some time it become unreliable, often was simply not verifying because it was not running.
Now there is new verifier in the picture. Based on proven gerrit-trigger-plugin custom REST API pooling strategy and Jenkins tandem. It is kindly hosted by the GerritForge. Long life to new GerritForge CI bot!

NoteDB

NoteDB is the defining feature of Gerrit 3.0. It will replace “conventional” database system and store everything inside git repositories. All the data that is currently stored in SQL DB will be moved to git repositories. Review related information will be stored in the particular repository using git-notes and special refs. User data will be moved to dedicated repository.
During the hackathon further steps into achieving the goal of removing the dependency from SQL DB were performed, some integration tests were fixed plus NoteDB tests were enabled  as a part of verification job.

New Gerrit UI with Polymer

Last but not least, the new Polymer based WEB UI for Gerrit was initially announced and integrated into Gerrit’s build process.

During the Gerrit User Summit, Google has presented the draft of a new Gerrit WEB UI. This time it is written using Polymer framework, which is a new JavaScript UI design framework from Google.

The new WEB UI will be fully written in JavaScript, making it easier for UI/UX designers to modify and faster to develop and compile.

As I mentioned before, during hackathon PolyGerrit project was integrated into standard Gerrit build system. It requires teaching Buck how to deal with javascript and its dependencies.

What is next?

Next is the Berlin Gerrit Hackathon in 2016. We’ve open a poll to gather input from the community about preferable date between 22nd of February and 25th of March 2016. Please participate if you would like to join us and hack Gerrit in Berlin 🙂

One Plus One and Rode SmartLav+

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!

How to easy customize Gerrit Submit rules

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:

  1. Verified +1 (V+1)
  2. 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.

Why it is harder? Because of Prolog.

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.

It contains two key parts:

  1. Quality Gate Gerrit Backend plugin – that adds special Prolog fact capable of understanding XML based configuration parameter.
  2. 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 1 2 3

Learning Gerrit Code Review by Luca Milanesio

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!Learning Gerrit Code Review book cover

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.