I am currently focusing on finishing my personal website (this page included), finishing a project a DBC alum hired me for, finishing my clone of 2048 and completing a forum type webiste, and a social media type website. I like to use these pages as a place to experiment with new things, so try to view the inconsistencies in styling (looking at you, topbars) between pages as fun experiments rather than poor taste.
"Foodie" is an app I built as my eight day capstone project at Dev Bootcamp. I collaborated with Harrison Klucher, Bill Leidy, and Mathew Liew. Foodie is a fully tested and functional app.
Foodie provides a platform for people who love good food, who want to hear about the newest hottest restaurants, best dishes, and local markets- quite simply, people who are "foodies- to connect, share, and engage with one another. I would describe it as a mixture of Yelp and Urbanspoon.
For the most part, responsibilities in this project were shared. However, I was solely responsible for user authentication/authorization and most user centric activities. I used Devise for authentication, Devise Invitable for mailing invitations, and Omniauth for authentication through social media sites, and accessed the Gravatar API for profile pictures.
We also used Kaminari for pagination through search results, Google Maps APIs (Distance Matrix for calculating closest restaurants, geolocation for users position), and Bootstrap Sass for styling.
Out of the those things that were my own responsibility, certainly the hardest was implementing Devise Invitable. While Devise has thorough documentation and clean, well maintained, commented code, Devise invitable is sort of a "black box" with little insight (and sometimes misleading docs) on how to customize it. After much unnecessary tinkering I found it was actually very simple.
What I ended up doing was overriding the invite! method, routes, and controller by creating the invite_reviewer! and invite_user! methods which essentially assign a role to the invitee upon instantiation of a new invitation. Then I just generated and customized the default devise view depending upon that role. The alternative, and much more complicated solution would be to override the mailer controller, create custom mailer views, override the invite controller, and override almost every method and route within the invite controller. However, this would essentially be overriding all of Devise Invitable and not really using much of the functionality at all.
Implementing Omniauth for a single provider was a cinch. After registering foodies app on the developer website for the provider and configuring the Heroku environment to contain the provider's secret key and secret app id, you simply add a uid and provider to the user model which you will then use to identify a user through the hash of information sent back by their provider after authentication. The next step is overriding the OmniuathCallbacks controller in order to configure steps for new and existing users. You then simply override the password_required? Devise method in order to allow them to sign up without passwords. In our model, for a single user, a username would not be necessary but we would let the user know that if they did not pick a different username their handle from the provider would be used.
I use a similar strategy for multiple providers; the key difference is that instead of the uid and provider living in the user model I move it to a separate model, called identity. A user has many identities and an identity belong to a user. Identities are linked through a common email. This change requires modifications of the callbacks controller as well as configuring devise forms and functions for multiple identites. The solution I came up with was to store essential user/identity information within the session hash once they have been authenticated through their provider, and then alter methods, forms, and routes to react to the presence or absence of that information.
Classy was a three day "client project" at Dev Bootcamp intended to simulate meeting project specifications under short time constraints. I worked with Harrison Klucher, Paulo Gonzales, and Nic Lombardi. The Trello board for our specifications can be viewed here: https://trello.com/b/qk65i4O1/dbc-roster-project
We were required to set up a system for teachers to be able to keep track of their students and some basic information about them. Basically, it was the same system that Dev Bootcamp uses. It was a very very simple schema: a one to many relationship from teachers to students. This is because in Dev Bootcamps model a teacher only has one "cohort" at a time. Additionally, the system should only be allowed to be accessed by teachers, and teachers should not be able to just sign up. They would hae to be invited by an administrator that was seeded upon instantiation of the database. However, this would restrict me from showing this project without sending a public invitation, so after completion I changed the access so that an outsider can sign up and view the site. The site was required to have a material design and be fully tested.
A two day group project intended as an introduction to Sinatra. Built with Sinatra, using a postgreSQL database managed by ActiveRecord, and features a mobile first CSS.
A one day project built as an early foray into implementing MVC architecture with JavaScript. Essentially it is a game where you are given a specific button to mash on the keyboard, specify how many players you want and how many times you want to mash the button, and the first one to mash it said amount of times wins.
A clone of the game 2048 I created. Still needs styling and animations fully implemented. In order to complete animations I just need to add a "Tile" class to in order to keep track of position so tiles that move or merge can be animated.
A two day group project built as an introduction to web development, CRUD, and restful routing. Our assignment was to create a clone of Stack Overflow, however we made a clone with a little bit of our own flavor baked in. The result: Stack OverBro, where you can sign up and ask other bro's only they would have the answers to. While by no means a fully finished product, even in its nascent stages it is expected to cause groundbreaking developments within the bro community.
I worked with Mat Liew, Alexis Moody, and Nicole Carpenter on this project.