メール送信者が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 メール送
この記事の内容 WordPressで作成したコンテンツを静的にホスティングする設計まとめ ハンズオンを兼ねた事例報告（+自分の所感）の流れで執筆 背景 そもそもなぜタイトルのような設計を考えたのかというと、先日アサインされたプロジェクトの要件が以下のとおりだったからです。 誰でも簡単にコンテンツを作成できる セキュアな設計 ここで、WordPressには以下の長所があります。 技術に明るくない人であっても簡単にコンテンツを作成できる 裏はPHPで動いているので拡張性が非常に高い 初期導入に必要となるコストが少ないこと ただし、ご存知の通りWordPressの欠点として大きなものが以下です。 脆弱性が多く十分な対策を要求される 上記を鑑みて、WordPressの長所を余すことなく享受し欠点を最大限カバーすることができるようになる「WordPressを静的コンテンツで配信」を目標に構築を行いま
SRAMはトロイの木馬を仕掛け、一気にシマノを窮地に追い込んだ。ロードバイク界隈はまだ平穏だが、MTB界には激震が走った。SRAMイーグルトランスミッションという革新的な兵器はいま、MTB界からシマノを追いやろうとしている。 2020年、SRAMがUDH（ユニバーサル・ディレイラーハンガー）を発表した。待っていたかのようにTREKからUDHを搭載したフューエルEXが登場した。SRAMとTREKはご近所だから、互いに協力しながら研究開発を進めていたのだろう。 当初、UDHのデザインは「どの自転車メーカーも無料で使用できるオープンスタンダード」として発表された。当初は、だ。 表向きは、業界全体で無数にある独自のハンガーやアクスルスレッド規格の必要性を減らし、消費者の利便性を向上させ、部品選定の悩みの種を減らすため、だった。しかし、これはSRAMが新しいダイレクトマウントディレイラー（フルマウン
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション）」という興味深いポストをX（旧Twitter）で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション） コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
『ソフトウェアアーキテクチャメトリクス―アーキテクチャ品質を改善する10のアドバイス』 - snoozer05's blog
翻訳を担当した書籍『ソフトウェアアーキテクチャメトリクス―アーキテクチャ品質を改善する10のアドバイス』（オライリー・ジャパン）が明日（2024年1月24日）発売となります（電子書籍はオライリー・ジャパンのサイトでの購入となります）。本書は、2022年10月に出版されたChristian Ciceri, Dave Farley, Neal Ford, Andrew Harmel-Law, Michael Keeling, Carola Lilienthal, João Rosa, Alexander von Zitzewitz, Rene Weiss, Eoin Woods 著『Software Architecture Metrics: Case Studies to Improve the Quality of Your Architecture』（O'Reilly Media）の全
先日、Qiitaに投稿された一つの記事が注目を集めました。 元記事では、htmxというJavaScriptライブラリが英語圏で認知を獲得しているとして、インストールの仕方から使い方について公式のドキュメントの全体にわたって簡単に説明が行われています。 さまざまなプラットフォームでこの記事に対する反応を観察してみると、どちらかというと懐疑的な見方のほうが優勢のように見受けられます。ただ、多くのコメントは誤解に基づいているように見受けられました。「JSが要らない」といった元記事のミスリードによるところも大きそうですが1、なぜhtmxが大きく支持を得つつあるのかを理解するには、背景情報を含めて理解することが必要です。 htmxは、最近の複雑化するフロントエンド技術に対する単なる逆張りではありません。これまで30年ほどのあいだウェブ上のシステムを支え続けた「ハイパーメディア」の持つ強力さに今一度目
ディメンショナルモデリングに入門しよう！Snowflakeとdbt Cloudで「Building a Kimball dimensional model with dbt」をやってみた | DevelopersIO
ディメンショナルモデリングに入門しよう！Snowflakeとdbt Cloudで「Building a Kimball dimensional model with dbt」をやってみた さがらです。 ここ２年ほどの間にdbtが日本でも急速に拡大し、様々な情報が日本語の記事でも見かけられるようになってきました。 dbtを採用してある程度活用を進めていくと、「より効率よくガバナンスを持ってデータを管理するにはどうすればいいんだろうか」といったデータの管理方法に悩む場面が出てくると思います。 そんなときに色々調べていくと、データを効率よく管理する手法として「データモデリング」が必要だとわかり、ディメンショナルモデリングやData Vaultなどの手法に行き着くのではないでしょうか。 そしてこれらのデータモデリングの手法の内、ディメンショナルモデリングについてdbtを用いて実践された記事がありま
UIデザインで、小さいサイズでもはっきりと美しく見えるように設計されたMicroサイズのSVGアイコン -Heroicons Micro
テキストの横にアイコンを配置すると、アイコンが少し大きすぎてバランスが悪いと感じることはありませんか？ アイコンは通常のMiniサイズだと20x20ですが、それより一回り小さく高密度のUI向けに設計されたMicroサイズの16x16のSVGアイコンを紹介します。 Heroicons Micro Heroicons -GitHub Heroicons Microの特徴 Heroicons Microのダウンロード Heroicons Microのアイコン Heroicons Microの特徴 Microサイズのアイコンは、先日v2.1にアップデートされたHeroiconsに新しく加わったサイズです。 タイトで高密度のUI向けに設計されており、UIデザイン用に約300種類のアイコンが揃っています。MITライセンスで、商用プロジェクトでも無料で利用できます。 Heroicons 既存のアイコンを
リリースするたびに「影響範囲の考慮漏れ」によるトラブルを起こす。こういう症状は、既存のソフトウェアシステムに追加開発を繰り返す組織によく見られるのではないかと感じます。コードやシステムの変更が影響を及ぼす箇所を見逃してしまい、未修正な箇所が残されたまま本番リリースされたために発生するトラブルです。 このようなトラブルが頻発すれば、関係者らは不満を感じます。エンジニアたちの能力に不信感を抱くかもしれません。 しかし、不満の矛先をエンジニアに向けたところで問題が解決することはありません。そもそも原因を見誤っているからです。根本的な原因は、もっと奥深くにあります。 影響範囲の考慮漏れの多発は、ソフトウェアシステムが大きな問題を抱えていることを知らせるサインです。このサインを見逃して表面的な対策ばかりを続けていると、症状が良くなるどころか、かえって悪化し続けることになるでしょう。 問題/原因の3層
ゲーム開発ひいてはクライアントサイドの開発において「クリーン」かどうかは正直けっこうどうでもよく、設計すべき一番のポイントは「制御フロー」にあります。 じゃあ具体的にどういう設計がいいのか、ていうのは、やはりjs界隈みたいにフレームワークになっていないとなかなか伝わらないようです。そういうのもそのうちつくってみたいなあと最近思ってます。 以下、以前ブログに書いたものの転載。 -- Unityで長らくゲーム開発をやっているけれど、Web界隈などで色々と発達しているアプリケーション設計パターンをおいそれと持ち込めば良いわけではないと感じているので、それについて考えてみようと思う。 ここでいう設計パターンていうのは、たとえばUIとかをつくるフレームワークの競争で発達してきた MVC派生 や ReactとかのElmアーキテクチャに影響を受けたものたち、はたまた、Webサーバ(HTTPサーバ) を書
公開日 2024/01/23更新日 2024/02/15あのサービスの監視・オブザーバビリティ アーキテクチャ選定【前編】 ユーザーや顧客へ信頼性を担保した価値提供をしていく中で、監視・オブザーバビリティの取り組みは非常に重要です。 今回の特集記事では、合同会社DMM.com、株式会社MIXI、株式会社マネーフォワード、パイオニア株式会社、Sansan株式会社、株式会社ZOZOの6社の各サービスを支える監視・オブザーバビリティの仕組みとして各社がどのようなアーキテクチャを組んでいるのか、またそのアーキテクチャにしている背景や意図についてお伺いしました。 自社に近いアーキテクチャやどのようにツールを活用しているかについて、実際の事例を元に参考になれば幸いです。 なお、後編も近いうちに公開させていただきますのでお楽しみに。 合同会社DMM.com（DMMブックス） アーキテクチャ設計の背景・意
Gmailが「メール送信者のガイドライン」を改訂し、なりすましメールへの対策を強化する旨を発表しています。今までは原則、なりすましメール対策の有無にかかわらず、メールはいちおうは届いていました。しかし今後は、なりすましとみなされたメールは届かなくなる方向に向かいつつあります。 なりすましメールとみなされないようにするために、メール送信者には、「メール送信ドメイン認証」への対応が求められます。メール送信ドメイン認証の技術には、主に以下の3つがあります。 SPF: Sender Policy Framework (RFC 7208) DKIM: DomainKeys Identified Mail (RFC 6376) DMARC: Domain-based Message Authentication, Reporting, and Conformance (RFC 7489) SPFは従来
はじめに 個人でフロントエンド(react)、バックエンド(node.js)、データベース(postgreSQL)を利用したWebサービスを公開したいと考えていました。 まずはテスト的に無料で外部公開できるサービスがないか調査しましたが、2022年8月に有料化されたHerokuの記事ばかりヒットしてしました。 結果的には無料で使用できる構成があり、実際にテストプログラムを動作させることができましたので構成例として記載しておきます。 ※無料なので比較的厳しい条件も含まれていたりするのでそれぞれのサービスを確認お願いします。 例えばsupabaseは数日間利用がないとインスタンスが一時停止して手動で起動させないといけないなどがあります。 今回試したサービス できるだけ同じサービスに集約したいと考えていましたが、実際にはフロントエンド、バックエンド、データベースはそれぞれ異なるサービスになってし
AI時代を生き抜くために処理をちゃんと書けるようになろう / write a executable process for AI era
2024/1/20に開催されたBuriKaigiでの登壇資料です
※リンクを効かせたい場合はダウンロードしてください
非同期ジョブをユーザーアクションに組み込まない
(勤務先に投稿した社内ブログの焼き直しです) ある日同僚から ActiveJob の perform_later で Barbeque にキューした非同期ジョブの起動が遅いと言われた。が、非同期ジョブの使い所について個人的な考えを書いてみることにする。 相談は「非同期ジョブの結果をユーザーに返しているため、高速になって欲しい。現状、最大で数分の時間を要す旨のメッセージを表示している」という内容でした。具体的には {内部 API} が重く、一部の処理を非同期ジョブにしていてユーザー体験の悪化につながっているとのこと。 盲目的に非同期にしても嬉しいことはない 結論としては、非同期にするのであれば丁寧にやれば良いけど、そもそも同期的でよくない? と考えて欲しいと返した。 まず、個人的にはユーザーアクション起因かつユーザーへフィードバックする必要のある処理を非同期ジョブにするのは本当に長時間かかる
Gmailで問題が生じる神奈川県立高校ネット出願システムの被疑箇所を調査、改善策を検討してみた | DevelopersIO
神奈川県高校入試のネット出願システムの不具合影響を受けた利用者として、Gmailを扱えないメール環境について外部から調査しました。 出願システムで独自実装されたメールシステムの不完全な実装と、メール関連のDNSの設定不備が原因であった可能性が高いと推測します。 2024年の神奈川県立高校入試出願システムの不具合の影響を受け、@gmail.comのメールアドレス を利用出来なかった一利用者として、 インターネットから参照可能な範囲で、出願システムのメール環境について調査。 被疑箇所の推定と、状況を改善する対策について検討する機会がありましたので、紹介させて頂きます。 神奈川県公立高等学校入学者選抜インターネット出願システムの稼動状況について MX設定 「mail.shutsugankanagawa.jp」のMXレコードを確認しました。 1/18(21時) $ dig mx mail.shut
こんにちは。コミュニケーションアプリ「LINE」のモバイルクライアントを開発している石川です。 この記事は、毎週木曜の定期連載 "Weekly Report" 共有の第 9 回です。Weekly Report については、第 1 回の記事を参照してください。 来た道を戻れ ネットワークやファイルシステムといった I/O を使う場合、I/O 上のデータ表現とコード上のデータ表現との間で相互に変換する必要があります。その典型例の一つが、インターフェース記述言語 (IDL) やデータベーススキーマなどの外部で定義されたデータと、コード上で定義されたモデルクラスとの相互変換でしょう。このとき、「状態」や「タイプ」を意味する値を使う場合は、コード上の表現として列挙型を使うこともあります。 以下のコードでは、データベースで使われている値と列挙子を相互変換するために Map を使っています。 enum
今がギリギリ体も頭も動くお金を使う最後のタイミングでしょ そこで投資とかいって金を死蔵して一体どうしたいんだろう
コード構造を設計するときは、ソフトウェアスタック内で機能を分離する方法を検討すると役立つことがしばしばある。その方法の一つとして、アプリケーションのレイヤーをその上下に存在する他のレイヤーから抽象化することが挙げられる。これは、「レイヤードアーキテクチャパターン」と呼ばれることが多いアプローチだ。 レイヤードアーキテクチャパターンはどのように機能するのか レイヤードアーキテクチャの各レイヤーは、特定のアプリケーションまたはビジネス目標に合わせて設計される。そのため、レイヤーとレイヤーが管理する機能の間には、明確な抽象化が存在する。例えば、アプリケーションは、ユーザービューをレンダリングするレイヤー、Web APIへの応答を中継するレイヤーおよびファイルシステムまたはデータベースへのデータの保存を担当するレイヤーを維持しているかもしれない。 関連記事 開発者が注意すべき「マイクロサービスの問
Microsoft VisioやDraw.io、Graphvizなど7つの「ソフトウェアアーキテクチャ視覚化ツール」をレビュー
Microsoft VisioやDraw.io、Graphvizなど7つの「ソフトウェアアーキテクチャ視覚化ツール」をレビュー：プロジェクトシナリオへの適合性を理解することが重要 TechTargetは、「ソフトウェアアーキテクチャ視覚化ツール」に関する記事を公開した。「Microsoft Visio」や「Draw.io」のような視覚化ツールは、ソフトウェアアーキテクチャの設計と管理に多くのメリットをもたらす。だが、重要なのは正しいツールを選択することだ。
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
良いコメントが良い設計を導く
要旨 コメントを適切に記述することは、特にインターフェイス（クラスやメソッド）において重要です。これにより、直感性が高まり、抽象化が十分に行われているかを確認する手助けになります。そのため、コメントはソフトウェア設計プロセスの重要な一部と位置づけられます。 2種類のコメントタイプ まず、コメントを2種類に分類します。 1️⃣ コードをより詳細化するコメント(lower-level comment) 2️⃣ コードをより抽象化するコメント(higher-level comment) どちらも必要なコメントとしつつ、本書では後者のコメントをより重視しています。 1️⃣ コードを詳細化するコメント(lower-level comment) 変数名などに残すタイプのコメントで、宣言した対象の単位や境界値、null許容などの詳細を明示することで、コードの正確性を高めます。こちらのタイプのコメントも必
前回の記事ではチーム中心の組織づくりの設計原則について書いた。今回は、それらの原則に基づくチームをソフトウェアプロダクト組織内にどう配備し、どのような機能を持たせるかについて考える。これは言わば、チームの責務を定義することに他ならない。本記事ではこれを、7つのガイドラインとして書き出してみることにした。 前回の記事：『チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog』 mtx2s.hatenablog.com 1. ストリームアラインド 2. オーナーシップ制 3. バリエーション分割 4. 技術横断型 5. DevOps 6. 機能横断型 7. マルチスキル 組織設計とはアーキテクティングである 1. ストリームアラインド ソフトウェアプロダクト組織の開発フローは、ユーザーや市場の観察をもとにアイデアを生み出すことから始まる。そのアイデアを仮説として、それを
2024年2月14日紙版発売 2024年2月14日電子版発売 マウンティングポリス 著 四六判／208ページ 定価1,540円（本体1,400円＋税10%） ISBN 978-4-297-13951-3 Gihyo Direct Amazon 楽天ブックス ヨドバシ.com 電子版 Gihyo Digital Publishing Amazon Kindle ブックライブ 楽天kobo honto この本の概要 人間関係あるところにマウントあり，マウンティングを制する者こそが人生を制する。 3万以上の事例を収集・分析してきたマウンティング研究家が，80億総マウント社会を乗り切るためのナレッジを集大成。 一流の人こそこっそり活用しているマウンティングの最強パターンとは ステルスマウント×マウントさせる＝最強のビジネススキル イノベーションはテクノロジーからではなくMX（マウンティングエクスペ
実録レガシーコード改善 / Working with Legacy Code: the True Record
2024/01/15(月) 12:00 〜 13:00 t-wadaさんが後世に残したい、実録レガシーコード改善 https://findy.connpass.com/event/304101/ テストコードが無いコードを引き継いだところからはじまる、実際に2018年に行った受託開発案件のエピソードとコードをプロダクトオーナー（引き継ぎ前のコードを書いた本人）の許可を得て使用しています。登場するコードは全て本物、登場するデータは講演用の架空のものです。
Rebuilding Netflix Video Processing Pipeline with Microservices
Liwei Guo, Anush Moorthy, Li-Heng Chen, Vinicius Carvalho, Aditya Mavlankar, Agata Opalach, Adithya Prakash, Kyle Swanson, Jessica Tweneboah, Subbu Venkatrav, Lishan Zhu This is the first blog in a multi-part series on how Netflix rebuilt its video processing pipeline with microservices, so we can maintain our rapid pace of innovation and continuously improve the system for member streaming and st
ミノ駆動さんに「なぜ負債解消にDDD？」と聞いたら、ソフトウェア開発の本質に気づかされた 2024年1月15日 株式会社スタメン ミノ駆動（仙塲大也） 電子機器メーカーや大手精密機器メーカー、クラウドワークスを経て、2021年4月にREADYFORに入社。アーキテクチャの変更容易性や機能性を促進する設計構造を目指し、リファクタリングやドメインモデリングを主軸としたシステム設計に従事する。現在は、組織改善のためのエンゲージメントプラットフォーム「TUNAG」を擁するスタメンに在籍。ITエンジニア本大賞2023技術書部門大賞を受賞した『良いコード/悪いコードで学ぶ設計入門』著者としても知られる。 X（@MinoDriven） note Qiita 株式会社スタメン・テックブログでの執筆記事 ドメイン駆動設計（以下、DDD）に注目が集まりだしてしばらく経ちますが、いまだに捉えづらさを感じている人
失敗例から学ぶSOLID原則
PHPカンファレンス北海道2024 https://fortee.jp/phpcon-hokkaido-2024/proposal/7d223fcd-ecc8-4cfb-92b2-4987749463d8 Lについての補足記事 https://asumikam.com/entry/2024/01/12/144338 Sについての補足記事 https://asumikam.com/entry/2024/01/13/152513
これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス：ALB or ECS Service 共有 or １環境毎 アクセスログ：ALB or WEBサーバー ECS / EKS デプロイ：Blue/Gr
Thinkings株式会社 では sonarATS の開発にあたり、基本的にはデザイナーがFigmaを作成し、それに基づいてエンジニアが開発するというフローを取っています。 そんな中、先日エンジニアサイドで画面設計を行ってみるという実験的な取り組みをしました。 本記事では画面設計を行うことになった経緯と具体的な取り組み内容を振り返り、エンジニアが画面設計をすることのメリットと課題感について考えたことをまとめたいと思います。 エンジニアサイドで画面設計をするきっかけとなった要因 エンジニアサイドで画面設計をすることとなった理由として、大きく分けて以下３つの要因がありました。 デザイナータスク削減の目標 あるマスタ画面を開発したときの課題感 上述の通り、『簡単なマスタ画面の開発』のような共通的な画面設計になる機能については、できるだけデザイナーが介入せずエンジニア主導で開発している → 実際に
TypeScriptとドメイン駆動設計（DDD）を組み合わせ、APIを構築するハンズオンガイドです。この本では、DDDとは何かという基礎的なところからソフトウェア開発における戦略的設計、戦術的設計まで、包括的な知識を提供します。 戦略的設計では、ビジネスの要求に合わせたドメインモデルの設計をイベントストーミングを用いて行います。その後、戦術的設計では、具体的なコードの実装に関連するDDDの原則と実践を学びます。 TypeScriptを使ってコードを書きながら、DDDの概念を実際のプロジェクトに適用するヒントを紹介します。
ソフトウェアアーキテクチャはシステムの成功に不可欠な要素であり、ソフトウェア開発者にはこの分野における効果的なスキルが求められる。しかし、その学習資料はまだ十分ではないのが現実である。株式会社えにしテックの代表取締役 島田浩二氏は、ソフトウェアアーキテクチャに関する書籍を多数翻訳している。Developers Summit 2023 Summerに登壇した島田氏は、数々の書籍から学んだソフトウェアアーキテクチャの重要なエッセンスを紹介した。 ソフトウェアアーキテクチャとは？ 3つの定義を紹介 島田氏は2009年に株式会社えにしテックを設立。2011年からは一般社団法人日本Rubyの会の理事を務めている。島田氏が翻訳に携わった書籍には、『進化的アーキテクチャ』『ソフトウェアアーキテクチャハードパーツ』、『ソフトウェアアーキテクチャの基礎』『Design It!』（いずれもオライリージャパン）
0063 号 巻頭言
DDD を理解したいあなたのための DDD 入門以前 Rubyist Magazine 63 号をお届けする。 突然のお知らせで恐縮だが、日本 Ruby の会の主たる事務所が東京から北海道に移転した。それもあってあまりまとまった時間がとれず、11 月のうちに書くはずだったのが気がつくと 12 月も半ばを過ぎていたので、今回は以前書きかけていた文章を発掘してお茶を濁したい。 Ruby とは直接関係がなくて恐縮だが、Ruby に限らずソフトウェア開発では現在でもちょくちょく話題になることがある、DDD についての話である。 ドメイン駆動設計こと DDD は 2020 年代のソフトウェア開発でもよく話題にされるが、率直に言うとストレートにポジティブな評価が行われているとは言い難い。 どちらかというと、ある種マニアックで、対象分野が制限されており、また初心者にはとっつきにくいところがある手法と思わ
TypeScriptで学ぶ！SOLID原則
はじめに 皆さんこんにちは、株式会社エムアイ・ラボのエンジニアです！ 今回はソフトウェア設計のSOLID原則について学習したので、弊社のメインの開発言語であるTypeScriptのサンプルコードを使って共有できればと思います。 SOLID原則は、オブジェクト思考プログラミングにおいて、ソフトウェアがメンテナンスしやすく、拡張や変更に強いソフトウェア設計を行うための原則です。 SOLID原則にはSOLIDの頭文字をそれぞれとった、５つの原則があります。 単一責任の原則（Single Responsibility Principle） 単一責任の原則とは、クラスが一つの機能や責任を持つべきで、クラスが変更される理由は一つであるべきというです。 クラスが一つの機能や責任のみを持つようにすることにより、コードは再利用可能でテストが容易になります。 単一責任の原則を遵守している例 以下のBirdクラ
ランキング参加中プログラミング はじめに この記事では、Immutable Data Modelと呼ばれる設計手法をもとに、リレーショナル・データベースにおける、テーブル設計の話を書いています。また、今回の実践で利用する、別の考え方の背景を理解するために、Out of the tar pitという小論文の内容にも言及します。 「状態とは何か？」というややこしい話がたくさん出てきますし、データベースのテーブル設計についての話であることから、たくさんのSQLが出てきます。なので、データモデリングとか状態管理とか、特にSQLとかに興味がない人には面白くないと思います。 そのあたりに興味ある方は、読んでみて欲しいです。 Immutable Data Modelを、実際のアプリケーションで使うデータベースに採用するにあたり、どういう考え方で、どのようにテーブルを構成したか、自分なりの経験を書いていま
新築住宅に住み始めてから1年経過しました。この1年を振り返ってよかったポイントや後悔ポイント、おすすめ設備を紹介します。 よかったポイント 後悔ポイント トイレの照明スイッチの位置がドアに向かって左右逆だった 問題 有効そうな予防策 対応策 トイレの照明を人感センサーにし忘れた 問題 有効そうな予防策 次善の対応策 追記（2024/01/09） トイレのタンクを断水時用に貯水タンク付きにしたつもりが付いてないかもしれない 問題 有効そうな予防策 次善の対応策 予定外に常設のテレビを設置することになり準備ができていなかった 問題 有効そうな予防策 次善の対応策 リビング階段にカーテンレールつける準備ができていなかった 問題 有効そうな予防策 次善の対応策 蓄電池の容量が少なかった 問題 有効そうな予防策 次善の対応策 エコキュートが昼間に沸き上げしてくれない 問題 有効そうな予防策 次善の対
近年のソフトウェアプロダクト開発組織の活動単位としてよく言われるのは、「少人数で安定したチーム」であろう。表現は違えど、どの文献でもそのように述べられる。 それでは、「少人数」と「安定」の2つの要件を満たせば高パフォーマンスなチームが設計できるかと言えば、そんなはずもない。他にも要件があるはずだ。 そこで、チームに共通して必要だと考える要件を、設計に関わったこれまでの組織から抽出して言語化し、原則としてまとめてみた。それが、「安定」「アトミック」「非兼務」「少人数」「流動性」「イテレーティブ」の6つだ。 初期に携わった組織には欠けていた要素もあるが、何度も失敗を重ねるうちに見いだしたものだ。組織設計のプラクティスとしてよく聞くものもあるが、いずれも実体験を経て必要だと感じたものばかりである。 なお、本記事で取り上げる6つのチーム設計原則だけでは、組織設計として不十分だ。チームにどういった機
1ヵ月ほど間が空いてしまったが、連載748回の続きとなる。ただ、来週からはCESで発表された製品を取り上げるので、また少し間が空く。 SiFiveがリリースしたRISC-VベースのIP「E31」を 複数のメーカーが採用する 米国ではRISC-Vを実装したIPと、そのIPを利用したシリコンが2017年頃から次第に登場し始めた。SiFiveは先行者利益をフルに享受したベンダーの一社であり、実際同社が最初にリリースしたE31はいろいろなメーカーに採用された。 1つの例は(2018年にMicrochipに買収された)Microsemiである。Microsemiはまず自社のFPGAにE31を移植、自社のFPGAファブリック上でE31が利用できるようにした。ほかにもE31はいくつものベンダーにライセンスされており、この成功もあってRISC-VのIPベンダーとしての地位を確立した格好だ。 そのほかのベン
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
WordPressをS3で静的ホスティングしてセキュアに配信する - Qiita
シマノが窮地に追い込まれた。SRAM Eagleトランスミッションがすべてを変える日
ソフトウェアに関わる人が知っておくといいかもしれない法則10個
htmxとは何なのか？ その背景にある思想について - Qiita
「影響範囲の考慮漏れ」によるソフトウェアトラブルの多発はビジネス継続性に対する危険信号｜mtx2s
ゲーム開発に所謂なアプリケーション設計パターンを適用するのは難しい - hadashiA
あのサービスの監視・オブザーバビリティ アーキテクチャ選定【前編】 - Findy Tools
DMARC をなめるな - 弁護士ドットコム株式会社 Creators’ blog
コストをかけずにWebサービスを公開するための構成例 - Qiita
"クラウドアプリケーション 10の設計原則" をもっと楽しむ
コード品質向上のテクニック: 第 9 回（来た道を戻れ）
一番不思議なのははてなにいる一生独身おじさんおばさんが投資とかしてどうすんのってこと
「レイヤードアーキテクチャパターン」の長所と短所
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
チームの機能と配備を考えるための7つのチーム責務定義ガイドライン - mtx2s’s blog
人生が整うマウンティング大全
ミノ駆動さんに「なぜ負債解消にDDD？」と聞いたら、ソフトウェア開発の本質に気づかされた
AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
エンジニアが画面設計（Figma）を担当してみた振り返り
はじめに｜【DDD入門】TypeScript × ドメイン駆動設計ハンズオン
【DDD入門】TypeScript × ドメイン駆動設計ハンズオン
『ソフトウェアアーキテクチャの基礎』島田浩二氏が語る、エンジニアが最初に知っておくべきアーキテクチャリテラシー
実践Immutable Data Model - 紙箱
新築住宅に1年住んでわかった後悔ポイントとおすすめ設備 - 若くない何かの悩み
チーム中心の組織作りのための6つのチーム設計原則 - mtx2s’s blog
早期からRISC-Vの開発に着手した中国企業 RISC-Vプロセッサー遍歴 (1/3)