Torihaji's Growth Diary

Little by little, no hurry.

Railsのdefaultで使われるメモリのキャッシュが本当に別プロセスで使えないか試してみた。

はじめに

みなさん、こんにちは torihaziです。

さっきのAIチャットbotをRedis、Sidekiqと合わせて使うためにRedisについて学んでいるのですが、

そこでキャッシュにまつわる記載が出てきたので、そこに対する理解を深めようと今こうして書いてます。

というかそもそもなんでredisじゃないとダメなのか、使わないとダメなのかを詳しく知る上で。

で結論言うと、railsデフォルトのキャッシュだと、別プロセスで使えないとか再起動したら吹っ飛ぶとかが原因でダメっぽいです。

別プロセスで使えないと何がダメかっていうと、他のサーバから見えないし使えないから?だと。

それがredisを使えば解決されると。

で、この別プロセスで使えないと言う日本語がよくわからなかったので実際にやってみました。

とりあえずやってみる、そう言う記事です。

Railsの立ち上げ

なんでもいいです。rails new して立ち上げてください。

GitHub - torihazi/chat_bot_rails

こいつcloneしてbuildして、やったら多分いけます。dbのcreateとかは適宜お願いします。

で、できた状態で話を進めます。

まずキャッシュを使いたいのですが、そもそも今キャッシュを使えるか実際にやってみます。

docker compose up -dしてrails c してコンソールに入ってください。

Railsでキャッシュを扱うためには Rails.cacheを使うのでキャッシュの書き込みをするために

Rails.cache.write("hoge","huga")で書き込みます。

そうするとtrueと返ってきます。

ちなみにさっきの例はkeyがhogevalueがhuga と言うデータをキャッシュに書き込むよって意味です。

で次は読み取りです。

勘の言い方ならRails.cacheときて何かわかるんじゃないでしょうか。

はい。Rails.cache.read("hoge")です。指定はkeyを指定します。

そうするとキャッシュが機能していれば出力形式は知らないとしても何かしら返ってくるはずですが

結果はnilと返ってきます。

なんでそうなるか。

config/development.rbのcache_storeと言う項目があるのでみてください。

  # Enable/disable caching. By default caching is disabled.
  # Run rails dev:cache to toggle caching.
  if Rails.root.join("tmp/caching-dev.txt").exist?
    config.cache_store = :memory_store
    config.public_file_server.headers = {
      "Cache-Control" => "public, max-age=#{2.days.to_i}"
    }
  else
    config.action_controller.perform_caching = false

    config.cache_store = :null_store
  end

20行目くらいになんか書いてありますね。

よくわかんないけど、tmp下にファイルがなければcache使わない、みたいなことがわかります。

じゃあそのファイル作りましょう。

作り方はコマンドがあって rails dev:cacheです。

これでtmp下覗いてみると作成されます。

じゃあ一回コンテナ再起動してやってみましょう。

立ち上がったらrails cして入って

irb(main):002> Rails.cache.write("hoge", "hoge")
=> true
irb(main):003> 
irb(main):004> 
irb(main):005> Rails.cache.read("hoge")
=> "hoge"

てしたらさっきできなかったことができてますね。

※ちなみにさっき作ったtmpのファイルですが、書き込まれることはないそうです。

あるかないかだけが重要なフラグ目的のファイルだそうです。

書き込まれているのはメモリ上ですね。

でだ。

じゃあ書けるようになったので、タイトルのことをやります。

別プロセスで書く

と言ってもどうするの、と思った方いると思います。

自分もその1人です。

別プロセス。

ターミナル2つ立ち上げてそれぞれでdocker compose exec rails cすればいいだけです。

と言うことでやってみましょう。

Vscodeで立ち上げてそれぞれでrails cをしました。

左では実際に書き込んで読み込めていますが、右では読み込めていません。

と言うことらしいです。

これが redisっていう共通の窓口さえあれば2人仲良く覗きにいけてデータも見れるで

ちゃんちゃん、というハッピーハッピーな結末になるみたいですね。

終わりに

そゆこと。

納得です。ならredis使わないとダメですね。

頑張りますか。

では。

爆速簡易的AIチャットbotの作り方(Rails、Python、Next.js)

