トップ «前の日(03-01) 最新 次の日(03-03)» 追記

2004-03-02

_ VikiWiki と blosxom

VikiWiki は本家でもエラー出まくりなので、やっぱりどうも期待できないんだなということにして放置することにした。とりあえず WikiFarm は PukiWiki でどうにか工夫するということで。(Unix なら Symlink が使えて楽なんだが。)まぁ mod_ruby の実験にはなったのでよしとしよう。

blosxom は PHP 版の完成度が高くないが Perl 版のぐちゃぐちゃしたコードがいやで、とりあえず Ruby 版を探し始める。PHP 版の足元にも及ばないくらいに完成度の低いものが見つかる。うーん。pyblosxom ってのもあるが、Python はあんまり見たくないし、xrea で使えない(はず)なのでこれもなんだかなぁ。本家 blosxom がコマンドラインじゃなくて CGI で static HTML を出力できればそれでいいのかなぁ。BASIC 認証だけ掛けておいて。えーん、Perl もいじりたくないなぁ。

Tags: Web Ruby Perl

_ 肉がもたれた

今ごろ思い出したが、そういえば閏肉の日に焼肉を食べていた。(閏肉を 忘れたわけでも食べたメニューを忘れたわけでもないが、リンクするまで に2日掛かった自分の頭。。。)安くてよいと評判だったので行ってみた チェーン店。

もたれた。

金沢の焼肉はたかちゃんに限るとの思いを新たにした。でも、たいがい 混んでて入れないんだよなぁ。大人数なら予約していけるんだけど、4人以下での予約不可は確認済みなので、タイミングをはかる、ねばる、以外に方法がなかったりする。

Tags: Food 日々

_ FreeSBIE

FreeBSD の Live CD その名も FreeSBIE なのであるが、、、重い。回線が重過ぎて全然ダメです。

うえーん。

Tags: Unix News

2006-03-02

_ 自分の行為の正当性はどこからくるのか

404 Blog Not Found:取材拒否の理由

別に今さら大上段から NHK やマスコミ批判をしたいなんてことはこれっぽっちも思っちゃいないんだけど、自分の正しさを信じて疑わない人は案外いるよなぁって思った。

もちろん、常に自分の正しさを疑うことでそれが自信のなさに繋がり、臆病でビクビクした挙動不審な人間になる*1とか、何かの宗教などにすがって思考停止してしまうという状態になるのも困るんだけども、まるっきり疑いがないというのもやっぱり困るんだな。

例えばそれが好意の押し売りレベルの日常的な程度なら愛想笑いしてりゃいいんだけど、マスコミや免許稼業*2の中には何らかの特権が世間やお上によって与えられていると勘違いする人も出てくる。まぁ個人的には出てきて当然かなとも思う。

自分の場合を振り返ってみると、なんていうか、振り子のように自信満々モードとマジヘコミモードの間を行ったりきたりしてるような、そんな感覚だ。単振動っていうほど単純ではなく、その周期も振れ幅も不定。振り子運動へ加わるエネルギーは外からのものもあれば中からのものもある。*3

例え話のままいくと、上に出てくる「困った人」っていうのは、外からのエネルギーだけでどっちかにばーんと行ったまま帰ってこない人のことなのかなと思う。たまにいる電波くんは中からのエネルギーだけでどっちかに行って帰ってこない人かな。

何が言いたいかっていうと、振り子でどっちかに寄ったままっちゅーのは重力に逆らった不自然な状態なので注意しましょうってことですよ。特にどっちかに振れやすい環境にいる人はね。まぁ、自然な状態を維持するのもそれはそれで大変なんだけどさ。

Tags: 生き方

*1 自分にもそんな時期はあったし、これからもどうなるかは正直分かんない。

*2 先生先生言われる職業とかね

*3 本当は振り子じゃなくてバネやゴムの縦波の方がイメージとしては近いんだけど、例えとして分かりにくいのでやめた。


2007-03-02

_ リアルタイム性と記録性、閲覧性、検索性の間

