Bruji News

As many of you know, the often updated beta versions of the Pedias are our work horses for the programs. That’s where bug fixes are implemented and new features are added for users to test and play with.

The latest feature added (currently only in the English beta version of DVDpedia, will come to all the Pedias and localizations with the next official update) is a new font size option for the source and list view: Extra Large.

We’ve had this request in the past from a couple of users and we did increase the size with the 5.0 release of the programs but that wasn’t quite enough, especially if you’re using the programs on a large screen 1080 TV with high resolution like DVDpedia user Thomas who sent this feature request to us most recently and finally kicked us into action on the problem.

The Full Screen Mode is great for use on larger screens since it automatically adapts to the number of available pixels but for browsing some users prefer the list view which unfortunately becomes too small to read when you’re sitting a few meters away from the screen. But with the Extra Large option, found in the Preferences/Style, that problem is taken care of. Thomas put up a blog post with screenshots to illustrate the change.

If you’d like to try it out for yourself, download the latest DVDpedia beta here and let us know what you think. Apple already provides great accessibility options for users but the Extra Large option might be a useful addition for users with visual impairments too.

We are always pleased to be complemented on our customer support. Often the complement comes with a request for advice on how to handle a large volume of email efficiently, be it at work or home. The trick is an empty inbox. This does not mean that our inbox is empty on the contrary, it normally has a few tens of emails in it yet everything in the inbox is being actively worked on. We don’t move messages to new folders based on priority or who should deal with them as they will inevitable  be forgotten.

The inbox automatically then works as a to do list and by keeping it date ordered the priority of messages decline as they drop down the stack. This puts you on the habit of dealing with messages as they arrive or if not a few days later as you continue to stare at them in the inbox. The corner stone of the philosophy of getting things done – if you can do something right away then get to it.

However, there comes the occasional feature request that would take many hours to complete and you do need a long term to do list for those. For these emails we transpose the request into a Lighthouse ticket that allows us to search it and give it a priority and define the milestone it should be associated with. Lighthouse issues are only reviewed and worked on with major releases to keep us focused on our own road map of features.

There are two weaknesses to this system. First being rare and impossible to reproduce bugs that tend to fall quickly down the stack and against our own advice go into a bugs folder after a few weeks. This is the black hole of support requests. The only reason they go into a folder instead of being deleted is that they have become so hard to fix or inconsequential that I am now waiting for someone else to report  the same issue to cross reference it. Currently the Bugs folder has 28 messages, of which I am pretty sure most are fixed and irrelevant today. For example the oldest, from 1/4/09, is about Pocketpedia1 not displaying a few Korean characters correctly. I like to think it’s fixed, but otherwise will wait for another Korean user to report it with Pocketpedia3.

The second issue is that by waiting to take action on an email before replying to the users means a few users might feel they didn’t get through to you when their request takes several days to complete. This is the recent case of Tom, who emailed us about printing and emailing a selection with a specific template. I immediately got to work on improving the programs. They now have the ability to print a selection instead of having to create a “Collection from Selection” and then use print. In the beta version of Bookpedia you can hold down the option key when clicking on the File menu and you will get a “Print Selection” command instead of the regular print or command-option-P; saving Tom and other users a couple of steps. This feature has been in the beta since two days after Tom wrote, yet the template requires painstaking work in HTML that I haven’t gotten around to. I foolishly wanted to finish the template before writing back to Tom, this was were I failed. Although I view Tom’s email everyday and sometimes work on it (tried to print out the edit window but did not succeed – the final template would have a similar look) he doesn’t know that we are paying attention.

To make sure this never happens all email in your inbox should be read after a couple of hours of being received, if not being worked on immediately they should be flagged and if they reach the point were they been in the inbox for more than a day they should be marked as replied so that users have the peace of mind that you are given their email attention. Even if it’s a simple “We are on it”.

On the days you achieve an empty inbox, then it’s time to celebrate and have a nice meal with loved ones. Now if I can get that template done, I would be at zero inbox Today.

We’ve just released 5.1.4 of the Pedias, both the regular and Mac App Store versions. This update includes some pretty important search plug-in updates, especially for IMDb in DVDpedia and DiscoGS in CDpedia. Bookpedia has gained a new search option with access to Google Books (especially great for non-English book searches).

All those lucky users with Retina displays, rejoice for the Pedias have finally been fully ‘retinafied’! We’ve also changed the color of the stars in the list view – let us know what you think about the gold.

This version also includes some changes to the way the programs handle the Last Seen/Read/Heard/Played History to ensure that all the date information is kept accurately for previously seen/read/heard/played entries.

As always, full release notes can be found on the What’s New? pages for DVDpedia, Bookpedia, CDpedia and Gamepedia.

To get 5.1.4, use the ‘Check for Updates’ command found under the program menu or if you have the MAS version, go into the ‘Updates’ tab of the App Store program.

