apk zipalign

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.

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.

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.

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

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.

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.

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 saving, no 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.

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.

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.

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.