2019年12月30日月曜日

4 人で麻雀を 3 年間続けた結果

麻雀力がほぼ同じレベル 4 人で毎月一回のペースで麻雀を 3 年間続けてみました
成績をすべて記録していたのでどうなったの紹介します
また続けるため方法やコツを紹介します

背景

熱中できることを探すシリーズ第三弾かもしれません
月に一度やるということが重要かなと思い始めてみました
結局 3 年間も続いたのでせっかくだから成績を公開しようかなと思った次第です

成績結果

とりあえず成績です
試合数は三人麻雀もあるのでバラバラですが 3 年間全部で 233 回戦です

  • Y -> + 615
  • M -> +779
  • H -> -996
  • I -> -398

総合得点の月ごとの変動グラフはこちら

プレイ動画

さすがにカメラが複数台あるわけではないので毎局全員分は撮れませんが各局ごとに一人分のプレイ動画を後ろから撮影したりしています
みな素人なのであしからず

結果からわかったこと

なーんとなくですが感じたこととしては

  • 一番上と下で一番点差がついたのが 1775
  • 実力が拮抗していれば回数を重ねればそこまで大きな差は生まれなさそうと当初は思っていたけど思った以上に開いた (収束するかもしれない)
  • データ取るとおもしろい
  • ちょっとづつ上手くなっている気がする

あたりかなと思います
上がり続けているときの打ち方は続けたほうが良いとか下がっているときは打ち方を変えてみようかなといった判断にも使えました

以下感じたことなどを雑記レベルで書いていきます

人読み

よくプロの公開対局などを見ていると「人読み」という言葉をよく聞きます
始めはそんなに気にしていませんでしたがやり続けると気にするようになりました
特に同じメンバーで打っていると気にせずにはいられなくなりました

「この人はこういう待ちをよくする」とか「この順番で捨てる」とかはあるかなと思います

ただ読み筋の情報としては価値はそこまで高くないかなと思います
おまけというかあとひとつ理由がほしいときに人読みする感じかなと思います
逆に人読みが優先してしまうと個人的には押すときに押しづらくなる感じがあるのであまり優先しないようにしています

ローカルルールを決める

結構細かいところまで決めていたかなと思います
例えばローカル役満として認めていたのは「大車輪」や「大数隣」「大竹林」あとは「紅孔雀」もありにしていました (出たことありませんでしたが)
ダブル役満とかトリプル役満とかはありにしていました (出たことありませんでしたが)
通常役は基本的なルールと同じでした
チートイツとイーペーコーを絡めるというローカルルールもあるようですがなしにしていました

あとは「残りツモ番なしのリーチはあり」とか「オープンリーチあり」とか」ダブロンあり」とか、とかとか結構いろいろ決めて管理しています
困ったときはルールブックを見てルールブックにないことが起きた場合はその場で決めて新たにルールブックに記載するようにしていました

そこまでやる必要は正直ないと思いますが勝負事なので結構大事です
「え、ありでしょ?」「いや、なしでしょ?」みたいな水掛け論にはなりたくためというのもあるかなと思います

スケジューリングが一番大変

基本は月イチで打っていました
みな社会人なので月イチ程度でないとメンバー全員が予定を合わせるのが厳しかったためです

スケジュールを決めるときも少しルールを設けていて

  • 毎週金曜日 18:00 から 23:00 まで
  • もし前回これなかった人がいたらその人の日程を優先する

というルールを設けていました
あとは LINE で細かい調整をして前月中に決めていく感じです
あとで紹介しますが三人麻雀もできるメンツだったので最悪 3 人しか集まらなかった場合は三人麻雀を開催していました
そして来月は来れなかった一人を優先するという感じです

雀荘に通い続けたほうが良い

