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

Galapagos Engineering Blog

株式会社ガラパゴス エンジニアチームによるブログです。

Phoenix Framework v1.3のおはなし

ご機嫌よう、ガラパゴスのおとめです。

今日は、先日RC版がリリースされたPhoenix Framework v1.3を見ていこうと思います。

大きく変わったところ

v1.3の変更点を眺めていて、次の点が興味深いと思いました。

  • web/ディレクトリが引っ越しました。
  • umbrellaがサポートされました。
  • contextがサポートされました。
  • action_fallbackが追加されました。

さて、これらの変更は、個々に見ていくよりも、まずは全体を見て概念をつかんだほうがいいのかな、と思いますので、背景から見てみましょう。

境界について考える

これまでのPhoenix Frameworkには、おおよそ以下のような問題があった、と考えられていたようです。

  • web/の下に何でもかんでも詰め込まれていて全体で一つのアプリケーションになっていて、ぜんぜん関係なくても全てに依存している。
  • modelに色々なロジックが詰め込まれていて見通しが悪いし、それでもロジックはmodelに集中して、分かりにくくなりがち。

でも、誰もが必要なことだけに集中したいですね。境界を、ここでの境界というのは境界線上のことではなく責任を明確にするとうことですが、はっきりさせたい。そのためにはどうしたらいいのかしらん?

ここに二つの鍵があります。コンテキスト境界と、アンブレラプロジェクトです。

コンテキスト境界

コンテキスト境界はドメイン駆動開発の概念ですが、軽くおさらいしておきましょう。

あるmodelがあったとして、そのmodelはあちこちで使われていて、それぞれに必要な色々なメソッドがあるとします。ことによると、あちらとこちらでは同じ言葉で違う意味、みたいな場合まであったりして、仕方がないので修飾語をくっつけてsome_method_of_a_contextとかsome_method_of_other_contextとか、みたいな感じになったりします。もちろんこういうのは、くんずほぐれつ、コード上のあちこちに散らばっていて、なんかもう全体として巨大な一つのmodelになっていて、この世に、少なくともオフィスには、呪いを生み出しますね。

無理。

ですので、共通な部分と、ある特定の部分と、別の特定の部分と、という風に分けましょう。

でも、どうやって? 概念としては分かりますが、例えばある特定の言語で書かれたコードでは?

Phoenix Framework v1.3では、複雑になる一方のmodelに対してコンテキストが導入されました。例えばこんな風になります。

$ mix phx.gen.json Followers User users username:string

ディレクトリ構造はこのようになります。

+- lib
   +- my_app
      +- followers
      +- users
      +- web

この例はマイクロブログ風にユーザーにはフォロワーがいて、という世界観を表現しています。フォローを承認してみましょう。モデルの.コンテキストの.メソッド、という呼び出しになります。

user
|> Followers.unaccepted
|> Followers.accept

もちろんこの単純な例では、そんなのUsersにあっても全然構わないように見えますが、それでも、ある種の責任を綺麗に分離できましたね。

アンブレラプロジェクト

Elixirにはアンブレラプロジェクトという、プロジェクトが大きくなった時に、複数の子プロジェクトに分割して管理するための機能があります。

そして、Phoenix Framework v1.3は、このアンブレラプロジェクトに対応しました。

まず、mix newで親プロジェクトを作ります。この時に--umbrellaオプションを指定します。

$ mix new my_app --umbrella

するとappsconfigだけのプロジェクトができます。

my_app
+- apps
+- config
|  +- config.exs
+- mix.exs

例えばガラパゴスは主にスマートフォンアプリを開発していますが、スマートフォンアプリはAPI(アプリ向け)とWEB(管理画面)がセットになっている場合がほとんどです。

それでは、子プロジェクトを作ってみましょう。

$ cd my_app/apps
$ mix phx.new.ecto my_app_core # 共通のコア機能
$ mix phx.new.web my_app_web # 管理画面
$ mix phx.new.web my_app_api # API

するとこのように、appsの下にそれぞれ独立したプロジェクトができました。御機嫌よう世界。

my_app
+- apps
|  +- my_app_api
|  |  +- assets
|  |  +- config
|  |  +- lib
|  |  +- priv
|  |  +- test
|  |  +- mix.exs
|  +- my_app_core
|  |  +- config
|  |  +- lib
|  |  +- priv
|  |  +- test
|  |  +- mix.exs
|  +- my_app_web
|     +- (ry
+- config
+- mix.exs

例えばAPIに管理画面関連の依存関係があっても全く無駄ですし、逆もそうですし、アプリケーションがロードされた時に必要ない依存関係が色々なオーバーヘッドになっているのとかも。

でも、こうしてアンブレラプロジェクトにすることで、スッキリしました。子プロジェクトという形で、責任の範囲も明確になりました。

さいごに

コードを書いていると、これはここにあっていいのかしら? みたいなことを感じることも多々ありますが、境界を綺麗に分割できると嬉しいですね。

さて、ガラパゴスでは人類の進化に貢献したいエンジニアを大絶賛超募集しています。皆様の応募をお待ちしています。

www.glpgs.com

では、御機嫌よう。

この記事は業務の一環として業務時間を使って書きました

テスト分析とテスト設計勉強会に参加しました!(後編)

こんにちは!テストチームとのの(TW:@tono2587)です。
先日2017/02/03、「テスト分析とテスト設計勉強会」に参加してきました!
内容もりだくさんに思えたので、前編と後編で参加レポートをまとめました。
(前編のシェアありがとうございます!)

gtech.hatenablog.com

こちらは後編として、もう少しお付き合いください。

f:id:glpgsinc:20170214211836p:plain …。。。(テスト設計)

■勉強会の内容(後編)

□湯本さん:ゆもつよメソッドにおけるテスト分析とテスト設計
□河野さん:テスコン優勝事例におけるテスト分析・設計の解説
□まりまりさん:大学祭の模擬店でデザインの力を感じた話

□湯本さん:ゆもつよメソッドにおけるテスト分析とテスト設計

分析とは?
対象をよく理解すること。
知りたいことに沿って対象をわけて、再整理する

設計とは?
・仕様をもとにして対象物の骨組みを決めること
・構築するにあたっての課題を解決すること
・発明(創意工夫)すること

例:家の設計
①家の仕様:予算、2階にトイレ、など。
②家の設計:①を元にして設計図ができる。→家の骨組みができる。
*ここにトイレを配置する場合、どんな配線(水道の)にするか?予算内でおさまるか?(課題解決)
③家の実装:大工さんが建てる

分析と設計を分けるのはなぜか?

◇全体像の理解が容易になるから。
「これをテストしてください」と言われたとする。
→なにをテストすればよいのか???となる。*ここで分析が必要になってくる
→分析をすることで、必要なことがわかる(要件を理解する)
→それをどうすれば実現できるか考える…つまり、設計

◇分析と設計は求められるスキルがちがうから。
分析スキル:ドメイン知識が必要。
設計スキル:その問題についてはこういうカバーのしかたがあります、などの「引き出し」
カバー方法をいろいろ知ってる必要がある。

◇分析と設計の成果物も分けたほうがよい
仕様変更による修正から、テストのやり直しとかがやりやすいため。

「分析しなくていいならやらなくていい。それは難しいからやる。やったほうが効率がよい。」

□河野さん:テスコン優勝事例におけるテスト分析・設計の解説

◇このプレゼン自体も分析/設計をしました。それの例も出しながら解説
流れ:分析→設計→実装
何の集まりなのか、聴講者の人数は、会場の大きさは?→それに対する答え(分析)
分析結果をもとに、話の内容、その順番を決める(設計)

◇分析と設計とは?
・考えて、何かしらの成果物を出す行為
・知的変換の大きさが分析と設計では違う(分析は材料あつめ、設計は料理くらい違う)
・分析は世界の整理、設計は課題解決

◇わかりやすい例とわかりにくい例で、分析と設計を考える
・わかりやすい例:家を建てるとき
・わかりにくい例:テスコン事例

お家を建てるとき
分析:住む人の周りの世界を整理する(営業の仕事)
・両親と同居するか?自宅で仕事をするか?休日は何をするか?生活の導線は?和風/洋風?
・制約(土地の場所、予算、建築基準法
聞き出して整理する

設計:お家の図面を書く(設計士の仕事)
・分析結果を満たすようなお家の構造を設計する

テスコンの場合
・テスト要求分析
・テストアーキテクチャ設計
・テスト詳細設計

まとめ
分析するために材料を用意する。その集めた材料で設計していく!

□まりまりさん:大学祭の模擬店でデザインの力を感じた話

模擬店でりんごあめと芋タルトを売りました
1日目:りんごあめ→2本で120円、芋タルト→大きいお皿に小さい芋タルトが1個で120円…
お客さんの声(え、りんごあめ2個なの?!い、芋タルトちっさい…)
*売れない…

対策(このあたりが「分析」だったのでは?)
☆金額を下げる
☆りんごあめ2個問題
→「2個」だとちゃんと言おう!
☆芋タルト(ぼったくり)問題
・この大きなお皿に何個なら満足するのか??
→在庫も捌けたいので、まとめ買いしてもらおう!

ーー看板のテーマを担当者に伝え、看板を描いてもらったーー

結果

大学祭の模擬店でデザインの力を感じた話 // Speaker Deck

資料の25〜
すごくわかりやすい看板になった!
→売上がのびた!!!!!

■参加後の気持ち

◇テスト分析、テスト設計ってなんだろう
 分析は、テスト設計するための材料あつめ。これからテストする対象について知る、整理すること
 設計は、それを実現するための方法を考えて形にすること
◇今まで項目書作成に時間がかかっていたのはなぜか?
 材料が十分に集まっていなかった。何をテストするかなど、整理できていなかった。
 なので抜け漏れが出て、その修正にまた時間がかかっていた。
 設計のスキルがそもそも足りない。…引き出しがまだ少ない。
◇わたしは何をすればいいのか
 やり方を変える:まず分析をする。
 知識を増やす:引き出しが必要なことがわかったので、仕様に対するカバー方法を知っていこう。

■感想/前後編のまとめ

 前編でもやもやしていた「分析」と「設計」がわかってきました。お家の例はすごくわかりやすかったです。
わたしは最近設計士の仕事が増えてきていたが、やっていることはいろいろすっ飛ばして大工に近かった、ということがわかりました。
現状が理解できてきたので、何をすればいいかもだんだんわかってきました。(上記)
まりまりさんがデザインの力で問題解決したように、この分析→設計の流れをおさえておけばテストという形でなくても使えそうな考え方だと思いました。
いろんな学びがあったので、仕事がよくできそうです!!!
よいアプリへの力になれますように!応援よろしくお願いします〜〜!
やる気のアップしたとののでした。ではまた

WORKS | 株式会社ガラパゴス iPhone/iPad/Androidのスマートフォンアプリ開発

ブログの極意を教わったのでかいてみたよ

こんにちは!テストチームとのの(TW:@tonono2587)です。 先日2017/01/30,バンさん( GitHub:@vanhuyz )と一緒に勉強会に参加してきました! このエンジニアブログも試行錯誤しているところなので、参考になりました。感想などまとめましたので、ぜひ読んでください。

f:id:glpgsinc:20170206212440p:plain ブログかくのも真剣(必死)ですよ…


参加した勉強会はこちら↓

「サポーターズ勉強会 エンジニアのためのブログ講座」
【学生&若手エンジニア向け勉強会】エンジニアのためのブログ講座 - connpass

2017/01/30 19:30〜 @渋谷サポーターズオフィス
講師:田中賢治さん


■内容

エンジニアのためのブログ講座で講師をさせていただきました! | Developers.IO


ご自分のブログで、レポートをあげてくれていました。内容はこれがすべて!って感じです 笑
そのなかで、わたしが個人的にいいなと思ったところをまとめます。

[気持ち編]

■自分にとってブログを書くメリット
・自分の理解を測り、深める…知識のアウトプット先、インプット元になる
・知人が増える

■自分以外の人にとってのメリット
・ハマるところはだれしもハマる。そんなときの助けになる
・書いている人からモチベーションをもらう


[書き方編]

■習慣化の方法
・とにかく小さい単位でつづける…少しでも、やってみた→どうなったの繰り返し
・他の人とかぶっても気にしない。自分が書くことに意味がある
・書きたいときに書く!
■装飾をうまくつかう
・リンクの貼り方や文字の装飾など、意味を知って効果的につかう
■目次から書いてみる
・目次を先につくり、テンプレート化する
・それに沿って書くと書きやすい

[ということで、やってみた!]

「目次から書いてみて、テンプレート化する」
たしかにこれなら早く書けそう!!と思ったので実践してみます。

こんな目次をつくりました〜
・バンさんと行った
・日時
・内容
・やってみた
・感想

すごくざっくりしているので、「内容」のところを書きながら細かくしていった感じです。
自分のメモを読むときにも整理しやすくて、はやく書けている気がします!
(ここまでで30分かかってない)

結果:「なんかはやく書けてる!気がする!!!」



[感想]
現実的に言うと、いままでの2本は書き始めてから1日以上、3日くらいで完成だったと思います。
話を聞いて、コツみたいなものがあるのかな〜となんとなく思いました。そこから「書ける!」気分になっていきました。
これからブログを始めようとしている方々とも交流できて刺激になりました。
そのとき弊社HPを見せてドヤ顔したのですが、なんとこのブログへのリンクがないことに気がつきました∑(*`ロ´ノ)ノ
近々HPにリンクを貼ってもらう予定ですので、応援よろしくお願いします〜!!

ドヤ顔できるガラパゴスHPはこちら

www.glpgs.com

それでは、またお会いしましょう、とののでした〜