{進捗記録}{一通り}{一箇所}{十分}{}{サービス}{進捗}{デライト}{希哲17年4月10日の開発}{希哲17年4月10日の進捗}(148)

{希哲17年4月10日12歩 K#F85E/E74C-A47E}

進捗時限記録中略

隠し破りKNEST一部として体系化することにし,仕様まとめ交度修正などを一通り終えた緊急性低いため未出振るい

KNEST では,%Y%m%d%H%M%S 形式求頼変数隠し破りとして扱い(例:?20230101000001デライトでもこれで統一することにした。この時印形式を「詰め込み時印ts_jam呼んでおく

隠し破り導入以後スクリプト装体書などの主要静的譜類には ?upd=K170101.1 のように,希哲紀元での日付連番形式基本的に使ってきたが,自我アイコン隠し破り対応では ?icon&upd=[Unix 時間] になったり,添付譜類では ?[Unix 時間] になったりと,統一感なくなってきていた

実用上なんでも良かったが,譜類添付機能実装以降用者目に触れやすくなったため,簡潔さ分かりやすさ両立させる必要性感じていたUnix 時間では非技術者理解しにくいし,技術者でも意図理解するのに時間がかかるそれが不安繋がることは好ましくない特に簡潔というわけでもない。

確実性重視するならハッシュ使うのが定石だが,抽象性が低いということでもあり,擬制的扱いにくく融通が利かない場面出てくる冗長さ一部省略何とかなるにしても,やはり分かりにくい

総合的に詰め込み時印のみが一番無難だろうと結論付けた更新時印でも整合性を保つやり方いくらでもある用者意図推測しやすく,開発者手動ったり異常に気付いたりしやすい。

強いて欠点を挙げるなら,更新日時知られたくないいるかもしれない,ということくらいだが,デライトでは大きな問題ではないだろう。そもそも更新履歴見られるサービス投稿同時に上信される SNS なら秘密情報ではない。

ウェブ捌き設定などで小細工しやすいように,upd= なり mod= なり ts= なりのとして表現することも再考したが,として扱うことを想定していない文字列という特殊性鑑みると,それはそれで違和感がある14桁数字列求頼変数隠し破り,と明確に決めておけば十分だろう。


これを機にこれまでいちいち書き換えてきた主要静的譜類用の隠し破り更新も,mkbld-etc自動化したテンプレート一箇所書き換えればいいようになっていたものの,積み重なるそれなりの手間だった。

自動化するまでもない隠し破り記述いくつか残っているが,これは ?upd=K170101.1 なら ?20230101000001 というように置換しておいた

{開発}{『希哲日記』}{日記}{KNS}{デライト}{適度な難しさだから共有したくなる}{知能増幅と人工知能}{希哲17年2月7日}{共有したくなる}{理解し難い}(93)

{希哲17年2月7日の日記 K#F85E/E74C-0C4A}

SNS における Twitter が,個人知識管理サービスにおける Evernote似た位置付けになってきて,「SNS 戦国時代」の訪れ感じる一時停滞感のあった「メモ戦国時代」も再び盛り上がり見せておりKNS たるデライトにとっては最高の状況出来つつある

GAFAM停滞期り,次の時代模索されている人工知能実用化急速にんだことで,かつての人工知能幻想」は鳴りを潜め人間の知能本当の問題であることに多くの人気付きつつある

KNS として,全知検索演心として,知能増幅技術として,この時代課題最も単純明快最も強力な解答提示出来るデライト快調に開発続けているデライト時代ようやく密致しつつあるのを強く感じる


最近Twitter代替として注目されている Nostr興味深眺めているネット受けするのに,分かりやすさ使いやすさ信頼性効率性高度な機能実は必要ない,ということの好例でもある。

既成概念組み合わせである Nostr難しいといっても多少の知識があれば理解出来る共有出来る適度な難しさだから共有したくなる最も知識のあるにも理解し難いデライトとは出発点違うものの,新生デライトの完成目指した全力疾走通過点として,こういう受容のされ方がすぐそこにあるかもしれないと思える

10日振り返り日記

{メモサービス}{}{}{}{一日一文}{サービス}{デライトの成功}{デライト宣伝攻勢}{デライト}{希哲16年4月29日}(327)

{第四次宣伝攻勢に向けて K#F85E/E74C-668D}

デライトは,黄金週間初日となる明日29日4度目の宣伝攻勢第四次宣伝攻勢始めるこれを機に中断していた一日一文」の日課再開することにした。

デライトはいま,包括的な改良構想によって「新生デライト」に生まれ変わろうとしている。今回の宣伝攻勢コンセプトは“新生デライト開発実況”だ。この一日一文含めて開発状況開発者考えなどについて積極的に発信していきたい。

森を見て木を見る

3度宣伝攻勢から得た教訓色々とあるが,4度目の宣伝攻勢目前にしてつくづく感じていることは,結局やってみなければ分からない,ということだ。

ソフトウェア開発やっていると,ここが悪い,あそこが分かりにくいなどといったことばかり考えてしまいがちだ。とりわけデライト新奇見える代物なので,開発者利用者も,“デライトの問題点”について考え込み過ぎる嫌いがある。

問題点地道に改善していくのは当たり前のことだが,問題点ばかり見ていると,「問題があることが問題」であるかのような錯覚に陥りがちだ。問題のないソフトウェアなど存在しないので,これは「木を見て森を見ず」でもある。広く使われている全てのソフトウェアは,それぞれに問題抱えながらそれぞれの役割を果たしている。その全体像見ず問題の大きさ正しく見ることは出来ない

そもそも使いやすい UI分かりやすい文書……などと全て兼ね備えた優等生的なソフトウェア世の中どれだけあるだろうか。使いにくかろうが分かりにくかろうが,バグだらけであろうが,“使う必要”があれば使われる。それが現実だ。ツール文書も,必要ならユーザー作り始める昔からそうやってソフトウェア共有されてきた。

そこに革新性があればなおのことだ。誰でも戸惑いなく使える革新的なソフトウェア──そんなものは夢の中にしか存在しないデライトがそうであれば,私はとっくに世界一の有名人にして世界一の大富豪になっている。冷静に考えれば馬鹿馬鹿しい話だが,知らず知らずのうちにそれに等しいことを考えてしまうのが認知バイアス怖さだ。

最大の課題

読み込み中...
{進捗記録}{一段落}{一通り}{進捗}{希哲16年4月6日}{出振るい}{希哲16年4月6日の開発}{希哲16年4月6日の進捗}{領当てが崩れる}{足りず}(101)

{希哲16年4月6日16歩 K#F85E/E74C-04AD}

進捗時限記録中略

フォーム部品装体調整デライト扉装体調整

一段落したため出振るい手定めして終了


まず,2日の開発思い付いた全知検索ボタン改良案導入した装体調整前

この検索ボタン装体は,もともと全知検索演算子連動させることを考えていたため,入力欄切り離したようなデザインになっている。一体感ボタンとしての分かりやすさ両立させたもので方向性としては悪くない。ただ,若干無駄があった2日の開発合体選り手同じ見せ方使えそうなことに気付き,これでまとめた

全知検索窓デライト最初期作り込んだ部分だったため,基本的にフォーム部品はこの装体間に合わせ継承していたが,全知検索窓以外では過度に重々しく見える問題があった先日描出ボタン改良好感触得たため,汎用的なボタン装体はそれに合わせてまとめることにした。

ボタン装体軽くなったことで全体的な釣り合い変わったため,一通り関連する装体調整行った設定ページ装体調整前だいぶ良い感じになったが,特に装体調整前大きく洗練されたこれまでの重々しくごつい印象が,だいぶ軽く柔らかく見えるようになった。スクリプト挙動おかしい所もいくつか修正した

新生デライト完成目前丁度良い然るべき時期出来て良かった


下見アイコンもここで出振るい出来た

足りず領当てが崩れることに気付いたため,幅狭領当てでは字数計をいったん非表示にすることにした。

{進捗記録}{進捗}{希哲16年2月9日}{希哲16年2月8日}{出振るい}{分かる}{希哲16年2月15日24歩}{希哲16年2月9日の開発}{確信が持てなかった}{領当て}(122)

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

進捗時限記録中略前後

デライト装体調整昨日7歩に関する整理終了

見出し段落よりも横幅両端0.5remずつ広げ区切り線<hr>段落よりも0.5remずつ狭めることにした見出しと区切り線装体・幅調整後

当初見出し下線区切り線見分けやすくするために,区切り線両端1emずつ狭める形にしかけたが,試しに出振るいしてみたこの形が想像以上しっくり来たので,基本方針として採用してしまうことにした。

文書構造視覚的にぐっと把握しやすくなった


段落に対して僅かに字上げするような見出し装体昔から気に入っていて,現状でも「はじめに」などのデライト文書<h2>1em<h3>0.5em字上げされている長らく更新していないため描写内見出しとは全体的に乖離している)月庭でどうしていたか忘れたが,特に理由がなければ似たような装体採用していたはずだ。

やはり,見出し直感的に把握しやすいのが大きな利点だが,描写内見出し採用出来なかった理由として,無駄な余白生じやすいという領当て上の問題大きかった。特に,諸場対応から強く意識するようになった幅狭領当てでは小さくない問題だった。

今回実験意外だったのは,全ての描写内見出し0.5remずらすだけでも十分な視覚効果得られたことだった。これなら,他の装体そのままに,見出し装体マージン削るだけで一応実現出来る。

読み込み中...
{進捗記録}{}{右上}{}{知名}{描写}{進捗}{描写下見機能}{希哲16年1月23日}{用者}(90)

{希哲16年1月23日1歩 K#F85E/E74C-27DA}

換配確認機能」についての再検討終了。なお,この検討から「下見プレビュー機能」に改称した。

下見機能は,輪郭選り手左下下見ボタンを置く形でほぼ確定か。


デラング整備進展とともに重要性増している下見機能だが,用合いをどうするかについてはまだ少し迷いがあった。

一応最有力案は,輪郭選り手左下に「確認ボタン」を置くというものだった。左上公開設定機能右上取り消しボタン使いたいので,左下置くのが自然ではある。

完了ボタン並べるという捨て切れなかったが,押し間違い多発しそうで用合いとしては難がある

今朝ふと,確認ボタンから描き出し完了ボタンへの二段階方式浮上してきた。つまり,必ず換配確認をしてから描き出し描き直しを行うことになる。

二段階方式利点には用合い単純化初心者にとっての流れ分かりやすさおまけに捌き手負荷軽減見込めるが,使い慣れた用者にとっては煩雑になり過ぎる懸念があり,採用見送った

ある程度複雑なデラング記法使う場合など換配確認をしたいこともなくはないが,確認するまでもない描き直し多々ある。また,公開設定機能導入によって気軽に描き出し描き直しが出来るようになると,役割重複してしまう。

一つ,輪郭削除確認機能を兼ねられるかとも思ったが,そもそも知名描写にして削除というのが確認作業兼ねているためこれもやはり煩わしい

やはり,換配確認選択的機能にしておくべきだろう。

これまで,完了ボタンに近い位置に置くことも考えていたため,描出流れの中で分かりやすいように「確認ボタン」「換配確認機能」などと「確認」をプレビュー日本語表現として採用していたが,ある程度独立した機能として認識しやすいように今後は「下見」とすることにした。

{希哲8年}{希哲3年}{希哲2年}{希哲元年}{日本語}{一日一文}{皇紀}{文化}{希哲館}{希哲館訳語}(77)

{希哲紀元とは何か K#F85E/E74C-DC33}

私はよく「希哲〜年」と書いている。例えば今年2021年なら希哲15年となる。これは「希哲紀元」という希哲館独自の紀年法だ。希哲館事業発足2007年希哲元年とし,そこから希哲2年希哲3年と数えていく。

この希哲紀元を私的に使い始めたのが希哲8(2014)年頃だから,もう7年ほど経つ。


希哲館訳語からも分かる通り,希哲館では日本語最重要視している。日本語の力を活かして知識産業革命を成し遂げ,日本語を世界中に広めたいと思っている。

ところがここで一つの問題があった。日本語で使える普遍的かつ合理的紀年法が無かったのだ。

我々日本人元号に慣れているし,愛着を持つ人も多いだろうが,元号はあくまでも天皇権威由来するものであり,外国人に押し付けられるものではない。紀年法としての分かりやすさ犠牲にする代わりに時代感共有しやすいなどと言われるが,それも国内の問題に過ぎない。

それでも日本人は元号を使うんだ,と言えるほど元号にこだわりがあるのかと言えば,実態はそうでもない。西暦も当たり前のように使われており,面倒だから西暦だけにしてくれという人もまた多い。ではその西暦に問題が無いのかと言えば,キリスト教価値観に基く紀年法が中立なわけはない。

キリスト教徒の少ない日本で,元号を捨てて西暦だけを使うようになった日本人というのも奇妙だろう。かといって,元号のみを使うのも皇紀を使うのも現実的ではない。併用している現状が良いのかと言うと,やはり面倒なことが多々ある。

残念ながら,日本語現状として,気持ち良く使える紀年法は無い。この気持ち悪さに自分なりに決着を付けたかった。希哲紀元を使い始めた動機はそんなところだ。


読み込み中...
{進捗記録}{進捗}{デライト}{通注}{最初期実装}{希哲15年3月4日の進捗時限}{希哲15年3月4日の進捗}{希哲15年3月4日}{デライト文書構造最適化}{描き直す?}(55)

{希哲15年3月4日5歩 K#F85E/E74C-2402}

デライト文書構造最適化中景部微調整

途中で終了。

統一感の無かった描出ボタン描き出しボタン描き直しボタン)と通注表現調整

ラベルには「描き直す?」と表示しておき,押すと「描き直す」に変わっていた描き直しボタンを「描き直す」と「完了」の組み合わせ修正。これに合わせ通注も「〜で編集」から「〜で描き直す」,「〜で保存」から「〜で完了」という表現統一

新規描出フォームでは描き出しボタンに合わせ通注の「〜で保存」を「〜で描き出す」に統一。

通注最初期実装から分かりやすさ重視し「編集」と「保存」の表現を使っていたが,その後,描出ボタン実装するにあたってボタンのラベルには「描き出す」,「描き直す」を使い,通注の方を放置していたことでこうした不統一が生じていた。

いずれにせよ描き出し描き直しデライトのごく基本的用語なので必ず理解してもらう必要があり,Twitter における「ツイート」同様ブランディング一環でもあるため,常に表示されているボタンには使わざるをえない(ここで使わなくて済むならそもそも特別な用語自体必要ない)。

ここで「編集」や「保存」などの用語が混在していることは好ましくないとは感じていたが,微妙に使い分けたいこともあり難しいところだった。

描き出しはともかく,描き直し編集欄を開く操作保存する操作があるため,これのために「」を使うという苦肉の策を取ったりしていた。後者のために「保存」を残すかとも考えたが,「完了」が一番自然であることに気付き決着

ちょっとしたことのようで大分すっきりしたように感じる。

{『希哲日記』}{日記}{}{KNS}{デライト}{}{デライト開発}{持ち辺}{デライト宣伝}{自我アイコン}(58)

{希哲15年1月6日の日記 K#F85E/E74C-D3BF}

ツイスト宣伝重視するようになってからデライト宣伝への反応は明らかに鈍くなっているが,最近,見せかけ分かりやすさではなく,ありのままデライト理解してもらうことの重みに向き合えていることがむしろ嬉しくも感じられる。

そしてこの重みは,「サービス統治」という観点からはかえって好都合かもしれない。文字献典収益性を上げるためには,玉石混淆割合をいかに上げるかがになるからだ。

今のデライト治安投稿の質ともに良好で,低質悪質投稿であふれ返っているよりはずっと良い状態にあると言える。この雰囲気を保ったまま活動用者が安定的に増えてくれるだけで収益化はそう遠い話ではなくなる。収益を得ながら爆発的増加に備える時間稼ぎが出来れば理想的ですらある。

いま取り組んでいる自我アイコン設定機能の実装も,KNS としてのデライト理解してもらうためという持ち辺が大きいが,これが一段落したら主要文書整備に取り組むことを考えている。

最新の方針実装との乖離が大きくなっているデライト主要文書については昨年9月19日にある程度改善案がまとまっているが,その後の変化を考えると今が一番効率的に片付けられる時期だろう。

新型コロナウイルスの新規感染者が2日連続で最多記録を更新し,米政局に大きな動きがあった日でもあり,情報収集考え事デライト開発には集中出来なかった。

焦らず弛まず」を心がけ,生活律動矯正のため早めに寝ることにした。

{分かりやすさ}

{}