I've done quite a bit of work with Selenium on and off, mainly for browser automation tests. There are many high quality official libraries for Selenium covering a range of languages. It's an amazing technology and a real joy to work with; however sometimes stuff can go wrong and it's useful to know what's going on under the hood in order to debug where the problem lies.

For this reason I present my very-probably-wrong guide to Selenium.

Gecko, drivers!? What's going on?

There are 3 components in code that interacts with Selenium (ignoring RemoteWebDriver use cases):

1. Your code
2. A driver
3. The browser

For each browser that supports Selenium, the browser vendor provides a "driver". This is usually a small executable (.exe) program tailored for a specific browser:

• Chrome / Chromium
• Firefox
• Edge
• Other drivers available

This driver is the part your code actually interacts with. The driver then communicates with the browser using whatever magic the vendors design. In order to change browsers while using the same code, the drivers expose interfaces/endpoints that implement the WebDriver specification.

Put simply, this means the drivers are a simple RESTful API.

Demo

To demonstrate this I'll use the ChromeDriver version 2.29 which is the latest version at the time of writing. Drivers can only talk to the versions of the browser they are compatible with. In this demo I'm running Chrome on version 58.

Often at work I'll be debugging some incredibly complex logic with lists that can be hundreds, if not thousands, of items long. While the ability to inspect these lists using the normal debugging tools is useful, it gets annoying trying to scroll to the 700th item in a list and then accidentally moving the mouse focus away and having to start again.

For this reason I wanted to look into the possiblity of creating a custom display for certain objects while debugging in Visual Studio. For those of you who have worked with the DataTable you might be familiar with this screen:

This can be accessed by hovering over the object when paused in the debugger and clicking the magnifying glass icon as shown here:

I was recently researching how to read from a COM (Serial) port in order to communicate with an old embedded system. If you're not familiar with them that's one of these:

C# provides the SerialPort class for just this purpose which is hugely helpful. However there's one problem with this class which is that it's just not... very good. I didn't know about this but this post by Ben Voigt should leave you in no doubt that it has some problems.

Setup

In order to test the code on my machine without access to the actual device which was elsewhere, I installed Eltima's Virtual Serial Port Driver which would allow me to test with emulated serial ports. Once I had set up a pair of ports I could send data from one end using PowerShell.

I've not been able to find time to blog at all since starting my new job in March, working at a startup means learning a lot but also working long hours!

Almost a year and a half after first blogging about vNext/.NET core I've finally written my first (almost) functional program in it. I've changed this blog from a horrible mess of PHP to a nice MVC6 site running on an Ubuntu server using .NET core. The nice part is noticeable in the code, the UI still remains a dumpster-fire.

The motivation to finally get a site running using .NET core was from this blog post by Scott Hanselman which shows just how easy it is to get something running on .NET core. I grabbed a very cheap Ubuntu droplet from Digital Ocean and followed along, all development was done on my awful 8 year old laptop running xUbuntu. It's so nice to be able to build C# apps and have them run across platforms.

Another improvement is I have scripted my entire deployment using a shell script, as soon as I'm happy with my changes I can run one script which will build, package, deploy and start the site. No more tedious manual FTP interaction.

The code for the blog is on GitHub so you can see just how badly written it is and probably hack my terrible home-brew security stuff.

I'm still missing a couple of features from the old blog which I was too lazy to port across but hopefully they won't be missed by anyone, if you want them back (code snippets hosted on this site for some older tutorials) let me know in the comments.

In order to learn Linux I'm biting off more than I can chew by trying to learn Elixir at the same time. From the available code editors for Linux I'm using Visual Studio Code.

Visual Studio Code has the ability to configure custom tasks.

To get to the custom task configuration you can use the command palette with Ctrl + Shift + P and type Tasks: Configure Task Runner. This will open "tasks.json". Replace the contents with:

{
    "version": "0.1.0",
    "command": "bash",
    "isShellCommand": true,
    "showOutput": "always",
    "args": [
        "-c"
    ],
    "tasks": [
        {
            "taskName": "Elixir-Test",
            "suppressTaskName": true,
            "isTestCommand": true,
            "args": ["mix test"]
        }
    ]
}

And save the file. Now if you use Ctrl + Shift + T mix will run your tests for the project (assuming you have the mix.exs level folder open) and print the output to the console.

This command could probably be improved by checking that it's executing in the correct folder first but I'm nowhere near confident enough with Bash to write it yet.

Further notes from adventures in Elixir

Function capturing (Capture operator)

This concept took me a little while to get to grips with because I couldn't think of an equivalent from C#.

A typical anonymous function in Elixir might take this form:

square = fn x -> x * x end

You would then call it with the dot "." between the function name and the argument like this: