Death of Tr.im: Rolling your own link shortener might be a good idea

RIP, Tr.im

RIP, Tr.im

UPDATE AUG 12: Tr.im reports that they’re not dead yet. Hey, congrats to them for working something out, at least for now. But still: As Aron Pilhofer notes in the comments below, relying on any third-party for a core functionality represents a significant risk, so I still stand by my advice in this post.

Yesterday the popular URL shortening service Tr.im abruptly bit the dust — begging the question of whether existing Tr.im shortlinks would suddenly break. (Tr.im says its existing links will continue to function at least through Dec. 31, 2009.)

This doesn’t affect me much, since I rarely used Tr.im — but others relied heavily on Tr.im and its statistics for how its shortlinks were used. Bit.ly, which also tracks shortlink statistics, is now Twitter’s default link shortener. PaidContent recently covered how difficult link shortener service business is. Which means that other link shorteners could fall down and go boom at any time.

So if you really must rely on shortlinks for any reason, it probably makes more sense than ever to create or control your own link shortener

Continue reading

My She’s Geeky Tweets, Part 1: Agile Methodologies

For me the session on Agile Methodologies led my Desi McAdam of Hashrocket was one of the highlights of January’s She’s Geeky unconference. It was one of those occasions when I felt several disparate pieces of context clicking into place and starting to make sense.

NOTE: This is part of a series based on my live tweets from At last weekend’s She’s Geeky unconference in Mountain View, CA.

Series index

My immediate need for understanding more about Agile development is that I’m helping to organize the new Reynolds Journalism Inst. News Collaboratory. The point of this effort, as Jason Kristufek recently wrote, is to be a “do tank,” not a think tank, for experimenting with new options for the news business.

That’s why we’re trying to engage in this community people with diverse types of “do” experience — technologists, librarians, entrepreneurs, financiers, advertising and marketing pros, etc. And, yes, journalists too. The point is to actually get people working together to try stuff and share the results, not just to talk about stuff.

The question then becomes: How do you get people to decide on which problems to solve or experiments to try, parse those out into doable chunks, move their efforts forward, and assess results? Rather than try to do this all on the fly, I thought it might be useful to borrow some ideas and practices from Agile development.

For context, here’s the Agile Manifesto, as well as an excerptWikipedia’s current article on Agile:

“Agile methodologies generally promote a project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices that allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals.”

So with that context, here are my live tweets from this discussion (cleaned up a bit). Unless otherwise attributed, all points made here came from Desi McAdam…

  • Now in the Agile methodologies session, which I hope will help with RJI collaboratory.
  • There’s a difference between Agile development & utter chaos. But Agile can devolve into chaos.
  • Agile is a very rigid process. If you don’t stick to the process, things fall apart quickly.
  • Agile is an iterative process: earlier work gets outdated quickly. Cycles are smaller, iterative, to adapt to change as change happens.
  • Pair programming is more popular with females — more interactive, cooperative. Keeps you on track, out of rat holes.
  • In Agile, you have to be disciplined: Organizations and your pair partner must be disciplined. Very accountable.
  • Pair programming is a wonderful way to do knowledge transfer.
  • Pair programming improves code quality. If you’re coding and someone’s watching, you’re less likely to do something hacky.
  • Pair programming is more productive. People don’t generally like to interrupt working pairs. (Interesting!)
  • Agile also is about sustainable work pace: Don’t burn people out, get the most benefit from coders.
  • Some companies require some up-front planning, like wireframes or mockups, before throwing Agile development team on it. Do you have a good base?
  • Agile used in Spot.us development process. David Cohn came to us with wireframes. We started storycarding. Right off bat, we had to prioritize and think about what desired feature could go.
  • Storycard = definition of a chunk of work. Say what the business value is first. Get client to tell you, helps set priorities
  • Glitches with Agile: Lack of quality assurance (QA): Developers should be writing test code. Pivotal tracker (popular Agile project management tool) doesn’t address QA.
  • Rally, other tools do account for QA — but they’re bloated and slow and tedious to use. Simpler configurable tools needed.
  • Standup meetings: key part of Agile process. Can work in any organization. Very short meeting: everyone stands up, gives recent and current tasks, identifies obstacles.
  • Agile is hard to do in a distributed environment (workers not in same location). iChat, screen sharing helps. Good manager/developer communication is crucial.
  • Good Agile stories follow INVEST principles (from Extreme Programming, a related discipline): Independent (self-contained), Negotiable, Valuable, Estimable (you can guess how involved/big it might be), Small, Testable.
  • ME: I’m liking the story analogy of the Agile process. I think media people will be able to relate to that.
  • Negotiable = not defining the story in such rigid detail that it can’t be changed.
  • Desi recommends Liz Keogh as a great resource on thinking about Agile.
  • ME: The Agile session is incredibly valuable! Desi rocks!!! I needed exactly this info right now!
  • I’ll be sharing more thoughts on Agile later — but for now here are a couple of takeaways that struck me:

    Storycarding reminds me of journalistic news judgment. The process of breaking a project down into tasks that meet invest criteria reminds me how journalists and editors decide which news and information warrant development into a story. Both involve assessing a situation and needs, and matching it with criteria. Both appear to be more like art than than science or rote procedure.

    Applying Agile techniques to other fields (such as news and journalism) is itself an experiment that should be handled in clear storycard-like chunks. It may not work, and it certainly would be a culture shift. I think, for cultural reasons this is a strong reason to involve geeks, entrepreneurs, and others in this process — and to team them together with journalists to promote knowledge transfer.

    …More thoughts later. But for now, what do you think? Please comment below.

    Reblog this post [with Zemanta]

    Working with Journalists: What’s in It for Geeks?

    NOTE: This post originally appeared on Poynter’s E-Media Tidbits, and there are some comments over there. I’m reposting this here because, frankly, this site poses fewer hurdles to commenters, and I’d like to get some diverse discussion happening.

    Earlier this week I wrote about the internal and external obstacles journalism schools face when trying to achieve collaboration with other academic departments (such as computer science). That spurred a pretty interesting discussion in the comments.

    This discussion got me thinking: Right now, it’s becoming obvious to many journalists that our field sorely needs lots of top-notch, creative technologists. Developers for whom software is a medium, and an art form. Developers with a deep passion for information, credibility, fairness, usefulness, and free speech.

    However, my impression is that, so far, it’s not nearly so obvious to most “geeks” (and I use that term with the utmost affection and respect, as do many geeks themselves) how they might benefit from collaborating with journalists, j-schools, and news organizations.

    So if journalists need geeks, but right now they don’t need (or even necessarily want) us as much, the question becomes: What’s in this for the geeks? Why might they want to work with us? Where’s their incentive?… Continue reading