Topic: Posts

A few weeks ago, a friend told me about this IDE (integrated development environment) called PIDA, and while I’m nothing more than a casual programmer, my interest was immediately piqued.

We’ll call it part of my interest in how programmers work. The truth is, as a text-editor junkie, my impulse is to say “meh, IDEs are passe,” but I think that’s probably unfair, and in my writing IDE post I think I recognized--by analogy--their worth. In any-case there’s something sort of nifty about PIDA: rather than recreate tools, it just makes use of what’s already there: the editor is emacs (or vim), the version control system is whatever you want (and already use). PIDA just brings all these things together in a nifty little package.

On the one hand, it’s not a really big deal. Cobbling together working software from a bunch of different existing tools isn’t particularly new. This is sort of the basis of unix-like computing, and further more it tracks the ways most people/geeks actually use computers: by finding the best tools for all of the jobs they have to do and then using them. This way of interacting seems to hold true for command-line and graphical users, I think. So rather than recreate the wheel, PIDA just uses all the existing wheels. The saddest part is that we don’t see more things like this in the graphical application world.

The end result of this mode of application development is that we’re given/build powerful tools that function in familiar ways and that are more powerful as a result of their integrations.

And that’s about it.

I initially thought that this was going to be a really long and really blathering post about integrated tools, and the power of open source/free software to allow tools to be combined rather than be forced to compete. While these are indeed important issues, they’re pretty self explanatory, and IDEs like PIDA provide a great example of how this can be the case, so much so that I find myself saying “why aren’t there more programs like this?”

Why not indeed?

I wrote in my post on the one true system about the informal systems that we use to interface the way we interact with knowledge and information in the “real world” with the way we represent that information on our computers. Exploring these systems lay at the core of the cyborg question, but today’s essay¹ is more about how our logic systems adapt as we use computers and as the kinds of information we need to store change and grow.

As near as I can tell there are a few kinds of “systems review” that we tend to do. Theoretically if you develop a system that’s flexible and that accounts for all of your future information needs, then you shouldn’t have to modify your system very much. Theoretically this is a good thing: better to spend time “doing things,” rather than thinking about “how you’re going to do things.”

The sad truth is that this doesn’t work out very well pragmatically: we change our work habits, and our information changes, and our projects change, and our informal logic for interacting with our computers fails to address the problems, and eventually everything spirals out of control. This is pretty abstract, but every time you see someone with hundreds of icons stacked on your (or someone else’s) desktop, or you find yourself with hundreds of unsorted (and unread!) email messages, or you have to hunt through half a dozen places for a PDF you are witnessing the symptoms of a flawed system.

The only way to address this is to review your “systems,” and make sure that you capture any problem before information spirals out of control:

1. Have an overflow bin, but only one overflow bin. This is important, but counter intuitive. By overflow bin, I mean something where unfile-able items are placed. This hopefully alleviates the tension to file away information that hasn’t been fully processed, or that doesn’t fit into your system, or might be ambiguously filed².

2. Do major reviews of your system only infrequently. By major review, I mean, think about how you use your information, what has worked, and what hasn’t, and then use this as a model for revising your system. Don’t do it regularly, even if you know that something isn’t working. Think of this as something that you do only about twice as often as you get a new computer. As part of this major review process:

   Keep a regular journal when you aren’t in the process of updating procedures. Track about what works and what doesn’t. Often I’ve found that I have ideas about how things should change, but the changes aren’t the kind of thing that I could reasonably change during normal work. These insights/problems are useful, eventually even if they aren’t always immediately relevant. So record them for later.

3. Do Minor reviews regularly. Look in the “overflow bin” from item one and see what’s falling through the cracks, file things that do need to be filed. The GTD folks call this a “weekly review,” and while GTD-task processing is only part of “the system."³ It depends on what kind of information you’re managing, but staying on top of and in touch with your “stuff” is important.

4. Be sure to “touch” your information regularly. While I’m in favor of keeping information even when it’s not apparently useful (you never know), I also agree with the idea that information is only really useful if you use it. I’ve often found myself falling into the trap where I’ll stockpile stuff “to read later,” which of course rarely happens. Avoid this and browse from time to time.

I mean in the end, I’m just a guy who writes more than he should, and has a pile of digital information that’s probably a bit too big, but this is how I do things, and I think the lessons I’ve learned (and continue to learn) may be helpful to some of you. Reviewing and thinking about systems before hand is, if nothing else, instructive.

Onward and Upward!

