{確実に}{戸惑っている}{言い切れず}{時間を奪う}{単純に}{日に日に}{描出手法}{負けず劣らず}{遂げている}{意外な発展}...=}(51)

{希哲15年9月14日の日記 K#F85E/A-E74C-4EEF}

やや軌道から逸れながらも,それを補う程度には成果を出している新生デライト開発負けず劣らず輪郭整備最近意外な発展遂げている

律動的集中生活に入ってから,朝の輪郭整備朝のデライト宣伝のような日課としての描出休止しているが,ここのところ,作業の合間などでついつい輪郭整備時間を費してしまう。

デライト自体が日に日に快適になっていること,描出手法洗練されてきたこと,素材として利用出来る輪郭充実してきたことなどで,単純に描出楽しく,ハマってしまっている。中毒性があるのはネットサービスとしては良いことだが,新生デライト開発時間を奪ってしまっている面もある。

ただ,輪郭整備は,見本献典拡充SEO手定め学習など,多方面効果のある作業だ。確実にデライト肥やしになっているという感触もあるので悪いとも言い切れず,少し戸惑っている

15日振り返り日記

=}
{大きかった}{非対応舞覧}{減らしたかった}{性能低下}{高負荷時}{大きな負荷}{録出力}{選択的読み込み}{離立備立}{やや混乱}...=}(97)

{希哲15年9月3日の開発 K#F85E/A-E74C-339B}

気になっていたデライト高速化に関する問題をいくつか片付け出振るいした。結果として大きな体感表示速度向上が見られた。

離立備立デバッグ備立切り分け

やや混乱していた kn cpl などを整理しながら,離立備立デバッグ備立切り分けられるようにした。5月デバッグ出力整備デバッグ出力録出力切り分けておいたことも奏功し,作業円滑進んだ

これまで,本番環境でも deln.fcgilibxtdxpo.Pgデバッグ出力無効化していなかった。特に大きな負荷になる要素ではないが,高負荷時性能低下要因極力減らしたかった

精神衛生的な面でも効果が大きかった。長い実験段階を終え,一つの製品として完成に向かうデライト象徴する出来事のような気がして嬉しかった

デライトの WebP 対応

一般用者自我アイコンWebP 化完了し,添付画像を除き,現時点で出来るデライトの WebP 対応完了した。

添付画像仕様再検討

先月31日12歩ではすっかり忘れていたが,互換性問題があるため,当面は元画像WebP共存させておくことにした。特に,Safari対応遅かったため,まだ WebP への統一時期尚早だろう。

非対応舞覧市影小さく,デライトにおける譜類添付機能もそれほど本質的付徴ではないため,割り切って無視出来なくもないかとも考えた。いずれにせよ,気になるのはストレージ容量なので,それが問題になるまでは様子見することにした。

外部スクリプト選択的読み込み

輪郭を含むページ無条件読み込んでいた KaTeXhighlight.js を,必要場合だけ後縁出力させるようにした。

体感表示速度への影響はこれが一番大きかった

交度記法における言語管理にも応用出来る。

{大きく依存}{希哲15年9月3日}{後から付いてくる}{広さより深さ}{十分な収益}{収益が上がる}{動かしようがない}{一見}{寄り付く}{捨て切れない}...=}(125)

