【エンジニア 情報収集】Developers Boost
U-30エンジニア対象のイベントに参加してきたので、その雑記メモです。
・13:00【B-1】オープンソースとグローバルで戦うスタートアップという生き方
【基調講演】横溝 一将 [BoostIO]/【パネラー】加藤 將倫 [Progate]/【パネラー】甲斐 啓真 [STUDIO]
横溝 一将 氏 [BoostIO]
Boostnoteを作っている会社
→ 100％ オープンソースのプロダクト
メリトクラシー
実力が平等に評価される社会をめざしている
いろいろあって、
会社が潰れる
→ 手元に残ったのは、Boostnote（エンジニア向けのマークダウンエディタ）だけだった
Boostnoteは最初はギットハブスター600で全然日の目を浴びていなかった。
ある時、海外のLinux系メディアに取り上げられてから一気に普及
そこからIssue Huntというアプリをリリース
IssueHuntについてはこちら
「IssueHuntのサービスは非常にシンプルです。GitHubアカウントでログインし、GitHub上で自分がメンテナンスしているリポジトリをIssueHunt上に登録します。するとGitHub上のIssueがIssueHuntへ自動的にインポートされ、それらのIssueに対して誰でも寄付できるようになります。そこで集まった寄付金の8割をそのIssueに対するコントリビューター（Pull Requestがマージされた人）、残り2割をリポジトリの管理者が得られるという仕組みです。類似サービスは他にもあったのですが、まだまだオープンソースへのコントリビューションとしての寄付行為は一般化していません。コミュニティを巻き込んでムーブメントを起こし、新しいオープンソースのエコシステム作りにチャレンジしていきたいです。」
横溝氏の思い
オープンソースを使うだけって、ダサくないか？
→オープンソースだけで食える世界があったら、素晴らしいのではないのか。
とはいえ、OSSだけで食えるひとはほとんどいない
OSSへの貢献は
コードを書くだけではない
資金援助etc…
技術援助にとどまらない
◎セッションパート
-STUDIO
甲斐さん
直感的なwebページ作成を可能にするツールを作成
https://earlyaccess.studio.design/
-サービスを作ったきっかけ
もともとIOSエンジニア
人手が足りず、デザインも自分で
-どうやって会社を作ったのか？
社内起業した。
その後、もとの会社に買い取ってもらう
-技術選定から開発の進め方
vue.jsを今はメインで利用
-コードが俗人化するのはどうする？
→相手の書き方に合わせてみる
-OSSはやらないのか？
なかなか
-開発者の採用で意識しているところ
マニアックなツールなので、こだわりの強いひと
-目指す世界
コードを書かない世界。コードを書かないのがかっこいいと思っている。
Progate 初心者向けプログラミング学習ツール
加藤さん（プロゲート創業者 25歳）
https://prog-8.com/
-サービスを作ったきっかけ
情報系の学部に進学。
C言語を学んでいた。
はじめはC言語を極めようとしていた。
しかし、Cでどんなアプリが作れるのかわから ない。
→ こういう人は世の中にいっぱいいるのでは？
- どうやって会社を作ったのか？
共同創業者が優秀だったので、彼を頼りに創業した。
- 技術選定
まず、ユーザ体験を考える
もともとJQueryでフロントを書いていた。
コードがぐちゃぐちゃで、バグが頻繁
→Reactへ
自分達がもってるアセットで総合的に決める
- OSSやらないのか？
やってもいい。ただ、それに向いてるプロジェクトとそうでないものがある
再利用可能なものはOSSをやったらよい
- 開発者の採用で意識しているところ
プログラミング初心者の体験をイメージした実装ができるひと。ユーザの心情を理解できるひと。どう稼ぐかというよりも。（Twitterのふぁぼは加藤さん本人が手動でやっている）
- 目指す世界
たとえばインドはまだカースト制度があって、職業が選べない。しかし、プログラミングは新しい概念で、カースト制度の職制に存在しないので、誰でも学ぶことができる。そういう意味で、フラットな世界、誰でも学べる世界をめざしている。
横溝氏
BoostnoteはOSSで、おもいもよらない実装がコミットされることがある
・13:50【A-2】リアルタイム対戦バトルゲームを支えるリアルタイムサーバの負荷試験のリアル 叶 若帆 [gumi]
負荷試験
クライアントとサーバ
Arkサーバの負荷最適化
Arkサーバとは？
自社開発のリアルタイムサーバ
おもにTCP。
UDPも可能。
オリジナルな実装
メッセージのPub Sub機能
負荷試験の必要性
システムのQoS（Quality of Service）の把握
スループットとレイテンシを知るため
負荷クライアントの話
AWSで構成
同じネットワーク内に入れることで、名前解決を簡易に。
負荷クライアント名
Flood（洪水）:Ark（箱舟）に対して、負荷を与えるもの
情報を可視化することで、何が問題となっているのかを把握しやすくする
このように
改善その1
もっと性能が出せるでしょうと言われて、、
さらに性能向上について研究
・14:15【C-3】サーバーレス+SPAでつくる！ユーザーご意見管理システム
木村 尚俊氏 [ナビタイムジャパン]
NAVITIMEジャパン
ユーザ数5000万人
500人の社員のうち8割がエンジニア
導入背景
ユーザの意見に対して、コミュニケーションをとりながらロイヤリティの改善
意見を投稿、取得できるAPI
AWSを使う
これではコストがかかりすぎる
サーバレスを検討
コスト感
EC2インスタンスをAPサーバとして利用するには高いが、サーバレスなら社内OKがでる価格感
開発フェーズ
プロジェクトはQiita記事に公開
https://qiita.com/navitime_tech/items/70432345d930c2bc1a14
SPAはVue.jsを採用
・14:50【C-4】なぜサーバーレス「と」Dockerなのか 〜インフラ運用を最小化するサービス開発〜
小笠原みつき氏 JX通信社
ニュースをBtoBとBtoCでやっている
本番系システムをサーバレスで構築
初期のころは、sshで手動アップロードというひどい運用をしていた（小笠原氏談）
エンジニアの数＞システムの数なので、インフラ管理は楽に行いたい。
サーバレスとDockerの両方運用でやっている
→sshで手動アップロードはなくなった
lambda（AWSのFaaS）は常駐プロセスがないので、メモリリークもおこらず、管理コストが低く、運用の安定も高い。
IaaS/VPS時代より、かなり楽
Docker環境とサーバレスの比較。サーバレスは、たとえばlambdaだと15分しか稼働できない
両者はちょうど両極端の特性をもっているので、これらを組み合わせて運用
デプロイを行うには、サーバレスとDockerは両方必要
インフラエンジニアがいなくても、ほぼ問題なく運用ができている
・15:15【B-5】先端機械学習モデルを自社サービスに導入
森山 直人 [パーソルキャリア]
・15:40【B-6】自然言語でナビを！VUIとしてのカーナビ
本多 広晃氏 [ナビタイムジャパン]
OK GoogleやAlexa
と呼びかけるUXを先駆けてやっていた
従来の課題
・16:15【A-7】家電事業におけるデータサイエンティストの活動紹介～家電のIoT化から新規サービス創出に至るまで～
菊地 啓太氏 [パナソニック]
AIチャットボット ゆいちゃん すでにリリース済
家の材質属性をとらえないと、ただしい温度制御はできない。
複雑な要素を把握する必要がある。
・16:40【C-8】スマホアプリで次世代ARを実現する～ARKit/ARCoreの活用
朝日田 卓哉 氏 [Cygames]
壁は現実のもので、キャラクターはAR
ホロレンズを利用
現実側が静止しているなら問題ないが、
それが動くとなると難しい。
あえていうなら、現実側の動体に対しては赤外線などでセンシングする技術が必要。
・17:05【A-9】「簡単でつかいやすい」を追求する開発の裏側 ～メディア解析基盤の話～
松石 浩輔 氏 [ミクシィ]
家族専用写真共有アプリ みてね
コンテンツ開発チームは3人
開発2
研究1
コンテンツ自動生成のしくみ
ひと月7000万枚ほどの写真がアップロードされる
インフラはAWS
旧メディア解析基盤の問題点は、運用コストが大きい
3人でやっているサービスなので、k8s(kubernetes)までは利用せず
機械学習による推論部分の構成 ↓
手動オペレーションが少なくなった
・17:45【A-10】カベを壊せ！「機械学習」×「グラフデータベース」×「チャット」で繋ぐヒューマンリレーションシップ！！
一ノ瀬 翔吾 氏 [ドリーム・アーツ]
コミュニケーションの課題を克服するために作ったアプリ
関係性の解決のために、グラフデータベースを利用
グラフデータベースとは？
このような関係図を
このようにモデル化
Webhook＋Flaskはチャットアプリの定石的手法
・18:10【B-11】Docker/KubernetesによるCloud Nativeな開発と未来
青山 真也氏 [サイバーエージェント]
k8s=kubernetes
Dockerはやや下火になりつつある？（登壇者談）
最近はk8sを使ったクラウドネイティブなサービスが増えてきた
k8s → 構成情報はYAMLファイルとして記述
以下はnginxのコンテナ化を3つ作る例
Dev側でインフラ側の設定まで記述
DevとOpsの境目が小さくなってくる
k8sでは何かが起きたときに自動復旧する仕組みがあるので、運用コストを下げられる。
たとえばVMなどの場合には、ロードバランサをはずして、イメージをアップデートして、ふたたびロードバランサをつけるという手順が必要だが、k8sにはそれは不要
マイクロサービスのしくみ
分割することで、開発の効率化を図る
たとえばTwitterやNetflixは500個以上のマイクロサービスで成立している。これを分割せずに、ひとつのサービスとして開発しようとすると、コンフリクトが起きてとてもではないが開発ができなくなる。70個くらいのマイクロサービスが出てくると、分割したほうが開発効率が上がるといわれている。
銀行などでもk8sが使われてきている
k8sはクラウド界のLinuxに
まとめ
クラウドサービスを利用することで、いかにインフラ管理コストを下げられるかがウェブサービス運営の上では大切だということがわかりました。今回のカンファレンスではAWSを利用しているという話を多く聞きました。そして、コンテナ技術のデファクトスタンダードはkubernetesになりそうな勢いを感じました。（サービスや開発チームの規模感ももちろんあるのでしょうけれど、Dockerは通過点でしかない、むしろ下火という感じな雰囲気もあり）
機械学習については、論文を読んで最新の手法にキャッチアップし、それを自社サービスに取り入れるケースもあるようですが、API+従来のアルゴリズム（グラフアルゴリズム等）で、ユーザの満足するものができたりする。つまり、ありものの組み合わせでそれなりのものができるということです。機械学習はつまるところ統計なので、欲しい結果を得るためにどんなデータが必要なのかを見極めることが実は難しかったりもするようです。アプリの規模によってはFaaS（Functiion as a Service）によるサーバレスの利用もあり。Webサービス界隈ではクラウドはデファクトスタンダードになりつつある印象。
インフラはクラウド（AWS）、機械学習はありものの組み合わせ
全体としてこんな雰囲気を感じました。
・18:35 懇親会
自コミュニティ宣伝用LT
以上です