システム開発で思うところ

Javaで主にシステム開発をしながら思うところをツラツラを綴る。主に自分向けのメモ。EE関連の情報が少なく自分自身がそういう情報があったら良いなぁということで他の人の参考になれば幸い

Kubernetesのメモ

k8s

www.slideshare.net

www.slideshare.net

www.slideshare.net

www.slideshare.net

github.com

speakerdeck.com

speakerdeck.com

speakerdeck.com

Istio

www.slideshare.net

サービスメッシュ

speakerdeck.com

その他

Payara and Hazelcast Japan Office Launch に行ってきました

glassfish.doorkeeper.jp

イントロ

  • HazelcastはJCacheの実装として使っている

  • HazelcastはAWSとAzureをまたがってもGridを共有できる。TCPが確立していればOK

  • Payaraサポートの中にHazelcastサポートも

メモ

前回、別の勉強会で遅刻したので今回は早めに と思っていたら、今度は早く着きすぎました。

会場受付が18時からだったのですが「入場できます」とのことで、何も考えず入場。

PayaraとHazelcastの方のお話が開始前からどんどんとされていきます。

「ん?まだ開始前なのに、こんなに話してて良いの?」などと思いつつ、人数が少ない中での話がされてて「ふむふむ」と思っていたのですが、どうやら「プレス向け」的な時間帯だったようです。。

今更ですが、部外者がシレっと入場してしまい、関係各位の方々申し訳ございませんでした。*1

Moving to MicroProfile and EE4J

  • EEが止まっている間にMicroProfileとして活動を続けたよ

  • JCPによる仕様策定はやめてCodeFirstにするよ

  • TCKcodeもOSSになるよ

  • ブランドとしての「Java EE」はやめるよ

メモ

その他詳細については、@n_agetsu さんの以下のスライドが詳しいので、そちらを見るのがお勧めです。

www.slideshare.net

Payara Server on the Cloud

  • Payara Server v5 (beta) を使ったデモがメイン

  • 管理コンソールは日本語対応

  • DataGridの実装がHazelcast

  • DataGridというメモリ上に自在にサービスを立てることが出来て、それをDASからコマンドで制御できる

  • --clustermode domain servername port --autobindtcp*2
    2018/2/1 訂正 --clustermode domain:servername:port --autobindhttp

枠外での質問

(短い時間で回答してもらったものなので、正確さは保証できません)

DataGridそのものの生存期間は?

DASが落ちてもDataGridそのものは残っていますし、その上のサービスも残っています。

DataGrid上のサービス(インスタンス)がすべて無くなったら、そのタイミングでDataGridが無くなります。

DASそのものの冗長化ってできるんですか?

PayaraとGlassfishは少なくとも出来なくて、ほかのEEサーバの多くも おそらく出来なかったはずです。

メモ

マイクロサービスは全てのインスタンスが分散であり冗長化をするものだと勝手に思っていたので、肝心のDASの冗長化については、少なくとも まだ不十分というのは ちょっと残念な気はしました。

デモで見せてもらったようなDASによるインスタンス管理はすごく便利に思えましたし、ALLinOneで管理できるんだったら、いろんなソフトの組み合わせによる習得や不具合への対策から解放されるから「EEサーバー(もしくは その設計思想)良いよね!」ってなる気がしました。

Hazelcast JET & Hazelcast IMDG

  • Hazelcast IMDGはOracle Coherenceみたいなものと思ってください。

  • JETはSparkみたいなもので、Sparkの2倍以上のスループット*3

  • サンプルコードをたくさん準備しているので見てください。

https://github.com/hazelcast/hazelcast-jet-code-samples

メモ

話を聞いた後で、CLOVERさんの記事を読むと、具体的には どういうことなのかっていうのが分かって より理解が深まりました。

Microservice meets Payara on k8s with Istio on Azure

  • Azureでk8sを使うんだったら AKS を使おう

  • AzureでPayaraServerをデプロイするときは war をデプロイしてください。内部のHazelcastが通信をしようとするため jar でデプロイするとうまく動かない。
    java -jar payara-microprofile.jar --deploy Hoge.war みたいなコマンドだったけど、メモしきれなかった。確実に何かが足りないのだけは分かるけど、、

2018/2/1 訂正

java -jar payara-microprofile.jar --hzconfigfile hazelcast-default.xml --deploy Hoge.war
  • 音声認識を使って「Azure」のサービスとも連携をするデモ

