Google Apps Script（GAS）を試す

無料で簡単にWebアプリが公開できるGoogle Apps Scriptなるものがあると聞いて試してみました。

Google Apps Script を追加する

まずはGoogleドライブにアクセスします。

新規 > その他 > アプリを追加 を選択し、「script」で検索します。Google Apps Scriptが出てくるので追加し、ファイルを新規作成します。

GASプロジェクトを作成する

新規作成すると、無題のプロジェクトに「コード.gs」が表示されているはずです。 が、メニューのヘルプ > 開始画面 と選択し、左ペイン下部のウェブアプリケーションを選択します。

すると、以下の４ファイルがすでに生成されています。

• コード.gs
• Index.html
• JavaScript.html
• Styleshiit.html

コード.gs がサーバー側処理、それ以外が View になります。 JavaScriptとCSSがhtmlファイルになっているのが気になるかもしれませんが、 GASでは現状このような形でしかJavaScriptとCSSを分離することができません・・・。

プロジェクト名を適当に変えてください。とりあえず「Sample Project」としてみます。

Webアプリケーションを公開する

メニューから 公開 > ウェブアプリケーションとして導入 を選択します。

以下を選択して「導入」ボタンを押しましょう。 承認が必要です、というダイアログが出たら確認して承認してください。

• プロジェクトバージョン： 新規作成
• 次のユーザーとしてアプリケーションを実行： 自分
• アプリケーションにアクセスできるユーザー： 全員（匿名ユーザーを含む）

なんとこれだけでWebアプリケーションが公開できます！ 「現在のウェブアプリケーションのURL」が公開したWebアプリケーションのエンドポイントになります。

ちなみにURLをそのままブラウザにコピー&ペーストすると、自分のGoogleドライブのルート階層のファイル一覧が表示されるはずです。

URLパラメータにfolderIdを指定すると、Googleドライブにある特定のフォルダ直下のファイル一覧が見れるようになります。 folderIdというのは、Googleドライブ内のフォルダにアクセスした時のURL末尾についているランダムな文字列のことです。

例) https ://drive.google.com/drive/folders/XXXXXXX ←このXXXXXXXの部分です。

URLパラメータの指定方法ですが、アプリケーションのURLが「https ://example/hogehoge/」だとすると、以下のように末尾に指定します。

例) https ://example/hogehoge/?folderId=XXXXXXX

簡単にコードの解説

コード.gs 内の doGet 関数がアプリケーションのエンドポイントです。

HtmlService.createTemplateFromFile('Index') で、Index.html からViewを生成して返していますね。 そのあとのif文でリクエストのパラメータをチェックして、folderIdがなければ”root”に設定しています。

function doGet(e) {
  var template = HtmlService.createTemplateFromFile('Index');

  // Retrieve and process any URL parameters, as necessary.
  if (e.parameter.folderId) {
    template.folderId = e.parameter.folderId;
  } else {
    template.folderId = 'root';
  }

  // Build and return HTML in IFRAME sandbox mode.
  return template.evaluate()
      .setTitle('Web App Window Title')
      .setSandboxMode(HtmlService.SandboxMode.IFRAME);
}

getFolderContents 関数でGoogleドライブにアクセスしています。

DriveApp.getRootFolder()とDriveApp.getFolderById(folderId)で、フォルダの情報をごそっと取得しています。 で、そこからフォルダ名やら子要素を取り出しているわけです。

function getFolderContents(folderId) {
  var topFolder;
  var contents = {
      children: []
  };

  if (folderId == 'root') {
    topFolder = DriveApp.getRootFolder();
  } else {
    // May throw exception if the folderId is invalid or app
    // doesn't have permission to access.
    topFolder = DriveApp.getFolderById(folderId);
  }
  contents.rootName = topFolder.getName() + '/';

  var files = topFolder.getFiles();
  var numFiles = 0;
  while (files.hasNext() && numFiles < 20) {
   var file = files.next();
   contents.children.push(file.getName());
   numFiles++;
  }

  return contents;
}

この getFolderContents 関数を呼び出しているのが、JavaScript.html 内の無名関数です。

リクエスト失敗時と成功時のコールバックが含まれているのでやや複雑になっていますが、 google.script.run.getFolderContents(folderId)だけでも呼び出すことが可能です。

リクエスト成功時は、updateDisplay 関数でレスポンスから必要な情報を取り出してDOMに挿入しています。

  $(function() {
    // Call the server here to retrieve any information needed to build the page.
    google.script.run
       .withSuccessHandler(function(contents) {
            // Respond to success conditions here.
            updateDisplay(contents);
          })
       .withFailureHandler(function(msg) {
            // Respond to failure conditions here.
            $('#main-heading').text(msg);
            $('#main-heading').addClass("error");
            $('#error-message').show();
          })
       .getFolderContents(folderId);
  });
  ...
  function updateDisplay(contents) {
    var headingText = "Displaying contents for " + contents.rootName + " folder:";
    $('#main-heading').text(headingText);
    for (var i = 0; i < contents.children.length; i++) {
      var name = contents.children[i];
      $('#results').append('<div>' + name + '</div>');
    }
  }

まとめ

ざっくりとした説明ですが、とりあえずここまで。いろいろと制限はあると思いますが、無料でこれだけ簡単に個人でWebアプリを公開できるのはすごいことですよね。

HTMLによる View の生成、JavaScriptによるサーバー処理の呼び出しとUIの更新、Googleドライブとの連携と開発に必要なエッセンスが詰まっていると思います。

あとは公式のドキュメントを見ながら修正していくだけで、それなりのものが作れるでしょう。

公式ドキュメント： https://developers.google.com/apps-script/overview

ちなみに、メニューの 公開 > ウェブアプリケーションとして導入 からテスト用のURLも取得できます。 修正をした後はテスト用のURLで確認が可能ですし、もちろん第三者に公開しているURLには修正内容は見えません。

修正が済んで新しいバージョンとして公開したいときは、プロジェクトバージョンから新規作成を選んで「更新」ボタンを押してください。公開用URLに修正が反映されます。

次はこれを元にオリジナルアプリを作る予定。

Effective Javaを勉強します【第3章】

Objectクラスのequals、hashCode、toString、clone、finalizeはすべて オーバーライドされるように設計されているため、明示的な一般契約がある。

これに従わないと、この契約に依存しているHashMapやHashSetなど他のクラスが 適切に機能しない恐れがあるため、いつ、どのようにオーバーライドすべきか学びましょうと いう話。 （ComparableはObjectではないが同様の特徴をもつため、本章で扱う）

