I’m sorry that I’ve not posted here very much recently and also that the links in this post will be pretty unadorned. I’ll make up for it with table of contents:

::: {.contents} :::

Ok, so it’s not much, but lets get started.

New Posts

While my posting volume has gone down, I have posted something since the last update post.

• /posts/teaching-writing-skills
• /posts/is-dropbox-the-mobile-file-system-standard
• /posts/why-you-dont-want-programers-to-write-your-documentation
• /posts/remote-accessibility-reverse-tunneling-super-dynamic-dns

Rest assured that there’s more stuff in the pipeline.

Lost Posts

For some reason, that I haven’t figured out and don’t really care to, for a number of months, my posts from July of 2009 went missing. Usually this wouldn’t even be worth mentioning, except I July of 2009 was a big month for me writing wise--I’d just moved to the east coast, I had my first real tech job and my mind was full and I felt on fire. I consider a couple of these posts to be “tychoish classics.” The good news is I’ve found them, so here they are:

• /posts/are-web-standards-broken
• /posts/distribution-habits-and-change
• /posts/fa-sol-la
• /posts/infrastructural-commerce
• /posts/multiple-computers-and-singular-systems
• /posts/my-workstation-choices
• /posts/new-workstation-trials
• /posts/on-package-management
• /posts/on-public-key-encryption-and-security
• /posts/org-mode-pitfalls
• /posts/personal-desktop
• /posts/personal-desktop-2
• /posts/stars-in-my-torchwood-pocket
• /posts/technology-as-infrastructure-act-one
• /posts/technology-as-infrastructure-act-two
• /posts/technology-as-infrastructure-act-three
• /posts/the-blog-is-dead-long-live-the-blog
• /posts/why-arch-linux-rocks

They seem to be arranged alphabetically rather than sequentially, Sorry about that!

Contra Dancing Feature

A contra dancing friend of mine solicited an email from me a few weeks ago about a couple of contra related topics, which have worked their way into posts that you can read below.

• Part one: Gender Swaping
• Part two: Improv Contra

The Internet is A Cool Place: Tablet/Cloud Computing

I found the following link on twitter from a few of my awesome (former) coworkers. It’s a blog post about a programmer who is using an iPad, a remote server, and a computer to do all of his work. read more

It’s an interesting possibility, frankly and I could probably make the shift easily enough if I wanted. Having said that, I feel like I’m a little too sensitive to TCP/SSH hiccups and I feel weird throwing all of my (potential?) productivity into something totally network dependent.

An Emacs Tip Interlude

I picked up the following little bit of emacs configuration, that I think is wicked cool. It removes some of the limitations on m mini-buffers, which gives them a lot of pretty cool features. It seemed like the kind of configuration that I should have known about and didn’t, so maybe some of you don’t know either.

(setq shell-command-default-error-buffer t)
(setq enable-recursive-minibuffers t)

Git, not Hypertext, Is the tool by which we experience becoming Nomad

I’m not entirely sure why I’m following Stephen Ramsay on twitter, but I am. The other day I saw the following exchange, and I feel like it’s worth recording:

<sramsay> Back in the day, it was fashionable to say that hypertext
  enacted certain theories associated with postmodernism (Deleuze, etc.)
<sramsay> We had it totally wrong.  *Git* is the tool
  by which we experience becoming nomad.

I love this idea, and I’ve been saying variants of this for a while, but it’s nice to get reinforcements. At the same I think it’s possible to easy to loose sight of how git is actually used of git when focusing on its transformative aspects. Which makes the theory read a little more hollow.

Onward and Upward!

I have a question for my system administrator readers. And maybe the rest of you as well.

I run a web server on my laptop that hosts about 8 test sites. Nothing special: mostly test and development sites for various public sites, but from time to time I think, “shit, wouldn’t it be nice if I could just give someone a link to this.” My solution is generally to copy whatever it is that I’m working on up to the server that runs this website, and while that generally work just fine, it could be better.

So here’s what I’m thinking:

I’d like to be able to hook my laptop up to the internet and be able to let people access (some) of the content running on this web server. I don’t want it to be automatic, or open my entire machine to the world (though… I could secure it, I suppose.) The options I’ve considered.

