Skip to content

Open Source

SonarLint 2.0 Is Now Available

Sonar - Wed, 05/25/2016 - 15:25

SonarLint is a pretty recent product that we released for the first time a few months ago for Eclipse, IntelliJ and Visual Studio. We have recently released the version 2.0 which brings the ability to connect SonarLint with a SonarQube server and was greatly expected by the community. I think the addition of this new feature is a good chance to recap SonarLint features. But before I do this, let me remind you of the SonarLint’s mission: to help developers spot as many coding issues as possible in their IDE, while they code. It has to be instant, integrated to the IDE, and valuable.

Since SonarLint 1.0, you can install the product from the market place for all 3 IDEs we currently support: Eclipse Marketplace, Jetbrains Plugin Repository or Visual Studio Gallery. Et voilà… You can continue your coding as usual and you will start seeing SonarLint issues reported as you type. If you open a file, it will get decorated immediately with issues.

You also benefit from a nice panel containing a list of issues that have been detected. Each issue comes with a short message and if that is not enough you can open a more detailed description of the problem, with code snippets and references to well known coding standards.

As I am sure you guessed already, all of this does not require any configuration. And this is actually the reason why version 2.0 was so expected: people who have defined their quality profile in SonarQube want to be able to use the same profile in SonarLint. This is the main feature provided by SonarLint 2.0.

In order to have SonarLint use the same quality profile as SonarQube you have to bind your project in your IDE to the remote project in SonarQube. This is done in two steps:

  • Configure a connection to your SonarQube server (URL + credentials)
  • Bind your project with the remote one

Et voilà… again… SonarLint will fetch configuration from the SonarQube server and use it when inspecting code.

That’s it for today!

Categories: Open Source

SonarQube 5.5 in Screenshots

Sonar - Thu, 05/19/2016 - 14:37

The team is proud to announce the release of 5.5, which features simplified concepts for easier triage and management of issues:

  • New SonarQube Quality Model
  • New Measures project page
  • Increased vertical scalability, performance, and stability

New SonarQube Quality Model

With 5.5 we’ve boiled quality down to its essentials to make it easier to understand and work with. Now there are Reliability Issues, Vulnerability Issues and Maintainability Issues. Or, in plainer talk: bugs, vulnerabilities, and code smells. By drawing bugs and vulnerabilities out of the mass of issues, any operational risks in your projects are highlighted for expedited handling.

You’ll see the change wherever there are issues and technichal debt, including the Rules and Issues domains:

We’ve also updated the default Quality Gate to match the importance of these newly isolated concepts:

New Measures project page

Also new in this version is a project-level Measures interface, which replaces the old metric drilldown. Click a metric from the project home page and you land at the new per-file metric value listing:

The Tree view offers a compact, per-directory aggregation, and the Treemap gives the familiar, colorful overview:

The metric domain page also offers a listing of metrics and project-level values, with a graphical presentation:

Increased vertical scalability, performance, and stability

The Compute Engine has been moved into a separate process, and the number of worker threads made configurable (SONARQUBE_HOME/conf/sonar.properties), so users will no longer have to deal with a sluggish interface when analysis reports are being processed, and the memory requirements for processing can be handled separately from those for the web application:

That’s All, Folks!

Time now to download the new version and try it out. But don’t forget to read the installation or upgrade guide first! Even if you’ve read it before, it may be worth taking another look at the upgrade guide; we changed it recently.

Categories: Open Source

What’s New in SonarEcosystem – April 2016

Sonar - Wed, 05/11/2016 - 10:52

SonarQube JavaScript 2.12 Released: symbolic execution and full support of @reactjs JSXhttps://t.co/yGPSamFqGH pic.twitter.com/JSEEhjfanC

— SonarQube (@SonarQube) April 21, 2016

SonarQube C/C++ 3.11 Released: with new path-sensitive data-flow analysis engine for C. See https://t.co/mycs42eEKJ pic.twitter.com/AMXks9OGwU

— SonarQube (@SonarQube) April 13, 2016

SonarQube Java 3.13 Released: 7 new rules and numerous improvements, see https://t.co/3bMZCU5Fi5 #java pic.twitter.com/EzeBuepZq4

— SonarQube (@SonarQube) April 13, 2016

New @SonarQube JavaScript rule just caught a bug in @Ionicframework https://t.co/FzRLcaaCkg pic.twitter.com/hsVdMfVzKM

— Elena Vilchik (@vilchik_elena) April 11, 2016

Categories: Open Source

SonarSource City Tour, We Are Coming Near You

Sonar - Wed, 04/27/2016 - 14:51

Since we love touring and meeting our community of users, we’re setting out on the road once again, this time to more cities than ever! Over the next 6 months you’ll be able to see us and ask any questions you have, in more than 10 cities in Europe and the US.

This year, we are very excited to return to the City Tour to share with you all the news around the SonarQube platform, and show you our latest product: SonarLint, which allows developers to track quality of their code in real time as they type it. Very powerful!

Here is what will be covered at each stop of the tour:

  • The Leak Approach: a new paradigm to manage Code Quality
  • SonarQube 5.x series in demo
  • SonarQube integration to Microsoft ALM
  • SonarLint, the missing piece of the puzzle
  • Customer feedback
  • Sonar Analyzers and well-established standards
  • Roadmap for the platform
  • Roadmap for Sonar Analyzers

It will also be a great opportunity to meet other SonarQube users to share tips and tricks and discuss your experiences with the platform.

Is there something you would like to know or ask us but haven’t had the opportunity to do so? Now’s your chance! Sign up for the free event in your preferred city, and we’ll see you soon!

Registrations are open on our website, so pick the city you want, fill the form and you’ll be all set.

Join the conversation by using #SSCT2016 in all your tweets about the events.

See you soon !

Categories: Open Source

The best bug tracker is no bug tracker

IceScrum - Tue, 04/19/2016 - 16:08
We are often told that iceScrum doesn’t do much to help manage bugs / defects, backed by the evidence that it doesn’t provide a separate bug system with its own workflow and that defects are seldom mentioned in the user interface. Actually, this doesn’t denote an absence of feature, it is a deliberate feature! Well,…
Categories: Open Source

SonarAnalyzer for Java: Tricky Bugs are Running Scared

Sonar - Wed, 04/13/2016 - 14:38

For the past year, the SonarSource team behind the SonarAnalyzer for Java has invested most of its time in developing a Symbolic Execution engine in order to find the kind of tricky bugs that are almost uncatchable by developers unaided.

The SonarAnalyzer for Java’s new symbolic execution engine allows it to statically trace all the execution paths in a piece of code. We’ll probably do a blog post in the near future to explain all the related concepts: Program Point, Program State, Symbolic Value, Control Flow Graph, Stack of Symbolic Values, Constraints on Symbolic Values, … but for the time being let’s just see the engine in action.

Example 1 is a null pointer dereference in the Apache Tika project. The nullability of an object is guessed here from a test done in the code.

Example 2 is also an NPE in the Apache Tika project. This time the nullability is due to a badly handled exception.

Example 3 is a useless condition in the Spark project.

Example 4 returns to Apache Tika with a suspect unreachable branch.

Based on those few examples I guess it’s pretty easy to understand how valuable it can be to quickly get this information early in the development lifecycle. So how can you benefit from the SonarAnalyzer for Java? Either by getting on-the-fly feedback directly in your favorite Java editor with SonarLint for Eclipse or SonarLint for IntelliJ, Or by integrating SonarQube analysis into your build process to continuously feed the SonarQube server.

Tricky bugs are running scared. The hunt is on!

Categories: Open Source

Stop planning; fix the leak!

Sonar - Wed, 04/06/2016 - 14:32

