"10年の長きに渡り Java の可変長引数を過信していた話"を読んで確認した

etc9.hatenablog.com

恥ずかしながら、自分も過信していたのでこのブログを読んで確認してみた。

public class 可変長引数テスト {
    
    public static void main(String... args) {

        new 可変長引数テスト().method();
        new 可変長引数テスト().method("hello");
        new 可変長引数テスト().method("hello", "world");

        String str = "hello";
        new 可変長引数テスト().method(str);

        str = null;
        new 可変長引数テスト().method(str);

        new 可変長引数テスト().method(null);

        new 可変長引数テスト().method((String) null);

        new 可変長引数テスト().method((String[]) null);

    }

    public void method(String... args) {

        System.out.println("*-*-*-*-*-");

        try {
            for (String string : args) {
                System.out.println(string);
            }
        } catch (NullPointerException e) {
            e.printStackTrace();
        }

    }
}

eclipseだと、

new 可変長引数テスト().method(null);

この行で以下のような警告文が表示される。(java1.7だと以下の文章)

タイプ null の引数は、タイプ 可変長引数テスト からの可変引数メソッド method(String…) の呼び出しに対しては String へ明示的にキャストする必要があります。あるいは、可変引数呼び出しに対しては String へキャストすることもできます

  1. コンパイラがこのような警告を吐く記述はちょっと疑うようにした方がいい。
  2. わかりました、ということでStringに明示的にキャストしても、元の記事にあるようにぬるぽで落ちる。
    nullを明示的に渡したいときはStringにキャストしないといけない。

普段意識したことが無かったので、勉強になった。

数年後の自分がこのブログにたどり着くことが無いといいな。

鹿児島から北海道まで全部の新幹線に乗って移動できるのか

調べてみた。

※参考 新幹線路線図 | nippon.com

鹿児島中央駅
↓ 九州新幹線
博多駅
↓ 山陽新幹線
新大阪駅
↓ 東海道新幹線
名古屋駅
↓ JR特急しらさぎ
金沢駅
↓ 北陸新幹線
高崎駅
↓ 上越新幹線
大宮駅
↓ 東北新幹線
福島駅
↓ 山形新幹線
新庄駅
↓ JR奥羽本線
秋田駅
↓ 秋田新幹線
盛岡駅
↓ 東北新幹線(再)
新青森駅
↓ 北海道新幹線
新函館北斗駅

移動の都合上、名古屋駅から金沢駅と、新庄駅から秋田駅までは新幹線以外のルートになるけど、それ以外は新幹線で頑張れる。

Bic simに乗り換えました

SoftbankVodafoneの時から使っていたのですが、2017年GW中に別れを告げて、Bic simに乗り換えました。

理由はシンプルで、通信費の削減が目的です。

夫婦でiPhoneなので、試算だと一ヶ月につき1万円弱の削減が出来るはず…。しばらく、解約手数料やらなんやらで支払いは増えそうですが、7月以降を楽しみにしたいと思います。

 

我が家は夫が聞こえなくて、妻が聞こえるという家族であることを念頭において、乗り換え時の手順を記録しておきます。

なお、電話番号はそのまま乗り換えたかったのでMNPしました。

契約名義は夫の名義です。

 

Softbankから予約番号を貰う その1

最初は妻に電話して貰い、予約番号を受け取ろうとしましたが、本人確認が出来ない云々で少々揉めてしまいました。

妻が強く言った結果、拙い発音で名乗ることで本人確認が出来た、ということになりましたが、音声だと成りすましが容易ですよね。この辺り、おかしな話だなと思います。

何とか本人確認が出来て、その後のやり取りは妻にやってもらったのですが、契約内容が認識していたのと違ったので電話での予約番号発行はやめて店頭に行くことになりました。

教訓:聞こえない人が名義人の時は素直にお店に足を運んだ方が早い。

 

Softbankから予約番号を貰う その②

