通常のブラウジングとChatGPTの個人的な使い分け

発端

 ChatGPTが普及して少し経ってから私もChatGPTを積極的に利用するようになりました。最初は「ChatGPTやっぱり便利」と思っていたのですが、個人的には通常のブラウジングとChatGPTの使い分けに課題を感じるようになりました。「これは通常のブラウジングのほうが求める結果を見つけるのは速いのでは？」などと感じる機会が少なからずあったからです。個人的に感じているストレスとそれに対する解決策を考察したものですが、今後も使い分けについて考えることがありそうです。

---

ストレスな部分

 一部前述していますが、ChatGPTでストレスに感じた部分は以下です。

• レスポンスの遅さ
• 「 通常のブラウジングのほうが求める結果を見つけるのは速いのでは？」と感じる
• 質問を続けて行ったとき、前の質問にて指定した前提条件を無視することがある

特に、2番目3番目が苦しいです。無課金利用なので、レスポンスが遅いのはそこまで問題ではありません。課金すればレスポンスが良くなるはずです。

 「 通常のブラウジングのほうが求める結果を見つけるのは速いのでは？」と感じる場面は、単純な質問をしている場面が多い気がします。一時的に忘れてしまっているコマンドを探すために質問していたりといった場面です。ChatGPTから的確な回答を引き出すためには、たとえ軽い調べ物であっても情報がある程度必要になります。それも単語区切りではうまくいかず、一文考えてChatGPTに質問するよりも、GoogleやYahooで単語区切りで入力したほうが良いです。単純な質問の場合、ChatGPTから一発で的確な回答を引き出すよりも、ブラウジングして1ページ目に出てきたWebページから正しい回答を見つけたほうが速いです。単純な質問の場合には自分で求めている回答がどれか、殆どの場合はWebページを見ればすぐに分かるからです。

 「質問を続けて行ったとき、前の質問にて指定した前提条件を無視することがある」という現象は、複雑な質問をしているときに発生することが多い気がします。例えば、Railsを用いて何かしらの機能実装を行うための方法を長文で質問した場合などです。ただし、最近はあまりこの現象は発生していません。私の質問の仕方が気づかぬうちに変わったのか、ChatGPTが何かしら変わったのか、詳細は分かりません(履歴OFFにしていなければ過去の質問を拾ってこれたのですが...)。この現象が発生した場合には条件を全て網羅して質問するのが良さそうですが、どうしても長文になり、仮に条件を増やして続けて質問してしまうと回答も似たような回答が続いてしまいます。これは個人的にかなりストレスです。

---

そもそもの特性

 通常のブラウジングとChatGPTの検索に関する特性について改めて考えてみると、以下のような点が挙げられます。

• 通常のブラウジング

  • 1つの検索に対して複数の回答候補(Webページ)を得られる。
  • Webページを覗いて、求める回答を探す必要がある。
  • 単語区切りで検索できる。
  • 長文で検索できない。
  • 検索履歴を残せる。
  • 正しくない回答が紛れている可能性がある。

• ChatGPT

  • 1つの質問に対して1つの回答(文章)を得られる。
  • Webページを覗いて、求める回答を探す必要がない。
  • 単語区切りで質問できない。
  • 長文で質問できる。
  • 質問履歴を残しておけない(オプトアウトして履歴OFFにもしているため)
  • 正しくない回答が紛れている可能性がある。

 通常のブラウジングとChatGPTの検索に関する特性で一番異なる点は、やはり単語・長文の使い分けだと感じます。通常のブラウジングにて単語区切りで検索を行うのは当たり前ですが、ChatGPTで単語区切りの質問をしても、最適な回答が得られる可能性は低くなるでしょう。逆にChatGPTで長文の質問をすれば、それだけ多くの情報を与えることができるので最適な回答を得られる可能性は高まりますが、通常のブラウジングで長文の検索をしても、最適な回答が得られる可能性は低くなるでしょう。

---

具体的にどう使い分けるか

 現状、個人的には以下のようは方針が良さそうです。

