Using C# .NET for auto-responding to SurveyMonkey surveys

If you need to do auto-responding to SurveyMonkey surveys, you can perchance use the below C# code as a source of inspiration.

I used it for testing a survey that we had running internally. Please bear in mind that your company's SurveyMonkey-subscription might put a cap on the number of survey-responses.

Basically it works by utilizing the Selenium library (download it care of Nuget) for web-page testing. I used the Chrome web-driver because it didn't store cookies or history for the browser session. I also included a unique temporary value for when accessing the survey, or I would get the "you've already responded"-message.

    class Program
    {
        static void Main(string[] args)
        {
            for (int i = 0; i < 58; i++)
            {
                RespondToSurvey();
                Console.WriteLine(i);
            }
        }

        private static void RespondToSurvey()
        {
            OpenQA.Selenium.Chrome.ChromeDriver driver = new OpenQA.Selenium.Chrome.ChromeDriver();

            string baseUrl = $@"https://da.surveymonkey.com/r/?tempValue=" + DateTime.Now.Ticks;

            driver.Navigate().GoToUrl(baseUrl + "/");

            Actions actions = new Actions(driver);
            IWebElement radioBtn = driver.FindElementById("72374030_573987619");
            actions.MoveToElement(radioBtn).Click().Perform();

            var element = driver.FindElement(By.Name("surveyForm"));
            element.Submit();

            driver.Close();
        }
    }

Connecting an ESP8266-12 to a DS1820 thermometer and do a http post data to the internet.

Here's how to connect an ESP8266-12 to a DS1820 thermometer and perform a

Pre-requisites! I'll be using these components:

@ A standard ESP8266-12 on a breakout-board such as the one shown.
@ Three 4.7k resistors.
@ A 3v battery (I use a CR123a) for powering the ESP826612.
@ A DS1820 (i use the DO-92 packaged version below)

The following requirements should be met:

@ All connections, including those on the The ESP 8266-12 on the breakout-board, are solid and conduct power as they should.
@ The battery holds at least 2.8v of power.
@ The ESP8266-12 has been programmed with the following sketch:



#include OneWire.h
#include DallasTemperature.h
#include ESP8266WiFi.h
#include ESP8266WiFiMulti.h
#include ESP8266HTTPClient.h

#define ONEWIRE_PIN 13

OneWire oneWire(ONEWIRE_PIN);
DallasTemperature sensors(&oneWire);

boolean TempSensorAvailable = false;
DeviceAddress TempSensor;
float tempCtry1;
float tempCtry2;

//AP definitions
#define AP_SSID "your wifi-network name here"
#define AP_PASSWORD "wifi password here"

void setup() {

//enable this to test from the arduino serial monitor
Serial.begin(74880);

sensors.begin();

Serial.print("Found ");
Serial.print(sensors.getDeviceCount(), DEC);
Serial.println(" OneWire device(s).");

// report parasite power requirements
Serial.print("Parasite power: ");
if (sensors.isParasitePowerMode()) Serial.println("ON");
else Serial.println("OFF");

if (!sensors.getAddress(TempSensor, 0)) {
Serial.println("No OneWire Device Found");
} else {
TempSensorAvailable = true;
Serial.println("OneWire Device Found");
sensors.setResolution(TempSensor, 12);
}
}

void loop() {

wifiConnect();
postTemperature();

delay(60 * 1000);
}

void postTemperature()
{
sensors.requestTemperatures(); // Get temprature
tempCtry1 = sensors.getTempC(TempSensor); // save temprature
sensors.requestTemperatures(); // Get temprature
tempCtry2 = sensors.getTempC(TempSensor); // save temprature

HTTPClient http;
http.begin("http://");
http.addHeader("Content-Type", "application/json");
String postMessagePart1 = String("{ 'sensorId' : 'L15-Out1', 'temperature' : '");
String postMessagePart2 = String("', 'postAttempts' : '");
String postMessagePart3 = String("', 'batteryVoltage' : '");
String postMessagePart4 = String("' }");
String postMessage = postMessagePart1 + ((tempCtry1+tempCtry2)/2) + postMessagePart2 + retries + postMessagePart3 + vdd + postMessagePart4 ;
int httpCode = http.POST(postMessage);
Serial.print("http result:");
Serial.println(httpCode);

http.writeToStream(&Serial);
http.end();

if ( httpCode != 200 && httpCode != 201)
{
delay(1000);
postTemperature();
}
}

