Tag Archives: C#

ESP8266 running on batteries

by

If you haven’t yet heard about the ESP8266 then it’s time for you to wake up and get serious! This little beauty is a seriously low-cost WiFi chip with a full TCP/IP stack and microcontroller made by ExpressIf. It sports 16 GPIO pins, SPI, I2C, UART, and even has a 10-bit ADC for good measure. And the price? Less than $2 on AliExpress! It is the size of a coin, and supports b/g/n wireless protocols. What’s not to love about this thing?

Wemos D1 mini ESP8266 Board Supports Shields with a Temperature ...

The device isn’t particularly heavy on electricity to start with, but it can pull as much as 200mA when it’s transmitting over WiFi, and generally around 75mA just being awake.

If you plan on running it on batteries, you’ll soon find that they only last a few days before the thing dies down!

 

Enter Deep Sleep Mode

Luckily, there is a very nice way to help on this. You see, the device has a hibernation mode (among other modes, see the full list here) that allows it to drop to as low as 60 microAmpere, and it is really easy to do it. Here are the relevant bits of code to make it happen (using Arduino Sketch or Visual Studio with VisualMicro extension: 

extern "C" {
#include "user_interface.h"
}

void setup()
{
    initSerial();
    initWifi();
    initSensors();
}

void loop()
{
    // Gather sensor data
    // Transmit sensor data over wifi somewhere

    Serial.println("Entering deep sleep mode");

    auto fiveMinutes = 5 * 60 * 1000000;

    system_deep_sleep(fiveMinutes);
}

At the top, we’re referencing a C-library, which is why it is wrapped in the extern scope. Fail to do this, and it won’t compile due to types being different and other woodoo.

The ESP8266 enters a state where everything is shut off except for the realtime clock to hit the 60µA. After the clock fires up again, the device essencially reboots, running setup() again before entering loop().

NOTE
This does NOT work unless you create a short circuit between GPIO pin 16 and the RESET pin on the device. The clock needs this wire in order to wake itself up after the timer ends. So remember, there is a hardware change included in getting this right!

Diagram

Conclusion

Setting the ESP8266 in deep-sleep mode means that you can start to make battery driven solutions that will last for months instead of days. At an average of 75mA in normal mode, a 2450ma Eneloop would last around 32 hours or less on battery power, but on the same battery, you should be able to expect months (depending on how hard you drive the WIFI and sensor power consumption ofc.) Also remember that the power converters from battery to 3.3v aren’t perfect, giving you at best 85% of stated battery capacity, but all in all, it’s a good and handy thing to know about!

A story about the weather

by

This is the second blog post of my project WaterMyPlants. You can find the first blog post here

Introduction

This time, I just wanted to share a little about the process of going through one task in TFS from the very beginning until the task was pegged “done” – all using BDD and TDD, of course – there is no other way!

image
Image 1: The task for Collecting weather data from api.yr.no is now resolved

Since I am the only developer on this project, and also project owner, the project architect, and project code monkey, my scrum board tends to look like the teeth of a shark. My backlog is wafer-thin, and the user stories often come about AFTER the tasks have been described. Normally, you would have a well-defined backlog of user stories and for each sprint, a set of tasks for every user story planned.

User Story and Scenario

In order to know where to start, I always and without exception define scenarios for the task at hand based on the user story. This time, the story was about collecting wetaher data from an external source – I do not own a weather station, so the next-best thing is to grab the weather from a trusted source: 

The user story

@story62
Feature: There is a component that can retrieve weather information from Yr.no

	As a system developer
	I can obtain information about the local weather from api.yr.no
	So that I can find patterns between plant thirst and outside weather
 
@task61 @performsIO
Scenario: The component retrieves data from api.yr.no based on provided GPS location
	Given that the system has implemented weather retrieval component for Yr.No
	When I ask the system to retrieve weather data for my gps position
	Then the system responds with some arbitrary weather data

Code: User story 62 is about getting weather information from an external source

The tag performsIO needs some explanation: What it does is basically tell SpecFlow to use a runtime configuration prior to running this scenario. I use Structuremap as my IoC container to keep things simple.

[BeforeScenario("performsIO")]
public void BeforeMockedEnpointsScenarios()
{
	ObjectFactory.Initialize(init => init.AddRegistry(new WebRuntimeRegistry()));	
}

I usually have one “real” registry that I provide the applications with, and one registry 
where all the IO performing classes are replaced with mocks.
 

 

Implementing the scenario

All that was left to do was to write the code for each scenario step and “discover” 
my components methods: 
[Given(@"that the system has implemented weather retrieval component for Yr\.No")]
public void GivenThatTheSystemHasImplementedWeatherRetrievalComponentForYr_No()
{
   // No code required for this step
}

[When(@"I ask the system to retrieve weather data for my gps position")]
public void WhenIAskTheSystemToRetrieveWeatherDataForMyGpsPosition()
{
    var collector = ObjectFactory.GetInstance<IWeatherCollector>();            
    var measurement = collector.GetWeather(new GpsLocation());

    ScenarioContext.Current.Set(measurement);
}

[Then(@"the system responds with some arbitrary weather data")]
public void ThenTheSystemRespondsWithSomeArbitraryWeatherData()
{
    var weatherMeasurement = ScenarioContext.Current.Get<WeatherMeasurement>();

   // Inspection…

}

I often write steps that do not require code. This is simply because I deem the scenario text 
to be a first class citizen, and seeing as it promotes understandability of the system, I 
opt for verbosity.
 
The GpsLocation class defaults to use the longitude and latitude of my house, which is why it 
only requires instanciation. 
 
Lastly, the inspection step simply verifies that the values of the weathermeasurement look ok. 
I’ve hidden the implementation details behind the comment “// Inspection”
 
 

The Test Driven part

BDD has now driven forth the need for an IWeatherCollector with the method GetWeather(GpsLocation). Additionally, it also specifies that it the collector needs to return some form of WeatherMeasurement class.

It is time to bring out the SOLID principles from the closet and do some test driven work. I will spare you the code details (do email me if you want them), but here are some of the points that I would like to make:

image
Image 2: Test explorer could use a “document order” sorting option

As you can tell, I am using Roy Osherove’s naming system for my unit tests. Since I see these as micro-specifications, I just love the way these work as fine-grained API documentation for the method I just described. Unfortunately, Visual Studio does not show me the tests in document-order!

This would give the most meaning to anyone looking at the unit-test explorer. A workaroundis to hit the shortcut-key ctrl+m+o between two unit tests in VS2012 to contract all methods:

image
Image 3: Collapsed view of my unit tests using Roy Osherove’s naming convention

Reading the unit-tests in document-order is, in my view, the best way to understand a method.

TDD is also about discovering contracts

Following the SOLID principles of object-oriented design, it quickly became clear during the implementation of  IWeatherCollector that the Single Responsability Principle drove me to use the following contracts: 

image
image
Image 4: Requirements of the WeatherCollector class identified during TDD

Why: The WeatherCollector class is no more than a service class that requests some xml from an external source and then translates that xml into a WeatherMeasurement object. The single responsability of the collector, is simply to combine the result of a reader and pass it along to the proper converter if all looks ok. This could possibly lead to using the name WeatherRepository instead, however, Collector was a term I felt more at ease with. Readability > patterns!

I won’t bother you with the details, but the implementations of the WebReader and Converter followed the same TDD approach – one after the other.

Geen tests lead to green story!

So, with all the specifications (unit-tests) now passing, and no more System.NotImplementedException() I ran SpecFlow to see if I had forgotten anything else:

image
Image 5: All done from SpecFlow. The user story was implemented as specified

General approach: Once you’re done with all the unit-tests for a method, you should run the user story to see if you have forgotten anything else. In my case, I only had one scenario, but I found out twice that I had to implement WebReader and then IConverter<XElement, WebMeasurement>. If you forget one, the SpecFlow report shines in red, telling you that sometihng is not yet implemented.  
– Do you still wonder why I love BDD?

image 
Image 6: Looking at the details of the scenario; the real output from api.yr.no

Conclusion

In this second post, I wanted to share with you how I use BDD and TDD to drive code:

  • Drag the task to “In progress” on your scrum board
  • Find or create the SpecFlow feature file for the user story that the task belongs to
  • Write one or more scenarios required to deliver that single task
  • Implement the scenario steps and drive forth the interfaces, their methods and objects required by the task. One scenario at the time! Do not implement classes yet, just let the interfaces sit until you’re done writing the scenarios.
  • Once done with one scenario, proceed to implementing the interfaces and objects using TDD
    • Create the classes
    • Implement the methods using TDD
    • Discover additional objects and contracts, but do not implement them before you’re done with the method you’re working on.
  • Every time you’re done with the unit-tests for a method, run a complete SpecFlow report and see if you have more scenarios to implement
    • Implement the missing scenarios, one at the time until report is all green
  • On the scrum board, drag your task from “In progress” to done
  • Pick the next task

 

Writing this blog post took me far longer than actually doing the steps above. Without the blog post, I would’ve been done within the hour.

Profectus Est!

by

(It is started!)

Project Water my Plants has begun. This blog post marks the arrival of the first bits of electronics, and provides a simple overview of how the getting started with gadgeteer felt like.

White stripe spider plant
Image 1: The victim: A white stripe spider plant(Chlorophytum comosum ‘Vittatum’)

My box of Gadgeteer devices has arrived. I’ve found a suitable plant to experiment with and all of the software required to get started is now installed in two places (on my desktop and on my laptop (for field experimentation). As you can see from the brown bits, this plant is already suffering, and requires immediate attention of the highest technical quality to survive…

Overview of the project

The project has been set up using Visual Studio 2012 and will be managed by Team foundation Service, which will also function as my source control provider.

 Initial Solution Layout
Figure 1: Overview of project layout

The project structure follows the typical N-layered approach as seen on the image above. Within folder 10.10 (Application/Micro Framework) is where the electronics software are made – the rest of the folders are hosts to the Web page and Web Services. The Specifications folder contains screenshots and some frameworks for running the project in a BDD harness using a combination of SpecFlow and CasperJs 

Getting started with Gadgeteer

DSC_8618
Image 2: The Gadgeteer Moisture sensor half buried in the plant soil

Installing the .Net gadgeteer project was straight forward, except for a couple of things:

  • You should install the entire 4.2 SDK, and then upgrade to 4.3
  • There is a Visual Studio 2012 compatible Core + Templates for Gadgeteer that you need to install once you’re done installing the 4.2 stuff, otherwise, you won’t be able to see the Gadgeteer application project types.

     

    Once installed, creating the project was as easy as adding a new project to the solution, choosing Gadgeteer Application and following the wizard:

    Gadgeteer Wizard
    Image 3: The first page of the wizard asks what type of mainboard you have

    The wizard starts by asking what type of mainboard you have, and then proceeds to create a diagram where the mainboard is visualized. From there, it is as simple as just dragging the components you want from the Toolbox onto the designer, and connecting them by clicking on the gates and drawing a line:

    Gadgeteer Designer in VS2012
    Image 4: Using the designer tool to drag the components and connect them to the board

    Auto-generated code

    Every time you save the designer, the auto-generated partial class Program is updated with the new components and port assignments. The generated code is clean and easy to understand. No cluttering or cryptic names here. The module names are default the same as the module type.

    OGadgeteer Designer Generated Code
    Image 5: Designer-generated code

    • Measure My Plant

    The first batch of electronics to arrive were needed for my first application, MeasureMyPlant.exe which is a device application that is going to do two things:

    1. Take readings of the environment that the plant is in (moisture, light, temperature)
    2. Transmit data over wifi to a cloud service in Azure

     

    Only part 1 was done in this stage, because I waited with the more expensive WiFi component to get a cheap proof of concept going. It turns out that I should’ve ordered everything at once. The electronics simply worked! Within 5 minutes of typing, I had the following program running on the Hydra board:

    MyFirstProgram
    Image 6: My first running program on the hydra board

    Time to order some more stuff!

    I will now proceed with some of the more expensive modules. While I await the arrival of these, I will be working on the website. There may be a blogpost or two about that soon…

    For now, a few more images of the protagonists of this blog post:

    DSC_8625
    Image 7: The modules used in this blog (click for larger image)

    DSC_8620_Snapseed
    Image 8: My Fez Hydra mainboard with all the connection ports(click for larger image)

    Structuremap: Singleton class with multiple interfaces

    by

    In a recent project, I had the need to implement multiple interfaces in a single Repository class

    public class UsageStatisticsRepository : DbContext, IApiKeyCounter, IIpAddresssCounter
    {
            // …
    }

    We use Structuremap as our IoC container, and attempting to configure the two interfaces as Singletons gave us two instances (naturally), once for each interface.

    The solution, was to use the not-so-obvious keyword Forward in order to re-use the Singleton instance for another interface as so: 

    public class DigitalDiasRegistry : Registry
{
    public DigitalDiasRegistry()
    {
        For<IApiKeyCounter>().Singleton().Use<UsageStatisticsRepository>();
        Forward<IApiKeyCounter, IIpAddressValidator>();
    }
}

     

    With that, the problem was solved, and only one instance occured. Since I fiddled some time to figure this out, I thought sharing it would help someone else.

    Hett smilefjes

    Using Structuremap to resolve ViewModels

    by

    One of the things I find myself doing over and over again when working in xaml-based applications is to create a ViewModelFactory based on Jeremy D. Miller’s StructureMap.

    All my ViewModel classes are based on a class BaseViewModel:

        public class BaseViewModel : INotifyPropertyChanged

    The fun, of course, begins when your viewmodels need to know about other viewmodels. Lets say, for instance that your main view contains a Container control in which you would like to swap views in. Using structuremap, it is easy to inherit the Registry class in order to stitch together associations between views and models:

    public class ViewModelsRegistry : Registry
{
    public ViewModelsRegistry()
    {
        Rig<MainWindowView, MainVindowViewModel>(Registered.MainWindow);
        Rig<TrioEventsView, TrioEventsViewModel>(Registered.TrioEvents);
        Rig<NewsContentView, NewsContentViewModel>(Registered.NewsContent);
    }

    private void Rig<TControl, TViewModel>(Registered name) 
        where  TControl : ContentControl where TViewModel : BaseViewModel
    {
        For<ContentControl>().Singleton().Use<TControl>().Named(name.ToString());
        For<BaseViewModel>().Singleton().Use<TViewModel>().Named(name.ToString());
    }
}
     

    The Registered reference is an enum that I use to keep tabs on what views/viewmodels that are implemented:

        public enum Registered
            {
            Unknown = 0,
            MainWindow,
            TrioEvents,
            NewsContent,
            Locations
        }

    As you can tell, the ViewModelsRegistry uses ContentControl as it’s container type. This makes it  compatible with all derivates, including Window and UserControl.
    Following the factory pattern, the result follows:

    public static class ViewModelFactory
{
    public static void Initialize(Registry registry)
    {
        ObjectFactory.Configure(o => o.AddRegistry(registry));            
    }

    public static ContentControl Get(Registered name)
    {
        var control = ObjectFactory.GetNamedInstance<ContentControl>(name.ToString());
        control.Loaded += (s, e) => {
            control.DataContext = GetDataContextFor(name);
        };
        return control;
    }

    public static BaseViewModel GetDataContextFor(Registered name)
    {
        return ObjectFactory.GetNamedInstance<BaseViewModel>(name.ToString());
    }
}

     

    The ViewModelFactory basically leans on structuremap providing the method Get() that stitches together a view and it’s model. One example of such use:

     

            public void LoadEvents(object dummy)
        {
            SetViewModel(Registered.TrioEvents);
        }

        private void SetViewModel(Registered name)
        {
            if(!_loadedControls.ContainsKey(name))
                _loadedControls.Add(name, ViewModelFactory.Get(name));
                
            CurrentContent = _loadedControls[name];
        }

    In the above snippet, taken from the MainWindowViewModel,  LoadEvents is bound to a button click on the Main Window. Once clicked, If I haven’t already loaded the control, I use the factory.Get() method to create a UserControl with initalized datacontext, before I finally set the ContentPresenter (CurrentContent) on the Main window viewmodel.

    The factory can easilly be expanded to swap out datacontexts, provide different views. This blog post is mainly about using structuremap to make it happen.

    Jeg bare tøyser

     

    Running CasperJs scripts from a C# console app

    by

    I recently came across the need to write a console application that can take a CasperJs script (or folder) and run it with console output on. I wanted to make this tool in order to integrate it with Visual Studio External tools, so that whenever I am editing a casperJs script, I can hit my keyboard shortcut to verify that all is ok.

    Doing this in C# is mostly straightforward:

    • You recieve the CasperJs file or folder to run as an argument to your console app
    • Inspect the environment variables to find:
      • Where Python is installed (by inspecting your path variable)
      • Where CasperJs is installed
    • You start a Process.Process() and provide it with enough details to run the script

     

    Challenge: Output

    The tricky bit, is to grab the output, and display it in your own app. Here’s my go at it: 

    private static void ExecutePythonScript(DirectoryInfo workingDir, FileInfo pythonPath, 
    string casperArguments)
{
    var p                              = new Process();
    p.StartInfo.WorkingDirectory       = workingDir.FullName;
    p.StartInfo.FileName               = pythonPath.FullName;
    p.StartInfo.Arguments              = casperArguments;
    p.StartInfo.UseShellExecute        = false;
    p.StartInfo.CreateNoWindow           = true;
    p.StartInfo.RedirectStandardError  = true;
    p.StartInfo.RedirectStandardInput  = true;
    p.StartInfo.RedirectStandardOutput = true;

    p.ErrorDataReceived += (s, e) => {
        if (!string.IsNullOrEmpty(e.Data))
            Console.WriteLine("e> " + e.Data);
    };

    p.OutputDataReceived += (s, e) => {
        if (!string.IsNullOrEmpty(e.Data))
            Console.WriteLine("->" + e.Data);
    };

    p.Start();
        p.BeginOutputReadLine();
        p.BeginErrorReadLine();
        p.WaitForExit();
    p.Close();
}

     

    The tricky bit to figure out was that after you start the processs (p.Start()), you need to call the asynchronous methods BeginOutputReadLine() and BeginErrorReadLine(), otherwise, events will never be posted. Sarching the internet for invoking processes did not include this little gem, hence this post.

    Happy coding!

    Jeg bare tøyser

    A good basis for unit testing

    by

    Over time, one developers techniques and habits that “just work”. In this post, I would like to share with you a set of base classes that I’ve been using and refining over time. They make my Unit Test writing a little more efficient and easy on the eyes.

    The base of the base

    I often start a new software project by setting up some form of base unit test class with functionality that I know I will be using, such as using embedded resource documents, various kinds of verifiers, test names etc. I usually name this class “BaseUnitTest”. This blog post will not be focussing on this base of bases, but to give you an idea, this is roughly how it starts out. 

    public class BaseUnitTest
{
    private Assembly _testAssembly;
    public EmbeddedResourceManger ResourceManager { get; internal set; }
    public IoVerificationManager IoVerifier { get; internal set; }

    public BaseUnitTest ()
    {
        _testAssembly = Assembly.GetCallingAssembly();
        ResourceManager = new EmbeddedResourceManger(_testAssembly);

        IoVerifier = new IoVerificationManager();
    }
}

    I usually add on methods to this class in the form of Verfiers of different sorts. A handy base class for your Unit  Tests is not the scope of this blog though…

    Wrapping AutoMocking and Instance creation with BasedOn<T>

    Now follows the real nugget. A base class for your unit tests that uses StuctureMap’s AutoMocker to construct a nice, testable innstance of the class under test.

    [TestClass]
public abstract class BasedOn<TInstance> : BaseUnitTest where TInstance : class
{
    public MoqAutoMocker<TInstance> AutoMocker { get; internal set; }
    public TInstance Instance { get; internal set; }

    [TestInitialize]
    public void RunBeforeEachTest() 
    {
        AutoMocker = new MoqAutoMocker<TInstance>();

        OverrideMocks();

        Instance = AutoMocker.ClassUnderTest;

        ExecuteBeforeEachTest();
    }

    public Mock<TInterface> GetMockFor<TInterface>() where TInterface : class
    {
        return Mock.Get(AutoMocker.Get<TInterface>());
    }

    /// <summary>
    /// Use this from your OverrideMocks() method so that all replacements are made before
    /// the Instance is created
    /// </summary>
    public void Replace<TInterface>(TInterface with) where TInterface: class
    {
        AutoMocker.Inject<TInterface>(with);
    }

    public virtual void OverrideMocks()
    {
    }

    public virtual void ExecuteBeforeEachTest()
    {
    }
}

    How it works

    The BasedOn<T> class defines an AutoMocker for the class that will be tested as well as a member named ‘Instance’ that is used in the unit tests. The method RunBeforeEachTest() is attributed with [TestInialize] so that it will execute prior to each unit test.

    Note: Because this attribute is used in the baseclass, you cannot re-attribute any method in your derived unit test class. That is why there is a method named ExecuteBeforeEachTest() that you can override to accomodate your Unit testing needs.

    If you need to prepare a special Mock or stub into the class you are testing, you can override the method OverrideMocks() in your unit test class – this method is executed just before the Instance member is created. The method Replace<T>(T with) is meant to be used for this very purpose.

    Example of use

    The class PersonManager is a business layer service that handles Person objects. In the following example, we are setting up a Unit test to ensure that person objects that do not have surnames cannot be updated. Using the BasedOn<T> base class: 

    [TestClass]
public class PersonManagerTests : BasedOn<PersonManager>
{
    [TestMethod]
    public void UpdatePerson_PersonHasNoLastName_DoesNotInvokeRepositoryUpdate()
    {
        // Arrange
        var testPerson = new Person();

        // Act
        Instance.UpdatePerson(testPerson);

        // Assert
        var repoMock = GetMockFor<IPersonRepository>();
        repoMock.Verify(o => o.Update(testPerson), Times.Never());
    }
}

In the next example, I am preparing the repository to throw an exception to verify
    that an exception uses the logger interface:
     
    [TestMethod]
public void Create_RepositoryThrowsException_ErrorMessageIsLogged()
{
    // Arrange
    var somePerson       = new Person();
    string exceptionText = "Something really bad just happened";
    var someException    = new Exception(exceptionText);
    var repoMock         = GetMockFor<IPersonRepository>();

    repoMock.Setup(o => o.Create(somePerson)).Throws(someException);

    // Act
    Instance.Create(somePerson);

    // Assert
    var loggerMock = GetMockFor<ILogger>();
    loggerMock.Verify(o => o.LogException(exceptionText), Times.Once());
}

     

    The magic performed by AutoMocker combined with a relatively simple base class has helped me immensly in making my tests more readable – and for others to read! At the time of this writing, AutoMocker supports Moq, Castle, and TypeMock.

    For those classes that you do not want automocked, you can always bypass the BasedOn<T> class and inherit the BaseUnitTest directly for access to the test helper methods and verifiers.

    Smilefjes