kbigwheelのプログラミング・ソフトウェア技術系ブログ

プログラミング・ソフトウェア技術系のことを書きます

slack知見

駄文

某scalikejdbcな人に教えてもらったslack app周りのノウハウ。 アプリを作りたかったので助かる。 以下の記述が間違っていたとしたら僕の書き間違い・理解の間違い。

  • 認証
    • よく読めばわかるがslack appの認証はOAuth
    • 現在の認証はbot tokenとuser tokenだけでよい
    • 旧bot tokenはすべての権限が付与された新bot tokenと等価。逆に言うと新botトークンは権限が選択式になった旧botトークン
    • user tokenは基本的に使わない。user tokenが必要なのはその人自身の権限でしかできないようなアクションをするとき
      • 例としてはその人に成り代わってpostするときや、一部の管理者権限はbotではもたせられないのでworkspace(team)でのadministrativeなアクションをするときはuser tokenである必要あり
    • workspace tokenは従来のbot tokenを更新する目的で作られかけたがうまくいかずdeprecated。ドキュメント上で言及されたり仕様例が残っているところもあるが使わないこと。
    • botトークンは管理者がインストールしてもユーザーがインストールしても機能が変わらない。
    • 基本的にbotトークンで済む場合はbotトークンを推奨
  • スラッシュコマンドは今後推奨されない？
    • 廃止されることはないが、先日発表されたショートカットのほうがGUIがあり便利なのでそちらを今後は推奨
    • ショートカットとスラッシュコマンドの両方を実装するのはあり
  • slackのドキュメントはナラティブに書くという方針があるらしく、英語ネイティブでないと読みづらかったりその方針のために？古い記述がよく残っている

「Kubernetesで実践するクラウドネイティブDevOps」感想・メモ

技術書感想

ソフトウェアエンジニアリングを10年以上やってきて、つまりはその年月の間ずっと技術を学習し続けたのだけど、 最終的に行き着いた学習方法はとりあえずやってみて、必要と感じた部分をピンポイントでググって調べる。 ある程度身についたら入門本やwalkthrough系の本を1冊丸々読んで欠けていたり自学で盲点となりやすいポイントを掬う、というものになった。

というわけでこの本はそのKubernetesのwalkthroughになる。その目的としては非常に優秀で良い本だった。

以下メモ

1章

3つの革命。

  1. クラウド
  2. DEvOps
  3. コンテナ

メインフレーム → クラウド 一周してきた

P6

一見どう見えようとも、それはつねに人間の問題である。

P14

Kubernetesによる抽象化でクラウド固有の詳細が隠されるため、...

これは嘘。ALBを使うにはalb-ingress-controllerを使う必要があるし、そうでなくてもLBへ証明書を割り当てるためにALB専用のアノテーションをつける必要がある。

Kubernetesが得意としないものもある。例えばデータベース。あとFaaSのほうがよいものもある。

P 18

個々の開発チームでは、チームが提供するシステムやサービスの健全性を担当する運用専門家が少なくとも1名は必要になります。

やっぱそうよなあ。

P 19

開発者生産性光学(Developer Productivity Engineering, DPE)

なるほど、従来の運用専門チームに変わる、分散化した運用者のために共通ツール・ノウハウを作って支援する部署)。

2章

P28

これと比較すると、公式のRubyコンテナイメージはサイズが1.5GiBで、Goイメージの約250倍もあります。

草。その通りだねとしか言えない。

P33

結構minikubeのセットアップには苦労した。特にdriverがvirtualboxとkvmとnoneの3種類あって、標準は遅いがbattle proofのあるvirtualboxなのだけど、ubuntuの最新virtualboxが6.x系ナノに対してminikubeの互換バージョンは5x系らしく、結局noneにした(パフォーマンスも良さそうなので)。

macでどうするかはまたひと悶着ありそう。docker for macのkubernetes使う手もあるそうだけど、kubernetes公式的にはminikube。なんとなくminikubeのほうが良さそうな気がするが手軽なのはdocker for macか？

3章

P41

何もない状態からKubernetesを本番の設定で運用し始めるためには、エンジニアの給与で約100万ドルが必要になると推定しています(「それでも目的を達成できないかもしれません」)。

