tanaka's Programming Memo

プログラミングについてのメモ。

Laravel5.4の新機能

Laravel5.4が出ていたので、公式ページの新しい機能の紹介部分を読みながらのざっくりメモです。

Release Notes - Laravel - The PHP Framework For Web Artisans

マークダウンでメールとNotificationsの文面を書けるようになった

マークダウンで書いたメールや通知の文面は、 Laravel でプリビルドされて、レスポンシブな HTML テンプレートと plain textの双方が生成されるとのことで、これはとてもありがたいです。

タグに該当するものは @component()〜@endcomponent で囲みます。

  • mail::message メール文
  • mail::button 第2引数に URL を渡して、ボタンを生成
  • {{}} で PHP が実行できるので、 {{ config(‘app.name’) }} などのようにすれば設定を読み取れる

マークダウンで生成されるスタイルをカスタマイズしたい場合は、artisan コマンドの vendor:publish を実行します。この設定だけ書き出したい場合は、 laravel-mail タグを追加します。

Laravel Dusk

Webブラウザー上での動きや、 API をテストするための新しい機能です。デフォルトで使う場合は、 JDKSelenium のインストールはせず、スタンドアロンの ChromeDriver を利用します。

Webブラウザー上でテストするので、 JavaScript を利用する機能のテストも可能です。

Selenium を利用することももちろんできます。

$this->browse(関数)でテスト開始します。

Browser Tests (Laravel Dusk) - Laravel - The PHP Framework For Web Artisans

Laravel Mix

これまでは、 Gulp ベースの Laravel Elixir がビルドツールとして提供されていましたが、その Webpack 版です。

Laravel Mix は、 Laravel アプリで使われる CSSJavaScript を処理するプリプロセッサーを Webpack の APIとして提供します。

Blade コンポーネントとスロット

Vue.js にある コンポーネントとスロットと同様の機能を Blade で使えるようになりました。

コンポーネントの定義内で、スロットの位置に {{ $slot }} を書きます。

Blade内で、上記で定義したコンポーネントを @component(コンポーネント名)〜@endcomponent で利用して、その間にスロットに差し込みます。

以下、公式サイトの例です。

以下、alert コンポーネントの定義例。

<!-- /resources/views/alert.blade.php -->

<div class="alert alert-danger">
    {{ $slot }}
</div>

以下で、alert コンポーネントのスロットに「Whoops! Something went wrong!」を渡します。

@component('alert')
    <strong>Whoops!</strong> Something went wrong!
@endcomponent

名前付きスロットを利用する場合は、 @slot(‘スロット名’)と@endslot の間に、スロットの中身を書きます。

Broadcast Model Binding

HTTPルートのように、 Broadcast の channel で、 Route Model Binding(RouteのURLセグメントに含まれるモデルのIDに該当するデータを、自動的にデータベースから取得して、ルート関数に渡す機能) と同様のルート機能を利用できるようになりました。

以下、公式サイトの例です。 Authorizing Channels の例を書き換えています。

use App\Order;

Broadcast::channel('order.{order}', function ($user, Order $order) {
    return $user->id === $order->user_id;
});

上記の元のコードは以下です。関数内で、データベースにアクセスしている部分が省略できています。

use App\Order;

Broadcast::channel('order.{orderId}', function ($user, $orderId) {
    return $user->id === Order::findOrNew($orderId)->user_id;
});

Collection Higher Order Messages

Collections (データベースから取り出したデータのオブジェクト) が、コレクション上でよく利用する共通の操作を行うショートカットを実装しました。対応したのは以下のメソッドです。

contains, each, every, filter, first, map, partition, reject, sortBy, sortByDesc, and sum.

以下、公式サイトの例です。 User モデルから votes の値が 500 より大きいデータを $users に取り出して、取得したデータごとにmarkAsVip()関数を実行する例です。

$users = User::where('votes', '>', 500)->get();

$users->each->markAsVip();

以下は、 sum の例で、 Userモデルから group が Development のデータを $users に取り出して、 取り出したデータの votes 要素の合計を求めて、 return しています。

$users = User::where('group', 'Development')->get();

return $users->sum->votes;

Object ベースの Eloquent イベント

Eloquent のイベントハンドラーがイベントオブジェクトに対応づけられました。より直感的に、 Eloquent イベントを制御したり、テストできるようになります。Eloquent モデルに $events プロパティーを定義することで、様々なライフサイクルでイベントを呼び出すことができます。

対応するイベントは Eloquent: Getting Started - Laravel - The PHP Framework For Web Artisans

Job Level Retry & Timeout

これまでの Job の リトライやタイムアウトは、コマンドラインからすべてのジョブに対して共通設定となっていました。これを、 job クラス上で、ジョブごとに設定できるようになりました。

$tries プロパティーでリトライ数、$timeout プロパティーでタイムアウトまでの秒数を指定できます。

リクエスト文字列を整理するミドルウェア

デフォルトミドルウェアに、 TrimStrings と ConvertEmptyStringToNull ミドルウェアが追加されました。これにより、入力文字列の前後の空白は削除され、未入力の場合は null になります。

Realtime ファサード

これまでは Laravel のビルトインのサービスのみがファサードとして利用できたが、ユーザーのクラスを簡単に Facade として利用できるようになった。 use Facades\ {} のブラケット内にクラス名を登録すれば、ファサードとして機能します。これを Realtime Facades と言います。

このように定義したユーザーファサードも、 shouldReceive()などのモック化機能が使えるので、テストも容易になります。

カスタム Pivot Table モデル

Laravel5.3 では、 belongsToMany() のリレーションのための pivot テーブルはすべて共通のビルトインの Pivot モデルインスタンスを利用していました。Laravel5.4では、カスタムの Pivot テーブルを定義できるようになりました。

テーブル間を結ぶ中間テーブルに独自のテーブルを指定したい場合は、 using メソッドで指定します。

Redis Cluster サポートの改良

これまでは、同じアプリケーション内で、単体のホストとクラスターへの Redis の接続を定義できませんでしたが、 5.4 では複数のホストとクラスターを一つのアプリケーション内で接続できるようになりました。

Migration Default String Length

Laravel5.4 では、絵文字に対応できるように、デフォルトの文字セットとして utf8mb4 を使うようになりました。Laravel5.3からアップグレードする際には、キャラクターセットの変更は不要です。

手動でこの文字セットに変更したい場合や、 MySQL の Ver5.7.7 より古いもので動かしている場合は、 migration によってデフォルトの文字長を設定し直す必要があります。 AppServiceProvider クラスの boot メソッド内で Schema::defaultStringLength メソッドを呼び出して設定します。

以下、公式サイトの例です。

use Illuminate\Support\Facades\Schema;

/**
 * Bootstrap any application services.
 *
 * @return void
 */
public function boot()
{
    Schema::defaultStringLength(191);
}

まとめ

メールや通知のマークダウン対応はすぐにでも取り入れたいです。Laravel Dusk は、 Codeception との位置付けがどうなっているか、まだ読んでいないのでわかりませんが、SeleniumJDKのインストールをせずに簡単なテストが可能になったのはありがたいです。PHPUnit のバージョンが変わって、メソッド名を変更しないと動かないことがあるようなので、その辺はアップグレードガイドの方で確認する必要があるようです。データベースの文字セットの変更もチェックが必要そうです。

