{しやすくなる}{交流したくない人}{交流したい人}{判別出来る}{権限確認用函数}{付けない}{前回の}{拡張出来る}{十分だった}{実際の}...=}(109)

{希哲16年7月13日の開発 K#F85E/E74C-3D0B}

公開設定機能部分実装一段落した出振るい手定めともに円滑に完了した

全体として,当初想定よりは時間がかかったが,想定以上にすっきりまとま満足出来た

{完成の域に達した}{表記的}{写し取りたい}{共有目的}{貼り付けたい}{外部媒体}{適当な時期}{整理中}{省略された}{写し取り時}...=}(145)

{希哲16年6月17日の開発 K#F85E/E74C-9EA6}

自我知番省略機能実装終え第二次知番改良完了とした20歩ここでやっておこう思ったのも,途中で第零番節の削除転換したのもあまりにだったが,その割には終始円滑にり,収穫想定はるかに越えて多大だった。全体として大成功言っていいだろう。

第二次知番改良経て知番表記的にも内部的にも完成の域に達した。あとは仕様実装微調整繰り返していく

まず,当初の目的だった知番の簡略化言うまでもなく大きいこれまで一般のデライト用者最短でも K#9-XXXX/A-YYYY という15文字知番輪郭扱う必要があった。それが第零番節の削除によって11文字K#XXXX/YYYY になり,自我知番の省略によって7文字K#/YYYY になった。知番表記仕様に関しては理想的な形だ。

第零番節の省略」から「第零番節の削除」に転換したことで,知番周りの交度出場整理劇的に進んだ。これにより,効率性保守性大幅に向上したのはもちろん,「新括体採番法の完成」という思わぬ収穫繋がった未実装だった自動知番拡張もここで実装出来た今のところ第二番節しか使っていない状況だが,そろそろ必要かという丁度良い時期だった。

波及効果想定以上に大きかった出場見通しの悪さなどが障害になっていた機能実装に関しては大幅な所要時間短縮見込めるようになった特に見通しが悪い課題だった KNEST 隠し出与え構造がこの期間固まり,一気に実装可能性高まった自我知番省略機能Dex との連携必要になったことで,他の記法でも活かせる出与え共有機構整った。これが無番輪符改良などにも繋がっている

将来的に長い知番増えた時のための「知番略記法」を中心とした第三次知番改良方針固まった。この長年の課題にも解決の見通しが立った。

一つ見送ったこともある。自我知番省略された知番写し取り時自我知番付け自輪郭描写欄などへの貼り付け時自我知番の省略をする4月8日の開発記録,というのは,やはり用合いとしては理想的盛り込みたかったが,今回見送った。このあたりの事象Aejs整理中なので,どうしても場当たり的交度になってしまう。他輪郭素出から写し取りたい時や,外部媒体厳密な知番貼り付けたいという時には便利だが,現時点必要としている人少ない共有目的なら共有ボタンがある。交度整理しながら適当な時期実装することにした。

{希哲16年6月17日の開発}{希哲16年6月17日の進捗}{第二次知番改良}{他人に見せる}{飛ばしている}{転送する}{他自我内検索}{辿った}{希哲16年6月17日の進捗時限}{希哲16年6月17日}...=}(60)

{希哲16年6月17日6歩 K#F85E/E74C-FED5}

{デライト}{なおかつ}{制御しやすい}{握接出来る}{選り手を開く}{操作手順}{複製輪郭}{ボタンを押す}{ずっと考えていた}{視認出来る}...=}(116)