• 通常のブラウジング

  • 求める回答がある程度分かっている場合。具象的な場合。

• ChatGPT

  • 求める回答がある程度分かっていない場合。抽象的な場合。

 通常のブラウジングのみで生活(何かしらの開発に必要な検索も含めて)してきたこともあり、通常のブラウジングは汎用的に使えることは分かり切っています。元々はこれしかなかった。結論としては、通常のブラウジングは「求める回答がある程度分かっている」場合に用いて、ChatGPTは「求める回答がある程度分かっていない」場合に用いるのが良いのではないかと考えました。ついつい何もかもChatGPTに質問しがちではありますが、質問の文章を考える思考的コストは大きいです。楽をしようとChatGPTに聞いているはずが、通常のブラウジングのほうが本当は楽という状態になるのは避けるべきです。であれば、本当に必要な場面でのみChatGPTを用いるのが良いでしょうし、その場面は「求める回答がある程度分かっていない」場合です。ChatGPTに質問して「求める回答をある程度分かっている」状態にしてから通常のブラウジングを行うのが良さそうです。もし既に「求める回答がある程度分かっている」のであれば、ChatGPTではなく通常のブラウジングで良いでしょう。

---

まとめ

 通常のブラウジングとChatGPTに関して、個人的に感じているストレスとそれに対する解決策を考察しました。その結果、通常のブラウジングは「求める回答がある程度分かっている」場合に用いて、「求める回答がある程度分かっていない」場合には前段階としてChatGPTを用いるのが良さそうだという結論に至りました。ただし、この結論は現時点における私の個人的なものであり、またChatGPTに関しては3.5しか経験していません。GPT-4を経験すれば考えは変わるかもしれませんし、近いうちにGPT-4を試す必要があります。もしGPT-4によって今回の結論が変わるのであれば、別途記事を残したいと思います。

Railsのフォーマッタ調査

 最近Railsを書いていてRubocopを適用した際に、ここはifのほうがすっきりわかる気がするけど、||に直されちゃったな〜などと思うことが何度かありました(それはRubocop特有だと思います)。そもそも私はこれまでRubyのフォーマッタはRubocop（フォーマッタ機能のみ使っているわけではないですが）しか使ったことが無いので、他にどのようなものがあるのか調べた内容を残しておきます。

ざっと挙がったもの

• Rufo^[1]
• prettier-ruby^[2]
• rubyfmt^[3]
• ERB Lint^[4]

所感

 個人的に「あっこれ使いたい」と真っ先に思ったのはERB Lintです。erbファイルはRubocopではカバーできない部分なので、これは助かりそうです。現状一番使い慣れているRubocop + ERB Lintの組み合わせは一度試してみたいです。
  先に上げた4つは何れも開発が継続されているようです。基本的にどれもRubocopよりも高速な動作をしそうですが、Rubocopがフォーマッタとして機能するだけではないことを考えると、私の場合は一旦このままで良い気がしています。もし試すとするならば、イントールが手軽なrubyfmtから試すと良さそうです。

References

• Rufo contributors：rufo、GitHub、入手先 < https://github.com/ruby-formatter/rufo >
• prettier-ruby contributors：plugin-ruby、GitHub、入手先 < https://github.com/prettier/plugin-ruby >
• rubyfmt contributors：rubyfmt、GitHub、入手先 < https://github.com/fables-tales/rubyfmt >
• ERB Lint contributors：erb-lint、GitHub、入手先 < https://github.com/Shopify/erb-lint >

React開発についてChatGPTに聞いてみた記録

 多くの方が試しておりn番煎じかは分かりませんが、React開発についていくつかChatGPTに聞いてみたので、記録として残しておきます。

Q. あなたへの質問でReactを用いた開発速度を速めたい場合、どのような質問が有効でしょうか？

Q. 複数人での画像シェアを目的としたWebサービスを作成するとして、Reactと共にどのようなライブラリが利用できますか？

Q. 複数人での画像シェアを目的としたWebサービスをReactで作成する場合、どのようなライブラリを用いて、どのようなサイズに画像を圧縮することがおすすめですか？

