S時計

開発日記

2026年

１
解散総選挙、開始。

自民党(維新の党付き) 対中道改革連合。

2026年2月8日に、激突する。

これから日本はどこに進むのかが問われる選挙です。

で、その物価高対策なのですが、まだ1円も無いです。笑
まったく無い。
どこに22兆円が消えたのだろう。

文字で22兆円って書くのは簡単だけど、実際は無理な金額です。
誰が払うねん、なっ、この莫大な金額を誰が払うねん。
22 000 000 000 000円。

どの政党も持続可能な経済と言うが、まったく具体的なことがない。
給料の基準となる最低賃金を3000円にするなどの具体的なものがない。

この点に関しては、石破の最低賃金1500円以上を、 2030年までに実現するとした政策が正しかったと思う。
が、これを言い出して失脚した。笑

中道改革連合の食品消費税ゼロは国民に概ね評判は良い。
が、定年廃止、週休三日は愚策中の愚策です。
格安の住居を提供するはまだ理解できるが、家賃補助は愚策です。
この考えはデフレ志向だと思う。

それよりもインフレ志向の考えを持つべきです。
給料の基準となる最低賃金を3000円にすることこそ、これからのグローバル経済で勝つ唯一の方法です。

欧米はグローバル経済だけど、日本というかアジアはローカル経済のようだ。
そのローカル経済からの脱却こそ、今、日本に求められているのです。
ちなみに欧米の最低賃金は事実上、5000円以上です。
そりゃ、日本は経済で欧米になめられるな。

ちなみに正社員の給料が最低賃金割れをしているのをよく見る。
だけど手当や会計処理でギリギリ維持はしているように見せかけている。
その手の層が損をしているのだろう。

賞与のない正社員に意味がない。そのパターンが多いよね。
あったとしても1ヶ月分など。笑
最低でも4ヶ月はないと無意味です。

はっきり言ってあるだけマシではなく、そんな1ヶ月分など要らないからベースアップの方が良いです。
良いですっていうか良かったな。笑

高市は何かに嫌気がさしたような解散だな。
22兆円の補正予算解散だからな。
誰が払うのだろう。
それとこの補正予算は評判が悪い。

このままではドンドンとタカられることになる。
特に維新との話し合いは無理筋ばっかりやん。
元々、自民党は道州制や副都心、そして議員削減に反対しているので、連立を解消したいのだと思います。
このままでは今年の年末も22兆円規模の補正予算となるだろう。

しかも何かあるたびに高市は、吉村藤田に呼び出されて説教されている。
吉村藤田が顔を真っ赤にして高市に説教している感じだ。
事実上の吉村藤田傀儡政権だったとも言えます。

このままでは、議員定数削減でネチネチを吉村藤田コンビに高市が説教される。
なぜなら議員定数削減などできないからです。
事実上の維新の党政権だった。

維新の党が薬価を高くした。
そのことを恨んでいる人は多いと思います。
削減という観点からは良いことなのかも知れませんが、病人にしては死活問題でもある。
その薬が無いと死に直面することも考えられる。

自民党に投票することは維新の党に投票することでもある。
また、維新の党に投票することは自民党に投票することになる。
歪な形の与党だからな。

自民党(維新の党付き)、自民党(維新の党付き)、自民党(維新の党付き)x5になるのか。
中道改革連合、中道改革連合、中道改革連合x5になるのか。
他の野党、他の野党、他の野党x5になるのか。
それは有権者の1票にかかっています。
激突の結果は2026年2月8日です。

整理します。
自民党(維新の党付き)、の自民党だけ勝利なら、裏金議員と不正宗教団体を認めることになる。
維新の党だけが勝利なら、吉村藤田コンビが高市をネチネチと説教できることになる。
中道改革連合が勝利なら、中道左翼よりに傾倒していく。
他党が勝利なら、いわゆる決められない政治になるか、減税になるか、不透明である。

実に楽しみです。

２
今年のおみくじは中吉だったのだけど、それが良いことが書かれまくりだった。
大吉のときよりも良いことが書かれていた。

今回は何々に注意がなく、良いことだけを書かれていた。
大吉のときは戒めとでもいうのか、少しネガティブなことも書かれていた。
けれど中吉では、そのような記述は一切なく、良いことの羅列でした。

勢いが、伸びて伸びて、伸びてx5のごとくに伸びる感じだ。
それは天にも伸びるどころか、天を越す勢いだった。

何をしても当たりまくりの当たり年なのかも。
当たって、当たって、当たりx5、の年になりそうやん。
いや、その予兆はある。
ヒシヒシと感じる吉の予兆。

今年が勝負の年なら、勝負しなくてはならない。
だって、勝ちまくりが保証されているのだからな。

いや、誰でもおみくじで中吉ぐらい引くやん。
なんでこれが自慢やねん。普通、それぐらいは誰でも引く。

自分はポジティブなのかもな。
ま、今年のおみくじは、中吉でした。
天が正しき道を示したのだと思います。

一度だけ正月に凶を引いた事がある。
そのときは速攻で、違う神社まで行っておみくじを引き直した。
するとそこでも小吉だったので、がっかりだった。

だけど、中吉と吉では、吉の方が上って話もあるみたい。
小吉と吉はどっちが上かも定かではない。

