読者です 読者をやめる 読者になる 読者になる

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

何でこれを書いたのか

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

前提条件

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

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

こちらについては、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つの手だとは思うが、テスト漏れがあった時のリスクも考慮しないといけない。
  • 現場で求められている内容に応じて臨機応変にやりつつ、スクリーンキャプチャの嵐を軽減する方法をこれからも模索していきたい。  

「小学生でもわかるプログラミングの世界」を読んだ

「小学生でもわかるプログラミングの世界」という本が気になったので読んでみました。
結論から言うと、前書きで著者が「大人にも楽しんでもらえるように書きました」と仰っている通り、楽しく読める一冊でした。

コンピュータの基礎である、CPUなどのハードウェアの説明から始まり、プログラミングとは何をするのか、どんな言語があるのか、を簡潔にわかりやすくまとめてある本です。
基本情報処理技術者試験を初めて受ける方や、システム開発の会社に入る、それまではプログラミングに全く触れたことがない学生等が初めの第一歩の知識を得るにはちょうどいいのではないでしょうか。

個人的には、プログラマーとはどんな仕事なのかを紹介しているところで書かれていた一文がとっても素晴らしいと思いました。

システムエンジニアプログラマーは別の職種?どっちが偉いの?

という疑問文に対し、

それぞれの協力関係で成り立つからどちらが偉いとか偉くないとかはないよ!

という回答が書かれています。
当たり前のことですが、システム開発はお互いの協力関係の下、成り立つものなので、どちらが偉いとかは関係なく、お互いを尊重しなければなりません。

小学生でもわかる、当たり前のことを大人が分かっていない言動がみられるのは恥ずかしいことではないでしょうか。

関西を代表する凄腕エンジニア、こざけさんもこんなツィートをされていますし。


小学低学年には難しい内容がたくさんですが、高学年なら理解できそうな文章とイラストで描かれているので、お父さんの仕事は何?と聞かれたシステム開発に携わっている人はこの本を読ませればよさそうです。
Excel方眼紙をいじるお仕事だよとはどこにも書かれていなかった

クリスマスですね

これは何?

【その2】妻・夫を愛してるITエンジニア Advent Calendar 2016の25日目です。
妻・夫を愛してるITエンジニア Advent Calendar 2016 - Adventarもありますね。

家族構成

私、妻、長男、次男の4人家族です。

妻との出会い

地元の手話講習会で、私が講師、妻が生徒という教え子の関係でした。 もちろん、付き合い始めたのは講習会が終わってからです。

交際から結婚まで

3年半ほど交際して、この人と一緒に生活したい、ほかの人には取られたくないという思いからプロポーズして見事にOKしてもらえました。

子育て

結婚1年もしないうちに長男を授かり、ウキウキしていましたが、ちょうどそのころ私は仕事がとても忙しく、終電帰りもよくある生活。
平日はほぼ、妻に子育てを任せっきり…たまに早く帰れた時や週末に、おしめ交換やお風呂に入れるくらい。
そして、東日本大震災もあり、計画停電等もあって大変な時期だったと思います。

次男を授かったときもなぜか仕事が忙しく、兄弟二人の子育てを妻に任せっきり…. もちろん時間があるときは協力しました。

今現在はほぼ定時で帰れる日々ですが、帰るころには子供たちは寝る時間。 寝る前の仕上げ歯磨きくらいしかお手伝い出来ません。

週末は一緒に遊んだり、子供と外出してちょっとでも妻が楽にできればいいのですが、なかなかうまくいかず…反省。

妻への感謝

妻は私の6つ年上で、体力的に暴れん坊の子供二人を見るのが辛いお年頃になってきています。 パートで忙しいにも関わらず、公文への送迎もしつつ、買い物もしつつとフル回転している妻には足を向けて寝られません。 また、妻は病院で医療事務として働いているので、人よりは若干病気に対してうるさく、すぐに病院に行きなさいとお尻を叩いてくれます。

以前、1年だけ沖縄で過ごしていたこともあり、沖縄の魅力をたくさん語ってくれます。 その影響で、私も沖縄が好きになり、年に1度は家族で訪れるようになりました。 2017年は夏に沖縄に行きたいねと話し合っており、それに向けて予算を見積中。

地元の講習会の講師をやるよと引き受けなければ妻と出会うこともありませんでした。
沖縄の魅力を妻から教わることもありませんでした。
毎日うるさい兄弟、二人を授かることもありませんでした。
妻と出会わなければ、私の性格的にたぶん今も一人だろうと思います。

真奈美、私と結婚してくれてありがとう。 2017年も情けない旦那を露呈することが多そうだけど、よろしくお願いします。

大腸CT検査を受けた体験談

これは何?

人間ドックを受けたら便潜血反応で陽性が出てしまったため、再検査を受けた時の体験記。