所感

 私はあまりChatGPTを触っているわけではないですが、勉強のためにTerraformでコードを提案してもらったりといった形で軽く利用してきました。コードの書き方などで詰まることの解決策にも利用できると思いますが、私のように技術選定に慣れていない人間にとっては、どのようなアーキテクチャでサービスを構成するかという提案をしてもらうことで、開発初期のスピードアップが図れそうだなと感じました。
 巷では、「GPT3.5とGPT4は別物だ」といった声も聞こえているので、落ち着いたらGPT4やCopilotもきちんと触ってみたいです。少し話はズレますが、自殺相談のチャットなどもそのうち裏でChatGPTが回答するようになるのかなあと思ったりしました。今でも自動チャットで相談に乗ってくれるようなサービスはありますが、個人的な感覚では、そこに人間的な温かみを感じるような回答はされるのだろうか気になっています。少なくとも、GPT3.5だと試したみた結果微妙そうでした。

References

• OpenAI：ChatGPT、ChatGPT、入手先 < https://chat.openai.com/ >

React useInsertionEffectについて

useInsertionEffectの用途

 React Docsに以下の記述^[1]がある通り、このHookはCSS in JS ライブラリの開発で用いるもの。DOM変更前に発火する。

useInsertionEffect is aimed at CSS-in-JS library authors. Unless you are working on a CSS-in-JS library and need a place to inject the styles, you probably want useEffect or useLayoutEffect instead.

useInsertionEffectを用いるメリット

 ランタイムでのstyleタグ挿入は以下の問題がある。useInsertionEffectを用いることで、後者の問題を解消することができる。

• ブラウザによって頻繁にスタイルの再計算が行われる。

• Reactのライフサイクルにおいて、間違ったタイミングで発火すると非常に動作が遅くなる。

所感

 Reactのライフサイクルにおいて、間違ったタイミングで発火すると非常に動作が遅くなる。^[1] これは実際に体感することがあったので、個人的にこうしたReactでのスタイル関連hookは今まで調べたことがなく興味深かった。このhookは基本的にCSS in JS ライブラリ内でしか使うことが無いが、本当に小さいCSS in JS ライブラリは意外と手軽に開発できそうだと感じた。CSS in JS ライブラリ開発についてもう少し調べてみたい。

References

• React Organization：useInsertionEffect、React Docs、入手先<https://beta.reactjs.org/reference/react/useInsertionEffect>

Svelteについて調べてみた。

Svelteとは

 Webアプリケーションフレームワークの1つ。ただ、公式HPではSvelteはコンパイラ ^[1]という記述もあり、従来のWebフレームワークとは異なる軸を持っているように思える。

Svelteの特徴

• テンプレート関連
  • ボイラープレートの無いコンポーネントを作成できる。
    • そもそもボイラープレートとはなんぞやというと、プログラム上で重複する定型文的なコードのこと。Create React Appなどで作成するテンプレートも当てはまるはず。
    • SvelteはReactやVueよりも少ないコード量で同等の実装を行うことが可能。 -コンポーネント関連
  • トップレベル要素を複数記述できる。
    • ReactやVueでは1コンポーネントにつき1トップレベル要素と決まっている。
  • stateの更新には代入演算子を使う。
    • useStateといったhookを利用する必要はなく、通常の変数のように値の更新ができる。
• レンダリング関連
  • 仮想DOMを使わない。
    • 多分一番の特徴。
    • 仮想DOMはイベントドリブンなUI開発を達成するために利用されるが、イベントドリブンなUI開発は必ずしも仮想DOMを必要としない。Svelteでは仮想DOMを使わないことで、より高速なレンダリングを目指している。
• 状態管理ライブラリを必要としない。
  • Reduxなどを必要としないという意味だと思うが、詳細な説明が書いてなかったので追って調査したい。

