Hnoss

Hnoss

よっし。卵アイコンばかりってのも難だから、試しに手元の画像を出してみたぞ~♪
カレンダー

文書タグ

フノス(訳者)(189) IT(165) 解説記事(121) GitLab CI(58) オープンソース(49) Linux(38) メディア(33) コンテナ(28) ウェブ制作(24) DTM(19) HTML5(19) Libre Music(18) おすすめ オープンソース・ソフトウェア(17) GitLab(15) 百科事典(14) プラグイン(13) 文化(12) ソフトウェア(11) 録音(11) ミキシング(11) MIDI(10) 西アジア/中東(10) ジョージア(9) グルジア(9) 東ヨーロッパ(9) セキュリティ(9) 料理(9) シーケンス(8) 芸能(8) 音楽編集(8) 音楽(7) マスタリング(7) Raspberry Pi(6) 経済(6) 業務効率化(6) Google(5) WordPress(5) アプリ(5) JACK(5) コマンド(5) マイクロサービス(5) Windows(4) Android(4) 映像制作(4) GNU(4) 音楽プレーヤー(4) Ubuntu(4) 北米(3) アニメ(3) ホームオートメーション(3) アニメーション(3) IoT(3) Ardour(3) 社会(3) Java(3) ワークフロー(3) ソーシャルメディア(3) DAW(3) 欧州(3) Python(3) 牛(2) iOS(2) 歴史(2) ニュース(2) GNOME3(2) PlayStation(2) 仮想通貨(2) 古代エジプト(2) マーケティング(2) 有角神(2) エジプト(2) ALSA(2) OS X(2) ERPシステム(2) 電子ブック(2) トヨタ(2) バト(2) Krita(2) 電子書籍(2) ウィッカ(2) GPL(2) ERP(2) オカルト(2) Twitter(2) ロスレス音源(2) スマホ(2) 魔女宗(1) アクティブSETI(1) バイノーラル(1) Papagayo(1) 写真(1) 意味(1) コシディウス(1) インド(1) ユーコン(1) ヤーウェ(1) CD(1) タブレット(1) 学校(1) 日本(1) 羊(1) ベルゼブブ(1) デジタルサイネージ(1) VR(1) アップストリーム・パッケージング(1) 画像(1) 由来(1) グンデストルップの大釜(1) カナン(1) カナダ(1) サウンドフォント(1) 詩篇(1) チップチューン(1) バ・ネブ・デデト(1) コットン・マザー(1) クラウドキャスティング(1) VST(1) ポータブルソフトウェア(1) エリファス・レヴィ(1) マサチューセッツ(1) UNIX(1) 考古学(1) 申命記(1) クヌム(1) 魔女裁判(1) オンデマンド(1) リーナス・トーバルズ(1) バフォメット(1) amazon(1) 黙示録(1) スタジオジブリ(1) アモン(1) セイラム魔女裁判(1) ねじ巻きラジオ(1) 3D(1) 政治(1) イボ人(1) 国際(1) クリエイティブ・コモンズ(1) キリスト教(1) レビ記(1) Synfig(1) 独占(1) アマナイ(1) 広告(1) KXStudio(1) EU(1) イケンガ(1) 国際公文書館会議(1) マイナビ(1) ユダヤ教(1) ウルガタ聖書(1) 科学技術(1) 出エジプト記(1) 観光案内(1) 絵文字(1) サンフランシスコ(1) パキスタン(1) リクルート(1) ハトホル(1) パン(1) 地方(1) Blender(1) 羊神(1) ギリシャ(1) 高速道路情報無線(1) ツイッター(1) Youtube(1) 中南米(1) モヘンジョ=ダロ(1) CC(1) 悪魔(1) ラジオ(1) アレクサンドロス大王(1) ローマ(1) ポッドキャスト(1) ゲーム(1) 法律(1) パシュパティ(1) アピス(1) 宗教(1) テレビ(1) OpenToonz(1) 電子教材(1) 船乗りの柱(1) シリア(1) GPS(1) アフリカ(1) リグ・ヴェーダ(1) F-Droid(1) ムネヴィス(1) ネオペイガニズム(1) コミュニティ放送(1) アンビソニック(1) BountySource(1) 元ネタ(1) ケルヌンノス(1) ナイジェリア(1) 日記(1) 聖書(1) 任天堂 DS(1) 教育(1) bi-modal IT(1)
リファレンス

