#しがないラジオ sp. 60に出演しました

2017年に開始され、現在100エピソード以上投稿されている技術系ポッドキャスト「しがないラジオ」にゲスト出演いたしました!

「出れるポッドキャスト」と謳っていますが、実際出れましたのでそのあたりを記載します。

なぜ出たいと思ったか

これについてはエピソード内でも語っているので補足的に。ポッドキャストの開始以来、いつか出たい*1と思っていたことや、出て話すだけのネタが集まったと思ったことです。

ラジオを盛り上げたいとも思っていて、その最も有効な手段がゲスト出演だった、というのもあります。

出演の流れ

出たいと言う、これだけです。

Slackでメンションを飛ばして出演希望を宣言しました。

f:id:alek3:20190520225802p:plain

1分かからずOKの返事が来た*2ので本当に出れるラジオなんだなと思いました。

宣言時は若干緊張しましたが、後から振り返るとどうってことないのでさっさと言ってしまった方がいいです。

日程調整

出演希望者が結構多いので先になるのかなと思っていましたが、たまたまGWが空いていたのでそこになりました。2週間後くらいの日程でしたが、そのときで6月くらいまで毎週収録が入っていました。

出演

ツクルバさんの会議室をお借りして収録しました。

最初は緊張しました。また、慣れてきても、2人が話しているところに割って入りづらく、結果として自分が話す時間が短かったかな?と思いました。

ただ、私自身はゲストがずっと話すよりも、パーソナリティの2人の考えを聞いてみたいという思いがありましたので、結果としては予定通りでした。

他に感じたのは準備の大切さです。何を話したいか考えたり、メインテーマについては自分の中で掘り下げることがもっと必要だったなと思いました。

公開

収録から2週間足らずで前半が公開、翌週に後編が出ましたので、スピーディーに出していただけたと思います。

自分の声を聞くのは最初非常に辛かったです。しかしそのうち感覚がマヒして慣れていきました。

まとめ

1年後くらいにまた出たいですね。まずは本業でサバイブできるように頑張ります。

*1:と思っていたからネタ集めをしていた

*2:正確には20秒

#genbadeDDD 「レガシーをぶっつぶせ。現場でDDD!」参加しました

こちらのイベントに参加しました!

genbade-ddd.connpass.com

気づいたときには無料参加枠は埋まっていたのですが、ブログ書きます枠が新設されたので、1人目として申し込めました。

以下の記載では基本的には登壇者が話したことを常体で書き、自分の感想とかは敬体で書いています。

登壇者の発表内容の記載がものによって全然違うのは、私の理解力の他に、スライドが公開されるかどうか知らなかったこともあります。結局全部公開されたのですごい。

前置き

イベントの説明にある「技術的負債が社会問題に!?」の内容とほぼ同様

ソフトウェアの核心にある複雑さに立ち向かう

株式会社ギルドワークス 増田 亨

www.slideshare.net

ドメイン駆動設計でなぜつくるのか

  • 動かした後も成長を続けられるようにする
  • ソフトウェアの変更を楽で安全にする
    • コスト・スピード・セキュリティにプラスに作用する
  • 技術の新しい古いは関係ない

「核心にある複雑さ」とは何か

  • ソフトウェア開発では色々な複雑さがある

  • ドメイン駆動設計で重視している複雑さは?

    • ドメイン:ユーザーの活動、ビジネスそのもの、複雑さの源泉
  • ドメインロジックとは何か?

    • →具体的にとらえると、ビジネスルール
  • ビジネスルールを適用する条件によってさまざまな分岐がある

    • そのため、複雑化する
  • ビジネスルールをドメイン層に切り出すと、入出力は面倒だけど複雑ではなくなる

    • したがって、変更が安全になる

その複雑さにどう立ち向かうか

  • 関心の分離の工夫
  • モジュールの構造の工夫

  • 従来のモジュール構造とビジネスルール

  • 計算から入出力を隔離する

    • 例えば、計算結果オブジェクトと、出力(画面、JSON、データベース)は分ける

上記二つの工夫がどのように違うのか、あまり理解できていないところがありますが、どちらにしても複雑さに立ち向かいやすくするための工夫なのかなと解釈しています。

本格的に立ち向かう

  • 深いモデルを探求する
  • ビジネスルールの中核を見定め、中核に集中する
  • ビジネスルール全体の関係を俯瞰的に整理する

エヴァンス本は、第1部~第4部からなる。第1部、2部は入門編で、本格的に立ち向かうなら第3部を読むとよい。

