コード日進月歩

しんくうの技術的な小話、メモ、つれづれ、など

『ボトムアップドメイン駆動設計』に行ってきたよメモ

『アーキテクチャ ディスカッション Vol.1のときにめっちゃ事例を話されていたnrsさん独演会的な勉強会であるボトムアップドメイン駆動設計 - connpass に行ってきたのでメモというか感想

発表

大ボリューム前後編の資料

発表メモ

  • エリック・エヴァンス本に関して「パターン」と「マインド」という切り出し方をして、「パターン」の部分に関して実装的な部分の内容をよりぬきでC#のコードに落として説明。
  • ValueObjectはもちろん、リポジトリの説明のためにDependency injection の話にも触れて、実装例やその際に使う実装手法を交えながらわかりやすい順番で話されていた感じ。
  • 最後の話の締め的にはDDDというよりかはレイヤードアーキテクチャ、ヘキサゴナルアーキテクチャの文脈で今日の実装例を締めくくった。

感想

DDDに出てくる実装寄りの話を「パターン」という囲み方でとっつきやすい形に説明されていた感じでした。ただ御本人もお話されていたようにドメイン駆動設計でよく登場するユビキタス言語のような概念部分の話は「マインド」という形で切り分け、そこの理解は実際の書籍を読んでねという感じ分けてました。

この切り方、あんざいゆきさんがDroidKaigiで話したものにおきかえると今回の「パターン」の部分が「戦術的設計」で、「マインド」の部分が「戦略的設計」にあたるのかなという印象でした。

https://2.bp.blogspot.com/-gI5NBeRI2B4/WMDZ1MGfYPI/AAAAAAAAlow/NjR-agnEsNojXft8Eb-KNM1X2SumFe2EACLcB/s320/DroidKaigi2017.046.jpeg

- Y.A.M の 雑記帳: ドメイン駆動設計について DroidKaigi 2017 で登壇しました。 より

ドメイン駆動設計の本質的な部分は今回で言うところの「マインド」のほうがウェイト大きいかなと思っていて、それを実践していく上でモデリング技術力であったり、ドメインエキスパートとのコミュニケーションフロー(ユースケース駆動開発とか)に発展していくと思うので、今日の内容はそういう意味でも「エリック・エヴァンスのドメイン駆動設計の本を読むにあたって、先に知っておきたいプログラミングテクニックガイド」という感じだったなという印象です。

そこに関しては「軽量DDD」という形であるということも発表内でも、Twitterでも発表者ご当人がお話されていました。

上記のような感想を書きましたが、今日の話は面白くなかったとかためにならなかったとかでは全然なく、実際に値オブジェクトやエリック・エヴァンス文脈のエンティティはどう使うのか、ドメインモデル貧血症ってどういう状態なのか、というようなところが順を追って説明されたのでとてもわかりやすく、また実践的に使っているテクニックが落とし込まれていてとても勉強になりました。

ドメイン駆動開発で扱われているこれって、実コードにするとどうなるの?」みたいなときに取り出しやすい資料を作っていただけてありがたいかぎりな感じでした。

(あと加えて書くとするなら、「マインド」の部分のドメイン駆動設計を知りたければもちこ本を読むと、エリック・エヴァンス本を読む前にはいいかもという気持ちにもなりました。)

おまけ

会場で質問したことにかとじゅんさんがレスポンスされており、なるほどなー!と思ったのでメモ

関連リンク

レビューコメントの意味通りを良くするためのヘッダTips

よくコードレビュー事例で『そのコメントの最初に [MUST] [MAY] とかをつけることにより対応の度合いを説明できる』 みたいな事例を見るけど、どういうのがあるのかの事例集。

英語パターン

MUST

必ず直して欲しい部分に関して使う。RailsでいうところのN+1が起きてるよ的な。

IMO(In My Option)

訳すると「私の考え」という訳になる、日本語であれば「提案」「参考」「おまかせ」などが近い表現になる。

NITS(nitpick)

細かい指摘、タイポやインデントミスのようなものに使う。些細なことだけど直して欲しいみたいな気遣い

ASK

質問。単純に疑問やどういう仕様なのかを聞きたいときに使う。

関連リンク

チャットコミュニケーション全盛だからこそのリリース作業の報連相を考えてみた。

自分の中のノウハウ的なものをアウトプットしよう的な雑記です。

この記事で言うリリース作業

Webアプリケーションには往々にして『環境』が分けられており、実際に利用ユーザが触れる『本番環境』、それに準じた内部関係者が利用する『ステージング環境』などがありますが、それぞれの『環境』に対してリリース作業というものがあります。

