なんか書いていこうぜー.com

Let's write something good

富山Ruby会議01でLTをしてきた

2019-11-03
  • Share on Facebook
  • Tweet
  • Add to Pocket

ライトニングトーク

富山 Ruby 会議 01 に参加して、LT してきた。トップバッターだった。

発表については、ありがたくも厳しいフィードバックを直後に複数いただいたので次回の LT に反映するとして、スライドはこちら。

今、試行錯誤しながらやっていることを発表したのだけれども、質問をもらったのでそのときの回答を以下に書いておく。

モブプロ、時間かからない?

ゼロからやろうとすると時間がかかるので、重めの調査が絡むやつは先に調査だけは先やっておくようにしている。※こちらも探り探り

全員が調査しはじめて黙っちゃって手が動かなくなったり、要件に絡む部分ではっきりした正解をもってる人がいない場合は結論でなくて先に進めなくなったりするから、調査もしくは下ごしらえの PR くらいは出してもらうようにし、そこから皆で問題に立ち向かうようにしている。

レビューたまりがちにならない?

マージ時に要求する Approve の数が多いこともあってちょっと溜まりがちになることもある。今、モブプロをやっている時間にレビュー時間を設けてその場でレビュー & マージしていこうか、というのを試そうとしているところ。

起こっているプロジェクト運営に関する問題は、スプリントごとになんかしらの施策を打っては試し打っては試しやっている最中のため、うまくいくかどうかはわからないが今絶賛試行中。

感想

地元富山の参加者が多く、また、北陸、中部、その他いろんな地域からの発表者、参加者がいて、内容も硬軟あわせたたのしい地域 Ruby 会議だった。

発表・LT にもツールとして Ruby を使う話がいくつかあり、私も Ruby 使ってみたいと思ったときに同じようにツールから入ったのを思い出した。地域限定せず、Ruby が使えるお仕事が増えるといいな。

Kanazawa.rb meetup #86 に参加した

2019-10-19
  • Share on Facebook
  • Tweet
  • Add to Pocket

毎月第 3 土曜に開催されている Kanazawa.rb の meetup である、kanazawa.rb meetup #86 に参加してきた。

今回はもくもく会だったので、最初にやることを宣言して作業を開始し、運営のブレストや LT やった後、今日やったことを発表する流れになっている。今回は、それプラス、近々開催されるイベントの紹介時間があった。

今回やったこと

『Vue.js 入門』 を買ったので、今回はその本を読んでいた。5.2 スロット から、10.2 コンポーネントの実装 まで読むことができた。 このあたりのライブラリは React.js から入った私からすると、Vue.js には若干の音楽性の違いが感じられて馴染めない感じなのだが、そうも言ってられないのでもう少しじっくりやってみようか…というところ。Vue.js についてはもう一冊本を買っているので、そちらも読んでから考えよう。

イベントの紹介コーナーでは、本社で開催される Agile Japan 2019 サテライト 福井 - 幸福度ナンバーワンのアジャイル の紹介と、富山Ruby会議01 の紹介をした。

前者は弊社が絡んでいることもあり、紹介しておいた。読み上げたくらいだけど。 富山 Ruby 会議の方は、前回スライド男優として紹介したこともあり、LT もやることになっているところから、流れで併せて簡単に紹介させてもらった。

感想

懇親会まで参加したが、この感じ、Kanazawa.rb であるって感じの懇親会だった。また来月懇親しましょうemoji-exclamation

富山 Ruby 会議には Kanazawa.rb のメンバーも講演・LT したり参加したりしているので、「次は富山 Ruby 会議で会いましょう」、と言って解散した。

ブログを Jekyll から Gatsby.js に乗り換えた

2019-10-14
  • Share on Facebook
  • Tweet
  • Add to Pocket

Jekyll が古くなってきたので、Gatsby.js に乗り換えてみた。 乗り換え作業している最中に Jekyll v4.0.0 が出たのだけれども、どうせアップデート作業しないといけないんだったらもういいや、とそのままつっきった。

