正しいものを正しく作る塾に参加しました

正しいものを正しくつくる(設計実装)に参加しました。

せっかくなので、塾の感想をブログに書き留めておこうと思います。

正しいものを正しくつくる(設計実装)とは

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法を執筆された増田さんが講師となり、設計について個々の言語化を促進する塾です。

塾では、下記6冊の参考図書に存在する隠れた関係性を紐付ける過程を通して、知識を広げながら深めていきました。1

毎回の講義始めにある30分間の対話を通じたアウトプットでは飽き足らず、塾生が主体となり休日に集まるなど互いに刺激し合いながら学んでいました。

なぜ、塾に参加したのか

塾に参加する前に、社内でも技術力の高いチームに異動しました。

異動直後、技術力が高いチームメンバーが負債に苦しんでいるのがわかりました。

私もコードやアーキテクチャーに強烈な違和感を感じるが、うまく言語化できないまま数週間が過ぎました。

このままでは、自分の言葉で説明できないまま負債という安易な言葉で片付けてしまうと思い、藁にもすがる気持ちで受講することにしました。

参加して学んだこと

塾を通して、大小様々なことを学びました。少し寄り道して哲学や生物学を学んだり、生活の一部となっている習慣(整理整頓)とオブジェクト指向を紐付けてみたりと内省とチャレンジを通じて言語化できたことをまとめてみます。

オブジェクト指向とは何か

オブジェクト指向とは、高凝縮、疎結合を目指すソフトウェア開発戦略です。この戦略を確かなものとするために、抽象データ型によるモジュール構造を塾では提唱していると紐付けました。

なぜ、高凝縮、疎結合である必要があるのでしょうか。それは、人間の脳が対応できる情報量が開発するソフトウェアの発達に伴って増加しないことに根本的な原因があると考えました。

責務を正しく分割し、周辺への影響範囲を最小限に留めることにより、情報量の指数関数的な増加を防ぐことが高凝縮、疎結合を目指す理由なのではないかと思います。

ビジネスロジックとは何か

Railsは、MVCというアーキテクチャーをとります。モデルであるMには、ビジネスロジックを書くべきであると言われていますが学生時代その意味がわかりませんでした。

塾で紹介された関心の分離の4象限からビジネスロジックとは、計算・判断と意図の表現の掛け合わせなのだとわかりました。

2

CCSRとは何か

塾では、CCSR(継続的・並行的・段階的な改善活動)を行うことが発展性のあるソフトウェア開発に繋がると紹介されました。

CCSRとは、ソフトウェアで解決する課題をステークホルダーとの対話を通じながら明らかに、型による継続的な構造化を行うことだと理解しました。

CCSRは、発展性に振り切った思想です。

コトラーの競争地位戦略

塾で最も印象に残っているのが、コトラーの競争地位戦略の話です。

コトラーの競争地位戦略のポジションによって、とるべきビジネス戦略が変化します。

そのビジネス戦略によって、ソフトウェアのどこに注力すべきかが変わってくるというものでした。

例として、楽天が紹介されました。

外から見るとECのリーダーだが、中ではAmazonに対するチャレンジャーであると言われた時は、ハッとさせられました。

また、外から客観的に判断できる数字によってポジションが決まるのではなく、中の人がどう思っているかによって変化するのだという視点には驚きました。

まだビジネス戦略を考慮して開発を行えていないですが、将来的に習得したいスキルを発見できたのは大きな収穫でした。

業務での変化

命名へのこだわり

現在、Stripeを利用して開発を行っています。そこでは、2重課金を防ぐためStripeから飛んできたイベントをDataBaseに格納し存在をチェックすることで冪等性を担保しています。

塾に参加する以前だと、RailsのActiveRecord#exists?APIをそのまま利用して実装していたと思いますが、イベントが処理されたことを明示するために、exists?のaliasとしてprocessed?を定義し実装を行いました。

これは、極めて小さな変化のように見えるかもしれません。しかし、リファクタリングを通してソフトウェアに息を吹き込むことがCCSRへの第一歩なのだと実感した体験でした。

適切な責務に配置されていないコードを指摘できた

