業務でAWSを利用する時に知っておくべきポイント10選 - Qiita
2024年1月時点のAWSベストプラクティスに従って作成しました 好評でしたら続編も検討します 1. 環境ごとにアカウントを分離する 本番、検証、開発ごとにアカウントを分割しましょう ✕良くない例 ◎良い例 最初にアカウント分割しておかないと、後で分割するのはとても大変です アカウントを分割することで「検証と思って作業したら、実は本番だった」のような事故を減らすことができます コストがアカウント単位で集計されるため、環境ごとのコストを簡単に算出することができます AWS Organizationsを使用することで、各環境に応じた権限設定が簡単にでき、ガバナンスを強化することができます AWSアカウントはAWS Control TowerのAccount Factoryを使用することで、クレジットカード情報を都度入力することなく簡単にアカウントの払い出しが可能です また、AWS Contro
【永久保存版】シェルスクリプト完全攻略ガイド - Qiita
弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 シェルスクリプトの世界へようこそ！ シェルスクリプトって何？ シェルスクリプトは普段 Bash などのシェルで実行しているコマンドを並べて、まとめて実行できるようにしたものです。ファイルのバックアップ、ログファイルの解析、システムのセットアップなど、ターミナルで行っていた一連の作業をまとめてシェルスクリプトに記述することで、シェルスクリプトを実行するだけで自動的に一連の作業を終わらせることができるようになります。また、シェルスクリプトはファイルに保存することになるため、再利用するのも簡単になります。 シェルスクリプトで使うコマンドの多くは UNIX コマンドになると思います
中途入社や部署異動で来た新メンバーを活躍しづらくするアンチパターン - Qiita
1. はじめに ソフトウェア開発のチームに、新しいメンバーが入ってくることはよくあります。 以前に新卒社員がチーム入ってきた場合の育成方法を紹介しました(こちら)。 今回は、新卒社員ではなく、他の会社から中途入社か同じ会社の部署異動で来る新メンバーの話です。 (エンジニアが数百人などで規模が大きい会社の場合、部署が違うと仕事のやり方が全く変わる場合があるので、今回は中途入社と他の部署からの異動を同じように「新メンバー」として扱います) 会社や部署が変わると仕事のやり方が大きく変わるため、仕事のやり方に戸惑うことが多いと思います。 本稿では、そのような「新メンバー」を活躍しづらくしてしまうアンチパターンとその対策を紹介します。 2. 中途入社や部署異動で来た新メンバーが適応することの困難さを理解する 中途入社や部署異動で来た新メンバーが組織に適応することは、新卒社員のそれとは別の難しさがあり
Terraform職人のためのOpenTofu入門 - Qiita
この記事は クラウドワークス Advent Calendar 2023 シリーズ1 の 4日目の記事です。 はじめに 「父さんな、Terraform職人やめてお豆腐職人で食っていこうと思うんだ」と言いたいだけの @minamijoyo です。 2023年8月HashiCorpはこれまでMPL2のOSSライセンスで公開していた主要製品をBSL(Business Source License)に変更することを発表し、Terraformはv1.6.0からOSSではなくなりました。 このライセンス変更を受けて、OSS版のTerraformを求める人たちで、MPL2時点のコードベースからforkしたOpenTofuの開発が進められています。 HashiCorpのBSLは、実質的に競合他社の商用利用に制限をかけたもので、ほとんどの一般的なユーザに直接的な追加の制限はありませんが、間接的にTerrafo
Architecture Decision Record を一年運用してみた - Qiita
この記事は、株式会社カオナビ Advent Calendar 2023の２日目です。 カオナビでは2022年9月からArchitecture Decision Record（以下ADR）を導入開始しました。本記事ではADRを導入し実際に一年間運用して見た経過をご報告しつつ、導入のポイントや注意点について紹介します。 ADRをなぜ導入したのか？ まずADRについて簡単に説明すると、「アーキテクチャー設計の記録をドキュメントとして残すこと」 です。Michael Nygardのブログ記事が初出のようです。 ソフトウェア開発を行っていく間には、途中で様々な設計決定をする必要があります。例えばウェブアプリケーションであれば、データベースはMySQLにしようとか、キャッシュはRedisを使おうとかという実行環境の決定の話から、実際のプログラムの基本構造といったところまで様々です。 この設計決定は、口
Makefile警察「ぐぬぬぬ…」 - Qiita
？「プロジェクトでよく使うコマンド Makefile に書いたろー」 ？「docker compose up -d --wait っと…」 👮♀「 Makefile警察 だ！」 👮♀「 Makefile は、ソフトウェアのビルドプロセスを自動化するためのファイルだ！」 👮♀「多目的なタスクランナーとして使うな！」 ？「せやったんか。誠にごめんなさい。」 Makefile は広く使われていますが、時々目的外に使われてしまうことがあります。しかし、そのような使い方にはより適した代替手段が存在します。この記事では、 Taskfile というツールについて解説します。 Makefile のつらみ Makefile は主にビルドプロセスを自動化する目的で生まれましたが、様々なコマンドをまとめて実行する便利さから多目的なタスクランナーとしてもよく使われます。しかし、次のような問題があります
Bashを使いこなすための必須コマンド71選 - Qiita
はじめに mkdir, ls, cp, touch, mv, rm以上のコマンドにあんまり触れていない。。。という方、もっとコマンドを使いこなしたい！という方。。。必見。 基本的だが全部網羅するには大変な基本コマンド及びショートカットを溢れんばかり71選お届けします。たくさんありますので、表題に何のコマンドか書いてあるのをご活用ください。 一部、macユーザー向けとなっていることをご了承ください。 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 Ctrl を使ったショートカット 最初に、Ctrlを使ったショートカットを紹介します。 Ctrl-A 行頭移動 ↓ Ctrl-E 行末移動 ↓ Ctrl-W 直前一単語を削除 ↓
デジタル庁のサイトやばすぎるwww - Qiita
はじめに みなさん、デジタル庁のサイトはご覧になったことはありますか？今話題のデジタル庁です。 こちらが2023年6月現在のデジタル庁のサイトです。やばくないですかこれ？最初見たときこれ「やっばw」と思いました。これからこのサイトのやばさを語っていきたいと思います。 洗練されたシンプルさ、そしてデザイン 僕は最初見たときびっくりしました。「なんてシンプルで見やすいんだ！」官公庁のサイトですよ？官公庁のサイトといえば、細かい字がずらっと並んで見づらいイメージでしたが、デジタル庁のサイトはとことんシンプルさを追求して見やすくしてます。フォントもNoto Sans JPを使われててとても読みやすい。黒も #000 でなく見やすい色になっている。 やばいですねこれ。 そしてこのレイアウトを見たとき、余白のおかげでとても見やすいなと思いました。そこでChrome Dev Toolでレイアウトを見てみ
シェルスクリプトで日付処理ならdateコマンドは投げ捨ててDateutilsを使おう！ - Qiita
この中で私が特に気に入ったコマンドは dateround です。次点は dategrep です。この二つは特に強力で、awk やその他のコマンドを使って日時をこねくり回すような「無駄に難解なコード」を書かずに Dateutils のコマンド群だけで大抵のことはなんでもできてしまいます。専用のことをするには専用のコマンドを作ることが重要であることを思い出させてくれるでしょう。 Dateutils の重要な特徴と使用例 大抵のコマンドは機能の説明から想像できると思いますし、公式サイトにも例があるので詳細を一つ一つ説明することはしません。その代わりに「Dateutils の使いこなしに必要な考え方」が分かるような例をいくつか紹介します。 重要な注意点ですが Dateutils はロケールをサポートしていますが、原則としてシステムのロケール情報やユーザーの環境変数には依存していません。内部にロケー
プロキシとの戦いに疲れたのでgoで透過プロキシを作ってみた - Qiita
背景 Qiitaのproxyタグを見てもわかるように、多くのエンジニアがプロキシサーバとの戦いで日々消耗し続けている。とはいえ、主にセキュリティ上の理由でプロキシサーバの利用は必要なことも分かる。 となると、プロキシサーバを意識しなくても(設定しなくても)自動的にプロキシサーバを経由してくれるようになればうれしいよね？ これは透過プロキシと言って昔からある考え方で、QiitaにもProxy環境下での仮想GW構築というすばらしい記事がある。 しかし、上記記事では透過プロキシにredsocks、DNSサーバにpdsndと複数のツールを組み合わせて実現されており、それぞれインストールや設定するのが個人的には面倒というのと、記事中で述べられているとおり、プロキシ経由で53/tcpに接続できない場合に対応できないという制約もあった。 というわけで、今回go言語の勉強も兼ねて自分好みの透過プロキシを自
名著「入門UNIXシェルプログラミング」の超詳細なレビューをしてみた（古い内容の訂正） - Qiita
はじめに そりゃまあ 30 年も経てば古くなりますよ。「入門UNIXシェルプログラミング」は今もシェルスクリプトに関するオススメの本として名前が挙がる名著です。しかしこの本は古い本です。POSIX でシェルが標準化される以前の本で、内容から判断するとおそらく 1990 年ぐらいの常識に基づいて書かれています。 古いから参考にならないと言うつもりはありません。しかしどれだけ優れた本でも時間の流れには勝てません。良書であると思っているからこそ、古くなってしまった内容は訂正する必要があると考えています。なおシェルスクリプトに関する古い本はこれだけではありません。オライリーから出版されている本も古い本ばかりです。いつ頃に（原書が）書かれた本なのかを確認した方が良いでしょう。 ということでレビューというていで、古くなってしまった内容の訂正を行いたいと思います。新しく「入門UNIXシェルプログラミング
Terraform でAWS 環境にDockle + git-secrets を組み込んだCIを構築する - Qiita
はじめに コンテナセキュリティのガイドライン NIST SP800-190(アプリケーションコンテナセキュリティガイド) では、イメージのリスクの1つとして 「イメージの設定の不備」 について言及されています。 さらに、NIST SP800-190 では、このリスクへの対策として、 「セキュアな設定のベストプラクティスへの準拠を検証および実施するためのツールとプロセスを採用すること」 を推奨しています。 本記事では、この 「イメージの設定の不備」 へのリスク対策ツールとして、Dockle とgit-secrets を採用し、このツール群を組み込んだCI パイプライン(ビルドのプロセス)をTerraform でAWS 環境に構築する方法を記載しています。 コンテナイメージのセキュリティ対策の一例として参考になれば幸いです。 Terraform で構築する全体構成図 構成の概要 Dockerf
Terraform でTrivy の脆弱性スキャンとSecurity Hub を統合したCIを構築する - Qiita
はじめに 本記事では、Trivy によるコンテナイメージの脆弱性スキャンとSecurity Hub を統合したCI(Continuous Integration)環境を構築するTerraform のコードをサンプルとして共有しています。コンテナイメージのセキュリティ対策の一例として参考になればと思います。 また、補足として、CodeBuild のビルド内のTrivy に関する処理について、簡単に説明をしています。 Terraform で構築する全体構成図 構成の概要 アーキテクチャは上記のAWS Security Blog を元にしています。 Dockerfile を含むコードをCodeCommit にプッシュするとCodePipeline が実行され、CodeBuild でビルドしたコンテナイメージを、Trivy で脆弱性スキャンをしています。 その結果、深刻度が CRITICAL な脆
POSIX 準拠のシェルスクリプトでは find | xargs よりも find -exec {} + を使うべき！ - Qiita
POSIX 準拠のシェルスクリプトでは find | xargs よりも find -exec {} + を使うべき！ShellScriptBashshellPOSIX はじめに find の出力を xargs にパイプで渡すというのはよく見かける使い方ですが、find -print0 | xargs -0 が使えない POSIX 準拠のシェルスクリプトでは find -exec {} + を使った方が良いです。安全かつ十分に速いからです。よく見かける -exec {} ; ではなく -exec {} + ですので間違えないようにしてください。多くのケースでは + の方が優れているのですが ; ばっかり使われているのを見ると、意外と知られてない気がします。 少しだけ予備知識として、-exec {} ; は -exec {} \; と ; をバックスラッシュでエスケープするのがよく見る使い方
Qiita記事にさりげなく（けど、わかりやすく）環境を記載する - Qiita
はじめに 先日、@uhooi さんの以下のツイートを見た時に、おっ自分と同じ悩みだなーと思い、Qiita記事の「どこに」、「どうやって」、環境を書くといいのか、少し考えてみました Qiitaに記事を投稿するときにいつも悩むのが「環境」を書く位置なんだよな バージョンによって動作が異なることもあるから書くんだけど、流れをぶった切ってしまうことが多いhttps://t.co/TbpySzD4S3 pic.twitter.com/MI6kc36E8H — ウホーイ (@the_uhooi) August 20, 2020 さりげなく（けど、わかりやすく）環境を記載する方法 過不足なく簡潔に環境を記載する方法を模索した結果、OSSのREADME.mdでよく利用されているbadgeサービス（Shields IOやBadgenなど）を利用して、環境を記事の1番上にbadge表示することにしました。1
これがなくては生きていけないVS Codeエクステンション10選 - Qiita
VisualStudioCodeは大人気なだけあって、有能なエクステンションが次から次へと出てきますね。 色々とっかえひっかえ試して遊んでいる人も多いのではないでしょうか。 なんかMinecraftのMOD環境構築と同じ空気を感じますね。 (環境ができたところで飽きて遊ばなくなる) まあ一番手っ取り早いのは、既に評価の固まっている手堅いエクステンションを導入することです。 ということで以下はSahil Bondre( Twitter / GitHub / LinkedIn / Instagram / 個人HP )による記事、💡 10 VS Code extensions I can't code withoutの日本語訳です。 💡 10 VS Code extensions I can't code without VSCodeは私のお気に入りのエディタです。 存在するコードエディタの
ご報告とお詫び 「Qiita」「Qiita Jobs」におけるユーザー情報の取り扱い不備について - Qiita株式会社
ご報告とお詫び 「Qiita」「Qiita Jobs」におけるユーザー情報の取り扱い不備について各位 Increments株式会社（本社：東京都港区、代表取締役社長：柴田健介、以下「弊社」）の運営するプログラマー向け情報共有サービスQiitaのユーザーページ（以下「ユーザーページ」）において、本年3月25日にリリースした新機能に関し、Qiitaのユーザー様をはじめとする皆様にご心配・ご迷惑をおかけし、誠に申し訳ございません。 本件の事実関係については、弊社内で調査を進める中でQiita Blogにおいてもお知らせしておりましたが、事実関係の確認を行った結果につきまして、判明した事実を改めてご報告いたします。 本年3月25日にリリースした新機能は、ユーザーページにおいて、ユーザー様が閲覧されたQiita内の記事に付されたタグのうち出現割合が高かったもの上位5つ及びその割合を、「読んだ記事」と
2020/03/25にリリースしたユーザーページについて、現在の状況を共有いたします - Qiita Blog
Qiita開発チームより、3月25日にリリースしたユーザーページに関しまして、現在確認できた事項をお知らせします。「2020/03/25にリリースしたユーザーページについて」の続報となります。 １．3月25日のユーザーページのリリースについて今回のユーザーページのリリースについて①ユーザーの皆様への配慮不足、②弊社内での事実確認不足がありました。 その結果、長い間一緒にQiitaというコミュニティを築いていただいたユーザーの皆様へご迷惑をおかけして誠に申し訳ございません。 ①および②について、背景・事実をご説明させていただきます。 ①ユーザーの皆様への配慮不足について 今回のユーザーページのリリースについては「ユーザーページをリニューアルしました」に記載させていただきましたが、開発チームでは、読んだ記事を視覚化することでより自分自身を客観的に理解し、また、他者からも認識されることでQiit
DXを大幅に低下させるDocker for Macを捨ててMac最速のDocker環境を手に入れる - Qiita
※DXはデジタルトランスフォーメーションではなくてDeveloper Experienceの方です 2020/05/26追記 https://qiita.com/nanasess/items/16ab9274c34bdc34e567 を使うことでVagrantを経由せずにDocker for Macの機能だけでMutagenを使うことができるようになりそうです。 パフォーマンスの測定はしていませんが、Docker for Macの設定のみでこの記事の手法と同等の速度が出るようになるかもしれません。 概要 Macでネイティブでの動作とほぼ同等の速度の安定したDocker環境を手に入れることができたので、その知見について公開します。 ものによりますが、最大10倍程度パフォーマンスの向上が見られました。 具体的な手法としてはVirtualBox + Dockerを用います。 設定は2ファイル50
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
爆速python-fire - Qiita
