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

  • I don't know about sisal specifically, but fiber-reinforced concrete (FRC) is a thing, so I imagine the answer is "yes". If you call up a concrete company and request a load of concrete, they will ask you if you want fiber. It's not as good as steel, but it's better than nothing at all.

    Source: I poured a concrete pad for a hot tub a few years ago. I used FRC and rebar.

  • 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.

No public wish lists :(