疑問や調査予定の課題。
{希哲17年8月13日の日記 K#F85E/0758-52A8}
宇田川浩行{希哲17年8月4日の日記 K#F85E/0758-9D54}
宇田川浩行{希哲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年5月3日の開発 K#F85E/E74C-5BB8}
宇田川浩行一つ一つ課題を解決しながら進めているので時間はかかっているが,何かと知見を深めることが出来ている。やはり総合的に CSS アイコンの利点は大きいので採用方針は変わらないが,割り切りと誤魔化しの技術が肝だなと感じている。そこを抑えられれば強力な武器になる。
CSS アイコンの欠点として,拡縮時に歪みやすいということが理解出来てきた。スマートフォンだと再現しないので,サブピクセルのレンダリング問題なのかもしれない。拡大時に1px程度のずれが生じることがあるのはともかく,縮小時に細い線が消えたりもする。これは有名な CSS アイコン集でも同様なので,そういうものなのだろう。
もっとも,ラスター画像の主要な問題である高精細画面でのぼやけに対応出来れば十分とも言える。舞覧のズーム機能を使うような人にとって多少の表示の乱れは想定内だろう。あとは歪みにくい書き方・デザインの問題か。
すぐに終わるだろうという当初想定に反してもう少し時間がかかりそうなので,明日からは別の作業にも多めに時間を割くことにした。
{希哲17年4月16日6歩 K#F85E/E74C-0FC3}
宇田川浩行インポート機能仕様検討,エクスポート機能の CSV 対応検討で終了。
待欄の閲覧性(迷惑行為対策)や時印指定がある場合の扱いが課題となってインポート機能実装の見通しは立っていなかったが,前者は未公開状態を使うこと,後者は編注記法で末尾に追記すること(実際の時印はインポート時のものになる)を思い付き,一気に実装イメージが固まってきた。どちらの課題も待欄がある KNS 特有のものだった。
輪数上限はエクスポート機能同様10,000輪,サイズ上限は譜類添付機能同様 5MiB の CSV が適当だろう。
これに合わせてエクスポート機能でも早期の CSV 対応を決めた。oln.csv
を ZIP 書庫化することになるだろう。
インポート・エクスポート機能の対応形式は輪郭譜類と CSV で当面は十分そうだ。あれもこれもと考え出すとキリがない。
pdftoppm
}{譜類添付機能調整}{譜類添付機能}(116){希哲17年4月5日の開発 K#F85E/E74C-3148}
宇田川浩行譜類添付機能調整など。
細かい挙動の調整を終えてから PDF 埋め込み対応を完了,譜類添付機能も全体として完成形と言える状態になり,ようやくエクスポート機能実装に移れる。
3月24日の開発時点では,添付ボタンと埋め込み記法でラスター画像(JPEG, PNG, GIF, WebP)が扱える程度で機能実装の一段落としたが,SVG,動画,音声までの埋め込み含めての対応,その他主要文書譜類対応,添付代置子の導入,貼り付け・ドロップ対応,更に PDF 埋め込み対応と,現時点でやりたいことは一通りやってしまった。一段落とは言ったものの,中途半端感が残りいまいちすっきりせず,デライト公式での機能紹介も出来ていなかった。
PDF 埋め込み対応に関しては,PDF.js と pdftoppm
が優秀だったおかげで意外とあっさり実装出来た。特に PDF.js は viewer.html
の場筋と PDF 譜類の場筋を組み合わせて <iframe>
の src
属性に渡せばいいだけで,スクリプト側の対応も簡単だった。
最初のページを pdftoppm
で JPEG に,cwebp
で WebP に変換,その画像をクリックで縦サイズを合わせた <iframe>
に置換し viewer.html
を読み込む。読み込み中の進捗表示も viewer.html
が行ってくれるので,これだけで違和感なく軽快な PDF 埋め込みが実現出来た。一応,「(.pdf
添付ファイル)」の形で小書き輪結も添えるようにしておいた(PDF 埋め込みの様子)。
一つ,添付譜類の握接権限の課題は残した。現状,場筋が分かっていれば誰でも握接出来るが,デライトの性質上大きな問題ではない。エクスポート機能で譜類の握接制御を実装するのでそれを応用することにした。
rgba( 255, 255, 255, .5 )
}(62){希哲17年4月1日8歩 K#F85E/E74C-6494}
宇田川浩行- 舞覧によっては横スクロールバーが内容に被ってしまうため
<pre.cd>
に設定していたpadding: .5em
を削除,<code>
にpadding: 1em .5em
を設定した。 - 交度写し取りボタンも被り過ぎていた上に若干不調和だったため,
<pre.cd>
の境界との間隔4pxを2pxに縮め,円の背景色をWhiteSmoke
からrgba( 255, 255, 255, .5 )
へと変更した。 - highlight.js の処理中にがたつきが発生していたが,これは
<code>
のdisplay
変更によるものだったため,予めdisplay: block
を設定しておいた。 - 現状の折り返し無しを折り返し有りにするか検討していたが,これは現状維持とすることにした。