lktslionel

A curated list of AWS resources to prepare for the AWS Certifications

A curated list of awesome AWS resources you need to prepare for the all 5 AWS Certifications. This gist will include: open source repos, blogs & blogposts, ebooks, PDF, whitepapers, video courses, free lecture, slides, sample test and many other resources.

---

Index:

lktslionel

if ! type "brew" > /dev/null; then
  ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)";
fi
brew tap phinze/homebrew-cask && brew install brew-cask;
brew cask install vagrant;
brew cask install virtualbox;

lktslionel

class RedisSessionStore(SessionStore):
    def __init__(self, expire = 1800, key_prefix=''):
        SessionStore.__init__(self)
        self.redis = redis.Redis(tools.config.get('redis_host', 'localhost'), 
                                 int(tools.config.get('redis_port', 6379)), 
                                 int(tools.config.get('redis_dbindex', 1)), 
                                 password=tools.config.get('redis_pass', None))
        self.path = session_path()
        self.expire = expire
        self.key_prefix = key_prefix

lktslionel

#Some discussions on logging from docker: Using logstash Using Papertrail

Issue Loging Drivers

Issue Enhanced Logging

A lot of this boils down to whether you want a single or multi-process (systemd, supervisord etc.) container...

lktslionel

Screencasting Framework

The following document is a written account of the Code School screencasting framework. It should be used as a reference of the accompanying screencast on the topic.

Why you should care about screencasting?

You're probably aren't going to take the time to read this document if you're not interested, but there are a lot of nice side effects caused by learning how to create quality screencasts.

1. Communicating more effectively - At Envy Labs we produce screencasts for our clients all the time. Whether it's demoing a new feature or for a presentation for an invester, they're often much more effective and pleasent than a phone call or screen sharing.

lktslionel

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.

lktslionel

Rules for good testing

Look at the following image...

...it shows an object being tested.

You can't see inside the object. All you can do is send it messages. This is an important point to make because we should be "testing the interface, and NOT the implementation" - doing so will allow us to change the implementation without causing our tests to break.

lktslionel

I just had to set up Jenkins to use GitHub. My notes (to myself, mostly):

Detailed Instructions

For setting up Jenkins to build GitHub projects. This assumes some ability to manage Jenkins, use the command line, set up a utility LDAP account, etc. Please share or improve this Gist as needed.

Install Jenkins Plugins

• get both the git and github plugin
• http://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin

lktslionel

# one or the other, NOT both

[url "https://github"]
  insteadOf = git://github

# or

[url "git@github.com:"]
  insteadOf = git://github

lktslionel

I use PlantUML a lot. It's what I use for drawing all sorts of diagrams and it's handy because of its easy markup (once you get used to it) while making things easy to maintain as projects grow (thanks to version control)

This gist details how I do my PlantUML workspace in a project.

• The idea is to keep a globals directory for all diagrams to follow (like the "stylesheet" below) to keep things consistent.
• The stylesheet.iuml file keeps the use of colors consistent through use of basic FOREGROUND, BACKGROUND and ACCENT colors.
• The style-presets.iuml file defines these colors so you can make "presets" or "themes" out of them.
• As stated in the stylesheet.iuml, you'll need the Roboto Condensed and Inconsolata fonts for these to work properly.