項目8. equalsをオーバーライドする時は一般契約に従う

equals()をオーバーライドすべきでない場合

以下の条件のいずれかに当てはまる場合は、equals()をオーバーライドしない方が適切。

• クラスの個々のインスタンスは本質的に一意である
  • Threadなどのように、値よりは能動的な実態を表しているクラスの場合
  • Objectクラスの提供するequals()の振る舞いが正しい
    • Objectの提供するequals()の実装は以下になってる。参照が同じである＝等しいと判断される。

public boolean equals(Object obj) {
    return (this == obj);
}

• 「論理的等価性」検査をクラスが提供するかどうかに関心がない

  • 例えばRandomインスタンスがこれから同じ乱数列を生成するか検査をする必要はない
  • この場合もObjectの提供するequals()の振る舞いが正しい

• スーパークラスがすでにequalsをオーバーライドしており、スーパークラスの振る舞いがこのクラスに対して適切である

  • 例えばSetならAbstractSet、ListならAbstractList、MapならAbstractMap

• クラスがprivateあるいはパッケージプライベートであり、そのequalsメソッドが決して呼び出されないことが確かである

  • 万が一呼び出された場合に備えて、以下のように例外をスローするようオーバーライドする

@Override public boolean equals (Object obj) {
    throw new AssertionError();
}

equals()をオーバーライドすべき場合

クラスが論理的等価性という概念を持っていて、スーパークラスがequals()をオーバーライドしていないとき。

• 論理的等価性＝論理的に同値であるのかを知りたい
  • オブジェクトの同一性（参照先が同じ）を確かめたいのではなく、持つ値が正しいのかを知りたい

equalsをオーバーライドする時は、以下の一般契約を厳守しなければならない

反射性

nullでない任意の参照値xに対して、x.equals(x)はtrueを返さなければならない。

• オブジェクトがそれ自身と等しくなければならないということ
• これを意図的に破ることは難しい

対称性

nullでない任意の参照値xとyに対して、y.equals(x)がtrueを返す場合のみ、x.equals(y)はtrueを返さなければならない。

以下の例のように簡単に破ることが可能なので注意。

public class CaseInsensitiveString {
    private final String s;
    public CaseInsensitiveString(String s) {
        if (s == null) {
            throw new NullPointerException();
        }
        this.s = s;
    }

    // 間違った例
    @Override
    public boolean equals(Object o) {
        if (o instanceof CaseInsensitiveString)
            return s.equalsIgnoreCase(((CaseInsensitiveString) o).s);
        if (o instanceof String)
            // 引数がStringの場合、大文字小文字を無視して比較しているが
            // Stringクラスでは無視しないため対称性が成り立たない
            return s.equalsIgnoreCase((String) o);
        return false;
    }

    // 正しい例
    @Override
    public boolean equals(Object o) {
        // クラスが異なる場合はfalseを返すのが正解（Stringは比較しない）
        return o instanceof CaseInsensitiveString &&
            ((CaseInsensitiveString) o).s.equalsIgnoreCase(s);
    }
}

推移性

nullでない任意の参照値x、y、zに対して、x.equals(y)とy.equals(z)がtrueを返すなら、x.equals(z)はtrueを返さなければならない。

• インスタンス化可能なあるクラスを拡張して、equals契約を守ったまま値要素を追加したサブクラスを実装する方法はないので注意
  • あるクラスに値要素を追加したい時は、継承ではなくコンポジションを用いるべきである（項目16）

例) ２次元座標を保持したPointクラスと、Pointクラスを継承して色情報を付加したColorPointというサブクラスを考える。

 // スーパークラス
public class Point {
    private final int x;
    private final int y;
    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }

    @Override
    public boolean equals(Object o) {
        if (!(o instanceof Point)) {
            return false;
        }
        Point p = (Point) o;
        return p.x == this.x && p.y == this.y;
    }
}

// サブクラス
public class ColorPoint extends Point {
    private Color color;
    public ColorPoint(int x, int y, Color color) {
        super(x, y);
        this.color = color;
    }
}

このときColorPointクラスでequalsをオーバーライドしなければ、ColorPointのequals比較では色情報が無視されてしまうため、 色情報も一致したときにtrueを返すよう以下のように実装することを考える。

// ColorPointの誤ったequals()の例1
// 対称性が守られていない
@Override
public boolean equals(Object o) {
    if (!(o instanceof ColorPoint)) {
        return false;
    }
    return super.equals(o) && ((ColorPoint) o).color == color;
}

これは以下のように比較を行った場合、対称性が守られないため不適切。

Point p = new Point(1, 2);
ColorPoint cp = new ColorPoint(1, 2, Color.RED);
p.equals(cp); // => true(色情報が無視される)
cp.equals(p); // => false

cp.equals(p)がtrueを返すよう、以下のようにColorPointクラスとPointクラスの比較の際は色情報を無視するよう実装すると、推移性が守られない。

// ColorPointの誤ったequals()の例1
// 推移性が守られていない
@Override
public boolean equals(Object o) {
    if (!(o instanceof Point)) {
        return false;
    }
    // oがPointクラスの場合は、Pointクラスのequals()で色情報を無視した比較を行う
    if (!(o instanceof ColorPoint)) {
        return o.equals(this);
    }
    return super.equals(o) && ((ColorPoint) o).color == color;
}

これは以下のように比較を行った場合、推移性が守られないため不適切。

ColorPoint p1 = new ColorPoint(1, 2, Color.RED);
Point p2 = new Point(1, 2);
ColorPoint p3 = new ColorPoint(1, 2, Color.BLUE);
p1.equals(p2); // => true
p2.equals(p3); // => true
p1.equals(p3); // => false

以下のようにコンポジションを用いることで、equals契約を守ったままPointクラスに色情報を付加できる。 （ColorPointクラスはPointのサブクラスではないためcp.equals(p)もp.equals(cp)もfalseになる）

public class ColorPoint {
    private Point point;
    private Color color;
    public ColorPoint(int x, int y, Color color) {
        if (color == null) {
            throw new NullPointerException();
        }
        point = new Point(x, y);
        this.color = color;
    }
    // ビューを返す
    public Point asPoint() {
        return point;
    }
    @Override
    public boolean equals(Object o) {
        if (!(o instanceof ColorPoint)) {
            return false;
        }
        ColorPoint cp = (ColorPoint) o;
        return cp.point.equals(point) && cp.color.equals(color);
    }
}

