エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

【翻訳】JavaScript Visualizer

経緯

目に止まって、内容見たら、新しい発見があったので、残す

元記事

JavaScript Visualizer - DEV Community

翻訳

DeepL翻訳より

もしあなたがJavaScriptがどのように動作するかに興味があるなら、私はこのオンラインJavaScriptツールをお勧めします、それは実行時のすべてのステップを視覚化します
このサイトの定義済みプリセットを読み込むだけで、または自分のコードをコピー&ペーストして、実行のステップを見ることができます 。
それは完全に無料です。以下をクリックして試してみてください。

感想・雑記など

リンク先のやつは、jsのプロセスの実行内容が、ビジュアライズされたツールのようだった。
開発で利用してるソースを貼るのは無理だが、ローカルでも動かせるっぽいので、準備できればローカルでも使えそう。

サンプル試していて気づいたのは、setTimeoutの実行タイミングが、思ってたのと違った。
promiseのやつもだけど。
setTimeoutは、一連の処理が終わった後にタスクが組まれるという事実を、初めて知った。
なんとなく、該当行を実行したときに、時間の計測が始まるのだと思っていたが、違うらしい。。。

jsの非同期系の処理は、あらためて、鬼門だと思いました。

実行タイミングに引っかかったら、これを使ってみるのもありかもしれない。

【日本語訳&検証】Gson, Moshi, Jackson

書くに至った経緯

Gson, Moshi, Jackson - DEV Community

↑のタイトル見て、Moshiって何だ?ってなったので、調べた。

とりあえず記事の日本語訳

deepl使ったけど、文化の違いか、意味の分からんところは意訳か省いてる。
あと、不要だなって思った文章も省いて簡略化している。

Gson, Moshi, Jackson

JSON Parserは、レスポンスをデータオブジェクトにデシリアライズしたり、情報オブジェクトをリクエストにシリアライズするために使用されます。

Gson

最も広く使われているのは、GoogleAndroidJSON Parserパッケージ。
Gson Javaパッケージを使って、JavaオブジェクトをJSON表現に変換することができる。また、JSONの文字列を対応するJavaオブジェクトに変換するために使うこともできます。

  • Gsonは、Googleが運営する特定の標準に準拠した標準ライブラリです。
  • 効率的 このJava標準ライブラリの追加は、信頼性が高く、迅速で、効率的です。
  • 最適化の強化がなされている。
  • ジェネリックのサポート ジェネリックのサポートが充実しています。
  • 大規模な継承階層や、複雑な内部クラスを持つオブジェクトをサポートします。

今後のGson

  • 使いやすい - Gson APIは、よく使われるユースケースを簡略化するための高レベルなファサードを提供します。
  • マッピングを作成する必要がない - Gson APIは、シリアライズされるオブジェクトのほとんどについて、デフォルトのマッピングを提供します。
  • パフォーマンス - Gsonは、比較的高速で、メモリフットプリントが小さい。大規模なオブジェクト・グラフやシステムに適しています。
  • クリーンなJSON - Gsonは、読みやすい、すっきりとコンパクトなJSONの結果を作成します。
  • 依存性がない - Gsonライブラリは、JDK以外の他のライブラリを必要としません。-オープンソース - Gsonライブラリは、オープンソースであり、自由に利用することができます。

Jackson

Jacksonパーサーは、JSONPやGSONのような他の一般的なパーシングライブラリと比較して、優れたパーシング速度を持っています。 Jackson には、JSON ファイルを解析してカスタム Java オブジェクトにデシリアライズする Object Mapper クラスが組み込まれています。これは、JavaオブジェクトからJSONを生成することを容易にするものです。

  • Jackson Core(Streaming API) - 低レベルのストリーミング API が定義されており、JSON 固有の実装が含まれています。
  • Jackson Annotations - 標準のJacksonアノテーションが含まれています。
  • Jackson Databind - ストリーミング・パッケージでのデータ・バインディング(およびオブジェクト・シリアライゼーション)のサポートを提供します。
  • フィールドにアノテーションを付けて、特定の JSON キーに対応させることができる機能。Jackson を使用すると、Java オブジェクトのフィールドにアノテーションを付けて、特定の JSON ドキュメントのキーに対応させることができます。その結果、複雑な JSON ドキュメントでの作業が大幅に簡素化されました。たとえば、@JsonProperty("name") アノテーションを使用すると、JSON ドキュメント内の "name" キーにマッピングされた Java オブジェクト内のフィールドにアクセスすることができます。
  • POJO(Plain Old Java Objects)とJAXBビーンズ(Java Architecture for XML Binding)です。Jacksonは、JAXBビーンズとPOJOの両方に対応しています。定型的なコードは必要なく、オブジェクトのシリアライズとデシリアライズが可能になりました。
  • さまざまなモジュールが追加機能を提供します。Jacksonには、追加機能を提供するいくつかのモジュールが含まれています。これらのモジュールはすべて、XMLYAML、およびCSV形式をサポートしています。

