clean_architecture.md 2020/5/31追記: 自分用のメモに書いていたつもりだったのですが、たくさんのスターを頂けてとても嬉しいです。 と同時に、書きかけで中途半端な状態のドキュメントをご覧いただくことになっており、大変心苦しく思っています。 このドキュメントを完成させるために、今後以下のような更新を予定しています。 TODO部分を埋める 書籍を基にした理論・原則パートと、実装例パートを分割 現在は4層のレイヤそれぞれごとに原則の確認→実装時の課題リスト→実装例という構成ですが、同じリポジトリへの言及箇所がバラバラになってしまう問題がありました。更新後は、実装時の課題リストを全て洗い出した後にまとめて実装を確認する構成とする予定です。 2021/1/22追記: パートの分割と、クリーンアーキテクチャという概念の定義について追記を行いました。大部分の実装例パートを中心

ZOZO×一休×PayPay AWS Nightは、2020年7月22日に開催されたZOZOテクノロジーズ・一休・PayPayの3社による合同イベントです。各社それぞれAWSの活用事例を紹介します。PayPay株式会社プラットフォームチームの西中氏がPayPayのインフラの概要について話しました（記事内の情報はイベント開催時点のもの）。 日本のNo.1 QRコード決済サービス 西中智樹氏（以下、西中）：「PayPayでのAWS活用事例について」と題して、PayPay Platformチーム・西中が発表いたします。 簡単に自己紹介します。西中智樹と申します。2018年12月よりPayPayで仕事をしていまして、現在、AWSなどのPayPayのインフラを所管するPlatformのチームに所属しています。好きなAWSサービスはEKSです。 本日のセッションのアジェンダになります。この順番でお話を

TL;DR 企画力が…欲しい… pic.twitter.com/hJfr0qNv7T— ゆずたそ (@yuzutas0) 2020年11月19日 試行錯誤の瓦礫の記録です。 はじめに もくじ TL;DR はじめに もくじ 以前書いた記事 前提・免責 アイデア 1日1案（やってよかったこと） 1stスクリーニング（やってよかったこと） コミュニケーション チームへのリスペクト（やってよかったこと） 話す <<< 聞く（改善余地あり） 即決する（やってよかったこと） 自分で各論まで見る（やってよかったこと） 発散→収束でディスカッション（改善余地あり） イラストで話す（改善余地あり） 日次ミーティング（やってよかったこと） 議事録を書く（改善余地あり） 得た情報を共有する（改善余地あり） 想定納期を示す（改善余地あり） カレンダー招待＆日程確約コメントを転記（改善余地あり） プロセス管理 仮説

（訳者注: 原文は https://rubyonrails.org/doctrine/ です。しばらく寝かして問題なさそうであれば本家に投げようかと思っています。おかしいところがあればコメント・編集リクエストをお待ちしております。) The Rails Doctrine By David Heinemeier Hansson in January, 2016 Ruby on Railsの驚異的な台頭は、斬新な技術とタイミングによるところが少なからずあります。しかし、技術的な優位性は時間の経過とともに失われていきますし、タイミングの良さだけでは長期にわたってムーブメントを維持できません。そのため、Railsがどのようにして現役であり続けることができたのかだけでなく、どのようにしてそのインパクトとコミュニティを成長させてきたのかについて、より広範な説明が求められています。私が提唱するのは、永続

これは何 「Rails Wayに沿って〜」とはReview欄などでよく言われるが、定義が人によってぶれている気がするので俺のRails Wayを示した記事です。 もはや本来のモノとは別物かも知れませんが、俺はこういう観点でRailsをみて、コードを書いているよ、ということを知ってもらう意味でもこの記事を公開することにしました。 前提として、「数人以上のチームでプロダクトを実際に開発して運用する」場合の自分のスタンスを示したものです。（私も仕事では独自DSLは書きませんが自由研究用途なら自分も独自DSLを書いたりします。） それでは、いってみましょう。 Model層 データベースの操作およびビジネスロジックを記述する。 テーブルの属性は原則NOT NULLにするべき。どうしても要件上NULLを許容しなければならない場合のみNULLを許容する。 Controllerからparamsを無思考で渡

浄土真宗の僧侶です。初めて書き込みます。 不慣れなため、先ほど書いた文章がすべて消えてしまい心折れかけましたが、やはり大事なことなので、増田さんに伝わればと願って改めて書き直します。 お祖父様のことをお悔やみ申し上げるとともに、今回このような形で、増田さんやお母様が悲しまれる結果になってしまったこと、痛惜に堪えません。 結論から言わせていただくと、リモート葬儀それ自体に否はありません。そんなもので台無しになるのが仏の教えならば、仏法は2500年も受け継がれたりなどしません。 私から言わせれば、死者を軽んじ、葬儀を台無しにしているのは、ご親族の方だと思います。 葬儀とは「弔(とむら)い」であります。弔いとは元来、「訪(とぶら)い」という字を用いました。これは遠近様々な場所から死者の元へと人々が訪れる様子を意味していますが、決してそれだけではありません。 死者に出会うということは、まだ生きてい

$ rails g devise_token_auth:install User auth Running via Spring preloader in process 3685 create config/initializers/devise_token_auth.rb create db/migrate/20180401103356_devise_token_auth_create_users.rb insert app/models/user.rb insert app/controllers/application_controller.rb gsub config/routes.rb GitHubのマニュアルに書いてある通りにこのコマンドを打ったはいいのですが、すでにdeviseを導入しているのでUserモデルはあるんですよね。なので、このままマイグレートしても失敗するのは目

これまでのあらすじ 財テクを書いた後に、いままで賃貸に住んでいて、戸建かマンションを買ってみるかとなった COVID-19 の影響で在宅勤務が長期化しており、都心の 1LDK よりも、少し郊外で広い家に引っ越して、書斎というかオフィス的な空間を自宅内に用意したいと考えた 家の買い方に関する本をいろいろ買って読んでみたり、ネットの記事を読んでみたり、実際にマンションの購入手続きを進めてみたり (途中でキャンセルしたけど) 、仲介業者の紹介でファイナンシャルプランナーに相談したりした 前提 shunirr の独自研究による財テクをまとめています shunirr は、そこそこの規模の会社勤務なソフトウェアエンジニア、東京 23 区内在住、実家は田舎の賃貸で、相続できる資産とかは無い shunirr の思想・価値観によってまとめられているので異なる価値観の人には合わない可能性があります shuni

いよいよSOC(State Of Charge)の表示方法です。関連情報URLのページが、みんカラで愛用している人の多い、ScanGuageIIのトヨタ車のPID情報をまとめているページになります。このページの下のほうに、「Generation III Prius 」となっているところが、現行プリウス(プリウスIII)のPID情報になります。この一番上のStateOfChargeを設定すれば、SOC情報の表示ができるようになるわけです。しかし、この項目は残念ながら、前回設定したプリセットされている、プリウスIIIの拡張IDセットに含まれてません。そのため、下記の手順で、追加を行います。 1.最初の起動画面で、メニューボタンを押す。 2.「設定」を選び、次に「拡張PID/センサ管理」を選ぶ。 3.出てきた画面で、メニューボタンを押し、「カスタムPIDを追加」を選ぶ。 4.下記の画面の通りに設

現在私は barista という OpenID Connect と OAuth2.0 に準拠したID製品の実装を行っています。 また、私の所属する事業開発部では prismatix というEC、CRM の API 製品の開発を行っていますが、この prismatix の認可サーバーとして barista を利用しています。 barista チームの増員や、prismatix の認可についての理解を促進するため OAuth 2.0 をある程度しっかりと理解しているメンバーを増やしたかったので、勉強会を開催しました。 勉強会の内容 概要 雰囲気でOAuth2.0を使っているエンジニアがOAuth2.0を整理して、手を動かしながら学べる本を全員で輪読 OIDC 編はこのあとやる予定 攻撃編もやりたい RFC 読んだりもしたい 参加者全員が以下を満たすことが目標 OAuth 2.0 の意図を理解

この記事はMERPAY TECH OPENNESS MONTHの15日目の記事です。 こんにちは。メルペイのPayment PlatformチームでPaymentServiceの開発を担当するエンジニアの @foghost です。 メルペイではマイクロサービスのアーキテクチャで決済システムを開発しています。その中でPaymentServiceは決済トランザクション管理の基盤サービスとして、下位層のサービス（外部サービスも含め）が提供する各種決済手段を利用して、上位層のサービス（メルカリ、NFC，コード払いなど）に必要な決済フローを共通APIとして提供しています。PaymentServiceが提供する決済処理に複数のサービスを跨いでお金の動きを正確に管理する必要があるので、作り始めた頃から決済トランザクション管理を最も重要な課題として、サービスを跨いでもデータの整合性が取れる仕組みを作ってき

AWS Lambdaの環境がどのようになっているか、ユーザが用意したLambdaファンクションがどんな感じで実行されるかってあたりを可能な限り詳しく説明したいと思います。 はじめに 大前提 コールドスタート/ウォームスタート コントロールプレーン/データプレーン アイソレーション AWS Lambdaのコンポーネント群 同期実行かつ初回呼び出し（コールドスタート）、もしくはスケーリング 同期実行かつ再利用（ウォームスタート） 非同期実行 スケールアップ エラーハンドリング リトライ その他 ネットワーク まとめ はじめに この投稿は2020年9月29日の21時から開催予定のイベント（ライブストリーミング）で話す内容です。 serverless-newworld.connpass.com もし間に合えば、かつ時間があればぜひライブ配信のほうにも参加ください。 （2020.09.30 upda

2年前、ぼくは大好きだったトヨタの人事部を辞めた。 思い返せば、入社式で豊田章男社長がこんなことを言っていた。 「つらいと思ったら、まず3日。3日間は歯を食いしばる。3日頑張れたら、次は3週間。さらにその次は3か月。そして、3年。3年は一生懸命がむしゃらに働きましょう」 トヨタでの3年間は決して「歯を食いしばって耐える」ようなつらいだけのものではなかった。むしろ、たくさん鍛えてもらい、貴重な経験をさせていただいた先輩方を心から尊敬しているし、今でも仕事、プライベートを問わず関係を続けられるその懐の深さには感謝の気持ちしかない。 でもぼくは、結果だけ見ればトヨタを3年でやめた。 最初に書いておくが、ぼくはこの文章のなかで、トヨタを批判するつもりはまったくない。3年ぽっちで見えている部分なんて、ほんのごく一部に過ぎないし、そもそもぼくはトヨタのことが嫌いになって辞めたのではない。 ぼくは日本企

「ビジネスの仕組みがわかる 図解のつくりかた」という本を全文公開します！この本は、2020年4月に出版されたスマホサイズのコンパクトな新書です。『ビジネスモデル2.0図鑑』を出版後、多くの反響をいただき、さまざまな企業でビジネスモデル図解について講演・ワークショップを開催してきたノウハウを凝縮した一冊になっています。 ※当記事の情報を転載、複製、改変等は禁止いたします それではここから全文公開をご覧ください。 第１章：ビジネスモデル図解、基本の「き」はじめに 僕たちが『ビジネスモデル2.0図鑑』を出版したのは２０１８年９月のことです。「Amazon Go」や「Spotify」など、１００の事例のビジネスモデルを同じフォーマットで図解した本は、７万部を超えるベストセラーになりました。その後さまざまな反響を得て、企業から多数の講演・ワークショップの依頼をいただきました。「ビジネスモデルを自分で

3年前に、図解の基本をまとめた本『図で考える。シンプルになる。』を書きました。その内容から、エッセンスを抽出したのが本noteになります。 （１）「幕の内図解」と「イチオシ図解」 図には、大きく分けて、2つのアプローチがあります。 ひとつは、幕の内弁当のように、いろんな要素を盛り込んだ図で、もうひとつが、唐揚げ弁当のように、イチオシのおかずにフォーカスした図です。 たとえば、桃太郎の話を「幕の内図解」のアプローチでまとめてみたのが、つぎの図です。 登場人物とエピソードをフラットに扱って、網羅的に盛り込んでいます。 この図を使って、人に説明しようとすると、「まず、お婆さんですが……」「つづいて、お爺さんですが……」といった具合に、「お婆さん」「お爺さん」「桃太郎」それぞれの視点に切り替えが必要になり、話す方も話しづらければ、聞く方もまどろっこしく感じてしまいます。 相手がじっくり聞く耳を持っ

こんにちは！ リクルートテクノロジーズでセキュリティエンジニアとして活動している、藤原 巧です。 毎年恒例となっており、大きな反響をいただいている、エンジニアコースの新人研修の内容を紹介させていただきます。 研修の概要 リクルートテクノロジーズでは、新卒採用の新人向けに３ヶ月間の技術研修を行っています。この技術研修では大きく分けて２つのコースが設けられています。 1. プログラミングやWebサービスの構造の基礎を体系的に学び、その後一人につき、ひとつのスマホサイトを企画からリリースまで行うコース 2. 一定以上のプログラミングスキルと開発系経験がある新人に向けた、実際の開発で必要となる様々な技術要素をより深く学び、その後実際のサービスでチーム開発にてOJTを行うコース 今回公開するのは 2. で使用した資料です。 この技術研修は、そのほとんどの部分を内製で実施しています。 この研修の最大の