最終更新: 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を使うアプローチはこれまでのやり方を踏襲するもので、置換範囲と置換文字列をレイアウト単位境界にそろえてから置換関数を呼び出す。計画倒れよりできあがってる方が偉い。
最終更新: 2011-05-12T14:37+0900
今は後ろだけシマノの完組ホイールが付いてる。
フレームのリアエンド幅が MTBの 135mm. 最初から付いてたタイヤのリムのサイズがロードの 700C. ロード向け完組ホイールのハブは 130mm幅にしか対応してないし、MTB向け完組ホイールの小径・幅広リムはいただけない。タイヤ径が変わると Vブレーキの取り付け位置も変わってくる。2万円と少しで工具を買って MTBハブとロードリムの組み合わせで手組みするのが割と現実的な選択肢。手組みは入り組んだスポークが見た目にうるさいのが唯一の不満。変則組みで解消できるけど自分では安全と耐久性を担保できないし……。
結局、日和って組んでもらうことにした。XTハブ+CXP33+DT Champion 2.0+真鍮ニップルといったありきたりな構成。選択肢がもともと少ない上に、駆動力のかかる(Vブレーキだけど制動力も？)リアホイールなので 1.8mm径のスポークやアルミニップルは選べなかった(小心者)。スポークは DT Competition 2.0/1.8の方が良かった。スポークが切れるのは端っこ(後輪だと特にテンションの低い左側)だというから真ん中は 1.8mmでも大丈夫そう。OpenProリムのセラミック加工がブレーキ面の色的にベストだし、CXP33より軽いんだけど、ブレーキシューの変更が必要になるのとブレーキの効きや音がどうかわるかわからないので避けた。雨でもシューが減らないらしいのもポイントは高いのだが……。CXP33の三角リムが前輪とおそろいだというのが CXP33を選んだ一番の理由。二番目は OpenProは手組みの定番中の定番だということに対する幼稚な抵抗。
今のタイヤがダメになったらひとつ細い 25Cのタイヤにして更なる慣性質量の減少を目指す(転がり抵抗もおまけで)。まち乗りだと信号とパチ屋の出入りの車によるストップ＆ゴーが多すぎるからこぎ出しの軽さが重要。
DT Champion 2.0 黒が欠品とのことで DT Competition 2.0/1.8 黒で組んでもらうことになった。しかし余分なお金が……。
DT Competition 2.0/1.8 黒も欠品と判明。黒の真鍮ニップルもないみたいで結局 DT Champion 1.8 黒とアルミ黒ニップルになった。壊れなければ 1.8mmでもアルミでもいいんだけど……(耐久性は落ちるよね)。パーツの入手性が悪すぎる。9速のシフターだって、Deoreも SLXも XTも、どこも在庫してないし。
？ 後上方にすっとんでいくような力がハブに(そしてスポークに)かかるような気がした。ディスクブレーキだと駆動力と反対の力がまんべんなくかかるような。Vブレーキとスポークの関係はディスクブレーキの場合と比べてどう？
最終更新: 2012-09-03T17:57+0900
負荷をかけると力が逃げてたたらを踏む。スプロケットのあたりを観察してると、チェーンがふくらんだように見えて、そしてガクっとくる。タイヤを空転させてるときは問題の徴候がないので、隣のギアに浮気しようとしてるのとは違うみたい。テンションがかかると歯と歯の間に収まるべきチェーンの駒が歯の上に乗っかってしまうんだろう。伸びたチェーンを使い続けたせいでスプロケットがそちらに最適化されてしまったとでもいおうか、一昨日チェーンを新品にしたせいで症状が出たと思われる。
症状が出るのはリア 1-8速のうち 3-6速。難を逃れたギアに理由をみつけるなら、1速は全く使わないから。2速は発進後 1から数秒で 3速に上げてしまうからと、径が大きく多くの歯に負荷を分散できるから。8速はオーバートップギアなのでよっぽど舗装が良く平坦な道路でないと使えない稀なギアだから。7速は事実上のトップギアなので加速のために使うことがほとんどないから。
チェーンを CN-HG50に換えても変わらなかったので、9速用のチェーンのせいではなかった。
ゴールデンウィーク明けまで直せないのが痛い。なんでそろいもそろって休むんだよー。
最終更新: 2011-04-28T00:00+0900
チェーンは CN-HG73。
標準のチェーンは 110リンク。アウター×トップの組み合わせでガイドプーリーとテンションプーリーが垂直線上に並んだので CN-HG73も 110リンクにカット。アウター×ローでリアディレイラーがかわいそうなほど引っぱられてるがローは使わないので良しとする。
接続部(チェーンカッターでコネクトピンを押し込んだところ)の動きが渋すぎる。山を作ったらテンショナーのバネの力では戻らない。そのせいだと思うが、リアの 3-8速(径の小さいギア)でカタン、カタンとチェーンが滑るような現象が起きる。後輪に動力が伝わらないよ。いつになったら全力でこげる。
最終更新: 2011-04-28T01:14+0900
5. COM オブジェクトのインスタンス作成
COM の初期化が済んだので、次には COM オブジェクトのインスタンスを作成する方法について確認しましょう。既に触れたように、今回のサンプルでは [6] の CoCreateInstance 関数を呼び出すことで、COM ベースのオブジェクトである Shell Link オブジェクトのインスタンスを作成しています。この [6] の Shell Link オブジェクトの作成の様子を、あえて C++ プログラミング スタイルで表現すると次のようになります (実際にはこのように書けません)。仮にクラス名を CShellLink とします。
例 1.5 インスタンスを作成し、特定のポインターで参照する
IShellLink* pShellLink = (IShellLink*) new CShellLink();
間違ったコードを書いて拡散させてはいけない。正しいコードを書いて導くこと。どうしても間違いを紹介する必要があるときは、コードそれ自体に間違っていることを主張させる。たとえばこの場合は
IShellLink* pShellLink = (IShellLink*) new CShellLink(); // 間違い！
とでもする。記憶も不確かな受け売りだけどね。
参考までにこのコード片を読んだ俺の反応。
頭から順に読んできたけど、問題のコードのすぐ上のパラグラフはまだ読んでなかった。サンプルコードは目をひくし、図や表と同じように何が書いてあるかをざっと掴む手がかりにもなる。ところがとんだトラップだ。
今月号のクーリエジャポンは福島の放射能汚染に関して風評被害がどうのといって白雪姫の風刺画を紹介してた。存在は知ってたがどういうものかをそこで初めて見た。文脈がどうであれ自分が拡散に荷担してる自覚はある？ Webなんかでも消えて欲しいと思うものに対して、引用して欠点をあげつらったり批判を加えたり、あげくご丁寧にリンクまではるのは逆効果。無視して埋もれて消えるに任せるのが一番。