void wifiConnect()
{
Serial.print("Connecting to AP");
WiFi.begin(AP_SSID, AP_PASSWORD);
while (WiFi.status() != WL_CONNECTED) {
delay(1000);
Serial.print(".");
}

Serial.println("");
Serial.println("WiFi connected");
}



Don't forget to import the libraries into the arduino IDE environment.
Given the above is in order, go ahead and connect the components as per the following pictures:



- The RESET and GPIO16 pins should be connected - this enables the ESP 8266-12 to wake up from deep sleep mode.
- The GPIO0 and GPIO2 should be connected to VCC with a 4.7k resistor in the middle. This is to prevent a so-called 'zombie-mode', in which the ESP8266-12 has trouble waking up from deep sleep.
- The data-line and the VCC line of the DS1820 should be joined by a 4.7k resistor, or the temperature will not be read.
- The data-line of the DS1820 should be connected to the GPIO13-pin of the stand-alone ESP8266-12, as this corresponds with the "#define ONEWIRE_PIN 13" statement of the code.


With the ESP connected like so, my ESP8266-12 happily does a http post to my web-service every 60 seconds, before repeating the cycle.

You should put the ESP8266-12 into deep sleep mode if you power your thermometer via battery.

Parallelizing data-processing with the TPL DataFlow library

I highly recommend the TPL - Tasks Parallel Library - 'DataFlow' library. It's a very good abstraction of the TPL itself, easy to use. I was in a situation where I had to parallelize the execution of a file-converter, which in a single instance-run used only 15% CPU. By parallelzing it I was able to utilize 100% CPU and finish the conversion-job much, much quicker.

IT works with .NET 4.5 and onwards, and I believe I saw a .NET Core version, too. But here's the .NET 4.5 version: https://www.nuget.org/packages/Microsoft.Tpl.Dataflow

Install with NuGet and look to the web for examples of use. Note that many of the examples deal with async-awaitable methods, but the library works quite well with synchronous tasks as well. I had no need for async use, so my inspiration-example below is synchronous tasks only:

public void ConvertFilesInFolder(string sourceFilesFolderPath)
{

string[] filePathsAndNames = getFilePathsAndNames(sourceFilesFolderPath);

// define a new 'ActionBlock', that you can push Tasks to.
var block = new ActionBlock(foobar =>
{
ConvertAndMoveTheFile(foo);
}, new ExecutionDataflowBlockOptions
{
MaxDegreeOfParallelism = 6 // 6 simultanous conversions (limit of my 3rd-party conversion library-licence)
});

// Go ahead and add conversion-Tasks to the action-block:
foreach (string filePathAndName in filePathsAndNames)
{
block.SendAsync(filePathAndName);
}

block.Complete(); // that's enough jobs...
block.Completion.Wait(); // ... now go ahead and execute until they're done.

/* Note that as I set the max-degree-of-parallelism to 6, we're limited to this number of executed tasks at the same - parrallel - time. As soon as one task completes, another is retrieved from the action-block 'queque' */
}

public void ConvertAndMoveTheFile(string filePathAndName)
{
try
{
ConvertFile(filePathAndName);
moveOriginalFileToArchive(filePathAndName);
}
catch (Exception ex)
{
// log, but otherwise suppress and move to next.
}
}


I found this blog-post very helpful in getting introduced and started with the library.

Programming an Arduino Pro Mini using Arduino IDE and a FT232RL FTDI USB to TTL Serial Adapter

I've just taken delivery of a couple of Arduino Pro Mini's and want to share how to program them, using the Arduino IDE and a FT232RL FTDI USB to TTL serial adapter.

The Arduino Pro Mini has the same feature-set as the Arduino Uno, for example, but is much, much smaller and doesn't consume the power the other Arduino's do, so it may be used in battery-powered projects or stuff where space is limited.

I'm told there's a 5v and a 3.3v version - I got the 5v ones.

Please refer to the below pictures for how to wire the units up. It's really quite easy, in as much as the pins on the FT232 corresponds exactly to the pins of the Arduino Pro Mini. So I'm simply using 6 female-to-female jumper cables, not even separated:



Remember to set the FT232 to 5v if you're programming the 5v version of the Pro Mini, and 3.3v if you have the 3.3v Pro mini. That's really the only thing that's possible to mess up! The 5v/3.3v setting is made by setting this jumper to its correct position (which should be marked on the board):



