週刊Railsウォッチ（20170414）サーバーを危うくする1行のコード、PostgreSQL 10の新機能ほか

こんにちは、hachi8833です。中途半端な季節が続きましたがやっと本格的に春になりましたね。

今週はRubyとRailsの公式情報の更新はありませんでした。RubyWeeklyは昨日最新版が公開されましたが、本日は追いきれないので来週お伝えいたします。

Chromeブラウザにヘッドレスモード

morimorihogeさんが昨晩fetchしました。

!!! chrome –headless !!!https://t.co/knIfp0putc

— Urabe, Shyouhei (@shyouhei) 2017年4月13日

ヘッドレス/サーバー環境でChromiumを使えるようになります。ページの読み込み、DOMなどのメタデータの展開、ページコンテンツからのビットマップ生成などに利用できます。

https://www.chromestatus.com/features/5678767817097216より

以下のように起動することでChromeをヘッドレスモードで起動できます。

chrome --headless --remote-debugging-port=9222 https://chromium.org

サーバーを危うくするたった1行のコード（Ruby Weeklyより）

元記事: One Line of Code that Compromises Your Server

セッションシークレットの扱いを主題にした、Railsに限定しないセキュリティ記事です。以下は同記事のサイドバーにある危険なセッションシークレットの例です。

Djangoのsettings.py

SECRET_KEY = 'super secret'

Playのapplication.conf

play.crypto.secret = "super secret"

Expressのserver.js

secret: 'super secret'

脆弱なセッションシークレットのクラック方法
- 辞書攻撃
- 注意事項
- 影響
アプリケーションを乗っ取る
- 影響
サーバーを乗っ取る
- サーバーでコマンドを実行する
- サーバーからデータを抜く
- 影響
防止策
- アプリケーション開発者のできる防止策
- ライブラリ・フレームワーク作者のできる防止策
結論

補足

以下はBPS Webチームリーダーのmorimorihogeさんの解説です。

この手のsecret keyは、どんなに長い引数を渡してもOpenSSLのdigestとかでハッシュ化すると同じ長さになるので、長さとかあまり気にせずに以下のような感じで適当にランダム文字列をぶち込むのが良いと思います。

head -c20 /dev/urandom | base64

複数台構成時にはそれぞれのsecrets.ymlに同じ値を入力しないといけなくなることがありますが、secrets.ymlに直接秘密キーを書くのはどうしてもはばかられます（ましてやGitリポジトリに登録してはいけません）。そういうわけで、近年のインフラ界隈では、AWSやDockerのインスタンス・コンテナ起動時にこの手の秘密の文字列を環境変数経由で渡すのが流行りです。

AWSの場合、秘密キーの渡し方として例えば以下のような方法が考えられますね。

AMIに入れておいて、普通にファイル管理する（楽だけど、AMIが抜かれると死亡）

EC2 instanceの起動時オプションで環境変数として突っ込む

EC2 instanceのタグ情報として入れておき、ec2 metadataから拾う

privateなS3とかにデータを置いておき、AMI起動時にそこから取ってくる

dockerなら -e オプションです。

月刊卜部さん

最近のruby-core (2017年3月)

詳しくはリンク先をご覧いただくに限ります。その中からいくつかを（リンク先は同記事のトピックです）。

#13072 Dateライブラリがメンテナンスされてない問題

ある意味衝撃でした。「Timezoneに影響されないDateはそれはそれで必要になるときもあるんじゃね？」などの意見がありました。

#13045 キーワード引数に文字列keyのハッシュを使いたい=>却下

最近TechRachoで記事にすることの多いRubyキーワード引数ですが、「文字列keyのキーワード引数を言語レベルでサポートするのは確かに抵抗があるなー」と卜部さんに一同うなずきました。

参考: Techracho キーワード引数関連の記事

#13241 Unicode文字の文字クラスを返すメソッドが欲しい

どうなんでしょうね、この機能誰が使うんでしょうか。
同記事より

文字コード厨の私もそういうメソッドが欲しいと思ったことはごくたまにしかありませんでした。
言語ごとにえっちらおっちら実装するより、unicode.orgが公式のAPIを用意してくれる方がありがたい気がします。

なお、Unicode文字から文字クラスなどの情報を知るのにはfileformat.infoが今のところ便利です。

#13077 `String#fstring`で`String#@-`のdupを抑制

Ruby 2.3からString#@-というものがあったことを初めて知りました。文字列の前に@-というのは、知らなかったらとまどいそうです。

– self -> String | self
self が freeze されている文字列の場合、self を返します。 freeze されていない場合は元の文字列の freeze された複製を返します。

Railsで巨大データを複製するには（RubyFlowより）

元記事へのリンク: Deduplicating Large Data With Rails

ログファイルを例にした巨大データの容量節約方法についての記事です。
ログエントリのほとんどは内容が同じであることに着目し、UserのログエントリをDigest::MD5.hexdigestでハッシュ化し、同じエントリが既にあれば保存しないようにすることで、同一の大量ログエントリによる容量増大を防ぐ手法を紹介しています。UserモデルとLogモデルとのリレーションの間にUserLogモデルを置くのがポイントです。

それに対し、社内で「そもそもDBにログを保存するという発想をやめるべき」というツッコミがありました。もっともでした。

RailsのPumaのマルチスレッド時ベンチマーク（Ruby Weeklyより）

元記事: Rails Benchmarking: Puma and MultiProcess

記事冒頭で、以前のRailsウォッチでも取り上げたRubyのGIL（global interpretation lock）問題に触れています。

同記事ではPumaのスレッド数が16になると急速に応答速度が低下したことが示されており、Pumaスレッド数などを適切にチューニングすることでパフォーマンス低下を回避できる可能性があると述べています。社内でも「これはよい話！」という声がありました。Puma最適化に関心のある方向け。

http://engineering.appfolio.com/より

なお、セクション見出しの「Per Aspera Ad Astra」はラテン語の格言「苦難を通じて栄光へ」だそうです。

参考: Wikipedia-ja グローバルインタプリタロック

Bundler 1.14の新機能（Ruby Weeklyより）

元記事: What’s new in Bundler 1.14?
Changelog

アップデートするgemが依存している他のgemアップデートをupdate --conservativeで抑制、すべてのgemでのチェックサムバリデーション実行、バイナリ版gemをforce_ruby_platformで強制的にコンパイル&インストール、など多くの改良が加えられました。

同記事によると、rubygems.orgでインデックスフォーマットが改定されたことでupdate --conservativeできるようになったそうです。

gemを1つアップデートしただけで連鎖反応的に依存gemがごっそりアップデートされてトラブルの原因になるのはよくある話ですが、そんなときにupdate --conservativeが使えるのはありがたいことです。

Bundlerは思っていたよりも動きが激しいですね。

AWS LambdaとCloudwatchでSidekiq監視するときのコツ（Ruby Weeklyより）

元記事: MONITORING SIDEKIQ USING AWS LAMBDA AND CLOUDWATCH

http://brandonhilkert.com/より

lambdaでカスタムメトリクスを定義するという、AWSにおけるbest practice的な記事です。

morimorihogeさん曰く「auto scalingのトリガメトリクスなんかはCPUとかだと指標としてぶれすぎるので、こうやってカスタムメトリクスを作る方がよいかもしれないですね」とのことでした。

「特異なRuby」シリーズ（Ruby Weeklyより）

サイト: Idiosyncratic Ruby

Stringオブジェクトの作り方210種やグローバル変数リストなどのRubyトリビアが多数紹介されています。

なにしろトリビアなので、実用を置き去りにした「よくこんなこと調べたな」的なマニアックなリストだらけです。「茶飲み話にいいかもね」との声も。

参考: [Ruby] Kernelの特殊変数をできるだけ$記号なしで書いてみる

GraphQL: Facebookが開発した一般性の高いAPIクエリ言語

公式サイト: http://graphql.org/
リポジトリ: rmosolgo/graphql-ruby

nettofarah/graphql-query-resolverというgemからたどりました。SQLをJSON化したような趣で、型も扱えます。

http://graphql.org/より

「この手のクエリ言語は山ほどあるので、自分好みで選べばよいんじゃね？」や「どちらかというと『この言語で実現できないAPIは書かないようにしよう』みたいに考えれば糞APIを作らずにすむかもね」などの意見がありました。

参考: GraphQLについて調べてみた

小ネタ: Rails vs PHP（Ruby Weeklyより）

PHPをダシにしたRailsプロモーション動画シリーズです。

日本のIT系の会社でこういうことってなかなかやりませんね。「ジャーはJarということでJava vs Railsの方が韻を踏んでていいんじゃね？」という声もありました。

Slack的なチャットアプリはオープンソースコミュニティには不向き（HackerNewsより）

元記事: Why Slack is inappropriate for open source communications

元記事の作者は、Slack/HipChat/Gitterなどの即座の返信を前提とするチャットアプリの利用がオープンソース界隈で増えていることについて問題を感じています。この手のアプリは社内チャットなどであれば非常によいが、オープンソースコミュニティでは「クローズドなのでTwitterにリンクひとつ貼れない」「議論を後から追いかけて参加しにくい」などの欠点が目立つので、メーリングリストやissue trackerやフォーラムの方がまし、という意見。

個人的にはGitのIssue trackerがやっぱり好きです。

PostgreSQL 10の新機能（HackerNewsより）

New Features Coming in PostgreSQL 10

リリースの近いPostgreSQL 10で導入が予定されている新機能です。今ざっとだけリストアップします。

この他にも新機能・改良が盛り沢山なようです。近日中に別記事で追ってみたいと思います。

夜でも昼間のようにフルカラーで撮影できるカメラ（HackerNewsより）

元記事: Incredible low-light camera turns night into day

スターライトスコープのような暗視装置やサーモグラフィーや赤外線カメラは、その性質上自然なカラー表示が不可能でした。

この記事で紹介されているのは、ごくわずかな光さえあれば昼間のように自然なカラーで撮影できる驚異的なカメラです。急に強い光を当てたらやっぱり壊れるんでしょうか。

今週は以上です。

今週の主なニュースソース

ソースの表記されていない項目は独自ルート（TwitterやRSSなど）です。

Ruby Weekly

RubyFlow

Hacker News

この記事の著者

hachi8833

Twitter: @hachi8833、GitHub: @hachi8833 コボラー、ITコンサル、ローカライズ業界、Rails開発を経てTechRachoの編集・記事作成を担当。これまでにRuby on Rails チュートリアル第2版の半分ほど、Railsガイドの初期翻訳ではほぼすべてを翻訳。その後も折に触れてそれぞれ一部を翻訳。かと思うと、正規表現の粋を尽くした日本語エラーチェックサービス enno.jpを運営。実は最近Go言語が好き。仕事に関係ないすっとこブログ「あけてくれ」は2000年頃から多少の中断をはさんで継続、現在はnote.muに移転。