In no particular order:

Org Mode Guilt and a Lisp Function

I have some guilt about having mostly forsaken org-mode,¹ in particular because I was watching Sacha Chua’s chat with John Wiegley, and I think both are such nifty hackers, and have done so many things that are pretty darn nifty.

I liked what I heard about johnw’s org mode setup so much that I might give it a try again. But in the mean time, I wanted to make my “recompile my tasklist function” to be a bit more clean. The result is follows:

(defun tychoish-todo-compile ()
   (interactive)
   (if (get-buffer "*todo-compile*")
       (progn
          (switch-to-buffer-other-window (get-buffer "*todo-compile*"))
          (recompile))
       (progn
          (compile "make -j -k -C ~/wiki")
          (switch-to-buffer-other-window "*compilation*")
          (rename-buffer "*todo-compile*")))
       (revbufs))

Notables:

• This is the first time I’ve used progn which is somewhat embarrassing, but it’s a great thing to have in the toolkit now. Link: progn
• I hadn’t realized until now that there wasn’t an else-if form in emacs lisp. Weird, but it makes sense.
• Compilation Mode is pretty much my current favorite thing in emacs.
• revbufs is this amazing thing that reverts buffers if there aren’t local modifications, and also reports to you if a buffer has changed outside of emacs and there are local modifications. So basically “does everything you want without destroying anything and then tells you what you need to do manually.” Smart. Simple. Perfect.

I might need to “macro-ize” this, as I have a lot of little compile processes for which I’d like to be able to trigger/maintain unique compile buffers. That’s a project for another day.

Emacs Thoughts

I’m even thinking about putting together a post about how, although I’m a diehard emacs user, and I’ve spent a fair bit of time learning how to do really great things with emacs, there are a lot of vim-ish things in my workflow:

• I read email with mutt and I’ve tried to get into GNUS, and I try it again every now and then, but I always find it so unbelievably gnarly. At least the transition. Same with Notmuch, which I like a lot more (in theory,) but I find the fact that Notmuch and mutt have this fundamental misunderstanding about what constitutes a “read” email, to be tragic.

• I use a crazy ikiwiki + deft + makefile setup for task tracking. As (obliquely) referenced above.

  I might give org another shot, and I’ve been looking at task warrior, but the sad truth is that what I have works incredibly well for in most cases, and switching is hard.

• I tend jump to a shell window to do version control and other things, even though I’m familiar with magit and dired, my use of these tools is somewhat spotty.

After doing the first pass of editing on my technical book, “Systems Administration for Cyborgs” on a screen and feeling utterly buried by it, (See: /posts/the-editing-hole,) and I’m considering different approaches for the next book. Specifically, for this novel I have, I’m thinking about getting the novel printed somehow and then editing it “analog style.”

I’d love to hear feedback from anyone who has done this, particularly recently. Particularly from people who are very digitally savy. Here’s my pro/con list:

Pros:

• It might be nice to have a different “editing context,” to help me keep focus on the project without the distractions of the internet and current writing projects.
• Having marked-up pages gives me an actual marker of progress, rather than a list of commits or diffs.
• It might be nice to get some practice writing longhand again. It’s embarrassing when someone hands me a pen and I’ve basically forgotten how to use it.
• It gives me a start to a collection of paper ephemera that I can burden some archivist with at some point.

Cons:

• Context switching, from a computer, to paper, to a tablet, or whatever is annoying and eats time/focus.
• Paper would force a more linear editing process, which may get me to focus on the story and characters more closely at the possible expense of seeing “broken sentences,” and other things that may be distracting to the next readers/editors/etc.
• If I edit on paper, I have to go through and apply those changes to the actual text. Which adds a step, and probably a number of additional weeks to the editing process.
• I’m awful writing things out long hand and I pretty much haven’t written anything long hand in 4 or 5 years.

Reflections

There’s also another little thorny problem: I’m not sure what the future of this book is: The prologue stands alone, and I want to try shopping it around. If I can get that published as a short that might be the hook to getting the rest of the book published.

Initially my plan was to have a friend read it as a podcast, and attempt to publish the prologue as a short, and then try and for-real publish the next book. The podcasting idea, while nice, wouldn’t work out as originally planned (long story.) Besides, it really depended on having someone else to the reading (I have neither the time, technical skills, nor the real ability to do the reading.) Which leaves me without a plan, and the following thoughts about the publication of this text:

• I feel like my writing career¹ is in good (enough) shape that my identity as a writer depends on publishing this novel in a particular way.
• On the other hand, getting the novel (or parts of it published) would be a great thing, and validates all this time/energy/interest that I have in writing science fiction.
• I’m not opposed to self publishing, except that it means more work for me for what is probably less impact (i.e. readers.)
• It took me embarrassingly long to write this novel. And knowing how much better my writing has gotten in the last three or four years, means that I’m pretty worried that this is really a cold pile of shit. I recognize that this is probably more reason to get the novel out to first readers, but I also feel like I should do them the favor of at least a little editing.

Printing in the Digital Age

As an aside, this has given me some time to do research on getting things printed, which I’d like to record here and share with you:

(Given a 325-350 page manuscript)

• I don’t own a printer, and have no particular interest in owning one, but a good color laser (in the 300-400 USD) or a good black and white (200-300 USD) becomes much more economical if analog editing becomes a thing.

  The downside of printing things yourself is that you still need some way to bind things. And there are maintenance and supply costs not factored into the above.

• The price to get printing/binding done at Staples is in the 35-40 range. Chances are that these copies are likely to be the highest quality, quickest turn around, and the web interface--though annoying--is probably the most straight forward.

• You can use Lulu.com to order prints. The same book costs 15 bucks. It’s also spiral bound (which seems preferable to perfect binding for writing.) I’m not sure what “lulu standard” paper is like quality wise, but I suspect it will be ok. If you’re ok with a fussy online interface, a weird approach to covers (no really, I’d just like transparent covers,) and turn around time, the price seems unbeatable.

Also, Lulu’s cover making interface makes it really hard to get a plain cover that doesn’t look like a joke.

I did some hunting around for local copy shops (I swear it seems like I pass several on my walk to work,) but had difficult finding a shop who would be able to do a very small order, and has the digital setup to accept a PDF for printing via email or a web site.

The success or failure of the collar of a sweater determines the success or failure of an entire sweater. This post provides an overview of my basic: “how to knit a collar” system that usually works for me and some thoughts on why collars are so important.

The hard part of collars is that on the whole, collar shaping accounts for five or ten percent of the knitting, but weeks or months worth of work hangs in the balance. The collar affects both the overall style of the sweater and has a great impact on how you will feel about the sweater when you wear it. A collar that doesn’t hang right, or is too narrow or too wide is the worst: the right collar can also make a sweater that is otherwise too light feel just warm enough and more importantly the sweater that’s too heavy not feel oppressively warm.

So how do you knit a collar?

Easy.

The fine print: These instructions assume that you’re knitting the sweater in the round.</small>

For a basic, round, crew neck…

Figure out how long your sweater will be from the top of the shoulder seam to the bottom hem. Typically this is the length measurement in the pattern and you can measure it easily yourself.

Figure out how many stitches around your collar opening needs to be at the very end, but the width of the hole at the top seam. Because you’re shaping the collar, the number of stitches on the collar as you knit it will be slightly higher because of the angles/sloped edges. Typically this is 13-16 inches for most people.

Elizabeth Zimmerman would figure 1/3rd of K, which is a good starting point, but if your sweater has too much ease or if your making a sweater in excess of 40 inches (which isn’t too big,) I think you’ll end up with neck openings that are a little too wide.

Before you start, compute the following values:

• Half of the total collar width. This is the total number of stitches that you need to set aside or decrease by the time you get to the shoulder seam on the front and the back.
• About half of this number or a quarter of the total (or a bit less, round down here, if need be) to set aside at the base of the neck.
• The total number of stitches minus the actual number of stitches set aside at the bottom of the neck, if your math is fuzzy. This is the number of stitches that you have to decrease on either side of the neck. This number must be even.
• The distance between the bottom of the neck and the top of the shoulder. This is almost always within a half an inch of 3 inches. Also record the number of rows.

With these numbers in hand, do the following.

Three (3) inches before this length, begin the collar shaping. (Change depth as needed.)

Set aside stitches at the bottom of the neck.

Decrease on either side of the neck opening (possibly using a steek,) every row until you have decreased half of the number of stitches that you need to decrease. Typically this should take about an inch and a half of knitting, or half of the total collar depth to accomplish.

After you’ve knitted half of the total collar depth, figure out how many stitches you’ve decreased at this point. Set this number of stitches aside in the middle of the back of the sweater.

Meanwhile: Create a new steak or begin decreasing at the back of the neck at the same rate as you decrease at the front.

Now decrease at half the rate (e.g. every other row) for the remainder of the depth of your collar opening. Bind off. You’ve made a sweater.

If you time it right, and your stitches are not too short and wide, this basically works out to: set aside stitches at the front, decrease every row for an inch and a half, set aside stitches at the back, decrease every other row for an inch and a half. Bind off for shoulders.

