Skip to content

Feed aggregator

Former Softie Patricia Walsh Sets a World Record for Blind Triathletes

J.D. Meier's Blog - Mon, 12/08/2014 - 18:20

I’m always of fan of hearing about how Softies change the world, inside and outside of Microsoft.

I was reading Blind Ambition: How to Envision Your Limitless Potential and Achieve the Success You Want by Patricia Walsh.  It’s an inspirational story, as well as an insightful read if you are looking for ways to up your game or get the edge in work and life.

I wrote a 10 Big Ideas from Blind Ambition to share some of the highlights from the book.

Walsh is a former Softie.  More than that, she has raced in marathons, ultra-marathons and IRONMAN triathlons.  In 2011, Walsh set a new world record for blind triathletes, shattering the previous male and female records by over 50 minutes.

Pretty impressive.

She left Microsoft to start her own business, pursuit her speaking career, and train as a world-class athlete.

She set a high-bar.

But she also set a great example.  Walsh wanted to help light the way for others to show them that they can be limitless if they set goals, put in the work, and don’t let fear or failures hold them back. 

And most importantly, don’t put limits on yourself, and don’t fall into the trap of the limits that others put on you.

Categories: Blogs

A Tech Lead Paradox: Technical Needs vs Business Needs - Mon, 12/08/2014 - 17:11

Agile Manifesto signatory Jim Highsmith talks about riding paradoxes in his approach to Adaptive Leadership.

A leader will find themselves choosing between two solutions or two situations that compete against each other. A leader successfully “rides the paradox” when they adopt an “AND” mindset, instead of an “OR” mindset. Instead of choosing one solution over another, they find a way to satisfy both situations, even though they contradict one another.

A common Tech Lead paradox is the case of Technical Needs versus Business Needs.

The case for Technical Needs

Before cloud services were available on the Internet, most companies would invest in hardware to run their services. The work to setup and configure machines was easier for non-technical stakeholders to see because of its physical aspect. Today software requires even more software and non-physical services that need configuring, testing and releasing. Much more of it is virtual.

Practices such as Continuous Delivery do not come without some overhead, although it provides an invaluable business capability. All of these “internally-facing” technical requirements demand time from the software delivery team.

The case for Business Needs

A lot of software is written for businesses, whose overall goal is to make money. A business that does not evolve their business offerings will lose out to competitors or to the ever-changing consumer marketplace. This means a business wants to always experiment with their existing services, or provide new services to keep their existing customer base, or to attract new customers.

This pressure to modify, or introduce new services demand either software support, or new software to be developed.

The conflict

A business will always put pressure on a development team to produce as much software as possible. At the same time, effective delivery of software is not possible without addressing some level of technical needs – such as technical debt, deployment pipelines, or automated test suites.

Time spent on technical needs is expected to improve developer effectiveness, but this is often hard to measure and prove to outside stakeholders. An endless amount of time can always be spent tweaking, optimising and improving technical infrastructure and tools. What starts off as “just an afternoon” turns into a week, or a month and business features are put on hold as a result. If this happens too long, the business might miss agreed external deadlines for certain features and thus lose customers, or money.

What does a Tech Lead do? Champion time for Technical Needs

A Tech Lead champions for time to spend on Technical Needs by being part of the prioritisation process. They ensure that enough work is delivered, or finds solutions to business problems that minimise the amount of software that needs writing. They ensure the team is not over-loaded with delivering new features and changes and finds small slices to work on technical needs that will provide a good benefit.

Explain the business benefit of each Technical Need

A team can spend an endless amount of time investigating, configuring and supporting their technical infrastructure. A Tech Lead will have support from non-technical stakeholders if they understand what benefits they bring. The successful Tech Lead can explain not just what the team is working on, but also why and who else benefits.

Some typical business benefits include: reducing the amount of repetitive work, improving the quality (by minimising the chance of human error), or to prove out a business opportunity.

The Tech Lead builds trust with non-technical people by highlighting benefits on Technical Needs and also demonstrating if they reach those benefits.

Work on high impact items first

A list of Technical Needs will often be endless, so a Tech Lead will work to prioritise the list, culling items that no longer make sense, or pulling work items forward that may have an immediate and significant effect.

Keep a balance

The Tech Lead is mindful that the team cannot work on Technical Needs alone, and watches to ensure a good balance is met.

Maximise the use of “quiet” periods