ただし抽象クラスのサブクラスには、equals契約を守ったまま値要素の追加が可能。 （スーパークラスはインスタンス化されないため、サブクラスと比較されて推移性に違反することがないため）

整合性

nullでない任意の参照値xとyに対して、オブジェクトに対するequals比較に使用される情報が変更されなければ、 x.equals(y)は常に同じ値を返し続けなければならない。

• 信頼できない資源に依存するequalsメソッドを書いてはならない
  • 例) java.net.URLのequalsメソッドは、比較対象URLに関連づけられたホストのIPに依存している
    • ホストをIPに変換する時ネットワークへのアクセスが必要であり、常に同じ結果が保証されないため不適切
  • メモリ中のオブジェクトのみに依存する処理を行うべき

非null性

nullでない任意の参照値xに対して、x.equals(null)はfalseを返さなければならない。

• nullが渡されたときにNullPointerExceptionがスローされるのは契約違反なので注意（falseを返すようにする）

高品質なequalsメソッドの書き方

1. 引数が自分自身のオブェクトであるかどうかを検査する場合は == を利用する
2. 引数が正しい型であるかを調べるためには instanceof を使う。
   • 正しい型とは、普通はメソッドが定義されているクラスである。場合によっては、このクラスによって実装されているインターフェース。
3. 引数を正しい型にキャストする
4. そのインスタンスのフィールドと、与えられたオブジェクトのフィールドを検査する
   • 基本データ型には==を、オブジェクトには再帰的にequalsを用いる
   • ただし、floatとdoubleにはFloat.compareとDouble.compareを利用する。
   • 配列のフィールドはArray.equalsが利用できる。
5. 「対称性」、「推移性」、「整合性」の性質を満たしたかどうかのテストを書く
   • 「反射性」と「非 null 性」は心配しなくても大抵の場合満たされる。

項目9. equalsをオーバーライドする時は、常にhashCodeをオーバライドする

equalsをオーバーライドしているすべてのクラスで、hashCodeをオーバーライドしなければならない。

• 上記を守っていないクラスがHashmap、HashSet、Hashtableを含む、すべてのハッシュに基づくコレクションで用いられると適切に機能しない

守らなければならない契約は以下。

1. equals比較で使用されるオブジェクトの情報が変更されない限り、hashCodeメソッドは同じオブジェクトに対して常に同じ整数を返さなければならない
2. 2つのオブジェクトがequals比較により等しければ、２つのオブジェクトの個々に体するhashCodeメソッド呼び出しは、同じ整数を返さなければならない
3. ２つのオブジェクトがequals比較により等しくない場合、２つのオブジェクトの個々に体するhashCodeメソッド呼び出しが別の整数を返さなければならない、ということは要求されない。しかし別の整数を返す場合、ハッシュテーブルのパフォーマンスが改善される可能性がある。

hashCodeをオーバーライドするのを忘れた場合、上記２が破られる。

例) hashCodeをオーバーライドしていないPhoneNumberClass

public class PhoneNumber {
    private final short areaCode;
    private final short prefix;
    private final short lineNumber;

    public PhoneNumber(int areaCode, int prefix, int lineNumber) {
        rangeCheck(areaCode, 999, "areaCode");
        rangeCheck(prefix, 999, "prefix");
        rangeCheck(lineNumber, 9999, "line number");
        this.areaCode = (short) areaCode;
        this.prefix = (short) prefix;
        this.lineNumber = (short) lineNumber;
    }

    private static void rangeCheck(int arg, int max, String name) {
        if (arg < 0 || max < arg) {
            throw new IllegalArgumentException(name + ": " + arg);
        }
    }

    @Override
    public boolean equals(Object o) {
        if (o == this)
            return true;
        if (!(o instanceof PhoneNumber))
            return false;

        PhoneNumber phoneNumber = (PhoneNumber) o;
        return phoneNumber.lineNumber == this.lineNumber
                && phoneNumber.prefix == prefix
                && phoneNumber.areaCode == areaCode;
    }

    // hashCode がない！
}

putとgetで利用される２つのPhoneNumberクラスのハッシュコードが一致しないため、下記のようにHashMapが正しく動作しない。

Map<PhoneNumber, String> m = new HashMap<PhoneNumber, String>();
m.put(new PhoneNumber(707, 867, 5309), "Jenny");
m.get(new PhoneNumber(707, 867, 5309)); // => null

以下の手順に従うことで、理想的なハッシュ関数を計算することが可能。

• 何らかのゼロでない定数、例えば 17 をresultという int 変数に保存する。
• オブジェクト内のequalsメソッドで考慮されるフィールドfに対して以下のことを行う。
  • 各フィールドに対する intのハッシュコードcを計算する。
    1. boolean ならば、(f ? 0: 1)を計算する。
    2. byte, char, short, int ならば(int) fを計算する。
    3. long ならば、(int)(field ^ (f >>> 32))を計算する。
    4. float ならば、Float.floatToIntBits(f)を計算する。
    5. double ならばDouble.doublToLongBits(f)を計算し、結果の long を6と同様にハッシュする。
    6. オブジェクト参照で、equals内でフィールドをequalsの再帰的呼び出しによって比較しているならば、再帰的にhashCodeを呼び出す。フィールドがnullなら0を返す。
    7. 配列ならば各要素を別々のフィールドとして取り扱い、各意味のある要素に対して再帰的にこれらの規則を適用してハッシュを計算する。要素全てに意味がある場合、Arrays.hashCodeメソッドの利用が可能。
  • 上記で計算したcをresult = 31 * result + c;の式に代入する。
• resultを返す。
• 等しいインスタンスが等しいハッシュコードを持つかどうかを自問し、単体テストを書く。

もしクラスが不変でハッシュコードを計算するコストが高いならば、オブジェクト内にハッシュコードをキャッシュしておくことを検討すべきである。

もしそのクラスのオブジェクトのほとんどがハッシュキーとして利用される場合、以下のいずれかの対策をすべきである。

• インスタンス生成時にハッシュコードを計算する
• 最初にhashCodeが呼び出された時に、遅延初期化をする（項目71）

項目10. toStringを常にオーバーライドする

toStringメソッドのデフォルト実装は、"クラス名@ハッシュコードの符号なし16進数表現"の文字列を返す。

