フィルタをつけて、スマホがこのくらいの大きさに写る
フィルタをつけて、スマホがこのくらいの大きさに写る
MC-21と合わないレンズ6本を処分した。代わりに何を買うか迷う…。本命は105mmぼけマスターだが、Lマウントで出るの12月だしなあ…。
This account is not set to public on notestock.
いくつ増えるかわからん、どんな改造されてるかわからん、間に何が挟まってるかわからんサービスのAPIエラー応答を分かりやすい表記に置き換えるとか無理だしサポート負荷が増えて俺が苦しむ害悪でしかない。STは赤字アプリなんだから、手抜きするために全力を尽くす所存
APIレスポンスのエラー表示、STではアプリ作者への問い合わせを減らすために、例え素人に意味が通じなかろうが全部見せる方針。JSONならerror項目を見るし、HTMLなら色々処理してテキスト化する。全く綺麗なコードではない。しかしそれが現実というものだ
APIの互換性を保ったまま、既存のデータがあればそれを返すようにするだけ。なのでサーバ側でできることだよ。
ユーザが管理できるUIがあるのはアプリとの連携であって、アプリ自体ではない。アプリ自体の登録情報は認証ユーザから行われる訳ではない。アプリの登録情報は投稿から参照されるのでそもそも削除できない。アプリの登録情報にはプライベートな要素は特にないが、なぜか今は内容が同じアプリをクライアントが個別に登録してサーバは個別にsecretを発行している。
スコープ、名前、コールバックURLなどの内容が同じならアプリの登録情報をみなで再利用するべき。
数日前にパジャマ3セット新調した。今どきは通販で高機能なパジャマ買えて良い
@u1_liquid DB的に最適な変更は、アプリテーブルにスコープ、名前、コールバックURLなどが同じデータがあれば、新規作成するかわりにそのデータを返す、だと思います。クライアント情報は更新も削除されないなら、再利用しても構わないはず。もし更新APIがあっても少なくともSTは使ってない
@tahnyadesign 歴史的な理由で、アプリ内で完結してる単語ミュート（選択してコピーから追加）と、サーバに保存するキーワードフィルター（カラムから追加可能）の二種類があります。
@u1_liquid Via芸があるからアプリ登録はクライアント側。なお、前回登録したアプリがまだ使えてアプリ名とスコープが同じなら再利用する程度はしている。そして全ての投稿がアプリを参照するため、アプリ登録を削除することは考えられていない。これはサービス側の問題。
