履いた靴の記録を取っている

昨年の6月くらいから履いた靴の記録を残すようにしました。　　 365shoes.style

残す理由は以下の通りです。

• 手持ちの靴が革のものが多く、経年変化の記録を残したい。
  • いつの間にか変わってることが多い。
• 靴が気付いたら増えているので、増減を記録したい。
  • 学習しないんや。。。
• 靴のレビューを残したい。
  • 今まで履いてきたものの記録がない為、反省できない場合が多い。
• 履く頻度の低い靴の処分判断がしたい。
  • あまり履いてないな、という感覚があるがどの程度が不明なことが多い。

開発のスタイル

基本的に土日にコードを書くスタイルです。
軽度のものは、勤務時間の休憩時間で対応しています。

技術スタックは下記のものを使用しています。
そのうちTypeScript、Next.jsに置きかえると思います。

• Flow
• Nodejs
• React
• Express
• GraphQL
• MongoDB
• Heroku
• AWS(S3)
• Cloudflare
• Cloudinary

2018年の集計結果

ちなみに昨年2018年の集計結果は下記の通りになりました。

Tokyo Sandalsのサンダルは利用頻度が差も高くて、その次にHunterのレインブーツ、後はローテンションで大体履いているので、ほぼ横並びです。

靴、サンダルの数は最終的に23足でした。(こんなにいらないと思う)

ブランド	名前	回数
Nicks Boots	6inch HotShot	11
Hunter	Chelsea Boots	15
Hunter	Original Festival Chelsea Boots	13
Brother Bridge	JAMES	9
Brother Bridge	McCLOUD	12
Rolling Dub Trio	ROOTS	4
Tokyo Sandals	DOBULE MONK SANDAL	31
Chippewa	6inch Service Boots Burgundy	11
Chippewa	6inch Service Boots Crazy house	11
Chippewa	Bridgeman Burgundy	9
Chippewa	Bridgeman Black Odessa	9
Chippewa	Suburban Navy	3
Slow Wear Lion	オイルドレザープレーンMIDブーツ Red	10
Slow Wear Lion	栃木レザープレーンミッドブーツ	11
Slow Wear Lion	オイルドレザーサイドゴアブーツ	11
Redwing	Irish Setter Black	11
Redwing	Irish Setter Gold russet	10
Berwick	Chukka boots	10
Timeberland	6inch Premium Boots	6
Timeberland	3eye Classic Lug Burgundy	7
Timeberland	3eye Classic Lug Brown	5
Timeberland	Earthkeepers 6inch Boots	7
PISTOLERO	Norwogian Split	7

Wescoのブーツが届きました

Wesco Custom 38LTT

3月7日にオーダーしていたWescoのブーツが最近届きました。
当初の8月末くらいという話だったのですが、8月17日にオーダーしたお店から午前中に連絡をいただいて、その日に受け取り行きました。(オーダーから約5ヶ月)

当初はオーダーするつもりはなかったのですが、Wesco100周年記念の3rd Anniversary Modelだったので、オーダーしました。

オーダー時は店舗でサイズを測ってもらい、レギュラートゥの38RTか、レーストゥトゥの38LTTを選ぶ感じでした。

フィット感がいい方が好きなので、レーストゥトゥの38LTTを選びました。

入っていた物

パッケージには、メンテナンス用のクロスや、オイル、ウールのキャップ、フォルスタン、ブーツ用の袋が入っていました。 しかも、ケース付きです。

また、ギャランティカードがあるので、下記の場合は修理費用がお安くなります。

1. １回目のヒール交換が無料
2. １回目のオールソールは¥5,000円程度 (通常は¥16,000円程度)

ワークブーツは大体頑丈なので、よっぽど酷使しなければ修理はそんなにする必要はないので、使うとしても大分先になりそうです。

箱の正面

履き方はフォルスタンなしで、シューレスはレザーのものを使用しています。 履くときにレザーのシューレスがフックにかけにくいのですが、Rootsで慣れているので、特に気にならなかったです。

