Scoreboard & QuickScore 2.3 Coming Soon

Scoreboard and QuickScore 2.3 are coming soon, and will have the following new features!

  • Dashboards: Ability to add a bubble link WOB for links to dashboards, briefing books, reports, and documents the same way you can add the bubble links for scorecard nodes in 2.1
  • Dashboards: Ability to show Action/Initiative Descriptions with the bubble link WOB.
  • Dashboards: Ability to add notes as a WOB from any scorecard node AND to update notes without leaving the dashboard (or slide if in a Briefing Book)
  • Dashboards: Ability to add notes as a WOB from any Action/Initiative AND to update notes without leaving the dashboard (or slide if in a Briefing Book)
  • Dashboards: Ability to embed any report from Report Writer or Chart from chart writer as a WOB
  • Dashboards: Dramatically improved export to PowerPoint, Office, PDF, Email functionality.
  • Dashboards: Visible PowerPoint frame border limit in edit mode to define the limits for good export to PowerPoint
  • KPI – Metrics Report on Scorecard Tab: option to include complete scorecard structure, ie parents and ancestors
  • Allow shiny images to be turned off
  • Alternative chart background colors that are less pastel
  • Show metrics in executive view
  • Ability to specify colors in chart writer
  • Preserve thresholds when changing scoring types
  • Export to Project
  • Relative dates for briefing book slides
  • Change password permission
  • Rename scorecard nodes and roots to scorecard objects and scorecard roots
  • Un-pixelate Admin | Images previews for IE7+
  • Incorporate unit types
  • Support SQL Server clusters and named instances
  • Add start and archive dates to scorecard nodes
  • Require explanation when over budget
  • Ability to send initiative emails from scorecard nodes
  • Ability to assign groups to a scorecard node

WOW! Multi-core processing a snap with Spring 3

For many years, processor speed was measured by the frequency of the processor (the number of MHz or GHz). As chip makers have squeezed more and more transistors into the same amount of space, physical limitations have prevented processors from running at faster frequencies. So, to keep creating gains in processor speed, chipmakers have increased the number of cores on the processor instead of raising the frequency. Additional cores allow the processor to do additional things at once. For example, if there are 4 cores that is theoretically 4 times more powerful than a processor with 1 core running at the same frequency.

In practice, most programmers are not used to supporting multiple processors, so the software they write can only take advantage of a single core. This means all that extra processing power sits idle. Fortunately, the Spring team, along with the rest of the Java community, has come up with a very elegant approach to supporting multiple processors.

Today for my R&D project, I changed our background score calculation process so that it can take advantage of more than one processor core. It only took a couple hours from the time I started reading the documentation to the time I had my code working. I couldn’t believe how easy it was! I will definitely keep an eye out for other places in our software that could take better advantage of multiple processing cores.

For the technical folks out there, here are the resources I used to get me up to speed so quickly. I used Spring’s @Async annotation, Java 5′s java.util.concurrent.Future class and Spring’s org.springframework.scheduling.annotation.AsyncResult.

SOAP Testing

Spider has done a significant amount of Web service extensions to our Scoreboard software throughout the past several years. Connect is a tool that uses these Web services to easily integrate data from existing sources into Scoreboard. I’ve personally found Web service technologies to be quite fascinatingly rewarding to work with.

What’s so different about Web service coding, however, as opposed to typical web application programming, is the way that you can make sure your code is working as expected.

When building a typical web application, you can write your code, deploy it, and view it through your web browser. When building any sort of SOA functionality though, all communication is done through code…not quite as “visual” (unless you’re also writing a bunch of extra logging code), and arguably a bit more difficult to debug.

I wanted a quick way to test out the Web services that Scoreboard was providing…similar to the way that you might use a SQL console to test out your queries before you throw them into your application.

Of course there are plenty of development tools out there that will explore a WSDL, tell you which endpoints are available, and help you to build clients and POJO’s to use those services…but I wanted something simpler.

I already knew exactly what my endpoints were, and what the SOAP messages should look like, it was just a matter of ensuring that they were working as expected. I wanted to send a simple SOAP message, and see what the response looked like before I started writing client code that would consume those services.

Perhaps I just didn’t look hard enough, but I couldn’t find any tools out there that were a simple “form” that I could throw a SOAP header, body, and URL into, and send them off for a response.

Thus, I built my own. It’s a pretty simple Java Swing application that runs completely independent of both Scoreboard and Connect. I’m looking forward to it relieving many headaches related to analyzing JDOM elements through my Eclipse debugger!

A sample SOAP request, retrieving data from Scoreboard

The source code, as well as an executable JAR file can be downloaded here.