【読書ノート】プログラミング作法

きっかけ

どこかでオススメ書籍として紹介されていたから、ぱら見で良さそうだったので購読することに。

まとめも

スタイル

名前

• グローバルには分かりやすい名前を、ローカルには短い名前を
  • 命名の統一性を重視
  • 関数には能動的な名前を
  • 名前は明確に

【個人の感想】
重要そうなところを抜き出したけど、ローカル変数名の命名には、若干反対である。
使っていいのは、慣例的に短いのを使うところだけだと思う。（for文のiとか）
ローカル変数でも、ある程度の分かりやすさは必要だと思う。
スコープ範囲にもよるが、だいたいコードは肥大化するものなので、短すぎる名前をつけて後々公開するようなら、最初から明瞭さを重視した方がいいと思ってる。

式と文

• 構造が分かるようにインデントする
  • インデントがあることで構造が分かりやすくなる
• 自然な形で式を使う
  • 条件式に否定を使うと、間違いが分かりにくくなる
• 括弧を使って曖昧さを解消する
  • 演算子の優先度の迷いを断ち切る
• 複雑な式は分割
  • 演算子が大量にあると、意図が分かりづらくなる
• 明確に書く
  • 小賢いコードを書くやつはド三流
• 副作用に注意

【個人の感想】
俺流に味付けしてまとめた。
小賢いコードを書くやつはド三流 は、なかなかのネーミングだと思ってる。
ハガレンの１話の神父に対して言った降りて来いよド三流から発想を得た。
たまに、小賢しいコードをマジで書くやつが居るから、困ったもんだ。
俺は、学生のときにそうなりかけたけど、小賢しいコードのせいでコードが読みづらいことに気づいて辞めた。

一貫性と慣用句

• インデントとブレースのスタイルを統一する
  • ブレース＝波括弧。ここでいいたいのは、if ~ else で、波括弧の位置をどうするかって意味
• 慣用句を使って一貫性を保つ

【個人の感想】
慣用句って、何をもって慣用句とするのだろうな？
それは、お前の中の常識であって、他の人は違うよ？って言われたら、何を信じていいのか分からなくなりそうな気がしないでもない。
こういうのは考えるのが面倒くさいから、フォーマッタを導入して機械的にやるほうが楽だと思う。

関数マクロ

Cの記述ばっかりだったので、スルー

マジックナンバー

マジックナンバー＝プログラム中に登場する数値

• マジックナンバーには名前をつける
  • 用途を明確にする
• マジックナンバーは定数化

【個人の感想】
マジックナンバーは、マジで有害だから、存在させないようにするほうが吉。
あと、マジックナンバーを定数化するときに、two = 2 みたいに命名するアホを見たときは、絶句した。
定数化する意味がないから、名前のところを読めって言いたくなる。

コメント

• 当たり前のことは書かない
  • プログラムの理解を助長するものを書く
• 関数とグローバルデータにはコメント
• 可読性の悪いコードは、コメントで補完するより書き直す
• コードとの矛盾を避ける

【個人の感想】
日本だと、可読性の悪いコードは、コメントで補完するより書き直す は許されない傾向にある気がする。
必要最低限の改修だけしろとよく言われる。
その流れになったのは、無能なコーダーが上位の役職についているからだと思うんだよね。
もしくは、その可読性最悪のコードの影響を理解していないとか。
どっちにしろ、無能が上にいるってことは変わらないな。

アルゴリズムとデータ構造

• データ量が少ない→単純なテクニックでやる
• データ量が増大する→スケールアップ可能な設計にする
• 高度なテクニックは、実際に計測するまで使わない方が無難

設計と実装

• 設計＝言語によらない

インタフェース

• サービスを提供するコードと、利用するコードの境界にある
• 実装の詳細を隠蔽する
  • 利用者への影響を少なくする
  • 実装の交換が容易になる
