gon｜エンジニア／テクノスタンダード代表

'happy.py'.rstrip('.py') が 'happy' ではなく 'ha' を返しました。 手元の検証(Python 3.13)では、rstrip の引数は接尾辞ではなく文字の集合として扱われ、'.' 'p' 'y' のどれかが末尾に続く限り削られました。 拡張子を外したいときは、3.9以降なら removesuffix('.py') を使うと、'happy.py' から 'happy' が得られました。 #Python #バグ予防 #バックエンド

def add(x, acc=[]) を3回呼ぶと、毎回新しいリストが返りそうに見えて、3回とも同じリストでした。 手元の検証(Python 3.13)では、デフォルト値は関数定義時に1度だけ作られ、呼び出し後の add.__defaults__ は ([1, 2, 3],) に書き換わっていました。 acc=None にして関数内で [] を作る形に変えると、結果は [1] [2] [3] になりました。空リストをデフォルト値のまま使う案は、共有される理由が読み取りにくいので採りません。 #Python #バックエンド #コードレビュー

json.dumps のデフォルトだと、ログの日本語が \u6771\u4eac のようにエスケープされて出力され、grep で探せません。 手元の検証(Python 3.13)では、ensure_ascii=False にすると、このサンプル(日本語の短い辞書)は138バイトから81バイトになりました。loads した結果は両方とも同一でした。 ただし、ログ基盤が UTF-8 前提でない場合は True のほうが安全なので、基盤の文字コードを確認してから切り替えます。 #Python #ログ設計 #バックエンド

Pythonで round(2.5) が 3 ではなく 2 になりました。 手元の検証(Python 3.13)では、round(0.5)、round(1.5)、round(2.5)、round(3.5) は 0, 2, 2, 4 を返し、組み込みの round は偶数丸め(銀行丸め)でした。 round(2.675, 2) も、浮動小数点の表現誤差で 2.68 ではなく 2.67 です。 金額計算で四捨五入が必要なら、Decimal と ROUND_HALF_UP を使うと 2.68 が返りました。 #Python #プログラミング #バグ

SQLiteで WHERE id NOT IN (SELECT a_id FROM b) が0件になりました。 手元の検証(SQLite 3.53.1)では、サブクエリ側の a_id に NULL が1行混ざっているだけで、NOT IN は条件が真にならず、本来残るはずの行も全て消えます。 NOT EXISTS に書き換えるか、サブクエリに WHERE a_id IS NOT NULL を足すと、期待どおり2件が返りました。 NULLを許す列に対する NOT IN は、結果が変わっても気づきにくいので注意しています。 #SQLite #SQL #データベース

障害の振り返りでは、原因の説明より先に「発生から気づくまでにかかった時間」を書くようにしています。 原因が分かっても、気づくのが遅ければ被害は広がります。検知までの時間を先に見ると、直すべきなのが修正なのか監視なのかが分かれやすくなります。 #システム開発 #障害対応 #振り返り

機能の検討では、採用した案だけでなく「やらないと決めたこと」も理由と一緒に残すようにしています。 数か月後に同じ提案が出たとき、経緯を調べ直す時間が省けます。判断の記録は、決めた内容より外した内容のほうが後で役に立つことが多いです。 #システム開発 #設計 #ドキュメント

見積もりを出すときに、作業時間とは別に「確認待ちの時間」も書くようにしました。 開発自体は予定どおり進んでも、仕様確認の返事待ちで日程がずれることが多いためです。待ち時間を先に見せておくと、相手との認識合わせもしやすくなります。 #システム開発 #見積もり #プロジェクト管理

仕様書のレビューでは、書かれていることより「書かれていないこと」を探すようにしています。 例外時の挙動や上限値など、抜けている項目は実装中に見つかるほど修正が高くつきます。着手前に空白を探す時間を取るだけで、手戻りが減ります。 #仕様レビュー #システム開発 #要件定義

コードレビューのコメントに、指摘の理由を一文添えるようにしました。 「ここを直してください」だけだと意図が伝わらず、修正の往復が増えがちです。理由が書いてあれば相手が自分で判断でき、レビューが短く済みます。 #コードレビュー #システム開発 #チーム開発

障害対応のあとの振り返りに、原因だけでなく「なぜ気づくのが遅れたか」も書き残すようにしました。 再発防止は原因の修正で終わりがちですが、検知の遅れを直すほうが次の被害を小さくできます。項目を1つ足すだけで始められます。 #障害対応 #システム開発 #運用改善

受け入れ条件を、実装に入る前に文章で書いてもらうようにしてから、手戻りが減りました。 「何ができたら完了か」を先に揃えると、開発側と依頼側で完成の認識がずれにくいです。書く量は少なくて構わず、3行でも効果がありました。 #受け入れ条件 #システム開発 #開発

管理ツールを使う人にヒアリングしたとき、最初に聞いた要望と、本当に困っていることが違っていたことがありました。 言われた機能をそのまま作るより、作業を横で見せてもらうほうが、小さな改修で効く場所が見つかった気がします。 #要件定義 #エンジニア #開発

今度の日曜、両国の屋上でエンジニア交流会（BBQ）を開きます。 技術の話もキャリアの話も、テーマは自由。おいしいものを食べながら、気軽に話せる場にしたいと思っています。 日時：10/25(日) 12:00〜 会場：両国（墨田区緑）いとうちゅう両国ビル屋上 参加費：3000円（食材・ドリンク込み） 初参加の方も、お一人での参加も大歓迎です。 peatix.com/event/5162428 #交流会 #エンジニア #BBQ

上流のスキルを伸ばしたい人が多いという結果、なるほどと思いました。私も受託やPMで要件定義を担当してきて、言われたことをそのまま形にするより、ヒアリングで本当に困っていることを探す時間のほうが長かったです。そこがいちばん手応えのある部分でした。

デメリットばかり語られる中で、メリットも考えるという視点に共感しました。私も受託で間に入る立場を経験し、人手の波を吸収できる面は感じていました。ただ、間が増えるほど要件の伝言は難しくなる気がします。

機能追加のついでに手を入れたら既存バグが見つかる流れ、よく分かります。私もバージョンアップでは、書き換えをテストで1つずつ確かめながら進めました。気が進まない作業ほど、後で効いてくる気がします。

開発環境を Vagrant と VirtualBox の仮想マシンから Docker に移したとき、一番変わったと感じたのは起動の速さより、環境の作り方が手順書ではなく設定ファイルとしてリポジトリに残るようになったことでした。新しく入った方に渡すものが長い手順書から設定ファイルと数行のコマンドになり、説明する側の私も楽になりました。 #Docker #開発環境 #チーム開発

AIが書いたコードのコメントにポエムが混ざる話、思わず笑ってしまいました。 私もレビューでは、コメントが処理の理由を説明しているかを見るようにしています。 後から読む人のことを思うと、少し気になります。

連休明けはまずログとアラートの確認から、という流れに共感しました。 私もサーバーの保守を見ていた頃は、休み明けの最初に休日中のアラート履歴を追っていました。 何も無いと分かると少しほっとします。