{希哲15年9月1日の日記 K#F85E/A-E74C-7706}

実装作業もそれなりに捗ったが,頭の整理もだいぶ進んだ一日だった。幸先が良い

組計整理み,当面組計見通しはさらに改善気持ちにも落ち着きが出てきた。

デライト市場戦略にも大きな進展が見られ,より一貫性が高まった。

なんとなく対 Facebook 戦略について考えていると,用者数30億人に迫る Facebook勝つのに50億人100億人目指すのはあまり賢くないな,という思い沸き起こってきた。

大きな風船量的大国には小さな弾丸質的大国ぶつけるしかない,というのはジパング計画考えてきたことだが,デライトに関しては,量より質という考え方徹底出来ず,まだ爆発的流行による成功という可能性捨て切れずにいた。

超高効率経営があり,安定拡大戦略があり,書き手読み手能力大きく依存する文字献典重視し,日本日本語重視し……と,全体として量より質志向すべき環境整っていた。現に,いまデライト運営なのは,異常なまでに知的好奇心旺盛リテラシー高い日本人用者しか寄り付いていないからだ。国内外から無闇に用者をかき集めていたら,いまごろ破綻している。

輪郭一覧にあるデライト広告も,どちらかといえば一見よりも描き手向けになっている。初期配置を決めてから何度再検討はしたが,ほとんど動かしようがなく,結果的にこうなっている。輪郭そのものに対して広告を付けると,単純描き手読み手双方にとっての快適性損うという問題もあるが,扇情的内容が増えれば増えるほど収益が上がる構造になり,信頼性モラル低下きかねない。

これだけの条件揃っていながら,まだ揺らぎがあった。問題は,こんな広告十分な収益を上げることが可能なのか,確証が掴めていないことだった。これについては先月実証され,最近では,全知検索使い込んでくれる重用者をいかに増やしていくか,という意識が高まっていた。これが最後のピースだった。

ここからは,デライト市場戦略でも,量より質広さより深さという考え方徹底していくことにした。デライト知能増幅メモサービスとしての完成度高めていけば,用者必ず後から付いてくる日本語圏限界に達する時には,世界中の人が日本語ばざるをえないだろう。

2日振り返り日記3日加筆修正

=}
{希哲15年8月28日の開発}{制危上の問題}{導入の敷居}{実験的 API}{簡易ウェブ捌き}{領下譜類}{Native File System API}{希哲15年8月28日の進捗時限}{希哲15年8月28日の進捗}{希哲15年8月28日}...=}(36)

{希哲15年8月28日8歩 K#F85E/A-E74C-9492}

公開設定機能領下譜類として扱う設定加える検討終了

デルン譜類管理系として利用するは以前からあり実験的なこともしていたが,簡易ウェブ捌きでも作らないと領下譜類を扱うのは難しいと考えていた。

しかし,どのみち高い導入の敷居を考えれば,Native File System API のような実験的 API拡張機能利用することを考えてもいいかもしれない。

ただし,輪郭の内容を領下に保存していても舞覧で扱う以上制危上の問題ゼロではなく,デライト側の瑕疵誤送信などが発生する可能性はあるので,あくまでも将来的可能性に留めておく。

=}
{希哲15年8月27日の開発}{ポリシー違反}{広告配信業者}{広告配信}{希哲15年8月27日の進捗時限}{希哲15年8月27日の進捗}{希哲15年8月27日}{公開設定}{自分だけ}{分からない}...=}(22)

{希哲15年8月27日11歩 K#F85E/A-E74C-35C7}

デライト広告公開設定著作権問題についての整理終了

とりあえず,「自分だけ」に設定した輪郭に限り,私的複製解釈することにした。アカウント共有などで著作権侵害が行われる可能性もあるが,これに関しては関知しえない利用者違法行為とみなす。

そうした輪郭が含まれるページに広告配信した場合,広告配信業者ポリシー違反になるかどうかは分からない

=}
{Re:「近象」と「遠象」について}{希哲15年8月13日のツイスト}{希哲15年8月13日}{文字列型}{良い例}{変種}{単純な}{抽象性}{輪郭}{ツイスト}...=}(42)

{「近象」と「遠象」について K#F85E/A-E74C-B093}

近象」というのは,感覚的身近抽象性のことです。言い換えると,「より単純包括的なもの」,つまり「輪郭」的なもの,ということになります。その反対が「遠象」です。

抽象」は,本来何かのために思考単純化するものですが,必ずしも感覚的近さ意味しません。数学のそれが良い例です。

例えば,「近象文字列」というのは,簡単に言えば「文字列直感的に扱えるように抽象化したもの」です。この直感的というのも厳密には「思いついたように扱えること」という意味で,「直想的」と表現していました。

C++文字列std::string と書きますが,様々な変種もあり,「文字列を扱いたい」という書き手単純な要求に対して直想的ではありませんでした。書き手の頭の中で,「文字列を使うこと」と「std::string を使うこと」の間に距離があるということです。C++ ではライブラリによって異なる文字列型を使い分けることが多々あるので,std::string固有名詞的に文字列を扱う手段の一つとしか認識されていません。

では,s_T として「細かいことはさておき大体の場面で使える文字列型」を提供することにしました。「文字列を使うこと」と「s_T を使うこと」が概念として普通名詞的に)一致するように設計されています。これを「近象文字列」と呼んでいました。

