eityansメモ

eityansメモ

ゆるくやっていきます

記事一覧

Railsのincludesとjoinsの本質的な違い

処理の範囲が違う

  • includes は先読みを行いキャッシュする → Railsのメモリに影響する（しない場合もある）

  • joins は INNER JOIN する → データベース内だけの話

関連先のデータを使いたいときはincludesを使うが、関連先の条件で絞り込みたい場合はjoinsを使う。メモリのこととか、速度のこととか、ここから考えていけばある程度応用が効く。

例：ユーザーのいいねした順でBookを取得したい

joinsを使う方がスマート

1user.books.joins(:likes).all.order('likes.created_at DESC').to_sql
2=> "SELECT \"books\".* FROM \"books\" INNER JOIN \"likes\" ON \"likes\".\"book_id\" = \"books\".\"id\" WHERE \"books\".\"user_id\" = 5 ORDER BY likes.created_at DESC"

Contentfulで定義したレスポンスをTypeScriptで使う

このブログはHeadless CMSであるContentfulで記事を作成し、Next.jsでデータを取得して表示しています。

今まで型定義を自前で用意していたのですが、自動で生成するライブラリを使うことにしました。

cf-content-types-generatorを試してみます。

contentful-typescript-codegenを使う方法を最初試していたのですが、メンテナンスがあまり活発でないことと、Contentfulのv10のアップデートに失敗してしまうことがわかりました。これから対応する方は注意してください。

型情報を含んだjsonを読み込んでTypeScriptの型を作るので、まずはそのjsonを作る準備をします。contentful-cliを使います。

1npm install -D contentful-cli

jsonを作るスクリプトをpackage.jsonに追加します。export-confing.jsonを別で作り、そこに設定値を入れます。この設定値には公開したくないアクセストークンをいれるので、gitignoreに入れてコミットしないようにします。

ちなみにｍanagementTokenはCMA tokensからPATを作成することで取得しました。

1{
2  // ...
3  "scripts": {
4    "contentful-export": "contentful space export --config export-config.json"
5  }
6}
7
1{
2  "spaceId": "XXXX",
3  "managementToken": "CFPAT-XXXX",
4  "contentFile": "contentful-export.json",
5  "skipContent": true,
6  "skipRoles": true,
7  "skipWebhooks": true,
8  "skipTags": true
9}

npm run contentful-exportを実行することで、型データのjson（contentful-export.json）が作られました。

次にこの型データjsonからTypeScriptの型を作ります。cf-content-types-generatorパッケージをインストールします。

1npm install -D cf-content-types-generator

package.jsonに以下のスクリプトを追加します

1{
2  // ...
3  "scripts": {
4    "contentful-generate-types": "cf-content-types-generator contentful-export.json -o ./@types --v10 --response"
5  }
6}

スクリプトを実行することで型が生成されます

1npm run contentful-generate-types

これで型が生成されました。これで安全に開発ができます。

eityans.comドメインを取得してみた

X(Twitter)もGitHubも全てeityansで統一しているし、せっかくなのでドメインも取得してみました。

Cloudflareで取得。年10$ほどで、それぐらいなら良いかなと思いました。

電車移動中にふと欲しくなったのでその場で取得。帰宅してからこのブログに設定しました。

このブログはVercelにホスティングしており、設定画面のドメインからポチポチするだけで反映されました。便利。

具体的に設定したこと

Cloudflare側

Vercel側

  • ドメインの追加

    • Settings→Domains→Addから今回取得したドメインを追加しました

    • Cloudflareにリダイレクトされ、良い感じに連携してくれました

    • 反映されるまで数分かかりました。

  • 元のドメインのリダイレクト設定

    • 「blog-eityans.vercel.app」というドメインが割り振られているので、これをeityans.comにリダイレクトさせる設定をしました。

テキストコミュニケーションのデメリットは本当にデメリットなのか

完全リモートの会社に転職して１年半近く経つ。

やり取りは全てSlack。文字だけのコミュニケーションで、会議と言えるものは朝会で一日5分程度。あと面接ぐらいか。同棲していなかったら一言も話さないこともありそう。

仕事を進めるうえで調整しなければならないことが発生したときも全てSlack。突発な会議や打ち合わせは行ったこと無い。それで仕事が進むのかと思う人もいるかも知れないが、案外進むものだ。

かなり極端な会社にいると思う。自分なりにテキストコミュニケーションだけで仕事を進めるメリットとデメリットを考えてみる

メリット

  • 仕事を邪魔されない

    • こういう言い方をすると新しく入ってきた人などがコミュニケーションを取りにくくなりそうだが、ここではシンプルにこう言い切る。同期的なコミュニケーションは要求する側にはメリットがあるが要求される側にはあまりメリットがないのだ。

    • 逆に、質問する側からすると仕事を邪魔する気後れみたいなものが無いのも良い。

  • 透明性

    • 誰が何に困っているのかがわかるし、誰がそれに対応しているのかもわかる。評価をする面でそれらがわかるのは良い。

  • 後世に残る

    • 文字に残ることで他の人に知見がいきわたる。

  • 考えが整理される

    • 瞬発的な会話を要求されないため、じっくり検討することができる。やり取りの濃度が上がる

  • 自己解決することがある

    • 考えが整理され、結果として自己解決することもある。

デメリット

  • 考えをテキストに起こすのに時間がかかる

    • これは慣れの問題もありそう。ただ、何に時間がかかるのかといえば考えを整理するところが大部分だと思うので、かつそれをあらかじめ整理するのは同期的だろうが非同期だろうがすることではないだろうか。

  • リードタイムがかかる

    • 性質上しょうがない。それを踏まえて各自が行動するのが望ましい。確認することは早めに確認し、回答を待つ間に別の作業を行うなど。

    • 回答する側は、ひとまず目は通しましたということや、今は回答できないことだけでもすぐに伝えたほうが良い。それだけで質問側のフラストレーションがかなり下がる。

  • 考えをテキストにまとめるのが苦手な人がいる

    • 国語の能力だったり、論理的思考力の話になる。得意不得意があるものだが、繰り返し練習すれば伸びるもの。重ねて言うが、得意不得意がある部分なので、苦手な人を努力不足と安直に判断するのは控えたほうが良い。

  • テキストでのコミュニケーション自体が苦手な人がいる

    • テキストはそっけなく見えてしまいがちで、その影響を忘れがち。

    • ある程度は慣れてもらうしか無い気がするが、そういう人もいるのは念頭においておきたい。

デメリットを小さくするために

メリットとデメリットを見ると、メリットは組織やチームに関係し、デメリットは個人に関係していることに気付く。であるならば、個人の改善が大いに効果を発揮するだろう。以下を意識する。

  • 質問を受けたらすぐに反応する

    • これは回答を含まなくても良い。あとで回答することを伝えるだけでも良い。

  • 絵文字や「！」をつける

    • おじさん構文になっても良い気がする。無機質な感じを減らせる。

前のページページ 6 / 13次のページ