Mark Gilbert's Blog

Science and technology, served light and fluffy.

3D-Printed Desk Fan Base

I’ve had a desk fan at home for years, but I was never happy with the base.  It was just too deep:


That large ring pushed the fan too far out from the wall, so it was taking up way more room than I thought it should.  The fan’s existing base attached with two screws, which were easily removed:


A little while ago, my brother got a 3D printer, and offered to print stuff for us.  All we needed to do was send him the file.  I decided it was time to try my hand at this, and see if I could come up with a better base.  The printer could handle things up to 5.5” x 5.5” x 5.5”.  That was more than enough to accommodate the height of what I had in mind, but to make the new base stable, I figured it would need to be close to the width of the fan, which was more like 8 inches.  Even if the printer could print something that large, I didn’t want to use that much filament printing a solid block of plastic.  I dug around my junk box, and found these:


These were bendable metal straps that came with a swingset anchor kit, but they were too small to use with our new swingset.  If I turned them up on their edges, though, they could become the legs of the new base.  With that idea in hand, I fired up SketchUp to generate the 3D drawing.  Fast forward 3 hours, and I arrived at this:


I exported this as an STL file, and emailed it to my brother.  Fast forward several hours again, and we get this:


The top is solid.  The bottom has two channels that I hoped would allow me to insert the metal straps:


I started by drilling out two holes that would hopefully match the fan’s base.


They are intentionally offset because I wanted the fan to lean back a little.  Next, I cut a piece of 12-gauge solid copper wire, and bent it into a U-shape:


The holes were just large enough to accommodate the wire, so friction would do most of the work of holding it in place:



Next it was time to insert the new legs.  I bent the metal straps to match the V-shaped bends in the base, and worked them in gently:


I was most worried about pieces of the plastic base snapping off if I pushed it too hard, but it remained solid. Here’s the assembled base:


I re-attached the base to the fan, and bent the wire over to make doubly-sure it wouldn’t pull out accidentally:


The new base didn’t look too bad:


And it was significantly less deep than the original:


I did notice the fan felt like it would fall backward a little too easily now, but another bend to the rear legs solved that:


All in all, a resounding success.  3D printing got a new fan today.


July 4, 2017 Posted by | Maker Life | Comments Off on 3D-Printed Desk Fan Base

Unit-Testing in Unity

CJ and I are collaborating to build an app that teaches you how to solve single-variable algebraic equations like this:

2x – 4 = 16

Our target audiences are kids and teachers, so it was obvious to us that this would be a mobile app.  For me, the choice of development platform was also a no-brainer – Unity:

  • Katherine and I had tinkered with Unity a while ago, so I was already familiar with it
  • It can generate binaries for every platform we’re considering, and then some (XBox or PS4 anyone?)
  • One of the primary programming languages supported was C#
  • Unity integrates with Visual Studio (you can also use MonoDevelop, but if you know and love VS, why?)
  • Unity has a flourishing user community
  • I could get started for free

One of the very first things I figure out with any new development language / platform / IDE is how to build unit-tests with it.  As it turns out, Unity has a built-in test-runner based on NUnit (yet another point of familiarity for me).  The runner is available under the Window menu, but normally I leave it docked on the right side of the IDE.


Now the next step was figure out WHERE my tests should actually live.  After a little digging I found an article on the Unity Test Runner.  The test runner has two modes – Play and Edit.  I started with Edit, and (as the article shows), there was a button for "Created EditMode Test".  I clicked it, and it created a folder called Assets/UnitTests/Editor.  I tried renaming and moving the folders in that string, and kept on eye on the test runner – would it find my test if I put it in a folder called this?.  As it turns out, the "Editor" folder has special meaning for Unity.  I settled on a folder structure of Assets/Editor/UnitTests (inverting what Unity created by default), so I could add other Editor scripts later if I needed.


Now that I had the basic structure, it was time to get down to business, and start writing the logic for the game.  Fast-forward several weeks and 450+ unit tests later, and I have a few observations about unit testing in Unity.

