Rails Developers Meetup 特別編 に行って、「あの」伊藤さんとお話をさせていただいた
Rubyを使っている人が調べ物をすると必ず出会うであろう、伊藤淳一（@jnchito ）さんの著書「プロを目指す人のためのRuby入門」出版イベントに行ってきました。
著書はこちら
動機は単純で、物理の伊藤さんがひと目見たかったからです。
自分は伊藤さんの記事と、その視点がとても好きで、そこには以下のような理由があります。
- 文系出身エンジニアだから（自分も文系出身なので）
- 元バンドマンだから（自分も音楽漬けだったことがあるので）
- フルリモートだから（旦那がフルリモートなので）
- 読む人、相手の気持ちを考えているから
- そこに裏付けられた分かりやすさがあるから
などなど。
今日の話で出ていたものもありますが、過去の記事でも取り上げられていたことがあります。
↓文系エンジニアのくだり↓
↓読む人の気持ちを考えるくだり↓
そんな感じで、Qiitaやブログをちょいちょい追っかけていたため、
「おお、本物が見られるのか」という軽いノリで参加してみたのでした。
（リファクタリングコンテストは、前日の深夜2時まで粘って記念参加したけど、全然歯が立たなかった...）
いざ会場に着くと、自分はミーハーなので登壇位置の目の前に陣取りました。笑
乾杯してビール飲んで、ピザ食べて、質問タイムがあって、その後は「分かりやすい技術記事を書くために」「技術書を読む価値」などについての、伊藤さんのありがたい講演がありました。そのあたりはきっと、他の参加者の方が詳しく書いてくださるかな、と思います。
そして、講演の後は「リファクタリングコンテスト」でした。
お題は以下のリポジトリです。
挙手制で、PRの内容を「タケシくん」に語りかけるように説明してください。とのこと。
自分もPR出してみたのですが、他の参加者のPRを見るとあまりにも圧倒的すぎて、挙手は控えていました。
数人「タケシくん」への説明を終えたところで、突然、司会の平野さん（@yoshi_hirano）が、なぜ今回このような形にしたかというと...というお話を始めました。
「もともとは、8月のイベントでやったように、伊藤さんにコードレビューをやってもらおうと思っていました。」
↓8月のイベントはこんな感じだったようです↓
「ところが伊藤さんが、『コードレビューを受けるのがつらくなったときは』という記事を読んで、参加者の方々にコードレビューをしてみてもらいたい、ということで、今回このような形で、みなさんがコードレビューをするという設定になりました」
えっ、ちょっと待って、それ自分の記事では...と思っていたら、
「その記事を書いた、めるさんがここにいらっしゃるということで」
なぜか立ってマイクを持つことになり、伊藤さんと数分間、対談させていただきました。
伊藤さんからも、
「東京に来たら、めるさんと話をしようと思っていました」
とおっしゃっていただけて、控えめに言っても、夢のようでした。
実は、こんな風にツイートしてくださっていたのは存じていて、
僕の記事と同僚の @mah_lab のスライドが載ってた。この記事についてのコメントは・・・うう、ツイッターじゃ収まらない💧
— Junichi Ito (伊藤淳一) (@jnchito) 2017年11月11日
コードレビューを受けるのがつらくなったときは - めるノート https://t.co/EJY0FQISN5
それについて直前の質問タイムで挙手したらちょうど時間切れだった、という偶然がありました。ネタバレしなくてよかったｗ
自分が座っていた位置も関係者席っぽい感じだったのでアレですが、帰り道で話しかけてくださった参加者の方々から、
「あの流れ、前もって言われてたんですよね？」
と何度か言われたのですが、いや、もちろん、まったく言われてませんでした！！！笑
思いがけず、きっと一生忘れないんじゃないか、という機会をいただけて、本当に本当に嬉しかったです。
伊藤さん、平野さん、本当にありがとうございました！
あー、一緒に写真撮ってもらえばよかったな、でもRubyを書いていれば、きっとまた会えるかな。
なんて思いながら、忘れないために書いておきます。
コードレビューを受けるのがつらくなったときは
そういうときがよくあります。
コードレビューがある会社は今が初めてだけど、きっとこれから先もコードレビューがある限りは、なくならない気持ちなんだと思います。
だから、そんなときに振り返れるようなものを残しておきます。
「コードレビュー つらい」でググってみると、はてな匿名ダイアリーのこんな記事が見つかりました。
さすがに、ここまでヒドいケースを経験したことはないし異常だと思ったけれど、以下のくだりは自分の胸にすごく刺さりました。
私はプログラマに向いていないんじゃないかと思う。よいプロダクトを作る上で強い言葉を交えた議論が必要不可欠ならば、それに強いストレスを感じてしまう私はプログラマとして適正がないのでは？
刺さったのですが、それでも自分はここでやっていかなくちゃならないと思っているので、つらくなったときにいつでも読み返せるよう、見つけた記事・資料をまとめておきます。
www.slideshare.net
ソニックガーデンの方です。
7つの秘訣は、
- レビューの観点を明確にすること
- 我が身に返ることを恐れずに指摘すること
- 何故悪いコードなのかを論理的に説明すること
- 良いコードについて共通認識を持つこと
- 小さい単位でレビューを繰り返すこと
- 指摘は素直な気持ちで受け入れること
- 指摘は人格否定でないことを理解すること
レビューを受ける立場として、6と7は「あっ、そうだよな」と自身の未熟さに気づいたところがありました。
一方で、1や4のような、共通認識とか、前提としての観点っていうのもあまり明確でないことがあるので、それは自分からある程度提示したり、問題提起したりで改善できそうです。
ペパボの方で、新卒のメンバーに向けてお話されたそう。「コードレビューのやり方」な話です。
勉強会などでよくペパボの方を見かけますが、ほんと、いい会社なんだなあ、という感じがします。
印象に残ったところだけ、かいつまんでしまいますが、
（主に新卒など駆け出しのエンジニアが）コードレビューをやる上で大切なのは、コードを読んで理解することだそうで、
- なんでこうなっているのか？を考えながらコードを読む
- わからないところがあると悩む
- 10分悩んだら自分ではわからないと判断して聞く
この「なんで・悩む・聞く」を繰り返すとできるようになる、とのことでした。
あとはコードレビューは「伝え方が9割」ということで
- 理由を書く
- 褒める
- 提案する
- 提案にも理由を書く
- コードで示す
ただし、このへんは上級者じゃないと難しいかも？だけど、LGTM画像、絵文字、顔文字で「めでたく」盛り上げることはできるよね、という感じでシメられていました。
ここからは自分の感想になりますが、コードレビューはとてもデリケートだから、レビュアーはいろんなこと意識しないといけないなって思いました。
指摘されたとき、レビューイ側は「じゃあどうすればいいの！」ってなっちゃうとき、ありますもんね。
LGTM画像については、以下の記事でも「叩かれすぎて凹む問題」で取り上げられていました。
http://ogihara-ryo.herokuapp.com/blogs/1
あとは、まあ、やっぱり「悩んだら聞く」ことが大事だなと。
自分もレビュアー側のとき、さっぱり分からずチンプンカンプンだったらレビューイに聞くようにしてます。当たり前ですがｗ
レビュアー側が「聞く」ことは初心者じゃなくても大事だということで、以下の記事でも取り上げられていました。
そして、レビューイ側も「聞く」ことが大事だと、以下の記事で取り上げられていました。
レビューイ側としても「悩んだら聞く」こと、痛いほど、わかっているんですよね。。。
ちょっとしたCSSの設計とか、エラーハンドリングとか、書く前に相談すれば間違いないんですよね。
この記事で良いなって思ったのは「修正対応の有無はハッキリと」のところです。
MUST・THINK・INFO・TRIVIALなど、修正対応の必要性がわかると、自分がレビューイだったら嬉しいなーと思いました！今度やってみよっと。
よーし、いろいろ見てたら楽しくなってきたぞ。
わかるわかる！と読んでいたら、存じている方の2年前の記事でした。
すごい人だなぁ、と思っていたので、誰もが最初はそうなんだな、とも思えて、元気が出ました。笑
変数やクラス名について批判されるのもなんだかセンスがないと言われているようで辛い。
これもあるある！な感じで、こういうものこそ、具体的な提案とその理由がほしいですよね。
この記事くらいちゃんと説明してくれないと、エラーが出たりパフォーマンスに関わる問題じゃないので、センスとか才能の問題なのかな？ってなっちゃって、違うと分かっていても、自分を否定されたような気持ちになっちゃいますよね。
ということで、いくつか記事や資料を挙げてきました。
コードレビューがつらくなっちゃうときは誰しもあるけれど、だからこそ、自分が担当するレビューイにはそんな思いをさせないよう、つらさを胸に刻みながら、精一杯相手のことを思ってレビューしよう、という感じでしょうか。
将来、後輩ができたときには「わかりやすくてやさしいから、あのひとにレビューされたい」って思われたらいいなあ。うん。
船の中で飛行機を間近に見ながらPHPの話ができるイベントを開催しました
嘘は言ってないぞ。嘘は。
お越しいただいたみなさま、本当に本当にありがとうございました。
あの場で初めてお会いした方々も含めて、またみなさまとゆっくりお話できたらな、と思います。
本日で、望月姓としては1歳、わたくし個人としては26歳を迎えました。
去年はいろいろ目標をたてましたが、これからの1年はその延長線上で、ゆっくり目の前のことに取り組めたらな、と思います。
どうぞ、よろしくお願いします。
以下、今日でラストにするので許してくださいw
誕生日の10/12が数日後に迫っているので、ほしいものリストを晒します😊https://t.co/vnt4tQpPHR
— める (@c5meru) 2017年10月8日
Rails × Webpackerで、CoffeeScriptをES2015にリプレースしました
表題のとおりです。
詳しいスライドはこちら
もっと詳しいブログはこちら
最初にサービス側を置き換えて、そのあと管理画面をやったのですが、だいぶ慣れてきました。
とはいえ、スライドの方にも書いたんですが、やっぱり詳しい方がいないと辛いです。
エラーを見るたびに追い詰められる気持ちになります...(´；ω；｀)
この週末が終わればもうちょっと時間に余裕ができると思うので、ちゃんと勉強します！
よかったら以下、ポチってください😊
誕生日の10/12が数日後に迫っているので、ほしいものリストを晒します😊https://t.co/vnt4tQpPHR
— める (@c5meru) 2017年10月8日
一週間のうち4日がエンジニアのイベントでした
10/9に一大イベントを控えていたにもかかわらず、その前週のスケジュールがすごいことになっていました。
まあ、文化祭（？）シーズンだし、しかたない。
HTML5 Confernce 2017打ち上げ
HTML5 Confernce 2017のボランティアスタッフだったので、公式スタッフの方、スピーカーの方、スポンサーの方なども参加する打ち上げに行ってきました。
ぼっち参加だったので、とても不安だったのですが、いろいろな方に声をかけていただいて、たくさん名刺交換もさせていただきました。
お話したみなさま、ありがとうございました。
お話する人の中には、業務でWebの開発をしていなかったり、そもそもエンジニアじゃなかったりする方もいらっしゃって、それでも独学でReact/Reduxやっていたり、当日LTされていたりなどなど、アグレッシブに活動されていて、ほんとうにすごいな、と思いました。脱帽。
毎回バイタリティあふれる方々に出会えるので、来年もボランティアスタッフやりたいなぁ。
PHP Conference 2017
前職ではほんのちょっとPHP（Wordpress, cakePHP, fuelPHP, Laravel, ECCUBE）をやっていたのですが、最近はほぼ触っていません。
今回は勉強というよりは、知っている方々の活躍を見に行った感じになります。笑
スライドと喋りのバランス、スライドのデザインや図の使い方など、慣れている方の発表はとても勉強になりました。
完全にスプラトゥーンのプロだと思っていた知り合いが、お仕事でもプロだということが分かって、いやぁ、天は二物を与えるのだなぁ、と思いました。
かねてより行ってみたいと思っていたイベントだったし、来年は時期的に難しそうなので、行けてよかったです。
全体的に、HTML5カンファレンスよりラフな雰囲気だったかな。LTも自由な感じだったし。筋肉とか、ライザップとか。
タイミングが合う年があれば、LTやってみたいかも？
Gotanda.js #9
今回の会場は、自分が初めて Gotanda.js に参加したときの会場でした。
自分が初めて Gotanda.js に参加した
ということは、自分の人生を大きく変えた場所でもあったりします。まあ、それはおいといて。笑
初めて Gotanda.js に参加したときは、登壇者が話していることが全く分からなくてショックで、でもなんとなく Gotanda.js の雰囲気が好きになったので、懇親会も残ってみました。
そのときに話しかけてくださった方々とは、今も仲良くさせてもらっています。いやはや、ありがとうございます。
あれから1年ちょっと、ほぼ独学ではありますが、自分なりに最近のフロントエンドを勉強してみて、話している内容がだいぶ分かるようになったことが、とても嬉しかったです。
いざ業務とかでやろうとすると、相変わらず実力不足を感じますが、最初に比べたら大きな進歩だな、と思いました(｀・ω・´)笑
Vue.js meetup #5
先述の通り1年ちょっと前から、最近のフロントエンドを知りたいと思っていて、でも身近なところに手がかりがまったくなくて、勉強会に出たり、情報収集をしたりして自分でちょっとずつ書いてみたりしていました。
そのときはReactが流行っていた頃だったのですが、どうもとっつきづらくて困っていたころに、Vue.jsの2系リリースがあったのを覚えています。
それで試しにやってみたら、日本語ドキュメントも充実してるし、とっつきやすそうだし、Single file component すげー！ってなったのでした。
あと、日本のVue.jsを担っている、@kazupon さんを始めとする方々がすごく優しい。これとっても重要です。
（ほんとうは技術や翻訳でも貢献できたらいいのですが、それはもうちょっとあとの話だとして笑）、今すぐなにか貢献できることはないだろうか？と思ったところに、スタッフの募集がかかったので、参加してみたのでした。
前々回は一般枠で参加した Vue.js meetup でしたが、今回はVue.js日本ユーザーグループのスタッフとして参加しました。
特に大きなトラブルもなく、自身も楽しみながら参加することができました。よかったです。
こちらでお話したみなさまも、ありがとうございました。
ということで、ざっと感想をまとめて書きました。
すごく楽しい一週間でした。
よかったら以下、ポチってください😊
誕生日の10/12が数日後に迫っているので、ほしいものリストを晒します😊https://t.co/vnt4tQpPHR
— める (@c5meru) 2017年10月8日
iPhone6Sのまま、SoftbankからIIJmioに切り替えました
携帯代がすごいことになっていたので、今月から切り替えました。
今回は手順だけ、ご紹介します。 流れとしてはこんな感じ。
- ソフトバンクメールが使えなくなるので対策しておく
- 「音声通話パックみおふぉん」を購入
- SIMロックを解除しておく
- Softbankに電話してMNPの予約番号をもらう
- IIJmioのページから申し込みをする
- MNP開通の電話をする
- SIMカードを入れ替えて設定をする
では、ひとつずつ見ていきましょう。
1. ソフトバンクメールが使えなくなるので対策しておく
ソフトバンクメールで連絡をとっている人は、gmailなどの他のアドレスに切り替えてもらいます。
また、ソフトバンクメールで登録をしているツールがあれば変更しておきます。
2. 「音声通話パックみおふぉん」を購入
先に買っておくと申込みがスムーズなので、買っておきます。
Amazonからだと安く買える＋割引がつきます。
3. SIMロックを解除しておく
店頭にいくと有料（3,000円）ですが、My Softbank から手続きをすると無料です。
あとはSIMを入れ替えるだけ、というところまでやっておきます。
4. Softbankに電話してMNPの予約番号をもらう
こちらに電話します。
引き止めるためか、いろいろ言われますが、ひととおりスルーします。
後ほど詳細を確認しますが、このときに、解約するために必要な金額の確認がされると思います。
電話を切ったあとしばらくすると、ショートメールで予約番号が送られてきます。
5. IIJmioのページから申し込みをする
「パッケージをお持ちの方」、「MNPの予約番号をお持ちの方」、という選択肢を選ぶようにしてください。
手続きには、身分証明書の写真データが必要です。
2〜3日で、登録した住所に新しいSIMカードが届きます。
6. MNP開通の電話をする
新しいSIMカードと一緒に、MNP開通をするための電話番号が書いた紙も同封されているので、そこに電話します。
すべて自動音声ですが、9:00〜19:00の受付なので、注意しましょう。
7. SIMカードを入れ替えて設定をする
Wifiがあるところで設定すると、とても楽です。
新しいSIMカードと一緒に、プロファイル設定用のQRコードが届きます。
SIMカードを入れ替えて、開通完了のメールが届いたら、QRコードからプロファイルをインストールします。
以上で手続きは完了です。
解約するのに必要なお金
Softbankを解約するときに、主に注意するべきなのが、
です。
マイソフトバンクから確認できると思うので前もって確認しておくと良いと思います。
自分は更新月でもないし、割賦金もちょっと残っていたので、最終引き落とし日に22,250円+既存の料金をとられます。。。
とはいえ、これまで携帯代がめちゃくちゃ高かった（12,000〜14,000円くらい...）ので、2〜3ヶ月くらいで元がとれる感じになるので、エイヤ！でやっちゃいました。
ちなみに、IIJmioのプランは、音声通話パックのライトスタートプラン（2,220円〜）です。
IIJmioのほうでは初期費用で＋3,000円が初月にかかります。
まとめ
今までau、Softbank、と移ってきましたが、今回は、スキマ時間でポチポチっと手続きを進められるスピード感に感動しました。
プラン変更も手元でできちゃうんだそうです。すごい。電車でアニメ見たくなったら、一時的にプランあげたりするのもいいかも。
もちろん金額についても言うことなしです。
先月あたりから固定費を2万円くらい削っているので、ちょっとラクになるかな、と思います。
家計簿の付け方も前と変えてみたので、節約＆貯金、がんばります！
Rails のフロントエンドについて社内勉強会をした
あまりフロントエンドに詳しい人がいなかったので、自分がたどたどしい資料をつくりました。
流れとしては、
だったのですが、時間が思ったよりなさそうだったし、みんな知ってるかなって思ったので
1. npm, yarn, webpack, browserifyの説明
を端折って進めたのですが、やっぱりあとから戻ることになりました。笑
前提の説明、大事ですもんね…(´・ω・｀)
そのなかで、いちばん困ったのが、
「WebpackとSprocketsってどう違うの？」
という質問でした。
試しにちゃちゃっと調べてみたのですが、あまり細かく比較している情報が見つけられませんでした。。
Sprockets捨てたいのはわかったから、もっと詳しく〜！という感じでした。
Webpackだと、コンパイルできる言語の範囲が広がる感じなんですかねぇ。
なんか、いい情報があったら教えてください。
これは企業のプロジェクトなら当たり前だと思うんですが、Sprockets捨てたい、CoffeeScript捨てたい、というのはモチベーションとしてはいい一方、正当な理由にはできないので、そういう感情だけで動かないようにしたいな、と思っています。
はじめてのLT登壇をした
気がつけば8月も終わりだということに衝撃を受けています。
10月半ばまでは（プライベートの）プロジェクト掛け持ちモードが続きそうで、多忙を極めております、めるです。
最近は仕事でガッツリコード書いているので、プライベートで書きたい欲が低め（というか他が多忙すぎて気力が…）という感じです。
さて、去る8/31(木)、TECHPLAY女子部LT大会にて、生まれて初めてのLT登壇をしました。
わたくしこれまで、1700人の前で楽器を吹いたり、法被で踊ったり、アニメ声で歌ったり、バスタオル姿で立ったりしましたが、人数が少ない方が個人的には緊張するので、LTってすごくハードルが高くて、マサカリが怖かったりもして、なかなか勇気が出ませんでしたが、ようやくやる気になりました。
女子部なのになぜか男気ジャンケンで順番が決められ、わたしは男気でトップバッターをつとめました。
以下、反省点をあげます。
- テーマ選びとTシャツ選びは、まあまあ正解だった
- タイトルの前に名乗ったほうが良かったなぁ
- まわりからのチャチャ（笑）にすごく救われた
- ざっくり原稿作ってきちゃったけど、読む感じになっちゃって裏目に出たかも
- 時間が余った、もうちょっとしゃべれたなぁ
- だから、本題じゃない話も、ちょっとしてもよかったかも
- 女子部だったので、もうちょっと女子っぽいスライドにすればよかった（笑）
- 動いてるスライドとか、iPadProで手書きしたスライドを使っている人がいてすごかった
- もうちょっといろんな人と喋って、感想きいても良かったかな
こんな感じでした。
懇親会や現場の雰囲気はとても和やかでした。
女の子がいっぱいいるところは久しぶりで、どうして良いかわかりませんでした。笑
ひとまず、とても楽しかったし、エンジニアとして一歩前進できたかな？という気がしたので、よかったです。
Ruby(Sinatra)とHerokuでTwitterbotを作るときに、tokenがリポジトリ内に残らないようにした
最近お仕事でしかコードを触っていなかったので、リハビリがてらサクッとできそうなやつを作りました。
表題の方法については、以下の記事をそのまま試しただけなので、ご参照下さい。
http://b0npu.hatenablog.com/entry/2016/06/15/230101
今回、Herokuだけではなく GitHubにもコードを乗っけたかったので、アクセストークンとかをべた書きではなく.envでの管理にしました。
その方法について、備忘録を書きます。
まず、ルートディレクトリに.envを作成します。
中身はこんな感じ。
CONSUMER_KEY="xxxxxxxx" CONSUMER_SECRET="xxxxxxxx" ACCESS_TOKEN_KEY="xxxxxxx" ACCESS_TOKEN_SECRET="xxxxxxxx"
.gitignoreに、忘れずに.envを追加しましょう。
/.bundle /.DS_Store /.env # 追加
Gemfileにdotenvのgemを追加します。
source 'https://rubygems.org' ruby '2.3.0' gem 'sinatra', '1.4.7' gem 'twitter', '5.16.0' gem 'dotenv' # 追加
bundle installします。
$ bundle install
tweet.rbの冒頭に、dotenv関連の記述を追加します。
require 'twitter' require 'dotenv' # 追加 Dotenv.load # 追加
同じファイルで、アクセストークンとかをべた書きしてたところをこんな感じに置き換えます。
config.consumer_key = ENV['CONSUMER_KEY'] config.consumer_secret = ENV['CONSUMER_SECRET'] config.access_token = ENV['ACCESS_TOKEN_KEY'] config.access_token_secret = ENV['ACCESS_TOKEN_SECRET']
これでローカルからの実行であれば動くようになったかと思います。
ところが、Herokuに乗っけると動きません。
なぜなら.envは.gitignoreされているので、git push heroku masterではデプロイされないんですね。
Herokuでは別途、環境変数の設定が必要になります。
ターミナルから
$ heroku config:set CONSUMER_KEY="xxxxxxx" $ heroku config:set CONSUMER_SECRET="xxxxxxxx" $ heroku config:set ACCESS_TOKEN_KEY="xxxxxxx" $ heroku config:set ACCESS_TOKEN_SECRET="xxxxxxxx"
このように設定してあげて下さい（ちょっと面倒…）。
そうすれば、Heroku上でも動かすことが出来ると思います。
Vue.jsで旗揚げゲームを作ってみた
自分の傾向として写経ばっかりしがちなので、たまには自分で考えて作ってみようと思って作りました。
作ったものはこちら。
https://c5meg1012.github.io/vue-flag/
https://github.com/c5meg1012/vue-flag
JavaScriptのフレームワークの話題でよく出てくる、
- componentをどう切るかが難しい
- データをどう持つかが難しい
- どこまで大きくなったらVuex（Redux）を入れれば良いのかが難しい
という感覚を、だいぶ理解できるようになったと共に、そのあたりの甘さが思いっきり出た感じになりました。。
Vuexを入れればApp.vueはほぼ表示に専念できるのかも、と思ったり。
あと、この手のJavaScriptはどうやってテストを書くのだろう、とも思ったり。
そもそも言語問わずテストの書き方自体をあまり知らないので、そこからなのですが。
メソッドの振る舞いを確認すればよいのかしら。これもちゃんと勉強しよう。
それから、デプロイ方法を探して悩みました。
github pagesは、masterブランチでなら/docs配下を公開できるようなんですが、パッと見gh-pagasブランチだとそれができなさそうなので…
herokuでもちょっとだけやってみたのですが、やはり/dist配下を公開するためのsubtree pushでエラーが出て詰まってしまいました(´・ω・｀)
ということで、結局まだデプロイはしていません。
お手軽な方法ないのかな。Firebaseがいいのかなぁ。うーん。
JavaScriptの師匠が欲しくなってきたので、いろいろコードリーディングしてみても良さそうです。
2017/07/17 22:28追記
→github pagesでデプロイできました！
gh-pagasブランチではビルドしたファイルだけにしてあとのファイルは全部消します。
ビルドしたファイルをdistの外に出して、distディレクトリも消して、
index.htmlやビルドしたjsファイルの中で、外部ファイル読んでるところのpathを調整してあげるとうまくいきました。
若干強引ではありますが(^^;)
