Blog \ Michael Murray - nawa236/StorefrontTestingApp GitHub Wiki

Hi, thanks for coming to my development blog!

9/15/19

Our group met with out customer/client Ben Fox back on the 13th at his office. We had prepared a long list of questions to help us get our bearings on what was expected for this project. At the time, hearing all the features that were expected or desired seemed like quite the challenge, especially for myself as much of the initial work of this project seems to be heavily focused on web programming. I'm currently in a web programming course and I'm sure the conjunction of the two will help the other but I'm hoping I'll be able to get my bearing quick enough to be as beneficial to the group as I would like. Nevertheless, after getting all the goals for this project on paper and discussing them as a group, it seems that the group as a whole is well equipped to tackle this task and with good time management and cooperation we should be able to succeed. We're just now in the process of writing up some user stories, Seanna uploaded her meeting notes and the combination of the notes and the guides we have for writing compelling user stories should allow us to further cement our needs for this project. The one thing that I'm curious about now is that the assignment we have is for only 3 user stories. While they can and will be subdivided later, drafting three tasks to encompass this project does mean that, in their current form, will likely need to be extremely large, not sure I've ever considered giving something 100 story points, but that may be necessary now. In any event, I think this project has an interesting real world benefit and working on it will help me build up some new skills and refine others, so I look forward to it, even if slightly intimidated right now.

9/25/19

Over the course of the previous weekend and this week, our team has been primarily working on drafting our Project Plan. Much of the work I ended up doing was converting our customer meeting notes into detailed requirements and user interaction tables. I got particularly invested in the user interactions, because up until this point, much of the requirements laid out by the customer were in a mostly unsorted form, so turning this into a truly end to end product in my head was quite fun. The other part that I feel I went potentially a little overboard on was the Risk and Mitigation section. Most of the risks were drawn from my fears of where the project could go wrong, so putting in a lot of effort to write up detailed plans for how to avoid or minimize these risks was very cathartic. All in all, with the plan mostly established at this point, the ability of our team to work so well asynchronously, as well as the depth of the core elements detailed in the plan, I'm feeling much more comfortable with the scope of this project.

10/9/19

Over the past few days I've been steadily learning php and the inclusion of jquery, ajax, sql into the mix. This has been all so that I could make the product list page. I have finished a basic version with all product elements drawn from a database that belongs to me on the uk cs server, that is interactive with the filtering selections of the user in realtime. I plan on working more on the hooks with other team member pages, but I'm very satisfied with how it has turned out considering all of these skills were non-existent a week ago.

10/25/19

I have previously added a connection with the product display page and fixed the ability for searches to be queried from pages that arent the product list page. The big announcement is the transition of the program files being run on a vm I have root control over. As such the address for all programs should now be able to remain static for the remainder of the project. http://172.31.147.179/StorefrontTestingApp/productList.php

11/9/19

I added a number of things since my last entry, products displayed are driven by the finalized database, product page handles the product permutations (different size/color/sku of items) items can be added to the cart, order history can be viewed. We recently moved over to another vm, this time no VPN is required making it easier to share with the client as well as all of our team members can access it simultaneously, meaning we can have a centralized database we all can work from instead of relying of recreating specific elements when testing another member's code. While I still have a few polishing tasks to do, I'm getting close to being able to start on the bug side of the project which I'm excited for.

11/23/19

I have started into the bug framework design and implemented 7 bugs that can be configured and set by using database calls that will eventually be entirely handled by seanna's admin page. I was a little sad that the bug calling in the code couldn't be reduced down to less lines, but I'm still happy with how minimal it is. In its current form you call a function bugCheck.php passing it the bug id number. This function will check the current logged in user against the bug assignment table, if the user is assigned a bug it will load the code associated with that bug id from the bug table. Regardless of success, the result of the function call is saved in a variable, if the variable is null then the default line of code is run, otherwise the loaded bug code is run. In essence to add a bug, you call bugCheck, and wrap the original line of functioning code in an if statement, running correct or bug depending on the result of the function call. This does require some level of actual code modification to add a bug, but it's almost identical between all 7 bugs I've made and the only effort is creating the substituted line of code which causes the issue.