The integration between the Unity IDE and Visual Studio is fairly seamless.  I can add a new test in the latter, switch back to the former (where it kicks off a compilation in the background automatically), and see it appear a second or two later.  In Studio, there is a preset button for attaching to Unity, allowing me to debug through my test and business logic easily.  The one minor quirk is how Unity reports compilation errors – subtly, at the very bottom of the Unity UI:


This stung me a couple of times – I would make some typographical error, miss this clue that my new code wasn’t actually compiling, and re-ran my unit tests expecting a change, only to find that the same test was failing because my new code wasn’t actually being used yet.  To avoid this, I now do an explicit compilation in Studio, and let Studio throw up the errors and warnings I’m used to seeing.

As a whole, the test runner does its job reliably.  One thing I’d change, though, is how it reports the current state of the tests.  If you’ve already run your test suite once, and want to run it again, Unity doesn’t clear all of the green (and red) flags for the already-run tests.  Unless something switches from red to green or vice versa, you really don’t have any indication which test is being run at the moment, how far it is through the suite, etc.  There IS a progress bar that appears while the tests are being executed:


And once that disappears you know it’s done, but I’d prefer the test statuses to be cleared before each run so I can watch it work through the suite again, fresh.

I’ve also noticed that the tests run much faster if you keep the focus on Unity the whole time.  More than once I would kick off a series of tests, and switch to some other window while they ran, and found my tests were still running long beyond when they should have (I’ve seen suites take 2-7 times longer to complete this way).  Again, a relatively easy issue to avoid – don’t switch away from Unity while the tests are running – but an odd one.

Overall, I’m very happy with my choice of Unity.

June 18, 2017 Posted by | Agile, Unity, Visual Studio/.NET | Comments Off on Unit-Testing in Unity

Moving back from the Cloud

Back in August I mentioned moving my critical files to the cloud so I’d have them available from both home and at work.  At the time I selected OneDrive to be my cloud storage provider, and mapped a network drive on both machines so all of my shortcuts would work.

While it solved the problem of losing a very tiny thumbdrive, it introduced some serious lag to Tasks, my custom-written task management app.  Every time I needed to create a new task, update an existing one, or reprioritize the things on my todo list, there was at least 2-3 seconds (and sometimes a lot more) delay in committing that change to OneDrive.  Very soon after I began using OneDrive like this, I started to think through how I could hide more of this lag in the background of Tasks so it would be less noticeable.

Then last week I started getting permission errors from OneDrive.  After some tinkering, I found that I could no longer even drag files into the drive letter I had mapped, or directly modify files through the drive letter, without it complaining about permission issues.  If I did everything through the browser, it was fine, but not through my drive letter.

I spent a night troubleshooting it, and then I pulled out my old thumbdrive as an interim solution.  I went a week like that, hoping that Microsoft would sort out whatever it was they had changed.  This weekend I retested it, and found it was still misbehaving.  I took another look at using Google Drive, but apparently you need some third-party software to map a drive letter to it, so I abandoned that idea.

That’s when I took a hard look at what I had in the cloud, and found that I either didn’t really need access to those files at work, or came up with alternatives (like the occasional email to myself).

Today was my first day 1) not carrying a thumbdrive, and 2) not relying on the cloud for anything relating to my todo list.  To my surprise, I barely noticed the difference.  I felt just as productive, and no longer experienced any of the lag I was seeing with saving things to OneDrive.  I still use Tasks at home, though, but the files are now stored on my local server, rather than in the cloud, so again – no thumbdrive and no lag.

Am I annoyed with OneDrive for ceasing to work?  A little, but being forced to give it up allowed me to ditch the lag at the same time, so I won’t be annoyed for long.

January 30, 2017 Posted by | Tools and Toys | Comments Off on Moving back from the Cloud

Dropping a mic – and picking up another

In the middle of our most recent podcast we had a major technical failure.


