builderscon 2018に参加してきた
今年もbuildersconに参加してきました。
参加したセッション内容のメモと簡単な所感、全体所感を書き残しておきます。資料が公開されているものはリンクを張っておきました。
※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい。
去年の感想。
- 全体所感
- 本編1日目
- 本編2日目
- 「Web とは何か？」 - あるいは「Web を Web たらしめるものは何か？」 - Idea of Web
- 証券トレーディング業務におけるExcel依存を脱却するプロジェクトで直面した技術的選択とプロジェクト運営の失敗
- なぜエンジニアはパフォーマンス計測しないのか
- 業務時間で書いたパッチは誰のもの？ OSS 活動にまつわる罠
- なぜ私はキーボードを作るのか
- LT
- キーボードをカスタムしてプログラミング環境を良くした話
- スーパーファミコン開発ことはじめ
- Micorservices-friendly data pipeline
- WebReplayから見るWeb開発の未来
- チームでテストを書くために
- capanfileがRubyパースできることに気づいた俺たちは
- こんな現場でやってられるか
- 5分でフォトブース
- Development Tools for Next Generation
- アップデートばかりしている言い訳をさせてくれ
- 登壇やLTを始めてみたい」方の背中を押してみたい
- iOSDC Japanを本物のインターネットを提供した話
- Node.jsでCloudFormationのテンプレートを分割して管理する
- ネットワーク障害を支配したい話
全体所感
メモが長いので全体所感を先に。
今年も「知らなかった、を聞く」が実現されている素晴らしいカンファレンスでした。色んな文化の人が出会える素敵な場です。
本当に色んな内容の話がありどのコマもどれを聞こうかという悩みが発生します。ゲストスピーカーも豪華ですしまさにフェスだと思います。
ここのところ業務であまり技術的なことができていないということもあり、気分をリフレッシュさせる気持ちで今回は参加しました。今回参加したことで技術の楽しさを再認識できましたし、自分はやはり何かをエンジニアリングで解決することが好きなんだなーということも再認識できました。何かを作りたいという気持ちも高まりました。とてもよい機会をいただき感謝の気持ちでいっぱいです。
最後に、運営で気になる点があったので改善の余地がある点を書いておきます。
- 去年に比べ記念ホール以外の各部屋が満席になるのが早かったように感じました。セッション終わってトイレへ行って次の部屋に行くとすでに立ち見であったり満席で入れないことが何度かありました。この辺りの調整は難しいとは思うのですがちょっと残念でした。もう一部屋くらい確保して溢れた人が休憩できる部屋とか用意できるとよいかもしれません。そこで新たな交流もうまれるでしょうし。
- セッション内で質問した時に、初めの方から手を挙げてるのに後から手を挙げた人に先にマイクを渡してどんどんスルーされ、なかなか質問できないということがありました。手を誰が挙げてたなのかを覚えておくのはなかなか難しいとは思うので立ってもらっておくなどの工夫が必要だと思いました。
- クロージング時のじゃんけん大会からベストスピーカー発表まで身内感がかなり出ていて参加者を置いていけぼりにしていたように感じました。その後、コミュニティのあり方についての素晴らしい話があったのに説得性が欠けるものになってしまっていました。ワイワイしている時は身内感が出てしまうのはしょうがないと思うので運営の一人一人が意識するしかないように思います。
色々書きましたがこれだけのカンファレンスを毎年続けているということは大変ありがたいですし、素晴らしいことだと思います。今後も楽しいカンファレンスを期待しています！
運営の皆様、発表者の皆様、参加者の皆様、楽しいカンファレンスをありがとうございました！
本編1日目
Electronによるアプリケーション開発事情2018
資料 : builderscon2018.pdf - Speaker Deck
内容
- MastdonクライアントをElectronで作った
- リリースに関して
- electron-builderがあればだいたいのことは解決する、マジ便利
- electron-userland/electron-builder: A complete solution to package and build a ready for distribution Electron app with “auto update” support out of the box
- electron-packagerというのもあるがそれよりelectron-builderがお勧め
- アプリのパッケージ、証明書の追加、各種インストール形式に圧縮、設定がpackage.jsonで書ける
- Mac App Store用にパッケージングするにはいろいろ大変...
- electron-builderがあればだいたいのことは解決する、マジ便利
- なぜMastodonアプリを作ったのか
- デスクトップ向けのクライアントが少なかったから
- Whalebirdのコンセプト
- Slackに慣れてるのでそれっぽい感じに
- Mediumに英語で記事書いたら海外から反応が
- いいアプリだけどElectronだから減点、みたいな意見が
- Electronが嫌いな理由
- メモリ消費が多いという意見が多い
- メモリ消費をなんとかしよう
- megalodonというmastdon APIクライアントライブラリも作った
- TypeScriptで実装
- TypeScript最高
- ElectronアプリもTypescriptで書けば良かった...
- Electronのセルフアップデート機能使うとAppleの審査に弾かれるので使っていない
所感
個人でプロダクトを作ってそこから普段の仕事では使っていないいろいろな技術を学んでいく姿勢が素晴らしいと思いました。英語で記事を書いて海外ユーザーを引き込むスタンスも素晴らしいです。あと、vue-cliでVueを使うElectronアプリの雛形を作れることは知りませんでした。
electron-builderが相当便利なことが分かったので、Electron使う機会があったら使っていきたいです。
パスワードレスなユーザー認証時代を迎えるためにサービス開発者がしなければならないこと
資料 : ritou_user_authn_builderscon_tokyo_2018 - Speaker Deck
内容
- パスワード認証
- 特定デバイス不要の最強の認証方式、のはずだった
- 現実には使い回し、サービス側の運用方針にユーザーが振り回されるという現実
- やめるべき理由
- ユーザーへの負担（ユーザーのスペック不足www）、サービス側のリスク/コスト
- 現状
- 最新動向
- FIDO2.0
- UAF + U2F
- FIDO1.0までバラバラの仕様だった
- Web Authn API
- FIDO2.0のWeb API仕様
- ここで試せる → WebAuthn demo
- 定着するまでに必要なこと
- ブラウザの対応、Authenticatorの普及、ユーザーへの啓蒙
- FIDO2.0
- 課題と対策
- どのようにしてパスワードレスを実現できるか
- 新規サービス
- パスワード認証を使わない
- 既存サービス
- パスワード認証を使うのをやめる
- 新たな認証方式の提供、新たな認証方式への移行、パスワード認証の撤廃
- パスワード認証を使うのをやめる
- 新規サービス
- 課題
- どの認証方式を使うか
- UXが変化する
- 登録フローが変化する、ログインフローが変化する
- パスワード確認相当の処理をどうするか
- どの認証方式で代替するかの決めが必要
- どのようにしてパスワードレスを実現できるか
- まとめ
- パスワード認証を安全に運用するのは困難
- WebAuthnによる新しい認証方式はすぐそこまで来ている
- #idcon - Identity Conferenceというコミュニティがあるので興味がある人はぜひ
所感
パスワードレスな認証の現状や関連技術のさわりについて丁寧に説明されていました。話を聞いているとパスワード認証をなくすのは技術的な話よりも人々のマインドを変えることの方が難しそうだなと思いました。
また、UXが変化するというのはあまり意識したことなかったですが確かにそのとおりですよね。
Authenticatorは果たしてあとどれくらいで普及してくるのだろうか？エンジニアが多い身の回りでもyubikey使っている人少ないのでまだ相当かかるだろうなあ。
Webサービスにて200週連続で新機能をリリースする舞台裏
資料 : Webサービスにて200週連続で新機能をリリースする舞台裏 / builderscon tokyo 2018 - Speaker Deck
内容
- Mackerelを200週連続でリリースしてきた話
- 連続リリースの定義
- ユーザーにとって価値のある機能をリリースする
- バグフィックスやメンテナンスリリースは含めない
- 何のためにやっているのか？
- 機能開発のスピード感が価値のひとつであり優位性だった
- 最初は連続リリースを意識していなかった、気づいたら50週いってた
- 毎週連続リリースをアピールしたら顧客獲得の大きな武器となった
- どうやって維持したか
- 続けるコツ
- 毎週告知をチームの最重要コミットメントと位置づけ、チーム全員がそれを目指す
- 毎週リリースをやめた理由
- 主な機能が出そろった
- スピード感より腰を据えた機能開発の方が顧客にとって大きな価値となるフェーズになったと判断。スタートアップ機の終了
- 毎週リリースを終えてみて
- 足回りの改善がやりやすくなった
- Playframweork、Scala、sbtのバージョンが一気に新しくなった
- 足回りの改善がやりやすくなった
所感
バグフィックスやメンテナンスリリースは含めずに、ユーザーに価値のある機能だけをこれだけの期間毎週リリースしてきたのは本当にすごいと思います。チーム作りもいろいろと試行錯誤があったかと思いますが工夫したんだろうなあと。
バックログに対してエンジニアの100%稼働を求めないで20～30%は余力が残るように計画するというのは本当に大事だと思います。（そうしようと思いつつなかなかできないのですが...）
あと、プレゼン資料の構成がとてもうまいと思いました。
daiksyさんのプレゼン構成はいつもとてもうまいなあと思う。内容がすっと入ってくる。何について話しているのか分かりやすい構成なんだろうな。
— uenot (@braitom) September 7, 2018
イノベーションを止めずに、端末管理と運用を行う方法
資料 : イノベーションを止めずに、端末管理と運用を行う方法 - Speaker Deck
内容
- なぜ端末管理するのか？
- ライセンス管理
- 稼働状況の確認、棚卸しなどコスト削減につなげるため
- 情報セキュリティ対策
- 不正利用対策
- 端末管理するからには目的を明確にする必要がある
- 念頭に置くこと
- 管理方針
- 懸念における対応が未定義ならきつめに設定
- 端末はなくしてしまう前提で設計
- macOSの管理
- プロファイルマネージャーというものがある
- auditログが読みづらいのでosqueryで取得してElasticSearchに入れる
- google/santa: A binary whitelisting/blacklisting system for macOS を使うなど
- Windowsの管理
- Azure ADとIntune
- Winlogbeatとosqueryで監査ログ取得してElasticSearchに入れる
- iOSの管理
- Androidの管理
- managed Googly Play
- ビジネス部門と管理部門のバランスが大事
- 要望をちゃんと受けていくスタイル、代替案を提示していくスタイル
- 一方的に締め作るのはダメ
- お互い歩み寄っていく姿勢が大事
- 要望をちゃんと受けていくスタイル、代替案を提示していくスタイル
所感
知見が共有されることが少ないデバイス管理系の話ということでとても参考になりました。端末管理をするにしても目的が大事で、何のためにその設定をするのかを忘れないようにすることがとても大切ということが伝わってきました。人はミスを犯すという前提で設計しないといけないこともなるほどなあと思いました。
Macの管理はとてもツラそう...でも色々なサービスやOSSを組み合わせて仕組みを作る感じはエンジニアリング感があってちょっと楽しそうかも。
また、気になったので以下の質問をしてみました。
- Q: 今後人数が増えていってもこの方法で運用が回るか？ライセンス費などもかさんでくると思うがペイできるか？
- A: できると思う。なるべく工数をかけない方向で努力している。人数増えてきたら外部の会社にお願いすることも検討すると思う。本当に必要なのはみんなの要望に対応するための時間を確保しておくこと
この質問をした意図としては人数が増えると運用負荷とライセンス費用がどかっと上がると思っているからです。また、ビジネス部門と管理部門のバランスの話をされていたのですが、人数が増えると色々な考えを持った人がどんどん増えていくということなのでこのバランスを保つためのコストもどんどん高くなってきます。そんな中でこの仕組みを続けていけるのだろうか？と疑問に思った次第です。
lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話
内容
- lldの紹介
- リンカとは
- オブジェクトファイルを1つの実行ファイルやDSO(DLL)にまとめるプログラム
- 開発のきっかけ
- どうやったか
- 何かが間違っていても全くヒントがない
- バイナリをプリントアウトして考える、バイナリを理解できるよう。とりあえずOSにロードされるように頑張った
- Hello Worldがリンクできるようになるまで数ヶ月、大きなプログラムがリンクできるまで1年くらいかかった
- リデザインのポイント
- 難しくし過ぎない
- 不自然な最適化はしない。自然と性能が出るように書く
- データ構造こそが重要
- 速くてシンプルなコードを書くために
- 良いデータ構造にするのが重要、データが先、コードは後
- 2回書く。1度目の経験を2度目に生かす
- 最適化する箇所を最小にとどめる
- 終わりに
- 問題についてよく考えて自分がよいと思うやり方を勇気を持って試してみる
- 存在しない問題を作りだしてそれを解決しようとするのではなく、元々の問題を直接解決できないのかよく考える
- カーゴ・カルト・プログラミングしない
- 理不尽なものは受け付けない
所感
まさに自分にとって「知らなかった、を聞く」セッションでした。
リンカを使うことはあってもそれを実際に作ることなんて考えたこともなかったのでどういう考えでつくるのか、どういう苦労があるのかが分かりこういう世界があるのかーと思いました。プログラマとしての生き方、考え方をあらためて考えさせられました。
あと、なんというか考え方とかすごいなーと聞いていて終始思っていました。
いやー面白かった。スーパーエンジニアがどう考えながらものごとを設計していくのか、解決していくのかが伝わってきた。考え方すごいなー。所々、勘でやったとか天才感はかなりあったけど。
— uenot (@braitom) September 7, 2018
このtweetがまさにこのセッションのすごさを表しているなーと。
るいさんのセッション大変良かった。伝説のロックバンドのライブを見た気分。ライブビデオを発売して欲しい。10年後、若者に「おじさんこのセッション生で見たんだぜ」て自慢したい。#builderscon
— ぎゃばん@並列プログラミング (@ledsun) September 7, 2018
本編2日目
「Web とは何か？」 - あるいは「Web を Web たらしめるものは何か？」 - Idea of Web
内容
- Webは進化しているが本当に正しい方向に進化しているのか？それを誰がバリデーションできるのか？
- Webに関わる視点
- Webを使う人たち、Webで作る人たち、Webを作る人たち
- 最初はティムバーナーズリーが論文を共有したいということから始まった
- HTML,HTTP,URL
- WebのApp化
- Cookie,Form,JS,iframe など
- Ajaxの登場
- Originの登場
- HTML5の登場
- アプリケーションを作るには貧弱すぎた
- データ保存できない、動画も音声も再生できない、線すら引けない etc
- Webは文章を共有するものではなくなった
- それはWebに本当に必要か？
- Contents Use Caseで議論すると失敗する
- 自分にとって必要/不要みたいな議論になる
- Functional Use Caseでの議論に移りつつある
- 互換性とセキュリティモデルが議論できるか
- Contents Use Caseで議論すると失敗する
- それはWebに本当に必要か？
- Extensible Webの話に
- アプリケーションを作るには貧弱すぎた
- アプリケーションプラットフォームの限界
- WebのOS化
- ここもFunctional Use Caseで議論
- OSのセキュリティモデルがWebにはない
- 安全なデバイスアクセスを実現するセキュリティモデルが必要
- Permissionの導入
- Hyper Media System → Application Platform → Operating System と変化
- Webは時代の要求に応じて変化する
- WebがWebとして壊れないために必要なモノを模索
- 今はWebにとって重要な過渡期
所感
WebのはじまりからAjax、HTML5、Deviceアクセス系のAPIがどういう経緯で登場してきたのかがセキュリティモデルの考えを絡めて丁寧に説明されていてとても勉強になりました。 「Hyper Media System → Application Platform → Operating System」という流れで進化してきており、これによりWebを支える技術で書かれている以上のことが必要な時代になってきていることがよく理解できました。個人的にはベストセッションでした。
「WebがOSに近づくという流れはOSがWebでいいじゃんって話とも言える。GoogleがChrome OSやってるのはその流れ」というのもなるほどなーと思いました。それを聞いてあらためて考えるとやっぱGoogleってすごいなという気持ちになってきました。ブラウザもOSも持っているわけで。WebとモバイルアプリとOSの境目をユーザーが分からないような世界を作れるのはやっぱGoogleなんだろうなーと。
証券トレーディング業務におけるExcel依存を脱却するプロジェクトで直面した技術的選択とプロジェクト運営の失敗
資料 : 公開なし
内容
- Excelはツラい、脱却しようとしてもツラかった
- 証券トレーディング業務とExcelの関係
- Excel脱却プロジェクト
- プロジェクトアンチパターン
- 上から降ってくる技術的選択、大きめの選択
- 政治力の及ばない相手との共同作業
- 短すぎる納期
- 既存ワークフローのいいところを無視
- 後から明らかになる要求に対応できない体制
所感
これは確かに資料公開もビデオ撮影もできないよな、というとても香ばしい内容でした。こんなにツラい案件をやっている人もいるんだと元気をもらいました。
やはり、こういった失敗プロジェクトの事例の共有はありがたいですね。とても参考になりますし、色々と考えさせられます。政治的な話はどうにもならないと逃げずにできる限りのことはやって、大爆死せずにいかに怪我を少なくできるかを考えていくのが大事だと思っています。
また、プロジェクトの進め方をもうちょい工夫すれば大爆死は避けられたのではないかと思いました。
結局マネージャーがいろいろサボったってだけの話に見えてきた。そもそ何で作るの？含めメンバー含め考えた方が良かっただろうし、社内政治やステークホルダーとの調整をサボったのも原因のように見える。 #builderscon #buildersconC
— uenot (@braitom) September 8, 2018
なぜエンジニアはパフォーマンス計測しないのか
資料 : why_dont_you_measure_your_performance - Speaker Deck
内容
- これと結構かぶっているとのこと
- ガジェットを駆使して自分を測る
- 結果を言うと体重減ったり、体脂肪減ったりで効果が出たことは出た
- プライベートでコードを書くようになったのも1つの成果
- 7年のログからみる自分の傾向
- 仕事が忙しくなると太る
- プライベートが不安定になると太る
- やる気がでないという問題も科学的アプローチで解決できるのでは？
- ありとあらゆるものを測定することに
- Withings Wifi body Scale
- Withings Activate
- Withings Sleep
- GoBe2
- Spire
- ZOZOスーツ
- キーボードのタイプ数
- 取ったデータを全てFirebaseに集約していく
- グラフを色々表示するUIも作成
- 睡眠時間と集中度の関係見たが相関あるのかないのかよく分からなかった...
- 人体ABテスト
- 朝ごはん食べる/食べない、カフェイン制限、朝運動してみる、満員電車に乗る、断酒
- どれもあまり数字に出なかった...
- 改善策
- 睡眠
- 食事
- 16時間断食
- 栄養を考える
- お勧めの間食
- 欲しいも、ナッツ、ブルーベリーなど
- 運動
- ジム通い、パーソナルトレーニング、歩く
- タバタトレーニング
- 脳機能改善にはトレイルランニングとクロスフィット
- 開発環境
- 立って開発
- Ergodox導入
- 机の下にステッパー導入。歩きながらコードを書く
- そんなに計測する必要あるの?
- ぶっちゃけ指標に関する数値は1つでよいと思う
- 自分の体のことは自分から学ぶしかない
- 自分の人生を自分で決める
- やる気を出すのではなくやる気が出る状態を作る
所感
これはネタ枠だから！、本当に立ち見してまで聞くこと？と心配そうな感じでしたがきちんと自分の問題を解決するためにエンジニアリングしていて素晴らしい発表だったと思います。
私もいろんなガジェットを買ってデータだけは集めているのですがほとんど分析できていないので見習おうと思いました。
これだけデータが貯まっているのでデータ分析系の話と組み合わせた何かをすると、昨今の機械学習ブームもあるのでもっと色々な人にアプローチできるかも。
業務時間で書いたパッチは誰のもの？ OSS 活動にまつわる罠
内容
- 業務で書いたパッチ投稿に潜む罠
- このパッチは社外公開してよいのか？
- 誰に許可を取ればいい？
- 何名義で公開すればいいの？
- CLAへの署名を求められたら？
- 趣味で書いたOSSを業務で改善するときの罠
- 業務時間を趣味OSSに使っていい？
- パッチの著作者は誰のもの？
- 会社のコードを混ぜたくない
- サイボウズのポリシー
- 策定の背景
- 著作権
- 極秘情報を含むもの、上長の明示的な指示または承認のもと作成されたものは会社に帰属する
- その他は社員個人のものとなる
- 趣味OSSへのパッチも自分のもの
- 業務で書いたときは会社のもの、本体に取り込まれたら個人のもの。
- 新規OSSは許可不要
- CLA同意を求められたら会社を代表して署名してよい
- 参考にした企業
所感
こういうポリシーを策定できるのはさすがサイボウズさんだなと思いました。 OSSに関する方針を会社としてしっかりと考えてポリシー作っているということは以下のような利点があると思います。
- 働いているエンジニアからしたら自分たちのことをきちんと理解してくれていてありがたいと
- 外から見たらエンジニアの取り組みを支援している素晴らしい会社、かつライセンス周りについてもきちんと理解している会社であると感じる
利点しかないですよねほんと。このポリシーを決めるにあたってきっと内部的にはいろいろと揉めたこととは思いますが、却下とならずにきちんとこうやって成果として出てくるのはさすがだなと思います。
これをきっかけに日本の企業も自社のOSSポリシーを持つのが当たり前になるとよいですね。セッション聞いた後、以下のようなことをモヤモヤと考えていました。
会社のOSSポリシー絶対必要だよなー。自分のところでやるとしたら、OSSは無料で使えるものでしよ？みたいな変な考えの層がそこそこいそうなのでそこから変えないとだなーとボンヤリ考えている #builderscon
— uenot (@braitom) September 8, 2018
なぜ私はキーボードを作るのか
資料 : なぜ私はキーボードを作るのか_builderscon2018 - Speaker Deck
内容
- キーボードを作るまで
- 肩こりがひどい
- Helixが社内で流行っていた
- HHKB2台使いに
- メリット: 何も自作しなくて良い
- デメリット: でかい、キー設定いじらないと無力
- キーキャップ選べるの楽しそう
- 自作キーボードについて
- 2種類ある
- 誰かが販売するPCBを用いて組み立てるもの
- ErgoDoxとかHelixはこっち
- PCBから自作するもの
- 誰かが販売するPCBを用いて組み立てるもの
- PCBとは
- プリント回路基板
- 2種類ある
- パーツ選定について
- 自作キーボードやらかし集
- 失敗はつきもの
- 失敗をおそれず色んなキーボードを自作してほしい
- 一歩先へ
- フットペダルつけてキースイッチを割り当てる
- なぜキーボードを自作するのか？
- 自分に道具を合わせるという考え方
- 既製品は自分を道具に合わせることになる
- 自分に道具を合わせるという考え方
所感
自作キーボード愛を感じるセッションでした。自作キーボードは一度やってみたかったので色々と参考になりました。 特に失敗事例の紹介はとても参考になると同時に、ハンダ付けのワザがやっぱ要求されるのかーとやはりちょっと尻込んでしまう自分が...
Helix買ってみようかなー。
LT
キーボードをカスタムしてプログラミング環境を良くした話
- Elixir好き
- 特にパイプ演算子が大好き
- パイプ演算子は格好いいけど最高に打ちにくい
- よし、キーマップ書き換えよう
- GitHub - qmk/qmk_firmware: keyboard controller firmware for Atmel AVR and ARM USB families で書き換える
- 3回入力が必要だったのが1回に！
スーパーファミコン開発ことはじめ
- なんかゲーム作りたい
- 25年以上前のもだし今ならなんとかなるでしょ → ならなかった
- いろいろ頑張ったけどツラい
- コンパイラか言語を自分で作るしかない！
- To Be Continue
Micorservices-friendly data pipeline
- マイクロサービス化が進むとデータが多くなってくる
- 中間層にデータパイプライン作ろうと試みている
- バッチとストリームのパスを用意
- まだプロトレベルでいろいろ考えているところ
- 中間層がモノリスになってしまうのでは？という不安も
WebReplayから見るWeb開発の未来
WebReplayから見るWeb開発の未来 #builderscon - Speaker Deck
- いわゆるTimeTravelDebugging(TTD)
- デバッグの巻き戻しが出来る
- 最近Firefoxのnightlyに入った
- クライアントサイドのバグ再現のためにある
- 現状まだ使うには厳しい...
- Web開発の未来がある機能な気がする！戻りたかったあの頃に戻れる！
チームでテストを書くために
資料 : チームでテストを書くために / To write test code with team members - Speaker Deck
- テストがない状態からテストを導入した話
- まずは経験を積んでもらった
- 先導する
- 敷居を下げる
- 効果を実感する
- 現在ではチーム全員がテストを書くように
- 知識と経験を付けるの大事
capanfileがRubyパースできることに気づいた俺たちは
こんな現場でやってられるか
5分でフォトブース
Development Tools for Next Generation
資料 : Development Tools for Next Generation - Speaker Deck
- ChromeBookで使えるエディタがない
- ないから自分で作ってる
- Next Editor
- Editor with Git
- 目標
- Git for Everyone
アップデートばかりしている言い訳をさせてくれ
登壇やLTを始めてみたい」方の背中を押してみたい
資料: 「登壇やLTを始めてみたい」方の 背中を押してみたい - Speaker Deck
- 自分も社内外の人から背中を押してもらってきた
- 背中を押して上げる
- アウトプットで学べることを教えてあげる
iOSDC Japanを本物のインターネットを提供した話
- 会場からdwangoのデータセンタへ雑に繋いだ
- 設計をどうするか？構築をどうするか？機材をどうするか？
- 牧さんの会社endeworksでネットワーク機器レンタルしている！
Node.jsでCloudFormationのテンプレートを分割して管理する
資料 : Node.jsでCloudFormation_のテンプレートを分割して管理する.pdf - Speaker Deck
- CloudFormationはテンプレートが大きくなりやすい
- 分割して管理したい
- S3にテンプレートを置く方法があるがめんどう
- 作った
- 見通しが良くなってめんどくささがなくなった
- honoka-api-base
ネットワーク障害を支配したい話
資料 : ネットワーク障害を支配したい話
- システム監視のリプレイス中にテストしたい
- 受け身じゃなく先手をうてるようになりたい
- iptableやtcで素振りできる
- もっと便利なものは？
- Chaos Engineering的な話
- 色々なツールがあるので素振りしていこう
