たごもりすメモ

コードとかその他の話とか。

GradleでMaven Centralにライブラリを公開する

前にこんなエントリを書いたが、このときはmavenから実行してた。今回はgradleから。参考にしたエントリはいくつかあったけど、ずばりというのがなくてつらかった。あれこれ試して組み合わせた。

はじめてのmaven central 公開 - たごもりすメモ

あとMaven Central(というかSonaType OSS)もちょっと変わってるのでそのへんも。なお環境は適当なMacに適当にgradleを入れた。以上。

前と変わらないところ

  • GPGのセットアップ
  • パッケージ名前空間を決める
  • アカウント登録

パッケージ名前空間は今回は前のと違ったので、申請は今回もやった。前と同じようにやってさくっと完了。

gradle環境の設定

"$HOME/.gradle/gradle.properties" に行う。

org.gradle.daemon=true
signing.keyId=DEADBEEF
signing.password=mypassphrase_for_gpgkey
signing.secretKeyRingFile=/Users/tagomoris/.gnupg/secring.gpg
sonatypeUsername=tagomoris
sonatypePassword=mypassword_for_sonatype

最初の1行は普通の便利設定で、他はJarの公開用。
パスワードやパスフレーズを毎回コンソールで聞かせる設定とかにする流儀もあるみたいだけど、とりあえずパス。ベタ書き。ここに書いておけばgradleの maven plugin が読んでくれる。

build.gradle の記述

がんばった。全体はここにあるので、ポイントをいくつか抜き出して書く。

apply plugin: "java"
apply plugin: "application"
apply plugin: "maven"
apply plugin: "signing"

group = "net.isucon.bench"
archivesBaseName = "isucon-bench"
version = "0.1.1"
description = "Benchmark framework for Web applications, especially for ISUCON"

java と application プラグインはビルドと実行用のもの、maven と signing がmaven centralでの公開用のもの。その下はパッケージのメタデータ宣言用。あとで使う。

maven-publish プラグインというのもあるみたいだったが、あれこれ試したところそれは自分で maven repository server を作って運用するようなときに、そこにpushするためのものっぽい。code signingと組み合わせるとうまく動かないという話が多くて、自分もやってみたところどうもダメな感じだった。なんかものすごい色々コード書けばできる的な話もあったけど、何のためにプラグイン使ってんのか分からなくなる的な展開が見えて避けた。

//set build variables based on build type (release, continuous integration, development)
def isDevBuild
def isCiBuild
def isReleaseBuild
def sonatypeRepositoryUrl
if (hasProperty("release")) {
    isReleaseBuild = true
    sonatypeRepositoryUrl = "https://oss.sonatype.org/service/local/staging/deploy/maven2/"
} else if (hasProperty("ci")) {
    isCiBuild = true
    version += "-SNAPSHOT"
    sonatypeRepositoryUrl = "https://oss.sonatype.org/content/repositories/snapshots/"
} else {
    isDevBuild = true
    version += "-SNAPSHOT"
}

repositories {
    mavenCentral()
}

普通にビルドしただけでSonaTypeに公開されたらたまらんのでリリース作業用の設定を明示的に行うように変更。CIの場合はSNAPSHOTを公開用とは別の場所に上げるようにしている。まあCIまわしてないんだけど……他で(ちゃんとやるケースで)真似したくなったときのために。

dependency, compileJava, mainClassName, run あたりは普通に java, application なビルド/実行のためのものなので割愛。javadocJar, sourcesJar, artifacts は見ればわかるので割愛。

signing {
    required { isReleaseBuild }
    sign configurations.archives
}

uploadArchives {
    repositories {
        if (isDevBuild) {
            mavenLocal()
        }
        else {
            mavenDeployer {
                if(isReleaseBuild) {
                    beforeDeployment { MavenDeployment deployment -> signing.signPom(deployment) }
                }

                repository(url: sonatypeRepositoryUrl) {
                    authentication(userName: sonatypeUsername, password: sonatypePassword)
                }

                pom.project {
                    name 'isucon-bench'
                    packaging 'jar'
                    description 'Benchmark framework for Web applications, especially for ISUCON'
                    url 'http://www.example.com/example-application'

                    scm {
                        url "scm:git@github.com:isucon/isucon-bench-java.git"
                        connection "scm:git@github.com:isucon/isucon-bench-java.git"
                        developerConnection "scm:git@github.com:isucon/isucon-bench-java.git"
                    }
                    licenses {
                        license {
                            name 'MIT'
                            url 'https://opensource.org/licenses/MIT'
                        }
                    }
                    developers {
                        developer {
                            id 'tagomoris'
                            name 'Satoshi Tagomori'
                            email 'tagomoris@gmail.com'
                        }
                    }
                }
            }
        }
    }
}

