GraphQLのメリット・デメリット

2019年9月追記しました！

最近GraphQLを扱うことが多かったのでその印象をまとめておこうかと思います。 現在、2018年10月の印象なのでここで上げたデメリットは今後解消されるかもしれないので悪しからず。

メリット

エンドポイントをいちいち設定しないで済む

扱ってみて最大のメリットだと感じたのが、RESTと違いエンドポイントが一つしか無い点です。そんなもんかと思うかもしれませんがGraphQLを使ってみていかにエンドポイントを新しく作るのが面倒だったのか痛感しました。
通常エンドポイントを作るには以下の作業が必要です。

• URL設計
• エンドポイントの共有
• クライアント側の修正
• サーバ側の修正

これらの点をGraphQLならサーバ側が新しくスキーマを定義して上げれば済むので、後は勝手にクライアント側が利用するだけとなります。

GraphiQLサーバが便利

だいたいどの言語のGraphQLを扱う仕組みでもGraphiQLサーバが実装されています。GraphiQLサーバではクエリをチェック出来るのでドキュメント代わりになれます。なのでAPI仕様書をいちいち作らなくても非常に便利で後はクライアント側がそこを参照さえすればいいので、タスクが疎結合になります。

実装とドキュメントが一致している

昔からあるアプリケーションの場合、ドキュメントで定義されている内容と実際のレスポンスが異なっているというのはあるあるだと思います。しかし上記のGraphiQLサーバは実装からドキュメントを定義されるため実装とドキュメントが異なることはありません。そのため、保守が非常に楽です。

型が定義されている

RESTもちゃんとやれば別に問題ないのですが結構神経を使うのでそこはGraphQLだと事前に定義するので便利でした。

デメリット

Apollo Clientが枯れていない

GraphQLを扱うとするとだいたいみんなApolloにたどり着くのですが、正直まだ枯れていないです。というよりGraphQL自体が枯れていないのでベストプラクティスがまだ発見されていないというのが正確だと思います。私はiOSではApolloを使いましたが開発途上だなというは感じました(Swiftとのバージョンの組み合わせなど)。
また、JavaScriptではReactとReduxで併用しようとしましたがと共存させかたがよくわかなかったのでApolloは見送って以下のミニマムなライブラリを使用しました。問題は全然無かったです。

github.com

見送った別の理由で言うとApolloがapollo-link-stateという新しい概念を提唱しているのですが現段階では流石に運用事例がほとんど無かったので見送ったのも理由です。万が一今後伸びてくるのであればその時に乗り換えればいいかと判断しました。

情報が英語

日本語の情報は非常に少なくだいたいは入門レベルなのできっかけにはなるけど全てカバー出来るわけではありませんでした。そのため英語の公式ドキュメントに頼ることになります。ただ英語ドキュメントでも使い方は載っているけど、困った時にどういう風に解決したかという情報はネット上には少なかったです

向いているアプリケーション

GraphQLが特定のアプリケーションのみ向き不向きがあるというわけではありませんが、向いているアプリケーションというのはあります。
例えば、クライアント側の開発が活発なアプリケーションでは向いていると感じています。例えば、iOS, Androidアプリとの連携などは向いています。反対に社内向けのAPIを提供する時はさほどメリットがあるわけでもないなと感じています。

まとめ

GraphQLを導入した方がいいのどうなのという意見でいうには、新規開発ならぜひ採用してRESTを置き換えるなら無理して導入しなくていいんじゃねというのが感想です。教育コストが云々の話もありますが一人がちゃんと勉強して横展開すればそこまでコストもかからないというのが印象です。

金額計算の設計に挑む

cassetteの延澤です。 今回はみんなが大好きなお金、、の設計について書いていきます。

きっかけ

皆さんは金額を扱うアプリケーションを構築したことがありますか？
私は何だかんだ最近までお金を扱うアプリケーションを構築したことがあまりありませんでした。理由とすると金額を扱うシステムは専門の部署・人が行うことが多かったので既に構築されていることが多かったです。しかし、最近になって開発することになって少し知見が貯まったので折角なのでを書いておきます。

お金を扱う難しさ

