Blog

Web App Project: Sprint 4

This week it turned into a learning fest. I spent time on each item but unfortunately, despite all the action, did not achieve any of the sprint goals the way I wanted:

  • User is able to trigger a website speed scan.
  • Displaying the results.
  • Securing the webservice.
  • Fixing the bug where login should redirect to the tasks screen.

The first two sprints of this project I struggled my way through learning Ember and spending last week on server-side was great because it just was more familiar and somehow easier. I doubt you will find a blog out there that will say it is easy to learn Ember. Reading the documentation on the main website several times does eventually help.

Keeping up with modern application development is a full-time job not to be underestimated, I think it’s become difficult to prove mastery with the constant switching between frameworks that seems to be required. A couple of years ago I would argue these were all magpie developers, but having spent a couple of years studying cloud tech and using it myself for a good year, I now understand things differently. You can never stop learning and have to like it.

For the next sprint, I want to go into laser beam focus, to regain confidence. I will continue on the feature to lookup the speed of a list of websites and to display the results. I will ignore everything else including the open bug, for which there is a workaround.

Having deployed the client on firebase, I discovered another problem, that the REST API must also be using HTTPS. I did try to set that up during the sprint but ran out of time in the end, so it will have to wait in the backlog along with other items.

The project backlog now has stories with 40 points. The good in knowing this is that we can quickly estimate how many more weeks we might need. I’m hoping an early beta version could hopefully be ready by the end of sprint 6. 

Blog

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.