3.2.13. Coming Around to Sublime Text

So, quite late to the party, I'm starting to come around to liking Sublime Text 2 after many months of using BBEdit 10 as my primary development editor. I still like BBEdit, but Sublime Text is starting to pull away.

Some of the things that I like about BBEdit is that it doesn't have this runaway set of extensions and packages. It just works pretty damn well out of the box. BBEdit also has a real manual. And a real preferences UI. BBEdit is fast, handles large files well, and is very Mac native.

I decided to take another look at Sublime Text recently. One reasons is that my previous script for integrating PyFlakes into BBEdit broke in BBEdit 10.5, and I was starting to lose time to little mistakes that PyFlakes can find before I restart a dev server. I had a "PyFlakes on Save" in TextMate that I was really starting to miss. I knew there was something similar for Sublime Text and wanted to check it out. Enter SublimeLinter.

I'm not a fan of keeping track of lots of custom little packages and learning them. I have important work to do, and one of the reasons I stayed away from Sublime Text was my worry that I would spend more time tinkering with it to make it useful than I would spend doing my work. However, on re-evaluating Sublime Text, the following built-in functionality is really killer and has caused me to seriously consider a full switch:

  • Knowledge of directories in 'quick open / open anything'. Neither TextMate nor BBEdit seemed to do this. I can have large Python customer or internal projects with many files named 'interfaces.py' or 'base.py' or 'configure.zcml'. Doing a quick open to get to one of those files in other editors hasn't worked out too well. In SublimeText, I can start typing the path and hit '/' to start matching against that subdirectory.
  • Open Anything rocks. Being able to not just jump to a particular file quickly, but to then navigate right into its classes/methods/etc, all from the keyboard, is again pretty damn amazing. And fast!
  • Multiple Selection. being able to quickly rename a variable or method and also change all of its other uses in one fell swoop is pretty neat. I've generally solved this with "use selection for find / use selection for replace" but Sublime Text's option seems even better.
  • Split Windows. TextMate 1 never offered this. BBEdit allowed splitting the same file, but I don't think it allowed splitting multiple files. In general, this problem is solved with multiple windows, but I've missed being able to split windows with different files like I could do so easily in Emacs and Vim. It's nice to have a fairly modern editor that is fairly native to OS X that does this. This is especially nice in the full screen and 'distraction free' modes that I like to hit from time to time.

Something that was bothering me back when I used TextMate, and Emacs (and sometimes Vim) before that, was how out of sync my home and work setups could get. I do very little coding at home any more, and any time I would open up my editor, all of the little settings and massages that I had set up at work wouldn't be there. BBEdit 10 solved this with some native support for storing preferences and snippets and scripts in DropBox. I found some tips and tricks for storing Packages and Settings for Sublime Text and they seem to work.

Labels: , ,

31.1.13. Refining my Work Contexts in OmniFocus

Contexts are a major component in the GTD system by David Allen, and thus figure prominently in OmniFocus. Understanding and working well within contexts is an ongoing process. Some are immediately understandable, such as "Grocery Store" or "Home". Some may be devices, such as "Phone". These are known physical limitations where an action can only be performed in that physical space or device.

My life doesn't involve a lot of physical contexts outside of errands (then grouped by a couple of common errand types, and then by store for anything really specific), home, and work. But 'Work' is where I do and use much of my planning. I found that just having that as a lone context didn't work for me. Years ago, I set up two sub-contexts, Coding and Office and that got me by for a while, with most work tasks being in Work : Coding. This is still the case today, but I've recently found that it's helped to create some additional contexts that revolve around tools and responsibilities.

My work sub-contexts:

  • Coding, wherein I do most of my work. This is the editor - terminal - browser cycle, usually. For the longest time, this context was synonymous with "@work", as it was, well, what I did.
  • Deployment, a newly created context. This also tends to involve the terminal, but doesn't really depend on the editor or other bits. It tends to mean kicking off some automated scripts and keeping an eye on them. I separated it out into its own context so that I could see these separately from all of the potential coding "next actions", as deployments may have a higher or different priority. For example, I can deploy while eating lunch at my desk, so I might let these pile up from various other projects.
  • Research. The actions in here vary, but being in this context often signifies needing to crawl through code, archives, or the internet to learn something new or be reminded of how something works.
  • Basecamp, for needing to interact with the Basecamp project management system. The actions for this could mean just marking a task assignment as complete, or it could mean needing to write a message or comment to communicate with the team. I found that these kinds of actions were starting to slip from my head.
  • Agenda for anything I need to bring up at a meeting.
  • Documentation for tasks needing a bit of extra focus for writing and publishing.
  • Office for anything generic that can only be done at the office. This might mean something that requires a printer (I have none at home), or it might mean something I need to pick up or drop off at the office.

The nice side of this is that I can just park OmniFocus on my iPad in the "Work" context and see the available actions in all of these sub-contexts. The context they're in might let me know the time or tools involved, and that can help me make decisions about what to do next when I have multiple things happening at or near the same time. For example, I met let a couple of deployment tasks queue up, or I can do a deployment task while working on another project's coding task, as deployment requires little physical or mental labor but may require a lot of watching and waiting for changes to roll out across our servers. My Basecamp tasks can queue up for the end of the day, and have been helpful in reminding me to update our central project system used for company communication.

There seem to be some people these days wanting "multiple context assignment" in OmniFocus. I do not. I'm happy with the hierarchical context system. When in work mode, I can choose the level at which I want to focus and tune other things out. OmniFocus's hierarchical contexts also make re-organization easy without losing assignment. If a certain hierarchy isn't working out, I can change it with some dragging and dropping. This has helped keep my system functioning for me as my needs and expectations have evolved over the years.

Labels: , , , ,

8.1.13. Collect, Clarify, Organize - Guide to Evaluating Personal Task Managers

I've recently discovered the excellent Mikes on Mics podcast and have been listening to some random episodes. One episode I was interested in was Episode 5, Taking You To Task where the hosts talk about choosing task managers. They spent a lot of time talking about OmniFocus and Asana and some time talking about general evaluation of tools, and while they often recommended "find the tool that works for you", I don't think they established a good criteria for selecting a task manager. It got me thinking about the steps I find important.

I'm going to focus on personal task management here. Group / collaborative management rarely applies to a "whole life" scenario and is typically not something that is chosen by end users anyway. Someone who is a freelancer working with various groups of people at different times may benefit by such a system, but for the most part I believe that group/collaborative task management can be a second level system if it is needed in one's life.

So what should a personal task management tool provide? A good system should help you collect, clarify, and organize, to borrow terms from David Allen. To borrow terms from the Rational Unified Process, these steps may be: inception, elaboration, construction, and transition. Finally, there is also review. When evaluating tools, it may help to make a list of these things and try to answer how well each tool helps. The short list is:

  1. How easy is it to rapidly enter things into the tool?
  2. Is it easy to edit and elaborate on things once they're in the tool? Is it easy to defer things off to the future?
  3. How easy is it to group and organize tasks? Does the tool support organization in a way that reflects my system or brain?
  4. Once tasks are in the tool, how easy is it to focus on just the things I need to get done now? How easily does it let me define what 'now' means?
  5. Can the tool be trusted to be with me and reasonably up-to-date wherever and whenever I need it?

