Qiita のトレンド記事を要約してまとめたモノ（さぼり）

# [ロードバランサーを設置してネットワークをまるごと吹っ飛ばした](https://qiita.com/nfujita55a/items/49eda31786516ffd1ea9)

12年前、著者は物理ロードバランサー導入時に、L2構成を誤解し、ブロードキャストループによるネットワーク障害を引き起こした。  L2スイッチがARPパケットの洪水でダウンし、既存サービスが停止した。  原因は、社内検証では問題なかったが、本番環境のトラフィック量を考慮していなかったため。  その後、ワンアーム構成に変更したが、検証不足のまま導入を試みた。

この経験から、著者は以下の3点を反省点として挙げている。

1. **ネットワーク非専任者はL3以下のレイヤに手を出さない:** L2、ARP、VRRP、ルーティングプロトコルなどの知識不足によるミスを防ぐため。
2. **検証用機器の購入:** 本番環境と同じ環境で検証を行うため。
3. **インフラエンジニアの雇用:** ネットワークに関する専門知識を持つ人材の必要性を痛感。

要約すると、ネットワークの専門知識不足と十分な検証不足による、物理ロードバランサー導入失敗と、その反省に基づいた改善策に関する記事である。


# [セキュリティエンジニアって200職あんねん（分類とキャリアの話）](https://qiita.com/ahera/items/3bea4df41423ef208700)

この記事は、セキュリティエンジニアの多様な業務を「オフェンシブ(攻撃的)／ディフェンシブ(防御的)」と「上流(計画・設計)／下流(実行・運用)」の2軸で4象限に分類し解説しています。  各象限には具体的な業務例(レッドチーム演習、ペネトレーションテスト、セキュリティポリシー策定、インシデント対応など)と関連資格が示されており、セキュリティエンジニアを目指す際のキャリアパスを考えるための参考資料となっています。  また、レッドチーム、ブルーチーム、パープルチームといった役割についても説明しています。


# [エンジニア向け数学・統計知識総復習【50選】](https://qiita.com/nem_Nuco/items/3a3b17a2a709a6697410)

この記事は、エンジニアにとって便利な数学・統計の基礎知識を、一口サイズで解説したテックブログ記事です。剰余演算、自然対数、対数関数、シグマ・パイ記号、有効数字、論理演算、集合・論理記号、二項係数、N進法、ベクトルと類似度、微分、積分、極限、双曲線関数、分散と標準偏差、変動係数、データの標準化、偏差値、相関係数、確率変数と確率分布、期待値、正規分布、大数の法則、モンテカルロ法、ベイズの定理、時系列分析、マルコフ連鎖、様々な確率分布、データ分析手法、最小二乗法、交差検証、浮動小数点数、文字コード、探索アルゴリズム、Antsの問題、黄金比・白銀比、グラフ理論、最短経路問題、1%ガチャ問題、誕生日のパラドックス、最適停止問題、72の法則、ピケティの不等式、ナッシュ均衡、降水確率、有限オートマトン、逆ポーランド記法、BNF記法といった、基礎から応用的な内容まで幅広く網羅されています。  各トピックは簡潔に説明され、理解を助ける図表も用いられています。


# [かわいいだけじゃだめですか？_(:3」∠)_](https://qiita.com/yu_kong/items/a9a7054644800c59933e)

この記事は、新卒エンジニアが絵文字より1行AA（顔文字）を好んで使う理由を解説したものです。  主な理由は3点。①1行AAは絵文字より種類が豊富で（424個vs106個）、表現力が高い。②感情表現が豊かで、微妙なニュアンスを伝えやすい。③最近の絵文字は意味不明なものも多く、誤解を招きやすいのに対し、1行AAは意味が限定的で分かりやすい、という点です。  さらに、おじさん構文に1行AAを適用することで、印象が改善される例も示し、1行AAの可愛らしさを強調して締めくくっています。


