A popular and effective way of developing a complex application in a team setting is to make use of git feature branches and submitting a pull request to be merged into the develop branch. Sometimes, though, the pull request can become quite large. This may result in a lengthy wait to get your pull request reviewed, bugs being overlooked, and merge conflicts.
These difficulties can be helped by shrinking your pull requests using the following two strategies:
Grids are an effective way of getting all the components in your website into the right spot. It allows you to put things into columns and get them to line up nicely.
If you don't have grids, your website is going to look something like this:
Active record makes it easy to write simple queries anywhere in your application. The key phrase here is anywhere in your application: When database queries are scattered throughout your application, simple database changes may require modifications to your controllers, your views, helpers, mailers, etc.
ActiveRecord provides you with
scopewhich allows you to hide the details of your schema so that database changes don't affect the entire application.
Stripe has a great API to manage subscription payments. Here we take advantage of it to implement recurring subscriptions in Rails 5.
Using the Stripe API means we do not have to store sensitive customer information like (credit card number or CVC), and the APIs are already set up to handle complex cases such as update plans, manage subscriptions, trigger refunds, and more.
Here are a few small hacks I have discovered over the years to streamline your Ruby projects.
Many projects require a method that takes a date as a parameter and returns the date if it is valid and false if it is not. This method should also not raise an exception.
As your audience grows, it is important to ensure that your website or application can be used by everyone - specifically people with permanent or temporary disabilities. This is often referred to as accessibility (or A11y as an abbreviation), and is a requirement for all modern websites or applications.
Today I will share with you how I approach reverse geocoding using the Geocoder gem.
As you may know, the Ruby gem Geocoder allows you to do reverse geocoding "automatically" in the model by doing
reverse_geocoded_by :latitude, :longitude. That is cool, but I found a better way...
Have you ever noticed how many discussions there are online about what programming language or framework is the best? People in forums are always praising one particular language and making fun of those who use a different language. I was guilty of doing that at an earlier point in my career. Ruby was everything, and anything other than Ruby was simply not as good.
Time passed and I came to the realisation that the programming language is nothing but a tool, and the real value of the software engineer is in their problem solving, thereby rendering the programming language used by the engineer simply a tool for solving problems. Different tools solve different problems, and some tools solve the same problems in different ways. With this in mind, I would like to draw a parallel between programming and music.
When working in the Rails console, I tend to build up commands over time that I run often. These might be for resetting data, fetching something from an API, generating tokens, etc. Multiple times a day, I find myself holding down the up arrow on the keyboard until I find the last time I ran it, so I can run it again. Usually, there will be multiple commands that need to be run in sequence, which get concatenated together with semi-colons so they can all be run in one go. I don't know for sure, but I imagine every developer does this.
As an example, right now I'm working on a project that calls a large number of API endpoints on various different microservices. These all require authentication via a JWT token. We use Her (an ORM for making requests to REST APIs and representing their responses with Ruby classes and objects). We have some Faraday middleware that adds the JWT token (stored in RequestLocals) to the Authorization header to authenticate the requests with the microservices. This means that when I am testing these API calls in the Rails console, I need to fetch a JWT and store it in RequestLocals.
Are you struggling to choose between ActiveAdmin and Rails Admin? Just to confuse you further, there is now a third option:
So, apart from an admin interface, what is Wallaby? The core design is that: