主にOSS活動を中心として、自分の今年の活動を簡単に振り返ってみる。
(書き方はバラバラだが)
2015/12/31
2015/12/20
GradleのContinuous BuildでSpring Bootアプリ実行中にリソース変更を反映する
タイトルの内容は、もともとできるんじゃないの?という感じもするかもしれないが、それではうまくいかないケースがあり、それをGradleのContinuous Build機能を使ったら何とか実現できた、という話。
Continuous Build
http://gradle.org/feature-spotlight-continuous-build/
https://docs.gradle.org/current/userguide/continuous_build.html
少し長いので、順序立てて説明。
背景
Spring Boot + Gradle で開発している時、特にWebの画面をもつアプリを開発している場合は「gradlew bootRunでのアプリ起動中にThymeleafテンプレートやpropertiesなどの静的リソースを変更したら、再起動なしで反映するようにしたい」と考えると思う。
もともと Spring Boot 1.2.x までは、デフォルトで src/main/resources 以下がbootRunタスクのクラスパスに追加されていたため、変更して画面をリロードすればすぐに反映されていた。
Spring Boot 1.3.0では、Automatic Restart、Live Reloadといった機能が DevTools として実装されたのだが、どうも意図したように再起動・リロードしてくれない。静的リソースを変更しただけで再起動してしまうし、Live Reload もうまく動作していない。
またこの機能が入ったことにより、bootRun タスクでは src/main/resources をクラスパスに含めないのがデフォルトとなったのだが、結局うまく動作しないので以下のように build.gradle に設定して、1.2.x までのようにクラスパスに入れてくれるようにしている。
bootRun {
addResources = true
}
しかし、この方法にはいくつか問題がある。
リソースが直接読み取られる
Spring Boot のドキュメントでも、bootRun.addResources = false をデフォルトにした理由として書いてあったのだが、この方法の問題は、 src/main/resources 以下のファイルの内容がそのまま Spring Boot に読み取られてしまうことだ。
bootRun は開発用のタスクであり、実際にリリースする場合は当然JARファイルにしてデプロイする。その際には src/main/resources が丸ごとJARに入って読み取られるわけではなく、processResources タスクでフィルタリングすることができ、ファイル内容を加工してからJARに入るようにしたり、一部のファイルだけを含めるようにしたりすることができる。
設定ファイルの一部に変数を埋め込んでおいて、processResources タスクで置換することもできる。
こうした処理をスキップして直接 src/main/resources 以下が読み取られてしまうので、processResources タスクなどでリソースに手を加える必要がある場合は、開発時とリリース時で異なる状態になってしまう。
プロパティファイルはnative2asciiした状態で管理しなければならない
Propertiesファイルの仕様としては、native2asciiをかけてUnicodeエスケープされていなければいけない。
だから、bootRunタスクでリソースを直接読み取らせるようにするならば、Unicodeエスケープされた状態でファイルを管理していなければならない。例えばIntelliJ で開発するなら Transparent native to ascii conversionの設定 をしておく必要がある。
これが非常に扱いづらい。
何と言っても、bootRun実行中にpropertiesを編集したりするとIntelliJが変換してくれないことがあるし、新規ファイルを追加した後はIntelliJを再起動しないと変換対象ファイルとして認識してくれなかったりする(これは動かしてみての推測で、仕様/不具合なのかどうかは不明)。
さらに、Unicodeエスケープされた状態のファイルをバージョン管理することになるので、ソースコードレビューする際にもUnicodeエスケープされた状態で差分が出てくる。
まあ、Thymeleafに限って言えば、native2asciiしてなくてもきちんと表示されるのだが、@PropertySourcesとかProperties#load()などを使ってプロパティを読み込む場合はきちんと変換していなければUnicode文字を表示できない。
解決策
というわけで、以下のように管理・開発できるのが望ましいなと考えた。
- src/main/resources以下のファイルはヒューマンリーダブルな状態で管理する
- アプリのビルド時にnative2asciiなどのファイル加工を実行する
- バージョン管理するのは加工前のヒューマンリーダブルなほう
- bootRunでの実行、JARファイルとしての実行、どちらも加工済みのファイルだけを参照する(開発・本番の差異は少なくする)
- processResourcesなどによるファイル加工は、ファイル変更を検知して自動的に実行する
src/main/resources以下のファイルを加工するタスクは、processResourcesでもいいし独自のタスクでも構わない。
processResourcesはデフォルトではbuild/resources/mainにファイルを出力するので、独自タスクを用意する場合は、このディレクトリにアウトプットすればいい。
このタスクを手動実行すれば話は簡単なのだが、開発効率が下がるので避けたい。
そこで解決策となるのは、冒頭に書いた通り、Gradle に最近追加された Continuous Build という機能。-tオプションをつけてタスクを実行すると、そのタスクの入力ファイルの変更を検知してタスクを再実行してくれる。この機能を使って、src/main/resources以下のファイルを随時加工していけばいい。
フロントエンド界隈のGulpとかGruntなどだと既に提供されている機能だけど、Gradleでもできるようになっていた。
例えば、src/main/resources/messages.propertiesをnative2asciiする場合は以下のようにすればいい。
task native2ascii {
inputs.files files("src/main/resources/messages.properties")
doLast {
ant.native2ascii(
src: "${projectDir}/src/main/resources",
dest: "${buildDir}/resources/main")
}
}
そして、次のように-tをつけてnative2asciiタスクを実行すれば、messages.propertiesを変更するたびにbuild/resources/以下に変換され、出力される。
./gradlew -t native2ascii
なお、これだけだと当然bootRunタスクは動かないので、
別のターミナルでbootRunタスクを実行しておく必要がある。
これで、bootRun.addResources = trueとしていなくても、
アプリ実行中に静的リソースの編集→反映ができて開発効率も落ちず
ソースコードレビューもしやすくなる。
残りの問題
Gradleを同じプロジェクトの中で複数動かすため、時々タスクの起動に失敗してしまう。正確には、Configurating …と表示されたまま止まってしまう。
(一度両方のタスクを停止して起動しなおせば大概うまくいくが)
それから、2つのタスクを別ターミナルで実行しなければいけないという面倒さ。開発が進行中のプロジェクトでは、きちんと周知しないと「変更が反映されなくなった!」と不満が噴出するかもしれない。
この2つが特に問題にならなければ、この方法でうまくいきそうだ。
2015/12/16
Gradleで依存関係が含まれているかを判定する方法
Gradleのあるプロジェクトが、あるdependencyを直接持っているかどうかは以下で確認できる。
boolean hasDependency(Project project, String group, String module) {
project.configurations.compile.incoming.resolutionResult.allComponents.any {
it.group == group && it.name == module
}
}
しかし、これだと推移的依存関係が判定できない。
つまり、「このプロジェクトにはライブラリAが含まれているか?」を判定したい場合に、「ライブラリAに依存しているライブラリB」を使用している場合は、上記の判定メソッドは false を返してしまう。
この推移的依存関係も判定するには次のようにする。
boolean hasDependency(Project project, String group, String module) {
project.configurations.compile.incoming.resolutionResult.allComponents.findAll {
it.getId() instanceof ModuleComponentIdentifier
}.collect {
it.getId() as ModuleComponentIdentifier
}.any {
it.group == group && it.module == module
}
}
いずれの場合も、プロジェクトが評価された後でなければ動作しない。
つまり以下のようにafterEvaluateを使う必要がある。
afterEvaluate { Project project ->
if (hasDependency(project, 'com.example', 'awesomelib')) {
// 'com.example:awesomelib'が含まれていた場合の処理
}
}
特に後者の”推移的依存関係が判定できる版”をGradleプラグインで使う場合、
Gradle TestKitでないと正しくテストできないので注意が必要。
普通のProjectBuilderを使ったテストでは
project.evaluate()などとしても正しい結果が得られない模様。
2015/12/16 23:36 追記
GradleプラグインのGroovyファイルでproject.evaluate()しても結果が得られなかったのは、
project.repositories {
mavenCentral()
}
が入っていなかったからだった。
dependencyを解決できないはずだが、単にproject.evaluate()を呼ぶだけでは何も例外がスローされないらしい。
2015/12/11
IntelliJのインデックス対象から除外する方法
IntelliJ IDEAで開発していると、プロジェクト内のファイルが自動的にインデックスされて検索などに利用される。
この機能によって、何かのツールが生成したファイルやログファイルなど、スキャンしてほしくないファイルまでスキャンされ、しかもそれらが頻繁に変更されて何度もスキャンされるため非常に動作が重たくなってしまうことがある。
これを回避するには、build.gradleでideaプラグインを適用して除外してやればいい。
例えばVagrantを使っている場合は.vagrantディレクトリは無視すべきディレクトリなので以下のように書けばいい。
apply plugin: 'idea'
idea {
module {
excludeDirs += [
file('.vagrant'),
]
}
}
これで.vagrantディレクトリ以下のファイルはスキャンされなくなる。
(検索にもヒットしなくなるので注意)
.gitignoreに入れているものは上記のexclude設定も入れておく、という感じ。
Gradle実行時のメモリオプション指定方法
Gradleを実行する時のメモリを調整したい場合、いつでも
下記に説明されているようなorg.gradle.jvmargs
を使えば良い
とつい最近まで思っていた。
https://docs.gradle.org/current/userguide/build_environment.html
しかしこのオプションが有効なのは、上記で説明されている通り
デーモンとして起動した場合だ。
デーモンとして起動しない場合は適用されないので注意。
だから、gradle.propertiesにorg.gradle.daemon=false
と書いておきながら
org.gradle.jvmargs=...
とか書いていても意味がない。
デーモン起動でない場合にメモリなどのJVMパラメータを指定したい場合は
GRADLE_OPTS
, JAVA_OPTS
を使うといいらしい。
(これも上記ドキュメントで説明されているが)
先日、Travis CIでの実行時にのみメモリ調整が必要なケースがあり、上記の違いを理解した。
なおTravis CIならば、.travis.ymlに例えば
env:
global:
- GRADLE_OPTS="-Xmx1024m -Xms256m -XX:MaxPermSize=256m -XX:PermSize=256m"
とか書けばいい。
Spring BootのプロファイルにGitコミットハッシュ値を含める
今起動しているSpring Bootアプリはどのコミットでビルドされたものなのか?
を確認できるようにしたいと思い、やり方を探ってみた。
前提として、ビルドにはGradleを使う。
AndroidアプリなどでもGradleを使ってSHAハッシュ値を
アプリの中に含めたりしていたが、それと似たようなことをやる方法。
2015/12/06
AndroidのCIでbuild-toolsの新しいバージョンが見つからない場合の対処
久しぶりにAndroid-ObservableScrollViewのAndroid SDKのバージョンなどを
アップデートしたが、Travis CIでもwerckerでもビルドが失敗してしまった。
もちろんローカルでは成功している。
API Levelの問題などではなく、build-tools-23.0.2が見つからなかったというもの。
結論としては、toolsを先にアップデートすれば良い。
2015/12/01
AndroidのテストタスクだけGradleでログ出力する
久々のAndroid関連ネタ。
Android-ObservableScrollViewでは、なるべくカバレッジ100%になるようテストを書こうとしている。
しかしテストが増えてきたせいか、Travis CIでのテスト実行中に出力がない時間が10分以上続いてしまい、ビルドが失敗することが多くなってきた。
テスト系のタスクだけもう少しログ出力させられないか?
を解決する方法について紹介する。
まず、テスト系限定でなく、すべてのタスクに対して
INFOレベルでログ出力するのなら
Gradle的には以下のように–infoなどをつければいい。
./gradlew connectedCheck --info
しかしすべてのタスクがINFOレベルで出力されるのは
見づらくなるだけなので避けたい。
2015/11/26
Gradleで表記ゆれをチェックするプラグインgradle-spelling-plugin
GradleからCoffeeScript、LESS、Bowerを使うプラグインgradle-web-resource-plugin
に続き、Javaプロジェクトの開発で使えるGradleプラグイン gradle-spelling-plugin を作ったので紹介。
これで何ができるかというと、ブラックリストに単語、表現を登録して、それを探していくだけ。
見つけた場合は、代わりにこれを使ってね、と警告する。
見つけた場合にビルドエラーとするかどうかは設定できる。
それだけ、ではあるのだけれど、ちょうどいいものが見つからなかったので作った。
Gradleを使い出すと、Gradleですべてチェックできるようにしたいと考えるようになる(たぶん)。
そして自動化したいと考える。
だから、grepしたりIDEで検索すればいいものだったとしても
Gradleで使える形になっていることが大事。
ライブラリが採用されてた!その2
YouTubeの最近の新しい動画について、今朝通知メールがきて、ふとAndroid Developersチャンネルの動画が目に留まった。
フリルのFablicさんの事例紹介だった。
マテリアルデザインを採用したらこんなに○○になった!というものだったが、マテリアルデザインのライブラリを作った自分としてはどんなものかチェックしなくては、と動画を観てみると…
おや、この動きはもしかして…!
ダウンロードしてみると、なんと使われてました!
Android-ObservableScrollViewが!
ライセンス欄にちゃんと書いてくれている。
こんな人気アプリに採用されているのは、やっぱり嬉しいですね。
Fablicさんありがとうございます。
ライブラリを使ってくれる方は
ぜひデベロッパーにフィードバックした方がいいと思います(もちろん、応援のフィードバックを…)。
特に個人で開発してると思われるプロジェクトに対しては。
メンテナンスしようというモチベーションが変わります。
(と言いつつ、諸事情で別のプロジェクトを優先していてなかなか最近できてないけど、気持ちはあります)
皆、どういう風にライブラリを採用しているのかは分からないけど、もしかすると受託開発だからオープンにできない、表立って使ってるよと言えない立場にあるのかもしれない。
それでも、もし何もフィードバックしていなければ、せめてGitHubのプロジェクトにスターを付けてくれるといいと思う。
良いと思ったから採用してくれているはずなのに、
こういう形でしか「使ってるよ!」というのが伝わらないのは残念だなと思う。
…と考えてみて、
自分も全てはそうしていなかったかもしれないなと反省。
作ったライブラリが依存しているライブラリなど、
見直してみようかなと思う。
2015/11/06
Spring Boot 1.3.0.RC1を試してみて
現在Spring Bootを使ったWebアプリを開発しているのだが、Spring Boot 1.3.0のリリースを心待ちにしていて、実際にMilestone/RC版を取り込んでみている。
その中でいくつかハマったこと(ドキュメントをよく読めという話だが)や、これは使ってみたいと思った機能などを書き留めておく。
これは1.3.0のリリース前のM5とRC1のことなので、そこはご注意を。
Gradleスクリプトの構造化
全然知らなかったのだけど、Gradleのプロジェクトでは、buildSrcというディレクトリを作ればビルド専用のクラスなどを定義できる。
例えば buildSrc/src/main/groovy/Foo.groovy というファイルを作りclass Fooとか定義すれば、build.gradleから普通に new Foo()というふうに参照できる。
classpathとか書く必要はない。
build.gradleは使っていくうちに段々と肥大化してきてしまうが、
これを使えば、複雑なtaskなどはきれいに構造化できるかもしれない。
これまで使っていたやり方としては、apply from:
を使う方法。
以前本家GradleのGitHub上のプロジェクトを参照したのだが(ここでbuildSrcに気づいても良かったんだが・・・)、gradleディレクトリにいくつもgradleファイルを置いている。
そして、これを apply from: "${rootDir}/gradle/hoge.gradle"
のように読み込む。
まとまった機能があればこのように切り出せばマルチプロジェクトでもそれなりにまとめられる。
しかしファイルを切り出してもそれはあくまでフラットな構造のスクリプトであり、ぐちゃぐちゃになりやすい。
クラス化したいなぁと思うことが何度もあったが、そんなときにbuildSrcを活用すると良いのかもしれない。
2015/10/30
GradleからCoffeeScript、LESS、Bowerを使うプラグインgradle-web-resource-plugin
前のエントリで少し触れてしまったけど、少し前に作り、最近大幅に改造してひとまず仕上げたGradleプラグインgradle-web-resource-pluginの紹介です。
というか、開発の経緯の説明という感じですが・・
このプラグインで何ができるのかというと、GradleのタスクでCoffeeScriptやLESSのソースをコンパイルでき、Bowerで利用できるライブラリを組み込むことができる。
しかもNode.js、npmなどのインストールは不要。
Gradle 2.8にしたときのSpockテストコードのビルドエラー
4月以来の久々のテクニカルな内容。
OSSを作るのはいいんだけど、そこで得た知見は、こういうところで書いたりしないと結果的にクローズドな感じになってしまうのでよくないなぁと思う今日この頃。
できるだけ、日々やってきたことをここで書き残そうと思います。
で、今回は今さっき試したばかりのこと。
Gradle 2.8がリリースされていたので、開発したプラグインの一つであるgradle-web-resource-pluginに適用してみた。
すると、compileTestGroovyタスクの実行時に以下のようなエラーが発生。
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':plugin:compileTestGroovy'.
...
Caused by: java.lang.ExceptionInInitializerError
2015/10/25
WhatsAppにライブラリが採用された!
夜遅くに仕事から帰り、夜中にいつも通り(?)コーディングをしていると、意味不明な通知メールが・・・”Milestone achieved”
マイルストーン??
見てみると、なんとAndroid-ObservableScrollViewがWhatsApp Messengerに採用されてるよ!と、初期からいろいろフィードバックしてくれてご自身のアプリにも組み込んでくれたユーザの AkshayChordiya さんが知らせてくれたのだった。
WhatsAppってあのWhatsApp・・・?
スクリーンショットも貼り付けてくれていたのだが、思わず自分でも調べてしまった。
確かに、自分の名前がある・・・。
一応書き残しておくと
設定>ヘルプ>WhatsAppについて>LICENSES
で確認できる。
“may be included”と書いてあるので、含まれていない場合もあるのかも。
10億ダウンロードを超えるこのアプリに搭載されるなんて夢のよう。
はたから見たら「だから何?」という出来事でもあるんだけれど、
自分にとっては確かに「Milestone achieved」な出来事。
GitHubにも書いたけど、ここまでこのライブラリを育ててくれた・サポートしてくれた方々に感謝するとともに、ますます頑張っていきたいと思えた大事な瞬間だった。
2015/07/11
毎日コードを書くことと、それにまつわること
とあるきっかけで、ここ1年半近くやってきた、毎日コードを書くことについて振り返ってみようということになった。
実質続いてるのは約一年。始めたのは2014年の3月頃。
約1年前に1週間ほど途切れた期間があるが、そこからちゃんと再開しているので、そこについても言及した方が良いかもということで
あえて試みを始めてからの期間で1年半と言っている。
これは現時点のコントリビューションの状況。
思いのほか、気づきがあって良かったと思う。きっかけを与えてくれた2人に感謝。
自分がこんなエントリを書くとはおこがましいという感覚があるのだけれど、
2人の意見を聞いて、もしかしたらこの話をオープンにしたら誰かの役に立つかもと思い、一度Secret Gistとして書いたものをもう一度時間を取って振り返り、バックグラウンドの説明を含めたりしつつ書き改めてみた。
前置きが長くなったが、これは毎日コードを書くことのような振り返りの話。
これをやった John Resig さんのルールは自分からするとかなり厳しく、このルールでは自分は続けられないと思う。
しかしそこまでやらなくても、十分に収穫があったと思うので、自分の経験を1つのサンプルとして紹介したい。
1つのエントリにしては長すぎるが、気にせず思いつく限り書いてみる。
2015/04/14
Spring Bootで静的コンテンツにフィンガープリントをつける
Spring BootではRuby on Railsのアセットパイプラインのようなものを
どうやって実現するのか?というのを調べていた。
Sprinb Bootのバージョンは1.2.3-RELEASE。
以下のSpringのブログによれば、静的コンテンツのハンドリングはSpring Framework 4.1で改善されたらしい。
Spring Framework 4.1 - handling static web resources
Thymeleafのlayoutを使う
Spring BootとThymeleafの組み合わせにおいて、th:fragment
などの使い方は分かったが、共通のレイアウト(<head>
なども含めて)を集約するにはどうすればいいのかわからなかった。
例によってSaganを見てみると、layout:
というのを使っていた。
Thymeleafの日本語ドキュメントのこのページを見ていたら見つからなかったが、こちらには書いてあった。
2015/04/12
Jekyllでチュートリアルを作る
チュートリアルサイトを作りたいと考えたが、
コンテンツはMarkdownで書きたい。
そうするとGitHub PagesとJekyllが楽かな、と考えた。
おまけ的にGithubプロジェクトの紹介ページを作ってみたことはあったが、今回の場合それがメインのコンテンツになる。
GitHubのリポジトリで静的なサイトを作る場合にどうしたら良いのか(ただしブログ ではない)という点で調べたり試行錯誤したことをまとめてみる。
2015/04/01
Spring Bootのバージョン定義の集約
Spring Boot 1.2.3.RELEASEが出ていたので、
早速todoサンプルプロジェクトに適用してみた。
Spring Bootはstarterなどで複数の同じバージョンのdependencyを使うので、バージョンは集約して定義しておいた方がメンテナンスしやすそう。
ということで、gradle.properties
をプロジェクトルートに作成し、
2015/03/31
gulp-uglify使用時のエラー
Saganを参考に、CSSとJavaScriptのminifyをしてみようとしたが、jQueryのminifyに失敗する。
使用していたのはgulp-uglifyの1.1.0。
Spring BootのIntelliJでのホットスワップ
ソースコードの修正に合わせて実行中のSpring Bootアプリケーションを自動的にリロードさせる方法(ホットスワップ)について。
基本的な方法はSpring Bootのドキュメントに書いてあるのだが、
実際に試してみて、bootRunの実行中に修正してもロードされず、困っていた。
このとき実は、bootRunをIntelliJ IDEA CE (14.0)のGradleビューのタスクをダブルクリックすることで実行していたのだが、これがいけなかった。
IntelliJのGradleビューからbootRunを実行してしまうと自動ビルドの対象外になってしまう。
IntelliJの設定でBuild, Execution, Deployment
> Compiler
の設定項目をよく見ると
Make project automatically (only works while not running / debugging)
と書いてある。
(=自動的なビルドは、実行・デバッグをしていないときにのみ有効)
つまり、Macならターミナル、Windowsならコマンドプロンプトなどで gradlew bootRun
を別で実行しておけば、IntelliJ自体はrunningでもdebuggingでもない状態なので、ファイルの保存時にコンパイル・ホットスワップしてくれる。
2015/03/29
Spring Bootでのフロントエンド開発
SpringにProject Saganというのがある。
spring.ioのリファレンスアプリケーションということらしい。
Spring Bootでのフロントエンド開発はサポートされているのかな?
と調べていたところで
https://spring.io/blog/2014/07/24/spring-framework-4-1-handling-static-web-resources
を見つけ、そこでProject Saganが説明されていた。
Bloggerでモバイル表示時に横スクロールが発生...
PageSpeed Insightsを使ってこのブログを色々改善しようと考えた。
それなりに改善したものもあるし、Bloggerを使っている限り難しそうなものも多いので諦めているものもあるが、その中で「なぜ?」というものがあった。
下記の警告。
コンテンツのサイズを表示域に合わせる
ページ コンテンツの幅が表示域に対して広すぎるため、水平方向へのスクロールが必要になります。ユーザー エクスペリエンスを向上させるためにページ コンテンツのサイズを表示域に合わせてください。
ページ コンテンツの幅は 360 CSS ピクセルですが、表示域の幅は 320 CSS ピクセルしかありません。次の要素が表示域から外れています:
要素「<div class="widget-content"></div>
」が表示域から外れています。
確かに、モバイルのエミュレーションで確認すると右側に余白ができており、横スクロールが発生している…。
2015/03/28
Spockのthenで使える表現
GroovyのテスティングフレームワークSpock Frameworkではthenの部分に合格条件を記述するが、一行で一つのbooleanを表現する必要がある。
JUnitのようにテストケース内に何を書いても良いフレームワークに慣れていると、どう書いていいかわからなかったりする。
以下に、thenに使えそうな表現をいくつか挙げてみる。
Gradle Pluginプロジェクトをマルチプロジェクトにするときの注意点
Gradle Pluginを作る際、シングルプロジェクト構成なら気にすることはないが、マルチプロジェクト構成にした時にartifactIdが変わってしまったのでその対策のメモ。
AndroidのGradleプラグインgradle-eclipse-aar-pluginを開発している時に起きたことだが、当初はシングルプロジェクト構成だったものを後からマルチプロジェクト構成に変更して問題が発生した。
以下のように、プラグインのプロジェクトに名前をつけてあげればいい。
rootProject.name = 'gradle-eclipse-aar-plugin'
include ':plugin', ':misc:samplelib'
// ディレクトリ構成上はpluginだが、別名を付ける
project(':plugin').name = 'gradle-eclipse-aar-plugin'
これをしないと、uploadArchives
タスクを実行した時に上記の例で言えばplugin
がartifactId
として扱われてしまう。
Spring Bootのアプリ内にパスワード生成タスクを追加
以前のエントリ Play Frameworkのアプリ内にパスワード生成プロジェクトを追加のようなことをSpring Bootで行う方法について。
上記エントリで書いたように、Gradleで簡単に定義できる。
暗号化方法は、Spring Bootでユーザ認証で書いたようにWebSecurityConfigurerAdapter
の継承クラスでnew StandardPasswordEncoder()
を設定している前提。
他のEncoderを使う場合はタスクの内容を適宜書き換えれば良いはず。
Spring Bootでユーザ認証
Spring Bootで(というかSpring Securityのような気もするが)
ユーザ認証を実装する方法について。
とりあえずハードコードで、という方法は見つかるのだが
- DBにユーザ情報を格納し
- ID以外のユーザ情報にもアクセスできるようにする
という場合の方法が見つからず苦労したので記録しておく。
Play Framework 2.3をJavaで使うときに困った話(凡ミス)
Play Framework 2.3.8を使ってサンプルを作っていた時、
チュートリアルを参考に進めていたつもりだったのだが
Viewなど至るところでplay.api.*
が参照されてしまい
クラスが見つからないエラーが多発した。
てっきりJavaはもうサポートされていないのかな…と
思ってしまったが、単なる凡ミスだった。
build.sbt
で以下のようにPlayJava
プラグインを使用するように設定すれば良いだけのこと。
lazy val root = (project in file(".")).enablePlugins(PlayJava)
これを、PlayScala
プラグインを適用していたせいで上手くいかなかったのであった。
恥ずかしい話だが、誰かの役に立つかもしれないのでメモ。
Play FrameworkのCustom Field Constructorを作る
Play Framework (2.3.8)では、Scalaでテンプレートを書くようになっているが、以下のようなフォームを作りたい場合に@helper.form
でフォームを作ると<dd>
タグなどでレイアウトされてしまい思うようにならない。
そこでCustom Field Constructorを定義する。
Play FrameworkでSQLで初期データ投入する方法
Play Frameworkでは、EBeanを使い
YAMLで初期データを書くようだが、
SpringのようにSQLファイルで初期化したい場合。
Scalaだとanormが使えるようだが、Javaだと以下のような感じに作るしかなさそう。
Play Frameworkは2.3.8。JavaはOracle JDK 7。
Play Frameworkのアプリ内にパスワード生成プロジェクトを追加
Webアプリケーションのユーザをテーブルで管理する場合
MySQLなどのDBで、SHA2()
関数などを使ってパスワードを変換しても良いのだが、プログラム側で生成するとした場合は開発中のテストユーザのパスワードを生成するのに困る。
Play Frameworkの場合はBCrypt
を使う例を見かけたので
これを使うタスクをSBTで定義できたら良いのかな、と考えた。
…が、結局(知識不足なためだろうが)うまくできずサブプロジェクトとして用意して解決できたのでそのメモ。
(Play Frameowrk 2.3.8, Java 7)
2015/03/27
Webアプリケーションフレームワークを調べてみる
最近、Webアプリケーションフレームワークを使ってみながら比較している。比較、といっても深い考察ができているわけではなく素人レベルで色々試しているだけ。
TODOアプリケーションという同じ題材を、複数のフレームワークを使って実装してみて、実際に開発してみるまでの入り易さや開発のし易さ、等々を肌で感じてみよう、という取り組みをしている。
https://github.com/ksoichiro/todo
現在は、Spring BootとPlay Frameworkを使ってみたところ。
(なぜこれ?というのはさておき)以下、雑感。
総じてPlayが良さそうな感じに見えてしまうが、素人意見であり、どちらが絶対に良いとか悪いとかの話ではなく単なる感想なので注意。
2015/03/26
IntelliJ IDEA 14.1でのScala Plugin
IntelliJ IDEA 14 CEを開くと、アップデートがあると表示されていたので14.1をインストールしてみた。
が、Play frameworkのプロジェクトを開いてみるとScalaを認識しなくなっていた。
そこで、Pluginを再インストールしないとダメなのかな?と思いPluginsを確認してみると、Scala Pluginのアップデートがある、という表示になっていた。
14.1向けにアップデートがあったのだろうと思いUpdateしてみると、Updateの表示が変わらず残っている・・・。
仕方なく、諦めて 14.0 を再インストールして使うことにした。
やはり、IDEのバージョンアップは慎重にやらないとダメだな。。。
再開
今回は、ここ1年くらいを少し振り返り、テクニカルな内容ではなくアウトプットに関することをだらだらと書く。
Qiitaに投稿するようになったこともあり、最近すっかりブログを書かないようになっていたが、どうしてもQiitaに投稿しようとすると完成度を上げてから、とか思ってしまい、アウトプットしにくくなっていた。(元々このブログに頻繁に書いていたわけでもないが)
一方、ソースコードに向かう時間を1日一回は作ろうと思っていて、ちょうど1年前くらいからGitHubに1日1回以上を目標にコミットするようにしてきた。
なぜ始めたかというと、スポーツでの練習と同じ感覚で、継続的なトレーニングが必要だと思ったから。