↓今回参加したハッカソン(10/26,27)
目次
作ったプロダクト
私のチームはVSCodeの拡張機能を2つ作りました。
- タイマー・ヒント機能
- 変数名の提案・修正機能
作り方なども含め、それぞれ説明します。
1. タイマー・ヒント機能
まず、こんな画面になっています。
そして使い方の流れとしては以下の様になります。
- タイマーを何分にするか自分で決めて、タイマー開始
- ヒントが欲しいと思ったら「ヒントを取得」を押す
a. 「仕様」に作りたい機能の簡単な説明、「ヒントのレベル」に欲しいヒントの文量を書いた上で押す（200, 400, 600文字のうちから好きな文量を選択できる）
- 出てきたヒントを参考にしながら開発を進める
- タイマーが終了したら画面中央にモーダルが表示される
という流れです。時間以内に実装してやろうという思いでゲーム性を楽しめると思います。
こだわりポイントは以下です。
- ヒントを貰える
- そしてその文量を調整できる
- Gemini APIを使用
- モーダルとして時間切れを伝える
- VSCodeのメッセージ(右下に出てくるやつ)として実装することもできたが、絶対に時間切れに気付けるようにしたいということでモーダルとして実装
GitHubにソースコードを上げています。（他メンバーのリポジトリ）
実は、使ったファイルはほぼこのextension.tsというファイル1つのみです。
自分も作ってみたいという方は、このコードを読むというよりも、以下の2つの記事を読んだうえで自分なりに応用を効かせて作ってみるのをオススメします。
1. 作り方の流れ
2. 具体的にどうやって機能を完成させるかの例
1の記事を見てもらえればわかると思いますが、実はVSCodeの拡張機能ってJavaScriptもしくはTypeScriptだけで簡単に作れちゃいます。
なぜならYeomanというプロジェクト雛形生成ツールが既に用意されているからです。
実際はYeomanを操作するためのyoというCLIを使用します。
そしてそのyoを使うためにgenerator-codeというジェネレーターを使用します。
つまり、以下2つのコマンドを実行するだけでほぼ準備が完了します。
npm install -g generator-code
npx yo code
凄いですよね。拡張機能とか絶対作るの難しいだろ...と思ってたんですが、さすがにこの簡単さはビビりました。詳細は記事をご参照ください。
2. 変数名の提案・修正機能
続いて、2つ目の拡張機能についてです。
変数名を決めるの悩むよね、ということで作りました。
そしてその中でも更に2つのパターンに分けてそれぞれ作りました。
- ホバーしたら提案が出る
- ファイルごと読み取ってまとめて提案が出る
ホバーしたら提案が出る
コードを書きながら柔軟に提案を受け取れるように、ホバーに対応したものです。
例えばこのfuncという関数にホバーすると、「funcをdivideに置き換えますか？」という提案をもらえます。
その提案を受けると、実際にその変更がファイルに適用されます。（この例だとdivideではなくdividになってしまっていますが見なかったことにしてください）
GitHubのリンクはこちらです。（他メンバーのリポジトリ）
ファイルごと読み取ってまとめて提案が出る
一気に提案をもらいたいというニーズもあるかなと思い、ファイルごと読み取ってもらうパターンも作りました。
まず、提案を受け取りたいファイルを開きます。
そこでコマンドパレットを開き、good suggestion pleaseという用意されたコマンドを実行します。
そうするとローディングがはしります。
そして3秒ほど経つとマークダウンファイルが作成されます。これは提案内容のログとして機能します。
最後に「はい」を押して提案を承認すると、変更内容を適用した新しいファイルが作成されます。
流れは以上です。今回我々は生成AIも使用したかったのでVSCode APIだけではなくGemini APIも使用して、コーディングではTypeScriptを使用する、という形で開発を行いました。
- 技術構成
- VSCode APIリファレンス（読みづらい）
- Gemini APIリファレンス（やや読みやすい）
結果
ギリギリ努力賞に滑り込めました...。受賞は初なので嬉しいです！
学び
- 正規表現を少し覚えた
- 変数名を必要な箇所だけ正確に置換するためには正規表現が必要だったため
- 例えばendをstartに置換したくても、endingをstartingに置換したい訳ではない。正規表現を使わないとendingもstartingになってしまう。
- 正規表現が自分の中でただの暗号ではなくなったのは嬉しい
- 変数名を必要な箇所だけ正確に置換するためには正規表現が必要だったため
- VSCodeのDebug Consoleを知った
- ここにconsole.logの結果が出るため
- 個人開発でもブランチを分ければcontribution数が3倍になることを知った
- commit, pr, merge(commit扱い)
- 案外何でも作れるのでは？という自信を得た
改善点
- 生成AIモデルとして使用したgemini-1.5-proの精度が悪い
- 他のチームで「ファインチューニングをした」というところがあって、「その手があったか！」と思った
- GPTなど他のモデルにするのもアリかもしれない
- ホバーの方でも削除機能を実装できたら理想
受賞のコツ的な
ハッカソンで受賞するためには使用技術よりもいかに驚きを与えるか・共感をもらえるかというプロダクトのコンセプトの方が重要だなぁと思いました。
理由は、前回のハッカソンの方が今回の5倍ぐらいいろいろな技術をがっつり使って、今回の2倍ぐらい時間を使ってフルコミットで作り上げたんですが、受賞は叶いませんでした。前回の方が「頑張った」し、「ゴリゴリに技術を使った」のに、結果だけで見れば今回よりも悪い訳です。
前回のハッカソンの振り返り↓
つまり、今回のように「変数名悩むのわかる～」とか「タイマーにヒントつけるの面白いな～」とか「拡張機能作れるんだ！凄い！」みたいな、驚きを与えたり共感をもらいやすいプロダクトの方が人間の心理的に影響が大きいんだなぁと。
なので頑張ったかどうか、技術をゴリゴリに使ったかどうか、とかはそれほど重視されないっぽいです。技術志向の自分からすると少しだけ残念な気持ちになりますが、考えてみれば世の中のサービスも一緒だと気付きました。
使用技術が古くても、機能が単調でも、需要があれば（=共感を貰えれば）爆発的に流行してますよね。当然開発者はお金をたくさん稼いでいると思います。
なるほどなぁ・・・
即席チームで大事なこと
受動的な姿勢は避け、能動的に動きましょう。（今まで自分も受動寄りでしたが、それをやられるとどんなにストレスか、される側になって初めて気付く・・・）
つまりテキスト・ボイスチャット問わず、発言は能動的に行いましょう。とにかくつぶやきまくりましょう。恐らくですが、たくさんつぶやくことによるデメリットは0です。しかしメリットは多いです。
話を振られたら話す、という機械的な会話は個人的に良くないと思います。みんなが能動的に話すような人間らしい会話をすれば、思わぬアイデアが降ってきたりして最終的には合理的に事が進みます。認識齟齬も減らせます。静かなチームは不透明で不合理です。
「結果」だけではなく「思考プロセス」が共有されるのが理想だと思っています。思考プロセスも丁寧につぶやいてくれてれば、「あ、そういう考え方があるのか！なるほど...」という気付きや「こういう考え方もアリかもしれませんよ！」という提案などが生まれます。共同作業による成長の相乗効果がバンバン生まれていきます。
人と話すことが特段好きではない私でも、合理的に事を進めるためにハッカソンではたくさん話すしつぶやくようにしています。
そして、メンバーが決まったら速攻でDiscordサーバを作って招待を送りましょう。チャンネルも複数作って発信しましょう。私のオススメのチャンネル分けは以下です。
- 自己紹介
- 雑談
- メモ
- 疑問
- 共有事項
- 「〇〇を変更したので注意して」とか伝えておくべき重要なこと
- 進捗共有
- 「ここ修正してみた」「これやってみようかなと思ってる」とか軽いノリで
- 日程調整
- アイデア
（おまけ）お気持ち表明
とりあえず思考回路をdiscordにつぶやいてみる、ていう癖があるお節介な人と一緒に開発したいなぁと強く思った。お節介というのは、何かをつぶやいたらそれに対して「ちなみに〇〇という方法もありますよ」とか、とにかくいろいろ喋ってくれる人。話を振られたから話すのではなくて、自分から「とりあえずこれつぶやいておこう」と思って癖のようにつぶやいてしまう人。
実際、そういう人と昔同じチームでプロジェクトを進めていたことがあって、その人のおかげで爆発的に成長できた経験がある。なので自分もその動きをすごく意識しているし、他の人にもやってほしいなぁ...と勝手に思っている。
めっちゃ無駄で不合理に思える会話が実はめちゃくちゃ合理的な結果に繋がっていたというのは大いにあり得ると思っている。
この記事はとても共感できる。