個人的な感想

 Reactを使っていて無駄にdivや<>が増えてしまうという経験があるので、トップレベル要素を複数記述できるのは、コンポーネントをもう少し柔軟に書くことができそうで地味に嬉しい。
 仮想DOMを使わないのは素のJSに近づくということで、仮想DOMを利用することが当たり前の今となっては少し抵抗がある。自分がこれまで経験した開発では仮想DOMが原因で遅くなるということはあまり起きていない（ただ、これは自分の経験が浅いからだと思う）。今すぐReactやVueといった仮想DOMを利用するWebアプリケーションフレームワークが消えるわけではないと思うが、仮想DOMを利用しない流れが増すとは思われる。

References

• [1] svelte.dev：コード量を減らす(Write less code)、Blog、入手先 <https://svelte.jp/blog/write-less-code>
• [2] svelte.dev：Svelte、Svelte公式HP、入手先 <https://svelte.jp>

Symfony UXについての調査

Symfony UXとは

 Symfony UXは以下の説明^[1]の通り、シームレスにJavaScriptをSymfony Applicationで扱うための取り組み・ライブラリとのこと。Stimulusをラップしているようです。

Symfony UX is an initiative and set of libraries to seamlessly integrate JavaScript tools into your application. For example, want to render a chart with Chart.js? Use UX Chart.js to build the chart in PHP. The JavaScript is handled for you automatically.

Behind the scenes, the UX packages leverage Stimulus: a small, but powerful library for binding JavaScript functionality to elements on your page.

Symfony UXには以下を始めとするパッケージが存在し、ReactやVueなどのWebアプリケーションフレームワークにも対応しています。

• ux-react
• ux-vue
• ux-twig-component
• ux-live-component:

Symfony UXのメリット

 なるべくJavaScriptを書かずにSymfony ApplicationをUIリッチ・UXリッチにできるのは良さそうです。ただ、そもそも用意されているパッケージが少ないので^[2]、ある程度リッチなアプリケーションにしようとすると結局JavaScriptを書くことになりそうです。

References

[1]. Symfony Organiztion：The Symfony UX Initiative & Packages、Symfony Documentation、入手先 < https://symfony.com/doc/current/frontend/ux.html > (参照 2023-01-31)
[2]. Symfony Incorporated：Symfony UX、入手先 < https://ux.symfony.com/ > (参照 2023-01-31)

React.lazyについての調査

React.lazyとは

 Docsには次のように書いてあります。^[1]

React.lazy 関数を使用すると、動的インポートを通常のコンポーネントとしてレンダーすることができます。

ここでいう動的インポートとは、次のようにimport文を利用した通常のインポートのこと。

import SampleComponent from './SampleComponent';

Ract.lazyを利用すると、次のように記述することができるとのこと。

const SampleComponent = React.lazy(() => import('./SampleComponent'));

React.lazyのメリット

 React.lazyを利用することで、初回レンダリング時に全てをインポートする必要がなくなり、インポートを必要とするときに初めて読み込むということが可能になる。

React.lazyの適用箇所

 React.lazyを利用したコード分割には、ルーティング単位でのコード分割が良いとのこと。^[2]

コード分割を導入するにあたって適している場所はルーティングです。Web を使用するほとんどの人は、多少のロード時間がかかるページ遷移に慣れています。また、ユーザがページ上の他の要素を同時に操作する可能性を減らすよう、ページ全体を一度に再レンダーすることが多いでしょう。

以下のようなコードがあった場合、問い合わせページ(inquity)では商品ページ(products)のコンポーネントは不要なので、問い合わせページに遷移した際は商品ページのコンポーネントは読み込まずに済む。

import React, { Suspense, lazy } from 'react';
import { BrowserRouter as Router, Routes, Route } from 'react-router-dom';

const Products = lazy(() => import('./routes/Products'));
const Inquiry = lazy(() => import('./routes/Inquity'));

const App = () => (
  <Router>
    <Suspense fallback={<div>Loading...</div>}>
      <Routes>
        <Route path="/products" element={<Products />} />
        <Route path="/inquiry" element={<Inquiry />} />
      </Routes>
    </Suspense>
  </Router>
);

References

[1][2]. React Organization：コード分割、React Docs、入手先 < https://ja.reactjs.org/docs/code-splitting.html > (参照2023-01-31)