はじめに

みなさん、こんにちは。torihaziです。

今日はタイトルの通り、AIチャットbotを作ってみようかと思います。

実務で似たような構成で扱うそうなので、どんなものかを実際に作ってみて

イメージ掴む目的でやってみました。

作成はClaudeが主で、微修正を私が行なったという感じです。

なお、筆者の言語経験としてはNext.jsとRailsは実務でやってるけどPythonは無という感じです

では行ってみましょう。

注意事項

ChatGPTのAPIを使用する都合上、$5くらいお金かかります。

デモ

構成

簡易的な構成図としては

Next.js ⇔ RailsPython(Flask) ⇔ ChatGPT

という形になっています。

RailsPythonはそれぞれ Dockerで個別に立ち上げて、Next.jsはローカルで 開発サーバ立ち上げる感じですね。

├── ai_server
│   ├── Dockerfile
│   ├── app.py
│   ├── docker-compose.yml
│   └── requirements.txt
├── backend
│   ├── Dockerfile
│   ├── Gemfile
│   ├── Gemfile.lock
├── frontend

構築(と言ってもcloneしてください)

GitHub - torihazi/chat_bot_ai_server

GitHub - torihazi/chat_bot_front

GitHub - torihazi/chat_bot_rails

これをして、ai_serverとrailsの方はdocker compose buildとかする前に一度networkを作成してください

docker network create chat_network

これをした後にdocker compose buildとかしてupしてみてください。

繋がってなければ、docker network lsとかdocker network inspect chat_networkしてみてください。

特に後者のコマンドで

[
    {
        "Name": "chat_network",
~~~
        "Containers": {
            "4445786e97ca71935d66b657efeecf43e696e388057ac89913e8eb6d8ad64e6b": {
                "Name": "backend-db-1",
~~
            },
            "d0fda1040494226eb34e72f822bce3f28542adc87e87bb9188288ac6f3ce52cd": {
                "Name": "backend-api-1",
~~
            }
        },
        "Options": {},
        "Labels": {}
    }
]

こんな感じでai_serverの記載がなかったら繋がってないので、もう一度network作り直してやってみてください。

これでRails、Flaskどちらもdocker compose up -dして、Next.jsもpnpm devってしたら繋がると思います。

ChatGPTのクレジット課金

OpenAIのAPIキー取得方法|2024年7月最新版|料金体系や注意事項 #DALLE - Qiita

課金方法はこちらを参考にしてください。

途中、オートリチャージとか求められるかと思いますが、そこはお任せします。

私は最安希望だったので、オートリチャージなしの$5で課金しました。

なお、この記事の途中で取得できるAPI_KEYをai_serverディレクトリ内の.envに

OPEN_API_KEY=apiのkey

として設定しておいてください。

このkey流出すると大変なので、.gitignoreで外しておいてくださいね。

cloneしたらされると思いますが、自力でやった人はお気をつけ。

接続

さてこれだけやればあとは準備OKなので、適当に文字を入力してみればokです

お疲れ様でした。

私はイメージ掴むだけが目的だったので、これにて終幕です。

おまけ

ちなみにこの構成だとシンプルだが、通信量増えるとタイムアウトになったりして本番運用とかなった場合

不安が残る構成だそう。

claudeに聞いたところ、Railsなら下記の構成が良さげらしいので今度はそっちでも作ってみようかと思います。

Frontend → Rails → Redis ⇄ Sidekiq → Python
                   ↑
                Frontend(ポーリング/WebSocket)

終わりに

ストリーミングで文字を早く受け取って、RedisとかSidekiqとか使ってやりたいです。

早くすごくなりたいです。

以上です笑

docker compose で MySQLを立ち上げる(ちょっとGo)

はじめに

現在、Goを触っています。

そこでgorm?とか使うためにMySQLを使うらしいのですが、

Udemyがローカルに入れたものを使っていました。

せっかくならDockerで立てたものを使いたくね?てことで急遽やりました。

この前PostgreSQLのコンテナ立てたしいけるでしょ、という楽観的思考のもと今ノリで書いてます。

いけるかな。

やり方

  1. 公式を読む。

https://hub.docker.com/_/mysql