抽象的な教えを試行錯誤しながら解釈した DDD の実践レポート

ほげさん

www.slideshare.net

抽象的な話が多くてまとめづらかったのですが、 P36、37のところは、何となく理解できて、重要なところは依存関係が本当に必要なのか考えることと、変更の巻き添えを食らわないように、抽象化することなのかなと。

DDDサンプルコード ライブリファクタリング

関西Javaエンジニアの会 irof

株式会社ギルドワークス 増田 亨

後ろのほうにいたので何書いているかは具体的に見えませんでしたが、まあ後でコミットしてくれるでしょうということで。

レポジトリ github.com

動くアプリ

https://isolating-the-domain.herokuapp.com/

このIssueに取り組んだ。

従業員登録手順をcordinatorパターンに · Issue #101 · system-sekkei/isolating-the-domain · GitHub

Issueの内容としては、コントローラーの中で複数のサービスを呼んでしまっているから、コーディネーターパターンを用いて、コントローラーからみてシンプルにしたいということ。

Jigで出力するソースコードの可視化していて、議論に役立っていました。Jigは↓

github.com

他にもいろいろやっていました。パッケージの関係図を見ながら、依存関係が正しいかどうか議論をしていました。

コミットは以下の「賃金パッケージを導入」~「EmployeeRecordCoordinator導入」までです。

https://github.com/system-sekkei/isolating-the-domain/commits/master

劇的ビフォーアフターBIGLOBEのDDDの昔と今〜

ビッグローブ株式会社 曽根 大作

DDDとの出会い

  • 独自言語*1の世界、マニュアルはExcel、どこに置かれているか分からない
  • 2013年にJavaが導入された。DDD・Scrumで開発
  • のれんわけ方式での拡大計画
    • ある程度チームが成熟したら、分裂し、新しい人を加入させる

ビフォーアフター①モデルの書き方

改善前

名詞ベースのみのモデリング。 情報が足りない、責務・関連依存・多重度などが欲しいという問題があった。

改善後

3つのモデルを作成するようにした。

  • 概念モデル
    • 依存を書く
    • イメージは世界地図
  • コンテキストマップ
  • ドメインモデル
    • ふるまいを記載する
    • イメージはナビゲーション

ビフォーアフター②状態の表し方

改善前

ひとつのエンティティにすべてのイベントがぶら下がっていた

例えば、契約エンティティに、申し込み、解約、その他もろもろが全部入っている状態だった。

すると、エンティティが肥大化してきて、実装時に本来関係ないイベントまで意識する必要が出てくるようになってしまった。

改善後

状態ごとに必要な要素のみを持ったエンティティを生成するようにした。

例えば、ファクトリやリポジトリに渡して書く状態のエンティティを作成、永続化した。

すると、エンティティの責務がはっきりするようになった。

不要なメソッドやフィールドがなくなり、変更やテストもしやすくなった。

ビフォーアフター③チェック

様々な業務ロジックをどのように表現するかについて

改善前

アプリケーション層にもロジックが記載されていた。

可読性が低くなる、テストが複雑になる、ドメインモデルに表現することができないという課題が生じていた。

改善後

ドメイン層にチェックに必要な業務ロジックを集約することで、上記の問題を解決した。

実録!LOHACOにおけるDDDとCleanなArchitecture

アスクル株式会社 佐藤 大典、中村 俊之

前半(抽象的な話)

LOHACO*2は巨大なモノリシックとなっている状態だったが、そこから変更のしやすいシステムを目指した取り組みを紹介していました。

ユビキタス言語のところについて、実際どうやったらよりうまくいったか*3というところは聞いてみたかったですね。

ビジネス側とのやり取りが必要な分野だと思いますので、うまくいった場合の応用はかなり幅広く利きそうです。

後半(具体的な話)

Maven multi-moduleについては、気をつけようという感じでもなんとかなる気もしますが、仕組みで強制するメリットもあると思います。

あんまり関係ないですが、レガシーDB対応はそれ一つでかなり大きな知見なんじゃないかという感じがありますね。

ビジネスルールの複雑さに立ち向かう実践技法

株式会社ギルドワークス 増田 亨

www.slideshare.net

スライド番号に付随して補足を記載します。

8

  • 右が戦術、左が戦略
  • すべてのプロフェッショナルになれというわけではないが、第1象限の能力を高めようとしたら、他の象限についても補強しないといけない

11

