2018-01-23

プロジェクトの立ち上げ時に入れてよかった/入れなくてもよかったgem

f:id:waterlow2013:20181109010853j:plain

はじめに

ここ最近趣味でrailsアプリを複数人で開発しています。
自分以外Railsは初心者 で、rails newしてgemを入れてDB初期設計やってはじめのコントローラ（API）をつくるまで位を自分でやったのですが、その後入れてよかった/入れなくてもよかったと思うgemがあり、多少は他の人や未来の自分にも役立つだろうということで書き留めます。

入れてよかった

onkcop(rubocop)

コーディングスタイルについて揉めたり、議論したりすることがなかった。
自分が設定して満足できた。

bootstrap

本デザインが当たっていないサンプルの状態でも、まあまあいい感じに見せられる。素のHTMLを見ることによるテンションの落ちがない。

gimei

後述するseed-fuでのサンプルデータ作成に役立った。

ridgepole

migrationファイルの記法がほとんど使えるため学習コストが低かった。ちょこちょこスキーマを修正するのにいちいちmigrationを作らなくてよかった。（古いmigrationファイルを直せばいいというのもあるけど、ほんの少し罪悪感がある。）

seed-fu

サンプルデータをはじめに整備しておくことで、いろいろイメージが付きやすかったり、たたき台にできたり。

shrine

本番ではS3を使うのだが、developmentではローカルにファイルを置くとか実装を切り替えれたのが便利。初めてつかったけど carrierwave をちゃんと使ったことがあればある程度は動かせた。他の人を見ていると学習コストは高めだった。

入れなくても良かった

active_model_serializers

これを使いこなすためには きれいなAPI設計 がおそらく必要なのだけど、それがネックだった。 APIが汚いとserializerも汚くなる。 controllerでの手動よびだしとかするといまいち。 jbuilderや、素のhashを返すpure rubyのクラスを作って自前でas_jsonをしていくほうが、コスト低くある程度の規約ができてよかったかもしれない。

devise

自分が知っていたので立ち上がりは早かった。ただ、自分が入れてjwtなどの設定もしたので、自分が全部面倒見る感じになってしまった。管理画面には積極的に使えばいいとおもう。

rspec

実際は「テスト各時間を取れなかった」という感じになる。作るものもよくわからないし、教える時間が満足に取れない状況ではどうしてもテストは後回しになってしまった。

まとめ

すべて学習コストとリターンのバランスかなという感じがしました！

2018-01-17

Rails.cacheの落とし穴

はじめに

仕事で開発をしていた所、コードを動かしていてキャッシュされるべきところがキャッシュされないことがあったのでメモ。

結論

モデルをキャッシュする時、以下のようにしてもキャッシュされない。

@users = Rails.cache.fetch('user_all') do
  User.all
end

なぜか

ActiveRecord は評価を遅延させます。@users = User.allとしてもすぐにSQLが発行されることはなく@users.eachなど発行するクエリが決まった段階でクエリ発行されるわけです。

結論に書いたケースだとUser::ActiveRecord_Relationのインスタンスがキャッシュに入り、インスタンスが評価された段階でSQLが発行されるため、結果としてキャッシュを使っても毎回SQLが発行されてしまうわけです。

どうればいいか

http://morizyun.github.io/blog/model-master-cache-rails-redis/index.html#Active-Record-Relation-to-a-1%E5%9B%9E%E5%91%BC%E3%81%B3%E5%87%BA%E3%81%97%E3%81%A6-%E3%81%AE%E3%82%AD%E3%83%A3%E3%83%83%E3%82%B7%E3%83%A5

上記の記事を参考にさせていただきました。以下の用にto_aを使ってクエリを即時発行すればOK。

@users = Rails.cache.fetch('user_all') do
  User.all.to_a
end

2018-01-14

webpackerのサンプルをparcelでつかったらautoloadが効かなかった

はじめに

parcelを使っていて動かすコードとしてwebpackerのreactのサンプルを使っていました。

その中で、parcelにはdefaultでautoloadの機能が備わっているのにloadされないという状態が起こりました。

ここでは原因とその対処法について書いていきます。

問題のコード

https://github.com/rails/webpacker/blob/05062bd72a6e759d34ed3f4e05639dbd0f3b4ce4/lib/install/examples/react/hello_react.jsx

import React from 'react'
import ReactDOM from 'react-dom'
import PropTypes from 'prop-types'