→ 分かりづらいので、オーバーライドしてオブジェクトに含まれる有益な（ユーザーが興味があるであろう）情報を全て返すようにすべき。

toStringをオーバーライドする時に考慮すべき点として以下が挙げられる。

• ドキュメンテーション（javadoc）で戻り値の形式を明示するかどうか
  • 明示することでユーザーに正確な表現形式を伝えることができる
  • 一方で、明示した表現形式に依存した利用がされている可能性を考えると、その後の仕様変更がしづらくなるというデメリットもある
• 明示する、しないに関わらず、その意図は正確にjavadocに記載すべき
• toStringの戻り値に含まれる全ての情報への、プログラミングによるアクセス手段を提供すべき

項目11. cloneを注意してオーバーライドする

cloneの一般契約は以下の通り。

• 「コピー」の正確な意味はオブジェクトのクラスに依存する
• 大まかな意図は以下が成り立つことだが、絶対的な要件ではない
  • 任意のオブジェクト x に対してx.clone() != xが true であること
  • またx.clone().getClass() == x.getClass()も true であること
  • x.clone().equals(x)が true であること
  • そのクラスの新たなインスタンスを生成することに加え、内部データ構造のコピーも必要な場合がある
  • コンストラクタは呼び出されない

cloneメソッドをオーバーライドするならば、super.cloneにより得られたオブジェクトを返すべき

以下の例を考える。

public class Data1 implements Cloneable {
    ...
    @Override
    public Object clone() throws CloneNotSupportedException {
        return new Data1(x);
    }
    ...
}
 
public class Data2 extends Data1 {
    ...
    @Override
    public Object clone() throws CloneNotSupportedException {
        return super.clone();
    }
    ...
}

上記の場合、Data2.cloneを呼び出すとsuper.cloneによりData1のコンストラクタが返却される。 したがって「x.clone().getClass() == x.getClass()も true であること」が成り立たない。 これはData1クラスでも同様に、cloneでsuper.cloneを返すようにすることで解決する。

また上記でcloneメソッドのアクセス修飾子が public となっていることも大切である。 本書に書いてある通り、Cloneableを実装しているクラスは、適切に機能している public のcloneメソッドを提供することが期待されている。

これらを踏まえて、java1.5からは下記のようにcloneメソッドを修正することができる。

public class Data1 implements Cloneable {
    ...
    @Override
    public Data1 clone() {
        try {
            return (Data1)super.clone();
        } catch(CloneNotSupportedException e) {
            throw new AssertionError();
        }
    }
    ...
}
 
public class Data2 extends Data1 {
    ...
    @Override
    public Data2 clone() {
        try {
            return (Data2)super.clone();
        } catch(CloneNotSupportedException e) {
            throw new AssertionError();
        }
    }
    ...
}

上記の修正したcloneメソッドにおいて、注目すべき点が３点ある。

• 修正したcloneの戻り値型がData1/Data2になっている
  • java1.5から導入された共変戻り値型によるもの（オーバーライドしたメソッドの戻り値型は元のメソッドの戻り値型のサブタイプであってもよい）
• super.cloneの戻り値は親クラスであるため、キャストを忘れずに行う（キャストはクライアントでなくライブラリーですべき処理）
• CloneNotSupportedExceptionのスロー宣言が削除されている
  • チェックされる例外をスローしない方が使い勝手が良い（publicのcloneメソッドはスローしないべき）
  • 継承されることを想定したクラスでcloneをオーバーライドする場合、cloneを protected と宣言し、CloneNotSupportedExceptionのスロー宣言をし、Cloneableは実装しないようにする（Object.cloneをまねるべき）

フィールドに可変オブジェクトが含まれる場合は、再帰的にcloneを呼び出す

下記の例を考える。

public class Stack {
    private Object[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;
    
    public Stack() {
        this.elements = new Object[DEFAULT_INITIAL_CAPACITY];
    }
    @Override
    public Stack clone() {
        try {
            Stack result = (Stack) super.clone();
            result.elements = elements.clone();
            return result;
        } catch (CloneNotSupportedException e) {
            throw new AssertionError();
        }
    }
    ...
}

上記のcloneメソッド内のsuper.cloneでは、elementsフィールドの参照がコピーされるだけである。 （浅いコピー。元のオブジェクトとcloneオブジェクトで同一の配列が共有されてしまう。） したがってelements.clone()のように、再帰的にcloneを呼び出す必要がある。

しかしelementsフィールドがfinalの場合、新たな値を代入することができないため正しく機能しない。 この場合は、フィールドのfinal修飾子を取り除く必要がある。（cloneのアーキテクチャは可変オブジェクトを参照している final のフィールドと両立しない）

内部クラスを保持するなど、クラスの構造が複雑な場合、上記のように再帰的にcloneを呼び出すだけでは不十分な場合もある。 その時はsuper.cloneを呼び出し、返されたオブジェクトのすべてのフィールドを初期化した上で、オブジェクトの状態を再現するために 「深いコピー」を実現するための処理を呼び出すべき。

一般的に、クラスが基本データ型のフィールドか不変オブジェクトへの参照しか保持していない場合、上記のような「深いコピー」のための処理は不要。

cloneが本当に必要かよく検討する

これまで述べたようにcloneの実装は気をつけるべき点が多く複雑であり、本当に必要なケースは稀である。 （配列のコピー用途以外ではcloneを利用しないという人も多い）

以下のいずれかの手段で代替できないかよく検討する。

• コピーコンストラクタかコピーファクトリーを提供する java public Yum(Yum yum); //コピーコンストラクタ public static Yum newInstance(Yum yum); //コピーファクトリー
• そもそもオブジェクトの複製機能を提供しない

項目12. Comparableの実装を検討する

Comparableを実装することで、インスタンスが自然な順序を持っていることを明示する。

→アルファベット順、数値順、年代順など、明らかに自然な順序を持つ値クラスを書く場合、Comparableを実装しcompareToメソッドを提供する。

compareToメソッドの一般契約は以下。これを守らないと、compareToに依存しているTreeSetやTreeMap、検索とソートアルゴリズムを含む CollectionsやArraysが正しく機能しない。

（sgn(expression)は、expressionが負の場合 -1、ゼロの場合 0、正の場合 1を返す関数）

• すべての x と y に関してsgn(x.compareTo(y)) == -sgn(y.compareTo(x))を保証しなければならない
  • x.compareTo(y)が例外をスローする（ y のクラスは x と比較できない）場合のみ、y.compareTo(x)は例外をスローしなければならない
• (x.compareTo(y) > 0 && y.compareTo(z) > 0)がtrueならばx.compareTo(z) > 0もtrueでなければならない
• すべての z に関してx.compareTo(y) == 0ならばsgn(x.compareTo(z)) == sgn(y.compareTo(z))でなければならない
• (x.compareTo(y) == 0) == x.equals(y)は強く推奨されるが必須ではない（破る場合は明示すべき）

上記制限はequals制限と同じく、反射性、対称性、推移性に従わなければならないことを示している。 したがってequalsと同様に、インスタンス化可能なクラスを拡張してcompareTo契約を守ったまま新たな値要素を追加する方法はなく、コンポジションが推奨される。

compareToは以下にしたがって実装すると良い。

• 基本データ型フィールドは関係演算子>と<で比較する
• 浮動小数点の比較ではDouble.compareかFloat.compareを使用する
• 配列は個々の要素に対して上記を適用する
• 比較するフィールドが複数ある場合、最も意味のあるフィールドから順に比較を行う
  • 例えば電話番号の場合、市外局番を先に比較すれば、残りの番号の比較が不要となる可能性がある

Effective Javaを勉強します【第2章】

入社3年目になりましたが、全然Javaの基礎できてないなと思いまして、 effective javaの学習を始めました。まず第1章から。

項目1. コンストラクタの代わりにstaticファクトリーメソッドを検討する

staticファクトリーメソッドとは

クラスのインスタンスを返す単なるstaticのメソッド。

• 例) 基本データ型booleanに対応するボクシングされた基本データクラスBooleanを返す
  • ボクシング：基本データ型の変数をそのラッパークラスのインスタンスに変換（逆はアンボクシング）

