patorashのブログ

pre-commitは、その名の通り、commitする前にフックして処理を実行するライブラリ。処理を定義ファイルに書いておくことができるので、個別に.git/hooks/pre-commitファイルを修正しなくていいのが助かる…はずであった。

pre-commitを入れてみたが、前提がホストOSのRubyのため、まともに動かず。以下のQiitaの記事を見て、git config pre-commit.ruby "docker-compose run --rm web bundle exec ruby"と打って、pre-commitで呼ばれるコマンドを定義してみたものの、動かず。（もちろん、コンテナ名は適宜変えている）

qiita.com

以下のエラーが出た。

-e:1: syntax error, unexpected end-of-input

pre-commitのコードを見ると、コンテナのRubyを呼び出して-eオプションで、渡された文字列をコードとして実行しようとしているのだが、どうすれば上記のエラーが消せるのかがわからなかった…。まぁどちらにしても、pre-commitのコードを修正せざるを得なさそうなので、メンバー全員に適用させるには修正コストが高くなりそうであった。

そのため、一旦諦め、overcommitを試すことに。

overcommitを試す

overcommitもpre-commitと同じようなものだけれど、ホストOSにRubyが入っていることが前提となり、コンテナ側の呼び出しができない。多機能そうなのだけれど、こちらはすぐに気づいたので早々に諦めた。

pre-commitでなんとかするしかないのか…しかし、最近はコンテナに開発環境を入れて開発することが増えているんだから、なにか別の方法があるはずだろう…と思い、調べること数十分。遂に見つけたのがLefthookだった。

Lefthookを試す

https://github.com/evilmartians/lefthook#your-own-tasks

Lefthookは、gemではなく、Goで作られているgitのhookを纏めるツールである。lefthook.ymlに定義を書いておくと、それをgitのhookのタイミングで実行できる。

見つけた記事は、twitterでフォローしている、れいなさんのQiitaの記事。

qiita.com

読んですぐに、「これだ！」と思った。因みにtechrachoでも紹介されていた。

techracho.bpsinc.jp

インストール

Lefthookはシングルバイナリで提供されているので、インストールも簡単。Macならば、Homebrewで入れることもできる。

brew install lefthook

そして、プロジェクトのルートディレクトリで、以下を行うと、lefthook.ymlが出来上がる。

lefthook install

pre-commitの処理を定義する

定義の仕方は、lefthook.ymlを見れば大体わかる。しかし、Dockerコンテナでやるのは、れいなさんの記事を参考に、piped: trueを追加して、処理を順番に書いた。

pre-commit:
  piped: true
  commands:
    1_docker-compose:
      root: .
      run: docker-compose up -d rails
    2_exec_rubocop:
      glob: "*.{rb,rake}"
      exclude: "application.rb|routes.rb"
      run: docker-compose exec rails bundle exec rubocop -P {staged_files}

対象をstaged_filesとすることで、rubocopで検証するファイルを少なくして、実行時間を短くできた🚀。今までは自力でgit diffを駆使して差分ファイルを絞り込んだりしていたのに、この指定だけで済むのは素晴らしい🥳

定義を動作を検証する

定義をテストするには、実際に実行してみるのが一番。以下のコマンドを打つと、gitでcommitせずに試すことができる。

lefthook run pre-commit

問題ないことを確認！

Lefthookはタスクランナーでもある

一番驚いたのが、Lefthookはgitのhookに関係なく、タスクを定義できるのである。

上記のURLの箇所を参考に、rubocopのauto-correct（自動修正）のタスクを定義した。

fixer:
  commands:
    ruby-fixer:
      glob: "*.{rb,rake}"
      exclude: "application.rb|routes.rb"
      run: docker-compose exec rails bundle exec rubocop --force-exclusion --safe-auto-correct {staged_files}

今までは、細かいオプションを設定するのが面倒で以下のコマンドを打っていた。

docker-compose exec rails bundlle exec rubocop -a

しかしこれだと、対象ファイルが全部になるので、時間がかかる。あと単純にコマンドが長い。まぁpecoを使って履歴から呼び出していたのでさほど苦でもないんだけれど…。

だが、上記のタスクを定義したことで、これで済む。

lefthook run fixer

圧倒的に短い！そして、対象ファイルがstaged_filesなので、処理速度も速い！それに、今後Prettierでのフォーマットも入れていきたいと思っていたので、それの定義も追加すれば更に自動化できる。

