Coderetreatを題材にした設計本

井上です。

Coderetreat (*1)というイベントをご存知でしょうか?
Coderetreat とは、ソフトウェア開発と設計の基本を学ぶためのイベントで、以下のような特徴があります。

  • 一日掛かりで行われる(5〜6セッション)
  • 参加者はペアでコードを書く(ペアプログラミング)
  • 1セッションは45分間
  • ライフゲーム (*2)」を題材とする
  • 各セッション終了後にコードを削除する
  • 各セッションで新しいペアを組む
  • セッションが進むにつれて制約を課す

また、CodeRetreatを世界中で同日に開催する 「Global Day of Coderetreat」 というものもあり、世界中で活発に開催されているイベントで、日本でも度々開催されています。(*3)
私もCodeRetreatに参加したことがあるのですが、一日掛かりのイベントなので大変な集中力を要しますが、とても勉強になりました。

そんな Coderetreat を題材にした設計本(洋書)を見つけたので紹介します。

続きを読む

スタートアップ向けハイブリッドUIフレームワークの比較

はじめまして、水谷と申します。

Railsの開発をメインにやっているのですが、最近ではフロント部分の比率も増えてきており、Backbone.jsやAngularJSなどJavaScriptに関わったり、Hubot, Chef, Vagrant, AWSなどでインフラ関連もしたりしています。小さなチームでやることが多いので何でも屋的なエンジニアです。

はじめに

スタートアップのサービス立ち上げの開発に関ることが多く、ここのところデスクトップ向けの開発では、バックエンドにRailsを使い、フロントエンドにリッチなUIを提供できるようにAngularJSを採用するケースが多くなってきています。

一方で、これだけスマートフォンが普及しているとサービス開始と同時にモバイルアプリも提供したいというニーズをよく承けます。

ただ、スタートアップで限られたリソースでデスクトップ向けの開発と同時にネイティブアプリを開発していくのは非常に難しい場合が多いと思われます。

そこで、タッチ/マルチタッチイベントやスマートフォン特有のAPIを扱うためのフレームワークを導入して、HTML5ハイブリッドアプリを構築するのも一つの手ではないでしょうか。

ここでは、AngularJSを使ってHTML5ハイブリッドアプリを構築できるフレームワークの代表的な3つのフレームワークの比較をしていきたいと思います。

続きを読む

ヘキサゴナルアーキテクチャ

河上です。

最近傾倒しているドメイン駆動設計という文脈で「ヘキサゴナルアーキテクチャ」というアプリケーションアーキテクチャについて色々と思う事を書きたいと思います。

ヘキサゴナルアーキテクチャはPofEAA(エンタープライズ・アプリケーションアーキテクチャパターン)という本で知りました。

アリスター・コーバーンのヘキサゴナルアーキテクチャ

Hexagonal-architecture

Applicationと記述してある内部の六角形はビジネスの感心事であるドメインモデルで、それ以外はすべて外部とのインターフェースであるというドメイン中心の考え方で、ポピュラーな3層アーキテクチャとはずいぶんと違う印象を受けますね。

この図を見てまず疑問に思ったのは【外部から内部への依存】なのか、【内部から外部への依存】なのかということなのですが、現時点の理解では、【外部から内部への依存】だと思っており、そちらに振り切って設計をしています。

私がこのように判断したのは「変更は予知できない」という経験からです。

いろいろ考えて、予想して、変更がありそうな部分を柔軟に作ったとしても、結局その柔軟性が発揮される事がなく無駄な複雑さだけが残ったという苦い経験があります…。
この経験から、下手に予想するのではなく、少なくともビジネスの文脈ですべてが規程されている形にしておけば、ビジネスの形との整合がとれているために変化点の見極めがしやすくなり、結果として変更がやりやすくなるはずだと考えました。そしてビジネスの形に合わせるということは、ビジネス(ドメイン)へ依存するという事なのではないかと思い、この依存の方向は外部から内部(ドメイン)へ向くべきであるという結論になりました。

また、この依存方向だと、単純なアプリケーションではドメインモデルが振る舞いらしい振る舞いを持たずただの構造のようになってしまったりしますが、そのときはそのドメインモデルがビジネス(業務)を表現できていれば良しとしています。

今後、実践していく中でまた違う結論になることもあるかと思いますが、「間違ってる」「こんな考え方があるよ」「こんなアーキテクチャなら良いのでは?」など、ディスカッションのネタがいただけると幸いです。

似たアーキテクチャで、より表現が近いかなというものを見つけたのでリンクを貼っておきます。

アンクル・ボブのクリーンアーキテクチャ

Gradleプロジェクトで依存関係の競合を解決する

河上です。

前回記事に載せられていなかったので改めて自己紹介を。
関西に住んでフリーエンジニアをやっております。河上です。
よろしくお願いします。

