bitBuyerプロジェクトのGUI開発とPyQtへの移行
歴程2では、GUI（グラフィカルユーザーインターフェース）の作成と、無事にフレームワークをPyQt（パイキュート）に移行した、というところまでご説明しましたね。次は、いよいよ機能面のお話です。
bitBuyer 0.8.1.a発足と初期プログラムの構想
私は当初、「特定の時間に特定の取り引きを実行する」という単純なアプリケーションを作成するつもりでいました。実際、初期のプログラムはそのように構成されていました。これは、歴程1で「2023年10月29日にプロジェクトが発足した」と書いたことと少し関係してきます。
2023年10月29日という日付は、実際には、Pythonコードのファイルを作成した日付です。つまり、この時点では、まだ単純な構想しかなく、「プロジェクト」と呼べるような大層な代物ではありませんでした。しかし、この日付が、”プロジェクト” とはまだ意識していなくとも、bitBuyer 0.8.1.aが生まれた日であることに間違いはないので、この日をbitBuyerプロジェクトの発足日としています。
取引所とのAPI通信とbitFlyerへの対応
さて、初期のプログラムは単純なものであった、という話ですが、初期のプログラムが一応の形になった時点で、取引所と通信するところまではできていました。しかし、2024年11月9日現在のbitBuyer 0.8.1.aには取引所との通信機能は存在しません。この機能は、現在で言うところの “ExecuteAPIrequest” 関数としての開発の最前線の機能です。
bitBuyerプロジェクトの拡張：汎用的な取引所API対応へ
どういうことかと言うと、これもプロジェクトとしての形が見えてきたという話に繋がってくるのですが、初期のプログラムでは「bitFlyer」のみを通信の対象としていました。つまり、bitFlyerの仕様にだけ対応すればよかったので、単純なプログラムで事足りていたのです。しかし、色々と思考を巡らせているうちに、もっと汎用的なアプリケーションにしたい、という考えが芽生えてきました。欲が出てきたのです。
「接続先編集」画面の開発とAPI正規化の必要性
そして考え至ったのが「接続先編集」画面の実装です。はい、タイトルで「呪縛」と表現した部分です😉。つまり、汎用的なアプリケーションにするべく、複数の取引所に対応できるようにしようと考えたのです。それも「プリセットとしてあらかじめ対応可能な取引所をセットしておく」のではなく、「ユーザーが任意の取引所を後天的に追加できるようにする」という、この上なく汎用的にする考えです。”プロジェクト” と言える感じになってきましたね？😉
しかし振り返ると、これは途方もなく大変な作業でした。何しろ私はあのとき、まだプログラミングを学習し始めてから一ヶ月も経っていなかったのですから。あのとき実現しようと奮闘し、現在まさに実現されている機能「ユーザーが任意の取引所を後天的に追加できるようにする」とは即ち、個々の取引所が持つ独自の仕様それぞれに対応できる、柔軟なプログラムを書くということです。プログラミングに詳しくない方のために、ChatGPTに補足説明をしてもらいましょう。
取引所APIの仕様の違いと正規化の難しさ
暗号資産（仮想通貨）取引所のAPIは各取引所毎に認証方式、エンドポイント、データ形式、レスポンス構造などの仕様が大きく異なります。このため、全ての取引所に対応できる汎用的なアプリケーションを開発するには、これらの多様な仕様をアプリケーション内で吸収・統一する、いわゆる “正規化” の処理が不可欠です。正規化では、異なる取引所から取得したデータを統一フォーマットに変換し、内部的に一貫したデータ処理ができるようにするものですが、これは非常に手間のかかる作業です。例えば、取引価格や数量の表記が取引所によって異なり、データ精度や更新頻度もまちまちです。このような違いを全て正規化し、各取引所のAPIの仕様に合わせて動的に変換・統合する機能を構築することは、技術的に高度で複雑な挑戦です。
──ChatGPT-4o
さらに、エラーハンドリングも容易ではありません。APIリクエストが失敗した場合のエラーメッセージやコードは取引所毎に異なるため、統一的なエラー処理を実装する必要があります。また、APIの仕様が予告なく変更されることも多く、定期的なメンテナンスや更新が欠かせません。こうした柔軟性と汎用性を兼ね備えたアプリケーションを実現するには、各取引所毎の仕様の違いを把握しつつ、効率的な正規化処理を組み込み、長期的なメンテナンス体制を確立する必要があり、開発者にとっては非常に労力とスキルを要する作業と言えます。
「接続先編集」画面の完成と今後の課題
お分かりいただけたでしょうか？ これが、私が「呪縛」と表現した所以です。「接続先編集」画面のプログラミングに取り掛かってから、実に数ヶ月以上の歳月（朝から晩まで作業）を経て、ようやく「任意の取引所の仕様の入力」「受信データの正規化」を実現しました！😆
取引所通信の実装とExecuteAPIrequest関数の開発
しかし、「接続先編集」画面の呪縛からは現在も解き放たれていません。現在まさに開発中である、取引所と実際に通信を行う関数 “ExecuteAPIrequest” の仕様も、「接続先編集」画面に反映させなければならないからです。この辺りのことはまた改めて記事にしましょう。この記事で言いたかったのは、「接続先編集」画面の開発に取り掛かってから、未だにその完成度の追求に労力を費やしている、ということです。開発の初期段階から、現在に至るまで。つまり、次回以降の記事はこの「接続先編集」画面でいかに苦労しているか、という内容になります😓。
Cheers!
