(Entries tagged as news)

State of the Company – Now Closed

nospam@example.com (Kevin Locke) — Thu, 17 Nov 2011 11:03:00 -0700

I am sorry to inform you that Digital Engine Software is no more. Priorities change, new opportunities arise, and we have decided to take advantage of them. Peter landed an amazing job working for Riot Games in Southern California, Mike is pursuing his Masters in Economics at the University of Vermont, and I am currently finishing the remaining obligations for Digital Engine Software with exciting opportunities on the horizon.

It has been a privilege working with Mike and Peter, and with all of our clients and business partners. It has also been a great enjoyment, both during work and engaging with all of you outside of work, particularly at our LAN events. I wish Mike and Peter the best of luck in their pursuits and I look forward to seeing you all wherever our paths may cross.

I will continue to be reachable through all of the usual methods for the foreseeable future to answer any questions and address any issues (both Digital Engine-related and otherwise). It has been a great run and I expect a lot more greatness from everyone involved in the years to come. Farewell Digital Engine Software.

State of the Company – Spring Time Happy Days

nospam@example.com (Mike Archer) — Tue, 22 Mar 2011 14:17:29 -0600

I've been slacking on state of the company updates because I'm a slacker.

What We Have Been Up To:

Peter has been working really hard on the heat mapping software we are making for NWB Sensors. The software can now record at 1 FPS (I'm told it will go up to 7 FPS if Sandra Bullock and Keaneu Reeves are using it). The software also keeps track of GPS coordinates which are some of the best coordinates to keep track of. If you need a top-of-the-line heat imaging setup using Flir Tau or Photon cameras and rad software from Digital Engine give Paul or any of the other NWB Sensors guys a call at 406.579.0510.

I have been putting together a web site for NWB Sensors which will be up as soon as they decide on a sufficiently cool URL. I have also been “helping” out at the social media user's group (SMUG) classes that the TechRanch has been hosting. We just finished with the beginner sessions so going forward there will be a class about once a month on various social media topics. Laura Rhodes has been doing a wonderful job putting these on so if you're interested drop by, you can find a schedule on the TechRanch website. Finally I am finishing up an idea we were tossing around the office – a Facebook application to trade and price your friends on a stock market. Brain Trolley Trader is in beta right now so come and try it out!

Kevin has been working on additions to the OpenWrt router firmware to enable VPN with IPsec connections. The functionality is all there and working as of a couple of days ago, woohoo Kevin! Kevin is now working on making the setup process a little more user friendly. The patches have been submitted to the OpenWrt project so be on the lookout for the updates to be committed in the near future. We have also been tossing around the idea of offering pre-loaded and configured routers for sale. I will definitely make it known if or when that happens.

We have also held two LAN parties since my last update. We have had around 30 people at each which has been amazing! Unfortunately we are really pushing the limits of the library’s electrical system so if we get too many more people we may have to start looking for a new venue. If anyone has any good and cheap suggestions please drop me an e-mail.

That is all for this month, happy Spring!

LAN Party

nospam@example.com (Mike Archer) — Sat, 29 Jan 2011 20:45:44 -0700

Digital Engine Software is proud to host our fourth LAN party of the year on February 5th from 1:00 p.m. to 10:00 p.m. at the Bozeman Public Library. We'll be playing some StarCraft 2, UT 2004, Quake 3, Team Fortress 2, Counter-Strike: Source, Left4Dead 2 and anything else that happens to strike our fancy. Drinks and snacks will be provided and we'll take pizza orders come dinner time. Admission is free and everyone is welcome. For more information visit:

Our website: http://www.digitalenginesoftware.com/lan/
Our Facebook group: http://www.facebook.com/#!/group.php?gid=102202183163875
Or e-mail: marcher@digitalenginesoftware.com

SotC November Style.

nospam@example.com (Mike Archer) — Wed, 03 Nov 2010 15:34:10 -0600

Another super exciting month for us here at Digital Engine Software. Ok, maybe not super exciting but marginally above average! Let’s see…beginning of the month we had our third LAN party of the year. It was a lot of fun, I got to play grownup Lego’s quite a bit (Minecraft) and Peter laughed all the way to the bank whooping it up on LoL (League of Legends). We also attended the Tech Ranch networking party at the 317 Pub. Having been to a whole two networking events with the Tech Ranch I can authoritatively state that they are all awesome. You get to meet some really interesting people, talk about some cool stuff and usually there is free food/drink. Which brings me to my starving entrepreneur tip of the day: There are a surprisingly large number of events in this town that just give away food. A lot of the time it is even good food (even assuming you haven’t eaten Ramen for the last 12 meals). Attend these events. You will meet some people (sometimes cool) and you may be able to sneak out some food. Mix your stolen food with Ramen the next day and you can eat like a king! I call it Fancy Ramen ™.

As far as actual work goes just some more of the same. I have been finalizing some of the web projects I have been working on and trying to develop a solid marketing plan for whenever Peter thinks of his name for the Git GUI project. Peter, ironically, has been working on the Git GUI project and Kevin has been working on his office management software along with a nearly fully-functional demo for a secret project we’ll hopefully be able to discuss sometime soon. Kevin has also submitted his patch to the Duplicity project to be merged with the main development branch so theoretically Duplicity will have a Window’s port (and a lot of bug fixes) available soon. A social media users group is in the works at the Tech Ranch. The first meeting should take place before the end of the year. Keep an eye on our blog or the Tech Ranch calendar for the official date. More next month!

The Curious Case of OBJC_DISABLE_GC in OCUnit tests

nospam@example.com (Peter Nix) — Wed, 20 Oct 2010 15:07:10 -0600

When I first started writing unit tests using the OCUnit testing framework, my unit tests were failing when I ran them, but when I set break points to debug them they started passing. It turned out, after much swearing and frustration, that there were errors being spewed to the standard error file handle. This error looked a little something like this:

GC: forcing GC OFF because OBJC_DISABLE_GC is set

Normally this wouldn't be a big deal, and my application at it core relies on reading messages from both standard out and standard error as part of communicating with an NSTask object. I'm using RegexKit in order to parse the output into a meaningful set of data, and that's where the problem manifests itself. Since this error is coming from the unit testing harness and my regex's are not expecting this error message in the standard error file handle, this led to failed unit tests.

Naturally, I immediately started googling for the answer, and read posts every from CocoaBuilder to StackOverflow, and everyone suggested to change the Garbage Collection behavior from Unsupported to either Supported or Required. Easy enough, and so I did, in these steps:

Double click on the project at the top of the project browser

Find the garbage collection setting

Change the value to either supported or required (supported in my case, as I'm actually using the retain count method)

Done and done...or so I thought. I ran my unit test again, and I continued to get the same error message. I switched the garbage collection setting to the other value (required in my case) and still I continued to get the error message.

So, I went back on the hunt for the answer and the same answer came up again and again, "Switch your garbage collection setting", which was not solving my problem. In the end, I did end up solving my problem and the answer is indeed "switch your garbage collection setting" but one thing no one told me, and I'm here to tell everyone having the same problem as I was having, is exactly WHICH garbage collection setting to change.

The secret it turns out is that the Unit Test Bundle has its own garbage collection setting, and its not inherited from the project level setting.

So, instead of double click on the project, double click HERE:

and change that garbage collection setting to either Supported or Required, per normal:

The instant I changed the unit test bundle's setting, the errors in standard out that I'm not expecting are gone.

The proper care and feeding of NSWindow objects display as a sheet

nospam@example.com (Peter Nix) — Fri, 15 Oct 2010 10:12:55 -0600

The Too Long, Didn't Read version:

Displaying a NSWindow, one that's lazily loaded from its own nib file, as a sheet doesn't have a any method for notifying observers that its about to be displayed, and therefore its difficult to reset the sheet UI on the second and later displays. Therefore, use this NSWindow subclass as your controller to re-set the UI right before the window will display as a sheet.

---

The long version wherein I lead the reader, step by step, through the problem and the solution to lazily-loaded, re-usable NSWindow objects displayed as a sheet:

In many examples of using custom NSWindow object displays as a sheet in a Cocoa application, found both on the web and in print, the author has placed the NSWindow object that will be used as a sheet inside in the .nib file of the window that the sheet will be attached to. This works fine if the sheet is guaranteed to be displayed to the user. On the other hand if you can't guarantee that the user will see the sheet, as you frequently cannot with a sheet, including the sheet in the nib file violates the guideline of "For a window or menu that is used only occasionally, store it in a separate nib file. By storing it in a separate nib file, you load the resource into memory only if it is actually used."

As a tangential discussion before diving into the main point, everytime you load a resource from a nib file all objects contained within the file, with the exception of the 'File's Owner', 'First Responder' and 'Application' objects since these are proxy objects, are unarchived and have their connections (both IBAction and IBOutlets) set up. Therefore, even if you don't use a particular resource contained with in the nib, such as in the case where the sheet is never presented to the user, the program has wasted both computation time and memory loading all the unused objects anyway. The more you can get away with not loading from your nib files, the faster your program will launch and the more memory efficient it will be while running. As such, the best way to handle NSWindow objects that may not be displayed to the user is to move them into their own nib file and only load them from the nib file when, and if, they need to be displayed to the user. For a more complete run down of the ins and outs of nib files please read through Apple's Resource Programming Guide.

So, in the case of a custom sheet, since we don't want to waste processing time and system memory until we need it, the best way to handle this is as follows. I'm purposefully omitting the corresponding .h files for this example since they're rather trivial. The only important part is that both MainWindowController and SheetController are both subclasses of NSWindowController:

MainWindowController.m

- (IBAction)displaySheet:(id)sender {
SheetController* sheetController = [[SheetController alloc] init];
[NSApp beginSheet:[sheetController window]
modalForWindow:[self window]
modalDelegate:self
didEndSelector:@selector(sheetDidEnd:returnCode:contextInfo:)
contextInfo:sheetController];
}

- (void)sheetDidEnd:(NSAlert*)alert returnCode:(NSInteger)returnCode
contextInfo:(void*)contextInfo {
// do something with the user input to the sheet here
SheetController* sheetController = contextInfo;
[sheetController release];
}

SheetController.m

- (id)init {
self = [super initWithWindowNibName:@"someSheet"];
return self;
}

- (IBAction)dimissSheet:(id)sender {
[NSApp endSheet:[self window] returnCode:NSOKButton];
[[self window] orderOut:self];
}

This is just sample code, with just enough to show how displaying a sheet would work. Obviously it will work, but there's a subtle error in here that's easy to miss for new programmers. Everytime [[SheetController alloc] init] is called in the main window controller, the contents of the nib containing the sheet is opened, unpacked, and hydrated. Even though we're properly lazily loading the objects in the nib file, we've committed another error. We're now incurring the nib loading everytime the sheet displays. It would be better if we could unpack this information from the nib only once, and reuse the sheet NSWindow object every time and therefore we only incur the cost of instantiation the first time a user needs the sheet.

Easy enough, in theory (you'll see why this turns out to be harder than it looks in a second), and with that change it looks something like this:

MainWindowController.h

@interface MainWindowController : NSWindowController {
SheetController* sheetController;
}
...
@end

MainWindowController.m

- (IBAction)displaySheet:(id)sender {
if (sheetController == nil) {
sheetController = [[SheetController alloc] init];
}
[NSApp beginSheet:[sheetController window]
modalForWindow:[self window]
modalDelegate:self
didEndSelector:@selector(sheetDidEnd:returnCode:contextInfo:)
contextInfo:sheetController];
}

- (void)sheetDidEnd:(NSAlert*)alert returnCode:(NSInteger)returnCode
contextInfo:(void*)contextInfo {
// do something with the user input to the sheet here
}

SheetController.m

Now, we're creating the sheet a single time, which fixes the problem of loading the resources from the nib every time you display the sheet, but introduces a new problem (one that's hard to see from the example code without running a full application that implements this code). The problem is that because we're using the exact same NSWindow object over and over, if the sheet contains UI elements that the user can change (NSTextField, NSSlider, NSPopupButton, etc.) then those UI elements will be displayed as the user left them from the first time they interacted with the sheet. Sometimes this is the desired behavior, but in the event that its not, you have a problem.

Normally in the case where you want to re-use a window over and over and want to reset its UI every time its presented to the user, you can override the - (IBAction)showWindow:(id)sender method in the NSWindowController. Unfortunately for a NSWindow displayed as a sheet, the showWindow: method is not invoked by [NSApp beginSheet:...] and therefore your NSWindowController subclass isn't notified that the window is about to be displayed. This lack of notification just prior to the window showing on screen as a sheet is the heart of the problem. As a quick rundown of the methods you might think work but don't:

When the sheet is loaded, it invokes windowDidLoad: on its controller, but this only happens the first time its loaded from the nib and is never invoked again (since we're re-using the sheet and only loading it from the nib a single time), so it can't be used to reset the UI for the second display of the sheet.
The NSWindow that will have a sheet attached to it notifies its delegate that its about to display a sheet through the willDisplaySheet:(NSNotification*) method, but the notification contains a nil userInfo dictionary so it doesn't contain a pointer to the sheet its about to display
You might think that when a window's delegate receives a willDisplaySheet: notification the delegate could invoke the attachedSheet method on the window that's about to display a sheet. Unfortunately, the NSWindow's attachedSheet method returns nil at this point since the sheet isn't yet attached.
You could override [controller window] method on the NSWindowController for the sheet in order to reset the UI before returning the window object. This partially works since you'll reset the UI as part of the [NSApp beginSheet:[sheetController window] ...] invocation, but it also means you lose access to what the user did on the other side since dismissing the sheet through [NSApp endSheet:[self window] ...] also resets the UI.

Since the last bullet point is half usable, it turns out that with the right tweaks, we can avoid restting the UI while dismissing the sheet. I now present the DESSheetController, which you can use in your own Xcode project to fix this issue:

DESSheetController.h

//
// DESSheetController.m
//
// Created by Peter Nix (pnix@digitalenginesoftware.com)
//

#import <Cocoa/Cocoa.h>

/*!
@class DESSheetController
@abstract An abstract super class to use instead of NSWindowController to
assist in using sheets.
@discussion Using an NSWindow controller loaded from its own nib as a sheet
(a distinct nib from the window its going to attach to) doesn't have a good
notification to its NSWindowController or delegate that its about to display.
Therefore, it is very difficult to reset the UI to a default state when re-displaying
the sheet to the user. This class provides the necessary overrides and callbacks
to help reset the UI to a default state when reusing the same NSWindow
object as a sheet.
@updated 2010-10-13
*/
@interface DESSheetController : NSWindowController {

}

/*!
@abstract dismissSheet: provides a way of dismissing the sheet without losing
the information contained in the UI elements the user can interact with.
@discussion Based on the override of the window method (see the implementation
file) if you call [self window] as part of the call to dismiss the sheet, you will
reset the UI on the sheet before you query for this information in your modal
delegate's selector callback. Therefore, the contract for overriding this class
for a custom sheet controller is call this method when dismissing the sheet
in order to preserve the UI state.
@param returnCode the integer indicating the status that the sheet ended with.
This parameter will be passed onto NSApp when sending the sheet out and in
turn gets passed to the modal delegate's callback selector.
*/
- (void)dismissSheet:(NSInteger)returnCode;

/*!
@abstract This is the method that needs to be overriden in your custom subclass
in order to reset the UI when redisplaying the sheet.
@discussion This method is invoked in the middle of returning the window from
your controller to the NSApp instance to begin a sheet. Therefore this method
is invoked at (literally) the last possible moment, meaning that all the UI for
the sheet has been properly hydrated from the nib, and is just about to be
displayed as a sheet. This method is empty in this class, and is designed to be
overridden by a custom subclass in order to perform any UI clean up in order
to get the sheet into a reset/clean state for display to the user.
*/
- (void)hydrateView;

@end

DESSheetController.m

#import "DESSheetController.h"

@implementation DESSheetController

#pragma mark inherited methods

- (NSWindow*)window {
NSWindow* window = [super window];
[self hydrateView];
return window;
}

#pragma mark private methods

- (void)hydrateView {
// do nothing by design, overridden by sub-classes
}

- (void)dismissSheet:(NSInteger)returnCode {
// note the use of super instead of self in order to bypass the sheet reset code
// via the hydrateView method
[NSApp endSheet:[super window] returnCode:returnCode];
[[super window] orderOut:self];
}

@end

So, now for a bit of explanation. The point is to use this class as your sheet controller's superclass instead of NSWindowController. By subclassing DESSheetController, all you have to do is implement -(void)hydrateView within your subclass and use that method to re-initialize the UI everytime the sheet is displayed. On the outgoing side, the contract is to invoke the - (void)dismissSheet:(NSInteger)returnCode method instead of invoking [NSApp endSheet:] directly in your subclass. The dismissSheet: method calls [super window] instead of [self window] and therefore avoids resetting the UI before the modal delegate can query the sheet for information.

Now, you can safely re-use a single NSWindow as a custom sheet for user interaction over and over again, and still stick to lazy initialization and avoid multiple nib loading.

State of the Company October Edition

nospam@example.com (Mike Archer) — Mon, 04 Oct 2010 14:35:14 -0600

September is gone already, that was crazy fast. Digital Engine Software has been busy but nothing too much has changed since last month. Kevin has been teetering on the edge of insanity as he works on trying to automate some interactions with the state websites. I’m tempted to try and push him over because I’ve never seen a ginger angry before but as it is I will most likely be the first against the wall when the Kevin revolution comes so I’m not going to push my luck.

In other news we were asked to do an evaluation of some inventory management software. Peter took charge of that and it turns out, unfortunately, that there is only one semi-decent piece of open source inventory management software (OpenBravo in case anyone is curious). OpenBravo is even a corporate sponsored half open source half premium product that has received almost $20M in venture funding. As we were evaluating off-the-shelf software options we also ran the numbers on our own development. Once you begin digging into the nitty gritty of the software features you begin to realize how incredibly immense these programs are. Our conservative estimate for development time was nearly 3,000 hours. There are admittedly some very complex and gigantic open source projects but inventory management doesn’t have nearly the sexy cachet of say a new encryption algorithm implementation. Ultimately we discovered that this is definitely an area that is better served by closed source proprietary solutions. Peter is also still hard at work on his GIT GUI project. I’m pushing him to get it done by December 7^th because it’s possible that he may become a permanent resident of the World of Warcraft once Cataclysm comes out.

As I blogged earlier I spent most of September preparing for and actually doing the Orbit seminars. So much fun! We have another LAN party coming up this Saturday (October 9^th) at the library. Our reserved seat charity this time around is the Human Resource Development Council – donate and help keep people warm and fed this winter. I’ve also been attending some Young Professionals Group meetings. These are really cool get-togethers put on once a month by the Chamber of Commerce (you don’t have to be a member of the Chamber to join YPG) where younger individuals (<35or so) meet to network, learn stuff, volunteer and have fun. Last month we had three business people from the community come in and answer our questions and I’ve heard that this month is Vegas night. There are four sub-committees within YPG that you can join: Community service, education, social and mentoring and the groups alternate hosting the meeting or activity each month. If you’re a younger professional and you enjoy groups you should totally join (bonus points if you’re not a financial adviser or a chiropractor).

Orbit Presentations

nospam@example.com (Mike Archer) — Mon, 27 Sep 2010 14:48:33 -0600

Last week Gary Bloomer from the Tech Ranch, Shelby Nordhagen of NetNewMarketin g and I made a trip up to Bigfork and Frenchtown to give our presentations on e-marketing. It was so much fun! The audience members were awesome! They were really engaged and often contributed as much or more than Shelby and I did. I should warn, however, that these seminars are pretty basic. We have a lot of great information but anyone involved in the industry will likely know 95% of the stuff we cover. However, if anyone reading this blog is interested in an introductory course on how to set up a WordPress site, search engine optimization, Google Analytics, AdWords, social networking or e-mail marketing should plan to attend one of our future seminars! They’re a lot of fun, you can make fun of Gary and he can’t do a thing about it plus lunch is included. Keep an eye on this blog or the official Orbit Montana site for dates and places starting again in the beginning of 2011.

State of Company

nospam@example.com (Mike Archer) — Fri, 03 Sep 2010 12:59:41 -0600

August is officially over (according to Julius Caesar) so time again for another State of the Company. The big news this month is that we have expanded! An incredible office opened up on the third floor and since things were getting a little cramped up in the tower we decided to get it. Half of the new office is for Peter and half has been converted into an employee lounge of sorts. It's pretty swanky. Unfortunately I keep forgetting to bring my camera into the office so no pictures yet but as soon as I remember I'll update this post.

For any budding entrepreneurs out there considering whether to get an office or work out of a garage, definitely get the office. Yep it's a little extra money a month (when we were first looking prices ranged from ~$275-$600 per month for single offices) but the ability to go somewhere outside of your house and focus on your work is priceless.

On the work front Kevin is still working diligently on his office management project. In fact, due to a shortage of decent backup programs Kevin spent part of August porting Duplicity from Linux to Windows! Woohoo Kevin! While we are waiting on some items to be sorted out with the heat mapping project Peter has been working on a GUI for Git which sounds like it is coming along nicely although I haven't seen it yet so it could be a lie just like the cake. Finally I have been finishing up the real estate search plug-in for Joomanager, making modifications to the Huffing For Stuffing site and working on my Orbit presentation. We are going to have a ton of great information at our Orbit presentations (the first two will be in Big Fork on the 22nd and Frenchtown on the 23rd) so come by if you can make it. Also the next LAN party will be on Saturday October 9th at the Library. See you next month!