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代は競争から降ろされる
蓄積で生きるか別の道で生きるか
３５歳プログラマ定年説
人の人生は人のもの
自分とは違う
50,60だと難しい
自分以外が全員年下。
相手にとってやりズラくないかどうか
定年を強いる圧力
年齢が上がると後進を育てるべきではという圧力
老害か
対策
実力で倒す
別の道を探す matz
後進に譲る
なんのためにプログラミングするのが
楽しいから 問題解決 金のため
人生について考える
後進がいないところに行く
未来を広げていこう
railsは武器になる
フルスタック
これで完結する
EPUBCheck
Javaせい lint
電子書籍はアーカイブできるのか
青空文庫
20年
著作権終了した文庫を公開
専属のエンジニアがいない
青空文庫をRubyか
変換ツールをgem化
事業継承問題
所感
マイクロサービス多い
matzがきててびっくりみんな普通に話してて、このコミュニティの雰囲気を感じた
1セッション30分だけれども、内容が50分くらい必要なものを圧縮してるのが多い感じがするし、休憩10分だけなので、とても疲れた。
明日はこういうメモ取らないかもしれぬ…
ダイエット生活第2週目
これからは日誌のように日々の状態を綴って行こうかなと思う。
月曜日
会社の付き合いでお昼ラーメンを食う。体重計に乗るのが少し怖かったが、増えなくてよかった。
今日から筋トレとランニングを始めるようにする。身体を作るために少しづつ、続けることを意識する。
火曜日
夜に前日買ったメロンパンを食べる。昨日に引き続きランニングと筋トレを行う。毎日行うためにジャージを何着か増やした。
体重は昨日から変わらないので。急激に下がらなくなって来たと感じた。
水曜日
ようやっといくらか体重が減る
仕事が忙しく、腹が減ったので昼にパンとパスタを食った。
筋トレとランニングを日課にし初めて慣れてきた。これからも続けていきたい。
木曜日
やっぱり停滞期のようだ。体重があまり減らなくなった。
食事は前日買ったメロンパン一つ。
ランニングも物足りなくなってきたので、明日からスピードをあげるか長く走るようにしたいと思う。
逆に筋トレは飽きてきたので、何か面白くなる方法を考えたい
金曜日
体重はあまり減らない。まぁ気長に進めて行こうかなという気分
食事はきゅうり
ランニングのスピードを上げてみた。これからも継続していきたい
筋トレが面倒になってきたので、映画とか動画見ながらやるようにした。それなりにやる気は出るようになった。
土曜日
体重が少しづつ下がってきた。食事のせいか、単に停滞期を抜けたか。要調査。
休日だし少し多めにランニング。まぁ昔からの経験上それですぐに体重が減るわけではないのはわかってる。
筋トレはいつもの通り、多くやりたいほどやる気が出ないのがなんとも…
日曜日
体重が落ちてガクッと落ちた。まぁこうやって少しづつ減らしていけたらなという感じかな。
今日はもやしを食べた。カロリーが低いのとタンパク質がそれなりにあり、量が食えるので、たくさん食べたい時とかに利用しようかなと思った。他にもキャベツやセロリ、グレープフルーツとかも良さげなので、飽きてきたら試そうかなという感じ。
トレーニングはいつも通り、基本的に面倒くさがりなので多めにやりたがる工夫を考えたいところ。
Keep
- 先週から始めたし現状はなし。
Problem
- 停滞期への対応。
- 食事の安定化。
- 運動のマンネリ化 多くする方法
Try
- 運動を日課にする。
その他
今週で-2.5kg、全体だと-7.4kg。落ちなくはなって来たけど、想定通りという感じ。
空腹時に運動すると筋肉が減るらしい？まぁ変に生活が変わるわけでもないので、普段は飯食った後にでもトレーニング挟もうかな。
毎日の食事を安定させたい。とりあえずローカロリーのものから、だんだんと食生活を日常レベルに戻す。というのが今後の目標
社会人だし、どうしても人付き合いで飯を食うときもある。一応飯も買ってあるんだけど、そういう時はどうしようかなという感じ。
ダイエット生活第1週目 ~ 今後の方針とか ~
痩せる宣言をしてから5日ほど経って最初の日曜日がきたので途中経過等書いていこうと思う。
これからは毎週日曜に経過をここで書いていけたらいいなー思う。
毎週KPTを回しつつ改善していく方針。
なぜ日曜日かといえば、休日は生活が変わるので外食しやすく太りやすいので、戒めのためのような感じ。
自分の見栄っ張りな点をうまく扱いつつこのタイミングで書いていったほうがいいかなーと思った次第。
で、現段階では-5.2㎏くらい。
5日でこの痩せ方は普通ではないと思う。スポーツマンの減量とかってこれくらい急激に痩せるのだろうか？
まぁなんでかといえば、この5日間ほぼ食わなかったということだけれど。
通常ならこういうことはあまり良くないとは思うけれど、今の自分はかなり体重も増えて胃袋も大きくなっているので、それを小さくしたいという意味合いもある。
これをずっと続けるつもりはないし、そんなことしたって意味ないことはわかるので適当なところで切り上げて、今後は運動量と食事量を均等に上げていく、体重は筋肉量と相談しつつ減らしていく、そして体重筋肉量運動量食事量を適当な値にしたらダイエットdoneという感じでいきたい。
そのための参考として
運動不足エンジニアが3ヶ月で健康になれた超簡単な取り組みを解説する - paiza開発日誌
不健康エンジニアが3ヶ月だけ食事に気をつけたら心も体も健康になれた話 - paiza開発日誌
はよく考えて見ていきたい。あと、
この辺とか買って読みたいなー
ただ読むだけではなく、自分の考えるダイエット論を更新していきたい。
正直今の考えはまだまだ稚拙なところもあるのでうまいこと合わせていきたい。
まぁただこれは、100人いれば100通りのやり方があると思うので自分をオリジナルのもの見出さねばならない。人から言われたことなんて必ず成功なんてことはない。特に自分ほど太った経験のない人の「こうすれば痩せる」は基本うまくいかない。これは経験論。
なので、考えながら痩せて行こうかなという意識表明を示したところで、今週は終わり。
vueの単一コンポーネントファイル内のcssが読み込めなかった。
少しつまづいたのでメモ程度に
普段はrails使ってるけれども、webpack4系が使いたくなったのでちょっとサーバーレスでvue書いてみて、慣れようかなーと最近やってます。
基本webpackerばかり使ってたからwebpackのお勉強も兼ねてやってるんだけれども、慣れてないせいかうまくいかないことも多い。
特にバージョン違いで入れるもの入れないものが結構異なってきて、そこでつまづく。
ネタバレだけど、タイトルの件もそのうちの一つだった。
とりあえず環境の構築として、github pageにSPAでデプロイしようかなーと思い
この辺を参考に進めてた。
"@vue/test-utils": "^1.0.0-beta.29",
"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",
一応入れたものはこの通り。( 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」∠)_
Railsのwebpackerがつらい
前々からRailsでなんか作ろうかなと色々やってきた。
とりあえず、Railsだしherokuに簡単なものデプロイする想定で考えた時、フロントの作り方どうしようかなって考える。で、フロントやりやすくするためにwebpack入れようとなるけれど
GitHub - rails/webpacker: Use Webpack to manage app-like JavaScript modules in Rails
Railsにはwebpackerがあるので入れて見るけど、これがなかなかつらい。
と色々つまづいてきてとてもつらい気分になった。
結局この後herokuにデプロイできなくて色々試してみて
最終的にwebpackをv3にすることで、なんとかうまくいった。
まぁこの後色々調べてみたけれど、webpack4の対応が2018年5月で未対応のようで…
その後一応対応するようになったようだけれど、私がたくさん踏んだようにまだつらいところ多く、安定して使うならwebpack v3で利用するのが吉のよう…
でも流石に今v3使うのもなーって考えると、Railsでwebpackerは避けるべきなのかな。
とすると、Railsのフロントはどうするべきなのだろうか。
私もまだRailsしてから4ヶ月くらいで、まだまだ知らないこと多いので良い選択肢が思い浮かばないけれど、webpacker入れてるとRailsがやってくれるフロント側のあれそれが邪魔に思えてきちゃって…
やっぱフロントは完全に切り離して、RailsはAPI作るだけにしたほうがいいのかな…?
rails5.2 + webpacker3.5(webpack4.28) でherokuにデプロイしようとしてエラー返された
この辺を参考にしつつ
webpack入れてherokuにデプロイしようとした時に
$ git push heroku master
remote: Running: rake assets:precompile
remote: yarn install v1.12.3
remote: warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised notto mix package managers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
remote: [1/4] Resolving packages...
remote: [2/4] Fetching packages...
remote: info fsevents@1.2.4: The platform "linux" is incompatible with this module.
remote: info "fsevents@1.2.4" is an optional dependency and failed compatibility check. Excluding it from installation.
remote: [3/4] Linking dependencies...
remote: [4/4] Building fresh packages...
remote: Done in 36.47s.
remote: rake aborted!
remote: Sprockets::ArgumentError: link_tree argument must be a directory
remote: /tmp/build_***/app/assets/config/manifest.js:2
とエラーでてデプロイできなかった。
エラー
$ RAILS_ENV=production bundle exec rails assets:precompile
yarn install v1.12.3
warning package-lock.json found. Your project contains lock files generated by tools other than Yarn. It is advised not to mix packagemanagers in order to avoid resolution inconsistencies caused by unsynchronized lock files. To clear this warning, remove package-lock.json.
[1/4] 🔍 Resolving packages...
[2/4] 🚚 Fetching packages...
[3/4] 🔗 Linking dependencies...
[4/4] 📃 Building fresh packages...
✨ Done in 5.65s.
rails aborted!
Sprockets::ArgumentError: link_tree argument must be a directory
remote: /tmp/build_***/app/assets/config/manifest.js:2
ちなmanifest.jsは
//= link_tree ../images
//= link_tree ../javascripts. es6
//= link_tree ../javascripts. js
//= link_directory ../stylesheets. scss
別段特別な変更は加えてない(scssにはしたけど)
エラー返されてるのがassetsの方だけれど、webpack入れてるからいらないよなーと思いassetsのファイル全部削除、ついでにwebpack入れた時にデフォルトでできるjavascriptファイルをfrontendに修正した。
そしたらうまくいった。
エラーの内容とか理由がよくわからんが、もうちょい使い慣れてきたらわかるようになるかな？
