Have you ever had a cracking idea? The sort of idea that just sits and simmers in your brain. Here at Atlassian, we have a team of awesome technical writers, full of ideas like these. However, keeping up with the dev teams and juggling documentation deadlines doesn't leave much time to try new things.

The solution? An innovation sprint!

An innovation sprint is a day set aside for the technical writers to explore new ideas related to the documentation. Giving everybody an outlet to explore these ideas is a win-win situation. As Thomas Edison once said, "To have a great idea, have a lot of them." We've implemented a number of ideas from past innovation sprints, such as flowcharts in key guides and Tips via Twitter pages.
 
 
How did it work?

A technical writer innovating looks surprisingly unassuming. You'd never know that they were turning brilliant ideas into awesome innovations. In fact, here are some examples of technical writers participating in an innovation sprint:

A few weeks ahead of time, we agreed to reserve the 20th of September for the innovation sprint. Closer to the date, we nominated the ideas that we'd be working on. These ideas were discussed at our team meeting just prior to the sprint for peer feedback.

During the day, each tech writer explored an idea that they had nominated at the previous team meeting. Some of us paired on a task, while others worked solo. Our team standup was cancelled and we only attended essential dev meetings.

We wore hats. We ate chocolate. We innovated.

 
 
What did we achieve?

We have a retrospective planned for our innovation sprint in two weeks time. However, the early results look promising. I've seen new conceptual diagrams, improved flowcharts, style investigations, scripts for finding broken links and conditional publishing prototypes. I'm sure that many of these ideas will find their way into our documentation.

Why hats? Everybody knows that a good hat is essential for innovation. Hats also help ward off pesky interruptions.
 
 
What could we have done better?

In hindsight, we should have dedicated more time to peer review of our ideas prior to the innovation sprint. Getting the perspective of other people can help you refine your idea earlier, making the sprint itself much more productive.
 
 
Guidelines for running your own innovation sprint

An innovation sprint doesn't require a lot of structure. However, it is important that everybody has a clear idea of what they want to work on. This prevents people from unknowingly working on the same idea or turning up on the day without anything to work on.

It's also helpful for participants to have as few interruptions as possible. A distraction can totally derail your train of thought. I posted an internal blog post a week ahead of time letting everyone in the company know that we would be unavailable on the day, except for urgent issues.

Finally, you want to make sure that your ideas are implemented. There's no point in dedicating a day to innovation when the results of everyone's work gets put on the backburner for the next year. Note, you don't want to deter people from aiming high and failing. However, participants should be planning out the next steps for their innovation work, regardless of how well the sprint went.

Best of luck running your own sprint!

It's been a while since the last update but I've finally gotten around to working a little more on my 20% project, the JIRA iPhone web-interface.

What is the iPhone web-interface? It's a plugins 2 plugin that can be deployed to a JIRA instance. Once deployed, any user accessing your JIRA instance will get redirected to a more iPhone friendly web-interface for JIRA. With the latest release (version 0.6) the following features are now available:

• Viewing Dashboards & Gadgets
• Creating Issues (limited to certain fields)
• Browse issues via favourite filters and JQL
• Viewing issues reported by you and assigned to you
• Adding comments to issues

Since the last release the UI's been completely re-written with jQTouch providing a much cleaner and faster UI. The plugin now works with JIRA 4.1 and it is now possible to create issues on the go (the most requested feature so far). Currently creating issues is limited to the following fields, but hopefully more will follow soon:

• Project
• Issue Type
• Summary
• Assignee
• Priority
• Description

So what's left on the roadmap? Adding more fields both to the view issue and create issue screens has the highest priority at the moment followed closely by edit issue functionality.

So feel free to give the plugin a go and leave any feedback on this blog or create reviews on the plugin's homepage.

At Atlassian, all developers end up doing a 2 week support rotation every now and then. It's a great opportunity to see first hand how all the buggy code I write as a developer ends up hurting customers and will hopefully provide an incentive to write less buggy code in the future ;). It is also a good time to come up with innovative little patches that help customers in the short-term, which can then be fed back into the product in the long run. This blog is about one such case.

