FC2ブログ

makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

自転車で山梨から静岡へ、富士山沿いの自転車旅 3連休2日目

2019年2月の3連休、自転車で山梨から静岡へ、富士山沿いの旅をしてきました。
このブログはその2日目(2019/2/24)の旅日記になります。

1日目の日記はこちら
http://makopi23.blog.fc2.com/blog-entry-303.html

2日目(2019/2/24)のスタート


真冬のキャンプ場で迎える朝~
野宿すると就寝時間も早いので、朝5時半くらいに目が覚めました。
防寒対策をして寝袋に包まるものの、明け方はさすがに寒かった・・・この日の最低気温は-6℃くらいだったそうな・・・
20190224_01.jpg

このキャンプ場は標高が800m以上ある高原に位置するので、東京よりずっと寒いんです。
あと、花粉症なので鼻が詰まる・・・自転車漕いでるときは問題なかったんですが、横になるとダメですね・・・

前日コンビニで買っといた朝食のパンと、自販機で買ったホットコーヒーを手に、キャンプ場の食堂へ。
食堂は24時間空いていて、暖房器具もあります。
20190224_02.jpg

日の出は6時20分くらい。食堂の隣にある池のそばから富士山を眺めます。
池に、鏡のように富士山が反射して見えますね。「逆さ富士」と呼ばれるビューポイントだそうな。
20190224_03.jpg

池からちょと離れ、再度お写真1枚。朝焼けに映える富士山、綺麗~
20190224_04.jpg

日の出から30分ほどすると、富士山の後ろから太陽が上がってきました。綺麗~
20190224_05.jpg

自転車とテントと富士山。
開放感、半端ないって。。。
20190224_07.jpg

朝露に濡れたテントやレジャーシートを干して乾かし、しばらくお散歩したあとに撤収準備。
20190224_08.jpg

受付でチェックアウトの手続きを済ませ、最後に自転車と富士山を1枚~
20190224_09.jpg

名残惜しいですが、ふもとっぱらを出発。富士山、最高の景色でした。

ふもとっぱらのキャンプ場から国道139号沿いに8kmほど南下し、富士山YMCAグローバルエコヴィレッジへ。
20190224_10.jpg

「ゆるキャン△」の第11話~12話でクリスマスキャンプの舞台となった聖地だそうな。
有料のキャンプ場に無断で立ち入るのはマナー違反なので、入り口付近から遠巻きに眺めます。
20190224_12.jpg

自転車と富士山と、お写真1枚。
20190224_11.jpg

富士山YMCAグローバルエコヴィレッジから1kmほど南にまかいの牧場(馬飼野牧場)があります。
こちらも「ゆるキャン△」の第11話~12話クリスマスキャンプで登場する聖地だそうな。
20190224_13.jpg

まかいの牧場は、ソフトクリーム総選挙にて第1位になったソフトクリームも有名なんだそうな。
20190224_14.jpg

今回の旅路は湖やキャンプ場や牧場などがいっぱいあるコースで、ほんと開放感満載なのです。
東京だと、こうはいかないね。。。
20190224_15.jpg

まかいの牧場から4kmほど南下し、「富士宮 白糸の滝」に到着~
20190224_16.jpg

高さ20m、幅150mの湾曲した絶壁から大小数百の滝が流れ落ちていて、観光名所の1つだそうな。
後ろに富士山も見えてます。
20190224_17.jpg

白糸の滝から11kmほど南下し、富士山本宮浅間大社へ。
20190224_18.jpg

富士山本宮浅間大社は、富士山信仰の広まりと共に全国に祀られた1300余の浅間神社の総本宮なんだそうな。

富士山本宮浅間大社の楼門をくぐる。
20190224_19.jpg

富士山本宮浅間大社の拝殿・幣殿へ。
20190224_20.jpg

富士山本宮浅間大社の隣に湧玉池があります。
富士山の雪解け水が湧出していて、特別天然記念物だそうな。
20190224_21.jpg

後輪のスポークが2本折れていたので、富士山本宮浅間大社の駐車場横で車輪の修理。
20190224_22.jpg

富士宮市を抜け、富士市へ。
20190224_23.jpg

この旅の終着点、JR富士駅へ到着~
20190224_24.jpg

この駅は自転車で東京から大阪へ560kmの旅をしたときに経由しました。
この時が初の自転車旅だったのでよく覚えています。懐かしい~。そんときのブログはこちら↓

自転車で東京→大阪へ560kmの旅 GW2日目
http://makopi23.blog.fc2.com/blog-entry-237.html

月曜も有給休暇を取ってたので、今日は三島まで行って明日は伊豆の修善寺まで行く予定をしていたのですが、あいにく明日は雨予報・・・
ということで、続きはまた今度~

自転車を輪行袋に詰め、品川区の自宅まで東海道線を乗り継いで輪行します。
20190224_25.jpg

新富士駅から新幹線も出てるけど、明日も休みだしそんな急ぐ旅路でもないので、のんびり読書しながら帰ることにしました。
幸い、JR富士駅からJR川崎駅までは座れました。

JR川崎駅で京浜東北線に乗り換え、輪行のお荷物一式をお写真1枚。重い・・・
20190224_26.jpg

この日はふもとっぱらのキャンプ場を出発して静岡県の富士駅まで、39kmほど走りました。
大半が下りだったので楽ちんでした。
20190224_27.jpg

感想


NHKの「ドキュメント72時間」で放送された「真冬のキャンプ場 富士山を眺めながら」に触発され、そこでゆるキャン△という冬キャンプをテーマにしたアニメの存在を知ったわけですが、実際やってみると、冬キャンプもアリですね~

たった一人の「ソロキャンプ」というのも流行ってるんだそうな。
これまでの旅では、テント野宿はあくまで宿泊代を節約するのが目的で、キャンプ自体を楽しむという発想がありませんでした。。。
テントのほかに、自炊道具やアウトドアチェアも持っていけば、もっともっと違う楽しみ、発見できそうです。

ただ、花粉症なので、2月後半にもなると花粉がツライです・・・
来年からは冬キャンプやるにも、2月中旬までにしよう・・・

花粉症シーズンが終われば、自転車旅に最適な温かい季節がやってきます。
自転車での日本一周達成も視野に入ってきたし、次はどこ行こーかな~、と思いを馳せるのが楽しみなのでした。

自転車で山梨から静岡へ、富士山沿いの自転車旅 3連休1日目