public static Boolean valueOf(boolean b) {
    return b ? Boolean.TRUE : Boolean.FALSE;
}

長所

コンストラクタと異なり名前を持つ

同じシグニチャを持つコンストラクタが複数必要な時は、シグニチャの順番を変えるしかない。

• Hoge(int num, String str)とHoge(String str, int num)
  • 外部からはコードが何をしているのか分からない
• Hoge.methodA(int num, String str)とHoge.methodB(int num, String str)
  • メソッド名で内部処理の違いを区別できる

メソッドが呼び出されるごとに新たなオブジェクトを生成する必要がない

あらかじめメンバーとして生成しておいたインスタンスや、オブジェクト生成時にキャッシュしておいたインスタンスを返すことで 不必要に重複したオブジェクトの生成を回避可能。

→オブジェクト生成のコストが高く、かつ頻繁に要求される場合は、パフォーマンスの大幅な向上につながる

• 例) Boolean.valueOf(boolean)メソッド
• Flyweight(フライ級)パターンと似ている（同じ？）
  • 等価なインスタンスを別々の箇所で使用する際に、一つのインスタンスを再利用することで省リソース化を図る
• 不必要なインスタンス化を防ぐ = 「インスタンス制御されている」状態にする
  • シングルトンやインスタンス化不可能を保証できる

メソッドの戻り値型の任意のサブタイプのオブジェクトを返却可能

• staticファクトリーメソッドの戻り値型を、とか抽象インタフェースとかにする
• 上記メソッドから返すクラスの実装を内部クラスとして持つ
  • 実装の隠蔽が可能
  • 複数のクラスを返却可能なので、柔軟なAPIの設計が可能になる

