This past weekend, I graduated, which was very exciting, of course.  My last class before I could officially graduated was my Capstone project.  The only way that I can really describe this project is that it was an 8-week project that involved 3 other classmates, 5 weeks of documentation building, and less than 2 weeks of programming.  Through what felt like a shady, underground deal, I was selected as the Project Manager by my peers, which ultimately turned into me being the Scrum Master and Tech Lead as well (seriously, do not try this at home).


We already had our group set and each of us fell within a wide array of technical knowledge.  The only thing that came to my mind was that I wanted to make everything as simple as possible.  When I was reviewing the class schedule, the 3-week sprint cycle stood out to me, so I knew that I wanted to keep the project as simple as possible. Another major thought that came to mind was presentation and the stack.  Since my school taught Java, I observed my peers discussing database connections, Maven builds (yeesh), Hibernate... all within 2 weeks of coding, on teams with limited and varying levels of experience.  One thing about these types of builds, is delivery and access. I immediately started to wonder, who would download and run an app to do a quick conversion?  I didn't want to do a desktop application for that reason alone, and I immediately wanted to do a simple, clean, web application -- client-side only :).


Description.  The task was simple... Create a currency conversion application -- no rules, no restrictions. The Stack. Very simple, very straightforward.  We used Angular JS clientside and connected to a free currency exchange API. Notes: Again, keeping with the simplicity theme, we saved all of the assets to the server and made references to them in our application through several JSON objects containing the metadata that we needed.  All currency information was queried upon each request, there was no need for caching the data since the API we used didn't do real time updates, so there were no query limits.

Post Mortem:

Because it was an accelerated course, we weren't given much time for development.  Our weeks were spent editing class diagrams, activity diagrams, and other SDLC documentation as anyone would expect from a Software Engineering class.  As the PM, my goal was really to keep things organized, create a doable timeframe, and leave plenty of time for testing.  Here are some things that I would change if given the time to:
  1. Creating a more robust solution - If this project timeline was longer, I would have liked to do some type of account creation step that saves user's queries and created a history log of past queries. I would have done Java backend, some datasource connection, and some type of authentication API.
  2. More check-ins with the team -  Although we had really decent communication, we only did 2 weekly stand ups.  I would have liked to do more pair programming with the team as well as have more time to discuss the design of the project overall.
  3. More extensive Financial API  - Use a paid API, the API we used was just enough to demonstrate the behavior that we wanted.  The actual resource only allowed conversions from a limited list of countries, most services that provide a more robust solution, had a hefty price tag associated with it.  It would have been nice to do a bit more from that aspect.
Capstone Project

Take a Look
One of my assignments in my Computer Graphics class really stood out to me because we were allowed to do something fun.  There were parameters on the project that were set, but we were allowed to choose the content as we saw fit.  On this assignment, I wanted to see if I was able to create a basic scene from one of my favorite games growing up as a kid, Mario Bros.


Utilize OpenGL + Glut to make a scene from one of my favorite games!


Animation.  Part of the assignment had to be animated, utilizing the standard sleep() function, along with Glut's display features. No External Libraries.  Originally, my mind went insane with the possibilities of what could be done with this assignment.  But the time frame was tight and given that I had to write our my physics functionality, the scope of the project was limited -- but taking the time to build out some of my own collision detection + physics was more beneficial than using an external library. Limitations. The assignment dictated that I still had to demonstrate the basics, so some elements were a part of the project, simply because it had to be.  I went with a big pink bouncing ball as the main element just because the ball was the best way of combining 6 or 7 of the mandatory things off of the checklist.  The lightning, collision, rotating, parabolic launching, scaling, and transforming were all applied to the ball.  I got to have more fun with the background especially with getting familiar with the different coordinate systems within OpenGL.

Post Mortem:

After I completed this class, my fascination with computer graphics grew 100 fold.  One of the major limitations to the project was that I was taking 20 credits during the Spring semester so there was the physical limitation of time.  Looking back I would have spent a little more time on the physics engine.  Although the physics functions met the requirements for the assignment, I would have liked to spend even more time fine tuning and adding some of the physics functions that I used in my Game Development and Design class previously.  In that class we used JMonkey, a Java based Game Engine.  JMonkey had quite a few physics functions that I could have recreated within my project.  Most of my thoughts after the project centered around wanting to be able to dig deeper into a specific area of OpenGL and/or graphics programming in general.

Take a Look