バッファは基本全部使われてしまうという話と「パーキンソンの法則」の関連性についてまとめる

「バッファなんて作ったら結局全部使い切るんだよ」という話はあるがどういう考え方なのか、パーキンソンの法則というキーワードからのざっくりまとめ

出典

第1法則
仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する
第2法則
支出の額は、収入の額に達するまで膨張する
- パーキンソンの法則 - Wikipedia

もともとの話

もともとは組織の拡大とともに人は増えるが、本質的な業務が増加するからではなく、組織が拡大するにつれてその組織内の調整のためのコストも膨れていくため、新しく投入した人員の分だけ拡大していくわけではない。何かを成すために投入され、ある程度余裕を見越して投入されているはずなのに様々な些末ごとで埋まっていく。

この話の元ネタは官僚組織において本質的な仕事よりも部下を増やすことやっきになるコストでどんどん時間が食いつぶされていく様を分析した話ということだった。

プロジェクトマネジメントへの転用

このパーキンソンの法則の第一法則の文章がプロジェクトマネジメントの工程と組み合わさり、以下のような解釈になった。

「決められた工程日数よりもたとえ早く終わったとしても、決められた工数日数を使ってから次の作業に入る」

これは『早期完了の未報告』と呼ばれる現象で文字通り「早く終わったけど終わったと報告せずに時間を使い切るまで報告しない」というような話につながっている。

（この解釈に関してはは書籍『Critical Chain』で語られている）

バッファを食いつぶす、という観点の整理

パーキンソンの法則というよりも「早期発見の未報告」という観点が強く、細分化されたタスクひとつひとつにバッファを積むと、自然と食いつぶしてしまうので、個別のタスクにバッファを積むべきではない、という話につながる。

参考リンク

• パーキンソンの法則（ぱーきんそんのほうそく） - ITmedia エンタープライズ
• 第7回 クリティカルチェーン | イノベーションマネジメント株式会社
• CCPMのおはなし2-7（原理編7）：プロマネで発生しやすい問題②：タスク編（後編） | どしろうと製作所：WebLog

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?

Rubyにおける ! を二重にした !! の使い所

エクスクラメーションマークの重ねがけ、二重のビックリマークなど、読み方が難しいやつ

環境

$ ruby -v
ruby 2.6.6p146 (2020-03-31 revision 67876) [x86_64-linux]

効能

明確に true か false にしたいシーンがあるときに ! をかけてtrueかfalseにしてからさらにもう一回 ! をかけると、明確にtrueかfalseか表現することができる

x = 1
puts !!x
true

そのため、オブジェクトの存在チェックをする場合は !! をすると有効

余談:真と偽になるパターンに関して

基本Rubyの世界では false と nil 以外は真で評価をされる

false は nil オブジェクトとともに偽を表し、その他の全てのオブジェクトは真です。 - class FalseClass (Ruby 2.7.0 リファレンスマニュアル)

そのため下記のようなif文は成立する

x = 1
puts 2 if x
2

x = nil
puts 2 if x
# 何も出ない

このようなことがあるため !!hoge を能動的に使いたくなる場面は、? をつけるようなクラスを提供する時が多いかと思われる

読み方

英語圏では ! を bangと読むことがあるらしく、double-bangと読む読み方があるとのこと。

参考リンク

• Rubyの否定演算子2つ重ね「!!」（double-bang）でtrue/falseを返す｜TechRacho（テックラッチョ）〜エンジニアの「？」を「！」に〜｜BPS株式会社

Rails(ActiveSupport)の blank? は false も trueになる

Railsガイドにも乗ってますが、改めてコードを掘り下げて挙動を見る。

環境

$ bin/rails -v
Rails 6.0.3.1

挙動

a = true
a.blank?
#=> false

a = ""
a.blank?
# => true

a = false
a.blank?
# => true

ソースコードから読む

かなり明快

def blank?
  respond_to?(:empty?) ? !!empty? : !self
end

rails/blank.rb at master · rails/rails · GitHub

empty? を持つオブジェクトであれば empty? の結果を !! を用いて 完全にtureか、falseのどちらかに変換する。持っていない場合は自分自身にnot演算子をかけた結果を返す。

false である FalseClass は empty? を持たない。

FalseClass.method_defined?(:empty?)
#=> false

そのため、結果は !false で trueになる。

参考リンク

• Active Support コア拡張機能 - Railsガイド

2020年8月現在、Slack(フリー版を除く)には「スター付き(Stared)」と同じ欄を作る機能がある

会社で有料版使っているのにみんな意外と知らない section の機能のことを雑に書く

出典

