Monthly Archives: August 2014

Upsource EAP Preview – Repository Browser and Code Review From JetBrains

Written by William Roush on August 28, 2014 at 10:38 pm

This article is a bit out of date, JetBrains has made some changes that I need to review and update the relevant sections of this article.

Upsource is a new code browser and code review system by JetBrains, the guys behind popular development software like Resharper, IntelliJ IDEA and TeamCity.

Update: I’ve been talking with some of the developers, I’ve made notes around the article with things they’ve gotten back to me about.

Upsource Early Access Program

Upsource is currently available through it’s Early Access Program — Mind you everything you read here is about Upsource in it’s EAP state, I’ll be doing more reviews as the software evolves (JetBrains continuously adds awesome stuff to their software).


Shame on me, didn’t check this at first. Threw it on a Linux machine with 2GB of memory, watched the entire system crash with out of memory exceptions. Oops.

The 8GB of RAM is a little steep, but it’s sitting on top of Java, so some memory hungry behavior is expected.

UpSource is a bit hungry resource wise.

Upsource is a bit hungry resource wise.

You may want to throw two CPU cores at it, startup was a bit slow, however once it was running the application was smooth.

Lets Get Started

So I unpack the zip file, install OpenJDK 7’s JRE, and fire up the services, Upsource is reported as online, but I’m met with a blank page while Java thrashes about. Very easy to set up though.

Project Management

Creating A Project

Creating a project is quite easy, give it a name, point it at your current repository sever, and away you go. No hang-ups here really.

Project Sprawl

At the current moment, for those of us working at places that have 40+ projects, it looks like there will just be a massive amount of horizontal sprawl going on, TeamCity had a similar issue until recently when project hierarchies were added, I’m sure this will end up in Upsource at some point.

This also includes the groups that are automatically created (“[project] Developers”, “[project] Observer”, and “[project] Project Admin”), these will be created for every repo you have, even though you’d likely have a ton of repos under one group schema.

Main Upsource UI

Main UpSource UI, showing projects and a news feed.

Main Upsource UI, showing projects and a news feed.

When logging in you view all available projects and your news feed. I really dig the news feed, showing all comments on your reviews and mentions for your user account. The main thing I don’t like is that getting to this page from a child project is annoying.

Project Status UI

Project overview UI is pretty straightforward.

Project overview UI is pretty straightforward.

The main project UI is pretty basic but gives you what you want, on the left side you see a handful of recent changesets with a nice visual tree. From here you can navigate to a commit to start a review, browse code in the repository or jump straight to analytics.


This is one of those major extras I love with systems like Upsource and Crucible. This gives a very visual breakdown of who handles what commits, and who is handling what reviews.

Statistics for Redmine contributions pulled from Bitbucket

Statistics for Redmine contributions pulled from Bitbucket

The visualization is powerful, I’d like the ability to map multiple users together to a single user in Upsource (doable in Redmine, Crucible, etc.), please allow this setting to be global (a major problem that Crucible had the last time I used it).


Code Reviews

This is by far the biggest reason I was looking towards Upsource. Previously I’ve looked at using Crucible for our code review system, and like 90% of it, however there is a critical piece of functionality it lacks, and that is supporting a good UX workflow for post-commit review for multiple branches of code. Sadly Upsource also suffers from this problem (and straight up doesn’t support it, more on this later).

My Mercurial Workflow

Basic mercurial workflow I follow.

Basic mercurial workflow I follow.

The workflow process I follow is pretty straight forward, each bug or feature gets it’s own named branch on Mercurial, each branch is closed and merged onto a staging branch where things are tested, verified and reviewed, and once everything is approved onto default it goes to get tagged and released.

Where Upsource Fails To Support This Workflow

Update: This is planned to be fixed in the 1.0 release, I’ll see if the UI works well.

To create a review in Upsource you select a single commit and click “Create Review”, from here you can add more revisions using Upsource’s powerful search system.

There are a couple issues I have however, if I search for “branch:stage-1.1.0”, it will also apparently bring in any parent of the named branch “stage-1.1.0” which will include all previous commits, so I can’t easily just add all commits I see on the search page.

I can search for each invididual commit ID by searching for “id:[] OR id:[] OR id:[]” for every included changeset, however there is a problem with including changesets from different branches (more on that later).

I’d love for some powerful way to select all items between the default commit at the bottom of the workflow image above and the last staging commit, this would make the workflow a thousand times easier and would instantly have me sold.

Code Review UI


Inline review is pretty clean, single-line comments leaves a little to be desired.

Inline review is pretty clean, single-line comments leaves a little to be desired.

