Subterfuge! (In the form of a symbolic link.)
mklink /D "Program Files (x86)" "C:\Program Files"
App now compiles. Problem solved.
Thursday, October 7, 2010
Use symbolic links to bridge the x86 / x64 development chasm
My main development machine is x86 but the developers who report to me are all running x64. (I haven't had time to rebuild my machine yet.) We're working on an internal administrative tool developed in Silverlight. We've recently started using a third party component that lives in the "Program Files (x86)" directory, which I don't have. The app won't compile for me. Oh, what to do?!?!
Subterfuge! (In the form of a symbolic link.)
App now compiles. Problem solved.
Subterfuge! (In the form of a symbolic link.)
App now compiles. Problem solved.
Monday, October 4, 2010
Crash gracefully
I'm currently in the thick of managing and building the next release of our proprietary internal line-of-business application which I'll call LOBAPP. It's always interesting to see what problems are discovered once acceptance testing begins.
It's challenging to maintain multiple development and test environments, and the personnel that keep everything running aren't under my control- they are motivated mainly because I'm such a nice guy. As LOBAPP has grown, it has unfortunately developed a few 'uninsulated' dependencies. By uninsulated I mean that the dependencies aren't hidden away behind a facade or a dependency injection container where their absence won't destabilize LOBAPP. Yes, I know, bad design, etc., but this is real life and we are dealing with it incrementally.
The point I want to make, though, is about what happens when certain external dependencies aren't available: LOBAPP displays a really ugly error report to the user then closes. Ugh. The app is dying violently instead of gracefully and with dignity.
Unless the exception is completely unhandled, you should make every attempt to tell the user what is happening. You don't need to display to them all of the gory details- in fact, this could be a major security risk- but the user interface should inform the user that something has gone wrong and that someone is being notified of the problem. Their work has already been interrupted so why aggravate and antagonize them more by abruptly crashing with only a witches' brew of technical mumbo jumbo as a farewell from the dying application?
It's challenging to maintain multiple development and test environments, and the personnel that keep everything running aren't under my control- they are motivated mainly because I'm such a nice guy. As LOBAPP has grown, it has unfortunately developed a few 'uninsulated' dependencies. By uninsulated I mean that the dependencies aren't hidden away behind a facade or a dependency injection container where their absence won't destabilize LOBAPP. Yes, I know, bad design, etc., but this is real life and we are dealing with it incrementally.
The point I want to make, though, is about what happens when certain external dependencies aren't available: LOBAPP displays a really ugly error report to the user then closes. Ugh. The app is dying violently instead of gracefully and with dignity.
Unless the exception is completely unhandled, you should make every attempt to tell the user what is happening. You don't need to display to them all of the gory details- in fact, this could be a major security risk- but the user interface should inform the user that something has gone wrong and that someone is being notified of the problem. Their work has already been interrupted so why aggravate and antagonize them more by abruptly crashing with only a witches' brew of technical mumbo jumbo as a farewell from the dying application?
Subscribe to:
Posts (Atom)