// java.util.Collectionsの抜粋
...
public class Collections {
    // インスタンス化不可能
    private Collections {
    ...
    // staticファクトリ〜メソッド
    public static <K,V> Map<K,V> More ...unmodifiableMap(Map<? extends K, ? extends V> m) {
        return new UnmodifiableMap<K,V>(m);
    }
    // 返却するクラスの実装
    private static class More ...UnmodifiableMap<K,V> implements Map<K,V>, Serializable {
}

パラメータ化された型のインスタンス生成の面倒さを低減する

Java７からはダイヤモンド構文が導入されたので、おそらく解決した

// ダイヤモンド構文
Map<String, List<String>> m = newHasMap<>();

以前は以下。

// 冗長で面倒
Map<String, List<String>> m = newHasMap<String, List<String>>();

public static <K, V> HashMap<K, V> newInstance() {
    return new HashMap<K, V>();
}
// 簡潔になる
Map<String, List<String>> m = HashMap.newInstance();

短所

publicあるいはprotectedのコンストラクタを持たないクラスのサブクラスを作れない

• インスタンス化不可能なクラスはstaticファクトリーメソッドから返すことができないため
  • コンポジションを利用する（項目１６で説明）

容易に他のstaticメソッドと区別がつかない

• コンストラクタほど目立たない（その他のメソッドと同列扱い）
  • valueOfなどstaticファクトリーメソッドでよく利用される命名法に従うことで軽減する

項目2. 数多くのコンストラクタパラメータに直面した時にはビルダーを検討する

数多くのコンストラクタパラメータが必要な時、実現方法としては以下の３つが考えられるが、 読みやすさ、書きやすさ、安全性の観点からビルダーパターンを検討すべきである。

• テレスコーピングコンストラクタ・パターン
• JavaBeansパターン
• ビルダーパターン

テレスコーピングコンストラクタ・パターン

いくつかの必須パラメータとn個のオプションパラメータが存在する時 以下のように複数のコンストラクタをオーバーロードする。

• 必須パラメータだけを受け取るコンストラクタ
• 必須パラメータ＋0個のオプションパラメータを受け取るコンストラクタ
• 必須パラメータ＋1個のオプションパラメータを受け取るコンストラクタ
• …
• 必須パラメータ＋n個のオプションパラメータを受け取るコンストラクタ

上記のうち、設定したいパラメータを全て含む最も短いパラメータリストを持つ コンストラクタを利用していくことになるが、大抵不要なパラメータも含まれることになる。

→可読性の低下、パラメータの順序を間違える恐れ

JavaBeansパターン

パラメータなしのコンストラクタを呼び出し、その後必要なパラメータと対応したセッターを呼び出し パラメータを設定する。

→生成が複数の呼び出しに分割されるので、その生成過程の途中で不整合な状態にある恐れ

ビルダーパターン

1. 対象のオブジェクトを直接生成する代わりに、必須パラメータをすべてもつビルダーオブジェクトを生成する。
   • ビルダーは生成するクラスのstaticメンバークラス
2. オプションパラメータはビルダーオブジェクトの持つセッターのようなメソッドから追加する。
3. ビルダーオブジェクトの持つbuild()メソッドから生成するクラスのコンストラクタを呼び出し、対象のオブジェクトを生成する。

// 例： Member member = new Member.Builder("Taro").age(25).build();
public class Member {
    private final String name;
    private final int age;
    public static class Builder {
        private final String name; //必須パラメータ
        private int age = 20; //オプションパラメータはデフォルト値で初期化
        public Builder(String name) {
            this.name = name;
        }
        public Builder age(int age) {
            this.age = age;
            return this;
        }
        public Member build() {
            return new Member(this);
        }
    }
    private Member(Builder builder) {
        this.name = Builder.name;
        this.age = Builder.age;
    }
}

欠点

• オブジェクト生成時に必ずビルダーオブジェクトの生成が必要
  • シビアなパフォーマンスが要求される場合は注意する
• テレスコーピングコンストラクタ・パターンより長くなりがち
  • 例えばパラメータ数４以上など、パラメータが多い場合にだけ利用すべき
  • 途中からビルダーパターンへ変更は難しいため、将来的にパラメータが増えそうな場合は 最初からビルダーパターンを検討すべき

項目3. privateのコンストラクタかenum型でシングルトンを強制する

シングルトンとは

一度しかインスタンスが作成されないクラス

→コード中の同じクラスのインスタンスは全て同一であることが保証される

実現方法1：privateなコンストラクタ + finalのフィールド (+ staticファクトリーメソッド)

以下ではfinalのフィールド初期化時にのみ、コンストラクタが呼び出される

public class Elvis {
    public static final Elvis INSTANCE = new Elvis();
    private Elvis() { ... }
    ...
}

または、staticファクトリーメソッドから返す。

public class Elvis {
    private static final Elvis INSTANCE = new Elvis();
    private Elvis() { ... }
    public static Elvis getInstance { return INSTANCE; }
    ...
}

上記はAccessibleObject.setAccessibleメソッドを使用して、リフレクションにより privateなコンストラクタを呼び出すことが可能。

• コンストラクタを修正して２つ目のインスタンス生成時は例外を返すなどして回避

また、シリアライズ可能にする場合、ディシリアライズ毎に新たなインスタンスが生成されることを防ぐために 次のメソッドを追加する。

private Object readResolve() throws ObjectStreamException {
    // ディシリアライズ時にINSTANCEを返却して、重複生成を防ぐ
    return INSTANCE;
}

リフレクションとは

「実行時にプログラム自身の情報を取得／振る舞いを変更する」仕組み。 （リフレクションがどうしても必要なケースがいまいち分からない）

Class cl = Class.forName("Foo"); //オブジェクト取得
Method method = cl.getMethod("hello"); //メソッド取得
method.invoke(cl.newInstance()); //メソッド実行

• JPCERTのセキュアコーディングスタンダードには 「リフレクションを使ってクラス、メソッド、フィールドのアクセス範囲を広げない」という項目がある

実現方法2：Enum

実現方法１よりこちらを選ぶべき。

• 記述が簡潔
• シリアライズ機構を持つ
• シリアライズ攻撃やリフレクション攻撃に対して鉄壁な保証

public enum Elvis {
    INSTANCE;
    ...
}

項目4. privateのコンストラクタでインスタンス化不可能を強制する

1つの明示的なprivateなコンストラクタを含むことでインスタンス化を防ぐ。

• 明示的にコンストラクタを書かないと、コンパイラによりデフォルトコンストラクタが 追加されてしまう
  • この方法だとサブクラスもインスタンス化不可能になる

public class UtilityClass {
    private UtilityClass() {
        throw new AssertionError();
    }
    ...
}

項目5. 不必要なオブジェクトの生成を避ける

機能的に同じオブジェクトが必要なときは、1つのオブジェクトを再利用するほうが大抵適切である。

極端にだめな例

String s = new String("stringette") //bad
String s = "stringette"

bad:

“stringette"自体がStringオブジェクトであり、Stringコンストラクタで生成されるオブジェクトと同等

→二重にオブジェクトが生成されてしまう

good:

言語仕様上、同じ内容の文字列リテラルで生成されるインスタンスは再利用することが保証されている。（同一JVM上のみ）

→"stringette"は一度しか生成されず、再利用される

不変クラスの再利用

• staticファクトリーメソッドを利用すれば大抵、不必要なオブジェクト生成は回避可能
  • 例) Boolean.valeOf(String)

変更されない可変オブジェクトの再利用

• static初期化子で回避可能
  • 例) 本文中例のDate/Calender/TimeZoneインスタンス

オートボクシングに注意

オートボクシングにより、基本データ型が自動で対応するラッパークラスに変換される

→不要なオブジェクトが増える可能性

Long sum = 0L;
for (long i = 0; i <= Integer.MAX_VALUE; i++) {
    sum += i; //iがLong型にオートボクシングされる
}

防御的コピーは別

何でも再利用すればよいわけではない。 防御的コピーが求められる場合、オブジェクトの再利用が悪質なバグやセキュリティホールにつながる可能性があるので注意。（項目39）

項目6. 廃れたオブジェクト参照を取り除く

廃れた参照

今後それを通してオブジェクトが参照されることのない単なる参照

• 本文中の例ではelements配列のsize外にある要素

→いらなくなったらnullを代入することで、スタックの利用クライアントで参照がなくなればGCされるようになる - 参照が間違っている場合、NullPointerExceptionでエラーを伝えることもできる

メモリリークを気をつけるべきとき

とにかくnullを入れればよいわけではない。廃れた参照に対する最善の方法は、参照が含まれていた変数を スコープの外に出すこと。

以下のような場合にメモリリークを注意すべき。

• クラスが独自のメモリを管理しているとき
  • 本文中コードだとStackのelements
• キャッシュ機構をもつとき
  • WeakHashMapでキャッシュを表現するのが望ましい
    • エントリーが廃れると（キーへの外部からの参照がなくなると）自動的に取り除かれる
• リスナーやコールバックを持つクラス
  • キャッシュと同じくWeakHashMapで解決可能

項目7. ファイナライザを避ける

ファイナライザは予測不可能で、大抵危険であり、一般には必要ない

• JPCERTのセキュアコーディングスタンダードには 「ファイナライザは使わない」という項目がある

ファイナライザ： GCによりインスタンスが破棄されるタイミングで実行されるメソッド