GradleやMavenなどでJavaのプロジェクト構成を管理していて間接的に依存しているライブラリ同士のバージョン競合が起こることってありますよね?

これを「推移的な依存の競合」と呼ぶのですが、今回は単純な例で競合はどのようにして起こり、どう解決するのかを単純な例で示してみたいと思います。

想定するGradleのバージョンは2.1とします。

推移的な依存の競合状態の単純な例

      foo:example:lib-a-1.0.0-RELEASE
         └bar:example:lib-x-2.0.0-REALEASE
      foo:example:lib-b-1.0.0-RELEASE
         └bar:example:lib-x-1.9.0-RELEASE

上記ではlib-xの2.0.0と1.9.0が競合状態にありますがGradleでの推移的依存の解決方法はデフォルトで[Newest:最も新しいバージョンの依存関係を使用する]となっており、このままではlib-x-2.0.0-RELEASEが使用される状態です。

問題はlib-xの2.0.0には下位互換性が無く1.9.0の方を使いたいといった時に、Gradleではどのようにするのか?
ということですが、とりあえず以下の2つの方法を覚えておけば大体のケースに対応できると思います。

 

  • DependencyHandlerでどちらかの推移依存を除外

 

  • ResolutionStrategyで推移依存をどちらかに固定

 

実際に例にある推移的依存のうち古い方のバージョンを採用する形で競合を解決してみると以下のようになります。

1. DependencyHandlerでどちらかの推移依存を除外

      dependency {
         compile('foo:example:lib-a-1.0.0-RELEASE') {
            exclude 'bar:example:lib-x-2.0.0-RELEASE'      
         }
         compile('foo:example:lib-b-1.0.0-RELEASE')
      }

2. ResolutionStrategyで推移依存をどちらかに固定

      dependency {
         compile('foo:example:lib-a-1.0.0-RELEASE')
         compile('foo:example:lib-b-1.0.0-RELEASE')
      }

      configurations.all {
         resolutionStrategy {
            force 'foo:example:lib-x-1.9.0-RELEASE'
         }
      }

まとめ

この他にもResolutionStrategyでは競合が起こった場合はエラーにするような設定ができたりと、競合解決に関する設定がいろいろとあるので是非試してみて下さい。

参考資料:依存関係の管理

補足:なぜこんなに複雑な管理をしなければならないのか?

これはJavaにモジュールシステムと言えるものが無い事が原因だと考えられます。
Javaの実行時の依存ライブラリの関係はすべてフラットで、直接依存しているJarファイルから推移的に依存しているJarファイルまですべてをフラットに含めなければなりません。
もしこれが、直接依存しているJarファイルを指定しておくだけで、そこから推移する依存関係は直接依存しているJarファイルの
名前空間からしかアクセスしないというようなクラスローディングの仕組みがあれば、このような複雑な管理はなくなります。
しかしこれには、重複するJarファイルもすべて直接依存するJarファイルごとに保持しなければならず、アプリケーションのサイズ(warファイルなど)が肥大化してまうというデメリットもあり悩ましいところです。

変更を容易にするための技術

はじめまして。河上です。

アプリケーション開発における領域を分ける言葉としてアプリケーションドメインとソリューションドメインというものがあります。アプリケーションドメインはユーザの関心事を表現する領域であるのに対し、ソリューションドメインはそれらを実現するためのフレームワーク、ユーティリティ、ミドルウェア、その他ツールなど一般化可能な技術を表す領域(サブドメイン)となります。

ソリューションドメインは、既製のOSSフレームワークなどの抽象化されたインフラストラクチャの上でアプリケーションを記述している昨今では意識することも少ない領域になりつつある一方、まだまだフレームワークやミドルウェアとアプリケーションドメインの間を埋めるためのコードを書く必要があったり、さらには運用・保守フェーズなども含めたアプリケーションのライフサイクル全体を考えると知識として必要となる場面は当分なくならない領域といえるでしょう。

これは私の考えですが、「ユーザの関心事であるアプリケーションドメインの変更しやすさ」を最大現にするための要素としては以下のようなものがあり、どちらも重要なものです。

  • アプリケーションドメインをどのように表現するかに焦点を当てたDDDのような設計手法
  • 継続的インテグレーションのようなソリューションドメインの技術

もちろんこれ以外にはチームビルディングなどの人的要素も挙げられるでしょう。

このブログでは、ソリューションドメインの技術に焦点をあて、「アプリケーションドメインの変更のしやすさ」を目的としつつ、比較的私が得意とする以下の領域を中心として、私の興味と方向性に合う新しいものを混ぜながら、実際の現場における各種ツールやフレームワークの使いどころを書いていきたいと思います。

  • テスト自動化
  • Java周りのエコシステム全般
  • 継続的インテグレーション&デリバリー

よろしくお願いいたします。