Time Travel Debuggingってなんだっけ

Vuexを用いた開発プロジェクト用にガイドラインを作成した話 - Qiita

を読んで、

最終的にチーム内で合意に至ったのは「パフォーマンスが懸念されるなどの特別な理由がない限り、原則として全ての状態をVuexのStoreで管理する」という方針です。

この決定に至った理由としては以下が挙げられます。

• Time Travel Debuggingが可能になるため、デバッグがしやすくなる
• テストがしやすくなる
• 複数人による開発の中で状態管理に一貫性が生まれる

というくだりを読んで、あれ、Time Travel って Vuex 使わないとできないんだっけ？ と思って確認してみた。

試してみた

Vue DevTools 5.0.0 で確認（なぜか 5.1.0 がうまく動かなかった）

Vue DevTools 上の Vuex タブで mutations の履歴を取得できる。この mutation は record された単なる events と違い、実際の変更の記録であり、以下の3つの操作を行える。

• export
• import
• commit all

ということで、「手元で起きたことを他の環境に持って行って」再検証することができる。

これが Time Travel Debug.

あーこれ Event Sourcing の話にも通じるのか。

Eventとの違い

Vue DevTools 上では Event も record できるのだけど、Event は単なる Event であり、record はできるが replay はできない。

これは Event はどこで起きるかもその結果を受けて何を行うかも自由なので replay の難易度が高いということかな？ Vuex Store への「変更」に関しては確実な操作（ユーザーの操作ではないけど）の記録であり、Vuex Store 上で replay することは Event をそのまま replay するより難しくない気がする。component が正しく Vuex の state の変化に対して Reactive に動作すればこれで十分である。

雑感

各 component のレベルで data の変更に対して Time Travel できるとより便利っぽい。でもそれができれば先のガイドラインの判断基準がなくなっちゃうのか。

それとは別に Event の export くらいはできるようになってほしいんだけどなぁ…。思わん？

ときどきの雑記帖 リターンズ 2007年5月 - awkってつくづく影が薄い喃

いやぁ。両方使いますけど PHP の方はやっぱ変な感じがしますよ。JavaScript も書くので awk と JavaScript は似ている感じしますけど、PHP の配列だけとても違和感があります。確かに便利に使えるシーンは多いんですけど、PHP から入っちゃった人は気をつけておかないと、他の言語で連想配列やハッシュと言われるものが思った通りに動かない問題にぶち当たると思います。

1. 道を鴨がゆうゆうと歩いていて、危うくひきそうになった
2. 意を決して ThinkPad を修理しようと思ったら見積もりだけで2万近く取られるところだった
   • 結局自分でパーツ買って直す決意をしたよ

2 のついでに。

プログラマに最適なPCって？ - てくのーと Splash☆Star

を読んで思っていたことを書いておこうっと。なぜプロに ThinkPad が受けるのか？

それは金が掛かるうえにブランドが持ち主の心をくすぐり続けるからではない。

• 自分の手を動かせる人間にとってこの機械は安心で、かつとても安上がりだから

である。

この話を説明するには「道具を手に入れること」と「お金を出してモノを買うこと」がイコールでないということをまず伝える必要がある。　

バイク乗りならこの話はスムーズに理解できると思うが、自分の道具は自分で手入れをし続けてこそ快適に使い続けることができるのである。自作機もそう、楽器も包丁もカメラもみんなそう。道具を本当によい状態で使い続けるためには自らその道具を愛し、手入れをするのがいちばんなのだ。そしてそれが可能なノートPC が ThinkPad なのである。

理由は ThinkPad 使いには常識すぎて今さら書くまでもないことだが、

• 分解マニュアルが本家サイトから手に入る
• 個人でもフツーにパーツ単位で購入が可能。そしてこれが安い。

の2点である。こんなことができるノートPC が他にもあるのか自分は知らないが、少なくともこれがあるから ThinkPad に安心感を抱いている人は多いはずである。¹

別にプロでなくたってそれなりに頑丈であるという理由だけでも ThinkPad を選んでいいと思う。しかし世間一般での ThinkPad の利用率と、オープンソース系のカンファレンスなどでの ThinkPad の利用率は恐らくものすごく違うはずである。自分の周りには自分の薦めた以外の非IT系の人が ThinkPad を使っている例はない。というか普通は薦めても Let's note の方を選ぶ。

