DevLOVE現場甲子園2013行ってきた

4つのセッションが同時進行する形式のボリュームたっぷりな勉強会でした。
その4つのセッションはプログラミング、運用、マネージメント、なんかの4つジャンルに分けられてて、参加者は自由に好きなセッションを聞ける感じだった。
以下印象残ったやつ。

webデザイナとWEBエンジニアのチームワーク加速させるjava用テンプレートエンジンMixier2 のご紹介

Mixier2というjavaテンプレートエンジンの話。
WEBデザイナにerbとかjspとかhamlとかの構文を覚えさせるんですか?
デザイナにロジック入りのテンプレートをメンテさせるんですか?
それって酷じゃないですか?(意訳)
Mixier2なら、デザイナが作ったモックアップをそのまま使えます。
javaCSSセレクタを書いて操作する。※そのためソースが長くなる
jspだとテストができないけど、Mixier2を使えばテストできます。

開発背景がわからないけどエンジニアには優しくないなぁと。
テンプレート見て埋め込まれてるロジックがわからないなんてつらぽよだし、
デザイナの学習コスト抑える前提なので繰り返しのマークアップを部品化して他から呼ぶとかするのできなさそう。
いまいちイメージできないけど、デザイナがメインの現場だとありなのかな?
動的なサイトに対して、静的なものを作るデザイナが中心って破綻してるような気がしないでもない。
よいサイト作りのためにデザイナが共通ツールへ学習意欲をもっと持てばいい話かなと思った。
(そんなこと言ったらエンジニアもAIを使えという話になるかも)

こういうタイプのテンプレートエンジンがあることを知れてよかった!

JacaScript development by Agile and Scrum

2ヶ月のjs案件をアジャイルで開発した話。

  • 基本的にペアプロ
    • 開発効率が断然よい
  • 期間が短いから(?)アジャイル開発でやろう
  • 実質二人
  • イテレーション毎に見えるものをオーナーに届けるようにした
  • コーヒースクリプトを採用
  • 難読化するとテストがこけたので難読化やめた
  • ユニットテスト、ブラウザテストテスト自動化
  • ファイル保存でテスト実行する
  • クロスブラウザ辛い
  • jenkinsは途中から使ってない
  • KPT(振り替え)を行うことで開発が加速
  • 見積もりポーカーやってた
  • ベロシティの計測で進捗見える化

発表はBeforeAfter形式だったのですごく説得力があった。

(アプリの話)UIと画面遷移を設計する時に破綻しないようにするための、ひと手間

アプリ開発でデザイナ、ディレクター、エンジニアでこう仕事するといいものができるという話。
http://sssslide.com/www.slideshare.net/toooommmmmmmmy/devlove-koshien-akb20131108publish

  • WEBと同じ開発フローにしないで!
  • アプリと対話して必要なUIを考えて!アプリは画面が小さいので繊細だよ!
    • すぐにうんこができるよ!
  • 設計の段階でデザイナも入れてよ!
  • デザイナがデザインを入れることができないので、デザイナがHTMLベースやFlashでモックを作ると、お客さんやエンジニアにデザインをそのまま伝えれるよ!
    • CSSでアニメーションを簡単に使えるし、Flashだとタイムラインで動きを見れたりして、微妙な調整を目で確認できるよ!

UIの作り方

ココナラでUIはこういうふうに作ってます的な話。

  • 基本的に1画面に詰め込むと破綻する。
  • 誰のためにどんな機能を提供するか明確にしてシンプルにする。
  • サービスのユースケース、コア機能を明確にする。
  • サービスの機能やページに対して組織やラベリングをする(うろ覚え)
  • 重要なものが感覚的にわかるようにデザインする。(大きくしたり)
  • 学習曲線を意識する。毎日使うものであればぱっと見よくわからなくていい。毎日の利用で使い方を学習していくため。
    • 逆に、月1回しか使わないのであれば学習が必要ない(意訳)くらい簡単画面でなければならない。
  • UXステートメント作る。
  • ペーパープロトタイプすごくいいよ。HTMLモックだとラベル名変じゃないこれみたいな詳細についてしか意見が出てこない。
    • ペーパープロトタイプだと本質な意見が出てくる。すごく好き。
  • 『お気に入りに入れる』 => 『お気に入りに登録にする』へ変更したらお気に入り登録数がすごく増えた。社内分析の結果、利用者の考えに近いラベル名なら押されやすい。

LT WIP PRをやってみた

WIP PRかわいいよWIP PRという話。
http://sssslide.com/www.slideshare.net/asuenami/wip-pr

  • Work In Progress Pull Requestの略。
  • 作業途中でプルリクエストを送ること。未実装部分は予め記載する。
  • 設計ミスを指摘しやすい。後戻りが少ないため申し訳なさがない。言いやすい。
  • 作業進捗がわかる。

これいい!