メモ

へぇーおもしろ。と思ってメモが疎かに。。

The Start of A New Future For Java

  • Java のLTSとかアップデートサイクルにおける注意事項を丁寧に説明
  • FlightRecorderやMissionControlもOSSになる

  • バイナリの提供は、今後 OpenJDKになって、しかも半年サイクルでサポートはされなくなる

  • 64bitサポートだけ。32bitもARMもサポートしない

  • でも、Azul Zule Java があるので安心!32bitもARMもサポートするし、最低10年サポートするよ

メモ

OracleJDK以外を考えたことは無かったけど(思考停止として)、色々なベンダーのJDKについて、もうちょっと調べた方が良いかもしれない。

あわせて、別の勉強会でも思ったけど、個人趣味開発であっても そろそろJavaVersion別のビルド用のCI環境について手を付けていったほうが良さそうな気がしてきた。

謝辞

@khasunuma さん
休憩時間での 突然の質問であり、またDASがどういうものか、ちゃんとわかっていない不躾な質問であったにも関わらず、丁寧に答えていただきありがとうございました。

@n_agetsuさん
片付け中に質問に答えていただきありがとうございました。

改めて、この場を借りてお礼申し上げます。

*1:おそらくですが邪魔はしていないつもりですが、ご迷惑であったらすみませんでした

*2:うろ覚えメモ

*3:色々すると10倍にも

オープンソースの脆弱性で不正アクセス、その責任は誰が負うのか?に参加してきました

オープンソースの脆弱性で不正アクセス、その責任は誰が負うのか? - マジセミ(参加者の役に立つ”本気”の情報提供セミナー) | Doorkeeper

ライセンスのこととか、ちゃんと聞く機会を設けることが大事だと思って参加してきました。

所用で5分ほど遅刻してしまいました。

さらっとメモ

オープンソースライセンスの類型化から見える法的リスク

  • 開発を外部に発注しても、最終責任は発注者になるので「知りませんでした」では済まされない

  • 表に出ていないだけで指摘を受けてリリース前に改修しているケースも

  • 動的リンクの場合でもGPLLGPLに従う必要あり、というのが公式回答

  • 著作と特許は別。特許について明記しているライセンスとそうじゃないライセンスがあるので注意を。OSSはコードが公開されているので侵害立証が容易。

  • 契約書に明示されていなくても当時の技術水準で対策を施すことが可能であるということで賠償することになった事例あり。IPAによる広報(セキュリティ対策のこと。SQLインジェクションはダメだよ、とか)が開発以前に出ていたことが根拠に使われた。債務不履行・重過失。想定以上にあっさり判決が出たという印象*1

  • Reactの問題となったBSD+パテントライセンスはOSSとしてNG。今は(V16から)ReactMITライセンスになっています。

  • さらっと凄いことを書いていたりするので原文は必ず目を通しましょう。

閉域接続で運用するIoTとOSSの密接な関係

  • 閉域接続って知らなかった。VPNのようにインターネットを介するのではなく、電話回線から直接閉域サービスへ接続する。

  • SIMによるDDOS攻撃って知らなかった。クライアントを落として何が嬉しいんだろうと思ったら、パケット量請求という詐欺行為が目的だった。えぐいなぁ。

  • CM的な感じはあったけど、知らないことが多かったし、SIM一枚から契約できるし(最低ランクだと月300円)、安全なIoTネットを考えるなら良いかもって思った。カード1枚から契約可能。

ツールを活用してソフトウェア開発の品質・生産性を向上する秘訣

  • 主催者のスポンサー枠的な感じ

