世界一適当な技術ブログ

日々学んだ内容をとにかくにブログ形式でアウトプットします。(技術系中心)基本自分用備忘録です。

ESLintとPrettierの違いについて

ESLintとPrettierの違いについて

ESLintとPrettierはどちらもソースコードの品質を高めるツールになります。

ESLint

  • JavaScriptのための静的検証ツール
  • ファイル内のバグチェックやコーディングスタイルの一貫性を保つ

例)

  • letを使っているが再代入していないので、constを使うべき
  • (TypeScriptの場合)関数の返り値の型が未定義である
  • 宣言されているが、使っていない変数がある
  • 未定義の変数やモジュールを使用している

Prettier

  • コードフォーマッター
  • ルールに従ってソースコードを整形してくれる
  • プロジェクトごとにルールを設定する

ESLintとPrettierの違い

ESLintとPrettierは併用されているケースが多い。

理由はできることが重複する部分があるが、それぞれ得意分野が違うのでそれぞれその分野を担当させようというケースが多いからである。

例)得意分野

ESLint:静的解析ツール。バグの可能性がある書き方を指摘する。

Prettier:コードフォーマッター。インデント、改行などを自動整形してくれる。

Rails設計パターン

Rails設計パターン

Railsの設計パターンについて、殴り描きします

MVCパターン

RailsTutorialから入った自分には一番馴染みの設計パターン

ルーティング(Routes)→コントローラー(Controller)→モデル(Model)→ビュー(View)の順番で処理がなされる

画像参考:【Rails】 MVCフレームワークを初心者向けに丁寧に解説! | Pikawaka

コントローラー設計の時に考えるべきポイント

1. 薄いコントローラーを意識する

コントローラの役割はユーザーのリクエストが不正でないかのチェックとレスポンスコードを返すです。 コントローラーにロジックをゴリゴリ入れるのはNG。薄いコントローラーである程よい。

例)コントローラーにロジックを入れすぎなサンプル

def index
  @published_posts = Post.where('published_at <= ?', Time.now)
  @unpublished_posts = Post.where('published_at IS NULL OR published_at > ?', Time.now)
end

次のように変更した方がベターです

def index
  @published_posts = Post.published
  @unpublished_posts = Post.unpublished
end

モデルにロジックを書き写します

scope :published, ->(timestamp = Time.now) { where('published_at <= ?', timestamp) }
scope :unpublished, ->(timestamp = Time.now) { where('published_at IS NULL OR published_at > ?', timestamp) }

2. RESTなコントローラーを意識する

:index, :show, :new, :create, :edit, :update, :destroyといった基本的なaction以外はできる限り利用しない方がベターです。 RestfuleなWEBアプリを意識しましょう

モデル設計の時に考えるべきポイント

1. データベースへの格納方法は、Modelに隠ぺいする

モデルクラスには、データベースを取り扱う(データベースへの格納方法は、Modelに隠ぺいする)という役割。 その役割から逸脱しないようにプログラムを書きましょう。

MVCアンチパターン

MVCにそれぞれ責務が存在します。

レイヤ MVC
ユーザインタフェース View
アプリケーション層 Controller
ドメイン Model

ユーザインタフェース層: ユーザに情報を表示し、ユーザの入力を解釈する。
アプリケーション層:ドメイン層のオブジェクトを協調させる。ビジネスに関する知識を持たず、作業を調整するだけ。
ドメイン層: わゆるビジネスロジックを表現する。一番重要な層。

上記のような責務に綺麗に分けてコード書くのがベストなのですが、多くのフレームワークがそのように分離することに強い制約を持っているわけではないのでアンチパターンなコードになってしまうケースがあります。

例)Fat View

例)Fat Controller

  • MVCアーキテクチャでWebアプリケーションを書くと誰もが最初に陥る
  • ドメイン層のロジックがアプリケーション層に書かれている状態で、一つの変更をするのに複数箇所変更しないといけなくなっていたりする

例)Fat Model

  • なんでもかんでもModelに詰め込んでいる状態
  • アプリケーション層のロジックまでModelに含まれていることも多い