Note that the Arduino Pro Mini shouldn't be connected to its' own power source - the FT 232 will deliver the power for now. Now, as you connect the units together via the jumper cables, you may be surprised to note how the Arduino starts blinking red, and furthermore there's a strong red LED that's turned on. Don't be alarmed; at least with my version of the Pro Mini, the red LED simply signifies the unit is powered on, and the blinking red stems from the fact that the unit was pre-programmed with the standard 'blink' sketch - in which the on-board LED blinks once every second.

Fire up the Arduino IDE, and in the 'tools->boards' menu select the 'Arduino Pro or Pro mini' variant. Select the right COM-port and hit 'upload' - that's really should be it.

SOLID principles, in layman's terms: Single Responsibility

Raison d'être: I set out to write about the SOLID software development principles. Specifically, my aim was/is to make these things more understandable to other developers who, much in the way as yours truly, found it troublesome to have to decipher lengthy, complex articles and books on the matter. These principles are for everyone to learn and use, but I found that they were hard to fully grasp; quite possibly because I come from a non-English speaking background. So with this series of articles I'm setting out to try and de-mystify the principles, with only the best intentions in mind. The principles apply to many layers of software development. In my articles, I specifially aim to describe them as they relate to programming. I hope it'll be of use to you. Thank you for stopping by.

This will be a 5 article-series about SOLID. SOLID is all the rage; at least as far as the job-adds I'm reading are concerned; "you are expected to honor the SOLID principles" etc. So what exactly is SOLID about? Plain and simple, it's a set of guide-lines in developing object-oriented systems. They are a group of concepts that have proven themselves valuable for a great many people coding a great many pieces of software. A tale told by your elders in software engineering, if you will, that you will want to pay heed to so you can boast on your CV that you're into the SOLID principles - and you'll be a better developer for knowing them, I promise you that. Heck, you're a better developer for simply _wanting_ to know them!

[S]OLID - The Single Responsibility principle

The Single Responsibility is the first in the set of principles that make out the SOLID acronym. It states that a class should have only one single reason to change. And one reason only.

And why is this a good thing? Because the clutter from having a class do too much stuff is long-term damaging to whatever you're trying to design.

That distinction - "a single reason to change" - is important. The principle is not "a single thing to do"; a class may certainly perform one or more related tasks within the same scope of the class' responsibility. For example, a class which performs logging to a text-file and a database would not be considered breaking the single responsibility principle. If you were to add functionality to log to, say, a central systems management tool, that's not breaking the principle: that class is still only having one reason to change, and you have merely exercised that reason. But if you were to introduce functionality to send a notification on, say, the log-disc being close to full - that's breaking the principle: new stuff to do, unrelated to the primary responsibility.

Below is listed the primary risks involved in not following the principle, as well as the benefits of, well, following it. But first let's go about how to fulfill the principle. It's very simple, really: Go through your classes and look for those that perform two or more different actions. For example: do you have a class that renders an object AND saves it to disk? Not good - the class is clearly having more than 'one reason to change' - it might be a change in the rendering, or a change in the persistence to disc-functionality. Take the below example:

public class Logger
{
    public Logger()
    {
    }

    public void WriteLog(string message)
    {
        // do something to write the message to disk log
    }

    public void GenerateLoggingStatistics()
    {
            // do something to retrieve some stats
    }
}

... which finds us with a Logging-class that writes to a log-file and is capable of generating some logging statistics as well. I'm not familiar with any form of tooling which may aide in this kind of 'single-context search', unfortunately. All I can offer is this, that you'll likely be looking to keeping your classes short. Big classes - my personal, general rule of thumb is 200 lines - marks a danger-sign that the class has too much on its plate. Further to that point, It's not necessarily a danger-sign that you have a multitude of small classes as opposed to a few heavy ones - likely quite the opposite. Keep'em short and lean. In regards to how to facility future changes without breaking the principle, look to hide implementation by interfacing, and there's also the magnificent strategy-pattern to be utilized.

That's it - that's the single responsibility principle, the first of the five. Not so terribly difficult, but then again that's the beauty of the principles, that they're easy to learn but difficult to master. I best saw the adverse of applying the principle described as a 'swiss army-knife class'; if you keep that image in your mind as you traverse your own, you're bound to avoid ending up with exactly those kind of 'do-all' classes. And as an extra positive, classes that are lean and mean are per definition easier to test, easier to read, easier to maintain. And that's what the Single Responsibility principle is all about.