一番難しいと感じたのは後方互換を残すことです。例えば、過去にユーザーに領収書・請求書を発行した場合、将来のシステム改修で過去の金額がズレることは避けなければいけません。また、決算においても売上・消費税の計算がズレるのはよろしくありません。
しかし、ユーザーの要望を満たすために決済手段は増えるし、様々な割引きプラン設定が金額計算をどんどん難しくさせます。そして気づいた時にに決済・会計ロジックはかなり複雑となり工数の増加を引き起こします。そして、最終的にズレる金額と対する早急な調査作業。。書いてて疲れてしまいました。

お金を不変として扱う

例えば、売上を1000円計上する場合はDBのカラムに格納します。そして、税率も同時に保存しておくと良いです。

売上	税率
1000	8

単純に定数として税率を設定していた場合、いつからその税率が適用されたのかが分かりにくくなるからです。それを回避するために同時に適用した税率も保存しておくことで後の計算をしやすくなります。また、全ての計算した金額も入れておきます。

税抜き	税率	税込み	割引金額	最終価格	手数料率	作成日時
1000	8	1080	500	580	20	2018-09-01 15:00:00

以上のように割引金額の計算ロジックや手数料率の計算は変更の入りやすい箇所でもあるので、その時の適用された金額や料率も格納しておきます。そして金額を表示する際はプログラムでごちゃごちゃ計算せずに素直にDBのカラムに保存してある金額を表示するほうがシンプルで楽です。 なので金額計算においてはdryで書くのではなく、毎回計算した値をDBに持っておくことで後で計算ロジックが変わっても過去のデータの考慮が少ないです。 *1

あと、金額計算を確認できる機能を管理画面に設置していると運用も楽になります。 また細かいことを言うと売上をいつ計上するのかという日付も会計上重要ですがここでは割愛します。

まとめ

販売管理システムは経験の差が出やすい箇所だなと感じました。
最新技術のキャッチアップは若手が有利ですが、こういう複雑で重要なビジネスロジックを構築できることはシニアエンジニアの強みでもあります。

*1:因みに割引金額が適用されるのが税抜き前に適用するのか税込みに適用するのか絶対に確認しておきましょう。

プログラムの効率的な読み方

casstteの延澤です。
今回はプログラムの読みかたについて書いていきます。

まず既存のシステムに新規の機能を追加する時に、

「あなたはどのファイルから開きますか？」

この質問について答えていくのが今回のブログの内容になります。

何故読み方が大事なのか

出来るエンジニアは平凡なエンジニアに比べて100倍生産力が違うと言われています。自分は出来るエンジニアは読むのが速いため設計・実装の時間に十分な時間が取れるから生産力が違うという意味で解釈しています。
逆に考えると読む時間が遅いと設計・実装の時間が足りず、考慮漏れなどを起こし二度手間を発生させる確率が高くなることに繋がります。 ともかくエンジニアの作業はコードを書いているイメージが先行しますが実は他人のコードやドキュメントを読んでいる時間がほとんどです。

また、学生時代はプログラミングが得意だった人も就職してみると当初思ったほど最初に仕事が出来ないことがあります。これは圧倒的に他人のコードを読む時間が不足しているのも理由の一つです。
なので当たり前すぎて軽視されがちな読みかたについて書きます。

読むためのコツ

0. サービスのコア機能を確認する

これは作業に当たる前に絶対にやるべき作業です。あなたが今回担当するサービスのコア機能については実際に使ってみることです。ここで言うコア機能とはそれがなくなったらそもそもサービスとして提供出来ない機能のことです。
大体のサービスは幹となるコア機能と補完する機能群であるためコア機能さえつかめれば一気に全体の把握が楽になります。問題はコア機能はロジックが複雑なためコードを理解するのが大変なことです。最悪、直接触らないのであれば概要が分かっていれば大丈夫です。
さらに言うとこのサービスは誰にどのような価値を届けるのかを意識しておくことです。登場人物や価値を理解していると読むスピードが大幅に違ってきます。

1. 現在の動きを確認する

今回改修する箇所の動きを確認しましょう。その際におすすめなのは現在どのようにデータが変わるのかこの時点で理解しておくことです。
また、新規機能追加の場合ではどのような流れで新規機能が使われるのかを意識しておきます。

2. 用語を確認する

プログラムでは特定の機能について特定の単語で表していますのでしっかり意味を確認しておきましょう。特にあなたが新人であるならば積極的に発言して確認することです。
しかし、特定の単語が別の意味で使われていたり、特定の機能が複数の単語で使われていたりするケースは注意が必要です。こういう場合は予めバグが紛れそうだなと考えて注意しておきます。

3. ライブラリのドキュメントを確認する