I expand on these topics, and more, below.

Collection (Inception)

Collection is an important step. How easy is it to rapidly add new items to the tool? This should be offered in a way that can be as unobtrusive as possible. On the desktop, many task managers feature a 'quick entry' window that can pop up, accept input, and disappear. Some may accept emails, either via special rules and scripts that run inside the mail client; others may have a dedicated email address. On devices, does it support input within a tap or two of the launch screen? Does it support voice? The tool should not only make it easy to add new items, but it should make it easy in a way that makes sense for how you use it. This can be easily tested within any desktop software's evaluation cycle.

A good modern task manager should have an "inbox" which means "collected, but unprocessed items." You should be able to add to the inbox easily and without guilt. You should also be able to process that inbox easily, which is discussed in the following steps.

Clarification (Elaboration)

In collection mode, you may jot down just a couple of words or copy in a few lines from an email. The next step is clarification/elaboration. A good tool should make it easy to start organizing items and their relevant data. A task like "call vet" should be easily expandable with a note about why you need to call the vet. If the tools supports devices like the phone, it should highlight phone numbers in the notes to make it easy to place a call within the task manager. The best way to cut down on the anxiety of tasks is to provide your future self with all the information it needs so that when it comes time to do the task, there's little reason to escape it. When evaluating the tools, think about what kind of information is helpful for that future self and evaluate whether the tool you're using makes it easy to enter and view that information or if it makes it difficult.

When clarifying a task, it may cause multiple subtasks to break out. Does the tool support hierarchies (outline style structure)? Does it let you think about how those hierarchies work (i.e. - are they a chain of dependent or independent actions)? If you're someone like me who thinks in outlines, this is an important thing to evaluate. If you're someone who thinks in flat lists, it's not as necessary.

Clarification is as important as collection, and tools that make it difficult to edit task titles and notes are to be avoided. Again, within the trial period of most desktop apps, you should be able to get a feel for this.

Organization (More Elaboration)

Most tools offer organization. A good GTD® style tool should promote organization by project and context. How easy is it to turn an individual task or one with subtasks into an new project? How easy is it to assign projects from the collection pool (Inbox)?

This is where tools can differentiate themselves and you can really start to feel out whether a particular tool might work for you. Some tools support projects as top-level list items, and everything else such as contexts are provided by tags. I'm not a big fan of tags (I find maintenance of a tag taxonomy tiring), but it works very well for others. Other tools support both hierarchical project and context lists. Some tools make it was to group things into folders as "general areas of focus".

The important evaluation questions are: is it easy to organize tasks in a way that makes sense to your brain and/or system? If you're a drag and drop person, does the UI support easy organization using drag and drop? If you're a keyboard person, are there sufficient keyboard shortcuts for assigning projects and tags/contexts as well as support for reordering (moving tasks up and down)?

Scheduling

Dates are important for clarification/organization, and allow you to have a good system for handling as much of your life as possible. A good tool should allow setting both start and due dates while requiring neither. Using both start and due dates can be an effective way of reminding yourself about a follow-up communication (i.e., getting an email that says "get back to me in a month if …") or other long-term reminders (renewing a web domain; canceling or renewing a membership; making travel arrangements for a conference). Start dates are also good for deferring or pausing work when interrupted by a more pressing project. If you don't always trust your own memory, a tool that tracks completion dates may be important when you need to look back at when you last paid a certain bill or need to write a report of work activity completed that week for a particular customer.

A particularly good tool should integrate with the platform's calendar if scheduling is important. This could be either being able to publish items as an internet calendar feed, or providing a view of scheduled tasks alongside other calendar items inside of the tool itself. Or both.

Note that items in a personal task system are just that - tasks. It's a good place to store reminders about setting appointments (i.e., call dentist in six months to schedule cleaning), but not a good place for the appointments themselves.

Construction (doing the work)

Your job is not about how well you organize your tasks. Your job is, well, your job. At some point, you actually have to do the work. After it's been collected, clarified, and organized, how easy is it to view? Does it offer views that let you focus on just the tasks you need to do now/next? What you need to do today? Who do you need to call? Who do you need to email? What files were you going to edit? What applications do you need to deploy?

Some days, I feel like the main character from the movie Memento, suddenly asking "ok, what was I doing?" If I've put my tasks together in my system in the right way, I should be able to answer that question pretty quickly by turning to my task manager.

This may be the hardest step to evaluate as this is when the system gets personal. The tool needs to step out of your way so you can do your work, but be able to answer the important "OK, what's next? What was I doing?" question as quickly as possible.

A good tool should help you focus on just the tasks that are relevant, hiding everything else, but make it easy to pull back to the wider view. You don't need to see bills or laundry action items when you're coding in the office or preparing a legal brief; and you don't need to see those office items when you're grocery shopping.

Having a good system or process like GTD® helps you understand the significance of these areas of focus and can help you evaluate the tools better. If you don't have a system of organization beyond basic project or context lists, then the more powerful tools can be avoided and you can get your feet wet with something like the Reminders App.

Transition (moving forward)

Of course, a good task management app should make it easy to mark a task as complete. If it has good "what's next?" views, it should pop the right item(s) into place as soon as you mark one off.

A good tool should keep completed items in the system but out of sight, and make it easy to bring those completed items up again when needed.

What you think should happen when you mark something as complete is a personal choice. I like having access to "what's next" views that just show me the next actions available in a certain context. But I also like being able to switch right to a project and focus on its actions (both next and upcoming), which can work well at work when I'm doing a single coding project at a time and want to see the upcoming steps.

This can be another hard one to evaluate. Try the different tools and just get a feel for how they present the items you're supposed to do now, and what happens when you mark those as done, and if you like the flow. Since this is where customizations may come in, you may want to read into the help files and videos and communities if you're not sure the tool does what you want.

Review

This is a major part of GTD® and, I believe, any good personal task management system. Review is what keeps your system from being "a place where good ideas go to die".

To evaluate review, just try to see if a tool has a good way of seeing and navigating through everything active or future so that you can evaluate if that's something that should stay, should go, or needs new clarification. This is hard to evaluate during the limited free-preview times offered by most tools because it might take a while to build up enough data to review. Some tools offer full on review modes, with the ability to timestamp the last review and when next to review a project. If this kind of review mechanism is important, look for that when evaluating tools. It's not a killer feature, but it can help ease the mind.

Ubiquity (everywhere you want it to be)

In GTD®, David Allen talks about needing a "trusted system" which is something you can rely on as being always available, always working, always up to date. The best system for this for the longest time was pen and paper. But now with smart phones, widely available internet, "The Cloud", etc, this can be handled by software. Is the tool you're evaluating available on the devices you need? Is it easy to keep all of those devices up to date?

You may not be able to evaluate software on the phone or tablet for free, but when looking at these systems, you can get a sense from the tool makers web sites and communities around that tool about how well ubiquity works.

Labels: , , ,

3.1.13. Remembering What You've Done, with OmniFocus
This year, the Christmas / New Year holidays brought about a pair of very short work weeks. This first day back brought with it our usual semi-weekly meeting, and one of the items that was still on my list was a pair of support tickets that I had completely forgotten. My boss said "no, you know about them, you were working on them last week and talking about them!" Yet there were no active action items or projects related to these items in my OmniFocus, and I was sure that if I was still working on these issues, they'd be written down. Did my system fail me?

