Resharper Build and Run

Just a quick shout out for Resharper’s new build and run feature. I’ve become accustomed to Resharper slowing my machine up as it endlessly loads a variety of caches and processes. Speaking as a member of the slower development machine community it is a delight to see a new feature that actually speed things up and increases productivity even on less than optimal machines. Build and run uses some heuristics (i.e. clever workings out) to analyse which projects actually need to be built then only builds these. On first build you don’t notice much of a difference but on subsequent build it makes for dramatic increases of speed. It’s impressive and a real benefit.

I won’t bore too much with my current slow machined troubles but I currently a home based contractor working on a mid range laptop – I anticipated this laptop to be used for some lightweight home development projects. Inside it’s running 2 Visual Studio instances with 35 and 12 projects each respectively. Really it can’t cope – except it suddenly can using Build and Run. 5 minutes build times have become 10 second affairs. It’s not too much to say that it has been a bit of a life (job) saver.

Of course the real solution is to buy a better machine. But as I find myself in a new, more expensive country funds are a little short right now. So until I spring for a new laptop, Resharper Build and Run is keeping me afloat. Thanks guys.

EDIT

I’ve actually now done the decent thing and upgraded my laptop to use a 500GB SSD disc and popped in some extra RAM while I was at it. It runs like a dream. I close down and reopen Visual Studio now just for the fun of it – takes seconds. I still like Resharper Build and Run though, but it’s now less critical to my health and well being.

Getting the Root Directory Path for .Net Core Applications

Quick one. Given any .Net app I want to know the root path of the application i.e. the top level directory. I was doing this with .Net Core but it puts in extra directories by default in the exe path i.e.

bin\Debug\netcoreapp2.0\my.dll

so my normal kuldgy methods weren’t working. This all works for any .Net app not just Core in fairness – it’s just that the extra stuffed in by .Net Core threw me a little. There are all kinds of ways to find this for particular applications web, windows etc.. but this should work generally. Well it worked with my little console app anyway.

The Code

Use reflection to targeting the executable and get the path

var rootDir  = System.Reflection.Assembly.GetExecutingAssembly().CodeBase;

this will get you

file:///c:/development/MyApp/bin/Debug/netcoreapp2.0/myApp.dll

which is the UNC path. Combine with Path.GetDirectoryName i.e.

var rootDir  = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.
GetExecutingAssembly().CodeBase);

this gets

file:\c:\development\MyApp\bin\Debug\netcoreapp2.0

which is a file path now and it has got us the directory of the executable. It’s still not where we want to be so use some regex

(?<!fil)[A-Za-z]:\\+[\S\s]*?(?=\\+bin)

This will chop up the path and gives you

c:\development\MyApp

which is correct.

The Function

So overall a useful function for this could be

public string GetApplicationRoot()
{
 var exePath =   Path.GetDirectoryName(System.Reflection
                   .Assembly.GetExecutingAssembly().CodeBase);
 Regex appPathMatcher=new Regex(@"(?<!fil)[A-Za-z]:\\+[\S\s]*?(?=\\+bin)");
 var appRoot = appPathMatcher.Match(exePath).Value;
 return appRoot;
}

Which does what we need or I quite like it as a (much abused) extension method

public static string ToApplicationPath(this string fileName)
{
 var exePath = Path.GetDirectoryName(System.Reflection
                     .Assembly.GetExecutingAssembly().CodeBase);
 Regex appPathMatcher=new Regex(@"(?<!fil)[A-Za-z]:\\+[\S\s]*?(?=\\+bin)");
 var appRoot = appPathMatcher.Match(exePath).Value;
 return Path.Combine(appRoot, fileName);
}

Which can be called like

“TargetFile.cs”.ToApplicationPath()

Which gives

c:\development\MyApp\TargetFile.cs

Job done.

The Regex

Not everyone likes Regex*. But for the aficionados here is what it is doing

(?<!fil)[A-Za-z]:\\+[\S\s]*?(?=\\+bin)

For example matching this

file:\c:\development\MyApp\bin\Debug\netcoreapp2.0

[A-Za-z]:\\+[\S\s]*?