• 即座にファイナライザが実行される保証がない
  • 時間的に制約のあることをファイナライザで行うべきではない
  • 実行タイミングはJVMごとのGCのアルゴリズムに依存する
• 実行されるかどうかも分からない
  • 重要な処理をファイナライザに頼ると実行されない可能性がある
  • 例1) データベースの共有ロックの解除
  • 例2) ファイナライザ中の例外は無視されて、そのままファイナライズは終了する
    • 他のオブジェクトへの悪影響を与える可能性もある
• パフォーマンスも悪い
• サブクラスのファイナライザは手作業でスーパークラスのファイナライザを呼び出す必要あり

→リソースの開放はファイナライザに頼らず、try-finallyのfinallyブロックで明示的に終了させる

ファイナライザが有効な場合

以下に対しては有効ではあるが、明示的終了のほうがよりよい。

• 安全ネットとして
  • 明示的な終了を忘れた場合に備えて、保険的にファイナライザを用いる
    • ただし明示的終了がされずファイナライザが呼ばれたときは警告ログを出力すべき
• ネイティブピアに対して

ファイナライズ連鎖とファイナライザガーディアン

サブクラスから、スーパークラスのファイナライザの呼び出しは手動で実施する必要がある。

→継承される可能性のあるクラスでファイナライズを用いる場合、 ファイナライザガーディアンと呼ばれる無名クラスを検討したほうがよい。

ファイナライザガーディアンとは

• ファイナライザ処理を含み、スーパークラスとなりうるクラスの内部クラスとして記述する
• ファイナライザガーディアンの中にスーパークラス自身のfinalize処理を書いておく
• サブクラスでスーパークラスのfinalize処理を忘れたとしても、内部クラスとして定義されている ファイナライザガーディアンによってスーパークラスはfinalize処理される

macでbashからzshへ乗り換えた話

今までずっとbashを使ってきましたが、補完が強力とか作業がいろいろ捗るとか聞くので、重い腰を持ち上げてzshに乗り換えることを決めました。

環境

• MacOS Sierra 10.12.3
• Homebrew 0.9.9

zshインストール

Homebrewは入れている前提です。

以下のコマンドでzshをインストールします。zsh-completionsは、zshの補完機能を強化するプラグインです。

$ brew install zsh
$ brew install zsh-completions

ログインシェルの変更

/etc/shellにログインシェルにできるプログラムがフルパスで記述されています。インストールしたzshのパスを追記します。

$ sudo sh -c "echo '/usr/local/bin/zsh' >> /etc/shells"

シェルを変更します。パスワードを入力後、ターミナルを再起動します。

$ chsh -s /usr/local/bin/zsh

初期設定

再起動後、以下のようなメッセージが表示されます。

This is the Z Shell configuration function for new users,
zsh-newuser-install.
You are seeing this message because you have no zsh startup files
(the files .zshenv, .zprofile, .zshrc, .zlogin in the directory
~).  This function can help you with a few settings that should
make your use of the shell easier.

You can:

(q)  Quit and do nothing.  The function will be run again next time.

(0)  Exit, creating the file ~/.zshrc containing just a comment.
     That will prevent this function being run again.

(1)  Continue to the main menu.

--- Type one of the keys in parentheses ---

• (q): 何もしません。次回ターミナル起動時に同じメッセージが再度表示されます。
• (0): ホームディレクトリ以下に.zshrcが作成されます。ここに設定を自分で書き込む方式です。
• (1): 対話式メニューで.zshrcの設定を決定していく方式です。

0を選択します。

zplugのインストール

zshのプラグインマネージャであるzplugをインストールします。

zshのプラグインマネージャといえばoh-my-zshやantigenも有名みたいですが、 参考にもあるようにパフォーマンス等の面でzplugが最近は流行っているよう。

$ brew install zplug

zplugのREADMEに従って~/.zshrcに設定を追加します。

# brewのインストールパスを設定する
export ZPLUG_HOME=/usr/local/opt/zplug
source $ZPLUG_HOME/init.zsh
# pluginの追加
## zsh-completions
zplug "zsh-users/zsh-completions"¬
fpath=(/usr/local/opt/zplug/repos/zsh-users/zsh-completions $fpath)¬
## git
zplug "plugins/git", from:oh-my-zsh
## 未インストール項目をインストールする
if ! zplug check --verbose; then
  printf "Install? [y/N]: "
  if read -q; then
       echo; zplug install
  fi
fi
## コマンドをリンクして、PATH に追加し、プラグインは読み込む
zplug load --verbose

上記で追加しているのは、git-completionsとoh-my-zshのgitプラグインです。

git-completionsは、vagrantコマンドやrailsコマンドなど、zshの補完を強化するプラグインです。 上記のみで補完が有効にならない場合は以下のコマンドも実行します。

$ rm -f ~/.zcompdump; compinit

oh-my-zshのgitプラグインは大量のgitのaliasや関数を読み込みます。（例：git status -s > gss） 全部はなかなか覚えられませんが、仕様頻度の高いaliasを使うだけでも意外と快適です。

vcs_infoの設定

vcsとはVersion Control Systemsの略です。 Gitとかバージョン管理システムの情報をターミナルに表示することが可能になります。

今回はシンプルにgitレポジトリ内ではブランチ名を表示するようにします。

# vcs_info
autoload -Uz vcs_info
## branchの表示
zstyle ':vcs_info:*' formats '(%b)'
precmd() { vcs_info }

#prompt
PROMPT='%n@%m: %~ ${vcs_info_msg_0}'

その他設定

上記に加えて、lessやgrepのグローバルエイリアス、historyの端末間での共有など 基本的な設定を追加したものが以下になります。

uu64/.zshrc

参考

• まだoh-my-zshで消耗してるの？
• macでzsh使う

RailsでBootstrapのmodalが開いてすぐ閉じてしまう問題

開発していて地味にハマったのでメモ。

概要

削除・更新系の処理実行前に確認画面を表示するために、bootstrapのmodalを利用。 ボタンを押すとmodalが一瞬表示されるが、何もUI操作をしていないのにmodalダイアログが閉じてしまう。

原因

異なる２つのgemの中でbootstrapを読み込んでいたことが原因。私の場合は”sass-rails”に加えて、"jquery-datatables-rails"のbootstrapオプションを利用していたからでした。

似たような事象が以下で報告されているので共有。どうやらmodal起動時に２回toggle()が呼ばれて、１回目の呼び出しでmodal起動、即座に２回目が呼び出されて閉じているっぽいですね。

