【勉強会メモ】FRONTEND CONFERENCE 2018
毎年恒例のフロントエンド製作者向けイベントに行ってきました。近年、Webブラウザの進化に伴いフロントエンド技術のカバーする範囲はどんどん拡大しています。PWAやWASMのような他の技術領域にも踏み込んだ技術の話、大規模スクラムの事例などからもその状況をうかがい知ることができ、フロントエンド技術の拡大を改めて実感することができました。最後のセッションで後藤さんが次のように仰っていました。
バックエンド経験の上にフロントを積むのではなく、ニューゲーム感覚で、新しい気持ちで挑めば
分業を前提としたフロントエンドとバックエンドというコンテキストはもはや手法の1つでしかなく、Webに携わる者としてはより良い技術選択をしていくための手法として向き合うべきだと感じました。
しっかりフロントエンドに向き合って強くてニューゲームをPlayしていかねばと思いました。 #frontkansai
— radiocat (@radiocatz) 2018年11月24日
WebMusicで何ができるか
okunokentaroさん
※途中から参加しました。
- グラフィカルに確認してコードに落とし込む
- MIDIならブラウザを超えて連携できる
CSSで扱う音声の概念
createMediaElementSource()を使うことで<audio>と連携- Selectors Level 4 擬似クラス
- Resource State Pseudos
:playing,:paused
- Time-dimensional Pseudo-classes
:current,:past,:future
- Resource State Pseudos
Web Musicのこれから
- Web Audio APIによるゲームやWebXRにおけるBGMや効果音の表現WebRTCでの音声通信
- WebMIDI APIによる多彩な機器制御、遠隔操作、演奏の同期
- 関連サービスやサードパーティAPIでさらにおもしろくなる
Chrome Dev Summit Recap
宇都宮佑亮さん
Performance
- 今年のセッションの全体的なテーマ
- 去年はPWAが多かった
Perf Budgets
- Webサイトは重い
- Image,JSのロードに時間がかかっている
- 各環境に応じたBudgetを用意することを推奨
Split your bundle
- JSで何ができるかというとCode-Splitting
- 各ページで使えるものだけをロードさせる
- RollupやWebpackではDynamic ImportされるモジュールをCodeSplitしてくれる
- linkで
rel="preload"すれば先行取得
ユニクロカナダのモバイル版サイトの事例
- 必要なものだけをbundleに入れる
- Preact（React.jsの軽量版）を使って成果を出している
Perf Budgetやスピードに関するツール
- PSIが新しくなりLighthouseが組み込まれた
- Web開発のベストプラクティスやAuditモニタリングを網羅的に行う
LighthouseがCIに組み込みやすくなった
bundlesize
画像・動画に関しても様々なベストプラクティス
- Imagemin
- Lazy Load Images
- AV1
Native Lazy Loading
宣言的にLazyloadする・しないなどが選択可能
実際問題やるべきことはたくさん
- 最近のマルチコア環境でシングルスレッドでは恩恵を受けられない
- Workerをどのように活用できるかを考える
- Paint Workletを利用したOff main Thread
WebAssembly Threads
- WASMも複数Workerで効率的にメモリを共有するThreadsのOriginTrialを開始
Workbox
- Service WorkerはWorkbox
- workbox streamsを利用することでそれぞれを同時並行でストリーミング
squoosh.app
- 画像をWebで使ううえでのベストプラクティスをプロダクト
未来の話
- アーリーステージの機能
Feature Policy
- Webサイトにポリシーをつける
- レポーティングのみに切り替えることも可能
Layered API
- ハイレベルなAPI
- スクロールでもNativeではスクロールAPIが用意されている
- WebはFWがライブラリやコンポーネントを提供しているがそのぶん重くなる
- ブラウザが標準でハイレベルなAPIを提供する
<virtual-scroll>
Web Packaging
- Webのリソースを文字通りパッケージングする
- Signed Exchange
- 署名
- Bundled Exchage
- 集合
- AMPのドキュメント
- 署名済のドキュメントは取得元に関係なく署名もとのオリジンのものとして表示
- Webで画面遷移が遅い
- Portalを使うと早くなる
※Chrome Dev Summitの参考情報
10名超えのスクラムでフロントエンド開発する現場の声
上原晃人さん
10名以上の場合はコミュニケーションコストが増えるためチームを分割する
3社合同チーム
- PO：2
- SM：1
- サーバサイド：6 -フロント：12
- デザイナー：4
- テストエンジニア：4〜
開発しているものは 2つのECサイト
開発の流れ
- 案件発生
- POからの依頼
- 主担当を決める
- 仕様検討
- デザイナー
- 画面遷移、UI、文言
- フロントエンドエンジニア
- データの取得方法やUIの実現性検討
- 相互に相談して実現性を検討する
- デザイナー
- デザインレビュー
- メインデザイナーが検討したデザインをチーム全員でレビュー
- チームのメンバーが共通認識を持てる
- 実装・テスト設計
- 細かい単位でタスクを作ってエンジニアが分担して進める
- GitlabのMRでレビュー
- テスト設計
- テストエンジニアから各エンジニアに質問して設計
- テスト実行
- デバッグ・保留検討
- 開発してみたがリリースを保留することもある
- リリース
プロジェクトの流れ
- 実際は複数の案件が並行で走る
- タイムボックスにわけて管理
- 案件別にチームがフレキシブルに生まれる
- 管理に使うツール
- Jira,Confluence,Sketch
スクラムイベント
- ふりかえり
- KPTでふりかえり、改善実施
課題
- 意味が広すぎるタスク
- 何をしたらいいかよくわからない
- タスクには明確な完了条件を設定
- 開発完了済機能の確認
- 実装を確認する際に確認が難しい画面がある
- デバッグ機能を用意
- デイリースクラムの長期化
- 人数が増えるにあたり時間が長くなる
- 案件別の報告
それぞれに得意領域を持つフロントエンドエンジニア
- クリエイティブ寄り
- デザインの糸を理解してHTML/CSS/JSで組み上げられる
- エンジニアリング寄り
- アプリケーションとして最適に構築
社内の推奨技術・ツール
- Vue
- React
- Angular
- RIOT-Riotx
- jQuery
- プロトタイプなどをさっと作るときに便利
どんな人がフロントエンドエンジニア？
- 様々なバックボーン
- 3つの気質
- 楽したい
- Greasemonkyやブックマークレット
- 便利にしたい
- 社内環境もフロントエンド技術で便利にする
- すぐ試してみたい
- 新しいものが出てきたらとりあえず試してみる
- 楽したい
この気質で社内の業務効率化を解消するためにスマートシェアボードのプロトタイプを作った
業務システムでこそ使えるPWA
中津川篤司さん
PWAで必須ではない
- アプリ化
- プッシュ通知
- Chache API使用
必要なこと
- 導入しやすいものから徐々に
- 最良なものから取り入れる
- ユーザー体験向上
技術的なアプローチ
- レスポンシブWebデザイン/HTTPS
- ストレージ
- WebAuthn
- Service Worker
- マニュフェスト
ダイアログ・ヘル
- マニュフェストは必須ではない
- スマホにあふれるダイアログ・バナー
- 無意識に無視・拒否
- 現在はアドレスバーにアプリを知らせるアイコンが出る案を試している
- 気づきにくい
- ボタンを押してアプリをインストールしてもらうのは最優先ではない
速度改善
- 旅行中500M/日
- 切れると速度制限
- jQueryの読み込みでエラー
- よく使うファイルだけでもキャッシュすれば高速化できる
- いきなり100%ではなく10%改善から始める
B2B Web App
- 黎明期
- 利用技術
- Cordovaの利用
- アプリ化することで審査が発生
- JavaScript部分では落ちないがプラグイン（ネイティブコード）部分で落ちることがある
- 速度が…（最近は改善）
- メリット
- 生産現場に
- ネットワークがあればどこでもアクセス
- デメリット
- OSの進化に追従できない
- 審査で落ちる
- アプリの更新が反映されない（アップデートしてくれない）
PWAの登場
- 審査なし
- 配布の手間なし
- アップデートの自動適用
- HTML5 APIで大抵の目的が果たせるようになってきた
- JavaScriptが高速化し実用化レベルになった
- メモリが大きくなってWebブラウザが落ちなくなった
- 遅くなっても落ちないので業務アプリにとって最適
業務システムのPWAメリット
- 利用者が限定される
- 定常的な利用が期待できる
- 高度なUIは求められない
- Webブラウザ上で確実に動作する
- オフライン化、表示の高速化
- 生産性向上
- 標準技術の採用による普遍性
- 5〜10年以上の保守・運用
- Web技術の採用
- 技術者のアサインがしやすい
Technology
ServiceWorker
- ワーカースレットで動作するのでバックグラウンド処理ができる
CACHE API
- SW内で動作するキャッシュシステム
- キャシュパターン workbox
Webプッシュ通知
IndexedDB
- Cookie
- localStorage
- IndexedDB
WebAssembly
- コードの暗号化
- キーの隠蔽化
- Webアプリケーションの高速化
- RustもいいけどGoがオススメ
WebAuthn
- ハードウェアキーを使った認証
- Krypton
マニュフェストファイル
- manifest.jsonでアプリ名やアイコンを設定
Tips
- キャッシュは注意
- 有効期限なし
- 強力なキャッシュ
- 消えなくなる
- Chrome for Androidでの設定
- Lighthouseの利用
- オフラインを再現
- Chrome Dev Tool
- デスクトップでも使う
- デスクトップアプリのように使える
- ネットワーク対応
- navigator.onLineで判定
- window.addEventListener 'online' 'offline'でイベント発火
PWAハンズオン資料
Rust+WebAssemblyで広がるWebの世界
尾上洋介さん
フリーランチの終焉
- フロントエンド開発への要求は高まる
- ハードウェア、JSエンジンの性能向上の恩恵を知らないうちに受けていた時代は終わるかも？
- フロントエンドエンジニアがJSプログラムの速度に負う責任が増す
- asm.jsを効果的につかえばこれまでWebでできなかった種類のアプリケーションが実現できる
- WebAssemblyによる進化に期待
- RustでWebの部品を作れる未来はそう遠くないかもしれない
- 1.0 has shipped in 4 majer browser engines
- バイナリーフォーマット言語
- 他言語からコンパイルして生成するのが一般的
- C/C++,Rust,Go,AssemblyScript
- 30以上の言語が取り組んでいる
- ネイティブ処理とWebのギャップを埋める
- メリット
- 高速
- 低レイヤーの操作
- 過去の資産活用
- デメリット
- 安全性
- 周辺ツールの不在
- 言語と一体化した周辺ツールが少ない
Rust
- 型安全
- TypeScriptよりも強力な型システム
- デフォルトで値が書き換えられない
- メタプログラミング
- パフォーマンス
- WebAssemblyをオフィシャルにサポート
WebAssemblyの出力
- wasm32-unknown-emscripten
- Emscriptenのライブラリを利用できる
- wasm32-unknown-unknown
- ランタイムなし
Setup
- rustupの導入
- rustup target add wasm32-unkonwn-unknown
ビルド
- cargo newでプロジェクト作成
- Cargo.tomlに設定ファイル
- create-type=["cdylib"] でC言語から呼び出せる種類
- cargo build
WebAssembly JS API
- .wasmフアイルを読み込んでWebAssembly.instantiateにわたす
- ArrayBufferを通じた低レイヤーな操作
- Number、TypedArrayを扱う関数のみ
wasm-bindgen
- RustオブジェクトとJSオブジェクトの相互変換レイヤーを定義して自動生成
- js-sys,web-sysによるJS、ブラウザAPIの操作
- webpackで予感時に読み込み可能
Introduction - The `wasm-bindgen` Guide
JSクラスの生成
- Rustの構造体、traitからJSクラスを生成
wasm-pack
- cargoへのtarget追加、ビルドの実行、npmパッケージの生成、配布までを自動化
Drawing Mandelbrot Set with Rust and WebAssembly
WwebAssemblyの今後
- Post MVP Features
- ツールのサポートの充実
Webのパフォーマンスを追求する意味
- コンピューターの性能向上＆理論の発展
- よりパフォーマンス要求のきついものがWASM
- パフォーマンス追求がWebの可能性を広げる
フロントエンドで作る理由
後藤知宏さん
フロントできない理由
- バックエンド脳
- SPA案件がない
- まだ時期じゃない
まだ時期じゃない?
- フロントエンドはどんどん簡単になっている
- バックエンドでもできるから…は言い訳にならない
Vue.js
- HTML/JSベースでシンプルに導入可能
- とっつきやすさ、学びやすさは最高レベル
- 極論、JSできなくてもVue.jsできる
Nuxt.js
- SPA構築がここまで簡単になった
- Vue.jsの使いやすさはそのまま
vue-cli
- コマンドで簡単にプロジェクトの初期セットアップが可能
- 複雑なWebpack設定を自動で構築
Hosting
SPAはより身近に簡単に
- 数年前と比べるとフロント制作の地盤は大きく安定
技術選定の基準
- 実務で使える（安定性）
- みんなが使える（学習コスト）
- 効率化できる（メリット）
わかりやすさは正義
- 安定性と学習コストをクリアしたうえでどういうメリットを考えるかが重要
Why SPA?
SPA制作 - フロント設計
- ページ遷移が容易になる
- 適切なナビゲーションを添えてシンプルな画面デザインに
- E2Eは最初から無理に頑張らなくていい
- SPAにはSPAの作り方、慣れの問題
SPA制作 - API設計
- 無理に抽象化的なAPIを作成する必要はない
- APIの受け入れテストは簡単につくれる
- バックエンドをAPI化することで品質を担保
- 守りたいデータ資産の安全性がフロントと分離
- より挑戦的なフロント改善を促進
変わる制作プロセス
- SPAにはSPAの作り方がある
これまでの制作フロー
- 大きな複数機能を一度に進めるのはとても大変
SPA時代の制作フロー
- 機能を分割してスケジュール化する
- 1機能ごとにリリース
- リリース＝外部リリースとは限らない
SPAの案件は「作る」
- よりよい制作のためにSPA
怖くないフロントエンド
- バックエンドでもできるの概念を捨ててフロントでつくるとどうなる？への挑戦
- 作り方の変化を制作フロー全体に反映させていく
強くてニューゲーム
- バックエンド経験の上にフロントエンドを積み上げるのではない
- ニューゲーム感覚で新しい気持ちで挑む
- フロントに親しむ
- フロントを当たり前に
※参考情報
【読書メモ】エンジニアのためのマネジメントキャリアパス
エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド
- 作者: Camille Fournier,及川卓也(まえがき),武舎広幸,武舎るみ
- 出版社/メーカー: オライリージャパン
- 発売日: 2018/09/26
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
巷でも話題になっていますが個人的にもちょうどこういう本を読みたかったタイミングでもあったため、久々に新刊を読みました（いつもはある程度時間を置いて周りの反応を見てから読むことが多い）。全体の感想として、エンジニア組織に属する人みんなに読んでほしい本です。特に、マネジメントを目指さないエンジニアや、コードを書かずにエンジニア組織のマネジメントに就く人にも読んでほしいと思いました。その理由も含めて、まずは個人的に印象に残っているポイントついて書いておきます。
オススメのポイント
エンジニア視点で書かれたマネジメント論
マネジメントの良書は世の中にたくさんあります。これらの本は広く一般的に支持されており、実際にマネジメントを目指す際には読むべきなんでしょうが、古典的な本が多いので日進月歩で進化する我々の業界に置き換えてイメージしながら読み進めるのはなかなか骨が折れる作業です。また、これらの本で書かれている例え話はたいてい企画や営業目線で語られているので、エンジニア視点でいったん自分の仕事に置き換えてイメージし直すという作業が発生します。これもまた読むハードルを上げている要因と言えるかもしれません。
エンジニア視点で書かれていることで我々の仕事と関連づけたイメージがしやすく、スムーズに読み進めることができるます。まえがきで及川さんが「エンジニアリングマネジメントはソフトウェア開発と似たところがあります」と書いていますが、この点についても他のマネジメントの本を読むよりもこの本のほうがイメージしやすいと思います。
もちろん、本格的にマネジメントを目指すと決めたならその次はドラッカー本なども読み進めるべきと思いますが、そこに向かうまでのハードルを下げてくれる本とも言えます。
![マネジメント[エッセンシャル版] - 基本と原則](https://images-fe.ssl-images-amazon.com/images/I/41AY8WEF74L._SL160_.jpg "マネジメント[エッセンシャル版] - 基本と原則")
- 作者: ピーター・F・ドラッカー,上田惇生
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2001/12/14
- メディア: 単行本
- 購入: 210人 クリック: 8,094回
- この商品を含むブログ (433件) を見る
マネジメントではなくマネジメントキャリアパスが主題
まえがきに書かれているように「エンジニアはマネジメントに関わることを毛嫌いする傾向」があります。せっかく技術スキルを磨いてもマネジメント職に就いたらその経験はあまり活かせないという事例もよく聞きます。しかし、組織においてエンジニアリングとマネジメントは両輪がうまく廻らなければ企業が継続的に事業を発展させることは難しいと私は考えています。継続的に事業を発展させられなければエンジニアの活躍の場も減っていくでしょう。組織の中でエンジニアがマネジメントに関わっていくことが健全に認知されないと、このような負のスパイラルに陥ってしまうと思うのです。そのためにはこれからキャリアを積み上げていくエンジニアにとって、この本のようにマネジメントキャリアパスが明示されていることは非常に価値の高いことだと思いました。
「複数チームの管理」の章に以下のような記述があります。
最低でも1種類のプログラミング言語を自在に使いこなせるようになっていないと、コード書きの作業からすっかり「足を洗ってしまう」ことの危険ははるかに大きくなります
これはこのポジションに就くまでに逆算して取り組むべき技術スキル習得のヒントにもなります。マネジメントキャリアパスを主題として読み進めることで、エンジニアリングとマネジメントを両立させてキャリアパスを歩むためのヒントが得られると思います。
マネジメントを目指さない人のキャリアパスの参考にもなる
一方で、一般的にはマネジメントから距離を置いたエンジニアのキャリアパスも明確に定義されていないケースが多いため、エンジニアがマネジメントから距離を取るとキャリアパスの迷子のになってしまう事例が起こりがちです。ある程度の規模以上の企業に所属しているなら、いかに技術スキルの高いエンジニアでもそれなりに意義のあるポジションに就いていなければ仕事を任される機会は得られません。私がマネジメントを目指さないエンジニアにも読んでほしいと思ったのはこの部分で、マネジメントを任されるにしても任されないにしても、組織の中で価値ある仕事の機会を得ようとするならマネジメントサイドと折り合いをつけながら仕事をするのは必須だと思うからです。マネジメントに関わらないにしても他人のキャリアパスを妨害するようなエンジニアが組織の中で価値ある仕事の機会を得られるとは考えにくいため、マネジメントキャリアパスを知っておいて損はないというわけです。マネジメントキャリアパスとは違う自分なりのエンジニアキャリアパスを模索するならマネジメントキャリアパスを知っておくことは無意味ではないと思います。
テックリードの章の「決断の時──技術職を貫くか、管理職への道を選 ぶか」の節に以下の項があります。
- 私の想像していた 「(部下をもたない)シニアエンジニアとしての日々」
- 現実の 「(部下をもたない)シニアエンジニアとしての日々」
- 私の想像していた 「管理職としての日々」
- 現実の 「管理職としての日々」
わりと生々しい現実を突きつけられる記述もありますが、マネジメントから距離を置いたキャリアパスをイメージするうえでのヒントにもなると感じました。
ボス・マネジメントの参考になる
ボス・マネジメントはマネジメントキャリアパスを歩むうえで必須ともいえるスキルです。リーダーシップの古典的名著であるジョン・P・コッターの「リーダーシップ論」でも「上司をマネジメントする」という章で述べられています。
- 作者: ジョン・Ｐ・コッター,DIAMOND ハーバード・ビジネス・レビュー編集部,黒田由貴子,有賀裕子
- 出版社/メーカー: ダイヤモンド社
- 発売日: 2012/03/09
- メディア: 単行本
- この商品を含むブログを見る
自分の職位だけでなくさらに上位の職位まで読み進めることで、自分の上司やその先の経営幹部に至るまでの職位の人がどのような課題を抱えて行動しているかをエンジニアの視点で知ることができます。自分に馴染みのない職位について書かれている章もそのような視点で読み進めればボス・マネジメントのスキルを磨くヒントにもなるでしょう。
読み進めるための補足情報
「まえがき」で及川さんが少し補足されていますが、日本では馴染みの薄い言葉がいくつか出てきます。これらは事前に意味を理解してから読み進めたほうが理解が深まると思います。
ジョブディスクリプション
「職務記述書」のことです。
具体的な職務内容や職務の目的、目標、責任、権限の範囲のほかに、そのポジションとかかわりをもつ社内外の関係先、必要とされる知識や技術、資格、経験、学歴など
採用時だけでなく社員の評価や昇進時にも基準として使われるようです。
キャリアラダー
ラダーとは「はしご」のことです。日本語だと「出世の階段」と言う言葉もありますが、少しニュアンスは違っていてもう少しきっちり体系化されたしくみを指します。
仕事を難易度や賃金に応じて複数の職階に細分化。それぞれの職務内容や必要なスキルを明確にし、下位職から上位職へ、はしごを昇るように着実に移行できるキャリア向上の道筋と、そのための能力開発の機会を提供するしくみ
キャリアパスの概要
読むべきポイントは前述の通りですが、それぞれのポジションで求められる役割やその意義について、概要をまとめておきます。具体的なマネジメントの事例やコツが知りたい場合は、本書を読み進めるのが良いでしょう。
マネジメントの基本
「上司に何を求めるか」と「管理のされ方」について。
『できる上司』に何を期待しますか？」と訊かれたら、答えられますか。
マネジメントの基本はマネジメントされる立場でマネジメントを認識する事から始まるという主旨。
メンタリング
メンティーとメンターの双方にとっての好機
双方にとって意義があるのは大まかに次の3つ
- 相手を通して会社や組織、人間関係を知る
- コミュニケーション能力を高める機会
- 未来への人脈づくり
テックリード
専門スキルとリーダーシップとが共に求められる役割
テックリードの主な役割は次の3つ
- システムアーキテクトとビジネスアナリスト
- プロジェクトランナー
- ソフトウェア開発者兼チームリーダー
人の管理
人の管理で求められる主な仕事は次の4つ
- 直属の部下との関係の構築
- 定期的な1対1のミーティング
- キャリアアップや作業の進捗状況、改善領域、功績の推奨などのフィードバック
- 各メンバーの研鑽を要する領域の見極めと、その領域の能力強化
チームの管理
作者によれば「チーム全体の責任を負う管理者」は「エンジニアリングリード」である。
人的管理以外に焦点を当てるべき側面
- ITスキルの維持
- 機能不全に陥ったチームの「デバッグ」
- チームの面々の「盾」になる
- チームの意思決定を主導する
複数チームの管理
この職位は大抵「技術部長」
このレベルの職位で必要な側面
- 時間の管理
- 意思決定の委任
- 開発チームの健全性を見極める
複数管理者の管理
期待される職務内容は、「複数のチーム を率いる管理者」の場合と大して変わらないが、以下の点が異なる。
各チームの専門分野が拡がる上に、プロジェクトの件数も部下の人数も自分独りでは到底管理不可能なレベルにまで増える
部署全体を管理するうえで外せないコツ
経営幹部
経営幹部の日々の職務内容は会社によって大きく異なる。
エンジニアである我々はテクノロジーの専門家ならではの責任 -- 絶えず変化を続けるテクノロジーの世界でキャリアを積んできた者ならではの責任を-- 担っているのです。
CTO、VP、技術本部長、統括者など呼び方は様々だが、とにかく技術部門の頂点に立ったらこの4種類の職務を果たしていく。
- 情報の収集・共有
- 注意喚起
- 意思決定
- ロールモデル
幹部の役割の一部
- 研究開発
- 技術戦略・ビジョナリー
- 組織化
- 執行
- 技術部門の対外的な「顔」
- 社内の技術インフラとその運用
- 事業化
トゥルー・ノース⇒管理者が職務を果たす上で外してはならない勘所
このような指導者になりたい人は、自信をもって迅速な意思決定を行えるよう、ぜひともキャリアの初期の段階から意識的に時間を割いて「技術者の勘」 を磨く努力を重ねなければなりません
文化の構築
文化の構築は技術系の経営幹部になると担う職責のひとつ。
文化は、拠り所となる重要なインフラの場合と同様に、チームが成長、発展していく過程で配慮を欠いてはならない要素
次の4つを判断基準にして自分の役割を見極める
- 社員の数
- 創業からの年数
- 既存のITインフラの規模
- リスク許容度
参考ブログ
他の人の感想を読むことで新たな気づきを得ることができるので合わせて読むと良さそうです。
「エンジニアのためのマネジメントキャリアパス」から学んだことをまとめてみた。 – iida – Medium
マネジメントに興味がなくても騙されたと思って『エンジニアのためのマネジメントキャリアパス』を読んでくれ - dskst's diary
「エンジニアのためのマネジメントキャリアパス ―テックリードからＣＴＯまでマネジメントスキル向上ガイド」を読んだ - A1 Blog
【勉強会メモ】Mobile Act OSAKA #7
今回もXamarinから仮想通貨、CI/CDまで様々な題材でモバイルアプリに関する知見を得ることができる場だったと思います。そら案内のバックエンドも含めた全体構成の貴重な事例も参考になります（10周年おめでとうございます）。クリーンアーキテクチャは10分間で全て理解するのは難しいですが本を読むモチベーションになる内容でした。懇親会ではいつものように美味しいビールを頂きました。
usami-k「Xamarin を使った iOS アプリ開発の現場から」
IDE & storyboard
- 現在も進化
- event
- delegateより簡単
- async / await
- 実装例：アラートのボタン押下待ち
- reactive extensions
- いわゆるRx
- ライブラリを入れなくても標準で対応している強み
shohei「仮想通貨アプリを作ったけどAppleReviwerに弾かれた話」
歩いたら仮想通貨をもらってお店でポイントとして使えるアプリをAppleで申請
- リジェクト12回
- 国際電話4回
App Store Reviewガイドラインにおける暗号通貨について
- 組織として登録しているデベロッパに限り許可
- 最近追加になった
- 法人アカウントが必要
法人のかたにお願いする
- Opening Lineに支援を依頼
仮想通貨アプリを法人アカウントでリリースする際の注意点
- 事前情報が必要
- そのまま申請すると仮想通貨の情報を教えろと言われる
- 仮想通貨の市場がどれくらいか
- 種類（NEM）
- どこで使えるか？
- いつリリースされたか？
- 歴史
Reviewに出す前にメモ欄に書くとすぐReviewが通りリリースできる
- ※トランザクションを発生させない仮想通貨アプリなら個人アカウントでリリース可能
itok「そら案内の作り方」
そら案内
- 11/17で10周年
気象データ
サーバ
- push通知のために別系統
- Parse独自構成
- Firebase使用
- AWS
- EC2/DynamoDB/SQS/S3
- さくらVPS
- 配信用
- 制限がない
- ほぼ Node.js（Typescript書き換え中）
- 一部PHP
- 独自フォーマットのサーバ処理は自作コマンド
- 市町村2,000地点、アメダス1,300地点の一時ファイル
- i-nodeを使い切ってしまう
- 合併で地点コードが更新される
- 事前準備大変
クライアントアプリ
- 用途に応じたアプリ構成
- そら気温などの単機能アプリもあり
- 以下略
アプリリニューアル予定
Takanori Hirobe「Swift Package Managerについて」
近年のモバイルアプリ
- 複雑で多機能
- 自前で実装していたら途方もない時間
- ライブラリ化して公開
- 例）LINE
- 100個以上
⇒便利なライブラリを自分のアプリで使いたい
ライブラリの管理
- 依存管理
- バージョン管理
iOS開発のためのライブラリマネージャ
SwiftPackageManager
- Swift本体に組み込まれたパッケージマネージャ
- ほとんど使わrてていない
- iOSアプリを公式サポートしていない
- 将来の対応を約束している
オススメ資料
minomata「モバイルアプリ開発に使える設計の話」
設計実装でよくある悩み
- FatViewControllerをなんとかしない
- MVC/MVVM/MVPなど
- 乱立するMVなんとか
MVVM＋クリーンアーキテクチャ
クリーンアーキテクチャ(The Clean Architecture翻訳) | blog.tai2.net
基本原則
- クリーンな設計にするためのルール
- 依存関係を一方向にする
- 内側は外側を知らないように依存関係を逆転させる
- 層をまたぐ参照はインターフェイスを経由する
- MV〜のような特定のクラス構成に縛るものではない
- 原則を守れば MVC,MVP,MVVMなど任意のアーキテクチャと組み合わせてよい
基本4層
- 外部インターフェイス
- アプリの外の世界と接合部分
- UI、ハードウェアなどのインターフェイス
- インターフェイスアダプタ
- 外部インターフェイスとUSECaseの間の相互変換
- ユースケース
- エンティティ（データ）
- アプリ内で共通に使うデータを定義
- 他の層を一切知らない
冗長だけど何が嬉しいのか
- 外部インターフェイスの事情をユースケースから切り離す
- 外部インターフェイスとビジネスロジックケースはお互い深く知らないでよい
- 分業しやすい
- ソースコードが汚れにくい
- 外層に依存しない
- 内層にも最低限しか依存しない
- 外部インターフェイスの変更・差し替えの影響が小さい
クリーンアーキテクチャのキモ：制御の反転
※参考
Clean Architecture 達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)
Hiron「4000のワーニングと戦え！これは警告だ！」
マネーフォワードの事例で警告除去にとりかかる
- 警告除去だけの時間は確保できないので合間で作業
- チームメンバー間の温度差
警告除去を盛り上げていこう！
- Slackにチャンネル作成
- 警告数の遷移を可視化
警告を消すってどういうこと？
- 警告⇒文法的には間違っていないがプログラムミスの可能性のある部分の指摘
- 警告を消す⇒問題があれば修正、なければ問題がないことを意思表示
Xcode9.3へのアップデート
- 4,000超え
- Implicit retain of 'self' within blocks
- UIスレッドで同期的に実行するユーティリティメソッドを作っていた（swiftなら@namescape)
どう解決するか
AとC採用
- 確認する意思のある人は確認して手動追加
- それ以外は機械的に追加
警告を増やさないために
- エラー扱いにする⇒デバッグ時に煩わしい
- CIのビルド時に警告をエラー扱いに
KatsukiNakatani「個人でもできる簡単CI/CD(Android)」
Androidの開発からリリースまでの作業
- 少しずつめんどくさく感じる
- 毎回apkやaabをアップロードして変更履歴
- リリースビルドしてadbコマンド
- ビルドに時間がかかる
Cricle CIでビルド環境を改善
- 無料でプライベートリポジトリにアクセスができる
- 1コンテナ1ジョブまでは無料
- developブランチは無視でmasterはビルド
出来た結果のapkを配信したい
- 実機端末にケーブルレスで配信したい
- 内部テストとして必要なメンバーだけ配信
- ストアに掲載する情報もできればリポジトリで管理したい
Deploy Gate
- aab未対応
- 結局Google Playで配信
Google Playの内部テスト版トラック
- リリース前レポートが実行されず即座に配信される
- aabも使える
Gradle Play Publisherを使う
- リリースするトラック情報の編集
- build.gradleに書く
- バージョン挙げ忘れなどもチェック
※参考
Kenta Nakai「Asset Catalog再入門」
画像の管理
Preserve Vector Data
- Xcode9/iOS11~
- PDFのベクターデータをバイナリに含めるように
- 実行時に自動的に拡大・縮小
色の管理
- 定義した色はコードでもInterface Builderでも使えて便利
- UIColer(name: "xxxx")
その他データ管理
- テキストデータ、オーディオなど
- プロジェクトの中に入れるよりは一括管理しやすい
アセットが大量になったら？
- Namespaces
- アセットに名前空間を提供
- Asset Catalog内のフォルダごとにnamespaceを設定
- Asset Catalogごとに分ける
- フォルダごとにはできない
- Bundleを分けてBundleの中で作れば分けられる
【勉強会メモ】関西Node学園 4時限目
- 日時：2018/11/02(金) 18:40 〜 21:00
- 場所：さくらインターネット株式会社 大阪本社
気づけば4時限目を迎えた関西Node学園。Nodeに限らず広くJavaScriptに関する知見共有の場ということで最近はReactやVueの話題が多いですが、そのあたりから流行をうかがい知ることができます。直接関係ないですが、Node.jsのアドベントカレンダーも参加を募集しているようです。
React/js小ネタ集
YukimasaFunaokaさん @mochiya98
遅れて参加して聞き逃してしまったので資料のみ紹介します。
Firebase Cloud Functionsを使って頑張って歩いた人へ仮想通貨NEMを無料で贈る仕組みを作った話
shoheiさん @hobbydevelop
歩いたらブロックチェーントークンをプレゼントするアプリを作りました
- 2015年最初のブロックが生成されたブロックチェーン
- 単位はXEM
- NEMの機能をWeb APIとして提供されている
- NEMを管理するためにはウォレットが必要
- 送金先アドレス：お金を受け取る
- 公開鍵
- 秘密鍵：バレると送金とかされてしまう
Firebase
- Cloud Firestore
- NoSQLデータベース
- 高速
- 様々な言語で利用可能
- Cloud Functions
- バックエンド処理
- Node.js
- イベント駆動
アプリの流れ
- 歩いたら歩数をFirestoreに登録
- Firestoreの登録をFunctionへ通知
- Functionから送金
nem Library
アプリ
歩くことでトークンを発行できる
Our Favorite DependencyUpdates Has Been Deprived
ttさん @tatsushitoji
npmどうやってアップデート？
- 2018.3月 renovateリリース
- Automated Dependency Update
対応サービス
動作環境
良い点
- 自動でPRを作成
- config ファイルで柔軟にカスタマイズ
- OSS
- Auto merge
これまで
- ブランチを作ってPush
- PR作成
- WebhookでCI実行
- CIが通ったら手動マージ
renovateなら 2 以降自動化できる
- Onboading PRを作ってくれる
configファイル（renovate.json）
- メジャーアップデートはAuto merge
- タイトルを編集するとrebaseしてくれる
※参考
js vs gs 〜JavaScriptとは違うGoogleAppsScriptの勘所&オープンデータ生成のGAS活用事例〜
xinsuzukiさん @xinsuzuki
GAS
- alertなどの関数が使えない
- ES2015非対応
- コード補完できない
- Github管理できない
解決できるスクリプト
- js->gs変換ライブラリやgas-clasp-starter
独学でVueを勉強した勢いで自社アプリをリプレイスした話
いずみんさん @is_ryo
www.slideshare.net
なぜVueなのか
- jQueryとかでアプリを作るの飽きてきた
自社アプリをリプレイス
IoT.kyoto VIS
- IoTデバイスデータの可視化アプリ
リプレイスした結果
- jQueryから卒業
- DOM操作って複雑になりがち
- めんどくさいDOM操作をVueが解決
- DOM操作のストレスから開放
- アプリがServerlessになった
最近のvue界隈
- VueにもCLIがある
- 生でJS書きたくないからTSで
- 初期のビルドでTypeScriptを用意できる
- Pug/Sass/TypeScriptでVueを書いている
- Vue UIがいい感じ
- beta版
- vuesax
- UIコンポーネントのFw
- ElementUIより良い感じ
- TypeScriptに対して優しくない
Evan You来日記念オンライン質問コーナー
TypeORMを素振りした話
ゆずさん @yuzu_441
発表資料
Node.jsでいい感じのORM知りませんか？
TypeORMとは
ormconfig.json
- DBの設定
- Entityのパス
できること
saveでinsertfindOneなどで検索- JOINもできる
- Transactionも書ける
@BeforeInsertみたいなフックもある- Loggerの設定もある
- RubyのActiveRecord風にも書ける
type safeに書けるのか？⇒今のところ書けない
プライベートでReactとTypescriptでアプリを作ったので知見を共有ししつつ、有識者にマサカリでズタズタにされたい
Nokogiriさん @nkgrnkgr
React/TypeScriptでハマったことなど
作ったもの⇒expenses-automation
- Googleカレンダーで入れた訪問先のデータを経費精算の形式にしてCSVで出力する
コンポーネントとデータ構造はほぼ同じ構成
- サーバからは月単位のデータをfetchしStateにそのまま突っ込む
モジュールのディレクトリ構成
ネストの深いStateの更新
- Reactの
setStateはStateが持つ第一階層のオブジェクトしか更新できない - 駅名を変更する場合でも月ごとのStateの更新が必要
- 普遍データ構造を扱うFacebook製ライブラリ
CSSはなるべく書きたくない
TypeScriptの導入
- 開発規模が小さいと方安全の恩恵は感じない
- Interface定義によるVSCodeの入力補完の恩恵はすごい
- TypeScriptを使うと引数がどんな戻り値を期待しているかが一目瞭然
パフォーマンス・チューニング
Redux
- 今回は導入なし
- バケツリレーは苦にならないと判断
- 小さくてもバケツリレーになるので入れておけばよかった
FunctionalComponent
- Stateがないものだけ使用
VSCode拡張
- Debugger
PR告知
自社の宣伝で恐縮ですが、弊社でもNodeやVueを使っているチームがあって今回の勉強会にも参加していました（偶然会場で会った）。そんなチームのメンバー（今回の勉強会の参加者とは別の人ですが）も登壇する大阪オフィス初のMeetupが11/27に開催されますのでよろしければご参加ください。
【勉強会メモ】ScrapboxやGyazoを生み出しているNOTAの開発の現場
- 日時：2018-10-29（月）19:30 - 21:30
- 場所：株式会社リアズ
京都でScrapboxやGyazoというサービスを開発しているNOTAという会社の開発の現場の話を聞いてきました。Scrapboxというサービスは個人で使ってみたことはあるのですが、それ以前に何かで知っていたはずだけど何だったかな？と思い出せずにいたのですが、答えはセションの中で紹介されていたWEB+DB PRESS vol.102の記事でした。この記事の中でも書かれていたドッグフーティングの取り組みが今回のセッションでも話題になっていました。
たしかにScrapboxやGyazoのようなサービスではドッグフーティングがとても大事だというのは話を聞いていてよくわかりました。思ったとおりに使えないと自分たちが困るくらいにドッグフーティングを徹底するというのは緊張感があってとてもよい環境だと思いました。
スクラムの部分はやや変則的なスタイルだと感じましたが、リモート前提でのアジャイルなスタイルを模索して取り組んでいるのがよくわかりました。ドッグフーティングと同様にリモートワークを中心に据える文化にこだわっている点は、自分たちがプロダクトにコミットし続けるために重要なことなのだろうと思いました。
アジャイル開発チームのための、ナレッジ共有入門
洛西 一周さん @rakusai
※遅刻して前半少し聞き逃しました。。
- 競争より創造
- ITの革命は常にユーザー向けの機能から
- Notaは創造のお手伝いができるツール群を開発
- プロジェクト管理を通じて、クリエイティブな組織にどうやって切り替えていくか
リモートワークキングの重鎮による宣言文
Notaは日本の企業として始めてRemoteOnly.orgに掲載
リモートワークの失敗
- 実際に人が会って、会話をしないと、知的なことは進められない
- Gyazo&Scrapboxを使おう
- オフィスをバーチャルに再現しようという考えを全部捨ててみる
- 「タスク管理」はどこまで行ってもサマリーの管理
バーチャル->リアル現象
- ミーティングの議題だけ書いておくと勝手に議題が進む
モダンなナレッジ共有に至る原則
ドッグフーティング
- 自分たちがリモートワークして毎日Gyazo,Scboを作っている
Notaのスクラムとマネジメント
秋山 博紀さん @akiroom
CTOとVPoE
- CTO：技術系の役員
- 新しい技術課題への挑戦、考察、実験
- 長期スパン
- VPoE：管理職
- 組織構築、採用、育成、マネジメント
- 中短期スパンで考える
スクラム導入後にVPoEに就任
スクラムの導入経緯
- 導入前：自由にタスクを決めて動く
- 人が増えてマネージャが全体を見られなくなった
- 当時の赤字を解消するためタスクの確実な実行が必要
以下2点を解決するためにスクラムを導入
- 会社で何が起きているか
- 必達のタスクを確実に遂行する
Nota式スクラムを支える技術
Sprint ,KPT
- 2週間1 Sprintタイムボックス
- Sprint初日にSprint中にやる内容を決める
- 毎日共有
- 最終日にふりかえり、KPT
Sprint 0〜
- スクラムの解説ページを作った
- タスクを集約して俯瞰できるようにする
- 体制の構築に時間をかける余裕がない
- 慣れてきた人が増えたらルールを追加
- 体制
- エンジニアとデザイナーDev
- PO⇒CEO
- Start MTG
- 具体的な施策の説明
- メンバーが現在のタスクを出していく
Sprint100週間で起きた変化
- Sprint 53（現在）
Sprintのメリット・デメリット
- メリット
- 実際にやってみて会社が取り組んでいるタスクが明瞭に
- お互いに困っていつところをさ助け合えている
- デメリット
- 今のところ無い
- 人数が増えた時にどうなるか
Kanban
- ZenHub利用
- 大事なタスクの進捗を厳密に管理
- レビュー待ちが一目瞭然
Scrapbox式プロジェクト管理
- Scrapboxにタスクを列挙
- 議論の粒度を柔軟に制御
- テキスト派も会議派も満足
Nota式スクラムのコツ
Gyazoの開発の進め方
Pasta-Kさん @pastak
Gyazo Browser Extension
Gyazoの開発環境
基本的に全員がリモートワーク可能
- PR⇒commitごとにstaging環境自動生成・更新⇒deployment APIで通知
ninja: release 〜とチャットに打つとrelease用のPRと確認用の環境が構築される- PRがmergeされるとdeply開始
ずっと変わっていないこと
- どこでも働ける
- Gyazoがあらゆるコミュニケーションの中心
Gyazoとドッグフーティング
Gyazoの新機能の生まれ方
- ビジネス的な要望
- VPoEとかから頼まれてSprintのタスクに組み込まれる
- ドッグフーティング
Move Fast and Beak Things
- 元はFacebookのモットー
- すばやく行動し破壊せよ
- とにかくデモファースト
- デモを大事にする
- 結局作ってみないとわからない
- 勝手におもしろ機能
誰でもGyazoに関わる全てのコードを変更できる
- 日々の文句があればPRで闘う
A/Bテスト
- 今はやっていない
- どんどんdeployしたりrollbackできるのでどんどん出して改善するスタイル
スタッフ向け機能
- リプレイスの影響が大きいものは作りながらスタッフ環境で日々ドッグフーティング
Scrapboxのドッグフーティング開発
daiizさん @daizplus
ドッグフーティング
- いろいろな用途で使う事が大事
- 日頃の開発コミュニケーション
- 個人のブログ
- 複数人での勉強会
- 気合が入る
- 自分が使うものが壊れていると困る
- 面白い機能や使い方を見つけることができる
やりたいことを全て書く
- とにかく書く⇒アイデアをリンクでつなげる
- ページを切り出す機能を使って細かく考えていく
- アイデアの例
- キーワードを指定したGoogle Maps埋め込み
- 建物を入力して地図
- アイデアはボツになったが地図を埋め込む機能で使われた
- キーワードを指定したGoogle Maps埋め込み
- 要望やバグを書く
- 作る機能について書く
- 調べたこと、試したことを書く
- 小さく作ってPRを出す
Q&Aセッションのメモ
- あまり書くのが得意ではない人もいるが、Scrapboxの使いかたは箇条書きが多く、長い文章は書かない
- 書ける人がフォローする
リモートワークの勤怠や評価の観点
- GitHubでエンジニアの仕事が可視化されてマネージャと話をすればだいたいわかる
- 時間では評価せず中身で評価
カルチャーの作り方やチームビルディング
- あとから来た人が何を聞いても大丈夫なようにテキスト化
- 絵文字を多くしてみる
- 知識をフラットにすると組織もフラットになる
- 開発合宿をやる
2週間スプリント
- 中間チェックポイントがあって進捗のカバーなどを相談する
ふりかえり