const Hello = props => (
  <div>Hello {props.name}!</div>
)

Hello.defaultProps = {
  name: 'David'
}

Hello.propTypes = {
  name: PropTypes.string
}

document.addEventListener('DOMContentLoaded', () => {
  ReactDOM.render(
    <Hello name="React" />,
    document.body.appendChild(document.createElement('div')),
  )
})

原因

以下のコードが問題でした。

document.addEventListener('DOMContentLoaded', () => {
  ReactDOM.render(
    <Hello name="React" />,
    document.body.appendChild(document.createElement('div')),
  )
})

autoloadはjsが再実行されるだけなので、addEventListenerで再度イベント登録しても、domがrenderされることはありません。

対処

まず、addEventListenerを使わずReactDOM.renderを即時実行するようにします。そうするとautoloadするたびにappendChildされるので、getElementByIdにして何個もdomが作られないようにします。html側にid要素をもつdivを一個作っておきました。

const mountNode = document.getElementById("app");
ReactDOM.render(<Hello name="React" />, mountNode);

jsのscriptタグがheadに書いてあったので、bodyの一番最後に変更してdivがある状態で読み込まれるようにもしました。

背景

Railsは基本scriptタグはheadに置くので、haedにおいても大丈夫なようにaddEventListenerを使った書き方になっているのだと思います。

まとめ

まだまだjsについては無知だなと感じました。

2018-01-07

モチベーションを上げたい２〜猪子寿之の話に学ぶ〜

f:id:waterlow2013:20181109010843j:plain

猪子寿之の話

https://ja.wikipedia.org/wiki/%E7%8C%AA%E5%AD%90%E5%AF%BF%E4%B9%8B

かなり前の話になるのだが、テレビで以下のような話をしていた。

仕事で海外に１人出張することが多く、いろいろとつらい
海外で自分の食べたいものを食べられないのがとくにつらい
なので、どこでも食べられる目玉焼きを好きになることにした
本当に好きになってたまに目玉焼きを家でも作る

モチベーションアップに置き換える

モチベーションの上がらない仕事を好きになる
何かモチベーションアップにつながるルーティンを持っておく

まとめ

結局のところ自己暗示の話なのだが、好きなものを変えるというのはなかなかぶっ飛んでいて面白いと思った。

2017-11-20

「Presentational and Container Components」を読んだメモ

はじめに

さいきんちょこちょこReactやReduxをやっているのですが、いつも読んだドキュメントのことを忘れてしまうのでちょこちょこまとめて行こうと思います。
今回はReduxの作者でもある@dan_abramov氏の書いた、Presentational and Container Componentsです。

Presentational and Container Components

コンポーネントをPresentationalとContainerに分けると、再利用がやりやすくなる。

presentational コンポーネントの特徴

見た目に関すること
presentational/container コンポーネントのどちらも含む。
DOM markupを含む。
this.props.childrenによる封じ込めを許可する（？）
アプリケーションの他の機能に依存がない
データの扱いや操作は書かない
propsを通じてデータやcallback関数を受け取る
まれに自身のstateを含む（？）
stateへのアクセスや、lifecycle hook、パフォーマンスの問題がない限り（？）はfunctionalにかく
ex) Page, Sidebar, Story, UserInfo, List.

container コンポーネントの特徴

どう動くかに関すること
presentational/container コンポーネントのどちらも含む。
ラップするためのdivを除いて、DOM markupを含まない
dataや振る舞いを他のpresentational/containerコンポーネントに提供する。
Flux actionを呼んでpresentationalコンポーネントにcallback関数として提供する（？）
ステートフルで、データソースとして機能することが多い。
手で書かない。React Reduxのconnect()を使う。
ex) UserPage, FollowersSidebar, StoryContainer, FollowedUserList.

このアプローチの利点

アプリケーションとUIをよく理解できる
再利用性が上がる
デザインだけの微調整ができる
layout componentsだけを外出することができる。（？）

どちらのコンポーネントもemit DOM（？）を含まないこと

presentationalコンポーネントだけでアプリケーションを作ろうとするとpropsを渡す煩雑さに気づく。（？） propsを渡して歩くよりcontainerを使う方が良い場合がある。（？）

２つのコンポーネントの差はtechnical（？）なものではなく目的である。

宗教的に２つのコンポーネントを書き分けようとしないこと。 presentationかcontainerかわからなければ、あえて決めなくても良い。

2017-10-08

捗る！Ruby on Railsでscaffold駆動開発