Modal Disappears Immediately · Issue #1611 · twbs/bootstrap · GitHub

Bootstrap Modal immediately disappearing - Stack Overflow

解決方法

bootstrapを呼び出しているGemのうち、片方の代替となるGemを探してそれを利用するとかでしょうか。もしくは、片方のGemでbootstrapを呼び出さないように、何かしら工夫をするとか（Gemによって対処方法は違うと思うので具体的な解決策を示すことができなくて申し訳ないのですが）

私の場合は"dataconfirm-modal"という別のgemを利用することで正常に動作するようになったので、そのまま放置してあります。結局、sass-railsとjquery-datatables-railsの両方を利用しているので、また再発するかもしれないです。が、現状は問題ないので、しばらくこのままでいこうと思います・・・。

macOS Sierra + Vagrant + CentOS7でRuby On Railsの開発環境を構築する

railsの開発環境をvagrant上のcentos7に構築するスクリプトを作成し、GItHubに公開しました。利用手順をREADME.mdに記載してあります。postgresqlの設定など、手順の一部は手動で実施する必要があります。

github.com

以下の環境で動作確認。

• OS: macOS Sierra 10.12.3
• Vagrant 1.8.1
• Virtualbox 5.0.18
• ruby 2.3.1
• rails 4.2.2
• postgresql 9.2.18
• nodejs 4.7.3

本記事は上記スクリプトの作成課程やスクリプトの実行内容をメモしたものです。

事前準備

• vagrantのインストール
• virtualboxのインストール
• virtualboxのpluginのインストール
  • vagrantのvmとホストの間でフォルダ共有をするために必要

$ vagrant plugin install vagrant-vbguest

VMの生成

• VagrantFileを生成
  • https://atlas.hashicorp.com/centos/boxes/7

$ vagrant init centos/7

• VagrantFileを以下のように書き換える

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure(2) do |config|
  # https://atlas.hashicorp.com/centos/boxes/7
  config.vm.box = "centos/7"
  config.vm.box_version = "1611.01"
  config.vm.netowrk "forwarded_port", guest: 3000, host: 3000
  config.vm.provider "virtualbox" do |vb|
    vb.memory = "2048"
    vb.name = "centos/7"
  end
  # vagrant up時にbin/setup.shを自動実行する
  config.vm.provision "shell", privileged: false, path: "bin/setup.sh"
end

• Vagrantfileの設定内容に沿ってVMを作成する

$ vagrant up --provider virtualbox

localeなどの初期設定、ruby、nodejs、postgresqlのインストール

• bin/setup.sh中で実行する
  • rbenvでrubyのバージョン管理する
  • nodejsはuglifierなどのgemで必要

#!/bin/sh
RUBY_VERSION='2.3.1'
HOME_DIR='/home/vagrant'

# set locale, keymap, timezone
sudo localectl set-locale LANG=ja_JP.utf8
sudo localectl set-keymap jp106
sudo timedatectl set-timezone Asia/Tokyo

# install ruby
sudo yum -y update
sudo yum -y install git-all openssl-devel readline-devel sqlite gcc gcc-c++
git clone git://github.com/sstephenson/rbenv.git ${HOME_DIR}/.rbenv
git clone git://github.com/sstephenson/ruby-build.git ${HOME_DIR}/.rbenv/plugins/ruby-build
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ${HOME_DIR}/.bashrc
echo 'export PATH="$HOME/.rbenv/plugins/ruby-build/bin:$PATH"' >> ${HOME_DIR}/.bashrc
echo 'eval "$(rbenv init -)"' >> ${HOME_DIR}/.bashrc
echo 'gem: --no-ri --no-rdoc' > ${HOME_DIR}/.gemrc
source ${HOME_DIR}/.bashrc
rbenv install $RUBY_VERSION
rbenv global $RUBY_VERSION
gem install bundler

# install nodejs
sudo rpm -Uvh https://rpm.nodesource.com/pub_4.x/el/7/x86_64/nodesource-release-el7-1.noarch.rpm
sudo yum -y install nodejs

# install postgresql
# https://www.postgresql.org/download/linux/redhat/#yum
sudo yum -y install http://yum.postgresql.org/9.5/redhat/rhel-7-x86_64/pgdg-redhat95-9.5-2.noarch.rpm
sudo yum -y install postgresql-devel postgresql95-server postgresql95-contrib
sudo /usr/pgsql-9.5/bin/postgresql95-setup initdb
sudo systemctl start postgresql-9.5.service
sudo systemctl enable postgresql-9.5.service

postgresqlの設定

これ以降は自動化できていないため、手動実行の必要がある。

• postgresユーザーのパスワード変更

$ sudo passwd postgres
Changing password for user postgres.
New password:  #パスワードを適当に設定する
Retype new password:

• postgresqlにvagrantユーザーを追加

$ su - postgres
$ createuser vagrant -s
$ psql
postgres=# \password vagrant # vagrantユーザにパスワードを設定
Enter new password: #パスワードを適当に設定する
Enter it again: 
postgres=# \q # psqlプロンプト終了
$ exit

• pg_hba.confの81行目付近を以下のように書き換える (peer → md5)

$ sudo vi /var/lib/pgsql/9.5/data/pg_hba.conf

# "local" is for Unix domain socket connections only
# local   all             all                                     peer
local   all             all                                     md5

$ sudo systemctl restart postgresql-9.5.service

Railsプロジェクトの作成

• 作業ディレクトリの作成

$ mkdir /vagrant/hello_app
$ cd /vagrant/hello_app

• railsのインストール

$ bundle init
$ vi Gemfile

# Gemfileを以下のように編集
source "https://rubygems.org"

gem "rails", "4.2.2"
gem 'pg', '0.17.1'

# ホストOSとの共有フォルダ内にinstallするとrails関係のコマンドの実行速度が遅くなる（原因不明）
$ bundle install --path ~/bundler/hello_app/vendor/bundle

• railsプロジェクトの作成とDB設定

$ bundle exec rails new . --database=postgresql
$ vi config/database.yml

# database.ymlを編集し、defaultにusernameとpasswordを設定
default:
  ...
  username: vagrant
  password: # 先ほど設定したパスワード

$ bin/rake db:create

• サーバーの起動

bin/rails server -b 0.0.0.0 -p 3000

• http://localhost:3000/にアクセスし、以下の画面が表示されることを確認する

課題など

• postgresqlの設定を自動化したい
• ansibleとか使ってみたい