TypeScript + Webpack 使った時に出たエラーと対処したこと
loaders に loader を指定する時は test
プロパティのパターンで絞り込むこと
html-loader を使おうと思って .html のファイルを require() したら、ts-loader に渡って解釈されてしまったので、絶対つけること。 当たり前っぽいけどこれでハマったので。
ERROR in ./src/component/root-index.html Module build failed: Error: Could not find file: 'C:\msys64\home\tyru\git\scrader\src\component\root-index.html'. at getValidSourceFile (C:\msys64\home\tyru\git\scrader\node_modules\typescript\lib\typescript.js:79277:23) at Object.getEmitOutput (C:\msys64\home\tyru\git\scrader\node_modules\typescript\lib\typescript.js:79644:30) at getEmit (C:\msys64\home\tyru\git\scrader\node_modules\ts-loader\dist\index.js:99:43) at Object.loader (C:\msys64\home\tyru\git\scrader\node_modules\ts-loader\dist\index.js:27:11) @ ./src/component/root-index.ts 11:14-42 @ multi ./src/init.ts ./src/component/root-index.ts ./src/routes.ts
module.exports = { // ... module: { loaders: [ { test: /\.ts$/, // これを必ずつける exclude: /(node_modules)/, loader: 'ts-loader' }, { test: /\.html$/, loader: 'html-loader', query: { minimize: true } } ] } }
「error TS2304: Cannot find name ‘require'」と言われる時は require() の型宣言をしてやること
declare function require(x: string): any;
このような型宣言をしないと、以下のようなエラーが出る。
ERROR in ./src/component/root-index.ts (12,15): error TS2304: Cannot find name 'require'.
以下のような通常の require() をしてる時は必要ないみたいだけど、
import angular = require('angular'); import 'angular-ui-router'; angular.module('scrader', ['ui.router']);
このように式の中?で require() をすると型宣言が必要になる。 正直 TypeScript 力が低すぎてよく分かってない。
// 以下の1行がないとコンパイルエラー!! declare function require(x: string): any; class RootIndex { msg: string; constructor() { this.msg = 'Hello!'; } } angular.module('scrader') .component('rootIndex', { template: require('./root-index.html'), // template: `<div ng-bind='$ctrl.msg'></div>`, controller: [RootIndex] });
WebPack と html-loader 便利すぎる。 Gulp より「コード」っぽい設定を書かずに済むし、loader めっちゃ便利だし、WebPack 大好きになってきた。 require() でコードに事前に*1色々埋め込める仕組みというのが気に入った。
参考記事
- TypeScript と Node.js で hello, world をする http server を作る - あいつの日誌β
- webpackを使い倒す - Thujikun blog
- WebPackを使ってJavaScriptを効率的に書くチュートリアル【入門編】 | 株式会社LIG
- javascript - How to use Webpack with Angular + templateCache? - Stack Overflow
- これで html-loader を知った
Special Thanks
TS の test、最後の $ が抜けてるかな?https://t.co/l9XeEAirN7
— 鳥頭なフレンズ (@kariya_mitsuru) 2017年2月19日
*1:「静的に」と言っていいんだろうか?
私の IT エンジニアとしての原点
エモい話を Twitter で呟いた。 ここら辺の話はHow I Vim のインタビューとかでも話してて、おそらく原点に近い*1部分だと思うので、ブログにも投下してみる。
アラートメールが埋もれる問題はなかなか難しくて、前の職場では朝チェックと称して人力で全てのサーバからの syslog が載ったメールを一行一行見てて、とても自分にはできないと思った。
— tyru (@_tyru_) 2017年2月18日
案の定ミス連発するし、他にも色々あって自分はインフラ業は向いてないと思ったきっかけでもあるけど、メール文面を解析して他への報告メール生成までを自動で作れる SPA(という呼称はまだなかったけど)ツールを作ったらかなり重宝された。現に他の人もちらほらミスしてるのが見つかった。
— tyru (@_tyru_) 2017年2月18日
俺は事務仕事向いてないし要領がほんとに良くないので「なんとなくやる」ってのができない。だから現場との相性はかなり場合によると思う
— tyru (@_tyru_) 2017年2月18日
俺がというより一般的に言って、プログラマに事務仕事させると死ぬ
— tyru (@_tyru_) 2017年2月18日
まぁ、仕事なんていっぱいあるんだよ、というのを転々として思った。転々とできるタイプの業種でほんと良かった
— tyru (@_tyru_) 2017年2月18日
SPA ツール、タブとかも備えたけっこうまともに SPA やってる作りで、「(そもそもプログラマじゃなかったから)開発ツールとかなんも入ってないけどみんなブラウザは入れてるからそれで使えるようにしよう」って感じだった。WSH とかも考えたけどブラウザのが楽だと思った
— tyru (@_tyru_) 2017年2月18日
しかもメールの本文(!)が 5MB とかあるから、時刻でソートして二分探索して固まらないよう高速にできたので結構楽しかったし嬉しかった。高速化は結果に出るから分かりやすくていいよね
— tyru (@_tyru_) 2017年2月18日
あと業務知識が絡んで来るから詳しいことは言えないけど、時刻、ホスト名、メッセージでフィルタリングが柔軟性高く実現できるように、S 式の形の JSON で条件を持って解釈実行したり、その条件の JSON をグラフィカルに作るツールを作ったり楽しかった。
— tyru (@_tyru_) 2017年2月18日
もちろん OR とか AND で階層的にフィルタ条件を作れるやつ。あの2つのツールのおかげであいい経験だって思えてる部分はかなりあるかもしれない。上司も優しい人ばかりだったし、プログラマのが向いてるよ、と言われた時は叱らせてしまってごめんなさいと思ってたのが救われた気分だった
— tyru (@_tyru_) 2017年2月18日
他の現場でもツールは毎回と言っていいほど作ったし、それで帳消しにしようとしてた浅ましい考えはあったかもしれない。ただ、今ではだいぶマシになったとはいえ、人には向き不向きがあり、どんなにがんばっても伸び代の低い部分というのは存在する。絶対に。
— tyru (@_tyru_) 2017年2月18日
だからインフラの人はすごいと思うし事務仕事を淡々とこなす人もすごいと思うし、それを忘れて技術で全部ぶっ壊してやるぜ、ってやり方は自分にはできないし合ってないような気がする(逆にそれをしようとした時は大抵よくない結果になる)。ベンチャーより SI に近い現場の方が合ってる人もいる。
— tyru (@_tyru_) 2017年2月18日
この世は本来草も生えないような地獄で、地獄だったけど、あれこれ努力して笑ってようやく人間らしい生き方ができるようになる。ここまで世界の形を変えた先人に感謝しかない。今だって気を抜いたらどんどん地獄になると思ってる
— tyru (@_tyru_) 2017年2月18日
(←草を生やすと笑うを掛けてうまいこと言ったつもりのドヤ顔の表情)
— tyru (@_tyru_) 2017年2月18日
*1:原点という意味ではその前とその前の前のアルバイトかな
YAMAHAルータ:LAN マップ機能、L2MS、スイッチ制御機能
プライベートブログに書いて、それなりに有用な情報が含まれてるような気がしたので公開しようと思ったけど、気のせいかもしれない。
YAMAHA の技術は世界一ィィィ!!
いいなー。 LAN マップ機能自体は RTX1210 や NVR510 が必要で手持ちがないけど、それさえ揃えば L2MS により RTX810 や SWX2200-8G をスレーブとして管理できる。つまり設定の中央集権化が可能。 いちいちそれぞれの機器にログインして設定とかする必要なし。素晴らしい…
- ASCII.jp:なれる!SE ヤマハ?の歩きかた 第6回
- 【ヤマハ ネットワーク製品の「継承」と「挑戦」】RTX1210がネットワークの司令塔に! 一新・強化されたLANマップ機能を見る - クラウド Watch
というわけで、(RTX1210 は高すぎるので)NVR510 がほしい。
それぞれの機種の特徴とか知っておきたいな。
NVR700W/NVR510製品発表のまとめ - Togetterまとめ
(追記 2017/02/07 1:44)
勘違いしてたかもしれない。 LAN マップ機能がなくても L2MS を用いて配下のスイッチやルーターの制御はできる。 それをするのが「スイッチ制御」機能。
これは手持ちの RTX810 も対応していて、コントローラーとして配下のスイッチを制御できる。 つまり、SWX2200-8G をつないで VLAN の設定を一括管理することは現状の手持ちの機器だけでもできる。
まだ LAN マップ機能とスイッチ制御機能の違いをよく理解していないけど、 スイッチ制御でも一括管理の他にグラフィカルに表示することもできるとか書いてある記事もあった。 ただこれは扱ってるルーターが RTX1200 だからなのかもしれない。
運用が楽なネットワークを構築しよう! (1) 導入・環境構築編 | マイナビニュース
結論から言うと、公式ページの冒頭の概要にかなり明確かつ簡潔に書かれていた。以下に丸ごと引用する。
ヤマハルーターは、スイッチ制御機能に対応したヤマハネットワーク機器を制御して、ヤマハネットワーク機器のポートの状態確認やVLANの設定などを行うことができます。スイッチ制御機能に対応しているヤマハルーターでは、スイッチ制御機能によるヤマハネットワーク機器の確認や設定などを行うことができます。スイッチ制御機能の詳細は「スイッチ制御機能」を参照してください。
LANマップではスイッチ制御機能にさらに機能が追加され、ユーザーによるネットワークの管理と運用をより簡単なものにします。 また、スナップショット機能はネットワーク異常の自動検知や、トラブル発生時の原因究明に役立てることができます。LANマップとスイッチ制御機能の差分点を以下に示します。
用途としては
LANマップをDCラックに導入してポートアサイン表を廃止してみたり、GUI画面から配下スイッチのVLAN設定を一括変更してみたり
ASCII.jp:なれる!SE ヤマハ?の歩きかた 第7回|ヤマハと電撃文庫の異色作『なれる!SE』のスペシャルコラボ!
ということなのだろう。
自分が本当に求めるのはグラフィカルにネットマーク図を表示してくれる機能じゃなくて、一括管理できるスイッチ制御で十分だったことに気が付いた。 欲しいと思っても飛びつかず、しばらく何日か下調べをして本当に助かった。 本当にもう少しで買うところだった。
どうやら L2MS とスイッチ制御機能は一緒で、L2MS が昔はスイッチ制御機能と呼ばれていたということらしい。
L2MS(Layer2 Management Service)とは、ヤマハネットワーク機器をレイヤー2レベルで管理する機能です。(中略)。従来は「スイッチ制御機能」という名称でしたが、対応機種や機能を拡充していく中で、より相応しい名称に変更しました。
上記でこのように書いたが、
まだ LAN マップ機能とスイッチ制御機能の違いをよく理解していないけど、 スイッチ制御でも一括管理の他にグラフィカルに表示することもできるとか書いてある記事もあった。 ただこれは扱ってるルーターが RTX1200 だからなのかもしれない。
スイッチ制御GUIといって、一応 L2MS にも GUI でスレーブの状態を表示したり設定を変更できる機能があるらしい。
「3. L2MSコントローラーWeb GUI対応機能表」では LAN マップ機能との比較までもがかなり詳細に記載されている。