31.5.06. Third Time, Slow Time, Inventing, Revisiting, and Fighting

A couple of months ago, we started work on a major rewrite of one of our core sites. What started as a small and specialized e-commerce service a few years ago has grown mightily over those same years. The architecture, however, has hit a limit - especially when compared to the large push for what we want to do (and can do) next. The current site works great and handles its load and duties very well. But there are small annoyances internally with some things, and there is some growth and market potential that it cannot satisfy.

The first version of the site’s primary work was done in less than a month. The main focus of that version was the visitor’s experience. The original HTML mockups drove a lot of the site, and the implementation was primarily done in Zope 2, through the web, using templates, scripts, and SQL Methods. It was a nice enough system for the time - we were very fast with it, we could tweak elements in each other’s offices, etc. It ended with an all-night debug-and-deploy session, wrought with all sorts of strange problems and angst and fun. But it worked. We continued to work on it over the next few weeks, of course, filling in some major holes that couldn’t be filled in initial development and responding to site usage.

The biggest problem with that implementation was the administration side. Since we were the only users of the administration screens, we punted on that issue. There was no form validation. All of the database CRUD statements were entered manually. Zope’s SQL Methods made this a bit easier, but their main optimization is for read-queries. Any new field required numerous code updates all over the place. The whole business was a little messy back then - requiring us to print out certain reports and delivering them to our providers on time-constrained schedules.

The site was never empty, but it got perilously close a few times during the lifetime of version 1. But there was enough interest to keep it going. With eyes on expanding and getting new providers, with providing new services (including physical goods), and with running the business side of things better, we went into version 2.

As I saw all of the HTML forms and database statements I’d have to change just to accommodate the expanding and changing data requirements, I started looking at options for easing that pain. I ultimately rolled my own system focused primarily on the common CRUD operations. There was no object-relational mapping solution at the time that I liked. A problem, at that time, was that we had many queries in place that would not work in the object-relational tools available.

What I really wanted was an architecture that:

1. Helped me get important / core business and administration logic out of the ZODB. We wanted to have as much of the core software on disk and under source control as possible.
2. Dynamic form and SQL generation for common tasks (primarily in the administration section). I wanted this so that adding new fields to the database schema required only one or two changes.
3. Still allowed us to use Zope’s SQL Methods for generating complex queries.
4. Could be introduced in a way that the public application might not even be aware: instead of a folder full of Python scripts in the ZODB, there’d be a single persistent instance of a class that had many of those scripts as methods.

The resulting framework was essentially a service layer comprised of very rough Table Data Gateways. You couldn’t load an object out and do a jeff.hair = 'bleached' and have it save. The get/create/save statements basically took a dictionary (hash table) of values to save and would flush it out to the database, after harvesting some information. It was expected that the gateways would have the data prepared before passing it off to the lowest level interface, handle_op, which would perform the requested operation.

When dealing with fairly set data, such as a form, this didn’t really matter. I cared about loading and binding the data to the widgets when a page was loaded, and then parsing/validating/converting that data on save. For that, this system worked like a champ. For some other pieces of business logic, it did OK. It wasn’t great, but it was better than what we had before - especially because it didn’t require specialized update SQL to be written for those situations where just a couple of values needed to be changed.

That site has served us fine, and now the offerings on the site are quite full (many many pages). The content providers have access to their items and reports, so we no longer have to run around town delivering reports and lists.

Both versions were deployed, in full, and then continuously massaged over time. There was no ‘beta’. Some features sneaked in after the deployment deadlines. Some specialized parts of the system were overhauled a couple of times to deal with scaling issues - ones that we could never have predicted.

We’ve kept laundry lists over the years of the things we wanted to do, but couldn’t under the first two designs. Some of these came from dealing with some hacks pulled together for a couple of special customers, some came from wishful thinking, some came from complicated set-ups required to make certain rare items available for purchase in the existing system. In a getting real sense, this was OK, but not great. It limited our ability to start working with larger and more specialized providers.

Architectures have continued to improve over the past couple of years as well. When Zope 3, version 3.1 specifically, came out, we were able to do a major rewrite of a content system for one of our oldest customers. We were even able to pick up additional related customers as a result. We’ve delivered other solutions on top of Zope 3 and the ZODB (Zope Object Database) that have been both impressive and fun to work on, although sometimes Zope 3 can still cause me to go off in a huge screaming match.

