【フィヨルドブートキャンプ】チーム開発のgood first issueでモブプロをした話

この記事は フィヨルドブートキャンプ Part 1 Advent Calendar 2024 の1日目の記事です。
フィヨルドブートキャンプのアドベントカレンダー2024は、Part1とPart2があります。

🔖 目次

👨🏻 自己紹介

@sugiwe (すぎえ)と申します。
デザイナーという肩書きでロゴデザインやウェブ制作、その他様々なデザイン業務を行なっています。
2021年10月よりプログラミングスクールの フィヨルドブートキャンプ (以下、FBCと呼称)に入り、仕事をしながらプログラミング学習を進めています。

bootcamp.fjord.jp

先日、ようやくチーム開発というプラクティスに到達しました!
この記事では、チーム開発のgood first issueをモブプロで行ったことについて紹介いたします。

✏️ 用語解説

まずざっくりと用語解説をします。
記事全体がちょい長いので、ここはご存知の方は読み飛ばしていただいて構いません💨

チーム開発とは(クリックで開閉)

📝 チーム開発とは

チーム開発とは、FBCの終盤で取り組むプラクティス(課題)の1つです。FBC受講生が学習のために普段使っているEラーニング用Webアプリケーションの開発に参加し、自分たちが使っているアプリを自分たちで開発していくという、とてもエキサイティングなプラクティスです。
担当するissueごとにポイントが割り振られており、合計20ptのissueをcloseさせたらプラクティス完了となります。

github.com

good first issueとは(クリックで開閉)

📝 good first issueとは

good first issueとは、その名の通り初めて行うのに適したissueです。
(元々GitHubがissueに付与するためにあらかじめ用意してあるラベルの1つだったようで、FBCにおいてはまずチーム開発の流れに慣れるために、修正内容自体はごく簡単な文字修正やリンク追加などのissueに割り振られているようです)

good first issue: 初回のコントリビューターに適した Issue を示します
デフォルトラベルについて

モブプロとは(クリックで開閉)

📝 モブプロとは

モブプロとはモブプログラミングの略です。

モブプログラミング 【mob programming】
プログラミングをグループの共同作業として行う手法の一つで、3人以上のチームが同じコード編集画面を見ながら作業を進める。一人がコードをタイプする「ドライバー」、残りのメンバーがドライバーへ記述内容を指示する「ナビゲーター」となる。
モブプログラミング(モビング)とは - IT用語辞典 e-Words

<モブプロについての補足>
定義上のモブプロでは「ドライバー」は他メンバーからの指示に従ってコードをタイピングしていきますが、今回はこの定義に沿っていません。
good first issueに取り組むにあたって、僕がissueの内容を読み上げたりどこのコードをどういじるのかを声に出して作業しているところを他の人に見ていただき、何か困ったことがあったらアドバイスをしてもらったり、そうじゃなくても見ている人が何か気づいたことや気になることがあればドンドン声をかけていただく、という形式のものでした。
(なので厳密には「モブプロ」ではないのですが、FBC内ではこのスタイルのことも「モブプロ」と呼んでいる気がします。他のちょうどいい言葉があるといいのになぁ)

🧑🏻‍💻 なぜモブプロでやったのか?

FBCのgood first issueを進めるにあたって、「Good First Issue 攻略」というFBC生向けのドキュメントがあります。
ものすごく丁寧な説明が掲載されたドキュメントで、基本的にはこのドキュメントに沿って進めればgood first issueは問題なくクリアできるのではと思います。

ではなぜわざわざモブプロでやったのかというと、理由は大きく2つあります。

  1. 先輩受講生がやっていて楽しそうだったから
  2. モブプロ・ペアプロの開催が増えてほしいから

1. 先輩受講生がやっていて楽しそうだったから

1つ目の理由はシンプルで、先輩がやっていてなんか楽しそうだったから、ということに尽きます。