だが上のことを知っていると、安心して型落ちの ThinkPad を買うことができる。ドライバや BIOS アップデートもサイトから手に入れればいい。多少壊れても自分で直せるし、液晶をつかんで本体を持ち上げてもフツーは壊れない。そういう、自分の手を動かして自分の思う通りにしかも安価に使い続けることができる感が ThinkPad の良さなのだ。

もちろんこういうことをわざわざ書く人間は、当然のようにキーボードの感触にもトラックポイントの使い勝手にもやられまくっている。間違いない。そして多少の重さや同時期の他社のマシンと比べたときのスペックの低さなどはまったく気にならなくなっているのである。²

以上が起きている間中キーボードを叩いているような人たちの間に ThinkPad 使いが多い、一つの理由である。

収納グッズを手に入れた。

上はで、なんか財布だの携帯だのをあまり考えずにつっこむところ。日用品をとりあえず散らばらないようにするために使う。こういうのはなんて名前なのかよく分からなくて結構調べにくい。自分の中ではカゴとかって感じになるんだけど、そういうカテゴリってフツーないよね。ケースってカテゴリで片っ端から見ていかないとなかなかちょうどいいのが見つからない。

下はで、二段あるのでどちらかを処理の必要な書類や請求書、もう一方を領収書だのの一時保管に使う。¹レターケースっていうのね、こういうの。A4 がちょうど収まるけど大きすぎず重くもない。なかなかいい感じ。

あんまりこういう「浮かない」レターケースってないんですよね。事務用品だと普通の家具にはまず合わないし、プラスチックのものはカラーボードとかメタリックなラックにはあんまり違和感ないかもしれないけど、チェストとか木の家具には合わない。あとおしゃれなやつもそうだけど、家具に傷がつきやすそうな作りになってることがある²とか、大きすぎるとか、意外と選ぶの大変。³

こういうの、前からほしかったんだけど以前は腰よりちょっと高いくらいの棚がなくて、収まりのいい場所がなかったんで放置しまくりでテーブルがものすごいことになってた。これでやっとテーブルの上のものが少し減らせる。

