A short time ago, in a galaxy not too far away, a group of talented but brash Developers were shockingly defeated by an enemy alliance forged from planets Tech Writing and Marketing. This epic battle came to be known throughout the universe as "FedEx IX". Soon afterwards, in a ruthless piece of propaganda, the Development empire's deputy overlord promised that the next FedEx would in turn be known as "The Developers Strike Back".

But first, the founders decided that we needed to shoot a prequel. This was to take place in a galaxy where gadgets ruled. Victory in "FedEx X - Attack of the Gadgets" would go to the developer(s) who showed the most useful (or creative) mastery of new gadget technologies. The development team in San Francisco prepared the battle ground with their work on gadgets and dashboards, then we unleashed the developers in Sydney for 24 hours of gadget building.

After an alarming opening skirmish in which the idea of a single-themed FedEx was likened to the constraints of haiku, and a few impromptu 17- (mostly) syllable poetic battle cries were heard, silence descended on the Corn Exchange as gadget ideas took shape. Many unflagging and courageous troops waged on through the evening, sustained only by their competitive instincts, V, and gourmet pizza. Some flanked out to protect the home front, while others remained locked in combat at the office.

At 2pm the next day a ceasefire was called, and the Atlassian squadrons gathered in the basement to report back to their rebel leaders. Tensions mounted during the presentations as we gasped and cheered at some inspiring demos, while willing on others as they fell casualty to some last-ditched iGoogle retaliatory strikes. Voting was held at 4pm (courtesy of a hastily whipped up founder-gadget) and finally the winners were announced.

In first place, with a nifty Server Resource Monitor gadget, was Erik van Zijst. Erik's gadget presents the resources of a server neatly graphed in real time for easy human consumption. It displays the current load in a real-time chart that is updated every second:

Below the CPU chart is a table that contains the entire process list of the server. This list is also updated every second and contains information such as the CPU usage, memory size and start time of each process. The table automatically sorts the process list on CPU usage and only displays the first 10 proceses. The most expensive process is always displayed first. And some very nice colour-gradient eye candy there Erik.

Tied for 2nd place were Don Brown's fancy plugin gadget and Jens Schumacher & Ryan Ackley's "Tickle Tickspot" gadget for easy timesheet recording. Don was so ecstatic that he took off to Thailand for 3 weeks before sending in his screenshots, but I can assure you it was awesome. Jens & Ryan shamelessly pursued the popular vote with their Tickle gadget, which automates the process of filling in many timesheets at once in our Tickspot time-tracking system.

The user selects the first day in the past that is yet to have a Tickspot entry. Clicking the Copy button will copy the previous day's entries to the currently selected date, and increment the date by 1 business day. It even takes weekends into account! The user can then just keep clicking Copy until all timesheets are complete. Of course, in some companies, there might be potential for abuse of this particular gadget, but that sort of thing wouldn't happen at Atlassian... right guys?

And in 4th place, earning an honoured newbie mention with his Staff Directory gadget, was Seb Ruiz. Seb wanted a better way of searching Atlassian's staff directory listing, and "writing a small gadget seemed like a great way to learn about the Confluence API as well as scratch an itch". To quickly find out what that person who keeps shredding you in inter-team code reviews actually looks like, just start typing in the gadget:

To read more about these and other gadget FedEx entries, including Geoff's "FishEye Smellometer", Kate's "Bamboo Builds O' Shame", Nick's "Go Go Clover Charts!" and Brendan's "Crucible Most Active", check out the full writeups here.

I could also make those FedEx X haiku entries available pending popular demand... mm... didn't really think so.

For Atlassian's 7th FedEx Day I implemented a Confluence macro that would defer rendering its body until the full page was received by the client. The body of the macro would then be sent back to Confluence for rendering via AJAX while the user was presented with a loading placeholder. As the rendering of the body occurs in the future with respect to the original page rendering pipeline, I called this functionality the Future Macro. It is ideally suited for rendering content that is retrieved from external sources where high latency can hold up the delivery of other content on the page.

After some further refinement during Atlassian's 20% time scheme, I am now pleased to announce that the Confluence Future Macro has been released as an open source plugin on the Atlassian Labs site.

It is currently in beta release and I welcome all feedback regarding its current operation and future improvements. Of course, as Atlassian has generously allowed me to release the source under the Apache 2 license, you are very much free to adjust it as you see fit!