これが西海岸のバブル給与だとしても、オンプレでやる場合日本円でも数千万はかかるというのは納得感がある。

P42

ぐだぐだと中小企業ではKubernetesを運用するのは高コストだからマネージドサービス使えと数ページ使って書かれている。

P43

著者らだけでなく、本書のためにインタビューした多くの人々の経験でも、Kubernetesを実行する最善の方法はマネージドサービスです。以上

P44

GKEのオートスケール

EKSはデフォルトではできない機能で羨ましいところ。

P45

とはいえ、マネージドKubernetes市場では最後発であるため、EKSがGoogleやMicrosoftのサービスに追いつくまでにはまだじかんがかかるでしょう。

AWSさんもっと頑張ってくれー (・∀・ )っ/凵⌒☆ﾁﾝﾁﾝ

P51

「実行するソフトウェアを減らす」という哲学には3本の柱があり、いずれも時間をうまく使って競争相手に打ち勝つために役立ちます。 1. 標準のテクノロジを選ぶ 2. 差別化につながらない面倒な作業はアウトソーシングする 3. 長続きする競争優位性を生み出す Rich Archbold

これいいね。

P54

それがAzure Container Instances やAWS Fargateなどの、いわゆるクラスタレスサービスです。

この呼称初めて聞いた。いいね。

P63

一般にDeploymentはユーザーが直接触るけどReplica Setを直接触ることは少ない

ほえー確かに。これ言われるまでPod, Replica set, Deploymentは3セットで人に説明していたわ。

P69

実際、ServiceとIngressはどちらも、クラウド型のロードバランサを自動的に作成できます。

この2つが似ているという認識はやっぱり正しいみたい。

P73

helmの辺りはなかなか刺激的だった。これなら自分でもchartを作れそうと思う。

P82

gRPC probe

それが簡単だからと安易にkubernetesの仕様へgRPCのプロトコルなどを組み込まなかったのはさすがの判断。OSSとして抑えなければいけない中立性をよくわかっている。

P83

readiness probeとliveness probeの違いというか使い分けがよくわからない。livenessが生きているか死んでいるかでこれがfalseになるとコンテナをdeleteする、readinessはそのコンテナが受付可能かどうかでserviceから切り離すかどうかを示す、であっているかなあ。

この動作が特に重要となるのはゼロダウンタイムアップグレードの場合です(詳細については13章の「13.2 デプロイ戦略」を参照)。

参照先をみてもreadinessのことが書かれていない。たぶんデプロイ戦略中の切り替えの判断にreadinessを使っているということだろうと思うのだけど。

P88

デフォルトのNamespaceは、間違いを起こしやすいため使用してはなりません。

そうなのか。

Kubernetesのベストプラクティス：名前空間を使用した整理| Google Cloudブログ

たしかにこちらにもそう書いてある。

P88

Serviceのアドレス

なるほど、Serviceだけ？がNamespaceの壁を超えられるのか。 カプセル化、というかインターフェイスはtcpに限定しているkubernetesの思想的には一貫している。

P89

ポッドの実行数のハードリミット。ただこれだと問答無用でエラーが発生するのでポッド実行のスロットリング目的としては不適か？ いやでもjob経由ならキューに積まれそう。

P92

ほとんどのマネージドKuberentesサービスには、コンテナのCPUおよびメモリ仕様状況を時間の経過に沿って表示する、何らかのダッシュボード機能が用意されています。

みてるかー、AWS EKSチーム見てるかー！！！

P93

Vritical Pod Autoscaler リソース要求の理想的な値を算出するのに役立つ。

単なるオートスケーリングだけじゃなくて実際にリソースを監視してリソースの最適なlimitを決めるのに使えるのか。便利。

P94

優れた経験則として、ノードは典型的なPodを少なくとも5つは実行するのに十分なサイズとする

fmfm

P97

kube-job-cleaner

なるほど、これは便利。

P98

Spot Instanceの利用

これ魅力的なのはわかるけどこれを使う設定がわからない。

[EKS] [request]: Spot instances for managed node groups · Issue #583 · aws/containers-roadmap

