一分一秒真剣勝負!

Ruby, Railsなど。Web系の技術ネタを充実させたい・・が、そうなるかは分からない。

AWS Database Migration Service

「異なるDB間で特定のデータを同期させたい」 ちょっと機会があったので、この要件をAWSのサービスで実現出来ないかと思って調べてみた。 それで出てきたのがこれ。

aws.amazon.com

DMSはユースケースに書いてある通り「DB間移行作業」で使うイメージが強いと思う。オンプレからAWSにサービスを載せ替えたい。といった要件はよくありそうだし、基本はこのようなケースで使われる事が多いのだろう。しかし、これもユースケースに書かれているが「継続的なデータレプリケーション」でも使えるサービスだったのだ。

テーブルマッピング」を見た感じ、DB間でテーブルの構成に差分があっても対応出来そう。ググってみると思っていたよりレプリケーション用途で使っている実例が出てきたので、そこそこある要件なんだなってのが分かる。使ってみたかったけど、他のプランにしてDMSは使いませんでした。

時間が無いから・・・って理由で一旦DMSを使ってデータを同期させ、別システムを構築とかやってるところありそう。どんどん機能が追加されてAWSが便利になっていくのはいいけど、負債の幅も広がっていくのかもしれない。

Terraform Cloud - Error: Error locking destination state: Error acquiring the state lock: resource not found

個人でTerraform Cloudにアカウントを作ってみたのですが、 terraform planを実行するとstateのlockエラーが出ました。

$ terraform plan

Error: Error locking state: Error acquiring the state lock: resource not found

Terraform acquires a state lock to protect the state from being written
by multiple users at the same time. Please resolve the issue above and try
again. For most commands, you can disable locking with the "-lock=false"
flag, but this is not recommended.

自分しか使っていないのになんでlockエラーなんだろう? しかもlock IDが表示されないのでterraform force-unlockできないし、state lockのエラーなのにresource not foundってなんだよ・・ぐぬぬ。 と、困っていましたが、API Tokenが複数種類あることに気づいて解決。 結論から言えばUser API Tokensを使おうぜってことだった。

Terraform CloudのAPI Tokenには3種類あって、雑に説明すると以下のような感じで使い分けろってことでした。

User API Tokens・・・CLI用途
Team API Tokens・・・CI/CD用途
Organization API Tokens・・・Organization管理用途

※詳細 - API Tokens - Terraform Cloud - Terraform by HashiCorp

自分はよく読まないでOrganization API TokensってことはOrganizationにスコープを絞ったトークンなんだろうなと思って使っていただけでした。 しかし、plan,applyできないOrganization API Tokensの使い所ってそんなに無いと思うんだけど、どうなんだろう。

技術書展6に行ってきた

techbookfest.org

きっかけと買った物

Pragmatic Terraform on AWS」の存在を知り、これ欲しいなと思って技術書展6に初参戦。実は同人即売会も人生初。 開始時間の10分前ぐらいに着いたら既に4000人近い行列が出来ていました。 この時点で帰りたくなったけど、列が進み始めると割とスムーズに進めて中に入れました。 前職の同僚が売っていたType Scriptの本を買ってフロントエンドの本を買って、目的の「Pragmatic Terraform on AWS」を買って暫くしたところで帰宅。 知ってる人が他にも数人いたはずなのにあまりの混み具合に見つけられませんでした。 この込み具合はなんとかならんものなのだろうか。

感想と反省

ところで今回気づいたのがこれ。

とはいえ全部紙で買っていると物理的にもう置く場所が無いので厳しい。どうしたもんか。 わざわざイベントで売らずに全部電子書籍で売ればいいじゃんと思っていたけど、直接買うと物理本+DLコードが付いてくるという俺が思ってる理想形態の売り方をしている人が多いし、せっかくここまで来たのだからと普段は自分が買わないようなジャンルの本も手にとって中身を見たりするので、新たなジャンルの技術との出会いがある(自分は今回帰ってしまったが)・・。なるほどこれは技術書展に足を運ぶ価値があるなと思った。あと、残念ながら後から気づいたんだけど、

というわけで秋にはしっかり調べてもっと買うことにします。 さて、続きを読まないと。

帰りにカフェでちょっと読んだ

同人イベント人生初参加。 #技術書展6

Rails Developers Meetup 2019

railsdm.github.io 行ってきました。とか言ってるけどもう1ヶ月近く経とうとしているので遅過ぎる感想。 初の3セッション同時進行・DHHのリモート参加・Jeremyの登壇などもあり、8000円のチケットが即完売。 どのセッションも素晴らしい内容でしたが、とにかく今回のRailsDMで印象に残ったのがDHHのキーノート。

DHHのキーノートで1回の質問に長文で返す攻撃は自分のリスニング能力と英語力を遥かに超えるもので衝撃を受けました。 最近色々と忙しくて時間をとるのが難しいけど、どうにか英語力を高めて行くぞ!と強く思いました。

www.youtube.com

というわけで今回でRailsDMは最終回。次回は来年、RailsKaigiという名前になるというサプライズがありました。 それまでに英語力を今よりマシにしたいものだ。

Ginza.rb 第67回 そろそろAction TextとAction Mailboxをみておこう

ginzarb.doorkeeper.jp

資料: https://gist.github.com/y-yagi/25171f5b6bb24d320ee69517fa7fdebf

遅い投稿。Ginza.rb 第67回目に参加しました。 Action Text / Action Mailbox どちらも使うかは微妙だなという感覚だったけど、これらの実装が Active Storage に依存している事が分かり、Active Storage はこの為にリリースされたんだなあってことが分かったのが素敵でした。なんで今さらファイルアップローダーなんかRailsに入れるんだよという謎が溶けた瞬間だった。 しかし今後、Action Text / Action Mailbox どちらかを使うなら、問題が起きた時など Active Storage の実装も追う事になると分かったのでぐぬぬ・・といったところ。

あと思ったのは勉強会の感想の記事は参加後のなるべく早い段階で書いたほうがいいな〜ってこと。なんかあと2〜3ぐらいいいこと思いついた記憶があるんですよ。なんだっけな〜。

Rails Developers Meetup 2018 Day3 Extremeで登壇しました

Rails Developers Meetup 2018 Day3 Extremeで登壇しました。 speakerdeck.com 正直、クオリティに納得いってないんですが公開。 どうしても付録Cと被ってしまう内容だったのと、TDDから初めてRSpecまでやろうと思ったら20分では無理でした。

とはいえ、Rails歴5年以上の人が6割超えのRailsdmなのに刺さった人が結構いて、定期的な啓蒙活動に意味がある分野なのではと思った。

アウトプット

技術ぽいネタをロクに書いてない。 あー、これ書くには3時間ぐらいかかるなーとか、こんなん誰かが書いてるだろとか考えてしまい、心の壁がそこにはあってブログに書かないことが増えた。 けど、半端でもなんでもアウトプットをネットに出した方がいいのではないか。 なんてことを仕事帰りの電車で考えていた。