{希哲15年10月14日の整清}{USB 配線整理}{綺麗にまとまった}{動作不良}{USB 3.0 ポート}{1つ}{中段}{入力装置}{2つ}{挿し替える}...=}(48)

{希哲15年10月14日5歩 K#F85E/A-E74C-884A}

主力機USB 機器整理

以下のような配置綺麗にまとまったため,いったん終了。これまで特に配置を決めず,適当にしていたので清掃後復元面倒だった。今後はこれを叩き台調整していく。

=}
{使わなくなった}{触らない}{よく使っていた}{打ちながら}{全体的な}{やりたかった}{ずっと}{希哲15年9月28日}{希哲15年9月26日の整清}{見つからなかった}...=}(45)

{希哲15年9月28日の整清 K#F85E/A-E74C-9B6A}

譜類整理

ずっとやりたかった全体的な譜類整理着手した。

ls打ちながらというのも辛いので,SLFS にも何か譜類管理系導入することを考えた。以前よく使っていた Thunar を入れようかと思ったが,極力依存性低いものがいい。しかし,単純引装しやすいものがなかなか見つからなかった

結局,Dired使うことにした。開発作業流れでは日常的に使ってきたが,こういう視点で使うことはあまり無かった。

テンキー

26日の整清なんとなくテンキーHHKB右上配置してみたが,これがなかなか良い

これまでマウス右側に置いていた。いまいち活用出来ず,ほとんど触らなくなっていた。

携帯抜控 DVD ケース

携帯抜控 DVD ケース26日の整清配置整理してからまた使えるようになり,日次抜控やりやすくなった日次抜控で使うことにしたものの,いつの間にか使わなくなった

ほか

1時間ほど家事など。

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

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

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

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

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

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

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

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

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

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

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

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

=}
{配置}{広告}=}(2)
{Android}{iOS}{共有ボタンを追加しました!}{タッチ端末}{マウスアウト}{デライト扉の様子・共有ボタン実装後}{雑然}{モノクロ}{四分円}{ell.x2.png}...=}(71)

{希哲15年3月27日の開発 K#F85E/A-E74C-1FE0}

主に共有ボタン実装

想像以上に確認調整しなければならないことが多く手間取ったが,それでも OGP 対応作業開始からわずか2日納得出来る形になった。



予定通り,採用サービスは FacebookTwitterLINEはてなブックマークPocket日本国内利用者数の多いサービスをより共有ボタンに近付ける形で配置した。

Web Share API に対応していれば省略記号(...)が表示され,それを押すと端末ネイティブ共有機能利用出来る。省略記号の画像には全知検索ページャーに使っている ell.x2.png がそのまま使えた。AndroidiOS動作確認済み

当初,不揃いな各ボタンを整然と並べるために四分円を使い,横長の Twitter と Facebook,正方形の LINE とはてブ,最後に Pocket,と三段で構成することを考えた扇形共有ボタン部区が,これは廃案とした。試してみると意外と悪目立ちしたため別の領当てを模索していたところ,二段目の余った左余白に Pocket と省略記号を並べれば綺麗にまとまることに気付いた。

例えば同じ形状モノクロにするなど,よくあるアレンジを加えようかとも思ったが,各サービスの利用規約に抵触する可能性がある上,用者にとっては一見して分かりにくいものになりがちなので,公式のものをそのまま利用することにした。

各サービスの徹案依存する格好にはなるものの,TwitterFacebook に合わせているのだろうし,LINE正方形ボタンを変える理由もなく,はてブは柔軟性があるのでそれなりに安定して使える領当てではないかと思う。

用合いとしては,共有ボタンへのマウスオーバー小窓を開き,小窓からのマウスアウトで閉じるようにした上で,タッチ端末向けにクリックタップ)での開閉も出来るようにした。触り心地良好だ。

でもデライト語体の右下に置いておくことにした(デライト扉の様子・共有ボタン実装後)。

ソーシャル ボタンは,徹案の上でも処理の上でも雑然としたものになりがちなので,単純性重視しているデライトでの採用は見送り続けてきた。普段は邪魔にならず,かといって手間にもならず,用者にとっては分かりやすく,そこそこ美しくも見える……と,限りなく理想形に近いものが出来たと思う。

LINEPocket は使ったことがなかったため,本機能の手定めのためにアカウントを取った。



エクスポート機能仕様検討も進んだ(9歩)。

{迷いをなくしておく}{ご回答ありがとうございます。}{輪括}{引き入れ}{立体階層構造}{子輪郭}{親輪郭}{輪郭構造説明図粗描}{輪括記号}{輪結}...=}(33)

{後景記号 =} について K#F85E/A-E74C-1BB1}

ご質問ありがとうございます!