他にも便利なタスクを定義していけそうなのは嬉しい。

まとめ

gitのフック系ツールはLefthookが一番使い勝手が良さそう。シングルバイナリでインストールも楽だし、設定もyaml形式で簡単。Dockerコンテナを指定して処理もできるので、開発環境をコンテナ化している場合はもちろん、そうでなくてもLefthookを使うのがいいと思う。

2021-10-20

開発チームのふりかえりをやった

日記

もう10日くらい前だが、弊チームの振り返りを行った。メンバーは私含めて3人で、1時間でKPTと開発チームのルールの見直しをした。

定例会で「ふりかえり」をしているのだが、開発としてのふりかえりではなく、製品に関わっている人のふりかえりなので、開発っぽいふりかえりをしたかった。因みに、そのふりかえりも、あまりビシッとした感じのネタは出てこない。時々出てくるけど。まぁそんなもんだろうか。

Keep

Keepは、

レビュー日を分ける
読書会
モブレビュー

で、これらはこのブログでも書いていたことだが、ちゃんとKeepしたい理由をフィードバックしてもらえたのでよかった。やってよかったー！って思える。作業日とレビュー日を分けたことで、レビューで辛くならないことだけではなく、「明日がレビュー日なので、それまでには仕上げたい！」というモチベーションに繋がったとのことだった。リズムも生まれたようで、これは副次的によかった面だった。

読書会は、もちろん勉強にもなるのだが、皆で同じ本を読んでいるので、共通言語ができるのが効いてくる。これはモブレビューのほうで詳しく説明する。あとは、プリンシプルオブプログラミングを読んだことで、どういうことに気をつければいいかが何となくわかるようになってきたので、コードの質がよくなったと思う。

モブレビューは、書いた人にPRのコードの説明をしてもらうので、意図がわかりやすいし、それならこうしたほうがいいよって言いやすい。ここで読書会の効果が効いてきて、Effective Rubyで書かれてたアレを適用したほうがいいとか、言いやすい。言う方も言いやすいけれど、言われたほうも「あー、確かにそうですね」と受け止めやすい。レビュー→修正→レビュー→修正→レビュー→修正…の地獄が起きにくい構造になるし、コミュニケーションコストが文字だけより断然早い（口頭で伝えた後に、コメントは残しています）。

Problem

問題は、あんまりそんな大きなものはなかったけれど、ちゃんと出してくれたのでよかった。心理的安全性が育っているかなと思える。

私が休みのときにスプリントプランニングしていいかわからない
夕会の時間が決まっていない

スプリントプランニングの件は、チケットはあって、優先度は決まっているのだが、なんらかの理由があって着手できないものがあるのだが、その判断が私になっているからだということだった。これを書いていて今、思い出した…😅。なぜ着手できないかを書いておくタスクを積んでおこう。とはいえ、取りかかれそうなやつからやってもらっていいですよって話はしておいた。

夕会は私のタイミングで適当にやっていたので、申し訳なかったなと思い、Teamsの会議で16:30に行うように設定しておいた。

Try

Tryはなんだったかな…。あまり思い出せない。ほとんどなかったような…。

定例会のふりかえりの項目をKPTをやめて意見の出やすいものにする

というのを、自分が上げたのは覚えている。以下のを参考に、定例会の議事録のフォーマットを変えてみた。

ihcomega.hatenadiary.com

一応、一回終わったのだが、まだあんまり慣れていないせいか、続けたいことやお礼したいことは出なかったけれど、聞いてほしいことに連絡事項がバババッと出ていて、それはよかったかなと思う。

開発チームのルールの見直し

書いてあることは至極真っ当なことなので、既存のものは変更なしでOKで、追加することにした。

他の人のために、Yard、JSDocを書きましょう
契約プログラミングを意識しましょう
コードのフォーマットはフォーマットルールに任せよう

YardやJSDocは、書いておいたほうが後で見返すときに助かるし、呼び出すときに引数の型がわかるので便利。やはり途中からプロジェクトに参加する人の理解の手助けになるので、やっていこうということにした。

契約プログラミングは、プリンシプルオブプログラミングに載っていたんだけれど、責任をメソッドの呼び出し側に持たせることができるので対応範囲が明確になるし、メソッド側で型のチェックを行わなくてもよくなるので、やっていこうということにした。