ITmedia Biz.ID:“社内IRC”を駆使するエンジニアの仕事術とは――モバイルファクトリー・松野徳大さん

こ、こんな若かったのか…。というのは置いといて。

irc + bot + plagger っつーのは確かにいいかもしんない。IP messenger のフォルダ添付もかなり便利で、(ファイルサーバを経由しちゃうとどこ行ったか訳分からなくなったりするような)こまいデータをリアルタイムにやりとりするにはものすごく重宝するんだけど、こういう応用はできないんだよな。

実は内部向け irc は一度試そうと思ったことがあって、というのは前から言ってるように Classic Mac も混ざっているネットワーク上ではまともなメッセンジャーソリューションてないわけ*1。じゃあ irc かなぁと思って実験してたんだけど、そのときは「(確か試した Classic 用のクライアントが)DCC send でファイルを送ろうとすると死ぬほど遅い」ということで断念したような気がする*2。文字だけなら IP messenger でもカバーできてるしってことで*3。ただこういう全体のシステムと同期させるってのは考えてなかったなぁ。

確かに以前にやりとりした情報を閲覧するとか検索するってことになると、Web ベースの方がなんとなくしっくりきたりする*4。でも入力の段階では Web ベースってのはちょっとだるい。専用のインターフェイスがあったりするのも意外と面倒。URL を特定するのが面倒だったりね*5。irc と連携させちゃうことで両方を一気に解決するってのはかなり面白い。irc bot って漠然とは興味持ってたんだけど、こうなると俄然面白そうだ。

ただこの irc ベースって、人数に制限があるような気がするんだよな…。100人、200人の体制で irc ってのはかなり無理があるような。channel 分けできる分、IP Messenger で行くよりは現実的だけど、例えば一時的に別な部署と情報を共有したいとかって要求になるとちょっと難しくなってくる。複数の channel に手動で入る操作って結構面倒くさいんだよな。起動して自動で入るようになってるだけなら簡単でいいんだけど。あ、それも bot 任せにすればいいのか。自分で手で channel に入らなくても bot が全体の情報を扱うシステムに転送して、そこから例えば複数の channel に bot が broadcast なんてこともできるのか。おぉすげぇ。妄想だけならどんどんシステムが膨らんでいくわ。

Tags: Tool Net

*1 Classic Mac を捨てろという正論はとりあえず置いておく。

*2 DCC なんだからサーバの問題じゃないよねぇ?

*3 ログは各自の判断で残すこともできるし、検索とかはお任せってことで。ま、たぶんそんな機能があるってことを知ってる人はほとんどいないだろうけど。

*4 これは最近 RSS リーダーべったりになっちゃったからかもしんないし、データの取り込みさえできればインターフェイスはみんな同じにできそうっていうのがもう見えてるからだな。

*5 Widget とか bookmarklet にすればいいのかもしんないけど。


2008-03-02

_ リベンジシリーズ第2弾 J.B.ハロルドの事件簿

TSUTAYA で見つけて衝動買い。

当時残り1人か2人くらい登場人物に会うことができず解けなかった本格推理アドベンチャーですよ! 捜査資料を自分で紙のノートのうえに作って行く過程がまた楽しくて非常に面白かった、そして悔しかった思い出のあるゲームだ。

風呂の友が増えた。(レイトン教授は残ったナゾのレベルが高くなりすぎてコンプリートできないまま挫折している。)

……。

あれ? 解けなかったのってマンハッタン・レクイエムじゃね? あれ? 全然違うゲーム買った?

Tags: 日々

2019-03-02

_ View FrameworkインスタンスをControllerに預けて管理してもらう現実的で雑なClean Architecture

[2019-04-11 追記]最初 Use Case に預けると書いたけど、Interactor の仕様が constructor のないものだったので Controller に変更しました。

まとめ

