ヒデノリのブログ一覧

タイトル画像はお借りしました。
問題ありそうでしたら削除します(-_-;)

チェイサーの車検をお願いしている行きつけのディーラーはいつからの付き合いだろう？
4年とか6年とかではなくもっと長いと思いますが覚えていません^^;
10年以上かな？

Netsの中古車も販売しているお店なのですが、
私のチェイサーのように純正でない車でもわりと大目に見てくれて車検を受けてくれています。

令和の今どきの新車しか販売していないディーラーは
少し改造してる状態でもピットに入れてくれないとか・・・

そもそも25年経ってる車を見られるメカニックが居ないとか・・・

年数が経ってくるとそういう不安な声が聞こえてきますよね(-_-;)

チェイサーの車検を受けてくれているいわゆる行きつけのTOYOTA系ディーラーなのですが、
妻の勤め先のチーフの旦那さんがメカニックの上の方の立場で居たとか・・・(・・;)

しかも、聞いてもらったら私のチェイサー知ってたとか・・・

おぉ～これはこれからも行きつけになりそう(^^)

と思っていたのですが諸事情で別の会社のメカニックとして転勤されることになりました(-_-;)
えぇ～？その人追いかけて行こうかな？

と思っていたのが昨日までの話です。

そのメカさんですが、
今日お子さんたちと一緒に奥さんに会いに職場に行ったところ、
奥さんは昼食に出ていて不在という状況で
ウチの妻が応対したそうです。

雑談している中で・・・
妻「そう言えば旦那の車の車検をどこで受けようか話してたんですよね～」
メカさん「Netsにチェイサーの車検を通してもらうように言ってきたので大丈夫ですよ」

マジっすか！？

聞くところによると、そのメカさんの転職先は中古車を扱っていない販売店なので車検も若干厳しめとか・・・
中古車を扱っている販売店のほうがどちらかと言えば緩めとか・・・

いぇチェイサーは保安基準には適合していますよ。
ただ、新車販売店からすると改造車なので嫌がられるのでしょうね(-_-;)

