花粉症治療薬シダトレンの体験談

結論

治療開始して3年たった結果、ほとんどスギ花粉を感じなくなった。
花粉から解放されて最高

シダトレンって何？

2014年から保険適用で購買できるようになった薬。
スギ花粉症を対象とした減感作療法（アレルゲン免疫療法）薬「シダトレン®スギ花粉舌下液」薬価収載および新発売のお知らせ | 鳥居薬品株式会社

シダトレンの概要

  • スギ花粉を毎日摂取して、アレルギー反応を抑えていくことで治療する薬
  • 病院で半年に1回採血して、アレルギー反応数値を計測する。数値が高い=アレルギー反応が強い
    • 上手くいけば、徐々に上記の数値が低くなる

治療の流れ

花粉症のシーズン以外なら開始できるらしい。
私は2015/6から治療開始した。

  1. 採血して、アレルギー反応の強さを計測する
  2. 最初は濃度の低い薬から開始
  3. しばらくすると濃い薬に切り替え
  4. 半年に1回ぐらい採血して、スギ花粉へのアレルギー反応数値を計測する

効果

  • 2015(治療前)
    • 鼻水とまらない
    • 目が痒くて涙止まらない
  • 2016(治療から8か月ぐらい)
    • マスクしていれば、鼻水はあんまり反応しない
    • 目が痒いけど我慢できるレベル
  • 2017(治療から20か月ぐらい)
    • 花粉の多い日に鼻水が出るのと、目がちょっと痒くなる
  • 2018(治療から32か月ぐらい)
    • ほとんど花粉に反応しなくなった
    • 花粉の多い日に外に出たら、ちょっとくしゃみが出るぐらい

注意点

  • 効果が出ない人がいるらしい
  • 最初に接種する場合は朝がおすすめ
    • 副作用が出ても病院にすぐに駆け込めるから
    • 朝起きて顔を洗ったらすぐにシダトレン接種するなど

感想

治療を開始して効果が判明するまで長いけど
僕の場合は年々花粉症に反応しなくなっていて最高

ITS健保 保養施設での越後湯沢旅行 #宿の申し込み編

概要

お酒飲んで、美味しいもの食べて、温泉入りたい人生を送りたくなったために、
ITS健保の施設を利用して旅行してきたので、そのメモを残します。

まずは宿の申し込み編から。

宿を決める

ITS健保では、保養施設 | ［ITS］関東ITソフトウェア健康保険組合から宿を選べます。
ここでは代表的な3つのタイプだけ紹介。

　
　

今回は、お酒と温泉と美味しい食事がテーマであり
会社の同僚と安く行きたいことから
酒蔵が近くにあり、宿自体に温泉がある
直営・通年・夏季保養施設のトスラブ湯沢 | ［ITS］関東ITソフトウェア健康保険組合
に決定。

申し込む

申し込みから利用まで | ［ITS］関東ITソフトウェア健康保険組合
には記載されていますが 、実際に行う流れを紹介します。

予約方法を決める

ITSでは、2ヶ月以内なら部屋が空いている日付を選択するか、
3ヶ月先の抽選予約を申し込む必要が有ります。

　
　

今回は8名参加ということで空いている日付が無かったので、
3ヶ月先の抽選予約を申し込みました。

3ヶ月先の抽選予約を申し込む

抽選予約できる期間は決まっており
申し込みから利用まで | ［ITS］関東ITソフトウェア健康保険組合
にて事前に確認します。

今回は、平成29年(2017年)1月分を予約したかったので、
実際の予約申し込みは平成28年(2016年)10月31日～11月7日の間に行いました。

以下のURLから、トスラブ湯沢を選択し、項目を入力します。
この辺は記憶が怪しいので、間違ってたらすみません。

  • WEB申請メニュー
  • 入力項目
    • 利用対象月
    • メールアドレス

　
　

上記で申請すると改めて、以下のようなメールが届くと思います。

-----------------------------------------------------------------------
本メールは、自動的に配信しています。
こちらのメールは送信専用のため、直接ご返信いただいてもお受けできません
ので、あらかじめご了承ください。
-----------------------------------------------------------------------

メールアドレスの確認を行いました。

以下のURLにアクセスしてトスラブ湯沢　2016年度1月分申込の手続きを行ってください。

https://専用申し込みのURL

　
　

上記のメールのURLにアクセスし抽選申し込みの詳細を入力します。

  • 入力項目
    • 自分の情報
      • 事業所記号
      • 被保険者番号
      • 申込代表者名(カナ氏名)
      • 生年月日
      • 性別
      • 続柄
    • 人数、部屋割り(4, 6, 8人部屋)
  • 入力の注意点
    • 事業所記号と被保険者番号については、
      健康増進・保健施設 | ［ITS］関東ITソフトウェア健康保険組合
      のQ1を参考にしてください。
    • 部屋について
      • 人数が多い場合は6人部屋だと、和室+洋室が合体した大きい部屋になり、
        部屋内で飲んだりゲームするときには便利です。
        • 洋室2人ベッド、和室4人布団
      • 4人部屋は、洋室1つに4人が寝ることになります。
        • 洋室2人ベッド、2人ソファーベッド 　
          　

入力が終わると、確認メールがきます。
確認メールで、自分の申込受付番号をメモしておきましょう。
あとは、抽選結果のメールを待つだけです。
　
当選メールが来る日付は
申し込みから利用まで | ［ITS］関東ITソフトウェア健康保険組合
に記載されています。

　
　

抽選で当選したら、宿泊者の情報を登録する

以下のようなメールがきたら、おめでとうございます。
早速メールのURLにアクセスし、宿泊者情報詳細を登録しましょう。

以下の申し込みについて当選されましたのでご連絡いたします。

申込受付番号　xxxxxx
利用施設名　　トスラブ湯沢
利用日　　　　2017/01/xx より 1泊


以下のURLから宿泊者の詳細情報を必ず登録してください。対応ブラウザ以外では、登録できない場合があります。
その場合は健康増進サービスセンターにご連絡ください。
https://宿泊者情報詳細入力画面のURL

　
　

宿泊者情報詳細入力画面のURLでは以下の情報を入力します。
ただし、宿泊者全員の個人情報が必要です。
各人にITS健保の宿の予約に必要なことを説明しつつ
以下の項目を教えてもらいましょう。

  • 入力項目
    • 宿泊者全員の情報
      • 事業所記号
      • 被保険者番号
      • 氏名(カナ氏名)
      • 生年月日
      • 性別
      • 続柄
  • 注意点

　
　

利用案内を確認し、その他の情報を宿にFaxする

宿泊者情報詳細入力を完了すると、 以下のメールが届きます。

申込受付番号xxxx

トスラブ湯沢　2016年度（2017年）1月分申込について宿泊者情報の登録を確認しました。
以下のURLより利用案内をダウンロードしてください。
※内容は必ずご確認ください。
※プリンターの設定により承認書が印刷できない場合があります。
　その場合は出力される承認書のサイズに合わせてプリンターを設定してください。

https://利用案内のURL

利用当日はフロントにて保険証（コピー不可）を必ずご呈示ください。

　
　

利用案内のURLにアクセスするとPDFがダウンロードできます。
PDFには、宿での注意事項が記載されているので確認しましょう。
またPDFを印刷後に夕食・朝食(メニューや時間)について記載し、
PDF内の番号へFaxしましょう。
　
ちなみにトスラブ湯沢ではコースを選べますので
レストラン（トスラブ湯沢） | ［ITS］関東ITソフトウェア健康保険組合
どれを食べるのか、Faxする書類に記載する必要が有ります。

注意点

もしキャンセルする場合は、以下のようなルールになっていますので、ご注意を。

  • 利用日の9日前～利用日前日まで: 利用料金の50％
  • 利用日当日: 利用料金全額

　
　

宿の予約だけで長くなったので、今日はここまで。
次回は、酒蔵、外食、日帰り温泉の手配について書きます。

Maven+JDK6での、peer not authenticated

Maven(3.0.3)+JDK6において実行してたら、repository.apache.orgにアクセスした時に、以下のエラー発生した模様。

[WARNING] Could not transfer metadata commons-collections:commons-collections:4.0-SNAPSHOT/maven-metadata.xml from/to apache (https://repository.apache.org/content/groups/snapshots/): peer not authenticated
[WARNING] Failure to transfer commons-collections:commons-collections:4.0-SNAPSHOT/maven-metadata.xml from https://repository.apache.org/content/groups/snapshots/ was cached in the local repository, resolution will not be reattempted until the update interval of apache has elapsed or updates are forced. Original error: Could not transfer metadata commons-collections:commons-collections:4.0-SNAPSHOT/maven-metadata.xml from/to apache (https://repository.apache.org/content/groups/snapshots/): peer not authenticated

　
　
　
peer not authenticatedと初めてのエラーだったけど、 証明書関連の問題かと早とちりして、ローカルのJDKに証明書のkeystoreに追加

$ openssl s_client -showcerts -connect repository.apache.org:443 </dev/null 2>/dev/null|openssl x509 -outform DER > repository-apache-org.cer
$ ${JAVA_HOME}/bin/keytool -import -trustcacerts -file repository-apache-org.cer -keystore ${JAVA_HOME}/jre/lib/security/cacerts -alias repository-apache-org -storepass changeit

　
　
　
でも、Mavenが、まだ失敗するので、調査。（同じエラーメッセージでた）
とりあえず、内部でどんなエラーでるのか、以前作成したscriptでcheck。

$ export JAVA_HOME=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
$ git clone https://github.com/hdkshjm/check-java-trusted-store.git
$ bash ./check-java-trusted-store/bin/access_ssl_test.sh -u https://repository.apache.org -c ${JAVA_HOME}/jre/lib/security/cacerts
JAVA_HOME=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
certs file=/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security/cacerts

Exception in thread "main" javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
    at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1747)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1708)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1691)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1222)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1199)
    at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:476)
    at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:166)
    at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1195)
    at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:234)
    at SSLClientSample.main(SSLClientSample.java:23)
