PowerTunes 1.0 is out!

Posted on July 9, 2008 by Brian Webster
Filed Under PowerTunes, News, Updates | Leave a Comment

I’m proud to announce that today I’m releasing a brand new application, PowerTunes! PowerTunes is to iTunes what iPhoto Library Manager is to iPhoto - it will let you:

It’s very satisfying to finally ship, especially after having worked on PowerTunes in one form or another for about a year and a half now. It’s been my number one request from existing users of iPhoto Library Manager and it’s been something I’ve wanted to do for quite a while.

As is always the case, I had way more feature ideas than I could possibly hope to implement in a 1.0 release (otherwise it would never ship!). In deciding the feature set for the program, I tried to concentrate on things relating to file management. There are plenty of things I could have done involving messing around with editing tags and such, which is a very common need, but is also already covered by a lot of other apps out there. My hope is that PowerTunes’ feature set is unique enough to be useful to many iTunes users, even if they already have one or more other iTunes helper programs.

The development process was, as always, enlightening, and I definitely plan to write up a couple blog posts exploring some aspects of developing this program. The most interesting thing overall is the program’s similarity in function to iPhoto Library Manager. This allowed me to reuse a bunch of code from iPLM, but it also gave me the opportunity to look back at the way I did some things in iPLM and reimplement them in new, better ways. The result of that is now giving me an overwhelming urge to tear up iPLM’s internals and redo it to match the way things work in PowerTunes. :)

So, go ahead and give PowerTunes a try! The program has a 30 day trial period during which all features of the application are fully accessible. After that, you’ll still be able to do the most basic things like open up your existing libraries, but most of the advanced functionality will be turned off until you get a license for the software.

And in case you’re wondering why I chose the name “PowerTunes” instead of, say, “iTunes Library Manager”, the answer is a) there is already a product with that name, and b) I learned my lesson with iPhoto Library Manager, whose name is really way too long. I mean come on - 9 syllables? What was I thinking? :)

Fixing Applescript

Posted on June 3, 2008 by Brian Webster
Filed Under Programming, Development | 1 Comment

After reading Daniel Jalkut’s post about replacing/supplementing Applescript on the Mac with Javascript (or perhaps another scripting language such a Ruby or Python), it got me to thinking about what exactly it is about Applescript that tends to trip people up. Would it be possible to figure out what the problem areas are, and just fix Applescript in those areas? There would be problems to this approach, the most prominent one being backwards compatibility. Some of the problems are fundamental enough that, if you fixed them, it would cause existing scripts to break. I believe Apple actually had plans a few years back of making a “new” Applescript that mostly acted like current Applescript, but was in fact a separate language and made an explicit break with previous versions of the language. Kind of like Carbon, where 80% of the stuff would work fine, but that problematic 20% would need rewriting under the new system.

So, what exactly are the problems that vex Applescripters so? There are quite a few, but here are some of the ones I can think of.

Lack of basic language features


Many modern scripting languages come with a fairly hefty set of built in data types and functions (or classes and methods for OO languages) that support a wide array of built-in functionality. Applescript has its own set of functionality, but for many standard tasks, it frequently either lacks the ability to do so at all or supports things but in a very hard to use or unintuitive way. A few examples include:

This is just a small sample, I’m sure there are many other things that are pretty standard in other languages that are absent from Applescript, or hidden away in the Standard Additions scripting dictionary somewhere.

File references are the devil



There are at least 5 different ways I can think of to refer to a file using Applescript (alias, POSIX file (a.k.a. file URL), Finder style object specifier, POSIX path, Carbon path). Different applications use different data types in different places, and will often barf back errors if you don’t use just the right kind of file reference. Figuring out how to translate from one kind to another is often maddening. Here’s an example from one of my own scripts, which uses three of the five types in a single line:


set helpFolderPath to POSIX path of ((folder “Help” of folder “en.lproj” of ptFolderAlias) as alias)

