Firefox 86

Firefox Desktop Browser 86 が1月26日にリリースされました。

Release notes

Firefox 86 release notes

Firefox 86 release notes for developers

Pickup for WebClass

Total Cookie Protection に Strict Mode が追加された

Cookie を使用したユーザートラッキングを防止するための設定の一つで、ユーザーが任意に設定することで有効になります。Strict Mode でも WebClass の動作に影響ありません。

今後の Firefox のリリースについて

次回のリリースは2021年3月23日に予定されています。

Firefox Release Calendar

その他ブラウザのリリースはこちらにまとめています。

Chrome 88

調査が遅れました。Chrome for Desktop 88 が 1月19日にリリースされています。

Chrome 88 Release note

以下に主な変更点の情報が記載されています。

https://www.chromestatus.com/features/schedule

Pickup for WebClass

target="_black" を指定している場合、 rel="noopener" がデフォルトで指定されているとみなされるようになった

Firefox 79 と同様の変更です。

Flash サポート終了

今後のリリース

次回のリリースは 2021年3月2日 に予定されています。

その他ブラウザのリリースはこちらにまとめています。

Firefox 85

Firefox Desktop Browser 85 が1月26日にリリースされました。

Release notes

Firefox 85 release notes

Firefox 85 release notes for developers

Pickup for WebClass

Adobe Flash のサポート終了

このバージョンから Flash はサポートされなくなります。他の最新ブラウザも軒並みサポートを終了しており、Flash に依存しているコンテンツやシステムを使用している場合は、別の技術に移行しなければなりません。

HTML <menuitem> 要素の廃止

WebClass では使用していないことを確認したため影響ありません。

今後の Firefox のリリースについて

次回のリリースは2021年2月23日に予定されています。

Firefox Release Calendar

その他ブラウザのリリースはこちらにまとめています。

中国の鉄道機関が Flash に依存していたため運営がストップしてしまったというニュースがありました。技術の動向を追い続けないと思わぬタイミングで足元をすくわれかねませんね。

類似レポート検知機能のスコアについて

WebClassでは、レポートの剽窃検知機能として、「類似レポート検知」という機能が用意されています。この機能は、提出されたレポート同士を比較して、それらの類似度をスコアとして表示することができます。

こちらのスコア算出の挙動について不可解な点があると指摘されておりましたので、今回いくつかの観点からスコアの変動について調査しました。

調査方法

  • 同じ文章にスペース・改行を入れた場合と入れない場合を比較
  • 10文字~12,000文字程度の文章をWikipediaから切り抜いて比較に使用
    • 全く違う文章・全く同じ文章それぞれで比較
    • 英語文・日本語文それぞれで比較
    • 同じ文章の繰り返しが含まれる・含まれない文章で比較(引用の多いレポートを想定)

調査結果

  1. スペース・改行はスコアに影響する。
    • 同じ文章でもスペースが抜けるだけで5~10程度スコアが低くなる
  2. テキストの長さによりスコアが変動する。(図1,2)
    • 基本はテキストが長くなるにつれスコアが下がる傾向
    • 極端にテキストが短い場合に、極端にスコアが高く
  3. 全体的に日本語文のほうが、スコアがはっきりする。
    • 違う文章のスコアが低い(図1)
    • 同じ文章のスコアが高い(図2)
  4. 同じ文章を繰り返し使うとスコアが高くなる。(図2 緑線)
    • 重複によるスコアが積み重なる?


      図1: 全く違う文章の比較


      図2: 全く同じ文章の比較

まとめ

今回の調査から、スペースや改行・文の長さ・英語文日本語文などの違いでスコアに5~10程度の変動があることが分かりました。そのため、これらの挙動を把握した上で、あるいはある程度の誤差をご承知の上ご使用されることをおすすめします。また、100文字程度以下の短い文章では異常なスコアが出ることから、この機能に使うレポートは100文字以上になっているものを対象にすることをおすすめします。(レポート課題作成時に「100文字以上」の文字数制限を付けることも可能です。)

今回の結果から、図3の「スコアの目安(旧)」にある「強い剽窃の疑いがあります」のレベルに達するのが、繰り返しが含まれるい場合や極端に文章が短い場合のみであることがかったので、このスコア区分をv11.9.0で図4のように修正しました。スコアが70程度あれば、かなり強い剽窃である可能性があるということをご留意してお使いいただければと思います。


    図3: スコアの目安(旧)


    図4: スコアの目安(新)

PhpStorm で Update Project 時に Merge するか Rebase するか

以下の説明は、PhpStorm に限らず、JetBrains の IDE なら同様のはずです。

PhpStorm で Git プロジェクトを扱っていると、リモートの変更を取得するために、Update Project ボタンを押しますよね。以下のように、Merge incoming changes into the current branchRebase the current branch on top of incoming changes のどちらかを選択しなければなりませんが、意味を知った上で選んでいますか?

Update Project

CLI から Git を使わず、IDE からのみ Git を操作していると、Rebase を知らない人もいるかもしれません。そういった初心者向けに説明します。

前提

コミットログが以下のような状態になっているとします。

ローカル master で一つコミット(一番上)したタイミングです。origin/master からはコミット一つ分進んでいます。

変更を Push する前に、Update Project したい。しかし実は、別の開発者が一つコミットをリモートに Push 済みだったとします。

Update Project 時に Merge ... を選んだ場合

Update Project 時に Merge ... を選んで OK を押しました。コミットツリーは以下のようになります。

Merge

別開発者が行ったリモートのコミットが最後にマージされ、マージコミットが作成されています。

Update Project 時に Rebase ... を選んだ場合

Update Project 時に Rebase ... を選んで OK を押しました。コミットツリーは以下のようになります。

Rebase

自分が最後に行ったコミットが一番後ろに付け足される形になりました。この時、マージコミットは作成されません。Rebase の方がコミットログがシンプルになることが分かると思います。

Merge と Rebase どちらを選ぶか?

コミットログのシンプルさが保たれるのは Rebase です。基本的に Rebase を選んでいいと思っています。

ただ、上記で説明した違いについては知っておくべきです。何か起こった時に対処するには、コミットログから過去を正確に知る必要があります。また、Git 自体の理解も重要です。全ての Git 操作を PhpStorm 上から行うことはできません。特にこの記事に書いてあることを知らなかった方は git rebase コマンドについて知らないことが多いかと思われます。よく使うことになるはずですので、是非調べてみてください。