カスタムセクションを使用してサイドバーを整理する | Slack

機能的な説明

Staredのメニューの中にsectionを作る項目があるのでそれを押すと下記のような画面が出てくる

新しいセクションを作る画面

ヘルプに色々書いてあるんですが箇条書きで特徴を書くと以下の感じ。

• 昔からある「スター付き（Stared）」と同列でグルーピングをするための「カスタムセクション」という枠が作れる
• Staredもカスタムセクションと同列の存在なので含めて並べ替えることが可能
• カスタムセクションにはemojiが設定でき、見出しとして使うことができる

自分のステータスのemojiと似た形でセクションごとにemojiが設定できる

並べるとこんな感じ

参考リンク

• 大事な内容に集中する | Slack
• Slackのチャンネルをprefixでまとめてくれる拡張を作りました！ - Qiita - そういえば非公式であったけど今動くのだろうか…

ソフト404とは何なのかざっくりまとめる

ソフト404って結局何がどういうことなんだっけ、というざっくりまとめ

出典

ソフト 404 エラー - Search Console ヘルプ

初出（と思われるもの）

HTTP 404 - Wikipedia 曰く ソフト404という用語は Sic Transit Gloria Telae : Towards an understanding of the Web's decay にて紹介されたとされている。

この論文では死んだページとその検出アルゴリズムについて書かれているのだが、その説明の中で下記のように語られている

ただし、今日の多くのWebサーバーは、存在しないページに対するHTTPリクエストを受信しても、エラーコードを返さないことがわかりました。 代わりに、OKコード（200）といくつかの代替ページを返します。 通常、この代替は、エラーメッセージページ、そのホストのホームページ、またはまったく関連のないページです。 上記のように動作する、存在しないページを「ソフト404ページ」と呼びます。

このように定義が書かれており、この用語がままつかわれるようになっている。

具体的にはどのようなページか

「ソフト404」と言われるものは、以下の要素をもちあわせている

• HTTPステータスコードは200OK
• ただし画面上の表記は「コンテンツが見つかりませんでした」などの表記で、汎用的な対応するページがないエラー（広い意味での 404 の状態）

ソフト404は何が良くないのか

この状態が芳しくない理由をGoogleのヘルプでは以下のように記載されている。

検索エンジンでは、成功コードが返されると、その URL に実際のページがあるものと判断します。その結果、ページが検索結果に表示され、検索エンジンは実際のページをクロールする代わりに、存在しない URL を引き続きクロールしようとします。

この状態が起きると具体的に何が良くないかがわかりにくいが、ことGoogleのbotにおいては以下のようなことになる可能性がある。

1. 存在しないページなのに存在するステータスコードを返すため、検索ボットクローラーが「意義のああるページ」と誤認する
2. ソフト404ページの実際の中身は「ページがない」という旨を知らせる共通HTMLであることが多いので、クローラーは同じページがたくさんあると誤認する
3. 同じ構成のページがたくさんあると重複コンテンツにあたるため、どれが正しいページが見定めようとする
4. 正しいページの見解を見誤ると検索に引っ掛けるための精度が下がるため、適切なページが検索結果に出にくくなる

※3,4に関しては重複コンテンツの説明である下記ページ参照のこと 重複した URL を統合する - Search Console ヘルプ

直接的にはソフト404自体でペナルティになる…ということはないが「重複コンテンツ」の仕組みとかけあわさると、正確な情報がクローリングされなくなる恐れがある、という問題に発展する可能性がある、というレベルが現在の実態の様子だった。

関連サイト

• ウェブの重複とは？――Google Webmaster Conferenceのライトニングトークより #GWCPS | 海外SEO情報ブログ
• 重複コンテンツが発生する理由、検索に与える悪影響、防ぐ方法などをGoogleが詳しく解説 | 海外SEO情報ブログ
• PWAサイトで、404エラーを返すべきなのに200を返してしまう <= noindexタグでソフト404扱いさせる | 海外SEO情報ブログ

URLで//(スラッシュスラッシュ)から記述してschema（プロトコル）を省略すると、現在のページのschemaで動く

いい感じにわかる情報がなかったので

出典

RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax

要約

//example.com などと http の部分（schema/プロトコル)を省略して記述した場合は、開いているページのものをそのまま使う。

内容と考え方

// で始まる net_path として定義されている。

net_path = "//" authority [ abs_path ]

また、この net_path は相対参照であることが記載されている・

The syntax for relative URI takes advantage of the <hier_part> syntax of (Section 3) in order to express a reference that is relative to the namespace of another hierarchical URI.
relativeURI = ( net_path | abs_path | rel_path ) [ "?" query ]
A relative reference beginning with two slash characters is termed a network-path reference, as defined by <net_path> in Section 3. Such references are rarely used.

