有給をとって朝からいた勢です
遅ればせながらのメモまとめ
11:20~12:40 A会場 今こそRDBの時代だ！・・いや待て、その前に～最近のRDB四方山話
パネラーの自己紹介のところで新しく知ったプロダクト:
Vertica:
Columnar DBの1つと言ってたのはわかったのだけど後は何かむにゃむにゃ言っててよくわからなかった。
追記
捕捉されて、紹介記事をいただいた。
どうやらrestrictionを行う前にprojectionを行うなど、参照対象のデータを予め少なくすることで高速化を図っているのが特徴のようだ。
追記終わり
Actian Vector:
これもcolumnar DBの1つで、内部的にはベクトル演算を用いて処理実行するようになっており、CPUの利用効率が良いのだとか。
例えば32コアのマシンに対して1つクエリを投げると、一気にCPUを100%使って処理し、終わったらすぐに落ち着くような挙動をするそうな。
スケールアップ・スケールアウトについて
- スケールアウトでボトルネックになるのはソフトウェア的な部分。パラレルな処理を上手く纏め上げたり、シャッフル的な挙動をなくしたりするなど。インターコネクトを速くするのはハードウェア的な問題? (ちゃんと聞いてなかった)
- スケールアップは基本的にハードウェアがボトルネック
- 上の話が終わった頃に奥野さんがスケールアップはHWの問題ばかりではないと解説を始める。座っている姿勢がとても良い
- 曰くDBのバージョンが古いとマルチコア / メニーコアへの対応ができてなく、そのようなCPUを用いても全然使い切ることができないのだと
- これはロックの粒度が粗いのが問題で、ロックの粒度を細かくしていく方向で対応が進んでいる
- この話の後に諸橋さんがメモリの観点で言うとロックが粗い方がリソースを使いきれるという主張を当ててきた
- また、新しいバージョンでロック粒度を細かくするようになっていくと、むしろコアの少ない構成ではパフォーマンスが下がったりするという指摘があった
- これはコア数が少ない分ロックに関わるオーバーヘッドの影響を受けやすいから。DBのバージョンアップをするならHWの見直しも必要そう
- 何にせよきちんとベンチマークを取りながら適切なアーキテクチャや設定 (実装?) を行っていくべき、というのが着地点
愛用製品に足りない機能
- 奥野さんによる熱いMySQL dis (CHECK制約のみ)
- 実装がないどころか、構文エラーにもならずただスルーされる
- 日本語ドキュメントなど
- 私が主に使用しているPostgreSQLは公式ドキュメントに関しては充実していて恵まれていると思う
- ただ書籍が少ないのがなあ...
- 洋書では最近色々出てきているのを確認しているので、もっとPostgres需要が高まって翻訳されるようになってほしいと願うばかり
- 自動チューニング・構成 / パラメータのアドバイザ機能
- MySQLは5.7でoptimizerが劇的に改善されている
- 不要な機能を使えなくしたり外したりするオプション
- 業務的なあれ
- 足りない機能を追求しすぎると仕様や実装が肥大化して、でも結局そこまで必要なかったよね、みたいなことになる
SQLに導入してほしい機能
- 何よりもまず決まったSQL標準に対応してほしい
- 多対多のテーブル制約
- 現在のテーブル制約には外部キー制約しかない
- Relational Modelを突き詰めて考えていくと欲しくなるのだそう
- これまでフラグで管理してたようなものを複数のテーブルに分割して管理したい時 (顧客テーブルに対する会員テーブルと非会員テーブルのような)
MOVEコマンド- 上の多対多テーブル制約と関連する
- 制約を保ったままレコードをテーブル間で移動させたい
RDBで解けない問題あるある
- グラフ: Graph DB使えばよくない? -> マシンパワーの向上で力技で解決、ということの方が多い
- traceableなログデータを構築するのに使っている例の紹介
- BOM (bill of materials)
- ぐるぐるバッチ
闇エピソード
JSON型の是非
- text型でJSON格納できるのでインパクトはない
- DBはアプリにとって最もアクセスしやすい永続化されたglobal変数
- JSONを1つの値として扱う分には問題ないが、それを切ったはったするとつらくなる
- RDB側でプロパティ使って演算するなど?
- RDBにJSONを操作するための機能が揃ってないから辛いのではないか
RDBじゃなくてもよかったなと思うこと
- 単純なデータ構造とか
- メモに「スライド参照」って書いてあるけどスライド上がってないっぽいので死んだ
リファクタリング、負債の先延ばしについて
- その場その場でコスト的に楽な方を選ぶ
- リファクタリングも先延ばしも計画的に行うこと
- リファクタリングについては『データベース・リファクタリング』 (原著: "Refactoring Ddatabase") を読むこと
- 『理論から学ぶ データベース実践入門』にも書いてある
- 奥野さんによるとアプリのリファクタリングだけ実施して、DBのリファクタリングを行わないのは片手落ちとのこと
- アプリと比較してDBは長生きで、一旦構築されるとずっとそのままで使われ続ける。またアプリではコードのコピペは悪とされているのにSQLや構造のコピーは何も言われないことが多い
- まずい設計のSQLがコピーされて伝播するなんてこともある話
- 最初からしっかりとした設計をしておく必要がある
- まずDBをリファクタリング可能にするために、1つのDBには1つのアプリだけアクセスしている状態にしなければならない
- DBのリファクタリングもアプリと同じくらい気軽にできるようにならないと先が暗い
- リファクタリングが大変だからと言ってスキーマレスな設計をするのは危険
注目しているDB関係のテクノロジー
RDBは今後どのように進化するべきか
- システムの変化に応じてDBも変更できるような変更のしやすさ
- 汎用化したインターフェイスの実装
- HadoopやNoSQLとどのように共存していくか、SQL on Hadoopがより注目されるのでは
- Relational DBとしての進化をするべき
- だが他のデータモデルに則った処理も同一のトランザクション内で行える、というような機能があることは良いと思う
13:00~14:00 E会場 そうだ、他社へ行こう
転職の動機
最初の方から「自分を取り巻く環境をリセット、もしくは変化させるために転職する」という主張があって、その後も話を聞いていると意識してかしてないかはわからないがその主張にそった体験談などを話していた。
これに関しては以前「今いる環境を変化させるよりも、自分が欲するような環境のある場所に移動する (=転職) の方が楽なので転職する」というような話をtwitterで見かけたことがあって、考えることは同じなのだろうと思った。
本当は会社の中で環境を変えられるようにできると良いのだけど、現実できてないよねー、はい、その通りだと思います。
転職市場ではどのような人が魅力的に見えるか
- 面接では割と募集要項に準じたような単一の項目 (スキル等) を求められることが多く、あれとこれと...とPRするとウケが悪いなんてことがある。あれもこれもやりたいというのが評価される所は珍しい (波多野さん)
- 採用する側としては、スキル面としてはツールや言語のようなspecificなものよりも、10年後、20年後も活かせる普遍的なものがある方が魅力的 (田中社長)
エージェント vs. 直接応募
- 直接応募だと明確な目的意識を持って応募してくるのでそちらに舵を切りたい。とにかく人が必要だった頃は多数のエージェントを使ったが、今後は比率を下げていきたい
- エージェントは会社によってピンキリ
- 手数料を倍出したらいい人が集まった、なんてことも
- ただ直接応募だけだと入ってくる人の性質に偏りが出てしまうので、社員の多様性を確保するために使うためにエージェントが必要かもしれない
- 入ってくる人に合わせて仕事が用意できると良い (?)
- 転職する側としては、これまでやってきたことをそのまま続けるよりも、これまでの経験でその会社の殻を破ることができるような会社に行きたい (寺尾さん)
- エージェント経由だとよりよく見せてくれる、というのは幻想
転職するか否か、良い転職とは
- 会社の中で自分にとってやりたい新しいことを見つける (転職しない): 自分にとっても会社にとっても幸せなパターン
- スキルの割に低い評価を受けている: 転職
- 上司と闘って勝つ、上司を置き換える: 自分にとってより良い環境は得られるだろうが、禍根が残りそう。これができなければ転職
- スキルを伸ばせてないので転職できないけど不満を撒き散らす: 最悪
いつでも転職できるように自分のスキルを高めることが必要。また自分の市場価値を客観的に判断するためにエージェントを使うと良い、とのこと。
この話の中で「スキルの割に評価が高い人はもう転職できない」という話があって、勤めているところがそういう方向に倒れやすい会社なので今まで漠然と抱いていた危機感が現実味を増してきている。
やめ方
- 円満に退職できると、それは外部とのコネクションとして残り、前職と現職でコラボというようなこともできるようになる。これは幸せなことだと思う (寺尾さん)
- 退職者・前職とのつながりは大切にした方が良いことがあるし、その為にも良好な関係のまま転職するようにしよう
14:10~15:30 大会場 開発プチ闇4連発！ 〜そのとき人はどうするか〜
パネラー4人がそれぞれ見てきたり経験したりした闇とそれをどう解決したか、もしくはやり過ごしてきたかというのを紹介していく形式だった。
カヤックの人たちの発表はどちらも技術基盤チームという人たちが光を照らすのに何らかの貢献をしたという話が出てきて、そう言ったエンジニアの日々の開発をサポートすることを責務とするような存在がうまく機能しているのは良いことだなー、うちにもそういう存在を作って色々な問題を解決していけたらなーとか思った。
昼食の後だったのでいい感じに眠くて全然メモを取れなかった...
15:50~17:10 C会場 クライアントサイド開発をWebとNativeから考える
結論から言うと状態管理とMVC (Flux) で盛り上がりすぎてトピックあまり消化できてなかった 。API設計とかテストの話とか聞きたかったな...
Web / Nativeの好きなところ、嫌いなところ
Webの好きなところ:
- みんなが1つの、安定するだろう仕様を作ることに向けて頑張っている感
- Nativeのプラットフォームは10年後も存在するかわからないが、Webはもっと長い期間生き続けるはず
- 実装側の動きの早さ
Webの嫌いなところ:
- 統一仕様を作成しようとしてるから歩みが遅くなってしまっている
- そこを現場がpolyfillとか独自仕様とかで穴埋めとして作ってしまい消耗している
- パフォーマンスが悪い
- UIのためのパーツが足りていない
- 制約が少ないため (それを求める人からすると) やりにくい
Nativeの好きなところ:
- 強力なプラットフォーマーがいる
- 制約によって開発しやすさが生まれている
- UIのパーツが豊富
Nativeの嫌いなところ:
これについて何か言ってた人がいなかったような...
クライアントサイド開発は難しいのか?
非同期処理:
- Webはpromiseの登場、generator / yieldやasync / awaitによって非同期処理を平たく書きやすくなっている
- だが広く使われているかというとそこまでではない
- 現代のWebアプリにおけるクライアントサイド開発ではpromiseは必修
- エラーハンドリングで
catchを書き漏らす人が多い。リテラシー上げていこう
- エラーハンドリングで
- ES2015以降の仕様に関しては現状言語標準として実装されていないので、ライブラリ (e.g. babel) に頼る必要があり、どこまでアグレッシブに新しい仕様を取り入れるかは考えどころ
- Webにおけるスレッド関連
- WebWorkerやServiceWorkerでUIスレッドから処理を逃がすことはでき、それで並行処理はできるようになっている
- IEというブロッカーの所為で界隈の経験値がまだ不足している (mizchiさん)
- Native側も最初は手作りしてたが最近はライブラリに任せられるようになって楽になった
状態管理:
- Webはフレームワークによるところが大きい
- jQuery時代: サーバが返してきたHTMLにたんぽぽを乗っける程度
- その後Webアプリでもちゃんと作ろうという機運が出てきて、その頃にbackboneが流行る
- backboneが流行って1年くらいしてdata bindingが発見されてAngularが流行る
- また1年くらいしたらReact / Fluxが登場
- Angularの時代までは1つのものだけが注目されていたが、最近は多様性が認められつつある (Angular2とReact, Fluxの元々のコンセプトとReduxという1つの実装, etc.)
- Nativeはプラットフォーマーがしっかりした土台を提供していたので、フレームワークに頼ることは起こらなかった
- むしろプラットフォームの上にさらにフレームワークを乗せることは良い事とみなされなかった
MVC:
- Webアプリにおいてはクライアントとサーバの責務を明確に分けられなかったという問題があった
- Webはフロントエンドに持ち込まれたMVCを理解する前にdata bindingなど新しいものが次々に来てそれに飛びついて行っただけで、決してつらい時代があったわけではなかったのでは?
- Fluxの良いところ: storeというここだけ見ていれば状態がわかるという局所点を作ったこと、イベントの流れが交通整理されていて見通しが良いこと
- data bindingでは様々なところから状態変更が飛んでくるので管理がつらい
- Reduxの良くないところの話 -> redux への 不満を解消する為に, flumptというFlux実装を作った
Rx:
- 難しすぎる、結構使えるという段階に至るまでだいぶ時間がかかる
- 内包されている概念が多いなど
- Rxを普通のWebアプリに使うとサーバサイドエンジニアにとって暗号になってしまうのでは
- RxはPromiseの代わりとしての選択肢だったり離散的なイベントを扱えるものだったり、であって、GUIプログラミングに必要なもの、というほどではない
- Native側では結構hotになっているので、WebでもRxが広まればWeb, Android, iOSでアプリの実装が統一的になりそう
型:
- 大規模アプリ開発では欲しくなる
- JSには型がないのでIDE支援による補完・関数絞り込みが使えないので辛い
- TypeScript + RxJSで解決するけどかなり縛られた環境になってしまうのであまり流行らないだろう
- 型が必要、という訳ではなく、ReactやRxなど型を要求するものが急激に増えてきて需要が高まっただけでは
- 最近導入されている機能は関数型プログラミングから取り入れられているものなので、関数型プログラミング(言語)を学んでおくと今後の動向を予想できるので勉強しておくと良い
今後
- Web側ではやはり型が求められる
- エコシステムとして大規模アプリを構築する土壌はあるので、実践して経験値を貯めていこう
- WebAssemblyによって (llvm言語なら) どんな言語でもWebをかけるようになるかもしれないので、llvm言語を学ぶと良い (Rust, Swift, C#など)
- UI state, data state, business logicを置く場所がきちんと決められたアーキテクチャを作る
メモを見返して、自分がWeb側だけの人間だからかNative側のメモが全然ないことに気づいた
アンカンファレンス
全部の時間枠で何かしら見てたけどその中で印象に残ったものを2つ:
スクリーンショットベースでテストができるPitaliumの紹介
Pitalium(hifiveリグレッションテストライブラリ) - hifive
名前からしてSeleniumのプラグインだよなあと思ったら案の定だった。
Seleniumを使ってテストできるのは基本的に機能面だけで、デザイン崩れといった描画に関わるテストはできないという主張に関しては確かにそうだなと思った。
Pitaliumそのものよりも結果チェックツールのPitalium Explorerにテスト結果のスクリーンショットからエッジ検出して形状の比較ができる機能があるという方に関心がいった。
GitHub Enterpriseを導入した話
GitLab + JenkinsがつらかったのでGHE + Circle CIに移行したという話。
LTが終わった後なぜGitLabだとつらかったのかという質問をしたところ、普段からGItHubを使っていると、GitHubとGitLabのUIや機能の差異の部分に戸惑いを感じてそれがつらさになる、というふうなことだった。
私の勤めている会社ではhgを使っているのだけど色々あってgitに移行しようかという機運があって、まだ検討も初期段階ではあるけど潤沢に資金があるわけでもないしGitLabかGitBucketになるんだろうなあと考えていたところでこういう話があったので、考え直した方がいいのだろうかというようになりつつある。
というのも、そもそもhgからgitに移行しないかという話が社内で出てきたのがメインストリームでない製品を使っていることによって選択肢が狭まり、かつ残された選択肢のどれも難点があるという苦しみの中から脱出したいという理由だったので、gitに移行してもgit界隈におけるメインストリームでない製品を使うのであればまた似たような苦しみに苛まれるのではないか、と思い始めたからだ。
現在のソースコード管理ツールのメインストリームはどうしようもなくGitHubで、関連ツールのそれもGitHubの使用が前提になっているきらいがある。
そんな中であえてメインストリームでないものを選ぶというのは、その選択肢が「メインストリームになれなかった理由や結果」というリスクを抱えなければならないということであり、基本的に自分たちでそれを打開しなければならないということになる。
うちの会社みたいな、アルファギークなどの物好きで尖ったエンジニアがいないようなところでそれをするのはまず無理で (だから今苦しんでいるわけで) 、それなら大人しくメインストリームに乗っかるのが余計なことを考えなくて済むのかなという感じ。
とはいえGHEは高いし、自社サーバに置くとなるとCircle CIとか使えなくなるのでは... と思ったらCircle CIも enterprise版があるそうな。まあそっちも結構なお値段するそうで。
そのほか
ココにうちの会社も載せたかったが諸事情により断念...#cross2016 pic.twitter.com/FbQwJNzbNI
— Mamoru Murayama (@mamorunner) February 5, 2016
会場着いてからこういうものがあった事に気がついた。
見たときはこういうアピールは大事だし、うちでもやれるようにならないかなーなど思っていたけど、今は別に会社がそういう事表明しなくてもエンジニア各個人がそれぞれの意思や目的で好きに行けたら良くて、むしろ「業務」という扱いになるのはどうなんだろうという感じになっている。
「業務扱いにしたげるから好きに行っといで」という意味での表明だとしたら良いのかもしれないけど、そういう会社ってそもそも対外的に表明しなくてもそういう風土になってそうな気がするし、そうなるとこういう表明って何かつらさが隠れているのではという疑りをしてしまうのだけど実際のところどうなんだろう。
こんな感じのことを悶々と考えて、結局は有給とって個人の時間として参加しといて良かったということで落ち着いている。