経緯

  1. 2016年11月上旬に人間ドックを受診
  2. 2016年11月下旬に検査結果が返って来て、便潜血反応で陽性が出ていた。
  3. 2016年11月下旬に近場の病院に行き、大腸CTを受けるための予約受診。
  4. 2016年12月上旬に大腸CT検査を受ける。
  5. 2016年12月中旬に検査結果が返って来て、異常なしとの診断。

JJUG CCCの時は実は内心、大腸がんとか見つかったらどうしようとドキドキだった

大腸CT検査を選んだ理由

大腸がん検査と聞くと、2Lの腸管洗浄剤を飲む前処置がとっても辛い思い出がよみがえってくる。
しかし、CT検査では2Lも飲まなくてよくて、前日に検査食を食べる、夜寝る前に下剤を飲むだけでOKというお手軽さ。

大腸CT検査を受けてみた感想

  1. 検査食は電子レンジで温めるだけのお手軽だけど、会社でやるのはちょっと勇気がいると思う。
    出来れば検査食は休日に食べて、翌日に仕事を午前半休して検査を受けるスケジュールの方がよい。
  2. 2Lの腸管洗浄剤を飲まなくていいのは楽だけど、大腸に便がちょっと残ってしまうのは申し訳ない気分になる。(個人差があると思う)
  3. 聞こえない人が検査を受ける時は出来れば配偶者か、通訳者がいた方がよい。
    基本は検査服に着替えて、お尻に管を突っ込まれて、CTを通るだけだけど、息を吸ったり吐いたりする指示がある。
    この指示が聞こえないと大変(一応マークで教えてくれる)なのでそばに誰かがいてくれた方が気持ち的に楽。

内視鏡検査との比較

  1. 検査前に2L飲まなくてよいのは楽
  2. お尻に突っ込まれるのは内視鏡検査もCT検査もそんな違和感がないのでどっちでもいいんじゃないかな。
  3. 検査で万が一悪いところが見つかった時、内視鏡検査の時は細胞検査用に取ることが出来るがCT検査はそれが出来ない。
  4. CT検査はあくまでも3Dによる造影なので、造影を信じない人は内視鏡検査の方がいいと思う。

まとめ

痔は直そう。

参考

大腸CT検査(大腸3DCT)について|トピックス|大手前病院

UIテスト自動化の話題で思ったこと

てんてんさんのブログや、それに関する色々な方のツイートを読んで思ったことを書き溜めておく。

 

まず、うらがみさんのセッションを聞いてて、スクショを自動で撮ってくれるのは私も魅力的だなと思ったのは事実。

でも、それ以上に思ったのは、やっぱりテストコードをシンプルに書けるところに魅力を感じた。

シンプルに書けるということは、テストデータの入力の部分を移譲しやすいので、大量データの入力及び、その処理結果が正常か、のテストを書きやすいとも言えるのではないか。

 

そして、マニュアル作成時にそのテストデータを流用することで、マニュアル作成に要する工数を減らすことに繋げられる、という方向で持っていくのがいいのかな、と考える。

 

単体テスト時のスクショとして考えてしまうけど、単体テストの時はまだ画面レイアウトもちゃんと確認できていないだろうし、UIテストを自動化したことに満足して目視確認を怠ってしまうという危うい部分もあるのではなかろうか。

 

というわけで、UIテスト自動化はスクショ目的ではなく、テストデータの入力を自動化、及び目視確認の補助として使うのがいいだろうというのが現時点での私の考えです。

 

JJUG CCC 2016 Fail で20分枠でお話しさせていただきました。#jjug_ccc

毎年春と秋に行われている、JJUG最大のイベント、CCCで20分枠でお話しさせていただきました。

発表した内容は以下に挙げてあります。

事前に台本も作り、脳内シミュレーションをやっていたのですが、いざとなるとやはりてんぱってしましました。
台本通りに喋れなかったので、聞いていた方は???な部分もあったかと思います。
申し訳ないです。

本当は手話を交えてお話しを、と思っていたのですが、普段技術の話を手話でやっていないせいか、登壇したら口しか動きませんでした。

応募してみたときは、Twitterで聞こえないことをいっぱい出しているし、補聴器アイコンだし、落ちるだろ~と思っていたのですが通ってしまい、焦りました。
でも、通ってしまったので改めてJMHについて調べていくと、理解が足りていなかった部分が出てきて自分の勉強にもなったので、応募してよかったなと感じています。

今回、20人ほどの方に聞いていただけたのは嬉しかったです。
私の時間になったときに数人、入ってきてくれたというのも、JMHというモノに興味を持ってくれたのだなとうれしい思いになりました。

私の話を聞いて、次の測定はJMHを使ってみよう!と思った人が一人でもいれば嬉しいです。

じゅくちょー様が私の話も聞いてくれたのかはわかりませんが、ちょっとはとんがったお話が出来ていたならいいなぁと。

懇談会の会長のLTで参加者数が905人、と出ていました。
経費も結構な多額が動いており、スタッフの方々の苦労が偲ばれます。
スタッフの方々、スムーズな運営をどうもありがとうございました。

2017年春は50分枠…無理なのでせめて懇談会でLT出来るネタは育てておこうと思います。