Wednesday, September 24, 2014

My new Wood LED Clock - Sparkfun Clockit Retrofit

I always enjoy a good project; a chance for me to make something new and work with something new in the process. These days I have several longer-term projects in-progress, so once in a while I enjoy working on something smaller that I can finish in a short time. This time it's my new wood LED clock project.


The Inspiration

First off, this is not a new idea by any means. I've seen these kinds of clocks around before, but hadn't considered making one until now. Recently I came across a website and youtube channel called "I Like To Make Stuff". Besides the fact that this statement perfectly describes me, I can also identify with the host/creator Bob Clagett. He's a father, software developer, and creative DIY'er like myself. Not long ago he posted a video on How to make a wooden digital clock that walks through the process.

The main driver for me was that I already has the most important part... a barebones clock. A few years ago I bought the ClockIt kit from Sparkfun when I was first getting into microcontrollers. I soldered it up, and then it sat on my workbench, mostly unused and ignored ever since. So I figured, why not retrofit this into a wood clock and put it up on my desk at work?

Reworking The Clock

The clock itself had a few issues that would make it difficult to place behind a sheet of veneer. There were a number of components on the circuit board that were too tall to make it work. I was able to remove a couple items completely. I wasn't planning on using the alarm feature, so I removed the buzzer and the alarm on/off switch. Both were easily de-soldered. I just replaced the switch with a wire jumper to simulate the alarm being in the off position. I could have bypassed this in code too, but this was simple enough.

There were also some buttons, a capacitor, and some programming headers on the front of the board that were a bit too tall. I was able to move the buttons and capacitor to the back of the board without much issue. I didn't get the buttons pushed back through the holes all the way, so they're a little ugly, but for my purposes it was fine. I decided to keep the programming headers, but just clip them shorter. In the end, my LED display was the tallest item on the front, and everything left on that side was short enough that I could fit a 1/8" board over them.

Ready for rework



Reprogramming

I won't get into too much detail here, but I also tweaked the programming on the clock a bit. I dug out my AVR programmer, downloaded the source code from Sparkfun's website, made some changes, and used WinAVR to reprogram the clock. The main thing I did was disable the am/pm indicator "dot" on the clock, purely for aesthetic reasons. I also increased the brightness a bit since it would be behind a sheet of veneer. Their code is fairly straightforward, so making these changes didn't take much effort.

UPDATE 10/6/2014 - I've reworked the code a bit more and made my version available at GitHub: https://github.com/benbrandt22/TimeBox

Building the Box

The front face was the most complicated part of the build, but wasn't too bad. I measured up the clock and used CAD to draw up some cutouts that I could use that would hold the clock kit. I printed those templates to paper, transferred them to my 1/8" boards, and cut them out with a jigsaw. I also ended up cutting a couple sheets of veneer to give me the height that I wanted (see photos below):

Paper templates & wood cutouts. Since it is a 12-hour clock, not all the display elements will be lit, so it's shifted slightly to the left so the time will appear centered.

Checking the height of my "faceplate"


The rest of the box was cut out of various sheets of plywood and MDF, and glued together with wood glue:


Once dried, I trimmed down all 4 sides on the table saw to make each side smooth:


Applying the Veneer & Finishing

At this point it wasn't much of a show piece (yet), just a bunch of plywood glued together. I hadn't worked with veneer before, so this was a fun new (and relatively easy) experience. I picked up a pack of maple veneer from the local woodworking store, and a small bottle of contact cement from Home Depot.

Each sheet of veneer was glued on with the contact cement. After drying, I used a power sander to knock down the edges to make them flush with the sides of the box. Once I had all the veneer applied, I gave the whole thing a couple coats of polyurethane for a nice finish. The polyurethane caused one minor issue I hadn't expected; it caused the veneer to warp slightly. This wasn't a problem where it was glued down, but the small rectangular area for the display ended up slightly indented. Eventually it flattened out a little bit, so it's not too noticeable anymore, but it's still not nice and flat like I was going for. Regardless, I think it turned out pretty nice.

I left the bottom open, so I can set the time, and remove the clock kit if necessary. I figure it's fun for people to be able to see what's inside to see how it was done, and knowing me, I'll probably want to make future changes, so it's nice having it accessible. I may add a removable base in the future, but for now I like the simplicity of the box in its current form.

Sanding down the edge of a veneer sheet

Applying contact cement

I masked off the area where the display would be, to avoid getting contact cement on it.

Adding polyurethane

The view from the bottom. Mounted in the back is a panel-mount power jack that runs to the clock inside.


The finished product.