月イチで雀荘に通っていると場代だけでも結構な額になります
しかも 3 年も続けていると余裕で全自動卓なんて買えちゃうくらい払っていると思います
それでも自分は雀荘を使ったほうが良いかなと思っています
理由はいろいろあると思いますが一番なのは以下の通り

  • 雀卓の管理が面倒
  • スペースの管理が必要、雀卓以外の椅子や机
  • 誰が管理するのかという問題と管理している人のところに行って毎回やるのが不公平感を抱く
  • 別料金だがメシとか飲み物がお願いすれば出てくる

かなと思い
であれば毎回借りていただほうが管理コストがなくなるので良いかなと
あと片付けとか掃除も最低限のマナーだけ守っておけば良いので

このあたりは人によってだいぶ意見が分かれるところなので将来的に 10, 20 年続けるのであればさっさと買ってしまうというものありだと思います
自宅が広いとか部屋が余っているなんてメンバーがいればなおよしかなと思います

月イチくらいがちょうどいい

これは先程のスケジューリングの理由も影響していますが月イチくらいの頻度で打ったほうが体力的にもモチベーション的にも良いかなと思います

体力的な意味だと麻雀は結構体力を使います
自分たちは一回で 5 - 6 時間打ちますがそれでも終わった後は結構疲れます
しかも次の日を考えるとそれくらいが限界かなと思っています
よく徹マンするケースもあると思いますが集中力も切れて次の日以降への影響も大きくなるので、自分たちはもうできないかなと思います
もちろん徹マンも楽しいので全然やりたい気持ちはありますが気持ちよりも先に体にガタがくるという感じです

モチベーション的にも月イチはちょうど良いかなと思います
開催間近のワクワク感はかなり充実したものが得られるかなと思います
物足りなさを覚えてるときもありますがそこは我慢して (というかスケジューリング的にできないのですが) 翌月頑張ろうという気持ちに変えています

どうしても打ちたい場合は年末年始の長期連休や夏休みなどの長期連休を使って不定期に開催することもありますがかなり稀です

三人麻雀を覚えると続けやすい

実は打ち始めた当初三人麻雀など知りもしませんでした
スケジューリングの都合でどうしても 4 人集まらない場合が結構あり、その場合は次月に延期していました
個人的にそれの「延期」が非常に嫌で毎月続けることが大事かなと思っていました (後述)
だったら三人麻雀を覚えればいいじゃないかということでメンバーと相談してみんなで覚えて打てるようになりました
始めはかなり手探りでしたが簡単に言えば萬子の 2 から 8 がないバージョンなのですぐに覚えた気がします

ちなみに三人麻雀の点数配分や役などもルールブックにちゃんと記載しています
三人麻雀の満貫以下の子のツモはよく忘れるのでルールブックに記載するようにしています

続けることは大変であり良いことである

結局言いたいのはこれかなと思います
月イチですが 3 年間続けられた事実は素晴らしいことかなと思います
特に麻雀のような複数人で遊ぶ娯楽でそれができたのは特に良かったかなと思います

そもそも麻雀が好きなので続けられているのが一番ですがちゃんとペースを守って続けられたのは今後 10 年 20 年、もしかしたら死ぬまで続けられることができる趣味が見つかったのかもと感じています
もしかしたら急に熱が冷める可能性もあるかもしれません
そしたらまた別の趣味を同じメンバーで見つけられる気がしています、たぶん

あとは毎月の楽しみな趣味が一つあるというのも良いことだと思います
よく「次の月の xx まであと何日!」みたいな感じで日頃のモチベーションを保つ人もいるのでそういうことにも使えるかなと思います
また年間にすれば 12 回も楽しみなことが待っていると思うとそれだけで頑張れるような気になれる人もいるかもしれません

継続はなんちゃらと言いますからね

最後に

なんかエモい感じの記事なってしまいましたがみなさんも友人と熱くなれる趣味を見つけてみてはいかがでしょうか
思わぬ発見があるかも

2019年12月25日水曜日

2019 できたこと・できなかったこと

去年に引き続き今年もやりました

できたこと

