Super simple: you check the presence of an object to do work on it. We see this in code all the time. Common presence check pattern if params[:coupon_code].present? params[:coupon_code].upcase else params[:coupon_code] # Let’s say this would return nil end This dance isn’t special and we can avoid it with a Ruby trick by typecasting the string. irb > nil.to_s => "" > "".upcase => "" Since typecasting nil to a string will always return a blank string, we can call string methods safely.
There’s columns you’ll want to query from your database. However, third party integrations (like Stripe or PayPal), in particular, might urge you NOT to add a column to your database, depending on your setup. Let’s state the obvious: a basic User class will most likely have an email column. You’ll be querying this often as a SaaS for customers. A database column makes complete sense is common sense. A good rule of thumb to add a database column when working with third parties is if you’ll be querying them often.
We come across the problem of successfully creating and activating a PayPal billing plan and not being able to create and execute a billing agreement attached to the plan. PayPal sandbox says a billing plan is created, and we create a billing agreement successfully. There’s an interesting dance where PayPal asks you to get customer approval before you can marry the plan and agreement with the execute command. This part sucks.
Here’s why and how you fix this error: PG::ObjectInUse: ERROR: database "<MY_DATABASE>" is being accessed by other users DETAIL: There are 4 other sessions using the database. : DROP DATABASE IF EXISTS "<MY_DATABASE>" You can have a console open in a shell, your server running, another console open and maybe try opening another Rails app in a Tmux session. You’re spinning multiple Ruby processes and Postgres isn’t down with it. You can’t perform normal tasks like rake db:drop or migrate because you have active connections to your Postgres database.
Let’s say we have an Account class with an address column. We got word a home address AND a work address is in play. Apparently addresses in our app are complex creatures and we have a has_one/belongs_to relationship. We’ll have to rename and add a column. Renaming the column is the point of this post and it will get tricky, especially with production data. When migrating data, we have a short window where Heroku will take roughly 60 seconds to migrate the data.
When reviewing a pull request that contains a new gem, search it in RubyGems and check the homepage. Most homepages lead you to Github. Here, we can view its dependencies. This check will force us to decide whether this gem, clothed in sheep skin as a mere dependency, might bite us in the butt because it depends on other libraries to function. Dependencies live in the gemspec file. Coupling your app to libaries with many dependencies should stop you dead in your tracks to second guess your decisions.
This post serves as a deploy catalog. Push to Github: Pull the latest changes from master. Switch to production branch. Update that shit. Check logs and diffs for both branches. Sanity check. git diff production..master Take note of features you’re merging. git merge master git push origin production Push to staging: Check heroku for greens: heroku status git push staging production:master && heroku run rake db:migrate -r staging && heroku restart -r staging Push your production branch to staging’s master branch.