Files really need to be treated as first class citizens, with support built in to the language, and without needing to rely on the Finder for all file system access. Or wait, am I supposed to rely on System Events now instead? Or maybe a “do shell script” call to ls on the command line? Oh, the pain.

Scripting dictionaries



This is one of the biggest hurdles that a lot of beginning scripters have with Applescript, is understanding how scripting dictionaries work. Tools like Script Debugger are extremely helpful when it comes to exploring an application’s dictionary (I hardly look at the dictionary anymore these days, and just go right to the explorer pane and start drilling down), but while $199 is a fair price for a developer, most people aren’t going to want to drop that sort of change just to learn Applescript. Script Editor did get a pretty good upgrade in Tiger, but I think it needs more work to help beginning scripters understand how to explore and use scripting dictionaries.

The death of recordability

Another invaluable tool for beginning scripters which is all but dead is application recordability. Back in the OS 9 days, you could hit the “Record” button in Script Editor and go perform operations in other applications, and the equivalent script commands would magically appear in Script Editor. This was a great way to quickly learn the commands to use to do certain things you already knew how to do using the GUI of the application. Since OS X, recording has basically gone away. The only applications I know of that are still recordable are the Finder and BBEdit/TextWrangler. Cocoa has zero support for recordability. Theoretically, you can use the Carbon APIs to do this still. I actually tried once, and gave up after a couple days of banging my head against the wall. I’d love to see recordability come back, with a whole new approach if necessary, with full Cocoa support.

Applescript does have a lot going for it, but is hamstrung by a lot of these types of issues and prevented from reaching its full potential. Replacing it with another language is one way to go, but fixing Applescript also has a lot of potential. This above list is just a sample of some of Applescript’s shortcomings (if you have your own pet peeves, feel free to express them in the comments). The idea of redesigning Applescript from the ground up, with nearly 20 years of experience to build on, is very appealing, but who knows if Apple will ever have resources to devote to a project like that.

Disappearing iPhoto libraries on external drives

Posted on May 16, 2008 by Brian Webster
Filed Under iPhoto, Tips & Tricks, iPhoto Library Manager | Leave a Comment

I just came across this article on TidBITS explaining how to deal with stray “doppleganger” folders that get created in the /Volumes directory, where external hard drives and network drives are mounted by Mac OS X. I’ve seen this particular issue come up quite a number of times with people working with iPhoto, so I’m glad to see someone else writing on the topic. I encourage everyone to go read the article, since you never know when this will crop up on your machine, and it’s good to have this floating around in your head as a possible cause.

The way this typically affects people using iPhoto is when you’re trying to open a library that you store on an external hard drive. One day, for no apparent reason, you open up iPhoto and are greeted with a totally empty library. Where did all my photos go!? Aaaaagh!

You’ll be glad to know that your photos aren’t actually gone, they’re just in a slightly different place, so iPhoto can’t find them. iPhoto stores its library location by a plain path, so it will be pointing to the “doppleganger” folder, instead of following the library to its new path where the external drive is actually located.

iPhoto Library Manager itself uses aliases to track library locations, so when this happens, it will usually figure out to update itself to point to libraries’ new locations. If it doesn’t automatically update, all you have to do then is to re-add any libraries that are pointing to the wrong place to iPLM’s library list, either by using the “Add Library” button, or by just dragging each library into the list. You can then remove the old, stale references from the library list, and you should be all set. If you’re just using iPhoto’s option-key-on-startup trick to switch libraries, you can just do that and go find the real library on the external drive to get iPhoto pointed back to the correct location.

Announcing PowerTunes private beta

Posted on April 23, 2008 by Brian Webster
Filed Under PowerTunes, News, Updates | Leave a Comment

You may have noticed things have been a bit quiet around here lately. The biggest reason for that is that I’ve been working on a brand new product for the last several months, called PowerTunes. The number one request I get from people who use iPhoto Library Manager is to have a similar program that lets you have multiple iTunes libraries. I’ve wanted to do this for a while, and finally started development on PowerTunes last year, in parallel with continuing work on iPhoto Library Manager and PlistEdit Pro. Today, it’s getting close to being ready to release, but I still need to do some further testing on it, so I’ve decided to run a (hopefully short) private beta to help work out any remaining kinks.

