Oracleからpostgresへの移行でCREATE SEQUENCEにハマる

OracleDBからpostgresへ移行しているのですが、シーケンスをOracleSQLDeveloperからDDLを生成して、そのままpostgresにCREATE SEQUENCEしたところ、下記エラーでそんなのないよと怒られます。。

test_db=# select * from tran_id
test_db-# ;
ERROR: relation tran_id does not exist

実行したDDLは下記の内容です。

CREATE SEQUENCE “TRAN_ID” MINVALUE 1 MAXVALUE 99999999 INCREMENT BY 1 START WITH 1 CACHE 20 CYCLE ;

権限周りを見直しても何も変わらず、試しに

 CREATE SEQUENCE TRAN_ID MINVALUE 1 MAXVALUE 99999999 INCREMENT BY 1 START WITH 1 CACHE 20 CYCLE ;

を実行したところ、CREATE出来た?普通にSQLでシーケンスが取れた。あれ?

postgresはダブルクォーテーションを付けると付けないでは別ものになるのですね。。

WindowsのRedmineプラグイン開発をVisualStudio Codeに移行してみた

 前にやろうとしていたRedmineのバージョンアップ対応ですが、バージョンが決まり(Redmine2.5.1&Ruby2.0&Rails3.2 → Redmine4.0.4&Ruby2.5&Rails5.2)、インフラ含めスケジュールされたので、ぼちぼち対応に入ろうとした所、Rubyのバージョンを2.0から2.5に変えた影響か、Windowsローカル環境のAptanaStudio3では、実行は出来てもデバッグしようとすると、


と出て動かなくなりました。

 これまで3年くらい、Redmineプラグインの開発用に使っていたAptanaStudio3ですが、原因調査を早々に諦めて、、VSCodeに開発環境を移行する事にしました。
 使っているWindows端末にはRuby系の環境は既にインストール済みなので、Rubyのみ最新にします。

C:¥temp>ruby -v
ruby 2.5.5p157 (2019-03-15 revision 67260) [x64-mingw32]

C:¥temp>rails -v
Rails 5.2.2

 VSCodeを普通にインストールして、既存のAptanaStudio3で対応していたフォルダをワークスペースに追加するだけで、準備が出来ましたが、デバッグ設定が一苦労。。ググるといろいろ情報があり、思いのほか試行錯誤しましたが、こちらが一番参考になりました。デバッグ用のGemをインストールし、設定を試していきます。

 最終的にlaunch.jsonは下記となり、ブレークポイントも止まるようになりました。


 VisualStudio Code ネットの評価に違わずいい感じです。新しいツールを使うのは少し手間が掛かりますが、気分的にもリフレッシュできますね。

Swagger + SpringBoot で APIサイトを作ってみる

既存システムのDBへアクセスしてデータを参照するようなAPIを、って事で、
SwaggerでAPIを定義し、Swaggerから自動生成したソースを使って実装してみました。
なお、今回対象としているのは参照系がメインでRESTって雰囲気ではありません。
対象が既存システムのDBなので。。

とりあえず、ざっくりとした要求と応答の仕様を整理し、Swagger Editorにyamlを書いてみます。

なお、Swagger Editorは、別件で使っていた端末内のxampp/htdocsにGitHubからダウンロードしたZIPを解凍して使ってます。
ある程度、定義を書いた後、Swagger EditorからGenerate ServerでSpringのサーバソースを出力してみます。

自動生成されたJavaソースはこんな構成です。

Controllerとレスポンスエンティティのモデルが揃ってます。全体的なソース構成は、コントローラ層、サービス層、データアクセス層という3構成になりますかね。
コントローラ層は概ねSwaggerで生成したので、データアクセス層も自動生成しようと、Doma2を使ってみます。
doma-gen-build.xmlに接続先DB情報と出力先ソースの設定等を記述し、こちらもGenerate!

結果、ソースを手書きする必要があるのは、

・サービス層全体

・Swaggerで自動生成されたSpringBootApplicationクラスのComponentScanにサービス層のパッケージを追記
  @ComponentScan(basePackages = { “io.swagger”, “io.swagger.api”,”jp.esoro.api” })

・Swaggerで自動生成されたControllerにServiceをコールする箇所を追記

・DAOインターフェースに下記アノテーションを追記
@ConfigAutowireable
@Repository

・自動生成不可能なSQL文の作成し、それに合わせてDAOにメソッド追加

といったところで、とりあえずの動作確認が出来ました。

ただ、実用するには認証やページング等も必要なので、こんな単純な話にはなりませんし、APIの仕様をちゃんと整理してからSwaggerでソースを生成して着手しないと後が面倒ですね。

google-http-clientを使ってみた

 とあるWebAPIサービスを提供しているサイトへアクセスするクライアントをjavaで書こうかと、最初はjerseyを試してみたのですが、これがなかなか厄介で、次から次と依存が判明して動作するまで一苦労。。
最終的には、とあるサイト側の認証における制約により、jerseyの仕様ではどうやってもアクセスが出来ない事が判明。。

 失敗の原因は概ね当たりが付いていたので、その辺りに問題が無さそうなライブラリとしてgoogle-http-clientを使うことにしました。
 jerseyで途中まで実装していたものをそのままgoogle-http-clientを使う形に置き換えて疎通確認レベルまでやってみます。

 google-http-clientは依存が無く構成がとてもシンプルで置き換えた途端に、サックリとAPIアクセスに成功しました。proxy経由でもJVM引数で指定してあっさり通りました。

 細かいところでは、どうも指定したタイムアウトは効いてないような気がしますが、まあ、今回の実務上問題無さそうなので、利用しやすいように整理して実装しようと思います。

 だいぶ経って2019年1月現在、久しぶりに使ってみると、当時のバージョン1.23と現在の1.28では仕様が変わっており上記のままでは動かなくなりました。。

自分が使わなきゃ、誰かに使ってもらえない

 先月、新居に引っ越したところ、備え付けのガス操作パネルに昨日と今日のガス代が表示される機能が付いていました。入居時にガス開栓に来てくれた係員曰く、一定の計算方法に基づいて表示している金額なので、実際のガス代とは違うとの事。
 使用状況を管理して、請求されるガス代と見比べられればガス代を節約出来ると思い、毎日のガス代を記録していく事にしました。
 で、どう記録しようと、ふと数年前に作ったAndriodアプリを思い出しました。

 ガス代の入力項目を設定して、

 こんな感じで毎日登録していきます。

 たまに登録忘れてますけど。。


 このアプリは、筆者が前職を辞めた後に、プログラミングのリハビリを兼ねて、JavaでAndroidアプリを作ったものですが、5年くらい経ってもまだ、ダウンロードは100レベル。。完全ほったらかしなんで、そんなもんでしょうし、どちらかというと仕事利用がターゲットで、利用者が自分でデータ項目を決めるというコンセプト自体がそもそも理解しにくいでしょうね。UIもAndroid2.X時代のままですし。。

 作ろうと思った経緯自体は、ビル管理の仕事をしている人から、計器類の記録を取るツールが欲しいなあという話を聞いたのがきっかけですが、コンセプトとしたのは

 ・汎用的なデータフォーマットに対応
 ・オフラインでも記録が可能
 ・記録したデータは他システムと連携可能
 という3点でした。

 最初の汎用的なデータフォーマットという所で、偶々見つけてくれた人でさえ、データを定義して設定しないと何もできないという難しさがあったと思います。
 2点目は、スマフォアプリなら出来て当たり前ですが。。
 3点目は、スマフォ内部でのデータ保存はあくまで一時的なもので、DBサーバとかに連携出来るよう、結果的にメール送信として実装しています。メールをインターフェース手段としておけば受信側で何か用意すればどうにでも取り込めるだろうと、SMTPの設定をすれば、送信ボタン一発で送れます。
入力画面から1件単位で送信するのと、例えば1か月とか貯めて一覧画面からCSVで送信するのと2パターンを用意しました。今回のガス代は後者を使ってあとでエクセルとかで確認する予定です。
完全フリーですが、この連携箇所に何等かのニーズがあればユーザー開拓が出来るかなあという目論見もありましたが、何も無かったですね。。

 コンセプトうんぬん以前に、作ったアプリを自分自身が使う機会が無かったという事が、ほったらかしにしてしまったようです。
 作った人が使わないものを他の誰かに使ってもらえるという事は期待しちゃいけないですね。5年くらいの時を経て改めて使ってみましたが、暫く使い続けて問題と感じたところを改良してみようと思います。

Windows10でHTAの画面フォントが崩れる

 少し前にHTAで作られたツールのWindows10対応をしていましたが、一部の画面で文字が巨大化したりで表示が崩れて目も当てられない状況。。

 でも全ての端末で起きる事象では無いらしく、特にパナのLet’s Note の場合に発生しているらしい。どうも、Win10のデスクトップ右クリックでディスプレイの設定を開き、「拡大縮小とレイアウト」が100%でないと崩れる模様。
 パナのLet’s Noteは、ディスプレイの解像度が高い為、文字を大きく表示したいと設定を変更する人が多いようです。

「拡大縮小とレイアウト」より設定を変更しながら対応結果の確認をしますが、HTAは「一部のアプリは、サインアウトするまで、拡大縮小の設定に応答しません」の対象なので、設定を変更してはサインアウトの繰り返しが必要。

 結局、HTAに書かれているCSSを確認したところ、%指定とかem指定とか結構適当になっていた事に起因している事が判明。
 フォントサイズを全てピクセル指定にして一件落着。

2期目の法人確定申告をしてきた

 今月末が法人2期目の確定申告期限になっていたので、徐々に決算申告の用意をしてました。
 既に1回は確定申告の経験があるので、前回を思い出しながら国税・県税・市民税と3か所から届いていた書類に順次記入していきます。
 2期目となって1期目と違うのは、前回の決算申告結果が反映する事でしょうか。特に、「別表4 所得の金額の計算に関する明細書(簡易方式)」の中にある「納税充当金から支出した事業税当の金額」という欄に前回の事業税等を損金として減算するところが2期目のキモっぽいです。
 あと今期は、10万以上のPCを購入していたので「別表16 少額減価償却資産の取得価額の損金算入特例に関する明細書」が加わり、難解な別表5辺りも含めて何とか書類の用意が終わり、本日やっとオフライン申告=税務署周りをしてきました。

 途中、銀行で現金を引き落としてから、管轄の松戸税務署へ行ってハンコを貰い、すぐ近くの県税事務所へ。こんな事もありましたが、さらっと提出してハンコとその場で納税して、あっという間に終了!
 時間を見たらまだ11時を回ったばかり。

 このタイミングは、二郎チャレンジか!と勇んで向かい、開店から2ロット目2番手となり、しばし店内で待ちます。回転は早くすぐに着座。野菜・にんにく注文し着丼

 筆者はジロリアンでは無く一般ピープルですが、都内の数店舗に行った事があり、松戸店は今回初。
 いつもの通り、最初はおいしく、途中で苦しく、終盤の達成感と食べ過ぎの後悔が入り混じった感覚が胃の中から逆流しそうなところで店を後にして、、次に市役所へ向かいます。

 こちらも瞬殺で同時に納税を済まして、帰宅後、e-Taxで国税のダイレクト納付をして本日のミッションは終了です。って、何かあれば後で連絡来るのでしょうけど。

 ところでe-Taxでは、どうやら申告書の作成もe-TaxのソフトをPCにインストールすれば出来そうな雰囲気。これまで筆者はwebのe-Taxしか使ってなかったので、次回はソフトも使ってやってみよう。

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

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

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

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

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

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

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

eLTaxのPCdeskで税務申告してみた

 昨年の10月くらいだったか「給与所得の源泉徴収表等の法定調書の提出について」と題した書類が届いていて、1月末までに提出しなければならないものがあるとの事なので、夏休みの宿題のように追われて対応していました。
 ネットで調べていくと、どうやら「給与所得の源泉徴収票等の法定調書」は税務署へ提出し、殆ど同じ内容の「給与支払報告書」を市町村に提出しなければならない模様。
 で、さらに調べるとラッキーなことに今年から一括提出が出来るようになったようで、一括提出にはPCdeskというソフトが必要との事。PCdeskはeTaxの地方税版であるeLTaxのクライアントソフトという位置づけのようで、PCにインストールする必要があります。
 eLTaxの利用申請は既にやっていたので、eLTaxのサイトからダウンロードしてインストール後すんなり使用可能になり、住基カードを使って何とか国税と地方税双方に申告することが出来ました。

が、このソフト、筆者にとってはかなり使い勝手が悪く、インポートとエクスポートとしかボタンに書いてないので、ボタンを押すことで何が起きるのかわからず、誤って入力したデータを何回か消しました。。
 通信で法人データを取得することをファイルのダウンロード処理とメッセージに表示されるのも、メッセージとしてとても分かりずらい。。
 どうもこのソフトは税理士等代理人が複数の企業を担当するのを意識して作られているようなので、その道のプロフェッショナルが対象という事なんでしょう。筆者のような素人は、このソフトがターゲットとしているユーザーではないのかもしれません。でも、それって公的機関が作るべきソフトとしてどうなんでしょうか?それを使わなければならない素人にもわかってもらうような対処がなければ、それは従来の業務を簡素化するだけで、その業務をやっていた人達が代理人だとすれば、このソフトは代理人の業務簡素化を目的に作ったのか、それとも作ったソフトを受入れ評価する人達がそのような立場の人たちしか集まらなかったのか??
 ソフトウェアの評価を求める時はいろんなタイプのユーザーを入れて評価してもらう、それが難しければ、せめて画面のメッセージぐらいは、いろんなタイプのユーザーの存在をちゃんと意識して文章にしようと思う今日この頃です。