GitHub の通知欄に「Potential security vulnerability found in the bootstrap dependency」という通知が来てた。クリックしてみるとこんな表示が。
package.json に脆弱性のある依存パッケージが含まれているからアップデートしなさい、ということらしい。
「Review vulnerable dependency」をクリックすると、Bootstrap に CVE-2018-14041 という脆弱性があることが分かります。
初めて知りましたが、GitHub はこういうのを検出してくれるんですね、親切。
で、このプロジェクトなんですが、もともと学習のためにお試しで作ったもので、かつ、Bootstrap 3 から 4 にアップデートするのがちょっと面倒だったので、今回はそっ閉じすることに...。時間があったらアップデートしよう。
GitHub - kntmr/bootstrap-vue-mockup
現場からは以上です。
先日、GFUG の「各ベンダーのJDKリリースモデル特集！」に行ってきました。簡単に所感をまとめます。
メモから抜粋。
www.slideshare.net
「JDK11 早めにおさわりください」 #glassfish_jp
— kntmr (@knt_mr) September 18, 2018
今回の勉強会に合わせて公開された Red Hat さんのエントリ。
あと、Java Champion の公式アナウンス。あとで読む。
Public Service Announcement - Java Is Still Free! We dig into the recent changes for how releases and support of #java will work in the future https://t.co/MSNr3rPjqk
— Java Champions (@Java_Champions) September 17, 2018
ちなみに会社の別チームでは Oracle JDK のサポートを購入するという話になっているところがチラホラ...。他には製品ベンダーの対応を待つ感じですかね。
最近よく思うのは、コミュニケーションの敷居が低くなるとプロジェクトの雰囲気がよくなる、ということ。
ここで言う『敷居が低い』には2つあって、コミュニケーションが簡単にとれることと、その内容に親近感 (安心感？) があること。
ここ数年、Slack などのコラボレーションツールが広く使われるようになり、メールを使う機会は以前よりずっと少なくなりました。
一般的にチャット上のテキストは口語的なものが多いと思われます。また、絵文字や顔文字を使うことで表現豊かなコミュニケーションが手軽にできます。メール時代にあったような挨拶文 (「お疲れ様です、○○です。」のような前置き) を書く必要はありません。チャットはメールよりリアルタイム性に優れているため、コミュニケーションのサイクルが格段に早く感じます。
たまには雑談を交わすのも OK です。ノイズが気になるなら専用のチャンネルやルームを用意すればいいわけです。
お堅い現場ではそうはいかないかもですし、モノによりますが、このようなツールを使う環境を用意するのはそれほど難しくはありません。とはいえ、ゆるい雰囲気で使えるかどうかはメンバーの性格やノリによるところが大きいと思います。そんなときは誰かが率先してゆるい雰囲気を作る必要があります。
自分は決してそういうキャラではないのですが (たぶん)、ゆるい雰囲気を作るために、日々、顔文字や絵文字、おもしろ画像を率先してポストする役目をこなすわけです。
今さらではあるのですが、先日、昨年の de:code 2017 で t_wada さんが公演されていたテスト駆動開発の動画をみんなで鑑賞するという会をやってみました。
今日は de:code2017 のテスト駆動開発の動画をみんなで鑑賞してわいわい意見を述べ合う場をやってみたけど、なかなか有意義な時間になってよかった https://t.co/wOrLq0vUZQ
— kntmr (@knt_mr) September 7, 2018
とはいえ、実際、de:code 2017 には参加しておらず、この動画も今年の春くらいに初めて見たのですが、内容がとてもよかったので「他のひとたちにも観てもらおう」と思ったのがきっかけです。
内容としては基本的なものかと思います。が、観たことがないという方はぜひ一度ご覧いただければと思います。途中、ライブコーディングのデモで TDD を紹介していますが、時間がない方は前半の概要と最後のまとめだけでも。(ライブコーディングのデモも非常に学びがあります)
大事なポイントとしては以下ですかね。
(ちなみに書籍はこちら > テスト駆動開発)
特に、この 仮実装 や 三角測量 はよく使う手法ですが、TDD に限った話ではないだろうと思います。
例えば、新しいフレームワークやライブラリを試すときに小さいサンプルアプリを作ったりすることがありますが、ゼロからすべてを一気に作るのは難しいので、モックのデータを返したりして、範囲を絞りながら調査を進めると思います。これは TDD の『仮実装』と同じアプローチです。
あと、デバッグするときに、あるパラメータを渡すとこう動作する、別のパラメータを渡すとこう動作する、ということはこのパラメータを渡せばこう動作するだろう、と再現パターンを調べることがあると思います。これは TDD の『三角測量』と同じアプローチです。
おそらく、テスト駆動開発の中で実践している細かいプラクティスは普段からすでにやっていることなのかもしれません。
自分も手探りながら テスト駆動開発モドキ を実践してみた中で大事だと考えているのは、テストから考え始めること (テストファースト) です。
テストから考え始めることで、仕様に対してどのように動作するべきか、ということを整理できてシンプルな観点として落とし込めるようになります。テストがシンプルになると、それに対する実装もシンプルになり易いです。これは実践してみて初めて気が付いたことです。
いきなり実装から書き始めるといろいろな条件を1箇所のロジックに詰め込みがちで、あっという間に複雑になります。当然、その実装に対するテストも複雑になります。そして誰もメンテできなくなるわけです。
ちなみに、鑑賞会のあとに参加者で意見交換したところ、やはり気になるのは既存のアプリにテストコードがないときはどうするか、ということ。正直、あとからテストコードを追加するのは非常に難しいと考えています。というか、かけるコストに対して得られるメリットが少ないんではないかと。
こういうときはテストコードは諦めてドキュメントベースでテスト観点を管理する、というのが最近の自分の見解です。
決してテストコードを書くことはマストではないと思います。メンバーのスキルを考慮する必要もあります。大事なのは実装のあるべき姿を最初に整理して何かしらの形で残すことだと思います。もちろんそれが設計の成果物にあたるのかもしれませんが、そのあたりは現場によってさまざまなのかな。
上司に説明するときに何かいい例えはないだろうかと考えて、なんとなくレゴブロックの例を思い付きました。主観的な内容ですのであしからず...。
レゴで遊んだことがあるひとには説明不要かと思いますが、レゴにはいろいろな形や色のブロックがあります。例えば、顧客から「とある形のブロックを別の色に変えて欲しい」という要求があったとします。
きちんと設計されていない、いわゆるスパゲッティ状態のプログラムをレゴで例えると、以下のように雑多にブロックが集められているようなイメージです。
(https://www.toysrus.co.jp/s/dsg-489487100)
顧客の要求に応えるには、この雑多なブロックの集まりをガサガサとかき分けて特定の形のブロックを探し出す必要があります。実際、このようなプログラムに手を入れるときも感覚としては近いものがあるような気がします。レゴで遊んだことがあるひとには分かるかもしれませんが、狙った形のブロックを探すのって意外と難しいものです。
一方で、割としっかり作ってはあるが、必要以上にかっちり作り過ぎて複雑になっているプログラムをレゴで例えると、以下のようなイメージです。(あくまでも例えです、この画像の建物はきちんと考えられて作られたものと思われます)
(https://www.gizmodo.jp/2017/05/lego-minecraft-the-mountain-cave.html)
顧客の要求に応えるには、同じようにガサガサとかき分けるわけにはいかず、まずどのような構造になっているか把握する必要があります。で、目星が付いたら、もとの形を崩さないように手を入れていく必要があります。もしかしたら屋根の部分や外壁の部分をごそっと取り外して中に手を突っ込むこともあるかもしれません。(※ここではリファクタリングの話とかはしません)
実際、このようなプログラムに手を入れるとき、現状を把握するのにとても苦労します。しかも、こういうときに限ってドキュメントがなかったりします...。
シンプルがいちばん。シンプルを保つのは簡単ではないが、できる限りシンプルさを保てるように継続的に改善しよう。
v-for に key 属性を指定するときとしないときの違いの一例 - kntmr-blog
これの余談なんですが、v-for と key の仕様を確認しようと思って公式ガイドを読んでたら、なんとなく誤訳かなと思われるものを見つけたので Pull Request を投げてみました。
当初の翻訳はこう。
可能なときはいつでも
v-forにkeyを与えることが推奨されます。これは、繰り返される DOM の内容が単純でない、または性能向上を標準の動作に意図的に頼っていない場合に限ります。
で、原文はこちら。
It is recommended to provide a key with v-for whenever possible, unless the iterated DOM content is simple, or you are intentionally relying on the default behavior for performance gains.
最初、この unless が接続詞なのかなと思って、それに続く the iterated DOM content is simple と you are intentionally relying on the default behavior for performance gains を否定してこれらを 除く ものと解釈しました。
可能なときはいつでも
v-forにkeyを与えることが推奨されます。ただし、繰り返される DOM の内容が単純でない、または性能向上のための標準の動作に意図的に頼らない場合を除きます。
が、この解釈は誤っているとコメントがあり、再度 Pull Request を投げることに。あと、前後の文章を入れ替えてみた。
繰り返される DOM の内容が単純でない場合、または性能向上のための標準の動作に意図的に頼る場合を除いて、可能なときはいつでも
v-forにkeyを与えることが推奨されます。
ただ、これも意味的には誤っていて、最終的にはこの Pull Request で修正していただきました。
繰り返される DOM の内容が単純な場合や、性能向上のために標準の動作に意図的に頼る場合を除いて、可能なときはいつでも
v-forにkeyを与えることが推奨されます。
ようするに、この unless は接続詞ではなく、単純に the iterated DOM content is simple を否定するための前置詞なんですね。確かに DOM が複雑というか処理が重くなりそうなら key を付けずに性能向上を図る方がいいのかもしれません。
結局、話をややこしくするだけになってしまって申し訳ない感じに...。一応、当初の内容から変わるきっかけにはなったので少しは役に立っただろうか。いろいろと勉強になりました。
先日、v-for に key 属性を指定しないことが原因で生じる不具合に遭遇しました。別にたいしたものではなんですが、v-for と key 属性の確認を兼ねて簡単にまとめます。
今日は v-for に :key を指定しないせいで起こる不具合に遭遇した
— kntmr (@knt_mr) 2018年8月7日
ただ、2.2.0 以降のバージョンでは key は必須なんですね。
2.2.0 以降で、コンポーネントで
v-forを使用するとき、keyは必須です
リストレンダリング #コンポーネントと v-for - Vue.js
雑なサンプルコードはこちら。
v-for に key を指定しない状態でリストを描画する。で、リスト内のある要素をクリックするとスタイル (文字色とか) が変わるものとする。
<div> <ul> <li v-for="item in items"> <p class="item" @click="select">{{ item.name }}</p> </li> </ul> <button @click="toggle">Toggle Data</button> </div>
ここで、いずれかの要素をクリックしてスタイルを変更した状態で、リストの要素をすべて入れ替える。(サンプルコードの中ではボタンクリックで items の中身をすべて入れ替えるようにしてあります)
すると、リストの内容は書き変わるが、先ほど変更したスタイルがそのまま残る。これは v-for が DOM を使い回しているため と思われる。
で、v-for に key を付ける。
<li v-for="item in items" :key="item.id">
こうすると、DOM の使い回しが回避できるため、あるべきスタイルで描画されるようになる。ちなみに、公式ガイドの key の項には以下のように記載されている。
この標準のモードは効率がいいです。しかしこれは、描画されたリストが子コンポーネントの状態や、一時的な DOM の状態に依存していないときにだけ適しています (例: フォームのインプットの値)。
というわけで、基本的には性能向上を目的として DOM を使い回す動作になっているようです。(が、安全な方に倒すのであれば、key を付けるのが無難な気がする...)
