jaikoo

I grew tired of my Xtreamer. It's nice and all but it's got far too many rough edges for me to accept so I decided to build an XBMC appliance recently.
Zotac had released their new ION2 based nettop box and while there were some complaints in the early days with fan noise recent BIOS updates have made the Zbox far quieter and cooler to run.

The only problems I had when trying to install XBMC live onto it were:
i) When installing it via a USB thumbdrive quarter of the way through installation it would complain it couldn't find a cdrom drive, which would make sense as there wasn't one. But still it shouldn't be complaining about that as XMBC is designed to be installed on nettops. In the end it turned out to be th Corsair thumbdrive that I'd created the usb boot device with. Switching to a different brand of USB thumbdrive fixed the problem.

ii) My second problem was audio through HDMI. I recommend using xmbc freaks version of the livecd found here http://www.xbmcfreak.nl/en/xbmcfreak-livecd-10-08-svn32416 . It's more upto date and has the more recent ALSA drivers installed. Though you'll still get some problems if you're like me as it still wasn't automatically configured properly. Follow on from step 4 from this guide under the section 'Upgrade Alsa'. Xbmc freaks llivecd already has the new ALSA updates and Nvidia drivers so all that's left to do is run through the configuration instructions.

So, 1080p was fully accelerated. Playing Star Trek at 1080p showed no slow down even during the fast battle scenes. I'm quite impressed as even on a Acer Revo 3610 there were times when fast paced action scenes did slow down for 1080p content.

Another thing which I haven't tried but will do is that upscaling of Divx content is done at the hardware level hopefully producing far better quality upscaling to 1080p of 420p content than the older ION nettops would be able to do with software alone.

www.binarydroid.com
www.linkedin.com/in/jaikoo
Tel. +44 (0)759 0543 558

I've been working with various startups for a long time and there have been three obvious things that had always stuck out at me when developing a great product. Notice I say a great product, not a successful product. In order to build a successful product requires a lot more than excellent engineering practices. If you don't believe me then you've either lived a blessed career or you need to grow up a bit.  I'll explain this in another blog post or probably several but for now I'll just concentrate on the subject of Kent Becks keynote.

So what are the three important engineering practices?
i) TDD.
ii) Being clear to the business what you're delivering.
ii) Get it out there as soon as possible even if it's not perfect.

Yeh, it's not revolutionary. There have been numerous people blog, write books and even do TV appearances on this subject. Nothing new to learn right? Not necessarily. Let me tell know about how a lot of engineers end up in the opposite of this situation.

A few years ago I was unfortunate enough to work at one of those startups that I really should of known better not to join. You know the type. They've got an ambitious delivery schedule, they want you to lead development and in 3 months they'll bring on some other engineers to help out. In reality their plan on hiring another couple of devs actually revolves on some dream that they'll be so shit hot that they'll have VC's banging on there door with sacks of money. Which in reality means you'll be the only one looking after the code base and delivering the product for foreseeable future.

This isn't necessarily a bad thing and in some circumstances be great. The time it becomes a nightmare is when you're finally given the code base for the product that another agency had developed the 'prototype' for.
Now two problems usually occur here:

i) When people tell you it's a prototype it usually means it's got in the zero engineering finals. There's little to no tests. And most of the few tests that there are have something like 'assert true, true'. When you look through the code you see that someone's been pushing business logic everywhere. In the controllers? Yep. In the view? Heck why not. What about a 150 line controller action just to mix it up a little.
Yes, while most of you will in your careers never have to live with that kind of ordeal some of you will.

ii) The business doesn't realize this is a 'prototype' heck, they've paid good money and somewhere down the line someone has told them this is production quality code that could power a billion transactions a second.
To them, all you've got to do is build on the existing code base and poop out a feature a minute. They have no idea, inclination or knowledge that they've actually paid for a throwaway. Someone down the line, be it the CTO, product manager or even the guys down at the development agency wasn't up front about what they were delivering.

So what happens next? You're in a high pressure situation and you've got your reputation of being a top notch coder with insane skills to protect. You'll either go along with trying to patch the code to make it do what you want until you collapse from fatigue. Or you go into engineering mode, deleting whole swathes of code in your path replacing it with beautifully engineered and tested lines of poetry. Either way the business at some point gets upset at the slowing of progress. So what if agency X delivered poor code if they coded 20x the features in the same period. They don't care that if the code base had some degree of good testing then you'd have predictable and sustainable delivery of features. And it's not really their job to either! Sure you can try and blame management, but in reality they're not engineers and the closest they can come to understanding our world is that which is tangible. Stuff they can view, click, drag etc.

And guess what. If management primarily judge your productivity by your tangible deliverables then guess what your end users judge you on? I'm not saying that users always want a constant stream of features in order to gauge how great the product is. But what they are expecting are improvements. If the end user can't enjoy the end product in some tangible way such as speed, simplicity etc. Then you might as well just shut up shop now.

To be a successful engineer you need to find balance with how your product is developed, engineered and tested against how quickly you can deliver tangible benefits to the end user.
It's  frustrating for me to come on to a project that has no tests and poor design. But it's equally frustrating for me to come onto a project that's over engineered with layers of abstractions that aren't required and a test suite that boasts 100% coverage but who's tests are either quite pointless (they don't test behavior) or they're extremely brittle to the point you spend more time maintaining existing tests that writing production code.

In case you've misread me, I'm not saying don't design and test. Sure, it might work in the short term. You'll probably deliver quite an impressive product in the short term. But either you're engineering team will come to the point that adding new features to the code causes some kind of quantum imbalance i.e no predictable effect or you'll just have to keep on hiring smarter guys who can understand the chaos. Of course with that comes high staff turnover as you slowly burn through smart guys (or gals).

What I usually recommend is something in the region of 80% test coverage and where I used to put a large emphasis on domain modeling I've actually found more benefit to looking at everything from a top down approach. That way there's a greater chance what I develop will actually go into the end user product. I've always found starting from the model has always left too many "what if's?" and it's so easy to get stuck solving edge cases.
I know a lot of people seem to poo poo on using an integration testing tools such as Cucumber but if I were going to use one tool to drive development from the top down it would be this. Not only do you have an executable list of features that you can demonstrate to the client but you also have that warm fuzzy confidence that what you've delivered will actually work. Add in a dash of capybara with the selenium 2.0 drivers and you have a high degree of confidence in your javascript based user interactions. Really, I just have no idea why some developer still resist the sweet lure of the cucumber. If that sounds kinky, it was intentional.

So to conclude, stop worrying about how well engineered your code is. As long as you can demonstrate sustained deliver ability of features in a timely manner that benefits your end users and ultimately the business then that's all you should care about. And remember, don't hide behind things such as "code craftsmanship", or start quoting the agile manifesto as soon as someone questions your lack of tangible in a while. Real craftsmen ship all the time.

www.jaikoo.com
www.binarydroid.com

Out of all the jobs I ever did to pay my way through college and university when I was a kid, working as a chef in a chinese restaurant proved to be one of the more beneficial.