Prototyping with scriptcs and building in Nancy

I had a project brief to work with an API the other day at work and it wasn’t one I was familiar with. Looking at the documentation for it I knew I wanted to hit some of the endpoints, get the responses and analyse the data before I dived in and started writing anything. I am a NancyFx convert, I like how easy it is to build any kind of web/HTTP based application. The speed and lightweight feel of it just sits well with me. However in this instance I want to dive into making API requests even faster than opening Visual Studio, picking a NancyFX template and creating some routes to return data from the API via my browser.

So how to do it?

I happened to go into the scriptcs session at the NDC London conference done by one of the founding fathers Glenn Block. Could I use this?

Well the answer is yes I could and it was great fun into the bargain! I won’t go through how to install it, how cool Chocolatey is (it really is) as the guide on the site will do a better job.

Yes, you have to know your way round what is in what namespace and get the right using statements (I have Notepad++ as my text editor, there is a plugin for scriptcs, which helps but doesn’t seem to bring in usings, I know there is a plugin for SublimeText maybe it is better? If so I would love to hear from you!). Personally I see this as a challenge to my own knowledge of the framework and part of my continued learning. Anyway it was nice to be able to jump into prototyping the API calls and seeing results quickly in the command line.

I put the following code into my text editor (removing the api key and location of the saved file on my machine) and saved it as ProjectsBoards.csx:

#r "Newtonsoft.Json.dll"

using System.Net;
using System.Collections.Specialized;
using System.IO;
using Newtonsoft.Json;

using (var client = new WebClient())
var data = new NameValueCollection();
client.Headers.Add("apikey", "<APIKeyValue>");

var response = client.UploadValues("", "POST", data);
var responseString = Encoding.Default.GetString(response);
File.WriteAllText(@"<filelocation>\projects-and-boards.json", responseString);

To run this script (after installing scriptcs obviously), you open a command prompt navigate to the directory you save your file and type:

scriptcs ProjectsBoards.csx

Alternatively you could give the scriptcs command the full path to your script file.

Now I have a JSON file I can look at, analyse and determine how I can use it in my application. I can parametrise the script and pass in the API endpoint and file name of where I want the data to be saved.

#r "Newtonsoft.Json.dll"

using System.Net;
using System.Collections.Specialized;
using System.IO;
using Newtonsoft.Json;

using (var client = new WebClient())
var data = new NameValueCollection();
client.Headers.Add("apikey", "enter api key");

var response = client.UploadValues(Env.ScriptArgs[0], "POST", data);
var responseString = Encoding.Default.GetString(response);
File.WriteAllText(@Env.ScriptArgs[1], responseString);

I can call this script as follows:

scriptcs Parameterised.csx -- path\to\file

Now I can hit any endpoint and write a file out with the results (reusable!). I passed each result into to generate POCOs for use in the Nancy application.

I then switched into Visual Studio and created my project using the Nancy application template with ASP.NET hosting and Razor with the knowledge of what data I was working with and some POCOs to start me off. Also performing this rapid prototyping with scriptcs had got me to consider that the API call needs parametrising in my application and encapsulating correctly. I can also quickly try out optional parameters on the API calls without having to change my application and roll it back if I am not happy with the results.

By using this approach I haven’t created an application I then scrapped or refactored once I knew more about the 3rd party API I was using. Plus it was good fun to use something new and see if it improved the overall development experience.


One of the problems with estimation is it is a “best guess”.  At the initial conception of the project we know the least about the requirements, solution and possibly even the platform or language we are using. So we use past experience and gut feeling to decide how long we think it will take to develop the application. If we are concientious then we will probably use a best, likely, worst case estimate and be honest towards which end of the scale it is going to be. Remember it is an “estimate” not a definite deadline.
Other professions over estimate and complete early based on estimate, we recently had some wardrobes fitted and the company doing it told us to expect it to take 2 days, so we could plan to leave our room in a state they could work in for that period. Upon starting the work i asked the fitter about this and he said

They always book us for 2 days, but it only ever takes 1 and a half at most

Surely this is just good practice, the fitter is able to spend more time if he hits a snag and the customer/client is not misled or disappointed. They have estimated on the worst case and allocated this time accordingly.

Does this happen in the software industry on the whole? Please feel free to comment on your own experiences.

Time served to be a Senior

With great power comes great responsibility – Stan Lee, Marvel Comics

Can you become a senior or lead based just on talent?

