Status Update

Ok, a confession: I totally ran out of my usual backlog of blog posts, that keeps these pages humming with the signs of life despite the fact that I don’t have time to write a post every day, and often don’t have reliable weekend time to write blog posts. This hasn’t happened in a few months, so it’s sort of disconcerting. One of the reasons why I ran out, is that I’ve been busy doing non-writing things for a few weekends, but a third (or forth?) weekend away from home was too much for my backlog to bare, so here we are.

Here’s a brief overview of what I’ve been up to and the kinds of projects I’m working on, and what the near future holds:

• I’m going to Dance Flury in a couple of weeks. I’ve not done the usual dance weekend thing before, aside from the Morris Dance gathering I’ve been going to for years. I’m really looking forward to it.

• I’m trying to get a better handle on the blog. I do this binge cycle thing with my blog posts, that leads to situations like the one that I’m currently experiencing, but also doesn’t actually mean that I have spare time to write fiction in a way that I might like.

• I’m working a bunch, and while every day is some kind of learning experience, I think I’ve figured out (largely) how to do what I do in a way that doesn’t have me leaving every night feeling like a fraud. There will be more learning curves, for sure, but it’s nice to not feel like I know what I’m doing.

• I’ve been throwing around the idea of writing poetry (hynms) vaguely in the tradition of the sacred harp. I’m not much of a poet, and the project I have in mind is a little bit peculiar (but then, this is me we’re talking about, so lets not be too surprised.) At the same time I’m irrationally interested in this project, and we’ll see how it goes.

• I switched to using Chromium as my primary browser. There are still a few plug-ins that I really liked on Firefox that aren’t quite as awesome or comfortable in their Chrome-equivalents, but it’s close and I’m sure it’ll get there. I’ve been looking for a viable non-Mac WebKit browser for a while, and am pretty happy with the Chrome.

• Check out git for writers, wiki page that I’ve been working on over at wikish to try and explore how writers use and might use the git version control system to manage their writing. Contribute if you like.

• This weekend (yay! snowpocolypse) I hooked up my laptop to my desktop rig, and have basically abandoned my desktop as a machine that I will interact with directly. (I’m a server guy, so it’ll get used.) This means I’m using xrandr with StumpWM (pretty swank,) and I must say that I love it. While I adore my laptop, and I really like only having to manage one computer, having this “desktop” setup makes it really perfect: I’m often most comfortable in desk chairs and I like the bigger screen and a real keyboard. So it works well. At some point I’ll write up a more thorough account of how I hacked this together.

Ok, this document has been open on my desktop for a few day and I don’t have anything new to add to it, so lets call it done.

Onward and Upward!

Putting the Wires in the Cloud

I’m thinking of canceling my home data connectivity and going with a 3G/4G wireless data connection from Sprint.

Here’s the argument for it:

• I’m not home very much. I work a lot (and there is plenty of internet there), and I spend about two thirds of my weekends away from home. This is something that I expect will become more–rather than less–intense as time goes on. It doesn’t make sense to pay for a full Internet connection here that I barely use.

• My bandwidth utilization is, I think, relatively low. I’ve turned on some monitoring tools, so I’ll know a bit more later, but in general, most of my actual use of the data connection is in keeping an SSH connection with my server alive. I download email, refresh a few websites more obsessively than I’d like (but I’m getting better with that), and that’s sort of it. I’ve also started running a reverse proxy because that makes some measure of sense.

• I find it difficult to use the data package on my cellphone. The fact that I get notified of all important emails on my phone, has disincentivized me from actually attending to my email in a useful way, and other than the occasional use of googlemaps (and I really should get an actual GPS to replace that…) If I get the right Wireless modem, however, it would be quasi-feasible to pipe my phone through the wireless Internet connection, so this might be a useful clarification.

The arguments against it are typical:

• The technology isn’t terribly mature, or particularly well deployed.

• Metered bandwidth is undesirable.

• Sprint sucks, or has in my experience, and the other providers are worse.

The questions that remain in my mind are:

• How well do these services work in moving vehicles? Cars? Trains?

• How much bandwidth do I actually use?

• Is this practical?

Feedback is, as always, very much welcomed here. I’m not in a huge rush to act, but I think it makes sense to feel things out. It also, I think posses an interesting question about how I (and we) use the Internet. Is the minimalist thing I do more idealistic than actual? I know that we have a pretty hard time conceptualizing how big a gigabyte of data actually is in practical usage. Further research is, clearly, indicated.

