なんか書いていこうぜー .com

Let's write something good

webpacker の loader 設定の変更

2017-10-15
  • Share on Facebook
  • Tweet
  • Add to Pocket

webpacker は以前は install 時にファイルを出力して直接 webpack の設定を変更できたのであるが、現在は webpack の設定を @rails/webpacker という npm package 内にあらかじめ持った loader の設定を load して利用している。

あらかじめ設定されているものをloadするので、使う側は簡単といえば簡単なのであるが、変更を加えようとすると Ruby の世界にないのでオープンクラスほどさっくりといかない。

前提

webpacker 3.0.2, もしくはこれを書いているときの master 8940b2cd8714f666cb4b2a14d5182daa976cfaa6 をもとにしている。

webpack の設定を変更する

config/webpack 以下に js ファイルがあるので、これらをいじって設定を変更する。

% ls -la config/webpack
合計 16K
-rw-r--r-- 1 muryoimpl muryoimpl  93 10月 15 01:57 development.js
-rw-r--r-- 1 muryoimpl muryoimpl 338 10月 15 04:34 environment.js
-rw-r--r-- 1 muryoimpl muryoimpl  93 10月 15 01:57 production.js
-rw-r--r-- 1 muryoimpl muryoimpl  93 10月 15 01:57 test.js

今回は全環境に対して変更を加えるものとして、environment.js に変更を入れる。

environment には、Environment class のインスタンス が入っていて、environment.loaders は webpacker/package/loaders ディレクトリのloaderの設定内容が Map になって格納されている。

それぞれのファイル名が Map の key, loader の rule が value になっているので、それを上書きするなり置換するなりしてあげれば更新されるはず。

例えば↓のような感じ。 TypeScript の tsx を jsx に変換した後の jsx を babel で処理したいと思ってこうしてみた。新しい設定はテキトーな名前の key で反映されたっぽいので特に何も考えてない。

--- a/config/webpack/environment.js
+++ b/config/webpack/environment.js
@@ -1, 3 +1, 8 @@
const { environment } = require('@rails/webpacker')

+const tsloaderConf = { test: /\.(ts)?(\.erb)?$/,  loader: 'ts-loader' }
+const tsxloaderConf = { test: /\.(tsx)?(\.erb)?$/,  loader: 'babel-loader!ts-loader' }
+environment.loaders.set('typescript',  tsloaderConf)
+environment.loaders.set('tsx',  tsxloaderConf)
+
module.exports = environment

とりあえずこれで動いたっぽいのでこのままいくけど、webpacker には loader の設定を merge するような仕組み…はソースみた感じなかった気がするけど、実は公式的な方法があったりする?

作成中のアプリをReact 15 -> 16 にしたときにやったこと

2017-10-09
  • Share on Facebook
  • Tweet
  • Add to Pocket

アプリの開発を再開しようとしたら、JavaScript のテストが動かなくなっていたので直した。 webpacker を使っていて、webpacker自体をアップデートしたら React が 16 に上がってしまったので引きずられて直した、という事案…

このあたり の奮闘記である。

アプリ側には影響なかった

結論からいうと、(アプリ側はまだまだ作成中なのだが、)改修の必要がなかった。

テスト周りがReactのメジャーバージョンアップによっていろいろ影響を受けていたので修正の必要があった。 ちなみにテストは、Jest と Enzyme を使っていて、テストを流すとどうも component のテストでエラーが発生しているようだった。

ちょっと調べて対応したらテストが通るようになったので、記録しておく。

Enzyme のバージョンアップ と adapter の導入

どうも Enzyme の v3 を使わなければならない、かつ、v3 から “adapter” という概念が追加になっているらしい。

React のバージョンが 16 になっているので、その名も “enzyme-adapter-react-16” なる adapter を導入した。Enzyme の README に表があるので、その表にある adapter を導入すればよい。package.json にある Jest の設定に”setupFiles” を追加してテスト実行前に require しておきたいファイルを書いておく。

  "jest": {
     "testMatch": [
       "**/__tests__/**/*.test.js?(x)"
+    ],
+    "setupFiles": [
+      "./app/javascript/__tests__/helpers/setup-test-env.js"
     ]
   },

上の ./app/javascript/__tests__/helpers/setup-test-env.js に以下の記述を追加して、adapter を設定する。

+import Enzyme from 'enzyme'
+import Adapter from 'enzyme-adapter-react-16'
+
+Enzyme.configure({ adapter: new Adapter() })

react-test-renderer のアップデート

テストを流すと以下のエラーが出た。

Cannot find module 'react/lib/React' from 'ReactShallowRenderer.js'
      at Resolver.resolveModule (node_modules/jest-resolve/build/index.js:179:17)
      at Object.<anonymous> (node_modules/react-test-renderer/lib/shallow/ReactShallowRenderer.js:16:13)

“react/lib/React” となっているってことはなんとなーく、React 16 に対応できていないっぽい。バージョン確認したら、15.6.1 だったので yarn upgrade-interactive したら 16.0.0 になってエラーが解消された。

polyfill の導入

React は Map と Set と requestAnimationFrame が必要なので、polyfill の導入がテストでも必須っぽい。 Map と Set は babel-polyfill か core-js で、requestAnimationFrame は raf の polyfill を導入するとよいらしい。

先に Enzyme の adapter を追記したファイルに、polyfill を import する。

+import 'babel-polyfill'
+import 'raf/polyfill'

import Enzyme from 'enzyme'
import Adapter from 'enzyme-adapter-react-16'

まとめ

React を使っていたアプリ側の変更は必要なかったが、テスト周りは影響を受けていたので修正した。 enzyme, enzyme-adapter-react-16, react-test-renderer のアップデート・導入をして、テスト実行前に polyfill と Enzyme の adapter の設定を読み込ませることで解消することができた。