2019年2月末の週末に有給休暇を1日くっつけて、自転車で山梨から静岡へ、富士山沿いの自転車旅をしてきました。
20190224_00.jpg


これまでの自転車旅


これまで長期休暇を何回か使って、小分けにして自転車で日本一周を目指してきました。経路はこちら。




日本一周とは別に、以下の場所へも自転車で旅をしてます。

今回の自転車旅の経緯


2/1(金)にNHKで放送された「ドキュメント72時間」、富士山のふもとにあるキャンプ場での真冬キャンプがテーマでした。

これまで真冬の自転車旅は避けてたんですが、こーゆうのも良いなぁぁ、と。
んで、この番組内で ゆるキャン△ というアニメのコスプレイヤーが登場してて、キャンプをテーマにしたアニメの存在を初めて知りました。



ちょうどBS11で再放送中ということで、第5話~6話と↑のニコニコ動画の第1話(無料)を見てみたら、意外と面白いw

しかも週末の2月23日は「富士山の日」ということで、もうこれは富士山を見に自転車で旅するしかない!

ということで、さっそく自転車で富士山を見に旅することにしたのでした。

1日目(2019/2/23)のスタート


初日は山梨県大月市のJR大月駅まで輪行し、ココから出発することにしました。
20190223_00.jpg

大月市は去年11月の自転車旅で初日に野宿した街なのです↓

自転車で東京から山梨&長野松本への旅 4連休1日目
http://makopi23.blog.fc2.com/blog-entry-293.html

やっぱ、出発地点は自転車で自力で行ったことがある場所がいいのです。
20190223_01.jpg

今回の旅から、椅子の後ろに荷台を取り付けました~
これで旅道具の積載量を増やすことができます。
20190223_02.jpg

山梨県の大月市を抜け、都留市へ。
20190223_03.jpg

国道139号を南西方向にのんびり走ります。
20190223_04.jpg

富士吉田市へ。富士山が見えてきました~
20190223_05.jpg

新倉山浅間公園へ向かう。新倉山を登る途中にある新倉富士浅間神社。
今回の自転車旅の交通祈願をしました。
20190223_06.jpg

398段ある「咲くや姫階段」を登っていきます。。。
20190223_07.jpg

新倉山の中腹にある新倉山浅間公園に到着。忠霊塔と富士山の構図が綺麗です~
20190223_07_01.jpg

新倉山浅間公園を後にし、南西4kmほど先の進行方向に富士急ハイランドがあるので寄り道。
20190223_08.jpg

富士急ハイランドは富士の裾野にあるアミューズメントパークです。入場無料なのがいいですね。
20190223_09.jpg

富士急ハイランドからも富士山が見えます。
20190223_10.jpg

富士急ハイランドから北に1kmほど行くと河口湖駅があります。
20190223_10_2.jpg

河口湖駅は富士急行線の終点駅で、駅前は観光客や登山客で賑わっています。
20190223_10_1.jpg

河口湖駅からもうちょい北へ進み、富士五湖の一つ、河口湖へ。
20190223_11.jpg

富士五湖は山梨県側の富士山麓に位置する5つの湖の総称です。河口湖はその1つ。大きくて綺麗~
20190223_12.jpg

「道の駅 かつやま」で休憩~
20190223_13.jpg

「道の駅 かつやま」は河口湖沿いにあります。
20190223_14.jpg

河口湖の隣にある西湖へ。
20190223_15.jpg

西湖も富士五湖の1つなのです。西湖の向こう側に富士山も綺麗に見えてます。
20190223_16.jpg

湖の北を走る湖北ビューラインにはブルーラインが引かれており、サイクリングロードになっているのです。のんびりペダルを漕ぐ~

西湖のそばに野鳥の森公園がありました。雪のオブジェがたくさん置いてあります。
20190223_17.jpg

精進湖へ。こちらも富士五湖の1つです。
20190223_18.jpg

精進湖と富士山をバックに、自転車のお写真1枚。雲が出てきて富士山が隠れ始めました。
20190223_19.jpg

精進湖の南にある本栖湖へ。こちらも富士五湖の1つです。
20190223_20.jpg

本栖湖はゆるキャン△の第一話でヒロイン二人が出会った場所です。
20190223_21.jpg

ゆるきゃん第1話で、志摩リンが自転車で抜けてきたトンネル。
20190223_22.jpg

ゆるきゃん第1話で、各務原なでしこが寝ていたトイレ。
20190223_23.jpg

