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

Let's write something good

作成中のアプリを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)書いてくれているので、「あるある」感を感じる。

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

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

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

Arch Linux のライブラリアップデート後に Wifi に接続できなくなった場合

2017-07-25
  • Share on Facebook
  • Tweet
  • Add to Pocket

yaourt -Syua とかやっているとたまに急に Wifi が down するときが 2 回発生(2 out)したのでメモ。

結論

ip link して表示された無線LAN デバイス が DOWN している、かつ、rfkill list して Wireless LAN が Soft Blocked: yes の場合は、rfkill unblock wifi すれば直る。

参照: Rfkillによるブロック

追ってみてみる

yaourt -Syua してライブラリアップデートをしながらネットサーフィンしていたら急に「インターネットにつながりません」 そして、デスクトップの無線LANマークが未接続になったことに気がつく。

コンソールで↓のコマンドをうってNICの状態を確認した。

$ ip link

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether f0:d5:bf:68:56:b4 brd ff:ff:ff:ff:ff:ff

2 の状態が DOWN になっている。そこで下記コマンドをうったが状況変わらず。

$ sudo ip link set wlp4s0 up
$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: wlp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000
    link/ether f0:d5:bf:68:56:b4 brd ff:ff:ff:ff:ff:ff

そういえば以前に、rfkill あたりをうって解決した記憶が…ググってみると、Rfkillによるブロック に当たった。 そこで書かれているように rfkill list をうってみる。一箇所 yes になっている箇所がある。

$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
        Soft blocked: no
        Hard blocked: no
1: phy0: Wireless LAN
        Soft blocked: yes
        Hard blocked: no
2: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no

これか…ということで Soft blocked を no に変更する。

$ sudo rfkill unblock wifi
$ rfkill list
0: tpacpi_bluetooth_sw: Bluetooth
        Soft blocked: no
        Hard blocked: no
1: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
2: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no

気がつくと、デスクトップのWifi接続通知が接続済みになっていた。

感想

何故にアップデートしていると rfkill が有効になって Wifi が繋がらなくなるのかわからんけど、急に繋がらなくなった場合はこいつを確認しよう。