awesome-wm でアプリを指定タグで起動させるために調べた

2017-09-14
  • Share on Facebook
  • Tweet
  • Add to Pocket

指定したタグで起動させるには、下記のように rc.lua に記載すればよい。 以下は、tag1 に Terminator、tag2 にGoogle Chrome、… という風にレイアウトされる。

awful.rules.rules = {
    { rule = { class = "Terminator" },
      properties = { screen = 1, tag = "1" } },
    { rule = { class = "Google-chrome" },
      properties = { screen = 1, tag = "2" } },
    { rule = { class = "Atom" },
      properties = { screen = 1, tag = "3" } },
    { rule = { class = "Franz" },
      properties = { screen = 1, tag = "4" } },
}

で、ここで class に指定する名前が何かわからない。これを知るためには、GitHub にある awesome の 90-FAQ.md にあるように xprop を使う。

yaourt xorg-xprop 等でインストールし、下記のコマンドを打ってclass名を知りたいアプリのウインドウをクリックすると、コンソールに以下のように出力されるので、この WM_CLASS を利用する。

$ xprop WM_CLASS WM_NAME
WM_CLASS(STRING) = "google-chrome", "Google-chrome"
WM_NAME(UTF8_STRING) = "awesome/90-FAQ.md at master · awesomeWM/awesome - Google Chrome"

起動時に上記のlayoutにアプリを配置させるためには、予め起動時にこれらを起動させておく必要がある。 私は以下のようなものを書いて起動させている。ArchWiki の awesome にある Auto プログラム を参考にしている。 English のページはやり方が変わっているので、そちらのほうがよいのかもしれない。

function run_once(prg)
  awful.util.spawn_with_shell("pgrep -u $USER -x " .. prg .. " || (" .. prg .. ")")
end

do
  local cmds =
  {
    "atom",
    "franz-bin",
    "terminator",
    "google-chrome-stable",
  }

  for _,i in pairs(cmds) do
    run_once(i)
  end
end

毎回 Win + R 入力して、かつ、アプリ名入力して Enter、配置のために Win + Shift + 番号 打つの面倒だったからすっきりした。

夏休みに思ったこと

2017-08-21
  • Share on Facebook
  • Tweet
  • Add to Pocket

なんか連休前後に複数の人と会話していて思ったことを書きたい気がしたけど、XP白本にある「完璧にやる」が全てを表しているので書くことがなくなってしまった。

完璧にやる

手を抜くのはそもそも完璧にやってないし(レビューで手を抜いてるのわかるし、レビュー負荷あがってよくないし)、割り当てられた作業についても「それは目的を達成するための最小の手数ですか?本当にそうですか?」って自問して作業していれば無駄をなくして時間あたりの作業としては最大限のことをやっていることになるだろうし。

(プログラマに対して「手を抜く」って表現使うのムズカシイ…怠惰も同じ…サボる・妥協する・なんも考えてないって表現するのが正解なのかな?)

見積もりがだいたいできて、作業が最小の手で実現できていれば、プロジェクトでソコソコ活躍できると思う… さすがに仕事で解決しないといけない問題に対しては真摯に対応しないと信頼貯金が貯まらないので、自分の首締まるだけ

コードが書ける、とは?

会話して気がついたのは、「(プログラマが)コードが書ける」って「仕事ができる」って意味で使っていることがあるってことかな。

アルゴリズムとか言語機能とか、ライブラリの機能を知っている、活用できるっていうのは求められるところなんだけど、仕様を理解するとか、相手が求めている機能を察知するとか、コードが書ける状態までもっていく力 がこの中に含まれている。求められている期間内に ってのを追加する必要があるかもしれない。前者ができていれば、後者は勿論できているよね?というイメージがあると言ってもいいかもしれない。コード書くときには必要になる能力だから。

完璧な詳細設計書が手渡されてあとはそれをコードに落としていくだけ、という作業がどれだけあるの?と言われるとそんな機会はないので、そりゃそうなんだけど、「コードが書ける」という字面にはそういう情報が抜けているような気がした。前提条件化されているので明文化や言語化されることが少ないということかな。

技術があっても仕事できないと仕事こないので、仕事以外でしか活躍できなくなってしまう。技術を評価してもらう土俵まで到達しないことになってしまうので、実際にコードを書くところ以外も鍛えなければならない。勿論、技術も両方鍛えないといけないのだけれども。

終わりに

おっさんがルーキーみたいなこと書いてしまったけど、夏休みがいろいろ思い返すよい機会になった。

Team Geek を読んだ

2017-08-21
  • Share on Facebook
  • Tweet
  • Add to Pocket

以前からよいと聞きつつも読めていなかったので、お休みと移動時間を利用して『Team Geek』を読んだ。

感想

読み終わったときに思ったのは、「よくできてる」ということ。 何らかのプロジェクトに参加しつつチームで作業している場合に感じる、ちょっと面倒な問題が実際に書かれている。開発コミュニティ運営を実際にしている人が実体験を(おそらく読めるようにemoji-sweat_smile)書いてくれているので、「あるある」感を感じる。

「チーム」を作る場合だけではなく、新加入メンバーをルーキーと捉えれば育成の参考にもなるんではなかろうか。

と書いたところで、割と「自分でコミュニティやプロジェクトを進められる」立場から書かれているものだな、と気づく。前述の新加入メンバーやルーキー側の視点からはあまり書かれていないかも。(もしかしたら読み込むと載っているのかもしれないけど…)

ミッションステートメント同様に何回か読んで、初心に戻って現状を見つめなおすお供によいかもしれない。何度も読むタイプの本なのではないかな、と思った。