We recently held Atlassian's ninth "FedEx" competition, and it's time to share the results with you.

FedEx is an Atlassian tradition that requires a little explanation: Every 3 months or so, we put aside our regular development work for a day and a half, and work on our own crazy ideas. At the end, everyone gets three minutes to present their project to the rest of the company, and we all vote to determine the winner of the prized FedEx trophy.

Why do we do this? We see a number of benefits: Firstly, it gives us an opportunity to get practical experience with emerging technologies, and to showcase their possibilities. Second, it lets us prototype ideas for new features, many of which make their way into our products. Last but not least, we do it because it's a lot of nerdy fun.

This time around, the FedEx trophy went to Ed Dawson, for his Atlassian-themed Flash game, "Atlassian Invaders", embedded within Confluence as an easter egg. While Ed's entry was a clear crowd favourite, and deserving of the trophy, his victory was something of an upset, given that Ed is a tech writer, rather than a developer. The gauntlet has been thrown, and it's up to Atlassian's developers to restore the trophy (and their pride) to its rightful location next FedEx.

You can enjoy the fruit of Ed's labour right here, in your browser. Move Charlie with your arrow keys, and shoot the oncoming work with your space bar.

In second place was Geoff Crain, from our Developer Tools team, with a new feature for Crucible that automatically suggests participants for code reviews, based on existing workload, and individuals' history of commits to the reviewed code. You can expect to see Geoff's "Suggested Reviewers" feature in an upcoming release of Crucible.


Third place was a tie between two entries: Mark Halvorson created a "Dogear" feature for Confluence, to help wiki users navigate long passages of deeply hyper-linked text.


Also in third place, were Edwin Wong and James Dumay. Working in partnership, they came up with a "Personal Builds" feature for Bamboo, to let individual developers test their changes in isolation from their team's builds.


You can read about many of the other entries, in the write-ups prepared by their developers.

That's FedEx 9 for you. Stay tuned for our next installment: FedEx 10... "The Developers Strike Back!"

Between the trials, tragedy and the triumph, the 8th instalment of Atlassian FedEx day came and went. 49 projects were submitted in the biggest and the best one yet! Projects spanned the entire gamut; from playing shiny new toys like Skitch, EC2, Groovy to parallelising Maven downloads and adding supportability to our products.

FedEx days have been a regular Atlassian event since 2005 and it's still going strong. What the hell is it? If you want to find out more, read Mike's inaugural blog about FedEx. For more information on FedEx 8 check out our page on Confluence

The Best

Tom Davies, formerly a Confluence developer and now a Cenquan, took out the coveted FedEx trophy with his NNTP Server for Confluence. Tom tried to solve the problem: "How do you keep up with recent changes from a Wiki without being overwhelmed, but without missing things you want to see?" He decided that RSS wasn't the way to go, and NNTP's threading (amongst other things) made it a winner. Tom's presentation also impressed the inner geek in all with hist cool retro newsreader.

"I'm shocked I made it through", Tom announced. "I put my win down to the quality quantity of jokes I made in my presentation - and people's reluctance to hand out back to back wins to Matt Ryall."

The winners of the previous two FedExes, Matt Ryall and Adrian Hempel, as well as the team of Per Fragemann and Chris Broadfoot also made it through to the finals.

Runner-up was Adrian's Elastic Bamboo that allows you run your distributed Bamboo agents in an Amazon Elastic Compute Cloud (EC2). He created EC2 images that let anyone instantly start up a Bamboo server and any number of Bamboo remote agents in the cloud. It also allows you to add or remove remote agents on the fly, utilising Amazon's (just about) boundless computing power by simply updating a text input field!

Matt Ryall has hit a winning formula on how to consistently make it to the final table of FedEx voting. His Expert Confluence console combined a nostalgic appeal to all those hours spent playing Doom, nice Web-2.0 transparency effects and even useful functionality! With his console, virtually all of Confluence's RPC methods can be simply accessed through a simple press of the tilde (~) key. Everything from basic search, simple go-to. It even has history for even easier usage.

Ever wanted to turn Confluence into Slashdot? Now you can with Chris Broadfoot's Confluence Karma! You can moderate a comment up or down, see a poster's overall Karma and all that jazz. Per joined forces with Chris to implement a comments slider. The "Sexy Slider" lets you hide and show comments based on the posting date, so you can quickly hide old or poorly moderated comments.

