Portfolio Category: Web Development
Thoughts:
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 :).Project:
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:- 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.
- 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.
- 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
Goal/Rules:
- Using tech to solve a problem, be funny, create a product, or start a business!
- Mobile apps, websites, software, etc. are all options!
- Prizes: $1000 individual; $2000 team
- MOIT Judge: Heather Hudson
- MOIT Choice Prize: $2000
Project:
Problem. Currently when searching for a lost pet, there are many different sites to offer services of searching for pets, but none really aggregates the search process. There's also a missing market for animals that have been sighted but not actually found. Our project hoped to fill the gap. Solution. Paw Patrol -- an app that facilitates quickly reuniting pets with their owners. Features. Aggregated information from top pet finder sites such as Barks and MD SPCA. Functionality that allows people to report sightings of animals/pets that have been seen in areas -- which gives pet owners good information to aid in their search efforts. Functionality that allows for people to report their pet missing. Functionality that allows users to search descriptions for certain keywords, allowing them to look for pets that match their pet's description.Post Mortem:
We had a great mix of team synergy for this project. We had two front end developers and two back end developers which made the workflow go well. But with any teams there are some things in hindsight that I look to address for the next hackathon:- Fleshing out all external APIs - There were some great ideas with APIs to use, however a major API switch, mid-project made a large part of work that I'd previously done, insignificant. Although the new API proved to be a better tool, hashing out the external libraries earlier would have helped us get much more of what we wanted to get done, completed.
- More mid-development progress meetings - We were all sitting at the same table, which made communication great, however we did have some times where we could have benefited from more small progress updates. We could have also addressed what was hindering people from moving forward and check to see if tasks could have been re-allocated in order to save time. However, we did get a lot accomplished within the time allotted!!!
Baltimore Hackathon
Take a Look
Goal:
Create a full game within 2 days!Features:
Protagonist. We had 3 main characters in the game. The first was the Zombie Psychiatrist, whose goal was to eat a certain number of "healthy" brains in order to advance to the next level. Characters. We had two other characters, a healthy patient and a crazy patient. The Zombie Psychiatrist's goal was to eat the healthy patient's brains, while avoiding the crazy patient's brain because it would kill him on impact (sad panda). Power Ups. There were 3 main boons for the game: 1) A sweater that granted the zombie a defense buff that would allow him not to die on impact from the crazy patient. 2) A pill that could be thrown on the crazy patient, turning her into a healthy patient. 3) A hypnosis wheel, that could redirect the path of the crazy patient when thrown at her. Game State. If the Zombie was able to avoid colliding with a crazy patient while eating enough healthy brains, he would advance to the next level. Game Setting. The game takes place in a hospital with a dystopian feel, after some type of catastrophic event!Post Mortem:
We worked together really well and really quickly. Some of the issues that we faced was not only developing the game, but getting everyone accustomed to using Unity 5. Out of the 4 of us, one of us had extensive experience using Unity 5, but with 3D tools, and 2 of us were using Unity 5 for the first time. Here are some takeaways:- Discuss tools/engines more in depth at the beginning. Perhaps a more common ground could have been found in regard to development tools to use.
- There were pockets of time wasted attempting to get some items working that weren't dire to the game. Perhaps a priority list could have been made at the very beginning, allowing the team to work in order of importance.
- I wish that we could have worked together after the game to get it completely finished, however, as it stands, I am taking Unity 5 trainings to get the game completely finished. This game will always hold a special place in my heart, 1) It's a game about zombies, 2) It's the product of my very first game jam!
Game Jam
Take a Look