すでに Elixir で環境を構築していたら不要とは思いますが、Webpack を採用する場合、 Laravel Mix へ移行すると良さそうです。

Bladeのコンポーネントとスロット機能や、データベースを操作するショートカット、入力値の自動トリミングや 空文字列の null 値への変更、カスタムファサード機能など、良い改良が施された印象でした。


以下、新しい機能ではありませんが、 Broadcast Model Binding を読む際にまとめてしまったので。

おまけ

Route Model Binding

モデルのIDをルートやコントローラーのアクションに渡す時に、渡された ID を持つモデルを検索する場合がしばしばあります。Laravel の Route Model Binding は、作成するルートに自動的に指定のモデルのインスタンスを渡す簡単な機能を提供します。例えば、ユーザーの ID をそのまま渡すのではなく、その ID が指定する ユーザーモデルのインスタンスを渡す方法です。

暗黙的なバインディング

Laravel は、ルートやコントロールアクション内のタイプヒントの文字列から、 Eloquentモデルのフィールド名を推測して、該当するモデルデータを自動的に取得します。

Route::get('api/users/{user}', function (App\User $user) {
    return $user->email;
});

(公式ページから転載)

例えば上記の例では、引数である $user には、App\User の Eloquent モデルが渡されるように型指定(type hinted)されていて、変数名と URI セグメントの指定が一致する {user} の場所の ID がモデルの特定に利用されます。 Laravelは自動的にリクエスト URI で渡される値からユーザーのIDを検索して、そのモデルのインスタンスを自動的に引数として渡します。もしデータベースで指定のIDが見つからなかった場合は、 404 HTTP レスポンスが自動的に生成されます。

## キー名のカスタマイズ

id 以外のフィールドでマッチさせたい場合は、Eloquentモデルの getRouteKeyName メソッドをオーバーライドします。

/**
 * モデルを検索するルートのキーとして slug を利用したい場合
 */
public function getRouteKeyName() {
    return 'slug';
}
明示的なバインディング

Router の model メソッドを使って、明示的に指定のクラスを登録することができます。明示的なモデルのバインディングの登録は、RouteServiceProviderクラスの boot メソッドに書きます。

以下、公式ページの例です。

public function boot()
{
    parent::boot();

    Route::model('user', App\User::class);
}

次に、{user}パラメーターを含んだルートを定義します。

Route::get('profile/{user}', function (App\User $user) {
    //
});

全ての {user} パラメーターは App\User モデルにバインドされて、User インスタンスがルートで渡されます。例えば、 profile/1 でリクエストされたら、 ID が 1 のユーザーモデルのインスタンスがコールバックの引数の $user に渡されます。

ID が見つからなかった場合は、 404 HTTP レスポンスが自動的に生成されます。

## 解決方法のカスタマイズ

独自に渡されたパラメーターからモデルを取得するロジックを組みたい場合は、 Route::bind メソッドを使うと良いでしょう。bind メソッドに渡した Closure で URI セグメントの値を受け取って、ルートに渡すクラスのインスタンスを返すようにします。

以下、公式サイトの例です。

public function boot()
{
    parent::boot();

    Route::bind('user', function ($value) {
        return App\User::where('name', $value)->first();
    });
}

GitHubでみんなで開発2016年度版-管理者編

オリジナルリポジトリーを管理できるように、プルリクエストの対応方法をまとめます。

前提

準備

すでにプルリクエストされるリポジトリーがあれば、プルリクエストをダウンロードするへ進んでください。練習をしたい人は、二人以上のグループで、以下の作業をしてください。

Webブラウザーhttps://github.com を開いて、ログインしてから作業を開始しましょう。

リポジトリーを作成する

Unity の新規プロジェクトを作成して、プルリクエストを送りあってみましょう。

  • Unity を起動して、New で AdminRensyu などの名前でプロジェクトを作成

バージョン管理をしやすくするための設定をします。[Inspector]ビューで、以下を設定してください。

  • [Edit]メニューから[Project Settings]>[Editor]を選択
  • [Version Control]欄を[Visible Meta Files]に変更
  • [Asset Serialization]を[Force Text]に変更 f:id:am1tanaka:20170204234425p:plain

保存します。

  • [File]メニューから[Save Scene]を選択して、[Test]などのシーン名で保存
  • [File]メニューから[Save Project]を選択

以上で、雛形の状態ができました。これを GitHub Desktop に登録します。

GitHubへの登録

  • [Project]ビューの[Test]スクリプトを右クリックして、[Show in Explorer]を選択して、プロジェクトの場所をエクスプローラーで開く
  • Assets フォルダーが開くので、一つ上のフォルダーへ移動 f:id:am1tanaka:20170204234520p:plain
  • そのフォルダーのパスをコピーしておく
  • GitHub Desktop を起動
  • 左上の[+] > [Add] をクリック
  • [Local path]欄に、先ほどコピーした Unity のプロジェクトフォルダーのパスを貼り付ける f:id:am1tanaka:20170204234536p:plain
  • 下に!が表示されて、[create a repository]がクリックできるので、クリック(!のメッセージが表示されない場合は、Unityのプロジェクトを、Unity Projects フォルダーか、GitHub フォルダー内に移動してから、再度試してみてください)
  • [Create]に切り替わるので、[Git ignore]を[Unity]にして、[Create repository]をクリック f:id:am1tanaka:20170204234551p:plain
  • [Changes]をクリック
  • [Summary]欄に「プロジェクトを追加」などと入力して、[Commit to master]をクリック
  • Publishを押す
  • Description欄に「GitHubの管理者練習用リポジトリー。」などのように入力
  • [Publish <リポジトリー名>]をクリック

以上で、練習用のリポジトリーの作成が完了した。

練習用リポジトリーのフォークとクローン

作成した練習用リポジトリーの URL を、練習相手と教えあいましょう。自分が作成した練習用リポジトリーの URL の確認方法は以下の通りです。

練習相手のリポジトリーの URL を Webブラウザーのアドレスバーに入力して開きます。

GitHubでみんなで開発2016年度版 - tanaka's Programming Memo の手順に従って、練習相手のリポジトリーをフォークして、 GitHub Desktop でクローンをしてください。

Unity で変更を加える

クローンしたリポジトリーは、 AdminRensyu-1 のような名前になっていると思います。それを、 Unity で開いてください。

  • Unity に切り替える
  • [File]メニュー > [Open Project…] を選択
  • クローンしたリポジトリーのフォルダーを選択して開く

Unityが起動したら、以下の変更を加えましょう。

  • [Hierarchy]ビューの[Create]をクリックして、[3D Object]>[Cube]で立方体を作成する
  • 作成した[Cube]を選択して、[Inspector]ビューの[Add Component]をクリックして、[New Script]を選択
  • 名前を[Test]などにして、[Create and Add]を選択して、スクリプトを作成して、Cubeにアタッチする
  • [File]>[Save Scenes]でシーンを保存
  • [File]>[Save Project]>でプロジェクトを保存

以上で、プルリクエストする内容ができました。

プルリクエストの作成

