【技術書まとめ31】現場で役立つシステム設計の原則

こんにちは。

今回は、DDD（ドメイン駆動設計）を学ぶために、勤めている会社で話題になっていた「現場で役立つシステム設計の原則」を読みました。

学ぶことが多く、今後も定期的に見返したいと思ったので、ポイントをまとめました。 

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

設計の重要性

• どこに何が書いてあるかを分かりやすくし、修正や拡張が楽なコードを生み出すこと

• 変更が大変なプログラムの特徴 3点。どれも関心事の詰め込みすぎが原因
• • メソッドが長い
  • クラスが大きい
  • 引数が多い

設計の仕方の比較

2つの設計の仕方を比較します。

どちらの設計も、関心事の分離のために 3層アーキテクチャ を使うことを前提にしています。

• プレゼンテーション層：UIなどの外部との入出力
• アプリケーション層：業務機能のマクロな手順
• データソース層：データベースとの入出力

データクラスを使う設計

• 従来の手続き型の設計で基本とされていた、データを格納するデータクラスと、ロジックを記述する機能クラスに分ける設計

• データクラスは getter/setterメソッドだけを持ち、データを使った判断/加工/計算のロジックは、機能クラスに記述する

• 3層が同じデータクラスを参照できる結果、データクラスを使うロジックが3層のどこでも書けてしまい、重複しやすくなってしまう欠点があった

イメージ図（本書のCHAPTER3 図3-2をベースに作成）

ドメインモデルを使う設計

• ドメインモデルとは、業務で扱うデータと関連する業務ロジックを集めて整理したもの
• • ドメインとは、業務アプリケーションの対象領域を指す

• ドメインモデルを使った設計では、ドメインモデルに集めた業務ロジックを3層が利用する形になる → 業務ロジックを書く場所が明確になり、重複を防げる

イメージ図（本書のCHAPTER3 図3-4をベースに作成）

• 業務ロジックを記載するのはドメインモデルのみとすることで、3層の記述は簡潔で分かりやすくなる。業務アプリケーションのコードが複雑になる理由は、業務ロジックの複雑さであるため

• ドメインモデルは画面やデータベースの都合からは独立して、純粋に業務の観点から業務ロジックを整理できる → ドメインモデルを見れば、業務全体がどういう関心事から成り立っているかを理解できるようになる

ドメインモデル設計の仕方

ドメインモデルを使う設計の利点を理解した後は、実際にどのように設計を行うかを学びます

• ドメインモデルの設計は、業務で使われる具体的な用語（概念）を手がかりに進める。その用語が、データとロジックをひとかたまりとしてプログラミング単位として使えるかを検証する

• 部分に注目し、個々の部品を作り、それを組み合わせて段階的に全体を作っていくボトムアップのアプローチを取る

• 部分に注目するが、全体像を意識しないと間違った方向へ進む危険がある。全体を俯瞰する道具として、以下の2つがある
• • パッケージ図
    • パッケージ間の依存関係を表現する

• • 業務フロー図
    • 業務の活動を時間軸に沿って図示したもの
    • 顧客/販売部門/出荷部門などの活動の主体ごとのレーンを並べ、その間の情報のやり取りを表現する

• これらの図で全体を俯瞰したら、重要な部分を探し、重要な部分から作っていく

• 業務を分析し、理解するために、業務の関心事をヒト/モノ/コトの3つに分類する手法がある
• • ヒト：人の意思/判断/行動についてのデータを持ち、そのデータを使った判断/加工/計算のロジックを持つ

• • モノ：ヒトが業務を遂行するときの関心の対象。これらの属性を表現するデータと、そのデータに対して業務的にどういう判断/加工/計算をしたいかをロジックとして持つ

• • コト：基本的にヒトの意思決定や行動の結果。業務アプリケーションの基本的な関心事は、コトを記録して、コトの発生を通知すること。コトに注目すると、全体の関係整理しやすい

ドメインモデル設計の注意点

• 業務では実際に使っていない抽象的な言葉をクラス名として使ってしまうと、そのクラス名は具体的には何も説明しておらず、業務を的確に捉えられない

• オブジェクトとテーブルを自動的にマッピングするアプローチは、どちらかの設計のアプローチの制約を受け、うまくいかないことが多い。業務ロジックはオブジェクトで、事実の記録はテーブルで行うべき

• 表示のためのロジックと業務ロジックを混在させない
• • 例1）一定金額を超え、かつ、注文後1日以上経過した注文を画面で強調表示する場合、画面表示のロジックに if 文を書いてしまうことがあるが、これは業務ルールなのでここに書かない方が良い

• • 例2）カンマや千円単位の表示なども、ドメインオブジェクトが持つべき加工ロジックの候補。データの文字列表現は、利用者の関心事であり、そういう関心事に関わる加工や判断のロジックはできるだけドメインオブジェクトに集約した方が変更が楽で安全になる

