Tom Mollerus' Weblog

I've been tearing out my hair, muttering curses under my breath, and slamming my fists to my desk for much of this week. The fault lies with Subclipse, and its stubborn refusal to find the default SVN client (namely JavaHL) that I so kindly installed for it on my MacBook Pro.

It all started when I completely rebuilt my Eclipse environment, using the latest version, Indigo, so that I could install the wonderful PhoneGap plugin. I installed the latest version of all of my plugins, including Subclipse, and I also installed the latest CollabNet subversion binaries. Subclipse's wikipage for JavaHL says that if you install these binaries says that you shouldn't have to do any further configuration to get Subclipse to work, but in my case that turned out to be wildly optimistic, to say the least. Each time I tried to use a Subclipse feature, I was presented with the dialog that I gather all too many people are familiar with: "Unable to load default SVN client". A search across the Googles for this sentence gave me a lot of results, almost all of which referred to confirming the path variables in your .profile file or your eclipse.ini file. I edited, I confirmed, I failed. Again and again. I even tried to install SVNKit, but their subversion client doesn't support the svn client version of 1.7.x that Subclipse was looking for. Aargh.

The binaries that Collabnet installs have version numbers of "1.0" in their filenames, so you really can't tell what version they are. Instead you have to run "svn-javahl --version" to get that information. And what do you know, I had version 1.6.x.

So the final solution?