I had hoped (and still wish) that for this particular site’s version 3 implementation we could ditch the relational database completely and just use the ZODB. Instead of classic Zope ZODB usage, where scripts and templates fill up the database, Zope 3 makes it much easier to keep that stuff OUT, and then easier to keep real data in. This is one of the nicer parts about working with the Zope 3 / ZODB stack: Python is just Python is just Python. There’s no translation layer, no tricks, trying to fake inheritance. There’s no real worry about translating statements into a query language - Python is the query language (with tools like the Catalog providing application level indexes for larger queries). I had an application that I was working on in Zope 3 that I thought would be a good testbed for writing as a Rails app - until I realized that Active Record’s inheritance model could never match my object model, at least as of Rails 1.0. I also played a little bit with Python’s Turbogears and SQLObject stacks, and they had me feeling pissed and frustrated within seconds. No offense to their authors, but they just did NOT work for me.

But the decision was made that for this site, we would continue with using a relational database. Well, I knew the strengths and limitations of our current systems. And I admit, I was envious of Ruby on Rails. In fact, I even suggested that we ditch Zope for this project and use Rails instead! But it was feared that there was no time on the schedule to learn Ruby. We did, however, agree on wanting a real object-relational system, or at least something more object oriented than what we used for Version 2. Version 3 has richer business logic requirements, and I’m happiest when that code can look as clean and natural as possible. I also wanted it to be easy to define new pages and views and to have to go through less guess-and-hope work than Zope 3 (as of 3.2) typically requires.

So we’ve birthed yet another in-house framework because there’s little out there that’s satisfactory. The one thing that is satisfactory is SQLAlchemy. I built a base storage framework on top of that which allowed us to use SQL Alchemy fairly transparently from within Zope. Fields and properties now let us define and use relationships fairly transparently. Items get bound to their context, are easily traversable, and can even masquerade as Zope containers without interfering with SQLAlchemy’s on system of managing work. We also birthed a base web framework that provides some useful base classes for constructing the kinds of pages and sub-views that we need with ease. These base classes corral some core Zope 3 features and some other in-house features together to ease our web development.

It’s all pretty cool, for what it is. But it’s going so slowly that I can’t help but wonder if we would have been better off working in Rails. I still haven’t found anything in the Python world that I’d leave Zope for, but Zope 3 continues to jump between being insanely cool and powerful and flexible, and being incredibly frustrating and aggravating. That I’ve been able to pull many of the tricks I’ve already been able to pull is a testament to the better parts of its design.

Even with all of my tricks and base classes, it can sometimes still take an entire morning just to get what seems like a simple page together and rendering. On the other hand, once you get pieces in place they’re pretty sturdy. There’s low likelihood of accidentally overriding a critical method name or a view/page that applies to a different context or interface layer.

But as it’s been going so seemingly slow, this development, I start to wonder why it feels that way. I really was trying to give myself a system where I could enjoy the benefits of Zope 3’s Component Architecture with an intelligent database / object-relational mapper while also enjoying the benefits of Getting Real. “Getting Real” isn’t anything really new to me (or many people). It just helps give you the OK to say “no”. Martin Fowler’s book, Refactoring, made me realize that bad smells are OK now, so long as they’re cleaned up later. In the interest of getting something done, it’s hard to go for purity. Or in the case of Python’s “import this”:

Special cases aren’t special enough to break the rules.
Although practicality beats purity.

So, what is the problem with me then?

I think it comes down to a very special case: the major rewrite. This is not a new application for us, nor is it a moderate upgrade or maintenance release. We’ve acknowledged that the existing architecture has issues when it comes to certain growth paths. To this point, we’ve also been good in saying “no” to those growth paths. But business situations and opportunities have changed.

