三菱東京UFJ銀行のウイルス対策ソフトのお知らせを消すたった一つの方法
Moneytreeなどのツールを使っていると、銀行からの重要なお知らせが来ているために口座情報が取れなくてエラーになってイラッと来てしまうことがあります。
本当に重要なお知らせの時もあるので仕方ないのですが、三菱東京UFJ銀行の場合は大抵がウイルス対策ソフトのお知らせで、イライラ度がより上がってしまうという弊害があります。
しかし、5分ほどちょっと我慢してパソコンから作業するだけで、ウイルス対策ソフトのお知らせがぴたっと止まって、快適になりました。
私は2017年8月頃に作業してからお知らせメールがぴたっと止まっています。
(この時期にシステム改修があって、お知らせメールが止まっただけだったらこの記事の意味も無いけど…)
その作業は極めて簡単で、お知らせメールのリンク先から一度、ウイルス対策ソフトをダウンロードする、それだけです。
インストール作業もやるかどうかは個々の判断ですが…。
おそらく、ダウンロードリンクを踏んだ時にシステム内のフラグが切り替わって、メール送信対象から外れるのだと思います。
というか、それ以外に判断できる方法も無いですし。
なので、5分ほどの作業をするだけでイライラが消えるなら作業した方がかなりいいはずです。
本来は、ダウンロード画面でダウンロードしないし、もうこの類のお知らせメールは不要、と選択できた方が嬉しいんですけどね〜
人間ドックで胃カメラ検査を受けた
今年の人間ドックで胃カメラ検査を初めて受けた。
流れは以下の通り。
1. 看護師から説明を受ける。カメラが入ったら飲み込む動きはしてはいけないとのこと。まぁそうだよね。
2. スプレータイプの麻酔を喉にかけられる。
3. ベッドに寝転がり、胃カメラを口から入れられる。
4. 胃カメラを抜いて完了。悪いところがなければ10分くらい？
聞こえない自分が困ったことは今回は無かった。でも、ヨダレが出まくってちょっと恥ずかしかった。あと、胃カメラが口に入るときにちょっとむせた。
バリウムとどっちが楽か？については、僕は胃カメラの方が楽。バリウムは飲んでゲップを堪えながらグルグル回るのが辛い。胃カメラは最初と最後の胃カメラの出入りさえ我慢できればいい。
という個人の感想です。
2017年11月時点の自分の思考を整理
ただの思考整理メモです。
●何が好きなのか？
ニーズに合わせて、新しい仕組みを考えて、実際に組み立てる。
うまく行かないとき、あれこれ試行錯誤して原因を究明する。
→うまく動いた時は嬉しいけど、大抵は誰も褒めてくれない。
→すぐに他人に頼ろうとするタイプの人には冷たくしてしまうが、よく考えると自分も初心者の時は割と頼りがちだったなと後になって反省する。
●何があまり好きではないのか？
他者が作った、自分の好みではないコードにガッツリ手を加える。
設計思考が受け入れられないものであればなおさら。
→大人なので一回だけなら我慢して淡々と対応するが、繰り返し来るとやる気がなくなってくる。
→設計思考がわかれば、一応それに合わせて柔軟に対応はするよう心がけてはいるが…
●なぜこの業界に入社したのか？
情報弱者の弱い部分を少しでも補えるお手伝いがしたかった。
直接補えなくても、直接補う人の負担軽減に繋がれば良さそう。
●今の不満
今のお仕事は、弱者に向けて全くお手伝いが出来ていない。
●自分に足りないもの、あるいは諦めてしまっているもの
夢を実現するために必要なプラスアルファの勉強をするための意欲
ふーむ。
次の面談で他のお仕事がしたいと訴えてみるか…
Eclipse Oxygen.1a (4.7.1a) でJava9+JUnit5を試したよ
導入
このツィートを見たので早速試してみた。
最近のeclipseはトップページからだとインストーラをダウンロードさせようとするが、以下ツィートのリンク先は昔からのユーザーにはおなじみの選択制zipなので嬉しい。
New Release - #Eclipse Oxygen.1a is now available with #Java9 and #JUnit5 https://t.co/Idn5S408Md pic.twitter.com/cdO1SGlvAA
— Java (@java) 2017年10月11日
JUnit5のチュートリアルはこれを見ながらやる。
でも、全編英語なので（当たり前）これも見ながらの方がいいかもしれない。
当たり前だけど、特にはまるポイントもなく環境は作れた。
JUnit 5 User Guide の注意点
- mavenで何を書けばいいかが初見だとわかりにくいので、"2.3. JUnit Jupiter Sample Projects"内にリンクされている、githubのサンプルからコピペした方が楽かも。
- あるいは、前述したきしださんのブログに書かれているpom.xmlをコピーするか。
- 基本は書かれているコード例をコピペで試せるが、"3.4. Assertions"だけコンパイルエラーが出る。該当メソッドはコメントアウトが無難。
- 5章のコードをコピペしてね、とか、github上のサンプルコードを持ってきてね（意訳）というサンプルがちらほらあるので柔軟に対応しよう。
- MockItoが唐突に出てくるが、導入の方法は書かれていないので以前に書いたpom.xmlが無ければググる必要がある。（ベータ版を使う？）
JUnit5を試した感想
- JUnit4で動いているテストは今すぐ書き換えなくていいかな。
- 新規で作るプロジェクトはJUnit5で書くのを視野に入れてもいいかも。
- Parameterized Testsは便利そう。
JavaOne2017に日本から参加した方々のブログ記事まとめ
個人的なメモです。
gihyo.jp に掲載されているレポート
http://gihyo.jp/news/report/01/JavaOne2017
Publickey(@Publickey)
http://www.publickey1.jp/blog/17/javaone_2017_keynote.html http://www.publickey1.jp/blog/17/javaproject_amberjavaone_2017.html
Takaaki Sugiyama さん(@zinbe)
http://nebuta.hatenablog.jp/entry/2017/10/02/161954 http://nebuta.hatenablog.jp/entry/2017/10/04/233841 http://nebuta.hatenablog.jp/entry/2017/10/07/205217
きしださん(@kis)
http://d.hatena.ne.jp/nowokay/20171002#1507028477 http://d.hatena.ne.jp/nowokay/20171003#1507163551 http://d.hatena.ne.jp/nowokay/20171004#1507329281 http://d.hatena.ne.jp/nowokay/20171005#1507599558
新・小僧さん(@toastkidjp)
https://reminiscencesoftoastkid.tumblr.com/post/165957550938/javaone-2017-day-1-flash-report https://reminiscencesoftoastkid.tumblr.com/post/165993641483/javaone-2017-day2-flash-report https://reminiscencesoftoastkid.tumblr.com/post/166028869458/javaone-2017-day3-flash-report https://reminiscencesoftoastkid.tumblr.com/post/166063657828/javaone-day4-flash-report https://reminiscencesoftoastkid.tumblr.com/post/166097265923/javaone-day-5-flash-report
よこなさん(@ihcomega)
http://ihcomega.hatenadiary.com/entry/2017/10/02/182157 http://ihcomega.hatenadiary.com/entry/2017/10/06/082500
まーやさん(@maaya8585)
https://hotchpotchj37.wordpress.com/2017/10/02/javaone-2017-1%E6%97%A5%E7%9B%AE%E3%83%8F%E3%82%A4%E3%83%A9%E3%82%A4%E3%83%88/ https://hotchpotchj37.wordpress.com/2017/10/03/javaone-2017-2%E6%97%A5%E7%9B%AE-%E3%83%8F%E3%82%A4%E3%83%A9%E3%82%A4%E3%83%88/
Java9のモジュール化について考えてみた #java9
これは何か
モジュール化のメリットがよくわからなかったので、実際に手を動かしながら考えてみた。
seasar2時代から発展していない時代遅れの脳だと、以下の構成がしっくり来た。
モジュールの分け方
actionModule、formModule、serviceModuleの3つに分けてみる。
- actionModuleはformModuleとserviceModuleを参照できる。
- formModuleはactionModuleからしか参照できない。
- serviceModuleはactionModuleから参照できない。
これで、xxxFormをうっかり（わざと？）serviceModule内で参照することを防ぐことができる。
または、formModuleでの入力チェックを行うために、serviceModuleを呼び出してしまうという事故も防げる。
お互いのモジュールの役割分担が出来るので、役割が分かりやすくなるかもしれない。
クラスパスの制御でもそれ出来るんじゃん？
今までは確かにクラスパスに追加する／しないでコントロールできたが、モジュール作成者の意図に沿ったものとは限らなかった。
今回、module-info.javaに依存関係を明記できるようになったことで、モジュール作成者の意図が伝えやすくなる。
思考をまとめてた時のソース
aaaActionModule
- Action.java
package action.project; import form.project.Form; import service.project.Bean; import service.project.Service; public class Action { public static void main(String... args) { Form form = new Form(); form.setName("aaa"); Bean bean = new Bean(); bean.setName(form.getName()); Service service = new Service(); service.execute(bean); } }
- module-info.java
module aaaActionModule {
requires aaaFormModule;
requires aaaServiceModule;
}
aaaFormModule
- Form.java
package form.project; public class Form { public String getName() { return name; } public void setName(String name) { this.name = name; } private String name; }
- module-info.java
module aaaFormModule {
exports form.project to aaaActionModule;
}
aaaServiceModule
- Bean.java
package service.project; public class Bean { public String getName() { return name; } public void setName(String name) { this.name = name; } private String name; }
- module-info.java
module aaaServiceModule {
exports service.project to aaaActionModule;
}
