Skip to content

Instantly share code, notes, and snippets.


John McMahon spaceghost69

Block or report user

Report or block spaceghost69

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
siordache /
Last active Nov 7, 2019
Committing multiple files with github-api (PR #361 -
import org.kohsuke.github.*;
public class MultiCommit {
public static void main(String[] args) throws Exception {
String userId = "your-user-id";
String password = "your-password";
String repoName = "your-repo-name";
zsup /
Last active Feb 8, 2020
Documentation-Driven Development (DDD)

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

  • Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
  • Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
  • Once documentation has been written, development should commence, and test-driven development is preferred.
  • Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
  • When a feature is being modified, it should be modified documentation-first.
  • When documentation is modified, so should be the tests.
You can’t perform that action at this time.