OSS 使うとリスク!ってホント?!OSS と上手に付き合ってDevOpsを実現!

  • WhiteSourceの販売と、日本での導入会社さん(株式会社マインド)の話

  • 使用しているOSSのライセンスと脆弱性をチェックするサービス

  • コードをアップするのではなく、使用しているOSSの情報をハッシュにして送信する*2

  • オフラインでも使える。送信するのがハッシュ情報だけなので、オフラインで取得してハッシュ情報だけをネット環境に持っていけばOK。

  • 日本に上陸したのは2017年9月なので遅いけど、OSSライセンスと脆弱性を扱う会社としては古参。

  • 開発元はイスラエルの会社

  • コードの脆弱性を診断するのではなくて、CVEなどのOSSセキュリティ情報と使用されているOSSのマッチングによる診断。なのでOSS情報のハッシュだけあれば良い。逆にいうと、脆弱性診断ツールではないので勘違いしないこと。

  • OSS公式HPに乗る前の情報でも開発元として入手していてチェックしてされるケースもあり。この辺りは古参ソフトならではの情報収集というところ。

  • MosP*3で実施したら、公式HPにないものが検出されて、、みたいなことがあった。あと、いつの間にか使用しているOSSのライセンス条項が変わっていて競合が発生して改修することになった。でも気が付かずにリリースしていたら、、と思うと恐ろしい。

  • CVEじゃなくてWSっていう識別子が点いている場合は、WhiteSourceが独自に検出した脆弱性の識別子。つまり第三者報告を二次利用するだけでなく独自に診断情報を収集もしているということ。

  • 主要な言語は全て対応している。

  • 評価版もございます。

  • 今後、納品にあたってOSS一覧とあわせて、その脆弱性診断状況が納品条件になりうる可能性に備える際に有効な選択肢です。

  • OSS検査レポートサービスを始めたので、興味がある方はお問い合わせくださいませ OSS検査ツール/レポートサービス | 勤怠管理・人事給与システムのスペシャリスト|株式会社マインド

感想など(主にWhiteSourceに関して)

  • ライセンスに関する知見を得られて非常に有意義な時間を過ごせました(これは全体的な感想)。

  • お値段は最低利用で年間100万未満。決して安くはないけれど、Webサービスやパッケージ開発をしているのであれば必要コストだと思う。少なくとも同様のことを人間が確実にやることを想定したら月10万分の工数では無理。

  • maven使ったら、使用ライブラリと そのバージョン一覧を作ることは出来る(できるはず)。でも月10万の予算で膨大な脆弱性情報の確認まで含めると、それは無理だと思う。素直にツールを使った方が良い。

  • WhiteSourceの売り方について、個人的に思うところとしては、日本だったらベンダーが付加価値をつける名目でコストをかけて自己診断するツールとして営業するよりも、ユーザーによる品質評価ツールになりうるものとして営業した方がよさそう。弁護士さんの話でもあったけどライセンスによる賠償責任は発注者にとってもリスクだから。んで、ユーザー検収でNG出されたら、手戻りコストが半端ないのでベンダーが必要経費として自分達でも購入するという流れ。

  • アジャイル万歳で「動くものが正義」に、ライセンス意識が低い開発会社が重なることによるリスクを早めに摘み取るためにも使えるし、使った方が良い。例えばオフショアとかだと「コレ ベンリ」と勝手にライブラリを追加していたりするリスクを仕組みとしてチェックすることは大事。規約や口頭ルールで規律を求めるよりも、ツールで診断するという方が お互いのために良い。

  • MopSはOSSとのことなので、色々と落ち着いたらちょっとコードを見てみようかなぁと思ったり思わなかったり

*1:本当にこれで大丈夫なの?という雰囲気を感じました

*2:コードが外部に送信されるわけではないので安心

*3:株式会社マインドの勤怠管理システム

【雑記】自動運転を考える

お金がある人が、こんなことをしてくれたら良いんじゃないですかね、という ただの思いつきメモ。

ここから導入したら?

過疎地など地方のバス運行。

なぜ

  • ルートが決まっているので導入コストが低い。
  • 乗車履歴はIoTで管理(スマホでも良い)
  • バスの位置をGPSで把握できるようにすれば、乗車タイミングも降車お迎えも無駄がない

収益性について

運行本数が少ないがゆえに収益性が悪いところもあると思うので、逆に増やすことで自家用車よりも便利になったら、バス利用が増える可能性があるかも。(これは堀江貴文さんが、どこかで言っていたことの引用です)。

移動宅配ボックスとして使うことで、配送手数料を稼げるかも。利用者は受取バス停を事前に連絡をしておき、バスの中のロッカーをQRコードとかで解錠して荷物を受け取る。

その他

バスが遅いということで追い越したい車は、アプリで「追い越したいアピール」をしたら、バスが徐行して道を譲ってくれるようにすれば、イライラも解消。

完全自動運転じゃなくて、ラジコンみたいにリモートドライブでも良いと思う。これであれば「在宅ドライバー」も実現可能。

セキュリティのメモ

HTTPヘッダ

