最近ChatGPT周りを見ていて、自分のブログをChatGPTに繋いでブログが言いそうな回答を出してもらうという記事に興味を持った。 自分のScrapboxをChatGPTにつないだ - 西尾泰和のScrapbox 自分のはてなブログをChat GPTにつないだ - hitode909の日記 ChatWP: WordPressをAI化しておしゃべりする しかし、その仕組みが分からなかったため、自分で実際に動かしながら内容を理解してみたい。 ブログを読んだときに感じた疑問点 なぜembeddings APIを使って数値ベクトルを使うことで、そのブログが答えそうな回答を得ることができるのか。数値をプロンプトに入れても意味はなさそうだが、どのようにしているのか？ まずは動かしてみる 自分もはてなブログを使っているので、https://blog.sushi.money/entry/2023/03/

最近2分間コーディングのすすめ、コードを書く習慣のハードルを下げるに触発されて2分間コーディングをやってみている。まずは昔興味が出ていたReactを自作しようをやってみたのでメモ。 やった様子は https://github.com/shibayu36/building-own-react に置いた。メインファイルは https://github.com/shibayu36/building-own-react/blob/main/src/index.tsx create-react-appしたままだと色々おかしくなったのでejectして手直ししたり、JSXのtranspileを置き換えるためにwebpackの設定を少しいじったりしたところが苦労した。そのあたりについては https://github.com/shibayu36/building-own-react/commits/mai

