Hussain is writing about his experience building an awesome timeline mash-up. His app pulls out events from Google Calendars and issues from codeBeamer’s super-elastic trackers, and visualizes them along a SIMILE timeline. What makes it even more interesting from technical perspective is the mix of technologies involved: .NET in the serverside, heavy javascript magic in the clientside, Google Calendar running in the cloud, and codeBeamer running in a Java servlet container and exposing its .NET remote API. The right tool for the right job.
We are incredibly appreciative of the efforts you put into projects like this. We will be doing whatever we can to support them, and would love to see more. Do you have questions? Comments? Something to show for the codeBeamer community? Just tweet us at @intland, and we will get back to you immediately.
CodeBeamer Timeline Builder
(Please click the images for their high resolution versions.)Background
Project dashboarding – viewing the progress of a software development project from different viewpoints – has been an interest of mine ever since I started developing software. After one particularly difficult project involving issues with requirements, development and operations deployment and environmental difficulties, with no shortage of fingerpointing going on, I thought it would be good to step back and see the project from a linear timeline perspective and gain some objectivity. Additionally and especially for long running projects, viewing time linearly helps us as humans see the scope of events.
Simile Timeline + Google Calendar
I’d already had a calendar that was a great repository of significant events, which meetings I’d scheduled, etc. in Google Calendar. The data originally came from the corporate Outlook, synced up to Google Calendar with the Google Calendar Sync application. Using the Simile Timeline Javascript widget, I wrote a quick export from Google Calendar using the Google Calendar Data API to format the calendar events into the Simile Timeline json format. Since the events were hand coded Client Requirements (grey), Impediment (red) and Success (green), viewing the events linearly helped clear up the discussion around where the issues were in deploying the application. This quick web application was very well received and project managers in both development and operations, as well as other non-project related developers and managers, since they were able to see the timeline of events that occurred for this particular project. I hadn’t fully automated the import from Google Calendar to the Project Timeline page, and that’s what led to the next step.Dynamic Timeline Generation
The timeline view of the project was very useful and I thought it’d be a great perspective for other projects. Most of the projects at the organization use codeBeamer by Intland as an issue tracker and document repository. CodeBeamer has a much richer ability to code tasks / tracker items with statuses as well as start dates, end dates, and changed dates. Being able to dynamically pull project info via tracker lists and view them in a linear timeline looked to be a great start for a project dashboard.
The Timeline Builder was constructed with two picklists, one that displayed the lists of projects available and the second picklist that was contextual to the project’s actual tracker lists. The codeBeamer repository is organized such that every project has multiple “tracker lists” such as Business Requirements, Change Requests, Production Releases, and Defects. Project administrators can also add tracker lists as needed. When a project is selected from the first picklist, an AJAX call is made to the codeBeamer services, returning the project-specific tracker lists. When a user selects a tracker list, the application issues an AJAX query and retrieves the list of tracker events and then displays them as a timeline. The timeline has three horizontally scrollable bands: a weekly view, a monthly view and a yearly view. Each of them can be dragged left or right and the display of events will be synchronized. The display is “coded” by status: tems with a status of “closed” are represented as a solid blue ribbon, individual events have a circle icon, “in progress” events are a slightly transparent blue ribbon, “open” items are represented by a slightly transparent red ribbon with a solid red circle icon. Selecting a timeline event yields a link to the original codeBeamer tracker item as well as a short description along with the open and closed/last updated information. Below the timeline is a tabular representation of all the event data.
Technology Decisions
The organization uses .NET predominantly so I decided on using WCF and the codeBeamer .NET SDK to serve up the Simile Timeline JSON and ASP.NET (without WebForms) and jQuery to make AJAX requests to the WCF codeBeamer services. Additionally, the organization is standardized on Windows 2003 and IIS6, so I passed on using ASP.NET MVC on IIS6. Each codeBeamer project can have multiple task trackers (“tracker lists”), so there were three total JSON services: GetAllProjects, GetTrackerListsForProject, and the last, GetTimelineForTrackerList, which retrieved all tracker items for a particular tracker list as Simile JSON events. Additionally, I used two jQuery plugins – jTemplates to populate portions of the page, and flexigrid to show the same events in a table below the timeline.Findings and Stumblings
Looking at the variety of projects that we have in a linear format brought some interesting insights, the first of which is that almost no two projects use Tracker lists the same way. Not every project uses codeBeamer the same way, even though we have default tracker lists for Business Requirements, Change Requests, Production Releases, and Defects. Not every Task Lead uses the default statuses the same way – some close all tracker items only when a project has deployed, and create a separate status – “development complete” – for developers to use. Tracker items stay open throughout the iteration. For long-running, multi-year projects, cyclicality was shown quite well in a linear timeline – periods of project activity were clearly mapped to variety of business cycles.With the differences in usage of codeBeamer trackers, the high level of ability to customize tracker item templates, and the variability in conforming to the SDLC in the organization, comparing project-to-project is difficult in general, not just with a linear timeline.
The decision to use .NET WCF and a jQuery-driven front-end separated the codeBeamer Tracker List JSON generation service from the UI application, creating two projects which may or may not have been a good idea – although service-oriented, it’s two distinct codebases to maintain. Another interesting challenge was the codeBeamer API documentation for .NET – there isn’t really any, for either Hessian C# or the codeBeamer Remote API. Using Reflector and referring to the codeBeamer Java SDK Javadocs did help, but a Sandcastle generated documentation set would’ve been useful. Thankfully, the Java and .NET API’s are extremely similar, so it wasn’t a problem interpreting what should’ve happened.
Project Next Steps / Directions
For the current iteration of this timeline builder I have a few minor technical issues I’d like to address. I’m planning on having better integration between the flexigrid table of events and the simile timeline so that when you select an item from the table, it scrolls the timeline to the relevant event. Another enhancement would be to allow stacking timelines of multiple projects for juxtaposition.
I’d also like to expand the data feed to other task tracker applications. The organization also uses VersionOne‘s on-line agile project tracking application which has similar data to codeBeamer. A future revision to this application may include pulling from VersionOne project data dynamically in a similar manner (choose a project, see a timeline). Similar “coding” issues occur with VersionOne as with codeBeamer use, but since VersionOne is more focused on an agile project management lifecycle, I expect representing the variety of task types to be somewhat easier. An initial version is pictured below (using jstree to visualize the project hierarchy, at the left). Coding (designating the display of open, closed, in progress, etc.) is a bigger issue, and relates more to the choice of software project management structure – agile, etc. – but is something that’s greatly needed to get a consistent level of display. Other project tracking software, which I’m familiar with from a user standpoint, that may be usable include Redmine and Assembla/Trac.
From the technical framework, I may experiment with ASP.NET MVC next (which would remove the need for a separate WCF project) and then GWT (with the codeBeamer Java SDK) to see which one is more code-efficient.
Thanks for reading this writeup!
G. Hussain Chinoy
hussain.chinoy @ bespokesystems