So there you are: you’ve finally decided to install the SonarQube platform and run a couple of analyses on your projects, but it unveiled so many issues that your team doesn’t know where to start. Don’t be tempted to start fixing issues here and there! It could be an endless effort, and you would quickly be depressed by the amount of work that remains. Instead, the first thing you should do is make sure your development team fixes the leak. Apply this principle from the very beginning, and it will ensure that your code is progressively cleaned up as you update and refactor over time. This new paradigm is so efficient at managing code quality that it just makes the traditional “remediation plan” approach obsolete. Actually, so obsolete that related features will disappear in SonarQube 5.5: action plans and the ability to link an issue to a third party task management system.

“Why the heck are you dropping useful features? Again!?…”

Well, we’ve tried to dogfood and really use those features at SonarSource ever since we introduced them – but never managed to. Maybe the most obvious reason we never used them is that far before conceptualizing the “Leak” paradigm, we were already fixing the leak thanks to appropriate Quality Gates set on every one of our projects. And while doing so, nobody was feeling the need to rely on action plans or JIRA to manage his/her issues.

There are actually other reasons why those features never got used. First, action plans live only in the SonarQube server, so they don’t appear in your favorite task management system. Because of that, chances are that you will eventually miss the related dead-lines. This is why you might be tempted to “link issues” to your task management system. But this “Link to” feature isn’t any better. Let’s say you’re using JIRA in your company. When you link an issue to JIRA, the SonarQube integration automatically creates a ticket for that issue. So if you want to keep track of 100 issues, you’ll end up with 100 JIRA tickets that aren’t really actionable (you just have a link back to SonarQube to identify every single issue) polluting your backlog. What’s even worse is that when an issue gets fixed in the code, it will be closed during the next SonarQube analysis, but the corresponding ticket in JIRA will remain open! Anyway, issues in the SonarQube server and tickets in JIRA just don’t have the same granularity.

“Still, there are cases when I really want to create a remediation plan. How can I do that?”

As discussed previously, you should really avoid defining a remediation plan, and take the opportunity instead to spend the energy on “fixing the leak” instead. Still, occasionally, you might be forced to do so. The main case we can think of is when you absolutely want to fix critical bugs or vulnerabilities found on legacy code that might really affect your business if they pop up in production. In that scenario, indeed you might want to create a dedicated remediation plan so that your development team gets rid of this operational risk.

The good thing is that SonarQube already has everything you need to clearly identify all those issues and plan a task to make sure they got fixed – whatever task management system you’re using:

  1. In the SonarQube UI:
    1. Start tagging issues you want to fix with a dedicated and specific tag, like “must-fix-for-v5.2″
    2. Create a public “issue filter” that displays only issues tagged with “must-fix-for-v5.2″
  2. In your task management system:
    1. Create a ticket in which you reference the URL of the issue filter
    2. Set a due date or a version
  3. You’re done! You have a remediation plan that you can manage like any other task and your team won’t forget to address those issues.

“I don’t need anything more then?”

Well, no. Defining remediation plans this way gives the best of both worlds: identifying issues to fix in the SonarQube UI, and planning the correspond effort in your own beloved task management system.

And once again, remember that if your team fixes the leak, chances are you will not need to create a remediation plan any longer. So yes, even if I’m the one who initially developed Action Plans and the “Link to” features a long time ago, I think it’s really time to say bye bye…

Categories: Open Source

Don’t Cross the Beams: Avoiding Interference Between Horizontal and Vertical Refactorings

JUnit Max - Kent Beck - Tue, 09/20/2011 - 03:32

As many of my pair programming partners could tell you, I have the annoying habit of saying “Stop thinking” during refactoring. I’ve always known this isn’t exactly what I meant, because I can’t mean it literally, but I’ve never had a better explanation of what I meant until now. So, apologies y’all, here’s what I wished I had said.

One of the challenges of refactoring is succession–how to slice the work of a refactoring into safe steps and how to order those steps. The two factors complicating succession in refactoring are efficiency and uncertainty. Working in safe steps it’s imperative to take those steps as quickly as possible to achieve overall efficiency. At the same time, refactorings are frequently uncertain–”I think I can move this field over there, but I’m not sure”–and going down a dead-end at high speed is not actually efficient.