One problem with the rewrite is the knowledge that it’s already been done. “We already did this three years ago, why can’t you show me it working in the new system already?” There senses of worry, fear, excitement all change. This is further exaggerated by the fact that these kind of rewrites are often architectural, perhaps deeply architectural. All of those agile decisions made in earlier versions no longer apply, since many of those decisions may have led to the limitations you’re trying to overcome. Those decisions were right at the time, and have been right for the past few years. But now you realize that being able to do more promotions, discount options, special offers, are among the things you really want to do with the cart. You also need to handle more delivery options instead of the two you’ve used for the past two years. You fight and push and think and tango with the cart, just focusing on shipping, with coupons in the back of the mind. Part of you thinks “I just want to add a shipping column / attribute here and be done with it, and we’ll expand it later…. Oh wait… This IS later… Oh yeah, we need to support more options… Oh yeah, this is one of the growth areas we’re focusing on. Crap!”

It’s an interesting struggle now, those two sides in my mind. In practical terms, I just want to add an extra column or attribute and be done. But I know in a week it’ll already be pushed to its limits. Better to apologize for lack of screens and work this the hell out now. Nothing fancy - keep the interfaces and collaborators simple, and expand on them if needed when more data presents itself.

26.5.06. Personal File

Last night I floated like a ghost past the strip club, under the freeway, over the railroad tracks, past the big electric sign and refrigeration companies and worn out corners until I got to the super-center. I needed milk, inner tubes for my bike, and dog treats. Of course, my cart started filling up with much more than just that. And in the middle of my 11pm shopping excursion I stumbled across the music/video section. As I stared (half-angrily) at the so-called “top sellers” in the country department (it’s where my cart stopped), I remembered coming across a new Johnny Cash collection on the iTunes Music Store.

So I now have Personal File. It’s a collection of recordings Johnny made (circa 1973-1980) in his studio. It’s just Johnny and his guitar: the same kind of intimate, personal, and raw sound that made the first American Recordings album such a standout. Some of these pieces are recognizable, such as When it’s Springtime in Alaska, It’s 40 Below and Jim, I Wore a Tie Today. Many songs have stories attached to them - why Johnny remembers it, why he wrote it, why he sings it, etc. It was a style seen on some of his commercial albums from that time, although those were accompanied by a larger band and sound.

The second disc of Personal File hasn’t grabbed me much. It’s fairly religious, and while I respect Johnny Cash’s religious strength, I have little interest in it. There are some nice songs on that disc though. But the first disc is the good one. It’s from a good time in Johnny’s life - settling into his life with June, his drug days behind him. The voice is powerful, most of the songs quite rich. A very enjoyable listen.

25.5.06. Online / Offline / Middle of the Line

I’m still offline at my new home. Curiously, this hasn’t been a huge deal for me, so far. I’m getting home so late (relatively), and then still have to walk the dog (if she stayed home that day), feed her, feed myself, etc. Other factors have been eating up bits of my evenings as well: cleaning out the old place (finally done as of yesterday), getting some finishing-touch little furnishings (one at a time since I don’t drive), and yet-more organizing and layout.

The situation with Comcast has just pissed me off enough that I haven’t wanted to call back to find out what’s next. Part of this is due to the inherent stress of workdays recently. I don’t want to add to the pile with long calls and situations where no one really seems to know what’s going on. But I know I have to, soon. Tomorrow.

I have not had any major beefs with Comcast (and AT&T before them) up to this point. And the whole situation may not be their fault, but rather the fault of bad information and the odd nature of this particular move. But as someone who has been a good customer for so long, I do feel a little insulted that someone hasn’t jumped up and said “hey! you know what, you’re a valued customer and we want to keep you so I’ll figure this out personally.” Not that I expect the average customer service person to care that much, but maybe I could be passed on up to someone who does.

This is a big thing for me right now. If they don’t seem to care, why should I? And if I don’t care, why aren’t I looking for alternatives? I still don’t really want to deal with phone companies and DSL, but I know it’s an option. And as far as television goes: I’ve long known that I need to cut back. As much as I’ve loved HBO and its original programming, I haven’t even noticed that I’ve missed a couple of weeks of the Sopranos now. I get a handful of channels off my antenna. I’m starting to think that maybe an option like USDTV could work too. Dish/Satellite is out. I hate those things and don’t really have anywhere to put the damn dish anyways.

But it comes down to this: I was told what the builder was told. “When the first person in wants cable, we just have to connect it to the building. It’s there and ready to go otherwise.” But now even the landlord / builder are getting the run-around.

This service is supposedly “right there, almost ready to go”. Why can’t I just get it turned on already?