Managed Node Groupでもサポートされていないし、これを使うとなるとアンマネージドになるのが辛い。

P102

Descheduler

ポッドの偏りを解消するコントローラ

P109

ベストプラクティスでのシングルテナントの推奨

これには賛成しかねる。 マルチテナントとシングルテナント, kubernetesで検索して出てくるスライド資料参照

P111

ベアメタルサーバ

どっかで聞いたような話だ。

P117

Copper, manifestのlinter

これはCIへ組み込むと良さそう。

P 128

kubectlの--watchコマンド

これ知らずにwhile sleepでループさせてた。参考にしよう。

P129

本書ではずっと、コードとしての宣言的インフラを使用する重要性を強調してきました。そのため、「命令的なkubectlコマンドの使用は推奨しない」という主張が驚かれることはないでしょう。

なるほど。たしかにcreateやdeleteはローカル環境でやる時以外は控えたほうが良いかも。

P134

コンテナへのアタッチ

用途がよくわからない。dockerなどと一緒だとしたら標準入力などを与える場合はこれが必要？

kubespy

リソースの変更を監視できるツール。 kubectl get --watch もよいがこれも便利そう。 ただkubernetesの手頃なdashboardがあれば不要？

P136

kubernetesクラスタのトラブルシューティング(主にネットワークなど)のための便利コマンド

kubectl run nslookup --image=busybox:1.28 --rm -it --restart=Never --command -- nslookup demo

P140

コンテキストはクラスタ、ユーザー、ネームスペースの組み合わせのこと

P155

本番環境でコンテナをデプロイするときは、latestタグの使用を避けるべきです。実行中のイメージのバージョンを把握することが難しく、また適切なロールバックが困難になるためです。

ああ、よく知ってる。

P163前後

ポッドのセキュリティ。非常に面倒くさいことだけはよくわかった。

P166

永続化ボリューム

そういえばeksでefsって使えるのかなと思って調べてみたら、この永続ボリュームの機能で使えるっぽい。

P175

Labelは内部的にも酷使されるためかなり厳しい制限がある。 具体的にはlabel名は63文字まで、ただしdnsサブドメイン形式での最大256文字までのprefixが認められる。 prefixとlabel名本体は/で区切られう。 labelの名前と値に使える文字は-_.alphanumのみ。

P176

こうした Affinity にはハードとソフトの 2 種類があります。残念ながらソフトウェアエンジニア は必ずしも命名の才に恵まれているわけではないため、 Kubernetes の場合、これらは次のように 呼ばれています。

● requiredDuringSchedulingIgnoredDuringExecution (ハード)

● preferredDuringSchedulingIgnoredDuringExecution (ソフト)

草

P184

StatefulSet

名前に反してDeploymentの各Podへindexがついただけのような微妙なリソースタイプ。

StatefulSet では、 PersistentVolumeClaim を自動的に作成する VolumeClaimTemplates を使用 して、紐づく一連の Pod のディスクストレージも管理できます

と思ったらやっぱり永続化に関する機能というかデフォルトの振る舞いもあるっぽい。

P186