プルリクエストを作成します。プルリクエストをする前に、コミットしておく必要があります。

  • GitHub Desktop に切り替える
  • [Changes]をクリック
  • [Summary]欄に「Cubeの追加」などと入力して、[Commit]

プルリクエストを実行します。

  • GitHub Desktop の[Pull request]をクリック f:id:am1tanaka:20170202234904p:plain
  • [from master into ・・・]の部分が[master]としか表示されていなかったら、[master]をクリックして、[Other branches]の下に表示されているリポジトリーを選択する
  • Title 欄と Description 欄に、相手に伝えたいコメントがあれば入力する。特になければそのままでよい
  • [Send pull request]をクリック

以上で、プルリクエストを発行することができました。Webブラウザーで自分の練習用リポジトリーを開いて、プルリクエストが届くのを待ってください。

プルリクエストをダウンロードする

自分が管理している GitHub リポジトリーにプルリクエストが届いたら、プルリクエストされたリポジトリーを手元のPCにダウンロードして、動作確認をしましょう。

  • WebブラウザーGitHub を開いてログイン
  • 管理しているリポジトリーを開く
  • プルリクエスト(Pull Requests)タブをクリック f:id:am1tanaka:20170204233414p:plain
  • リストが表示されるので、確かめたいプルリクエストを選択
  • [open this in GitHub Desktop]のリンクをクリック f:id:am1tanaka:20170204233437p:plain

クリックしてから、実際に実行されるまでしばらく時間がかかる場合があります。反応がなくても、1分程度は待ってください。

GitHub Desktop が起動して、ブランチが[pr/23]のように表示されれば成功です。プルリクエストされたプロジェクトを確認できます。

プルリクエストされた状態を確認

プルリクエストされた状態の動作を確認します。

  • 画面左のリポジトリーを右クリック
  • [Open in Explorer]を選択して、クローンしたフォルダーを確認
  • Unityを起動
  • [Open]を選択して、クローンしたフォルダーを選択して開く

プロジェクトが開いたら、実行して、動作を確認します。

変更されたファイルを確認する

何が変更されたかは把握しておく必要があります。GitHub Desktop で簡単に確認ができます。

  • [History]をクリック
  • コミットのリストが表示されるので、確認したいコミットをクリック
  • 画面右に、変更があったファイルの一覧が表示される
  • [+]をクリックすると、中身が確認できる。問題点がないかを確認する f:id:am1tanaka:20170204233634p:plain

問題点を報告

動作確認や、変更されたファイルをチェックして、不具合があったり、コードがよくなかったりした場合、修正して欲しい箇所をプルリクエストした人に知らせて修正をお願いします。

  • Webブラウザーでプルリクエストのタブを開く
  • マージ欄の下の [Leave a comment] 欄に、伝えたいコメントを書いて、[Comment]ボタンを押す f:id:am1tanaka:20170204233733p:plain

これを、受け入れができる状態になるまで繰り返します。

変更を受け入れる

プルリクエストの内容に問題がなくなったら、最新の master ブランチに結合(マージ)します。

マージする時にファイルに変更があってはいけません。自分で修正したことがあればコミットをします。

変更を取り消す操作

変更した覚えがないのに、変更があったら以下の操作で変更を取り消すことができます。

  • GitHub Desktop の[Changes]を選択 > 取り消したい変更を右クリック > [Discard changes]を選択 f:id:am1tanaka:20170204234049p:plain

以上で、前回コミットした状態に戻すことができます。

マージ

変更点がなくなったら、 master ブランチに、プルリクエストの内容を取り込みます。手順が逆にならないように注意してください。

  • GitHub Desktop のブランチをクリックして、[pr/??]ブランチを[master]に切り替える f:id:am1tanaka:20170204233857p:plain
  • [Compare]をクリックして、[pr/??]に切り替える
  • [Update from pr/??]をクリック

以上で完了です。ブランチの方向を間違えたり、失敗したら、一度クローンしたフォルダーを削除して、プルリクエストの内容をクローンするところからやり直すと楽です。

GitHubへ反映させる

何も起きなければ、GitHub Desktop で [Publish]、或いは[Sync]を押して、 GitHub へ反映させれば完了です。

Issues を閉じる

Pull Request が Issues で報告されている内容を解決するものであったら、その Issues を閉じましょう。

  • GitHub Desktop の左からリポジトリーを右クリックして、 [View on GitHub]を選択して、WebブラウザーGitHub を開く
  • [Issues]をクリック
  • 一覧表示の中から、処理した Issues をクリック
  • コメントがあれば [Leave a comment] 欄に入力する。なければ空欄でよい
  • [Close issue]を押す f:id:am1tanaka:20170204234149p:plain

以上で、Issue がクロースされて、リストから非表示になります。[Issues]タブをクリックして、Issue リストを表示すると、閉じた項目は表示されなくなります。 [Closed]をクリックすると、閉じた Issue を見ることができます。


コンフリクトさえ発生しなければ、ここまで OK です。ここからは、コンフリクトが発生した時に備えての演習を紹介します。

コンフリクト解決の練習

master ブランチに何事もなくマージできればよいのですが、同時に同じ場所を編集した場合、コンフリクト(Conflict=衝突)が発生します。これの解決が、共同開発する時の最大の難題です。コンフリクトが発生した時の対応方法を練習しましょう。プルリクエストの練習で利用したリポジトリーで引き続き作業をしましょう。

プロジェクトを開く

  • Unity に切り替える
  • [File]メニューから、[Open Project]を選択
  • 自分が作成した AdminRensyu プロジェクトフォルダーを選択して開く

コンフリクトを仕込む

コンフリクトは、同じ場所に変更を加えることで発生します。ブランチを2つ作成して、それぞれで Test スクリプトの同じ場所に違う変更を加えることでコンフリクトさせましょう。

  • GitHub Desktop で [Create new branch] を押す
  • [conflict1]などの名前を入力して、[Create new branch]で新しいブランチを作成
  • ブランチを[master]に戻す
  • 同様に、[conflict2]というブランチを作成
conflict2の作業

まずは、conflict2 ブランチに変更を加えます。以下、Unityで作業します。

  • [Cube]の X 座標を -1 にする
  • [Project]ビューの[Test]スクリプトをダブルクリックして、エディターで開く
  • 以下のコードにする
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class Test : MonoBehaviour {

    // Update is called once per frame
    void Update () {
        Vector3 next = transform.position;
        next.x+=1f*Time.deltaTime;
        transform.position = next;
    }
}
  • 上書き保存して、Unityに切り替える
  • [File]メニューから[Save Scene]を選択
  • [File]メニューから[Save Project]を選択

実行すると、キューブが右に移動します。これをコミットします。

  • GitHub Desktop に切り替える
  • [Summary]欄に、「座標の変更と右へ移動」と入力
  • [Commit to conflict2]をクリック
conflict1の作業

コミットが完了したら、conflict1 に切り替えて、同じ場所に別の変更を加えます。

  • GitHub Desktop で、ブランチを[conflict1]に切り替える
  • Unityに切り替える
  • リロードの確認ウィンドウが表示されるので、[Reload]を押す
  • [Project]ビューから[Test]シーンをダブルクリック