Anyways - thank goodness for Apple’s iDisk service (as part of their .Mac offerings). iDisk can be synchronized and worked with off-line. So I can at least keep my iBook up to date with my plans/actions list and a few other key documents, and I can update source code to work from home by bringing the iBook into work and using CVS. This helps with the offline mode - knowing that some information, including work stuff (useful in these busy times) can be brought with me even if there’s no connection. This is the downside to otherwise wonderful services like Backpack: except for emailing myself a copy of pages, I’m cut off from any information I may be collecting in a system like that.

This is something that I’ve been concerned about ever since Microsoft first started promoting “internet everywhere” inside of Windows. I don’t use Windows, so it didn’t concern me much (but it’s been interesting to see how their strategy effectively made the security problem they wrestle with today). But I always wondered: “what happens if there’s no internet? if the network’s down?”. The Dashboard in Mac OS X 10.4 is effectively useless on my iMac at home now. Not that I’d expect anything different: how can it update its backpack widget and all of those weather feeds with nothing to feed it? It’s just sad though, seeing that computer that is normally so great become so useless without a connection. I can’t upload photos, can’t update my web site, can’t collaborate with musicians, can’t shop for art supplies, can’t check the train schedule, can’t get new documentation, can’t get new music from the iTunes Music Store, can’t manage the Netflix queue that I’m finally going to set up… All of these things, taken for granted. And now, thanks to a stressful and confusing mess, I don’t know when I’ll be able to take them for granted again.

Helmet Head

"But I don't have $100 and I can't come by with a truck for two weeks..." No piano for you! Life sucks; get a helmet.

24.5.06. Enjoy Forgetting

I really enjoy forgetting. When I first come to a place, I notice all the little details. I notice the way the sky looks. The color of white paper. The way people walk. Doorknobs. Everything. Then I get used to the place and I don't notice those things anymore. So only by forgetting can I see the place again as it really is. - David Byrne as Narrator, True Stories (1986)

23.5.06. Post to MarsEdit from QuickSilver, using Markdown

This is an AppleScript I cobbled together real quick to post to this weblog quickly from QuickSilver, using MarsEdit to handle the posting. I don’t claim to have any real in-depth knowledge of AppleScript, and I doubt this will win any “prettiest” or “best” code awards. I just thought it might be helpful to others.

    using terms from application "Quicksilver" 
        on process text ThisClipping
            my SendToMars(ThisClipping)
        end process text
    end using terms from

    on SendToMars(IncomingString)
        set mdcommand to "/opt/local/bin/Markdown.pl " 
        set webtext to do shell script "echo " & quoted form of IncomingString & " | " & mdcommand
        tell application "MarsEdit" 
            make new post window
            tell post window 1
                set body to webtext
                send post to weblog
            end tell
        end tell
    end SendToMars

Any text formatter could be used here – I went with Markdown for this situation as it seems to be the best fit for the tiny little text window you get with QuickSilver.

To install, I put this in Library/Application Support/Quicksilver/Actions inside my home folder under the name Post to Griddle. Any text typed can then be posted immediately. Your mileage may vary, depending on your MarsEdit configuration.

This is a test, of sorts, to see how easy it is to write an applescript to send a post to GriddleNoise via MarsEdit.

It's an attempt to see how easy it might be to do some tumblelog style posts using QuickSilver as the entry pad.

22.5.06. Settling In

I moved into my new apartment a week ago. Except for one glaring problem, it’s really quite nice. The one glaring problem is huge: no internet, yet. I’ve been a happy user of cable based internet for most of the past six or seven years, from Fredericksburg to Salt Lake. I haven’t even had a phone line since moving back to SLC.

I’ve been happy enough with cable internet, having had very few problems over the past few years. But right now, COMCAST is having troubles recognizing the existence of my new building – even though the builder remembers working with COMCAST to lay the cable. It’s there, apparently, waiting for the first tenant to place a subscription order. And hey! That’s me! I don’t think it’s any major fault of COMCAST’s though… Not really anybody’s fault. But I hope it gets resolved soon.

The apartment is small, but cozy. And it’s not even really that small. This is the third in a series of living spaces that have been open plans: the only doors (besides the entrance) in my last three apartments have been for the bathroom, storage areas, and (in the case of the last two) a/c and water heater access. What differentiates the new space is that it features an upstairs loft, letting me separate the living space from the working space while still keeping everything open. It also means that the ceiling in the working space is extremely high. Actually it slopes back as it’s an arched roof.