元チームのPullRequestをレビューしている際に、3つのモデルの責務が1つにモデルのメソッドとして記述されていることを発見し、未然に負債化を防ぐことができました。

変更が少ないものに、依存すべきであるのではないかと考えはじめた

成果として、GitHubのGraphQL API v4にて、EmailのScalar型を定義していない理由を考察してみたをアウトプットしました。

2020年12月にどうなっていたいのか

  • リファクタリングスキルをつけ、負債の解消する
  • 人間とソフトウェアの関係性についての深掘り

業務では、システムの理想と現実を明らかにしながら負債を解消していきたいです。

人間についてより理解を深めることで、ソフトウェアに対する深い洞察が得られるのではないかと考えています。

まずは、その足掛かりを探したいと思っています。

何をアウトプットしていたいか

  • DDDと静的型付け言語(Java)の理解を深め、GraphQLのSchemaガイドを作成

深掘りたい参考文献

塾では主専攻、副専攻2つの書籍を深めることが推奨されています。 下記2つを深め、どこかで発表したいと思います。

まとめ

会社に受講料を負担してもらいながら、社会人1年目と早い段階で設計に関して深掘りする機会を得られたのは、これからのエンジニア人生で大きな資産になると思う。これからも油断せず、継続的にアウトプットをしていきたいです。


  1. ラーニング・パターンに基づいた学習

  2. 画像の使用許可を確認済み

整理してOAuth2.0を使うためのチュートリアルガイドを読んだ

モチベーション

個人開発でYoutube Data APIを利用したかったので、ドキュメント読みOAuth2.0を雰囲気で理解しました。

サービスのコア機能であることや、ライブラリの利用方法だけ理解し実装することはユーザーの個人情報流出リスクが高いと考え、正しい知識を身に付けようと思いました。1

書籍での学び

認可サーバーとリソースサーバーがあること

Using OAuth 2.0 to Access Google APIsのシーケンス図では、Google Serviceとして認可サーバーとリソースサーバーがまとめられています。書籍にて認可サーバーとリソースサーバーが紹介されており、認識のズレがなくなりました

インプリシットグランドが非推奨であること

認可リクエスト時に、response_typeを必須パラメータとして与える必要があります。

response_typeには、codetokenの選択肢がありますが、両者の違いが不明確でした。

5章の認可コードグラントとインプリシットグランドの説明を読むことで、response_typeがcodeの時は認可コードグラント、tokenの時はインプリシットグランドであることがわかりました。

インプリシットグランドは、認可リクエストを行うとアクセストークンを取得することができるのが特徴です。2

そのため、セキュリティの問題でインプリシットグランドが非推奨であることがわかりました。

これは、OAuth 2.0 Security Best Current Practice draft-ietf-oauth-security-topics-09で確認できます。

個人開発のサービスでは、response_type=codeにしておけばいいことがわかりました。

フラグメント識別子は、サーバーまで届かない

MDNにも、以下のような記載があります。

# より後の部分はフラグメント識別としても知られており、要求でサーバーには送信されないことは注目に値します。

知見でした。

OAuthは、認可の仕組みである

GoogleのOAuthドキュメントを読むまでは、OAuthは認証の仕組みであると思っていました。

なぜ、このような勘違いをしていたか明らかでなかったのですが付録Aを読んで腑に落ちました。

Rubyのライブラリであるomniauth-google-oauth2でしかOAuthという存在を知らなかったのでOAuthは認証の仕組みであると勘違いしていた。

まとめ

雰囲気で使わずきちんと理解する!整理してOAuth2.0を使うためのチュートリアルガイドは、OAuthを完全理解するためにオススメの本でした。

参考文献

2020年 GWに読んだ書籍

Linux教科書 LPICレベル1 Version5.0対応

社会人2年目の目標は、「緊急時のバグ修正速度の向上や運用を意識した開発を行う」です。

Linuxの基礎をググらなくても理解できていることを目指すのが良いと思い、LPIC1xxと2xxを取得するため勉強していました。

Linux教科書 LPICレベル1 Version5.0対応

Linux教科書 LPICレベル1 Version5.0対応

  • 作者:中島 能和
  • 発売日: 2019/04/08
  • メディア: 単行本(ソフトカバー)

Patterns of Enterprise Application Architecture

会社で行っている輪読会の書籍で、翻訳担当の章であるDomain Logic Patternsを読んでいました。復習として、Part 1も読みました。

社会人2年目になり理解できる部分も増えています。成長を実感できる書籍です。

エリック・エヴァンスのドメイン駆動設計

第2部まで読みました。エリック本は、外部研修の教材になっているため指定された章のみで、通しでは読んでいませんでした。

業務ではRailsを利用しているため開発手法として採用することは難しいですが、エッセンスを転用できる箇所が多々合ったので目的が合致した時に試してみたいと思いました。

GraphQLのAPI開発にValue Objectを意識すると、より良いSchemaが提供できるのではないかと思いました。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

  • 作者:Eric Evans
  • 発売日: 2013/11/20
  • メディア: Kindle版

ドメイン駆動設計 モデリング/実装ガイド

エリック本だけでは、各単語を人に伝えることができるまで理解できなかったため松岡さんの書籍を購入しました。

集約とは、「必ず守りたい強い整合性を持ったオブジェクトのまとまり」であるという言葉で理解が深まりました。

エリック本を読んだ後に、読むことを強く勧められる一冊でした。

最後に紹介されていた成瀬さんの「ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本」も読んでみたいです。

ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本

ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本

  • 作者:成瀬 允宣
  • 発売日: 2020/02/13
  • メディア: 単行本(ソフトカバー)

little-hands.booth.pm

入門 起業の科学

個人開発をやりたくなったので読みました。一度、型に従って開発を行うことで自分なりのスタイルを確立したいという思惑がありました。

サービスのコンセプトやコア機能を定義し、へーパープロトタイプまで完成したので8月リリースを目標にコア機能に注力し開発を進めていこうと思います。

入門 起業の科学

入門 起業の科学

改訂版 ウェブ解析士認定試験公式テキスト2020

技術以外に新しい視点で物事を判断できるようになりたいと思い、読みました。

資格を取得するかに関係なく本当にオススメできる一冊です。サービス全体の流れとKPIを紐付けた図を作成することで学びを確かなものにしたいです。

思考法図鑑 ひらめきを生む問題解決・アイデア発想のアプローチ60

このまま技術のことを学んでも、半年後に成長速度が落ちるという漠然とした危機感を持っていました。

対策としてインプットの質を上げる必要があると思いました。

どのように物事を考えるのかメタ的に理解するため思考法図鑑を購入し読みました。

各章の練習問題に手をつけていないので定着が甘いかもしれませんが、読み終わりました。

一日一つ思考法を業務で試していこうと思います。

思考法図鑑 ひらめきを生む問題解決・アイデア発想のアプローチ60

思考法図鑑 ひらめきを生む問題解決・アイデア発想のアプローチ60

Linuxで動かしながら学ぶTCP/IPネットワーク入門 Kindle版 が開けない時の対処法

Kindle for Macで「Linuxで動かしながら学ぶTCP/IPネットワーク入門」をDLするとKindleのアップデートを求められた。

KindleやMacのアップデートを行ったが、症状が継続していた。

Twitterで呟くと、著者様より記事を紹介してもらった。

記事の方法でも解決しなかったので、Amazonのサポートに問い合わせたところ無事閲覧することができた。

GitHubのGraphQL API v4にて、EmailのScalar型を定義していない理由を考察してみた

GitHubのAPI v4は、GraphQLで開発されている。バックエンドの開発者で参考にされることが多い。

GraphQLは、StringやIntなどビルドインのScalar型以外に独自定義を行うことで型安全なAPIを開発することができる。

GitHubのAPIにおいても多くのカスタムScalars型が定義されている。

少しドキュメントを眺めてみるとRFCやISOなど比較的変更が起こりにくいものに依存して型を定義していることがわかる。

しかし、UserオブジェクトのEmail Filedの型にはStringが利用されている。

そこでタイトルの通り、GitHubのGraphQL API v4にて、EmailのScalar型を定義していない理由を考察してみた。

考察

RubyにおけるEmailのバリデーションは、以下の通りである。

URI::MailTo::EMAIL_REGEXP

EMAIL_REGEXP = /\A[a-zA-Z0-9.!\#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*\z/

https://github.com/ruby/ruby/blob/ruby_2_7/lib/uri/mailto.rb#L56

しかし、愚直に利用すると思わぬ失敗を招いてしまうことがある。

これについては、その正規表現、意義ありの資料が参考になる。

Railsというフレームワークを用いた開発では、Deviseという認証系のライブラリが頻繁に利用される。実装は以下の通りだ。

@@email_regexp = /\A[^@\s]+@[^@\s]+\z/

https://github.com/heartcombo/devise/blob/5-rc/lib/devise.rb#L116

議論からEmailバリデーションの困難さが窺える。

最初に、以下のように述べたがEmailは実装が安定していないことからGitHubではカスタムScalar型を定義していないのではないかと考えた。

RFCやISOなど比較的変更が起こりにくいものに依存して型を定義している

この考えは、Shopifyのスキーマ設計チュートリアルでも述べられる。

Use weaker types for inputs (e.g. String instead of Email) when the format is unambiguous and client-side validation is complex. This lets the server run all non-trivial validations at once and return the errors in a single place in a single format, simplifying the client.

まとめ

GitHubのGraphQL API v4にて、EmailのScalar型を定義していないを理由を考察した。

Emailは、実装が安定していないためカスタムScalar型を定義すると複雑性をアプリケーションに注入することになる。

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

IRBをアップデートすると undefined method `encoding_system_needs' for Reline:Module エラーになるときの対応

環境

$ irb -v
irb 1.2.3 (2020-02-15)
$ ruby -v
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-darwin18]

解決方法

reline をインストールする

gem install reline

参考文献

IRB 1.2.3 does not boot with Ruby 2.7 on my mac · Issue #87 · ruby/irb · GitHub

改訂2版 パーフェクトRuby

改訂2版 パーフェクトRuby

WebAPIは、HTTP通信という制約を持ったPublicメソッドである

エンジニアになって1年経ったので考えを整理しておく。

タイトルの通り、「WebAPIとは、HTTP通信という制約を持ったPublicメソッド」である。

HTTP通信という制約下で実行するため、通信による失敗が多いことやデータベースによるトランザクションを利用できないことが特徴だ。

これによって、例外処理や冪等性、結果整合性など余分に考慮することが増える。

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus)

  • 作者:山本 陽平
  • 発売日: 2010/04/08
  • メディア: 単行本(ソフトカバー)

メトリクスをなぜ、とるのか

note.com

「スタートアップ経営で現れる壁と事例とその対策について」を読んでメトリクスをなぜ、とる必要があるのか考えてみたので、メモとして残しておく。

資料を摺り合わすことなく考えたため、大枠すら捉えられていない可能性があるので注意したい。

メモ

日常の業務では、少し立ち止まって考えてないと浮かび上がってこない綻びが各所に点在している。

小さな綻びが大きな問題となって現れた時、対処はより困難となっている。

メトリクスは、立ち止まって考える機会を与えるために必要であると考えた。

つまり、問題を問題として認識するために必要なのだ。

よって、メトリクスを設定する時に、計測することでどのような問題を検知することができるのか、また何を検知できないかを熟考することが重要だ。

この際、気をつけなればいけないのは綻びに気付けたとしても、その問題が検知対象の問題であるとは限らない。

問題を正しく認識することができず、解決方法を誤ってしまい思わぬ食う時間を可能性があるだろう。

よって、メトリクスの責務を問題を可視化させることに注力させることが重要であると考える。

上がってきた問題を分類し、どのように解決するかは個別に対応する必要がある。

以上。

Enumerable#none?でReadableなコードにする

Railsにて要素が存在しないことを blank?empty? で確かめることがある

def purchased_book payments
  payments.none? "未購入" : "購入済み"
end

しかし、あるユースケースではRubyの Enumerable#none? を利用した方が意味が明らかになるので、積極的に利用したい