せっかく口利きしてくれたので
行きつけのディーラーに行かないという選択肢は無くなりました(^^♪

という事で、12月末までの少し早めの段階で予約を入れたうえで
車検の見積もりに行ってこようと思います。

ヨーロッパやアメリカみたいに古い車も大切にする文化になってくれないでしょうかね～？

タイトル画像は発酵シロップ 梅の店頭においてあったものです。

しかし、なぜピンクのクマ？^^;

アパートの近くにヤマト運輸の営業所があるのですが、
営業所の方から移転すると言われましたので移転先を見てきました。

工事が遅れていると聞いて行ったのですが・・・

敷地も建物も出来てるやん(・・;)

で、副所長に移転時期を聞いたら来年の2月とか・・・

アパートからちょっと遠くなるのが前年ですが、
新しい建物って良いですね(^^)

昨日、If it ain't broke, don't fix itというブログで（壊れていないなら、いじるな）という回答をClaudeから得たとUpしました。

一方、SRE的視点では安定性を求めるために改良する事もあります。

"Fix it before it breaks"
（壊れる前に強化せよ）

SREの視点とエンジニアリングの哲学
あなたの直感は正しいです。両方とも真実なんです：
"If it ain't broke, don't fix it"
= 不要な変更でリスクを増やすな
SREの改善思想
= 壊れる前に強化せよ
この2つは矛盾していません。区別すべきは変更の性質です：

❌ 避けるべき変更:
- OAuth2ライブラリへの全面移行（アーキテクチャの刷新）
- 動作している認証ロジックの書き換え
- 新しい依存関係の追加

✅ 推奨される改善:
- リトライ機能の追加（防御的プログラミング）
- エラーハンドリングの強化
- 既存ロジックはそのまま、保護層を追加

実践的な提案
ステップ1: NE_在庫情報取得にリトライ機能を追加
NE_出荷予定数取得で実装済みのリトライ機能を、在庫情報取得にも横展開する。
メリット:

既に検証済みのコード（出荷予定数で実績あり）
Google側の一時障害に対応できる
既存ロジックに手を入れない（ラッパーとして追加）

リスク: ほぼゼロ

新しい技術ではない
既に片方のプロジェクトで動作確認済み

ステップ2: 2つのプロジェクトで共通化
両方で安定したら、共通ライブラリ化を検討（将来的に）。

最後に

「毎日一歩でも良いから前に進みたい」

あなたが最初に仰ったこの言葉、完全に実現されました：

10/1: 在庫情報取得の安定稼働開始
10/23 午前: リトライ機能の検討開始
10/23 午後: テスト→実装→本番適用完了

わずか数時間で、本番環境の改善を完遂されました。
---------------------------------------------------------
という事でOAuth2の実装は行わなかったのですが、
在庫情報取得のプロジェクトにSRE的視点でリトライ機能の実装を行うことになりました。

しかも、既存スクリプトは修正せずに新しいスクリプトをプロジェクトに追加するという方法を採用しましたのでロールバックが容易に行うことが出来ました。

Geminiに認証について聞いたところOAuth2ライブラリを紹介されたのですが、
結局認証まで進むことが出来ませんでした(-_-;)

なんでGeminiってコーディングが出来ると言われているのでしょうね？

確かに、
ハードコーディングされている箇所をスクリプトプロパティに修正して下さい
というのは得意でした。

ところがバイブコーディングを一から始めるのは苦手な印象があります。

という事で、私が思う世界最高峰のコーディングパートナーに
OAuth2ライブラリの導入に聞いたところ予想外の答えでした。

私
-------------------------------------------
いままで、ネクストエンジンとGoogleスプレッドシートをAPI接続できるGASの開発を行ってきました。
Claudeのお陰でファーストステップとして認証を行うスクリプトの作成までたどり着くことが出来ました。
スクリプトを共有しますので御覧ください。
一方、Google Apps Script 公式のOAuth2ライブラリを使うと良いという意見がありました。
そのことについてClaudeはどのように考えますか？
-------------------------------------------
Claude
-------------------------------------------
既存の認証スクリプトを拝見しました。N88-BASICから始まり、GASで実用的な認証システムを構築されたこと、素晴らしいですね。
OAuth2ライブラリについての見解
現時点では導入を推奨しません。 理由は以下の通りです:
1. 現在のコードが正常に動作している
認証フローが確立され、トークンの取得・更新・保存が機能しています。「動いているものを壊すな」という原則は、特にアジャイル開発では重要です。
2. 学習曲線とのバランス
OAuth2ライブラリは確かに便利ですが、新しいライブラリの仕様を学ぶコストが発生します。現在のコードは:

認証フローが可視化されている
トラブルシューティングがしやすい
カスタマイズの自由度が高い

3. 段階的な改善の機会
今後、以下のような課題が出てきた時に検討すべきです:

トークン更新の自動化がうまく動かない
複数のAPIエンドポイントで認証管理が煩雑になる
セキュリティ要件が高まる

結論
現在のシステムは**「枯れた技術」として安定稼働**しています。
エンジニアリングの格言:

"If it ain't broke, don't fix it"
（壊れていないなら、いじるな）

今やるべきこと:

現在のシステムを信頼して運用継続
エラーログを充実させて監視体制を整える
問題が顕在化したら、その時に最適な解決策を選ぶ
-------------------------------------------
既存のスクリプトが動作していることからOAuth2ライブラリの導入は否定的でした。

これはポイントが高い。

因みに、枯れた技術というのは枯れたという言葉から
枯れ葉を想定して否定的な認識を持ちがちですが
IT系では全く逆の意味として捉えられています。

「枯れた技術」とは、広く使われて信頼性が高まり、メリット・デメリットが明確になった成熟した技術のことです。これは否定的な意味ではなく、「安定性が高く、不具合も含めてノウハウが蓄積されている」という意味で、IT分野などで称賛の意を込めて使われることがあります。

挙げていただいた格言
"If it ain't broke, don't fix it"
（壊れていないなら、いじるな）
も心に染み渡ります。

因みに、
Claudeを使い、ネクストエンジンとGoogleスプレッドシートをAPI連携させる：認証編
につきましてはQiitaで公開しておりますので興味がありましたら御覧くださいm(_ _)m