はじめに AWSのアクセス制御サービスであるIAMについて、2022年7月時点での機能および使用法を、初学者でも理解しやすいことを心掛けてまとめました。 IAMをよく分からないまま適当に設定するとセキュリティ的にまずいので、これを機に設定を見直して頂き、セキュリティレベル向上に貢献できれば幸いです。 特に、後述するIAM設定手順は、AWSに登録して最初に実施すべき設定に相当するため、セキュリティに興味がなくとも一度は実施することをお勧めします。 また公式のベストプラクティスは丁寧にまとめたつもりなので、初学者以外でもAWSのセキュリティ確保に興味がある方は、ぜひご一読頂けると嬉しいです。 IAMとは 「Identity and Access Management」の略です。 公式ドキュメントによると、IAMは「誰」が「どのAWSのサービスやリソース」に「どのような条件」でアクセスできるかを
みなさま、認可の設計に苦しんでいるでしょうか？私は苦しんでいます。苦しまなかった瞬間などありません。昔「アプリケーションにおける権限設計の課題」を執筆しましたが、あれから3年以上が経ちます。 当時は認可の設計に関する情報がうまくまとまっている記事などほとんど無く、調べに調べて得たナレッジを書き記したのが上記の記事です。3年以上経ちますが、苦悩が今も特に変わっていないことが驚きです。 ただし、世の中的には認可のライブラリであったりサービスというのは少しずつ増えてきている印象があります(Auth0の OpenFGA であったりOsoの Oso Cloud 、Asertoの Topaz )。 認可の設計に関する記事も少しずつ増えている印象があり、その中でも本記事で紹介したいのがAuthorization Academyです。 これは認可サービスである Oso Cloud やOSSのライブラリ o
このドキュメントは、効率的なイメージ構築のために推奨するベストプラクティスを扱います。 Docker は Dockerfile に書かれた命令を読み込み、自動的にイメージを構築します。 Dockerfile はイメージを構築するために必要な全ての命令を、順番通りに記述したテキストファイルです。 Dockerfile は特定の書式と命令群に忠実であり、それらは Dockerfile リファレンス で確認できます。 Dockerfile の命令に相当する読み込み専用のレイヤによって、 Docker イメージは構成されます。それぞれのレイヤは直前のレイヤから変更した差分であり、これらのレイヤは積み重なっています。次の Dockerfile を見ましょう。 命令ごとに１つのレイヤを作成します。 FROM は ubuntu:18.04 の Docker イメージからレイヤを作成 COPY は現在のデ
業務やプライベートでのハンズオンを通して得た知見を元に、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
【初心者向け】「AWS 設計のベストプラクティスで最低限知っておくべき 10 のこと」を受講しました。 | DevelopersIO
どうもさいちゃんです。 AWSには利用者が仮想環境を構築していくのに役立つベストプラクティスと呼ばれるものがあります。 これからAWSでガンガン仮想環境を構築していくにあたって設計のベストプラクティスを復習してみようということで、今回はAWS公式から出ている「AWS 設計のベストプラクティスで最低限知っておくべき 10(+1) のこと」という動画を視聴したのでご紹介をしていきます。 登録さえすれば、無料で動画の視聴と資料のダウンロードができます。 こちらから受講が可能です。 はじめに このセッションはAWSにおける設計おベストプラクティスの理解を深める目的で、 クラウド導入を検討している方 オンプレミスからクラウドへの移行を検討している方 クラウドを使い始めたがベストプラクティスを適用できているか悩んでいる方 向けに細かくわかりやすくベストプラクティスについてを説明しているものになります。
はじめに 皆さん、docker composeを利用しているでしょうか？ 複数のdockerコンテナをまとめて立ち上げたり、環境変数を定義できたり便利ですよね。 今回はある程度docker composeを利用している方向けに私が便利、便利そうと感じたdocker composeの機能を挙げてみました。 docker compose cli v2を利用 docker-composeではなく docker composeコマンドも利用可能になってます。 Docker Desktopでは v3.4.0から利用可能で、基本的にはコマンドの互換性あります。 Docker image名やコンテナ名のプレフィックスをディレクトリ名から変更する 通常は ${ディレクトリ名}_${サービス名}でイメージが作成されます。 環境変数COMPOSE_PROJECT_NAMEでプロジェクト名を指定することにより
PagerDuty Advent Calendarの8日目！ 今日はOps Guidesのお話です。 うちはこうだけど、他はどうやってるんだろう？ 普段から運用に関わっていると、ふとした瞬間に「そういえば他の会社ではどういう運用をやっているんだろう？」と気になること、ありませんか？ そのきっかけは「本当になんとなく」といったものから「上手くいかない運用にフラストレーションが溜まって」というどす黒いものまで色々あると思いますが、いずれにせよ「他の会社の良いところを取り入れて、自分たちの運用を改善したい」という気持ちから来ているのは間違いないでしょう。 だからこそ、いろんなミートアップに参加して発表を聞いたり、懇親会で話してみたり、Xに垂れ流されているいろんなポストを読んで事例を学ぶわけです。 ベストプラクティスを学びたい! このような取り組みはとても良いことですし、是非とも継続して情報収集し
APIの設計って意外と移り変わりがあるんです。例えばAPIのバージョンの指定方法がヘッダーを使う方法からURLを使う方法にだんだん統合されてきました。 したがって本やスライドなど、その時点のベストプラクティスを読むよりは、生きているベストプラクティスを読んだ方が良いと思います。 ここではいくつか参考になるリソースのご紹介と、よく聞かれる質問について触れておきます。 設計ガイドライン、スタイルガイドAPIの設計のベストプラクティスを把握するためによくAPIのドキュメントを見ているのですが、特にご紹介したいのはスタイルガイドや設計ガイドです。 マイクロソフトのAPIガイドライン
アジャイル・DevOps時代の テストと品質保証 （完全版） / Testing and Quality Assurance in Agile and DevOps Era
この10年は多くの変化がありました。 ソフトウェア開発プロセスにおいては、アジャイル開発の普及が進み、さまざまな現場でスクラムが活用されるようになりました。 技術面では、コンテナ技術やその管理の自動化が進み、システムはどんどん複雑になりつつあります。 一方で、テストや品質保証はどのように変わってきたでしょうか？ 私はアジャイルコーチとして10年活動してきましたが、 最近話題の「DX（デジタルトランスフォーメーション）」の影響か、 開発に速さがより求められるようになってきたように感じています。 そして、その影響もあってか「テストがボトルネックになりがち」や 「マニュアルテストのチームがコストセンターになってしまった」という相談をよく受けるようになりました。 このセッションでは、アジャイル・DevOps時代におけるテストと品質について、 - 現在 - 戦略と戦術 - 組織未来 のお話させていた
Amazon SES でメール送信するときのベストプラクティスまとめ(2020年10月) | DevelopersIO
Amazon SES API についての補足の説明です。 From, To, Subject, Body のみ指定すれば、残りはすべて AmazonSES が適切にフォーマットした Eメールメッセージで簡単にメール送信できるのが SendEmail API です。 添付ファイルを使うなど、独自に細かく制御したフォーマットにカスタマイズしてメール送信をしたい場合は SendRawEmail API を利用します。 基本となるテンプレートメールを作成して、テンプレート内の変数に対してパーソナライズされた値に置換した内容で Eメールメッセージを送信できるのが SendTemplatedEmail および SendBulkTemplatedEmail のAPIです。 詳細については、AmazonSESのEメール送信方法 を確認下さい。 SESのSMTPエンドポイントを使ったメール送信例は下記ブログ
Kubernetes ベスト プラクティス 6 選
2019.6.23 DevLOVE X (DevLOVE 10周年イベント) @ NAVITIME で話した資料です。
こんにちは。クラメソのスジェです。 ほとんどのサービスにはベストプラクティス（=best practices）というのがあります。 そのサービスを利用する際、このベストプラクティスを守るとより効率的に性能を100%活用することができます。 もちろんterraformにもこのようなベストプラクティスがあります。 今回はこのベストプラクティスについて整理してみました。 参考資料 本記事は下記の資料を参考にして作成しました。 本記事ではほとんどのプロジェクトに活用できる程度の項目を紹介しています。つまり、ベストプラクティスについて軽く説明している感じなので、詳細な内容までは上記の資料をご参照ください。 また、紹介した資料以外にもベストプラクティスを調べてみたら、たくさんの資料がありますので、そちらもあわせて確認することをお勧めします。 読む前に 実際にベストプラクティスをプロジェクトに適用しよう
ChatGPTプロンプトエンジニアリングのコツ8箇条～OpenAI公式のベストプラクティスから学ぶ～ - Qiita
はじめに OpenAI API (ChatGPT含む) のプロンプトエンジニアリングのベストプラクティスが公式から出ているのを知り、和訳しながら読んでいきたいと思います！ プロンプトエンジニアリング8箇条 (忙しい人向け) 最新のモデルを使用する 指示をプロンプトの最初に配置し、###または"""で指示と文脈を分ける 望む文脈、結果、長さ、形式、スタイルなどについて具体的で詳細に記述する 例を使って望む出力形式を明示する ゼロショットから始め、効果がなければファインチューニングを行う 曖昧で不正確な表現を減らす やってほしくないことだけでなく、代わりにやってほしいことも記述する コード生成には、特定のパターンに誘導する「leading words」を使用する How prompt engineering works (プロンプトエンジニアリングの仕組み) インストラクション・フォロー・モデ
【資料公開】プロダクトマネージャーのしごと
みなさんこんにちは。@ryuzeeです。 2023年10月17日に行われたオンラインイベント「プロダクトマネージャーのしごと - Forkwell Library #33」の登壇資料を公開します。 内容は、新刊書籍『プロダクトマネージャーのしごと』に関するものなのですが、30分という時間で全部を網羅的に紹介するのは無理ですし、ぜひ本書を読んでいただきたいので、僕が気に入っているところと、本書全体を通して中心にある考え方を紹介しました。 ちなみに書籍は16章から構成されていて、そのなかで特に自分が好きなのは「7章 「ベストプラクティス」のワーストなところ」です。 職業柄、日頃から「プロダクトマネジメントではどんなフレームワークを使うといいですか？」「プロダクトマネジメントの日本での成功事例を教えてください」「プロダクトマネジメントのベストプラクティスを教えてください」のような質問をたびたびい
なるべく楽したいAWSセキュリティ
AWSのベストプラクティスに従う SecurityHub でセキュリティチェック なるべく持ち物を減らし、ツールの既定に合わせる Fargateを使い管理対象インスタンスを減らす ネットワーク環境構築をCopilot CLIに任せる アプリケーションレベルでもAWSサービスを活用する 典型的な攻撃はアプリ到達前にWAFで防ぐ ECRコンテナスキャンで脆弱性をチェックする
フロントエンドテストにおける知見の宝庫を発見！「javascript-testing-best-practices」 - Qiita
フロントエンドテストにおける知見の宝庫を発見！「javascript-testing-best-practices」JavaScriptテストフロントエンド はじめに JavaScriptにおけるテストのベストプラクティスをまとめた「javascript-testing-best-practices」というGitHubレポジトリが大変勉強になったため、特に参考になった内容をまとめて共有したいと思います。 （補足）本レポジトリにはfrontendのみならずbackendのテストに関する情報もありますが、今回はfrontendに焦点を当てて共有します。そのため扱うSectionは以下の4つです。 Section 0: The Golden Rule Section 1: The Test Anatomy Section 3: Frontend Section 4: Measuring Test
本書ではGitHub Organizationをセキュアに運用する方法について解説します。 GitHubは大変便利なサービスで、個人利用のみならず組織で活用されるケースも多いです。しかしGitHubの初期設定は利便性重視であり、セキュリティ対策は利用者による明示的な設定が必要です。 本書では意外と日本語でまとまった情報がない、Organizationレベルのベストプラクティスを体系化しています。GitHub Organization管理者はもちろんのこと、ソフトウェア開発者にも有益な情報を提供します。
AWSセキュリティベストプラクティスを実践するに当たって適度に抜粋しながら解説・補足した内容を共有します | DevelopersIO
こんにちは、臼田です。 皆さん、セキュリティ意識してますか？(挨拶 今回はお客様宛にAWSのセキュリティベストプラクティスについて補足・解説したものを汎用化して共有します。 公式のドキュメントだと少し硬くて読みづらいみたいなイメージもあるかと思いますので、こちらの記事を参考に感覚を掴んでいただければと思います。なお、いろいろ簡潔にしたりするためにすべてのことについて説明していませんのでご了承ください。 熟読いただきたい資料 AWSのセキュリティベストプラクティスの資料は本当は熟読していただきたいです。しかしながら、最初はとっつき辛いと思うのでこの先の内容を見ていただいて、余力があればこちらのセキュリティベストプラクティスを見ていってください。 https://d1.awsstatic.com/whitepapers/ja_JP/Security/AWS_Security_Best_Prac
木瓜丸です。 最近になって、やっとNext.jsを上手く使いこなせてるんじゃないか？！と思えるようなコンポーネントの設計手法を見つけたので、Zennにまとめてみたいなと思います。 この記事で触れること この記事では、主にページ単位でどのように状態管理を行うのかに焦点を当てることにします。 コンポーネントの管理の仕方などは特に着目しませんがご了承下さい。 hooksの導入 React初心者の方は最初に疑問に思うと思いますので、hooksについて触れておきます。 hooksというのは、Reactによって提供されているuseState, useEffectといったやつや、それらを組み合わせて作ったオレオレ状態管理基盤の総称です。 この記事で用いる基本的なhooksをいくつか紹介します。 useState その名の通り、状態を持つ変数を作ってくれます。 const Hoge = () => { c
はじめに 2021年、Pythonで複数の暗号系ライブラリを開発してPyPIで公開してきました。その過程で、setuptools、flit、poetryと、幾つかのパッケージ管理をわたり歩き、GitHub上でのCI/CDも色々試す中で私的なべスプラが定まってきたので、2022年初に備忘録としてまとめておきます。 具体的には、pyenv、poetry、pre-commit、tox、GitHub Actions を活用し、低コストで（＝なるべく自動で）、高品質のプロダクトをPyPIにデプロイする方法・設定を共有します。個別のツールの記事はよく目にするのですが、開発ライフサイクル全体をカバーする記事がなかなか無かったので。 開発環境の整備 - pyenvで複数のPythonバージョンでの開発環境を整備 パッケージ管理 - poetry/pyproject.tomlでの一元的なパッケージ管理 静的
本記事は、Simon Holdorf氏による「9 Popular GitHub Repos For Every Web Developer」（2021年4月4日公開）の和訳を、著者の許可を得て掲載しているものです。 こちらもどうぞ すべてのウェブ開発者へ。人気GitHubリポジトリ10選 便利なツール、参考になる例など はじめに GitHubは、最近の（ウェブ）開発に関連するすべてのワンストップショップです。フレームワーク、デモ、あらゆる種類のコレクションなど、GitHubで見つけられないものはないでしょう。しかし、この膨大な量が問題です。あまりにも多くのレポジトリがあるので、おそらく聞いたことのないクールなものがあります。 そこで今回も、知っておくべき最も人気のGitHubリポジトリを紹介することにします。各リポジトリには少なくとも30,000個の星が付いています。 1. Realwor
AWS Well-Architected フレームワーク - AWS Well-Architected フレームワーク
要約 このホワイトペーパーでは、AWS Well-Architected フレームワークについて説明します。本書は、お客様が AWS 環境の設計、提供、メンテナンスを行う際にベストプラクティスを適用できるようにするためのガイダンスを提供します。ここでは Well-Architected フレームワークの柱とされる 6 つの概念領域における一般的な設計の原則と、特定のベストプラクティスおよびガイダンスを紹介します。 はじめに 定義 アーキテクチャ 一般的な設計の原則 フレームワークの 6 本の柱 運用上の優秀性 セキュリティ 信頼性 パフォーマンス効率 コスト最適化 持続可能性 レビュープロセス まとめ 寄稿者 注記 お客様は、この文書に記載されている情報を独自に評価する責任を負うものとします。本書は、(a) 情報提供のみを目的とし、(b) AWS の現行製品と慣行について説明しており、これ
要約 Docker in Docker な CI では、以下の Docker Build をオススメします。 スクリプト Buildx を使う Buildx を使えないならば、BuildKit + –cache-fromオプションを使う Dockerfile ステージ間の依存を弱くする(依存インストールとビルドを分ける) 中間イメージも軽量化する 不要なキャッシュを削除 ファイル変更差分によりますが、これらにより最大 1/3 へビルド時間を短縮しました。 はじめに 『ホットペッパービューティー』美容クリニックのカウンセリング予約サービスのバックエンドを担当している安達です。 新卒として 4 月に入社して、5 月中旬に美容クリニックに配属され、すでに約 4 ヶ月が過ぎました。 まず、チーム内で自分が活躍できる庭を作りたかったため Docker について詳しくなろうと思いました。 そこで、CI
Amazon Web Services ブログ AWS 利用標準化ガイドライン策定のベストプラクティス 組織で横断的に AWS の展開を進めていくにあたり、クラウド環境の統制、セキュリティ対策、品質の確保にお悩みではありませんか？ 組織で AWS の利用を拡大する際には、それぞれの環境において確実に統制を効かせ、適切なセキュリティ対策を行い、品質のばらつきを抑えることが欠かせません。その際に有効なアプローチが AWS 利用標準化ガイドライン（以下「ガイドライン」と記載）の活用です。本ブログではガイドラインを策定し、有効に活用するためのベストプラクティスをご紹介します。 はじめに 多くの企業や政府機関において、クラウドの活用を加速する動きが加速しています。しかし、その過程において以下のような課題に直面するケースがあります。 設計・運用方針がバラバラで統制が取れていない セキュリティ対策が十分
Front-End Study #1「Cloud Native時代のフロントエンド」 - connpass の発表内容のテキスト版です。 発表に載せられなかった参考資料集 StatCounter Global Stats - Browser, OS, Search Engine including Mobile Usage Share The "Developer Experience" Bait-and-Switch - Infrequently Noted JavaScriptよ。文明を捨て、自然に還れ。 ::ハブろぐ Deno - A secure runtime for JavaScript and TypeScript Rome Toolchain Blitz.js - The Fullstack React Framework | Blitz.js ⚡️ Prisma - Da
[初心者向け]AWS Well-Architected ドキュメントの歩き方 | DevelopersIO
2022バージョンについて 新バージョンをリリースしています。 今後はこちらをご参照ください。 以下2021バージョン AWS認定トレーニング講師の平野@おんせん県おおいたです。 今日はWell-Architectedがテーマです。 はじめに AWS Well-Architected フレームワークとは AWSとAWSユーザの10年以上の経験からまとめられたベストプラクティクス集です。 いいかえれば、多くの失敗反省を元に作られています。 これからAWSを活用する際に、皆さんが同じ失敗をしないためのガイドラインとも言えます。 AWSを始めたら、まずは目を通してもらいたいドキュメントです。 とはいえ... とはいえ、このドキュメントなかなか読みづらいです。 私も正直最初は？？？という感じでした。 そこで、これからWell-Architected ドキュメントを読む方のサポートができないかと思い
![[初心者向け]AWS Well-Architected ドキュメントの歩き方 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/61b8033f05d1e5ba2c6b80dad8bd07c481d8078f/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2021%2F06%2FWA_guide-1.png)
【React/Vue.js】コンポーネント設計の（個人的）ベストプラクティス | Offers Tech Blog
概要 こんにちは、Offers を運営している株式会社 overflow の Software Engineer（主戦場はフロントエンド）の Kazuya です。今回は、React や Vue.js などの SPA フレームワークにおけるコンポーネント設計について紹介します。 昨今のフロントエンド開発では、コンポーネント指向での開発がスタンダート化しつつありますが、コンポーネント設計には厳格なルールが無く、どのように設計すればいいか悩む方も多いのではないでしょうか？（筆者は沼にはまりました） コンポーネントの単位はどの程度に分割すべきなのか、状態管理はどうすればいいのか、API 通信はどこですべきなのかなど、一言にコンポーネント設計と言っても考えるべき項目が多いです。チーム開発では、認識があっていないとコードが魔境になることもしばしばあると思います。（筆者の経験談より） そこで今回は、数々
この記事では、Dockerを例に、コンテナログ処理の一般的な方法やベストプラクティスをいくつか紹介しています。 背景 Docker, Inc. 旧社名：dotCloud, Inc）は、2013年にDockerをオープンソースプロジェクトとしてリリースしました。その後、Dockerに代表されるコンテナ製品は、分離性能の良さ、移植性の高さ、リソース消費の少なさ、起動の早さなど複数の特徴から、瞬く間に世界中で人気を博しました。下図は2013年からのDockerとOpenStackの検索傾向を示しています。 コンテナ技術は、アプリケーションの展開や配信など、多くの便利さをもたらします。また、以下のようなログ処理のための多くの課題ももたらします。 1、コンテナの中にログを保存した場合、コンテナが取り外されるとログは消えてしまいます。コンテナは頻繁に作成・削除されるため、コンテナのライフサイクルは仮想
Tableauによる最新版『可視化ベストプラクティス』〜Tableau Blueprint〜 #tableau | DevelopersIO
先日のブログでも紹介しましたTableau社によるベスト・プラクティス集『Tableau Blueprint』。 当エントリでは、その中から『可視化』の部分にフォーカスを当てたトピック『Visual Best Practices』に関してその内容をまとめて見たいと思います。 Visual Best Practices - Tableau 目次 はじめに ユーザー視点に立って考える コンテキスト 適切なチャートの選択 レイアウト 配色 タイトルと字幕 ツールチップ フォント ダッシュボードのサイズ ダッシュボードに対話性を持たせる パフォーマンス設計 まとめ はじめに ダッシュボードの究極的なゴールは『ユーザーが答えを簡単に導き出すことが出来る』ことと言えるでしょう。如何に見栄えの良い、美しいダッシュボードが出来たとしてもユーザーがそれを使って洞察を得て答えを見つける事が出来なければ何の役に
意外と知られてない？AWS Prescriptive Guidance（AWS規範的ガイダンス）めっちゃ使えるよ | DevelopersIO
AWS Prescriptive Guidance（AWS規範的ガイダンス）について紹介されているものが少なったので、ひょっとして未だ認知度低いんじゃないか？ということで紹介したいと思います！ AWS Prescriptive Guidance（AWS規範的ガイダンス） Amazon Web Services (AWS) Prescriptive Guidance provides time-tested strategies, guides, and patterns to help accelerate your cloud migration, modernization, and optimization projects. These resources were developed by AWS technology experts and the global communi
GitHub - hexops/dockerfile: Dockerfile best-practices for writing production-worthy Docker images.
Writing production-worthy Dockerfiles is, unfortunately, not as simple as you would imagine. Most Docker images in the wild fail here, and even professionals often[1] get[2] this[3] wrong[4]. This repository has best-practices for writing Dockerfiles that I (@slimsag) have quite painfully learned over the years both from my personal projects and from my work @sourcegraph. This is all guidance, not
[初級編] なぜ「AWS で負荷分散は３AZ にまたがるのがベストプラクティス」と言われるのか 可用性の面から考えてみた | DevelopersIO
水平分散のアーキテクチャを考えるときに、「負荷分散装置の下に並べる分散先 (サーバ) は３台以上がよい」「AWS であれば３ AZ にまたがるとよい」とはよく聞かれます。それがどういう意味をもつのか、主に可用性の面から考えてみました。 みなさん、AWS使ってますか！（挨拶 AWSに限らず、ある程度の規模の何かしらの本番システムを組もうというときに、こういう言葉を聞いたことはないでしょうか。 「負荷分散装置の下に並べる分散先 (サーバ) は３台以上がよい」 「AWS であれば３アベイラビリティゾーン (AZ) にまたがるとよい」 負荷分散装置（ロードバランサー）は負荷を分散するのがお仕事です。分散するだけなら 2 台でもよさそうですよね？ AWS の３ AZ に至っては、そもそも AZ 単位の障害なんてそうそうないし、あったとしてももう片方の AZ が生きていればなんとかなりそうに思えます。
![[初級編] なぜ「AWS で負荷分散は３AZ にまたがるのがベストプラクティス」と言われるのか 可用性の面から考えてみた | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/876809e40a16193d45c580a01a3f67fc9a50a044/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Felastic-load-balancing.png)
機械学習なdockerfileを書くときに気をつけとくと良いこと - nykergoto’s blog
みなさん機械学習系の環境構築はどうやってますか? 僕は最近は Docker を使った管理を行っています。 特に師匠も居なかったので、ぐぐったり人のイメージを見たり手探りで docker をつかいつかいしている中で、最初からやっとけばよかったなーということがいくつかあるのでメモとして残しておきます。 大きく2つです。 キャッシュは消す テストを書く キャッシュは消す ライブラリをいろいろと install すると大抵の場合ダウンロードしたファイルを保存されている場合が多いです。何かのタイミングで再びそのライブラリをインストールする際にはダウンロードしたファイルを使って、素早くインストールすることができます (この仕組みがキャッシュです)。 キャッシュがあると容量が重くなるという欠点があります。重たいイメージは pull に単に時間がかかりますから、システムとしてデプロイする時にトラフィックが
Engineer / Technology Evangelist at SAKURA Internet, Inc.
本記事は React best practices and patterns to reduce code を提供元の事前許可を得たうえで翻訳したものです。 元の記事に従いタイトルに「ベストプラクティス」と含んでいますが、実際にはベストプラクティスは規模や状況によって大きく異なります。 チームの状況にあわせて参考にしていただければと思います。 ===== これは全3パート中の第1パートとなる記事です。 パート1（この記事）パート2パート3 私は数年に渡っていくつかのプロジェクトで、React.jsを使った取り組みに参加してきました。様々なプロジェクトに取り組む中でいくつかの共通するパターンを見出したため本ブログでご紹介いたします。それではいきましょう。 1. reduxのactionsとdispatcherのためにカスタムフックを作成する私はreduxを使うことを好んではいませんが、いくつ
原 康紘 アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト AWS 上でのマネージド・サービスメッシュを実現する AWS App Mesh や、Kubernetes ワークロードとの親和性が高い Istio など、サービスメッシュの世界には数々のプロダクトやソリューション、アイデアが生まれつつあります。本セッションでは、マイクロサービスにおけるベストプラクティスの集大成とも言えるサービスメッシュについて、その解決すべき課題と人々が熱狂する理由、サービスメッシュそのものの必要性について掘り下げます。同時に、サービスメッシュを実現する上で最も重要なコンポーネントの一つとも言える Envoy の詳細にも触れながら、皆さまがサービスメッシュを活用する手助けとなるヒントを紹介します。 AWS の詳細については http://aws.amazon.com/jp
技術 1 課の水本です。 最近 Terraform のリファクタリングを行っているのですが、ベストプラクティス迷子になっています。 HashiCorp でも明確な方針は打ち出していない為、Terraform を利用する各プロジェクトで方針を決めているのが現実のようです。 今回は私が出会ってきた問題と、それについての対応、見解を書き連ねていきます。 あくまでも私が思ったことですので、「こうしたほうがいいよ！」というネタも募集しています。 workspace 使うのか使わないのか問題 結論として、私自身は workspace という機能を知ったものの、使うことは考えませんでした。 Terraform では workspace という個別のエリアを設けることが可能で、これを prod や staging と命名し作成しておくと、完全に環境を分離できるというメリットがあります。 ただしデメリットと
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【2022年版ベストプラクティス】AWS IAMまとめ - Qiita
認可のアーキテクチャに関する考察（Authorization Academy IIを読んで）
Dockerfile のベスト・プラクティス — Docker-docs-ja 19.03 ドキュメント
Dockerfileのベストプラクティス - Qiita
個人的docker composeおすすめtips6選 - Qiita
運用に携わる人全員に見てほしい！ Ops Guidesの紹介 - Qiita
REST API設計のパターンと原則｜Sachiko Kijima
アジャイルな開発組織のOKRベストプラクティス＆アンチパターン
Terraform ベストプラクティスを整理してみました。 | DevelopersIO
GitHubセキュリティ Organization運用のベストプラクティス
React/Next.jsでの俺的ベストプラクティスを見てくれ
Pythonでの開発・CI/CDの私的ベストプラクティス2022
すべてのウェブ開発者へ。人気GitHubリポジトリ9選 - Qiita
CI での Docker Build のベストプラクティスを考えてみた
AWS 利用標準化ガイドライン策定のベストプラクティス | Amazon Web Services
Frontend Study #1: 基調講演 - Frontend 領域を再定義する
Dockerセキュリティベストプラクティス トップ20：究極ガイド #aqua #コンテナ #セキュリティ #ベストプラクティス - クリエーションライン株式会社
コンテナログ処理の技術的なベストプラクティス：Dockerのケーススタディ - Qiita
http://tink.elliptium.net/2021/05/30/how_to_use_python_official_documentation.html
Dockerfileを改善するためのBest Practice 2019年版
Reactのベストプラクティスとコード削減パターン - パート1
サービスメッシュは本当に必要なのか、何を解決するのか | AWS Summit Tokyo 2019
最近、Terraform のベストプラクティス迷子です - サーバーワークスエンジニアブログ