YahooTechConferenceのメモ

 YahooTechConferenceのメモ。少し時間がたってしまったけど。
 内容としてはk8sをサービス化というのが、やっぱりDockerを追っている身として面白かった。Dockerがk8sを取り込んだが、そうなる前、すでに三年ぐらい前からk8sをサービス化するものを開発していたとのこと。というのを考えると、バックエンドやらフロントエンドやらどこかはわからんけど、すでにどこかで「次」が来ているんだなぁと思うなど。

Kotlinの導入と展望
==================
C 14:00-
 Kotlinはけっこうというかかなり短く簡潔に書ける。


なぜKotlinを入れるか
・desugar問題
・Swiftと似ている→iOSエンジニアと相互理解を深められる。実際深まった
・イベントハンドリング、通信、非同期処理が簡潔に書ける

Kotlinを入れるリスク
・学習コスト
・ビルド時間が増加しない?
・既存のCIパイプラインが継続して使えるか

Kotlin in Actionは学び初めによさげ

実際に導入するルール
・単純にKotlin置き換えをするタスクは積まない

一日かけてチームでToDoアプリを作って勉強(ToDoなのはDBキャッシュや非同期処理などいい教材になるから。それで十分にそれ以降の開発をキックできた)

ペアプロで

Kotlin導入結果
・導入直後からメンバーがKotlinに好感触
・Swiftコードも読めるようになった
・CIパイプラインはそのまま動いた
・サーバサイドKotlinへの流れが生まれた(Springが使える)

技術導入はトップダウンでやるのは危険。それぞれのプロジェクトで環境も要件も違うのだから、求めるものも違う。



PaaSな開発基盤
==============
A:15:00-
 最適化のためにPaaS化していきたい。
 CloudFoundry→PaaS
 Conなんとか→CI/CD

CloudFoundry→OSSのPaaSプラットフォーム
プライベートPaaSってことか

Coucourse→OSSのCI/CDプラットフォーム
CloudFoundryと連携が良好


アジャイルマニフェスト:継続的な価値の提供を提供したい、すべき
デリバリの時間を短くしていく
継続的デリバリは早さだけではなく安全性も達成させてくれる
複雑な問題は出来事から学んで対応する

半自律チーム
 理解の共有
 相互機能、バランス
 素早い判断
 ぶっといコミュニケーションバンドワイズ

昨日までの開発者
 仕様を読む
 コードを書く

明日の開発者
 聞く
 コミュニケーション
 テストを書く
 コードを書く
 デプロイ
 学ぶ
 Reflect

テストかけ、ユーザサーベイやれ、CI/CDやれ

実験的思考
 ちーむでいろいろ試す
 間違ってもいいんだという意識の共有
 →その後に間違いを防ぐ仕組みを作れたらとてもいい。とくに自動化とか人の手を介さない方法を導入するとかって方向で

カルチャーは実際みんなで働いている毎日というのが反映される

アプリケーションの高速デプロイを可能にする技術(k8s)
===================================================
C:16:30-

社内向けにContainer as a Serviceな部署がある
コンテナ化のメリット
 ライブラリ、パッケージの依存関係がコンテナ単位
 パッケージング、デプロイも

k8s
 スケーリング、オートヒーリングが可能
 コンテナのデプロイ、スケーリング、管理

社内でKubernates as a Seriviceなるものがあって、管理が楽になっている

もともとVMの管理コスト増加があった
メンテとかで開発にリソースが割けなくなってきていた

まずはローカル環境から導入した

k8sのデータを入れているetcdというkvsがある。k8sをサービス化したかったらこれのバックアップとか考えなきゃいけない。
Yahoo
comment: 0