The basic idea behind PowerTunes is quite similar to iPhoto Library Manager: instead of just having one monolithic iTunes library where you dump all your music and video, you can instead split your stuff up among multiple libraries and switch between them. This can be useful for simple organizational purposes, and can allow you to do things such as allow multiple people to keep separate iTunes collections (and sync them with their respective iPods) without having to go through the hassle of setting up multiple user accounts to do so.

Like iPhoto Library Manager, not only does PowerTunes let you set up multiple libraries, but it also offers additional features that let you copy music and playlists between libraries, organize multiple music folders, clean out unwanted files from your music folder, fix dead tracks in your library, and much more.

iTunes 7 actually added for the first time the ability to place your iTunes library file in a different location from the default location by holding down the option key when you launch iTunes, just the same as you can in iPhoto (previously, the only way you could shift your iTunes library location was by using aliases and such). PowerTunes actually utilizes this mechanism itself, and thus requires iTunes 7 or later. Unlike iTunes, PowerTunes also ties each library to a particular music folder, so if you have music stored in separate places, it will switch the music folder location along with the library location when you change back and forth.

The main reason for want to have some other testers before a final release is that there are many possible ways one could go about setting up their iTunes libraries and music folders, including putting stuff on external hard drives, accessing stuff over file sharing or an Airport Disk, and so on. I’ve tested as much of this as I can, but there will always be setups I either can’t test or haven’t even thought of.

So, if you’re interested in helping to test PowerTunes, I’ve set up a form that you can fill out to sign up for the beta. I don’t know how many testers I’ll need or how long the testing period will take at this point. If everything works fine, it could be as brief as a couple weeks, or it could take longer if more things need fixing. So, depending on how many testers I need, not all those who signup will necessarily become testers.

Like I said before, I’ve done a lot of testing so far, but the possibility of bugs occurring still remains, so all testers will be encouraged to back up their iTunes library and music, just in case. Those who do help in testing will get a free PowerTunes license and the thrill that comes from running beta software. :-)

So, if you’re interested, head on over to the signup form and sign up to be a beta tester. Oh, and I almost forgot, a couple obligatory screenshots. :-)


Picture 1.png
sharing.png
sharing.png

MacSanta is coming to town

Posted on December 15, 2007 by Brian Webster
Filed Under News, PlistEdit Pro, iPhoto Library Manager | Leave a Comment

I’m happy to be participating this year in the MacSanta promotion! Generously set up by Paul Kafasis of Rogue Amoeba, MacSanta offers deals from now until Christmas on products from five new Mac software companies every day. iPhoto Library Manager and PlistEdit Pro are both being featured today (December 15th), and you can get 20% off by using the coupon code MACSANTA07 when purchasing.

Also be sure to check out the Extended Deals page, which lists all the products that have been featured so far in the month, and you can still get 10% off any of those products by using the coupon code MACSANTA07TEN anytime until the end of December (this also applies to iPhoto Library Manager and PlistEdit Pro after today). There is also an RSS feed available, so you can continue to keep up on new deals that appear between now and Christmas.

Optimization for Dummies

Posted on November 23, 2007 by Brian Webster
Filed Under Cocoa, Programming, Development | 2 Comments

A somewhat inconspicuous looking article on optimizing third party code has stirred up quite a conversation/flame war among many in the Mac developer community. The comment thread on the article is already quite long, and it seems to me that the people with opposing viewpoints are just talking right past each other at this point, so I thought I’d add in my own perspective here.

The jist of the article is that the author, Ankur, needed to draw some gradients in one of his applications, downloaded the source code for CTGradient, an open source library that provides a class to draw various types of gradients, and decided that it had way more functionality than he needed in his own program. So, he went through the code and basically removed everything he didn’t need for this single application. That’s all fine and good, and the article is actually an interesting look at performing various refactorings and dead code removal.

