Topic: Technology

My grandmother reminds me that she got a laptop in the late eighties,¹ it’s massive by today’s standards (particularly in comparison to my 12 inch thinkpad), but it had a great keyobard, and she remembers using it rather effectively. It had WordPerfect 5.1 back in the day but I think it also had StarWriter/StarOffice (which, the astute will recognize as the predecessor code-base for today’s Open Office). It probably weight ten or fifteen pounds, and I think she even brought it between work and home several times a week (using a luggage cart); but this was before her days on the Internet, and like all good things this laptop has gone to the land beyond.

For my college years, and a few years after I was a laptop-only computer user. It didn’t make sense to have a computer that I’d have to move so damn frequently, and it wasn’t like I was playing games or anything that would require desktop, and I loved having only one machine to keep current and up to date. It seems like laptop-only is a definite trend among the Internet-hipster/start-up monkey crowd. And it’s admirable, and for these folks (who are likely, and appropriately, Apple users) a laptop-tax of 400 dollars isn’t too much for people who have already bought into the Apple tax.

And then, along came the “netbook” phenomena, which posits that most of the time we don’t really need a desktop-grade laptop when we’re on the run. There’s a lot of merit to this model as well. We don’t really need to carry around powerhouses to check our emails in coffee shops, and for folks like me for whom the vast majority of our computing is pretty lightweight, building a system around a primary desktop computer and a sufficient but not supercharged laptop makes a lot of sense.

So what kind of laptop system do you use?

For the last, call it 8 years, having a website, dynamically generated with most of the content pulled on (nearly) every reload from a database. MySQL or PostgreSQL, or some such. It’s a great model, in a lot of ways, because it represents the (near) ultimate separation of content and display, it means that static pages don’t have to be generated whenever you generate new content. Dynamic, database driven websites were going to the future, and I think history has proven this argument.

At the same time, I think a further analysis is required.

Just to be super clear the advantages of database driven websites are that:

• Pages don’t have to be regenerated when content changes.
• Content is more customizable and can be pulled together in ad-hoc settings.

I would argue however, that there are some fundamental weaknesses that this system of deploying websites promotes:

1. Database driven websites increase the complexity of web-site software by a magnitude or two. I can in my sleep hack together a static website (most people can); working with database requires a much more specialized system that is harder for website owners to maintain. While separating content from display is often an effort to make systems easier to understand and change, in point of fact, databases make website maintenance a specialized task.
2. Database driven websites have a lot of overhead. Because pages need to be regenerated regularly, they require beefy hardware to work correctly. On top of this database systems need to be cached in such a way, that they’re not quite as dynamic as they once were.
3. Databases are mostly server-based technologies, which means a lot of the dynamic client-side scripting (EMCAscript/JavaScript and AJAX/AHAH) that are all the rage these days (and what people most often mean when they say “dynamic”) aren’t nearly as dependent on databases as what’s going on in that space.
4. Given the very structured nature of databases, websites often need to develop their content structure with near prescience regarding what’s going to happen in their site for the next five years. This is complicated, difficult, and often means that the same content-system needs to be redeveloped (often at great cost) far too often.

In light of this I’ve been thinking, increasingly, that the future of websites will likely be powered by a much different kind of website software. Here are some observations about the future of the web:

• Structured data formats, and plain text files are the future. Stored in/with formats like yaml, we can (very easily) have flexible structures can adapt to the changing needs of a website owner.
• Some very large sites (eg. facebook, wikipedia) will likely always be powered by databases, because in situations where a single website has > 100,000 pieces of content databases begin to make sense. Remarkably, single websites so rarely have that much content. Particularly if engineered correctly.
• Most content on the web doesn’t change very often. We regenerate pages thousands and thousands of times a day that would be unlikely to be update more than a dozen times a day.

This is not to say that there aren’t several challenges to the prospect of websites powered by static-site generators/compilers. They are:

• Some content will likely always be compiled using some very basic server-side includes, and dynamic content will continue to be generated using java script or something similar.
• Authentication and web-based security will likely also need to be built into webservers directly (the direction, I think things are going in anyway) and complicated access control (for intranets, say) may still require databases.
• Web-based interfaces for editing (ubiquitous, in page, “edit this” links). and commenting systems often need more dynamic functionality than other content. We need to both figure out a way to do commenting/annotation in a static-based system and find a way to do commenting in a more socially productive manner (existing locally hosted commenting systems, are I think fundamentally broken).
• Concurrent Editing. Wiki engines address this to some degree, and I think we need additional productive ways of addressing this in a truly user friendly manner, that doesn’t rely on over powered databases for what is probably an edge case.

Thoughts? I’m not describing technology that doesn’t exist, but I am suggesting that the current “way of doing things,” isn’t the future of how we will “do content on the web.” The tools are out there, all that’s missing is a simple, user friendly, method for pulling all this content together.

