ちなみに、縦書きを仕込んだわけじゃありません（改行位置は表示環境でずれるしね）
ちなみに、縦書きを仕込んだわけじゃありません（改行位置は表示環境でずれるしね）
@japaslu ひとり仲良くやってる人がいっぱい居るね！ 平和だね！
あ、そうそう。部屋を換気しないと、酸素不足で意識が途切れるので、修羅場中のみんなは換気しようね！
修羅場って言ってもクリスマスにケンカしてる人のことじゃないよ！
@mayaeh 私の評価としては、導入しても現在の状況と大きく変わらない、という判断です。承認で良いと思います。
@Telmina 何か質問したいと思ったら、このFediverseで普通に聞けばいいよね。
お題とか切っ掛けが欲しいというのはあるかもしれないけど、その場合は、本人が関連する話をしているときにすればいいんじゃないかな。
相手がその話を聞く準備が出来ていないときに話したって、いい話は出てこないんだし。
@hanage999 @Achi そうだ、この頃のメインはperlだった！ ResEditもそうだけど、アイコンがそれぞれ印象的でいいですよね。富士山にラクダでしたっけ！
RealBasicは、現在でもXojoとして生き続けていて、我らDTP勢必携のドキュメントバージョン判別アプリ Glee、Glee Ai の開発言語として現在でも成果物を毎日使っておりますぞ！
@shinderuman 一番面白そうだったヤツをチョイス。
Go使いの悪魔！
@Achi すごい！ こんなんあったんや！ 今見ても格好良いなぁ。
@Achi 私も専門学校で触ったclassic（たぶん）が最初だったんじゃないかなー。全部GUIで面食らったのを覚えています。（それでもHyperCardぐらいは頑張った）
あの頃、何を基準にパソコンを選んだりしていたのか、記憶が曖昧で……。自作PC全盛期で、秋葉原に通ってて、いつもサンボで食べてたことしか覚えていないw
@Achi その時代は、私は職場で7500を割り当てられており、8500いいなーと眺めていた気がします。
あと、自宅用に6100を買ってもらい、いろいろいじくりまわしていたような気がするのですが、何をやっていたかいまいち覚えていない。
Think C の入門書とか、CodeWarriorとかResEditとかと闘っていたことは覚えている。Jterm + 實篤 とか ComNifty + 魔法のナイフ + NIFTY-Jぞーさん + 茄子R とか、PixelCat、まいまい、DragThing、Jedit、YooEdit などの記憶がでてきた。ということはパソコン通信全盛の頃か……。
あれ、Jeditってこの時代から使ってて、今日もDockに生き延びてるのか。すごいな……。 #dtp
This account is not set to public on notestock.
This account is not set to public on notestock.
@toco それこそガタン！ってひっくり返して、自分で傷つけたり壊したりしてしまう……。
メモリ不足の環境には良いこと何もないので、予算をそこに集中させてつめるだけ積むの大賛成ですw
@toco 27インチ！
あれデカイんだよなぁ。抱きかかえるようにしないと持てないw
デスクトップ機は、それこそ壊れるとこ限られてるし自力交換してもいけちゃうから、AppleCare入ろうと思えないですよね……。
【DTP-Mstdn.jp】
@popn_ja さんのfixで、タグTL表示から別のタグ表示に切り替えたりするとアウトな不具合、直ってます。
https://github.com/tootsuite/mastodon/issues/9548
https://github.com/kaias1jp/mastodon/commit/fd78d5b0986332aff3f0cecdeb18fe3441479455 #dtp
pyOpenSSLの問題は、昨晩発生していたので対処したところですわ。面倒くさいね!!
@toco まぁ、胴元が損をするような設定にはなってないですよねw
【DTP-Mstdn.jp】
HEAD is now at e25947db4 Sanitize and sandbox toot embeds (#9552) #dtp
@toco 実はあんまり壊れないですよねw
今回もバッテリーがヤバイレベルでへたったので交換してもらったんですが（ついでにキーボード面回りのパネルもまるごと交換）、AppleCare入ってなかったら、自分でバッテリー取り寄せて交換しちゃうので、自腹で8,000円弱ってとこです。
買い換え前のMacBook Proが3台ありますが、一台バッテリー変えただけで、他はピンピンしてるしな。毎日持ち歩いていたというのに……。
@toco 先日MacBook Proの修理で活躍してくれましたが、効果はこんな感じでした！
購入時に32,800円かかっているのでそれほどお得というワケではないですが、元をとった上でまだ1年ほど期間が残っているし、つけといて正解だったと思います。
@rk_asylum うん、とてもいい。いいものをみせてもらった。
@mayaeh agreementがboolで良ければ、このまま承認しちゃった方がいいかもしれませんね。
@mayaeh アプリのベストプラクティスを提案して了解をとりつけて、ドキュメントに明示することじゃないですかね。
「登録時の確認メッセージ」を管理設定画面に追加する、が私の案です。aboutやmoreやtermをどうこうしろって、難しくないですか？
This account is not set to public on notestock.
@mayaeh 同時に話すと、相手が二つの文脈を受け取ることになるので、一つずつの方が効果があるかも。
オレならこういう実装にするぜ！ っていうのをプルリクぶん投げて納得させる……ぐらいの技術をまず身につけねば……
@mayaeh PC向けのアプリケーションでは、インストーラーってのがありますが、基本的にアレと一緒だと思うんですよね。同意しなければいけない文書を設定すると、それに同意しないといけない。（設定してなければ同意求める画面なし）。
InstallshieldとかInnoSetupとか懐かしい……。
既存のインスタンスの説明や規約のページ（about, more, term）はこの用途に適してないので、「インスタンス登録前の確認メッセージ」を設定する項目をつくって、それを表示するようにするのが現実的なのではないかと思います。WebViewへ遷移するアンカータグぐらいはいいけど、他のHTMLは無しね。前述の通り、空なら確認なしでOK。
アプリ開発者からみても、この確認メッセージを表示するのがベストだと思えば、使ってくれると思います。少なくとも既存のあれら（前述）をどうこうする面倒くささからしたら、提供されてれば使うでしょう。
APIレベルで何か細工するとしたら、確認メッセージはinstancesから取得して、そのハッシュ値を登録APIに渡す、とかすればいいんじゃないかな。
1周年を迎えたiMastのこれまでとこれから - rinsuki's blog
https://blog.rinsuki.net/articles/imast-3-1/ #dtp
@mayaeh 利用規約ですが、ソフトウェアのライセンスと同様に、公式で、広く共有されて、公知のモノであることで実効性を担保する、いわば「Mastodonインスタンス利用ライセンス」が存在していることに対する価値というのはあるかと思います。Discourseのプライバシーポリシーを下敷きにしてるんでしたよね。
それを置き換えるものとしての「カスタム」なので、実はあれ、割と重いのではないかと思っています。
デフォルト空っぽだし、特定言語でしか書けないし、カスタムすると劣化する面がある。
代案としては「独自の利用規約」「利用規約の独自定義」を挙げておきます。
広告表示必須のTwitterで、WebUIや公式アプリを強制しなければならない事情はわかる。
Mastodonは果たしてどうか。WebUIに縛り付けるべきか。
アプリで一通りのことができるようにしたい、というのはあります。WebUIを完全に代替したい。
endorsementだってそうだし、exploreだってそうだけど、APIがないものは無くしたい。
設定項目で同期できないものが多数あって、デフォルト公開範囲とか色々面倒くさいことになっている。
reCAPTCHA導入できる（改造できる）人は、登録APIを無効にするのも簡単なので、面倒みなくてよくね？ ってのはある。
スジの悪いところとしては
「インスタンスの説明」「カスタム詳細説明」「カスタム利用規約」にHTMLが使えて、WebUIの特定の場所に表示されることを前提に利用されている、というところ。
「短いインスタンス説明」は1段落という制限があるものの、実はHTMLは書ける。
もっと広い視野で、サイトのカスタマイズ用という見方ではなく、意味に基づいた、再利用性の高い設定項目になっていないと、利用しづらい。
@mayaeh WebUIからの登録と等価とみなせるので、特にコメントすることはない、ということかなー。
アカウント作成APIの件、思ったことなど。
身勝手なアカウント作成bot（スパム）に対抗するためには、APIのレート制限とメール承認フローがあり、ここに規約の確認フローを追加しても（この観点からは）利益がない。
APIベースの規約確認フローにreCAPTCHA相当の強度（botにとっての突破の面倒くささ）を持たせる有効な技術的解決手段が提案されていない。
アカウント作成前に、ユーザーから規約への同意の明示的確認をとること。これはWebUIでもやっていないので、WebUIにも実装して一貫性を持たせる方向でプルリクした方が筋が良いかと。
行儀の良いアプリ実装と、適切なサイト設定を促す、開発者と運営者向けのドキュメントを整備する。
必要であれば、設定項目や項目の表記、補足説明、追加や削除を検討し、「この項目に何を記載すべきか」「いつ、どの項目をアプリから利用すべきか」を整理する。
一貫性という観点から、オイゲンさんからみて、WebUIとAPIは同等であるとみなされている。APIをオフにする代わりに、登録を閉じる（招待に限定する）ことができるので、それで足りると考えられる。
@Yashima そうすると、1/3が本当のアクティブ、1/3が見てるだけ、1/3がアプリ等でログインしてるけど実際はみてない、ぐらいの見立てですかね、大雑把過ぎるけど。
統計する仕組みは単純なので、あとでウチでもう少し詳しく、このへんの数字が見えてくるような仕掛けを仕込んでみようかな……
