😍

Open AIを利用したPrompt Codingでどこまで実務で使えそうなユースケースまとめてみた

2022/12/06に公開

Open AIのGPT-3が流行っていますね。
僕自身も結構前からGithub Copilotを利用して、Prompt Codingしていたのですが、
新しい技術だと思ってどこまでできるのかいろいろ試してみました。
まだリアルタイムで試している途中なので、他にいい使い方できそうだったらユースケースまとめてみます。

公式： https://chat.openai.com/chat

結論

ジュニアレベルで書くようなコードのフィードバックは、ぶっちゃけOpenAIでいけそうな気がしてしまうような気がしました。

Syntax Errorレベルのエラーの指摘のみならず、「Railsっぽく改善するならどうしたらいいか？」みたいなことも教えてくれました。例えばN+1が発生しているコードの改善方法とかもいけました。Linterと違って、「これはダメ」「こう書いて」と選択肢を一つだけ出されるのではなくて、複数の最適化案まで提示されました。

後普通に設計とかもかなりまともな答えが返ってきます。

あとドキュメンテーションで面倒臭いマークダウン書いたりしなくても、自然言語からマークダウンやmermaid変換してくれるので、ここが地味に助かるかな。一番使えそうです。

事例一覧

✅【実装】RSpecでCSVインポートする実装方法教えて

Rspec of csv importでRSpecでCSVインポートを実装する方法を教えてくれた。

RSpec is a testing tool for the Ruby programming language. It can be used to test the functionality of a CSV import script, which is a script that is used to import data from a CSV (Comma Separated Values) file into another system or application.

To write an RSpec test for a CSV import script, you would first need to write the script itself, or have access to an existing one. Then, you would write one or more RSpec test cases that exercise the functionality of the script, such as importing a CSV file and verifying that the data was imported correctly.
Here is an example of a simple RSpec test for a CSV import script:

✅ 【テーブル設計】特定のモデルの設定を扱う場合、同一モデルに置くべきかモデルを分けるべきか教えて

case by caseで、場合によって使い分けろということを教えてくれて、さらにPRO CONまで教えてくれました。
コードレビューのみではなく、設計よりも相談も割と的を得た質問が返ってくるようです。

Suppose you have a blog model when you are writing Ruby on Rails. Now you want to add blog's Setting.
Which is better, to add setting attribute to blog model, or add another model to save blog settings.

Whether you should add a setting attribute to the existing blog model or create a separate model for blog settings depends on the specific requirements and context of your project. Here are some factors to consider when making this decision:

If the settings are closely related to the blog and are only used by the blog, then it may make sense to add them as attributes to the blog model. This can make it easier to manage the data and ensure that the settings are always associated with the correct blog.
On the other hand, if the settings are more general and may be used by other models or objects in your application, then it may make more sense to create a separate model for the settings. This can help to keep the data more organized and maintainable, and make it easier to reuse the settings in other parts of the application.
Another factor to consider is the complexity of the settings. If the settings are simple and only consist of a few attributes, then adding them to the blog model may be a good solution. But if the settings are complex and have many attributes or associations, then it may be better to create a separate model to manage them. This can help to keep the blog model simple and avoid clutter.
In general, the decision of whether to add a setting attribute to the blog model or create a separate model for blog settings will depend on the specific requirements and context of your project. It's best to carefully consider the factors mentioned above and choose the approach that makes the most sense for your specific situation.

【技術選定】HerokuとAWSどっち選んだ方がいいですか？

当たり前すぎて込み入ったことは答えてくれないですが、ジェネラルな意見としては完全に合っている答えが返ってきました。

We are building SaaS app and using Heroku as infrastructure. Now we are thinking of transferring to AWS. Which do you think is better option?

Both Heroku and AWS are popular and widely used cloud computing platforms, and each has its own strengths and weaknesses. Choosing between the two will depend on the specific requirements and needs of your SaaS app.

One advantage of Heroku is that it is a fully managed platform, which means that it takes care of many of the technical details and infrastructure management tasks for you. This can be a convenient and time-saving option, particularly for developers who are not experienced with managing infrastructure. Heroku also has a large ecosystem of add-on services and tools, which can make it easy to add features and functionality to your app.

On the other hand, AWS is a more flexible and scalable platform than Heroku. It offers a wide range of services and tools, which can be combined and customized to support a wide variety of use cases and workloads. AWS also offers a pay-as-you-go pricing model, which can be more cost-effective than Heroku's fixed pricing plans for some applications.

Overall, it is difficult to say which platform is better without knowing the specific requirements and needs of your SaaS app. It is recommended to carefully evaluate the features, pricing, and support offered by both Heroku and AWS, and choose the platform that will best meet your needs.

✅ コードレビューしてください！ -> Syntax Errorレベルの指摘

ジュニアが出してきそうなPRのソースコードをイメージして、実際に「レビューして」と入れてコードを囲むと、「未定義だよ〜」とか「こう直すといいよ〜」とか教えてくれる。RailsのLinterのrubocopがやってくれそうなことを、自然言語で教えてくれるので、エラーがまだ読めない新人さんとかだとかなり重宝するかも！
（クラスの値が複数になったままだったりするので、完全に理解できているわけではなさそうだけど大枠合ってました、Blogs -> Blogであるべき）

