【勉強会メモ】大阪Ruby会議01
- 日時：2018-07-21（土）10:00 - 17:00
- 場所：大阪科学技術センター 4階 401号室
Rubyはほとんど使ったことが無いのですが、まつもとゆきひろさんの話を聞きたかったのと、先日同じようにあまり使わないレベルのPHPについても PHPカンファレンス関西 に行ってきたので、それならRubyのコミュニティにも参加してみたいという思いもあって行ってきました。今回聞いてきたどのテーマも根底は言語に依存しない普遍的なテーマだったので「Rubyじゃなくても大切だよなぁ」と思いながら聞きつつ、それが言語の特性を踏まえた知見から語られているので「Rubyだとそうなんだなぁ」という気づきも得られて非常に参考になりました。
keynote : Rubyはなんでできてるの？
まつもとゆきひろ さん
Ruby25周年
Rubyをつくったきっかけ
- 1993年ごろバブル崩壊
- 不況の産物
- 社内システムの開発⇒景気が悪くなって解散
- 大半のメンバーはお金を稼ぐ部署に移動
- 社内システムのメンテのために2人だけ残された
- そのうちの1人がまつもとさん
- 基本ひまだった
- なんかやるかと思って作ったのがRuby
高校時代の夢
- BASIC使っていてこれよりましな言語がほしい
- 言語を勉強しているうちに言語は面白い⇒言語作りたいになった
- 当時はまだネットがなかったので情報が本か雑誌しかない
- やさしいコンパイルのつくりかた
- 高校生には難しかった
結局何に興味があったか？
過去の言語のいいとこ取り
Rubyの発想の源
- 大学時代Sun3ワークステーションを学部生100人で共有
- Emacs使うことは禁止されていた
- ソースコードリーディング⇒Emacsの中身を読み始めた
- Tagged Pointer
- Garbage Collector
- auto-indent
ruby-mode.elを作ってからRubyの文法を決めた
CとRubyを交互に使う
- 視覚的にコンテクストスイッチが行われる
- シンボル⇒当たり前と思っていた
- Bignum⇒すごい悩んだ
fcntlを追加した時…Tagged Pointerを使っているので整数は32bitしかない
- メタプログラミング
- CLOS
- bit 別冊 Commpn Lisp オブジェクトシステム
- 1988年インスパイアされた本
- nil
Eiffel
- オブジェクト指向Ara
- マイナー言語
- 昔は金融系などで使われていた
- Object-criented software constructionオブジェクト指向入門
- タイトル詐欺⇒入門じゃない
- 卒業研究でプログラミング言語を作った
- 静的型
- 多重継承
- プロファイル（インターフェース）
- これらは結果的に次に作ったRubyには全部入っていない
- 櫛形構文
- require
- ensure
- rescue
- ↑Rubyも影響
- 櫛形構文
CLU
- Barbara Liskov
- リスコフ置換原則の人
- 抽象型言語
iter() do|i| ... end
Sather
- UCBで開発されたEiffel類似言語
- undef
- alias
- Sather 1.0にはundefはない
- バージョンが進んだ時にすれられた⇒LSPに反するせい？
- Rubyにコピーされて生き残った
- class
- def
Smaltalk
- select
- collect
- detect
- reject
- ブロック引数の
||
- 演算字優先順位
- 目標：Perlと同じような仕事ができること
- これらをオブジェクト指向で再構成⇒正解だった
- グローバル変数は不正解
- 正直後悔している
- 未来は予想しづらい
- RoRやWebアプリケーションになることは想像していなかった
真似なかった言語
デザインの困難さ
- なにをパクるか
- どれだけパクるか
- そのままパクるか
- 周囲との整合性
- Rubyにしかない要素はあまりない
バランスが大切
- エクストリーム
- ボリュームのつまみを一番上まで上げる
- 極端は簡単
- バランスが大切⇒すごいむずかしい
- 「ちょうどいい」が必要
- 答えがない
- 人によって違う、時代によって違う、条件によって変わる
- 誰かが決めないといけない
安定と進歩
- 互換性は重要
- 互換性がないと古いバージョンを使い続ける人がでてくる
- しかし、変化は止められない
- テクノロジーの進歩
- 「昔はそんなのあったよね」と言われる
- 緩やかな死
- 進歩を止める≒死
- Rubyがそうならないように進歩を止めるわけにはいかない
- バージョンアップ地獄
- 下にいる人が苦労して互換性を保っても上側で壊れる
- なぜか？⇒Webというドメインの変化が早い
- たとえ互換性を壊してでも変化を続けなければ取り残されてしまう世界
- JavaScript
- フレームワークさえ交代
言語のデザイン
- 困難
- 柔軟性と性能
- 厳密さと気分
- 静的と動的
- デザインの面白さ
- デザインの困難さ
Ruby3について
- 2020年ぐらい出したい
- バランス
- 互換性の維持
- 「盲腸」の切除（誰も使っていないもの）
- 性能の改善
- Ruby3x3
- JITコンパイラ
- MJIT
- MIR
- まだ動くだけ
- 将来に期待
- マルチコア時代
- GIL⇒外せるけどクラシュする
- Guild
- メモリ容量
- GC改善
- 関数型プログラミング
- 列指向プログラミング
- パターンマッチ
- 鋭意開発中
つまり
- バランス
- 既存のコードを壊さない
- 性能改善
- より良いRubyのために一本橋の上を駆け抜ける
- 既存のソフトウェアを壊さない選択肢を探す細い一本道しかない
- ソフトウェア開発・デザインの困難さ
- すべてのデザインの面白さ
- Rubyの特異さ
Rubyは良い言語
- ただデザインは厳しくなって狭くなる選択の余地
- 言語デザインの難しさ⇒言語デザイナーの醍醐味
- プログラマー≒デザイナー
プログラミングの醍醐味
- 自分はデザイナーであるということも頭におく
- 困難はつきまとうけどそれが一番おもしろい
Tech Talk：Complexity and You
@yuki24 さん
過去のWeb開発
- HTTPサーバは基本Apach
- ファイル構造が表示されるだけで感動
- PerlやPHPでページごとにゴリゴリ書く
- 単なるテキストファイルをデータベースっぽく使用
- アクセスがあるたびにデスクI/O
- 適当なロック処理
- なんとなく動かしていた
- 紙のページを彷彿とさせるデザイン
- JavaScriptは悪
- ページ遷移でキラキラアニメーション
- マウスポインタを追従する画像
- JS使うな
↓このようなWebサイト
bitfission.com - Will Leinweber
今日のWeb開発
- 数多に存在するフレームワーク
- 当たり前のようにRDBMSを使用
- Node.jsでSSR
- バックエンドなしでもアプリ開発
- Firebase
- Google Mapの登場でJS復活
- Protorype.js
- jQuery
- フロントエンドライブラリ
- React Angular Vue
- SPA
- Virtual Dom SSR PWA
- GraphQL
何使ったらええねん
今日のWeb開発のぱっと見の印象
- とてもスムーズに動くUI複数の要素が同時にロード
- ページングなしで画面遷移
- エッジケースも簡単
プロジェクトが始まってから明らかになる事実
- JS難しい
- AngularとかFW難しい
- SEO難しい
- Bundled JSのファイルサイズ大きすぎ
- PWAまだわからん
- JS依存ライブラリがメンテされず死んでいる
- ちゃんとテストされていない
それRailsで5分でできるよ
- ソフトウェア開発とは単なる線形な仕事ではない
- 日々積み重なる複雑度により同じ機能でも別アプリだと実装の速度が変わってしまう
Complexity
- Apach + PHP
- 高価値／実現困難
- JS before Google Map
- 低価値／実現困難
- Rails
- 高価値／実現困難⇒高価値／実現容易 価値があって難しいものが簡単に移動
- JS after Google Maps
- 低価値／実現困難⇒高価値／実現容易
- 高価値で実現困難
それReactで簡単にできるよ
- Railsだけでやろうと思うと見当もつかない
- JSならさっと思い浮かぶ
- Reduxでデータを共通管理
- イベントもRedux
Reactで実現した後…
また高価値で実現困難な要求が発生
- 認証系機能
- 管理画面
- バージネーション
⇒それRailsで5分でできるよ
Railsでできる⇒Reactでできる⇒循環
いいとこどりしようとした結果
ソフトウェア開発!=コーディング
- 高価値／実現容易でユーザーを獲得できないと実は価値がない可能性もある
- リスク・不確実性
本当にhigh valueか？
常にXを使え（使うな）族
道具はツールボックスのように整理されていて使わないといけない
- 学習はツールボクスの中身を増やしていくこと
- 慣れたツールもあれば慣れていないツールもある
- よく使うツールもあれば使わないツールもある
- 高価値／実現容易でユーザーを獲得しないと何もできない
- 高価値／実現困難にフォーカスできているのはプロジェクトとしてはヘルシーな状態
- 高価値／実現困難をシンプルにするにはどうしたら良いか
それXでできるよの投げ合いは解決に至らない
- 過去の成果に対するリスペクトがあるか
- 道具に対する知識が十分あるか
y=f(x) x=使用可能な技術 y=テックスタックの決断
y=g(x) x=開発を始めるときの年 y=使用可能な技術
y=f(g(x)) g(x)は使用可能な技術を返す関数 関数fは人間
あなたの関数f(x)はなんですか？
Tech Talk:GR-CITRUSいろいろ
たろサ さん
GR-CITRUS
- 極小Rubyボード
- mruby
- 2,200円
- 2014年ごろからWakayama.rbで開発
- ルネサスさんが企画して秋月電子通商さんが商品化
- オープンソースハードウェア
- Ras-Pi Zeroより小さい
Ruby Cam-Robo360
VS-Code Studioで開発
- VS Code Rubicを入れる
参考
開発当初からの変更点
- プログラムサイズ制限をなくした（4KBから無制限）
- 大きなコードが動かないという声が多数
- ただし暴走は自己責任
- プログラム実行の自動切り替え
- 電源起動すると
main.mrbが自動起動 - USBでPCにつないだときはデバックモードで手動実行
- 電源起動すると
- 強制ブレイク
- 無限ループでもブレイクできる
サンプル