商用環境で設定しておきたいセキュリティ関連 HTTP ヘッダまとめ - A Memorandum

http://sinsengumi.net/blog/2012/04/httpservletrequestwrapper%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6%E3%80%81http%E3%83%AA%E3%82%AF%E3%82%A8%E3%82%B9%E3%83%88%E3%82%92%E6%94%B9%E5%A4%89%E3%81%99%E3%82%8B/

Spectre の脅威とウェブサイトが設定すべきヘッダーについて

Java EE セキュリティ

Java EE Security APIが街にやってきた! - Qiita

CSRFトーク

このWeb APIってCSRF対策出来てますか?って質問にこたえよう - Qiita

覚え書き: Rails で CSRF トークン検証エラーが出ることがある

さよならCSRF(?) 2017 - WAF Tech Blog | クラウド型 WAFサービス Scutum 【スキュータム】

静的コンテンツのトークンベースのアクセス制御 - Qiita

JSF

JSFにおけるXSS、XSRF対策 - kounan13の日記

シリアライズ

シリアライズ・フィルタリング

全般

何が必要か、というキーワードとして

基礎からのSpring Security | 株式会社カサレアル ラーニングサービス

どうしてリスクアセスメントせずに JWT をセッションに使っちゃうわけ? - co3k.org

Webサービスによくある各機能の仕様とセキュリティ観点(ユーザ登録機能) - Qiita

Webセキュリティ覚書 : "攻撃" 編 [ 初学者向け ] - Qiita

リダイレクト

これなら合格! 正しいリダイレクターの作り方:HTML5時代の「新しいセキュリティ・エチケット」(4)(1/3 ページ) - @IT

脆弱性