For more details on the finalists, check out their projects' Confluence pages.

1. Tom's NNTP Server
2. Adrian's Elastic Bamboo
3. Matt's Expert Confluence Console
4. Per & Chris's Sexy comment slider & Karma

The Rest

With some 49 FedEx projects submitted for FedEx 8, many cool projects missed out on the finals. You can see details of many of the projects on the FedEx 8 Confluence page.

My personal favourite project for the day was Chris Owen's Macro AOP plugin. This allowed you apply an aspect across all macros in a Confluence instance or space. For example, you can replace the entire content of a particular macro between 430pm and 500pm each day with just a single AOP expression. This was seriously evil.

Product installation was also in vogue with Brenden Bain, Samuel Le Berrigaud and Matt "Viking" Jensen all taking a dip. Brenden used apt-get, Sam attempted an Atlassian Uber-Installer and Matt Jensen wrote a GUI front end for the Atlassian Application Manager.

On the testing front Brendan Humphreys began working on "Quiver - a Mutation tester for Clover 2". The idea was to use Clover's per-test coverage data to find which classes were hit by a particular test, and vice-versa. You can then use this information to find the subset of tests that will exercise a given mutation. This avoids the need to rerun the entire test suite, giving you a much more efficient mutation testing framework.

Don Brown ventured into the world of Grails to write a server monitoring application. Co-Founder, Mike Cannon-Brookes revisited his love hate relationship with GWT for a cross application embedded chat client. Despite a lot of swearing early on, he did come out the other end glowing about GWT. Other interesting bits an pieces was Nick Pellow's Skitch slap application that allowed you to automatically upload Skitch images to JIRA. Pete Moore's project allowed you to open any file in FishEye using IntelliJ IDEA's Ctrl+Shift+N shortcut.

Chris Mountford, to much applause from Ian (JIRA support lead), made the "JIRA Modz Detector". This extension to JIRA allows our support engineers to identify any modified files / JARs in a JIRA instance immediately. Brad Baker also worked on a hodge podge of useful support & plugin resource improvements. On the resources front, you can now including minifiable web resources (so plugins can have minified CSS & Javascript files) as well as optionally include a JS file at the bottom of the page rather than the top of the page for performance reasons. For support, JIRA can now produce Apache CLF formatted logs.

Overall, another enjoyable day for the developers and congrats to all for delivering so many cool and useful projects!