コードのフォーマットは、RubyはRubocopに任せているんだけれど、JavaScriptとCSSはまだ特にないので、ちゃんとPrettier等を導入していこうということにしたところ（まだやってない。チケットは登録した！）。

とまぁ、こんな感じで開発チームのルールをアップデートできたのは、モブレビューと読書会があってこそだなと思う💪。最近「みんなでアジャイル」を読んで、開発以外にもアジャイルを適用できるようにしていきたいと意識が高まっているので、頑張っていきたい。

2021-10-04

9月にやったこと

日記

もう10月に入ってしまったけれど、9月にやったことを書いとく。 8月にやったことは、これ。

さわって学ぶクラウドインフラ　docker基礎からのコンテナ構築

継続していること

プリンシプルオブプログラミング読書会（終わり）
Docker本読書会（開始）
モブレビュー
スプリントプランニング
レビューする曜日を決める等

引き続きやっているっちゃやっているのだが、ちょっと最近ダレてきている感じがする。俺だけがそう感じているのかどうか…。他のメンバーにも聞いていきたいところ。

プリンシプルオブプログラミングはとてもいい本だったとは思うが、時々読めない漢字が出てきて、この表現ここで必要？というところはあった。このエッセンスを開発チームのルールに組み込んでいきたいなぁと考えているので、開発チームの振り返りを行う際に提案してみようかと思う。例えば、契約プログラミングとか。責任の所在を決められるのがよい。

一応読み終えた後に、次はどの本にするか？という候補を出してもらう期間を設けたのだが、メンバーから特に上がってこなかったので、自分が読みたい本の候補をいくつか挙げていった。「次はなんか手を動かしたいですね」とパートナーさんが言っていたので、Dockerの本を挙げたのだが、それが実際に手を動かしながらDockerのことやk8sのことが学べそうだったので、その本に決定した。開発環境はdocker-composeを使っているのだが、雰囲気で使っているところがあるので、ちゃんと学びたかったのでヨシ。

作者:大澤文孝,浅居尚
日経BP

因みにこの本はKindle Unlimitedに入っていたら読めるので個人的にはお財布に優しい😊

今までのところでは、AWSにUbuntuでEC2インスタンスを立てて、そこでコマンドを打ちながらdocker imageをpullしたり、コンテナを作ったり、コンテナを動かしたり、コンテナの削除やイメージを削除したりなどを一通り行った。実はdocker-composeばっかり使っていて、あんまりdockerコマンドを打つことがないので、曖昧だったところが学べてよい。

会社が期首

9月は期首で目標設定とか新しいグループになったりとか、期首ならではの会議の多さとかであんまり仕事を進められた感じはしなかった。

雑談

Rubyのグループの雑談には顔を出すようにして、話を振ってみたりするのだが、俺の雑談力が低いのか、なかなか話を広げられない。まぁ技術的な雑談のときはいいんだけれど。このあたりの引き出しがもっと欲しい…。

年俸制になった

今期から私の階級は年俸制になった。突然の年俸制なので、何をどうしたら？という感じだったのだが、まぁそれは会社側もそうみたいだったので、まぁ大体これくらいの予定ですって感じだった。下がってはいないし、まぁまぁ上げてくれてたので、今期にガツンと結果を出して、来期にドヤれるように頑張ろう。

ソフトウェア・ファーストを社長に薦めた

ソフトウェア・ファースト、ずっと積読してあったのだけれど、ようやく読んだ。大概の日本企業にぶっ刺さる内容で、自分のキャリアとかも考えさせられた。今後のエンジニア採用とか組織運営とかをどうしていったらいいかのヒントが詰まっていて、めっちゃいい本なのだが、こんないい本を2年も放置していたのか俺は！？😓まぁその間にはリーダーシップの本とか読んだり、色々とやってましたが。でも、この本の内容は、もっと上の立場の人に読んでもらわないと組織的に変えるのは難しいよなぁと思ったので、弊社社長に読んでくださいってメールをしておいた。早速買ってくださったようなので、よかった。

ソフトウェア・ファースト

作者:及川卓也
日経BP

体系的に学ぶ安全なWebアプリケーションの作り方第2版［リフロー版］　脆弱性が生まれる原理と対策の実践

徳丸本読書会を始めた

