{葛西臨海公園サイクリング}{希哲16年4月10日の副日記}{感慨深かった}{いままで}{近便}{退屈さ}{広いだけ}{多彩さ}{移動速度}{大き過ぎない}...=}(92)

{希哲16年4月10日の散歩 K#F85E/E74C-51E1}

11時頃から葛西臨海公園若洲海浜公園夢の島公園辰巳の森海浜公園などを巡って17時過ぎ帰った道に迷うことが多かったせいもあり,昨日最長記録大幅に更新し,約48.1km走った

休日なので少し遠い辰巳の森海浜公園目指して出発したが,葛西臨海公園り,荒川河口橋越えたあたりで勘違いして曲がってしまい,若洲海浜公園着いた。ここはここで海が綺麗見える良い公園だった。植物見るなら葛西臨海公園十分だったので結果的には良かった

見ながらり,15時頃,少し懐かしい辰巳の森海浜公園休憩したデライト正式離立前に何度か訪れ計画を練った思い出があり希哲13年10月7日の散歩記録なんだか感慨深かった近便適当に買ったもので食事を取再開葛西臨海公園ぶらぶらしてから帰った

他の大きな公園走ってみたことで,葛西臨海公園サイクリングコースとしての優秀さ再確認した小さ過ぎず大き過ぎない敷地見所凝縮されていて,自転車移動速度に対する景色多彩さ絶妙だ。ただ漠然と広いだけ公園感じる退屈さ無い希哲荘からの距離運動には最適で,恐らく最高の場所だろう。徒歩行くことが多かったので,いままでこの真価気付かなかった

{用者}{HTML}{HTML5}{デラング}{進捗記録}{高い}{あれ}{役割を持たせる}{役割を持つ}{緩衝的}...=}(248)

{希哲16年2月15日10歩 K#F85E/E74C-2CA8}

進捗時限記録中略

昨日寝る直前にまた脳爆発があり,今朝にかけて文字装飾記法タグ記法周りの概念整理仕様整理急速に進んだ

文字装飾記法は,「文字装飾を伴う慣用表現」のための記法位置付けることにした。太字記法##斜体記法//下線記法__打ち消し線記法~~翌日のまとめで「打ち消し記法」から改称4記法基本とし,それぞれ所定装体スタイルを伴う <b><i><u><s> HTML 要素対応する

@ を使った文字サイズ記法% を使った色記法検討していたが,タグ記法概念が出来たことで中途半端なものになるため,これは廃案とする。

文字装飾記法はこれがほぼ完成形か。

検討過程

3つ検討方針

実装自体は容易部類で,記法概ね固まっていたにもかかわらず文字装飾記法実装踏み切れなかった理由として意味論的な問題があり,これが思いのほか難題だった。実装方針3通り考えられる

  1. 完全に意味論的な記法にする
  2. 完全に装飾的な記法にする
  3. 意味論装飾重ね合わせた記法にする

記法趣旨からしても,軽量標記マークアップ言語特性を考えても,1つ目に無理があるのは明らかだ。対応する HTML<b><i><u><s> は,私が何度解説を読んでもややこし感じる代物だ。それを多くの人正しく理解して使うのは不可能だろう。そもそも「文字装飾記法」という分かりやすい説明体系捨てることになるが,代替案があるわけでもない。

かといって,2つ目ももったいない。要は <span>装体指定だけにするということだが,例えば,太字にはしたいが <b> にはしたくない場合打ち消し線引きたい<s> にはしたくない場合がどれだけあるのかと考えると,無難通り越して臆病過ぎる失う可接性アクセシビリティ応用可能性釣り合わない

最終的に採用することになった3つ目も,全く考えなかったわけではないが,柔軟性に欠け,前の2つの悪い所組み合わされる気もして,有力案にはなっていなかった。

タグ記法による書き分け

この膠着状態変えたのは,前日概念としてまとまったばかりのタグ記法だった。

これまで,デラングにおける HTML は,どうしてもデラング出来ない表現をしたい場合などの“抜け道”とか“救済措置”に近い位置付けで,積極的に使うことを想定していなかった。実際個人的にはほとんど使っておらず放置している不具合多い部分だった。

デラングタグ記法として間接的に HTML使うことで,略記法導入可能になり,HTML 側の仕様変更に対しても一定の緩衝帯設けることが出来る。ここに来て初めて文字装飾記法でも「書き分け」が考えられるようになった文字装飾記法対応しうるのが全て1文字要素だったことも幸いした

昨日寝る直前に,##太字的な表現##<{font-weight:bold}>太字</> のように書き分けるよりも,##太字##<b>太字的な表現</b> のように書き分ける方がマシであることに気付いて,1つ目の実装方針完全に潰せた

これにより一時的に2つ目の実装方針再浮上したが,標準的に使う記法として標準的な用途最適化不足なのはやはり否めなかった

決着

最終的に,「文字装飾を伴う慣用表現」という用者自然に理解出来る範囲での意味論的位置付け与え逸脱する用途ならタグ記法書き分けるのが使用頻度に対して最適だろうという結論に達した。3つ目の実装方針洗練させた格好になる。

例えば##太字## は「太字装体<b>」に対応する装体邪魔なら <b>太字的な表現</b>書けるし,意味邪魔なら <{font-weight:bold}>太字</>略記法検討段階のように書けるが,これらの場合稀少なのは明らかで,記述量上手く釣り合うワープロならともかく,軽量標記言語手書きしようという人にとって難しい使い分けではないだろう。

そもそも<b><i><u><s> は,古くからある視覚的要素HTML5慣用的な用途引き継いで意味論化されたものなので,「文字装飾を伴う慣用表現」と非常に相性が良い相互変換にも全く問題ない

何より,直感的に入力すれば構造的に出力されるというデラングの理想適っている

文字サイズ記法色記法廃案

文字装飾記法を「文字装飾を伴う慣用表現」と位置付けたことで,慣用表現を持たない文字サイズ記法色記法仲間外れになるが,タグ記法によって出る幕がなくなった感があるので,ここで廃案にすることとした。

第一に,タグ記法略記法整備した方が一貫性応用可能性高い特定プロパティ省略出来るようにし,<{white}>白い文字</> のように書ければ,%white%白い文字%% と書くのと記述量大差ない

もともとパラメーター必要とする記法異質感はあり,文字装飾記法統一感損うかという懸念はあったので丁度良かった

波及的検討

波及的に,いくつかこまごまとした検討進んだ

組み合わせは「」ではなく「入れ子」へ

これまで,複数文字装飾記法組み合わせ#/太字と斜体/# のように,「記号を1つずつ逆さにした終了記号挟む」といったややこしい説明考えていたが,##//太字と斜体//## のような「入れ子」を #/太字と斜体/#短縮出来るという考え方にした方が分かりやすいため改めることにした。

タグ記法発展

今回検討で,タグ記法早くも実践的な役割を持つことになり,デラングにおける存在感一気に増した

タグ記法HTML仕様変更対する緩衝的役割を持たせること,要素名省略<span> にすることを考え始めた

{進捗記録}{高い}{希哲16年2月7日の開発}{表示された}{0.1em刻み}{狭まってしまう}{滅多に使わない}{階層の深さ}{変わってしまう}{4階層}...=}(87)

