JavaMailで送信日時が取得できないケースがある

 メールを受信する業務用ツールをJavaMailで実装して、かれこれ一年近く普通に使っていたのですが、新しい要件に沿った機能を追加してテストしていたところ、メールの送信日時を取得
javax.mail.Message.getSentDate()
でnullを想定しておらずエラーに。。
これまで何も問題がなかったのですが、どうもメールによっては取れないケースがある模様。
メールをemlファイルにして中身をエディタで見たところ、

問題無いケース Date: Fri, 23 Jun 2017 11:23:10 +0900
問題有るケース Date: Tue Jun 6 12:31:19 2017

 で、試しにemlファイルのDateヘッダを問題無いケースに書き換えてやってみたところ、普通にJavaMailで送信日時が取れた、、という事は?

 細かくは調べてませんが、問題となるメールはDate書式がMIMEの仕様に沿っていないようです。
仕様に沿っていないのか、仕様が明確でないのか、もしかして、仕様が明確になる前からあるSMTPサーバなのか・・?

 OutLook等の一般的なメーラーで見る限り、普通に送信日時として表示されます。
こういう場合、メールを受信する側からすれば、細かい箇所が仕様に沿っていなくても、問題無く処理できるものを用意しなくてはなりません。
とはいえ、なかなか事前に想定するのは難しく、メールみたいに昔からあるものは特に注意しなければいけませんね。。

カテゴリー: Java

映画「メッセージ」を見て思う事

 昨日、近所の映画館で「メッセージ」を見てきました。何となく柿の種のような(ばかうけの方が正しかったみたいですが・・)宇宙船がちょっと気になった程度で見て見てみようと思っただけなのですが、なかなか、色々な示唆に富んだ映画でした。
 基本的には、未知の宇宙人とのコミュニケーションを取る過程が殆どなんですが、時間軸的に行ったり来たりするので、結構解りにくく、しかしそれがそもそもこの映画の主題なんだろうと思うのですが、それ以上に相手から聞くという事の重要性について考えました。
 システムの業界って、こんな事を実現したいというクライアントの言っている事を、開発者がよく理解出来ない時に、大抵、よくない事が現実化します。それをクライアントが避けたい場合には、高い金を払ってコンサルタントを雇い、その間に入れる事もあります。同じ言葉を使う相手でさえもこんな事は日常茶飯事なのですから、映画のように全く相手に言葉(=WORD)が通じないとしたら、その苦労は大変なものです。
 お互いが相手を理解する為には、少なくともどちらか一方が一旦は聞き役になる必要があります。伝える側は相手を理解すると言う事を目的にはしていないので、聞き役しか相手を理解する事は出来ません。聞き役は「あなたが伝えたい事はこのことですね?」と理解している事を相手に伝え、信用を得た上で次のステップに進む事が出来ます。映画のラストでは主人公が重要人物に伝えたい事を伝える為に、相手を理解していると言う事も同時に伝える事で信用を得ていますが、これは、その重要人物からそれを聞いた事に起因しています。未来に、ですが。
 結局のところ、人と人(または人以外の何か)の関係は、信用しているか?疑っているか?無関心か?の3つの状態を互いに9通りを時間軸で行ったり来たりしているだけと言えば、だけなのかもしれませんが、最低でもどちらか一方が聞くスタンスを持ち、多少なりとも聞く為の技術を持っていれば、信用しているか?という要素がいつのまに何処にも無くなっていたという状況は避けられると思います。
 もうひとつ、この映画に出てくる象徴的な言葉として「ノンゼロサムゲーム」がありました。宇宙人がなぜ地球に来たのかはネタバレなので避けますが、それは数千年後に起きる出来事に関してなので、直接的な利害関係は全く無いようなものです。利害関係が無いのに、なぜ相手を信用出来ないのか?逆に言うと相手を不信に思う時は、ただ単純に相手が嫌いなだけ(信用していない側の問題)か、何らかの「ゼロサムゲーム」的な、勝ち負け、損得の要素が相手との関係の中に生じたと言う事なんでしょう。

消費税の届け出に関する書類が来た

 先日、税務署から「消費税の届出のお尋ね」という書類が来ていました。
あれ?確か、起業から2年は免税じゃなかったっけ?と思いながらも、書類を読んでも「課税期間」という言葉がピンとこないので、税務署の方に電話してみました。なお、筆者の法人はあと2か月で2期目終了となります。
 税務署の電話口では、企業名を言うとすぐに過去の申告内容が検索できるようになってるらしく、前期の売上が1千万超えているから提出が必要ですとの事。ただ、2年間免税なのはその通りで問題無く、課税期間=3期目が始まる今のタイミングで「消費税課税事業者届出書」を提出する必要があるようです。

 もうちょっと調べていくと、消費税には、「原則課税」と中小事業者向けの特例「簡易課税」の2つの計算方法あり、「簡易課税」を選択する場合は、こちらも事前に「消費税簡易課税制度選択届出書」という書類を提出しておく必要があるとの事。
 となると、どちらの計算方法を選択すべきかという事になるのですが、簡易課税を選択すると業種によって「みなし仕入れ率」が決まっており、筆者のような業種だとサービス業に入るので50%で、売上額*消費税率*みなし仕入れ率で、おおよそ消費税率に対し半分が消費税納付額になる模様。一方の「原則課税」は、仕入れ関係の帳簿や請求書等を確実に保存する必要がある、と届いた書類に記載されているので、その辺りの管理が厄介そう。

 計算や帳簿管理が簡単だし、仕入が少ない業種は簡易課税の方がお得になりそうなので、こちらの届出も一緒に提出することにします。

特別徴収税額通知書がきた

 先日、市役所の方から「特別徴収税額通知書」なる書類が送られて来てました。
 
特別って、何??と思い中を開けると、どうやら源泉徴収の住民税版のようなものらしいのですが、いろいろ調べてみると、従業員が自分で住んでいる自治体に支払う「普通徴収」と、会社(事業所)の方が、従業員が住んでいる自治体に支払う「特別徴収」の2通りがあるようで、知らないうちに特別徴収義務者になっていたらしい。。

 封筒の中には、「特別徴収税額の決定通知書」と、6月分から来年5月分までの納付書が毎月分入っており、6月分は7月10日期限となっています。源泉徴収のように半年に一回支払いすれば済むものでは無いようなのですが、納付書があるのでまとめて先払いしちゃえばそれほど手間がかかるものでは無さそうです。とは言え、給料を払う前に税を払うという事は、経理上、源泉徴収とは逆の対処が必要そうなので、どうやるのかは別途調べないといけませんね。。

curlでパラメータを指定してWebページ上のファイルを取得してみる

 とあるWebサイトからファイルをダウンロードする作業を自動化したいという話があり、Linux上で動作するものという要件でしたので
とりあえずcurlでコマンドを作ってみました。対象サイトの認証はログイン画面からIDとパスワードを入力するという一般的な内容ですが、画面以外の対象サイトにおける認証の仕様については、何も情報が無くどうやらWebアプリ独自仕様のようです。
 ログイン画面でどんなやり取りがされているかと、FireFoxの開発ツールで確認し、POSTするパラメータを指定するコマンドを作成していきます。クッキーも指定してやってみますが、まだダメ。。

 今度はhttpヘッダの情報も開発ツールで確認しながら、必要そうなヘッダもcrulコマンドに指定すると、うまく動作しました。下記のような感じです。

ログイン画面

curl -X POST -L -b my.cookie -c my.cookie --header "Content-Type: application/x-www-form-urlencoded" -d "log=****&pwd=****" "https://targethost/login"

ダウンロードするファイルのGET

curl -L -b my.cookie -c my.cookie -o getout --header "Referer:https://targethost/aaaaa" https://targethost/files/targetfile.zip

 出来る出来ないはWebサイト側の作り次第かもしれませんが、とりあえずcurlでアクセスする事が出来そうです。
 とは言え、対象サイトの認証パスワードは定期更新が必要だし、他にもいろいろ対処が必要なので別の手段も考えた方がいいかもしれません。。。

backlog4jで課題を登録してみる

今度は、backlogへの課題登録を自動化したいという話があり、前回のredmineと似通った要件なので再利用箇所も多く、redmine java api部分をヌーラボ公認のbacklog4jに置き換えて実装してみました。
redmineとの違いはそれなりにありますが、backlog4jの方はKeyとIDを混同しやすい感じがします。例えば、課題のKeyはURLを見ればすぐ解りますが、IDの方は内部的なユニークな数値です。これに注意しながらbacklog用に前回のラッパークラスを置き換えてみました。

上記を呼び出すのはこんな感じ

後日談
GetIssieで3ヶ月経って問題発生・・・たまに課題の取得に失敗するようになりました・・・
下記のようにしましたが、最初からそうしろ!って事ですね。でも、3ヶ月は何も問題なかったのですが・・
public Issue getIssue(String issueKey)

redmine java api でチケットを取得してみる

 前回の続きで、今度はチケットを取得してみます。単純にチケットIDを指定して一つのチケットを取得するのでは無く、条件を指定し一括してチケットを取得して何かをするような要件への対応です。

 下記サンプルでは、クエリーを使用せずに、
ステータスID=2 かつ トラッカーID=10または11 かつ 題名に「テスト」を含む
という条件に一致するチケットを全て取得する内容です。
100件ずつチケットを取得して、100件以上のチケットがあればページ番号を変えて全チケットを取得します。

redmine java api でチケットを登録してみる

 redmineへのチケット登録を自動化したいという話があり、内容的には常時トリガーを拾って登録という感じだったので、javaの常駐プロセスでトリガーを拾う事を前提として、こちらを使用して実装してみました。
https://github.com/taskadapter/redmine-java-api
なお、登録対象のredmineは2.5系でしたが、それほどバージョンを意識しなくても大丈夫そうです。

事前準備として、対象のredmineへapi登録用のユーザーを用意し、登録対象のプロジェクトへの権限を付与、個人設定画面からapiキーを取得します。

その他、プロジェクトidやトラッカーid等のredmine内部で持っているidの値はブラウザからapiで下記のようにidの値を確認してセットとなります。ただ、redmine java apiには、様々なマネージャーがあるので、id指定でなくても都度問い合わせしてidを取得できそうです。

ソース的には下記のようなラッパークラスを作って、登録や更新を呼び出し側で簡略化出来るようにしてます。

下記の呼び出し側では、親チケットを作成してジャーナルを追加、子チケットを2つ作成し関連付けてます。

いろいろやってみましたが、redmineに対して殆どの事は出来そうです。

e-Taxで法人税の中間申告&納税してみた。

中間申告の通知が来ていたので、e-Taxで納税してみました。

e-Taxは何回も使ってますが、中間申告は今回初めて。
確定申告の期間なので、e-Taxが土日もやっており助かります。

e-Taxにログインし、申告・申請・納税を押して、新規作成
で次はどこ押すの?と立ち止まる。

正解は、「納税情報を登録する」なのだが、
中間申告の通知を送ってきてるんだから、既に税務署にデータは登録されているんじゃないの?
と疑問を感じつつ先へ進む。税務署は初期表示されているので、次へ
作成方法の選択と来て、「新規作成」を選択し、次へ
税目を「法人税」と選択し、次へ
課税期間を送られてきた通知の通り入力し、「中間申告」を選択し、次へ
通知に書かれていた金額を「本税」に入力し、次へ
ここで入力内容の確認画面となり、確認後、次へ
受付システムへの送信となり、送信
「送信が完了しました」と出て、受信通知の確認を押す。
送信されたデータを受け付けたと表示され、画面下の方に、電子納税とあるので、今すぐ納付でやると今日は土曜でダメ、納付日を指定される方というボタンを押すと、登録済の口座情報が表示され、納付ボタンを押して終了です。

これって、画面4つ程度で事足りるし、その方が解りやすい気がしますが、どうなんでしょう?
昔、画面1ついくらみたいな開発費用の見積もりをした事もありましたが、今もそうなのかなあ?

なお、このオペレーションを法人税と地方法人税で2回やって、中間申告&納税手続きは終了です。

コンピューターは人がやりたがらない仕事をすればいい

 基本的に筆者の仕事の大半は、企業内で人手がかかるオフィス業務を自動化するためのプログラム作りと言っていいのかも知れません。オフィス業務といってもいろいろあって、バックオフィス業務の自動化であったり、システム運用作業の自動化だったり、要件はそれぞれ違いますが、どちらかというとシステム運用作業の自動化の方が簡単というか、結構ワンパターンなので、完全自動化はやりやすいです。逆に言うと、開発を経てシステム運用フェーズに至る前にちゃんと運用設計されていれば、運用をフォローしやすくする為の設計とか運用ツールとかがある程度用意されているので、それらに沿って運用作業を自動化するだけという事で簡単に感じるのかも知れません。早い話、コマンドを自動的に実行出来ればいいみたいな。逆にバックオフィス業務はそういう観点から構築されていないので、業務分析という整理をするフェーズが無いと何がベストか解りにくいですね。

 10年以上前の事ですが、某地銀の仕事をやってた時にその銀行の部長が、システムを導入するのは人を減らすのが目的ではなく、今居る人で今後増えていく業務量をこなしていく為にシステムを導入するんだというような事を言っていたのを今でも覚えています。システム開発の仕事をしていると、自分の仕事は誰かの仕事を奪っているのではないか?という風に感じた事もありましたが、その部長の言葉は、とても腑に落ちました。

 今の時代、AIとかで人の仕事が無くなるのでは?みたいな話題が多いですが、結局の所、その仕事はどこからどこまでが範囲で、何をしてよくて何をしてはならないといったルールを定義するのはAIではなく人です。そんなケースごとに決める必要が無い範囲では既にコンピューターやロボットで自動化されていると思います。その先を実現しているのは、逆説的にコンピューターの世界で出来る範囲だけがその仕事の範囲であると定義付けしたところだけでは?
 オフィス業務はイレギュラーなケースを考えると無限に近いパターンがありますが、90%程度はワンパターンかも知れません。でもそこから少しでも外れたことがあれば人にしかできないし、そこまでフォロー出来る仕組みを作る方が却って人を雇うよりコスト高になると思います。判断基準は変わっていきますし、昔の判断が今でも正しいと決めつけてたら間違いますよ(例えば、昔はタバコをどこでも吸って、どこでも灰を落としてるけど、それは今時であれば限られた場所でしか出来ないみたいな)

今の所、コンピューターが人の仕事を奪っているのは、人があまりやりたがらないルーチンワークが殆どです。大量生産をひたすら24時間続けるなんて誰もやりたがらないし出来ないですよね。いつか、AIだけで会社を経営する事が出来る時代になったら、その時は人の仕事が殆ど無くなるんだろうと思いますが、そんな時代は当面無いですよね?
 
 例えばタクシーの運転手も配達員もただクルマを運転している訳では無く、依頼を聞くとか、請求するとか、荷物を車に載せるとか、伝票を処理するとか、不在だったらどうする?とか、自動運転が実現しても、他の仕事範囲はまた別の話です。その先にあるであろう、経営自体をAIでってのは全く聞いたことがありません。経営をAIに任せようという時代が来た時点で、その先の時代はターミネーターだったりマトリックスのようなストーリーが本当になる可能性が出てくるんでしょうね。