I’m really interested in seeing what people are coming up with.

So I’ve noticed that my impulse on these shorter blog posts (codas) that I tend to just do my normal essay thing only shorter, which is more of an old habit than it is something productive or intentional. Weird. To help break out of this bad habit, I’m going to post some links that I’ve collected recently.

I saw a couple of articles on user experience issues that piqued my interest, perhaps they’ll pique yours as well: Agile Product Desgin on Agile Development and UX Practice and On Technology, User Experience and the need for Creative Technologists.

Cheetah Template Engine for Python. This isn’t an announcement but I’ve been toying around with the idea of reimplementing Jekyll in python (to learn, because I like python more than Ruby). Cheetah seems to be the template engine for python that looks the coolest/best. I need to read more about it, of course

I didn’t get to go to Drupal Con (alas), but there were a few sessions that piqued my interest, or at least that I’d like to look into mostly because the presenters are people I know/watch/respect: Sacha Chua’s Rocking your Development Environment Liza Kindred’s Bussiness and Open Source James Walker’s Why I Hate Drupal.

Sacha’s because I’m always interested in how developers work, and we have emacs in common. Liza’s because Open Source business models are really (perversely) fascinating, even if I think the Drupal world is much less innovative (commercially) than you’d initially think. Finally, given how grumpy I’m prone to being, how could walkah’s talk not be on my list?

Anyone have something good for me?

In the latest/forthcoming version of GNU Emacs there exists a daemon mode. The intent is to make it easier to run in one instance of emacs, and rather than starting new instances, you can run everything in one instance. Less overhead on your system, and everyone’s happy. Without daemon mode, you can still run in server mode and get nearly the same effect, but you end up with one emacs frame that’s the “host,” which means, if you’re dumb and close it (or it’s running inside of another process which crashes…) all of the frames close.

I suppose, as an interjection, that my attempt to explain why this is cool to a generalized audience is somewhat of a lost cause.

In any case, there’s a problem daemon mode doesn’t behave like anyone would want it to. This post explains it better than anything else I’ve read thus far, but it’s not all that clear. Basically when you start emacs --daemon it doesn’t load your .emacs init file correctly, and so things like display settings are off kilter, and can’t really be fixed. I resorted to running my “host” emacs frame inside of a terminal/screen session, because that worked and was basically the same from my perspective.

Nevertheless I’ve discovered “the fix” to the emacs daemon it to work like you’d expect. Run the following command at the command line (changing username and font/fontsize):

emacs -u [USERNAME] --daemon --eval "(setq default-frame-alist \ '((font-backend . "xft") (font . "[FONT]-[SIZE]")))" -l ~/.emacs

And then, open an emacsclient.

… and there was much rejoicing …

There are a couple of things that I can’t get to work reliably. Most notably, though the emacsclient works in terminal instances, it has some sort of problem with attaching new clients to X after an X crash/restart. No clue what this is about. Not quite sure what the deal is with this, but needing to reboot every time X goes down is a bummer. Other than that? Emacs bliss. For the moment.

So I was sorting through my org-mode files and I found a little snippet of code that I had lying around. I’ve had a problem with shell scripting for a while. I use bash a lot, and I’ve written a few functions, and procedural scripts that I’ve found useful in my travels, but anything that requires “logic,” often escapes me in tragic and epic ways.

Here’s the problem. I had a directory of notes that I had compiled for presentation in an ikiwiki blog for notes. As I wanted these notes to be in my org-mode system, I needed to take a directory of 60 or so files, and turn them into a single org file. As an additional bonus, I needed the files to be organized by date rather than by the alphabet. Also, as ikiwiki generated page titles from the filename, I needed to capture that information in the org-mode file. Here’s what I came up with

for i in `ls -t`;  do
   echo -e "$i" >> ~/org/legacy_notes.org &&
   cat "$i" >> ~/org/legacy_notes.org ;
done

It works as a one liner, but it works. I think previous attempts have left out crucial semi-colons or the do and done statements. No clue. Baby steps folks.

A few months ago I got a Happy Hacking Keyboard because, hey, I’m a writer and a GNU/Linux guy, and I use almost entirely keyboard driven software/desktop environment a good keyboard seems like a reasonable investment..

So after a few months, what do I think? The keyboard is great. I don’t miss the keys, I like having everything in reach, I like being able to have my tea close and not have to move as far for the mouse when I need it. Additionally, and you wouldn’t believe how true this is, but the keys feel so nice to type on. It’s nosier, the response is good (not buckling springs good, but quite nice), and I defiantly feel the difference between it and other computers (let alone laptops; I tried to type on a MacBook the other day, and it was quite nearly painful.) If anyone is looking for a new keyboard, this is defiantly one to consider, and if size is an issue, then I (probably) wouldn’t consider anything else.

Keep on typing!

