ihtfyp | 6.148 (web programming competition)

-



January 2016 has been a month-long 6.148 hackathon - my friend and I often worked on our web app until 4 am! We're hosting it at ihtfyp.herokuapp.com.

Currently, we made the semi-finalist round of the competition! (We'll find out how we did tomorrow!) You should also vote for us for the Webby awards at http://6.148.scripts.mit.edu/2016/webby/ihtfyp :) :) :)

The theme of this year's 6.148 was "remember the future" so we created an app that would be the future "lost and found box" for the MIT community. As of now, if you lose something, it's hard to know what to do: do you dig through physical lost and found boxes around campus? Do you ask your friends on facebook to look out for your lost item? Do you post a wanted poster?

We wanted to build a reliable, universal way of matching lost and found items, so we made ihtfyp. (We were in a punny mood when we came up with the name - our team name was MITeam)

We learned how to use a lot of tools along the way, including d3.js, heroku, nodemailer, body-parser, google maps javascript api, node.js, express/express-generator, client-sessions, motio, mongodb/mongolabs, bootstrap, jquery/css/html (and figured out when to use javascript callbacks!). You can check out our code at https://github.com/lizziew/ihtfyp

I think some of our coolest features were:

  • the matching algorithm: we had to pay a lot of attention to detail, and carefully update all of our mongodb collections so they were in sync 
  • verification questions: this was how we ensured that items got back to the right people. The questions are item-specific. For example, if you claimed you lost cash, you have to specify the amount. If you lost a shirt, you have to describe its color(s). We then send the answer to the finder to be confirmed. 
  • email notifications: we wanted ihtfyp to integrate easily into users' lives. That's why we decided to keep users updated via emails every step of the matching process. 
  • pusheen: including a hidden easter egg :) 

We did a lot of user testing, and think that our product is very easy to use (even if it's the user's first time!). Furthermore, making this a web app was appropriate because it fit user scenarios.

In the future, we hope to address spam issues - methods we're currently considering include human moderators and captcha.

After IAP, we're hoping to launch ihtfyp and help out the MIT community!






Popular posts from this blog

Building A Toy Language Interpreter in Go

-
Image
In this post, I'll be giving a high-level overview of interpreters, why they're interesting, and how they work. I'll be referencing my repo, go_interpreter , which is a simple interpreter written in Go for a toy language. The figure below shows the structure of our interpreter with an example input: What is an interpreter?  An interpreter is a language processor that seems to directly execute the source program on user input: In contrast, a compiler first takes in a source program and translates it to an executable machine code target program. Then, the user can pass in inputs to this target program and get outputs. In general, an interpreter is better at reporting errors since it's processing statements one at a time, and a compiler is faster at generating outputs from inputs. In this post, we're going to go over a simple interpreter that is capable of supporting: integers, booleans, strings, arrays, hashmaps prefix, infix operators index opera
Read more

Space Race: a simple Rust game built on the Bevy framework

-
Image
When I saw a post announcing the release of the Bevy framework  (an open source game engine written in Rust), I thought it'd be a fun way to learn Rust.  So I made Space Race , a 2 player game on top of the Bevy framework. How to Play The Astronaut moves around collecting jewels (using WASD keys). The Alien moves around trying to catch the Astronaut (using arrow keys).  The Astronaut wins if they collect at least 5 jewels and make it back to home base before the Alien catches them.  The Alien wins otherwise.  Things I learned about Rust  I had a lot of fun making & playing this game, and also got some hands on experience with Rust like working with structs enums vectors iterators traits dyn trait vs impl trait  dyn trait is used for trait objects, which are fat pointers made up of 1) a pointer to the value 2) a pointer to a vtable. A vtable is a table of methods, where each method points to its implementation, generated once at compile time. Each instance of a type that impleme
Read more

Building a Toy Language Compiler in Go

-
Image
A follow-up to my previous post about building a toy language interpreter in Go. Throughout this post, I'll be referencing my repo . We'll go over a compiler which translates source code to machine code, and then a VM to execute this machine code. What is a compiler?  A compiler takes source code and translates it to executable machine code . (See my previous post for more details.) The figure below shows the high-level architecture of a simple compiler. Like the interpreter we built previously, our compiler has a lexer and a parser which turn our source code into an AST . This is our compiler's frontend . However, that's where a compiler diverges.  The compiler may translate the AST into at least one internal representation (IR) . The IR(s) may be represented using any data structure (even another AST!), but they should follow two rules: (1) be easy to produce, (2) be easy to translate into the target machine code. The IR can also be optimized
Read more