/ 最近 .rdf 追記 設定 本棚

脳log[2015-03-05～]

最近

2015年03月05日 (木) [Firefox] とうとう Firefoxにもルビが……(縦書きが仲間になりたそうにこちらを見ている)。「Ruby support in Firefox Developer Edition 38 ✩ Mozilla Hacks – the Web developer blog」全然違和感なかったけど参考画像が超電磁砲(レールガン)だ。■以前にもリンクを張った去年の７月の記事「CSS3のルビ機能を考える - ちくちく日記」■待っただけあってすごくいい。自分にとってはあれができないこういう不都合があるということのない全部入りだし、むしろそこまでこだわる？という部分(space-aroundと space-betweenの違い)もあり、それでいて冗長さのない使いやすいマークアップになってると思う。省略と補完を前提にしたタグの使い方はセパレータとして理解できる。こんなんだったら hikidoc.rbに追加したルビ記法(20121128p01)の仕事なんて記号からタグへの逐次的な置換だけで済んでしまう。■もろもろの理由があって Firefoxのバージョンアップは 23.0で止まってしまってるけど(20131210)、ちょっと悩むな。ちょっとだけ。

ツッコミを入れる

2015年03月04日 (水) アイロンその後(前出:20141109)。1)アイロンはもちろんだがアイロン台が暖まってからが本番。2)簡単なところからかける。折り目をつけた所は扱いやすくなる。3)引っ張るのは縫い目に沿ってか生地が伸びない方向に。あとは重力そしてアイロン台との摩擦を利用してしわを伸ばす。4)アイロンは引っ張ったのと同じ方向に動かす。面を利用すれば縦横に動かす必要はない。下手に生地を伸ばしてしまうと面倒なので。5)重ねた生地を相手にするときは圧力をかけるのが有効。でないと下側がいまいちシャンとしない。■■■@2015-05-25 湾曲したアイロン台はいらいらするね。袖口とかボタンのあいだとかアイロンの先っちょで細かい部分のシワを伸ばそうとすると、してるつもりなのに、よく見ると浮き上がっていてさっぱりだ。■湾曲してるのの何がいいのかと検索してみた。人体のカーブに合わせてあるからシャツが密着する？さいわい立体裁断を相手にする必要はまだない。点で接するから滑りがスムーズでシワを寄せにくい？でも俺は面でプレスしたいんだよ。普通のアイロンは大きすぎて接触点(かけ面の真ん中へん)で隅々までカバーできないんだよ。シワが寄りやすいなら生地の向きや縫い目を読んでアイロンを動かす方向をひとつに決め、その一端を左手でつまんでおけばいいじゃない。滑りはアイロンの方のニッケルやらセラミックやらチタンのコーティングに任せた。スムーザーなんてのもあるって。

ツッコミを入れる

