When managers are deciding how to allocate funds and resources on a project, their first request is usually for metrics. With so much data floating around, the message may end up lost, or worse, misinterpreted.
Tools such as SonarQube and Jenkins do display such information, but in a way that is often too detailed or project specific. High level trends are difficult to pick out across projects when parsing data such as lines of code, technical debt, and individual security findings. SonarQube can display these characteristics, but not easily in a good visualized manner. There is a gap for a tool that pools together findings to represent the overarching projects.
Enter Dashing: a widget based custom toolset built on Ruby. It provides built-in widgets to show graphs, lists, and meters, to name a few. These can be queried to provide updates to data in real-time. The example on the homepage (http://dashingdemo.herokuapp.com/sample) provides a great visualization of the default widgets that update every few seconds. There is also an open source community to provide more functionality through plugins.
Databases and Dashing
Databases can be queried and used to feed the widgets. Unfortunately, the readme and user manual for Dashing is limited. You will need to review each widget’s readme on github, along with all of the forum posts included to identify how to properly use the tool. Even then, many solutions are not intuitive.
How to display data from a sql call as a graph with multiple sets is, at best, documented only in parts.
In a nutshell, an array of points must be constructed for each intended graph within the series. A database connection client must also be established using the username, password, port, and target database. Then the sql statement is to be executed and pulled into the results. Here is a basic code template to solve the problem:
arrayofpoints1 = []
arrayofpoints2 = []
SCHEDULER.every ‘1m’, :first_in => 0 do |job|
setup db_connection
sql_statement1 = (SELECT tests AS testresults FROM testresultstable WHERE status EQUALS success)
pass_results = db_connection.query(sql_statement1)
sql_statement2 = (SELECT tests AS testresults FROM testresultstable WHERE status EQUALS failure)
fail_results = db_connection.query(sql_statement2)
passing = pass_results.map do |row1|
failing = fail_results.map do |row2|
array1_y_values = row1[‘testresults’]
array2_y_values = row2[‘testresults’]
counter = 0
array1 << { x: counter, y: array1_y_values }
array2 << { x: counter, y: array2_y_values }
array1.shift
array2.shift
series = [
{
name: “Passing Tests”,
data: arrayofpoints1.last(counter)
},
{
name: “Failing Tests”,
data: arrayofpoints2.last(counter)
}
]
send_event(id, { series: series })
counter += 1
end
end
end
When properly used, Dashing helps inform management on a project’s status and allows them to make decisions to better guide teams. It illustrates a convenient link between quality and quantity. As the managers are better informed on the health of a project, future efforts can be dedicated to produce more reliable code. Where a spike in lines of code is created, a related spike will occur in number of issues. Managers may then want to allocate time to resolving the issues rather than continuing to meet deadlines with bug filled code.
