ようへいの日々精進XP

よかろうもん

2018 年 08 月 27 日 (月)

ジョギング

  • 香椎浜 x 2 周
  • 引き続き, 右足の股関節から太腿に強い張り

日課

  • (腕立て x 50) x 3

寝ても疲れが...

コマーシャルで「寝ても疲れが...」って言っていて, 「そんなことあるかーい」って思っていたけど, 実際に今はそんな感じ.

やばいな.

2018 年 08 月 26 日 (日)

ジョギング

  • 香椎浜 x 2 周
  • 右足の股関節から太腿に強い張り
  • 引き続き, 暑さが堪える...

日課

  • (腕立て x 50) x 3

九州新喜劇

blogs.yahoo.co.jp

九州新喜劇を観てきた. テレビで見るのと違ってすごい熱が伝わってきて本当に心から笑えた. 奥さんも元気よく笑っていて, 芸人さん達に本当に感謝.

今日の AWS ~ AWS 認定デベロッパー – アソシエイトレベルサンプル試験を解く (6) ~

公開されているサンプル試験問題を解く. なぜ, その答えになるのかをちゃんと理解する必要がある. 尚, 今回は英語版のサンプル問題である為, 翻訳には Google 翻訳を利用している.

Q7. DynamoDB において, 別プロセスからの書き込みを保護する方法

設問

Your web application reads an item from your DynamoDB table, changes an attribute, and then writes the item back to the table. You need to ensure that one process doesn't overwrite a simultaneous change from another process.

Webアプリケーションは, DynamoDBテーブルから項目を読み取り, 属性を変更して, その項目をテーブルに書き戻. あるプロセスが別のプロセスからの同時変更を上書きしないようにする必要がある

How can you ensure concurrency?

A) Implement optimistic concurrency by using a conditional write.
B) Implement pessimistic concurrency by using a conditional write.
C) Implement optimistic concurrency by locking the item upon read.
D) Implement pessimistic concurrency by locking the item upon read.

どのようにして並行性を保つか.

A) 条件付き書込みを使用して楽観的な同時実行を実装する
B) 条件付き書込みを使用して悲観的な同時実行を実装する
C) 読み込み時に項目をロックすることにより, 楽観的同時実行を実装する
D) 読み取り時に項目をロックすることにより, 悲観的な並行性を実装する

解答

A) Implement optimistic concurrency by using a conditional write. (条件付き書込みを使用して楽観的な同時実行を実装する)

メモ

解答より引用.

Optimistic concurrency depends on checking a value upon save to ensure that it has not changed. Pessimistic concurrency prevents a value from changing by locking the item or row in the database. DynamoDB does not support item locking, and conditional writes are perfect for implementing optimistic concurrency.

  • 楽観的な並行性は, 保存時に値をチェックして変更されていないことを確認することに依存する
  • 悲観的な並行処理は, データベース内の項目または行をロックすることによって値が変更されることを防ぐ
  • DynamoDB はアイテムロックをサポートしておらず, 条件付き書き込みは楽観的同時実行の実装には最適である

楽観的ロックと悲観的ロックの違いについて.

  • https://qiita.com/NagaokaKenichi/items/73040df85b7bd4e9ecfc より引用させて頂いた
  • 楽観的ロック (楽観的排他制御)
    • データそのものはロックせず, 更新対象のデータがデータ取得時と同じ状態であることを確認してから更新することでデータの整合性を保証する方式
  • 悲観的ロック (悲観的排他制御)
    • 更新対象のデータを取得する際にロックをかけることで, 他のトランザクションから更新されないようにする方式
    • DynamoDB はアイテムロックをサポートしていない = 悲観的ロックは出来ない (ということで良いのかな??)

DynamoDB の条件付き書き込みについて.

Q8. SQS や SNS を利用したアプリケーションの実装

設問

Your application triggers events that must be delivered to all your partners. The exact partner list is constantly changing: some partners run a highly available endpoint, and other partners’ endpoints are online only a few hours each night. Your application is mission-critical, and communication with your partners must not introduce delay in its operation. A delay in delivering the event to one partner cannot delay delivery to other partners.

  • アプリケーションは, すべてのパートナーに配信する必要があるイベントをトリガーする
  • 正確なパートナーリストは絶えず変化している
  • 一部のパートナーは可用性の高いエンドポイントを実行し, 他のパートナーのエンドポイントは毎晩わずか数時間オンラインである
  • あなたのアプリケーションはミッションクリティカルであり, パートナーとのコミュニケーションが操作を遅らせてはならない
  • あるパートナーにイベントを配信するのが遅れても, 他のパートナーへの配信が遅れることはない