これで、master からブランチを作成した時点に戻ります。別の変更を加えます。

  • [Hierarchy]ビューから[Cube]を選択
  • X座標を 1 に変更
  • [Project]ビューの[Test]スクリプトをダブルクリックする
  • 起動したら、スクリプトを以下のようにする
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class Test : MonoBehaviour {

    // Update is called once per frame
    void Update () {
        Quaternion now = transform.rotation;
        Quaternion rot = Quaternion.AngleAxis(90f*Time.deltaTime, Vector3.up);
        rot = rot*now;
        transform.rotation = rot;
    }
}
  • 上書き保存して、Unityに切り替える
  • [File]メニューから[Save Scene]を選択
  • [File]メニューから[Save Project]を選択

実行すると、キューブが回転します。これをコミットします。

  • GitHub Desktop に切り替える
  • [Summary]欄に、「座標の変更と回転」と入力
  • [Commit to conflict1]をクリック

コンフリクトを発生させる

conflict1 ブランチと conflict2 ブランチを master ブランチにマージして、コンフリクトを発生させます。

  • GitHub Desktop に切り替え
  • [master] ブランチに切り替える
  • [Unity]に切り替えて、ビルドされるのを待ち、ウィンドウが表示されたら[Reload]ボタンを押す
  • GitHub Desktop に戻る
  • [Compare]をクリックして、[conflict1]を選択
  • [Update from comflict1]ボタンを押す
  • [Unity]に切り替えて、ビルドされるのを待ち、ウィンドウが表示されたら[Reload]ボタンを押す

これで、 master ブランチに conflict1 ブランチがマージされます。master は conflict1 を実装開始する時から変更されていないので、コンフリクトは起きません。実行すると conflict1 の内容である Cube の回転が見られます。

次に、 conflict2 ブランチをマージします。

  • GitHub Desktop に切り替える
  • [conflict1]をクリックして、[conflict2]に切り替える f:id:am1tanaka:20170204234752p:plain
  • [Update from conflict2]をクリック
ここでコンフリクトが発生します(Unable to merge=マージできません)!

[View conflicts]を選択して、コンフリクトを表示します。 f:id:am1tanaka:20170204234822p:plain

コンフリクトが発生した一覧が表示されて、右に[!]マークが表示されます。今回は2つのファイルが該当します。これを全て解決します。 f:id:am1tanaka:20170204234833p:plain

コンフリクトを解決する

衝突している部分は、「<<<<<<< HEAD」「=======」「>>>>>>> <ブランチ名>」の3つの記号の行で示されます。

  • 「<<<<<<< HEAD」から「=======」の間は、現在のコード
  • 「=======」から「>>>>>>> <ブランチ名>」の間は、マージしようとしているコード

いずれか一方を残すか、あるいは両方残して、3つの記号の行を削除することで、コンフリクトを解決することができます。まずは、Test.csから解決します。

Test.csを解決

Test.cs には、移動と回転のコードが追加されています。これは、両方とも採用することにします。その場合は、区切りの記号行を削除するだけで解決します。

  • Unity の [Project]ビューで[Test]スクリプトをダブルクリックして、エディターで開く
  • 記号の行を3つとも削除して、以下のようにする
using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class Test : MonoBehaviour {

    // Update is called once per frame
    void Update () {
        Quaternion now = transform.rotation;
        Quaternion rot = Quaternion.AngleAxis(90f*Time.deltaTime, Vector3.up);
        rot = rot*now;
        transform.rotation = rot;

        Vector3 next = transform.position;
        next.x+=1f*Time.deltaTime;
        transform.position = next;
    }
}
  • 上書き保存する

以上で、 Test.cs の衝突は解決しました。まだ、衝突が残っているので、 Unity に切り替えてもエラーになります。衝突は、全て解決する必要があります。

Test.unityを解決

Unityでバージョン管理をする時の最大の困難は、[.unity]ファイルのような Unity の設定ファイルが衝突した時です。今回は、 Cube オブジェクトの座標に関する設定がコンフリクトしました。プレハブなどでも同じように発生します。

設定ファイルの場合、項目ごとに1つのパラメータになるはずなので、 Test.cs でやったように両方残すことは有り得ません。衝突した変更をした担当者に何を変更したかを聞き取り、どちらか一方の変更を採用するようにします。

今回は、 conflict2 の方を採用することにします。

  • [Unity]に切り替える
  • リロードのダイアログが表示されたら、[Reload]をクリック
  • [Project]ビューから[Test.cs]などを右クリックして、[Show in Explorer]でプロジェクトフォルダーを開く
  • 該当ファイル(ここでは Test.unity )を右クリックして、Atom などのテキストエディターで開く
  • GitHub Desktop で Test.unity を選択すると、変更箇所が表示されるので、行番号を確認する
  • 変更点を、以下のように修正する
    • 変更前
<<<<<<< HEAD
  m_LocalPosition: {x: 1, y: 0, z: 0}
=======
  m_LocalPosition: {x: -1, y: 0, z: 0}
>>>>>>> refs/heads/conflict2
  • 変更後
  m_LocalPosition: {x: -1, y: 0, z: 0}
  • 上書き保存して、 Unity に切り替える
  • ダイアログが表示されたら[Reload]をクリック

以上で全ての衝突が解決しました。 Unity が実行できるようになるので実行してください。座標はやや左から(conflict2の座標)、回転しながら右に移動します。

解決した内容をコミットする

衝突を解決したら、コミットします。

  • Unityで[File]から[Save Scene]、[File]から[Save Project]を実行して、保存する
  • GitHub Desktop に切り替える
  • 衝突しているファイルはチェックが外れているので、チェックを入れる f:id:am1tanaka:20170204235127p:plain
  • 必要であれば、 Summary や Description を書き換える。そのままでよければそのままでよい
  • [Commit to master]をクリック

以上で解決です。

まとめ

簡単なプルリクエストへの最小限の対処方法をまとめました。コンフリクトが発生すると、面倒になることが確認できたと思います。適切にファイルを分割して、作業担当を割り振れば、コンフリクトは減らすことができます。色々と試してみてください。

コンフリクトが発生したら、衝突場所を示す記号の行がテキストファイルに挿入されます。そのままではプログラムは動かなくなるので、残したいコードを残し、不要なコードを削除しながら、記号の行を削除します。

コンフリクトで厄介なのは、 Unity が管理している設定ファイルが衝突した時でした。その場合は、どちらか一方を採用することにして、一方の変更を削除するようにするとよいでしょう。

ここで紹介したことに加えて、書式をチェックする Linter ツールや、自動的テストを導入すると、さらに開発がしやすくなります。手順が飲み込めたら、そのような自動化ツールも調べてみましょう。

色々とややこしいですし、ここに書いてあるのはごく初歩的な部分だけです。実際にやってみると、様々なことが発生することでしょう。それらを沢山体験しておくと、今後に活きてきます。早速、自分たちでプロジェクトを立ち上げて、共同開発に挑戦してみてください。

参考URL

GitHubでみんなで開発2016年度版

(リポジトリー管理者向け記事はこちら)

複数メンバーでの開発は、コードの更新タイミングなどで様々なトラブルが発生しますし、完全な自動化はできません。慣れるまでは失敗はつきものですし、面倒に感じる部分もありますが、避けて通ることはできません。基本的な流れを覚えて、失敗しながら使い始めてみましょう。




利用するもの

