Blogaomu

WEBアプリケーション開発とその周辺のメモをゆるふわに書いていきます。

Kanazawa.rb meetup #66 に参加しました #kzrb

Ruby Elixir 勉強会

雪が降って寒い一日でした。

kzrb.doorkeeper.jp

いつも通りプログラミングElixirの続きをやってLTを聞いてお酒を飲んで満足度の高い時間を過ごすことができました。

プログラミングElixir

第13章

  • GitHubのissueをテーブル形式で表示するプログラム
    • プロセスにおけるデータ変換をそれぞれ関数と見なして設計する方針
  • mix コマンドでElixirプロジェクトを管理することができる
    • mix <task>
    • 自分でmixのタスクを書くこともできる
    • mix help <task>
  • mix new issues コマンドを実行すると以下のようになる
$ mix new issues
* creating README.md
* creating .gitignore
* creating mix.exs
* creating config
* creating config/config.exs
* creating lib
* creating lib/issues.ex
* creating test
* creating test/test_helper.exs
* creating test/issues_test.exs

Your Mix project was created successfully.
You can use "mix" to compile it, test it, and more:

    cd issues
    mix test

Run "mix help" for more commands.
  • mix run でコンパイルをしてプログラムを実行する
  • mix.exs の deps 内配列に依存関係を追加していく
    • hex.pm で検索できる
    • mix deps.get で依存関係をインストールする
  • mix.exsの中で実行するアプリケーションを設定できる
    • 今回は :httpoison を追加した

後から気付いたんですが、前回は第11章やっていたので第12章飛ばしてましたw プロジェクトのexファイルではインストールした外部ライブラリを明示的にインポートしなくても使えるの不思議だなあと思いました。Rubyでいうところの require 書かなくてもなんで呼び出せるのかが分かっていない。。 時間が来てしまったので13章の半分くらいで終了。

あと、今回は余裕があれば発表しようと思ってたんですが間に合わず。ErlPortというライブラリがあってこれを使うとRubyやPythonのコードをElixirから接続できるようになるとのこと。これを使ってElixirとRubyを行ったり来たりというのをやってみようと思ってました。これは来月発表したいです。

erlport.org

懇親会

r.gnavi.co.jp

www.hotpepper.jp

www.hotpepper.jp

前回丸二が満席で入れなかったので満を持して予約。0次会も含めてだいぶ飲みましたね。

なんかの拍子で中谷宇吉郎の話になってそういえば今展覧会やってるなあってのを思い出した。銀座でやってて残念ながら行けなさそう。

www.japandesign.ne.jp

来月ももくもく会です。

Terraform独習メモ3日目

AWS Terraform

引き続きTerraformを触ってみてます。

www.blogaomu.com

2018-02-03

  • 前回はpublicサブネットの構築まで終了した
  • ルートテーブルに作成したpublicサブネットをひもづける
  • privateサブネットを作成する
    • publicサブネットを作成したときと同様に、ルートテーブル、subnet、これらのひもづけリソースの定義を行う
    • ルートテーブルには route を定義しない(後でNATゲートウェイを割り当てる予定)
    • これによって直接外部のネットワークにはルーティングされないのでプライベートなリソースとなる
  • 誤った定義でapplyしてしまった...
    • 1手戻したいときはどうするのがいいのか？(誰か教えてください)
    • 今回は壊してもいい環境だったので、追加したリソースをコメントアウトしてapplyし、該当のリソースを削除した(betterな方法かは分からない)
  • 今回までの成果をグラフに出力しました

f:id:TAKAyuki_atkwsk:20180203170357p:plain

今日はここまで。

kanazawa.rb meetup #65 に参加しました #kzrb

勉強会 Ruby Elixir

kzrb.doorkeeper.jp

新年一発目のkzrbはいつも通りElixir本を読み進めつつ、 @wtnabe さんにCloudFormationの話を聞きつつという感じでやってました。

会場であるITビジネスプラザ武蔵のCRITに『ルビィのぼうけん』が置いてありました。Kickstarterで少しばかりのお金を支援したのは懐かしいです。

ルビィのぼうけん こんにちは！プログラミング

