Kichijojipm-mini #012 でLTしてきました

kichijojipm.connpass.com

日が空いてしまいましたが、3/14 に Kichijojipm-mini #012 でLTしてきました。

吉祥寺.pm は、Perlのイベントではありますが、「吉祥寺.pm」は概念なので、割と何でもありのイベントです。 雰囲気が温かいので初心者でも快く受け入れてくれる懐の深い場所です。
つまり、*.pmとは、「PostgreSQLのP」でも良いし、「MetricsのM」でも、「ManagementのM」良いのです。 Perl以外にも、GoやScalaの話なんて事もあります。

なので、話のネタもバリエーションだけでなく、面白いものから興味深いものまで幅が広くとても楽しいイベントです。

kichijojipm.connpass.com ハッシュタグは、 #kichijojipm です。

「吉祥寺.pm」は、レギュラーイベントの「Kichijoji.pm #000」と今回参加した「Kichijojipm-mini #000」の2つあり、 miniの方はこじんまりと少数でワイワイやる感じです。

今回のテーマは「設計」で、私は、特殊なインフラ環境下での自分のETLやデータ分析で扱うスクリプトなどに関する設計に関する話をしました。

まず、主な話のネタは、しんぺいさんのスライド「今あえてDRY原則に向き合う」を中心に色々な設計に関する話がありました。

speakerdeck.com

ざっくりした話としては、闇雲にDRY原則だけを持ち込まない。「どこに変化があるのか?」を見極めてから問題を分割して構造化する(そこにDRYを持ち込む)という話で、

DRY原則 とは、重複を排除しようとする ソフトウェア設計 に関する原則であり、 ソフトウェア設計 とは、 問題を分割して構造化する事 と考えた場合に、実際のコードを用いながら、 DRY原則 だけでなく、他の原則を含めた以下の観点を用いてソフトウェアの設計を考えようという話になっています。

観点 要約
解放閉鎖原則 拡張に対して開き、修正に対して閉じている
凝集度と結合度 凝集度は高く・結合度は低く
(なるべくまとめるけど、まとめたものは相手への影響は最小にする)
単一責任原則 あるクラスが変更される理由が2つ以上あってはならない
→責務を適切に分割するために、変化点を見極めてそこから分割点を見いだす
解放閉鎖原則 拡張に対して開き、修正に対して閉じている

とても良い内容なので是非見てください。

その後の私の発表スライドはこれ。

www.slideshare.net

私の所属部署でのデータ基盤について、インフラ構成が、アプリもRDBも同じ Dell の Rxxx のホストとして、ストレージを Storage SCxxxxx で構成されている状態にあって、RDBへのロードがすぐに詰まったりしており非常に困った状態にあります。
また、データソースも色々をイケていない構成になっていてそれが更に面と臭い事になっている状態にあります。

そんな辛い環境下で、ETLやデータ分析に伴うコーディングで気をつけている事を簡単にまとめた話をしてきました。

とても、良い話が様々出来て、とても充実した勉強会ではあったものの、居酒屋で酒飲みながらやっていたため、メモが取れず「最高に良い会だった!」という体験だけが残ってしまったのが非常に残念でした(-_-;)

最後に。

近々、第2回があるようです。
吉祥寺.pm on Twitter: "Kichijojipm-mini 012、全て終了しました(まだ帰宅中の方がいる模様ですが…) 残念なことに、しんぺいさんの過去スライドを2本準備頂いたのに、1本しか消化できなかったので、ぜひ「設計ナイト2 よりぬきしんぺいスペシャル」を開催したいと思います。お楽しみに! #kichijojipm"

楽しみですね。