Secrets of the JavaScript Ninja 2nd 読書メモ 第1章 JavaScriptはどこにでも

Secrets of the Javascript Ninja

JavaScript言語を理解する

JavaScriptは以下のような点で他の言語と異なる。

  • 関数がファーストクラスオブジェクトである
  • クロージャ
  • スコープ(ES2015より前には、JavaScriptにブロックスコープはなかった)
  • プロトタイプベースのオブジェクト指向

オブジェクトとプロトタイプ、関数とクロージャーの関係を理解することで、JavaScriptのプログラミングスキルが向上する。

加えて、以下のような機能を理解することで、美しく効率の良いコードを書くことができる。

  • ジェネレーター
  • Promiseによる非同期処理
  • Proxyによるオブジェクトへのアクセス制御
  • Arrayのメソッド群
  • Mapによる辞書型コレクション、Setによる一意なコレクション
  • 正規表現
  • モジュール

ブラウザを理解する

JavaScript実行環境としてもっとも重要なのはブラウザである。ここでは以下のトピックに集中する。

  • DOM(Document Object Model)
  • イベント
  • ブラウザのAPI

ベストプラクティスに従う

JavaScriptの習熟に加えて、以下のようなスキルを身につけていることが重要である。

  • デバッグ
  • テスト
  • パフォーマンス分析

スキルを持ち運びやすくする

JavaScriptのコアとなる部分について深い理解があれば、様々な種類のアプリケーション開発にスキルを活用できる。

  • デスクトップアプリ(Electron)
  • モバイルアプリ(Cordova, React Native)
  • サーバーサイドアプリ(Node.js)

Secrets of the JavaScript Ninja 2nd 読書メモ 0 はじめに

Secrets of the Javascript Ninja

『Effective C#』第3版のおかげで、洋書をちまちま読む習慣が身につきました。良い流れを切らさないよう、新しい本に手を付けてみます。次に読む本は『Secrets of the JavaScript Ninja』の第2版。jQueryの作者であるJohn Resig氏の著書で、第1版は「JavaScript Ninjaの極意」というタイトルで邦訳されています。本書は、2016年10月に発売された第2版で、ES6(ES2015)の文法も踏まえた最新版です。

今回は「はじめに(Author’s Introduction)」の部分からメモ。


JavaScriptを取り巻く環境は、著者が本書の初版を書き始めた2008年頃と比べると、様々な点で異なる。

  • JavaScriptはクロスプラットフォームで動作する言語として最大の人気を得ている
  • (JavaScript実行環境の)プラットフォーム間の差異は縮小傾向にある
  • 開発環境の進歩も著しい

JavaScriptの書き方は以前とは様変わりしている。本書には、新しい時代のJavaScriptを、上手に書くための知見がまとめられている。

Effective C# 3rd 読書メモ 50 例外フィルタの副作用を利用する

常にfalseを返す例外フィルタを定義することは奇妙に思えるかもしれないが、そうすべき理由がある。例外フィルタはスタックの一部として実行されるので、スタックが破棄される前に実行されるのだ。

これを利用すると、以下のように、例外の詳細な情報をログに書き込むことができる。

public static void Main()
{
    var failures = 0;
    var data = default(string);

    while (data == null)
    {
        try
        {
            data = MakeWebRequest();
        }
        catch (Exception e) when (ConsoleLogException(e))
        {
        }
        catch (TimeoutException e) when (failures++ < 10)
        {
            WriteLine("Time out error: trying again");
        }
    }
}

public static bool ConsoleLogException(Exception e)
{
    var oldColor = Console.ForegroundColor;
    Console.ForegroundColor = ConsoleColor.Red;
    WriteLine($"Error {e}");
    Console.ForegroundColor = oldColor;
    return false;
}

private static string MakeWebRequest()
{
    throw new TimeoutException();
}

以上で、『Effective C#』の第3版、読了です。C#は仕様の大きな言語で、それなりの歴史もあるので、同じことをするにも複数の書き方ができます。典型的な例はローカル変数の定義で、型を明示的に指定することもできれば、型推論に任せることもできます。初心者のうちは、どちらの書き方を使えばいいのかわかりませんでした。

本書には、そういったC#を書く上での迷いどころや落とし穴の回避方法がまとめられています。『やさしいC#』等の入門書を読んだ後、2冊目ないし3冊目あたりで読むと良いと思いました。

ちなみに、『Effective C#』の類書として『実戦で役立つ C#プログラミングのイディオム/定石&パターン』があります。こちらは入門書の次に読んでも大丈夫なくらいの内容で、C#で何かをしたいときに役立つ書き方が「イディオム」としてまとめられています。

Effective C# 3rd 読書メモ 49 例外フィルタを使う

通常のcatch節では、例外の型に基いて捕捉を行う。例外をキャッチしたらリトライするような実装では、最終的に、例外を再度throwすることになる。このやり方では、その後の分析が難しくなる。このような場合には、例外フィルタを使うべきである。

例外フィルタは、catch節にwhenキーワードを重ねて使用する。

