(c) Recruit Co., Ltd.
Play Framework 2.3 For Java 入門記事一覧 第2回はPlayで最初にプロジェクト内のファイルを見て何が起きてるか一番意味が分からなかったviewのテンプレートエンジンについてです。 ルーターの仕組みとかMVCの仕組みとかはRailsとかCakePHPとかと同じような感じなんだろうということでなんとなく分かる。でも、viewはほとんど何も書いてないのに、サイドバーとか色々なリンクが貼られたページが出てきてなんじゃこりゃとなった。しかも、scala.htmlっておれJavaのサンプル作ったんですけど。 Playで使ってるテンプレートエンジンについてちゃんと知らないと人に教えられないなと思ったのでまずはここを調べる。 Play Frameworkのテンプレートエンジン最高 いきなり話は飛びますが、そういうことです。 公式のJavaTemplatesの説明を読み進めながら
ScalaでDIコンテナというとGoogle Guiceを使っている人が多いと思うけど、僕は最近airframeを使い始めました。 何がどう違うのというのは以下の記事を読んで欲しい。個人的には、Scalaで使うための設計が前提になっているかが大きいと思っています。Guiceでもいいけど、無邪気に使っているとJava前提のライブラリはハマることもあるし、Scalaの独自機能に対するケアもないので…。 使い方はQuick Startを読んでください。たけぞえさんのブログ記事 「Scala用のDIライブラリAirframeを試してみた」 でも紹介されています。1 以上、終了でもよかったのですが、日本語で簡単に解説しておきます。 最低限知っておくとよいのは、Design, Sessionです。あとは、DIコンテナがサポートするLife Cycleはドキュメントをみてください。DesignとSess
def save = Action { request: Request[AnyContent] => val body: AnyContent = request.body // デフォルトでは上記のように request.body は AnyContent 型です。 Content-Type ヘッダの値によって適切な型として parse されます。たとえば Content-Type が application/json であれば JSON として parse され、request.body.asJson で JSON が取り出せます。 今回はパースされたボディと共に、生のリクエストボディにアクセスしたいと思いました。 Play では BodyParser[A] が HTTP リクエストボディを解釈します。 その定義 を見るとわかるように RequestHeader => Accumul
前置き さて、前置きですが、モナドと書きましたが実際にはモナドではなく、モナドのようなものです。 ここで言うモナドというものは、Scalaにおけるfor式で扱えるように、以下のメソッドを実装している型のことを指します。 map/flatMap （つまり、for式で使える型、ifフィルターとyieldではないfor式を除く） あと、記事中の英語は適当です。 はじめに どこかで見た便利な書き方としてfor式のネストした形式を紹介します。（具体的な呼び名は知らない。勝手にネストfor式とか言っておく。） Scalaでのエラーハンドリングはキモくなりがちです。 Either、Try、Optionの入り混ざったものを一つのfor式で扱うのは困難で、 最初にfor式中で使用したモナドに、以降も制限されてしまいます。 scala> { | for { | result <- Future { Try("
@import helper._ @main("サンプル"){ <font size=5>■サンプル画面</font><br/> @helper.form( action = helper.CSRF(routes.SampleController.sampleAction) ){ <input type = "hidden" name = "idParam" value="test" /> <input type = "submit" value="送信する"> } } package controllers import javax.inject._ import play.api._ import play.api.mvc._ import play.api.data._ import play.api.i18n.I18nSupport import play.api.i18n._ @
kamon { metric { # 秒間60でメトリクスを取得 # これを追加しないとCloudWatchの料金が大変なことになる tick-interval = 60 second } cloudwatch { # カスタムメトリクスで表示する名前 namespace = kamon-`<アプリ名>` # Cloudwatchのリージョン region = eu-west-1 # Cloudwatchに一度に送るデータ数？ batch-size = 20 # falseだったらCloudwatchにメトリクスを送らない？ send-metrics = true # スレッドプール数 async-threads = 5 # 取得するメトリクスを指定 subscriptions { histogram = [] min-max-counter = [] gauge = [] counter
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 問題 redis.actors.RedisClientActor - ConnectionClosed PeerClosedのWarningログが各APIのCloudWatchに出続ける（出現間隔は1分に1回） 原因 redisにtimeoutが設定されているため、timeout時間内にredisに対してread/writeの操作がなければ、redisへのコネクションを切る そのため、各APIでredisへのread/writeが頻繁に起こらない状態だと、redis側からコネクションが切られ、play-redis(scala)からPee
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く