今どきのサービスでFrameworkやライブラリを一切使っていない現場は少ないでしょう。もしあなたがそのFrameworkやライブラリについて使用するのが初めてであるならばしっかりと公式ドキュメントを読んでおきましょう。勘所としてはこのライブラリが何を解決するのかと哲学も理解しておきましょう。ここを意識していないと間違った使い方をするため技術負債を増やします。

4. コードジャンプ機能を使う

これは賛否が分かれるところですが、コードを追っていくならコードジャンプ機能はあった方が楽です。私はIntelliJ IDEAの有料版を使っています。
その他にもMacであればDashというAPI Document Browserと連携させてさらに効率化させています。

Dash for macOS - API Documentation Browser, Snippet Manager - Kapeli

5. 設計について理解する

レイヤードアーキテクチャ、Clean Architectureなど全体の設計に関わるものから、Design Patternを通したクラス関係については理解しておくと読みやすいです。この辺がキレイに作られているサービスは必要な読む箇所と影響範囲も分かるので理解が早くなります。ただ、現実問題としてここがしっかりとキレイに作られているケースは何だかんだ稀です。。

6. 頭を整理する

コードをずっと読んでいると頭がこんがらがってくることもあります。その結果何度も同じコードを読んでしまいループします。
そこでおすすめなのが途中でメモを書いたり図に起こしてしまうことです。特にオススメなのが図です。下手な図でいいのでコードや仕様の関係性を書いてみると案外スッキリします。私はよくホワイトボードにシーケンス図やベン図を書いて理解しています。

まとめ

上記の中で個人的に一番重要なのは「0. サービスのコア機能を確認する」です。コードの読むのが遅い人はそもそもサービスの理解が深くないケースが多いです。全体像を把握していないのに詳細なソースコードを読んでも中々頭に入ってこないです。
全体像を理解した上でコードが実際にそうなっているのか確認してみると理解しやすいです。そうやって考えるとこの記事の一番上にあった「あなたはどのファイルから開きますか？」という質問に対しては、まずいきなりファイルを開かないが正解になります。
昨今、入社試験などでアルゴリズムの問題を出すことが多いですが、個人的にはプログラムの読解をさせた方が実務の能力を図るのに適していると考えてます。読解させた上で仕様を読み取れるのか、設計が良いのか悪いのか議論した方が試験内容としては面白いと感じます。

企業勤めでは評価と年収に相関性はそこまでないんじゃないかな

cassetteの延澤です！ 以下の記事を読んで少し引っ掛かることがあったので記事を書きます。 logmi.jp

簡単な要約

技術力ばかり上げていたら、相手から求めていることとの乖離が起きて評価が上がらないよというお話。後半の時間と目標については前半の話とあんまり関係ないのでここでは無視します。

評価と年収に相関性はそこまでない

9割同意する内容なんだけど、年収1000万円との関連性があまりよくわからなかった。相手の評価が良かったからといって年収が上がるということは考えづらい。例えば、平均年収500万円ぐらいの企業で働いていた場合いくら優秀でも年収1000万円に手が届くのは難しいじゃないのかな。この人は評価と能力が良ければ年収も上がると考えているけど、自分は個人の能力よりも以下の三点で年収は決まると思う。

1. 業界年収
2. 企業業績
3. 企業文化

1. 業界年収

業界の平均年収というのは大体決まっていて大きくそれることはない。何故かと言うと業界首位の会社が粗利で業界2位の会社に倍の差をつけていたとしても社員の平均年収に2倍の差があることは聞いたことがない。これって談合なんじゃないのかと個人的には考えている。

2. 企業業績

どんなに優秀で救世主な人材であっても会社の業績が悪ければ年収は伸びない。まあ金がないからしょうがいないよね。シリコンバレーではそもそも投資金額が桁外れに多いから企業業績関係無しに給料が払われる。すごい文化だな。

3. 企業文化

よくあるのが企業の文化として特定の部署が強いということ。例えば、Googleではエンジニアが部門が強いためエンジニアとしては働きやすいし年収も高い。自分はかつて働いていた部門の幹部がウチの部門はコストセンターだって言っていて萎えたことはある。謙遜するのもいいけどWeb企業の開発がコストセンターだって言い切られると流石に苦笑した。
なので会社の認識としてこの部署は利益を生み出していると考えているかどうかで大きく変わる。

年収とは

何を言いたいのかというと個人の能力や成果なんて上記の3つの要素に比べれば鼻くそみたいなものだ。そういう不安定な要素で年収なんて決まるのだから自分がやりたいことをしてお金を稼いだ方がいい。他人の評価ばかりを気にして成果を上げる人生って楽しいのかな。

まとめ

自分は上記の不安定な要素を嫌ってフリーランスになったのも一つの理由だ。能力と稼ぎは直結するし例え駄目でも納得感はある。
他に能力的なことを言うと関数型言語最高と普段言っている自分が言うのもあれだがプロジェクト管理の経験はやって損はないと思う。視野が広くなるし管理者が自分に何を求めているのかも分かる。自分が関わるプロジェクト失敗の確率がかなり減るのでオススメです。

ReactとVue.jsを状態管理から見た選び方

今回はReactとVue.jsのどちらを選定するかについて状態管理という観点で書いていこうと考えてます。

結論

いきなり結論ですがReactは関数型視点でコンポーネントを設計していく。Vue.jsはオブジェクト指向視点でコンポーネントを設計していく。
以上終わり。

と、さすがにこれだけだと何のこっちゃという話なので整理していきたいと思います。

そもそもJavaScritptとは

JavaScriptは言語の中でもかなり特殊な言語です。具体的に言うと関数型っぽくも書けるしオブジェクト指向っぽくも書ける言語です。結果的にプログラミングスタイルが定まっていないため一部混乱をきたしています。そういうある意味カオスなところがこの言語の持ち味です。ただ、その影響もあってライブラリの設計思想にも影響が出ています。

ReactとVuejsのコンポーネントの設計方針

Reactはコンポーネントに状態を持たせないステートレスなコンポーネントの設計を推奨しています。つまり、stateを使わずにpropsを使え。コンポーネントにライフサイクルを持たすなと推奨しています。stateやライフサイクルはコンポーネントに副作用をもたらすためです。
Vuejsはコンポーネントにステートレスな状態を持たせることが推奨していません。別に否定もしてませんが。ただ、現実問題としてVue.jsのコンポーネントにステートレス状態にさせることにそこまでメリットをやはり感じません。

コンポーネントの状態について

結局、コンポーネントにおいては状態をどう扱うかが肝になってきます。逆に状態を持たないアプリケーションであれば無理してコンポーネント化しなくてもいいのではないかと個人的に考えてます。
そのため、ReduxやVuexのなどの状態を管理するライブラリを使用することとセットで考える必要があります。

ReduxとVuex

ReduxはReactのstateの状態を持たせないステートレスなコンポーネントを強制することができます。ReduxはElmという関数型言語から影響を受けているためこのような作りになっています。つまりReduxの冗長な書き方は関数型から影響を受けていると考えればある意味納得できます。私も初めて触った時は処理が分散していてなんとも見通しが悪いなと感じました。しかし、処理が固まっていて欲しいと考えるのはオブジェクト指向のカプセル化の考えが染み付いているためだと後になって気づきました。 その反面、Vuexについてはスッと学習コストもなく覚えることが出来ました。同期処理ならここ、非同期処理ならここというようにVuejsの延長線上で考えれます。恐らくオブジェクト指向のままで考えると便利なライブラリです。

ReactとVuejsの選定基準

1. 関数型とオブジェクト指向での基準

開発者がオブジェクト指向型言語出身のメンバーであればVue.jsを使った方がすんなり開発できます。例えば、Ruby on Railsをよく使用しているエンジニアが参加するのであればこちらをオススメします。特に開発メンバーのJavaScriptのスキルがそこまで高くないのであればこちらの方がリスクが低いです。 逆に中心的なフロントエンドエンジニアがプロジェクトに存在するのであればReactがいいでしょう。

2. 大規模サービスかどうか

Vue.jsは状態を持ってしまうので、Reactと比較すれば大規模なサービスでが苦しくなってきます。ちゃんと設計すれば問題ないという指摘もありますが、バックエンドに比べて変更が多いフロントではアーキテクチャで固めた方が保守しやすいです。

3. 設計の難易度

Reduxのフレームワークは非同期処理以外はどこにロジックを記述すればいいか明確です。デメリットとしてはよく言われているようにボイラーテンプレートが多くなります。
反対にVuexは処理をどこに持たすのか自由なため設計次第ということになります。そのため、初期の学習コストは低めですが保守コストはVue.jsの方が高いです。

私はどちらを使うことにしたのか

