Qiita のトレンドの記事を要約をつけてそのまま載せてる記事（さぼり）

## [2024年最新版：Pythonデータ解析ライブラリ総まとめ - 実践的ガイド](https://qiita.com/Tadataka_Takahashi/items/3f48b48c95b63f6d6ab7)
2024年最新版のPythonデータ解析ライブラリに関するガイドでは、データ処理や可視化、機械学習の自動化を可能にする新しいツールを紹介しています。Pythonのデータ解析エコシステムは進化し続けており、最新のライブラリの特徴や使用例、導入方法について詳しく解説されています。 まず、データ操作ライブラリとして、PolarsとVaexが挙げられています。PolarsはRustで実装され、高速なデータ処理が可能であり、pandasに似たAPIを持つため、ユーザーは使いやすさを感じることができます。特に、金融業界やIoTデバイスからのデータ分析に適しており、1億行のデータセットでの集計操作ではpandasよりも約5倍速く動作します。一方、Vaexは数十億行のデータを効率的に処理できるライブラリで、特に天文学やゲノム解析での利用が進んでいます。Vaexは遅延評価を利用してメモリ効率が高く、基本的な統計計算ではDaskよりも2倍のスピードを示します。 次に、データ可視化ライブラリとして、Plotly ExpressとAltairが紹介されています。Plotly Expressはインタラクティブなグラフを簡単に作成でき、美しいデフォルトデザインを持ちます。Altairは宣言的な方法でのチャート作成が可能であり、データジャーナリズムや学術研究に広く活用されています。特に、複雑な多層グラフの作成においては、AltairはMatplotlibよりもコード量を50%以上削減できます。 機械学習ライブラリとしては、PyCaretとSHAPが取り上げられています。PyCaretは機械学習のワークフローを自動化し、初心者でも使いやすいことが特徴です。小売業や医療分野でのモデル構築に役立ち、手動でのモデル選択と比較して約70%の時間を短縮できます。SHAPは機械学習モデルの予測を視覚的に説明するためのライブラリで、金融機関や環境科学での応用が広がっています。 最後に、2024年におけるPythonデータ解析ライブラリのトレンドとして、分散処理の進化やAutoMLの高度化、説明可能AIの重要性増大、インタラクティブ可視化の標準化、クラウドネイティブな解析環境の発展が予測されています。これらのライブラリを適切に利用することで、より効率的で洞察に満ちたデータ分析が可能になります。データサイエンスの進化に対応するためには、継続的な学習が重要です。
## [【git stash入門｜初心者向け】3分で学べる！git stashの基本的な使い方](https://qiita.com/wamauuphhh/items/687530c5638605cd0779)
この記事では、Gitのコマンド「git stash」の基本的な使い方を解説しています。主な対象はGit初心者で、特にaddやcommitといった基本操作を理解しているが、stashについては未経験の方です。また、複数人での開発を始めたばかりの方にも役立つ内容となっています。 git stashは、現在のブランチで行った変更内容をコミットせずに一時保存できる機能です。これにより、別のブランチに移動する必要がある場合や誤って異なるブランチで作業してしまった際にも、作業内容を失うことなく管理できます。例えば、作業中に急に別のタスクが発生した場合でも、stashを使用すれば現在の進捗を保存して他の作業を行うことができます。 基本的なコマンドとしては、まず「git stash」を使用することで変更内容が一時保存され、次に「git stash push -m "コメント"」によってコメント付きで保存することも可能です。保存した変更を確認するためには「git stash list」を実行し、一覧を表示させることができます。さらに、一時保存した変更を現在のブランチに適用するには「git stash apply」を使い、変更を適用した後もstashリストに残すことが可能です。また、「git stash pop」を使用すれば、変更を適用した上でstashリストから削除することができます。 他にも、特定の変更をstashリストから削除する「git stash drop」や、全ての変更を削除する「git stash clear」といったコマンドも存在します。これらのコマンドを駆使することで、効率的に作業を進めることができるでしょう。最後に、この記事が読者にとって有益であることを願っています。
## [iPadにUbuntu 22.04をインストールする](https://qiita.com/Teggu/items/5951dc91a98644467846)
iPadにUbuntu 22.04をインストールする方法について説明します。UTM SEというアプリがApple Storeに公開され、これを利用することでiPad上でUbuntuを動かすことが可能になりました。UTMは仮想環境を構築するソフトウェアで、Macの場合はM1 Mac上でWindowsを実行できる機能がありますが、iPad版は以前はAppleによるエミュレータアプリの公開禁止により実現できませんでした。しかし、最近Appleの審査を通過し、公開される運びとなりました。 ただし、現時点ではいくつかの理由からインストールは推奨されていません。具体的には、最適化が不十分で動作が重く、起動に体感で約30分かかること、ログインできない問題があること、しばらく使用しないとアプリが自動的に終了してしまうことなどがあります。 インストール手順は以下の通りです。まず、Apple StoreからUTM SEアプリをダウンロードし、開きます。次に、アプリ内の「UTMギャラリーをブラウズ」から「Ubuntu 22.04」を選び、ビルド済みのパッケージをダウンロードします。ダウンロードが完了したら、「ubuntu-20.04-arm64-utm.zip」を解凍し、「Ubuntu 22.04」をUTM SEで開きます。その後、設定を変更し、メモリやCPUコアをiPadに合わせて調整します。最後に再生ボタンを押すと、Ubuntuの起動が始まります。待機中はSplit Viewで他のアプリを開くことで退屈せずに済むでしょう。
## [ひとりSEは「仕事の早い屋台のおっちゃん」を目指そう](https://qiita.com/minoden_works/items/d0fac6e5471b64409811)
ひとりSEは「仕事の早い屋台のおっちゃん」を目指すというテーマで、社員100名規模の企業で社内SEが一人しかいない状況における対策や工夫について述べています。社内ではIT系専任が自分一人という環境で、業務システムは外注しつつも、社内インフラの管理者が不在であるため、経理が限界に達している現状を分析しています。 まず、社内インフラの統一が重要で、Google WorkspaceやMicrosoft 365を用いることでIDを一本化し、クラウド化を進める必要があります。オンプレミスのNASなど二重管理を避けるため、クラウドサービスの導入が必須です。また、デバイスの統一についても、同じメーカーやモデルを揃えることで管理を簡素化し、OSイメージの仮想化を活用してキッティングを迅速に行っています。 次に、ベンダーの活用を通じて物理作業を減少させ、経理的にも効率化を図ります。定常業務の自動化では、Google App ScriptやPowerShellを利用し、ユーザーの入退社情報をスムーズに管理する方法を提案しています。これにより、従業員の変更をアナログからデジタルに移行し、業務の効率化を図ることが可能です。 キッティングに関しては、迅速なPC準備が求められるため、VHDブートを用いた効率化を実現し、さらに自動化のためのツールやサービスを模索しています。ユーザーからの問い合わせ管理も重要で、シンプルな方法で対応できる体制を整えておくべきです。複雑なシステムは逆に負担を増やすため、ワンインフラを目指すことが肝要です。 ネットワーク管理については、クラウド管理可能なデバイスを選び、必要に応じてモバイルデバイス管理（MDM）を導入し、社員の使用環境を整えています。特にApple製品が好まれているため、Jamfのような管理ツールに注目しています。また、iPadを活用したVDIの導入がフロントラインの業務において役立つとされています。 最後に、SSO（シングルサインオン）は必要最小限にとどめ、キッティングの効率化を進めることが求められます。全体を通して、ひとりSEとしての役割を果たすためには、自動化と効率化を重視し、ユーザー対応に時間をかけることで「仕事の早い屋台のおっちゃん」のような存在を目指すことが大切であると結論づけています。ドキュメントの整備も重要な要素で、属人化を避けるための対策が強調されています。
## [FastAPIのテストをしっかり書いてみる](https://qiita.com/Katsuya_Ogata/items/bf722219c2aa454bb0eb)
この記事では、FastAPIにおけるテストの書き方について、大学生のインターンが自身の経験を元にまとめています。FastAPIは高性能で柔軟なフレームワークですが、テストを書くには工夫が必要です。特に非同期処理を含むテストについて、pytestを使用したユニットテストやAPIテストの方法、CIの設定について詳しく説明しています。具体的な内容としては、非同期テストの実践、pytestの基本的な使い方、Dockerを用いたCIの実装方法などに焦点を当てています。 非同期テストでは、FastAPIの特性を活かし、テスト関数に@pytest.mark.asyncioデコレータを付与する必要があることが強調されています。ASGI（非同期サーバーゲートウェイインターフェース）の特性を理解することも重要です。続いて、pytestの便利な機能として、fixtureを使ったテストの前後処理や、parametrizeでのテスト共通化、pytest-mockを活用したユニットテストの実施方法が紹介されています。これにより、効率的でわかりやすいテストコードが実現できます。 CIの実装については、GitHub Actionsを利用した具体的な設定例が示されており、ユニットテストやAPIテストを自動化する方法が詳述されています。テストの結果はPRのコメント欄に表示され、コードの品質を保つための重要な手段としての役割を果たします。特に、Docker環境でのテスト実行や、MySQLコンテナを用いたデータベースの準備方法についても触れています。 最後に、テストを書くことは手間がかかりますが、CIを導入することでコードの品質を保ち、安全に変更を迅速にデプロイできると締めくくられています。記事は、同様の課題を抱える開発者にとって参考になることを目的としています。
## [SSH キーの複数管理の設定手順をまとめてみた](https://qiita.com/hirokazu_nakao/items/1f0af8fe487ccc4f53da)
SSHキーの複数管理の設定手順について、エンジニアの方々に向けてまとめられた内容です。まず、著者は「複数のGitHubアカウントのSSH管理」に関する情報収集の難しさを共有し、その結果として手順を整理しました。前提として、Macの操作手順を基に、すでにGitHubアカウントAでのSSH鍵の設定が行われていることが前提です。また、GitHubアカウントBの鍵は未設定であり、リモートリポジトリへの登録も完了している状態です。 手順はまず、アカウントB用の公開鍵と秘密鍵の作成から始まります。ターミナルを使い、特定のコマンドを入力することで、指定されたファイル名の鍵を生成します。次に、SSHキーをssh-agentに追加し、configファイルにアカウントB用の設定を加えます。その後、生成した秘密鍵の内容を確認し、パスフレーズをキーチェーンに保存します。 続いて、GitHubアカウントBにSSHキーを追加するため、公開鍵の内容をコピーし、GitHubの設定画面で必要な手続きを行います。次のステップでは、リモートリポジトリの接続先を確認し、必要に応じてHost名を変更します。最後に、SSHの疎通確認を行い、正しく設定が完了したことを確認します。 著者は、今回の経験を通じてSSHに関する理解を深めることができたと述べ、特にGitHubアカウント単体の設定は公式手順に従えば容易であるとしています。この情報が他のエンジニアに役立つことを願っています。最後には、著者が所属する会社の紹介と、求人情報へのリンクも提供されています。
## [SQL に C# のコードを書いて実行する](https://qiita.com/YoshitakaTerashima/items/55c4d3d5b10d066a1f74)
SQLにC#のコードを埋め込み実行するライブラリ「NDao」の紹介です。NDaoは、データベース操作を行うためのDAO（Data Access Object）を自動生成し、ユーザーはインターフェースを通じて簡単にデータベースを操作できます。具体的には、SQLを実行するコードをRoslynのSource Generatorを用いてビルド時に生成することで、パフォーマンスの向上やエラー発見の容易さを実現しています。 NDaoの特徴には、SQLファイルを簡単に実行できる仕組みやC#コードを埋め込む機能、動的なSQLの生成、CRUD用APIの提供、SQLのロギング機能が含まれています。また、EF Coreのマイグレーション機能とも併用可能で、特に「EF CoreでマイグレーションはしたいがSQLは自分で書きたい」というニーズに応えるものです。まだ実績がない段階ですが、今後実務に耐えられる製品へと成長させていく意向があります。 このライブラリは個人開発のアプリケーションのために作成されましたが、一般公開することにしました。詳細なドキュメントやサンプルプログラムはリポジトリにて提供予定で、SQLiteを使用しているため、特別な設定なしで試すことができます。興味のある方はぜひお試しください。
## [無知の学生が3ヶ月で緑色コーダーになるまで](https://qiita.com/kazuppa/items/4f11e45743ae179dc459)
無知の学生が3ヶ月で緑色コーダーになるまでの過程を振り返った内容です。著者は7月14日にAtCoderで入緑を達成したことを報告し、自己の成長を紹介しています。競技プログラミング、通称競プロは、与えられた問題をプログラミングで実装し、正確性や速さを競うもので、AtCoderがそのプラットフォームとして知られています。競技者は同一の課題に取り組み、その結果によってレートが変動し、レートに応じて色が変わる仕組みがあります。 著者は、灰色から茶色、茶色から緑色に上がる過程が簡単ではないと述べています。特に、茶コーダーになるためにはAtCoder Beginners Selectionを活用し、基本的な問題の提出方法や過去問を解くことが大切です。AB問題の解法には、基本的なプログラミングスキルが必要であり、特にB問題では計算や条件分岐、繰り返し処理などが求められます。 著者はAB問題の解法として、全探索やシミュレーション、数学的考察を使用する方法を説明しています。プログラミング力は、データ構造とアルゴリズムに関する知識とコーディング能力の組み合わせによって決まると考えています。B問題を解けるようになった後は、C問題に挑戦し、計算量やアルゴリズムの知識が求められます。 C問題の例として、配列の並び替えを行う問題が挙げられ、実行時間の制限内に解くために効率的なアルゴリズムを考える必要があると説明しています。著者は、解説を読むことの重要性や、アルゴリズム系の学習材料についても触れています。特に、蟻本や鉄則本、アルゴ式などの書籍を活用し、アルゴリズムやデータ構造の知識を深めていくことが重要です。 入緑に必要な要素として、3冠早解きやアルゴリズム・データ構造の知識が挙げられ、特に早解きはタイピングの速さや問題への慣れに依存すると述べています。また、過去問演習が力を身につけるために最も重要であり、AtCoder Problemsを利用して解いていくことを推奨しています。 著者は、自身の茶色コーダー時代の振り返りとして、緊張感を持ちながらコンテストに臨んだ経験や、実装力の重要性を強調しています。特に、コンテスト中のミスや学びを通じて、成長を感じることができたと述べています。最終的に、ABC362のコンテストで入緑を達成した際の喜びを振り返り、読者に向けて感謝の意を表しています。 このように、著者は競技プログラミングの楽しさや挑戦を伝えた記事を通じて、他の人々にも役立つ情報を提供し、さらなる成長を目指す意欲を示しています。次は水色コーダーを目指して成長していくと締めくくっています。
## [Java Silver 試験対策 メソッドまとめ一覧](https://qiita.com/JK447/items/fabda6464d5bd78d1545)
Java Silver試験に向けたメソッドのまとめでは、主にStringクラス、StringBuilderクラス、Mathクラス、Arraysクラス、Collectionsクラスに関連するメソッドが紹介されています。 まず、Stringクラスのメソッドとして、`indexOf`は指定した文字や文字列の最初の出現位置を返し、見つからない場合は-1を返します。`substring`は指定した範囲の文字列を返し、`replace`は特定の文字や文字列を別のものに置き換えます。`replaceAll`は正規表現に一致するすべての部分文字列を置き換えます。また、`split`メソッドは文字列を指定した区切り文字で分割し、配列として返します。`trim`は文字列の前後の空白を削除し、`charAt`は指定したインデックスの文字を取得します。さらに、`equals`メソッドは二つの文字列が等しいかを比較し、`compareTo`は辞書順での比較を行います。`toUpperCase`および`toLowerCase`は文字列を大文字または小文字に変換します。 次にStringBuilderクラスでは、`append`で文字列を末尾に追加し、`insert`で指定した位置に文字列を挿入します。`delete`メソッドは特定の範囲の文字を削除し、`replace`は範囲内の文字を置き換えます。また、`reverse`メソッドで文字列を逆順にし、`capacity`メソッドは現在の容量を取得します。`length`は文字列の長さを返し、`setLength`で長さを設定できます。`substring`メソッドも提供され、Stringクラスのものと同様に動作します。 その他のクラスにおいて、Mathクラスでは`max`および`min`メソッドが二つの値の大きさや小ささを返し、`abs`は絶対値、`sqrt`は平方根、`pow`はべき乗を計算し、`random`はランダムな値を生成します。Arraysクラスでは、`sort`で配列を昇順に並べ替え、`binarySearch`で指定した値を検索し、`equals`で配列の等しさを比較し、`fill`で全要素を指定した値で埋めます。最後にCollectionsクラスでは、`sort`でリストを昇順にソートし、`binarySearch`でリストから値を検索、`reverse`でリストの要素を逆順にし、`shuffle`でリストをランダムに並べ替えることができます。
## [バッファレスレンダリングで25行から始めるWebGL2](https://qiita.com/emadurandal/items/c88d95aa321eea179ac2)
WebGL2を利用したバッファレスレンダリングの方法について解説がなされています。WebGLを試す際に、頂点バッファの準備が面倒に感じることがありますが、WebGL2ではgl_VertexIDという内部変数を使用することで、頂点バッファなしで三角形を描画することが可能です。具体的には、著者が提供する25行のコード（実際には26行）を用いて、簡潔なWebGL2のプログラムを作成します。 このプログラムでは、頂点シェーダーとフラグメントシェーダーが定義されており、gl_VertexIDを使って三角形の頂点の位置を計算します。実際のコードは、initWebGL、initShaders、drawといった関数を呼び出すことで、三角形を画面に表示します。頂点シェーダーの内容を詳しく見ると、gl_VertexIDの値が0、1、2の時にそれぞれの頂点がどのように配置されるかが理解できます。 また、バッファなしで画面全体を覆う矩形を描画する方法も紹介されており、テクスチャ座標を用いてポストプロセスやスクリーンスペース処理ができるため、非常に便利です。これらの技術は、バッファレスレンダリングと呼ばれ、頂点データの準備を省略することによって、コードを簡潔に保つことができます。この記事では、WebGL2の可能性を活かし、シンプルで効率的な描画方法を提案しています。
## [#100DaysOfCodeをはじめて気がついたら1ヶ月がたっていた話](https://qiita.com/masafumi1073/items/97ef3d12f96a4aef01e0)
#100DaysOfCodeというハッシュタグは、コーディングの習慣を身につけるためのチャレンジです。私もこのチャレンジを始めた結果、1ヶ月が経過したことを振り返りたいと思います。このチャレンジは、毎日最低1時間以上のコーディングを行い、その成果をTwitterに投稿するというものです。具体的なルールについては公式サイトを参照できます。 私がこのチャレンジを始めたきっかけは、会社の後輩との勉強会でした。仕事をしながら毎日続けるのは難しいため、お互いのモチベーションを維持しつつ、取り組みを確認し合うためにこの挑戦を選びました。チャレンジを通じて得た良かったことは、勉強の習慣化、モチベーションの維持、そして自肯定感の向上です。特に、自肯定感が高まったことは大きな成果だと感じています。プログラミングの勉強には壁があり、エラーが解決できないことや理解が難しいことが多いため、自分に適性がないと思いがちです。しかし、同じチャレンジをする仲間からの反応が励みとなり、自分の頑張りを実感できるようになりました。 現在、100日間のチャレンジの1/3を達成したところですが、勉強の習慣が身につき、スキルも向上したと感じています。今後は、勉強の質をさらに高めていくことを目指しています。プログラミングの勉強は時間がかかるもので、長く続けるためには自分を適度に褒めることが重要だと、このチャレンジを通じて実感しました。さまざまな学びの方法がある中で、他の皆さんも自分に合った方法で頑張ってほしいと思います。興味のある方はぜひ#100DaysOfCodeに参加してみてください！
## [ROS 2のDockerコンテナ間でpub/subするとき、docker runでどのオプションを付ければいいの？](https://qiita.com/dandelion1124/items/9c0a9c16956bb8fb9065)
ROS 2のDockerコンテナ間での通信方法について、特にpub/subの実装に関する詳細が述べられています。まず、Dockerコンテナ間の通信に必要なオプションとして「--net=host」と「--ipc=host」が推奨される理由を掘り下げていきます。これにより、同一マシン上でROS 2のコンテナが正常に通信できることが確認されます。 次に、ユースケースに応じたdocker runオプションが説明され、特にROS 2 HumbleとFast DDSを使用した場合の動作確認が行われます。環境設定として、Ubuntu 22.04とDockerを用いており、具体的にはFast DDSとCyclone DDSの2つのDDSを比較する形で検証が行われました。動作確認の結果、Fast DDSを用いた場合は「net=host」オプションを使わないとpub/subができないことが示されましたが、Cyclone DDSではいずれのオプションでも通信が成立しました。 さらに、docker runの「net」オプションの詳細について説明され、特に「--net=host」の使用が強調されます。このオプションを使用することで、ホストと同一のネットワークインターフェースを利用し、よりスムーズな通信が可能になります。また、「--ipc」オプションについても、プロセス間通信のためにホストの名前空間を共有する設定が重要であることが強調されます。 後半では、Fast DDSを用いてShared Memory Transportを利用するための具体的な設定が記載され、初期化時にエラーが出ずにpub/subが成功したことが報告されています。ここでは、Shared Memory Transportを利用する場合には「--ipc=host」が必要ですが、UDP Transportを利用する設定にすれば「--ipc=host」を外すことができるという柔軟性があります。 また、Dockerコンテナでの共有メモリの割り当てについても触れられ、デフォルトの共有メモリサイズが64MBであるため、必要に応じて「--shm-size」オプションで増やすことが推奨されています。具体的には、1GBの共有メモリを割り当てる設定も示されています。 最後に、ROS 2のコンテナを異なるPC間でpub/subさせる場合には、「--net=host」が必要であり、これがデフォルトの「--net=bridge」では通信ができない理由が説明されます。これらの設定やオプションを理解することで、ROS 2のDocker環境での効率的な通信が実現できます。
## [アンリーダブルコード](https://qiita.com/kaku3/items/be52433ebcb19a4485f6)
アンリーダブルコードは、コンピュータには読めるが人間には理解しにくいコードを指します。このようなコードは技術的負債としばしば議論され、リファクタリングの必要性が問われます。人間が書くにもかかわらず、長くてまとまりのない関数や、脈絡のない処理が散在することが多く、コピペによるチグハグなコメントや名称と実際の処理が異なる関数が問題視されています。コンピュータは文法的にエラーがなければコードを実行できるため、必ずしも人間が理解しやすい形式である必要がないのが、アンリーダブルなコードが生まれる一因です。 分かりやすいコードを書くためには、構成力、整理力、文章力が必要です。これらの能力を駆使して、理路整然としたプログラムを書けば、理解しやすいコードが生まれるでしょう。プログラミングは日本語の設計をコンピュータの言語に翻訳する作業であり、私たちは日常的に長文を書くことが少ないため、これらのスキルが不足しがちです。書籍によってカイゼンを目指す人が多いことは、そのニーズを示していますが、実際にスキルを高めるには、書籍を読むだけでは不十分で、反復練習が必要です。 文章力が向上したら、次はコードをリーダブルにする訓練が求められます。しかし、これもまた年単位の実践が不可欠です。最終的には、書いたコードがどのようなものであるかを把握し、カイゼンに向けた法則やルールを学び、それを定着させるための反復が必要であると考察しました。特に、リーダブルなコードを書くためには、学び続ける姿勢と実践が重要です。
## [AWS NAT ゲートウェイ を理解した上で起動＆停止 Lambda を用意する](https://qiita.com/haruki-lo-shelon/items/62739a79787dca986b61)
AWS NATゲートウェイを理解した上で、開発環境とステージング環境のコスト削減を目的として、夜間と休日にNATゲートウェイを自動的に起動・停止させるLambdaを作成します。ただし、実装にあたっては、NATゲートウェイに関する知識をしっかりと持っておく必要があります。特に、NATゲートウェイは「起動」と「停止」ができず「作成」と「削除」しかできないため、注意が必要です。 また、NATゲートウェイの役割やElastic IPの割り当てについても理解しておくことが重要です。NATゲートウェイはプライベートリソースが外部にアクセスできるようにするもので、パブリックサブネットに設置されます。さらに、NATゲートウェイが動的に割り当てられるElastic IPを持つこと、及びその個数に上限があることも把握しておく必要があります。 NATゲートウェイに関連するルーティング設定も重要で、プライベートサブネットはデフォルトルートをNATゲートウェイに設定し、パブリックサブネットはインターネットゲートウェイに設定することが求められます。これにより、NATゲートウェイの作成や削除の際には、プライベートサブネットのルートテーブルのみを操作すれば良いことが理解できます。 Lambdaの実装においては、NATゲートウェイとルーティングの作成・削除の順序が重要であり、適切に待機処理を入れることが必要です。具体的には、Elastic IPの取得、NATゲートウェイの作成、ルーティングの設定といった処理を行います。これにより、既存のシステム構成を維持したままNATゲートウェイを操作することが可能になります。 最終的には、これらのLambdaをスケジューラで自動実行することで、夜間や休日にNATゲートウェイを効率的に管理し、コストを削減するシステムが構築できます。
## [NEM NIS1ノードを建ててみよう [夏休みの自由研究に]](https://qiita.com/curupo/items/84b1d3e76e1aef2e2f34)
夏休みの自由研究として、NEM NIS1ノードの構築に挑戦することを提案しています。必要なものは、自宅のインターネット光回線とLinuxが動くコンピュータ、さらにスーパーノードプログラムに参加する場合は10,001XEMが必要です。これに対して、LinuxやDockerの経験、NEM NIS1ノード構築の経験が得られ、スーパーノードプログラム参加報酬として1日1ドル程度のXEMが手に入ります。 未経験者にはハードルが高いかもしれませんが、先輩たちも同じ道を通ったことを思い出し、挑戦する価値があります。ノード構築にはポート開放が必要であり、具体的には7890（基本通信）、7778（Websockets用）、7891（必要ならhttps用）、7779（必要ならhttps用）、7880（スーパーノード用）を開放する必要があります。 Dockerのインストールはインターネット上の参考記事を使って行うことができます。準備として、まずは「nem」ユーザーを作成し、sudoグループに追加します。その後、Dockerグループにも追加し、設定を反映させるために再度ログインします。動作確認として、Dockerが正常に動作しているかを「docker run hello-world」でテストすることができます。 次に、nem-dockerを用いてノードを構築します。GitHubからリポジトリをクローンし、設定ファイルを自分の環境に合わせて修正します。具体的には、ホストのIPアドレスやNISブートキーを設定し、その後「boot.sh」を実行します。途中でエラーが出た場合は、コメントアウトで回避する方法が示されています。Dockerfileも自分の環境に合わせて修正し、再度起動します。 最後に、起動したサービスの状態を確認し、スーパーノードプログラムに参加する場合はサーヴァントを起動し、必要に応じて停止する方法も説明されています。参考文献として、GitHubのリポジトリや関連したQiitaの記事が提供されています。
## [ESXi上のAmazonLinux2023でNTP同期を無効化する](https://qiita.com/nw-engineer/items/05268f718378b8e1a7dc)
ESXi上でAmazon Linux 2023のNTP同期を無効化する手順について説明します。まず、OSの設定を変更するために、chronydとsystemd-timesyncdを無効化する必要があります。具体的には、`systemctl stop chronyd`と`systemctl stop systemd-timesyncd`を実行し、続けてそれぞれのサービスを無効にします。また、もしタイムゾーンがJSTに設定されている場合は、`timedatectl set-local-rtc 1 --adjust-system-clock`を実行しておくと良いでしょう。しかし、この段階では、dateコマンドを使用しても時刻がすぐに元に戻ってしまうため、次にESXiの設定を変更します。 ESXiの設定変更では、対象の仮想マシンの「設定の編集」を開き、「VMware Tools」のオプションから「ホストとゲスト時間を同期」のチェックを外します。Amazon Linux 2023はデフォルトでこの設定が有効になっているため、これを解除することが重要です。設定を保存した後、`date`コマンドで手動で時刻を変更します。例えば、`date -s "2024/07/19 10:00:00"`のように実行します。検証が完了したら、最終的に元の設定に戻すために、chronydとsystemd-timesyncdを再度有効化し、起動します。これにより、NTP同期の無効化が完了します。
## [EKS上にCiliumサービスメッシュを稼動させてみた!](https://qiita.com/daitak/items/9749c3c6d9c489351ef6)
EKS上でCiliumサービスメッシュを稼働させることに挑戦しました。CiliumはeBPFを活用してネットワーク接続を提供し、従来のサービスメッシュのサイドカーコンテナが不要なため、Pod間通信がシンプルになり、オーバーヘッドが減少します。これにより通信レイテンシが改善される多くの利点があります。Ciliumは、Cilium CNI、Cilium Service Mesh、Cilium Hubbleという3つの主要なコンポーネントから成り立っています。また、Ciliumは2023年にCNCFのGraduationプロジェクトに認定されており、本番システムでの稼働が可能な品質であることが確認されています。 このサンプルを実行するためには、AWSおよびKubernetes API Serverに接続できる端末が必要で、私はAWSコンソールからCloudShellを使用しました。また、AWS CLI、Terraform、kubectl、Cilium CLI、Helmの各CLIツールがインストールされている必要があります。公式サンプルのリポジトリをクローンし、Terraformを使ってEKSクラスタをデプロイしました。 次に、CiliumをEKSクラスタにインストールします。envoyフィルタを設定し、トラフィックシフティングのテストを行いました。具体的には、productcatalogPodから作成したServiceに対して10回連続でcurlコマンドを実行し、設定した割合に応じたレスポンスを確認しました。実行結果は、"version":"1"が7回、"version":"2"が3回で、設定した割合がうまく機能していることが示されました。 今回の実験を通じて、Ciliumを使用することで従来のkube-proxyやIngress Controllerが置き換わることが確認でき、非常に有意義な学びが得られました。さらに、Ciliumのオブザーバビリティ機能であるHubbleが、EKSクラスタのコンポーネントの大部分を置き換える可能性があることも実感しました。今後は、Ciliumの性能検証にも挑戦したいと考えています。
## [実況AI。ユーザーが選択したスポーツの架空の実況テキストを生成し、それをラジオ感覚で再生することができます。](https://qiita.com/tetsutakamurata76/items/ef59330aed0b483d6e55)
この文章では、開発者の佐藤が「実況AI」という革新的なプロジェクトに取り組む様子が描かれています。青空の広がる夏の日、佐藤は様々なスポーツの試合をリアルに実況し、音声で届けることができるAIの開発を進めていました。彼は10種類のスポーツ—アメリカンフットボール、野球、ボクシング、剣道、ラグビー、テニス、水泳、バスケットボール、サッカー、バレーボール—に対応できるようになったことを喜びました。 佐藤はAIモデルのトレーニングを終え、Gradioインターフェースを立ち上げ、ユーザーが簡単にスポーツを選んで実況テキストと音声を生成できる環境を整えました。彼は早速、野球を選んで生成ボタンをクリックすると、AIはリアルな実況を即座に生成し、音声に変換する機能を使ってMP3ファイルとして保存しました。生成された音声を再生すると、臨場感あふれる実況が流れ、まるで球場にいるかのような感覚を味わいました。 続いて剣道の実況を選んだ佐藤は、生成されたテキストを楽しみながらAIの精度に感動しました。彼は「これで多くの人が、自宅にいながら様々なスポーツの試合を楽しむことができる」と感じ、プロジェクトの進捗に満足感を覚えました。夜遅くまで作業を続けた彼は、明日も新しい挑戦が待っていることを考えながら、静かにパソコンを切りました。 このショートストーリーは、佐藤が「実況AI」プロジェクトに取り組む過程での喜びと興奮を表現しており、AIがリアルなスポーツ実況を生成して音声で届ける技術の開発に焦点を当てています。続いて実際の試合の実況が紹介され、ロッタス・マーリンズとサウルズ・レッドスの試合での状況や、ボクシングの試合における「マット」の戦い、サッカーチャンピオンシップ決勝の緊張感のある進行について説明されています。 さらに、コードの説明では、必要なライブラリのインストールやモデルの読み込み、実況テキストの生成を行うためのプロンプト設定、音声に変換する関数などの詳細が示されています。コードを実行することで、ユーザーはスポーツを選択し、それに応じた実況テキストと音声を生成して再生することができる仕組みです。
## [エンジニアのお悩み相談 AI。プロンプトを入力すると、アドバイスを生成し音声合成してくれるAIモデル。](https://qiita.com/tetsutakamurata76/items/e042f980cde2fcffe080)
エンジニアのお悩み相談AIをテーマにしたショートストーリーでは、近未来の都市ネオ・トーキョーで、技術が人々の生活を向上させている様子が描かれています。特に、「お悩み相談のアドバイザー」というアプリが注目されており、このアプリはユーザーが入力した悩みに対して、10人の専門家に扮したAIが様々な視点からアドバイスを提供します。専門家には、プログラマー、教師、牧師、僧侶、芸術家、歴史家など多様なキャラクターが用意されています。 物語の中で、主人公のマリコは、友人ユウジの仕事のストレスによる体調不良を心配し、このアプリを利用します。彼女は心理カウンセラーや弁護士、医者、ファイナンシャルプランナーのアドバイスを順に求め、数分後に生成されたアドバイスを音声で再生してユウジに聞かせる決意をします。 ユウジはアプリからのアドバイスに従って生活習慣を見直し、心のケア、法的問題の整理、健康改善、経済的安定を図る行動を開始します。その結果、数週間後には健康が改善し、ストレスも軽減され、彼は元気を取り戻します。マリコは彼の回復に喜び、アプリが実際の生活に変化をもたらす力を持つことを実感します。 この物語は、技術の進化が人々の悩みを解決し、希望をもたらす様子を描いています。また、アプリを利用することでより良い未来を作る手助けとなることを示しています。さらに、サンプルのお悩みとして、仕事のストレス、人間関係、健康問題などが挙げられ、それに対するアドバイスがどのように生成されるかが示されています。各キャラクターが特定の専門知識を持ち、それに基づいた具体的な助言を提供することで、ユーザーが実生活で役立てられるような内容となっています。
## [注文してから3.047190秒で出てきた。50倍速いぞ。Python time: 141.329512 seconds C++ time: 3.047190 seconds](https://qiita.com/tetsutakamurata76/items/94f6a0e3f31dba1b9505)
注文してから3.047190秒で出てきた結果から、C++はPythonに比べて約50倍速いことが示されています。具体的には、Pythonの実行時間が141.329512秒に対し、C++はわずか3.047190秒でした。この比較を行うためには、1から10億までカウントするためのC++とPythonのコードをそれぞれ実行する必要があります。 まず、C++のプログラムを作成するところから始めます。このプログラムは、1から10億までの数をカウントし、その実行時間を測定します。C++コードは、ファイルに書き込まれた後、コンパイルされ、実行されるという手順で進みます。また、Pythonのカウント処理も同様に実行され、時間を計測します。 このプロセスは、Python環境内でC++コードをコンパイルして実行できるように設計されており、両方の言語でのパフォーマンスを直接比較することが可能です。実際にGoogle Colabを使用して、これらのコードを検証しました。 C++コードは、標準出力を介して実行時間を表示し、Pythonの実行時間を計測した後に、両者の結果を比較して出力します。具体的には、C++のコードは高解像度クロックを使用して実行時間を測定し、Pythonはtimeモジュールを使用して同様の処理を行います。最終的に、C++による実行時間が取得され、Pythonに対してどれだけ速いかの比較がされます。 全体として、C++はPythonに比べて計算速度が圧倒的に速いことが証明され、特に大量のデータを処理するタスクにおいてその差が顕著であることが確認されました。
## [ORACLE PL/SQLとは　〜初学者向け入門編〜](https://qiita.com/yoshida_t/items/d4c0e3d8ed5fcac6bcec)
ORACLE PL/SQLについての入門編では、PL/SQLの基本的な知識を初学者向けに整理しています。この資料は、PL/SQLに関する文献が少ない現状を踏まえ、著者の実務経験をもとに自らの知識とネット上の情報を組み合わせて作成されました。著者はPL/SQLを1年3ヶ月使用しており、銀行系やリース決済システムに携わっています。目次には、PL/SQLの定義、用途、実務での使用法、基本構造、データ型、プロシージャ、ストアドプログラム、パッケージ、資料のまとめなどが含まれています。 PL/SQLはオラクル社が開発した手続き型言語で、非手続き型言語のSQLを拡張したものであり、複数のSQL文を同時に扱うことができます。特に銀行系や決算システムなどの大規模な数字を扱うシステムでよく使用されます。PL/SQLを使用することで、IF文を利用した分岐処理や、複数のSQL文やDML（更新、挿入、削除）を組み合わせた処理が可能になります。 実務的には、業務システムの画面操作やバッチプログラムの処理などにPL/SQLが利用されることが多いです。基本構造は、宣言部、実行部、例外処理の3つの部分からなり、SQL文を実行する際にはDECLAREで変数を宣言し、BEGINで実行を行います。例外処理は、実行中にエラーが発生した場合に対応する部分です。 ストアドプログラムはPL/SQLで記述された一連の処理を指し、主にプロシージャとファンクションに分けられます。プロシージャは戻り値を持たず、ファンクションは戻り値を持つのが特徴です。具体的な例として、引数を使ったファンクションや、戻り値を持つプロシージャの記述が示されています。 また、パッケージはPL/SQLの型や変数、サブプログラムをまとめたもので、関連する処理をグループ化することができます。最後に、PL/SQLは他のプログラミング言語に比べて人気はないものの、データベースとのやりとりが頻繁に行われるため、データベースに興味のある人にとっては習得しやすい言語であると強調されています。参考文献として公式の資料も示されています。
## [ElixirでCPUの周波数を取得をする](https://qiita.com/t-yamanashi/items/3d17a635164ac755c784)
Elixirを使用してCPUの周波数を取得するための手順が示されています。前提条件として、OSはUbuntu 22.04で、実行環境はLivebookです。具体的なソースコードでは、まず`/proc/cpuinfo`からCPU情報を読み込み、文字列を行ごとに分割した後、`cpu MHz`に関連する行だけをフィルタリングします。そして、フィルタリングされた結果を表示するために、各行を出力します。 結果として、さまざまなCPUの周波数が出力され、具体的には985.976 MHzから1100.007 MHzまでの値が見られます。これらの値の中には、800.000 MHzという周波数が複数回現れており、全体的にCPUのパフォーマンスに関する情報が得られる結果となっています。
## [ROSで座標を扱う方法(C++限定)(tf, tf2_ros, geometry_msgs)](https://qiita.com/nabeya11/items/daf968cc0491b20e3563)
ROSで座標を扱う方法についての解説がされています。まず、ROS(C++)では座標を扱うために主に2つの方法があり、一つはtf2_rosライブラリの型を使用する方法、もう一つはgeometry_msgsライブラリの型を使う方法です。tf2::Transform型とgeometry_msgs::TransformStamped型は異なるものであり、ノード内でのみ情報を扱う場合にはtf2_rosが便利です。一方で、別ノードから得た情報を扱う際や、座標変換を行う場合、または要素を単独で操作する場合にはgeometry_msgs系とdoTransform()を用いることが推奨されます。 オイラー角の入出力が必要な場合や、より複雑な操作を行う際には、Subscribeした情報をfromMsg()を使ってgeometry_msgsからtf2_rosに変換することが必要です。また、作業後にpublishする必要がある場合にはtoMsg()を使用してtf2_rosからgeometry_msgsに戻します。 tf2_rosライブラリに属する型はクラスであり、数学演算が直感的に行える一方で、特定の要素のみを扱うのは煩雑です。tf2::Vector3は座標点やベクトルを表現するために使用し、初期化や値のセット・読み出しが可能です。演算としては、ベクトル同士の加減算やスカラーとの乗算・除算が行えます。主に使えるメンバ関数には、ベクトルの大きさを求めるlength()や、normalize()が含まれます。 tf2::Quaternionは回転を表すために使用され、オイラー角からの初期化や値のセット・読み出しが可能です。演算としては、Quaternion同士の乗算ができ、回転の順番は重要です。主なメンバ関数としては、逆回転を行うinverse()が存在します。 tf2::Transformは位置と姿勢を表し、要素としてtf2::Vector3とtf2::Quaternionを含みます。これにより、回転行列を扱うことができ、姿勢の演算も可能です。主に使えるメンバ関数にはinverse()があり、逆変換が可能です。 一方、geometry_msgsライブラリは構造体としてメンバ関数がなく、要素を直接操作することができますが、数学的演算が定義されていません。よく使われる型にはPointやPose、Transform、Twistなどがあります。 geometry_msgsシリーズには座標変換のツールもあり、tf2::doTransformを用いて座標系の変換が行えます。変換行列はtf2_rosのBufferを使用し、lookupTransform()関数で取得します。座標変換の際は、source_frameとtarget_frameの指定に注意が必要です。 tf2とgeometry_msgs間の型変換はfromMsg()やtoMsg()関数を使用して行います。これにより、異なるROSノードからのデータを適切に扱うことが可能です。最後に、Pythonではtf2_rosが存在しないことも留意すべきポイントとして挙げられています。
## [WAKE Career オンラインイベント「iCARE/YOUTRUST/STORESの成長を支えるRailsアプリケーション開発の裏側」レポート](https://qiita.com/Mymt_aggw2208/items/4ef82d40a70749f610f6)
WAKE Careerのオンラインイベント「iCARE/YOUTRUST/STORESの成長を支えるRailsアプリケーション開発の裏側」について、みやもとがレポートをまとめました。彼はWAKE Communityのエバンジェリストに認定され、活動を応援するために応募したことを伝えています。エバンジェリストの役割については強制的な取り組みはなく、楽しんで共有することが重要だと考えています。 イベントでは、iCARE、YOUTRUST、STORESのエンジニアが参加し、LT（ライトニングトーク）とパネルディスカッションが行われました。主催のbgrass株式会社は「IT業界のジェンダーギャップを融かす」というミッションを掲げ、様々なサービスを提供しています。 最初のLTではiCAREの工藤氏が、健康管理システム「Carely」の技術課題と企業成長におけるCTOの役割を語りました。彼は技術的な課題による成長のボトルネックを防ぐため、継続的な改善が必要であると強調しました。Railsの利点として、技術的負債が少なく、豊富な事例があることを挙げました。 次にYOUTRUSTの寺井氏が、SNS特有のタイムライン機能における工夫を紹介しました。リスト取得方法のメリット・デメリットについて触れ、システム側の都合でユーザーが不利益を被ることを許容しない企業方針が印象的でした。 最後のLTではSTORESの今泉氏が、RubyとRuby on Railsのバージョンアップについて話しました。最新バージョンを常に使用する理由や運用方針について説明し、バージョンアップに関する様々な情報を共有しました。 その後、パネルディスカッションに移り、開発チームの構成やRubyの魅力について話し合いました。各社の開発チームは少人数制で連携している印象があり、Rubyの柔軟性やコミュニティの温かさが語られました。 イベントを通じて、Rubyに対する愛情や関心が強く感じられ、参加者の性別に関わらず魅力的なイベントであったことが特に印象に残りました。みやもとは、興味のある方にアーカイブ視聴を推奨し、登録ユーザーは過去のイベントを自由に視聴できることを伝えています。参加者は性別を問わず、イベントに気軽に参加できる環境が整っていることが強調されています。
## [勢いだけでAWS Certified Security - Specialty受けたら落ちた話](https://qiita.com/Jasmine_teeeeee/items/99e0802b1270c18817a3)
AWS Certified Security - Specialty (SCS-C02)を受験した体験についての記録です。受験に向けて、書店で購入した参考書を使って演習問題を3周し、さらにUdemyで約30問を解いたとのことです。受験者はAWS Certified Solutions Architect - Associate (SAA)の資格を保有しており、新しい問題を解く中で、過去に見たことのある問題が約20%含まれていると感じました。しかし、知らないサービス名も登場し、解いた問題については不正解の選択肢も調べて自信を持っていたものの、勉強量に対する不安がありました。その結果、試験には不合格となり、再度受験する予定です。次回までにUdemyの全問題を解く計画を立てています。再受験の詳細は今後発表される予定です。
## [AWS CloudFormationの最近の変更点 その2](https://qiita.com/a-shiosalt/items/0965895b9b19a6bb0af8)
AWS CloudFormationに関する最近の変更点についての詳細を以下に要約します。まず、「根本原因を検出」ボタンが2023年11月に追加され、スタックのイベントタブに表示されるようになりました。このボタンは、成功したスタックでは無効であり、押すことで原因と思われるイベントに「考えられる根本原因」が表示され、大量のイベントログの中から判別するのに役立ちます。 次に、AWS CloudTrailとの統合が2024年5月に行われ、スタックのイベントタブ内の「根本原因を検出」機能に「CloudTrailイベントを表示」リンクが追加されました。このリンクをクリックすると、CloudTrailのイベント履歴が表示され、特定の条件でフィルタ表示されますが、保存期間を過ぎたイベントは見つからない場合があります。 また、変更セットの可視性が向上し、2024年4月からは、スタックの更新前に追加・更新・削除対象となるリソースを確認できる機能が強化されました。具体的には、プロパティレベルの変更やポリシーアクションの列が追加され、変更内容の詳細を事前に把握することが可能になりました。 さらに、DeleteStack APIにDeletionModeが追加され、スタックの削除時に強制削除が可能になりました。このオプションを利用すると、リソースIDを指定せずにスタックを強制的に削除でき、削除に失敗した場合は「削除を再試行」オプションから強制的に削除することが選択できます。この際、状況の理由が記録されるようになりました。 スタックの作成ウィザードにおけるエラー表示も変更され、エラーメッセージが画面下に移動し、以前よりもわかりやすく表示されるようになりました。さらに、テンプレートのフォーマットエラー箇所も表示されるようになり、エラーの詳細を確認するのが容易になっています。 これらの変更は、AWSの「What's New with AWS?」ではアナウンスされていないことが多く、利用者にとっては改良点を意識する機会が少ないかもしれません。また、関連書籍「詳解 AWS CloudFormation」では、これらの変更点についても触れられており、特に「根本原因を検出」と「変更セットでの可視性向上」については記載されています。
## [Qiita投稿100本目指します](https://qiita.com/bisketoriba/items/1c51f63956f4ea3453a8)
Qiitaに投稿することを目指し、今後半年間でマインドを変えて本気で学習する決意を固めた大学生3年生のインターン生が、現状の課題を抱えていることを明かしています。普段はプログラミングを行っていますが、アプリを1から作るとなると手が止まってしまい、さまざまな技術のチュートリアルに手を出すことが多いため、スキルが定まらない状態にあると述べています。短期的には毎日学習内容を記事に投稿すること、中期的には大学で使えるサービスを開発すること、長期的にはメガベンチャー企業への就職を目指しています。これからはJISOUというコーチングサービスを利用し、アウトプットを重視した学習を行い、日々の開発で遭遇したエラーや学習した経験を記事で共有する予定です。
## [Sidekiq v7.3に導入されたSidekiq::IterableJobについて](https://qiita.com/hypermkt/items/b364d307567db4d1abf2)
Sidekiq v7.3に新たに導入されたSidekiq::IterableJobについて、まずはこの機能が長時間実行されるジョブを安全にデプロイできるようにすることを目的としていることが説明されています。この機能は、Sidekiqの開発者であるMike Perham氏が、以前から存在していたfatkodima/sidekiq-iterationというGemを基に提案し、最終的にSidekiq本体に取り込まれました。 具体的に、Sidekiq::IterableJobを使用することにより、長時間実行されるジョブの処理をループ内で分割し、任意のポイントで中断できるようになります。この機能は、特に大量のデータを処理する場合に有効で、例えばデータベース内の製品情報をループ処理する際に、エラーが発生した場合やデプロイがトリガーされた際に、最初から再開する必要がなくなります。 Sidekiq::IterableJobを使うには、performメソッドを実装するのではなく、build_enumeratorとeach_iterationの二つのメソッドを実装する必要があります。これにより、ジョブの繰り返し処理を設定し、各反復で実行される作業を定義できます。また、配列やActiveRecord::Relationに応じたヘルパーメソッドも用意されており、データの種類に応じて使い分けることが可能です。 さらに、便利なコールバックメソッドも提供されており、ジョブの開始、再開、停止、完了時にそれぞれ処理を行うことができます。ただし、この機能はまだBETA版として扱われていて、次のマイナーリリースまで本番環境での利用は控えるべきだとされています。 最後に、Sidekiq::IterableJobがどのように中断されるかについての説明があり、ジョブが中断される条件として、「quiet」状態や「shutting down」状態をトリガーにすることが明記されています。中断が検知されると、現在の状態をRedisに保存し、再エンキューされる際には最新のカーソルから再開できるようになります。これにより、ジョブの安全な中断と再開が可能となります。 総じて、Sidekiq::IterableJobはデプロイ時のジョブの安全な中断と再開、実行時間の最小化に貢献する機能として非常に有用であると考えられますが、BETA版であるため、次のマイナーリリースまでの利用を待つことが推奨されています。今後の発展に期待が寄せられます。
## [Phoenix Playground をWSL環境から使えるようにする](https://qiita.com/GeekMasahiro/items/eb7918eafd1ac62c6b77)
Phoenix PlaygroundをWSL環境で使用する際に直面した問題は、Livebookから実行すると起動できないことでした。その原因は、Phoenix Playgroundがxgd-openを使用してlocalhost:4000をブラウザーで開こうとするも、xdg-openが実行できずエラーが発生したことです。この問題を解決するためには、xdg-openを実行する際にWindows側のブラウザを起動するように設定を変更しました。具体的には、次の記事に記載された設定を行った結果、無事にPhoenix Playgroundのサンプルを開くことができました。
## [containerにおけるSELinuxの役割について](https://qiita.com/Gekko0114/items/4645c331bdcbf0235474)
YoukiにおけるSELinuxの導入を通じて、SELinuxの役割や機能についての理解が深まった。YoukiはRustでruncを再実装するオープンソースプロジェクトであり、本家のruncには存在するSELinux関連機能がYoukiには未実装であった。そのため、Rust向けのSELinux crateの再実装が決定し、私がそのプロジェクトに参加することになった。しかし、当初はSELinuxに関する知識が全くなかったため、様々な情報を調査しまとめることにした。 SELinuxとは、「Security-Enhanced Linux」の略で、Mandatory Access Control（MAC）を実施するための技術である。SELinuxを設定することで、通常のセキュリティ機能に加えてシステムのセキュリティをさらに強化でき、ラベルとポリシーを組み合わせたセキュリティ制御が特徴的である。この仕組みにより、プロセスやファイル、ネットワークなどのオブジェクトにラベルが付与され、セキュリティポリシーに基づいてアクセスが制御される。 SELinuxの主なメリットは、ラベルを用いたルール設定により、ルート権限を考慮する必要がないことだ。これにより、権限昇格攻撃のリスクを軽減し、プロセスやファイルが互いに分離されるため、万が一プロセスが侵害されても被害を抑えることができる。また、管理者がアクセス制御を行うため、一般ユーザーに変更される心配がなく、ウイルス対策ソフトとは独立した機能としてOSの安全性を向上させる。 SELinuxの動作モードには、Enforcing（SELinux有効、ルール外の動作を全て停止）、Permissive（SELinux有効、ルール外の動作をログに記録）、Disable（SELinux無効）があり、これらは設定ファイルを通じて変更できる。SELinuxが有効な場合、特定のディレクトリにSELinuxファイルシステムがマウントされ、ポリシーや状態管理が行われる。 ラベルは、「User:Role:Type:level」という4つの部分から構成され、具体的にはユーザーごとのラベル、役割名、ドメインやオブジェクトのタイプ、MLSやMCSに利用される属性が含まれる。ドメイン間のアクセス制御は、ポリシー規則に基づいて行われ、特定のドメインに制約されないunconfinedドメインも設定可能である。 さらに、SELinuxは標準のファイル属性に加え、メタデータをファイルに格納するためのxattr（拡張属性）を使用し、セキュリティラベルを設定する。プロセスに関する情報はprocfsに保存され、SELinuxのルールは、特定のクラスに対するアクセスを制御する形で定義される。 Dockerやコンテナ環境におけるSELinuxの使用方法については、ホストとコンテナ間の保護に利用され、特にtype enforcementとMCS（Multi-category Security）分離が重要な役割を果たす。Dockerでは、SELinuxがデフォルトで有効化されていないため、ユーザーが明示的に設定を変更する必要がある。 MCS分離機能により、コンテナごとにユニークな値が付与され、プロセスのMCSラベルはアクセスするファイルのMCSラベルと対応する必要がある。複数のカテゴリを推奨されるため、ラベルの設定には注意が必要である。 最後に、go-selinuxというプロジェクトがSELinux機能のサポートを行っており、コンテナ関連のプロジェクトがSELinux機能を利用するためのOSSとして機能している。また、このレポジトリの機能は現在R