上述の「Good First Issue 攻略」というドキュメント内に、先輩受講生がgood first issueでモブプロを呼びかけているDiscord画面のスクリーンショットがありました。これを見てシンプルに「good first issueでモブプロやるの面白そうだな、自分もやってみたいな」と思ったのがモブプロ開催をしたキッカケです。

(「Good First Issue 攻略」内にもチーム開発に参加し、はじめて Issue に着手する際はペアプロ・モブプロを開催するのがおすすめです。サポートしてもらいましょう。と記載されています)

先輩受講生がモブプロ開催を呼びかけているところ

2. モブプロ・ペアプロの開催が増えてほしいから

実は、僕はこれまでも以下のシーンでモブプロやペアプロ等を経験したことがありました。

  • ラクティスで詰まってしまいメンターさんに依頼してペアプロを実施した
  • 勝手にモブプロ」というFBC内のイベントでみんなでワイワイとモブプロした
  • (これはモブプロではないですが)各種輪読会で不定期にドライバーを担当する

メンターさんや受講生の皆さんが温かく見守ってくれるというのが非常に大きいですが、こういった経験から「モブプロは見るのもやるのもめっちゃ役に立つし、なんといっても楽しい!」という印象を持っていました。

また、もっとFBC内でモブプロが開催されて欲しいという想いもあったので、それならまず自分でやってみようということで開催することにしました。

もっとモブプロ開催が増えていくといいなと思っています😄

👣 モブプロ開催までの流れ

モブプロ開催は非常に簡単です。

  1. 日時を決める
  2. 告知する
  3. 開催する

これだけです。

ただ、ビビリの僕は、実は「呼びかけてもボッチだったらどうしよう…」という恐怖心を持っていました😂
それもあって、告知をする前に自分の日報で参加してくれる人がいることを確認した上で開催告知をした、という流れでした。

日報内で参加してくれるとコメントをいただきました。圧倒的感謝…!

めでたくボッチにならないことが確定したので、FBC用のDiscord内で開催告知をしました。

Discord内でモブプロ開催を告知するsugiweの投稿
Discord内での告知。スタンプでの反応が嬉しかったです!

※1回やってみて思うのは、参加者が少なくてもボッチだとしても失うものは何も無いので、今後もっと気軽に開催したいなーとも思っています。(むしろボッチ開催の実績を解除したい)

😸 モブプロをやった感想

普段参加している輪読会後の時間に開催だったということもあり、輪読会に参加しているメンバーの皆がモブプロにも参加してくださいました!
Discord内の輪読会用ボイスチャンネルからモブプロ用チャンネルに一斉に移ってきてくれて、めちゃくちゃ嬉しかったです✨

実はモブプロをするにあたって、「モタついてしまったらどうしよう…」という不安があり、事前にコードの準備まではしていないですがざっくりどんなふうに進めれば良いかをイメトレして臨んでいました。

ちなみにその時のPRは以下です。

github.com

蛇足ですが僕はポッドキャストが大好きなので、ポッドキャストのリンクを追加するというissueを担当させてもらえたのも何気に嬉しかったです😄

🏋️ モブプロ開催で得られたこと

イメトレの甲斐もあり、作業自体はかなりスムーズに進めることができました。

「じゃあモブプロじゃなくても良かったんじゃないのか?」と思われたかもしれませんが、そんなことは無かったです。モブプロに参加してくださった方に、ドキュメントには載っていない色々なアドバイスをもらうこともできました。

  • issueやその他GitHub上で質問するときは、必ずメンションをつけるようにする(使い分けた方がいいかなと思ったりもしましたが、変に遠慮しても気づいてもらえないので遠慮は不要)
  • good first issueはテストが無くても問題ないことが多いけど、基本的には何か修正をしたらテストを追加すべき
  • 複数のissueを同時に進めてデモを行う際、手元でブランチをその都度切り替えると大変なので、複数のブランチをまとめたデモ用ブランチをローカルに作っておくと便利
  • レビューを担当した際、最終的にOKのタイミングでApproveを押さないといけない。(コメントで「OKです」とするだけではApproveしたことににならないので注意)

