Notes〜新たな"Wow"を生み出す〜TOPABOUTPROFILEPRODUCTRECRUIT閉じる2020-02-05駆け出しエンジニア1年目で学んだ3つのことWeb開発チームのフロントを担当している山本です。最近では技術開発部の仲間も着々と増え、再来年入社の新卒採用まで始まりました。基本的に技術開発部は実務経験のある方が主なのですが、私は実務未経験からの採用でした。エンジニアを目指している人やエンジニアとして働き始めた人たちがエンジニアとして働くイメージが膨らむよう、エンジニア1年目で得た3つの学びを紹介したいと思います。ReactとReduxの技術面での挑戦Reactでの開発時にデータ管理の複雑さが増していき、Reduxを取り入れようという話になりました。それからWeb開発チームでも定期的にRedux勉強会を開催されるようになりました。毎回テーマを決め、各自で事前に予習をし、勉強会でお互いに学んだことを共有するスタイルで行っています。Reduxを勉強する中で、Reactの復習にもなり、初期の頃より理解できることが増えてきたのを実感できたのも嬉しかったです。機能(サービス)リリースするまでの見積もりの大切さ機能追加などを行う中で、現在の自分の力を考慮し、実装にかかる時間を正確に見積もることが大切だとよく上司から言われます。無限に時間があればいいのですが、そういうわけにはいきません。機能実装の時に必要な作業を書き出し、それに対してかかる作業時間を見積もるようにしています。数時間で終わるだろうと思っていても実際に取り掛かると手間取り、見積もりと差が出ることがよくありました。作業時間の見積もりは正確だとしても他の作業が発生することもあるため、それも事前に想定しながら見積もることが必要です。見積もり時間が短いからいいというわけではなく、自分の力量を知るために自分と向き合う時間でもあると思っています。今はInstaganttでスケジュール管理をしており、タスク状況を視覚的に把握できるので便利です。他にもオススメのツールがあれば教えて欲しいです。仕様の決定からデザインについて考えるようになる初めて機能追加する時に、仕様の可能性が無限大だということに気がつきました。ユーザーが使う時のことを考えながら、開発期間内でできることを決めていく必要があります。既存の機能のことも考慮しないといけないため、色々なケースを想定する必要があり、何度も話し合いが必要なこともあります。私の場合デザイナーにデザイン依頼する前に、自分が実現したいものを伝えるため、ワイヤーフレームを作成します。大まかな配置も伝えたいので、色々と調べたり部内メンバーからもフィードバックをもらうことがあります。ワイヤーフレーム自体は、HTMLやCSSでコードを書きながら調整したり、既にあるコンテンツをつなげながら作っています。ワイヤフレームを作るようになり、他のサイトのレイアウトなども意識するようになりました。まとめ以前のエンジニアに対して、コーディングだけが仕事内容だというイメージがあったのですが、仕様決めからスケジューリングなどコードを書く上で必要な作業があることも知りました。未経験でも勉強すればできるようになることも増えると実感し、今後も学び続けたいと思います。昨年は目の前のことで精一杯でしたが、今年はES6などの基礎部分を固めたり、もう少しバックエンドのことにも挑戦したりすることで、自分でできることの幅を増やしたいです。我々ワウテック技術開発部はこのような環境で開発をしています。興味を持った方がいらっしゃればいつでもご連絡下さい。09:19駆け出しエンジニア1年目で学んだ3つのことTweetもっと読むコメントを書く2020-01-09ペアプログラミングを試してみたどうもこんにちは!web開発チームのしまねです。最近web開発チームでペアプログラミングに取り組んでみました。取り組んだ開発はまだリリースまでいっていませんが、どのように取り組んだのか・やってみた感想などを振り返ってみたいと思います。目的としては大きく3つありました。レビューが十分にできていない状況を変えたいコードレビューの依頼は来るのですが自分の開発業務もあるため、十分にできていないなぁという思いを少し前から抱えていました。ある機能を実装するとしてそれに関するコードをすべてレビューするとなると、まとまった時間が必要となるためついつい後回しにしてしまっていました。結局十分な時間がとれず深く見れずに終わってしまうという。ペアプログラミングで開発すればレビューせざるを得ないためレビュー不足な状況を変えることができるのではないかと考えました。新卒が入った時に研修で使えるかを検証したいワウテックでは新卒採用を始めていて近い将来新卒が入社します。新卒の研修の一環としてペアプログラミングはいいんじゃないかなと思っていたので、その効果を検証する必要がありました。テスト時のバグ改修の工数を減らしたい開発の工数は見積もりやすいのですが、テストに出したあとのバグ改修はバグの数によって工数が増減するため見積もりにくくスケジュールが押してしまうことがありました。テスト提出の時点で極力バグを少なくできればテスト工数の振れ幅も小さくなり見積もりやすくなるはずです。2人で1人分のコードしか書けないので開発スピードは遅くなりますが、2人で確認しながら進めるのでバグが減ってテスト時のバグ改修の工数では短くなるのではないかという期待がありました。Codeでソースコードを複数人で編集できるようになります。誰か1人がホストになり共同編集する人を招待し、招待された人はホストのファイルを編集できるようになります。他の人がどこを編集しているのかはカーソルで表示されてわかりやすかったです。招待したり招待されたホストに接続する際にMicrosoftアカウントかGitHubアカウントが必要です。調べてみるとペアの中でドライバーとナビゲーターという役割に分ける方法があったので参考にしました。・コードを書くその他にはルールとして次のことを決めました。今回は僕がナビゲーターでペアのメンバーがドライバーで進めていくことにしました。ナビゲーターの僕がコーディングの前に大まかな作りを説明し、処理をコメントで書いていきました。この間はドライバーはやることがなくなってしまうので最初だけでもこの作業はあらかじめやっておくべきでした。キリの良いところまで処理を書いてドライバーにコーディングを始めてもらいました。目の前でどんどんコードが書かれていくのが面白くてしばらく見ていたのですが、「いけない、いけない。次の処理のコメント書かなくちゃ」ということでいったん次に実装予定の処理をコメントでどんどん書いていきました。その後はドライバーの書いたコードを見たり、疑問点に答えたり、次の実装を書いたりと進めていって最初に目標にしていた部分まで実装してその日は終わりにしました。1回やってみた時点で、2人とも他の業務もあり今回ペアプログラミングを行ったプロジェクトだけやるわけにはいかないので週に何回か2~3時間くらいでやってみよう、また、ペアプログラミングをする部分はそのプロジェクトのコアになるようなロジックの部分にしてcssの設定等の見た目の部分は1人で進めていこうということになりました。その後何度かやってみて・・・ペアプログラミングした部分のソースコードについては考え方まで理解しているのでレビューする必要が全くなかった。ナビゲーターはあまりやることがないのではないかと思っていたがドライバーとのやり取りが多く発生して想定していたよりも忙しかった。1時間を目安に休憩と決めていたがついつい進めてしまって休憩を取りそこねることが多かった。どこまでやるかを毎回最初に決めておいてよかった。いうような感想をもちました。Shareはすごく便利1つのPCではなくそれぞれのPCでできるようになるのでナビゲーター側の自由度が高くなります。昔は1つのPCに2人がはりついてやっていたそうですが、それだとお互いにかなりストレスになると思います。どこまでやるかを毎回最初に決めておくことが重要ペアプログラミングをしていると1人でやるより疲れるので予めゴールを設定しておくと気が楽です。気が楽なだけですが続けていくには重要なことです。コードレビューの時間をとる必要はないペアプログラミングを行った部分に関してはドライバー側が書いたコードもナビゲーター側が設計しているし、議論しながら進めているためコードを書き終わった時点でもうレビューはしなくてもいい状態になっています。新卒の研修としてはとてもアリマンツーマンでしっかりコードの書き方から見ることができるので新卒の研修時には非常に有用だと思いました。研修の際には逆にナビゲーターをやってもらってプログラムの構成を考えてもらうのもありかもしれません。目的3についてはまだテストまで到達していないので検証できていないです。現時点の感想では、仮にペアプログラミングで開発した方が工数がかかったとしてもメンバー間の知識の共有や議論して進めることでの品質のアップと他に得られるものがあると思います。やってコードを書くのかについては体系的に説明するのは難しいため、書いているところを見てもらうのが一番早いです。慣れませんがもうしばらく続けてみたいです。今回はやりませんでしたがLiveShareを使えばリモートワーク中でもペアプログラミングできるかもしれないので近い将来チャレンジしてみたいです。我々ワウテック技術開発部はこのような環境で開発をしています。興味を持った方がいらっしゃればいつでもご連絡下さい。18:16ペアプログラミングを試してみたTweetもっと読むコメントを書く2020-01-082020年もワウテックをよろしくお願いします新年あけましておめでとうございます。アプリ開発チームの岡野です。今年もよろしくお願いします。今年で2回目ですが、ワウテックでは毎年年明けに全社で神田明神に参拝に行っています。9時に神田明神に到着。去年も天気がよくなった気がしますが、残念ながら今年も雨でした(2敗)待ち時間の間にお守りを購入。我らが技術開発部部長(自分の上司)は、今年もIT情報安全祈願のお守りを買って早速会社のデスクに飾っていました。去年はこれのおかげでほぼ半年間重大な障害なく過ごせました。今年もご利益があるよう願います。個人的には今年も金運のお守りを買いました。宝くじが当たりますように。去年は文化交流館という箇所の2階で参拝しましたが、今年は御神殿で参拝できました。して参拝して神社の方に商売繁盛の祈願をしてもらう間参列している会社の名前が呼ばれるのですがIT系の企業名が多く呼ばれていました。IT時代を感じますね。混雑日を避けたことや去年よりも開始時間が早いこともあってか人は比較的少なく、スムーズに参拝は終了しました。解散後、去年買ったお守りをお焚き上げ所に渡し、今年一年の運勢を占うべくおみくじを購入しました。:Dうまくいかないことがあってもおおらかな心で構えていろというありがたいお言葉。忘れないように持って返って飾っておくことにします。今年もきっと慌しくなるでしょうが、公私共に最高な1年にできるように頑張りたいと思います。今年もワウテックをよろしくお願いします。参考リンク神田明神https://www.kandamyoujin.or.jp/我々ワウテック技術開発部はこのような環境で開発をしています。興味を持った方がいらっしゃればいつでもご連絡下さい。ワウテックAndroidアプリ担当の岡野です。今回は珍しくAndroidに関する投稿です。WowTalkには様々な機能がありますが、私が着任当時に実装した機能がタスク管理機能でした。当時はiOS担当だったため、Androidの実装は当時の担当の方がしてくれた(※1)のですが、最近不定期に機能改善をする際にAndroidのタスク管理機能のメンテナンスに苦心することが多かったので思い切ってアーキテクチャの変更に取り組みました。タスク管理機能の概要WowTalkでは作業内容をタスクとして管理する機能があり、テキスト情報に加えて画像やドキュメントファイルを添付し、タスクの担当者・関係者間で共有できる仕組みです。タスクには期限が設定でき、期限切れ当日には通知が届くようにもなっています。自分はもっぱら個人のタスク管理に使うことが多いこのタスク管理機能は大きく3種類のActivityから構成されています。編集画面は1つのActivityで実装されていたそれぞれ独立したActivityで実装されており、サーバーからのデータ取得リクエスト呼び出しや描画に伴うデータ加工などもそれぞれのActivityで実装されていました。上述したとおり複数の役割を1つのActivityで実装したため、多いものではソースコードの行数が2800行近くにまでなりました。多いと見るかは個人差があるかもしれませんが、個人的にはかなり苦労するレベルです。メンテナンスも忘れた頃にするので、毎回作業時に「これなにしてるんだっけ...」と処理を見返すことが何度もあり、作業効率があまりに悪いということもありました。今回はタスクの詳細・編集画面を改修することにし、下記の2つを実施することにしました。画面ごとにActivityを切り分けるタスクの詳細画面と編集画面は類似したインターフェース及びデータ構造のため、1つのクラスで実装されていましたが、それぞれ表示の仕方が変わるため、モードの切り替え時に逐次ViewのVisibilityを変更していました。これらを個別のActivityに分割することで状態の管理などを気にしなくて済むような実装にしていきます。データとViewの操作をActivityから切り分ける(MVVMアーキテクチャ)合わせてデータ操作とViewの状態管理も切り分けて、それぞれが依存しないようにしていきます。今回はGoogleがAndroidアプリ実装時の推奨アーキテクチャとしているMVVM(※2)を採用することにしました。簡単にMVVMについて書くと、データの取得/送信部分をModel(M)クラスに任せ、ViewModel(VM)はModelからデータを受け取り、View(V)が使いやすい形でデータを提供します(※3)。今回2つの画面のデータ取得ロジックがほぼ同じため、下記の様にModelを共通化した形で変更を加えることにしました。画面ごとにActivityを切り分けた上、MVVMにすることで1クラスあたりのソースコード量が減り、かなり見やすくなりました。合わせて以下の様な効果がありました。・現在の状態を意識する必要がなくなった・クラス内部の変数が減り、各変数への依存関係も減ったためロジックの構築がシンプルになった・表示のための"ビューロジック"と"実際の表示処理"が個々のクラス内で完結しているため、実装時に頭の中で同時に考える負担が減り実装が早くなった1つ目と2つ目は書いている通りで、今の画面が詳細画面なのか編集画面なのかを意識する必要もなく、またそれぞれの状態で利用していた変数を個別のClassで管理する様になったので、条件分岐などの記述が減り1つの関数の行数もだいぶ削減されました。3つ目に関しては実際に経験があるとイメージしやすいのですが、1つのActivity内でデータの取得から表示までの一連の流れを書く場合1バックグランドでデータの取得2受け取ったデータをメインスレッド(Handler)にポストする3メインスレッド内で変数への保存を行いデータの表示処理を行うみたいなことをするわけですが、一連の流れを描く際に1つで今回取り扱うデータとは関係ないデータを取り扱う処理(例えば描画や別の処理のエラーハンドリング関数)をかき分けながらHandlerを探すなんてことがよくあります。これが無くなるだけでもかなり実装時の負担は低減されました。気づいたこと今回実装していて思ったのがViewModelが思ったよりも肥大化したことでした。実装にあたりLiveData(※4)を利用した値の自動更新を採用したのですが、これとビューロジックを一度に実装するとそこそこな分量になりました(1000行程)また通常ModelはSingleton(※5)で実装してDBやサーバーから取得したデータをキャッシュすることを推奨(※6)されているのですが、別のタスクを開いたはずが直前のタスクの情報が表示されてるなんてこともありました。ActivityとModelは依存関係を排除しているとはいえ、用途は想定して実装しないといけませんね。終わりに今回はタスク管理機能のFatActivityをビューロジックの切り分けと整理によって2800行あったソースコードを200~1000行のクラスに分割し、保守性を改善しました。今後はこの画面以外でも同様の問題を抱えている箇所を1つずつ改善していければと思います。当たり障りのない内容でしたが、基本的なことの大切さを実感します。社内ではこういった既存実装が抱える問題を「負の遺産」と呼んでいますが、まだまだ負の遺産はありますので1つずつ返済していきたいと思います。Androidの実装は当時の担当の方がしてくれた決して前任者のソースコードがわかりにくいというわけではないです。MVCと何が違うのかいわゆる昔のModel-View-Controller(MVC)と同じに聞こえるかもしれませんが、個人的に思うControllerとViewModelの大きな違いはまさにViewのModelである点です。画面で表示する際、仕様によって表現を変える必要が出てくる場合があります。UnixTimeで保存し、アプリ側ではこれを「2019-11-29」と表示する場合もあれば「明日」「今日」の様な表現にする場合もあります。これらの表示の上での計算(=ビューロジック)は、MVCにおいてControllerで記述することはせず、Viewで加工することになります。MVVMではこのビューロジックをViewではなくViewModelに担当させることでViewは複雑な処理を記述する必要がなく、表示だけに集中できます。Androidアプリ設計パターン入門https://peaks.cc/books/architecture_patterns我々ワウテック技術開発部はこのような環境で開発をしています。興味を持った方がいらっしゃればいつでもご連絡下さい。性能改善お久しぶりです。WowTalkのAndroid開発担当している岡野です。前回1週間でヘルプボット作って社内リリースした話を書きました。その際にいくつか課題が出ましたので、今回は前回ほど専門的な内容ではありませんが、課題解決までのアプローチを書いていきたいと思います。前回作成したボットですが、欠点として単一のキーワードを送った時した回答できないという課題がありました。通常ユーザーがボットに質問する時には適当な長さの文章を送ってくると考えると使い物にならないですね。この課題を解決するため下記の流れでアプローチしていきました。記事の検索方法の変更1つずつ見ていきましょう。形態素解析とはなんぞやというと方のためにお話しすると、要は文章を意味のある単語単位(形態素)で分割し、それぞれの品詞などを解析する作業です。名詞となることはわかると思います。あとはこのキーワードをうまくユーザガイドの検索ワードとして投げてあげるだけ。Comprehendというサービスがありました。APIという似たようなサービスがあるそうです。Googleさんなら日本語にも対応しているし安心かな。Apiでの解析ちゃんと日本語も解析できてるようです。あとはコスト面が気になるので確認することにしました。Apiはユニット単位の課金らしいです。使用量は「ユニット」の数に基づいて計算されます。ユニットの複数ユニットとしてカウントされます。ユニットとして課金されます。機能とその機能を使用して評価されたユニットの数に基づいて、月単位で計算されます。ユニットあたりの料金を示します。1000文字ごとに1ユニットが消費され、最低でも1回のリクエストで1ユニットが消費されるそうです。通常チャットで質問する時には短文であることが多いため、これでは費用対効果が悪いと判断しました。このAPI、そこそこの長さの分を構文解析する時には有用だけど、今回みたいな短文向きではなさそうです(料金的な意味で)。最後に以前Androidの開発の時にふと見つけたKuromojiというライブラリを思い出してnodeモジュールがないか探してみることに。最近はなんでもありますね。Kuromojiによる解析これなら日本語にも対応してくれてるし、料金も利用したLambdaのリソース分しかかからないので、(Lambdaの利用料金は実行時間と消費したメモリの量に依存するため)残念なコードを書かない限り料金も抑えれそうです。以下今回の調査のまとめです。・精度自体はAWSよりいいと思う。・日本語で利用できる機能が少ない。・名詞を分割して解析するので自分でどこまでがまとまった単語なのか判定するロジックを追加する必要がある。APIで検索を行う時、通常の質問形式や複数キーワードを投げても適切な回答が得られないという話をしました。これは{domain}/wp-json/wp/v2/posts/?search="キーワード"のクエリで検索した時に、完全一致で検索しようとするため、投稿のタイトルや本文内に質問文と同じものがなければ検索結果に出てこないことが原因でした。ユーザの質問文に含まれるキーワードが必ずしもユーザガイドに含まれないこともあります。「トークの一覧」という言い方をする人と「トークのリスト」という人がいる場合にユーザガイド内の言い方が「トークの一覧」だったとすると後者の検索で「リスト」というキーワードに一致しなくなります。このような揺らぎを少しでもなくすために、ある程度予測される表現については別途「タグ」として管理することにし、「タグ」による検索を行えるようにしました。{domain}/wp-json/wp/v2/posts/?filter[tag]="キーワード1,キーワード2..."こうすることでかなりの期待したものに近い結果が得られるようになりました。あとは細かいロジックの調整(連続する名詞を1つの単語として検索する、一致するキーワードが多い記事を優先して表示するなど)をして完成(?)と相成りました。関係のない機能を説明しているわけではないのですが、本来ユーザーが調べたい機能以外のことが多く存在していると、欲しい回答を探す手間が発生します。回答の書かれたURLを教えてもらってもその回答がすぐにはわからないとストレスになってしまいますね。これは当社のユーザーガイド作成の至らない点です。今後はユーザーガイドの改善もしながらボットの改善を目指して行けるようにも動いていきたいと思います。いつの日か、このボットが皆さんの前に現れてくれることを願います。6.おわりに今回の記事では、以前作成した「キーワードに一致する記事のURLを返却するボット」へのリクエストフォーマットを改善してより意味のあるURLを返すようにするための取り組みについて記載しました。内容としてはあまり専門的なものではなかったですが、結局はこういう地道なことの積み重ねでUXがよくなるのかなとも思っています。次回はいい加減Androidについて記事を書きたいなと思いますので、その時は改めてよろしくお願いします。APIKuromoji我々ワウテック技術開発部はこのような環境で開発をしています。興味を持った方がいらっしゃればいつでもご連絡下さい。WowTalkのAndroid開発担当している岡野です。今回はAndroidと全く関係ないのですが、AWSのサービスを使ってWowTalkのユーザサポート用のボットを作って1週間で社内リリースした話を書いていこうと思います。作ろうと思ったのかWowTalkには電話やメールでのサポート窓口というものがあるですが、ここに来る問い合わせ件数を減らせないかというのがそもそもの始まりでした。WowTalkには操作説明が載っているユーザーサイトもあるのですが、せっかくWowTalkには自分でカスタマイズできるボット機能と、WowTalkにメッセージを送信できるOpenAPIもあるのでそれをうまく利用したいと考えました。今回は検証も兼ねて、社内からの問い合わせに対応できるよう社内公開しましたが、最終的にはユーザの皆様に公開し、利用していただけるようなボットを提供できればと考えています。サーバー立てずに実装したいWowTalkは裏側でAWSを使っているのですが、今回は機能上EC2でインスタンスを立てる必要もないと判断したためAPIGateWayとLambdaを使うことにしました。インスタンスを立てないことに伴いLambdaの設定を工夫する必要がありました。IPアドレスがない問題WowTalkのOpenAPIの利用にはセキュアアクセスのためアクセス元にIPアドレスが必要ですが、LambdaはサーバーレスなFaaSサービスのためIPアドレスがありません。するかというと、OpenAPIと同じサブネットにLambdaを設置することで対応しました。OpenAPIは社内で検証を行うことがしばしばあるので、同じサービスネットワーク内からのアクセスは許可されています。Lambda関数のVPC設定から、WowTalkのインスタンス群と同じサブネットに配置することでOpenAPIの呼び出しを行えるようにしました。Lambda関数のコンソールからVPCの設定をする5.Lamdaから外部へアクセスできない問題ただこれだけでは不十分で、今度はLambdaからユーザーサイトにアクセスできなくなりました。GateWayを設定していないため外部ネットワークとのアクセスができず、ドメイン解決ができなくなるので当然と言えば当然なのですが(汗)これはRoute53のプライベートホストゾーン設定にユーザーサイトへアクセスするためのレコードセットを設定することで解決しました。OpenAPIのサーバーへのアクセスも同様に通常のドメイン設定ではアクセスできなくなったので合わせて設定することで対応しました。6.回答しようここまでできたらあとは裏側の処理をnode.jsでガリガリ書くだけです。シンプルにキーワードに関連する記事のURLをボットのそれっぽく返却するだけにしました。回答が制限を超える場合は別のメッセージとして送信するようにする。}こうして記事のURLを返却するボットを無事(?)社内リリースしました。APIへの検索方法も改善しないと使い物にならないな〜」となりました。そちらについてはまた今後追記していきたいと思います。おわりに今回の記事では(ボットのクオリティはさておき)お手製のサポートボットをリリースするまでを簡単に追いました。タイトルにもある通り、AWSのサーバーレスアーキテクチャを利用すると、アーキテクチャを考えてから社内リリースするまで1週間という短期間で実装ができました。EC2でインスタンスを立てると利用していないリソースにまで料金が発生したり負荷が高くなった時のスケーリングとかリソースの配分なども考えないといけませんが、そこを考慮しなくて済むのは魅力的です。Androidアプリ開発する傍ら、サービスがもっと使いやすくなるような機能の模索もしていきたいと思います。Frameworkの使い方まとめServerlessでLambdaをVPC内にデプロイする我々ワウテック技術開発部はこのような環境で開発をしています。興味を持った方がいらっしゃればいつでもご連絡下さい。JavaScriptこんにちは。Web開発チームの島根です。今回のテーマはReactとCodeIgniterでのWebアプリケーション開発です。Laravel使った方が楽なのでしょうが、現在動いている他のシステムでCodeIgniterが使われているので今回やったことを他のシステムに流用できるようCodeIgniterを選択しました。やったことはと言えば、要はReactをビルドして作られたindex.htmlと同じことをCodeIginterのviewで行うということだけです。2点ほどつまづいてしまいました。1.create-react-appでreactプロジェクトを作ったのでビルドする度にファイル名が変わるこれは、create-react-appで作ったreacctプロジェクトでは、webpackの設定でビルド時にファイル名にハッシュ値を含むようにしてあります。ejectすればconfigファイルを設定できるようですが戻せなくなるため、今回はbuildした後にできるasset-manifest.jsonからファイル名を読み込むという方法をとりました。読み込みたいのは・main..chunk.js・.chunk.js・main..chunk.css・.chunk.cssの4つのファイルです。$filePaths);}}file_get_contentsでasset-manifest.jsonからファイル名のマッピング情報を取って正規表現で各ファイルを判断してます。main.jsとmain.cssはキーが固定なのでキーで判断し、残り2つは正規表現で判断。main.jsとmain.cssもchunk.jsやchunk.cssで終わるのでキーの名前ではじいています。(力技)こうしておけばビルドしたらCodeIgniter側から読み取れるフォルダにasset-manifest.jsonとjsファイルとcssファイルを移動すれば読み取れるようになります。ファイル移動の部分はshell書いてもいいですし、デプロイ時のフローに入れてもいいですし簡単に自動化できると思います。src="<?=$CHUNK_JS?>"></script></body></html>2.BrowserRouteを使うとページを読み込めない。これに関してはエラーが出なかったため困りました。jsやcssのファイルが読み込めていないわけでもなく、コンソールやサーバー側のログファイルにも気になるエラーは何もなし。Toolで調べたところ、Component自体が読み込めていない様子でした。rootの中が空なので一番トップのBrowserRouterがきちんとルーティングできていなかった。HashRouteに変えればちゃんと表示されました。簡単に書いておきます。codeigniter・reactやCodeIgniterでコードを書く。ReactのRouterにはHashRouterを使う。・buildしてCodeIgniter側にソースコードを移動。・CodeIgniterのトップページでbuildしたreactのソースコードを読み込めるようにする。index.html内に直接書かれているscriptをコピペする。おまけ最後におまけですが、Storybookというコンポーネントをカタログにして共有できるツールも入れました。コンポーネントごとにPropsやコンポーネント自体の説明を書けたり渡す値を変えたりできるaddonがあったりしてすごくいいです。Storybookはまだまだ活用しきれていないので熟した頃に投稿させてもらいます。はてなブログProWowTechエンジニアによる開発ブログです。社内チャットツールWowTalkの開発をしています。読者になるSERCHLINKはてなブログブログをはじめる週刊はてなブログはてなブログProNEW駆け出しエンジニア1年目で学んだ3つのことペアプログラミングを試してみた2020年もワウテックをよろしくお願いします大きなActivityは小さく分割したほうがいいお話1週間で作って社内リリースしたヘルプボットを性能改善した話ARCHIVEスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。