Web FrontendでClean Architectureを試す - Qiita を読んで違和感を覚えたので、もうちょっとざっくりでいいし React に詳細突っ込みすぎでは?という気持ちを整理しようと考えてたらたどりついた現時点での考え方。ざっくり言うと

  • MVVM でやってることの範囲をそのまま広げれば Controller まで適用可能なのでは?
  • 枯れたライブラリにもっと任せるとよいのでは?

と思った話。

もっと雑に言うとタイトルの通りで View Framework を Controller に DI しちゃえばだいたいイケんじゃね説。

※ もちろん PubSub や EventBus に置き換えてもよい。少なくとも View Framework を直接 DI してしまうと Framework への変更の通知が直接手続きになってしまいやすい。そうなると密結合となりやすく、View Framework の詳細を知らないといけなくなる。ここは注意が必要。Usecase の実行後の処理も View Framework 側にイベントで通知する形を強制するには PubSub の方が安全ではある。*1

Clean Architectureってなんだっけ

The Clean Architecture - Clean Coder Blog

Clean Architecture はざっくり言うと具体的なテクノロジー、詳細を外側に置き、原則的に外から内へ依存させようという考え方。処理の流れと依存関係が逆転するところがある。テキストで無理やり有名な図を描くとこんな感じ。

+----------------------------+
| Devices                Web |
|  +----------------------+  |
|  |     Controllers      |  |
|  |   +--------------+   |  |
|  |   |  Use Cases   |   |  |
|  |   | +----------+ |   |  |
|  |   | | Entities | |   |  |
|  |   | +----------+ |   |  |
|  |   +--------------+   |  |
|  | Gateways  Presenters |  |
|  +----------------------+  |
| DB                      UI |
+----------------------------+

ではWebフロントエンドってなんだっけ

まず前提として昨今の View Framework は Presenter から Web / UI の層を担っている。というか Web フロントエンドって言ってるんだから当たり前で、そもそも中心ではなく比較的周辺の領域を扱っている。

この View / UI Framework という周辺事項から内側の Controller へは普通に依存を持つことができる。

しかし View / UI 以外の情報も扱う必要がある場合、例えば Storage や Network を扱う場合は、以下の問題にぶつかる。

  • まず Network や Storage などは View / UI コンポーネントの関心外
  • かつ Controller / Use Cases から周辺に依存しない方がよい

じゃあUseCaseを意識しつつViewFrameworkとどう付き合うのがよいのか

上の問題に対する解として例のサークルで言うところの Gateways と Use Cases の境界を曖昧にすることで、以下のように書ける気がする。例は雑に Vue.js + ES2015+ で書いてある。

☆ App.vue
<script>
import Controller from 'controller_case'

export default {
  created() {
    this.controller = new Controller(this)
  },
  methods: {
    handler1() {
      this.$emit('event1', val1)
    },
    handler2() {
      this.$emit('event2', val2)
    }
  }
}
</script>

「Controller に対して ViewModel 自身を DI する」ことで中心を Controller 側にずらす意味合いを表しているつもり。

考え方としては Backbone.js, Angular 1 以降に定着し、ViewModel コンポーネントも実際にやっている、「依存を片方向に限定し、反対方向はすべてイベントで伝える」ということを頼りにしつつ DI で依存関係を逆転させるというもの。

Controller のインスタンスを this の中に保存しているのは単に消えてしまわないようにするためだけで、実際には View / UI Framework から Controller の何かを操作するといったことは行わない。

☆ controller.js
import Repository   from 'repository'
import RemoteFacade from 'remote_facade'
import Interactor   from 'interactor'

class Controller {
  constructor(vm) {
    this.vm = vm
    this.initListeners()
  }

  initListeners() {
    this.vm.$on(event1, usecase1)
    this.vm.$on(event2, usecase2)
    this.vm.$on(event3, usecase3)
  }

  async usecase1(val1) {
    return await Repository.foo(val1)
  }

  async usecase2(val2) {
    return await RemoteFacade.bar(val2)
  }

  async usecase3(val3) {
    return await Interactor.run(val3)
  }
}

Controller 側は ViewModel インスタンスの特定のイベントを処理できるようにしつつ、関連する Repository や RemoteFacade, Interactor などもここで初期化している。