1. Install MacPorts if you don't have it already.
2. Use MacPorts to install the JavaHL bindings (you'll get the latest version by default):
   sudo port install subversion-javahlbindings

I've recently found myself evaluating wireframing tools, and I thought I'd share the results of my analysis. First, let's put out a definition of just what a "wireframe" is:

"[a wireframe] is a visualization tool for presenting proposed functions, structure and content of a Web page or Web site. A wireframe separates the graphic elements of a Web site from the functional elements in such a way that Web teams can easily explain how users will interact with the Web site."
From Webopedia

Here are the main criteria I used to compare wireframe tools:

• I would prefer an online tool, or at least a desktop tool that offers real-time collaboration instead of file fragmentation. This tool should offer the ability to preview or user-test the wireframe over the web.
• I would love a tool that promotes and supports gradual enhancement of site elements, starting with basic page elements showing relative priority, then adding layout, then adding visual design.
• I would love functional prototyping, where you can configure clickthroughs from one page in the wireframe to another. In-page functional prototyping (such as drop-downs, popups, overlays, AJAX, etc., would be a bonus).
• I really want master templates to support global changes to page elements (ie, when you change the header or footer or even the layout of the template, it affects all pages in the wireframe).
• Export in HTML/CSS is highly preferred since it would save me time, but it's not completely necessary from my perspective.
• I would love the ability for us to add comments and annotations to individual page elements. This will help us evolve each wireframe, and annotations can serve as valuable notes during development to tell webdevs how each page should function.

I looked at the following tools:

• Like the snap-to alignment!
• Drag pages onto page elements to create links
• I like the ease and simplicity, but there doesn't seem to be a header/footer/page wrapper-- no master templates.
• Only exports as PNG/PDF.

• Exports as HTML.
• I don't like the open dialog, but I love the fact they have templates for different devices.
• Flash-based, and so the interface just isn't as fast as others.
• Controls for master templates are very hard to find.

• Requires Flash
• Has page commenting
• I like the presence of the drag-n-drop widget list, but it's ordered alphabetically instead of by functional groups, and the drawings look like a pencil sketch.

• It's a download, but has collaborative access (even SVN, where you can check out individual pages).
• Can upload files to share.axure.com to generate password-protected prototypes, or can generate local prototypes.
• You can export all copy
• You can gather and manage comments
• You can add annotations/page notes
• Export HTML
• Masters make templates for header, footer, etc.
• Disappointing that you have to publish specs to MS Word
• Disappointing that it's not a one-step publish to a web-available prototype.

• Has templates and masters
• Has component/widget palette, but these tend to be richer and more complex than I really want.
• Has page documentation and annotation
• Lets you modify CSS and HTML

Admit it: one of the least favorite parts of our jobs as developers is coming up with time estimates for our work. Joel Spoelsky describes it this way:

Why won't developers make schedules? Two reasons. One: it's a pain in the butt. Two: nobody believes the schedule is realistic. Why go to all the trouble of working on a schedule if it's not going to be right?

If you're like me, and don't have the data available to do evidence-based scheduling, to produce estimates you basically make a guess based on past experience. And we all know how accurate those guesses are. (Usually, not very accurate at all. I worked with a project manager once who confided to me that all of the PMs at the company would take the developers' estimates and then double them to come up with what they felt was a more realistic schedule.) Sometimes I feel like it's like a serious job endeavour and more like a game of Name That Tune for software ("I can code that feature in... 6 hours, George!").

So around here at Ping Identity, we don't have to rely on time estimates so much. Instead, the engineering team has started using a metric called "Whitneys", measured on what we call the Whitney Complexity Scale. It's named after its creator, technical project director Brian Whitney.

Just a tip for those of you who, like me, have svn+ssh access to a Subversion server whose ssh port is not set to the usual value of 22: you can usually specify the port right after the server name, like so:

svn+ssh://svn.someserver.com:12345/path/to/repo

svn+ssh is a protocol that provides more security than using just svn over port 3690 or port 80, since all of your traffic will be encrypted like any other ssh communications.

Thanks to everyone who attended tonight's Boston CFUG presentation on using Subversion. If I can help anyone get set up with the server or a client, just let me know.

Wow. Between a new job with Ping Identity and attending the cf.Objective() conference, it's been at least 3 weeks since my last posting. Well, one of the things I learned at the conference came after asking a presenter for his opinion on whether there was any Subversion client for Macintosh that was worth using. The Finder plugin is a great idea, since it's like TortoiseSVN, but it's not full-featured and doesn't always show status overlays correctly; and other clients keep views of working folders and repositories in separate windows. Finally, other clients don't have a built-in diff program. The presenter didn't think that any Mac client was worth using either.

But someone from the end of my row in the audience told me to speak to him after the session was over, and he told me about Syncro SVN. It has everything you could want in a client-- an integrated view of your repositories, working directories, a great diff viewer, and session log. Plus, it has all of the features you might want, such as the ability to relocate working directories between repositories. If you're not satisfied with other Subversion clients on the Macintosh, I'd suggest you give Syncro SVN a look.

I'm a big fan of the version-tracking application Subversion (aka, SVN), as it's saved my bacon many a time. It's so easy and so helpful that I wonder why I didn't start using it sooner than two years ago.

I like SVN so much that I'll be speaking on how to use Subversion to the Boston CFUG on May 20th, 6:00pm. If you live in the Boston area, make sure to RSVP-- I'd be thrilled to see you there. Whether you're on a development team and want to avoid overwrite conflicts, or whether you're a solo developer who wants to have a record of coding changes over time, Subversion can save your bacon, too.

Today when I checked a third-party site for updates to the XSLT files I use in Microformats.cfc, I found myself wondering how I'd update the new files so that they contained the minor modifications needed for use in my component. I could have saved the new files in a separate directory, then opened each new file and compared it to my older version, making changes by hand. But I was a little worried that I'd forget to notice a change or two-- these XSLT files aren't exactly easy to read, and I only work with them once every few months. Then I remembered the ever-so-handy "diff" utility from my Subversion client, TortoiseSVN.

Just an FYI to everyone who read yesterday's post about changing the URL for your Subversion working directory when your repository is migrated to a new server: Stefan from TortoiseSVN politely informed me that I was mistaken to suggest that the "switch" function could be used to associate working directories with new URLs; instead, the "relocate" command should be used.

I might as well take this opportunity to thank Stefan and the rest of the TortoiseSVN team for not only making such a great FOSS product, but for ensuring that I don't propagate my own silly mistakes to the rest of the Internet developer community. ;)

[Editor's note: this posting has been updated to correct an inaccuracy about which Subversion function should be used to associate working directories with new URLs.]

Pete Freitag mentions a way to move a Subversion repository from one server to another server by making a dumpfile from the old repository and importing it into the new repository. I've had to accomplish the same thing, but I was faced with an extra step afterward. If you're like me, you may have some changes that you're testing in your working directory but haven't yet committed; so how do you keep those changes while reassigning your local working directory to use the new repository?

The answer is the "switch" function. Just select the top level of your working directory and run "switch" The answer is the "relocate" function. Just select the top level of your working directory and run "relocate"(which in the case of my SVN client, TortoiseSVN, means right-clicking on the working directory.) You'll see a dialog that looks something like this:

Just enter the URL for the new server, and all of your local SVN files will be updated to use the new repository. That way, you don't have to check out from the new repository and you can keep changes that you haven't yet committed.

After having this happen to me several times, I finally woke up and smelled the coffee-- I went and set up Subversion as a version-control system for all of our web files. What a lifesaver! I will never, ever do web work without saving changes to Subversion (SVN) again.

If you've never used a version control system before, I can't encourage you enough to start. There's no longer any valid excuse not to use it:

• Using version control will be too hard to do, with checking files out, checking them in, and resolving conflicts.
  That may be what it's like to use Microsoft's Visual SourceSafe product, but SVN solves all of those problems, and makes it so easy to save changes. With SVN, you check out a copy of all of the files in the project, then edit them as you wish and save changes as you wish. There are no locks-- you can save your changes any time you like. If another developer happens to have saved changes to the same file, SVN will automatically merge the changes for you. If your changes directly conflict with those of the other developer (meaning that you've changed the same lines), SVN will let you know that you need to perform the merge yourself.
  
• I'm the only developer working with these files. Why would I need version control if I can't overwrite my own changes?
  True, you can't unknowingly overwrite your own changes. But certainly there have been and will be times that you wish you could revert to an earlier version of a page that had a better layout or lacked a certain bug. Unless you're using version control, you can't get those versions back.
  
• My web site just isn't important enough to merit version control-- it's only HTML, after all.
  When Subversion is easy to use and free, there's no good reason not to use it. And there's no site that's not going to run into the issue of needing to revert to a previous version of one page or another. Even with an HTML-only site, you may want to revert to an earlier version of your design, your CSS, your HTML, or most likely, your content.