{希哲15年8月2日の開発}{私的複製}{パクりサイト}{サービス全体}{引用の主従関係}{著作権的}{公開設定機能}{未公開非共有}{公開設定}{希哲15年8月2日の進捗時限}...=}(41)

{希哲15年8月2日15歩 K#F85E/A-E74C-8EB5}

公開設定機能公開範囲設定機能についての検討終了

描写埋め込みでは,公開設定無視出来ることにした(ただし,自輪郭に限ってなど何らかの制限必要だろう)

一つの動機として,引用などの著作権的問題回避出来そうということがあった。

引用の主従関係については,文書としての輪郭特異性から何とも言い難いところがあったが,引用文だけの輪郭が増え過ぎれば NAVER まとめ二の舞になりかねないという危惧もあった(もっとも,サービス全体としては独自性のかたまりなので単なるパクりサイトとは言われないだろうが)

とはいえ,引用文輪郭として保存して再利用したいというのは自然の流れで,法的な問題なくそういう活用が出来る環境を整えたいと思っていた。

公開設定機能描写埋め込みが出来るようになれば,引用文だけの輪郭未公開非共有にして私的複製扱いにしつつ,公開輪郭に埋め込んで利用するといったことが可能になる。

=}
{Meson}{新生デライトの要件}{日本語表現}{換配確認機能}{確認ボタン}{プレビュー機能}{開閉状態}{応用の可能性}{確認用}{ページ読み込み時}...=}(109)

{希哲15年8月1日の開発 K#F85E/A-E74C-7A28}

新生デライトの要件

もう考えていても仕方ない段階に来ているので,とりあえず雑に書き出しておく。

舞覧手定め環境整備

舞覧手定め環境整備一環として,SLFSChrome59最新版92更新

3月15日7歩でも試みているが,その時は libxkbcommon不足失敗依存性地獄懸念して中断した。

libxkbcommon引装には MesonNinja の引装が必要で,Meson と Ninja には Python 3 の引装が必要だったものの,それ以外に直接必要なライブラリはなく,意外とあっさり更新出来た。

これで SLFS では FirefoxChrome最新版が使えるようになり,手定め用iPhone 7近日中手に入る予定なので,舞覧手定め環境整備はここで一段落とする。

Android 端末向けの舞覧手持ちのスマホで,Edge 含め,Windows 向けの舞覧Windows 仮想機で使える。

実機仮想機では主に最新舞覧を使い,古い舞覧などは LambdaTest などのサービス利用すれば十分だろう。

輪郭選り手抜控機能整備など

描き直し選り手同期するように調整

とりあえず,選り手が開いている場合に内容同期させるようにだけしておいた。これで複数窓で同じ輪郭の選り手が開いていても混乱しにくくなり,内容が長い場合には複数窓で別々の箇所を編集することも出来るようになった。

現状,抜控のある選り手はページ読み込み時に開くようになっているが,閉じている場合でも別窓で抜控が出来た場合は開いたり,別窓で閉じた場合は自動的に閉じたりと,開閉状態同期もしようかと思っていた。これは止めておいた。

開閉状態の同期はしない方が,一方の編集用にして,一方の窓を確認用するなどといった応用の可能性が広がることに気付いた

現状では描き直し完了選り手閉じる機能的に一緒になっているが,複数窓有効活用を考えると保存と閉じるで分離すべきか。取り消しボタンを閉じるために使うかと思ったが,操作性を考えると,今の完了ボタンを保存・閉じるの二段階にする方向が良さそうだ。

そんなことを考えているうちに,保存せずに換配後プレビューが出来る機能についても検討し始めた。概念操作複雑化を避けることを考えるなら,完了ボタン機能現状維持プレビュー機能本命かもしれない。

プレビュー日本語表現は「確認」が分かりやすいだろう。内部的には「換配確認機能」や「確認ボタン」と呼んでおくことにした。

=}
{輪郭}
{}