ぎんさんマインド

いち弱小エンジニアの思考とか趣味についてつらつらと書いてみるかもしれない。

Rails Developers Meetup 3/22 個人用メモ

Rails Developers Meetup 2019
詳細: https://railsdm.github.io/

 

個人用メモ誤字とかたくさんあると思う。気がついたら直すかも。

 

1030 DHH質疑応答
全英語なので理解度薄い
質問内容: https://railsdm.herokuapp.com/issues/110

 

翻訳ありがたい

https://twitter.com/_yasaichi/status/1108907660085067777

https://twitter.com/m4buya/status/1108909638227886081

https://twitter.com/m4buya/status/1108911818255196160

 

あとで映像配布するらしい。

 

11:50 アプリケーションを作るときに考える25のこと session-A

https://togetter.com/li/1330555

 

価値があるか 難しいかの二つの軸で考えて4つに分ける それぞれでフレームワークを考える
API特化などはRailsが得意なので簡単に作れる

Railsの基礎
リクエストの流れ Generatorを利用

Slimの良さ

狩野モデル
当たり前品質
充足品質のグラフ

kaminariのページネーション
pagy gem ページネートオブジェクト用gem
kaminari without_count
kaminariの中は読むと良い

ファイルストレージgem
dependents gem
githubでスター数高いもの調べてgemfile調べていくとgemに詳しくなる。

ActiveSupport::CurrentAttributes
default_scopeの罠

論理削除
acts_as_paranoid paranoia discard
deleted_atをつける
削除テーブル
削除したら別テーブルに写す 数ヶ月後に物理削除する的なことができる
削除ろぐを作成する 不必要テーブルが多すぎるときろぐに逃がす
確認するときはログを見る

ランキング
redisのsorted setを使いたい
zuhionstore RUby
boffin gem

github検索して全部見る
ライセンスより推薦に振りたい

markdown
commonMark
方言の多い言語
commonmarkで統一しよう
一覧でまとまる
redcarpet kramdown
HTML Piperine

編集履歴 audit_log 監査ろぐ
ActiveModel::Dirty
User.changed?とか
監査ログ

 

 

12:30 DevOps, Immutable Infrastructure, microservices そして Chaos Engineering
DevOps, Immutable Infrastructure, microservices and Chaos Engineering


https://speakerdeck.com/yoshiori/devops-immutable-infrastructure-microservices-and-chaos-engineering

 

タイトルのアレの全体の流れ
Fowler
immutable Infrastructure chadFowker 情熱プログラマー
サーバーの普遍性
インフラをimmutableにしようね
あとでchefに開いておくだと忘れるから 不変にしておこう

microservices
martin fowler
超巨大な組織から 小型化していこうね
実は組織パターンの話
急速に流行り過ぎた
あんまりマイクロサービスにしすぎるのはダメだよ

クックパッド
spec 20000以上
rrrspec
mamiya

docker
Aplicationもimmutableを意識することを強制
アプリケーションコードも意識していかなければならない

container Orchestration
k8s ECS
実行を抽象化 docker run
microservices化で多数のコンテナ化されたアプリケーションを管理する
contrainer orchestration

serviceMesh
serviceはMesh構造になってるよね
envoy
アプリケーションごとにプロキシを立てる
サービルの通信状況を把握
タイムアウトリトライサーキットブレーカーをアプリケーションから外す
全てenvoyに任せちゃう

chaos Engineering
分散システムにおいてシステムが不安定に耐える環境を構築すること
サービス インスタンスを落とすことではない!!

steady state
pact
正常状態を計測する
毎秒どれくらいのユーザーが動画を見ているのかログインしているのかを判別する。
レシピの閲覧数:検索数
Envoyによるstateがfailedのテストを確認
どうなるかを確認して影響範囲を調べる

microservicesはユーザーの影響を常に考える
steady stateも考えていく

 

 

14:00 サーバーサイドエンジニアも知っておくべきフロントエンドの今

フロントエンドのエコシステム
JS ⇨ TS
TSを導入すべきか
TS強いから以降が進んでる
コンパイル IE11は切ってもいい
ES2015以上を洗濯してもいいよね
DOM 宣言的View
React Vue etc
仮装DOM 手続き的DOm
JQueryよか仮装DOM系
lit-html
仮装DOMではないけれどdiff取れる
editer vscode
Linteer ESLint一強
formetter prettier
prettier-rubyの開発が進んでる
rubocopとどうなるか
module bundler
webpack 🌟
Rollup
pika
test
jest
jest + Puppetter
selenium離れがきてる
非同期処理
axiosがbetter

