ORACLE CODE TOKYO B-3-1
を拝聴したメモです。
技術の移り変わりがすさまじいこの時期に私たちはどの技術を選べばいいのかというひとつの指標になればと思います。
長生きしている技術
- Unix
- REST/Web
- RDBMS
共通点
制約がもたらす共有
- インターフェースが狭く限定的
- 振る舞いの種類が少ない
- 実装に依存しない
- 接続と再利用が時間をまたいでいる
決定的な違いをもたらした技術
- Ruby on Rails
- Cloud
- Docker
- React
Ruby on Rails/Cloud/Docker
量的（時間的）な変化が大きい
「安い」「うまい」の実現
React
サーバーサイドの処理を記述する感覚でフロントエンドのコードが書ける
データ更新の方向が一方通行（混乱しない）（？）
Reactによるて手数は増えたが、心配は減った
結局なにを使えばいいの
- Game Changer（大きな変化をもたらすもの）は必ずしも採用する必要はないが、それらが変えた後あとの世界は知っておく必要がある。
- 開発にかかわる労力（コスト、心的コスト）を矢印で表したとき、その長さや構造を圧倒的に変えるもの。 もしくは矢印は折る（ジャンルそのものを不要にする）
ここまでの変化がないものをスルーするかどうかは「お好みで」
「その技術が何のために出てきて、何をどのくらい変化させるのか見切れればスルーできる」
WorthisBetter
簡潔性、正当性、一貫性、完全性の観点でソフトウェアの設計を行う。
設計も実装もシンプルがベストだがそれができないときになにを重要視するかというもの
- MIT/Stanfordアプローチ
コードがいくら複雑になっても正しいことをせよ
- New Jerseyアプローチ
ユーザの負担が増えたとしてもコードを単純に保て
従来のソフトウェア設計観点からいくとMIT/Stanfordが「より良い(Better)」でNew Jerseyが「悪い(Worth)」
しかし、実際は単純なコード単純な実装で50%の正しさをもったものをつくったほうが伝染性がよく、結果的に技術的改善が行われ90%まで実現するだろう
っていう考え
（汚く早く書いたほうがいいという話ではないです）
まとめ
- 技術の変化は螺旋状。技術の歴史は同じような周期で回っているが、実は螺旋構造で同じところには返ってこない。
- 変わらない技術には特徴がある。その背景を理解する。
- とりあえず新しい技術が生まれたら触ってみようぜ。