Our Jira configuration is way less messy than what is going into this handmade sausage, and the details won't gross you out. (erix! / via Flickr)

By Kim Bryant

For those of you gung ho to get your geek on (and I mean that in the nicest possible way), this post is designed to give you the skinny on some of our basic Jira configurations. Not much philosophizing, but chock full of grainy-detailed goodness. Dig in!

User Types (Roles)
We have 5 main user types, what Jira calls "roles:" Component Lead, Project Administrator, Project Manager, Resource (developers, UX and designers), and Users.

Component leads are also usually Product Owners. They are responsible for specific products, driving the road map, and the work prioritization of a specific product. In Jira, they triage, enter, track and ensure completion of tasks. As I mentioned in my first post of this series, Jira automatically assigns tasks to component leads, though some users have the ability to change the assignee to someone else.

Project Administrators own a specific Jira project and have more permissions than most user roles. They can create components, assign component leads, set default assignees to a component, create new versions, and release and archive versions. For obvious reasons, there are only a few people with this role.

Project Managers are project managers at NPR, not just in Jira. They need some specific permissions in Jira that allow them to execute a handful of actions usually only given to Jira Project Administrators. For example, they can force tasks through specific workflow states, but they can't create or release versions.

Resources carry out the actual work required by the issue and include staff from the user experience, design, and development groups. Resources are usually assignees in Jira.

Users are our most basic role and usually stakeholders, managers, and business owners. They use Jira infrequently, and most often for logging bugs or enhancement requests.

NPR Jira's projects and similarly crunchy nuts and bolts, after the jump.

Continue reading "Jira: NPR's version" >

By Andy Carvin (@acarvin)

It's been just over one week since a devastating earthquake struck Haiti. As relief organizations rushed to the scene and ordinary people opened their wallets to support the disaster response, hundreds of techies from around the world have also stepped up to offer their unique skills to these efforts.

In the five years since the 2004 Boxing Day tsunami, more and more software developers, designers and bloggers have offered their services to a wide range of relief projects. I've been involved with many of them, and am helping out with Haiti efforts as well. This time around, much of the activity has come together around a virtual project known as CrisisCommons, which last year held an Barcamp-like event called CrisisCamp, challenging techies to brainstorm ways to build digital tools that support relief efforts. The CrisisCommons volunteers kicked into high gear last week, wasting no time in organizing a series of CrisisCamps last Saturday in half a dozen cities around the US.

I participated in the DC CrisisCamp, hosted by the Sunlight Foundation, and it was a remarkable event. Nearly 200 of us gathered over the course of nine hours to work on a variety of projects, such as GPS-powered mobile maps of Haiti with the latest satellite imagery and incident reports, to an English-Creole dictionary that can be downloaded to iPhones and Android phones. The app, called Tradui (translate in Creole), is currently available in the Android Market and is waiting to be approved for the iPhone app store.

Meanwhile, I've pulled together a team of information architects and researchers to start creating a wiki that serves as a sort of Yellow Pages for disaster and emergency preparedness resources that can be deployed for any disaster. We did something similar for the 2008 hurricane season on a wiki called HurricaneWiki.org. This new wiki will allow us to document resources related to Haiti, but also allow us to add new sections easily if a tornado were to strike Kansas, for example, or if dengue fever broke out in Southeast Asia.

The crisis response team at Google has taken the lead in unifying all the various collections of missing persons lists, from Facebook and news Web sites to the Red Cross. And it's already getting use - the Haitian embassy is utilizing this database as a tool for coordinating their efforts back home. A list of the various projects can be found at CrisisCommons.org.

Despite all the work that's been done already, there's still a lot left for us to do -- so much so that we're organizing another round of CrisisCamps this coming Saturday. NPR will host CrisisCamp DC, and we'll also have events in Boston, Denver, LA, Miami, New York, Portland and Silicon Valley. Even more cities may organize their own camps -- I'll post updates as they happen.

It's not just techies who are coming to these events -- we're also looking for people who are really good at doing online research, for example, or anyone who speaks either French or Creole. Even if you don't have any specific skills and want to help out with event logistics, we can probably put you to work. So if you're free this Saturday and live in a city hosting a camp, please consider participating. Even if you can't attend, there may be ways you can volunteer online. Visit CrisisCommons.org to learn more about the projects.

By Andy Carvin (@acarvin)

One of the biggest projects to come out of the many online volunteer efforts in response to the Haiti earthquake is the Person Finder widget. Created by Google's Crisis Response Team, the widget allows you to search a database of missing people in Haiti, as well as to add new people to it. Here's the code to embed it:

