Topic: Cyborg

This post is the culmination of two things:

1. Who wants to be a PHP Developer?

2. An ongoing conversation I've had with a number of coworkers about the substandard technologies that always seem to triumph over the "better" options.

The examples of the success of inferior technologies are bountiful. MySQL's prevalence despite some non-trivial technical flaws (around clustering, around licensing as highlighted by the Oracle merger); PHP as the de facto glue language of the web despite the fact that every other language in it's class is probably a better programming language (e.g. Python, Perl); VHS and Beta Max; BlueRay (which are proprietary and a physically less durable media) and HD-DVD; and so forth.

The factors are (of course) multiple:

• Marketing.

People have to know about technologies at some stage in their development if the technology is to take off. I'm not sure what that crucial point is, and frankly marketing is something that not only I don't understand, but I don't really think anyone understands. Having said that, I think it's clear that technologies don't compete simply on their technical merits, and this is in recognition of that.

• Timing.

Technologies that appear at the right time, with regards to availability of alternatives and the needs/interests in the market on those technologies matter a great deal, and can sometimes tip the balance between competing technologies. Arguably MySQL beat PostgreSQL not because it was better, but because it existed in a firm way a little bit earlier. Linux "won" market share over BSD, because BSD wasn't quite fully free/open source (or available) in 1990-1992 when Linux was taking off.

• Momentum.

A project that doesn't look like it has energy and a large team behind it is probably doomed to fail on some level, not because it's a bad technology, but potential users of a technology need to feel confident that it's going to stick around. If no one is excited about it, then it'll never win, even if it's superior in the final analysis.

There's nothing, really, to be done. I think the truly superior technologies might benefit by paying attention to these factors when it matters, but then the developers of said technologies are probably less interested in marketing and proper timing than the competition. Which is perhaps as it should be.

I guess the lingering questions that I'll leave you with relate to thinking about the ways that open source and free software relate to other technologies. It strikes me that while there's a pretty good balance between open source and proprietary technologies in the examples I provided above, all of the open source technologies were commercialized very early on and very intensely in a way that none of their competitors really did. Are "wining technologies," a mystification of the proprietary technology world? Can community-based open source and free software technologies innovate and "win" in relation to their competitors?

I look forward to sorting out the answers in the comments. Onward and Upward!

So PHP is this programming language that's widely used, and often reviled by systems administrators and people who fancy theme selves "real programmers." And yet, I think, while the "real programmers" were busy being "real," PHP got something very fundamental right that explains its success despite the disdain.

I should interject with some context. First, I think this is another in my ongoing series of posts regarding linguistic relativism and computer programming. Second, for those of you who don't spend your days in this space PHP is a programming language designed specifically for use in the context of the web, and it has only comparatively recently emerged as a possibility for "general programming tasks," in contrast to other languages in "the space" (ruby, python, perl, etc.) which started as general purpose languages that have become common for use for web programming. Also as a computer language, there's nothing particularly innovative about PHP, which earns it no small amount of ire.

So here's the thing. PHP is easy. It's designed to be easy. The syntax is familiar to people who are know even a little Perl or other C-like languages. Although the language has had object oriented support for several years, most PHP applications aren't written in an object oriented manner and in a number of contexts that makes things a bit easier to understand.

And here's the thing that I seem to notice in the context of administration: compared to other languages and frameworks, PHP is dead simple to deploy. Sure, everything under big loads becomes complex, and sure PHP applications consume more server resources than perhaps they should, but basically you configure a web-server to process PHP code, and then you write your code, inside of your page, and the web server generates what you need it to, and it just works. You don't have to screw around with writing boilerplate CGI stuff, you don't have to screw around with cgi-bins/ and script aliases which were never intuitive, you don't need special servers, it just works.

And I already know that, someone is going to tell me that there's a Perl module that lets you use perl in the same way, or that Python and Ruby don't make you write CGI boilerplate either (or that there's a Perl module to write the CGI boilerplate). And I know these things, but I'm not sure that it matters anymore. PHP, as a language is written around the needs of web development, and there's merit in that.

I'm not saying, "go forth and write your next application in PHP:" I don't even know if dynamic web applications are worth writing anymore. I am saying that despite all of the dreck in the PHP space, there are some things that are incredibly worthwhile that the current generation of web developers may miss.

That is all. For now. Onward and Upward!

As if I needed a new project, this post introduces a new project that's floating around in my mind. I was having a conversation with a friend about how I use the computer, I realized that while I've talked about various elements of how I use computer's (the short story: peculiarly), I've not really talked about the holistic experience. As I started to talk about the various components and how they connect and work together, I realized that with out an example it was about as clear as mud.

So, in light of this, I've decided to make a "tychoish stack," which won't be anything particularly novel, but a repackaging of the software--mostly configurations and little bits here and there--that I use on a daily basis. My stumpwm configuration. The highlights of my Emacs configuration, and a few install scripts to make it all work together. An SSH configuration file that will make your life much easier, a list of packages that you'll want to install on common operating systems (Debian/Ubuntu and Arch Linux), and--because I am who I am--a fair piece of writing about best practices and how to these tools effectively.

---

I was talking with Chris the other day in one of our never ending conversations regarding is ever changing choices of desktop operating systems. "Windows just feels more polished to me right now," he said after a stint with the latest Ubuntu or one of its derivatives.

To which I said, "of course it does," they pay bunches of people lots of money to make sure that Windows is polished and it's a high priority given the failure of Vista and the direction of the market. The reason I use Linux full time is not because I want a better more polished experience, I use Linux full time, because I want something very specific: a window manager that stays out of my way and doesn't distract me with "chrome," emacs buffers that run in the way that I expect them to, package management tools that allow my system to work and function day in and day out, the ability to customize all of these functions to suit the evolving needs of my work, and nothing else that I have to mess around with.

This is something that I can only get from a UNIX system, and the more I play with different systems, the more I'm inclined to think that the only way to get this is with Arch Linux. But that's just me. I've played with a bunch of different operating systems (that's an aspect of my day job) and I've spent time using OS X, and it just doesn't work for me. I don't need smooth, I don't want polish, I just want something that lets me work.