というわけで、お店に足を運んで予約番号が欲しい旨伝えます。多少引き止めはありますが、もう決めたんだ!という強い意志を見せればよろしいかと。

店頭だと、契約内容についても詳しく確認出来るので安心です。

店頭では特に聞こえないから困ることもなく、筆談でのやり取りでスムーズに進みました。

 

Bic simに申し込む

ビックカメラ店頭でも、インターネットからでも申し込みが出来るので、どちらのやり方でもよろしいかと。

私は店員さんに質問したい事項も無かったのでインターネットから申し込みしましたが、質問がある時は店頭での方がいいでしょうね。

インターネットで申し込んだら、翌々日にはSIMカートが届きました。

 

④携帯にSIMカードを刺して開通手続き

ここでまた、聞こえないと困る出来事があります。開通させるには指定された電話番号に電話しないといけませんでした。

今回も妻に頼りまして、対応してもらったんですが、自動応答のようなので、トリガーとなる音さえ拾えれば、聞こえない人でも自分で出来るのかも…?

店頭でやる時は別料金らしいのですが、聞こえない人を対象にした、何かサービスがあるといいかもなぁと思いました。

教訓:聞こえない家族だとちょっと厳しいかもしれない。聞こえる知人の助けが必要。

 

⑤その後

メールアドレスの変更は新アドレスから一括で送信しました。アドレス漏洩がないように、送信対象の人は全員BCCで指定しました。

新アドレスは@icloud.comを使っています。

インターネットの速度は現状、不満もありません。YouTubewifi環境でしか見ませんし。

 

⑥まとめ

私自身は慎重に下調べして、メリットとデメリットを確認した上で乗り換えました。

ニュースで格安スマホのトラブルが増えているとも言っていましたので、乗り換える際はじっくり下調べしましょう。

特に、店頭での相談がやりにくくなるので聞こえない人にとってはそこがデメリットになるかと思います。

周りに知識を持つ人がいるから平気平気、という思考を持つ人もいるかと思いますが、その知人は無償で手助けしてくれているだけです。

何かの拍子にトラブルになった時人間関係も含めて困るよ、というのも忘れないようにしたいものです。

 

 

 

"Date and Time API をJDBCで扱ってみる"を読んでDB2を確認した

を読んで、昔DB2で仕事していた身として、DB2の状況が気になったので検証してみた。

環境など

ソース

package example;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.SQLException;
import java.time.LocalDate;

public class localDate {

    public static void main(String[] args) {
        String url = "jdbc:db2://localhost:50000/SAMPLE";
        String user = "xxxx";
        String pass = "xxxx";

        try {
            Class.forName("com.ibm.db2.jcc.DB2Driver");

            Connection con = DriverManager.getConnection(url, user, pass);
    
            PreparedStatement ps = null;

            ps = con.prepareStatement("update sample set ts = ? where id = 'hoge'");
            ps.setObject(1, LocalDate.of(2016, 4, 29));
    
            ps.executeUpdate();

            con.close();

            System.out.println("接続成功");
        } catch (SQLException | ClassNotFoundException e) {
            e.printStackTrace();
        }

    }

}

結果

LocalDateの時点で未対応…?

com.ibm.db2.jcc.am.SqlSyntaxErrorException: [jcc][1091][10824][4.22.29] データ変換が無効です: 要求された変換のパラメーター・インスタンス 2016-04-29 が無効です。 ERRORCODE=-4461, SQLSTATE=42815
    at com.ibm.db2.jcc.am.ld.a(ld.java:810)
    at com.ibm.db2.jcc.am.ld.a(ld.java:66)
    at com.ibm.db2.jcc.am.ld.a(ld.java:116)
    at com.ibm.db2.jcc.am.vp.c(vp.java:2677)
    at com.ibm.db2.jcc.am.vp.setObject(vp.java:2456)
    at example.localDate.main(localDate.java:26)

まとめ

悲しい結論になってしまったのでIBMさんにはぜひとも早めに対応していただきたい。