web components
polyfill
一応使える技術になってる
githubも導入
でもいくらか注意が必要
仮想DOMが死ぬことはない
昨日が足りてないので現状下位互換
webcomponentsは使い続ける流れではある

最近注目のものから1つ
CDN worker
micro frontends
pwa
レンダリング最適化
webpyments
CDN Worker とは
CDNへのレスポンスをフック
AWS LAmbda@Edge CloudFront
Firebase Hosting
BFFをエッジロケーションにおける
担うところ
認証
APIAggergation
Server Side Rendering
Cache
SPA技術で用いた環境でこれまでやりたかったことと課題
FMP SEO を最適化したい
できるだけ早く描画したい
そのためにはレンダリング済みHTMLをクライアントに送る
SSRしたい
課題
SSRにはJSの実行環境が必要
RTT通信距離を最短に
エッジロケーションで通信を完結したい
動的サイトの場合はオリジンサーバーでHTMLを作って送ってもらう
CDNworkerなら解決できるかも
RTT FMP SEO
自前でNodejsサーバー建てなくても良い
オリジンサーバーへのリクエスト数を最小化できる
リージョン変えて値段が安く
cloud flear service
CDN Woeker

エコシステムの成熟
開発体験が良くなってる ライブラリ乱立が落ち着く
UXに直結する話題が多い
最適な設計にはフロント知識も必須
TS 宣言的View flax Vuex View flax Vuex

 

 

14:40 SQLQL は GraphQL にとって、何なのか

https://www.slideshare.net/yancyajp/sqlql-graphql

what is SQLQL
https://qiita.com/yancya/items/4b7979d83cbf6af9b819
APIに直接SQLを投げる。JSON形式で帰ってくる
RDBMSを使いたいPostgreSQLを使いたい
物理的に直接テーブルを触れさせたくはない。流石に
sqlql_sample github https://github.com/sqlql/sqlql_sample
ツイッターのファボ 鍵機能付き
CTE インラインのView
問題点
Mutation DELETE関係
スキーマ就職
無限ループ
再起クエリ
Mutations の除外 Rails6.0
replica属性のサブコネクションから簡単に描ける
replica: true でmutationが除外
CTEのWITHも弾いてしまう
モンキーパッチで対応できるが、そもそもWITHをなくした理由があれ
副作用が起こせる
DBのreadonlyユーザーを作る他ない
無限ループ対策
タイムアウト
DOSに弱い
SQLQLを使って何がしたかったのか
インピーダンスミスマッチ
JSONからExcel形式とかやりたくない
Relation to Object
JSON_TO_RECORD
JSON_TO_RECORD_SET

 

15:20 休憩

 

16:00 我々はマイクロサービスとどう向き合うべきか session-c

https://speakerdeck.com/ota42y/how-should-we-face-with-microservices

マイクロサービス構成
事業が幅広いので初期から携わっている
50ほど
疎結合にはなってる
railsdm day4
事業が大きくなるほどに肥大化していく
カオスコード化していく
リファクタリングより昨日開発が優先されてしまう
新機能が多くなるにつれてさらにカオスに
それぞれのアプリチームがPDCAを回せるように
マイクロサービスはそしてパターン
新機能をやったり既存機能をマイクロサービス貸したり
マイクロサービスの良かった点
CIのすぐ終わる
日々の開発速度が大幅に上がる
クラス依存が少なくなる
影響範囲が小さくなる
チームごとにPDCAがしやすくなる
することしないことが明確化しやすくなる
キャッチアップもし安い
ただし、マイクロサービスが増えすぎると
エンジニア数よりも多いマイクロサービスがでる
れい:ランキングマイクロサービス
最初の分割はいいマイクロサービスだった
<!-- モノリシックな分割 -->
セキュリティ対応が手薄になる
バージョンアップが遅くなる
githubのsecutity alartが出てようやっと対応
一人で兼任しているとアップデートの困難
気づきにくくなる
対応はアップデートしやすいのでマイクロサービスは良いてん
チーム街の対応は大変
モノリシックは大変だが漏れにくい
マイクロサービスは簡単だが漏れやすい
漏れを減らす対応が必要
gemicoma
週にの割れ窓直す時間を確保
warningを消す
ビルド環境を整える
ドメインが成長して変わることがある
他企業との連携
あるコミュニティとの紐付け
communityというマイクロサービスとの関連
マイクロサービスごとに違いがある
ドメインも切りにくい
community ranking chat
結果としてドメインが変わってしまう場合もある。
回避法は難しい。
完璧なドメイン分割はDHHでも難しい
二つのマイクロサービスを同時に変更することが多いのならば一つに統合するのも手である。
これも辛いのでベストアンサーが欲しいところ
トランザクション処理
インフラ
チーム連携
サービスをまたいたオーバーヘッド
でもこれらはマイクロサービス特有の問題ではない
チームならよくある問題
ただそれがマイクロサービスなら何倍にも膨れ上がる
リファクタも多くなる
人数<サービス数 だとさらに辛い
サービス数 連携の数によってツラミが増える
人数が多ければ対応できることは多い。
組織の成長が大事
組織の強さとマイクロサービスの数がちょうどいい堆肥が良い
対策
ラッパーマイクロサービス
新サービスは旧サービスをラッピングしていく
新機能はBFFに追加していく
エクソダスサービス
新機能はベット作っていく
マイクロサービスにおけるRails
小中規模に止めると良い
しかし、密結合になりやすい
将来的なマイクロサービス
CI/CDほどに成熟はしていない
周辺ツールが発達しているのでその辺の動きによりよくはなっていく
BAllerina マイクロサービス用のプログラミング言語
将来的にマイクロサービスの辛い領域を小さくしていきたい
用法用量を守って正しくマイクロサービス
Railsのマイクロサービス知見もっと欲しい

 

 

