著者アーカイブ 杉浦

著者:杉浦

ソースコード間の関わりをシンプルにするFacadeパターン

Facade パターン – Wikipedia
　Facadeパターンはプログラミングのデザインパターンの一つです。Facadeは建物の正面を意味する語で、Facadeパターンは建物全体でなく正面だけを見ればよいようにコーディングを行う方法です。もし多数のクラス、関数、データが協調するプログラムを記述する際、すべてを同等に扱ったり散らかったままにすると、どこから何をどの手順で取ってくるのが良い方法か分かりにくくなります。ひどいことに、このクラスを呼ぶ前にはこの関数とあの関数をあらかじめ使っておき、データをどうこう加工しておく必要がある、なんてことにもなります。そういった事態を避けるために、モジュール間のやり取りをシンプルにする窓口を作るというのがFacadeパターンです。次の図は増補改訂版Java言語で学ぶデザインパターン入門に載っているFacadeパターンのクラス図です。ClientがシンプルなFacadeクラスという窓口を介することでClassA~Dを楽に扱えます。
　
　Laravelにはファサードという仕組みがあります。
ファサード 5.7 Laravel
　このファサードの中身を見ていくとFacadeパターンを体現しています。例えばAuthファサードは次です。雑多なAuth関連クラスである@see以下の4つをまとめ上げて、21の関数のアクセス方法を見せています。これを使うことが出来ると大変わかりやすく、便利です。これを使わず雑に、@see以下を読んでは継承で上書きしてテスト、読んでは上書きしてテスト、を繰り返すコーディングをするとあっという間に難解なコードになり後の修正やリファクタリングがとても面倒になります。

/**
 * @method static mixed guard(string|null $name = null)
 * @method static void shouldUse(string $name);
 * @method static bool check()
 * @method static bool guest()
 * @method static \Illuminate\Contracts\Auth\Authenticatable|null user()
 * @method static int|null id()
 * @method static bool validate(array $credentials = [])
 * @method static void setUser(\Illuminate\Contracts\Auth\Authenticatable $user)
 * @method static bool attempt(array $credentials = [], bool $remember = false)
 * @method static bool once(array $credentials = [])
 * @method static void login(\Illuminate\Contracts\Auth\Authenticatable $user, bool $remember = false)
 * @method static \Illuminate\Contracts\Auth\Authenticatable loginUsingId(mixed $id, bool $remember = false)
 * @method static bool onceUsingId(mixed $id)
 * @method static bool viaRemember()
 * @method static void logout()
 * @method static \Symfony\Component\HttpFoundation\Response|null onceBasic(string $field = 'email',array $extraConditions = [])
 * @method static null|bool logoutOtherDevices(string $password, string $attribute = 'password')
 * @method static \Illuminate\Contracts\Auth\UserProvider|null createUserProvider(string $provider = null)
 * @method static \Illuminate\Auth\AuthManager extend(string $driver, \Closure $callback)
 * @method static \Illuminate\Auth\AuthManager provider(string $name, \Closure $callback)
 *
 * @see \Illuminate\Auth\AuthManager
 * @see \Illuminate\Contracts\Auth\Factory
 * @see \Illuminate\Contracts\Auth\Guard
 * @see \Illuminate\Contracts\Auth\StatefulGuard
 */
class Auth extends Facade

著者:杉浦

多様な言語のチートシートページDevhints

Devhints — TL;DR for developer documentation
　Devhintsは様々な言語、プログラムの基本的な書き方の例文が載っているページです。開発中の「あれはこの言語であっただろうか」「何かいい感じの書き方用意されてないか」「忘れた」といった時にチラっと見ることのできるヒント集になります。DevhintsにはC++の例文、vimの操作方法、firefoxの過去バージョンへのリンクなど様々ありますが、大体役に立つのはプログラミング言語の例文とCLIの操作例です。
　Devhintsに載っているコードはいかにもヒントな印象で簡易なものです。次はVue.jsに関するチートシートの一部です。

new Vue({
  data: { ... }
  props: ['size'],
  props: { size: Number },
  computed: { fullname() { return this.name + ' ' + this.lastName } },
  methods: { go() { ... } },
  watch: { a (val, oldVal) { ... } },
  el: '#foo',
  template: '...',
  replace: true, // replace element (default true)

  // lifecycle
  created () {},
  beforeCompile () {},
  compiled () {},
  ready () {}, // $el is inserted for the first time
  attached () {},
  detached () {},
  beforeDestroy () {},
  destroyed () {},

  // options
  directives: {},
  elementDirectives: {},
  filters: {},
  components: {},
  transitions: {},
  partials: {}
})

　とても端的です。これを最初に読むには説明がまるで足りていませんが、思い出す時、調べるきっかけになる何かの機能の名前を知りたい時にはあっという間に読める文量のこれぐらいが便利です。

著者:杉浦

オンラインPlantUMLエディタのPlantTextの紹介

PlantText UML Editor
　PlantTextはPlantUMLのオンラインエディタです。PlantUMLはUML図を容易に作図するための言語です。UMLとはUnified Modeling Language、統一モデリング言語の略でありUML図はUMLの記法に従った図です。フローチャート、クラス図、シーケンス図、状態遷移図などの様にモデルがどの様な構造でどの様にふるまうかを一定の規則でわかりやすく示します。次の図はあるイベントに参加するか否かのフローチャートのUML図です。