Is my match – this will match a drive and a path up to

(?=\\+bin)

It’s a lookahead (zero length assertion). It will check for “bin” but not include it in the match

(?<!fil)

It’s a negative lookbehind (zero length assertion again). It will make sure that the letters fil don’t immediately proceed the match. This is to stop e:// being the match i.e. the e from file.

Clearly this assumes that the bin folder is directly under the root path as it normal is. If it isn’t in your app then break out your favourite Regex editor and write your own. It will make a man/woman/scared child of you.

(* Hardly anyone likes it – well I haven’t met many)

Useful Links

https://stackoverflow.com/questions/837488/how-can-i-get-the-applications-path-in-a-net-console-application
Full disclosure – the first bit of this is from this SO question. The extension I did with my very own coding fingers

http://regexstorm.net/tester
Regex storm – C# regex tester. Very good. JavaScript based testers don’t work with this as they can’t do negative lookbehinds.

https://www.regular-expressions.info/lookaround.html
Look ahead, behind and all around with zero length assertions

From Classic ASP to React

I’ve been a software developer for over 16 years. It’s not that long but in terms of software development it’s pretty long time. Perhaps it’s like dog years – 1 development year equals 7 normal person years so actually I’ve been a developer for 112 software dev years. That seems more like it.

Over that time I’ve seen 4 major shifts in web development. Shifts up to new versions happen all the time – this is more where everything you know needs to be put in the bin and you start up again. Seems harsh but that’s the business and if you don’t like it then it’s perhaps time to move on. I’m shifting again to Node.js and React but as I do it’s kind of interesting to look back at the other shifts and how I felt about them at the time and how good they were in retrospect.

Classic ASP

It’s where it all began. Asp files with VBScript and <% %> to poke holes in the html to fit the programming stuff in

<!DOCTYPE html>
<html>
<body>

<%
For i = 0 To 5

 response.write("The number is " & i & "<br>")
Next
%>

</body>
</html>

It’s all about the response.write. I loved it.

Features

Interpreted language – no compilation
Written in scripting language like VBScript or JScript
One file called *.asp. Everything is in there.
One file per page
Lots of use of Response and Request objects. Felt like you were working with the architecture of the web rather than against it
Stateless

How excited was I to use it?

Ecstatically excited. I loved coding in it. Dynamic web pages that could squirt out content for each individual user. Amazing. It was all interpreted – no compilation here – no need for it. I did this for a Masters project and we all loved it. My supervisor was talking about PhDs in it.

Downsides

It wasn’t perfect. The downsides were

Terrible IDE. It was MS InterDev and it was unusable. We all used to code in EditPad Pro which at least had colours.
No structure. You could put COM+ components in to force some structure into it but you would only do this if you really hated your coworkers.
No debugging unless you count writing acres of Response.Writes all over your code
No state management at all. You want to persist the state of a textbox then do it yourself …

which sets the stage for

ASP.Net Web Forms

A proper compiled language with a new framework and new languages to boot .To get a flavour here is the ubiquitous page load event

protected void Page_Load(object sender, EventArgs e)
{
    if (IsPostBack)
    {
        Response.Write("<br>Page has been posted back.");
    }
}

Felt radical at the time.

Features

A compiled language – Wow!
Code behind – split files with markup and code in separate files combined with partial statements
Highly abstracted – managed through page life cycle events
Stateful – Automatic state management through View State

How excited was I to use it?

Passed myself with excitement. I got to build a new server first to host it and I had a big silver machine on my desk making a sound like an aircraft for months. And that was just the start – new language, new IDE that worked, proper code and architecture. Who wouldn’t like all this.

Downsides

The world moved past webforms and while they were good initially, the advent of more client side techniques such as AJAX showed it’s limitations

Worked very badly with JavaScript. WebForms mangled HTML element ids and made it difficult to work with
It was really like windows programming for the web. While hiding the complexity of the web might seem good I’m convinced that webform programming led to a cohort of web developers who really didn’t understand the nature of the web.
Inefficient – lots of postbacks and ViewState (stashing the state of the form to persist it) was massive and came over the wire every time.
Very difficult to unit test. Too many tightly bound dependencies
In the end I hated some of the components. Some were good like ListView and some were made for abuse and torture such as the UpdatePanel. Nest these babies and watch the bad times roll.