Edit: This plan would have to rely on the fact that I might be spending a large amount of time in a city with unmetered 4G access with sprint. I’ve used a gig and a half of transfer to my laptop’s wireless interface in 5 days. I think that would coincide with when I would be doing the heaviest traffic anyway. I wonder how unlimited the unlimited is…

Decreasing Emacs Start Times

One oft made complaint about emacs is that it takes forever to start up, particularly if you’ve got a lot of packages to load it can take a few seconds for everything to start up. In a lot of respects this is an old problem, that isn’t as relevant given contemporary hardware. Between improvements to emacs, and the fact that computers these days are incredibly powerful, it’s just not a major issue.

Having said that, until recently an emacs instance took as much as 7 seconds to start up. I’ve beaten it down to under two seconds, and using emacsclient and starting emacs with ”emacs --daemon” makes the start up time much more manageable.

Step One: Manage your Display Yourself

I’ve written about this before, but really even a 2 second start time feels absurd, if I had to start a new emacs session each time I needed to look into a file. ”emacs --daemon” and emacsclient mean that each time you “run” emacs rather than start a new emacs instance, it just opens a new frame on the existing instance. Quicker start up times. It means you can open a bunch of buffers in one frame, settle into work on one file, and then open a second buffer and edit one of the previous files you opened. Good stuff. The quirk is that if you’ve set up your emacs files to load the configuration for your window displays late in game, the windows won’t look right. I have a file in my emacs files called gui-init.el, and it looks sort of like this:

  (provide 'gui-init)

  (defun tychoish-font-small ()
    (interactive)
    (setq default-frame-alist '((font-backend . "xft")(font . "Inconsolata-08") 
          (vertical-scroll-bars . 0) (menu-bar-lines . 0) (tool-bar-lines . 0)
          (left-fringe . 1) (right-fringe . 1)
          (alpha 86 84)))
    (tool-bar-mode -1)
    (scroll-bar-mode -1)
  )

  (if (string-match "laptop" system-name)
      (tychoish-font-big))