The UI is pretty clean, one feature I do miss from ReviewBoard is being able to make block comments. This allows you to choose a range of line numbers by clicking and dragging and putting a comment on them. This allows you to bring a developer’s attention to a block of code instead of an individual line.

Side-by-side diffs are available too.

Side-by-side diffs are available too.

Side-by-side diffs are nice, double clicking allows you to still add comments to the commit, this wasn’t immediately apparent and they should probably leverage the same edit icon on the inline code review diffs.


Additionally, I really did prefer the nice single file UI that Crucible has, I’ve worked with some changes that can span 10-15 files, and hundreds of lines of changes. When these are all crammed onto the same page your scroll bar can get really tiny (and some other ill effects in terms of browser performance can begin to happen). These aren’t often, but when refactoring old code bases it’s bound to happen.

Code Review Process

Unlike Crucible there isn’t a predefined process, which is unfortunate, every time you do a review you add individual users to the review and individual users as watchers.

Completed reviews show a green check box near the user's icon.

Completed reviews show a green check box near the user’s icon.

I do like that you complete reviews, which is better over ReviewBoard which only includes a “ship it” button, so no way to mark a review as completed but the code quality insufficient for production.

Reviewing Code From Multiple Branches

Update: This is planned to be fixed in the 1.0 release.

So when attempting to review code from multiple branches (say from my example of the resulting code from bug 1 and bug 2 to be pushed to live), you are greeted with this error:

No multi-branch review support.

No multi-branch review support.

So even if I was patient enough to select each individual changeset it won’t support it.

Repository Browser

Code Display

Code browser, limited language support.

Code browser, limited language support.

The code display is pretty straight forward, lets you browse through your repository, uses the same display as your inline diff UI, only thing I wish I had here was multiple language support (even if it was a framework that 3rd parties could write tools for).

File History

File history, what more is there to ask for?

File history, what more is there to ask for?

File history is pretty straight forward, I seriously can’t think of anything to ask for.

Code Annotation

Annotation works like blame in Git/Mercurial.

Annotation works like blame in Git/Mercurial.

Code annotation is pretty nice, shows you who and what changeset the last changes came from, much like blame in Git and Mercurial, but this UI is a bit nicer and will let you navigate straight to the related changeset.

Final Thoughts

Sadly Upsource doesn’t support the code review process I’d need to adopt it, however JetBrains is known to constantly improve their product line and I’m eager to see this product continue to evolve. If you don’t mind per-commit reviews (instead of batching reviews based on branching policies) then I’d recommend you keep an eye out for Upsource coming out.

Required Features Before I’d Use it

  • Support for batched reviews, based off the results of multiple branches coming together.

Tasty Features

  • Ability to define a more strict revival process (all reviews require approval from [x] people from team [a] and/or [y] people from team [b]), with the ability to automatically mark a review as complete with this objective is met.
  • Approval/rejection of a code review.
  • Single-file review process that isn’t just side-by-side.
  • A little more love for the side-by-side UI.

Bugs I Ran Into

  • Every once in awhile when refreshing a page, I was greeted with an authentication failure error, refreshing the page a few times would generally fix this.
  • Adding an empty repository will have pretty bad consequences and errors everywhere.


  • On every page you navigate around Upsource you are greeted “Loading Upsource” UI element while the page loads, as if they intended it to be a single page application but moved away from it. At least I don’t typically see this behavior in an application that has a bunch of individual pages. Update: The application is supposed to be a single page application! Found a bug that apparently is known but they’re gathering info on, will be providing info to JetBrains to fix.

How VMware Can Make The Web Client Awesome

Written by William Roush on August 4, 2014 at 12:39 pm

Some pretty basic design principals that would make the web client on VMware awesome, including the ability to make it redundant and supported on free systems!

I was reading this article by Trevor Pott, which does a fairly good job dealing some major problems on VMware’s vSphere web client, and how absolutely terrible it is. However I have some major issues with this article, first of all is no real concrete suggestions on architecture changes (how do we handle the vCenter single point of failure? What about free clients? What about the Flash plugins?). Here I’m going to offer up some suggestions to reaffirm Trevor’s stance that VMware could and should do this better!

A True Single-Page Application

By far I figure one of the easiest ways to resolve all of our issues is a solid single-page application. This is the concept that the website you visit will load all the resources needed on your computer to run without refreshing the page. This is generally done using HTML5 and Javascript, common frameworks include AngularJS and Ember.JS. A giant flash application like the vSphere web client has now doesn’t really count.

How to Handle the API