What is an appropriate way to code this?

A) Implement an Amazon SWF task to deliver the message to each partner. Initiate an Amazon SWF workflow execution.
B) Send the event as an Amazon SNS message. Instruct your partners to create an HTTP. Subscribe their HTTP endpoint to the Amazon SNS topic.
C) Create one SQS queue per partner. Iterate through the queues and write the event to each one. Partners retrieve messages from their queue.
D) Send the event as an Amazon SNS message. Create one SQS queue per partner that subscribes to the Amazon SNS topic. Partners retrieve messages from their queue.

これをコード化する適切な方法はどれか?

A) 各パートナーにメッセージを配信する Amazon SWF タスクを実装して, Amazon SWF ワークフローの実行を開始する
B) イベントを Amazon SNS メッセージとして送信する. パートナーに HTTP を作成するように指示する. HTTP エンドポイントを Amazon SNS トピックに登録する
C) パートナーごとに 1 つの SQS キューを作成する. キューを繰り返し, 各イベントにイベントを書き込む. パートナーはキューからメッセージを取得する
D) イベントを Amazon SNS メッセージとして送信する. Amazon SNS トピックにサブスクライブするパートナーごとに 1 つの SQS キューを作成する. パートナーはキューからメッセージを取得する

解答

D) Send the event as an Amazon SNS message. Create one SQS queue per partner that subscribes to the Amazon SNS topic. Partners retrieve messages from their queue. (イベントを Amazon SNS メッセージとして送信する. Amazon SNS トピックにサブスクライブするパートナーごとに 1 つの SQS キューを作成する. パートナーはキューからメッセージを取得する)

メモ

解説より引用.

There are two challenges here: the command must be “fanned out” to a variable pool of partners, and your app must be decoupled from the partners because they are not highly available. Sending the command as an SNS message achieves the fan-out via its publication/subscribe model, and using an SQS queue for each partner decouples your app from the partners. Writing the message to each queue directly would cause more latency for your app and would require your app to monitor which partners were active. It would be difficult to write an Amazon SWF workflow for a rapidly changing set of partners.

  • パートナーのさまざまなパートナーにコマンドを fanned out する必要がある
  • アプリケーションは高可用性ではない為, パートナーから切り離さなければならない
  • コマンドを SNS メッセージとして送信すると, そのパブリケーション/サブスクライブモデルによって fanned out が達成される
  • パートナーごとに SQS キューを使用することで, パートナーからアプリが切り離される
  • 仮に, 各キューにメッセージを直接書き込とアプリケーションは, どのパートナーがアクティブであるかをアプリケーションに監視させる必要がある
  • 急速に変化するパートナーのために Amazon SWF ワークフローを作成するのは難しい

Q9. CloudFormation のスタック数が上限に達したけど...どうする?

設問

You have reached your account limit for the number of CloudFormation stacks in a region

リージョンのCloudFormationスタック数のアカウント制限に達した.

How do you increase your limit?

A) Use the AWS Command Line Interface.
B) Send an email to limits@amazon.com with the subject “CloudFormation.”
C) Use the Support Center in the AWS Management Console.
D) All service limits are fixed and cannot be increased.

どのようにして制限を増加させるか.

A) AWS コマンドラインインターフェイスを使用 する
B) limits@amazon.com に件名「CloudFormation」で電子メールを送信する
C) AWS 管理コンソールでサポートセンターを使用する 
D) すべてのサービス制限は固定されており, 増額することはできない

解答

C) Use the Support Center in the AWS Management Console. (AWS 管理コンソールでサポートセンターを使用する)

メモ

解説より引用.

The Support Center in the AWS Management Console allows customers to request limit increases by creating a case.

AWS Management Console のサポートセンターでは, ケースを作成することによって制限の増加をリクエストすることが出来る.

CloudFormation の各種制限.

Q10. アプリケーション層とデータベース層で疎通が取れないのはなんでや?

設問

You have a three-tier web application (web, app, and data) in a single Amazon VPC. The web and app tiers each span two Availability Zones, are in separate subnets, and sit behind ELB Classic Load Balancers. The data tier is a Multi-AZ Amazon RDS MySQL database instance in database subnets. When you call the database tier from your app tier instances, you receive a timeout error.

  • 1 つの Amazon VPC に 3 層の Web アプリケーション (Web 層, アプリケーション層, データ層) がある
  • Web 層とアプリケーション層はそれぞれ 2 つの Availability Zone にまたがり, 別々のサブネットにあり, ELB Classic Load Balancerの背後に位置する
  • データ層は, データベースサブネット内の複数 AZ Amazon RDS MySQL データベースインスタンス
  • アプリケーション層インスタンスからデータベース層を呼び出すと, タイムアウトエラーが発生する