これを読みます。

  1. docker-compose.ymlを作る。

公式のをパクります。

# Use root/example as user/password credentials
version: '3.1'

services:

  db:
    image: mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: example
    # (this is just an example, not intended to be a production configuration)

あとは必要な以下の情報をちょろっと。

version: '3.1'

services:

  db:
    image: mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: example
      MYSQL_USER: example
    ports:
      - "3306:3306"
    volumes:
      - mysql_data:/var/lib/mysql


volumes:
  mysql_data:

立ち上げ

docker compose upで立ち上がるのを確認

接続

docker compose exec db bashで一旦コンソールへ入る。

次はmysqlコマンドで接続

bash-5.1# mysql -h localhost -P 3306 -u root -p
Enter password: 

パスワードはさっき入れたexample。

これで繋がりました。

この後の話のために

CREATE USER 'notes'@'localhost' IDENTIFIED BY 'tmp_pwd';
CREATE DATABASE notes;
GRANT ALL PRIVILEGES ON notes.* TO 'notes'@'localhost';

だけやっておきます。(udemyのまんまですね)

SHOW DATABASES;で作成したデータベース一覧を見れます。(psqlよりわかりやすかった)

おまけ

で今回やりたいことはgormに繋げること。

と言うことで色々入れます。

作業時のディレクトリ構造はこんなです。

go mod とかした状態です。

で、ライブラリを入れる。

go get -u gorm.io/gorm
go get -u gorm.io/driver/mysql

次は接続用関数を作る

var DB *gorm.DB

func connectDatabase() {
    dsn := "notes:tmp_pwd@tcp(localhost:3306)/notes?charset=utf8"
    databse, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
    if err != nil {
        panic("Failed to connect to database!")
    }

    DB = databse
}

でmain.goはこんな感じ。

package main

import (
    "fmt"
    "log"
    "net/http"

    "github.com/gin-gonic/gin"
    "gorm.io/driver/mysql"
    "gorm.io/gorm"
)

var DB *gorm.DB

func connectDatabase() {
    dsn := "notes:tmp_pwd@tcp(localhost:3306)/notes?charset=utf8"
    databse, err := gorm.Open(mysql.Open(dsn), &gorm.Config{})
    if err != nil {
        fmt.Println("error:", err)
        panic("Failed to connect to database!")
    }

    DB = databse
}

func main(){
    r := gin.Default()
    r.Use(gin.Logger())

    r.Static("/vendor", "./static/vendor")

    r.LoadHTMLGlob("templates/**/*")

    connectDatabase()

    r.GET("/", func(c *gin.Context) {
        c.HTML(http.StatusOK, "views/index.html", gin.H{
            "title": "Notes Application",
        })
    })

    log.Println("Server Started!")
    r.Run() //Defailt Port 8080
}

えー繋がりません。

なんでだ。パスワードあってるじゃん。

Access denied for user 'notes'@'172.18.0.1' (using password: YES)

格闘の結果、AIにも聞いた結果。

CREATE USER 'notes'@'localhost' IDENTIFIED BY 'tmp_pwd';

userの作り方が不味かったみたい。

CREATE USER 'notes'@'%' IDENTIFIED BY 'tmp_pwd';

とすることで"任意のipからユーザ名notesでパスワードがtmp_pwdで接続してきたuserはok"となるらしい。

うまく説明できませんが、多分下記の記事が原因かと。dockerの知識が不足してた。

Dockerのネットワーク、基礎理解は万全ですか?【Dockerコンテナ・グレートジャーニー④】 #container - Qiita

とりあえずこれで繋がりました

終わりに

すぐ終わると思ったのに。

疲れた。寝る。

実務初めて4ヶ月の振り返り

はじめに

みなさん、こんにちは torihaziです

さて、今年は残すは1ヶ月となりました。

寒いですね、私は朝起きるのが遅くなってきました。

あまり生活習慣が乱れないように7時台には起きれるように頑張っていきたいと思います。

では 4ヶ月目の振り返り、startです

感想

そうですね、箇条書きで思いついたこと書いていきます。

  • エラーの解決が早くなった。
  • やっぱりコード書くのが楽しい。
  • 記事投稿が少なかった
  • backendのコードリーディングが早くなった
  • 口うるさいかもしれん
  • Go は難しい