「私は型原理主義者なので」とのこと。

17

汎用型とはint型など 楽で安全、というのは、制約がかかっていることによる。intとかだと何が入っているか分からない。

23

種類を限定すると、境界値テストがほとんど意味をなさなくなる。

34

むちゃくちゃ細かいロジックになってくると、マニュアルを読むだけではなく現場に聞いてみないと分からないことがある。

44

SEの領域といった印象。本自体は難解らしい。

感想

前半のプレゼンでも感じたことですが、非常にメモが取りやすいです。例えば資料内では表や箇条書きになっていることでも、それについて論理的な構成立てで話してくださるので、自分の中に入っていきやすいです。

全体まとめ

レガシー改善というのは最新技術で華麗に解決するというものではなく、地道な取り組みで成果を積み重ねていくものだと思います。

非常に複雑なビジネスロジックに対する戦いは、いつまでもなくならないと思いますが、逆に知見も豊富になりうると思います。これからも頑張っていきたい。

*1:xmlベースの何かという話だった

*2:アスクル保有するECサイトドメインが単純なECサイトより複雑

*3:もしくは必要なかったか

レビュー『チーム開発1年目の教科書』

技術書典には参加していませんが、こちらの書籍を読みましたのでレビューします。

マインドセット

チーム入りたて、チーム開発も初めての自分が、1日でも早く価値を生み出せるようになるにはどうすればいいか?という問いから始まっています。

その中で本書が主張しているのは、コミュニケーションであったり、情報の整理であったりします。

情報整理の効率化については、Markdownを取り上げてかなり掘り下げられています。

コードを書くのも価値創造ですが、情報の整理(あるいはその効率化)も価値を生み出していると思います。

スコープの絞り込み

似たようなタイトルの商業書籍に『チーム開発実践入門』というのがあります。

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

ざっくりいうとそこで取り上げられているのは、バージョン管理・チケット管理・CI・CDです。

体系的に学ぶことができますが、分量も300ページとそれなりです。

一方、本書ではチケット管理以降をバッサリと切り、100ページ強に抑えることができました。   これはスコープの絞り込みによるもので、「1年目」ならGitの把握の方が優先だということでしょう。

論理の省略

Markdownを取り上げるにあたって一つ気になったのは、論理の省略です。

どういうことかというと、例えば私は今のプロジェクトでドキュメントはワードやエクセルで書いています。

すると、Markdownが活躍する余地はありません。なぜなら対応していないからです。

なので、「ドキュメントは何処に、なんのソフトウェアで書かれるべきか」という説明があると「なぜMarkdownを身につけるべきなのか」という問いについて、納得感が出てくると思いました。  

その他

誤字がいくつかあったので、どこかで指摘しようかなと思っています。

[AWS][EC2][Windows Server 2019]同サブネットグループ内で、pingが通らないときに確認すべき2点

タイトルのとおりです。

複数のWindows Serverインスタンス間で通信を行おうとしたのですがうまくいかず、そもそもpingも通らないことに気づいたものの、対処に少々時間がかかったのでまとめます。

ちなみに、以下で説明する確認ポイントはpingの受け手側が対象です。

セキュリティグループの確認

VPCにはデフォルトのセキュリティグループが用意されていますが、対象のEC2インスタンスがそのグループに所属していることを確認してください。

↓こんな感じのグループです。

f:id:alek3:20190427111843p:plainf:id:alek3:20190427111853p:plain

※追記:これは、このセキュリティグループに所属するインスタンスからのインバウンドトラフィックを許可するものです。

VPC のセキュリティグループ - Amazon Virtual Private Cloud

Server内のセキュリティ確認

これだけだとつながらない場合は、Windows Serverのセキュリティを緩めます。

メニューから、「Windows Security」にアクセスし、ファイアウォールの設定画面を開きます。

f:id:alek3:20190427112120p:plain

このうち、Private NetworkのFirewallをオフにします。

f:id:alek3:20190427112218p:plain

ping確認

通りました。

f:id:alek3:20190427112548p:plain

株式会社カサレアルの、初心者向けSpring 5 ハンズオンを完了した

以下のSpringハンズオンをやりきったので報告です。非常におススメです。

qiita.com

私がこれを知ったのは去年12月のJJUG CCCでしたので、ようやく重い腰を上げて実施したわけです。

よいところ

  • 無料

  • すぐ終わる

3時間あれば全部のハンズオンを一通り終えることができます。*1

  • Springの基本的な全体像が分かる

