差別的、排除的な単語の言い換え。よく使われる「dummy」が差別的用語というのは知らなかったです。

- [Inclusive Naming Initiative](https://inclusivenaming.org/)
- [GoogleのWrite inclusive documentation](https://developers.google.com/style/inclusive-documentation)
- [Airbnbのinclusionドキュメント](https://github.com/airbnb/inclusion)
- [UNREAL ENGINE 5 コーディング規約インクルーシブな言葉の選択](https://docs.unrealengine.com/5.0/ja/epic-cplusplus-coding-standard-for-unreal-engine/#%E3%82%A4%E3%83%B3%E3%82%AF%E3%83%AB%E3%83%BC%E3%82%B7%E3%83%96%E3%81%AA%E8%A8%80%E8%91%89%E3%81%AE%E9%81%B8%E6%8A%9E)

Inclusive documentation

# AWSコスト削減

- EC2
    - opswitch
        - [opswitch を使って AWS 開発環境のコストを半分にした](https://blog.yuu26.com/opswitch/)
- RDS
    - opswitch（EC2と同様）
    - ストレージサイズはあとから小さくできないので、最初は小さめで作る
- ECS
    - EventBridgeで起動、停止
        - [Amazon EventBridge SchedulerでECS Fargateのタスクを定期起動・定期停止してみた](https://dev.classmethod.jp/articles/amazon-eventbridge-scheduler-ecs-stop-start/)
- ECR
    - ライフサイクルポリシーの設定
        - [Amazon ECRに無駄なコストがかかっていた](https://speakerdeck.com/iwamot/reduced-amazon-ecr-costs-b5f35a27-8378-4a93-b430-c34b3fd83a4c)

# フロント

- [私の推しフロントエンドディレクトリ構成と気をつけたいポイント](https://zenn.dev/sakito/articles/af87061a5016e6)
- [私のフロントエンドディレクトリ構成・テスト観点 2022](https://zenn.dev/takepepe/articles/nextjs-testing-strategy-2022)
- [“Tao of Node - Design, Architecture & Best Practices” 日本語翻訳](https://jqk.life/tao-of-node-japanese)

# 仕事全般

- [リモートワークのための質問力向上研修を実施しました](https://tech.classi.jp/entry/2021/12/07/120000)
- [BeProudコミュニケーションガイド (HTML版)](https://github.com/beproud/beproud-guide#%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%AC%E3%82%A4%E3%83%89)
- [セルフマネジメントで自由に働くまでの５段階ロードマップ 〜 自己管理だけではない](https://kuranuki.sonicgarden.jp/2022/03/self-management-roadmap.html)
- [roadmap.sh](https://roadmap.sh/)
- [「無人化システム」を駆逐する組織マネジメントとエンジニアリング](https://zenn.dev/tmknom/articles/93f227ad5e55aa)

# セキュリティ


- [雑な攻撃からELBを守る一工夫 ＋おまけ](https://speakerdeck.com/hiroga/know-how-to-protect-servers-from-miscellaneous-attacks)
- [Railsのセキュリティベストプラクティス](https://techracho.bpsinc.jp/hachi8833/2022_10_11/122536#2-3)

# デザイン

- [quocca works demo](https://quocca-works.com/demo/)(レスポンシブの挙動を確認できるサイト)

# 個人開発

- [個人開発のサービスをVPSからVercelとCloud Runに移行した話](https://zenn.dev/hokaccha/articles/81d0545c1517f1)

# テストコード

- [テストコード(RSpec)の高速化事例](https://tech.unifa-e.com/entry/2017/01/25/105653)
- [フロントエンドのテストコードを書くときに大切にしていること](https://blog.cybozu.io/entry/2022/11/14/120000)

# その他

- [jsでのディープコピーstructuredClone](https://developer.mozilla.org/en-US/docs/Web/API/structuredClone)
- [VSCode Remote Containerが良い](https://qiita.com/d0ne1s/items/d2649801c6f804019db7)
- [tailwindcssの公式プラグイン4つをそれぞれ使ってみた](https://dev.classmethod.jp/articles/tailwind-official-plugins/)
- [Railsルーティングのconstraintsオプション](https://railsguides.jp/routing.html#%E3%82%BB%E3%82%B0%E3%83%A1%E3%83%B3%E3%83%88%E3%82%92%E5%88%B6%E9%99%90%E3%81%99%E3%82%8B)
- [知っておきたいWebエンジニアリング各分野の基礎知見80](https://zenn.dev/rio_dev/articles/c0da74ae28bdcd)
- [mysql force index](https://man.plustar.jp/mysql/index-hints.html)
- [【React】1度だけ変更されるstateにはuseStateよりuseReducerを使う方が最適](https://zenn.dev/spacemarket/articles/9eb80496fa5fe6)
- [Next.js 製 Web フロントエンドの CI ビルド時間を 1/3 にした話](https://blog.studysapuri.jp/entry/beyond-the-lightning)
- [既存サービスに Hotwire を部分導入して得られた知見](https://note.com/everyleaf/n/n5c0f123b20a6)
- [\[AWS\]AWSアカウント取得後にやるべき9つの設定](https://zenn.dev/pageo/articles/32223dbc7dfb70)

2022年11月のブックマーク

wip　後で同じことを考え直さないようにメモ。
# クラス定義

* SDKが用意されている場合
  * やりたいことが単純なら、継承したクラスまたはinitializerで認証用の値を渡すのみ
  * 用途を限定したい場合や自サービスのモデルを加工して渡したい場合など、使用に制限をかけたい場合はインスタンス変数でクライアントを持つ
* 独自にクライアントクラスを作る場合
  * 各メソッドにリファレンスへのurlを張る

# テスト

* テストコードでAPIが使われないように、モック、スタブを使う
```
client = instance_double(Class)
allow(client).to receive(:hoge).and_return({"data": "aaa"})
allow(SdkClient).to receive(new).and_return(client)
```

外部APIを使うときに気をつけていること

抜け漏れ防止として書く。思いついたら加筆。
# migration

- null制約の有無
- unique制約の有無
- indexの有無、複数インデックスであれば張る順番

# Model

- validateをつける
- 既存のモデルと関連があるとき、既存のモデルの方でassociationを指定する
- dependentオプションを指定する
- 必要があればbelongs_toをoptionalにする

# テストコード

- FactoryBotで、uniqueの値にはsequenceを使う

# その他メモ

* （いつも忘れるのでメモ）別名をつけるときはforeign_key: { to_table: :hoge }

新しくモデルを作成するときに気をつけていること

普段通りこう書いていたら、rubocopでRails/BulkChangeTableの警告が出た。

```
class CreateUsers < ActiveRecord::Migration[7.0]
  def change
    create_table :users do |t|
      t.string :uid, null: false
      t.string :email, null: false

      t.timestamps
    end
    add_index :users, :uid, unique: true
    add_index :users, :email, unique: true
  end
end
```

bulkのオプションも、t.indexでインデックスを張れるのも知らなかった…
```
class CreateUsers < ActiveRecord::Migration[7.0]
  def change
    create_table :users, bulk: true do |t|
      t.string :uid, null: false
      t.index :uid, unique: true
      t.string :email, null: false
      t.index :email, unique: true

      t.timestamps
    end
  end
end
```

create_tableと同時にindexを貼る

- [DevelopersIO](https://dev.classmethod.jp)
- [TechRachoのRails記事](https://techracho.bpsinc.jp/category/ruby-rails-related)

インプットまとめ

# 背景

- 今まで.rubocop.ymlの参考になる記事が見つからず、自作していた
  - 今思うと「ruby スタイルガイド」で検索かけたら良かった
- [こちらの記事](https://techracho.bpsinc.jp/hachi8833/2022_07_12/119649#3-3)でShopifyのRubyスタイルガイドが有名でだと知った
- .rubocop.ymlも公開されていたので、早速使ってみた

# 導入方法

[公式](https://ruby-style-guide.shopify.dev/#adoption-with-rubocop)の通り

# 所感

自分のリポジトリで`rubocop —auto-correct`して、特に差分が出たところをピックアップした。

## ダブルクォーテーションVSシングルクォーテーション

Shopifyはダブルクォーテーションで統一。個人的には使い分けるのが好みだが、せっかくなので今後はダブルクォーテーションで統一してみる。

ネットで検索かけると、「USキーボードだとシングルクォーテーションの方が入力が楽」という意見があって、自分もこの影響が大きかったかもと思った。

## %記法

Shopifyは%記法を使わないようにしている。自分も使わないほうが見やすいと思うので、Shopifyに合わせる。

# 最終的な.rubocop.yml

Shopifyではメソッドのカッコ省略をしないようにしているが、migration、jbuilder、specのファイルにはそのルールが適さないので、Excludeしている。

```yaml
require: rubocop-rails
inherit_gem:
  rubocop-shopify: rubocop.yml
Style/FrozenStringLiteralComment:
  Enabled: false
Style/MethodCallWithArgsParentheses:
  Enabled: true
  Exclude:
  - "spec/**/*"
  - "db/migrate/*"
  - "**/*.jbuilder"
```

ShopifyのRubyスタイルガイドを適用した

# 前提

バックエンドはRailsで作っている

# 目的

* rails consoleによるメモ投稿から脱却

# できたもの

* ログイン機能
  * devise
* メモ管理機能
  * [編集画面にはsimple mdeを適用](https://github.com/sparksuite/simplemde-markdown-editor)
  * クラスレスCSSの[new.css](https://newcss.net/)を利用
* メモの内容のツイート機能

# 参考リンク

* [バックエンド Web API に管理画面/管理機能を追加するアーキテクチャパターン](https://ohbarye.hatenablog.jp/entry/2021/01/22/admin-feature-architecture-patterns)
  * これでいうとパターン1

CMSの管理画面を作った

前の転職時に感じた課題を解決するために、個人でCMS作成プロジェクトをやってみます。

# 課題

- 現状のエンジニアとしてのスキルを表現するのに、最終的なソースコードを見せるだけでは表現しきれないことがある
    - 実際の業務で気にかけている「機能をどう分けて開発するか」などを見せられない
- どのようなドキュメントを書くのか表現したいが、ローコンテキストなドキュメントを沢山書くのは難しい
    - 実際の業務では、ある程度のコンテキストを共有した上でのドキュメントを書くことが多い
- プロジェクト管理など、エンジニアリング以外のソフトスキルについて表現できない

# アプローチ

- チーム開発っぽくgithubを運用する
    - （今までは適当にmainブランチにプッシュしたり、デプロイもそんなに自動化してなかった）
- 「CMS作成」というテーマに絞ってドキュメントを書いていく
- Notionでプロジェクト管理する

記事一覧