MacHash

I’ve always been a fan of MacHash, a service that aggregates RSS posts from Apple-related websites. From January 2012:

I’ve been a huge fan of MacHash since I started using the service last year. With a straightforward web interface that aggregates the latest Apple headlines from websites like ours, MacRumors, TUAW, Macgasm, AppStorm, iMore and many others and an iOS client that offers more customization options alongside an in-app browser, MacHash has become my go-to place to stay on the top of the latest Apple news and commentary from the community.

Released yesterday, MacHash 4.0 brings a new, cleaner interface, iCloud syncing for settings, and improved sharing.

Sites are now available in a Facebook-like sidebar that you can access by swiping horizontally on screen or tapping the list button in the top left corner of the title bar; you can pull to refresh this view, or “star” sites that you want to display in the Favorites tab. Starring a site will give you quicker access to its standalone stream of articles, which, as in previous versions of the app, is fetched via RSS: if a site doesn’t have a full-text RSS feed, it will be truncated in MacHash (just like any other RSS reader).

MacHash already had a filtering option to “mute” sites that you weren’t interested in seeing in the main stream, and in this new version filters should sync alongside sync across various instances of MacHash (say on the iPhone and iPad) through iCloud. I say “should” because, in practice, my settings are being constantly reset to default state every time I start the iPad app. I have no idea whether this bug is due to MacHash itself or iCloud, but I wouldn’t be surprised to know the latter is the culprit.

My favorite new feature of MacHash 4.0 is the tap & hold menu for sharing. You can now tap & hold any article to bring up a Copy & Paste-like menu with options to view the full website, a mobilized version, share the link on Twitter, or open more sharing actions. Because the middle button is configurable, and because auto-sharing can be activated, I can now send articles to Evernote with just two taps without having to confirm the clipping action every time. It would be nice to be able to send links to specific Drafts actions, though I understand the added complexity of specifying a Drafts URLs to send links to.

MacHash 4.0 comes with other speed and stability improvements (though the app still crashed for me once) and an overall more polished interface. MacHash continues to be my daily destination to get a quick overview of a day’s Apple news, and the app is free on the App Store (with In-App Purchase to hide ads).

I recently wrote up an interview here on MacStories and although I was able to get it posted, I almost had to scrap the entire article because QuickTime crashed and I lost the recording of the interview.

I say it was a crash but to this day I still don’t know what happened. I had recorded my conversation with Ken Case on my Mac using QuickTime X player. The process to record audio with QuickTime is simple enough and it has never failed me in the past. After we got off the phone I immediately hit play on the recording to make sure the sound levels were adequate – first mistake. I should have hit Save then checked the sound levels. Not wanting to listen to the interview on the speakers in my display I paused the interview and left the room to track down my headphones. When I came back the audio recording was gone. The QuickTime application was still running but the recording window was gone.

My stomach dropped.

I frantically started tabbing through all of my open applications to see if anything else had closed, but they were all running. I checked all my desktop spaces and minimized windows but found nothing; it was gone and I hadn’t clicked save.

At this point, I hit up Viticci and started cussing like sailor at my own stupidity. He later told me that when I wrote up this recovery tutorial, I could post exactly what was said in our conversation. However it was so explicit that I decided not to.

Anyway, I started crawling the web for any information I could find on QuickTime temp file locations, Viticci and Cody contributed some suggestions as well.

Here are some of the potential locations I checked via web results:

$TMPDIR/com.apple.QuickTimePlayerX 

~/Library/Caches/QuickTime/ 

/tmp /var/folders/ 

/tmp/501/TemporaryItems/ 

/Library/Application Support/ 

etc... 

Unfortunately, none of those directories turned up anything useful. As last attempt I decided to run some 3rd party recovery software.

I did a quick Google search and downloaded a demo of Disk Drill for Mac. After running it for about an hour, it found a lot of deleted files, but not my QuickTime recording. The problem was I still didn’t even know what format it would be in or what filename it might have.

I soon remembered that I had a copy Data Rescue 3 so I immediately ran it. Data Rescue 3 ran for several hours, well in to the night, and found a lot more than the demo of Disk Drill found. However I was in the same situation, I had a lot of files but none of the audio recordings it found was the interview with Ken Case and I still had no idea where I should be looking.

So I decided I would start another recording in QuickTime, stop it, then check all of those temp location suggestions I had found. Unfortunately I didn’t find anything useful doing that.

Then by either divine intervention or a stroke of genius I opened a Terminal window and dragged the little QuickTime icon from the recording window in to the Terminal window and dropped it.

Sure enough, it printed out the location and file name of that test recording.

It all became clear, I can’t believe I hadn’t thought of it sooner. Now that QuickTime is sandboxed I needed to look in QuickTime’s container for the temp recording. I finally had all of the information I needed:

In the directory:

/Users/Don/Library/Containers/com.apple.QuickTimePlayerX/Data/Library/Autosave Information 

In a bundle called:

Unsaved QuickTime Player Document.qtpxcomposition 

I simply had to right click on the .qtpxcompostion file and inside I found the .m4a audio recording of my QuickTime test.

Now this is where the magic ends; this next part, the actual recovery of the file was thanks to Time Machine doing hourly updates. I simply had to open the Quicktime Autosave Information directory in Time Machine to the time right after I ended the call with Ken and there was my recording in its sandboxed temp directory.

I know this probably seems like common sense – just open up Time Machine and recover the file. However if you don’t know the filename or the directory it was located in your backup is not going to be much use. Thus, I felt this was worth sharing in case you are ever in the situation of having to retrieve a lost QuickTime recording.

Now you know where to look.

Developed by Steve Streza and released during last night’s App.net hackathon, Project Amy integrates App.net private messaging with the Messages application for OS X. A first version of Project Amy has been made available for download on App.net itself.

Project Amy is a clever experiment that showcases the App.net API and Apple’s IMServicePlugin.framework: using only public APIs and no proxies (unlike Steve’s first App.net project), Project Amy adds App.net as a native account in Messages, allowing you to have private conversations with other App.net users inside Messages. Once installed, you can simply login with your App.net credentials to have the account listed alongside AIM in the bottom left corner of Messages; choose Window > Buddies (or hit CMD+1) to show a list of users that you can send private messages to (they will be displayed as online with their full names rather than usernames).

Because it uses official APIs, messages sent through Project Amy also show up on App.net’s online messaging interface, Omega. In my tests, messaging with one or multiple users in Messages correctly mirrored the conversations to Omega, where they were updated in real-time without needing to refresh the webpage. I was even able to drag images into the conversation in Messages, and, while they didn’t show up as attachments on my end, they did appear as inline uploads on Omega and inside the recipient’s Messages application. Obviously, file uploads were handled by App.net’s File API as well.

Project Amy is a little buggy in this first version, but certainly promising. Aside from using an official OS X framework that few developers seem to know about, it shows the potential of the App.net API as a versatile solution capable of delivering more than just Twitter clones at this point.

Check out Project Amy here.