Some suggestions on how to handle API calls to the hosts/vCenter:

  1. Transparent layer – Have the web server host a JSON based API that gets translated into the API calls to the host/vCenter box. This allows you to have very low overhead calls (as opposed to very noisy SOAP), and allow Javascript to do what it does best (talking in a native tongue instead of using Apache CXF for Javascript clients). This incurs minor overhead on the host running the web server to do the translations, this also effectively creates two web APIs you use (though arguably you wouldn’t support consumption of the JSON API).
  2. Reverse Proxy – This allows you to remove any difficulty with Javascript dealing with cross-port requests, but you’re going to be leveraging something like Apache CXF for the web services.
  3. Direct Communication – vCenter and VMware’s APIs already exist over HTTPS for web services, if you serve up the single-page application from the same domain/port in a hybrid host setup there will be no additional overhead!

In-Browser Remote Console

Now this is the one piece I will detail is pretty experimental, and by all means feel free to fall back to a Flash/Java console, but what I’d really like to see is a true in-browser console, look at solutions like Guacamole which runs a full VNC client in-browser. Of course there may be some barriers here (Guacamole requires server-side code, not sure how much overhead is acceptable on the Busybox management VM on vSphere).

The only feature I can’t think of reproducing in HTML5 is direct device access required for mounting ISOs/USB devices.

Addressing The Single Point of Failure

These thin API layers (or in one case non-existent) allows not only vCenter to support these single-page web applications, but also the individual hosts. Now it becomes safe to completely scrap the old vSphere desktop clients.

Browser Security

Trevor Pott does some hand-waving about security issues on browsers, and then goes in to complain that the problem really relies with Flash and Java Applets. I’d recommend dropping auto-sign on removing all need for plugins and leaving it at that.

The current desktop client embeds Java applets for some 3rd party tools, so to say it’s more secure is silly.


The old Windows client is imperceptible. Click and the info is there. Expanding a tree just completes in a time frame so short that a human can’t tell there was a delay.

Yeah, I’m not going to stand by this stance at all, the desktop client is a massively bloated slow piece of garbage. It eats a massive amount of memory, is prone to killing consoles and requiring you to play whack-a-mole in your process manager to kill the spawned processes and get it online again.

The web client is slower, but the desktop client isn’t some kind of idea of what we’d want to achieve, that was pretty bad to begin with.

Using PowerCLI it seems like most operations are pretty instant, so it just seems to be entirely overhead on the applications themselves, so a well-written single-page application could easily handle this and be lightning fast.

What’s ultimately the damning element of this is that Internet Explorer is the most common enterprise browser. In many environments, browsers that aren’t Internet Explorer are outright banned. 

This is more of a problem with your work environment than the web application itself. If you’re on IE11, things are pretty decent (Javascript is fast, support for modern things is pretty up to date). If you’re at a company that keeps you on IE8 and wont let you install Chrome, that is absolutely no fault of VMware’s.

 Other Options and Why I Think They’re Not Good Routes

Native Application

This is going back to the roots of the vSphere desktop client, which generally comes with the same problems (going to be Windows only). I highly doubt VMware will write some GTK+ Windows/Mac/Linux client. So far VMware has still been unwilling to patch a major problem with RVC, so I don’t think they’re giving attention to more “hip” languages like Python and Ruby.

Cross-Platform Application

The next option is planning on a cross-platform application, and I know what they’re going to do: what ever other vendor has done.


I don’t really think I need to say more, I have a love/hate relationship with Java, but most system admins have just the hate side. Mainly it comes down to writing cross-platform applications can be more costly in languages that aren’t like Java with a nice solid platform.

Mono is also an option, but I have a feeling VMware won’t jump on that boat this early.


By far, one of the best parts of major infrastructure decisions: freebies. Additional features or supported platforms with reduced, little or no effort. This list is by no means exhaustive.

OSX/Linux Support

This has been a goal off and on for VMware, obviously fully HTML5 will get you 98% of functionality on OSX and Linux, with minor plugins needed for device management.

Mobile Support

Take that single-page web application, wrap it in a delivery method like PhoneGap, stylize it so that it fits better on the device (different CSS files for phone/tablet), and you’re going to have not just a small subset of features (like most current mobile apps available), but the ability to fully manage your VMware cluster from the ground up.


There is no reason that VMware should have shipped the web client in it’s current state, nor is it an example of why VMware shouldn’t dedicate resources to writing solid web-based management software, it misses most of the point while throwing all of it’s resources into a dying framework. A bit of design centered around delivering the things customers have been asking for could lead to a product that will put all competitors to shame, instead of turning them away from vSphere.