Different computer systems make sense for different people. There's no problem with that assertion, I think.

---

The problem of course, that my setup doesn't scale. I can go from a bare arch installation to a working version of my system in a few hours by using rsync to copy over my home directory, updating a few git repositories, installing a list of packages, and creating a half dozen symbolic links, but building this from the bottom up would take a long time.

The goal of this project then, is to make that process easier. I've done a bunch of work to get a setup that does what I need it to do, I know which applications work, I know how to plug everything together to make it easier to manage. I want to build a stack so that you all can take it, learn from what I've done, and spend the time customizing it to what you do, rather than going through the trouble of building it up yourselves.

How's that sound?

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, [1] and while difficult the community building aspects of wikis are straightforward. [2] 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?

[1]	There are a number of very simple and lightweight wiki engines, including some that run in only a few lines of Perl. Once we had the tools to build dynamic websites (CGI, circa 1993/1994), the wiki became a trivial implementation.

[2]

The general Principal of building a successful community edited wiki is basically to pay attention to the community in the early stages. Your first few contributors are very important, and contributions have to be invited and nurtured, and communities don't just happen. In the context of wikis, in addition to supporting the first few contributors, the founders also need to construct a substantive seed of content.

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.

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've had a tab open for most of last week for a 128 gig solid state hard disk that would fit my laptop, and that had a list price that I was comfortable with, and a maker that I tend to consider reputable. I haven't ordered if for a number of reasons (not ready to swap drives, I'm using the wrong kind of file systems, given that my current drive works fine it's a bit more than I want to spend at the moment.) But the fact that these things are "affordable," and cost half what I thought they did, I've been thinking about my current stable of gear. This is, as those of you who think about technology in a way similar to me, not surprising. Here's what's on my mind in terms of new gadgets:

Netbooks, the small laptops are awfully sexy and I kind of want one. This isn't logical: my real laptop is both small (12 inches,) has a full sized keyboard, decent resolution, and is totally functional: I use it for everything from the writing and production of this blog, to most of my day job, to all of my entertainment computing. I take my laptop everywhere, so a notebook doesn't make a lot of sense. Also the relative (and ongoing!) cost of maintain a full "tycho-stack" on more than one machine is difficult and not something I want to get into. This doesn't mean that I don't find all the netbooks extremely cute and desirable but I don't really need one. I suppose the interest in the SSD is part of an effort to make the existing laptop into more of a netbook.

Also on the stack I'm approaching the time in my cell phone contract when it's time to upgrade again. I've been debating the Nokia N900 for some time. Though I've not played around with the n900 I think all of my "I wish my phone could do X," problems could be solved by using a phone that actually uses Debian. Except I've learned in the last week that the screen on the n900 is resistive, like all of the old Palm Pilots (say,) and not capacitive like the iPhone/iPod Touch/Android phones. Big bummer. Not only is the phone not subsidized, and expensive, but it uses outmoded technology for the most important component. Fail.

At the same time it looks like Android phones are finally starting to make it to ATT. I'm not a good candidate for the iPhone (not being a reliable Mac User) and while I'm not sure about the enduring possibilities of the Android Platform, it seems like the best option at the moment.

I like my blackberry, really, but the replacement for the blackberry I have at the moment? The same phone. Really. Well, I think it has a different model number and a slightly different trackball, but otherwise, it's the same. I mean... Throw me something here? Upgrades are supposed to be upgrades. I wonder if Blackberry smart-phones are today's Nokia S60.

In any case, dithering about cell phones, netbooks, and SSDs aside, nothing else in my technology stable needs changing really. I geeked out a few weeks ago, and reorganized some of my mail config (but not much of it!), and I think if I had free time, I might redeploy the server to use nginx and prosody which are a bit more lightweight that my current stack, but that's all minor and will totally wait. It's a good place to be.