The first open source crowdfunding platform for creative projects in the world
Ruby HTML CSS JavaScript Other
Pull request Compare This branch is 79 commits behind catarse:master.
Latest commit d994797 Apr 27, 2017 @adrianob adrianob fix error message
Permalink
Failed to load latest commit information.
.magick
app
bin
config
db
deploy
doc
lib
public
spec
vendor
.bowerrc
.buildpacks
.dockerignore
.gitignore
.python-version
.rspec
.ruby-version
.travis.yml
Cheffile
Cheffile.lock
Dockerfile
Gemfile
Gemfile.lock
MIT-LICENSE
Procfile
README.md
RUNNING_WITH_DOCKER.md
Rakefile
Vagrantfile
app.json
bower.json
circle.yml
config.ru
dev.Dockerfile
docker-compose.yml
package.json

README.md

Catarse

Circle CI Coverage Status Code Climate

The first crowdfunding platform from Brazil

An open-source crowdfunding platform for creative projects

Welcome to Catarse's source code repository. Our goal with opening the source code is to stimulate the creation of a community of developers around a high-quality crowdfunding platform.

You can see the software in action in http://catarse.me. The official repo is https://github.com/catarse/catarse

Getting started

Dependencies

To run this project you need to have:

Setup the project

  • Clone the project

      $ git clone https://github.com/catarse/catarse.git
    
  • Enter project folder

      $ cd catarse
    
  • Create the database.yml

      $ cp config/database.sample.yml config/database.yml
    

    You must do this to configure your local database! Add your database username and password (unless you don't have any).

  • Install the gems

      $ bundle install
    
  • Install the front-end dependencies

      $ bower install
    

    Requires bower, which requires Node.js and its package manager, npm. Follow the instructions on the bower.io website.

  • Create and seed the database

      $ rake db:create db:migrate db:seed
    
  • Configure the API server

    We provide authentication through JWT (JSON Web Tokens) and it can be configured by CatarseSettings into rails console.

      $ bundle exec rails console
      > CatarseSettings[:api_host] = "http://localhost:3004" # postgREST server url
      > CatarseSettings[:jwt_secret] = "gZH75aKtMN3Yj0iPS4hcgUuTwjAzZr9C" # this token is just a valid example
    

If everything goes OK, you can now run the project!

Running the project

  • Run API server

    After downloading PostgREST 0.3.x you can unpack and run the executable as below.

      $ ./postgrest postgres://postgrest@localhost/catarse_development -a anonymous --jwt-secret gZH75aKtMN3Yj0iPS4hcgUuTwjAzZr9C -s 1 -p 3004
    
  • Run Rails server

$ rails server

Open http://localhost:3000

Translations

We hope to support a lot of languages in the future, so we are willing to accept pull requests with translations to other languages.

Thanks a lot to Daniel Walmsley, from http://purpose.com, for starting the internationalization and beginning the English translation.

Payment gateways

Currently, we support pagarme through our payment engines. Payment engines are extensions to Catarse that implement a specific payment gateway logic.

If you have created a different payment engine to Catarse, please contact us so we can link your engine here. If you want to create a payment engine, please join our mailing list at http://groups.google.com/group/catarse-dev

List of payment enginees that are being developed or need to be developed further

https://github.com/catarse/catarse_pagarme (payment engine used by Catarse.me)
https://github.com/devton/catarse_paypal_express (currently out of date and not maintained)
https://github.com/sushant12/CatarseStripe (just starting to be developed and needs extra hands -- please pitch in...)

How to contribute with code

Discuss your plans in our mailing list (http://groups.google.com/group/catarse-dev).

After that, just fork the project, change what you want, and send us a pull request.

Best practices (or how to get your pull request accepted faster)

  • Follow this style guide: https://github.com/bbatsov/ruby-style-guide
  • Create one acceptance tests for each scenario of the feature you are trying to implement.
  • Create model and controller tests to keep 100% of code coverage in the new parts you are writing.
  • Feel free to add specs to committed code that lacks coverage ;)
  • Let our tests serve as a style guide: we try to use implicit spec subjects and lazy evaluation wherever we can.

Credits

Author: Daniel Weinmann

Contributors: You know who you are ;) The commit history can help, but the list was getting bigger and pointless to keep in the README.

License

Copyright (c) 2016 Softa

Licensed under the MIT license (see MIT-LICENSE file)