「みんなの翻訳」は、世界中の文書をみんなで協力して翻訳するサイトです。

みんなの翻訳ロゴ
ブクタブ
翻訳サイト

カテゴリ一覧

このサイトについて 新規登録はこちら お試し翻訳

一覧

2017/07/28

メンテナンス終了のお知らせ

2017/7/25-2017/7/28に実施したメンテナンスは、2017/7/28/14:20に終了いたしました。 ご協力をいただき、ありが…

List

Hnoss

English⇒Japanese

shikimi

English⇒Japanese

sysInfo

English⇒Japanese

tkkobe

English⇒Japanese

ホーム > 翻訳記事

翻訳記事

Hugo vs. Jekyll | 静的サイトを作るのに向いているプラットフォームはどっちだ | from Opensource.com / Jason van Gumster

  もし、みなさんに新しくウェブサイトを作る予定があるのなら、プラットフォームに静的サイトジェネレータを選択しておいて間違いないでしょう。

  2017年5月18日 | Jason van Gumster
 

  例えば、エミリー・ディキンソン(訳者によるリンク)みたいに、生涯のうちにその名を知られることがない芸術家を本気で目指している人ならともかく、自分で作ったものがあったなら、それを公開して、あまり大人数でなくても世間の誰かとは共有したいものですよね。

 今は便利なもんで、ウェブサイトを使って公開することなら簡単にできますよ。
 もちろん、ここでいうウェブサイトには、ソーシャルメディア・サイトも含まれます。そこでたくさんの観衆の前であなたの作品を公開できる。作品を発表することを目的としたソーシャルメディアも、Flickr、SoundCloud、Wattpadなど、ほとんど選び放題という状態です。
 (日本でいうなら、pixiv、ニコ動、魔法のiらんど、みたいなとこか?)
 

  自分の作品を世に広めたいなら、そういうサイトを使った方がいいのは確かです。けっきょく、観客がいるのはそのへんですからね。

 しかし、本当にそういうサイトが全ての創作家に合うかっていったら、そうでもありません。
 移り変わりが激しくて、あまりあてにもならない観衆たちに神経をすりへらしたりとか、創作の目的がどんどんおかしくなっていく人もいますよ。ソーシャルのそういうところはよくない。創作行為と相性のよくない部分があるんです。

 あくまで、ソーシャルメディアは宣伝と割り切って、あるていど他人が手出しできない自己管理型のホームベースを用意しておいたほうが、創作に集中できるんだと思います。
 

  コントロールができる。それが、そもそものウェブの持ち味であり、醍醐味でしょ。
 

  でも、今回ここでお話しするのは、独自ドメインを獲得して自分のウェブサイトを作る方法とかではありません。そのあと、実際どのようにしてサイトを作るかという部分です。

 たとえば、こういう時に、いちばんよく聞く選択肢で、もちろんたくさんの人が選んでいるのはWordPressです。
