Web App Project: Sprint 3

Last night we welcomed in the new year. I love spending time with my family, and finally, my kids are old enough to experience it – it was great! If you’re reading this, I wish you a fantastic start in 2017.

The project continues, and this last sprint brought a couple of unexpected turns. So far we have a screen capable of storing websites, login is implemented to secure the data. The goal this time was to create a service capable of testing a websites speed.

It would have been very easy for me to setup a Linux server, then install NodeJS, PhantomJS and YSlow. I’ve shown these before in a vlog and had planned to do that, but during my research, I came across the fact that YSlow since over 3 years is no longer being maintained. It’s perhaps out of scope but it’s interesting to see services like gtmetrix charging up to 150 USD per month for tech that seems to be completely outdated. Nowadays we see business models even around providing simple newsletter popup boxes, so it’s perhaps not that surprising that they still make money, but amazing.

I came across a new alternative API called sitespeed which is active. However, I was unable to get the NPM version running, which seen me giving it up after a couple of hours trying to make it work. Having little alternative at the moment I decided to use the Google PageSpeed API, even though I wanted to be able to show the number of milliseconds to load a site, but, now will be providing a value from 0 to 100, anything over 85 and I would be speaking of competitive edge.

Actually, at the time of writing this blog I just found an alternative webpagetest.org which did seem quite comprehensive as speed tests go, it has an API so like the Google service could easily be tied into a continuous integration test to ensure the speed of a site.

On Tuesday morning last week I came across an offer on Google which I decided to look at, they are offering free $300 in services on their cloud platform over the next 60 days. Music to my Scottish heart and just the thing I need for this project. If nobody likes this service and it doesn’t work out, then we pull the plug and infrastructure costs are ZERO 😉

Finally, instead of using an old school Linux VM, I decided it would be interesting to try out some new tech. The Google container service is supposed to allow you to concentrate on the programming part of creating a solution. Knowing apps like Pokemon GO and Snapchat having used this platform made it an easy choice. This lead to me learning a few new things this week, including; Docker, Kubernetes and writing my first server side API using NodeJS (and using gulp to test that on my machine). Luckily to have paid access to platforms like PluralSight and Cloud Academy and with a couple of tutorials got most of the next gen tech under my control.

Had I come up with the technology change last week, the estimates the current sprint might have been somewhat different. I did spend a few extra hours this week learning stuff, but I’m quite excited about the unexpected turn, cloud tech does that to me.

In Sprint 4 I want to add security to the speed comparison service but will also try to bring that into the tool and display the results. Total 7 story points:

  • User is able to trigger a website speed comparison (3 points)
  • Visualise speed comparisons in a simple table format (1 point)
  • Make speed comparison service secure (3 points)

Sprint 4 Backlog

I’ve added a story to the backlog, that a scheduler will trigger scans on a daily basis.

Currently, there are stories with a total of 35 points left, so with the increased velocity I should need another five sprints. I still need to break down those 8 pointer stories and then can hopefully bring this in when I said.

If next week, the app can use the new webservice, then I’ll probably try to publish the beta version.