Vue.jsチョット書いたのでふりかえり

Jun 11, 2018

ちまちま各論のメモは起こしてあるけど、ざっくり全体のメモがなかったので、自分が現時点で意識していることをまとめてみた。

Vue.jsのメリット

Single File Componentが標準で扱える

Single File Component がすべての問題を解決するとは思っていないのだけれど、まず自分は

jQuery 的な DOM 要素とそのイベント中心の書き方
Unobstrusive JavaScript

の組み合わせは「操作」が「要素」と密結合しているにも関わらず、コードとしては非常に距離が遠く凝集度が低すぎると考えている。HTML と JavaScript の紐付けは class や ID で行うが、ページをまたいで影響させるのは難易度が高すぎる。またコードがイベント中心かつ操作中心になりすぎてしまい、抽象度が低すぎる。本当に考えるべき状態やロジックまで意識を到達させるのはとても難しい。要するにものすごくちぐはぐなのだ。

この問題を Single File Component は比較的うまく解決していると思う。機能として意味のある HTML 断片をコンポーネントとして切り出し、その隣に実際の機能を記述することができる。また Scoped CSS を書けるのもよい。

これが Vue.js では追加設定なしに書ける。

ある程度オールインワンなので準備が楽

AngularJS (v1) のように世界が閉じすぎておらず、React や Mithril のように単機能すぎない。一応 Babel などのビルドプロセスがなくても動かすことができる。Angular (2+) のように TypeScript を新たに勉強する必要もない。

この準備が複雑すぎないことはとても重要と考えている。少なくとも現在の環境では

デザイナーなど必ずしも JavaScript に明るいわけではない人にも扱える
Node.js ヘビーな JavaScript の環境構築に詳しくない人でも扱える

ことを重視している。

環境構築は目的ではなく手段。手段の習得がヘビーすぎるのは完全に本末転倒と言ってよい。準備が楽であればあるほど新しく参加するメンバーの初期コストが下がる。それは特に小さく固定的でないチームにとって重要である。

必要な用語が少ない

正確な理解とより良いコードを書くためには、当然のことながら各機能の意味や役割を表現するために用語を使いこなす必要はあるのだが、さしあたって動くコードを書くためにあまり多くの用語を必要としないのはよいことである。

（※ ただし、準備が楽で必要な用語が少ないからと言って必ずしも学習コストが小さいとは言い切れないと思っているので、このような表現になっている。）

ある程度流行っている

個人的には、JavaScript を利用したシンプルな ViewModel フレームワークとしては Mithril が好きなのだけれど、いかんせん CSS フレームワーク、UI フレームワークと組み合わせるとか、単純にノウハウなどの流通において React, Vue.js, Angular に大きく水を開けられてしまっているのは事実である。

こうなると他のツールと同じことを再現しようとした時にはややコストの大きな環境になってしまいやすい。Mithril 自体の準備はそんなに大変じゃないけど、デザイナーが手を加えていくプロセスにおいてゼロベースのコーディングの量が増えてしまいやすかったり、何か意図通りに動かず困った事態に陥っても、とにかく自分で試行錯誤する以外の解決方法が見つからない可能性もある。

これがライブラリのアップデートに煩わされず、細かいデザイン要件のない業務向けなら CSS の優先度を下げて妥協するといった判断もできるが、Consumer 向けの Web を扱おうと思うとさすがにそういうわけにはいかないだろう。

Vue.js なら十分に流行っているのでそのような心配はほとんどないと言ってよい。安心してググれるし、情報交換が可能である。

PWAやネイティブアプリへの道もある

これらはさすがに標準対応じゃないけど、道があるという事実だけメモしておく。

現在のVueとの付き合い方

ノーフレームワーク（一部Babelだけアリ）
Rails + Webpacker
Nuxt（SSR 付き）

をやってみた¹ が、この中でバランス的には Rails + Webpacker で小さなアプリから始めるのがよさそうだと感じている。要するにサーバ側との統合作業も Webpack などの JavaScript 周りのごちゃごちゃとした設定作業も必要にならないもの、である。

逆にサーバ側と絶対に密結合にならないようにするために Nuxt で全部縛っちゃうというのもギプスとしてはアリかなという気がしている。少なくともこれが使いこなせればサーバ側の選択肢は広がる²。ただし Nuxt は SSR がすごい悩む。最初は SPA モードのみにするのもアリだとは思う。³

とりあえずサラから Webpack を書くのはやらないと決めている。このこだわりは正解だったと思っている。⁴

Vueの扱いで気をつけるべきこと

Vue Componentに過度の期待をしない

Vue Component で扱えること、Vue Component に書けることは限られている。基本的には

変更を監視するデータ
（ユーザの入力に対する）イベントハンドラ
VM Life Cycle Hook

くらいしかない。あとは変更を監視するのがデータそのものではなくメモ化機能付きの function か、extends 元があるか、くらいだ。

