SonarQube provides a plugin for IntelliJ (and Eclipse as well) which is a great tool to perform dev-box code analysis before committing or checking-in your changes. It gives the developers a chance to check and make sure they aren’t introducing any new defects or technical debt in the code they have added or modified. Here’s how to set up the plugin and get going.
Install SonarQube IntelliJ Plugin
Launch IntelliJ and go to File -> Settings -> Plugins
Search for ‘sonarqube’ and install the plugin
Setting up SonarQube plugin
In IntelliJ go to File -> Settings -> Other Settings -> SonarQube
Add details about the sonar server here. The plugin will use this to download the quality profile/analyzers etc.
This plugin executes the analysis in preview mode where no data is pushed to the server.
Associate your IntelliJ project with Sonar project
Right click on the project in IntelliJ and select "Associate with SonarQube…"
Search for the sonar project and select it
Running the analysis
Make your code changes
Right click on the project and select Analyze -> Run Inspection by Name…
In the search box type "Sonarqube" and select "SonarQube Issue" from the result list
In the "Inspection Scope" dialog, select Custom Scope and set its value to Changed Files. This will ensure that the analysis is run on the files modified by you.
The plugin will run the preview analysis and display the results in the inspection tab. The inspection shows issues in two files which were modified before the analysis.
Branch policies in VSO allow you to set certain rules against branches in your Visual Studio Online git repos. They are more or less like gated check-ins which TFS has had since forever. Visual Studio Online supports the below policies by default:
Changes must be submitted to a branch only via Pull Requests
A build must complete successfully before changes can be merged to the destination branch
Add certain reviewers if the pull request modifies files in certain paths in the repo
To setup branch policies login to your visual studio online account and navigate to the team project, which has the git repo you want to set the policy on. You will need to have administrator privileges on the team project to setup the policy. After you’ve navigated to your team project, click on the settings wheel icon on the top right corner, this will take you to the admin panel of your team project. Select the ‘version control’ tab, and on the left rail select the branch you want to set the policy on (master branch in my case), and click on ‘branch policies’ tab. Refer the figure below, the click points are highlighted in yellow.
Under ‘Automatically build pull requests’, select both check boxes. You will need to provide a build definition here which VSO will queue every time a pull request is submitted or updated with a new commit. The second check box, ‘Block the merge’, is actually optional, if you want to allow the merge even on build break, you can uncheck this. Though I’m not sure why you’d want to do that.
The next section, ‘Code review requirements’, allows you to control how changes can be submitted to master branch. The first check box, ‘Require code reviews using pull request’, ensures that any changes to master happen only via pull requests and no one is able to push their changes directly to master. ‘Allow users to approve their own changes’, allows to you add yourself as one of the reviewers and approve the changes, which is nuts really :-)
The last option, ‘Add a new path’, enables you to add reviewers optionally depending on the files involved in the commits. For scenarios where you really want Dave C to look at the changes if anyone modifies files under \kernel\base. It has support for wild chars as well.
After the policies are set, when someone tries to push their changes directly to master, they see this:
So what you need to do now, is move your changes to a feature branch, push that branch to server and create a pull request to merge the changes to master. This workflow is explained in the link shared above.
Now let’s say, the feature branch was pushed and a pull request was created, but the change list has a silly syntax error. You will see the branch policies show up in the right rail and a build will be queued for verification.
Since the pull request had a syntax error, the build will fail and attempting to merge the changes to master will be blocked.
The next step is to fix the build failure, add a commit to the pull request and make sure you have at least one approval from reviewers. As soon as you push your local branch to server, a new build will be queued automatically and the status updated.
To enhance this even further, you can improve your build definition by, let’s say, adding a unit test build step and a code analysis build step, to ensure that all unit tests pass, before the pull request can be accepted and merged into master.
In this post we’ll look at how to configure an on-premise build agent to work with your visual studio online account. If you haven’t given Visual Studio Online a try yet, I suggest you head over to https://www.visualstudio.com/, sign-in using your Microsoft account, create a free VSO account and take it for a spin! If you’re new to VSO, these channel9 videos should help get you up to speed.
Create a team project and add sample code
For our purposes here, we’ll create a new team project and add a simple Windows Forms application to it and set up the build agent to build this project. After you log into VSO, select the ‘new’ link from under ‘Recent projects and teams’ section to create a new team project. I selected Agile process template and git as the underlying version control, but these aren’t necessary for our discussion here, you can try out other combinations as well.
Navigate to the newly created team project and select ‘Open with Visual Studio’. This should launch Visual Studio and might ask you for credentials to connect to VSO. Clone the repository and add a new solution to the repo, commit the changes and push them to the server. The project should now show up in the VSO portal.
Configuring the build agent
For the demo here, I’ll be using my trusty Lenovo ThinkPad as the build agent. Log into your VSO account and select the gear icon on top right of the screen to go into your account settings. Click on ‘Control Panel’ and select ‘Agent Pools’.
Click on ‘Download agent’ to download the VSO agent binaries and the scripts to configure the agent. Save agent.zip to your favorite location on the disk and extract it (for e.g. to c:\agent). You might need to unblock the zip file before extracting it, just right click on the zip file, select properties and check the ‘unblock’ box. The zip file contains the binaries for the build agent and also a powershell script, ConfigureAgent.ps1, which will help you setup the machine as a build agent.
Open a powershell prompt and navigate to c:\agent and run ConfigureAgent.ps1. This will launch a command prompt window and ask you details about the agent, here’s what to select:
Name for this agent: leave as default or give a fancy name
Configure this agent against which agent pool?: default
Work folder path: leave as default
Install the agent as Windows Service: Y
Your build agent is now setup and if you go to the account settings and refresh the agent pool, you should see the new agent listed under the default pool.
And that’s it! The build agent is now ready, we just need to create a build definition which will use this agent to build our project.
Note: The last step in the build agent setup, install as windows service, is optional. But I couldn’t get the project to build if the agent isn’t installed as a windows service. I will investigate this and update later.
Create a build definition
Go to the Build tab of your team project and click on + to create a new build definition. You can start from an empty build definition; add the ‘MSBuild’ task to the definition, browse and select the solution you want to build.
Under the ‘general’ tab, choose the default queue. Remember this is what we used while creating the build agent.
Give the build definition a name and save it. Select ‘Queue build…” after this to trigger a build. Within few seconds you should see the build being run. If you want to publish the build artifacts to a file share or any other location, you can add another task to the build definition ‘Publish build artifacts’, and set it up accordingly.
I had to get this setup up and running at work, thought it’ll be a good idea to jot it down here. The first step is to install IntelliJ IDE from here. I installed the ultimate edition which has a free 30-day trial, but the steps below should work well with the free community edition as well (looks like this does not work on community edition). We’ll be hosting the app on Tomcat server (running on a remote machine) so go ahead and install it from here. I installed version 8 using the windows service installer. And of course, since you’re developing a java app make sure you have the jdk installed.
Launch IDEA and create a new project, we’ll call it SimpleJavaWebApp. Select Java Enterprise and Web Application. Make sure the project SDK is set correctly and application server is set to the version of Tomcat you installed.
Let’s add a Java servlet to the project. Right click on the src folder in project explorer and select New –> Servlet, give the servlet a name and add it to the project.
Open MyServlet.java and copy paste the below code in the doGet() function,
If you are seeing an error which says “java: try with resources is not supported in –source 1.6”, go to project properties by right clicking on the project and selecting Open Module Settings, select Project on the left rail and change the Project Language Level to 8.
Let’s modify index.jsp to put an entry point to our servlet,
Go to Build –> Rebuild Project, and make sure the project is building fine. Let’s now package our application in WAR format (Web application ARchive) and deploy it on a machine running Tomcat.
Right click on the project and select Open Module Settings, click on Artifacts on the left rail and select + to add a new artifact type. Click on Web Application : Archive and select the project name.
Now when you build the project you will find file SimpleJavaWebApp_war.war generated under \SimpleJavaWebApp\out\artifacts\SimpleJavaWebApp_war folder.
Let’s deploy our app now, go to the machine where you installed Tomcat (it could be the same machine too), and under the Tomcat installation directory, copy the above WAR file under the webapps folder. For me the path is “C:\Program Files (x86)\Apache Software Foundation\Tomcat 8.0\webapps”. To make sure your app is working as expected, navigate to http://localhost:8080/SimpleJavaWebApp_war/ and check if the web page loads up correctly.
So the bulk of the work is done. We’ve created a simple Java web app, added a java servlet to it, deployed the application on Tomcat and made sure that the servlet code is invoked correctly. We’ll now look at how to remotely debug this app. This is useful is cases where you have the application running on a server, and your code and source enlistment are on a different machine.
To get remote debugging working, we need to instruct Tomcat to start the JVM in a “debug” mode and then attach to the JVM from IDEA.
Open Tomcat server properties, go to the Java tab and add the below entry under Java Options (make sure you add this in a new line),
Restart the server and check if you can access SimpleJavaWebApp from a remote machine. I setup the server and deployed the war file on a different machine and navigated to below URL to check,
We now need to create a debug configuration in IDEA to connect to this machine. Go to Run –> Edit Configurations… Click on the + icon and add Tomat Server –> Remote configuration. Make sure you specify the host IP address correctly. You can also modify the ‘Open Browser’ option so that the java app launches when you start debugging.
Switch to ‘Startup/Connection’ tab and set the TCP port to the one you used while setting up Tomcat, 1043 in this case,
Save the debug configuration and set a breakpoint in the doGet() function in MyServlet.java file. Now start debugging. You should see the web browser launch and when you click on the link to invoke the servlet, your breakpoint should be hit.
In case you see an error in IDEA which says ‘unable to connect : connection refused’, you might need a firewall exception for incoming connections on port 1043 (and 8080 too). So go to Windows Firewall settings and create an inbound rule on TCP port 1043 to allow incoming connections, and that should fix the problem.
Yep, that video above shows my HTC HD2 running Android Gingerbread (v2.3.4)! I came back home, and not having much to do thought I’ll give android another try. Sometime back I had tried running android from SD card but it didn’t work, later I found out that it was because of an older radio version on my device, so I had to update the radio version to fix it but it all looked like too much trouble and I put the HD2 back in its box. This was 6 months ago.
Today I thought I should take it for another spin. But this time we go all in, erase Windows Mobile 6 and flash the ROM with all the android goodness! It is pretty simple really, all you need is some patience to read all those articles on XDA a little carefully :)
The basic steps I followed are,
Check your radio version and update to 2.08.50 (if you’re running an older version)
Install MAGLDR 1.13 on your phone
Install Clockwork Mod on your device
Select an android ROM of your choice and flash. I chose the stock android gingerbread ROM version 2.3.4.
Here are the posts on XDA I referred to androidify my hd2,
I am still waiting for my invite. Looks like they are sending out invites starting from the list of supported countries, which unfortunately, India is not a part of. I’ll write when I get the invite and let you know how the installation goes on my HD7.
One thing that was pending on my “todo” list from a long time was implementing the ‘Game Of Life’ on Windows Phone 7. I got the basic version running in a couple of hours and I’ve been thinking about improving it since and adding new features to it. Maybe I’ll submit it to the marketplace someday, who knows. I have also been reading about gestures, multi-touch, pinch-to-zoom and related topics and most importantly trying to understand the math behind each of those gestures, and the math is so elegant that it fascinates me!
Game Of Life Game Of Life is a simple cellular automaton in which you create a pattern in a world made of rectangular grids, start the evolution process and then watch the pattern change as the world evolves. The world is made up of dead cells initially, you create a pattern by selecting a few cells and giving them “life”. The world then evolves according to a set of rules (source: Wikipedia):
Any live cell with fewer than two live neighbours dies, as if caused by under-population.
Any live cell with two or three live neighbours lives on to the next generation.
Any live cell with more than three live neighbours dies, as if by overcrowding.
Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
Gestures like translation, scaling and rotation seemed complex to me at first, but they’re pretty simple once you understand the math that makes the magic happen. I came across two great articles that really dig deep into these concepts. Both articles use the Silverlight Toolkit for Windows Phone 7 and the gesture support that it provides. I was a little surprised to know that the silverlight toolkit actually uses XNA’s touch api’s to detect gestures. These are the articles that you must read:
Charles Petzolds’ implementation makes use of Matrix transforms. It took me some time to understand matrix transforms and realize their importance in 2D/3D graphics. The only time I used matrix multiplication was to solve silly linear equations in college. You’ll find many a articles on the internet about matrix transforms but the best resource I found again comes from Charles Petzold. Chapter 22 – From Gestures to Transforms in his free book Programming Windows Phone 7. Download it now if you haven’t already, it’s a great resource.
The two paths had to meet. Using gestures in Game Of Life was the best way to learn them.
In my first implementation of Game Of Life, I used the Manipulation Delta events to support pinch-to-zoom. In this I used the DeltaManipulation.Scale.X and DeltaManipulation.Scale.Y values in the ManipulationDeltaEventArgs class (passed to the ManipulationDelta event handler) to modify the ScaleX and ScaleY values of a Scale transform on the object to be scaled. If that sentence didn’t make sense, don’t worry, this is the easiest and the worst implementation of pinch-to-zoom. The scaling was not smooth or accurate. To understand what a perfect pinch-to-zoom should be read this – Pinch Zooming using XNA on WP7: Getting it right. The article explains this with reference to XNA but the concept remains the same everywhere.
In my second attempt I used the Silverlight Toolkit for Windows Phone and Francesco’s implementation of pinch-to-zoom. It was working pretty nicely with a few quirks here and there. Though the implementation is easy to understand, I felt there were too many variables used for storing state information and the code looked a bit messy, but it worked.
It is while tuning this implementation that the MSDN Magazine article was published. Charles Petzold’s implementation felt intuitive and was much cleaner. The only part I had to figure out was the matrix transforms he used. And that I’ll explain a bit here.
This is what the app looks like,
The rectangular grids are added programmatically to a canvas. Here is the XAML for the canvas,
So during the Drag Delta and Pinch Delta events the transforms under currentTransform are manipulated to achieve the desired effect and once the drag or pinch gestures are completed a function, TransferTransforms(), is called:
To understand what is happening here we need to look at the XAML first. The RenderTransform on the MainCanvas is a double-barrelled (term used by Charles in his article) transform. Basically, a transform group within a transform group. So the effective transform on MainCanvas is equal to the effect of previousTransform plus the effect of currentTransform. Well, it’s not exactly “plus”. First, previousTransform is applied on MainCanvas to change its state, and then currentTransform is applied on that state to change it further. If you download and look into Charles’ code, you’ll see that during drag delta and pinch delta events, only currentTransform values are modified. Once the drag or pinch gesture is complete, TransferTransform() is called to “transfer” the values of currentTransform to previousTransform. And this transfer happens by the way of matrix multiplication, which is what the function Mulitply() does. It’s not over yet. After the multiplication the values of currentTransform (i.e scaleTransform, rotateTransform and translateTransform) are reset. This is important because, as we discussed before, the effective transform on MainCanvas is effect of previousTransform “plus” the effect of currentTransform. Transferring the values of currentTransform to previousTransform and then resetting currentTransform keeps the effect same.
CacheMode and BitmapCache
Now I got the translation, scaling and rotation to work correctly, but the performance was not very great. There was a huge lag in pinching and dragging, and this is where BitmapCache comes in. Every UIElement has a property called CacheMode, which can be set to BitmapCache.
In XAML, CacheMode=”BitmapCache”
In code, uiElem.CacheMode = new BitmapCache();
When the CacheMode of a UIElement is set to BitmapCache, a snapshot of the UIElement is taken and is stored in the video memory. So the element is not redrawn every time, instead all the operations are performed on the cached bitmap. This is super fast and is particularly useful when working with transforms on controls. Change the MainCanvas element in the XAML to include CacheMode,
and this will have a dramatic effect on the performance as you will see in the video below.
Please leave a comment if you have anything else to add.