このへんも見ればだいたいわかるが、丸っと書いてあるページがなくて難儀した。開発時ビルドにはスキップする設定で、書名とかパッケージのメタデータとかが書いてある。

この設定を書いておいたら、あとはコマンドでは "gradle clean && gradle uploadArchives -Prelease" すればSonaTypeのリポジトリにアップロードまでやれる。単に uploadArchives するとなんか変なゴミが含まれたJarが作られてしまった気がしたのでいちおう今のところはこうしている。それは不要だとか、綺麗なJarを一発で作る方法があったら教えてほしい。

まあなんにしろ、これでうまくいく。

$ gradle clean && gradle uploadArchives -Prelease
:clean

BUILD SUCCESSFUL

Total time: 0.863 secs
:compileJava
注意:入力ファイルの操作のうち、未チェックまたは安全ではないものがあります。
注意:詳細は、-Xlint:uncheckedオプションを指定して再コンパイルしてください。
:processResources UP-TO-DATE
:classes
:jar
:startScripts
:distTar
:distZip
:javadocJar
:sourcesJar
:signArchives
:uploadArchives
Could not find metadata net.isucon.bench:isucon-bench/maven-metadata.xml in remote (https://oss.sonatype.org/service/local/staging/deploy/maven2/)

BUILD SUCCESSFUL

Total time: 1 mins 3.332 secs

なんか通知ぽいものが出ているが、これはSonaTypeのリポジトリが新しくなって以降出る(ことがある)ようになったもの。とりあえず無視してよい。

SonaType Nexus Repositoryでの手続き

これが変わったところ。先程のコマンドでSonaTypeのリポジトリには格納された(stagingになった)はずだが、そこから先の処理をワンステップやらないといけない。新しいWeb UI (Nexus Repository)が登場する。
なお以下のページに案内がある。スクリーンショットとかあって前よりだいぶ分かりやすいので、読むとよい。

Releasing the Deployment

で、具体的にはこのページを開く: https://oss.sonatype.org/index.html#stagingRepositories

認証は作成してあるSonaTypeのアカウントで通れる。(開いてなければ)左側のメニューから "Staging Repositories" をクリックすると、いろいろ見られるリストの中に自分がアップロードしたっぽい名前があることを確認する。

https://i.gyazo.com/d6a722eb1925c3009627bceed2b8f549.png

選択すると上のメニューで "Close" と "Drop" のボタンが有効になるはず。なったら "Close" をクリックして、ダイアログから "confirm" する。このときパッケージになにか問題があるとエラーになるらしい(なったことがない)。問題がなければ該当の staging repository の状態が closed になる。問題なければそのまま "Release" ボタンが有効になるので、押してリリース。

完了したらリポジトリの管理チケットに完了したよとコメントを書くと、staging -> release の手続きの自動化を有効にしてもらえて、一件落着。リリースされたら、Nexus Repository内でパッケージ名で検索したとき、該当バージョンが releases 下にあるように表示されるからわかるはず。

完了!

なお最近試したところ Maven Central の検索画面に出てくるようになるまではだいぶ時間がかかった。が、その状態で pom.xml に書いてみたところ正常にダウンロードできたので、あまり気にする必要はなさそう。
あと一度自動リリースが有効になったリポジトリで staging を手動で close してみたら、なんか変なことになったかも。stagingから出ていかなくなってしまった。焦らず落ち着いて様子を見よう。

なんにしろ、これでできた。やってしまえばなんとかなる。便利。

CROSS 2016に行ってきた&しゃべってきた

2016.cross-party.com

先週金曜に横浜大さん橋ホールであったCROSS 2016に行ってきた。上記のセッションにスピーカーの一人として誘っていただいてたので、参加して、日本で・国をまたいで仕事をするということについて思うところをしゃべったりとか。
これは日本で働くか米国に移住するかみたいな二択では決してなく、いろいろ日本にいながらやれることはあるし、逆に最低限やっておかないといけないことももちろんある*1、でもまあ技術がちゃんとあっていいコード書けることも大事だよね、とか思いながらしゃべっていたが、ちゃんと伝わったかなあ。

いっしょに登壇してた @kuenishi さんの以下のエントリに @hasegaw さんのtweetが引用されてるけど、そうそう、そういう感じなんだよ! という気はします。

エンジニアCROSS 2016で登壇してきました - kuenishi's blog

興味があったら上記CROSSのセッションページに動画があるので、そちらをどうぞ。

CROSSについて

大勢の参加者がいてすばらしいことだけど、セッションのテーマが働きかたとか転職とかにだいぶ寄っているような気はして、(自分もそういう系ので話しておいてなんだけど)だいぶ食傷気味になる、という気がする。これが求められているということなら、自分の好みのカンファレンスとはちょっと違ってきたなあ、という感想になった。

あともうとにかく音響がひどい。自分たちがしゃべっているとき、比較的近くでデイリーポータル(?)の企画かなにかがすごい音量でアナウンスしててつらかった。後ろのほうの席の人、こちらの話し声が聞こえてなさそうだったしなあ。ホールの雰囲気が面白いのはわかるけどあれじゃ本末転倒だ。

終わったあと近くのビアバーで飲んでたけど、途中から合流した某社の若い人になんかおっさんくさいことを説教っぽくしゃべってしまった気がする。おっさん力の向上がつらい。

*1:OSS、コメントやコミットコメントやドキュメントやメールでの英語のやりとりなど

2015年を振り返ってみる

今年はとにかく仕事してた……。ということで、Blogエントリ数を見てみるとこれまでの数年に較べてだいぶ少ない。

転職した

大手インターネットサービス事業者から、いろいろあって結果的には西海岸のスタートアップ(の東京オフィス)に移った。

tagomoris.hatenablog.com
tagomoris.hatenablog.com

今年のいちばん大きな変化だったのは間違いない。このあとUSオフィスに少し行ってたり、この「いろいろあって」のときに考えてたことをエントリに書いたりもしていた。
結局その後に仕事をしていてこれまでと全く違う環境になったし、書くコードの種類や性質、考えかたなんかもけっこう変わったなという自覚はある。

あとこれまでに較べて格段に英語を使うようになった。おかげでだいぶ慣れてきたなとは思う。

書いたコード

OSSのコードはこれまでのプロダクトのメンテナンス系が多い、けど、Dockerのfluentd logging driverを書いたりmsgpack-rubyのメンテナをやることになったり、そこそこ新しいこともやってはいたかな。あんまり大物ではないけど、自分にとっては新しいものだったりそれなりに影響する範囲も広かったりで、面白い経験にはなっている。

あとはISUCON関係。これはあとで。
仕事関連だと社内向けの実装を直すことが多かったのがあって、ほとんどそういうエントリは書かなかったな。Hiveの挙動を一部乗っ取るためのコードをどこにどう書けばいいか、みたいな他社では役に立ちそうもないノウハウはだいぶ得たけど……。

発表やら執筆やら

海外のカンファレンスが2件、そのほか国内ではYAPC::Asia, RubyKaigi, 秋デブサミなどなど。秋デブサミのエントリは書き損ねてるな。7月まで大きいイベントや出張は皆無だったのに、8月からいくつも続いたのでだいぶばたばたしてた。いっぽう初めてヨーロッパに(2度も!)行けたのはいい経験だった。

割と概論や考え方についての話をするケースが多かったので、まあこれはこれで悪くはないんだけど、もうすこしコードの話をしたいなあと思ってはいる。そのためにはコード書かないとなー。いや書いてるんだけど、なんというか、もうすこし話にしやすいやつ……。

あと依頼があってWEB+DB PRESSにひとつ記事を寄稿した。個人的には記念にしたいくらいの思い出になりそう。

ISUCON

ISUCON5の出題をやった。9月末に予選、10月末に決勝というスケジュールを調整していたときは準備にたっぷり時間をかけられるはずだったんだけど、仕事の予定がズレ込んで、1年で(仕事だけで)いちばん忙しいという時期にISUCONの準備や各種発表が全部重なるという感じで、死にそうな2ヶ月になった。たぶんこれまでの人生でいちばん忙しくしてたと思う。

まあ、いろいろ不手際があって申し訳なかったとはいえ、いちおう成功したと言っていい終わりかただったのではないかとは思う。個人的にもJava8のコードをだいぶ書いたりで得たものは大きかった。ベンチマークツールフレームワークになってるので、もうすこし直してちゃんと単独のプロダクトとして出すつもり。ちょこちょこまだ直している途中。

あれこれ

その他、ウケた記事もあった。YAPC::Asiaでの発表からの一連の流れはちょっと感激なくらいで、いろいろ考えてることをぼろっと外に出すと面白いことが起きることもある、といういい例になったかもしれない。

tagomoris.hatenablog.com
tagomoris.hatenablog.com

加えて転職の時期とISUCON後で2回も morisnite をやったり、いろんな人にお世話になってるなあ、と本当に思うことが多かった。みなさん本当にありがとうございました。

来年

Fluentd v0.14に向けたPlugin APIの作り直しを4〜5月頃に途中までやってたんだけど、その後に社内向けの大きい仕事にかかりきりになっていて済んでない。正直あれがblockerになってるので、まずいなあとは思ってる。2016年の最初の大きい仕事としてこれをやるつもり。

他に社内向けにはHadoop/Hiveよりも少しインフラっぽいことや便利ツールまわりをやろうとも思ってるので、そのへんの技術をさわってみることも増えると思う。というか、増やしたい。今年は春にひたすらChefと格闘してたくらいで、その後にそっちをあまり見られなくなってしまった。
あとは某分散処理をゴニョゴニョ。これは形になるのはもうちょっと先になるかな。面白いコードをあれこれ書ける予定があれこれあるので、楽しみたいと思う。

LogstashからFluentdにデータを転送する

このエントリはFluentd Advent Calendar 2015の12月25日分の記事です。4日遅れ!

で、本題ですが、もうタイトルそのまんま、logstash-output-fluentd を作りました。
logstash-output-fluentd | RubyGems.org | your community gem host
tagomoris/logstash-output-fluentd · GitHub

How to install / use

先日書いたものと全く一緒ですが、いちおう書いておきます。

とりあえずインストール。

$ bin/plugin install ../logstash-output-fluentd-0.1.0.gem 
Uninstalling logstash-output-fluentd
Validating ../logstash-output-fluentd-0.1.0.gem
Installing logstash-output-fluentd
Installation successful

そしたら以下の設定ファイルを用意します。stdinから読み込んで 127.0.0.1 (のデフォルトポート 24224)に送るやつ。

input {
  stdin {}
}
output {
  fluentd {
    host => "127.0.0.1"
    tag => "logstash"
  }
}

起動すればもう使えます。簡単ですね!

$ bin/logstash -f example.conf 
Settings: Default filter workers: 2
Logstash startup completed
line 1
line 2
line 3
line 4

https://i.gyazo.com/1205f1400186157524418e9ad4f0c3ef.png

Yay!

注意点など

まだごくシンプルに指定したホストの in_forward に向けてデータを投げ付けるだけですが、まあ、使えなくもないかなというところです。Fluentdのforwardプロトコルにはいろいろと機能があるんですが、そのへんやover SSL*1やらはまだ全くしておりません。また複数ホストへのロードバランスやら死活確認(つまりHA)やらも対応しておりません。
そのうちやろうかなあ、どうしようかなあ。

バッファは logstash-output-treasure_data と同じでオンメモリに適当に持っているだけです。デフォルトは短めで50イベントもしくは5秒。これも flush_size および flush_interval で制御できます。正常にシャットダウンすればflushされるけどその時に失敗したり異常終了したりしたらイベントが失われるのも同じです。

まとめ

Enjoy logging!

*1:つまりin_secure_forward対応

LogStashからTreasure Dataにデータを投入する

このエントリは(2日遅れましたが)Treasure Data Advent Calendar 2015の12月25日分の記事です!

みなさんTreasure Dataにログ入れてますか? FluentdやEmbulkで入れてますよね?
しかし世界的に見てFluentdはまだまだ最有力のソフトウェアとは言えず、特にUSやヨーロッパのスタートアップ界隈ではLogStashが強い勢力を誇っています。Treasure Dataにログを投入するためだけにFluentdをインストールするのには抵抗のある向きもそちらには多いのです。

ということで、しょうがないから作りました! 本日から使えます。
logstash-output-treasure_data | RubyGems.org | your community gem host
tagomoris/logstash-output-treasure_data · GitHub

ただし現状ではdev releaseのライブラリに依存しており、この後ちゃんとメンテナンスリリースが出せるよう直すつもりです。また公式のlogstash-pluginsに入れてもらえるようにするつもりです。2016年かな。

How to install / use

LogStashを手元に展開したら、以下のコマンド一発でインストールできます。

$ bin/plugin install logstash-output-treasure_data
Validating logstash-output-treasure_data
Installing logstash-output-treasure_data
Installation successful

そして設定ファイルを用意します。以下の設定は stdin を用いて標準入力から1行ずつ読み込み message というフィールドに入れ、そのイベントを treasure_data プラグインを用いてTreasure Dataの指定したデータベース/テーブルにアップロードします。(API Keyやデータベース名、テーブル名は実際に使用するものに置き換えてください)

input {
  stdin {}
}
output {
  treasure_data {
    apikey => "0/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    database => "dbname"
    table => "tablename"
  }
}

準備できたら起動するだけです。コンソールにメッセージを適当に入力し、終わったら Ctrl-D で入力を終端できます。終端したら自動的にflushされ、Treasure Dataへのアップロードが行われます。

$ bin/logstash -f ~/example.conf 
Settings: Default filter workers: 2
Logstash startup completed
line 1
line 2
line 3
line 4
line 5
Logstash shutdown completed

https://i.gyazo.com/fc5b009f4ce425e49e17b2e59daa0b38.png

簡単ですね! やった!

注意点

LogStashはソフトウェアの機能としてはバッファリング機構を持っておらず、そのため logstash-output-treasure_data では他の多くのプラグインにあわせる形で、オンメモリでのキャッシュを行っています。
Treasure Dataにあまり細かい単位でbulk importを行うのは非常に効率が悪いため、現在はデフォルトでは10,000レコード、もしくは5分毎にflushを行うことになっています。*1

通常の手順でLogStashをシャットダウンすればその際にflush/uploadが行われますが、プロセスの異常終了などが起きた場合はメモリ内のデータは失われるのでご注意ください。

まとめ

Happy Logging!

*1:これらの設定は flush_size および flush_interval で制御できます。

WEB+DB PRESS Vol.90にコラムを書いた

明後日ですね、12月23日発売の WEB+DB PRESS Vol.90 の15周年記念エッセイ「私を変えたソフトウェア」にて2ページ、記事を書きました。
たまに(?)このblogでもエモいアレを書いたりしますが、なんかそういうやつです。原稿料をもらってこういうのを書いたのは初めてです。たぶん。

gihyo.jp

内容は本誌を読んでいただきたいんですが*1、要するに今現在に毎日ミドルウェアを読み書きして生活するようになったきっかけは何だったか、という話です。きっかけひとつというわけでもなく幾つか段階があるなあと思ったので、それについてつらつら思い出話のようなものを書いてます。
改めて読んでみると最後の1ステップ(現職への転職)が抜けているのでそこに何の迷いもなかったようになってますが、もちろん実際はそんなことはありません。が、まあそれはソフトウェア開発者としての転機というよりは人生どう生きるかみたいな部分なので、いいかなと思います。

しかし他の3氏がものすごくて、Rubyの人とHSPの人とLispの人ですよ……。ひええ。あと他がみんな1990年以前の話なのに、自分のやつだけ2010年代になってます。並んでるソフトウェア名も EmacsスペースインベーダーLisp と並んで "FluentdとNorikra" とか、うああ。*2
他の方よりもうちょっと卑近な例ということで、これはこれで存在意義があるに違いないと自分に言い聞かせてます。

他の記事だと自分には特に特集2のドラクエXの話が興味深くて、ほほうKTにCassandraにExadataとな……みたいな感じです。まだざっと目を通しただけなのでじっくり読みたい。大規模MMORPGのバックエンドについて詳しく雑誌に書かれるとはすごい時代だなと思いますね。

ということで、興味があれば読んでみてくださいな、という話でした。

*1:PDFでも1部単位で買えますね、いい時代だ

*2:書影出てくるまで他の著者が誰かとか知らなかったんだけど、これ知ってたら原稿書けてたのかな……。

RubyKaigi 2015に行ってきた&しゃべってきた

この週末にあったRubyKaigi 2015に参加した。
RubyKaigiはRubyコミッタやその他の人々に、特に低レイヤや各種OSの事情に詳しい人なんかも多くて、これはこれで非常に刺激になっていていいなあ。言語ランタイムの最適化の話を何セッションも聞くとかは国内の他のカンファレンスでは自分はあまり経験しないので、いつも楽しい。

しゃべってきた

EuRuKo 2015で話したのと同じタイトルだけど内容はけっこう違ってて、なぜTDではRubyでqueue/workerシステムを必死に作っているか、みたいな話をメインに据えて話してきた。あまりRubyのコードそのものに触れることができなかったのがちょっと残念だけど、前提条件から丁寧に、必要性とどうなっているかを説明できたかなという気はする。
あとシステムを改善するときにどうしたらいいかという方針の話を質疑応答で少しできて、それもすごくよかった。質問してくれた @joker1007 さんのおかげです。

来年

京都だ! 楽しみ。行きたいなあ。そのためにもうちょっとコードそのものについて話せるようなネタを作りたいなー。