What could be causing this?

A) The IAM role associated with the app tier instances does not have rights to the MySQL database.
B) The security group for the Amazon RDS instance does not allow traffic on port 3306 from the app instances.
C) The Amazon RDS database instance does not have a public IP address.
D) There is no route defined between the app tier and the database tier in the Amazon VPC.

これを引き起こす原因は何か?

A) アプリケーション層インスタンスに関連付けられた IAM ロールには, MySQL データベースに対する権限がない
B) Amazon RDS インスタンスのセキュリティグループは, アプリケーションインスタンスからのポート 3306 のトラフィックを許可していない
C) Amazon RDS データベースインスタンスにパブリック IP アドレスがない
D) Amazon VPC のアプリケーション層とデータベース層の間に定義された経路がない

解答

B) The security group for the Amazon RDS instance does not allow traffic on port 3306 from the app instances. (Amazon RDS インスタンスのセキュリティグループは, アプリケーションインスタンスからのポート 3306 のトラフィックを許可していない)

メモ

解説より引用.

Security groups block all network traffic by default, so if a group is not correctly configured, it can lead to a timeout error. MySQL security, not IAM, controls MySQL security. All subnets in an Amazon VPC have routes to all other subnets. Internal traffic within an Amazon VPC does not require public IP addresses.

  • セキュリティグループは全てのトラフィックを既定でブロックする為, 正しく構成されていないと, タイムアウトエラーが発生する可能性がある
  • IAM ではなく MySQL のセキュリティが MySQL のセキュリティを制御する
  • Amazon VPC の全てのサブネットには, 他のすべてのサブネットへのルートがある
  • Amazon VPC 内の内部トラフィックにはパブリック IP アドレスは不要

フムフム.

2018 年 08 月 25 日 (土)

ジョギング

  • 香椎浜 x 2 周
  • 右足の太腿に強い張り
  • んー, 暑さが堪える...

日課

  • そろそろ始めなきゃな...と思ってるところ

星野源のアイデア

www.youtube.com

新しい感じがしたり, 色々とアイデアが詰まったミュージック・ビデオで良かった. 特に 2 番以降, ガラッと雰囲気が変わったと思ったら, いきなりアコースティック・ギターでの弾き語りがあったりして, そんなに音楽を真剣に聞かない自分だけどすごく印象深い作品だと思う.

今日の AWS ~ AWS 認定デベロッパー – アソシエイトレベルサンプル試験を解く (5) ~

公開されているサンプル試験問題を解く. なぜ, その答えになるのかをちゃんと理解する必要がある. 尚, 今回は英語版のサンプル問題である為, 翻訳には Google 翻訳を利用している.

Q4. 一貫性の無い結果を返す操作

設問

Which operation could return temporarily inconsistent results?

  • 一時的に一貫性のない結果を返す操作はどれか
A) Getting an object from Amazon S3 after it was initially created
B) Selecting a row from an Amazon RDS database after it was inserted
C) Selecting a row from an Amazon RDS database after it was deleted
D) Getting an object from Amazon S3 after it was deleted

どれか.

A) Amazon S3 において, 初めてオブジェクトを作成した直後にオブジェクトを取得する
B) Amazon RDS において, データベースを挿入した後にその行を選択する
C) Amazon RDS において, 行を削除した直後に行を選択する
D) Amazon S3 において, オブジェクトを削除した直後にオブジェクトを取得する

正答

D) Getting an object from Amazon S3 after it was deleted (Amazon S3 において, オブジェクトを削除した直後にオブジェクトを取得する)

メモ

解答のコメントより引用.

S3 has eventual consistency for overwrite PUTS and DELETES.

S3 の PUT と DELETE は結果整合性となる.

Q5. DynamoDB の実装

設問

You are creating a DynamoDB table with the following attributes:

* PurchaseOrderNumber (partition key)
* CustomerID
* PurchaseDate
* TotalPurchaseValue

One of your applications must retrieve items from the table to calculate the total value of purchases for a particular customer over a date range.

以下のような属性を持った DynamoDB テーブルを作成しようとしている.

  • PurchaseOrderNumber (partition key)
  • CustomerID
  • PurchaseDate
  • TotalPurchaseValue