Inexperienced responsive designers can get in a state where they try to move quickly on refactorings that are unlikely to work out, get burned, then move slowly and cautiously on refactorings that are sure to pay off. Sometimes they will make real progress, but go try a risky refactoring before reaching a stable-but-incomplete state. Thinking of refactorings as horizontal and vertical is a heuristic for turning this situation around–eliminating risk quickly and exploiting proven opportunities efficiently.

The other day I was in the middle of a big refactoring when I recognized the difference between horizontal and vertical refactorings and realized that the code we were working on would make a good example (good examples are by far the hardest part of explaining design). The code in question selected a subset of menu items for inclusion in a user interface. The original code was ten if statements in a row. Some of the conditions were similar, but none were identical. Our first step was to extract 10 Choice objects, each of which had an isValid method and a widget method.

before:

if (...choice 1 valid...) {
  add($widget1);
}
if (...choice 2 valid...) {
  add($widget2);
}
... 

after:

$choices = array(new Choice1(), new Choice2(), ...);
foreach ($choices as $each)
  if ($each->isValid())
    add($each->widget());

After we had done this, we noticed that the isValid methods had feature envy. Each of them extracted data from an A and a B and used that data to determine whether the choice would be added.

Choice pulls data from A and B

Choice1 isValid() {
  $data1 = $this->a->data1;
  $data2 = $this->a->data2;
  $data3 = $this->a->b->data3;
  $data4 = $this->a->b->data4;
  return ...some expression of data1-4...;
}

We wanted to move the logic to the data.

Choice calls A which calls B

Choice1 isValid() {
  return $this->a->isChoice1Valid();
}
A isChoice1Valid() {
  return ...some expression of data1-2 && $this-b->isChoice1Valid();
}
Succession

Which Choice should we work on first? Should we move logic to A first and then B, or B first and then A? How much do we work on one Choice before moving to the next? What about other refactoring opportunities we see as we go along? These are the kinds of succession questions that make refactoring an art.

Since we only suspected that it would be possible to move the isValid methods to A, it didn’t matter much which Choice we started with. The first question to answer was, “Can we move logic to A?” We picked Choice. The refactoring worked, so we had code that looked like:

Choice calls A which gets data from B

A isChoice1Valid() {
  $data3 = $this->b->data3;
  $data4 = $this->b->data4;
  return ...some expression of data1-4...;
}

Again we had a succession decision. Do we move part of the logic along to B or do we go on to the next Choice? I pushed for a change of direction, to go on to the next Choice. I had a couple of reasons:

  • The code was already clearly cleaner and I wanted to realize that value if possible by refactoring all of the Choices.
  • One of the other Choices might still be a problem, and the further we went with our current line of refactoring, the more time we would waste if we hit a dead end and had to backtrack.

The first refactoring (move a method to A) is a vertical refactoring. I think of it as moving a method or field up or down the call stack, hence the “vertical” tag. The phase of refactoring where we repeat our success with a bunch of siblings is horizontal, by contrast, because there is no clear ordering between, in our case, the different Choices.

Because we knew that moving the method into A could work, while we were refactoring the other Choices we paid attention to optimization. We tried to come up with creative ways to accomplish the same refactoring safely, but with fewer steps by composing various smaller refactorings in different ways. By putting our heads down and getting through the other nine Choices, we got them done quickly and validated that none of them contained hidden complexities that would invalidate our plan.

Doing the same thing ten times in a row is boring. Half way through my partner started getting good ideas about how to move some of the functionality to B. That’s when I told him to stop thinking. I don’t actually want him to stop thinking, I just wanted him to stay focused on what we were doing. There’s no sense pounding a piton in half way then stopping because you see where you want to pound the next one in.

As it turned out, by the time we were done moving logic to A, we were tired enough that resting was our most productive activity. However, we had code in a consistent state (all the implementations of isValid simply delegated to A) and we knew exactly what we wanted to do next.

Conclusion

