RFCのMUST/MUST NOT/SHOULD/SHOULD NOT/ MAYに関しては個別に使い方を説明したRFCがある

トリビアの泉みたいな見出し

出典

RFC 2119 - Key words for use in RFCs to Indicate Requirement Levels

こちらはIPAの和訳がある

Key words for use in RFCs to Indicate Requirement Levels

どのようなRFCなのか

特定の大文字英単語（MUST / MUST NOT / SHOULD / SHOULD NOT / MAY ,など)が使われる場合はその言葉そのものに意味を持つというもの。

このルールが働くときにかならずある注記

この大文字英単語に意義をもたせる場合には下記の文章を載せろ、とRFC2119内にも記載があり、この文章の有無が効力を発揮するものかを判断する基準になる。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

具体どのようなことを示すのか

大文字英単語が持つ意味合いに関して表にまとめる

表記英語	意味	同列表現
MUST	その規定が当該仕様の絶対的な 要請事項であること	REQUIRED,SHALL
MUST NOT	その規定が当該仕様の絶対的な禁止事項であること	SHALL NOT
SHOULD	特定の状況下では、特定の項目を無視する正当な理由が存在するかもしれませんが、 異なる選択をする前に、当該項目の示唆するところを十分に理解し、 慎重に重要性を判断しなければならない	RECOMMENDED
SHOULD NOT	特定の動作が容認できる、ないし、非常に有用である、というような 特定の状況下では、正当な理由が存在するかもしれませんが、 このレベルの動作を実装する前に、当該項目の示唆するところを十分に理解し、慎重に重要性を判断しなければならない	NOT RECOMENDED
MAY	ある要素が、まさに選択的であることを意味します。特定の選択事項（オプション）を含まない実装は、おそらく機能的には劣る ことになるでしょうが、そのオプションを含む他の実装との相互運用に備えなければなりません。 同様に、特定のオプションを含む実装は、そのオプションを含まない実装 との相互運用に備えなければなりません。	OPTIONAL

文章内の記載例

例えば以下のような記述。下記の例の場合は MUST NOT

The user agent MUST NOT include more than one Origin header field in any HTTP request. (ユーザエージェントは、複数の Origin ヘッダーフィールドを、いかなる HTTP request 中にも含めてはならない) - The Web Origin Concept

RFC8174による追加

「小文字はどう捉えればいいのか」という曖昧な部分に関してRFC8174で「単語はすべて大文字である場合にのみ意味を持ち、そうではない場合は通常の英語の意味を持つ」というように追記が加わった。さらに説明用の一文が下記のように変化している。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

参考リンク

• ASCII.jp：RFCの文中で「MUST」や「SHOULD」に出会ったら…
• RFC8174「RFC 2119のキーワードにおける大文字と小文字の曖昧性」 - ASnoKaze blog

HTTPヘッダのXから始まるものについての歴史と2020年現在での使い方をざっくりまとめる

もともとX-Forwarded-Forを調べていたが前段としてX-hogehoge（以下X接頭辞）についてまとめる。なお和訳はほとんど powered by Google翻訳

出典

このX接頭辞非推奨についてまとめられているRFC6648にそもそもX接頭辞はどう始まったかも含めてまとまっている。

RFC 6648 - Deprecating the "X-" Prefix and Similar Constructs in Application Protocols

X接頭辞のはじまり（RFC6648の付録Aより）

その記述によると最初はFTPのRFC691に記載されている以下の記述が始まり

I suggest that parameters be allowed to be more than one letter, and that an initial letter X be used for really local idiosyncracies （本当にローカル特異パラメータは、複数の文字にすることにし、最初の文字をXにすることをお勧めします） - RFC 691 - One more try on the FTP

またFTPではX接頭辞は使われ…

FTP allows "experimental" commands, whose names begin with "X". If these commands are subsequently adopted as standards, there may still be existing implementations using the "X" form.... ( FTPでは、名前が"X"で始まる"実験的"コマンドを使用できます。これらのコマンドがその後標準として採用される場合でも、"X"形式を使用した既存の実装がまだ存在する可能性があります。) - RFC 1123 - Requirements for Internet Hosts - Application and Support

