最終更新: 2011-06-11T02:05+0900
ここに犯人がいます。言い訳すると、これは見逃してもしかたがないと思うの。(補記だし存在しない機能だし)
補記 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)
テストケースはこれから整理する。(パターン内でのコンテクスト×エスケープシークェンス×正規表現ライブラリ)
テストマクロを書いた。>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ベース、ですべてのテストに成功する。逆に、パッチなしだと期待した通りに失敗する。
掲示板>1571
コミット>r1923
* 違った。もうシラネっていってたやつだ。たぶん。
最終更新: 2017-09-15T10:23+0900
なんというか……ばっちい(だから非公開(書き直すつもりがないので観念した))。だらだら書き下すとこうなるのね、っていう。申し訳のように抜き出したカスタマイズポイントもうまく分離できなかった記憶がある。たんに切り取って別の場所に貼り付けただけだろう、と。svn logを見てみたら 2009年3月に書いたものらしい。最初はセクションごとに表示する仕様で、それだと日記を分断して邪魔なので一日の最後に表示するオプションを付けたとか。……logによれば。とりあえずこの日記(tDiary-2.3.3.20091124, Ruby-1.8.7-p248)では動いてるみたい。
「カテゴリ[……]の他の日記」リンクの URLはこの日記に特有の、最新表示とカテゴリ表示をくっつけたもののだから他の日記では使えないね(それも非公開の理由)。
2007年や 2009年の日記のタイトルが 2011年のこの日記から参照できてるのは「プラグインが自由に日記データを取得できる手段を提供した」恩恵を my-exプラグインが受けているからじゃないかと推測してる。
最終更新: 2011-05-30T23:46+0900
「カートに入れる」の結果と「カートを確認」の結果、それらと注文処理に進んだときに表示される注文内容が一致しない。カートに入れたはずの本が入ってなかったり、注文に進むとカートに入ってなかった本が表示される。
何となくつかんだからくりはこう。「カートに入れる」ボタンを表示してる商品ページは状態を持ってる。その「状態」に依拠してカートに商品を追加したりカートの内容を表示したりするのだけど、そんな、ページを表示したときのカートの中身やログイン状況に依存した処理が正しいわけがない。こっちは(Amazon以外ではよくある)忘れっぽいショッピングカート対策として、買いたい商品のページを一個一個タブに開いていって、ゲストのカートに追加されないようにログインして、最後にまとめてカートに入れてるんだから。
のが原因ぽい。偉大なる通販サイト Amazon様の解は、ログイン状態をキープし続ける(※)、だ。その上で、個人情報やお金に関する操作の前にパスワードを求める。アマゾンのログイン状態っていうのは OpenIDでも代替できるような、あるユーザーとあるユーザーを見分けるだけのもので特定の個人とは結びついていない(あるいは Windowsの UAC。普段の権限は低くしておいて必要に応じて昇格する)。ねぇ、なんで勝手にログインセッションを切ったりカートをすぐに空にしたりしたがるの？>有象無象のオンラインショップ。www.junkudo.co.jpは、ブラウザを閉じるまで有効って期限を明示してるだけマシだけど。不都合ばっかりじゃない。
※アマゾンのヘルプに
カートに入れたはずの商品がカートに入っていない
2.アカウントにサインインせずに、商品をカートに入れた
この場合は、サインイン後にあらためて商品をカートに入れてください。
ってあるけど、ログイン状態ログアウト状態を取り混ぜてカートを操作してもカートの中身は一貫性を保ってた(おかしくなったのは「カートを見る」ボタンに表示された商品数だけ)。アマゾンはほぼ常にログイン状態であることに頼ってるわけではなさそう。たぶんこういうことだ。
丸善＆ジュンク堂書店も同じような仕組み(ブラウザカートとアカウントカートとその間の商品移動)は持ってる。想定外だったのは、アカウントカートに商品を入れる(cart-account.png)でも、ブラウザカートに商品を入れる(cart-browser.png)でもない変な状態(cart-hatena.png)になるルートが存在したこと(でもそんなんタブでもマルチウィンドウでも当たり前にありうる操作だ)。想像するに、
ってところではないかと。
最終更新: 2011-06-12T18:07+0900
変化など。
ディスクローター・マウントを使う予定はないのだけど、黒はシルバーと違って一種類しかない(FH-M770-S相当が用意されていない)のでいらなくても付いてくる。ゴムのカバーが付いてるので想定された使い方。
「素早い駆動力の伝達を可能にするフリーハブボディ:爪がかかるまでの角度を減少」とのことで、空転させるとチチチチチチチチ細かく音がする。しかも音の質が変わっていて前より響く。
裏からの見た目は Sunraceの方が上。曲線で構成された相似形が少しずつ角度を変えて並んでた。
リムの幅が細くなった。ひとまわり、サイドの厚み×2ぐらい。リムテープはシュワルベの水色 18mmが苦もなくぴったりはまった。タイヤも初めてタイヤレバーなしではめられた。空気圧は 80から 90くらい(単位不明)にしてるが、WH-T565のリムテープには何の問題も見当たらなかった。
リムが細くなったのでブレーキシューが届かなくなった。厚みの違うカラーを入れ替えてパッド(舟)を近づけた。そろそろ(アームはそのままで)ブレーキパッドだけでも TEKTROから換えようか。
WH-T565にはやらしい(bladed)スポークが付いてたよ。知らなかった。反フリー側はラジアル組みだし、することはしてたんだ。翻って新しいホイールのスポーク。耐久性を犠牲にして色気をだすつもりはなかったのに 1.8mmになってしまった。2.0mmだったら折れても「寿命かな」で済むけど、意に反して 1.8mmになった以上たぶんに悔いが残るだろう。
ワイヤーを巻き取るレバーの軸がハンドルバーから遠くなった。どちらも一気に三段シフトダウンできる仕組みなのだが、SLXの場合レバーが弧を描くというよりどんどん遠ざかっていってしまうため、レバーがハンドルバー手前に飛び出すように取りつけ角度を工夫しても指の長さが足りなくなる。必須の機能というわけではないけど、2.8目盛りくらいまで押し込んでから「やっぱり無理」とレバーを戻したのでは無駄。指の当たる面が凹(Alivio)から凸(SLX)になって非常に押しにくい。俺は摩擦力に頼ったデザインは嫌いだ。巻き取りレバーを近くに持ってこようとブレーキレバーの内側に設置するとリリースレバーとブレーキレバーが一緒に指にかかってしまう。2-wayリリースのためか知らないけどトリガーが大きくなってるし長すぎるし。
2-wayリリースって使い方がわからなかったけど、海外のサイトに thumb-thumb or thumb-triggerって書いてあった。リリースも親指でやろうってことなのか。
CN-HG73への疑惑を晴らしただけで CN-HG50が無駄になってしまった(20110429p01)。コネクトピン(5個入り約600円)を買えばまた使えるけど 8-speedをこれから使う機会はないだろうな。
そのまま使える。スプロケットが 8速から 9速になってロー側への移動量が足りなくなっていたので Lと書かれた方のネジを緩めて調整した。
リアディレイラーのプーリーをベアリング入り(無音)にしたい。ブレーキワイヤー(inner/outer)とシフトワイヤー(inner/outer)を新品にしたい。ワイヤーカッター高い。ブレーキの舟をテクトロから換えたい。シューも、雨の日に使うといっぺんになくなってしまう S70C(後ろに使ってる)や、長持ちするかわりにガシガシ リムを攻撃する M70R2(前に使ってる)の代わりを見つけたい。最近はタイヤ(700×28C)をみるたびに太いなぁなんて思ってしまう。ちょっと前まではこれが普通だと思ってたのに。次は Synapse Flat Bar 105に乗りたいぞ。
最終更新: 2011-05-19T13:48+0900
7. In app code, never use force_encoding to convert BINARY data into a particular encoding. By the time you've reached app code, you have lost the information about which encoding is being used. Instead, find where the String came into Ruby, and fix it to set up the encoding based on the information it knows.
アプリケーションコードの場合、バイナリデータを特定のエンコーディングに変換するために force_encoding を決して使わないこと。アプリケーションコードをいじっているのであれば 使用されているエンコーディングに関する情報をたたくさん持っているはずである。 この場合、その文字列がどこからRubyにやってきたかを突き止め、わかっている情報に 基づいてエンコーディングを設定するように修正すること。
いまもって Ruby 1.9のエンコーディングに関するベストプラクティスがわからないので、すごくためになるリスト。7はこう理解した。
(文字列のエンコーディング情報が失われた)末端コードで、(その場で必要とされるエンコーディングに基づいて場当たり的に) force_encodingしないこと。その文字列の来歴をたどって一番根っこ(※ライブラリの修正が必要かも)で正しい情報(※ないのなら慣習に従うか、その不完全なプロトコルを捨てる)に基づいて force_encodingすること。(末端コードで必要に応じて行うのは encodeだったり encode!)
最終更新: 2011-05-16T15:33+0900
モノ、ジ、トリ、テトラ、ペンタ、ヘキサ、ヘプタ、オクタ、ノナ、デカ。 理科の教科書の巻末にギリシャ文字と並んで紹介されてたのを何とはなしに覚えてしまった。リンピョウトウシャカイジンレツザイゼンとか寿限無みたいなものか。わりと使われてるので記憶が強化されて忘れられない。
これ、そうかな？ってのを挙げていってみよう。
モノマー。モノラル。モノリシック。モノポリー。
ジクロロベンゼン。ジアゾ基。ジレンマ。ダイオキシン。ダイオード。ダイアミター？(ダイア・ミーターではなかったのねん)
tribool. トリプレット。トリオ。トリトン(トリトーンや海のトリトンは違うかも)。トライアスロン。トライリンガル。トライアル……は違うか。
テトリス。テトラポッド。テトラパック。ネオンテトラ……はどうかな？
ペンタゴン。ペントミノ。ペンタックス？
ヘキサデシマル。ヘックスレンチ。
無い。Septemberとか関係ないかな？無理かな？
オクトパス。オクターヴ。オクトーバー。オクテットストリーム(1byte=8bitsのときバイトストリームと同じ？)。オクタヴィアヌスはどう？
無い。nineとか neunの源流っぽいかなー？ 検索したら nonet(九重奏)だって。
デシリットル？。デケイド(アクセントはデ)。デカスロン。デシマル。
オリゴ糖。オリゴペプチド。
ポリマー。ポリゴン。ポリペプチド。ポリエチレンテレフタラート(PET)。ポリノミ……アル。ポリリン酸。日本ポリグル株式会社(TV(ガイアの夜明け)と新聞(GLOBE)で見た)。
nona-は使われてるのに気付いてない可能性が高そうだけど、ヘプタの(特徴的な音と比べた)影の薄さときたら。
最終更新: 2011-05-10T18:49+0900
どういう関数？>「改行のエスケープシーケンス（'\\'+'n'）で区切られる文字列の個数を数える（WCHAR版）」
使われ方>「複数行指定方法の改善（正規表現パターンの行数とダイアログ設定値の大きい方を採用する）」
これだけ対応していないなら「正規表現による」というより、\nというエスケープシーケンスにだけ対応した普通の検索といったほうが当たってる。正規表現ライブラリに今以上の機能(hitEnd)を求めないのなら、これが最大限度の対応なのかもしれないが……。GetCountOfDividedStringWには期待せず、ダイアログで 100とか設定しておけば大体はうまくいくのかもしれない。
どういう関数？>「０文字マッチや改行文字の途中を考慮した置換文字数の補正値を取得する」
なぜ必要？>ドキュメントの操作がビュー経由でしか行えないため、ロジック単位で行った検索をレイアウト単位に変換してから置換を実行しなければいけない。置換関数の中ではレイアウト単位をロジック単位に変換して……といったことがもちろん行われるわけで……ムキー、ってなことを 20100907p01.03に書いた。
とりあえずロジック単位で置換範囲を指定できる置換関数をどこかに作ろうとして、20100709p01の複数行置換の実装は止まっている。CMultiLineSearch::GetCompensationLengthを使うアプローチはこれまでのやり方を踏襲するもので、置換範囲と置換文字列をレイアウト単位境界にそろえてから置換関数を呼び出す。計画倒れよりできあがってる方が偉い。