I used to think that you needed to follow a progression over time, moving from one level to the next, spending a considerable period of time at each. Almost like any apprenticeship, you start out shadowing someone more senior, learning off them and being given small tasks. You then progress to being given more responsibility for owning and delivering projects for the company you work for. At some point you are given the chance to lead the way and have people guided by you, you make the decisions, more junior members look to you for help and advice.
Perhaps narrowed minded in my thinking “fast tracking” through the stages never really occurred to me till someone I have worked with mentioned my equivalent at another Manchester agency was in his early 20s and was an outstanding developer.

Do you need experience?

Designing and architecting software can be done using knowledge and talent for principles, patterns and chosen language or framework, however experience gives you the benefit of drawing on past failures. It also allows you to mentor others by providing a wealth of real life examples to back up your theory.

It isn’t a right of passage to achieve seniority

Seniority shouldn’t just be a “time served” reward, clear goals and achievements need to be formed to allow people to know what the company you work requires of you at the next level. Experience, application to your craft, responsibility for your work and team, coupled with a passion to expand your technical knowledge in my mind mean there should be no boundaries to the progression of your career. Working for a company for 10+ years and knowing a couple of legacy systems inside out is not enough for me.

So master your craft, lead your team to quality and innovative solutions and it doesn’t matter how old you are. Oh and maybe admit now and again you were mistaken about something!

Patterns and Practices or use your brain?

There was a time when i thought you needed to use patterns and best practices to keep consistent and maintainable code. After all if everyone follows them then we are all building software in a similar way. New and existing team members and freelancers can all understand the code and maintain it. Problem solved, blog post over.

However do you end up forcing a pattern into an architecture for the sake of it? This could lead you to not build the best solution for the problem, but the solution with the best use of several patterns. Could your code be simpler and more maintainable without using the patterns?

Best practice treated like a magic bullet.
By applying “best practices” you limit the chances of failing from a certain point of view, but does it stop you thinking and using your brain? One of the many things I learnt working with @grumpydev was that if you use common sense and engage your brain then your code will more than likely be maintainable and others will understand what you are trying to achieve. Also when you come back to that code that you haven’t seen for months does applying common sense and engaging your brain mean you understand your own code easily.

Principles over patterns.
Patterns can be useful, but it depends on context. Just because the pattern worked in one instance does not mean it will always work for the code you are writing. Principles however should when applied well, assist you in writing quality code. My wife bakes cakes as one of many jobs she does (shameless plug – @itcakestwobaby) and started out using a recipe for cupcakes. It describes everything you need to do to make cupcakes just like her. Does this mean anyone can make them like her? Maybe…however I have watched her and she doesn’t stick to the recipe, it is all her own judgement from experience and knowing her ingredients and our oven. I don’t think you can add a spoonful of factory pattern and a dash of decorator pattern and create a perfect solution by keeping to them.

Jedi mind tricks or cardboard cut out?

I was sat with a developer in my team the other day. He was trying to put some functionality into an existing site. Impressively he had drawn out the flow and logic for the problem so it was all laid out in front of us. He described several ways of handling the GET and POST requests needed to implement what he had in mind. The stumbling block was that he didn’t like the solution that seemed the clearest and most simple. It seemed too simple, to the point where it felt like there must be something wrong with it. Thanks to the diagram and his description of the solution I couldn’t see any better way of doing it. I spoke relatively little and asked why he thought his solution was flawed?

After a few minutes we both agreed he had the answer, at this point he was convinced I had told him the solution and how to implement it. The truth is I hadn’t, he had it all along. He just needed to be convinced that he wasn’t missing something and that simple can be right.

I told him he had solved it, it was all his work, I just listened and asked a couple of questions.

No, you just did some kind of Jedi mind trick on me to make me think it was my idea.

A developer I used to work with called it the “cardboard cutout”, the person you are helping talks to you, you either just listen or ask the odd question. This usually flushes out any issues and helps arrive at the best solution. No mind tricks, no persuasion, nothing but a few minutes of geeky goodness.

We are using this technique more and more to work together, improving the understanding and quality of what we are building.

Needing to know the basics – part 2

In part 1 I looked at my early career and the lessons learned by having to know what was happening in my code and others in order to understand bugs and build upon existing features. In part 2 I intend to look at more specific examples of using tools and how not knowing what is happening can affect a developer’s ability to do their job.