Sometimes a development team will outpace the ability for a business to prioritise, “What’s next?” You might recognise these periods when a Product Owner has met all their objectives, or they are working on clarifying the next set. The Tech Lead uses these “quiet periods” as an opportunity for their development team to work on infrastructure, or tasks that have always been deprioritised.

These are often good periods for a team to run a “Hack Day” or for the team to work on small ideas they have had themselves that provide a good benefit.

If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Categories: Blogs

XProgramming is Moving – Slowly - Mon, 12/08/2014 - 10:11

As you may have noticed in the “XProgNew” articles, I’m moving the XProgramming site from WordPress to a static site. The main reason for this is to get it under control for a few more years,and out from under the WordPress update cycle and the legacy WP scripting that makes it what it is.

I also own The plan is to move all the content from here to there, then to begin to redirect from here to there, and finally to point directly there.

This will happen incrementally, and this site will not disappear any time soon. New material is already appearing on, however.

We anticipate that existing article links from here will ultimately work there, at least if they work here now. There are, unfortunately, some things that have already been lost or mislaid over the years and versions of this site. Some of these articles will likely re-appear, since they’ll be in the WordPress export even if you can’t find a link to them.

Except for this one, which I’m sticking to the top of the page, new articles will appear on, and not here. I’ll be grateful if you’ll watch it for new material. There’s already an interesting series on the Diamond Problem (or Diamond Kata), and other articles as well.

The site is evolving in content and style, as we learn what works and what we like. It will benefit from your feedback via email and if you can begin to link to it, that will help as well.

Thanks … see you there as well as here!

Categories: Blogs

The End of Common-off-the-Shelf Software

Xebia Blog - Mon, 12/08/2014 - 09:12

Large Common-of-the-Shelf Software (COTS for short) packages are difficult to implement and integrate. Buying a large software package is not a good idea. Below I will explain how Agile methods and services on light weight containers will help implement minimal, focused solutions.

Given the standard [hardware | OS | app server | business logic | user interface] software stack, COTS packages include some of the app server, all of the business logic and the full user interface. Examples are packages for sales support, financial management or marketing. Large and unwieldy beasts that thrash around on your IT infrastructure, needing herds of specialists to keep them going and insist that you install Java 1.6 and Oracle 10 on Redhat 4.2, IE 8.0 and the biggest, meanest server money can buy.

It probably all started with honorable intentions: buy over reuse over build appears to make perfect sense if you don’t look too closely. I even agree, though we might disagree on one important aspect, and that would be scale.
In the old waterfall days we were used to writing an architecture and make an inventory of business needs. Because people quickly learned that they rarely get more than one opportunity to ask for what they needed, they tended to ask for a lot, cramming in as much features as they could think of. At some point in the decision process everyone realized they might as well buy something really versatile; a large software package that matches all requirements now and in the future.

All is well.

Until the next business need pops up and the same reasoning (fix all specs up front, one shot to get it right, might as well ask a little extra, won’t hurt) leads to another package that has some overlap with the first but not too much so that’s OK. Then the need arises to synchronize data (because of the slight overlap between the packages) and an ESB is implemented (because you might as well buy a software package right?).

Now there are two stovepipes in your landscape glued together with a SPOF and things are not well any more. Changing stuff means coordinating the effort of multiple teams. Testing and integrating becomes the task of a large team, no team has ‘works in production’ in their definition of done. Works on my machine is the best you may hope for and somebody else will fix all integration problems. Oh, and the people who use this software switch between badly designed screens running in a bunch of yesteryear’s browsers.

How can modern software development wisdom and architecture help?

Two trends allow us to avoid stovepipes connected by super glue: micro-services hosted on light weight containers and Agile methods.

Micro services on light weight containers like Docker or maybe Dropwizard or Spring Boot are the end of the application server that served us so well last decade. If you can scale your application by starting a new process on a fresh VM you don’t need complex software to share resources. That means you don’t really need a lot of infrastructure. You can deploy small components with negligible overhead. Key-value data stores allow you to relax constraints on data that where imposed by relational databases. A service might support two versions of an interface at the same time. Combined with REST, a DNS and a load balancer this is the end of ESBs.

Agile promotes stable teams and budgets that are allocated to a team instead of a project. This means we don’t really have to do budget calculations anymore. Because we can change direction every sprint there is no need to ask for the world like we did in the waterfall days. That implies that we should create the smallest thing that could possible solve the problem, instead of buying the biggest beast that will solve all our problems and some others we don’t even have.