There’s this idea in linguistic/cognitive anthropology that the limitations of linguistic possibility limit what the bounds of what we’re able to think about. If we lack words for a given thing or a concept, it’s really hard to even conceive what it is. I’ll get to the strengths and limits of the hypothesis in a bit, but lets just say the reception of these ideas (i.e. “linguistic relativism”) is somewhat mixed. Nevertheless it’s had a great impact on me and the kinds of ideas I deal in.

For instance, though I’m not an active programmer, I talk to programmers a bunch I tweak code from time to time, and I’ve tried to learn programming enough times that I sort of get the basics of enough stuff to know what’s going on, and if there’s one theme to my interests in open source and software development, it’s looking at the software and tools that developers us, in part for issues related to linguistic relativism. Basically, if the people who develop programming languages, and software itself don’t provide for possibilities, developers and users won’t be able to think about things downstream. Or at least that’s the theory.*

The problem with linguistic relativism in general, is that it’s really hard to test, and we get into causality issues. “Describe this thing that you don’t know about!” is a bad interview tactic and we run into the questions like: Is it really language that limits knowability or is some other combination of typical experiences that limits both knowability and language? I’ve read far too many a number of papers from a couple of different scholars, and I almost always end up in the “relativist camp,” but that might be a personality feature.

In computer science, I suppose it is also not quite so cut and dry. Questions like “Does the advancement of things like hardware limit technical possibility more than programing languages and tools?” come up, but I think for the most part it is more cut and dry: Erlang’s concurrency model makes thins possible, and makes programmers think in ways that they’re not prone to thinking about them otherwise. Git’s method promoting collaboration requires people to think differently about authorship and collaboration. Maybe. I mean it makes sense to me.

These low-level tools shape what’s possible on the higher level not simply in that a programing language implements features that are then used to build higher level applications, but if you teach someone to program in emacs-lisp (say) they’ll think about building software in a very different way from the folks who learn how to program Java. Or Perl. Or PHP.

And those differences work down the software food chain: what programmers are able to code, limits the software that people like you and me use on a day to day basis. That’s terribly important.

I think the impulse when talking about open source and free software is to talk about subjects that are (more) digestible to non-technical users, and provide examples of software projects that are more easily understood (e.g. firefox and open office rather than gcc and the Linux kernel, say.) This strikes me as the wrong impulse, when we could focus on talking about more technical projects and then use abstractions and metaphors to get to a more general audience if needed. I’m not saying I’ve mastered this, but I’m trying, and I think we’ll ultimately learn a lot more this way. Or so I hope. There is always much to learn.

Onward and Upward!

* In a previous era/maturity state I would have been somewhat guarded about that subject which I think is going to be a major theme in oh the rest of my life. But, this is open source and knowledge wants to be free and all that. Actually, less altruistically, I’m much more worried that it’s a lackluster research question than I am that someone is going to “snipe it from me,” and suggestions and challenges I think would be really productive.

During my middle year of college, I took a class on gender and literature where we had to write a series (10? 12?) of “journal” entries. The assignment was to write 250-300 (hard boundaries) words due by midnight on Friday during most of the weeks of the semester. And there were other rules regarding the speed or frequency you could turn them in that I don’t remember, but there were notably few restrictions on what they could be about.

A few interesting things happened. One is, that though we could write all of them in a weekend, we never did. My roommate(s) and I would write them while everyone was drinking on Friday night. We got pretty heroic about how close we’d cut these to the deadline. There was even a night when I was driving a friend to the airport (3-4 hours in the car) and I argued for an extension through an intermediary whilst driving quite assertively on I-90. Another is that we all got very good at editing our writing to a limited number of words, and it’s a good skill to have. But the most important thing is that all my classmates wrote about the texts we were reading. I wrote about, g-d knows what. Not the things we were reading, except in loose tangential ways.

A roommate asked about if this was, an acceptable thing to do, and I wrote the professor somewhat worried that maybe my journal entries had strayed too far afield. In fairness, the professor’s lectures had a similar tendency to stray, as near as I could tell, but it seemed like the thing to do.

The response was something along the lines of “Don’t worry [tycho,] I quite enjoy your widely synthetic entries. You’ve received credit for all that you’ve submitted.”

Needless to say “widely synthetic,” became my new slogan.¹

I think my blagging style developed in that class, such as it is, which is all sorts of scary.

I started writing this post with the intention of discussing the Sapir-Worf and programing languages. Which I think certainly qualifies as being “widely synthetic,” hence the story, but I think I’ll have to save that for next time.

