もっと見る

もっとこうしたらいいんじゃね? という、仕組みの改善を考えるのが好きで、実際に実行して結果を確かめるのも好きで、それを趣味にしたり仕事にしていたりする。

思い通りにいくこともあるし、見立て(前提の捉え方)が間違っていることに気付くこともあるし、よりシンプルな解法があったのに複雑にしすぎて失敗したり、運用が負担になる持続性のない不自然な形を作ってしまうこともある。

なるべく苦労せずに済むように答えを探すのは勿論だが、上手くいかなかった時が一番力を試されるし、血肉になる。

プログラミングはこうした目的には非常に適していて、それを知った時からこれまでずっと興味が尽きないし、それゆえに勝手に身につけてきた。

なにより、低コストで素早く沢山失敗できるのが良い。また、一人でやれる範囲が広い。さらに、同じように取り組む仲間が沢山いて、技術を共有する文化があり、容赦ない欠点の指摘をポジティブに受け入れる希な世界でもある。

自分の生まれた時代に発展した新しい分野で非常に幸運と言うしかない。

よし、BASEから注文だ。
シマダ農園他、注文いれるよー!
@nelsoncoffeeroaster

なんかこう、音楽が延々と頭のなかに流れ続けてとまらないヤツあるじゃないですか。言葉とか概念もまた、延々と繰り返したりするんですよね。

最近、バーチャルユーチュー鳩 ダヴ沢の「これをみろよ」ってタイトルが自分の中でジワジワと評価を上げていて、そうだよなぁ、我々がMastodonで画像をアップしたりエピソードを紹介したりするのって、もう「これをみろよ」以外の何モノでもないよなぁ。なんでこんなにぴったりくる言葉を選べるんだろう。などとぐるぐると頭の中で反芻している。素晴らしいタイトルです。何か、人の業を一言であわらしたような……(以下、ずっとループ)

【鯖缶向け】Rakeタスクを活用しよう 

Mastodonの管理に便利なツールが用意されています。一覧はこちら。
github.com/tootsuite/documenta

Mastodonユーザーで、Mastodonが配置されているディレクトリ(変更していなければ ~/live )に移動し、

RAILS_ENV=production bundle exec rake タスク名

で実行します。

オプションを指定するものもあります。

たとえば、外部のインスタンスから取得したメディアファイルを削除するタスクは、何日前のものを削除するかを指定する NUM_DAYS というオプションがあり、指定しないと7日前となります。これを14日前にするには、

NUM_DAYS=14 RAILS_ENV=production bundle exec rake mastodon:media:remove_remote

と指定します。

注意点として、多くのタスクが、Mastodon本体と同様に、Workerを通じて非同期に実行されるようになっています。即座に結果が反映されないのでご注意ください。

【鯖缶向け】Rakeタスクを活用しよう 

Mastodonの管理に便利な、ちょっとしたツールが用意されています。一覧はこちら。
github.com/tootsuite/documenta

Mastodonユーザーで、Mastodonが配置されているディレクトリ(変更していなければ ~/live )に移動し、

RAILS_ENV=production bundle exec rake タスク名

で実行します。

オプションを指定するものもあります。

たとえば、外部のインスタンスから取得したメディアファイルを削除するタスクは、何日前のものを削除するかを指定する NUM_DAYS というオプションがあり、指定しないと7日前となります。これを14日前にするには、

NUM_DAYS=14 RAILS_ENV=production bundle exec rake mastodon:media:remove_remote

と指定します。

注意点として、多くのタスクが、Mastodon本体と同様に、Workerを通じて非同期に実行されるようになっています。即座に結果が反映されないのでご注意ください。

ハチウエかと思ったw
ハウリングチェックか……。

relayの裏でwakinさんのsimple_apをずっといじってる。

なんか例外吐いてるっぽいところがあるんだけど、どうデバッグしていいかわからない。Pythonも頑張らねば……。

やっぱり銀河丼をリレーに引き込まなあかん。もっと環境を整備しておかねば……。

Typekitの本当の凄さは、本家とはライセンス(許諾範囲)が異なることかな。

……DTP勢の詳しい人を呼んでこないと説明できないけどw

