Coffee App Redux: Planning

Published by Ben on May 22, 2018 at 13:50pm

CoffeeSite2

This ain't my first rodeo

Back when I was first beginning to learn C#, I was given a task.  Create a Web Application that would use a database tracking the stock of coffee at the Antelle office to create charts display various kinds of information.  This project was intended to introduce me to ASP.NET, Razor and all the concepts that creating a Web Application would entail.  I failed in many different ways, the lessons I learned from mistakes in that project would improve my development skills no doubt, but the project was never truly finished.  Some features were completed, you could in fact; view charts, create/edit/delete records and view all of the records in a paged table.

However, the project was a mess, there is a barely existent Business Logic Layer, in my haste to have a functioning project I opted to design stored procedures instead of processing data through the business logic for consumption on the front end.  I didn't even manage to use any Razor, instead of relying on 937(!!!) lines of awful jQuery to handle changing data and my implementation of the charts extended to a bar chart and a pie chart, neither of which were working at all well.

I did make a previous attempt to finish this project, an MVC app that I planned and built with a far better idea of what to expect and how the functionality could be built and delivered, however CoffeeSiteTrial never reached further than setting up the CRUD (Create, Read, Update, Delete) functionality and an example chart.

When I was considering what to do as a working playground for my latest exam, I realised I had a chance to finish off my white whale, my Moby Dick.

This is the first in a series of blog posts I will write as I produce this project, I will talk about my reasoning and execution of various parts of the project as it progresses and even hopefully provide some tutorials for certain aspects of functionality.

I am Ahab, this blog shall be the Pequod and all readers shall be Ishmael.

Plan of Attack

Database

Thankfully, there isn't anything inherently broken from CoffeeSite2 in this area, it was a very simple database, with a table for tracking updates, and two tables for describing what type of Coffee was being added or removed from the stock and for detailing how it was removed (Drunk/Removed from the Office).  Instead of fixing what isn't broken, I'm expanding the scope of the information.

Previously the database only tracked if the type of coffee was Lungo, Espresso or Decaf.  For the new one, I intend to add exact flavours (and we have quite a few) not only will this allow us track if we are actually running out of a type of coffee, but it gives me a lot more room to play with charts on the front end, to preserve the Lungo/Espresso/Decaf classification a new table will be joined on to the CoffeeType table that details what category it belongs to, this allows additional categories beyond those three to be added but I don't see it being used.

A consequence of this, however, is that I can't reuse the data from CoffeeSite2, the dataset was created too long ago and there is no chance the charts could be accurate by adding flavours such as Generic Lungo or Generic Espresso.  So over the course of this project, I intend to gather both a true dataset, tracking coffee stock changes, and a test dataset with all manner of flavours that I can use to test charts with a longer time-frame in mind.

I do intend to have a single stored procedure, one that will return Updates with the relevant flavour names, category and CoffeeOutType to be delivered for displaying the records on the site. Whether this is really needed is something I'll find out as I move into rendering the records but I'm erring on the side of caution.

Business Logic

This is where I want to make the biggest changes from CoffeeSite2, the business logic there essentially operated as a conversion between SQL Data and JSON that was delivered to the gargantuan javascript on the front-end.  This time the Business Logic will provide concise data that will allow charts to be built with time ranges, filters and separate sets of data for comparison and trend charts.  It will contain ViewModels for delivering combined data and will handle CRUD in a way that isn't hardcoded SQL statements using String.format() to insert data into them (I wish I was kidding). I also want to play with implementing custom HTTP Statuses on this project to inform my learning for the exam.

It is here that I want to implement a comprehensive logging system, this will let me track how the application is working and also refresh my memory of how to effectively log information ahead of the aforementioned exam. Next is a full and bulletproof exception handling system so that the app should never fail to display a page. Finally is a rigorous Unit Test regime, I want to be able to test everything after I make changes to make sure there are no bumps in the road on this front.

All of the above are very important to do well, these are critical topics for the exam this project is in preparation for and yet are also areas I have fairly good existing knowledge in, one trait of my exam results so far is that I tend to under-perform in those areas and I want to break this trend for this exam.

In the context of projects, I've worked on before this isn't a particularly complex Business Logic layer but I have greater plans for features to include in this project once it is fully functional.  I'll cover these in the Business Logic blog post.

Front End

I'm aiming to keep this as simple as possible, I will likely utilise the base Entity Framework views as I begin until the presentation of charts is nailed down to a satisfactory degree before making any significant changes.

Speaking of charts, as of now there are eight charts I am definitely going to implement, any more than I decide to include are essentially stretch goals at this point, these charts are;

  • Line Graph of the L/E/D categories stock over time (Filterable by Date Ranges)
  • Line Graph of flavour stocks within these categories over time (Filterable by Date Ranges)
  • Pie Graph showing stocks of flavours (Can be set to display stock on any day in the past)
  • Line Graph showing a change in total stock over time (Filterable by Date Ranges)
  • Trend Graph to compare changes in consumption over time (Unsure of what type of chart to use or even if this needs a chart at all, Filterable by Date Ranges)
  • Bar Chart showing the change in consumption month on month (Filterable by choosing which two months and which flavour)
  • Bar Chart showing the favourite flavour of coffee for every day of the week (Filterable by Category)
  • Bar Chart showing streaks of days where a flavour is drunk/not drunk (Filterable by flavour)

In all honesty, now that I am not a struggling novice, I don't anticipate creating these datasets and the charts to show them to be too difficult (famous last words), the focus of this project is mostly doing this right and doing it well.

In terms of what use I'm getting from this section for exam preparation, I am mostly looking at Reusable Partials, Correct SEO setup and Mobile Display Modes (different interface for displaying charts).

Conclusion

This is my plan, while this is a small application and really will only exist to justify the addition of additional systems to help me prepare for an exam I'm still extremely keen to make this a complete success.  After a thorough self-review of just how badly the wrong CoffeeSite2 went, I've been gripped by the fervour to do it better, do it right and if I have to christen my harpoon in the name of the devil himself to slay this beast.

So be it.

| Next Post |