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

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

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

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

{デライト}{OFFSET}{減らせる}{付けたかった}{ts_upd}{利用しやすくなった}{実装しておいた}{一覧部分}{整備した}{隠し効率}...=}(210)

{希哲16年6月30日の開発 K#F85E/E74C-A106}

デライト高速化における KNEST 隠し実装一段落した。18日作業方針検討のみで20日から,休日除いてちょうど10日間での達成だった。出振るい済み

全体としては大成功だった。

必要以上に固め過ぎるのも良くないため,隠し化現時点最低限必要範囲留めたが,期待以上安定性期待通り高速化得られた次の施策出来たので,まだまだ高速化出来るKNEST 隠しDex匹敵するデライト武器になるだろう。

交度整理しっかり進めたこともあり最初の輪数取得改良想定以上に長引いたものの,ここで KNEST 隠し共通の問題ほとんど解決したため,自我隠し輪郭隠し半日ほどで終わった。この交度整理収穫として大きかった輪郭操作系の kn の外充て函数整備したことで関連交度一気に整理された

影響範囲確率的に大きな問題はないだろうと見て排他制御甘い部分あえて残して出振るい急いだが,出振るい直後壊衝多発して少し焦ったすぐに論軸的問題気付修正し,その後むしろ想定以上に安定して動いている。この判断結果として正解だった。

輪数取得改良

輪数隠しに関しては,第二次知番改良中に固まった輪数取得改良」として,輪数取得仕組み全体的に改良した

これまでデルンではいちいち厳密な輪数表示をしていたが,これが大きな低速化要因になっていた。デライト以前まで,count()遅さ対する認識が甘かったデライト以後そもそも出場における件数計算原理的に遅いもの,と気付いてページ付けOFFSET上限設けるなどの対策はしていた希哲13年10月14日の開発記録が,輪数一筋縄ではいかない部分があり放置してきた

厳密な同期必要性隠し効率から,次のように整理することにした。

この通りに実装終え上手く動いている

また,この過程で各輪郭操作での輪数更新必要になったため,ほとんど未実装だった輪郭操作系の外充て函数整備した

自我隠し輪郭隠しから次の施策

自我隠しに関しては昨年4月中途半端な実装をしていたため,これを整理した輪郭隠しは,現時点一覧部分には適用出来ないものの一応実装しておいた

自我隠し出来たことで自我情報利用しやすくなったため,自我アイコンts_upd使った隠し破り付けたかったが,自我情報取得部分がまだ非効率なので見送った

輪郭情報求頼分割し過ぎているので,これを統合することを考えているうちに,次の施策まとまった

輪郭一覧については,まず知番のみで中景輪取得し,輪郭隠し照合してから三景輪郭情報同時に取得することにした。これで輪郭隠し効率的に利用出来求頼大幅に減らせる予定していた検索属性もここで盛り込む

{高さ制限}{内容の高さ}{機能的に}{混乱させない}{用者層}{利用率}{ウェブ利用者}{影響しない}{設定しておく}{最初以外}...=}(92)

{希哲16年5月30日の開発 K#F85E/E74C-DB91}

自動ページ展開機能実装一段落した細部に課題はあるが,実用出来る水準に達した出振るい手定め済み

これに伴い正式離立前試していた全知検索窓新規描出フォームの固定表示復活させる検討大きく進んだ。また,輪郭一覧動的追加仕組み整えたことで,検索新規描出時にも応用出来るようになった。輪郭一覧の更新効率的に行えるようになり,高速化にも大きく貢献するだろう。


AutoPagerize 対応どうするかというのが難しい問題だったが,これは挿入監視して削除注意書き表示する方向落ち着いた最初以外 .autopagerize_page_elementdisplay: none設定しておくことで表示には影響しない

AutoPagerize は,ウェブ利用者全体ではわずかな利用率だが,デライト用者使っているのを見て私自身使うようになったというのもあり,用者層重なり小さくない出来るだけ混乱させないようにしたかった。


今後広告の調整重要になってくるため,ここで運営者開発者向けダミー広告表示する仕組み整えたダミー広告の様子

AdSense は,設置者によるクリックもちろん無闇に表示させることも避けるべきとされているので,これまでは単に非表示にしていた


機能的に自動ページ展開機能似たところがある描写後略機能実装方針検討ほぼ完了

内容の高さ高さ制限足りない場合どうするか最後の課題だったが,これは舞覧側で追加取得すればいいことに気付いて解決した


=}
{出振るい}{低下する}{発生していない}{心当たりがない}{一番気になった}{新規描出下書き抜控}{判別用}{Aejs_DG_rev}{長期的視野に立って}{更新方法}...=}(224)