The problem arises in that he implies that if a developer decides to use some open source code and doesn’t go through and strip out every ounce of functionality that they’re not immediately using, that means that they’re encouraging “code bloat” and that their code is not “optimized”. Several commenters asked what kind of performance/memory gain he actually saw, and the only numbers he provided were from the “Real Memory” column in Activity Monitor, which is a pretty crude measure. The conversation went downhill from there.

I think one main point of miscommunication here is over the terminology the original author uses for some of the things he’s talking about. When you talk about “optimizing” code, I, and most other developers I know of, think of making the code run faster. The author reinforces this by stating “…you can optimize this thing till it runs like a Ferrari”. Certainly sounds like he’s talking about making the code faster, but the vast majority of what he’s doing is simply stripping out code that he’s not going to be using. This has pretty little effect in and of itself - it saves a few KB in disk space, and if the code truly is unused, it probably won’t even get paged into memory in the first place. There are a few places where the code probably runs faster, but the gains look pretty minimal in the big picture. However, arguing the nitty gritty details about his particular optimizations is missing the bigger point…

Engineering is all about tradeoffs, and in computer software, this typically means choosing between things such as memory usage, disk usage, CPU usage, and so on. Every one of these, however, inevitably comes up against the restraint of development time. You can spend days, weeks, or months optimizing your code in various ways, but it’s all for naught if you don’t eventually ship your application. This means that you can’t do everything, and have to pick and choose what areas of your code to work on, whether to add new features or shore up existing ones, and how much time to spend optimizing performance and memory usage.

What is conspicuously missing from the article is any sort of evidence that CTGradient was actually causing any sort of performance or memory problem in his application in the first place. Now, may more have gone on that he didn’t include in his write-up, but it sounds like he simply looked at the code, decided that it was obviously too big and bloated, and set to work spending quite a bit of time hacking it down to the bare minimum he needed.

Finding and fixing performance and memory problems in real applications, however, is rarely so simple. It’s rare that you can glance at a piece of code and immediately deduce that it’s going to be problematic for your application, causing slowdowns or whatnot. Most such bottlenecks are discovered as a result of rigorous testing, using tools provided by Apple such as Sampler, Shark, and Instruments (among others) to dig into the details of what your app is actually doing and where it’s spending its time. Upon discovering such a problem, you can then go in and spend your precious time fixing what most needs to be fixed. It’s not that the modifications he makes don’t actually reduce code size and memory footprint (they do) or increase performance (still not really sure about this without empirical data), but with testing first to find what needs fixing, the time spent doing all this could very well have been better spent fixing something that actually needs fixing.

I actually use CTGradient in a couple of my projects, and I use the code basically untouched. This is not because I’m “lazy” and would rather count my customers’ money while cackling evilly than spend the time to strip out everything I don’t use, but rather because I have plenty of other things to spend time on, optimizing my app in ways that make a difference, and adding features that people want and need. None of my tests of my drawing code have ever shown any performance problems arising from using CTGradient as-is, so my motto is, if it ain’t broke, don’t fix it. The critical flaw in Ankur’s argument in his post is that he never showed any evidence that anything was broken in the first place.

Miscellaneous Leopard development gotchas

Posted on November 1, 2007 by Brian Webster
Filed Under Cocoa, Programming, Development, Tips & Tricks | Leave a Comment

I’ve been using Xcode 3.0 under Leopard to do my development since Leopard came out last week, and thought I’d share a few changes that tripped me up.

Well, that’s what I’ve got for now, I may add more to the list later as I come across them. Hopefully this will help somebody out there (or maybe myself in a couple months when I forget and have to relearn this stuff over again).

Running FogBugz on Leopard

Posted on October 30, 2007 by Brian Webster
Filed Under Development, Tips & Tricks | 1 Comment

I use FogBugz as my main bug tracking and customer support system. It’s a neat application that runs on PHP and a web interface and allows me to both keep track of bugs/features in my development, as well as handle all tech support e-mail. It’s designed with a multi-user environment in mind, but works quite well for a one-man shop such as myself. The web interface is not as good as a true desktop interface could be, but it’s perfectly sufficient, and I’ve become quite dependent on FogBugz as part of my daily workflow.