• I set up a VPN that I can connect to the public server (that hosts this website) from the laptop, and I have a virtual host (or set of virtual hosts) that proxy requests to the laptop. Wherever I am, it works. I’m not worried about the bandwidth or the strain on the server given the usage pattern I’m expecting.

  • Pros: Simple, Secure, works even if I’m on a weird local network. Potentially useful for other kinds of nifty hacking including tunneling all traffic through the VPN on insecure connections.
  • Cons: Way complex, and I’m not sure if it will work. I’ll need to set up VPN software. And it’s total overkill.

• Some sort of scripted dynamic DNS solution, probably involving running my own DNS server.

  • Pros: less proxy madness. Pretty simple.
  • Cons: running a DNS server. Won’t work on some (most) local networks.

• There has to be some sort of alternate approach using a minimalist tunneling solution. There are a few of them, I think they’re nifty, and it would probably be perfect. I’m just not sure what it is.

  …and then half the night later, I finished deploying the VPN. I have to say that I’m really pleased with it:

• It can (and has) replaced my ssh tunnels for sending email. That’s pretty great.

• The web server stuff works, though I don’t have anything really up there yet. I feel like I need some sort of access restriction method, but I don’t really like any of the options. HTTP Auth is annoying rather than protective, SSL is terribly imperfect and fussy, host based control isn’t very tight.

• I think I will be able to finally sacrifice a laptop to the “homeserver” because aside from dis/re-enabling the “sleep on laptop close” function. If needed it’ll be dead simple to convert a sever laptop to a mobile laptop.

Thoughts?

All of my friends who have taught composition are appalled when they hear me say that I want to teach writing. But it’s true: I would be interested in having the opportunity to give people the kind of writing education that I never got to have. I’ve even collected a few of these ideas on a very rough “pedagogy” page. This post, by contrast, will be a list of “things I wish I could have learned before I got a job writing.”

• How to write in long form. The skils and process for writing something that’s a hundred pages is fundamentally different from the process for writing pieces that are a few hundred words or a few pages. Project management, planning, and organization are totally different skills.
• Working with editors. In school, the editing process is very conversational. Editors, comment and ask you to make changes if agree with their judgment. Writers need to learn how to gather requirements, write the best possible content, and then hand it over to an editor who will modify the text without comment. Not only is it important to learn how to “get over this,” but also in how to learn from this kind of editing
• How to revise work. While I’ve learned to avoid making a number of mistakes to which I’m particularly prone, and spot those errors when the slip through, it’s really the process of applying for jobs that has taught me how to revise my own writing. Revision is probably the hardest writing skill, and I think there are probably better ways to teach revision than some sort of idealized “drafting process.”
• How to write at volume, even when you’re not feeling inspired. We’re pretty good at teaching people to write when they’re inspired or have done a lot of research. But writing Writing needs to be as instinctive as speech and the kind of thing that you don’t need to be inspired to be able to do. Not because anyone writes that much, but it’s a comfort thing.
• How to document things. Which is to say, how to record a practice, wprocedure, or interface, to tell people (and your future self,) how to do something. I had to figure this out on my own, and I think people would be much better writers for being 10% worse at writing essays and 10% better at writing processes.

That would do it! I’ve included some work in this direction in the pedagogy page, but comments, are always valuable.

I’ve started using Dropbox on my Android devices recently (and my laptop as a result,¹) and I’m incredibly impressed with the software and with the way that this service is a perfect example of the kind of web services that we need to see more of. While I have some fairly uninteresting concerns about data security and relying on a service that I’m not administrating personally, I think it’s too easy to get caught up the implications of where the data lives and forget what the implications of having “just works,” file syncing between every computer.

I used to think that the thing that kept mobile devices from being “real” was the fact that they couldn’t sell “post-file system” computer use. I’m not sure that we’re ready to do away with the file system metaphor yet. I think Dropbox is largely successful because it brings files back and makes them available in a way that makes sense for mobile devices.