{希哲16年2月7日16歩 K#F85E/E74C-5EF4}

{デライト}{写真}{『希哲日記』}{散歩}{日中}{買う}{持つ}{思い立つ}{模体}{21VW-206G}...=}(219)

{希哲15年11月21日の日記 K#F85E/E74C-D3A2}

ついに自転車を買った前々からぼんやり欲しいとは思っていたが,なかなか模体モデル決まらず,大して必要にも迫られず踏ん切りがつかなかった

金風以後市内中心買い出し事務的な用事歩き回ることも増え自転車くらいは必要かと強く感じるようになっていた。散歩徒歩行ける所はほとんど行き尽くしてしまい,少し飽きつつある買い出しに関しては,ネットスーパー利用することも考えたものの,店舗には店舗の面白さ便利さがあり,篭りがち仕事合間良い運動気分転換になっているので,自転車さえあれば不満はない

実家にいくつかあった自転車は,盗まれたのか持って行ったのか,いつの間にか無くなっている最近惹かれていたのはダホン K3 だが,今のところそこまでの可搬性必要ない。となると走行性能費用対効果低過ぎる

もうこの際,実用性最低限見た目があればつなぎとしてシティサイクルでもいいかと思い立ち,昼前から散歩がてら自転車屋巡ってみることにした。最初近所でよく前を通る小さな自転車屋入ってみたが,品揃え少な過ぎたため,少し離れた大型専門店まで足を延ばした

ここは流石に品揃え豊富で,いくつか惹かれる模体見つかった一番気に入ったのは一通り装備が付いた20インチ折り畳み自転車だった。趣味用自転車特有面倒臭さがなく,適度お洒落感はある。

この系統だと2種類,かなり似た形状のものがあり,一方はフォルクスワーゲン2021年型 VW-206G本体価格3万円台半ば,もう一方は1万円ほど安い独自ブランド模体だった。そもそもつなぎなので最初は安い方でいいかと思ったが,よく見る細部美しさ価格なりの差があり,結構迷った。結局,ここで妥協するなら1万円くらいのシティサイクル大差ないことに気付いて VW-206G買った防犯登録保証保守サービス整備防犯用品一通り付け4万3千円ちょっとで,すぐに乗って帰れた。

最初は1年くらいつなぎってくれればいいかと思っていたものの,ってみると,意外にも自転車欲あっさり満たされてしまった。元々合理的移動手段として欲しかっただけで趣味として追求したいわけではなかったし,この模体自体の費用対効果期待以上高かった

走行性能は,ぶらぶら走る程度なら以前所有していたダホンSpeed P8変わらない印象で,10万円ちょっとまでの20インチ自転車ではどれと比べても大差ないだろう。都内で見かける自転車大半より見栄えも良い

外観に関しては,そもそもこの形状一番好みだったことに買ってから気付いた最低限装備しか付けていなかった Speed P8似ているとは初見では感じなかったが,後で写真見比べる骨格驚くほど似ていた愛嬌かっこよさ兼ね備えるこの感じ20インチ折り畳み自転車が元々ツボだったのかもしれない。新しい2022年型ではフレーム形状変わってしまっているので買わなかったかもしれない。そう思うとしばらくはこれでいいやという気もするし,後継車ハードル高そうだ。

見た目優先折り畳み機能使い道はあまり考えていなかったが,ってみると玄関置いておくのが最適という結論になり,結果的にこの点でも大正解だった。

およそ10年ぶり自転車には感慨深いものがあり,まであちこち走った自転車よく乗っていた時期長くないものの,平日日中でも毎日のように Speed P8都心走り回っていたので,想い出濃い天気は悪かったが,涼しくて好都合だった。

考えてみれば,デルンの実用化引き換え自転車も自転車でぶらぶら走るゆとり失ったようなもので,デライト自転車組み合わせ新しい体験もたらしてくれそうだ。最近睡眠の質課題なので運動機会増えたのも嬉しいってぼんやり考え事をしているよりはサイクリングでもしていた方がいい。

22日振り返り日記

{進捗記録}{撤去前}{気にならなかった}{置けそう}{速度計測}{設置場所}{希哲15年10月12日の進捗時限}{希哲15年10月12日の進捗}{希哲15年10月12日}{希哲15年10月11日}...=}(47)

