Heroku

【意訳】Heroku上でPlayFramework + Scalaアプリケーションを実行する (12 Aug 2012 | Tags: 【意訳】Heroku上でPlayFramework + Scalaアプリケーションを実行する

modal_soul debriefing

Book Category Tag About
Aug 12, 2012
【意訳】Heroku上でPlayFramework + Scalaアプリケーションを実行する

Programing Scala PlayFramework Heroku

誤訳・誤植等ありましたら、@modal_soulまでリプライいただけるとありがたいです。

ScalaでPlay Frameworkアプリを構築するのが最近流行っているようです。理由としては、これまでのJVMベースのWebアプリよりも簡単に構築、デプロイできることです。ScalaでPlayアプリの構築とHerokuへのデプロイをやってみましょう。

Step1) Play Frameworkをインストールします（バージョン1.2.3以上をインストールしてください)。

Step2) Play Scalaモジュールをインストールします。

play install scala

Step3) ScalaサポートしたPlayアプリを作成します。

play new playwithscala --with scala

Step4) アプリケーションをスタートします。

cd playwithscala play run

Step5) ブラウザでアプリケーションを開きます。

http://localhost:9000

とても簡単ですね。Heroku上にデプロイする前に、カスタムmodel, view, controllerを追加してもう少し味付けしてみましょう。

Step1) app/models/Widget.scalaを新規作成して、以下を記述します。

package models case class Widget(id: Int, name: String)

Step2) app/views/Widget/list.scala.htmlファイルを新規作成して、以下を記述します。

＠(widgets: Vector[models.Widget]) <!DOCTYPE html> <html> <body> @widgets.map { widget => Widget @widget.id = @widget.name</br> } </body> </html>

Step3) app/controllers/WidgetController.scalaを新規作成して、以下を記述します。

package controllers import play._ import play.mvc._ object WidgetController extends Controller { import views.Widget._ import models.Widget def list = { val widget1 = Widget(1, "The first Widget") val widget2 = Widget(2, "A really special Widget") val widget3 = Widget(3, "Just another Widget") html.list(Vector(widget1, widget2, widget3)) } }

Step4) 以下のURLを表示して、動きを確認しましょう。

http://localhost:9000/WidgetController/list

動きましたね。それにサーバーのリロードも不要でした。URLを少しきれいにしましょう。conf/routeファイルを修正して、”Application.index”を”WidgetController.list”へ変更します。

GET / WidgetController.list

簡単にできましたが、ついでに友達にも見せたいですね。Herokuへデプロイしましょう。

Step1) Linux, MacもしくはWindowsに、Herokuコマンドクライアントをインストールします。

Step2) コマンドラインからHerokuへログインします。

heroku auth:login

Step3) Herokuは、アプリケーションのデプロイにgitを使うので、.gitignoreファイルを作成して、以下を記述します。

/modules /tmp

Step4) gitリポジトリを作成して、ファイルを追加し、コミットします。

git init git add . git commit -m init

Step5) Herokuにアプリケーションを新規作成します。

heroku create -s cedar

これで、Heroku上に新しいアプリケーションを規定し、アプリケーションへのランダムな名前/のURLを割り当てます。

Step6) アプリケーションをデプロイします。

git push heroku master

アプリケーションがアセンブルされ、Heroku上にデプロイされます。

Step7) ブラウザでアプリケーションを開きます。

heroku open

ジャジャーン！これでPlay + Scala アプリがクラウド上で実行されました。

JavaOneで、これをBill Venners(ScalaTestの作者)に見せたら、scalatest.orgのWebサイト（Play + Scalaのアプリ)をHerokuへ移行してくれました。クール！

何か質問あれば、教えてください。

ツイート

Link
Latest post:

OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った

OpenWhisk+Scalaで作るServerless Architectureとっかかり

BluemixにPlayframeworkアプリケーションをデプロイする

sbt、Giter8を統合するってよ

Scala 2.12.0でSAM型

Recent Books:

新装版達人プログラマー職人から名匠への道

プリンシプルオブプログラミング3年目までに身につけたい一生役立つ101の原理原則

Scalaスケーラブルプログラミング第3版

SOFT SKILLS ソフトウェア開発者の人生マニュアル

Sparkによる実践データ解析 ―大規模データのための機械学習事例集
modal_soul debriefing
modal_soul debriefing
modalsoul

modal_soul
I guess you could call it a failure, but I prefer the term learning experience.
)

【意訳】Scala on Play2 with Squerylではじめるデータベース駆動アプリ　#scalajp　#play_ja (31 Jul 2012 | Tags: 【意訳】Scala on Play2 with Squerylではじめるデータベース駆動アプリ　#scalajp　#play_ja

Jul 31, 2012

【意訳】Scala on Play2 with Squerylではじめるデータベース駆動アプリ　#scalajp　#play_ja

Programing Play2 Heroku Database-Driven Scala Squeryl CoffeeScript JSON jQuery ScalaTest

この記事は、HerokuのPrincipal Developer EvangelistのJames Ward氏とRyan Knight氏の記事Getting Started with Play 2, Scala, and Squerylの意訳です。参考程度にどうぞ。

Getting Started with Play 2, Scala, and Squeryl

誤訳・誤植等ありましたら、@modal_soulまでリプライいただけるとありがたいです。

サマリー

この記事では、Play2,Scala,Squeryl,JSON,CoffeScript,CoffeScript,jQueryとScalaTestを使ったWebアプリケーションの作り方を紹介します。また、同時にScalaTestを使ったテスト方法とHerokuを使ったクラウド環境へのアプリケーションデプロイについても学べます。

Play2,Scala,Squeryl,JSON,CoffeScript,jQueryとScalaTestの組み合わせによって、モダンなWebアプリケーションの構築とテストを効率的に行うことができ, シンプルなデータベース駆動Webアプリケーションの構築、テスト、クラウドへのデプロイを体験できます。

Play2の紹介

Play2は数あるWebフレームワークの中でも、ステートレスアーキテクチャで設計された、ユニークなWebフレームワークです。 Play2は、メモリやCPUなどのリソースの消費を抑えた、とても軽量なフレームワークです。ステートレスであるため、昨今クラウドアーキテクチャにとって重要な、水平のスケーリングを容易に行うことができます。他のアーキテクチャの特徴としては、完全に非同期なHTTPプログラミングモデルを使った、Websocketやcometのようなlong lived-connectionを利用するために設計されていることです。

