sphinx-javalinkを使ってSphinxドキュメントからJavadocへのリンクをはってみる

Sphinxで作ったドキュメントから、Javadocへのリンクをはれる拡張のsphinx-javalinkの使い方。
※昔書いた、sphinxからjavadocへのリンク簡単に貼れる拡張 - しおしおのほうが使い方は簡単なんだけど、Java8で作られたドキュメントへのリンクがうまくできない問題があったりする。

インストール

pipを使ってインストールする。

pip install sphinx-javalink

拡張を使えるようにする

conf.pyのextensionsにこの拡張を使えるよう設定を追加する。
下のように、javalinkを追加する。

extensions = ['javalink']

javalinkに対する設定をする

conf.pyにいくつか設定を追加する。javalink_classpathの設定はわりと面倒な感じがある。

# 設定を追加するためのimport
import javalink

# Java8で生成したドキュメントへリンクをはる（デフォルトだと7)
javalink_default_version = 8

# クラスを探すためのライブラリのパスの設定
# javalink.find_rt_jar()と書くと、JAVA_HOMEからrt.jarを探してくれる
# 自分のプロジェクトのライブラリに対してリンクを貼りたい場合は、
# そのプロジェクトのjarのパスかビルド後のクラスファイルが
# 出力されるディレクトリを指定する必要がある。
javalink_classpath = [
    javalink.find_rt_jar(),
    '/home/siosio/junit-4.12.jar'
]

# Javadocのリンク先を列挙する。
# 列挙しておけば、あとは良さげにリンク先を設定してくれるらしい
javalink_docroots = [
    'https://docs.oracle.com/javase/jp/8/docs/api/',
    'http://junit.org/junit4/javadoc/latest/'
]

rstを書いて・・・

javarefを使って、リンクをはれる。
メソッドに飛ばす場合は、クラスメイトメソッド名を#で区切る。（Javadocの@seeの書き方とかと一緒）

* こんな感じにリンクをはれる →  :javaref:`java.lang.Object`
* メソッドに対しては、こんなかんじになる → :javaref:`java.lang.String#valueOf(java.lang.Object)`
* Javaのライブラリ以外もいける :javaref:`@Test <org.junit.Test>` アノテーションにもとべる

ビルドして・・・

こんな感じに生成される。

IntelliJ IDEAのjump to colors and fontsが便利過ぎる件

いまいさんのこんなツィート見かけて、かなり便利そうなのでちょっと試してみた。

IntelliJさん，"Jump to Colors and Fonts"なんで便利な機能，いつの間に作ったんやｗ

— いまいまさのぶ (@masanobuimai) 2017年7月27日

なにが便利かというと、jump to colors and fontsを使うと、今カーソルがある要素の色設定にダイレクトで飛べるようにる。
これで、File | Settings | Editor | Color Schemeから、頑張って色設定を変えたい要素を探す必要がなくなる感じ。

なお、使えるようになったのは2017.2からだと思われる。

使い方

使い方は、色設定を変えたい要素にカーソルを移動して、Find Actionからjump to colors and fontsを選んであげます。*1

もし、複数の設定項目がある場合は、下の画像のようにどの設定に行くか聞いてくれるので、かなり親切です。

微妙に伝わりづらいような気がするけど、使ってみると便利さわかるかなと。

おわり。

*1:デフォルトはショートカットキーも割り当てられていないので、Find Actionからアクションを実行しないとダメ

Gradleのsonarqubeプラグインを使ってみる

Analyzing with SonarQube Scanner for Gradle - Scanners - Doc SonarQubeを使ってGradleなプロジェクトの品質チェックを行う方法。

sonarqubeプラグインを導入する

Gradleのbuildスクリプトに以下を追加する。(バージョンは現時点での最新)

plugins {
  id "org.sonarqube" version "2.5"
}

※sonarqubeプラグインに対する設定値などはこちら→SonarQube properties
なお、Gradleのデフォルト構成のプロジェクトの場合は基本設定は不要。

カバレッジを取得する場合はjacocoプラグインも導入する

カバレッジ情報をsonarqubeに連携する場合には、gradleにjacocoプラグインを追加してあげる。

apply plugin: "jacoco"

sonarqubeの場所をgradle.propertiesに設定する

systemProp.sonar.host.url=http://localhost:9000

sonarqubeタスクを実行する

sonarqubeタスクを実行する。jacoco.reportPathが非推奨と言われるけど、これはsonarqubeプラグインのデフォルト設定なやつなので、次回以降のバージョンアップで解消するのではと思う。

./gradlew clean sonarqube
:clean
:compileJava
:processResources NO-SOURCE
:classes
:compileTestJava
:processTestResources NO-SOURCE
:testClasses
:test
:sonarqube
Property 'sonar.jacoco.reportPath' is deprecated. Please use 'sonar.jacoco.reportPaths' instead.

BUILD SUCCESSFUL

sonarqubeで見てみると

こんな感じに結果が見れる。

sonarqubeを用意するのにつかったcomposeファイル

postgresql:
  image: postgres
  ports:
    - "5432:5432"
  environment:
    - POSTGRES_USER=sonar
    - POSTGRES_PASSWORD=sonar
    - POSTGRES_DB=sonar
sonarqube:
  image: sonarqube
  ports:
    - "9000:9000"
    - "9092:9092"
  environment:
    - SONARQUBE_JDBC_USERNAME=sonar
    - SONARQUBE_JDBC_PASSWORD=sonar
    - SONARQUBE_JDBC_URL=jdbc:postgresql://postgresql/sonar
  links:
    - postgresql