I have been called over by a more junior member of the development team in several of my past jobs to help them with a problem. Usually it is with a piece of legacy code written in ASP or PHP, they have made a change and it has broken something. “I have made this change and now it has stopped working…i need to debug it” Now at this point if it is ASP we could attach the debugger ( and step through the code after some tinkering. Or we drop in a Response.Write or two and hit refresh in the browser. Mostly you can get to the bottom of it fairly quickly without any extra tooling, just remember to take those write statements out before you deploy!

Another instance of knowing what is going on can arise from occasions where developers have used one of two things. Either the (horrible) Visual Studio toolbox to drag and drop a whole set of controls onto a page or when someone is using an ORM to do their database modelling.

VS Toolbox

This approach can help the “bedroom” or newbie developer to get things up and running with no hassle (if you want no hassle development and efficiency of getting things up and running, check out NancyFx) or need to write their own code. Great you might think, I have a login form or set of pages to do CRUD operations on my data and I didn’t have to write anything! What happens if you need to extend it or debug it, maybe someone else needs to style it or write some client side code against it, is it secure, does it perform well? With some digging into the auto generated code and what is being called lower down the stack and in the database you can find out the answers. However then you have just defeated the object of using some “tools” to get you to a place quickly without having to write code.


In my career so far i have done pretty much every approach to persist and read data into and from a database, SQL commands/parameters, stored procedures, views, datasets, data tables and database first, code first and dynamic style modelling using an ORM. I have had several Twitter conversations with @JohnnoNolan and @FranHoey around the potential for a dying breed of developers who can write and understand SQL. I have also spoken to people I have worked with about cracking open the Profiler and seeing what their LINQ or similar is actually doing.

Mapping database fields and values to POCOs is great and can allow middle-ware and UI development to be done without having a dependency on a particular data source. However if this source is from a database, are these queries performing as well as they could? Are you going to incur the wrath of a DBA somewhere?

At the end of the days tools are brilliant, but it is useful to know the basics, then you can extend what the tools are giving you. You can also help solve that tricky bug and gain the plaudits of your ever so grateful colleagues!

Needing to know the basics – part 1

At present we are in a great era of tools and resources to help us as developers achieve the goals of our projects whether they are work based, private or for the hell of it. We have editors, IDEs, code pens, validators, browser add-ons, frameworks and boilerplate libraries at our disposal. They give us ways of speeding up development, making it more efficient and just get the “boring” stuff done for us.

However it wasn’t always this way, when I first started out as a fresh faced graduate seeking to earn a living as a developer I was using ASP (why is it called Classic ASP? ASP.NET is .NET, if I say ASP to someone i haven’t had anyone of them mistake what i am talking about for .NET). I was writing ASP using VBScript, supplementing that with HTML/CSS and JavaScript. All of this was going on in Notepad and Macromedia Dreamweaver, a local IIS 5 install and a whole lot of trial and error!

If something went wrong with the server side code, you got most of the time a less than helpful error message, which meant you needed to debug it. So you found the area of the code that seem to be causing the trouble and started writing values to the page to see what was going on. Issue with the front end code? Open the page source and look at what was rendered, hop back to Dreamweaver and change it, back to the browser and hit refresh with everything crossed.

What did this teach me? It taught me to try and get things right first time, build small parts to test, test thoroughly when i made a change and most of all have a great deal of patience. It also gave me an appreciation for knowing what is going on in my code and why it was breaking. I had no tools to model my database, default my styles out across browsers, show me what properties are on my objects and make sure i hadn’t made a typo somewhere. I only found out once i started testing it in a browser.

I have encountered a few people over the years who love their tools and can use them very well, I love tools too and use them every day. However these few have found it very strange that i need to know what is happening in my code to a level that they take for granted because of a debugger here and an ORM there. Now like i said i love tools, the Visual Studio debugger is very powerful as are the Immediate window and ability to change values on the fly. They save time, they give you a way to poke around inside an application and understand it. Could i work without them at all and be nearly as effective though?

I would like to think that i could, i often practice it (with varying degrees of success!) when developing. Almost like a challenge to stand on my own and see how i cope.

In the next post, part 2 of this I look at more specific examples of needing to know what is happening “under the hood”.

I’ve finally done it

After 3 years of University (where blogging was yet to be mainstream) and 12 years of working my way through the developer ranks i have finally got myself a blog and queued up some topics to write about.

Several of my colleagues and ex-colleagues (some i even count as friends!) blog fairly regularly, after reading their offerings and discussing them with the authors it persuaded me to start to.

So here we go, i have topics ready that need writing up, i am not bothered if i have a readership of 1 (me) or more, it is more about an outlet for my thoughts than to gain any kind of acclaim or recognition.

If you are reading this i hope you enjoy reading as much as i am hoping to enjoy writing.