Variants:

• Knit more on the front so that the shoulder seam is actually at the top of the back, and the front of the sweater extends over the top of the shoulder.

• Use shoulder saddles or straps to increase the depth of the neck. This is a perpendicular strip of knitting that starts at the side of the neck and extends across the shoulders and forms the top part of the sleeve.

  In this case, subtract half of the width of the saddle/strap from the depth of the collar opening, and twice the width from the opening. Adjust accordingly: typically the best thing to do is figure out how much additional depth you need to decrease, figure out how many rows that will be, and plan to decrease on every row and set aside the remainder. Depending on the depth you may need to “fill in” or shape some of the depth on the back of the neck.

• If your shoulders slope downward, consider short rows across one or both of the sides, to make the top of the sweater a bit more conical.

• I often make Henly-style sweaters by setting aside a single stitch (and knitting a steek) 3-5 inches bellow the bottom of the collar. This keeps sweaters from becoming too warm.

I’ve had a nice quiet weekend, the first such weekend in quite a while. It’s nice to be able to relax, work on projects without deadlines, and avoid all of the editing that I ought to be doing.

Some notable accomplishments, current projects, and other events in the last few weeks:

• If you ever visit tychoish.com in your web browser (as opposed to by way of its aggregation,) you’ll note that the design has changed somewhat.

  This is the design that I’ve been using for my personal wiki for months, and so I’m quite used to it, but feedback is welcome.

  The design change has inspired a bit of introspection, hence this post, and perhaps some of the posts that will follow. Please bear with me.

• Months ago a friend of mine said “some of us might like to know how you’re doing every now and then, and your blog is just stuff about obscure technology.”

  Guilty as charged. Recently, I’ve been much more interested in using this blog as a scratch space for projects that I don’t have quite enough time to pursue in appropriate depth.

  Having said that, I think (or hoped,) that I’ve calmed down a bit in recent months and years: My career/professional identity seems a bit more stable. I’m doing a better job at focusing big projects, which means some shorter posts and more personal posts may be in order.

• I got a new computer last week. I’m working on a post that addresses this in a bit more depth. In short it’s great. So my largely unnecessary justification is:

  • A smaller machine, which is better on my back when I am walking around.
  • Beefier system, which means I can compile things quicker (and I’ve been doing more of this recently.)

• The ability to dedicate the older system to some stay at home things: having a working desk at home, playing music, running some buildbot stuff, and the like.

I’ve realized that even though there are little things that I might like to change about how my computer works, and things that I’d like to setup and get working for the most part, things just work. And that’s really great.

• There’s a host of stuff that I’m working on that probably isn’t apparent to the internet:

  • My day job. I’m doing awesome documentation things for a neat New York City database software company/open source project that you’ve probably heard of (if you’re into this kind of thing.) It’s rewarding, interesting, and it means I can spend all most of my time day making things.
  • I’ve been working on submitting documentation patches to a couple of open source projects: buildbot and MediaGoblin. I need to do more of this work.
  • The editing pile. Currently on tap: a mess of blog posts, the prologue of my most recently drafted novel, and some of the last little pieces of the Cyborg Institute launch. Speaking of which that should happen in the next week or so.

  Next up? More of the novel and suggestions from frist readers of the systems administration book (see next item.)

• Never to be deterred, I’m hard at work on the outline for another novel. The plan is to have something I can start drafting in earnest by the end of the summer. I feel pretty good about the project, although as I was working on an outline last night, I changed the last third of the book. Oops.

• The systems administration book. Available via git today, With general release following shortly. All feedback as well as pull or merge requests with comments and suggestions are all welcome. See the following for git repositories

  • administration on git.cyborginstitute.net
  • administration on github.com

  (Both are identical.)

  The cyborg institute listserv would be a good place for bug/issue tracking at least for now.

• On the topic of editing, I’ve recently discovered the one clause per-line formatting style.

I’ve long attempted to keep lines short to promote cleaner diffs, but in truth, if you end up reflowing paragraphs, the resulting diffs are basically useless. I’ve encountered one-sentence-per-line tactics, which seems like a good idea, except that sentences often exceed 80 characters.

I’m not yet decided on the subject, especially for writing longer sections of text, but it does make editing easier.

Onward and Upward!

In the course of writing a computer program, engineers typically face the same kinds problems again and again. As a result programmers have developed a way of thinking about different kinds of solutions and situations as “patterns,” which provide generalized ways of talking about common problems and strategies.

> See: Portland Pattern Repository for an > example catalog of programming patterns.