基本的には、GitHubリポジトリーを操作する公式アプリのGitHub Desktop(f:id:am1tanaka:20170125215602p:plain)を利用します。

最初のプロジェクトをクローンする段階で、インターネット上の GitHub ページを利用します。


Gitはどうしてややこしいのか

「状態の異なるバージョンのファイルががあちこちにあるから」

図1は、GitHubで開発する時のリポジトリーの様子です。
f:id:am1tanaka:20170202134153p:plain
図1 GitHubリポジトリ
(パソコンのイラスト:かわいいフリー素材集 いらすとやより)

①オリジナルリポジトリ

プログラムの本家本元となるリポジトリーです。管理権限があるメンバーが管理していて、管理権限がない人が勝手に内容を書き換えることはできません。

②フォークされたリポジトリ

オリジナルリポジトリーをコピーしたリポジトリーです。あるリポジトリーを、自分のアカウントのGitHubにコピーすることをフォーク(Fork)といいます。フォークしたリポジトリーは、各ユーザーのアカウントのGitHubに複製されたものなので、自由に内容を変更することができます。

プルリクエスト(Pull Request)をすることで、このリポジトリーで行った開発内容を、オリジナルリポジトリーに反映する提案が行えます。

③ローカルのリポジトリ

開発をGitHub上で行うのは不便なので、手元のPCにリポジトリーをダウンロードして操作します。GitHubから手元のPCにリポジトリーをダウンロードすることをクローン(Clone)といいます。

ローカルで変更を加えたら、コミット(Commit)をして、ローカルPCのリポジトリーを更新します。その上で、プッシュ(Push)、GitHub Desktopではシンクロ(Sync)操作をすることで、フォークされたリポジトリーにその変更内容がアップロードされます。

リポジトリーのまとめ

リポジトリーは、オリジナルのもの、各ユーザーのGitHubアカウントにフォークされたもの、ローカルPCにクローンされたものがあります。それぞれが個別に存在するので、混乱のもとになりやすいです。自分が今操作しているリポジトリーがどれなのかを考えながら操作しましょう。

リポジトリーが密接に同期されないことは混乱の元なのですが、そのメリットは絶大です。管理者でなければ、オリジナルのリポジトリーを変更することはできません。フォークしたものは失敗を恐れずに自由に変更してよいということです。失敗したら、自分のリポジトリーを削除して、オリジナルからフォークをし直せばやり直せるのです。この気軽さが Git の素晴らしさです。


リポジトリーのフォーク

みんなで開発する手始めに、オリジナルのリポジトリーを自分のアカウントにフォークしましょう。

  • http://github.com を新しいタブで開いて、自分のアカウントでログインする
  • ログインが完了したWebブラウザーで新しいタブを開いて、開発に参加したいアカウントのリポジトリーを開く
  • 右上の方にある [Fork] ボタンを押す

f:id:am1tanaka:20170125230237p:plain

フォークが完了したら、リポジトリーページの左上を確認してください。[自分のアカウント / リポジトリー名]となっています。その下に小さい文字で[forked from]とあり、続けてオリジナルのリポジトリーへのリンクが記載されています。
f:id:am1tanaka:20170125230641p:plain

自分のアカウントにフォークしたリポジトリーができました。これをローカルPCにクローンして開発をしていきます。


フォークしたリポジトリーをクローンする