ゆるきゃん第1話で、リンを追いかけてた各務原なでしこがひっかけて転んだチェーン(笑
20190223_24.jpg

本栖湖の湖岸にテントが結構見えます。ゆるきゃん効果かな?
20190223_25.jpg

本栖湖から国道139号を南下し、山梨県を抜けて静岡県の富士宮市へ。
20190223_26.jpg

「道の駅 朝霧高原」へ。
20190223_27.jpg

「道の駅 朝霧高原」もゆるキャン△の第三話に登場する聖地だそうな。
20190223_28.jpg

そして今回の本命、「ふもとっぱら」のキャンプ場へ。
NHKの「ドキュメント72時間」で紹介されたキャンプ場で、ゆるキャン△の第二話~第三話の聖地です。
20190223_29.jpg

到着して受付へ。
20190223_30.jpg

ゆるキャン△の第二話に登場するライオン(?)のオブジェクト。
20190223_31.jpg

18時前くらいですが、残念ながら雲が出てきて富士山は見えません。明日に期待~
20190223_32.jpg

こちらもゆるキャン△の第二話に登場する建屋。
20190223_33.jpg

テント設営完了~
自転車旅であちこちでテント野宿してるので、設営もずいぶん手慣れたものです。
20190223_34.jpg

日が沈み、テントに明かりが灯り始めました。
20190223_35.jpg

自炊道具は持ってないので・・・一度キャンプ場を離れ、最寄りのコンビニで食料とビールを調達~
これまでの旅は宿泊代の節約のためにテント野宿してたわけなんですが、自炊道具とかアウトドアチェアとかも欲しいな~

夕食を済ませた後、キャンプ場の大浴場でのんびり一日の疲れを癒します。

夕方は雲がすごく多かったんですが、夜遅くになると雲はほとんど無くなり、しかも満月だったので、ライトなしでも歩くことができるくらいでした。
トイレのためテントから出てちょと歩くわけなんですが、空気が澄んでいて、満月の明かりにうっすらと富士山の全容が見えるんですよね。
星空も綺麗でした~
20190223_37.jpg

この日は山梨県大月市から「ふもとっぱら」まで、78kmほど走りました。
20190223_36.jpg

2日目の日記へ
 

「JSUG勉強会 2019その2 Spring BootベースのDDDサンプル徹底解説!」に参加しました

2019/2/18(月) 「JSUG勉強会 2019その2 Spring BootベースのDDDサンプル徹底解説!」に参加してきました。

Doorkeeper
https://jsug.doorkeeper.jp/events/86655

Togetter
https://togetter.com/li/1320727

参加の経緯


これまで「エリック・エヴァンスのドメイン駆動設計」「実践ドメイン駆動設計」の読書会に参加したりして一通り書籍は読んでいるものの、コードのイメージが中々掴めないままでモヤモヤしてたので、このイベントはホントありがたい~

事前にGitHubのリポジトリからDDDサンプルをcloneしてEclipseにインポートし、手元でアプリを動かしてみたり、コードをいくつか眺めてみたりして、勉強会中にもすぐ見て触れる状態にしてから参加しました。

聴講メモ


DDD sample code explained in Java from 亨 増田


はじめに

始める前に (P.2)
  • 「面白かったらブログ書いてみようかな、と思ってる方、挙手!」
  • 「ブログを書いてくれる方は「現場で役立つシステム設計の原則」の書籍をお渡ししようと思います。」 By 増田さん




なぜ作ったか? (P.3)
  • まずV1としてシンプルなDDDサンプルを開発した。
  • V1は「どこがDDDなんだ?」という感じで具体性が無かった。なのでV2として大幅にバージョンアップして公開し直した。
  • 言葉でDDDについてやりとりしても具体性がない。コードが一番具体的に伝えられる。
  • DDDサンプルを作ってから現場で実際に話す機会があって、質問が具体的にできるようになった。
  • 今日はQAタイムでいろいろ話してみたい。


何の具体例か? (P.5)
  • キーワードは3つ
  • 1.ビジネスルールが複雑さの原因
    • DDD本の副題に「ソフトウェアの核心にある複雑さに立ち向かう」とあるが、ビジネスルールが単純ならば複雑にならない。
    • 複雑さはビジネスルールに依存する。
  • 2.計算をモデリング
    • オブジェクト指向でソフトウェアを作るのに、データモデリングはぜんぜん関係がない世界。
    • ビジネスルールを計算モデルで表現する。
  • 3.型指向でプログラミング
    • どう実装するのか、徹底的に型指向でプログラミングする。
  • 3/22の[DevLOVE Premium第3回]ドメイン駆動設計 本格入門のイベントで、なぜそう考えるのか、3点がどういう位置づけにあるのか、を詳しく説明する。


関心の分離 (P.6)
  • 「計算(ビジネスルール)を実行するモジュール群」と「データを入出力するモジュール群 」を、モジュールとして明確に分ける。



モジュール構造の選択 (P.7)
  • 業務アプリはトランザクションスクリプトで書かれているいることが多い。
  • そうでなく、型と型を組み合わせてドメインモデルを作る。
  • ドメインモデルはビジネスルールが中核。計算に登場する値の種類に注目して、型で定義する。


サンプルの概要 (P.8)
  • 時給ベースの給与計算モデルは、日付計算、時間計算、金額計算などのネタがある。
  • 契約や法律などのルールもある。給与は書面に署名して、契約して単価が決まる。背景に雇用契約がある。
  • 単価×数量、だけじゃなく、残業割増とか深夜割増とか、いろいろな要素がある。労働基準法でも決まっている。
  • なのでサンプルのテーマに選んだ。
  • 契約 + 法規 + どのくらい働いたか、等をぶつけると、給与の支払い額になる。
  • 給与計算ルールを62種類の型で記述している。
  • 今日は給与(Payroll)型をどう使ってるかを具体的に説明する。


この後の段取り (P.9)
  • まずドメイン層(ビジネスルール層)を固める。
  • 次に、ドメイン層を使って機能を実現するアプリケーション層を実装する。
  • 次にデータソース層、最後にプレゼンテーション層を実装しにいく。
  • 設計・実装の観点で考えるとこの順序になるので、今日の説明のこの順序で行く。
  • 最後に6番目でビジネスドキュメントをコードから出力するツールについて説明する。


給与計算 (P.10)
  • サンプルを動かして実物を見せながら説明する。
  • 「給与の一覧」画面がある。布川さんの2月の支払額は86,450円。
20190218_01.jpg


  • 「勤務時間の一覧」のリンクを押すと、勤務時間の一覧が表示される。いつ、何時から何時まで働いたか。
  • 勤務時間を計算すると、2/1~2/18までで91時間。
20190218_02.jpg

  • 「従業員の一覧」画面を見ると、布川さんの現在の時給は12/21から950円。
  • ずっと働いてると時給が上がることもある。今は契約として、時給が950円と決まっている。
20190218_03.jpg
  • 布川さんの2月の支払額、86,450円をどう計算しているか。
  • PayrollクラスのtotalPaymentメソッドが86450円を計算して返している。

  • ContractWageから契約給与を取ってきて、PaymentAmount(支払い金額)にaddしていく。
  • 契約条件(Contract)という事実と、どれだけ働いたかという勤怠(Attendance)の事実から計算する。
  • 細かい計算式はPayrollにはない。それぞれの種類のクラスが持っている。
  • 責任をクラスに割り当てていくと、給与計算ルールのクラス数が60くらいになった。

  • WageConditionクラスが賃金条件を決める。
  • ベースがいくらで、割増率がいくらで、といった事実は、WageConditionクラスのフィールドの各クラスが持っている。

  • これらをPayrollクラスのtotalPaymentメソッドで合算して86,450円を算出している。


ドメイン層(ビジネスルール層) (P.11)
  • ビジネスルールに基づいた計算が重要。その置き場がドメイン層。
  • modelパッケージとtypeパッケージの2つに分けている。
  • モデルそのものと、それを使う部品パッケージを分ける。
  • 最初からハッキリ分かれるわけではなく、行ったり来たりの試行錯誤を相当やっている。
  • 型指向のプログラミングについて、Wikiに設計ガイドラインを書いている。相当こだわって書いた。

  • Bean Validationで有効範囲を記述している。自己文書化してる。

  • Plain Old Java
    • 「可読性 over Java」については設計ガイドラインを見てほしい。
    • 例えば、イミュータブルなフィールドはprivate finalにすべき、という意見があるが、でもビジネスルールってどうなの?
    • privateとかfinalはこのDDDサンプルでは書いてない。 → ガイド該当箇所
    • そこらへんは実験してる最中。コードを読んだとき、ルールとして読みやすいこと重視してる。
    • Javaの構文のお作法にはこだわってない。
    • setter/setterはビジネスルールの表現手段としては全然意味が無い。Direct Field Accessを使う。
    • LombokやJPAのアノテーションも使わない。
    • ビジネスルールをシンプルに書くとき、それらのアノテーションはほとんど意味が無い。考え方として、それらは有り得ない。

  • Payrollクラス
    • Contract型(契約条件)とAttendance型(勤務実績)という2つの事実を知っている。
    • 戻り値としてBigDecimalとかは返したくないので、PaymentAmount型(支払金額)のクラスを用意している。


QAタイム (P.12)
  • Q1.
    • Payrollクラスの37行目、value()メソッドで値を取り出してるが、どこでvalue()で取り出すのかのガイドラインはあるか?
  • A1.
    • このvalue()メソッドは、無くしたい。このサンプルは完璧な完成系ではない。
    • ただ、timeRecord.workDate().value()と、ドット連結はイヤだな・・・
    • 言い訳をすると、パッケージ間の相互依存を無くすために、あえて型でなくプリミティブで値を使った。。。
    • パッケージ関係の依存関係を無くしたかった。パッケージ間の依存関係は重要で、依存関係を減らしたい。
    • プリミティブは徹底的につぶしにいく。


  • Q2.
    • PayrollクラスのtotalPaymentメソッドでreduceを使っていないのは何故か?
  • A2.
    • reduceよりもforの方が分かりやすいから。
    • Stream APIを増田さんが嫌っている、というのはある。 By irofさん
    • Stream APIはシビアに見極めないと、業務の表現として貧弱なところがある。
    • その言葉を避けようとするとforで書いたほうがいい感じになることがある。
    • Streamという言葉が出てくること自体を避けたい。
    • Haskellとか関数型言語は大好きだけど、Collection操作をそれでやってしまうと、Javaだと自然に書けない。。。
    • Groovyだとさくっと書けるけど、Javaだと素直に書けない。。。
    • Stream APIを主要なところで使うと、ノイズに見える。
    • どこまで読みやすくするかのバランスで決める。


  • Q3.
    • MailAddressクラスに文字数の上限のバリデーションが入ってない。
    • 一方、DBテーブルのメールアドレスのカラムはVARCHAR(255)で定義されており、255文字までという暗黙の制限があるはず。
    • ちなみにPhoneNumberクラスは文字数のバリデーションチェックがちゃんと入っている。
    • この差は何か?
  • A3.
    • サンプルの品質がばらついてるだけ。ただ、255文字という制限は微妙。。。
    • DBの制約はかけるだけかけたほうがいい。
    • ドメインオブジェクトも、それはそれで制約を書くべき。


  • Q4.
    • Payrollクラスについて。
      • ①getterは使わないという話だったが、37行目のvalue()メソッドはgetterにしか見えない。
      • ②TimeRecordsという複数形のドメインオブジェクトではなく、List<timerecord>というリスト型を使っているのは何故か?
  • A4.
    • ①について
      • getterを無くしたい、という意図は、値を持っているドメインオブジェクト自身で計算処理をさせたいから。
      • でも、複数のドメインオブジェクトを組み合わせて計算させるとき、value()を使うかの選択の余地はある。
      • できたらvalue()やgetterは無くしたい。意味がないgetメソッドとかは書きたくない。
      • パッケージに閉じてるなら、フィールド直接アクセスもありなんじゃないか。
    • ②について
      • List<timerecord>じゃなくてTimeRecordsに修正します。
      • 言い訳をすると、このコード部分はもっと処理を持っていたが、どんどん消して、今はこうなってる。
      • AvailableTimeRecord型を戻すようにすべき。


  • Q5.
    • ドメイン層のvalidationとController層のvalidationの違いをどう考えるか?
    • 例えば、管理者権限の場合はこのチェックをするとか、場合分けがある場合とか。
  • A5.
    • SpringのBean ValidationのGroupを使うとかで対処できるのでは。
    • あとは、権限の違いで処理を分けるというのはそもそも複雑なので、別アプリにしちゃうという考え方もある。



アプリケーション層 (P.13)
  • アプリケーション層は、計算モデルのPayrollクラスを使う側。
  • 基本的にはPayrollを生成する指示を出す。それが責務。
  • ① Query サービス : 計算結果を返す
  • ② Operation サービス:計算結果の記録/通知を指示する。
  • アプリケーション層の役割はこのどちらかになる。QueryとCommand、と表現されることもある。
  • (1) serviceクラス: repositoryにautowireしてin/outする。単機能。
    • 例: ContractQueryService、AttendanceQueryService
  • (2) coordinatorクラス: repositoryには一切autowireかけない。サービスとサービスを複合する。
    • 例: PayrollQueryCoordinator は ContractQueryService と AttendanceQueryService を複合してPayroll型を1個1個作る。それらをforでループしてaddして返す。


  • DBとやりとりをする単機能の要素が(1)のServiceクラス。
  • それらを組み合わせてなにか仕事してるのが(2)のCoordinatorクラス。
  • リポジトリは入出力の関心事が入ってるので、アプリケーション層に移動しようとしてる。
  • ロジックとか分岐とかは基本的にifで分岐しない。serviceに持たせない。
  • アプリケーション層は計算をかき集めて、オブジェクトにして返す。


QAタイム (P.14)
  • Q1.
    • joinでいっぺんに取ってこれるところもこういう分け方をするのか?
  • A1.
    • 計算モデルを作るところに振り切る。
    • こういう入出力で解決できるんじゃないか、はあるが、あえてやってない。
    • 計算モデルを実行するにはどうすればいいか、という組み立てをしてる。



データソース層 (P.15)
  • 増田さんはMyBatis一択。irofさんはDomaを採用したいと思ってる。
  • SQLを生でちゃんと書くという発想を大事に。
  • アプリケーション層から見ると、selectの実行を指示するとオブジェクトを生成してくれるのがデータソース層。Javaからみたらそういう世界。
  • DBとしてどういうデータ構造を持つのかは、計算モデルとは独立だと思ってる。
  • テーブル設計は、独立して良いテーブル設計を追及したい。
  • データモデルと計算モデルは、理屈では繋がってるが、実装でいうと、関心事が一致しない。
  • SQLという道具があるんだから、それで繋ごう。
  • ContractDataSourceクラスはmapperを定義して、mapperから取ってくるだけ。



データベース (P.16)
  • イミュータブルデータモデル
    • データベースの方は、イミュータブルデータモデルという考え方を大事にする。
    • イミュータブルデータモデルについては川島さんのスライドがある。
    • まず履歴がある。履歴に最新レコードが積みあがっていく。Insertオンリー。
    • 起きた事はまずinsertする。それが積み重なって履歴になる。
    • それだけで最新状態を導出できる。それで済むならそれで終了。
    • でも最新状態を知りたいので、最新をDelete + Insertで入れておく。
    • Updateを使わない。最新状態すらもCreate + Add。
  • 型とか制約は徹底的に書くべき。
  • とことん日本語。

  • ContractMapper.xmlはテーブル名もカラム名も日本語。
  • 読んだときにドキュメントとして意味がある情報をどれだけ持ってるか。
  • コメントでなく、コードを間違えるとエラーになるようにする。




QAタイム (P.17)
  • Q1.
    • DBは日本語に全部したとのことだが、Javaのコードは日本語にしないのか?
  • A1.
    • 区分は100%日本語にしてる。メソッド名とかは踏み切れない。あとIDEの補完とかも厳しいことがある。
    • 日本語だと大文字と小文字の区別とかができない。
    • 日本語だと複数形も表現できない。例えばTimeRecordとTimeRecordsの使い分け、日本語で分けるの難しい。


  • Q2.
    • DBでイミュータブルモデルを採用するとデータ量が膨らんでしまう。それで反対とかされないか?
  • A2.
    • そういうスケール問題が発生するような規模のプロジェクトじゃない。
    • 今はメモリとかパーティショニングとか、インフラが良くなってきている。
    • Oracle 7の時代では許してもらえないが。。。
    • 無視はできないが、今ならそこそこいけるんじゃないかな。


  • Q3.
    • 外部APIとか連携する処理はデータソース層に実装する?
    • 外部APIの仕様がイケてないので変換ロジックとかどこで吸収するか?
  • A3.
    • 外部APIとかの詰め変えはトランスファー層で入れる。
    • コントローラーのプレゼンテーション層にインバウンドを入れる。
    • アプリケーション層には外部の都合は入れない。


  • Q4.
    • 日本語のテーブル設計だが、IntelliJ IDEAを使ってると、補完が2段階になって止めようと思った。。。
  • A4.
    • IDEで補完してくれるようになった時代より前から書いてるから、補完は気にならない。
    • IDEの補完は、開発の生産性にあんまり関係ないかなと思っている。


  • Q5.
    • イミュータブルデータモデルについて。CRUDは普通にやって、Triggerを使って履歴テーブルに入れていくほうが効率が良さそうだが?
  • A5.
    • Triggerは使いたくない。いろいろ嫌な目にあってる。
    • でも、事実を記録してから残高を更新する方が、業務の考え方として正しいんじゃないかな。
    • 事実の置き方の順番として、これがいいのかなと思っている。


  • Q6.
    • データソース層のエラーの扱いをどうやってるか。
    • エラーをモデルに詰めてドメイン層に返す?
  • A6.
    • データソース層でエラーが起きないようにドメイン層で頑張る。
    • データソース層でエラーが起きたときは、システムエラーくらいにしておく。そういう場合は例外を投げちゃう。


  • Q7.
    • イミュータブルデータモデルで最新をDelete + Insertするのは同一トランザクションでやってるのか。それとも結果整合性で遅延同期を許すのか?
  • A7.
    • DDDサンプルはトランザクションを意図的に組んでない。
    • 最新って複数持つことも在りなんじゃないか。レプリカとか。
    • なのでトランザクションをガチガチに組むことは今はやってない。



プレゼンテーション層 (P.18)
  • ドメインオブジェクトをそのままviewに表示させる。naked objectパターンに従う。いちいちDTOオブジェクトに詰め替えない。


Naked Objectsパターン (Wikipedia抜粋
このパターンは、次の二つの仮定に基づいている。
・良質なドメインモデルがあれば、ユーザインターフェイスは、単純にドメインモデルを反映したものになる。
・ドメインモデルを直接反映したユーザインターフェイスが必要であれば、より良いドメインモデルの設計を余儀なくされる。


  • Spring MVCでは、デフォルトではgetter/setterを要求してくる。
  • なのでDirect Field Accessをtrueにして、getter/setter無しでもいけるようにしている。

  • CSSフレームワークとしてSemantic UIを使っている。
  • クラス名なんかを物理的構造よりも意味としてマークアップするという考え方が非常に気に入っている。

  • PayrollControllerクラスではPayrollクラスを作ってmodelオブジェクトに突っ込む。
  • modelオブジェクトに突っ込むのはPayrollのListではなく、Payrollsという複数型のドメインオブジェクト。
  • payrollの複数型のオブジェクトごとmodelから渡して、viewで取り出す。naked objectパターンに従う。
  • 計算モデルのオブジェクトの参照をプレゼンテーション層に渡す。
  • プレゼンテーション層の機能でレンダリングする。


JIGドキュメント (P.20)
  • https://github.com/dddjava/Jig
  • 冶具。コードで設計するためのツール。
  • コードやドキュメントを置き去りにせず、ループに参加させる。
  • ビジネスルールをドメイン層に独立してドキュメント化する。
  • 日本語はjavadocコメントとpackage-info.javaで書いてる
  • ソースに日本語を埋めてると一覧に出せる。
  • 出てきそうな用語がクラスに抽出されている。
  • JIGでドキュメントを出すと、怪しげな名前や歪みが分かるので修正する。
  • パッケージの依存関係も生成ドキュメントから分かる。
  • コードだけ見てると部分部分はよく書けて見えるけど、JIGをかけるといろいろわかってコード改善ができる。
  • Enumの使用関係も出せる。ビジネスが複雑になるのは区分が複雑になることが多い。
  • 型の依存関係を詳細レベルで出せる。ホットなノードがわかる。
  • 相互参照があると赤字になったりする。
  • どのserviceがどのrepositoryを呼んでるか、どのrepositoryがどのクラスをinsertしてる、select、deleteしてるかを出せる。
  • 可能な限りリストにしてる。一覧形式で見ると、あれっ、と思うところが見つかる。
  • identifierとかenumとかnumberとか、使用箇所はどこで何か所あるか、とか分かる。
  • 真偽値よりenum返したほうがいいんじゃないか、とか、注意メソッドシートに出してくれる。


最後の質疑応答
  • Q1.
    • このDDDサンプルができるのにどのくらいの時間、試行錯誤にかかったのか?
  • A1.
    • 朝から晩までやって1か月くらいかな。1~2週間のレベルではない。
    • コアをどこに置くかを決めるのにまず作って会話した。まず動かすモノを作ったの大きかった。


  • Q2.
    • DBの方はイミュータブルデータモデルでupdateを使わないという話があった。
    • 一方、Javaオブジェクトはprivate もfinalも使わない、という話があったが、そうすると、書き換えられてしまうのでは?
  • A2.
    • 教育するしかないのかな。。。


  • Q3.
    • 新人研修でこっちの世界にどう導けばいいか。。。?
  • A3.
    • Javaのプログラミングの基本をちゃんとする。
    • intとintを足すとオーバーフローするでしょ。オーバーフローしないようにちゃんと型を使う。
    • booleanとintの足し算はできない、というところをきちんと教育する。
    • 型は、何が許されているのかの知識。
    • クラスを使って独自の型を定義できるのがいいんだよ、に目覚めてもらう。


  • Q4.
    • 大規模プロジェクトでDDDを使おうとして、オフショアに出したいと考えている。
    • 基本的なところは少数でやって、以降はオフショアに出したい。
    • どういうふうにやればいいいか。
  • A4.
    • 構造の部分はコアメンバーで頑張る。
    • 構造が固まった範囲でモジュール分割して、オフショアに出す。
    • でも、可能な限り少人数で密にやったほうがいい。
    • 可能な限りオフショアじゃなくて日本人で頑張ってほしい。


  • Q5.
    • DDDより形式手法を当てはめた方が、より素直に作れるのでは?
  • A5.
    • 形式手法の考え方は、静的な型付け言語では既にそうなってると思ってる。
    • でも「形式手法」だけでは伝わらない。
    • Javaがダントツでいいと思ってる
    • 型を静的に作って形式的に整合性をとる。

感想


すごく濃い話の連続でした。。。

SpringとMyBatisは普段使ってるし、こーゆうサンプルがあるとホント助かります。
DDD本の題材になってる貨物輸送、サンプルとしてはちょと題材が特殊すぎて馴染み薄すぎるねん。。。
IDDD本のアジャイルツールのサンプルも、GUIのWebアプリじゃないからイメージ湧かないし。。。

Spring BootだとTomcatや簡易DBも内蔵されてるので、サンプルとして気軽に動作させられるのもいいですね。
DDD本、ちょと抽象的な要素が多いので、このサンプルを傍に置いて読むといいんじゃないでしょうか。

増田さんはじめ、勉強会の関係者の皆様、ありがとーございました。

「Developers Summit 2019」に参加しました

2019/2/14(木)~2/15(金) Developers Summit 2019に参加してきました。

公式サイト
https://event.shoeisha.jp/devsumi/20190214/

今年もなんとか仕事に都合をつけての参加です。
2日目は仕事の都合上、13:50終了のセッションまででしたが。

20190214_01.jpg

ちょと気になったセッションの聴講メモをブログに残しておこうと思います。

Scrum@Scale入門





ちょうど仕事で大規模スクラムのプロジェクトに関わってるので聴講しました。以下メモ。

権力の源泉 (P.6)
  • 農耕時代は「土地」と「労働力」を持ってる人が強かった。
  • 産業時代は「資本」と「労働力」を持ってる人が強かった。
  • 今の情報時代は「知的労働力」と「情報」を持ってる人が強い。それをどう集められるかがキー。

Power to the Edge (P.7~P.8)
  • 昔はコマンド&コントロールといえば「指揮命令系統」だった。
  • 「末端に判断する権限を委譲できる組織を作らないといけないよ」という意見が出てきたのが10年前。
  • 米海軍の、指揮命令しない艦長の最強組織。意図を伝えることによるリーダーシップが重要。

アジャイル時代 (P.9)
  • 顧客第一
  • 「ちいさな独立したチーム」が寄って集ってなんとかする
  • ネットワークを使って仕事する

チームの人数 (P.10)
  • 5人のコミュニケーションパスは10個。みんながみんな知っている。意思決定の速さにつながる
  • 9人だとコミュニケーションパスは36個。だいぶ辛い。

Agility をスケールさせるには? (P.11)
  • 何をスケールさせるのか?
  • P.12は中国の住宅の例。同じ家をスケールさせた結果、誰も住まなくなった。
  • P.13はトルコの例。今度は城を並べてスケールさせた。これも破綻した。
  • 横スケールのコピペは上手くいかない。横展開は難しい。
  • コピペでチームは作れない。
  • スケールアップ、アウトしかできないのなら、それはスケーリングじゃなくて膨張してるだけ。

スケールが必要なのはなぜか? (P.15~18)
  • P.16はチリの貧困者住宅。
  • Aravena氏が作った。TEDの彼のプレゼンが面白いのでぜひ見てほしい。
  • 貧困者住宅が完成して入居後、風景が一変した。
  • スペースが空いてる場所は、住人が自分たちで埋め始めた。
  • 住人が自分自身で作る。1階を倉庫にしたり、作業部屋にしたり。
  • そして、住んでる人同士がメンテナンスのノウハウを共有し始める。
  • 住宅を半完成の状態で住人に渡したのは、貧困者住宅なのでお金が足りなかったから。
  • スケーリングはこの例のようにしたい。
  • 「アジャイル開発標準」なんてつくってるんじゃねーぞ(笑

スケールさせる前に・・・ (P.19
  • スケールさせる前に、上手くいってるスクラムチームを2つ育てること。
  • そうしないと、良くないチームをスケールさせようとする。
  • いいチームができてから、それをスケールせよ。

Scrum @ Scale Framework (P.20)
  • スクラムガイドはプロダクトオーナーに冷たいので、POについてあんまり書いてないw
  • Scrum @ Scaleではプロダクトオーナーのサイクルがある。なぜプロダクトが必要なのか。
  • スクラムマスターサイクルもある。これってデプロイサイクルじゃないか、という話もあるが。作ってデプロイするまでのサイクルになってる。
  • この2つのサイクルがscrum@scale


スケールフリーアーキテクチャ (P.22)
  • 幾何級数的にスケールしたいなら、「スケールフリー」なアーキテクチャが必要。
  • ジェフ・サザーランドのスクラムはいきなり十数チーム。

スケーリングの課題:官僚主義と階層 (P.23)
  • 3~7のチームが集まって、チームがチームとして動くにはどうすればいいかがscrum@scaleの課題。
  • 官僚主義を最小限にするのがscrum@scale。

デイリースクラムのスケーリング (P.24)
  • スクラムオブスクラムを使う。
  • さらに階層化する。
  • Scrum of Scrums Master(SoSM)が必要。

スケール化デイリースクラム (SDS) (P.25)
  • デイリースクラム終わったら、代表者で集まって共有する。それがどんどん上にあがっていく。

エグゼクティブアクションチーム (P.26)
  • EAT(エグゼクティブアクションチーム)が一番上にいて、会社の役員レベルで構成される。
  • EATはスクラムマスターがやることをやる。チームの妨害を取り除く。
  • チームのスクラムマスターはできることが限られてるので、チームレベルで対処できない場合は上の層へエスカレーションする。
  • 3段階上くらいにEATの役員がいる。EATがその場で判断する。持ち帰りは許されない。


SAAB Technologies社の事例 (P.28)
  • 「みなさん、エースコンバットは好きですか?」 by 原田氏
  • SAAB社では戦闘機の「グリペン」を作ってる。
  • グリペンは半年に1回、ニューバージョンが出る。費用対効果が高い戦闘機。
  • いつもバラしてるのでメンテナンス性が高い。
  • デイリースクラムを4段階の階層でやってる。2000人を1.25時間で同期してる。


EATには誰が必要? (P.29)
  • EATで、承認なしにすぐ決めれるようにする。
  • EATにはCOOとかCTOとかを入れて、財務権限がある人も入れて、人事や法務の担当者も入れる。
  • スクラムのチャンピオンとかも入れる。

プロダクトオーナーをスケールする (P.30)
  • チームのPOに権限移譲できるようにする。
  • POもグループを作る。
    • CPO MetaScrum: POを集めたチーフプロダクトオーナー
    • Excecutive MetaScrum: チーフチーフプロダクトオーナー

スクラムマスターとプロダクトオーナーの スケーリングの違い (P.32)
  • マネージャは妨害を止めるのが仕事なので、POよりはスクラムマスター寄りの役割。
  • なのでPOはマネージャである必要はない。
  • スクラムオブスクラムマスターは「みんなで寄って集ってなんとかしよう」という考え方。
  • POはちょっと違う。意思決定が勝負。
  • 上のPOの判断が絶対。相談しない。迷ったらチーフPOが決める。
  • POは「調査してから・・・」だと遅い。調査で待たせるよりは、今すぐに判断をして、間違えろ。
  • POは後回しにするな。次のイテレーションで取り返せ。すぐに間違えることでチームも自分も学ぶことができる。

組織の状況を見える化するところから (P.35)
  • 壁に自分の組織を付箋で書く。付箋の色で課題状況を示す。
  • 紫の付箋が、全然ダメなところ。紫→赤→黄色→青の順に良くなる。
  • どのへんが赤いかがわかる。
  • 壁にずっと貼っておく。通称、恥の壁。

Scrum@Scale の利用方法は組織によって異なる (P.36)
  • Scrum@Scaleを組織にどうやって入れるか、詰めるかはScrum@Scaleのガイドには書いてない。自分で詰めろ。
  • チームに必ずPOとスクラムマスターがいるのは狙いがある。両者くっついてるので、チームごと、ごそっと動かせる。
  • ニーズが増えたところにチームごと移動させられる。チームをゼロから立ち上げる労力に比べれば、はるかに短くて済む。
  • チームを壊さないでください
  • POはビジネスのインタフェースとしての役割もある。
  • EATもスクラムチーム。見積もらないといけないし、デモしないといけない。


マネージャで一番大事なのは、チームの邪魔をしないこと



Scrum@Scale、日本語版のガイドも公開されています。




エンジニアの知的生産術 ビフォー・アフター



↓をクリックすると資料のPDFに飛びます。
20190214_02.jpg

自分の勉強方法や読書方法についてモヤモヤ感が否めないので、なにかキッカケを得られれば、と思って聴講しました。
以下メモ。

「エンジニアの知的生産術」の書籍を執筆 (P.2)


学びの加速 (P.11)
  • 学ばない人よりも学ぶ人の方が上を行くが、学ぶ人と学びを加速させる人との差に比べれば微々たるもの。
  • 学びを加速させていかないといけない。それが長期的な大きな差につながる。

「理解」は「仮説」 (P.17)
  • 「理解した」という気持ちは仮設でしかない。
  • 実行して動作を見る。「手を動かす」ことによりアウトプットする。

サイクルを小さくする (P.19)
  • 報酬のサイクル: 「動かない」→「動いた」→「楽しい」
  • 仮説検証のサイクルを小さく高速に回す。

行動によって検証する (P.21)
  • 「知識を行動によって検証する」が学びに重要。
  • アウトプットが大事。学んでからアウトプットしよう、ではダメ。
  • LTとかも有効。
  • まず20文字くらいの付箋に書いてみよう。まず書くこと。書くと情報が消えないので、安心できる。
  • 脳を、情報を組み立てる方に投資する。

今 (P.28)
  • 魚の絵。水面下にあるものを言葉で表現してフックをかける。
  • フックをかけて水面上に釣り上げる。フックする、ハンドルする方法を手に入れることによって思考がやりやすくなる。
  • 思考の効率を言葉が底上げする。

Scrapbox (P.31)
  • 知的生産術を支えるソフトウェアがScrapbox。情報間のつながりを表現するコストを極限まで減らし、記述しやすくしてる。
  • Wikipediaのページ間リンクは有効だけど、Wikipediaは全世界に公開されるので汎用的にしか書けない。
  • それに比べ、Scrapboxは個人で使えるので自分の好きなように書ける。
  • 書籍だとリンクや参照を書いても、すぐに飛べない。一次元のインプットにしかならない。Scrapboxはそうじゃない。
  • 西尾泰和のScrapbox


講演終了後、内容に興味が沸いたのでデブサミの書籍販売コーナーで10%割引やってるし早速購入~
20190214_03.jpg



感想


今年のデブサミも楽しく有意義なヒトトキでした。
他のセッションも興味深いのいくつかあったので、スライド公開されたら追記するかも。

デブサミ関係者の皆様、有意義なイベント今年もありがとーございました。
また来年も仕事に都合をつけて、なんとか参加したいと思うのでした。




ボートレース平和島へ、人生初の競艇に行ってきました

2019/2/3(日) ボートレース平和島へ、人生初の競艇に行ってきました。

公式サイト
http://www.heiwajima.gr.jp/

競艇に行ってみよう、と思ったのはちょっとしたキッカケでした。

自転車で日本中あちこち旅して観光名所もかなり制覇してるんですが、今住んでる地元について実は結構知らないこと多いなぁ、と。
灯台下暗し、というやつです。
Googleマップで自宅の周りを眺めると、さすがに東京都品川区ということで、観光ポイントたくさん見つかります。

そんなわけで昨日は自宅からすぐ近くにある品川区立品川歴史館とか大森貝塚遺跡庭園とか、のんびりサイクリングしつつ回りました。

ところで、Googleマップで一番目立つ自宅最寄りの拠点は大井競馬場ボートレース平和島なのです。
個人的にギャンブルはまったくしない性格なので両者とも行ったことなかったのですが、せっかく近場にあるのでちょと行ってみよう、と思い立ったのでした。
両者とも、自転車なら10分くらいで行けちゃう距離なのです。

2/3(日)は競馬はやってないけど競艇はやってるということで、今日はボートレース平和島の方へ行ってみることにしたのでした。

ボートレース平和島へ


自宅を朝10時すぎに自転車で出発して、10分ほどでボートレース平和島に到着~
20190203_01.jpg

入場料はたった100円!
舟券を買わなければ、100円で一日観戦することも可能です。

中に入るとこんな感じ。
20190203_02.jpg

スタンドへ。
20190203_03_.jpg

舟券を買いに、スタンドから中に戻り、券売機へ。
20190203_04.jpg

近くにいた係の人にマークシートの記入方法を教えてもらい、券売機で舟券を購入~
20190203_05.jpg

この日は1Rから12Rまで、12レースありました。
とりあえず午前に行われる1R~3Rまで、1Rずつ100円だけ賭けました。3レースとも2連複で。

1R開始!
20190203_07.jpg

負けました・・・

前日に公式サイトの初心者向けページ 「BOAT RACE GUIDE」 には一通り目を通しておいたおかげで、十分に楽しめます。
午前のレース分、3Rまでとりあえず舟券買ってたのですが、なかなか興味深かったので、午後の最終12Rまで今日はのんびりしようと思い直しました。

屋内には売店や出店がたくさんあります。吉野家とかもありました。
20190203_08.jpg

値段も良心的です。コロッケとか60円だし。
行楽地へ行くとメニューの価格がすごく高かったりすることありますが、ここはそんなことありません。
昼食も屋内のお店で取りました。ソースカツ丼ならぬ、ソース勝丼~

無料のドリンクコーナーもあり、温かい緑茶や麦茶が飲めます。
入場料100円なのにこのサービスは素晴らしい。
20190203_09.jpg

屋内にはあちこちに予想屋さんがいます。緑の服の方です。この予想屋さん、大繁盛してました。
20190203_10.jpg

予想屋さんは各レース前にレース展開を予想し、自分の予想や見解を周りの聴衆に熱く語ります。
そして最後に、自分の予想を書いた紙切れを威勢のいい掛け声とともに聴衆に売り捌きます(笑
予想が書かれた紙切れは1枚100円で貰えるみたいでした。
聴衆がどんどん机に100円を置いて、予想屋さんが威勢のいい掛け声とともに紙切れを頒布していきます。

ボートレース平和島の隣に「ボートレース平和島劇場」という建物があります。
ボートレース場の出口の発券機で再入場券を発行し、いったん外に出て、隣の「ボートレース平和島劇場」へ。
20190203_11.jpg

中はこんな感じ。入場無料。
平和島レース場以外の、同時刻に行われている全国各地レース場の舟券が買え、大画面でレース中継もされています。
20190203_12.jpg

左の大画面は平和島のレース場、右の大画面は常滑のレース場。
常滑は今日、GⅠレースだったそうな。
20190203_13.jpg

「ボートレース平和島劇場」からまたボートレース場に戻り、しばし観戦~
14:00からはボートレース場でB.LEAGUEバスケの試合をスマホで観戦しつつ、目の前のレースをのんびり楽しみました。

1R~8Rまではハズレばかりでしたが、9Rにようやく的中!
20190203_14.jpg

2連複の1番人気で倍率は2.6倍だったので、100円を賭けて、払い戻しが260円(笑
20190203_15.jpg

1R~12Rまで全部ハズれだとさすがに悲しいですが、なんとか1レースでも的中して良かったw
20190203_21.jpg

ボートレース平和島の公式Twitterさんも楽しそうです。


最終12Rレース前の予想屋さん前。大繁盛~
20190203_16.jpg

12Rは出走者6人全員がランクA1ということで、エース級のレーサー同士の勝負です。
最初、2連複1-2で舟券を買ったんですが、倍率が3倍くらいしかなくて個人的にちょと盛り上がりに欠けたので。。。

これが最後のレースだし、最後だけもう1枚舟券を追加で買うことにしました。
購入締め切り3分前くらいに急いで券売機に行き、2連複2=4の倍率約20倍の舟券を追加購入~
20190203_17.jpg

そして・・・見事的中! 最終レースで奇跡w
20190203_18.jpg

最終レースは途中から4-2の先行逃げ切りだったので、「うおお、これは行ける~~!」てな感じでハラハラ見てました。。。

最後に買った100円が、1950円になって戻ってきました(笑
20190203_19.jpg

結果、1R~12Rまでの12レースで、2勝10敗・・・
1Rずつ100円だけ賭けて、最終12Rだけ追加でもう100円賭けたので、支出は1300円。
収入は9R的中の260円と、12R的中の1950円の、合計2210円!
収支は910円の黒字でした(笑

ちょとだけ儲かったので、今日は節分だし、豆と恵方巻を買って帰ろう~

最終レースに勝利し、ほんわか暖かな気持ちで帰宅の途へ~
20190203_20.jpg

感想


初めての競艇だったけど、とっても楽しく新鮮な一日でした。
入場料たった100円だし、これなら本とか持参して、のんびり1日過ごすのも良いかなーと思うのでした。
レースを見るのも楽しいのですが、周りの人々の喜怒哀楽や立ち振る舞いも新鮮でした。
普段の私生活や仕事ではあまり関わることのない背景の方々がたくさん来ていて、こーゆう世界もあるんだな~、と。。。

1レース100円ずつ賭けるだけなら、1日12レース、たった1200円でちょっとしたドキドキ感を味わえます。
また今度、是非行ってみようと思うのでした。

-->