We checked the live site in relation to in question and they appeared partially done. "That's funny," I thought, "why didn't I have an action for the remaining items? Did my system fail me?" I was stumped, trying to remember the previous Friday. I had worked on these issues, and towards the end of the day they opened up a larger topic that we discussed in our week-closing get together (half meeting, half beer bash). Maybe I got these support tickets nearly-finished, but the week closer had killed the final one. But again, if that had happened, I would have that final action written down. Right?

Enter my Recently Completed OmniFocus perspective, which shows all of my completed actions, grouped and sorted by their completion date. I flipped back to last friday, and sure enough, there were both support tickets as OmniFocus actions, and they were both marked as completed. My system didn't fail me! I double checked our source code repository and found the related commits and was able to verify that all the actions were, in fact, completed.

So what happened?

When the support issues came in via Basecamp, our company's project management system, I then entered them into OmniFocus which I use as my personal system. With OmniFocus, I then have much more control over editing items, grouping, organizing, splitting, etc. As I completed the items, I marked them as complete in OmniFocus, but I forgot to mark them as complete in Basecamp, which caused my boss to bring the items back up in our Wednesday meeting. A new trick that I've added to deal with this is to make a new context, Work : Basecamp, with an action to go in and close out tasks and/or leave comments as necessary.

The takeaway from this is that when using OmniFocus as your complete system, it becomes a trusted resource for not only "what am I supposed to be doing?" but also "wait, didn't I do that already?"

Side Story on Bills

A few years ago, I remember getting a phone call from American Express, asking why I hadn't paid my Amex Bill. It turns out that I had just forgot to do it. I had paid the previous bill pretty close to the deadline, and then spent the next month thinking I had paid the latest bill because my brain said "yeah, I just paid that!"

Now I put all bills into OmniFocus, even if I intend on paying the bill immediately upon arrival. Why? I have a Bills Paid perspective which is like my Recently Completed perspective but focusing on just Bills, and I can refer to that if I'm thinking "wait, it feels like I should be paying the gas bill right about now. Did I do that already?" Also useful for any paper-mail or other check based situation (like my rent checks) when I notice that I have too much money in my checking account and want to see if I did pay that month and the recipient was being slow, or if I was the errant party.

 

Labels: , ,

19.12.12. Restoring Lost OS X Notes Folders
So I'm a loose fan of OS X's Notes app. It's simple - no having to think of filenames or storage, simple folders if needed, and it syncs everywhere. No dealing with Markdown. It's pretty damn close to a piece of notepaper.


Unfortunately, it has some weaknesses. And the most unfortunate weakness is that its data can be a bit fragile. The data is stored in IMAP on your mail server, and to keep things simple, I just had two folders in my iCloud mail account. All was going OK. Until the app had a mini-freakout earlier (it wasn't showing a cursor in the note area). I quit and reopened the app, and I was faced with a collection of local folders as well as iCloud folders. The local folders had 'recovered data', but I only had one new note in there. So I tried to empty and delete the 'recovered data' local folder.

Instead, I ended up accidentally deleting my Work Folder, and the ten or so notes I had in there. There was a warning dialog that popped up, but I thought it was in reference to the local folder and clicked through it.

So the notes were gone. I had to try to find them, but they were gone. The computer I was on didn't have Time Machine, so I had to hope that there was something I could go back in time and find at home.

Here's the location - {Home}/Library/Mail/{iCloud folder}/. I hit the time machine button once I was in there and was able to go back to yesterday and found a Work.mbox. I restored this .mbox folder, but that alone didn't cause the notes to come back. There are a bunch of folders and subfolders until one comes to .emlx messages. The easiest way to list all of them is to search for .emlx files. They don't open in Notes.app but they will open in Mail.app, with all of their formatting preserved. I imagine if you could open them in OS X 10.7 Mail.app, which still had the integrated Notes folders, you could move the messages into a new subfolder. But on 10.8, I had to manually copy the message text into Notes. It was only about 10 notes, so it wasn't bad. It's better than losing some of this data.

This did lead me to start looking at other options to handle short term reference that was as simple and convenient as Notes, but maybe with an easier-to-restore backup option, but I haven't found it. I am evaluating Evernote, but it feels more complex than what I use Notes for.

For me, Notes.app is a good place for temporary reference or some other minor/personal notes and lists. It's not a permanent archive, but it's a good place to collect thoughts before going into meetings or to hold onto some reference material from emails. Again, I don't need to think of filenames or tags or Markdown or anything fancy with it. I just wish it behaved a little better on OS X. I wish it was an iCloud Documents app that hid the file management part completely, but could take advantage of OS X document management (versions, time machine, etc).

Evernote may solve my problem of where to put notes after they're no longer needed in Notes.app, but feels a bit heavy for the use case outlined above.

Hopefully this is the only time I run into this problem.

Labels: , ,

18.11.12. My Email Inbox Workflow with OmniFocus
I had one of those mornings where I was dealing with personal morning stuff - exchanging some items with a neighbor, worrying about some odd behaviors from the dog, and the usual flurry of getting dressed and trying to get the dog out for a walk. As this is going on, a rush of emails starts coming in of actions to do for work, on a project that I had done little work on and wasn't immediately prepared to handle. In particular, I was seeing these emails come in on my iPhone where I could do little about it. My first instinct, and action, was to start stressing out a little bit: "Why this project? Why now? What do all of these things mean? Oh crap, is this new email related to another project?" Meanwhile, more emails were coming in and getting grouped together in my inbox in their own stream-of-receipt way.

But then I was able to let go of the stress and let the flood continue. Why?

  1. It's my job to deal with this stuff. There was no bad news or anything here.
  2. I didn't need to deal with it immediately. Just because there was an email on my phone didn't mean that I had to start working. It can be easy to forget this.
  3. I didn't even need to read every email immediately. Once I recognized the pattern, I could just let them pile up like in the old days before constant communication, while still keeping an eye out for anything urgent or that could be answered quickly while waiting for the dog to finish sniffing whatever has her attention while we walk.
  4. I strive to maintain "Inbox Zero", so I didn't need to worry about preserving an unread count as "emails that need processing". Basically, if it's in the inbox, it's awaiting processing. So after reading a couple of these emails and recognizing what was going on, I knew that I could wait until I got to the office to actually deal with them.
  5. I didn't have worry about process or organization. I have OmniFocus, and I knew that it would be easy to turn these static out-of-order emails into actual items that I could process. OmniFocus makes it easy to copy all or part of an email message to its own inbox, but from there I can edit the text, re-order things, start picking apart subtasks, and so on.
  6. Once those items are captured into OmniFocus, I can move those emails out of the inbox and into a project folder, possibly never to be seen again. I can open the original message from OmniFocus if needed. This will bring my Inbox count back down to zero (or near zero).
  7. Now I can actually process all of this information that came flooding in and get things done.
Also, spending time with meditation has allowed me to recognize the silliness of that sudden stress-tick that comes when emails like this start coming in while I'm rushing to finish other things. It made it easier to recognize, as Merlin Mann once said in an episode of "Back to Work" (can't remember which episode), that it's just a new email. I'm not alone in the woods, trying not to be eaten by bears. Instead, I think of the list of things above: "wait, why am I worried about this? I have a process for dealing with this, it'll be OK."

