英航空ショーに参加したF35戦闘機を見る観客（2022年7月19日撮影、資料写真）。(c)JUSTIN TALLIS / AFP 【9月18日 AFP】米サウスカロライナ州で17日、米軍のステルス戦闘機F35が行方不明となり、軍が市民に情報提供を呼び掛けている。 当局によると17日午後、サウスカロライナ州を飛行中のF35で「不運な出来事」があり、戦闘機から操縦士が緊急脱出した。操縦士は無事生還したが、機体の行方が分からなくなっている。 事態を受け、チャールストン統合基地（Joint Base Charleston）は「捜索チームの助けになるような情報があれば、基地の防衛作戦センターに通報してください」と、X（旧ツイッター〈Twitter〉）に投稿し、地元住民に協力を仰いだ。 統合基地は連邦航空規制当局と協力し、チャールストン（Charleston）市北側にある二つの湖周辺で捜索を行っている

(2009.3.5 テストデータについてちょっと追記) Working Effectively with Legacy Codeを読んでいます。前半、テストの意義とか概念の紹介(test harness, seamなど)はすばらしい。後半の、個別の状況への対策も、整理されていてありがたいです。自分でも使っているおなじみの手法もあれば、目ウロコなこともある。 でも、こういう↓章があったらよかったなあ。 「テストを書きたいけれどプログラムが巨大なSQLの固まりだ」 いま仕事をしている保守プロジェクトが、そういう状況なわけです。もうすこし整理すると、 テーブル数が多く(100以上)、重複した項目も多い(非正規化) ひとつの処理をするのにだいたい、最低5つ以上(10を超えるものも多い)のテーブルを扱っている(参照ならJOINやUNION、更新ならそれぞれにUPDATE/INSERT) 処理を走らせ

SQLインジェクションによる認証回避 SQLインジェクションによる影響として、情報が漏洩するとか、データが勝手に更新されてしまうなどとともに、認証回避の例がよく紹介されます（私の本でも取り上げています）。 典型的な例は下記のとおりです。 // $id と $password は外部からの入力 $sql = "SELECT * FROM users WHERE id='$id' AND password='$password'";

SPAやモバイルアプリから利用するAPIを開発する際の、トークン認証のお話です。 どの認証ライブラリを使うべきという話ではなく、トークン認証の論理的な設計について考察します。 私自身も結論が出ていないので、色んな意見が聞けると嬉しいです。 出発点 ユーザテーブルにアクセストークンを持つのが最も安直な発想だと思います。 ログイン成功時にアクセストークンを発行し、該当ユーザレコードにセット。 同時に有効期限もセットします。 認証時には、アクセストークンが存在し有効期限内であれば、認証を通過させ、 そうでなければ認証失敗とします。 ログアウト時には、該当ユーザレコードのアクセストークンを空にします。 発行日時を持ち、システム内に定義された有効期間をもとに、認証時に計算する方法もあると思います。 Laravel Sanctum 等はそういう実装です（しかもデフォルトでは有効期限なし）。 有効かどう

Adobe Firefly で生成PdMむけの記事でこのような記事がある。 「プロダクトマネージャーこそ、戦略的に読書せよ！」── 最短で成果を出すための読書地図 (1/6)|ProductZine（プロダクトジン） これのエンジニア向けの記事がないかなと思っていたがなさそうだったので作ろうと思った。しかし客観的な視点でこれがおすすめというのは難しいので自分が参考になったと思った本を家の本棚を見ながらまずは100冊リストアップしてみた。 紹介する本は10年読まれていたり、近年発売のものであれば10年後にも読まれているだろうというものを選ぶようにしている。個別のプログラミング言語やフレームワークなどの本はバージョンアップに追随ができないことが多いので選んでいない。 入門本プリンシプル オブ プログラミングリーダブルコード定番中の定番。おそらくこの2冊はあちらこちらで紹介されている。とりあえず