コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

『Kaigi on Rails』をみたよメモ

Kaigi on Rails はリモート開催でしたので、それの見ましたよメモです。

各発表の感想

※資料スライドは見つけたら貼ります。

Viewがレンダリングされるまでの技術とその理解

動画をどうぞ

発表メモ

  • Railsがリクエストを受けてから結果を返すまでをパートごとに分けて、わかりやすいコードを添えながら説明してもらった。内容は以下。
    • Request
    • WebServer
    • Rack
    • Middleware
    • Router
    • Controller
    • View
  • Rackはどんなことをしているか、Routeはどういう動き方をしているか、ControllerはViewのrenderにどうやってつなげているのか

感想

  • なんとなく理解しているを改めてリクエストの流れをおうことでキレイな理解ができた。
  • bin/rails r 'File.binwrite "out.html", {{アプリケーション名}}::Application.routes.router.visualizer' で画像で見ることができるので、機能があるのは知らなかったのでぜひとも仕事でつかっているアプリでつかってみたい

関連リンク


Railsパフォーマンス・チューニング入門

感想

  • DBを中心にパフォーマンスでネックになるところを解説した話。
  • MySQLの気持ちになって考えてみよう」という考え方はシンプルに考えやすくてよかった
  • この手の話は大体N+1や発行クエリが増えまくる話が多かったけど、正しいindexを作ろうという(当たり前なんだけど)新しい切り口だった

関連リンク


FactoryBot the right way

感想

  • 何も考えずにcreateしてたけど、言われてみればbuildでいいじゃないかということを普通に思わされた話。
  • build_stubbedevaluator での数の制御 は初見の情報だったので今後有効活用していきたい

関連リンク


Rails 6.1's ActiveModel#errors Changes

感想

  • Rails6.1からerrorsの中身が変わるよ!という話でした。
  • いままで独自validationの結果をmessagesに直截足したりするバリデータ作ってたりするのでそこらへんが大変になりそうな変更だった。
  • 地味につらさがある変化なので来たるべきときに備えて対応できるようにしておきたい

関連リンク


Railsワンマン運転の手引き

speakerdeck.com

ざっくり発表内容メモ

  • Railsはサービスではない、そのためサービスとして成立させるためにはどういう要素が必要か?というのをRailsにちなんで鉄道にまつわる要素で説明
  • サーバを電車、駅はロードバランサー、駅名(駅看板)を(DNSのほうの)ドメインとして例えた

感想

  • 初学者向けの内容ではあったが導入やたとえ話の構成がいい感じになっており、とても楽しく聞けた。
  • Railsのコードを書く、というような分業スタイルの人は見えないところなのかなと思うので俯瞰的な視点で考える力を持つことは大切だよなとしみじみ
  • 車掌さんの帽子をかぶったりとリアル会場でなかったのが惜しまれるネタ仕込みだった

関連リンク

Railsはおまかせ(Rails is omakase翻訳) | blog.tai2.net - Rails周りのたとえ話といえばこちらも


継承とメタプログラミング満載なアプリケーションコードでもアクションとフィルタに悩まないためのGemを作った話

感想

  • 継承されまくっているControllerのCallback類を把握するためのgemを作った際に得られた知見の話で、午後の昼後だったのもあり一発では理解するのが難しい話だった。が、とてもcallback実装の丁寧な説明だったので、読み直したい話でした。
  • 地獄のような状況を打破するために自らでgemをつくるというのはよい話だし、業務だったりしたのかな…とか思った。

関連リンク


Action Mailbox in Action

感想

  • 注意を払う必要がすごくあるSMTPの話とActionMailboxの話。
  • 昨今メールサーバーを建てるようなシーンもないし、SaaSのほうがちゃんとやってくれるのでそこに乗っかるべきだなと切に感じた。
  • しかしActionMailbox使うようなシーンって一体…

関連リンク


コードレビュー100本ノックで学んだRailsリファクタリング

スライドは見つけたら貼ります

発表メモ

  • コードレビューを通して得た知見に関しての話、トピックごとに説明があった
    • 命名
    • クエリ
    • 不安定テスト・スローテスト
    • コミットへの意識

感想

  • sleep使うな、findつかえ、というのは心に刻みたい
  • コミットメッセージには理由を添えるというのは案外やってくれないんですよね…と思うのでこうやって定着化しているところはすごいいいなと思っている
  • このあとのkoicさんの話にも繋がりますが、独立した変更単位のコミットを作るというのは大変大事だなと思った
  • ただRailsの場合、Model+Controller+Viewでコミットつくるともりもりになるので、そのもりもり具合でやるのがいいのか悪いのかなどの見解を知りたい感じではあった

