DDD失敗談を話して学んだこと関西Javaエンジニアの会(関ジャバ) '17 10月度 - connpass https://kanjava.connpass.com/event/68169/ での発表資料です。
ヘキサゴナルアーキテクチャ(Hexagonal architecture翻訳)
Alistair Cockburn による Hexagonal architecture の翻訳です。PoEAAで言及されていることから、2002年ごろにはすでにC2 Wikiにページがあった模様。似たようなアーキテクチャである クリーンアーキテクチャ も翻訳したので参考にしてください。 この記事は著者から許可を得て公開しています。Thanks to Alistair Cockburn! 目次 パターン: Ports and Adapters (構造に関するパターン) 意図 動機 解決法の本質 構造 サンプルコード ステージ1: FIT アプリ 定数をモックデータベースとして ステージ2: UI アプリ 定数をモックデータベースとして ステージ3: (FITまたはUI) アプリ モックデータベース 応用ノート 左右の非対称性 ユースケースとアプリケーションの境界 ポートはいくつ? 既知の用
DRYと不当な抽象化によるコストについて | POSTD
本記事は、もう随分と長い間、私がToDoリストに記したままになっていたものです。ですが今日だけは、その考えを実行に移すエネルギーと時間があったようです。私は今、少し前に最初の記事を投稿した時と同じカフェにいます。たまたまなのか、それとも……。店員が私に出した飲み物に何か入れていたに違いありません。 ベストプラクティスにならえ、という古き良きアドバイスがありますよね。そうした情報は常に耳に入ってきます。私たちは、どういうわけかテクニカルな会話の中で DRY とか KISS といった頭字語を第一の原則としてきました。熱心に、まずそうした概念に従っています。たまたま、知識欲があるために、あるいは知識がなかったために、そうした概念から外れたことをする人がいようものなら、確実にその人に嵐のような批判を浴びせます。この原則にとらわれすぎていて、そこに背を向けることを拒んでいるのです。 念のためですが、
リアクティブ宣言
異なる分野で活動する組織が、同じようなソフトウェア構築のパターンを独立に発見している。このようなシステムはより堅牢で、より耐障害性があり、より柔軟で、より最新の要求を反映しやすくなっている。 こうした変化が起きているのは、近年、アプリケーションの要求が著しく変化してきているからだ。ほんの数年前、巨大アプリケーションは数十のサーバから構成され、数秒の応答時間と数時間のオフラインメンテナンスを許容し、データは数ギガバイトだった。今日のアプリケーションは、モバイル機器から数千のマルチコアプロセッサによって動作するクラウドベースのクラスタまで、あらゆる機器上に配備される。ユーザはミリ秒の応答時間と 100% の稼働率を期待する。データはペタバイト単位で測定される。昨日のソフトウェアアーキテクチャは、今日の要求を全く満たしていない。 求められているのは、システムアーキテクチャに対する明快なアプローチ
新卒ソフトウェアエンジニアのための技術書100冊 - クックパッド開発者ブログ
こんにちは、技術部 高井です。 春といえば、フレッシュマンの季節ですね。このブログを読む方の中には、明日からエンジニアとして新社会人になるという方もいらっしゃるのではないでしょうか。クックパッドでも新しい仲間を迎えるための準備をしていたところで、その準備の一環として「新卒ソフトウェアエンジニアのための技術書100冊」というものを作成しました。 この100冊は、職業ソフトウェアエンジニアとしてキャリアを積むにあたって、読むべき技術書に悩んだら、まずはこのリストから選ぶとよいのではないでしょうかという提案です。 リストに多少の趣味や主張がはいっているのは、まあご愛嬌ということでお許しいただければとおもいますが、職業プログラマとして知っておくべき知識を網羅できるように心がけました。古典と呼ばれる名著についてはできるだけ取りいれ、独習が難しい難解なコンピュータサイエンスの教科書は避けています。これ
若手開発者の後悔 | POSTD
(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間
コードレビューについて - (define -ayalog '())
普段お仕事している中で何故かコードレビューをしている時間がわりとあって、暇さえあれば(暇がなくても)コードレビューしている。 そんな中でどういうところを見たらいいのか、あるいは見るべきなのかというのが自分の中である程度蓄積された気がするので書いてみる。あと最後に普段考えていることを少し書いた。 前提 現在の僕の参加しているプロジェクトはこんな感じ Rails プロジェクト( AngularJS 使ったりしている) Git 使ってる( Pull Request ベースの開発で以下が merge 条件) 2 人以上に approve される テストが通ること(継続的インテグレーションの実施) 静的コード解析は導入している( Rubocop, jshint, pre-commit など ) テストのカバレッジは計測していない(月一くらいで測ってるらしいんだけど、だからどうっていう話はない) プ
エンジニアの面接でコードレビューさせてる
（あんま多くないみたいだから多分すぐ身バレしそうだけど書く） エンジニアの面接で実際にコードを書かせる会社が最近は多いみたいだね。でもウチでは特に面接で書かせない。というか今まで書いてきた、関わってきたコードなんて書類で大体分かるでしょ？ それよりも、ウチではコードレビューをさせてる。 選考用にわざと少し突っ込みドコロの多いコード（30〜50行程度のコードを3〜4ファイル）を渡して、もちろんファイル構成自体へのレビューも含めて、どんな意見をその人が出せるかを問う。 レビュー用のコードは複数言語用意してて、一番得意な言語を選んでもらってる。 時間は1時間。資料と赤ペン、そしてネットに繫がったパソコンを渡して、いくらでもググってもらって構わない環境でレビューを紙に赤して貰う。 「コードレビュー」ってものに対しての認識だとか、コードを管理するための能力もある程度分かるし、すごく良い選考制度だと思
メタプログラミングをして割に合うかの判断基準：処理を1箇所に局所化できるか - 2014-01-16 - ククログ
毎日他の人のコミットをながめる文化で生活していると、理由は浮かばないけど「ん？このコミットはなんか気になる」と感じるようになります。それは、新しいことを知ることができたコミットだったり、真似したくなるようなコードが入っているコミットだったり、なんかまずそうな気がするコミットだったり、様々です。 「ん？」と感じてコミットを見直してみても、何が気になったか自分でもすぐにわからない場合があります。そんなとき、気になったことをコミットした人に伝えるために、コミットへのコメントをまとめ始めます。「コミットした人に伝えるため」というように、他の人に伝えようとすることがポイントです。他の人に伝えるためにまとめようとすると、思いの外なにが気になったかまとまるものです。 今回は、メタプログラミングを使ってコードを整理したコミットで「ん？」と感じたときのことについて紹介します。このおかげで「メタプログラミング
Dash – Snippet Manager, Documentation Browser
Overview Dash is an API Documentation Browser and Code Snippet Manager. Dash instantly searches offline documentation sets for 200+ APIs, 100+ cheat sheets and more. You can even generate your own docsets or request docsets to be included. Supported Documentation Sets Dash comes with 200+ offline documentation sets. You can choose which documentation sets to download and Dash will take care of the
2012/07/06 リーダブルコード − 忘れてもいいコードを書こう。#devlove
ichitani ／ 組織を芯からアジャイルにする @papanda 今日はリーダブルコードの #devlove 97本に続いてオライリーさんと組んでやります。DevLOVEが何が出来るというわけではないのだけど、良い本が売れてそれでまた良い本が世の中に出てきたら、それだけでこういう企画をやる値打ちはあると思っているのだった。 2012-07-06 16:50:31 Ryan Edsall @rezn #devlove "@LaurentKP: @iMMMOOO that's not what I mean I'm the dev of EasySmileys and I receive good reviews because of MegaSmiley promo ℓ☺ℓ" 2012-07-06 17:15:18
Rubyの例外クラス設計 - kなんとかの日記
具体的には、テストです *2 。例えば foo(1, 2) で wrong number of arguments が投げられることをテストしたいとします。以下のテストだと、wrong number of arguments 以外の ArgumentError が投げられる場合でも合格になってしまいます。 assert_raise(ArgumentError) { foo(1, 2) }ちゃんとやりたければ、例えばこんな感じのコードを書かないとだめかな。 flag = false begin foo(1, 2) rescue ArgumentError => e raise unless ex.message[/\Awrong number of arguments \(\d+ for \d+\)\z/] flag = true end assert(flag) Ruby の例外クラスは分
Designing a framework in an "open" way (オープンなフレームワーク設計)：An Agile Way：オルタナティブ・ブログ
"Beautiful Code" を読んでいます。 いいですねー。カーニハンやベントレー（『プログラマの打ち明け話』、『珠玉のプログラミング』、『プログラミングの設計と着想』など、昔ファンでした）の文章をひさしぶりに読みました。まだまだ、プログラミングにもわくわくすることが一杯ありますね。 ぼくが最も感動したは、Michael Feather （"Working Effectively with Legacy Code"の著者）の "Framework for Integrated Test: Beauty Through Fragility"(英語GoogleBook全文) です。コーディング（プログラム設計）に関する Ward Cuninngham の逸話はいくつもあります。November メソッドの話、400行の Perl で書かれた初版 Wiki の話、などなど。 今回は、Web
「プログラミング言語Ruby」を読まなくてもよいのは誰か : \ay diary
一昨日になってようやく入手できたプログラミング言語Ruby[rakuten]を、Ruby 1.9.1RC2とそのNEWSファイルを手元に置きながら読んだ。 少々乱暴な言い方になるかもしれないが、この本は以下のような人には用のないものだと思う。 Ruby 1.9.xもRuby 1.8.xも十分に理解できている Ruby 1.9.xをしばらくは使うつもりがなく、自分が使う範囲においてRuby 1.8.xに不明なところはない Rubyの経験がなく、その他のオブジェクト指向言語の経験および知識もない プログラミング経験がなく、これからプログラミングの学習を始める この本はRubyそのもののかなり詳しい解説書である。入門書ではない。一応は簡単なところから入る形になっているのだが、大部分はすでにRubyを使っていて、ちょっとしたことなら困らない程度の知識があることを前提としている。つまり、
ファクトリー ファクトリー ファクトリー API のユーザビリティテスト
前に 欲しいと書いた API のユーザビリティテスト. 実際にやってみたぜという話を読んだ. "The Factory Pattern in API Design: A Usability Evaluation (PDF)" という記事がそれ. 俎上に載ったのは factory パターン. 素のコンストラクタとどちらが使いやすいかを比べてみたという. そんなの, Factory が腐ってるだなんて Joel...じゃなくて Joel の読者も言っている. 実際この調査でも "factory は使いにくい" という思ったとおりの結論. 面白さはユーザビリティテストをした事実そのものにある. 調査では 12 人の被験者をあつめ, 5 つの課題をこなしてもらう. コードはぜんぶ Java. 課題1: メールを送信する. ライブラリを使ってこんな風に書けたらいいなと思うコードを notepad で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Async programming is all about programming synchronously.
Practical Meta Programming on Rails Application
書いたもの
repl.it
正規表現に見切りをつけるとき