おわりに

ここまで読んでいただきありがとうございます。

これまで DDD（ドメイン駆動設計）の本を何冊か読んできましたが、個人的には本書が一番理解しやすかったです。本書をとっかかりにして、関連書籍を読んでいき、実践することで DDD への理解を深めていこうと思います。

本書の中では、図を多く使って丁寧に説明されていて理解しやすかったので、ご興味ある方は是非読んでみてください。 

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法

【読書まとめ30】いちばんやさしいアジャイル開発の教本

勤務している会社でアジャイル開発を取り入れはじめ、開発・ビジネスサイドのメンバー合同で「いちばんやさしいアジャイル開発の教本」の輪読会を行いました。

学びが多く、これからアジャイル開発を実践していく中で、都度振り返れるようポイントをまとめました。

いちばんやさしいアジャイル開発の教本　人気講師が教えるDXを支える開発手法 「いちばんやさしい教本」シリーズ

なぜアジャイル開発が必要とされるのか

従来型の開発手法であるウォーターフォールの課題を整理し、その上でなぜアジャイルなのかを学びます

ウォーターフォールとは

一言で説明すると

開発をいくつかの工程に分けて順番に取り組んでいく手法

メリット

工程が明確に分かれているので、進捗確認、役割分担がしやすい

ソフトウェア開発の難しさ

開発したけど使われない問題

ソフトウェアの6割の機能は使われていないという調査結果がある

なぜそんなことが起こるのかというと、利用者が欲しいと思っているものが本当に必要かどうかは、利用してみるまでわからない

不確実性が高い

特にプロジェクト初期ほど不確実性が高く、見積もりから大きくブレやすい

プロジェクト初期では、見積もりの0.25倍〜4番の振れ幅があるとされている

ウォーターフォールの課題

• 手戻りができない。ただ、実際にソフトウェアを触ってみないとわからないこともあるので、要件を最初に全て決めることは現実的ではない → 本当に必要なものからかけ離れたものが作り込まれてしまうリスクがある

• 前工程で遅延が発生した場合に、後工程で辻褄あわせのために期間が圧縮されることがある。前述のように序盤の工程ほど不確実性は大きい → テストなどの工程が削減され、品質の低いソフトウェアになるリスクがある

ウォーターフォールとアジャイル開発の違い

• ウォーターフォール：各工程での成果物を完成品とみなし、後工程での手戻りが発生しないようになっている。各工程は1度ずつのみ行う

• アジャイル開発：一定の期間（スプリント）ごとに動くソフトウェアが作られ、次のスプリントではそのソフトウェアから得られた気づき・フィードバックをもとに要件レベルから見直しが行われる。 スプリントの数だけ各工程を繰り返す

→ アジャイル開発だと少しずつ動くものを作るので、細かくフィードバックを受けることができ、本当に必要なものを作れる可能性が上がる

アジャイル開発の原則・コンセプト

アジャイル開発について理解するために、原則・コンセプトをまとめます

主な原則

• 継続的かつ短い間隔でのリリース
• ビジネスサイドと開発者の協働
• 対話の重視
• 絶え間のないカイゼン
• ふりかえり
• 動くソフトウェアの重視
• 要求の変更はたとえ開発の後期であっても歓迎する

3つのコアコンセプト

• チーム：アジャイル開発における機能するチームは、自己組織化されており、職能横断型なチーム
• • 自己組織化：自分たちで物事を決めて自律的に動けること
  • 職能横断型：複数の専門性を保有し、ソフトウェアを完成させる能力を有していること

• インクリメンタル：少しずつ作る

• イテレーティブ：反復的に作る。反復的に作ることで、経験・得られた学びに基づき次の開発ができる

具体的な手法・カイゼン例

職場で実際に使えそうな手法や、カイゼンの例をまとめました

「カイゼン」は、改善とは区別されています

• カイゼン：今あるものをより良いものしていくという、前向きで積極的な活動を意味する
• 改善：発生している問題を取り除くという、カイゼンに比べると若干後向きなニュアンス

プロジェクト開始時に有効な手法

プロジェクト、プロダクト作りを始めるにあたり、目的や前提を把握することやチームメンバーへの理解を深めることは、状況に応じた判断を自分たちで行うための第一歩。このような共通理解を深める3つの方法がある

• インセプションデッキ：プロジェクト、プロダクトレベルで目的や目標、前提や制約を理解する

• ドラッガー風エクササイズ：チームメンバーレベルで考え方や得意なことを理解する

• ワーキングアグリーメント：チーム活動レベルで協働のためのルールを理解する。何か問題が起きる都度、ルールの追加、変更を検討する

デイリースクラムのカイゼン例

• 進捗遅れがあるにも関わらず「問題ありません」発言が目立ってきたら、「困っていること」から「モヤモヤと違和感を感じていること」に変えてみると良い。メンバーが問題を共有するハードルを下げることができる