# [ジャンク携帯の中に眠る金、でも掘り出したのは赤字でした](https://qiita.com/tsuchida_na/items/e550ea481c9d1545a94f)

金価格の高騰(経済不安、リスク回避、地政学的リスクが要因)を受け、著者はジャンク携帯から金を取り出す試みを行った。秋葉原で500円のジャンク携帯を購入し解体、金の含有量を概算で計算した結果、約81円の金しか得られず、大幅な赤字となった。


# [Database：Optimistic LockとPessimistic Lock](https://qiita.com/Ian_C/items/c3c4cb00a63fb6092a37)

本記事は、データベースにおける同期問題の解決策としてOptimistic LockとPessimistic Lockを比較解説している。Optimistic Lockはデータ競合を想定せずバージョン番号で衝突を検知する効率的な手法だが、衝突頻度が高いと再試行が増えスループットが低下する。Pessimistic Lockはデータベースロックを用いて競合を防止するが、システム負荷が高まりデッドロックのリスクがある。最適な選択は、衝突率、効率要件、整合性、システム能力を考慮し、データベースのIsolation levelも考慮すべきであると結論づけている。


# [Simple File Manager for Amazon EFSを使ってファイルの操作してみる](https://qiita.com/imataka90/items/1c97b30897e50be6ee7f)

この記事は、Amazon EFSへのファイルアップロードを簡素化する「Simple File Manager for Amazon EFS」ツールの使用事例を紹介している。CloudFormationを用いた簡単なデプロイ手順と、ファイルのアップロード、ダウンロード、削除といった基本操作を解説しており、安価かつ容易にEFSへのファイルアクセス環境を構築できることを示している。  セキュリティ面への考慮も促している。


# [ウォータフォールに少しずつアジャイルのベストプラクティスを導入していった話](https://qiita.com/namatya/items/1e4c7fe86bcf3542b20c)

本記事は、大規模ウォーターフォール開発プロジェクトにおいて、アジャイル開発の手法を一部取り入れる試みについて述べている。具体的には、Microsoft Plannerを用いた進捗管理、定期的な振り返り、打ち合わせ後の議事録作成と認識合わせを実施した。Plannerは個人利用には向いたがチーム管理には不向きだった。振り返りは一定の効果があったものの、プロジェクト後半は時間不足で実施頻度が低下した。議事録作成と認識合わせは当初有効だったが、プロジェクト後半はスケジュール逼迫により頻度が減少した。全体として、大規模プロジェクトでアジャイル要素を取り入れるには時間的な制約が大きいが、一部の手法は有効に機能したと結論付けている。


# [Flutter開発: finalとvarの現実的な使い方](https://qiita.com/badrakh_ted/items/70d3137ac585e2773186)

この記事はFlutter開発における`final`と`var`変数の使い分けについて解説しています。  基本的には、コードの安全性を高めるために`final`変数（一度設定したら変更できない変数）の使用が推奨されます。しかし、単体テストを行う場合は、`var`変数（変更可能な変数）を使うことで、テストしやすいコードが書けます。  Linterの設定によっては`final`の使用が強制される場合がありますが、単体テストを行う場合は、Linterルールを調整するか、`var`を使用し、テストの柔軟性を優先すべきだと結論付けています。


# [Microsoft の「MarkItDown」で Officeファイルを Markdownファイルに変換【Python】](https://qiita.com/youtoy/items/e0495701f03c1875e032)

この記事は、Microsoftが公開したOfficeファイル(Excel、Wordなど)をMarkdownに変換するライブラリ「MarkItDown」を試したレポートです。  厚生労働省の統計データExcelファイルと、e-Govデータポータルのオープンデータ基本指針Wordファイルを用いて変換を行い、その結果をMarkdownテキストとして出力、表示しています。  変換結果は概ね良好で、表データや脚注も適切に処理されていることを確認しています。  ただし、セル結合の処理や、より複雑な文書構造への対応については、さらなる検証が必要であると結論づけています。  最後に、MarkItDownのオンラインコンバータへのリンクも紹介しています。