Moshi

3つのパーサーのうち最も新しい。
Gsonのチームメンバーも関わっている。
GSONと比較すると、Kotlinを意識して書いたという点が光ります。ポリモーフィックアダプタやプライマリTypeアダプタの利用やテスト作成がかなりシンプルになりました。これによって、プロジェクトのコード品質をさらに高めることができるのです。

Moshiは、JacksonやGsonのようなライブラリよりも、パフォーマンスを犠牲にすることなく、より凝縮されたAPIを提供します。その結果、よりテストしやすいコードを設計することができ、アプリへの統合がよりシンプルになります。Android向けの開発など、状況によっては、より少ない依存性で済むことが重要な場合があります。

Moshiは任意のランダムなJava Beanを、他の種類と同じガイドラインに従って値が変換されたJSONオブジェクトに自動的に変換します。これは、Java BeanがJava Bean内で必要なだけ深くシリアライズされることを示します。 その後、Moshi-adaptersの依存関係のおかげで、特定の追加変換ルールにアクセスすることができます。

Enumsアダプタはもう少し堅牢で、JSONから不確かな値を読み込む際のフォールバック値を有効にします。日付の RFC-3339 形式をサポートしています。

検証

github

GitHub - suzaku-tec/JsonSample

一部抜粋するので、本ソースが見たい人は↑

テスト用JSON

{
    "name": "sample json",
    "userInfos": [
        {
            "age": 1,
            "name": "json 1"
        },
// ・・・・
        {
            "age": 500,
            "name": "json 500"
        }
    ]
}

とりあえず、普通の要素とリスト要素(500件)を持つものを生成。
本来なら、たぶん、深いネストのjsonを用意するのが正しい気がするが、テストデータを生成する気力が分かんかった。。。

計測

     // Gson
        Gson gson = new Gson();
        startTime = System.currentTimeMillis();
        GsonCompany gsonCompany = gson.fromJson(json, GsonCompany.class);
        System.out.println("gson:" + gsonCompany);
        endTime = System.currentTimeMillis();
        System.out.println("処理時間:" + (endTime - startTime) + " ms");

        // Jackson
        ObjectMapper mapper = new ObjectMapper();
        startTime = System.currentTimeMillis();
        JacksonCompany jacksonCompany = mapper.readValue(json, JacksonCompany.class);
        System.out.println("jackson:" + jacksonCompany);
        endTime = System.currentTimeMillis();
        System.out.println("処理時間:" + (endTime - startTime) + " ms");

        // Moshi
        Moshi moshi = new Moshi.Builder().build();
        JsonAdapter<MoshiCompany> jsonAdapter = moshi.adapter(MoshiCompany.class);
        startTime = System.currentTimeMillis();
        MoshiCompany moshiCompany = jsonAdapter.fromJson(json);
        System.out.println("moshi:" + moshiCompany);
        endTime = System.currentTimeMillis();
        System.out.println("処理時間:" + (endTime - startTime) + " ms");

各ライブラリを利用してjsonjava objectにマッピングさせている。
必要なオブジェクト生成で差が出そうだったので、単純に変換させるところだけ計測

処理時間:22 ms
処理時間:70 ms
処理時間:14 ms

上から、gson/jackson/moshi

jacksonが時間かかってるようにみえるけど、パフォーマンス計測的に、あまり信用できる方法でやってないので、もっと検証に時間をかければ、より差分は見えてきそう。
どっちかというと、利用方法に着目していたので、今回は深掘りはあまりしない。

使ってみて思ったこと

gsonは、知ってたけど、使ったこと無かった。
比較的、シンプルに書けて柔軟性が高い感じた。
private変数に入れられるので、lombok使った環境とかにも導入しやすいのかと思った。
ただ、俺はlombokアンチ民なので、メリットを感じないが。

jackson/moshiは、private変数には入れられないけど、publicになっていれば入れられるので、gsonからjackson/moshiに移行する場合は、変数のアクセス範囲には注意する必要がると感じた。
jackson -> moshiは、オブジェクトのデータ構造の変更の必要がないので、比較的楽に移行できそうだと感じた。逆もしかり。
アノテーションで柔軟性を広げているので、移行するときは、そこに注意が必要そう。