アプリケーションでは, テーブルから項目を取得して, 特定の顧客を特定の期間にわたって特定する. (ちょっと日本語がアレ)

What secondary index do you need to add to the table?

A) Local secondary index with a partition key of CustomerID and sort key of PurchaseDate; project the TotalPurchaseValue attribute
B) Local secondary index with a partition key of PurchaseDate and sort key of CustomerID; project the TotalPurchaseValue attribute
C) Global secondary index with a partition key of CustomerID and sort key of PurchaseDate; project the TotalPurchaseValue attribute
D) Global secondary index with a partition key of PurchaseDate and sort key of CustomerID; project the TotalPurchaseValue attribute

テーブルに追加するセカンダリインデックスはどれか?

A) CustomerID のパーティションキーと PurchaseDate のソートキーを持つローカルのセカンダリインデックス. TotalPurchaseValue 属性を投影する.
B) PurchaseDate のパーティションキーと CustomerID のソートキーを持つローカルのセカンダリインデックス. TotalPurchaseValue 属性を投影する.
C) CustomerID のパーティションキーと PurchaseDate のソートキーを持つグローバルセカンダリインデックス. TotalPurchaseValue 属性を投影する.
D) PurchaseDate のパーティションキーと CustomerID のソートキーを持つグローバルセカンダリインデックス. TotalPurchaseValue 属性を投影する.

正答

C) Global secondary index with a partition key of CustomerID and sort key of PurchaseDate; project the TotalPurchaseValue attribute (CustomerID のパーティションキーと PurchaseDate のソートキーを持つグローバルセカンダリインデックス. TotalPurchaseValue 属性を投影する.)

メモ

The query is for a particular CustomerID, so a Global Secondary Index is needed for a different partition key. To retrieve only the desired date range, the PurchaseDate must be the sort key. Projecting the TotalPurchaseValue into the index provides all the data needed to satisfy the use case.

  • クエリは特定のCustomerIDのため, 別のパーティションキーにはグローバルセカンダリインデックスが必要
  • 目的の日付範囲のみを取得するには, PurchaseDate がソートキーでなければならない
  • TotalPurchaseValue をインデックスに投影すると, ユースケースを満たすために必要なすべてのデータが提供される

Q6. CloudFormation の実装

設問

Your CloudFormation template has the following Mappings section:

あんたの CloudFormation テンプレートにおいて, Mappings セクションは以下の通りである.

"Mappings" : {
 "RegionMap" : {
 "us-east-1" : { "32" : "ami-6411e20d"},
 "us-west-1" : { "32" : "ami-c9c7978c"}
 }
}

Which JSON snippet will result in the value "ami-6411e20d" when a stack is launched in us-east-1?

us-east-1 でスタックを起動した場合, JSON スニペットの値が ami-6411e20d になるのはなぜか.

A) { "Fn::FindInMap" : [ "Mappings", { "RegionMap" : ["us-east-1", "us-west-1"] }, "32"]}
B) { "Fn::FindInMap" : [ "Mappings", { "Ref" : "AWS::Region" }, "32"]}
C) { "Fn::FindInMap" : [ "RegionMap", { "Ref" : "AWS::Region" }, "32"]}
D) { "Fn::FindInMap" : [ "RegionMap", { "RegionMap" : "AWS::Region" }, "32"]}

正答

C) { "Fn::FindInMap" : [ "RegionMap", { "Ref" : "AWS::Region" }, "32"]}

メモ

以下, ドキュメントより引用.

{
  "AWSTemplateFormatVersion" : "2010-09-09",

  "Mappings" : {
    "RegionMap" : {
      "us-east-1" : { "32" : "ami-6411e20d", "64" : "ami-7a11e213" },
      "us-west-1" : { "32" : "ami-c9c7978c", "64" : "ami-cfc7978a" },
      "eu-west-1" : { "32" : "ami-37c2f643", "64" : "ami-31c2f645" },
      "ap-southeast-1" : { "32" : "ami-66f28c34", "64" : "ami-60f28c32" },
      "ap-northeast-1" : { "32" : "ami-9c03a89d", "64" : "ami-a003a8a1" }
    }
  },

  "Resources" : {
    "myEC2Instance" : {
      "Type" : "AWS::EC2::Instance",
      "Properties" : {
        "ImageId" : { "Fn::FindInMap" : [ "RegionMap", { "Ref" : "AWS::Region" }, "32"]},
        "InstanceType" : "m1.small"
      }
    }
  }
}