2015年02月28日 (土) バズワードっぽいなとだけ知っていたが、最近読んだ本にも出てきた。「「ナラティブ」概念について - Togetterまとめ」■本は『[単行本] マイケル・S. ガザニガ【〈わたし〉はどこにあるのか: ガザニガ脳科学講義】 紀伊國屋書店』。いわく左脳にはインタープリターが存在し事後的に現象(自分の行動)を解釈しているのだと。でも事後解釈であることが全く意識されないのは自分に聞いてみればわかる。脳梁(左右の脳のつながり)を切断した患者は右脳が起こした行動を、耳で聞くか目で見るまで左脳が知ることはできない。右脳と左脳は視野の左右・運動神経の左右の処理を分担してるのだけど脳梁を通した情報交換が阻害されている人間の右脳と左脳に対して選択的に入力と出力を行う(行わせる)と、指示とは異なるちぐはぐな結果が現れる。で、結果に対してなんでそういう行動をとったのかを説明させると、さも当然とばかりに傍目にはこじつけめいた理由を述べる。本人はしごくまっとうな理由で自らの意思に従って行動したと疑っていないが、右脳と左脳の両方が入力を受け取っていれば同じ結果にならなかったのは明らかなのだ。ヒトは左脳が解釈したストーリーを自分の意思で選択した結果であると信じて生きているのではないかと。この文脈でナラティブという語が出てきた。■すっごくテキトーな理解と説明なので正確なところは本を読んでね。一般向けの本だし、インタープリターについて書かれた３章も、脳が中央制御なしの並列分散処理装置だという２章も、個が全体を構成し全体が個に影響するというフィードバックのループが人類を作り替え飼い慣らしてきたという、今読んでる『[新書] 蔵本 由紀【非線形科学 同期する世界 (集英社新書)】 集英社』にも通じる６章も、他の章も、まあ全部面白かった。■だから、Togetterの「承前）《リニアかつ固定された物語》はナラティブではなく《プレイヤーがゲームをプレイすることで事後的にプレイヤーの中に生成されるような物語》こそがナラティブであるとするのは、かなり特殊なナラティブの理解であり、ナラティブの従来の意味を知っている人が戸惑いを感じるのは当然だと思う。→」という発言に対して、むしろそれこそが俺が本から得たナラティブの理解そのものではないかと思った。「ナラティブの従来の意味」を俺は知らないのかもしれないけど、べつにその「独特な」ナラティブはゲームデザイン業界に限ったものでもカタカナ語化する際の誤解や曲解でもないと思う。■「フロム脳」とか「ドラクエ 考察」とかが実例じゃないの？■(ちょっとそれる) 一から十までわかりやすく書かれた文章には十の価値があるかもしれないけど、フィクションは読者を辞書として利用することで一を十にも百にもして伝えることができるんじゃないかというシャノンの情報理論を超える話。このとき読者に伝わった十や百の物語が俺の考えるナラティブ。(おお、話が戻った)■「narrativeは物語か語りと読んどけばとくにまちがいない」という発言もあるけど、物語るのは誰か？というのが本質なんでは？ つまり制作者ではなく個々のプレイヤーであると。■最近読み始めた別の本『[単行本] アンドルー・ゴードン【ミシンと日本の近代―― 消費者の創出】 みすず書房』にもナラティブって出てきた。こんな一般的な語だったっけ？はやってんの？翻訳の必要のないカタカナ語だってみなされるようになっただけ？(<それは間違ってる)■@2013-03-10 毎年毎年飽きもせず年末に繰り返される忠臣蔵だとか、アンビリバボーが現実の出来事をどのように切り取り視聴者の情緒に訴えるかといったところにもナラティブが隠れてそう。たぶんこれはミシンの本での使われ方と同じ。ゲームの方との違いは、散々語られ尽くして強力に作用することが確認された間違いのない方法論だけど、対象が固定されるところ。世界で売るゲームには向かないよ。俺だって見ないしね。韓ドラにはまるおばちゃんの例に見るように、逆に韓国には通用するかもしれないけど、そこまで。

ツッコミを入れる

2015年02月27日 (金) 下碗部を切断？「腕を切断して置き換える「サイバー義手」、オーストラリアで患者に移植される | スラッシュドット・ジャパン」■「質問です！ 上肢は上腕前腕、下肢は大腿下腿といいますよね？ なんで上腕は「上」なのに前腕は「下腕」といわないのでしょうか？」はなはだ当てにできない回答では upper armと forearm の訳語ではないかと言っている。でもスラドのしたうで(※カワンでは一発変換できないので)だって lower armの訳なんだよなあ。■ともあれ前腕って書けよ、と。尺骨を elbow boneって言うみたいに分かり易い俗語ってわけでなし。■■■@2015-06-16 そもそも腕ですらなかった>下碗

ツッコミを入れる

2015年02月26日 (木) 研ぎやすそうな片刃、肉も魚もよう扱わんので薄刃、となると鎌型薄刃包丁。3000円の物、6000円の物、8000円の物、どれにしようか迷ってるうちに見つけてしまった「源泉正 [IZUMIMASA] 白鋼本焼 桜花鏡面仕上 鎌形薄刃包丁 ６.５寸 (195mm)」オウカキョウメンシアゲとか実に中二心をくすぐってくる。ちょっと軟派かなとか外人向けのおみやげ価格が入ってるんじゃないのとか思わないでもないが、どういうわけか桜のモチーフには滅法弱い。ここにこうして文章にして物欲を鎮めている。質的にも金額的にも分不相応だしね。でも 36000円のもあるんだよ……。

ツッコミを入れる

2015年02月22日 (日) 原文の方に言葉が少なくて意味が曖昧だというのはあるけれど「99%のEmailアドレスにマッチする正規表現公開される」■"99.9% Works"を「99%のEmailアドレスにマッチする」と訳すのは明らかな誤り。だって 100%の Eメールアドレスにマッチするパターンを作るのなんて簡単そのものだからだ(その代わりアドレスでないものにもマッチする)。

ツッコミを入れる

2015年02月19日 (木) 昨日あたりの読売新聞の小欄。AならばBという言説を引いておいて、なるほどAでないものはBではないなどと書いている。違うでしょ、自分がBでないものを持ち出してきたから(※つまりそれが論理を無視して偶然を必然に見せかけてまで書きたかったことだ)、それがAではなかったんでしょ。数Aは習わなかった？

ツッコミを入れる

2015年02月18日 (水) 例によって本題とは関係ないところにコメントする。「全称セレクターは擬似要素にマッチしない - Weblog - Hail2u.net」■実際には赤色のテキストが緑色に上書きされるケースは確認されていないのだから「(※赤文字) If this text is green, the universal selector also matches pseudo elements.」の部分に仮定法を使ってもいいんじゃなかろうか。あるいは otherwiseに続けて本来想定している結論(緑でないならマッチしない)をチラ見せでもしておくと素直に理解しやすい。

ツッコミを入れる

2015年02月17日 (火) [Firefox] 英語のサイトの文字が小さすぎて困ったときは……オプション>コンテンツ>フォントと配色>詳細設定>対象言語>西欧>最小フォントサイズを大きくする。(効果がないとき)javascript:void(document.documentElement.lang="en") (最終手段)Ctrl++++++

ツッコミを入れる

2015年02月14日 (土) [SakuraEditor] [sakura-unicode:2253] これはキモい(誰のせいだ)。スペースで区切ってなくても検索語を勝手に分割してしまうのか。検索語(全体)の前後が単語境界であるかだけをテストするっていう選択肢もあったのだな(強調キーワードと同じ方式)。当時それに気づかなかったのはおそらく単語検索メソッドという道具がすでに存在していたからそれを使う何かしか見えていなかったのだろう。いずれにしろ直前の置換によって単語境界が消えた場合に一部の置換対象がスキップされたようにみえる問題は起こる。正規表現置換でも「置換の繰り返しではない[すべて置換]」以外では起こる。テキスト「あいう■■■あいう■■■あいう」検索「\b.+?\b」置換「DEF」。ただまあ、自分でパターンを入力したわけではない単語検索では GREP置換と同じ結果がわかりやすいと思う。■■■どうやって実現するかは知らない。(個人ビルドの)色分けを SHJS方式にして行単位で色分けの状態を保存し行単位で色分けを行うと決めたときに思い知ったけど、それは改行文字が極端に少ないテキストで速度が低下するってことだ。折り返さない設定でも実は数万桁で折り返しているというのは最悪時のパフォーマンスを入力(テキストエディタの入力はテキスト)によらず予測可能な範囲にとどめる処置だ。というわけで改修するとしてもインクリメンタルな処理は維持したくて、検索置換イテレーションの一部をオーバーラップさせて置換するまえに次の検索を行うとかが考えられるけど、マッチ位置を検索語・置換文字の文字数差(バイト数差)で前後移動させるのが危なっかしいというか、改行文字が消えたり現れたり折り返し位置をまたぐ置換の時にどうなるのという不安がある。サクラエディタ固有の問題として置換対象の指定がたぶんビューと範囲選択(レイアウト単位)を経由した迂遠な方法になっているだろうからバイト単位でマッチ位置を移動させることができない場合があるのではないかとかいう不安もある。とかとか考えてると MS伝家の宝刀"by design"も悪くない気がする不思議。■■■@2015-03-07 JavaScriptで "A\nA\nA\nZ".replace(/^A\n/gm, "B") の値は "BBBZ"。これは Grep置換と同じ。文字列が immutableな(実装はどうあれそう振る舞う) JavaScriptからヒントをもらったもう一案。行バッファをもうひとつ用意してマッチ部分(の置換済み文字列)と非マッチ部分を交互に新バッファにコピーしていく。でも「Expand(20100907p01.01)」がないんよね。検索と同時に置換してしまうと何の解決にもならないし。