「体系的に学ぶ安全なWebアプリケーションの作り方」の読書会を始めた。これは今期から「業務時間の一部を学習に充てていいですよ」という会社のルールができたのだけれど、それを使って開催している。エンジニアの技術力の底上げが至上命題になっているので、開発言語を超えた内容でできないものか？と考えた結果、これにした。というのも、こういう本は1人で読むことも、もちろんできるのだけれど、内容が内容なだけに、挫折しやすい…。なので、挫折しないために読書会にした感じです。

作者:徳丸浩
SBクリエイティブ

社内勉強会でHotwireを紹介した

今更感はあるけれど、でもまだあんまりHotwireを試していない人が多そうだったので、Hotwireを試した所感を社内勉強会で発表した。自分としては、Hotwireめっちゃいいやん！という気持ちなのだが、世間はフロントエンドとバックエンドを疎結合にしていく流れ…なのだろうか？小さなチームでそこそこのサイズのアプリケーションを作るのであれば、Rails + Hotwireでイケるやん！と思う。ネイティブアプリを作ったり、外部にAPIを公開したりするのであれば、APIを作っていくのもアリだが…。

まぁそれはアプリの適性次第である。

新型コロナウィルスのワクチン接種を終えた

8月末に1回目、9月末に2回目のワクチン接種を終えた。打ったのは、モデルナです。1回目は熱も出ずに、ただ腕が筋肉痛っぽい感じなだけでした。2回目の副反応はキツイと聞かされてたので、解熱剤を買ったりしていたのだけれど、思ったよりも熱は上がらず、38度丁度ぐらいでそこまでではなかったです。しかし、めちゃくちゃだるかった…。布団と背中が引っ付いたんじゃないか？というくらい、動きたくなかった。そして、眠い。結構な時間寝ました。12～48時間くらいで副反応が出たので、2日ほど休みました。

まぁ新しい期になってから、まだあまり動けてない…というか手を動かせてないのかな…。いや、でもマネジメント的なことは結構やっているし、教育的なこともやっている…。技術検証もしている。うーん、結構動いているけれど、動けていないように感じているだけなんだろうか？

2021-09-16

GraphQLでActiveRecord::RecordNotFoundをいい感じに処理する

GraphQL Ruby on Rails

GraphQLを使ってWebAPIの構築をやっているのですが、対象のデータが存在しない（ActiveRecord::RecordNotFound）場合にどうすればいいかがわからなかったので調べました。

結論

graphql-rubyのエラーハンドリングのところに書いてありました。

graphql-ruby.org

該当箇所を抜粋すると、こういうことです。rescue_fromを使って、ActiveRecord::RecordNotFoundの場合にはGraphQL::ExecutionErrorを発行すればOK。

class MySchema < GraphQL::Schema
  # ...

  rescue_from(ActiveRecord::RecordNotFound) do |_err, _obj, _args, _ctx, field|
    # Raise a graphql-friendly error with a custom message
    raise GraphQL::ExecutionError, "#{field.type.unwrap.graphql_name} not found"
  end
end

おーし、これでええかな😊と思っていたのですが、graphql-batchを使ってデータをロードしていたので、思ったように機能せず…😢

graphql-batchに対応する

graphql-batchはGraphQLでデータを取得する際にN+1問題が発生しないようにクエリを解析して、うまいことpreloadを呼んでくれるやつです。

スモール・リーダーシップチームを育てながらゴールに導く「協調型」リーダー

READMEを読んで、その通りにやっていくと、RecordLoaderを定義して、loadメソッドを呼ぶことになります。READMEからコピーしてくると、以下のような感じ。

field :product, Types::Product, null: true do
  argument :id, ID, required: true
end

def product(id:)
  RecordLoader.for(Product).load(id)
end

これだと、null: trueなので、nullを許可したくないので削除します。

field :product, Types::Product do
  argument :id, ID, required: true
end

def product(id:)
  RecordLoader.for(Product).load(id)
end

でもこの状態だと、loadはnilを返すので値がnullになってしまい、GraphQLが返すエラーメッセージがおかしなことに…😵

{
  "data": null,
  "errors": [
    {
      "message": "Cannot return null for non-nullable field Query.product"
    }
  ]
}

Not NullなフィールドなのにNull返すなよ！っていう実装側へのメッセージですね。クライアントは悪くない。

じゃあこれを直します！thenを使っていきます。これは、graphql-batchのREADMEに書いてあるような対応方法です。

field :product, Types::Product do
  argument :id, ID, required: true
end

def product(id:)
  RecordLoader.for(Product).load(id).then do |product|
    raise ActiveRecord::RecordNotFound if product.nil?

    product
  end