その後、メールのヘッダにも使われるようになり、RFC1154にて以下の記述が登場する。

Keywords beginning with "X-" are permanently reserved to implementation-specific use. No standard registered encoding keyword will ever begin with "X-". ( "X-" で始まるキーワードは、実装固有の使用のために永久に予約されています。 " X-" で始まる標準の登録済みエンコーディングキーワードはありません。 )

このメールヘッダでの利用を倣ってほかのものでも踏襲されたとされている。（ただしこのあとメールヘッダでの利用は非推奨となる）

バックグラウンドの説明ではこのようにX接頭辞が使いたくなる場面として「標準化される可能性のあるような実験的なもの」や「決して標準化されないような拡張機能」があるとしている。

またこのX接頭辞使用するのは仕様を作る側の個別の選択であり、それをうまく取り込んでいるRFCもあると説明がされている。

X接頭辞の現況

出典のRFC6648によって、2012年6月からはX接頭辞は非推奨となっている。RFC6648では非推奨に関しての前置きで以下のように記述している。

In short, although in theory the "X-" convention was a good way to avoid collisions (and attendant interoperability problems) between standardized parameters and unstandardized parameters, in practice the benefits have been outweighed by the costs associated with the leakage of unstandardized parameters into the standards space. ( 要するに、理論的には"X-"規則は、標準化されたパラメータと標準化されていないパラメータの間の衝突（および付随する相互運用性の問題）を回避するための良い方法でしたが、実際には、標準化されていないパラメータが標準化されたパラメータへと変わってしまうコストがメリットを上回ってしまっています。 )

これは元となったメールヘッダなどがX接頭辞として始まったものが標準化されXを使用しないものとして動かされる事例があることを元に、置き換える際の様々なコストがかかることを懸念して、廃止にすべき…ということのようだった。

X接頭辞を使いたくなる場合どうするべきか

RFC6648には「新しいパラメータの作成者への推奨事項」という記載があり

1. SHOULD assume that all parameters they create might become standardized, public, commonly deployed, or usable across multiple implementations.(それらが作成するすべてのパラメータが、標準化され、公開され、一般に展開され、または複数の実装にわたって使用可能になる可能性があると想定する必要があります。)
2. SHOULD employ meaningful parameter names that they have reason to believe are currently unused.(現在未使用であると考える理由がある意味のあるパラメーター名を使用する必要があります。)
3. SHOULD NOT prefix their parameter names with "X-" or similar constructs. (パラメータ名の前に「X-」または同様の構成体を付けないでください。) - RFC 6648 - Deprecating the "X-" Prefix and Similar Constructs in Application Protocols

というように、そのあと標準化される懸念をしながらX接頭辞に近しいものは使うな、というように念押しされている。

独自ヘッダの事例

思いをはせる、というようなガイドラインになっているが、具体的にはどうするといいのか、他社事例としてOpenStackの事例があった。

OPENSTACKではこのRFCを前提において以下のように OpenStack 接頭辞をつけることをしている。以下説明の抜粋です。

To do this, use “OpenStack” and the service name in the header. An example might be “OpenStack-Compute-FooBar”, which is unlikely to be standardized already or conflict with existing headers.(これを行うには、「OpenStack」とヘッダーのサービス名を使用します。たとえば、「OpenStack-Compute-FooBar」は、すでに標準化されているか、既存のヘッダーと競合する可能性が低いです。) - HTTP Header Guidelines — API Special Interest Group documentation

このように基本的にあるコンテキスト固有のものはこのようにそのコンテキストを象徴する文字列がいいのかもしれないです。

関連リンク

• HTTP ヘッダー - HTTP | MDN
• RFC 4229 - HTTP Header Field Registrations - HTTPヘッダのベースとなるリスト、このリストからIANAにてヘッダの登録管理を行っている

フラッグシップモデルという言葉をざっくりまとめる

ハイエンドモデルと何が違うんだっけ？ってなるので

語源

