- You MUST NOT try and generate a Rails app from scratch on your own by generating each file. For a NEW app you MUST use
rails new
first to generate all of the boilerplate files necessary. - Create an app in the current directory with
rails new .
- Use Tailwind CSS for styling. Use
--css tailwind
as an option on therails new
call to do this automatically. - Use Ruby 3.2+ and Rails 8.0+ practices.
- Use the default Minitest approach for testing, do not use RSpec.
- Default to using SQLite in development.
rails new
will do this automatically but take care if you write any custom SQL that it is SQLite compatible. - An app can be built with a devcontainer such as
rails new myapp --devcontainer
but only do this if requested directly. - Rails apps have a lot of directories to consider, such as app, config, db, etc.
- Adhere to MVC conventions: singular model names (e.g., Product) map to plural tables (products); controllers are plural.
- Guard against incapable browsers accessing controllers with `allo
# zsh | |
sudo apt-get install zsh | |
sh -c "$(wget https://raw.githubusercontent.com/robbyrussell/oh-my-zsh/master/tools/install.sh -O -)" | |
cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc | |
chsh -s $(which zsh) | |
# rbenv | |
curl -fsSL https://github.com/rbenv/rbenv-installer/raw/HEAD/bin/rbenv-installer | bash | |
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.zshrc | |
echo 'eval "$(rbenv init -)"' >> ~/.zshrc |
ruby '2.7.1' | |
gem 'rails', github: 'rails/rails' | |
gem 'tzinfo-data', '>= 1.2016.7' # Don't rely on OSX/Linux timezone data | |
# Action Text | |
gem 'actiontext', github: 'basecamp/actiontext', ref: 'okra' | |
gem 'okra', github: 'basecamp/okra' | |
# Drivers |
Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.
- Follow standard conventions.
- Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
- Boy scout rule. Leave the campground cleaner than you found it.
- Always find root cause. Always look for the root cause of a problem.
Optimistic Locking assumes that a database transaction conflict is very rare to happen. It uses a version number of the record to track the changes. It raise an error when other user tries to update the record while it is lock.
usage
Just add a lock_version column to the table you want to place the lock and Rails will automatically check this column before updating the record.
Pessimistic locking assumes that database transaction conflict is very likely to happen. It locks the record until the transaction is done. If the record is currently lock and the other user make a transaction, that second transaction will wait until the lock in first transaction is release.
usage
# Call scopes directly from your URL params: | |
# | |
# @products = Product.filter(params.slice(:status, :location, :starts_with)) | |
module Filterable | |
extend ActiveSupport::Concern | |
module ClassMethods | |
# Call the class methods with names based on the keys in <tt>filtering_params</tt> | |
# with their associated values. For example, "{ status: 'delayed' }" would call |