Not all refactorings require horizontal phases. If you have one big ugly method, you create a Method Object for it, and break the method into tidy shiny pieces, you may be working vertically the whole time. However, when you have multiple callers to refactor or multiple implementors to refactor, it’s time to begin paying attention to going back and forth between vertical and horizontal, keeping the two separate, and staying aware of how deep to push the vertical refactorings.

Keeping an index card next to my computer helps me stay focused. When I see the opportunity for a vertical refactoring in the midst of a horizontal phase (or vice versa) I jot the idea down on the card and get back to what I was doing. This allows me to efficiently finish one job before moving onto the next, while at the same time not losing any good ideas. At its best, this process feels like meditation, where you stay aware of your breath and don’t get caught in the spiral of your own thoughts.

Categories: Open Source

My Ideal Job Description

JUnit Max - Kent Beck - Mon, 08/29/2011 - 21:30

September 2014

To Whom It May Concern,

I am writing this letter of recommendation on behalf of Kent Beck. He has been here for three years in a complicated role and we have been satisfied with his performance, so I will take a moment to describe what he has done and what he has done for us.

The basic constraint we faced three years ago was that exploding business opportunities demanded more engineering capacity than we could easily provide through hiring. We brought Kent on board with the premise that he would help our existing and new engineers be more effective as a team. He has enhanced our ability to grow and prosper while hiring at a sane pace.

Kent began by working on product features. This established credibility with the engineers and gave him a solid understanding of our codebase. He wasn’t able to work independently on our most complicated code, but he found small features that contributed and worked with teams on bigger features. He has continued working on features off and on the whole time he has been here.

Over time he shifted much of his programming to tool building. The tools he started have become an integral part of how we work. We also grew comfortable moving him to “hot spot” teams that had performance, reliability, or teamwork problems. He was generally successful at helping these teams get back on track.

At first we weren’t sure about his work-from-home policy. In the end it clearly kept him from getting as much done as he would have had he been on site every day, but it wasn’t an insurmountable problem. He visited HQ frequently enough to maintain key relationships and meet new engineers.

When he asked that research & publication on software design be part of his official duties, we were frankly skeptical. His research has turned into one of the most valuable of his activities. Our engineers have had early access to revolutionary design ideas and design-savvy recruits have been attracted by our public sponsorship of Kent’s blog, video series, and recently-published book. His research also drove much of the tool building I mentioned earlier.

Kent is not always the easiest employee to manage. His short attention span means that sometimes you will need to remind him to finish tasks. If he suddenly stops communicating, he has almost certainly gone down a rat hole and would benefit from a firm reminder to stay connected with the goals of the company. His compensation didn’t really fit into our existing structure, but he was flexible about making that part of the relationship work.

The biggest impact of Kent’s presence has been his personal relationships with individual engineers. Kent has spent thousands of hours pair programming remotely. Engineers he pairs with regularly show a marked improvement in programming skill, engineering intuition, and sometimes interpersonal skills. I am a good example. I came here full of ideas and energy but frustrated that no one would listen to me. From working with Kent I learned leadership skills, patience, and empathy, culminating in my recent promotion to director of development.

I understand Kent’s desire to move on, and I wish him well. If you are building an engineering culture focused on skill, responsibility and accountability, I recommend that you consider him for a position.

 

===============================================

I used the above as an exercise to help try to understand the connection between what I would like to do and what others might see as valuable. My needs are:

  • Predictability. After 15 years as a consultant, I am willing to trade some freedom for a more predictable employer and income. I don’t mind (actually I prefer) that the work itself be varied, but the stress of variability has been amplified by having two kids in college at the same time (& for several more years).
  • Belonging. I have really appreciated feeling part of a team for the last eight months & didn’t know how much I missed it as a consultant.
  • Purpose. I’ve been working since I was 18 to improve the work of programmers, but I also crave a larger sense of purpose. I’d like to be able to answer the question, “Improved programming toward what social goal?”
Categories: Open Source

Thu, 01/01/1970 - 02:00