{『希哲日記』}{}{}{}{日記}{}{}{}{}{テキスト向き}(401)

{希哲17年7月15日の日記 K#F85E/0758-279C}

激化する SNS 戦国時代の中で,サービス文化について考えさせられること多い今日ちょっと面白い発見もあった。

以前にも SNS におけるオタク文化について考えたことがあるが3月1日の日記依然としてその影響力強い感じる例えばMisskey猫耳機能などは私の価値観からすると完全にありえないものだが,そういう部分があることでオタク層からの信頼得ているはあるだろう。誰かにとっての「居心地の良さ」を提供することは SNS核心であって,Misskeyまだ小規模ながら興味深い事例ではある。

最近でいえば,Threads急速な台頭によって,キラキラした Instagram 的な対するドブ川」としての Twitter に,想像以上に多くの Twitter 用者想像以上に強い愛着持っていることが分かってきた。「陽キャ」に対する陰キャ」のコミュニティであるという意識やはり根強いようだ。それは単なる自虐というより,昔から言う明るい人気者ほどつまらない」とか「面白い奴には根暗多い」とか,その種含みがある。

確かに自分が好きだったお笑い芸人なんかを振り返ってみても,根暗ひねくれていたばかりだ。そういう人が,業界一定の地位いて妙に社交的な「明るい人」になったりして,つまらないこと笑うようになり,かつての面白さ失っていく,という哀しい現象よく見てきた

明るい人というのは箸が転んでもおかしいというなので,日常そこまでひねりの効いた刺激求めていないのだ。Twitter 用者Instagram 的SNS感じるつまらなさとは,こういうことなのだと思う

幼稚なデマ煽られやすいなど,全体としては知的脆弱さ目立つ Twitter ではあるが,役立つ投稿面白い投稿比較的多いことは認めざるをえない学問文芸も,多少ひねくれていたり,オタク気質だったりするくらいが丁度良いからだろう。その点で,Twitter 文化にはマイクロブログ型 SNS における確かな優位性がある。

そういう観点からデライト文化について考えてみたら,対 Twitter 戦略なんて無理筋じゃないかと一瞬思いかけた。というのも,デライト文化種子たる私自身が,人間の限りない可能性限りない成功対して限りなく楽天的性格であって,その実現のためにデライト開発してきたからだ。サービス名〈delight〉歓喜かけているくらいなので,そもそもデライトこの上なく明るい気分から生まれているそういう意味では,インスタグラマー真っ青キラキラ志向なのだ。

単純な話Twitter陰キャ寄りオタク寄りSNS だとして,デライトそうでないとすると,どうやって用者移行させるのかという問題があるここまでのデライト運営実感としても,Twitterはじめとするマイクロブログ型 SNS からの訪問者は,明らかにデライト文化引いている

読み込み中...
{進捗記録}{進捗}{デライト}{希哲17年4月28日の開発}{希哲17年4月28日の進捗}{希哲17年4月28日}{保たれている}{高めず}{渡配無し}{調整出来る}(121)

{希哲17年4月28日6歩 K#F85E/E74C-9EF4}

進捗時限記録中略

デライトにおける νSJavaScript渡配トランスパイルについての検討などで終了

しばらくES5 への渡配やめて様子見することにした。備立環境調整済み次回の前縁出振るい本番環境にも反映されるだろう。

希哲13年8月23日の開発以来νS では ES2015基礎にしているが,同時に Babel導入し配信スクリプトES5渡配していた。それから4年近く経ちデライトの舞覧対応方針洗練されES2015対応舞覧十分な市影有しているもはや ES5 との互換性引きずるべきではないと判断した

とりあえず--presets 応付子外してbabel --no-babelrc --minified --no-comments だけで換配するようにしてみると,ae.js譜類サイズ20kB近く減った譜類サイズ削減以上にスクリプト複雑化伴うオーバーヘッド増加抑制期待出来る

ES2016 以上交度うっかり紛れ込む紛れ込んでいる可能性考えるES2015 への渡配をしておいた方がいいかと思ったが,どうもそういう考え方をする時代でもなく,Browserslist使った手法主流らしい。確かに舞覧対応状況非常に流動的なので実態合わせる方が合理的ではあるが,ブラックボックス化避けたいこれまで通り導入付徴対応状況個別に把握しておくことにした。デライトの能力活かせるだろう。

いずれにせよ Babel の設定後からいくらでも調整出来るので,いったん渡配無し様子見する


ついでに変数名などの短縮などについても再検討したが,やはり外部通類への依存度高めず保守性維持するのは難しいため見送った交度英語おかげで一定の短縮性保たれている

{}{進捗記録}{進捗}{.zip}{希哲17年4月14日の開発}{希哲17年4月14日の進捗}{希哲17年4月14日}{含められる}{確実ではない}{移動される}(125)

{希哲17年4月14日12歩 K#F85E/E74C-3EE7}

進捗時限記録中略

設定ページ整備エクスポート機能実装

仕様検討終了

サイクリング中良い思い付きいくつかありエクスポート機能想定以上に洗練されたものになりそうだ。

読み込み中...
{十分}{}{知番}{開発記録}{WebP}{拡張子}{描写下見機能}{譜類添付機能}{cwebp}{譜類添付機能の様子}(187)

{希哲17年3月24日の開発 K#F85E/E74C-A57A}

譜類添付機能実装一段落させた出振るい手定め済み

いくつか課題残ったものの,これで譜類添付機能基礎出来た輪郭選り手領当てほぼ完成形言っていいだろう。本当努通して関連仕様検討や,中途半端だった libxtd譜類操作関連交度整備なども大きく進んだ

用合いとしては,録入り中描写選り手左下譜類添付ボタン置き譜類選択同時に上信開始完了したら埋め込み記法+[拡張子]追記下見開く開いている場合更新するというになった。すでに同拡張子添付譜類存在する場合上書きする予定通り描写内参照消し描き出し描き直しまたは輪郭削除削除されるようにした。

当初譜類選択後専用下見機能付き小窓開き確認してから送信,という用合い考えていたが,素早く描き出したい場合煩雑になり,交度複雑化見合わない可能性があるため見送った「送信中...」,「+[拡張子] を追記しました。」,「.[拡張子] で保存しました。」上書き場合3種類メッセージ@msg表示し下見関しては既存の下見機能利用すれ十分なことに気付いた描き出し前には上信せずスクリプト保持することも検討したが,これもページ遷移などへの対応考える無駄な複雑化招く可能性があるため見送った

対応形式とりあえず JPEGPNGGIFWebP のみ。WebP 以外場合長辺1920px以下WebP変換するWebP上信関してはImageMagick未対応パッケージまだ多いことなどから,1MiBサイズ上限のみで対応することにした。その他譜類サイズ上限原則として5MiBサイズ上限以外基本的に kn upl仕様合わせたが,cwebpICC プロファイル捨ててしまう問題気付いて kn upl ともども -metadata icc加えた

埋め込み記法では,拡張子のみ,知番拡張子組み合わせ加えて輪符拡張子組み合わせにも対応した

下見機能利用するために添付譜類舞覧隠し戦略見直した結局譜類更新時印から隠し破り付与出来るようにし,隠し破り有無Cache-Controlpublicno-cache切り替えられるようにした5歩これまでは一律 no-cache だった)Dex実譜類依存するのは水平拡大考えるとどうかと思ったが,そのうち KNEST 隠し化すればいいと判断した

最後の最後で,領下手定め環境問題なかった新規描出フォーム添付譜類本番環境では 404 Not Found になるという問題はまったが,これは systemdPrivateTmp による問題であることが分かり一時的に無効化してから問題無いように修正し元に戻した新規描出フォームでは無駄に永続譜類残さないように /tmp/利用していたことが原因だった。最終的に,これが大して意味を持たない設計になったので再描出フォーム同じ自我台録利用することにした。

{可能性}

{}