{希哲15年10月12日5歩 K#F85E/E74C-F2B6}

進捗時限記録中略

適当にしていた家庭用路定機Speed Wi-Fi HOME 5G L11設置場所について検討

昨日移動させながら速度計測してみたら設置場所で思ったより大きく速度変わることが分かった

家中置けそう場所し,最適設置場所見つけた


現状速度妥協出来ないこともないが不安定なのが気にかかる

以前の光回線では,速度気にするような使い方もせず,実際気にならなかったので速度計測自体まともにやったことが無かった。たまに試して,「こんなものか」と思った記憶だけが残っているので,可もなく不可もなくだったのだろう。

比較のため撤去前計測しておこうと思っていたが,いざ家庭用路定機届くと早く試したくなり,設定切り替えした時点で戻すのも面倒になってしまった。

とりあえず体感的遜色ない通信品質になれば問題ない

=}
{早朝出振るい}{違了処理整備}{出振るい}{進捗記録}{希哲15年9月6日の開発}{急がない}{希哲15年9月7日}{まとめて}{やりやすくなった}{5時前起床}...=}(46)

{希哲15年9月6日4歩 K#F85E/E74C-F11E}

出振るい作業についての検討終了

最近,断帯を伴う出振るいタイミング迷うことがく,結果的にまとめて行うことも多くなっていた。今後,急がない出振るいについては意識的まとめて行うことにした。

保守作業中ページへの切り替え機能再整備違了処理整備輪郭選り手抜控機能整備を経て出振るい作業もずいぶんやりやすくなったが,機会損失に繋がる断帯最小化したい。

時間帯も,深夜にまとめようかと思ったが,生活律動との兼ね合いがあるため5時台の「早朝出振るい」を心がけることにした。朝のデライト宣伝6時台最適考えてきたため,流れとして丁度良いだろう。

これに伴い,明日から5時前起床目指すことにした。最近,夜更かし目立つようになってきたためこれも丁度良い

{デライト}{希哲館}{遠象性}{目指している}{近象性}{引き出せる}{動物の脳}{近象的}{進化生物学}{重要度}...=}(49)