一回試し履きした感じは、NicksのHot Shotより軽くていい感じです、足馴染みも早そうです。

これからどんどん履いて行きたいです。

HackでAttributeを表現するためのインターフェース

HHVM3.29より、Attributeを表現するインターフェースが追加されました。
今までも、Attribute自体は使用できていましたが、以下の問題がありました。

• タイプチェックがかからない。
  • Attributeに依存する処理でバグがあると原因を特定しにくい。
• ユーザー独自のAttributeの仕様をコードで表現できない。
  • 引数は2つなのか、型はstringなのか表現できないので、ドキュメントなどにまとめる必要があった。

この問題をHHVM3.29で組み込まれた、インターフェースで解決できるようになりました。
.hhconfig に user_attributes= を設定として追加した後に、下記のインターフェースを実装するだけで、Attributeが利用できる部分の指定、インターフェースを実装したクラスでのタイプチェックがかかります。

• ClassAttribute - クラス
• EnumAttribute - 列挙型
• TypeAliasAttribute - 型の別名
• FunctionAttribute - 関数
• MethodAttribute - メソッド
• InstancePropertyAttribute - インスタンスプロパティ
• StaticPropertyAttribute - 静的プロパティ
• ParameterAttribute - 引数

Attribute仕様の表現

例えば、クラスとメソッドに指定できるAttributeを表現したい場合、下記のようにインターフェースを指定します。

\HH\ClassAttribute, \HH\MethodAttribute をクラスに実装することで、クラスとメソッドに指定できる部分を制限できます。

<?hh //strict

namespace TypedUserAttributes;

final class Version implements \HH\EnumAttribute, \HH\ClassAttribute, \HH\MethodAttribute, \HH\FunctionAttribute {
  public function __construct(
    private float $version
  ) {
  }

  public function __toString() : string {
    return (string) $this->version;
  }
}

また、指定する場所を間違えたり、パラメータの型を間違えた場合、タイプチェックに引っかかることがわかります。

Attributeの取得

Attributeの情報を取得する場合は、リフレクションを使用します。
メソッドとして、getAttributeClass が提供されているので、Attributeのクラス名を引数に渡して、Attributeのインスタンスを取得できます。

<?hh //strict

namespace TypedUserAttributes;

require_once 'Post.hh';
require_once 'Version.hh';

use \ReflectionClass;

<<__EntryPoint>>
function main(): noreturn {
  $class = new ReflectionClass(\TypedUserAttributes\Post::class);

  $classVersion = $class->getAttributeClass(\TypedUserAttributes\Version::class);
  \printf("class version: %s\n", $classVersion);

  $methodVersion = $class->getMethod('getTitle')->getAttributeClass(\TypedUserAttributes\Version::class);
  \printf("method version: %s\n", $methodVersion);

  exit();
}

最後に

インターフェースが追加されたことにより、パッケージを設計する開発者にとっては非常にありがたい恩恵を受けることができるようになりました。

これからはAttributeを使う際には、インターフェースを使用して欲しいです。

また、ここで紹介したコードはここに置いて起きました。 gist.github.com

HackのコードジェネレーターをHackTestに対応させた

Hack用のテストフレームワークが出たので、HackUnitから置き換えました。
github.com

そのついでに、CodegenにHackTestのテストコードを生成できるジェネレーターを追加しました。 github.com

HackUnitからの移行

名前空間をHackUnitからHackTestに置き換えるだけで移行できます。

移行前

use HHPack\Codegen\HackUnit\{TestClassGenerator};

移行後

use HHPack\Codegen\HackTest\{TestClassGenerator};

生成されるテストコード

下記のようなテストコードを生成します。
テストコード自体は、HackTestとFBExpectを使用する前提のコードなので、composerで別途パッケージをイントールする必要があります。

