Originally written by Richard during JumboSmash 2017. This is really just a collection of suggestions to make the most out of this tradition. Feel free to modify it based on your experience
JumboSmash is two Tufts traditions smashed into one. The first tradition is to enable seniors to connect with each other during Senior Week. The second tradition is for students (traditionally CS) to make a thing entirely from scratch.
The first tradition is cool, but it's really the making tradition that we're interested in preserving. Rarely does a project ever have a guaranteed audience before launch. The hardest part of any project is not building it, but getting people to use it. This is often why people lose interest in their own projects. In this case, you can guarantee that there will be an audience, which means you'll work harder, learn more, be more ambitious, take more risks, and build a better product.
Hopefully, the following list will help preserve this second tradition.
- Try new technologies
- Don't just build what you know how to build. Did mobile VR / AR / drones / AI / chatbots become ubiquitous? Is there a hot new framework / language / platform? Try them out! You don't have to use something cutting edge, just don't use the exact same tools you've used in the past.
- Prioritize diversity in the team
- Diversity of skills, backgrounds, race, gender, etc. Shouldn't have to explain why.
- Everything built in house
- Exceptions: open source frameworks, your own past material, and 'provided shit' (next section). Don't take stuff from past JumboSmashes without first asking and giving credit. This includes marketing, design, software, and text material.
- Keep the basic premise relatively in tact
- Users indicate interest and JumboSmash facilitates connections of mutual interest. This consistency is important for maintaining the hype for future generations
- Reach out to past generations for help!
- Contact information below
- No passive fucking "PM"s
- The project lead must be heavily involved in building the product (software / hardware). No marketing / ELS-only leads. This is probably my one strict rule. JumboSmash is to remain a tradition amongst builders.
- Make it yours
- Rewrite the rules if you think it will lead to a better experience and enhance / preserve the tradition.
- jumbosmash.com url
- jumbosmash slack
- jumbosmash github repository
2015: We thought it would be super fun to build a localized, college-seniors-only Tinder app for one week. And it succeeded beyond our most wishful fancy. Of a graduating class of around 1000, we had 500 active users for the week of operation. Very fun, very rewarding. We even know some long-term relationships that formed!
- Backend: Django and Postgres
- Frontend: Web, Backbone.js
Team: Sam Purcell (Frontend), Tyler Lubeck (Backend)
2016: Based off of the previous year's success with the app idea, our team decided to continue the JumboSmash tradition. After getting source code from Tyler and Sam and realizing that we wanted to build it in our own technologies this time around, we scrapped the old project. Reception was wholly positive with ~600 users and ~700,000 swipes in the week. Would highly recommend implementing a k-clique approximation in the future, we only got to enumerating all the 3-cliques.
- Backend: Golang, Python
- Frontend: Ractive
Team: Teddy Cleveland, Todd Pollak, and Nikhil Shinday
2017: We went really hard, arguably too hard but learned a ton as a result. 900 users, 1m swipes in 24 hours, 5m total. Our focus was to build a cross-platform app using Facebook's ReactNative. At a high level, our stack was:
- Backend: Firebase (image hosting, auth, chat) and Heroku (user information, most of the logic)
- Frontend: Facebook's ReactNative (iOS and Android)
- Static Website: ScrollMagic, Justin's sweat and tears, hosted on GitHub
- Distribution / Beta testing: Fastlane
Team: Richard Kim, Elif Kinli, Jared Moskowitz, and Jade Chan on mobile / backend; Bruno Olmedo and Shanshan Duan on Design; Justin Sullivan on Web
Images: Screenshots, Progress.gif, Overview, Posters
- May 2, 2017: Richard Kim - wrote the thing with help from Yuki
- May 13, 2017: 2015 and 2016 descriptions added
- Oct 10, 2017: Links to emails fixed