Tag Archive | Rob Crocombe

Braces

There are a few things that any seasoned Software Engineer will have had arguments discussions about. Windows vs Linux, Merge vs Rebase and inevitably code indentation style.

Just today Rob and I discussed whether we should diverge from the “One True Brace Style” (1TBS) decreed by the AirBnB JavaScript Guide toward the Stoustrup style of indentation. The only difference? Stroustrup does not use a “cuddled else”, instead else keywords are on their own line.

Does such a minor difference matter? I would argue it does. If being able to read code in a certain style increases a programmers productivity then that is no bad thing. However, this increase in productivity can be easily offset by having to change style when working in different codebases. Consistency is important.

To maintain consistency in the CS Blogs codebase every component would have to be updated. This would mean 100s of lines changing for style, reducing the effectiveness of git blame and muddying the commit history. Even if we were to do this eslint-config-airbnb was downloaded 399,657 times in the last month and I would wager most of the projects using it are sticking with the suggested 1TBS style. The advantage of having code that looks like the “standard” for an open source project is that it enables potential contributers to get involved that bit easier.

My theory about code style guidelines is that in a team of people n-1 people will be unhappy with at least part of the guideline. The only person that will be completely happy with them will be the person whom decided upon the rules. Programming is merely transcribing processes and thoughts into a language a computer can understand, and in that sense it is very personal and everyone is likely therefore to have strong feelings around how those thoughts look on screen.

As with so many things in Software Engineering, in many ways the style you choose doesn’t matter, but sticking to it and enforcing consistency does. This is why I am against changing the CS Blogs codebase even though I agree with Rob that the stoustrup style is nicer on the eye.

So, what can Rob do in this situation? The first option would be to just keep writing in the 1TBS style until it seems natural (this took me a few days of writing), however he could also use an automated code formatter to change how his local code looks and then automatically have it changed to the prescribed style before any commits to version control. Any mistakes by the automated code formatter would be caught by the ESLint commit hook.

Danny

Writing better quality Node.js applications

In February last year I started writing my first Node.js App, csblogs.com, alongside Rob Crocombe. The application has run without too many issues since then, serving around 1100 unique visitors per month. However, because it started out as a prototype we didn’t follow many of the best practices we should have done, and its starting to show now we want to extend the application.

Since writing a more complicated application at Trainline — which provides an API to clients and consumes many Windows Services, RESTful APIs and Redis Caches itself — I’ve realised how important it is to be using good software engineering techniques and tools from the very beginning of development.

Whilst most of the concepts in this post are language independent, the example tools I explain are all geared towards Node.

The Basics

These first few things are obvious, and are things you should be doing in all your projects.

Source Control

Source Control everything, even prototypes. The minuscule amount of disk space a git repository will require, and the few seconds every so often to write a commit message will be incomparable to the amount of time you will save by being able to revert a change, or check when changes occurred.

I’ve taken to using Github’s variant of the git flow pattern in which branches are deployed to production and only merged into master once they have been tested “in the wild”. This means that whatever code is in master is always certified as working in production and can be relied upon to be rolled back to in the event a new branch doesn’t work as intended. I like the WordPress Calypso Branch Naming Scheme to make it easy to understand what is being developed in each branch.

Branches use the following naming conventions:

  • add/{something} — When you are adding a completely new feature
  • update/{something} — When you are iterating on an existing feature
  • fix/{something} — When you are fixing something broken in a feature
  • try/{something} — When you are trying out an idea and want feedback

If you don’t like that naming convention or it doesn’t suit your needs, thats fine. Choose a naming convention and stick with it. As with so many stylistic choices in Software Engineering it isn’t the style that is important but the uniformity and consistency it brings.

Documentation

There are few things as annoying when developing software as opening a repository to find no information in how to build the project, run tests against the project or what data and functions the code it contains exposes to its consumers. When developing your code you should try to keep your documentation up to date with at least this information:

  • How to build
  • How to run tests
  • How to deploy
  • Data and functions exposed

