Projects I've Worked On

There's a joke in the photography community. It goes like this. Q: "How do you make a small fortune doing photography?" A: "Sell all your gear". Camera gear is expensive; lenses range from hundreds to well into the thousands of dollars. But, camera lenses depreciate very slowly. If you play your cards right, it's surprisingly easy to buy used lenses, use them for a couple years, and finally resell them to break even or even make a profit.

I've spent my fair share of time obsessing over gear. It's a classic case of bad GAS, or "Gear Acquisition Syndrome". I've spent hours poring through Ebay listings looking for that killer deal, and recently, I figured why not let a machine do it for me? So I wrote an Ebay tracker in Nodejs. It pulls data from the Ebay Finding API every 17.5 seconds (Ebay sets a 5000/day API call limit on non-validated applications) and, using the Gmail Javascript API, sends me an email with every new listing that it finds. It puts every listing it sees into a hashmap to efficiently check if it's a new listing, guaranteeing that I only get at maximum one email per listing.

Next steps are to add multi-user and multi-listing functionality. Will use express-session on NPM for user management. Then afterwards, I'll implement a web interface with websockets for the sweet browser window live updates. I'm trying to keep this project free for now, so I figure I'll use a workaround to the lackluster free DB options in Heroku-- I will simply utilize the free 5gb of storage from Storj, and upload my own MySQL DB for user data storage. That will also solve an issue I have with Heroku's lack of built in permanent storage.

Eventually I'd like to make an iOS app and put it on the app store. Perhaps add a subscription model for Ebay power users to take advantage of the functionality.

NOTE: I HAVE SHUT THIS DOWN BECAUSE AWS STARTED CHARGING ME AFTER THE FREE YEAR. I WILL EVENTUALLY MIGRATE THIS TO A FREE HEROKU DYNO. While I was interviewing for a company, the interviewer gave me an interesting engineering assignment that indirectly inspired this app. When complete, it will take a search term, several addresses, and a maximum distance. Then, it will find search terms that are within the maximum distance of each address, making travel and coordination easier for all parties involved.

My reason for building this app was to expand my technology stack. I have the app deployed on AWS using Elastic Beanstalk. The backend is written using NodeJS, and communicates with the frontend through Websockets. The Google Maps API is used to query locations and information about locations. I have a distance checking function running on the backend, but offloading the calculations onto the frontend client will significantly reduce the number of computing operations per query.

I plan to create a login system complete with sessions and Oauth. My current client ID system is quite lacking-- it limits the backend to run on a single core and does not keep track of sessions. Each marker on the Google Maps view will have an info-box giving relevant information such as prices and ratings-- the data is actually already being pushed to the frontend. A client-side mergesort would also be useful in providing nearest-distance information in list-form as well.

In designing this website, I wanted to build a one-page experience for my viewers. I drew some inspiration from scrolljacking web page designs, and designed a controller in JS that relied on scrolling in order to implement a similar effect.

Within the one-page style, I had to make sacrifices, as cleanliness often came by sacrificing usability. Apple's advertisement page for their iPhone 5s/5c, for example, was themed to transition out a page at a time when triggered, creating a clean look, but also locking the user out of their scroll wheel. On the other hand, a continuous scroll feature, while providing the user more inherent feedback, may be less smooth and less consistent due to factors such as varying scroll speeds.

I decided to give my users some more freedom to scroll, and added a scrolling indicator into the sidebar to increase user interactivity.

This is a simpler yet more coherent version of what I envisioned my original Adventures page to be. It uses the exact same scrolling framework I wrote to power my index.html.

I decided against making fancy animations or writing more than a sentence of text per photo. Instead, I let my photos do the talking, and I think the end result is quite enjoyable.

One of my main goals of building josephou.com is to improve my web design skills. With my Adventures page came one of my early attempts at building something that would interact with the user, and the knowledge gained from this experiment is what enabled me to write the current index.html.

This page is a desktop viewable site that hinges on animated orbs that beg attention from the user. My original plan was to create many of these and to guide the user to points of interest throughout the page. This page is on hiatus until I figure out an implementation that is satisfactory to my standards.

My friend and I decided to build a food-centered social media Android app using the Google Maps Android API to share and display locations. We decided to use Firebase as a backend for its authentication and synchronization features and the simplicity of its integrated NoSQL database.

It was a great learning experience for me. For example, although Firebase does not support backend logic, I figured out that by cleverly structuring our DB, our DB could replace any and all backend logic our app needed.