Tag Archives: tools

At my new job, we’re selecting a hosted “revision control + wiki + issue tracker + document repository” service.

My first recommendation was Bitbucket. I’ve used it for a while, and have always been satisfied. (I even have a paying account plan!) But after a day of use, we bumped into odd problems. Like, Windows users couldn’t upload documents, and errors when we used HTTP Secure protocol. And then I found many issues in Bitbucket’s issue tracker (i.e., issues about Bitbucket) that were (open && non-trivial && had no activity for many weeks).

How do we confidently assess the health of a hosted service? Large enterprises can meet the other company’s management and get privileged information about its finances, staffing, etc. But individuals or start-ups getting at that kind of information is impossible, or at least will need way more back-and-forth e-mails than they have time for.

Read More

In Becoming a Craftsman, Rock Hymas writes about Mercurial vs. Subversion. It’s an excellent exposition of the tools and their underlying philosophies, and how his own development style changed from working on a Mercurial-based project. It’s slightly marred by his conclusion that using Mercurial makes you a better developer; he seems to believe it does this partly through its own weaknesses, which I find odd reasoning. But putting that aside, it’s an excellent read.

He tasks me for my July 2008 article on Mercurial vs. Subversion:

One counterpoint to the ease of branching is that it may isolate developers. John DeRosa registers his concern about this:

“Additionally, I think distributed SCMs like Mercurial have a not-yet-fully-appreciated problem in making it too easy to not [ever] check code back into the main pool.  With a local repository, a developer can feel protected from accidents and continue working happily for quite a long time.  And then, say a year down the road, he/she does a massive check-in and discovers an integration problem.  Branches, or a local repository that is effectively a private branch,  should be easy to make — but not too easy.”

Let me explain why I don’t buy it. First, “a year down the road”?! Seriously? It says something that you have to imagine a scenario so horrible and unlikely in order to envision easy branching as a bad thing. I think that the author likely didn’t realize how easy merging usually is with a DVCS like Mercurial. And he must have totally forgotten that this lone maverick developer could have been merging the main development line into her own repository every day or week. The right solution to this imagined (and barely imaginable) scenario is not to eliminate easy branching, since without it the lone developer will do the same thing, but be much more likely to lose her work because it won’t be stored in a repository. The right solution is to fix a broken culture that enables someone to go a full year with no accountability for their work.

Read More

NewsGator has released a Beta update (3.2b6) of NetNewsWire, which is their Mac syndication feed reader. I’ve used NetNewsWire for over a year, and before that I used their FeedDemon syndication reader on Windows. I’ve been very happy with their readers, so when I received the notice of the new version + impending change to their synchronization service, I immediately upgraded.

Here is a snap review.

The UI is unchanged and there are no new features. Q: What new development has Newsgator done with their syndication readers? A: Nothing.

The only change is that it now syncs with Google syndication reader, because they’re nuking their NewsGator Online syndication service. Essentially, it’s now just a front-end to Google Reader. A front-end with a dated UI.

As an extra bonus, it nuked 3/4 of my subscriptions. By, “nuke,” I mean that they flat-out disappeared. Gone. Pffffffffffffft. That’s 3/4 of the subscriptions I have lovingly built up over the years. Thank you, that was swell.

I can easily confuse it by creating folder names containing commas.

I know this is a Beta, but come on.

I’m looking for recommendations for alternative RSS readers. I don’t like web-based readers; I prefer a local application. Any suggestions?

Update 7/30/09: The NetNewsWire Beta blog has a to-do list for version 3.2. It lists things that don’t work because Google Reader doesn’t support them. Like nested folders, and folders with names containing “certain characters.” The 3.2b6 Beta deletes them with no warning. Brilliant.

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to Ma.gnoliaAdd to TechnoratiAdd to FurlAdd to Newsvine

Over the years, I’ve used many website forums and bulletin boards. They’ve been based on a variety of packages, such as phpBB, LiveCloud, or vBulletin. PhpBB is, I think, the reigning king of forum software.

To add a forum to a site, you can use an off-the-shelf system, or roll your own. Casual sleuthing will reveal an assortment of at least 50 some-odd off-the-shelf bulletin board systems, from which you can choose one to run your forum. If you want a bespoke forum, most frameworks provide bits of the necessary functionality, if not entire customizable forum modules. For example, see the Django forum applications or Drupal’s Forum module.

Web forums are OK, but I’ve yet to encounter one that wasn’t clumsy in some way — sometimes, in multiple ways. And you know what? I’ve yet to find one that beats august Usenet, when accessed with a decent reader such as Agent or Unison.

Add to FacebookAdd to NewsvineAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to Ma.gnoliaAdd to TechnoratiAdd to Furl

I’ve used micro-blogging for the past five months. I’m switching to twitter.


I was involved with a number of projects at Fisher Communications until last month. Including building a Plone system to be its news sites’ in-house CMS. Our development environment and technology stack were open-source, with only a couple exceptions.

When I worked on our technology roadmap, an early consideration was how to distribute quick (lightweight) intra-team updates. Virtually the entire development team would be within the same building; of those, virtually all would be within one office. The CMS project would eventually reach 10 heads in dev, QA, and operations; plus content creation and advertising traffic control. Other dev or page layout individuals would be on other activities. For all of this, we needed a way to inform each other about daily activities. Daily stand-ups are used for this in a typical XP or Scrum team. (To be fair, stand-ups are used in many different development methodologies, but XP and Scrum have greatly popularized them in the mainstream technical media.)
Read More