難しそうな「情報設計」に実際にふれてみる #DevKan
2016年3月18日に開催された表題の勉強会に参加してきました。
株式会社インパス 山下 一樹さん
UXをインクリメントするのに、UIだけをカバーしてるのはダメで、カテゴライズなどの情報設計も重要。
建築のプロセスに当てはめてみると、建築資材からコンセプトを決め、導線を決め、間取りを考え、使いやすさを実現するといった整理・設計が非常に重要になる。
情報設計は地味で出来て当たり前と捉えられがちだが、ディテールに拘る意味では計測をしっかり行うこととあわせてガチで重要だと思う。
デザインやUIだけ決めて工数見積もるとかやめて、コンセプトで情報設計に徹底的こだわるべきなのではないかと思う。
山下さん、会場の楽天さん、DevLove関西スタッフの皆さま、ありがとうございました。
『FRONTEND CONFERENCE 2016』に行ってきました
2016年3月5日にあった表題のイベントに参加しました。
特に良かったと感じているのは、以下の内容です。
大型フロントエンド開発におけるTypeScriptとDDD
奥野賢太郎さん Chatwork株式会社
累計メッセージ数 10億
以前のWeb版Chatwork
- moduleなし
- jQuery
TypeScript導入の経緯
『型がないとしんどい. 』
チームが拡大
1人 -> 8人 拡大することによる特有の問題が発生
- コメント、コーディング規約
- デザイナーとの連携
- テスト
- ビルド、タスクランナー
コメントは意図を残す
「なぜそう書かざるを得なかったのか?」
ドキュメント、コーディング規約
外注さんは背景をご存知でない。だが、JSやHTML5は得意。 暗黙知であったものを共有することが必要。 主要な処理は「エントリポイント」を用意し、新しい人でもコードをたどれるように。
ex. onclickから発火して、どのようにデータを取っていくのか
『入り口、玄関をきれいににしておく』
エントリポイントを用意する考えは参考にしたいです。
dockerfileなどのように。
デザイナーさんとの連携
- SCSSを採用 変数やmixin
エンジニアがTypescriptでHTMLのテンプレートを管理
テンプレートでUIをロジカルに設計してHTMLを構成する
そこから先がデザイナーの仕事
これをちゃんと分離していることがUIの改善を行う上で重要なんだと思います。
デザイン仕様書の取り扱い
その結果として「リポジトリ内で検索しやすい!」とのこと
単体テスト
mocha + power-assert
モックを扱ったり型違反を意図的に扱ったりする ここだけTypescriptではなくES2015で記述する部分も
不安なロジックはしっかりテスト
カバレッジ100%は目指さない。 もし実装を変更するたびにテストが赤になっていたらそもそも何か問題がある。
設計変更で壊れるテストをなくせるテスト自体も負債化する
E2Eテスト
PageObjectパターンを導入する
PageObjectは自分もGebで使っていますが、非常にわかりやすくシナリオと実現方法を分離できます。
Karmaテスト
- 開発初期のテストはmochaとE2Eだけだった
- イベントハンドリング周りの検証
ちょっと試してみたい。。。
タスクランナー
- gulpを使用
- 属人性に気をつける あっという間に秘伝のタレ化
gulpファイルの差分を見やすくするように管理
検証環境の構築
検証環境へのデプロイもgulpで構築 @kyo_agoさん
- 実際のAPIレスポンスを用いて開発
build
- build時間はモチベーションに直結 browserifyをwebpackに替えたら5分の1 tslintはバックグラウンドで回すように scssだけのタスク
TypescriptとDDD
約400のソース
- Component, Service, Utility, API
- チームメンバー全員で共有するのが大変
Typescriptの型はチームメンバープロダクト全体の把握を助け、揺るぎない情報となる
大きなシステムほど「膨大な知識」が要求される -> Domain Driven
型の恩恵
一ヶ月後の自分は他人
コンパイラはJSDocと違って嘘をつかない むしろ@paramに型情報を書かない
短いコメントを付けるくらいなら型名をIDEを使うと、ショートカットやクリックでファイルを辿れる
テストの捉え方が本質にせまる -> 振る舞いそのもの
『実行時Assert』自信を持ってリファクタリング 1、2行の変更であれば型が壊れていなければ安心
DDD
- 完璧なDDDの実践は難しい 言語的な面もチーム共有の側面も
ユビキタス言語 エンジニア、デザイナー、ビジネスでの共通言語
コンテキスト
coreドメイン
- User, Message, Taskなどのドメインモデル コレクションごとのClass
Applicationドメイン BindableUser class
『3人』という文字列 {length}人ではなく{UserCounts}
TypeScriptとDDD
Viewフレームワークとの付き合い方
オワコンなんてない フレームワークの「変動に強いアーキテクチャ」の検討
フレームワークロックインへの考え方
いつでも捨てても大丈夫なように抽象化された実装にする
Applicationドメインに表示描画用のロジックを集約
Angular2化を始めている
二槽式アーキテクチャ フロントエンドフロントエンド CSSとかDom
フロントエンド・バックエンド Coreドメイン、Applicationドメイン
ScalaJSに置き換えたい
感想
『型がないとしんどい. 』とはどういうことなんだろう、と思いました。
型がある複雑な言語だと抽象化する必要があるときに複雑なステップになったりする傾向がある、と知り合いに聞いています。
ChatworkのサーバサイドはScalaと聞いているので、その影響が多いんだろうかと思いました。
型で管理するのはいいけど、特定のデザインパターンに縛られることだけは避けたい気がします。
TypeScriptを使ってIDEでの操作しやすくしたり、テストを書きやすくするってのは良さそうだけどAngularはちょっと見たいな気持ち。。。
そうしたViewフレームワークなどのJSのメインストリームの変化に対しては、抽象化している「変動に強いアーキテクチャ」で対応するというのは素晴らしいと思います。
サーバーインフラの文脈でも『Docker、Vagrant、Serverlessアーキテクチャとかに依存しすぎない』、と同じように言われています。
変動に強いエンジニアになりたいです。
不勉強なところはとにかく何とかしたい。。。
奥野さん、FRONTEND CONFERENCE 2016のスタッフの皆さま、ありがとうございました。
大事なことはすべて村上春樹の『風の歌を聴け』に学んだ
この記事は随時追記するかも。
かなりポエミーな雑記です。
『僕たちが認識しようと努めるものと、実際に認識するものの間には深い淵が横たわっている。』ってずっと昔に書かれているんだけど、素通りしてしまっている気がする。
これってつまり『認知のバイアス』だとか、『7つの習慣』でいうところの『パラダイム』の議論にも通じていると思う。
好きとか通り過ぎて何回も読み返しているけど、まだこういう気付きがある。
「インフラエンジニアの現場における仕事と文化」のDiff #DevKan
2016年2月5日のDevLove関西の表題のイベントに参加してきました。(いちおう受付スタッフも)
Developer Infrastructure in DevLove Kansai
話し手:Wantedly 坂部広大さん
www.slideshare.net
Devlove現場甲子園東日本大会での坂部さんの話がもう一度聞きたいと思って、DevLove関西でもやってもらえました。 念願かなった感じです。
syncメッセンジャー
1月からsyncというメッセンジャーアプリをローンチしたとのこと。 syncはfacebookのメッセンジャーが仕事の話が混じってしまうことを嫌う人のために、仕事領域のメッセージサービスとして特化した形を目指しているそうです。
「話を聞きに行く」「応募情報の自動入力」のボタン(OpenAPI)を作った話。
東日本大会のときはわかっていなかったのですが、相川さんというかたとタッグを組んで実現されてたのですね。 ただOpenAPIを作るというだけではなく、企画書を書いたり、使ってもらえそうなところを訪問してちゃんと営業までする、というのがインフラエンジニアとしての領域、もしくはエンジニアとしての領域を『越境』していると感じます。 そしてそれが、「Ownership」ということなのかと。 そうでもしないとWantedlyのメンバーとして生き残れない感じがあるんじゃないかなぁと邪推してしまいます。
インフラエンジニアがボトルネックにならないために
Wantedlyのサービス開発はとにかくプロトタイプを早く作り、どんどん早くリリースして検証したいという感じらしいです。 Devのエンジニアがリリース依頼して、インフラがリリースするという流れだとタスクが溜まってインフラチームがボトルネックになる。
解決する道は2通り
- インフラエンジニアを増やして人海戦術
- インフラの質を上げる
Wantedlyは後者のアプローチを取ったそうです。
『Facebookは5人で10万台のサーバーの面倒を見ている。俺たちもfacebookになろうぜ!』
『変化に強いインフラ』を目指すために
- 自動化
- セルフサービス化
を実現する。 直近の取り組みとしてCoreOSにすべてのコンテナを置き換えたとのこと。 ChefやPackerを使った構築の自動化だと、結局は「秘伝のタレ」化がなされてしまい、アプリのエンジニアがどこを変更すればいいかわからなくなるとのこと。 Dockerfileだけにしてしまえばインフラエンジニアじゃなくてもわかる。
GitHub Issueのフル活用
これはエンジニアだけでなく、ビジネスサイドの人もそうです。 そこに「Why」と「What」を必ず盛り込むため、チーム間でIssueのバトンタッチができるとのこと。 そして、PullRequestで「nginxのワーカープロセスを議論する」ということができているとのこと。
『インフラエンジニアこそ情熱的に仕事をする。』
感想ですが、どうすればこのように越境するエンジニアリングができるのか、ということを考えながらこれから先歩んでいきたいと思っています。
WhyとWhatを大切にし、必要ならばどんどん企画書を書き、営業もできるように。。。。
地道にAWS構築自動化に取り組んでいるお話し
話し手:Serverworks 永田明さん
www.slideshare.net
Serverworksのインフラエンジニアとしての構築のお仕事
サーバーワークスの提供しているのはAWSを中心として様々なサービスを組み合わせて最高のサービス基盤(インフラ)を提供すること。 そのため、セールスをしている人もセールスと言いつつ凄腕のエンジニア。 大体の構築はわかる。
もともとは、BacklogのWikiにパラメータシートをMarkdownでうめこみ、それをもとにお客様とやり取りするスタイル
そのほかAtlassian Confluenceにノウハウをためているとのこと。 でも、、「その情報あったんかい!」てなることも多いとのこと。
Wikiに記述されたパラメータをAWSのマネジメントコンソールからポチポチ転記。 その結果としてミスすることもある。
属人性が非常に高い設計フェーズだった!
自動化タスクフォース
これではあかん、ということで構築を自動化しようという運動が持ち上がったそうです。
最初にやったのはYAMLをJSON(AWS CloudFormation)にするスクリプトの作成
やってみたけれど、課題が…
CloudFormationのそもそもの課題として動かないとどこがおかしいのかわかりづらい。 AWSマネジメントコンソールは入力値のチェックもしてくれるし、元のほうがよかったのでは…
でも
そもそもAWSはプログラマブルなサービス そして我々はトップレベルのベンダー
自動化を続けるために、小さく早く試して、たくさん失敗できるようにしよう
まず、達成すべき課題として以下の2つがある * YAMLの二重管理 * スクリプトの実行環境がローカルで毎回アップデートについていかないといけない
これを解決するために
WEBアプリ化
Jenkinsによるバッチ処理実行するようにすることで、実行環境が常に最新化されスクリプトが実行する人が気にしなくてもいいようになった。
そして、Jsonだけじゃなく、Markdownを生成。
生成されるのは、属人的に作られたものじゃなく、フルスペックのパラメータ表。
これによって、ひな形のYAMLができて、無難な設計が共有されるように。
いわば『秘伝のタレ』
自動構築化後の課題
自動で構築しても確認は必要。 そして、確認は目視。 CloudFormationは動かないとどこがおかしいのかわかりづらい問題。 逆に動くと快感らしい。。。
確認のためにRSpecをもととしたWebアプリをつくる、、、ということを目指しているそう。
自動テストの文化を作るところから再スタート
感想ですが、今までやってきたことがアンチパターンになる場合もある、という言葉に深く共感します。 そのために、改善と軌道修正をやめたら負けということも。
自分も今の現場で自動化の取り組みをしていますが、今まで築きあげてきたものがレガシーになったときに、捨てたり式年遷宮的にちゃんと切り替えができるように考えていかなければいけないんじゃないかなーと思いました。
全体の感想
スタートアップとクラウドのトップベンダーという2つの現場の文化の違いはとても感じられたし、自分の現場とも比較することができ、とてもよかった!
坂部さん、永田さん、会場のMOテックスさん、参加してくれた皆さま、本当にありがとうございました。
Microsoft の DevOps ハッカソンに参加しました #DEVOPSJP
2016年1月23, 24日に開催された表題のハッカソンに参加してきました。
ハッカソンへの参加は初めてでした!楽しかった!
DevOpsとは
なんぞ、ということを牛尾さんと小塚さんがプレゼンしてくれました。
アジャイルマニフェストと違って、はっきりと明文化されたものがないため、言ってることが定まらなかったという変遷があるとのこと。
ただ、ツールをさすのではないので、特定のツールにたいして「このツールはDevOps対応ツールですよ」と売り込んでくる場合は注意が必要。
10 deploy / day
開発者とインフラ技術者が協力し、ソフトウェアライフサイクルやビジネス価値の創出を改善する活動
草の根から始まって、途中からトップダウンに
開発部門と運用部門の壁
開発部門
「リリース終わった やったー」
運用部門の気持ち
「上からなんか使えるのかわからないもの降ってきた」
いがみあったりするようにならないように。。。
PO , dev, qa, opsが1チーム
DevOps 1番最初にやること Dev側 = テスト駆動開発
システムテストをがっつり自動化
50時間以上のシステムテスト
Jenkinsを利用して、並列に2時間
※お金を扱うのでトランザクションミスったら終わる
クックパッド
単体テスト以上は必要ない
間違っていたら8秒で戻せるようにしている
DevOps 1番最初にやること Ops側 = Infrastructure as Code
Visual Studio Team services 便利そうです。
カンバン機能(its機能)とビルド機能などがつながっている。
gradle, xcode, gulpなどのビルドもできる。
ハッカソン実践 『Dockerでオートスケールを実現する』チーム
目指すのはサービスの負荷が高くなった時に自動的にコンテナが立ち上がり、ノードに追加されて負荷を分散するシステム
なんか、MS寺田さんに見せてもらったデモをとにかく参考にしたという感じです。
パクリかもしれない。
1日目はAzureの操作に戸惑いすぎてほぼ何もできず、みたいなかんじでした。
Jenkins入りのイメージを起動したのですが、そいつがDockerコンテナの中で動いていたのでDockerコンテナの外側からビルドなどのコマンドをすることはできず。。
2日目にやったことはタスクボードに張り付けてログを取ってました。
が、画像が荒すぎて見えない
チームで実現したDoneは以下のような感じ
足回り
- Visual Studio Team Services上にソースコードとDockerfile保存用のGitリポジトリを作る
-
Wordpressを動かすDockerfileを試作
Jenkinsが動かない問題
Jenkinsジョブ設定
- SCMポーリングでDockerfileの変化をフック
- dockerコンテナをビルドし、イメージをDockerHubにプッシュする(Jenkinsのプラグイン使用)
CloudBees Docker Build and Publish plugin - Jenkins - Jenkins Wiki
Tutumまわり
- webhookでDockerHubのイメージの変更を検知
- Azure上にDockerコンテナ作成、起動
- Tutum上でコンテナを増やす
ビルドパイプライン全体
- Dockerfileをgit pushするだけでAzure上にコンテナが立ち上がる
ただし、Wordpressは試作のDockerfileでは動かなかったです。
というわけで
1コンテナでWordpressを動かす
- bug: コンテナ上でリンクが作成できない(権限の問題)
- 上記bugfix: tarボールの解凍時に適切な場所にcpしてしまう
update for boot2docker aufs issue · CentOS/CentOS-Dockerfiles@d2b7b93 · GitHub
- bug: mysqld, httpdデーモンプロセスを動かしたコンテナが即終了する
- bugfix: tail -f /dev/nullを最後に実行する
複数コンテナでWordpressを動かす
- tutumでオートスケールできないか調査
- haproxyで2コンテナにロードバランス
といったところでタイムアウトです。
肝心のオートスケールは実現できませんでしたが自分一人ではできないこともチームで挑戦することでいろいろ実現できました。
DevとOpsという垣根はなかったです。Opsしかやってない感じはありましたが!
自分はGitまわりとWordpressを1コンテナで動かすというところに注力していたので、Tutumの操作はチームメンバーにやってもらっていましたが、非常に便利だと感じました。
発表自体はちょっと残念な感じになっちゃったのですが、個人的にはDockerを実際に使い、tutumにも関われて非常に満足でした。
ハッカソンというイベント自体もそんなにパーフェクトにやろうと構えず、失敗してもいいという気持ちで参加してもよいことが分かったので行ってよかったです。
声かけてくれた自動化コーチに感謝です。
牛尾さん、寺田さん、小塚さんをはじめとしたスタッフの皆さま、チームのメンバーの方、そのほか参加者の皆さま、本当にありがとうございました。
素晴らしいイベントでした。
「エンジニアが幸せな人生を過ごすための学び方、関わり方、あり方」の再演 #DevKan
2016年1月22日に開催された表題の勉強会に参加してきました。
エンジニアが幸せな人生を過ごすための学び方、関わり方、あり方。
<話し手>久保 明(@HappyLuckyAkira)さん
やっぱりプレゼンが面白い!
自分のプレゼンと比べるべくもありません。
学び方についてですが、とくに勉強会に参加するときに無理にアウトプットを出そうとか、会社で参加した勉強会の内容について共有しようとか、そういう構えはしなくてもいいんじゃないかというふうにおっしゃってました。
まったくその通りだと思います。
とりあえず聞くだけ聞いてみて面白くて楽しかったらオッケーだと思います。
アウトプット出すにしても徐々に徐々に、段階的にでいいと思います。
派生開発についての勉強会については質問も上がっていたけど、自分も気になります。
開発は変化を前提としているほうがありがたいですけど、そうではない場合どうしたらいいんだろう。
あり方については深い、、、、とおもいます。
時々自分のエンジニアとしてのあり方間違っているのではないかとか、何のために生きているんだろうか思う次第です。
そういうときはステレオポニーの『星屑カンテラ』を聞いています(どうでもいい)。
ワークについて
ペットボトルからコップに水を入れる動作の手順を説明するチェックリストをつくる、というのをやりました。
自分は15ステップでしたが、お手本は27ステップ。
以下に、「これくらいはわかるだろう」という思い込みで省略されているのかということが分かりました。
いろんなことを省略して阿吽の呼吸のハイコンテキストでコミュニケーションができるのが理想だと思いますが、それを目指すためには差をちゃんと埋めていく努力が大切かなあとおもいます。
そのほか質問でありましたが、バグとか起きても犯人捜しでネガティブにならずに、このタイミングで見つけてくれてありがとうというふうに思いましょうとのこと。
場の空気を換えるのは難しいそうですが、そういう認知のバイアスを変えていくのも継続してやることで自然とチームの雰囲気改善につながるんじゃないかと思いました。
久保さん、会場のロックオンさん、スタッフの皆さまありがとうございました。
『それぞれの現場で実践した【自動化】の話』に参加・発表してきました #DevKan
2016年1月18日にあった表題の勉強会に参加・発表してきました。
自動化とは何か?ゲーム開発において実践した自動化とは?
<話し手>森田 和則(@pg_morita)さん
DevLove現場甲子園西日本大会の再演です。
2度目になりますが「ベヨネッタ2のゲーム開発のデバッグにおいてコントローラの操作を自動化する」というブログ記事の執筆者です。
バグチェック作業の自動化について
自動化の意義はクリエイティブなことに集中したいから。
そしてなるべくコードを書くという作業を減らしたいから、というのもあるそうです。
ブログ記事の動画を見せてもらいましたが本当に素晴らしいです。
ゲームの負荷などのパフォーマンスを表示する処理ではjQueryを使いこなしてすごく見やすいビューを作っています。
意外なことにjQueryプラグインを使うのがかなり好きなのだとか。
クリエイターさんがVFXなどを変更して結果としてパフォーマンスが落ちたときに、一発でわかるという感じです。
自分はまだまだプロダクトのため、開発で本当にやりたいことに集中するための自動化というのができていないため見習っていきたいです。
特にテスト系をもっとしっかりやりたい。きちんとしたXPやりたい。
森田さんありがとうございました!
ECサービスフロントエンドエンジニアがリリース改善やブラウザ自動テストに取り組んでみた話
発表したスライドは以下になります。
初めてなのもあり、つたない発表で申し訳ありません。
(※ スライド中の、「第2部 完」の画像は手書きです)
会場のサイバーエージェントさん、お聞きくださった方、スタッフの皆さま、本当にありがとうございました。