ついにJava系のPaaSはGAEだけでなくHerokuも使えるようになり随分幅が広がって来ました。 データベースに様々なものが使え、技術的にロックインされないう点でHerokuには大きな魅了があります。というわけで、今回はScala2.9.1を使ってScalatraというRubyのSinatraライクなWebフレームワークをHerokuにデプロイし、Eclipseでのデバック&開発環境を作成するということをやっていきます。 なお、前回Mavenでビルドを行うということをやっていましたが、sbtとgiter8を使った方が断然開発が楽ですし、GitHubと連携して更新が速いので、個人的にはsbtをお勧めします。 環境は、 scala 2.9.1-1 sbt 0.11.2 giter8 0.4.0 にて行います。全てMacOSX LionにてHomebrewのbrew installでインスト
これ https://github.com/paulp/sbt-extras きっかけは、 さくらのVPNが新しいプラン発表される ↓ 新しい方に申しこむ ↓ いままで使っていたものがそのまま移行できないらしいので手動で以降ェ・・・ ↓ 今まで sbt7 sbt10 sbt11 sbt12 ってそれぞれファイルつくってたけど、この際やりかた変えようかな・・・ という感じで。sbt はご存知の通り(?) それぞれ 0.7系 ⇔ 0.10系 ⇔ 0.11系 ⇔ 0.12系 で、相互にlauncherの互換性がないわけです。(たとえば0.11.1と0.11.2とかならば互換性ある) どういうことかというと、0.10.0のlancuherを使って0.11.0を起動させることができない。 で、それらをうまくやってくれたりその他いろいろやってくれるのが*1 sbt-extras なわけです。おもにシェ
Scala には REPL のテストをするための ReplTest っていうそのままの名前のクラスがあって https://github.com/scala/scala/blob/v2.10.0-M2/src/partest/scala/tools/partest/ReplTest.scala こんな感じに使います https://github.com/scala/scala/blob/v2.10.0-M2/test/files/run/macro-repl-basic.scala https://github.com/scala/scala/blob/v2.10.0-M2/test/files/run/macro-repl-basic.check もちろん、Scala自体を作ってる中の人が使うためのものです。で、それつかってこんなもの作ってみました。↓ このあたり見てもらえばわかりますが
Scalaで開発してるプロジェクトでsbt0.10を使ってるんですが、テストの数が増えてきて、テストのコンパイルでOut Of Memoryが発生しちゃう、という問題にぶつかりました。 テストケースはScalaTest使ってます。 解決策として、プロジェクトを分割してテストコードを分散させました。 ※追記 xuweiさんからのコメントにある通り https://github.com/harrah/xsbt/wiki/Setup-Notes にあるメモリに関する起動オプションをつけることで、開発時は大丈夫でした。 起動オプションで回避できることが多いと思いますので、そちらを先に確認するのが良いです。 開発時は大丈夫だったんですが、jenkinsに新規ジョブを作ったときに発生してしまいました。 subversionリポジトリからチェックアウト→sbt test の流れで全部のテストケースをコン
手順 unfilteredでアプリを作る web.xmlを書く xsbt-web-pluginでwarにする tomcatにデプロイ unfilteredでアプリを作る "Hello"って返すだけのアプリを作ります。 Unfiltered では Plan ってのを作って URL のルーティングをします。 package com.github.tototoshi.unfiltered_example import unfiltered.request._ import unfiltered.response._ import unfiltered.filter._ class HelloApp extends Plan { def intent = { case _ => ResponseString("Hello") } } web.xmlを書く 作った Plan を FIlter に指定
追記:この記事を最初に書いたときには存在しませんでしたが、このstandard projectを0.11系に対応させたものがこれ https://github.com/twitter/sbt-package-dist のようです twitter さんが、わりとどんなプロジェクトでも標準で使っているこれ https://github.com/twitter/standard-project/ をだらだらと読んで、なんとなく感想を書いてみるエントリ。実際自分が試したわけではなく、読んでみて「なんとなくこういうことしてるんだろうなぁ」っていう妄想が入っているので、正確じゃない部分があるかもしれません。*1このblog書いてる時点で最新っぽい 1.0.0のtag https://github.com/twitter/standard-project/blob/org=com.twitter,nam
ls-sbt 0.1.0 の時点で書いているので、最新の情報は以下をご確認ください。 http://ls.implicit.ly/ https://github.com/softprops/ls というか、本家に書いてある内容を順序立てて日本語で書いただけなので本家を見たほうが早いかも、、です。 lsとは? sbt の dependency 追加を楽にしてくれる仕組みです。 ls.implicit.ly のサーバに登録済の情報を sbt プラグインで取得して build.sbt に反映することができます。 たとえば unfiltered がこのように登録されているので http://ls.implicit.ly/unfiltered/unfiltered unfiltered を使いたければ、sbtで > ls-install unfilteredとやると、unfiltered の dep
2011-09-18 / sbt テストの話をしよう。一度プラグインを書いてしまうと、どうしても長期的なものになってしまう。新しい機能を加え続ける(もしくはバグを直し続ける)ためにはテストを書くのが合理的だ。だけど、ビルドツールのプラグインのテストなんてどうやって書けばいいんだろう?もちろん飛ぶんだよ。 scripted test framework sbt は、scripted test framework というものが付いてきて、ビルドの筋書きをスクリプトに書くことができる。これは、もともと 変更の自動検知や、部分コンパイルなどの複雑な状況下で sbt 自体をテストするために書かれたものだ: ここで、仮に B.scala を削除するが、A.scala には変更を加えないものとする。ここで、再コンパイルすると、A から参照される B が存在しないために、エラーが得られるはずだ。 [中略
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く