だらだらと思いついたこととか書くブログ

エンジニア的なネタとか備忘録とかを書いていく予定

豚バラ肉と春キャベツの塩蒸し

豚バラ肉と春キャベツの塩蒸しに挑戦してみたのでその記録

作ったもの

  • 豚バラ肉(ではなく、正確には豚の薄切り肉)と春キャベツの塩蒸し

成果・結果

  • 今回はさほど難易度が高くなかったこともあり食べれるものが作れた。
  • 材料や調味料も白ワイン以外は普段、家においてあるものでさっと作れるので、今後も御飯作る時のレパートリーに一つにしたい

感想・反省

  • 最初は深めのフライパンで作ろうとしていたが、妻のアドバイスで鍋で作ったのが大正解だった
  • ルクルーゼは熱伝導率が高いので、今回の用途には 適さない → 他のものを作るときでも熱伝導率が高いので焦げやすさなどには注意
  • 野菜から出てくる水分がそんなに多くなかったので、ワインの量を多くするか、もしくは水を少しいれても良かったかもしれない
  • 最初は火を強めすぎて下のほうが少し焦げてしまったのは今後気をつける
  • 今後はそれなりに食べれるものが出来たときは写真を取って、記録と自己満足感を高められるようにすると良いのかなと思った

自分のゴハンを作ってみる

自分のゴハンを作ってみる その1(その2があるかどうかは未定)

今日は妻が遅めの美味しいご飯にお呼ばれされて夕飯がいらないということで、自分のゴハンを用意するべく出来ない料理について挑戦しました。

今日、挑戦してみたのは以下の2品

1.ほうれん草とニンジンのナムル
2.たらのムニエル

1.ほうれん草とニンジンのナムル

結果としては基本的に野菜を切って、温めて、タレと絡める。 なので、大きな失敗のしようもなく、何とか出来ました。 ただ、味が少々薄めな気が・・

分量について

ほうれん草1袋、とあったので素直にその通りにしていたが、
自分が買ってきたほうれん草はちょっと多めだったように感じていたので、切る前に多いいかな、と思った時点で減らすべきだったと思う。
この結果、タレも分量通りだと全然足りなく、最後の味の調節でミスったと思う

ニンジンの千切り

レシピを見ていた時は、ハイハイ、千切りね。と余裕こいていたのですが・・
自分が野菜の切り方すら分かっていないレベルであることを、ニンジンを前にするまで忘れており、ここは妻に教えてもらいながら対応。
ウチのやり方では、

* ニンジンを適度な長さに分割  
* 分割したニンジンを立てて薄切りにする  
* 薄切りにしたニンジンを重ねて線状に切る

なんか、基本、太めになってしまうので、色々やり方や工夫はあるのかもしれないけど、とりあえずこの方法をできるようにしないことには始まらない。。

タレ作り

これは美味しいだろう、というようなものばかり混ぜているので、間違えるとすれば濃すぎるか、薄すぎるかのどちらからで今回は後者だったように感じる。 ただ、味見の時点ではしょっぱかったので、多分、混ざり切っていない。が正解なんだと思う。

今回の敗因としては、まずど初心者なので分量をちゃんと量りながらやるべきだった。適当なスプーンでなくて計量スプーンでちゃんとやる。

あと今回感じたのは、ゴマって彩り、見た目や味を多少ごまかす的な要素で使っているもんだと思っていたが、今回みたいに何かをませる時の混ざり具合の目安としても役立つという発見があった。

2.たらのムニエル

もうこれは結果から言って大失敗。
身が崩れ、味のつき方もイマイチで、まあ残念なものとなってしまった。ごめんなさい・・

小麦粉少なかったか

小麦粉が少なかったように思う。ただ、あくまでそんな感じがした、と言う程度なので定かではない

最初の焼きが足りなかった

最初にしっかり焼いておかないといけないのだが、焼きが甘く、結果として火の通りが甘い感じで出来上がってしまった。ここは大反省の1つ

タラを半分に切っておくべきだったっぽい

身が崩れてしまって、見た目もよろしくない感じになってしまった。妻のアドバイスでは身を半分にするなどしておけば崩れなかったのでは?と言うことだったので次回気をつける

フライパン選びが良くなかった

家にはサイズ的に小・中・大のフライパンがあって、今回は中を選んだが結果、これが大きな失敗だったと思う。 最後は焼いたタラの身をタレで煮詰める感じになるのだが、フライパンが大きく煮詰める感じにできず、うまく味が付かなかったのが大反省の2つ目。

ただ、ここには前述の小麦粉の分量や、タレの分量の甘さ、火加減をちゃんとしてなかった、など色々とよろしくない点があっての結果だと思うので、フライパンはあくまで要因の1つだと思うけれど、せめて小を選んでいればもうちょっと何とかなったかも、と思うと残念でならない・・

全体

とりあえず簡単なおつまみ的なものは今後もちょっとずつ挑戦して、包丁の使い方や料理を進めていく上での手際、整理の術を身につけて行こうと思った。
また、小麦粉を使う料理やムニエル自体が初挑戦だったので、失敗はしたが良い経験だったと思うので、今回の反省を生かしてまた挑戦したい。

コードで理解するDDDの戦略的設計・戦術的設計のつながり勉強会メモ

だいぶ経ってしまったが8/4(土)にDDDの勉強会に参加してきたのでその時のメモまとめ 講師は現在ビズリーチに在籍されている松岡さんで、自分も本人とは気づかぬうちにDDD関連の調べ物をしている際にブログを拝見させていただいたことがある方でした。 当初の予定よりも30分延長してくださり3時間半の長丁場で内容の濃い勉強会でした

DDD

まずは原典にあたってみるのが良い https://domainlanguage.com/ddd/reference/

設計したモデルとコードを一致させる モデルと実装の変更に耐えられる設計でないといけない -> これを実現するのが戦術的設計

モデルとは

対象領域の特定の側面を表現し、関連する問題を解決するために使用する対象物 ユビキタス言語でモデルを表現する

知識

問題領域の知識(Why,What)

お客さんの業務 ユーザのニーズ 市場 ->聞く、情報収集をする、フィードバックをもらう

解決領域の知識(How)

ツール、ライブラリの使い方 コード文法 ->実際に試して得る

境界づけられたコンテキスト

特定のモデルが適用される境界

戦略的設計

コンテキストを定義、再配置するなど?

戦術的設計

構成的にやりやすい形にするための設計?

アーキテクチャ

レイヤードアーキテクチャ

3層アーキテクチャなど Infra層がAppやDomainに依存する -> DBを差し替えたりなど出来ない

ヘキサゴナルアーキテクチャ

オニオンやクリーンはこれの派生 ポートとアダプターで外部サービスとやりとり? 外側は交換可能だが、中心はそんなに変わらない

オニオンアーキテクチャ

infra層が一番上に持ってこられるアーキテクチャ -> infra層がAppやDomainに依存しない マイクロサービスなどで用いられている(サービス同士のhttp通信などはinfra層同士のやりとり) https://dzone.com/articles/onion-architecture-is-interesting

クリーンアーキテクチャ

ドメイン

ドメインサービス

ドメインサービス

個体で扱えない、集合体で扱うものなどに利用(部屋の空き時間を知る場合は各予約単体では分からないため予約の集合体から空き時間を確認する必要がある) ただ、極力使わないようにするべき

ファクトリ

ドメインモデル

エンティティ

可変 IDを持つ IDで比較する 1テーブルに相当

値オブジェクト

不変 IDを持たない 値で比較する テーブルの値に相当

ドメインイベント

集約

整合性を保つ単位? -> トランザクションで整合性を保証する単位? 1repository1集約 1つのコンテキストの中に複数の集約がある

マイクロサービス

マイクロサービスはコンテキスト単位

ドメイン駆動設計について調べてみる - Part1

ドメイン駆動設計について自分なりに調べてまとめてみる まずはドメインや境界づけられたコンテキストなど実践ドメイン駆動設計の第2章から

ドメイン

組織が行う事業やそれを取り巻く世界のこと

ドメインモデル

ドメインの知識や振舞を抽象化したもの

業務の"データ"と業務の"機能"をコードで表現 -> データクラスと機能クラスに分けるのはアンチパターン => クラスにカプセル化 -> データと機能を行ったり来たりしながらドメインモデルを作り上げていく

ドメインモデルをみんな(データベースや各アプリケーションなど)で共有する

あちこちに分散しがちな業務ロジックをデータ中心に整理して集約する ->ドメインモデルに業務ロジックを集めて重複コードを減らす

ドメイン層のオブジェクト

業務の"関心事"を表現したオブジェクト

業務サービスの実行役

独自の型(利用者の関心事)だらけにする

ユビキタス言語

ドメインエキスパート(その業務に詳しい人)や開発者を含めたチーム全体で作り上げる共通言語

境界づけられたコンテキスト

ユビキタス言語が使われるコンテキストを明示したもの