Sql query performance monitoring with EF6 through interception

Lately I've been building a web application against a database that I don't have full control over which is used by a variety of other internal applications. If something were to affect the performance of my app (such as a slow database query) I'd like to know before my users start to complain. To that end, I've built out some very basic always-on production monitoring/instrumentation. For example, I set up a Http Module to monitor response times on all Http requests, and log the ones that fall outside of a given threshold.

I've been using NLog, through the Common.Logging interface to handle this sort of thing. I have NLog configured to email me a log dump whenever an error or warning occurs. If I can just log a warning when a sql query takes too long, the rest of the process (logging, emailing, etc) is taken care of.

When I first started looking into it, I was looking at the new DbContext.Database.Log property in Entity Framework 6. I could set it to any action that takes a string, intercept the messages, and parse out the occasional log message that contained the query execution time. This was admittedly a bit messy, but it worked.

I did a little more research and discovered what I really needed... database interception. In particular, this article laid out a simple example of database interception code. However it didn't show any way to actually measure query execution time. I decided to figure out how the EF logger was doing it. After looking at some stack traces and poking around in JustDecompile, I found the System.Data.Entity.Infrastructure.Interception.DatabaseLogFormatter class. This is the class that actually generates the messages sent through the Database.Log action. It works as a database interceptor, and just implements a simple timer that starts and stops with each SQL command that passes through it. Armed with this information, I had enough to build up a proper sql monitoring class for EF6 that logs slow queries and also sql errors:

Thursday, July 17, 2014

Capturing log messages in the MSTest Unit Test Output with Common.Logging

Lately I've been enjoying the abstraction of a logging facade in my .NET apps, specifically the Common.Logging project. This provides me with a simple, standard interface for logging in my code which I can configure to output to a variety of destinations. Typically I send the logging output through NLog to a combination of outputs (file, email, event log, etc), but the beauty of using a logging facade is that you can change how the log messages are handled without changing your production code.

Today I though it would be nice to see what my code was logging during my unit tests, and I didn't want to dig through a log file to find the log from one specific test. Since the unit test runner is a different executing assembly than my web project, it can have it's own configuration for logging separate from the application. Knowing this, I should be able to set up this new logging behavior for my tests without changing anything in my main project's configuration.

So what makes it possible to log messages from Common.Logging to the standard unit test output?
  • Anything written to Console.Out during a unit test will get captured in the unit test Output.
  • Common.Logging ships with a built-in Console.Out logger adapter that we can use without requiring a larger logging framework.
Knowing these two facts, we can implement this easily in a Unit Test Project:
  1. The code being tested should be doing its logging through the Common.Logging log methods.
  2. Using NuGet, install the Common.Logging package into your unit test project
  3. In the unit test project's App.Config file, add the necessary XML to configure the console logger (See XML snippet below)
  4. Run your unit test(s)
  5. See the log messages captured during each test in your test output:
And of course, let's not forget the code and configuration details:

Thursday, July 10, 2014

Running Visual Studio Tests from a Network Drive

This afternoon I ran into an odd issue with Visual Studio 2013 that ate up an unreasonable amount of my time. I recently set up a new project using the built-in Git source control tools. To keep my project safer I put the repository on my network drive, which gets backed-up regularly. In the future we may get a central server, but for now this is good enough. The code was building and running with no problem until I tried running a unit test. No matter what I did Visual Studio couldn't detect any of my tests. The Test output window said:

------ Discover test started ------
Could not load file or assembly 'file:///U:\Repos\Scheduler\Scheduler\Scheduler.Web.Tests\bin\Debug\Scheduler.Web.Tests.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
========== Discover test finished: 0 found (0:00:00.5040504) ==========

It took some digging, and a few failed attempts at other suggested solutions, but I finally found the workaround:

  • Open a command prompt and type "setx COMPLUS_LoadFromRemoteSources 1"
  • or
  • Create an environment variable named COMPLUS_LoadFromRemoteSources
  • Set the value to 1
  • Restart Studio
Source: https://connect.microsoft.com/VisualStudio/feedback/details/502353/running-unit-tests-from-network-drive

Incidentally, I came across another suggested fix that involved changing a "LoadFromRemoteSources" value in the devenv.exe.config file, but this did not work for me. The Environment Variable did the trick.

Wednesday, July 2, 2014

From Steel Tubing to DIY Monitor Stand

About a month ago I started a new job, developing software for a manufacturing company that makes steel tubing of various shapes and sizes.

