Tag: computers

App Store First Impressions

Today Apple launched the App Store for Mac. The App Store on the Mac is a lot like the App store for the iPhone/iPad/iPod that is part of the iTunes Store. I’ve been spending some time today trying out the App Store, have downloaded a few of the free applications, and have made a few modest purchases. Here are some of my initial impressions.

The App Store is installed when you update your Mac operating software to 10.6.6 (by selecting “Software Update…” from the Apple Menu). It is not available to those running older versions of the Mac OS, like Leopard and Tiger. This is not much of a problem for me, as I almost always run the latest version of the operating system. But I do know people who are still running older versions of the Mac OS who won’t be able to attend the App Store party, at least not until they upgrade (assuming they have an Intel Mac and can upgrade to Snow Leopard).

Once installed, the App Store icon appears in the dock, by default right next to the Finder icon. A link to the App Store also appears in the first section of the Apple Menu, right below Software Update. And of course, the App Store application can be found in the Application folder. The App Store for Mac is not hard to miss, but It’s not built into iTunes, where I suppose it could be confused with the App Store for iOS.

Although the App Store is a separate application from iTunes, it borrows heavily from the App Store on iTunes in form and function. You use your Apple ID to login, and iTunes Store account information is used for any purchases. So if you got an iTunes Gift Card like I did over the holidays, you can now use it to pay for Apps from the App Store. This makes those iTunes Gift Cards quite versatile: I can use them in iTunes to purchase music and music videos, rent and/or purchase movies and TV shows, buy audiobooks and apps for my iOS devices, plus I can use them in iBooks to purchase books. And now I can use them to buy software for my Mac. Sweet.

One of the first things I noticed after I launched the App Store was that it recognized quite a few programs already installed on my Mac. For example, instead of a “Buy” button next to the description for iMovie, there was an “Installed” button. This was true for all of the programs in the iLife and iWork suites, as well as some third-party programs that I had on my computer, like MacFamily Tree from Synium Software and Transmit from Panic Software.

But interestingly, not all programs that are on my computer show up as installed in the App Store. For example, I own iStopMotion Home from Boinx Software, yet the App Store does not seem to recognize it. At first I thought this might be due to having a different version installed, but no, the version on my computer is the same version that is available from the App Store. This behavior is not unique to Boinx products, as I noticed the same thing with Compartments from LittleFin Software and TapeDeck from SuperMegaUltraGoovy (yes that really is the name of the developer of this fine audio recording app). I suspect that programmers need to include something in a a program’s code in order for the App Store to recognize it as installed, so perhaps these programs just need to include this code in future versions.

The first program I purchased on the App Store today was a game called Chopper 2 from Majic Jungle Software. I own the first version of Chopper, and thought this would be a good time to upgrade to Chopper 2. The price was certainly right: Chopper 2 is just 99 cents (for a “limited time” according to the App Store). Purchasing was easy, and proceeded much like a purchase in iTunes. Once I clicked the Buy button, I saw a cute animation of the Chopper 2 icon flying from the App Store to land in the dock, along with a download progress indicator below it. Once installed, the Buy button became an Installed button in the App Store. Unlike my other apps that the App Store recognizes as installed, Chopper 2 was listed in the App Store under the purchases tab. It seems that only apps purchased through the App Store show up on this list.

One of the most interesting things I noticed about the App Store was the dramatic reduction in prices on some of Apple’s products. Aperture, for example, retails in a physical box for $199, but costs just $79.99 as a download through the App Store. This is less than the price of the Academic version of Aperture, which unfortunately is not available for upgrade pricing. (I wonder if the App Store version of Aperture will be eligible for upgrade pricing when a new version comes out.) Even more dramatic is the cost reduction of Apple Remote Desktop. Yesterday this product cost $299 for the ten seat version and $499 for the unlimited seat version. But today it can be downloaded from the App Store for just $79.99. And since the App Store description doesn’t mention a seat limitation, this might be the unlimited version, which could make this a very tempting purchase. What is not clear to me, however, is whether the terms of the license for this product would allow me to use it to manage a small group of computers where I work. The license reads that I can install the software on computers that I “own or control,” so perhaps this might be permissible. In any case, it’s interesting that the version of ARD on the App Store makes no mention of a limit on how many clients one can control; I’m still not clear on why Apple decided to sell two different versions of ARD based on the number of clients anyway.

There are plenty of good apps available at good prices in the App Store. There are also quite a few not-so-good apps available, but I suspect the overall quality level of the software available will improve with time. Noticeably absent from the App Store are the big third-party software companies, like Adobe and Microsoft, which is perhaps not surprising. Staples like Roxio’s Toast and Parallels Desktop are also absent. Given the time of the year, I was really surprised not to find any of the major tax preparation programs available on the App Store. Neither Intuit’s TurboTax nor H&R Block at Home (formerly known as TaxCut) are currently available.

Another surprise was the absence of iBooks from the launch of the Mac App Store. Amazon’s Kindle app is on the App Store, so I suspect it won’t be long until we see iBooks released for Mac. But this raises an interesting possibility of having three programs on my Mac where I could spend my iTunes gift cards: iTunes, the App Store, and iBooks. Perhaps this is the start of a trend, and someday Apple will enable the use of iTunes cards in iPhoto for paying for cards and calendars.

