新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 - Qiita
あわせて読みたい 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 「オブジェクト指向プログラミング」と「関数型プログラミング」のたった一つのシンプルな違い あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ 2015年に備えて知っておきたいリアクティブアーキテクチャの潮流 この記事について この記事は新人向けの研修内容を再編集してお送りいたします。 ここで述べる内容はどのようにして現在のプログラミングスタイルが生まれてきたかを理解することで、よりよいプログラムを書くためのもので、正確なソフトウェア工学の歴史を学ぶためのものではありません。正確な歴史を把握したい場合は、原典をあたるようにしてください。 また、想定している読者は「よくあるオブジェクト指向プログラミングの学習」を既にし
なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − ＠IT
ユーザー同士のつながりを元に時系列に140文字のメッセージを20個ほど表示する――。Twitterのサービスは、文字にしてしまうと実にシンプルだが、背後には非常に大きな技術的チャレンジが横たわっている。つぶやき数は月間10億件を突破、Twitterを流れるメッセージ数は秒間120万にも達し、ユーザー同士のつながりを表すソーシャル・グラフですらメモリに載る量を超えている。途方もないスケールのデータをつないでいるにも関わらず、0.1秒以下でWebページの表示を完了させなければならない。そのために各データストレージは1～5ms程度で応答しなければならない。 Twitterのリスト機能の実装でプロジェクトリーダーを務めたこともあるNick Kallen氏が来日し、2010年4月19日から2日間の予定で開催中の「QCon Tokyo 2010」で基調講演を行った。「Data Architecture
DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab
株式会社ログラスの松岡です。 本記事では、DDDに関する疑問で頻出な、複数集約間の整合性を確保する方法について、具体的なコードを交えて紹介します。 実装方法は、主に以下の3つに分かれます。 ユースケースで複数集約に更新をかける ドメインサービスを使用する ドメインイベントを使用する 目次 目次 集約の定義について 題材とする事例 実装方法1. ユースケースで複数集約を更新する メリット・デメリット 実装方法2. ドメインサービスを使用する メリット・デメリット 改善案 実装方法3. ドメインイベントを使用する ドメインイベント作成に制約をつける メリット・デメリット まとめ 集約の定義について詳しく知りたい方は 現場での導入で困ったら 集約の定義について 集約自体の説明については、本記事では割愛します。詳しくは下記の書籍「集約」の章をご覧ください。 little-hands.booth.p
![DDDで複数集約間の整合性を確保する方法(サンプルコードあり)[ドメイン駆動設計] - little hands' lab](https://cdn-ak-scissors.b.st-hatena.com/image/square/e19eb6aae8a33a9c7d58ab11012b9b1e4fd3dc14/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Fl%2Flittle_hands%2F20210306%2F20210306230551.png)
ラムダ式でCommandパターンで書かれたコードをシンプルにする ～ ラムダ式使いへの第一歩
Java SE 8では、新しい構文要素として「ラムダ式」が導入されました。これにより、これまで用いられたデザインパターンのいくつかは、特に意識しなくても同等のコードが書けるようになります。デザインパターンが解決しようとしていた問題が、ラムダ式によって素直に実装できるからです。本連載では、デザインパターンを使って書かれたコードをラムダ式を使ったシンプルなコードに書き換えながら、ラムダ式の使いどころ・使い方を学んでいきます。 言語の洗練によってパターンは背景に退く まず、デザインパターンについておさらいしましょう。デザインパターンとは、オブジェクト指向言語を用いてプログラムを書くときに、頻発するプログラム設計上の工夫を「パターン」としてまとめたものです。ギャング・オブ・フォー（GoF）と呼ばれる4人の著者（エーリヒ・ガンマ、リチャード・ヘルム、ラルフ・ジョンソン、ジョン・ブリシディース）が執筆
Minimal Cake Pattern 再考 - Qiita
かつて Scalaにおける最適なDependency Injectionの方法を考察する 〜なぜドワンゴアカウントシステムの生産性は高いのか〜 という記事が公開されたとき、ぶっちゃけ私は 100 日も経てば忘れられているだろうと思っていました。私の予想に反して 2020 年現在でも Twitter では Minimal Cake Pattern への言及がたまに見られ、中にはこのパターンが（あるいは DI そのものが）難しいと感じる人もいるようなので、今一度このパターンについて整理してみようと思います。 依存性注入とは Minimal Cake Pattern は 依存性注入 (Dependency Injection, DI) を実現するためのデザインパターンです。ですのでまずは DI についておさらいしましょう。理解済みであればこの節は飛ばして構いません。 例として、時間の計測を行う
オブジェクト指向エクササイズのススメ
3. ThoughtWorksアンソロジー ThoughtWorks社コンサルタント ● の 骨太なエッセイ集 様々な ジャンルを収録 ● DSL、プログラミング、設計、 マネジメント、ビルド、デプロイ、テス ト．．． オライリーさんブースで ● 絶賛販売中！ 3
UML作成ガイド | オンライン作図ツール Cacoo(カクー)
CacooのUMLガイドへようこそ！ このガイドは、こんな人に役立ちます。 複雑なシステムの視覚化に興味がある UMLの入門書を求めているシステムアーキテクト、ソフトウェアエンジニア、ソフトウェア開発者 UMLの基本とUML 2.5でのアップデートについてブラッシュアップしたい 本ガイドは以下の3部構成で形成されています。UMLを基礎や応用など、自分が学びたいテーマを選択しましょう！ UMLの概要 モデリングとは？ モデリングとは、ソフトウェアアプリケーションの設計を視覚化し、チームがコーディングを開始する前に要件を満たしていることをチェックする方法です。 超高層ビルの建設を始める前に建築家が設計図を作成するように、開発者はモデリング図を使って、コーディングを始める前にこれから作るソフトウェアの設計を固め、テストすることができます。 どんなプロジェクトであれ、綿密な計画を立てることで最初の
ARCHITECTURE.mdというものを書いてみた - maru source
こんにちは丸山@h13i32maruです。システム全体を簡単な図とテキストでまとめる「ARCHITECTURE.md」というものを最近知りました。これは良さそうと思い、JasperのARCHITECTURE.mdを書いてみました。 jasperapp/jasper/ARCHITECTURE.md ARCHITECTURE.md自体の目的は「プロジェクトへの新規参加者が全体像の把握を効率的に行えるようにする」という感じです。書き方の指針や注意点などは考案者による記事を見てもらうのがよさそうです。また良いサンプルとしてrust-analyzerというOSSのARCHITECTURE.mdが紹介されています。 https://matklad.github.io//2021/02/06/ARCHITECTURE.md.html https://github.com/rust-analyzer/ru
Webアプリの設計はガーデニングと一緒です
Webアプリの設計はこわくありません。日々開発が快適になるように手入れをする、まるでガーデ ニングのようなものです。一度やればいいものでもないし、サービスが続くかぎり終わりもありません。 この動画は下記スライドから設計に関する話題を再演したものです。 https://speakerdeck.com/okunokentaro/frontend-conference-fukuoka-2018 # タイムライン 0:00 オープニング 0:53 設計にはフェーズがある 4:12 コードレビューをする 7:15 意思決定を減らすスキームを導入する 11:11 振り返り 14:30 エンディング
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
You Could Have Invented EigenLayer: Explaining EigenLayer
RESTful APIのエンドポイントを綺麗に設計しよう ｜保守性の高いソフトウェア開発のTips集
藤村 on Twitter: "アプリケーションコードでの抽象化、不可能に近いくらい難しいと思った。抽象化する時点で、その時の局所解ではなく、抽象化された形で想定される全ての状況に対応することを求められる。そういうのはライブラリで時間をかけて丁寧にやる仕事"
ひさてるさん on Twitter: "Prototype と Flyweight は動機が OOP パフォーマンス落ちるって苦情への対応だから微妙。Interpreter もぜんぶ OOP で固めず外部化するとこは ASCII テキストに吐けって話でイレギュラー対応"
加藤潤一(かとじゅん) on Twitter: "https://t.co/qQCP7jUhk1 ロジカルにCQRSしたいなら、Repositoryはクエリ責務ではなくコマンド側で利用する責務と解釈したほうがよい。そう考えないとリポジトリにページングやソートというクエリ責務が紛れ… https://t.co/kIl9ygB0Ie"
大貫剛🇺🇦🇯🇵З Україною on Twitter: "みずほATMのトラブルを見てると、JR東日本のSuicaシステムは先見の明があったなと思う。全システムがダウンすると首都圏の通勤が麻痺してしまうおそれがあるので、それを想定したシステムになってる。"
加藤潤一(かとじゅん) on Twitter: "広義としては、ドメイン駆動設計は問題を解く考え方イコールドメインモデルをソフトウェアに反映する設計手法です。問題を解かないソフトウェアはないと思いますので多かれ少なかれドメイン駆動設計はするのではない… 続きは質問箱へ… https://t.co/GflMjENWA2"
杉本啓 on Twitter: "getterは、自身が返す値がインスタンス変数として保持されたいたのか算出値なのかという知識を隠蔽するのが責務。その責務をちゃんと果たしている。 その他の知識を隠さないからといってgetterはカプセル化違反だというのは、スジが通らない。責務を分離して考えましょう。"
Unityにおける設計パターン
杉本啓 on Twitter: "設計について講釈垂れる前に、それなりに完結したシステムを自分で設計し、稼働・運用まで持ち込んでみた方がいいと思う。 それをしていない人、結構いるんではないか。"
杉本啓 on Twitter: "コードを書く時に僕が考えているのは、 ①達成したいことそのまま書くのではなく、相互に独立した要素に分解して書こう（関心の分離） ②意図が伝わる書き方にしよう ③ユニットテストし易くしよう ⓸その上で、要素の数をできるだけ減らそう ということぐらい。"