This doesn’t mean we shouldn’t buy software anymore. What I would love to see happening is vendors focusing on small specialized components: a highly specialized service using state-of-the-art algorithms to assess credit risk or a component that knows all about registering and monitoring customer service calls. That would be awesome. But no user interface thanks, we’ll be happy to create that ourselves, grabbing the data with a HTTP call and present it exactly like its needed.

Categories: Companies

Start Slackin

Bobtuse Bobservations - Bob MacNeal - Mon, 12/08/2014 - 01:52
The infrastructure supporting the flow of communication has become an iteration zero concern. For software developers, a team chat application is becoming as fundamental as a GitHub...

Bobtuse can be wildly informative
Categories: Blogs

R: String to Date or NA

Mark Needham - Sun, 12/07/2014 - 21:29

I’ve been trying to clean up a CSV file which contains some rows with dates and some not – I only want to keep the cells which do have dates so I’ve been trying to work out how to do that.

My first thought was that I’d try and find a function which would convert the contents of the cell into a date if it was in date format and NA if not. I could then filter out the NA values using the function.

I started out with the as.Date function…

> as.Date("2014-01-01")
[1] "2014-01-01"
> as.Date("foo")
Error in charToDate(x) : 
  character string is not in a standard unambiguous format

…but that throws an error if we have a non date value so it’s not so useful in this case.

Instead we can make use of the strptime function which does exactly what we want:

> strptime("2014-01-01", "%Y-%m-%d")
[1] "2014-01-01 GMT"
> strptime("foo", "%Y-%m-%d")
[1] NA

We can then feed those values into

> strptime("2014-01-01", "%Y-%m-%d") %>%
> strptime("foo", "%Y-%m-%d") %>%
[1] TRUE

…and we have exactly the behaviour we were looking for.

Categories: Blogs

Pair Programming in Perspective

Bobtuse Bobservations - Bob MacNeal - Sun, 12/07/2014 - 20:12
Annual Mermaid Parade Coney Island, 2012 I offered my 2¢ on this question from another developer: Would you consider joining a company where pair programming is an essential part of software...

Bobtuse can be wildly informative
Categories: Blogs

Why do you pay people? No, really?

Manage Well - Tathagat Varma - Sun, 12/07/2014 - 19:18
I think the only reason why we (must) pay people is so they bring ideas to the workplace. New, big, fresh, stolen, borrowed, bold, controversial, unscientific, unproven, risky, weak, potential gamechangers, disruptor of status quo, creative, ridiculous, audacious (big hairy audacious is even better), slayer of mindless bureaucracy, harbingers of change...just about anything will do as long as they bring something to the workplace, as opposed to just being a plug-and-play part in the giant corporate machinery whose daily activities are pretty much pre-decided as per the giant process manual. Continue reading →
Categories: Blogs

Four things I learnt as a volunteer…

Manage Well - Tathagat Varma - Sun, 12/07/2014 - 19:13
I have been a passionate volunteer since last 20+ years. During this time, I have had wonderful opportunities of volunteering with global organizations such as IEEE, ACM, PMI and various Agile community groups like AgileIndia, while also had opportunities to volunteer with small, but not unimportant, causes, such as my apartment association and my community social. Why, I even volunteered to spend 16 months in icy continent of Antarctica — something no one in their right senses would ever do! (and here is the TEDx talk I delivered on it.) While some experiences lasted longer (and better) than others, all of them left me with invaluable learnings. In this blog post, I call out my favorite learnings: Continue reading →
Categories: Blogs

Week 1 of my Lean Consulting Startup

Manage Well - Tathagat Varma - Sun, 12/07/2014 - 19:07
TL;DR: I started my consulting startup earlier this week after seven years of groundwork in a Lean Startup fashion. Here's the story that led to week one. Continue reading →
Categories: Blogs

The problems with "large, complex projects" in the enterprise

What is a "large, complex project"?When someone says "large and complex" in an enterprise context, they're typically referring to a few attributes:
  • Multiple teams
  • Multiple components, including non-IT components
  • Multiple vendors
  • Distributed teams
  • Year plus timelines
These attributes lead to several problems...
"Large, complex projects" suffer from two particular problems1. Lack of alignmentIt is much more difficult to create and maintain aligned intent, which means it's more difficult to coordinate efforts to achieve any overall target outcome.
This becomes worse with some multi-year programs as the sheer length of time tends to lead to a lack of continuity of leadership and management.