{近象的であることについて K#F85E/E74C-4C23}

近象的であることが良いというよりも,現象遠近適切利用した方が良いとは言えると思います。

進化生物学的に考えれば,動物の脳は,状況に合わせて生存最適行動を取るための情報処理を担っているはずです。要は,情報優先順位を付けて,重要度の高い情報をすぐに引き出せるように出来ています。重要な情報は近くに,瑣末な情報は遠くに置いているとも言えます。この情報遠近法を形にしたのがデライト輪郭法です。

この輪郭法は希哲社の「知機」開発プロジェクト核心ですが,一部です。

例えば,今の一般的なコンピューターUI では,何かの目的に対し,ユーザーがアプリを選んで対応します。これは十分に近象的ではなく,雑音が多すぎます。「○○がしたい」という時に,「○○を実現してくれる××を使う」のではなく,「○○を使う」と考えられるのが近象的な UI です。

具体的には,統一感の無い絵柄アイコン固有名詞ではなく,ピクトグラムのように体系化されたアイコンで,目的を直接的に表現します。コモディティ化したアプリの仕様の大枠はプラットフォームが決め,サードパーティーはその実装を競作するか,実験的なアプリの提供を行い収益を得ます。

こうした試みは無かったわけではなく,Apple も方向性としてはそれに近いことをやろうとしていますが,突き詰めればこういう形になっていくと予想しています。

CLI でも似たようなことが言えます。例えば,「ファイルを全文検索したい」という時に find と何々を組み合わせて……と考えるのは近象的ではありません。grep -r も grep が固有名詞なので近象的ではありません。理想を言えば find 'foo' と書けるべきでしょう。

知機 Unix 相互運用標準」として希哲館が策定している Synx では,同じことが交度英語fnd 'foo' と書けます。一般の Unix コマンドと区別するため kn fnd 'foo' とも書けます。

要するに,ユーザーが頭に思い描いたことと,UI の言語体系との間に距離が無いことが,工学における近象性です。この点で現在の多くの UI には課題があると感じています。

今の UI は迂遠なことが多いので主に近象性が課題になりますが,もちろん,より複雑・詳細な表現に対応する遠象性も適切に扱える必要があります。

UI が理想的な近象性を実現した時,物理的接続しなくても,十分に脳とシームレスに繋がるコンピューターが実現出来ることになります。これを「知機」と呼んでいます。デライトも含めて,それこそ私が目指していることです。

{デライト開発}{進捗記録}{新生デライトの要件}{希哲15年7月22日の開発}{作業が捗る}{部分更新}{細かく制御}{駒手一発}{最適な窓構成}{適当な名前}...=}(50)

{希哲15年7月22日10歩 K#F85E/E74C-D90E}

進捗時限記録中略

開発環境整備

作りかけ使っていなかった kn scr仮想画面単位での窓構成保存復元に使えるようにしていったん終了

画面番号適当な名前を付けて作業最適な窓構成駒手一発展開出来るようになった。各 xterm 用の screenrc用意し,シェル状態細かく制御出来るようになった。

これまでは主力機起動しっぱなしにしておくことが多く,窓構成模索していたためいちいち手作業調整していた。

最近,デライト開発最適窓構成が掴めてきたことと,外出が多い上に今年の夏に少し危険性感じること,そして昨日までに新生デライトの要件まとま作業効率可能な限り上げておきたかったことで機が熟した

これで臨時調整再起動部分更新などがずっとしやすくなり,作業が捗るだろう。

{デライト}{lightgray}{出振るい}{silver}{進捗記録}{WhiteSmoke}{gray}{下線記法}{引用部区}{希哲15年6月21日の開発}...=}(160)