リリース作業というのは開発を行ってきたアプリケーションコードを反映させ、動ける状態に持っていくまでのことを指すことがだいたいで、2018年現在では『デプロイ』と呼ぶことのほうが多いと思われます。(参考

今回はこのリリース作業をする上での報連相に関して。

リリース作業における「報告・連絡・相談」

リリース作業そのものは何かのアクションを伴います、例えば

  • リリース手順書に書き起こされた手順を順に実行していく
  • Jenkinsに仕込まれたワークフローを実行する
  • AWS CodeDeployなどクラウドのソリューションを利用する
  • capistranoDeployer などのデプロイツールを使う

様々な手法があるが、何か順番に行っていくということには代わりがないかと思います。

ただしこれらの作業の前にそもそもとしてリリース作業を行うことで影響がでることがある。例えば「作業中はアクセスしないでください」などです。実態の作業ビジネス上のステークホルダーにも作業に関しての状況ちゃんと伝える必要がある。そこで今回はそれを報・連・相の形で噛み砕いてみましょう。

連絡

リリース作業に置ける報告は行動の事前周知にあたります。

大きなリリース作業ともなれば、事前にオペレーションのタイムスケジュールなどは共有されているはずだと思われます。そのときの行動をするまえに関係各所に周知をする必要があります。

例えば…

  • 19時になりましたので、本番環境で作業を始めます
  • サイトをメンテナンスモードにします。終了は20時予定です。
  • 本番環境にソースを反映しました、社内からであればアクセスできるようにしたので確認お願いします。

のような事項をメールやチャットで行うことです。

これを行うことにより、作業者が作業をしているのか、何かトラブって作業が中断してしまっているのかなどを気づくことができるかと思います。

報告

リリース作業における報告は進捗報告にあたるものです。

連絡は作業開始の宣言だとすれば報告は作業の終了などにあたり、作業が滞りなく進んでいるのか、現状として進捗しているのかを知らせることです。もちろん全ての工程が終わった場合も知らせる必要があるかと思います。

例えば…

  • DBのリセット作業は完了したので次工程に移ります。
  • 19時ですが、まだ前工程の作業が長引いているので次工程には移れていません
  • 作業終了し、確認取れたので本日の工程全て終了しました。

のような事項をメールやチャットで行うことです。

これらも連絡の内容同様に関係者への状況をリアルタイムで伝えることができます。仮にリモートワークをしている状況の場合ではオフィスでの空気や会話で伝わる進捗状況のようなものが伝わらなかったりするので、この報告をこまめにすることが大事かなと思われます。

相談

リリース作業における相談は有事の際の相談にあたります。

作業がある程度手順化された中で、作業に想定外のことが発生することがある。その場合はそのまま作業を続行していいか、もしくはリカバーの何かをするかを判断しなければならない。そういう場合は関係各位に対して相談を投げかけるのがベターかと思います。。

例えば…

  • DBの初期化が失敗してしまいました、同じことを再度やるべきでしょうか?
  • 実行した際のログが手順書に書かれているものと違いました。このまま続行していいでしょうか?

などがある。特に2つ目のような期待値と違うことが起きた場合に然るべきところに確認をするのが、二次災害、惨事災害を避けるために重要になってくると考えられます。

チャット全盛におけるリリース作業の連携

報連相で一番伝えたかったのは「現在の状況をつつがなく周知して、トラブったときはすぐに相談する」という側面です。

これが同じオフィスにいれば口頭ですぐに伝えられたりするのですが、物理的にはなれたチャットで連動する場合などは事細かにやることが重要かと思っています。

ことトラブルが起きたときこと報告/連絡の部分が重要になってきて、良かれと思ってリカバリー作業を2人が初めて二次災害が発生したりすると悲しい結果になってしまいます。

そのため、離れているからこそ、事細かな連絡と状況の共有は大事になってくるかと思います。

まとめ

  • リリース作業では報連相(状況報告・進捗連絡・トラブル時相談)をしっかりしましょう
  • 現場の空気感みたいなもので伝わるものはチャットだと伝わりにくいので、そこをカバーするためにも細かめに共有はしましょう

参考リンク

デフォルトのRailsログで突き合わせ用のIDとして使われているのはリクエストヘッダのX-Request-ID

Railsログの先頭に一意のIDが出てるなー、きっとよしなに何か振ってくれているんだろうなーとか思ったら違った。という話。

環境

rails (5.2.0)

やっている設定

enviromentsのこの記述

# Prepend all log lines with the following tags.
config.log_tags = [:request_id]

request_idの出元は、というとActionDispatchのRequestIdの記述

def call(env)
  req = ActionDispatch::Request.new env
  req.request_id = make_request_id(req.x_request_id)
  @app.call(env).tap { |_status, headers, _body| headers[X_REQUEST_ID] = req.request_id }
end

rails/actionpack/lib/action_dispatch/middleware/request_id.rb

nginxなどが X-Request-ID をつけてくれていたりするので、それがある場合はnginx側のログとの突き合わせも可能になる

参考URL

詳しく挙動を知りたい場合は以下のリンク参考のこと。

bashで環境変数をexportせずにシェルスクリプトを実行したい場合はコマンドの前に記述することで代替できる

実は最近まで知らなかったのでメモ。

環境

$ bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin17)
Copyright (C) 2007 Free Software Foundation, Inc.

