2011年06月10日 (金) 「「三大」 - みねこあ」新しく三つあげるのはしないけど、既存の三つがいけてないのはすぐわかる。どれも目的でなく手段や結果でしかない。その三つを聞いても OOPが何者なのかわからない。OOPの精神が伝わらない。そういうわけで唯一生き残った「ポリモーフィズム」も俺にはわからない。それは必要に迫られて使うけれど、あえて推す理由は？ 複数のタイプを対象にした目的を同じくする利用側の(ソース)コードを一つにできること？「カプセル化」を言い換えるなら抽象化の他に「自律性」はどうだろう。そして C++のクラスでは、実装の詳細をカプセル化(アクセス制限や不可視化)して抽象を提供することはできるけど、並列実行世界での自律を保つには不十分なんだよね。複数の実行軸に貫かれる C++のインスタンスはいっぱしのオブジェクトではなくしょせん傀儡なのですよ。指向する中心にあるとはいえない。
2011年06月09日 (木) 「Appleに殺されてしまうひと達まとめ、あるいはプラットフォームに依存するということ - yifeの日記」Appleは OSからデバイスからエコシステムまで握ってやりたい放題じゃないか。独占的な立場を利用してるといって OSと分離させることはできないの？それとも印象に比してまだまだ俺みたいに他人事(ひとごと)で済ませられる人も多いのかな。
2011年06月08日 (水) Coders at Workにあった定型質問の一つ。全員が全てのコードを共有し変更するのか、一部の人が所有し変更するのか。オブジェクト指向、クラスベースでやるなら所有者がいた方がいいと思ってる。一人二役でやるにしてもクラスの利用者視点と実装者視点を切り替えることは絶対に必要。クラスが何に依存し何を提供し何を提供しないのかを決めるために。切り替えられないと癒着する。担当者が別だと被使用クラス対使用クラスがそのまま人間対人間のやりとりになって自然に適切な距離が保てそうな。スピードは遅くなるだろうが。
2011年06月07日 (火) 「bron250beta1.7z (148,135bytes) : 次期バージョン向けβ版（\R, \K, \X などに対応）」 このダウンロードサイズはさすがの 7-zip。どのパターンも知らないので調べた。\Rは改行全般(CRLF,CR,LF,VT=垂直タブ,FF=書式送り,NEL=NextLine,LS=LineSeparator,PS=ParagraphSeparator)にマッチする。文字クラスの中では使えない。\Kは、これより左のパターンにマッチしたものをマッチ結果から除外する。戻り読みより使いやすい(けど \Kの左右なんてくくりは簡単にアクセス可能にできるんだからマッチの利用法に制限のある状況専用)。\XはUNICODE複合文字の並びにマッチするとか。基底となる文字＋オプションでウムラウトや丸囲みみたいなものの並び、だろうか。Unicodeに対応した . みたいなもの。ハングルの合成用の字母の並びはたぶん違う(よね？)。### なんちゃって hitEndを付け加えてるからアップデートは少し面倒。### ちゃんとドキュメントあるし。bregonigでは \R=(?>\x0D\x0A|[\x0A-\x0D])だから NEL,LS,PSにはマッチしない(鬼車自体が USE_UNICODE_ALL_LINE_TERMINATORSを定義しないと NEL,LS,PSを改行とみなさない)。\Rだけでもそうだけど \r\Rも CRLFにマッチする。
2011年06月06日 (月) いつからだろう、viewvcがコミットログの rXXXXをリンクにしてくれてる。そういうふうにして参照してきたから嬉しい。
最終更新: 2011-06-06T23:39+0900
♪ [SHJS] 色分けを確かめてみるページを作った。
http://vvvvvv.sakura.ne.jp/shjs/test.html?lang=JavaScript;theme=golden
Firefox 4.0.1でだけ、なんとか、動くことを確認してる。サンプルソースはそのページの初期化スクリプト。JavaScriptの色分け(sh_javascript.js)と Rubyの色分け(sh_ruby.js)だけ、オリジナルの shjs-0.6とは異なる。
2011年06月05日 (日) Cannondale BAD BOYを見つけたのって、たぶん中学生のときから使ってる財布のせいだ。それを何かの折にネットで検索した。2003年頃。
最終更新: 2011-06-05T22:03+0900
♪ [SakuraEditor] 固定長のタイプ別設定って
タイプ別設定一覧ダイアログの見せ方だけで、並べ替えたり可変長に見せかけて(実は上限は30で変わらない)削除・追加を受け付けたりできるよね。
それが行われるとファイルタイプを選択するツールバーボタン(リスト)のアイテムの並びも考えないといけなくなるけど。
2011年06月04日 (土) 「痛いニュース(ﾉ∀`) : 外人 「なんで日本では○が正解でチェックマークが不正解なの？意味不明」 - ライブドアブログ」 スペック表で、あるフィーチャーが存在するかどうかを示すのに✕印が使われていたりすると相当に迷う。もちろんそれは日本のサイトではない。✕や✓はどちらも否定でネガティブで打ち消しだという認識があるからなあ。考えたことなかったけど、○と正しいことの間に文化的なものでない繋がりってないのかな。
2011年06月02日 (木) ATOK2009の補完はいまいち。一度入力した単語は二度と最後まで入力したくないのに、一度は候補に出てきた単語がどんどんどんどん忘れられていく。あと、最長の候補が最初から出てこない。同じ文章を再入力するときでも、末尾の一語だけしか補完できないなんてことがよくある。
最終更新: 2011-06-04T20:36+0900
♪ [SakuraEditor] 文字の幅。代替表示。色分け・強調。
画像の通りに、メイリオUIをインストールしてから日本語文字(Consolasにリンクされたメイリオ)が半角になる。メモ帳もそう。素のサクラエディタでは半角表示の日本語に全角のマス目を割り当てて字間に謎の空白が表示される。画像でそうなってないのは CNativeW::GetKetaOfCharを、文字コードの範囲によらず常にフォントを通して字幅を得るようにいじったから。性能に大いに悪影響を与えるだろう。気にならないけど。で、それだけだと Deleteキーを押したときにキャレットと離れた位置の文字が消えるようなことが起こる。そういうときはキャレットの左側に□で表示された全角空白があったりする。(半角で表示される)全角空白を(半角で表示される)□と表示する view/figures/CFigure_ZenSpaceが□を描画した後にカーソルを無条件で 2進めるために CNativeW::GetKetaOfCharの返す値との間に齟齬を生じていた。文字の幅や高さをコードポイントから決めることはできない。それは代替表示や部分強調も絡めてビューが決めること。
2011年06月01日 (水) あかん。r1921をマージするのは死ねる。ファイル構成(※)が違うし名前が違うし DoChangeColorとかもうないし。※SColorStrategyInfoは CColorStrategyのインターフェイスの一部(CColorStrategy.hの中に入れるもの)ではなく、その利用者 CEditViewに属するものだと思うんだよね。本来無関係な CEditViewの一部を取り込んでおいて #include "view/CEditView.h"(※2)とか、その引きずってるものの大きさを考えたら気違い沙汰ですよ。と思ったので色分けを SHJS方式にしたときに構成を変えたのだった。※2 #includeはコメントアウトされてるように見えるけどヘッダの中で Viewのメンバを呼んでるからむしろ何でそれでOKなの？ .cppに移動させてもリンクのコストが無駄に増えるのは変わりない。CColorStrategy.hをインクルードする他のファイルに無駄な依存を伝播させることはなくなるけど。### r1921のマージはアイディアを借りた再実装と同じだとわかった。だったら今はやらない。
最終更新: 2011-06-11T02:05+0900
♪ [SakuraEditor] BugReport/82 - SakuraEditorWiki 正規表現検索の不具合
ここに犯人がいます。言い訳すると、これは見逃してもしかたがないと思うの。(補記だし存在しない機能だし)
補記 3. Perl 5.8.0と比較して存在しない機能+ \N{name} + \l,\u,\L,\U, \X, \C + (?{code}) + (??{code}) + (?(condition)yes-pat|no-pat) * \Q...\E 但しONIG_SYNTAX_PERLとONIG_SYNTAX_JAVAでは有効
bregonig.dllは ONIG_SYNTAX_PERL_NGを使ってるみたいだから \Q...\Eは有効。bregexp.dllは \Q...\Eをサポートしていない。
パッチはこれ。>regex_trick_coping_with_qeescape.patch(13.3KB, 2011-06-01)
テストケースはこれから整理する。(パターン内でのコンテクスト×エスケープシークェンス×正規表現ライブラリ)
@2011-06-02
テストマクロを書いた。>test_regex_trick.js(5.0KB, 2011-06-02)
そうすると、\c\\ みたいなパターンに対応できていないことが新たに判明した*。ちょっとだけ修正したパッチはこれ。>regex_trick_coping_with_qeescape.rev2.patch(13.3KB, 2011-06-02)
手もとでは bcc32で作成した sakura.exe(1.6.6.0 with bregonig-1.45)と VS2008EEで作成した sakura.exe(2.0.2.0 with bregonig-2.02)、ともに Revision 1922ベース、ですべてのテストに成功する。逆に、パッチなしだと期待した通りに失敗する。
@2011-06-10
掲示板>1571
コミット>r1923
* 違った。もうシラネっていってたやつだ。たぶん。
2011年05月30日 (月) Windowsなら Alt+D&Dや、クリップボードにコピーして適当なフォルダで右クリック(OR Ctrl+Spaceでファイルの選択を解除してから Shift+F10か App key)、「ショートカットの貼り付け(&S)」でマウスや右ボタンを使わずにできるかと。
2011年05月29日 (日) カムイがまたやってくれた。見てるこちらの心拍数も上がるラスト10数周だった。
2011年05月26日 (木) [tDiary] 編集機能ってなくてもいい。むしろない方がいい。でないと際限のない誘惑に負けるから。Hikiのような履歴管理がおとしどころかな。あれでも「なかったこと」にはできないから。各リビジョンに URLも割り振って……。
2011年05月24日 (火) パンストの続編見たいな。
最終更新: 2017-09-15T10:23+0900
♪ [tDiary] 同カテゴリのセクションへのリンクを表示するプラグイン(sections_of_a_category.rb)。
なんというか……ばっちい(だから非公開(書き直すつもりがないので観念した))。だらだら書き下すとこうなるのね、っていう。申し訳のように抜き出したカスタマイズポイントもうまく分離できなかった記憶がある。たんに切り取って別の場所に貼り付けただけだろう、と。svn logを見てみたら 2009年3月に書いたものらしい。最初はセクションごとに表示する仕様で、それだと日記を分断して邪魔なので一日の最後に表示するオプションを付けたとか。……logによれば。とりあえずこの日記(tDiary-2.3.3.20091124, Ruby-1.8.7-p248)では動いてるみたい。
「カテゴリ[……]の他の日記」リンクの URLはこの日記に特有の、最新表示とカテゴリ表示をくっつけたもののだから他の日記では使えないね(それも非公開の理由)。
2007年や 2009年の日記のタイトルが 2011年のこの日記から参照できてるのは「プラグインが自由に日記データを取得できる手段を提供した」恩恵を my-exプラグインが受けているからじゃないかと推測してる。
@2017-09 書き直した(リンクはそのまま)。
最終更新: 2011-05-30T23:46+0900
♪ www.junkudo.co.jpのショッピングカートが腐ってる。(Firefox4.0で見た場合。念のため)
「カートに入れる」の結果と「カートを確認」の結果、それらと注文処理に進んだときに表示される注文内容が一致しない。カートに入れたはずの本が入ってなかったり、注文に進むとカートに入ってなかった本が表示される。
何となくつかんだからくりはこう。「カートに入れる」ボタンを表示してる商品ページは状態を持ってる。その「状態」に依拠してカートに商品を追加したりカートの内容を表示したりするのだけど、そんな、ページを表示したときのカートの中身やログイン状況に依存した処理が正しいわけがない。こっちは(Amazon以外ではよくある)忘れっぽいショッピングカート対策として、買いたい商品のページを一個一個タブに開いていって、ゲストのカートに追加されないようにログインして、最後にまとめてカートに入れてるんだから。
- ログインしてない状態で商品ページを表示して、
- 他のページでログインしてから、
- (ログインしてない状態で表示した商品ページから)カートに入れた
のが原因ぽい。偉大なる通販サイト Amazon様の解は、ログイン状態をキープし続ける(※)、だ。その上で、個人情報やお金に関する操作の前にパスワードを求める。アマゾンのログイン状態っていうのは OpenIDでも代替できるような、あるユーザーとあるユーザーを見分けるだけのもので特定の個人とは結びついていない(あるいは Windowsの UAC。普段の権限は低くしておいて必要に応じて昇格する)。ねぇ、なんで勝手にログインセッションを切ったりカートをすぐに空にしたりしたがるの？>有象無象のオンラインショップ。www.junkudo.co.jpは、ブラウザを閉じるまで有効って期限を明示してるだけマシだけど。不都合ばっかりじゃない。
※アマゾンのヘルプに
カートに入れたはずの商品がカートに入っていない
2.アカウントにサインインせずに、商品をカートに入れた
この場合は、サインイン後にあらためて商品をカートに入れてください。
ってあるけど、ログイン状態ログアウト状態を取り混ぜてカートを操作してもカートの中身は一貫性を保ってた(おかしくなったのは「カートを見る」ボタンに表示された商品数だけ)。アマゾンはほぼ常にログイン状態であることに頼ってるわけではなさそう。たぶんこういうことだ。
- ログイン状態でのカート(IN)とログアウト状態でのカート(OUT)が別々に存在する。
- カートINはアカウントにひもつけて永続化される。
- カートOUTはブラウザにひもつけて永続化される。(つまりブラウザの数だけ存在する)
- カートOUTの中身は可能なかぎり速やかにカートINに移される。(つまりサインインしたときにってこと)
- サインアウトするとカートINの中身は見えなくなる。(カートOUTの中身は移動済みなのでカートは空になったように見える。サインインすると中身は戻ってくる)
丸善＆ジュンク堂書店も同じような仕組み(ブラウザカートとアカウントカートとその間の商品移動)は持ってる。想定外だったのは、アカウントカートに商品を入れる(cart-account.png)でも、ブラウザカートに商品を入れる(cart-browser.png)でもない変な状態(cart-hatena.png)になるルートが存在したこと(でもそんなんタブでもマルチウィンドウでも当たり前にありうる操作だ)。想像するに、
- ブラウザカートに商品を入れてみたけど、
- どういうわけだか(嗤)もうログインしている。(アカウントカートに商品を追加すべきだった)
- もうログインしているからブラウザカートの中身をアカウントカートに移す機会はない。
- ログアウトするとブラウザカートの中身は消えてしまう。(ブラウザカートの中身は移動済みで空のはずだった)
- おまけに、ブラウザカートに商品があるとログインしていてもアカウントカートの中身は見られない。(不適切な依存関係、誤った論理あるいは優先順位の錯誤)
ってところではないかと。