The caveat is that it provides a file system in a way that makes sense in the context for these kinds of “file systemless” platforms. Dropbox provides access to files, but in a way that doesn’t require applications (or users) to have a firm awareness of “real files. Best of all, Dropbox (or similar) can handle all of the synchronization, so that every application doesn’t need to have its own system.

This might mean that Dropbox is the first functionally Unix-like mobile application. I think (and hope) that Dropbox’s success will prove to be an indicator for future development. Not that there will be more file syncing services, but that mobile applications and platforms will have applications that “do one thing well,” and provide a functionality upon which other applications can build awesome features.

This isn’t to say that there aren’t other important issues with Dropbox. Where your data lives does matter, who controls the servers that your data lives on is important. Fundamentally, Dropbox isn’t doing anything technologically complicated. When I started writing the post, I said “oh, it wouldn’t be too hard to get something similar set up,” and while Dropbox does seem like the relative leader, it looks like there is a fair amount of competition. That’s probably a good thing.

So despite the concerns about relying on a proprietary vendor and about trusting your data on someone else’s server, data has to go somewhere. As long as users have choices and options, and there are open ways of achieving the same ends, I think that these issues are less important than many others.

So the documentation sucks. Hire someone to make the documentation suck less.

Simple enough, right?

Right.

Just don’t hire a programmer to write documentation, even though this seems to be a pretty common impulse. There are a lot of reasons, but here are some of the most important from my perspective:

• Programmers focus on the code they write, or might write, to be able to describe and document entire projects. It’s really hard to get programmers to approach documentation from the biggest possible frame.
• Programmers have a hard time organizing larger scale documentation resources, because they approach it as a database problem rather than a cognitive/use problem.
• Programmers solve problems by writing code, not by documenting it. You can push programmers to write notes and you can push the best programmers who can write to work on documentation; but unless you dedicate an engineer to writing documentation full time (which is a peculiar management decision) documentation will always come second.
• I’d wager that every organization large enough to have documentation that sucks is probably large enough to have enough documentation for a full time technical writer.
• Engineers, particularly those who are familiar with a piece of technology, do this really interesting thing where they explain phenomena from the most basic assumptions prompted to describe something, but regularly skip crucial steps in processes and parts explanations if they think they’re obvious.

Interesting cognitive phenomena do not make for good documentation.

What am I missing?

I went through a few days ago to collect all of the updates and work that I’d done since the last time I did one of these posts. Sometimes just looking through an activity log is all you need to remember that you’re actually doing something. Here’s what I’ve been working on:

• isd" is a developing page of material for my ongoing story project. I’ve written it in my “Wiki Fiction” post. This particular page is basically sysadminning-punk, if I may be so bold. The story as a whole is largely a future history of human’s expansion into the solar system and beyond, using Kim Stanley Robinson’s idea of Accelerando. This piece in particular is all about the emergence of an asynchronous database network that eventually replaces the Internet as we know it, because interstellar distances render trans-planetary TCP (in any form) unworkable. I’ve got an outline and I’m slowly working to fill in the blanks. Editing, ideas, and any amount of text are all welcome.
• I added a page to the technical writing section on “Why the Documentation Sucks,” and I’ve done some additional editing and revising of this section of the wiki. The /technical-writing/documentation-sucks page has also served as the foundation of my post about documentation publishing systems.
• I’ve added a number of new posts that I hope won’t be forgotten too quickly. They are:
  • Is Android the Future of Linux
  • Advice for Blogging Successfully
  • :Issue Tracking and the Health of Open Source Software
  • Tablet Interfaces and Intuition
  • Org Mode and Mobile Writing
  • Publishing System Requirements
  • Android Tablets and the Workstations of the Future
• There has also been some discussions of new and old rhizomes on the discourse pages.
• A few weeks ago I posted a few new scripts in the code section. Tell me what you think:
  • ikiwiki tasklist
  • download mail
• My post, 9 Awesome SSH Tricks from March 2011, spent a number of hours on the front page of hacker new. You can read the comments over there, and probably on some other sites as well.

The coolest part about this is that some of you have helped to build a page of ssh tricks on the wiki that go above and beyond the little tricks that I use.