手元のPCで開発できるように、フォークしたリポジトリーをクローンします。

  • GitHub Desktop(f:id:am1tanaka:20170125215602p:plain)を起動
  • ログインしていなければ、ログインする(右上の歯車アイコンをクリックして、[Options...]を選択。Accounts にアカウントが表示されていなければ、アカウント名とパスワードを入力してログインする)
  • 左上の[+]をクリック > [Clone]をクリック > [Filter repositories]欄に、クローンしたいリポジトリー名を入力 > 表示されるリポジトリーを選択 > [Clone <プロジェクト名>をクリック

f:id:am1tanaka:20170125231054p:plain

  • 作業したい場所を指定する。特別なことがなければ、そのままの場所で[OK]でよい

以上で、手元のPCにリポジトリーがダウンロードされました。これで開発を行います。


開発作業

開発の流れを体験してみます。README.md ファイルに、自分の学籍番号と名前を追加する作業をしてみます。

ブランチ(Branch)とは

Gitなどのバージョン管理システムは、様々な状態のリポジトリーを扱うためのブランチ(Branch)という機能を持っています。詳しくは専門書やインターネット上の記事に譲りまして、ここでは基本的な方針を述べます。

  • master ブランチは、常に動作する状態を維持する
  • 開発は、一言で書き表せる程度の目標に分割して、そのためのブランチを作成して、そこで行う
  • 開発が完了したら、オリジナルリポジトリーの master ブランチ(dev ブランチなどの他のブランチにプルリクエストするようなルールがあればそれに従う)に、プルリクエストを発行する
  • プルリクエストは、完成しない状態で送ってもよい。開発者とディスカッションをしながら機能の完成をしていくことができる
  • 機能の実装が完了して、プルリクエストがオリジナルに組み込まれた開発用のブランチは、そのまま放置でよい

master ブランチは、いつでもそこから別の開発が始められるように、バグが無い状態を保ちます。そのためには、 master ブランチ上で開発することは得策ではありません。開発用のブランチを作成して、そこで開発をすることで、 master ブランチは常に動作する状態を保てます。

ブランチを作成する

ブランチは、 GitHub Desktop で簡単に作成できます。それでは名前を追加するためのブランチということで[add-name]というブランチを作成します。

  • GitHub Desktopの[Create new branch]ボタンを押す

f:id:am1tanaka:20170202231537p:plain

  • Name欄に[add-name]と入力して、[Create new branch]を押す
  • ブランチ名が[add-name]に切り替わっていればOK

f:id:am1tanaka:20170202231852p:plain

これで作業用フォルダーの中身が add-name ブランチに切り替わりました。

プロジェクトを変更する

開発用のブランチ[add-name]に切り替わりましたので、作業を行います。

  • GitHub Desktop で、作業したいリポジトリーをクリックして選択
  • 右上の[Atom]ボタンを押す(Atom以外のエディターを利用する場合は、クローンしたフォルダーの README.md をファイルから開く)

f:id:am1tanaka:20170202235007p:plain

  • 適当な場所に、学籍番号と氏名を入力
# yoketoru-unity-2016
2016年度版よけとるUnity for Unity5.5

# メンバーリスト
- 00 たなかゆう
  • 書き込みが終わったら、上書き保存する

以上でこの作業は完了です。次の手順に進みます。

コミット(Commit)とプッシュ(Push/Publish/Sync)

ファイルなどを変更したら、コミットをしてリポジトリーに変更内容を記録します。

  • GitHub Desktop に切り替える
  • (1)[Changes]を押す > (2)[Summary]欄に変更内容を書く(「学籍番号と名前を追加」など) > (3)[Commit to add-name]を押す > (4)[Publish]を押す(2回目以降は[Sync])

f:id:am1tanaka:20170202233113p:plain

以上で、ローカルPCのリポジトリーに変更が記録され、その内容がフォークしたリポジトリーに反映されます。ここまでをワンセットで操作するとよいでしょう。

コミットをすると、その後、いつでもその状態に戻すことができます。コミットは小まめに行うようにしましょう。

ブランチの動作を確認する

コミットが完了したら、ブランチを切り替えることができます。 master ブランチに切り替えて、 README.md がどうなるか確認してみましょう。

  • GitHub Desktop の [add-name]の部分をクリックして、[Default branch]の[master]に切り替える

f:id:am1tanaka:20170202231852p:plain

  • Atom エディターなどで、 README.md を確認する

以下のように、先ほどの変更が消えています。

# yoketoru-unity-2016
2016年度版よけとるUnity for Unity5.5

# メンバーリスト

同様の操作で add-name ブランチに戻してから README.md を確認してください。学籍番号と名前が復活します。ブランチごとに、違う状態が保持されているのです。

ブランチの下に表示される[Other branches]欄には、オリジナルのリポジトリーが表示されています。これを選べば、オリジナルの状態を参照することもできます。
f:id:am1tanaka:20170202234203p:plain

コミットしていない変更があるとブランチは切り替えられません。ブランチを切り替える前にはコミットするようにしてください。

プルリクエスト(Pull Request)

変更が完了したら、オリジナルのリポジトリーに反映してもらうためにプルリクエストをします。

  • GitHub Desktop の右上の[Pull request]を押す

f:id:am1tanaka:20170202234904p:plain

  • 必要であればタイトルを変更。Descriptionに簡単な修正内容を記載。テストや確認点があれば追記して、[Send pull request]を押す

f:id:am1tanaka:20170202235406p:plain

完了したら、[Pull request created]と表示されます。その下の[View it on GitHub]をクリックすると、Webブラウザーが開いて、オリジナルリポジトリーに送られたプルリクエストを見ることができます。

f:id:am1tanaka:20170202235839p:plain

このページで管理者と相談をしたり、駄目な場所があれば指摘されるので、それを持ち帰って改変します。

変更した内容をコミットしてSyncすると、プルリクエストにも自動的に反映します。一度プルリクエストを発行したら、それ以降は、普通に開発をして、コミットしてSyncして開発を進めればよいのです。

完了

管理者がプルリクエストをオリジナルのリポジトリーにマージ(Merge)して組み込まれれば作業完了です。これを繰り返していくことで、複数人数で、一つのプロジェクトを開発していくことができます。


次の開発をする

作業者が自分だけであればよいのですが、複数いる場合は、オリジナルのリポジトリーには他の人の変更も加わっていきます。その変更をローカルのリポジトリーに反映させる方法です。

  • ローカルブランチを[Default branch]の[master]に切り替える
  • [Compere]をクリックして、[Other branches]のオリジナルリポジトリーを選択

f:id:am1tanaka:20170203000918p:plain

  • [Update from <オリジナルのアカウント>/master]をクリック

f:id:am1tanaka:20170203001047p:plain

以上で、オリジナルのリポジトリーの master ブランチの状態を、ローカルリポジトリーの master に反映させました。 README.md を見れば、自分が行っていない変更があれば、それが加わっていることが確認できます。

あとは、また開発用のブランチを新しく作成して、そこで開発→コミット→Sync→プルリクエスト のサイクルで開発してください。


まとめ

以上で、開発者として開発に参加する流れは最低限押さえました。簡単なプロジェクトで作成をしてみましょう。

管理者を引き受ける場合は、ここでやったものの他に、プルリクエストの受け入れと、別々の人たちが同じ場所を変更した時に発生する衝突=コンフリクト(Conflict)の解決が必要になりますが、それはまた別の機会に。

以下、開発時のTipsをおさらいしておきます。

  • オリジナルのリポジトリーから、自分のアカウントにリポジトリーをフォークして開発を開始
  • 自分のアカウントから、開発するPC上にリポジトリをクローンする
  • master ブランチ上では直接開発しない
  • 開発時には、一言で表せる程度の規模の目標を立てて、ブランチを作成
  • コミットとSyncは小まめに
  • プルリクエストは早めに行ってよい
  • 完了したら、オリジナルリポジトリーの管理者によって、プルリクエストがオリジナルリポジトリーにマージされる
  • 最新状態は、 Compare からオリジナルのリポジトリーを選んで、 Update する

困った時は

手元のリポジトリーを削除して、フォークやクローンし直そう。

ブランチの単位は

以下のように、一言で書き表せる程度にしましょう。

  • 得点アイテムを追加する
  • 敵の弾を追加する
  • プレイヤーのバグを直す

コミットはもっと小まめにしましょう。

リポジトリー管理者向けの記事を、こちらにアップしました。


GitHub Pagesのマークダウンにテーマを設定する

はじめに

GitHubの機能の一つである GitHub Pages を使えば、無料で自分のWebサイトや作品のWebサイトをインターネット上で公開することができます。マークダウンで書かれたファイルは自動的にHTMLに変換して表示します。とても便利ですが、デフォルトのスタイルはものすごく質素です(図1)。

f:id:am1tanaka:20170201180641p:plain:h200
(図1)デフォルトのGitHub Pages

GitHub Pages は Jekyll というツールを使ってマークダウンファイルをHTMLに変換していて、あらかじめいくつかのテーマが組み込まれています。それを適用すれば見た目を改善することができます。




方針

方針は以下の2点です。

  • 作品を作成しているリポジトリーとWebページを共存させる(Webページ専用のリポジトリーは作らない)
  • GitHub Page用のデータは master ブランチの docs フォルダーに入れる



前提

以下の環境を前提とします。



GitHub Pages用のフォルダーの作成

プロジェクトフォルダーに docs フォルダーを作成して、GitHubにプッシュします。

  • GitHub Desktop(f:id:am1tanaka:20170125215602p:plain) を起動
  • 作業したいリポジトリーを右クリックして、[Show in Explorer]を選択してエクスプローラーで開く
    • 作業手順を確認したいだけで、作品がない場合は、GitHub Desktop で新しいプロジェクトを作成して、上記の作業をしてください
  • 開いたフォルダーに docs という名前のフォルダーを新規に作成
  • README.md をコピーして、 docs フォルダー内に貼り付ける
  • GitHub Desktop に切り替える
  • 表示を[Changes]に変更
  • [Summary]欄に[docsフォルダーを追加]などのように入力
  • [Commit to master]を押す
  • 右上の[Sync]を押す

以上で、 GitHub Pages 用のフォルダーができました。


GitHubでページの設定

フォルダーができたので、GitHub Pagesをそのフォルダーに割り当てます。

f:id:am1tanaka:20170201182344p:plain
図3 Settings

  • 画面を下にスクロールさせて [GitHub Pages]の欄を表示
  • Source 欄のコンボボックスをクリック > [master branch /docs folder]を選択 > [Save]ボタンを押す(図4)

f:id:am1tanaka:20170201182552p:plain
図4 GitHub Pagesを docs フォルダーに設定

GitHub Pages の設定をした欄の下に表示するための URL が表示される(図5)ので、そこをクリックしてください。ビルドが完了し次第(1分程度かかる可能性があります)、 README.md が成形されて表示されます(図6)。
f:id:am1tanaka:20170201183804p:plain
図5 作品ページのURL

f:id:am1tanaka:20170201211851p:plain
図6 最初のGitHub Pages


テーマを適用

簡素な画面に、組み込みテーマを適用します。

f:id:am1tanaka:20170201212255p:plain
図7 Change Themeボタン

  • 採用したテーマをクリックする
    • クリックすると、そのテーマでの描画イメージがページの下に表示されるので、確認してください
  • 画面右の[Select Theme]をクリックする(図8)

f:id:am1tanaka:20170201213024p:plain
図8 Select Theme

  • デフォルトのマークダウンが表示されるので、ひとまず画面下の[Commit Changes]をクリック(図9)

f:id:am1tanaka:20170201213239p:plain
図9 Commit Changes

以上で適用完了です。作品の GitHub Pages を再読み込みしてください。マークダウンの使い方が記されたページが、選択したテーマで表示されます(図10)。
f:id:am1tanaka:20170201213449p:plain
図10 テーマが適用されたページ


ページ内容を構築する

テーマの設定ができたので、あとはページの内容を作品のものに書き換えます。

ページに必要な画像や素材の準備

作品の紹介に使う画像ファイルや、UnityのWebGLをビルドしたフォルダーを、 docs フォルダーにコピーします。たとえば、以下のような構成にします。

  • docs/images フォルダー内に img0.png と img1.png
  • docs/webgl フォルダー内に Unity でビルドした WebGL のプロジェクト

ページを作成

作品ページをマークダウンで作成します。

  • GitHub Desktop に切り替える
  • 画面右上の[Sync]を押して、GitHub の更新を取得
  • Atom などのエディターで、作品フォルダー内の docs/README.md を開く
  • あらかじめ入力されているマークダウンの例は不要なので削除
  • 作品の紹介マークダウンを入力する。以下、例
# 正月休み課題「鶏Bomb2017」
ver 170108
<p>
<a href="webgl/index.html" target="_blank">
<img src="images/img0.png" height="240px" alt="タイトル画面">
<img src="images/img1.png" height="240px" alt="ゲーム画面">
<p>ゲームで遊ぶ</p>
</a>
</p>

# ルール
画面の上から卵が降ってきます。これを爆風で孵化させてください。

卵が下に落ちて割れたらゲームオーバーです。

# 操作方法
- 画面をタップした場所に爆弾が置かれます
- 爆弾は一定時間が経過すると爆発します
- 爆風で卵を孵してください
- 爆風に触れた爆弾も、爆発します

# 高得点のヒント
- 卵は画面下で孵化させるほど高得点です
- 一つの爆風で、複数の卵を孵すと得点が増えます
- 誘爆させた爆風で孵化させると、得点が増えます

# 既知のバグ
まだ開発中のため、バグがあります。

バグの確認や報告は[こちら](https://github.com/tanakaedu/ToriBomb2017/issues)へどうぞ。

---
Copyright(C)2017 YuTanaka
  • 上書き保存する
  • GitHub Desktop に切り替える
  • [Changes]に切り替えて、 [Summary]に「ドキュメントの作成」などと入力して[Commit to master]を押す
  • 右上の[Sync]を押す

以上で完了です。作品ページを再読み込みしてください。適用したテーマで、作品ページが表示されるようになります。変更が反映するまでに1分程度かかる可能性がありますので、変更が確認できない場合は、しばらく待ってから再読み込みをしてみてください。


ページの上段の変更

一度設定したレイアウトは、 [Settings]メニューから別のテーマを選択すれば切り替えることができます。切り替わるのに1分程度かかる場合があるので、設定したらしばらく待ってください。

ページの先頭は、リポジトリー名とリポジトリーの Description が自動的に挿入されます(図11)。
f:id:am1tanaka:20170201220508p:plain
図11 ページの先頭部分

Description を変更したい場合は、以下のようにします。

  • リポジトリーページを開いて、 Description の右の [Edit]をクリック

f:id:am1tanaka:20170201220955p:plain

  • テキストボックスの内容を変更して、右の[Save]を押す

以上だけでは、ページは更新されないようです。再構築をするには、Settingsから一度別のテーマを設定してから、元のテーマに設定しなおしてください。


まとめ

以上で、デフォルトの状態よりも見た目がよいページにすることができます。似合うテーマを色々と試してみてください。

以下、作例です。


ここでのやり方は、GitHubに予め用意された定型のテーマやレイアウトでの利用にとどまります。自由に見た目を変更したい場合は、 Jekyll というWebサイト生成ツールを利用します。英語ですが、手順が紹介されているページがこちらにあります。興味があれば、調べてみてください。


Hexo3について私見

ある程度、使い方を把握しました。結論としては、肌に合わないので利用は見合わせることにします。

以下、問題に感じた点です。

アセットフォルダーの仕様が整理されていない

アセットデータへのパスの指定方法が整理されていません。結果的に、Markdownで普通に画像を表示させることができません。{% %}を使った特殊な表記で解決することは可能ですが、基本中の基本の機能なだけに、他にやり方はなかったのかと思います。


加工しないページの指定方法が不明

source フォルダーに入っているマークダウンや HTML は、強制的にテーマの形式に変更されます。そのため、Unity で出力した WebGL 用のページをそのまま表示するなどができません。実行もできません。これは最初の問題と関連していて、 JavaScript などへのリンクが切れてしまっているためと思われます。

デプロイを個別にやるとか、あるいは何らかの書き方があるかもしれませんが、そもそも強制的にすべてのページをビルドするという仕様が乱暴に感じました。


まとめ

いったんHexoはあきらめて、Jekyll を改めて調査します。Jekyll も同様な場合は戻ってくるかも知れませんが、ひとまず現段階では Hexo の採用は見送ります。

HexoのインストールとGitHub Pageへデプロイ

GitHubで公開しているアプリなど用のWebページを、Hexoで作成する手順です。Webページとアプリでリポジトリを共有できるように、Hexoは gh-pages ブランチにデプロイします。



前提

  • VirtualBox にインストールされている Ubuntu で作業する前提です。
  • VitualBox と Ubuntu はインストール済みとします。



Ubuntuの起動

まずは、 VirtualBoxUbuntu を起動します。

  • VirtualBoxを起動
  • Ubuntuのプロジェクトを選択して、[起動]を押す

以上で、起動するまで待ちます。

画面サイズが大きくて不便な場合は、以下を先にやっておきます。

VirtualBoxのUbuntuの画面サイズを調整する - tanaka's Programming Memo


nodeのインストール

  • Ubuntu の画面左上の[コンピュータを検索]アイコンをクリック
  • [te]ぐらいまで入力すると[端末]が見つかるので、クリック

以下を参考に、nodeの最新版を Ubuntu にインストールします。
Ubuntuに最新のNode.jsを難なくインストールする - Qiita

apt-getなど、処理が開始するまで数分かかることがあるので、コマンドを入力して、エラーが表示されていなければ、動きがあるまで焦らず待ってください。

最後、以下で不要なパッケージを削除します。

sudo apt autoremove

グローバル環境を以下で更新しておきます。

sudo npm update -g

以上ができたら、あらためて node -v と npm -v を実行して、バージョンが表示されることを確認して完了です。


Hexoのインストール

以下を参考に、インストールします。
Hexo

sudo npm install hexo-cli -g



Gitのインストール

Gitが必要なので、以下でインストールします。

sudo apt-get install git-core

インストールが完了したら、 Git にデフォルトのメールアドレスと名前の設定をしますので、以下のように端末で実行します。以下の例の「メールアドレス」の部分に連絡用のメールアドレス、「EntryName」のところにGitにコミットするときに表示する名前に差し替えます。

git config --global user.email "メールアドレス"
git config --global user.name "EntryName"



SSHGitHubに接続できるようにする

安全な通信をするために、秘密鍵と公開鍵を作成します。ユーザーディレクトリ内の .ssh フォルダー内に作成しますが、最初はフォルダーが無いので、ターミナルから以下で作成しておきます。

mkdir ~/.ssh

途中で必要になるファイル内容をクリップボードにコピーする xsel というプログラムを以下でインストールしておきます。

sudo apt-get install xsel 

以下を参考に、SSHGitHubに接続できるように設定してください。そのままで成功しない部分があるので、下の注意点も確認してください。

gitHubでssh接続する手順~公開鍵・秘密鍵の生成から~ - Qiita

  • パスフレーズなどは、説明通りで省略してかまわない
  • キーの生成が完了したら、UbuntuFirefox を起動して、指定のURLを入力して、GitHubを開いて、ログイン
  • 画面右上のボタンの表示は、[Add SSH key]から[New SSH key]に変更されているので、[New SSH key]を押す
  • 公開鍵名は[dat-ubuntu]など
  • ターミナルで、以下を実行して、公開鍵の文字列をクリップボードにコピー
cat ./id_rsa.pub | xsel --clipboard --input
  • Firefoxに戻して、[Key]欄に貼り付ける
  • 左下の [Add SSH key] ボタンを押す

以上で完了です。ターミナルで以下を実行して、 GitHub への接続を試みます。

ssh -T git@github.com

最初の一回目は警告が表示されるので、[yes]を入力して[Enter]キーを押して確認します。

「Hi <GitHubのアカウント名>」が表示されれば成功です。これ以降は、SSHで自分のアカウントに接続ができるようになります。


ブログを作成する

公式ページの Get Started に沿って、簡単なブログを作成してみます。

  • 以下で、ブログ用のフォルダーを作成して、その中に移動する
cd ~
mkdir blogs
cd blogs
  • 以下で、ブログを作成して、その中に入る
hexo init test-blog
cd test-blog
  • 初回は、必要なパッケージのインストールが必要なので、以下を実行
npm install
npm install hexo-deployer-git --save
  • ブログサーバーを起動する。WARNINGが出ても気にしなくてよい
hexo server

以上で、hexoのブログサーバーが起動します。UbuntuFirefox で、 http://localhost:4000 を開いて、ブログページを確認してください。


GitHub Pagesへの導入

GitHubのアップロード先のリポジトリーを準備

アップロード用のリポジトリーがなければ以下の手順で作成します。すでにある場合は、そのページを UbuntuFirefox で開いてリポジトリーのSSH文字列のコピーへ進みます。

  • UbuntuFirefoxGitHub を開いて、ログイン
  • 右上の[+]アイコンをクリックして、[New repository]を選択してリポジトリーを作成
  • Repository nameに「hexo-test」などを入力
  • [Initialize this repository with a README]にチェックを入れる
  • あとはそのままで[Create repository]を押す

リポジトリーのSSH文字列のコピー

アップロード先の設定のために、以下の操作でこのリポジトリーを指定する文字列をコピーしておきます。

  • UbuntuFirefox上で、作成したリポジトリーページの右にある[Clone or download]ボタンを押す
  • 右に表示される[Use SSH]のリンクをクリック
  • [git@github.com:・・・]と表示されるテキストボックスの右のコピーアイコンをクリック

何も起きませんが、これでコピーが完了しているので、続けて以下の作業に進んでください。

ブログの設定

ブログの情報や、URL、GitHub Pagesに Hexo で生成したブログをアップロードするための情報など、各種情報は、_config.yml というファイルに設定します。

ブログの基本設定

まずはブログの基本情報を編集します。

  • Ubuntu の左上の[コンピューターを検索]アイコンをクリック
  • [te]が入力されていると、[テキストエディター]も検索されるので、それをクリックして起動
  • [開く]を押して、[他のドキュメント]>[blogs]>[test-blog]>[_config.yml]を選択して開く
  • 以下の設定を自分の環境の合わせて変更する
    • title ブログのタイトル
    • subtitle ブログにサブタイトルがあれば入力。省略可
    • description ブログの説明。省略可
    • author ブログの著者名。自分の名前やハンドル名に変更
    • language 日本語の場合、 ja としておく
    • timezone 時差の設定。日本だと Asia/Tokyo にする

以下、例です。

title: Hexoの練習
subtitle:
description:
author: たなかゆう
language: ja
timezone: Asia/Tokyo
公開先URLの設定

公開先のURLを設定します。

  • [# URL]から始まる行(16行目付近)を探して、その下の url と root を、公開先の URL とパスに変更。例えば、 tanakaedu という GitHub アカウントで、 hexo-test というリポジトリーで公開する場合は以下の通り
url: https://tanakaedu.github.io/hexo-test
root: /hexo-test/
デプロイ設定

続けて、以下を参考に GitHub への公開設定をします。
Deployment | Hexo

  • [# Deployment]という行を探して(一番下)、GitHubの情報を入力
# Deployment
## Docs: https://hexo.io/docs/deployment.html
deploy:
  type: git
  repo: (ここに貼り付けをして、GitHubでコピーした文字列を張り付ける。例) git@github.com:アカウント/リポジトリー名.git)
  branch: gh-pages
cd ~/blogs/test-blog
hexo deploy -g

以上で、「INFO Deploy done: git」と表示されれば、アップロード完了です。GitHubにアップロードされましたので、確認は Ubuntu でも、ホストPCでもどちらでも可能です。

https://<アカウント名>.github.io/hexo-test

にアクセスします。アカウント名のところは、自分のアカウント名に差し替えてください。たとえば以下のようなURLになります。

https://tanakaedu.github.io/hexo-test

Hexo のインストール後に localhost:4000 で確認したのと同じページが表示されていれば成功です。


まとめ

以上で設定完了です。これ以降は、 Hexo の使い方に従ってデザインを導入して、記事を作成したら hexo deploy -g でデプロイすればページが更新されます。


VirtualBoxのUbuntuの画面サイズを調整する

画面サイズを変更

画面の解像度が低いPCで動かす場合、画面が収まらないと操作が不便なので、画面サイズを調整します。

高さ720pxのモニターで表示できるようにします。

以下を参考に解像度の設定をインストールします。

virtualbox 上の ubuntu の解像度 ( 画面サイズ ) 変更方法 - Opensourcetechブログ(ZeusITCamp裏BLOG)

再起動が完了したら、左の[CD]のイメージを右クリックして、[取り出し]で取り出します。その後、以下で解像度を変更します。

  • 画面左下の[設定]ボタンを押す
  • [ディスプレイ]をクリック
  • 解像度欄を適したサイズに変更。高さ720pxの場合、1280x720(16:9)か、800x600(4:3)
  • [適用]を押して、[この設定のままにする]を押す

[表示]メニューから[フルスクリーンモード]を選択すると、全画面をUbuntuで利用できます。