please review code below written in ruby

BlogController < ApplicationController
   def show
      @blog = Blogs.find(blog_params)
   end
end

There are a couple of issues with the code you provided. First, the BlogController class should inherit from ApplicationController, not be equal to it. This can be fixed by changing the line BlogController < ApplicationController to class BlogController < ApplicationController.

Another issue is with the show method. It appears that the blog_params method is being used as if it were an argument to the find method, but it is not defined anywhere in the code. Additionally, the Blogs class should be referenced using the Blogs class name, not the blogs method name.

Here is how the code could be fixed:

class BlogController < ApplicationController
   def show
      # Use the correct class name and pass in the correct parameter
      @blog = Blogs.find(params[:id])
   end
end

Rails的APIのエラーハンドリングのベストプラクティス教えて

設計方針から何まで知らないことを教えてくれました。
普通にお金払って教えてもらう内容な気がする。
この辺はGoogleで検索しても、かなり古い記事ばっかり出ていて、かつドンピシャな回答が少なく、非常にありがたいです。実は個別のエラー解決とかよりも、設計とかそちらの方がGoogleにない情報なので、Open AIを使うと見つかる情報だったりするかもしれません。

ちなみに答えはエラーハンドリングクラスを作ればいいよ〜ときたので、追加で「そのエラーハンドリングクラスはAPIからどう呼び出せばいいの？」と質問すると、完全に前後の文脈を読み取って答えを教えてくれました。
確かにいろんなOSS見ているとこういう設計になっている実装見たことありまして、勉強になりました。

Please tell me the best practice of handling api error in ruby on rails

In Ruby on Rails, a common practice for handling API errors is to use a custom error handling mechanism that catches errors and converts them into appropriate HTTP responses.
Here is an example of how you could implement custom error handling in a Rails application:

# Define a custom error handling mechanism
class CustomErrorHandler
  # Handle any errors that are raised in the application
  def self.call(error)
    # Log the error
    Rails.logger.error(error)

    # Convert the error into an appropriate HTTP response
    case error
    when ActiveRecord::RecordNotFound
      [404, {}, ["Not Found"]]
    when ActiveRecord::RecordInvalid
      [422, {}, ["Unprocessable Entity"]]
    else
      [500, {}, ["Internal Server Error"]]
    end
  end
end

# Use the custom error handler in the application
config.exceptions_app = CustomErrorHandler

In this example, the CustomErrorHandler class defines a call method that is called whenever an error is raised in the application. The method logs the error, and it converts the error into an appropriate HTTP response using the HTTP status codes for common API errors, such as 404 (Not Found) and 422 (Unprocessable Entity).
To use this custom error handler in your Rails application, you can set the config.exceptions_app configuration option to the `

how do you use explained class to api controller?

To use the CustomErrorHandler class in an API controller in Ruby on Rails, you can add a rescue_from block to the controller, like this:

class ApiController < ApplicationController
  # Use the custom error handler to catch and handle errors
  rescue_from StandardError, with: CustomErrorHandler

  # Define an API action that raises an error
  def show
    raise ActiveRecord::RecordNotFound
  end
end

✅ N+1が発生するコードへの指摘

pluck使う方法とincludes使う方法を、提示したソースコードレベルで提案されました。
この辺とか、確か僕自身も昔レビュワーから指摘された記憶があり、身につけた知識です。
「Linterではここ教えてくれないからな〜」と悩んでいたところだったのですが、このくらいならレビュワーなしで気付くことができると考えると、やはり新人の方はOpen AIとお付き合いするのはとってもよさそうです。

Improve speed of code below written in Ruby

@blogs = Blog.all
blogs.each do |blog|
  article = blog.article
  article.title
end

「以下のシーケンス図をmermaidで」

よくNotion + Mermaidで設計仕様書書いていたのですが、Mermaidはちゃんと読み込まれなくてエラーになったりとかしんどいな〜と思ってました。
しかしOpen AIで書くと、普通に自然言語で書いたやつが変換するので、UXとしてはかなり最高of最高でした。
ふっつーに全く問題ないmermaidで書いてくれた。今までがんばってmermaid記法覚えてたのがバカらしくなってきました。

以下のシーケンス図をmermaidで

ユーザー：申し込む
アプリ：管理者に通知する
管理者：メールを読む
管理者：ユーザーに対してメールして日程調整する
ユーザー：返信する

最後に

今後やりたいこと（どちらかというと誰かにやってほしいこと）として、以下があります。

Prompt Codingのユースケース集めてコードなるべくかかずに楽したい。事例ベースでいろいろな使い方集めたい
SlackとOpen AI連携して、一人コードレビューできるようにしたい
NotionとOpen AI連携して、技術仕様書を簡単にかけるようにしたい

いろいろ情報交換してくれる人募集中です。

APIリファレンス：

結論