https://fortee.jp/yapc-hiroshima-2024/proposal/1e9fbacd-5a50-43ef-87f1-490e85448f17
Amazon ECSで好きなだけ検証環境を起動できるOSSの設計・実装・運用 / YAPC::Hiroshima 2024
https://fortee.jp/yapc-hiroshima-2024/proposal/1e9fbacd-5a50-43ef-87f1-490e85448f17
2024年1月時点のAWSベストプラクティスに従って作成しました 好評でしたら続編も検討します 1. 環境ごとにアカウントを分離する 本番、検証、開発ごとにアカウントを分割しましょう ✕良くない例 ◎良い例 最初にアカウント分割しておかないと、後で分割するのはとても大変です アカウントを分割することで「検証と思って作業したら、実は本番だった」のような事故を減らすことができます コストがアカウント単位で集計されるため、環境ごとのコストを簡単に算出することができます AWS Organizationsを使用することで、各環境に応じた権限設定が簡単にでき、ガバナンスを強化することができます AWSアカウントはAWS Control TowerのAccount Factoryを使用することで、クレジットカード情報を都度入力することなく簡単にアカウントの払い出しが可能です また、AWS Contro
継承はなんでダメ？ - まめめも
「オブジェクト指向の継承を使うな」という主張が広まっているようです。なんでダメになったんでしょうか。 インターネットで見かけた「継承はダメ」という主張をいくつか眺めて、友人と議論しつつ、考えてみました。 「コードが読みにくくなる」 継承があると、メソッド呼び出しが実際にどのメソッド定義を呼び出すのか字面でわからない。 デバッガを使って、親クラスのメソッドに飛んだり、子クラスに飛んだりするのを追いかけないと行けない。 つらい。という主張。 めっちゃわかる。わかるんですが、これは「高度に共通化されたコードは読みにくい」という一般的な側面がかなり大きいような。 たとえば継承の代わりに高階関数を使うと、関数呼び出しがどのクロージャに飛ぶか字面でわからなくなる。 ひどいとコールバック地獄になって何が何やらになります。 継承がことさらにまずい理由を想像すると、すべてのメソッド呼び出しがポリモーフィック
何度か講演でこの話をしたのだが、気が向いたのでエッセンスを書き下しておこうと思う。 テスト駆動という言葉が流行る前にプログラマとなった私は、当初どのようにテストを書いてよいのか分からなかった。そんなとき、(当時はオーム社で現在はラムダノートの)鹿野さんから「ビューティフルコード」を献本していただいた。分厚い本なので、興味ある章から読んでいった。その一つがアルベルト・サボイア氏が書いた7章「ビューティフル・テスト」だ。 ビューティフルコード (THEORY/IN/PRACTICE) 作者:Brian Kernighan,Jon Bentley,まつもとゆきひろオライリージャパンAmazon この章では、例として二分探索が取り上げられる。二分探索のアイディアが出されたのは1946年だが、バグのない実装ができたのは12年後だという。実際に実装してみると分かるが、ソートされた配列の中に目的の要素が
GraphQL「良さ」・「難しさ」再探訪 〜スタディサプリにおける実例〜 / StudySapuri with GraphQL
2024/02/08 に「LayerX、スタディサプリ、SHEと考える GraphQLが向いている現場とは？運用実践LT」で、内山高広( @highwide )が発表した資料です。 #Offers_GraphQL実践LT
「事前検死」というメソッドを使うと、プロジェクトの失敗率を大きくさげられてオススメ。それ用のGPTsも作った。 事前検死とは？事前検死というのは、失敗学で用いられるメソッド。プロジェクトの一番最初に、「プロジェクトは盛大に失敗したのだ！」という設定で、プロジェクトの生前葬と反省会を行う。 たとえば「新規サービスを作ったがローンチに失敗した何故だ！？」という問いからスタートし、 市場調査をしなかった プロトタイプを作らなかった ゴールラインをリリースに引いてしまっていた など、起こり得るプロジェクトの失敗を最初にシミュレートする。 事前検死の例たとえば、以下みたいに雑に入力した場合も、GPTsさんなら事前検死をしてくれる（もっと丁寧に企画書まるごといれると精度があがる）。 私: スマホを振るだけでビットコインがたまるDAOサービスを作りたい。 以下、AIさんの回答 スマホを振るだけでビットコ
業務システムとオブジェクト指向 - Hot Heart, Cool Mind.
業務システムの設計・開発を職業とする人々の間で、オブジェクト指向はいまだに一般的なものと受け止められていないように思える。しかし実際にやってみると、オブジェクト指向は業務システムにうまく馴染むし、システムの品質とメンテナンス性の改善につながる。 ==== オブジェクト指向の適用例 具体的な例で見てみよう。仕訳を作成して記帳するという、会計システムのもっとも基本的な処理を、Javaでオブジェクトを使って書いてみる： /** * 7月度の「帳簿(book)」を取得する。 */ 1: Book book = application.getBook("2006/7"); /** * 仕訳(JournalSlip)」を生成し、項目を設定する。 **/ 2: JournalSlip slip = book.createJournalSlip(); //仕訳日 3: slip.setJournalDat
定期的に DDD やクリーンアーキテクチャなどを題材にした記事が盛り上がっているのを見ていると、いま長年の疑問を書けば誰か答えてくれるのではと思って書いてみる。 何に困っているかというと、 いわゆるレポジトリ層が持つ create/update 関数の引数は Entity で待ち受けるべきか、プレーンなオブジェクトで待ち受けるべきか分からない ユーザーから POST Body されたデータにはビジネスルールを適用させるべきか（= 一度 Entity を作るべきか）分からない だ。 Entity を作らない場合、いわゆるトランザクションスクリプトと呼ばれているものに近づく。 そしてトランザクションスクリプトには結構否定的な意見も見られる。 しかし、自分は Entity を作ることが必ず正解とは思えず、レイヤードな設計とトランザクションスクリプトを組み合わせる設計の余地もあると思っていて、トラ
運用設計における設計項目の体系化 / 20240207-ssmjp-operation-design-items
ssmjp ssmonline #38 "第四回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/307397/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)
続いてそれぞれのユースケースについて、具体的な使い方を解説します。 Figmaの使い方・操作方法 デザインをもとにコーディングする場合 ‐ Dev mode Dev modeの利用がおすすめです。現在ベータ版で公開されており、2024年中に有料プランのみ使用可能となります。 主な機能として、作成したデザインをもとにコードを自動で生成させることができます。CSS、iOSのSwiftUI、AndroidのXMLなどに対応しています。 具体的な使い方は次のとおりです。今回はログイン画面を例にしています。 画面をセクションで囲む セクション名の右横のコードアイコンをクリック Open in Dev modeでDev modeに切り替える コード化したいコンポーネントを選択すると、右側のInspectでコードを参照できる ワイヤーフレームを作成する場合 ‐ コンポーネント機能 コンポーネント機能を利
コンテンツマーケティングの戦略設計
コンテンツマーケティングの4つの戦略軸の重要性とその詳細、それらの評価や分析に関する資料です。コンテンツマーケティングは「オーディエンスを魅了して関係性を持つこと」を目指さなければいけません。 関連ページ（資料内容を解説したブログ記事各種あり） https://cinci.jp/docs/content-marketing-strategy 株式会社真摯 https://cinci.jp/
Rails: Active RecordでRepositoryパターンを実装する（翻訳）｜TechRacho by BPS株式会社
概要 元サイトの許諾を得て翻訳・公開いたします。 英語記事: Repository implementation on ActiveRecord | Arkency Blog 原文公開日: 2023/12/28 原著者: Paweł Pacana Repositoryは本質的に、ドメインオブジェクトをその永続化方法から切り離して、それらにアクセスするための限定的なインターフェイスを提供します。Repositoryは戦術的なパターンの一種であり、本記事の導入部で私が説明したい内容よりずっと詳しくMartin FowlerやEric Evansが解説しています。Repositoryパターンが推し進めるものは、いわゆるActive Recordパターンと真逆です。なぜパターンをわざわざ別のものに変換するのでしょうか？ Active Recordパターンは両刃の剣であり、その問題はまさに最大の長所
アプリの画面をデザインする際、エンジニアさんに 「なにも登録データがない場合、どう表示しますか」「選択したときの状態ってどんなデザインですか」などと聞かれて 「ｳﾜｱ考えてなかったすみません、今作ります。。」 （なんて自分はポンコツなんだ、、ｳｳｳ） と、なりたくないですよね。 UI Stackは👆のような状況を回避するのに便利で大事な考え方だと思ったので、言葉の意味を知らない方はぜひ読んでってください！ UI Stack アメリカのプロダクトデザイナー Scott Hurff さんが世に出した 「UIの考慮すべき5つの状態」という考え方です 5つの状態 ・Blank State（空っぽの状態） ・Loading State（ローディング状態） ・Partial State（部分達成状態） ・Error State（エラー状態） ・Ideal State（理想状態） 一つ一つ参考を交えな
プログラマーの教養としての原則
参考 プリンシプル オブ プログラミング - 3年目までに身につけたい一生役立つ101の原理原則 発行: 2016/3/23 著者: 上田 勲 まえがき プログラマーの世界で語り継がれる原則や格言を知ることは、その共通の言語や道徳を理解する手助けとなります。 『プリンシプル オブ プログラミング』（以下、プリプロ）は、統一された語句と形式により、先人のプログラマーたちが重要視していた思考法やアプローチを、微妙な概念の違いに気を使うことなく理解できるよう構築されています。この記事では、この本を読む上で役立つ101の原則マップと原則から抽出した価値観をまとめます。プリプロを読む際のガイドになればと思います。 一方で、プリプロに収録されていないウィットに富んだ原則や格言も多く存在します。この記事では、主に私の現場で重要視しているプリプロの101の原則以外の原則・格言も追加で紹介します。 プログラ
背景: dbtを使っていてもER図は欲しい! どうやってER図を生成するか どうやってER図を見やすくするか まとめ 背景: dbtを使っていてもER図は欲しい! dbtはモデル間のリネージなど可視化が得意なツールではありますが、万能なわけではありません。モデルの生成過程などはリネージで担保できますが、分析時に「どれとどのモデルがJOINできて、JOINする際のキーはこれを使って」というER図で扱うような可視化はディフォルトではできません。 DWHを作っている側からすると「このテーブルはあの辺のテーブルと一緒に使うと便利で、いつもあのキーでJOINして」というのが頭の中に入っていることが多いため、ER図がなくてもどうにかなることも多いでしょう。しかし、分析に慣れていない人や分析に慣れている人であっても、普段と異なるドメインのテーブルを触るときはER図が提供してくれる情報は有用です。ちなみに
DWHにおけるデータモデリングで大事にしている考え方
こんにちは。データエンジニアリングの支援を行っているstable株式会社の代表の宮﨑（@ikki_mz）です。弊社では、クライアント社内のデータウェアハウス（DWH）におけるデータモデリングをサポート...
インフラマネージャー厳選！10年使える知識が身につくおすすめ書籍10選 - RAKUS Developers Blog | ラクス エンジニアブログ
ラクスでは多くのSaaSプロダクトを開発・運用しており、オンプレミスまたはクラウドを適切に選択してインフラ基盤を構築しています。 そのインフラを担うのが、ラクスのインフラ開発部です。 今回はインフラ開発部のマネージャーが厳選した、インフラエンジニアにおすすめの書籍10選をご紹介します。 それぞれの書籍に推薦コメントを記載していますので、是非ご参考になさってください。 選定基準は以下の通りで、今後インフラを深く理解し実力をつけていきたい方にも最適です。是非ご覧ください。 「すぐに役に立つがすぐに廃れる知識ではなく、10年以上使える書籍」 「分かりやすい本ではなく、難解ではあるがきちんと原理・原則を学べる書籍」 目次 目次 Operating Systemを理解しよう 詳解 Linuxカーネル 第3版 DNS & BIND 第5版 トラブルシューティングを理解しよう 詳解 システム・パフォーマ
人とコンピュータの関係を考えると、二者間には常にインタフェースが存在します。本連載では、人とコンピュータの間に介在するインタフェースに着目し、インタフェースとそれらを世に生み出すプロダクト開発について議論します。Helpfeelが、独自のインタフェースを実装しながら、便利さと楽しさを備えたWebサービスをどのように開発しているのかについてお伝えします。 こんにちは。yuisekiです。Helpfeelでメディアキャプチャーツール「Gyazo」のプロダクトマネージャーをしています。今回は、Gyazoの設計・開発の過程で得られた、人間の認知や判断、行動や操作に関する知見を紹介します。 人間の速さへのもう一つの視点 本稿でみなさんに最もお伝えしたいのは、「人間は極めて速いけど、遅いほうが適切な場面もある」ということです。前回は、「人間は極めて速い」という事実を前提として、ソフトウェアにおける実際
(株)松尾設計室 代表取締役 兵庫県出身、九州大学工学部建築学科卒の一級建築士。「健康で快適な省エネ建築を経済的に実現する」ことをモットーに、設計活動のほか、住宅専門紙への連載や「断熱」「省エネ」に関する講演を多数実施。これまでに受講した設計事務所、工務店等は延べ6,000社を超える。2005年「サステナブル住宅賞（現：SDGs住宅賞）」受賞、2020年から開始したYouTubeチャンネルの登録者数は6.9万人（2024年1月時点）。著書『ホントは安いエコハウス』、『あたらしい家づくりの教科書』（共著）、『5人の先生が教える一生幸せなエコハウスのつくりかた』（共著）など。 快適な住宅に欠かせない「断熱」。近年、注目されている背景は？ ── 昨今、断熱への注目度が高まっているように感じます。そもそもなぜ断熱が重要なのでしょうか？ 松尾さん：断熱って簡単に言うと「住宅の厚着」なんです。日本の古
セキュリティインシデントから会社を守る！~小さく始めるCSIRT設計事例~ - Techtouch Developers Blog
はじめに CSIRT とは CSIRT を立ち上げるモチベーション セキュリティインシデントは避けられない 意思決定者の訓練機会の不足 世界的なインシデントレスポンスの重要性の高まり CSIRT 作りの準備 教科書に学ぶ 他社に学ぶ テックタッチにおける CSIRT の設計 スモールスタートするための責任境界 ちゃんと機能する！ハンドリングマニュアル 窓口の明確化 継続的なスペシャリティの維持 さいごに 参考 はじめに こんにちは。SRE 兼 CSIRT の izzii（𝕏）です。Flatt Security mini CTF #4 に参加して入賞景品のTシャツをゲットできたのが最近のプチ自慢です。 さて本日の記事は、テックタッチにおいて私含む現場のメンバー（izzii, kacchan, ue）が Computer Security Incident Response Team (CS
「200年の寿命」のはずが… 140個もの切り離し可能なカプセルを組み合わせた中銀カプセルタワーは、まさに20世紀を代表する建築物だ。このタワーを設計した黒川紀章が思い描くメタボリズム的な未来都市では、組み合わせたり切り離したりできる複数のパーツからなるビルがずらりと立ち並んでいた。その様子は、まるで生き物が成長し、体のパーツを増やしていくかのようだ。 黒川は2007年、亡くなる直前のインタビューでこう語っている。 「25年ごとにカプセルを交換すれば、中銀は200年もつでしょう。これはリサイクル可能な建築です。私は、サステナブルな建築として中銀カプセルタワーを設計したのです」 しかし年月とともに住人の大部分がいなくなり、中銀は荒廃していった。そして住人たちは、中銀をそのまま保存しておくよりも取り壊すことを選んだ。これは「建築界の悲劇」だ。 予定より数年遅れた2022年10月、タワーは解体さ
Web API 学習ロードマップ 2024 / Web API Learning Roadmap 2024
Presentation Slides for Postman Tokyo Meetup 2024.01 Session title: Web API 学習ロードマップ 2024 Date: 2024/01/29
TOPインタビュー【CADDi小橋×藤倉】組織の痛みを「成長痛」で終わらせない。元SansanCTO藤倉成太が今のCADDiに必要な理由 キャディ株式会社 CTO 小橋 昭文 スタンフォード大学・大学院にて電子工学を専攻。世界最大の軍事企業であるロッキード・マーティン米国本社で4年超勤務。ソフトウェアエンジニアとして衛星の大量画像データ処理システムを構築、JAXAやNASAも巻き込んでの共同開発に参画。その後、アップル米国本社にてハードウェア・ソフトウェアの両面からiPhone、iPad、Apple Watchの電池持続性改善などに従事した後、シニアエンジニアとしてAirPodsなど、組み込み製品の開発をリード。2017年11月に、キャディ株式会社をCEOの加藤勇志郎氏と共同創業。 キャディ株式会社 DRAWER事業本部 VPoE 藤倉 成太 株式会社オージス総研に入社し、ミドルウェア製品
良いソフトウェアとコードレビュー / Good software and code review
Scala + Caliban で作るGraphQL バックエンド / Making GraphQL Backend with Scala + Caliban
本イベントでは「実録レガシーコード改善」というタイトルで、実際にt-wadaさんがテストの全くないシステムを引き継いだところからスタートする実話をお話していただきます。 イベントページ： https://findy.connpass.com/event/304101/
オブジェクト指向プログラミングにある程度精通していれば、この開発スタイルが、特定の言語やフレームワークの選択よりも、基礎となる設計手法に深く関わっていることを知っているだろう。オブジェクト指向の適切な設計については数多くの主張や見解があるが、「SOLID原則」は、オブジェクト指向設計に携わる全ての開発者が従うべきルールとして、その権威を確立している。 SOLIDの原則を真に理解するには、この原則が推奨する個々の設計プラクティスについて学び、「各原則を並べて議論する必要性」を理解しなければならない。そこで本稿では、SOLIDが表すオブジェクト指向設計の5つの原則をそれぞれ確認する。「各原則がどう違うか」ではなく「各原則を相互に結び付ける根本的な概念とは何か」について説明する。 オブジェクト指向設計のSOLID原則とは オブジェクト指向プログラミングには特有の5つの原則がある。この5つの原則は
2022年夏、 我々はアプリケーションのバックエンドとして利用していたFirebaseをやめる決断をした。それは事業とソフトウェアの成長に伴いユースケースが合わなくなってきたことが主な理由だ。 これはFirebase、特にNoSQLドキュメントデータベースであるFirestoreから自分たちでRDBを使ったREST APIを開発し移行する物語。 何を考え、何を行うか、RDBとは異なるデータ構造のFirestoreのデータをどのように再設計/開発/移行するかについて愚直に語ります。 同じような悩み、課題もつ皆さんになんらかのきっかけを与える45分に。 スピーカー： 西谷 圭介 氏 (CTO, Singular Perturbations Inc） セッションに関する情報： ・想定聴講者の役割/開発対象：Web バックエンド / サーバーサイド開発 ・セッションのトピック：Web バックエ
オープンソースらしくソフトウェアを設計する
こんにちは、出前館のプロダクトを担当しているヨンジェです。私は10余りのオープンソースプロジェクトをディレクションして開発し、チームで新しいソフトウェアを設計するときは、なるべくオープンソースへの移行...
ドメイン駆動設計を実践して自分の LINE 環境をリファクタリングしてみた（実装編２） | DevelopersIO
間が空いてしまいましたが、Lambda リファクタリングの最終回です。空いてしまったのはこのあともこの環境を使おうかと GitHub の環境構築に手間取ってしまったためでして。 こんにちは、高崎＠アノテーションです。 はじめに 設計：ドメイン駆動設計を実践して自分の LINE 環境をリファクタリングしてみた 実装：ドメイン駆動設計を実践して自分の LINE 環境をリファクタリングしてみた（実装編） の続きになります。 残りのソースをそれぞれ書いて説明していこうかと思いましたが、記事が長々となってしまったため GitHub に置きました。 1 今回の記事では clone 後の利用方法と、各機能についてを実装したことを記載しますが記事内では抜粋して記載しますので詳細は GitHub のソースをご参照ください。 なお、今回もお約束として正確性としては程遠い可能性もあり、エラーチェックも甘い実装例
fumi 小学校1年生で初めてはんだ付けをしてから電子工作にハマり，今はハードウェア全般広くものづくりをしています。
前回は、「UIデザインってそもそも何なの？」という概論的な説明と、UIデザイン未導入の組織の中でみんなでデザインを始めてみるための施策（プロトタイピングとユーザビリティ評価）を話しました。 ※最新の勉強会の開催情報についてはXをご参照ください 今回はサービス、プロダクト開発において、デザイナーではない人でも知っていて損はないUIデザインの重要ポイントについて説明します。主に以下の３つのテーマについて順番に議論をしていきます。 デバイスやソフトによるUIの違い ユーザーにかかる身体的・認知的負荷を理解する UIの重要概念（ナビゲーション、インタラクションなど）を知る 「ちょっと」と銘打っておきながらめちゃくちゃ長いnoteになってしまったので、気になる項目だけ読むか、何回かに分けて読んでいただくことをおすすめします、。 ※どこか内容に間違ってる部分やご意見ありましたらコメントいただけたら嬉し
技術負債とデータ構造
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
はじめに 有用な知識の特性 Google SRE リソース Site Reliability Engineering: How Google Runs Production Systems The Site Reliability Workbook: Practical Ways to Implement SRE Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems SLO Adoption and Usage in SRE Creating a Production Launch Plan Training Site Reliability Engineers: What Your Organization Needs to Cre
XUnit Test Patterns に筆者の経験則を落とし込んでまとめています。 2024/01/25 TechBrew in 東京 〜技術的負債と共に歩むプロダクトの成長〜 の登壇資料です。 https://findy.connpass.com/event/306451/
書籍「ソフトウェアテスト技法ドリル」ではテスト設計の考えとツールの使い方まで学べちゃいました | DevelopersIO
私は開発寄りのエンジニアであり、テストやQA専門の方と同じチームで頑張る機会が少なかったのですが、「なるほど、こうやって考えて、こういうツールを使っているのか」と非常に勉強になりました。 こんにちは。AWS事業本部モダンアプリケーションコンサルティング部に所属している今泉（@bun76235104）です。 最近ではアジャイル開発やスクラム開発が多く採用され、ビジネスのスピードに負けないようにプロダクト開発・リリースのスピードが求められれている中で、「いかに効率よく、かつ効果的なテストをしていけるか」というのはテスト担当だけでなく、開発メンバー全員で考える必要があると思います。 とはいえ、実際のチームには「専任のQAエンジニアやテストアナリストはいない」ということは非常に多いと思います。 基本的なテスト技法は本で学んできたけど、どういう時にどんな技法でテストを設計すればよいの？ 本職のテスト
はじめに 設計と開発プロセスの関係性 システムの構造とタスク構成 設計の影響（生産性、外部品質） ソフトウェア設計の知識と技能 経験則 （経験による暗黙知 ⇒言語化：原則、パターン、体験談） 習熟 （手を動かして内面化された経験則） 共創 （知識と技能の連結） ① ソフトウェア設計の基礎知識 a. 基本課題 複雑さと発展性 大きな泥団子 巨大な一枚岩（モノリス） b. 解決のアプローチ 関心の分離→部品化→モジュール化 交換容易性（モジュラー性） c. モジュール化：基本となる４つの技法 モデル 直接的な写像 カプセル化 仕様 ② モジュール化 a. モジュールの分類 機能(Function)と型(Type) インバウンド、アウトバウンド、演算 可変と不変 ブレークダウンとビルドアップ b. オブジェクト指向プログラミングのモジュール化 抽象データ型 型の連結 型の分類（subtyping
はじめに 佐藤：佐藤歩です。現職では開発からしばらく離れていたんですが、最近またまとまった量のリプレイス開発に携わってるので、モデレーターとして、よしこさん、うひょさんからいろいろお話を伺っていきたいなと思っております。 よしこ：こんばんは。よしこです。株式会社ナレッジワークに創業期に入社し、フロントエンドエンジニアをしています。プロダクトの0→1のところから、今の1→10のフェーズに入るまで、SPAのアプリケーション設計や運用をしてきました。 うひょ：うひょです。株式会社バベルに在籍しています。これまでずっとTypeScriptとReactでフロントエンドのアプリ開発に携わってきました。昨年はTypeScriptに関する本も出版しています。 佐藤：今回は、Reactのコンポーネント設計におけるこちらの5つのテーマごとに、よしこさんとうひょさんに順番に簡単にお話をしていただきつつ、都度ディ
以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから
和田 卓人さん（t_wadaさん）に「予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント」を社内で講演いただきました！ | Wantedly Engineer Blog
こんにちは、ウォンテッドリーDev Branch VPoE 室長の髙橋です。 ウォンテッドリーの開発組織であるDev Branchでは、外部から有識者を招いて勉強会を開催したり、技術顧問として知見を取り入れるなど、プロダクト開発により強い組織となるためにさまざまな施策を行っています。 今回、「テスト書いてないとかお前それ @t_wada の前でも同じ事言えんの」 でおなじみのt_wadaさん（和田 卓人さん、以下和田さん）に「予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント」をウォンテッドリー向けにカスタマイズして講演いただきました。 このストーリーでは、今回の講演の経緯から社内の反応・Q&Aまで、講演に関する詳細をご紹介いたします。 社内講演のきっかけ事の発端は、弊社のVPoEである要（X : @nory_kaname）より、外部エンジニアを招いて勉強会を開催する旨の問いかけ
メール送信者がone-click unsubscriptionを実装する方式を検討します - Pepabo Tech Portal
訂正 2024-01-31: 指定するメールヘッダの用法を訂正しました。訂正以前はList-Unsubscribe-Post ヘッダにエンドポイントのURLを記載するとしていました。正しくはList-Unsubscribe ヘッダにエンドポイントのURLを記載します。また、List-Unsubscribe-Post ヘッダには List-Unsubscribe=One-Click と記載します。 はじめに こんにちは、新卒 13th の@donokunです。12 月は SUZURI 事業部に参加して、いちごジャムとたまごペーストがトーストにあうことを学びました。騙されたと思って喫茶店のモーニングで試してください。ジャムが塗ってあるトーストにたまごペーストを上から塗って食べるのです。 この記事ではワンクリックでの配信停止（one-click unsubscription）という E メール送
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
業務でAWSを利用する時に知っておくべきポイント10選 - Qiita
私とテストと自動化と - あどけない話
プロジェクトの最初に「事前検死」をしろ｜深津 貴之 (fladdict)
レイヤードアーキテクチャでデータを作成・編集するときの設計が分からん
エンジニア向けFigmaの使い方を徹底解説 | 株式会社LIG(リグ)｜DX支援・システム開発・Web制作
その状態のデザイン考えてなかった！ UI Stackってナニ｜kana
dbtで見やすいER図を生成する - yasuhisa's blog
それもまたUIだね。インタフェース散歩！(9) 人間の速さを鎮めておもてなしする
“断熱の鬼”が費用対効果の高い新築断熱住宅について語り尽くす！ - 住まいのお役立ち記事
米紙が賞賛する中銀カプセルタワー 「サステナビリティの先駆けだった」 | 黒川紀章の遺志は継がれ
【CADDi小橋×藤倉】組織の痛みを「成長痛」で終わらせない。元SansanCTO藤倉成太が今のCADDiに必要な理由
【アーカイブ動画】t-wadaさんが後世に残したい、実録レガシーコード改善
オブジェクト指向設計の5つの原則「SOLID」を解説
脱 Firebase. 我々はどう生きるか | AWS Dev Day 2022 Japan #AWSDevDay
みなさん「はんだ付け」してますか？ 電子工作初心者にこそ知ってほしい楽しさと奥深さ | となりのカインズさん
知識０から、ちょっとUIデザインに詳しくなるnote｜やました
このSRE本がすごい！2024年版 - じゃあ、おうちで学べる
テストコードを負債化させない上手な付き合い方 / Test Code Management
設計の知識と技能で駆動するソフトウェア開発
うひょさん、よしこさんと改めて考えるReactコンポーネント設計 | Offers Magazine
DDDの実装にはあまり興味がなくなっている - Mitsuyuki.Shiiba