上記の例だと, FindInMap 関数 (AWS::Region 擬似パラメーターを使用して) を用いて, スタックの作成先となるリージョンとしてキーを指定し, 対応付ける値の名前として 32 を指定している.

フムフム.

俺の A Tour of Go (2)

A Tour of Go

https://go-tour-jp.appspot.com/ を写経していく.

Variables

// filename: variables.go
package main

import "fmt"

var c, python, java bool

func main() {
    var i int
    fmt.Println(i, c, python, java)
}

以下, 実行結果.

$ ./_run.sh variables.go 
0 false false false

Variables with initializers

  • https://go-tour-jp.appspot.com/basics/9
  • var 宣言では, 変数毎に初期化子 (initializer) を与えることができる
  • 初期化子が与えられている場合は型を省略出来, その変数は初期化子が持つ型となる
// filename: variables-with-initializers.go
package main

import "fmt"

var i, j int = 1, 2

func main() {
    var c, python, java = true, false, "no!"
    fmt.Println(i, j, c, python, java)
}

以下, 実行結果.

$ ./_run.sh variables-with-initializers.go 
1 2 true false no!

あまり関係ないかもしれないけど, 変数にスコープって存在しないのかなと思ったりした.

Short variable declarations

  • https://go-tour-jp.appspot.com/basics/10
  • 関数の中では, var 宣言の代わりに, 短い := の代入文を使って暗黙的な型宣言が出来る
  • 関数外では, キーワードではじまる宣言 (var, func, など) が必要で := での暗黙的な宣言は利用出来ない
// filename: short-variable-declarations.go
package main

import "fmt"

func main() {
    var i, j int = 1, 2
    k := 3
    c, python, java := true, false, "no!"

    fmt.Println(i, j, k, c, python, java)
}

変数 kvar で宣言されていないが, 代入文として := が利用されている為, 3 が代入されている.

$ ./_run.sh short-variable-declarations.go 
1 2 3 true false no!

Basic types

Go 言語の基本型 (組み込み型) は以下の通り.

bool

string

int  int8  int16  int32  int64
uint uint8 uint16 uint32 uint64 uintptr

byte // uint8 の別名

rune // int32 の別名
     // Unicode のコードポイントを表す

float32 float64

complex64 complex128
  • https://go-tour-jp.appspot.com/basics/11
  • int, uint, uintptr 型は, 32-bit のシステムでは 32 bit で, 64-bit のシステムでは 64 bit を表現する
  • サイズ, 符号なし (unsigned) 整数の型を使うための特別な理由がない限り, 整数の変数が必要な場合は int を使うようにする
// filename: basic-types.go
package main

import (
    "fmt"
    "math/cmplx"
)

var (
    ToBe   bool       = false
    MaxInt uint64     = 1<<64 - 1
    z      complex128 = cmplx.Sqrt(-5 + 12i)
)

func main() {
    fmt.Printf("Type: %T Value: %v\n", ToBe, ToBe)
    fmt.Printf("Type: %T Value: %v\n", MaxInt, MaxInt)
    fmt.Printf("Type: %T Value: %v\n", z, z)

以下, 実行結果.

$ ./_run.sh basic-types.go 
Type: bool Value: false
Type: uint64 Value: 18446744073709551615
Type: complex128 Value: (2+3i)

%T で変数の型, %v で変数の中身にアクセスすることが出来るようだ.

// filename: basic-types2.go
package main

import (
    "fmt"
)

var (
    Foo    string     = "Foo"
)

func main() {
    fmt.Printf("Type: %T Value: %v\n", Foo, Foo)
}

以下, 実行結果.

$ ./_run.sh basic-types2.go 
Type: string Value: Foo

Zero values

  • https://go-tour-jp.appspot.com/basics/12
  • 変数に初期値を与えずに宣言すると, ゼロ値 (zero value) が与えられる
  • ゼロ値は型によって以下のように与えられる
    • 数値型 (int,float など): 0
    • bool 型: false
    • string 型: "" (空文字列 (empty string))
// filename: zero.go
package main

import "fmt"

func main() {
    var i int
    var f float64
    var b bool
    var s string
    fmt.Printf("%v %v %v %q\n", i, f, b, s)
}

以下, 実行結果.

$ ./_run.sh zero.go 
0 0 false ""

Type conversions

以下, 変換の例.

var i int = 42
var f float64 = float64(i)
var u uint = uint(f)

# よりシンプルに
i := 42
f := float64(i)
u := uint(f)

C 言語とは異なり, Go での型変換は明示的な変換が必要となる.

// filename: type-conversions.go
package main

import (
    "fmt"
    "math"
)

func main() {
    var x, y int = 3, 4
    var f float64 = math.Sqrt(float64(x*x + y*y))
    var z uint = uint(f)
    fmt.Println(x, y, z)
}

以下, 実行結果.

$ ./_run.sh type-conversions.go 
3 4 5

以下, float64 に型変換しなかった場合の実行結果.

$ ./_run.sh type-conversions.go 
# command-line-arguments
/sandbox/type-conversions.go:11:33: cannot use x * x + y * y (type int) as type float64 in argument to math.Sqrt

Type inference

  • https://go-tour-jp.appspot.com/basics/14
  • 明示的な型を指定せずに変数を宣言する場合 (:= や var = のいずれか), 変数の型は右側の変数から型推論される
  • 以下のように, 右側の変数が型を持っている場合, 左側の新しい変数は同じ型になる
var i int
j := i // j の型は int になる

上記を念の為, 確認する.

// filename: type-inference-check1.go
package main

import (
    "fmt"
)

func main() {
  var i int = 100
  j := i
  fmt.Printf("Type: %T Value: %v\n", j, j)
}

実行してみると...

$ ./_run.sh type-inference-check.go 
Type: int Value: 100

右側に型を指定しない数値である場合, 左側の新しい変数は右側の定数の精度に基いて int, float64, complex128 の型となる.

i := 42           // int
f := 3.142        // float64
g := 0.867 + 0.5i // complex128

こちらも念の為に確認.

// filename: type-inference-check2.go
package main

import (
    "fmt"
)

func main() {
  i := 42
  f := 3.142
  g := 0.867 + 0.5i
  fmt.Printf("Type: %T Value: %v\n", i, i)
  fmt.Printf("Type: %T Value: %v\n", f, f)
  fmt.Printf("Type: %T Value: %v\n", g, g)
}

実行してみると...

$ ./_run.sh type-inference-check2.go 
Type: int Value: 42
Type: float64 Value: 3.142
Type: complex128 Value: (0.867+0.5i)

以下, ツアーのコード.

// filename: type-inference.go
package main

import "fmt"

func main() {
    v := 42 // change me!
    fmt.Printf("v is of type %T\n", v)
}

以下, 実行.

$ ./_run.sh type-inference.go 
v is of type int

例えば, v の値を "foo" にした場合には以下のような結果となった.

$ ./_run.sh type-inference.go 
v is of type string

Constants

  • https://go-tour-jp.appspot.com/basics/15
  • 定数 (constant) は, const キーワードを使って変数と同じように宣言可
  • 定数は, 文字 (character), 文字列 (string), boolean, 数値 (numeric) のみで利用可能
  • 定数は := を使って宣言不可
// filename: constants.go
package main

import "fmt"

const Pi = 3.14

func main() {
    const World = "世界"
    fmt.Println("Hello", World)
    fmt.Println("Happy", Pi, "Day")

    const Truth = true
    fmt.Println("Go rules?", Truth)
}

以下, 実行結果.

$ ./_run.sh constants.go 
Hello 世界
Happy 3.14 Day
Go rules? true

Numeric Constants

// filename: numeric-constants.go
package main

import "fmt"

const (
    // Create a huge number by shifting a 1 bit left 100 places.
    // In other words, the binary number that is 1 followed by 100 zeroes.
    Big = 1 << 100
    // Shift it right again 99 places, so we end up with 1<<1, or 2.
    Small = Big >> 99
)

func needInt(x int) int { return x*10 + 1 }
func needFloat(x float64) float64 {
    return x * 0.1
}

func main() {
    fmt.Println(needInt(Small))
    fmt.Println(needFloat(Small))
    fmt.Println(needFloat(Big))
}

以下, 実行例.

$ ./_run.sh numeric-constants.go 
21
0.2
1.2676506002282295e+29

コードの needInt(Big) を出力した場合...

$ ./_run.sh numeric-constants.go 
# command-line-arguments
/sandbox/numeric-constants.go:20:21: constant 1267650600228229401496703205376 overflows int

int は 64-bit の整数を保持出来るが, それでは足りないことがある場合に const を活用する.

Go, Go, Go, Go 〜 (郷ひろみ風)

以上, Basics が終了〜でした.

2018 年 08 月 24 日 (金)

ジョギング

  • 右足甲と右太腿に痛みがあったので, 香椎浜まで散歩
  • 右太腿の痛みはいつものやつだと思うんだけど, 強い張りを感じている

日課

  • そろそろ始めなきゃな...と思ってるところ

体調

あまり良くない. 夏バテが今頃きている感じ.

Software Design 2018 年 9 月号

gihyo.jp

今すぐデータサイエンス云々をどうこうするつもりは無いけど, 「統計学」というワードに惹かれたので購入. 読み始めている. とにかくちんぷんかんである.

久しぶりに

Go を触っている. 以前にギョームで見様見真似で作ったツールの改修. Hello World からやり直ししなければいけないなと反省しているところ.

2018 年 08 月 23 日 (木)

ジョギング

  • 香椎浜 x 2 周
  • 右足甲と右太腿に痛み
  • 明日は散歩に切り替えるつもり

日課

  • そろそろ始めなきゃな...と思ってるところ

放送大学

Ruby 認定試験と同日に受験した放送大学の単位認定試験だったけど, その結果が学生専用サイトで公開されていた. レポート自体は「優」を頂いていたけど, 試験自体は自信が無かったのでどーなるだろうなあと思っていたが, 良い結果に倒れたので安心している.

レポート書いたり, 試験受けたり大変だったけど, 久しぶりの経験で少し学生生活に浸ることが出来て楽しかった.

2018 年 08 月 22 日 (水)

ジョギング

  • 香椎浜 x 2 周
  • 右足甲に痛み
  • 疲れが溜まっている感があり, すごくキツかった

日課

  • そろそろ始めなきゃな...

Serverless Meetup Fukuoka #2

serverless.connpass.com

サーバーがあるからサーバーレスというバズワードが生まれたとするならば, きっと, 数年後にはサーバーレスという言葉も無くなって, なんにも, 誰もその存在を意識しないアプリケーションの実行環境という感じになるんじゃないかなーという話を懇親会で話したのがハイライトだった.

2018 年 08 月 21 日 (火)

ジョギング

  • 右足太ももに違和感が痛みになったのでお休み

日課

  • だらだらーっとお休みしてしまった
  • そろそろ始めなきゃな...

明日は

serverless.connpass.com

次は勉強して登壇したいな.

2018 年 08 月 20 日 (月)

ジョギング

  • 香椎浜 x 2 周
  • ゆっくりとダラッと走った
  • 右足太ももに違和感, ちょと休もうかな

日課

  • 引き続き, 腰に痛みがあるので休み中
  • そろそろ始めなきゃな...

奥さん

  • 体調を崩す
  • 涼しかったり, 暑かったり, 昨日は色々と大変だったからな...

疲れていたので

  • 日記も書かずに寝てしまっていた

2018 年 08 月 19 日 (日)

ジョギング

  • 香椎浜 x 2 周
  • ゆっくりとダラッと走った

日課

  • 引き続き, 腰と腰に痛みがあるので休み中

次の住処を決めてきた

  • 今度は, 奥さん待望のちょっと広めの部屋
  • 引っ越しは来月というタイトなスケジュールだけど無理せず頑張ろう

今日の AWS ~ AWS 認定デベロッパー – アソシエイトレベルサンプル試験を解く (4) ~

公開されているサンプル試験問題を解く. なぜ, その答えになるのかをちゃんと理解する必要がある. 尚, 今回は英語版のサンプル問題である為, 翻訳には Google 翻訳を利用している.

Q1. CloudFormation 展開時のエラー

設問

1) Your CloudFormation template launches a two-tier web application in us-east-1. When you attempt to create a development stack in us-west-1, the process fails.

  • 二層の Web アプリケーションを us-east-1 に CloudFormation を利用して展開しようとしている
  • このテンプレートを us-west-1 で展開しようとすると失敗する

