Hack24 2017

Today’s header image was created by Paul Seal, and it was taken as AbstractSausageFactory took an early morning break while hacking together their entry for Hack24.

This week’s post will be a slight departure from .NET Core stuff… kinda

Hack24 The Planet!

Not quite.

This past weekend, I took part in Hack24 in Nottingham with Zac Braddy, Paul Seal and James Studdart; we entered the competition as AbstractSausageFactory and, in less than 24 hours, created an entire line of business application from nothing.

An Entire Application?

Yup. We started work at 12 midday on the Saturday and by 12 midday on the Sunday we had an entire application which could measure employee engagement.

The event itself actually started at 9 am on the Saturday

It used an impressive list of technologies too:

• GitHub integration
• .NET Core
• Node.js
• ESLint
• .NET Framework
• ReactJS
• Firebase

That’s an end-to-end description of the technologies used in the stack.

Although, I’m sure that I’m leaving something out.

Zac has already published a blog post about the things that he learnt with regards to ReactJS over at thereactionary.net. I’d recommend that you give it a read, as there’s a lot of distilled knowledge in that post.

As with his other posts too, of course

The challenge we had entered called for us to measure employee engagement across a fictional company. I’ll let MHR (the challenge sponsor) describe it best:

Based on that brief we set about creating an application which would measure engagement via work completed.

If you to skip directly to our submission video, you can do so by clicking here.

The Idea

We started where we live: programming.

Let’s make programming into a game.

We started with by taking a look at Code.RPGify to see if we could figure out how that worked and whether we could rip it off gain inspiration from it.

If we could gamify cutting and committing code, then we could produce stats on it. We could then provide an admin panel and let managers and tech leads see how their developers are doing with their tasks.

We retired to a safe distance (Starbucks across the street), white board in hand, and created the first of our design diagrams.

We had a simple idea:

• User commits code to GitHub
• GitHub talks to an API that I would write (in .NET Core)

Because it’s important to be relevant to this blog, right?

• My API would pass on relevant information to Zac’s Node instance
• Zac’s Node instance would do some magic and send data to James’ game server
• James’ game server would send some data to Paul’s Firebase DB server

There’s a lot of the magic missing here, because you’re only interested in the parts I put together, right?

My API

I needed to know how to communicate with GitHub, so I looked up their version of GitHooks.

GitHub is just Git in the cloud, so it should have GitHooks, right?

Turns out that GitHub has a thing called Webhooks. A GitHub repo can be configured to send messages to a given external API when certain events happen. These events are:

• A repository is pushed to
• A pull request is opened
• A GitHub Pages site is built
• A new member is added to a team

The only one we were interested in was a repo push. So I navigated to a GitHub repo and set one up. It was surprisingly easy to do.

Setting up a new GitHub Webhook

I headed over to the settings page of the GitHub repo that I was looking at, found the big “Webhooks” button, and gave it a click.

A Webhook will send you either JSON data or a urlencoded web-form. I chose to receive web-form data, that way the data would be sent to my API in a string called “payload” – making parsing it a little easier.

The WebApi Project

Then I threw together a .NET Core WebApi application which would act as the POST end point for GitHub to communicate with. I spun up an Azure instance

I’ve written about spinning one of those up before, but as a cloud VM

and published to it.

To test that it was working (after adding a single GET method), I fired up postman and sent it a GET request.

Now that it was responding to GET requests, I needed to get it to receive and parse JSON data as part of a POST and I would be set.

Parsing the JSON Data

Since the data would be in JSON, I threw together some classes which represented the JSON data and decorated the properties with JsonProperty attributes.

I didn’t have time to represent every property of the JSON, so I picked the most important ones for our application

We only had 24 hours, after all

I threw the following classes together:

I’ve left in comments showing the format of the original JSON data

All I had to do then was deserialise the JSON data back into an instance of the GitHubPushJson class.

Again, with Postman I checked that the API was working, and it was.

We Need More Data

Looking at the returned data, we didn’t really have a great deal. Namely, we had filenames, but not file paths or branch names.

Bother!

