MicroReview - Tacens RADIX ECO 500W PSU

Disclaimer / warning: This review contains opinions. Also, if you're looking for a technical specification or unbiased information on how this piece of hardware actually fulfills it's duty, you won't likely find it here. But, if you are a system builder and would like a second opinion or hints on what to keep in mind when working with this specific component, look no further. :)

From entry-level power supplies I considered for Machine #1, the Tacens RADIX ECO 500W PSU seemed to be the most interesting, promising to be quiet and eco-friendly, while being promoted on a Spanish-only website. What's not to like, eh?
Packaged in a pretty white box, you can find a black PSU with a large white fan:

Mounting this PSU into the case went as expected, size- and screw-wise a standard ATX PSU.

When mounting the unit to the top of a case, as you can see from the image above, the wire bundle exits the PSU from the open side of the case. For a person who's more familiar with Cooler Master or Corsair brands, this might seem a bit unorthodox. If you actually plan your cable management ahead, be aware of the fact.

The on-off switch for the unit has a really comfortable placement, especially when top-mounting the PSU. It can, however, make you a bit nervous while assembling, since the switch is really close to the top edge of the case.

The set of connectors provided with the PSU is decent enough if you're building a small system and are not planning to have a large number of hard drives, or high-end PCI(e) cards that require additional power. What you get with the 500W unit, are:

• a 20+4 pin motherboard connector,
• one 4-pin CPU power connector,
• two SATA power connectors,
• two 4-pin HDD connectors and
• one 4-pin FDD connector.

And this is what the unit looks like installed, including the fair warning: "Hazardous voltages contained within this power supply."

Detect file leaks in Java - the quick way

Sometimes you just can't be bothered to install a JVM profiler only to trace the files that have been opened by the piece of code you're debugging. As it turns out, there's a really nifty agent library available for tracing where, when and by which thread your JVM file descriptors have been opened - the File Leak Detector by Kohsuke Kawaguchi.
I've found it to be easiest to use the built-in HTTP server option:

java -javaagent:path/to/file-leak-detector.jar=http=19999 ...

... and then pointing your browser to 

http://[the machine's hostname or IP]:19999

You get a report that shows the file name, the thread responsible for opening the file (accompanied by the stack trace of the open call) and the timestamp of when the file was opened. Just lovely. 

MicroReview - MSI B75MA-E31 Motherboard

Disclaimer / warning: This review contains opinions. Also, if you're looking for a technical specification or unbiased information on how this piece of hardware actually fulfills it's duty, you won't likely find it here. But, if you are a system builder and would like a second opinion or hints on what to keep in mind when working with this specific component, look no further. :)

MSI B75MA-E31, it's the one with solid capacitors. A micro-ATX motherboard, with an LGA1155 socket for your Intel CPUs. This is what it looks like fully clothed:

(1) - Friendly GUI should really be named "awesome GUI". Essentially, it has an old-school Phoenix BIOS - looking tabbed GUI interface, with tons of options to configure and mouse support. Fun!

The box contains just the motherboard, a disc with chipset drivers on it, a back-panel for an ATX case, an installation guide and two SATA cables, which also makes the box surprisingly small, even for a micro-ATX board.

When unpacked, this is what the board looks like:

... and with some additional views:

A few things to note here:

• There's just one SATA III connector. This is stated in the tech specs as well, but if you're planning on building a fast software RAID array on top of this board (and you like to do it eyes closed), you might be out of luck.
• There's a good-old PCI socket available, which means you can hook some older hardware on the board as well.
• The auxiliary CPU power input and the main power supply socket are quite far away from each other. There's likely a good technical reason for that in terms of electrical engineering, but just make sure that the power cables from the PSU can bend that way.
• The pin set for front-panel connectors might not exactly match what's described in the "quick installation guide". Although the main pins, such as HDD LED, power switch, reset switch and power LED work fine, pins for SLED and PLED did not seem to be where shown in the guide.

When installing the motherboard, take note of the screw hole layout on this board. The bottom ones are not aligned into a rectangle, but rather with a wider distance between the front holes (H and R, in terms of the microATX standard). Or don't, and end up like I did:

The rear panel looks simple and clear, probably just a bit hard to see in low light, because of embossed markings.

Just try to make sure that all of the thin metal edges around the sockets have been bent properly before installing the board. Otherwise, you'll end up with this:

All in all, MSI B75MA-E31 is a lovely little motherboard to work with, as long as you're satisfied with a basic set of features and a small price tag.

MicroReviews on hardware

As an attempt to reboot the blog, I will attempt to create a few tiny reviews a month on different computer hardware I like to play around with. Since for every piece there are probably metric tons of performance-, price- and other important-things-related-reviews available, I will most likely be focusing on how the pieces might impact someone who's building a computer (i.e. before the PC is booted up for the first time).

A well-written book on producing Open Source

Due to a recently found interest in applying open source project management ideas in a closed commercial software development environment, I started reading a great (and free!) online book - Producing Open Source Software by Karl Fogel. Although not exactly a "new" book, it still contains a lot of fresh ideas and field experience on producing OSS.

Rubber duck debugging revisited

I have always enjoyed thinking out loud - especially when thinking about complex technical problems, but have never given much attention to this process until a colleague of mine pointed out a catchy term (which for some unknown reason I wasn't aware of) for this process - Rubber Duck Debugging. Other (common?) variations of this are the Cardboard Programmer and the Cone of Answers. Here are a few more patterns I thought of naming (haven't tried them all in real life, though):

Preschool debugging

Goal: To have a more interactive communication experience as compared to a cutout or a ducky.
Method: You need to have really good relations with a colleague's preschool kid for this. Or better yet, to have your own offspring ready for action. Take a 3-5 year old kid to your computer and start explaining the piece of software you're working on. Use domain-specific language as you please. Continue until you get tired of the why-questions or one of you gets cranky. Don't be surprised if it is you - the little devils can be quite persistent.

Grandmother debugging

Goal: To explain the software details in non-domain specific terminology.

Method: Similar to preschool debugging, but "use" a foreigner to the domain of your software solution. Bonus points for actually employing a grandmother. Try to explain the software in terms that the foreigner would understand. Use analogies, if needed - extra bonus points for applying sewing or knitting terminology in case of thread management issues.

Blind man debugging

Goal: To find lack of coherence in a user interface design.

Method: Take a "blind" subject - a person that has never seen the user interface you have designed, give the subject a piece of paper and a pen. Take a usage scenario to be executed on the interface and describe the user interface elements to the subject. Let the subject draw the UI elements in the execution order of the flow, eyes closed. Take the drawing and compare it to the described design - UI elements that are most inaccurately positioned compared to the original are probably the hardest to find for a regular user. (Haven't tried this one - just based on a hunch)

Persisting mutable objects in Tapestry

Since Tapestry makes it easy to persist application state by using the @Persist annotation, I tend to have a habit of using mutable state objects and then stumbling on problems when changing these mutable persisted values do not result in updates to the underlying session store.
Here's a sample page class:
On the page template, we simply display the current state and an action link to call the onActionFromChangeState event. Everything seems to work - the state object (List) is lazily initialized and new items are appended to it.
Long story short, Tapestry does not detect the changes to a mutable persisted state object. Unfortunately, the way HTTP sessions are usually implemented in many servlet containers, changes to the mutable state are still persisted (bypassing the Tapestry's persistent field invalidation mechanism). This can cause unexpected and hard-to-trace problems later, when trying to switch the persistence strategy for a specific state variable, e.g. from the session to the client strategy.
For instance, here we try to change the previous sample to use client-side persistence instead:
But when calling the onActionFromChangeState, nothing seems to happen. The state is transferred from the server to the client and back, but this always contains an empty List. This corresponds to the empty List initialized on the first render request.
To demonstrate that this is really the case, we can use a simple hack:
Now the changeState action works once again, since the PersistentFieldConduit responsible for recording the change of the field value is used. Although this kind of a "hack-y" approach works, the moral of the story seems to be quite clear - be very careful when persisting mutable values.