データバインディングはとても便利だ。変更の操作を記述する必要がない。しかしそれ以上は面倒を見てくれない。結局のところ人間の「考える」余地は大きく、設計がダメならコードが必要以上の複雑さを抱えてしまうのは普通のプログラミングと同じである。現実世界の課題は Vue Component というか React が集中しようとした ViewModel なコンポーネントで扱う範囲より広く、より複雑な形で存在している。

Vue Componentの外のコードを活用する

これはアセットバンドラがないとダメなので準備が楽という話と矛盾してしまうが、Vue Component の外にコードが置けることは重要である。

上にも挙げたが、Vue Component の中で function の書ける場所は基本的には computed か methods しかない。ごく単純に言い換えるとデータバインディング用かイベントハンドラ用である。

また Vue Component 同士で function を融通する方法は extends か mixin、要するに mixin である。雑に言うとフラットに function をぶちまけるだけで名前空間的にはぶつかりまくるし、Component から独立した function を融通する方法はないということである。

これはもう function をいい具合に管理することは Component のスコープから外したと考えるしかない。JavaScript が持っている機能は JavaScript の方で解決しましょう、普通に export / import しましょうということだ。Vue Component 以外を export / import すれば普通に class も利用できるし、Component から独立した共通の function を名前の重複を気にせず import することもできる。

VirtualDOMで扱えない世界や一般的なモデリングなどの手法に精通する

結局のところ現実世界の課題を分析し、適切なコードを書くには

HTML 5 時代の新しい要素である video や audio, canvas
Vue Component の外の Pure JS な世界
OOP や DDD などのパラダイム

に精通する必要があると言ってよい。

ViewModel コンポーネントが解決するのはあくまでごく一部なのだ。

Lifecycle Hookは用法、用量を守って

Lifecycle Hook は便利なのでついついいろんなことをさせてしまうが、Lifecycle Hook の中のコードが長くなると

function に分割されていないのでコードの意図を読み取りにくい
タイミングを制御しきれない場合がある
テストコードを書く際の stub out の単位がでかすぎる

といった問題が出てくる。これは歴史の中に学ことができる。昔なつかしい「コンストラクタ頑張りすぎ問題」だ。

Lifecycle Hook の中のコードを整理するためにも Vue Component の外にコードを分割して置くのが恐らくかなり重要なテクニックになると言ってよいと思う。

素振りとしては、素から、vue-cli から、Parcel からも試したが、実プロダクトとしては上の 3 つになっている。 ↩
単に API の役割を果たしてくれればコードベースを共有する必要もまったくない。 ↩
自分はなんか逃げたくなかったのでやらなかったけど ↩
結局テストコードのために書くことになるんだけど ↩

Pragger 続き

Jun 11, 2008

どうもこれまずい気がしてきた。

現在(Rev 100)の構造では plugin の中で依存している plugin を動的に読み込むことができない
したがって先に YAML をパースして、利用する plugin だけ読み込んで動作を軽くすることはできない
つまり今後も重くなる一方

うーん。ちらちら plagger も読んでるんだけど、こっちはやっぱきれいにできてんだよなぁ。もったいない。せっかく pragger は依存モジュール地獄に落ちずに済んだのに。

あ。Plugin クラスの load_plugins() をバラせばいいのかな？

def load_plugins()
  ファイルをリストアップしてぐるぐる do |file|
    register( file )
  end
end

def register( file )
  $plugins[ごにょ] = Plugin.new( file )
end

みたいな感じか？あ、register で与える file はフルパスじゃなくて plugin ディレクトリ以下じゃないと不便だね。

またドキュメントのためにコードを丸ごと文字列で持つのは RD とか RDoc をうまく使えば避けられるんじゃないかと思ったけど、よく分かんないorz Perl なら Pod 関係のパッケージですぐできるんだけど、Ruby ではやり方が分からない。いやビックリ。まさかオレ Perl の方が得意なんじゃね？まぁ全部文字列で持つとしても、少なくとも個々の plugin を選択的に読み込む機能がつけばだいぶ違うような気がする。うむうむ。やっぱまずそこか？

学校向けにPCリサイクルができるのか

Jun 11, 2007

スラッシュドットジャパン | 「学校向けWindows 98/Meインフォメーションセンター」でセキュリティ関連情報を提供

から

ICT教育推進プログラム協議会

スクール OS 無償プログラムは、学校に寄贈された PC が Microsoft Windows ( R ) OS のライセンスを持たない場合、あるいはライセンス所有の有無が不明確な場合に、無償で正規ライセンスを提供するプログラムです。

これは知らなかった。

けどあれか。自宅サーバで無料 OS 使ってた機械の場合はダメなのね。アレゲ人のお下がりに期待するのは結構難しそうだな¹。それに管理する側からすると全然違う機械がたくさんあっても困っちゃうよなぁ。中の人（教員）もそうだし、外の人（請け負う業者）も困る。あんまりいいことないよな。全部ネットワークブートでまかなえるようになるとか言うんなら話は別かもしれないけど。

