{進捗記録}{}{十分}{知番}{意味符号化}{抜控}{進捗}{デライト}{👍}{希哲17年4月17日の開発}(148)

{希哲17年4月17日13歩 K#F85E/E74C-3416}

進捗時限記録中略

デライト全体における添付譜類方針検討終了

添付譜類あくまでも添え物として最小限の役割留めエクスポート機能でも実譜類出力には今後対応しない方針固めた

元々添付譜類添え物として設計しているが,実際に譜類添付機能出来エクスポート機能実装しようとしてみると,実質的な役割落とし所意外に難しい意図に反して,変に使われ過ぎるのも問題だ。

エクスポート機能では,とりあえずは代替 HTML などで済ませゆとりが出来た実譜類にも対応するか,などと考えていたそもそもどんな大企業クラウドであれ消えて困るような譜類唯一の保管場所にすべきではないし,そこまで神経質な人手元抜控持っていないということも考えにくいので,実はさほど必要性の高い付徴ではない。とはいえエクスポート時負荷帯域だけが問題なら金で解決出来るのだから,将来的に対応しないというほどの動機もない

しかし添付譜類エクスポート出来てしまうことで譜類倉庫的な利用増え,それに伴い譜類保全責任が増せば,将来にわたって無視出来ない経営上の問題になる。ということについさっき気付いた描出公開原則同様,ここは割り切った用者文化育てていくべきだろう。

これに気付いてみて,最近添付譜類役割広げようとし過ぎていたことにも気付いた譜類添付機能サイズ上限拡張子制限緩和考えていたが,これも最小限留めることにした。拡張子制限制危面もあるが,献典として非効率だったり無意味だったりする譜類上信抑止といった効果望める例えば .bmpそのまま上信して欲しくはない

デライトの強みは,知番による意味符号化文字献典情報密度極限まで高め,その軽さ最大限に活かせることだ。譜類倉庫的な方面消耗するのは差別化戦略として明らかに悪手だ。譜類添付機能実装以降,その微妙揺らいでいることはうっすら感じていた今日は妙にもやもやしていると思ったら,どうもがそれを訴えていたらしい。気付いたら非常にすっきりした

描出公開原則のように何かこの方針名前を付けたくなったが,「譜類添付機能」という名前趣旨表現出来ているので,それに立ち返るということで十分だろう。

{開発}{開発記録}{}{デライト}{描写下見機能}{年齢}{新生デライト}{付徴}{機種変更}{iOS}(97)

{希哲15年8月6日の開発 K#F85E/E74C-2EFA}

休日なので,新生デライト開発における作業の進め方などについてじっくり考えた

抜控機能によって安心して描出出来るようにするという当初の目的は果しているので,とりあえず換配確認機能実装まで輪郭選り手整備を進め,いったんデラング整備戻ることにした。換配確認機能デラング整備を大きく加速させるだろう。

輪郭選り手整備イメージもだいぶ固まった

新生デライト全体像出来上がったということは,単純に作業項目が増えたということでもあるが,死角が無くなり,効率的作業の組み合わせ完成までの最短経路考えやすくなったパズルゲーム連鎖狙うようなもので,選択次第結果雲泥の差になるだろう。

とはいえ,どれだけ完成が早くても収益目標達成を待てる期間内間に合うかどうかは分からない。むしろ不安の方が強い。完成を遅らせても宣伝効果の高い付徴優先しなければならない場面も出てくるだろう。


手定め用iPhone 7明後日にでも手に入ることが確定した。

Appleウェブ積極的ではないこともあり,Safari への対応は積極的にしたいことではなかったが,新生デライト開発を前に舞覧手定め環境整備本格的考えるようになり,中古でも iOS 端末を持っておこうかとぼんやり考え始めたのが先月30日だった。

世界的には Android 端末多数派といっても,日本北米ではまだ iOS市影は大きく,日本重視しているデライトでは無視出来ないものがあった。

前々からiPhone 7 からの機種変更をしたいと言っていたので,なんとなく聞いてみたら偶然にも翌日手続きに行こうとしているところで,あっさり貰えることになった。年齢なりに機械音痴なのでその後右往左往していたが,今日ようやく新端末購入手続きを済ませた。

iPhone 7 は,古過ぎず新し過ぎず最新の iOS利用出来,中古人気もありいまだに市影は高い,と手定め機としては理想に近い。

中古価格手頃だが,私の Apple 製品との縁の無さを考えると,こんなことでもなければ調べる気にもならず,結局 LambdaTest あたりで済ませていた可能性が高かった。これも不思議な偶然だ。

{使い方}{進捗記録}{十分}{}{}{知名}{描写}{進捗}{デライト}{CSS}(161)

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

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

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

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

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

経緯

長い歴史

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

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

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

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

読み込み中...
{無視出来ない}

{}