Life Blog

Immediately following the end of school, I began to get into the habit of programming again.

What followed was a incredibly liberating period in which I was able to balance my life well and get lots of work done.

I began by making a small webapp for a friend of mine, Max, who needed a 29.97 Dropframe Timecode calculator. He had only known a couple that worked per the specifications that he needed, and he couldn't modify them. Searching on the interweb, I was able to find a great explanation of what the SMPTE Algorithm did, and as a bonus included pseudo-code.

In general, the reason for this algorithm is to provide for a time transformation of visual media to match the running time of the media to be exactly the running time on a clock. Given >2 hours of media, because of the aggregate time to display all 30 frames, the actual running time on a clock will be less than the presented time on the media. So the point is to adjust the running time of the media, and (despite the name) not drop frames.

The issue was that Max needed his timecodes to start at 1:00:00,00 (1 hour exactly, frame 0) in order for his transformation to include an hour of timecode. Because of the way the algorithm works, beginning at hour 0 makes all timecodes congruent, leaving us with no dropped frames for a whole hour.

At any rate, I made it work for him, and open-sourced the code. Later down the line I had a job interview and was asked to showcase some prior work done. I made the SMPTE calculator look spiffier with some CSS and used it alongside Whozawhat.

Whozawhat was a big thing I worked on over the summer too. In desperate need of a rewrite, I took a huge chunk of time and redesigned the entire Auditing, Spreadsheet, and Inspection subsystems. Calling it Whozawhat Lambda, I challenged myself to figure out a very well thought-out design that would give much more flexibility to the user in terms of sharing their spreadsheet with their officers, or to the public in general.

Without redesigning the user database, I worked out a scheme that hosted WoW characters independent of (but classified by) a arbitrary team, and a administration table dependent on a users table and team table.

Having had experience with hosting team + team element data before, this aspect was trivial and most problems revolved around how to store specific type of data rather than getting it in there.

One of the more interesting machinations was the initial design and redesign of the administration table. The plan was to have 3 fields that pertained to a user's permission of a particular team: “F”: Founder, “W”: Write, and “R”: Read. All of which were integer values such that given the value was not zero, it is considered true. And F implies W implies R. (not iff) (Implicit Hypothesis)

On pencil and paper, this made sense. Given F is true, you can read, write, and modify the team. Given F is false, W is true, you can read and write to the team. Given F, W, are false, R is true, you can read the team. Given F,W,R, are all false, you can do nothing to the team.

But when actually writing the code, this fails to make any sense. Why would I store 3 values in 3 variable (or array fields), much less further complicate a database design by adding unnecessary fields. So I set out to make a simplified method of permission values.

What I came up with is the UNIX File permission system. But honest to god, I didn't know that when I was designing it until I took a step back from it after it was done.

Letting the permissions F,W,R be an integer value in a bit string X1X2X3

Given F ≡ True, then because F→W→R thus X1X2X3 = 111

Given F ≡ False and W ≡ True, then because W→R thus X1X2X3 = 011

Given F ≡ False and W ≡ False and R ≡ True, then because R→R thus X1X2X3 = 001

Given F ≡ False and W ≡ False and R ≡ False, then X1X2X3 = 000

For each of these binary strings, there is an integer equivalent such that 111 = 1*2² + 1*2¹ + 1*2º = 7, 011 = 0*2² + 1*2¹ + 1*2º = 3, 001 = 0*2² + 0*2¹ + 1*2º = 1, 000 = 0

Thus I can store permissions as one value that is unique for the permission type, and can validate against weird permissions like 100, or 010, because of the Implicit Hypothesis.

Unlike UNIX permissions, 100 makes perfect sense and so does every other permission mask available. But because of my Implicit Hypothesis, it renders them useless, and in fact 100 == 111.

Other things I managed to implement was an OAuth2.0 server. Currently, I'll provide secure transactions between Whozawhat and the user's client allowing computations and database calls to be made strictly on the server-side, while the user waits with a completely rendered webpage. It has made Whozawhat feel less clunky, and much faster as a whole.

On the flipside, Blizzard announced in August that they too were switching over to an OAuth2 service. While definitely cool, the restrictions they've put on their service is much more crufty and bogacious forcing calls to their service to be much less than what Whozawhat normally calls for less than 1 team.

In order to compensate, I believe I'll have to distribute traffic load somehow. Most likely I'll need to pick up a few cheap VPSs and utilize them. For now, their deprecated service still works, but I reckon only until the end of the year. Home
Previous Seasons

Hello World!

In the Summer of 2012, I finished a semester of college with a lot of time to do things, and in need of a way to keep track of it all.

It was a good success, and after some time it feel by the wayside as my “doing” habits grew stronger.

Instead of a TODO list, I'm keeping this blog as a quarterly journal of what has been keeping my occupied.

QR Code: URL of current page
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial 3.0 Unported