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時点)