ルビィのぼうけん こんにちは！プログラミング

プログラミングElixir

第11章

  • "" で囲まれたものは文字列リテラルとなる
  • """""" でヒアドキュメントが書ける
  • ~c などのようなものをシジル(sigil)と呼ぶ
    • 自分でシジルを定義できるらしい
  • '' で囲まれたものは文字コードのリストとなる(=整数値のリスト)
    • iexは整数のリストを印字可能であれば文字列として出力する
iex> [67, 55,84]
'C7T'
  • <<>> で囲まれたものはバイナリリテラルとなる
    • ビット列を表す
    • <<4>> は1バイトのデータ
      • 数字が項に入るとバイトの並びとして格納される
iex(47)> b = << 1::size(2), 1::size(3) >>
<<9::size(5)>> # => 01001
iex(48)> byte_size b
1
iex(49)> bit_size b
5

iex(57)> agyou =  "あいうえお"
"あいうえお"
iex(58)> String.length agyou
5
iex(59)> byte_size agyou
15
  • Stringモジュールの関数たち
  • 書記素(grapheme)とコードポイントは別で扱っているのが特徴的

  • String.next_codepoint は [head|tail] っぽい感じ
  • バイナリの最初のルール「疑わしければ、各フィールドの型を指定せよ」
    • 利用可能な型 binary, bits, bitstring, bytes, float, integer, utf8, utf16, utf32
  • 文字列を含むバイナリでhead/tailを分けたい

第11章はまだページ数的には半分行ってなくて次の章に制御構造が出てきたりと、おなじみの概念が後の方に出てくるのがすごいHaskell本と似ているなあと思った。

プログラミングElixir

プログラミングElixir

すごいHaskellたのしく学ぼう!

すごいHaskellたのしく学ぼう!

余談だけど、頭がぼんやりしていてあんまり集中できなかった。この週はずっとこんな感じでつらい。。

懇親会

www.hotpepper.jp

www.hotpepper.jp

www.hotpepper.jp

なんか唐揚げ食べたい！っていう流れになって丸二さん行きたかったけど満席でいけなかったのが残念。

もつ鍋美味しかった。ひたすらもつ鍋食べたい。

Terraform独習メモ1日目、2日目

AWS Terraform

最近、AWSの環境構築に当たって大量の手作業が辛くなってきたのである程度ツールに任せたいなと思い始め、Terraformを触ってみることにしました。0.11.1 を手元にインストールしてます。

2017-01-06

  • 想定する環境を決める
    • ざっとこんな感じで。Webアプリケーションを動かす環境のイメージ。
- VPC
  - この中にサブネットをいくつか用意する
  - パブリックアクセス可能なものとプライベートなものを用意する
- DynamoDB
- EC2インスタンス
  - アプリケーションサーバー * 2
- ALB
  - インターネット - ALb - EC2インスタンス群(App)
  - 443ポートにエンドポイントを作成
  - Appサーバーは8080番ポートにマッピング
- セキュリティーグループ
  - ALB用
  - Appサーバー用
    - ALBのみインバウンドを許可
- IAMロール
  - Appサーバーにひもづけるロール
    - DynamoDBへのread/writeアクセス
provider "aws" {
  region  = "us-west-2"
  # default プロファイルを使用する
  profile = "default"
}

resource "aws_vpc" "main" {
  # 192.168.0.0/20 になる
  cidr_block = "${cidrsubnet("192.168.0.0/16", 4, 0)}"
}

resource "aws_internet_gateway" "main" {
  vpc_id = "${aws_vpc.main.id}"
}

2017-01-11

  • 今日はサブネットを作ろうと思う
    • public * 2 (AZ-A, AZ-B)
    • private * 2 (AZ-A, AZ-B)
  • その前にルートテーブルにゲートウェイをひもづける
  • サブネット
  • cidrsubnet(aws_vpc.main.cidr_block, 4, 0) を使って3番目の引数を0, 1, 2,... にしていくと
    • 192.168.0.0/24, 192.168.1.0/24,... とCIDRが設定されていい感じ(これまでは頭の中or書き出してIPアドレス範囲を計算していた)
    • 当初はこの関数を使う利点がよく分からなかったが、ここでメリットが出てきた
  • とりあえず1ファイルにまとめているが、見にくくなったらファイル分割しようと思う
  • ルートテーブルとpublicサブネットを作成した
