1. Thou Shalt add Comments

Who knows what is going on in your code if you don’t tell anyone. A good developer will make sure they add descriptive comments to help anyone who looks at their code to understand.


  1. Thou Shalt do Testing

Testing is imperative from Test driven development(TDD) to simple unit tests, although in the short term they might take longer to implement, in the long run they will be hugely beneficial. A good developer will start writing test as they go along sometimes even before they have even started writing any code.


  1. Thou Shalt Try and break

If you don’t try and break your own code someone else will. A good developer will add unexpected inputs, click in places that you wouldn’t expect, enter unknown web address, etc try and do whatever they can to break their own code to make sure that it is robust.


  1. Thou Shalt use good communication

There’s always this conception that developers are introvert and live in the dark, this isn’t the case in the majority. A good developer has the ability to communicate with not only another developer but various stakeholders in the project, from the end user to the project manager and not with the use of ‘technical jargon either’.


  1. Thou Shalt think about their end user

So the software is fantastic, does everything it was meant to do and more, yet it’s bright yellow and all the buttons are placed all over the screen. if your user can’t use what you have created what is the point? A good developer will make sure that they validate their  design choices with an end user.


  1. Thou Shalt be Full Stack

Yes developers can have particular areas of expertise: front-end, back-end, databases. A good developer should be rounded enough to be able to work with all of these areas. They can still have an area of expertise but being able to work on multiple areas is very important.


  1. Thou Shalt help thy fellow developer

Suppose you have a variable that determines whether a tap is on, if you call it tapOn, perfect. However if you call it longPieceOfMetalOnOrOff that isn’t going to help anyone, especially when it comes to the maintenance of your code. A good developer will make sure that things are named appropriately and logically.


  1. Thou Shalt make things simple

This comes to down to code structure and simplicity. If you have five methods all doing the same little bit of logic, turn that logic into one method and have all the methods call that same method, that way should you need to modify this it is all editable in one place. In a house you have separate rooms for separate things, you don’t do everything in the same room. A good developer will apply this principle to their code, they won’t put it all in one file, they will break it down and separate it out.


  1. Thou Shalt use source control

Source control, through the means of git, is very important. It has three main properties: as a form of backup, to allow multiple people to work on the same piece of code and to see the changes that have been made to code files. A good developer will regularly commit to their git branches to allow for their changes to be protected.


  1. Thou Shalt evolve

In such a fast moving industry constant learning is very important. A good developer will keep himself up to speed with the latest technologies and practices to allow themselves to have all the tools in their arsenal to tackle any problems.


Happy Easter Everyone!


We’ve got Saturday night fever here at QuayTech!  One of our clients requires a live sales dashboard that would essentially be ‘staying live’ ensuring it is constantly refreshing to show real-time data.  Live polling is the ability for a page to maintain/update itself without the need for user interaction.  The dashboard is utilising the DataTables widget (https://datatables.net/) to group the sales data, in different ways, tailored to the currently loggedin user.  How could we achieve live polling datatables to refresh the data currently being displayed on our dashboard?

THE How?

First things first your Datatable needs to be populated through a json web service call to return the data, as opposed to a model being passed to the view (if using C#).  In the code below you will see a URL is called, this endpoint needs to return the json object to the Datatable.  The data NEEDS to be returned in this format “{\”data\”: ” + jsonData + “}”; this allows the Datatable to see that the data being passed back is data for the Datatable.

Note: The “bDestroy” : true variable that is being set here, this tells the Datatable that it is allowed to be destroyed and remade as necessary.

As long as we can identify the Datatable through an id, we are then able to call a reload on the ajax which will update the rows. The setInterval method is where the magic really happens, this sends a call to the method every 20 seconds in order for the datatables to poll.

As a little bit of an extra, a count of the rows on the table is taken before the call and after, it is then noted if there is a difference and if so a notification is displayed to the user that a new order has been received as seen in the code below. I have added a two second delay on this check to allow the table to sort itself out before checking, else it is too fast to see any row changes.

Note: datatableIDs is a string array of the IDs of the datatables that you are polling. Timing in JavaScript is in milliseconds so 20000 in the setInterval is actually 20 seconds.

So there you have it, how to live poll a datatable.


Today’s Blog, Like a BATch Out of Hell, has been written based on some experience I’ve recently had with building and debugging a Windows Service.

Recently we have been tasked with building a windows service for a client that would use multi-threading to continuously poll between two databases. We chose to create a windows service for this solution as we felt it would be the most efficient approach.  However, having never built a windows service before, debugging and creating the service was a little more tricky than simply clicking start and running with breakpoints … This is where the magic batch file came into play.

To test a windows service first you need to make your necessary changes, build the project and then install it onto your computer.  Making sure you are logged in as an administrator else you won’t get anything done! We added a “nice to have feature” whereby the service will write to the windows Event Log – something we made sure to get setup properly before deploying the service.

Key batch file commands to stream line your windows service developing:

wevtutil cl logName – this command clears the log for the windows service, replace logName with that of your log.

call “C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\Tools\VsDevCmd.bat” – this command opens the visual studio command prompt that is necessary to begin the installation.

 cd C:\YourFileLocation\YourSolutionFolder\bin\Debug – change the directory into the bin – debug folder where you have built your windows service to.

installutil.exe /u YourWindowsService.exe
– This will uninstall the windows service that you are working with (always good to start a fresh right?).

cd C:\YourFileLocation\YourSolutionFolder\bin\Debug – double check that you are back in the same directory as your windows service again

installutil.exe YourWindowsService.exe – final command to reinstall the windows service to your machine


Just for ease of reading a code snippet is here.


Just to clarify a batch file is saved ‘.bat’, to clear up the title.  Right-click on the file and click run as administrator else your batch commands won’t work.



To begin running your service, search for services in your start-up and then start your service.  To attach your debugger to your installed service, select debug in visual studio, and then attach to process. Search for your process in the list of running processes and attach to the process you have installed (note: it HAS to be running to show up in this list) it should then hit any set breakpoints that you have set, fingers crossed.


Happy Batching!