# [NEC印西データセンターで Oracle FastConnect L2 接続してみてみた](https://qiita.com/shirok/items/7109cc5be1d5230162c2)

NEC印西データセンターにOracle Cloud Infrastructure (OCI) へのFastConnect接続拠点が開設された。これにより、印西データセンターは国内唯一の主要3パブリッククラウド接続拠点を備えるデータセンターとなり、セキュアかつ低遅延なハイブリッド/マルチクラウド環境を提供する。記事では、NECがCiscoルーターを用いてOCIとのFastConnect接続（BGP、ECMP、BFD使用）を構築する手順、設定例、検証結果、およびトラブルシューティングについて詳細に解説している。


# [【全エンジニア必見？】仕事で使えないLinuxネタコマンド大全](https://qiita.com/nuco_sat/items/6851ff4e04dc87882e37)

この記事は、Linuxコマンドラインで使える、実用性はないが面白いコマンドを紹介するテックブログ記事です。  紹介されているコマンドは、牛の絵文字でメッセージを表示する`cowsay`とその派生コマンド、文字列を逆さまにする`rev`、大きな文字で表示する`banner`と`figlet`、ASCIIアートで日本語を表示する`toilet`、テキストを装飾する`boxes`、虹色で表示する`lolcat`など、テキスト操作や表示に特化したものが中心です。  さらに、マトリックス風エフェクトの`cmatrix`、ASCIIアートの水族館`asciiquarium`、テキストベースのゲームなど、アニメーションやゲーム系のコマンドも多数紹介されています。  これらのコマンドは、インストール方法と実行例とともに説明されており、暇つぶしや同僚への話のネタとして活用できることを提案しています。


# [migemoとfzfを合体させたようなものを作りたい](https://qiita.com/kazto/items/b66d8c39a5ed0d63d099)

この記事は、ローマ字入力から日本語を検索するmigemoと、コマンドラインのあいまい検索ツールfzfを組み合わせたツールを作るというアイデアを提案している。migemoの日本語検索機能とfzfのあいまい検索の相性の良さに着目し、Go言語での実装や、Webブラウザ上でのWASMコンパイルによる利用を展望している。ただし、著者はGo言語の経験が浅く、実装には至っていないため、他者による開発への期待も示している。


# [SVGについて理解が曖昧なあなたへ](https://qiita.com/ngtnysk/items/efd5e741817ecbafcced)

この記事はSVG（スケーラブルベクターグラフィックス）の概要と利点を解説したテックブログ記事です。SVGはXMLベースのベクター画像フォーマットで、解像度によらず高画質を維持し、テキストエディタで編集可能、CSSやJavaScriptによるアニメーションも容易に作成できます。  JPG、PNG、GIF、WebPなどのラスター形式との違いを比較し、SVGがロゴ、アイコン、Webアニメーションなどに適していることを説明しています。さらに、簡単なSVGコードの例とアニメーション実装のJavaScript、CSSコード例を示し、SVGの可能性を紹介しています。  WebPのような次世代フォーマットと比較しながら、SVGの継続的な活用を推奨しています。


# [errgroupの上位互換？ sourcegraph/concを触ってみる](https://qiita.com/takurUN/items/d472c066945e252b86f5)

この記事は、Go言語のパッケージ`sourcegraph/conc`を紹介するテックブログ記事です。`sync.WaitGroup`や`sync/errgroup`の上位互換として、より扱いやすい並行処理を実現します。`sourcegraph/conc`は、複数のエラーを返す`WithErrors`、任意の値を返す`ResultContextPool`、panicをキャッチする`panics.Catcher`、同時実行数を制限する`WithMaxGoroutines`などの機能を提供し、Goの並行処理における複雑さを軽減します。  `iter`や`stream`といった、タスクの順番を維持する機能も備えています。  著者は、複雑な並行処理を簡潔に記述でき、保守性も高いこのパッケージを推奨しています。