また他の特徴としては、Herokuのようなクラウドアプリケーションプラットフォームへのデプロイに適するように、完璧に完結していることです。 Playアプリケーションのデプロイはシンプルで、コンテナベースのアプローチをしてきたJava開発者の多くが経験してきた環境齟齬を回避することができます。

Ruby on Rails, GrailsやDjangoなどの新しいWebフレームワークは、動的型付によってとても優れた生産性を発揮します。Playも動的言語フレームワークが持っているのと同じように、素早い繰り返しと高速な開発を行うことができ、しかしながらJavaやScalaのような静的型付言語による恩恵も留めています。これによりコンパイラは生産性を妨害することなく開発者を支援することができます。

Squerylの紹介

データベースとのインテグレーションに最適の技術は何か？これは今まで幾度と無く討論されてきました。幸いなことに、JavaやScalaのエコシステムでは、データの永続化の方法が複数用意され、選択することができます。 Play2のデフォルトのデータベースマッピングツールはAnormが使われています。(※AnormはORMではありません) 名前が指し示す通り、Anormはオブジェクトとリレーショナルモデルとの自動マッピングを行いません。代わりに、開発者はネイティブなSQLを書き、手動でリレーショナルデータとオブジェクトのマッピングを行います。この手法では、実行される生のクエリーをチューニングすることができるという利点があります。 Playの開発者は、SQLを使用することはリレーショナルデータベースとの対話とSQL層を抽象化することにおいての優れたDSLであり、パワフルで柔軟な方法だと主張してます。

Squerylは、Scalaにおけるデータ永続化のためのAnormの代替手段です。Anormと比較して、SquerylはHibernateに似ており、オブジェクトリレーショナルマッピングを提供します。Squerylはデータベースとの対話において、型安全なDSLを提供します。またSquerylは、明示的に取得されるデータオブジェクトの粒度を制御することができます。 Hibernateのような従来のORMと共通のN+1問題に対するエレガントなソリューションを提供します。

SquerylはPlay2のデフォルトのデータ永続化ライブラリではありませんが、特別な追加設定やセットアップは必要としません。データベースエボリューションは手動で行う必要があり、データベース接続は初期起動時に生成する必要があります。トランザクションも同様に、コントローラーで呼ばれた際に、明示的に定義される必要があります。

Play2でのSquerylのセットアップ

Play2プロジェクトがまだない場合、Play2をインストール後、新規プロジェクトを作成しましょう。

play new mysquerylapp

プロジェクトの言語はScalaを選択しましょう。

SquerylライブラリをPlayプロジェクトに追加する必要があります。後ほどプロジェクトはHerokuにデプロイします。HerokuのデフォルトのデータベースはPostgreSQLで、PostgreJDBCドライバーも依存関係にあるためここで追加します。

project/Build.scalaファイルを編集し、依存関係を更新しましょう。

val appDependencies = Seq(
  "org.squeryl" %% "squeryl" % "0.9.5-2",
  "postgresql" % "postgresql" % "9.1-901-1.jdbc4"
)

IDEにEclipseやIntellijを使っている場合、Playはプロジェクトを自動作成してくれます。

Intellijの場合

play idea

Eclipseの場合

play eclipsify

ここでは注意ですが、プロジェクトファイルは依存関係を更新した後に作成しましょう。なぜならプロジェクトは必要なライブラリも含めて構成されるからです。もし後で依存関係を更新する場合は、プロジェクトを生成するコマンドを再度実行してください。

これでプロジェクトを実行することができます。プロジェクトルートに移動し、以下のコマンドを実行しましょう。

play ~run

サーバは以下のURLで起動しています。確かめてみましょう。

http://localhost:9000

ローカルでのテストではインメモリのh2データベースを使用します。Playでこのデータベースを使用するには、conf/application.confファイルを修正し、以下の行のコメントアウトの解除か、行の追加をします。

db.default.driver=org.h2.Driver
db.default.url="jdbc:h2:mem:play"

最後のセットアップ手順として、Squerylデータベースを接続します。データベースの接続情報を取得するために、Play標準の構成システムを使います。 Playアプリケーションのライフサイクルのスタートアップフェーズにフックするグローバルクラスを追加するだけで完了です。 app/Global.scalaファイルを新規に作成し、以下を記述します。

import org.squeryl.adapters.{H2Adapter, PostgreSqlAdapter}
import org.squeryl.internals.DatabaseAdapter
import org.squeryl.{Session, SessionFactory}
import play.api.db.DB
import play.api.GlobalSettings

import play.api.Application

object Global extends GlobalSettings {

  override def onStart(app: Application) {
    SessionFactory.concreteFactory = app.configuration.getString("db.default.driver") match {
      case Some("org.h2.Driver") => Some(() => getSession(new H2Adapter, app))
      case Some("org.postgresql.Driver") => Some(() => getSession(new PostgreSqlAdapter, app))
      case _ => sys.error("Database driver must be either org.h2.Driver or org.postgresql.Driver")
    }
  }

  def getSession(adapter:DatabaseAdapter, app: Application) = Session.create(DB.getConnection()(app), adapter)

}

アプリケーションスタートアップのdb.default.driver設定パラメータは、データベース接続のセットアップのために使用するドライバを決定するために使われます。新しいコネクションが生成され、SquerylのSessionFactoryにストアされます。

ブラウザで、http://localhost:9000をリロードすると、アプリケーションが動作し、PlayのSTDOUTログで以下のメッセージが表示されるはずです。

[info] play - database [default] connected at jdbc:h2:mem:play

Entityの作成

それでは、データベースでデータを保持するためのシンプルなEntityオブジェクトを作成しましょう。app/models/Bar.scalaファイルを新規に作成し、以下のを記述します。

package models

import org.squeryl.{Schema, KeyedEntity}

case class Bar(name: Option[String]) extends KeyedEntity[Long] {
  val id: Long = 0
}

object AppDB extends Schema {
  val barTable = table［Bar］("bar")
}

これはBarオブジェクトのリストを保持するかなりシンプルなentityです。各々のBarはnameとプライマリキーとしてIDを持っています。Scalaのcase classは,不変で、基本的にクラスを文法上の便宜で満たすものです。また、クライアントから返却されたフォーム値のマッチングを行う際にとても便利なパターンマッチングとして使用することもできます。AppDBオブジェクトは、Squerylがデータベースへマッピングするスキーマのインスタンスです。今回の場合、データベースにbarというテーブルを１つ定義します。スキーマは単一のオブジェクトとして宣言されるため、シングルトンオブジェクトを生成します。

