wilmoore

Building Docker image with Packer and provisioning with Ansible

Overview

Packer

• Packer is used to build image from a base image, perform provisions and store (commit) the final image.

• We use provisioners and Packer templates to do the actual work to create the final image.

• We use Ansible for provisioning.

wilmoore

F#	C#	Scala	Clojure	Python	Ruby	Haskell	SQL	OCaml	Common Lisp	Erlang	Smalltalk	Scheme	Ecmascript 5	Perl 5
map	Select	map	map	map	collect	map	Select	map	mapcar	map	collect:	map	map	map
filter	Where	filter	filter	filter	select	filter	Where	filter	remove-if-not	filter	select:	filter	filter	grep
fold	Aggregate	foldLeft	reduce	reduce	inject	foldl

wilmoore

Why I Don't Write Web Apps (if I can help it)

This is what happens when I try to pick a language.

Note: If I didn't think it was possible to create a development environment without any of these issues (which I consider "major" for the most part), I would not have written this list.

C/C++

• NOTHNX.

Node.js

wilmoore

require 'tire'

# Tire.configure { logger STDERR, level: 'debug' }

Tire.index('movie-titles') do
  delete
  create \
    settings: {
      index: {
        analysis: {

wilmoore

defprotocol Dict.Protocol do
  def keys(dict)
  def values(dict)
  def size(dict)
  def has_key?(dict, key)
  def get(dict, key, default)
  def get!(dict, key)
  def put(dict, key, val)
  def put_new(dict, key, val)
  def delete(dict, key)

wilmoore

#
# This is the way I configured my ruby environment on ArchLinux.
# 
# I don't like the overhead of rvm, so I use chruby to switch between ruby versions.
# So first you need to install chruby from source: 
# 
# https://github.com/postmodern/chruby#install
#
# To build ruby from source I use ruby-build, so after chruby we install ruby-build:
#

wilmoore

Avoid jQuery When Possible

jQuery does good jobs when you're dealing with browser compatibility. But we're living in an age that fewer and fewer people use old-school browsers such as IE <= 7. With the growing of DOM APIs in modern browsers (including IE 8), most functions that jQuery provides are built-in natively.

When targeting only modern browsers, it is better to avoid using jQuery's backward-compatible features. Instead, use the native DOM API, which will make your web page run much faster than you might think (native C / C++ implementaion v.s. JavaScript).

If you're making a web page for iOS (e.g. UIWebView), you should use native DOM APIs because mobile Safari is not that old-school web browser; it supports lots of native DOM APIs.

If you're making a Chrome Extension, you should always use native APIs, not only because Chrome has almost the latest DOM APIs available, but this can also avoid performance issue and unnecessary memory occupation (each jQuery-driven extension needs a separate

wilmoore

@ChristinGorman gave this talk at JavaZone: https://vimeo.com/49484333  It's quite good, short, energetic, enthusiastic, 
intelligent, and completely misses the point.  

While it's true that the code she produces is much better than the original, and is quite easy to understand; it fails one 
critical test.  It's not polite.

Polite code is like a well written newspaper article.  It allows you to bail out early.  A well written article has a 
headline, a synopsis, and a set of paragraphs that begin with the high level concepts and get more and more detailed as you 
read through the article.  At any point you can decide: "I get it!  I don't need to read further."  Indeed, this is how most 
people read newspapers or magazines.  The articles are polite, because they allow you to get out quickly.

wilmoore

@events =

  events: {}

  on: (topic, handler, context = this) ->
    (@events[topic] or= []).push {handler, context}

  trigger: (topic, args...) ->
    return unless @events[topic]?
    handler.apply(context, args) for {handler, context} in @events[topic]

wilmoore

{
    // --------------------------------------------------------------------
    // JSHint Configuration, Strict Edition
    // --------------------------------------------------------------------
    //
    // This is a options template for [JSHint][1], using [JSHint example][2]
    // and [Ory Band's example][3] as basis and setting config values to
    // be most strict:
    //
    // * set all enforcing options to true