• 直行性のある小さな単位を選択する
  • 必要以上の機能を提供するのはＮＧ
    • 管理が面倒になる
    • 使いこなすのが難しくなる
  • 必要十分なものを規定する

デバッグ

• バグを埋め込みやすいパターンを探してみる
• バグ対応は、横展開とセットで
• スタックトレースをよく読み、原因を特定するまでは、修正してはいけない
• 他人に説明してデバック

バグへの対応

• 再現させる
• ログファイルを出力
• UML書いてみる
• printデバッグ

テスト

• デバッグ＝テストではない
  • デバッグ＝コードに問題があるときにすること
  • テスト＝プログラムを破綻させるためにする作業

コーディング時のテスト

• 境界条件テスト
• 実行前後の変化を検証する
• アサーション
• ありえないケースへの対応も考えておく（防御的プログラミング）

系統的なテスト

• テストは１個ずつ段階的にやる
  • ビッグバンテスト→破綻する
• 単純な部品からテストする
  • 複雑な箇所からやると、バグの修正が難しくなる
• 期待値は明確にする

テストの自動化

大量のテストは、注意力が散漫になり、労力もかかる。
テストを自動化して、いつでも気軽に頻繁にテストできるようにすることは、十分に価値がある。

性能

• 測定→検証のサイクルが基本
• ベンチマークの結果は、政治的意図があるので、結果は割り引いて考えておく

移植性

環境に依存することなく動作させる理想のこと

移植性が必要な理由

• 動作環境が決まっていることが少ない
• 環境は変化する
• 移植性があるものは優れたものが多い
  • やりすぎは厳禁

言語

• 標準にこだわる
  • 移植性を高くしてくれる
• 王道プログラミング
  • 専門用語が出てくるのは、王道ではない
  • 確率されたスタイルをなるべく使う
• 言語のトラブルスポットに注意する
  • 演算子の評価順
  • 算術／論理シフト

【個人の感想】
「王」って単語に反応しちゃう

隔離

• システム依存は別ファイルに移動し、インタフェースで隠蔽

データ交換

• なるべくテキスト
  • 扱いやすい
  • 見やすい
  • 手作業で変更可能
  • バイナリ使う際は、固定バイト順にする

移植性とバージョンアップ

• 仕様を変えるなら名前を変える
  • 解釈が変わる→意図的に別のソフトウェアが生まれるようなもの
  • 仕様が変わる＝意図しない移植上の問題が発生する可能性が高い
• 後方互換を維持する
  • 手段が変わる＝影響範囲大
  • 非互換性は、コストと相談

国際化

• 英語を前提にしない
  • 漢字等が入れば、文字サイズも変わる
  • エラーメッセージに業界用語や特定言語のスラングはやめる

感想

ところどころ端折ったが、既存の考えと大筋変わらない。
古典っぽい内容だったな～というのが正直な感想。
リーダブルコードで事足りそうな気がしないでもない。

Angular + electron の環境構築

きっかけ

electronでUIフレームワークで何かいいものないかと探して、react／vueにたどり着いた。
しかし、さっぱり動きが分からない。
理解し難い。
それなら、以前使ったAngularならイケるだろうと思い、調査して、とりあえず連携させるまでできたので晒す。

環境

VisualStudioCodeのバージョン情報で事足りそうだったので、逐一コマンドは打って貼付はしない。

バージョン: 1.38.1 (system setup)
コミット: b37e54c98e1a74ba89e03073e5a3761284e3ffb0
日付: 2019-09-11T13:35:15.005Z
Electron: 4.2.10
Chrome: 69.0.3497.128
Node.js: 10.11.0
V8: 6.9.427.31-electron.0
OS: Windows_NT x64 10.0.18362

実証

流れ

1. angularの実行環境準備
2. electornのインストール
3. main.jsの作成
4. Angularの設定変更
5. 実行スクリプトの準備
6. 実行

angularの実行環境準備

下記のコマンドを実行