Squerylを使うと、AppDB.createメソッドを呼ぶだけでプラグラムチックにデータベーススキーマを生成することができます。ですが、手動でSQLスクリプトを作成する方法をお勧めします（PlayではこのSQLスクリプトをevolutions scriptと呼びます)。Playは、これらのSQLスクリプトに対応するデータベーススキーマをチェックして、データベーススキーマの変更を追跡します。Playは、スキーマが古くなっていることを検出すると、このSQLスクリプトの適用を提案してきます。これはDEVモードのときにのみ行われ、PRODモードでは、アプリケーションの起動前にスクリプトを適用されます。これにより、データベーススキーマの変更やバージョンのロールバックを行う必要がある場合に、スキーマの変更をコントロールすることができます。

conf/evolutions/default/1.sqlファイルを新規作成して、以下を記述します。

# --- First database schema

# --- !Ups

create sequence s_bar_id;

create table bar (
  id    bigint DEFAULT nextval('s_bar_id'),
  name  varchar(128)
);


# --- !Downs

drop table bar;
drop sequence s_bar_id;

このSQLファイルは”Ups”と”Downs”の2つのセクションから成っています。”Ups”セクションは、データベーススキーマに変更を反映させ、”Downs”セクションは、データベースへの変更を取り消す際の記述です。Playは、データベーススキーマへの変更をこれらのファイルの名前順に適用します。もし、デプロイ後1.sqlの適用後にスキーマへ変更を行う必要がある場合は、2.sqlファイルに変更内容を記述します。 http://localhost:9000をリロードすると、Playがデータベースへの変更を適用するか尋ねてくるはずです。1.sqlの”Ups”セクションをローカルのインメモリデータベースに適用するために、Apply this script now!ボタンをクリックします。

モデルのテスト

Play2では、テスト駆動開発のスタイルに合った強力なテストサポートがなされています。ScalaでPlay2を使う場合、テストはデフォルトでspaes2が使われていますが、ScalaTestを使用します。Barモデルオブジェクトのシンプルなテストを作ります。プロジェクトにScalaTestの依存関係を追加し、testOptions設定を修正します。project/Build.scalaを以下を追記して更新します。

val appDependencies = Seq(
  "org.scalatest" %% "scalatest" % "1.8" % "test",
  "org.squeryl" %% "squeryl" % "0.9.5-2",
  "postgresql" % "postgresql" % "9.1-901-1.jdbc4"
)

val main = PlayProject(appName, appVersion, appDependencies, mainLang = SCALA).settings(
  testOptions in Test := Nil
  // Add your own project settings here
)

test/BarSpec.scalaを新規作成し以下を記述します。

import models.{AppDB, Bar}

import org.scalatest.FlatSpec
import org.scalatest.matchers.ShouldMatchers

import org.squeryl.PrimitiveTypeMode.inTransaction

import play.api.test._
import play.api.test.Helpers._

class BarSpec extends FlatSpec with ShouldMatchers {

  "A Bar" should "be creatable" in {
    running(FakeApplication(additionalConfiguration = inMemoryDatabase())) {
      inTransaction {
        val bar = AppDB.barTable insert Bar(Some("foo"))
        bar.id should not equal(0)
      }
    }
  }

}

このテストでは、実行するためにFakeApplicationとインメモリデータベースを使います。FakeApplicationを使用すると、Squerylデータベースコネクションは先に生成されたGlobalオブジェクトを使って構成されます。テスト本体は単純にBarのインスタンスを生成し、idが０ではないことをテストします。これはSquerylトランザクションで行われます。 1系のPlayと異なり、テストはコマンドラインから実行されます。コマンドは以下

play test

テストが終了したら、以下のメッセージがPlayのSTDOUTログに出力されていることを確認します。

[info] Passed: : Total 1, Failed 0, Errors 0, Passed 1, Skipped 0

ソースの変更の度にテストを実行するには、以下のコマンドで実行します

play ~test

~runと~testコマンドはバックグラウンドで継続して実行することができます。これにより、ユニットテスト/機能テストやブラウザからの手動テストをすぐさま実行することができます。

WebフォームからBarを生成する

新しくBarオブジェクトを生成するための基本的なWeb UIを追加してみましょう。このセクションの手順を全て踏まないとコードのコンパイルができないので注意してください。

最初に、app/controllers/Application.scalaファイルを下記の記述を追加して更新します。

package controllers

import play.api.mvc._

import com.codahale.jerkson.Json
import play.api.data.Form
import play.api.data.Forms.{mapping, text, optional}

import org.squeryl.PrimitiveTypeMode._
import models.{AppDB, Bar}


object Application extends Controller {

  val barForm = Form(
    mapping(
      "name" -> optional(text)
    )(Bar.apply)(Bar.unapply)
  )

  def index = Action {
    Ok(views.html.index(barForm))
  }

  def addBar = Action { implicit request =>
    barForm.bindFromRequest.value map { bar =>
      inTransaction(AppDB.barTable insert bar)
      Redirect(routes.Application.index())
    } getOrElse BadRequest
  }

}

barFormは、リクエストパラメーターnameからcace class Barのプロパティnameへ（コンストラクタを通して）マッピングをします。indexメソッドは、index templateへbarFormのインスタンスを渡すように更新されました。次にtemplateを更新します。addBarメソッドは、リクエストパラメーターをオブジェクトbarにバインドし、トランザクション内でデータベースへインサートします。SquerylはPlay frameworkに統合されていないので、データベーストランザクションはSquerylのinTransactionを使って明示的に開始する必要があります。次にユーザはindexページにリダイレクトされます。リクエストパラメータがbarFormを使ってBarにマッピングされなかった場合、BadRequestエラーが返却されます。

次にapp/views/index.scala.htmlテンプレートに以下を追記して更新します。

 ＠(form: play.api.data.Form[Bar])

 ＠main("Welcome to Play 2.0") {

    @helper.form(action = routes.Application.addBar) {
        @helper.inputText(form("name"))
        <input type="submit"/>
    }

}

この時点で、テンプレートはApplication Controllerのindexメソッドから渡されたForm[Bar]パラメータを取ります。テンプレート本体の新しいHTMLフォームはPlay2のform helperを使ってレンダリングされます。このフォームは、nameフィールドとsubmitボタンを持ちます。注意しなければいけないのは、フォームのアクションは、ルートからApplication controllerのaddBarメソッドへを指していることです。