Railsアプリケーションが巨大化した時の対象方法

プロダクトが肥大化してきて、MVCではコードの管理がキツくなってきた時の対処方法を記載します。

こちらの記事が非常にわかりやすかったです。

中/大規模開発のためのRails設計パターン - Qiita

お手軽な第一歩としてはserviceレイヤーを導入するのが、一番簡単な対象方法

RailsにService層を導入 - Qiita

参考

肥大化したActiveRecordモデルをリファクタリングする7つの方法(翻訳)|TechRacho by BPS株式会社

Railsのアーキテクチャについて考えるための読み物まとめ - Qiita

実務で学んだRailsの設計・リファクタリング | wawoon

オブジェクト指向設計ガイド(Ruby)の内容をわかりやすくまとめてみた2020年 - Qiita

中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita

Railsアプリケーションのパフォーマンス・チューニング

railsActiveRecordって便利だけど、実際にどんなクエリが吐かれるかチェックしてないとパフォーマンスすぐに落ちるケース多い。

遅いAPIをどのようにして発見するか?

■ 1.APM(Application Monitoring Management)を導入する

おすすめはこの辺り

- NewRelic
- DATADOG

■ 2. APM(Application Monitoring Management)を利用しパフォーマンスの悪いAPIを探す

APMツールを利用すると、どのエンドポイントが遅いか可視化できるので当たりをつけてボトルネックを探す。

クエリの発行を調査するときはExplainを使うとクエリ詳細情報が出るので良い。

どのように改善するか?

■ アプリケーションレベルでの対策

1. キャッシュを使う。
2. データベース操作回数を減らす。1テーブル1回を目指す。
3. データベースから取得するレコードとカラムを最小限にする。
4. データベースのインデックスの張り方を工夫する。インデックスが使えるようなクエリにする。
5. マルチスレッドで処理する。
6. 高速なライブラリを導入する。
7. HTML作成(の一部)をJavaScriptに任せる。
8. Ajaxでレスポンスを返し、ページの一部分の更新のみで済ませる。

■ インフラレベルでの対策

1. ミドルウェアのバージョンを最新のものに変える
2. 速いサーバーに乗り換える
3. サーバーの数を増やす
4.ネットワークを高速なものに変える

参考

パフォーマンス・チューニング Rails編 | Money Forward Engineers' Blog

Rails パフォーマンス・チューニング入門 / 黒曜 - YouTube

APIを設計するときに気を付けていること

APIを設計するときに気を付けていること

RestAPI設計をするときに気をつけていることを殴り書きします

ちなみにAPI設計を綺麗に設計することにより下記のようなメリットがあります。

1. 使いやすい
2. 保守運用が容易
3. セキュリティリスクが下げることができる

WEB APIを美しく設計する重要性 - 世界一適当な技術ブログ

RESTの設計原則

RESTの設計原理をまずまとめます。 設計原理を知らないとそもそも良い設計とは何かが理解できないです。

1. ステートレス(Stateless)

RESTではサーバ側で状態の管理を行わないのが基本です。 RESTで情報を持ちたい場合はクッキーとセッションを利用する

Cookieとセッションをまとめてみた。 - Qiita

2. 統一インターフェース(Uniform Interface)

RESTではリソースの処理をCRUD(GET/POST/PUT/DELETE)で処理する

API設計ステップ

  1. 対象となるデータを認識する
  2. 対象となるデータをリソースに分ける
  3. リソースにURLで名前を付ける
  4. リソースに対してGET/POST/PUT/DELETEをマッピングする
  5. クライアントから受信する表現を設計する
  6. クライアントに提供する表現を設計する
  7. ハイパーメディアリングとフォームを使用して、既存のリソースと統合する(接続性を高める)
  8. 正常系を考える
  9. 例外条件を考える

API設計する上で気をつけること

1. 綺麗なURI(ルーティング)を作る

綺麗なURI(ルーティング)を作るときのTIPS - 世界一適当な技術ブログ

2.RESTful な URL にする