Rails

最近Ruby on Railsの開発をするときに、色々参考にするためにscaffoldを叩くようにしています。 scaffoldのコードからどういうところが学べるのかを書いていきます。

scaffoldは誰もが通る道

きっとRailsを始める人は、Rails チュートリアルなり本なりで勉強することが多いはずです。scaffoldはそれらの中でRailsを始める第一歩として取り上げられることが多く、よってかなりの人がscaffoldのコードを目にしているはずです。

scaffoldから学べるポイント

コントローラで例外処理を書かない

scaffoldで作られるコントローラには、例外処理が一切ありません。しかし、ActiveRecord::RecordNotFoundになったら404が返るし、NoMethodErrorは500が返るわけです。これによりコントローラでの関心事を少なくすることができます。多くのアプリケーションでは404や500のエラーページを専用のものを用意しますが、以下のようなプラクティスで、例外処理を共通化することができます。

Railsの404,500エラーページをカスタマイズ - Qiita

update系の成功失敗は戻り値で判断

jnchitoさんが以下の記事に書いてくださっています。 qiita.com save, update, destroyはバリデーションエラーが発生する可能性があり、その場合はエラーページではなく正常なページでバリデーションで引っかかった箇所をユーザに通知するのが望ましいです。エラーをraiseして500エラーページを出してはいけません。

ルーティングはRESTに

特に必要がなれけばconfig/routes.rbにはresourcesでルーティングを定義するのが良いです。これにより全体のAPIインタフェースを合わせることができます。

namespaceありの場合の挙動

例えば以下のようなコマンドを打ったとしましょう

rails g scaffold foo/bar

すると、以下のようなモジュールが追加されます

module Foo
  def self.table_name_prefix
    'foo_'
  end
end

これにより、モジュール下のモデルにtable nameをいちいち書く必要がなくなります。また、ルーティングもどのようにして書かなければならないかいつも覚えられないのですが、動作できるように追加してくれます。

だめなところもある

コントローラでbefore_action でついてくるset_xxxは実はもやもやしています。 scaffoldで書いてあるのくらいであればいいのですが、だんだん増えてコントローラのconcernで共通化やり出す発想になるのは避けたいところです。

Controllerのbefore_actionにおけるインスタンス変数セットについて from pospome

www.slideshare.net

まとめ

scaffoldをを叩いたときに学べるポイントをメインに書いていきました。もっとみんなscaffoldを使ってほしい！！！！

2017-06-17

Rails アンチパターン - スケールへの壁（Scaling Roadblocks）

引き続きRails AntiPatternsという本を読んでいます。

https://www.amazon.co.jp/dp/B004C04QE0/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1

前回は5 Servicesの2つめ「Sluggish Services」についてまとめました。

waterlow2013.hatenablog.com

今回は8 Scaling and Deployingの1つめ「 Scaling Roadblocks」についてまとめます。

Scaling Roadblocks

Railsアプリケーションを運用するのに、本番サーバ１台でなんとかなるのにわざわざクラスタ化などのコストの高い対応を初めからする必要はない。ただ、コストが低いもの、もしくは後で対応するとコストが高くなるものは初めに対応しておいてもよさそう。

Solution: Build to Scale from the Start

例えばimageの配信はローカルのファイルではなくS3においておくというのはそこまでコストはかからない。 gemも存在している。carieerwaveやpaperclip、shrineなど。

まとめ

最近はRailsアプリはコンテナ化しておくのが割と普通になっている感じがしていて、時代が変わったなと思いました。 asset-syncやcdnなども、やっておいてもよさそうだなと思いました。

はじめに

入れてよかった

onkcop(rubocop)

bootstrap

gimei

ridgepole

seed-fu

shrine

capistrano-*

入れなくても良かった

active_model_serializers

devise

まとめ

はじめに

結論

なぜか

どうればいいか

はじめに

問題のコード

原因

対処

背景

まとめ

猪子寿之の話

モチベーションアップに置き換える

まとめ

はじめに

Presentational and Container Components

presentational コンポーネントの特徴

container コンポーネントの特徴

このアプローチの利点

scaffoldは誰もが通る道

scaffoldから学べるポイント

コントローラで例外処理を書かない

update系の成功失敗は戻り値で判断

ルーティングはRESTに

namespaceありの場合の挙動

だめなところもある

まとめ

Scaling Roadblocks

Solution: Build to Scale from the Start

まとめ