ActivityPub完全に理解した

いやでもこれ公開範囲の判定にバグあるな

あとはDeleteとかに対応するだけ

ああー疲れた

返信も処理できている
おおおおお

実質AP実装完成ですこれ

うおおおおおおお
Createも処理できた!!!

時系列グチャグチャwww

みんなそうっぽいな

んー4~5分io遅延しとる

いやでもさいばれさんおるな
遅延してるけど

io遅延Botというかなんかしらんけどioから配送されない

んーなんか変だなぁ

それか超高速になったのか?

やっぱio遅延Bot壊れてね

右シフト封印するか

括弧を入力しようとした時に'を入力してしまう病気にかかっています

node_modulesが消せないってそういう

出来たわ

「関数を指定のスコープに抽出」 引数の制御がよくわからん

IDEのリファクタリング機能を使いこなせない

https://blog.nicovideo.jp/niconews/193884.html?ref=videotop_info

サポート終了対象OS Android 4.4 iOS 10

io遅延Bot壊れた?

もういいや循環参照なんて知らね

ゴリ押しで実装してやれ

このアカウントは、notestockで公開設定になっていません。

やべ ふろはいるか

Misskey、Zen UIでおかえりなさいでなくていい

https://twitter.com/IFULL_TAKEHARA/status/1660933707908145155

竹原駅前商店街ももねこ様カメラ 投稿時刻は2023-05-23_18:00です。 #あいふる316 Auto tweets from Ubuntu MOMOCAM.

Glazeはかなり画質悪化するので絵を描いてる人からすると結構厳しいものだと思うんだけどどうなんだろ

画像の保存難易度あげたところで無駄だとは思う

原神は最初らへんが一番楽しい

原神1からやり直したい

このアカウントは、notestockで公開設定になっていません。

DHCPっていっぱいあったら喧嘩しないの?

やる気が出ねぇ

今日一日無駄にした

あ、Javaの誕生日なんですね今日

ベータ版に対応してるの

Twitterのリストは死んでるけどリストの中から検索してるやつは動いているので謎

☑ 右左の話ではない

んーヘッドホンにも向き不向きあるなぁ

やる気 出し方 検索

JavaからPython呼ぶ方法考えるよりPythonで一から作ったほうが早いな

腹の調子が悪いな

ボケニャス ← かわいい

このアカウントは、notestockで公開設定になっていません。

💩 ← ack

G502はでかいので邪魔だぞ

https://www.techno-edge.net/article/2023/05/23/1323.html

Twitterは広報部門を解散しており、今回の問題に対するメディアからの問い合わせのメールにも、いつものように”💩”の絵文字を自動返信しています。

このアカウントは、notestockで公開設定になっていません。

jarはただのZipなので頑張ったら自己解凍形式として実行可能…?

このアカウントは、notestockで公開設定になっていません。

このアカウントは、notestockで公開設定になっていません。

C#遅いっていうイメージが～って別にC#速くないだろ
Javaもそうだけど限界がある

なんかC#推しが多い

C++製のMisskey(すぐ死ぬ)

Ktorで作ろう

型ガッチガチでいいですよ

(Spring Frameworkで作らない? Misskey)

Rustのいいところ全然知らんのでただの寝言です

Rustにしようよ～

実験段階じゃん 解散

gomobileなるものがあるのか

このアカウントは、notestockで公開設定になっていません。

GoでAndroidとか聞いたこと無い

MisskeyにMastodonのAPIを生やす ← ある
MastodonにMisskeyのAPIを生やす ← ?

よく考えたらなんとかならないことに気づいたのでなんとかなりません。

リンクだけ置いとけばなんとかなる

とりあえず循環参照問題をいい感じに解決するまで返信とかは手動でなんとかしてもらおう

お昼食べるか

あやべ

このアカウントは、notestockで公開設定になっていません。

Misskeyは結局Golangでやるのかな?

このアカウントは、notestockで公開設定になっていません。

かなりまともな設計のライブラリで助かってる
めっちゃ拡張性高い

KJob改造して使ってる

MongoDB用のジョブキューをとりあえずRDBでも使えるようにしたやつを使ってるので

DBへの負荷考え始めるとジョブキューなんとかしないといけない

お一人様向けと割り切ってDBへの負荷は考えない

解決策: とりあえずIDだけDBに保存して重複を発見出来るようにする。あとは普通の再帰で何とかする。

まぁ引用もリプライも参照してるのには変わりないからいいか

テスト

RE: https://misskey.usbharu.dev/notes/9f3b9hrtf8

Fedibirdだとどうなるんだ

現在は投稿は投稿、ユーザーはユーザーで別れています。

APのリソースを取得するクラスを作る必要があるか
これなら比較的簡単になんとか出来る気がする

再帰的している回数をそもそも保持できない構造が悪い気がするので全体的に見直すか…

んー難しい
何もわからん

