home ホーム search 検索 -  login ログイン  | help ヘルプ

find 検索

11 - 20 / 1320    [|<]  [|<]  [<]  1  2  3  4  5  6  7  8  9  10   [>]  [>|][>|]
タイトル/名前 更新者 更新日
Java/Maven3/Version Range "[3.0.0, 3.1.0)" などの表記について msakamoto-sf 2019-01-04 14:33:16
Java/Quartz Job Scheduler 参考メモ msakamoto-sf 2019-01-04 11:11:22
技術/Security/mitmproxy (Python製 HTTP/1, HTTP/2, WebSocket プロキシ) (URLメモ) msakamoto-sf 2019-01-04 10:46:14
日記/2019/01/03/Slackへのソフトウェアリリース情報収集の勉強メモ msakamoto-sf 2019-01-03 22:08:07
Java/"Google Java Style" とビルドシステムからの一括フォーマッタ "Spotless" 関連メモ msakamoto-sf 2019-01-02 19:17:08
Java/Java8u60でのラムダ式引数名のリフレクション対応を活用したクールなMapビルダーの参考URLメモ msakamoto-sf 2019-01-02 18:53:14
日記/2019/01/02/IntelliJ IDEA の雰囲気を掴む msakamoto-sf 2019-01-02 18:37:53
日記/2019/01/02/ブログとYakiBikiの今後について msakamoto-sf 2019-01-02 15:09:07
Java/IntelliJ IDEA/プラグイン参考メモ(2018-12時点調査段階) msakamoto-sf 2019-01-01 09:59:49
Java/Springでの Server-Sent Events, WebSocket 参考メモ(2018-12月頃) msakamoto-sf 2019-01-01 09:27:02
ソート項目 / ソート順     1ページ 件ずつ表示

Java/Maven3/Version Range "[3.0.0, 3.1.0)" などの表記について  ↑

所有者: msakamoto-sf    作成日: 2019-01-04 14:28:38
カテゴリ: Java Maven 

pom.xmlでの <version> タグの書き方で、バージョンxx以上の最新などレンジを指定できる書き方がある。
以下のような書き方ができる。 

<version>[1.0.0,)</version>
<version>[1.0.0,2.0.0)</version>
<version>LATEST</version>
<version>RELEASE</version>

参考:

ただ、Eclipseのm2eでたまたま <plugin> の <version> で上記表記を試したところ、m2eのライフサイクルがうまくこれを認識してくれなかったりした。あまり使わないほうがいいのかもしれない。
よって、実際に使うときはそもそも本当にこの表記が必要なのか？また、IDEなど周辺ツールが対応しているか？を検証する必要がありそう。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-04 14:33:16
md5:02ad91e94015bee4555789e28051e97c
sha1:b9ecab73808a18edeee6d7c9d4b1f21eacba6d3c

Java/Quartz Job Scheduler 参考メモ  ↑

所有者: msakamoto-sf    作成日: 2019-01-04 11:11:02
カテゴリ: Java 

Javaでのジョブスケジューラとして Quartz というライブラリが有名なので、参考URLなどメモ。