end

こうすると、GraphQLが返すエラーはこのようになります。GraphQLのクエリのこの辺りがおかしいよというメッセージ付きに。

{
  "data": null,
  "errors": [
    {
      "message": "Product not found",
      "locations": [
        {
          "line": 6,
          "column": 3
        }
      ],
      "path": [
        "product"
      ]
    }
  ]
}

やったぜ！👍👍👍

load!メソッドを定義する

しかし、これだとloadメソッドを呼ぶところ全てでnilチェックをしないといけなくなるので、面倒…。ということで、RecordLoaderにload!メソッドを定義しました。

class RecordLoader < GraphQL::Batch::Loader
  # ...

  def load!(key)
    load(key).then do |record|
      raise ActiveRecord::RecordNotFound if record.nil?

      record
    end
  end

  # ...
end

これを使うと、フィールドの定義が簡潔になります。loadに!を追加するだけですからね。

field :product, Types::Product do
  argument :id, ID, required: true
end

def product(id:)
  RecordLoader.for(Product).load!(id)
end

まとめ

GraphQLでレコードが見つからなかった場合にエラーメッセージを出すようにしました。

しかし、graphql-batchのサンプルコードのように、そもそもnullを許可したほうがいいのだろうか？と、ちょっとAPI設計的にどちらがよいのか疑問です🤔

もっと記事を読んだり本を読んだりしながら、ベストプラクティスを知りたいところ。いい情報があったらお願いします！

2021-09-06

Railsのモブバージョンアップ会を開いた

Ruby on Rails 日記

先週ですが、うちのプロダクトのRailsのバージョンを6.0系から6.1.4.1にアップグレードしました。その際に、1人でアップグレードを行うのではなく、チームメンバー3人全員でバージョンアップを行ったので、それについて書いておこうと思います。

なぜ全員でやったか？

Railsのバージョンアップをする機会って、実はなかなかありません。最後の1桁のバージョンアップは基本的にセキュリティ修正やバグ修正のため、ほぼ設定を修正することなく終わるアップデートです。

Rails 6.1はリリースされてから結構経っていますが、実は出た直後くらいに後輩くんにRailsのバージョンアップの経験をしてもらおうとタスクを振ってみたのですが、数日かかっても終わらなかったので、当時は「いくらなんでもこれだけ時間かけてRailsのバージョンアップが終わらんって…😯」と思っていました。しかし、スモールリーダーシップを読んでから、「やっぱこういうところから一緒にやっていくところが大事やな」と考えを改めて、モブバージョンアップ会をやろうとずっと考えていました（だいぶ後回しにしてしまったけど）。

私はRails3の頃からずっとバージョンアップをやってきているので、大体手順は分かっています。一般的なRailsのバージョンアップで気を付ける点と、うちのプロダクト独自のハマりポイントに気が付くので、そういう地雷に対する鼻を利かせながら教えることができます。これもまた、情報格差を減らせるタイミングです。

因みにあと1人は協力会社のパートナーさんですが、パートナーさんも一緒にやったのは、バージョンアップの経験をしておく人数は多いに越したことはないと思ったからです。

進め方

画面共有はTeamsで、コード共有はJetBrainsのRubyMineを使っているので、CodeWithMeを使いました。修正してCIを流してエラーメッセージを確認して、何が原因かを話し合いながら、調べた結果を共有しながら進めました。

実際にハマったところ

うちの製品はPostGISを使っているので、Rails 6.1にしたタイミングでactiverecord-postgis-adapterのバージョンアップも必要になりました。また、RGeoの初期設定でsridの設定が必要になったみたいだったので、それの修正を行いました。

みんな位置情報は使っているということは知っているんだけれど、PostGIS用のgemにまではなかなか思いつかなかったようだったので、「多分これだと思うよ」って伝えて、実際にREADMEを読んでみようと言って該当箇所を見つけ、コードをみんなで修正してテストを流してローカルで通ることを確認後、再push。無事にCIも通って、1日以内にマージすることができました🎉

良かった点

言わずもがな、知見の共有ができたことです。スモールリーダーシップに書いてあったけれど、「1人でやらない。複数人でやる。」というのは、情報格差があるときにはすごく大事だと思います。PostGIS系でハマることは多々あるので、次回は似たようなエラーメッセージが出たら直ぐに「あー、RGeoやな」と思ってくれることでしょう。また、通常のRailsバージョンアップの手順についても話すことができました。これで、次回からは自信を持ってやってもらえるはず💪