時系列

資格、DIY、麻雀、ダーツと趣味に関しては満遍なく成果を上げることができた
動画に Output できたのは個人的にチャレンジャブルで Good ポイントだったと思う

その他

  • ブログ執筆数: 254 (12/23 時点)
  • Podcast エピソード数: 12
  • 資産運用を継続できた

これらは去年から引き続きがんばれたかなと思う

できなかったこと

  • Youtube Live (去年に引き続き)
  • 3D ゲーム開発 (去年に引き続き)

ライブはもうやらないかもしれない、、
3D ゲーム開発は Swift でやるか悩んでいるが Unity を使わざるを得ない気がする

来年の豊富

  • 3D プリンタの購入とおもちゃの手作り
  • モチベーションを維持する

全体的なモチベーションの低下が今年は結構感じれたので来年は現状維持で良いのでしたい

2019年12月19日木曜日

今更ながら達人プログラマーを読んだので感想

今更ながら達人プログラマーを読んだので所感を備忘録として残しておきます
読んだのは翻訳版です


はじめに

本書内ではいくつのサンプルコードが出てくるが主に C++ や Java になっている
具体的なコーディング方法などが紹介される場面もある
そういった場面では基本的に C++ や Java がベースになっているので自身で使われている言語のニュアンスと少し食い違うケースがあるかもしれない
Perl や Ruby などの高級言語もちらほらでてくるがメイン言語としては使われておらずコードジェネレートの際のパーサスクリプトなどに使われいる

また本書はある程度プログラミングの知識と経験のある人向けかなと感じた
タイトルに「今更」とつけているが今更と思うくらい後に読んでも全然大丈夫だと思う

本書内で出てくるワードがわからない場合は検索しながら読み進めると良い

特に重要だと感じたフレーズ

  • 二重化しないためのコードジェネレート
  • コード、モジュール同士の結合度を最小に抑える

印象に残った言葉、フレーズ

  • プラグマティズム、実践的な
  • 十分に幅広いバックグラウンドと経験が基盤にあってこそ、特定の状況に応じた優れた解決策を選択できる
  • 達人プログラマーの性格「新しい物好き」「研究好き」「批判的」「現実的」「何でも屋」
  • 弁解の代わりに対策を提案
  • good enough でいい、やりすぎない、やめ時を知る
  • 自分の知識に対して定期的に投資しなければならない
  • DRY (Don’t Repeat Yourself)、二重化、重複は NG
  • 片方を変更しても他方に影響を与えない場合、それらを直交していると呼ぶ
  • 曳光弾を打つ -> 常に目標やゴールを見据えながら開発する、プロトタイピングではない
  • プロトタイプの真の目的は学びにある
  • OS やデータベースのバグは少ない、まずは自分たちのアプリを疑う
  • 完璧なソフトウェアは存在しないし作れない
  • DbC (Design by Contract) 契約プログラミング、契約に従わない実装を防ぐことができる、呼び出し元/先の責任分界
  • コードの修正時、どういった影響があるのか分からないという理由で、開発者達が及び腰になってしまう
  • 偶発的プログラミング、おそらくそうであろうという環境やコンテキストを想定して開発してしまうこと
  • 要求は掘り起こすもの
  • あなたが作った 200 ページにも及ぶドキュメントを承認しているかもしれない、しかしいったん実際に稼働しているシステムを見た途端、星の数ほどの変更を要求してくる
  • テストのカバレッジを 100% にすること自体を目的にしてはいけない
  • 状態のカバレッジをテストすること

これらを踏まえて疑問に思った点や自分なりに考えた点は以下の通り

疑問点、所感

割れた窓理論について

細かいことを気にしすぎると返ってコストの問題などで大変なことになりそう
だったら 1 から作り直すなど大きな枠で変革するほうが良いのではないのかと思った
腐敗の加速のほうが速いことも可能性としてあると思う (それ以上に速く沈下できるようになれというメッセージなのかもしれないが)

