builderscon tokyo 2017 1日目 ~アウトラインメモ~

builderscon tokyo 2017に参加してきました。

builderscon.io

参加したセッションのアウトラインメモを残しておきます。中途半端なメモのところもありますがそこはご愛敬ということで。資料が公開されているものはリンクを張っておきました。

※一部、私個人の解釈でメモしているものもあり、発表者の方の本来の意図とズレているものがあるかもしれませんがご了承下さい。


オープニング

  • buildersconはYAPCの直系のイベント
  • Discover somthing new
  • 発見と知識を共有

Desktop Apps with JavaScript

  • SlackでDesktopアプリを作っている
    • チームは4人
  • Windows7だと絵文字とかのサポートがつらいから早くアップデートしてw
  • クロスプラットフォームアプリを作る理由
  • JavaScriptで書かれたアプリはもう世の中にあふれている
  • Electronについて
    • Node.js + Chromium(レンダリングエンジンの部分だけ) + C++(OSネイティブ機能)
    • Main ProcessとRenderer Process間での通信が可能
  • Slackアプリの話
    • Electron、TypeScript、C++
    • 複雑な部分(全体の5%くらい?)はC++使っている。Video Call部分とか。
  • ライブコーディングしながらElectronアプリを作るデモ
  • テストはこの辺り使って行っている

所感

Slackの中の人の話を聞けるなんて本当に良い経験でした。
ライブコーディングが最高でした。Electronアプリの作り方の基本がばっちり理解でき、Electronで何か作ってみようと思わせる非常に良いセッションでした。

SlackではVideo Call部分はC++で書いているといっていましたし、パフォーマンス求められるようなアプリを作るにはやはりElectronだけではダメなんだろうなと思った次第。

なお、ライブコーディングしたサンプルは以下で公開しているそうです。

ブラウザ拡張のクロスブラウザ対応についてどう向き合っているか

speakerdeck.com

所感

私自身ブラウザ拡張機能はいくつか作っていたりするのですがクロスブラウザ対応するという考えは今まで考えたことありませんでした。そういう意味でなるほどなーと考えさせられました。
ちゃんとしたサービスのブラウザ拡張を仕事で作っていないと出てこない考えだよなーと。個人で作ると、正直自分のメインブラウザだけ対応すればいいやってなっちゃいますからね。
自分のブラウザ拡張をクロスブラウザ対応してみようという気持ちがかなり高まりました。

自分でクロスブラウザ対応するためのツールを色々作っているのもすごいですね。便利そうなので使ってみたい。

Haskellを使おう

speakerdeck.com

  • Stack
    • cabel-installに変わるビルドツール
    • プロジェクト間の依存パッケージのバージョン違いを適切に扱ってくれる
  • Stackage
  • Hoogle
    • 関数名、型名とか検索できる
  • 日本HaskellユーザーグループのSlackの#questionで質問受け付けている
  • 本出す
  • I/O処理
    • あんまり得意ではない。が、苦手というほどでもない
  • I/Oモナド
    • PythonとかPHPなどと同等の機能を提供する
    • 入出力、ミュータブル変数、例外
  • do記法のコツ
    • let x = ...x <- ...を使い分ける
    • 冗長でも<-で別の変数に束縛してから使う
  • HaskellではI/Oはモナド
    • モナドを使ったプログラミングが必須
  • モナディックなAPIの読み方
    • 何を提供するモナドか、メンタルモデルを把握する
    • モナドの剥がし方を探す
  • なぜHaskell使う?Goじゃだめなの?
    • GHC使うとパフォーマンスを担保できる
    • Goと比べると型システムが優れていて抽象度の高いコードが書ける

所感

すごいH本を過去に1度読んだだけの私にはなかなか理解がキツかったです…
Haskellではモナドを理解しないとダメなことが良く分りました。モナドが曖昧になっているのでこれを機にすごいH本を読み直そうと思いました。

RDBアンチパターン リファクタリング

speakerdeck.com

  • データベースの寿命はアプリケーションより長い
  • 最近はDBのチューニングはマネージドサービスがやってくれる
    • でも、設計は自分たちでやる必要がある
  • データは生き物、基本的にdeleteよりinsertが多い
  • RDBアンチパターンを見極めるのが大事
    • 不吉な臭いを見極められるように
    • Softwear Designで連載してるから見てね
  • 何をリファクタリングするかはアプリの特徴によって変わってくる
  • データベースリファクタリングはすごく長くなる→戦うための準備が必要
  • 「モニタリングのないオペレーションはテストのないコードと一緒である」→モニタリングは超大事
  • DBを止めるのは難しい
    • 停止時間を限りなく短くすることはできる
    • サービス停止の壁は政治と技術の両方で解決する
  • データベースリファクタリングするだけの価値があるか見極める
    • 意味はあるのか
    • 作業に応じた効果があるのか
    • 今やるべきか
  • 小さい変更を長いスパンで繰り返す
    • 欲張らない、一気にやりたい気持ちを抑える
    • DBは影響範囲が広いので切り分けできるように
  • 金で殴る
    • 金の弾丸
    • DBはお金の力でなんとかなることも多い
  • 1度作ったDBは消せない
  • RDBの知識は寿命が長い
    • 1度覚えれば長く役立つので勉強の費用対効果が高い

所感

過去のスライド等に目を通していたので、内容はだいたい知っていたのですがやっぱせっかくなので生で講演を聞こうと思って参加。プレゼンもうまく非常に楽しませてもらいました。
RDBリファクタリングは技術や政治の力が必要だけど「覚悟」も大事。

しかし、やっぱアプリの要はDBですね。DB知らないでアプリは作れん!と改めて思いました。DBエンジニアの方は偉大だ。

RDBは学習の費用対効果が高いというのはごもっともだと思いました。今をときめく機械学習系のライブラリやVR技術なんかは10年後どうなっているか予測できませんが、RDBが10年後に無くなっているとは到底思えませんからね。


1日目はこんな感じでした。「知らなかった、を聞く」ことができて非常に満足度高いです。 明日も楽しみです。