余談だが、moshiを maven repositoryで探した際、moshiがなぜかscope=runtimeになっていて、実装しているときに"なぜ使えないんだ?"ってすごく迷った。
なぜruntimeになっているんだ?

参考

Gson, Moshi, Jackson - DEV Community

Jackson使い方メモ - Qiita

gsonの使い方 - Qiita

【Java】JJUG CCC 2022 Spring参加報告

公式サイト

JJUG CCC 2022 Spring

参加セッション

  • 開発者にやさしく、柔軟性、安全性を高めたGithub ActionsベースのCI/CDを構築する
  • Java で作るカスタム GitHub Actions

参加理由

ネタ探し&恒例行事のため

感想

メモ書き程度です。。。

開発者にやさしく、柔軟性、安全性を高めたGithub ActionsベースのCI/CDを構築する

  • CI/CDのタスク→なるべく小さなタスクに分割する
    • 必要な作業のみしたい場合に対応しやすくなる
  • actions/cache → ライブラリのダウンロード短縮ができる
  • flyway → DBマイグレツール。springと相性がいい
  • デプロイの効率化→デグレ確認・テスト作業の時間確保がしやすくなる
  • 環境ごとのブランチ→テストしたものが本番にあがっているのか判断しにくい。
    • 早い開発をしていくと、ネックになっていた。

Java で作るカスタム GitHub Actions

  • カスタムアクションは、そこまで面倒ではない
  • 好きな言語で作成できる
  • 他タスクと連携しやすいように、引数で挙動制御できるようにする
  • 文字列の扱いが煩雑になることは、なるべく辞める

「サポート」は製品開発? - JDBCライブラリ屋さんが実践する攻めのテクニカルサポートとJavaエンジニアのキャリアについて -

  • 質問をニーズと捉える
  • サポートできるシナリオを増やす

サポートにネガティブなイメージが多いのは、障害対応と同じ作業をするイメージが多いから。
バグ修正でいい思い出がある人って少ないと思うんだよね。。。
しかも、間違いを公然の場で指摘されるから、辛そうってイメージがあるんだと思う。

APIをラップしてSQLライクにアクセスできるってわけか。。。
ドライバの問題、利用するサービスのAPIの問題とか、いろいろな問題が凝縮されてそう。。。
twitterjdbc経由でデータ取れるんだ。。。

話を来ていて、どっちかというと、プロダクトマネージャーに近い気がした。
組織構造が気になった。

Java初心者が知っておくべきプログラミングのこと

  • 変数の難しさ:再代入とかしてると、それをおいきれてないために分からなくなる
    • ループがない→変数の再代入がない→状態保持しない→理解しやすい
  • オブジェクト志向:過度な適用をして難易度を上げている

過度な適用をしている例は結構ある。無駄なsetter/getterがそのいい例。
プログラミングが難しいと思われるのは、いろいろな問題が複合しているのを細分化できずに苦戦して、解決できる前に挫折する人が多いからだと思う。

  • readcode
    • in/outでなんとなく読める
    • 短い時間でやれる

AtCodeは、前に挑戦したことあるんだけど、入力した内容が全部消えてやる気がゼロになった

脱二重メンテナンス!ドキュメント自動生成への道

  • openAPI
    • swagger = openAPIのツールセットの一つ
  • テーブル定義書:schemaspy
    • DBからメタ情報を読み込んでドキュメント生成

swaggerって、結構簡単に導入できるんだな。
実際に動いているものからドキュメントを生成するのが、今の流行りなんだと思いました。

挙動が分からないときは、ソース見ろってことですね。。。

Javaのビルドやバージョンの違いをグラフデータベースで理解する。移行で困らないための知識グラフを作ろう。

あんまり利用用途がピンと来てない。

テストコードの注入から始めるレガシーコードのリファクタリング

  • テストはいっぺんに全部かかない
  • カバレッジを確認しながら進める
    • 100%を目指すのではなく、通っているところをリファクタリングする、通ってないところを通すテストケースを書くために利用する。
  • テストの目的を理解し、不要・重複するテストケースは削除する
  • モックはなるべく使わない。前提を間違うとテストも間違える。使うなら前提条件の確認もする

テストコードは、IntelliJだとTestMe使って、Mockito+JUnit5で作ると楽
実際の業務に耐えられるものかは知らないが、個人でやるレベルでは、問題ない。

