ちょっと頑張ってはみたが、やはりRetrofitで適当にinterface書いちゃうほうが末端のアプリ開発者としては楽なのではという気持ちは出てしまうな
ボンクラプログラマー
頭とお腹が弱い。
最近は個人鯖の @shibafu528 がメインです。
⚠️ CW設定のない下品な発言が非常に多いです。これは仕様ですのでご了承下さい。
ℹ️ spam対策でフォロー承認制にしています。上の一文が構わないという方ならお気軽にどうぞ。
FINAL FANTASY XIV 関連の著作物は
(C) SQUARE ENIX CO., LTD. All Rights Reserved.
ちょっと頑張ってはみたが、やはりRetrofitで適当にinterface書いちゃうほうが末端のアプリ開発者としては楽なのではという気持ちは出てしまうな
yanzmさんのAndroid 13のLT聞いてる
通知にruntime permission要求必要なのか……iOSかな?
通知にruntime permissionを要求するの、ユーザーとしては能動的に通知を潰すチャンスが発生するので良いけど、開発としては全てが面倒だな
正しい設定からエクスポートされたデータは正しいが、一度インポートして壊れたらそれをエクスポートしたものは壊れているわけで
あの時の俺がもうちょっと賢いか、あるいはJSONを選ばなければ回避できたかもしれない。今いってもしゃあない。
2016年からのバグ
設定JSONからのインポート時、数値データは可能な限りLongとしてパースされるようにする by shibafu528 · Pull Request #305 · shibafu528/Yukari
https://github.com/shibafu528/Yukari/pull/305
何が悲惨って、こんなバグ社会に出てから書いたコードで埋め込むなやってこともそうだけど、YukariがAndroid 2.3を切る直前に機種変のために作った機能だっつーのに、最初から壊れていたことですよ
health checkにだけ応答してrecpt1の子守を放棄して家庭崩壊してるmirakc初めて見た
journalctl -n 100 してヘルスチェックログしかなかったらアラートを飛ばすのもアリな気がしてきたな
今は毎朝6時に直近24時間に1本もTSファイルが増えてなかったらメールが飛んでくる (が、録画スケジュールを覚えてないので1日くらいスルーしがちあ)
でもこれすらもておくれる宿命にあるんだよな。だって金曜8時から障害起こしてたら、大抵金曜6時以降の録画はないとして最速で土曜6時にメールだし… 金夜を落としてる
mirakcのログは何もしてなくてもEPGコレクターのログがあるから動いているはずである、という仮定はたぶん上手く行く
まあ分かっている奴が"やっている"一方、こういう時の殴り方を分かっている人もいるだろうからそんなに不安は無いのですが
今のGradle、incremental annotation processingとかいうのあるのか。y4aのコード生成に使ってるプロジェクトでwarnが出た。
入出力 1:n関係でコード生成を行うプロセッサはisolated processorとしてマークできて、それによって高速化できるのか
何が変化したら注釈処理を再実行しなければいけないかが分かるから、それで枝刈りしてるんか
yukari-processorだと自作ORMとジョブキュージェネレーターはisolatedでマークできそうだな
HTMLのHTの部分を100回読み直しても文書じゃなくてアプリのGUI定義言語として使うのやっぱり商業的都合で狂っているのでは
そうかな、そうはいってもレンダリングの過程のパイプラインは文書レイアウトシステムじゃん。
文書レイアウトシステムとしてのあらゆる要素をバイパスしてアプリのGUIをレンダリングしたら、原理主義者とHTMLの上に乗っていたがために利益を得ていた人は色々な課題を指摘してキレるかもしれないけど俺は別にそれでいいかな
朝叩き起こされて受け取った荷物確認したら、キズナアイのラストライブのCFのリターンだった
あwかwりwっwてwきwたwww(おどる紲星あかりBB) - ニコニコ動画
https://www.nicovideo.jp/watch/sm40465376
Yukari Next 3.1.2.2267 (mirage 220515 e6aec87)/exvoice arm64-v8a(May 3 2022 12:44:30)/Google/Pixel 5a/12
ブックマークだけは直せそうで実装投入したけど、他にも影響してそうだな〜みたいな (そうなるともはや無理めなテーブルもありそうだけど)
本日はスタジオに露出評論家であり思考露出狂である @giraffe_beer さんにお越しいただきました。
ンwww y4aからTwitterの /api/1.1/help/configuration を未だに起動するたびに呼んでたわ
GET /1.1/help/configuration.json APIの廃止対応 · Issue #306 · shibafu528/Yukari
https://github.com/shibafu528/Yukari/issues/306
文字数判定とかやるためにサービスごとに実装書いてあるバリデーターに機能足せば、対応Mastodonサーバで添付可能枚数を5枚以上にするとかやれるけど、俺自身はバニラな鯖でやってるのでスルーで……
サービス x アカウントの掛け合わせでそれぞれ異なる判定基準で応答する……みたいな実装も可能な仕組みではあるが、なんかこう拡張性がある場所に限って特に拡張する予定がないね
ふとy4aのコードを見たらJobIntentServiceに打ち消し線が引かれており、ギエーーわざわざ対応したのにとなって軽く目を通している
How To Migrate The Deprecated JobIntentService | by Yanneck Reiß | Tech Takeaways | Medium
https://medium.com/tech-takeaways/how-to-migrate-the-deprecated-jobintentservice-a0071a7957ed
まあIntentServiceがオワコン化していた時点で移行すべきだったのだろうが…
WorkManager、いい加減学ぶか……このAPIもう相当前に追加されたはずなのになぜ今まで俺は
IntentServiceからWorkManagerへの移行できるのかを考えてみたんだが、y4aは様々なロジックがバインドしたサービスとのIPCで実行されるので、Androidコンポーネントと切り離された世界観でジョブを実装するWorkManagerへの移行は容易じゃない気がするぞ
あれ初見の人本当にギョッとする実装だと思うんですよね、今の俺も実質他人なのでだいぶギョッとする
実際にはSingletonをApplicationContextに持たせるとかそういう雑でも良かったんじゃないかと思われます
たぶんy4aで引き続きServiceとして実装されていても良いのはストリーミング処理とかその辺であって、アプリケーションの大半から参照するSQLiteコネクションとかシングルトンとかの初期化ではないんだよな
これリファクタリングできたらもうYukari 4でいいだろ
TwitterService.javaの廃止 · Issue #307 · shibafu528/Yukari
https://github.com/shibafu528/Yukari/issues/307
* 設定インポートでデータベースが破損することがある重大なバグを修正
* プライマリアカウントによって受信アカウントが上書きされたトゥートに対してふぁぼ等の操作ができなくなるバグを修正
* ブックマーク修復が常に全てエラーで終わるバグを修正
* 多くの依存ライブラリを更新
デプゲ: https://dply.me/d7i2s6
リリースノート: https://github.com/shibafu528/Yukari/wiki/Release-Notes
あれ今実装するんだったらメモ機能とかそういう名前にするんだけど、TwitterとMastodonが機能名かぶらせてきたのが悪い
OpenCommで適当に配信聞きながら作業するのやってみて、1時間以上普通に行けたのでこれは行けそうやな
STの簡易投稿欄の左のボタン押したときに出るやつ、どんなViewなのかと思ったらシンプルにDialogだったので、こういう使い方できるのか!と目から鱗
このアカウントは、notestockで公開設定になっていません。