09 Aug 2016
· 3 min read
Another year, another HackMIT FAQ readers experiment. From May 31 to
August 7, we had the following item in HackMIT’s FAQ:
Like last year, the experiment wasn’t particularly
scientific. We just wanted to give people the opportunity to email us random
Last year, we did a qualitative analysis of the emails we received, so for
a change, this year, we took a very quantitative approach.
We had 227 unique individuals email us (compared to 493 last year). We
responded to 220 of these people, giving us a response rate of 97% (up from 80%
The distribution of response times was pretty good:
A handful of team members were responsible for the majority of responses:
Some team members got pretty competitive trying to be the fastest to respond to
Even though the experiment began on May 31, we received a lot more email once
registration opened on July 1st, receiving the greatest number of emails on
People did sent us email at all hours, but the morning seemed to be the least
popular time to send messages:
mit.edu were the most popular email domains
among FAQ readers:
Emoji were quite popular in our emails. Among all the emails that were sent and
received, here are the most used emoji:
Apparently, the HackMIT team really loves emoji, being responsible for 67% of
the total emoji use:
Luckily, the majority of emails we received were positive (according to
a sentiment analysis engine):
Here’s the most negative email we received:
And here’s the most positive:
Okay, so most of this data analysis is pretty silly. It’s not meant to be taken
too seriously! We had a great time going overboard and making pretty graphs.
In case anyone is curious about how we did the analysis, here’s a short
summary. We archived all the emails that were sent to
and after the conclusion of the experiment, we loaded all the data into
a Jupyter notebook using Python’s mailbox library. We
analyzed the data using NumPy, pandas, NLTK,
TextBlob, talon, and emoji, and we made the
graphs using matplotlib and Seaborn.
Thanks to Claire, Kimberli, Stef, and the rest of the
HackMIT team for feedback on this post!
31 Jul 2016
· 2 min read
— shared on
Product Hunt and
I do most of my software development in my terminal, with my trusty tmux / zsh
/ vim setup. When coding, I frequently switch back and forth between my
terminal, which has a dark background, and my web browser, where sites usually
have light backgrounds.
One big problem with this setup is that my laptop’s backlight is either so dim
that I can’t read the text in my terminal or so bright that I’m blinded by
looking at websites. The problem is especially bad at night.
Many laptops support automatic brightness control, but it’s usually not very
useful. Both macOS and Windows support setting screen brightness automatically
based on ambient brightness, but the feature rarely comes in handy. It seems to
cause more harm than good. I keep it disabled on my laptops.
A Better Way
What if laptops set screen brightness automatically, but based on screen
contents rather than ambient brightness? I did some research, but I couldn’t
find any software that does this, so I wrote my own tool.
This is how Lumen was born. Lumen is a tiny menu bar app for macOS
that magically sets screen brightness based on screen contents.
Here’s what it looks like in action:
In an early prototype, I had hard-coded relationships between the lightness of
screen contents and the backlight settings that I desired. This turned out to
be somewhat annoying, because my preferences changed slightly depending on the
environment that I was in and exactly what I was doing. I needed to make the
It’s annoying to have lots of explicit on-screen controls for something that
should be simple, so I implemented something that I think is a pretty neat
feature. As it’s running, Lumen monitors how you change your backlight settings
using the keyboard. If you override anything that Lumen does, it takes note,
automatically learning your preferences. The
implementation is not too complicated, but I think it’s
a neat UI paradigm.
Source Code and Downloads
Lumen is open source, released under GPLv3. There are binaries
available for download too.
03 Jun 2016
· 4 min read
— shared on
Most personal location sharing services are people oriented — the
applications are designed for following specific people. For example, with
Find my Friends, you can share your GPS location with
selected contacts. Instead, what if a location sharing service were designed
for following people’s presence in a single physical space?
Recently, I built and deployed a location sharing system designed for a
particular physical space to solve a specific problem. I’m part of a student
group called HackMIT, and we have an office in the student center
where we like to hang out. However, it’s no fun to hang out in our office when
nobody else is there, and it’s kind of awkward to always be asking “is anyone
in the office?” on Slack. So we wanted a better way of knowing when people are
there. Maybe this sounds slightly ridiculous, but it’s a real problem we had.
Our solution was OffiX, a WiFi-based presence tracking system for our office.
Such a system that inverts traditional location tracking has some interesting
properties. Based on feedback I’ve gotten, space-oriented systems feel less
awkward to use than person-oriented systems. Furthermore, even though it’s an
always-on system, the space-oriented system better respects people’s privacy,
because their location is only shared when they’re in that specific place.
Plus, in our case, people’s privacy is enforced by the physical limitations of
the implementation: the system cannot possibly be used to track people outside
OffiX was designed to require minimal effort to set up and use. We have a web
interface for initial setup, where each individual creates an account and adds
the wireless MAC addresses of their devices:
And that’s it! After that, people can see who is in the office by looking at
the web interface:
We also have a Slack interface, so people usually end up using that over the
The Slack interface even has push notifications to
#social for new arrivals
to the office:
The technology powering the system is quite simple. It uses WiFi for tracking
presence, so it doesn’t require any sophisticated hardware. Here is how it
works: every couple minutes, wireless-enabled devices broadcast a special type
of 802.11 frame called a probe request. The frame includes the device’s MAC
address, which is a globally unique identifier. Once people register the MAC
addresses of their computer and phone to create an association between their
identity and their devices’ addresses, it’s possible to monitor presence by
passively monitoring WiFi signals. All it takes is a wireless card supporting
monitor mode and a little bit of C code to extract the data.
The physical setup is pretty simple, too:
Before deploying OffiX, my hypothesis was that people would visit the office a
lot more often as a result of deploying the system. And luckily, it did turn
out that way — OffiX actually had a pretty huge impact on the frequency of
people hanging out in the office. Even when people knew the office was empty,
they’d go there, knowing that others would hear about it and probably come hang
OffiX significantly increased office traffic, probably helped most by the Slack
integration, especially the “$name is in the office!” announcements. Now I hear
stories like this every so often: “I was walking by the student center, and I
was going to go home, but then I saw that someone was in the office, so I went
there to hang out”.
When I asked my friends about their thoughts on OffiX, they had some
interesting things to say:
As is the case with a lot of projects I work on, the source code for
OffiX is available under a free software license. If you do anything cool with
it, be sure to let me know!