resource "aws_route_table" "r" {
  vpc_id = "${aws_vpc.main.id}"

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = "${aws_internet_gateway.main.id}"
  }

  tags {
    Name = "main"
  }
}

resource "aws_subnet" "public-a" {
  vpc_id            = "${aws_vpc.main.id}"
  cidr_block        = "${cidrsubnet(aws_vpc.main.cidr_block, 4, 0)}"
  # 本当はリージョンも変数化したい
  availability_zone = "us-west-2a"

  tags {
    Name = "public-a"
  }
}

resource "aws_subnet" "public-b" {
  vpc_id            = "${aws_vpc.main.id}"
  cidr_block        = "${cidrsubnet(aws_vpc.main.cidr_block, 4, 1)}"
  availability_zone = "us-west-2b"

  tags {
    Name = "public-b"
  }
}

まだまだ作りたいリソースはたくさん残っていますが、(いまのところ)簡潔に書けてパッと実行できるのはいいですね。

2017年個人的振り返り

web開発 雑記

毎年やってるやつです。去年はこちら。

www.blogaomu.com

仕事

2016年に引き続きスタートトゥデイ工務店のお仕事をお手伝いしておりました。年の途中で携わるプロジェクトが変わっていわゆる立ち上げフェーズという状況だったのですが、APIやCLIツールの実装、コードレビュー、クラウドサービス上での環境構築・運用、新しく導入するツールやサービスの調査などをメインに行いました。今のプロジェクトでは若いメンバーがおりまして彼ら彼女らの成長っぷりをみることができて嬉しいし刺激になります。それと同時にいつの間にか自分自身がミドル層というかそういう歴になってきたのかというのも感じてます。

新しいこととしてはPythonと英語が大きなところで、仕事で使う動的型付けのプログラム言語としてはRuby以来で新鮮でした。英語は外国語話者とのコミュニケーションをスムーズにしたいということで一部導入されています。私は主にライティングで使っていますが徐々に慣れてきたかなという感じです。一方で新しいフレームワークだったり概念だったり日々進んでいるものに対してのキャッチアップはなかなかできなくなっていました。この辺は去年からの課題ですねー。

仕事で使うツールとしてはこちらに課金しました。GitHub issueやPull Requestのreaderアプリケーションで、とても捗っています。

jasperapp.io

コミュニティ活動

今年も引き続きKanazawa.rbとJAWS-UG金沢に参加していました。Kanazawa.rbではtogetterまとめをやるようになり、少しづつ運営にも携わるようになりました。定期的に集まってもくもくしたり喋ったりすることは地方都市においては貴重な機会なのでこれからも続けていきたいですねえ。

個人開発

前回のKanazawa.rbで発表したのですがTwitterクライアントなどたまに作っていました。仕事としてはごりごりソースコードを書くっていう機会は年々減っていってるので、個人で手を動かす時間も取りたいなと思ってます。

仕事してお金を稼いで、個人開発で作りたいものを作り知識を増やす、こういうものをベースに健康的に生活するというのを継続してやっていきたいですね。

これは2016振り返りの中の一文です。個人開発はまだ足りないですが、お金を稼いで健康的に生活するというのは最低限できたかなと思います。2018年もこの方針は変えずにインプットアウトプットを増やしていきたいですね。

締めは乾杯の風景で。それでは良いお年を。

kanazawa.rb meetup #64 に参加しました #kzrb

勉強会 Ruby

kzrb.doorkeeper.jp

#63 は参加したけどブログ書き損ねてました。#64 は年末恒例のLT大会！参加者はまあなんでもいいので5分喋ろうって感じです。

ちなみに去年のやつ。 www.blogaomu.com

私の発表

今回発表したのはこの2つです。

docs.google.com

docs.google.com

両方とも前半に喋りすぎて後半飛ばし飛ばしになってしまい、思うように伝えられなかったのが残念でした。もともとゆっくり喋るというか言葉が出てくるまで時間がかかることがあるので内容を絞ってもいいのかもしれないなあ。