{希哲16年5月23日の開発 K#F85E/E74C-8D2F}

輪郭選り手抜控機能整備概ね終えようやく出振るい出来た追い追い修正していけばいい程度の軽微な不具合はいくつか見つかったが,抜控機能整備についてはここで一段落とすることにした。

この出振るいにより,中途半端な実装だった輪郭選り手抜控機能一通りの機能揃った下書き抜控一覧使えるようになり,抜控把握容易になった予てから欲しかった新規描出フォーム消去復元ボタン抜控削除のため追加した18日の開発実装した描写拡縮ボタン使えるようになった。また,周辺の交度整理大きく進み,理腑としての意義大きかった

利便性信頼性向上はもちろんのこと,昨年から中途半端な状態引きずってきた当努片付いたことによる精神衛生上効果大きい昨年来他の当努本格的に着手していないか,着手して間もないので,ここから思考整理しやすくなる


抜控機能整備長引いた最大の原因は,他にやりたいこと多過ぎたことだが,これ自体も決して簡単な作業ではなかった。ただ,この間設計方針変わったり深刻な不具合気付いたりしたので,時間をかけたことで円滑に片付いたもある。

再描出知番でいいとして,新規描出をどうするか,というのは難しい問題一つだった。昨年7月28日6歩から検索語含めるようにして悪くなかったので,基本的にこれを踏襲することにした。ただし,全知検索窓から未送信検索語まで取っていたため,これを書き換える意図せず他の抜控上書きしたり消去してしまう可能性があった4月28日20歩書いた消失不具合原因だろう)。これは求頼文字列から取ることで回避した

下書き抜控一覧についても,表示条件領当てなど色々考えること多かった検討の結果再描出下書きは,検索語無し場合上部メニュー同様のみ輪郭一覧表示画面撮り新規描出下書きは,他の抜控がある場合のみ新規描出フォーム上に常に表示させることにした画面撮り邪魔になり過ぎない程度に気付きやすい。また,4月10日の開発決めた通り一覧省略などせずにそのまま表示することにした。描写部のように高さ固定することも考えたが,やはり,用合いの複雑化抜控溜め込み過ぎる懸念があるため見送った抜控溜め込み性能低下消失リスク増大(あるいはそれを補う作業コスト増大繋がる目障りになったら消化するようにしてもらいたい。

一番難しかったのは鍵仕様設計だった。一応鍵仕様変更時の更新方法考えていたが,手間考えるころころ変えるわけにもいかないので,長期的視野に立って設計する必要があった。これもなんとか落とし所見つかった一時仕様変更日時含めることを考えていたが,これは複雑化招くだけなので廃案とし,Aejs_DG_rev判別用文字列入れておくことにした。新規描出下書き抜控には自我知番含め自我切り替えにも対応した

その他,これまで描写のみ保存していたのを知名にも対応する消去ボタン復元ボタン実装する,などこまごまとした問題片付ける必要があった


出振るい後軽微な不具合がいくつか見つかったが,一番気になったのが,鍵仕様更新処理失敗だった。領下十分な手定めをしたつもりだが,本番環境では一部1回処理更新出来なかった結果的に3回実行する必要があった開発者通類localStorage内容見ても交度見返しても心当たりがない

少し迷ったが,時間が経つにつれ重要性急速に低下する部分なので,調査打ち切ることにした。最も使用頻度高い常連用者達が出振るい後普通に使えていることから,深刻な問題発生していない判断した今後同様処理書く際の注意点として記憶しておく。

=}
{👍}{希哲16年4月7日の開発}{希哲16年4月7日の進捗}{ページ遷移無し}{停止する}{フォームの送信}{-webkit-tap-highlight-color}{妙な効果}{タップ時}{用意されている}...=}(75)