So what does a steel tubing manufacturer have an abundance of? Steel tubing. What do they do when they need new shelving, furniture, etc? Open the office supply catalog? Nope... They go to the maintenance department and make their own out of... you guessed it, steel tubing. This is not a knock on the company at all. As a big time DIY guy, I can appreciate this kind of self-sufficiency.

Case and point... this is the desk I inherited, made primarily out of 1" square tubing:


It's been several years since I've been able to work hands-on with metal (I miss the days of having full access to the machine shop at college). So I decided that I wanted to raise up my monitors, and do it myself with steel from the scrap bins. The room next door was being remodeled, and some extra monitor mounts were being taken down from the wall, which I could use in my new setup.

Over the course of a couple weeks, one of my coworkers introduced me to the guys in Maintenance and Quality while I collected, measured, and cut several pieces of sheet steel and square tubing. Our welder helped me weld together a few pieces, and I took care of drilling, cutting, and painting.

What I ended up with was a square tube support across the back, and two adjustable monitor mounts that hung from the bar. With a coat of black Rustoleum, I think it turned out quite nice.




One of my friends from my last job said that he couldn't wait to see all the stuff I would build in my house using steel tubing. While I don't foresee that happening in the near future (especially since I don't own a welder... yet), I have a feeling that this is how it starts. Today a monitor stand, tomorrow the world.

Tuesday, July 1, 2014

Getting Started with LESS CSS in your ASP.Net MVC project

Today one of my coworkers asked me for more information on a CSS preprocessor I had mentioned in one of our weekly meetings. I've been using LESS CSS lately for one of my projects and enjoying it. It simplifies the CSS I have to write, and the language is easy to follow as most of the syntax reads like standard CSS code.

Getting Started with LESS

Here’s the official LESS website that will walk you through how it works:
They have some good documentation and examples to get you started.

This was originally designed to “compile” the CSS in the user's web browser. I prefer to do this before it gets to the client. This offloads some of the work from the client browser, and ensures your CSS will always be generated the same way every time regardless of the client's browser capabilities. This also prevents the chance of making the page “blink” as it converts the LESS to CSS. This is especially applicable to me as my current web application project is running on a "thin client" machine which runs an older browser on a limited processor.

So how do we get from a LESS file to usable CSS? There are a couple ways to generate your CSS from LESS files…

Getting to CSS

The easiest way to get started would be to use the popular Visual Studio extension Web Essentials:
It provides great LESS support in Visual Studio (and lots of other handy features). Every time you save a LESS file, it automatically generates an accompanying CSS file in your project, which you can then reference in your page.

Too many files?

Personally I don’t like managing all the extra CSS files in my project. Part of me worries that my CSS won't always be "in sync" with my LESS file, either from some unseen bug or more likely a mistake I may make. I prefer to let the server automatically generate my CSS on the fly, and cache the generated result. This gets a bit more complex and requires some other packages, but I feel it's worth it.

First, I love the LESS preview function in Web Essentials, but as I mentioned I don't want the CSS files generated. This is easy to disable under Visual Studio's Tools > Options menu. Under Web Essentials > Less, disable "Compile files on save."

I use a NuGet package called dotLess (a .net based LESS compiler):
It handles all requests for .less files and returns the compiled CSS. This way I can put a reference on my page for a .LESS file and the server will return the compiled CSS automatically. The only drawback is that it isn't quite up to date with the LESS spec, so I've run into a few issues with some of the more complicated aspects of the LESS language. Thus far I've been able to work around them so I'm willing the accept the trade off for the convenience it provides.

Bundling & Minification

Generated CSS is great, but it's even better if we can bundle and minify everything to improve the page load time and the overall user experience.

For bundling & minification with dotLess, I use this package:
This gives me a “LessBundle” class that will let me bundle & minify multiple CSS & LESS files. For example, my BundleConfig.cs file in my MVC project has this entry in it:

bundles.Add(new LessBundle("~/Content/styles")
    .Include("~/Content/normalize.css")
    .Include("~/Content/less/Site.less")
);
Now, I can just include a reference to the bundle in my view:
@Styles.Render("~/Content/styles")
In debug mode I get a style tag for each file. The request for the less file will be handled by dotLess
<link href="/Content/normalize.css" rel="stylesheet"></link>
<link href="/Content/less/Site.less" rel="stylesheet"></link>
In Release mode, bundling and minification become enabled, and everything in the LESS Bundle is compiled with dotLess and minified into a single stylesheet link:
<link href="/Content/styles?v=OVSsAe9M_HQdBtQlL5-p9IRWblY32n6g5U4FaGEiUCE1" rel="stylesheet"></link>
More LESS Links: