日頃の行い

個人的な日頃の行いをつらつら書いてます\\\\ ٩( 'ω' )و ////

Gotanda.js#4 in Retty でLTしてきました #gotandajs

6/3にGotanda.jsというイベントがあり、そこでLTしてきました。

gotandajs.connpass.com

イベント全体を通した内容などはこちらの記事にまとめられていました。
(私の資料次の日にあげたので見つからなくてすみません・・・
www.chirashiura.com

発表内容

発表資料はこちらです。
slideshareあげたら日本語消える問題直ってなかったので、speakerdeckにしました。

speakerdeck.com

node-questというライブラリを作ってSlack上でRPGを再現するみたいな話をしました。
node-quest自体は概念だけで、hubot上で色々実装する必要はありつつ、色々実装してみてこんな感じで遊べるよみたいなのが伝わればよかったかなぁと思います。
是非気になった方はぜひ使ってみてください\\\ ٩( 'ω' )و ////
ただ、version1.0.0行くまでは突然インターフェースが変わる可能性があったりするので、すみませんというところです・・・w

www.npmjs.com

ほんとはやりたかったこと

hubotの具体的な実装を書いたpluginを公開してだれでもインストールできるようにしたいなと思っていたので、これは今後やろうかなと思いました。
先週やる気が出なくて、空実装まででした。

github.com

感想

  • JSのフレームワークとかbuildツール周り趣味でしか使っていないので、その辺聞けて良かった
  • Webpackで3分半と聞いてやばそうと思った(小並感)
  • 学びが多くて良いためにLTする側としてはハードル高くてめっちゃ緊張した
  • デモ盛り上がってよかった
  • またいい感じのネタを仕込んでLTしにいきたい\\\ ٩( 'ω' )و ////

(だいたい)新卒エンジニア向け技術交流会vol.7 を実施した話

6/4にこんなイベントが有りました。

dark.connpass.com

参加者 34名 出席者 30名で参加率88%でした。わりと高め\\\ ٩( 'ω' )و ////
ありがとうございます!

【参加された方々へ】
Slackの方にもぜひぜひ参加してください。
認証情報わからん・・・等あればこちらから招待送るので、__dark__ (@ngineerxiv) | Twitter にリプライやDMなどでご連絡ください〜

http://yamiga.waka.ru.com/slack

発表内容

内容の一覧というか予定はこんな感じでした。

f:id:arata3da4:20160605220103p:plain

ウチのおじいちゃん凄いんだよ(Jenkinsってこんな使い方もするぜ)

by @jp_taku2

※資料は見つけ次第追記します
Jenkinsおじいちゃんと労る話でした。
実際のおじいちゃんももっとちゃんと労りましょう(?)w

チームを作ろう

by @papix

https://slas.la/papix/dark7

slasla というサービスを立ち上げた時の話でした。
技術的に何を使っている等の話からサービス開発楽しそうと思えるエモい話まであってサービス開発いいなと思いました。

スタートアップのくせになまいきだ

by @hoto17296

https://slas.la/hoto17296/hoto_dark_7

"今すぐ"ガンガン開発/ガンガンデプロイ・"スケールしても" ガンガン開発/ガンガンデプロイすることが大事という点からHerokuを使ったアプリケーション開発の話でした。
The Twelve-Factor App (日本語訳) のお話は知らなかったので学びがありました。

Z-Shell

by @equal_001

zshの便利さについての話でした。http://www.zsh.org/
実際資料はそこまでなく、ライブコーディング?ライブコマンディング?で発表してくれました。新しい!
zsh自分も使ってますが、何も考えずとりあえず設定している項目が多くて「あ、それそういう設定でそうなるんだ」みたいな感じになってよかったです。
ちなみに私は「ぜっしゅ」と読んでます。

(Title忘れてしまったので資料見つけ次第追記します)

by @YAMITZKY

わりと後半私が酔っ払ってたためタイトル忘れてしまいました😇
ただ、pyconに投稿するとのことだったので、そのうち資料と共に公開されると思うので、その時に追記しようと思います。
ちなみに、pyconに投稿しないと、次回イベント時にピザではなく、寿司になり、差分の金額を@YAMITZKYさんが払ってくれるとのことでした←

最後に

次回イベントはまた3ヶ月後とかになるかと思います。
ぜひ気になる方は ngineerxiv - connpass にてメンバーに登録してみてください〜

Domain Driven Design Quickly Onlineを読む #2

www.infoq.com を読みます。

1章 Domain Driven Design Quickly Onlineを読む #1 - 日頃の行い

章ごとに雑なメモとして解説などではなく、思ったことを淡々と書いていくつもりです。

2章 ユビキタス言語

共通言語の必要性

前章おさらい
ソフトウェアの専門家とドメインの専門家が一緒に働き、ドメインモデルを作成することが不可欠

しかし、それぞれの専門とする分野の言葉をそれぞれが使おうとするため、コミュニケーションが難しくなる
部外者が理解できないような専門用語など
開発者やドメインの専門家が使う言葉を門外漢がわかるように例えた言葉であったとしてもドメインに関する知識を確立する作業には役立たない
ドメイン駆動設計の核となる原則:ドメインモデルに基づく言語を使う
コミュニケーションやプログラミングコードにもこのドメインモデルに基づく言葉を使う
このような言葉をユビキタス言語と呼ぶ

共通言語として使える用語を見つけるのは簡単じゃない
ドメインの定義と設計の方向を決めるような重要な要素を見つけ、これらの要素に適切な名前をつけることで、共通言語として使える用語が手に入る

ドメインの専門家は、ドメインモデルや共通言語の中で理解できないものがあった時は何らかの間違いがある
開発者は設計に紛れ込みやすい曖昧さや矛盾が現れていないかを注視しないといけない

この辺りでユビキタス言語を作っていくストーリーの具体例

普段の会話では婉曲的な会話になることや、詳細に立ち入りすぎること、概念を取り違えたりすることがよくある
そのような会話でユビキタス言語を見つけるのは難しい
なので、チームすべてのメンバでユビキタス言語を作らなければならないと自覚して重要な点に集中しつつ、
必要なときには既に作成したユビキタス言語を利用する
そして、このような作業時には独自の専門用語を極力使わないようにする

開発者はドメインモデルの主要な概念をコードへ実装するべき

ユビキタス言語はどのように表現すべきか
UMLも良い、文書を使っても良い
モデルについての認識を合わせるためのおすすめは、モデルの部分を表す小さな図を作成すること
これらの図は、幾つかのクラスを含み、それらの関係を表し、概念全体の一部を適切に含む
ドメインモデル全体を表す大きな図は作成できたとしても雑然としているはずなので、小さな図の集まりの方がよりよく理解できるはず

ソフトウェアアーキテクト・開発者・ドメインの専門家を含む設計チームに必要なのは、作業を統一し、モデルの作成とコーディングを助ける共通言語

まとめ

  • 開発者だけではなくドメインの専門家も含めたそれぞれの専門用語ではない共通言語(ユビキタス言語)の作成がチームでプロジェクトを進めていく上で大事
  • ユビキタス言語は図や文章様々な表現方法で、大きく全体的というより、小さな図の集合によって表すと良い

Domain Driven Design Quickly Onlineを読む #1

DDDの本を読もうと思ったけど、先が長くて意志の強さが足りそうにないので、こちらから読んでいくことにしました。 章ごとに雑なメモとして解説などではなく、思ったことを淡々と書いていくつもりです。

www.infoq.com

1章

ドメイン駆動設計とは何か

メモ

ソフトウェアは業務の自動化や現実世界の問題などの具体的なドメインのためのもの
ソフトウェアは特定のドメインから生まれ、そのドメインと深く関わっている
優れたソフトウェアを作るにはドメインの理解が必要
例)銀行業務
Q. ドメインの理解がある人はだれか A. 銀行員
彼らは全ての細部・全ての落とし穴・全ての潜在的な問題点・全てのルールを知っている。
ここから出発しなければならない。
これがドメインから出発するということ?