npm install @angular/cli -g

プロジェクト毎にインストールメリットを感じなかったので、グローバルインストール。

インストールが終わったら、Angular用のプロジェクトを下記コマンドで作成する。

$ ng new angular-electron-demo

electornのインストール

Angularのもろもろの準備が終わったので、作成したプロジェクトに移動して、electronを入れる。
セキュリティを考慮して最新版を入れたが、何か特定のバージョンに思い入れがあれば、指定する。
※動作確認はしてないので、問題は各自で解決してね。

$ cd angular-electron-demo
$ npm install --save-dev electron@latest

自分の実行環境では、6.0.9が入ってきた

main.jsの作成

プロジェクトディレクトリ直下（package.jsonがあるディレクトリ）に、main.jsを作成する。

中身は、electronのquick-startからパクったやつ。

const { app, BrowserWindow } = require("electron");
const url = require("url");
const path = require("path");

let mainWindow;

function createWindow() {
  mainWindow = new BrowserWindow({
    width: 800,
    height: 600,
    webPreferences: {
      nodeIntegration: true
    }
  });

  mainWindow.loadURL(
    url.format({
      pathname: path.join(__dirname, `/dist/index.html`),
      protocol: "file:",
      slashes: true
    })
  );
  // Open the DevTools.
  mainWindow.webContents.openDevTools();

  mainWindow.on("closed", function() {
    mainWindow = null;
  });
}

app.on("ready", createWindow);

app.on("window-all-closed", function() {
  if (process.platform !== "darwin") app.quit();
});

app.on("activate", function() {
  if (mainWindow === null) createWindow();
});

Angularの設定変更

angular.jsonを開いて、出力先のパスを合わせる。

projects → angular-electron-demo → architect → build → options → outputPath の値を、dist/angular-electron-demo から dist に変える

  "projects": {
    "angular-electron-demo": {
      "projectType": "application",
      "schematics": {},
      "root": "",
      "sourceRoot": "src",
      "prefix": "app",
      "architect": {
        "build": {
          "builder": "@angular-devkit/build-angular:browser",
          "options": {
            "outputPath": "dist",

次に、package.json を開いて、実行するjsファイルを指定する。
"main": "main.js", を追記して終わり。

{
  "name": "angular-electron-demo",
  "version": "0.0.0",
  "main": "main.js",

実行スクリプトの準備

Angularのビルド→electornの実行の順で実行するためのスクリプトを下記の通り追加。
※start:electronを追記する

  "scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "ng lint",
    "e2e": "ng e2e",
    "start:electron": "ng build --base-href ./ && electron ."
  },

実行

さっき追加したスクリプトを下記の通りに実行する。

$ npm run start:electron

そうすると、下記の画面が出てくるはず。

今回のソース

GitHub - suzaku-tec/angular-electron-demo

雑記

react、vueより扱いが簡単だといいな。。。

windows10って、print screen使えなくなった？
キーを叩いてもスクショがとれてなくて、結構、焦った。
snipping toolに移管していくつもりなのだろうか？

参考サイト

Electron with Angular 8|7 Tutorial | Techiediaries

Build Electron Desktop App with Angular 8 | Electron Angular Tutorial

2019/09/09週 気づきと振り返り

業務こなしての問題・気づき

callkit の CXProvideDelegate

すべてのイベントがハンドリングできるわけではない。

CXCallObserverDelegateで監視してやる必要がある。
着信画面の応答・拒否は、CXCallObserverDelegateでしかハンドリングできない。

CXCallObserverDelegate → call（CXProvideに状態の変化を伝えるメソッドを叩く） → CXProvideDelegate の流れがcallkitを開発した人が目論んでる流れだと思う。

stack viewで表示しきれない

stack viewで表示しきれない場合、scrollviewを使って、スクロールで表示できるようにする。

scroll -> stack -> ~ で実装すると、いい感じにできる。
iphone XRだと問題ないのだが、SEで表示ができず、レイアウト配置で相当悩んだ。
逆に考えるんだ、「出せなきゃ出さなきゃいいのさ」と考えて、この対応を考えた。
やっぱり、ジョジョは偉大。

その他雑記

カフェイン

最近分かったが、俺は、どうやらカフェインに過剰反応するらしい。

コーラを飲んだだけで、眠れなくなる。
夕食のときにコーラを飲んでしまうと、２時位まで寝付けないという事象が発生するのが、最近になって分かった。

ちなみに、コーヒーを飲むと、過剰反応で頭痛と下痢になる。
たぶん、血管が収縮して、血液が周りにくくなって酸素が回ってないから頭痛になるんじゃないかと予想。
下痢は、分からん。

腕時計

昔、腕時計を買ったのだが、全然身につける習慣がなくて、もったいないから、最近なるべくつけるようにしている。
そしたら、腕時計を付けたところが青ざめるんですけど、アレルギー反応なのかな？
出社するまでの１時間くらいで、うっすら青ざめてムッチャ怖いんですけど。。。
痒くなるし、変色するし、汗でベタつくから不快なんだよね。。。

仕事中は外してる。
使うのは、資格試験のときの時間確認くらいでしか利用したことがない。

これは、俺にアップルウォッチを買えというお告げなのうだろうか？
スマホは、Androidなんだけど。。。。

また増えた

今週で、とうとう３２歳ですわ。
来年でゾロ目だな。

2019/08/26週 気づきと振り返り

業務こなしての問題・気づき

Swiftのlazy

クラス変数をOptionalにしたくないときに使う。
singletonみたいな使い方ができる。
遅延実行の方が近いかもしれない。

参考サイト

【Swift4.1】lazyプロパティの使い所 - Qiita

【Swift】レイジ―プロパティ（lazy）の使い方。最初にアクセスされたときに初期値が決まる。 | はじはじアプリ体験記

複数人開発でのStoryboardの使い方

複数人で開発する場合、画面ごとに分けたほうがいい。
競合が多くなり、開発効率が悪化するので、人数が増えてきたら考慮の余地がある。

参考サイト

【Xcode】Storyboardを複数に分割して管理する方法 - Qiita

多人数でのiOS開発におけるStoryboardとの向き合い方（１画面１Storyboard） - machio Development Diary

[iOS] チーム開発するなら Storyboard を分割セヨ ｜ DevelopersIO

swiftのtableviewで、storyboardとコードの住み分け

コード回避可能なものは、なるべくコードで定義。
storyboardで何でも解決しようとすると、黒魔術化して、自分があとで分らなくなる。 見た目は、storyboard、ロジックはコードで実装するのが、一番分りやすいと思う。

Java13リリース前の予習（Text Blocks深堀）

きっかけ

前回記事でJava13の調査したけど、後々になってTextBlocksに疑問が湧いてきたので調査した

過去記事は、書きを参照

suzaku-tec.hatenadiary.jp

355: Text Blocks (Preview)

JEP 355: Text Blocks (Preview)

ダブルクォートだけを表示させたらどうなるか？

テストコード

public class Jep355Sample2 {
  public static void main(String[] args) throws Exception {
    String str = """"""";
    System.out.println(str);
  }
}

期待値

「"」だけが表示される。

答え

$ javac --enable-preview --release 13 Jep355Sample2.java 
Jep355Sample2.java:3: エラー: テキスト・ブロックの開始区切り文字のシーケンスが無効です。行の終了文字がありません
    String str = """"""";
                    ^    
Jep355Sample2.java:3: エラー: テキスト・ブロックの開始区切り文字のシーケンスが無効です。行の終了文字がありません
    String str = """"""";
                       ^

コンパイル時に怒られた。。。

Descriptionをよく読むと、The opening delimiter is a sequence of three double quote characters (""") followed by zero or more white spaces followed by a line terminator. とある。

「Google翻訳よ、おらに力を分けてくれ～」と思いながら翻訳すると、「開始区切り文字は、3つの二重引用符（ "" "）の後にゼロ個以上の空白が続き、行終端文字が続くシーケンスです。」となる。

期待値通りの出力をするには、下記に変えると行ける。

public class Jep355Sample2 {
  public static void main(String[] args) throws Exception {
    String str = """ 
    " 
    """;
    System.out.println(str);
  }
}

テキストブロックに\nを入れたらどうなるか？

public class Jep355Sample3 {
  public static void main(String[] args) throws Exception {
    String str = """
    hello\nSaga!!
    """;
    System.out.println(str);
  }
}

何を表示させようかと迷ったら、とりあえず佐賀。

期待値

そのまま、「hello\nSaga!!」が表示される

答え

$ java --enable-preview Jep355Sample3
hello
Saga!!

改行されるだと。。。

Descriptionをよく読むと、たしかになんか書いてある。

The content may include line terminators directly, unlike the characters in a string literal. The use of \n in a text block is permitted, but not necessary or recommended. For example, the text block:

"""
line 1
line 2
line 3
"""

is equivalent to the string literal:

"line 1\nline 2\nline 3\n"

or a concatenation of string literals:

"line 1\n" +
"line 2\n" +
"line 3\n"

If a line terminator is not required at the end of the string, then the closing delimiter can be placed on the last line of content. For example, the text block:

"""
line 1
line 2
line 3"""

is equivalent to the string literal:

"line 1\nline 2\nline 3"

ざっくり読むと、「書くこともできるけど、非推奨」的な感じだと思う。
わざわざ「\n」入れるより、改行したほうが楽だろうってことだろうね。。。

たぶん、ほかのエスケープ系の文字も同様の扱いになっている気がする。

疑問

どこでインデントがきまるの？

    String str = """
    hello Saga!!
    """;

上記の実行結果は、下記になる。

$ java --enable-preview Jep355Sample4
hello Saga!!

本来なら、文字列の前にインデントようの空白があるのだが、なぜか表示されない。
意図通りだからいいんだけど、どういうルールなのか気になった。

さっきよりインデントを増やしたら、どうなるのか試したら、今度は、追加したインデントが表示された。

    String str = """
      hello Saga!!
    """;

$ java --enable-preview Jep355Sample4
  hello Saga!!

インデントの位置は、たぶん、もっともインデントが少ないところがベースになるのだろうと予想。

dependenciesをよく読んでいると、2. Incidental white space に、なんかそれっぽい記述がある。
どうも、インデントの決定は、開始の"""以降の最小のインデントで決まるっぽい。

タブ文字は、１文字とカウントされるっぽいので、インデントに使う文字列を統一してないと、予期せぬレイアウト崩れになりそう。
TextBlocksのところだけインデントが１行ごとに違うとかは、面倒くさいから誰もやらないとは思うが、Javaのユーザ数は多いから、居そうだな。。。

Java13リリース前の予習

書こうと思ったきっかけ

そろそろリリースが近づいて来たので、まとめようと思い一念発起した。
サイト見る限り、最終リリース候補が出てるようなので、もう、大きな変更はないだろうから、キャッチアップしても大丈夫だろうという考えもある。

各種サイトへのリンク

https://openjdk.java.net/projects/jdk/13/

JDK 13 Early-Access Builds

JEP

• 350: Dynamic CDS Archives
• 351: ZGC: Uncommit Unused Memory
• 353: Reimplement the Legacy Socket API
• 354: Switch Expressions (Preview)
• 355: Text Blocks (Preview)

ざっくり読んだ感じ、開発者に影響がありそうなのは、JEP 354／JEP 355

JEP 353も影響ありそうかと思ったけど、内部の実装の変更のようなので、調査対象から外した。
Google翻訳でやってるから、微妙に違うところがあるかも。。。
あと、見てて思ったが、JavaでSocketAPIを直に見るのは、学生のとき以来だなって思った。

354: Switch Expressions (Preview)

簡単に言うと、switchの結果を変数に入れられるようになった。

テストコード

下記の通り、テストコードを作成
java12のやつを流用して作った。

import java.util.Calendar;
import static java.util.Calendar.*;

public class jep354sample {
  public static void main(String[] args) {
    int day = Calendar.getInstance().get(Calendar.DAY_OF_WEEK);
    int numLetters = switch (day) {
      case MONDAY, FRIDAY, SUNDAY -> 6;
      case TUESDAY                -> 7;
      case THURSDAY, SATURDAY     -> 8;
      case WEDNESDAY              -> 9;
      default -> 0;
    };
    
    System.out.println("numLetters:" + numLetters);
  }
}

実行

最初、defaultがない状態でコンパイルしようとしたら、下記の通り、コンパイルエラーになった。

$ javac --enable-preview --release 13 jep354sample.java 
jep354sample.java:7: エラー: switch式がすべての可能な入力値をカバーしていません
    int numLetters = switch (day) {
                     ^
注意:jep354sample.javaはプレビュー言語機能を使用します。
注意:詳細は、-Xlint:previewオプションを指定して再コンパイルしてください。
エラー1個

網羅されてないとエラーになるようになったんだな。。。
それとも、前から？
Java12のときは、エラーにならなかった気がするが、気のせいかな？

本題とはそれるので、とりあえず、コンパイル＆実行

$ javac --enable-preview --release 13 jep354sample.java 
$ java --enable-preview jep354sample
numLetters:8

土曜日なので、SATURDAYだから、8で正解。
どうでもいい話だが、SATURDAYは、一週間が終わったから「去ったデー」って習った。

注目スべきは、switchの戻り値があるところだろう。
これで、ケースに応じて結果を返せるようになった。
個人的には、defualtの挙動の方が驚いた。。。

swiftの画面遷移とかで使うswitchの使い方に近いことができるのではないかと思う。

yield

yieldっていう結果返すワードが追加されたので、試す。

テストコード

public class Jep354YieldSample {
  public static void main(String[] args) {
    String day = "xxx";
    int j = switch (day) {
        case "MONDAY"  -> 0;
        case "TUESDAY" -> 1;
        default      -> {
            int k = day.toString().length();
            System.out.println("default day:" + day);
            int result = f(k);
            yield result;
        }
    };
    
    System.out.println("j:" + j);
  }
  
  private static int f(int k) {
    return k + 10000;
  }
}

実行

実行したら、下記の通り。

$ javac --enable-preview --release 13 Jep354YieldSample.java 
$ java --enable-preview Jep354YieldSample
default day:xxx
j:10003

caseの中で計算が必要なときに使うのだろうけど、必要なのか疑問に感じてしまう。。。
とりあえず、新しい動きなので、覚えておいて損はないだろう。

355: Text Blocks (Preview)

開発者が定義した通りの文字列を定義できる。 エスケープ処理が入るので、開発者は、\nとかを気にしなくていい

テストコード

import javax.script.ScriptEngineManager;
import javax.script.ScriptEngine;

public class Jep355Sample {
  public static void main(String[] args) throws Exception {
    String html = """
              <html>
                  <body>
                      <p>Hello, Saga!!</p>
                  </body>
              </html>
              """;

    System.out.println("== html ==");
    System.out.println(html);
    System.out.println("==========");

    String query = """
               SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`
               WHERE `CITY` = 'INDIANAPOLIS'
               ORDER BY `EMP_ID`, `LAST_NAME`;
               """;

    System.out.println("== sql ==");
    System.out.println(query);
    System.out.println("=========");

    ScriptEngine engine = new ScriptEngineManager().getEngineByName("js");
    Object obj = engine.eval("""
                            function hello() {
                                print('"Hello, Saga!!"');
                            }
                            
                            hello();
                            """);
  }
}

やってるのは、HTMLとSQLの表示、JSの実行。

実行

$ javac --enable-preview --release 13 Jep355Sample.java 
$ java --enable-preview Jep355Sample
== html ==
<html>
    <body>
        <p>Hello, Saga!!</p>
    </body>
</html>

==========
== sql ==
SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`
WHERE `CITY` = 'INDIANAPOLIS'
ORDER BY `EMP_ID`, `LAST_NAME`;

=========
Warning: Nashorn engine is planned to be removed from a future JDK release
"Hello, Saga!!"

エスケープ文字列入れてないのに、ちゃんと改行されて、きれいにHTMLとSQLが出力される。
jsも、エスケープ処理なくても、きちんと実行できて"Hello, Saga!!"が出力される。

簡単なDBアクセスでSQL発行するサンプルを作りたいとか、簡単にできそう。
できれば、文字列の代入もあるといいかなと思う。
いちいちプラスで連結するのは、面倒。
Swiftみたいに、\()で代入できると楽なんだが、対応予定はあるのかな？

感想

355: Text Blocks がとても気になる。
文字列操作がもどかしいことがよくあるので、これからも継続的に改善があると嬉しい。

スケジュール通りに進んでいるようなので、Java13も予定通りリリースされると思う。

luceneで文章の類似性を試す

きっかけ

Javaで文章の類似性を数値化できないか調べたところ、luceneというライブラリで実現可能なようなので、サンプル実装して動かしてみた。

環境

IntelliJ IDEA 2019.2.1 (Community Edition)
Build #IC-192.6262.58, built on August 20, 2019
Runtime version: 11.0.3+12-b304.39 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
GC: ParNew, ConcurrentMarkSweep
Memory: 2002M
Cores: 4
Registry: 
Non-Bundled Plugins: net.seesharpsoft.intellij.plugins.csv

実装

GitHub - suzaku-tec/sample-lucene

githubにコード載せておいたので、適時参照してね。

Gradle dependencies

必要になるのは、下記

    // https://mvnrepository.com/artifact/org.apache.lucene/lucene-core
    compile group: 'org.apache.lucene', name: 'lucene-core', version: '8.2.0'

    // https://mvnrepository.com/artifact/org.apache.lucene/lucene-spellchecker
    compile group: 'org.apache.lucene', name: 'lucene-spellchecker', version: '3.6.2'

今回試す分は、上記だけで大丈夫。

TestBatch.java

import org.apache.lucene.search.spell.JaroWinklerDistance;
import org.apache.lucene.search.spell.LevensteinDistance;

public class TestBatch {

    public static void main(String[] arg) throws Exception {

        String one = "今日の東京は非常に寒いです。でも、天気は快晴ですよ！";
        String two = "今日の京都は非常に暑いです。";

        //1に近いほど似ている
        LevensteinDistance l_algo = new LevensteinDistance();

        JaroWinklerDistance j_algo = new JaroWinklerDistance();

        System.out.println("実行結果(LevensteinDistance):" + l_algo.getDistance(one,two));
        System.out.println("実行結果(JaroWinklerDistance):" + j_algo.getDistance(one,two));

    }

}

やることは、インスタンスを生成して比較するだけ。

実行すると、下記のような表示になるはず。

実行結果(LevensteinDistance):0.42307693
実行結果(JaroWinklerDistance):0.7990983

感想

意外と簡単に試せた。
比較のアルゴリズムが、全然分からないから、調査が必要そう。
たぶんだが、コサイン類似度を使ってるんだろうなって気はする。

タスク

• 類似性チェックのアルゴリズムを調査する

参考サイト

Java で Firebase を使う方法のまとめ。 | ソフトコミュ開発ブログ

2つの文字列がどれだけ類似しているかを判定するレーベンシュタイン距離とジャロ・ウィンクラー距離(Java編) | ぱーくん plus idea