{希哲16年4月7日14歩 K#F85E/E74C-D3A9}

進捗時限記録中略

細かい装体調整など。

iOS上のSafariで,横方向での閲覧時に引き入れ輪郭が不自然に大きく表示される」という不具合報告があったが,確かに手元iPhone同様現象があり,気になっていたデライトの不具合にしては不可解なのでもしかしたら舞覧稀なバグなのかと思ったが,再現性があるらしいことが分かったため調査した。

結局諸場舞覧自動拡大機能であり,text-size-adjust-webkit-text-size-adjust)という制御用CSS プロパティまで用意されていることが分かった。以下のようにして解決

-webkit-text-size-adjust: 100%;
text-size-adjust: 100%;

もう一つ諸場舞覧気になっていたことに,輪結ボタンタップ時妙な効果入るというのがあったので,ついでに調べてみると,これも諸場舞覧特有機能で,-webkit-tap-highlight-color不可視出来た


スマホ弄っているうちに,iOSSafari全知検索ボタン動き付け止まっていることに気付いた

これはフォームの送信などで描画処理停止する Safari 特有仕様であることが分かったSafari の問題といえばそうだが,実用上の問題はなく,まともな解決策無さそうなので放っておくことにした。

全知検索整備方針定まったことだし,そろそろページ遷移無し輪郭一覧更新出来るようにしてもいい頃だろう。

=}
{デライト}{用者}{知能増幅メモサービス}{『希哲日記』}{高い}{勝つ}{デライト市場戦略}{希哲15年9月の月記}{大きく依存}{希哲15年9月3日}...=}(126)

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

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

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

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

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

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

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

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

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

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

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

=}
{デライト}{一日一文}{希哲館}{希哲館訳語}{希哲8年}{希哲6年}{希哲2年}{希哲15年4月22日の日記}{投げ遣り}{翻訳語整備}...=}(66)

{希哲館訳語の原点,サブスクと待っ読(まっとく) K#F85E/E74C-B90D}

先日,デライトでも RSS 対応をした。以下のように,任意の輪郭一覧RSS で「待っ読(まっとく)ことが出来る。

この「待っ読」,フィードにおける〈subscribe〉あるいは〈subscription〉翻訳語として昔考案したものだ。

今のようにデルンデライト)で何でもかんでも記録するようになる前だったので,正確な考案時期は忘れてしまったが,デルンが実用化した希哲6(2012)年より前だったことは間違いない。ただ,しばらくはの一つだったようで,希哲8(2014)年に改めて採用することを決めている〈subscribe〉を「待っ読」と訳す

今となっては希哲館訳語蓄積膨大なものとなったが,そのほとんどはデルン実用化後に出来たものだ。「待っ読」は独自性を持つ最古の希哲館訳語と言える。「希哲館訳語の原点」と言っても過言ではない


この「待っ読」,すでにお気付きかもしれないが「積ん読」にちなんだものだ。

そもそも〈subscribe〉翻訳語を考えるきっかけは,phpBB3 という掲示板スクリプト日本語パックを作りたいと思ったことだった。希哲館事業発足間もない希哲2(2008)年のことだ。

phpBB3 は,希哲館情報交換のために使える掲示板として当時は有力な選択肢だった。かねてより必要を感じていた翻訳語整備も兼ねていた。今はデライトがあるが,このデライトを実現するためにデルンの実用化を目指すことになり,この望事プロジェクト自体は立ち消えとなった。

その中にこの用語があったが,直訳の「購読」では明らかに不自然だった。散々考えた挙句,投げ遣り気味に「積ん読」と訳すことを考えたRSS フィード等の “Subscribe” は「積ん読 (つんどく)」か。これは流石に無理があったものの,しばらくして「待っ読」の元になったわけだ。


それから十数年経ち,〈subscription〉という概念は,サービスなどの定額制を意味する「サブスク」として広く認知されるようになった。

しかし,フィード等の〈subscribe〉をどう翻訳するか,という問題は当時から未解決のままだ。

デライトでは,利用者が出来るだけ自然に使えるように,希哲館訳語のほとんどをあえて採用していない。見慣れない翻訳語に気を取られて欲しくないので,多少のカタカナ語には目を瞑っている。

それにしても,「サブスクライブ」も「購読」も自然分かりやすいとは言えない。なら「待っ読」でいいんじゃないか,と採用することになった。

最も思い出深い翻訳語がここで復活してくれたことに,運命的なものを感じざるをえない。

=}
{輪郭一覧}

{}