The building is a converted warehouse. It’s a newer warehouse than the ones I was previously in, with cinderblock walls. It was one of those high ceiling single-story warehouses with the arched roofs, which is where the room for the upstairs loft comes in. The cross beams up there remain exposed (providing fun places to try to hang / tuck things). The ceiling/roof is punctuated with clear skylights, with one in the loft area that can be cracked open for ventilation. I’ve enjoyed being able to sit / lie up there while watching clouds go by. The arched roof creates an interesting sense of coziness as it slopes down away from the living space. From my reading space in the corner, the place feels snug – almost like a cabin. I can then go over to my writing desk and peer into the workspace, enjoying the open nature. But while sitting and writing, it’s never overwhelming.

Another feature across my recent series of apartments has been hard flooring. Hardwood floors in one, painted plywood/particle board (yep) floors in another, and in the new space: brushed concrete!!! Damn that’s nice. Unlike the last two apartments though, I also have carpet in the loft – a feature that my dog greatly appreciates (thin-skinned bony greyhounds love soft surfaces).

While the kitchen and bath (on the main level) and living space (loft) feature regular lights, the workspace can be illuminated by two pairs of halogen lights. Excellent for painting, drawing, recording, everything! A large modern ceiling fan in this area circulates air and drives down the need to keep the air conditioner on constantly.

Perhaps the best feature of all is the neighborhood. I’m surrounded by metal recyclers, an old concrete plant my dad worked at when I was young (primarily empty now, although its large silos still seem to be in use). Empty warehouses, active warehouses and industry, random pockets of artists, trains, overpasses, underpasses, industrial back-alleys, a pyramid, and more. It feels good to be out just-ahead of the city. My last couple of places were a little closer to the heart – different sides of the heart, though. The area I moved out of (and where my office remains) has started to feel different over the past few months, and I don’t like the feeling. It’s not bad – in fact, I’m glad my office is still here. There is a lot of interesting growth happening and on the verge of happening here. And suddenly, it felt boring. It felt too contemporary when I wanted it to feel more creative, which is strange because I lived in the actual artist block of Artspace and had some great (and creative) neighbors. But the edge was gone.

I think my last trip to New York woke me up to this feeling. I played a show in the Red Hook neighborhood of Brooklyn and fell in love. I fell into a funk as my plane landed back in Salt Lake. Over the next couple of weeks I daydreamed of a new space to live and work. I hid in old films, images, and articles of SoHo, and scoured Flickr archives for photos from different neighborhoods and cities that captured an elusive feeling that I was wanting back. My lease came up for renewal, which put me on month-to-month until I renewed, and I decided to take a serious look around at some new options. Ideally I wanted a place I could convert on my own, with a big garage door and a layout that’d let me keep the dog(s) safe on one side while I worked on the other. I don’t really have the spare time or funds to support such an endeavor at this time. Still, I decided to look around and see what was available that would allow me to separate workspace and living space, or that I could buy. This was when a flyer showed up under my door announcing the lofts that I’ve now moved into.

As I walked down to check them out, I realized that they were in the heart of the industrial area that I loved. In fact, I had been walking through that area a couple of weeks prior and had been kicking myself for not having a camera along with me. The energy of the area was more active, fresh, raw, gritty, real, and beautiful – to me anyways. And upon seeing these new spaces and their design, I signed almost immediately. A couple of weeks later, I was moved in. It all happened so fast and naturally, just a straight-ahead instinctual thing. Compared to all of the stress I’ve felt this year, it was nice to do something big that felt just right.

Best of all – the dog loves it. In fact, she seems even more playful now.

All I need now is internet.

11.5.06. Tinderbox, OmniOutliner, and GTD (again)

A few months ago I bit the bullet and purchased Tinderbox, an interesting outlining/mapping/linking application for Mac OS. I primarily purchased it to use Ryan Holcomb’s template for a Tinderbox based system for the Getting Things Done workflow, but I also dreamt of using it for more.