たいていのプロバイダでインストールできて、その手間もワンクリックです。並外れて大きいプラグインやテーマのマーケットから、あなたがビルドしてみたいデザインを選ぶことができます。

 しかし、WordPressには、ほとんどのウェブサイトに必要のない機能まで入っています。それのおかげで、ウェブサイトに数々の動的な要素を取り付けられるけど、
 それらにアップデートをかけるなど、ぜんぶにきちんとメンテナンスをしなければ、セキュリティリスクがはね上がるのも事実です。サイトがハイジャックされる可能性があります。

 

  もう1つ、静的ウェブサイトを作るという選択肢があります。サーバーサイドに動的な要素を入れていないので、より安全で管理が楽です。
 物凄く多機能ではないというマイナス面はありますが、作品を掲載する目的で使うなら、機能としては十分です。

 HTMLとCSS(あとは少しのJavaScript)という、昔ながらの言語を使って、自分でサイトの材料をだいたい把握しながらサイトを運営できるというメリットがあります。
 もちろん、低レベルな部分から学ばなくてはいけないわけではありません。そのあたりを処理してくれるのが、静的サイト・ジェネレータというソフトです。
 

  素早く安全性の高い静的HTMLページを、動的サイトと同じくらい便利なワークフローで作成できます。クロスブラウザ対応だって簡単にできるんです。
 この静的サイト・ジェネレータの代表的なもの2つが、 HugoJekyll です。
 (ちなみに、あのPaolo Bonziniは記事を発表するのに、Jekyllを使っていたそうです。)

 でも、どちらを選べばよいのでしょう。この記事では、その2つの違いを大まかに説明します。基本的な使い方や使えるテーマ、編集の方法、どこを拡張できるかなど、選択する上での参考にしてください。

 

  基本的な使い方

  これにおいては、どちらも同じような方法です。
 コマンドラインでの操作だから。ですが、そこで使うコマンドも決して難しいものではありません。むしろ、適宜調整ができる可能性があります。クリックだけで操作できるインターフェイスではありませんが。

  JekyllもHugoもインストールの方法はいたってシンプルです。
 JekyllはインストールにRubyGemsを使います。
 Hugoは必要なバイナリが全てひとまとめになっているので開始が速い。シングル・インストール・パッケージというのですが、これといった設定が必要ありません。

 それに比べてRubyGemsを使用する方法は、インストールする前にコンピューターのRuby環境を設定する必要があります。よほど改良を加えたフォーク版でもないかぎりは、Rubyの設定が必要です。

 なので、インストールしやすさはJekyllの方に少し軍配が上がります。
 

  一度インストールしてしまえば、使い方においては両方とも同じくらい簡単です。どちらも丁寧な使用説明書と、クイックスタートガイドがあります。

 たとえば、新しいサイトを開始する操作は、
 Jekyllの場合、jekyll new <your_site>
 Hugoの場合、hugo new site <your_site>
 というコマンドで可能です。

 次にディレクトリ構造を設定します。そのディレクトリ構造もどちらも同じような状態です。
 Jekyllの場合、 _config.ymlファイルで、
 Hugoの場合、config.toml ファイルにディレクトリの設定が記述されています。
 (config.tomlファイルには、YAMLやJSONシンタックスを適用させることができます。人によってはこれが便利です。)

 メタデータは、どちらもコンテンツファイルの先頭に挿入することができ、コンテンツファイルに同じシンタックスを設定することができます。そして、どちらもコンテンツはマークダウンで記述可能です。
 

  それから、サイトを開始したときの様子には、双方に違いがあります。
 初心者に優しいと言えるのは、Jekyllのほうです。なぜなら、スタート時点でベーシックコンテンツやデフォルトのテーマが用意されているからです。そのデフォルトのテンプレートやテーマを使って、そのままサイトを構築してしまうこともできます。

 それに対して、Hugoにはベーシックコンテンツやデフォルトのテーマなどが用意されていません。デフォルトのテーマがついてきても、変更などで削除してしまう予定の人なら、これでよいのかもしれません。


 

  テーマ

  前述のとおり、Hugoにはデフォルトのテーマが存在しません。まず最初にどのテーマを使用するかの設定が必要です。
 Jekyllの場合はデフォルトのテーマが用意されていますが、あまりにもそっけないデザインなので、用件を満たせるかどうかがわかりません。これはこれで他のテーマを探しにJekyllサイトを見て回ることになるでしょう。
 

  HugoもJekyllも、シングルページテーマから、ブログポストやコメント欄を設けたサイトまで、いろいろな種類のテーマを用意しています。
 しかし、どちらもきちんと自分に合ったテーマが見つかりづらい。

 たとえば、Hugoの場合はというthemes.gohugo.ioサイト、
 Jekyllの場合はjekyllthemes.orgというサイトに行けば、探すことは可能です。
 双方、テーマのスクリーンショットを見ることができ、クリックすれば詳しい情報が表示されます。ただ、どっちも情報が雑。

 しいていうなら、Hugoの方がテーマに大まかなタグ付けがされていて、幾分かはどのような用途のテーマなのかが分かりやすくなっています。
 

  テーマ管理は気になる審査ポイントですよね。

 両方とも、ほとんどのテーマがGitレポジトリ形式で(なおかつGitHubに公開されていて)、ウェブサイトで使う時にはそのコピーを組み込みます。
 Jekyllの場合は、テーマを組み込むときにRubyGemsのバンドルが必要です。バンドルを用意しておくことで、テーマの中にGemfileがなかったとしても、ウェブサイトに問題なく適用させることができます。
 Hugoには、バンドルを設定する工程がありません。config.tomlに設定を反映させるだけでテーマを変えられるので、この辺はHugoのほうが手軽といえます。
 

  あくまで筆者の独断ですが、テーマの扱いについてはHugoのほうが便利だと思います。
 GitHubからコピー(クローン)したか、あるいは自分で改造したテーマを、これから使うテーマの候補にして「テーマ・サブディレクトリ」というスペースに入れておきます。
 そしたら、それらを度々切り替えてどちらが便利かを見比べることができます。
 最初はそうやって、自分に合うテーマを見つければよいのではないかと思うんです。

 実は、オリジナルのテーマを使い続けなくてはならないこともないんです。そこらの人が自分のために作ったものを公開していることもあって、そんなものも参考にしながら、自分に合ったものにカスタマイズしていけばよいのです。
 また、公開されていなかったとしても、「これは」と感じたテーマを作った人に連絡を取って、ディストリビューションを願い出るのも、勿論可能です。


 

  ワークフロー

  サイトをビルドする手間に関しては、一度設定をすればそれらが自動で適用されるので、どちらも同じような感じです。

 どちらのツールも軽量ですから、作成したサイトのチェックはローカル環境でできます。わざわざプレヴューのためにアップロードする必要がないのはうれしいですね。
 また、双方デフォルトや一度した設定を変更できるところが、本当に素晴らしい。

 ローカルに保存していたサイトをブラウザで見た瞬間に、すべての変更を自動的にアップロードするという機能もあります。この機能を使うと、コンテンツの更新から、設定、テーマ、画像などの変更も反映されるので便利です。実に時間の短縮になります。

 

  どちらのツールもコンテンツの記述には、 Markdownシンタックスが使えます。Markdownて何?って方もすぐに感覚的に覚えられるような言語なので、ぜひ挑戦してみてください。書きやすく、後から読みやすい原稿ができるはずです。プレーンテキストとして処理されるので、バージョン管理も簡単です。私もネットで何か文章を書くときには、ほとんどこれを使用しています。
 

  新しいコンテンツを追加する時には、手動で正しい場所を選んでファイルを作れば大丈夫です。ただ、原稿にMarkdownを使う場合には、ファイルの先頭にある「front matter(前づけ)」メタデータにMarkdownであることを記述する必要があります。

 その前づけの設定ファイルには、
  Jekyllの場合、YAMLシンタックスが、
 Hugoの場合、TOML(デフォルト)とYAML、JSONが使えます。

 Jekyllなら「 _drafts(下書き)」ディレクトリと「_posts (投稿)」ディレクトリとが分かれていて、途中の原稿も正しく保管することができます。
 Hugoにおいては、「content」ディレクトリが1つあるだけで、コンテンツを出すか出さないかにおいては、ファイルの前づけに書き込まなくてはなりません。
 

  このように、どちらのツールもコンテンツを手動で管理する仕組みであることがわかります。

 Hugoには、コンテンツ管理に便利な簡易関数が用意されています。
 新しいページを作る関数と、前づけを設定する関数の2種類があります。
 使い方は簡単。まず、新しいページを作るには、ファイルを作成するディレクトリに移動して、
 hugo new content/<新しいページ名.md>
 
