{新生デライト}{希哲16年5月の一日一文}{順調に行って}{“知能増幅メモサービス”はなぜいま最も重要なのか}{受け付けている}{解決したい}{緩やかに}{保証する}{一事業者}{起こしている}...=}(135)

{新生デライトとは何か K#F85E/A-E74C-AEC2}

最近デライトでは「新生デライト」という表現多用している簡単に言えば使いやすく生まれ変わったデライトのことだ。

デライトの使い方の考え方」や「“知能増幅メモサービス”はなぜいま最も重要なのか」でも書いたように,前例のない目的持ったデライトには,どうしても特有の難しさがある。

それでもシステムの実用化から10年以上サービス公開から2年以上ち,その有用性十分に実証されている多くの人様々なメモツールブログSNS などを行ったり来たりしながらやってきた情報蓄積発信を,私は10年以上前からほとんどこのシステムだけで実現しているサービス公開後は,デライトでしか出来ないこと見出して使い続けてくれる利用者もいる。

使える人には使える”ことは分かっている残る問題は,使える人少なさだ。そこでいま,多くの人親しめる快適なサービスにするため,文書整備機能整備高速化,そして独自の軽量マークアップ言語デラング」の整備といった包括的な改良構想推し進めている。その完成形を「新生デライト」と呼ぶ

順調に行って6月中,ずれ込んでも7月中には完成見通しだ。


機能整備という点では,すでに使いこなしている利用者にとっての利便性向上もちろん,他のメモツールなどに慣れ親しんだ初心者戸惑いがち機能不足補うことを意識している

例えば,輪郭非公開近い未公開状態」に出来る公開設定機能編集中にリンクしたい輪郭を検索出来る機能全文検索機能検索語提案(サジェスト)機能ファイル添付機能輪郭を削除する機能自動ページ展開機能インポートエクスポート機能高度なアカウント管理機能などの追加予定している

これまでにない密度人の頭の中保存するようなサービスの性質上いわゆる非公開機能導入特に難しい問題だった。AppleGoogle のような世界最大級の企業でも個人情報流出事件起こしているわけで,一事業者安全性保証することは不可能考えている。これに関しては,他の利用者からの閲覧緩やかに制限する未公開状態」の導入と,知番ファイル名として利用したローカルでのファイル管理手法広めることで解決したい

質問要望常に受け付けているので,“世界を変える新生デライト開発どんどん参加してほしい。


=}
{希哲16年4月7日の開発}{希哲16年4月7日の進捗}{多段化}{進めて}{後縁の対応}{追加取得}{フラグ化}{確定出来る}{余計な検索}{目に見えている}...=}(109)

{希哲16年4月7日10歩 K#F85E/A-E74C-B300}

進捗時限記録中略

全知検索整備方針検討終了

2月23日頃から検索結果改良について本格的に考え始めていたが,「検索属性」を導入し,検索結果多段化進めていくことにした。

現状例えば括弧類自動付加した検索は出来るが,その出来ない括弧付き描出したい場合括弧無し検索して既存輪郭無いことを確認した後,括弧を付け再検索するということがく,とりあえずこの手間無くしたかった全知検索演算子制御任意の括弧類使える好都合ということもあった。

文字数昇順揃えてそれなりの結果になっているのでこれを降順にすればいいかと思ったが,上手く行かない場面多々あるので一時凌ぎ域を出ない

将来的な拡張性考える検索結果多段化好ましい風船輪郭輪括内検索にも応用出来る希哲14年7月30日8歩から輪括内検索輪括内のみにすると使いにくいという理由中途半端な状態になっていたが,優先表示解決出来ることに気付いた

整数値揃え兼ねた役割を与え,これを「検索属性」として利用出来るようにする。

ここまでは良いが,効率的な実装難しい単純に全ての検索パターンUNION結合すればひどいことになるのは目に見えている外充て函数余計な検索省くようにする,挿入更新時に確定出来る情報フラグ化しておくといったことに加えて後縁での出力最低限にして前縁追加取得するといった工夫必要になるかもしれない。

いずれにせよ後縁の対応進めて問題ないだろう。設計方針さえ固まれば最適化どうとでもなる

=}
{希哲16年4月5日の開発}{希哲16年4月5日の進捗}{CSS 変数}{生み出した}{伝証}{合理化した}{呼ぶべき}{汚い現実}{ウェブの理想と現実}{もたらされる}...=}(208)