これらは、チーム開発を進めるにあたって必須とも言えることばかりですが、モブプロをしていなければ知るのが遅くなってしまったのは間違いないので、モブプロ実施によって初めのタイミングでキャッチアップできて本当によかったです。

モブプロ・ペアプロのメリットとして「改めて共有するまでもないコツなどをシェアできる」ということは一般的にもよく挙げられますが、今回このメリットを強く実感しました。

あとはなんといっても、モブプロ自体が楽しいです。PRを出した瞬間にDiscordの拍手機能で祝ってもらえて嬉しかったです😄✨

モブプロやペアプロ、自分ももっとやりたいし、FBC全体でもっと沢山開催されるといいなと思いました。

🔥 終わりに

20ptのissueをcloseさせたら完了となるチーム開発ですが、現状で僕が割り振られているのは9pt分です。まだ半分の手前といったところなのでこれから困難が待ち受けているような気がしますが、今のところは難しさを感じながらも楽しく取り組めています。

FBCで学習をしていくにあたっての最近の自分のテーマは「できることを楽しむ」です。 (そのテーマで1ヶ月ほど前にLT発表もしました!)

speakerdeck.com

引き続き、「楽しむ」を大切にしてFBCでの学習を続けていきたいと思います。

🚀 余談の裏目

最後に余談となりますが、僕はチーム開発で「出来るだけ自分で立てたissueを担当する」という裏目標を掲げています。

(※チーム開発ではメンターさんからissueを割り振ってもらい取り組んでいきますが、issueは誰でも自由に立てることができます)

自分が立てたissueを担当するというのはメリット・デメリット両面あると思いますが、個人的には大きなやりがいを感じています。(毎日自分が使っているアプリで自分が欲しいと思った機能を自分で実装できるなんてサイコーだと思いませんか?)これについてはチーム開発のプラクティスが全て終わってから改めて別記事で書きたいと思っています🚀

📅 明日のアドカレ

ここまで読んでくださりありがとうございました!

明日のフィヨルドブートキャンプのアドベントカレンダー2024は、以下の予定です!

  • Part 1: chihaso さん
  • Part 2: okuramasafumi さん

フィヨルドブートキャンプのアドベントカレンダー2024は始まったばかりです、この後も素敵な記事がたくさんアップされて来ますのでお楽しみに✨

📣 終わりの終わりに宣伝

今回のアドベントカレンダーとは別で、ふと思い立って1人アドベントカレンダーを立ち上げました。宣伝も兼ねつつ、挫折しないよう自分にプレッシャーをかけるためにここでお知らせいたします🚀

内容は「AtCoder過去問(主にA問題)をRubyで1日1問解く」です。さらに、解いてる様子を画面録画しており、その動画をYouTubeに配信したページを毎日掲載していきます。

これは1人でやってるのでモブプロではないのですが、ブツブツ言いながらAtCoderを解く様子を動画で眺めるのはモブプロへの参加者を疑似体験しているとも言える気がするので、もし良かったらたまに覗いていただけると嬉しいです。

adventar.org

お試しの11/30分と初回の12/1分はすでにアップ済みです。(途中、おそらくブラウザの問題でテスト結果が出ず若干グダっております、省エネのため極力編集に手間をかけずやっているのでご容赦ください😂)

www.youtube.com

ブログをWordPressからはてなブログに引っ越した

タイトルの通り、WordPressで構築していたブログをはてなブログに全部移してみた。

友人知人がはてなブログを書いている関係ではてなスターをよく使っているけど、僕のはてなアカウントがはてなスター用みたいになってるので、せっかくならブログもはてなに移してはてなの世界に浸かってみようという気持ちから。

WordPressからエクスポートしてはてなブログにインポート。思ったより簡単にできて驚いた。

