README.md

#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.

Analytics

• Python
• R

Agile

• Kanban
• User Stories
• Working Agreements

Backend

• Java
• Microservices
• Node.js
• Python
• REST Services
• Ruby
• Scala

Big Data

• Best practices for Hadoop
• Hadoop Development & Best Practices
• Hadoop Management Hardware and OS
• HBase Management
• Spark Best Practices
• Amazon Redshift Best Practices

Cloud Computing

• Amazon Web Services
• Microsoft Azure

DevOps

• Configuration Management
• Docker
• Infrastructure Management
• Git

Frontend

• Angular.js
• HTML5
• Javascript
• CSS & Styling
• Frontend Tool Ecosystem
• Polymer
• Emberjs

IT Security & Hardening

• Server Security
• Secure Development

### NoSQL

• MongoDB

Quality Assurance

• ATDD Acceptance Test-driven Development
• Calabash
• Code Design
• Code Optimization
• Cucumber
• Sonar
• Testing techniques
• TDD, BDD and Acceptance Test
• TDD Test-driven Development

Contrib Guidelines

• 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.
• Add attributions and references if necessary to external sites, it's nice when your work is recognized by others.
• 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.

---

Licence

Please see LICENSE.

---

BEEVA | Technology and innovative solutions for companies