@kussy_tessy@fedibird.com 既に存在しているノートかのチェックなどが簡単にできたら実現できます。毎回DBに問い合わせることになってそれこそ自滅しかねないので難しい感じです。

やっぱ参照先の投稿とかは最低限必要な分を読んで必要になったらもう一回取得するほうがいいのかな

何が大変ってくっしーさんも言ってたけどただのリプライツリーを参照が多すぎるつって捨ててしまう可能性がある

@kussy_tessy@fedibird.com でもこの例だと途中でDBなどに保存したら重複を発見できるので例として適切じゃなかったですね…。

@kussy_tessy@fedibird.com パッと思いつくのはこれなんですが色々な方法で循環参照してしまうので難しいです。

例えば 投稿 → メンション → メンション先固定ノート → 最初の投稿 とかで循環参照してしまうとカウントするのが困難になります。

これ固定ノート取得ってMastodonと同じ解釈をした結果なので普通にoutboxに全部の投稿があったら余裕で死ねる

んんんんn

しかし大量にメンションとかされるとdosが発生するのでマジでめんどくさい。

(メンション→メンション先のユーザー取得→固定ノート取得→そこから参照先のノート等取得)

あとは昨日言ったみたいに参照先は更に参照が発生しない部分だけ読むとか

再帰的に取得していくのでリミットとかそういうの使ったら行けそうではある。

APで循環参照するノート飛んできたらどうしたらいいのか問題

https://ja.wikipedia.org/wiki/%E7%84%A1%E9%99%90%E3%83%AB%E3%83%BC%E3%83%97

無限ループは、通常、プログラマが原因を突き止めることができると簡単に考える者もいる[要出典]ようだが、次のような例を考えればそうでないことがわかる（簡単のため、数値は無限に大きな値を扱えるものとする）。

IFTTTに課金できる余裕はないのでいい感じの解決策を見つけるまで停止です。

そういえば @illust 停止しましたね

DP接続にしてるけどめんどくさいからHDMIにもどそうかな

タブレットの充電がねぇ

コレクションとかでなりがち

起こるときは起こる

そもそも再帰作られたらスタックオーバーフロー発生するところだったのでそれがなくなっただけマシ(後回しにしたとも言う)

​​

流石に時間やばいので寝ます

これで一度取得されているNoteをもう一回取得してしまうことはなくなるので循環参照が発生するだけでなんとかなる(なんとか出来るかは別)

Note取得を工夫して最低限必要な分をDBに保存してから追加情報を取得するようにするか

え、マジでどうしよう

APで再帰作られたら詰むんだが…

いや今も無理だが

テストコード書いてから組めるほど作り始めたときの僕はAPにもSNSにも詳しくなかった…

コントローラーか
まぁいいや

PostPostPostService
(投稿を投稿するエンドポイントのPOSTメソッドのサービス)

ここ数日でAPI生やしてテスト書いてフォローできるようにしてる。投稿の取得を今作っているけど若干デカ目のクラスが出来始めていて限界が近い

大急ぎで実装を進めた結果コードがエライことになってるのでリファクタリングする必要がある

https://twitter.com/hpeo_jp/status/1660556360059351045

情報処理技術者試験に申し込んだだけで受験しなかった方々の受験料総額（令和4年度）：約8億円 この善意の寄付のおかげで、高品質な試験を低価格で受験できています。みなさん感謝しましょう。

Misskeyでも話出てましたね

Noteにセンシティブフラグ追加するだけなのに手が動かない

まだ寝ません

もうこんな時間

Misskeyでだべって思考整理するの辞めたい

DBで配列型を使わざるを得なくなる理由

よっぽどの理由がない限り使いませんが…

一々中間テーブル作るのだるくて配列型使いたくなってくる

コード変えたのにテスト通るときってだいたいテストがダメ(2回目)

ん Rustで書く話かな?

自衛隊の「資材運搬車」など各種車両をウクライナに供与（JSF） - 個人 - Yahoo!ニュース
https://news.yahoo.co.jp/byline/obiekt/20230522-00350515

まぁでもこれ手を抜く言い訳でもあるのでなんとかしたい部分もある

逆にドキュメントとかはある程度人のためにやっている部分があるので辛い

僕はそもそも自分が使いたいものを作るためにプログラミングとか電子工作とか3DCGとかやってるのでそこは問題ではない

翻訳とか設定ファイルは何回かありがとう言われてるけどプログラミングは多分無いなぁ

電子工作は自分用しか作ってないし

自分が作ったものを人に使ってもらったこと多分無い

辛辣ですね… まぁその通りなんですが

Createは今のところNoteだけでいいのか

いや普通に開発用なので…

じゃぁORM改造していい感じにマイグレーションして貰う必要がある

鍵だけエクスポートしてインポートできる機能が必要

リプライの仕様めんどくさいな テーブル構造変わるわこれ

toが未収載とかホーム投稿とかの判断に使われる公開範囲、ccが見る権限的な公開範囲か

toとかccとかわからんぞ…

まぁMFMに対応するわけ無いので無視しますが…