16:40 AskDoctorsの13年目を支える技術 session-b

M3 サービス多数
askDoctors コンシューマー向けサービス
いつでも体の悩みをお医者さんに相談できる 医者6000にん
2005 ~ 2019
JQueryが2006年から
PC向け App向け 女性向けでそれぞれ分けていた
委託していたのでコードも別々
コンテンツの共有をしたい
CoreAPI
見た目の速度改善
3つ分けるのはあれなので統合したい
Railsで統合
13年間やっていると使用を全くわからない
DBの統合
CoreAPIのデメリット
データ生合成の問題
少ない人数で多くのサービスを進める
リプレースが一つ一つになる
ゾンビサービスが増える
ある程度サービスが落ち着いてから UIUXの改善を目指すようになる
キャッシュ
DBスケール
Docker k8s
メリットがあるかどうか
週一でエンジニアが自由にやっていい時間がある
ひどいコードを見たときにどういう経緯でやってきたのかを考える
時系列に元ずいた全体像が見えてくる

 

 

17:20 Rails meets Protocol Buffers - For Schema First Development session-b

ゲーム開発でのRails
APIモード
ランタイムの許容可能なオーバーヘっどが確保
rails を使える人が多い
コーディング規約がすでに定まっている
ボイラープレートが少ない
必要な部分だけ開発すれば良い
Rails Engine
スキーマfirst開発
フロントとバックエンドで忙しいタイミングが異なる
差し戻しで両方忙しくなり炎上
ドキュメントで管理するとコストがかかる
スケジュール管理も面倒
ドキュメントの時間小さくしたい
swagger openapi
スキーマ定義
お互いの合意を取る
自動でコードを生成
モックも作成
お互いが作業に集中できる
変更はスキーマに変更すれば良い

2010年で選んだもの protbuf ln-house schema
スキーマfirst開発は
プロダクトを良くすることであり、スキーマを完璧にすることではない
Rails とprotobufの関係
protobuf簡単に覚えられる
restfullAPI
シンプルな開発が行エル

18:00 疲れた。休憩

 

 

18:40 毎日の開発に役立つRailsプラグインづくりの秘訣 session-a

gem書いた話
http://github.com/amatsuda/丸々
現場の問題を解決するためにgemを作る
現場の問題のために道具を作る
E2Eテスト書くの面倒くさい
普段描かない人も楽にかけるといいなー
heavens_door
READMEにgif
昔作ったものの書き直し
hocus_pocus
趣味で作った
path直打ちでscafford
localhost動かすことでコードの生成をする
構想はあったけれど、進まなかった
実際に問題を解決するものでないとやる気が続かない
スモールスタートがいい
機能は少なくした方が良い
READMEもかけない
READMEのアニメgifは良い
現場の問題
ER図が見たい
erd gem
status of erd
画面遷移図を見たい
画面遷移図の素材はrails app に全部ある
gemで作れる
pdfか
e2eテストから遷移を記録してER図に表す
カバレッジにもなる
テスト資産を増やす
still_life
テスト中に描写されたrenderをhtmlで書き出す
自作テンプレートエンジン
Himl
Haml の良さ 閉じタグを描かなくても良い 絶対に安全
どこにでも問題はある
それを解消するためにgem作るというのもある

 

 

