Continuing from my recent post about a new concept we learned, we get our hands on an interesting programming practice called Continuous Integration. For this assignment, we were partnered up and create a command line interface for the WattDepot system. WattDepot is a web service that collects information about Oahu’s energy and power production/consumption. My partner, David Joel Lazarro, and I had to implement various commands to be used on the stored WattDepot data. We planned on splitting the commands in two and as we started working on our commands, we got our first experience of practicing continuous integration. We initially didn’t get the hang of it. We rarely commit to our repository, waiting until a full working method, both tested and verified locally, before committing our changes. But as we progress in this project we learned how to properly practice it. We did have some problems such as fixing merge conflicts since we didn’t really have any set design plan. As our code continued to grow, we finally found a good rhythm that tied our code into a unified look.
As for WattDepot, we implemented all the commands that were assigned. This is one of the first times where I had to build on someone else’s code in this scale. Having a good documentation and API really helped me understand the inner workings of the WattDepot system. This reinforces the importance of the third prime directives first taught in this class. The commands were mixed in terms of implementation difficulty, but I noticed some recurring similarities within some consecutive commands, which made the whole thing not so bad. Halfway through our given time for this project we were told improve our design strategy and implementation. This threw us of a little. The new strategy is meant to improve the scalability, reusability and efficiency of the command line interface. My partner and I understood the design strategy that was shown to us and we tried to implement it but to no success. This is the reason why we didn’t really have some good test cases for this project. The new strategy could’ve helped us design better cases instead of having just acceptance tests. Our methods were designed in way that it is constrained by the parameters preventing us from testing the instances of commands. This would’ve been easily implemented if we followed the new strategy’s design of having the commands in separate classes.
All in all I thought this project gave me an insight to the world of software engineering. Planning and implementing this project was just as fun as meeting up and working with my partner. I also thought that having a project that teaches us the importance of sustainability, especially in these times, is a cool way to really get our attention.
Our distribution file: Ekahi.
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment