読者です 読者をやめる 読者になる 読者になる

CotEditor(v2.2.0以降)のCLIツール用homebrew formula書いた

よく使っているCotEditorがMacAppStoreでの配布を始めたということでインストールしたら、それまで使えていたCLIツールが利用出来なくなり、別途GitHubからCloneしてインストールしてくれとの事だったので、homebrewで管理できるようにした。

github.com

使い方

tapしてinstallする。以上。

brew tap jsoizo/homebrew-cot
brew install cot

課題

  • CLIツールのページThe new cot command-line tool for CotEditor 2.2.0 と記してあったのでDependencyにはv2.2.0以上と書いてしまったものの、古いバージョン(v2.1.6)でも動いたので要確認。もしかしてバージョンの2.2.0が係ってるのが CotEditorじゃなくて command-line toolの方なのかも…
  • リリースタグが打たれたらそっちを参照するように修正する
    • その場合masterを参照する版を --HEAD オプションでインストールできるようにする

2015-08-28

朝イチからボウリング疲れた。2ゲームやってハイスコア131なのでまぁいい感じ。

DDD本読書メモ

2章 ドメインサブドメイン、境界づけられたコンテキスト

2.11 境界づけられたコンテキストの意味を知る

本節の最初には以下のように記されている

境界づけられたコンテキストは明示的な境界であり、ドメインモデルがどこに属するのかを表すものである。ドメインモデルはユビキタス言語をソフトウェアモデルとして表したものだ。

いきなり境界づけられたとか言われてもなんのこっっちゃよーわからん。ってなったなので、原典たる英語版での用語を漁ったら Bounded Context と書いてあった。Boundedって数学的な用語で有界のとかそういう意味らしいのだが、そういうつもりでこの言葉をBoundedとしたんじゃないかなぁと。"境界づけられた"よりも"有界の"のほうが腹落ちする。あるいは"束縛された"でもいいかもしれない。

要は、ユビキタス言語が示すコト(=ドメインモデル)がどの業務において利用されるかという言葉の定義が効く範囲(=コンテキスト)を示しているのだと思う。例えばクリエイティブという言葉は一般的には創造性みたいな形容詞であるのだが、広告業界では広告表現に利用されるオブジェクトのことをクリエイティブと呼ぶ。広告配信のプロダクトを作っていたとして、クリエイティブは広告配信業務コンテキスト内のユビキタス言語であるし、広告配信業務コンテキストが境界づけられたコンテキストとなる。

境界づけられたコンテキストの"境界"とはなにか? 個人的には問題空間上のビジネス課題(プロダクトの提供する価値)の範囲だと理解した。本書には

システムやアプリケーション、あるいは業務サービスなどを区切るために使うことも多い

と書かれているが、混乱を避けるという意味でシステム内部での用語世界の範囲決め使わないほうがいいと思った。本書に手もコンテキストのサイズを誤るパターンとして、フレームワークやシステムアーキテクチャの影響により言語的な境界から技術的な境界を考えてしまう事があると示しているしね。

境界づけられたコンテキストによりユビキタス言語やドメインモデルをカプセル化することができる。のが最大のメリット。仕事でよくモデル設計をしている時に"XXはα界の用言葉だからβ界に滲みでたらアカンよね"みたいな話を良くするのだが、その界が境界づけられたコンテキストであり、その中のドメインモデル同士がコンテキストを跨いで紐づくと美しく設計されている状態になるのであろう。

じゃあどうやって境界づけられたコンテキストやドメインモデルを設計するのという話は3章でコンテキストマップとして触れるとあるので待つ。

システム実装上は com.jsoizo.ddd のような名前空間が境界づけられたコンテキストになるし、そこからさらに com.jsoizo.ddd.controllerscom.jsoizo.ddd.models みたいな名前空間になっても基本的に同じコンテキスト内で同じドメインモデルを操作する人間が開発にアサインされた方がいい。

今日のトレーニング

メニュー

またさぼった。明日は休日なのでやろう

計測

64.25kg

会社の体重計に服を着た状態で乗ると62~63kg台なのに、家の体重計に服をほとんど着ない状態で乗ったら64kg台になる。家で測るときはだいたい夕食を食べた後だから単に重いのかもしれないが、誤差は結構あるなぁ。

2015-08-27

日記

Product ManagerのSlack眺めてる。有名な会社のCEOやらCTOやら居てビビる。バックグラウンドに技術がありつつプロダクトの価値とか組織とかを語れて、スーパーマンに見える。そういう人になりたい。あと3~5年くらい後かな? 眺めてるだけでも学ぶこと多い。一方で、発言しようと思って内容整理していたら会話が流れていったりって事があって、自分のアウトプットのスピード感のなさに辟易した。こういうブログとかを毎日書くことでスキル向上したらいいな。

DDD本読書メモ

2章 ドメインサブドメイン、境界づけられたコンテキスト

実世界における2.10 ドメインサブドメイン

昨日の続き.

ドメインは問題空間と解決空間を持つ。本には以下のように書かれている。

  • 問題空間 : ビジネス戦略上の課題を浮き彫りにする
  • 解決空間 : ソフトウェアの実装課題を解決する

問題空間=要求定義, 解決空間=要件定義 的な理解をした。問題空間は過去のドメインやいくつかのサブドメインからプロダクトのコアドメインをつくる場所。つまり、プロダクト自身の価値は何?それがユーザーのどんな問題を解決するってことを定義する(※解決しないことを定めるのも大事ね)。ここを履き違えると以降のプロセスがグズり、有名な↓の画像みたいな状況に陥る。

本書には問題空間の理解にアセスメントビューが使えると書いてあったが、その説明がなかったのでさっぱり。

f:id:jsoizo:20150827230850g:plain

解決空間においてはプロダクトを構成するシステムを定義する、ソフトウェアモデルの集合。ソフトウェアモデル同士は境界づけられたコンテキストによって区切られる。問題空間にて定義したドメインをシステムとしてどう表現するかがポイントかな。ドメインがそのまま境界づけられたコンテキストになればいいが、実体として同じドメイン複数のソフトウェアが利用することがほとんどだ。

務めている会社ではドメインモデルをjar化して複数Scalaアプリケーションで使いまわすということをしている。残念なことにリポジトリ層とモデルがべったりくっついた状態(ライトDDD?)なので改善の余地有りだが、リポジトリがほぼRDBMSと決まっているのでまぁ無理に分けなくても良かったのかもしれないとも思う。

めも

Eric EvansのDDD本にある戦術的パターンがところどころ出てくるので参照してみよう。

今日のトレーニング

メニュー

仕事忙しくてさぼった。明日は行きたいが飲み会あるのでどうしようか。

計測

62.85kg

2015-08-26

日記

これから毎日、ささやかでもいいから毎日書くことを心がける。

DDD本を読み始めたが、なかなか理解しきった感じがしない。マメにアウトプットしていたら腹落ちするのだろうか?具体的に身近なところで考えてみるというワークをしたほうがいいのかもしれない。

実践DDD本読書メモ

2章 ドメインサブドメイン、境界づけられたコンテキスト

2.8 全体像

ドメインとは、事業と取り巻く世界のこと。事業ドメイン全体をカバーするモデルをつくるのではなく、ドメイン複数サブドメインを組み合わせる。

サブドメインには以下3種。具体的な例で整理したいところだがサクッと思い浮かばない

実世界における2.10 ドメインサブドメイン

ドメインは問題空間と解決空間を持つ。本には以下のように書かれている。よくわからなかったので明日また読んで書き起こしていく。

  • 問題空間 : ビジネス戦略上の課題を浮き彫りにする
  • 解決空間 : ソフトウェアの実装課題を解決する

今日のトレーニング

メニュー

  • 腹筋 10回3セット
  • チェストプレス 17.5kg10回3セット
  • ランニング 9.3km/h 20min 3km 250kcal

計測

  • 体重 : 63.85kg

scala学習10日目だが…

scala & liftをモリモリ勉強しているのだが、全く進まないやばい。 scalaの文法もろもろはこれ読んで実行してみてなんとなくわかったんだけど、結局コード書かないと覚えないんで、liftでWeb App作ってみようとしているんだけど、Hello Worldしたところで止まってるやばい。先に進みたいけどsbt分かんないから右も左も分からなくてやばい。焦ってさらにやばい。

FlashPlayerのバージョンを取得するjs

書いた。

コード

Flash Playerがインストールされていたらバージョン(メジャーバージョン)を返して、インストールされていなかったら0を返す。

IEだけバージョンの取得方法が違って、navigator.mimetypesが使えないので、ActiveXオブジェクトの生成を使う。IE以外、あるいはFlash PlayerのインストールされていないIEだとActive Xオブジェクトの生成でエラー吐くのでtry catchしている。あと、IE以外用の判定処理を先に書こうと思ったが、世にあるブラウザの約60%はIEなので、無駄な処理をさせないようにIE向けの判定を先に書いている。モバイルとか考えたら逆のほうがいいかもしれない。

gist9700142

デモ

JSFiddleでの表現の都合上、上のコードでalertしているところを、DOM挿入でHTMLに突っ込んでいる。Flash Playerのバージョンを取ってくる関数自体は変わらず。

Flash Playerを無効にすればテストできる。chromeならchrome://pluginsを開いて設定可。

以上。

アウェー徳島戦の行き方 (東京発)

Jリーグ グランパス

徳島ヴォルティス、J1昇格おめでとうございます。

ユース出身の津田、優勝時にバックアッパーとして支えてくれたちよたんのゴールによる見事な勝利と、グランパスサポーターの僕にとっても嬉しい試合だった。シュート4本で2-0なんてスコアを見ると、来シーズン以降のアウェー徳島戦は、かつて小林伸二監督に率いられた山形@NDスタの時ように、面倒な試合になりそう。

さて、そんな徳島遠征に向けて、東京23区に住む僕がポカスタ開催のナイトゲームを観に行く仮定で、パラパラと調べた結果を簡単にまとめておく。

要約すると、最もコスパがいいのは高速バスの直行便か、スカイマークの神戸便をと高速バスを併用する方法がベストだが、他にも幾つか手段があって、だいたい片道\8,000~\20,000くらいで行ける模様。

続きを読む