Caused by: java.lang.RuntimeException: Could not generate DH keypair
    at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:114)
    at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:559)
    at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:186)
    at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
    at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:943)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1188)
    at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1215)
    ... 6 more
Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive)
    at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
    at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
    at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:107)
    ... 13 more
fail to access https://repository.apache.org

　
　
　
Prime size must be multiple of 64, and can only range from 512 to 1024 (inclusive) というエラーメッセージから こことか ここに関連するかと思い、
最終的には、JDK-6521495 : Lift 1024-bit long prime restriction on Diffie-Hellmanに当てはまるかと推測。 JDK7だと、これによって、7u85で修正されている。 　
でも、推測は外れた模様。 上記のfix前の7u4で試したところ、上記エラーメッセージは表示されなかった。。。。
(7u4では同じエラーメッセージが表示され、7u85では表示されないと想定してた) 　
　
そもそもEOLを迎えているJDK6を使うべきではないので、これ以上調査するのを止めてJDK7使うことで解決とした。
これ以上調べても、結局JDK7or8使うことが解決策になるだろうと思う。 時間があったら、もうちょっと調べてみよう。

Maven実行時のsun.security.validator.ValidatorException

Mavenを実行してたら、teklabsにアクセスした時に、表題のエラー発生

[WARNING] Could not transfer metadata asm:asm/maven-metadata.xml from/to gwt-i18n-server (https://service.teklabs.com/nexus/content/repositories/public-releases/): Error transferring file: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

　

https://service.teklabs.comの証明書を見たところ、2015/09/21に更新した模様
簡単なscript書いて、確認したところ、JDKのkeystoreが、teklabsを信用していない様子

$ git clone https://github.com/hdkshjm/check-java-trusted-store.git
$ bash ./check-java-trusted-store/bin/access_ssl_test.sh -u https://service.teklabs.com
Exception in thread "main" javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

　

解決方法は2つあって
1. 社内のNEXUSでreverse proxyする
2. JDKのkeystoreに、teklabsを追加

1の方が確実なんだけど(NEXUS側で証明書について対応するので、JenkinsとかローカルのPCのJDKに変更不要)
とりあえず、2の方法での対応方法をmemoしておく

$ openssl s_client -showcerts -connect service.teklabs.com:443 </dev/null 2>/dev/null|openssl x509 -outform DER > teklabs.cer
$ ${JAVA_HOME}/bin/keytool -import -trustcacerts -file teklabs.cer -keystore ${JAVA_HOME}/jre/lib/security/cacerts -alias teklabs -storepass changeit

2015-04-08 Java Day Tokyo 2015 のメモ

とりあえず、メモ

間違っているところあれば、ごめんなさい

 

ゴールドマン・サックスのJavaへの取り組み 

  • 資料
  • hash
    • #jdt62
  • Javaに取り組んでる
    • 社員の25%がエンジニア
    • scalaを早期（2003?）から利用
    • GS Colllectionsを早期から着手
      • lambdaを見据えて設計
      • 2012 に上記をOSS化
    • OpenJDKで開発してます
      • 190GBのheapとかあるので、JVMの仕様をしらないと、開発、運用できないの
      • ソースを観れるので、以下を実施できるよ
        • 本番での障害対応
        • 機能改善
        • セキュリティの対応
        • bug fixのfeed back
      • 主な活用
        • トラブルシュート、チューニングのため
        • リサーチして、事前にアプリに活用できるか検討
      • トラブルシュート
        • クラッシュダンプ解析
        • ソースから、デバッグ用のbuild作成する
        • 緊急時は、patchをあてたbuildを作成するが、基本はOpenJDK本家にパッチを投げてる
        • JVM TI Agentのトラブル
          • JVMがクラッシュした
          • デーモンスレッド上に、スレッド終了時のクラスロードで発生する？(ちと、聞き取れなかった)
          • コードを確認したら、以前のopenjdkのbug fixで終了時のcondition checkが追加されたが
            周辺のユーティリティでは、追加されてないみたいなので、追加するpatchを本家に送った
      • 研究事例
        • 圧縮OOP
          • 参照Objectを64bitじゃなくて圧縮32bitで参照できる
          • 64bitだと、メモリを食うので
            以前のOpenJDKでは32bitを３bit shiftでmem 32GBで使える
          • GSが改良して４bit shiftでmem 64GB使えるようにしたpatchを本家に投げた
            あと、このJVMのオプションを使うよう、社内にうながした
    • GS　Collections