Episode #514 – December 2, 2014

In this episode we yap about Rails 4.2 RC1, Opal, Deployment, Interpol, Sportdb, Service Objects, and Emails.

The 2013 HTPC Build

September 18, 2013

I no longer own any laptops. Everything in our house is a tablet: multiple Nexus 7s, multiple iPad 4s, and a Surface Pro. In fact, the only traditional computers I own are my triple-monitor desktop home office beast, and the small Home Theater PC (HTPC) that drives all our home entertainment in the living room.

It's a Mini-ITX case with compact, console-like 3.8" × 8.7" × 12.9" dimensions. It is a class act, totally at home in any civilized home theater environment.

I love that little HTPC to death. It is such a versatile, flexible, always-on box. The longer I work on my HTPC project, the more I believe the evolution of the HTPC is a nice metaphor for the overall future direction of the PC. In summary:

2005	~$1000	512 MB RAM, single core CPU	80 watts idle
2008	~$520	2 GB RAM, dual core CPU	45 watts idle
2011	~$420	4 GB RAM, dual core CPU + GPU	22 watts idle
2013	~$300*	8 GB RAM, dual core CPU + GPU×2	15 watts idle

15 watts at idle! Incredible, isn't it? But you probably also noticed how some of these stats aren't improving so much. Basically, they don't need to – we've reached such an absurd overabundance of computing power that slathering more on top no longer gets us much. It's been about 2&half; years since my last HTPC build, and (*) all I did this year is swap out the motherboard, CPU, and RAM:

I started by removing the overhead drive tray, then pulling out the motherboard and anything attached to it. Notice there's a ton of room in the front of the case where the old power supply used to be. No need for it. We're using a more efficient and way smaller PicoPSU. That space is now available for an extra 2TB 2.5" drive, sitting there on some mildly sticky sheets of sorbothane. Once you factor in the PicoPSU, it's a roomy build despite the compact dimensions.

Then I mounted the motherboard, attached the front USB and eSATA headers, the power/reset switches, and the aforementioned PicoPSU, which you can see sticking out of the motherboard's power header near the hard drive. Note that everything not directly attached to the motherboard is driven off a single power connector, so there are two SATA splitters in use. This particular PicoPSU and power brick are rated to 60 watts which is enough for what we're doing.

The top drive tray slides in with 3 screws. There's also a place just underneath the two drives above for a slimline Blu-ray or DVD drive, but I found I have virtually no use for optical media any more, so I've skipped it.

The main motivation for this upgrade is the lower power usage and better GPU performance of the Haswell CPU, versus the Sandy Bridge CPU that was in there. Everything else remains the same, though I have been selectively upgrading bits and pieces since 2011:

Yes, that's right, 4.5 terra-friggin-bytes of storage. What can I say? I like me some media, man. The 512GB boot SSD is a little excessive, I'll grant you that, so feel free to replace the drives with something more modest in your build. I'm just addicted to SSD speed and didn't want to compromise too much on total storage.

You may wonder why I bothered upgrading memory, since the trusty DDR3-1333 RAM in the old HTPC works fine in the new motherboard. Fair question. Normally, RAM speeds are little more than a curiosity on modern computers, as minor improvements in memory speed have long since ceased to produce meaningful differences in benchmarks. But we are using Haswell's on-die GPU, and it relies on main memory as graphics memory. Even a low-end video card will have 1GB of ram on it these days, and games certainly expect GPUs with at least 256MB or 512MB of dedicated, extremely high speed graphics memory. This is the rare case where you do care about memory performance. Consider these AnandTech game benchmark results:

It's a bit difficult to read, but think of it as "percent better than vanilla DDR3-1333", since that's the baseline zero value here. The sweet spot is DDR3-1866 CL9 (light blue bar). That grade of memory is only nominally more expensive, and gets you reasonably near the top of each graph, but this motherboard doesn't support anything higher than 1600. DDR3-2133 CL9 (dark purple bar) is also out there.

