GitHub から Potential security vulnerability found という通知が来てた

GitHub の通知欄に「Potential security vulnerability found in the bootstrap dependency」という通知が来てました。クリックしてみるとこんな表示が。

f:id:knt_mr:20180920170710p:plain

package.json脆弱性のある依存パッケージが含まれているからアップデートしなさい、ということらしい。

「Review vulnerable dependency」をクリックすると、Bootstrap に CVE-2018-14041 という脆弱性があることが分かります。

f:id:knt_mr:20180920170719p:plain

初めて知りましたが、GitHub はこういうのを検出してくれるんですね。親切。

で、もともとこのプロジェクトなんですが、学習のためにお試しで作ったもので、かつ、Bootstrap 3 から 4 にアップデートするのがちょっと面倒だったので、今回はそっ閉じしました...。

GitHub - kntmr/bootstrap-vue-mockup

現場からは以上です。

GFUG の「各ベンダーのJDKリリースモデル特集!」に行ってきた #glassfish_jp

先日、GFUG の「各ベンダーのJDKリリースモデル特集!」に行ってきました。簡単に所感をまとめます。

glassfish.doorkeeper.jp

メモから抜粋。

Azul Systems - Your Long Term Java Partner

  • Microsoft は Azul 製品の最初のユーザー
  • Zing
    • Java ランタイム
    • JavaGC やウォームアップの問題を排除
    • パフォーマンスのよさがウリ (HotSpot よりパフォーマンスがいい)
    • ヒープ 8TB までをサポート
    • LLVM ベースの JIT コンパイラ
  • Zulu / Zulu Enterprise
    • Zulu は OpenJDK ビルド
    • Java スタンダードに準拠 (Java SE 認定の100%オープンソース)
    • Enterprise は Zulu + サポート
    • LTS あり
    • 10年以上(!)のサポートあり
  • Zulu Embedded
    • 組み込みや IoT 向け
    • 技術的な違いは Enterprise と違いはない
    • 組み込みの場合は Embedded になる?
  • x86/32ビットOSをサポート
  • 非LTS版 の Mid Term Support あり
  • Java FX はすべてサポート
  • ブラウザのプラグインや Applet はない
  • Azul のサポートは基本的に英語 (日本にエンジニアがいない)

オープンソースで提供される第二のJVM:OpenJ9 VMIBM Javaについて

www.slideshare.net

  • IBM SDK for Java Technology
    • Java SE 仕様に準拠
    • IBM 独自実装の JVM (J9 VM) を含む開発/実行環境
    • サーバーサイドのみ (JavaFX などは含まれない)
  • OpenJ9
  • OpenJDK + OpenJ9
    • OpenJDK (クラスライブラリ) + OpenJ9 (JVM)
    • AdoptOpenJDK や Docker Hub (Dockerイメージ) から入手可能
  • サポート
  • IBM SDK for Java Technology
    • OpenJDK + OpenJ9 ベース + IBM 独自機能
    • 製品同梱で提供
    • 単独入手は Docker イメージのみ
    • IBM SDK for Java 11 は 2025年までサポート
  • 今後、IBMミドルウェアは原則としてDockerイメージで提供していく
  • WebSphere Liberty
    • 軽量/高速なランタイム
    • Open Liberty の商用版
  • OracleIBMバグフィックスは別物か?
    • 原則、Oracle と同期するようにしている
    • 今のところ Oracle からパッチの提供を受けている

今後の Java に関して

  • なぜ半年1回のリリースになったのか
  • IT業界においての3年はとても長い
  • 3年ごとに新しい機能を入れても価値がないかもしれない
  • Java の進化のためにサイクルを早くする
  • モジュール化によって新しい機能を追加しやすくなった
  • Java の開発/提供もアジャイル的に
  • JDK10 から Docker コンテナの対応を強化
    • ヒープのメモリ割り当てや CPU 状況の取得を改善
  • JDK11 では今まで動いてたアプリケーションが動かないかも?
    • Java SE から多くのパッケージが削除される (JAX-WS, JAXB, ...)
    • 依存ライブラリを追加する
    • ユーザー側で対応できるのか製品側の対応を待つ必要があるのかを確認すること
  • カスタム JDK/JRE が作れる

その他

今回の勉強会に合わせて公開された Red Hat さんのエントリ。

nekop.hatenablog.com

あと、Java Champion の公式アナウンス。あとで読む。

ちなみに会社の別チームでは Oracle JDK のサポートを購入するという話になっているところがチラホラ...。他には製品ベンダーの対応を待つ感じですかね。

コミュニケーションの敷居を下げてプロジェクトの雰囲気をよくする

ここ最近よく思うのは、コミュニケーションの敷居が低いとプロジェクトの雰囲気がよくなるなぁ、ということ。