{希哲15年6月21日9歩 K#F85E/E74C-A945}

強調輪符輪結装体リンクスタイルについてのまとめ

これまで輪符輪結装体1px #999破下線にしていたが,通常の線のlightgray引用部区ブロックなど WhiteSmoke 背景の上では silver と,かなり薄くした強調記法単独で囲まれた輪符に関しては,silver一本下線にし,少し目立つようにした。

これにより,輪結リンク重要性に応じてメリハリが付くようになり,重要性変調さりげなく示唆したいような場合は軽い強調はっきり強調したい場合は重い強調というように,強調記法と組み合わせた「強調輪符」の記法確立した。

輪符自体を強調するのではなく,参照名を強調したいのであれば内側に強調記法を置くことも出来る(例:軽い強調重い強調)。

経緯

長い歴史

輪符表示をどうするかという問題は,デルン最初期からの課題だった。

最初は重要な輪符を少しずつ貼り付けるような使い方しかしていなかったため大きな問題ではなかったが,いずれ文中輪符が増えてくれば,重要性によって表示し分ける必要が出てくる,というのは当初から想定していた。元々,入力道手メソッド機能自動補完などで文章のほとんどが意味符号になるような技術として構想していたからだ。

実際,デライト以後,私自身の慣れデライトの品質向上によって自然と文中に輪符が増えてきた。現在,私の描出ではほとんどの輪符であり,輪結になっている。こうなると,閲覧者にとっては,どこが重要な輪結なのか分からない上に,中途半端に目立つ輪結だらけで見にくいという問題が出てくる。

もう一つ,輪符に関する問題があった。輪符知名を変えて参照したということが分かりにくいという問題だった。輪符の知名を変えたということが読み手にとって重要なことがあるが,これまでそれを表現する良い手段が無かった。

どちらの問題も,少し前までは自動的解決出来るのではないかと考えていた。例えば,前景輪にある輪符自動的強調表示したり,知名と異なる名前で参照された輪符斜体にするなどということを考えていた

ただ,これは描出経験を積むにつれ無理がある感じるようになった。

まず,時として膨大になる前景輪に一致する輪符をいちいち見つけるのは現実的ではない。見えている10輪限定するのも不自然見え方になるだろう。輪符参照名をいちいち照合するのも軽い処理ではない。

描写隠し文字列でも埋め込めば負荷軽減にはなるだろうが,依然として無視出来ないコストではある。何より,出与え一貫性保守性深刻な影響を及ぼすことは目に見えている。

それ以前に,自動装体スタイリング適用すべきではない場合が多々あることも分かってきた。全知検索との兼ね合いも考えると,文中目立たせたい輪符引き入れたい輪郭はむしろ一致しないことの方が多い。

知名に関しても,例えば,「知る」という輪郭を「って」のように語形を変えて参照することも増えてきた。明らかに自動装体にすべきではない,瑣末な場合が多々ある。

最近では,デラング整備進展もあり,これは手動装体,つまり何らかの記法対応すべきなのではないか,と考えるようになっていた。

今日の進展

こうした問題解決に向けて本格的に考え始めたのは,まさに今日,昨日の日記を付けていた時に,「希哲15年6月20日の開発」という輪郭を「開発では」として参照した時だった。この「開発」が,一般的な意味での開発なのか,特定の日の開発を指しているのか,一見して分からない。これは以前からずっと気になっていた問題だが,そろそろ何とかしたいと思った。

重い強調を使ってみたりもしたが,重過ぎる。そこで軽い強調を使ってみることにしたが,軽い強調は欧文向けで,斜体伊体依存した装体は避けたかった。ここで,強調輪符下線調整することを考え始めた。

強調輪符をいかに目立たせるか,ということを考えているうちに,そもそも輪符輪結全般が目立ち過ぎていることに気付いた。というより,これまではこの輪結装体軽い参照重い参照表現していたので,気付いてもどうしようもなかった。ここで,通常の輪符と強調輪符でメリハリを付けることを考え始めた。

破線は太くすると環境によって全体的に大きくなり短いでは破線らしく見えなかったりするため,一本下線にすることを考えた。もともと点下線破下線一本下線輪結の強さ表現した装体で,一本下線は前景輪のために取っておいたが,前述の理由で未使用だった。ここで,輪結装体に関する問題全般と繋ってきた。

通常の輪符に関しては,いっそのこと下線類を無くしてもいいかと思ったが,流石に文字色だけでは心許無い視線の流れを遮ることなく,視線を止めれば容易に輪結と視認出来る按配理想として,破下線を極力薄くすることにし,白背景なら lightgray引用部区など WhiteSmoke 背景の上では silver最適結論付けた

Firefox調整していたためもう一段濃い silver と darkgray の組み合せで決めかけたが,他の環境では破線密度の差でまだ濃過ぎるように見えたため,まとめ中に修正)

強調輪符一本下線に関しては,薄い色では弱いように思え gray を試したが,明示的下線を引きたい場合のために下線記法導入することも考えているため,兼ね合いであえて silver にしておくことにした。

まずは CSS のみでの出振るいonly-child で複数の輪符には効果が跨らないようにしてあるが,テキストノードは含まれうる。本来は一つの輪符のみを強調した時の効果であるべきだが,とりあえずは十分だろう。

総括

開発記録に書いておく。

{最適}

{}