あとは単純に割れた窓に気づくことができないケースがありそう

考え方はプログラマ以外にも通ずるところがあると思う

「自分の知識に投資しよう」とか「情報を伝達しよう」といった考え方はプログラマ以外にも通ずるかなと感じた
ただ伝達する際に「WISDOM を考えよう」とか「質問をするタイミングを考えよう」という教えがあったが、質問するためにそこまで考えなければいけないのであれば自分で調べたほうが早そうな気がした
そして伝達に e-mail をオススメしている感があったのでそれも、うーん、、という感じだった
たぶん重要なのは証跡を残そうということだと理解した

二重化を防ぐためのコードジェネレータ

例えばヘッダファイルを自動で生成したりクラスファイルをデータベースの構造から自動で生成するようにしようという感じ
最近だとフレームワークが頑張ってくれるケースのあるので導入は簡単な気がする
ただコードジェネレータにバグがあるという可能性を考えるとあまり頼りすぎるのも良くない気がした
この辺りは「邪悪な魔法使い」の部分でも言及されていた
要するに中身がよくわかっていないコードジェネレータは中身を理解するまでは使うなということ
また本書内ではいろいろなケースのコードジェネレータが出てくるがそれらの二重化はどうやって防いでいるのか気になった

ドキュメントドリブンに開発する際にドキュメントが変更されるとテストも必ず変更する必要があるからドキュメントを変更するとテストも自動で変更される仕組みを作るというアプローチは良いアプローチだと思った

あと二重化している箇所に気づくのは結局人によるレビューしかないのかなと思った
そういうツールも現代だとあるのだろうか
このあとで紹介してる「直行性」に関しても同じようにどう気づくのかがポイントかなと思った

というか完全に二重化していない直行しているシステムなんて作れるのだろうか
しかもそれを開発の初期段階から意識してできるのだろうか (できるようになれば達人ということだと思うが)
またコードジェネレートに関しては本書内で至るところに出てきた印象があり筆者としてもかなり推したい手法なんだと感じた (Perl)

具体的なアプローチに落とし込めるか

前述の二重化や直行性を解決するのにコードジェネレータを使ったり AOP のアプローチを使おうという紹介はある
それらを読んで実際のプロダクトに適用する際に具体的なアプローチにまで落とし込めるかがポイントかなと思った
愚直にコードジェネレータや AOP のアプローチを適用しても良いがたぶん大変なことになるので自分たちのプロダクトにあった同じようなアプローチを選択できるのかがポイントかなと思った

例えばコードジェネレータは swagger を使ったり AOP のアプローチは DI (Dependency Injection) ならできそうだなーといった具合に具体的なアプローチを自身で見つけられるかが重要かなと感じた

プロトタイピングのコードは絶対に使い捨てでなければならないのか

個人的にはプロトタイピングで使った言語やフレームワークレベルでは流用して良いと思っている
データモデルや UI の部分も全く同じなのであれば使って良い気がする
むしろ使わないと二重化のルールに抵触しそうな気がする
もしかするとプロトタイピングに関しては二重化や直行性は無視して作れということなのかもしれない
だから使い捨てなのだと

そもそもプロトタイピング=コーディングすることだと思っているのが間違いなのだと思うが

道具の使い分け

IDE だけではなくてシェルも使うと便利だよという話
頭ごなしに IDE を否定しているわけではないが IDE だけだと不便なこともある
自分も Swift を書く場合は Xcode を必ず使っているがファイルを検索するときやリポジトリに push するときはターミナルアプリを使っている
また Ruby を書くときは emacs + tmux でターミナルウィンドウ内を行ったり来たりしてコーディング、ビルドを繰り返している
要するに達人なのであれば適材適所、状況にあった最適なツールを選択すべしということなんだと思う

