Archive for the ‘swdev/tools’ Category

Personal wiki and multiple desktops

Monday, July 4th, 2005

I’ve found PersonalWiki a good way to keep a lot of information that was previously distributed in text files, outlook, jabber histories, etc. It’s a single, low-friction, hypertext place, with lots of good search capabilities, and my implementation is based on a free and open solution with a great support community (MoinMoin).

Now that I’ve got MultipleDesktops working smoothly for simple things using Subversion, the obvious question is can I use it to keep my PersonalWiki synchronized across machines as well?

Yes, and I’m rather happy with the result; see this experience paper for details (a wiki page at MoinMoin itself).

Subversion desktop synchronizing

Wednesday, June 22nd, 2005

I mentioned in an earlier post about groove and synchronization that I was more interested in using subversion to synchronize my work on multiple computers — an idea I first saw in this Martin Fowler post.

Adding a mac to our home has finally forced the issue, and I’ve now got a subversion repository on the mac for synch’ing my stuff across different machines. I’ve not pushed the Multiple Desktops idea very far yet — I hope to report back on that later — but I took some subversion setup notes in case you’re trying to do something similar.

(more…)

So many ways to skin that scm cat

Saturday, September 18th, 2004

While pulling sources for tortoisesvn, I came across the better-scm site; from there, I found David Wheeler’s essay on OSS/FS scm tools, which primarily discusses CVS, subversion, gnu ARCH, and Monotone (the latter two were new to me).

Having recently moved to subversion, and being very happy with it, I was surprised to see a lukewarm review. Of course, my previous experience with scm has been primarily HP’s softbench, clearcase, and RCS (and, fortunately, the briefest of encounters with VSS), so I’m already lightheaded with being set free from the pessimistic-lock camp of version control. Liberal use of branching, and easy separation of commits and lands, has been a major major improvement in my sw development team lead experience. Funny just how long you can work in a cruddy setup without knowing how cruddy it is.

So Wheeler’s paper turned me on to the next scm things that I don’t even know that I don’t know. A basic difference looks to be centralized vs. decentralized models:

Some people believe SCM systems should primarily aid in controlling a centralized repository, and so they design their tool to support a centralized repository (such as CVS and Subversion). Others believe SCM systems should primarily aid in allowing independent developers to work asynchronously, and then synchronize and pull in changes from each others, so they develop tools to support a decentralized approach (like GNU arch, monotone, darcs, and Bitkeeper).

Though even centralization can mean different things; he quotes Bastiaan Veelo:

In short, one could say that Arch is centralized around a code integrator, and that Subversion (like CVS) is centralized around a repository.

Wheeler’s darc horse for scm leapfrog is darcs, something written in Haskell, a language I’ve never even heard of. His example of token replacement showing the handling inter-patch dependencies was pretty cool. But he doesn’t think it will happen: most scm tools are working well enough (yeah, CVS worked well enough for a long time), and Haskell’s functional programming is a serious barrier to contribution.

I had no idea what I was missing in scm. It seems wherever you go, someone has gone a lot, lot further.

Learning from SWT

Sunday, September 5th, 2004

Although blogs often suggest the freshest of web content, I often find myself reading things months or years old, by following a blog’s links.

An example is some OTI stuff on SWT, from way back in 2001. The first article shows rather clearly the impact of two different approaches to using JNI for accessing platform-specific GUI widgets. By strictly using JNI as no more than a forwarding proxy, they get a single API to support, all the power of java for all of their programming logic, and much simpler debugging and profiling.

This led me to a second SWT article which is a good example of coding standards in action. The standards are defensive, and influence the api design, e.g.

This rule occasionally leads to API that seems artificial. For example, GC.getClipping (Region) forces the programmer to create a Region in order to get the clipping region from a GC. Although it might have been a bit “prettier” to provide GC.getClipping () that returned a Region, this would break the rule because it would have to allocate an operating system resource outside of a constructor. While it could be documented that the programmer needs to free the Region returned by GC.getClipping (), programmers don’t always read the documentation. Making the programmer call the constructor for the Region makes it clear that it is the programmer’s responsibility to free the resource.

In the “how did I get here” department: wanting to see the contents of Steve McConnell’s second edition of Code Complete, I bugmenotted my way past cc2e’s registration. Out of curiosity, I clicked the “profile” button for the bugmenot user, and saw a mailinator email address. “That’s cool,” I thought, and seeing that its creator had a blog, I stopped by there and read his java rant. Which had a kind reference to SWT.

Oh please God, let it be ready for primetime…

Saturday, June 19th, 2004

Signed up today (well, tomorrow, according to system timestamp–guess that’s Russia) for resharper EAP at intellij’s confluence community site. VS.NET has been a major disappointment since IDEA; I can’t wait for nav, dead-code graying, and at least the push-it-around-and-rename-it refactoring stuff. I’m the proud inheritor of a 4000-line C# class that needs some help bad.