2. OverconfidenceNovices in "large, complex projects" tend to be overconfident in the predictability of humans, technology and context, that is, in the comprehensibility of both the problem and solution.

This overconfidence leads to a specific questionable belief: If it works on paper, then it must work in practice, that is, documents are a reliable form of control.

This belief leads to a critical failure pattern with  "large, complex projects": Waiting until late in the life cycle to test the integration of systems, humans, and processes.

I see the overconfidence as partly coming from an assumption that they're dealing with a technical problem rather than a socio-technical problem (multiple teams, vendors, sites, business processes, etc.).

Another way of describing this is considering the difference between a "bicycle system" and a "frog system".  With a bicycle, if we break everything down into pieces, it can be assembled into a working result in a predictable manner.  We can't do the same with a frog.  "Large, complex" projects in the enterprise, with the multiple teams, vendors, sites, non-IT components, etc. are more like frogs than bicycles.

Next: Solutions for "large, complex projects" in the enterprise that don't work

Frog picture from
Categories: Blogs

Cocktail party facilitation

A common ground rule for facilitated group sessions is "one person speaks at a time".

The rationale is that it's easier to understand a single-threaded conversation, it addresses people being interrupted, etc.

I wonder if, at least in some cases, this rationale is flawed.

Single-threaded conversations are unnatural because they imposed a centralised structure.  How might a more natural, decentralised facilitation approach look?

What if your group session was facilitated like a cocktail party or other similar social gathering?

People would have conversations based on what they want to talk about with whom they want to talk to.  Some conversations would be more dynamic, even heated where others might be more relaxed.

There are some problems with this.  How would we collectively learn about what each group talked about?  What about people who don't feel comfortable participating?

Some kind report-out would seem reasonable.  I'm also sceptical that anyone uncomfortable participating would not also be uncomfortable in a "one person speaks" scenario.

Perhaps this all comes back to Open Space and World Cafe style approaches?

Categories: Blogs

New Case Study: SAFe and COTS at Royal Melbourne Institute of Technology

Agile Product Owner - Fri, 12/05/2014 - 23:50

RMIT UniversityOur colleague (and SPC) Em Campbell-Pretty from Context Matters has been supporting the Royal Melbourne Institute of Technology (aka RMIT University) with implementing SAFe on a large COTS implementation. A few weeks ago, Catherine Haugh (Release Train Engineer) and some of her team presented their success story at the ANZ Oracle Higher Education User Group conference. Knowing everyone likes a good case study, I asked them if I could share the presentation to add to our collection of SAFe case studies, and they agreed.

The presentation at HEUG outlined the journey of a new Agile Release Train (ART) at RMIT, Australia’s largest University, and the ways the ART supports the Student Administration value stream, which they call a StAART. The core Student Administration system is a COTS, specifically Oracle PeopleSoft. Also and FYI, this is the same ART references in Em Campbell-Pretty’s blog posts “Pitching the Pixar Pitch” and “The ART of the All-Hands Release Planning Meeting” from her blog, Pretty Agile: Adventures in Scaling Agile, so you can learn more about this project there.

All in all, it is a great presentation showing the benefits of scaling Lean and Agile practices in the realm of education administration. Thanks Em, for the contribution!

Read all about it here.

Stay SAFe,

Categories: Blogs

Agile Quick Links #27

Notes from a Tool User - Mark Levison - Fri, 12/05/2014 - 20:10
Links of interest to Agile and ScrumSome interesting reading for the Agile community:
Categories: Blogs

Why You’ll Want to Attend Humanizing Work 2015

Agile For All - Bob Hartman - Fri, 12/05/2014 - 18:48

Every year, we put on a conference just for agile practitioners who’ve been in one of our classes. Check out this 90 second video to see what makes the Humanizing Work Conference so special:

We hope you’ll join us at the next Humanizing Work Conference in July 2015. If you haven’t been in one of our classes yet, there are plenty of opportunities to attend a public CSM or CSPO, or contact us about a private Agile for Teams class for your organization.

Sign up for our conference newsletter to keep up with the latest news and to be notified when registration opens in January:

The post Why You’ll Want to Attend Humanizing Work 2015 appeared first on Agile For All.

Categories: Blogs

Whole Agile – Unleash People & Organizations

Agilitrix - Michael Sahota - Thu, 12/04/2014 - 20:27

Agile missing partsAgile is incomplete. We need to augment it to create the “whole product”. But what is it?

