Category Archives: Development

Throwback: Video Recording Hack on the Palm Pre

This is a throwback post, but I never documented my experience regarding hacking the Palm Pre.  To the best of my knowledge, this is how things went down.


Back when the Palm Pre was released, it wasn’t quite a finished product.  Yes, WebOS was a pretty awesome OS at the time, and the hardware keyboard was a nice touch.  Except critical functionality, besides a shortage of apps developed for WebOS, was missing from the phone.

One of the biggest complaints was the lack of video recording for the Pre’s built-in camera.  I know many people were looking into a homebrew solution for this, so I thought I’d start doing some research and see if I could contribute.

Plan of Attack

The first step I took was to research the hardware involved.  It turns out that the CCD camera chip used in the Pre was the same as the one used in the OLPC (XO laptop).  Knowing that the OLPC offered video chat capabilities, I started researching how those were implemented.

I had already rooted my Pre and had command line access.  The next step was seeing what software was already loaded onto the Pre.

In one example for the XO laptop, Gstreamer was used to pull video from the camera.  I lucked out and realized that Gstreamer was already installed on the Pre, including a number of encoders /decoders muxers/demuxers and video and audio sinks.  It was just a matter of hoping the encoders were actually implemented properly, and that I could actually pipe data through them, and ultimately to the file system.


After a great deal of dabbling at the command line, I was able to pipe raw H.264 video to the file system, a file which was then playable in VLC despite having no file container surrounding it properly:

(make sure FS is rw)
mount -o remount,rw /
gst-launch camsrc ! palmvideoencoder ! filesink location=/media/internal/downloads/foo.mp4
mount -o remount,ro /

A wiki post detailing my original hack is located at WebOS Internals.  I’ve also attached the first successful video (foo) that I was able to record — it was like 4AM and me sitting at my desk in the dark, hoping that the hack session would pay off!  Ultimately, it did.

I’m writing this article years after the fact, but in 2013 I actually ran into a guy and we were talking about the Pre, and I had mentioned I was the guy who performed the original video hack and he remembered it.  Kind of cool to have a little geek street cred!  The original Pre Central post on the topic is located here.

ClosedXML: To Equal or not To Equal?

The Problem

After utilizing the ClosedXML library for Excel parsing, my fellow developer, Sean Killeen and I hit a snag:

We were using FluentValidation with custom validators to test records in an Excel worksheet.  Except, whenever an error was triggered, instead of returning the validation failures, it was throwing an exception regarding some functionality we weren’t even using; it was throwing about XLColor or some other object irrelevant to what were validating.  Weird.

Debugging and dropping a break point in the code showed that everything was working as expected, even up to the return statement!  So one morning I declared my intent to solve the bug once and for all.

I realized the issue must be with serializing the response object — if everything is good up until that point, something is going wrong in the serializer.  So I got the source to Newtonsoft JSON serializer and started stepping through.

Aha!  Obviously when an object gets serialized to JSON, the serializer must recursively go through each child object.  It turns out, Newtonsoft checks if the object is already in a collection of objects that are already serialized.  This requires it to use the contains method of the collection, which in turn calls equals on every object within.

The way FluentValidation works is that it will return to you the attempted value that failed validation.  Upon trying to serialize the cell that failed the validation, it was serializing all the properties of the XLCell, hence why the XLColor object was attempting serialization.

Turns out, ClosedXML doesn’t implement .Equals correctly for most of its classes.  That is, if you perform the check on an object of a different type, it throws rather than simply returning false.  I confirmed the expected behavior of built-in complex objects in C# should be to return false, not cause a failure.  When the serializer would attempt to call contains on the XLColor object it was being compared to objects of other types already in the collection, causing it to throw.

The Solution

So I checked out their repository and started making updates, plus unit test coverage on each class to confirm proper functionality.  Unfortunately, my laptop croaked shortly thereafter so I haven’t had a chance to check-in my changes and open source contribution to the project yet.  Perhaps when I have a little downtime soon.

Our stop-gap solution was to pass the serializer a filter to ignore the AttemptedValue property of the FluentValidation failure, since we weren’t using it for anything in this specific scenario anyway.


While this was a headache that required delving into several other codebases, it was a good reminder that something as trivial as the implementation of .Equals should be paid attention to by any developer, and that a unit test to cover that scenario is not necessary a trivial case that can be ignored.


On Technical Recruiting

For the last four months or so my company has dedicated time to recruiting a new senior developer in order to build out our development team from two people. Being in the D.C. Metro area, I figured this would be a relatively simple task: there are a ton of people in the area, many of whom are working on technical projects for government contractors or for the government direction. A permanent position at a private company with excellent benefits should carry mass appeal.

So now, four months, ~20 in-office interviews, and after countless pre-screening exams and phone interviews, we’re still without a new Senior .NET Developer.


I started at the company as a semi-technical consultant, primarily focusing on client work, back in Fall of 2009. After being at the company a few months, I started taking a look at our (at the time) SharePoint 2007-based Claims Administration Platform. It was originally built for the company by an outside consulting firm and was basically a way for us to disseminate complaints to our clients and have them acknowledge receipt of the complaints. It was largely built using BDC web parts, a little bit of custom code for uploading documents and interfacing with our existing SQL databases, as well as using a custom SQL membership and role provider.

Fast forward to today, and we’ve expanded that platform to offer more information about claimants to our clients, including custom workflow functionality that suits their needs. It basically went from a glorified document acceptance system, to a full blown claims administration platform, and we also expanded development into adjacent product areas including insurance coverage.  We’re in the process of transitioning a few clients that remain on the SharePoint system to the re-written platform that is a 5-tier architecture utilizing MVC, WebAPI, KnockoutJS, and OrmLite for the data access layer.

My background with respect to programming goes back to playing with VB back on my dad’s old Gateway 2000 486 (with Turbo button and math co-processor, natch) running Windows 3.1 back in elementary school.  Throughout middle school and high school I continued to take an interest in development, taking whatever classes were available and teaching myself a lot as well. I ended up majoring in Business with a minor in Computer Science, and most of my internships were technical, but I never really worked in a formal development environment. That is to say, I wouldn’t consider myself professionally trained as a web developer.

Our Process

We generally like to do a phone screening to gauge how the individual would fit with the company (we’re relatively young, small, and not rigid — we need self-motivated people, not to hear “that’s not part of my job”). We like to get a narrative on why they’re looking for new work, ask questions about any gaps in their resume, and talk turkey on their past projects to get an idea of how experienced they are.

If the phone interview is satisfactory, we have them do a brief, 5-question online exam on InterviewZen. A side note: InterviewZen, though not polished, is a pretty neat tool: it allows you to create interview questions, has syntax highlighting for a number of languages, and allows you to “replay” the candidates’ responses in real-time in order to see how long it took them to answer a question, as well as whether or not a copied and pasted code in order to complete it. Pretty nice way to make sure everyone’s being honest.

We ask some basic logic questions, C# debugging, SQL, as well as asking the candidate to write an AJAX call to some MVC and WebAPI methods that we provide. Generally basic stuff that any senior developer candidate should be able to do in their sleep. We aren’t looking for absolute perfection necessarily, but you know when you see a red flag.

If the candidate passes the pre-exam, which weeds out probably 70% of candidates, then we bring them into the office for a coding challenge, group interview with the development team (generally non-technical), and then for interviews with management.

For our coding exam, we ask the candidate to write a simple MVC-based web application in approximately 2-3 hours. Without giving away what we usually task people with, it should consist of about 3 AJAX calls, and have one model, one view, and 1-2 controllers (depending on whether they want to use WebAPI). We only demand that it not do full-page refreshes (i.e. use AJAX) and that data persists (but we don’t require a database — a static list of data, or storing it in the Session would be sufficient for this purpose).

