This is a Ruby on Rails application produced as a possible solution to the coding task described here.
Please ensure your system has the proper prerequisites installed. These are:
- Ruby version 3.1.2
- SQLite3
- Clone this repository, and switch to the new directory
$ git clone git@github.com:kierandenshi/test-app-rails.git
$ cd test-app-rails
- Install required Ruby gems
$ bundle install
This application uses the following additional gems to support testing and development: rspec-rails, factory_bot_rails, shoulda-matchers, webmock, rubocop, rubocop-performance, rubocop-rails, rubocop-rspec.
- Prepare the database
$ bundle exec rails db:create
$ bundle exec rails db:migrate
- Start the application
$ bundle exec rails server
Then you can visit the application in a browser at http://localhost:3000
. Rails will log output directly to the terminal. Use ctrl+c
to stop the server at any time.
Rails will bind to IP
127.0.0.1
and port3000
by default. If these defaults do not suit your system, you can specify a different IP and port to bind to using the-b
and-p
switches - example:bundle exec rails server -b=0.0.0.0 -p=4000
In keeping with the Rails principle of convention over configuration, the application's files live inside the /app
directory. Following MVC, sub-directories of interest (for this application) are controllers
, models
, services
, and views
. Routes are defined in /config/routes.rb
.
This application uses:
- RSpec for unit tests.
The files that contain unit tests can be found in the
/spec
directory.
$ bundle exec rspec
- Rubocop for linting.
$ bundle exec rubocop
Some of the default rules relating to next line indentation have been disabled to suit personal preference. These can be re-enabled by updating the root level configuration file
.rubocop.yml
Data required for functional display is persisted locally so it is not necessary to perform a fetch each time the application receives a request. Simple rate limiting could be implemented by locally storing and checking a timestamp value before performing fetches.
The "like" functionality could be improved. Using a dedicated controller and model could improve routing, and polymorphic associations would allow the like function to be used with additional models should the application grow. Full page reloads when using the "like" links could be avoided with use of Hotwire, or some client side Javascript.
- More/better unit testing, particularly controller tests.
- Automated browser testing to test actual page rendering and interactions.