学校向けの機械の難しさって、ストーリー中のコメントにもあるけど、周辺機器の複雑さなんだよな。しかもアプリの市場もそんなに儲かるわけではないので、異常に古いプラットフォームを前提にしているケースがままある。そして後継バージョンはないという状況。一般のオフィスワークからはかけ離れた、結構ヘビーな使い方してるんだよなー。JUST SYSTEM のアプリさえ動けばいいってもんじゃーない。

ドライバの問題やアプリの問題を解決しないと Un*x へ移行して経費削減、なんてのはかなり難しいだろうな。Edubuntu とか使ったことないけど、どういう工夫してるんだろ？そしてそれは日本にもマッチするのかな？

cf. Open Tech Press | Edubuntu：教育現場のためのLinux

自分のもアウト ↩

Frenzy is temporarily suspended

Jun 11, 2007

Frenzy 1.1 / Forum / Frenzy

うぉっつ。

しかしそこでじゃあオレ手伝うよ、と言えるほどモノが分かっていないのが悲しいところ。あんまりじっくりと OS の勉強できる状態でもねーしなぁ。にんともかんとも。（Debian Live だの浮気してる場合じゃないか？）

分かっている人は FreeSBIE でオリジナル Live CD をガンガン作って活用してるから Frenzy が遅れても困ってないのかしら？

epeg はちょっとクオリティ低いな

Jun 11, 2006

いやなブログ: Epeg で JPEG ファイルのサムネイルを高速に生成する

は以前から気にはなっていたんだけど、今回実際に FreeBSD に入れて、自宅サーバに入れている Singapore がもっと早くならないか試してみた。

epeg は C のライブラリで、PHP のバインディングは存在しない。しかし epeg コマンドが存在するのでもともと外部コマンドを呼び出してサムネイルを作っていた Singapore では利用しやすかった。¹

やることは thumb.php の中で $imagetype が 2 のときに imagemagick の convert コマンドではなく epeg コマンドを呼び出すようにするだけ。

はえぇぇ。

超はえぇぇ。

正直、C3 1GHz のサーバの性能そのものに限界を感じていたんだけど、まだまだ十分いけんじゃんと思わせるに十分な速度だ。

……。

あれ？

なんか画像が汚いなぁ。

あー。

分かった。本当にサムネイル向けなんだ、これ。ここで自分の環境を整理してみる。

手元の Singapore では 40*40, 120*120, 160*160, 700*600 の各サイズの画像を生成している
700*600 は閲覧用。それ以外はナビゲーション用。
汚いと感じたのは 700*600

要するに、epeg の縮小画像の生成はすごい速いけど、よく見るとアラが目につくレベルなわけだ。仕方がないので、700*600 の縮小画像を生成するときは epeg ではなく、従来通り ImageMagick を使うように設定した。

ちなみにリンク先の記事では ImageMagick に size オプションをつけるとかなり性能が向上するように書かれているが、手元の環境では size オプションをつけても思ったようには速くならなかった²。少なくともその状態でも epeg とは圧倒的な差があった。

そうすっとあれだな。ユーザーのアクションに追随しなければいけないような速度を要求されるサムネイルの作成（例えばアップロード済み写真の確認とか）には epeg を、くり返して「観る」ための画像の作成には ImageMagick をバックグラウンドで、と使い分けると気持ちいいアプリになるのかもしんない。

最初のうちは gd2 で画像の操作をしていたんだけど、gd では画像の操作が完了するまで PHP が何も返してこなくてブラウザがロックされたような状態になるので、外部コマンドを起動する方式になっていた ImageMagick に切り替えていた。 ↩
速くなったかな？って感じはするんだけど。 ↩

田舎に泊まろう石川県宝達志水町

Jun 11, 2006

すっげ。今まで見たことないくらいに断られてるわ。やっぱ北陸は閉鎖的なんだなって感じですなぁ、こりゃ。

まぁこの企画はそもそも女性には向いていないと思うけどねぇ。それにしたってこれはすげぇ。偉人て言ったのに、モーゼの墓なんつーオチがくるのも普通は予想できないって。

Free-ATX セレクション

Jun 11, 2004

日々

http://www3.soldam.co.jp/free_atx/live/

キューブ型でもベアボーンじゃないケース群のうちの一つ、Live1000.

これ + マザーで4万くらいか。HDD 2基搭載できて、静音性、冷却性もよいとなるとやっぱ惹かれるものがあるな。

Unison の運用考察 → 断念

Jun 11, 2004

Unison + Zebedee

Unison をすでによく使っている方の日記。誰かと思えば Wikicker の作者。

こちらの予想とは裏腹に、Zebedee では補えない問題がいくつかあることが判明。

サーバ側でミラーリング対象のディレクトリを制限できない
- これはプロファイルをうまく書けばできそうな気がするので追試
unison 単体では一切の認証不可
- rsyncd は単体で一応認証可能
- Zebedee を使おうにもまず fw で unison の素のポートを閉じる必要があるが、そういう fw が Windows には標準で用意されていない。

てことですな。とりあえず認証は置いておくとして、プロファイルでサーバ側のディレクトリをどうにか制限できないか、実験してみよう。

と思ったが、