タグ

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

  • AWS認定11冠達成したので振り返りと個人的ロードマップを考えてみた - Qiita

    はじめに 今月未取得だった残りのAWS認定試験に合格して、無事に11冠を達成したので振り返りと個人的なロードマップを考えてみました。 この記事がどなたかのご参考になれば幸いです。 謝辞 自分が合格できたのは、他の方の合格記や出版された対策、練習問題をまとめて公開してくださっている方々のおかげだと思っています。 まずはその方々に感謝させていただきます。ありがとうございました。 この記事でわかること AWS認定試験の(個人的)お勧め取得順 AWS認定試験の(個人的)勉強方法 事前情報 AWS経験は2年と半年程度 普段はデータ分析系のサービスを使うことが多い 最近は業務でセキュリティ周りのこともやる機会が増えてきた 注意 記事に書いてあるのはあくまで個人の意見です。 受験される方の性格や所有スキルによってこの勉強法が合わない可能性があります。 自分は資格試験を必要なスキルの知識を手っ取り早く

    AWS認定11冠達成したので振り返りと個人的ロードマップを考えてみた - Qiita
  • すべての開発者へ。すごいGitHubリポジトリ10選 - Qiita

    記事は、Simon Holdorf氏による「10 Extraordinary GitHub Repos for All Developers」(2021年4月4日公開)の和訳を、著者の許可を得て掲載しているものです。 こちらもどうぞ すべてのウェブ開発者へ。人気GitHubリポジトリ9選 面接のリソース、build your own X、優れたパブリックAPIのリストなど Photo by Vishnu R Nair on Unsplash はじめに GitHubは、あらゆる種類の技術、フレームワーク、ライブラリ、コレクションなどを共有するためのNo.1プラットフォームです。しかし、その巨大さゆえに、最も有用なリポジトリを探すのが難しいという問題もあります。そこで私は、すべてのソフトウェアエンジニアに大きな価値のある、素晴らしいリポジトリ10選を作ることにしました。すべてに多くのGitH

    すべての開発者へ。すごいGitHubリポジトリ10選 - Qiita
  • 技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita

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

    技術選定/アーキテクチャ設計で後悔しないためのガイドライン - Qiita
  • 2020年現在のNewSQLについて - Qiita

    Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較 NewSQLのコンポーネント詳解 1章から3章までの内容を当記事で解説する。 4章はさらに詳細な技術的解説となり、後編の「NewSQLのコンポーネント詳解」で記述している。 こちらも合わせて一読いただきたい。 1. NewSQLとは何か NewSQLとは、海

    2020年現在のNewSQLについて - Qiita
  • GoのGCを10分で学ぼう  - Qiita

    はじめに GoのGC(Garbage Collection)を調べる中で学んだことをなるべく分かりやすく簡潔にまとめたものです。 GCのアルゴリズムやメモリ割り当てについてまとめています。 記事内で使われている「オブジェクト」という用語はGoにおいては適切でないかもしれませんが、説明のしやすさから使用しています。 概要を把握しやすいように単純化しているため細部は正確でない部分があります。 GC基 用語集 前提となる用語です。 ルート ルートとは、オブジェクトが到達可能か(生存しているか)を判定するための始点です。 プログラミング言語にもよりますが、基的にメモリのスタック領域がルートになります。 フラグメンテーション フラグメンテーションとは、使用可能なメモリが断片化し途切れ途切れになっている状態です。 フラグメンテーションになってしまうと、総量的にはメモリが空いていてもアプリケーション

    GoのGCを10分で学ぼう  - Qiita
  • Protocol Buffers(proto3)でoptionalをどう扱うか - Qiita

    2021.4.14 追記 proto3で削除されたoptionalですがv3.15(experimentalオプションを利用する場合はv3.12)から正式に実装されたため、それ以降のバージョンを利用する場合は素直にoptionalを利用してもらうのがいいと思います! https://github.com/protocolbuffers/protobuf/releases/tag/v3.15.0 Protocol Buffersはproto3でrequiredとoptionalが削除されました。 そもそも削除された経緯に関しては、@qsonaさんのエントリーにて、分かりやすくまとめて下さっています。 そこで課題になるのが、proto3において各フィールドは全てデフォルト値を持つため、デフォルト値が設定されたフィールドが利用側から 1. 意図的にセットされたデフォルト値と同様の値 2. 存在し

    Protocol Buffers(proto3)でoptionalをどう扱うか - Qiita
  • トップデベロッパーになるために作成したいアプリ8選 - Qiita

    こちらの記事は、Indrek Lasn 氏により2017年 12月に公開された『 The Secret to Being a Top Developer Is Building Things! Here’s a List of Fun Apps to Build! 』の和訳です。 記事は原著者から許可を得た上で記事を公開しています。 著者Twitter https://twitter.com/lasnindrek 少し考えてみてください。あなたがもし健康に関する書籍をたくさん読んだとしても健康になることはありません。実際には、ジムに行き数時間運動をして汗をかかなければ健康は手に入りません。 同じことが開発にも言えます。努力なしに優れたデベロッパーになることはできないのです。 そこで、コーディング力を鍛える8つの素晴らしいプロジェクトを紹介します。 あなたの好きなテクノロジースタックを使っ

    トップデベロッパーになるために作成したいアプリ8選 - Qiita
  • Linux ファイルシステムを理解したい - Qiita

    ]# cat /etc/redhat-release CentOS Linux release 7.7.1908 (Core) ]# uname -a Linux localhost.localdomain 3.10.0-1062.1.2.el7.x86_64 #1 SMP Mon Sep 30 14:19:46 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux ファイルシステムとは何か? データを管理/操作するための仕組み。 ファイルとディレクトリで構成されていて、/ を基点とした木構造になっている。 # ls -l / 合計 56 lrwxrwxrwx. 1 root root 7 8月 25 01:17 bin -> usr/bin dr-xr-xr-x. 6 root root 4096 9月 29 15:51 boot drwxr-xr-x. 19

    Linux ファイルシステムを理解したい - Qiita
  • 自作OSとかLinuxカーネルについて役立った本 - Qiita

    はじめに なんらかの理由によってOSやOSカーネルに興味を持つ人は多々います。しかし、その次のステップとしてどんなを読めばいいんだろうと思っている人はこれまたいっぱいいます。そこで、長年Linuxカーネルにかかわってきた筆者がこれまでに読んでよかったと思うものについてここの列挙しました。紹介するのはだけであって、記事は省いています。もう一点、筆者が書いたものは省いています。 OSそのものに興味を持った人は、その後に興味の方向が次のような二つに分かれることが多いと筆者は考えています。 オレオレOSを作りたい 既存のOSを改造したい この仮説をもとに、それぞれについて筆者がかつて真面目に読んだの中から「自作OS」および「Linuxカーネル」というキーワードでよかったものを挙げておきます。Linux以外の既存OSについては語れるほどの知識はないので書いてません。 筆者について の良し悪し

    自作OSとかLinuxカーネルについて役立った本 - Qiita
  • OAuth 2.0 クライアント認証 - Qiita

    はじめに この記事では、OAuth 2.0 の『クライアント認証』について説明します。 RFC 6749 に記述されているクライアント認証方式のほか、クライアントアサーションやクライアント証明書を用いるクライアント認証方式についても説明します。 1. クライアント認証方式 1.1. トークンエンドポイント 認可サーバーがあります。 認可サーバーからアクセストークンの発行を受けたいクライアントアプリケーションがあります。 アクセストークンは、幾つかの例外を除き、認可サーバーのトークンエンドポイントから発行されます。そのため、認可サーバーはトークンエンドポイントを用意します。 クライアントアプリケーションは、アクセストークンの発行を受けるために、トークンエンドポイントにトークンリクエストを投げます。 認可サーバーは、トークンレスポンスを返します。この応答の中に、アクセストークンが含まれます。

    OAuth 2.0 クライアント認証 - Qiita
  • dockerでvolumeをマウントしたときのファイルのowner問題 - Qiita

    dockerでvolumeをマウントするときの問題点 docker runするときに-vオプションをつけることによってホストのディレクトリをコンテナ内にマウントすることができる。 ホスト側のファイルをコンテナ内で使いたい場合や、逆にコンテナで作ったファイルにホストからアクセスしたい場合に有用なのだが、ファイルのアクセス権限についてちゃんと考えておかないと問題が起きることがある。 例えば、ホスト内でのユーザーのuidが500だったとしよう。 $ id uid=500(ec2-user) gid=500(ec2-user) groups=500(ec2-user),10(wheel),497(docker) $ mkdir -p temp && touch temp/foo # 実験用に適当なディレクトリを作ってみる $ docker run -it -v $(pwd)/temp:/temp

    dockerでvolumeをマウントしたときのファイルのowner問題 - Qiita
  • Ricty を神フォントだと崇める僕が、フリーライセンスのプログラミングフォント「白源」を作った話 - Qiita

    誰もが知る(?)プログラミングフォントこと Ricty にインスパイアされ、Ricty のように英文フォントと和文フォントを合成したプログラミングフォントを作りました。 その名も、プログラミングフォント「白源 (はくげん/HackGen)」です! 白源 (はくげん/HackGen) 通常版 生成元にはプログラミング向け英文フォント Hack と、Adobe 製作の源ノ角ゴシックに丸みを付けた派生フォント 源柔ゴシック を使用させていただきました。 白源の生成元である Hack、及び源柔ゴシックには、いずれも SIL Open Font License Version 1.1 という大らかなライセンスが適用されているため、改変及び配布が自由となっています。したがって、白源の生成済みフォントファイル (ttf ファイル) は GitHub からダウンロードして、すぐにご利用いただけます。 「白

    Ricty を神フォントだと崇める僕が、フリーライセンスのプログラミングフォント「白源」を作った話 - Qiita
    ttakezawa
    ttakezawa 2019/05/29
    事あるごとに他のフォント試してはRictyに戻ってたけど、今度こそはRictyから乗り換えそう
  • 実装者による Financial-grade API (FAPI) 解説 - Qiita

    注記: 2021 年 3 月に公開された FAPI 1.0 最終版に対応するため、記事の内容を大幅に更新しました。タイトルも『世界最先端の API セキュリティ技術、実装者による『FAPI(Financial-grade API)』解説』から『実装者による Financial-grade API (FAPI) 解説』に変更しました。記事の英語版は "Financial-grade API (FAPI), explained by an implementer" です。 はじめに Financial-grade API(通称 FAPI; ファピ)は、OpenID Foundation の Financial-grade API ワーキンググループが策定した技術仕様です。OAuth 2.0 と OpenID Connect(以降 OIDC)を基盤とし、より高い API セキュリティーを必

    実装者による Financial-grade API (FAPI) 解説 - Qiita
  • トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita

    トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べたAPIOAuthWeb TL;DR HTTP でトークンを利用した認証・認可をする手法として RFC 6750 がある OAuth に限らず、トークンを利用して認証・認可する機構の一部として Authorization: Bearer ヘッダを使うことができる 使い方について詳しくはこの記事の下のほうに書いた 要求 トークンを利用した認証・認可機構を持つ API を作りたい クライアントがトークンを HTTP リクエストに含めて送信し、サーバはトークンを検証してリソースへのアクセスを許可したい Authorization: Bearer トークン ヘッダでトークンを送る API あるよね、ああいうやつ 疑問 Authorization: Bearer ヘッダは OA

    トークンを利用した認証・認可 API を実装するとき Authorization: Bearer ヘッダを使っていいのか調べた - Qiita
  • C++標準化委員会、ついに文字とは何かを理解する: char8_t - Qiita

    C++ Advent Calendar 2018 この記事はC++ Advent Calendar 2018 15日目の記事です。 14日目: VTKライブラリ 16日目: C++のエラー処理との付き合い方 当初見積もりよりも大幅に長い記事となり、投稿したのは12/22で1週間遅刻です。すみません。 お知らせ cpprefjpにchar8_t型追加について解説を書きました。ぎゅぎゅっとコンパクトに、また査読を受けて中立的な表現で書いていますので、よければどうぞ。 UTF-8エンコーディングされた文字の型としてchar8_tを追加 - cpprefjp C++語リファレンス 追記 全ての開発者が知っておくべきUnicodeについての最低限の知識 - GIGAZINE Unicodeについて簡潔にまとまってるいい記事を見つけました。 Caution この文章には以下の要素が含まれます。苦手

    C++標準化委員会、ついに文字とは何かを理解する: char8_t - Qiita
    ttakezawa
    ttakezawa 2018/12/23
  • Goで書くClean Architecture API - Qiita

    Enterprise Business Rules ビジネスルールの為のデータ構造を持ったオブジェクト。 データの実態を表す場所。 Application Business Rules ビジネスルールを操作する場所。 つまりこのアプリケーションで何ができるかを実践します。 Interface Adapter 外部からの入力、データの永続化、表示を担当する場所 Frameworks & Drivers Webフレームワーク、DB操作の実際に担うソース、 フロントエンドUIなどがここに所属しています。 外側のレイヤーの要素を直接参照してはならない 上記の図におけるこの矢印は依存を表しており、 内側のレイヤーから外側のレイヤーの要素への依存を禁じます。 ここでいう依存とは要素(構造体、変数など)への直接参照をさせないということです。 では外側のレイヤー要素を参照せざる得ないは、どうするのでしょ

    Goで書くClean Architecture API - Qiita
  • Envoy (Envoy proxy)、Istio とは? - Qiita

    Microservices Advent Calendar 2017 14日目の記事です。 今回は、EnvoyIstioという、microservicesの文脈でよく出てくるツールの紹介です。 https://www.envoyproxy.io/ https://istio.io/ どちらも立派な公式ページ/ドキュメントがあり、紹介も何もあったもんじゃないと思われるかもしれませんが、公式ドキュメント上では、とてもたくさんの概念と機能が紹介されていて、私にはこの2つが一体何物なのか中々掴めなかったので、私なりの理解での言葉に置き換えて説明したいと思います。 tl;dr Envoyはmicroservicesなシステムを作るときに必要な機能を提供してくれるside-car proxy。 Istioenvoykubernetes上で使うのを助けてくれるツール。(将来的にはkubernete

    Envoy (Envoy proxy)、Istio とは? - Qiita
  • ECS + Fargate + gRPCを使ったマイクロサービス構成 - Qiita

    バックエンドサーバは機能毎にマイクロサービスとして分割し、サーバ間通信には gRPC を使ってモダンな感じにしたい。 最初のインフラ構想 まず Node.js アプリケーションをコンテナベースにして、Code Pipeline + CodeBuild + ECR + ECS + Fargate で継続的デプロイ&オートスケールする仕組みを作った。 でもバックエンドの gRPC でサーバ間通信を行う部分で Unavailable, transport is closing というエラーになってしまいうまくいかなかった。 この ALB を使って ECS タスクに対して負荷分散させる構成は gRPC を使わずに REST API でならうまくいった。 HTTP/2 の gRPC は ALB と相性が悪い gRPC は HTTP/2 が必須となり、ALB も HTTP/2 に対応しているが、それは

    ECS + Fargate + gRPCを使ったマイクロサービス構成 - Qiita
  • 心理的安全性ガイドライン(あるいは権威勾配に関する一考察) - Qiita

    はじめに 「心理的安全性」とは、「対人リスクを取っても問題ないという信念がチームで共有されている状態」であるとか、「自分のキャリアやステータス、セルフイメージにネガティブな影響を与える恐れのなく、自分を表現し働くことができること」というような定義がなされています。 心理的安全性という言葉はともすれば、ただ快適で居心地のよい職場という意味にも聞こえます。そのため、ぬるま湯で緊張感のない関係性のことを「心理的安全性が高い」と言うのではないかと考えても不思議はありません。 そのため、友人関係のようにプライベートの時間を長く共有する関係になることが、心理的安全性が高いのだろうと考え、飲み会やバーベキュー、慰安旅行などを企画してみたりとプライベートでも遊ぶ機会を増やそうと考える人もいるでしょう。 いわゆる「アットホームな会社です」とアルバイトの求人記事に書かれているような状態です。こういった求人内容

    心理的安全性ガイドライン(あるいは権威勾配に関する一考察) - Qiita
  • Electronより軽くて手軽なlorca製デスクトップガワアプリのススメ - Qiita

    最近ScrapboxデスクトップPWAとして使い始めました。 やはりデスクトップアプリとしてDockに表示されるだけで体験はすごく良くなるなー PWAもっといろんなサービスで使えるようになってほしいです(オフライン動作とかとりあえず要らないんでアプリとしてインストールだけでもさせてほしいなぁ) Webサービスデスクトップアプリ化で感じる利点は、具体的にはショートカットやSpotlightで呼び出しやすいといったことくらいなのですが、OSのインタフェースから自然に使えるという体験はヘビーユースしているWebサービスを更にヘビーに使うきっかけになりえるなと。 自分自身、よく使うWebサービスは個別アプリにしたいと日頃から思っており、Electronを使ってよく使うWebサービスは個人利用用にアプリ化したりしてました。 ただElectronはアプリサイズが大きいのと、Gmail等一部のWeb

    Electronより軽くて手軽なlorca製デスクトップガワアプリのススメ - Qiita