bikeindex / bike_index

[![BIKE INDEX][bike-index-logo]][bike-index] [![View performance data on Skylight][skylight-badge]][skylight] [bike-index-logo]: https://github.com/bikeindex/bike_index/blob/main/public/icon-dark.svg?raw=true [skylight]: https://oss.skylight.io/app/applications/j93iQ4K2pxCP [skylight-badge]: https://badges.skylight.io/status/j93iQ4K2pxCP.svg [bike-index]: https://www.bikeindex.org Bike registration that works: online, powerful, free. Registering a 🚲 only takes a few minutes and gives 🚴‍♀️ a permanent record linked to their identity that proves ownership in the case of a theft. We're an open source project. Take a gander through our code, report bugs, or download it and run it locally. Dependencies _We recommend mise for managing versions of Ruby and Node. Check the .tool-versions file to see the versions of required versions of:_ • Ruby • Node _Bike Index also requires some additional libraries. We recommend installing them via your system package manager / homebrew_ • PostgreSQL • Redis • and for image manipulation • Eventually, will only be required for testing (via chunky_png), but we're not there yet Running Bike Index locally Follow the Getting Started guide for a complete set up. Or if you're familiar with developing Ruby on Rails applications start with these steps and a local Postgresql installation: • sets up the application and seeds test organizations, bikes and users: • Three test user accounts: admin@bikeindex.org, member@bikeindex.org, user@bikeindex.org (all have password ) • Gives user@bikeindex.org 50 bikes • Give test organization Hogwarts all organization features and some test parking notifications • start the server. It starts redis in the background and runs foreman with the dev procfile. If you need/prefer something else, do that. If your "something else" isn't running at localhost:3042, change the appropriate values in Procfile.dev and .env • Go to localhost:3042 | Toggle in development | command | default | | --------- | ------- | ------- | | Caching | | disabled | | [letter_opener][] | | enabled | | logging with lograge | | enabled | [letter_opener]: https://github.com/ryanb/letter_opener Localization See the localization docs for details (we use translation.io for localization). Testing We use RSpec and Guard for testing. • Run the test suite continuously in the background with (watches for file changes/saves and runs those specs) • You may have to manually add the extension, which we use for near serial searches, to your databases. The migration should take care of this but sometimes doesn't. Open the databases in postgres ( and ) and add the extension. We use to run the test suite in parallel. By default, this will spawn one process per CPU in your computer. • Run all the tests in parallel with • Run to synchronize the test db schema after migrations (rather than ). • Run specific files or test directories with • Run Guard with parallelism Code Hygiene We use the following tools to automate code formatting and linting: • EditorConfig • StandardRB • ESlint Run to automatically lint the files and/or add auto formatters to your text editor (e.g. prettier-standard) EditorConfig EditorConfig ensures whitespace consistency. See the [Download a Plugin][editorconfig-plugin] section of the EditorConfig docs to find a plugin appropriate to your editor. [editorconfig-plugin]: https://editorconfig.org/#download StandardRB StandardRB is an opinionated Ruby style guide, linter, and formatter - it is "a spiritual port of StandardJS". See the how do I run standard in my editor section of the StandardRB docs to find an appropriate plugin for on-the-fly linting. [standardrb-plugin]: https://github.com/testdouble/standard#how-do-i-run-standard-in-my-editor StandardJS standard is configured to run on project JavaScript. Install it with Run it with . Bug tracker Have a bug or a feature request? Open an issue. Community Keep track of development and community news. • Follow @bikeindex on Twitter. • Read the Bike Index Blog. Contributing Open a Pull request! Don't wait until you have a finished feature before before opening the PR, unfinished pull requests are welcome! The earlier you open the pull request, the earlier it's possible to discuss the direction of the changes. Once the PR is ready for review, request review from the relevant person. If your pull request contains Ruby patches or features, you must include relevant Rspec tests. ... and go hard