Things like how to run your build, test and deployment scripts shouldn’t be changing so often as to be a pain to keep up to date. The data and functions exposed however may change reasonably often, especially if you are iterating whilst developing an API, so in order to make that task easier I suggest you use something like Swagger.io.

Testing

Testing code is one of the things that, 5 years into learning about developing software, I’m still learning about and still eager to learn more about. Good quality testing can be the difference between a bug rearing its head in production and costing you thousands of pounds and it being caught, thought about, and fixed earlier in the development cycle. Automated testing also means that you can be confident that any changes you make won’t be causing regression bugs.

When writing a new class, I first sketch out the interface — e.g. the public constructors, functions and data that the class will expose.

class Train {
     constructor(name, britishRailCode) {

     }

     getTopSpeed() {

     }

     determineLocation() {

     }
}

Then I spend some time thinking about all the potential edge cases, as well as the ‘happy path‘ through each of the functions. For example, what should happen when an invalid BR code is provided to the constructor? What happens if GPS coordinates cannot be determine due to faulty hardware — or in the case of html5 geolocation lack of user permission — in the determineLocation() call? What data should I get back from each of these functions? Is there a timeout after which the function should return an error if it hasn’t completed?

Once I have an idea of the expected behaviour of the class I start writing test, in a Behaviour Driven Development way, using the Chai Assertion Library and Mocha Test Framework. There are many advantages to use BDD, one of my favourites is that you dont write names for your unit tests, you state the expected behaviour in a full sentence — this makes it so much easier to realise the intention of the test and makes it so that test code can, in some senses, document the application code. Another great attribute of BDD is that it allows you to think in terms of what you want your code to behave like, rather than implementation details.

Test Coverage

Test coverage is a highly discredited method of determining the quality of a set of unit tests. Covering every line of code doesn’t mean you have thought of every conceivable edge case and therefore doesn’t guarantee your code is free of defects — indeed no testing can, as testing only shows the existence of bugs, not their absence. However, at minimum you should be covering every line of code — and every branch. (Yes, you can have a branch of code that doesn’t include any lines — I leave working out how as an exercise for the reader)

Linting

JavaScript allows you to make decisions on many areas of syntax. To use semi-colons, or not to use semi-colons — that is just one of the questions. When writing code in a team its easier if all of the code is formatted in the same way, so you don’t waste time reformatting it to a way you prefer code to be written. One way of doing this is to have everyone memorise your projects coding conventions and hope they stick to them, a much better way is to use a linter which will warn the programmer if they break any of the projects rules — this ensures that everybody writes in the same style.

An additional benefit of linting is that, depending on which linter you use, you get static analysis of your code provided to you too. This means the linter can point out any variables you have defined, but haven’t later used, for example.

I personally prefer to use ESLint as it allows different rules to be configured through the use of plugins. This means that you can have a set of rules for React JSX code and a different, more suitable, set of rules for your Mocha tests. For the bulk of my application code I use the official Airbnb style guide ESLint plugin — I like Airbnb’s focus on using modern JavaScript constructs and having code be as explicit as possible. They also provide lint rules for React code.

Commit Hooks

Linting and Testing is all well and good, but you need to have the members of your team buy in to using it. And, even on a one man team, I often forget to run tests and linting before I commit code resulting in broken builds and ugly code being in the master branch of my respository.

 

Pre-commit hooks to the rescue!

Pre-commit hooks to the rescue!

Commit hooks can be used to ensure that your unit tests and linter are always ran before a developer can commit their code. This means they can’t forget to lint or unit test and actually saves time in the long run. I use the pre-commit package to provide this functionality. In combination with good unit tests and linting, pre-commit hooks can help ensure that the code in your repository is always working and readable. (Note: a developer can decide to skip hooks if they’re in a rush to develop a hot fix, but this should be avoided under normal working conditions)

Configuration

Configuration is an important part of any application. It can be as simple as wanting to be able to change which database you want to connect to when on your location machine vs which one you connect to in production, however you don’t want this information to get into the public domain!

I used to use JSON files for configuration. However, these could easily be accidentally committed to git and make the secrets they contain public knowledge. Recently I’ve opted to use Environmental Variables for all the reasons outlined by Twelve Factor. The dotenv module for Node.js makes environmental variables easy to change in development. In the CSBlogs applications I’ve been writing I provide a sample.env file which includes all the names of environmental variables developers should be setting to get the app working in their local environment.

So, there it is. A quick run-down of some very basic steps to give yourself a nice place to work in JavaScript world. Now get developing!

Danny

Introducing CSBlogs.com

CSBlogs.com Homepage

Between studying hard for my masters degree — and applying for jobs for when it ends — I have managed to find some time to set up a new website called CSBlogs.com

People who have been reading this blog for a few years will have seen HullCompSciBlogs.com mentioned a few times, for those that haven’t it was a service which aggregated all of the blog feeds of computer science students at the University of Hull.

John Van Rij did a great job of keeping that service online, but unfortunately doesn’t have time to maintain it anymore. Since the service went down I have grown to miss it — I guess I didn’t realise how much enjoyment I get from seeing how well everyone is doing from back in Hull — current students, alumni and even lecturers.

In order to resolve this problem I set up CSBlogs.com with the aim of getting all of the Hull Computer Science bloggers and others from around the country onboard.

The project is entirely open source, under the MIT license, and can be forked, modified and improved by the community on Github.

The website itself is hosted on Microsoft Azure and utilises CloudFlare to provide security, analytics and a global content delivery network. Node.js is used as the backend programming language and the MongoDB NoSQL database is used for persistent data storage. Nodes packages are used extensively, including Express.js for routing, Handlebars for data-binding to the front end and LESS-Middleware to improve CSS development.

Complicated acronyms aside I have worked hard to make setting up a local development environment and contributing source as easy as possible for beginners via the instructions I have written on the homepage of the Github repository. I would really recommend any 1st or 2nd year students give it a go — open source development looks great on your CV! And if you need any help contact me as per the instructions.

We are currently in the process of setting up all of the required frameworks and technologies and writing guides for how to get involved (this has actually been one of the more challenging and interesting parts of the project so far) and hope to have a working minimum viable product in the next week.

At this point I would like to thank Charlotte Godley, Alex Pringle & Rob Crocombe for their extensive help in getting the project to where it is now. Charlotte has taken on a role of project management, Alex has developed a rudimentary database controller and Rob has been working on implementing less.js support and developing a theme for the site.

I will keep the blog updated with progress on the project.

Danny

America Roadtrip Summer 2014

Road tripping in LA

I was going to write a blog post about my month travelling around Arizona, Nevada and California with my friend and fellow computer scientist Rob Crocombe, but frankly I don’t think I could improve on what he’s already written. So, if you want to read about all the exciting places I went this summer including:

  • The Grand Canyon
  • Las Vegas
  • Santa Monica Pier
  • Griffiths observatory
  • Disneyland Anaheim
  • The Pacific Highway
  • The Golden Gate Bridge
  • Silicon Valley
  • Alcatraz

and much more, then make sure you click across to Robs blog posts and pictures:

Blog and Pictures of Arizona

Blog and Pictures of Las Vegas

Blog and Pictures of Los Angeles and Southern California

Blog and Pictures of San Francisco

Thanks to rob for such great work on the blog and images, and of course for coming along and having a great time in the USA.
Danny

Graduating and Being Awarded the Departmental Prize

Walking past the chancellor as part of the graduation ceremony

On the 14th of July 2014 my degree was officially conferred to me at a graduation ceremony at Hull City Hall.

The day started off with a lunch inside the computer science department at the university, which was a nice opportunity for my parents and siblings to see the labs in which I’ve done a lot of my work over the past three years.

Whilst we were at the lunch I was called up in front of the other students, and their families, to receive the departmental award. The award means that my name will be shown on a golden plaque inside the social area of the department and I will receive £100 from the university. It will be quite cool to have a plaque inside the department, especially as I recognize a lot of the names on the board already as being our current lecturers — my name will be in good company. I received the award for having the highest overall grade of a graduating student — at 86.05%.

 

 

After lunch my family and I made made our way to the Guildhall in Hull City Centre where I picked up my cap and gown.

 

 

We then made our way to the City Hall where the actual graduation took place. Rob Miles, one of my lecturers from the first two years of my degree, explained how the process of graduating worked. We simply had to walk across a stage after our names had been called and nod at the Chancellor of the University. Behind us were some of the lecturers from Computer Science, Maths & Physics and The Hull York Medical School — all of the departments who had people graduating that day.

 

 

Once the graduation had taken place inside we went outside for the traditional slate throwing with the town crier. He was rather funny.

Preparing for Cap Throwing Outside

Preparing for Cap Throwing Outside

Once all of the pomp and ceremony was over my family and I went for dinner and then the drinks started flowing with my brother and university friends out in a few pubs in old town, and then the Piper Club on Newland Avenue.

My degree certificate, and shield, on my living room wall.

My degree certificate, and shield, on my living room wall.

The day after my graduation was my birthday, so its been a truly brilliant few days. Thanks to everyone involved, you know who you are!
Danny

Year 3 Semester 2 Results

Year 3 Semester 2 Results

Today I received my final set of grades for my BSc (Hons) in Computer Science from the University of Hull – This included my two second semester modules, Mobile Devices and Application and Distributed Systems Programming, as well as my Final Year Project.

I achieved a grade of 85% in Mobile Devices and Applications, and 89% in Distributed Systems Programming.

The final year project was worth twice as many credits as each second semester, and so had more of an effect on the final grade. Thankfully I did quite well in the final year project, achieving a grade of 86%.

My overall weighted average for this year, including my first semester modules grades, is 86.5%.

This grade, weighted with my second year grades, means that my final grade for my degree as a whole is 86% – a very high first! I am of course over the moon with this.

I’d like to again say thank you to everyone who has made my time at university not only great for learning, but truly the best three years of my life (so far! :P). Particularly, but not limited to:

  • Rob Crocombe
  • Simon Watkins
  • Hayley Hatton
  • Russell Billingsley
  • Toby Russell
  • Jon Rich
  • Tom “Jeff” Procter
  • Special mention to “our American foreign exchange students”

 

  • Dr Martin Walker
  • Eur Ing Brian Tompsett
  • Rob Miles
  • Dr David Parker
  • Dr Peter Robinson

And of course anyone I spent time with in the labs or any of the many, many nights out in the first two years. Last but by no stretch of the imagination least thanks to my Mum, Dad, Brother and Sister for supporting me throughout the last 3 years.

I’m looking forward to trying to maintain this good score next year at York! Of course I will continue to do this blog throughout my time there too.

Danny

University of York – MSc in Advanced Computer Science

University of York Computer Science Department

Today I recieved word that I have been accepted for an award of a £5000 academic performance scholarship at The University of York.

This offer, alongside the high standard of teaching & research, beautiful new department facilities (pictured above) means that I have decided that I will be spending next year studying a Masters of Science degree in Advanced Computer Science at The University of York.

It is my intention, once the masters degree is complete, to continue on with a PhD. The masters degree should give me all the knowledge and experience I need to choose a partciular field in which I wish to do my research.

In the near future I will be formally accepting the offer, which I can do once I have recieved my final transcript from here in Hull, choosing my accomodation and selecting my module choices for next year. I will of course keep the blog updated with any developments.

I would like to take this time to thank Dr. Martin Walker and Rob Miles at the University of Hull for writing me two fantastic references, which no doubt helped me get accepted onto the course and in the application process for the scholarship award.

Similarly I would like to thank Jonathan Stokoe for the making the application process so pain-free, and Dr. Jeremey Jacobs for giving both myself and Rob Crocombe a tour of the Computer Science facilities at York.

Danny