{希哲16年4月5日14歩 K#F85E/A-E74C-6431}

CSS 変数(カスタムプロパティ)の導入舞覧ブラウザ五年対応原則採用決め終了今後デライトでは,「5年以内離立された版存主要舞覧」を中心に対応していく

希哲15年3月1日の開発から「デライト推奨動作環境」として同様の定義考えてはいたが,当時は,古い舞覧対応努力はするが推奨はしない程度の,もっと緩やかなものを想定していた


希哲13年ECMAScript 2015HTML5CSS3比較的新しいウェブ標準導入決めてからだいぶモダンにはなったが,まだデライトの舞覧対応方針には感覚的保守的なところがあった。感覚的に影響範囲の広い付徴主要舞覧対応から10年影響範囲の狭い付徴5年目安導入考えていたrem ですら必要以上には使わなかった

先日前次記法実装グリッド領当て導入したが,これはちょうど主要舞覧使えるようになってから5年ほど経つ機能だった。一記法装体過ぎなかったこともあり,ここまで辛うじて良かったが,他にも色々応用したいことが出てき舞覧対応方針見直し必要を感じていた

決め手は,デライトのダークテーマ対応見据えて CSS 変数の導入考え始めたことだった。CSS 変数主要舞覧対応から5年ほど経つが,本格的に導入するとなると影響範囲広がり過ぎる


Can I use対応舞覧よく調べるようになってから,「5年以内離立された版存主要舞覧」が意外に普及していることに気付いた大体90%以上はある。

地域にもよるだろうが,確かに今時古い舞覧使い続ける方が難しいかもしれない。個人機なら5年平均的な買い替え周期であり,スマートフォンなら古い部類だろう。自動更新標準的になった昔と違って多数派の“普通の人”ほど新しい舞覧使っている

あえて古い舞覧使い続ける場合というと,一昔前なら古い個人機再利用というのがあったが,格安インターネット端末普通に流通している今,新しい舞覧使えないほど古い端末使い続ける費用対効果疑わしく,制危考えれば推奨出来ることではない

一番面倒なのが舞覧の更新許されない企業内利用だが,そもそもそんな保守的な環境デライト利用出来るとは考えにくい

こう考えていくと,デライトにとって古い舞覧への対応重要性極めて低い言わざるをえない

奇しくも新生デライトの完成目指している6月15日に,IE11 のサポート終了がある。中途半端気もする内容だが,いわゆるモダンではない舞覧最後の砦崩壊する新しいウェブ標準への社会的移行象徴的な出来事にはなる。


ある程度古い舞覧への対応考慮してきたのは,企業体力がついた将来対応拡充することを考えていたからだったが,これもよく考えると合理性怪しい

技術的負債”は簡単に返せるものではない。大企業肥大化した交度にいかに苦しめられているかを考えれば合理的に古い舞覧への対応出来る来るかどうかも分からないむしろ組織大きくなった時にこそ見通しの良さ重要になる


もっと根本的なこと言えばデライトウェブ標準という盤本の“キラーアプリ”になるべきものだ。新しいウェブ標準普及牽引していくくらいの考えがなくてはいけない。

その伝証デモ足掛かりがすでにこれだけ普及していれば十分過ぎるだろう。


舞覧五年対応原則導入によって,ウェブの理想と現実における汚い現実大部分だった古い舞覧正しく切り捨てることが出来るようになり,前縁整備はもちろん,デライト文書整備でも大きな効率化もたらされるだろう。文書整備では,対応舞覧についてどう説明していくかが一つの課題だった。ここまで絞り込めば説明すっきりする

デライト開発劇的に合理化した描出公開原則とともに「デライト二大原則」と呼ぶべきかもしれない。思えば描出公開原則デライト正式離立という大きな節目目前にして生み出したものだった。


=}
{出力する}{漠然と}{こまごまとした問題}{キーボード操作}{簡潔な表現}{ダブルクリック操作}{意味が分かりにくかった}{誘導効果}{見えやすくなった}{戻り方}...=}(99)

{希哲16年3月31日の開発 K#F85E/A-E74C-FB1F}

こまごまとした問題片付けた


就寝前閲覧専用模動に関して閃きがあり,また脳爆発始まってしまった

漠然と中景部角丸周辺ボタンとして使えそうだとは思っていたが,これで吹き描き長方形にして前後景部し,さらに中景輪符波括弧角括弧変えれば吹き描き意味ともデラングとも調和する詳細はまだ練る必要があるが,かなりの有力案になりそうだ。

{需要がある}{地味ながら}{厳密に考える}{見分けが付く}{開いている時}{実装出来た}{現仕様}{万能ではない}{`resize: vertical`}{高過ぎず}...=}(115)

{希哲16年3月30日の開発 K#F85E/A-E74C-7061}

描写欄高さ問題きっかけ自動リサイズ機能字数計実装出来た。ほか装体調整など。

出振るい済み

自動リサイズ機能

旧輪郭選り手では,描写欄出放り高さ新規描出フォーム10em再描出フォーム15emとしていたが,新輪郭選り手ではたまたま15em統一されていた画面撮り10emでは長文書きにくいのでこれはこれでいいかと思ったが,やはり新規描出フォーム一言だけや知名だけの描出使うことも多いためこの高さでは邪魔臭い

ここで,予てからぼんやり検討していた自動リサイズ機能導入考えた一応 resize: vertical設定してあるが,万能ではない10emから20em程度までの範囲で,改行毎に自動リサイズさせる。導入予定字数計では字数情報必要になるため,一緒に行数保持させることにした。

実際に試してみると,1em刻みでも2em刻みでも違和感があったため,10emから19emまで1.5em刻みリサイズするようにした画面撮り初期状態最大自動リサイズ19emだと個人機でも低過ぎず高過ぎずスマートフォン縦向き柔品キーボード表示させてもちょうど収まる程度の高さになる。折り返し多い1行もありうるため,厳密にするなら字数考えるべきだが,とりあえずはこれで様子を見ることにした。

再描出フォームに関しては,さほど目立つものでもなく,描写部高さ合わせて描写欄開くようになっている現仕様悪くないので,現状維持様子見しておく。

字数計

字数行数保持出来たことで字数計難無く実装出来た描出ボタン時印左側邪魔にならないように表示させてみた字数計の様子

下見字数分けようかと思っていたが,下見開いている時下見字数置換すれば十分であることに気付いた一応見分けが付くようにに「」を付けるようにした。

これも,厳密に考える特殊な文字符号などを考慮する必要があるが,キリがないのでとりあえず .length による概算でよしとしておく。

字数計は,地味ながら意外に需要があることを市場調査通して知った自分でもたまに欲しくなることがあった。

{導入}

{}