REST のキーとなる概念は、論理的に分割されたリソースを HTTP メソッド(GET, POST, PUT, PATCH, DELETE)で操作する、ということです。

GET /tickets - チケットのリストを取得する
GET /tickets/12 - 指定したチケットの情報を取得する
POST /tickets - 新しいチケットを作成する
PUT /tickets/12 - チケット #12 を更新する
PATCH /tickets/12 - チケット #12 を部分的に更新する
DELETE /tickets/12 - チケット #12 を削除する

3.バージョンはURLに含めれる

バージョン管理をすることで、メジャーアップデートがあるような場合は移行期間として過去バージョンと共存させるなど、滑らかな改修作業が可能になります。

4. フィルタ・ソート・検索はリクエストパラメータで対応する

ベースとなる URL はできるだけシンプルにしておくのが良いです。

フィルタやソート、検索といった機能はリクエストパラメータで制御するのが良い(もっとも、これは単一リソースに絞るが)

1.フィルタリング

例)公開中のチケットのみを取得する

GET /tickets?state=open

2.ソート

例) チケットのリストを priority の降順で取得する

GET /tickets?sort=-priority

3.検索

例)最近クローズされたチケットを取得する

GET /tickets?state=closed&sort=-updated_at

参考

翻訳: WebAPI 設計のベストプラクティス - Qiita

RailsでREST API設計するときに知っておきたい集 - Qiita

特定のブランチのファイルを現在の作業ブランチにマージする方法

特定のブランチのファイルを現在の作業ブランチにマージする方法

あるブランチのファイルを現在の作業ブランチに移動させたいケースの対応方法を記載

例)materブランチのhoge.textを現在の作業ブランチに移動(コピー)させる

git checkout origin/master app/views/hoge/hoge.text

個人開発のおすすめ無料素材

1. Adobe Stock

Adobe Stock(アドビ ストック)は、商用利用可能な1億点を超える素材(写真、イラスト、ベクター画像)を提供するストックフォトサービスです。

商用利用も可能です。

使い方はこちらを参考にできます。

公式サイト:Adobe Stock 無料コレクション : 写真、ベクター、ビデオ | Adobe Stock

Railsのメリット、デメリット

メリット

■ 開発速度が速い

RaislはRubyを使ったフルスタックWEBフレームワーク(DBを扱うActiveRecordが優秀、、メールを送る仕組みがデフォルトである、ジョブを実行できる)で、Rails Wayな書き方をすることで開発スピードを上げることが出来る。

Rails Wayについてはこちらの記事が参考になる Only My Rails Way

フルスタックフレームワーク RaulsはフルスタックフレームワークでWEB開発に必要な機能を大枠全て兼ね備えています。

例) - DBを扱うActiveRecord - メールを送る仕組み - ジョブを実行できる仕組み - ストレージ管理の仕組み

デメリット

ActiveRecordを利用すればSQLを知らないのにSQLが書ける

ActiveRecord(O/Rマッパー)を利用すると、SQLを知らなくてもSQLを書くことができます。

ただ、難しい処理の場合実際に発行されるクエリがわかりにくい、ActiveRecordから逸脱したことをやろうとすると面倒といったデメリットもあります。

■ 実行速度が遅い

スクリプトプログラミング言語Rubyでは、Rubyコマンドが読み込んだプログラムを逐次解析して処理を実行します。 そのためコンピュータで直接実行できるプログラムに変換するコンパイル型に比べると、処理速度が遅いです。

結論、Railsは利用すべき?

結論はAPIモードとしてRailsを利用するケースが一番良い。

Railsフルスタックフレームワークなので、もちろんViewを持っていてHTML出力も可能ですがフロントフレームワーク(Vue.js, React)と相性が良くない。

なので、フロントとバックエンドは完全に分けて利用するのがよい。

どんな企業がRailsを採用すべき?

Railsの最大のメリットは、開発スピードが速く高速でPDCAを回すことが可能なことです。

そう言った特徴を考えると、スタートアップ企業にとっては一番良いフレームワークなのかなと考えます。

参考