前節でdiffとpatch、そしてGitについて学びました。いつ、何を変更したかをいつでも確認できて、やりかけている修正をいつでも巻き戻せるのは非常に強力なツールです。個人で使っていても強力ですし、チームで使うと「え、これ誰が変えたの？」とか「私が入れた修正を消しちゃったの誰？」みたいなトラブルを防げるのはなにものにも変えがたい魅力です。
ところが、この恩恵を被れるのはテキストファイルだけです。Gitにバイナリーファイル、例えばパワーポイントの資料や画像ファイルを保存して管理することは出来ますが、diffを取ることは出来ません。
そこで、チームで作成する文書はすべてテキストファイルで保存することにするのが良いでしょう。
例えば、プログラム中にがっつりそのプログラムの説明を書きたいことがあります。プログラム言語には、ソースコード中にコメントを書く機能がありますが、そのコメントの形で後でこのプログラムを読む人向けに、そこそこ長い文章で説明を書こうと。当然、見出しを書いたり、箇条書きしたり、説明のためにコードを引用したりしたくなります。また、このコメントを抜き出して、後でプログラムの仕様書として利用すれば良いじゃないかと、みんな思います。なので、そのような埋め込みドキュメントの整形ツールが作られました。
あるいは、Webが一般的になってくると自分の日記をWeb上で公開したいという人が現れました。Webで公開するんだから最終的にはHTMLになるんですが、日記のような毎日書く文書をHTMLで書くのは面倒くさい。なので、テキストでそれっぽく書くと、HTMLにして公開してくれるツールをいろんな人が作りました。後にこのようにWeb上で簡単に文章を書いてそれを公開できるツールは”Web log”を略してblog(ブログ)ツールと呼ばれるようになります。
さらに、Web上の情報をみんなで更新し合う仕組みというのも作られました。最初は誰かとりまとめの人のところに情報を送ったり、それこそ修正をpatchにして送ったりしていましたが、「みんなで編集できたらいいじゃない」ということで、複数の人がひとつの文章を更新出来るWikiWikiWebというサイトとそれを実現するツールが作られました。当然、誰がどんな変更を入れたのかがわかるようにする必要がありますから、diffが内部で使われていますし、文章はあるルールに従ったテキストフォーマットで書く必要があります。ちなみに、このWikiWikiWebに触発され、いろんなWikiツールが作られ、「Wikiツールでみんなで百科事典作ったら凄くね？」というようなことを思いつく人まで現れました。はい、Wikipediaのことです。
このように「あるフォーマットに従ったテキストファイルを書くと、それがHTMLに変換される」ツールは、いろんなところで同時多発的に開発されました。もちろん、ツールを作っている人達はお互いのことをある程度は知っていましたが、いろいろな事情で「あっちでは箇条書きに”*“を使っているけど、うちは”-“でやろう」「あっちでは見出しを”#”で表しているけど、うちは”#”は別の意味で使っちゃっているから”=”でやろう」というようなことが起こり、似たような目的のためにいろいろなフォーマットが生まれました。
Web日記ツールや、blogツールもみんなが競って作りました。ツールごとにフォーマットのルールはちょっとずつ違っていました。Wikiツールもみんなが競って作りました。ツールごとにフォーマットのルールがちょっとずつ違っていました。
これらは最終的にHTMLに変換されることが多かったので、HTMLより簡単なマークアップ言語という意味で、「簡易マークアップ言語」とか「軽量マークアップ言語」と呼ばれます。Wikipediaの「軽量マークアップ言語」のページには、ざっと20種類の軽量マークアップ言語のリストが出ていますが、たぶん、もっともっとたくさん作られたはずです。
みんなうんざりしました。
どれかひとつのツールがデファクトスタンダードになればそのフォーマットに収束していったのでしょうが、なんせ埋め込みドキュメントとブログとWikiを統一するツールがライバルを蹴散らしてフォーマットを統一する・・・というのは考えづらく、長く「いろんな書き方がある」状態が続きました。
しかし、最終的にはMarkdown(Markup LanguageにMarkdownなんて名前をつけるのはちょっと洒落ています)というあるフォーマットに、徐々にみんなが対応してまとまっていきました。Markdownはジョン・グルーバーというアメリカで一番有名な技術系のブロガー、ポッドキャスターが提案したものなのですが、正直、その作者の知名度で流行ったのかどうかも、よくわかりません。このような経緯なので、Markdownの書式は例えば「箇条書きを書くには”*“でも、”+”でも、”-“でもOK」のように過去のフォーマットをまとめたようなルールになっていますし、それでもMarkdownの方言もいろいろあります。ただ、とりあえずはみんなが「Markdownってだいたいこんなの」という相互理解がある状態になっていますし、GitHubを多くの開発者が使うようになったので、「GitHubが処理してくれるMarkdownを書いておけばいいだろう」ということになりました。
1次資料という意味では、グルーバーのサイトである“DARING FIREBALL”なのかもしれませんが、これをMarkdownの仕様だと思っている人はほぼいないと思います。なんせ、2004年が最後の更新ですから。
MarkdownのRFCもありますが、今、Markdownを学習する人が安心して参照できるのはGitHubです。GitHub Docの「基本的な書き方とフォーマットの構文」を参考にして下さい。というのも、皆さんにはGitHubで開発日誌をつけてもらうつもりだからです。この記事の「人やTeamのメンション」や「Issueおよびプルリクエストの参照」など一部のセクションはなんのことやらわからないかもしれないです。読み飛ばしてください。
Markdownの書き方について学習するときに知っておくことは、「歴史的経緯がいろいろあり、勝手な拡張をされていることも多いので、ツールごとに微妙にルールが違ったり、書き方を紹介しているサイトごとに言ってることが違ったりするけど、気にしない。自分が使っているツールで上手く動くかどうかが大事」ということです。あまり厳密な決まりはないんだな、ぐらいに思ってもらってOKです。
GitHubには決まったディレクトリにMarkdownで記述されたファイルを置いておくと、それをWebから見えるようにしてくれる機能があります。GitHub Pagesと言います。
説明はGitHub Pages サイトの公開元を設定するにあるのですが、最近、いろんな機能が増えたので正直言ってとても読みづらくなりました。
最小のGitHub Pagesの設定は以下です
公開するMarkdownファイルを入れるブランチを決める。私たちはまだブランチについて何も学んでいないので、デフォルトのブランチであるmainを選べば良い
公開するMarkdownファイルを入れるディレクトリを決める。ルートディレクトリ(一番上のディレクトリ)か、docsディレクトリのどちらかを選べるので、docsを選ぶ
ただ、この2つだけです。後はdocsディレクトリにindex.mdファイルを作れば、index.htmlが作られて、指定のディレクトリにアクセスするとその内容が表示されます。万事OKです。
今後、本書を読みながらやっていく作業はGitで管理をし、コミットログも書いていきますが、何をやったのかの具体的な内容は日誌としてこのディレクトリにMarkdownで書いていってください。作業日誌を付けることは技術者としての基本です。今後、プロジェクト活動の中でも必ず書いていくようにして下さい。