Dependent enough that it was a rather rude (but not wholly unexpected) discovery to find that upgrading to Leopard pretty soundly hosed my FogBugz installation. Not that it went and deleted files or data or anything, but the setup was quite far from working normally.

The primary cause for this was that Leopard now ships with Apache 2.2, whereas Tiger came with Apache 1.3. All the various differences are well documented out there on the intertubes, but a lot of things, such as where configuration files are stored, changed between the two versions. For example, instead of httpd.conf being in /etc/httpd, it now resides in /etc/apache2.

I got that part figured out pretty quickly, but then when I went to start up the web server, I would get a message printed in the system console reading:

Oct 30 12:07:57 bw-mbp org.apache.httpd[11317]: httpd: Syntax error on line 484 of /private/etc/apache2/httpd.conf: Syntax error on line 8 of /private/etc/apache2/other/+entropy-php.conf: Cannot load /usr/local/php5/libphp5.so into server: dlopen(/usr/local/php5/libphp5.so, 10): no suitable image found. Did find:\n\t/usr/local/php5/libphp5.so: no matching architecture in universal wrapper

Hmmm, well, I do have a custom build of PHP5 (in /usr/local/php5, with additional extensions needed for FogBugz) and it seems to be finding that OK, but it’s complaining about architecture something-or-other. I’m still running on Intel, aren’t I?

[bw-mbp:~] bwebster% file /usr/local/php5/libphp5.so
/usr/local/php5/libphp5.so: Mach-O universal binary with 2 architectures
/usr/local/php5/libphp5.so (for architecture ppc): Mach-O bundle ppc
/usr/local/php5/libphp5.so (for architecture i386): Mach-O bundle i386

Yeah, that’s got an Intel build in there, that’s OK. What the heck is Apache’s problem?

[bw-mbp:~] bwebster% file /usr/sbin/httpd
/usr/sbin/httpd: Mach-O universal binary with 4 architectures
/usr/sbin/httpd (for architecture ppc7400): Mach-O executable ppc
/usr/sbin/httpd (for architecture ppc64): Mach-O 64-bit executable ppc64
/usr/sbin/httpd (for architecture i386): Mach-O executable i386
/usr/sbin/httpd (for architecture x86_64): Mach-O 64-bit executable x86_64

Oooh, I see 64-bit stuff in there, don’t I? I suppose that could be a problem if it’s trying to load a 32-bit library. Well, the packaged PHP that I installed from entropy.ch hasn’t been updated yet for Leopard, so I guess I’ll have to download and compile PHP myself so I can get in on the 64-bit goodness.

*insert footage of Brian downloading a bunch of stuff, typing ./configure and make, and seeing copious error messages fly across his terminal window*

Hmmm, OK, I think someone smarter than me is going to need to figure this stuff out. But I don’t have time for that, I want to get my FogBugz up and running so I don’t have to switch back to Tiger just to answer customer e-mail. If I could just force Apache to run as 32-bit instead of 64-bit, it should be able to load this PHP module just fine. Now let’s see, what would Dr. 90210 do…?

[bw-mbp:~] bwebster% man lipo

Yes, this is extremely hacktackular, and I’m sure there must be a better way to do this, but this is what I got.

[bw-mbp:~] bwebster% cd /usr/sbin

[bw-mbp:~] bwebster% sudo cp httpd httpd-fat

[bw-mbp:~] bwebster% sudo lipo httpd -thin i386 -output httpd

After making a backup of the httpd executable for safety purposes, the lipo commands sucks out all of the architectures included in the universal binary except the 32-bit Intel one (specified by “i386″). Apache can’t run as 64-bit if it doesn’t have a 64-bit binary!