テストクラスのメソッドに日本語入れるのは、賛成派。
半角全角の切り替えが面倒だから、あんまり使わないのが現状だけどね。。。

気になったもの

  • flayway
  • actions/cache
  • readcode

あとで調べるか。。。

感想

そう言えば、マイクロサービスってワードが頻出しなくなったな。
バズワードでは無くなったのだろう。

セッション聞いても、なかなか質問ってし辛い。。。
経験を聞くだけだと、「へぇ~」になってしまいがちなのをなんとかしたいと思ってる。
バカの壁が超えられてないなぁ~と個人的に感じている。
知識がないわけじゃないんだけど、たぶん、当事者意識が、今は低いのだろうと感じた。

アンカンファレンスの方に言ってみるべきだったかもしれないとは、後々思った。

【ネタ】SoftwareDesign2022年06月号 SE用語集の感想

書くに至った経緯

ゆるい記事があってもいいかなと思い、感想をつらつらと書きたくなったから。

不思議の国のSE用語

気になったものを一部抜粋

確かに、業界用語化しているから、初めての人は分からんだろうなと思う。

動詞編

渡す/わたす

これは、よくに言う。
語源は、たぶん、変数を箱として捉えるように言われて、そのイメージを言語化した結果、「渡す」になったんだと思う。

配る/くばる

最近は、言わない気がする。
どっちかというと、俺は、バラ撒くとか言う。
配ると同じだけど、バラ撒くの方が富豪になれた気がして気分がいい。

立てる/たてる

たぶん、「立てる」のイメージは「建てる」の方が合ってる気がする。
主にサーバーに対して使うけど、サーバー=インフラで、インフラ整備=建築から「建てる」って呼び回しが増えたんだと思う。

食べる/たべる

使った記憶がない。
どっちかというと、インポート/エクスポートって言う。

舐める/なめる

使ってる人は、見たことあるけど、俺は使ったことないな。
たぶん、50代以降の人しか使ってないと思う。
嫌らしい意味に聞こえるのは、僕だけでしょうか?

名詞編

ほげ

サンプルコードでしか見たことない。
言っている人って居るの??

ポンチ絵/ぽんちえ

聞いたことがない。
いい間違えそうなんで、たぶん、使うことはないだろう。

マサカリ/まさかり

イベントに出るようになって知った。
語源が分からんのだが、投げるのなら手裏剣の方がよくない?

形容詞編

しこしこ

セクハラで訴えられそうだから、使わない。
使ってる人をみたことあるけど、これも50代前後の人だけだと思う。

そもそも、しこしこって思いつく時点で、何かを狙ってるよね。

ペコペコ

使ってる人みたことないのだが、居るのか??
兎田ぺこらの狂信者しか使わないと思うぺこ!

Pekora Ch. 兎田ぺこら - YouTube

会議ワード編

運用でカバー

面倒くさいからシステム化対象外にしようぜって意味

理解理解

おっさんしか使わないイメージ
俺は使わない。
逆に、2度言う事で理解してないという印象を受けるのだが、俺だけ?

一瞬だけ

一瞬じゃない

正直ベース

実態を聞き出すための枕詞

感想

アジェンダってないんだ。。。
最初聞いたとき、意味わからんかったのだが。

他のやつも見てるけど、おっさんが使いそうなワードがいっぱいあった。
俺は使ったことないワードが多い。
どっちかというと、SIer業界で年のいった人が使ってそうな言葉が多い。
そのうち淘汰されていくと思う。

【翻訳】The 6 key questions I ask when reviewing code

元記事

The 6 key questions I ask when reviewing code - DEV Community

経緯

ちょっと興味を惹かれたので、翻訳してみた

要点

コードレビューでするべき質問・確認すべき内容

  1. 変更理由の説明
  2. 変更内容の副作用の検証(要求以外の挙動をしないかの検証)
  3. 影響範囲
  4. エンドユーザー・運用者からの視点
  5. いつ実行されるか?
  6. 要件がすべて満たされているか?

指摘は、否定的なものになりがち。
肯定的なコメントを残せるなら残す。

感想

書かれると当然だが、文章化してみたことは、ほとんどないなと思った。

業務をやっていって、なんとなく覚えたけど、初学者は分からんだろうなと思う。
対面あり/なしにかかわらず、する側もされる側も、これに注視して説明が必要だろうとは思う。

特に対面だと、レビューイとレビューアで、前提が違っていると、空回りすることが多い。
コーディング規約があるのなら、レビュー規約も作って、円滑にレビューが進むようにすべきだと思いました。