Doma2のチュートリアルを今更ながらやった #Doma2

この手順通りにやれば出来るのだけど、途中で1分ほどはまったので忘備録として残しておく。
Getting Started — Doma 2.0 ドキュメント
Qiitaに書くほどのものでもないのでブログだけにメモ。

前提

  • Windows10
  • 端末のユーザーが日本語名
  • JDKEclipseは最新

はまったところ

ひな形プロジェクトをcloneしてEclipse 用の設定ファイルを生成して、Eclipseにインポートすると謎のコンパイルエラーが出ている。 f:id:su_zu_ki_1010:20170401094938p:plain

原因

doma.jarへのパスが文字化けしているのが原因。 f:id:su_zu_ki_1010:20170401095024p:plain

対応

文字化けしているパスを選んでEditボタンを押して、正しいパスを指定してあげればよい。 f:id:su_zu_ki_1010:20170401095257p:plain

コンパイルエラーが消えたことが確認できる。 f:id:su_zu_ki_1010:20170401095331p:plain

得られる教訓

  • Javaで遊ぶ端末のユーザー名はマルチバイト文字は避けたほうがいい。
  • コンパイルエラーが出たときはまず、設定を一通り確認してみよう。

テーブル存在チェックはどう書くべきなのか

何でこれを書いたのか

コードレビューしていてちょっともやもやしたので吐きだしてみた。 自分の考えが間違っているかもしれないので、吐きだしてみて意見がもらえたらラッキー、程度。

前提条件

存在チェックはどうあるべきか

単純に存在しなかったら登録、存在したら更新、の時

こちらについては、nullか、そうでないかで処理分岐でよいと思う。

Hoge hoge = dao.getByPrimaryKey(キー);
if(hoge == null) {
    hoge = new Hoge();
    hoge.setXxx(xxx);
    dao.insert(hoge);
} else {
    hoge.setXxx(xxx);
    dao.update(hoge);
}

dao.getByPrimaryKey(キー) の先で呼ばれているSQLはこれ。

select * from hoge where KEY = 'キー'; 

DB反映が絡まないタイミングで重複チェックを行いたいとき

  • パターンA:nullかどうかで判定
Hoge hoge = dao.getByPrimaryKey(キー);
if(hoge == null) {
    return "OK";
} else {
    return "NG";
}
  • パターンB:count(*)を使って判定
if(dao.countByPrimaryKey(キー) == 0) {
    return "OK";
} else {
    return "NG";
}

dao.countByPrimaryKey(キー) の先で呼ばれているSQLはこれ。

select count(*) from hoge where KEY = 'キー'; 

後続処理で使わないオブジェクトがnullかどうか、の判定で使うのはなんだかもやもやする。
存在チェックを行うだけならcount(*)の方が後々の可読性も高いし、DAOだけ読んだ時もこれは存在チェックにしか使われていないなということが一目瞭然。 パターンBの方がコードの意味がわかりやすいのではなかろうか。 既にdaoにgetByPrimaryKey(キー)メソッドが実装されている時はパターンAを使う方が楽だろうし、実際に自分も使ってしまっているが・・・。

COBOLだったら?

IBM社のDB2は、SELECT時にSQLCODEが0だったら該当データ有、-100だったら該当データ無し、それ以外は異常、という判定で統一出来ててわかりやすかった記憶がある。 OracleMySQLPostgreSQLも同様のリターンコードで判定できるのだろうとは思う。

ここまで書いて気づいたこと

今のプロジェクト、何も考えないでパターンAで書いてしまったコードがいっぱいあるなぁ・・・

検証資料の変遷について

最初に

SIerに勤務している自分が今まで作ってきた検証資料の変遷についてまとめてみました。あくまでも私の話なので、皆が皆同じではないです。
あと、検証資料のことをエビデンスという人は嫌いです。なんだよエビデンスって。海老でんす?