ということで、モブバージョンアップ、お薦めです。あと、スモールリーダーシップもお薦めです。

作者:和智右桂
翔泳社

2021-09-06

スマホ用ゲームコントローラーGameSir X2 Type-Cを買ったのでレビューする

もう1か月前近くになりますが、スマホでゲームできるようにしたいなぁと思っていたので、スマホ用ゲームコントローラーを買いました！

my new gear pic.twitter.com/0l51Llvyqv
— パトラッシュ@エキスパート職 (@patorash) 2021年8月12日

最初はボーナスも出たことだし、Nintendo Switch Liteでも買おうかなぁと考えていたのですが、あんまりゲーマーでもないし、そこそこ高額な買い物になるのにやらなさそう、というかできないので（子供達がいると難しい…😅）、投資費用が7千円程度と少なくて済むスマホ用のコントローラーを買って、スマホ用にリメイクされたゲーム群をボチボチやってみようかなぁ～という感じです。（Switchは実はあるけれど、子供がよく使っている）

なお、今日ようやくスマホ版のクロノトリガーの1回目をクリアしました😀中学生か高校生の頃にやっていたはずなのに、ほとんど覚えていなかったです。まぁ友達から借りてやっていたので、クリアすることを目的にしていたのかもしれない…。今思うと…。

プレイしたことのないドラクエや、久々にやりたかったFFタクティクスとかも買ってあるので、やるのが楽しみ。

それはそうと、ちょっとしたレビューくらいしておこうかなと思った次第です。

外見

これが付属のケースです。すごくしっかりしていて、衝撃に強そうです。

f:id:patorash:20210906010249j:plain

これがGameSir X2 Type-Cの本体。USB接続なので、遅延が少ないとのこと。（まぁ遅延を気にするようなゲームはしなさそうだが…）

f:id:patorash:20210906010422j:plain

これが、スマホを装着したところ。スマホカバーを付けていても、問題なく装着できました。

f:id:patorash:20210906010617j:plain

動作環境

次に、動作環境ですが、以下の通り。

スマホ：Galaxy A30（メモリ4GB）
コントローラー： GameSir X2 Type-C
アプリ： GameSir
ファームウェア： 1.18-1.3
Key layout Settings： Xbox layout

スマホはサムスンの廉価モデルのGalaxy A30です。2019年8月（2年前）に買ったっていう記事を書いてます。もう2年経ったのか…。

GameSir X2 モバイルコントローラー Androidスマホゲームパッドクラウドゲームコントローラー xCloud/Stadia/Vortex に対応

アプリ「GameSir」は、コントローラーの設定とかをするために必要です。Google Playからダウンロードじゃなくて、QRコードからダウンロードしたような…記憶…。ファームウェアは、スマホとコントローラーをつないだ状態で、アップデートができます。これをしないとKey layout SettingsのXbox layoutが出てきませんでした。

f:id:patorash:20210906011633j:plain

ちなみにKey layout SettingsをXbox Layoutにしないと、慣れてるボタンレイアウト設定になりません。

物理ボタン	Aボタン	Bボタン
Swtch layout	キャンセル	決定
Xbox layout	決定	キャンセル

f:id:patorash:20210906011659j:plain

この設定にする前にクロノトリガーをやろうとしたときは激しく後悔して、ボタン配置を変える方法を調べようとしたのですが、その前にファームウェアを更新したらKey layout Settingsが出てきて事なきを得た、という感じでした。神アップデート！

1ヶ月くらい使った感想

まだクロノトリガーしかしてないけれど、当然遅延はありませんし、スマホの画面に出てくるコントローラーに比べると操作性は当然ながら格段にいいし、本当に文句なしです！👍👍👍 因みにコントローラーのほうにUSB-Cの挿し口があるので、充電しながらプレイできますから、電源の問題もありません。

それにしても、持った感じはまさにNintendo Switch。ゲームしているところを次男に見られたら、Switch買ってきたと勘違いされたくらい…😅

次男氏が「お父さんがSwitch買ってきたよー！」って妻に言ってるけど、違うんや…。 https://t.co/wTKUDWenpk
— パトラッシュ@エキスパート職 (@patorash) 2021年8月12日

2年前の廉価モデルのメモリ4GBのスマホで問題なく操作できるので（もちろんゲームに因るとは思うけど）、もっとスペック高いスマホなら余裕でしょう。