public static void Main()
{
    var retryCount = 0;
    var data = default(string);

    while (data == null)
    {
        try
        {
            data = MakeWebRequest();
        }
        catch (TimeoutException e) when (retryCount++ < 3)
        {
            WriteLine("Operation timed out. Trying again");
            Task.Delay(1000 * retryCount);
        }
    }
}

private static string MakeWebRequest()
{
    throw new TimeoutException();
}

例外フィルタを使用すると、例外をキャッチした際にもコールスタックは破棄されないので、例外の発生した状況をあとで追いやすい。また、例外フィルタを使用したほうがパフォーマンスも良くなる。

Effective C# 3rd 読書メモ 48 例外:強い保証を使用する

例外が投げられると、処理の流れは中断される。不適切な方法で例外を投げると、それをハンドリングすることは困難である。例外の投げ方にはベストプラクティスがある。

  1. 基本的な保証
  2. 強い保証
  3. no-throw保証

基本的な保証は、例外が投げられた後でも、そのメソッドにおいて全てのオブジェクトがリークせず、有効な状態であることを意味する。強い保証は、基本的な保証に加えて、例外が発生した場合でも、プログラムの状態が変わらないことを意味する。no-throw保証は、処理が絶対に失敗せず、例外が投げられないことをいう。

このうち、強い保証を採用することが、安全性とシンプルさの点からバランスがよい。強い保証のもとでは、メソッドの結果は、処理が完了するか、何も変わらないかのいずれかである。中間点はない。強い保証の利点は、例外をキャッチした後でも処理を継続しやすいことだ。

強い保証のためには以下のような(今までに紹介してきた)テクニックが使用できる。

  • プログラムが使用するデータはイミュータブルな値型に入れる
  • LINQクエリのような関数型プログラミングのスタイルを使用する

データの書き換えは以下の様式に沿って行うべきである。

  1. 変更されるデータのコピーを作成する
  2. コピーに対して変更を行う
  3. コピーをオリジナルと置き換える
public class SalaryManager
{
    public void PhysicalMove(string title, decimal newPay)
    {
        // コピーを作成
        var d = new PayrollData(title, newPay);
        // オリジナルと置き換え
        PayrollData = d;
    }

    public PayrollData PayrollData { get; private set; }
}

public struct PayrollData
{
    public PayrollData(string title, decimal pay)
    {
        Title = title;
        Pay = pay;
    }

    public string Title { get; }
    public decimal Pay { get; }
}

しかし、強い保証を使用するとパフォーマンスの問題が発生することもある。たとえば、ループで大量のオブジェクトを書き換える場合には、コピーを作って差し替える方式は効率が悪い。

また、差し替え方式は、参照型では使用することができない。コピーとオリジナルと差し替えても、オリジナルを参照しているオブジェクトが残っている場合があるからだ。

実用的な対処法は、以下のように新しくデータを作り直すことである。

private List<PayrollData> data;
public IList<PayrollData> MyCollection
{
    get
    {
        return data;
    }
}

public void UpdateData()
{
    // 失敗する可能性のある処理
    var temp = UnreliableOperation();

    data.Clear();
    foreach (var item in temp)
        data.Add(item);
}

上の方法は絶対確実な方法とはいえない。絶対確実にするためには、以下のように、データを包含するクラス(Envelope)を作成し、そのクラスに置き換えを行わせる必要がある。

public class Envelope : IList<PayrollData>
{
        private List<PayrollData> data = new List<PayrollData>();

        public void SafeUpdate(IEnumerable<PayrollData> sourceList) {
            // コピーの作成
            List<PayrollData> updates =
                new List<PayrollData>(sourceList.ToList());
            // 差し替え
            data = updates;
        }

        public PayrollData this[int index]
        {
            get { return data[index]; }
            set { data[index] = value; }
        }

        public int Count => data.Count;

        public bool IsReadOnly =>
            ((IList<PayrollData>)data).IsReadOnly;
            public void Add(PayrollData item) => data.Add(item);

        public void Clear() => data.Clear();

        public bool Contains(PayrollData item) =>
            data.Contains(item);

        public void CopyTo(PayrollData[] array, int arrayIndex) => data.CopyTo(array, arrayIndex);

        public IEnumerator<PayrollData> GetEnumerator() =>
            data.GetEnumerator();

        public int IndexOf(PayrollData item) =>
            data.IndexOf(item);

        public void Insert(int index, PayrollData item) =>
            data.Insert(index, item);

        public bool Remove(PayrollData item)
        {
            return ((IList<PayrollData>)data).Remove(item);
        }
        public void RemoveAt(int index)
        {
            ((IList<PayrollData>)data).RemoveAt(index);
        }
        IEnumerator IEnumerable.GetEnumerator() =>
            data.GetEnumerator();
}

このクラスは以下のように使用する。

private Envelope data;
public IList<PayrollData> MyCollection
{
    get
    {
        return data;
    }
}

public void UpdateData()
{
    data.SafeUpdate(UnreliableOperation());
}

所感

「強い保証」の考え方はRDBMSのトランザクションっぽくて面白い。1メソッドを1トランザクションと考えて、そのメソッド内で処理が完了すればコミット、何かうまくいかないことがあればロールバック。