1つずつみていきましょう

エラーの解決が早くなった

これは、同じエラーを何度もみているからかログを意識的に読むようにしていたからか早くなったと感じます。

多分、何度もフロントとバックのコードを行ったり来たりして全体がわかるようになってきたからということも影響している かなと思います。今までは他人が書いたコード(特にバックエンド)の意味を理解することになかなか苦労していました。

しかし「最終的にやりたいことは何か」と言うのがわかると解決までが早いことがわかりました。

例えば、最終的にそれが多分必要だからそこから逆算してこの値がおそらく必要。だからここではこの値を返す必要があってDBにこの値で絞り込んでこの処理を書く必要があるんだけど、多分ここでこれがこうなってるからエラーが返ってくると思うんだよね、あ、やっぱりログ見ると同じところで引っかかってるしビンゴみたいな感じですね。

今まではコードを追うことができていなかったもしくは甘かったのだと思います。

慣れていなかっただけということもあるかもしれません。

実際やってみると、難解なアルゴリズムをつらつらと書いているわけではないし、

1つずつ紐解いていけば基本的なことの連鎖でした。

基礎侮ること無かれですね。Claudeにエラー文はっつけて、言われたことを実施するだけのエンジニアにならなくてよかったです。

やっぱりコード書くのが楽しい

11月初旬は少し腐っていました。全体の要件を理解できていなかったからというのもあったかもしれません。

メンバーにタスクを振るもしくはドキュメントに残タスクを書き出すみたいな少し味気ないものばかりをやっていました。

めちゃめちゃつまらなかったです。コード書かずに1日が終わる時もありました。

ただそこから徐々にプロジェクトの理解が進み、道筋がわかってくるといつの間にか自身のモヤモヤというか焦りが消えていました。

書いていて思ったのですが、自分は目指すべきゴールが分からずに作業を進めることにひどく不快感を覚えるようですね。

確かにむしゃくしゃしていました。焦りもあったと思います。こんなんじゃいつまで経っても稼げんてみたいな。

要件理解するまで人捕まえて聞いて、聞いて、でやっと理解して。

あのとき腐り切らずに途中で持ち直せてよかったです。自分の精神力に感謝ですね笑

PMつまんないというわけじゃないですよ。今思えばさっきも書きましたが要件理解しきれてなかったことが原因ですね。

11月の中盤くらいからコード書くことが増えてきて、やっぱむっちゃ楽しいとなったので思いついたんだと思います。

記事投稿が少なかった

これは少し反省ものですね。技術記事投稿が少なかったです。

1日業務やっていて分からないことの1つや2つ出てくるはずです。

もしなければ昔の自分に向けてRubyの概念の1つや2つ出せるはずです。

出そうとしていないから出ないだけ。

甘えでしたね。12月は頑張らないと。

1週間に1つはやんないとですね。

backendのコードリーディングが早くなった

これはエラー解決の時に読むようになったからですかね。

名前空間とか仕組みが最初わかんなかったのですが、今となっては大丈夫です。

理解の詳細度が上がったからだと思います

口うるさいかもしれない

これは母親譲りだと思います。よく言えば他人を気にかけている見ている、悪く言えばおせっかい口うるさいです。

PMもどきとして"終わらせる"ということに意識を向けるとどうしても"早くしないと、あの人大丈夫かな、詰まってないかな"

と思ってしまいます。それが当人のコードと向き合う時間、考える時間を奪い成長を阻害してしまっているのではないかと。

最近はいい意味で"ほっとく"ことを意識していますが、やっぱり気になります。どうすればいいんでしょうかね。

ただあるところまで行くと一気に母親と同じでその相手に対して無関心状態になると思うので、んーまぁそうならないように気をつけます。

Goは難しい

文字通り、難しいです。

バニラな印象を持ちました。いろんなことを自分で1から書かないといけないなというのが感想です。

ただ1から書けるから制御も細かくできそうかなとも思いました。

現状わからないのはポインタとgoroutineとかいうやつですね。

ifとかforは他の言語と似てるのでそこはハードル低かったです。