古いブログの方はどうすればいいんだっけ、ちょくちょくアクセスもあったり過去記事のURLはSNSなどに残っていたりもするので、すぐ消すのも忍びない。Canonical設定みたいなやつでSEO的に新しいドメイン(=このはてなブログ)にSEOパワーを移せる的な話があったような気がする、全てうろ覚え😂

ドメインの失効が60日後らしく、1年延長するかどうか、悩む…。

あと広告が思ったより目立つので広告を消したい。はてなProか…。

そもそも、毎日の日記は Cosense に書いてるので、はてなブログに何を書くのかというのもまだちゃんと考えていない。 プログラミング関連のまとまった文章などについてはこちらに書いていくのがいいかな〜

【Ruby基礎】AtCoder Beginner Contest 083 A - Libra

■はじめに

Rubyの基礎的な問題をたくさん解くことで基本的な考え方やメソッドの使い方を定着させたい。 基本的にはAtCoderというプログラミングコンテスト競技プログラミング)の過去問を使う。(AtCoderは難易度が分かれており、難易度の低いA問題かB問題を解いていく)

■問題

●出典

AtCoder Beginner Contest 083のA問題 https://atcoder.jp/contests/abc083/tasks/abc083_a

●問題文

上皿天秤は、左の皿に乗っているおもりの重さの合計を L とし、右の皿に乗っているおもりの重さの合計を R としたとき、 L > R なら左に傾き、L = R なら釣り合い、L < R なら右に傾きます。

高橋君は、上皿天秤の左の皿に重さ A のおもりと重さ B のおもりを、右の皿に重さ C のおもりと重さ D のおもりを置きました。

上皿天秤が左に傾くなら Left を、釣り合うなら Balanced を、右に傾くなら Right を出力してください。

●制約

  • 1≤A,B,C,D≤10
  • 入力はすべて整数である

●入力

入力は以下の形式で標準入力から与えられる。

A B C D

●出力

上皿天秤が左に傾くなら Left を、釣り合うなら Balanced を、右に傾くなら Right を出力せよ。

■回答

●愚直に書く

直感的に宇宙船演算子が使えないかなと思ったけど、まずは愚直に書いていく。

a, b, c, d = gets.split.map(&:to_i)
ab = a + b
cd = c + d

if ab > cd
  puts "Left"
elsif ab == cd
  puts "Balanced"
else
  puts "Right"
end

通った!

●メソッド化して書く

メソッドを作る練習のために、あえてそういう書き方をするコーナー。

今日はスキップ。

リファクタリング/別アプローチ

宇宙船演算子、調べてやってみた。

a, b, c, d = gets.split.map(&:to_i)
answer = ["Balanced", "Left", "Right"]
puts answer[a + b <=> c + d]

通った!うれしい〜!!

●他の方の回答例

上位の方々も、変数に入れないとか色々コードを短くする技は使っているけど宇宙船演算子を使っていた。

●出てきたメソッド等

公式リファレンスを見る訓練。

■振り返りなど

宇宙船演算子を使えて嬉しかった。 直感的に思いつけたのと、実際使うにあたって一回配列に入れてそのインデックスを取るという流れも調べずに思いつけて良かった。

【Ruby基礎】AtCoder Beginner Contest 082 A - Round Up the Mean

■はじめに

Rubyの基礎的な問題をたくさん解くことで基本的な考え方やメソッドの使い方を定着させたい。 基本的にはAtCoderというプログラミングコンテスト競技プログラミング)の過去問を使う。(AtCoderは難易度が分かれており、難易度の低いA問題かB問題を解いていく)

■問題

●出典

AtCoder Beginner Contest 082のA問題 https://atcoder.jp/contests/abc082/tasks/abc082_a

●問題文

2 つの正整数 a, b が与えられます。 a, b の平均値を x とします。 x の小数点以下を切り上げて得られる整数を出力してください。

