2014-03-19
松江Ruby会議05に参加してきた(3)
昨日の最初に書いた「普段置かれている環境への疑問」てのは職場のことであって、Twitterとかで関わってる人たちのことではない。ここを誤解されると致命傷になりかねんので一応念のため。
さて、今回は松江Ruby会議05ちょー個人的感想の最終回で、DXRubyに関することあれこれをまとめて。
DXRubyとは
松江Ruby会議05はその後に懇親会もあって、たくさんの人と色々話してきた。そこで感じたのは、DXRubyを既に知っている人は講演で話したようなこととは少し違うことを知りたかったのかな、ということ。なので、ちょっと違った切り口で。
何度も繰り返すが、DXRubyは複雑なゲームを簡単に作れる、というタイプのライブラリではない。簡単なものを簡単に作れる。提供している機能は
・ゲームを作るのに最低限必須なもの
・表現力を拡張するもの
・こまごまとした面倒な処理をサポートするもの
という程度であって、ゲーム全体の構造の定義や制御に関することはほぼ無い。あるのはWindow.loopとSpriteだけである。
要は「表現する手段は提供するから手法は自分で考えろ」という話であって、それを考えるのがゲームプログラミングの楽しいところだ、と主張している。
ゲーム的な動きを自分の頭で考えて→作ってみて→動かして→喜ぶ、というサイクルを繰り返すのが俺の趣味であり、DXRubyはまさにこのためだけに生まれた。それに不要なものの一切をRubyレベルから隠し、または実装せず、俺にとって楽しいところを純粋に抽出したものが、DXRubyを使ったプログラミングなのである。書いて思ったけどすげー自己中だなこれｗ
ちなみに実行速度にやたらと力を入れているのは、その手の最適化もまた俺の趣味だからである。この2つの点が小さい頃から俺をプログラミングに引き付け続ける要素であり、例えばMatzが言語にのみ興味を持つような感じで、俺もその2点にのみ興味を持っている。なので、DXRubyを開発して自分で使うというのは、俺にとって理想的な趣味といえる。Matzの言う「魂の浮力」はここにある。
DXRubyに関する質問や要望について
x64サポート
いずれ世の中は64bitが主流になる。Windowsの場合、Microsoftが頑張るだろうから32bitのプログラムは長くサポートされるだろうが、Rubyの拡張ライブラリはことWindowsに限定するとバイナリ配布が多いので、32bitのみのままだと64bit用拡張ライブラリとの併用ができないという問題が発生する。ずっと先を考えると、どこかで64bit対応をする必要がある。
ところが、DirectX9は調べた限りでは64bitのバイナリが無い。すると、64bitに対応するためにはDirectX10以上を使うように書き直す必要が出てくる。
もともとやりたいことにImageとRenderTargetの融合というネタがあって、これができるのがDirectX12なのかもっと先なのかはわからないが、そのうち書き直すときが来るとは思っていた。とはいえ、世の中の流れに従っていないと取り残されることになるので、何かしらのタイミングでどうにかする必要はありそうだ。
まあ、Twitterのプロフィールにも書いてあるように「時代の最後端を追いかけるC言語プログラマ」というのが売り文句であり、世の中の初心者はいつでも最後端スレスレに存在していると思っているので、そこからはみ出さないように自然と追いかけていくことになるだろう。初心者と歩調をあわせるのは俺のスタイルである。ちなみに自分のプロフィールにこの文を掲げて17年になる。
Macサポート
やはりと言うかなんと言うか。この話題はネットでもちらほら見るし、dxruby_sdlやdxruby_rp5はその対策として生まれたものである。
現実的に、Macで動くようにするにはDirectX直叩きをやめる必要がある。手法としては(1)低レベルレイヤにマルチプラットフォームのライブラリ(SDLなど)を使うようにするか、(2)自力開発するなら低レベルAPIを切り離した形に設計して、差し替え可能にするか、そんなところだろう。OpenGLを使えば解決、というほどヌルい話ではない。
(1)の方法で、SDLを使えばWindowsでもMacでもそのまま動くかというと、たぶんそんな単純な話でもなくて、例えばStarRubyだってMacで色がおかしいとかの不具合報告がされたりしていたし、俺自身Macを持っていないので「SDLだからMacでも動きまーす」って公開するわけにもいかない。不具合報告されても直せないし動作確認もできない。個人で開発する以上、マルチプラットフォーム化には限界がある。
(2)は差し替えが可能な設計にしておくと言うだけで、動くように誰かがそのレイヤを書いてくれと言う話となる。これは恐らくほんとにそこを書くだけでバッチリとはならず、上のほうまで修正しないとダメね〜ってなることが容易に想像できるわけだが、少なくとも今のDXRubyを書き換えてMac対応するような泥沼の作業と比べて随分ラクにはなるはずだ。
よさげなのは(1)と(2)を合わせたような形で、低レベルAPIを切り離した設計にしたうえで、SDLを使うようなコードを誰かが書いてくれるという状態か。ただ、ImageとRenderTargetの融合などが実現された場合、SDL2.0でもそれは不可能なので、そういったものは作れなくなる。
俺としてはマルチプラットフォームを前提にしたせいでやりたいことが実現できないのはイヤなので、次世代DXRubyもやっぱり何も考えずにDirectXを使うようにしちゃうかもしれない。みなさん互換ライブラリ頑張ってください。
音関連
前にもTwitterでつぶやいたりしてたけども、AyameやLightNoteのバインダを作りながら思ったのは、外部のサウンドドライバを使う形ではRubyとの親和性という点で問題がある。まあ、主にGC周り。
例えばoggを再生しようとするとストリーミング再生することになって、別スレッドでデコード＆バッファへの書き込みを行うことになる。小さい効果音ならプリデコードしてバッファに突っ込む。そうした場合、どのデータをどこでキャッシュして、どのタイミングで解放するのか、Rubyのオブジェクトは何を保持するのか、別スレッドのアクセスとRubyからのアクセスをどのように協調させるのか、GCが動いたときにどうするべきなのか、などなど、考えるべき点がたくさんあり、ある程度がサウンドドライバ側で実装されていると、どうしてもRubyと拡張ライブラリと、サウンドドライバとの効率的な結合ができなくなる。もしくは実現できない機能が出てくる。
究極的にはRuby専用のサウンドドライバを設計するのが解決策になるわけだが、それをするのもまた手間と時間がかかる。そのへんは現在勉強中なのでそのうち始めるかもしれないが、誰か作ってくれたら嬉しいなーとかすごく思う。
少なくともこれだけは言える。現在の組み込みSoundクラスやDXRubyWikiに置いてあるものでは俺は満足していない。
Github
懇親会で中村さん(@nari3)と話した。
nari3「Githubにソース置かないんですか」
mirichi「Githubに置いたらなんかいいことあるんですか」
nari3「ソースが見やすくなります」
mirichi「へ？ソース見るんですか？」
nari3「見てますよ？」
mirichi「ﾌｧｯ?!」
まさかあの年単位で時間をかけてツギハギにしていった汚いコードを見ている人がいるとは。驚愕の事実である。誰も来ないからと部屋を散らかし放題にしていたところに突然お客さんが来ちゃったような気分である。とはいえSourceForgeで管理しているので言わばガラス張りの部屋を散らかしていたとも言えるわけで、それはそれでひどい。
Githubにコードを置くなら、SourceForgeのsvnと両方管理するのは面倒極まりないので、たぶんGithubメインになるだろう。ソースを管理せずリリースと公式サイトだけをSourceForgeにするというご都合主義的な選択はアリなのかと言うと、たぶんSourceForgeの理念的には問題無いと思う。
といってもすぐに引越しするかというとそうでもなくて、そのうち引越しするかも〜？程度に。リファレンスもGithubに置くかとかそういうのも考えたりしていて、それもあわせていずれ時期がくるだろう。
あと、Githubに置くなら今のように誰にもビルドできないような極悪な状態も問題で、x64サポートとともに開発環境をmingw系に移行しつつ、そこそこ簡単にビルドできるような状態を確保する必要がありそうである。
3D
これは昔からずーっと考えていることで、どのように効率的に処理するかが一番の問題点となっている。
スキンメッシュアニメーションをする場合、まず間違いなくRubyで処理することになるわけだが、そうするとそこに負荷が集中してしまうので、そのへんの対策が必須のポイントとなる。例えば今の開発版のVectorオブジェクトを配列に突っ込んで頂点バッファを生成するなどでは相当遅いことが予想できる。
俺としては最終的なターゲットをMMDのモデルの描画に置く感じでいて、最初からそれができるように作るのは大変だが、いずれ拡張していく形でそこにたどり着けるような設計にしておかなければならない。ベースとなる部分の柔軟性と速度を確保することが重要、ということだ。
これはまたチマチマ実験しつつ、ボツにしつつ、Rubyで実用的で簡単な3Dプログラミングとは何かを考えていくことになる。DXRubyの思想にあう3Dプログラミングとはどういうものか、と言ったほうがいいか。
バグとか互換性とか
Ruby合宿担当の野坂さん(@hnozaka)に聞いてみたのだが、バグを踏み抜いて大変なことになった経験は無いそうだ。また、バージョンアップで互換性が無くなって苦労したことも無いらしい。バグについてはそれなりにテスト＆実際に使ってからリリースしているが、環境によって出るものもありそうではあるのでラッキーという感じである。互換性はかなり気をつけているので基本的に過去のコードが動かないことはほぼ無いはず。はじめの頃はひどかったと思う。
それとは別に、Smalrubyのコードを見てたときにDXRubyのバグ回避的なコードとコメントを見た記憶があるので、あっちのほうではそういう点で苦労させてしまっていたかもしれない。高尾さんに同じことを聞かなかったのは俺のミスだが、とはいえイチイチ報告しろとも言えない。回避可能なバグであれば回避してもらって、コミットログなりコメントなりにちょろっと書いておいてもらって、俺が見に行くのがよいかなー。
ビルド環境
現在、Microsoft DirectX 9.0 SDK (October 2004)を使っている。恐ろしく古いSDKを使い続けているのはワケがあって、これがスタティックリンクできる最後のバージョンだからである。ダイナミックリンクするものはSDKのバージョン以上のランタイムが必要で、ランタイムが古いと変なエラーが出て質問が大量に来てしまうのでそれの対策という形。いまどきならすでにあまり問題にならないのかもしれない。どうでもいいがスタティックリンクしたほうがパフォーマンスは良くなる。
使っているコンパイラはVC2008。リンクするRubyの対象はRubyInstallerのmingw32版なので、元々はVC6.0でビルドされたRubyが無いと作れないのだが、かなり強引な方法を使うことでVC2008でビルドしている。ビルドしたいという人がいた場合にうまいこと説明できないのでどうしたものかと。
64bit版のRubyInstallerのバイナリにリンクする拡張ライブラリはどうやって作ればいいのかはまだ調べていないが、Devkitでビルドすれば動くだろうとは思う。問題はDirectXをそれで簡単にリンクできるのかというところで、mingw-w64ならDirectXも入ってるとかなんかそんな話を見た気もするが、そしたらmingw64のRubyとリンクできるのかどうかという話になって、結局よくわかっていない。いずれ試す必要があるだろう。
オープンソースソフトウェアについて
ふと思ったので書いておく。
勉強会的なものにDXRubyを使ってもらっているが、俺のほうはそれを狙って作っているわけではない。俺が作りたかったもの、自分で使いたかったものが、他と比べてフィットしたという話である。
当然、他にもっといいものが出てきたらそっちに乗り換えるだろうし、例えば俺が飽きてやめるとか、俺の好みを追求していったらフィットしなくなったとか、もっと予算がついて勉強会用にライブラリを開発することになるとか、そういったこともありえる。
つまりは、俺がやっていることと、島根・松江がやっていることが、今の時点で偶然クロスしたということであって、その「ゆるさ」や「一期一会感」こそがOSSのあるべき形なのかもしれない。もちろん、どっちかがどっちかに影響を受けて方針が変更されることもあるだろうし、フォークされることもあるだろう。その辺まで含めてOSSとはそういうものだ、と思う。
おしまい
まあ、こんな感じ。
DXRubyは1.4.1をリリースして一区切りしたので、今後は大きな新機能について検討していくことになるだろう。現状のままそれらが追加されるのか、それとも大きく書き直してDXRuby2.0(仮名)になるのが先か、それは今のところまったく決まっていない。
松江Ruby会議05に参加して知名度が上がってダウンロード数が急上昇、ってことも別に無いようなので、まあ、いつもどおりに地味に続けていこう。
2014-03-18
松江Ruby会議05に参加してきた(2)
前回は講演の超主観的な感想であった。全体的にレベルが高いのは松江だからなのか、それともどこに行ってもこんな感じなのか。
自分が普段置かれている環境に若干の疑問を持ちつつ。次いってみよー。
松江、島根の取り組み
Ruby合宿、中学生Ruby教室、Ruby.Jrなど、Rubyの勉強会的なものを自治体が主体でやっている。いずれもDXRubyを使ったり、使わなかったりしていて、また、よくわからないのだが、NaClが関係していたり、していなかったりするようだ。
Matsue.rbのTシャツを着ている人がMatsue.rbのメンバーなんだろうという気がする。県とか市の人も着ていた。このあたり、特定個人が組織やコミュニティにかぶって所属していると思うので実態がいまいち把握できていない。
結局のところ、誰(どこ)が具体的に何をしているのかというのは妙にややこしくて、というか理解が足りてなくて、うまく説明できない。ともあれ、それぐらい渾然一体となってRubyを広めようと頑張っている、と考えるのがよさそうだ。
実際に教えている人の話
県や市の人とは懇親会で酔っ払った状態で話していたから、記憶が怪しいことになっているわけだが、まあ、それでもいろいろと話してきた。
・DXRubyはプログラム初心者に興味を持ってもらうのに良い
・数えてみたら松江の中学生の100人に1人ぐらいはDXRubyを使ったことがあることになるらしい
・ごく普通のJC(原文ママ)が楽しそうにデバッグしていた
などなど。
DXRubyについては「これがあったからこういう活動をしていけている」というお言葉をもらった。まあ、多分にリップサービスが入っているだろうとは思うが、少なくとも使われている、選択されているという状況が俺にとっては嬉しい。
DXRubyを使っている理由
島根・松江の取り組みについて、前にTwitterで「担当者の趣味でライブラリ選んでるんじゃね」ってなツッコミを見たことがある。
俺自身、そうなのかなーとか思ってたのだが、実際に担当の人などに話を聞いていると、選択されたポイントというのがなんとなくわかってきた。俺的解釈だが。
・初心者や子供にRubyを教えるのに、まず興味を持ってもらうのが大事。ゲームは題材として大変良い。
・ゲームを作るからと言って低レベルレイヤの知識から始めるのは無駄。そもそもそこはRubyじゃない。体験して欲しいのはRubyなのだ。
・高度なゲームを簡単に作れるようなツール系のものはツールを使う技術を教えることになってしまうのでよろしくない。
つまり、低レベルレイヤを極限まで抽象化して、ゲームのアルゴリズム部分のサポートは呆れるほど無い、Rubyで書いたコードがそのまま目に見える形で動く、そういうライブラリを所望していた、というわけだ。他の色々なライブラリと比較した結果として、DXRubyが選ばれたという話であった。当然ながら、今後もずっと選ばれ続けるという保証は無い。
Smalruby
話は変わるが、Ruby.Jrの発表会のとき、高尾さん(@takaokouji)がSmalrubyを実演していた。SmalrubyはRubyAssociationの2013年度助成事業に採択されたもので、子供向けRuby学習教材一式を作るプロジェクトである。助成金の対象はこの一連のプロジェクトのうちのsmalruby-editorとなっているようだ。Scratchのようなブロックを組み立ててプログラムを作る感じのものである。
実演していたのはGoogle blocklyをベースにしたもので、ブロックを組み上げた結果がRubyのコードとして出力できるようになっていた。逆に、出力されたRubyのコードを修正するとブロックの構成も変わる。これはすごい。
このsmalruby-editorで出力されたコードはローカルにダウンロードしてSmalrubyのライブラリ上で動かすわけなのだが、Smalrubyのライブラリのさらに低レベルレイヤがDXRubyである。最初にSmalrubyのコードを見たときに、変わったAPIだなーという印象を持ったが、ブロックの構造をそのままコードに落とすことを想定して作っていたと考えると納得。ぶっちゃけDXRubyの面影は無いが、別に問題も無い。
高尾さんはdxruby_sdlも作っていて、これはSDLにかぶせるDXRuby互換APIライブラリで、SmalrubyもWindows以外の場合はdxruby_sdlを使うように作られているようだ。ただ、SDLを使うとどうしてもフレームレートは下がってしまうから、そのあたりをどうしていくかは悩むところだろう。Ruby/SDLのSDL2.0対応誰かはよ。SDL2.0はRenderTargetオブジェクトを作れるから、DXRubyのShader以外はほとんどそのまま実装できるはずだ。
BASICとの類似点
この件については去年、土屋つかささん(@t_tutiya)がDXRubyAdventCalendar2013で書いていたが、ちょっと上に書いた選択されたポイントはおそらく昔のBASICにそのまま当てはまる。
最初に少しコード書いて動かしたときのインパクト、これは面白い、と思う初っ端の感覚は、それ以後「プログラムは面白いものだ」という意識を形成するのに重要なのではないかと思う。その意識がある人はたとえ作るものがゲームじゃなくても、プログラムそれそのものが楽しいものだと思える。かもしれない。
DXRubyを推してくれている人たちの年齢層もなんか近いものがありそうだし、その使い勝手、感覚にピコーンと来る人は、当時BASICをいじっていた人か、DXRubyでそれを感じた人かのどちらかである可能性は高そうだ。
ちなみに俺もその世代ではあるのだが、別にBASICを意識して作ったわけではない。自分で使いたいものを作っていたらこうなったのだ。ひょっとしたら当時の感覚を現代に再現したかったのかもしれん。知らんけど。
現在の状況として
Ruby合宿に参加した人が既に社会人になっている。実際、NaClの資本が入った会社にそういう取り組みの参加者がいるとのこと。そしてその人は松江Ruby会議05にも来ていた。ITで、Rubyで街起こしをしようという松江にとって、何もしなかった場合と比べてそっち方面に興味を持って進む人、何かしら関わりたいと思う人が増えるのは大変よいことだろう。
前出の高尾さんのブログにこんな記事がある。そういう感じなんだよね。何かしらの影響は与えていて、それがすごく大きな動きになるかというとわからないけども、間違いなく少しは影響が実際に出ていて、だからモチベーションを保って進めるし、県や市からも予算が出るし、市立中学校でRubyの授業をするとかいう話にも展開するし、これから先、もっと変わって行くはずだという希望も持てる。
そういう島根県や松江市の動きに俺が何かしら貢献したかというと、なんというか、やった事は自分用に作ったものを公開しただけでぶっちゃけ副作用としか言いようが無いのだが、OSSってそういうもんだとも思うし、いずれ歳食ったときに松江がRubyで発展してたりしたら、「松江はわしが育てた」とか適当に爺くさいコト言ってればいいような感じで、何が言いたいのかよくわからんくなってきたのだが、まあ、俺にできることはDXRubyを作ることぐらいなので、それを活用できる人が活用してもらえると良い。
他になんか手伝えることありますか、とか聞いてみてもたぶん、いや、いつもどおりに作っててください、みたいに言われちゃうんだろうな。OSSってそういうもんだし。
おしまい
ところで、TwitterでMatzにMatsue.rbのTシャツを贈呈する写真が出ていたけど、実は俺もあとでもらった。どっかのRuby会議に参加することがあれば着て行こうかなーと。
2014-03-17
松江Ruby会議05に参加してきた
2014/3/15(土)、島根県松江市にてMatsue.rb主催の松江Ruby会議05が行われた。それのゲスト講演をしてきた。
島根県がやっているRuby合宿でDXRubyが使われているという繋がりでDXRubyに関する講演の依頼が来たので、ちょっと喋りに行ったという経緯である。
懇親会含めていろんな人と話したし、こっちで細々とライブラリ作ってるだけではわからない松江の現場の話を色々と聞けて、非常に楽しかった。まとめるにもどうまとめたらいいのかよくわからない感じになっているので、何回かに分けて感想などを書いていくことにする。
まずは講演の感想から。
Matzの基調講演「Prepend Your Class」
Ruby2.0とRuby2.1での新機能について、及び、Ruby2.0で追加されたModule#prependの話。
Module#prependはこのブログでも過去記事で軽く紹介しているし、Ustreamで録画されているのでそれを見るとたぶんよくわかる。
Matzの話ではアスペクト指向を実現するために必要な機能だと言う感じで、なにやら難しくてわからないのだが、後の前田さんの講演で具体的に使用されている。といってもこっちも難しい。
重要なのは継承階層の下側に追加されるという点で、複数のクラスに対して共通したコードを最も優先度の高いところに追加することができる。includeが存在しないメソッドを追加する用途で、prependは存在するメソッドをオーバーライドする用途である、という部分か。
DXRubyでどう活用するかは難しいところで、少なくとも最低対応バージョンが2.0にならないと使いにくい。ま、使わないといけないわけでもないからいずれ何かいい用途が思いついたらまた試すという感じに。
俺の講演「DXRubyのご紹介」
DXRuby関連で初めての講演なので、軽くゆるく紹介する感じで、って思っていたのだが、松江Ruby会議05の参加者は化け物みたいな人がゴロゴロしてたので舐めてかかっていたかもしれない。そもそもMatsue.rbメンバーのDXRuby関係者率が高くて紹介しなくても知ってるよって感じ。参加者には知らない人もおったと思うけど。
USTは恥ずかしいのでここには書かないが、上のんから辿れば出てくるのであまり意味は無い。どのように話したらどのように見えるのかというのが全く未体験ゾーンだったのでお見苦しい姿を見せてしまって申し訳ない。などと意味不明の供述をしており。
さて、話した内容は軽い紹介程度ではあったが、ともかくシンプルで初心者フレンドリーである、という点に絞ってみた。実際にはそのように使えるものにするためにそれなりの時間と作業量がかかっている。簡単に使えるものは簡単に作れるわけではないのだな。後で他の人と話したときにはそういう質問も出ていて、実装的な話とか、最適化関連の話とか、あそこにいた人たちはそこから話し始めてもいいレベルだったのだろうなと思った次第。
後半のライブコーディングは、TeraPadひとつで0からコードを書いてブロック崩しを15分で作るというネタ。使ってたノートPCは借りたもので、「RubyとDXRubyとテキストエディタがあればいいです」って言っておいたらほんとにそうなった。知らない開発環境を入れられててもたぶん使えなくて焦ることになっただろう。テキストエディタだけで作れるという実演にもなったのでよしとする。
実は時間が足りなかったときに3分間クッキングよろしく完成品を出そうかとも思っていたのだが、何も準備しないことにした。勇気と無謀は違うものだということを身を持って知ることにならなくてよかった。
ライブコーディングのネタはいくつか考えていて、10〜15分で作れるものとして、簡単なシューティングゲームとか、簡単なジャンプアクションなども検討していたのだが、シューティングはクラス定義しないと辛いし、ジャンプアクションはマップ作ったりするのが面倒なのでやめておいた。ブロック崩しが一番手軽だった。それぞれ2回ほどコードを書いて試したというのは裏話である。ブロック崩しは最初に書いたものがライブコーディングで書いたものとほぼ同じ内容・時間で書けていたので、完全にぶっつけ本番でも15分でいけただろうと思う。しかしそれは完全に無謀な試みである。
貧相なものができあがっていたわけだけども、俺が目指すのは簡単に豪華なものが作れるライブラリではないので、このライブコーディングそれそのものがDXRubyとはどういうものかを如実に表していたのではなかろうか。
橋本さん「ちょっとるりまでも更新してみようか」
bitclustを使ってるりまを更新する作業のライブコーディング。なんか難しくてよくわからんかったのだが、ブラウザがるりま用カスタムだったりRubyのソースまで見てるりまを更新するというのは凄味があった。
普段、リファレンスマニュアル書くの面倒だなー誰か作ってくれないかなーとか思っていたが、作ってる人じゃない他の人がマニュアルを書くのはそれはそれで非常に大変な話なのだと言うことがよくわかった。
これぐらいすごい人がマニュアル書いてくれたら確かにできるんだろうけど、そんな人がDXRubyのマニュアルを書くのはまず間違いなくオーバースペックである。
がんばって書きます。
木村さん「RubyMotionいつやるの？」
RubyMotionでiOS用のアプリを作るという恐ろしいライブコーディング。そこに書かれたコードで実際にiOS用アプリが動くというのはライブコーディングならでは。るりまのやつもブラウザで見るマニュアルが変わっていくし、これは面白いなあ、と思った。俺のんも貧相なブロック崩しが少しずつできていったので楽しんでもらえたのかしらん。
そういえばRubyMotionというのは存在は知ってたけどコード見たのは初めてだった。Objective-Cから呼ぶメソッドをRubyから叩けるのだな。クラス名やメソッド名が恐ろしく長かったのはそういう文化なのだろうけども、Rubyの文化とは明らかに違うので好みの分かれるところだろう。
直前にエディタを変更した都合で最後のほうは時間が足りなくて動くコードをコピペしてたけど、よく考えると少しずつコピペして動かして見せるのとキーを叩くのは理論的には違いが無い。見ている人が「こうやって開発するんだなあ」と感じる量が変わるという感じか。ライブコーディングの価値はまさにライブ感なのか。
この後の前田さんが「ライブコーディング失敗する人が多いので準備してきました」的なことを言ってたのは、動くかどうかよりもライブ感を大事にしていたと言うことなのかな。
前田さん「Module#prependとRefinementsで遊ぶ」
Matzの発表であったprependをベースに、アスペクト指向的なコーディングをするという発表。用途として想定されているログの取得を実現する、という内容だった。Refinementsは後のほうでちょこっとだけあった。
実際のところ、prependは今のところそんなに使われている感じは無くて、たぶんきちんと設計されたクラス群に対して使うものというのがあって、ちょっとしたコードでは使いにくいのもあるんじゃないかと思っている。動作の理屈自体は簡単なものだから、例えばDXRubyでゲームを作る場合に有用な使い方というのもありそうではある。
Refinementsを使った例はちょっと面白かった。標準のクラスのネームスペースを汚染しないように拡張して局所的に使うことができる。これはDXRubyでは例えばSpriteの配列に対してupdateするのに、Sprite.updateを使うんじゃなくて、Array#updateを追加するような暴挙を、自分のコードの一部分に限定してできるわけで、うまく使えば便利そうである。このような使い方ができるのがRuby2.1からというのが残念だが、いずれRuby2.1がいくらなんでもそれは古いやろーと言われる時がくると思うので、知っておくとよい。
あと、リファクタリングしてクラスを移動したらselfが変わってしまう問題の対策とか、めっちゃメタプログラミングでクラスやメソッドを抽出したりするあたり、勉強になる。
高尾さんと岩石さん「takaokoujiとrockzeroのぶつかり稽古」
最初の簡単な問題は簡単だったが、いきなりFizzBuzzになってレベルが跳ね上がった。高尾さんがお父さんみたいだったｗいいコンビである。
4x4のルービックキューブって初めて見たけどあれは無理だわー。3x3でも無理なのに。
Ruby.Jr
ライブコーディング大喜利には参加せず、Ruby.Jrの発表を見ていた。機材がMacということもあって、RSDLを使っていたようだ。RSDLはMacで動くようにSDLを組み込んだRubyで、くまりゅうさん作。くまりゅうさんはRikoの人。ずっと前にRubyでゲームを作る発表をRuby会議2009でしていた。当時はRubyでゲームが盛り上がっていて、カンブリア紀の進化の爆発のように色々なライブラリが出ていた。DXRubyをSourceForgeで公開したのもちょうどこの頃で、これは偶然である。なんせDXRubyのプロトタイプは2005年。まあそういう話はまたいずれ。
ともあれ、Ruby.Jrの発表会で若い子たちが自分で作ったものを一人一人発表していた。Ruby.Jrは中学生Ruby教室などに参加したあと、継続して学ぶ場として月1回、全7回というペースで行う勉強会で、当日は最後の発表の日だった。終わる頃には参加者とスタッフの人と俺と野坂さんぐらいしかおらんかったような気が。Ruby合宿みたいな豪快な成果物じゃないからしょうがないのかもしれんけども。
見てて思ったのは、SDL1.2では辛いな、ということ。ぶっちゃけ、速さは力だな、と。
Ruby用にSDL2.0のライブラリが出ると状況も変わるんじゃないかと思う。開発されているものがひとつあるのは知ってるけど。
おしまい
松江市や島根県の取り組み、こっちにいてはわからないような現場の感覚や状況など、そういう話は後日。
それから、DXRubyに対するリクエストや質問、使ってる人たちの言葉なども生で聞いてきたのでそういう話も後日予定。
最後に、ライブコーディングで書いたコードをのっけておく。