これを和訳すると以下の通り

相対URIの構文は、別の階層URIの名前空間に関連する参照を表すために、（セクション3）の<hier_part>構文を利用します。
relativeURI = ( net_path | abs_path | rel_path ) [ "?" query ]
セクション3の<net_path>で定義されているように、2つのスラッシュ文字で始まる相対参照は、ネットワークパス参照と呼ばれます。このような参照はほとんど使用されません。

これらより以下のことでschema部が補完される。

• // から始まるURIは相対参照（ネットワークパス参照）と呼ばれるの相対URI扱い
• 相対URIなので通常の https://example.com/a.html で <img src="images/sample.gif"> 記述したときに <img src="https://example.com/images/sample.gif"> と補完されるのと同じ原理でschema部が補完される。

参考サイト

• あーありがち - schemeのないURLは相対URL
• Uniform Resource Identifier (URI): 一般的構文
• HTMLやCSSでのプロトコル表記（http:、https:）の省略について: 小粋空間
• リンクの http: や https: を省略して現在のプロトコルでリンク先にアクセスさせる - Qiita

GitHubのカバレッジなどのバッチと同じような画像が作れるサイト shields.io

カバレッジバッジとかの画像と似たようなものが自作できるのでメモ

サイト

Shields.io: Quality metadata badges for open source projects

このサイトの便利ポイント

画像生成サイトは数多があるが、このサイトの便利なところはURLで画像の中身を設定できるところ。

命名規則は簡単で

https://img.shields.io/badge/{{ラベル名}}-{{メッセージ名}}-{{色名称}}

例えばテストが通過したなどのアイコンを作りたい場合は以下のような感じのURLを指し示せばOK

https://img.shields.io/badge/test-complete-green

なお、日本語も使える。

また、動的につくる仕組みも用意しているので自前のサイトでシンプルなバッジを用意する際などには便利。

• JSONの在り処を示すと、そのJSONを元にバッジを作るなど動的に作る仕組みのEndpoint
• 既存の配信データから特定の部分を指し示すことで任意のデータを見せるDynamic

Dynamicについて

DynamicはJSONの指定位置を指し示してデータを取得する方法。

データの指定としては以下のようなルールになっている（ドキュメントらしいドキュメントがないのでざっとの説明）

UI上の名前	入れるデータ
label	左側に記載される文字
data url	今回の情報取得元のURL
query	取得したい情報の位置を示す文字列。JSONの場合は$. から初めてキー名を指定してあげる。
color	右側に記載される動的文字列の色名
prefix	動的取得した文字の前に記載する文字
prefix	動的取得した文字の後に記載する文字

QiitaAPIを使った事例

たとえばQiitaの記事APIは以下のようなJSONになっている（完全な資料はAPIドキュメント参照）

{
  "rendered_body": "<h1>Example</h1>",
  "body": "# Example",
  "coediting": false,
  "comments_count": 100,
  "created_at": "2000-01-01T00:00:00+00:00",
  "group": {
    "created_at": "2000-01-01T00:00:00+00:00",
    "id": 1,
    "name": "Dev",
    "private": false,
    "updated_at": "2000-01-01T00:00:00+00:00",
    "url_name": "dev"
  },
  "id": "c686397e4a0f4f11683d",
  "likes_count": 100,
  "private": false,
  "reactions_count": 100,
  "tags": [
    {
      "name": "Ruby",
      "versions": [
        "0.0.1"
      ]
    }
  ]
 //#### 以下略 ###
}

この場合LGTM数はlikes_countなので下記のようにURLを指定するとLGTM数を交えたアイコンが作れる。

そのため今回は下記のようにデータを指定した

UI上の名前	入れるデータ
label	Qiita
data url	https://qiita.com/api/v2/items/f2651073fb71416b6cd7
query	$.likes_count
color	green
prefix	LGTM数は
prefix	LGTM

そうすると下記のようなURLが生成され、動的に画像が表示される。

https://img.shields.io/badge/dynamic/json?color=green&label=Qiita&prefix=LGTM%E6%95%B0%E3%81%AF&query=%24.likes_count&suffix=LGTM&url=https%3A%2F%2Fqiita.com%2Fapi%2Fv2%2Fitems%2Ff2651073fb71416b6cd7

関連リンク

• shields.ioを使って技術系アイコンを量産した - Qiita
• プルリクエストへのコメントでは Text Blaze でラベルバッジをつけよう！ - Qiita