nashcft's blog

時々何か書く。

#CROSS2016 メモ

有給をとって朝からいた勢です
遅ればせながらのメモまとめ

togetter.com

11:20~12:40 A会場 今こそRDBの時代だ!・・いや待て、その前に~最近のRDB四方山話

2016.cross-party.com

togetter.com

パネラーの自己紹介のところで新しく知ったプロダクト:
Vertica: Columnar DBの1つと言ってたのはわかったのだけど後は何かむにゃむにゃ言っててよくわからなかった。

追記
捕捉されて、紹介記事をいただいた。
どうやらrestrictionを行う前にprojectionを行うなど、参照対象のデータを予め少なくすることで高速化を図っているのが特徴のようだ。
追記終わり

Actian Vector: これもcolumnar DBの1つで、内部的にはベクトル演算を用いて処理実行するようになっており、CPUの利用効率が良いのだとか。
例えば32コアのマシンに対して1つクエリを投げると、一気にCPUを100%使って処理し、終わったらすぐに落ち着くような挙動をするそうな。

スケールアップ・スケールアウトについて
  • スケールアウトでボトルネックになるのはソフトウェア的な部分。パラレルな処理を上手く纏め上げたり、シャッフル的な挙動をなくしたりするなど。インターコネクトを速くするのはハードウェア的な問題? (ちゃんと聞いてなかった)
  • スケールアップは基本的にハードウェアがボトルネック
    • OracleSparc M7というデータベース関連の処理をCPU内で行うことのできるチップを開発。暗号化処理やインメモリで行われる処理をCPUが肩代わりするような感じで処理を行う
    • 現状Solarisでしか動かないのでほとんど普及していない
    • こういったチップの進化でもスケールアップは進化する、とのこと
  • 上の話が終わった頃に奥野さんがスケールアップはHWの問題ばかりではないと解説を始める。座っている姿勢がとても良い
    • 曰くDBのバージョンが古いとマルチコア / メニーコアへの対応ができてなく、そのようなCPUを用いても全然使い切ることができないのだと
    • これはロックの粒度が粗いのが問題で、ロックの粒度を細かくしていく方向で対応が進んでいる
  • この話の後に諸橋さんがメモリの観点で言うとロックが粗い方がリソースを使いきれるという主張を当ててきた
    • この主張に対して間違いではと指摘があった
      • これに関しては上のtweetに続くやり取りにあるように、私もcolumnar storageの観点からの主張だったのではと思っている。奥野さんはRDBの視点からロックを細かく、と主張されていたので、そもそも前提が異なっていて、それを明確に共有できてなかったように思える
      • その辺は確かに触れられていなかったなあ
  • また、新しいバージョンでロック粒度を細かくするようになっていくと、むしろコアの少ない構成ではパフォーマンスが下がったりするという指摘があった
    • これはコア数が少ない分ロックに関わるオーバーヘッドの影響を受けやすいから。DBのバージョンアップをするならHWの見直しも必要そう
  • 何にせよきちんとベンチマークを取りながら適切なアーキテクチャや設定 (実装?) を行っていくべき、というのが着地点
愛用製品に足りない機能
  • 奥野さんによる熱いMySQL dis (CHECK制約のみ)
    • 実装がないどころか、構文エラーにもならずただスルーされる
  • 日本語ドキュメントなど
    • 私が主に使用しているPostgreSQLは公式ドキュメントに関しては充実していて恵まれていると思う
    • ただ書籍が少ないのがなあ...
    • 洋書では最近色々出てきているのを確認しているので、もっとPostgres需要が高まって翻訳されるようになってほしいと願うばかり
  • 自動チューニング・構成 / パラメータのアドバイザ機能
    • MySQLは5.7でoptimizerが劇的に改善されている
  • 不要な機能を使えなくしたり外したりするオプション
    • 業務的なあれ
  • 足りない機能を追求しすぎると仕様や実装が肥大化して、でも結局そこまで必要なかったよね、みたいなことになる
SQLに導入してほしい機能
  • 何よりもまず決まったSQL標準に対応してほしい
  • 多対多のテーブル制約
    • 現在のテーブル制約には外部キー制約しかない
    • Relational Modelを突き詰めて考えていくと欲しくなるのだそう
      • これまでフラグで管理してたようなものを複数のテーブルに分割して管理したい時 (顧客テーブルに対する会員テーブルと非会員テーブルのような)
  • MOVEコマンド
    • 上の多対多テーブル制約と関連する
    • 制約を保ったままレコードをテーブル間で移動させたい
RDBで解けない問題あるある
  • グラフ: Graph DB使えばよくない? -> マシンパワーの向上で力技で解決、ということの方が多い
    • traceableなログデータを構築するのに使っている例の紹介
  • BOM (bill of materials)
  • ぐるぐるバッチ
闇エピソード
  • これはtogetter見た方が面白いかも
  • すごいカラム名列伝
    • 在庫フラグ -> 仕様書見ると「在庫削除フラグ」だった
    • 期間を表すのにfrom, toを使用し予約語とバッティングして無事死亡
    • yobi000 ~ yobi999
      • 20個の予備カラムの内18個目まで使ってしまったので、19個目にXMLを放り込みXML側に属性を追加しまくる
JSON型の是非
RDBじゃなくてもよかったなと思うこと
  • 単純なデータ構造とか
  • メモに「スライド参照」って書いてあるけどスライド上がってないっぽいので死んだ
