トップ «前の日(02-05) 最新 次の日(02-07)» 追記

2003-02-06

_ Opera 7.01 リリース

さくっと出ました。タイミング計っての発表だったのかもしれませんが。

http://www.zdnet.co.jp/news/0302/06/nebt_01.html

Tags: Tool News Web

2004-02-06

_ 職場の ADSL を 1.5 → 24 に契約変更

実測値は 500 〜 700kbps 程度から 1.3Mbps 程度に。倍にはなったが、釈然としない。まー予想通りと言えば予想通りなんだけど、あまりに予想通りすぎて悲しい。

ただし、合わせて変更したルータの効果がなかなか大きい。少なくとも「通信が詰まる」感じはなくなった。NAT のセッション数の限界か何かで全然セッションを開始できない問題もほとんど解決した。速さはほとんど実感できないが、ストレスはだいぶ減った。これだけでもよしとしなければいけない。

Tags: Biz 日々 Net

2006-02-06

_ zsh + screen 環境で単に cd って打つと挙動がおかしい

  • screen を使ってないとおかしくならないので先日の zsh スクリプトの影響だろう
  • zsh 4.2.5 + screen 3.09.15(OSX)では問題ない
  • zsh 4.0.4 + screen 3.09.11(Debian 3.0 x86)で問題発生

screen の window title が空っぽになっちゃって、何をしても画面上に反応が出なくなる。current の window を閉じちゃえば使えるが、なんか食い違ってるらしく、リフレッシュさせないと画面が壊れてしまう。

cd ~

ってやれば回避できるんだけど、なんか気持ち悪いな。


2007-02-06

_ DOM で要素の絶対的な位置を計算してみる

※ 長さの割に内容はありません。先にあやまっておきますごめんなさい。

ことの発端はある部分のデータ量が多くてそこだけ縦に長くなっちゃってレイアウトが見苦しいので調整したいという要望だった。

んなもん紙じゃねーんだからバランス取ろうとする方がおかしいんだ

と思ったけれども、CSS(overflow: auto) + JavaScript(style.height をごにょごにょ)でなんとかなるかなーと思ってやってみた*1ら HTML の組み方によっては厳しいことが分かってきた。要は

旧石器時代に滅んだはずの table レイアウトってやつ

だ。あれは難しい。なぜなら table は内容全体に応じてセルの大きさが伸縮しちゃうからセルの大きさそのものは計算してもみんな同じなんだな、これが。中身がスカスカで見た目のバランスが崩れているかどうかは、セルの大きさを比較しても分からないわけ。

じゃあってんで内容の方に注目してその height を比較して調整すればいんじゃね?と思ったんだけど、デフォルトの margin なんかがあって意外とうまくいかない。マジックナンバーを投入するとなんとなくうまくいってるように見えるんだけど、ちょっと変更が入っただけで簡単に破綻してしまった。

じゃあ height じゃなくて注目している要素の bottom を比較できればいいんだなと思ったけれど、これをすんなり取得する方法は DOM にはないっぽい。offsetTop, offsetLeft てのはあるんだけどこれは親要素を原点としているので、ページレイアウト上の絶対位置は取得できない。

あれまーと思ったんだけどこういう方法で取得してみた。ある要素の上辺の、ページ内における絶対的な位置を取得する関数*2

function top( obj ) {
  var pos = 0;
  if ( obj ) {
    pos = obj.offsetTop;
    if ( obj.offsetParent ) {
      pos += top( obj.offsetParent );
    }
  }
  return pos;
}

※ 横着してますが obj は DOM の HTMLElement オブジェクトが入ってきていると思ってください。

offsetTop が親要素に対する相対位置なのだから、てっぺんの要素まで再帰でさかのぼって行けばいいじゃんていう話。試したところ狙い通りの値が取れてるみたいなんだけど、なんかおかしいこと考えてるかもしれないんで、気づいた方はツッコんでください*3。一応 Opera 9, MacIE 5, WinIE 6/7, Safari 1.3, Firefox 1.5/2, iCab 3.0.2(build 382) で大丈夫みたい。つか今どきのフレームワークにはこういう機能すでにあるんかもしれんなぁ。

bottom の方は top + height を計算すればいいだけなので割愛。left, right も同じ要領なのでこれまた割愛。というかたぶん調整したいと言われるのは縦方向だけだと思う。

*1 ページング処理すれば?ってのはこの場合デザイン上ナシの方向で。

*2 実際にはこんながっつりグローバルな関数じゃないんだけど。

*3 親要素をはみ出しちゃうようなダイナミックな CSS レイアウトは考慮してません。つかそういうデザインなら今回のようなことは考える必要ないもの。たぶん。


2009-02-06

_ Net::SSH で明示的に password 認証に

twitter log 掘り起こし日記。

12:55:10 wtnabe< デフォルトと違う設定の ssh で capistrano を使おうとし
て大ハマり中
13:19:15 wtnabe< なんか :auth_methods の扱いもおかしいっぽいなぁ
13:20:57 wtnabe< passphrase を聞いてくるのが謎い
13:22:25 wtnabe< 自分自身の passphrase を使うわけではないので
:auth_methods を password に限定すると認証に失敗する
14:32:21 wtnabe< :ssh_options[:keys] = [] にしたら passphrase 聞いてこ
なくなった

Net::SSH 単体ではなく Capistrano で使っていたんだけど、

set :ssh_options[:keys], []

にしたってことです。