<iframe

    src="http://haiticrisis.appspot.com/?small=yes"

    width=350 height=300 frameborder=0

    style="border: dashed 2px #77c"></iframe>

  

One of the most personally gratifying things to come out of this effort is the fact that Google is using PeopleFinder Interchange Format (PFIF) to process the missing persons report. PFIF was created in the days and weeks following Hurricane Katrina, during which time many websites served as ad hoc collections of missing persons information, often published by family and friends in a narrative format. While this format made for powerful, heartbreaking reading, it meant there was no easy way to organize all of this data into a single database. So a group of volunteers created PFIF as a way of structuring this data, then mobilized literally thousands of other volunteers to convert these collections of missing persons information into PFIF.

We've seen the same thing happen over the last week - websites from CNN.com to Facebook have attracted thousands of posts from members of the public looking for loved ones in Haiti. With the creation of the Person Finder widget, it's now possible for any website to host a simple mechanism for posting or finding missing persons information. Some sites, including NYTimes.com, have managed to export their collections into PFIF. In other cases, volunteers have either converted missing persons lists by hand or have written scripts to scrape the information from other sites and send it to Google as a spreadsheet. And as of today, there's even an API to make this process even easier.

If you haven't explored the widget yet, please try it out. And if you have a Web site where you can publish it, please consider embedding it on your site.

By Andy Carvin

If you're a software developer, designer, database guru or any other type of geek who's got some free time on Saturday and wants to volunteer in response to the Haiti earthquake, be sure to check out CrisisCamp. Taking place in various cities across the US and in the UK tomorrow, these events will bring together technologists to tackle a variety of projects, such as building interactive maps of the earthquake zone, wikis, missing persons databases and other resources. Dozens of tech volunteers from around the world have been working on these projects all week, and CrisisCamp will be a chance for many of them to collaborate in person and kick them into high gear.

I'll be participating in CrisisCampDC, taking place at 9am Saturday at the Sunlight Foundation in downtown Washington. Check out this invitation page for more details. I'm helping out specifically in creating a wiki similar to our 2008 HurricaneWiki.org project, though focusing on a wiki that can be used for Haiti and future emergencies as well. Meanwhile, there are also camps scheduled tomorrow in Silicon Valley, Los Angeles, Brooklyn, London and Denver. Hope you can join us!

The Marine Iguana, while adept at foraging in water, would probably make a poor issue tracker. (Phil Frank)

By Kim Bryant

Bugzilla, Gojira... issue tracking software manufacturers must have a thing for Japanese sci-fi. All monster-lizard monikered apps are not created equal, though, and our challenges hardly resembled Hello Kitty.

The Digital Media Applications team used Bugzilla for about 4 1/2 years to file bugs, note future enhancements, and keep a general record of past fixes. Besides the Digital Media technical staff, some editors and interns also filed bugs in Bugzilla. Careful thought went into designing the fields so the information gathered would be as complete as possible, including details on platforms, browsers, and components. Items were selected from Bugzilla for upcoming releases, but the product owners often kept separate lists of "their" bugs in Excel or Word so they'd remember what was most important to them and their area.

By January 2009, Bugzilla had become a giant to-do list that kept growing exponentially. There were 3,000 open bugs when we started prepping for the switch to Jira, and many of those were no longer valid. It was hard to search for specific issues, and non-technical staff members were intimidated by the number of choices in field drop-downs. Bugs were often missing key information as a result and duplicates were accidentally missed. When developers added comments or a request for details to a bug, it was often overlooked or ignored because Bugzilla emails were sent to a large distribution list. Before a release, we had to contact reporters in a separate email or call them so they'd know when their bug was fixed and ready for them to test.

Why we decided to go Jira (please groan at bad pun now), after the jump

Continue reading "Jira: You Say Godzilla, I Say Gojira" >

By Demian Perry

Earlier this week, when our Washington office was closed and buried under two feet of snow, we compiled and released our first Android app to the Market, Android's version of the iTunes app store. Within seconds, the app was live to the world. There was no lengthy approval process, no request that the app more closely conform to the UI conventions of the operating system, not even a quiet suggestion from Google for how we might make our app perform faster. For a piece of software built by an old-media company, it was a bazaar beginning.

Coder-philosophers out there might have already caught my allusion to Eric Raymond's essay, The Cathedral and the Bazaar, the seminal work on the intellectual underpinnings of the open source software movement. Raymond's essay challenges the old notion that "the most important software...needed to be built like cathedrals, carefully crafted by individual wizards or small bands of mages working in splendid isolation, with no beta to be released before its time." Rather, developers should "release early and often, delegate everything you can, be open to the point of promiscuity" and rely on a developer community that resembles "a great babbling bazaar of differing agendas and approaches."

