RubyGems公開準備
作成内容が未熟では?とためらう気持ちがありつつも経験を積むため、公開までもっていくことにしました。
そのためにgemの内容を見直していきます。
出力内容の整形から。
■日付を年月日形式で出力。
timeをdateクラスとして取り出し、整形。
(require 'date'の記述を忘れないこと。)
transformed_data["日時"] = transformed_data["日時"].map { |time| Date.parse(time).strftime("%Y年%-m月%-d日")}■気温に「度」を追記。
ここまで作業して、そもそもそれはgemの役割だろうか?と思えてきました。
このgemの目的は情報の取得。
gemのユーザーはフォーマットを自由に設定したいかもしれない。
変えてもらって良いとはいえgem内で設定されていれば変更が面倒です。
gemを利用するメリットが薄れてしまいます。
chatGBTに相談。
gemはあくまで一つのライブラリーであり、その使用方法や表示方法は使用者が自由に決めることができます。そのため、一概に「整形する必要がない」とは言えません。
しかし、gemの目的がデータの取得や処理であり、出力については使用者に任せる、という姿勢を持つことは一般的です。これには次のような理由があります。
1. 自由度: 使用者は取得したデータを自身のプロジェクトに合わせて自由に利用したいと考えることが多いです。そのため、gem側で固定の形式に整形してしまうと、使用者の自由度を制限してしまう可能性があります。
2. 汎用性: データの形式や出力の形式はプロジェクトにより大きく異なるため、一つの形に固定してしまうと汎用性を損なう可能性があります。
3. 整形の負担: 出力結果を整えるためのコードをgem側で書くと、その分ソースコードが長くなり、メンテナンスも難しくなります。
ですから、gemを作成する際には内部でデータを取得し、そのデータを渡す役割に集中し、出力の形式については使用者に任せる、という考え方が一般的です。ただし、出力を美しく整形することがgemの目的であれば、それに合わせた設計をするのも一つの方法です。
具体的な方法としては、例えばユーザーに出力フォーマットを選ばせるオプションを用意して、デフォルトではシンプルなデータ形式（例えばハッシュ）を提供し、必要に応じて整形された形式（例えばJSONやXML）を提供する、というような実装にすることが考えられます。そのようにすることで、gemの使いやすさや汎用性を保ちつつ、一部の必要な場面では整形された出力を提供することが可能です。
上記を踏まえて、整形するのではなくデータはハッシュ形式とし、出力される値が扱いやすいように変更していくことにします。
■weatherコードは変換させる→対応
■時刻は日本時刻に変換する
こちらはAPI URLにタイムゾーンのパラメーターをつけることで対応できました。
module WeatherToday でデータが取得でき、exeファイルの実行で取得したデータが確認できるように変更。
ReadMeとgemspecの修正をしていきます。
修正後、github actionでfailedが発生。
ログを確認しrubocopの警告に従う必要があることを把握しました。
Running RuboCop...
RuboCop failed!
Inspecting 11 files
.........C.
Offenses:
spec/weather_today_spec.rb:7:1: C: Metrics/BlockLength: Block has too many lines. [37/25]
RSpec.describe WeatherToday::WeatherClient do ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
spec/weather_today_spec.rb:12:3: C: Metrics/BlockLength: Block has too many lines. [32/25]
context 'when fetching weather data for kagoshima' do ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
11 files inspected, 2 offenses detected
Error: Process completed with exit code 1.モックデータを含んでいるため、行数が増えてしまっていました。
手元のrubocopで初期設定用のファイルを追加し、初期状態を修正するか検討。
(以下のコマンドで.rubocop.yml ファイルの作成ができました。)
% bundle exec rubocop --auto-gen-config参照リンク:【Rails】RuboCopの導入 ~ おすすめルールの設定方法
テストはしたいのですが、可読性は損ないたくない。
結局デフォルトの設定のままコード内容を見直し、規定の行数25行以内に収めました。
なお、設定を検討するためにファイルを作成したところ、Terminal側とGithub Actions側のrubocopの表記とで相違が出てしまい、何度もrunをかけることになってしまいました。
今後は気をつけたいと思います。
fatal: refusing to merge unrelated historie
作業中のブランチを粗雑に扱ってしまいコンフリクト発生。
不用意なundoでリモートとローカルのリポジトリのログに不一致が生じてしまいました。
一旦、ローカルのリポジトリの情報を名前を変更してバックアップを用意(.backupを付与するなど)。
リモートリポジトリをクローン
% ghq get <リモートリポジトリのURL>クローンしたリポジトリにバックアップリポジトリのファイルをコピー。
同名のファイルは上書きされますが、差分をGithub Desktopで確認できます。
必要な変更を取捨選択。
「不要なファイルがバックアップから追加された」といったことがあれば、discard chengesで変更を破棄できます。
「-rf」オプションは強制上書き。
参照リンク:Linuxで既存サブフォルダごと上書きコピーする
ちなみに、Github Desktopのある undo ボタンはコミットの取り消し→ステージングに戻す処理。
ついでにgit undoを確認。
参照リンク: How to undo (almost) anything with Git
まだほぼ使ったことがなかったのですが、さまざまなシーンで使えるようなので早めに慣れていきたいところです。