らこらこブログ

唐揚げとアニメとプログラミングが大好きです

Design-JP 第1回 勉強会に行ってきたメモ

先日、 "Design-JP"という名前のデザイン勉強会に参加してきた。

design-jp.connpass.com

その名のとおりデザイナーやデザイン寄りのエンジニア向けの勉強会で、 専らGoogle App EngineやらAngularやらやってる人間からすると未知の領域だった。 今の仕事でデザインやプロトタイピングをやることはまず無いので、 "知識"を得るというよりは、"異文化交流"しようと思って、新しい考え方を求めて参加した。

以下はイベント中のメモや参考リンクの備忘録である。 発表中に"これは秘密で"と言われた部分はもちろん書いていない。


プロトタイピングツールの使い所の話

  • プロトタイピングツール
    • Prott
      • 聞いたことはあった
    • Adobe XD
      • 聞いたこともなかった
    • その他もいろいろ
  • 結論
    • 適切なタイミングで適切なツールを使うべし
    • 適切なタイミング
      • デザインが決まった後でアニメーション試すためにあとから突っ込むみたいなのは成功しない
    • 適切なツール
      • プロトタイピングにかかわる人間に合わせる
      • クライアントと共同作業があるならそれに合わせる
      • ひとつのツールにこだわって効率を落とさない
        • パーツ作りをXDでやって、Prottで組み合わせてプロトタイプを作る合わせ技
        • 若い人ほどひとつのツールを使いこなして完結させようとしがち

プロトタイピングによる効率化

  • なぜ多彩なデザインツールが出てきているのか

www.yasuhisa.com

  • ありがちなプロトタイプ失敗パターン

www.yasuhisa.com

  • プロトタイピングによくある失敗

    • プロトタイプを成果物と思ってしまう
      • 学びを得るためのツールだと思っていない
    • プロトタイプを共有する相手を見ていない
      • 自己満足な作りこみ
    • ひとつのツールに固執する
  • プロトタイプの目的

    • イデアやデザインを忠実に伝えるために本物に限りなく近いものを作ること ではない
    • 時間をかけずに目的に合わせて内容を可視化すること
  • ツールの充実
    • 動くもの(それは本当にプロトタイプなのか?)を作ることが前提っぽい風潮
    • 無駄なことをやってしまう
  • 本末転倒なプロトタイプ
    • 相手に伝わらない
    • 画面数が多くて修正に時間がかかる
    • 見せたかった部分じゃないところにツッコミ
    • 実装が無理だった
  • 本来の目的を思い出す
    • 内容の確認
      • 何を?誰と?
    • 共有
      • 誰と?
    • 実装機能の検証
      • 何を?どのレベルで?
    • フィードバックの収集
      • 誰から?何を?
    • 実際の環境に向けての最終調整
      • どんな環境?
  • Keynoteは最強のプロトタイピングツール
    • 静止画で画面のストーリーを作る
    • 実装がないので修正も早いしわかりやすい
    • お客さんが理解できるツールのほうがいい場合も多い
      • クライアントの担当者の、さらに上からOKを貰えるプロトタイプが必要

