Wednesday, October 30, 2013
Week 7 Implementation of Other Team's Design
In that week, we implemented another team's design. It seemed to be pretty straight forward. However, there wasn't really any communication from the other team as to check up on our progress. I did make some prior communication with them, but it was dead silent after that. Maybe if we had asked questions to them then probably we would have gotten communication with them. However, I think it was both of our faults as to where there was a communication break down. There wasn't any problems in implementing the design. But I think it is very bad practice to not communicate with your remote implementation team to check up on their progress. In the end, we got the design implemented to their specified API and class diagrams. I am not sure if there was any quality assurance though.
Wednesday, October 23, 2013
Week 6 - Project Design and Planning
In this week, we planned out our design for the implementation of the Search List. We had meetings throughout that entire week discussing about what kind of data structures we are going to use for this project. We came up with proposals such as using a Hash Map table, fly-weight design pattern, using an array list etc. We kind of ran into some roadblocks, I would think, when trying to decide on a data structure to use. The thing we were worried about was about deleting a node and trying to compensate for the remaining indices of the remaining nodes on the list that we should update all of the indices of the list taking up precious computational resources. We decided to stick with a simple doubly linked list for our design. We had our Design API Document and Class Design Diagram up on our wiki site for the other team to use.
Tuesday, October 15, 2013
Week 5 - Unit Tests from HELL
We were given part 2 of Project 1 to implement. We are supposed to create unit tests for a provided open program. However, when trying to do the unit tests. I personally ran into a lot of problems. Besides not being able to have time to actually look through the code and being a complete novice when doing unit testing, a whole lot of the methods are considered to be private only. It makes it very hard to try and pick which methods to unit test based on the Cyclomatic complexity plugin for Visual Studio. Also, Cyclomatic lies to you about the actual complexity of a method. It does not say whether or not a method is dependent on a more complex method! And that dependent method could be private! This also made it very hard to try and unit test it. There was also a lack of documentation that came with the code project making it difficult to understand some of the logic behind these methods. Also, there was no overall plan by the designer of the program to understand what their vision for the project is. It was mostly was trial by fire and running around blind in the dark for this entire project. I learned a lot of harsh lessons from this project.
1. Do not outsource your unit testing to a third party without documentation
2. Only developers of the code should do unit testing because they would have a better understanding of their own code
3. If you are outsourcing your unit testing, be sure to have access to the original developers to the code to understand what they are thinking
4. Provide Documentation
5. Provide Documentation
6. PROVIDE DOCUMENTATION
1. Do not outsource your unit testing to a third party without documentation
2. Only developers of the code should do unit testing because they would have a better understanding of their own code
3. If you are outsourcing your unit testing, be sure to have access to the original developers to the code to understand what they are thinking
4. Provide Documentation
5. Provide Documentation
6. PROVIDE DOCUMENTATION
Sunday, October 6, 2013
Week 4
This week consisted of talking about how to deal with conflicts at the work place whether they were big or small. It was pretty interesting to see real world examples that Ed gave which consisted of a person being assault by a power transformer! We also talked about our teams and the planning for our project. I think our team's project plan is decent albeit where we have the choice of what methods we would want to unit test that fulfills the assignment requirement of going within the bounds of the "Cyclomatic" complexity. I have created two unit tests with one more being a work in progress and I still have to create one more which needs a complexity of 7 or more. I hope to be able to get this done by tomorrow. However, I ran into a snag earlier because my teammates were using the latest version of Visual Studio (I have Visual Studio 2010) which led to a conflict of the .NET Framework. I was forced to download Visual Studio 2012 and this fixed the problem. Everything seems to be okay so far.
Monday, September 30, 2013
Week 3
Well, we went over some Perforce stuff and also a little bit of the homework that was due last week. Then we covered topics about meetings, planning them, and also the effectiveness of them. After that, we then talked about technical designed documents that show what has been done to implementations that are part of the software development process. Ed gave examples of technical design documents when working on the video game "Stranglehold" during his time as Director of Technology of Midway. We saw the changelists and the problems encountered when trying to fix certain bugs that were encountered when trying to design the systems for the video game (ex. camera, shaders, etc.). It was very interesting to see these design documents and also gain a very deep insight in working with the video game industry. I also have my own team formed up. I am not going to be able to attend our first Skype meeting, but there are also other very important resources at our disposal (the wiki, Piazza forums) to hopefully make this very coordinated so that we could get the first part of Project 1 completed before Wednesday's class.
Sunday, September 22, 2013
Week 2
This week, we talked about the advanced features of Perforce. We talked about making branches off of a project from the main line project making a new feature in the branch without it conflicting with the current main line project. The homework was pretty straightforward (we did most of it in class with the coding part). It was really interesting to see the advanced features of Perforce in action. I also really liked the merge feature when combining computer code. I think these features will be really useful when working on my video game capstone when working with multiple video game programmers. I am pretty excited to see what teams are going to be formed for next week.
Thursday, September 12, 2013
First Post
Well, I can say that this class is very interesting, and I am actually pretty excited to be working with people halfway across the globe! It was that time again to get reacquainted with programming again. I have worked extensively with C# last quarter so this was not that hard to start off. Also, the Fibonacci Sequence was drilled into my head when taking CSC373 Computer Systems I when trying to defuse a phase for the bufbomb lab for that class. The process of trying to program it was not that difficult. In the end, I got the output that was supposed to be made. I am very pumped to see how this class would pan out. However, I am a little bit more worried about Game Optimization.
![]() |
| The Fibonacci Program |
Subscribe to:
Posts (Atom)
