on 24-Apr-2019 (Wed)

After the success of CNNs in IVSRC 2012 (Krizhevsky et al. (2012)), initialization with Gaussian noise with mean equal to zero and standard deviation set to 0.01 and adding bias equal to one for some layers become very popular.

Why it is not possible to train very deep networks from scratch with this initialization?

In terraform, for map keys, fill out occulsion below to show how you would treat a map key that is a non-literal expression, specifically the map key is the value of input variable "business_unit_tag_name":

{

[...] = "SRE"

}

(var.business_unit_tag_name)

^^^ note how the non-literal map key is enclosed in brackets!!

provider

^^^ e.g. below, note the aws prefix (for aws provider) in the "aws_instance" block label (remember that "resource" is block type and "aws_instance" and "example" are block labels)

resource "aws_instance" "example" {
  ami           = "ami-2757f631"
  instance_type = "t2.micro"
}

it installs any needed provider plugins based on stated configs

^^^ e.g. it installs AWS provider plugin
^^^^ note "terraform init" is idempotent (i.e. you can run it many times with no issues) but must be run before you do inital plan/apply

it grabs any child modules declared in the configs

^^^ note "terraform init" is idempotent (i.e. you can run it many times with no issues) but must be run before you do inital plan/apply

it setups the remote backend

^^^ note "terraform init" is idempotent (i.e. you can run it many times with no issues) but must be run before you do inital plan/apply

In terraform, if you want to see what changes will be made to your infra, before you do a "terraform apply", you can run this command:

terraform [...]

In terraform, if you want to cleanup/delete all the infra declared in your *.tf configurations, you must run command:

terrafrom [...]

implicit / explicit

^^^ note implicit dependency is when the value of an argument in one resource block is derived from the output/creation of another resource
^^^^ explicit dependency is speified explicitly via the depends_on argument declaration within the resource block

the value of an argument in one resource block is derived from the output/creation of another resource

^^^ e.g. when ec2 instace has to be created before elastic ip:

resource "aws_eip" "ip" {
  instance = "${aws_instance.example.id}"
}

depends_on

^^^ e.g.:

resource "aws_instance" "example" {
  ami           = "ami-2757f631"
  instance_type = "t2.micro"

  # Tells Terraform that this EC2 instance must be created only after the
  # S3 bucket has been created.
  depends_on = ["aws_s3_bucket.example"]
}

provisioner

e.g.:

resource "aws_instance" "web" {
  # ...

  provisioner "file" {
    source      = "script.sh"
    destination = "/tmp/script.sh"
  }

  provisioner "remote-exec" {
    inline = [
      "chmod +x /tmp/script.sh",
      "/tmp/script.sh",
    ]
  }
}

local

^^^ input is for things like values you want to provide at "terraform apply" runtime (like sensative secrests you don't want checked into source control), output is for created resource info you wan to highlight at end of "terrafrom apply" or pass to child module (like elastic ip created), local is just used within the *.tf configs so you are not repeating code (and that things are easy to change in just one place)

^^^^ local variables are declared and defined within "locals" blocks in the *.tf files, and is just a map of values, e.g.

locals {
  default_name_prefix = "${var.project_name}-web"
  name_prefix         = "something"
}

via -var flag to terraform command

^^^ e.g.:

terraform apply -var 'region=europe-west1-a'

declare them in the *.tf configuration files

^^ e.g.

variable "region" {
     default = "us-east-1"
}
variable "AMI" {}

variable "region" {
   default = "us-west-2" 
}

In terraform, say you declared input variable "region", using following block in your *.tf config file:

variable "region" {
   default = "us-west-2" 
}

how do you access the value of this variable in the following *.tf code block:
provider "aws" {
access_key = "AKIA98298ADFDDRDSFDFSF"
secret_key = "_adofijoeairjdsfDDF(*Fjij"
region = [...]
}

"${var.region}"

^^ Note the use of the var syntax
^^^ note the outer enclosure in double quotes to mean derived value is string
^^^^note the inner enclosure in ${} to mean that this value is derived.

In terraform, say you declared input variable "region", using following block in your *.tf config file:

variable "region" {}

and you use its value in the following *.tf code block:

provider "aws" {
  access_key = "AKIA98298ADFDDRDSFDFSF"
  secret_key = "_adofijoeairjdsfDDF(*Fjij"
  region     = "${var.region}"
}

how do you assign it value of "us-west-2" in your *.tfvars file:

[...]

variable "cidrs" {
   default = []
}

OR:

variable "cidrs" {
    type = list
}

map lookup

^^^ e.g.:

variable "amis" {
  default = {
    "us-east-1" = "ami-b374d5a5"
    "us-west-2" = "ami-4b32be2b"
  }
}

variable "region" {}

resource "aws_instance" "example" {
  ami           = "${lookup(var.amis, var.region)}"
  instance_type = "t2.micro"
}

In terraform, say you have a declared (and assigned values via the default argument) a variabled called "amis", as
follows:

variable "amis" {
  default = {
    "us-east-1" = "ami-b374d5a5"
    "us-west-2" = "ami-4b32be2b"
  }
}

And you have declared region variable as follows:

variable "region" {}

Complete the configure code block below to assign the right AMI to your EC2 resource, based on the "region" input variable give at "terraform apply" runtime:

resource "aws_instance" "example" {
ami = [...]
instance_type = "t2.micro"
}

"${lookup(var.amis, var.region)}"

^^ note use of built-in lookup function that takes a map argument and a key argument and returns the value for the key
^^^ note the outer double-quote enclosing to denote a returned string value
^^^^ note the inner ${} enclosing to denote that the value is derived/computed

In terraform, say you create an Elastic IP resource (to get a static/non-changing public IP you can assign to an EC2 instance), as follows:

resource "aws_eip" "ip" {
  instance = "${aws_instance.example.id}"
}

After elastic ip resource is created, it will have an exported variable called "public_ip". Create a output variable called "ip" that will expose this value (as output to "terraform apply" or to a module that uses your module)

[...]

output "ip" {
  value = "${aws_eip.ip.public_ip}"
}

^^ note the keyword "output" for the block type

In terrafrom, say you have already run "terraform apply" but still want to see the value of output variable "ip" (which is say the public ip of your newly-created AWS Elastic IP resource), you can do so via following command:

terraform [...] [...]

locals {
  default_name_prefix = "${var.project_name}-web"
  name_prefix         = "something"
}

^^ note the use of the locals block type (un-named block) to decalre and assign all the local variables.

^^^ note that these values can be accessed in the rest of the *.tf configs, using the local.* syntax (e.x. "${local.name_prefix}")

In terraform, if the following local values/variables are setup in your *.tf file:

locals {
  default_name_prefix = "${var.project_name}-web"
  name_prefix         = "something"
}

How do you access these values in the rest of your *.tf config file, for example finish this code snippet:

resource "aws_s3_bucket" "files" {
  bucket = "[...OCCULSION IS HERE...]-files"
  # ...
}

resource "aws_s3_bucket" "files" {
  bucket = "${local.name_prefix}-files"
  # ...
}

^^ note the use of the "local" keyword

^^^ note the outer double quote enclosure to denote string value

^^^^ note the inner ${} enclosure to denote derived value.