CronJob マ ニ フ ェ ス ト で 注 目 す べ き 重 要 な フ ィ ー ル ド は 、 spec.schedule と spec.job Template の 2 つです。 schedule フィールドはジョブが実行されるタイミングを指定するも ので、 Unix の cron ユーティリティと同じ形式( https://en.wikipedia.org/wiki/Cron )を使用し ます † 4 。

本書く人ですらWikipediaを参照する程度にcronのフォーマットの仕様はwebに明記されていないんよな。 man結果を安定的にホスティングするセミオフィシャルなサイトとかあったらいいんだけど。

P190

監訳注: 2016 年に Operator を提唱した CoreOS 社(現在は IBM 社の一部)は、ブログ( https://coreos.com/blog/introd ucing-operators.html )で Operator を「アプリケーション固有の運用ナレッジがプログラミングされたカスタムコントロー ラ」と言っています。そのため、このサンプルは Operator ではなく Kubernetes コントローラと呼ぶほうが一般的かもしれ ません。

P192

証明書ってIngressで設定できたんだへーと思ったら

tls.secretNameからACMに証明書をインポート・問題＃1084・kubernetes-sigs / aws-alb-ingress-controller

ACMでもできるようになりつつあるらしい。 これでalb-ingress-controllerがちゃんと取り込まれたらAWSでもKubernetesとクラウドサービスの結合度はかなり高くなるなあ

P204

envFromを使用することで、COnfigMapからすべてのキーを取り込んで環境変数に変換するための簡単な方法が用意されています。

これは便利。

P205

configMapからコンテナ上のファイルへそのまま書き出す方法が書かれている

P215

SOPS

現状parameter storeとexternal-secretsで同期しているから不要？ でもhelm-secretsを使う利点もあるかもしれない。

SOPS、読み進めるとこれ12 factors appに反しているな。 あとterraformからのパラメータの引き渡しも難しい。やっぱりSOPSは微妙な気がする。

P222

マルチテナントについて これはたしかに最も安全なアプローチですが、クラスタを追加していくことにはトレードオフもあしります。どのクラスタもパッチ適用や監視の対象とする必要があり、多数の小さなクラスタは少数の大きなクラスタに比べて実行効率が劣る傾向もあります。

うん。だからterraformのmoduleを使用してなるべく一つのアプローチで一気に管理できるようにしようとしている。

P223

viewロール

これいいね。readonlyロール

P249

values.yaml

なるほど、これがあればhelm-install.shはもっとよく書けそう。

P255

helmfile

これ、argo cdと競合するので使うべきか悩む。

P257

ksonnetの最も重要な点は、プロトタイプという概念を導入していることです。これは Kubernetes リソースのあらかじめ記述された組み合わせで、よく使われるマニフェストのパ ターンを、スタンプで押すように手軽に利用できるようになります。

これは魅力的。

P 260

kubeval

これ読む限り、こいつがやってくれるvalidationはkubectlがやってくれるものと完全に等価？ ユーザーグラウンドでこのプロパティの値はこの範囲、のような指定はできないのかも。 そういうのはconftestか。

P263

13章開発ワークフローはローカル環境で高速に開発サイクルを回したいときのツールらしい。 なかなか難しいトピックになってきた。

Draft, Skaffold, Telepresence

この辺り、部内でk8sを広めていくためには必要になってくるかー。

P269

BGデプロイをlabelでする

これをなんらかのツールなどで支援できないとなかなかつらい。オペミス発生しそう。

カナリアデプロイにはIstioが必要

P270

Helmのフック機能

これいいなー。

P276

14.2 おすすめのCDツール

weave fluxもargo cdも書かれていない？ 時期が2年近く前であることを考えると必然か？

P279

と思ったらfluxはこっちにあった。

P294

ユーザがハッピーでなければ 9 の数に意味はありません。 ―― Charity Majors ( https://red.ht/2FMZcMZ )

いい言葉だ。

15章、16章は流してしまった。 また興味が湧いたら読み直す。

すぐやること

  • インスタンスサイズは4つより2つのほうが良さげ
  • defaultのネームスペースは危険なので使わない
  • Copper - manifestのlinter
  • envFromで変数の羅列をやめる
  • deschedulerは大定番っぽいので基本入れる
  • conftest, kubevalは基本入れる(これはkubernetes meetup #29から)
  • 管理者以外にviewロールで権限を付与する
  • velero - これもmeetup #29からでもあるけど、とりあえずsnapshotを取っておくだけでもかなり有用

「OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法」感想

技術書感想

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法 | クリスティーナ・ウォドキー, 及川 卓也(解説), 二木 夢子 |本 | 通販 | Amazon

死ぬほどひどいタイトルにドン引きしてこれがおおよそcannonicalな本であることはわかっていたにも関わらず別の本に逃げていた。

今、どんなタイトルからこんなひどいタイトルの本にしてしまったのか原書を調べていたのだけど原書のタイトルは大きく違った。

Amazon.com: Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results ( OKRs ) eBook: Christina Wodtke: Kindle Store

Radical Focus, 徹底的な集中。たしかにこのほうがこの本で言いたいことの本質を捉えている気がする。 これにOKRとタイトルを付けるのはわかりやすいかもしれないけどまさに目的より手段を優先することを冗長していないだろうか。

閑話休題、結論から言うとけして悪くはないと思う。 序盤の小説仕立てのところは触りとしては悪くない。 もうちょっと間間に挟んでくれるともっと読みやすかった気もするが、そこまでするほどでもない気はする。

後半を非常に駆け足で読んだのでそこは再度読み直したほうがよいかも。

あと、このOKRをボトムアップでやるのはあんまり有効ではないなと思った。 この中で説明されているように基本的にOKRはトップダウンだと思うので1チームで導入しようとしてもひとつ上の枠組みで目指すものとの整合性が取りにくい。 もしひとつ上の枠組みでOKRではなくMVVのようなものが設定されている場合、MVVからOKRへ落とすような工夫が必要になると思う。

4セルでキープする項目を書くのは良いと思った。 OKRやKPIで、じゃあ目標だけおっていればいいのか、他のことは後回しでいいのかっていう話に良くなったので。

bastionを廃してRDSのパブリックアクセス可能(publicly accessible)を有効にしてはどうか提言

AWS

tl;dr

  • Site to Site VPN, Direct Connect, Client VPNなどでオフィスネットワークとVPCがつながっていない前提
  • 従来Bastionインスタンスをおいていたがモダンな設計ではもはやRDS以外で使われない
  • publicly accessibleがtrueでもセキュリティを担保しやすくなっておりメリットも多いのでそうしたらどうだろうか

BastionがもはやEC2インスタンス用でいらない背景

elpy1/ssh-over-ssmやEC2 instance connect, そもそもECSやEKSの場合は個別のノードへログインする必要性がない、などの背景でモダンなAWSアーキテクチャではEC2インスタンスへのログインのためにbastionはほぼほぼ不要になりつつある。

bastionを使うとbastionに秘密鍵をおいてしまったり退職者のユーザーアカウントがなかなか削除されなかったりいつの間にかそこからデプロイされるようになる = immutableではなくなり作り直しができなくなる、などの問題があるためむしろ積極的に避けたい。

public accessibleをtrueにする利点

  • メリット
    • 設計がシンプル
      • RDSを知っている人なら誰でも接続方法がわかる
      • 部署やシステムごとに接続方法が変わったりしない
        • 接続方法のドキュメントをメンテナンスしたりその場所を考慮したりする必要がない
    • 余計な経路がないので可用性が高まる
      • bastionの可用性を担保しようとすると冗長化などでかなり構成が複雑になる
    • bastionで余計なコストが掛からない
    • mysqlクライアントから接続するときにssh port forwardingなどの設定が不要
      • 設定が難解で動作確認も難しいので非エンジニアにもやってもらうのがキビシイ
    • ssh port forwardingやbastionサーバをサポートしていないmysqlクライアントでも接続可能

publicly accessibleを有効にするリスクは幽霊では？

RDSでpublicly accessibleがtrueであることがセキュリティリスクである、ということはAWSを使う者にとってある程度の共通認識である。 しかし、これがどうにも疑わしい。 bastionを経由しようが結局public IPアドレスが振られるのがRDSインスタンスからbastionへ変わっただけで実態的なセキュリティリスクは減っていない。 確かにMySQLなどはプロトコルがセキュアでなかったりsshより比較的簡単なIDパスワードが使われる傾向がある。しかしIAMデータベース認証ではセキュアプロトコルが強制されるしセキュリティグループなどで接続元を絞れば十分安全である。またパスワードはそもそも十分セキュアな文字列にするべきだ。

これは個人的な推測なのだがどうにもpublicly accessible有効が危険だという認識は極めてずさんな設定のRDSへ攻撃された事例や話から生まれている気がする。実際の事例を聞くと安易にpublicly accessibleを有効にしたRDSインスタンスでsecureでないrootアカウントを設定してrootアカウントのユーザー名も"root"のままにしていたような、そのような話しかない。 確かにpublicly accessibleをfalseにすれば攻撃の難易度は上がるがDBインスタンスへのアクセシビリティを犠牲にしているので一概にやるべきとは思えない。

上記を踏まえてのpublicly accessible: trueでのおすすめ設定

  • (must) publicly accessibleをtrueにする
  • (must) セキュリティグループでingressをオフィスゲートウェイ(+ VPC)に絞る
  • (must) アプリケーション用パスワードは十分セキュアな文字列にする(パスワードジェネレータなど推奨)
  • (must) インターネットを経由する接続には必ずSSLプロトコルを利用する
  • (should) 開発者の接続はIAM データベース認証 - Amazon Auroraを使う
    • 必然的にプロトコルもSSLになるためインターネット経由の接続でも通信内容が漏れる心配がない
  • (may) 接続ポートをデフォルトから変える1
    • 安易な攻撃からの防御手段になるがポートスキャンなどで無意味化される。本質的な対策ではないかも。

残タスク

publicly accessibleを有効にした場合、果たしてもはやprivate subnetは必要なのかという疑問が湧いてくる。 現段階ではもはや必要ない気がする2。ここについては追加調査が必要。

2020/06/19 追記

AWSのサポートに本件について問い合わせたところ、Publicly AccessibleのON/OFFとセキュリティについてはどちらとも言えないという返答が返ってきた。 Publicly AccessibleをONにしてもSecurity Groupなどを使えばセキュアにできるし、 Publicly AccessibleをOFFにしても踏み台サーバのセキュリティが弱かったりすればRDSへ侵入される危険があると。 道理だ。

  1. 変える場合は変更先のポート番号などに特にコンベンションなどなさそうなので(TCPやUDPにおけるポート番号の一覧 - Wikipedia)雑だが1万番代のポート番号からランダムで選択などでいいと思う。特にRDSは独立したインスタンスなのでポート番号がかぶる心配はない↩

  2. GCPとかそもそもVPC概念薄いが運用上問題になる話はほぼない。あっても既存の運用を変えずにGCPへ持っていきたいというケースしか聞かない↩

【WIP】slackでイケてないと感じる点リスト

駄文
  • スレッドが使いづらい
    • 本来threadとチャンネルはよく似た概念としてよく似た使い方をできるべきなのに設計が微妙でほぼ同じスレッドとチャンネルがまったく別の機能として実装され、その結果ぎこちなくなっている。最たるものは右のパネルで開かれるスレッドと、チャンネルにも投稿されるというチェックボックス。およびスレッドへのサブスクライブ。
  • 複数のチャンネルやスレッドを同時に開きたいのにできない
  • チャンネルへの入退室がログに残る
    • 設定から非表示にできるがデフォルト非表示でいい
  • 各種改善の速度が遅い
    • 予約投稿がAPI的には実装されたのに半年以上UIが用意されない
  • 議論がググれない
  • 内容をpublic webに公開できない
  • エセmarkdown
    • そのWYSIWYGが壊れている(特に日本語入力が絡むと)
  • TBL

「本気でゴールを達成したい人とチームのための OKR」感想

技術書感想

OKR本がいくつか選択肢がある中で一旦読みやすいものをと思って日本人が書いた本を手に取った。

最初の方の筆者の個人的な経験が冗長かつ根拠のない説教を聞かされている感じで辛い。 うざい上司に仕事論を聞かされている感じでなるほどtraditional japanese companyではこういったことを飲み会で聞かされるんだろうなと思って飲み会参加したくない感が高まる。

後半は具体的なOKRの運用や概念に近づくのでだいぶマシになったが、おまそうかもしれないので改めて別の本を読んで裏取りしたほうが良さそう。

結論: 最初からcanonicalなOKR本を読んだらよかった。

「階層脳」を使って自分の改造構造・タグについての考えを整理してみる

ポエム

きっかけ

以前から僕は階層不要説に懐疑的だったのだけど、ふとそのことについてつぶやいたらscrapboxの開発者の人がそれに反応してくれた。 いい機会なので記事分類手法における階層について僕が思っていることを書く。

階層脳に対する反論

scrapbox.io

この記事は反階層主張の中でもかなり有名だと思うのだけど(かつ上記の反応してくれた人の記事でもある)、 ちょうどいいのでこれを題材にして僕の考えを浮かび上がらせようと思う。

以下上記記事中のトピックとそれに対する僕の意見を書く。

階層的管理の失敗

たいてい途中で破綻する

大筋同意だけども、僕が見た破綻は以下の2パターンでどちらも階層構造固有とは言い難かった。

  1. 新たなコミュニティの参加者が階層構造を把握せずroot直下でページを作ってしまう
    • scrapboxでもリンクを貼らなかったりすでにあるハッシュタグを使わずページを作ると結局同じ
    • つまるところオンボーディングの問題
  2. 階層構造を変更したい人間が従来と異なる階層ルールを導入して新旧ルールが入り混じり、その結果ルールが崩壊する
    • きちんとコンセンサスを取らないことが原因
    • また階層構造変更の提案が通りにくい遠因として構造を変更するとリンク切れを起こしたり、そもそもページの移動が手作業で大変だったりするシステム側の問題がある
      • 後述のようにページへのパーマリンクを階層構造とは切り離しておけばパーマリンクは死なないし、REST APIなどでページを移動できるようにしておけば階層構造変更もそれほど高コストではなくなる1

タグづけ機能を追加する

タグ付けについては僕も階層構造と同時に実装するのは微妙だと思う。タグも階層構造もどちらも記事の分類目的なのだからどちらかにするか、あるいはタグ自体に階層構造をもたせるのがよいかもしれない( lang/java や system-alpha/post-mortem などのイメージ)

Symbolic Linkのようなリンクを付加する

おそらくページを階層構造上の2箇所以上へ擬似的に置きたいという意図だと思うが、いっそhard linkにして普通に2箇所におけるようにすれば良いと思う。パーマリンクを階層構造と無関係にすれば実現は難しくない。

しかし既にある階層同士の参照を壊すわけにはいかないので、階層構造は維持される

ここはコンテキストが省略されすぎていてちょっとわからなかった

うまくいく場合

 誰もが納得する簡単な階層構造があるときは大丈夫かも
  日付
  音楽データ
   アーティスト/アルバム/曲名
 最初に階層構造を決めないとうまくいかない
  構造が綺麗に決まっていると、新参者でもデータを追加しやすい

この辺でこれを書いた人はそのページのカテゴライズ・階層構造上の位置が書いた瞬間に絶対的に決まるイメージを持っていることに気づく。それは確かにしんどい構造なので継続的に階層構造を保守していくイメージを持てばいいんじゃないかなと思う。

うまくいかない理由

 複数の属性をもつものをどこに置けば良いかわからない
  aka [こうもり問題]
  こうもりは動物か鳥か分類し辛い
  特に複数人で書いているwikiでは判断が分かれて、ケンカの元になる
 階層的に分類するのは疲れる
 階層構造の変更が大変
  最初に決めた階層は大抵見通しが甘いのに

複数の属性を持つケースは階層構造上の複数の位置への配置を許容してしまえばいい(前述のハードリンク)。 階層構造の変更が大変な点はサービス・システム側で補助してやればいい(前述)。

何故階層脳になるか

ここに関してはおまそう要素が強すぎるので省略。

階層脳脱出するには

 Webと似たようなものだと言えばどうか
  無階層でも検索できれば良いと思う
  「Yahoo JPのトップページ使わないでしょ？」
 Gyazz的なものの有用さをじわじわ浸透させる
 複数人でのwiki運用では階層分類に困るものが頻出する
  例
   [カレーうどん]
   プロダクトAとプロダクトBの連携機能についてのユーザーサポートページ
    どの階層に入れる？ユーザーサポート or A or B
　　厳格なルールを決めないと、分類できない
   そのルールは全員が覚えられない
   間違った場所に保存すると怒られるから、wikiを書けなくなる
  ガチガチの運用ルールで縛らないと普通のwikiは使えない

普通にページを階層構造上の2箇所以上へおけば良さそう。 またその情報共有サービスの全記事に対して同一のルールを強制するのではなく、その中を縦に区切ってそれぞれの中で分割統治する方式はどうか(イメージとしては部署ごとにその中が整理されている感じ)

書いていて自分のイメージするタグ/階層構造の仕組みがだいぶイメージできてきたので後日文書化する。

  1. 過去これを達成するためにredmine wikiの階層構造を簡単に整理するためこういうものを作ったりしていたのを思い出した bigwheel/rmwikifs↩