The microphone Katherine, Lucy, and I have used for the first 32 podcasts finally gave up the ghost.  To be fair, it had broken a couple of times before, and I had apply liberal amounts of glue to piece it back together.  This time, though, half of the audio tracks Lucy and I recorded had too much static to be usable.

So, we said goodbye to Computer Associates, and hello to Tonor.


This is a Tonor 3.5mm Cardoid Condensor Microphone.  We recorded all of the tracks for Episode 33 with the Tonor, and we think it sounds at least as good.  Let us know what you think!

January 11, 2017 Posted by | Podcast, Tools and Toys | Comments Off on Dropping a mic – and picking up another

Science & Technology Podcast, Episode 33: String Shooter

Mark and Lucy build a machine that shoots string, and lets them play with waves:

January 10, 2017 Posted by | Podcast, Science | Comments Off on Science & Technology Podcast, Episode 33: String Shooter

Science & Technology Podcast, Episode 32: Summoning Thor’s Hammer

Where we build a second prototype of a flying Thor’s Hammer that you can summon:

September 23, 2016 Posted by | Podcast | Comments Off on Science & Technology Podcast, Episode 32: Summoning Thor’s Hammer

Moving to the Cloud

For many years, I’ve carried what you might call my life’s work on a thumb drive.


This 4GB drive held sample code I put together, documents I’d written, all of the data files for Tasks, my personal log – everything.  It was getting backed up every night to the cloud, but the primary source of truth was always this drive.

Then a couple of months ago I got a new laptop at work, mostly because I found myself needing to travel more frequently – whether it was down the hall to a conference call, or out of state for an onsite.  Since this was my primary machine, I would faithfully plug this thumb drive into the side.  However, it would stick out so far I was always afraid I would snag it on something, and bend or otherwise damage it.

So I replaced it with this tiny SanDisk.


My thinking was that it would keep a low-enough profile that I wouldn’t need to worry about it catching on anything.  I wasn’t wrong there, but moving to such a small thumb drive had an unexpected consequence.  I had to pay extra attention to where the thing was when it wasn’t a) plugged into my computer, or b) zipped up in my laptop case.

In other words, it was so tiny I was in danger of losing it every time I put it in my pocket. 

That thought increasingly nagged me.  Then one morning I walked out to my car and it fell out of my pocket when I retrieved my keys.  When I got to the car, I patted my pocket to make sure it was there, and it wasn’t.  I hurriedly retraced my steps, and found it in the garage.  I never even heard it hit the ground because the noise from the garage door opener masked the impact.  I resolved then and there to find a better solution.

I took a long hard look at what was on the drive, and what I actually needed with me:

  • I was keeping several software installers and configuration files on that drive.  Those were easy to move to my home server.  If I actually needed them at work, I could always wait a day, and bring in what I needed the next morning.
  • The next batch of files comprised the bulk of the contents of the drive.  They were files I rarely dipped into, and more times than not was actually at home when I did.  Those also got moved onto my home server.
  • Then there were a handful of files that I would actually need at work.  These were rarely (if ever) needed at work, so those got left on my corporate user’s drive.

Then it came down to the files that I would needed regularly at both home and at work – the files that Tasks required, and my personal log.  I didn’t want to load those onto my phone because then I’d have to keep it jacked into my computer to access them.  I also discarded any "syncing" solution due to my previous bad experiences.

That left me with putting these files in the cloud.  Would it be possible to map a drive letter to a folder somewhere (a requirement to keep Tasks work as is), and let me access them from home or at work?  I looked at both Microsoft’s OneDrive and Google’s Drive, and as it turns out both allow me to map a local drive letter.  I ultimately went with OneDrive since I already had files up there from past projects. 

With these files in the cloud, I had completely weaned myself off of thumb drive.  I could now fire up Tasks at home or at work, and get to all of my project notes.  The biggest downside has been the lag – saving files to the cloud is substantially slower than saving them on my thumb drive.  I’ve started thinking about ways to modify Tasks to do its saving-to-the-cloud in the background, making it more responsive.