Other than lower power consumption, and a modest bump in CPU power, the really big improvement is GPU performance. It's kind of a complicated matrix, but the i3-4130T chip has an Intel HD 4400 GPU, compared to the HD 2000 GPU that was in the i3-2100T I upgraded from. For example, Dirt 3 on medium detail at 1024x768 notebookcheck.net shows a gain from 21.4 fps to 44.6 fps for these specific GPUs – more than double the GPU performance, at the same 35 watt TDP!

That's the other reason I was excited about this upgrade: Steam's Big Picture mode. With that doubling of GPU power, this 15 watt idle HTPC we just built … is now a credible gaming machine!

You will need an Xbox 360 Wireless kit for PC, which works perfectly with Steam Big Picture mode. Just plug and play, provided you stick to the 190 Steam games with full controller support. You'll still have to tinker a bit sometimes to get things to work, and you won't be running Battlefield 4 in hi-def at 60fps or anything, but overall it's quite promising and bodes well for a console-like future. I've had solid results with slightly older games in 720p using medium and occasionally high detail levels, depending on the game.

So what exactly do we get for our upgrade troubles, 2&half; years on?

A 32% drop in idle power, from 22 watts to 15 watts. And an overall reduction in power consumption when the machine does happen to be doing something. 17 watts when in an active torrent, for example, up to around 50 watts when playing GRID 2.
A credible gaming box for the first time, thanks to 2× the GPU power. It also coincides nicely with the maturing of Steam's Big Picture mode. When Gabe Newell talks about Linux as the future of gaming, this is the sort of machine he's referring to.

I'm not sure how much lower we can go on power, but I'm absolutely certain that Intel's on-die GPUs will continue to roughly double in power each generation for the forseeable future. This little HTPC box just keeps getting more versatile over time, while costing me less (in power consumption, at least) every year. It's the funnest build ever. HTPC, I love you, man!

[advertisement] Hiring developers? Post your open positions with Stack Overflow Careers and reach over 20MM awesome devs already on Stack Overflow. Create your satisfaction-guaranteed job listing today!

[…]

Mob Refactoring

January 30, 2014

When teams try to take control of their technical debt and improve the maintainability of their codebase over time, one problem that can crop up is a lack of refactoring experience. Teams are often composed of developers with a mix of experience levels (both overall and within the application domain) and stylistic preferences, making it difficult for well-intentioned contributors to effect positive change.

There are a variety of techniques to help in these cases, but one I’ve had success with is “Mob Refactoring”. It’s a variant of Mob Programming, which is like pair programming with more than two people (though still with one computer). This sounds crazy at first, and I certainly don’t recommend working like this all the time, but it can be very effective for leveling up the refactoring abilities of the team and establishing shared conventions for style and structure of code.

Here’s how it works:

Assemble the team for an hour around a computer and a projector. It’s a great opportunity to order food and eat lunch together, of course.
Bring an area of the codebase that is in need of refactoring. Have one person drive the computer, while the rest of the team navigates.
Attempt to refactor the code as much as possible within the hour.
Don’t expect to produce production-ready code during these sessions. When you’re done, throw out the changes. Do not try to finish the refactoring after the session – it’s an easy way to get lost in the weeds.

The idea is that the value of the exercise is in the conversations that will take place, not the resulting commits. Mob Refactoring sessions provide the opportunity for less experienced members of the team to ask questions like, “Why do we do this like that?”, or for more senior programmers to describe different implementation approaches that have been tried, and how they’ve worked out in the past. The discussions will help close the experience gap and often lead to a new consensus about the preferred way of doing things.

Do this a few times, and rotate the area of focus and the lead each week. Start with a controller, then work on a model, or perhaps a troublesome view. Give each member of the team a chance to select the code to be refactored and drive the session. Even the least experienced member of your team can pick a good project – and they’ll probably learn more while by working on a problem that is on the top of their mind.

If you have a team that wants to get better at refactoring, but experience and differing style patterns are a challenge, give Mob Refactoring a try. It requires little preparation, and only an hour of investment (although I would recommend trying it three times before judging the effect). If you give it a go, let me know how it went for you in the comments.

[…]

The Ruby Rails Aggregator