頑張りどこですね。

得た知識

フロントバックについて得た知識をつらつらと。

front

  • useSWRはキーが変わると再取得を行う
  • useSWRはmutationする際キーの管理が重要
  • リフレッシュトークンの扱いはシングルトンクラス使うと便利かも
  • Mapオブジェクトはキーとバリューの組み合わせからなるデータ構造で使うと便利なことが多い

front少ないですね。多分まだ頭の中で埋没してそうな気がします。そうですね、現場で使ってる技術の詳細な説明を詳しく書いた記事を12月は書くことにしましょう。react-hook-form、zod、useSWRとかでしょうかね。

back

  • 名前空間は実際のディレクトリ構造と一致しているわけではない
  • module Hogeとか使ってディレクトリ構造と別にすることができるけどわかりにくいからしないだけ。
  • モデルのcreate処理で例外処理目的で!つけるけどそれが可能なのはActiveRecord::Baseを継承したものだけ
  • Mailを送るには ActionMailer::Baseとかいうやつを継承したものじゃないとダメ
  • 変数の存在判定はempty?とかあるけどblank?が便利。
  • frontからjsonをbackに送るにはjson.stringfyしないとダメ

backも少ないですね。多分まだあると思うんですが埋没しているだけですね。理解の詳細度をもっと上げてかないといけません。

インフラ系に関する知識は・・・ですね。ここら辺の知識をどうつけるかが考えところです。

終わりに

今年ももう終わりかけています。

今年の最初を思い出してみるとちょうどHCに入ったくらいですかね。

昔立てた目標を見てみるとまだスクールは卒業しておらず、Goの勉強とかをしていたそうです。

本当は前職9月くらいで辞められていたことを考えると本当に思い切って抜け出してよかったと思います。

まじで人生変わったと思います。

あの時は本当に辛かったですね。

実務と違うことを勉強しないといけなかったので、本業へのやる気を見出すのがきつかったです。

資格を頑張ってとっても特に関係なかったし。

思い出すと目の前暗くなるのでこれくらいにしときますが、

兎にも角にも死に物狂いで頑張ったからこそ今があると思っています。

とにかくやったからです。

ただひたすらに。

それ以外に目標達成する方法はないと思います。

愚直に継続あるのみです。

ということで今年最後の1ヶ月お互い頑張りましょう。

現場からは以上です。

Railsの 例外処理 したければなんでも!つければいいてわけじゃない

はじめに

みなさん、こんにちは torihaziです

今日はタイトルのことについて軽く触れていこうと思います。

というかそれが結論なのでそれ以上言うことないのですが。

ま、いいか。

結論

RailsにおいてDBへのCreate、Update、Deleteとかする際に例外処理をする目的で

create!のように! をつけるかと思いますが、!で例外処理が働くのは

ActiveRecord::Baseを継承したモデルに対してのみです。

経緯

社内プロジェクトの独自実装のクラスで ActiveRecord::Baseを継承していない::Hoge::Hogehoge.create!のようにしてたところ

そんなもんないぞとRailsから怒られたことが発端。

調べてみると、!で例外処理を投げることができるのはActiveRecord::Baseの機能の1つらしい。

終わりに

確かに !つけると例外処理になるのは知ってましたが、あれはActiveRecord::Baseの機能だったんですね。初耳でした。

少ないですけど、今日はここまで。

個人開発-v2-1日目

はじめに

みなさん、こんにちは。torihaziです。

今日から勉強の新しいモチベとして個人開発をまたやりたいと思います。

前回よりかは少しパワーアップしておいて欲しいと思ってます。

それではいってみましょう!!

要件

どういうものを作りたいか。

それはですね、HappinessChainでも使われているのですが

日報アプリケーションです。

アプリケーションからマークダウンエディタを使用して日報を作成し、

それをGithubAPIやらを使用してGithubにpushできる、みたいなそんなアプリケーションです

実務で少しづつできることが増えてきたので、そろそろ少しステップアップしたいなと。

今回の個人開発を通して、認証とGithubAPIとか、他だとCIとか何というか守りの部分も強くなれたらなと思っています。

使用技術

Backendは Railsの 7か8です。これはまだ決めてません。

