Day 37 – Auxano Sprint 6

It’s still difficult to believe we’re in boot camp week 8 of 8, sprint 6 of 6, and almost done with this crazy experience and on to new things (unless we stick around on project Auxano for a while longer).

Scrum: Yesterday we planned out our sprint 6 tasks. I started the afternoon off by separating the Engagement model, controller, and views from the Time Activity model, controller, and views. I managed to do that pretty quickly and get that change pushed after all tests were working and the app was running smoothly post-changes. After that, Dave and I started working on Engagement controller and view stuff, and I threw together a simple engagement list with nonfunctional edit and delete buttons. Today I’m going to add delete functionality, and dave is working on edit functionality so we’ll have all of the CRUD operations covered.

Friday I suggested the group collaborate on a master list of interview questions for our board reviews next week. I shared a google document with the team and hope that everyone contributes to it over the next few days. I know the guys have been studying, so I’ll be poking them to share their knowledge with the rest of the group. After typing the previous sentence, I went and answered a few questions for good measure.

Today I worked more on writing some tests for our Engagement controller and getting a delete button to work. Dave continued working on edit, and we got some help with passing things through controller action methods and then returning a view with the necessary object.

Much, much later…

Huge changes made tonight. I’ll need to talk to Dave about what changes I made to his commit (he beat me to the push) in the morning, but it’s not actually that big of a deal. There were just some minor naming differences, and I learned a few things which I added to the Edit parts of the controller and view.

I made a design decision on my own tonight that I (might) need to bring to the group for review. Since our Time Activities are tied to an Engagement (can’t have a time activity without an engagement attached to it), if you try to delete an engagement, the database flips out and breaks because time activities are dependant on Engagements. This will not be a problem when deleting time activities, but deleting engagements is another story. I decided to do a half-solution and just put a “Deleted” boolean on the Engagement class and in the Engagement database table that we can flag when we want to “delete” an engagement, and instead of actually removing it from the table, it will just allow us to filter it out of our gets without breaking any time activities that were attached to that engagement (in theory). We’ll have to do further testing on this.

Which brings me to my next idea… Should we, instead of having an engagement on TimeActivity, just set the values (class/department/service/client) on each individual activity based on the engagement being pulled in in the form, but not make the database tables rely on each other? I’ll discuss this tomorrow. Gah this will break so many tests. *sigh*

I worked until about 10:30pm today, so I’m going to take it easy tomorrow. Definitely watching the USA vs. Germany game!

USA! USA! USA!

–R

“You can fail at what you don’t want, so you might as well take a chance on doing what you love.”

-JimCarry

Potential Project / Client: http://www.ogsys.com/

SQL Update: http://stackoverflow.com/questions/15246182/sql-update-statement-in-c-sharp