During my last support stint one of our JIRA Studio support engineers brought a support case to my attention where customers where using the JIRA dashboard fairly heavily from iPhone and Android devices. Since their Studio instance got upgraded to JIRA 4.0, they could hardly use the dashboard anymore and apparently 2 gadgets were critical for their users in the field. The JIRA 4 dashboard includes a lot of javascript at the top of the page, and generates a lot of DOM elements dynamically with javascript. This generally isn't a problem on most modern browsers, but on a mobile device with limited CPU and memory it can make a website crawl.

Read on for a one file solution to this problem.

Continue reading "Help! The JIRA 4 dashboard is slow on a mobile device!" »

JIRA's UI on the iPhone (or any mobile device for that matter) leaves a lot to be desired. It's slow, shows too much information and is difficult to navigate on a screen that only supports a resolution of 320x480 pixels. There's already some native iPhone apps for JIRA available like iJIRA, JIRA Mate and JIRA Touch, however they require developers to go through app store approval first and users to install the apps manually on their iPhones.

With my last fedex day project, I created the JIRA iPhone Webclient as a proof of concept showing that it's possible to develop a web-interface for the iPhone that looks and feels almost like a native iPhone app.

Continue reading "JIRA iPhone Web Interface Plugin" »

In a previous post I described how Hamcrest can save your soul. After writing that, it was pointed out that you probably don't need to suffer so much boiler-plate to save your soul.

