#Best Practices in BEEVA
Here is the list of best practices, guidelines, codestyles and recommendations that we follow and encourage in BEEVA, please read the contrib guidelines before sending your pull request with your content.
If you think any information is wrong or missing please write us an email or directly create an issue inside this repo.
- Best practices for Hadoop
- Hadoop Development & Best Practices
- Hadoop Management Hardware and OS
- HBase Management
- Spark Best Practices
- Amazon Redshift Best Practices
### NoSQL
- ATDD Acceptance Test-driven Development
- Calabash
- Code Design
- Code Optimization
- Cucumber
- Sonar
- Testing techniques
- TDD, BDD and Acceptance Test
- TDD Test-driven Development
- Please contribute with OC only no body likes copy/paste gangstas around, but if you think another site has already explained a section/technology better than you provide a link and add attributions and references if necessary to external sites, it's nice when your work is recognized by others. We know its hard to write something new that explains something old, that is simpler and more clear so in some cases its better to make diagrams to explain yourself and try to explain the same concepts in a more interesting and fun way.
- User your beeva github account (beeva-*) not your personal account, so we can track your contributions properlly.
- Each user should make his contributions with his own account, for the same reason as above otherwise we won't be able to tell who contributed with what.
- To contrib please use github issues and pull requests. For instance if you want to contrib to the documents of Calabash and Server Security you first should check if there is an issue about those topics, if there isn't you should create 2 separate issues, and explain on the body of the issue what contributions you want to make, the whole idea behind this is that if another employee wants to contribute to the same topic you both don't duplicate content and work on the same fork, so the issues will be the communication method between the committers. Once you agree on how you will contribute either alone or with your colleagues you can create a fork from the repo, you and other committers of the same topic/document/subject have to use the same forked repository to make your changes, so you will need to agree who will be the "fork" responsible (and of course grant write permissions between yourself in your own fork).
- Once all your contributions are finished in your fork, you should send a Pull Request petition so the integrators can review it and merge it into the main repository of best practices.
- Don't forget to check if your contribution it's linked here in the main index file or in a parent section referenced here.
- Here is the markdown cheatsheet you can use to create your documents.
- Write in english please :), don't worry if everything is not perfect as we will continue improving this guidelines overtime as we find and implement new best practices.
- VERY IMPORTANT, add the images that you required to this repo in the static subfolder of each subsection, in this way we ensure no broken links will be ever created, avoid using external image links.
Please see LICENSE.
BEEVA | Technology and innovative solutions for companies