Week 12 (July 20 – July 24)

This week was very similar to the last with an emphasis on performance increases. There were several meetings dedicated to improving our performance or determining if we even can improve. I suggested using bulk insert for saving data to the database instead of our current method of batch inserts but we decided that we shouldn’t do this so we can more easily debugging problems with saving, and also to get more detailed logging. We’ve also recently been testing our application on our dev server.

Week 11 (July 13 – July 17)

Things have died down a bit now. Most of my work consisted of testing and debugging our application. Also because of our big application change there was some broken code. I spent a lot of my time fixing erroneous and buggy code, ass well as repairing some of the unit tests. We`re starting to realize that the application may take longer than 15 minutes so we`re trying to increase performance.

Week 10 (July 6 – July 10)

This week was crazy busy. I believe I worked around 60-70 hours, however I’m starting to get used to the long hours, time really seems to fly at work now. We ran into a big problem this week that really set us back. During our integration testing for the application we realized that we were saving duplicate data to the database which was causing exceptions to be thrown. At first I thought there was a bug in my database writer but after a couple hours of debugging I realized that the problem was actually because of how our stop based freight moved object was structured. This meant huge changes to our application. In the end we decided the simplest and most effective solution was to have the stop object be set up like a graph where each sub object relates back to its parent. This way if you were given any part of the stop you could “walk” across the entire freight move. We also added functionality to reuse objects when the data is the same instead of creating new ones. This way we could reuse references and only save an object once per freight move. This wasn’t the ideal solution but it allowed us to keep the object at a stop level so as to not break all the existing methods in the application. We had to rush this fix and begin testing again hence the long hours but I’m starting to enjoy the coding and free pizza.

Week 9 (June 29 – July 3)

Time is flying by and I can’t believe I’m already a quarter of the way  through my term. I was able to get more work done on the writer and run some tests and the results are good, I’ve now begun looking at ways to improve performance and have started testing. There was some integration testing starting near the end of the week which is promising. I do believe the deadline will be moved back to August for the application however. We’ve started to realize exactly how big this project is, as is everyone else in the company. We’ve been having more meetings trying to better design our application and try and be ready by August. I’ve also been staying late a lot more, this includes free pizza however so it’s not that big of a deal. On a side note Canada day was pretty fun, great way to break up the week.

Week 8 (June 22 – June 26)

I have made really good progress with the database writer. I have basically finished the data access layer for the raw freight move data, and have now begun planning out how I will save the analyzer data. Since we are storing data at a stop level, the current version of the writer is designed to call one save method and pass in the stop object, the writer will then call several individual and more specific writer for each inner object. I believe the writer for the analyzer and calculator data will work in a much similar way. We are approaching July now and there are growing concerns that we won’t make our deadline. We haven’t done much testing on our application (so far only unit testing not much in the way of integration), and we don’t know much about how much memory the application uses or if it can be completed in under the 15 minute timeline. We’re starting to have more meetings trying to figure all this out. I’ve begun staying late to help the team however there isn’t much believe that we can meet the deadline.

Week 7 (June 15 – June 19)

I started working on the database writing portion of the application; the other co-op student will finish off the csv reader. I believe for the most part this will be my own mini project which is exciting. I’ve only begun to lay the groundwork for it but it has definitely given me some really important practice designing and implementing my own software. The full timers have begun work on the calculator portion of the application, as well as creating unit tests for the analyzer and calculator. I’m starting to be given way more freedom and responsibility on this project, which is exciting.

Week 6 (June 8 – June 12)

Our work on the csv parser is almost done and it works well and fast. The work for the analyzer being done by the full time programmers is also coming along well. Working in tandem with the other co-op student on the csv parser was a great introduction to pair programming. I’m really starting to get the hang of agile development. I started learning about a concept known in the company as BOL reconciliation. Our application needs to be responsible for this and it seems really confusing. It’s definitely something i’ll have to learn moving forward with this project however.

Week 5 (June 1 – June 5)

The other coop and I have switched gears a little on our design for the csv reading part of the application; we have decided to use an existing nuget package for parsing the file, and we have set up the application to read all the different data files and build freight move objects in parallel. Our ssis package that builds the csv will probably be replaced by another teams application so we don’t have t support it, assuming we can convince them to take it on. We are all working in parallel on the application now. The full time programmers are mostly working on the analyzer, while the other co-op and I work on the builder.

Week 4 (May 25 – May 29)

The hardest part of this application seems to be the transition from one phase to another. We have most of the design done for each individual component but aren’t sure about the best way to move from one step to the other. We have decided that the application should save all information given to it, that all the freight move objects, eval objects, and KPI result data will be saved to the TPS database. We also have performance requirement that states that the application should complete in under 15 minutes. We don’t know how reasonable this is yet but that is the current goal. Coding for the application finally started later this week. We aren’t sure about the current deadline of June and I believe it will be moved to July. The other co-op and I ran into a problem earlier this week with our ssis package. Apparently our queries for getting all the data were way more expensive then we anticipated, and the additional load of us repeatedly testing the package almost took down an important production server. Thankfully this didn’t happen and we fixed the problem. My team lead did say that if a programmer doesn’t come close to doing that at some point they aren’t working hard enough, but I believe that was just to make me feel better. The other co-op and I have now begun working on reading the csv files and building freight move objects