関連リンク


育てるSinatra

動画は以下

発表メモ

  • SinatraをベースにRailsライクなものを実装することでRailsを理解する
  • ModelなどはActiveRecordを使うが、Railsがデフォルトでやってくれている設定なども自前で作る必要がある。
  • RailtieというRails本体とも言えるようなものが存在する

感想

  • Sinatra自体存在は知っているが、全然触れたことがなかったので、SinatraのシンプルさとRailsが色々やってくれているというのを改めて感じる話。
  • スライドが再度見れるようになったら見直したい話。

関連リンク


ミドルウェアActionDispatch::HostAuthorizationと学ぶDNSのしくみ

感想

  • ESM第2の刺客、DNSの基礎的な説明からそれを悪用した話、そしてRailsがどうやって防ぐ機構を設けているかという話
  • このスライドで大体理解できる + トラブルシュート集もついていて他の人への情報共有力が高い発表でした。
  • 内容ももちろんですが、スライドのビジュアルも素敵でした。イラストは手書きなんだろうけど、丸の囲みとかも手書きなんだろうか…

関連リンク


Rubyで書かれたソースコードを読む技術

感想

  • Railsにおいてソースコードを読み解いていくテクニックを語るスライド
  • 便利なソース検知 source_location をはじめ、 puts caller で呼び出し元を探る、 gemに動作確認コードを入れていき、戻すときは bundle pristine などの豆知識満載だった

関連リンク


ActiveRecordの歩み方

感想

  • ActiveRecordRubyだから読める!という話でActiveRecordの読み方の話。
  • かなり読むのに根気がいるのがActionRecordなのでライブリーディングもその辛さが出てました。
  • 迷子になるので迷子にならないように目標をもつのが大事そう

関連リンク


Ruby 3.0におけるドキュメンテーションと端末制御の未来

スライドなどではなかったので発表メモだけ… 動画は以下

発表メモ

  • RubyAPIを調べる方法は用意されているが、Googleで調べる利便性には負けるので、そこに対してirb側にドキュメント閲覧できる機能をirbの実装見直しに合わせて組み込んでいる話
  • 上記の話に合わせて豊かな自然の映像とエモい話が要所要所に挟まる。

感想

  • 話のネタ映像が凝り過ぎてて内容が素通りする発表でした。
  • irbとpry、RDocとYARDの関係性に関して手堅くやるべきものと先進的なものとの切り分けをしているという話はなるほどなという感じだった。
  • とにかくビデオプレゼンという形を最大限に利用したプレゼンだった…岸壁登ったり沢下りの映像と技術の話を交えて最後に深い話で閉めるのは印象の強さがすごかった

関連リンク


ひみつきちを作りたい 〜「こどもれっどまいん」テーマ作りでの学び

感想

  • 子供向けのものを作りたい、という形からメッセージカスタムプラグインを作り上げた話
  • i18nを子供向け言葉の変換に使うという発想はなかった
  • フォントの力は本当にあるよなーと思いつつ聞いてました。

関連リンク


快適なリモートワークを実現するために〜RailsでSSOを実現する3パターン

感想

  • 社内ツールのセキュリティ封じ込めアイデア「IP制限」がリモート時代で使えなくなってきたのでそこをどうカバーするかという話
  • 社内的なツールのアカウント管理って会社組織やサービスの拡大に伴って絶対ぶつかる壁なので、この知見はすごく活きる発表だった

関連リンク


TDD with git. Long live engineering.

感想

  • TDDの考え方、GitHub登場前後の状況などの歴史を含めてどういう形でGitHubのPRやコミットはあるべきかという話。
  • 「誰のためのコード?個人のためのコードではなくチームのためのコードだよね」という旨の話は感銘を受けた
  • rebaseとかsquashをちゃんと使いこなせてないので、これを期につかってみたいなと思った。

関連リンク


Sidekiq to Kafka 〜ストリームベースのmicroservices〜

感想

  • ActiveJobの特性から、非同期処理からKafka基盤の利用につながる話
  • Railsでつくったものをいかに置き換えていくかという部分でも知見あるし、ストリームイベントに対しての戦い方みたいな意味でも聴き応えのある話でした。

関連リンク


Coming Soon... 💎

発表メモ

  • OSSをやりたいというが、そのやるに至らないのは技術力不足ではなくきっかけではないかというところからのお話
  • 直したいコードがあったときにすぐ動けるようにするのが大事、そのためにgem-srcなどを準備しておく
  • gemとRailsPluginの違いに関しても当時の状況を交えて説明
  • その後は松田さんが作っているRailsまわりのgemに関してのお話

感想

  • 松田さんの作ってきたものの話といままでの歴史を交えたようなお話。
  • kaminariが出来上がった話はいろいろなところで聞くことはありますが、作者の想像以上に使われたというお話は初めて聞いた感じでした。
  • 「手触り」というのを普通のRubyモジュールを素直に使い、特殊な基底クラスを継承しないなど言語化されていてこの点参考にしようと思った

関連リンク


全体を通しての感想

  • Railsの技術的な取り組み寄りの話多い感じでした。
  • トップバッターのアーロンさんの話が中盤のRackを踏まえた話の前段として機能したり、ソースコードリーディング系の話から最後のOSS貢献の話へつながったりと、かぶっている部分が多少ありながらも
  • 今回リモートということで、Liveでやるひとはもちろん、当日予定があるから録画で対応してくる人、映像交えてやりたいからビデオを出してくる人など色々なものがあってとてもバラエティに富んでいてよかった。
  • スポンサー表示の仕組みなどはすごい旨味あるなーと思いながらみてました。
  • リアルとは違うトラブルなどもあって大変そうでしたが、リアル現場にいけない生活環境の人たちにはすごい良いカンファレンスでした(懇親会とかもいきたかった…)運営の皆様お疲れさまでした!

他の方の感想ブログなど

Railsの raw は <%== と同じ

小ネタ

そもそもrawとは

通常、erbにて変数出力をするときは以下のような構文を用いる

<%= @hoge_var %>

この @hoge_var にHTMLが含まれる場合はRails側でよしなにエスケープ処理がかかり、文字列として表現されるようになる。

ただし、ただのまま変数の文字列をHTMLとして解釈してほしい場合もあるので、その場合はrawを使う

<%= raw @hoge_var %>

rawと同義の記号

Railsガイドに以下のように記述がある通り <%== と同義

rawと同等の<%==を使います。 - Active Support コア拡張機能 - Railsガイド

html_safeではなくraw

似たようなものとしてhtml_safeを使うのがいいかもしれないと思う場面がありますが、内部実装としてはhtml_safeを使っているrawを使ったほうがいい

def raw(stringish)
  stringish.to_s.html_safe
end

関連リンク

インプットとアウトプットのバランスを鑑みた運用変更

雑記です。

近況

ほぼ毎日ペースで更新をしてきたのですが、最近のワタシの状況としては

  • 基本的に案件マネジメントと内部調整がメインでインプットする事柄がない
    • 現職が長くなってきたので、古参ならではの取り回しが増加
    • 業務ドメインに向き合ったり、チームの運用的な話が増えてブログのネタに昇華しづらい
  • 圧倒的リモートワークで残業が減るも、家庭環境の変化で家事時間の比率が増加、時間的にもインプットの時間がない

という状況に陥っているのが現状です。

日々学んだ何かをアウトプットするというのがこのブログのスタンスでしたが、インプットがないので 基本、インプットと同時にアウトプットするというスタイルが続いています。

インプットとアウトプットのバランス

いままでは

  1. 何かしら業務でインプット(技術的な発見、業務で得た普遍的な知識)
  2. 業務時間外で整理
  3. 業務時間外で業務ドメインを排除した形でアウトプット

というスタイルだったんですが、最近は

  1. 業務中に気になった事柄をメモ
  2. 業務時間外でインプット作業を行う
  3. 業務時間外でインプットした事柄を整理
  4. 業務時間外でアウトプット

という感じで、基本ゼロからの記事生成となっており大変キツくなってまいりました。

これからのブログ

割とネタストックはあるので、書きたいことはちょこちょことあるのですが、インプットの量がイマイチだとアウトプットの量もイマイチ感が出てきているのでもう少しその点を改めて行きたいと思っています。 (最近だとスイスチーズモデルとかパスワードスプレーとかレベルの話ももうちょい掘り下げて書くべきだった)

そのため運用として、以下を頑張っていきたいと思っています。(カックさんのメンタリングのエッセンスを取り入れる)

  • 絶対週一回以上投稿
  • 週イチにするのでもうすこしインプットや検証を行ってボリュームアップして「実戦投入力」を鑑みた投稿にする
  • とはいえ時事ネタとかをざっくり書くのは好きなのでそのようなネタが発生したときはボリューム意識せず書く

関連リンク

スイスチーズモデルに関してざっくりまとめる

いろんな文脈で出てくるのでざっくり

意味

スイスチーズの内部に多数の穴が空いているが、穴の空き方が異なる薄切りにしたスイスチーズを何枚も重ねると、貫通する可能性は低くなる。同様に、リスク管理においても、視点の異なる防護策を何重にも組み合わせることで、事故や不祥事が発生する危険性を低減させることができる。 - スイスチーズモデルとは - コトバンク

イメージ図としては以下の感じ

f:id:shinkufencer:20200916234725p:plain
いらすとやより

スイスチーズモデルで語られること

スイスチーズモデルを用いて語られることはいかのようなことがある

  1. 意味で説明した通り、完璧でない防護策も複数用意することによりお互いのカバーしていない範囲をカバーできるため意味があるという守りに関しての話
  2. 複数にわたる防護策を講じて安全を守っていても、その一つ一つの安全をおそろかにしていくと複数あることで守られていたことがらが守れなくなってしまうリスク発生の側面の話

2の話に関しては、組織が抱えた問題が影響を与えることで直接的な事故の引き金に当たる行為になるという形で触れられ、事故は個人ではなく組織が原因になるという話のベースとしてもこのスイスチーズモデルは使われることが多いようです。

参考リンク

テレコとはどういう意味かまとめる

作業会話で使われるのでざっくり書き留める

意味

交互、互い違い、逆、あべこべなどの意。 - テレコ - Wikipedia

もともとは歌舞伎の用語から。

使われる場面

「テレコになる」という現象だがあべこべになっているという状況。

  • 『2重ループの外と中の処理をテレコで書いてしまった』
  • sampleA.comに255.255.255.123 ,sampleB.comに255.255.255.321 としたかったのに sampleA.comに255.255.255.321 ,sampleB.comに255.255.255.123 とテレコしてしまった』

のようなことが挙げられる

字面が似ている全く違う言葉

入れ子

プログラム的にはネストのことを指す、マトリョーシカのような状況

テレコール

電話勧誘販売のこと。

テレコミュニケーション

遠く離れた地域間で、無線や有線の回線を使用して行う通信全般を指す言葉。

テープレコーダー

文字通りテープ式のレコーダー。略称でテレコといわれるが違うもの。

関連リンク

パスワードスプレーに関してざっくりまとめる

トレンドの用語をざっくりまとめる

言葉の意味

同じパスワードを用いて、複数のアカウントへのログインを実行して侵入を試みる方法

どのような考え方なのか

特定の一つのアカウントに対して侵入するのではなく、どのアカウントでもいいから、侵入したい場合に試される手法。パスワードの内容はわからないが、アカウントのリストなどがあれば試せる。

通常、特定のアカウントに対して複数回パスワードでログインすることを試すと、アカウントがロックされる機構はあるが、このパスワードスプレーの場合は防げない。

有効な対抗策

よく挙げられる対策のアイデアとしては以下

  • リストパターンを網羅しにくいパスワードの設定にする(英文字記号混合など)
  • 2要素認証など、パスワードが解けることだけの状態にしない

関連リンク

CNAMEトラッキングとは何かざっくりまとめる

どのようなことを行うのかというのと理由をざっくり

そもそもどういう場面で使われるのか

広告媒体においては、どのユーザーがどのサイトを閲覧したか?という情報は非常に有用で、行動したデータを蓄積することでそのデータからユーザーの興味がありそうな広告を提示することができる。

そのため、ユーザー個人を特定しないという前提の元で横断的なWeb閲覧履歴がほしいのだが、基本的にこの情報を取得することには様々な問題が絡み合っている。

とられる手法

自社のサブドメインの向け先をトラッキングしたい会社のサーバに向ける手法、CNAME自社ドメインをほかサイトのドメインに向ける

なぜこの手法をとるのか

背景

ITP2.3が適用されている現在では、閲覧しているサイトとは別のドメインから発行したCookieやJSを使って発行されたCookieの有効期限はとても短い。

そのため、その回避策として同一ドメインサイトで発行したCookie(≒ 1st Party Cookie)として、Cookieを使えば問題がない、という発想に至ったのがこの手法。

(ファーストパーティクッキーとは、という話は過去記事参照)

危険性

この手法、トラッキングをしたい会社に自社サイトで発行したCookieが見えてしまう可能性があるため、良し悪しがある。

参考