●制約

  • a, b は整数である。
  • 1≤a,b≤100

●入力

入力は以下の形式で標準入力から与えられる。

a b

●出力

x の小数点以下を切り上げて得られる整数を出力せよ。

■回答

●愚直に書く

切り上げってのが厄介。 余りを切り上げるメソッドとかあるのかな、それを調べる前にまずは愚直に「aとbを足して奇数だったら1足して、それから2で割る」で答えは出そう。

a, b = gets.split.map(&:to_i)
sum = a + b
puts sum % 2 == 1 ? (sum + 1) / 2 : sum / 2

通った!

●メソッド化して書く

メソッドを作る練習のために、あえてそういう書き方をする。

メインメソッド、計算するメソッド、標準入力を取得するメソッドの3つを作成。

def main
  a, b = read_nums
  puts get_average(a, b)
end

def get_average(a, b)
  sum = a + b
  sum % 2 == 1 ? (sum + 1) / 2 : sum / 2
end

def read_nums
  gets.split.map(&:to_i)
end

main

通った!

リファクタリング/別アプローチ

そもそも余りを切り上げるようなメソッドがあれば一発なので調べる。

ceilメソッドが浮動小数点数を切り上げるらしい、ふむ。 そうすると標準入力で取得した整数を一旦浮動小数に変換してからceilして、最後にまた整数に戻すってこと?それはそれで冗長な気もする…。 あ、違う、ceilすれば浮動小数点数を切り上げた形の整数にしてくれるんだ。

a, b = gets.split.map(&:to_i)
sum = a + b

puts (sum.to_f / 2).ceil

通った!

●他の方の回答例

a, b = gets.split.map(&:to_i)
puts (a+b+1)/2

あ、そうか。。。。整数の割り算は小数点切り捨てられるから、「奇数なら1足して」見たいな場合分けは不要で、単純にsumに1を足して2で割れば求める結果になるじゃん…。ショック!

●出てきたメソッド等

公式リファレンスを見る訓練。

自身と等しいかより大きな整数のうち最小のものを返します。

この日本語がむずくて5分くらい考えてた汗。 1.2の場合、これ自身が少数だから「自身と等しい整数」はなくて、より大きな整数の最小のものってのが2、すなわち繰り上げてるってことね。

■振り返りなど

回り道していてショックだったけど、まぁceilとかを調べられたのでOK。

【Ruby基礎】AtCoder Beginner Contest 081 A - Placing Marbles

■はじめに

Rubyの基礎的な問題をたくさん解くことで基本的な考え方やメソッドの使い方を定着させたい。 基本的にはAtCoderというプログラミングコンテスト競技プログラミング)の過去問を使う。(AtCoderは難易度が分かれており、難易度の低いA問題かB問題を解いていく)

■問題

●出典

AtCoder Beginner Contest 081のA問題 https://atcoder.jp/contests/abc081/tasks/abc081_a

●問題文

すぬけ君は 1,2,3 の番号がついた 3 つのマスからなるマス目を持っています。 各マスには 01 が書かれており、マス i には si が書かれています。

すぬけ君は 1 が書かれたマスにビー玉を置きます。 ビー玉が置かれるマスがいくつあるか求めてください。

●制約

  • s1,s2,s31 あるいは 0

●入力

入力は以下の形式で標準入力から与えられる。

s1s2s3

●出力

答えを出力せよ。

■回答

●愚直に書く

つまり1がいくつあるかってことだよね?

標準入力の取り方など色々忘れてるな、、、

文字列として取得してcharsメソッドで配列に分解して、それを数字にして足し込めば答えは出そう。

a = gets.chomp.chars
puts a[0].to_i + a[1].to_i + a[2].to_i

通った! しかしこれはあまりに愚直すぎるな、、、

少し調べた。 digitsメソッドで数字を位ごとに分割した配列にできて、それをsumすれば良さそう。

a = gets.to_i.digits.sum
puts a

通った!上のよりはスマートになった、かな?

●メソッド化して書く

メソッドを作る練習のために、あえてそういう書き方をする。 久しぶりなのでやっておくか…!

メインメソッド、計算するメソッド、標準入力を取得するメソッドの3つを作成。

def main
  a = read_num
  puts calculate(a)
end

def calculate(a)
   a.digits.sum
end

def read_num
  gets.to_i
end

main

通った! いつも処理用のメソッドの命名にちょっと悩むな…。

リファクタリング/別アプローチ

上の愚直に書くところで別アプローチを1つ書いていたのでここではスキップ

●他の方の回答例

p gets.sum-154

何これ😂 どうやら文字列をsumしており、unicodeとかそういうのの数値を利用しているのかな…?

p gets.count('1')

あーこれドンピシャのやつじゃないか、文字列の中から任意の文字が何回使われているかを探すメソッド。 これは思いつけるはずなので、思いつきたかった。

●出てきたメソッド等

公式リファレンスを見る訓練。

■振り返りなど

久しぶりで何もかも忘れていたので、引き続きリハビリしていく。 ちょっとしたメソッドなどもまた色々調べて使って思い出していきたい。

2023年の振り返り

恒例の、年末の雑な振り返り。

法人化して4年が経った

  • 会社が存続できていることは感謝しかない🙏

仕事について

  • 今年もメインとしてはウェブサイトの制作・更新など。今年も色々とやったなぁ。楽しかった。
  • Podcast制作支援などをしているPitPaさんのロゴリニューアルをさせてもらえて、とっても嬉しかった。
  • Kaigi on Rails 2023のお仕事ができて楽しかった。


  • タイポグラフィ年鑑は今年も出してたんだけどダメだった。うーん行けると思ったんだけどな、悔しい。継続してやっていく。
  • 下に書くけど、来年はフィヨルドブートキャンプが佳境になると思われる(そうしたい)ので、それ自体が忙しくなりそうなことに加えて、「その後どうしていくか」というのを少しずつ定めていきたい。

フィヨルドブートキャンプ(FBC

  • 2021年秋から入会したプログラミングスクール、フィヨルドブートキャンプ
  • 今年も頑張った。でも思うように進まない時期もあった。ざっくり計算すると今年も450時間くらいやったかな?
  • 昨年末、2023年に卒業したいとか書いてたけど、とてもじゃないが無理だった😂
  • 来年いっぱいで卒業というのが現実的かつ必達としたいところ。できればもうちょっと早くにしたいが…。
  • 輪読会に参加するようになって、仲間が増えた気がする。
  • オフラインイベントにも参加したし登壇もした。


記録と発信

  • scrapboxでの日記をずっと継続して書いている
    • https://scrapbox.io/sugie/
    • junebokuさんがやっている Nikki Hub というプロジェクト?にも参加して、8〜9割くらいの日は登録したかな?junebokuさんやtaizoooさんなど他の方の日記もかなり読んでて、面白かった
  • しずかなインターネットを始めた
    • https://sizu.me/sugie
    • 上述のscrapboxが俺のしずかなインターネットだけど、こっちも好き。猫と料理のことを投稿している
  • Podcastを始めた

生活

  • 早朝生活は継続。
    • そろそろ娘の寝る時間も遅くなってくるし、再来年の4月から娘が自分の部屋を持つという話になっている。そうなるとこれまでの早寝が継続できるか微妙になってくる可能性がある
  • ちょこざっぷを始めたけど、お金の都合もあり秋にやめてしまった。
  • 今も朝にウォーキングをしているが、体を動かすのがほぼそれだけなので、もう少し運動しないといけないなと思っている。
  • 上でも書いたけど、scrapbox日記を1年以上継続できて大変嬉しい。日付タグをつけることで1年前の同日の日記リンクが表示されるので、1年前の日記に毎日邂逅できているのが楽しい。
  • 今年は週末に料理をすることが増えた。もっとレポートリーを増やしたいし、今はレシピを見て必要なものを揃えて作る、という幹事なので、もう少し冷蔵庫の中を見て「これとこれがあるからこれ作るかー」みたいなことをできるようになりたい。

総括と2024年

  • 2023年も、家族・仕事・プログラミング学習と充実してあっという間の1年だった。
    • 去年とほとんど同じこと書いてるな、、、
  • 今年は本厄だったけど、無事過ごすことができた。ありがたい。
  • 2024年のお仕事について。来年はまだ過渡期というか、これまでの流れのお仕事はしっかりやりながら、2025年に新しい芽が出るような動きを2024年は始めていきたい。できるかな?
  • 2024年の生活について。これまで通り、ライフワークバランスを保ちながら家族仲良く過ごしていきたい。
  • もーちょい本を読みたい
  • もーちょい英語を勉強したい
  • ドラム叩きたい
  • 誰かとの雑談Podcastもやりたい

【Ruby基礎】AtCoder Beginner Contest 080 A - Parking

■はじめに

Rubyの基礎的な問題をたくさん解くことで基本的な考え方やメソッドの使い方を定着させたい。 基本的にはAtCoderというプログラミングコンテスト競技プログラミング)の過去問を使う。(AtCoderは難易度が分かれており、難易度の低いA問題かB問題を解いていく)