ツッコミを入れる

2015年02月13日 (金) 「デルがお勧めするWindows」に関しては20120724で書いた。今日(12日)の新聞広告ではその下に「円安値上げに対抗」とあった。主語は Dellだろうけど、その対抗馬は円安値上げ？ 釣り合いとれてなくない？ 対抗っていうけど、円安の勢いに負けて損しないように値上げするってこと？ ひょっとしてその逆？ 対抗より抵抗の方がふさわしかったと思うなあ。

ツッコミを入れる

2015年02月12日 (木) チョーお役立ち。「等幅フォントが使われる要素の扱いがブラウザー間でまちまちな問題 - Weblog - Hail2u.net」 記事が書かれたのは 2012年。そして今もって有用な記事。ただし Firefox23はもはや無指定でも等幅フォントを勝手に小さくしたりはしない。この日記には１年以上前からこういう CSSルールがあった。「pre { font-size: 100%; /* IE9のUAスタイルシートが縮小するのを阻止する。*//* 100%を指定してすら縮小する WebKit/Blinkのことは知らない */」 font-sizeの他に必要だったのは font-family: monospace, serif; 等幅で表示される要素に対してさらに monospaceを指定したりしないし、ましてまったく必要のない serifなりなんなりをくっつけたりはしない。難しすぎ。

ツッコミを入れる

2015年02月11日 (水) [SakuraEditor] [sakura-unicode:2251] 前にも書いたかな。萌ディタの拡張子クラスは継承関係のある設定群だ。差分設定は実行されエディタに登録される。色分けも劣らぬ素敵仕様。例えば言語ごとにパターン群をエディタに登録するのだが状態遷移を管理できる。そしてまた言語間の遷移もサポートされる。■■■「データ構造と メソッドのネーミング - Ph by codic team」■intersectionは差集合でなく積集合。■「―addは末尾に追加する?―」付け加えると、appendにはそういうニュアンスがあると思ってる。しかし……。■shift/unshiftに方向性はないのでは？必ず右シフト/左シフトって言うし。Perlが関数(サブルーチン？よく知らん)の頭で shiftってよく使うのが原イメージ。そこで初めて方向が固定化されるので「―unshiftのイメージ―」は余計なお世話、というかどっちでも良くね？。■traverse「ツリー（木構造）の用語で、ノードを全て辿ることを意味します。」まったく「用語のイメージもつかめるよう」な努力の形跡が見られない。木に登るだけ下りるだけでなく横方向(兄弟ノード)にも移動する(traverse)から、結果的に全ノードを辿ることになるのでは？そして専門用語としてはさらに厳しく意味が限定されている気がする>"In computer science, tree traversal (also known as tree search) is a form of graph traversal and refers to the process of visiting (examining and/or updating) each node in a tree data structure, exactly once, in a systematic way."

ツッコミを入れる
最近
Generated by tDiary version 2.3.3.20091124
Powered by Ruby version 2.5.5-p157