Webviewまとめ
Webviewまとめ
■ Webviewとは
HTMLコンテンツを、アプリ(スマホ)内で表示できるようにするもの。
Webページは主にHTML という言語で作成されており、アプリ内でHTML を解析し、Webページのように表示することを可能にします。
■ Webviewのメリットは？
コスト面の削減ができる。
例えば既にWEB上にコンテンツがある場合はそれを流用してスマホアプリ開発すれば新規でプログラムすることなくアプリ上で同じコンテンツが表示できます。
■ ネイティブとの違いは？
ネイティブの方がサクサク・快適・スムーズな操作感を実現できます。
方ネイティブアプリでは、アプリ内にある程度のパーツを持っているので、画面遷移時の通信量を抑えることができ、よりなめらかで、サクサクした操作感を実現できます。また「画像が『ふわっと』表示される」というようなアニメーションもネイティブアプリならより自由に表現可能です。
ですのでユーザー体験にこだわるのであればネイティブで実装する方が良いです。
■ まとめ
Webviewは低予算で作成可能ですが、利用できる機能に制限がある
ネイティブは予算が高いが、利用できる範囲が広い
コスト重視 → Webview UX重視 → ネイティブ
ちなみにWebviewはあくまで機能の一種であるため、ネイティブアプリに組み込むことができます。ネイティブアプリとWebviewを組み合わせたアプリは「ハイブリッドアプリ」と呼ばれます。
参考
クラス/インスタンスメソッドの使い分け方法
クラス/インスタンスメソッドの使い分け方法
railsのモデルファイルを書いていて間違えやすいのが、クラス/インスタンスメソッドの使い分けです。
先に結論
データすべて(モデルそのもの)に対する操作はクラスメソッド。特定のデータに対する操作はインスタンスメソッド
例）Personモデルを定義したと仮定した場合
class Person # クラスメソッド def self.exists_no_name_person? no_name_person_list = Person.where(name: nil) no_name_person_list.exits? end # インスタンスメソッド def full_name self.first_name + self.last_name end end # exists_no_name_person?クラスメソッドは全てのPersonデータに対しての処理なのでクラスメソッドになる Person.exists_no_name_person? # full_nameインスタンスメソッドは特定のpersonにな対しての処理なのでインスタンスメソッドになる tanaka = Person.new(name: 'tanaka') tanaka.full_name
参考：
必要なModelファイルを作成する|RailsとReactでUberEats風SPAアプリケーションをつくってみよう！|Techpit
rails newでgit 管理外れる場合の対象方法
rails new git 管理外れる場合の対象方法
rails newで作成したアプリケーションのディレクトリに移行してみると、git initのコマンドを打ち込んでいないのにも関わらずgitの管理が始まってします。
このときの対処方法を記載する
例）こんな現象
[/Users/user_name]$ rails new testapp [/Users/user_name]$ cd testapp [/Users/user_name/testapp](master)$
対策方法
単純にgitの管理を破棄したいなら対象ディレクトリ内の.gitディレクトリを削除すればいいです。
cd sample-app
- ls -laで.git」というディレクトリを確認
$ ls -la total 56 drwxr-xr-x 21 inouehiroki staff 672 5 28 20:20 . drwxr-xr-x 6 inouehiroki staff 192 5 28 20:20 .. drwxr-xr-x 9 inouehiroki staff 288 5 28 20:20 .git <==== これ -rw-r--r-- 1 inouehiroki staff 750 5 28 20:20 .gitignore -rw-r--r-- 1 inouehiroki staff 6 5 28 20:20 .ruby-version -rw-r--r-- 1 inouehiroki staff 1427 5 28 20:20 Gemfile -rw-r--r-- 1 inouehiroki staff 3962 5 28 20:20 Gemfile.lock -rw-r--r-- 1 inouehiroki staff 374 5 28 20:20 README.md -rw-r--r-- 1 inouehiroki staff 227 5 28 20:20 Rakefile drwxr-xr-x 8 inouehiroki staff 256 5 28 20:20 app drwxr-xr-x 7 inouehiroki staff 224 5 28 20:20 bin drwxr-xr-x 16 inouehiroki staff 512 5 28 20:20 config -rw-r--r-- 1 inouehiroki staff 130 5 28 20:20 config.ru drwxr-xr-x 3 inouehiroki staff 96 5 28 20:20 db drwxr-xr-x 3 inouehiroki staff 96 5 28 20:20 lib drwxr-xr-x 3 inouehiroki staff 96 5 28 20:20 log drwxr-xr-x 3 inouehiroki staff 96 5 28 20:20 public drwxr-xr-x 3 inouehiroki staff 96 5 28 20:20 storage drwxr-xr-x 9 inouehiroki staff 288 5 28 20:20 test drwxr-xr-x 6 inouehiroki staff 192 5 28 20:20 tmp drwxr-xr-x 3 inouehiroki staff 96 5 28 20:20 vendor
- rm -rfで削除
rm -rf .gitをすればitの管理下から外れます
参考
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
- ユーザインタフェース層にアプリケーションやドメイン層のロジックが詰め込まれた状態
- Viewから直接Modelを触っているとn+1問題が頻出する
例）Fat Controller
例）Fat Model
- なんでもかんでもModelに詰め込んでいる状態
- アプリケーション層のロジックまでModelに含まれていることも多い
Railsアプリケーションが巨大化した時の対象方法
プロダクトが肥大化してきて、MVCではコードの管理がキツくなってきた時の対処方法を記載します。
こちらの記事が非常にわかりやすかったです。
中／大規模開発のためのRails設計パターン - Qiita
お手軽な第一歩としてはserviceレイヤーを導入するのが、一番簡単な対象方法
参考
肥大化したActiveRecordモデルをリファクタリングする7つの方法（翻訳）｜TechRacho by BPS株式会社
Railsのアーキテクチャについて考えるための読み物まとめ - Qiita
実務で学んだRailsの設計・リファクタリング | wawoon
Railsアプリケーションのパフォーマンス・チューニング
railsのActiveRecordって便利だけど、実際にどんなクエリが吐かれるかチェックしてないとパフォーマンスすぐに落ちるケース多い。
遅いAPIをどのようにして発見するか？
■ 1.APM(Application Monitoring Management)を導入する
おすすめはこの辺り
- NewRelic - DATADOG
■ 2. APM(Application Monitoring Management)を利用しパフォーマンスの悪いAPIを探す
APMツールを利用すると、どのエンドポイントが遅いか可視化できるので当たりをつけてボトルネックを探す。
クエリの発行を調査するときはExplainを使うとクエリ詳細情報が出るので良い。
どのように改善するか？
■ アプリケーションレベルでの対策
1. キャッシュを使う。 2. データベース操作回数を減らす。１テーブル１回を目指す。 3. データベースから取得するレコードとカラムを最小限にする。 4. データベースのインデックスの張り方を工夫する。インデックスが使えるようなクエリにする。 5. マルチスレッドで処理する。 6. 高速なライブラリを導入する。 7. HTML作成(の一部)をJavaScriptに任せる。 8. Ajaxでレスポンスを返し、ページの一部分の更新のみで済ませる。
■ インフラレベルでの対策
1. ミドルウェアのバージョンを最新のものに変える 2. 速いサーバーに乗り換える 3. サーバーの数を増やす 4.ネットワークを高速なものに変える
参考
APIを設計するときに気を付けていること
APIを設計するときに気を付けていること
RestAPI設計をするときに気をつけていることを殴り書きします
ちなみにAPI設計を綺麗に設計することにより下記のようなメリットがあります。
1. 使いやすい 2. 保守運用が容易 3. セキュリティリスクが下げることができる
WEB APIを美しく設計する重要性 - 世界一適当な技術ブログ
RESTの設計原則
RESTの設計原理をまずまとめます。 設計原理を知らないとそもそも良い設計とは何かが理解できないです。
1. ステートレス(Stateless)
RESTではサーバ側で状態の管理を行わないのが基本です。 RESTで情報を持ちたい場合はクッキーとセッションを利用する
2. 統一インターフェース(Uniform Interface)
RESTではリソースの処理をCRUD(GET/POST/PUT/DELETE)で処理する
API設計ステップ
- 対象となるデータを認識する
- 対象となるデータをリソースに分ける
- リソースにURLで名前を付ける
- リソースに対してGET/POST/PUT/DELETEをマッピングする
- クライアントから受信する表現を設計する
- クライアントに提供する表現を設計する
- ハイパーメディアリングとフォームを使用して、既存のリソースと統合する(接続性を高める)
- 正常系を考える
- 例外条件を考える
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