And finally,I ’d like to welcome Kevin Grande, who made a new folk page recently. I’m also very sorry that I haven’t been updating more frequently. I started a new job on September 26, and between that and my usual gallivanting around for singing and dancing my blogging habit has. One the other hand I’m writing about 1200 words a day, and life is pretty good so no complaints there.

Onward and Upward!

The ideal writing application is emacs, at least for me. In the absence of emacs (as on a tablet,) I’ve been thinking about what features I actually need in a writing application. While I’ve grown to admire the power of a full Lisp machine in my text editor, I accept that it’s not, strictly speaking required. Here’s a first stab at the list of requirements. Feel free to comment or submit a patch to this page.

• Simple, primarily full screen editing.
• The ability edit very large files, 100kbs should present no issue.
• Some sort of syntax highlight during the editing process, preferably support for LaTeX, Markdown, and org-mode.
• Word count generation for the entire files and for current selections.
• Auto-save as crash protection.
• Undo/Redo last typing action.

Nice to have (but not crucial) features:

• The ability to edit one file and reference another (or potentially edit) at the same time. Bonus points for being able to switch between to parts of a single file at once.
• The ability to hide or collapse some sections of a file.
• Optional spell checking.
• Parenthetical and double-quote matching.
• Soft and hard line/word wrapping.

Other than that I don’t think there’s anything that I really need to have to get writing done 90% of the time. How about you?

I’ve only had the tablet for a few weeks, but I’m pretty sure the tablet incarnation of Android is probably 80% of what most users need in a workstation. I’m not most users, but I figure: hook up a big screen and a real keyboard. Create some key bindings to replace most of the gestures, and write a few pieces of software to handle document production, presentations, and spreadsheets in a slightly more robust manner, and you’re basically there. I wouldn’t give up my laptop today for a tablet, and I think the platforms still have a ways yet to go, but that’s not insurmountable.

Prediction: in the next decade, we’ll see embeded tablet-like devices begin to replace desktops computers for some classes of use and users. General web surfing, reading, quick email, and watching videos on YouTube seem like the obvious niche for now. I started to explore this in “Is Android the Future of Linux,” but it’s not abusrd to suggest that Android or iOS like devices might begin to address more “general purpose desktop computing.”

I want to be clear: we’re not there yet. These systems aren’t versatile and fully featured enough to keep up with full time use on an extended basis. This is mostly an application/software problem. As applications evolve and as more functionality moves to remote systems anyway (this is the “cloud,” we’ve heard so much about,) tablet operating systems will seem much more capable for general purpose work. Better mobile productivity software will help as well. Eventually, I think Android and similar platforms will have a shot at the desktop market for most usage because:

• IT departments will get a lot more control over intra-organization information flow, which could save a lot of money for various IT categories: administration, support, and data protection costs.

• Behind the firewall dropbox-like services, and creating some sort of centralized workstation configuration management (which makes sense for a flash based device,) means backups can happen automatically, and if devices need to be re-imaged or are lost or damaged, it only takes a few minutes to get someone back to work after a technology failure.

• Limited multi-tasking ability will probably increase productivity.

• Disconnecting keyboards from the screen will probably lead to better ergonomic possibilities.

• Eventually, it will be easier to integrate Android-like devices with various workflow management/content management systems.

  The technology needs to mature and workers and IT departments need to become more comfortable with tablets, without question. Also, there are some fundamental developments in the technology that need to transpire before “desktop tablets” happen, including:

• More power user-type interface features.

• Split screen operation. There are enough “common tasks” that require looking at two different pieces of information at the same time that I think tablets will eventually have to give up “full screen everywhere,” operation. Conventional windowing is unnecessary, and I don’t think anyone would go for that, but displaying two different and distinct pieces of information at once is essential.

• Better “Office” software for spreadsheets, presentations and document preparation. A necessary evil.

• Behind the firewall (preferably open source) solutions to replace services like Dropbox/Box.net and whatever other services emerge as essential parts of the “tablet/smartphone” stack.

• VPN clients and shared file system clients that are de ad simple to use. I think these are features for operating system vendors to develop.

Thoughts? Onward and upward!