Things looked a lot brighter over at the Rails community so we got …..

ASP.Net MVC

Model, View Controllers in the Net world. It was a proper architectural pattern that was fully unit testable. It wasn’t pretending to be windows programming – it was the web and it was proud of it. Clearly still very much used today.

@{ var theMonth = DateTime.Now.Month; }

<p>The numeric value of the current month: @theMonth</p> 

@{ var outsideTemp = 79; var weatherMessage = "Hello, it is " + outsideTemp + " degrees."; }

<p>Today's weather: @weatherMessage</p>

How excited was I to use it?

It wasn’t so much as excited – I was relieved. After fighting against webforms, here was something that worked with you. It was almost back to classic ASP in some ways so I felt like I was coming home.

Features

Skinny controllers, dumb Views and fat models
Clever routing so it wasn’t one file per page any more. That more than anything amazed me
Worked well with dependency injection so was testable
Worked well with JavaScript. Generally felt like the web
Stateless again

Downsides

Honestly I just like MVC and always have done. If pushed I might say

It still posts back so not as responsive as it could be
It’s a different stack to front end so you would need to know C# and JavaScript
It’s easy to write badly – massive Views full of logic aren’t good

But while we weren’t looking Node.js was discovered and we get….

React

Or I could have said Angular or Ember or fill in the blank with your favourite framework. For me, it’s the most radical shift yet because it’s not the Microsoft stack – we’re not in Kansas any more. It’s all in JavaScript, even the server. And while it’s not restricted to the client it’s focus is around ‘reactive’ single page applications (well my focus is anyway).

render() {

return<MasterPage>
 
<Jumbotron>
<h1>Home Page</h1>
</Jumbotron>

<Row>
 <Col lgOffset={1}>
   <Button bsStyle="primary"onClick={() =>this.showMessage('Danger, danger: high voltage')}>Panic</Button>
   <Button bsStyle="primary"onClick={() =>this.showMessage('Calm down, calm down')}>No Panic</Button> 
  </Col>
 </Row>
</MasterPage>;

}

Features

Highly componentised
JavaScript with HTML like syntax embedded in
Single page application (often)
View only .
Blazing fast if on single page app – uses Virtual DOM to only update what it needs to on the page
Back to stateful (if on single page app)

How excited am I to use it?

I feel pretty fortunate to have to opportunity to use this in a commercial setting. I’ve always liked JavaScript and it’s fascinating to see it build out a large scale application. I like Angular for the same reason. So I’m excited once again.

Downsides

It’s not all gravy though. Downsides include

It is a steep learning curve and fast moving so the curve keeps shifting
It’s JavaScript which is great but it’s easy to write terrible JavaScript so terrible React
You’ll need a decent architecture to go with it like Redux – not a disadvantage but you need to be aware of it
It’s just the view so the rest is up to you to (re)invent.

Looking Back and Looking forward

I feel all misty eyed looking back and this is just one aspect of the development I’ve been involved in. There’s ORMs, mobile development, testability, ASP Core, the rise of Dev Ops and on and on and on. Headspinning but great.

What’s next – it’s just so hard to say. I reckon .Net Core will take off, JavaScript will be replaced or transform to something unrecognisable, everyone will decide they hate ORMs and rediscover stored procedures, machine learning will be big, driverless cars will start to fly and we will all go to live on Mars with Elon Musk. Or maybe someone will invent a web framework which combines the best of classic, web forms, mvc and react; perhaps like this ……

The simplicity of classic ASP
The rapid development capabilities of web forms
The testability of MVC
The blazing speed of React

Can someone invent that one please.

Useful Links

https://www.w3schools.com/ASp/asp_examples.asp
Classic ASP examples

https://msdn.microsoft.com/en-us/library/ms178472.aspx
WebForms page management life cycle

https://www.asp.net/mvc
Microsoft site for MVC

https://reactjs.org/
Main page for react from FaceBook this time

Shorter syntax for Node.js module import