おわり。

proxy環境下でUpsourceを使う

proxy環境下にUpsourceを構築して、外の世界のリポジトリ（例えばgithub）のコードを参照したい場合の設定方法。

※古いバージョン(Upsource 2017.1以前)では、多分この方法ではproxyを突破することができないと思います。
かなり初期の頃は、どう頑張ってもproxyを突破できずにIntelliJ IDEAさんにオレオレパッチを当てて突破してました。

proxyの設定方法

下の設定を行うことで、お外の世界のリポジトリを参照できるようになる。

1. upsourceディレクトリ/conf/upsource-frontend/upsource-frontend.jvmoptions.distをupsource-frontend.jvmoptionsにリネームする。
2. リネームしたupsource-frontend.jvmoptionsを開き、proxyの設定を追加する。
例

-Dhttps.proxyHost=hoge.fuga.coom
-Dhttps.proxyPort=8080

3. upsourceを起動する

おわり。

JBeret SEで起動したJOBを停止する

JBeret SEで起動したJOBをJMXを使って停止させてみる。*1

MXBeanを作る

インタフェースと実装はこんな感じに。
とりあえず、executionIdとステータスやジョブ名を参照できるようにして、操作としてstopを定義してみた。

インタフェース

public interface JobControllerMXBean {

    void stop();

    Long getExecutionId();

    String getJobName();

    String getBatchStatus();
}

実装

public class JobController implements JobControllerMXBean {

    private final JobExecution jobExecution;

    public JobController(final JobExecution jobExecution) {
        this.jobExecution = jobExecution;
    }

    @Override
    public void stop() {
        BatchRuntime.getJobOperator().stop(getExecutionId());
    }

    @Override
    public Long getExecutionId() {
        return jobExecution.getExecutionId();
    }

    @Override
    public String getJobName() {
        return jobExecution.getJobName();
    }

    @Override
    public String getBatchStatus() {
        return jobExecution.getBatchStatus().name();
    }
}

JOBの実行とMXBeanの登録

sampleジョブを実行しつつ、JobExecutionを持つMXBeanを登録する。

fun main(args: Array<String>) {

    val mbs = ManagementFactory.getPlatformMBeanServer()

    val jobOperator = BatchRuntime.getJobOperator()
    val executionId = jobOperator.start("sample", null)

    val jobExecution = jobOperator.getJobExecution(executionId)
    val jobController = JobController(jobExecution)

    val name = ObjectName("siosio:type=JOB")
    mbs.registerMBean(jobController, name)

    (jobExecution as JobExecutionImpl).awaitTermination(0, TimeUnit.SECONDS)
}

JConsoleで見てみると

下の画像のように情報が参照できているのがわかる

stop操作をしてみると

下の画像のようにstop要求が行われ、最終的にジョブが終了しプロセスがなくなっていることがわかる。

ジョブリポジトリのbatchstatusもSTOPPEDに変更されているので、ジョブが停止されたことが確認できる。

おわり。

*1:単純に別プロセスからJobOperator#stopしてみたけど、別プロセスから呼び出しても意味ないみたいでした。

IntelliJ IDEA2017.2でパンくずリストをエディタの上部に表示する

IntelliJ IDEA2017.2 EAPにしたらパンくずリストが、こんな感じにエディタの下に表示されるようになってしまった。
これを、2017.1の時と同じようにエディタの上部に表示するように変更してみた。

※build no:172.2465.6からは、下に書いた面倒なことをやらなくても簡単に表示位置をtopに変更できるようになりました。
変更方法は、設定画面のEditor -> General -> Breadcrumbsからできます。

registry画面を表示する

設定画面からは変更できないっぽいので、registryをいじってあげる必要があるようです。

registryの画面はFind Actionから表示できます。

設定を変更する

この画像のようにeditor.breadcrumbs.aboveのチェックをオンにしてあげます。

これで、こんな感じにエディタの上部に表示されるようになります。
すでに開いているファイルは開き直すことで設定が反映されます。

PostgreSQLでREAD COMMITEDとdelete->insertの組み合わせの問題のメモ

PostgreSQLのREAD COMMITEDでdelete->insertを使った場合、あるはずのレコードに対する削除がされずにinsertで一意制約違反が発生するらしい。。。

テーブルの状態

postgres=> select * from hoge;
 id
----
  1

2つのトランザクションで以下のSQLを実行

delete from hoge where id = 1;
insert into hoge values (1);

結果

先に実行されたトランザクションの処理は当然成功する。

postgres=> begin
postgres-> ;
BEGIN
postgres=> delete from hoge where id = 1;
DELETE 1
postgres=> insert into hoge values (1);
INSERT 0 1
postgres=> commit;
COMMIT

後に実行されたトランザクションは、deleteがロックを解除されるのを待ち、delete -> insertが成功されると思っていたが異なる結果となった。
結果は以下のログのようにdelete処理では何も削除されずに、insertで一意制約違反となる。

postgres=> begin;
BEGIN
postgres=> delete from hoge where id = 1;
DELETE 0
postgres=> insert into hoge values (1);
ERROR:  重複キーが一意性制約"hoge_pkey"に違反しています
DETAIL:  キー (id)=(1) はすでに存在します

原因

以下に詳しく書いてありますが、delete対象のレコードに対するロックの取得待ちをしていて、そのレコードがなくなったためにこのような挙動になるようです。
https://dba.stackexchange.com/questions/27688/locking-issue-with-concurrent-delete-insert-in-postgresql

READ COMMITEDでdelete->insertは選択しちゃダメなのですね。