Skip to content

Instantly share code, notes, and snippets.

View scopenco's full-sized avatar

Andrei Skopenko scopenco

View GitHub Profile
@scopenco
scopenco / Jenkinsfile
Created April 5, 2018 15:31 — forked from jhryniuk/Jenkinsfile
Jenkinsfile
String path = 'src/'
node('docker') {
ansiColor('xterm') {
stage('Checkout') {
checkout scm
}
stage('Pulling') {
@scopenco
scopenco / Jenkinsfile
Created March 22, 2018 20:38 — forked from JJediny/Jenkinsfile
An example Declarative Pipeline Jenkinsfile for Feb 15 2017 demo
// A Declarative Pipeline is defined within a 'pipeline' block.
pipeline {
// agent defines where the pipeline will run.
agent {
// This also could have been 'agent any' - that has the same meaning.
label ""
// Other possible built-in agent types are 'agent none', for not running the
// top-level on any agent (which results in you needing to specify agents on
// each stage and do explicit checkouts of scm in those stages), 'docker',
@scopenco
scopenco / tomcat_memory.md
Created December 13, 2017 09:41 — forked from mlconnor/tomcat_memory.md
Memory settings for Java JVM in Amazon Elastic Beanstalk

Elastic Beanstalk Java JVM Settings

Determining the right memory settings (MX & MS) for the JVM is not trivial. If you set memory too low then your machine will trash as it runs out and eventually crash. If you set it too high then other critical processes such as Apache or the OS itself may become memory starved and also cause crashes.

In general, I think it best to set the initial memory setting (MS) to be small, around 200M. The real variable we need to calculate is the limit we will place on JVM memory (MS).

In order to make this determination, we need to calculate a few things such as the memory that Apache and the Linux OS need to operate efficiently.

Apache Memory Needs

@scopenco
scopenco / ddd.md
Created May 22, 2017 15:35 — forked from zsup/ddd.md
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.
@scopenco
scopenco / web-servers.md
Created March 26, 2017 14:14 — forked from willurd/web-servers.md
Big list of http static server one-liners

Each of these commands will run an ad hoc http static server in your current (or specified) directory, available at http://localhost:8000. Use this power wisely.

Discussion on reddit.

Python 2.x

$ python -m SimpleHTTPServer 8000