After doing this, starting up the web server again worked just fine, and loaded the existing 32-bit PHP5 module. Once I got all my httpd.conf customizations moved over to the new location, that was pretty much all I needed to do. It also turns out that I probably would have run into this same problem for FogBugz specifically, since it loads its own fogutil.so PHP module which is also only available as 32-bit right now. I don’t know for sure, but I’m guessing people running on G5s, which also support 64-bit, would probably need the same trick, except replacing “ppc” for “i386″.

This is obviously a very poor long term solution, but if anyone needs to get FogBugz up and running on Leopard right away, this did the trick for me. Ultimately, getting FogBugz to work hack-free will require someone to get a 64-bit build of the PHP5 Apache module figured out, as well as Fog Creek providing a 64-bit build of their own Apache module. And of course what I’ve outlined here is totally unsupported by Fog Creek, so proceed at your own risk!

iPhoto Library Manager 3.4 released

Posted on October 30, 2007 by Brian Webster
Filed Under Updates, iPhoto Library Manager | 7 Comments

At long last, iPhoto Library Manager is ready for Leopard! OK, it hasn’t really been that long since Leopard came out (4 days?), but it seemed like a long time. The new version is available for download and as usual, is a free update for existing customers. Leopard compatibility was the biggest change in this new version, but it also includes a bug fix or two as well. Enjoy!

MacFixIt’s scare tactics

Posted on October 26, 2007 by Brian Webster
Filed Under Apple | Leave a Comment

I just read this article on MacJournals regarding MacFixit’s tendancy to overhype problems, and I’m glad someone is calling a spade a spade here. MacFixIt used to be a useful site, but in recent years it has gone downhill in the quality of what they publish, almost to the point of being useless, or worse, harmful. It reminds me somewhat of Symantec trying to hype nonexistent virus threats to the Mac so they can sell more copies of Norton AntiVirus that nobody needs.

The article uses a recent MacFixIt post on DiskWarrior as an example, and I actually used to work for Alsoft for a few years, and it’s definitely not the first time this sort of thing has happened with MacFixIt. We had to deal with them on several occasions when they posted various stories, mostly regarding DiskWarrior, that either stretched the truth or were just outright false.

It seems that a large amount of MacFixIt’s material comes from reader e-mails and other such input. That’s not a problem in and of itself, but the problem is that there is almost no effort put forth on their part to filter and/or verify the statements made by their readers. The result is that stories go up on the site that have absolutely no basis in reality, simply because one or two readers e-mailed in. “I noticed that when I upgraded my iLife on the full moon, it crashed my machine, but then when I rebooted and tried again when the moon was waning, it worked!” results in the headline “Warning: iLife installer deletes your photos when installed under a full moon!“

MacFixIt seems to hardly ever even bother to try some of these things readers write in about to see if they actually behave as described, but even worse, they often won’t even try verifying something with the developer of an application if a problem is reported with it. This happened several times at Alsoft, where some reader reported a problem with DiskWarrior and blamed it on something, and MacFixIt happily plastered it on their front page as though it were gospel, causing all sorts of people to panic about running DiskWarrior under whatever circumstances they claimed caused the problem. I remember one case in particular where they claimed that DiskWarrior wouldn’t work with Firewire 800 drives (which is utter nonsense), simply because some reader had had a problem rebuilding their own Firewire 800 drive. Of course it turned out to have a completely different cause (a bug in Quicktime), one that had actually already been well documented months ago, on MacFixIt’s own site!.

Had they bothered to simply shoot an e-mail or phone call our way, we could have provided them with the solution, they could have referred their reader to their old article with the solution, and saved everyone a whole lot of hassle. This is not only a problem for MacFixIt’s readers, but it costs the victim company time and money in responding to the resulting support calls and e-mails, plus the effort needed by the company to try to set the record straight.

So, if you’re a regular MacFixIt reader, I would encourage you to take everything they say at least with a grain of salt, if not to stop reading the site altogether. They have journalistic integrity on par with the National Enquirer. And if you do experience a problem with a program, contact the program’s developer. They are often quite helpful and actually know what they’re talking about, and will be happy to help you with your problem. Now if you’ll excuse me, I need to go install Leopard before the tides come in…

keep looking »

Feed