{`overflow: hidden`}{進捗記録}{希哲16年3月2日の開発}{希哲16年3月2日の進捗}{希哲16年3月2日}{`position: relative`}{`overflow: clip`}{調整していく}{揃わなくなる}{縦位置}...=}(83)

{希哲16年3月2日10歩 K#F85E/A-E74C-FDA9}

=}
{文字サイズ}{進捗記録}{目立たな過ぎる}{装体の調整}{読みにくさ}{短い URL}{事情が異なる}{ちょっと長い}{文書の傾向}{検討していた}...=}(94)

{希哲16年1月19日1歩 K#F85E/A-E74C-5396}

デライト装体調整URL 装体調整終了

直書き URL<a.URI>font-size: 0.9em等幅フォントにしたURL 装体調整前後字間無し昨年6月30日の開発からだが維持する。

直書き URL のある描写読みにくい問題はずっと以前から感じていて,何度か調整しているが,一昨日の開発中にふと,「文字サイズ小さくしていない」ことに気付いた

昨年6月30日の開発字間無しにしているが,等幅フォントにして変に目立ち過ぎるという理由したりもしている。この時になぜ文字サイズ小さくするという発想がなかったのか不思議だ。他にも問題山積していて思考時間割けず灯台の下まで目が行かなかったか。

今回<kbd><code>装体について考えていたところだったので,その関連気付けたのだろう。

文字サイズはやはり0.9em丁度良い0.8emにすると長い URL はともかく短い URL提示する時に今度は目立たな過ぎる


これにより,十分凝縮されメリハリが付いたので,予てから検討していた長い URL の省略については保留とすることにした。

長い URL の省略は,簡単なようでいざ導入しようとすると意外と難しい問題がある。

まず,デライト上文書の傾向からいっても,「ちょっと長い」程度の URL省略したくない。URL全体情報として有用場合しばしばある。このあたりはマイクロブログなどとは事情が異なる

では,どこで省略すべきかという問題になるが,長い URL許容すればするほど比較的短い URL読みにくさ解消されないというジレンマがあった。これは装体の調整解決した。

そもそも輪結記法[ ... ]もあるので,現状維持で特に困ることはないだろう。そのうち https://example.com/abc ... xyx のような省略記法導入してもいい。

ただ,パーセント符号化復号はしたい。これは昨年3月22日2歩決めていたことだが,少し面倒臭い部分がありいまだに実現していない。

{進捗記録}{Slackware 時代}{ネット環境整備}{希哲15年10月26日の開発}{希哲15年10月26日の整清}{内部配線}{試していない}{良い復習}{弄っていなかった}{変わらなかった}...=}(70)

{希哲15年10月26日9歩 K#F85E/A-E74C-A67B}

ネット環境整備配線整理過程SLFS における USB 3.0 ポート認識不良についての調査始めたものの,未解決保留

主力機には筐体前面背面にそれぞれ2つずつ USB 3.0 ポートがあるが,Linux では Slackware 時代からいまいち使えた試しがない。それもそのはずで,どうも USB 3.0 ホストコントローラー認識されていない最初から Windows仮想機でしか入れていないので,Linux 固有問題かもしれない。

lspci では Etron TechnologyEJ168 が見えるがドライバ表示がなく lsusb では表示されない。

怪しいのは UEFI核脳構配起動応付あたりだが,今のところよく分かっていない。UEFI 設定見直した明らかおかしい所は見つからなかった

核脳構配では,そもそも USB 3.0有効にしていなかったので CONFIG_USB_XHCI_HCD=yCONFIG_USB_XHCI_PCI=y加えて核脳再構築をしたが,相変わらず。更に CONFIG_USB_XHCI_PLATFORM=y を加えても変わらなかった

これまで使っていた Linux 核脳 vmlinuz-4.9.9-slfs-t2希哲11年6月28日備立したもので,しばらく弄っていなかったので,良い復習にはなった。今回の備立は一応 vmlinuz-4.9.9-slfs-t3 としておいた。今後何かと調整しやすくなるだろう。

起動応付変更はまだ試していないが,急ぐことでもないので今日はこの辺でやめておいた。

内部配線問題もありそうな気がしてきたので,今度の主力機清掃時に確認してみる。

{進捗記録}{希哲15年9月11日の開発}{将来的な}{必要なさそう}{噛み合っていない}{数MB}{数十kB}{上手く動いていた}{現行方式}{`tee -a`}...=}(83)