There are many ideas: transformation approach, culture, leadership, but something is still missing.



Whole Agile

Whole = Agile + People + OrganizationWhole Agile is a holistic way to see the functioning of the entire organization.

In order to fully unleash the potential of workers we need to augment Agile with Valuing People and rewire Organizational Governance.

Valuing People is about building a place where the whole person is welcome so they are fully engaged in work. A place where there is safety, trust and authentic connection.

Organizational Governance refers to the approaches we use to run organizations: organizational structure, planning & control, roles & titles, compensation, performance management, information access, leadership and power. These need to shift for us to reinvent our organizations to unleash people’s capabilities.

This is essentially what I have been doing the last few years. Now I have a good name for it. I will be writing more about Whole Agile in the coming weeks but in the meantime, here is a video summary and slides.

Video Summary


Whole Agile – Unleashing People & Organizations from Michael Sahota Why “Whole Agile”?

An obvious question is: Why do we need something more than Agile? Why make up a new name?

One answer is that Agile is great at a team level but provides no guidance at an organizational level. We need to replace burdensome organizational processes and with lightweight ones that foster self-organization and engagement.

The most important reason for selecting a name is that we want to create a movement within the Agile community. Not everyone will be interested in building whole organizations and that’s OK.

Here are some alternative names:

  • Holistic Agile
  • Conscious Agile
  • Evolve Agile
  • Beyond Agile
  • AgileAsItWasMeantToBe

Online survey results with comments on names. You can add to the survey as well.


First, I would like to thank my dear friend and colleague Olaf Lewitz who has been deeply involved in developing this. Other key contributors include: Melanie Meinen and Laura Powers. Thanks also to those who responded to my online survey: Clint, Jeff K, Fanny, Olivier Gourment, Shyam Kumar, Geir, Peter Trudelle, Frank Olsen, Alistair McKinnell, Justin Reyna.


The post Whole Agile – Unleash People & Organizations appeared first on Catalyst - Agile & Culture.

Related posts:

  1. People over Process – Win with People Success comes from Valuing People When we simplify the Agile...
  2. WholeHearted Manifesto: We Value People The WholeHearted Manifesto consists on one value statement: We Value...
  3. Letting Go of Agile (Culture) “If you want something very, very badly, let it go...

Related posts brought to you by Yet Another Related Posts Plugin.

Categories: Blogs

The Technical Debt Trap

Scrum Expert - Thu, 12/04/2014 - 19:06
Technical Debt has become an Agile catch-all phrase for any code that needs to be re-worked. Much like Refactoring has become a catch-all phrase for any activity that involves changing code. These fundamental misunderstandings and comfortable yet mis-applied metaphors have resulted in a plethora of poor decisions. What is technical debt? What is not technical debt? Why should we care? What is the cost of misunderstanding? What do we do about it? This presentation discusses the origins of the metaphor, what it means today, and how we properly identify and manage ...
Categories: Communities

7 Tips for Meetings That Don’t Suck

Rally Agile Blog - Thu, 12/04/2014 - 15:00

In his book, Tribal Leadership, Dave Logan suggests that every organization consists of “tribes” at different stages. At the lowest level is the tribe who thinks, “Life sucks.” From there it goes up to “My life sucks,” then “I’m great,” then “We’re great,” and finally to “Life’s great.”

(image: finding marbles)

Do Your Meetings Suck?

When it comes to your meetings, where are you and your tribe on this scale? If your answer is, “Meetings suck,” then sadly, you are not alone. What’s driving this negative meeting culture, and, how can we move to, “My meetings are great” or better still, “Our meetings are great.” (Note: “Life is great” may be beyond the scope of this post.)

The dilemma here lies in the fundamental fact that, as we scale our Agile adoptions, we have more meetings: whether ad-hoc, one-off, cross-functional, or on a regular cadence. And we have ever larger meetings. If we don’t address meeting dysfunctions, we have no chance of moving up to the stages with non-sucky meetings.

Top 10 Reasons Why Meetings Suck

Do your meetings suck? Why do you think that is?