Springを始めよう、またはSpring案件に入ったけど何が何だかわからない、という人には非常に有用です。

  • ハンズオン後に「その次やるべきこと」が示されている

実は講義編としてのスライドも用意されています。

www.slideshare.net

その中で、さらに学びたい場合の参考書籍が紹介されています。

学んだこと

Springは簡単なレベルで雰囲気で使っていましたが、今回のハンズオンでいくつか学びがありました。

「HogeHogeのBeanを、コンストラクタでDIする」という言い回し

あるクラス内で、とりあえずコンストラクタ周辺で以下のような記述がよくあります。

    // Fugaクラス内
    private final Hoge hoge;

    public Fuga(Hoge hoge) {
        this.hoge = hoge;
    }

今までは雰囲気で、「ここはBeanを使いまわしているからインスタンスを新しく作成する必要がないんだな~」くらいにしか思っていませんでしたが、

これで何をしているかが言葉で説明できるようになりました。

@Validatedアノテーションと検証用アノテーションの存在

フォームから入力された値に関するバリデーションはどこでもやると思いますが、コントローラーの各メソッドの引数に@Validatedを付与し、サーバーサイドのフォームを構成するプロパティに@NotBlank, @Length, @Emailなどのアノテーションを付けてチェックができることは初めて知りました。

ハンズオンの例にもあるように、ステートレスなバリデーションで使うのがいいかもと思いました。

その他

次はこれを読んで、さらに理解を深めたいと思います。

*1:IntelliJ IDEAやEclipseのインストールから始めるなど、まっさらな状態から環境構築するとなるともう少しかかる

ABC124感想

2週連続で参加しました。

atcoder.jp

A感想

同じ場合と違う場合で場合分けすればよさそう。3分でAC。

B感想

螺旋本の最初に乗っている例題とだいたい同じもの。5分でAC。

C感想

010101…か101010…の2パターンしかないのでどっちかを計算すればよい。 もう片方は文字列の長さから引けば算出できる。 12分でAC。

D感想

問題文を読み違えていて、気づいたのが30分後くらいだったのでそのままギブアップ。とはいえ読み直しても無理でしたね……。

Dは問題文もそれなりに複雑な気がするので焦らずじっくり問題文を理解すべきと思いました。

全般感想

20分でCまでACできたのは満足。Dはこれからですね。

D解きなおし

解説のPDFを読んで方針を確認して実装しました。方針がわかれば実装は素直にできる気がします。

Submission #4969555 - AtCoder Beginner Contest 124

D問題は、以下の3つを考えるのが大事だと思いました。

おまけ

最近勢いがすごいんですけど何があったんでしょうか?

ABC123感想

AtCoderのテストを久しぶりに解きました。

atcoder.jp

どれくらい久しぶりかというと、この記事を書いたときぶりで、今年に入って初です。

alek3.hatenablog.com

結果

A~Cの3完でした。Cにてこずりすぎたかなと思いつつも、自分にとっての最低ラインである3完は死守したのでよしとします。

A感想

最近のAの中だと割と難しい気がします。3分でAC。

B感想

料理の注文時間の1の位に着目すればよいが、それを完全に理解するのにやや時間がかかりました。 10分でAC。

C感想

ボトルネックとなる一番輸送能力の低い交通機関にのみ着目すればよいということはパッと見で分かりました。

しかし、割り切れる割り切れないの場合分けを忘れていて、3WAを出してしましました。

10分で最初の提出、そこからACまで25分かかりました。

D感想

本番中は、実装方針を考えましたが、アルゴリズム書けなさそうとみてギブアップ。

解説のPDFを見て、方針②なら簡単に実装できそうと思い、改めて解きなおしてみました。

Submission #4880342 - AtCoder Beginner Contest 123

秒数はギリギリでしたが、一発AC。

解法①や②はアルゴリズムをほとんど使っていませんね。それでもDが解けるかもしれないと判明したのは収穫でした。

今後に向けて

6月末*1までに、

  • Rate800↑
  • ABC4完

を目標に頑張りたいと思います。

アルゴリズムはこちらで勉強していきます。

蟻本で挫折したのでもう少し簡単そうなものにしました。

ちなみにIDは「alkwest」です。なんでこんな名前にしたかというと、alekからちょっと変化を加えたかったからです。正直かなり名前変えたいですが、チャンスが1回しかないそうなのでまだいいかという気持ちです。

*1:時期に意味はないけどあんまりダラダラやっててもしょうがないということで