• ファイブフィンガーで進捗状況を発言しやすくできる。スプリントゴールの達成度合いは5本の指で表現するといくつぐらいか、と数字の大きさで表明してもらうと、問題ありませんと発言していたメンバーも数字の理由を聞くことで状況を発言しやすくなる

• 個人レベルの失敗を共有することは、チームで成果を出すための成長と前進のきっかけ。デイリースクラムで共有される問題は、他のメンバーが同じ失敗をしないための学びのきっかけであることを強調するためにも、マネージャーなどから積極的に行っていく

振り返りのカイゼン例

• 暗くなるようの反省会のようになってしまったら、良いことをさらに良くするための振り返り方法を試してみる

• 「YWT」：やったこと(Y)、わかったこと(W)、次にやること(Y)を意味し、わかったことという気づきをベースに、次にやることを明確にできる。気付いた学びを次に活かすという流れが成長を促進する

• 「Fun! Done! Learn!」：楽しかったこと(Fun!)、やったこと(Done!)、学んだこと(Learn!)を意味し、これら3つの円を重ね合わせて、実施したことがやっただけなのか、楽しさも同居していたのか、さらには学びもあったのかを振り返る。振り返りながら楽しさをイメージするため、記憶に残りやすい成功体験の学びになる

• KPTはカイゼン策に、YWTは気づきに、Fun! Done! Learn! は楽しかった学びに関心のフォーカスが当たる。3種類の振り返りを定期的に変えたり、状況によって使い分けることで形骸化を打破できる

• こぼれ球を拾う、手こずっているメンバーを手伝うなどの動きはチームワークを発揮するために重要だが、フィードバックがなければ継続する気力がなくなっていく。チームワークを支える行動にフィードバックを与えるには、感謝を見える化するプラクティスが有効。KPTに感謝という軸を加え、Tryを決めた後に最後にチームメンバーへの感謝を示すアクティビティをすると良い。チーム内に互いを尊重し称え合う文化も醸成されていく

プロセスのカイゼン例

• プロセスの無駄を見える化するためには、バリューストリームマッピングが有効。開発が始まってからユーザーに届くまでのプロセスを全て洗い出すことで、待ち時間が多いところや、手戻りが発生しやすい箇所が見つけられる

その他覚えておきたいこと

• DX（デジタルトランスフォーメーション）とは、ITを道具として活用するだけでなく、ITによりビジネスや生活を変革させていくこと。これまでのITとビジネスの関係は、もともと人間が行なっていたことをITで置き換えることだが、DXが実現するのはITを前提とした新しいプロセスやビジネス
  • 例：音楽ストリーミングサービス

• 仮説を検証するための、価値を提供できる実用的で最小限のプロダクトのことをMVP（Minimum Viable Product、Viable: 実行可能な）という

• モブプロなどの1人でできることを全員でやったら時間が無駄なのではないか？への回答
• • 隙間時間があって時間を無駄にしていることを懸念するよりも、価値が早く顧客の手に届く流れの効率を大切にしている。人がフル稼働することよりも、開発された成果物を重視している。リリースすることで顧客が利用可能になり、使われて初めて価値が生まれる

• プロダクトバックログの開発可能チェックリスト
• • スプリント内で開発着手できる具体的な情報がある
  • 顧客に価値がある根拠や仮説がある
  • 優先順位で並べ替えられている
  • スプリントで開発可能な大きさに分解されている
  • 見積もられている
  • テスト可能な受け入れ条件がある

おわりに

ここまでお読みいただきありがとうございます。

本書の中では図がたくさん使われており、アジャイル開発の考え方がとても理解しやすかったの、ご興味ある方は是非読んでみてください。

いちばんやさしいアジャイル開発の教本　人気講師が教えるDXを支える開発手法 「いちばんやさしい教本」シリーズ

以下の関連記事を合わせて読むことでアジャイル開発、アジャイル開発の1つであるスクラムについての理解がさらに深まると思うので、ご興味ある方は是非ご覧ください。

ysk-pro.hatenablog.com

ysk-pro.hatenablog.com

ysk-pro.hatenablog.com

【読書まとめ29】学びを結果に変えるアウトプット大全

久々に技術書以外も読みたいな、と思い「学びを結果に変えるアウトプット大全」を読みました。

 

この本に書かれていた次のことがいいなと思いました。

勉強/読書前に何を学びたいかを自分に問いかけると良い。その内容に注意が向くようになり、関連する情報が出た時に集中力が高まる。

この通りに本を読み、その結果をこの記事にまとめます。

学びを結果に変えるアウトプット大全

（読む前）この本で学びたいこと

① アウトプットの効果

② 今日から始められるアウトプットの仕方

 

アウトプットするのが良いというのはなんとなく体感としてありましたが、具体的にどんな良いことがあるのか知りたかったです。