When I compare the iPhone to the Android, I feel as though I am handling the tangible instantiations of these two abstract ideas. The iPhone is an exquisite cathedral, a bastion of controlled design, where everything functions with over-wrought precision. The Android is, of course, the bazaar. Managed by the Open Handset Alliance, the Android operating system comprises the collective contributions of carriers, handset manufacturers and software developers. In many ways, the battle between the Android and the iPhone is more than a battle for market-share; it is a battle of ideas.

NPR chose to approach these two philosophically-opposed operating systems in kind. Our iPhone app was a work for hire, built by a specialist app developer recommended to us by Apple. The code remains proprietary, and we have no plans to open this code to the world. Our Android app, in contrast, was built by Google developer Michael Frederick as a 20% project, as Google allows its engineers to spend 20% of their time on projects they're passionate about. This was not only a gift to NPR, but a gift to the world: in the next few weeks, our Android code will be open-sourced under the Apache license. That means that anyone in the world can steal our code and use it, in part or in total, in whatever project they want.

And there are some really good things to steal here. I'll let you be the judge of where the most valuable code resides (just search for 'NPR News' in the Android Market), but my favorite part of the app is the player tray, the slide-up tool bar that allows you to see what's playing and interact with it, no matter where you are in the app. That was Michael's idea, and it seems unlikely that we would have landed on that idea had we taken the top-down 'cathedral' approach to designing this app.

To be sure, this is not the iPhone app: there are no live streams from stations, no program guide showing you what's playing on stations right now, no sharing tools. With the iPhone app, we tried to release perfection. With the Android, we were more concerned with creating tight code. Tight code means lightweight development, a virtue that will support the open source community that we hope to build around the app. In short, our plan was to build the kernel and leave plenty of room for growth.

We hope you enjoy our work in progress and, if you really like it, we hope you'll progress our work.

By Demian Perry

This morning, David Kaplan of Paid Content noted that today's re-launch of the NPR mobile site is "part of a larger strategy designed to ensure that its member stations don't get lost in the listener transition from over-the-air to digital." Kaplan got that right. While we're excited by the new features at NPR Mobile, we're even more excited by the seismic change in our mobile strategy that it represents.

But first, I want to gloat a little bit about the new features. Today is the first time our mobile Web audience has ever been able to:

• stream live signals from nearly every public radio station in the country, from Anchorage to Bangor

• listen to hundreds of public radio programs (not just the handful we offered before)

• hear full-quality audio over the Blackberry

It's a big day for public radio fans everywhere.

Although these changes are valuable, the most important benefit of the new mobile site will come in the weeks ahead, as we take advantage of the control and flexibility of our new platform. Unlike our previous site, which was developed and hosted by a third-party provider, our new mobile Web site is hosted entirely by NPR, and we have made a commitment to carry on future development in-house.

And that is no small challenge. Remember the browser wars? Back in the late 90s, before software manufacturers embraced the Web standards we enjoy today, Web developers had to create a different Web site for every web browsing program. With the emergence of the mobile Web, browser wars are back in a big way. Now that there are hundreds of mobile devices, each with its own browser and software limitations, developers are faced with a complex dilemma. Do we build something mediocre that works everywhere, or do we push the limits of the technology by building for only the best devices?

To answer that question, NPR turned to Conmio, a mobile software company based in Finland. Conmio began by considering how we could build upon the success of our existing mobile Web site, which was launched in 2007 by Crisp Wireless and won the 2009 Webby for best mobile news site. But Conmio also pushed us to expand the feature set and content offerings of our mobile Web site.

The result is a site that works on even the most basic feature phones, but also offers advanced features for a select group of devices, such as iPhones and Androids. The mobile site also extends our content offerings to encompass all the full text stories and audio in our archive, including Car Talk, All Things Considered, and many music segments previously unavailable over mobile. None of this would have been possible without some big help from Conmio's head of Technology, Lauri Piispanen.

We will still lean on Conmio from time to time, new features will be built and coded by our Java team, with all mobile development led by NPR's own Joanne Garlow. When mobile was an experiment, we looked outside our building for expertise in this technology. As mobile becomes the future of radio, we need to understand the technology ourselves.

In a few weeks, we'll begin tweaking the mobile Web site, but before we do that, we need to know how you're using it. Are you listening to a playlist on your morning jog? Are you selecting your local station and listening to live coverage in the car? Maybe you're using it to pipe your favorite music station over your home speaker system. If you're not doing these things, give it a try. And if you are, let us know what works and (more important) what doesn't.

For more on today's mobile Web site launch, check out NPR's press release, as well as some of the related coverage by mocoNews and TechCrunch. And coming soon: details on our forthcoming NPR News Android app.

