Loot

An e-commerce platform tailored to your preferences. Who knows, maybe you'll discover some hidden treasure!

Comment

Process:

  1. Brainstormed(for a long time)
  2. Moltin API meeting to understand what their API can do
  3. Assessed our strengths and combined to form a single group of 6 individuals
  4. Divided Workload (2FE + 2BE -> use pair programming) 4a. Progress check-in every 1-2 hours
  5. Picked our tech stack (what FE and BE we wanted)
  6. Set realistic goals → aimed to have a presentable and functional project
  7. Started hacking :)

Our process began with brainstorming during the team formation session, which lasted nearly 2 hours. We attended the Motlin API meeting and concluded that we would like to create a project that implemented their ecommerce API. After that meeting, one of our team members, Chris, wanted to create an app that would allow college students to barter services. With the help of his RA, he was able to come up with a new idea that would combine Tinder and Amazon - Swipeazon. This would allow the team to use Moltin API with the marketplace for a unique shopping experience. The original idea was that swiping right would buy the product, and swiping left would cause the app to show the user the next product. Throughout the coding process, the idea evolved to become an app that would add to your wishlist on a right swipe, remember items that you don’t like with the left swipe gesture, and add to your cart with a upward swipe.

The six-person team first began by assessing everyone’s strengths. There were two members that had skills in front-end programming, and two members that had skills with back-end programming. The remaining members were new to the competitive coding experience. The front-end programmers pair-programmed with the novices, allowing them to learn new languages and terminology during the app development process. The team reconvened to summarize what was accomplished every 1-2 hours, allowing everyone to stay on task and complete realistic goals by the assigned time. This allowed the team to ship a minimum viable product that sufficiently demoed our app idea within the limited timeframe.

The front-end programmers decided to use Ionic, a framework built on AngularJS and Apache Cordova, to design the app, due to the language’s simplicity and comprehensibility. Cari focused on creating the design of the pages and the app’s logo and icon. Chris converted these designs into actual pages within the app, as well as implementing API calls. Patrick and Spenser developed a backend api using Django’s rest framework that handled most of our custom backend needs including predictive analytics and strategic next-item-assignment. Both the front end and the backend interfaced with Moltin’s service, which provided us with an easy to use database of items and shoppers, and allowed us to quickly implement advanced functionality such as user specific online shopping carts.

The team planned to first work on the back-end and front-end tasks separately, and then merge both aspects together by Saturday night. Initially, this seemed like a great plan. However, during the second day, it was discovered that Ionic would be incompatible with Django - integration between the back-end and front-end code would not be secure. This lead to the team’s need to devise a new plan late during the second night. However, due to the precautionary steps we had taken in making sure we would have a functional app by the end of the hackathon, the team was able to proceed without being affected by the change in plans .

Choices + Motives:

  • Wanted to use Moltin API with marketplace for unique shopping experience (Tinder concept)
  • Ionic - Comfort - Easy/simple to use
  • Python - Comfort
  • Django - Prior use
  • Rest API - Ionic not useful with Django
  • “No one left behind” mentality

After attending the Moltin API Intro workshop on the first day, our group of hackers was impressed by the flexible and easy-to-use design of the Moltin API. Combined with our initial idea of creating a marketplace for students, our main goal for the event was to incorporate the moltinAPI into our project.

When deciding our tech stack, our main goal was to use programs we were most proficient and comfortable with using. Since Chris knew Ionic from prior projects, so we knew he could easily get a functional and visually appealing app up and running very quickly. Cari had experience with creating art assets in the Adobe Suite, so we used Adobe Illustrator and Photoshop for our logo and icon designs. Our two BE programmers, Spenser and Patrick, both had experience with Python, and one had used the Django Framework. We wanted to spend more of our time with implementing the moltinAPI, and understanding the interaction between FE and BE that occurs with sending requests/data between the two instead of having to worry about learning new languages. Unfortunately the Django Framework did not work well with Ionic, so we had to resort to using the Django REST Framework in order to take care of HTTP POST/GET calls.

Unlike most groups that had a max of 5 members, we formed a 6-person “super group” with the mentality of ‘no one gets left behind’. This mentality carried over into our group dynamic, because we were always there for one another when we were struggling and we were able to incorporate the less experienced members in our development process. Also, on the first night our team left at the same time, and literally made sure that ‘no one [on our team got] left behind’.

Successes:

The team experienced various successes throughout the HackBeanpot experience. First, the front end programmers were able to successfully integrate the moltinAPI into our project that allowed product information to be easily accessed and managed. Furthermore, our front end programmers developed an even greater understanding of Ionic, which allowed our group to develop our project’s mobile application. Next, our back-end programmers were able to further improve their knowledge of Python, and learn how to implement folders such as NumPy, a library used for scientific computing. The novice members of the team were able to experience Git for the first time in a more realistic setting (beyond school assignments). Every member of the group also continued to learn about new terminology such as APIs, stacks, back-end and front-end programming and were able to learn more about the back-end code of CSS The team was ultimately successful in functioning as a cohesive group in which every skill set was utilized. Communication was also a priority for the group in which we would debrief every one or two hours to set realistic goals and bounce ideas off one another. While there were two novice members in the group, we implemented pair programming to allow them to get the most out of their first hackathon experience. Using technologies that we were familiar with also gave us plenty of time to answer any questions that they may have about the coding project process. The hackathon has also served as an opportunity for experiential learning in which each member was able to apply skills learned in class to a real functioning project, and understand challenges faced by full-time programmers.

Beyond the scope of learning and practicing code, a big success of our HackBeanpot experience was being able to work with so many talented mentors and being able to interact with a variety of people from different backgrounds. This experience has provided each team member with new perspectives toward goal setting, and introduced new thinking methodologies on how to get more experience with coding.

Failures:

No hackathon is complete without suffering at least a bit of failure, and a compelling need to hack. Originally, our back-end was designed to use the Django framework in the more traditional sense, serving HTML files via templates with references to CSS and JavaScript files and using Django as an overarching container for the project. However, during our first iteration of the frontend-backend integration, we realized that the Ionic framework and the Django framework were not compatible in this way. Our back-end programmers (who both had no experience with web design) realized that the appropriate solution was to use the Django REST Framework to convert our back-end into a callable API and then use API calls to communicate between the front-end and back-end. And this worked! After many iterations, and some fantastic help from mentors late on a Saturday night, we successfully re-implemented our back-end as a callable API. However, the transition of the app from our local computer to the cloud ended up being significantly more difficult than imagined. Our back-end engineers attempted to use multiple cloud based hosting platforms, including pythonanywhere.com and heroku; however, neither platform proved to be viable options. Strapped for time, the team made the bold decision to abandon the predictive analytics provided by our back-end for the sake of the demo, in order to ensure that users of the app would be in the best shape possible for the presentations.

Acknowledgements:

The team would like to thank: 1. Alfred Ababio, for his help with branding, JS, advice for moving forward, and career advice 2. Michael Pelletier, for help with design concept and JS troubleshooting

Built With

Share this project:

Updates