In general, I think the App Store is off to a strong start. There are some inconsistencies in how it recognizes installed apps, and I hope Apple improves on this feature in a future update. I think the App Store could eventually move closer to the functionality of the MacUpdate Desktop App, recognizing all of the software on your computer and alerting you to any available updates. The current number of apps for sale in the Mac App Store is modest; at the moment, there are only 7 programs available in the news category, 8 programs in the Weather category, and 9 in the Medical category. But I suspect the number of available apps will grow quickly as developers recognize the potential of this new marketplace for Mac software.

Podcast Producer 2 and the iPad

Shortly after I got my iPad, I discovered something interesting. Whenever I visited one of the many web pages on my Snow Leopard Server with embedded videos created by Podcast Producer 2, the videos wouldn’t play. When I clicked the thumbnail, the image would just turn to a black square.

Some of you who read my blog know that I’ve written many posts about Podcast Producer 2, a key component of Snow Leopard Server. I’ve described various techniques for getting Podcast Producer 2 (PP2) to “play nice” with Windows Internet Explorer, and how I substituted the Quicktime plugin for the open source Flash player Flowplayer. Of course, Flash doesn’t work on the iPhone, but that wasn’t a major issue since Snow Leopard Server dishes up a different version of a PP2 page for iPhones. I had hacked together a solution that would serve PP2 videos inside Flowplayer when viewed on a computer browser, but serve PP2 videos inside the native H.264 player on the iPhone.

But my little cludge didn’t work on Mobile Safari on the iPad. That’s because Snow Leopard Server doesn’t serve up a different page for iPads like it does for iPhones. Perhaps this is deliberate, since the bigger screen real estate on the iPad doesn’t necessitate the compact presentation of an iPhone-optimized page. Or perhaps Apple didn’t include in the latest update to Snow Leopard Server specific user agent detection code to serve iPad-optimized pages.

Whatever the case may be, I reported this situation as a bug to Apple a few days ago. I had hoped that the most recent Snow Leopard Server update would include code that would produce PP2 pages that could be viewed on the iPad, but no such luck. Hopefully, this will come in an update down the road. But until then, I’ve developed a workaround.

Here’s how I got PP2 to play nice with the iPad…

First, I downloaded the open source javascript library Modernizr from http://www.modernizr.com. This little gem allows one to detect whether a client’s web browser can handle HTML 5. Mobile Safari on the iPad can display HTML 5 video, and in fact, Apple explicitly recommends using the HTML 5 VIDEO tag to display video on an iPad optimized page in this technote.

I put the Modernizr javascript file in my web directory (I just put it at the root level). Then I added a line in the custom wiki theme that I use for PP2 pages. The line I added is just a simple SCRIPT tag that references the Modernizr javascript file. Essentially, every page the PP2/Wiki Server produces that uses this custom wiki theme will include a call to the Modernizr javascript library. This wasn’t hard to do; in fact, the process was very similar to what I did to add a call to the Flowplayer javascript library that I described in great detail in a previous post.

Next, I added the following bit of code in the expandMedia function found in wiki.js (and compressed_wiki.js)…


else if (Modernizr.video) {
var objectHTML = '<video autoplay width="'+img.width+'" height="'+(img.height+(extendHeight?16:0))+'" src="'+fullSrc+'?sessionID='+server().sessionID+'" controls></video>';
embed.innerHTML = objectHTML;
Element.hide(img);
}

Essentially what this code does is call on Modernizr to test whether a browser supports HTML 5, and if so, uses HTML 5 to display the PP2 video instead of presenting it with the Quicktime plugin. I use the autoplay attribute to cause the video to click when a user clicks on the thumbnail. And the controls attribute causes the video to be displayed with whatever playback control bar is provided by the browser.

Again, I describe in great detail in this previous post the process for editing the wiki.js and compressed_wiki.js files, since I used a similar technique for swapping out the Quicktime plugin for Flowplayer. I would certainly recommend making backups of the original wiki.js and compressed_wiki.js files, as well as any modifications, since these files will likely be overwritten by future Snow Leopard Server updates.

With these changes, the Podcast Producer 2 videos on my website can now be played on an iPad. Indeed, as an added bonus, these videos are now displayed using HTML 5 on any web browser that supports HTML 5, like Safari and Chrome. The Modernizr script detects whether the page is being viewed in an HTML 5 capable browser, and if so, my code swaps in the appropriate HTML 5 code.

My iPad is happy now. Here’s hoping that the folks at Apple who maintain the Snow Leopard Server code will produce an update that will work with an iPad someday. Until then, my little hack seems to do the trick.

Graffiti Networks Project ate my wiki!

Today I noticed something strange while backing up the database from another website I manage, ComWiki. The database backup took much longer than usual, and I was surprised when the size of the backup started to go over a gigabyte. Either someone had been adding lots of pages to the wiki, or something weird was going on.

