ハクトーバーフェストへの最後の貢献として、私は Bytechef というプロジェクトに取り組みました。 Bytechef は、ローコード API 統合およびワークフロー自動化プラットフォームです。さまざまなコンポーネントを追加して接続し、API からの応答を使用できる制御フローを作成することで、API を介してサポートされているサービスの大規模なリストと対話できるようになります。
私の仕事は、Baserow というデータベース サービスのコンポーネントに新しい機能を追加することでした。私が取り組まなければならなかった機能は、コンポーネントがデータベース内の行を更新できるようにする「アクション」(つまり、コンポーネントの関数) でした。
Baserow - 行の更新アクション
#1645
Baserow コンポーネントの行更新アクションを実装して、ユーザーが Baserow データベース内のテーブル内の特定の行を変更できるようにします。
アクションのプロパティ:
- テーブル ID - 行を更新するテーブルの ID
- 行 ID - 更新する行の ID
- user_field_names - このエンドポイントによって返されるフィールド名がフィールドの実際の名前であるべきかどうかを示すブール値
- フィールド - テーブルのフィールドとその新しい値のマップ。このプロパティは、行内で更新されるデータを指定し、ユーザーが 1 回の操作で複数のフィールドを変更できるようにします。
出力:
- row - 指定されたテーブル内の行に関連付けられたすべてのデータフィールドと値を含む更新された行オブジェクト
ドキュメントリファレンス: https://baserow.io/api-docs
</div>
<div class="gh-btn-container"><a class="gh-btn" href="https://github.com/bytechefhq/bytechef/issues/1645">View on GitHub</a></div>
ログイン後にコピー
この号にサインアップするまで、私は Java を最小限しか使用していませんでした。私は学校のコースの一環として小さな JavaFX プログラムをやったことしかありませんでしたが、もっと学びたいと思っていました。私は自分で少し勉強していたので、パッケージ、アクセス修飾子、依存関係、プロジェクトで使用されるビルド ツールである Gradle などの概念についてはある程度の知識がありました。これらを知っていれば、このプロジェクトに参加することへの不安は確実に軽減されました。 Gradle プロジェクトが、それぞれ異なるビルド構成を持つサブプロジェクトとサブパッケージでどのように構成されているかを学んだので、プロジェクトの構造を理解しました。
クラスメートの Arina は、私たちが同じプロジェクトに取り組んでいることに気づき、コンポーネントを追加するための開発者ドキュメントと、そのコンポーネントにすでに定義されているアクションへのリンクを示して、親切にもいくつかのヒントを教えてくれました。これは、関連するファイル/ディレクトリを見つけるために自分でリポジトリを調べる必要がないことを意味します。しかし、もし必要であれば、git grep、GitHub のコード検索、または IntelliJ の検索を使用したでしょう。 gitblame を使用して、作業しようとしていたコンポーネントの履歴を確認したところ、すべて 1 つのコミットで開発されたことがわかりました。
プロジェクトの貢献ドキュメントは、詳細な手順が段階的に説明されており、非常に理解しやすかったです。しかし、このプロジェクトは非常に若いようでした。いくつかの README ファイルに // TODO.
とだけ書かれていることに気づきました。
変更を加える前にプログラムをコンパイルして実行して、どのように機能するかを確認しようとしましたが、大まかなプロセスでした。私がとったメモをざっと見てみましょう:
コンパイルが完了した後 (1 時間以上かかりました)、既存のコンポーネントをチェックアウトするために実行しました。クライアントを使用するアカウントを作成しようとしましたが、許可されませんでした。そこで、提供ドキュメントに戻って、開発に使用できる管理者アカウントが付属していることがわかりました。これは、docker を実行するときに作成されると思われます。 -作成します
ログインした後、Baserow コンポーネントを作成しようとしましたが、クライアントが少し遅かったため、誤って複製を作成してしまいました。削除しようとするとクライアントがフリーズしたため、更新を押したところ、サーバー エラーが発生し始め、クライアントがタイムアウトしました。サーバーとクライアントを再起動しようとしましたが、時間がかかり、また 1 時間かかりそうな感じでした。約 16 分間待った後、一晩終わらせて、後で作業することにしました。
4日後
このプロジェクトに戻るのと、1 時間にも及ぶコンパイル時間に対処しなければならないのが怖かったのですが、Hacktoberfest が終わりに近づいていたので、あまり選択肢がありませんでした。したがって、プロジェクトがエラーなくビルドされ、5 分もかからずに稼働したときの私の驚きを想像してみてください。何が変わったのでしょうか？分かりません。
そこで私はクライアントに飛び、Baserow コンポーネントを見つけました。
図 - Baserow コンポーネントとそのコンポーネント上の既存のアクション
Create Row アクションを追加するには、Baserow API ドキュメントを参照する必要がありました。このドキュメントはメンテナによってリンクされていました。ドキュメントを表示するには Baserow アカウントを作成する必要があり、少し奇妙だと思いましたが、それも大したことではありませんでした。
そこで、既存のアクション「行の作成」をテストしたところ、ページ全体がエラー メッセージになるというバグに遭遇しました。予期しない値を入力したと思いましたが、後でこのバグが私とは関係のない別の問題ですでに追跡されていることがわかりました。
その後のテスト試行では、行の作成アクションが成功したため、アクションがどのように作成されるかを理解するために勉強するのに適していると判断しました。私は、問題、既存のアクション、および貢献ドキュメントを相互参照しながら進めていきました。
アクションは、必要な入力パラメーター、出力スキーマ、およびアクションが実行する実際のプロセスを定義するメソッドを定義することによって作成されることを学びました。
行の作成アクションには、入力パラメーターの定義に使用されるテーブルの行のフィールドを取得するメソッドがあることがわかりました。これを自分のアクションで使用できることに気づきましたが、あたかも行の作成アクションでのみ使用することを目的としているかのように名前が付けられました。使用するのは理にかなっていると思ったので、実際に使用して、メンテナに知らせることにしました。
Baserow API ドキュメントを読んでいると、行を更新するには「PATCH」と呼ばれる HTTP メソッドを使用することがわかりました。このメソッドの存在すら知りませんでした。 PATCH は PUT に似ていますが、リソースを置き換えるのではなく、部分的に変更します。興味深い内容です。
それで、実際にアクションを書くようになり、既存のアクションからコードのほぼ全体を取り出すことができました。受け入れるパラメータ (更新する行を識別するために行 ID を追加しました)、出力スキーマ、および呼び出すメソッド (エンドポイントと HTTP メソッドを変更しました) をわずかに調整するだけで済みました。行 ID を許可するには、Baserow コンポーネントに関連するすべての定数が含まれる constant/ サブディレクトリ内のファイルに定数を追加する必要がありました。
既存のソース コード ファイルすべてにライセンス ヘッダーがあることに気づき、それを自分のソース コード ファイルにもコピーしました。インポートを整理し、コードをフォーマットし、手動でテストするときが来ました。
この時点で、行の作成アクション (既存のもの) の説明が間違っていることに気づきました。Baserow のサンプル データベースに行を作成し、単に作成できると言うのではなく、名前で参照すると書かれていました。一行。メンテナにもこのことを伝えるためにメモを書きました:
図 - Create Rowコンポーネント
の誤った説明
私のアクションはクライアントに表示され、視覚的にはすべてが良好に見えました:
タイトルと説明が表示されました:
プロパティ (つまり、入力パラメータ) が表示されました:
ワークフローは正常に実行され、成功の応答を受け取りました:
そして、Baserow アカウントでテーブルが更新されました:
変更内容に満足したので、フォーマッタとテストを実行しましたが、テストは失敗しました。テストの 1 つでは、Baserow コンポーネントのアクションが 1 つだけであると想定されていたためです。新しいアクションに合わせてテストを更新し、コンポーネントのドキュメントを自動的に生成するスクリプトを実行しました。テストを再実行すると、テストは成功しましたが、アクションに対して単体テストを追加する必要がありました。既存のコンポーネントの単体テストを見て、頭を悩ませました。かなりの進歩があったと判断したので、これで終わりにし、ドラフト PR を開いて、気づいた問題についてメンテナに知らせました。
次の日
既存のテストは怖そうに見えましたが、自分のアクションにもテストを追加する以外にあまり選択肢がなかったので、既存のテストに戻って何が起こっているのかを理解しようとしました。使用されているテスト ライブラリである JUnit Jupiter と Mockito を少し調べてみました。私はそれを少しずつ分解し、LLM を使用して各行で何が起こっているかを理解しようとしました。しかし正直に言うと、私はまだ何が起こっているのか漠然としか理解していませんでした。 Baserow API をモックし、その API 上でアクションのメソッドを呼び出していることはわかっていましたが、それが私の理解の範囲でした。
どうやら、それで十分だったようです。 PR にレビュー準備完了のマークを付けたところ、メンテナは私の変更を受け入れました。彼らはいくつかのフィードバックを提供してくれました。私はそれらを読んだにもかかわらず、貢献フローの一部に従うのを忘れていました。次回は、プル リクエストを作成する前に、貢献ドキュメントを確認する必要があります。
Baserow コンポーネントの行更新アクションを作成する
#1656
説明
#1645 を修正
変更の種類
- 新機能 (機能を追加する重大な変更ではありません)
- この変更にはドキュメントの更新が必要です
これはどのようにテストされましたか?
- 新しいアクションに対応するために更新された BaserowComponentHandler 定義テストでテストされました。
- クライアントを通じて手動でテストされたアクション:
チェックリスト:
- [x] 私のコードはこのプロジェクトのスタイル ガイドラインに従っています
- [x] 自分のコードのセルフレビューを実行しました
- [ ] コード、特に理解しにくい部分にコメントを付けました
- 既存のアクションにもコメントが含まれていないため、コメントは必要ありません
- [x] ドキュメントに対応する変更を加えました
- [x] 変更しても新しい警告は生成されません
- [x] 修正が有効であること、または機能が機能することを証明するテストを追加しました
- [x] 新規および既存の単体テストは、変更を加えてもローカルで合格します
GitHub で表示
初期設定とテストの作成が、この問題の最も恐ろしい部分であることがわかりました。実際に機能を追加するのは比較的簡単でした。しかし、この問題で本当に素晴らしいと思ったのは、よく整備されたドキュメントと理解しやすいコードのおかげで、あまりよく知らない言語でプロジェクトに貢献できたことです。
これが、Hacktoberfest 2024 の最後の PR でした。総括投稿は近日公開予定です!
bytechefhq
/
バイテクフ
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