Hope this helps you in your further career. And good luck with it, too!

Buy me a coffee

Running a standalone ESP 8266-12 - and returning from deep sleep

Further to my post on programming a standalone ESP8266-12, this post describes how to actually run the ESP when it's been programmed. Specifically, how to wake it up from deep sleep.

Disclaimer: This post describes the bare neccessities for making the unit run. For production purposes it may be necessary to pull other pins high/low, add capacitors for smoothing out currents, so on and so forth. I came across this post, which suggested the following: "A large capacitor (suggest using 470 uF) across the Vcc to Gnd rails on your breadboard or PCB is a vital ingredient that will minimize reset inducing voltage fluctuations.
A 0.1 uF decoupling capacitor across the ESP8266 Vcc to Gnd inputs very close to the pins (within 1/2 inch). DO NOT SKIP THIS COMPONENT! This cheap yet often overlooked component, when missing, is the root cause of ESP8266 resets."]

Pre-requisites! I'll be using these components:

@ A standard ESP8266-12 on a breakout-board such as the one shown.
@ Two 4.7k resistors.
@ A 3v battery (I use a CR123a) for powering the ESP826612.

The following requirements should be met:

@ All connections, including those on the The ESP 8266-12 on the breakout-board, are solid and conduct power as they should.
@ The battery holds at least 2.8v of power.
@ The ESP8266-12 has been programmed with the following sketch:


// Time to sleep (in seconds):
const int sleepTimeS = 5; // 5 seconds

void setup() {

  delay(2000);                      // Wait for two seconds
  ESP.deepSleep(sleepTimeS * 1000000);
}

// there's nothing in the loop section - all's done in the setup() section.
void loop() {
}




Given the above is in order, go ahead and connect the components as per the following pictures:



- The RESET and GPIO16 pins should be connected - this enables the ESP 8266-12 to wake up from deep sleep mode.
- The GPIO0 and GPIO2 should be connected to VCC with a 4.7k resistor in the middle. This is to prevent a so-called 'zombie-mode', in which the ESP8266-12 has trouble waking up from deep sleep.

With the ESP connected like so, my ESP8266-12 happily resets/wakes up, does nothing for two seconds, then sleeps again for five seconds before repeating the cycle.

If you look to the tiny blue LED situated just below the ESP and the antenna, you will notice it blinking every ~ 7 seconds, to indicate when the ESP comes back to life.



I measure 15 microampere (uA) when in deep sleep. This will keep the unit running for a months on end.

Programming a standalone ESP 8266-12 using Arduino IDE and a FT232RL FTDI USB to TTL Serial Adapter

The ESP 8266-12 won't last long on a batteries; it uses 80 mA per hour. So to use it for last-lasting battery-powered sensors it's necessary to put it in sleep mode and, furthermore, use a stand-alone version without all the development board components. So this post will be about how to program a stand-alone ESP 8266-12.

Pre-requisites! I'll be using these components:

@ A standard ESP8266-12 on a breakout-board such as the one shown.
@ A FT232RL USB to TTL serial adapter, for programming.
@ A 3v battery (I use a CR123a) for powering the ESP826612.
@ The Arduino IDE - I'm using version 1.6.12 for this tutorial.

The following requirements should be met:

@ The FT232RL is recognized by the PC and shows as a virtual COM port.
@ All connections, including those on the The ESP 8266-12 on the breakout-board, are solid and conduct power as they should.
@ The battery holds at least 2.8v of power.
@ The ESP core-libraries have been imported into the Arduino IDE.

Connect the components as per the following pictures:

It's important that the GPIO 0 pin is connected to ground - that's the signal to the ESP8266-12 that it's about to be programmed. I have found it's also important to power the ESP off and then on again before programming it from the Arduino IDE.

Having connected the above, we can move to the Arduino IDE. From the ESP-examples - File=>Examples=>ESP - load a basic sketch. Now head to the 'Tools' menu and ensure the below settings:



Again, remember to do a power-cycle of the ESP 8266-12 before programming it.

Given the above, it should be a simple matter of hitting 'Upload' and the Arduino IDE should program - 'flash' - the ESP8266-12.