プロトタイピングのコツ

  • 忠実度を考える(作り込み過ぎない)
    • 誰に見せるか、適材適所と作業時間でどれを作るかを考える
    • 自分だけ(素早さ) < チーム(話し合い・共有) < テスト用(見た目・印象) < クライアント(見た目・完成度)
  • ツールの使い分け
    • 目的別のツール選定表 Prototyping Tools | Cooper
    • どこでも素早く仕事したいならネイティブアプリのツール
    • Keynote最強 誰もが持っている・使える・編集できる
  • 早く作り過ぎない/打ち合わせの場で作る
    • ちょっと早く出すくらいがちょうどいい
  • みんなではじめるデザイン批評
    • プロトタイプを批評してもらう、批評するタイミングが重要
    • イデアを自分の言葉で説明できるくらいに固まってから批評をもらう
  • A shorthand for designing UI flows
    • デザイン抜きで、各画面で見えているものとできることだけを書き出してつなげておくと、デザインするときに頭が整理されている
  • アニメーションは作ってしまうのもひとつの手
    • アニメーションはカーブを使って表現する
      • 直線?指数関数的?
      • とりあえずエンジニアに頼んで作ってもらうが、そのコードは 捨てる前提 で書いてもらう
  • ダミーではなくちゃんと本物の画像や文言を使うことで、コンテンツの意味を考えて幅や文字の大きさなどデザインを評価できる
  • (iOSとかAndroidとかそれぞれのプラットフォームの標準パーツを組み合わせて作ったものが、基本的にいいものになる
    • 独自のパーツはよっぽど斬新なアイデアのときだけ
  • プロトタイプのときはまずひとりで使えるもの、ソーシャルはその後
    • はじめて使う時だけの画面は忘れがち
    • インストール/登録→初回→友達がだれもいない状態のデザインが重要
  • 狩野モデル
    • 作りこんでも当たり前だと思われる部分、作りこんだら魅力になる部分
    • "当たり前品質要素"をまず大事にする

以上、ざっくりメモ。噛みくだいていけばプログラミングにも応用できる話がいくつもあったように思う。 話の内容こそ実感のないものだったが、特に難しい用語があるわけではないのでイベントは十分楽しめてよかった。 次回もぜひ参加したい。

GitHubでしりとりを始めました

何を言っているかわからないと思いますが、僕も自分が何を始めたのかいまいちわかりません。

github.com

Pull Requestでしりとりを繋いでいくだけのリポジトリを作りました。次に挙げるような意図があります。

  • GitHubOSSへのコントリビューションに不慣れな人に、遊び感覚でプルリクエストの練習をしてほしい
  • GitHubの緑を絶やしたくない人のための遊び場に。
  • 僕がいろんなプルリクエストを処理してみたい

初日からたくさんのプルリクエストやイシューをもらって、「しりとり」から「ニジェール」まで進みました。地道に続けていきましょう。


技術的な話として、せっかくGitHubを使うので、ユニットテストとCIによるしりとりの整合性チェックを自動で行おうとしています。 現在実装済みのテストは以下のものです

  • すでに使われている単語のチェック
  • 末尾の文字が「ン」か「ん」でないことのチェック
  • 発音した時に最後が「ン」にならないことのチェック

3つ目の発音のチェックは kuromoji.js を使った形態素解析によるものです。このチェックによって、「習慣」のような単語を弾くことができます。

次の段階としてしりとりがしりとりになっているか、すなわち「前の単語の最終音と次の単語の開始音が一致するか」のチェックを行おうと思っていますが、長音や促音など考慮する点がいろいろあるので慎重に実装していきたいと思ってます。 一番つらそうなのは表記ゆれ、「ユーザ」と「ユーザー」をどう処理するかという問題です。おいおい考えます。

将来的にはテストが通ってCIグリーンなPRは自動でmergeされるような仕組みができればいいなと思ってますがまだまだ先になりそうです。

Angular 2へのコントリビュート支援をしていきます

らこです。今回は所信表明という感じで。

僕はここしばらくAngular 2にコントリビュートをしていて、今まで出したプルリクエストは10数件ですが、だいたい受理されています。 なんとなくコツも掴んできたし、Angular TeamとのGitHub上でのやりとりも慣れてきました。 Angular 2はまだまだ開発途上なので修正する余地はたくさんありますし、特にドキュメンテーションの整備など人の手が必要な部分はコントリビューションを大募集しています。

そこで、日本からのAngularコミュニティからのコントリビューションをもっと増やすための取り組みを行おうと思います。 うまくいくかどうかはわかりませんが、Angularをもっとよくしたいと思っている日本人の助けになればうれしいです。

日本語でIssueを書けるようにする

コントリビューションの基本はIssueです。バグ報告や質問、機能の要望や提案など、まずはIssueでの議論から始まります。 ですが公式のリポジトリはすべて英語ですし、いきなりAngular Teamの目に留まるところに書き込むのは抵抗がある方もいるかもしれません。

そこで、私がコントリビューション用にフォークしているAngular 2のリポジトリのIssueを、日本語でIssueを書ける場として開放します。

github.com

これはwatildeさんがnpmのCLIリポジトリで始めた取り組みで、とてもいいなと思っていたので真似させてもらいました。

github.com

まだ始めたばかりでドキュメンテーションはできていないですが、いつでも気軽に書き込んでください。

コントリビューションガイドの作成

Angular 2にコントリビューションする、具体的にはパッチを作ってプルリクエストを送り、受理されてmergeされるまでの手順、フローを解説したドキュメントを作成しようと思います。

まだ取り掛かっていないのですが、6月中には出せれば良いなと思います。


僕はAngular TeamでもGooglerでもないですが、いちコントリビューターとして、Angularをよりよくするための活動をしていくつもりです。 質問や意見、なんでも https://github.com/laco0416/angular/issues に書き込んでください。

みなさんからのコントリビューションをお待ちしています!

JSer.info 5周年記念イベントに行ってきた

JSer.info 5周年記念イベントに行ってきました。

jser.info

会場のサイボウズさん、広いし綺麗だし面白い。

f:id:laco0416:20160116145709j:plain

f:id:laco0416:20160116145655j:plain

イベントの内容はazuさんが↑の記事でまとめてくれているので割愛、印象に残ったことだけ書く。

JSer.infoの仕組み

azuさんがJSer.infoがどう運用されているのかの話は感心しっぱなしだった。 つい最近ng2-infoというブログを立ち上げた身としてはフル手動なのが恥ずかしくなる。 まあ個人の片手間ブログをどこまで自動化コストかけるかというところで、JSer.infoは毎週更新という決まりがあるので時間を短縮することのメリットがでかいのだと思う。観測対象も多いし。 参考にはなるけど自分にはオーバースペックな運用だなと思った。

「仕様を理解していないコードは書けない」

mizchiさんの「React on 現場」で出てきた。 既存のレガシーなコードをリファクタしたいというときに、その仕様を理解せずに動きだけ真似ようとするのは無理だという話。 先にアプリケーション単位、画面単位、機能単位での仕様を把握したうえでやらないといかんなぁというのは今の仕事でもちょうど少し悩んでいたところだったので、 共感しつつ、乗り越えなきゃいかんなと勇気をもらった。

スティングフレームワーク「ava」の話

t_wadaさんのLTで出てきた新しいテスティングフレームワーク

github.com

アサーションにpower-assertが組み込まれていて、しかもbabelも入っているのでES6でテスト書くならすごくいいと思う。 TypeScriptから吐き出したES6でもテストできるのか後日試す。 気になったポイントはmochaのdescribeitのようなグローバル変数を使わないというところ。 実はAngular2がjasmineを組み込んでいるせいでグローバルの型定義が汚染されているため、mochaのテストを書けない問題があるのだけど、 それを解決してくれるのではという期待が持てる。ダメかもしれんが。

この他にもたくさん気になる話があった。雑談の中ではFalcorやGraphQLなどのオーケストレーション的なものをどう見るかだったり、 オフレコの話だったり、面白かった。

またJSer.infoのイベントがあったら是非参加しようと思う。

火曜アニメ#2

早くも冬アニメ2週目に突入。今週も走り抜けていくぞ

プリンス・オブ・ストライド

面白すぎる…

1話と同じく勢いがすごい。ひたすらに熱く、ひたすらにカッコイイアニメだ。 まっすぐな人間たちがまっすぐにぶつかり、まっすぐに進んでいく物語が本当に大好き。