Here at Atlassian we have just finished up our sixth edition of "Fedex Day". What is it?
For those who don't know, "Fedex Day" is Atlassian's irregular answer to Google 20% time: time set aside for developers to work on whatever they want with a skew towards our products. We tend to run "Fedex" with a fairly open format you can do whatever you want as long as you can somehow relate it to our products. We have expanded it such that we set aside 1 1/2 days for the developers to complete their ideas. We start after lunch on a Thursday and work until 4pm Friday when we present what we have to everyone. The goals of "Fedex" are: Foster creativity. Atlassian is good at hiring smart people and we'd be mad to keep all that brain-power locked up. Scratch itches. Every developer has something that bugs them about our products, or something they'd like to see them do. Spike. Often, radical ideas don't get traction because we don't understand how they'd work or what benefit they'd provide. Have fun. Institutions like Fedex make Atlassian a fun place to work. Being the competitive individuals we are we also have a trophy plus bragging rights for the winner.
The Results We are always growing here at Atlassian, this time around we had 32 separate projects compared with 12 from our first Fedex. Here are the highlights of what happened: The Winners
First Prize - JIRA Caller ID JIRA Caller ID developed by Adrian Hempel set out to use Caller ID information from an Asterisk based phone system to automatically retrieve the caller's information in JIRA. It turned out great, even including a call history embedded in JIRA where you could replay recorded calls.	Second Prize - Atlasbook Second prize went to Atlassian founder Mike Cannon Brookes with his "evil-twisted-modification of Facebook for Atlassian's developers", Atlasbook. What it does is aggregate action data from various different external servers and display a single chronological feed. What is more impressive is that "Cannon" wrote about 40 screens and did the whole thing in Groovy + Grails all in the Fedex timeframe.
Thrid Prize - Calling Bamboo Samuel Le Berrigaud made Bamboo build status information available over the phone. Using VXML or VoiceXML he added voice recognition so that one could say which project they would like to know the status of. The plugin would then read the builds status through the phone. Being a phone based plugin there is not much in the way of screenshots to show, but take my word for it, the demo was very cool.
JIRA Projects
JIRA JMX Andreas Knecht decided it would be good to monitor real-time what happens in any given JIRA instance. This includes any issue events (creation, comments, etc) that are taking place, as well as more detailed profiling information to identify slow sub-systems in JIRA. He did this using Spring JMX and the JManage console.	Visualizing JIRA Workflows For a while now Anton Mazkovoi has been attempting to use various tools to create a graphical (flowchart like) view of a JIRA Workflow. Workflows can get quite complicated in JIRA, and with a non-graphical representation of a workflow it is a bit confusing to see how an issue can move through the workflow. He finally stumbled upon Drag Node Chart from FusionCharts and came up with a pretty nice looking graph. The graphing tool is proprietary and we are looking into getting something like this into JIRA.
Add Users from URL for JIRA Dushan Hanuska modified JIRA to allow it to import users by reading microformatted user information from a given URL. If you want to quickly import a set of users into JIRA and you have their information already available with microformatted markup then this could be a huge time saver.	AJAX diffing saved filter portlet + Side dashboard At Atlassian we use JIRA for many things, one of them is doing support. Dylan Etkin was bothered that he constantly had to refresh his dashboard to see if there are any new issues "in-the-box" and he wanted to do support while keeping an eye on the "inbox". He created an AJAX updated version of the saved filter portlet which also shows a color-coded diff of the found results for each refresh. He then created a "right-hand" nav style view of the dashboard so you can work and keep a eye on your portlets. This should hopefully find its way into the JIRA Toolkit.
Long Running Tasks in JIRA Brad Baker tackled the fact that long running tasks in JIRA, such a migrating issues in workflows, do not display anything in the browser to indicate progress until the operation completes. He provided a bit of page to show tasks logs but then decided that a fully fledged Video Poker game in JavaScript to play while you wait would be cooler. So He wrote one.
Confluence Projects
Staff Directory using Simile Exhibit This was the inaugural entry from the Internal Systems team, being Ernest Wong and John Rotenstein. They used MIT Simile Exhibit technology to revamp our staff contact list which is kept in Confluence. They made the list searchable, pretty, they included a timeline for employees start dates and a Google map view of where each employee was from. It looked amazing.	Copy Space Plugin Published Don Willis spent Fedex finishing and publishing his project from last Fedex. The Copy Space Plugin copies an entire Confluence Space including its pages within a single Confluence instance. Sounds simple but Confluence doesn't let you do it out of the box. This is now available in confluence plugin repository.
Return to Castle Confluence Our Fedex V winner Nick Menere and Matt Jensen had a very ambitious plan in mind. This involved using the Confluence Remote API to analyze a Confluence instance to generate a series of rooms to give the user a fully immersive 3D interface to Confluence. What they ended up with was a single room, Confluence on the wall and an image download process collecting images from the Confluence dashboard history. There was some fun stuff added (a Tin Soldier, a V-can rocket launcher, and the pictured V-storm), as a "cheap effort to win more votes".	Confluence Profiler Per Fragemann ventured out to implement a simple AspectJ-based profiler for Confluence, which displays its results in a ordered table list through a configurable Macro. As shown his venture was a success.
Confluence ROX Soren Harner and Brett Jackson set out to create a Digg like capability for Confluence. There approach was base ranking top ROX pages based on a social network analysis. As happens sometimes on Fedex the project did not yield any demo-able results, but they are armed for next time.	One-Click Blog Publishing Don Brown as fully described here bridged the gap between Confluence blogging and blogging in Moveable Type. In his demo he published his developer blog from a local instance of Confluence running his plugin, it was quite impressive.
Bamboo/Crowd Projects
Visualisation for Bamboo Builds Brendan Humphreys wanted to implement a visualisation of build results as they came from his teams Bamboo server - something he could have running on a spare display for the team area. He also wanted a project that would give him an excuse to learn Quartz Composer. Overall he was pleased to get something working, but pretty disappointed with the general appearance of his screensaver. He'd have preferred spending more time polishing the look and feel of the composition rather than grappling with subtle timing issues and 3D transformations.	Crowd Auditing Justin Koke, a Crowd developer, decided to add something he really was missing in his product, placing auditing into Crowd. He introduced a plugin point to Crowd, similar to Confluence around Event Listeners, so now you can drop in a JAR file that has your defined listeners for given events. The ground work has been laid, the next step will be some 'portlet' style graphs for the Crowd Console.
FishEye Projects
FishEye TreeMap Visualization Conor MacNeill wanted to add treemap visualizations to FishEye. He used the jtreemap library available on sourceforge. An image map was generated to allow the user to navigate into the tree. The image map was constructed so that any click would take the user down one level in the tree but rendered tooltips related to 2 levels down in the treemap. This allowed users to hover over a hot spot within a container to find out what it may be. Leaf nodes would take the user back into FishEye's traditional browse mode.	Fisheye Plugin for Eclipse Michael Studman chose to write the beginnings of a plugin for Eclipse that would provide access to some rudimentary features of FishEye. He wanted to achieve this through integration with the widely used CVS/SVN plugins shipped by Eclipse and others. All features, besides CVS integration, were implemented. With just a few configuration settings users can now view basic FishEye information for their SVN project files and folders. We are looking at about 3 or 4 days of polishing to wipe out the NPEs and rough edges before we try to get this into the hands of our customers.
Clover Projects
Realtime Code Coverage Viewer Nick Pellow created a real time viewer of code coverage metrics. The idea behind this, apart from giving you something interesting to look at while your tests run, was to also reveal tests which take a long time to run but don't do much for your overall code coverage. Some problems were encountered and in the end it was no longer a real-time viewer, however it was displaying Code Coverage versus Time, and as Nick says, "admittedly I was trying to grab some cheap FedEx votes from people impressed by an animated line crawling up the screen".
Cross Product Projects
Scriptdiculous Chris Mountford added an extension to the cross-product plugin system to enable plugin developers to use a wide range of scripting languages to develop bona fide plugins for Atlassian products. He implemented one scripting bridge as a ModuleFactory, namely BsfModuleFactory. It integrates with Apache BSF (Bean Scripting Framework) which is a common abstraction over a number of scripting languages. In the end it was quite a success and he created a simple JavaScript based IssueTabPanel and two simple Groovy based JIRA portlets.	Picture Uploader Web Component Edwin Wong figured it would be great if users of Atlassian products could preview, crop, and resize their pictures before they are uploaded. The new picture uploader ended up as a basic two step wizard. Upload the picture, then you can crop a section of the picture, the user can use a draggable, resizable box to make their selection on the image that they just uploaded. This is done using YUI and Java AWT package's Graphics2D object which does the real work on the server. The next step after adding resize, of course, is to incorporate the uploader into Confluence, JIRA, and even Bamboo.
Conclusion If you made it this far, I have to say you are a real Champ. It feels like every "Fedex" day everyone really kicks it up a notch and we here at Atlassian can't wait until the next one.