何のことかと言うと、自分の環境で ssh connection 絡みのテストをやると自動的に自分の config が反映されて面倒なことになっちゃったりするので、その辺をリセットするために行った措置だったりします。

※ 関係は薄いのですが password を Capfile の外から与えられないとまずいよなぁと思ったのと、どの程度のできるのか確かめたくて CLI.ui も試してみました。これは

HighLine

highline というライブラリを使っているわけですが、こいつが、なのか Capistrano の CLI の使い方が、なのか readline が効かない状態。対話的な処理を真面目に作り込もうとするとちょっとキツいかもしれません。

cap shell

は readline 効いてるのにね。


2011-02-06

_ bluepillを知る

最近 Ruby 関係のことを知るのに都合のいい情報源は

  • E和の人のtweet
  • Stack Overflow

であることが多い。いやもちろんるびまも重宝していますが。

というわけで bluepill もそんな情報源から知った一つ。何かと思って調べたら Matrix 的なものではなく、

God が memory leak するから書いたものらしい。それ以外に気になるのは syslog に落とせるくらいか。そんなに大きな違いはないというかむしろものすごく God に似ている。

とりあえず今 God で困ってないんだけど、押さえておこう。

[2011-02-15 追記]

Ruby 1.9.2 の問題という話もあるみたい。

Twitter / @Tohru Hshimoto: そういえば、1.9.2ではrubyのバグのため安定し ...

Tags: Sysadmin Ruby
本日のツッコミ(全1件) [ツッコミを入れる]

_ しばた [SEO的な意味で便利!というメリットもあります:)]


2019-02-06

_ 大雑把にViewコンポーネントから責務をひっぺがしていくフロントエンド設計

Vue.js を利用すると仮定して、だいたいこんな感じに登場人物を分けるといいんじゃないかというメモ。View フレームワークのコンポーネントの分類の話ではなくて、コンポーネントに限らずに単純に責務を分離しようとしているだけ。

考え方の基本は以下の2点。

  • 並行作業のしやすさ(クリティカルパスの短縮)
  • テスト容易性の確保

以下、仮に UI を決める component の名前を UI.vue とする。なお、☆の数は現時点で考えている重要度を表す。

☆☆☆ Model.jsとの分離

データによって UI に変化が起きるデータバインディングの部分は「データ取得の仕組み」に依存してはいけない。

  • View が Vue コンポーネントから data をセットされる際、その仕組みの詳細に依存する必要はない
    • YAML を直接読み込んでいようが API にアクセスしていようが View には影響しない
  • つまり Vue コンポーネントの中にその仕組みの詳細を置いてはいけない
    • 置いてあったら詳細の変更の影響を受ける

上の考え方を適用すれば「View」と「データ取得、反映の仕組み」の開発は分離して同時に行えるのでお互いの作業をブロックしないし、それぞれ自動テストに対応させやすい。

もちろん、設計段階でお互いに連携しなければいけない責務は 考慮はしておく。例えばデータの取得に失敗した場合のユーザーへのフィードバックの方法などは Model でエラーの種類などを整理したうえで View にどうやって反映するかを考えておかなければいけない。

この辺をまず大雑把に Model と呼び、View component から分離しておく。この考え方で言う Model は特定のフレームワークに依存する必要はないので VanillaJS で書いておけばよい。attribute の扱いやエラーの扱いなどの共通の処理を内包するなんらかのライブラリがあるならそれを使ってもよいかもしれないが、Model すなわち State を持つ Store というわけではない。ここ重要。

☆☆ Container.vueとの分離

Container と Presentational の分離の話。methods, data, props, $emit の話。

例えば分離しておけば Model を仮置きしておいて後で差し替えるといった際に UI.vue 側は何も変更する必要がない。

cf. Vueで雑にContainer Component - あーありがち(2019-02-03)

☆☆ Error.vueとの分離

  • エラー処理をいちいち if で分岐すると処理の本質を追いにくくなる
  • 例えば Error.vue を用意し <Error v-if="errors.length > 0" :errors=errors> で丸投げ

ViewModel から見て model.errors と this.errors の 2パターン用意できるかも。

※ ActiveModel::Errors の考え方を転用。

☆ ModelとModelState.jsの分離

  • Model と ModelState は分けてよい
  • Flux 系 Store は State だけ担っていると考えればよい

☆ ModelとInteractor.jsの分離

Clean Architecture 的な意味での Interactor みたいな何か。Model 一つで処理できなければ、複数の責務にまたがる一つの処理にまとめる人を用意する。

errors も relay していく感じ。

まとめ

こんな構造になるかな。

Container.vue (3)
  `-- UI.vue (1)
  |    `-- Error.vue
  `-- Model.js (2)
  |    `-- errors
  `-- ModelState.js ( nearly equal Store ) (4)

順番としては 1, 2, 3, 4 で考えたらいいんじゃないかと考えている。Interactor を入れるとこんな感じかな?

Container.vue (3)
  `-- UI.vue (1)
  |    `-- Error.vue
  `-- Interactor.js (5)
  |    `-- ModelA.js (2)
  |    |    `-- errors
  |    `-- ModelB.js
  `-- ModelState.js ( nearly equal Store ) (4)

書いてみて思ったんだけど、こういう考え方だから、世間でよく観測される ViewModel コンポーネントの分類の話や Model == Store みたいな話にピンとこないんだなぁということが分かってきた。

Tags: Vue.js Web