というコマンドを打つだけ。これで新しいページが作られるはずです。

 もう1つが、「archetypes」というテンプレート型の関数です。カスタマイズすれば、同じ前づけの設定を他のファイルでもすぐに指定できるようになります。
 たとえば、ブログ記事やポッドキャストなど、ウェブサイトのコンテンツの種類ごとにテンプレートを決定しておくと、いちいち「ここの設定どうするんだっけ?」となる心配が減りますね。
 

  サイトを公開する準備ができたら、プレビューサーバーを閉じて、そのページに対してビルドコマンドを打ちます。これらはHugo独特の使い方ですね。

 Jekyllは、サイトに掲載する内容はすべて「_site」サブディレクトリに集約されます。Hugoでいうところの「public」ディレクトリに相当する部分です。

 どちらも、使い方を覚えてしまえば、自分だけの静的サイトを構築できます。あとはどんどんアップロードするだけ。

 

  カスタマイズ 

  HugoもJekyllも、いくつかの点でサイトをカスタマイズできます。先ほど説明したとおり、テーマの変更なども一種のカスタマイズです。
 他にも、機能面でカスタマイズするという方法もあります。

 Jekyllには、プラグインAPIが用意されていて、テーマの他にも機能的なコードを追加することができます。プラグインはコミュニティから仕入れたり、自分で記述することで入手します。
 

  しかし、HugoにはプラグインAPIがありません。なので、機能的なカスタマイズにおいては少し難しい状態です。将来プラグインを追加するための、きちんとした仕組みが登場する可能性は0ではありませんが、実際にそのような動きに転じたという話はまだ出てきていません。


 

  さて、選ぶならどっち?

  大まかにくくれば、HugoもJekyllもほとんど似たようなツールです。
 あとはそれぞれが、細かい違いを吟味して、自分が作りたいサイトに合う方を選択すればよいでしょう。

 JekyllはRubyGems環境を設定して、プラグインまで追加できるなど、機能的に様々な工夫ができるようです。

 それに対してHugoは、もっと単純で分かりやすいワークフローで、あなたのサイトを簡潔にカスタマイズできるという印象です。
 

  これはあくまで個人の感想ですが、私はHugoの方が今回の使用目的にかなっていると考えました。
  今回の目標は、「作品を掲載するためのサイトを作る」ことです。そこにこれといったプラグインなどは必要ないと感じたからです。

 もちろん、人によって静的サイトを作る目的には少しずつ違いがあるでしょう。あなたはどのような静的サイト・ジェネレータを選びますか?