The Problem

Many people have come to know and love JIRA as an issue tracker for software development projects. What many people don't realise is that JIRA, with its customisable workflows, is useful for any team that needs to track issues.

For example, within Atlassian, we use JIRA to:

• Track support requests from our customers;
• Track candidates in our recruitment process;
• Track the tasks and issues that arise in any significant project, such as our recent move, or our acquisition of Cenqua.

For last week's FedEx, Atlassian's semi-regular day and a half of (almost) unconstrained innovation, I saw an opportunity for a plug-in that I hope will make JIRA even more appealing for applications outside of JIRA's traditional domain.

The Idea

Even in the age of e-mail and the web, for many businesses, the telephone remains a primary means of contact with their customers. Many of these phone calls require some follow up action, others are enquiries about the status of an existing issue.

Why not improve JIRA's abilities as a tool for capturing and responding to telephone enquiries? Most calls include Caller ID, showing the called party the caller's telephone number. Why not use this information to automatically retrieve the caller's information in JIRA, saving time and frustration for both parties?

This is exactly what I set out to do.

The Delivery

JIRA Caller ID is a plug-in that integrates JIRA with an organisation's telephone system, to allow one-click navigation to a caller's issues, and more.

The plug-in places an "Identify Caller" icon in the toolbar that appears at the top of every JIRA page. When a JIRA user receives a phone call, they click the icon.

The first time a call is received from a particular number, the JIRA user sees the page depicted below. As you can see, JIRA has obtained the telephone number of the caller from the telephone system. From here, the JIRA user can look up the JIRA account of the caller, and associate it with the telephone number.