入社初期

  • COBOLで書いたバッチプログラムのテストケースはexcelで作られた雛形に記入した。
  • テスト結果は入力ファイル、出力ファイルをダンプ形式で紙に出力し、テスト番号やテスト結果の補足を手書きで記入&マーカーで印をつけて提出する。
  • テストケースとテスト結果はレビュアーのチェックを通過後、お客様チェックまで進む。お客様のチェック結果も戻って来て、OKなら本番リリースが出来る。
  • 社内ではある程度細かく見てもらえていた。
  • 先輩社員はAS400の画面も新規開発、あるいは修正していて、画面のテスト結果はスクリーンキャプチャを紙に出力していた。

入社3年目頃

  • AS400画面をWeb画面に作り変えるプロジェクトに携わる。
  • この時も、提出物は紙だったので諸々印刷する必要があった。この辺りでexcelの図形を使えば強調したいところを強調出来るという発見があり、じわじわとプロジェクトメンバーに手法が広がっていく。
  • データの集計結果確認にもexcelの機能が使えたので、ファイルを複数使うより、シートを複数使ってテスト結果をまとめていくやり方が当たり前のようになっていく。
  • 最初は画面の機能もシンプルだったが、段々複雑なものが求められるようになり、スクリーンキャプチャを取るのが苦痛になってくるのもこの頃。
  • 印刷する必要があったため、印刷時のレイアウトも考慮する必要があったのが辛かった。

入社10年目頃

  • 承認フローのシステム画面が導入されたことに伴い、紙での提出が廃止される。すなわち、印刷時のレイアウトを気にしなくてよくなった。
  • テスト結果に求められる内容は変わらないため、スクリーンキャプチャをペタペタ貼り付ける作業が必要なのは変わらない。
  • ただ、この頃からJUnitも使い始めたのでJUnitの実行結果を貼り付けて終わりに出来る場合もあった。
  • テスト結果の確認は、社内メンバーはレビューフローを明確にしたこともあり、ローテーションでチェック体制が出来ていた。チェックする側は大変だったけど…

現在

  • プロジェクトが変わり、現在のプロジェクトではテスト結果を客先に提出はしていない。(お客様の受入環境があり、そちらで確認していただいている)
  • そのため、テスト結果はかなり簡略化されて作成が楽になった。
  • また、自分で開発、修正してテスト、と全部自分でやるためテスト結果をチェックする人もほぼいないに等しい。
  • ではなぜ作っているのか?と聞かれると、テスト漏れがないかの自己チェックや、あえて資料化することで見落としを減らす、あとは後々担当が変わった時の引き継ぎ資料となればいいな、というのも含まれている。

 

考察

  • 前提として、資料を作る過程で発見できる不具合は間違いなく存在するのでテスト結果は資料に残した方がいいという考え方。
    • 特に、プログラミングを他のところに依頼したときは、テストをちゃんとやったのかの証跡としてどうしても必要になる。
    • バッチプログラムならJUnit等でも対応出来るかもしれないが、画面側はスクリーンショットが無いと証跡として弱い。
  • ただ、不具合ゼロを求め過ぎて、スクリーンキャプチャを大量に取らないといけなくなるのは無駄な仕事を増やすだけ。
  • Excelだと、画面の遷移も静止画になってしまってわかりにくい部分があるので、gifや動画をうまく組み合わせたものが作れるとベストだと思っている。
  • 今はmarkdownで書いて、html化することも出来るのでこの辺りを組み合わせられないかとも思っているが、excelのレイアウト調整のやり易さがそれを邪魔する…。
  • Wordを使えやという意見も散見されるが、Wordはレイアウトの調整がやりにくいのでストレスになるからダメ

私見

  • 資料を見てもらえる人がいないなら、思い切って作るのをやめてしまうのも1つの手だとは思うが、テスト漏れがあった時のリスクも考慮しないといけない。
  • 現場で求められている内容に応じて臨機応変にやりつつ、スクリーンキャプチャの嵐を軽減する方法をこれからも模索していきたい。