【Java】ジャロ・ウィンクラー距離を試してみる

経緯

RSSリーダーを作っているのだが、登録しているサイトが膨大になり、タイトルからある程度、類似した項目を抽出できないかと調査した。
その結果、ジャロ・ウィンクラー距離にたどり着いたので、とりあえず試してみる。

定義

ジャロ・ウィンクラー距離に最初からたどり着いたわけではなく、レーベンシュタイン距離の方が先にたどり着いた。
ちょっと、判定方法が安易だなと思って、もう少し深く調べたら、ジャロ・ウィンクラー距離にたどり着いたので試してみる

wikipedia

ジャロ・ウィンクラー距離 - Wikipedia

全然意味がわからねぇ。。。
調べた感じ、文字列を置換・編集して同じ文字列になる距離を測ることで、一致度を判定しているらしい。

実装

今回の環境

Java11
IntelliJ IDEA 2022.1.1 (Community Edition)
Gradle 5.5

build.gradle

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

    // https://mvnrepository.com/artifact/org.apache.lucene/lucene-analyzers-kuromoji
    implementation group: 'org.apache.lucene', name: 'lucene-analyzers-kuromoji', version: '8.11.1'

↑のやつをdependenciesに加えればイケるはず。

サンプル実装

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

public class Test {

  public static void main(String[] args) {
    String str1 = "足なんて飾りです。偉い人にはそれが分からんのです。";
    String str2 = "胸なんて飾りです。男にはそれが分からんのです。";

    JaroWinklerDistance jaro = new JaroWinklerDistance();

    System.out.println(jaro.getDistance(str1, str2));
  }
}

※実装内容に他意はありません。

予防線張っておかないと、今の御時世、怖いからね!

使い方は簡単で、JaroWinklerDistanceってのを生成して、getDistanceメソッドで比較したい文字列を渡すだけ。
それだけで結果が見える。
ジャロ・ウィンクラー距離のアルゴリズムは、最初の頃は知りたいと思ったけど、ソース見てその気は失せた。

実行結果

0.91768116

かなり似てる判定になってますね。

逆に、ガンダム語録を変えて比較してみると

    String str1 = "足なんて飾りです。偉い人にはそれが分からんのです。";
    String str2 = "親父にもぶたれたことないのに!";
0.3777778

ふむ。。。
ちゃんと文章を見ているけど、さすがに、意味や背景は考慮してないな。

所感

できれば、意味を考えて距離計算できるといいんだけどなぁ。。。
たしか、ウィキペディアで該当ページまでたどり着けるまで、どれくらいか判定するサービスが会ったような気がする。
それと組み合わせてみると面白そうだと思った。※やる気はない

あと、いろいろ調べてて思ったけど、ベクトル計算が重要だなと思った。
どのアルゴリズムを見ても、ベクトル計算が必須。
いかに数値に置き換えるかが重要だった。
学生諸君は、ちゃんと数学は勉強したほうがいい。
分からなくても、概要は把握した方がいい。

参考サイト

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

【技術解説】似ている文字列がわかる!レーベンシュタイン距離とジャロ・ウィンクラー距離の計算方法とは - ミエルカAI は、自然言語処理技術を中心とした、RPA開発・サイト改善・流入改善レコメンドエンジンを開発

2022/05/30週 気づきと振り返り 開発環境なんとかなりませんかねぇ。。。

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

ログ調査

結合フェーズに入って、ログを見て、挙動調査しているのだが、マジでハゲそう。。。。

原因が特定できず、ログとにらめっこして、時間だけが溶けていくので、ものすごい焦るんだよね。。。
ある程度、調査しても進展がなかったら、やり方を変える方がいいと学びましたとさ。

開発環境

ビルドが。。。

ビルドが遅すぎる。。。
いらないソース削ったりしてなんとかしてるけど、資材の不整合がおきて実行時にエラーが出たりすると、かなり混乱する。

本来ならば、それを考慮してシステム配置を考えるべきだったが、それを失敗すると、開発効率に甚大な影響があると学びましたとさ。。。。
それが、今後に活きてくるのかは、分からんけど。

Mockito

UnnecessaryStubbingExceptionの発生

使ってないmockがあると、発生するらしい。
最初、それが分からなくて、設定なにか間違ったか凄くコードを疑ってたけど、俺は何も悪くなかったんだ!悪いのは俺の周りの環境!

Java: Mockitoでハマった落とし穴5つとその解決方法 - Qiita

UnnecessaryStubbingException - mockito-core 2.6.5 javadoc

mockito blog: New Mockito API: lenient()