first-time visitors
user guide
謝辞

「みんなの翻訳」は情報通信研究機構言語翻訳グループ東京大学図書館情報学研究室による共同プロジェクトであり、三省堂国立情報学研究所連想情報学研究開発センターが開発に協力しています。三省堂には「グランドコンサイス英和辞典(36万項目収録)」の使用を許可していただきました。

連携研究グループはこちらをご覧ください。

「みんなの翻訳」を使っている翻訳グループについてはこちらをご覧ください。

バナー

logo

ポスター

poster

フライヤー

poster poster
Mozilla Firefox ブラウザ無料ダウンロード
本サイトはブラウザ「Mozilla Firefox」推奨です。
Firefox3で動作確認しています。

Valid XHTML 1.0 Transitional


GitLab DocumentationUser documentationProjectsGitLab Pages 説明書>GitLab Pages の 概要

 まず最初に

 GitLab Pagesは、無料で静的ウェブサイトをホスティングできるGitLabのサービスです。GitLab CIとGitLabランナーの力も借りて、ぜひあなた個人や、皆さんが所属しているグループのウェブページを作ってください。

 このページの終わりごろに『GitLab.comでGitLab Pagesを利用する』というコーナーがあります。
 そこでは、GitLab.comというクラウドサービスを使ってウェブサイトを作成する方法を詳しくお教えいたします。

 GitLabPagesについて、皆さんに知っていただきたいことをこちらのページにまとめました。
 (ウェブページ、記事、ガイド、ブログ、ビデオチュートリアルなど、様々なコンテンツがありますが)ぜひ、全部読んで、これからのウェブサイトの制作にお役立てください。

 GitLab Pagesの始め方

