apk zipalign

I saw a link today from Hack The Planet titled “What’s new in JavaScript 1.7: Lisp/Python!”, pointing to a “new in JavaScript 1.7” page at developer.mozilla.org.

So, of course I had to follow this and see what he meant. Sure enough, JavaScript 1.7 starts to look a bit more like Python in some places. From the “What’s new” document, this is an Array Comprehensions example:

var ten_squares = [i * i for (i in range(0, 10))];

Take out the word var, and that’s 100% valid Python (although Python can get by here with less parentheses and without the semicolon).

Iterators in JavaScript 1.7 are also very similar to Python’s, with objects providing an optional __iterator__ slot. Iterators just implement a next() method, and raise StopIteration when done. Generators turn functions into iterators by using the yield keyword.

Very interesting. For a while, I was a fan of the MochiKit JavaScript libraries. MochiKit takes a lot of inspiration from Python and some Python toolkits like Twisted. Among other things, it provides MochiKit.Iter, which brings a lot of the Python itertools functions as well as basic Iterator concepts to current JavaScript, if desired.

I must admit, however, that while I like MochiKit for its general philosophy and the fact that it’s one of the best documented ‘New Age’ JavaScript libraries/frameworks/toolkits around, I’ve gone back to using Prototype.js for most of my work. MochiKit is big. It’s powerful, but big. Yet I found myself straining to copy over some really useful little functions from Prototype, some done while trying to make the Ajax calls a little easier to work with. Ultimately, I find that my Prototype.js based code tends to be easier to read, write, and comprehend. I’m a JavaScript outsider, and Prototype.js pulls enough tricks to make programming much more familiar and convenient. While it’s not well documented, its source code is actually quite easy to read. Both toolkits are nice, but I now reserve MochiKit for heavy-lifting situations only.

Congratulations to Allan Odgaard and everyone else involved with TextMate on winning an Apple Design Award for Best Mac OS X Developer Tool. TextMate has so greatly improved my development life, finally allowing me to (where possible) work on my desktops / laptop instead of on a development server as I’ve done for so many years.

A little bit of my development day today: Using Mac OS X terminal to test a new date-range formatting function. The results were clipped directly into a Circus Ponies Notebook page without leaving Terminal via Mac OS X Services. All of those clippings were then brought into Hog Bay Software’s excellent WriteRoom where I went into full screen mode to turn the test results into documentation that could run via Python’s super-cool Doctest tool. Using WriteRoom for this allowed me to focus on writing the documentation without distractions: it was like being back in the old old 70’s terminals: green text, black screen. No syntax coloring, no modes, nothing.

A couple of times while writing the documentation, I was able to use the globally installed Edit in TextMate… command that lets just about any Cocoa text field / area / etc be editable in a TextMate window. I used this during the main writing to do some big find/replace runs (some names that I had imported in the terminal were redundant in the test documentation). So, from WriteRoom, I hit Edit in TextMate… (actually, I just hit control-command-e) and a new TextMate window opens up with the contents of my WriteRoom document. I used TextMate’s nicer search/replace tools to do some mass fixing, hit ‘save’ to send the results back to WriteRoom, and closed the window - which caused a direct return to WriteRoom.

Again, this was nice for this situation since I could use a specialized no-frills tool to focus on the words I wanted to write. When I was done with the writing, I copied everything out of WriteRoom and went back to TextMate to paste the documentation in the docstring of this function. At that point I could use TextMate’s tools and powers to format the results (wrap / indent properly, apply some reStructuredText styling, etc).

What a cool little collection of tools.

And happily, when the documentation test was executed, it ran on the first pass.

These are absolutely amazing. Phill Ryu held a Fake Leopard Screenshot Contest in anticipation of next week’s Apple Developer Conference which will unveil the next version of Mac OS X. Some of these people put a lot of time into these designs and some of theme are quite interesting. The winning shots by Eric Patterson are quite nice, going for user experience: more views of data “your way”, nice collections of information. Some of it reminds me of the pie-in-the-sky Longhorn screen shots showcasing all of the power of Windows Vista.. well, all the power that was hoped… And Eric’s tabbed finder is about the only mock-up that I’ve seen that I would use.

Honestly - why are people so obsessed with a tabbed Finder? I like the Finder browser (metal) windows, I like Column view, but I don’t want tabs. What I do want is “Open Folder in New Browser Window” so I can branch off at any time. What I would like - a shelf. The sidebar in the Finder is nice. I use it like Tabs anyways, but it’s better. It’s so easy to throw folders on there for one time use for easy copying. And it’s useful when working on long-term projects for rapid access to documents. But it doesn’t deal with drives going away and coming back very well.

Anyways, back to the fake screenshots. The final runner-up is acknowledged as being the most out there, and the most controversial. I like this guy for - ahem - thinking differently. Stephen Sciliano wraps everything up into a single window interface, with multiple panes. I’ve seen some Unix window managers that do similar, with a heavy focus on being text-only. I think I know some people who are big fans of it. Sciliano’s mock-up reminds me a bit of OpenDoc gone wild, and reminds me of Microsoft’s new UI for Office 2007.

Another runner-up, Nathan Ziarek, focuses heavily on metadata - particularly on making metadata easy and obvious. Among other things, his shots showcase being able to associate files and other items with To Do items in iCal, and associating files with contacts so that viewing them from the contact view can link to associated files and other objects.

And that brings me back to one of my favorite Longhorn images (which I haven’t been able to find) was one that showed a Contact. Well, not a contact, but everything associated with that contact: IM chats, phone calls, files, events, etc. In one window, nice and clean. I think it was a WinFS showcase item. I haven’t seen anything like it in Longhorn / Vista screen shots over the past couple of years. That’s something I would like: ways to just group a lot of different information together without requiring a third party app.

I want this most in the home studio. I have lots of audio files and (now) a rapidly growing iPhoto library. The audio files at home that I’m concerned about are not the songs in my iTunes library, but all of the work for Eucci, aodl, etc. Most of them are raw little audio bits, not fit for a loop library or management through a dedicated audio program: they’re AIFF’s of various lengths in various states of processing. I use labels (the little color codes in the Finder) to highlight some of them, such as completed pieces or raw sources (usually the two kinds worth keeping around), but they still tend to get lost, especially if I’ve been away for a while. It would be nice if it were easier to tag those files, to group them dynamically, to associate them with a particular contact to whom I’ve promised an album, to associate them with a to-do so that I have a better sense of what I was doing if I have been away for a while. “Oh yeah, I need to just finalize the levels on that track and I can send it to …”.