With that thought I set out to write the deeplyIsEqual matcher. The result is the DeepIsEqual Matcher. Using it is pretty easy. In that previous post I described the Matcher for comparing lightsabers, LightsaberIsEqual. We no longer need that. Now we can simply do

    assertThat(anakinsLightsaber, is(deeplyEqualTo(lukesFirstLightsaber));

No extra boilerplate is needed and we still get all the benefits of only seeing the fields that didn't match in the error messages. Oh, and the reported expected value is built using reflection too, so you don't need to worry about whether the type of objects you're comparing implement toString or how they implement it.

After going through the initial implementation I started switching over the OAuth tests to use this new matcher. Everything was going great until I hit a case where PublicKey or PrivateKey objects were being compared. The problem was, one was a generated key and the other was converted from an encoded string value. Apparently, depending on which way you create Key objects, the internal fields can be slightly different. So, comparing them recursively was failing. I struggled with what to do - I could add the Key to the internal, hardcoded types that are compared by simply using equals(), or I could add the ability for testers to specify how they wanted certain types to be compared using a MatcherFactory. This being 20% time and me seeing other places where specifying custom matchers for certain types would be very useful, I went with the second option.

So, if we wanted to match Hilts in a very specific way we could that pretty simply.

    public static Matcher<? super Lightsaber> equalTo(Lightsaber lightsaber)
    {
        return deeplyEqualTo(lightsaber, extraTypeMatchers);
    }

I wrapped the deeplyEqualTo call in a convience method, because the creation of the extraTypeMatchers can be a bit gnarly and makes the tests a bit harder to read. As a simple example, let's say we want to compare {{Hilt}}s using their equals() and don't care if the subtypes are different. To accomplish that we could use the following extraTypeMatchers.

import static com.atlassian.hamcrest.ClassMatchers.isAssignableTo;
import static com.atlassian.hamcrest.DeepIsEqual.deeplyEqualTo;
import static com.atlassian.hamcrest.MatcherFactories.isEqual;
    Map<Matcher<Class<?>>, MatcherFactory> extraTypeMatchers = new HashMap<Matcher<Class<?>>, MatcherFactory>()
    {{
        put(isAssignableTo(Hilt.class), isEqual());
    }};

That's not very pretty, but by wrapping it up our test can go back to simply being

    assertThat(anakinsLightsaber, is(equalTo(lukesFirstLightsaber));

and we get all the benefits we had before, plus we are matching Hilts in the desired way.

The biggest thing left to tackle is how to handle object graphs that have cycles in them. We have some ideas about how to do it, such as tracking the objects visited and if we find one that we've already visited just stop recursion and assume it will be true, relying on all the other matching to prove otherwise. I'm not 100% sure this will work. The main problem being, what happens if a field in expected value has a reference to, for example, the first object in the graph. But, the actual value doesn't have a cyclic reference but does have a reference to an object that should be considered "equal" to the same object as the expected value (I know, it's probably not entirely clear what I mean but I'm having a problem figuring out how to phrase it more better as my brain keeps breaking when I think too hard about it). I'm thinking for now, being able to specify custom matchers for types should be enough. If there is some part of the object graph that we expect to have a cycle, then just specify a custom matcher for it and move on.

To play with this you can checkout the code from the labs project, or you can get from our public maven repository. If you find any problems with it report them in JIRA.

Thanks, and enjoy testing again!

This week's offer of $5 licenses puts JIRA and Confluence within reach of even the smallest of teams. You'd be mad not to take advantage of it.

You're probably thinking: "Yup, that's a great deal, but I how do I run it?". Anticipating this, I took some 20% time last week to find a way to get you up and running quickly. What I've worked out will get you started with no up-front costs, and running costs that can be less than $5 a week!

With a few simple steps, anyone can use Amazon's Elastic Compute Cloud (EC2) to get JIRA and Confluence up and running for their team in a matter of minutes. Let me show you how:

Setting up

Step 1: Create an Amazon Web Services account

Follow Amazon's instructions for setting up an account for use with their EC2 hosting service. Skip the part about the X.509 Certificate and the AWS Account ID, as you won't be needing them. Instead, look for your Access Key ID and Secret Access Key on the Account Identifiers page.

Make sure you record your Access Key ID and Secret Access Key, as you'll need them in step 3.

Step 2: Install Java

Make sure that you have a recent version of Java installed on your desktop PC. You may already have it.

Step 3: Download and run the Instant Atlassian tool

Download the Instant Atlassian tool to your desktop PC, and at a command line, change to the directory containing the tool and run the following command (substituting the red placeholders with the credentials you obtained in step 1):

This will create a server for you, with JIRA and Confluence pre-installed, and 10 gigabytes of space for storing your data.

This tool uses the Amazon Elastic Block Store to store your data. 10 gigabytes of space will cost you $1 per month. These charges stop once you use the tool's "delete" command (described below) to delete the data.

The server will take a couple of minutes to start. During this process, it will give you two pieces of information that you need to keep a note of: The EBS Volume ID (which you'll need to stop the server, and hence the time-based charging), and the URL of your new server.

The server is a "small" EC2 instance located in the US and running Linux, so it costs 10 cents per hour (or part hour). These charges stop once you use the tool's "pause" command (described below) to shut down the server.

Step 4: Complete the JIRA and Confluence Setup Wizards

Open the server URL in your web browser, and you'll see the following page:

From this page, you can click the JIRA and Confluence logos to navigate to the respective applications.

To start, each application will display a Setup Wizard which you will need to complete with a few details. To make your life easier, some of the options have been pre-configured for you, and are disabled in this configuration.

Step 5: Share the URL with your team

Once you've finished the Setup Wizards, share the URL of the server with the rest of your team. They can open it in their web browser and can immediately get to work with JIRA and Confluence.

When you're done

Cutting costs by pausing and resuming

Your team might not need 24x7 access to JIRA and Confluence, so there's a lot of potential to cut costs by pausing your Instant Atlassian server when you're not using it: A 24x7 server will cost you $16.80/week, but this drops to just $4/week if you only run the server for 40 hours a week. (Storage and data transfer costs will be additional, but in typical usage scenarios these will be negligible compared to the time-based charges.)

To pause your server, simply run the following command on your desktop PC (substituting the red placeholders with the credentials from step 1 and the volume ID from step 3):

Once this command completes, your hourly charges have stopped (but your data storage charges will continue until you use the "delete" command, described in the next section).

When you need your server again, just run the following command:

When this command completes, your server will be up and running again. The URL will have changed, so make a note of it, and make sure to share it with your team. (Later in the week, I'll show you how you can set up your very own customised URL that won't change when you pause and resume your server.)

Cleaning up when you're done

While your server is paused, Amazon will only be charging you for the cost of data storage. If you've followed the instructions above to create a 10 gigabyte storage allocation, this will only cost you $1 per month.

If you have finished with your server, and you're sure you no longer need any of your data, you can delete your data storage by entering the following command:

When this command completes, your data will have been deleted, and Amazon will no longer be charging you for its storage.

Beyond the basics

These instructions should be all you need to get your team started with JIRA and Confluence.

Later in the week, I'll show you how to give your new server a customised URL of your own, how to backup and restore your data to protect against the risk of data loss, and how you might be able to reduce your costs even further by making an up-front payment.

All currency amounts are in US dollars, and were correct at the time of writing.

In my previous blog about 20% Time, I gave a summary of Atlassian's "20% Experiment" but left readers hanging as to the future of 20% Time at Atlassian. Well, I'm glad to end that suspense now and officially announce that Atlassian is continuing with 20% Time, rather than keeping it under the label of being an "experiment".

We get a lot of questions about the 'nuts and bolts' of how we've implemented 20% Time, so I'm happy to share the details.

The Goal of 20% Time
	To encourage innovation in products, development techniques and the Atlassian development ecosystem. Not every 20% Time project has to lead to shipped features Internal innovation is encouraged - new processes, techniques, libraries Contribution to the larger ecosystem counts too, where it assists Atlassian Failing is OK

The key here is that innovation is not guaranteed. We can't mandate that every 20% Time project must lead to a new feature since we don't want people to be afraid of failure. Rather, we aim to create an environment where innovation is encouraged and where 'trying' is as much a cause to celebrate as 'succeeding'.

We have also stated a broad scope for 20% Time that includes work on productivity enhancements and external activities (eg working on Open Source projects) — but only where there is a beneficial link back to Atlassian. After all, 20% Time is a part of our Development effort, not a charity. (We have the Atlassian Foundation for that!)

Tracking effort vs Tracking projects

Reporting against specific 20% projects can lead to a decrease in the innovation factor. 20% projects, by their very nature, will have a lot of false starts, dead-ends, and time spent that doesn't directly contribute to a production product (and that is how it should be). If you start tracking and reporting on individuals and how much time they are spending on a project, they might start picking safer, less innovative products, so they don't have a lot of false starts and dead-ends showing up against their name in the reports.

These two viewpoints lead to some friction. For example, we have two sign-off points to ensure projects don't consume too much time without foreseeable benefit:

• Any project that has consumed more than 5 days of developer time requires the sign-off of three supporters. These supporters should be developers who are not involved in the project, but who believe the project is both viable, and a good idea.
• Any project that has consumed more than 10 days of developer time requires sign-off from a Founder.

Enforcing these rules would mean that we have to track time against each project, but this is contrary to giving Developers freedom to innovate without a "big brother" watching over them.

After vigorous debate amongst management, it was decided to have Faith that our Developers would apply their time wisely. Therefore, we are tracking 20% Time at a high-level within our normal time-tracking system, but not at the individual project level. Developers are responsible for getting appropriate sign-off and updating the status of their own projects, the results of which are displayed on a dashboard on our corporate wiki.

(For those interested, we track each 20% project as an individual 'issue' within JIRA, then display those projects as a dashboard on our Confluence wiki.)

It's also worth mentioning that our quarterly FedEx days also contribute to 20% Time but are tracked separately. They involve specific days set aside for innovation in a time-limited, competitive-like atmosphere.

The Future

One year ago, Atlassian announced it's 20% Time Experiment. Originally a 6-month trial, we've actually let it go for 12 months before reviewing results and determining its fate.

In line with Atlassian's innate openness, I'm happy to share our findings.

The biggest surprise was the fact that we only delivered "1.1% Time", based upon the number of developers involved. While people had worried that we would spend too much time on 20% projects, it turned out that we hardly invested much time at all.

It's worth mentioning that these statistics are approximate. We didn't mandate strict record-keeping and we don't have reliable timesheet data since 20% Time got mixed-in with our FedEx projects. Therefore, the actual time spent could be 2 or 3 times this figure, which is still very low.

However, we do know that projects ranged in time from 1 to 18 days of effort and that we created some shit-hot improvements to JIRA, Confluence and Bamboo. There were also some projects focussed on internal improvements and Open Source efforts.

How did it work?

Each project was listed on our internal Confluence wiki, with manual tracking of 'days expended'. Projects that got incorporated into products were moved to a virtual 'Hall of Fame' while other projects were retired. A great many projects are still on-going.

Interestingly, the projects that were incorporated into products actually consumed very little 20% Time. Once a concept was proven, it was typically adopted by a Product Manager and incorporated into the normal stream of development. The bulk of work on the feature (adding functionality, testing, perfecting) was therefore done in normal development time. As a result, Hall of Fame projects were typically only 1-5 days.

What problems did we experience?

Atlassian has frequent product releases, so it is very hard for teams to schedule 'down time'. Small teams in particular found it hard to afford time away from core product development. This wasn't due to Team Leaders being harsh. It was often due to developers not wanting to increase the workload on their peers while they did 20% work. They like the products they are developing and are proud of their efforts. However, they don't want to be seen as enjoying a privilege while others carry the workload.

Another problem was accurate tracking of 20% effort. We have tight controls around Annual Leave, so why don't we have controls around 20% Time? The answer probably lies within the Atlassian culture. One of our core values is to "build with heart and balance" and there is a shared feeling of trust that people know whether they are providing valuable work. We track time in major buckets (eg new product development vs maintenance) but there is no "big brother" breathing down the necks of developers who can't explain every minute of their day.

Are we continuing with 20% Time?

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!

As you may recall, in March this year, Atlassian publically announced the commencement of the 20% Time Experiment. Since then, we have been keeping you up to date how it works, and what people have been doing.

Dmitry Baranovskiy, a Developer on the Confluence team, has been spending his 20% time on a JavaScript library for creating vector graphics. In August, Dmitry released Raphaël -- the first 20% project unrelated to an Atlassian product to be released to the public. At the 2008 Web Directions South conference held last week in Sydney, Dmitry delivered a presentation, related to his work, and was interviewed by SitePoint's Andrew Tetlaw on the beginnings and details of the library.

Here's an excerpt from the article:

SitePoint: Right, I thought my first question should be: why did you write Raphaël? What inspired you to write it?

I was doing a FedEx project. Internally at Atlassian, we have FedEx Days when you are given the time to present a project you've been working on. [...] So I thought I'd do something the programmers might not know anything about, and because I've had experience with SVG before, it made sense to work with SVG. But, as a front end developer, I'm concerned about creating something that only works in Firefox, so I wanted to create a bridge for VML on IE. My original project was to create a charting application, like a simple line chart. I quickly knocked it up in a day and a half from scratch, showed it, but it didn't win anything. It didn't impress people.

SP: Not even a little bit?

Oh, maybe a little bit, but not in general. So I left it for a while. Then we started our 20% projects (just like Google). I decided to pick up this project and extend it a little bit. I got rid of the charting part and turned it into a generic drawing library. Just a bridge between SVG and VML to enable me to do more cool stuff without worrying about browser compatibility.

So at the next FedEx Day, I used this library to create a Skitch-like application. You could take a picture and add things like arrows and ellipses. It even saved the image, but obviously that's not the hardest part.

Then I started working more on this 20% project. To be honest, I spent more than one day a week: I worked with my laptop on the train -- one hour to work and one hour back -- two days a week in general, for about a month. Then I decided that it was good enough to release, because it's better to do so before another developer releases the same thing. So, I released it in the middle of August.

I was stunned by the feedback. I didn't expect it, to be honest, because I wrote about it on my blog and I usually get about 20 hits per day; but after it was released and made it to the front page of Delicious and Reddit, I got about 8,000 hits per day. It chewed through my bandwidth and I had to create a new domain. It actually started costing me money!

To find out more about technical challenges Dmitry faced, like cross-browser compatibility, you can read the full interview. And if you're super keen, you can also follow Dmitry's personal blog to get the latest on what he's up to.

I expect that as 20% time continues to give our developers an outlet for innovation outside of the realm of Atlassian's existing products, more projects like Raphaël will make their way into the wild. As a relatively young Atlassian, this excites me greatly, as it's yet another reminder of how cool this place is to work at, and gives me instant bragging rights in any tech-related conversations that could occur in a social context (believe me, it happens!). Stay tuned for more updates!