並び順

ブックマーク数

期間指定

  • から
  • まで

81 - 120 件 / 216件

新着順 人気順

ベストプラクティスの検索結果81 - 120 件 / 216件

  • 大規模システムにおける5つのログ転送パターン

    成功者がどのようにNew Relicを使用してKubernetesのパフォーマンスを4倍に向上させ、拡張性とスループットを改善したかをご覧ください。

      大規模システムにおける5つのログ転送パターン
    • GitHub、“Open Source Guides”の日本語訳を公開 ~OSSコミュニティのベストプラクティスを集約/オープンソース入門者だけでなく、すでに貢献をしている開発者にも

        GitHub、“Open Source Guides”の日本語訳を公開 ~OSSコミュニティのベストプラクティスを集約/オープンソース入門者だけでなく、すでに貢献をしている開発者にも
      • http://alanpryorjr.com/2019-05-20-flask-api-example/

          http://alanpryorjr.com/2019-05-20-flask-api-example/
        • AWSにおけるアプリケーションのログ記録のベストプラクティス - Qiita

          はじめに アプリケーションログは、アプリケーションの動作状況をログファイルに記録するプロセスです。アプリケーションよって、この動作状況は1つ以上のファイルに記録することが多いです。このログファイルは、セキュリティとパフォーマンスの分析の実行、アプリの問題のトラブルシューティングなどに役立ちます。この記事では、ログ、ログの種類およびAWSのCloudwatLogsサービスについて説明したいと思います。 各個人によって好きなAWSサービスがそれぞれだと思います。これが正解という訳ではありませんが、参考にしてただければと思います。 対象者 AWSでログの記録に興味がある方。 AWSでワークロードを運用している担当者。 ログレベル ログレベルについて皆さんご存じだと思いますが、主に3種類のログがあります。 レベル 説明

            AWSにおけるアプリケーションのログ記録のベストプラクティス - Qiita
          • 継続的なソフトウェア・アップデートのためのDevOpsベストプラクティス・アンチパターン / DevOps Patterns and Antipatterns for Continuous Software Updates

            Cloud Native Days Tokyo 2020

              継続的なソフトウェア・アップデートのためのDevOpsベストプラクティス・アンチパターン / DevOps Patterns and Antipatterns for Continuous Software Updates
            • JavaScriptの非同期処理をじっくり理解する (4) AbortSignal, Event, Async Context

              対象読者と目的 非同期処理の実装方法は知っているが、仕組みを詳しく知らないのでベストプラクティスがわからないときがある 実行順序の保証がよくわからないので自信をもってデプロイできない変更がある より詳しい仕組みを理解することでより計画的な実装をできるようになりたい という動機で書かれた記事です。同様の課題を抱える人を対象読者として想定しています。 目次 実行モデルとタスクキュー Promise async/await AbortSignal, Event, Async Context WHATWG Streams / Node.js Streams (執筆中) 未定 中止処理 並行処理ではしばしば実行中の処理を中止したい場合があります。 古典的なキャンセル処理 Webブラウザ/Node.jsともに、 setTimeout の中止が可能です。 const timeout = setTimeo

                JavaScriptの非同期処理をじっくり理解する (4) AbortSignal, Event, Async Context
              • セキュリティを重視した開発手法ベストプラクティス

                モバイルアプリケーションから大規模な金融機関のインフラストラクチャーまで、ソフトウェアの構築方法は急速に進化しており、セキュリティは開発者が最初から考慮するものとなりました。開発のペースが速まると、セキュリティ侵害のリスクが大きくなります。セキュリティに気を使っている大企業でさえ、公開されているソースコードにパスワードを残したり、お客様の個人データを漏洩したり、明らかに脆弱性があるのに重要なアプリケーションを本稼働させたり、といったことは珍しくありません。多くの企業が新しいソフトウェアをいち早くリリースしようと懸命になり、ソフトウェアの安全性を保つことに苦労しています。 このように、企業におけるソフトウェア開発は迅速な作業とセキュアな構築の両立が課題になっています。新しい開発手法はコードをより早く市場に投入できますが、不適切なツールやプロセスを使うと、セキュリティが不十分になりかねません。

                  セキュリティを重視した開発手法ベストプラクティス
                • 【アップデート】AWS Security Hub の『基礎セキュリティのベストプラクティス』に新たに25個のチェック項目が追加されました | DevelopersIO

                  【アップデート】AWS Security Hub の『基礎セキュリティのベストプラクティス』に新たに25個のチェック項目が追加されました はじめに みなさん、セキュリティチェックしていますか?(挨拶 AWS Security Hub の『AWS 基礎セキュリティのベストプラクティス v1.0.0』に新たに 25個のチェック項目(コントロール)が 追加されました。AWS公式も以下のようにアナウンスしています。 この新しいチェック項目は Security Hub の [設定 > 一般 > 新しいコントロールの自動有効化] を ON に していると自動的に追加されます。 いつのまにか CRITICAL/HIGH の項目で失敗していて、大量に通知が飛んできた方もいらっしゃるかもしれません。 本ブログで新規追加されたコントロールを簡単なコメント付きで紹介していきます。 (コントロールの題目はまだ日本

                    【アップデート】AWS Security Hub の『基礎セキュリティのベストプラクティス』に新たに25個のチェック項目が追加されました | DevelopersIO
                  • AWS Organizations における組織単位のベストプラクティス | Amazon Web Services

                    Amazon Web Services ブログ AWS Organizations における組織単位のベストプラクティス AWS のお客様は、新しいビジネスのイノベーションを生み出す際に、迅速かつ安全に行動できることを求めています。マルチアカウントフレームワークは、お客様に合ったAWS 環境を計画するのに役立つガイダンスを提供します。このフレームワークは、変化するビジネスニーズに合わせて環境の拡張と適応能力を維持しながら、セキュリティのニーズを満たすように設計されています。適切に設計されたマルチアカウントの AWS 環境の基礎は AWS Organizations です。これは、複数のアカウントを一元的に管理および管理できる AWS サービスです。 この記事では、AWS環境の構築を検討する際に役立つAWS のベストプラクティスに基づいたアーキテクチャについて詳細に説明します。推奨される組織

                      AWS Organizations における組織単位のベストプラクティス | Amazon Web Services
                    • [Rust] モジュールのベストプラクティス

                      Rust のモジュールシステムは私の知る中でもトップクラスによくできた仕組みだと思います。特にリファクタリングによってモジュールを再構成するときのやりやすさは他の言語では経験できないものです。例えばそれなりの規模の Python プロジェクトを回帰バグを導入せずにモジュール構造のリファクタリングするのは不可能に近いですが、 Rust ではそのような不安を覚えたためしがありません。 Rust のモジュールシステムがどういうものかは、 The book にも書かれていますし、すでに大量のガイドが書かれていると思います。しかし、どのように使うべきかについては意外なほど情報が少なく感じます。 ベストプラクティスというのもおこがましいですが、数年使ってきて Rust のモジュールシステムを使う上でスムーズに感じる方法をまとめておきたいと思います。 Rust のモジュールシステム 本稿の主題はモジュー

                        [Rust] モジュールのベストプラクティス
                      • Terraform を使用するためのベスト プラクティス  |  Google Cloud

                        フィードバックを送信 Terraform を使用するためのベスト プラクティス コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このドキュメントでは、複数のチームメンバーやワーク ストリームで Terraform を使用した効果的な開発を行うためのガイドラインと推奨事項について説明します。 このガイドでは Terraform の概要は説明しません。Google Cloud で Terraform を使用する方法については、Terraform を使ってみるをご覧ください。 スタイルと構造に関する一般的なガイドライン 以下の推奨事項は、Terraform 構成の基本スタイルと構造を対象としています。この推奨事項は、再利用可能な Terraform モジュールとルート構成に適用されます。 標準のモジュール構造に従う Terraform モジュールは、標準のモジュ

                          Terraform を使用するためのベスト プラクティス  |  Google Cloud
                        • Microsoft、パスワードの有効期限のベストプラクティスを見直し

                          ユーザーが実践できているかどうかは別として、サイバー攻撃で悪用されにくいパスワードを作成・運用するためのベストプラクティスはいくつもある。そのひとつに「パスワードを定期的に変更する」がある。IT部門が存在する企業では、ユーザーに定期的なパスワードの変更を強要しているケースも少なくない。しかし、このベストプラクティスはしばらくすると候補から外れるかもしれない。 The Hacker Newsは5月10日(米国時間)、「Is it still a good idea to require users to change their passwords?」において、企業はおそらく初めて、パスワードの定期的な変更を要求することがよいアイデアであるかを検討する必要に迫られていると伝えた。なぜなら最近、Microsoftが同社のパスワードに関するベストプラクティスを変更したためだ。同社の最新のパスワー

                            Microsoft、パスワードの有効期限のベストプラクティスを見直し
                          • A/Bテストのベストプラクティスと落とし穴 ~KDD2019 レポート~ - Gunosyデータ分析ブログ

                            はじめに 研究開発チームの関です。古川未鈴さんの結婚、ニジマス大門果琳さんの卒業、uijinの解散とアイドル業界も激動の秋を迎えていますね。 2019年8月4日から5日間、アメリカはアラスカ州アンカレッジで開催されたデータマイニング領域のトップカンファレンスであるKDD2019にGunosyから北田と関が参加・発表してきました。 これまでに2つのレポートを公開しています。 data.gunosy.io data.gunosy.io 本レポートではTutorialとして開催された「Challenges, Best Practices and Pitfalls in Evaluating Results of Online Controlled Experiments」の内容をレポートします。 内容は現在のA/Bテストのガイドラインと言ってもいい内容で、非常に参考になるポイントが多かったです。

                              A/Bテストのベストプラクティスと落とし穴 ~KDD2019 レポート~ - Gunosyデータ分析ブログ
                            • Best Practices | Playwright

                              Introduction​ This guide should help you to make sure you are following our best practices and writing tests that are more resilient. Testing philosophy​ Test user-visible behavior​ Automated tests should verify that the application code works for the end users, and avoid relying on implementation details such as things which users will not typically use, see, or even know about such as the name o

                                Best Practices | Playwright
                              • Next.jsにおけるenvのベストプラクティス

                                Next.js で env をうまく扱うために僕がよく使う手法を紹介します。 Next.js がサポートしている env の扱い Next.js はデフォルトで大きく 2 つの方法で env をサポートしています。 .env ファイルの読み込み next.config.js の env キーに記述する .env ファイルの読み込み Next.js は .env ファイルを配置することで process.env に読み込む機能をデフォルトでサポートしています。なのでプロジェクトのルートに、以下のようなファイルを配置してください。

                                  Next.jsにおけるenvのベストプラクティス
                                • Elasticsearch における類似度ベクトル検索のベストプラクティスを求めて/es-vector-search

                                  Cookiecutter Template for Data Scientists Working in Docker Containers

                                    Elasticsearch における類似度ベクトル検索のベストプラクティスを求めて/es-vector-search
                                  • AWS におけるマルチアカウント構成の動向 - 理系学生日記

                                    AWS で環境を構築する際はマルチアカウントになることが多い、これは理解していたつもりでした。 stg 環境と prod 環境は AWS アカウントごと分ける。dev 環境も分ける。 しかし、世の中のベストプラクティスはもっと先を行っていました。 なぜアカウントを分けるのか isolation authz & authn auditing and reporting 世の中のマルチアカウント構成 各企業の事例 AWS が提供するベストプラクティス Gruntwork から見た AWS ベストプラクティス 各社のプラクティスから読み取れること なぜアカウントを分けるのか AWS アカウントを分ける理由は 3 つあります。 isolation authz & anthn auditing and reporting isolation そもそもとして、環境は分離しないと、というものです。 st

                                      AWS におけるマルチアカウント構成の動向 - 理系学生日記
                                    • オープンソースのベストプラクティスを企業内で実践/How to implement InnerSource

                                      Developers Summit 2021の「オープンソースのベストプラクティスを企業内で実践 ~インナーソースのすすめ」というセッションの発表資料です。 https://event.shoeisha.jp/devsumi/20210218/session/3044/

                                        オープンソースのベストプラクティスを企業内で実践/How to implement InnerSource
                                      • Pythonのパッケージ管理ベストプラクティス - Qiita

                                        ※おすすめの基準には上記「導入の手軽さ」「学習の手軽さ」「パッケージ依存関係の解決」以外に、「対象OSとの相性」「検索による情報の見つかりやすさ」を考慮しています。詳しくは後述します 筆者の主観が入りますが、概ね以下のフローチャートのように選択すると良いかと思います (詳しくは後述します) なお、実用上ハマりやすいプロキシ環境での使用方法についても、以下の記事に別途まとめました 必要知識 ここから先は、Pythonのパッケージ管理が何をやっているかを解説します。 「御託はいいから早く使いたい!」という方は、「3種類の方法比較」の項目まで飛んでください まず、一般的に「パッケージ管理」と呼ばれている要素を、以下の4つの機能に分割して考える必要があります。 A. インタプリタ切替 (Pythonのバージョンを切り替える) B. パッケージ切替 (パッケージのバージョンを切り替える) C. パッ

                                          Pythonのパッケージ管理ベストプラクティス - Qiita
                                        • クリーンなReactプロジェクトの21のベストプラクティス - Qiita

                                          コード品質向上のための実践的アドバイス Photo by Diana Polekhina on Unsplash. はじめに Reactは、構成の方法について特に決まりがありません。まさにこれが理由で、プロジェクトをクリーンで保守可能な状態に保つことは、私たちの責任なのです。 今日は、Reactアプリケーションの状態を改善するために従うべきベストプラクティスについて説明します。これらのルールは広く受け入れられているため、この知識を持つことは必須です。 すべてコードで示します。さあ始めましょう! 1. JSXの省略形を使用する ブール変数の受け渡しには、JSXの省略形を使うようにしましょう。例えば、Navbarコンポーネントのタイトルの可視性を制御するとします。 悪い例

                                            クリーンなReactプロジェクトの21のベストプラクティス - Qiita
                                          • モダンなシステムにSLI/SLOを設定するときのベストプラクティス

                                            New RelicではどのようにSLI/SLOを定義し、SREを実践しているか。その経験から、SLI/SLOについて解説した記事 Best Practices for Setting SLOs and SLIs For Modern, Complex Systems の翻訳です。 -- New Relicのサイト信頼性VPであるMatthew Flamingも、この記事に貢献しています。この記事はサンフランシスコその他で行ったFutreStack18での講演「SLOs and SLIs In The Real World: A Deep Dive.」をもとに作られています。 New Relicでは、サービスレベル指標(Service Level Indicator: SLI)とサービスレベル目標(Service Level Objective: SLO)を定義したり設定したりことが、サイト

                                              モダンなシステムにSLI/SLOを設定するときのベストプラクティス
                                            • Elasticsearchを用いて類似度ベクトル検索をやってみてわかったこと

                                              2019年7月31日、検索技術研究会が主催するイベント「Search Engineering Tech Talk 2019 Summer」が開催されました。「検索」や「検索システム」にまつわる技術や手法を共有する本イベント。第3回となる今回は、3人のエンジニアが、現場の経験を通して学んだノウハウや、検索にまつわる知見を語ります。プレゼンテーション「Elasticsearch における類似度ベクトル検索のベストプラクティスを求めて 」に登壇したのは、伊藤敬彦氏。講演資料はこちら Elasticserchにおける類似度ベクトル検索のベストプラクティスを求めて 伊藤敬彦(@takahi_i) 氏(以下、伊藤):「Elasticserchにおける類似度ベクトル検索のベストプラクティスを求めて」ということで、いろいろ調査をしてみましてとりあえずまとめてみましたというお話です。 シュッとやると最初は書

                                                Elasticsearchを用いて類似度ベクトル検索をやってみてわかったこと
                                              • AWS Well-Architected Toolが日本語をサポートしました(東京リージョンでご利用いただけます) | Amazon Web Services

                                                Amazon Web Services ブログ AWS Well-Architected Toolが日本語をサポートしました(東京リージョンでご利用いただけます) 私たちが、2015年に発表したAWS Well-Architected フレームワークは、クラウドにおけるシステム設計・構築・運用において、設計原則と「運用の優秀性」「セキュリティ」「信頼性」「パフォーマンス効率」「コストの最適化」の5つの柱を使用して、ガイダンスとベストプラクティスを提供するものです。 さらに2018年にはAWS Well-Architected Toolをリリースし、お客様のワークロードがAWSアーキテクチャの最新ベストプラクティスに則っているか、どのようなギャップがあって、どのようなリスクや改善点があるかを自分自身でご確認いただけるようになりました。このツールは昨年のリリース以降、すでに世界中で何万ものワー

                                                  AWS Well-Architected Toolが日本語をサポートしました(東京リージョンでご利用いただけます) | Amazon Web Services
                                                • DockerでRUNをまとめた方が良いとは限らない | フューチャー技術ブログ

                                                  TIG/DXの渋川です。 ソフトウェアの世界では、ツールや言語の進歩があって、もはや古い知識になっているにも関わらず、古い知識がベストプラクティスと呼ばれて蔓延し続けている例があります。Dockerだと「RUNをまとめよう」というのがそうです。かつてはこれは常に行うべきプラクティスでしたが、現代だとそうじゃないケースもあり、デメリットもあります。 https://www.docker.com/company/newsroom/media-resources 1. ただファイルが増えるだけのケースであれば気にしなくていい次の2つのファイルで実験してみます。ベースイメージに、10MBのファイルを作成するコマンドをふたつ並べたものです。 FROM debian:bullseye-slim RUN dd if=/dev/zero of=dummy1 bs=1M count=10 RUN dd if

                                                    DockerでRUNをまとめた方が良いとは限らない | フューチャー技術ブログ
                                                  • Reactのユニットテスト2021

                                                    React でユニットテストをするときのベストプラクティスはいつも悩むのですが、とりあえず 2021 年 2 月時点では、こうかなーというのをまとめてみます。 まずテストランナーは jest で確定です。ここで悩む要素はまずありません。 では、React のテストをどうやるか?です。 公式の react-dom/test-utils を使う 公式の react-test-renderer を使う @testing-library/react を使う 選択肢としてはこの三種類が有名なところでしょう。 公式という響きはとても魅力的ですが、実は公式ドキュメントから「ボイラープレートを減らすため、エンドユーザが使うのと同じ形でコンポーネントを使ってテストが記述できるように設計されている、React Testing Library の利用をお勧めします。」という形で、@testing-library

                                                      Reactのユニットテスト2021
                                                    • Dockerfileの属人化による脆弱性を防げ ベストなイメージが作成可能なCloud Native Buildpacksの使い方

                                                      クラウドネイティブ技術を日本にも浸透させることを目的に開催された「CLOUDNATIVE DAYS Spring 2021 ONLINE」。ここでVMwareの伊藤氏が「脱 Dockerfile! Cloud Native Buildpacksとkpackを使った簡単で安全なイメージ」をテーマに登壇。まずは、Dockerfileの問題点とCloud Native Buildpacksについて紹介しました。 トーク内容の目次 伊藤裕一氏(以下、伊藤):「脱 Dockerfile! Cloud Native Buildpacksとkpackを使った簡単で安全なイメージ」という内容について、伊藤がお話しします。 目次です。最初にDockerfileのおさらいと、問題点を話します。そして、Dockerfileを使わずにビルドを実施するCloud Native Buildpacks(CNB)の概要と

                                                        Dockerfileの属人化による脆弱性を防げ ベストなイメージが作成可能なCloud Native Buildpacksの使い方
                                                      • Terraformアンチパターン(2019年版) - Qiita

                                                        はじめに Infrastructure as Code(以下IaCと略します)って最近では当たり前のように実践されてますよね。特にterraformはかなりユーザが多く、開発のスピードも速い印象です。 IaCを実現できたインフラエンジニアの皆さんの多くが次に直面する問題はコードの保守運用に関する事柄ではないでしょうか? terraformもコードなので、アプリケーションのコードと同じように保守性(テスト容易性、理解容易性、変更容易性)を意識する必要があります。ただコード化しただけでは属人性を排除したとは言えないと思います。 保守性の高いterraformって具体的にどう書けばいいの?と周りに聞いてみても、巷には「ぼくのかんがえた最強のterraformベストプラクティス」が乱立していて、自転車置き場の議論になりがちです。 また、v0.12前後でterraformの記法が大きく変わったので、

                                                          Terraformアンチパターン(2019年版) - Qiita
                                                        • Best practices for using the Terraform AWS Provider - AWS Prescriptive Guidance

                                                          Michael Begin, Senior DevOps Consultant, Amazon Web Services (AWS) May 2024 (document history) Managing infrastructure as code (IaC) with Terraform on AWS offers important benefits such as improved consistency, security, and agility. However, as your Terraform configuration grows in size and complexity, it becomes critical to follow best practices to avoid pitfalls. This guide provides recommended

                                                          • よりよいCLIプログラムを書くためのCLI Guidelines

                                                            Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...

                                                              よりよいCLIプログラムを書くためのCLI Guidelines
                                                            • AWS環境にセキュアなベースラインを提供するテンプレート「Baseline Environment on AWS」のご紹介 | Amazon Web Services

                                                              Amazon Web Services ブログ AWS環境にセキュアなベースラインを提供するテンプレート「Baseline Environment on AWS」のご紹介 みなさんこんにちは。ソリューションアーキテクトの大村です。 このブログでは、私たちAWS Japanのソリューションアーキテクトが AWS Samples に公開している 「Baseline Environment on AWS(BLEA)」について詳しくご紹介します。 これはAWSのセキュリティのベストプラクティスを実装した環境を、迅速に実現するためのテンプレートです。 セキュリティサービスだけでなく、よく利用されるアプリケーションの実装サンプルも含んでいます。これによって基本的なセキュリティを実現した状態をスタート地点としてシステム構築を開始できます。このテンプレートは単一のアカウントでも、また AWS Contro

                                                                AWS環境にセキュアなベースラインを提供するテンプレート「Baseline Environment on AWS」のご紹介 | Amazon Web Services
                                                              • Dockerfileのベストプラクティス - Qiita

                                                                業務やプライベートでのハンズオンを通して得た知見を元に、dockerfileの実践的な書き方を記載いたしました。 軽量なdocker imageを作る観点とセキュリティーの観点を踏まえた内容になっております。なにか付け足す点などあればコメントいただければと思います。 軽量なimageを作る観点 軽量なimageの使用 Dockerfileでimageを指定する際に、軽量なimageを使用することが進めれている。 docker docsでも代表的な軽量なimageのalpineをおすすめしている。 Whenever possible, use current official images as the basis for your images. We recommend the Alpine image as it is tightly controlled and small in s

                                                                  Dockerfileのベストプラクティス - Qiita
                                                                • Microsoftセキュリティチーム、「Azure」で仮想マシンを保護するためのベストプラクティスを紹介

                                                                  Microsoftのセキュリティインシデントレスポンスチームは2020年10月7日(米国時間)、クラウドセキュリティに関するベストプラクティスを紹介した。 Microsoftの検知/対応チーム(DART)とカスタマーサービスサポート(CSS)のセキュリティチームはユーザーのインシデントを調査する際、インターネットから攻撃を受けた仮想マシン(VM)を目にすることが多いのだという。 クラウドセキュリティの責任共有モデルでは、クラウドプロバイダーとユーザーがどのレイヤーに責任を持つのか理解しておく必要がある。 今回のベストプラクティスでは、クラウドプロバイダーと顧客の責任共有モデルが適用される対象の1つとしてVMを取り上げ、「Microsoft Azure」でVMを含むワークロードを保護するための7つの手法を紹介した。 (1)Azure DefenderのAzureセキュリティスコアをガイドとし

                                                                    Microsoftセキュリティチーム、「Azure」で仮想マシンを保護するためのベストプラクティスを紹介
                                                                  • Introducing Dockercast – the Docker Podcast | Docker Blog

                                                                    Products Docker DesktopContainerize your applicationsDocker HubDiscover and share container imagesDocker ScoutSimplify the software supply chainDocker Build CloudSpeed up your image buildsTestcontainers Desktop Local testing with real dependenciesTestcontainers Cloud Test without limits in the cloud See our product roadmapMORE resources for developers

                                                                      Introducing Dockercast – the Docker Podcast | Docker Blog
                                                                    • AWSのマルチアカウント戦略ってなに?なぜ必要?【社内勉強会スライド】 | DevelopersIO

                                                                      社内勉強会で AWSのマルチアカウント戦略について話しました。 使ったスライドを公開しています。 構成は以下のようになっています。 マルチアカウントでよく出てくる用語や考え方を説明しました。 #1 マルチアカウント戦略が必要な理由 #2 マルチアカウント戦略 と AWS Organizations の位置付け #3 ランディングゾーンってなに? (それと AWS Control Tower) 少しでも参考になれば幸いです。 参考 マルチアカウント戦略 / AWS Organizations AWSにおけるマルチアカウント管理の手法とベストプラクティス | AWS 20210526 AWS Expert Online マルチアカウント管理の基本 | SlideShare AWS Organizations とは | AWS Organizations AWS Organizations で使

                                                                        AWSのマルチアカウント戦略ってなに?なぜ必要?【社内勉強会スライド】 | DevelopersIO
                                                                      • ようこそ | ja 🇯🇵 | docs

                                                                        GitHub Copilot パターン&エクササイズ のドキュメンテーションへようこそ! 👋 このコミュニティ駆動のオープンソースガイドは、GitHub Copilot のベストプラクティスを提供することに専念しています。 あなたのプロジェクトにこれらの慣行を理解し、評価し、統合するのを簡単にすることが私たちの目的です。 🚀 `�抌U このドキュメントは、開発者がGitHub Copilotや他のAI駆動のツールをより良く使用するのを助けるために、GitHubのカスタマーサクセスアーキテクト @yuhattor によって提供されています。 GitHubの公式ドキュメントではなく、個人やコミュニティの意見が反映されたコミュニティドキュメントとしての特性を持ちます。 ぜひコントリビューションをして、あなたの意見もこの本に反映させてください。 これらのパターンの一部は個々の環境で効果が実証さ

                                                                          ようこそ | ja 🇯🇵 | docs
                                                                        • AWS黎明期のベストプラクティスを改めて読み返すことで、クラウドのためのアーキテクチャー大原則を再確認する | DevelopersIO

                                                                          西澤です。最近AWSの進化が凄まじすぎて、そもそもついていけない選択肢が多すぎるし、設計難しいよなーって思うことが増えています。もうAWS上で動かすことができないシステムはほぼ無くなりつつあるのが現状だとは思いますが、それでもやはりクラウドとの親和性が高いシステムとそうでないシステムがあることも事実だし、そもそもの大原則を復習することで、本来想定されていたあるべき姿を抑えておくことには意味があるんじゃないかと考えています。そこで、私が初めてAWSを知ったときに衝撃を受けた資料を読み返してみたところ、シンプルで非常に重要な原則が書かれていることを再確認できたので、ここで改めてご紹介したいと思いました。 ご紹介したい資料 私がクラスメソッドにジョインしたときに書いたブログでもご紹介させていただいたのですが、今回ご紹介するのは、当時AWSのエバンジェリストだった玉川さん、ソリューションアーキテク

                                                                            AWS黎明期のベストプラクティスを改めて読み返すことで、クラウドのためのアーキテクチャー大原則を再確認する | DevelopersIO
                                                                          • 徹底解剖 TLS 1.3 | 翔泳社

                                                                            wolfSSLをもとに、SSL/TLSの正しい利用法と仕組みを理解する 暗号化された安全な通信は、ネットワークを使う全てのアプリケーションにとって、 考慮すべき重要な課題です。 セキュアな通信を実現するために用いられる技術SSL/TLSの最新版がTLS 1.3であり 各種SSLライブラリも対応してきています。 ただ、ライブラリだけが最新のものになっても、仕組みを知り、 正しく使わなければ、安全は担保されません。 そこで本書は、そんなTLS 1.3の基礎的なプロトコルの流れから、 暗号化・認証の仕組み、アプリケーション実装のベストプラクティスを 組み込みシステム向けの軽量&高機能なライブラリwolfSSLを例に 解説していきます。 さらに、ライブラリコードの解説を含め、内部実装にまで踏み込んだ解説も行い、 SSLライブラリを徹底的に理解できる一冊です。 Part 1:TLSの技術 ・Chap

                                                                              徹底解剖 TLS 1.3 | 翔泳社
                                                                            • GitHub Organizationの安全な運用とモニタリングに関するスライド(全44ページ)を無償公開しました - Flatt Security Blog

                                                                              はじめに こんにちは、株式会社Flatt Securityプロダクトマネージャーの小島です。Shisho Cloud というソフトウェアサプライチェーンに関するセキュリティ上の問題の発見から修正までを包括的にサポートする開発者向けセキュリティツールを開発しています。 shisho.dev 本日はこのサービスに関連して、GitHub Organizationを安全に運用していくためのベストプラクティス、そしてそのベストプラクティスがきちんと開発組織の中で運用されているかをモニタリングする方法についてまとめたスライドを公開しました。 スライドは下記のSpeakerdeckのURLより無料/登録不要で閲覧/ダウンロードいただけます。 https://speakerdeck.com/flatt_security/2022-github-org-best-practices この記事では、そのスライ

                                                                                GitHub Organizationの安全な運用とモニタリングに関するスライド(全44ページ)を無償公開しました - Flatt Security Blog
                                                                              • なるべく楽したいAWSセキュリティ

                                                                                Leaner 開発チームの黒曜(@kokuyouwind)です。 先日開催された AWS Starup Community スタートアップ事例祭り 〜監視・モニタリング・セキュリティ編〜 に登壇させていただき、「なるべく楽したい AWS セキュリティ」と題して Leaner Technologies での AWS セキュリティ設定事例を紹介しました。 今回は発表内容のポイントとともに、発表で省いた話をいくつか記事にまとめていきます。 発表スライド 口頭での補足を前提としたスライド構成になっているため、スライドのみだと少々分かりづらい部分があります。 発表時の動画がアップロードされているので、そちらをご覧いただくとよりわかりやすいです。 発表内容のおおまかなまとめ スライドだけだと分かりづらいし、動画だと見るのに時間がかかるなぁ… という方もいそうなので、発表内容のポイントを以下にまとめます

                                                                                  なるべく楽したいAWSセキュリティ
                                                                                • 私が Azure Functions アプリケーションの開発時に意識していること - しばやん雑記

                                                                                  ここ数年は Azure Functions をフルに活用したアプリケーションを実装することが多かったのですが、同時に Azure Functions を失敗しないように使う方法も分かってくるので、ここらでちゃんと言語化しておきます。 最近は特に Azure Light-up というハッカソンを行うことが多いのですが、Azure Functions を使う場合には必ずこの辺りは毎回説明するようにしています。要するに Azure Functions の利点・特性を理解して賢く使いこなそうという話です。 Binding / Trigger で実現出来ないか考える Function の実装は出来る限り小さく保つ リトライのしやすい実装を重視する 最新の .NET での作法に沿ったコードを書く Graceful Shutdown に対応したコードを書く 機能単位で Function App プロジェ

                                                                                    私が Azure Functions アプリケーションの開発時に意識していること - しばやん雑記