NPR Chrome Extension (Screenshot / Jon Foreman / NPR)

By Jon Foreman

Today we launched an NPR extension for the Google Chrome web browser. Powered by the NPR API, the extension displays the latest headlines for various topics, allows users to set up custom news feeds and provides a streamlined listening experience.

For custom news feeds, you can set up tabs featuring headlines associated with a keyword. So if you are interested in news about Russia, for example, you can go to the extension options, enter the keyword 'Russia' and a new tab will be created listing headlines associated with this topic.

For stories that have audio, you can listen with a simple click. The audio continues to play as you browse through any web site. The audio player uses HTML5 to play the story. HTML5 audio tags allow one to play a clip directly from the browser without any additional audio streaming software, like Flash or Windows Media Player.

To try out the extension, you'll need the beta version of Google Chrome. After that is installed, go to the NPR extension page and install it.

By Jason Grosman (Programmer, Digital Media)

Before we release new code, such as our recent redesign, we do our best to test as well as possible, but we can't possibly figure out everything that could go wrong before we put it out there in the world. Even under the best circumstances, in a web site this complex and busy, problems will occur. Some of them are are avoidable, such as bugs in our code. And some of them are environmental issues, such as a network problem or database failure. Often, it's difficult to distinguish between the two. That's why it is essential to have a solid error handling system to track the errors as them come in, prioritize them, and give us enough information to be able to fix them.

Obviously, we have spent a lot of time building features of our system that users see. A large percentage of our time is also spent on error handling. The error handling system that we've developed has been through several rounds of incremental improvements, starting with writing to a log, then emailing a developer, and now updating our issue tracking system. These approaches are described below in greater detail.

Logging

Every time our PHP code encounters an error, it gets automatically logged by our Apache web servers. We have dozens of web servers and they generate thousands of lines of logging information every day. We could get lost in the torrential downpour of log messages. Parsing through the logs is a good way to track down a problem once we know about it, but it was horrendously inefficient way to stay on top of new issues as they come in. Not only were they coming in too fast for any one person to keep track of, they also didn't provide any context about what a user was doing when the error occurred (and context is critical to the fundamental truth of debugging code that you must be able to consistently reproduce the problem before you can fix it or test the fix).

The other problem with this kind of logging was that we were missing out on client side error messages. In the past year or so, NPR.org has added more and more javascript to support a growing list of features. This resulted in more client side errors, which were very hard to track. All of the different combinations of web browsers, browser settings, operating systems, proxy servers, etc., each one potentially handling our javascript differently, led to problems that we might never have encountered while testing in our limited set of test environments. And since they only occurred on the client machine, we would never know about them unless a user sent us an email or complained in some other way.

As a result, we implemented something last year that we call jslog. With AJAX, we are able to send messages back to the server without reloading the page. Now, every time one of our pages has a javascript error, instead of making the user's client browser handle the error, leading to a less than stellar user experience, we catch the error and send it to the server using AJAX to be logged in the Apache web server logs. This is completely transparent to the user and allows the page to keep loading, even if it is not 100% perfect.

Continue reading "What Happens When Stuff Breaks On NPR.org" >

By Mark Stencel and Keith Jenkins

YouTube announced today that NPR is one of a handful of news organizations pioneering YouTube Direct, a new tool that allows us to request, review and display video clips produced and submitted by YouTube users.

YouTube Direct will be embedded on NPR.org, where we can easily solicit user-generated video and feature the pieces our editors select. Our first project will focus on science. The WonderScope Challenge is an occasional series that solicits original video, art and animation related to a particular scientific concept -- and challenges users to "bring the abstract to life." The first concept we are inviting submissions on is "time"; the deadline is Thursday, December 17, at midnight. We'll solicit submissions via NPR.org, YouTube, Facebook and Twitter.

This is how it works:

1. We create an assignment, like the one described above.

2. Users upload their submissions via the submission box on the page.

3. All videos go into our "submission" box for review.

4. Once a submission is accepted, it is added to the playlist for that assignment. This playlist will be on the submission page and also be shown on our YouTube page. YouTube will also be promoting the assignments on their pages as well.

5. When we selected a user piece for our playlist, it will get a NPR icon attached that will travel with it wherever it is embedded -- on YouTube, our site or elsewhere. If we don't approve the piece, the video remains on the user's own YouTube page.

The WonderScope Challenge is our first foray with YouTube Direct. We're hoping that it will have a number of applications when it comes to collecting and curating user-generated videos. And as always, we welcome your feedback.

(Mark Stencel is NPR's managing editor for Digital News. Keith Jenkins is supervising senior producer for multimedia.)