I’ve found myself writing a lot of import module statements during React development that I could have shortened. It’s a bit dispiriting when everything above the fold in your code is a boilerplate import. To give an example – this very simple React page

(this demo app is so bland I actually tarted up the image in photoshop – and it’s still bland)

Is constructed from this component

import React from 'react';

var Info = require('./Labels.jsx').Info;
var Warning = require('./Labels.jsx').Warning;
var Danger = require('./Labels.jsx').Danger;

export default class Page1 extends React.Component {
render() {
  return <div>
     <div className="jumbotron">
     <h1>What's up</h1>
     </div>
     <Info />
     <Warning />
     <Danger />
   </div>;
 }
}

Even in this simple example, I’ve a bunch of imports from the same Alerts module. This could potentially go on and on and has done when I’m using something like React-Bootstrap. It’s not pretty. Happily this can all be shortened to one line thus

var {Info, Warning, Danger} = require('./Labels.jsx')

When I first saw this I found it baffling and unexplained – especially when just importing 1 object from a module e.g.

var {Info} = require('./Labels.jsx')

Suddenly there is curly brackets in the way. What’s all that about?

It’s all in the Destructure

It’s using ES6 object destructuring to do this magic. A simple example of object destructuring would be

//.. the object
var o = {p: 42, q: true};

//.. destructuring it into p and q
var {p, q} = o;

// p = 42
// q = true

The first object is automatically split into 2 variable when assigned – this is the destructuring

So our react import is the same as this in essence. Label.jsx is the component (object) we are importing

import React from 'react';

var Info = class extends React.Component {
render() {
   return <div className="alert alert-info">Info</div>;
  }
}

var Warning = class extends React.Component {
render() {
   return <div className="alert alert-warning">Warning</div>;
 }
}

var Danger = class extends React.Component {
render() {
   return <div className="alert alert-danger">Danger</div>;;
 }
}

module.exports = {
Info: Info,
Warning: Warning,
Danger: Danger
}

The export at the end is what is going to be destructured – we could simplify this further and omit the property names (with more ES6)

module.exports = {
Info,
Warning,
Danger
}

Anyway that’s not strictly relevant. Explaining onwards – the require squirts out the object and the destructuring assigns it to 3 variables which we can use in our page

var {Info, Warning, Danger} = require('./Labels.jsx')

This can be rewritten as an ES6 import statement which will transpile down into require with something like Babel if need be.

import {Info, Warning, Danger} from './Labels.jsx'

It’s this form in particular I often see in code samples and the like. So that’s explained then and a little bit of the grey fog has lifted. Lovely.

Useful Links

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment
ES6 Destructuring – good detailed explanation

https://blog.risingstack.com/node-js-at-scale-module-system-commonjs-require/
This is all underpinned by Node.js CommonJS module load pattern – that’s the require bit. More detail above.

https://github.com/timbrownls20/Demo/tree/master/React/CommonJSDemo
The sample code isn’t much but as ever the code is on my GitHub site. It’s using webpack as the task runner which is different to the gulp runner I’ve been using. Probably better if I’m honest.

Only 92% Happy According to Cognitive Services

I’m particularly pleased with the photo of myself on this blog. I normally look a bit odd on photos but this one was taken about 2 days into a new job for an id card. I still had the new job glow. I was relaxed, tousled haired and the future lay ahead bright and clear. I look happy. So I thought I would upload it into Microsoft Cognitive Services Emotion API to get the confirmation that was indeed 100% happy.

I am shocked that even at my most happy I only achieve 92.8% happiness. My British reserve clearly means that I hold back 7% for that neutral stiff upper lip feeling. There are flickers of other emotions with contempt peeking out. Where does that come from ? It’s a new job. Surely contempt should only be registering when I’ve been there a month or two. I uploaded an uncropped image of myself a few months previously and I was registering about 3% fear . The only difference is that the very top of my head was visible that time. I’ve clearly got a very fearful haircut.

Is there a serious point to this? Probably not but it is my first foray into machine learning and as a professional software developer it certainly won’t be the last. I’m pretty fascinated about it. I hope I can start to register 100% happiness when I get into it more. At least 95% – come on!