Gatsby.js はエコシステムに S3 等のホスティングサービスへデプロイする仕組みが入っているので、前よりはわかりやすいし、各ブログの部品も graphql query を意識しないといけない部分はあるものの、コンポーネントの作成に場面を意識しなくてもよいので意外にすんなり作成できた。

ヘッダ周りが、ベースにした gatsby-starter-blog と異なっていたので、ちょっと苦労したものの、それ意外は素直に作れた。

ハマったところ

$ gatsby build で本番用にビルドをすると、トップページでコンテンツが表示されない。いろいろと探したところ、dangerouslySetInnerHTML does not work on production builds #11108 にぶち当たった。

#issuecomment-455472204 に、p タグは dangerouslySetInnerHTML が展開されないようなことが記載されていたので、p タグ -> div タグに変更したら表示されるようになった。

できた!と思ったらこれが発現してしまったので、一番焦った emoji-sweat_drops

Kanazawa.rb#84で LT をした

2019-09-01
  • Share on Facebook
  • Tweet
  • Add to Pocket

Kanazawa.rb が祝 7 周年!ということで LT 大会が開催されたので、Kanazawa.rb#84 に参加してきたときの記録。

実際は、同僚の kunitoo から預かっていた 富山 Ruby 会議01 についてのスライドと、以下のスライドの 2 つを発表した。 スライド男優デビュー戦であった。

以前、HashiCorp Terraform & Vault Enterprise 勉強会 in 金沢に参加した で Terraform 0.12 に触れていたので、0.12 リリースされたからちょっとだけ触れてみた。

がっつり触れるには時間が足りないので、0.12 対応するアップグレード対応部分だけ、esa で公開してリンクを貼り付けておいた。(現地ではリンクの中も少し紹介できた。)

Kanazawa.rb の LT はあえてテーマの枠を設けてないようだし、しかも一人複数 OK なので、いろんな題材の LT が聴ける。話す方も気楽に作成できるので楽。作るときはそれなりに難産だったりするんだけど。

HashiCorp Terraform & Vault Enterprise 勉強会 in 金沢に参加した

2019-03-17
  • Share on Facebook
  • Tweet
  • Add to Pocket

HashiCorp Terraform & Vault Enterprise 勉強会 in 金沢 ←に発表つきで参加してきた。

HashiCorp 製品について知らなかったものも含め話を聴けたし、事例の紹介もあって参考になった。

メモした内容など

  • Terraform Enterprise

    • policy を設定して従来のワークフローに対して制限を設けることができる(instance数とかregion指定とか)
    • Web の GUIがある
    • ソースコードはVCSから取得可能
    • 環境変数をWeb上から設定でき、その値は裏でVaultが管理している
    • commit/push 等のhookからapplyが実行され、設定によって最終実行までする or 最後の実行は手でを選べる
  • Vault

    • インターフェースとしてGUI, CLI, API があって、使い方によっては Encryption as a service として利用できる
    • 時間制限ありの動的シークレットを作成できる
    • Enterprise は Adobe がバックエンドでかなり使っているらしい
  • Nomad

    • そういうデプロイツールがあるのを初めて知った
  • その他

    • HashiCorp 製品のドキュメントの Learn からアクセスするのがオススメらしい
    • HashiCorp 製品開発時はまずドキュメントから作成するらしい
    • Ruby を使っている部分もある

個人的には Vault よくわかんないなーと思っていたけど、話聴いてちょっと興味でてきたので Learn のドキュメントを読もうかなと思っている。

発表について

発表の方は、Terraform を選んだ理由や、定義を作っていく際に意識していることを話ししたつもり。

三行でいうと、↓のような感じ。

  • 実行前にdiffがみえて、作ったものが簡単に削除できる、読みやすいDSLが気に入っている
  • 秘匿情報持たないようにDataSourceやRondomをうまく使う、削除するリソース単位にディレクトリ分けるを意識している
  • 定義作成の負荷を下げるためベタに書いて、後で diff みつつリファクタするのがよさそう

時間におさまったのでよかった。パネルディスカッションでも発言できたので、なんとか役目は果たしたかな。