If you’d like to try the web app out, it is available here https://clouded-pagespeed-client.firebaseapp.com. There were two goals this week; I was looking at improving the usability & design and fixing a logical bug where users would be overwriting each other’s data.
I’ve not needed to learn much about Bootstrap yet, but this week I quickly had to get to grips, luckily after spending some days surfing and not getting so far, I found the Pluralsight course Bootstrap 3 by Shawn Wildermuth. It allowed me to correct some problems with the navigation menu and site speed result table. Also, I checked out some sites offering themes, like Bootswatch, and even tried to integrate into my Ember app, but, that didn’t work unfortunately.
I like Googles Firebase NoSQL database a lot. Similar to standard databases you are applying rules on the server side, which they solved in an incredibly efficient way. The bug I mentioned at the beginning of users overwriting each other’s lists was a matter of placing their data under a user directory using their id, which I found out about in a couple of helpful blogs posts. Luckily I also consulted my Ember expert Alexandr Opak who came up with a much simpler solution, which again for me at least highlights that code like that is going to require refactoring neverminding the perils of copy and paste from the internet.
The following architecture diagram will let you understand the overall environment and high-level technology choices, which I didn’t have time to update for a couple of weeks now.
Everything is on Google Cloud Platform and so far $70 of free credit has been used on infrastructure. Firebase has a different pricing and is currently free.
Also worth a mention on Google Cloud Platform is that it notified me this week that the new NGINX service is not requiring so many resources as given. A great feature in the form of a pop-up offered me to reduce the compute resource and thus save money. I’ve not seen that on other cloud platforms yet. It certainly makes sense as it currently roughly looks to be costing about $25 per week.
For the last sprint, I have decided I want to look at compatibility on mobile devices (2 points) and try to integrate a bootstrap theme (2 points). The total story points for the sprint is 4. I spent a little bit of time going through the backlog tidying up the stories and creating epics where-ever a feature would require more than one sprint. I’ve grouped the stories into 3 epics; usability (11 points), scheduled speed comparisons and notification (22 points) and app monetization (13 points). With the current velocity which on average is 4 points per Sprints we would need about 12 sprints to implement everything. Remember I only planned to spend 5 to 10 hours a week on the project. Working full-time with a team you could easily get there in 2 to 4 weeks. As long as you estimate your stories every week, then you will always be in a position to estimate the time required and budget appropriately.