At PyCon 2012, Paul Graham spoke on how he wanted a replacement for email that was really "send me to-dos." I guess for him, most real emails are actionable items and he wants them presented as such. Combining OmniFocus' mail clipping capabilities provides something similar for me, but with me taking an active step in transforming some inbound request into actionable data. I think this works better since not every email is actionable, or its action may be a quick reply. For me, the important thing is to figure out what needs to be done and get all of those messages out of my Inbox and filed away.

If the email is just reference info, or is not related to anything I'm currently doing but may come up again in a few days, I scan it and file it away. If it warrants a quick reply, that is done before filing it away. Longer term reference info is often copied into something like Apple's simple Notes app before filing the original email away.

If the email pertains to something actionable, it tends to go into OmniFocus for further processing. Most of the time this is related to work stuff, but it can also be reminders of something to do at home such as a reminder to download an update to some audio software. OmniFocus' quick entry window makes it easy to assign projects and/or contexts. If it requires deeper thinking, it just goes into the OmniFocus inbox. Then the original email may, of course, get filed away into an appropriate folder.

If the email relates to something like a shipping notification that I want to track, I copy the tracking number into an iPhone app dedicated to package tracking. For a long time, these tended to be the kinds of emails that would stick around in the inbox until the item arrived, but during some shopping sprees or slow-delivery items, I found that the emails were getting distracting. A dedicated app also makes it easier to visually track the status of multiple shipments. Once the shipping info is in the tracking app, the original email is deleted. No need to keep those around for reference.

Receipts get archived immediately to a folder named "receipts". Other emails that are not related to a project or receipt that are not spam are now moved to the "Archive" folder. I'm glad this is a quick action in OS X's mail (I used to keep a generic "reference" folder for this, and turned that into the "archive" folder).

And with all this, I tend to keep my email inbox count to zero or near zero. This makes it easier to process big volumes when they come.

See also: The OmniFocus and GTD White Paper (PDF). My personal system is not full GTD, but the basics are there and the core inbox-processing workflow is well diagrammed and discussed in this paper.

 

Labels: , , , ,

5.11.12. iPad and the Incase Origami Workstation
The iPad writing station experiment continues. The latest addition is the Origami Workstation by Incase. This is a simple case for the Apple Wireless Keyboard that folds out into a supportive structure for holding an iPad. When I started this project, I was using the Apple Smart Cover to support the iPad in a landscape position, like a laptop. The Origami Workstation supports the same thing, but it supports placing the iPad in any orientation. iA Writer looks great in both, and it can be nicer and even more like a piece of paper to type in portrait, which is what I'm trying now.

I have yet to try even commuting with this keyboard, as it's not something I need at work. I use the iPad at the office, but don't do very much typing. Any input that I need on the iPad at work comes in via various cloud/sync solutions like OmniFocus, Notes, and iCloud. Still, I'm going to toss the keyboard and this case in the backpack tomorrow to see how it feels and fits. The aluminum keyboard is not small, and packing it around could start to mitigate the advantages of the iPad. However, I think the case will be a nice occassional throw-in for going to a neighborhood coffee shop (waiting on a new one to open in a couple of months) or maybe travel when I want to do some writing.

This makes me recognize some of the appeal of Microsoft's Surface and Windows 8 strategy, which is to promote a laptop/tablet hybrid. With this keyboard, I'm closer to that situation. I have more thoughts on this that I plan on posting in the future.

For this post regarding the Origami Workstation case and the Apple Wireless Keyboard, the takeaway is that this is a nice piece of kit that seems to compare favorably with other iPad keyboard/case combinations. Some other combinations combine the keyboard into the iPad case, and I don't like those. While I like having a keyboard for my iPad, it's not something I need for most of the day or evening. With the Origami Workstation, my keyboard is protected and put away most of the day and isn't taking up any more space. It does take up more space when it is in the backpack, but again it's not something I plan on taking with me daily. Integrated case-keyboard solutions also tend to force you into landscape mode - even the Microsoft Surface's savvy design does this. While this isn't necessarily bad, I do find that when writing long bits of text, portrait mode can be a much more natural fit. Since the Origami Workstation just unfolds into a supportive triangle, the iPad can be propped in either orientation. The iPad can even stay inside most cases that you can put on it.

It's also pretty easy to pop the keyboard in and out of the case. This is nice since I might want to use the keyboard on my lap while keeping the iPad on my desk. This is like the iMac where I can place the keyboard wherever is comfortable, independent of the display - something you can't do with laptops or integrated keyboard cases.

Finally, the Apple Wireless Keyboard is great. It's what I use on all of my iMacs, and is the same layout as on my (aging) MacBook. I'm used to the feel and spacing of these keys. The Origami Workstation lets me stay with that keyboard while letting me use the iPad like a laptop, desktop, or tablet as much as I want. The main downside is size, as the keyboard is taller than the iPad, and thicker due to its use of AA batteries. Since I expect to mostly use this at home, that's not a big deal. It's still a pretty compact setup.

The cost of the Apple Wireless Keyboard ($69 USD) and Incase Origami Workstation ($29) matches nicely with most of the top integrated keyboard case solutions which seem to average around $99-$129. This pairing is excellent for anyone wanting to do long writing on the iPad.

Labels: ,

3.11.12. On iPad Sizes
With the launch of the iPad Mini, Apple's 7.9" iPad, there seems to be a lot of "this is the future of the iPad" or "this is the iPad we'll all use" comments in various reviews I've read. Without having used one, I'll say differently.

When the iPad was announced in January 2010, there seemed to be a lot of discussion about whether the iPad was a device for consumption or creation, and about whether it could be a suitable laptop replacement. Nearly 3 years into the iPad era, there seems to be a consensus that this device is suitable for creation and it can be a laptop replacement or alternative for many. It is also an absolutely terrific machine for consumption of both text and media, but I think that it's usefulness as a creativity machine has surprised many.

I believe this is strongest at the 10" side. I think that the iPad Mini will be a nice creative machine, but early reviews and indications seem to indicate that people are finding it most useful as a "pick up and read/search/view" machine. The Mini is something they can use while pacing around and talking on the phone. It's smaller and lighter, which some say "is exactly what we all want out of our devices" (while at the same time everyone is saying the iPhone remains too small and should be bigger, and the oddly sized Samsung Galaxy Note has a surprisingly good number of fans).

Personally, I want my iPhone to be the size that it is. It fits well in my pocket, where it spends a lot of its time. I can keep it in my pocket when laying on the couch or in bed for a mid afternoon weekend nap, and it does not bother me the way bulky old cell phones did in the past. But I fear that if it were any larger, it would feel uncomfortable like a Moleskine notebook. I think the iPhone is the perfect size.