# [【壁】新卒1年目にぶち当たった頻出エラーを振り返ってみる](https://qiita.com/k-morita412/items/e647921443c3c23ecbd0)

この記事は、新卒エンジニア1年目の著者が2024年に遭遇した頻出エラーをランキング形式で紹介している。

1位は**UndefinedError**（変数やプロパティが未定義の場合）、2位は**command not found**（コマンドの実行ファイルが見つからない場合）、3位は**TypeError**（型の不一致）である。それぞれ、原因と解決策が具体的なコード例とともに解説されている。著者は、エラーを単なる問題ではなく、コード修正の指針と捉えるようになったと述べている。


# [Certified Kubernetes Application Developer (CKAD) 試験の学習方法](https://qiita.com/takahiro_fukushima/items/74b066320cc0dcdfadf4)

この記事は、Certified Kubernetes Application Developer (CKAD)試験に合格した著者が、その試験対策と学習方法を共有している。試験は実技形式で、Kubernetes、Docker、Helmの公式ドキュメントを参照しながら15～20問を2時間で解答する。著者は、試験対策として、kubectlコマンドを熟知し、ドキュメントを参照せずにPod、Deployment、Service、PersistentVolume、PersistentVolumeClaim、ConfigMapの作成と設定を即座に行えるよう、コマンドとYAML定義を暗記することを推奨している。  特に、公式ドキュメントを参照すると時間がかかり、インデントエラーなどにも注意が必要であると指摘している。  最後に、CKA、CKS取得を目指すと述べている。


# [プロダクトを横断するSREチームの実践ベストプラクティス](https://qiita.com/naomichi-y/items/fcde3b9de402d1cc2a33)

メタップスホールディングスのSRE組織立ち上げ6年分の経験をまとめた記事。Google SRE本を完全には満たせないものの、インフラ基盤の安定性向上と障害予防に注力。プロダクト横断型のSREチームをEmbedded SREとPlatform SREに分け、柔軟性とスケーラビリティを両立。AWSを中心としたインフラ、Datadog/PagerDuty/Sentry等のツール、TerraformによるIaC、GitHub ActionsによるCI/CDなどを活用。SLO監視、ログ管理(DatadogとS3併用によるコスト最適化)、トイル削減、インシデント対応、ポストモーテム、プレイブック作成、AI活用(Amazon Bedrock)などを実践。若手育成にも力を入れている。継続的な改善によりインフラの信頼性と保守性を向上させている。


# [新人エンジニアが、仕事を「何もわからない」から「何とかわかる」ようにするには](https://qiita.com/fujiiran/items/e665ebd73a0ae575a6e8)

この記事は、文系出身のサーバーエンジニアが、新卒未経験の後輩エンジニア向けに、仕事を進める上での最低限のポイントをまとめたものである。

**要約:**

未経験エンジニアは「何がわからないかわからない」状態になりがちだが、まずは以下の３点を意識すべきである。

1. **現場の資料を徹底的に読む:** システム構成、関連システム、環境設定、社内ルールなどを理解する。最初は全体像を掴むことを目標に、不明点はメモを取る。
2. **先輩に積極的に質問する:** 回答が理解できなくてもメモを取り、後で復習する。
3. **試行錯誤（try & error）を繰り返す:**  実践を通して学ぶ。同時に、報連相を徹底し、信頼関係を築く。


**要約文の本文:**

新卒未経験のサーバーエンジニアは、仕事の進め方に戸惑うことが多い。  この記事では、そんな状況を打破するための３つのステップを提案している。まず、設計書などの現場資料を精読し、システム構成や関連システム、社内ルールなどを把握する。次に、不明点を先輩に積極的に質問し、回答内容が分からなくてもメモを取り、後日の学習に活かす。そして、実際に手を動かし、試行錯誤を繰り返すことで実践的なスキルを身につける。  同時に、報連相を心がけ、周囲との信頼関係を構築することも重要だと強調している。技術的なスキルは後からついてくるので、まずは現場を理解し、積極的に学ぶ姿勢を続けることが大切であると結論づけている。