語源は海軍用語の旗艦（フラッグシップ）から

また、他の多くの海軍用語と同様、「旗艦」「フラグシップ」もほかの用途に転用されて、日常的な用語として使われる。この場合、集団やグループの最も重要な位置付けにあるものを指すが、この最も重要な位置付けとは、通常、ステータス性を持つものや戦略的に重要なものとしての位置づけである。 たとえば、会社の利益を支える主力製品、あるいは会社の技術の粋を尽くしてつくられた最高価格製品を「旗艦製品」「フラグシッププロダクト」と呼んだり、会社の中で最大の設備・規模を有する中核店舗、あるいは先駆的な試みをする位置付けの店舗を「旗艦店」「フラグシップストア」と呼んだりする。 - 旗艦 - Wikipedia

使われ方

重要なプロダクトの"モデル"であることは語源から汲み取れるが、実際に扱われる場合は2つのパターンがあるとされている。

1. そのモデル（またはブランド）において最も機能が優れているモデル
2. そのモデル（またはブランド）において最も重要な立ち位置のモデル

2の意味が本来のフラグシップだと思われるが、それが転じて最高機能を持つモデルという意味合いで使われることが増えた模様

参考リンク

• フラッグシップモデルとは 「フラッグシップ, フラグシップ」 (Flagship Model)： - IT用語辞典バイナリ
• フラグシップ機 - Wikipedia

Railsのmigrationでカラムコメントをつけたいときは comment で記述できる

Railsだとmigrateファイルあるからいらんって言われがちだけどつけたいよね、っていうメモ

環境

rails (5.0.2)

やり方

カラム指定時に comment: "書きたいコメント" をつければOK

例

class AddColumnHogeHoge < ActiveRecord::Migration[5.0]
  def change
    add_column :users, :profile_text, :string, comment: "プロフィールの文章"
  end
end

参考

標準になったのはRails5系からなんですね…

• [Rails 5] マイグレーション時にデータベースのカラムにコメントを追加する｜TechRacho（テックラッチョ）〜エンジニアの「？」を「！」に〜｜BPS株式会社

rubyタグは文字以外の要素の上にもふれる

青空文庫を読んでいたら出てきたので「こういうのもあるのか…」というメモ

記述例

例えば以下のように記述する

<ruby>
<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     viewBox="5 5 10 10" width="20" height="20">
  <circle cx="10" cy="10" r="5" fill="#000" />
</svg>
<rp>(</rp><rt>黒円</rt><rp>)</rp>
</ruby>

そうするとこのように円のsvgの上にルビをふることができる。

ルビがsvgの上にふられる

参考リンク

• 芥川龍之介 羅生門 - 肩で息を切りながら、眼を、眼球めだまが〜 の下りでまぶたという字を画像でおいてrubyタグで表現することをしている

RubyのArrayなどでfirstは空ならnilを返すことがあるので、気をつけて使おう

Railsだけど、自分の体験した辛さを言語化するシリーズ

要約

messages.first.title とかやるとコケるので、ちゃんとこういうことを考慮した作りにして欲しい。

遭遇した事象

Railsのview上に以下のようなコードがあった

<div class="title">
    <div id="notifce_message">『<%= @messages.first.title %>』が最初のメッセージタイトルです</div>
</div>

複数あるメッセージの中で最初のメッセージが届いている旨のコードである。だがこの @messsages が 0件の場合は @messages.first の結果が nil になるため nil.title しようとしてエラーになる。

回避の考え方

回避の考え方とはとしては2つある

1. nilにならないようにする
2. nilでも大丈夫なようにする

nilにならないようにする

無理やりfirstでとってきてメソッドチェインで解決しようとするからまずいので、ちゃんとそれように変数に詰めるなり、メソッドを用意してあげる。

今回の例の場合はdecorator系のメソッドを用意してあげれば解決する。

def first_message_title
  return "" if @messages.first.nil?
  @messages.frist.title
end

<div class="title">
    <div id="notifce_message">『<%= first_message_title %>』が最初のメッセージタイトルです。</div>
</div>