Wordpress is great software, and I’ve been a user for many years. Many years. It used to be called “b2” and I used it then as well. There are a lot of more powerful content management systems, a lot of systems that are much more flexible than wordpress these days, and often I get the feeling that other platforms attempt to define themselves in contrast to wordpress. In the larger sense, this post is an attempt to resist this temptation while also exploring the limitations of wordpress.

Wordpress is a pure blogging engine: it provides interfaces for writers to publish weblogs (blogs), manage content (to some degree) and generate pages based on templates. Before wordpress, blogging was done either by hand edited text files, or by systems that complied static HTML from some sort of database.¹ Wordpress is an improvement because it’s easy to install, it’s reliable, and pages generate dynamically on viewing, rather than just when the site owner hits “save” or “rebuild.” In the end, we discovered that systems where managing “websites” was divorced from (even simple) server management had a great democratizing effect on content, and that’s sort of the core of wordpress.

Because wordpress is designed to be a blogging platform, it doesn’t need to be as flexible as other generalized content management systems. Flexibility comes at the cost of complexity, and developers decided that in some cases, less was, in fact, more. There are a lot of things that you could do with b2 (albeit with some hacking) because the site generation/templating system was much less rigid, at the same time, it was much easier to get sites with broken links, and bad pages, particularly as you changed from theme to theme. That’s bad, and it seems pretty reasonable to me to want to avoid that.

The end result is a program that does almost everything you could want it to do as long as you only want a blog, if you try and stretch it too far it simply won’t work. Well it will work, but the advantage of using Wordpress to manage a website that isn’t a blog (or very similar to one) disappears quickly when you have to impose informal limitations on how you enter content in the system to generate well formated pages. It’s a slippery slope, and you’d be surprised how quickly a site goes from being a standard Wordpress site, to requiring customized themes, specialized content entry patterns. And pretty soon, a lot of the things that make Wordpress “simple” and “essay,” aren’t really available to your new site. That’s the limitation of Wordpress.

Knowing where the line is, is often the largest challenge in Wordpress development, and being able to say, “you know, this is the kind of site that you really want to be building with Django, or Drupal, or Rails, or Expression Engine,” Or even saying “you know this is the kind of site that we could probably do more effectively using flat files and PHP includes. Wordpress is great, and in the cases where it’s well suited to the task at hand, it’s the ideal solution. In other situations? Less so.

Onward and Upward!

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?

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!

Before I made the switch to linux, my only computer was a single macbook. Great machine, and in addition to not being able to (really) use Awesome, I was pretty frustrated by the lack of screen space. I was (and do) need to filter through lots of different kinds of documents and I felt like I was spending half my time sorting through any of the several dozen (!) windows that I kept open. As a result one of my chief requirements for the new system was having the ability to run a 2 monitor (dual head) setup.[^DH] I was even willing to sacrifice¹ some raw power for this.

So here I was with a dual head setup, and a sort of lackluster idea of how to use all this new space, aside from the visceral knowledge that needed more room. I’ve tried a few things to try and use the space, but I continue to feel as if I haven’t found the right way to use this space.

I should preface this by saying a word about my window management software: it revolves around the notion of “tags,” which are similar to virtual desktops, so while I only look at 1-5 windows on each monitor there are many more than 5 windows open and running at anyone time.

My first attempt was to create task-centric virtual desktops, so that there were tags for windows that had to do with work, tags that had to do with fiction writing, tags for browsing the web, tags for chatting, tags for interacting with the system and so forth. This was an epic failure, as the joys of a multi-tasking operating system are that they allow you to have a number of different processes running in parallel, and if you have you window manager setup to constrain your to one task per screen then you’ve basically shackled your computer into only being able to do two things at once. Which is both distracting (as you end up hiding needed windows, or disregarding the established tagging systems. I also found that in an attempt to use both windows, I ended up using the middle half of each monitor more than I used the outer half.

My second attempt was to have a primary/secondary monitor setup, with my keyboard in front of the left screen which had most “action” related tasks (writing, email, etc.) and the right screen was for reference materials (web, chat, pdfs, etc,) and I’ve tried both organizing tags based on task/sphere, and also based on window type (so that “work” happened in more ad-hoc spaces). Neither works particularly well.

My current attempt is still largely based on the main/reference mode of operation, except I’ve made things a bunch less rigid, and mixed things up a bit to see if this makes things a bit easier to work with. I have background processes on the left monitors: email, web, file management on the left; org-mode files, and chat on the right. And then, I have writing spaces and adhoc workspaces on the left, with work and some project-specific workspaces on the right.

I’m not sure that this is the best thing. There’s a dynamic workspace/window tagging library, but I haven’t really tried it out, and I want to test things out on the laptop (one screen) first.

There’s got to be a better way of doing this. On one level this is a problem of riches, (how do I use all this space I have), but on another it’s a much more simple problem that addresses focus and the way that we present/organize information on our screens Thoughts?

Onward and Upward?