ソフトウェア設計に関する知識が昔のままで止まっていて、最近の設計のためのワードはぼんやりと理解できるものの、はっきりと分かっていないなと感じていた。そこでまだ読んでいなかった設計に関する本を読もうと思い、まずは「エンタープライズアプリケーションアーキテクチャパターン」を読んだ。 エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented SELECTION) 作者:マーチン・ファウラー翔泳社Amazon これまでプログラムを書いていた経験からか、全く知らないパターンというのは少なかったのだけど、これまでの経験知に名前付けを出来たのは良かった。特にシングルテーブル継承、具象テーブル継承、クラステーブル継承の話は面白く、どれも見たことあるしメリット・デメリット分かる！という気持ちになった。 次は エリック・エヴァンスのドメイン駆動設計 (IT Architect

ある機能が重いなどといった理由で、DBのどのクエリが遅いか把握したいことはよくあります。そんな時、PostgreSQLのauto_explainが便利だったので紹介。 auto_explainを使うと、指定した実行時間以上を利用しているクエリに対して、自動で実行計画をログファイルに出力してくれるというもの。詳細はこちら。 https://www.postgresql.jp/document/9.6/html/auto-explain.html https://www.postgresql.jp/document/9.6/html/using-explain.html 最近便利に使えたのは以下の設定。 # 自動でEXPLAIN ANALYZEしてパフォーマンス解析したい時用 session_preload_libraries = 'auto_explain' auto_explain.log

先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。 いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした— 趣味はマリンスポーツです (@hitode909) 2018年3月27日 技術的負債について - hitode909の日記 それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。 思いついたパターンは3つ。 変

最近golangでCLIツールを作っていたのだけど、Linuxのお作法とかいまいち分かっていなかった。そこでそのあたりのことが学べそうな「ふつうのLinuxプログラミング」を読んだ。 ふつうのLinuxプログラミング 第2版 Linuxの仕組みから学べるgccプログラミングの王道 作者:青木 峰郎SBクリエイティブAmazon この本はLinuxにおいてC言語でプログラミングする方法を、Linuxでの重要な概念も含めて教えてくれる本。この本を読めばとりあえずC言語を使ってLinux用のプログラムを書き始めることが出来るようになりそうだった。 それでC言語を使わない場合でも役に立つの？ということだけど、非常に役立ちそうで面白かった。なぜなら、単なるプログラミングの方法を教えてくれるだけではなくて、 Linuxの重要な考え方をファイルシステム・プロセス・ストリームという概念にまとめて教えてくれ

ちょっとAPIを調査したいと思った時に、スクリプトを書くのも面倒なのでcurlとjqとかを利用してみたら、便利だったのでメモ。今回はTrelloをちょっといじってみた。 Redirecter ひとまずcurlでjsonを出す これは普通にcurlするだけ。 curl 'https://api.trello.com/1/boards/4d5ea62fd76aa1136000000c/cards'これでは見づらい。 curlで出たjsonをpretty化する jqに通すだけでpretty化と更に色付けされる。 curl 'https://api.trello.com/1/boards/4d5ea62fd76aa1136000000c/cards' | jq '.' curlで出たjsonの一部だけ表示する jqはjsonをいろいろ絞り込み出来る。 例えばリストの5件目まで表示。 curl 'h

コードレビュー - hitode909の日記 この話。 大体こういう風なやり方をしてる。Diffだけを見るんじゃなくて手元でもコードチェックアウトしてて、それとDiffを行ったり来たりしながらレビューすることが多い。こういう方法のほうがかっこいいよねみたいなのは書くけどその通りにしてもらうことを強制はしないというのも賛同。 逆にcommitの中身*1はあえて見ないようにしてる。僕はレビューする時に、そのコードについての学習が行われていない状態で見たほうが良いなと思っている。commitの中身を１つずつ見ていくと学習が進んでしまって、少しわかりづらいコードもあっても、学習が進んでいるせいで無意識に目からすり抜けてしまうという経験があったので、あえてcommitみないということをしてる。 例外もあって、少し大きめなリファクタリングが行われた時はcommitを１つずつ読んでいくことが多い。少し大

最近開発用のドキュメントをどこに配置するか悩んでて、いくつか試して見てる。今回言っている開発用のドキュメントというのは、コードの触り方も含んだサービスの開発に関するもの。例えば 開発環境セットアップ方法 ページに表示している広告をどのように切り替えたりするか(googleの管理やコードの変更も含めた) サービス内の特定の機能の仕組み 内部用HTTP APIドキュメント などを指している。 結構いろいろ考えるところがあるので、思っていることをまとめてみたい。一応先に結論を言っておくと 基本は実装に一番近いところにコメントとしてドキュメント書くのが良いと思う いろんなパーツが絡みあうような大きな機能の場合、導入部分だけ別の場所に書く 出来るだけrepository内に入れておくと探しやすく、更新しやすいと思う あといろいろ悩んでるので事例あったら教えてください。 起きている問題 ドキュメントは

テスト書きすぎ問題 - hitode909の日記、階層を増やしすぎるとテストが多くなりがちという問題 - はこべにっき ♨みたいにテストの話が何個か出たので、ちょっと関係ないけど最近のテストで気をつけていることの一つについて書こうと思う。テストを書くときに気をつけていることとして、そのテストが何をテストしているのかという対応関係を明確にしながらテストを書くということを気をつけている。 例えば以下の様なクラスがあるとする。 package Blog; use strict; use warnings; sub new { my ($class, $args) = @_; return bless $args, $class; } sub has_favicon { my ($self) = @_; return !! $self->{favicon_path}; } sub favicon_

Web Applicationを綺麗に設計するためのMVACという考え方 - Dive into the Tech World! では、様々な意見をいただきありがとうございました。コメントを見る限り、うまく伝えきれていないなという部分がいくつかあったため、補足としてまとめたいと思います。 前提 前回の記事は一応前提として、以下のようなものがあります。 Web Application設計の新しい手法を提案したわけではない 昔からある手法の理解が自分の中で深まったので、まとめてみたわけです もらった意見とその補足 MVCにおけるMの定義がおかしいのでは Mの定義がおかしいから、Aがある データモデルがMと思うと失敗する これに関しては、「MにSkinnyを」などというように、記事の書き方が少し良くなかったのではないかなと思いました。Mに関しては、DBへのインターフェイス、オブジェクトの層、ロジ