For a while now (since OS X 10.7) EVP_ calls in OpenSSL have been deprecated. But Wolf Rentzsch’s article has recently stirred developers to look for replacements for these calls in Common Digest. Most developers only use the EVP_ functions in order to validate a Mac App Store receipt hash, as it’s used in the sample code provided by Apple (listing 1-7). It’s easy to replace the 6 calls to EVP with the following Common Digest code:

I always use Objective-C where I can, hence my input string is already concatenated and the SHA1 digest result is converted into a NSData so that I can compare it with stored GUID in the receipt directly. Here is the code in case you need to copy paste:

Hope someone find this useful as a few questions at Stack Overflow are going unanswered due to their more generic phrasing about replacing EVP calls in general. Most of the EVP algorithms are not replaceable but if you are using any of the MD or SHA versions then you can use the above solution.

With the launch of iPhone 5 today we wanted to let you know that the upcoming version of Pocketpedia will support the extra 176 pixels. For data driven apps like Pocketpedia the extra height is a great addition since more of your collections, items, results and details will be visible. Specifically, this means you get to see two more collections and one more row of items when you’re in a collection.

Below are listed a few fantasy books from my personal collection. The first screenshot is for iPhone 4S followed by iPhone 5 screenshot.

iOS makes it easy to cram a lot onto the screen but it was getting crowded when the search was in use. As above, iPhone 4S screenshot followed by iPhone 5.

iPhone 5 brings a little bit more of everything to Pocketpedia. If you are lucky enough to get your hands on an iPhone 5 on launch day, then look forward to the next release of Pocketpedia. (As soon as I am done with some other features currently in development.)

After struggling with their servers and mirrors for years, we finally found one that’s slightly better than the others so Conor has put together a search plug-in for the ofdb.de site. It’s still very much a beta plug-in because the server times out at times and sometimes refuses searches without explanation. But hopefully it’ll still be useful for our German-speaking users and we’ll be able to improve the plug-in with time.

You can download the plug-in on our Extras page.

As with most other search sites, for additional search delimiter options (in this case, choose between DVD or Blu-Ray), select the OFDB site directly in the search window instead of using the ‘All’ search.

Click on the little magnifying glass in the search field to select a search site directly.

Version 5.1.2 is ready for download in the App Store now as well, except for DVDpedia which for some reason was not granted the same expedited review process as the other three programs.

This is the first time we’ve applied for an expedited review since the Amazon API issue is time sensitive (it comes into full effect on August 31st) but Apple only granted the fast track for Bookpedia, CDpedia and Gamepedia. We sent a second request to include DVDpedia since the programs are a suite and many users own more than one of the apps but Apple declined on the grounds that they had already granted expedited reviews to the other programs. Apparently three is the limit you can ask for?!

We apologize to all DVDpedia users who run the App Store version and we’re hoping for a quick review once the program has made it to the front of the queue. In the meantime, you can already sign up for an associate ID and enter that into the Preferences > Amazon Settings as detailed in this post to avoid running into issues with the Amazon search.

Amazon is changing their API access requirements on August 31st. It will be limited to associates only which means a personal associate ID will be required by all users accessing Amazon. For most users no action should be necessary since you should already have your own associate ID linked to your AWS account and the Amazon search will keep working as usual. (The current version of the Pedias, 5.1.2, requires a personal associate ID from all users accessing Amazon.)

For those without a personal associate ID, you need to sign up using the same account that you are using for the access key, i.e. both have to be linked to the same email address.
If you are currently using the default Bruji Associate ID (bruji00-20), please visit the Amazon associate portal and create an associate account with your own email address. Once logged in, take note of your new associate ID (also called a “Tracking ID”) and copy it over to the associate ID field in the Pedia Preferences -> Sites -> Amazon Settings. 

If you receive an error after entering your new ID, please try logging into the Amazon Associate site once with your new credentials and then return to the Amazon Settings window in your Pedia program.

If you are still having issues after signing up with a new email and associate account, get in touch with Amazon directly please. Make sure you include your access key and corresponding associate ID in the message. You do not need to send them your secret key.

You can read more about the recent changes in the Amazon forums, for example here and
here.

We know that the associate program is essential for some of our users and we hope to continue providing access to Amazon’s searches in the future but our main focus in the programs goes towards collaborative and user-friendly sites such as Freebase, Wikipedia and of course the Pedias’ own Doghouse. You can help us make these sites, and in turn the Pedia searches, better by contributing missing items and information. Especially for Doghouse this is easy and quick and makes the Pedias better programs for everyone. If you haven’t signed up for Doghouse yet, check out the help files for more details on how you can contribute.

Today Brent Simmons improved the developer pool of reusable code by posting his code for testing if the value of an object is empty. Most programmers start down this path with NSString where for most purposes an empty string is the same as nil. From there it grows to include NSNull which JSON parser will commonly return, as well as other common objects found in collections such as NSNumber and NSDate and the collections themselves NSDictionary and NSArray.

