ソフトウェア設計の課題 ソフトウエア設計の品質 学習と成長 設計の初歩を学ぶ 中級者への道 上級者の挑戦Read less
ソフトウェア設計の学び方を考える
ソフトウェア設計の課題 ソフトウエア設計の品質 学習と成長 設計の初歩を学ぶ 中級者への道 上級者の挑戦Read less
実況中継シリーズ 「開発現場で役立たせるための設計原則とパターン」 #builderscon 2018 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
先日慶應義塾大学日吉キャンパスで行われた builderscon2018、最高のカンファレンスでしたね。わたしも「開発現場で役立たせるための設計原則とパターン」というタイトルで発表させていただきました。今回は恒例「実況中継シリーズ」として、プレゼンの再現をブログで行いたいと思います。 なお、過去の実況中継シリーズは前職の技術ブログにまとまっていますので、そちらからご覧ください。 それでは本編を開始したいと思います。 開発現場で役立たせるための設計原則とパターン アバンパート よろしくお願いします。 まず最初に簡単に自己紹介をさせていただきます。 先月転職をしまして、8/1からClassiという会社で働いています。妻と息子がおります。Scalaが好きですが、仕事ではRubyメインという感じです。 Web+DB PressやSoftware Designで何度か特集を書かせていただきました。と
今あえてDRY原則に向き合う
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
作り直し - hitode909の日記
ソフトウェアを作ってて、作り直したり、書き直したりするべきかどうかという話をすることがある。 大きな規模だと、ソフトウェアを作り直す、というところから、小さな規模だと、込み入った機能を書き直す、くらいまであるけど、作り直すとうまくいくのは、次の二つのうちどちらかではないか。 最初に作ったときより世の中の技術が発展したとき 昔のコンピュータでは収まらなかったとか、昔は良いライブラリがなかったけど、今はある、というとき。 単に今ありふれた技術で作り直すと、よいものができそう。 最初に作ったときよりはコンピュータのスペックが上がったので、そのつもりで、並列度倍に上げても止まらないし、より速く動かせる、とか。 昔はバッチで計算しないといけなかったけど、今ならリアルタイムに返せる、とか。 昔は依存管理のよいライブラリがなかったけど、今ならこれ入れたら簡単、とか。 最初に作ったときより人間の技術が発展
ドメインモデル貧血症 - Strategic Choice
Anemic Domain Modelどういうこと？マーチン・ファウラーさんの著書「エンタープライズ・アプリケーション・アーキテクチャ・パターン」で紹介されている、「ドメインモデル」パターンを使用した場合の、「アンチ」パターンです。本来のドメインモデルは、「対象となるビジネスエリアをモデル化したオブジェクトのレイヤ全体を挿入する」ということです。モデル化したオブジェクトは、オブジェクト指向設計の基本概念通り、データとプロセスを結合し、対象となるデータと関係しているプロセスを集積します。ドメインモデル貧血症は、一見、本物のドメインモデルに見えます。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。ただし、それらのオブジェクトにはわずかな振る
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
分散システム設計のチェックリスト - ワザノバ | wazanova
http://monkey.org/~marius/checklist.pdf 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 TwitterのMarius Eriksenは分散システムのエキスパートであり、モジュール化され、安全でかつ効率よく機能するサーバソフトの構築のノウハウは、「Your Server as a Function」という論文にまとめられています。 また、分散システム設計における留意点も、下記の内容のチェックリストというかたちで紹介してくれています。 1. 障害耐性 もし依存先が障害を起こしたらどうなるか？その障害がゆっくりと起きたらどうか？ システムをどのようにスムーズにデグレードさせることができるか？ システムは想定以上の負荷にどう対処するようになっているか？ 大きな障害が起き
iOSアプリの設計でBaseViewControllerのようなのは作りたくない - Qiita
結論 小手先で楽をするためのボトムアップな設計は後々苦労する 継承を使った差分プログラミングは長年運用していくと大変だ 人は楽な方に流れるので、Baseクラスで解決すべきでない問題をBaseクラスで解決して後で困る はじめに この文章は2015年1月のpotatotips13で発表するネタ用のメモに書いてました。 実際に発表した内容を含む様子は下記のページにまとめています。 http://curiosity.co.jp/potatotips13/ 会場で質問されたりツイートの様子を見てて気づいたのですが、BaseViewControllerを使いたくないという"この文章"と同意の意見は、比較的経験のあるおじさんたちの意見であって、若い人からするとなぜBaseViewControllerを使ってはいけないように言われるのかについて具体例を聞きたがる傾向が強いです。 また、不必要に自分が気に入
bitlyでの分散システム構築から学んだこと
5月に開催されたBacon Conferenceで，bitlyのアプリケーション開発リーダのSean O’Connor氏は，毎月600億クリックを処理する分散システムの開発を通じてbitlyの開発者たちが学んだ，最も価値ある教訓について説明した。 分散システムとは何か？ 分散システムを定義する３大特性は，氏によれば，Wikipediaで簡単に見付けることができる。 コンポーネントノードの真の並行性。これによってノード間の同調に関連するコストと複雑性が発生する。 共通クロックの不在。このため，異なるノードで発生したイベントを時間順に並べることは不可能になる。 障害の独立性。これはノード障害がシステム内の他のノードに影響を与えない，という能力として理解されるべきだ。 従って分散システムの構築では，これらの特性を扱うことを目標にする必要がある。 ただし氏の意見として，システムの分散的特性に起因す
再利用性を高めるAPIの設計と見極め - ワザノバ | wazanova
https://www.youtube.com/watch?v=ZQ5_u8Lgvyk 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約1時間前 Casey MuratoriのGameTech Conference 2004での講演。 コードを再利用したいと皆言うけれども、いざ実践となるとなかなかうまくいかない。 ことの背景の解説とその解決策の方向性について、キャラクターアニメーションパッケージの開発を通じてCaseyが学んだことをシェアしてくれています。10年経っても変わらず、またゲーム以外の開発においても、当てはまることが多いかと。 インテグレーションのオプション あるコンポーネントをAPIを用意してゲームに組み込むインテグレーション作業と、その作業がどれだけゲームの完成に効果がある（ゲームプレイの完成とい
論理的な設計と非論理的な人間 - mizchi's blog
TDD勢に叩かれそうな言葉で、「複雑すぎてテストできない」といいたくなるケースあるんだけど、「テストを想定してないので振る舞いが多用すぎて現実的にすべての振る舞いを確認できない」という、いわゆる設計が失敗してるコード、どう向き合ったらいいんでしょうか(都内・26歳・男性)— 俺は平気だよ (@mizchi) 2014, 5月 22 GUIアプリでテスト可能な設計するの、副作用が観測されないことが多いので、実質的に大量のバックドアを用意することになると思うんですよ。で、それってどうなのっていう。— 俺は平気だよ (@mizchi) 2014, 5月 22 MVVMがテストしやすいの、値に振る舞いが従属するので、値を確認すればいい、という建前があるからだけど、テストのためにMVVMを採用するのは本質的ではないと思うし、とはいえ何かしらの設計を講じないとMとVが密結合した構造を取るので、プログラ
実践的な設計って、なんだろう？
Devlove 名古屋 2014-5-18 DDD, Object Oriented Design, ドメイン駆動設計 オブジェクト指向設計Read less
■ - hitode909の日記
staticおじさんっていう，インスタンスを作らず，ぜんぶstaticメソッドで済ませようという人が居る．僕もクラスなるべく作りたくないと思っていて，ちゃんとしたクラスを作るのは難しいので，インスタンス作らずに済むに越したことはないと思う．ドメイン駆動設計っていう本読むと，Serviceクラスは状態を持たないみたいな話があったけど，いま触ってるプロジェクトではServiceクラスはインスタンスを作らず，クラスメソッドだけ持たせるようにしてる．インスタンス作ると，そのインスタンスは何を持つのかとか，誰がどういう責任を持つのかとか，いろいろ考えることあるけど，クラスメソッドなら単なる関数なので，作るのが楽．オブジェクト指向分からないからという理由でやってるのではなくて，作らず済むときには作らないようにしている．必要なときにはインスタンス作っていて，引数10個の関数の呼び出しをがんばって組み立て
オブジェクト指向設計の４つの流派からドメイン駆動設計へ - プログラマの思索
先日の大阪DDD勉強会に刺激を受けて、「ユースケース駆動開発実践ガイド」と「オブジェクト開発の神髄」と「アジャイルソフトウェア開発の奥義」「実践UML」を読み直している。 ラフなメモ書き。 【元ネタ】 【限定募集：第1回の申込者のみ、参加登録可能】第２回ドメイン駆動設計読書会@大阪 - ドメイン駆動設計読書会@大阪 | Doorkeeper vol2_20140309 · dddosaka/reading_ddd_report Wiki 【１】個人的には、オブジェクト指向設計という考え方は好き。 データモデリングはDB設計でも業務の設計でも必須だが、データだけではシステムは動かない。プログラムも作る必要があるけれど、DOAにこだわると、なぜかソースの自動生成に走ってしまうように思える。 オブジェクト指向設計は、アジャイル開発と相性がよい。 また、開発チームの構造解析にもオブジェクト指向設計
コードレビュー - hitode909の日記
コードレビュー，慣れるとできるけど，いきなりdiffを渡されて，どうぞ見てくださいと言われてもよくわからないと思う． やりましょうというのはいいけど，ただむやみに読んでもうまくいかない．変更がある程度大きくなるとdiffだけ見てもよくわからないので，いろいろ見ることになる． 僕はいつも以下のようなことを無意識にやってて，うまくいってる気がしてる．GitHubのPull Requestの仕組みを使ってる前提で． Discussionをさらっと眺めてどういう問題を解決したいのか見る Commit Statusを見て，テスト通ってることを確認する Commitsタブで1コミットずつブラウザの新しいタブに開く 全部クリックし終わったら古い順に1コミットずつ読む 気になる点があったらエディタとかにメモしておく．あとで書き直されるかもしれないので，まだコメントしない 全コミット見終わったらFiles
ssig33.com - Rails のファットモデル対策
http://37signals.com/svn/posts/3372-put-chubby-models-on-a-diet-with-concerns これ読めばいいんじゃねえかと思います。 Rails を設計している人達は module に切り出せばそれでいいだろ糞 include された結果生成されるドメインモデルが超絶巨大だろうが知ったことか糞 という発想で生きていることが伺えます。 module に切り出す粒度はどうするかとかこれはこれで難しいとろはあるのですが簡単な考え方ですし、現実的な落とし所がこの辺にある場合は多いと思います。 無意味に複雑なやり方を導入しようとする人間を殺せ。 back to index of texts Site Search
Transaction Resource パターン - リソースモデリングパターン
POST /transactions ↓ PUT /transactions/123 ↓ PUT /transactions/123/committed 「Webを支える技術」p278より引用 実際のシステムでは、より複雑な処理、たとえば複数のリソースにまたがった変更をひとまとまりに扱う、いわゆるトランザクションが必要になるケースもあるでしょう。 主にCollection & Member Resource パターンを用いたトランザクションの実装。 ウィザードなどにも適用可能で、モデルでないリソースになりうる。 例 http://qa.atmarkit.co.jp/q/2555#answer_15110 の id:moro さんの回答より引用 やり方はいろいろありますが、データインポートなど複数のリソースに影響を及ぼす、バッチ的な動きをさせたい場合には「トランザクションリソースを作る」とい
spika hackathon というのをやった - id:k-z-h
2013-10-21 spika hackathon というのをやった refs Spikaを公開して起こった事 - ヨーロッパで働く社長のブログ Spika Hackathon に参加してきた - Born Too Late お二人とも綺麗なことを書いているので僕はあんまり綺麗じゃないことを書こうと思います。あ、あと読ませる気全くないのでクソ読みにくいと思うので適当に流し読みするのが良いかと思われます。まず前提として、自分はこのプロジェクトにはビタイチ興味がないし、将来にも一切の期待をしていない。失礼な話ではあるが完全に事実だし、hackathon を主催したのもプロジェクトを良いものにしようという意図は全くなく、別の狙いがあってのことです。公開された Spika-Server のソースコードをざらっと読んで、これはもう貢献する価値無し、と判断したのですが理由としては大量の脆弱性やレガシ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テスト容易性のためのシステム設計
Udi Dahan氏がイベント駆動アーキテクチャと疎結合なシステムについて語る