私はサーバサイドを関数型のElixirを使っているのでReactを使うことにしました。スタートダッシュではVue.jsの方がメリットが高いので迷ったのですが思想は共通していた方が後々良いと判断しました。後は、別の仕事でも使用していたので学習コストはゼロだったのも理由です。

PhoenixでpryをDockerと併用して使う

久しぶりに普通の技術ネタを一つ。
今、ElixirのPhoenixを使って開発をしています。PhoenixはRuby on Railsの弟分みたいな存在でRailsを使用したことある人なら学習コストが低めで開発出来ると思います。
そこでpryをdockerと併用して使う方法の説明になります。

Docker 起動

$ docker-compose run --service-ports app sh

説明するとappはPhoenixが起動しているコンテナでshコマンドでログインしています。肝となるのが--service-portsオプションでこれがないとHostのポートとマッピンが出来ません。portの設定はdocker-compose.ymlで設定してください。

Phoenix起動

$ iex -S mix phx.server

mix.exsファイルがあるディレクトリで以上のコマンドを実行することでREPLになります。 あとは、breakしたい箇所で以下のコードを実行します。

require IEx
IEx.pry()

あとは、Allow? [Yn]みたにpryに接続していいか聞かれるのでyを入力すれば止まります。

コマンドのリファレンス

IEx.Helpers

6年間SEO対策に携わってみて

タイトルは釣りだ。流石に6年間ずっとSEOをやってきたわけではない。しかし、SEOについてエンジニア側から発信の情報は少なかった。その中で私がSEO対策をしていて気づいた原則を今回書いていきたい。

SEOは最適化であって上位にあげる手段ではない

SEOの本来の目的はGoogleの検索ボットに正しくインデックスするために情報を整理することである。ただ、企業が行うSEO対策の目的は検索順位を上げることである。いきなり本題であるがこれは全く似て非なるものであって本来のサービスの実力以上に検索順位が上がることはない。勿論、例外はあるだろう。そのパターンは競合サービスがペナルティを受けていたり相当SEOに対して手を抜いているのでたまたま検索上位にいるだけであって持続性はない。とにかく弱小サービスが業界上位のサービスに対してSEOで勝つことは基本的に不可能である。。 これはユーザー視点から考えてみれば当然である。例えば賃貸物件を検索する時に大手サービスではなくローカルな不動産屋が検索順位を独占しているのと一緒だ。ただ、当事者で作業している時にはこの視点がすっぽり抜けていたり、企画の段階でそもそも論を言い出しにくい雰囲気はある。

裏ワザはない

SEO対策をやっていると実は何か裏ワザや革新的な手段があるのではないのかと考えることがある。確かにひょっとしたら裏ワザは”あるかも”しれない。この”あるかも”というのが厄介で断言できないことが多くの悲劇を生み出している。 結局、Googleの社員でもないのでその裏ワザを見つけ出すのは宝くじに当たるようなものであり再現性は低い。

小技はあんまり効かなかった

SEO対策と言っても内部構造を大きく変えることやページのタイトルの修正も含めて大小様々な施策がある。しかし、大体は出来る小さな施策から手を打っていくことが多い。ただ、小さな施策は効果検証がしにくいし効果もあまり出なかった。要するに安物買いの銭失いという状態である。結局多少効果もあるだろうが多少なため費用対効果が薄かった。

じゃあ、効果あることは何だ

エンジニアたるもの公式ドキュメントを見よう。その中の対策はまず一通り行う。ただ、公式ドキュメントの内容を実施したとしても競合サイトとは差別化しにくい。。いや本当だろうか？ 「質の高いコンテンツを提供しよう」というところだ。要するに動的に自動生成したようなページではなく独自性のあるコンテンツを提供しようということだ。ユーザー視点から見れば本当にそうで、自分だって動的に自動生成したようなページを見ることはない。結局、お金をかけて地道にページに付加価値をつけることが近道である。そういう当たり前の面倒くささを回避してアイディアや知恵で乗り越えようとするからおかしな話になってくる。だから、SEOというのはお金がある企業がやるような対策であって小さい企業が真剣にやるようなことではない。

余談

SEO施策は何度もやっているが退屈な仕事であるし、殆どのエンジニアの偽らざる本音だろう。だからこそやるならしっかりとキーワード選定も含めた戦略を立てて実行したい。ここには書いていないことは少しはあるがそこは内緒ということで〜