見づらいとこ書き直したくなるけど、やめておこうw

Mastodonの管理画面、超格好良いダッシュボードが追加されましたね。なんでいままでなかったんだコレ……w

自分でリレーサーバのコードを書いたみたいな実装の説明をしましたが、単に読んで説明しただけです。読み違えていたらご容赦ください。

このあたりを踏まえておくと、リレーってどうよ、という話をする際に、実装を知らずに話すより生産的な議論ができるのではないかと思います。

dtp-mstdn.jp/@noellabo/1003801

リレーサーバの実装の話。

現在のリレーサーバ実装(pub-relay)は、登録インスタンスのリスト(ドメインとinboxのアドレス)と、登録を拒否(ブロック)するドメインのリストだけをデータベースに持っています。

relay@リレーサーバ というアカウントが直接生えているので、各インスタンスはこれとやりとりしています。

登録インスタンスがrelayのinboxに投稿を投げてよこしたら、全登録インスタンスのinboxにそれを投げ直します(パススルー)。

relayへのフォローリクエストの体で、リレーに登録し、フォロー取り消しで削除。

sidekiqでProcessWorkerとDeliverWorkerが走っていて、ProcessWorkerがrelayに対するリクエストの処理、DeliverWorkerが各インスタンスへトゥートを配信する処理を行います。

sidekiqのキューはdefaultのみ、リトライは行いません。

登録インスタンス一覧と、ブロックの登録・削除を行う、シンプルなコマンドラインツールがついています。

実に美しく読みやすい。
※個人の感想です

リレー、動かしてみて良いところをみつけたり、問題点をあぶり出したりする段階なので、たくさん話題になるといいな。

箕面どんの鯖缶 @toneji さんが、v2.4.3にリレーの機能だけをcherry-pickして動かし始めました。

relay.dtp-mstdn.jp をリレーに登録し、参加いただいています。こちらは現在11のインスタンスが登録しています。

@h3zjp@m.xn--fiqwix98h.jp によると、現在下記のリレーが観測されているようです。
m.中二病.jp/@h3zjp/10037936058685

※ リレーはオプション機能で、全文検索機能のように、Mastodonに必ず必要なものではありません。また、まだ最初の実装が提供されて日の浅い、極めて実験的なものです。皆さんに積極的におすすめするものではありません。

いち早く体験し、どういうものが導入されようとしているのか、自ら確認してみたい!という人はやってみてもいいんじゃないかな、という程度です。

※ もともとがオプションということもあり、導入しても具合が悪ければすぐにリレー登録を止められるので、過度な心配は不要です。

※ cherry-pick:自分の気に入ったものだけをつまみ食いする、の意。gitで、特定の変更だけを取り入れるときに使う機能

migrateは、データベースに変更が必要な箇所をソースコードから見つけ出して、追加・変更のためのマイグレーションコード(rubyのプログラム)を生成します。

生成したmigrate用のコードは~/live/db/migrate/ に増えていきます。ここをチェックすると、データベースにいつどのような変更をしてきたのか、履歴がたどれます。

生成したコードを実行して、データベースに実際の変更を行います。

このコード生成と実行を行うのが、いつもやっている
RAILS_ENV=production bundle exec rails db:migrate
です。

(まれにmigrateに失敗して、アップデートが立ち往生することがあります。そのときに、問題を起こしているファイルを削除てやりなおしたり、コードに手を入れる場合があります)

Mastodon本体のプログラムは開発者達が修正してくれますが、自分のインスタンスの状態は自分で面倒をみなければならないので、覚えておきましょう!

@toneji

ここんとこマジメなことばかり言っていたから、少しくだらないことをいって中和せねば(いらない

@Cutls さんが違う世界線に生きているっぽくて……ゾクゾクする(ちがう

もっと見る

のえる :cava_red: DTP鯖管 によるおすすめ:

DTP-Mstdn.jp

DTP-Mstdn.jpは、DTP・デザイン・印刷に関わる人々のためのMastodonインスタンスです。特定分野の専門インスタンスですので、日々のつぶやき、耳寄りな情報の共有、ディスカッション、質問とその回答、役立つスクリプトなど、他では投稿しづらい内容も、思う存分トゥートしましょう!