Scraps 最終更新 2026/10/01 22:40

記事一覧 新着順

@kanzawa_kentaro /

【自社開発1年目】「チーム経験ゼロ」の27歳元営業が、ダイレクト出版でAIを使い倒し本番コードを書くエンジニアになるまで

  • 未経験のエンジニアが1年でFEとBEを経験し、コードの責任感を身につけた
  • 仮想PJでTypeScriptとGoを使ったアプリ開発、実務で画像アップロードAPIや決済処理、AIを活用したコード作成
  • 1文字のコード変更がユーザーに大きな影響を与えることを実感し、責任あるコード書く重要性を学んだ

@AIフクロウ|夜な夜なClaude Code /

夜間ジョブが朝まで固まっていた自作ツールの外部通信19か所を、Claude Codeに16分でタイムアウト棚卸し表(判定4種)にして、上限つきリトライまで入れてもらった夜

  • 自作ツールの外部通信19か所をClaude Codeでタイムアウト棚卸し表にした
  • タイムアウトなし12か所、リトライ上限なし3か所、判定4種類で分類
  • 上限のないリトライは別枠で記載し、失敗時の影響を列に記載することで判断材料とした

@jqit-yukiono /

個人開発アプリ「MineWatch」の記事まとめ(随時更新)

  • MineWatchの開発・運用で学んだApp Storeリリースフローと技術的取り組みがまとめられている
  • App Store審査対応、JenkinsとGitHub ActionsのCI/CD、Argo Rolloutsのデプロイ、E2Eテスト設計、負荷試験の実施
  • 審査通過後のCI/CD事故やインフラ設計の誤解、テストコードの罠など実務上の注意点が具体的に記載されている

@jqit-yukiono /

GitHub Actionsの自動マージが、次のworkflowを起動しない ― 2ヶ月「直っていない」と思い込んでいたバグの正体

  • GitHub ActionsでGITHUB_TOKENを使ったマージは次のworkflowを起動しない
  • GITHUB_TOKENで操作するとworkflowのトリガーにならない、PATを使うことで解決
  • PATをsecretsに登録する際、登録前にテストすると対策が効いていないように見える

@jqit-yukiono /

Argo RolloutsのBlue-Greenは「2つの環境の交代」じゃなかった ― 名前に引きずられて誤解していた話

  • Argo RolloutsのBlue-Greenは「2つの固定環境の交代」ではなく、activeとpreviewの役割に毎回新規ReplicaSetを割り当てる方式だった
  • activeServiceとpreviewServiceの2つのServiceを指定し、ReplicaSetは毎回新規作成されて古い方は昇格後に破棄される、Serviceのselectorが新しいReplicaSetへ書き換わる
  • 昇格後、旧ReplicaSetは300秒スケールダウン後に0台になるため、旧環境を温存しない

@jqit-yukiono /

「別々のアプリが似た症状で落ちる」を手がかりに、NFS越しのSonarQube・Nexus・Jenkinsが繰り返しクラッシュする原因を追った話

  • Jenkins・Nexus・SonarQubeがNFS上のファイルI/Oエラーで繰り返しクラッシュしていた
  • NFSサーバーのext4ジャーナルがabort、iSCSI接続の瞬断が原因、watchdogによる自動再起動対応
  • NFSの根本原因はNAS側のiSCSI不安定性で、現在も調査中で応急処置のみ実施

@jqit-yukiono /

「見るだけ」から「操作できる」へ ― MinecraftサーバーへのRCON実行を、個人開発でどう安全に作ったか

  • MinecraftサーバーのRCON操作機能を個人開発で実装する際のセキュリティ対策を解説
  • 接続情報はFernet暗号化で保存し、パスワードはAPIレスポンスとログに一切出さない。RCON失敗時は成功記録として扱い、監査ログに実行履歴を残す
  • RCONパスワードはDBとAPIレスポンスに絶対に表示せず、監査ログで実行履歴を残すことで操作の追跡性を確保する

@jqit-yukiono /

GitHub CodeQLが個人アカウントでは使えなかった話 ― 開発ツールを9本まとめて入れた棚卸しの顛末

  • GitHub CodeQLは個人アカウントのプライベートリポジトリでは導入できず、Semgrepの代替としてOpenGrepに移行した
  • CodeQLはOrganization向けプランで、個人アカウントでは購入メニューが存在せず、OpenGrepはSemgrepの無料フォークでtaint解析が可能
  • 個人アカウントでは有料ツールの利用制限があるため、代替ツールの選定が重要で、LGPLライセンスのOpenGrepを検討すべき