振り返りの方は、個人で作っていたものとその他インプットアウトプットについて話しました。普段業務ではサーバーサイドの開発やAWSでの環境構築・運用を行うことが多いのでクライアントアプリを作ってみたいという欲求があるのかもしれません。Twitterクライアントは自分の求めるものを作りたいなあというモチベーションはありますが。読書はどれも読み切れないという1年でした。読むか〜っていう感じになかなかならなかったし、まとまった時間が作れなかったというのもあるかもしれないですね。その中でもElixir本はkzrbのもくもく会を使って少しづつ進んでいるので来年も継続していきたいです。

新幹線tipsはなんかネタないかなーと考えていて、そういえば出張まあまあ行ってるなということを思い出し5分くらいでちょうどいい感じになりそうと思いまとめました。強く言いたかったスライドが最後になってバタバタしてしまったのは構成としてあれだったなあ。ビール情報は今後も開拓していきたいです。

全体的に

他の人の発表は、今年はこういうもの買ったで〜とかこんなの作ったで〜とかいう感じでした(雑)。買ったもの発表は物欲を刺激されますね...w

懇親会

今年最後ってことで肉を食らいました。肉美味しい。肉最高。

二次会はワインのお店。2017年のボジョレーヌーボーを頂きました。ワイングラスの話になって、他のお酒(日本酒やウィスキーなど)を入れても香りを楽しめていいよねっていう話になりました。この日は雨風が強かったのですが、突撃したお店が軒並み満席でしばらく放浪してましたw 年末感出てきてます。

ECRのライフサイクルポリシーを試す

AWS ECR

JAWS-UG金沢のもくもく会に参加してきました。で、最近ECRのコンソールにライフサイクルポリシーというメニューが追加されてたのが気になっていたので軽く触ってみました。

jawsug-kanazawa.doorkeeper.jp

Amazon ECRのライフサイクルポリシーでコンテナイメージのクリーンアップ | Amazon Web Services ブログ

ライフサイクルポリシーを使うことで、古い又は使われていないイメージを自動的に削除することで、コンテナイメージのレポジトリをきれいに保つことができるようになりました。

なるほど。たしかに、リポジトリ当たりのイメージ数制限がある(上限申請可)ので古くなったイメージを自動的に削除してほしい。今まではcron等でAPI叩いて行う感じのものが良い感じに自動化できるので良さそう。

Amazon ECR ライフサイクルポリシー - Amazon ECR

コンソールには Dry run of lifecycle rules と Lifecycle policy というメニューが増えていた。ポリシーを作成して、dry runののち正式に適用することができる。

ルールの追加画面。キモとなるのは Match criteria という項目。ここでイメージの削除条件を決める。 条件は Image count more than もしくは Since image pushed を選択できる。前者は指定した数(=n)を超えてイメージが存在しているときに最新n個のイメージは残りその他のイメージは削除される。後者はpushされてからn日を超えたイメージは全て削除される。

この時点ではラベルの通り作成したルールは未保存状態なので、 Save and perform dry run をクリックする。

すると、ルールを適用する場合に削除されるイメージの一覧が表示される。この時点ではリポジトリに全部で4個のイメージが存在しており、その中でタグがついてないものは3個であった。このため、タグのない(=untagged)2個を超える分がここでは表示されている。dry runしてみて良さげであれば Apply as lifecycle policy をクリックして実際に適用することができる。

これは、クリック直後のリポジトリ内のイメージ一覧であるが変化はなかった。

ライフサイクルポリシーの作成後、影響を受けるイメージは 24 時間以内に有効期限切れになります。

ドキュメントを見ると即時削除されるわけではないので気長に待ちましょう。

時間が経ってからコンソールを確認すると設定したポリシーが実行されたログが残っていた。

リポジトリ内のイメージを見ると確かにタグの無いイメージは2個になっている。素晴らしい。

今回はお試しで簡易に確認するため制限数を少なくしたが、90日とか180日とかプロジェクトのライフサイクルに合わせて設定しておけば、docker pushしようとしたらリポジトリいっぱいでした〜みたいなトラブルを避けられるのでいいなと感じた。