やり方と例

こんな感じでシェルスクリプトを用意する

$ cat test.sh
echo hoge is $HOGE .

HOGE に何も設定されていないので実行すると何も出ない

sh test.sh
hoge is .

コマンド実行前に文を入れると成立する

$ HOGE="Set All Right" sh test.sh
hoge is Set All Right .

複数設定もできる

$ cat test.sh
echo hoge is $HOGE . huga is $HUGA
$ HOGE="Set All Right" HUGA="xxx" sh test.sh
hoge is Set All Right . huga is xxx

ただし実行するシェル自体には反映されないので注意、下記の例だとセットされていないので何も出ないことがわかる。

HOGE="Set All Right" echo hoge is $HOGE
hoge is

参考リンク

シェル 一時的な環境変数を渡す方法csh/tcsh/sh/zsh/bash - sh系だけでほかは書き方が違う

『銀座Rails#2』に行ってきたよメモ

JokerさんのActiveRecordの話が聞きたくて銀座Rails#2に行ってきたよメモ

各発表の感想

※資料スライドは見つけたら貼ります。


カンファレンス型 技術イベントの作り方 〜Rails Developers Meetup の辿った道〜

感想

  • カルパスさんのRailsDM開催に至るまでに得た経験や知見が惜しげもなく発揮されたスライド
  • どんどんRailsDMが大きくなっていく経緯は物語性強すぎてちょっと目が潤む
  • 本当に自分の気持ちだけでつく割と本気で勉強会の運営ってやってみたいなという気持ちになった
  • 本当にカルパスさんの前座パワーは毎回すごいなと思ってたし、ああいう温め方できるひとがいると喋る人も楽だとすごい思う。

関連リンク


Swagger (OpenAPI 2.0) を使ったAPI仕様Drivenな開発

スライドリンク

感想

  • Swagger活用事例
  • 結構いろんなツール使っている事例が豊富で、Rubymineのプラグインとか、committeeとかは初めて聞く治験だった
  • コピってモックアプリとしてしまえばいいじゃんというのは目から鱗。確かに感すごかったのでこれは活用していきたい。

関連リンク


ActiveRecordだけで戦うには、この世界は複雑過ぎる

スライドリンクは出たら張ります。

内容メモ

  • ARだけでは大変な部分をどう戦いぬくかという話
  • 前半はモデルの話、RDBではないデータリソースを扱うのにActiveRecordは使いにくいので、Structを使う例などを紹介
  • 後半は大量のデータ取扱の話、レコードに対してオブジェクトを作るARはRDBの得意分野とする大量データの取扱は不向きなので、Railsにおいて生SQLを活用していくかの事例を紹介、更にそこに重ねる形でバッチ技術のトレンド紹介があった。

感想

  • ARだけでは大変な部分をどう戦いぬくかという話
  • Structは全然発送になかったのでなるほどなという感じ。
  • ARで生SQLをどう扱うかというところでselectとかならよく聞くが、SQLをERBに起こしてテンプレ化するってのはできるんだという気持ちに。
  • Fargateの有効活用を気にしている民だったのでwrapbox便利そう!って思った。
  • ちょっと資料が公開されたら噛み砕いて読み直したい。

関連リンク


全体を通しての感想

  • 今回どのスライドも全然違う側面で勉強になったし、自分の知識補填としてもよかった。
  • エモさと感動という意味ではカルパスさんのスライドがすさまじかったし、昨今の成長系話と重なって相乗効果倍
  • swaggerの話は無理をしないがきっちりと合わせていく使い方の話でswagger-blocksを使っている現場を改めたいなと思った感じ。
  • 最後のActiveRecordの話は昨今のマイクロサービス文脈においてデータソースが変わりまくるし、モデリング的にもActiveRecordがあてはめずらいものが出てくると思うのでそういう複雑さと戦うという意味ではすごい役に立ちそうな知見だった。
  • 勉強会やりたい。

Confluenceのエディタは { でマクロのショートカット入力ができるし、{ code } でコードスニペット領域が作れる

コードスニペットを書くためのコードブロック領域に関して、意外とみんな知らなかったのでメモ。

コードブロックマクロとは

マークダウンでやるところの ``` で囲む表現あたるものとして「コードブロック」のマクロがある。

f:id:shinkufencer:20181017235920p:plain

↑のような感じで表示できる。

作り方

マクロ一覧から選択するのも方法としてはあるのだけれど、一番カンタンなのは 『{』を入力させる方法がある。百聞は一見にしかずなのでスクリーンショットを乗せる。

f:id:shinkufencer:20181017235458g:plain

カスタマイズの仕方

ただ、このままだと白地の背景に白の領域というすごく見づらい状態になるので言語の構文強調や、色替えは「編集」から行える

f:id:shinkufencer:20181018000012p:plain