The Code Jedi Development, Perspectives, and Ramblings-on

How Not to Transition an Acquired Company’s Site

13. March 2015 04:00 by hugodahl in Opinion

In my current workplace, we use AccuRev as the source/version control system. I’ve recently found out that the company who is/was behind the product, presumably called “AccuRev Inc.” based on the “About” dialog of the product, was acquired by Borland, who was acquired by Micro Focus a while back (specifically 2009 for those so inclined to the details). Yes, the COBOL company.


When what you're listening to matters...

9. January 2015 04:00 by hugodahl in Tools and Utilties

About a week or two ago, I saw a discussion on Hacker News about How Surround Sound for Headphones Works. Linked within the article, as well as the source item's page, was a free tool for OSX called "Hajo's Headphone Enhancer". I downloaded and installed it, without giving it much more thought. However, I was working on my Macbook today, and thought I'd pop in some headphones and see just what kind of difference, if any, I would notice.

As tersely as I can put it - WOW! Alternating between different settings, on songs I've been listening to for ages was absolutely stunning. Rather than feeling like I was listening to a music album, it felts as if I were a fly in the studio during the recording sessions.

I used it for all of 45 seconds when I decided that this was absolutely worth the 10$ to register the software, and avoid any nagware screen after the free trial period. You can keep running it, as the author says on the page that it is free, however, as with all effective nagware, a prompt/reminder to register will appear every so often - every 30 minutes if I am remembering correctly.

As you can see by the options for audio/ambiance styles, it's not as elaborate a configuration as Boom 2, which did sound quite nice when I tested it with the built-in speakers (I did not try "Boom 2" with headphones before my trial period lapsed). However, the counter argument of "it's not as elaborate a configuration" makes it quite simple to pick a setting, give it the thumbs up, and rock out! But maybe that's just the knob fiddler in me trying to set different things within Boom 2 in a "let's see what happens now" attitude!

tl;dr: If you run OSX and use headphones, get "Hajo's Headphone Enhancer" and pay the unquestionably cheap but totally worth it 10$ for registration!

Using the CodeRush Test Runner with Platform Specific Libraries

13. August 2012 08:57 by hugodahl in Unit Testing, Tips and Tricks

An issue appeared today for a co-worker, who was getting failing unit tests on one of our components, when the tests were being run from the CodeRush Test Runner. By the way, have I mentioned my love for CodeRush + Refactor? No? Well I do, to the point where I have a work license as well as a personal, paid for out of my own pocket, license! Unfortunately, he was getting an error whenever he ran the tests against the library, which we know has been working without issue for years. Not only that, but when he checked the build history on our build box, there was no report of failing tests. That reminds me, you ARE running your unit test suite in your Continuous Integration environment, right? Right?


He then mentioned the error he was getting, which is a BadImageFormatException getting thrown. That immediately connected two dots in my head, and I verified my suspicions. I was right, as it turns out, our image processing library is compiled against a .Net wrapper against a platform specific DLL targeting the x64 platform. It turns out, his CodeRush test runner was running in 32 bit mode. The fix was a simple one, where he simply had to tell CodeRush to run in x64 mode if the target platform was AnyCPU. The option is fairly obvious, if you know where to look.


Coderush Test RunnerIn order to enable it, bring up the CodeRush options (DevExpress menu –> Options or Ctrl+Alt+Shift+O for the keyboard inclined), expand the "Unit Testing" option folder on the left, and select the "Test Runner" sub-item. In the main window, about half way down, you will see a checkbox marked as "Execute in x64 mode if active configuration is AnyCPU". Check that, click Ok, and you’re set!


It is important to note that the only time this will cause an issue, if you have a library that is explicitly targeting a specific platform. If all of your libraries are targeting AnyCPU, you will not run into a problem, though you probably want to run your tests to where you are targeting both platforms, in case you notice any discrepancies, run into overflows, type incompatibilities, etc. In our case, we have an C++ image processing library that was compiled and linked to target the x64 platform, and as such, will only run in 64 bit mode.

Using OData from Objective-C - Fixing the odatagen NSRangeException bug

9. July 2011 22:10 by hugodahl in Objective-C

Lately, I've been working on getting a small sample project up and running on the iOS platform, and using an OData endpoint for external data access. Fortunately, the OData site is an incredibly useful resource for a vast array of information, from both the publisher and consumer perspective. There is even an office Microsoft OData helper project for Objective-C which lives over on Codeplex.

Part of this toolkit is an incredibly indispensible tool, which in its simplest form, can generate your entity classes (.h and .m files) from the OData Metadata. So in theory, if you wanted to generate the entities for the Netflix catalog API, all you need to do is call it as such:
./odatagen /uri= /out=~/Projects/MyNetflixApp


Book Review - The Art of Unit Testing: With Examples in .Net

4. July 2011 18:00 by hugodahl in Books, Unit Testing
Title The Art of Unit Testing: With Examples in .Net
Author(s) Roy Osherove (blog)
Rating 5 / 5
Release Date May 2009
Publisher Manning Publications
Book Site
Publisher’s support site Manning Sandbox
Book Support Site

I first started reading Roy Osherove’s “The Art of Unit Testing” over a year ago, as my team was ramping up design and development of a new application to be written, in its entirety, in new technology (.Net framework 4.0, WPF, EF 4.0, etc). So new in fact, that when we started development, there was no “4.0” released, it was still at the Beta 2 stage. Also, since we were to be the first truly “agile” (scrum) team, we knew we had a lot of eyes on us, both from above as well as from fellow developers. By “truly agile” we were fairly close to textbook. We all worked in the same environment (shared room), including 3 developers (with one added for a 1.5 month stint to make up lacking capacity), manager/scrum master as well as QA. We had a CI environment which was setup and maintained. We had a scrum board, or boards, which were large 24” x 36” post-its or a wall when needed, filled with user stories, tasks, backlog, all diligently written and managed on post-it notes.