お仕事で akka-quartz ( https://github.com/enragedginger/akka-quartz-scheduler ) を使ったことがあって、そちらではcron形式での定時実行を動かしてた。
使い込むと、もっときめ細かいジョブ制御ができそう。

日本語参考記事：


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-04 11:11:22
md5:3d814d9238bd93187a1b4807dba7d172
sha1:cb3c6fb91716ec4c6ad30c9b9a36bc92e19aa2e0

技術/Security/mitmproxy (Python製 HTTP/1, HTTP/2, WebSocket プロキシ) (URLメモ)  ↑

所有者: msakamoto-sf    作成日: 2019-01-04 10:44:04
カテゴリ: HTTP Python SSL/TLS セキュリティ ネットワーク 

Python製の HTTP/1, HTTP/2, WebSocket 対応MITMプロキシ。良さそう。
しばらく前にチェックしたときはターミナルUIだけだったが、最新だとWebUIも備え、Windows版ではインストーラも提供されていて、かなり使いやすくなった感じ。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-04 10:46:14
md5:8621500eb3644308d0f74d04a5d927b8
sha1:e40eba658273131aeb6a401c0981155b2956346d

日記/2019/01/03/Slackへのソフトウェアリリース情報収集の勉強メモ  ↑

所有者: msakamoto-sf    作成日: 2019-01-03 22:06:46
カテゴリ: Slack 

最近のソフトウェアリリース情報を収集する方法の勉強メモです。特にまとまってませんがダラダラと書いてきます。
主に Java エコシステム周りを中心とした収集方法を想定しています。

  • Twitter : リリース情報以外のアカウントも沢山フォローしてるので、情報が埋もれる。
    • リストで管理した上で、後述の Zapier でリストからslackに送るなどが可能となる。ただ、これも後述の通りZapierは無料枠では厳しいものがあったのでやめた。
  • mailing list : OpenJDKがMLでマージcommitなどを配信している。
    • 後述の通り、購読してるMLを Email -> Slack 連携アプリに転送すればいけそう。
  • RSS/ATOM Feed : ブログなどでは未だに活用されている。RSS フィード -> Slack連携アプリも利用できるので、今でも活用できそう。
    • 後述の通り GitHub の Release ページでもRSSフィードがこっそり埋め込まれてるので、公式のブログやTwitterがなくても、Release情報のフィードを収集することが可能。

収集先としては・・・

  • Twitter : 情報が埋もれる。
  • メール : これも情報が埋もれるし、いちいち目を通そうとしてしまい疲れる。
  • Feedly : 一時期使ってたが、これも全部目を通して既読にしようとしてしまい、疲れる。
  • Slack : これがいいかも。

ポイントは、「目を通そうとして疲れてしまわないかどうか？」かもしれない。
メールやFeedlyだと、メールorフィード一個一個で未読/既読がわかってしまうため、どうしても「目を通す」意識が発生してしまう。
Slackのチャネルに適当に流してる状態なら、「全部まとめてざっと見て終わり」になる。つまり、チャネルをざーっとスクロールするだけで既読状態になるので、精神的な負荷が低い。
あと、実際に職場のSlackでもそうしたニュースを流し込んでるチャネルがあり、それを実際に見てて、それほど「目を通すこと」を意識することなく低い負荷で流し読みできているので、自分にはそれが向いてそう、という感じがしてる。

→ということで、個人で初めてSlackのワークスペース作成した。

まず Twitter -> Slack への集約を試してみたが・・・これ、結局やめた。

続いてRSSフィード購読を試してみた。

これは無難に使えそう。以下のフィードを試しに購読させてみた。・・・まぁ、年始ということもありすぐには動きは出てこないので、数日ちょっと様子を見てみる。

メーリングリストをSlackに流す：

実際に以下のMLをsubscribeし、GmailのMLフィルタからslackの環境設定で取得した転送先メールアドレスに転送してみる。

→ とりあえず数件、slackbotに流れてきてるので、あとはしばらく様子を見てみる。

他参考：


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-03 22:08:07
md5:48adf2b878e6190b394099815b197ada
sha1:a40bbbd4664c7c51deee879c4a91211e9569778d

Java/"Google Java Style" とビルドシステムからの一括フォーマッタ "Spotless" 関連メモ  ↑

所有者: msakamoto-sf    作成日: 2019-01-02 19:16:46
カテゴリ: Java 

IntelliJ IDEAのフォーマッタとか調べてたら、"Google Java Style" というのが出てきた。
これらしい。

Google謹製のフォーマッタツールも公開されてる。

Checkstyle向けのXMLも、Checkstyle公式からDLできるらしい。

参考:

これらを使えば、IDEから手軽にフォーマットできるし、checkstyleで一括チェック・レポートも生成できる。

一歩進んで、ビルドシステム側で、そもそもcheckstyleの前に一括してチェックしたいし、IDEでちまちまフォーマットしてくよりは、設定変えたときに一括して再フォーマットしたい。
そんな要望を実現するために "Spotless" という GradleやMaven向けのライブラリが開発されてた。

参考:

これらを活用することで、フォーマット関連の作業を最大限効率化できそうなので、いつか試してみたい。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-02 19:17:08
md5:99c04e1233e0841a6b88c78ce987a55c
sha1:6afa25e9f3ea114125d72a4956577833d328edc4

Java/Java8u60でのラムダ式引数名のリフレクション対応を活用したクールなMapビルダーの参考URLメモ  ↑

所有者: msakamoto-sf    作成日: 2019-01-02 18:52:57
カテゴリ: Java 

参考:

何ができるようになるか？： 

    @Test
    public void java_hash_literal() {
        Map<String, String> hash = hash(
            hello -> "world",
            bob -> bob,
            bill -> "was here"
        );

        assertEquals("world", hash.get("hello"));
        assertEquals("bob", hash.get("bob"));
        assertEquals("was here", hash.get("bill"));
    }

    public static <T> Map<String, T> hash(NamedValue<T>... keyValuePairs) {
        Map<String, T> map = new HashMap<>();
        asList(keyValuePairs)
            .stream()
            .forEach(kvp ->
                map.put(
                    kvp.name(),
                    kvp.value())
                );
        return map;
    }

(via : https://github.com/benjiman/lambda-type-references/blob/master/src/test/java/com/benjiweber/HashLiteralExample.java )

なんとなくしか理解してないが、ラムダ式の引数名をリフレクションで取り出せるようになったのを活用して、key -> value をラムダ式に見立てれば、key をラムダ式の引数名として取り出せるよね、それでクールなMapビルダー作れたよ！という話らしい。
まぁ空白とか記号混じりは厳しそうなのである程度制限はあると思うが、アイデアとしては面白い。

・・・まぁ、これ使うくらいならドメイン特化したビルダー作るかもしれないけど・・・。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-02 18:53:14
md5:b1f1cb66a1292b4a3d7984071d6f59a5
sha1:c476d0e872c2313fa3077f1a2bcc12ebc8fd0670

日記/2019/01/02/IntelliJ IDEA の雰囲気を掴む  ↑

所有者: msakamoto-sf    作成日: 2019-01-02 18:36:38
カテゴリ: IntelliJ IDEA 

IntelliJ IDEAの雰囲気を掴むために、だらだらとググったり、軽くHello Worldを手元で触ったり既存Mavenプロジェクトをインポートしたりしたメモ。

3行でまとめ：

  1. Kotlin, Scala, Android開発するなら鉄板。エコシステムの中枢だから。
  2. Community Edition は商用利用可能。
  3. JavaEE や Spring でガッツリ開発するなら Community Edition では力不足で、有償製品であるUltimate版を購入したほうが良い。

Eclipseユーザからの移行ガイド系:

もちろん、中にはEclipseに戻ってきた人もいるようで・・・。

機能は豊富・・・なのは当然として、ショートカットキーや補完機能が豊富。

またヘルプドキュメントもしっかりしていて、日本語サイトもバッチリ。

ぶっちゃけ、ググるくらいならその前に上記日本語ドキュメント読んだ方がよほど勉強になると思われ。

最近は個人/仕事とも、Spring FrameworkやSpring Bootを触ることが多い。
基本的にはどれも普通のMaven/GradleのJavaプロジェクトなので、読み込んで実行する分にはIDEAでも問題ない。(jarビルドの場合は。warビルドにしてTomcat等にデプロイするとなると、Community Edition ではTomcat等のアプリケーションサーバの実行が未対応っぽいので、Ultimate版が必要かもしれない)

ただし、Spring Boot のプロジェクト作成については Community Edition 版は未対応。Ultimateなら対応してる。

Spring Boot のdevtoolsも、Community Edition でなんとか使えるっぽい。

Spring開発については、公式からは Eclipse ベースの Spring Tool Suite (STS)が提供されている。

今はこれを使っているのだが、IntelliJ IDEA の、それもUltimate版になると Thymeleaf のテンプレートでThymeleafの補完が使えたり、SpringにおけるDIの依存関係のビジュアライズなど使えるっぽい。

これが結構嬉しいかもしれない。

ぶっちゃけ、Eclipse(= STS)でも問題ないっちゃ問題ない。
ただ、ガッツリ開発に集中するとなると、IDEAの細かいところまで行き届いた一貫性のあるIDEとしてのエコシステムの完成度や、キーボードショートカット・補完機能による開発(体感)効率の向上は無視できない。

言い方を変えると、Eclipse(or STS)では無料 + 開発者自身で足りてない部分をアレコレリサーチして作り込んだり対応するコストがあるが、IDEAの場合は有料の代わりにIDEA内ですべて完結するようになっている、とも言える。
価格としても2019年1月時点で Ultimate版のOrganization向けが1ユーザ/年で499ドルと、安くはないが、飛び抜けて高いわけでもない絶妙な値付けになっている。
よって本気で開発にリソース投下するなら、最高の装備としてUltimate版を購入するというのは十分有効な選択肢に思われる。

まぁEclipseでも無料で戦えるじゃん！と言われるかもだけど、年額499ドルは、無料の代わりに払う諸々のコストを札束でぶん殴って十分お釣りがくる値付けだと個人的には思われる。

例えるなら、熟練兵でゲリラ戦するならEclipseでもそりゃ戦えるけど、年額499ドル払うだけで新兵を熟練兵とまではいかずともそれなりにブーストできるわけ。
それなら最初から熟練兵に499ドルの最新兵器を与えれば、最強じゃね？という話。

一言でまとめると、金の力は偉大。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-02 18:37:53
md5:c8cf16df4db72a71907f94d28a20a283
sha1:d1d983ab11655317a72588780d783fb5dea1dc53

日記/2019/01/02/ブログとYakiBikiの今後について  ↑

所有者: msakamoto-sf    作成日: 2019-01-02 15:03:01
カテゴリ: YakiBiki 

このブログのために自作したYakiBikiだが、PHP4の最後の時代に作ったこともありいい加減古い。
PHP5にキャッチアップできてないのと、それゆえに、PHP7では多分動かない。

それ以外にも機能/設計面で厳しいところも多い。例えば・・・

  • 記事の更新時にACLキャッシュを再生成するため重い。
    • これが割とクリティカルで、気軽に記事を作れない・・・。
  • 常にACLを参照するのと、生成したHTMLのキャッシュ更新が走るため、記事を表示するだけでもレスポンスが重いときが多い。
  • プレビュー画面が無いのがいい加減しんどい。
  • 記事表示画面でも編集系アイコン・リンクを出力してるが、Google Botなどがこれらを辿った結果、ときどきGoogle Analyticsで大量の403アラートが出る。
  • Markdown対応してない。

もともとYakiBikiを作るときの目標として、小～中規模IT企業における社内Wikiという活用方法を想定していた。
そのためACLに注力し、その結果としてACLのキャッシュという形を仕込んだわけだが、これがnon-DB(独自ファイルストア)と相まり、1,000件を超えたあたりから記事の更新が数秒かかるようになってしまった。
それでもプレビューがあればまだマシだったが、プレビュー機能は手抜きで作らなかったし・・・。
そうなると、個人利用でSEOも気にしたパフォーマンスそこそこ出す必要のあるブログとしては、もはや時代遅れも大概な遺物となってしまっている。

社内Wikiというか社内ナレッジサイトなら、今なら esa.io もあるし、GSuite や Office365 などでクラウドストレージ兼ドキュメントシステムもある。
タスク/プロジェクト管理やナレッジ共有 Backlog もあるしオンプレなら老舗のredmineでも戦える。メンバー構成によってはGitHub系も選択肢に上げられる。

自分自身も、働く会社が、受託系で細かくACLを気にする必要のあるSE/PG中心SIerではなく、ある程度の期間自社メンバーと一緒に働く場所に身をおいていることもあり、ACLの必要性が薄れてしまった。
そうなると、ACLを重視したYakiBikiはもうオーバースペックというか要望的にアンマッチであり、会社で使うことも将来的にまず考えられない。

で・・・じゃぁ、どうすんねん？だが、方向性としては以下のいずれかが考えられる。

  1. PHP7へのマイグレーション & ACL機能削除による軽量化 & プレビューと下書き機能追加
  2. 別のOSSブログシステムへの移行 (WPとかその他OSSのシステム)
  3. GitHub Pages への移行(= Jekyll ベースの静的サイトジェネレータ)
  4. Qiitaやはてなブログや WordPress.com など外部ブログASPへの移行

ここでどうしても死守すべき要件は次の一点。

  1. 今のサイトのURLは死守する。(はてなブックマークや、現行URL資産で参照している外部サイトの価値を保全したい)

全く新しいサイトを新規作成して、そこで新しい記事を書いていく・・・のは、それはそれで問題ない。
が、「今のサイトのURLを死守」というのは別のOSSブログシステムやGitHub Pages(Jekyll)や、ましてやはてなブログ/WP.comでは実現できない。
(多分静的サイトジェネレータの一部では .htaccess 調整でリダイレクト対応とかできるかもしれないが、現行URLは1,000を超えており、.htaccessでそれだけのエントリのrewriteを管理するのは不可能)

つまり、「今のサイトのURLを死守」＝「今のサイトを引き続き独自アプリでメンテしてく必要がある」ことを意味する。

まぁ実際問題、"/"区切りの記事の階層化とか、プラグイン記法によるナビゲーションや階層化記事の一覧機能など、機能としてはそこそこ便利だし引き続き使いたい機能はある。
これを完全に捨て去るのは、個人的にも惜しい。

外部ブログASPについては・・・

  • プログラミングの記事であればQiitaで申し分無いが、ちょっとしたメモや、プログラミング/IT系以外の記事については書けない。よって、どうしてもQiita以外も併用する必要が出てくる。
  • はてなブログは、無料版はキーワードリンクが厄介。CSSとかで事実上無効化はできるが・・・。広告も消すには有料版が必要。ただ、有料版といえども、そもそもサイトの表示が（個人的な主観だが）微妙に重いときもあり、個人的に使うときに「個人的に好み」かと言われるとイマイチなところがある。
  • WordPress.com : 論外。
  • どちらにしても死守要件は適用できない。
    • 一応はてなブログではWP/MTの記事をインポートできるようにはなっているが、そもそも現行記事データは現行Wikiフォーマットの固まりでインポートしようが無いし、WP/MT形式のエキスポート機能自体が無いので作らないといけないしで超面倒臭そう。

つまり死守要件は適用できないので現行サイトには使えないし、新しい記事についてだけ外部ASPを使おうとしてもそもそも個人的に気に入ったASPが無い。

GitHub Page など静的サイトジェネレータへはどうか？これも .htaccess のrewrite問題 + 過去記事互換性問題が立ちはだかるのと、新しい記事についてだけ～というパターンでも、やっぱり静的サイトジェネレータだと執筆環境がWebではなくて、サイトジェネレータ + アップロードという手間がかかるので個人的には厳しい。

結局のところ、現行サイトのURLと記事生成の仕組み(現行Wikiシステム)を維持する以上、何を選んでも「現行システムのPHPマイグレーション」は避けられない。
プラス、現行Wikiシステムは今後も使いたい。
となれば、YakiBikiの軽量化 & モダナイズが総合的には最も満足度の点からも、コストの点からも優れている。(結局マイグレーションしなければいけないなら、その見返りとして現行Wikiシステムのメリットを享受し続けたい)
ただし、引き換えに、また5～10年後に同様にマイグレーションの必要が生じる。
が、まぁ、それはそれで、いいかな・・・と。なかなか難しいところはあるけれど、現行資産の保全が割と優先度高いので。

現行 "/view/(数値)" URLを Permanent Redirect で "/view/(数値).html" にしておいて、もしものときの静的HTMLアーカイブ対応に備えておく、というのも考えたが・・・
まぁ、しておくことはしておくが・・・
次回または次次回のマイグレーション時の検討課題として残しておく。

要するに、超長期的には静的HTMLアーカイブした上で GitHub Pagesなどにごっそり上げる方向で考えたい。
しかし、そのための中期～長期のURL移行期間が必要なのと、その数年～十年単位の間での技術革新によりまた選択肢が増えることもあり得る。
そのため短期的にはPHPマイグレーションを主目的にしつつ、超長期に向けた移行期間への備えとして軽量化＆モダナイズを実行し、いざというときの静的HTMLアーカイブに対応しやすいようにシンプルなサイト構成となるよう改造する。

軽量化&モダナイズ&機能強化のアイデア例：

  • ACL機能削除, グループ機能削除
    • マルチユーザは残しておくが、単に「執筆者」以外の機能は持たず、記事の公開アクセス範囲には関連しない。記事はワールドワイドに公開するか、下書きか、どちらかで、下書きについても執筆者であれば全員が見れる。
    • このへんを削れると、性能面でだいぶ改善されるはず。
  • 画像/ファイル/URLアップロードについて、検索や最新一覧での表示対象外にしたい。
    • 今は一覧に出てしまうので、気軽に画像やちょっとしたファイルをUPできない・・・。それか、完全にdiscloseして、そういうのは外部ストレージに回したい・・・。
  • Markdown対応、現行Wiki記法の細かなバグ調整など
  • 下書き・プレビュー機能
  • カテゴリ管理や編集時の設定のモダナイズ
  • 記事のpermanent url を "/view/(数値).html" に変更
    • これが超長期に向けた、中長期の移行を見据えた短期的に実施可能な布石。
  • 検索機能を単純な一覧化 & タイトルやカテゴリ検索を、フロントエンド側のJSフィルタリング機能として実装しなおす。
    • フロントエンド側にカタログデータを出力して、ブラウザJS側でタイトル/カテゴリフィルタリングする形にしても実用上問題ない。SEOとしてそこまで追っかけてほしいわけじゃないし。
    • つまりサーバサイドレンダリングとしては単純なWiki一覧が出てくればよくて、まぁソート機能付きならベスト。で、検索というかフィルタリングとしてはブラウザのフロントJS + フロント用のフィルタリング結果を返すAPIで動的に行い、それは別にSEO考えなくていいのでOK。という形にする。
    • こうすることで、将来静的HTMLで凍結しやすくしておく。

→ここでの問題として、「現行、ワールドワイドには非公開の記事をどうするか？」問題が残っている。
これについては、現行のデータを洗い出した上で、非公開記事データは現状自分しか見れない状態なので、HTML or 記事そのままのテキスト状態で、Google Driveに入れておく、という程度で問題ないと思う。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-02 15:09:07
md5:bc5c6975d1af1bef87cec22097a450b4
sha1:0923bff3a91adf384f25ec296e3dab9048662085

Java/IntelliJ IDEA/プラグイン参考メモ(2018-12時点調査段階)  ↑

所有者: msakamoto-sf    作成日: 2019-01-01 09:59:19
カテゴリ: IntelliJ IDEA Java 

2018-12時点で、Eclipseでよく使ってる（というか必須の）プラグインでInteliJ IDEA版がどうなってるか軽くググった参考メモです。
リンク先について、Community EditionでもOKなのか商用版のみかは検証してません。調査段階のメモなので、今後実際に動かして確認してくかもしれません。

TestNG: JUnitよりはTestNGの方が実用的でシンプル、使い勝手が良いので愛用してます。

  • TestNG - IDEA Plugin
    • http://testng.org/doc/idea.html
    • IntelliJ IDEA 7 からIDEA本体にバンドルされてるようです。2018-12時点のCommunity Edition最新は 2018-3 でだいぶバージョン上がってるので、多分大丈夫じゃないでしょうか。

CheckStyle: IDEAだと、checkstyle.xml をソースコードフォーマッタにも反映できるのが良さげ。Eclipseだとここ、分断されてるので checkstyle.xml とは別に Java Editor の Code Formatter を手動で揃えないといけないんですよね・・・。

  • CheckStyle-IDEA - Plugins | JetBrains
  • Java - IntelliJ IDEAにCheckStyleプラグインを導入し、フォーマッタに反映する - Qiita
  • Google Java StyleをCheckstyleとIntelliJ IDEAに適用する手順メモ | takemikami's note
  • Google Java Style Guide
    • https://google.github.io/styleguide/javaguide.html
    • こちらが Google からの Java Style Guide ですが、わりと無難で最大公約数的な内容なので、受け容れやすそうです。一行100文字の制限だけ個人的にはちょっと厳しいかも？
    • ただ、ところどころにexception扱いがあるなど、checkstyle.xmlで完全にカバー・制約付けするのも難しそうなところもあるので、100%カバーは難しいかもしれません。

一個気になる機能として、Eclipseのcode formatterでは以下のような形でフォーマッタの適用範囲外を設定できる機能があります。 

// @formatter:off
...
// @formatter:on

checkstyleというよりはIDEのフォーマッタの機能になりますが、同等なものが IntelliJ IDEAにあるか若干気になりました。

→ありました。2018年最新版ならまず問題なさそう。

FindBugs or SpotBugsプラグイン → FindBugsならプラグインあり。SpotBugsについてはリクエスト中。

とりあえず、あるのはわかったので、後日時間があれば、実際に動かしてみたい。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-01 09:59:49
md5:ee5c6c80c76cfcba7a77afe02eca4e2f
sha1:d2e9b36b7f1b219387e971f97a2a70750e4ed3c3

Java/Springでの Server-Sent Events, WebSocket 参考メモ(2018-12月頃)  ↑

所有者: msakamoto-sf    作成日: 2019-01-01 09:25:10
カテゴリ: HTTP Java Spring Framework 

Springでの Server-Sent Events, WebSocket 参考メモ(2018-12月頃)

SseEmitter版:

WebFlux版:

SseEmitter版の方が簡単そう。


プレーンテキスト形式でダウンロード
現在のバージョン : 1
更新者: msakamoto-sf
更新日: 2019-01-01 09:27:02
md5:4a68854273f3da4a4e6743410b9035cc
sha1:b3f0d3bfbd525ab43f6a4e3ef465ec59d1c39907