記号 =} は,輪郭間の関係を表す記号で,「後景記号」と呼んでいます。逆向き {= は「前景記号」ということになります。

以下の図を見て頂くと分かりやすいのではないかと思いますが,「立体階層構造」とも言える輪郭同士の入れ子関係は遠近関係でもあります。つまり,親輪郭前景(手前)で,子輪郭後景(奥)に配置されているというイメージです。

親子というのは便宜上の表現で,正式な用語としては前景・後景といいます。一覧では三層になっていますが,中間のものは中景と呼びます。

この記号は,どちらかというと不等号集合記号のような数学記号イメージで昔考案したものです。単純に連想関係を表す矢印のようにも見えるので分かりやすいだろうと思いました。

ちなみに,引き入れ関係は「輪括」(リンクルージョン)と呼びます。希哲館訳語輪結リンク)と引括インクルージョン)の合成です。この二つの性質を合わせ持っていることを表現しています。

後景記号前景記号を総称して「輪括記号」とも言えます。

このあたりの用語記号はまだ整備途上なので,将来的には変わる可能性もあります。

逆向きの方が直感的というのは新鮮ご意見だったので参考になりました。今後の検討材料に加えさせて頂きます。

{希哲14年10月18日の開発}{希哲14年10月18日の進捗時限}{希哲14年10月18日の進捗}{希哲14年10月18日}{描出ボタン}{ボタン式操作}{装体}{進捗記録}{進捗時限記録}{進捗時限}...=}(17)
{希哲14年9月24日の開発}{HTTP/2}{あれ}{推奨動作環境}{埋没時間}{希哲14年9月24日の進捗時限}{希哲14年9月24日の進捗}{希哲14年9月24日}{スプライト化}{デライト・アイコン集}...=}(56)

{希哲14年9月24日2歩 K#F85E/A-5B28-A037}

昨日,アイコンスプライト化3歩ほど試行してみて,やはり保守性問題を感じた。

ドメイン シャーディングにも言えることだが,最適化のために実装意図曖昧遠回しにする,というのは全体最適化観点から避けるべきことだ。開発者としてはどうしてもここにひっかかる。

そんな時,HTTP/2 のことを思い出した。RFC 7540 が出来た頃に情報収集した記憶があるが,流石にその時は時期尚早導入は考えにくかった。現状月庭も含めてデルンHTTP/1.1 で動いている。

改めて調べてみると,採用実績は十分にある。請い手側の普及率調査によって中途半端なところもあるが,時間解決する問題であること,そもそもデライト比較的新しいブラウザ事実上推奨動作環境としていることから問題ない。

kitetu.com の HTTPS 統一 はすでに実現しているため,手定め環境nginxngx_http_v2_module導入するだけで環境は整いそうだ。

スプライト化に費したのは,デライト・アイコン集制作の時に配置工夫したこと,昨日の3歩くらいで正味数時間だろう。埋没時間はほぼない。

早速 HTTP/2導入試験を始めることにした。

ちょうど11月から GooglebotHTTP/2 に対応するらしいので,今が好機なのだろう。

=}
{希哲14年8月7日の開発}{全知検索ページャー}{あれ}{上線}{下部ページャー}{ページ番号}{ページ更新}{更新不要}{灰色表示}{上部ページャー}...=}(44)

{希哲14年8月7日9歩 K#F85E/A-5B28-ACED}

前後景一覧整備,装体書整理ページ付け

ページャー仕様徹案は概ね出来ページ付けに関しては実装調整を残すのみとなった。色彩配置記号など試行錯誤したが,何とか満足出来るものになった。

まず,輪郭一覧上部ページャー初期状態で下図のように表示する。左肩には更新を示す輪結 灰色表示され,これは更新不要示唆している。右肩に輪数を置く。

新着確認が出来た場合,下図のように新着輪数を加えて を表示する。

一定時間で新着確認機能が停止しても新着確認が出来なかった場合は,? を加えて を表示する。

この新着確認実装優先度は高くないためデライト離立補完後に回す可能性も高いが,無駄ページ更新抑制する効果も見込める。

上部ページャー2ページ目では下図のように変化する。先頭の意を で表し,ページ番号が表示される。輪数には表示範囲が加えられる。

さらに,3ページ目では下図のように変化する。1ページ戻るための が加わる。

下部ページャーも基本は同じだが,左下には新規描出+ を表示しておきたいため,右下に置く。また,状態を把握しやすいように,1ページ目からページ番号を表示しておく。

当初,↑↓の矢印の横に前ページと次ページのページ番号を表示させるつもりだったが,このまとめをしながら修正した。現在のページ番号が分かれば前後は自明なので,こちらの方がすっきりする。

また,ページ番号の上線下線の表現に合わせて範囲を表現している。輪数数字と区別しやすくすると同時に,将来的に直接ページ番号入力出来るようにした際,プロンプトを兼ねるようになっている。

なお,初期状態の取得時印送信するため,ある時点からの一覧新規描出によって伸びてしまうということはない。再描出によって縮んでしまうということはありうるが,現時点でさほど問題になるとは考えにくいため,頭の片隅に入れておくに留める。

{配置}
{}