The last time we tried to start a Whole 30, it all just fell apart rather quickly – twice. However, this time, we have a much better plan for getting it kicked off. My wife started by creating a list of Reasons For Doing a Whole 30. She hopes that this will keep her focused on why she wants to stop reaching for the slice of cake, the can of Diet Code, or the bag of potato chips; she wants to be in the healthiest position possible when we start trying for another child; and she wants to have better productivity at work that the tiger blood brings on for her. For me, this is Marathon Training: Day -83.
Tomorrow, we start another Whole30 eating plan. The last two times I did this, it was both wonderful and horrible. In order to be able to look back on this experience one day and (hopefully) remember it fondly, I am going to attempt to put together a day-by-day activities list of how I
survived thrived during what will be my third trip. As with both of the other adventures, this started with a massive shopping trip to Costco and a bunch of food prep.
These are some notes that I typed up during an Azure Machine Learning - Data Camp that I attended at the Microsoft learning center in the Aon building. It was entertaining, informative, and all around a great session; unfortunately, it was entirely useless for my job, since this really has nothing to do with the work that I perform. On the plus side - I was able to recommend to my co-workers on the Analytics team that they should attend it.
Command Query Responsibility Segregation (CQRS) was not something that I easily understood. Martin Fowler did a thorough job of explaining it in often-linked post from 2011. However, I still did not quite grasp it at the time. I also wasn’t working on any project large enough or complex enough that it made sense to use a pattern with that level of depth. When I came back to the concept many years later while working on a significantly more complex project, I could put together all of the puzzle pieces but I still couldn’t quite see the whole picture. While researching the topic, I stumbled on a blog post by Cesar de la Torre from Microsoft - CQRS BUS and Windows Azure technologies. His picture was well worth the thousands of words that I had already read.
I may have gone down a long and twisted rabbit hole trying to figure out this problem, but I learned a lot about how model binding along the way, so I consider the whole experiment a productive use of my time, even if I end up ripping it all out in a few weeks. However, since I thought this would be a good idea, I figure others might find a good use for this knowledge. Thus, this is how I am using an explicity constructor when the input is in a
JSON format and parameter is bound using the request body.
Now that the Vigil Project has breached into the API layer, I started to learn all kinds of new information about what takes place before the Controller’s Action method is called and what happens after that method returns. The MVC framework, especially while using Visual Studio, make it incredibly easy to forget about all of the heavy lifting that the framework does – long before my code is ever executed. It is only when I wanted to start changing how pieces worked that I really start to see the true depth and breadth of what Microsoft has created. As I begin to discover new pieces of the framework, I felt that the best way to retain this information is to repeat it; and since no one around me wants to hear about all of this, I’ll just type it into a blog post.
As I was writing the previous post, it came as a shock how far behind my posts on the progress of the Vigil Donor Relationship Management System had gotten. I was going too deep into the code and making too many changes that I didn’t pause to write a post about my progress. My posts are 22 commits behind, and there are quite a few changes I’ve made to the workflow and to the application. As a way to catch up on all the missed posts that I should have written, I am putting this one together as a status report of the project/journey/solution.
In terms of workflow, I have embraced the GitHub Flow workflow (both for Vigil and for this blog). For my little project, since there is no discussion and no deployments (as of yet), the workflow is as simple as Branch, Commit(s), Pull, Merge, Delete. I like the way that a merge can squash all of the commits made on a branch, so that I have one summarized collection of everything that I did. This way, I can easily differentiate the content of a post by doing one per Pull Request / Merge. Hopefully, this process will now keep the posts coming regularly, help me be more concise about what should be in a post, and better contain runaway developing.