とりあえずGalaxy A30を使っている人でこれが気になっている人には、全く問題ない、と言えるかと思います。

GameSir

2021-09-02

8月にやったこと

日記

9月になったので、8月にやったことを書いておく。7月のやつはこれ。

継続して取り組んでいることは、以下の通り。

プリンシプルオブプログラミング読書会
モブレビュー
スプリントプランニング
レビューする曜日を決める等

8月は祝日の移動や夏季休暇の取得などで、変則的になったりもしたけれど、まぁなんとか継続中。

やったことでいえば、社内ISUCONを行った。ようやくできたのでよかった。あとは久々にリファクタリングデーを開催した。長いこと放置していた、rubocop_todo.ymlにメス入れようぜーって話していたのだった。

プリンシプルオブプログラミング読書会

プリンシプルオブプログラミング読書会は、もうちょっとで終わりそう。残りは最後の7章になったので。 UNIX哲学を伝える章があったので、「UNIXという考え方」の話を交えながら、色々と話をした。前に書いたのがこれ。

あとは最近読んだ章でいえば、契約プログラミングの考え方とか、防御的プログラミングの考え方の話があって、この辺りについての考えが自分自身でも曖昧だったので、はっきりとしたルールを作っていくべきだなと思うようになった。これは開発チームのルールに追加するべきかなと思った。そうすれば、レビューでブレないと思う。

社内ISUCON

Rails ISUCONと称して、社内ISUCONを開催した。まぁその話は既に記事にしているので、過去記事を貼っておく。

ありがたいことに、公開2週間くらい経過してからブクマが急に伸びて、はてブのホットエントリー入りしていた。丁度、isucandarの記事を書いた後だったのだが、 id:Soudai がTwitterで言及してくれてから突如伸びたので、インフルエンサーの力はすごい👏👏👏

isucandarの記事はこっち。

リファクタリングデーを開催

数か月ぶりに開催した。rubocop_todo.ymlに手を入れた。とりあえず上から見ていくかーって話をして、Layoutに関するやつは終わった。進め方は、正直やった後の感想としてはあんまりよくなかったけれど、一応書くと、以下のようにした。

ルール毎にRedMineのチケットを作成する
Auto Correct（自動修正のこと）できるルールは bundle exec rubocop -a --only [ルール] で1つずつ直す（これが微妙だった…）
Auto Correctできないルールは手動で直す
PRを作成する
モブレビューして問題なければマージする

なにがよくなかったかを書いていく。

rubocopのLayoutルールを1つずつ直すのは何がよくないか？

まず、Layoutルールは定義は1つずつ独立しているものの、他のルールと密接に関係しているため、onlyで1つ直しても、後でonly外して実行すると他のルールに引っかかってしまう。また、PRを作成してマージしていて気付いたというか最初から気付けよっていう話なのだけれど、1つのルールを直したPRを取り込んだ後だと、必ずコンフリクトが発生して、素直に他の修正PRがマージできなくなってしまった😔

よくよく調べたら、rubocopにはLayoutルールに関するものだけを自動修正するための --fix-layout というオプションがあった。なので、最初にLayoutのルールを全部決めて、以下のコマンドを流すのをお薦めしたい。

bundle exec rubocop --fix-layout

最終的には、これに気付いたのでLayoutのルールに関するPRは全てクローズして、上記のコマンドで一括修正したものをPRし直して事なきを得た。

リリース前検証はやっぱり大事

リリーススプリントで、プロダクトのリリース前検証を後輩氏にしてもらっているのだが、そこでElasticsearchに繋がらなくて落ちるエラーが起きた。その件は記事にしてある。

テストも通っているし、ローカルでも発生しないけれど、本番環境相当の場合のみ起きる不具合…。やはりあり得るので、リリース前検証は大事…。

それにしても後輩氏に検証してもらえるようになったので、その点は楽になったのだが、あくまで仕事が自分から後輩氏に移動しただけなので、もうちょいなんかできないか考えたいところ。

会社が期末・期首

30期が終わって、もう9月なので31期がスタートした。

30期は、テーマとしては「教育」にしていたので、色々できたんじゃないかと思う。

スクラム
ペアプロ・モブプロ
モブ設計
リファクタリングデー
読書会
社内ISUCON

丁度1年前くらいにスクラムやろうとしている記事書いていた。