Luckily the GitHub data exposed an API that I could call to get the data for a commit.

And here’s why I left the comments in the above code

Which is the same format as the GitHub Commit API method for getting all of the data for a single commit.

which you can read here

All I had to do was get the sha of the commit, replace “{sha}” with it, and put in a GET request to GitHub.

The keen eyed of you will have already spotted the method I used to get the full URL to use, earlier.

The first thing I did was write a Helper to perform the GET for me:

Then I added code to my POST method to perform the GET

This didn’t work, as GitHub kept refusing my connection due to a Protocol Violation. But it worked when I performed the GET from Postman and in my browser.

It turned out

thanks to this Stack Overflow answer

that the answer was to include a user agent. It didn’t matter what the user agent was, as long as one was included. So I chose to pretend that the WebApi was Firefox

Because why not

It was a simple change:

The GET started working after that.

Committing to the Commit

Now that I had the commit JSON

and the documentation

I could write a class which would have the file paths for all of the files contained within the pushed commit.

As with the original JSON data from the push, I decided to only parse the most important data

otherwise I’d have been there all night, creating a class hierarchy

The initial version of our application would deal with javascript files only. We had plans to extend this, but for now it would do.

we only had 24 hours, you know

So I needed to figure out which files where javascript and send their file paths (along with the number of changes in the file and the author of the commit) to Zac’s Node endpoint.

I decided to use a Singleton to do the actual POST to Zac’s endpoint

Because why not?

and a helper which the Singleton would use to perform the POST.

This Singleton isn’t thread safe. See: my comment about 24 hours

and I consumed these in the new version of the PushEndPoint like this:

A quick check with Zac showed that the file paths were coming through OK.

What Now?

I started looking into both Trello and Google Docs APIs.

I’m not going to lie, I didn’t get very far with them. Then again, it was 3 or 4 am by this point and I’d been working solidly since midday.

Not to mention an early start, after a late night

We took the group decision that, since I wasn’t getting anywhere with them, I should take a look at building an MVC app which would represent a call centre timer.

Short Brief

A start button, a stop button, a timer, and post the data to the server. Done

Can’t really get more succinct than that, right?

I created a .NET MVC application

NOT a .NET Core one – which was amazing foresight

and threw this code into the Home view

A call centre operative supplies their name, clicks “Start” when they pick up the phone, and clicks “Stop” when they hang up. The call data is JSON’d then posted directly to the game server.

Simple.

Tidying Up, UI and Video

By this point, it was time for breakfast. Only 5 hours to go and we still had a lot to do.

We needed:

• A UI dashboard (showing all stats for all users)
• A user profile page (showing the stats for a single user)
• Various tidying up jobs
• A video to actually submit our app

After a chat with James about what I needed to do to get the user data, I created the classes and threw together an MVC app for the dashboard (adding it to the MVC app that I’d created for the Call Centre application).

all the while an exhaustion based case of impostor syndrome started to set in

All that was left was to implement the styling created by James and Paul. James did the design on our whiteboard and Paul threw it together in Bootstrap studio in minutes.

Then it was down to me to apply the styling.

Once that as done, it was testing time.

During which Zac created our submission video, which you can watch here:

Submitting, Chilling, and Results

Once Zac had put the video together

and it really is ace!

 with parts from each of us, we submitted the video and chilled the eff out.

there was Rocket League on a PS4 and extremely comfy chairs. I chose the chairs and nearly fell asleep

The next thing we knew it was results time.

The short version is that we didn’t win.

We’d overshot the mark, by going from 0 to a full line of business app in 24 hours. The other submissions (for the challenge we had entered) were great and targeted the problem better than we had, because we’d wandered a little from the scope a little.

Scope and feature creep are real things.

Reflections

The amount of work that we’d put in was phenomenal.

 even with me complaining that I hadn’t done enough; stupid Impostor Syndrome

I remain convinced that if this application was built properly, without cutting any corners, and in a fully Agile environment, it would have taken us a week to get to where we were on Sunday at 12 midday.

And we did it in 24 hours.

That’s an amazing achievement.