Take care of yourselves, dearest readers.

My blog reading eyes/ears tend to perk up when I see someone writing about git as this piece of software fascinates me in a potentially unhealthy sort of way. I read a post the other day that talked a bunch about git, and centralized SCM tools like SVN and CVS, as well as the other distributed SCM bazaar. If that last sentence was greek to you, don’t worry, I’m heading into a pretty general discussion. Here’s the background:

Version control or source control management systems (VCS/SCM), are tools that programmers use to store the code of a program or project as they develop it. These tools store versions of a code base which has a lot of benefits: programmers can work concurrently on a project and distribute their changes regularly to avoid duplicating efforts or working on divergent editions code. SCMs also save your history incase you change something that you didn’t intended to you can go back to known working states, or “revive” older features that you’d deleted. SCMs are It’s a good thing, and I’d wager that most programmers use some sort of system to track this task.¹

The basic unit of any version control system is the “commit,” which represents a collection or set of changes that a given developer chooses to “check in” to the system. There are two basic models of VCS/SCM: the centralized client/server system and the distributed system. Centralization means that the history is stored on a server or centralized machine, and a group of developers all send and pull changes from that central “repository.” Distributed systems give every developer in a project a copy of the full history, and give them the capability of sending or pulling changes from any other developer in a system.

There’s a lot of topics about the various merits of both distributed and centralized version control systems, and a lot of this discussion ends up being hashed over technological features like speed and the various ease of various operations or over process features that relate to what a system allows or promotes in terms of workflow. While these discussions are interesting they’re too close to the actual programs to see something that I think is pretty interesting.

In centralized systems, “the commit” is something that serves the project’s management. If done right (so the theory goes), in a centralized system, only a select few have access to submit changes, as the central server’s only way of reconciling diverging versions of a code-base is to accept the first submitted change (poor solution) and the more developers you have the greater the chance of having version collisions. As a result there’s a lot less committing that happens. In big projects, you still have to mail patches around because only a few people can commit changes and in smaller teams, people are more likely to “put off committing” because frequent commits of incremental changes are more likely to confuse teammates, and committing amounts to publication.

In distributed systems, since the total “repository” is stored locally, committing changes to your repository and publishing changes with collaborators are separate options. As a result, there’s less incentive for developers to avoid creating commits for incremental changes. Rather than have commits mark complete working states with a lot of changes in every individual commit, commits mark points of experimentation in the distributed system.

This difference, is really critical. Commits in a centralized system serve the person who “owns” the repository, whereas in the distributed system they serve the developer. There are other aspects of these programs which affect the way developers relate to their code, but I think on some fundamental level this is really important.

Also, I don’t want to make the argument that “bottom up distribution = good and top down centralization = bad,” as I think it’s more complicated than that. It’s also possible to use distributed technology in centralized workflows, and if you use centralized systems with the right team, the top-down limitation isn’t particularly noticeable. But as a starting point, it’s an interesting analysis.

I promised that I’d post some of the stuff from my .emacs file that makes my org-mode system work. Here we are.

There are some basic settings that I use on all major modes that I use in emacs. Basically, I want to attach the spell checker (the minor modes, flyspell-mode and auto-fill-mode). These lines do this:

(add-hook 'org-mode-hook 'turn-on-auto-fill)
(add-hook 'org-mode-hook 'flyspell-mode)

I also, attached “.org” as the file extension to org-mode. This setting is good for this kind of thing:

(setq auto-mode-alist
(cons '("\\.org" . org-mode)auto-mode-alist))

The following are a list of basic org-mode related settings that I’ve found helpful. In some sequence, I keep org-mode files in the ~/org/ directory, with codex.org being my general catch-all file. I like my agenda views to include todos, even if they’re not date-specific (this is a great boon) I’ve included the diary in the agenda views for grins, though I’m not yet smart enough to really make the most of that one.

The odd-levels-only, and hide-leading-stars are aesthetic settings only, and can be changed/converted from at any point, but I like them

The org-todo-keywords setting allows you to specify alternate todo-statuses. I’ve found that this sorting is a useful and allows me to visually sort out things I need to write, versus chores and other more clerical tasks. The pipe seperates finished statuses from open statuses. I debated for a long time about weather “differed” should be “done” or “not done,” but decided that with “pending,” I was safe to use “differed” tasks for “not my problem any more” items.

(setq org-directory "~/org/")
(setq org-default-notes-file (concat org-directory "/codex.org"))
(setq org-agenda-include-all-todo t)
(setq org-agenda-include-diary t)
(setq org-hide-leading-stars t)
(setq org-odd-levels-only t)
(setq org-todo-keywords
      '((sequence "TODO"
                  "WRITE"
                  "REVIEW"
                  "PENDING" "|"
                  "DIFFERED"
                  "DELEGATED"
                  "DONE")))