19:20 まだ40代後半のプログラマの話、あるいは50代プログラマについて考える

40代後半としてのプログラミング
30代はまだ競争できる
40代は競争から降ろされる
蓄積で生きるか別の道で生きるか
35歳プログラマ定年説
人の人生は人のもの
自分とは違う
50,60だと難しい
自分以外が全員年下。
相手にとってやりズラくないかどうか
定年を強いる圧力
年齢が上がると後進を育てるべきではという圧力
老害
対策
実力で倒す
別の道を探す matz
後進に譲る
なんのためにプログラミングするのが
楽しいから 問題解決 金のため
人生について考える
後進がいないところに行く
未来を広げていこう
railsは武器になる
フルスタック
これで完結する
EPUBCheck
Javaせい lint
電子書籍アーカイブできるのか
青空文庫
20年
著作権終了した文庫を公開
専属のエンジニアがいない
青空文庫Ruby
変換ツールをgem化
事業継承問題

 

 

所感
マイクロサービス多い
matzがきててびっくりみんな普通に話してて、このコミュニティの雰囲気を感じた
1セッション30分だけれども、内容が50分くらい必要なものを圧縮してるのが多い感じがするし、休憩10分だけなので、とても疲れた。

明日はこういうメモ取らないかもしれぬ…

ダイエット生活第2週目

これからは日誌のように日々の状態を綴って行こうかなと思う。

 

月曜日

会社の付き合いでお昼ラーメンを食う。体重計に乗るのが少し怖かったが、増えなくてよかった。

今日から筋トレとランニングを始めるようにする。身体を作るために少しづつ、続けることを意識する。

 

火曜日

夜に前日買ったメロンパンを食べる。昨日に引き続きランニングと筋トレを行う。毎日行うためにジャージを何着か増やした。

体重は昨日から変わらないので。急激に下がらなくなって来たと感じた。

 

水曜日

ようやっといくらか体重が減る

仕事が忙しく、腹が減ったので昼にパンとパスタを食った。

筋トレとランニングを日課にし初めて慣れてきた。これからも続けていきたい。

 

木曜日

やっぱり停滞期のようだ。体重があまり減らなくなった。

食事は前日買ったメロンパン一つ。

ランニングも物足りなくなってきたので、明日からスピードをあげるか長く走るようにしたいと思う。

逆に筋トレは飽きてきたので、何か面白くなる方法を考えたい

 

金曜日

体重はあまり減らない。まぁ気長に進めて行こうかなという気分

食事はきゅうり

ランニングのスピードを上げてみた。これからも継続していきたい

筋トレが面倒になってきたので、映画とか動画見ながらやるようにした。それなりにやる気は出るようになった。

 

土曜日

体重が少しづつ下がってきた。食事のせいか、単に停滞期を抜けたか。要調査。

休日だし少し多めにランニング。まぁ昔からの経験上それですぐに体重が減るわけではないのはわかってる。

筋トレはいつもの通り、多くやりたいほどやる気が出ないのがなんとも…

 

日曜日

体重が落ちてガクッと落ちた。まぁこうやって少しづつ減らしていけたらなという感じかな。

今日はもやしを食べた。カロリーが低いのとタンパク質がそれなりにあり、量が食えるので、たくさん食べたい時とかに利用しようかなと思った。他にもキャベツやセロリ、グレープフルーツとかも良さげなので、飽きてきたら試そうかなという感じ。

レーニングはいつも通り、基本的に面倒くさがりなので多めにやりたがる工夫を考えたいところ。

 

 

Keep

  • 先週から始めたし現状はなし。

Problem

  • 停滞期への対応。
  • 食事の安定化。
  • 運動のマンネリ化 多くする方法

Try

 

その他 

f:id:ImpureSilver11:20190317191815j:plain

今週で-2.5kg、全体だと-7.4kg。落ちなくはなって来たけど、想定通りという感じ。

 空腹時に運動すると筋肉が減るらしい?まぁ変に生活が変わるわけでもないので、普段は飯食った後にでもトレーニング挟もうかな。

 毎日の食事を安定させたい。とりあえずローカロリーのものから、だんだんと食生活を日常レベルに戻す。というのが今後の目標

 社会人だし、どうしても人付き合いで飯を食うときもある。一応飯も買ってあるんだけど、そういう時はどうしようかなという感じ。

 