I have so far had one occasion where I lost a file update (memories of August 2009 came rushing back – see the links above).  I wasn’t sure what triggered it, but somewhere along the way one of my most critical project files got completely wiped out – a 0-byte was all that remained.  I had a relatively recent update, and only ended up losing a few hours’ worth of work, but as a result, I’ve tweaked my regular backup to pull these files down from OneDrive, nightly.

All in all, the move to the cloud seems to be working fairly well, and it certainly renders the question of "what do I do if I lose my thumb drive?" moot.

August 13, 2016 Posted by | Tools and Toys | Comments Off on Moving to the Cloud

Test-Driven Home Repair

Over the last year, our fluorescent kitchen light was starting to show signs of wear.  Some mornings it would take several minutes to fully turn on.  In January, it started turning on and off on its own.  Then it stopped working altogether.

CJ and I opted for an LED replacement light that had the same footprint as the fluorescent – that way, any unseemly holes or scars that emerged when I took the old light down would at least be covered up when I installed the new one.

Now, does everyone remember what the first step is when working on something electrical?  Make sure you don’t have power running through the lines.

Downstairs I went, to the breaker box.  I had visions of multiple trips up and down, trying to find exactly the right breaker, but incredibly, there was one marked "Kitchen Lt".  I turned it off, and went back up.  I unwrapped the electrical leads to the light – taking care to not touch any of the exposed copper – and tested them.  The indicator light on my tester stayed dark, so that meant no power.  I can proceed, right?

Not so fast.  While I’m relatively comfortable working on the electrical fixtures in my house, I’m also fairly paranoid about it.  After all, I only do something like this maybe twice a year.  How could I tell if the power was REALLY out?

I’d turn the breaker back on, see that the light on my tester actually lit up, turn the breaker off again, and see that it went out.  In other words, test-driven home repair.  I needed to write a failing test – touch the tester to the wires and see the indicator light come up.  Then I would write code to pass that test – turn off the breaker, and the indicator light should go dark.

Another trip the breaker box.  Another trip back upstairs.  Another test of the wires.

The light on my tester was STILL dark.


Do I have a bad tester?  I plugged it into the nearest electrical outlet, and the indicator light came right on.

Um.  Now what? 

With the breaker on, there should be power running through these wires.  Is it possible that I have a break somewhere in the junction box that this light hangs from?  Is there a break in the wires leading from that junction box back to the breaker?  Suddenly, I’m feeling way less confident in my ability to switch out this light.  CJ and I discussed a couple of possibilities, but we decided that if I wasn’t confident enough to finish this job, we’d just have to call in a professional electrician.  I covered up the bare ends (again, taking great care not to touch the copper), and feeling a little dejected and more than a little puzzled.


After a good night’s sleep, CJ figured out the missing piece.  She caught me this morning asked, "You turned off the breaker, but did you…" – and that was all that I needed.  This is a light, Mark.  A kitchen light… with a switch of its own.

Forehead?  Meet wall.

I toggled the power at the breaker, but the light switch on the wall had been off the entire time.  OF COURSE there wouldn’t be any power running through it.

I pulled my tools back up to the kitchen; uncovered the ends; turned on the light switch.  The indicator light on my tester lit right up.  Sigh.  10 minutes later, I had the new light mounted and working*.

While this was another in a long line of "duh" moments for me in the home-improvement space, I was very glad I insisted on getting a failing test before proceeding.  In my day job, not being that disciplined means bugs or bad assumptions can make it through.  When I’m working with 110V, though…

Yeah, you get the picture.


* For the record: 144 LEDs are bright!  CJ says without the cover, the light makes it look like Vegas in our kitchen.  🙂

March 13, 2016 Posted by | Agile | Comments Off on Test-Driven Home Repair

Building Tools

For the better part of a year, I’ve been trying to build a system to capture and analyze data points – on me.  This is part of a long-shot plan to find out what might be contributing to my headaches.  I’m pleased to say that since July of 2015, I’ve been successfully capturing over a dozen data points on myself, multiple times a day.