# [Open WebUIにSwarmを組み込む](https://qiita.com/mrsd/items/b692c3fd90a360d2e833)

この記事は、Open WebUIとSwarmを用いて、TRIAL＆RetailAI Advent Calendarの記事を英訳するマルチエージェントシステムを構築した事例を紹介しています。Open WebUIのPipeline機能にSwarmを組み込み、トリアージ、一覧表示、記事取得の3つのエージェントを作成。シンプルなタスクでは効果を発揮しましたが、複雑なタスクやエラー処理にはチューニングが必要であると結論づけています。ローカルLLM利用時などに有用な手法として紹介されています。


# [顔画像を切り抜きたい！~ Google Mediapipeを使って顔検知編 ~](https://qiita.com/a_yoshio/items/af26e2baca940c35c538)

この記事は、Google MediaPipeを用いて画像から顔を検出し、その座標を取得するまでの過程を記述したテックブログです。  MediaPipeのインストール、顔検出モデルの読み込み、顔ランドマークの検出、そして検出されたランドマークの座標をピクセル座標に変換する手順をコード付きで解説しています。  ただし、座標から顔の輪郭を抽出し、顔を切り抜く処理までは実装できておらず、今後の課題として残されています。  MediaPipeによる顔検出と特徴量取得の可能性についても触れられています。


# [AWSコンソール上からWindowsServerにユーザを作成する](https://qiita.com/g-nawa/items/da7319b2d3e31512d241)

AWS Systems Managerを用いて、AWSコンソールからWindows Serverにユーザーを作成する方法を紹介している。前提として、VPC、EC2、SSMAgent、KMSキーが設定済みである必要がある。手順は、1. セッションマネージャーの設定(KMSキーの指定)、2. EC2インスタンスにSSMManagedInstanceCoreポリシーとKMSアクセス権限を持つIAMロールのアタッチ、3. Systems Managerのフリートマネージャーからユーザー作成と「Remote Desktop Users」グループへの追加、4. リモートデスクトップ接続による確認、の4ステップ。パスワードを設定する場合はKMSキーが必要となる。


# [人の話の聞き方](https://qiita.com/Yuki_Ishikawa/items/c2484ddc0c6ac17f1546)

このテックブログ記事は、社会人にとって重要な「人の話を聞くスキル」について解説している。  要点は以下の3点。

1. **メモを取る:** 仕事の会話では、記憶に頼らずメモを取ることで正確な情報取得と後からの確認を可能にする。
2. **疑問点を後回しにする:** 話の途中で質問せず、最後まで聞いて内容を整理してから、必要な情報を聞き漏らしていないか確認し、疑問点を質問する。作業手順を事前にイメージすることで、質問すべき点を明確にできる。
3. **最後まで聞くことの重要性:** 話を途中で遮ると相手にストレスを与え、情報伝達を阻害し、最終的に自身の評価にも悪影響を及ぼすため、最後まで聞くことを優先する。


要約した内容を簡潔に表現すると、「**社会人として、話を聞く際はメモを取り、最後まで聞き、内容を整理してから疑問点を質問する事が重要である**」となる。


# [JUnitを用いた単体テストについて](https://qiita.com/Nami_kawa/items/1c0b8e18001ddc7d36a1)

この記事は、JUnit、MockK、Mockitoを用いた単体テスト作成に関する備忘録です。`@Test`, `@Before`, `@MockK`, `@Mock`アノテーションの使い方、`assertEquals`, `assertThat`アサーション、MockKの`every {} returns`、Mockitoの`when().thenReturn()`によるモックの振る舞い定義方法を説明しています。  JavaとKotlinの両方のコード例を示しています。


# [Wordの便利なオプション設定について](https://qiita.com/ta-okamoto/items/35528c5a79bad44cc07a)