{希哲15年9月11日4歩 K#F85E/A-E74C-BFAF}

デルン出力録整備deln出力録保存機能調整

昨日時点では「間に合わせ」に近い感覚だったが,調整を続けてみると機能性能ともに十分なものになったため,4月デルン出力録整備作った現行方式をいったん正式採用出力録保存機能に関しては一段落とすることにした。

deln.log 肥大化問題最終的解決したといってよさそうだ。

deln_log実装将来的な選択肢の一つとして保留しておく。


昨日の時点でも概ね上手く動いていたが,一つだけ気にかかることがあった。

watchdeln.log変化観察してみると,tail切り詰める一瞬合間に,数十kBから数MBサイズ極端増えることがあった。しかも大きい方のサイズは減ることなく,微増を続けている様子だった。

以前の deln.log 肥大化問題に比べればずっと緩やかなもので,直ちに問題があるほどではなかったが,時限爆弾のような気持ち悪さがあった。

挙動からして,tail譜類置換した後も tee累積した出力再作成し続けているとしか考えられなかった。最初はバッファか何かが上手く噛み合っていないのかと思い stdbuf調整してみたが変わらず,結局,tee -a を使うことで問題解消した。

これは tee仕様なのか,もっと基本的な譜類司組司組呼応の問題なのかは分からない


まずは速度改善してみようと tail -n 1000tail -c 50kB に変えてみたりもしたが,文字交度して Bashcommand substitution: ignored null byte in input という警告を出すので止めておいた。そこまでの性能必要なさそうだ。

=}
{}{進捗記録}{論組}{デライト}{希哲15年9月10日の開発}{考えている}{動いている}{deln_log}{希哲15年9月10日の進捗時限}{希哲15年9月10日の進捗}...=}(35)

{希哲15年9月10日11歩 K#F85E/A-E74C-2FAE}

散歩中良い思いつきがあり,デルン出力録整備再開。以前仕組みは作ったものの効率上の問題が大きく無効化保留していた。

いまのところデライトそれなりに安定して動いているが,たまに壊衝しているため,やはり欲しい

segmentation fault はともかく,例外ならバッファに溜めておいた吐き出すくらいのことは出来そうだと考えていると,出力を一時的に預かっておいて deln.fcgi が落ちた時に書き出す論組があればいいことに気付いた。これを仮に deln_log としておく。

少し仕様を練って終了

=}
{新生デライト}{飛当}{デライト開発}{第四次宣伝攻勢}{宣伝攻勢}{『希哲日記』}{希哲14年}{第三次デライト市場戦略}{デライト}{見せたくない}...=}(98)

{希哲15年8月4日の日記 K#F85E/A-E74C-85D0}

新生デライト開発中の収益目標達成狙うことになり,第四次宣伝攻勢位置付け,引いてはデライト宣伝あり方について見直す必要を感じたため,今日は現状整理時間を費した

デライト高速化前の現状整理以来だが,この3ヶ月あまりの間にも数多くの出来事があり,ついこのあいだ脳爆発があったばかりなので,現在地よく分からなくなっていた。「新生デライト」というのも,そもそも何を意味していたのか忘れかけていた

第三次市場戦略以後,「新生デライト」は「理想的な完成度に達したデライト」に近い意味を持ってきた。その要件先月下旬まとまり,今月から「新生デライト開発」に入れるようになった。それも12ヶ月中の「完成」が視野に入っている。

意識の変化言葉の変化にも表れている。これまで「新生デライト宣言」という表現をよく使っていたが,これは明確な区切りのないものに「完成」の類を使うことに違和感を覚えていたことによる。「完成」が自然に使えるようになったのは,やはり要件がまとまり,新生デライト像明確になったからだ。

その完成を目指せるようになってはじめて,「新生デライト開発」という表現も出来るようになった。デライト開発新しい段階に入ったことは明らかだろう。

一方で,これまでの波状攻撃のようなデライト宣伝根底には,デライトの品質に対する不安があった。出来るだけ品質の高い状態で多くの人の目に触れるようにしたかった。逆に言えば,見せたくない状態が多々あった。それが今のデライトにも必要かというと,少なくとも明確な必要性感じていない

要するに,今のデライトはいつ誰に見せてもいいし,いつ飛当してもおかしくない。だとすれば,もう宣伝攻勢頼らずデライト宣伝日常的継続するべきかもしれない。具体的には,宣伝攻勢では1日3時間としていた宣伝時間1日30分にしてでも毎日する,といったことを考えた

いずれにせよ,新生デライトの完成まで宣伝待つことは出来ないので,新生デライト開発と宣伝は並行させざるをえない。並行させる以上,相乗効果を生むように作業優先順位などを調整していくことになる。

第四次宣伝攻勢をするかどうかは,結論を急ぐことでもないので保留とした。


からしばらくは良い調子だったが,昨年からのデライト開発駆け足振り返りCμ の公開まで考え出してしまったせいで,久しぶり分かりやすい脳疲労症状が出た夕食後には復調した)

しかし,ここで意識正しく更新出来て良かった。ぼんやりした意識のまま突き進んでいたら何かしら判断を誤っただろうし,危なかった

=}
{保留}

{}