I have the good fortune to talk with a lot of people about all sorts of meetings. And when it comes to the explanations I hear for why meetings suck, I think of a David Letterman-esque list. I’ll call it “Top 10 Reasons Why Meetings Suck”:

  1. No logistical preparation for the meeting (ensuring the right people are invited, the right room is set up, you have the right technology)
  2. Lack of clear purpose or agenda
  3. No actionable decisions or tracking of actions
  4. Discussions go down rat holes and never get back to the topic at hand
  5. Managers in a mode of telling versus engaging in the meeting
  6. No divergence of ideas
  7. Participants don’t feel heard, understood, or valued
  8. Bad behaviors dominate the meeting
  9. Lack of constructive conflict (it's either destructive or avoided)
  10. No neutral facilitator present to address Numbers 2 through 10
Fix Your Meetings Right Now

It really is possible to have meetings that don’t suck. As you scale your meeting size and frequency, you absolutely can move beyond the suck threshold. Here are seven tips to get you going.

  1. Timebox all your meetings and stick to the timebox.
  2. Don’t attend a meeting unless it has a well-articulated purpose and agenda.
  3. Plan out the overall flow of your meeting well in advance to ensure you have the right timebox and the right attendees.
  4. For large meetings, make sure you’re capturing all voices in the room by using small group, individual, or anonymous feedback techniques.
  5. Engage brainstorming practices to solicit a breadth of ideas, and use grouping and prioritizing techniques to converge on sustainable decisions.
  6. For long meetings, check-in regularly with yourself and with participants: Do we need a coffee break? How’s our energy? Is one person doing all the talking?
  7. Retrospect at the end of your meetings so you can continually improve on how you lead them.
Start off 2015 with Less Suckiness and More Greatness

Want to take this on? You have the power to facilitate collaborative meetings. The New Year is a great time to get started.

Join me January 21-22 for my Leading Collaborative Meetings training in Boulder, Colorado. With practice and perseverance, you can move the “Meetings suck” dial to “Our meetings are great.” And maybe, just maybe, that will lead to a “Life’s great” moment for you.

Jean Tabaka
Categories: Companies

New LTS Version Sums Impressive Array of New Features

Sonar - Thu, 12/04/2014 - 14:35

In November, SonarQube version 4.5.1 was announced as the new Long Term Support (LTS) release of the platform. It’s been nearly a year since the last LTS version was announced – a very busy, feature-packed year. Let’s take a look at the results.

Technical Debt moves into the core

If you’re upgrading directly from 3.7.4, the previous LTS, the change with the biggest impact is the addition of built-in support for Technical Debt calculation. The SonarQube platform is all about identifying and displaying technical debt, but previously there was no built-in way to calculate the cumulative amount.

Over the course of the last year, we’ve fixed that by moving the bulk of our SQALE implementation from the commercial SQALE plugin into the core platform. (Shameless plug: there’s still plenty of value left in the plugin.) Now you can see your technical debt in time (minutes, hours or days) without spending a penny. It’ll show up automatically in the re-vamped Issues and Technical Debt widget:

You can also see the technical debt ratio (time to fix the app versus an estimate of the time spent writing the current code base) and the SQALE rating. They show up in the Technical Debt Synopsis widget:

For more on Technical Debt, check out the docs.

Multi-language analysis debuts

This year also saw the fulfillment our most-requested feature ever: the ability to analyze a project for multiple languages. Now you can analyze all the Java, JavaScript, HTML, &etc. in your project with a single analysis, and see the consolidated results in SonarQube.

Note that if you previously relied on SonarQube’s default language setting (typically “Java”) rather than specifying sonar.language in the analysis properties, your first analysis after jumping to the new LTS will pick up more files than previously. Under multi-language, every language plugin that sees some of “its” files in your project will kick in automatically.

Rule management and Quality Gates emerge from the shadow of Profiles

Another paradigm shift this year, was the removal from Quality Profiles of Rule management and Quality Gates (previously known as Alerts). Now Quality Profiles are simply collections of rules, and Quality Gates and Rule management stand on their own.

Previously, if you wanted to apply the same standards to all projects across all languages, you had to set those standards up as Alerts in each and every single profile. I.E. you had to duplicate them. With the introduction of Quality Gates, those standards gain first-class citizenship and become applicable as a set across all projects.

Similarly, if you wanted to browse rules before, you could only do it in the context of a Quality Profile, and interacting with rules across multiple profiles was cumbersome at best. With the introduction of the Rules space, you can browse rules outside the context of a profile, and easily 1) see when a rule is active in multiple profiles, 2) activate or deactivate it in any profile in the instance. There are also impressive new search capabilities and a bevy of smaller, but nonetheless valuable, new features.

UI gains consistency