また、息をするようにアウトプットができるタイプではないので、気軽に今日から始めれられるアウトプットの方法が知りたいと思いました。 

 

（読んだ後）この本で学べたこと

① アウトプットの効果

学んだことが定着しやすくなる

脳はインプットしてもその情報を何度も使わないとすぐ忘れてしまう。脳に入力された情報は海馬に2~4週間の間、仮保存される。海馬への仮保存中にその情報が何度も使われると、脳はその情報を重要と判断して側頭葉の長期記憶に移動する。目安として2週間で3回以上アウトプットすると、長期記憶として残りやすくなる

参考書を読むだけで問題集を解かなかったり、技術書を読むだけで実際に手を動かさないとすぐ忘れてしまうという体感と一致し、納得感がありました。

ただ、1度アウトプットすれば良いものでもなく、2週間に3回以上必要というのは思っていたよりも多く、意識してアウトプットしなければ到達できなさそうだな、と思いました。

 

② 今日から始められるアウトプットの仕方

日記を書く

日記は手軽なアウトプットトレーニング。ポジティブ、楽しい出来事を中心に書くことで、日常から楽しいことを発見する能力が高まる。1日10分間日記を書くと幸せになるという研究結果もある

過去日記を書いていた時期はあるのですがやめてしまっていたので、この本を読んで再開してみました。

特に何もないような日でも日記を書くと毎日楽しいことがあると実感でき、この本の通りポジティブになれている気がします。

 

会社で続けている技術書の輪読会を継続する

人に教えることを前提に勉強するだけで記憶力がアップする。教えることで、自分の理解度や不十分な点が明確に見えてくる

 

説明することによって記憶に残りやすくなる。なぜなら、説明することによって意味記憶からエピソード記憶に変換されるため

・意味記憶：apple=りんごのように関連性の薄い組み合わせ。記憶に残りにくい

・エピソード記憶：過去にあった出来事や体験、ストーリーとしての記憶。記憶に残りやすい

会社のメンバー数人で、技術書を1章ずつ順番に説明する輪読会を1年くらい続けています。説明したり議論したりすることで理解が深まったり、記憶に残りやすくなる実感があったので納得感がありました。

 

本を読んだらブログに残す

本を読んでも気づきを書き留めないと自己成長につながらない。現実を変えるためには行動を変える必要があるため、TODOリストを作成すると良い

これまでは特にいいなと思った本・技術書のみをブログに残していましたが、基本ブログを書く前提で読もうと思います。

この本を読んだ上での僕のTODOは、「② 今日から始められるアウトプットの仕方」の3つと「読書前に学びたいことを決めるこの読書法」の計4つを継続し、習慣にすることです。

 

その他覚えておきたいことのメモ

• 理想的な費やす時間の比は インプット：アウトプット = 3：7

• 文章を速く書く方法
• • 時間を決めて書く：締め切りを決めることで集中して一気に書くことができる
  • 先に構成を決める

• ぼーっとしてる状態がひらめきやすい。ぼーっとしている時、脳内では通常の活動時の15倍ものエネルギーが消費されている。空いた時間はスマホで埋めるのではなく、意識的に何も考えない時間を取ると良い

おわりに

ここまでお読みいただきありがとうございます。

これまで何となく本を読んで何となくメモを残したりすることが多かったですが、この本を読んで「明確な目的を持って本を読み、行動を変えるための読書法」に切り替えるきっかけが得られたと思います。

ここに書いたこと以外にも多くの内容が詰まっており、刺さる部分は人によって違うと思うので気になった方は是非読んでみてください。

学びを結果に変えるアウトプット大全

【読書まとめ28】アジャイルサムライ 達人開発者への道

勤務している会社のPJでアジャイル開発を取り入れはじめました。

ただ雰囲気でやっている部分も多く、より効果的にアジャイルを活用するため、まずは体系的に学びたいと思いこの本を読みました。

これから実践していく際にこの本に立ち返りやすいよう、ポイントをまとめました。

アジャイルサムライ――達人開発者への道

 

プロジェクト全般

• ソフトウェア開発の3つの真実
• • プロジェクトの開始時点に全ての要求を集めることはできない

• • 集めたところで、要求はどれも必ずといっていいほど変わる

• • やるべきことはいつでも、与えられた時間と資金よりも多い

• ソフトウェアの64%の機能は、ほとんどあるいは全く使われていない。このことからも、本当に重要なことだけに集中すべき

• アジャイル開発の原則として、ビジネス側の人と開発者は、プロジェクトを通じて日々一緒に働かなければいけない

プロジェクト開始時

• チームメンバーが誰もいないところで合意したことを前提にすると、プロジェクトはダメになる。プロジェクトの開始時点で関係者の認識が揃っていないのは当然なので、プロジェクト開始前に関係者全員でプロジェクトについて話し合うべき。そんな時にインセプションデッキが有効