If you take a look at his code you will notice it’s a function (same as Wil Shipley’s). Because I write almost exclusively Objective-C a function call in my code makes me pause and think. I avoid this by using categories and get to call methods instead of functions. This also avoids the issue of having to write an optimized version of the function to remember to use on NSStrings. With a category you can optimize each individual call for the specific object. So in the hope of improving that shared code pool below is my implementation. Overwhelmingly (97.63% of the time so far) I want to do something with an object when it’s not empty, so my method is reversed. Also isNotEmpty sent to a nil object will result in the correct NO value being returned.

@interface NSString (NSStringExtensions)
- (BOOL)isNotEmpty;
@end

@interface NSNull (NSNullExtensions)
- (BOOL)isNotEmpty;
@end

@interface NSNumber (NSNumberExtensions)
- (BOOL)isNotEmpty;
@end

@interface NSDate (NSDateExtensions)
- (BOOL)isNotEmpty;
@end

@interface NSArray (NSArrayExtensions)
- (BOOL)isNotEmpty;
@end

@interface NSDictionary (NSDictionaryExtensions)
- (BOOL)isNotEmpty;
@end


@implementation NSString (NSStringExtensions)
- (BOOL)isNotEmpty {
	if ([self length] > 0)
		return YES;
	return NO;
}
@end

@implementation NSNull (NSNullExtensions)
- (BOOL)isNotEmpty {
	return NO;
}
@end

@implementation NSNumber (NSNumberExtensions)
- (BOOL)isNotEmpty {
	if ([self integerValue] == 0)
		return NO;
	return YES;
}
@end

@implementation NSDate (NSDateExtensions)
- (BOOL)isNotEmpty {
	if (self != nil)
		return YES;
	return NO;
}
@end

@implementation NSArray (NSArrayExtensions)
- (BOOL)isNotEmpty {
	if ([self count])
		return YES;
	return NO;
}
@end

@implementation NSDictionary (NSDictionaryExtensions)
- (BOOL)isNotEmpty {
	if ([self count])
		return YES;
	return NO;
}
@end

I wrote these categories in 2003 and haven’t thought about them since then. I have 674 total calls to these functions in my code (how I know the exact percentage on how often I use it). Since I recently discovered the easy to use BNRTimeBlock for testing performance I ran the three implementation 10 million times and came up with the following averages after 10 runs:

Time for == King Kong
Conor's isNotEmpty:       0.165795
Brent's RSStringIsEmpty:  0.182188
Wil's isEmpty:            0.860662

Time for == (null)
Conor's isNotEmpty:       0.045048
Brent's RSStringIsEmpty:  0.039325
Wil's isEmpty:            0.041882

Time for == @""
Conor's isNotEmpty:       0.167456
Brent's RSStringIsEmpty:  0.186889
Wil's isEmpty:            0.329623

Average:                  0.224318

This shows that at .000000022 seconds per call you should be using these easy to read and maintain functions and/or methods all over your Objective-C code. Brent’s longer RSIsEmpty performs similar to Wil’s function as it includes the necessary call to respondsToSelector:. At these speeds I think the RSStringIsEmpty optimization is unnecessary except in the heaviest of loops.

I do believe my version should be renamed isSet or isFull to avoid using “not” in the method name; but although one learns a lot in 10 years, I also have been using isNotEmpty for 10 years.

A new version of Pocketpedia is out! We were very happy with the initial release of Pocketpedia and got wonderful responses from you all – thank you! – but as it happens, a few bugs slipped past us in the first version so 3.0.1 addresses mostly those little bugs and annoyances.

Some users with older hardware (iPad 1, iPhone 3GS, older iPod touch) and large collections experienced some trouble synching and opening collections. Since most of our testers have newer devices we never came across these problems during the beta phase. But thanks to the fixes we put into place for these older devices now, Pocketpedia has become faster for ALL users. You’ll notice this especially if you have a large database with more than 10,000 entries but everyone is going to benefit from the quicker response of the program for sorting and displaying entries.

We’ve also fiddled with the UI to include the track number for albums on the iPhone version as well as track artist (if available). On the iPad version we’ve added scrolling to the ‘More’ window which is essential for those users with a lot of information in all of their fields.

3.0.1 also brings a moderating option to all entries found via Doghouse searches. You don’t have to be a moderator to edit an entry directly through Pocketpedia now, just press the ‘Edit in Doghouse’ link at the bottom of any search result and fix it before you add the entry. Now it’s correct for you and everyone else using Doghouse. (You’ll have to sign up for a user account in Doghouse before you can edit an entry, if you’re a moderator already use that same username/password combo.)

This is all about sharing and being nice to each other because we like that sort of thing here at Bruji and we’re pretty sure you all do too judging from the wonderful response we’ve had from all those users who got involved with Doghouse moderation and have helped us (and you) by fixing and improving entries. Thank you!

For a full list of the release notes, please check out Pocketpedia’s What’s New? page.