この時点でコンソールウィンドウをみると”value addBar is not a member of controllers.ReverseApplication”エラーがみられると思います。これは、routeファイルがコンパイルされ、routeがチェックされたからです。まだrouteが作られていないので、conf/routesファイルを編集し、以下の行を追加します。

POST    /bars                       controllers.Application.addBar

これにより、/barsURLへのPOSTリクエストをaddBarメソッドへマッピングするHTTPルートを作成します。

ブラウザでhttp://localhost:9000 を更新すると、新しいBarオブジェクトを追加するための基本的なフォームが表示されているはずです。成功した場合、新しいBarを追加した後に、ブラウザはindexページにリダイレクトして戻ります。

これで一通りが動くようになったので、controllerのコードに戻り、これらの動作についてより理解しましょう。addBarメソッドについて理解することは、コンパイラが周囲のスコープから値を見つけるために、どのように暗黙的なキーワードを通知するかを理解するのに役立ちます。Scalaでは、implicitキーワードは、implicit関数のパラメータもしくは、inplicitオブジェクトへの変換としても使用することができます。二つは全く異なりますが、両方ともにScalaの定義を解決する方法に関連しています。この場合、implicitは一つもしくはそれ以上の関数を呼ぶ場合と全ての関数に同じあたいを渡す必要がある場合に使われます。この手順は、APIを構成する際に便利で、ユーザはいつも何のパラメータが使用されるかについて明示する必要がなくなりますが、変わりにデフォルト値に依存します。

addBarの場合、barForm.bindFromRequestメソッドがplay.api.mvc.Requestパラメータをとり、明示的に渡す必要がないため、リクエストをimplicitと明示します。

参考に、Form.bindToRequestメソッドのメソッド定義を記載します。

def bindFromRequest()(implicit request: play.api.mvc.Request[_]): Form[T] = {...}

bindFromRequestはフォームオブジェクトを返します。addBarメソッドでは、この場合Option[Bar]を返却するFormインスタンスのvalueメソッドを呼び出します。そして、呼び出しもとのマップがBarを取得し、フォームマッピングから生成できれば生成し、そうでなければgetOrElseステートメントはBadRequestを返却します。Barオブジェクトが生成することができた場合、それはトランザクション内でデータベースに保存されます。

これで、Squerylでリクエストパラメータとオブジェクトをマップしオブジェクトを保存する方法について理解できたと思うので、新しいaddBar controllerメソッドのテストを書きましょう。

Barの追加のテスト

下記の記述を新規作成したtest/ApplicationSpec.scalaファイルを記述し、addBar controllerメソッドの新しいテストを作ります。

import controllers.routes
import models.{AppDB, Bar}

import org.scalatest.FlatSpec
import org.scalatest.matchers.ShouldMatchers

import org.squeryl.PrimitiveTypeMode.inTransaction

import play.api.http.ContentTypes.JSON
import play.api.test._
import play.api.test.Helpers._

class ApplicationSpec extends FlatSpec with ShouldMatchers {

  "A request to the addBar action" should "respond" in {
    running(FakeApplication(additionalConfiguration = inMemoryDatabase())) {
      val result = controllers.Application.addBar(FakeRequest().withFormUrlEncodedBody("name" -> "FooBar"))
      status(result) should equal (SEE_OTHER)
      redirectLocation(result) should equal (Some(routes.Application.index.url))
    }
  }

}

機能テストではインメモリーデータベースとFakeApplicationを使います。テストでは、Application controllerのaddBarメソッドへのリクエストとnameという名前でFooBarという値のフォームパラメータを生成します。このテストの成功は、シンプルにindexページへリダイレクトされることで、ステータスがSEE_OTHER(HTTP 303ステータスコード)であるかをチェックし、リダイレクトのロケーションはindexページのURLでチェックされます。play testでテストを実行するか、play ~testであればコードの変更のタイミングでテストが実行されています。

JSONとしてBarを取得する

JSONのシリアライズされたデータとして全てのBarオブジェクトをアプリケーションへ返却するRESTfulなサービスを追加しましょう。app/controllers/Application.scalaファイルに新しいメソッドを追加します。

  def getBars = Action {
    val json = inTransaction {
      val bars = from(AppDB.barTable)(barTable =>
        select(barTable)
      )
      Json.generate(bars)
    }
    Ok(json).as(JSON)
  }

getBarsメソッドは、Squerylを使用してデータベースからBarオブジェクトを取ってきて、BarオブジェクトのJSON形式のリストを生成し、JSONデータを返却します。

conf/routesファイルに新しいルートを追加します。

GET     /bars                       controllers.Application.getBars

これにより、/barsへのGETリクエストがgetBarsメソッドへマッピングされます。

ブラウザでhttp://localhost:9000/barsを表示させ確認してみましょう。

JSONとしてシリアライズされたBarオブジェクトのリストが見られるはずです。

前述した通り、トランザクションはSquerylのinTransactionで明示的に開始される必要があり、データベースから値をselectする場合もです。そして、トランザクション内で、Barの全てののエンティティはデータベースから取得されます。

クエリーの構文は、Squerylのタイプ・セーフなクエリー言語の力とDSLを作るためのScalaの力を示しています。from関数は最初のパラメータとしてテーブルへのタイプ・セーフな参照を受け取ります。これはキーワードからのSQLに似ています。２番目のパラメータは、パラメータとしてクエリーにテーブルを取得し、そのテーブル上に何をするかを指定します。この場合はselectです。formは、barsを不変な定数にセットされている反復処理可能なオブジェクトを返却します。その後、Json.generateメソッドは、データベースから取得されたbarsを反復処理し、それらを返却します。jsonの定数は、application/json(JSONの値)にセットされたコンテントタイプと共に、OK(HTTP 200ステータスコードの応答)で返却されます。

JSONサービスをテストする

JSONサービスをテストする新しいテストのためにtest/ApplicationSpec.scalaを更新します。以下を追記します。

"A request to the getBars Action" should "respond with data" in {
    running(FakeApplication(additionalConfiguration = inMemoryDatabase())) {
      inTransaction(AppDB.barTable insert Bar(Some("foo")))

      val result = controllers.Application.getBars(FakeRequest())
      status(result) should equal (OK)
      contentAsString(result) should include ("foo")
    }
  }

再びこの機能テストでは、FakeApplicationとインメモリデータベースを使用します。そしてデータベースに新しいBarを生成し、Application controllerのgetBarsメソッドへのリクエストを作ります。テストしたレスポンスはOK(HTTP 200)で、生成されたBarの名前を含んでいるはずです。前と同じように、play testでこのテストを実行するか、play ~testで実行します。これで３つのテストに通っているはずです。