• インセプションデッキについて
• • プロジェクトを開始する前に聞いておかなければならない10個の質問で構成されている

• • プロジェクトを核心まで煮詰めて抽出した共通理解を、開発チームだけでなくプロジェクト関係者全員へ手軽に伝えるためのツール

• • 作成にあたって、ステークホルダーを巻き込むことがとても重要。インセプションデッキは、「それでもなお、プロジェクトをやるのか？」という極めて重要な決断を下すうえで有用な情報を提供してくれるため、ステークホルダーにとっても役に立つ

• • 仕事場の壁に貼り出しておき、何を作ろうとしているのか、そしてそれはなぜなのかを時々眺めて思い出すとよい

• • プロジェクトの真のゴールは、よくよく話し合い、議論を重ねて理解を深めることでしか浮かび上がってこない

• • プロジェクトの基本的な考え方やスコープ、存在意義が変化してしまったら、全員でもう一度インセプションデッキを見直して、チームの向いている先と、プロジェクトへの理解が揃っていることを確認すべき

プロジェクト運営

• 良いユーザーストーリーの6つの要素（英語の頭文字をとって INVEST と呼ばれる）
• • 独立している（Independent）：ストーリーが互いに独立していると、必要に応じてスコープを柔軟に調整しやすい

• • 交渉の余地がある（Negotiable）：予算などに応じて実現方法を選択することができる

• • 価値がある（Valuable）：顧客が対価を払っていいと思えるもの

• • 見積もれる（Estimatable）

• • 小さい（Small）：1週間や2週間といったイテレーションに収まるようにする

• • テストできる（Testable）：完了の基準が明確になる

• ユーザーストーリーのテンプレート
• • 〈ユーザーの種類〉として、〈達成したいゴール〉をしたい。なぜなら〈理由〉だからだ

• • テンプレートを使うことで、誰が、何を、なぜ、という重要な疑問を明確にできる

• ベロシティはチームとしての生産性を計測する。個人の生産性を測るのは良くない。個人の生産性を測ると、協調しようとか知見を共有しようという気持ちがなくなり、各人が何としても自分自身の生産性を確保しようと躍起になってしまう

• プロジェクトの完了時期の見通しを立てるにはバーンダウンチャートが便利。ただ、バーンダウンチャートだと途中でのストーリー追加がわかりづらいので、途中でのストーリー追加をわかりやすくしたければバーンアップチャートが便利

開発関連

• アジャイルなプログラマが当然のように実践していること
• • テストをたくさん書く。設計のためにテストを活用することも多い

• • プロジェクトの進行中にも、アーキテクチャの設計と改善に継続的に取り組む

• • コードベースをいつでもリリースできる状態にしておく

• バグを見つけたら、修正する前にバグが原因で失敗するユニットテストを書く。こうすることで、同じバグが2度と現れないことを保証できる

• TDD（テスト駆動開発）：以下の短いサイクルを繰り返しながら少しずつソフトウェアを設計していく手法
• • レッド：必要なコードが既にあると考えて、失敗するユニットテストを書く。設計についてしっかり考え、コードの意図をテストで示す

• • グリーン：とにかくテストに成功するコードを書く

• • リファクタリング：実装を見直し、わかりやすいコードにする

おわりに

ここまでお読みいただきありがとうございます。

本書は翻訳本に関わらず読みやすく、アジャイル開発の考え方を理解するのに最適だと思ったので、ご興味ある方は是非読んでみてください。

アジャイルサムライ――達人開発者への道

 本書で学んだことを、明日から1つずつ業務で実践していこうと思います。

以下の記事を合わせて読むことでアジャイル開発、アジャイル開発の1つであるスクラムについての理解がさらに深まると思うので、ご興味ある方は是非ご覧ください。

ysk-pro.hatenablog.com

ysk-pro.hatenablog.com

ysk-pro.hatenablog.com

エンジニア3年目の2020年振り返り

こんにちは。2020年ももう終わってしまいますね。
気づけば、エンジニアになって2年半が経っていました。

去年と一昨年も年末に振り返り記事を書いているので、今年もやってきたことをまとめておこうと思います。

去年の記事：エンジニア2年目の2019年振り返り - 銀行員からのRailsエンジニア
一昨年の記事：エンジニアになって2018年にやってきたことを一覧にしてみた + KPT振り返り - 銀行員からのRailsエンジニア

仕事のことはあまり詳細に書けないので、主に仕事以外でやってきたことを書いていきます。

振り返り記事なので、アイキャッチは振り返ってるうちの猫です。かわいい 😻

個人開発

2つサービスをリリースできました 🎉

楽々ゴルフ

移動時間で絞り込めるゴルフ場検索サービスです。

今年のお正月（約1年前）に、妻と2人で作りました。

