Developers Summit 2019
○ 概要
「SHARE YOUR FUN!」がテーマ。
技術を学ぶことは楽しいことであり、楽しいことは成長をブーストさせることに繋がる。エンジニアの皆さんが楽しく学んだ技術を共有することで、参加者全員の成長をブーストさせることを目的とする。
○ リンク
○ twitter
◎全体ハッシュタグ
devsumi
◎部屋別ハッシュタグ
A会場 devsumiA
B会場 devsumiB
C会場 devsumiC
D会場 devsumiD
E会場 devsumiE
F会場 devsumiF
G会場 devsumiG
▼ イノベーションを支えるアマゾン文化
○ 会場
02/14 10:00~10:45 【14-C-1】
○ リンク
○ 登壇者
西谷 圭介 アマゾン ウェブ サービス ジャパン
○ 内容
「地球上で最もお客様を大切にするようであること」をテーマとする。
https://res.cloudinary.com/silverbirder/image/upload/v1550151697/developers%20summit%202019/Amazon_01.jpg
Customer Obsession,
→お客様への執心
→常にお客様を起点に行動する。徹底する。
Long Term Thinking
長期的な視野
https://res.cloudinary.com/silverbirder/image/upload/v1550151701/developers%20summit%202019/Amazon_03.jpg
selection → 品揃え
customer experience → 顧客満足度
traffic → 顧客数
sellers → 売り手の数
lower cost structure → 低コスト
lower price → 低価格
if you want to be inventive, you have to be willing to fail
ビジョンにはこだわって、ディテールには柔軟に。
awsは、当初risky betと呼ばれた。
物流システム、小さなロボットで荷物を運んでいる。
https://res.cloudinary.com/silverbirder/image/upload/v1550151717/developers%20summit%202019/Amazon_05.jpg
amazon goもサービスイン
You have to be willing to be misunderstood for a long time
イノベーションのための組織づくり
・メカニズム
→ press release, faq, user manual
https://res.cloudinary.com/silverbirder/image/upload/v1550151701/developers%20summit%202019/Amazon_06.jpg
→ プレスリリースとfaqを始めにプロダクトを作る際、用意する。outputするため。
外に流さない(社内向け)も、同様のプロセスを踏むそう。
5questions
https://res.cloudinary.com/silverbirder/image/upload/v1550151765/developers%20summit%202019/Amazon_07.jpg
顧客視点でquestionを考える。
FAQは、顧客やステークホルダー両方ともきくそう。
どんなハードな内容も聞く。んー、逃げないのかな。
Visuals
・ラフアイデアとして、簡単に書く。
Press Release, FAQ, Visuals
https://res.cloudinary.com/silverbirder/image/upload/v1550151702/developers%20summit%202019/Amazon_09.jpg
・プレゼンテーションツールの利用はやめている。
→ 話し手の力に依存。確かに。聞き手もそう。
会議では、6ペーパーと呼ばれる形式のレポートで行われる。
→ 5分間、読む。考える時間があって良いよね。
・アーキテクチャ
→ モノリシックをマイクロに。 2 pizza teams ?
HTTPSのAPIのみ
お互いをブラックボックス、microsevices/ devops
→ アマゾンの巨大システムだと、障壁がたくさんありそう。
すべてのアマゾニアンが心がける心情で、人事評価に関わる。公開している。
https://res.cloudinary.com/silverbirder/image/upload/v1550151702/developers%20summit%202019/Amazon_10.jpg
公開する度胸。
テストを大切にしている。
テストを非常に重要視しているので、それを中心としてシステム設計をしている。
テストは、もちろん自動化し、CIでテストしてもらう。
運用も大切にしている。
ほぼすべて自動化している。
よく考えるため、5回whyを繰り返す。
倹約、お客様にとって重要でないものに、お金を使わない。
発明を育てる源。IRに出ている。
https://res.cloudinary.com/silverbirder/image/upload/v1550151704/developers%20summit%202019/Amazon_12.jpg
プロトタイプを作って、早く作って、早く失敗して、繰り返す。
早くしろ!じゃなくて、過剰な分析をやめること。
人を追加する際、高いレベルを下げないよう、採用をしている。Hire and develop the best
→ 無関係な人がインタビューし、チームのレベルを上げるような人材を狙う。
・組織
https://res.cloudinary.com/silverbirder/image/upload/v1550151704/developers%20summit%202019/Amazon_13.jpg
2pizza teams
→ 少数精鋭が良いよね。2枚のピザで収まるぐらいの人の数にする。
→ ロードマップや開発、運用・カスタマーサポート、作るものすべての責任を負う。
QAも、トラブル(オンコール)も。
Opsは、存在しない。
・高い水準を維持する
→ 繰り返し学習を進める。
・イテレーションが大切
▼ Alexaスキルで収益化を目指そう
○ 会場
02/14 11:05~11:50 【14-D-2】
○ リンク
○ 登壇者
畠中 俊巳 アマゾンジャパン
○ 内容
・デザインガイドもらった!
・拡大し続けるAlexa
https://res.cloudinary.com/silverbirder/image/upload/v1550151698/developers%20summit%202019/Alexa_01.jpg
→ スマートスピーカーとして発売したが、これからは様々な媒体にも連携できるようになる。
・スキル内課金の可能性
https://res.cloudinary.com/silverbirder/image/upload/v1550151698/developers%20summit%202019/Alexa_02.jpg
会社ではb2bだから、難しいけど、個人サービスで利用できるかも?
1.amazon pay for alexa (物理的なもの)
アマゾン以外のECサイトでもお買い物ができる。
amazonアカウントでお支払い
→ ウチのECサイトに導入。。んー。b2bだから無理か。
↓
for alexa
→ 出前館、JTB、メガネスーパーなど
リピート購入には、効果的。
alexa.design/jp-amazon-pay
→ 音声インターフェースで購入。。そんなシナリオはないかなー?
2.スキル内課金 (デジタルなもの)
日本ではまだ導入できないかな?
One-Time purchases
買い切り型
→ ゲームでいう新ステージ購入とか?
Subscriptions
定期
→ 有料コンテンツを定期的に支払いする。そういう仕組を作れる。
Consumables
消費型
→ ゲーム内コインとか、アイテムとかかな?
米国マーケットのみ!
https://res.cloudinary.com/silverbirder/image/upload/v1550151696/developers%20summit%202019/Alexa_03.jpg
スキル内課金により収益は、70%が入ってくる!
30%は、アマゾンに入る。(ディスカウントも含む)
developer.amazon.com/alexa-skills-kit/make-money
金額支払いまわりの応答は、おまかせできる。
・収益をもたらすスキルとは?
音声ならではの特徴があるよね。
→ 手が離せないときとか、会話を楽しみたいとか、視覚に不自由な人とか。動きたくないとか。
→ Webやスマホアプリとは異なる体験になる。
→ 音声だからこそのシチュエーション
★ 繰り返し使ってもらえるスキルが大切
・コンテンツは、米国を参考にしてもよいが、それよりも日本人向けのコンテンツを考えてみよう。
・ベストプラクティスは、最初フリーで、全てのコンテンツを使ってもらい、途中で課金できるようにする。まあ当たり前よね。
https://res.cloudinary.com/silverbirder/image/upload/v1550151698/developers%20summit%202019/Alexa_04.jpg
※まだ日本に導入されていない。チャンスか!?
にすべて集約している。
alexa.design/jp-alexadojo
▼ セキュリティ・テストの自動化によるDevSecOpsの実現 (デモ有)
○ 会場
02/14 12:10~12:40 【14-E-3】
★ランチ(軽食付)
○ リンク
○ 登壇者
吉井 雅人 日本シノプシス
○ 内容
シノプシスという会社は、エンジニアの支援する会社。
静的解析ツールが主サービス。
上のサービスの紹介を述べている。。
https://res.cloudinary.com/silverbirder/image/upload/v1550151779/developers%20summit%202019/%E3%82%B7%E3%83%8E%E3%83%95%E3%82%9A%E3%82%B7%E3%82%B9_01.jpg
SAST & SCA
静的解析ツール?
SEEKER IAST
CI/CD自動化によるビルド
DAST & Pen0test
QAおよび運用中に実行中のあぷりけーしょんで脆弱な動作をテストアンド報告する。
DevOpsのセキュリティ
→ テスト結果にご検知が多いので、トリアージに時間を要する。。。
→ 環境を用意しないといけない。開発プロセスの変更が必要
→ セキュリティテストの結果を見ても分からない。(専門の人がいる)
↓
以下をモットーとする。
正確性(誤検知が少ない)
連携(ツールをつくらなくてもすむ)
対応可能(具体的なソースコード位置を言う)
1.開発者のストレスにならない正確さ
→ 誤検知 < 5%
HTTPリクエスト後、javaのエージェントを埋め込むことで、コードを分析してくれる。
java寄りやん!
2.機能テストを実行するだけ
→ 特別な環境を用意しない
3.開発者が対応可能な表示をしてくれる
→ ファイル名、メソッド、行番号まで言ってくれる。
webgoatとは?
脆弱性が多いアプリケーションのこと。
→ webのゴート。
どこから、どうデータが降りていくのかわかる。
また、どう直したらよいかのっている。
▼ 日経電子版のマイクロフロントエンドとPWAによる改善事例
○ 会場
02/14 13:05~13:50 【14-B-4】
○ リンク
○ 登壇者
宮本 将 日本経済新聞社
○ 内容
日経電子版、Node.js,vanillaJsが技術スタック。すごくjs推し。
日経電子版、
→ トップ、記事(静的ページ)
→ 検索、Myニュース(動的)
ページごとにマイクロサービスに分割しているみたい。
CDNでエンドポイントを振り分けしている。
TypeScriptを導入した
→ うちも導入したい!
→ flowはプロジェクトをまたいで型定義を共有しにくい。
TypeScriptって、ウチのクライアントと相性良いのか?
JSXを導入
→ テンプレートエンジンの静的チェックがきびしかったため、導入。
うちのテンプレートエンジン、jinja2とかは、あるのかな?
PWAの話
AppShellを導入した。Fastになる。
FirstPaintが高速になる
aタグのhrefをpreloadしてくれるライブラリ。
割と今ほしかった機能。
treeshaking 不要なコードを削除する系かな?
critial render path ?
critial cssを最適化するため、CDNでesiタグを付与して、軽くする。
serverless-chromeを導入したい
キャッシュ戦略で、キャッシュアイテムの所有者を誰かを管理する
Feture toggle とは?
フラグ制御で、サービスのON/OFFを行うこと。
ウチのplugin.jsと同じ発想かな。
▼ 【第1部セッション】いまなぜGoogle Cloud Platformを学ぶのか!?〜GCPを支えるGoogleテクノロジーと愛を語る〜
○ 会場
02/14 14:10~15:40 【14-G-1】
○ リンク
○ 登壇者
中井 悦司 グーグル・クラウド・ジャパン
【MC】深堀 まど佳 グーグル・クラウド・ジャパン
福田 潔 グーグル・クラウド・ジャパン
岩崎 大志 グーグル・クラウド・ジャパン
千藏 大輔 グーグル・クラウド・ジャパン
有賀 征爾 グーグル・クラウド・ジャパン
○ 内容
https://res.cloudinary.com/silverbirder/image/upload/v1550151705/developers%20summit%202019/GCP_01.jpg
gcpの愛を語る会
googleの自分たちのサービスを作る上で用意していたテクノロジー。
それを公開するようになったのが、gcp。
なかいさん、ソリューションアーキテクト
@enakai00
GCPの技術支援を担当
googleの技術情報は、ゆるく、ほぼ誰でも共有できるという!!
(社員の話か?、社員の話っぽかった)
Googleは、「世界中の情報を整理し、世界中の人々がアクセスできて使えるようにする」
ターゲットは、全世界の人。かっけー!スケーラブルアプリを作るの、大変そう。
https://res.cloudinary.com/silverbirder/image/upload/v1550151705/developers%20summit%202019/GCP_02.jpg
googleでは、k8sではなく、google-borgを使っているそう。k8sの根幹?
https://res.cloudinary.com/silverbirder/image/upload/v1550151708/developers%20summit%202019/GCP_03.jpg
基本的に、標準化を意識している。ので、これ使いたい!でも標準化されていないと使っちゃだめ。スケーラブルでなくなるから。sql使いたい!とかね。
いよいよ開発環境の中身の話!
googleは、gitつかってないだと!!!(おれおれgitらしい)
https://res.cloudinary.com/silverbirder/image/upload/v1550151709/developers%20summit%202019/GCP_04.jpg
また、リポジトリは1つだけで、フォルダで階層化している。
リポジトリが1つのメリット
https://res.cloudinary.com/silverbirder/image/upload/v1550151708/developers%20summit%202019/GCP_05.jpg
・プロジェクト間でのソースコードの共有を促進
・複数バージョンにまたがる依存関係の問題が起きにくい
・リポジトリ全体にまたがった大規模なリファクタリングが可能
(ソースコードレベルでincludeしているため、ビルドしやすい。バージョン依存問題はありえない)
・巨大な最適化ができる(?)
→ たとえば、C++のリファクタリングで最適化するのだが、1リポジトリなので、一括交換できる。
→ テストとか、どうやってるの??
(デメリットが知りたい)
ブランチは切らない開発ツリー
→ 本番リリースは、ちゃんとブランチがある。(リリースブランチ)
→ 開発ブランチは、ない。 cherry_pick。
デメリット
https://res.cloudinary.com/silverbirder/image/upload/v1550151709/developers%20summit%202019/GCP_06.jpg
・専用ツールの開発・メンテナンス
→ 40000コミット/日を支える分散ビルド、分散テスト環境
→ 20億行を超えるソースコードの検索システム
→ 社内独自の検索システムがあるみたい。
・ライブラリ依存関係の適切な管理
→ 依存関係の自動探索、不適切なAPI呼び出しの防止
→ インクロードしまくるってるので、自分が変わったら誰が変化があるのか把握しづらい
→ わかるように用意している。
https://res.cloudinary.com/silverbirder/image/upload/v1550151710/developers%20summit%202019/GCP_07.jpg
・自動テスト環境がものすごく大事
→ あるライブラリが変わったら、影響があるユニットテストすべて動きだす。
・ 一定の条件が揃ったら自動コミットが走るそう。
→ こわい!どれがコミットされるか・・・。
※ 年末年始は、コミット数が激減。ほわいと企業や!
https://res.cloudinary.com/silverbirder/image/upload/v1550151711/developers%20summit%202019/GCP_08.jpg
・blaze (bazelの類似のビルドツール)で依存間駅と自動テストのルールを指定
全部が全部コミット後テスト動かしてたら大変。
https://res.cloudinary.com/silverbirder/image/upload/v1550151712/developers%20summit%202019/GCP_09.jpg
→ 一定期間まって、コミットが溜まった段階で、ユニークなユニットテストを実施している。
チェックポイント(一定期間)がくるまで、待たないといけない・・!
→ 依存関係のホップ数が10を超えると、正直関係ないことが多い。
→ 10未満のものは、結構影響あり得るため、よく調べる。
コードレビュープロセス
https://res.cloudinary.com/silverbirder/image/upload/v1550151713/developers%20summit%202019/GCP_10.jpg
・リポジトリ全体を(仮想的に!!!)ローカルにコピー(数十テラバイトだし)
・ローカルで修正した内容をコードレビュー
・レビュー終了後にリポジトリにこみっと
・コードレビューの前後に自動テストを実行(あと??)
google critique gerrit
https://res.cloudinary.com/silverbirder/image/upload/v1550151733/developers%20summit%202019/GCP_11.jpg
・レビュワーは任意。ただしコードOwnerのLGTMが必要
・コードチェックーが発見した問題は自動でレビューコメント
・変更内容がめちゃくちゃ小さい
→ 軽量なレビュープロセス
(1行の変更があったら、おめでとうとメンションされるそう)
https://res.cloudinary.com/silverbirder/image/upload/v1550151728/developers%20summit%202019/GCP_12.jpg
・小さな変更なら1時間、大きな変更で5時間ぐらい
→ 1人の開発者は、平均して週に3時間のコードレビューを実施
https://res.cloudinary.com/silverbirder/image/upload/v1550151729/developers%20summit%202019/GCP_13.jpg
・コードレビューを目的
→ 他人が理解できるコードを書くこと(これが本当に大事!!)
副次的なこととして、メンテナンス性の向上、バグの混入防止、新規メンバーの教育、他のチームによる利用を用意にする。
レビュワーは簡単にレビューできる状態でなければ、却下すれば良い。
https://res.cloudinary.com/silverbirder/image/upload/v1550151721/developers%20summit%202019/GCP_14.jpg
https://res.cloudinary.com/silverbirder/image/upload/v1550151721/developers%20summit%202019/GCP_15.jpg
・パネルディスカッション
写真・動画・SNSは禁止!
のため、省略
▼ 【第2部ハンズオン】GCPをさわりまくれ!スペシャリストに聞きまくれ!〜大QWIKLABS大会〜
○ 会場
02/14 16:20~18:45 【14-G-2】
○ リンク
○ 登壇者
Google Cloud チーム
○ 内容
を進める。
▼ ソフトウェア開発の「今ココ」に適応するために― カイゼン・ジャーニーから見つかった新たなfunと前進への旅路 ―
○ 会場
02/15 10:00~10:45 【15-E-1】
○ リンク
○ 登壇者
市谷 聡啓 ギルドワークス
新井 剛 ヴァル研究所・エナジャイル
○ 内容
カイゼンジャーニー読んでね!
・4つの役割
本業、副業、勉強会、書籍
↓
んー、スライドが早くつらい
写真いっぱいとった。
なんだか、簡単に言うと
無駄に時間を使わず、人生楽しく進めていこうね的な。
副業や趣味、なんでも良いがやってみようね。
市谷さんは、人の笑顔をやりがいを感じて、
それをモチベーションに進めていく感じ?
んー、気持ち話だった。
新井の話
改善ジャーニーを読んだ人の意見が嬉しかった。
実際に訪問してみた。70回。
越境を繰り返し、進めている。
コミュニティがあるからこそ、継続的に活動できた。
気合を入れるため、沈んでいたコミュニティ(devLove)をあげた!
現在、個人選択が少ない。組織選択が多い。
それはこれからも続くわけではない。
組織で働くよりも、個人で働く、もしくは両方がありうる。
また、自立し、チームを組んで(ギルドを組んで)活動していく。
株式会社ではなく、組合でもない、共同体。
組織があるからチームがあるのではなく、
共通する信念があるからチームがある。
スタートアップの考えの話?
組織に従って働くよりも、副業とかコミュニティ作って
活動もしたほうが楽しいんじゃね?ってかんじ。
取引の考えを共創の関係を築きたい。
→ できるの?
なんだかふわっとした話。具体的な話が知りたかったな。
▼ CI/CDを使い倒して数段上のソフトウェア開発をしよう!
○ 会場
02/15 11:05~11:50 【15-E-2】
○ リンク
○ 登壇者
金 洋国 CircleCI
○ 内容
CI/CDの戦国時代!
What
CIとは?
↓
テスト書いてます?
なぜ、テストを書かないといけないのか?
→ 何度も同じ手順を繰り返さないといけない
→ ミスするので、コンピュータにやらせる。
→ CIに任せる
Why
CIが解決できる
・テストがあるけど、実行し忘れてた。
→ githubの変更をCI/CDが検知
・昔書いたテストが壊れていて動かない
→ テストが壊れた時点で検知。直さないとそもそもマージできない。
使われていない自動化は壊れていく
→ 常に自動実施させていく。
・テスト結果が環境依存
→ まっさらな環境でテストを実行(docker)
→ いつ実行しても同じテスト結果になる
Why Not
CIの導入を妨げる問題
→テストがない!!
テストがなくても進める方法
Step1: お好みのCI/CDを選ぶ
Step2: テスト以外のタスクを自動化
→ lint、カバレッジ計測、循環的複雑度のチェック、ドキュメントの自動生成
Step3: 可視化しよう
→ statusバッジ、ダッシュボードの作成、メール・チャットでの通知
Step4: マージブロック有効化
→ CIが通らないとマージできない、管理者しかマージできない、Force Push禁止
Step5: テストを追加
→ ユニットテストはとりあえず後回し、最も大事なビジネスロジックをする。頑張りすぎない、無理にすると燃え尽きるので、しやすいものから。
CIの導入を妨げる問題
→ メンテナンス
→ 通常専任のエンジニアが必要、CircleCIのようなクラウド型。
クラウド型
→ AWS CodeBuild, CircleCI, GCP Cloud Build Travis CI
オンプレ型
→ jenkins
Beyound
開発フローおさらい
コードをpush → CIで自動テスト → masterへマージ → リリース
CIの先、CDも。
What is CD
→ Continuous Delivery
→ 常にリリース可能な状態を維持する
→ リリース作業に人間の意志が介在する(いつ、どこ、どのバージョンを)
→ Continous Deployment
→ 全て自動
デプロイ
→ コードを本番環境に配置
リリース
→ 配置したコードがトラフィックをさばくこと
Why CD
→ リリース後の問題
→ 検証環境で見つからなかったバグ、仕様とぜんぜん違う動きをする、
→ 細かくリリースし、フィードバックループをする。
そもそもアーキテクチャーがCDに向いていない
→ エンタープライズ、レガシー
→ サービスの疎結合、徐々にモダン化
新システムの導入は、まずCI/CDを導入
→ 後々のことを考えると、楽だから。
CircleCIも密結合システムだったから、Docker/k8sで、マイクロサービス化(1年)かかる。
Beyound CD
・迅速なロールバックができる
→ git revert → CI/CD → 修正完了
・本番環境でのテスト
→ テスト環境だけでテストできることは小さい。
→ 本番環境じゃないとテストできないことが多々ある。
↓
安全で効率よくするためには?
→ カナリアリリース
→ ブルー・グリーンデプロイ
CDによる
・迅速なロールバック、本番環境でのテスト、高度なリリース手法。
→ 間違ってもすぐやり直せるから、リリースは怖くない。
CI/CDの未来
常に自動化してきて、進化してきた。
CI → CD → 今手動でしていること
・CI/CDの設定
・モニタリング
・デプロイ環境の構築
▼ 飲食 x IT 〜飲食業界の課題解決に挑むサービス開発の現場〜
→ なくなった。トレタの未来?
○ 会場
02/15 12:10~12:40 【15-D-3】
★ランチ(軽食付)
○ リンク
○ 登壇者
吉田 健吾 トレタ
○ 内容
トレタについて話
飲食店向け予約管理、顧客管理のクラウドサービス
→ 業務支援ツール
→ 予約台帳サービスなので、売上が入っていない。
トレタのミッション
→ 食の仕事を、おもしろく。
飲食店の従業員は、人海戦術で気合ゴリ押しで頑張っていることが多い。
→ 新たな取組が取りづらい
トレタのサービスを使った居酒屋さん(3000円ぐらいの単価)
→ walk inレベルのお客さんは、予約をわざわざしようとしない。リピータはすくない。(リピータの人もいるかもだけど)
→ そりゃそうだ。
トレタのサービスを使った居酒屋?さん(5000円ぐらいの単価)
→ リピータが割と増えている。
→ パーソナライズされるため、もう一度いきたくなる。
リピートと売上に相関があるのか売上データがわからないので、わからない。
→ データを提供して頂いて分析したところ、正の相関があった。
ほとんどの飲食店は、常連化に失敗している
→ 新規客が1000人いても2年後には2人しかいない。
常連になるのは、最初の1~3回目が勝負(3回目に来た人が4回目に来る確率は30%程度?)
(10回目の人が20回きてくれるのは容易)
→ スタンプカードで10回目の人には不要ではないか。
常連予備軍(2回目、3回目)をいかにして常連になってもらうか、試行錯誤している。
トレタ、予約管理の未来に力をいれる。
→ 配席技術の未来
要は、パズルのように、席を埋めていくと効率よく収益が増える
→ 属人化しており、これによって収益が10%から20%かわるところもある。リスクがある...
→ 自動配席機能を作った
→時間短縮が圧倒的で、能力も熟練者なみ。
→ 良いサービスになりそう。
超直前予約
→ 2次会の手配とか、あるよね。21:00以降ならめっちゃ空いてるのにもったいない。
→ 行きたいところとマッチできないときがあるから、もったいない
→ 直前キャンセル(無断キャンセル)も、飲食店にとって直前予約はありがたい。
↓
オンライン決済で、財布すらいらないようになれば、なおよい
▼ OSS開発スタイルを取り入れて、効率的な開発を!~InnerSourceのススメ~
○ 会場
02/15 13:05~13:50 【15-D-4】
○ リンク
○ 登壇者
田中 裕一 GitHub
○ 内容
企業にOSSを取り入れることによるメリットについて紹介
githubに入社すると、githubで全て管理されている。
入社後、onboarding checklistをissueに出されるので、読んで進める。
→ 読むべきドキュメント、インストール手順
→ URLの間違いを見つけた。
→ このままでも結局大丈夫なんだけど、直しといたほうが良いかも。
→ リンク切れをプルリク出して、修正してマージした。
→ マージ時、CIが動くし、レビュワーが自動アサインされた。また、目次を自動生成するのも走った。
→ 5分後にOkもらって。ちょっとした修正なのに、うれしかった。
→ たったドキュメントなのに、他のチームなのに、みんなでコントリビュートしていく文化。その仕組もちゃんとある。
・貢献できる喜び、重複した無駄な作業がない、高い生産性に、感動した。
企業内にOSS的な文化が根付かせれば良いな(innerSource)
企業のソフトウェア開発の問題
→ ソースコード、ドキュメントが簡単に検索できない。
→ 組織内の知識共有がうまくできていない
→ 社内のソフトウェアの再利用性が低い
→ チーム間のコミュニケーションコストが高い(マネージャーをめっちゃ挟まないといけない)
InnerSOurceとは、オープンソースのベストプラクティスを企業内のソフトウェアを取り入れること。
・コードの再利用
・チームをまたいだコラボレーション
・品質の高いソフトウェアをより高速に開発
文化を変えるのはとても大変
→ ツールを導入することで、それを使う人の行動が変わり、ちょっとずつ文化が変わり始める。
→ まずはツールをつかってもらう。
1.情報を共有する基盤を統一する
→ 他の人が見ることができるようにしないと始まらない。
→ 理由がない限りは、パブリックにしておく
→ 検索できるようになるのも非常に大事
あらゆるコンテンツにURLを残しておくこと
→ 経緯がわかるため、次のステップを進めれる
(メールはだめ。URLが振られるのが最も良い)
2.コントリビュートの仕方を明確に
・コントリビュートへの敷居を下げる
・チーム外からのコントリビュートを歓迎していることを明記
・コントリビュートの具体的な手順を明記
・contributing.md
→ バグレポートの登録の仕方
→ 機能要望の登録のシアkた
→ pull requestの送り方
・issueやpr templateがある。
3.ワークフローを自動化
→ 変更のにようにとってレビュアーを自動で設定
→ PRがマージ可能となる条件を明確化
→ ドキュメントサイトを自動生成
→ その他のワークフローを自動化
CODEOWNERS
→ ファイルの種類やディレクトリ毎にOwnerを指定可能
→ Jsはフロント、goはバックエンド、cssはデザインとか。
CI + Protected Branch
→ 初めてコントリビュートした人にとって、どんな規約なのかわからない。
→ CIで教えてもらえる。
GitHub Pages
→ ドキュメント用ページ(ページが自動生成する系)
交通費精算のドキュメントも、github pagesで生成して、リポジトリ管理される。
GitHub Actions
→ push、pull requestなどのイベントをフックして、ワークフローをトリガーできる。
→ docker コンテナになっているので、再利用可能
ex.
・issueが来たら、コメントを返すとか
・マージ済みのブランチを削除する
・マークダウンの目次を生成する
・WIPやPRを間違ってマージしないようにする
Trusted Committers
レビューする人。
誰もレビューしなくなるから、当番制にしてドキュメント化する。
コントリビュータ側からするとドキュメントを見て誰をレビュワーにしたらよいか分かる。
Getting Started with InnerSource
Understanding the InnerSource Checklist
という無料本がある。
というオープンソースに関わる活動。
コントリビュートの良い例
▼ これをまだ知らない Web エンジニアへ贈る - 私が愛する Elixir/Erlang の楽しさと辛さ -
○ 会場
02/15 14:10~14:55 【15-D-5】
○ リンク
○ 登壇者
幾田 雅仁 gumi
○ 内容
運用における辛い面
→ 並行性、メンテナンス性、耐障害性
↓
Webサービスの悩み
↓
エリクサーが解決してくれる?
流行ってない!!!!
Web開発のための優秀ツール完備、サーバ構成をシンプルに保てる、コードもシンプルに保てる。
↓
なぜ!
↓
学習コストが高い!
・並行処理、関数型、マクロ、Erlang
→ 実は高くないよ(低くもない)
・安全性が高く、生産性が高い。
学習コストを割く→ リストの扱い方
割かない → 並行処理、マクロ、ビヘイビア、プロトコルなど
逐次処理を書くだけで、並行処理の恩恵が受けれる?
Phoenix
EVM(erlang vm) = OS
Cowboy = WebServer
iex = shell
EVM
・独立したCPUを持つ
・独立したメモリを持つ
・ネットワーク上のいち伊那住所を持つ
iex → shell_default.i
速さよりも、安全性が重視されている。
関数型であるが、純粋ではない。ただ、関数型を手軽に学べるから良い。
プログラミング elixir p11 -p157
(11,16,20を読み飛ばす)
リストがある。
enumある。
doある。
エリクサーで、パイプラインっぽく書ける
→ 可読性を上げる
関数定義に一貫性が生じる
→ パイプライン
エリクサーの用途をAPIサーバとしてのみ使う。ステートレスでオートスケール。
ETS,DETS,Mnesia
→ 「すごいErlangゆかいに学ぼう」で学べる
複雑になるから使わない。
クラスタリング
→ 不要
コードホットスワップ
→ 不要
↓
楽にしたいから触れるな。
触ってみたくなった。
▼ サーバーレスで最高に楽しめるアプリ開発
○ 会場
02/15 15:15~16:00 【15-B-6】
○ リンク
○ 登壇者
江藤 武司 Riotz Works
○ 内容
サーバーレスで進める。あるものをつなぎあわせているだけ。
ハッカソンで24時間以内でリアルタイム動画対決アプリを作ることができた。
サーバーレスなので、リクエスト数に応じて課金される。ので、ほったらかしでも無料になっている。
サーバーレスは、周辺システムの監視やログと統合しやすいメリットがある。
もともと、EC2で作っていたものをサーバーレスに移行した。
問題として、マイクロサービスが過剰すぎて複雑になった。
問題点
分割し口絵、パス長すぎ。(マイクロにしすぎたため)
コールドスタートが長すぎた。
↓
実行ランタイムを変更して解決した(Javaからnode.js)
なぜなら、マイクロサービスになっているので影響を受けない。
サーバーレスなので、手軽に変更できる。
みんな大好きtypescriptで型定義
まあ、サーバーレスがあればあんまり周辺について気にしなくてすむから、メリットではあるけど、納期1ヶ月前に実行ランタイム変更ってやばそう(Java→Node.js)
▼ GKEとIstioで構築するクラウドネイティブ・アプリケーション - What, Why, Where and How to use Istio?
○ 会場
02/15 16:20~17:05 【15-C-7】
○ リンク
○ 登壇者
福田 潔 グーグル・クラウド・ジャパン
○ 内容
Why
ソフトウェアが世界を飲み込み
→ それぐらい重要になっている。
アプリケーションをどれぐらい早くデリバリーするのか、ビジネスリーダーにとっては重要になってきている。
今は、昔と違って分散ワールドになっており、スケーラビリティになっている。
→ デメリットもある。難しさ。
→ k8sとistioが解決してくれる
また、モノリスティック vs マイクロサービスの話。
遅延が発生したり、管理が複雑になる。
クラウドネイティブ・アプリケーション
Biz ビジネス Time to market
Dev 開発 任意のコードで開発できる
Ops 運用 自動化する
クラウドネイティブ、本当に自分たちに必要なのか?
What
Istioとは?
サービスメッシュと呼ばれる。
サービス間通信を管理するためのオープンプラットフォーム
CNCF。
Istio以前は、10%カナリアリリースするためにはロードバランサーが必要。
Istion以後は、設定でできる。yamlを書く。ユーザーエージェントで振り分けとかできる。
どことどうつながっているのか、istionならグラフィカルに分かる。
envoy
また、アクセス制限することもしてくれる。
How
サイドカーコンテナ
データプレーン、コントロールプレーン。
Where
GKEから、istioチェックボックスを入れるだけ。
あとはデモで見ていた。
▼ アウトプットのススメ ~技術同人誌・LT登壇・Podcast~
○ 会場
02/15 17:25~18:25 【15-E-8】
○ リンク
○ 登壇者
おやかた
ariaki
hekitter
mochikoAsTech
KANE
長村ひろ
erukiti
○ 内容
おやかたさん
何かしらアウトプットしましょうね。
その中で、技術同人誌おすすめだよとのこと。
1.技術の知識が整理される
2. アウトプットの規模がちょうどいい(商業誌とかの大きすぎず)
3.自分で全部する。 構成・執筆・組版・販売
4.商業化(んー。。)
ariakiさん
無意識を意識する
文章で表現するとか、同人誌を書くとか?
選択的注意
カクテルパーティ効果(うるさいときに自分の名前が聞こえる)
アウトプットする情報は無意識のものにもたくさんあるから、
意識していこうねって感じ。例えば、「ありがとう」という言葉を出したなら、それはそれでアウトプットしている。(?)
hekitter
もともとSlerの文系女子。一度経験してみたくLT登壇をし、変わり始めたとのこと。
初めて書いたアウトプットにコメントを頂き、エネルギーをもらう。
一人だけではもったいない、共有したいとのことで、conpassに投稿し、LT。
developers summitにもお声がかかったため、規模感知らず参加し、今に至る。
長村ひろ
井の中の蛙とおっしゃるひろさん。
同じような仕事を続け、外のことも知らない状態。
その分野ではチョットデキルレベルだった。
10年もずっと同じならそうだよね。
別現場に移動になった際、何もついていけずつらかった。
また、現場部長より「バリューを出せ」と言われ、
アウトプットを出していこうと決意した。
そこから、手順書を作ったりした。
↓
書籍をアウトプットした。そこで、技術同人誌へ。
壁にあたり、そこにくじけず(10年続けていた枷があったのに)、前向きにアウトプットを進めるようになった姿は、良いイメージやね。
mochikoAsTech
インフラエンジニアだった人が、初めて同人誌を書いてみた。4000冊まで売れた。やばい。
特に執筆経験があったわけではなく、全く素人。
他の人とは違って思ったのは、「こういう人にかってほしい」が明確で、内容自体も「インフラという難しそうな部分を丁寧に」という需要があって、あーやってみたいなーって思った。
KANE
ポッドキャストの人。声が大きい。
話す力、聞く力を鍛えてる。
確かに、話す力がすごいな〜
erukiti
アウトプットは、誰でもできる。しないと便秘になる。アウトプットしようと思ったものが、つまらなく感じるかも。
ブログ、twitterをし始めた。コミュニケーションが苦手だからしてる。
あと、バズった記事で、同人誌化・商業化
▼その他
https://res.cloudinary.com/silverbirder/image/upload/v1550151767/developers%20summit%202019/雅叙園東京_2.jpg
https://res.cloudinary.com/silverbirder/image/upload/v1550151764/developers%20summit%202019/バッジ_1.jpg
https://res.cloudinary.com/silverbirder/image/upload/v1550151756/developers%20summit%202019/%E3%83%8F%E3%82%99%E3%83%83%E3%82%B7%E3%82%99_2.jpg
https://res.cloudinary.com/silverbirder/image/upload/v1550151732/developers%20summit%202019/GCP%E3%83%8F%E3%83%B3%E3%82%BA%E3%82%AA%E3%83%B3_3.jpg
https://res.cloudinary.com/silverbirder/image/upload/v1550151781/developers%20summit%202019/言語ペットボトル_1.jpg
https://res.cloudinary.com/silverbirder/image/upload/v1550151796/developers%20summit%202019/言語ランキング_1.jpg
https://res.cloudinary.com/silverbirder/image/upload/v1550151790/developers%20summit%202019/%E3%83%9D%E3%82%B9%E3%82%BF%E3%83%BC_1.jpg
https://res.cloudinary.com/silverbirder/image/upload/v1550151789/developers%20summit%202019/%E9%96%8B%E5%A7%8B%E3%82%B9%E3%83%A9%E3%82%A4%E3%83%89.jpg
わーい!
https://res.cloudinary.com/silverbirder/image/upload/v1550151722/developers%20summit%202019/GCP%E3%83%8F%E3%83%B3%E3%82%BA%E3%82%AA%E3%83%B3_1.jpg