nilでも大丈夫なようにする

messageは1件以上入ることが絶対で、メソッドをつくるほどでもない場合はボッチ演算子で回避することもできる。ただしこれは使い方によってエラーを正しく認識出来ない場合があるのでケースバイケース

<div class="title">
    <div id="notifce_message">『<%= @messages.first&.title %>』が最初のメッセージタイトルです</div>
</div>

参考

• 【RubyonRails】tryとtry!の違い【ぼっち演算子&.とは】 - SakuraWi - BLog

AWSのインスタンスにおける バースト / クレジットの考え方をざっくりまとめる

クレジットを食いつぶす展開、とは何か。

出典

バーストパフォーマンスインスタンスの CPU クレジットとベースライン使用率 - Amazon Elastic Compute Cloud

バーストパフォーマンスとは

バーストパフォーマンスインスタンスに関して以下のように説明がある

T3、T3a、および T2 インスタンスを含むバーストパフォーマンスインスタンスは、ベースラインレベルの CPU パフォーマンスを実現するとともに、ワークロードの必要に応じて高いレベルまでバーストする機能を実現できるように設計されています。 - バーストパフォーマンスインスタンス - Amazon Elastic Compute Cloud

上記の記述にあるとおり、ベースラインレベルのCPUから高いレベルの機能を発揮できるのがバーストということになる

ベースラインのCPUパワーとクレジット

バーストを語るときにCPUクレジットの概念を考える必要がある。CPUクレジットとは以下のように説明されている。

CPU クレジットは、1 分間の CPU コア全体の使用率を 100% にします。その他の vCPU、使用率、時間数の組み合わせを CPU クレジットと同じにすることができます。たとえば、1 個の CPU クレジットは 1 台の vCPU を使用率 50% で 2 分間実行するか、または 2 台の vCPU を使用率 25% で 2 分間実行するのと等しくなります。 - バーストパフォーマンスインスタンスの CPU クレジットとベースライン使用率 - Amazon Elastic Compute Cloud

1分間100%のパワーを使うための単位が1クレジットです。そのため、CPUが2つあると、2クレジットないと100%の力を出せず、1クレジットの場合は各CPUが50%が限界となります。

クレジットの増加方法

クレジットと蓄積できるクレジットの最大値はインスタンスタイプによって追加のされかたが違います。

例えばt2系だと以下のようにドキュメントに記述されています

タイプ	60分あたり獲得できるクレジット	蓄積可能なクレジット	vCPUの数
t2.micro	6	144	1
t2.small	12	288	1
t2.medium	24	576	2
t2.large	36	864	2

上記のようにクレジットが付与されるので60分間100%フルパワーを使うことはできないようになっている。

例えばt2.smallは60分あたりに12クレジットしか獲得できないので1時間あたり20%以上のCPUパワーを使うとCPUパワーが枯渇してしまう。このように順当に使うと使い切るのをベースライン使用率とドキュメントには記載がされている。

ただし、その代わり費用が低く、20%以下の時間帯があればクレジットを貯蓄することが可能となっている。

上記を踏まえバーストとは

そのためバーストパフォーマンスとはベースラインを超えたパフォーマンスを利用することであり、アプリケーションがベースラインパフォーマンスを常時使い続ける仕組みだと、バーストさせることはできない状態になる。そのため常に一定量使うようなアプリケーションではバーストパフォーマンスのインスタンスタイプが適正かは考えたほうがよいと思われる。

また、ピークタイムが存在するアプリでも蓄積量以上に瞬間消費が上回るとクレジットの追加分の補填が間に合わず、食いつぶしてしまう。そのため安定性を重視する場合はバーストパフォーマンスインスタンスを選択するのが最善なのかなどは考えたほうが良いと思われる。

参考リンク

• ちょっと待ってください!あなたが使うべきは本当にT系インスタンスですか!? ｜ Developers.IO
• 私はAWS EC2のt2インスタンスを誤解していた - CPUクレジットとベースラインパフォーマンス、そしてT2 Unlimited - SMARTCAMP Engineer Blog