Frontendは Next.jsの14にしとこうかなと思います。

認証周りはClaudeと相談して 自前で行こうかと思います。

まぁまだ先行きも見えてないので、少しづつやっていきます

リアライザはalba使おうかなと。

最近Rails名前空間も理解が深まったのでそこもうまーくやっていけたらと思ってます。

デザイン

画面としては認証画面、日報一覧画面、日報詳細、更新、作成画面、プロフィール設定画面とかでしょうかね。

終わりに

明日からDB設計とかやりましょうかね。

ではがんばりましょう

実務初めて3ヶ月の振り返り

はじめに

みなさん、こんにちは torihaziです

今日は実務が始まって3ヶ月が経とうとしているので

いつも通り振り返りをしていこうと思います。

言語化していくことで、自分の進歩を実感できるとともに

理想としている姿との差異の可視化ができると思っているので色々棚卸していこうと思います

フォーマットは特に決まっていません。固定化すると凝り固まる気がするので。

思いついたことをそれなりにまとめて書いていこうと思います。

感想

やり切ったというのと少し報われたというのが感想です。

やり切ったというのはアプリの仮リリースまで走りきれたということです。

私のチームはアプリリリースを来週までに、来週までに、来週・・・とかれこれリリースするする詐欺を繰り返していました。

しかし10月初めくらいに「そろそろ仮リリースしよう!」となり、こりゃ大変だと思っていたらなぜか自分が仮リリース隊長に選ばれました笑

せっかくもらった仕事だったし、PMみたいなものだったし、なんとしてでも結果を残さなきゃと思ってもいたので

土日返上でガリガリコードを書きまくって、PRしてmergeしてPRしてmergeしてを繰り返し、

なんとか宣言した期限までに仮リリースをすることができました。

もちろん自分1人で全部はできませんでした。

Githubのカンバンボードに現状の修正箇所をバリバリあげまくったり、それをいろんな人に振り分けたり

これは自分も多分無理そうってなったら「ヘルプです!助けて!」を上の人に秒で投げたり、

上手く周りを巻き込めたのではないかと思います。

コミュ力という一言で括りたくないので少し言葉を変えるならば「とにかく人を巻き込む」という能力はエンジニアにとって必要不可欠だと思いました。

プライドも良い意味でなくてよかったと思います。

「全部1人でやってやるんだ」というのは多分無理だったと思うし、やらなくて良かったと思います。

あと良かった点としたら2つくらいでしょうか。

1つ目はタスクをカンバンボードに書き出す際に詳細度をできるだけあげて書き出したことです。

見た人がその問題を読むあるいは添付画像を見るだけで問題を理解でき、実現すべきゴールをイメージしやすくできるように工夫しました

リモートで働くメンバーもいるので、テキストのコミュニケーションがとても重要です。

質問がチャットで来たとしてもいつも迅速に返信できるとは限らないし、その質問をしてからの時間が全体の遅れにも繋がります。

こうしたことが起きないよう可能な限りタスクの記載には十分気をつけました。

2つ目はPRのmergeを可能な限り早くすることです。

PRが積み上がると、コンフリクトが起こる可能性が高まります。

またPushしたいけど以前出したPRがなかなかmergeされずに次の作業に移行できないことも。

それだけはなんとしてでも避けなければなりませんでした。

そのため私はレビュアーに指定された時はなる早で見てmergeをするように心がけました。

ただ後にPRの開発体験周りが向上したのでこの点についてはそこまで意識しなくても良くなりました。

以上がやり切ったの感想です。

次の報われたというのが、月報酬が5万上がったということです。

あまりお金関係のことは話すと気を悪くする人もいると思うので、スルーしたい方は読み飛ばしてください。

別にふんぞり返って自慢したいというわけではありません。

ただ本当に嬉しかった、というだけです。

仮リリースをし切ったというのも評価されたのかもしれません。

前職では3年かけて1~2万とかしか上がらなかったので、純粋に嬉しかったです。

昇給ペースで行ったら、数十倍です。2ヶ月少しの実務で5万。

初めてなんです。月の給料で振り込まれる額が20超えるの。

3ヶ月なかなか早いペースでやり切ってきて良かったと思います。