　長方形は処理、ダイヤは分岐、黒は処理のない始点、終点、通過点とわかれており、矢印はフローの方向を示し、UMLに従って作図するだけでわかりやすく仕上がります。UML図は便利ですが作図という性質上、まともに箱を書いて、丸を書いて、矢印を作って、と繰り返しているととても手間で面倒です。PlantUMLはUML図を容易に作図するために文字列だけを用います。
　PlantUMLの実行環境は様々です。大体IDEや多機能エディタには初期装備かプラグインかであります。PlantText UML EditorはPlantUMLのオンラインエディタです。先ほどの図は次の様に記述することで作図しました。

　画像右下のリンクにある様に画像として出力、テキストとして出力もできます。Editはコードの共有用です。先ほどのコードならばPlantTextの様にEditから飛ばされる先のリンクで共有できます。
　PlantUMLはUML用ですがER図もかなりそれらしいものが記述できます。下のリンクは読みやすかったPlantUMLの書き方です。
PlantUML Cheat Sheet – Qiita
PlantUML で ER 図（ERD）を描く（似非ではないです） – Qiita

著者:杉浦

任意のJSONを返すサーバーを簡単に作るJSON Serverの紹介

json-server – npm
　JSON ServerはJSONファイルに書いた内容をそのままJSONとしてレスポンスしてくれるHTTPサーバを簡単に立てるパッケージです。使い方は簡単。

npm install -g json-server

　でjson-serverをインストール。必要があればglobalでなくしてプロジェクトに入れておきます。次に、任意の場所に適当なjsonファイルを置きます。例えばdb,jsonというファイル名で次の内容が記述されたものをC:\tmpの中に入れておきます。

{
  "profile": { "name": "typicode" },
  "spot": [
    {"id":1, "X":-140987.23691179, "Y":-71607.046446965, "lat":34.726604791, "lng":137.718115230},
    {"id":2, "X":-140987.23691179, "Y":-71607.046446965, "lat":34.726604791, "lng":137.718115230}
  ]
}

　この状態で

json-server --watch C:\tmp\db.json

　とコマンドを打てば、これでjsonレスポンスを返すサーバーが立ちました。こうすると次の様な画面になります。

　Resourcesに定義したjsonへのURLが記述されています。この通りにアクセスすると次図の様にjson形式のレスポンスが返ってきます。

　watchというコマンドから連想できるようにjson-serverはjsonファイルを監視しています。記述を変える度に再起動する手間も必要なく便利です。APIに関連するテストモックなどでよく使えます。

著者:杉浦

バグの記録の仕方とテスト駆動開発

　プログラミングをする上でバグの発生は避けることが非常に困難な現象です。ほとんどの場合においてバグは発生したならば直す必要があります。バグが直ったことを確かめるためにはバグが再現する条件を見つける必要があります。バグが再現しなくなってようやく、ある条件において発生していた意図しない動作は発生しなくなった、と言えます。そのためバグの発見時の記録には、バグが再現するための条件、バグが直った場合の動作、がわかるための手がかりとなることが求められます。Matt Doar著のバグレポートの使い方には次の様にあります。

• バグの再現方法(できるだけ詐しく)と発生頻度
• 本来の仕様(バグがない場合の望ましい動作。こうあるべき、という自分の意見でかまわない)
• 実際の動作(完全でなくても、自分の記録した範囲で詳しく書く)

　なぜバグが起きるのか、どうすれば直ったと言えるのかに必要な情報がまとまっています。テスト駆動開発という手法ではこれを元に自動テストを書き、それを適宜通すことで再発を防ぐ方法が唱えられています。これは3ステップで、まず、バグが再現する操作を再現して、本来の仕様ならばテストが通るテスト関数を作り、それが常にレッド（テストが通らない状態）であることを確認。次いで、無理やりにでも直して常にグリーン（テストが通る状態）であることを確認。最後に、リファクタリングでコードをきれいにし、かつ常にグリーンであることを確認する。といった具合です。これを繰り返すとバグらないきれいなコードが残ります。

著者:杉浦

メソッドからコンストラクタへのパラメータの移動によるリファクタリング

　このリファクタリングはあるオブジェクトの複数のメソッドで同じパラメータを渡している場合に有効です。コンストラクタでパラメータを定義することによって、インスタンス化された際にあらかじめ何度も渡されるはずだったパラメータを定義することによってコードをシンプルにします。
　次は期限が1日になる様にのAPIトークンを更新するメソッドの呼び出しです。これを行う箇所が複数のコードファイルの中で何度も出てくると仮定します。その場合[‘expired_at’ => now()->addDay()->format(‘Y-m-d H:i:s’)]も何度も出てくるということです。この状態でAPIトークンの期限を3時間にしたいという要求が来た場合、変更箇所が複数に渡り少々面倒なことになります。（置換で対処しようにも妙な変数名や何やらで失敗するかも）そうでなくとも単に行が長くなりがちです。

/** @var ApiToken $api_token */
$api_token->fill(['expired_at' => now()->addDay()->format('Y-m-d H:i:s')]);

　これをApiTokenクラスのコンストラクタに記述し、fillの度に呼び出すことで改善します。

class ApiTokens extends Model
{
    public function __construct(array $attributes = [])
    {
        parent::__construct($attributes);
        $this->new_expired_at = now()->addDay()->format('Y-m-d H:i:s');
    }
    public function fill(array $attributes)
    {
        $attributes['expired_at'] = $this->new_expired_at;
        return parent::fill($attributes);
    }
}

　こうするとクラスApiTokenからインスタンス$api_tokenを定義するたびに更新用の新たな期限が$api_tokenのプロパティに設定され、fill()に新たな期限の値を渡さずともfill()は新たな期限をトークンに設定します。例では1つのメソッドでのみプロパティを扱いましたがこれが複数のメソッドになってくるとなお効いてきます。

/** @var ApiToken $api_token */
$api_token->fill();