In the city

What’s up Internet — it’s been a while since I last posted. My school work, activities, and jobs have kept me busy, which has left little time to blurt out or reflect on random thoughts.

However, once again, it’s summer and I have the luxury to jot down some thoughts. This time around I’m living in San Francisco working at Yelp! I really love it here and am happily digging deep into my first project.

Seeing that I didn’t really fulfill my commitment towards one post a day last summer, I have downgraded my expectations to a few posts a week. However, I have a feeling this time around it will not be as difficult to come up with thoughts to jot down as before. I’m learning so much at work and have many curiosities to explore. I already have many tips, experiments, and practices that I want to share!

On another note, I’m also making an effort to explore the city as much as I can. Even though I’m from Berkeley, I rarely have the time to trek across the bay into the city. Living in the center of San Francisco really opens the doors up to doing anything.

Just a day after I moved into my apartment, I went to a tea house (in an attempt to be sophisticated), where my brain was steeped in way too much tea knowledge.

All in all, I’m excited to be here. Summer, let’s roll!

Some cool python eggs

Try them out!

import this

import antigravity

from __future__ import braces

Deploying a child folder to Heroku

When I’m working on a project with many different parts, I will often place different components into different folders.

I’ll end up with a Git repo that looks something like this:

/parent_folder
    /child1
    /child2
    /child3

However, if child1 is the only folder I want to deploy to Heroku, I run into some errors. Heroku states that the pushed root directory must contain the Procfile and app.py (or whatever one decides to name their main app file).

To solve the root directory problem, I pushed the subdirectory with git-subtree. Downloaded the zip and ran sudo ./install.sh to add the plugin to git.

The following will push only your child directory to Heroku

git subtree push --prefix frontend heroku master

Pro-tip for late night walks

Walk around with with a police scanner app on full blast as if you were a undercover cop.

Python dictionaries

I’ve been recently implementing a memoized version of the Levenshtein Distance function that requires the memoization dictionary to be reset after each use. My original intuition was to use d.clear() for the dictionary, but I wondered if creating a new dictionary would be any faster.

The results suprised me:

$ python -m timeit -s "d={}" "for i in range(500000): d.clear()"
10 loops, best of 3: 55.3 msec per loop

$ python -m timeit -s "d={}" "for i in range(500000): d=dict()"
10 loops, best of 3: 176 msec per loop

$ python -m timeit -s "d={}" "for i in range(500000): d={}"
10 loops, best of 3: 29.2 msec per loop

As you can see, the act of creating a new dictionary gave me two very different results; one better than using the clear method and one worse.

Matt Good over at Stackoverflow explains the nitty gritty:

Python allocates a fixed-size “free list” where it can quickly allocate dictionary objects (until it fills). Dictionaries allocated via the {} syntax (or a C call to PyDict_New) can come from this free list. When the dictionary is no longer referenced it gets returned to the free list and that memory block can be reused (though the fields are reset first).

Since the {} syntax is handled in byte-code it can use this optimization mentioned above. On the other hand dict() is handled like a regular class constructor and Python uses the generic memory allocator, which does not follow an easily predictable pattern like the free list above.

TL;DR: Use d = {} when creating dictionaries for faster execution.

Taking on a 32-hour hackathon solo

This roundup comes a little bit late (by 2 weeks) because I’ve been busy moving all my stuff back into my apartment. A couple weeks ago I attended a hackathon at Box’s headquarters. The hackathon was great; free delicious food (Chicken Tikka Masala wraps), high profile speakers (CEO of Yammer), and a great work environment (except for those really hard chairs that were hard to sit in for durations of more than an hour).

The event

I haven’t been to many hackathons, but when I attend I usually go with friends that I know and am comfortable working with. This time, however, nobody around was available to go. In retrospect, I’m glad I didn’t go with anyone. Going alone served as that extra bit of motivation to go meet and greet others more openly.

There was a huge a variety people there: a few juniors and seniors were still in high school, some college students from across the world (Singapore and Carnegie Mellon) were relaxing from their internships, and even a few full-time software engineers (I could tell by their gray hairs) were trying their hand at the hackathon’s grand prize.

My project - Drop Channel

My project was essentially the Mac OSX’s AirDrop ported to a web application with some minor differences. AirDrop provided the user with the ability to share files with another Mac user via a wireless/wired network.

However, AirDrop has a few gnawing stipulations:

• Doesn’t work with Windows or Linux
• Can’t share with people on different subnets and/or networks
• Can’t share with a group of people

Drop Channel is network agnostic; it only cares about your physical location. The canvas provides an area for users to add files to share to anyone within a 50 meter radius. The canvas can get cluttered if many files are being shared, so channels are used for de-cluttering the visual drop space. Channels are labeled by different colors.

Files, as well as file placement on the canvas, are synced with all users who visit the website. To do this, I used Firebase to synchronize everything. Firebase is a backend that makes building real-time apps stupid-easy; it essentially synchronizes JSON data on all clients painlessly.

For handling the files being uploaded, I used Filepicker.io. It is by far the easiest API I have ever used for file management. I included a total of 2 lines of code to handle all file upload interactions (which includes drag and drop file handling, Dropbox, Facebook, and a host of many ways to upload data).

You can check it out here and the source is on my github account.

I didn’t end up winning any prizes from the event sponsors, but made a cool app that I’ve been using frequently myself and made a few friends. Can’t wait until another one!

An OSX Prank

You can get a real good view of OS X’s Mission Control with this:

defaults write com.apple.dock expose-animation-duration -float 30; killall Dock;

I’m sorry for wasting a minute of your time.