ソフトウェアを導入する真の目的はそのドメインの業務をより効率的にするため。
したがって、改善対象のドメインに円滑に適用できなければならない。

ドメインの反映としてソフトウェアを作ることで、ソフトウェアをドメインに円滑に適合させることができる。
ドメインの核となる概念や要素を取り入れ、それらの関係を正確に再現する。
(再現させるために?)ソフトウェアはドメインをモデル化する必要がある。

ドメイン=この世界についての何か
ドメインは、単にキーボードでコンピュータにとり込んだり注ぎ込んだりすればコードになるというようなものではない。
ドメインの抽象的な概念(青写真)=が必要。つまりモデル化が必要。
抽象とはドメインのモデルのこと
ドメインモデルは特定の図で表わされるものではない。
そのような図が伝えようとする概念のこと。
ドメインモデルはドメインの専門家の頭のなかにある単なる知識ではない。
ドメインモデルはそういった知識を厳密に取捨選択しながら作成する抽象のこと。

ドメインモデルは対象のドメインをプロジェクトの関係者に向けて表現したもの。
ドメインはとても多くの情報を含んでいるので全てをモデルに取り込めない。
何をモデルに取り込み、何を捨てるのか。これが設計作業でありソフトウェアの作成。

モデルは他人に伝えなければならない。
私たちは一人で作業するわけではない。

勝手なまとめ

  • ソフトウェア=業務を自動化するもの・現実の問題を解決するもの
  • ドメイン=この世界についての何か
  • ドメインモデル=ドメインの抽象的な概念
  • ドメインについての専門家から必要なものを取り込み、不必要なものを排除したものがドメインモデル

ドメインの知識を構築する

例)飛行機の飛行制御システム システムの目的:飛行機同士が衝突しないようにすること ドメイン:航空監視業務 ドメインの専門家:航空管制官

を元にした具体的なやりとりだった。