「既存のゴルフ場検索サービスでは、自宅からの車での移動時間で絞り込めない」という僕の思っていた課題を解決できて嬉しかったです。

フロントエンドにはReactを初めて使いましたが、妻に手取り足取り教えてもらったのでだいぶ理解できるようになりました。

バックエンドはAWS Lambda（言語はRuby）、API Gateway、DynamoDBでサーバレスの構成にしてみました。

ysk-pro.hatenablog.com

Golf Medley

ゴルフ練習場の口コミサイトです 🏌️‍♂️

「楽々ゴルフを見たのですがこんなもの一緒に作らないですか」というTwitterDMをいただいたのがきっかけで生まれたサービスです。楽々ゴルフを作って公開したことで、このサービスに繋がりました。

現在はゴルフ練習場の口コミ機能のみですが、ゆくゆくはゴルフにまつわる総合サイトにするため、様々な機能を検討・実装中です。これまで僕はサービスを作って終わりというのが多く、継続的に開発している個人開発のサービスは初めてなので、少しずつ良いものにしていきたいです。

開発は妻と僕、機能の検討やデータ入力等は声をかけていただいた方が行う、3人チームで進めています。

技術的にはフロントエンドにNext.js、Typescript、認証にAuth0（JWTトークン認証）、バックエンドにRailsという構成で、Rails以外ほとんど触ったことのない個人的に攻めた構成にしました。

元々フロントエンドはReact SPAで作り始めたのですが、SNSシェアされた時に展開される情報を動的に変えられないことが辛く、SSRができるNext.jsに切り替えました。ページごとにSSR, SSGを切り替えられたり、SSGでも(ほぼ)動的なサイトを実現できたりとNext.jsが便利すぎて驚きました。

golf-medley.com

AtCoder

2019年にハマった競技プログラミングを継続していました。
今年の前半は、ほぼ毎週オンラインでのコンテストに出場していました。

基礎的なアルゴリズムは習得できたと思います。

念願だった水色になってからレートが停滞して、徐々にやらなくなってしまいました。

ysk-pro.hatenablog.com

ysk-pro.hatenablog.com

CTF

CTFとはセキュリティ系のコンテストで、Web、暗号化、ネットワーク幅広い分野が対象です。詳細を知りたい方はこちらがとてもわかりやすいです。
CTF（Capture The Flag）とは？概要から基本ルール、メリットデメリットまで徹底解説

AtCoderと入れ替わりで始めてみました。

主にWeb分野の過去問に取り組んでおり、SQLインジェクションなどで攻撃するのが楽しいですw（そういう問題なので攻撃OKです）

デザインパターンの勉強

2019年から始めたデザインパターンの勉強を継続していました。

Rubyによるデザインパターン を読んで、紹介されている16のパターンを1パターンずつオリジナルのサンプルコードと共にブログにまとめました。

かなり時間がかかりましたが、デザインパターンをざっくり理解することができ、コードの良し悪しが少しずつ分かるようになった気がします。
まとめた自分のブログを見ながらコードを書くことが多くなりました。

ysk-pro.hatenablog.com

仕事

APIを一から作ってパフォーマンスの問題に苦しんだり、スクラム難しいなーてなったり、Kubernetesを触ったり、大きめの障害を起こしてヘコんだり、新しいサービスの技術選定・設計をし始めたりしてました。

現職で2年半以上経ちましたが、メンバーに恵まれているのと、次々に初めて経験する難しい課題が現れるので全く飽きずに楽しめています。

おまけ（プライベート編）

3月からフルリモートになり家の環境整えました

よくあるデスク環境紹介ブログを書いてみました。

ysk-pro.hatenablog.com

広い家に引越して、猫を飼い始めました

リモートワークになり、会社の近くに住む意味がなくなったので、広くて猫飼育可の物件に引っ越して猫を飼い始めました。
めっちゃかわいいです...！

ついに子猫ちゃんがうちにやってきたーーーー！！！

可愛すぎてやばい...！ pic.twitter.com/aG4hcZELlD

— ゆうすけ@育休中 (@ysk_pro) 2020年11月14日

ジムは解約し、家トレを毎日継続してます

コロナの影響でジムに行きづらくなったので、家でトレーニングできる環境を整えました。

ジムは2日に1回行く程度でしたが、家だとすぐに取りかかれるのが楽で毎日筋トレをする習慣がつきました。

筋トレ用のベンチが届いてホームジムが完成したーーー！！

最高！！！！ pic.twitter.com/on5SLNwbeL

— ゆうすけ@育休中 (@ysk_pro) 2020年4月24日

マンガをたくさん読みました

リモートワークになって自由な時間が増えたのもあり、マンガをたくさん読みました。

技術書もそうですが、妻と2人で読めば実質半額でお得です。

僕が今年読み始めたマンガでの個人的なTOP3は、1位：ワールドトリガー、2位：七つの大罪、3位：呪術廻戦 です。

（今Amazonで調べてたらワールドトリガーが2021/1/11まで1巻〜9巻 Kindle版無料で読めるらしいすごい）

ワールドトリガー 1巻から22巻まで一気読みしてしまったー！

おもしろいーーーー！！！#Web本棚 https://t.co/5IYse2MWIy

— ゆうすけ@育休中 (@ysk_pro) 2020年6月9日

妻とゴルフレッスン通い始め、夫婦でゴルフ旅行に何度か行きました

夫婦でゴルフ旅行という、ゴルフを始めた頃の夢が叶いました。最高です。

夫婦でゴルフ旅行という、人生でいつかやりたかったとこを成し遂げて感無量。

ゴルフに興味を持ってくれて始めてくれた妻に感謝しかない。

めちゃ楽しかったので来月も行くぞーー！

— ゆうすけ@育休中 (@ysk_pro) 2020年8月7日

おわりに

ここまで読んでいただきありがとうございます。

今年も色々取り組めていい年でした。

来年は Golf Medley を成長させつつ、興味の赴くままに新しいことに色々チャレンジする1年にしたいです。

ご興味あれば、去年・一昨年のブログも合わせてご覧ください。

ysk-pro.hatenablog.com 

ysk-pro.hatenablog.com

良いお年を！

【読書まとめ27】Atomic Design 〜 堅牢で使いやすいUIを効率よく設計する

個人で開発しているサービスに Atomic Design を採用しているのですが、雰囲気で使っており一度体系的に学びたいと思いこの本を読みました。

Atomic Design やその周辺知識をまとめて得ることができたので読んで良かったです。

後から見返せるように、ポイントを簡潔にまとめました。 

Atomic Design ～堅牢で使いやすいUIを効率良く設計する

Atomic Designとは

• 小さいUIコンポーネントを組み合わせてより大きなコンポーネントを作っていくためのデザイン・フレームワーク

• UIコンポーネントを5つの階層に分類する

コンポーネントベースでのUI開発のメリット

• 再利用性が高い

• 再利用されることで、統一された使い勝手をユーザーに提供できる

• コンポーネント毎に独立しているので、複数人で並行して実装しやすい

• コンポーネント単位でテストできる

• CSSもコンポーネント化することで、他のコンポーネントに影響を与えずにCSSを書くことができる

各階層について

小さい方から1つずつ説明します。

Atoms

• これ以上UIとしての機能性を破壊しない最小単位。使い回しやすいように、抽象的な機能だけを持つように作られる

• （例）ボタン、テキストフォームなど

• （関心事）デザインの統一性

Molecules

• 機能を組み合わせてユーザーの具体的な行動に応える機能の単位

• （例）Atomsのボタン、テキストフォームなどを組み合わせた検索フォームなど

• （関心事）行動を阻害しない操作性

Organisms

• 独立して成立するコンテンツを提供する

• （例）ユーザーの投稿を表示するコンポーネント

• （関心事）ユーザーの行動を促すコンテンツ

Templates

• 具体的なコンテンツを持たないページの雛形。OrganismsやMolecules、Atomsのコンポーネントを実際のページの通りに配置する

• （関心事）画面全体のレイアウト

Pages

• Template層のコンポーネントに実際のコンテンツを流し込んで、ユーザーが実際に触れるもの

• 各ページに1つ作られ、この層は再利用されない

コンポーネントを階層化するメリット

• 全体を考慮する必要がなく、1つの層の関心事に集中できる

• 同一層に属するコンポーネントであれば差し替えやすく、A/Bテストなどもスムーズに行うことができる

• 更新頻度の高い上位層（Pages、Template）のUIコンポーネントの変更が、下位層に影響しない

知っておくと役に立ちそうなこと

• MoleculesとOrganismsの分け方
• • どちらに含めるか悩むケースは多いので、次のような判断基準で分けるのがよい

• • Molecules：独立して存在できるコンポーネントではなく、他のコンポーネントの機能を助けるヘルパーとしての存在意義が強いコンポーネント（単体で見たときに意味が分からない）

• • Organisms：独立して存在できるコンポーネント（単体で見たときに意味が分かる）

• 命名について
• • 命名の基本は「コンポーネントが持っている機能に対して、過不足ない名前をつける」ことであるがとても難しい。以下の命名のサンプルが参考になる

• • Atoms：Button, Image, Text

• • Molecules：SearchForm, Pagenation

• • Organisms：Header, NotificationList

• • Templates：MyPageTemplate, ContactTemplate（Orgainsms層との名前の重複を避けるため、共通してTemplateを後ろにつける方法がよく使われる）

• • Pages：MyPagePage, ContactPage（Template層のコンポーネントに実際のデータを適用したものがPages層なので、Template層のTemplateをPageに変えると分かりやすい）