I haven’t used Tinderbox much in the past couple of months. Kinkless GTD 0.83 came out along with the OmniOutliner 3.6 beta (now in final release), and it solved many of the issues I had with earlier versions of the KGTD/OmniOutliner combination. Prior to OmniOutliner 3.6, there was just a single toolbar customization setting for OmniOutliner. In most Mac OS X Cocoa apps, you can customize the toolbar pretty easily. It’s just one toolbar – not the big mess of toolbars that the Office systems have become. Generally, it’s been a very handy feature.

As OmniOutliner grew terrific Applescript support, they allowed you to add your scripts to the toolbar. Kinkless GTD is, in fact, a handful of Applescripts that do an implementation of the Getting Things Done method of planning / management. By putting a few new buttons on the toolbar, you essentially got a new specialized application that took advantage of the terrific nature of OmniOutliner (still the easiest and most fluid outliner on Mac OS X, and looks great too). The downside was that if you wanted to work on other outlines, the GTD buttons would still be there even if they had nothing to do with the document you were working on.

With OmniOutliner 3.6, you can now have document specific custom toolbars, meaning that my KGTD outline no longer interferes with other outliner documents. A few other concerns were dealt with in the new KGTD release that made it feel much more natural, and I found myself switching back to the OmniOutliner/Kinkless combination as my “trusted system”.

There’s a big difference in styles between how OmniOutliner / KGTD work and how Tinderbox / GTDRules work.

About OmniOutliner + Kinkless GTD:

