プログラマのための ChatGPT 

ChatGPT活用のポイント 人間だと思って接する 正解がもらえるわけではなく、AIが自分の知識で答えているだけです 優秀な同僚だと思いましょう プロンプトは適当でも大丈夫 「プロンプトエンジニアリング重要！」みたいな話をよく見るけど、そこまで気にしなくて大丈夫 指示が明確でさえあればok まずは気軽に聞いてみましょう 

色々おねがい まずは簡単な用途から DevToys的に使える。大抵のことが依頼できてしまう。 🧑 日本の15:00 はUTC で何時ですか？ 🧑 URL エンコードしてください https://clipkit.co/? こんにちは 🧑 整形してください select * from users left join groups on users.id = groups.user_id 🧑 強度の高いパスワードを10 個作ってください 🧑 ダミー文章を500 文字くらいで作ってください 

変換処理が得意 ↓ 🧑 このCSS をSCSS に変換してください。 ul.list { padding: 1px 5px; overflow: auto; } ul.list li { display: block; margin: 2px 5px 2px 0; } ul.list { padding: 1px 5px; overflow: auto; li { display: block; margin: 2px 5px 2px 0; } } 

変換処理が得意 ↓ 🧑 このERB をSlim に変換してください。 <% @records.each do |record| %> <%= record.email %> <%= record.decorate.created_at %> <% end %> - @records.each do |record| tr td a href=admin_user_path(record) = record.email td.text-right = record.decorate.created_at 

変換処理が得意 既存のツールでは難しかった高度な変換も可能！！（ロジックを理解して書き換えてくれる） ↓ ES6が苦手な人はjQueryで書いてChatGPTに変換してもらう。という使い方ができる。 ChatGPTで学習スピード爆上げになる一例。 🧑 jQuery を使わずES6 以降のVanillaJS で書き直してください。 $(function() { $('#button1').click(function() { $('#area1').append($('#text1').val()).append('\n'); }); }); document.addEventListener('DOMContentLoaded', () => { document.getElementById('button1').addEventListener('click', () => { const textValue = document.getElementById('text1').value; document.getElementById('area1').value += textValue + '\n'; }); }); 

軽いリファクタリングも テキストエディタでがんばるの結構大変なやつ ↓ 🧑 スネークケースの変数名をキャメルケースに変えてください。 const first_number = 10; const second_number = 20; const sum_of_numbers = first_number + second_number; console.log('The sum of the numbers is: ' + sum_of_numbers); const firstNumber = 10; const secondNumber = 20; const sumOfNumbers = firstNumber + secondNumber; console.log('The sum of the numbers is: ' + sumOfNumbers); 

翻訳も得意 単純な翻訳だけでなく、フォーマットを考慮して翻訳してくれたりも（ちゃんとlangをenにしてくれてる！） ↓ 🧑 これはI18n の辞書ファイルです。英語版を作ってください。 ja: site: mypage: index: title: マイページ menu_writer: 記事を作成 en: site: mypage: index: title: My Page menu_writer: Create Article 

フォーマットチェック（バリデーター） XMLやJSONのフォーマットに問題がないかサクッとチェック ↓ このJSONファイルは問題なく、正しくフォーマットされています。各セクションが適切に "heading" と "body" の2つのキーを持つオブジ ェクトとして表現されています。"title", "description", そして "sections" の3つのキーを持つ "article" オブジェクトも適切に定義さ れています。このファイルはJSONの構文に従っているため、JSONをサポートするほとんどのプログラミング言語で読み込み、解析すること ができます。 🧑 このJSON に問題はありますか？ { "article": { "title": "VR 技術を使った仮想体験が可能に！", ・・・以下略・・・ 

エラーを説明してもらう とりあえず聞く。とっかかりが得られたらGoogleで調べる。 ↓ このエラーは、Google APIへのアクセス時に発生するもので、ユーザーがサイトに対して十分な権限を持っていないときに表示されます。具 体的な原因は次のようなものが考えられます： 1. 誤った認証情報：アプリケーションがGoogle APIにアクセスするためには、正しい認証情報（通常はAPIキーまたはOAuth 2.0トーク ン）が必要です。認証情報が正しくない場合、または認証情報が期限切れである場合には、この種のエラーが発生することがあります。 2. 権限が不足している：Google APIには多くの種類があり、それぞれ異なる権限が必要です。例えば、Google Analyticsのデータを読 み取るためには、そのアカウントに対する適切な閲覧権限が必要です。対象となるサイトに対する十分な権限を持っていない場合、このエ ラーが発生します。 問題の解決には、まず使用しているAPIと認証情報を確認することが重要です。それから、Google Cloud Consoleを確認して、必要な権 限が正しく設定されているかどうかを確認します。さらに詳しい解決策を求める場合には、どのGoogle APIを使っていて、どのような操作 を試みたか、そしてどのような認証情報を使用しているか等の詳細情報が必要になります。 🧑 このエラーの原因を教えてください。 Google::Apis::ClientError forbidden: User does not have sufficient permission for site 

コミットメッセージの書き方を聞く 最近Conventional Commitsを採用しているが、慣れるまで型（接頭辞）の選択に迷うことが多い ↓ Conventional Commitsのスタンダードでは、特定のUI変更に対する具体的なコミットメッセージの型(type)は厳密に定められていませ ん。このため、どの型を使うべきかはプロジェクトによります。ただし、一般的には以下の型がUIの変更によく使われます: feat: 新しい機能を追加した場合や大きなUIの変更を行った場合。 fix: UIのバグを修正した場合。 style: UIの見た目やスタイルを変更した場合で、これによる機能的な変更は無い場合。 refactor: UIのコードのリファクタリングを行った場合で、これによる外部から見た動作の変更は無い場合。 しかし、これらのルールはあくまで一般的なもので、特定のプロジェクトでは独自の型を定義している場合もあります。そのため、プロジェクト ごとの規約をチェックしてください。 🧑 Conventional Commits で、UI の変更を行なった場合の型は何にしたらいいでしょうか。 

命名を考える 変数名やテーブル名などの命名をAIと一緒に考えるといい感じ ↓ 1. ai_article_suggestions : AIが提案した記事全体に関する情報を格納する場合。 2. ai_theme_suggestions : AIが提案したテーマだけに関する情報を格納する場合。 3. suggested_themes : AIによる提案であることは明らかである場合や、テーブル名をよりシンプルにしたい場合。 ここからさらに「他には？」「themeという単語は使いたくないです」などチャットでキャッチボールしていくと理想 的な名前が見つかります。 🧑 AI が提案した記事のテーマを格納するDBMS のテーブル名は何がいいでしょうか 

RuboCopの警告に対してアドバイスをもらう RuboCopはドキュメントが英語なので調べるの辛かったり、具体的な修正方法に迷うことも多いですよね。 AIが解説付きで具体的な修正を提案してくれます。 ↓ RubocopのStyle/RedundantConditionという警告は、通常、冗長な条件分岐を指摘します。 あなたのコードはdirection変数が存在するかどうかをチェックし、存在しない場合にsite.directions.find_by(is_default: 1)を使用 します。これはRubyの||=演算子を使ってシンプルに書くことができます。||=演算子は、左辺の変数がnilまたはfalseの場合に右辺の値を 代入します。 したがって、あなたのコードは以下のように書き換えることができます： このコードは、「directionがnilまたはfalseの場合、site.directions.find_by(is_default: 1)の結果をdirectionに代入する」という 意味になります。これにより、Rubocopの警告を解消できます。 🧑 次のコードでconvention:Style/RedundantCondition という警告が出ました。どうすれば解消できますか？ direction ? direction : site.directions.find_by(is_default: 1) direction ||= site.directions.find_by(is_default: 1) 

HTML、CSSも作ってもらう ↓ CSSのフレックスボックス（Flexbox）やグリッド（Grid）を使用することで、HTML要素を簡単に左、中央、右に配置することができます。以 下にそれぞれの方法を示します。 フレックスボックスを使用する方法： ここでは、フレックスコンテナ（.container）内の要素が左、中央、右に均等に配置されます。justify-content: space-between;により、各 要素の間に均等なスペースが確保されます。 🧑 HTML で3 つの要素をそれぞれ左、中央、右に配置するにはどうしたらいいですか？ .container { display: flex; justify-content: space-between; } ・・・以下略・・・ 

HTML、CSSも作ってもらう グリッドを使用する方法： この例では、.containerをグリッドコンテナに設定し、その内部に3つの等しい幅の列を作成しています。各

コードの説明をしてもらう コメントもドキュメントもないClipkitのasync-action.jsを読んでもらいます 🧑 このコードを説明してください (function () { function defineAsyncAction(button) { const buttonOriginalHtml = button.html(); button.on('click', function (e) { const pushedButton = $(this); const asyncAction = pushedButton.data('async-action'); const url = pushedButton.attr('href'); const redirectUrl = pushedButton.data('redirect-path') ? pushedButton.data('redirect-path') : ''; function wait(sec) { const objDef = new $.Deferred(); setTimeout(function () { objDef.resolve(sec); }, sec * 1000); return objDef.promise(); } ・・・以下略・・・ 

コードの説明をしてもらう（結果） かなり適切な解説 このJavaScriptコードは、Ajaxリクエストを用いて非同期処理を行うボタンの動作を定義しています。具体的には、「data-async- action」属性を持つボタンがクリックされたとき、特定の非同期処理（長期間かかる場合や背景で実行する必要がある場合など）を実行し、そ の処理が完了するまでボタンを無効化します。 以下に各関数と処理の詳細を説明します： 1. defineAsyncAction(button): この関数では、ボタンのクリックイベントに対する動作を定義します。クリックイベントが発生した際に は、以下の処理が実行されます： ボタンが無効化され、スピナーアイコンが表示されます（performAction関数）。 サーバーに非同期処理の開始をリクエストし、その処理が終了するまでポーリングを繰り返します（polling関数）。 2. wait(sec): 指定された秒数だけ待機する関数です。非同期処理の一部として、ポーリング間隔を制御します。 3. prepend_url_params(url, params): URLにパラメータを付加する関数です。 4. polling(job_id): サーバーに非同期処理の状態を問い合わせ、処理が終了するまでポーリングを繰り返す関数です。 5. performAction(): ボタンを無効化し、非同期処理を開始する関数です。 最後に、HTMLが読み込まれたときやページ遷移が完了したときに、上記の非同期処理を定義するイベントリスナーが設定されています。 

SQLを書いてもらう ふわっと聞いてみる 🧑 次のテーブルがあります。 テーブル名: users （ユーザー） カラム: id, email テーブル名: view_logs （閲覧ログ） カラム: id, user_id, url, created_at ユーザーごとの閲覧数を多い順で取得するSQL を書いてください。 閲覧のないユーザーもすべて含めてください。 

SQLを書いてもらう（結果） 解説付きで答えてくれるので、とても勉強になる 以下のSQLクエリを使うと、ユーザーごとの閲覧数を多い順に取得し、閲覧のないユーザーも含めることができます。 このクエリは、ユーザーのidとemail、そしてそのユーザーが閲覧したページの数（view_count）を選択します。 LEFT JOINを使うと、ユーザー表のすべての行（閲覧のないユーザーも含む）と、それに一致する閲覧ログ表の行が結合されます。そして、 GROUP BYを使ってユーザーのidとemailでグループ化します。 最後に、ORDER BYを使ってview_countを降順（多い順）で並べ替えます。これにより、閲覧数が多いユーザーが上に表示されます。 SELECT users.id, users.email, COUNT(view_logs.id) AS view_count FROM users LEFT JOIN view_logs ON users.id = view_logs.user_id GROUP BY users.id, users.email ORDER BY view_count DESC; 

SQLの問題点を指摘してもらう ↓ このSQLクエリはかなり大規模で、特定の範囲で最適化できるかもしれない要素がいくつか存在します。以下、一部の提案を記載します： 1. カラム選択：クエリが非常に多くのカラムを選択しています。必要なカラムだけを選択することで、不要なデータの読み取りを避け、パフォ ーマンスを向上させることができます。 2. インデックス：検索が速くなるように、検索を行うカラムにインデックスを追加することを考えてみてください。これには articles.site_id、articles.page_type、articles.enabled、articles.expired_at、articles.published_at と articles.key などが含まれます。ただし、インデックスはデータベースの書き込み性能に影響を与える可能性があるため、適切に設計・評価する必要があ ります。 3. LIKE句の最適化：現在、多くのLIKE句がクエリに存在しています。LIKE句は一般的に遅いです、特に % を先頭に持つとインデックスが利 用できない可能性があります。全文検索エンジン（PostgreSQLのFTSやElasticSearchなど）を利用することを検討してみてくださ い。 4. OR句の最適化：複数のOR句がクエリに存在しています。OR句は一般的に遅いです、特に複数のOR句が組み合わさると最適化が困難に なります。これを改善する方法の一つは、複数のクエリに分割し、結果をアプリケーション側で結合することです。 5. サブクエリの最適化：一部のサブクエリは最適化が可能かもしれません。例えば、articles.id IN (SELECT DISTINCT "articles"."id" FROM "articles" INNER JOIN... の部分は JOIN を使って書き換えることが可能です。 🧑 以下はPostgreSQL のSQL です。性能を改善できそうな点を教えてください。 SELECT "articles"."id" AS t0_r0, "articles"."key" AS t0_r1, "articles"."site_id" AS t0_r2, "articles"."user_id" AS t0_r3 

クエリー実行計画の分析 実行計画の分析は難解です。AIにやってもらいましょう。 🧑 以下は先ほどのSQL のEXPLAIN の結果です。これを見て改善できそうな点を教えてください。 Limit (cost=9201.12..9566.12 rows=100 width=4446) -> Nested Loop Left Join (cost=9201.12..151245.13 rows=38916 width=4446) Join Filter: (sites_categories.id = categories.site_id) -> Nested Loop Left Join (cost=9201.12..150269.20 rows=38916 width=3133) -> Nested Loop Left Join (cost=9200.85..136879.31 rows=38916 width=2666) Join Filter: (sites.id = articles.site_id) -> Index Scan using index_articles_on_last_published_at_desc on articles (cost=9200.85..136292.54 Filter: (((expired_at IS NULL) OR (expired_at > '2023-05-27 12:25:29.484963'::timestamp withou ・・・以下略・・・ 

クエリー実行計画の分析（結果） 提供されたSQLのEXPLAINの結果を見て、以下の改善点が考えられます： 1. インデックスの追加と調整: articlesテーブルに対するインデックススキャンでは多くの行がフィルタリングされています。これはインデッ クスが最適化されていないか、適切なインデックスが存在しない可能性があります。site_id、page_type、enabled、そして文字列検索 を行っているフィールド(key, title, description)に対するインデックスの追加や調整がパフォーマンス向上に寄与するかもしれませ ん。 2. クエリの改善: 'GUCCI’に対するフィルタリングが重複しています。これはクエリの効率を低下させます。また、同じタグIDに対する SubPlanが2回現れています。これらのクエリの改善が必要です。 3. 文字列操作の最適化: upper関数を用いた大文字変換と~~を用いたパターンマッチングは、パフォーマンスに影響を与えます。この部分の 最適化も検討するべきです。 4. シーケンシャルスキャン: sitesとsites_categoriesテーブルに対してシーケンシャルスキャン（全行スキャン）が行われています。もし頻 繁にクエリされるのであれば、適切なインデックスを作成することで改善されるかもしれません。 これらの改善点は一般的な推測であり、実際の改善はテーブルのデータ分布、DBの設定、ハードウェアの性能などによります。各提案を実 装する前には、その影響を正確に理解し、必要に応じて詳細なベンチマーキングやテストを行うことをお勧めします。