ダイエット生活第1週目 ~ 今後の方針とか ~

 

f:id:ImpureSilver11:20190310211102p:plain

再生回数が順当に増えていってます。

 

間違えました。

痩せる宣言をしてから5日ほど経って最初の日曜日がきたので途中経過等書いていこうと思う。

これからは毎週日曜に経過をここで書いていけたらいいなー思う。

毎週KPTを回しつつ改善していく方針。

なぜ日曜日かといえば、休日は生活が変わるので外食しやすく太りやすいので、戒めのためのような感じ。

自分の見栄っ張りな点をうまく扱いつつこのタイミングで書いていったほうがいいかなーと思った次第。

 

f:id:ImpureSilver11:20190310210808j:plain


 

で、現段階では-5.2㎏くらい。

 

5日でこの痩せ方は普通ではないと思う。スポーツマンの減量とかってこれくらい急激に痩せるのだろうか?

まぁなんでかといえば、この5日間ほぼ食わなかったということだけれど。

通常ならこういうことはあまり良くないとは思うけれど、今の自分はかなり体重も増えて胃袋も大きくなっているので、それを小さくしたいという意味合いもある。

これをずっと続けるつもりはないし、そんなことしたって意味ないことはわかるので適当なところで切り上げて、今後は運動量と食事量を均等に上げていく、体重は筋肉量と相談しつつ減らしていく、そして体重筋肉量運動量食事量を適当な値にしたらダイエットdoneという感じでいきたい。

 

そのための参考として

運動不足エンジニアが3ヶ月で健康になれた超簡単な取り組みを解説する - paiza開発日誌

不健康エンジニアが3ヶ月だけ食事に気をつけたら心も体も健康になれた話 - paiza開発日誌

はよく考えて見ていきたい。あと、

https://www.amazon.co.jp/%E3%83%98%E3%83%AB%E3%82%B7%E3%83%BC%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E-%E2%80%95%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E3%82%92%E6%A5%BD%E3%81%97%E3%81%8F%E7%B6%9A%E3%81%91%E3%82%8B%E3%81%9F%E3%82%81%E3%81%AE%E5%81%A5%E5%BA%B7Hack-Joe-Kutner/dp/4873117283

この辺とか買って読みたいなー

 

ただ読むだけではなく、自分の考えるダイエット論を更新していきたい。

正直今の考えはまだまだ稚拙なところもあるのでうまいこと合わせていきたい。

 

まぁただこれは、100人いれば100通りのやり方があると思うので自分をオリジナルのもの見出さねばならない。人から言われたことなんて必ず成功なんてことはない。特に自分ほど太った経験のない人の「こうすれば痩せる」は基本うまくいかない。これは経験論。

 

なので、考えながら痩せて行こうかなという意識表明を示したところで、今週は終わり。 

vueの単一コンポーネントファイル内のcssが読み込めなかった。

少しつまづいたのでメモ程度に

普段はrails使ってるけれども、webpack4系が使いたくなったのでちょっとサーバーレスでvue書いてみて、慣れようかなーと最近やってます。

基本webpackerばかり使ってたからwebpackのお勉強も兼ねてやってるんだけれども、慣れてないせいかうまくいかないことも多い。

特にバージョン違いで入れるもの入れないものが結構異なってきて、そこでつまづく。

 

ネタバレだけど、タイトルの件もそのうちの一つだった。

とりあえず環境の構築として、github pageにSPAでデプロイしようかなーと思い

qiita.com

この辺を参考に進めてた。

"@vue/test-utils": "^1.0.0-beta.29",
"css-loader": "^2.1.0",
"gh-pages": "^1.2.0",
"jest": "^24.1.0",
 
"vue": "^2.5.17",
"vue-loader": "^15.6.2",
"vue-lodash": "^2.0.0",
"webpack-dev-server": "^3.1.14"
"vue-router": "^3.0.1",
"vue-template-compiler": "^2.5.17",
"webpack": "^4.17.1",
"webpack-cli": "^3.2.3"

一応入れたものはこの通り。( GitHub - ImpureSilver11/othello: GitHub Pages Sample. ここで作ってる。)

で、書いていたらbuildするときに