自分が今回引いたところは、大吉、中吉、吉、小吉、凶のような気がします。
中吉が以前引いた吉よりも良いことのオンパレードだったからです。

ここは神社省庁(架空)がしっかりと声明をだすべきだ。

それと夜店にある水中コイン落とし、これ外れたら、ミルクせんべいが3枚、成功すると10枚なので、絶対に外せないところだ。

はっきり言って、子供の頃に行う、
この水中コイン落としでの合否によって、人生が決まると言っても過言ではない。
ここ、勝負どころはここなのです。

３
どうしてもクラスは使うのでこれらが必要になります。

@ObservedObjectのみ。ケースによる。
@ObservedObject + シングルトン。推奨。
@StateObjectのみ。推奨。
@StateObject + シングルトン。非推奨。

@StateObject + シングルトンが非推奨なのは、 @StateObject自体がシングルトン的な要素を持っているからです。

これって一概に言えないから面倒だな。

@ObservedObject + シングルトンでクラスをインスタンス生成して、それを、 @ObservedObjectのみ、と、@StateObjectのみ、で切り分けて使うのが、正当な手法のようです。

単純に考えて、 @ObservedObjectのみなら再起動し易い、 @StateObjectのみなら再起動し難い。

で、ios18のときよりもios26になって厳格になったようだ。笑
自分の場合は、ルートで一回しか読み出さないので、それほど重要ではなかった。それが、テストチェックで、 #Preview {}、を使うために呼び出していたのでした。笑
2回呼び出しているままだったのです。
頻繁に再起動するので、なぜってなった。
が、ios18のときはそれほどでもなかったのだけどね。
正しい動作なので、なにも文句は言えません。そりゃそうだ。

//
どうしてこうなったのかを検証します。
@ObservedObject + シングルトン、だった。
安定していた。

循環参照を嫌い、@ObservedObjectのみに変更した。
循環参照を調べる時間がなかったからです。
どこで循環参照しているかを調べるのは時間がかかる。
ここでも安定していた。
なぜなら一度しか呼び出していないからです。

他のことで仕様が変更されたので、テストチェックで、#Preview {}、を使うことになるが、そこで初期化するのが邪魔くさく、ダミー的に呼び出していた。
ios18なら問題がなかったが、ios26になって厳格になったのか、頻繁に再起動することになった。
//

2回目を呼び出さなければ、 @ObservedObjectのみでも問題はない。

けれど、
@ObservedObject + シングルトン、または、
@StateObjectのみ、にすることにしました。
その方が推奨されているようです。

今回は@StateObjectのみを使うことにしました。
理由は今まで使ったことがないからです。
また、どこかで呼び出すかも知れないからね。

いや、ど忘れするやん。
一月ぐらいプログラムファイルすら開かないときもある。
他にすることがあるからな。

久しぶりに開けると手直しがあればそれで疲れる。
また、コネクトのサイトに行くと、契約でボタンを押しまくる。
簡単に言えば、マジで面倒なのです。

ルートで@ObservedObjectのみを呼び出して、あとはすべてバケツリレーで送り込む。
@ObservedObject + シングルトンでどこからでもアクセスできるようにする。
@StateObjectのみでどこからでもアクセスできるけど注意が必要ではある。

どの道、仕組みがバケツリレーにしているので、基本的に一度しか呼び出さないので、どれでも同じなのですが、たまにチェックするときに呼び出してしまい、それを(シングルトンだったのか、のみで一度だけとしているのか)忘れていることがあるので、安全性で@StateObjectのみとしました。

@ObservedObject + シングルトンの場合、そこかしこで手軽に呼び出すやん。
それで循環参照になると不味いから、@ObservedObjectのみとしたけど、これはこれで呼び出しが1度だけになるからチェックするときに手間になる。
それで、@StateObjectのみ、これが今のところ良さそう。

@StateObjectのみなら2度呼び出しても良いようだ。
だけど注意は必要です。

あとコメントを強化して、久しぶりにプログラムを見ても思い出すようにしました。
これは自分の都合ですので、別にプログラム自体の話では無い。

それと、プログラムを分散していたところを統合して、スムーズに進むようにしました。
少しでも計算が重複しないようにしました。
が、これは案外、面倒なことで、無駄でも重複させた方が、管理しやすいのだけどな。

一度、計算しているのだからその値を使いたいけど、離れたところのファイルで使うとなると、また計算かとなる。
Aファイルでルート計算を100ほどして、 Bファイルでルート計算を10する場合のその10が、すでにAファイルで計算している100の内の10だった場合、 Aファイルで計算している値を使いたいのですけど、 AファイルとBファイルが離れているときにどうするかとなる。
また、CファイルでもAファイルの100の内の20を使いたいし、 Aファイルは100の内の100を使う。

今回のアプデは、軽微な改善とパフォーマンスの強化です。
計算することを束ねました。微々たるパフォーマンスの強化ですけど、やった感はあるやん。

時計アプリは一つのエンジンですべてを動かしています。
timerにtimerを入れたり、timer、timerとするとズレる。
だからtimerは一つで、それですべてを動かしている。
RunLoopを駆使するとズレないかも知れません。
またはTaskを使う。

ま、swiftuiというかプログラムに精通していない人が、それらを使うことはあまり推奨されません。

2026/01/24