Developers' Blog

“Dude. Where the heck is MYStuff 2.0? You said, like, months ago that you were working on it.”

While not a literal email from any of the current MYStuff users, it’s a paraphrase of a number of emails as of late. So I thought I’d take a few minutes and give everyone an update.

As I stated over a year ago, MYStuff 2 is a ground-up rewrite that I started in September. It’s more than just re-writing all the existing features and making them better. I’m adding tons of new features, too. From the database backend to the user interface to all the new stuff, MYStuff 2 has been a major undertaking, and some of the features have proven to be quite ambitious. Further, all this new code has to be tested and debugged as well, and since it’s a ground-up rewrite all the program code is new. (Well, not all of it. I was able to re-purpose about 10% of the existing codebase.)

Half of me is jumping up and down with excitement about the new version and is screaming in my left ear, “It’s close enough! Wrap it up! Ship it now! Ship it now!” while the other half of me is screaming in the right ear, “It’s not done! Make sure it’s polished! Don’t cut out any features! Give the users a good value! Make it seamless!”

So I’ve been left with a decision: strip out planned features and release “soon” and dribble out the missing features as I finish them, or stick with the intended feature set for 2.0 and ship “soon-ish”.

After much hand-wringing, I’ve decided to go with the latter option.

And I’ll give you an example of one of the features that’s been slowing me down: barcode scanning.

I’ve had people asking for it since MYStuff 1.0 was in beta. Unfortunately, it’s not a trivial feature to implement. There are other programs out there that have it, but few have pulled it off successfully. I have a little test program running that scans barcodes just fine and dandy, but it’s problematic: It generates false readings about 20% of the time, and that’s assuming you have the lighting good enough to get it to recognize the barcode at all. If the lighting is good and you have everything set just so it doesn’t do a bad job, but do you want a piece of software with a feature that’s just “okay” and doesn’t work well enough for you to use all the time? I didn’t think so. At the same time, if all I gave you for an upgrade was a new paint job and no new features worth mentioning, would you be excited about it? Again, I didn’t think so.

Long story short, I’ve been working hard at making MYStuff 2 (and MYStuff 2 Pro) an upgrade worth getting excited about. Rest assured that it is under very active development at the moment, and that it will be getting into beta “soon” with an expected ship date of “soon-ish”. Have patience. I promise it will be worth the wait.

Sorry, comments are closed for this item.

I’m really happy to have Stock Keeper 1.1 “out of the nest” as it were. I’ve been wanting to do the new features I added in this release pretty much since 1.0 shipped. And since I use Stock Keeper in my daily work as a developer (I have a huge library of icons) the missing features were driving me nuts as I work on MYStuff 2.0. So I devoted about 25% of my time to Stock Keeper while pushing forward on MYStuff 2, and finally got it to a point where I felt it was bug-free and released it into the wild yesterday.

The first thing existing users will notice is that Stock Keeper uses much less memory than the 1.0 version. And when I say “much less memory” I mean “an order of magnitude lower.” Really. How was I able to accomplish this? It’s geeky programmer-speak, but for those of you who care about such things, I switched from automatic garbage collection to manual memory management. This consumed the bulk of my time in getting 1.1 out the door, as it is not a trivial task. Almost everything that was woking perfectly (albeit while consuming gobs of memory) was now broken and had to be tested, fixed, and tested again and again and again. I turned to the excellent beta testing program at which I had used before, and about 50 people participated in testing the beta releases, helping me find at least a dozen memory bugs that I never would have found myself. Let’s just say I spent a lot of time staring at crash logs starting with “EXC_BAD_ACCESS”.

The next thing existing users will notice is a huge increase in speed and performance, especially with large images and large libraries. Before, Stock Keeper was generating images for the browser view on-the-fly, which really bogged down when you have boatloads of high-res images. So with this release, Stock Keeper is now generating 512-pixel thumbnails on import and using those for the browser view. Thanks to the improvements in memory management, this operation was able to be threaded with virtually no impact on import speed.

Sk menubar widget

Finally, the “hallmark feature” for Stock Keeper 1.1 is the menubar widget. I wanted to do this as part of 1.0, but simply didn’t have the time. The worst thing in the world is to have to stop work in your foreground application so you can go digging for a file in your media library. I don’t care if your library is in Stock Keeper, iPhoto, or you manually manage your library in the Finder… switching applications and mentally breaking the flow of work is a horrible drag on productivity. Think about it: you’re working along, and all of a sudden you go, “I need a picture.” (Or audio file, or movie clip, or whatever.) I don’t care if you’re a graphic designer needing a logo, a software developer needing an icon, or someone putting together a presentation on their new nanotechnology startup. After you spend 15 minutes looking for what you needed, you come back to Illustrator or Xcode or Keynote and you go, “Okay, now where was I? What was I going to do next?” Stock Keeper’s menubar widget fixes this problem. Now, you never have to leave your foreground application to get to what you need, quickly, all without breaking your mental flow.

Sure, Apple’s applications have the “Media Browser”, which is fine if 1) your media is in iTunes, iPhoto, or your Movies folder, and 2) you’re using an Apple application. Stock Keeper’s approach is to make your entire media library accessible to every application on your Mac. Period. If your application accepts files via drag-and-drop, you can use Stock Keeper with it.

Finally, a word about Stock Keeper’s library. Some people complain that Stock Keeper has its own library and that it doesn’t just scan a folder full of files. That is the point. Think about it: on your iPad, do you care where your files are located? Do you care what they’re named? When you take a photo with your iPhone, then a few hours later you want to send an MMS message with that photo, do you navigate a file hierarchy to find it? No. You don’t care about where the files are located, nor what they’re named. You want this photo in that application. That is all that matters. With Stock Keeper, the goal is the same: remove you, the user, from the pain and time-consuming hassle of organizing your media files, and just make it easy to find them and use them.

I know, it’s hard to embrace this way of thinking after years of maintaining meticulous file folder hierarchies. But manually organizing media libraries is nothing but a time-consuming chore that gets more painful and more time-consuming the larger the media library gets. With the power of today’s computers, using the computer to search is always faster than manually drilling down through a byzantine maze of file folders. So when you import files into Stock Keeper, just tag them with information that is fresh on your mind: project number, client name, “logo”, “product shot”, et cetera. Use tags that are the same as folders you might create to store the files. Then later, just search. That’s all you have to do, because that’s all you should have to do. Find your file, use it, get on with your life.

This line of thinking has led us to adopt a new tagline for Stock Keeper: Stop organizing. Get working.

Sorry, comments are closed for this item.