CoffeScriptとjQueryでBarsを表示する

これで、Barオブジェクトのリストを取得するRESTfulなJSONサービスができたので、取得とindexページへの表示を行うようCoffeScriptとjQueryを使って書いてみましょう。Play2の新しい機能の一つに、CoffeeScriptからJavaScriptへコンパイルとJavaScriptの構文チェック、ミニファイ化、LESSのCSSへのコンパイルを行うassetコンパイラがあります。

app/assets/javascripts/index.coffeeファイルを新規作成し、下記を記述します。

$ ->
  $.get "/bars", (data) ->
    $.each data, (index, item) ->
      $("#bars").append $("<li>").text item.name

このCoffeeScriptは、/barsへのgetリクエストを作るためにjQueryを使用し、各barに対して反復処理を行い、barsのidと共にbarをページのエレメントに追加します。では、このスクリプトをロードするためにapp/views/index.scala.htmlテンプレートを更新し、ページにbarsエレメントを入れてみましょう。以下の記述をテンプレートのmainセクションのトップに追加します。

 <script src="@routes.Assets.at("javascripts/index.min.js")" type="text/javascript"></script>    
    <ul id="bars"></ul>

スクリプトのsrcは、javascripts/index.min.jsファイルへのURLを取得するためにroutes.Assets.at関数を使うことに注意してください。まだこのファイルは存在していません。Playのassetコンパイラは、index.coffeeファイルをコンパイルしてミニファイ化されたこのファイルを生成する必要がることを検知します。再度http://localhost:9000 のWebページを読み込み、新しいBarを生成し、Webページに表示されることを確認しましょう。

Herokuへのデプロイ

Herokuはクラウド上でPlay2の実行環境を提供する複数言語対応したCloud Application Platformです。このアプリケーションをHerokuへデプロイするには以下の手順を実行します。

1. 下記の内容を記述したProcfileをルートディレクトリは以下に作成します。

web: target/start -Dhttp.port=${PORT} -DapplyEvolutions.default=true -Ddb.default.driver=org.postgresql.Driver -Ddb.default.url=${DATABASE_URL} ${JAVA_OPTS}

これによりHerokuへPlayアプリケーションの実行方法を伝えます。

2. Herokuは、Heroku上へのファイル転送にGitを用います。まだGitがインストールされていないのであれば、Gitをインストールしましょう。プロジェクトのルートディレクトリから、このプロジェクト用のGitリポジトリを生成し、ファイルを追加し、コミットします。

git init
git add .
git commit -m init

3. HerokuのツールベルトはHerokuへのコマンドラインインターフェースです。Heroku ツールベルトをインストールしましょう。

4. Herokuアカウントへサインアップします。

5. コマンドラインからHerokuへログインします：

heroku login

GitのSSHキーをセットアップし、それをHerokuアカウントへ紐付けます。

6. 新しいアプリケーションをHerokuにプロビジョニングします。

heroku create --stack cedar

7. HerokuへアプリケーションをPushします。

git push heroku master

Herokuが、SBTでアプリケーションをビルドし、dyno上で実行します。

8. ブラウザでクラウド上で実行されるアプリケーションを開きましょう。

heroku open

おめでとうございます！これであなたのアプリケーションはクラウド上で実行されています。

Play2について思うところはありませんか？Getting Started with Play2, Scala, and Squerylのフォーラムトピックで議論しましょう。

リソース

このプロジェクトの全てのソースコードは、Github上から入手することができます。

https://github.com/jamesward/play2bars/blob/scala-squeryl

ローカルでPlayが実行されている場合、Playのローカルドキュメントにアクセスできます。

http://localhost:9000/@documentation

下記のサイトでもPlayのドキュメントを閲覧できます。

http://www.playframework.org/documentation

Herokuについては、Heroku Dev Centerを見てください。

http://devcenter.heroku.com/

この記事が一助となればと思いますが、もし質問や問題があれば我々に知らせてください。

著者について

James Ward (www.jamesward.com) is a Principal Developer Evangelist at Heroku. Today he focuses on teaching developers how to deploy Java, Play! and Scala apps to the cloud. James frequently presents at conferences around the world such as JavaOne, Devoxx, and many other Java get-togethers. Along with Bruce Eckel, James co-authored First Steps in Flex. He has also published numerous screencasts, blogs, and technical articles. Starting with Pascal and Assembly in the 80’s, James found his passion for writing code. Beginning in the 90’s he began doing web development with HTML, Perl/CGI, then Java. After building a Flex and Java based customer service portal in 2004 for Pillar Data Systems he became a Technical Evangelist for Flex at Adobe. You can find him tweeting as @JamesWard, answering questions on StackOverflow.com, and posting code at github.com/jamesward.

Ryan Knight is a senior software architect and consultant with over fifteen years of experience in all aspects of cloud computing and software development. He first started Java Consulting for Sun Microsystems Java Center and now runs his own consulting company. Some of his recent projects include being a software Consultant for Deloitte at the State of Louisiana, expert services for Adobe at T-Mobile, creatng a web application at Team Marketing Report, development of a text and voice chat system for Sony Online Entertainment, contributing to the Development of a Gift Card Creation Tool, and being a software architect for Williams Pipeline.

Link

Latest post:

Recent Books:

)

【意訳】データベース駆動アプリのための、Play2最適化について　#play_ja (26 Jul 2012 | Tags: 【意訳】データベース駆動アプリのための、Play2最適化について　#play_ja

modal_soul debriefing

Book Category Tag About
Jul 26, 2012
【意訳】データベース駆動アプリのための、Play2最適化について　#play_ja

Programing Play2 Heroku Database-Driven Akka

この記事は、HerokuのPrincipal Developer EvangelistのJames Ward氏の記事の意訳です。参考程度にどうぞ。

誤訳・誤植等ありましたら、@modal_soulまでリプライいただけるとありがたいです。

先週Matt Raible氏と共に、UberConfで行われたPlay vs. Grailsスマックダウンでプレゼンテーションをしました。このセッションの目標は、同じフレームワークを用いて同じアプリケーションを作り、Play2+JavaとGrailsを比較することです。比較のために、いくつかのベンチマークを含む評価基準を使用しました。結果については、こちら（Matt’s session recap blog）に詳しく掲載されています。評価結果のプレゼンの後、これらのタイプのアプリケーションでPlay2のAkkaスレッドシステムを最適化するのに重要なことを発見しました。 Play2は、ブロッキングのコールを含まないHTTPリクエスト(i.e. 非同期)のためにout-of-the-boxに最適化されています。 Javaのほとんどのデータベース駆動アプリでは同期コールはJDBC経由で使用されるため、Play2ではこれらのリクエストタイプのためにAkkaを調整するちょっとした設定が必要です。

シンプルな例をあげてみます。時間的に現実的なデータベースブロックをシミュレートするために、このベンチマークをローカルではなくHeroku上で実行します。 “play2bars”example appから”java-ebean”ブランチとHerokuの共有のPostgreSQLデータベースを使います。

Apache Benchを実行して、同時100クライアント接続で10000リクエストをアプリのJSONサービスへ投げるために、同じAWSリージョンにあるEC2サーバーからHerokuのmy appとして、以下のコマンドを実行しました。

ab -n 10000 -c 100 http://falling-dusk-7291.herokuapp.com/bars

最初の最適化前の結果がこちらです

Concurrency Level: 100 Time taken for tests: 10.272 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Total transferred: 1560000 bytes HTML transferred: 510000 bytes Requests per second: 973.53 [#/sec] (mean) Time per request: 102.719 [ms] (mean)

毎秒973リクエストは悪くはありませんが、下記のようなエラーが確認できました。

[error] play - Cannot invoke the action, eventually got an error: Thrown(akka.pattern.AskTimeoutException: Timed out)

これは、Akkaが長時間ブロックされたことを意味しており、同期のコード実行を改善するようにPlay中のAkkaの設定を変え、評価を再実行しました。その結果は以下のようになりました。

Concurrency Level: 100 Time taken for tests: 7.274 seconds Complete requests: 10000 Failed requests: 0 Write errors: 0 Total transferred: 1560000 bytes HTML transferred: 510000 bytes Requests per second: 1374.70 [#/sec] (mean) Time per request: 72.743 [ms] (mean)

今回は、毎秒1374リクエストになりました。シンプルな最適化の方法は、Akkaで処理を行うスレッドを増やすして、タイムアウト値を長く設定することです。それによりスレッドが同期DBによってブロックされた際、より多くのリクエストをハンドリングするためにさらにスレッドを呼び出します。実際に使ったPlayの設定は以下です。

play { akka { actor { deployment { /actions { router = round-robin nr-of-instances = 100 } /promises { router = round-robin nr-of-instances = 100 } } retrieveBodyParserTimeout = 5 seconds actions-dispatcher = { fork-join-executor { parallelism-factor = 100 parallelism-max = 100 } } promises-dispatcher = { fork-join-executor { parallelism-factor = 100 parallelism-max = 100 } } } } }

Akkaで使用されるスレッドの数は、CPUと”parallelism-factor”の設定値を掛け合わせた値で、”parallelism-max”が上限値です。デフォルトの”parallelism-factor”は”1”に設定されていて、この場合スレッド数はCPU数と同じで、”parallelism-max”のデフォルトは”24”です。これらの設定について詳しくは、Playのドキュメントで確認できます。

すべての設定ファイルはこちらのplay2barsプロジェクトから

このベンチマークはあくまで参考であって、それぞれの環境で異なってくると思います。それぞれの環境に合わせたチューニングをしてください。質問があれば是非。

ツイート

Link
Latest post:

OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った

OpenWhisk+Scalaで作るServerless Architectureとっかかり

BluemixにPlayframeworkアプリケーションをデプロイする

sbt、Giter8を統合するってよ

Scala 2.12.0でSAM型

Recent Books:

新装版達人プログラマー職人から名匠への道

プリンシプルオブプログラミング3年目までに身につけたい一生役立つ101の原理原則

Scalaスケーラブルプログラミング第3版

SOFT SKILLS ソフトウェア開発者の人生マニュアル

Sparkによる実践データ解析 ―大規模データのための機械学習事例集
modal_soul debriefing
modal_soul debriefing
modalsoul

modal_soul
I guess you could call it a failure, but I prefer the term learning experience.
)
【意訳】Tutorial：Play Framework 2 with Scala, Anorm, JSON, CoffeeScript, jQuery＆Heroku［Herokuデプロイ編］ (04 Mar 2012 | Tags: 【意訳】Tutorial：Play Framework 2 with Scala, Anorm, JSON, CoffeeScript, jQuery＆Heroku［Herokuデプロイ編］

modal_soul debriefing

Book Category Tag About
Mar 4, 2012
【意訳】Tutorial：Play Framework 2 with Scala, Anorm, JSON, CoffeeScript, jQuery＆Heroku［Herokuデプロイ編］

Programing Play2 Scala CoffeeScript jQuery Heroku Anrom

元記事はこちら

少々長い記事なので、Play2アプリのビルド編とHerokuへのデプロイ編に分けます。

今回は、Herokuへのデプロイ編です。

Play2アプリのビルド編は、こちら

Step 1) Herokuのアカウントを取得して、Heroku Toolbeltとgitをインストールして、コマンドラインからHerokuへログインします

$ heroku login

もしこれがはじめてのHerokuへのログインだったら、git用のSSHキーの作成と、Herokuアカウントへの紐付けをする必要があります。

Step 2) Heroku上の各アプリケーションは、テスト用にPostgres DBを持っています。 Heroku上でアプリケーションを実行してこのDBを使うには、別途設定が必要です。これにはいくつか方法がありますが、最も簡単な方法はスタートアップコマンドラインからDBの設定をオーバーライドする方法です。これはStep3で紹介します。その前に、Psotgres JDBCドライバーをプロジェクトの依存関係として指定する必要があります。 “project/Build.scala”ファイルに、以下のような”appDependencies”を設定します。

val appDependencies = Seq( "postgresql" % "postgresql" % "9.1-901-1.jdbc4" )

Step 3) Herokuにどのプロセスを実行するのかを教えるために、プロジェクトルートディレクトリ配下にファイル名”Procfile”を作成し（※大文字と小文字が区別されます）、以下のように記述します

web: target/start -Dhttp.port=$PORT -DapplyEvolutions.default=true -Ddb.default.driver=org.postgresql.Driver -Ddb.default.url=$DATABASE_URL

Play2では、プロジェクトのビルドにScala Build Tool(SBT)を使います。プロジェクトがHerokuへデプロイされると、プロジェクトをコンパイルするため”sbt stage!コマンドが実行されます。そして、プロセスがJavaのクラスパスの設定とPlayサーバーの起動をする”taget/start”スクリプトを生成します。 Herokuはアプリケーションに、Javaプロパティ”http.port”が適宜設定されるように、環境変数”PORT”を使用してリッスンすべきHTTPポートを通知します。また、Heroku上のアプリケーションへDB（とその他のリソース）への接続文字列は、デフォルトでは環境変数介して渡されます。環境変数のDATABASE_URLは、DBホスト、名前、ユーザ名、パスワードを含みます。所謂”db.default.url”プロパティがその値で設定されます。またドライバは、Postgres JDBCドライバクラスに設定されます。

Step 4) Herokuはアプリケーションのアップロード方法としてgitを使っています。 SCMツールにgitを使っていようと無かろうとHerokuへアプリケーションをアップロードするにはgitを使います。プロジェクトのルートディレクトリでgit repoを作り、ファイルを追加してコミットします。

git init git add Procfile app conf project public git commit -m init

※ 選択しての”git add”の代わりに、”.gitignore”ファイルを更新することもできます。

Step 5) Heroku CLIを使用して、Heroku上に新しいアプリケーションをプロビジョニングします。あなたが作った各アプリケーションは1月辺り、750“dyno”時間無料です。開発者として無料でHerokuを使用でき、スケールした分だけ支払うことになります。コマンドライン上で、”cedar”スタックを使って新しいアプリケーションを作ります。

heroku create -s cedar

これでアプリケーションのHTTPとgitのエンドポイントを作ります。アプリケーションで変更した名前を使うことも、自身のドメイン名を使うことも可能です。

Step 6) アプリケーションはクラウドへデプロイする準備が整いました。コマンドラインからHerokuのマスターブランチへ”git push”します。

git push heroku master

Herokuがファイル受け取ると、Play Frameworkのプレコンパイラが実行され、Herokuが”slug file”をアセンブルし、”slug”がdynoへデプロイされます。

Step 7) これで”heroku create”に続いて出力のドメインに移動する、もしくは単純に実行することで、ブラウザでアプリケーションを表示できます。

heroku open

Scala, Anorm, JSON, CoffeeScript, jQueryを使ったPlay2アプリケーションをHeroku上にデプロイできたはずです。これよりも詳細にHerokuの使い方を知りたいときは、Heroku Dev Centerを確認してください。もし質問があったら、私に知らせてください。

このエントリーは、CoffeeScript, jQuery, Play Framework, Scalaを使ってポストされました。パーマリンクをブックマークしてください。コメントかトラックバックをよろしく。トラックバックURLは、こちら

ツイート

Link
Latest post:

OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った

OpenWhisk+Scalaで作るServerless Architectureとっかかり

BluemixにPlayframeworkアプリケーションをデプロイする

sbt、Giter8を統合するってよ

Scala 2.12.0でSAM型

Recent Books:

新装版達人プログラマー職人から名匠への道

プリンシプルオブプログラミング3年目までに身につけたい一生役立つ101の原理原則

Scalaスケーラブルプログラミング第3版

SOFT SKILLS ソフトウェア開発者の人生マニュアル

Sparkによる実践データ解析 ―大規模データのための機械学習事例集
modal_soul debriefing
modal_soul debriefing
modalsoul

modal_soul
I guess you could call it a failure, but I prefer the term learning experience.
)
【意訳】Tutorial：Play Framework 2 with Scala, Anorm, JSON, CoffeeScript, jQuery&Heroku ［Play2アプリのビルド編］ (29 Feb 2012 | Tags: 【意訳】Tutorial：Play Framework 2 with Scala, Anorm, JSON, CoffeeScript, jQuery&Heroku ［Play2アプリのビルド編］

modal_soul debriefing

Book Category Tag About
Feb 29, 2012
【意訳】Tutorial：Play Framework 2 with Scala, Anorm, JSON, CoffeeScript, jQuery&Heroku ［Play2アプリのビルド編］

Programing Play2 Scala CoffeeScript jQuery Heroku AnormEdit

元記事はこちら

少々長い記事なので、Play2アプリのビルド編とHerokuへのデプロイ編に分けます。

今回は、Play2アプリのビルド編です。

Herokuへのデプロイ編は、こちら

※ 2012/03/06:アドバイスいただいた箇所について修正しました。

Play Framework2 RC2がリリースされ、モダンなWebアプリケーションを構築する手法として成熟した生産的な方法になっています。

Play2とScala,Anorm,JSON,CoffeeScript,jQueryを使って迅速なアプリケーション構築を体験してみましょう。

一度ローカルでアプリケーションが動いてしまえば、あとはHerokuにデプロイするだけです。

（注意：これはmy Play1+Java turtorialの、Play2＋Scala版です。）Githubからソースを入手してください。

Step 1) Play2 RC2版をダウンロード・インストールしてください。

Step 2) 新しいアプリケーションを作ります：

$ play new foobar

プロンプトの言語選択画面がでたら、Scalaを選択してください。

Step 3) 新しく作成した”foobar”ディレクトリ配下にIDEの設定ファイルを生成します。

IntelliJでは、このように実行します。

$ play new foobar

注意：ここで生成されたIMLファイルは、プロジェクトとして直接インポート可能ではありません。代わりに、モジュールなしでプロジェクトを新たに生成して、このステップで生成したIMLファイルからそのプロジェクトへモジュールをインポートする必要があります。もしわからなければ、Play1+Scala IntelliJ articleが参考になります。

Eclipseプロジェクト化するために、下記のコマンドを実行

$ play eclipsify

Step 4) Playサーバの起動

$ play run

正常に起動していることをテストするために、ここにアクセスhttp://localhost:9000

Step 5) Play2 with ScalaではデフォルトでORマッパーを提供していません。代わりにデフォルトのRDBMS永続性プロバイダとなっているのがAnormです(Anormは Object Relational Mapperではありません)。このシンプルなアプリケーションでは、1つの永続的オブジェクト：Bar(ひとつのプライマリキーと名前を持っている)を持っています。Anormは、自動でのスキーマ作成を行わないので、SQLスキーマの作成/廃棄のためのスクリプトが必要です。新しいファイル”conf/evolutions/default/1.sql”を作成し、以下の内容を記述します。

# --- First database schema # --- !Ups CREATE TABLE bar ( id SERIAL PRIMARY KEY, name VARCHAR(255) NOT NULL ); # --- !Downs DROP TABLE IF EXISTS bar;

Anormでは、Scalaの”case class”を永続的/CRUDインターフェースとして、値オブジェクトとシングルトンオブジェクトとして扱うことができます。”app/models/Bar.scla”というファイルにBar case classとオブジェクトを作成して、以下の内容を記述します。

package models import play.api.db._ import play.api.Play.current import anorm._ import anorm.SqlParser._ case class Bar(id: Pk[Long], name: String) object Bar { val simple = { get[Pk[Long]]（"id") ~ get[String]（"name") map { case id~name => Bar(id, name) } } def findAll(): Seq[Bar] = { DB.withConnection { implicit connection => SQL("select * from bar").as(Bar.simple *) } } def create(bar: Bar): Unit = { DB.withConnection { implicit connection => SQL("insert into bar(name) values ({name})").on( 'name -> bar.name ).executeUpdate() } } }

変数の”simple”は、データベースの行値をBar case classにマップする、基本的なパーサを提供します。

静的関数、”findAll”と”create”は、一般的なデータアクセスを行います。

注意点としては、”findAll”はBarへ各行を返すために、”simple” row parserを使っている点です。

Step 6) インメモリーのh2データベースを使うために、”conf/application.conf”ファイルに以下の値を設定する。

db.default.driver=org.h2.Driver db.default.url="jdbc:h2:mem:play"

Step 7) “app/controllers/Application.scala”を下記のように更新し、BarをHTTP POSTへ変換してデータベースに反映するアプリケーションコントローラー関数を作成します。

package controllers import play.api.data.Form import play.api.data.Forms.{single, nonEmptyText} import play.api.mvc.{Action, Controller} import anorm.NotAssigned import models.Bar object Application extends Controller { val barForm = Form( single("name" -> nonEmptyText) ) def index = Action { Ok(views.html.index(barForm)) } def addBar() = Action { implicit request => barForm.bindFromRequest.fold( errors => BadRequest, { case (name) => Bar.create(Bar(NotAssigned, name)) Redirect(routes.Application.index()) } ) } }

“barForm”マップは、フォームオブジェクトへパラメータを要求し、入力データのバリデーションを行います。静的関数の”addBar”は、リクエストと”barForm”へのリクエストパラメータのマッピングを行います。失敗した場合は、コントローラはBadRequestを返します。成功した場合は、Barの名前は新しい”Bar”を構築するために使われます。そしてその”Bar”はデータベースに保存され、indexページへのリダイレクトが送られます。 index関数は、Step 9で更新されるテンプレートへ”barForm”を渡すように変更されました。

Step 8) “conf/routes”ファイルに以下の行を追加して、”/addBar” URLへのPOSTリクエストを”Application.addBar”へマップする新しいルートを作成します。

POST /addBar controllers.Application.addBar

Step 9) フォームパラメータを受け取るために、”main”テンプレートを拡張した”app/views/index.scala.html”テンプレートを更新し、Webページ上のフォームをレンダリングするためにPlay2 form helperを使います。

　＠(form: play.api.data.Form[String]) 　＠main("Welcome to Play 2.0") ｛　＠helper.form(action = routes.Application.addBar) ｛　＠helper.inputText(form("name")) ＜input type="submit"/＞｝｝

ブラウザでhttp://localhost:9000を開き、データベース変更の適用と、フォームのテストをします。うまくできていれば、フォームを送信するとindexページへリダイレクトされるはずです。

Step 10) JSONサービスを作成し、barの全てを取得するための関数を、”app/controllers/Application.scala”ファイルに追加します。

import com.codahale.jerkson.Json def listBars() = Action { val bars = Bar.findAll() val json = Json.generate(bars) Ok(json).as("application/json") }

新しく作成した関数は、シリアル化されたJSONとして、”Bar.findAll()”から”Bar”オブジェクトのリストを返します。

“/listBars”へのリクエストのために、下記のように新しいGET request handlerを”conf/routes”に追加します。

GET /listBars controllers.Application.listBars

ブラウザでhttp://localhost:9000/listBarsを開いてみてください。Step 9で作成したbarが表示されているはずです。

Step 11) jQueryを使いJSONシリアル化されたbarの取得と、それぞれのページ追加のために、新しいCoffeeScriptファイル”app/assets/javascripts/index.coffee”を作成します。内容は以下

$ -> $.get "/listBars", (data) -＞ $.each data, (index, item) -＞ $("#bars").append "＜li＞Bar " + item.name + "＜/li＞"

CoffeScriptは、”/listBars”へのGETリクエストの作成と返却値の反復、ページ(Step 12で追加します)の”bars”エレメントへの各アイテムの追加のために、jQueryを使います。

Step 12) CoffeeScriptのソースから自動コンパイルされたindex.jsスクリプトを使うために、”app/views/index.scala.html”を以下の行を”main”ブロックへ追加し、更新します。

　＜script src="＠routes.Assets.at("javascripts/index.js")" type="text/javascript"＞＜/script＞　＜ul id="bars"＞＜/ul＞

ブラウザで、http://localhost:9000/を表示し、barがページ上部に表示され、新しいbarが期待通りに追加されていることを確認してください。

これで、Scala, Anorm, JSON, CoffeeScript, jQueryを使ったPlay2アプリのビルド完了です。ここで紹介したすべてのソースコードはGitHub上にあります。あとはHerokuへデプロイするだけです。

ツイート

Link
Latest post:

OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った

OpenWhisk+Scalaで作るServerless Architectureとっかかり

BluemixにPlayframeworkアプリケーションをデプロイする

sbt、Giter8を統合するってよ

Scala 2.12.0でSAM型

Recent Books:

新装版達人プログラマー職人から名匠への道

プリンシプルオブプログラミング3年目までに身につけたい一生役立つ101の原理原則

Scalaスケーラブルプログラミング第3版

SOFT SKILLS ソフトウェア開発者の人生マニュアル

Sparkによる実践データ解析 ―大規模データのための機械学習事例集
modal_soul debriefing
modal_soul debriefing
modalsoul

modal_soul
I guess you could call it a failure, but I prefer the term learning experience.
)

Heroku

Latest post:

Recent Books:

サマリー

Play2の紹介

Squerylの紹介

Play2でのSquerylのセットアップ

Entityの作成

モデルのテスト

WebフォームからBarを生成する

Barの追加のテスト

JSONとしてBarを取得する

JSONサービスをテストする

CoffeScriptとjQueryでBarsを表示する

Herokuへのデプロイ

Share Your Opinion

リソース

著者について

Latest post:

Recent Books:

Latest post:

Recent Books:

Latest post:

Recent Books:

Latest post:

Recent Books: