タグ

ブックマーク / qiita.com (364)

  • Terraformで、Systems Manager(Session Manager)でアクセスできるようにしたEC2インスタンスを構築する - Qiita

    Terraformで、Systems Manager(Session Manager)でアクセスできるようにしたEC2インスタンスを構築するAWSTerraform TL;DR AWS Systems Managerを使って、EC2インスタンスにSSH鍵なしでアクセスできるようにしたい そのための環境を、Terraformで構築する AWS Systems Managerを利用するためには、EC2にAmazonSSMManagedInstanceCoreポリシーを含むIAMインスタンスプロファイルを付与する必要がある AWS Systems Manager AWS Systems Managerとは、AWSインフラリソースの運用の役立つサービスです。 AWS Systems Manager AWS Systems Managerの機能は、こちら。 Systems Manager の機能 ま

    Terraformで、Systems Manager(Session Manager)でアクセスできるようにしたEC2インスタンスを構築する - Qiita
  • 【要件定義】いきなり内容説明しない!業務フローを説明するまでの「長い道のり」をまとめました。 - Qiita

    要件定義をしているときに、お客さんに資料を説明することがあります。ITを専門にしていないお客さんにどのように説明するのがよいのでしょうか。まずは、資料の中身を説明する前に、前提を話す必要があります。資料の作り方は書籍やネットの記事でよく目にしますが、資料説明の仕方はあまりないようにみえます。ので、資料を丁寧に説明する流れを検討し、自分なりの言葉でまとめました。 記事では、 ①紙媒体で行っていた業務をシステム化するプロジェクト ②「要件定義フェーズ」 ③「業務フロー」を「お客さん(ITを専門にしない方)」に説明する と仮定して、セリフと解説を記載してきます。 説明の流れ 1.ウォーターフォールモデルにおける要件定義の解説 2.使用する資料の概要説明 3.近々のスケジュールの確認 4.資料の見方と説明の流れの提示 5.資料の説明開始!

    【要件定義】いきなり内容説明しない!業務フローを説明するまでの「長い道のり」をまとめました。 - Qiita
  • クラウドエンジニア(AWS)ロードマップ2021 - Qiita

    お知らせ 2022年初頭に記事を元にしたAWS書籍が技術評論社より全国出版決定いたしました。 関係者各位のご協力に深く感謝いたします。 タイトル:AWSエンジニア入門講座――学習ロードマップで体系的に学ぶ 書籍出版までの制作プロセス、チーム執筆の方法論などをまとめました チームで技術書を出版して学べた共同執筆メソッド はじめに インフラ初学者がAWSを用いた設計・構築レベルに到達するため、学習の全体像をロードマップ図にまとめました。 背景 パブリッククラウド全盛期においてAWSは全エンジニアにとって「常識」となりました。 しかしながら、情報過多によってAWS学習に必要な情報がネット上のノイズに埋もれてしまい、初学者の直感による判断が誤った学習に行き着くこともあります。 このロードマップはAWS学習の全体像を俯瞰でき、パブリッククラウドを用いた設計・構築レベルに到達するまで導く体系的なス

    クラウドエンジニア(AWS)ロードマップ2021 - Qiita
  • AWS-PlantUMLで使える全AWSリソースの定義と画像表示 - Qiita

    お題 PlantUMLという、ダイアグラムを独自のDSLで生成するツールがある。 (名前にUMLは付くもののUML以外にも、ワイヤーフレーム、ガントチャート、マインドマップ、ER図などさまざまなダイアグラムを生成できる。) そのPlantUMLの公式ライブラリとして、AWS-PlantUMLというものがあり、これを使うとテキスト形式のファイルでAWSリソースを使ったアーキテクチャ図を表現できる。 具体的には以下の通り。 1) 以下のようなPlantUML独自のDSLでテキストファイルを作る。 @startuml !define AWSPUML https://raw.githubusercontent.com/milo-minderbinder/AWS-PlantUML/release/18-2-22/dist !includeurl AWSPUML/common.puml !includ

    AWS-PlantUMLで使える全AWSリソースの定義と画像表示 - Qiita
  • Webの技術だけで作るQRコードリーダー - Qiita

    この記事はPWA Advent Calendar 2019の1日目の記事です。 以前、PWA Night vol.9 で、Web技術だけで作るQRコードリーダーという内容で紹介したのですが、当日は時間の問題で概要程度だったのでもう少し技術的な詳細を書きます。(当日のスライドはこちら) 作ったもの まずは、実際に見ていただくのがイメージつきやすいと思うので動作しているGIFです。 QRコードを読み込んで結果を表示するというものですが、これがブラウザで動いています。 実際に公開されていますのでよかったら使ってみてください。 サイト:https://simple-qr.netlify.com/ GitHub:https://github.com/KanDai/simple-qr-reader 確認している対応ブラウザは以下です。 Android Chrome Android Firefox iO

    Webの技術だけで作るQRコードリーダー - Qiita
  • 憧れのTypeScriptフルスタック環境がコマンド1発で作れる超軽量フレームワーク「frourio」 - Qiita

    今年6月のTypeScript Meetup #4で初公開されたTypeScript製フレームワーク「frourio (フルーリオ)」が今月のアップデートでめちゃくちゃカッコいい感じに仕上がっているので紹介します frourioはフロントからバックエンド・ORマッパーまでのアプリ全体を一つのTypeScriptとして統合型チェックが可能になるフレームワークです 1つのディレクトリで完結するので一見するとモノリシックのようですが、型で繋がっていること以外はフロントとバックが個別のプロジェクト扱い(それぞれに別のpackage.jsonがある)なのでフロントはVercel、バックエンドはDockerAWSにデプロイするみたいなことが可能です 新しいfrourioの特徴 TypeScript製で最速のフレームワーク コマンド1発でフロントSPA + RESTサーバー + ORマッパーの環境構築

    憧れのTypeScriptフルスタック環境がコマンド1発で作れる超軽量フレームワーク「frourio」 - Qiita
  • Google Data Studioでオープンデータを可視化してみた - Qiita

    クエリを実行する 今回は、世帯年収毎にグループ化しそれぞれの生活への満足度の回答を集計します。 また、それぞれの回答に対して「as~」で名前を付け、わかりやすくしていきます。 そして「is not null」 で年収質問への無回答者を省く対応も行います。 コードはこちらです。 SELECT annual_income, count(satisfaction = 1 or null) as Extremely_Satisfied, count(satisfaction = 2 or null) as Satisfied, count(satisfaction = 3 or null) as Dissatisfied, count(satisfaction = 4 or null) as Extremely_Dissatisfied, count(satisfaction = 5 or nul

    Google Data Studioでオープンデータを可視化してみた - Qiita
  • 技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita

    はじめに 稿は、ソフトウェア開発を進める際に直面する様々な技術的な意思決定やライブラリ・フレームワーク・XaaS等を選択し正しく活用していくのかについての考え方をサポートすることを目的としています。「すべてにおいてこのようなワークフローを通じて検討すべきである」という主張ではありません。読者の抱える問題領域に応じて、必要な箇所を取捨選択するための1種の考え方を提供するものです。 そもそもアーキテクチャ・技術選定に時間をかけるべきか まず第一に伝えておきたいことは、技術選定やアーキテクチャ設計に常に慎重であるべきではないということです。ソフトウェアの規模やライフサイクルに応じて、そもそも時間をさく必要がないということも多くあります。書き捨てのシェルスクリプトにも読みやすいコードを求めて書くことは非常に重要ですが、だからといって組織だって議論・検討するようなものでもないのです。一方で、5年も

    技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
  • GraphQLとPersisted Query - Qiita

    最近、GraphQL APIをインターネット上に晒す上で何を考慮したらいいのだろうか、的なことを考える機会が多く、空いた時間でチマチマと素振りしています。 今日はGraphQLのクライアント - サーバー間に挟むリバプロ的な機能について書いてみようと思います。 やりたいこと 1. 想定しないクエリの排除 例えばECやメディアサイトのような、未ログインでも情報の閲覧が可能なサービスのWeb API層をGrahpQLで実装したとします。ECにしろメディアにしろ、詳細ページでの回遊率を上げるため、詳細同士を関連付けるようなスキーマ設計となるのは自然なことでしょう。 GrahpQLのスキーマ定義で書くと、下記のようなイメージです。 type Product { id: ID! name: String! relatedProducts: [Product] } type Query { produ

    GraphQLとPersisted Query - Qiita
    toshipon123
    toshipon123 2020/11/14
    graphsqlにおける権限やキャッシュのおはなし
  • Goの初心者が見ると幸せになれる場所 #golang - Qiita

    公式サイト A Tour of Go Web上で実行しながら学ぶことができる公式のチュートリアルです。 チュートリアル 公式のチュートリアルです。初学者向けからジェネリクスのチュートリアルなども用意されています。 A Tour of Goが終わった後に取り組むと良いでしょう。 Go Wiki Go Code Review Commentsなどが掲載されているGitHub上のWikiです。 パッケージドキュメント 標準パッケージやサードパーティ製のパッケージのドキュメントが見れるサイトです。検索もできます。 入門 プログラミング言語Go完全入門 筆者が作っている巨大なGoの入門資料です。なぜGoが作られたのか、から最新のジェネリクスの情報、静的解析まで扱っています。 Gopher道場 Goを体系的に学べる場です。10時間くらいある動画教材(自習室から入手可)もあります。 Go の最初の手順

    Goの初心者が見ると幸せになれる場所 #golang - Qiita
  • ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが? - Qiita

    ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが?LaravelDDD設計アーキテクチャCleanArchitecture ある日夢の中で設計に詳しい悪役令嬢が現れてこんなことを言い放ったので、考察してみましたという設定のポエムです。 問題提起 ドメイン駆動設計、オニオンアーキテクチャ、クリーンアーキテクチャといった考え方はもちろん重要なものの、僕は難しく考えずに「削除しやすいように機能を作る」のが第一歩として重要ではないかと考えています。 記事では「削除しやすい設計」について持論を展開してみます。 ※議論のスコープはWebサービスに限定し、例示としてPHPのフレームワークであるLaravelを用います 削除しやすいことがなぜ重要か 一度開発した機能は、それで終わりではなく、改修、改善を繰り返し、そして場合によっては仕様が廃止さ

    ご主人様、小難しいDDDやクリーンアーキテクチャはお忘れになって、”削除しやすい設計”から始められてはいかが? - Qiita
  • Amazon ECSのタスクロールとタスク実行ロールの違い - Qiita

    EC2で動かしているケースにおけるEC2のIAMロールみたいなもの。 主にアプリケーションが使用する権限を付与する。 たとえばS3やElasticSearchへのアクセス権限付与などだろうか。 EC2でタスクを動かす場合、タスクロールと同じ権限を ホストであるEC2のIAMロールに付与する必要はない。 (EC2のIAMロールなしでタスクロールだけでもOK) Fargateだとタスクロールだけしかないのでわかりやすいが ECSをEC2で使っていると権限設定の仕方によっては 単純な二重管理になってしまうような気がした。 (特にタスクを1つしか実行しない場合) EC2のIAMロールでは ・AmazonEC2ContainerServiceforEC2Role ・AmazonEC2RoleforSSM あたりを設定して、他はタスクロールに回すのがいいのかもしれない。

    Amazon ECSのタスクロールとタスク実行ロールの違い - Qiita
  • マイクロサービスでの認証認可 - Qiita

    複数のクラウドサービスを利用している(マルチクラウド)など、単純には閉域網を構築できない環境でマイクロサービスアーキテクチャを採用する場合には、サービス間の認証認可が必要となる。この場合のサービス間の認証認可方式を決める参考となる、OSSやSaaS、Webサービスで採用方式ついて整理した。 Istio サービスメッシュの実装として有名なIstioではサービス間通信を以下のように制御できる。 Istioの認証認可では認証主体がService Identityというモデルで抽象化され、KubernatesやIstioで定義するService Accountに加えて、GCP/AWSのIAMアカウントやオンプレミスの既存IDなどをService Identityとして扱うことができる。 サービス間の認証 (Peer Authentication) は、各サービス (Pod) に設置するSideca

    マイクロサービスでの認証認可 - Qiita
  • Adobe製デザインシステム「React Spectrum」がすごいので紹介したい - Qiita

    🚀 Super excited to announce: ♿️ React Aria — Accessible UI primitives for your design system. 👑 React Stately — State and core logic for your design system. 🌈 React Spectrum — Adobe’s design system. Learn more: https://t.co/ucVguh3rqp Github: https://t.co/e8aOfLgCVK — Devon Govett (@devongovett) July 15, 2020 7月15日にAdobeのデザインシステム react-spectrum がリリースされました。 デザイン製も優れていますが、他の部分でのクォリティーが個人的にショックだった

    Adobe製デザインシステム「React Spectrum」がすごいので紹介したい - Qiita
  • 現代開発者のためのCSS基礎技術 - Qiita

    ウェブアプリケーション開発における、現代的なCSSの基礎技術についてまとめました。 ちまたには「CSSとは何か」を学ぶ教材はたくさんあっても、「CSSをどうやってうまく使うか」についてはあまり詳しく触れられません。 仕様をたくさん記憶したところで、いつになっても開発力はあがらないのです。 記事は「CSSをうまく使う技術」に焦点をあてて、実際に現代的なウェブアプリケーションに求められるレベルのCSSを書くための知識を紹介します。 特に プログラミング経験はあるもののウェブフロントエンドの経験が浅い方 初級レベルのCSSはある程度理解したものの、次にどうしたらいいかわからない方 にお勧めです。 プロローグ CSSの書き方は一通りではありません。 好きな書き方を自由に選ぶことができます。 これは一見すると良いことですが、裏を返すと最適ではない書き方がたくさんあるということです。 この場において

    現代開発者のためのCSS基礎技術 - Qiita
  • GUIテストツール一覧 - Qiita

    GUIテストツールについての比較 現場での:GUIテストツール導入にあたり 「メリット」 と 「デメリット」 を纏めてみました。 (昨今、ツールの数が多く何がどのテストツールがマッチしているのかも含め。) 今まで色々とGUIテストツールの導入検討してきましたが、業務タスクに沿った選定ができればと思い、纏めております。 もちろんテストツールには有償・無償ありますが、「費用対効果も含め」 選定ができれば尚良し。 Seleniumファミリーだけではなく、最近のテストツールトレンド傾向を調査し、どのツールがベストなのか。 Selenium(WebDriver) E2Eテストの王道、WebDriverに依存するため最新ブラウザには注意が必要であるが、プログラミングライブラリが豊富。 ※Seleniumは、テストツールではなく 「ブラウザ操作ツール」 であるがここでは「テストツールグループ」に入れてお

    GUIテストツール一覧 - Qiita
  • プルリク単位でステージング環境をつくる。docker, k8s - Qiita

    自己紹介 @mochizukikotaro 株式会社ベーシック Rails, CakePHP, AWS サーバーサイド、フロントを書きます インフラはほぼ触っていません これまで dev: Vagrant stg: Itamae, Capistrano prd: Itamae, Capistrano いま dev: Docker stg: Docker, k8s prd: Itamae, Capistrano 今後 番も Docker 試してみたい... 社内の日常 1日に何個も PR が出てきて、何回か番をデプロイをやるような環境ですので、ステージングが渋滞気味になることがありました。 なので PR ごとに動作確認ができるようなステージング環境がボコボコできたらいいなと思っていました。 Heroku Review Apps でできます。 それを、docker, k8s をつかって自前

    プルリク単位でステージング環境をつくる。docker, k8s - Qiita
  • ワイ「何でそんな小っさいコンポーネント作ってるん?w」 - Qiita

    とあるWeb制作会社にて ワイ「ハスケル子ちゃん」 ハスケル子「はい」 ワイ「今日ワイは何の仕事するんやったっけ?」 ハスケル子「確か今日からは」 ハスケル子「Nuxt.jsとVuetifyを使って管理画面を作る案件が始まるんじゃなかったでしたっけ?」 ワイ「おお、せやった」 ワイ「とある管理画面のフロントエンド開発をするんやったな」 ハスケル子「もうFigmaのデザイン見ましたか?」 ワイ「ヒグマ?」 ワイ「ヒグマなんて、写真でしか見たことないけど」 ハスケル子「Figmaです」 ハスケル子「ブラウザ上でも使えるデザインツールですよ」 ワイ「ああ、そっちな」 ワイ「Higumaのほうね」 ハスケル子「じゃあ、さっそくデザイン見ながら」 ハスケル子「コーディングしていきましょう」 ワイ「おお、頑張っていこか!」 デザインを見てみる ハスケル子「↑このキャンセルボタンとOKボタン」 ハスケル

    ワイ「何でそんな小っさいコンポーネント作ってるん?w」 - Qiita
  • create-react-appからの脱却 - TypeScript,Reduxの導入(RxJS6も - Qiita

    コード書き始めてから1年くらいのNoobです。ぼちぼち、create-react-appにまかせっきりのスタイルから脱却を図ります。ついでに、JavaScript(以下js)で静的型付けを実現するTypeScript(以下ts)、状態管理周りのごちゃごちゃも一掃するためのRedux、それで非同期処理を行うためのRxJS6も導入します。 create-react-appをejectし、とりあえずtsとReduxを使った簡単なページを作成します。 学ぶこと TypeScriptの書き方 Reduxの基的な使い方 Reduxでの非同期処理(redux-observable) ReactTypeScriptとReduxの連携 この記事の対象読者としては、create-react-appで何か作ったことがあって、jsについて基だけはわかるという人を想像しています。基的に読んだ記事へのリンクを

    create-react-appからの脱却 - TypeScript,Reduxの導入(RxJS6も - Qiita
  • 開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiita

    はじめに ソフトウェア開発のチームの生産性や健全性というものは、内部の体感的として理解できるものの、外部の人間からは見えにくいものです。こういった情報の非対称性は開発チーム外の人々との関係の中での問題の原因になってきました。 また、複数の開発チームやプロダクトを束ねるEM、CTOや、管理職にとってそれぞれの状況を客観的な数字やグラフで可視化することは、全体的な戦略を考える上でも重要な参考情報になります。ですが、アンケートやプロジェクト管理を増やすほど、どんどんと開発メンバーに負担をかけてしまうことになり、計測のし過ぎによる疲れなども誘発してしまいます。 稿では、gitリポジトリのログ情報から、いくつかのグラフを生成し、チームの状況を可視化するためのツールgilotを作成したので、その目的と意図、そして使い方、注意点を解説します。 アプローチ方法 gilotのアプローチは、git log

    開発チームの生産性・健全性を客観的に知るためにリポジトリ履歴から機械的に可視化するツールを作った - Qiita