When I opened the editor to write this post, I wanted to write something to connect this idea of a “pattern” with a knitting pattern, which I think is (or could be) a very related concept.

Rather thank think about knitting designs as these static instructions for constructing a single kind of garment, I think it might be cool to think of knitting patterns in the sense that programmers use the word: as a set of generalized responses to various states and situations.

This isn’t revolutionary. If you’ve been knitting seriously for more than a couple of years, you probably already think about knitting in this way. At the same time, knitting publishers organize information in other ways: knitting “content” is either design and object centric (how to knit a “thing,”) or it’s technique centric (how to make a specific kind of “stitch” or “how to execute a specific kind of operation.”)

Patterns are good because they are guides to become more creative and more resourceful knitters. Patterns help us understand how to effectively use resources, to execute the objects that we want to without dithering, and how to fix mistakes in our knitting when we make them. Focusing on knitting “patterns,” is not only important because knitters will find them useful, but because it will advance the state of the craft.

Patterns also help resolve an ongoing “problem” in the knitting world: an online, free culture repository of information about knitting.

In the decade or so, I’ve watched a number of knitters attempt to create online information resources that serve as a free culture repository for knitting. Nothing has been particularly successful, and there’s not a lot of “knitting free culture” out there.

While the lack of knitting free culture is due to a large number of factors, the fact that knitting content has always centered on “objects” and “techniques” is almost certainly a factor:

• objects are difficult to design, represent professional designer’s only real way of generating a reputation and income, and it’s difficult to divide the work of writing instructions for creating objects.
• there are a few (3-5) really, really good knitting techniques compendiums, and while new techniques emerge every now and then the books from 1938 (Mary Thomas’) are as good as any of the more recent examples.

Patterns in this sense might be the best way to build an online knitting resource. Rather than store indexes upon indexes of cast on methods, full patterns for garments, and stitch patterns, we could create an index of knitting patterns, generated and indexed by situation and purpose. Example patterns might include:

• Heels for Light Weight socks.
• Heels for thick socks.
• Crew neck collars.
• How to knit sweaters in the round when you don’t want to steek.
• How to secure a steek if the yarn isn’t wool.
• Knitting socks for high arches.

And so forth…

I’m going to use my (admittedly sporadic) knitting blogging to begin capturing some of these knitting patterns. Then, if there’s interest, we can convert these into a more robust form.

Anyone interested?

This is an entry in my loose series of posts about build systems.

I’ve been thinking recently about why I’ve come to think that build systems are so important, and this post is mostly just me thinking aloud about this issue and related questions.

Making Builds Efficient

Writing a build systems for a project is often relatively trivial, once you capture the process, and figure out the base dependencies, you can write scripts and make files to automate this process. The problem is that the most rudimentary build systems aren’t terribly efficient, for two main reasons:

1. It’s difficult to stumble into a build process that is easy to parallelize, so these rudimentary solutions often depend on a series of step happening in a specific order.

2. It’s easier to write a build system that rebuilds too much rather than too little for subsequent builds. From the perspective of build tool designers, this is the correct behavior; but it means that it takes more work to ensure that you only rebuild what you need to.

As a corollary, you need to test build systems and approaches with significantly large systems, where “rebuilding too much,” can be detectable.

Making a build system efficient isn’t too hard, but it does require some amount of testing and experimentation, and often it centers on having explicit dependencies, so that the build tool (i.e. Make, SCons, Ninja, etc.) can build output files in the correct order and only build when a dependency changes.¹

The Benefits of a Fast Build

1. Fast builds increase overall personal productivity.

   You don’t have to wait for a build to complete, and you’re not tempted to context switch during the build, so you stay focused on your work.

2. Fast builds increase quality.

   If your build system (and to a similar extent, your test system,) run efficiently, it’s possible to detect errors earlier in the development process, which will prevent errors and defects. A tighter feedback loop on the code you write is helpful.

3. Fast builds democratize the development process.

   If builds are easy to run, and require minimal cajoling and intervention, it becomes much more likely that many people

   This is obviously most prevalent in open source communities and projects, this is probably true of all development teams.

4. Fast builds promote freshness.

   If the build process is frustrating, then anyone who might run the build will avoid it and run the build less frequently, and on the whole the development effort looses important feedback and data.

   Continuous integration systems help with this, but they require significant resources, are clumsy solutions, and above all, CI attempts to solve a slightly different problem.

Optimizing Builds

Steps you can take to optimizing builds:

(Note: I’m by no means an expert in this, so feel free to add or edit these suggestions.)