--> ドメイン毎(サブドメインの集合体)の境界を表すものなのか、そのドメインが共有されている組織を表すものなのか、はたまたそのどっちでも無いのか、ここについてまだ理解ができていない・・

https://www.slideshare.net/masuda220/ss-26583161 https://www.slideshare.net/masuda220/ss-57352072 https://www.slideshare.net/hirokishigemura9/ruby-ddd

単方向と双方向について

単方向

  • 後から双方向にデータをたどりたいといった時に単方向で作ってしまうと改修に手間が掛かる可能性がある
# one側
@Entity
@Data
public class Department implements Serializable {
    
    @Id
    @Column(name = "department_id")
    private String departmentId;

    @OneToMany(name  ="member_fk", referencedColumnName="member_id", nullable = false)
    private List<Member> members;
}
# many側
@Entity
@Data
public class Member implements Serializable {
    
    @Id
    @Column(name = "member_id")
    private String memberId;

}

双方向

双方向には下記の2パターンが存在する * mappedByを使う方法 * @JoinTableを利用する方法 → あいだにテーブルを仲介する

mappedByを使う方法

  • @OneToManyアノテーションを付けて、mappedByで関連させる相手側エンティティのフィールドを指定する → 相手側(多側)で外部キー用のフィールドを持つ必要がある

‘’‘java

coding: UTF-8

one側

@Entity @Data public class Department implements Serializable {

@Id
@Column(name = "department_id")
private String departmentId;

@OneToMany(mappedBy="departmentFk")
private List<Member> members;

} ‘’'

‘’‘java

coding: UTF-8

many側

@Entity @Data public class Member implements Serializable {

@Id
@Column(name = "member_id")
private String memberId;

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "department_fk", referencedColumnName = "departmentId")
private Department departmentFk;

} ‘’'

JoinColumnアノテーションについて
  • 結合表のための外部キーカラム名を「name」で指定できる
  • 外部キーカラムによって参照された結合先テーブルのカラム名を「referencedColumnName」で指定できる(※その場合は必ず結合先テーブルのプライマリキーとなっているカラムを指定)
  • 複数の外部キーカラムがある場合は@JoinColumnsを使用して、それぞれの関連に対して@JoinColumnを指定する必要がある
  • @JoinColumnを明示的に指定しない場合は、リレーションが双方向でなく単方向に扱われてしまう

@JoinTableを利用する方法

※こちらは概要のみ

  • @JoinTableを使ってテーブル結合させ、joinColumnsと@JoinColumnを使って結合表のための外部キーカラム名を「name」で指定する
  • また、外部キーカラムによって参照された結合先テーブルのカラム名を「referencedColumnName」で指定する
  • 同時にinverseJoinColumnsと@JoinColumnを使って結合表のための相手側の外部キーカラム名を「name」で指定できる
  • それと合わせて、外部キーカラムによって相手に参照される結合先テーブルのカラム名を「referencedColumnName」で指定できる

単方向を使うべきか双方向を使うべきか?

単方向OneToManyをお薦めしない理由

子テーブルは対応する子オブジェクトにマップされないカラム(FK)を持つことになるから一般的じゃないってのが主な理由 もし単方向関連だったら、子オブジェクトは親オブジェクト無しでも存在できてしまう。もし親が必要だとしたら双方向ににするべきでは!?

ちょっと視点を変えて「関連の所有」という見方をすると・・(※ここは参考とだいぶ違うので理解が間違っているかも・・) 上記の例の場合だと、一対多の関連はどちらが所有してるのか?  → 直感的に考えるとdepartmentが複数のmemberを所有しているため「department」では?  → 実際は「member」、なぜならmemberは外部キーから関連するdepartmenetが辿れるが、departmentからは対応するmemberを辿れないため  → こうなってくると当初考えていたのと所有者が逆に・・ => ORマッパー的には逆のように見えてしまうため単方向を使うのは避けたほうがよい??

FetchTypeについて

データをDBから取得する際に関連テーブルの方も一緒に取り出すかどうかで下記の2タイプがある * LAZY → 取得しない(※正確には遅延ロード) * EAGER → 取得する

LAZY

関連テーブルへのアクセスが発生したタイミングでロードされる → 元テーブルのみのアクセスの場合は関連テーブルのロードは行われない  → フィールドの呼び出しを最初の呼び出しで行う

EAGER

元テーブルにアクセスした際に関連テーブルも合わせてロードしデータが取得・格納される  → そのフィールドにアクセスがあった時点でフィールドをデータベースから呼び出す