Several pages throughout the interface have been reworked to improve consistency and add functionality. The new Rules and Quality Gate spaces were implemented with an updated UI design, so the Measures and Issues pages have been updated as well to keep pace.

In addition, the component viewer has been completely re-imagined. Now it’s possible, for instance, to see the duplicated blocks and the issues in a file at the same time.

Widgets are added, updated

Several new widgets have been added for displaying Measure filters since the last LTS: donut chart (a pie with a hole in the middle ;-), bubble chart, and histogram. Word cloud has moved from a separate page to a reusable widget. And TreeMap has been completely rewritten to improve responsiveness and functionality.

Interactions outside the interface improve

The final two changes to mention are a little less showy, but no less important.

First, an incremental analysis mode has been added. It allows you to run a local analysis (the SonarQube database is not updated) on only the files that have changed locally since the last full analysis. With the two IDE plugins and the ability to run incremental analysis manually, there are three options for pre-commit analysis.

The last major change is the addition of built-in web service documentation. You’ll find the link in the SonarQube footer.

It leads to a listing of every web service available on the instance, with documentation for the methods, and in some cases a sample response. Never again will you wonder if you’re looking at the right version of the docs!

Coming up

It always seems a long time to me from release to release, but looking back, it has been an amazingly short time to have packed in so much new functionality. If you’re upgrading from the previous LTS, it’s definitely worth taking a look at the migration guide.

Coming up next, I’ll talk about SonarSource’s LTS philosophy – why we do it and what it means – and in another post I’ll talk about all the features planned for the next LTS.

Categories: Open Source

R: Applying a function to every row of a data frame

Mark Needham - Thu, 12/04/2014 - 08:31

In my continued exploration of London’s meetups I wanted to calculate the distance from meetup venues to a centre point in London.

I’ve created a gist containing the coordinates of some of the venues that host NoSQL meetups in London town if you want to follow along:

venues = read.csv("/tmp/venues.csv")
venues %>% head()
##                        venue      lat       lon
## 1              Skills Matter 51.52482 -0.099109
## 2                   Skinkers 51.50492 -0.083870
## 3          Theodore Bullfrog 51.50878 -0.123749
## 4 The Skills Matter eXchange 51.52452 -0.099231
## 5               The Guardian 51.53373 -0.122340
## 6            White Bear Yard 51.52227 -0.109804

Now to do the calculation. I’ve chosen the Centre Point building in Tottenham Court Road as our centre point. We can use the distHaversine function in the geosphere library allows us to do the calculation:

options("scipen"=100, "digits"=4)
centre = c(-0.129581, 51.516578)
aVenue = venues %>% slice(1)
##           venue   lat      lon
## 1 Skills Matter 51.52 -0.09911

Now we can calculate the distance from Skillsmatter to our centre point:

distHaversine(c(aVenue$lon, aVenue$lat), centre)
## [1] 2302

That works pretty well so now we want to apply it to every row in the venues data frame and add an extra column containing that value.

This was my first attempt…

venues %>% mutate(distHaversine(c(lon,lat),centre))
## Error in .pointsToMatrix(p1): Wrong length for a vector, should be 2

…which didn’t work quite as I’d imagined!

I eventually found my way to the by function which allows you to ‘apply a function to a data frame split by factors’. In this case I wouldn’t be grouping rows by a factor – I’d apply the function to each row separately.

I wired everything up like so:

distanceFromCentre = by(venues, 1:nrow(venues), function(row) { distHaversine(c(row$lon, row$lat), centre)  })
distanceFromCentre %>% head()
## 1:nrow(venues)
##      1      2      3      4      5      6 
## 2301.6 3422.6  957.5 2280.6 1974.1 1509.5

We can now add the distances to our venues data frame:

venuesWithCentre = venues %>% 
  mutate(distanceFromCentre = by(venues, 1:nrow(venues), function(row) { distHaversine(c(row$lon, row$lat), centre)  }))
venuesWithCentre %>% head()
##                        venue   lat      lon distanceFromCentre
## 1              Skills Matter 51.52 -0.09911             2301.6
## 2                   Skinkers 51.50 -0.08387             3422.6
## 3          Theodore Bullfrog 51.51 -0.12375              957.5
## 4 The Skills Matter eXchange 51.52 -0.09923             2280.6
## 5               The Guardian 51.53 -0.12234             1974.1
## 6            White Bear Yard 51.52 -0.10980             1509.5

Et voila!

Categories: Blogs

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.