Likewise, I think the iPad's full size is also perfect for me. Let me list the ways I use my iPad:

  • OmniFocus. As a developer, my work desktop has a lot of apps and windows open, and keeping on top of my best laid plans was mildly annoying until the iPad came along. I do my planning on the iMac, entering in things I need to do to get some piece of work done, and then use the iPad as a separate dedicated screen for keeping on top of that list and marking things off. For a while, I was actually using a laptop for this, as that separate, dedicated screen makes it easier to find and reference what needs to be done when there are so many noisy resources needing my attention on my main work machine.
  • Reading. I eat at my desk a lot, either with local take-out or sack lunches from home, and the iPad, mounted on my Compass iPad Stand, makes for terrific reading and is a good size for at-desk reading whether using Kindle, iBooks, InstaPaper, DC Comics, The Economist, or the web itself. I know the "mini" size is supposed to be better for reading, but the 10" iPad is great for its placement and distance on my desk at lunch time.
  • Twitter. A wonderful, horrible distraction that is just a couple of swipes away while I'm working.
  • Writing. I'm writing this on my iPad on a crowded but cozy CB2 metal desk in the kitchen area of my loft. The 10" size works great for writing with iA Writer, Blogsy, the built-in Notes app, etc. The not-much-smaller 7.9" is probably fine, but for me, I no longer need a MacBook Air now that I've finally added a selectively-used keyboard to my iPad. Laptop replacement? You bet. I'm not programming on it, but I know now that I could probably use this with apps like Diet Coda to get some work done from home needed, although I do have good full-computer fallbacks for that.
  • Music. There are some terrific music apps for the iPhone and iPad, and the good iPad ones are quite terrific. Again, I find the larger screen works well for those apps. Some apps like the Korg iElectribe come close to matching the physical size of the full Electribe machines. The iPad is not yet an indispensable piece of my music setup, but it's a fun and useful addition on occasion.
There is also a lot of heavy consumption use in the evening as an IMDB and Twitter lookup machine while watching movies or TV that could possibly be served just as well by the iPad Mini, but the occasional video consumption (Netflix, Hulu, iTunes movies, HBO Go) also seem like they're better suited to this larger screen.

So for me, this 10" iPad is just fine. All of this talk about how we'll all be using 7 to 8" tablets is like saying we'll all be using the 11" MacBook Air and no one will use the 13"; or that no one will use a 15" laptop when there is a 13" available; or that no one will use a 42" TV when there is a 32" available. It all depends on need, use, and budget. Or as Horace Dediu says, it depends on the job(s) for which you're hiring the device.

I have never seen so much pointless talk over a device taking on an additional size as with the launch of the iPad Mini. It's just another size. It's not the second coming of the iPad, nor is it the doom. In my mind, there's nothing that exciting about the iPad Mini at all. I'm not saying its a bad device, it's just what it is: a smaller iPad.

Wake me up when there's a 13" iPad and iOS finally grows support for intelligently dealing with different scales and dimensions.

 

Labels: , , , ,

1.11.12. A few more thoughts on iA Writer

A day into the iA Writer experiment on my iPad and iMacs, and these are some quick thoughts:

Good: iCloud Support. I like Dropbox, but there are situations where iCloud documents just make more sense to my brain. I haven't had any strange behaviors yet, whereas some Dropbox based apps that I use on both my Mac and iPad do exhibit annoying behaviors. I like that I can have the same document open on multiple devices and that the document itself gets updated in place. I'm not trying to write on multiple devices at the same time, but I don't like getting funny "(saved on …)" files when I forgot to close a window or document on a device. I like OS X Mountain Lion's iCloud document management window within the app, and it's very easy to drag files in and out to file things away in the larger file system (including Dropbox via its OS X Finder Integration).

On iOS, iA Writer also supports Dropbox, but I have not tested it yet.

Good: Simple Interface. This is the first "distraction free" simple writing app that I've enjoyed since the original WriteRoom 1.0 (I didn't like future versions as much). It's very easy just to write, whether in windowed mode or full screen. Writing this in full screen on my iMac right now doesn't feel much different than writing on my iPad with a bluetooth keyboard last night.

The default (and only) font is quite nice on all platforms.

Mediocre: Markdown Links. While inline-style Markdown links are OK, I like the footnote style when I'm just writing things down and want to pile up a list of links to collect later at the bottom of the document. I'm interested in iA Writer as a blogging tool and like that I can compose entries so easily on my Macs and iOS devices, but this little missing feature is annoying. I'm not a heavy Markdown user and don't care about "MultiMarkdown" or other such enhancements, but footer-style links would be nice.

The developers say that such support is coming.

I'm also undecided about my blogging host/platform, so the ability to write in simple Markdown and "Copy as HTML" is a nice feature in iA Writer for posting via other tools that may not have (easy) Markdown support. This need of mine may change.

Labels: ,

31.10.12. Testing iA Writer and Keyboard

This is something that may or may not get me back into blogging - being able to use my iPad but type at near-full speeds. I've added an Apple Wireless Keyboard to my setup. It's an experiment. A friend challenged me to participate in NaNoWriMo. I have doubts about that, but thought that it might be worth a try. I have characters and places and bits of story that are already lying around and it would be good to challenge myself to do something with it. But my main machine at home is an aging (mid 2007) iMac that is really my music studio machine. Well, it's really a media server that services the iPad and iPhone these days. Occasionally it's used for music, but that's like once per month. The point is, it's not the most comfortable writing environment due to the way the desk and iMac are set up.

