One of our tasks is to add a test for a function that does not exist yet, namely to rename the existing team when there is import conflict. Therefore, as per test-driven development practice, the test will always fail until the function is correctly implemented.
If you have any questions, feel free to contact with [email protected], [email protected], [email protected]. Thanks!
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities.
The expertiza environment is already set up in NC State's VCL image "[CSC517, S18] Ruby on Rails / Expertiza".
Using the VCL is the quickest way to get started, but you may find it awkward developing on a remote machine with network lag and having to reinstall gems every time you connect. Installing locally can be a pain though too. Life is full of tradeoffs. :-) The good news is that you can start on one environment, push your work to git, and switch to another environment if you don't like the one you started with.
See the Google doc on setting up the Expertiza development environment.
Depreciation warning: See the Expertiza wiki for setup instructions. Please update the wiki with corrections or additional helpful information. (http://wiki.expertiza.ncsu.edu/index.php/Development:Setup:OSX, http://wiki.expertiza.ncsu.edu/index.php/Development:Setup:Linux:RHEL, http://wiki.expertiza.ncsu.edu/index.php/Creating_a_Linux_Development_Environment_for_Expertiza_-_Installation_Guide)
- Fork the expertiza project
- Create a new branch for your contribution with a descriptive name
- Commit and push until you are happy with your contribution - follow the style guidelines below
- Make sure to add tests for it; the tests should fail before your contribution/fix and pass afterward
- Send a pull request to have your code reviewed for merging back into Expertiza
We've had many contributors in the past who have used a wide variety of ruby coding styles. It's a mess, and we're trying to unify it.
All new files/contributions should:
- Use unix line endings (Windows users: configure git to use autocrlf)
- Indent with 2 spaces (no tabs; configure your editor) both in ruby and erb
- Follow the Ruby Style Guide style for syntax, formatting, and naming
- Follow the design guidelines for the views.
When editing existing files:
- Keep the existing tabbing (use tabs instead of spaces in files that already use tabs everywhere; otherwise use spaces)
- Keep the existing line ending style (dos/unix)
- Follow the Ruby style Guide on code you add or edit, as above
Please do no go crazy changing old code to match these guidelines; it will just create lots of potential merge conflicts. Applying style guidelines to code you add and modify is good enough. :-)
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent