Web APIの設計にUI Flowsはすごく便利だった

以前、全てがJSONになる - ✘╹◡╹✘ を読んでなるほどなーって具合にpocketに突っ込んでいたんだけど、最近Web API設計をする機会があったので、を参考にIF仕様をJSON Schemaで作成することにした。

IF仕様書というと

  • エンドポイント定義
  • リクエストデータ定義
  • レスポンスデータ定義

みたいな構成になるかと思うんだけど、そもそもエンドポイントをどうやって導くかみたいな話になって。取り敢えず画面遷移図みたいなんが欲しいねってことに。

ただ、僕らみたいなプログラマって、PhotoshopだったりExcelだったりで画面を定義するのはちょっと辛いじゃない。そこで、これも以前pocketに入れていた 画面遷移に疑問を感じたあなたにオススメするUI Flowsというツール | Reflection | UIデザイン会社Standard Incのブログ を参考にcacooでUI Flowsを簡単に記述して、その矢印に対してエンドポイントを付ける、みたいなやり方でやってみた。

結果、作業的に割りとスムーズにエンドポイントとレスポンスデータの定義が出来た。これには少し驚いてる。 ただ、まだちょっとJSON Schemaの書き方がわからなくて英語と格闘中なう。

情報収集と保存とSlackで共有を自動化する

社内Qiita:Teamに投稿したけど響かなすぎて承認欲求を満たすためにブログに書く。

ここから。

エンジニアを職業にしてると、情報収集がとても大切になってくるわけですが、その上企業に属していると集めた情報を社員間で共有することもとても大切になります。

1人で収集出来る情報には限界があります。
そのため、皆で集めて共有し、より早く自社コンテキストに沿いそうな情報をローカライズしていく必要がありますよね。

そこで僕が考えた最強の情報収集・共有の自動化方法を紹介します。
取り敢えず、以下のサービスを使用します。

情報収集の自動化

以下の2ツールを使用します。

Twitter

Web界隈で有名な人々をフォローしておくだけで、日々良質な情報が収集可能です。技術系情報の収集ツールとしてはノイズが多いですが、 彼らが日々どんなことを考えているのかを知ることが出来て個人的には手放せないサービスです。

HBFav

はてなブックマークTwitterのタイムラインのように表示出来るアプリです。面白いのは、 誰のアカウントでも使用可能である点です。

例えば僕のはてなidを使うと、僕がフォローしている人たちがブックマークした情報をHBFavのタイムラインに表示することが出来ます。
これを利用して、Web界隈で有名なエンジニアのidを使って 彼らが収集した良質な情報を自動で収集出来ます。

情報共有の自動化

新たに以下の2ツールを使用します。

  • IFTTT
  • Slack

HBFavは、はてなブックマークに登録する際にTwitterへ投稿するオプションを備えています。これを使うと、 自分がブックマークした記事にコメントを付けた上でTwitterへ投稿が可能になります。

これで、 自動的に得た情報を感想含めてTwitterへ共有が自出来るようになります。

Twitterへ共有するだけでは、全ての社員に僕のTwitterアカウントをフォローして貰う必要があって大変です。そのため、以下のサービスを使ってツイート内容をSlackへ流すことをします。

IFTTT

あるサービスのイベントをhookしてあるサービスの機能を呼び出すことが出来るサービスです。
これを使うと、

ことが可能になります。

ここまでを設定すると、

  • HBFav、Twitterで著名人の集めた情報を取得
  • それらからこれは役立ちそう!という情報をHBFav、あるいはTwitterでなんらかのハッシュタグ、コメントを付けて投稿
  • はてブTwitter、Slackに情報が投稿される

という感じになります。

f:id:hatajoe:20141113024838p:plain

情報保存の自動化

新たに以下のサービスを使用します。

  • Pocket

ここまでを設定すると情報収集、共有は自動化出来ますが、収集した情報はどんどん流れていってしまいます。これを保存するためにPocketというサービスを使用します。

Pocket

URLをとりあえずどんどん保存して後から検索して探せるサービスです。
僕は取り敢えず読んだ記事や後で読む系の記事をどんどん保存しています。

IFTTTを使うと

  • 例えば#pocketというハッシュタグを付けたツイート内にあるURLをPocketに保存

が可能になります。これで完成です。

  • HBFavかTwitterで#pocketタグを付けてツイート
  • ツイート内容がSlackに投稿される!
  • ツイート内のURLがPocketに保存される!

完成

 良質な情報
     | 自動で取得!
   HBFav
     | ツイートで共有!
  Twitter  
     | 自動で連携!
   IFTTT
     | 自動で情報共有・保存!
Slack/Pocket   

これで、HBFav/Twitterをチェックし、適当に#pocketタグを付けてツイートしとけば勝手にどんどん情報共有・保存が出来るようになります。

これでもう知らぬ間にどんどん情報共有が出来るわけです!これで俺らが知らないことなんて無くなんじゃね?やばくね? 皆さんも是非この自動化を体験してみてください。気持ちいいから。

ここまで。

結果、僕しかやってない。

全然最強じゃなかった... あと複数人でやると情報が被りまくってしまうな。 Slackの場合同じURLがあると二度目はページ情報が展開されないのでそれである程度わかるかな。 誰かやってくんないかな...

chef-containerを使ってみて

chef-containerで色々なコンテナを作成してみて思ったことなど。

fig良い

と言いつつ、いきなり脱線しちゃうんですが、ちょっと前に、boot2docker v1.3がリリースされ、ホストマシンからboot2docker上のDockerコンテナへディレクトリマウントが可能になりました。
また、同時にDockerコンテナを使用して開発環境を構築するための公式ユーティリティツールであるfigもv1.0がリリースされました。
これらを使用すると簡単にポコっと開発環境コンテナ群というものを立ち上げることが出来ます。(boot2docker+figの詳細は既にWebにあると思いますので割愛)

これまで開発環境にはVagrantを使用していたのですが、figを使うと簡単に全開発環境、いわゆる、ローカル環境、テスト環境みたいなものがそれぞれリポジトリをクローンして fig up とコマンド打つだけで再現出来るため、boot2docker+figに移行しました。

例えば、今開発中の案件だと以下のようなデーモン達が必要で。

これを以下のようなコンテナ群にして。

  • web (nginx + httpd + php + fluentd) → chef-containerでコンテナ作成後DockerHubへpush
  • web2 (nginx + nodejs) → chef-containerでコンテナ作成後DockerHubへpush
  • mysql → DockerHubから適当なやつ
  • memcached → DockerHubから適当なやつ
  • redis → DockerHubから適当なやつ
  • mongodb → DockerHubから適当なやつ

これらが fig up とすると立ち上がります。
さらにfigのlinkというオプションを利用すると、web1,2/etc/hosts に各バックエンドサーバーのIPアドレスと任意のホスト名を登録することが出来ます。
これにより、WAFによくあるバックエンド接続情報にその任意のホスト名を書いておけば、Dockerが動作するどの環境でも同じようにコードを変更することなく動作する環境が手に入るという感じです。素晴らしく使いやすいです。

chef-containerの話

で、chef-container。

Dockerコンテナの作成にはchef-containerを採用しました。
理由は、本番環境ではDockerコンテナを使わないからです。(ちょっと知見が足りな過ぎる気がしているのでまだ踏み切れないといった感じ。)
ただ、本番サーバーをプロビジョニングする必要は当然あるので、chef-containerを使っとくと取り敢えずレシピが残るという点で採用しました。

ただchef-containerは、コンテナ起動時に毎度プロビジョニングが実行されます。
これはまぁ仕方が無いけど正直微妙。コンテナスタンバイにまぁ数分かかっちゃう。(起動だけなら数秒なのに)

いやわかるんですけどね。
Dockeコンテナにinitデーモンが存在しない都合上、chefによってインストールされOS起動時に起動するよう設定されたデーモンを起動する術が無いから、chef-initが再度プロビジョニングすれば全部起動するよねという発想。だと思うんだけど。(cookbook_fileなどはコンテナ内にキャッシュされているものがコピーされる模様)

僕はこれを勘違いしていて、chef-containerで作ったコンテナはchef-initがプロビジョニングせずデーモンを次々起動してくれるものだと思っていて。
ただある日なんかコンテナ起動したのにブラウザでアクセスしても暫く繋がらない事案が発生してしまって。調べてみるとそういうことだった。(fig logs web1とかやると見れる)

まー割りとchefのレシピはある日突然動かなくなったりするので(特にyumリポジトリのURLが変わったりだとか、突然postfixが必要になったりだとか...)、毎度プロビジョニングも悪くは無いのかもしれないけれども。

そんなわけでDockerコンテナは開発から本番まで通して使用し、Dockerfileで構築するのがベストプラクティスな気がしたわけです。(公式まんまだけども)

そうなるとchefのレシピからDockerfileを生成出来ると嬉しいかもしれない。
Ansibleからなら比較的やりやすそうな印象あるがchefからは色々大変そうだな。。

第六回ドメイン駆動設計読書会@大阪に参加した

ひとまずの最終回。

今回で

と役者が出揃った。 中でも、個人的に印象深かった実践的モデラについて少し考えをまとめたい。

実践的モデラに対する僕の理解は、ドメインエキスパートと共にユビキタス言語を導き、イテレーティブなモデル設計を実施し、かつプログラミングを行う人を指している。

これは、僕だ。

僕は普段仕事でWebアプリケーション開発に携わってるけど、ドメインエキスパート(企画者、ディレクター)とモデル(仕様)を作成し共通認識(ユビキタス言語)を維持しながらコーディングしている。 モデル(仕様)が変われば共通認識(ユビキタス言語)が変わりコードが変化する。普段の風景。

ただし、モデル(仕様)も共通認識(ユビキタス言語)もなーんにも文書化されずガシガシ作るスタイルなのは問題。まぁこれはひとまず置いておいて。

全てのWebの現場がそんな風な作り方をしているわけじゃないと思うけど、割りとこういう現場は多いのでは。 自社サービスを開発していてドメインエキスパートが社内に居るとかだと、モデル駆動設計に対する敷居は無いに等しい。 (その難易度は度外視したとして)

逆にドメインエキスパートが社外の人間、特にお客さんとかになると敷居がグッと上がる気がする。大体、対社外的なフロントに立つ人間は、自分自身プログラミングしないことが多い。 伝言ゲームみたいなもんで、情報は劣化する。 対社内でさえも劣化するから、これは相当難しいイメージ。 これはシステム化するか制度化して無理やりにでも共通認識を持つみたいな仕組みが無いとという発想になる。 そういった意味で、ドメインエキスパート(お客さん)がDSLを使ってシステムを構築出来るソフトウェアというジェネレーティブなアプローチが注目される理由もなんとなくわかる。 ただし、そこにはどうしても汎用性の壁があると思うし、実践的モデラを見出すことが出来る現場ならそういう作り方をした方が最終的には幸せになれる気がしないでもない。

6回を終えて

ドメイン駆動設計を学び始める前は、これを学べばイケメンになれると思っていた。だけどもうイケメンだったし、開発手法として何か新しいということは無いんだなという感想(そもそも初版2003年だし)。

ただ学んでみて本当に良かったと思える。 なんだかモヤっとしたところがクリアになった。色々な概念に名前がついたこと、それらがどのように作用するか定義されたこと。 そして最大の功績は今よりまだ開発プロセスが良く出来ることが明確に見えたこと。

副作用として、これまで疑問視しなかった色々なことに対する考えをクリアにしようという発想も出てきた。

以前、まだドメイン駆動設計に対する理解の浅い段階で、取り敢えず勢いでドメイン駆動設計ワークショップというものを社内で開催したけど、個人的には不発に終わっていてまだモヤモヤしている。 今ならもう少しマシなものが出来そう。その時にはもうドメイン駆動設計という言葉は使わず、今やってることをもう少し良くしようって感じになると思う。

なんだか達観者のようなエントリになっちゃってアレなんですが実際課題は山積み。今後は以下をどうするか考えたい。

PHPメンターズ道場生になりました

http://phpmentors.jp/

@itemanさんにお誘い頂き、この度道場生として勉強させて頂けることになりました。こえぇ。
DDD読書会@大阪は、今後も形を少し変えて継続していく予定です。

第五回ドメイン駆動設計読書会@大阪に参加した

5回目。 固定メンバーでの勉強回ということもあって流石に馴染んだ感じある。

今回はモデル駆動設計へと続く大事な章。 勇んで独断と偏見による感想文で他を圧倒するしかと思ったけどレポートが素晴らしすぎて鼻血出た。ここに今回の全てがあります。@sugimoto_keiさん、いつこれだけのメモを...?

個人的なハイライトは以下だった。

具象から抽象へ

僕達みたいなソフトウェアエンジニアは、顧客の要求を解決するため、日々その要求に対して向き合っている。これは、場をエンタテインメントに移した場合でもそんなに変わらなくて、要するにユーザーに価値を提供すること、つまりソリューションの提供を目的としているはず。

このソリューションの提供までには、様々な人が多種多様なコンテキストを持ってゴタゴタ進んでいく。DDD本を読んでいて、ここでまず重要になるのが「要求」と「ユビキタス言語」だということに気がついてきた。

最も重要なことは「要求」。理由は、これがゴールとなるから。 要求をなるべく正確に得るためには、「分析」することが必要になる。 分析とは、ドメインエキスパート(ユーザー)からドメインの知識(要求)を抽出することだと思う。 ただ気をつける必要があるのが、ドメインエキスパートも我々も、この時点で実は正しい要求を持っていない場合が多いんじゃないかと思う点。つまり、この時点で詳細には分析出来ないはず。普通は。

じゃどうするかというと、まずはざっくり。なんかドメインエキスパートの人が言ってるから取り敢えずそれを実装しちゃう。ここが本当のスタート地点なんだと思う。 とにかく動かす。実はここに全力を傾けるべきだったんじゃないか?

僕はこれまで結構分析してた。 いるかどうかもわからない機能を考慮したり。 思い込みの塊に時間を費やしたり。 初めから色々考慮しとくと後が楽だろう?!みたいな。

まぁこれが悪いとかは無い。ただもっといい方法があったという話。

この動くもの。これは具象。誰が見てもそう。 まずはこの具象を持ってもう一度「要求」について話合うことが必要だと思う。ここで本格的に登場するのが「ユビキタス言語」じゃないかと。そしてこの「要求」を「ユビキタス言語」で表したものを「モデル」と呼び、この行為それを「分析」と呼ぶ。 この過程でモデルは何れかの「ドメイン」に紐づいていく。

これは「モデル駆動設計」と呼べそうだ。 この過程は、様々なものが具象から抽象へと昇華している。すごく自然な形だと思う。 5回の読書会で得られた理解は今ここ。

明日から使える!的なものとしては

「とにかくいいから動くもんを最速で作れ。話はそれからだ。」

これを補う技術領域がCI、TDD、リファクタリングなんだろうなーという感じがしている。

第四回ドメイン駆動設計読書会@大阪に参加した

4回目。 隔週1回だから初めて2ヶ月が経過したわけで。 今回はレポート担当。 レポートは読書会中で議論した内容をメモしたものをチョチョッとまとめる感じにして、ブログには今回得ることのできた個人的な知見みたいなものを書こうと思う。

今回のキーワードは

の2つ。

深いモデル

読書会のいいところだと思うんだけど、一人で読んでるとそんなに深く考えない軽く読み流しちゃうような単語も「これって...?」みたいな話になりますね。 この「深いモデル」という言葉、僕は引っかからなかったやつ。

でこれって一体どんなモデルなんだ?というところで、以下のような意見が出た。

  • 解決領域を多く持つようなもんではないよね。
  • 表層的なものではなく本質的なもの...本質的とは?
  • よく考えぬかれたモデル!...ほう?

みたいなね。

ここで僕が思ったのは、「深い」というのは「色々なコンテキストを持った」ということではないかということだった。 どういうことかをあるモデルAとBで簡単に説明するとだな。 AとBは、実はまったく同じものを解決できるモデル。 しかし、そこに至るまでの道程は全然違っていて。 Aは一本道で出来上がったモデル。Bは様々な理由から最終的にそうなったモデル。

最終的にアプリケーションにとってみたらどちらでも同じなんだけど、作る側に取っては同じじゃないと思う。 AよりBの方が意図が明確だろうし、次に進むべき道も自ずと示されそうな感じ。 なんとなく積み重ねた偶然と、正しいかはわからないけど意図して積み重ねた必然。

アクションには理由が無いと積み重ねられない。 これってキャリアプランとかビジョンとか施策とか会社経営みたいなものにも通じるところがある。

  • なぜ僕はドメイン駆動設計を勉強しているのか
  • なぜ会社はこの製品を作っているのか
  • なぜチームはこの施策を打つのか
  • なぜこのモデルにはこの機能があるのか
  • なぜこのクラスにはこのメソッドがあるのか

深いモデルとは、色々なコンテキストが積み重なって出来ているモデルだというのが今の僕の見解で、それを作る方法はちゃんとその都度「なぜ」を解決することだと思っている。そしてそれを作ることは出来そうだよね。要は考えろってことなんだから多分。

ユビキタス言語

僕がまだDDDってなんだろみたいな時に、ちょっとググってこの「ユビキタス言語」という単語を見つけて一気に引いていったやつ。なんか難しそうな言葉だし学問の匂いがする。苦手だ。

本から言葉を借りて一言で表すと「モデルのセマンティクスが反映されている共通語」となるかな。要するにどんなものなの?という話で、以下のような意見が出た。

  • ユビキタス言語には手続きは出てこない
  • 故に順序は無い
  • 用語集じゃ!

こんな感じ。 (実はここら辺りで盛り上がった話があったのだけどこれは端折る。「DDDって言葉にこだわる感じの〜」の下りのやつね笑)

唐突だけれども、僕はユビキタス言語はAPIだと思った。APIリファレンスみたいな。 モデルはパッケージみたいな感覚で、ユビキタス言語はそのパッケージを表すAPI。 誰もが共通認識を持てる。同じ言葉で話が出来る。 ユビキタス言語の変更はモデルの変更を意味するみたいなところも妙に納得の行く感じで。 こう考えると、ユビキタス言語の導き方も割りとエンジニアリングに近い感覚で行えるような。

で「これや!これなんや!」くらい僕は興奮していて。

けどそれを巧妙に隠した上でクールに「なんかユビキタス言語ってAPIみたいだなぁって」って決めた俺ナイスユビキタスイケメン。 ただあんま刺さらんかった。

なんやかんやで@itemanさんが仰っていた「ユビキタス言語は結果としてモデルから導き出される」という言葉が印象的でした。 ともすれば、例えばIDEなどでクラスやメソッドのコメントをユビキタス言語として抽出するみたいなことも出来るだろうし、逆にそこまでやらないとモデルとユビキタス言語のメンテナンスは大変だろーみたいな。確かに。

積み重ねること

今回の読書会で、正直正しいかどうかわからんけれど自分の知識が積み重なってることを実感した。 僕にとってはこの感覚が結構大切で、なんというか一旦理解する感じ。 ロッククライミングで言うと(やったことないけど)、なんかあの釘みたいなやつを手頃なところへガツンと打つじゃないすか。 そんな感じで、一旦中継地点で間違ってるかもしらんけど次を積み重ねられる状態にする。 この道程が僕のコンテキストで、一旦理解出来ることにこそ価値がある。 このコンテキストの積み重ねが今の僕を作ってきたし、それは間違いじゃないと思っている。

第三回ドメイン駆動設計読書会@大阪に参加した

第三回ドメイン駆動設計読書会@大阪に参加した

隔週開催のこの勉強会も今日で三度目。 どうでもいいけど勉強会初心者の僕は、集まって始まるまでの間の牽制した感じにまだ慣れない。 もっとこうフランクにニュートラルにその場に馴染むよう心掛けたい。

実は今日から第1章

3回目にして第1章突入。 第1章はエヴァンスの実例を持って話が進んで行く。 重要なこと、色々な話をしたけれどあんまり覚えていないので手元のメモを元にまとめると以下の三点になると思う。

  • ドメインを小さくキープ
  • ブレスト
  • フィードバック

ドメインを小さくキープ

往々にして、ソフトウェア開発の現場では風呂敷を広げがちであると。 例えば、「今は必要ないんだけど、きっとこれから必要になりそうだね」とか、ある解決領域の話をするためにその周辺知識を補完する必要が出てきて、そこら辺がふくらんで結局何を解決しないといけないのか、チーム内や顧客間で共通認識が薄れてくるみたいな。

そこに対して、もっと解決領域(ドメイン)を限定し、ソフトウェアの目的をしっかり定義することが必要なんじゃないかという話。

今解決しないといけないことを絞る。余分なものは捨てる

ブレスト

ドメインを小さくキープしたい。余分なものは省きたい。 そんなものを導き出すためには話し合うしかない。ここで印象的だった話として、お客さんやユーザーの興味の対象って、 画面みたいな目に見える部分や実際に触れられる部分であってドメインではない。ただ開発者はドメインに中力したい。そんな感じでどうやって話合っていくのか?というところ。

これについては双方が歩み寄って行くしかないという至極まっとうな意見にまとまった。 お互いの目的をお互いが理解することが双方に取っていい結果に結びつくという話。言葉で言うと簡単だけれど、実際にやろうとすると難しいよなーと思った。というかソフトウェア開発で一番難しいのってプログラミングとかじゃなくてこういった共通認識のすり合わせだなーと思う。

面白かったのが、ブレストは拳で語り合う必要がある、という意見。(笑) 要は、それくらいの覚悟を持ってして挑んで、最終的には河原で2人仰向けに倒れて

「お前、なかなかやるやん?」

みたいにお互いが認め合えればええやん? DDD、肉体言語やん? by @kazuhito_m

フィードバック

最も重要な部分であると思う。 本にも書いてあるけど、「完全なドメインは存在しない。」と。何度もブレストを繰り返し、実装し、ドメインを進化させていく。初めはミニマムスタート。必要なときに必要な機能を議論してドメインに反映して実装する。

(なんだかここまで書いて、どれも基本的な内容じゃんという感じになってしまったな...)

悩ましいところ

実際の開発ではブレストとフィードバック、おざなりになりがちだと思う。 個人的にそうなってしまう理由としては以下があるように思う。

  • そもそも何を実現したいかぼんやりしている

結局、自分たちがどんなものを実現しようとしているのか十分に理解出来ていことあるなと。 ブレストもなんか曖昧なんだけど取り敢えずわかったような気になって先に進んじゃうとか、そんなんだからドメインを洗練させることが難しいし、なんとなくボヤっとしたままリリース。結局何を目的としているかがボヤっとしているからフィードバックと言っても難しくなる。 しかもそれができない理由をなんか「時間が無いから」みたいな話で丸め込んで次に向かうみたいな流れ。

よくよく考えてみると、時間が無いとか嘘で、実際にプログラミングとかしてる時間ってものすごく短時間で、それ以外の仕様確認やら手戻りやら要件変更やらtwitter閲覧によって引き起こされる時間が圧倒的だなーと。特にtwitter

ただ悩ましいのが、企画者みたいな人がこれをやります!みたいな時に、「なぜです?それはどういう意図があるんです?」みたいなのも嫌なヤツだなーとか。聞き方ってあると思うしね。 でも 曖昧さはドメインを形成する上で非常にやっかいな代物という印象なので、そこのせめぎ合いみたいなところは 拳で語り合うしかないかなーと。それなりの覚悟を持って開発に向かう必要はあるかな。結局は良い物を提供したいという共通認識はブレないわけだし、その過程は少々ゴタゴタしても良い結果を得ることで全てチャラちゃうかなと。

これDDD関係ない気がしてきているけど、とても実になる(まだなってないけど)話だなーと思っている。