I started out with the easiest thing that could work: an alarm clock telling me to take a survey every 15 minutes, and a Windows desktop app called iSelfSurvey that saved its data to a text file.


Then, in mid-January, I launched an Android version of iSelfSurvey that allows me to capture data outside of the 7:30-5 that I’m at my computer at work.




Late last year, I also built a companion application called iSelfAnalysis that allows me to upload those data files, and then run a number of functions on the data, looking for patterns.


For example: is there any correlation of the severity of my headaches to the number of hours of sleep that I got the night before?  Is there any correlation to the amount of liquid I’ve been drinking?  How about if my blood sugar takes a dive 4 hours ago – does that affect my headaches now?  I’ve only begun to scratch the surface of the kinds of questions I can ask – and now answer.  I now have the tools in place to run experiments on myself – experiments where I adjust one data point and observe how my headaches react.

Is this system over the top?  Have I spent too much time sharpening my axe?  No.  Asking anyone to answer a dozen questions every 15 minutes is moderately intrusive at best.  Trying to analyze the data by hand would get old after about a day.  This system takes as much of the pain out of this process as I can manage, and makes it far more likely that I’ll continue day after day after day.

I have 127 days’ worth of data collected so far – thousands of data points.  I don’t expect to find any smoking guns, but if I can find ways to minimize my headaches, I’ll consider that a win.

January 30, 2016 Posted by | Science, Tools and Toys | Comments Off on Building Tools

Verifying the new world order

On the iSelf project, I needed to validate that lists of things were being returned in the correct order.  I knew I would have to do this over and over, and the thought of writing tests like this made me cringe:

Assert.Equals(1, ListOfSomeClass[0].SomeProperty, "SomeProperty 0 didn't match");
Assert.Equals(4, ListOfSomeClass[1].SomeProperty, "SomeProperty 1 didn't match");
Assert.Equals(9, ListOfSomeClass[2].SomeProperty, "SomeProperty 2 didn't match"); 

I decided to try my luck creating a generic function that I could pass the test values, the expected values, and a function to evaluate the two lists.  After a few iterations, here is what I came up with:

public void VerifyPropertyValuesInThisOrder<TTestValues, TExpectedValues>(List<TTestValues> ValuesToTest, 
                                      Func<TTestValues, TExpectedValues, Boolean> EvaluationFunction, 
                                      params TExpectedValues[] ExpectedValues)
    if (ValuesToTest == null && ExpectedValues == null) { return; }
    if (ValuesToTest == null) { Assert.Fail("ValuesToTest was null while ExpectedValues was not."); }

    Assert.AreEqual(ExpectedValues.Count(), ValuesToTest.Count, "ValuesToTest and ExpectedValues didn't have the same number");

    for (int i = 0; i < ValuesToTest.Count; i++)
        Assert.IsTrue(EvaluationFunction(ValuesToTest[i], ExpectedValues[i]), 
                        String.Format("Answer[{0}] was wrong.  Expected: '{1}'", 

This allows me to check entire lists of things – either lists of simple values, or properties of more complex objects – with a single call.

this.VerifyPropertyValuesInThisOrder<int, int>(TestValues,
                                               (a, b) => (a == b),
                                               1, 3, 5, 2);


this.VerifyPropertyValuesInThisOrder<TestClass, Boolean>(TestValues,
                                                         (a, b) => (a.BooleanMember == b),
                                                         true, false, false, true);

For most of my tests, the order that the values appeared in the list were important.  However, if you need to verify that all of the expected values appear in the list, without regard to their order, simply sort both lists before you pass them in.

this.VerifyPropertyValuesInThisOrder<int, int>(TestValues.OrderBy(i=>i).ToList(),
                                               (a, b) => (a == b),
                                               1, 2, 3, 5);   

Here is a complete working example program showing VerifyPropertyValuesInThisOrder.  This sample requires NUnit 3.0.1, easily available through NuGet.

January 18, 2016 Posted by | Visual Studio/.NET | Comments Off on Verifying the new world order