2016/1/28(木) 「JS Board Shibuya #7 もくもく会」に参加してきました。
connpass
http://jsbshibuya.connpass.com/event/24947/場所は新宿のさくらインターネットさんです。
参加者は１０人くらいかな？
私は前回のRaspberry Pi特集の時以来の参加です。そんときのブログはこちら。
「JS Board Shibuya #4 Raspberry Pi入門」に参加しましたせっかく買ったラズパイ、自宅にいると中々重い腰が上がらないので、こーゆう場があるのは良いですね。
今回はいろいろ設定したり、書籍に沿ってLチカやったりして遊びました。
↑で言う書籍とは、２０１４年の
XP祭りで貰ったコレ。
Lチカ。ブレッドボードに発行ダイオードとΩ抵抗を接続して、ちょっとした機械いじりを楽しみます。
スマホからVNCでラズパイにリモートアクセスして操作できるようにしました。
もちろんPCからもラズパイにリモートアクセスできます。
リモートで繋げば、ラズパイにディスプレイ、マウス、キーボードなどを接続することは不要になります。
そんなこんなで２２時過ぎまで機械いじりを楽しんでました。
次回もこーゆう会があると、重い腰が上がるので良いですね。
ラズパイ用の新しい書籍も買いたいなぁ。
関係者の皆様、ありがとーございました。
2016/1/23(土) 「Java読書会 "Java EE 7徹底入門" を読む会」に参加してきました。
Java読書会のサイト
http://www.javareading.com/bof/読書会(Java EE 7徹底入門)第1回議事録
http://www.javareading.com/bof/java_ee7_1.html場所は川崎市教育文化会館です。
私が住む最寄り駅のJR大森駅からJR川崎駅まで２駅で、個人的にはアクセスしやすい立地です。
参加者は１６人かな。
新しい本になると初回はいつも参加者が多めになります。静岡から早朝鈍行で参加されてた猛者も・・・
私が初参加したのは２０１３年の１０月で、そっから常連になりましたが、あれからもう２年以上経ちます。
前回で「
Javaパフォーマンス」を読みきったので、年が変わって１月から新しい書籍を読みます。
寺田 佳央 猪瀬 淳 加藤田 益嗣 羽生田 恒永 梶浦 美咲
翔泳社
売り上げランキング: 13,245
読書会で書籍を読み終わると、新しい書籍をどれにするかWebサイトで投票が行われます。
今回の投票結果はこちら。
http://www.javareading.com/bof/cgi/rank.cgi?Dummy=1454134173491投票最終日の夜時点で２冊が８票で同点だったんですが、その後、私が投じた１票が決定打になるとは・・・
投票はいつも迷うのですが、ちょうど自社でもJavaのWeb開発フレームワークを刷新しているところで、この本には興味あったんですよね。
個人的にもStruts1とSpring Frameworkは触ったことあるものの、Java EEのJSFやJPAなどはほとんど触ったことありませんでした。
今まで読書会で読んできた書籍は「読み物」系が多かったのですが、今回の書籍は「実装」寄りの印象を受けます。
なので、手を動かしながら学べる本ということで、事前に写経してから参加しました。
１０年以上、毎月休まず開催されてきた歴史があるJavaの読書会です。
前々回は２００回目だったそうで、読書会後にみんなでボーリングに行きました。
是非、そこの貴方もJava読書会に参加して、Java EEの新しい技術に触れてみませんか～
2016-01-25（月） 「【東京】JJUGナイトセミナー Git入門」に参加してきました。
DoorKeeper
https://jjug.doorkeeper.jp/events/37249Togetter
http://togetter.com/li/930969場所は日本オラクルさんです。
参加者は２３０人くらいでしょうか。会場は後まで満杯で、立ち見まで出て大盛況でした。
普段のお仕事でもGitやGitBucketを使う機会がだいぶ増えました。
ただ、使いこなせてるかというと自信がなかったので、この日の勉強会の内容はとても興味がありました。
以下、自分用のメモ。
Gitはじめの一歩 (@ihcomegaさん)
手書きの絵がかわいいですね。新卒３年目で登壇とは素晴らしい。
■ 分散バージョン管理の便利なところ- 自分自身のリポジトリが作れるので気軽に操作できて精神的にも嬉しい。
- SVNだと皆で使うリポジトリが１つだけなので、操作にプロジェクト全体が影響する。
■ ローカルでの操作詳細- commitする前にステージに上げる。(git add)
- ステージから戻すこともできる。(git reset)
■ リモート・ローカルで歴史をやりとり■ ブランチ- 今作業中のブランチをHEADという
- ブランチの統合には２種類ある。 merge / rebase
- 合体させて１つにする： git merge
- つけかえて１つにする（歴史が書きかわる）： git rebase
■ マージの種類- fast-forward ： 枝分かれ元に変更がない
- non-fast-forward ： 枝分かれ元に変更がある
■ オススメ本（無料）
Git実践入門 (@syobochimさん)
入社４年目で大手SIer勤務とのこと。
この日の講演者はお二人とも女性で、入社３～４年目の若手エンジニアでした。素晴らしいチャレンジ精神。
■ 開発スタイル
■ 困ったこと
■ プロジェクト構成とブランチモデル(1) ケース１- ベースリポジトリとサイトリポジトリに分ける。
- ライブラリアンというチームを作って、ベースリポジトリはそのチームしか触れない。
- ベースリポジトリからリリース物を作る
- フレームワーク用にリポジトリを分けている。
- フレームワークの取り込みタイミングは、アプリチームが最適のタイミングを決められる。
(2) ケース２- developA、developB、developC・・・は、開発拠点毎に作る。
- フレームワークの変更がdevelopにマージされ、それしか使えないので、すぐに各チームは取り込まないといけなくなるので、素早く変更が反映される。
(3) ケース３- developブランチのみで開発し、直接developへコミットする。
- masterへのブランチは受け入れ時のみ。
■ 導入・運用してみて思った事- ガイドを用意するとスムーズ。
- しょぼちむさん作成のガイド： http://syobochim-doc.readthedocs.org/ja/latest/index.html
- ややこしいことはさせない。禁止するんじゃなく、教えない。
■ 改善が必要だと思うこと
■ ギットクエスト■ 質疑応答Q1.Gitが流行ってるから導入したい、ってPMに説得したけど、受け入れてもらえなかった。
説得をどうすればいいか？
A1.そういうPMはGitとかに興味がないので、PMを説得せずに先に入れちゃう。
無料なので、開発者の中で同意がとれてればいいのでは。バレたら謝るくらい。
わからない人にはわからないことを言わないｗ
Q2.SVNでできるのってGitでもできるの？
A2SVNはロックがかけられる（チェックアウト時の凍結ロック）のがGitと異なる。
Gitはマージが優秀なのでマージでカバーする。
マージの恐怖心をなくしてあげることが重要。
Q3.SVNよくしってる現場にGitをいれるとき、SVNと同じ使い方もできると思うが、Gitの何をつかえばよいか？
A3.SVNは同じところにコミットしていくのでプレッシャーがある。
Gitは同じとこにコミットするという精神的負荷がないのが良い。
★感想：登壇者のお二人、入社３～４年目の若手女性エンジニアさんだったんですが、とても「しっかり」しているイメージでした。
きちんと自分の考えを持って、自分の意見を主張している姿が目に浮かびます。
個人的にも、Gitについて理解があやふやな点も整理でき、とても有意義でした。
あと、ギットクエストをプレイしてみたんですが、斬新な発想ですね。
Gitの学習を始めるステージ、コアな部分をアトラシアンのサイトに丸投げしている部分にいつも噴くｗ
関係者の皆様、ありがとうございました。
2016/1/21(木) 「DDD Alliance! ドメイン駆動設計のためのオブジェクト指向入門」に参加してきました。
connpass
http://ddd-alliance.connpass.com/event/25209/Togetter
http://togetter.com/li/928734場所は株式会社ドワンゴさんです。
参加者は100人弱でしょうか。私は抽選はハズレてしまったのですが、キャンセル出たおかげで繰り上がりました。
以下、個人メモ。
■ ドメイン駆動設計- ドメイン層のソフトウェア設計の話。ベースはオブジェクト指向。
- オブジェクト指向の場合はドメインの理解とプログラミングの距離が近いと思っている。
- １～３章に原則が書いてある。それ以降はその原則をどうやっていくか、知見が書いてある。
- ドメインモデルが１～３章のキーモデル。
- ユビキタス言語の中でも特に重要な関心事を集めたのがドメインモデル。ユビキタス言語のサブスタック。
- 2章でコミュニケーションを重視しているということは、アジャイルの考えに近い。
- 3章の「モデルと実装を結びつける」ことによって、オブジェクト指向が求めてる生産性とか変更容易性が生まれてくる。
- クラスを発見する人間と分析する人間が一緒となるという考え方。
- コードを書く人が分析して書けばいいんじゃないか。
■ ドメインの隔離- ドメイン層を独立させて、学んだことをいかにここに書くか。
- ドメイン層は他の層を見えてない。他の層がドメイン層を参照する。
■ オブジェクト指向： コードの整理- クラス単位にコードを整理する。
- 主要な関心事の単位にクラスを作る。顧客とか。
■ オブジェクト指向：アーキテクチャ- 変更のコストを下げることによって、変更をあたりまえにする。
- アジャイルとオブジェクト指向は一体。
■ 独自の「型」を設計する- 独自の型 ＝ 利用者の関心事
- 基本データ型 ＝ コンピュータの関心事
■ 契約による設計- バートランド・メイヤーの本を読んで、「契約による設計」っていうのを理解した。
- それをベースに考えると、他のもわかるようになってきた。
- エリック・エヴァンスも契約による設計をベースにする、と本に書いていた。
■ 実装手段(how)を隠蔽する- メソッドの引数とか戻り値にJava言語仕様の型(StringとかLocalDate)とか使われてたら、それは改善すべき。
■ メトリクス- １つのアグリゲートでオブジェクトが１０くらいぶら下がっている。
■ 参照オブジェクト vs @Entity
- ドメイン駆動設計における「エンティティ」というのは、参照オブジェクトのこと。JPAの@Entityとはまったくの別物。
- テーブルというのは業務の関心事とは一致しない。
- 基本型が見えちゃうので、JPAはドメイン駆動設計とは必ずしも相性良くない。
- なのでMyBatis使ってる理由でもある。
■ オブジェクト指向設計の学び方- まずはやってみる（コードを書く）
- 上2冊は鉄板のおすすめ
Martin Fowler
オーム社
売り上げランキング: 28,286
ケント・ベック Kent Beck
ピアソンエデュケーション
売り上げランキング: 134,260
Q1.
トランザクション周りで、集約をまたいじゃった時、どう解決するのか
A1.
今回の講演では割愛した部分に対する質問ですね。
私はアンチトランザクション派なので、トランザクション組まない。小さく分解していく。
注文と注文明細を考えるとき、大きいのガツンと保存するんじゃなくて、小さく注文明細ごとに書き込む。
Q2.
ドキュメントを残さないようにするという話があった。システムが大きくなると、ドキュメントを残さずにやるにはどうすれば。
A2.
ドキュメントは書かないわけじゃない。必要なときに必要なドキュメントを作る。
でも、長期メンテするものではない。一切メンテしない。
正しくて最新なのはコードだけ。
Q3.
リポジトリからデータ取得するとき、戻り値の型で、商品を例にするとIDとか商品名とかがある。
findメソッド使う場合、商品自体がオブジェクトとして帰ってくるが、商品名だけほしい場合はどうする？
A3.
商品リポジトリから必要なものだけとってくる。業務的に本当に必要なら。
Q4.
プリミティブを隠蔽して表現力高めるのはいいと思うが、コンストラクタのnewも丸出しは良くないと思うがどうか。
C言語のmallocみたいに感じる。
A4.
コンストラクタは隠したほうがいい。
フレームワークがDBからデータを取ってきて作ってくれるし、ファクトリが作ってくれたりするようにする。
Q5.
DDDで構築したとしても、ドメインが変化していくスピードが早すぎてコードが追いつかない場合はどうすれば。
A5.
オブジェクト指向のスキルを磨くこと。
ビジネスががらっと変わるよりも、ビジネスをやりながら徐々に分かってきて商売を変化させていく時は、DDDで商売を捉えられていたら、商売とシステムの変化の速度はそれほど変わらないはず。
スピードが出ないなら、オブジェクト指向とか設計とか商売の構造が捕まえきれてないのでは。
そもそもリアルな商売の変更も、コストと時間はそれなりにかかる。
Q6.
ビジネスの市場が未成熟でドメインエキスパートもビジネスを理解しきれてない場合、どういうアプローチができるか？
A6.
ドメインエキスパートは、安定した業界でもいない。なので自分から提案してキャッチしにいかないといけない。
ソフト開発者はそのビジネスの一人としてビジネスを一緒に考えるくらいじゃないといけない。
Q7.
プリミティブ型ではなく独自型を使う利点はわかったが、フレームワーク使う場合は妥協点を見つけないといけない。
MyBatis使ったとのことだが、苦労しなかったか。
A7.
値オブジェクトの中には基本データ型がある。
MyBatisはsetterなくてもやってくれるが、SpringのORMはsetterないとうまくやってくれなかったりする。
そのへんは妥協。
★感想：増田さんのお話を聞いていて思ったのは、増田さんが自らDDD講演の場に身を置く機会を設けることで、増田さん自身がDDDの新たな知見を貯めこんでいっているのでは、ということでした。
講演の中でもおっしゃってましたが、「本を何度も読みなおすことでいつも新しい発見がある」と。
あの鈍器に匹敵する本を何度も読みなおすというモチベーションと労力は、並大抵ではないと思う。
それをあえてやっていのも凄いし、それを毎回、スライドに自分の言葉で纏め講演することで、さらにDDDの知見を深めているのだと思う。
そしてその知見を惜しみなく勉強会で提供する。OSSに通じるものがありますね。感謝。
スライドの中で、ControllerクラスをPresentation層として表現していましたが、これって一般的なのかな？
私はApplication層くらいかな、と思ってました。Presentation層って、Viewのイメージなので・・・
増田さん、関係者の皆様、ありがとうございました。
2016/1/15(金) 「エンタープライズアジャイル勉強会 2016年1月セミナー」に参加してきました。
開催お知らせページ
https://easg.smartcore.jp/C22/notice_details/QjJNSVBnPT0=今回はソニックガーデンの倉貫さんが講演されるということで、申し込もうとしたら既に満員締め切りでした。
前日、無理を承知でお問い合わせページから参加させていただきたい旨、カキコしたところ、事務局の方から参加許可いただけました。
お願いしてみるものですね。感謝。
以下、講演時のメモ。
メモはあまりとらず傾聴してたので、メモ内容は単発系です。
倉貫さん、今日はエンタープライズということで、わざわざ背広を着て、散髪してきたとのこと（笑
この日もアイスブレークから冴えてます。
倉貫 義人
日本実業出版社
売り上げランキング: 47,715
倉貫 義人
日本実業出版社
売り上げランキング: 11,891
前者は存在を知っていたのですがまだ読んでなくて、この日はその話を聞くために参加しました。
後者は最近出たそうです。この日も、リモートワークについての話が結構出てきました。
■ 納品のない受託開発- 受託だと何をやってもうまくいかなかった。会社で偉くなっても営業を自分でやっても、受託の限り上手くいかなかった。
- そこで、受託から社内システム開発に変えると上手くいくようになった。
- クラウドビジネスは納品しないで改善していくので、アジャイル開発がフィットした。
■ エンタープライズアジャイルとは
- 「エンタープライズアジャイル」ってなんだ？と2日くらい悩んだ。
- 言葉からスタートすることを止めて、企業を取り巻く状況から考えることを始めた。
■ ソフトウェアありきの企業の台頭
■ 「アジャイル企業」という発想
- 事業に合わせてITも変化させ育てていかないといけない
- ウォーターフォールでやってって、事業に合わせて変化に追随できるのか？
- それはできないので、「アジャイルありき」で経営を考えていく。
- 「アジャイルが前提の会社」＝「アジャイル企業」これは倉貫さんの造語。
■ 戦術としてのアジャイル、アジャイルのための戦略- 与えられた環境の中でアジャイルってどう上手くやるんだろ？みたいなのを考えるのが、目標としてアジャイル。
- ぞうじゃない。アジャイルを「目指す」のではなくて、アジャイルになる「環境を整える」ことが大事。
- アジャイルは目標でなく、結果。
- 経営からアジャイルにしていき、社員は自然とアジャイルで仕事するようになれば、それは究極のアジャイル。至高のアジャイル、とは真逆。
- そこを考えるのに、「エンタープライズ」とか、どーでもいい。
■ アジャイル企業の目指すポジショニング
- 4象限にわけてみた。
- コスト、品質、スコープの3軸がある三角形の図をよく見かける。
- 3軸のうち、スコープをを変えて変化に対応するのがアジャイルです、という説明をよく見る。
- でも、これは目標を先に決めてる予測型。
- 普通の会社は予測計画型。この予算で達成しましょう、と決めてその通りにやる計画型ビジネス。これは図でいうと左側。
- Facebookとかは予測型でない。まずサービスを初めて、ヒットしすぎてから、どうしよう？と考えるタイプ。
- 「エンタープライズ」を議論するより、左（予測型／計画重視）か右（適応型／結果重視）かをまず考えたほうがいい。
- 左（予測型／計画重視）の会社が一生懸命アジャイルしようとするから上手くいかない。
- 「エンタープライズアジャイル」 ではなく、「アジャイルエンタープライズ」として考える方が良い。
- （アジャイルをエンタープライズに適合させるのではなく、元々アジャイルで上手くいっていた少人数プロジェクトを、どうエンタープライズにスケールさせていくかを考える）
- アジャイルの価値観を経営に。
■ アジャイル開発と受託開発
- 一括請負だと、作ることがゴールになる。人月見積もりなのに完成責任を負わされる。仕様凍結vs要件詰込の対立。
- これはビジネスモデルの構造的欠陥なので、受託開発である限り誰も幸せになれない。
■ 納品のない受託開発
- ソニックガーデンでは、一人のエンジニアが「顧問」として、すべての役割を担う。
- 納品のない受託開発では、要件定義をしなくてもよい、仕様変更をいつでも出来る、という顧客メリットがある。
- そもそも要件定義をしたいのはベンダ側の理論でしかない。きちんと要件を決めておかないと、あとで追加変更に苦しめられるから。
- ユーザ側が仕様変更をちょっと相談しようとすると、ベンダはすぐ追加見積もりをもってくる。なのでユーザは嫌がる。
- その弊害を取っ払う。
- 納期を死守しない。
■ ワークスタイル
- 違う場所で同じ時間に働く。
- チームなので、苦手なところをサポートしあう。
- エンジニアは腕を磨いて目の前のお客さんを満足させることだけを考えればいい。
- 好きな仕事をやっているならば、縛る必要は全くない。
■ 「管理」のいらない良い人材を集める
- 焦って人を入れて上手くいったことがない。いい人がいるまで採用しない。
- 変な人を採用しない、いい人しか採用しない。なので人の管理もいらない。
- プログラミングできることは前提でしかない。
■ 経営モデル
- 売り切りの商売をしない。細い客をたくさんもつほうが会社は安定する。
■ アジャイルエンタープライズ
- アジャイル企業としてスケールする。
- 従来のでかい企業がどうアジャイルになるか、の方向じゃない。
■ アジャイル企業マニフェスト
- 売上や規模の拡大よりも社員の幸せを
- 経営者として価値観をきちんと表明すること。新しい価値観の会社がでてきてもいいんじゃないか。
★感想：
倉貫さんの語りは自信に満ちあふれているというか。
きっと、自分の主張と成果が一致しているからなのでしょうね。
倉貫さんの思想をいきなり自社に適用するのは難しいとしても、プロジェクトのチーム編成時とかで参考にできると思いました。
あと、
プログラマーを一生の仕事にする
プログラマを誇れる仕事にする
というビジョンとミッションは心に響きますね。プログラマがほんと好きで、敬意を払ってることが伺えます。
倉貫さん、関係者の皆様、ありがとーございました。
ちなみにこの日の金曜ロードショー、ラピュタだったんですが、勉強会からの帰宅が間に合ったので詠唱しておきました。