最後に

単方向・双方向のどちらを使うか、また使った際に各オプションをどうセットするべきかについてちゃんと理解しする必要があったため今回、まとめてみた 個人的には当初は外部キーはEntityクラスとして持たないほうが良いのでは?と思い単方向を使うつもりでいたが、関連についての記事などを見てみたりあらためて調べると双方向にシフトした方が、 本来の使い方や、今後の拡張性も考えると良さそうな気がしてきた。

ただし、この辺りはN+1問題や今回はあまり取り扱えていない「inertanle,updateble,nullable」の辺りもしっかり理解した上で判断するのが良さそうなのでそのあたりについても調べてまとめる必要がありそう

Ref.

http://blog.livedoor.jp/chuhei1107/archives/51524817.html

https://gist.github.com/momotar/edccbea0e9712a3b3a6e

http://juzow.hatenablog.com/entry/20121017/1350480972

RESTについて - part.1

RESTの成熟度レベル

  • Level 0:SOAPXMLでやりとりをするHTTP通信 → URI と HTTPが 1to1
  • Level 1:URLでリソースを表すようにする(リソースを動詞でなく名詞で表す)
  • Level 2:HTTPメソッド(GET, POST, PUT, DELETE)を正しく使い分けている
  • Level 3:レスポンスの中に関連するリンクを含める → HATEOAS

[アプリケーションのRESTful度合いをどう計測するか|https://www.infoq.com/jp/news/2011/05/measuring-rest] [RESTとは何か|http://qiita.com/aosho235/items/125af74e2eab66c7a816] [Richardson Maturity Model|https://martinfowler.com/articles/richardsonMaturityModel.html] [フロントエンド開発者の僕にもやっとわかった!RESTfulの本当の意味|https://www.webprofessional.jp/what-does-restful-really-mean/] [第3回 マイクロサービス アーキテクチャ 読書会 メモ|http://nashcft.hatenablog.com/entry/2016/09/08/014818]

JJUG CCC 2017 Springに行ってきた

今更ながら参加してきたので当日のメモなどを 本当に適当なメモ書きレベルなので後で編集したい・・

レガシーアプリケーションの巻き取りとモジュール分割

ブランチ運用

テスト(CI/CD) 単体 → junit(validation etc) 画面単体 結合

@Runwith(Enclosed.class) → レビューアに優しいテストコード

selenide → 自動テストに利用

SpotBugs

tool

コーディング規約ならCheckStyle 問題検出は、PMD、SpotBugs、CheckerFw、 error-proneから選ぶ感じ

findbugs

onlyAnalizeで対象クラスを絞る visitorsで利用detectorをけずる(何を優先してチェックするのか) → これは使いやすいと思うとのこと

Spring cloud stream

Batchをスケールアウトしたことで、ポーリングによるRDBへの負荷が高まった → spring cloud streamを使った仕組みにつくりかえ => イベントドリブンに作り変え

SCS(spring cloud stream)

  • メッセージドリブンなマイクロサービスが実装しやすい(pub-subモデル)
  • spring bootアプリケーション
  • consumer groups → レポート作成のスケールアウトが容易になった => これによりノードごとに別IDの処理が行えるようになった(Batchをスケールアウトしたことで、ポーリングによるRDBへの負荷が高まった)
  • binder application → アプリ-ミドルウェア間が疎結合になるらしい(共通のdestination設定でOK)

spring batch job管理テーブルに大量INSERTでエラー(Sink側のSpring Batchが大量に起動した時に、Job管理テーブルに大量のinsertが流れてエラーに… )

  • maxAttemptの調整 → これだけだと不十分
  • DeadLetterQueue → エラーリカバリ用のMQを用意 => SCSのautoBindDlqをtrueに する

→ただ根本対応にはなっていないのでJobRepository側の対応方法を調査中。。

ポーリング型からイベントドリブンに変えたことでスループットが向上

CloudFoundryへ移行してスケールアウトが容易にできるようにする  → cflogin, cfpush? => この辺も含めて謎なので調べてみる

c.f) 第2世代への作り変えについて https://www.slideshare.net/techblogyahoo/jjugccc-cccf1-phpjava

c.f) pulsar https://www.infoq.com/jp/news/2016/10/pulsar

Jigsaw

・module-info.java - dependency disclosure scope → JAR内のこのファイルにモジュールの依存を記述する(module-info.javaでjarのメタ情報(依存性と公開範囲)を管理してModule化)

java –list-modules、現状73個のモジュールがリストされる