ここで言う『敷居が低い』には2つあって、コミュニケーションが簡単にとれることと、コミュニケーションの内容に親近感 (安心感?) があること。

最近は、Slack などのコラボレーションツールが広く使われるようになりました。メールを使う機会は以前よりずっと少なくなりました。

チャット形式で日常のコミュニケーションをとる場合、メール時代にあったような余計な挨拶文 (「お疲れ様です、○○です。」のような前置き) は不要です。口語で OK だし、絵文字や顔文字を使ってもいいと思います。もちろん、たまには雑談を交わすのも OK です。ノイズが気になるなら専用のチャンネルやルームを用意すればいいわけです。

お堅い現場ではそうはいかないかもですし、モノによりますが、このようなツールを使う環境を用意するのはそれほど難しくはありません。とはいえ、ゆるい雰囲気で使えるかどうかはメンバーの性格やノリによるところが大きいと思います。そんなときは誰かが率先してゆるい雰囲気を作る必要があります。

自分は決してそういうキャラではないのですが (たぶん)、ゆるい雰囲気を作るために、日々、顔文字や絵文字、おもしろ画像を率先してポストする役目をこなすわけです。

de:code 2017 テスト駆動開発の動画の鑑賞会をやってみた

今さらではあるのですが、先日、昨年の de:code 2017 で t_wada さんが公演されていたテスト駆動開発の動画をみんなで鑑賞するという会をやってみました。

とはいえ、実際、de:code 2017 には参加しておらず、この動画も今年の春くらいに初めて見たのですが、内容がとてもよかったので「他のひとたちにも観てもらおう」と思ったのがきっかけです。

内容としては基本的なものかと思います。が、観たことがないという方はぜひ一度ご覧いただければと思います。途中、ライブコーディングのデモで TDD を紹介していますが、時間がない方は前半の概要と最後のまとめだけでも。(ライブコーディングのデモも非常に学びがあります)

大事なポイントとしては以下ですかね。

  • 動作するきれいなコードには2つの道がある
  • TDD のサイクル (Red-Green-Refactor)
  • テストが予想通り落ちることを確かめる
  • 仮実装、三角測量

(ちなみに書籍はこちら > テスト駆動開発)

特に、この 仮実装三角測量 はよく使う手法ですが、TDD に限った話ではないだろうと思います。

例えば、新しいフレームワークやライブラリを試すときに小さいサンプルアプリを作ったりすることがありますが、ゼロからすべてを一気に作るのは難しいので、モックのデータを返したりして、範囲を絞りながら調査を進めると思います。これは TDD の『仮実装』と同じアプローチです。

あと、デバッグするときに、あるパラメータを渡すとこう動作する、別のパラメータを渡すとこう動作する、ということはこのパラメータを渡せばこう動作するだろう、と再現パターンを調べることがあると思います。これは TDD の『三角測量』と同じアプローチです。

おそらく、テスト駆動開発の中で実践している細かいプラクティスは普段からすでにやっていることなのかもしれません。

まとめ

自分も手探りながら テスト駆動開発モドキ を実践してみた中で大事だと考えているのは、テストから考え始めること (テストファースト) です。

テストから考え始めることで、仕様に対してどのように動作するべきか、ということを整理できてシンプルな観点として落とし込めるようになります。テストがシンプルになると、それに対する実装もシンプルになり易いです。これは実践してみて初めて気が付いたことです。

いきなり実装から書き始めるといろいろな条件を1箇所のロジックに詰め込みがちで、あっという間に複雑になります。当然、その実装に対するテストも複雑になります。そして誰もメンテできなくなるわけです。

ちなみに、鑑賞会のあとに参加者で意見交換したところ、やはり気になるのは既存のアプリにテストコードがないときはどうするか、ということ。正直、あとからテストコードを追加するのは非常に難しいと考えています。というか、かけるコストに対して得られるメリットが少ないんではないかと。

こういうときはテストコードは諦めてドキュメントベースでテスト観点を管理する、というのが最近の自分の見解です。

決してテストコードを書くことはマストではないと思います。メンバーのスキルを考慮する必要もあります。大事なのは実装のあるべき姿を最初に整理して何かしらの形で残すことだと思います。もちろんそれが設計の成果物にあたるのかもしれませんが、そのあたりは現場によってさまざまなのかな。

プログラムの複雑さをレゴブロックで例えてみる

上司に説明するときに何かいい例えはないだろうかと考えて、なんとなくレゴブロックの例を思い付きました。主観的な内容ですのであしからず...。


レゴで遊んだことがあるひとには説明不要かと思いますが、レゴにはいろいろな形や色のブロックがあります。例えば、顧客から「とある形のブロックを別の色に変えて欲しい」という要求があったとします。