いやーストレージの設計って難しいな(違

※ 晒し上げっていうか、向こうの方が人気blogなんだけど。

家計簿が欲しい！ - てくのーと Splash☆Star

JavaScript が有効ならできるだけストレスなく操作でき、かつ w3m でも編集できるとチョー嬉しいです。あと Rails 依存はやだな。

MoBo でつけてたんだけど、全角半角の処理が不親切とか編集が月全体になって重たいとかで挫折したもんで、別な実装におおいに期待するところなのでありました。

MoBo を直す気はあったんだけど、どうしても優先順位が低くなっちゃうのと、本家 commit までの道のりがどーも遠く感じるので結局何もしてないですが。

先日書いたファイルのカタログを作成するもの が AppleScript で作れないかなと思い、ちまちまと調べながら Script Editor と格闘。やることは

1. 対象となるフォルダを指定して
2. カタログ情報の出力先を指定して
3. find TARGET
4. 結果を受け取ってリストにして
5. リストに上がってるファイルに対して順番に情報を取得して、それを付加して
6. ファイルに書き出す

という流れになるんだけど、2 と 5 の、要するにファイルの書き出しがよく分からないというか今のところうまく行かない（すでに開かれているだの、開かれていないだの、目的に合致した状態にならない。）。そこを無視すると一応できたんだけど、結果が今のところダイアログにしか出せなくて、まったく使いものにならない（画面に収まらない）。

初めての AppleScript の感想は、

• 基本の構文が英文ライク（な end 構文）でタイプ量が多い
• フリーフォーマットでないというか、複数行に気楽に分けて記述できない
• 暗黙の変数 Result に頼りまくりなのは Perl や Ruby のようでもあるけど、あんまり気持ちよくない（Result を壊さないようにするためにスクリプトの記述順序に気を使う）
• OS X での AppleScript は do shell script 命令のおかげでものすごく楽ができそうだ
• AppleScript 内ではパスは Classic 風に扱うが、POSIX パスと簡単に相互変換できるので助かる
• 他の言語でポピュラーな文字列処理の関数（命令？）がない¹ので、その辺も全部外部のコマンドに頼ってしまいそうだ（ファイルの出力も do shell script でリダイレクトしたら？と言われたが、さすがにちょっと躊躇している。）
• しかしいかにも UI をかぶせただけって感じになってしまうといささかかっこ悪いので、AppleScript Studio が使いこなせると気持ちよさげ
  • とりあえず Inerface Builder も動かしてみたけど、いやぁ Aqua な UI やメタルな UI ができてるよー。かっこいいよー。見た目がいいとモノがよさげに見えるから不思議だよー。
• 逆にコマンドラインで AppleScript を使うのも便利そう。それも可能らしいけどまだよく分からない。

なんだか可能性はずいぶん広がった気がする。

• 説教講座 BookMark さらにサルベージ
• PHP のデバッガ調査

教えてもらったのでメモ。NetBIOS なのか？という疑問は残るが、まぁそれは言うまい。（もう言ってるけど。）

しかしそうまでして Windows の共有って使わないかんもんですかね。。。

先日

• yahoo.co.jp
• hotmail.com

からのメールを受信拒否するようにしたが、今日新たに

• yahoo.com
• star-beach.com

も拒否。

もじら組は最近見てないから気づいてなかったけど。

ハタから見ていても namazu.org の管理体制がしっかりしているとは思えない。新版が出てもまともなリリースノートすらないし、そもそもが非常に古きよき牧歌的なグループに見える。もともと大学的なノリと言ったらいいか。。。namazu.org にアカウント持ってても現在は Namazu に参加してない人の方が多いんじゃないかと思うくらい。

オープンソースという単語がビジネスの世界でさかんに言われ出して以降のオープンソースグループは namazu.org とは違う。彼らは明らかに「ライセンス」と「組織」についてある程度の見聞がある。（見識があるとまでは言わない。）しかし namazu.org はだいぶそういう組織とは違うように見える。

もじら組についてはよく分からないけど、手を広げすぎてる感じがしないでもない。

開発プロジェクトでもドキュメンテーションプロジェクトでもいいが、すべてのプロジェクトにサーバ管理、ユーザー管理のスキルのある人間が居るとは限らない。というかむしろ居る方が稀だろう。sf.jp もアタックを受けた（正確にはあるプロジェクトの XOOPS 用のプラグイン）が、それでもなお、素人のグループの用意したサーバよりは信用できるような気がする。（ここ1年は過負荷のためかやたらとメンテ中のことが多いが。）可能なら、そういうリソースを利用するようにしておいて、バックアップを自分たちのサーバに持ってくるようにしておいた方がリスクヘッジになる。人数が増えて運用体制がしっかりしてきたとか、帯域やプロセッサパワーを食いすぎてどうしようもないとか、そうなってから自分たちのサーバを用意すればいいのではなかろうか。

もちろんこれはそうしたリソースが充実している今だからこそ言えるわけで、namazu.org 設立時にその選択肢があったわけじゃないけど。

鵜飼さんの Wiki に情報が集まりつつあります

個人的にはなんで大熊さんが反論しているのだ、というのが気になります。つーか煽り返してるし。おいおい。「だって自分は別に今回の発表で使われるなんて思ってないもん」てことなら「コミュニティとやら」なんて言葉を持ち出してそのコミュニティとやらに燃料を投げてやらんでも。不明確な部分を補足しておしまいにしとけばよかったのに。

みなさん、単に一企業がクライアントに説明しやすいように作った資料とやらと、それを作った人に踊らされすぎじゃないすか。まー自分が今回のオープンソースの定義に合致するソフトを作って発表してたらそんな悠長な気分じゃいられなかったかもしれないけど。

とゆーか、お願いします。モノ書きにも合いの手、違う愛の手を。えぇまぁ、たいしたことしちゃいませんがね。いぢいぢ。yomoyomo さんくらいにビッグになったらもう少し偉ぶろう。（無理だって。つーかキャラ違うしね。）

（みなさん仰るように、まつもとさんの日記がおすすめです。リンク張ると tDiary に補足されるので上の WiLiki から辿ってください。しかし大熊さん、鵜飼さんの目に止まっちゃったらオープンソース界隈で仕事しにくくないすか？ 他人事ながら大丈夫？）