注:この文章では、ドメインの説明に「example.io」を使っていきます。頭の中で皆さんのドメインに変換して考えてください。

 GitLabで作れるページには、主に2つの種類があります。
 *いずれもドメインですので、()内はすべて半角英数であることを念頭においてください

  • ユーザーごとのページ(ユーザー名.example.io)、グループごとのページ(グループ名.example.io
  • プロジェクトごとのページ(ユーザー名.example.io/プロジェクト名 あるいは グループ名.example.io/プロジェクト名


 GitLabでは、ユーザー名やグループ名を複数持つことはできない決まりになっていますが、名前空間を作ることは可能です。

 以下の表は、GitLab Pagesの種類ごとに、GitLab上に作られるプロジェクト名と、サイトのURLとを比較したものです。

GitLab Pagesの種類 GitLab上に作られるプロジェクト名 ウェブサイトの URL
ユーザーごとのページ username.example.io http(s)://username.example.io
グループごとのページ groupname.example.io http(s)://groupname.example.io
個人ユーザーがプロジェクトを有している場合 projectname http(s)://username.example.io/projectname
グループがプロジェクトを有している場合 projectname http(s)://groupname.example.io/projectname

 警告:名前空間で作成したドメインには、HTTPSの使用に制限があります。詳しくは、同文以下の『GitLab Pagesにおける制限』をご覧ください。

 GitLab Pagesで必要なもの

 GitLab Pagesでウェブサイトをアップロードするには、これらの工程が必要です。:

  1. 作成したページにたどり着くまでの一般ドメイン名を知ること。管理者に尋ねること。ほとんどこれが最重要事項なので、最初に聞いておく。
  2. プロジェクトを作成すること。
  3. レポジトリのルートディレクトリに.gitlab-ci.yml fileをプッシュすること。その際、 pagesというjobタスクグループを設定しておくことを忘れない。
  4. ランナーをウェブサイトのビルドに向けて設定すること。


 注:ランナーは、管理者から勧められたものがあるなら、なるべくそれを使用すること。

 ユーザーごとのページ、グループごとのページについて

 ユーザーやグループごとにウェブページを作成する場合、プロジェクト名と一般ドメイン名とにユーザー名やグループ名が冠されるのが普通です。
 たとえば、ユーザー名でプロジェクトを作成すると、「username.example.io」というレポジトリが作られます。
 ここでプロジェクト名をつけてプロジェクトを作った場合は、必ずしもユーザー名がつけられるわけではないので、それも考慮に入れておくとようでしょう。

 グループページも同様に、グループ名が入ったプロジェクト名とドメインとがつけられます。グループの名前空間の中にプロジェクトを作成すると、自動的にそのような設定になります。

(写真1)新しくプロジェクトを作る

 レポジトリの中に何らかの静的コンテンツをプッシュすると、GitLabランナーがGitLab CIの設定を元にアップロードします。
 あとは、「http(s)://username.example.io」などのアドレスでウェブサイトにアクセスして、出来栄えを確認しましょう。

 注:ユーザー名やグループ名にドット「.」がついている場合(「foo.bar」など)、ワイルドカードドメインでHTTPSが使えません。詳しくは同文以下『GitLab Pagesにおける制限』を読んでください。

 プロジェクト名からページを作る

 ユーザーアカウントでも、グループアカウントでも、名前の付いたプロジェクトを作成することは可能です。
 同じように、GitLab Pagesを利用する時にも、まずはプロジェクトを作成してからページの作成に取り掛かることができます。

 ウェブページの作り方自体は、ユーザー/グループごとに作るページと変わりません。:

  1. 新しくプロジェクトを作成する
  2. レポジトリのルートディレクトリに.gitlab-ci.yml fileをプッシュする。その際、 pagesというjobタスクグループを設定しておくことを忘れない。
  3. ランナーをウェブサイトのビルドに向けて設定する。


 そうして作られたプロジェクトは、「http(s)://username.example.io/projectname」あるいは、「http(s)://groupname.example.io/projectname」というようなドメインで配信される。

 プロジェクトから作成したウェブページがどのようなドメインになるかは、『GitLab Pages のこと全部教えます!①「静的ウェブサイトとは何か」「デフォルトのドメイン設定」』が参考になります。

 手っ取り早く始めるには

 まずは、GitLab Pagesが発表しているガイダンスや、GitLab.comでウェブサイトを公開する方法を映像で説明したビデオも公開されていますので、ぜひ内容をご確認ください。

 また、GitLab Pagesの機能についてさらに詳しく知りたい方は、GitLab Pagesのリソースリストから様々な記事にアクセスいただけます。

 .gitlab-ci.ymlファイルでできること

 GitLab Pagesを使う上でのかなめになるのが、.gitlab-ci.ymlファイルの設定です。これを使うことでビルドプロセスを効果的に操作できます。
 これからウェブサイトをビルドするうえで大切な、CI job の大まかな作り方を紹介します。

 GitLab Pages用の CI/CD 例は『【GitLab Pages 公式 を訳してみた】GitLab Pages のこと全部教えます!④ 「GitLab CI を作成し、工夫する」』が参考になります。

注:この説明を読むか前に、GitLab CIの使い方と、「.gitlab-ci.yml」ファイルのシンタックスについて目を通しておいてください。こちらのクイックスタートガイドが参考になります。

 GitLab Pages用の「.gitlab-ci.yml」を作成していく上で、守っていただきたいルールがあります。

  • pages」というGitLab Pagesでしか使われないjobを設定すること
  • GitLab Pagesで扱われる静的コンテンツは、すべて「public/」ディレクトリ配下に入れること
  • artifacts」というキーワードの下に、「public/」へのパスを設けること

 最も単純な設定例はこちらです。ひな型にしてください。

======================
pages:
 script:
 - my_commands
 artifacts:
  paths:
  - public
======================

 ランナーがページを組み立てるには、何にせよ「pages」jobがなくてはなりません。ビルドに必要なコマンド類は「script」パラメータに記入します。
 jobの成果が0ではなかった時に限り、「public/」ディレクトリにアップロードが行われ、GitLab Pagesに反映される仕組みです。

 「public/」ディレクトリには、皆さんのウェブサイトにある静的コンテンツを全て収蔵します。
 ウェブサイトを”技術的な意味で”どのように発表させるかについては、「script」パラメータを使います。

 Pagesはデフォルトの状態では、branch/tagに対応しておりません。ウェブページのデプロイは、基本的に「.gitlab-ci.yml」で定義したものにのみ従うようにされています。
 そこで、branchやtagにプッシュをしたいときには、コンフィグファイルの「only」パラメータをその通りに定義する必要があります。

 以下に示しますのは、masterブランチにプッシュがあったときにのみ、ウェブページをデプロイさせる設定です。

======================
pages:
 script:
 - my_commands
 artifacts:
  paths:
  - public
 only:
 - master
======================

 ウェブページを構築するパラメータは、すべて「pages」jobに入れることで始めて、ランナーは「これからウェブページをビルドするんだ」ということを感知できます。
 特に、「public/」ディレクトリについては、「pages」job配下に入れないと、ランナーが静的コンテンツの収容場所と認識してくれません。

 静的コンテンツを全部「public/」ディレクトリに入れる方法

 ごく一般的な静的サイトジェネレータなどを使っている場合などは、レポジトリ内には次のようなファイルがあることでしょう。

======================
├── index.html
├── css
│ └── main.css
└── js
└── main.js
======================

 拡張子を見ると、それぞれ「html、css、js。」これらはすべて静的コンテンツに当てはまりますね。だいたい、プロジェクトのrootディレクトリのどこかに収容されています。
 こういうものたちを「.gitlab-ci.yml」ファイルの設定で、ビルド時に「public/」ディレクトリに送付されるようにしなくてはなりません。

 以下はその一例です。
 「public/」ディレクトリをコピーし続ける無限ループを防止するために、「.public」のコピーを一時的に抑制する設定(- cp -r* .public)をしてあります。

======================
pages:
 script:
 - mkdir .public
 - cp -r * .public
 - mv .public public
 artifacts:
  paths:
  - public
 only:
 - master
======================

 とくに静的サイトジェネレータを使う時に必要な設定

  GitLab Pagesは、ほぼ全種類の静的サイトジェネレータに対応しています。
 「.gitlab-ci.yml」で静的サイトジェネレータを使う上で必要なコマンドを設定すると効率的です。

 サイトジェネレータのソースファイルは、Gitレポジトリのrootディレクトリに収納しましょう。
 どのジェネレータを使うかについては、主に「.gitlab-ci.yml」ファイルで設定します。

 たとえば、Jekyllサイトジェネレータを使う場合は、次のような設定が入ります。

======================
pages: # ビルドjobは「pages」にしなきゃだめ。
 script:
 - gem install jekyll # Jekyllをインストールするコマンド
 - jekyll build -d public/ # Jekyllでサイトをビルドするコマンド。対象ディレクトリが「public/」になっている。
 artifacts:
  paths:
  - public # これはランナーがウェブサイトのアップロード先を認識するのに必要。
 only:
 - master # 以上のスクリプトはmasterブランチにしか影響しないことを明示する。
======================

 このように、必要なライブラリをDockerコンテナで用意することがあります。
 他のプロジェクトならともかく、ウェブページを立ち上げる際には、ランナーでDockerエクゼキュータが使えることが求められるかもしれません。

 静的サイトジェネレータでサイトを作る時は、scriptの段階からして「public/」ディレクトリに全てのコンテンツが組み立てられるように注意しなくてはなりません。(例:- jekyll build -d public/)
 「paths: - public」は、あくまでランナーだけを対象にした指令であることを忘れないでください。

 「script」に記載する、静的サイトジェネレータ向けのコマンドは、ソフトによって異なります。
 ディレクトリの指定方法を重点的に、各自で調べて入力してください。

 一部ジェネレータでは、ディレクトリを指定するオプションが存在しない可能性があります。その際は「script」に、結果ディレクトリを「public/」にするコマンドを挿入してください。

 そして「artifacts: paths: - public」の入れ忘れで、ランナー自体がコンテンツの収容場所を認知できずに、ビルドが果たされないケースもよくあります。こちらも十分ご注意ください。

 jekyllの機能や仕組みについて、より理解を深めたい方はjekyll example projectをご覧ください。

 Pagesプロジェクトに簡単に導入できるジェネレータは、後述「プロジェクト実例」の章で紹介いたします。

 GitLab Pagesの「レポジトリ」を立ち上げるコマンド

 先ほど、GitLab Pagesはよほど「.gitlab-ci.yml」ファイルに定義しないかぎり、「branch/tag」を無視するように設計されていると述べました。
 「pages」jobが働くのは、onlyパラメータで定義されたブランチに更新があったときだけです。

 これらの条件を念頭に、ウェブページ用の独立ブランチ(仮に『pages』と名付ける)で、静的サイトジェネレータで作ったサイトをホストする手順をご紹介します。

 まずは、新しい空白ブランチを作成します。

======================
git checkout --orphan pages
======================

 最初のコミット時点では、rootディレクトリには何のファイルもプログラムもありません。もちろん、このままでは何の機能の果たしませんよ。

 そこで静的サイトジェネレータのバイナリを、このブランチに挿入するとサイトが一気に形に近づきます。

 バイナリの導入には「.gitlab-ci.yml」を使用します。
 ジェネレータがjekyllの場合は、次のようなコンフィグが基本となるでしょう。

======================
image: ruby:2.1

pages:
 script:
 - gem install jekyll
 - jekyll build -d public/
 artifacts:
  paths:
  - public
 only:
 - pages
======================

 同じJekyllをソースにしたウェブページといえども、masterブランチでビルドするものと、pagesブランチでビルドするものではソースファイルが違います。.gitlab-ci.ymlで指定する際には、ご注意ください。


 次の段階

 ウェブサイトのデプロイで大前提となる条件は以上です。うまくいったでしょうか?
 GitLab Pagesの更なる使い方を見てみましょう。

 例示プロジェクト

 GitLab Pagesでは、主に以下のようなジェネレータの例示プロジェクトを掲載しています。
 ごく普通のHTMLサイトから、様々な静的サイトジェネレータを扱っています。
 どれもたくさんの人にフォークされるものです。改良案がございましたら、ぜひコミットしてください。

 その他の例示プロジェクト: https://gitlab.com/groups/pages


 制作したウェブサイトに独自ドメインをつける

 Pagesのドメイン変更方法については、『GitLab Pages のこと全部教えます!③「カスタムドメインの設定」「サブドメインの設定」』に詳細な情報がありますが、ここではGitLabのUIを使って、ドメインを変更する手順を追っていきます。

 まず、この操作には、皆さんがGitLabプロジェクトの管理者であることが求められます。
 皆さんがウェブページプロジェクトの管理者なら、プロジェクト設定画面の「Pages」という項目の右上に、「+ New Domain」ボタンが表示されているはずです。

 (写真1) 「+ New Domain」ボタン

 GitLabでホストしているウェブサイトを示すドメインは、複数個を登録することができます。
 一度登録したドメインは、「Domains」という項目にまとめて表示されます。
 (写真2)「Domains」に表示されたドメイン

 最後に、DNS設定と、CNAMEをuser/groupページを指すように登録します。
 ドメイン横の「Details」ボタンをクリックしてください。
 (写真3)DNS設定画面

注:独自ドメインは現在、プロジェクトごとに登録する形態をとっております。たとえば、「username.example.io/foo」というドメインがついているPagesプロジェクトがあったとします。ここに独自ドメイン(例:example.com)を追加すると、ユーザーのウェブサイト(username.example.io)のプロジェクトのドメインが変更されることになるので、元の「username.example.io/foo」ではプロジェクトにアクセスできなくなります。

 TLS証明書で独自ドメインをより安全に運用する

 新たに独自ドメインを登録した方は、ぜひともTLS証明書を追加することをお勧めします。
 ウェブページプロジェクトの管理の方なら、ドメインに公開証明書とプライベートキーを付加させられます。

 (写真4) TLS設定画面

 詳しくは、GitLab Pages のこと全部教えます!③「カスタムドメインの設定」「サブドメインの設定」をご覧ください。

 エラーコードの設定

 GitLab Pagesでは、403や404エラーの設置は個人に任せられています。
 これらは、「public/」ディレクトリの「root」ディレクトリ内に、「403.html」「404.html」ファイルを設けることで構築します。

 これらのファイルはプロジェクトの「root」ディレクトリに設置することがほとんどですが、静的サイトジェネレータによってその仕様が異なる可能性があります。

 特に「404.html」の設置方法は、状況に応じて変化しますのでご注意ください。

  • プロジェクトのPages(仮に、/projectname/)を使っており、「/projectname/non/existing_file」へのアクセスを試みるとします。すると、GitLab Pagesはまず「/projectname/404.html」を表示しようするので、結果的に「/404.html」ファイルにありつけるようになります。
  • ユーザーあるいはグループのPages(/の配下に具体的なページが示される)を使っており、「 /non/existing_file」へのアクセスを試みるとします。すると、GitLab Pagesは「/404.html」を送信します。
  • 独自ドメインを使っており、「/non/existing_file」へのアクセスをするならば、GitLab Pagesは「/404.html」を送信します。

 ウェブサイトの削除方法

 サイトをどうしても削除しなくてはならない場合、プロジェクトの右上にある歯車型アイコンから「Pages」を選択、設定ページに進みます。
 そこから、「Remove pages」ボタンを押せば、ウェブサイトの削除が実行されます。たったこれだけなので、判断は慎重に。
 (写真5)ウェブサイトを削除する

 GitLab.comでGitLab Pagesを利用する

 GitLab.comでウェブサイトをホストすると、次のような機能が使えます。

  • GitLab.comにホストされたPagesの一般ドメイン名には、「gitlab.io」がつく。
  • 独自ドメインと、そこにTLS証明書をつけること。
  • デフォルトで共有ランナーの使用(無料)が許可されている。個人で作成したランナーを使用してもよい。ウェブサイトのビルドでお金を取られる心配はない。

 さらに詳細については、次のガイドをご覧ください。

参照:GitLab Pages のこと全部教えます!①「静的ウェブサイトとは何か」「デフォルトのドメイン設定」

 GitLab Pagesにおける制限

 GitLabが提供している一般ドメイン(*.example.io)でPagesを作成した場合は、サブドメインにHTTPSを使用することができません。
 特にユーザー名やグループ名にドット「.」がついている場合(例:『foo.bar』など。URLは『https://foo.bar.example.io』にしたいけれど…)では、ドメインにHTTPSが使えません。
 この制限については、TLSプロトコルを使ったHTTP通信の性質によるものです。
 以上の場合については、HTTPからHTTPSへのリダイレクトが発生しないため、通信が暗号化されません。

 GitLab Pagesプロジェクトには、サブグループを設けることができません。ウェブサイトについては、最上位グループを設けるにとどまります。

 GitLab Pagesのリダイレクト

 「.htaccess」や「.conf」ファイルなど、何らかの独自サーバー設定ファイルが使えない際に、ページをリダイレクトする場合は、HTTP meta refreshをお使いください。

 静的サイトジェネレータによっては、あらかじめリダイレクト専用のプラグインを用意しているものがありますので、HTMLファイルを正確に作成する自信がない場合は、それを使うとよいでしょう。
 たとえば、Jekyllなら「redirect-from plugin」というものがあります。

 よくある質問

 作成したウェブページはダウンロードできますか?

 もちろん。アーティファクトをダウンロードすることで、あなたが作成したページをアーカイブ保存しておくことが可能です。

 GitLab Pagesはプロジェクトのソースを非公開にして構いませんか?

 はい。GitLab Pagesのプロジェクトは、非公開(private)、一部公開(internal)、完全公開(public)のいずれかから公開レベルを選択できます。

 ウェブサイトのプロジェクトを作成する前に、ユーザー/グループのウェブサイトを作っておく必要はありますか?

 いいえ。そのような操作はできません。
 まずはページのプロジェクトを作成してから、「http(s)://namespace.example.io/projectname」のようなURLでアクセスができるようになります。


 この機能に関するご意見

 すでにお寄せいただいているご意見、議論につきましては、GitLab's public issue trackerに掲載されています。


Edit this page

原文:https://docs.gitlab.com/ee/user/project/pages/introduction.html
原文ページプロジェクト並びにドキュメントファイルは、MIT Licenseのもと公開されています。(URL: https://gitlab.com/gitlab-com/gitlab-docs/commit/1ecee98751ee89d91de5bfb272535c16b94981ab)この記事の文章は、訳者の判断によりCreative Commons BY (version 3.0) を適用するものとします。
新着文書(Hnoss)

Configuration of your jobs with .gitlab-ci.yml
 目次: > .gitlab-ci.yml とは  > image と services  > before_script  > after_script  > stages  > types  > variables ...
Getting started with GitLab CI/CD
GitLab Documentation > GitLab Continuous Integration (GitLab CI) >GitLab CI/CD の使い方 注: GitLab バージョン 8.0から、 GitLab ...
Configuring GitLab Runners
GitLab Documentation > GitLab Continuous Integration (GitLab CI) >GitLab Runnerを設定する  GitLab CIにおいて、Runner(ランナー...
Introduction to job artifacts
GitLab Documentation > User documentation > Projects > job artigacts の概要 注: この機能は、GitLab 8.2 並びに GitLa...

新着文書

Diplomacy of Conscience[Chapter 1]Amnesty International and Changing Human Rights Norms / Ann Marie Clark
第1章 国際政治の中のアムネスティ・インターナショナル 小さな個々人の集まりがアムネスティ・インターナショナル(AI)を1961年に設立した:人権...
release sudan human rights defender dr mudawi ibrahim adam / Defend the brave: release Dr Mudawi Ibrahim Adam
[組織的な運動原文] ムダウィ博士は勇敢に強く弁護した:スーダンで暴力から避難する家族たちのために、多くの他の人権問題と同様に。このために、彼は...
The Impact of Reparameterization on Point Estimates / Bob Carpenter
点推定における再パラメータ化の衝撃 ボブ カーペンター 2016年4月24日 概要 変数を変更する時、変換の変化率を説明するために、ヤコビアンの調...

新着Wikipedia翻訳

Trusted Computer System Evaluation Criteria
Trusted Computer System Evaluation Criteria(信頼されたコンピュータ・システム評価基準) 【画像のキャプション】オレンジブック 信頼されたコ...
Trusted computing base
Trusted computing base 信頼できるコンピューティング( Trusted Computing )と混同しないこと。 コンピュータシステムのtrusted computing...
Wikipedia Today's Photo: March 30 2017
オランダの後期印象派画家、ヴィンセント・ヴァン・ゴッホ(1853-1890)。作品が進化していくにつれ、静物、農民、風景、オリーブの木、小麦畑、ひま...

更新履歴

※文書量によっては処理に数十秒かかる場合があります
バージョン 比較対象 更新日時 更新者
1(最新) 2018-01-31 00:12:27 Hnoss
2 2018-01-31 00:12:15 Hnoss
3 2018-01-31 00:10:18 Hnoss
4 2018-01-31 00:08:47 Hnoss
5 2018-01-31 00:03:01 Hnoss
6 2018-01-31 00:02:06 Hnoss
7 2018-01-31 00:02:04 Hnoss
8 2018-01-31 00:01:06 Hnoss
9 2018-01-30 23:59:54 Hnoss
10 2018-01-30 23:53:40 Hnoss

    
ブックマーク登録

タグを「;(半角セミコロン)」区切りで入力して下さい(例)tag1;tag2;tag3
10タグまで登録可能。各タグ30文字まで

履歴
状態 作業中 作業予定あり 作業予定なし 作業完了
テーマ 社会 政治 法律 経済 文化 芸能 科学技術 IT 健康/医療 スポーツ メディア 植物 動物 菌類 地方 国際
地域 日本 東アジア アフリカ 南アジア 東南アジア 西アジア/中東 太平洋 北米 中南米 欧州
ジャンル ニュース 解説記事 論文 日記 百科事典

コメントを入力して下さい
0 / 250
    
ブックマーク登録

ブックマークに登録しました。


言語選択

    
ファイルプロパティ

使用許諾条件
ファイル情報
あなただけがこのファイルを閲覧・編集できます。
みんながこのファイルを閲覧できますが、
編集ができるのはあなただけです。
あなたに加えて、指定された人やグループが
このファイルを自由に閲覧・編集できます。
公開設定
編集設定
グループ:0組 翻訳者:0人
    
アクセス属性
この文書は「非公開」設定になっています。
一般公開する場合は、編集ページの書誌情報で「公開」設定に変更して下さい。
翻訳者選択

※メニュー「翻訳者管理」で翻訳者、グループを追加することができます。


    
ノート

非公開ノート
0 / 2000 ※「公開・編集」権限を持つ翻訳者のみに公開されます。
公開ノート
0 / 2000 ※文書を「公開」にした場合、一般に公開されます。

言語選択

 →