Please note that the above it what works for me. Your USB-to-TTL module may be different, your PC may need a different upload speed, so on and so forth. You'll need to experiment a bit - as did I - if the above doesn't work straight away.

In a further blog-post I'll then document how to run the ESP - including bringing it in and out of deep sleep - after having programmed it.

Hope this helps you out!

Buy me a coffee

Why aren't developers better at designing a domain?

Why are developers not better at designing domains?

Given teams in which the responsibility of designing the domain isn't delegated to any individual team-lead or architect, I see it time and time again: solutions implemented with an overt focus on the technical aspects. Faced with a problem the business needs solved, the developer's mindset aptly turns to thoughts on architectural frameworks, methodology styles, immediate speculations of which layer goes in which physical tier, etc. Seldom, in my experience, are the initial notions reserved for modelling the domain.

Be it green-field projects or legacy systems maintenance, I have witnessed developers desperate for domain know-how search left and right for any semblance of a domain model. As they discover none is available, they'll turn to a project manager who'll get the business-knowledge they need to get the job done, or they'll seek out a corporate character and find the info waiting for them here. Yet - given the team without a designated lead-developer or architect - they think of solving only the issues at hand. And when the task has been cleared and the problem thus solved, too often there seems little incentive to anchor that domain knowledge - either by commencing the construction of a domain model, or at the very least documenting the rather valuable information.

And so the domain knowledge isn't shared, rather it stays inside the developers head, to be neglected and forgotten over time, or disappear altogether when jobs are changed.

Given A) teams with no clear leader, B) developers free to prioritize and C) no pressing deadlines to be honored, why - in my experience - does not the developer assume a greater responsibility for modelling the domain to the utmost extend? The merits of which remain unchallenged.

It cannot be a generation gap issue. I have seen it with the junior as well as the senior developer. Nor a gender gap; I have noticed no discernible difference with male vs. female developers. Nor a training bridge too far; most educations and courses offer at the very least a mention of the benefits or domain modelling. 

I suspect one or a combination of the following are at fault (in no particular order):

- With no established lead to follow, few desire to be the first to pick up the mantle, of fear of doing damage to the established work-place structure or etiquette. Building and sustaining a domain model is a joint effort - but how can one be sure the group is up for it?

- There is truly nothing even in lieu of a domain model, which triggers insecurity in starting one to begin with. The "no-one has so far, so why/how/when/where should I?"-issue.

- The developer's ego. We're adept at solving technical problems, and most of our training and wherewithal tends to that - so that's where we desire to shine.

- The perceived tediousness of talking about business issues, when one could be happily coding away.

- The rapid technological shifts. We have to keep track, in order to enhance our prospects
and chances of a fulfilling career, and satisfy our tech-savvy conscience; we invest more in ourselves rather than the workplace.

- Perceived job-security: the subconscious notion of "they can't fire me when I'm the only one who knows about this stuff, so I won't document it".

- Poor knowledge and use of tooling; developing (not designing) an anemic domain model around a set of domain objects, automatically constructing a database and repositories around that and believing that to suffice, as it's easily supported by the developer's tool of choice.

Given even a minor complex domain, I find this to be unacceptable. Shying away from modelling a domain is detrimental to the health of the business, herein failure to sustain business know-how, failure to communicate, failure to become flexible in the face of changes.

I submit that it's never too late to do domain modelling, and further that it's entirely possible to do domain modelling as an afterthought. Certainly it's not ideal, but feasible - and will add value. Though DDD remains my preferred approach, I'm not here advocating it as the sole approach; basically any approach will do, as long as it adheres to the core of the business and, in the end, the reasoning behind applying information technology to enhance it. I propose a "low and slow" means to the end. "Low" as in a single object library, identified from rudimentary traversal of, say, screenshots of an existing application, is definitely fine for starters - as long as it forms the basis of a declaration of intent, i.e. a) it's version controlled for the team to see, b) it's concisely annotated, and c) it's been validated by the business - no meetings required, a simple "let me run this by you real quick" will suffice. "Slow" in as much as it needn't be a huge effort up front, it might be ten minutes here and there, drawing a diagram, validating it, cooking up a basic entity class to represent it. 

To be sure, it requires a bit of discipline, and if you haven't got it, forget it. But if you do, over time - given a few hundred of those aforementioned ten minutes - the domain model will emerge. And you will be adding value. To the business, and to yourself.