Personal blog for nerds and geeks!
You can see the software in action in jonataseduardo.me.
The official repo is https://github.com/jonatassalgado/nerdium
To run this project in development you need to have:
- Git
- Ruby 2.0.0
- Rails 4.0.3
-
Clone the project
$ git clone https://github.com/jonatassalgado/nerdium.git -
Enter project folder
$ cd nerdium -
Install the gems (dependencies)
$ bundle install -
Compile assets (js, css, images)
$ bundle exec rake assets:precompile -
Create the database
$ bundle exec rake db:schema:load -
Create faker data with seed
$ bundle exec rake db:seed
If everything goes OK, you can now run the project!
$ rails server
-
Login as admin
-
Complete the form with
email: admin@gmail.com
password: password
- Installing PG gem - failure to build native extension
- No bundle shim; rbenv: bundle: command not found
- ExecJS::RuntimeUnavailable: Could not find a JavaScript runtime
The best way to collaborate is to "Fork" repo on GitHub. This will create a copy of the repo on your GitHub account.
Before you set out to improve the code, you should have a focused idea in mind of what you want to do.
Each commit should do one thing, and each PR should be one specific improvement.
$ git clone
Ok, you're ready to start editing the code, right? Not quite! Before you start editing, you should create a branch. A branch is like an alternate timeline.
You can read more about git branch here.
If you're trying to fix a bug, you might want to name the branch:
`fix-short-description`
If you're adding a feature:
`feature-short-description`
After you can execute checkout to go the branch
git checkout -b branch-name
As far as code style, just try to imitate the style of existing code. Don't sweat over this too much. If the maintainer doesn't like how your code looks, they'll suggest changes.
You can set of tests to make sure that the existing functionality of the code stays the same as you make changes. This helps keep the software stable.
git commit -m "your commit message"
Using Your Change: though it may not be obvious, you can begin using your code in your own projects immediately.
You made your change, tested it, committed it with git commit, and want to send it back to the project and have it included in a future version.
To do this on GitHub, you need to submit a "pull request" (PR).
The golden rule of submitting PRs is to do things the way the project maintainers would want it done.
In GitHub, "Bug Reports" are called "Issues."
- Has This Been Asked Before?
Before you submit a bug report, you should search existing issues. Be sure to check both currently open issues, as well as issues that are already closed. If you find an issue that seems to be similar to yours, read through it.
If this issue is the same as yours, you can comment with additional information to help the maintainer debug it. Adding a comment will subscribe you to email notifications, which can be helpful in getting important updates regarding the issue. If you don't have anything to add but still want to receive email updates, you can click the "watch" button at the bottom of the comments.
- Nope, Hasn't Been Asked Before
If you can't find anything in the existing issues, don't be shy about filing a new one.
Project maintainers really appreciate thorough explanations. It usually helps them address the problem more quickly, so everyone wins!
- 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 at least in the new parts that you are writing.
Founder: Jonatas Eduardo (John) from Brazil.
GNU AFFERO GENERAL PUBLIC LICENSE
Read more on: asm-products/villeme/LICENSE