Play Framework2.0系でセッション用のcookieにsecure属性をつける方法

application.conf
に

session.secure=true

を書きます。

http://stackoverflow.com/questions/11232304/creating-a-very-secure-login-with-cookies-and-java

まあNetty単体だと実際に動いているかわからないので、ApacheなりのSSLを使って確認するしか方法ありませんが・・・

JSONIgnoreがちょっと残念 | Play Framework2.0 ここんがんばれ！

Play Framework 2.1がリリースされましたね。
さて、そんななか、Playについて叱咤激励していきます。
Java版だとORMにEBeanを使っています。

modelsの中に各モデルを記述していきます。
ここに書いた内容がDBにも反映されます。
例えば
emailを必須項目としたい場合は

@Entity
public class User extends Model {
@Required
public String email;

みたいな感じに書くわけですね。
ちなみにこの中には

 public String getEmai() {
return email + "hoge";
    }

みたいな事もかけてしまいます。
これやると、 テンプレート側で

user.getEmail()ってやったときとuser.emailってやった時で挙動が変わってしまうので、
注意が必要です。

さて、それとは別に
Modelの中には
static関数もかけてしまいます。

public static List<User> getChildren(){
return Ebean.find(User.class)
    .where()
      .eq("parentUserId", this.userId)
    .findList();
}

みたいな感じですね。
で、これを書いた状態でユーザーのリストをJSONで取ってくるなんてした時には、全てのデータに対してstatic関数の中身も処理した上でJSONを返すため、
必要でないデータは意図的に@JsonIgnoreする必要があります。

おそらくModelの中にはstatic関数は書かなくて別の所で処理したほうがいいんでしょうが・・・。
（phpで使ってたPropelだとPeerがあったし、Slim3だとServiceがあるんだけどなあ・・・）

2.2チームをアジャイルにするためのコツ- アジャイルサムライを読んで考える

アジャイルサムライを読み進めながら、自分の業務と照らし合わせながら、落とし込み方を考えていきます。
チケット管理システム（RedmineやBacklog、tracなど）やCIツールとしてJenkinsを使っているので、その使い方と合わせながら考えて行きたいと思います。

チームをアジャイルにするためのコツ

チームをアジャイルにするためのコツは次の5つ

1. 同じ仕事場で働く
2. 積極的に深くかかわる顧客の存在
3. 自己組織化
4. 成果責任と権限委譲
5. 職能横断型チーム

最初の2つはどちらかと言うとチームの外的要因なので、大事そうなところを見ていくよ。

自己組織化

それぞれがチームの一員としてどう振る舞えば最善の成果を届けられるかを考えぬく。
役割に人を合わせるのではなく、人に合わせて役割分担を決める。
そのためのヒントとして

• 自分たちで計画を立てる。見積もりも立てる。当事者意識を持つ。
• テスト済のちゃんと動くソフトウェアを提供し続けることに心を砕く。肩書きとか役割は意味が無いよ。
• 自分から動ける人を探そう。

最良のアーキテクチャ・要求・設計は自己組織化したチームから生み出されます。

成果責任と権限委譲

自分たちで判断し、自分たちで正しいと思うことを実行出来るだけの権限を与えること。
現在実装しているソフトウェアをデモしてみせる。それだけで成果責任についてもっと自覚的に慣れる。
デモを続けていればいずれ自分たちの成果に確信を持てるようになるために必要な権限を要求し始める。

具体的には・・・

現場に責任を与える


これは現時点の自分の状況ではなかなか難しいところがある。確かに自分一人で改修して、お客さんと直接やり取りをして、といったことをしていたプロジェクトでは成果に対しての責任を果たすための意識が強く働いていたと思う。

ただプロジェクトの規模が大きくなり、メンバーも増えてメンバーを見るので手一杯になることが多く他の部署の力も借りている現在では、なかなか難しいのが現状だと思う。

それでも出来ることは残されていると思う。

せっかく開発している最新の状態をだれでも見られるようにしている（CI,継続的インテグレーションにより開発最新版の動作している環境を用意するのがプロジェクト開始時の掟になっている）のだから、せめて社内でクライアントとやり取りをしている人に対しては、現場こういった状況で、と言った報告をすることは出来るんじゃないかと考えている。

いわゆる社内営業ってやつだ。

そういえば直接お客さんとやり取りしてる場合には、お客さんに対しては「テストアップしました。確認おねがいします。」と言ったメールを送ってる。

でも、間接的になると、クライアントとやり取りをしている担当の人に対しても現状報告をしがちになってしまうので、

直接クライアントとやり取りしている人に対して、今週はこういった機能を作ったので触ってみて下さいといったメールを送るのは有効じゃないかと思う。

その担当者が実際に触ってみて、お客さんに伝えたい！と思ってもらえるように導けるかが肝になるかと思っている。

アジャイルサムライ－達人開発者への道－ 新品価格 ￥2,730から (2013/1/24 00:48時点)

2.1アジャイルなプロジェクトはどこが違うのか- アジャイルサムライを読んで考える

アジャイルサムライを読み進めながら、自分の業務と照らし合わせながら、落とし込み方を考えていきます。
チケット管理システム（RedmineやBacklog、tracなど）やCIツールとしてJenkinsを使っているので、その使い方と合わせながら考えて行きたいと思います。

アジャイルなプロジェクトはどこが違うのか

アジャイルチームに見られる特徴は次の3つ

1. 役割分担がはっきりとは分かれていない
2. 開発工程が途切れることなく続く連続的な取り組みになる
3. チームが一丸となって成果責任を果たす

役割分担がはっきりとは分かれていない

プロジェクトの成功に寄与することならなんだって協力する

具体的には・・・

開発者もテストをやる


現在は開発担当・テスト担当といったようにプロジェクトメンバーの中で役割分担を分けるのではなく、開発もテストも担当するといった体制になっています。
次のステップとしては使い勝手・画面遷移などに対しても分担しないでも出来る体制になることかと考えています。（完全フラットというよりはUI・UXなどに対して意見の言いやすい環境づくりかなと考えています）

役割分担をはっきりわけないことで、自分の作業が終わったら終わりといった意識にならないようになったり、機能や操作性・画面遷移といったものに対して疑問を抱きながら開発することがなくなり、それらがよりよい製品づくりにつながるんじゃないでしょうか。

開発工程が途切れることなく続く連続的な取り組みになる

開発工程が他の工程から独立して行われることはない

具体的には・・・

1つのチケットに対して開発してテストしてリリースして完了


設計フェーズ・開発フェーズ・テストフェーズ・リリース。そういったプロジェクトの期間ごとのまとまりはなくなり、1つの機能（1つのチケット）ごとに対して設計・開発・テスト・リリースといった取り組みがなされることとなります。
アジャイルなプロジェクトだと、1つの機能に対して開発が終わってリリースされるまで（テストがまだのまま）しばらく寝かせて醸造することはありません。

チームが一丸となって成果責任を果たす

品質に責任を持つのはチームであり、品質保証部門ではない

具体的には・・・

誰かがテストしてくれるから大丈夫だろう、ここの担当は自分じゃないから気にしないといったことをなくす


確かな品質を達成するのはチームのメンバー各々の仕事。あらゆる作業が品質保証につながっている。

これはまだ達成できていないと思う。開発だけじゃなくプロジェクトに関わっているチーム全員にこの意識が必要になってくるんだと思います。自分の担当が終わったから終わり、ではなく一つの製品としてプロジェクトを見た時に果たしてまっとうなものに仕上がっているかといった観点で見られる視点を持たなければいけません。
そうしないとちぐはぐなものが出来上がってしまう。
そういったチームを作るのがプロマネの仕事。

きっとチームメンバーにリリース完了時の報告をするとかそういったことも大事になってくるんだと思います。


この章ではアジャイルなチームに関する3つの特徴が記載されていました。
意識の問題をいかにチームのフローとして落とし込んでいくかがプロマネとして問われている部分なのかなと思います。
最初の2つはある程度仕組みでカバーできそうなので、3つ目のチームとしての成果責任も仕組みに出来るんじゃないかなとは思いますが・・・

アジャイルサムライ－達人開発者への道－ 新品価格 ￥2,730から (2013/1/24 00:48時点)

外部のライブラリ追加が楽だね| Play Framework2.0 ここがいい！

libフォルダに色々追加する
classpathに追加する

そんな時期が私にもありました。
でも今は違う！Play Frameworkではそんな事する必要ありません。

project/Build.scala
に必要な記述を追加すれば、後は勝手に取ってきてくれます。

http://www.playframework-ja.org/documentation/2.0.4/SBTDependencies

STEP1

http://mvnrepository.com/

にアクセスして、自分がほしいライブラリを検索します。
次に自分が使いたいバージョンを選びます。

STEP2

http://mvnrepository.com/artifact/net.sourceforge.nekohtml/nekohtml/1.9.17

とかで「SBT」を選びます。

libraryDependencies += "net.sourceforge.nekohtml" % "nekohtml" % "1.9.17"

STEP3

書式を整えて project/Build.scala に追記します。

val appDependencies = Seq(
  "org.apache.derby" % "derby" % "10.4.1.3",
  "net.sourceforge.nekohtml"%"nekohtml" % "1.9.17"
)

みたいな感じですね。