• ReactはコンポーネントベースでUI開発することに特化したJavaScriptライブラリで、Atomic Designと相性がよいため一緒に使われることが多い

• Storybookを使うと、アプリケーションでどんなUIコンポーネントを使っているのか一覧で見れるコンポーネントリストが簡単に作れる

おわりに

ここまでお読みいただきありがとうございます。

本書ではReactを使った豊富なサンプルがあり、さらにテストにも言及しており学ぶことがとても多かったので、ご興味ある方はぜひご覧ください。

Atomic Design ～堅牢で使いやすいUIを効率良く設計する

この本を読んで、個人開発しているサービスのコンポーネントの分け方で改善したいところが色々と出てきたので、どんどん実践していこうと思います。

自己yieldについて【Ruby】

こんにちは。

最近 メタプログラミングRuby を読み印象に残るところが多かったので、1つずつブログにまとめています。

今回は第2弾で、自己yield についてまとめました。

自己yield とは

Rubyはメソッドにブロックを渡すことができます。
メソッドに渡されたブロックは、メソッド内で yield とすることで実行できます。

自己yield は、メソッド内で yield を使ってブロックを呼び出すときに、yield self としてオブジェクト自身(self)を引数としてブロックに渡すことを言います。

これがどのように使えるのか、サンプルコードを見ていきましょう。

サンプルコード

自己yield を使っていないコードを自己yield を使って書き換えていきます。

まずは、自己yield を使っていないコードです。

class PC
  attr_writer :name, :os, :price

  def initialize(name, os, price)
    self.name = name
    self.os = os
    self.price = price
  end
end

mac_book_air = PC.new('mac book air', 'mac', 150_000)
p mac_book_air #-> #<PC:0x00007fcf05863158 @name="mac book air", @os="mac", @price=150000>

インスタンス作成時にインスタンス変数をいくつかセットするだけのシンプルなコードです。
インスタンス変数が3つだと問題はなさそうですが、数が増えると引数の順番に気をつかう必要が出て分かりづらくなりそうですね。

このコードを自己yield を使って書き換えると次のようになります。

class PC
  attr_writer :name, :os, :price

  def initialize
    yield self
  end
end

mac_book_pro = PC.new do |pc|
  pc.name = 'mac book pro'
  pc.os = 'mac'
  pc.price = 200_000
end
p mac_book_pro #-> #<PC:0x00007f8015017128 @name="mac book pro", @os="mac", @price=200000>

PCクラスのインスタンスを作る際にブロックを渡しており、PCクラスの initializeメソッドでそのブロックを呼び出しています。

ブロックでインスタンス変数をセットしていることで、どのインスタンス変数にどの値を入れているか分かりやすくなりましたね。

さらに、メソッドにブロックが渡されたか判定できる block_given? メソッド を使えば、どちらのインスタンス作成の方法にも対応することができます。

class PC
  attr_writer :name, :os, :price

  def initialize(name = nil, os = nil, price = nil)
    if block_given?
      yield self
    else
      self.name = name
      self.os = os
      self.price = price
    end
  end
end

実際に使われているところ

自己yield が実際に使われている例を見てみましょう。

Faraday

よく使われている HTTPクライアントライブラリ Faraday で自己yield が使われています。

Faraday は次のように、分かりやすく HTTPリクエストを行うことができます。

resp = Faraday.get('http://sushi.com/search') do |req|
  req.params['limit'] = 100
  req.headers['Content-Type'] = 'application/json'
  req.body = {query: 'salmon'}.to_json
end
# => GET http://sushi.com/search?limit=100

このコードは 公式ドキュメント からの引用です。

ブロックを使うことで、クエリパラメータやリクエストヘッダ、ボディに直感的に値をセットすることができます。

Faraday のコード内で yield self が実行されています。

tap

tap はメソッドチェーンの途中で値をチェックしたい場合などに使われるメソッドです。

次のようによく使われます。

a = ['r', 'u', 'b', 'y'].map(&:next).pop
puts a #-> z

# メソッドチェーンの途中で値を確認する
a = ['r', 'u', 'b', 'y'].map(&:next).tap{|x| p x}.pop #-> ["s", "v", "c", "z"]
puts a #-> z

実際の tap はRubyで書かれていませんが、Rubyで実装すると自己yield を使った次のようなシンプルなコードになります。

class Object
  def tap
    yield self
    self
  end
end

おわりに

ここまでお読みいただきありがとうございます。

自己yield は色々なところで使われており、ソースコードを読む際にも必要になるので、知っておいて損はないと思います。

今回紹介した自己yield はメタプログラミングRuby の「付録A よくあるイディオム」に記載されていました。

メタプログラミングRuby 第2版

次回もまた、メタプログラミングRubyを読んで印象に残ったところをまとめていこうと思います。

アクセスメソッドの注意点について書いた前回の記事も是非合わせてご覧ください。
ysk-pro.hatenablog.com