So I went to the “All pages” page on the wiki and noticed a bunch of pages with strange titles that appeared to be spam-like URLs. Visiting those pages gave me a big shock, as the content appeared to be some kind of binary code. It sort of reminded me of the old Usenet rar files, line after line of gobbledegook that looked suspiciously like a slice of Warez.

Then I got an even bigger surprise, when I got a message on my screen that Google had detected malware on the site. Oh boy.

After doing some more digging, I found a note from something called the Graffiti Networks Project. Apparently, this was a project started by a couple of students at Brown University to exploit a weakness in MediaWiki, the open source software that runs Wikipedia (and the software I use on ComWiki). Essentially, the project demonstrated how one could use this weakness to establish a peer to peer file sharing network.

Here’s the more technical description from their website:

In response to the lack of user anonymity and long-term data persistence in existing P2P systems, we developed the Graffiti Network distributed file sharing protocol that uses multiple third-party storage sites as a data replication and transfer medium between clients. Our approach is to use publically available web sites to store multiple copies of shared content. We use the term graffiti for our work since we are storing data in a way that non-network participants may regard as unsightly or unwanted vandalism.

Employing the same concept of a central tracker as in the BitTorrent protocol, a Graffiti client will connect to a tracker and receive well-defined instructions on where and how to retrieve segments of shared files from a remote storage site. Upon successfully downloading and decrypting some portion of the shared data, the client will receive further instructions to replicate that same data at different storage site. If the client succeeds in replicating the data, it notifies the tracker of the new replica location to receive the next data segment it needs and then repeats the process. Our approach has several key benefits over other P2P systems where clients transmit data directly with each other:

A newly arriving peer can still download files even if all other peers have long disconnected
A peer does not need to know about the existence of other peers
A tracker does not need multiple peers in order to enforce tit-for-tat policies.

Wow. You would think they would have at least asked me first before they started hacking at ComWiki. But then I guess that would spoil the fun.

Anyway, I’ve taken ComWiki down for now and put up a “parking page” until I can sort out this mess. When I do get ComWiki back up, I’ll probably have to put up a bunch of security measures, like CAPTCHA-style “type the letters you see in the box” routines, in order to keep out spammers…and Brown University students.

I can understand the theory behind this “experiment.” But I don’t appreciate the ethics, or lack of them, in its execution. I get the impression that these students felt that they were simply testing a “proof of concept,” and that no harm was done by storing their “encrypted data payloads” on wiki pages. But just because something CAN be done doesn’t mean it SHOULD be done. In the social sciences, I doubt if this kind of “experiment” would ever be approved by a human subjects research board.

Sure, running an open wiki means one has to expect some vandalism. I’ve come to expect some “edit wars” when running an open wiki, as people try to use the wiki to advance a particular agenda. Yet I’m still a real believer in the value of open wikis. I like the fact that on an open wiki, one can quickly correct a typo or add an important point to an article. No need to register, no need to squint at a CAPTCHA. Just hit edit and do it. Free and open. Anyone can edit. Yes, that means you have to expect edit wars, but that’s part of the wiki culture. And sometimes you can learn a lot from edit wars. If nothing else, you learn something about those who feel so compelled about their views that they take the time to engage in an edit war.

But to set up a P2P system that exploits this openness takes the “edit wars nuisance” to whole new level, one that just seems wrong to me. I don’t really care if people want to use the internet to share music or movies or warez. Indeed, that’s become part of the culture of the internet, and there’s not much I can do about it. Nor does it seem there is much the RIAA and MPAA can do about it. But to exploit a weakness in MediaWiki (and in particular, a default open installation of MediaWiki) just seems to spit in the face of the Wikimedia Foundation, one of the biggest defenders of openness on the internet.

In my opinion, the real shame in all of this is that when I finally do get comwiki.org back up, it will have to be a more closed wiki, which defeats one of the major advantages of a wiki: the fact that “anyone can edit it.” In fact, at one point I did have comwiki.org more closed, so that only registered users could edit articles. But when I did so, I noticed a significant decrease in edits from users. So I opened it back up, thinking that this might encourage a more open, freely-editable wiki experience. It was just such a freely open wiki environment that these students sought to exploit with their P2P experiment. And now it looks like I’ll have to lock it back up. What a pity.

By the way, even though the Graffiti Networks Projects’s web site claims they used their “removal tool” to delete their “encrypted data payloads” as of April 11, three weeks later I am still getting tons of hits to the wiki from bots. In the time it took me to manually delete a bogus wiki page and its edits, another page or two would pop up. So far this month, the traffic on this site is over 12 gigs. And even after completely removing MediaWiki and putting up a temporary parking page, the domain name is still getting hundreds of hits every day.

More on blogging with touch

Another day, another try with blogging on the iPod Touch. One nice feature of the wordpress iPhone blogging tool is the ability to store local drafts of posts. So while it takes longer to type an entry, one can take a break, save the local draft, and return to writing later.

The onscreen keyboard takes some getting used to, but I’m starting to get the hang of it. Still, I’m not as well versed in the “texting” approach to typing. My thumbs seem to big to type accurately while using both of them. Perhaps I’d be better at this if I had pointier thumbs. I seem to do better using one finger.