builderscon tokyo 2017 1日目 ~アウトラインメモ~
builderscon tokyo 2017に参加してきました。
参加したセッションのアウトラインメモを残しておきます。中途半端なメモのところもありますがそこはご愛敬ということで。資料が公開されているものはリンクを張っておきました。
※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい。
オープニング
- buildersconはYAPCの直系のイベント
- Discover somthing new
- 発見と知識を共有
Desktop Apps with JavaScript
- SlackでDesktopアプリを作っている
- チームは4人
- Windows7だと絵文字とかのサポートがつらいから早くアップデートしてw
- クロスプラットフォームアプリを作る理由
- JavaScriptで書かれたアプリはもう世の中にあふれている
- Electronについて
- Slackアプリの話
- ライブコーディングしながらElectronアプリを作るデモ
- Monaco Editorを使ったエディタアプリを作っていく
- シンタックスハイライトだけでなく補完も効く
- Electronアプリ上でOSのファイルシステムにアクセスできる
- これが怖い部分でもある
- Monaco Editorを使ったエディタアプリを作っていく
- テストはこの辺り使って行っている
所感
Slackの中の人の話を聞けるなんて本当に良い経験でした。
ライブコーディングが最高でした。Electronアプリの作り方の基本がばっちり理解でき、Electronで何か作ってみようと思わせる非常に良いセッションでした。
SlackではVideo Call部分はC++で書いているといっていましたし、パフォーマンス求められるようなアプリを作るにはやはりElectronだけではダメなんだろうなと思った次第。
なお、ライブコーディングしたサンプルは以下で公開しているそうです。
ブラウザ拡張のクロスブラウザ対応についてどう向き合っているか
- Gyazoのブラウザ拡張作っている
- ブラウザ拡張の状況
- Chrome Extensionと互換のあるAPIを利用した実装がFirefoxとEdgeに載ってる
- Firefox v57からWebExtensionのみサポートになる
- WebExtensions - MozillaWiki
- Chrome Extensionからの移行
- Chrome Extensionをそのまま他のブラウザに移行するといろいろな問題が起きる
- manifest.jsonと向き合う
- Browser compatibility for manifest.json - Mozilla | MDN
- ただしFirefoxの実装を元に書かれている
- manifest.jsonをブラウザ毎にフォーマットやバリデートしてくれるツールを作った
- GitHub - pastak/wemf: Format manifest.json in Chrome Extension, Firefox WebExtension and Extension for Edge
- 地道に変換していく
- Browser compatibility for manifest.json - Mozilla | MDN
- APIのオブジェクト名が違う問題
- Chromeはchrome、Edgeはbrowser、Firefoxはchrome,browser両方いける…
- GitHub - pastak/chrome-browser-object-polyfill
- Polifill作った
- しかもFirefoxだけPromiseを返す
- chromeオブジェクトもPromise返すやつを作った
- GitHub - pastak/then-chrome: Promise-based chrome-api
- GitHub - pastak/chrome-browser-object-polyfill
- Chromeはchrome、Edgeはbrowser、Firefoxはchrome,browser両方いける…
- 未実装のAPIどうするか
- その他
- popup.html内のCSSとかの対応状況はWebアプリと一緒なので頑張る
- Edgeの拡張を作る意味あるのか?ユーザーいないのでは?
- クロスプブラウザ対応のExtension作るのどこまでいけるの?
所感
私自身ブラウザ拡張機能はいくつか作っていたりするのですがクロスブラウザ対応するという考えは今まで考えたことありませんでした。そういう意味でなるほどなーと考えさせられました。
ちゃんとしたサービスのブラウザ拡張を仕事で作っていないと出てこない考えだよなーと。個人で作ると、正直自分のメインブラウザだけ対応すればいいやってなっちゃいますからね。
自分のブラウザ拡張をクロスブラウザ対応してみようという気持ちがかなり高まりました。
自分でクロスブラウザ対応するためのツールを色々作っているのもすごいですね。便利そうなので使ってみたい。
Haskellを使おう
- Stack
- cabel-installに変わるビルドツール
- プロジェクト間の依存パッケージのバージョン違いを適切に扱ってくれる
- Stackage
- Hoogle
- 関数名、型名とか検索できる
- 日本HaskellユーザーグループのSlackの#questionで質問受け付けている
- 本出す
- Haskell入門、9/27発売予定
- I/O処理
- あんまり得意ではない。が、苦手というほどでもない
- I/Oモナド
- do記法のコツ
let x = ...
とx <- ...
を使い分ける- 冗長でも
<-
で別の変数に束縛してから使う
- HaskellではI/Oはモナド
- モナドを使ったプログラミングが必須
- モナディックなAPIの読み方
- なぜHaskell使う?Goじゃだめなの?
- GHC使うとパフォーマンスを担保できる
- Goと比べると型システムが優れていて抽象度の高いコードが書ける
所感
すごいH本を過去に1度読んだだけの私にはなかなか理解がキツかったです…
Haskellではモナドを理解しないとダメなことが良く分りました。モナドが曖昧になっているのでこれを機にすごいH本を読み直そうと思いました。
RDBアンチパターン リファクタリング
- データベースの寿命はアプリケーションより長い
- 最近はDBのチューニングはマネージドサービスがやってくれる
- でも、設計は自分たちでやる必要がある
- データは生き物、基本的にdeleteよりinsertが多い
- RDBアンチパターンを見極めるのが大事
- 不吉な臭いを見極められるように
- Softwear Designで連載してるから見てね
- 何をリファクタリングするかはアプリの特徴によって変わってくる
- データベースリファクタリングはすごく長くなる→戦うための準備が必要
- 「モニタリングのないオペレーションはテストのないコードと一緒である」→モニタリングは超大事
- DBを止めるのは難しい
- 停止時間を限りなく短くすることはできる
- サービス停止の壁は政治と技術の両方で解決する
- データベースリファクタリングするだけの価値があるか見極める
- 意味はあるのか
- 作業に応じた効果があるのか
- 今やるべきか
- 小さい変更を長いスパンで繰り返す
- 欲張らない、一気にやりたい気持ちを抑える
- DBは影響範囲が広いので切り分けできるように
- 金で殴る
- 金の弾丸
- DBはお金の力でなんとかなることも多い
- 1度作ったDBは消せない
- RDBの知識は寿命が長い
- 1度覚えれば長く役立つので勉強の費用対効果が高い
所感
過去のスライド等に目を通していたので、内容はだいたい知っていたのですがやっぱせっかくなので生で講演を聞こうと思って参加。プレゼンもうまく非常に楽しませてもらいました。
RDBのリファクタリングは技術や政治の力が必要だけど「覚悟」も大事。
しかし、やっぱアプリの要はDBですね。DB知らないでアプリは作れん!と改めて思いました。DBエンジニアの方は偉大だ。
RDBは学習の費用対効果が高いというのはごもっともだと思いました。今をときめく機械学習系のライブラリやVR技術なんかは10年後どうなっているか予測できませんが、RDBが10年後に無くなっているとは到底思えませんからね。
1日目はこんな感じでした。「知らなかった、を聞く」ことができて非常に満足度高いです。 明日も楽しみです。