What could be the problem?

A) The AMIs referenced in the template are not available in us-west-1.
B) The IAM roles referenced in the template are not valid in us-west-1.
C) Two ELB Classic Load Balancers cannot have the same Name tag.
D) CloudFormation templates can be launched only in a single region.

何が問題なのか.

A) テンプレートで参照されている AMI は us-west-1 では使用できない
B) テンプレートで参照されている IAM ロールは us-west-1 では無効である
C) 2 つの ELB クラシックロードバランサは同じ名前タグを持つことが出来ない
D) CloudFormation テンプレートは、単一の領域でのみ起動出来る

正答

A) The AMIs referenced in the template are not available in us-west-1. (テンプレートで参照されている AMI は us-west-1 では使用できない)

メモ

解答のコメントより引用.

AMIs are stored in a region and cannot be accessed in other regions. To use the AMI in another region, you must copy it to that region. IAM roles are valid across the entire account.

  • AMI はリージョン毎に格納され, 他のリージョンからアクセス出来ない
  • 別のリージョンで利用する場合には AMI をコピーする必要がある
  • IAM ロールはアカウント全体で有効となる

Q2. SQS の仕様

設問

Your application reads commands from an SQS queue and sends them to web services hosted by your partners. When a partner's endpoint goes down, your application continually returns their commands to the queue. The repeated attempts to deliver these commands use up resources. Commands that can’t be delivered must not be lost.

  • アプリケーションは SQS キューからコマンドを読み取り, パートナーがホストする Web サービスにコマンドを送信する
  • パートナーの Web サービスが停止した場合, アプリケーションはコマンドをキューに継続的に送信してしまう
  • 継続的に送信するとリソースが消費されてしまう
  • 配信されなかったコマンドは失われてはいけない

