はじめに Spring Security プロジェクトは、認可サーバーの実装を今後サポートしない旨、2019 年 11 月 14 日付の『Spring Security OAuth 2.0 Roadmap Update』でアナウンスしました。しかしその後、一部の有志が Spring の認可サーバー実装プロジェクト『Spring Authorization Server』を開始しました。この記事は、そのプロジェクトに対する警鐘となります。 OAuth 2.0 Multiple Response Type Encoding Practices 2012 年 10 月の RFC 6749(The OAuth 2.0 Authorization Framework)のリリースから 1 年 4 ヶ月後の 2014 年 2 月、OAuth 2.0 Multiple Response Type Enco
アジャイル開発をはじめて体験すると、いろいろな考え方を身につけるために苦労をすることがあります。 特に、相対見積もりや、ベロシティによる経験主義的な見通しの取り方について、実際に経験せずに理解するのは難しいようです。 そこで今日は、日常生活の中で馴染みの深い考え方を使って、説明を試みてみたいと思います。 「コース定数」でアジャイルな見積もりを考えてみる 国民的な娯楽である登山をやられる人なら誰もが知っている「コース定数」という考え方があります。みなさんもご存知かと思いますが、簡単に解説します。 山は、事前の計画がとても重要でありつつも、実際に登ってみないとコースの状態や、自分の体力がその山に適しているのかがわかりづらい遊びです。そういう意味では、経験主義的なアプローチが必要なソフトウェア開発に似ているとも言えます。 交通機関やレスキューの体制が整備されている街中と違い、山は自分の体がすべて
みなさんさようなら,最近デプロイが趣味の@h3_potetoです. この記事は,僕が趣味で改善していたCrowdWorksのデプロイ周りの大改造の歴史を振り返ります.基本的には,デプロイが趣味の方向けの記事です.とても長いです. 手動構築の時代 その昔,CrowdWorksのサーバは手動で構築されていました. 手動でRuby等の設定をいれたサーバを複数台用意し,そこにcapistranoデプロイをしていました. インフラは手動構築だった割に,なぜかBlue/Greenデプロイを実現していました. Blue/Greenの実現方法 まずはじめに, Blueが稼働系 Greenが待機系 です. Blue/Greenデプロイをする際には,Green系にデプロイをして,Blue系と挿げ替え,旧Blue系をそのまま廃棄します. この動作をどこで実現しているかというと,なんとCrowdWorksのアプリ
3. 8 Architectureとは ● Martin Fowler 「重要かつ変更が困難な意思決定であ る」 ● Grady Booch 「システムを形作る重要な設計上の意思決 定であり、その重要性は変更のコストによって測られる」 ● Michael Keeling「ソフトウェアが望ましい品質特性や他 の性質をどうやって達成していくかについての重要な設計 上の意思決定である」 Design It! Architecturally Significant Requirements (ASR) 4. 9 Architectural Significant Requirements 構造 アーキテクチャのパターンやスタイルに影響を与える決定 例) マイクロサービス間のデータの共有の仕方 機能特性 技術の選択がパフォーマンスに影響を与え、パフォーマンスがアプリケーションの重要な側面である場合
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
フリーランスエンジニア。システム開発のよろず相談受付中。Java、テスト自動化、モデリングなど、コード/アーキテクチャ/チームなど幅広くカバー。 「Javaエンジニア養成読本」の「Java入門」、WEB+DB PRESS vol.92 - 104で「Javaの新定石」などを執筆。 あたりまえのことがあたりまえに行われる開発を実現するため、自身の「ふつう」を色々な形で発信中。 「他言語のシステムをJavaに移す、『揺れ戻し』のトレンドがある。」 そう語るのは関西Javaエンジニアの会などのコミュニティ活動も積極的に行われている、フリーランスエンジニアのいろふ(@irof)さん。今回は、いろふさんにJavaの案件のトレンドを踏まえた今後のフリーランスエンジニアに必要なスキルについてご紹介いただきます。 今の案件内容と獲得経路 Javaをメインにフリーランスエンジニアをしている、いろふ(@iro
1970年群馬県生まれ。工作をしがちなため、各種素材や工具や作品で家が手狭になってきた。一生手狭なんだろう。出したものを片付けないからでもある。性格も雑だ。もう一生こうなんだろう。(動画インタビュー) 前の記事:超簡単にペン回しできる指輪を作る > 個人サイト 妄想工作所 10パターン制作の呪い 「顧客が本当に必要だった物」などといきなり切り出してしまい申し訳無い。そういう、IT業界のシステム開発案件における「あるある」を風刺したイラストが存在するのだ。まずはその風刺画の説明をしよう。 私が目にしたのは10年くらい前だったか。面白いし、よくできてるなぁと、定期的に見たくなる絵だ。今回調べて初めて知ったのだが、元ネタはもうすでに70年代からあるという。元は、アメリカ産業界あるあるネタを風刺したイラストだったもよう。 これが「顧客が本当に必要だったもの」の基本イラストだ!(ニコニコ大百科より)
システム開発の世界において「技術的負債(Technical Debt)」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham (ウォード・カニンガム)です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました("Shipping first time code is like going into debt")。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
嫌な意見は「ミュート」できるようになった。山田ルイ53世さんがご機嫌に年を重ねる理由 #エンタメ#老いの準備#楽に生きる 公開日 | 2020/04/30 更新日 | 2020/09/17 お笑いコンビ・髭男爵の山田ルイ53世さん。“貴族のお漫才”で注目を浴び、芸人として世に出たのは31歳の頃。そのままステップアップし、芸人における王道のキャリアを夢見ていた時期もあったと言います。しかし、いつしか世間的な認識は“一発屋”に……。 受け入れがたい現実。当初は抗いながらも年齢を重ね、やがて「諦めの境地」に至ったのだとか。 今年で45歳。今後の仕事や老後についての不安がないわけではありません。それでも、今はそうしたネガティブな思考を「ミュート」できるようになったと山田さん。ままならない現実を受け止め、暮らしていく。そのための心の持ちようについて伺いました。 今回のtayoriniなる人 山田ルイ
Fearless Change のパターンリストを A4 x 2枚 のシートにしました! PDFファイルはこちらです。 Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン 作者:Mary Lynn Manns,Linda Rising出版社/メーカー: 丸善出版発売日: 2014/01/30メディア: 単行本(ソフトカバー)Fearless Change: Patterns for Introducing New Ideas (English Edition) 作者:Linda, Ph.D. Rising,Mary Lynn, Ph.D. Manns出版社/メーカー: Addison-Wesley Professional発売日: 2004/10/04メディア: Kindle版
code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない
はじめに 「解説記事を幾つも読んだけど OpenID Connect を理解できた気がしない」― この文書は、そういう悩みを抱えたエンジニアの方々に向けた OpenID Connect 解説文書です。概念的・抽象的な話を避け、具体例を用いて OpenID Connect を解説していこうと思います。 この文書では、JWS (RFC 7515)、JWE (RFC 7516)、JWK (RFC 7517)、JWT (RFC 7519)、ID トークンの説明をおこないます。 追記(2020-03-20) この記事の内容を含む、筆者本人による『OAuth & OIDC 入門編』解説動画を公開しました! 1. 『ID トークン』を発行するための仕様 一般の方々に対しては「OpenID Connect は認証の仕様である」という説明で良いと思います。一方、技術的な理解を渇望しているエンジニアの方々に対
Abstract OpenID Connect 1.0 は, OAuth 2.0 プロトコルの上にシンプルなアイデンティティレイヤーを付与したものである. このプロトコルは Client が Authorization Server の認証結果に基づいて End-User のアイデンティティを検証可能にする. また同時に End-User の必要最低限のプロフィール情報を, 相互運用可能かつ RESTful な形で取得することも可能にする. この仕様は, OpenID Connect の主要な機能である OAuth 2.0 上で End-User の情報伝達のために Claim を用いる認証機能 を定義する. この仕様はまた, OpenID Connect を利用するための Security, Privacy Considerations を説明する. Table of Contents
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く