ERROR in ./src/pages/Home.vue?vue&type=style&index=0&lang=css& (./node_modules/vue-loader/lib??vue-loader-options!./src/pages/Home.vue?vue&type=style&index=0&lang=css&) 74:0
Module parse failed: Unexpected token (74:0)
You may need an appropriate loader to handle this file type.

 って怒られた。

まだvueよくわかってなかったからメッセージの読み方もよくわかってなかったけれど、色々調べてみると、

vue-loaderの14系と15系だとstylesheetの読み込み方が違うみたいね。

https://vue-loader.vuejs.org/migrating.html#notable-breaking-changes

これの通りにwebpack.config.jsに下のruleを追加した

module: {

 rules: [

  {

   test: /\.less$/,

   use: [

    'vue-style-loader',

    'css-loader',

    'less-loader'

   ]

  }

 ]

}

で、見てみると、vue-loader@15系だとstyleは.lessとして読み込まれるのかな?で、私の場合はless-loaderがなかったので、その辺で怒られてたと。

 

そもそも普段scss使ってて、lessとか知らなかったよ…

もうちっとフロントに強くならんとなーと思う_(:3」∠)_

RIDDLE JOKER面白い

たまには大人な記事も書く書く。

 

この前丁度見つけたのでRIDDLE JOKERを見つけたので買った。

まだ一年経ってないしそんな古くもない気もするけど、それなりに買うのに時間がかかった。

 

というのも夏ぐらいにエロゲやりたいなーって時があって、RIDDLE JOKERとDRACU-RIOT!のどっち買おうかなーって悩んでたんだけれども、RIDDLE JOKERの発売後の評判見て、なんだか微妙みたいなことが聞こえてきたから、じゃあDRACU-RIOT!買おうかなーってなって、夏はそっちやってた。

私はゆずソフトはサノバ辺りの時期からやってたけど、どの作品も尊さがやばいよね。

 

今回のRIDDLE JOKERは特にキャラクターが良い…

一応謳い文句として三司さんの偽乳がーみたいなの言われてて、そこには魅力を感じてなかったんだけど、それよりも三司さんのキャラが良い。大正義さわさわさわさんの声良すぎて、お気に入りボイスがどんどん埋まる。ツッコミできるキャラは強い。面白すぎる。エロシーンでも笑わせてくるのはほんと卑怯だと思う。

www.nicovideo.jp

この動画もいいけど三司さんルートも良い、なんでも話せる友だちから恋人になる流れはキュンキュンくる。

 

 

三司さんだけでなく、他のヒロインも良い…

千咲の可愛さなんか特にすごい…(語彙力)

いひひ♪を無限に聞いていたい

nico.ms

 

なんだか普通によくいる女の子みたいな性格のキャラが多い感じがして、個人的にクる子が多かった。

 

可愛すぎて学生時代に戻りたくなった。

今はもう学生に戻れないことに気づいてやむくらいにハマってる。

多分この先1,2週間ぐらいは頭の中がお花畑になってると思う。

やっぱゆずソフトは最高やな…

Railsのwebpackerがつらい

前々からRailsでなんか作ろうかなと色々やってきた。

とりあえず、Railsだしherokuに簡単なものデプロイする想定で考えた時、フロントの作り方どうしようかなって考える。で、フロントやりやすくするためにwebpack入れようとなるけれど

GitHub - rails/webpacker: Use Webpack to manage app-like JavaScript modules in Rails

Railsにはwebpackerがあるので入れて見るけど、これがなかなかつらい。

impuresilver11.hateblo.jp

impuresilver11.hateblo.jp

と色々つまづいてきてとてもつらい気分になった。

結局この後herokuにデプロイできなくて色々試してみて

最終的にwebpackをv3にすることで、なんとかうまくいった。

 

まぁこの後色々調べてみたけれど、webpack4の対応が2018年5月で未対応のようで…

blog.euxn.me

 

その後一応対応するようになったようだけれど、私がたくさん踏んだようにまだつらいところ多く、安定して使うならwebpack v3で利用するのが吉のよう…

 

でも流石に今v3使うのもなーって考えると、Railsでwebpackerは避けるべきなのかな。

とすると、Railsのフロントはどうするべきなのだろうか。

 

私もまだRailsしてから4ヶ月くらいで、まだまだ知らないこと多いので良い選択肢が思い浮かばないけれど、webpacker入れてるとRailsがやってくれるフロント側のあれそれが邪魔に思えてきちゃって…

やっぱフロントは完全に切り離して、RailsAPI作るだけにしたほうがいいのかな…?