[Click to enlarge]

Thanks to the AJAX user picker that first appeared in JIRA 3.10, finding users is quick and easy. For more advanced search capabilities, you can open JIRA's full user picker window.

Once the association between user account and phone number is created, JIRA navigates to the caller's user profile. You can see the user's telephone number is stored as a property of the user profile, named "CALLERID".

[Click to enlarge]

This was as much as I'd hoped to deliver for my first FedEx, but I found myself with a couple of hours to spare. Treading very carefully (I'd heard battle stories from colleagues who'd broken their FedEx entries in the final frenzied rush to add just one more feature), I decided to add a call history feature, complete with recordings of answered calls:

[Click to enlarge]

Behind The Curtain

So how was it all done?

[By all means, skip this part unless you're interested in the technical nitty-gritty!]

First step was to set up a phone system to integrate with. Any business of a significant size uses a PABX to manage its telephone calls. Traditionally, these have been based on very expensive proprietary hardware and software. In recent years, the Asterisk project has gained a lot of attention as an attractive alternative. It's open-source, highly configurable and programmable, runs on a variety of inexpensive computing platforms, and integrates nicely with both traditional telephony hardware and lines, and the newer breed of VoIP devices and services. I downloaded and built Asterisk, and within 15 minutes had my own little telephone exchange running on my MacBook Pro.

Next step was to set up a telephone extension on my exchange. Luckily, Atlassian is already running a VoIP-based phone system (It's actually running on a commercial derivative of Asterisk), so I was able to borrow a spare VoIP handset. Configuring it was a simple matter of adding some account details to Asterisk's SIP protocol configuration file, and entering the same credentials on the handset. Once this was done, the handset registered with the server, and I was able to test my setup by dialling the various demonstration applications that come pre-configured with Asterisk.

What I needed next was a telephone number that could be used to dial in. I already had my telephone line at home integrated with an Asterisk server by means of a Digium TDM400P PCI card with an X100M FXO Module. It's configured to forward my calls to my SIP-enabled mobile phone, when it's in Wi-Fi coverage, to the softphone on my Mac Pro when I'm at work, or to Asterisk-hosted voicemail when I'm unavailable. After some minor reconfiguration, it was also forwarding my calls to my FedEx Asterisk server at Atlassian. This required changes in three places:

1. Adding account details for my FedEx server to my home server's IAX protocol configuration file, so that my FedEx server becomes a "peer" of my home server, able to accept calls from it;
2. Adding corresponding details, and an instruction to register with my home server, to my FedEx server's IAX configuration file. This makes my home server a "user" of my FedEx server, able to place calls to it;
3. Modifying the "dial plan", the logic that determines call routing, on my home server so that calls into my home phone are routed to the new "user" on the FedEx server. This is done by editing the extensions configuration file.

[Click to enlarge]

You may have noticed that I'm using two different protocols: SIP (Session Initiation Protocol) for signalling between Asterisk and the handset, but IAX (Inter-Asterisk eXchange protocol) between my two Asterisk servers. SIP is much more widely supported, and is the only protocol supported by the handset I was using. With a bit of work, I could have used SIP for both connections, but IAX has a couple of advantages that make it a much easier protocol to work with when firewalls are involved:

1. SIP includes IP addresses in the payload of its messages, not just the IP header. This means that if you're using NAT (Network Address Translation) to share one or more public Internet IP addresses between a group of hosts on a private network, your NAT implementation needs to be SIP-aware so that it can translate the addresses in both the header AND the payload. IAX does not include IP addresses in its payloads, so it doesn't suffer from this problem.
2. SIP only carries the signalling used to establish and control calls, and actually relies on other protocols, typically a combination of RTP (Real-time Transport Protocol) and RTCP (Real-time Transport Control Protocol), to carry the audio data. While SIP typically operates on a well-known port number (5060), RTP and RTCP typically use dynamically assigned port numbers. This makes getting SIP-based connections through NAT a real headache. IAX uses a single well-known port number (4569) for signalling and data, so it doesn't suffer from this problem.

Now that I was able to call my home number and have my FedEx extension ring, it was time to integrate Asterisk with JIRA.

JIRA plug-ins are simply JAR files containing an XML-based descriptor of the modules they contain, and Java classes and resources implementing the modules. The JIRA Caller ID plug-in includes the following modules:

Module	Description	JIRA Plug-in Module Type
Identify Caller Link	The telephone icon link that appears in the top of every JIRA page	web-item
Identify Caller Action	A WebWork action that is executed whenever the telephone icon is clicked	webwork1
Caller ID Service	A component that implements the business logic of retrieving the Caller ID, and managing its association with JIRA user accounts	component

Asterisk provides a few different integration points to choose from. I made use of the Asterisk Manager API, a socket-based interface that can be used to monitor and control activities on the Asterisk server. Integrating with this interface was easy, thanks to the open-source Asterisk-Java library.

With all this in place, the plug-in can query Asterisk for a summary of all active "channels". A typical call consists of two channels (or "legs"): A channel between the originator of the call and Asterisk, and another channel between Asterisk and the recipient of the call. From the summary, the plug-in can determine the Asterisk-assigned names of any channels currently established to the demonstration handset.

The next step is to obtain the Caller ID. Every channel managed by Asterisk has a set of associated variables, which contain all kinds of useful information. For example, there is a built-in variable, CALLERID(num), that contains the telephone number from the Caller ID on the channel. The catch, however, is that this is the number of the party directly connected to this channel, but we need the number of the party on the other channel in the call. This easiest way to do this is to add a step to Asterisk's dial plan to set a variable (_JIRA_CALLERID) on the inbound channel to the current Caller ID. Because the variable name starts with an underscore, Asterisk propagates it to the outbound channel when it is created. It is then available for the JIRA Caller ID to query, via the Asterisk Manager API.

Adding call recording was deceptively simple: It just took a couple of additional lines in the Asterisk dial-plan to generate a unique file name, make it available as a channel variable (so that the plug-in can query for it), and start recording the call.

Add a puff of smoke, a couple of strategically-placed mirrors, and there you have it: JIRA Caller ID, FedEx edition.

Where To From Here?

Now that the mad rush of FedEx is over, there's a bit of work to be done to make it production ready: Hard-coded values to be made configurable, edge cases to be handled (such as phone numbers shared by multiple users, and users with multiple phone numbers), security to be added, automated tests to be written, and chewing gum and sticky tape to be removed.

Once that's done, I'm keen to unleash it on support.atlassian.com, so that our legendary support team can put it to use (Donna, in our San Francisco support team, has already lodged a feature request!).

From there, I hope to package it as a plug-in, and make it available for download from our plug-in library. I'm also considering the possibility of providing an API for adding support for telephone systems other than Asterisk.

Conclusion

I'd like to say a quick thank you to a few of my colleagues: Cheers to Stephen on our UI team, for the cool little telephone icon he designed, and to our legendary SysAdmin, Steve, for lending me the VoIP handset. Thanks to the JIRA team for building such a great, flexible product to build upon. Finally, thanks to our management team for giving us the time to do FedEx, and to fellow developer Dylan for organising FedEx VI: It's one of the many things that makes Atlassian such an enjoyable and rewarding place to work.

If you've got a great idea for a plug-in for JIRA (or Confluence, or Bamboo, for that matter), check out the Atlassian Developer Network. Better yet, why not come and join us for FedEx VII?

An important lesson in software is to use it for what it does well, and don't try to force it into areas it isn't meant for. Blogging has become an important communication tool for many companies, both outside and inside the firewall. Confluence provides decent support for blogging, and a good match for behind-the-firewall internal blogs that need connectivity to core business systems rather than optimised public access. On the other hand, Confluence isn't as well suited to be a public blog, particularly one that receives a lot of traffic and malicious attention.

At Atlassian, we use Confluence very heavily for internal blogging. Every department, from engineering to sales, uses internal blogs to communicate with the company at large and document internal discussions and announcements. For our external blogs, however, we chose to use Movable Type, a popular and fully-featured blogging software by Six Apart. While clearly a case of the best tool for the job, having two blogging systems can be rather unwieldy, particularly when a rather insightful internal blog post is voted to be promoted to one of the external blogs.

Enter One-Click Blog Publishing

My FedEx day project was to create a Confluence plugin that provided a "Publish" button on top of each internal blog post, allowing the author to easily send the post to our external blog system. While not the most complicated FedEx project, I hope it will be one of the more useful ones by saving us time and ensuring our external blogs are kept up to date.

When the "Publish" button is pressed, this happens:

1. The destination blog and internal post id are sent to an action
2. The action gets the internal post and renders its contents
3. The action also retrieves any post attachments and publishes them as Movable Type resources using their MetaWeblog API
4. The rendered post is processed for link rewriting, using the new link URL's from the newly created Movable Type resources
5. The rendered post is sent as a draft to the Movable Type blog, again via their MetaWeblog API
6. Finally, the user is redirected to the "Edit Draft" page, so they can tweak the presentation and publish

While this plugin is meant to work with our Movable Type blog, any blogging system that supports the MetaWeblog API should be compatible.

What's Missing

In a nutshell, any pages for configuration. Before this went live, I would expect to see:

• A screen to add external blog servers
• A screen to allow users to map their account to their Movable Type account
• Content massaging to preserve the look and feel from the Confluence post

Conclusion

Within a company, this plugin can enable a very useful publishing workflow that gets other people involved in the blogging process. It lets blog authors construct a post and publish it internally, gathering feedback and making improvements as necessary. Since the internal post is also a wiki, multi-author collaboration now becomes easy and second-nature. Once the decision has been made to push the change public, this plugin makes the publishing step a one-click operation. No more emailing word documents around; no more copy/paste from system to system. Now even blogging can be collaborative.

So my last fedex day I started to stumble into the world of Firefox Plugin's, the result was a somewhat lame and only partially usable Bamboo plugin for Firefox. This time round I decided to have another crack at it, pick up from where I left off, and try to make this puppy shippable! So with my XUL utility belt and some JavaScript know how I got to work ...

Continue reading "Fedex V - Bamboo Firefox Plugin - Redux" »

For Fedex V I created a plugin that allows a Confluence space to be copied. This is partially in response to the existence of CONF-3191, but it's more because the workaround is horrible. Occasionally when I've been working in support, I've been asked about how to copy a space, and it always makes me cringe.

The plugin I wrote provides an extra link on the Space Admin screen:

The user submits the form, with the new space name and key, then waits while their space is copied. The new space provides a link back to the original in the Space Admin screen.

The plugin duplicates most of the space's attributes and content, including:

• the space description
• the space and team labels
• the labels on all the pages in the space
• the current versions of all pages, in their proper hierarchy
• the space permissions
• the page level restrictions on all pages
• the attachments on all pages
• the current theme, logo and colour scheme
• the page templates
• Optionally, all comments on all pages, leaving their authors and dates intact.
• Optionally, the author and editing time of all non-comment content in the copy, (otherwise the copier authoer and copy time is used).

Some of the space's features are not copied (for no better reason than my not having time to implement it on fedex day):

• News items (blogposts)
• Mail
• past versions of anything (eg page history is not copied)
• things I don't know about (eg if another plugin stores information about a space or its content somewhere, then that information is not copied. I didn't provide a means for other plugins to be aware of space copying either. Publishing an event would be a good start.)

The space copying could really do with a progress bar too.

For my Fedex Day project, I wrote an application to extract social interaction data from internal Atlassian blog posts and perform several types of Social Network Analysis. Social Network Analysis uses graph theory algorithms to study social relationships among individuals.

I compared the Atlassian blogging community to three other datasets, which can be downloaded for research: interactions among a group of 62 dolphins; social interactions in a Karate club at a US University; and co-appearances among characters in Victor Hugo's Les Miserables. I wrote the program for building the social network graph in Ruby, and I used the R Statistical System and the SNA package to do the social network analysis computations.

The social network graph for blog posts looks like this, where individuals are nodes in the graph and edges are interactions.

I calculated several social network analysis metrics: I calculated "betweenness", which identifies people who bridge various parts of the network; I calculated "closeness", which indicates the strength of someone's "grapevine", for being plugged into information; and I calculated "eigenvector centrality", which is often interpreted to indicated the "power" of a node in the network.

I found distribution of the "betweenness" scores most useful (i.e. discriminating) in comparing the Atlassian community with the other groups. The Atlassian "betweenness" scores were distributed like this:

At the end of the analysis, it was clear that the Atlassian blogging community resembled (you guessed it!) the dolphin community most closely. In the Atlassian and Dolphins graphs, different regions of the graph had many "bridges" between them. In the social network graphs for Les Miserables and the Karate Club, different regions of the graph depended on just a couple of people to "bridge" them. I interpret this as meaning that communication is less "siloed" for the Dolphins and for Atlassian.