<?hh // strict
/**
 * This file is generated. Do not modify it manually!
 *
 * @generated SignedSource<<d89af2ac5307bacbedfa27fd6389c1ff>>
 */
namespace HHPack\Codegen\Example\Test;
use type Facebook\HackTest\HackTest;
use function Facebook\FBExpect\expect;

final class Bar extends HackTest {

  public function testExample(): void {
    expect(true)->toBeTrue();
  }
}

パッケージのインストールはHackTestのREADME.mdに書いてある通りにコマンドを実行するだけで、インストールできます。

hhvm /path/to/composer.phar require --dev hhvm/hacktest facebook/fbexpect

HackUnit、PHPUnit使わなくて済むのと、オフィシャルのテストフレームワーク(ブログで発表された)ぽいので、これ使った方がいいと思います。

jbuilderからduneに変えた

dune1.0がリリースされたので、jbuilderからduneに置き換えました。
作業内容としてはそんなに修正箇所はありませんでした。

github.com

作業内容

1. jbuildファイルの変更
   • jbuildファイルをduneにリネーム
   • 設定ファイルの変更
2. コマンドをjbuilderからduneに変更
   • Makefileの変更
3. opamファイルの変更
   • 依存しているパッケージをjbuilderからduneに変更
4. コンパイル時のwarningメッセージを出ないように修正
   • コンパイル時のオプションが変わったのか、warningがでるようになったのでソースを修正

1. jbuildファイルの変更

jbuildファイルをduneに名前を変えた後に、S式の()を一つ外します。
duneではいらなくなったようです。

削除し忘れていても、ビルド時にメッセージで()がいらないと言われるので、すぐ直せます。

不要な()を削除する

修正前

(library (
  (public_name typesafety.misc)
  (name misc)
))

修正後

(library
  (public_name typesafety.misc)
  (name misc)
)

パラメメータの置き換え

パラメータは${}で指定できましたが、duneからは%{}に変わったようです。　　

(rule (
  (targets (github_t.ml github_t.mli))
  (deps (github.atd))
  (action (run ${bin:atdgen} -t ${<}))
))

(rule
  (targets github_t.ml github_t.mli)
  (deps github.atd)
  (action (run %{bin:atdgen} -t %{deps}))
)

2. コマンドをjbuilderからduneに変更

これは単純にjbuilderをduneに置き換えるだけです。

修正前

build:
    jbuilder build

修正跡

build:
    dune build

3. opamファイルの変更

これも単純にjbuilderをduneに置き換えるだけです。

修正前

build: [
  ["jbuilder" "build" "-p" name "-j" jobs]
]
build-test: [
  ["jbuilder" "runtest" "-p" name]
]
depends: [
  "jbuilder" {build}
]

修正後

build: [
  ["dune" "build" "-p" name "-j" jobs]
]
build-test: [
  ["dune" "runtest" "-p" name]
]
depends: [
  "dune" {build}
]

4. コンパイル時のwarningメッセージを出ないように修正

使用していない式や型の定義などは、warningがでるようになりました。
これは単純に直していけばいいので、そんなに難しくないかと思います。

js_of_ocamlをjbuilder(dune)で試してみた

OCamlのバイトコードをJSに変換できるツール、js_of_ocamlを試して見ました。
とりあえず、jbuilder(dune)を使用して、JSを出力できるようにはなりました。
今回はビルドの方法だけの内容です。

必要なもの

opam経由で必要なパッケージをインストールします。
必要なパッケージは下記の通りです。
インストールされたバージョンは最新の3.1.0です。

• OCaml compiler - 4.06.1
• js_of_ocaml - v3.1.0
• js_of_ocaml-ppx - v3.1.0

opam install -y js_of_ocaml js_of_ocaml-ppx

jbuildファイルを用意する

ruleに出力するファイルの設定を追加します。
js_of_ocamlのオプションに--source-mapを追加して、ソースマップを出力するようにしています。

また、aliasにDEFAULTを追加して、依存しているファイルも用意するようにしています。
jbuildファイルがあるディレクトリをベースにindex.html、main.jsをコピーします。

(jbuild_version 1)

(executables (
  (names (main))
  (preprocess (pps (js_of_ocaml-ppx)))
))

(rule (
  (targets (main.js))
  (action
    (run ${bin:js_of_ocaml} --source-map ${path:main.bc} -o ${@} --pretty)
  )
))

(alias (
  (name DEFAULT)
  (deps (main.js index.html))
))

index.htmlの用意

main.jsのファイルを読み込む適当なHTMLファイルを用意します。

<!doctype html>
<html>
  <head>
    <title>example</title>
    <script src="main.js"></script>
  </head>
  <body>
  </body>
</html>

main.mlの用意

コードは簡単なものにして、デバッグしやすくします。
このコードは、DOMContentLoadedイベントにイベントハンドラを追加して、デバッグログを出力するだけのコードです。

open Js_of_ocaml

module Html = Dom_html

let document = Html.window##.document
let addEventListener = Dom.addEventListener
let domContentLoaded = Dom_events.Typ.domContentLoaded

let debug f = Printf.ksprintf (fun s -> Firebug.console##log (Js.string s)) f

(* DOMContentLoadedのイベントハンドラ *)
let dom_content_loaded evt =
  debug "debug: %s" "domContentLoaded!!";
  Js.bool true

let () =
  let event_handler = Dom.handler dom_content_loaded in
  ignore (addEventListener document domContentLoaded event_handler (Js.bool false))

Makefileを用意する

とりあえず、ビルドと成果物のクリーンアップをできるようにします。
jbuildのaliasにDEFAULTを指定しているので、@DEFAULTをコマンドの引数に追加するだけで、ビルドできます。

all:
    jbuilder build @DEFAULT

clean:
    jbuilder clean

JSのビルド

ビルドはmakeコマンドを実行するだけです。
__build/default の配下に出力されたJSファイル、index.htmlコピーがあるはずです。
index.htmlファイルをブラウザで開いて、コンソールにデバッグメッセージが出力されていればOKです。

make

Hackで書いたProcessパッケージ

Processパッケージをリファクタリングしました。
https://github.com/hhpack/process

主な変更点は下記の2点です。

• stream_selectからstream_awaitへの置き換え
• IDisposableを使用したリソース管理

stream_selectからstream_awaitへの置き換え

パイプの状態監視に今まではstream_selectを使用していました。
これをstream_awaitに置き換えました。

stream_awaitは非同期な関数なので、awaitを使用していたのですが、戻り値のステータスが期待した値を返してくれませんでした。

仕方ないので、\HH\Asio\join関数で処理を待つように変更したところ期待通り動作するようになりました。

stream_awaitは内部的にepollでも使ってるのかな?

before

await stream_await($handle, STREAM_AWAIT_READ, 0.2);

after

\HH\Asio\join(stream_await($handle, STREAM_AWAIT_READ, 0.2));

IDisposableを使用したリソース管理

前の実装までは__destructでプロセスのパイプをクローズしていたのですが、IDisposableが使えるようになったので、置き換えました。

これでブロックスコープを抜けた後などに、パイプをすぐにクローズできるようになりました。

この機能はHHVM3.24以降で利用可能です。 https://hhvm.com/blog/2018/01/16/hhvm-3.24.html

おそらく、C#ユーザーあたりから提案があったのだと思います。(async/awaitもそうだったはず)

<?hh //strict

use HHPack\Process;
use HHPack\Process\ProcessOptions;
use HHPack\Process\Output\{ Stdout, Stderr };

async function pipe_example() : Awaitable<void>
{
  $options = new ProcessOptions();
  $options->stdout(new Stdout());
  $options->stderr(new Stderr());

  using ($p = Process\spawn('hh_client restart', [], $options)) {
    await $p->wait();
  }

  using ($p = Process\spawn('hh_client check --json', [], $options)) {
    await $p->wait();
  }
}