The next bit, is something that I got from Jack. It creates an org-mode file with time-stamp headlines which you can use to create a journal file to record daily activities.

The first block sets up which file the journal should be in, and the second sets up entry. My main complaint with this is that I’m not very habitual about using it.

(defvar org-journal-file "~/org/journal.org"
   "Path to OrgMode journal file.")
(defvar org-journal-date-format "%Y-%m-%d"
   "Date format string for journal headings.")

(defun org-journal-entry ()
  "Create a new diary entry for today or append to an existing one."
  (interactive)
  (switch-to-buffer (find-file org-journal-file))
  (widen)
  (let ((today (format-time-string org-journal-date-format)))
    (beginning-of-buffer)
    (unless (org-goto-local-search-headings today nil t)
      ((lambda ()
         (org-insert-heading)
         (insert today)
         (insert "\n\n  \n"))))
    (beginning-of-buffer)
    (org-show-entry)
    (org-narrow-to-subtree)
    (end-of-buffer)
    (backward-char 2)
    (unless (= (current-column) 2)
      (insert "\n\n  "))))

The integration between remember-mode functionality and org-mode is one of those things that just makes org-mode amazing and awe inspiring. The sad part is that it takes some setup to make it work right and therefore doesn’t work straight out of the hook.

I’d explain the template syntax better if I understood it a bit better. I should look into that.

