Bic simに乗り換えました
SoftbankをVodafoneの時から使っていたのですが、2017年GW中に別れを告げて、Bic simに乗り換えました。
理由はシンプルで、通信費の削減が目的です。
夫婦でiPhoneなので、試算だと一ヶ月につき1万円弱の削減が出来るはず…。しばらく、解約手数料やらなんやらで支払いは増えそうですが、7月以降を楽しみにしたいと思います。
我が家は夫が聞こえなくて、妻が聞こえるという家族であることを念頭において、乗り換え時の手順を記録しておきます。
なお、電話番号はそのまま乗り換えたかったのでMNPしました。
契約名義は夫の名義です。
①Softbankから予約番号を貰う その1
最初は妻に電話して貰い、予約番号を受け取ろうとしましたが、本人確認が出来ない云々で少々揉めてしまいました。
妻が強く言った結果、拙い発音で名乗ることで本人確認が出来た、ということになりましたが、音声だと成りすましが容易ですよね。この辺り、おかしな話だなと思います。
何とか本人確認が出来て、その後のやり取りは妻にやってもらったのですが、契約内容が認識していたのと違ったので電話での予約番号発行はやめて店頭に行くことになりました。
教訓：聞こえない人が名義人の時は素直にお店に足を運んだ方が早い。
②Softbankから予約番号を貰う その②
というわけで、お店に足を運んで予約番号が欲しい旨伝えます。多少引き止めはありますが、もう決めたんだ！という強い意志を見せればよろしいかと。
店頭だと、契約内容についても詳しく確認出来るので安心です。
店頭では特に聞こえないから困ることもなく、筆談でのやり取りでスムーズに進みました。
③Bic simに申し込む
ビックカメラ店頭でも、インターネットからでも申し込みが出来るので、どちらのやり方でもよろしいかと。
私は店員さんに質問したい事項も無かったのでインターネットから申し込みしましたが、質問がある時は店頭での方がいいでしょうね。
インターネットで申し込んだら、翌々日にはSIMカートが届きました。
④携帯にSIMカードを刺して開通手続き
ここでまた、聞こえないと困る出来事があります。開通させるには指定された電話番号に電話しないといけませんでした。
今回も妻に頼りまして、対応してもらったんですが、自動応答のようなので、トリガーとなる音さえ拾えれば、聞こえない人でも自分で出来るのかも…？
店頭でやる時は別料金らしいのですが、聞こえない人を対象にした、何かサービスがあるといいかもなぁと思いました。
教訓：聞こえない家族だとちょっと厳しいかもしれない。聞こえる知人の助けが必要。
⑤その後
メールアドレスの変更は新アドレスから一括で送信しました。アドレス漏洩がないように、送信対象の人は全員BCCで指定しました。
新アドレスは@icloud.comを使っています。
インターネットの速度は現状、不満もありません。YouTubeはwifi環境でしか見ませんし。
⑥まとめ
私自身は慎重に下調べして、メリットとデメリットを確認した上で乗り換えました。
ニュースで格安スマホのトラブルが増えているとも言っていましたので、乗り換える際はじっくり下調べしましょう。
特に、店頭での相談がやりにくくなるので聞こえない人にとってはそこがデメリットになるかと思います。
周りに知識を持つ人がいるから平気平気、という思考を持つ人もいるかと思いますが、その知人は無償で手助けしてくれているだけです。
何かの拍子にトラブルになった時人間関係も含めて困るよ、というのも忘れないようにしたいものです。
"Date and Time API をJDBCで扱ってみる"を読んでDB2を確認した
昨日の発表資料です。
— ひじり🐸 (@hijiri408) 2017年4月27日
Date and Time API をJDBCで扱ってみる https://t.co/7NUUDCOBhS #kanjava
を読んで、昔DB2で仕事していた身として、DB2の状況が気になったので検証してみた。
環境など
- Windows10
- jdk 1.8
- DB2 Express-C 11.1 + JDBCドライバ 4.22.29(http://www-01.ibm.com/support/docview.wss?uid=swg21363866)
ソース
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
テーブル存在チェックはどう書くべきなのか
何でこれを書いたのか
コードレビューしていてちょっともやもやしたので吐きだしてみた。 自分の考えが間違っているかもしれないので、吐きだしてみて意見がもらえたらラッキー、程度。
前提条件
存在チェックはどうあるべきか
単純に存在しなかったら登録、存在したら更新、の時
こちらについては、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だったら該当データ無し、それ以外は異常、という判定で統一出来ててわかりやすかった記憶がある。 OracleやMySQL、PostgreSQLも同様のリターンコードで判定できるのだろうとは思う。
ここまで書いて気づいたこと
今のプロジェクト、何も考えないでパターンAで書いてしまったコードがいっぱいあるなぁ･･･
検証資料の変遷について
最初に
某SIerに勤務している自分が今まで作ってきた検証資料の変遷についてまとめてみました。あくまでも私の話なので、皆が皆同じではないです。
あと、検証資料のことをエビデンスという人は嫌いです。なんだよエビデンスって。海老でんす？
入社初期
- COBOLで書いたバッチプログラムのテストケースはexcelで作られた雛形に記入した。
- テスト結果は入力ファイル、出力ファイルをダンプ形式で紙に出力し、テスト番号やテスト結果の補足を手書きで記入&マーカーで印をつけて提出する。
- テストケースとテスト結果はレビュアーのチェックを通過後、お客様チェックまで進む。お客様のチェック結果も戻って来て、OKなら本番リリースが出来る。
- 社内ではある程度細かく見てもらえていた。
- 先輩社員はAS400の画面も新規開発、あるいは修正していて、画面のテスト結果はスクリーンキャプチャを紙に出力していた。
入社3年目頃
- AS400画面をWeb画面に作り変えるプロジェクトに携わる。
- この時も、提出物は紙だったので諸々印刷する必要があった。この辺りでexcelの図形を使えば強調したいところを強調出来るという発見があり、じわじわとプロジェクトメンバーに手法が広がっていく。
- データの集計結果確認にもexcelの機能が使えたので、ファイルを複数使うより、シートを複数使ってテスト結果をまとめていくやり方が当たり前のようになっていく。
- 最初は画面の機能もシンプルだったが、段々複雑なものが求められるようになり、スクリーンキャプチャを取るのが苦痛になってくるのもこの頃。
- 印刷する必要があったため、印刷時のレイアウトも考慮する必要があったのが辛かった。
入社10年目頃
- 承認フローのシステム画面が導入されたことに伴い、紙での提出が廃止される。すなわち、印刷時のレイアウトを気にしなくてよくなった。
- テスト結果に求められる内容は変わらないため、スクリーンキャプチャをペタペタ貼り付ける作業が必要なのは変わらない。
- ただ、この頃からJUnitも使い始めたのでJUnitの実行結果を貼り付けて終わりに出来る場合もあった。
- テスト結果の確認は、社内メンバーはレビューフローを明確にしたこともあり、ローテーションでチェック体制が出来ていた。チェックする側は大変だったけど…
現在
- プロジェクトが変わり、現在のプロジェクトではテスト結果を客先に提出はしていない。(お客様の受入環境があり、そちらで確認していただいている)
- そのため、テスト結果はかなり簡略化されて作成が楽になった。
- また、自分で開発、修正してテスト、と全部自分でやるためテスト結果をチェックする人もほぼいないに等しい。
- ではなぜ作っているのか？と聞かれると、テスト漏れがないかの自己チェックや、あえて資料化することで見落としを減らす、あとは後々担当が変わった時の引き継ぎ資料となればいいな、というのも含まれている。
考察
- 前提として、資料を作る過程で発見できる不具合は間違いなく存在するのでテスト結果は資料に残した方がいいという考え方。
- ただ、不具合ゼロを求め過ぎて、スクリーンキャプチャを大量に取らないといけなくなるのは無駄な仕事を増やすだけ。
- Excelだと、画面の遷移も静止画になってしまってわかりにくい部分があるので、gifや動画をうまく組み合わせたものが作れるとベストだと思っている。
- 今はmarkdownで書いて、html化することも出来るのでこの辺りを組み合わせられないかとも思っているが、excelのレイアウト調整のやり易さがそれを邪魔する…。
Wordを使えやという意見も散見されるが、Wordはレイアウトの調整がやりにくいのでストレスになるからダメ
私見
- 資料を見てもらえる人がいないなら、思い切って作るのをやめてしまうのも１つの手だとは思うが、テスト漏れがあった時のリスクも考慮しないといけない。
- 現場で求められている内容に応じて臨機応変にやりつつ、スクリーンキャプチャの嵐を軽減する方法をこれからも模索していきたい。
「小学生でもわかるプログラミングの世界」を読んだ
「小学生でもわかるプログラミングの世界」という本が気になったので読んでみました。
結論から言うと、前書きで著者が「大人にも楽しんでもらえるように書きました」と仰っている通り、楽しく読める一冊でした。
コンピュータの基礎である、CPUなどのハードウェアの説明から始まり、プログラミングとは何をするのか、どんな言語があるのか、を簡潔にわかりやすくまとめてある本です。
基本情報処理技術者試験を初めて受ける方や、システム開発の会社に入る、それまではプログラミングに全く触れたことがない学生等が初めの第一歩の知識を得るにはちょうどいいのではないでしょうか。
個人的には、プログラマーとはどんな仕事なのかを紹介しているところで書かれていた一文がとっても素晴らしいと思いました。
という疑問文に対し、
それぞれの協力関係で成り立つからどちらが偉いとか偉くないとかはないよ！
という回答が書かれています。
当たり前のことですが、システム開発はお互いの協力関係の下、成り立つものなので、どちらが偉いとかは関係なく、お互いを尊重しなければなりません。
小学生でもわかる、当たり前のことを大人が分かっていない言動がみられるのは恥ずかしいことではないでしょうか。
関西を代表する凄腕エンジニア、こざけさんもこんなツィートをされていますし。
結局、エンジニアだから偉いわけじゃないし、マネージャーだから偉いわけじゃない。
— こざけ (@s_kozake) 2017年2月10日
職種より職能ってことだよね
頑張らないとね
小学低学年には難しい内容がたくさんですが、高学年なら理解できそうな文章とイラストで描かれているので、お父さんの仕事は何？と聞かれたシステム開発に携わっている人はこの本を読ませればよさそうです。
Excel方眼紙をいじるお仕事だよとはどこにも書かれていなかった
クリスマスですね
これは何？
【その2】妻・夫を愛してるITエンジニア Advent Calendar 2016の25日目です。
妻・夫を愛してるITエンジニア Advent Calendar 2016 - Adventarもありますね。
家族構成
私、妻、長男、次男の4人家族です。
妻との出会い
地元の手話講習会で、私が講師、妻が生徒という教え子の関係でした。 もちろん、付き合い始めたのは講習会が終わってからです。
交際から結婚まで
3年半ほど交際して、この人と一緒に生活したい、ほかの人には取られたくないという思いからプロポーズして見事にOKしてもらえました。
子育て
結婚1年もしないうちに長男を授かり、ウキウキしていましたが、ちょうどそのころ私は仕事がとても忙しく、終電帰りもよくある生活。
平日はほぼ、妻に子育てを任せっきり…たまに早く帰れた時や週末に、おしめ交換やお風呂に入れるくらい。
そして、東日本大震災もあり、計画停電等もあって大変な時期だったと思います。
次男を授かったときもなぜか仕事が忙しく、兄弟二人の子育てを妻に任せっきり…. もちろん時間があるときは協力しました。
今現在はほぼ定時で帰れる日々ですが、帰るころには子供たちは寝る時間。 寝る前の仕上げ歯磨きくらいしかお手伝い出来ません。
週末は一緒に遊んだり、子供と外出してちょっとでも妻が楽にできればいいのですが、なかなかうまくいかず…反省。
妻への感謝
妻は私の6つ年上で、体力的に暴れん坊の子供二人を見るのが辛いお年頃になってきています。 パートで忙しいにも関わらず、公文への送迎もしつつ、買い物もしつつとフル回転している妻には足を向けて寝られません。 また、妻は病院で医療事務として働いているので、人よりは若干病気に対してうるさく、すぐに病院に行きなさいとお尻を叩いてくれます。
以前、1年だけ沖縄で過ごしていたこともあり、沖縄の魅力をたくさん語ってくれます。 その影響で、私も沖縄が好きになり、年に1度は家族で訪れるようになりました。 2017年は夏に沖縄に行きたいねと話し合っており、それに向けて予算を見積中。
地元の講習会の講師をやるよと引き受けなければ妻と出会うこともありませんでした。
沖縄の魅力を妻から教わることもありませんでした。
毎日うるさい兄弟、二人を授かることもありませんでした。
妻と出会わなければ、私の性格的にたぶん今も一人だろうと思います。
真奈美、私と結婚してくれてありがとう。 2017年も情けない旦那を露呈することが多そうだけど、よろしくお願いします。