Modifying, of course, the system name, and the settings to match your tastes and circumstances. The (if) statement allows you to have a couple of these -font- functions defined and then toggle between them based on which machine you load emacs on. Then in your init file (e.g. .emacs), make sure the first two lines are:

  (setq load-path (cons "~/confs/emacs" load-path)) 
  (require 'gui-init)

Establish the load path first so that emacs knows where to look for your required files, and then use the (require) sexep to load in the file. Bingo.

Package Things Yourself

We saw this above, but as much as possible avoid using the load function. When you use load emacs has to (I’m pretty sure) do a fairly expensive file system operation and then load the file and then compile and load the file. This takes time. Using the require function is not without it’s own cost, but it does save some time compared to load because it lets you take advantage of the work emacs does with the library loading. At least in my experience.

In your various .el files, insert the following statement:

  (provide 'package)

And then in your .emacs, use the following statement

  (require 'package)

To load it in. You’re probably already familiar with using these to configure packages that you download. Better yet, don’t require at all, but use the auto-load function. This just creates a little arrow inside of emacs that says “when this function is called, load this file, and hopefully the ‘real’ function by this name will be in there.” This lets you avoid loading packages that you don’t use frequently until you actually need them. The following example provides an auto-load for the identica-mode:

   (autoload 'identica-mode "identica-mode.el" "Mode for Updating Identi.ca Microblog" t)

Byte Compile files as much as you can.

Contrary to whatever you’ve been told, emacs isn’t a text editor, as much as it is a virtual machine with a good deal of low level functions established for interacting with text and textual environments and some editing-based interfaces. But really at the core, it’s just virtual machine that interprets a quirky Lisp dialect.

The execution model is pretty simple and straightforward, particularly to people who are used to Java and Python: you load source files, emacs imports them and compiles them half way, they’re not the kind of thing that you could read on your own or would want to write, but it’s not quite machine code either. Byte-compiled files are easier for the machine to read, and quicker to process, but they’re not human intelligible. Then when you need to do something with the function that it’s byte-compiled, emacs compiles it the rest of the way into machine code and executes it. Usually this all happens too fast that we don’t really notice it.

One tried and true means of speeding up emacs load times is to byte-compile files manually so that emacs doesn’t have to do it itself when it loads. The emacs-lisp libraries are byte compiled when emacs installs itself, but your files probably aren’t. Now generally, only byte-compile files that you’re not going to be editing yourself regularly. Byte compiled files have an .elc extension, and as soon as there’s a .el file and a .elc of the same name in a directory, emacs will ignore the .el file even if there have been changes made. To byte compile an emacs-lisp file, simply type M-x to get the execute-extended-command prompt, and then run the function byte-compile (i.e. ”M-x byte-compile”). Viola!

I hope these all help you all and lead to a slightly more efficient emacs experience.

Winter Break in Reality

I meant to write a more thorough overview of what I was doing with the “extra time” over the holidays. But I don’t think I had as much extra time at the end of the year as I expected to have. What follows is a brief overview what I did do, how the new year has begun and what I’ve been thinking about.

In years past the time at the end of the year was a time to catch up on lost sleep and connections that had fallen by the wayside in the recent months. I also used the time, in some years, to get a lot done: one year I knit about 10 hats. Another, I wrote about a quarter of a novel on a binge. Some years I just vegged.

This year, is different. I haven’t been in school full time for years, and I haven’t received any college credit in a year. I didn’t have significant time off of work. There’s a way in which the holidays were incredibly relaxing. I still have a bunch of friends who are in the later stages of being students, and there’s something awesome about not being a student that’s incredibly relaxing. I mean, working a regular job is not all sunshine and rainbows, but it’s pretty swell, and there’s something about the structure of regular and the mostly even routine that makes it–to my mind–have a greater potential for productivity than “the academic routine.”

In a lot of ways, while I looked forward to holiday time off, and saved up countless projects for that time off, not only did I not make “epic headway” on my projects but I came into the new year feeling sort of behind and tired. Wierd. I blame this on the holidays themselves. It’s as if the entire world slows down: everything gets more difficult for a month or as if the planet is slowly careening to toward this thing that we don’t really enjoy (if we’re being honest,) but that we pretend we really love.

And there’s no getting away from it. You can’t really opt out of the holidays: even if you’re not particularly festive, you can’t control the celebration of other people. You can’t control the fact that the same four songs play on endless repeat in public spaces, you can’t control that everyone wishes you a good holiday, you can’t control all of the federal holidays, you can’t escape tacky decorations, you just can’t escape. And after like 3 days of this, you get tired.

In previous years, the break, the chance to take time off from the big projects I’d been working on (school, applying to graduate school, etc.) was a great opportunity to get “other things done.” Now, there’s no real break from the daily grind, just modulations and finding good balance. That’s an ongoing project, and one that’s better serviced by a good routine and not a few extra days off during a stressful time of year. In any case, I’m glad to have gotten back into things, and I look forward to getting things done.

Onward an Upward!

Wikish and the Personal Public Wiki

First, an announcement. I’ve started a tychoish.com wiki. I’m calling it, appropriately enough ”wikish.” You can see a brief introduction and note about my intentions there.

I’ve written a bunch here about the peculiarities of building communities and practices around “the wiki,” as I think it represents a new paradigm for thinking about collaboration and “the text.” I’m, slowly, working on building a community around the cyborg institute wiki, and that’s an ongoing (and fairly specific) project. I’ve also, in much smaller ways, done things with wikis in a couple of other situations: for some group projects I’ve been involved with, a few things for work, and so forth. Perhaps more relevantly, I also used a wiki–much like this one and the others I am responsible for–as the system I used for storing everything in my brain. From these experiences I’ve come to the following conclusion:

• In any given wiki, most of the “work,” particular at the beginning, is accomplished by a very small number of contributors. Potentially only one contributor.

  Critical mass is a difficult thing to manage or predict, and if you start a wiki and you want it to succeed, you have to be ready to do all of the work of getting it to critical mass, which could take a long time. Fair warning.

• Wikis are incredibly unstructured. It’s easy to impose structure on a new wiki, in cases where structure will actually hinder growth and development rather than promote development. Particularly if the kind of content you hope to develop is wiki like. For personal organization tasks, wikis are often not the right answer, even if they appear to work for a long time.

• Creating a page in a wiki is often better and more effective than writing an email of some length (say, more than 250 words), particularly when more than two people are involved in the correspondence.

• I need another wiki like I need a hole in the head. But, I like that wikish is both public–you all can watch and contribute to what I’m working on–and focused on what I’m working on. The personal wiki, the one that was just for internal use suffered from lack of audience even an imagined audience.

• I think putting the novella that I wrote in late 2007 into a wiki and working on revisions and tweaks in that context makes a great deal of sense, and I think wikish feels like the “right place” to put that work.

So that’s the plan. I’ll probably post from time to time about new things that I’m posting there, and I’m perfectly happy to have you all make pages in wikish as you want. I’ve also decided, that wikish will require OpenIDs as the only means of authentication. Just cause. See you there!