(5/23時点の方針) メソッドの切り分け方や値の受け渡しを練習するために、コード長の短さについては気にせずに書くことにする。

(2022/10/17時点の方針) しばらくはB問題を小さい番号の方からやっていく。たまにA問題もやるかも。

(2023/11/10メモ) 忙しさにかまけて半年くらい空いてしまった。またA問題からやっていく。

■問題

●出典

AtCoder Beginner Contest 080のA問題 https://atcoder.jp/contests/abc080/tasks/abc080_a

●問題文

駐車場があり、以下の二種類のプランのどちらかを選んで駐車できます。

  • プラン 1 : T 時間駐車した場合、A×T 円が駐車料金となる。
  • プラン 2 : 駐車した時間に関わらず B 円が駐車料金となる。

N 時間駐車するとき、駐車料金は最小でいくらになるか求めてください。

●制約

  • 1≦N≦20
  • 1≦A≦100
  • 1≦B≦2000
  • 入力は全て整数

●入力

入力は以下の形式で標準入力から与えられる。

N 
A 
B

●出力

駐車料金が最小で x 円のとき、x を出力せよ。

■回答

●愚直に書く

n*abの小さいほうが解答、ということかな。

n, a, b = gets.split.map(&:to_i)
puts [n*a, b].min

通った!

●メソッド化して書く

メソッドを作る練習のために、あえてそういう書き方をする。 久しぶりなのでやっておくか…! (↑っていう記載が2023/6/22の投稿にもあった汗)

メインメソッド、小さい方を出すメソッド、標準入力を取得するメソッドの3つを作成。

def main
  n, a, b = read_nums
  puts show_min(n, a, b)
end

def show_min(n, a, b)
   [n * a, b].min
end

def read_nums
  gets.split.map(&:to_i)
end

main

通った!

●11/13追記

juneboku さんにアドバイスをいただきました、いつも大感謝…!🙏

  • show_min メソッドについて、表示は行っていないので show って言わない方がよさそう

→確かに、showしてないなぁと思いました😂 小さい方を「判定」しているのでjudge_minくらいかな…!

リファクタリング/別アプローチ

もっと短い書き方あるのかな。 ちょっと思いつかないのでパス。

●他の方の回答例

改行やスペースを省いているかどうかの違いだけで、上位の皆さんも全員同じでした。

●出てきたメソッド等

公式リファレンスを見る訓練。

■振り返りなど

久しぶりで標準入力の取り方も忘れていた。 また定期的にやっていきたい。