• A large number of smaller jobs that can complete independently of other tools, are easy to run in parallel. If the jobs that create a product take longer and are more difficult to split into components, then the build will be slower, particularly on more powerful hardware.
• Incremental builds are a huge win, particularly for larger processes. Most of the reasons why you want “fast builds,” only require fast rebuilds and partial builds, not necessarily the full “clean builds.” While fast initial builds are not unimportant, they account for a small percentage of use.
• Manage complexity.

There are a lot of things you can do to make builds smarter, which should theoretically make builds faster.

Examples of this kind of complexity include storing dependency information in a database, or using hashing rather than “mtime” to detect staleness, or integrating the build automation with other parts of the development tool chain, or using a more limited method to specify build processes.

The problem, or the potential problem is that you lose simplicity, and it’s possible that something in this “smarter and more complex” system can break or slow down under certain pressures, or can have enough overhead to render them unproductive optimizations.

I’ve found myself writing a fair number of Makefiles in the last few weeks: In part because it was a tool, hell a class of tools, that I didn’t really understand and I’m a big sucker for learning new things, and in part because I had a lot of build process-related tasks to automate. But I think my interest is a bit deeper than that.

Make and related tools provide a good metaphor for thinking about certain kinds of tasks and processes. Build systems are less about making something more efficient (though often it does do that,) and more about making processes reproducible and consistent. In some respects I think it’s appropriate to think of build tools as.

I’ve written here before about the merits of /technical-writing/compilation for documentation, and I think that still holds true: build processes add necessary procedural structure. Indirectly, having formalized build process, also makes it very easy to extend and develop processes as needs change. There’s some up-front work, but it nearly always pays off.

While I want to avoid thinking that everything is a Makefile-shaped nail, I think it’s also probably true that there are a lot of common tasks in general purpose computing that are make shaped: format conversion, extracting and importing data, typesetting (and all sorts of publication related tasks,) archiving, system configuration, etc. Perhaps, more generic build tools need to be part of basic computer literacy. That’s another topic for a much larger discussion.

Finally, I want to raise (or re-raise) the question, that another function of build systems is reduce friction on common tasks and increase the likelihood that tasks will get done, and that people will need less technical background to do fundamentally mundane tasks. Build systems are absolutely essential for producing output from any really complex process because it’s hard to reliably produce builds without them; for less complex processes they’re essential because no one (or fewer people) do those tasks without some kind of support.

Rough thoughts as always.

I’m working on the final touches of a treatise on Systems Administration that I’ve mentioned in passing here before. I hope to have this project up on a web-server near you (near me?) in a few months. Because I’ve had a lot of fun working on this project, I decided that it would be cool to do a similar project on another topic dear to my technical interest: Computing Literacy.

Computing literacy? Isn’t that a little *early nineties* for you and or everyone?

Well yes, I suppose, but don’t think that the improvements that have aided the adoption of technology in the last 20 years have necessarily raised the amount of computing literacy. In fact, it would not surprise me if all of the abstraction and friendly user interfaces make it more difficult for users to understand how their computers actually work.

Because their computers play such an important role in everyone’s life and work, I suspect that there are a lot of folks who don’t know how these things work but want to learn. And the truth is that there aren’t a lot of resources around for people who aren’t already tinkerers and hackers.

This is where I fit in: I can write a book-like object that provides useful information in an easy to understand way that technical people can provide their friends and family say things like “what’s a database?” or “what do you mean compiled?” or “what’s a server?” or “what is this file system thing?”

Are you so arrogant as to think that you can add something new to this subject?

I’m not going to develop new technology here, or suddenly make things easier to understand, but I think there’s a niche for computer users between people like me, who download putty on other people’s computers to ssh into their VPS server which hosts a VPN that their laptops are connected to, to ssh into their laptops to kill misbehaving X11 sessions (no really, I just did that,)* and most people who just know how to open MS word and send emails, and browse the web.

And I think that giving folks who are technically creative, intuitive, and curious a way to learn about their computers and technology would be great. Particularly in a way that doesn’t assume too much prior knowledge, or an interest in complicated math.

Ok, so you’re convinced that it’s a good idea, what’s going to be special about this?

First, while the material will not be so complicated or so novel, I think the presentation may be. Additionally, I envision this document as a useful reference for describing and defining basic computing concepts, to support more technical blog posts and articles.

Finally , I think it would be fun to do this book-like object in a more iterative style, relative to the Systems Administration book: I’ll sketch out the basics, put a disclaimer at the top about links breaking and then publish it, and publish changes and make the whole thing accessible by git..

Sound cool to anyone?

So there you have it.

Expect to hear more in the late summer or fall…