リファクタリング、負債の先延ばしについて
注目しているDB関係のテクノロジー
RDBは今後どのように進化するべきか
  • システムの変化に応じてDBも変更できるような変更のしやすさ
  • 汎用化したインターフェイスの実装
  • HadoopやNoSQLとどのように共存していくか、SQL on Hadoopがより注目されるのでは
  • Relational DBとしての進化をするべき
    • だが他のデータモデルに則った処理も同一のトランザクション内で行える、というような機能があることは良いと思う

13:00~14:00 E会場 そうだ、他社へ行こう

2016.cross-party.com

togetter.com

転職の動機

最初の方から「自分を取り巻く環境をリセット、もしくは変化させるために転職する」という主張があって、その後も話を聞いていると意識してかしてないかはわからないがその主張にそった体験談などを話していた。
これに関しては以前「今いる環境を変化させるよりも、自分が欲するような環境のある場所に移動する (=転職) の方が楽なので転職する」というような話をtwitterで見かけたことがあって、考えることは同じなのだろうと思った。
本当は会社の中で環境を変えられるようにできると良いのだけど、現実できてないよねー、はい、その通りだと思います。

転職市場ではどのような人が魅力的に見えるか
  • 面接では割と募集要項に準じたような単一の項目 (スキル等) を求められることが多く、あれとこれと...とPRするとウケが悪いなんてことがある。あれもこれもやりたいというのが評価される所は珍しい (波多野さん)
  • 採用する側としては、スキル面としてはツールや言語のようなspecificなものよりも、10年後、20年後も活かせる普遍的なものがある方が魅力的 (田中社長)
エージェント vs. 直接応募
  • 直接応募だと明確な目的意識を持って応募してくるのでそちらに舵を切りたい。とにかく人が必要だった頃は多数のエージェントを使ったが、今後は比率を下げていきたい
  • エージェントは会社によってピンキリ
    • 手数料を倍出したらいい人が集まった、なんてことも
  • ただ直接応募だけだと入ってくる人の性質に偏りが出てしまうので、社員の多様性を確保するために使うためにエージェントが必要かもしれない
    • 入ってくる人に合わせて仕事が用意できると良い (?)
    • 転職する側としては、これまでやってきたことをそのまま続けるよりも、これまでの経験でその会社の殻を破ることができるような会社に行きたい (寺尾さん)
  • エージェント経由だとよりよく見せてくれる、というのは幻想
転職するか否か、良い転職とは
  1. 会社の中で自分にとってやりたい新しいことを見つける (転職しない): 自分にとっても会社にとっても幸せなパターン
  2. スキルの割に低い評価を受けている: 転職
  3. 上司と闘って勝つ、上司を置き換える: 自分にとってより良い環境は得られるだろうが、禍根が残りそう。これができなければ転職
  4. スキルを伸ばせてないので転職できないけど不満を撒き散らす: 最悪

いつでも転職できるように自分のスキルを高めることが必要。また自分の市場価値を客観的に判断するためにエージェントを使うと良い、とのこと。
この話の中で「スキルの割に評価が高い人はもう転職できない」という話があって、勤めているところがそういう方向に倒れやすい会社なので今まで漠然と抱いていた危機感が現実味を増してきている。

やめ方
  • 円満に退職できると、それは外部とのコネクションとして残り、前職と現職でコラボというようなこともできるようになる。これは幸せなことだと思う (寺尾さん)
  • 退職者・前職とのつながりは大切にした方が良いことがあるし、その為にも良好な関係のまま転職するようにしよう

14:10~15:30 大会場 開発プチ闇4連発! 〜そのとき人はどうするか〜

2016.cross-party.com

togetter.com

パネラー4人がそれぞれ見てきたり経験したりした闇とそれをどう解決したか、もしくはやり過ごしてきたかというのを紹介していく形式だった。

カヤックの人たちの発表はどちらも技術基盤チームという人たちが光を照らすのに何らかの貢献をしたという話が出てきて、そう言ったエンジニアの日々の開発をサポートすることを責務とするような存在がうまく機能しているのは良いことだなー、うちにもそういう存在を作って色々な問題を解決していけたらなーとか思った。

昼食の後だったのでいい感じに眠くて全然メモを取れなかった...

15:50~17:10 C会場 クライアントサイド開発をWebとNativeから考える

2016.cross-party.com

togetter.com

結論から言うと状態管理と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におけるスレッド関連
  • 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版があるそうな。まあそっちも結構なお値段するそうで。

そのほか

会場着いてからこういうものがあった事に気がついた。
見たときはこういうアピールは大事だし、うちでもやれるようにならないかなーなど思っていたけど、今は別に会社がそういう事表明しなくてもエンジニア各個人がそれぞれの意思や目的で好きに行けたら良くて、むしろ「業務」という扱いになるのはどうなんだろうという感じになっている。
「業務扱いにしたげるから好きに行っといで」という意味での表明だとしたら良いのかもしれないけど、そういう会社ってそもそも対外的に表明しなくてもそういう風土になってそうな気がするし、そうなるとこういう表明って何かつらさが隠れているのではという疑りをしてしまうのだけど実際のところどうなんだろう。

こんな感じのことを悶々と考えて、結局は有給とって個人の時間として参加しといて良かったということで落ち着いている。