WebClass R&D Team Blog

平素は弊社製品 WebClass をご利用いただきまして誠にありがとうございます。

WebClass は、2021年7月末リリース予定のバージョンより、推奨ブラウザから
Internet Explorer 11 を除外することとなりましたのでお知らせいたします。
Windows をご利用の場合は Microsoft Edge など他のブラウザでご利用いただきますようお願いいたします。

WebClass のサポートブラウザからの除外について

皆様もご存知のとおり、Microsoft 365もInternet Explorer 11のサポートを
今夏終了することがアナウンスされ、Windows10 の標準ブラウザは Microsoft Edge に切り替わりました。
現在 Internet Explorer は ActiveX などを使用する、レガシーなシステムの互換性維持のために残されてる状況です。

Microsoft 365 アプリの Internet Explorer 11 のサポート終了

このような状況から、今後WebClassは、最新のWeb技術を取り入れたモダンなブラウザをサポート対象とし、
さらなる機能強化とパフォーマンスの向上を目指すことといたしました。
ユーザの皆様のご理解を賜りますようお願い申し上げます。

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 に限らず、JetBrains の IDE なら同様のはずです。

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

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

前提

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

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

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

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

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

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

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

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

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

Merge と Rebase どちらを選ぶか？

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

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

こんにちは。福岡です。

ファイルをアップロードする時、制限されているファイルをアップロードしようとするのはシステムとして負荷もかかるので、できる限り「正しく」使って欲しいところです。一方で、「正しい」とはどんな条件をいうのかユーザが必ずしも認識できていないことはあり得るし、細かく注意書きを書けば書くほど読まれなくなります。そこで、Javascriptを使ってアップロードする前にファイルを検査する方法を探っています。

これは、今日では Javascript から Fie API を使って簡単にできるようになっています。制限サイズを超えていないか、拡張子のレベルで形式が合っているか、くらいはすぐにできます。

例えば以下の資料があります。
https://developer.mozilla.org/ja/docs/Web/API/File/Using_files_from_web_applications

WebClassでも、レポートファイルのアップロードでこれらを使ったチェックをやろうと思ったのがv11.8.2でした。が、問題が見つかって急遽キャンセルしたのがv11.8.2−2でした。

ほとんどの環境で動作していたのですが、Chrome + Android の環境で、Google Drive のファイルを指定してアップロードしようとする際に問題がありました。なぜか、アップロード前にJavascriptでファイルのチェックをすると、アップロードができなくなってしまいます。最近は学生もクラウドドライブ経由でレポート提出することも多いので、余計な混乱の元になりそうだったために元に戻してあります。

この問題は Chromium に報告してあり、現在、再現可能な問題として認識され、より詳細な調査をしよう、というステータスです。

https://bugs.chromium.org/p/chromium/issues/detail?id=1102021

早く治るといいなぁ。