• KGTD is an aggressive user of OmniOutliner’s extensive Applescript support (and in turn, OmniOutliner’s Applescript support has gotten even stronger).
• KGTD’s main unit of work is a big synchronization script that moves and copies outline elements around. In the Getting Things Done method, you “plan in projects and work in contexts”, and often need at least two views of your actions – the plan list, and the actual “do this next in this place” list. Kinkless GTD manages both by copying/merging/moving.
• By using AppleScript so extensively, Kinkless GTD works well with tools like Quicksilver, whose motto is “act without doing”. It’s easy to send an action into your KGTD inbox without ever switching applications or even taking your hands off the keyboard. Kinkless GTD has also done a lot of work to integrate with Apple’s iCal calendar, which in turn allows one to use various menu bar tools and Dashboard widgets to keep an eye on actions without having to bring OmniOutliner into focus. The use of applescript brings integration with other common tools.
• However, KGTD requires manual execution of the synchronization command. It’s possible to end up with ghosts and duplicates since it’s doing so much copying and moving. It’s gotten a lot better when it comes to the ghosts and duplicates, but it means that an active action may have two or three copies in the same document, all separate outline rows.
• OmniOutliner is a single-window application (well, single window per document). But with the new sections and navigation features in OmniOutliner 3, it’s quite easy to move around and focus on particular elements.
• As a native and modern Mac OS X application, built by a shop with a long history of Cocoa/OpenStep/NeXTStep development, OmniOutliner also gets to take advantage of many advanced Mac OS X features. Services, text system plug-ins, etc. This includes automatic spell checking, in-place dictionary look-ups, and more (ie – with “Equation Service”http://www.versiontracker.com/dyn/moreinfo/macosx/14090 installed you can easily convert LaTeX source to a rendered PDF and back again, without OmniOutliner ever knowing anything about LaTeX)

About Tinderbox + GTDRules:

• GTDRules is an aggressive user of Tinderbox’s system of agents and prototypes.
• GTDRules main unit of work is a collection of agents that are always running. Agents in Tinderbox are live queries which can also act on the items that they match. In the document view(s), found items are displayed as children of the agent. Most of the agents in GTDRules are ‘contexts’ (again – plan in projects, work in contexts), showing the next actions for the office, for home, for errands, etc, under the agent.
• Synchronization is always happening, so when an item is marked as complete, it disappears from the agent displaying it immediately.
• Data is not duplicated – the agent results are treated as Aliases, which you can also make manually in Tinderbox. Aliases are like their desktop / file system counterparts: a symbolic link. This way, there are no ghosts or duplicates.
• Tinderbox has a menu, customizable per document, called “Value”. You can use the Value menu to quick-stamp values on Tinderbox nodes. Since there are no checkboxes in the outline views, this is how you mark something as complete. But it’s also a way you can select many actions and set them all to be “Office” actions, in one swoop. Or put them on hold in one swoop. Customizing this menu is pretty easy.
• GTDRules also takes advantage of Tinderbox’s “OnAdd” rule setting, allowing you to set default values for nodes added – ie, a work project can easily be set to have its children be ‘Office’ prototypes so that they show up in the Office context, but projects for an on-site customer could default to ‘Remote’ instead.
• Tinderbox allows many windows to be open for a single document, and remembers their placement and displayed content. This allows one to take a big system like this and section it off into numerous views.
• Tinderbox, however, is very much a classic style ‘Carbon’ application. It still feels like a custom classic Mac application, and does not take advantage of many modern Mac OS X features – even ones that are available to Carbon, such as Services. This isn’t a HUGE deal – at least it’s native – but it’s frustrating to use the Font menu when I have so many many fonts installed that are so easy to work with in Cocoa text areas (using the font browser in OS X).
• Tinderbox has practically no Applescript support. It’s an island. Within the system there are a lot of things you can do. But you can’t easily send yourself notes from Quicksilver, from Mail rules, etc. There’s no integration with iCal or anything else. Using Tinderbox is almost like using Squeak on Mac OS X. Yeah, your mouse and keyboard and the clipboard all work, but beyond that it’s a universe unto itself.

Tinderbox’s isolation was a key figure in driving me back to Kinkless GTD / OmniOutliner. The GTDRules implementation on Tinderbox is a more “pure” implementation of the GTD workflow and easier to customize to one’s preferences (no applescript programming required). But data entry – especially of the quick “i need to remember to look at this later” variety – is not its strong suit here. There was something about it that started causing me stress when I’d look at my system. Maybe it was me getting sloppy and not cleaning / planning as well as I should. But something would just feel off.

All of that said, Tinderbox has a lot of great features that I’ve been meaning to explore. The euc.cx universe is ever growing, a great jumble of myth and fact, legend and memory. I’ve been wanting to start setting down all of the characters, locations, productions, etc, of it all and exploring the relationships. This is Tinderbox’s strong suit – links, relationships, visual maps (as well as outlines), prototypes, custom data, all should play in here. I really do need to keep myself still long enough to start learning how to do this. And I want to write again. Like really write, in hypertext, with relationships and cross references. I tried this once with ddec, a system based on an old implementation of the FTrain sitekit. But I hated writing in XML. (I just hate XML. I don’t care about it as a storage format, but I do hate writing in it, configuring in it, etc). This kind of writing is the real concept behind Eastgate as an entity. Whether anything will actually happen is hard to say at this point. But it looks like my writing desk will be in an excellent location in my new space and I hope it’ll help inspire me.

The view from where the desk will most likely be. (It’s a console table actually, just the right size for an iBook, a small lamp, a pile of notebooks, and the dog’s leash):

5.5.06. Studio Peak (Inspirational Peek)

As I’m getting ready to move to a new loft that will give me a nicer, more dedicated working space, I’ve found myself doing a lot more painting. I was working on large canvas in front of this stack of metal cube-ish storage things. As I was taking some pictures of the work in progress, I realized I needed to get a shot of what sits up top. Here, in bite sizes, are a lot of representative elements from artists, designers, factories, and companies that are a pretty strong source of inspiration. So, to step away from the usual crankiness and software focus for a bit, I thought I’d share a bit:

SuperSampler, Lubitel, LCA, and Baby Holga (110 Format!) Cameras. The 120 Format “standard” Holga is on top of my desk and not with the rest of the family. I do love these cameras: they have a lot of personality, with the LC-A being my favorite point’n’shoot 35mm camera ever. I don’t do film as much these days. For a few years my walk home took me past a few places where I could get film developed (including the 110 and 120 formats), often dropping the 35mm off in the morning on the way to work and picking it up on the way home. I haven’t had that since I moved into my current place, and that’s taken a big bite out of me rolling over new rolls as often. Plus I do have the digital camera that’s great for taking endless pictures of the dog, of paintings, and flash conditions. But it’s a soulless camera compared to these guys, most of which are completely themed around a terrific (and fun) mantra: don’t think, just shoot.

Brushes, Brushes, Brushes. Some of these brushes came with me back from Virginia and are still in pretty good shape – probably because I don’t paint nearly as much as I used to. But when I got my current place I finally got that container they’re in, which has made access to my core set much easier than my previous contraptions.

Helmut Lang promotional cards (from one of the last seasons). Helmut Lang was my favorite designer, with a terrific design aesthetic that was applied to everything under the brand. The flagship store in New York, designed by Richard Gluckman, was a terrific piece of architecture. Completely opposite of most New York stores (crowded, impersonal, or overly flashy), the Helmut Lang space used design to usher you in to a private area with large aisles and easy access to everything, without ever telling you what tricks it was pulling. It was an amazingly comfortable space. There was a “complete experience” about Lang that I sorely miss.

Ryoji Ikeda ‘Formula’ DVD and Book. Another terrific aesthetic minimalist, Ryoji Ikeda’s installations and a live set are showcased in this excellent volume. Ikeda is another artist who, like Lang, seems adroit at knowing what to take away, what to shift, and what to tuck into a piece of art (design, clothing, composition).

New reissue of Pizzicato Five’s Romantique 96, in front of Merzbow ‘Senmaida’ card (making it look like Maki and the Dalmations are on a Merzbow promo here). Two more excellent Japanese artists. Pizzicato Five kept many Jet Age fashions, designs, and ideals alive in their music. Their album packaging was often a step above (with only a couple of the U.S. releases falling short). Credit cards, luggage tags, postcards, stickers, bookmarks were among the things one could find inside a common release. And of course, there were the pictures of Konishi and Maki. Beautiful music, and a favorite artist of mine for years. Merzbow is almost their opposite: harsh noise. Hundreds of releases across an almost equal number of labels and distributors. He carries on almost a pure dadaist spirit. The cover art and packaging quality can vary wildly. The noise is almost always top-notch and he remains one of the kings. The postcard (mostly hidden in this photo) is from Senmaida which featured art by Val Denham that I just had to have for the picture alone.

Stack of book size Hafler Trio and Pizzicato Five releases, more albums in excellent packaging. The Hafler Trio being another terrific inspiration on many many fronts. Among other things, The Hafler Trio has played with sound-as-high-art, putting out releases in very limited numbers and with many extras in the packaging or experience to make it especially worth obtaining.

Brazil!. On VHS. Ahhh, Terry Gilliam.

“I draw on anything for inspiration – a fond memory, a piece of paper, a wall in a train station” – Danger Doom/Talib Kwali

Tools

I’ve never been a fan of IDE’s. I grew up on Commodore 64 BASIC – always on, just start typing in code and it works. I used IDE’s a little bit way back in my high school computer science day, but I remember it as little more than an editor / compiler combination (Lightspeed Pascal on Mac System 6). After that, I did very little programming for a few years except for casual purposes until I started using Python in 1996.

Most of my Python programming career has been focused on web development, and subsequently most of my development environments have been on development servers. For a good stretch of time, my editor/environment of choice was XEmacs. A couple of years ago I switched to VIM (lighter weight, didn’t need to bother setting up X Windows any more, and I could go into a stripped down production server running bare bones VI and not feel completely lost). A couple of months ago I started using TextMate pretty heavily, and started working on my desktops again since Mac OS X is, after all, Unix. Using DarwinPorts I could get the requirements for both Zope 3 and Ruby on Rails going pretty easily. And in this “just a plain but smart editor please” camp I remained, using the terminal to start and stop servers, to debug, to watch logs, etc.

But the other day I decided to check out RadRails, an Eclipse based IDE for Ruby/Rails development.

And holy shit, I was impressed.

Traditionally IDE’s have bugged me with their ever proliferating collection of panes and tabs. Too much noise! Too much to set up! Too much fighting to make it work my way! But with a little bit of preference tweaking (to point RadRails at the right Ruby / Rails installations on my desktop), I got RadRails running. I didn’t use it heavily (I’m not doing active Rails development, but continue to check it out from a point of envy / curiosity), but I was impressed with what it had: good knowledge of the Rails Generators, the database explorer, consoles, log watchers, etc. All things that I’m sure IDE users take for granted. I was especially impressed with how easily one could maximize any pane to be full-window size, and then go back to the many-many-many-views, using just a double click.

While it still doesn’t feel 100% native, RadRails/Eclipse actually performed and behaved rather well in Mac OS X – better than any other Java application I’ve used. Better by a long shot.

Now where’s something like this for Zope 3? Especially for my bastardized system using SQLAlchemy? :)