If there’s a set of data you regularly look up in SonarQube, the Measures Service – and saved filters – are going to be your new favorite SonarQube features.
A user at my day job recently showed me a spreadsheet he’s using to track the metrics of the “worst offender” files in his COBOL project. I was afraid I already knew the answer, but I asked how he was getting the data for each file. It was one time I wasn’t happy to be right – he was doing it the hard way, manually recursing each branch of his project’s components tree to find the numbers.
That’s when I pointed him to the Measures service. It lets you search for any type of resource based on a host of criteria. He was looking for files in his project that exceeded a certain threshold. This doctored screenshot shows the kind of search I showed him how to run:
First he specified what he was looking for: files, and then the criteria by which to choose them: Components of the project, SonarQube in this case, with Coverage less than 90%. Just having the list of relevant files pulled neatly together thrilled him; I could tell by the way the corner of his mouth quirked up.
His mouth quirked again. He was really happy. Except…
We both started to speak, but he beat me to the gate, “Can you save…?” I knew he didn’t want to have to reconfigure this every time – who would?
I had him close column editing mode (a crucial step), and the “Save As” link reappeared:
He gave it a name, and knew that from then on, it would always be waiting for him in the saved filters menu:
I got the mouth quirk again.
Then, I showed him how to use a “Measure Filter as List” widget on his own private dashboard to display the saved filter automatically, and pointed out that he could make that dashboard the first page he saw in SonarQube.
He actually smiled.
It makes me enormously happy and proud to announce that the Selenium Conference 2014 will be held in Bangalore on the 4-6 September. I’m looking forward to seeing you there!
One of the plans we’ve had from the very beginning for SeConf was that it was going to be a conference for the community of people who make Selenium such a fun project to work on. One way to do this was to host the conference where the largest groups of people using Selenium are found. We kicked off the first conference in San Francisco mainly because of the large number of Selenium users there (and, I’ll be honest, because that’s where the organising team had the most experience and contacts!)
In Europe, that large pool was London, so we held the second conference there. We had originally planned for the third conference to be in New York, but that proved to be a little too expensive, so we moved it North a little to Boston. Essentially, the pattern is that we alternate between the US one year and The Rest of the World the other.
That brings us to the planning for Selenium Conference this year. We had a look at the data available to us, and noticed that there were two areas of the world that it would be great to take the conference to. Selenium Camp, hosted in Kiev each year, does a great job of catering to one of these groups, so that leaves the second.
It’s India’s turn.
Thank you to everyone who’s already poured so much heart and spirit into this conference. We’ll be putting up a call for papers and more details soon, so please stay tuned!
As a quality-first focus becomes increasingly important in modern software development, more and more developers are asking how to find new issues before they check their code in.
For some of you, it’s a point of pride. For others, it’s a question of keeping management off your back, and for still others it’s simply a matter of not embarrassing yourself publicly. Fortunately, the SonarQube developers (being developers themselves) understand the problem and have come up with three different ways of dealing with it: the Eclipse plugin, the IntelliJ plugin, and the Issues Report plugin.
All three allow you to perform a pre-commit check on your code, and the two IDE plugins use incremental mode, which shortens analysis time by looking only at the files you’ve edited, rather than re-analyzing every file in the project. This recent improvement takes running a pre-commit check on a large project from a productivity drag to just another simple step in the process. You can use incremental mode with the Issues Report plugin too, it’s just not the default.
Both IDE plugins support Java, and the Eclipse plugin supports C++ and Python as well. For any other language, regardless of your IDE, you’ll want to use the Issues Report plugin, which isn’t an IDE plugin at all, but one you install in SonarQube itself.Eclipse
If you’ve heard of pre-commit analysis before, it was probably in the context of Eclipse, because the Eclipse plugin has been around the longest. Once you have it installed and configured, you’re ready to start working with it.
The first thing you may notice after linking your local project with its SonarQube analog is that extra decorators show up in your code.
Each decorator marks a line with an existing issue. Mouse over a decorator to get a tooltip listing the issues. There’s also a SonarQube Issues view, which gives you a listing of all the issues in the project, but can also be narrowed to show only new issues. Double click any issue to open the relevant file and jump to the appropriate (or rather, “inappropriate”) line of code.
When you’re ready to commit new code, checking it in SonarQube is easy: right-click the project in the Project or Package Explorer and choose SonarQube > Analyze. By default, any new issues you’ve introduced will be marked as errors in the Problems tab, so you don’t have to go hunting for them; they jump out at you.
By the way, that behavior’s configurable, so if you want new issues demoted from errors to warnings (like some of my day job colleagues) it’s easy to do.IntelliJ
After you link your local project in IntelliJ with its SonarQube analog, lines with existing issues will be highlighted. You can mouse over the line or the corresponding right-margin marker to see the issues.
When you’re ready to check your code in, scanning it for new issues has a few more steps than in Eclipse, but still isn’t hard. Right-click on the project, choose Analyze > Run Inspection by Name…, search for SonarQube Issues in the dialog, and run the analysis on the whole project (in the next dialog).
An Inspection Results section is added to the window, and new issues are marked as such.
The third way to perform a pre-commit analysis is to use the Issues Report plugin. It installs directly into SonarQube. Once it’s in place, you’re still not quite done; you’ll need to install SonarQube Runner locally. Don’t worry about configuring the connection to your SonarQube database, like the installation instructions call for. For the analysis you’ll be doing, you only need to specify sonar.host.url.
Then you need to set up a sonar-project.properties file in your project root if you don’t already have one. Make sure it includes the property sonar.analysis.mode=incremental. That’s what narrows your pre-commit check to only the files you’ve changed and prevents SonarQube Runner from trying to commit the results to the database.
Before you fire your first analysis, there are a few more options to consider. The Issues Report plugin has a couple of configuragions that can be turned on at either the global level or the individual analysis level: sonar.issuesReport.console.enable, and sonar.issuesReport.html.enable. By default both are set to false. As you might guess, sonar.issuesReport.console.enable enables summary reporting in the analysis console. Here’s what it looks like:
You can use the console report to see if you need to look at the HTML report. (That’s assuming you set sonar.issuesReport.html.enable=true. Otherwise all you got was .sonar/sonar-report.json.) Two versions of the HTML report are automatically created, issues-report.html and issues-report-light.html. By default, they land in .sonar/issues-report, but that’s configurable. The difference between them is that the light version only shows new issues. The “heavy” version contains all issues, but defaults to showing new issues only:
So that’s it. Now, no matter what your language, no matter what your IDE, you too can run a pre-commit check. Happy coding!
Here’s a recap from the latest Selenium Hangout panel discussion. To submit questions for future hangouts, you can message us on Twitter (@seleniumhangout) or e-mail us (firstname.lastname@example.org).
1:30-16:51: How to handle screenshots across different drivers
tl;dr driver specific issues due to a lacking standard and missing API
- This is getting addressed in World Wide Web Consortium (W3C) spec which is under development
- E-mail use-cases you would like to see in the spec to email@example.com
17:30-22:40 : Internet Explorer (IE) 9 pitfalls and how to avoid them
tl;dr use 32-bit IE (if you’re not) and report issues to Selenium Issues
22:50-28:30 How do you do image and video comparison testing?
tl;dr straight image comparison is a flawed strategy, but there’s a better way — also, Selenium’s not the best tool for the job
- Kevin Menard’s GTAC talk
- Michael Tamm’s GTAC video
- Image capture library from Mozilla (the library and a blog post about it)
28:58-38:15 How do you get started with Selenium?
tl;dr pick a language you feel comfortable with, choose an editor that makes you productive, and dig into the available resources
- Selenium 2 Testing Tools (David Burns’ book)
- The Selenium Guidebook (Dave Haeffner’s new book)
- Free, weekly tip newsletter on how to use Selenium (also by Dave Haeffner)
- Selenium HQ
- Selenium Users Group
- Selenium IRC chat channel (here’s a write-up on what it is and how to access it)
38:23-42:50 Selenium 3 Update
tl;dr still a work in progress, steadily moving forward, a big update will likely be required
43:15-44:00 Conference Update
tl;dr nothing finalized, hoping to do it internationally, but US is a fallback; still working on options (will know soon)
44:10-45:20 Mobile Changes to the Selenium project
tl;dr Android and iPhone Selenium drivers deprecated in favor of other compatible libraries
45:20-47:30 New Mobile Selenium Drivers
tl;dr RIM (BlackBerry Smartphones) and Microsoft (Windows phones)
I recently wrote a post listing what was accomplished in the SonarQube platform last year. Today, I’ll continue with even more exciting stuff: what we’ll do this year! I’ll share: what the main innovations will be, how the ecosystem will evolve, and what technical challenges we’ll face.
I’ll start with the highest voted request in the SonarQube Jira, which is only six months younger than SonarSource itself:Support of multi-languages projects
We have a number of features in mind when we talk about the Cartography domain, but in 2014 the first two features we provide will be:
- Cross-Source navigation: the ability to click on any type, method call, variable, … to quickly switch to its definition
- References: the ability to track all uses of a type, method class, variable, … in the overall project portfolio
With those two features in place, we really hope to make code navigation as fluent as in any IDE, making SonarQube one of the best places to browse the source code. An extra effort will be required on each language plugin to feed the SonarQube platform with the necessary dependency information, and we’ll initiate the effort with the Java and COBOL plugins.Tags everywhere
With the integration of ElasticSearch, which started in SonarQube 4.1, the goal is to make it possible to tag rules and issues to cover two distinct and valuable use cases:
- Rule tagging will make it possible for any user to efficiently navigate through the list of available rules to find rules relating to security, complexity, documentation, unit tests, … making it much easier to determine which rules would make sense in a particular context.
- Issue tagging will make it possible to efficiently classify and retrieve technical debt instead of having to use action plans, which aren’t suitable for this kind of task.
Java SE 8 is expected to be released in March, so the goal is to make the SonarQube Java Ecosystem support this new version and all related new language features as soon as possible. We’ll also work to provide some new quality rules relating to use of lambdas.Full rewrite of the ABAP and PHP plugins
In 2013, we invested a lot of energy in the our C/C++ parser to make it support all C/C++ language ambiguities by using a cutting-edge GLL parsing approach. In 2014, we have two main goals for the C/C++ plugin: greatly increase the number of rules available out of the box, and make the configuration of C/C++ analysis as simple as possible. We’ll do that by automatically extracting configuration information from the Visual C++ solution when there is one. When there’s not, we’ll hook a proxy into the compile process to “eavesdrop” on the preprocessor and get all the details needed to build – and analyze – a project, such as macro definitions, the order to import header files in, and so on.RPG
This legacy IBM language will join the list of languages supported by the SonarQube ecosystem.
See you in 1 year for the “Looking Back at 2014 Sonar Platform Accomplishments”!
SonarSource is celebrating! The last few months have seen some significant milestones for the company. The biggest is that we’re 5 years in now, and still growing.
In November, we celebrated the company’s 5th anniversary, with a fabulous afternoon and evening in Annecy. It started with a super hero-themed trivia game. Here you see Team Iron Man (Simon Brandhof and Olivier Gaudin) competing against Team Wonder Woman (Vanessa Briens and Christelle Farez) and Team Captain America (Eli Goodrich and me): .
After the game, we had a guided boat tour of the lake. SonarSources’s founders, Freddy Mallet, Olivier Gaudin, and Simon Brandhof were proud to fly the 5th Anniversary flag:
After the boat tour, the evening continued with a presentation on the history of SonarSource, which ended by highlighting each person’s unique contributions to the team and our “hire order” with the company. I’m employee #20, and I’ve got the t-shirt to prove it! Stas Vilchik, at the time our newest developer, wasn’t able to be with us that day. But our new Customer Support Manager, José Gomez, was there, and he was delightful company at dinner.
At a time when many companies floundered, SonarSource has flourished in the last five years. We’ve grown in that period from the three founders to a lively team of 25. Most recently, we’ve grown in the areas of customer support, development, and sales, but we’re not done yet. We’ll be adding more folks soon in development and infrastructure.
And here’s the best news yet: we’re still hiring.
FOSDEM is probably the biggest open-source developers' conference in Europe.
This year will be the 3rd year for us to be present in FOSDEM. There will be a bunch of community people, handing out flyers and stickers, showing Jenkins, and generally be available to talk to people! This year, we'll bring some Jenkins T-shirts to sell, and hopefully some bobble heads as well. So please be sure to drop by.
And if you are already involved in the Jenkins project and willing to help us man the booth, that'd be awesome! Looking forward to seeing you!
A new year provides a good opportunity to look back at what was achieved the previous year. I’ll do that for the SonarQube platform in this post.
Let’s start with a summary of this retrospective. Last year:
- the platform was renamed into SonarQube
- 5 releases of SonarQube platform
- 130 releases of ecosystem products
- 75,000+ downloads of SonarQube
- 13,000+ messages on mailing lists
So I suppose we can call this a pretty active year for the community. Now, the longer version:The Plan
One year ago, we had the following ambitions :
To cover the Java language, we still rely a lot on Checkstyle and PMD. We want to migrate a substantial number of those rules onto our own technical stack (see SSLR). The objective for 2014 is to not rely anymore on Checkstyle and PMD to get full control of the stack and so to increase significantly the level of support we can provide: reduce the noise, ease migration on new java versions,…
DONE, with SonarQube Java ecosystem 2.0. Moreover, the description of most Java rules have been significantly improved. Indeed the completeness of a rule description is as important as the quality of its implementation.
Make the Eclipse plugin support incremental analysis
DONE. Now only updated source files are analyzed locally, making the SonarQube plugin usable even with large projects.
Lines covered by one unit test, getting the answer to the following questions: How many and which unit tests are covering this line of code? How many and which lines of code are covered by this unit test ?
DONE. The feature is available for Java projects.
Merge the two close Violations and Reviews concepts into Issues
DONE, and it is now possible to search for issues across all projects and not just project by project.
C and C++ plugin take off
DONE. We still have a long journey ahead, but we’ve managed to greatly improve our parsing technology by supporting what makes C++ one of the most complex languages: ambiguities. From there, we still need to work hard to provide more and more C++ rules.
Cartography. Behind this word, we group many features based on the dependencies between methods, attributes, classes, files, modules, projects, teams, departments… Here are the first use cases that we’ll cover: impact analysis and cross-sources navigation.
This was one of our most ambitious objectives for last year, and we decided to postpone it because we didn’t have the right back-end technology to correctly support this kind of feature. That’s why we started embedding ElasticSearch in SonarQube 4.1, and we are relying more on more on this NOSQL backend.
Ability to track and review new code
We also postponed this for a functional reason: it isn’t hard to extend the SonarQube platform to provide a post-commit code review tool, but providing a pre-commit code review mode and the ability to fully support branches is another story. Eventually, we want to provide a complete code review system, but before we start investing in code review features, we want to be able to sustain the effort in the long term, and that’s not yet the case.Beyond the plan
As mentioned above, we have invested heavily in rule descriptions for all language plugins to standardize their format and to make them as meaningful as possible. This effort started 6 months ago and we will sustain it throughout the development of the platform. Any feedback is of course welcome to keep on improving current rule descriptions.
See this recent blog entry to know more about this feature Analysis vs. Preview vs. Incremental Preview in SonarQube
SQALE available out-the-box
See this recent blog entry to know more about this feature SQALE models – more than just tiny cities*
IntelliJ IDEA plugin
And last but not least, we’ve finally decided to develop a SonarQube IntelliJ plugin to finally support the most popular Java IDE.
So after all this, what could be the exciting challenges for 2014? That will be the subject of my next post!