PDF
更新日:2017-08-17 23:15:01 Hnoss 0  del.icio.usに追加   はてなブックマークに追加   twitterに投稿   facebookでshare
[ 原文 ] https://opensource.com/article/17/5/hugo-vs-jekyll Creative Commons License この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス
翻訳者ページをみる

この記事の翻訳者

Hnoss さんの翻訳記事

【GitLab 公式 を訳してみた】ランナーを登録する

GitLab Runner > ランナーを登録する  「ランナーの登録」とは、GitLabで実際に使っていくランナーをまとめあげる工程を指します。   前提条件   ラン…2017-11-24 21:17:38

【GitLab 公式 を訳してみた】GitLab Runnerをインストールする

GitLab Runner >Install GitLab Runner  GitLab Runnerは、GNU/Linux、 macOS、 FreeBSD、 Windowsでインストールと使用することが可能です。  インストールには3つの方法があり…2017-11-24 21:16:30

【GitLab 公式 を訳してみた】GitLab CI~コードの質を「Code Climate CLI」に判定してもらう設定

GitLab Documentation > GitLab Continuous Integration (GitLab CI) > GitLab CI 設定サンプル集 >コードの質を「Code Climate CLI」に判定してもらう  開発しているアプリ…2017-11-24 19:27:43

【GitLab 公式 を訳してみた】 .gitlab-ci.yml 設定メニュー

 (訳者より:翻訳がもうだいぶ進んだところで、GitLab CIについてネットで検索をかけてみたところ、 Qiitaにてynott様が公開されたバージョン があることに気がつきました。  原…2017-11-24 19:21:10