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. 

Web App Project: Sprint 2

It is two weeks into my 8-week web app project. The total worked time so far is just over 21 hours. I’m amazed how much an hour in the morning and evening can accrue. This week was tough, not only did I have to contend with the learning curve for the Ember framework which I’ve never used before and is the front-end of this app, but, to make matters worse, I’ve also have been sick for about 10 days, and it had me flat on my back for a whole day last weekend.

When using Scrum, you should avoid debating about how much time might be required when trying to estimate stories. I think it’s relevant to mention it here. Always be comparing stories on complexity, then unknown stuff you might have to learn. If the number of days spent changes that will, of course, impact the sprint velocity which so far in this project is 4. If you just watched the demo, you’d know there are some bugs; I think it reflects the situation that happened in this sprint which had me only being able to work about half the amount of hours I gave into the first sprint.

Several times I both read and heard authentication using Ember and Google OAuth is easy. Unfortunately, I didn’t find it that way, and I eventually came across other blogs stating the literature is out of date and not quite geared toward what “normal” people are trying to accomplish. It didn’t take too long until I decided to reach out to Alexandr Opak again, who quickly added the required libraries and prepared the application. All I had to decide on was the provider; Google, Twitter, Facebook, then add the code. He could have done it all but knew I wanted to learn the framework. Needless to say, I’m starting to become a fan of this guy, and without him, I probably would have had to fail the sprint.

So far I’ve been trying to avoid making this into a technical journal with source code listings, but, I would like to share the links for the required API documentation to help anyone wanting to do similar work:


I’ve also just bought a book “Deliver Audacious Web Apps with Ember 2” by Matthew White, which I think is excellent, I’ve already read 20%, it takes you step for step through creating an application like Evernote and provides a lot of know-how your not just going to stumble across on the web.

This leads me to my main takeaway this week and I’m thinking it is fairly certain there will be a bit of refactoring and work required to make this app beautiful, but, for now, let’s get to what I would call the juicy part, the planning and what next.

Sprint 3 Backlog

In next weeks sprint I have 3 bugs and again taken stories with a total estimate of 4 points;

  • Setup Linux server (1 point).
  • Create service to time website (3 points).

For the job to be considered done, I expect the service to take a URL  and check the site’s performance and log it to a text file. The program does not have to interface with the database.

The backlog is not looking good right now. There are stories with a total of 35 points and with a velocity of 4 points per sprint, we might need another 9. I’m going to have to spend a bit of time on working on it next week. Hopefully, some of the 3 pointer stories are not as complicated I thought.