Part of me was thinking this would be a good opportunity to buy a MacBook Air, I really can't afford one and don't have a strong need for one (they're not strong enough for music, and I don't move around enough to warrant buying another laptop. Besides, I still have an old white plastic MacBook that is serving its remaining years as a bedside Netflix and DVD viewer (and the DVD portion is important). I haven't found need to use for much else beyond that in the past couple of years, so it's getting a bit crusty.

Still, I was thinking about what would help me try to write from a more comfortable place? Well, there's the iPad, of course! Using its onscreen keyboard for longer pieces, such as the one I'm writing now, is inadequate. So I thought it was time to finally try adding a bluetooth keyboard, and most reports I've read indicate that the Apple aluminum wireless keyboard is generally unbeaten. I don't plan on taking this with me to very many places. I just want to stay on this side of the loft with a smaller, simpler, more focused machine. So far, it seems to be working.

For the start of this experiment, I'm typing this all out in iA Writer, a very clean and simple writing app that is a blank white screen and a nice big font. More importantly, to me, is that it supports iCloud's "documents in the cloud" feature. While I like DropBox and have had some success using text editors in DropBox, iCloud's setup when there's a nice corresponding Mac app seems even simpler. I've been wanting to give iCloud documents a serious try, as there are more and more places where I find myself wanting it.

So, a new experiment begins, starting to use the iPad even more seriously as a productive machine.

Labels: , ,

6.9.11. HTTP Basic Auth problems that affect Zope (2 and 3) in Safari 5.1, Mac OS X Lion

One very frustrating experience that I encountered after upgrading to OS X Lion (10.7) was that Safari 5.1, as included in Lion, would constantly pop up basic-authentication dialog boxes on our CMS sites, which are based on the Zope Toolkit (kind of between Zope 3.4 and Bluebream). Just about every page in our admin UI would do this. To get around this, I switched to Firefox for interacting with our admin screens, but still used Safari as my primary browser (better OS X citizen, takes advantage of Lion features which I enjoy, bookmark syncing, etc). This lead to problems as Firefox could get pushed way back in the usage stack and would be paged out, and it did NOT like to wake up after long periods of inactivity.

A couple of days ago I decided to take another look at the WebKit project as I was certain that I was not the only person having this issue. And I found a bug that had been recently closed relating to this issue. It's WebKit bug 66354 and it's resolution is in the WebKit nightly builds since at least September 2, 2011.

Apparently this only affects OS X Lion as it has to do with low level CFNetwork changes in Lion. The bug occurs not with basic auth, exactly, as I was able to use other systems behind basic auth. The bug occurs when there are redirects with Basic Auth, which our CMS uses a fair bit in its admins for basic navigation links.

As of OS X 10.7.1 and its Safari (Version 5.1 (7534.48.3)) this is broken. If you use OS X Lion and Safari and encounter HTTP Basic Auth problems, I'd recommend switching to the nightly builds.

 

Labels: , , ,

19.8.11. PyFlakes and BBEdit, kind of together (at last?!)

I've recently returned to BBEdit as my primary development editor after spending the past few years with the increasingly neglected TextMate. One thing that I missed from TextMate was some nice 'PyFlakes' integration. Since adding PyFlakes to my daily workflow in TextMate, either through the 'PyCheckMate' option or via the 'PyFlakes On Save' option (which popped up in a tooltip), my module imports have been cleaner and refactorings have gone more smoothly as I can catch forgotten names and imports in moved code.

The first thing I did when I moved to BBEdit was to rig up a quick script that ran PyFlakes and bound it to command-shift-V (V for Verify, or validate), based on the PyFlakes-On-Save TextMate command (which I found in a Zope bundle, I think). My script just dumped the results into a new BBEdit 'Unix Script Output' text document window. It worked, but was not particularly helpful. BBEdit has a 'check syntax' command built in that will catch SyntaxErrors in a python file, and its results go into the 'search results' window which allows you to step through the errors nicely in a dedicated window. I remember using something like this with Emacs and things that modified Make-mode to jump to error results in unit tests, making it easy to step through failures with a single key-chord.

Well today, I finally found how to get my results into that window. The script is now up on GitHub in Gist 1157742.

 

Labels: , ,

15.8.11. New Synthesizer Purchase, and near-future music ideas

I bought another synth and am just waiting for it to arrive. I bought the Akai MiniAK after seeing a friend, himself quite an accomplished ‘experimental music’ composer, get quite delighted after purchasing one. I’m also exploring a new collaborative electronic music project, possibly quite club oriented, that may also do some live shows in the future. For myself, I’m interested in doing this without a computer. My laptop is getting quite aged and I don’t have the desire (or funds), yet, to replace the studio iMac with a Macbook Pro that could venture out on occasion while retaining the master keys for my suite of software. Granted, with my software suite, I could do pretty amazing things, but I’m more of a tweaker here than a performer.

I’ve been interested in getting a keyboard synth for a while now. I have a keyboard USB MIDI controller and in theory I could just attach it to my Korg MS2000BR rack mountable module. I have no power adapter for this controller (it prefers USB power and I haven’t bothered looking for an AC adapter for it), and the MS2000BR is cool, but the two pieces of gear together are a bit beefy.

I’ve considered the microKORG, partially for its kitsch value, partially because it is an interesting synth. But it’s essentially the MS2000BR in a toy-ish package, and I already have that engine in a more complete synth. Since I haven’t done much programming with the MS2000BR, I sometimes wish I had bought the microKORG instead. Then again, the programming that I have done with the MS2000BR has produced some nice results.

Recently, after revisiting some half-finished electronic experiments from the past few years, I started reconsidering getting the Alesis Micron. I like the Micron’s visual design and found its sounds interesting, although a bit too clean. The sounds can be easily dirtied up with the plethora of noise gear and MoogerFoogers and Metasonix modules I already have. Then I noticed that the Micron was disappearing from various online resellers, and appeared to have been discontinued. Still, after my friend’s MiniAK purchase and in light of my other desires, I came very close to buying a Micron…

Until I found out that the MiniAK is essentially a re-packaged Micron, with a sturdier Akai Pro body and a (silly) emphasis on the vocoder. I like my MPC500 and plan to have it at the center of whatever the hell I’m building out here.

I guess I finally have to learn (and learn to like) MIDI. I’ve got plenty of disparate pieces, just need to put them together. MS2000BR, MPC500, Electribe EMX-1, and now MiniAK. Plus all my pedals and little analog bits.

And I have my eye on getting a Dave Smith module or two. I’ve been fascinated with the Evolver for a while, and the Mo’Pho and Tetra are pretty damn cool. My big analog modular plan can wait a little while longer.

Labels: , ,

9.6.11. Is This Sensationalist Headline In The Form Of A Question?

It depends. We'll have to wait and see. Only time will tell. And other such bullshit.

19.5.11. To square and back again

I believe I'm ending my personal Squarespace experience. While I like Squarespace's UI and tools quite a bit, I just don't write enough to make it worth even the small amount I spend per month on their most basic package. I've copied some of my better posts from the [now old] http://eucci.squarespace.com/ blog back into this one, and give no further promises on whether I will suddenly feel like posting more often or not. But, of course, I do hope to post more. On Python, on audio, on iPads and file management... We'll see.

29.3.11. Needlessly adding complexity in tests in order to hide their complexity

Some tweets from DHH on testing:

I respect the guys behind it and I'm all for experimentation, but the proliferation of rSpec and Cucumber makes me sad. (source)

RSpec offends me aesthetically with no discernible benefit for its added complexity over test/unit. (source)

Cucumber makes no sense to me unless you have clients reading the tests. Why would you build a test-specific parser for English? (source)

The important thing is of course that we get people testing, so tools shouldn't matter too much. But the added complexity still upsets me. (source)

I agree, and I'm glad that these kinds of tests have never really caught fire in the Python world. There are implementations of the RSpec and Cucumber ideas, but they don't seem to be as fully embraced. In my opinion, the dark side of testing in the Python world is the abuse of doc tests, thinking that they make both good test cases and good documentation, when in fact they're neither. There are good use cases for doc tests, but I think they've been horribly abused by certain sects within the Python world. However, even when they've been horribly abused, the people writing them seem to go after pretty broad code coverage, and they don't waste a lot of time trying to be cleverly concise (in fact, the verbosity of these large doc tests is what makes them so awful when they're also treated as documentation).

One of my main issues with RSpec and Cucumber as I've seen them in the wild is that there seems to be very few tests, and they're not terribly useful. They seem to be repeats of the classic "baby's first use case", which is "user logs in". Maybe their usage outside of the open-source world is different, but the few projects I've seen which use them have very few test cases that always has me going "that's it? you think you're tested?"

And as David points out, the complexity going on behind the scenes to make the tests just seems silly. Granted, 'Unit Tests' aren't always that easy to read, but they offer a finer example of API interactions. And if you want clarity, just add some comments. Take a cucumber-esque line like "verify that the file is encoded in UTF-8" and "now the file is encoded as latin-1" and put them as comments above the test/assert/verify statements that prove that line.

RSpec and Cucumber feel like the kinds of fiddly things that get in the way of doing real work - you can spend a lot of time writing all the back-end support to get a single test to read like an english Haiku. Or you can spend time writing a good battery of tests that actually get good coverage of the system.

Labels: , , ,

24.3.11. Forget distraction free, I want file-management free!

A few years back I downloaded an interesting piece of software for the Mac OS - Writeroom version 1.0. Writeroom sells itself as a "distraction free writing environment." It's main feature was that it was plain text only and could run in a full screen mode with default colors of being green text on black background. There was some fanfare around it and some skepticism. Personally, I liked the idea - get rid of all of the other windows, instant messages, dancing gifs, email notifications, etc, and just write.

This is something which I like about the iPad - only the current application has my attention. I hope that this doesn't change. I do not like what I see in Android 3.0, nor what little I've seen of the Blackberry Playbook. Their interfaces look too busy. I deal with busy interfaces all day. For me, the iPad is a relief from the world of current desktop computing.

My favorite key combination on Mac OS X is option-command-h, aka Hide Others. When the screen starts filling up with windows and more windows and more windows, Hide Others temporarily brings some order to the madness.

Back to Writeroom. My favorite feature of 1.0 was actually not this 'distraction free writing environment' nonsense. That was a useful feature, to be sure. But the feature I liked most was that it was a file management free writing environment. Writeroom 1.0 managed its own files. There was no savingno filename choosing (the document name was taken from the first line of the document). This made it a perfect place for just jotting things down, working small ideas out, and maybe taking them into bigger things. That file management free writing environment was bliss, at least for my uses. Every time you opened the app, there were all your documents. You could close them to hide them, but they were easily accessible from a menu and a keyboard shortcut.

There were some other apps that offered similar features - the Stickies application that comes with Mac OS X (and dates back to Mac OS System 7.5) is another nice tool for temporarily holding small pieces of information without having to worry about file management; Yojimbo is a collection bucket of notes, PDFs, etc, and can be another place for notes to quickly go; and Apple Mail in Mac OS X 10.5 added Notes which could be stored in IMAP (and can finally sync to the Notes app in iOS 4) and offer a nice quick jot-down place that also takes its title from the first line.

Writeroom 2.0 killed this feature. I avoided writeroom 2.0, but when version 2.5 was on the Mac App Store at a temporary discount, I bought it. And I hate it. Now I have to think about filenames. Now I have to think about where things are being stored. Writeroom 1.0 allowed you to easily export a document out, but that kind of decision was usually made AFTER you were finished with the document. There are times when I don't want to think about that stuff when starting out. This is not true for all cases - much of my day work is spent in TextMate writing Python code, reStructuredText documents, and managing configuration files. Of course I need full file management in that situation. But when it comes to just writing down some notes, capturing some ideas, and maybe thinking through a proposal, I miss that Writeroom 1.0 functionality.

And again, this is something that the iPad (and iPhone) gets right, for most instances. Whether its OmniGraffle, Pages, Garageband, or the built in Notes app, starting a new document is damn easy. Saving is automatic. You just start using it.

Fortunately, the next version of Mac OS X, "Lion", looks like it offers many long overdue file/document management features for developers so that they can offer functionality closer to Writeroom 1.0. Again - I'll always need TextMate and some apps to do manual file management, but those uses are specialized and becoming more rare. Mac OS X Lion adds support now for auto-save, reversion, locking, and historical change tracking. In some ways, this feels like going back to some of the ideas explored in the LISA and other pre-Mac user interfaces that weren't shackled to the hardware limitations of the original Mac OS (file management in the Lisa OS was quite a bit different - everything started from the finder, including new documents). In other ways, it feels like we're catching up to what the Newton OS, Palm OS, and iOS devices have long done in their aims of imitating paper notebooks and planners - everything is just saved, automatically.

It's not perfect for every situation, but it's something I've long been wanting in more places than just calendar and contact apps.

Labels: , , ,

15.2.11. Dead SCSI Bits

Some time ago, there was a cool audio project hosted by Radiantslab called DeadSCSI. And there was also DeadSCSI 2. It all appears to be gone now, but there is at least some information available in the wayback machine. I contributed in both rounds as Eucci.

When Ergo Phizmiz recently tweeted a link to this page of failing hard drive sounds, it got me thinking about my bits of the DeadSCSI project that I had laying around on my studio drobo. I spent some of saturday doing some lightweight remastering. Early Eucci, where I abused the computer like I used to abuse tape, is pretty rough in its output quality. Levels are just all over the place. DC Offset lingers here and there. It's a mess. But there are some pretty spectrum graphs.

Last night I uploaded the tracks to my Rive collection on archive.org and cut a release as rive 058.

What is mildly interesting about this is that although all of the tracks were re-finalized on Saturday, I didn't upload them until last night. It was a process I was starting to put off, remembering that I needed to name the files properly, upload them, enter metadata, and make a web page on euc.cx. Not that big of a deal, really, but big enough to put off until tomorrow and tomorrow and tomorrow.

Last night, when I got home from work and after I had walked the dog (enjoying some unseasonal warmth before winter makes its fierce return later this week), I was thinking about what to do from that moment until dinner. I was starting to get ready to play the excellent Red Dead Redemption, but I knew I had to cut this release. Then I remembered something Merlin Mann said in the first or second episode of the Back To Work podcast. He basically said that it's easy to complain about needing time or certain circumstances in order to work on something, but that we don't complain about needing that time or certain circumstances to play video games, and we sure as hell can sit there and play a video game for an hour. It feels like a shame to have to be reminded of this ridiculousness, but it's something I apparently need to remember constantly. So instead of playing Red Dead for an hour, I spent the time preparing the release. It took a little bit longer than expected and the dog was getting impatient towards the end. But overall it was a nice use of that time.

There are many more releases to come, including some new material.

 

Labels: , ,

13.2.11. To Laptop or Not To Laptop

PyCon 2011 is coming soon, and as it does, I find myself facing the question "do I bring my Macbook this year or not?"

My Macbook has spent most of the past couple of years serving as a vehicle for viewing DVDs, Hulu, or Netflix streaming from bed. It does get used occasionally as a home / travel development machine, but that use has declined significantly over the past year. I'm fortunate to be at the place in my life where I can leave work at work; but I also have been rather uninspired to do personal development work. Hence, the laptop is basically a DVD viewer.

And for DVDs, it's quite nice to watch TV series DVDs from bed. I only watch about 20-30 minutes a night before tiring out. It's a fun way to revisit personal favorites like HBO's The Wire and Deadwood. I'm currently watching Twin Peaks, seeing season 2 for the first time.

But for DVDs, it's also starting to become a liability, as I own more and more blu-ray. As soon as I decide to get a blu-ray player for upstairs (either a portable one or getting a second television), the laptop's uses will be near zero.

One potential use is for travel, at least for technical conferences. I brought the Macbook along to PyCon last year. I did the whole trip out of my day-to-day backpack, which accommodates the Macbook just fine. While at the airport and in flight, the extra weight and space did stand out, but that was only a fraction of the trip. I'm trying to remember now just how much I used it once there. I took far less notes on the device than I expected, and have done little with the notes I did take. They still sit in a folder on the Macbook's desktop.

I know I did some coding while there, but not much. I don't believe I made any major commits or pushes while at the conference. I wasn't involved in tutorials or sprints last year and won't be this year either, so there's little need to code while at the conference.

Finally, my co-worker had brought his laptop and while he did use it to maintain some situations back at the office, he told me he never used it on the conference floor. I think the most use we got out of our laptops was for watching movies on the plane. And hey, I've got an iPad for that.

So as this next tech conference comes up, I'm seriously considering leaving the laptop behind and just using good old pen and paper. Maybe my personal era of the laptop is officially over. Weird.

 

Labels: , ,

27.1.11. Sunhil Intentions for 2011

As announcing one's intentions is the simplest way of hearing God laugh, I'm planning on doing the following for Eucci and AODL this year: it's time to finish cleaning out the back catalog. Whether this is a coda at the end or the beginning of the next phase for both projects is uncertain. I just know that it's time to stop letting these unreleased pieces hold me back. Yes, I'd like for some of them to be released in beautiful physical form, and some might still be so. But chances are that most of them will be released online, for free. The candidates are:

Eucci

  • Pachyderm (1994) - Tape collage, and really the first proper 'Eucci' recording where the early style really came together. Meant to be on tape, but it's long (45 minutes) and I could never find a satisfactory b-side.
  • Star City (1996-1999) - mid-era electroacoustics and musique concrete, some for radio programs.
  • Apt (2004) - unreleased sounds for an empty apartment in the world's last perfect spring.
  • Like The City, We're Bound To Last (2000-2009) - Spans some of the earliest Eucci (2000), mid-era (2004) and some late-era work (2007-2009).

AODL

  • Fans of Flesh and Textured Wrecks (2004-2007) - the most likely to get a proper vinyl release. Long form dark AODL, most of it in special live broadcast performances.

Maybe

  • Eucci, "Because 1999 Needs an Enemy" - very limited edition tape from a bad start to the year. Of interest, mostly, as it is the direct ancestor of AODL. It was the first experiments in doing feedback loops of effect pedals, and using those as the only sound source.

 

Labels: , ,

29.11.10. Keeping History

Back in mid 2005 I worked on a project for customer wherein I was generating "Froogle Feed" data for the customer's e-commerce sites. For some reason, the project never went live. Suddenly, a request shows up from the customer mentioning "Froogle Project" and asking for a couple of features.

I have no memory of how I accomplished this project in the first place. I don't know if the customer does either. I just have a couple of features in an email project and zero context. Does the customer remember the experimental work we did a couple of years ago? Does he remember the UI?

The big problem is that aside from a couple of emails and basecamp messages, and a couple of generated 'feed' files, I have nothing for this project. Looking through source code history returns nothing. Looking through the current site (an old Zope 2 based site, built out of page templates, python scripts, and SQL Methods) yields nothing either. Unfortunately, there's not a lot of history in the site. And if the feature in question never went live, there's (of course) not going to be ANY history.

I dug through a big folder of printouts and such collected over the eight-plus years of history with this customer. Nothing.

I finally turned to notepads and notebooks, and did manage to find a couple of notes in a couple of different places. And digging through some basecamp messages yielded a mention of a 'froogle.py' file in a development instance that was not put into source control (CVS at the time). That development server was killed off long ago. It may have been hobbling around, but after moving offices twice in the last year or so, the number of internal servers is nearly zero. Long unused development servers tend not to get plugged back in.

Some lessons learned:

  1. Always put a date stamp on handwritten notes. This is now a habit for me, but it apparently wasn't a habit back in 2005. I did find some dates on some pages and used that to backtrack to when this work was initially done (using date stamps on Basecamp and email messages). A side lesson to this is to always include the year when date stamping.
  2. Always use source control, even for unfinished projects. If this one file had been checked into CVS, I would be a bit less stressed right now. I'm far less familiar with this customer's site now than I was then and trying to remember how I built multiple Froogle files and put them into a Zip file would be great knowledge right now, even if the format has changed. Since moving to Git, it's easier to keep dead branches in the central repository. CVS made branching so painful that we never would start a 'froogle-feed' branch. Even if that branch never goes live, it's damn useful to have.
  3. Don't trust development servers. They may not be around forever, and odd little unfinished files or projects can get lost very easily over time. May not seem like a big deal, but sometimes these little projects come roaring back to life after five years. We now do most of our development on our desktop machines. When we get a new machine, all of our files roll over. Central servers work if it's a central common copy (like a master account server). I've found that development servers just lose luster over time, and tend to get very far behind in terms of hardware and core OS performance. Plus they tend not to have the kind of machine/account migration tools that desktop OS's like Mac OS X have.

 

Labels: ,

9.4.10. iPad and Creativity, I

This Post by Giles Bowkett goes into why the iPad is NOT where creativity goes to die. It's something I have been meaning to write up myself, but haven't gotten around to doing so just yet. I do hope to write more on the subject, but until then I will just add this: if the iPad was only about consumption, I would not have bought one. For months, dating back to when the iPad was just an ever growing rumor, I would show friends apps like Looptastic and Jasuto and say "imagine this on a bigger screen!"

I didn't even see the i-Electribe app coming. I have a real Korg Electribe as well. The iPad implementation is just stunning. (I also have both a real Korg MS-10 and a DS-10 cartridge for Nintendo DS. It's fun to have these real tools, and then have software representations of them in unusual places. A VST plug-in is just so boring compared to an iPad or DS surface, and both of those surfaces are far more fun to use on trains or patios than a laptop).

The iPhone has already proven itself as a fun and capable device for making music, visual art, and even for writing. It's like the universal pocket notebook, capable of capturing not just words and doodles and snapshots but also drum beats and synth sounds and singing and on and on and on. The quantity and quality of creative apps for the iPhone is part of what excites me about the platform. The iPad just adds to that excitement.

Labels:

5.3.10. iPad, Periodicals, and Purchase Options

Apple has announced an iPad ship date of Apr 3 for the wi-fi only edition, with the 3G model slated for late April. Pre-orders start next week.

I'm hoping for good magazine content, and I would be willing to pay. The web often sucks for magazine content as obtrusive advertising, annoying pagination (often in support of more obtrusive advertising), and random encounters with pay walls get in the way. And it just sucks to read on a computer screen. It's not the LCD display, but the position and layout of the screen that is frustrating.

I've had subscriptions to The Economist, The New Yorker, and Harper's in the past, and I'm starting to miss them as I've been trying to make more time for reading. The weeklies, especially, are the ones I would like to have electronically if I could pay on a month by month basis. Sometimes it's hard to keep up when life gets busy, and those weekly magazines can pile up quickly.

Finally, I'd love for the magazines to work offline. Then I think I could totally buy into the wi-fi only iPad. I'm already sold on the iPad, just can't decide which model to get. I don't leave the house or travel too often, and the iPhone is often good enough when I am out like that. But having the 3G as a pay-as-you-go option for the iPad could be handy on those occasional small trips.

Still, I think that when I take the train from SLC to DEN later next month, I will be much happier with traditional books and cameras than with a gadget, no matter how cool the gadget is. It's nice to just turn things off for a couple of days.

I think I just talked myself into the wi-fi only iPad.

Labels: ,