ただ一つ腑に落ちなかったのはエディタの拡張性の話で確かにキーバインドや face などは拡張できたほうが操作性はあがるのだけれども、その拡張がされていないと操作できなくなるリスクが伴う
なのでできる限りデフォルトの設定に慣れておきどうしてもという部分だけを拡張するようにしたほうが個人的には良いと思う

本書が emacs 推しなのはよかった

テストに関して

本書内では具体的なテストの手法などについては書かれていない
代わりに「テストがしやすいコーディングの方法」や「バグとの向きたい方」などが書かれている

テストもバグ取りの一種だと自分は理解し結局の目的は「問題を修復すること」にある

個人的にテストに関しては DHH の「TDD is dead. Long live testing」の考えが好きでシステムテストに重点を置くようにしている (参考)
本書ではユニットテストについて具体的に触れているところはないが目的である「問題を修復すること」は同じだと思う

またテストのコストやテストにおける二重化や直行性についても特に触れられてはいなかった
テストケースやデータを自動生成しようという話はあった
個人的な意見だが TDD まで厳密にとは言わないがコーディングしたらそれと同時に最低限のテストを書いておいたほうが安定したコードになる気がする
本書内でもコーディングの終了=テストの終了という表現が使われていた

デメテルの法則

厳密に守ることができるのだろうか
またそれに気づく方法が経験しかなさそう
参考

すべてのコンテキストを網羅することはできるのか

本書内で「コンテキストの事故」というトピックで紹介されていた
「GUI ではなく CUI も想定しているか」「英語以外の言語に対応できているか」「ユニバーサルデザインに対応しているか」などが紹介されていた
おそらく洗い出したらきりがないとと思う
開発中のアプリケーションに対してすべてのコンテキストを洗い出して対応することはできるのだろうか
またそれらは本当にユーザが求めているのかの判断も難しい気がする

想定していないコンテキストがあるとそれが偶発的プログラミングの元になりバグを生み出す可能性になるのはわかるがすべてを網羅するのは難しいと感じた
またすべての内容を理解しながらコーディングを進めるのも必要ではあるが難しいケースもあるかなと感じた

リファクタリング、最適化

二重化/直行性やの結合度を最小化は当然としてアルゴリズムのオーダーの見直しやリソース/コストの見積もりと削減なども重要だなと感じた
プロファイリングなどを使ってコーディングの段階から意識したほうが良さそう

リファクタリングの前に必ずテストが用意されているという点も重要だと思う
意外とテストとリファクタリングを同時に行ってしまうケースはあると思う

リファクタリング時のミスをなくすという意味でやはり IDE は便利だと感じた

精神論

途中「本能に任せる」とか「経験から考える」「準備できるまで様子を見てみる」といったフレーズが出てくる
こういったのは経験からしか判断できないことが多いのでまずは考えないでもいいのかもしれない

別の箇所で「形式方法論」というツールなどを使ったアプローチを紹介している
デメリットもあるがそちらのほうがスタートは切りやすいと思う

チームの機能的分担

分析、設計、コーディング、テストという単位ではなくシステムの機能単位でコントロールするほうが良い
そのほうが全員がシステム全体を把握することができる
無理に機能単位でコントロール必要はないと思うがメンバー全員が分析、設計、コーディング、テストなどすべてを網羅的に把握しているほうが良いと思う

ビルフローなどの自動化についても触れられているが最近だとアプリケーション開発においてはデファクトで導入されているケースもあると思う (Github Actions や Circle CI など)

その他、あまりピンとこなかった話

  • ミニ言語
  • 見積もり
  • プレーンテキスト
  • 表明プログラミング
  • リソースの開放
  • ホワイトボードシステム (kvs 的なことだろうか、タプル空間)

最後に

本書を読んで自分なりに判断した「達人プログラマー」とは
幅広い知識と豊富な経験から算出される最適な答えと手法を導き出せる人 かなと思う

あと付録C のクイックリファレンスガイドがかなり役に立つので見返す時にオススメ