{希哲16年5月18日の開発 K#F85E/E74C-2BA8}

長い間課題だった描写拡縮ボタン輪郭複製機能について大きな進展があった。

描写拡縮ボタン

昨日の開発最大化アイコン出来たことをきっかけに,描写拡縮ボタン実装イメージ固まり,実装手定めまで概ね完了した想像以上に早く上手くまとまった下見機能との相性も良い。ただし輪郭選り手抜控機能整備途中であるため未出振るい

描写拡縮機能的には単純だが,用合い特に領当て難しかった最近描写部下境界重ねる形での実装考えていたが,描写部飛び出す他の要素干渉してしまう。かといって余白無駄に広げたくない。これは,下部陰影重ねつつ,初期化時点スクロール可能な場合は下余白追加することで解決した文字暗い背景色重なっても視認出来るように,半透明白背景付けた

拡大ボタンスクロール可能であることの目印としても効果的なので,これを活かしてスクロール完了時には透明度を上げ,それと分かるようにした。

これで,外観操作感ともにデライト調和した描写拡縮ボタン出来た描写部高さ固定一覧性確保するために必要なものだったが,用合い上弊害小さくなかった陰影付きスクロール最大化アイコン,そして描写拡縮ボタンによって,ようやくこの問題解決した

輪郭複製機能

輪郭複製機能課題としてずっと考えていたが,用合い上難しさがあった。

ボタンを押すことで複製輪郭出来る,というのは使用頻度考える誤操作懸念の方が大きい。となると,目立たないように置くしかない。かといって,操作手順増えると,選り手を開いて写し貼りするのと大差ない

簡単に握接出来て,なおかつ制御しやすい用合い必要だった。ここで,「知名描写複製して新規描出フォーム移動するボタン」があればいいことに気付いた。これなら,自輪郭常に表示しておいてもいいだろう。

輪郭選り手では×ボタンがある位置置けそうだ。

{用者}{進捗記録}{越える}{分かる}{知番}{希哲15年12月24日の開発}{導入しなかった}{完全に隠す}{繋がりうる}{知番の強み}...=}(116)

{希哲15年12月24日6歩 K#F85E/E74C-9D02}

自我知番の省略についての検討終了

昨日の開発から本格的に検討始めた自我知番の省略だが,描写内では輪郭自我知番全知検索などでは録入り中自我知番指す略記法として導入することを決めた

仕様として導入することに大きな問題はないが,難しいのは用合いにどう調和させるかで,これは今後の課題とする。

利点言うまでもなく文字列としての短縮性だが,変則性を一つ加えることで扱い難しくなる懸念もあった。省略有無混乱の元になる可能性もあるため,極力混同させないようにしつつ,ある程度は混同されることを想定した用合い提供する必要がある。この難しさは,これまで導入しなかった正しさでもある。

現状のように自我知番4桁収まっている間は,まだ略記法利点欠点拮抗するだろうが,そのうち8桁になれば流石に邪魔になってくるだろう。将来的に知番の長さ補う方法必要になってくるということは考えていたが,この課題解決策にもなることに気付いたことが決め手だった。

第零番節を除き輪郭知番8桁越えることは機械的な描出でもしない限り)考えにくいが,自我知番4桁なのはむしろ例外的な時期で,いずれ8桁標準になるし,遠い将来には12桁になることも考えておく必要がある。つまり,知番全体20桁まで長くなる現実的な可能性がある。

ここで自我知番の省略が出来れば,少なくとも自輪郭に関しては4桁から8桁輪郭知番だけ考えればいいので,十分な短縮性と言える。他輪郭なら20桁でも扱えなくはない

もっとも,自我知番12桁になるのは40億用者越えてからのことで,輪郭知番4桁もそう簡単には埋まらないので,現実には12桁から16桁知番模量層になるだろう。司組用者成熟度合わせて長くなっていくのが知番の強みだ。


考えている内に,自我知番の省略には無用な自我知番露出避けられる利点もあることに気付いた

テプラ機器知番ったりしているが,人目に触れる場所ではこれも個人情報流出繋がりうる自分だけ分かればいいなら自我知番表記しておく必要はないし,未公開にして完全に隠すことも出来る。

=}
{1秒}{進捗記録}{KNEST 隠し}{希哲15年4月12日の開発}{輪数取得}{希哲15年4月12日の進捗時限}{希哲15年4月12日の進捗}{希哲15年4月12日}{隠し化}{自輪郭}...=}(25)

{希哲15年4月12日11歩 K#F85E/E74C-EB34}

KNEST 隠し仕様検討で終了。


考えているうちに,輪数取得も思ったより負担になっていることに気付いた。前後景輪数は性質上出場側で隠し化しているが,検索時の輪数はいちいち計算している。

最新の自輪郭検索した時,妙にもたつきを感じると思っていたが,K#F85E ではこの求頼だけで約1秒かかってしまっている。

正体が分かったのは収穫だった。

=}
{自輪郭}

{}