Member Since: December 16, 2010

Country: United States


Programming Languages

C, C++, Perl


application development (both desktop and the web), MVC, ORM, enterprise deployments, virtualization

  • Mine came with a piece of tape over the sensor. Does this need to be removed for proper operation or hydration of the sensor? Or can I leave it in place to guard against potential water splashes?

  • The referenced code is horrid.

  • Damn. That was kinda sad. :(

    Good luck, Rob!

  • Ah. “Third installment”. Har.

    Very subtle. I completely missed it.

  • I want to use one as a replacement for a touch interface for a pcDuino running Android in my shop. The most applicable use would be moving through a document (such as a PDF) being displayed on the LCD TV in my shop by using gestures. I recently picked up a ZX and a Leap Motion. I’ll soon see how well each is up to the task. I may use both of them.

  • Until Casey obtains enough Actobotics c-channel to complete his operational B-25 Mitchell replica, he will have to get by on Microsoft Flight Simulator.

  • Great video. My favorite part is the song. ♫ That Jeep ♫ Kinda scares me. ♫ Oh that Jeep ♫ Kinda scares me.

  • Or simply “a tenth of the cost”. Saying X orders of magnitude less expensive where X is > 1 doesn’t make any sense from a mathematical perspective. Words mean things. It was a pet peeve of my grandfather’s (NASA engineer) and it’s a pet peeve of mine as well.

  • In my experience as a software developer, it’s not just about expecting failures and failing gracefully but also making sure the appropriate details of the failure is provided to the consumer. When I say “consumer”, I don’t necessarily mean the end-user of a device, either. A consumer can be a developer who utilizes a third-party API that may in turn use another API internally. Handling all of the possible error messages and encapsulating them appropriately for the consumer of the interface is important.

    In this case, that error message is appropriate for a technician, not the end-user of the device. The appropriate message to present to the end-user would be “Failure during initializing; please try again. If problem persists, call XXX-XXX-XXXX for service.” The details of the error can be made available via a secondary screen/button or a serial console.

    Now, consider how confounded you might be if the error returned was not formatted for a technician, either. What if the message displayed was the raw error returned by the kernel’s write() system call? “Error 32” Imagine how maddening that would be, both for the end-user as well as the technician and/or engineer whom have to debug the issue. The unfortunate truth is that sort of thing happens far more often than you think.

  • Why call the number, wait three days for service, and pay $500 when a power cycle fixes the issue? The whole point is the unit failed clumsily. It could have rebuilt the file. Or, if it was an unrecoverable error, wait until the number of failures crosses a certain threshold before waving the white flag. Increment a counter stored in non-volatile memory and power itself off. Once counter surpasses five, show the error. Since a power cycle fixed the issue, the counter is cleared, and no message would have been shown. It’s called UX (user experience) design.

    We’re engineers here. We don’t take clumsy failures very well. If this had happened to me, I would have found it very difficult to not attribute it to a deliberate attempt by the manufacturer to drum up unnecessary service work.

No public wish lists :(