サンプルプロジェクト 構成 イベント駆動と CQRS を意識した、レイヤードアーキテクチャをベースとしたヘキサゴナルアーキテクチャになります。 各層について レイヤードアーキテクチャをベースに、以下の4層に分けています。 プレゼンテーション層: ソフトウェアの入出力を担当 アプリケーション層: ソフトウェアのユースケースを担当 ドメイン層: ドメイン知識を元にしたビジネスのルールや制約、プロセスを担当 インフラストラクチャー層: 技術的関心ごとの全般を担当 ディレクトリ構成 domain/ # ドメイン層 models/ ## ドメインモデルを格納 services/ ## ドメインサービスを格納 application/ # アプリケーション層 use-cases/ ## ユースケースインプットポートを格納 interactors/ ## コマンドにあたるユースケースの実装クラスを格納

この半年で変わったものと変わらないもの - SaaS開発の現場より / Developers Summit 2020 Summer

はじめに こんにちは、ダイニーの ogino です。 この記事では GitHub の bug bounty で脆弱性を報告し、実際に報奨金を受け取った時の体験を共有します。 私は特にセキュリティの専門家ではなく、偶然に問題を見つけて初めて報告をしました。読者の方が同じようなチャンスに遭遇した時スムーズに行くように、海外からお金を受け取る上での意外なつまずきポイントや、実際に貰える金額などについて紹介します。 どんな問題を見つけたのか 今回見つけたのは、GitHub Copilot の VSCode 拡張機能に関する問題です。 この拡張機能のソースコードは本来公開されていないはずですが、TypeScript のソースマップによって元のコードが露出していました。 そもそも VSCode の拡張機能は .vsix という拡張子の付いたパッケージ形式で配布されます。これは実態としてはただの zip

2025/03/27追記 Cursor側のアップデートが1ヶ月で進んでいるので、以下追記しました。 本記事の内容を踏まえたあとに読むとよいかと思います！ はじめに こんにちは。Builtoという会社で代表 & エンジニアをしている冨田です。 私たちはマネジメントとタスク管理を圧倒的にサポートするAIエージェントを開発しています。 開発にもAIをフル活用しており、そこで得られた知見を共有したいと思います。 具体的には、経験3年以上の現役ソフトウェアエンジニア（生成AIのない時代からコードを書いてきた方々）をターゲットに、本番運用レベルの大規模コードベースでもCursorを活用しコーディング時間を 1/3〜1/5 に縮めている手法をお伝えします。 仕様策定やアプリの機能にもLLMをフル活用していますが、今回は実装にフォーカスします！ （なお本記事は中級者以上向けのため、まだCursorに触れた

AWSを使っている方なら、dwar.ioを使って構成図を書く機会が結構あると思います。構成図を書く時のイラッとをなくすレイヤーという機能を知ったのでご紹介したいと思います。え？今更知ったの？そんなの知ってるよ。と言われちゃうかもですが、ご紹介させてくださいませ。 その前に、構成図書く時にどう書いたら良いんだろう、、、となる時ありますよね。参考にしている良い記事あるのでご紹介させてください。今まで結構雰囲気で書いていたのですが、この記事を見てから綺麗にかけるようになりました。 AWSのアーキテクチャ図を描くときに意識していること それではレイヤーのお話に行きたいと思います。ECSコンテナを編集したい場合、まずレイヤーを使っていないときは、こうなりますよね。 邪魔なのをどかしてどかして、やっと編集できます。次回すぐ編集できるように最前面に移動することもあるかと思います。これレイヤーを使うとこん

🕹 Puppeteer is a Node library which provides a high-level API to control headless Chrome or Chromium over the DevTools Protocol. This guide has recipes for automating Web Performance measurement with Puppeteer. An accompanying GitHub repository for this write-up is also available. Get a DevTools performance trace for a page load Puppeteer API: tracing.start() const puppeteer = require('puppeteer'

有給消化期間中に前から気になっていたNixを使い始めたはなし。 fastfetchの出力 Ansibleによるセットアップ #以前はAnsibleを使ってMacbookをセットアップしていた。 正直特に不満はなく、足りない部分は自分でモジュールを書いたりして便利に使っていた1。 不満点があるとすれば、Ansibleのplaybookを管理しているgitリポジトリをprivateにしていたこと。 ssh用の秘密鍵やGitHubのtokenなど、秘密情報はAnsible Vaultで暗号化して保存していた。 暗号化しているとはいえ秘密情報は秘密情報なので、publicにする気にはならなかった。 privateなので、当然playbookを直接共有することができず、不便を感じていた。 ただ、これは秘密情報をどう扱うかという構成に関する不満であって、Ansibleに対する不満ではないのはお察しの通

海外で働くということ 1ヶ月ほど休みを取って、その国に行き、仕事を探すつもりだ。そういう意味のことを、その人はいっていた。そして欧州のある国の名前を挙げた。知的で真面目そうな風貌。それなりの年代だろうか。そして続けた。日本で求職活動をしても、時間ばかりかかって、埒が明かない。やはり現地に行った方が早い、と。 近くのテーブルで耳に入っただけだから、わたしが何かコメントする立場にはない。しかし思った。（この人は中年過ぎて外国人労働者になるのか。それがどういう事なのか、分かっているのかな。家族も居るようだが、どう思っているのだろうか） 『外国人労働者』という言葉は、日本ではなぜか、単純労働者のことだけを指すようだ。だが大学出の知的職業だろうが何だろうが、自営業のプロフェッショナルでない限り、組織に雇われて働くものは労働者だ。そして外国、とくに欧米で働いて、なおかつ一定のリスペクトを受けて自分の地

「AWSセキュリティを「日本語で」学習していくための良いコンテンツをまとめてみた」というタイトルでAWS Summit Japan 2024のCommunity Stageで登壇しました #AWSSummit AWS Summit JapanのCommunity Stageで登壇した「AWSセキュリティを「日本語で」学習していくための良いコンテンツをまとめてみた」の解説です。 こんにちは、臼田です。 みなさん、AWSセキュリティの勉強してますか？(挨拶 今回はAWS Summit JapanのCommunity Stageで登壇した内容の解説です。 資料 解説 AWSとセキュリティの勉強をしていく時、嬉しいことにAWS関連の情報はたくさんあります。しかし、どの情報から勉強していくか迷いますよね？そこで、AWS Security Heroである私がオススメする「日本語で」学習するための良いA

開発サイクルの終盤に近づくと「今回は優先順位の高いここまでを実装して、残りは優先順位が低いのでまたの機会にしましょう」という話になりがちだ。自分もこれまで何度もそうしてきたし、その場の判断としては正しい。が、このやり方に味をしめて常にこの調子で進めて、なんとなく上手く仕事をこなしている気になってしまうことには危機感がある。 以下、普段考えていることを自戒を込めてメモしておく。（なお、筆者の経験は toB ・Web 系・自社開発が中心なので読者の置かれている状況とは一致しないかもしれない） 優先度が低いタスクに着手する機会が一生訪れない 仮にあるタスクの優先度を下げたとする。バックログを眺めるとそのタスクに着手できそうなのは３ヶ月後だ。そして３ヶ月後、やっとそのタスクに着手できるかというと、そんなことは決してない。３ヶ月の間にそれよりも優先度の高いタスクが積まれているからだ。タスクを消化する

TL;DR 自身の成果をアピールするために、1)Before/After、2)自分の寄与度、3)数字的インパクトを過不足なく伝えることが重要 説明の冒頭では、課題と解法の全体感と成果を述べ、詳細は後に肉付けすると伝わりやすい 課題を伝える際は"誰から見た課題か"を明確にする。課題は解法の前提であるためブレないように はじめに 技術広報のしゅーぞーです。この記事では、過去100人分程度の成果報告書を読み、気付いた "自分の成果をわかりやすく伝える書き方"をまとめています。 仕事をしていると自身の成果を的確に伝える機会は数多くありますよね。 評価期、転職面接、昇格面談など 評価者に自分の成果をどう分かりやすく伝えるか は自分のキャリアを伸ばす上でとても大事なスキルです。 しかし、自分の頑張りや成果を上手く言語化し、相手に正しく理解してもらうのは簡単ではありません。 特に、経験の浅い若手にとって

これは、複数の他社の人から聞いた話をくっつけたり混ぜたり脚色した話になる。つまるところフィクションだ。 あるIT企業ではチームごとに始業時にスタンドアップミーティングを行っている。スクラムで言うところのデイリースクラムである。よくあるやつだ。 ある日、5〜6人くらいの小規模チームに新しいメンバーが加入した。新卒ではないけれど第二新卒くらいの若さのメンバーであった。将来的にはリードする役職（テックリードだったり、デザインリードだったりそういうやつ）につきたいという、意欲のあるメンバーだ。仮にメンバーを山田としよう。 入社後しばらくした山田からマネージャーに相談があった。 「毎朝、スタンドアップミーティングをしているが、時間の無駄にしか感じない。それぞれが進捗を共有するが、自分には関係ないタスクの話を聞いても意味がないので早くタスク消化に入りたい。」 マネージャーはスタンドアップミーティングの

この記事は、慶應理工アドベントカレンダー2021の20日目の記事です。 カレンダー全日埋まってすごい 🎉🎉 adventar.org 「Database Design and Implementation」という簡素なDBをスクラッチで作っていく本に取り組んだので、その読了エントリです。 Database Design and Implementation: Second Edition (Data-Centric Systems and Applications) (English Edition) 作者:Sciore, EdwardSpringerAmazon こんな人におすすめ MySQLやPostgreSQLを使った経験はあるが、DBの理論やその実装はあまり詳しくない人に特におすすめです。特に自作〇〇*1に興味がある人は間違いなく楽しめると思います。単純に本に紹介されている理論

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

「Developers Summit 2021 Summer」での登壇資料です。 https://event.shoeisha.jp/devsumi/20210730/session/3243/

Developers Summit 2021 Summer (2021/07/30)の登壇資料です。 https://event.shoeisha.jp/devsumi/20210730/session/3249/

プログラミング言語のお作法から外れたコードやメンテ性が悪いコードを書くのはダメとよくいわれます。わたしは学生の頃、そういう意見を過剰に気にしていました。コードを書くことそのものに慣れていないのに綺麗に書こうとして手が動かず、動かないがゆえにコーディングの練習が進まない、という悪循環になっていました。そうすると何もアウトプットしないまま知識だけが増えていって、自分がこれくらいできそうというイメージと実際のプログラミング能力とのギャップで苦しみました。 この意識が薄れたのは、あるときものすごく手が早い人のコードを偶然見たときでした。たしかにちゃんと動くものができているんですが、そのコードの中身は当時の私の基準からいって*1おぞましいほど汚いものでした。そこで「これはわたしが書けば100倍くらい綺麗なコードを書けるんでは…」と一瞬思ったんですが、その後すぐに「あ、自分は知識はあるけど練習してない

以下のイベントの投影資料です。 https://confengine.com/conferences/scrum-fest-osaka-2021/proposal/15337 お問い合わせは https://twitter.com/nihonbuson まで。 【発表資料中のURL】 P…