きちんと設計されていない、いわゆるスパゲッティ状態のプログラムをレゴで例えると、以下のように雑多にブロックが集められているようなイメージです。

f:id:knt_mr:20180823224523j:plain:w400 (https://www.toysrus.co.jp/s/dsg-489487100)

顧客の要求に応えるには、この雑多なブロックの集まりをガサガサとかき分けて特定の形のブロックを探し出す必要があります。実際、このようなプログラムに手を入れるときも感覚としては近いものがあるような気がします。レゴで遊んだことがあるひとには分かるかもしれませんが、狙った形のブロックを探すのって意外と難しいものです。

一方で、割としっかり作ってはあるが、必要以上にかっちり作り過ぎて複雑になっているプログラムをレゴで例えると、以下のようなイメージです。(あくまでも例えです、この画像の建物はきちんと考えられて作られたものと思われます)

f:id:knt_mr:20180823224531j:plain:w400 (https://www.gizmodo.jp/2017/05/lego-minecraft-the-mountain-cave.html)

顧客の要求に応えるには、同じようにガサガサとかき分けるわけにはいかず、まずどのような構造になっているか把握する必要があります。で、目星が付いたら、もとの形を崩さないように手を入れていく必要があります。もしかしたら屋根の部分や外壁の部分をごそっと取り外して中に手を突っ込むこともあるかもしれません。(※ここではリファクタリングの話とかはしません)
実際、このようなプログラムに手を入れるとき、現状を把握するのにとても苦労します。しかも、こういうときに限ってドキュメントがなかったりします...。

まとめ

シンプルがいちばん。シンプルを保つのは簡単ではないが、できる限りシンプルさを保てるように継続的に改善しよう。

Vue.js の日本語ガイドに PR したら英語の勉強になった

v-for に key 属性を指定するときとしないときの違いの一例 - kntmr-blog

これの余談なんですが、v-forkey の仕様を確認しようと思って公式ガイドを読んでたら、なんとなく誤訳かなと思われるものを見つけたので Pull Request を投げてみました。

当初の翻訳はこう。

可能なときはいつでも v-forkey を与えることが推奨されます。これは、繰り返される 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 simpleyou are intentionally relying on the default behavior for performance gains を否定してこれらを 除く ものと解釈しました。

可能なときはいつでも v-forkey を与えることが推奨されます。ただし、繰り返される DOM の内容が単純でない、または性能向上のための標準の動作に意図的に頼らない場合を除きます。

が、この解釈は誤っているとコメントがあり、再度 Pull Request を投げることに。あと、前後の文章を入れ替えてみた。

繰り返される DOM の内容が単純でない場合、または性能向上のための標準の動作に意図的に頼る場合を除いて、可能なときはいつでも v-forkey を与えることが推奨されます。

ただ、これも意味的には誤っていて、最終的にはこの Pull Request で修正していただきました。

繰り返される DOM の内容が単純な場合や、性能向上のために標準の動作に意図的に頼る場合を除いて、可能なときはいつでも v-forkey を与えることが推奨されます。

ようするに、この unless は接続詞ではなく、単純に the iterated DOM content is simple を否定するための前置詞なんですね。確かに DOM が複雑というか処理が重くなりそうなら key を付けずに性能向上を図る方がいいのかもしれません。

結局、話をややこしくするだけになってしまって申し訳ない感じに...。一応、当初の内容から変わるきっかけにはなったので少しは役に立っただろうか。いろいろと勉強になりました。

v-for に key 属性を指定するときとしないときの違いの一例

先日、v-forkey 属性を指定しないことが原因で生じる不具合に遭遇しました。別にたいしたものではなんですが、v-forkey 属性の確認を兼ねて簡単にまとめます。

ただ、最新のバージョンでは key は必須なんですね。

2.2.0 以降で、コンポーネントv-for を使用するとき、key は必須です

リストレンダリング #コンポーネントと v-for - Vue.js

雑なサンプルコードはこちら。

kntmr/playground - GitHub


v-forkey を指定しない状態でリストを描画する。で、リスト内のある要素をクリックするとスタイル (文字色とか) が変わるものとする。

<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-forDOM を使い回しているため と思われる。

で、v-forkey を付ける。

<li v-for="item in items" :key="item.id">

こうすると、DOM の使い回しが回避できるため、あるべきスタイルで描画されるようになる。ちなみに、公式ガイドの key の項には以下のように記載されている。

この標準のモードは効率がいいです。しかしこれは、描画されたリストが子コンポーネントの状態や、一時的な DOM の状態に依存していないときにだけ適しています (例: フォームのインプットの値)。

リストレンダリング #key - Vue.js

というわけで、基本的には性能向上を目的として DOM を使い回す動作になっているようです。(が、安全な方に倒すのであれば、key を付けるのが無難な気がする...)