Spring Boot Jackson脆弱性メモ(Hishidama's Spring Boot jackson-databind issue 1723 Memo)

Struts2が危険である理由 - WAF Tech Blog | クラウド型 WAFサービス Scutum 【スキュータム】


Dockerのメモ

Windows10マシンにDocker Toolbox を入れて個人用の開発環境を作る - Qiita

dockerのデータボリュームとそのバックアップ方法 - Qiita

Dockerのデータ永続化関連について - Qiita

Data Volume と Data Volume Container - Qiita

DockerでポータブルなLinux開発環境(GUI付き)を構築する - Qiita

k8n

speakerdeck.com

GitHubにMavenを使って作ったJavaDocを公開

はじめに

GitHubMavenリポジトリを作成して 細かくパッケージを分割した開発できるようになったと喜んでいたのですが パッケージを分けたためにJavaDocのリンクが切れてしまう状態になってしまいました。

vermeer.hatenablog.jp

リンク切れについてはモジュールとして まとめてJavaDocを生成すれば対応できます。

ただ、これだとローカル環境でコードから生成しないといけません。

まぁ、それでも良いのですが自分自身が利用者となった時、どこかにJavaDocが一か所で見られる状態になっていたら良いなぁと考えていくと JavaDocGitHubで公開したら良さそうだな、と。

ということで やってみたことの まとめです。

ざっくり

  • プロジェクトにdocsフォルダを作成する(maven
  • ついでにオフライン環境でも使えるようにjarも作る(maven
  • ドキュメントを作成する(maven
  • docsフォルダに格納されている資産をソースとしたgh-pagesを作成する(GitHub

Maven

pom.xml

対象をまとめる

ローカル環境のプロジェクトのドキュメントを作成するプロジェクトからの相対位置を指定します。

<modules>
    <module>../base</module>  
    <module>../xml</module>
    <!-- 省略 -->
</modules>

モジュールをまとめてJavaDocを作成するための指定です。

<aggregate>true</aggregate>

JavaDocのための編集

ただ作るだけだったら何もしなくていいのですが、せっかくなので ちょっとした整形をしてみようと思います。

タイトルをつける

JavaDocの概要の一番上に表示されるタイトルは デフォルトではartifactIdversionで自動で編集されます。

私の場合、現状ではWeb上で公開する資産は最新のものだけを と思ったので タイトルを固定した表現にしようと思いました。

ついでにWindowのタイトルも一致させました。

<doctitle>${javadoc.title}</doctitle>
<windowtitle>${javadoc.title}</windowtitle>

概要・詳細を編集

package-infoのようなドキュメントをトップページに記載することで 全体の概要もしくは詳細の説明が記載されているリンクへの誘導を表現できます。

ドキュメント用のhtmlを作成します*1

/src/main/javadoc/overview.html

今回はmevenプロジェクトへのリンクを指定することで READMEページへ誘導する、という趣旨の編集をしました。

JavaDocと同様に、1行目が概要、2行目以降が説明として出力されます。

外部プロジェクトのドキュメントのリンク

自分のプロジェクトへのリンクはmodulesで参照すれば良いですが、外部プロジェクトの場合は公開されているリンク先を指定します。

<links>
    <link>https://docs.oracle.com/javase/jp/8/docs/api</link>
    <link>https://square.github.io/javapoet/javadoc/javapoet</link>
</links>

私は日本人なので、JavaSEのドキュメントも日本語の方が読みやすいです。 ということで、日本語の公開ドキュメントへのリンクにしました。

JavaPoet*2 も参照しているので、それも追記しました*3

FastClasspathScanner*4も使用していますが、JavaDocとしては表現されることはないので除外しています。*5

パッケージをグループ化

フラットなJavaDocは読みにくいので意味のある塊でまとめて表現すると良いと思います*6

<groups>
    <group>
        <title>Annotation Processor Core</title>
        <packages>org.vermeerlab.apt*</packages>
    </group>
    <group>
        <title>Annotation Processer with JavaPoet</title>
        <packages>org.vermeerlab.apt.element:org.vermeerlab.apt.javapoet</packages>
    </group>
    <group>
        <title>Annotation Processor Command</title>
        <packages>org.vermeerlab.apt.command.*</packages>
    </group>
</groups>

ドキュメントの出力先を指定

デフォルトのままだとtarget配下にJavaDocが作成されて資産管理対象外のままになってしまうということと、GitHubPageで参照するフォルダに常に作成されるようにしておきたい ということで出力先のパスを指定します。

<destDir>docs</destDir>

GitHubPageではdocs配下の資産を自動でgh-pageの対象資産としてくれます。

タイムスタンプを除去

デフォルトではJavaDocにタイムスタンプを埋め込むため、常にすべての資産が更新対象になってしまいます。

ということでタイムスタンプを除去する設定をしました。

<notimestamp>true</notimestamp>

ローカル環境用のjarの出力先

ドキュメントと同様、デフォルトのままだとtarget配下に作成されるので 出力先を変更します。

<jarOutputDirectory>jar</jarOutputDirectory>

フォルダ名 jar に作成します。

コマンド実行

mvn clean:clean javadoc:aggregate-jar

GitHub

参考にしたリンク通りなので・・

2016年新機能! GitHubのmasterブランチをWebページとして公開する手順 - Qiita

JavaDocページ

vermeerlab API

たとえば、こんな感じでGitHubのトップREADMEに指定おけば JavaDocのURLやjarの場所が分かりやすいように思います*7

GitHub - vermeerlab/javadoc

さいごに

個人的にはOSSJavaDocもWeb上で見られるようにしてほしいなぁ、と。

GitHubだとMarkdownはWeb上で見られるので良いですが、API仕様まで確認したいときに ちょっと切なくなるんですよね。

「どんなAPI仕様なのかな?」くらいの気持ちで読みたい側からすると 地味に手間というか。。

ローカルでビルドすれば良いだけかもしれませんが、開発環境を介せず見られる方がありがたいです。

例えば、OSSAPI仕様を調べよう(確認しよう)と思ったときに できれば 検索エンジン経由でWeb上で見られると 楽というか。

イメージとしては JavaSEのAPI仕様は検索エンジンで引っかかってくれるので有難いですよね?という感じです。

今回のケースだとJavaPoetJavaDocGitHubに上げてくれているのでJavaDocがイイ感じに作成できました。

そういうメリットもあります。

*1:作成パスはデフォルト通り

*2:GitHub - square/javapoet: A Java API for generating .java source files.

*3:こちらのプロジェクトもGitHubPageでJavaDocを公開していますね

*4:GitHub - lukehutch/fast-classpath-scanner: Uber-fast, ultra-lightweight Java classpath scanner.

*5:追記してもmavenの実行時に警告が表示されるだけですが、警告が出るのが私は嫌なので外しました。安全を考えて警告が出ても追記しておくという運用でも良いと思います。

*6:JSR 376(Java9 Jigsaw)で また表現が変わってくるとは思いますが、Java8までだと有効だと思います

*7:というか、ファーストユーザーである自分にとって分かりやすい