The candidates are welcome to use whatever resources they want (let’s be serious, we all Google sometimes) but only require that they don’t reference an already-completed project of a similar variety. They’re welcome to use any client-side libraries they want, including MVVM. It doesn’t have to be a straight MVC solution.

The Reality

We’ve had literally no success in finding someone who can competently complete (or even mostly complete) the in-office coding challenge. As a sanity check, both myself and our former other senior developer performed the task and were able to complete it in about an hour, give or take 15 minutes.

Our salary range is on par with the industry in the area, and our recruiters know that we’re not limiting on the high end either — it’s basically just a benchmark range.  It’s discouraging because we had a guy come in demanding over six-figures, who clearly hadn’t done much programming — he bound his view to a class which had a second non-static initializer class in the same file, yet he was trying to access said second non-static class.  Like we’re seriously going to pay someone six-figures for that kind of code?  You. Have. Got. To. Be. Kidding.

Issues Experienced

  • Data Persistence: Despite the suggestion to use a non-database persistence mechanism (we even tell them to use a static list or the Session) many people were not able to get data to persist at all, which clearly demonstrates a misunderstanding of relatively basic web development functionality.
  • JavaScript: Most people are remarkably weak on the JavaScript side of their skills. I mean literally Googling “javascript function syntax” after telling me they’ve used jQuery to perform at least hiding/showing elements. We’ve had people clearly look up jQuery ID selector syntax — for ID selectors. How can you not know how to use that if you claim you have experience?
    • Inline javascript is remarkably common. It’s not a deal breaker for us, but it literally takes 2 seconds to drop a script tag on the page to reference another JS file, and let’s be serious, that’s how things should be done so I can actually minify (and eventually unit test) our JS source.
    • No JavaScript namespacing. Literally, only one person has used non-global functions and variables.  Bleh.
  • User Interface: Really messed up and inefficient user interfaces, if they even got to that point.  Some people didn’t even write a lick of HTML in 2 hours.  Others had wonky multi-page layouts for something that is supposed to be incredibly simple, and on a single page.
  • MVC Fails: Models bound to views that are for a single list item, rather than binding the view to a collection of said models, when multiple are supposed to be shown. How do you show more than one item in a list, ever, when setup like that? Sure, you could do an AJAX call on document ready to pull all of them, but no one actually did that, meaning that they clearly just didn’t understand MVC and how to payload a initial list of items.
    • Models that don’t have fields for the requisite information being captured.  If I need to mark some item as completed, shouldn’t it have a boolean to store that information?
  • What do you mean, “server-side”?: Pages that literally have no server-side code written and that simply manipulate the DOM manually.  Clearly, the requirement of data persistence and making AJAX calls was entirely lost on these folks.


We’ve been working with a number of recruiters, as well as putting up job postings on Stack Overflow Careers. I can say with certainty that the idea that someone non-technical can place a technical person efficiently into a technical position is a flawed idea.

The candidate pool we’ve had has just been attrocious and it makes me worry for the industry and the country. If we can’t even place people into “knowledge economy” jobs anymore, it’s not really surprising that America is falling in global competitiveness. That said, we even had some foreign workers with visas come through and fail catastrophically at our recruitment process as well.

I basically have no faith in resumes or recruiters at this point. I’m hoping to utilize Betamore’s co-working space in Baltimore as a resource for honing our recruitment process further, or possibly even finding a developer who currently works out of their space.

The thing that just astounds me is the fact that my degree is not particularly technical, nor was our other senior developers undergrad experience, yet we’re far more capable out of the box than 99% of the market. It’s just crazy to me. Perhaps its just the nature of hiring people who are out of government positions where they might be in a huge pool of developers and are able to hide their incompetence, or have less-strict deadlines than private industry requires, making the “get shit done” side of things less critical to being considered successful.

We’ll keep on trucking…I will not settle for hiring someone less experienced than me, primarily because I need, at minimum, a peer to bounce ideas off of, and ideally someone who knows a lot more than me.  That’s the best way to effectively and organically grow a team and it is something on which I will simply not compromise.