大事なのは Repository や RemoteFacade, Usecase Interactor は外側の技術的な詳細そのものではないということ。あくまで Gateway 的なものですよという言い訳と言ってもよいかもしれない。少なくともここを見ると「何と何を使って何をしようとしているのかは分かる」くらいの粒度に収めたいというのが前提にある。

各 use case はメソッド一つで処理できるかもしれないし、中身が複雑になったら class に分けてもよい。Operator とか Command とか Service とかそんなやつ。Clean Architecture 的には Interactor.

今回改めて考えてみたこと

上で意識したのは

  • View / UI Framework のコンポーネントは*2それだけで複雑であり、その初期化に関して必要以上に情報を持ち込まない方がよい
  • View / UI Framework は「entry point ではあるが全体から見ると周辺事項」であり、「全体を見る人は別にいた方」が扱いやすそう
    • 全体には当然 View / UI 以外も入る
  • Repository や RemoteFacade の詳細は気にしたくないので書かない。その向こうは依存の方向が内→外になる可能性もあるが、気にしない
    • テスタビリティの確保なら stub out とか方法はある
    • 必要ならこれらを Factory にして具象 → 抽象の依存の方向を実現することはできる
  • Repository と Factory の関係は Usecase Interactor にも適用できるかも
    • 直接インスタンスを作るのではなく Factory 経由で全部 constructor DI にするとか

こうしておけば例えば WebRTC などが増えた際には素直に WebRTC を中心に追加できる。*3

いずれにせよ、いかに Clean かということよりも、

  1. View / UI Framework の中だけで頑張りすぎないこと
  2. いかに独立してテストしやすくするかということ
  3. そのうえで関心外の情報が一気に全部見えないようにすること
  4. 中心的に見なければいけないのは Controller / Use Cases であり、そこを見ると関連をたどりやすいこと

を考えている。

本来の Clean Architecture はフレームワーク非依存な考え方だが、現実的にはなんらかのフレームワークが考え方の起点となっていることは多い。

実際に Web フロントエンドはなんらかの View / UI Framework を採用することはほぼ前提と言ってよく、これらのフレームワークでは DOM や Event といった最も外側に位置する最も詳細なテクノロジーから一段階距離を置く手法が取られている。そしてこれと同じことは Storage や Remote Facade 系のライブラリにも言える。

つまりそれぞれの領域において概ね成熟したライブラリに任せていることは同じであり、必要以上に Clean な依存の方向にこだわりすぎてコード量が増えて特定のところで一気に依存解決する複雑さが見えてしまうくらいなら、まずは思い切ってざっくり View(UI) / Storage / Network くらいに分けてそれらをコントロールする人を中心に置く方が全体の見通しは楽になるし、個々のライブラリの機能を生かすことでテスタビリティは十分確保できるので、こんなもんでいいんじゃないの?ということを考えている。

逆に言うとこの考え方では cookie も localStorage も Fetch API もブラウザネイティブのものは極力直接使わないことを前提にしている。

で、「これはフレームワークから距離を置いた方がよい」と考えた場合には、グッと Clean Architecture に寄せてコード量を増やしてゴリゴリ書けばよい。

TDD も Clean Architecture も考え方を参考にしつつ、現実には増えるコード量とコスト感との兼ね合いの部分は必ず出てくる。その際に

  • どこが中心か
  • どこは任せてよいか
    • 外側の詳細に直接タッチしていないか
  • 特定のフレームワークの中だけで頑張ろうとしすぎていないか

くらいだけを気にしておけば、「そこそこClean」な状態は維持できるんじゃないかなーという感じのことを最近は考えている。

参考

Tags: JavaScript

*1 Vueの場合、空っぽのVueインスタンスをEventBus ( EventHub ) として使う方法も公式に紹介されてたりする。https://vuejs.org/v2/guide/migration.html#dispatch-and-broadcast-replaced

*2 以前よりシンプルになっているとは言え

*3 もちろんその役割を表す一段抽象化してものだが