@jqit-yukiono /

Web/admin/iOSにE2Eテストを整備した話 ― 認証を迂回したら、次はテストコード自身の罠が待っていた

  • Web/admin/iOSにE2Eテストを整備し、認証を迂回する仕組みを構築した
  • Web/adminはFirebaseカスタムトークンとApp Check debug token、iOSは起動引数によるDevBypassで認証を迂回、XCUITestのローカライズ文字列やnavigation barの曖昧さが罠
  • Jenkinsのまっさらな環境でAPNs鍵やFirebase設定が不足する問題が発覚し、フォールバック処理を追加した

@jqit-yukiono /

同一人物がApple/Googleどちらでログインしても同じアカウントにする ― Firebase純正のlink(with:)を使わなかった理由

  • Firebase純正のlink(with:)を使わず、バックエンド独自のauth_identitiesテーブルでアカウント連携を実装した
  • Firebaseのcredential-already-in-useエラー対応が破壊的で複数ステップ、auth_identitiesテーブルで1 User : N firebase_uidを管理
  • コンフリクト解決は1つのDBトランザクションに閉じ込め、失敗時ロールバックで詰み状態を回避

@jqit-yukiono /

個人開発のiOS共通ライブラリをSSHフリー化した話 ― 「publicだから認証不要」の勘違いに、Dockerビルドだけが気づいていた

  • YoLibraryのSSH参照をHTTPSに変更したが、認証情報の依存が隠れていた
  • Forgejoミラーはprivateで認証が必要、Dockerビルドで401エラーが発生
  • コードコメントに誤った前提が残り、環境依存の問題を引き起こした

@rana_kualu /

【JavaScript】Promise.resolveはPromiseでないオブジェクトもresolveするしそのせいで脆弱性がたくさんある

  • JavaScriptのthenable仕様がセキュリティ脆弱性の原因となり、SafeResolveプロポーザルが導入されている
  • thenメソッドの存在でthenableと判定され、Promise.resolveが解決する仕様。SafeResolveではユーザコード実行の可能性を確認し、非同期ジョブで解決する
  • Promise.resolveがthenableを解決する仕様はセキュリティリスクがあり、SafeResolveで解決処理を非同期化することでメモリ破壊系の脆弱性を防ぐ

@榊原昌彦 /

クロスプラットフォームアプリのためのiPhone Duoレビュー

  • iPhone Duoではツールバーとタブがvertical barsに移動し、リストの表示範囲がSafe Area内に収まる
  • ツールバーの操作がvertical barsに配置、リストの枠がvertical bars側のSafe Area内に収まる、タブが文字だけでもvertical barsに移動
  • vertical barsの配置はデバイスが自動で決定し、アプリ側で明示的な設定が必要

@カノン@Zenn /

RX 5500 XTからV100S×4まで、4台の計算機でローカルLLMを測り比べた話

  • 4台のGPUでローカルLLMの性能を測定し、pp512とtg128の差が主な指標となった
  • pp512は行列演算器の有無で、tg128はメモリ帯域で差が決まる。V100SはHBM2でtg128が速く、RDNA4はVulkanの方がROCmより速い
  • pp512は行列演算器の有無が重要で、tg128はメモリ帯域の効率が鍵。マルチGPUは容量拡張に有効で、ベンチマークと実運用の差に注意が必要

@anms /

AIは便利な部下から「権限を持つ部下」へ―企業が今すぐ見直すべきAIエージェントのセキュリティ7原則

  • AIエージェントのセキュリティを強化する7つの原則が提示された
  • 最小権限、読み取りと実行の分離、高リスク操作の人間承認、すべての操作ログの残し、AI用IDの分離、緊急停止ボタン、定期的な権限見直しが含まれる
  • AIに与える権限を厳しく管理し、操作ログを残し、緊急停止手段を確保することが重要である

@TechStudioLab /

LINEと診察券番号を安全に紐付ける医療連携設計

  • LINEのuserIdと院内患者IDをアカウント連携で安全に紐付ける設計を採用
  • LINE公式アカウント連携フローで本人確認済みの院内アカウントと結び付け、nonceをランダムな一回限りの値で管理
  • 診察券番号を外部連携に広げず、通知はホワイトリスト方式で送信可否をコードで固定する