In many ways, I think you could say, I live and work in a bubble of the technical future that, as Gibson said “isn’t evenly distributed,” yet. I have developed a set of tools and work flows that enable me to work nearly anywhere and on a moment’s notice. I work for a company which great and open internal infrastructure that allows us to securely communicate and collaborate in whatever way we think will best serve the projects we’re working on. And I know enough to be able to automate the boring parts of my technological experience. In all, pretty good.

Here’s the thing though: despite all of this technological infrastructure, all this know how and frankly awesome connectivity: all of the tools we use to collaborate technologically: chat rooms, wikis, paste-bins, version control systems, instant messages and email all work better when you’re in the same room. Examples:

I was sitting in a talk with a coworker, and we were both logged into an IRC room from our laptops, where we were able to share some useful examples, links, and other commentary without being (very) disruptive. In day to day work, I (and my coworkers) spend a lot of time using chat rooms to communicate and share information with people who are only a few feet away, and in the end we get a lot done.

There are probably a lot of reasons why this is the case: digital relationships are almost always supported by real life relationships, there’s a level of hard to document interstitial and context setting that we do in real life that is difficult to efficiently create digitally, but that can be accomplished without second thought *in real life, and so forth. But, having made this realization, I think there are a few conclusions to be drawn about collaboration technology:

• It helps to centralize information flow. So much collaboration technology is “pull” based, and there’s no good way to ensure that people know you’ve done something that they might consider without pushing information to them in some manner. Even so, create one place where the people you’re working with can see what you’re working on.

  Use something like an IRC channel, or an xmpp MUC room, combined with a service like notifixious or something similar. In a lot of ways, the incessant emails Facebook sends achieve the same goal.

• Communities come together to work on something specific and concrete, but inevitably they bond and endure for other reasons and other kinds of conversations. While creating “off topic” silos is awkward, creating the space for people to get to know each other is essential to making people work together well (and thus use collaborative technology better.)

• Focus most of your attention on “getting things done,” and less attention on the “how things are done.” There are so many technological solutions, so many options, and so many different contexts that it doesn’t really matter how things get done as long as they do get done. The right and preferred tools will arise and present themselves when needed, and as long as things are getting done using the right tool doesn’t matter much.

Onward and Upward!

I’ve been trying to figure out wikis for a long time. It always strikes me that the wiki is probably the first truly unique (and successful) textual form of the Internet age. And there’s a lot to figure out. The technological innovation of the wiki is actually remarkably straightforward,¹ and while difficult the community building aspects of wikis are straightforward.² The piece of the wiki puzzle that I can’t nail down in a pithy sentence or two is how to organize information effectively on a wiki.

That’s not entirely true.

The issue, is I think that there are a number of different ways to organize content for a wiki, and no one organizational strategy seems to be absolutely perfect, and I’ve never been able to settle on a way of organizing wiki pages that I am truly happy with. The goals of a good wiki “information architecture” (if I may be so bold) are as follows:

• Clarity: It should be immediately clear to the readers and writers of a wiki where a page should be located in the wiki. If there’s hierarchy, it needs to fit your subject area perfectly and require minimal effort to grok. Because you want people to focus on the content rather than the organization, and we don’t tend to focus on organizational systems when they’re clear.
• Simplicity: Wikis have a great number of internal links and can (and are) indexed manually as needed, so as the proprietor of a wiki you probably need to do a lot less “infrastructural work” than you think you need to. Less is probably more in this situation.
• Intuitive: Flowing from the above, wikis ought to strive to be intuitive in their organization. Pages should answer questions that people have, and then provide additional information out from there. One shouldn’t have to dig in a wiki for pages, if there are categories or some sort of hierarchy there pages there shouldn’t be overlap at the tips of various trees.

Strategies that flow from this are:

• In general, write content on a very small number of pages, and expand outward as you have content for those pages (by chopping up existing pages as it makes sense and using this content to spur the creation of new pages.
• Use one style of links/hierarchy (wikish and ciwiki fail at this.) You don’t want people to think: Should this be a camel case link? Should this be a regular one word link? Should this be a multiple word link with dash separated words or underscore separated words? One convention to rule them all.
• Realize that separate hierarchies of content within a single wiki effectively create separate wikis and sites within a single wiki, and that depending on your software, it can be non-intuitive to link between different hierarchies.
• As a result: use as little hierarchy and structure as possible. hierarchy creates possibilities where things can go wrong and where confusion can happen. At some point you’ll probably need infrastructure to help make the navigation among pages more intuitive, but that point is always later than you think it’s going to be.
• Avoid reflexivity. This is probably generalizable to the entire Internet, but in general people aren’t very interested in how things work and the way you’re thinking about your content organization. They’re visiting your wiki to learn something or share some information, not to think through the meta crap with you. Focus on that.
• Have content on all pages, and have relatively few pages which only serve to point visitors at other pages. Your main index page is probably well suited as a traffic intersection without additional content, but in most cases you probably only need a very small number of these pass through pages. In general, make it so your wikis have content everywhere.

… and other helpful suggestions which I have yet to figure out. Any suggestions from wiki maintainers?

My most sincere apologies to Virginia Woolf for the title.

We use a lot of git at work, and I’ve earned a bit of a reputation as “the git guy,” both at work and amongst the folks who read the blog. So, I suppose it should come as no surprise that a coworker (hi stan!) said “You should write something about using git when it’s just one person.” And I said “well sure, but it’s not nearly as interesting as you think it’s going to be.” He didn’t seem to mind, so here I am.

Lets back up for a second.

Git is a tool that programmers use to facilitate collaboration. It stores versions of computer code (and associated file) and save incremental sets of changes to those files, so that programmers can easily experiment with changes without destroying code, and so that teams of programmers (sometimes even large teams) can all work and develop on a single code base without stepping on eachothers toes, or duplicating efforts because you end up working on different versions of the code.

Git makes a number of innovations that make version control with git much preferable (at least in my experience) to other tools, but fundamentally that’s what git does. Git has all sorts of innovations that make it awesome: it’s fast, it can take “diverged branches” and merge them together painlessly and almost automatically. It’s great and mind bending, and I think really forces us to rethink all sorts of assumptions about authorship, and the coherency of “texts” in general.

But I’m famous for using git all alone, with just me. Here are the lessons and conclusions that I’d draw from my experiences over the past… two or three (or so) years of using git:

• Use fewer features. Git can do all sorts of funny stuff with branches and merges, but the truth is that when you’re working alone you don’t really want to have to much with branches. Because they’re the really novel feature (at least in terms of their usability) in git, everyone wants to use them but they add complexity, and there are other approaches to managing files and content with git that are probably preferable.
• Resist the temptation to store binary files in git. It’ll work, but you won’t be really happy with it.
• Even though you don’t need to have a remote repository to push your git repositories to, keep an off site repository in almost every case. You get incremental backups for free with git, and remote back ups are nearly free.
• Use a tool like gitosis (but it’s probably in your distribution’s repository and you should use that version) to manage repositories. It’s overkill for your use-case, but it makes things easier in terms of creating repositories. Perhaps consider something like girocco if you want even more overkill, and more web-based interface.
• There are git tools for most text editors and graphical tools that you may choose to use, but don’t, at least until you understand what’s going on behind the scenes. Learn git commands, and do stuff from the command line, as you’ll be much better (in the long term,) at fixing things as issues come up.
• If you need to maintain multiple machines, think of each machine as a collaborator, and it’s probably easiest to have a centralized group of repositories that you can push to in order to keep these machines up to date.
• If you’re using git to manage configuration files (which is great) I strongly recommend having a “sub-home” directory in a git repository with your configuration files with symbolic links pointing to the files in the repository. This strikes me as towing the balance between utility and control, without being a total pain the ass. As it were.

And that’s about it.

The background:

Sun Microsystems developed this file system called “ZFS,” which is exceptionally awesome in it’s capabilities and possibilities. The problem, is that it was developed and released as part of the Open Solaris project which has a licensing incompatibility with the Linux Kernel. Both are open source, but there is a technical (and not all together uncommon) conflict in the terms of the license that makes it possible to combine code from both licenses in a single executable.

Basically the GPL, under which the Linux Kernel is distributed, says if you distribute a binary (executable) under the terms of the GPL, the source code is all files that you used to make that binary. By contrast ZFS’s license says “here are all the files that we used to make this binary, if you change them when you make your binary and give that binary to other people you have to give them, but if you add additional files, you don’t have to give those out to people.”

Apparently the idea behind the ZFS license (i.e. the CDDL, and the MPL from whence it originated,) is that it allows for easier embedding of ZFS (and other technologies) in proprietary code because the resulting binary isn’t list covered by the CDDL in most cases. Even though the CDDL is incredibly confusing, apparently it’s more “business friendly,” but I diverge from my original point.

And so if Linux users want to run ZFS, they have to run it as a user-space process (i.e. not in the kernel,) which is suboptimal, or they have to run Solaris in a vitalized environment (difficult,) or something. There’s also a ZFS-like file system called “btrfs,” which can be included in the kernel (interestingly, developed by Oracle who of course now own ZFS itself,) but it is not production ready.

What I’m about to propose is an end run around the GPL. Because it seems to me that combining the source code violates neither license, distributing source code violates no license. Compiling the source code for your own use violates no license. I mean it’s annoying and would require a bit of bootstrapping to get a Linux+zfs system up and running, but this is the kind of thing that Gentoo Linux users do all the time, and isn’t a huge technological barrier.

It feels a bit creepy of course. but I think it works. The logic has also been used before. We’ll call it the “PGP loophole.”

PGP is an encryption system that’s damn good so good in fact, that when it was first released, there were export restrictions on the source code because it qualified as military-grade munitions in America. Source code. How peculiar. In any case there were lawsuits, and PGP source was released outside of America by printing it in a book. Which could be disassembled and scanned into a computer and then compiled. Books were never and--as far as I know--are not classified as munitions, and so they could be exported. Of course I’m not a lawyer, but it strikes me that linux+zfs and PGP in the 90’s may be in analogous situations.

And I think, because this proposal centers around the distribution of source code and only source code this kind of distribution is fully within the spirit of free software. Sure it’s pretty easy, even for the “good guys,” to run a foul by distributing a binary, but this would be easy to spot, and there are already suitable enforcement mechanisms in place, for the Linux kernel generally, and Oracle’s legal department which we can assume will take care of itself.

Or Oracle could release ZFS under GPL. Either solution works for me.

A reader (hi grandma!) asked me to write a post about why I’m so interested in open source, and who am I to refuse. In fact, I tend to do requests pretty well, so if there’s a subject you’d like to see me cover here, just ask and I’ll see what I can do. In any case, I’ve been involved, for varying definitions of involved, in Free Software and open source for a few years now. On a personal level, I use this software (almost exclusively) because I can make it do exactly what I need it to do, because it’s very stable, and because from an architecture perspective I understand how these systems work and that’s useful for me. Having said that, I think open source is important and worth considering for reasons beyond the fact that I (and people like me) find it to be the most important tool for the work we do.

When folks get together and say “I’m going to work on an open source project,” I think some interesting things happen. First, they’re making a number of interesting economic decisions about their work. There are business models around open source, but they are more complex than “I make software, you give me money for software,” and thus require people to think a little bit more widely about the economic impact of their work. I think the way that people view the implications of their labor is incredibly important, and free software presents an interesting context to think about these questions.

The second, and perhaps larger reason I’m interested in open source is the community. Open source developers often know that the things they want to create are beyond the scope of their free time and personal ability, so they collaborate with other people to make something of value and worth. How this collaboration happens: what motivates developers, how they create tools and technologies to support this kind of work flow, how the “intellectual property” is negotiated (particularly in projects that don’t use the GNU GPL,) how leaders are selected and appointed, how decisions are made as a community, and how teams are organized and organize themselves. These are intensely fascinating.

And these phenomena matter, both in and for themselves, but also as they impact and connect with other questions and phenomena in the world. For instance:

• I think that the decision making process in free software projects is instructive for thinking about how all sorts of communities can reach a “decision making fork” resolve it somehow and then continue with their work. Some open source projects have formal structures, and that is easier to understand from the outside, but most make decisions in an informal way, and that decision making process is potentially novel, I’d argue. In what other context do people have to construct projects outside of work.
• While leaders in the open source community are rarely elected (aside from a number of notable examples; the Debian Project Leader springs instantly to mind) most projects are very democratic. But this requires that we keep in mind a fairly broad definition of democracy. Because there isn’t a lot of voting, and sometimes decisions aren’t discussed thoroughly before people start doing things, it doesn’t look democratic. But everything is volunteer based, and leaders I think have a sense of responsibilities to their constituencies, which is meaningful.
• The tools that open source developers use are, unsurprisingly open source, and are often picked up and used by teams that aren’t making free software. I’m interested in thinking about how “ways of working,” proliferate out of open source and into other spheres. Is non-open source developed differently if the developers are familiar with and use open source tools?
• Similarly, I think I’m interested in thinking about how the architecture of Linux and Unix give rise to a thought about APIs and open standards in a way that doesn’t necessarily happen on closed platforms. After a certain point, I think I’m forced to ask: is GNU/Linux the leading free software/open source platform because it just happens to be, or because it’s UNIX. Is there something special about the design of UNIX that leads to openness, and the practices of openness? To what extent does the limitations of the environment (operating system here) the social conventions that are built on it?

And then beyond the specific questions--which are terribly important in and of themselves--open source present a terribly exciting subject for the study of these issues. There is so much data on the ground concerning open source: version control history, email logs, IRC logs, and so forth. Not only are the issues important but the data is rich, and I think has a lot to tell us if we (I?) can bother to spend some time with it.

I finished chapter eight of the novel that I’ve been working on for… Oh? Way. Too. Fucking. Long. And you want to know how I’m even comfortable asserting that I’m done with the initial draft of Chapter 8? I wrote an entire scene from Chapter 9 without saying “wow, I need another scene in Chapter 8 so that the story works out.” Because I’ve finished Chapter 8 at least three times, but this time I’m pretty sure. There are a couple of interesting, or at least quasi interesting factors that I think are worth some attention.

For starters, I made some progress on the novel. I know that I don’t have endless time to write fiction, and in addition to a day job that requires a bunch of my time and brain cycles, I write the blog, and work on other side projects: fiction, programming related things, the Cyborg Institute, dancing, singing, and occasionally sleeping. These are all projects that are important to me, and I think create value for me (and I hope in their own ways, you as well) so I don’t want to sound as if I’m complaining about being too busy and overextended (perhaps I am), but as a result I think I’m being pragmatic to accept a slower pace of development.

At the same time, damn I need to finish this thing. It’s good, I’m finally back in a place where I don’t hate the story, but at the same time I’m very aware that I’ve learned a lot.

And perhaps that’s the problem with taking so long to finish novels. Not so much that writing is a race, but if you aren’t able to pull it off in a reasonable period of time, say 12 months, or so by the time you get to the end, you know so much more about the way you work about how to put together stories, and how to write, that creating a cohesive work becomes an actual challenge. At least for me, the thing I probably want more than anything right now, is a chance to work on other fiction projects, to take the lessons that I’ve learned from writing this story and apply them to writing other projects. I have a great idea for a new story laying around in a text file, but I’m not touching it yet.

The two most important things about being a writer, as far as I’m concerned, are actually writing things (done!) and finishing things (at which I think I get a middling B). So just starting new projects at whim, isn’t exactly an option either. So in light of all this, what’s my strategy? Fairly simple…

I’ve set a recurring task in my org system to write 100 words a day on the novel. Just 100 words. And if I know it’s not going to happen I can mark the task as “skipped” or do it “late.” But the truth is that 100 words is the kind of thing I can do in only a few moments, so it’s not only a regular reminder to write, but also an eminently reasonable goal. Not only do 100 word segments add up (in a way that 0 word segments never do,) but the real trick is that in my mind I’m not trying to write very much, just enough to get started. If I don’t, at least I’ve made a little progress. If I do, then all the better.

In addition to the regular writing task for the fiction project, I’ve also started keeping a journal using this method. I’ve also created a recurring tasks for keeping the journal, and I find this method tends to have a positive effect on my productivity. To-do lists are great for remembering and prioritizing tasks when you have a lot of balls up in the air, but they often fail at tracking real life in a reasonable way. The journal provides a good way to keep track of, and recognize the importance of all the things that we spend time doing, but that don’t often have an opportunity to be captured into the to-do list before they get done. I think of it as a sort of inverse-to-do list.

It doesn’t always work, of course. There are days when I don’t get to either one of these tasks, and there are some days where I catch up on one or the other of them. But it’s a good practice, and I focus on the things that are important: actually producing something and then also building and maintaining a habit.

Because I don’t know how else things get done. Not that I’d be unwilling to listen if you have a better solution. See you in comments…

Ok, confession time, I don’t really get object orientation. So in an effort to increase my understanding, I’m going to write some overview and discussion in an effort to understand things a bit better. Hopefully some of you will find this helpful. I’ve tinkered with programing for a long time. I read a huge chunk of a popular Python introductory text, and I’ve read a chunk of Practical Common Lisp, but people start talking about objects and I loose track of everything. I think there’s something slightly unconventional--at least initially--about object orientation.

We understand procedural programming pretty easily. There’s a set of steps that you need to perform, and you tell the computer what they are, and then data gets handed off to the program, it runs, and the steps are performed at the end. Or, conversely, someone calls your program and says “I want data” (perhaps implicitly) and the program says “ok, to go get data, I need to do these things,” and then it runs and at the end you see data.

Object orientation turns this sort of sideways and says “lets build a representation of our data (objects) then write code that says what happens to those objects.” Ok, that almost makes sense, data happens to your program and you write code to provide behaviors and responses to all of the things that will happen when your program runs. So you feed objects (data) into your program it does its thing in response to those objects and different data (probably) exists on the other end.

I hope I haven’t lied yet! To continue…

The thing that always confused me, given my utter lack of background is this whole “methods,” and “classes,” thing that programmer types launch into almost immediately. To overview:

Objects as I said above, are just another way to think about data. It’s a “thing,” that the program has to deal with. Classes really just represent the structure of a program. We hear “objects are instances of classes,” but this feels sort of backwards, it feels more intuitive to say that classes provide a framework for interacting with objects: they describe the loose “shape” of their objects and then create a place for behaviors to exist. Methods, then, are those behaviors. Often methods “belong” to classes (either literally in the structure of the code, or just conceptually) and they define what happens to objects as the program runs.

Thus the role of an object oriented runtime (or compiler? I think that’s the right word for the program that executes the program,) is to take data that comes in, figure out what class (or classes) the object “fits into,” and then apply the methods that belong to that class.

Whew! So, how’d I do?

Assuming my understanding is correct, allow to offer the following analysis:

• By using multiple methods, in given sequence you can reuse code within a class, rather than needing to define and redefine a set of increasingly complex procedures.

• At the same time there’s a much higher start up cost for object oriented code. Because we think about getting things done in programs we--or I--tend to think in terms of procedures, rather than objects, it takes a bit of extra brainpower to do the object oriented way. And for most tasks--which are pretty small--creating classes and creating methods seems like a lot of stuff to have to hold in your head when you’re figuring out what needs to done?

  It sort of seems like, in order to do object orientation right, you have to already know what has to happen in the program. Otherwise, classes fail to properly describe the data/methods that you need.

• Ok, so now that I, more or less, understand what’s going on here, might we be better off calling it class-oriented programming? Or “class-centered” programming?

Thoughts?

A few years ago, at a Morris Dance weekend, I saw a woman sitting in one of the common rooms obviously struggling with a piece of knitting. I helped her figure out something, and then went back to singing or whatever it was. When I returned to my chair the experienced dancer sitting next to me assumed I was the student and said, “Getting a knitting lesson, eh?”

And I chuckled in between choruses and said “Not really, I’m an even better knitter than I am a Morris dancer.”

Impressed he said “Wow, and you’re a pretty good Morris Dancer.”

Which was an utterly delightful thing to hear, particularly from this chap. I’m an ok Morris dancer, and--particularly then--I tend to use youth as a compensation for skill. And I don’t knit as much now I as used to, and while I don’t know all there is to know about knitting, not by a long shot, I’m pretty good. I’ve been knitting for 8 years, or so and the thing that’s keeping me from knitting these days is time, and the fact that I live in a pretty warm climate at the moment. I never see something knitted and think “wow that’s too hard for me.” In a lot of ways, I think I’ve mastered knitting.

In some ways that’s kind of cool. It’s nifty to be able to think about something and say, “yes! I can do this.” And at the same time, I can’t help but have a little bit of regret for the fact that I spent so much time figuring out how to do something that I can’t really use most of the time: I don’t live in a climate that really calls for woolens most of the time, I don’t have any real interest in being a knitwear designer, and I consistently have trouble finding time to knit amongst all of the other things that I find myself committed to.

Speaking of which, I’ve certainly committed myself to other things. The dancing, I’ve spent a lot of time dancing and learning how to be a better dancer. And it’s sort of paid off. I’m not great, and I fake my way though far too many things, but I feel competent, and I’ve gotten some pretty good feedback. And that’s awesome. While it’s fun and socially fulfilling--and that’s good enough--at the same time I’m not sure if it gets me anywhere in particular. I don’t really want to play music, and I’m not a very good teacher of dance.

I am incredibly grateful that I started dancing when I was in high school. I don’t know if I’d have been able to pick things up as easily without those experiences. As with knitting in college, the early and intense experiences gave confidence and enough base-skill to make mastery a possibility. Had I started not when I did, I don’t know that I would have had the patience, confidence, or persistence as a(n albeit-young) adult to learn the things that I do automatically. I can’t really fathom it.

Which brings me to writing. And I don’t even have a clue what to say there. I’m pretty good--I mean, I definitely have the persistence nailed--but I have no delusions that I’m a great writer. I’ve been writing forever, and I’ve definitely been in situations where I’ve had to edit other people’s work and thought “wow, my prose may be flawed, but at least it isn’t that.” I wonder why writing is different then, at least for me. Am I a better dancer/knitter than I am a writer? Is it simply easier to critique writing than it is to critique a sweater or ones ability to dance socially? Is the fact that one some level the production of text has economic baggage in a way that a waltz so rarely does?

My own angst aside, I was talking with a longtime reader of the blog about employment and changing careers and about figuring what your skills and assets are. Because the transition from “I know how to knit sweaters and write things and dance,” into “I have a job writing about Linux-based systems administration,” isn’t the kind of thing that makes sense immediately.

But when you dig, I think it does: it turns out that writing knitting patterns in a the narrative/Elizabeth Zimmerman-inspired way that I do/did, is very much like process for writing about systems administration tasks. And I think dancing gives you the ability to be nimble and quick, not just physically (which may be of limited use more generally,) but also in social situations. Fixing a contra dance line that’s gone awry in the middle of the line has transferable skills. We hope, at least.

The challenge is in making those connections is difficult, and figuring out how to calculate the value that these skills might provide to the world. And isn’t this always the case?