How can you accommodate the partners' broken web services without wasting your resources?

A) Create a delay queue and set DelaySeconds to 30 seconds.
B) Requeue the message with a VisibilityTimeout of 30 seconds.
C) Create a dead letter queue and set the Maximum Receives to 3.
D) Requeue the message with a DelaySeconds of 30 seconds.

リソースを浪費することなく, 停止されるパートナーの Web サービスに対してどのように対応できるか?

A) 遅延キューを作成し, DelaySeconds を 30 秒に設定します
B) 30 秒の VisibilityTimeout でメッセージを再キューします
C) デッドレターキューを作成し, 最大受信数を 3 に設定します
D) 30 秒の DelaySeconds でメッセージを再キューします

正答

なんだろう...このような場合には Long Polling が有効のような気がするけど...

C) Create a dead letter queue and set the Maximum Receives to 3. (デッドレターキューを作成し, 最大受信数を 3 に設定します)

メモ

解答のコメントより引用.

After a message is taken from the queue and returned for the maximum number of retries, it is automatically sent to a dead letter queue, if one has been configured. It stays there until you retrieve it for forensic purposes.

  • デッドレターキューが設定されている場合, メッセージ取得の最大試行回数を超えると, 自動的にデッドレターキューに送信される
  • forensic purposes = 法医学って訳されるので, ちょっとここはよく意味が分からない

設問に「配信されなかったコマンドは失われてはいけない」とあるので, デッドレターキューを設定し, 正常に処理出来なかったメッセージを後から処理出来るようにしておく必要があるということかな.

Q3. 安全に SQS にデータを書き込む為に必要な AWS の資格情報をどのように管理するか的な

設問

Your application must write to an SQS queue. Your corporate security policies require that AWS credentials are always encrypted and are rotated at least once a week.

  • アプリケーションは SQS キューにメッセージを書き込む必要がある
  • 企業のセキュリティポリシーでは, AWS 資格情報は常に暗号化され, 少なくとも1週間に1回ローテーションされる

How can you securely provide credentials that allow your application to write to the queue?

A) Have the application fetch an access key from an Amazon S3 bucket at run time.
B) Launch the application's Amazon EC2 instance with an IAM role.
C) Encrypt an access key in the application source code.
D) Enroll the instance in an Active Directory domain and use AD authentication.

アプリケーションがキューに書き込むための資格情報を安全に提供するにはどうすればよいか?

A) 実行時にアプリケーションが Amazon S3 バケットからアクセスキーをフェッチするようにします.
B) IAM Role が付与された Amazon EC2 インスタンスでアプリケーションを起動します.
C) アプリケーションソースコード内のアクセスキーを暗号化します.
D) インスタンスを Active Directory ドメインに登録し, AD 認証を使用します.

正答

B) Launch the application's Amazon EC2 instance with an IAM role. (IAM Role が付与された Amazon EC2 インスタンスでアプリケーションを起動します.)

メモ

解答のコメントより引用.

IAM roles are based on temporary security tokens, so they are rotated automatically. Keys in the source code cannot be rotated (and are a very bad idea). It’s impossible to retrieve credentials from an S3 bucket if you don’t already have credentials for that bucket. Active Directory authorization will not grant access to AWS resources.

  • IAM ロールは一時的なセキュリティトークンに基づいている為, 自動的にローテーションされる
  • ソースコード内のキーはローテーション出来ない (とても悪い実装である)
  • S3 バケットへの資格情報がない場合, S3 バケットから資格情報を取得することは不可能である
  • Active Directory の承認は, AWS リソースへのアクセスを許可しない (そりゃそうだ...)

フムフム.