(require 'remember)
(setq remember-annotation-functions '(org-remember-annotation))
(setq remember-handler-functions '(org-remember-handler))
(add-hook 'remember-mode-hook 'org-remember-apply-template)

(setq org-remember-templates
      '(("todo" ?t "* TODO %?\n  %i\n  %a" "~/org/codex.org" "Tasks")
        ("notes" ?n "* %?\n  %i\n  %a" "~/org/codex.org" "Inbox and Notes")
        ("blog" ?b "* %U %?\n\n  %i\n  %a" "~/org/blog.org")
        ("technology" ?s "* %U %?\n\n  %i\n  %a" "~/org/technology.org")
        ("fiction" ?f "* %U %?\n\n  %i\n  %a" "~/org/fiction.org"))

Finally, key bindings that make org-mode functionality accessible whenever I need it in emacs. I should do things to have raise emacsclient windows from other applications, but I’ll deal with that later. There aren’t that many, and I put org-mode stuff under control-c (C-c).

(global-set-key "\C-ca" 'org-agenda)
(global-set-key "\C-cr" 'org-remember)
(global-set-key "\C-cj" 'org-journal-entry)

And that’s it. If you use org-mode, what’s the killer snippet that I’ve forgotten? If you don’t use org-mode but are curious, what should I talk about next. If you’re still not clear what org-mode is, ask, as I should work on getting better at explaining.

Thanks for reading. Cheers!

So I’ve been posting about cyborg systems on tychoish, about the informal logical systems we use to interface our lives/reality/thoughts/work into digital systems to organize what we accomplish with our computers. It’s a topic of some interesting to me, and I’m going to provide a simple piece of advice in this post:

Try your damnedest to only use one system. For as much of your data as you possibly can.

This might be an odd piece of advice, you say, coming from someone who proudly supports the Unix philosophy of “use tools that do one thing well.” I think, however, that the question of tools and systems are fundamentally different. Having tools that do lots of things (poorly) means that you have ineffective tools. Having more than one system to organize your data means that things get lost.

Joseph Spiros, a friend of mine from way back, wrote an essay that I think serves as a pretty good introduction to some of these ideas. Read Prelude to Haven and come back when you’re done.

Back?

Great. Lets continue.

Having one system that houses everything is a great boon to our representation. If you know, from the very beginning, what kind of data you’re going to be dealing with, and develop some sort of organizational system based on this knowledge then it’s really hard for files to get lost, for things to be double classified and without reference. Basically, for any given thing, there should be only one given place that you should have to look for this.

This is of course pretty difficult to do. So maybe I don’t mean “only have one system for everything” but, rather “have one system for any given thing.” More concretely:

• Only have one email account. If you get mail at more than one address, use a client that allows you to view/send email from more than one address (eg. gmail) or forward multiple accounts to one address. This way, if you’re looking for an email there’s only one bucket to look in.
• Organize data by either projects, subjects, or kind, but not more than one of these categories. Projects would be spheres of your work that form a body onto themselves: if you wrote books, a project would be a book and you’d collect notes, drafts, and versions related to a book in one “pile”¹. Subjects can get dicey (as they require you to sort your data into a given number of subject-based piles and then be able to recall that sorting again. Kind-based organizations require you to keep all your notes in one pile, drafts in another, final copies in another which can grow unwieldy depending on subject, but greatly decreases the chance of misfiling.
• For data manipulation standardize your practices on specific tools: tasks go in one place, project files go in another, references in another, and so forth. If you track two todo-lists that don’t synchronize with each other, then the chance of loosing track on some things in one when they should have gone in the other system. One “OK” system is superior to 2 or more excellent systems.
• Use search tools to your advantage, but avoid the google-method of relying search to be smarter than the index of files. Search is good, and there are a lot of times when searching for something is helpful (lost files, finding a specific quote), but often times they take a lot of system resources to build a gross index that likely doesn’t contain the kind of information your looking for.

And that’s it. One more step on the road to a better, more fulfilling cyborg experience.

In the last six months or year (or two years) I’ve written a lot here, about technology open source software and related topics. In a way this was a new thing for me. I majored in Women’s Studies and Psychology in college. I wrote about gender and queerness, and knitting for many years. My big thing (or one of them, at any rate) is science fiction literarture, where I’m interested in very historical/“soft” sub genres. While some SF writers feel ghettoized by the “hard”/“soft” boundary in the genre, I love the fact that there’s (a very popular) field of science fiction that isn’t based on firm understandings of existing science/technology and tightly formed elaboration thereon. I love being non-technical on some level. Despite my current technological musings, this is very much a past that I must contend with.

But I digress.

Before all of this hippy-drippy stuff, I wrote a lot about technology. Back in 1999/2000/2001 I was reasonably active in the discourse surrounding mobile technology. Indeed through this I discovered blogging itself. There are a couple of subtitles to this that I think are appropriate: first, the state of mobile technology about 10 years ago was much different than it is today. Much different. Laptops were significantly bigger and less portable, cellphones were much less “smart,” and disconnected PDAs were the light of the times.

But sooner rather than later, I broke down, bought a nice fountain pen and just kept a notebook when I was away from my computer. It worked. Eventually I got a cellphone, but I always tended toward the “dumb”-phone type that were incredibly simple. They worked. The paper worked. When I went away to college I got a 12 inch iBook (as my only computer) and it was great. Small laptops with wireless and long battery life seem to be a great solution to the “mobile technology” problem, and as--at the time--it seemed like my life/work was trending around in a different direction, I stared writing about different things, which when you think about it is all for the best.

For the intervening years, I’ve been sort of cool toward a lot of gadgetry. Laptops are small enough and powerful enough and frankly cheap enough (considering) to account for a huge percentage of digital mobility, that the remaining need is actually pretty small. And it was my experience that mobile technology wasn’t there, for the in between spaces yet. Recording bits of minutia in a usable way on a PDA was never quite as quick and seamless as doing it either on a computer or with paper.

Eventually I’ve gotten back into writing about technology, but by this time it was a different kind of technology: unix/linux stuff, cyborg stuff, tools for writing, usage methodologies, and organization stuff. The technology itself (for me) has taken a backseat to the ways we use technology.

But in the mean time the mobile technology has mostly caught up. At least somewhat. Cellphones became a lot smarter, the data transmission got cheaper (and unlimited), syncing tools through google and mobile me (if that’s your style) make the experience much more coherent. In a lot of ways, the fact that cellphones and connected devices can--independently of host computers--interact with the internet has made them infinitely more useful. And the fact that, at least in my case, do this via protocols that we’re already familiar with (REST API’s or email) makes this even more attractive.

I also think, at least in some cases, that a lot of this “web 2.0 stuff” makes the most sense in the context of mobile devices. While I don’t often think about twittering, or dicking around on facebook when I’m sitting somewhere with just my Blackberry, the applications that connect with these web 2.0 services on phones are really clever. Maybe it’s that limited functionality apps make more sense on phones/PDAs than they do on desktop computers, but that could just be me. In the end, I’m still dubious of all this “web stuff,” but I think it at least makes sense now.

So there.

Onward and Upward!