この記事は、Wordの便利な設定3つを解説したものです。

1. **編集記号の表示:** 段落記号、スペース、タブ記号などを表示し、文字配置や書式を確認しやすくする設定方法を説明。
2. **オートコレクトオプション:** 「the」を「The」に自動変換するなど、自動変換機能の設定方法を説明。
3. **フィールドの網かけ表示:** 日付や段落番号などWord機能使用箇所をグレーで強調表示する設定方法を説明。


これらの設定は、「ファイル」>「オプション」から行うことができます。


# [開発を実際に行ってみて...](https://qiita.com/takumi08/items/c08d9e9ceaebcd493e6a)

2年間のエンジニア経験を振り返る記事。初期はテストや修正作業が中心で自信過剰だったが、実際の開発でその自信は打ち砕かれた。フリーフォーマットでの開発を通して、テスト仕様書作成時の整理の重要性、ソースコードのインデントや命名規則の統一性、分かりやすい資料作成の必要性を学んだ。今後はこれらの点を改善し、スキルアップを目指していく。


# [VMを初めて使った時のメモ](https://qiita.com/saito-hiro/items/5a3f00515412d45ae17e)

この記事は、新卒エンジニアが初めてVirtualBoxとUbuntuを用いた開発環境構築の経験を記したものである。VirtualBoxのスナップショット、クリップボード共有、シームレスモード、リソース設定の4つの機能が便利だった一方、スナップショットの使いすぎでPC容量を圧迫し、環境が壊れるという失敗も経験した。この失敗から、不要なスナップショットの削除と、問題発生時の早期上司への相談の重要性を学んだ。


# [これを知らないと損！開発者なら知っておきたいGitコマンド10選](https://qiita.com/muu3/items/c99ec4df17acf498aec1)

この記事は、Gitの基本コマンドだけでは十分に活用できていない開発者に向けて、開発効率を劇的に向上させる10個のGitコマンドを紹介している。具体的には、バグ特定のための`git bisect`、作業状態の一時保存`git stash`、コミット履歴確認`git reflog`、特定コミットの適用`git cherry-pick`、変更履歴確認`git blame`、不要ファイル削除`git clean`、コミット履歴表示`git log --oneline --graph`、リセット`git reset`、差分表示`git diff`、アーカイブ作成`git archive`といったコマンドの使い方と例が解説されている。これらのコマンドを活用することで、開発プロセスをよりスムーズにできるようになる。


# [新卒が5ヶ月働いて感じた良かった習慣](https://qiita.com/630/items/7ee7871b84f40928fec6)

この記事は、新卒の著者が社会人生活で効果的だった「手書きノートによるメモ」の習慣について述べています。  会議メモ、タスク管理、疑問点、調査結果など、あらゆる情報を手書きノートに記録することで、過去の類似事例の参照や迅速な対応が可能になり、業務効率の向上に繋がったと報告しています。  手書きノートのメリットとして、「すぐに記入できる」「図表が書きやすい」「視覚的に分かりやすい」「文具でモチベーションを上げられる」点を挙げ、具体的な活用方法やおすすめのノート、メモの取り方（日付、記号の統一、1冊にまとめる、感情の記述）を紹介しています。


# [家に Raspberry Pi が落ちていたので腰痛を改善しようとした](https://qiita.com/kotenpan7255/items/f17dfc8a28d8bf9a5b71)

この記事は、著者が長時間のデスクワークによる腰痛予防のために、自宅にあったRaspberry Piを用いて姿勢検知システムを作成した過程を記述している。  Raspberry Pi、カメラ、MoveNetという姿勢推定モデルを用い、猫背と前傾姿勢を検知するシステムを構築した。  シンプルなルールベースで実装したため精度に課題が残るものの、リアルタイムでの姿勢検知を実現した。 今後の改善点として、時間軸データの活用や機械学習モデルの導入を挙げている。  最後に、エンジニアにとって健康の重要性を強調している。