Small Wonders

I want to write today about the amazing feat of technological advancement illustrated by this picture.

There are two memory systems shown. In the background, a core memory fragment with an 8 byte capacity and resting on top of it, a Micro SD card with an 8 Gig capacity.

Here’s the clincher. While these memory systems both have a similar total cost, the SD card has a billion (‭1,073,741,824‬ to be exact) times the capacity! Now, for such small devices, there’s a lot to know about them. It turns out that we’re all in luck. The YouTube channel Explaining Computers does a fantastic job of… explaining computer stuff! In particular, a recent video did such a fantastic job of making the complex world of SD memory devices simple that I just had to take notes. The summary of those notes is here.

Given the amount of effort that went into the video, I do not think it appropriate to reproduce that material here. You should watch the video for yourself or at least refer to the notes. Instead, I thought it might be useful to examine some actual SD cards and see what can be learned from their various markings:

Let’s start off with an older device. We can see that this is a 4 Gig High Capacity (HC) Micro SD card, with a write speed of 4 MB per second (C4). It has no other attributes specified.

The second example is the popular Samsung EVO, 32 Gig High Capacity (HC) Micro SD card. It has a write speed of 10 MB per second (U1). Sorry, the HC part is just barely legible in the picture, but it is there.

Our last example is the newest device that I own. It has the most attributes, namely: 128 Gig, Extended Capacity (XC), a write speed of 30 MB per second (U3 and V30), a bus speed of 104 MB per second (I) and a basic, level 1 application rating (A1).

Initially, SD media were designed for devices like cameras and other media recorders. That is why earlier specifications placed such emphasis on write speed above all. Lately, we’ve been seeing these devices being used as the non-volatile memory of small computers like the Raspberry Pi. While media recorders typically blast out large amounts of data to one file at a time, applications often read and write to a very large number of smaller files. This usage pattern has resulted in a new emphasis on application performance and the A1 and A2 ratings. A great look at this is also to be found at my favorite source here.

Finally, a disclaimer. I have no relationship with the video blog Explaining Computers, beyond subscribing and being a fan. I receive no recognition or compensation of any kind for this posting. I simply feel that this information is useful and should be made available.

The next time you go shopping for SD memory, it would be a good idea to know what the specifications are and what they mean. It could make the difference between poor or unreliable performance with a slow device or paying too much for performance or features you don’t need.

Your truly

Peter Camilleri (aka Squidly Jones)

Often, Less is Better!

When I was learning Ruby, I was searching for things that could be improved. I was looking for ways I could make things better. One of the areas I was involved in was testing. This should come as no surprise. If you are writing Ruby code, you need to be writing tests. The exact order in which this is done is not my point. Just that tests must be written and run frequently. Here is a typical test run using the minitest facility:

Standard Test Output

To my mind, this was not communicating that true progress of the tests. Consider: What version of minitest was in use? What files were being processed? How many tests were in each of those files? Most of all, why does this output look so boring?

Yes; boring! So being bored I thought: Surely I can do better! I came up with a gem I call minitest_visible to spruce things up. Here’s what its output looks like:

Enhanced Test Output

Much better! Clearer! Nice progress! and so entertaining? Well at least I thought it was a big improvement. It would seem that not many people shared my view. I can see their points. Notice that the bottom line is the same in both cases:

21 runs, 92 assertions, 0 failures, 0 errors, 0 skips

This result line is what counts. These are tests, not video games. They should test the code without a lot of bells and whistles and let you get on with the real work.

I was also told that my little gem did not fit in with the minitest ecosystem. I asked what was meant by this but I never got a reply. I suppose somebody was channeling their inner Linus Torvalds of rudeness that day. I’ll never know. It also does not matter.

I have finally come to realize that the critics were right. The best answer is to keep things as simple and lean as possible. No being fancy; no showing off. To that end I have worked to remove the minitest_visible augmentation from almost all of my work.

Affected gems are: composite_rng, counted_cache, fibonacci_rng, flex_array, format_engine, full_clone, full_dup, fully_freeze, in_array, insouciant, lexical_analyzer, make_gem, mini_erb, mini_readline, mini_term, mysh, parse_queue, pause_output, safe_clone, and safe_dup. The exception is the fOOrth gem experiment that has so many test files that it would be hard to sort out what was happening without a little help. At least for now.

Now these gems can be used by others without the hassle of having to install a non-standard testing extension.

Is less more? I’m not sure. Is less better? Very often, yes it is.

Your truly

Peter Camilleri (aka Squidly Jones)