目標の年収1000万まではまだ遠いですが、小さな目標を立てて必ず実現させてみせます。

ということで以上、感想でした

技術的に身についたこと

ブログもかなり書いたし、実務で知ることも増えたし、語彙力が酷いですけど色々できるようになったと思います。

今年の最初はRailsもまともに知らなかったのに、今ではRailsとNext.jsの企業様でフリーランスしてるので。

どういうことを知れたかというと、、、実務と自分の勉強で知れたことを棚おろすと

backendは

  • Railsのシリアライザは albaというのがめっちゃ使いやすい
  • devise-jwtは設定がだるい
  • ActiveStorageはBlobだけUserとかにAttachしないで先に作成してuploadすることもできる
  • render json: とかできる
  • rails g のコマンドは自作できる
  • routingはmemberとかcollectionsとかある
  • Railsにおいて非同期処理を扱うなら RedisとSidekiqかshoryukenとSQSか
  • モデルのidでuuidを使うならmigrationファイルで拡張機能使うと宣言必要(Postgresql)
  • t.references :userだけでuser_idとindexを貼ってくれる
  • 外部キー制約をつける方法は t.uuid :user_idとadd_foreign_keyを使うかt.referencesを使うかの2通り
  • indexを消したいなら外部キーを先に消す必要あり
  • もしindexを貼りたいならindexを貼ってから外部キーを貼ること。

frontendは

  • axiosにおいてinterceptorを使うと全部のリクエストの前後、レスポンスを受ける前後に記述した処理を挟み込める
  • スネークケースにしたりキャメルケースにしたりするならaxiosのinterceptorでreduce使ってやるといい
  • swrはkeyを依存配列のように指定でき、そこが変更されると勝手に再取得してくれる
  • ページネーションは現在のページ、1ページあたりの表示数、合計、useStateのset関数を取得すればできる
  • mutateは再取得を命令する
  • 画像をuploadするならFormDataを使う
  • 画像をpreviewするならURL.createObjectURL(file)をimgのsrcに。
  • react-hook-formで手動でバリデーション走らせるならtrigger。
  • ボタンを押したらinputのファイルが開く機能を自作するならinpuにrefは必須。
  • Promiseで指定する型は戻り値の型。
  • zodのmergeとextendの使い分けは既存のschemaを使い回すか否か
  • prismaはコマンド2つでbackendのDBからスキーマを読み取りzodに反映できる

とかでしょうか。

色々Qiitaとかの記事も書いてみたのでかなり良かったのではないでしょうか。

最速で最適な道を行っている気はしませんが、それでも色々なところにぶつかりながら

なんだかんだ大きくなれていると実感しています。

先月の目標を見てみる

読み直してみると、副業をしたい、と書いていました。

確かに副業の申し込みは5社ほどしてみました。

結果は全敗でした。

経験年数不足が主な原因だと思います。

やはり現実は甘くありませんでした。

1社だけ面接をしていただけるところがありまして、

そこのCTOの方とお話をしてみたのですが色々と優しくされど厳しいお言葉をいただきました。

ただとても次進むべき道が見えた気がしたので、結果的には残念でしたが落ちて良かったと思うし今では感謝しています。

数年後の目標から逆算して今すべき行動を行うべし、みたいなことがその面談で心に留まったことですね。

なので1年後の目標をここで立ててみましょう。

そうですね、何が良いでしょう。

やはり今の会社のシステム全てを最悪1人でも回せるくらいのレベルに到達する、という目標がしっくりきます。

FronendとBackend + インフラの比率はまずはBackendの方に重きを置きたいですね。

やっぱり3ヶ月やってみてそっちの方が楽しいというかかっこよさを感じました。

とある人に追いつくという目標も掲げても良いですね。

なので、目標としてはその2つですね。

1人で回せる、追いつく、ということです。

そのためにはどうするか。もっとRailsであったりインフラに触れる必要がありますね。

詰まったら先駆者に教えを乞うことにします。

終わりに

ということで月の振り返り終了です

今年も残すところあと2ヶ月。

今年は人生が大きく変わった年であるので、このままぐいんと舵を切って

飛躍の年にしていきたいです

それでは、また来月。