Jewel-mmo開発日記

みなとRuby会議やるよ

2012-04-02T00:00:00+09:00

みなとRuby会議やるよ

Yokohama.rb主催の地域Ruby会議「みなとRuby会議」を6/2に開催する。

年末のYokohama.rbでメンバーに地域Ruby会議の開催を提案したところ瞬く間に十数人のスタッフが集まり、いま着々と準備が進んでいる。最大120人くらいの規模になりそうなので、Yokohama.rb主催のイベントとしては圧倒的に過去最大。

「みなと」という名前は2010年に@1syoから提案されたもの。 Yokohama.rbがはじまって間もない頃に提案されて当時はどうしたものかと困ったけど…。言い出しっぺの法則により実行委員長は@1syoにお願いすることになり、実行委員長@1syoのもとスタッフが編成され、実行委員長@1syoを中心に以下のようなすばらしい開催趣意も作られた。

横浜ではじめての地域RubyKaigi、『みなとRuby会議01』を2012年6月2日に開催いたします。

『みなとRuby会議01』のテーマは「はじめの一歩」です。

はじめてRubyを使う方、はじめてRailsを使う方、はじめてコミュニティに参加する方、皆さまそれぞれの「はじめの一歩」をコンセプトにプログラムを企画しました。

6月2日は横浜港が開港した日です。私たちクルー（みなとRuby会議実行委員）は、この開港記念日に「はじめの一歩」を踏み出します！

皆さまのご来場を心よりお待ち申し上げます。

こうして振り返ってみると何もかも@1syoにみえるけど、突進力半端ない@1syoプロジェクトのフォロー役に副実行委員長@satococoaもいてくれるし、他のスタッフも意欲的なので、きっと面白いRuby会議が実現できるのではないかと…。

最後に。詳しいことは近々発表されるはずだけど、会場は真の横浜らしさを存分に実感できる場所にあるので、皆さま覚悟の上是非ともご来場ください。

そうそう、3年後はパシフィコでやるよ！

Oink Gamesに入社しました

2012-04-01T00:00:00+09:00

Oink Gamesに入社しました

この4月より株式会社オインクゲームズに入社しました。

Oink Gamesはボードゲームを作っている小さな日本の会社です。

日本のボードゲーム市場は世界と比べてまだとても小さいのですが、でもそんなかでOinkは企業として着々と製品をリリースしはじめました。事業の規模もまだまだ小さく、売上も多くはないため、制作にかけられるコストは限られています。そんな中あくまでビジネスとして、ユニークな商品を産み出してくる代表の@44giには強い創造力を感じています。

Oinkは"ゲーム"を作る会社です。既存の枠にとらわれることなく、広い意味でのゲームを、作り手が楽しみながら作り続けていく...そんなOinkの方針がとても好きです。

Oinkへの入社は個人的に重要な決断です。本当にやりたい事、小さなチームでスピード感をもって勝負するということ、にこれからの人生を賭ける意思表示でもあります。大きな決断にもかかわらず迷うことなくOKしてくれた妻の理解に感謝しています。

Oink Gamesははじまったばかり。この先どんな新しいことにも挑戦できる自由さと可能性にわくわくしています！

Oinkともども、これからもよろしくお願いします！

RubyKaja(冠者)が面白くなりそう

2012-03-30T00:00:00+09:00

RubyKaja(冠者)が面白くなりそう

前回のYokohama.rb で@nagachikaが提案したRubyKajaが面白いことになりそうだ。

発表直後から話題性抜群。

プロデューサーに指名されてしまった@dan5yaとしては中途半端なことは出来ないと覚悟を決めて、 Yokohama.rbメンバーと緊急ミーティングを開催した。

個人的に難しいと思ったのはここ。

これまであまり知られることのなかった Rubyist が認知されるきっかけにして、一層コミュニティ活動を推奨して Hero 候補を産み出していくというような方向になってくれるといいなと考えました。

http://d.hatena.ne.jp/nagachika/20120312/ruby_kaja

発表後の反省会で話していたときは、一般投票で決めるという形をみんな漠然と想像していたと思う。でも、多数決だと "知られることのなかった Rubyist" ではなく、ある程度有名な人が選ばれることになって、当初のコンセプトとずれてしまうのではないかいうのが心配だった。

かと言って、誰かが審査員になって選ぶという形だと審査するにあたって難しい問題が出てくるだろうし、運用のコストも高い。コストが高い方法は継続が困難になるので極力避けたい。Yokohama.rbのテーマは継続である。10年続く枠組みを考えぬいて苦なく継続させてこそYokohama.rbのやり方である。継続は力なり。

というのを緊急ミーテイングに参加しているメンバーで共有できてしまえば、さすが勢いのあるメンバーとばかりにどこからともなくさくっといいアイデアが出てきた。これは本当にいいアイデアだと思う。そしてとっても面白い試みだと思う。具体的なことは6/2の「みなとRuby会議」で大発表するのでお楽しみに。この夏には世界のRubyistの中から初のKajaが誕生しているはず！

Kaja担当としていち早く名乗りを上げてくれた@tyabeありがとう！そしてこれまたいち早く手伝いたいと言ってくださった日本Rubyの会のみなさま今後とも協力をよろしくお願いします！

http://nagachika.tumblr.com/post/19945144717/yokohama-rb

さて、大変残念なことだけど@nagachikaは神奈川をはなれてしまうことに。 @nagachikaは、Yokohama.rbは当然のこと、その前の横へなふつける本読書会から神奈川地区センターでの勉強会を盛り上げてくれていていたメンバーである。個人的にはRuby以外でも通じるところがあって、Rubyを使い始めた当初から交流のある友人であり、そのただならぬ関係を見抜いていつも生暖かく見守ってくれた@publichtmlさんどうもありがとうございました。

最後にすごいものを提案してきてくれてありがとう！別に最後じゃないけど。

てすと

2012-03-28T00:00:00+09:00

てすと

書き込みテスト。

UnityでCoffeeScriptを使うのは諦めた

2012-03-23T00:00:00+09:00

UnityでCoffeeScriptを使うのは諦めた

CoffeeScriptで生成したJSをUnityで動かそうと頑張ってみたのだけど挫折。

例えば、UnityではこんなのがNG。

var a, b;

以下のように書き直さないといけない。

var a;
var b;

これはほんの一例。

で、次に考えたのはNodo.jsとUnityの両方で動くように気をつけながらJavaScriptを書くということ。

でもこれさえも断念。UnityのJavaScriptはふつうのJavaScriptじゃなさすぎる。（JavaScriptの定義を調べてないので正しくないかどうかはわからない。）

というわけでC#を試してみた。 C#は今まで1行も書いたことがなかったので、まずはMac上でC#を動かすべくMonoをインストール。（今回入れたのはMonoFramework-MRE-2.10.8_3.macos10.xamarin.x86.dmg）

普通にインストールするだけでターミナルからC#が使える！

ただ上記dmgをインストールするだけで、以下のようにしてコンパイルと実行ができちゃう。

mcs hello.cs
mono hello.exe

さっそくFizzBuzzのコードを探してきて、それをMac上とUnity上とで動かしてみる。動くっ！動くぞっ！

というか、そもそもUnityのC#はMonoを利用しているそうで、少なくとも言語部分については安心して使えそうだ。

なんでMac上でも動かしたいかというと、可能な部分だけでもMac上でテストしたいから。ゲームの開発環境は、特殊なハードと特殊なライブラリを特殊な開発環境で使うことになるのだけど（例えばUnity）、これがプログラミング環境として使いやすいとは限らない。特にコードを書き換えてから実行結果を確認するまでの時間的なサイクルが遅くなってしまうのがいやで、部分的だったとしてもコンソールからビルドして実行したくなってしまう。極力マウスも使いたくない。

グラフィカルなキャラクターの動きなどは実機で動かしながらでないと作り込めないし、作るのにある程度時間がかかってしまうのはしょうがない。でもどんなゲームもビジュアルと関係ないロジックの実装は存在するので、この部分の開発に関してはターミナルの中で完結してテストできるようにしておくことで開発速度が飛躍的に向上するのだ。

UnityでCoffeeScriptを使えないものか…

2012-03-17T00:00:00+09:00

UnityでCoffeeScriptを使えないものか…

Unityでちょっとしたアプリを作ってみたい思ってて、ゲームのモデル部分（映像表現と直接関係ないところ）をCoffeeScriptで書いてローカルのPCとかWeb上でゲームロジックの検証とかテストができたらいいなと。

でもこの作戦はたぶんダメで、というのは聞いたところによるとUnityのJavaScriptは、 JavaScriptっぽい何かでしかなく、CoffeeScriptの出力したJSを実行させるのは難しい… と噂に聞いている。

とりあえず、node上でスクリプトを書いて、それがどこまでUnityで走るかを試してみようかと。

gumroad で電子書籍を公開してみた

2012-02-28T00:00:00+09:00

gumroad で電子書籍を公開してみた

http://dgames.jp/books/

電子書籍の公開と言っても大したことではなくて、以前ブログに書いたネタを手直ししてPDF化し、そのURLをgumroadで売るという簡単な試み。 gumroadの可能性を探るのになにかやってみるかーというわけでやってみた。

しかし実際にやってみるとgumroadで何かを売るのはほんと簡単。売りたいものをWeb上において、そのURLとタイトルと価格を入力するだけでいい。

これからは数は多くなくても着実に応援してくれるファンを持っている人が、ものづくりしやすい世の中になっていくんじゃないかなーと思った。

C言語を知ってて良かった話

2011-10-21T00:00:00+09:00

C言語を知ってて良かった話

低級言語Rubyの世界。

メカじい「まだいたのか。いつまで突っ立てるんだ。他の連中はとっくに行っちまったぞ。暗くなる前にささっと帰れ」

子供「あの…。何か仕事はありませんか…？」

メカじい「仕事？人を雇う余裕なんてねぇよ。前らが知ってるマシンランゲジなんてここじゃ何の役にも立たねぇ」

子供「あの一応Rubyが書けます。あとCも少しだけ…」

メカじい「なんだと！Cが書けるのか！？」

子供「はい。古い井戸の水汲みをRubyで制御してて…あの重量センサが調子悪くって、Cで拡張して…」

メカじい「……」

子供「その…ただIOの調子悪かっただけで繰り返しリトラ…」

メカじい「んー、金曜の夜だけ店の灯りが消えねえんだ。ちょっと見てくれ。安心しろお前らの大好きなマシンランゲじだ。パスワードは…」

子供「はい！」

36歳からでもリフティングはうまくなるか？

2011-10-20T00:00:00+09:00

36歳からでもリフティングはうまくなるか？

夏に36歳になった。36と言えばプログラマを引退すべきと言われるかもしれない年齢だ。

35歳までしかプログラミングできないかどうかは興味深いところではあるけども、それはさておき、今日はリフティングについて考えてみる。

このところの週末は特別な事情がない限り、3年生の息子の通う地元の少年サッカーチームで親コーチをしてる。コーチと言ってもオレはもともとサッカー経験者ではない。とはいえ、コーチの役割はサッカーの手本を子供に見せることだけではないし、小さな子達をまっすぐ並ばせるだけでも骨の折れる作業なので、仕事はいくらでもあるのだ。

今年でコーチ3年目だけど、3年生になると子供の成長力が急激に上がるのを日々目の当たりにしている。おそらくゴールデンエイジと言われる12歳あたりではより高い成長力が期待できるのだろう。小学生の間でリフティング回数も10回程度から100〜1000回程度まで劇的に上昇する。

では大人のリフティング力についてはどうだろう。

2年半コーチをやってきた経験からすると、30代後半が中心メンバーであるコーチ達のリフティングはほとんど上達しない。上達するどころか衰えていくこともあるはずだ。

でもコーチの中にも例外はいる。もともとスポーツが得意だった38歳のあるお父さんコーチは、少し前からサッカーを初めてとんでもないスピードで上達しているし、うちのチームではオレも例外的な存在。子供の頃からサッカーはおろか運動全般が苦手だったけども、リフティングだけは30歳を過ぎてから100回を超えた。これまでほとんど右足だけでしか蹴れなかったので、今は左右の足で交互に蹴るパタンを練習している。これも練習しただけ着実に回数が上がる。

オレがボールを蹴り始めたのは28歳のとき。職場のメンバーとでフットサルをはじめたのがきっかけ。リフティングは最初は5回を超えるのも大変だったが、その後の地道な練習で最高170回をマーク。リフティングの練習時間はたぶんトータルで30時間くらい。最近は暇があると左右両足のリフティングを練習してるけど、練習時間は年間で2時間いかないくらいのペースじゃないかと思う。想像だけど単位時間あたりの上達量は、ゴールデンエイジには負けそうだけど、普通の子供には引けを取らないペースじゃないかと思う。

これは練習さえすれば誰でも出来ることだと思う。つまり単に練習をするかしないのかだけのことだ。

お父さんコーチは子供の頃サッカーを経験してた人が多いのだけど、リフティングが得意でない人もいる。30回続かない人もいる（今の子どもはレベルが高い！）。そもそもリフティングが得意でないコーチはリフティングを見せてくれない気がする。100回出来るまでやり続けろ言われたら果たして何割が合格できるだろうか。

さて、30歳を過ぎてからリフティングの練習をしていたオレからすれば、そんなコーチたちがすぐに上達するだろうことは簡単に想像できる。何もやってなかったオレとはそもそも足の器用さがぜんぜん違うのだから。今からでも少し練習すれば着実に上達するはずなのだ。

しかし、ある程度以上のスキルを既に獲得しているコーチが上達する例は見たことがないし、これから先も上達する気配はない。あくまでうちのチーム内の何人かを見ての話ではあるけども。

なんにせよ結局のところ30歳代の既にサッカーのできるコーチたちはもううまくなりそうな気がしないのだ。これはリフティングに限った話ではない。なぜだろう？

今さら練習したところでもう上達しないと思い込んでいる
努力してまでうまくなりたいとは思っていない
そもそも上達することに興味がない（それなりにできるので特に困っていない）

こんな理由じゃないかな。これは実質的に限界に達しているということかもしれない。でももっとうまくなれる可能性は多分にある。第一線で活躍してるプロなら話は違うだろうけど、ある程度のレベルまでならこの年からでもサッカーにおいて上達できる要素はたくさんあるはずだ。

で、自分がプログラマーとして既にこれ以上成長できないほどのレベルかといえば、全くそんなことはないわけで、なんだか似た話かもしれない。最近リフティングやってなかったけど、もう少しだけ積極的に練習継続してみよっと。　

一瞬でiPhone付属イヤホンの低音を2.5倍響かせる方法

2011-10-19T00:00:00+09:00

一瞬でiPhone付属イヤホンの低音を2.5倍響かせる方法

これは曲のベース音などの低音をよく聞きたい時によく使う手法。

iPhoneやiPod付属のイヤホンを用意
音量を少し大きめにする
両手の中指の腹で左右耳のイヤホンを軽くおさえる

音が小さいと効果を感じにくいので屋外で試すと効果的。あと指先ではダメ。指の腹、指紋のうずまきの中心をイヤホンにあてること。

前はイヤホン苦手で外で音楽聴けなかったんだけど（耳が痛くなった）、この Appleの純正イヤホンは楽に使えて shuffle 以来ずっと愛用してる。

息子がプログラミングをはじめた

2011-10-13T00:00:00+09:00

息子がプログラミングをはじめた

今年3年生になった息子に前から「ゲーム作りたいゲーム作りたい」と言われていた。プログラミング環境を用意してあげたいと思っていたところ、同僚の @fum1h1ro がMacbook Air 11インチ（昨年のモデル）を格安で譲ってくれた。

というわけで息子のプログラマー人生がスタート。

したのだけど、どうやってプログラミングを練習させたものか難しい。

さしあたって初日はターミナルからirbを開く方法を教えて、そこで変数の初期化と乱数と足し算を教えた。具体的にはこんなの。

hp = 1
hp = hp + rand(10)

息子の性格を踏まえてこのような地味なところからのスタートしている。好きなことに対してだけは粘り強くて、そして単純に小さい頃から数字が好きだったので、こんなやり方が許されているところは多分にある。

で、こっから先どうしようかなと悩んでて、いい方法ないかなあ...。

そもそも3年生だと、持っている知識が少なくてなかなか難しい。とはいえ、国語の教科書を引っ張り出してきてアルファベットを使ったローマ字表記を一気に覚えてしまったくらいやる気はある。

子どもがプログラミングを学ぶにはやっぱりゲームかな。irb上でメソッドを呼び出していくことで進行させられるゲーム。息子はしょっちゅう武器やモンスターなどのゲームデータを紙に書きまくってるから（ほんとにとんでもない量の…）、アイテムやその発生率をCSVか何かで簡単に定義できると面白そう。

ただ単にアイテムリストを一覧表示するプログラムなんてのも好きそうだ。自分で作ったリストがゲーム即座に反映されたりHTMLで表示できたりしたらそれだけで楽しそう。

irbくらい容易に開始できるならJavaScriptの方がいいかもしれない。JavaScriptならブラウザ内に簡単に図形や画像を描画できる。node.jsを使えば当然irbみたいなことも出来るだろうし応用範囲が格段に広い。CoffeeScriptもいいかもしれないなあ。

そう考えると昔98上で動かしていたN88-BASICはすごかった。パソコンの電源を入れれば勝手に起動して、その場でソースを編集できて実行できて、文字だけじゃなくて線や円がスクリーンに描画できて、シンプルなマシン語世界に簡単に入ることができたりしたわけで。

#yokohamarb のRubyレシピブック読書会が面白い

2011-10-09T00:00:00+09:00

#yokohamarb のRubyレシピブック読書会が面白い

@1syo が中心となって開催している Rubyレシピブックを用いたYokohama.rbでの恒例セッション。昨日で3回目だったかな。

これが面白い。どういう意味で面白いかというと、まず単純にRubyを深く学ぶことができて面白い。ふだん何気なく使っているRubyの機能も、ちょっと掘り下げてみれば知らないことが山ほど出てくる。そして、ふっと湧いた謎をその場の参加者みんなで考察してゆく流れがとっても心地良い。

昨日は「008繰り返し」から。

008繰り返し

まず「whileは使わない」という話が出る。いやそんなことはない普通に使うでしょ。

例えばこんなの。

while e = ary.shift
  ...
end

aryがキューでここに要素が入ってきたら、要素を頭から取り出しつつ処理をしていくときとか。

会場で自分の書いたソースをgrepしてみたらこんなのが見つかった。

rand < 0.7 ? self.lv += 1 : break while true

これは可読性が低いって言われた。たしかにそうかも知れない。でもこのくらいだと1行にまとめたい衝動が我慢出来ない。

今あらためてgrepしてみるとこんなのが見つかった。

create while count < 5

これはActiveRecord::Baseを継承したモデルのクラスメソッドでやってるのだけど、こっちはwhileを使うとうまく書けるいい例じゃないかな。

untilは個人的にあまり使わないなあ。ということはやっぱりwhileを使う頻度がそもそも少ないということかもしれない。unlessは普通に使うわけだし。

もちろんforも使わない。

繰り返し処理をもう一度実行するredoは使ったことがないのだけど、これは単に自分の発想が及ばなかっただけで実際使える機能じゃないかな。

さてここで書籍に書かれていないretry（索引にも載っていない！）をネタにかつてないほど盛り上がったのだけど長いので省略。

個人的にretryは「勘違いによって罠となり得るから繰り返し処理では使えなくした」と推測してる（もしくはそんな話しを聞いたことがある気がする）のだけどどうだろう。

009メソッド呼び出し

メソッド呼び出しにおけるカッコの省略基準について質問が出た。個人的な使い分けとしてはメソッドの戻り値を利用する場合はカッコを書くという基準でやってて、でこれは青木さんのコーディングスタイルがそうだから...と説明してその場で青木さんのコーディングスタイルを読んだのだけど、そんなことどこにも書いていないっ！

それが青木さんスタイルと思ってたのだけど完全に勘違いっだのかな？青木さん本人から直接聞いたという可能性もなくはないけど...それはないかなー。

010ブロック

ブロックは難しい。持論としてブロックが理解できたらRuby中級者を名乗っていいとかねがね思っている。

C言語から来たプログラマには、以下のようなコードの仕組みと流れがまったく想像できないものである。

ary.each do |e|
  puts e
end

オレはブロックを理解するまで1〜2年ほどかかったのだけど、やっぱり他にもそういう人がいた。

そのあと1.9では変数がシャドウイングされることをみんなで確認。なるほどー。

さらに「;」を使ってブロックローカル変数が書けることを初めて知った。勉強になるー。

ary.each do |e; x|
  x = "hello"
  puts e, x
end

puts x # エラー: undefined local variable or method `x'

この節の最後にprocが出てくるんだけど、ここはまた時間がかかりそうなので次回のお楽しみとすることとした。紙面上はたった6行だけど。

レシピブックは初心者から上級者まで楽しむことの書籍として非常に良い選択だったと思う。@1syo GJ!

#rubykaigi 2011に行ってきた

2011-07-19T00:00:00+09:00

#rubykaigi 2011に行ってきた

書きたいことが多すぎて逆に書けなくなりそうなので、まとめようとせずだらだらと思いついたことを書いていく。

1日目

金曜から3泊するつもりで池袋のホテルをとっておいたのだけど、会社関係の用事でチェックインが午前4時に。忙しかったので開催スケジュールもろくに確認出来ていないまま、なんとか開始時間に滑り込んだ。もしホテルをとってなかったら何時入りになったのかわからない。

初日の最後は闇RubyKaigiだったわけだけど、できればエントリしたいなと思い立って当日に資料を書き始める。会場でスライド作りをしてたわけで、初日の発表はあまり聞けなかった。

幸運なことに闇トーカーに選ばれて「打倒tDiaryメンバー募集」というタイトルで脱tDiaryとPipinについて話させていただいた。Yokohama.rbについては我らが @1syo に丸投げして、完全に個人的な内容でいくことにした。時間切れのドラが鳴ってしまったけど、LTだしまあ最低限言いたいところまでは言えたので、自分的に目的は果たせた。

tDiary方面に対して挑発的なタイトルだけども、相手は元祖モヒカンのただただしだし、ハンドアックスを投げつけることに躊躇はいらないと思った。というかオレの攻撃力じゃカスリ傷ひとつ与えられる気がしないので、躊躇すること自体がおこがましい。なので容赦なく投げたが、投げ返される覚悟はちゃんとしてたよ。

翌日たださんに「だんさんをとっちめなきゃ」と言われたり、きたさんに凄まれたりしてたいへん光栄です。

発表内容とかPipinについての詳しいことは別エントリであとで書く。

2日目

1日目のあと、池袋でVDD方面のオーストラリア組と一緒に飲んでたのだけど、あのAndyの異様なハイテンションの中にあってコーラしか飲まなかったため体調は前日よりも良し。

さて2日目のメインイベントは「ゆRuby」。お昼に3Fの和室で「toRuby, guRuby, Yokohama.rb 出張版」という形で勉強会を開催。

しかし、Yokohama.rbの名前が入ってはいるものの、実質Yokohama.rbが貢献することは何もなくて、勉強会を勉強させてもらうために参加させていただいた次第。本当はYokohama.rbからも何か企画を提案出来ればよかったのだけど、こちらの力不足で形にできなかった。とうわけで結果的にも本当にただおじゃまさせていただいただけで、この辺でもこれからの課題が浮き彫りに。

guRubyの「初めてのRuby」読書会セッションは著者のyuguiさんに本人に朗読してもらうという豪華セッション。和室で「正座禁止」というゆるさを強制される中、yuguiさんは厳格で厳しくって、個人的にあの雰囲気のyugui先生好き。

後半はこれまた豪華で咳さんによるdRuby体験セッション。dRubyを触るのが8年ぶりくらいだったので新鮮だった。toRubyは安定感があって貫禄の存在なので、あの空気感をYokohama.rbのメンバーが経験できたのは良かったと思う。

ゆRubyにYokohama.rbが参加させてもらう形を実現したのは@1syoによる働きかけによるもので、Yokohama.rb側からすればたいへんなGJ。きっと今後の勉強会運営において、貴重な経験になるに違いない。 toRuby, guRubyのみなさま、本当になんにもお手伝いできませんでしたがいい体験ができました。本当にありがとうございました。

角谷さんの話はこれからの活動を考える上での大きなヒントになるはず。冒頭でYokohama.rbに言及していただいて光栄だった。

2日目本編終了後、懇親会の開始まで少し時間があったので、急遽その場にいた10人くらいでぞろぞろと池袋ジュンク堂で行われているというRubyKaigi写真展にいくことにした。到着すると壁に10枚ちょっとの写真が貼ってあるだけで一瞬拍子抜けしたんだけど、実際写真を見てるとどれだけいても飽きないという不思議な空間だった。2006年から毎年の写真が並んでいて、どこを見てもいろんな思い出があって感慨深い時間を過ごすことができた。行って大正解だった。

3日目

3日目はゆっくり発表を見ることができた。

特に島田さんの存在が印象に残っている。

昼にRails勉強会@東京が行われているという噂を聞きつけて3Fへ行ってみると、なんと@1syoが仕切っているではないか。最近Rails勉強会に顔を出してなかったけど、こっちでも活躍してたのね。

後半はAkitaOnRailsさんが飛び入り参加してのスピーチ。突然激アツのスピーチが始まって、英語力が足りないことを悔やみつつも、英語を学ぶモチベーションをもらうことができた。ハプニング的な展開まで含めてとてもアツイ場になっていた。

アジャイル系の本は買ったことなかったのだけど、薄くて読みやすいと聞いてアジャイルサムライを買いに行ったら、おさださんが「一番最初に売れたのはだんさんの本ですよ！！」と教えてくれて、またRubyKaigi直前に立て続けに売れちゃって在庫の調達が大変だったとか、光栄なお話をいただいてびっくり。この辺の話しを突然元気いっぱいに言われてドキッとしてしまったのだけど、あくまできのこ派なので自重。

まとめ

とにかくいろんなことが多すぎて、とても書ききれない。やっぱりまとまらないので思いついたまま書いていく。

@nagachikaのLTはとっても良かった。個人的にLTの中で一番面白かった。@nagachikaは、昨年のRubyKaigiの直後Yokohama.rbを立ち上げることをWebで表明したとき真っ先に参加表明をしてくれた人で、そのあとruby-trunk-changesがはじまったり、コミッタになったり、Yokohama.rbでも発表してもらったりと、この一年ほんと活躍してるのを近くで見てたし、何かとお世話になったり。

@1syo。さんざん話題になっていたので今更特に書くまでもないのだけど、もしYokohama.rbが100人の村だったら30人が@1syoです。というくらい彼が今のYokohama.rbを形作ってるし動かしてる。スライドでの登場回数も得点王争いに参加できるほどだったんじゃないかな。3日目はもう燃え尽きてたけど、大変だったぶんいろんなことを動かしたと思うよ。横浜の坂本龍馬。

他にもYokohama.rbのメンバーが活躍してるところや、楽しそうにしているところをたくさん目撃した。

今回、今までのRubyKaigiと比べて個人的に大きな違いがあって、それはYokohama.rbというホームがあったということ。一般参加した去年はランチにいくにしても夜ふらっと飲みに行くにしてもメンバー探しに一苦労してたわけだけど、今回はその心配がまったくなかった。ランチ行きましょうと #yokohamarb のハッシュタグをつぶやけば、誰かしらつかまるという安心感は初めての経験だった。でもこっやって内輪で仲良くしてると、外の人がボッチ感を感じちゃう気持ちがわかるので難しいんだけど、よくも悪くも今までとは全然違った。

先日一緒にハッカソンをやった姉妹rbであるMinami.rbのメンバーもともずっと仲良くさせてもらった。つじたさんとも会えて良かった。

Yokohama.rbと関係ないところでは、岡山からひとりで来たという学生さんと話す機会があってパワーを貰ったり。そして、なによりたださんと絡めて嬉しかった。また最後の席が偶然柴田(@hsbt)さんでちょっとだけPipinについて話ができたことも幸運だった。

#railshachathon ふりかえり

2011-06-26T00:00:00+09:00

#railshachathon ふりかえり

来週のYokohama.rbの懇親会でふりかえりをやるという提案もあったけど、帰りの電車でさくっとふりかえった。ただし一部の具合の悪くなった人たちは不参加。

keep

mと@watarumの参加
運営
- 段取り
minamiの人たちと交流できた
ファウンダー同士の交流。hubだから
日本酒がうまかった
山喜
- 回線
- 畳の匂いが良かった
- 一階はいろいろキレイ
- 海近
プロジェクタがあった
品評会の場所が調度良かった
13時入りは時間が確保できた

problem

募集を分けたのは？
連絡がゆきとどかなかった？
成果物の実用性が？
電源タップ
たぶん部外者が #railshackathon で不謹慎なツイートをしてた

try

次をやりたい
新しい人たちを呼びたい
第何回が参加のハードルを高くしてる
毎回が第1回
初めてでも楽しめます、と書く
時間を長く
みんな一緒の部屋で
ひとりチームをやってみたい
足りないとかない決算の方法を考える

bundlerでgemを作ってみる

2011-06-19T00:00:00+09:00

bundlerでgemを作ってみる

昨日のYokohama.rbで#railshackathonに向けたアイデアソンでいろいろ話してたら新しいブログシステムのメージが具体化してきた。

実装はbilbo以上に小さくできそうな気がしているので、もうアイデアをメモするよりもメモがわりにプロジェクトを立ち上げてしまっていいかなと。

で、どうせだから今回はgem化してみよう。

以前@jugyoに教えてもらったjewelerを使ってみようかなと思ったけど、gem作成においてより後発のbundlerを使ってみることにする（thx @takkanm @nagachika）。

雛形の作成

gem install bundler

新しいgem化するプロジェクト名をpipinとすると、

bundle gem pipin

これでpipin gemの雛形ができる。

=>
      create  pipin/Gemfile
      create  pipin/Rakefile
      create  pipin/.gitignore
      create  pipin/pipin.gemspec
      create  pipin/lib/pipin.rb
      create  pipin/lib/pipin/version.rb

Hello Pipin

ひな形として作成されたlib/pipin.rbに"Hello Pipin!"の表示を追加する。

module Pipin
  # Your code goes here...
  puts 'Hello Pipin!'
end

それとpipin.gemspecのTODO（2箇所）を書き換えてbuildする（TODOという文字列が残っているとbuildできない）。

rake build
=> pipin 0.0.1 built to pkg/pipin-0.0.1.gem

gemファイルが作れた模様。

gem install

次のようにbuildで作成されたpkg/*.gemファイルを直接指定したらインストールできた。

gem install pkg/pipin-0.0.1.gem

実行してみる。

ruby -r pipin -e ''
=> Hello Pipin!

うまくいった！

RubyGems.orgで公開

pipin.gemspecの s.authorsとs.emailをRubyGems.orgに作成したアカウントに合わせてbuildした上で、

gem push pkg/pipin-0.0.1.gem

でOK。

githubへ

githubのDashboardのNew Repositryでリポジトリを作成し、そのあと表示される以下のヘルプの手順でOK。

Existing Git Repo?
  cd existing_git_repo
  git remote add origin git@github.com:dan5/pipin.git
  git push -u origin master

oink雑談

2011-06-10T00:00:00+09:00

oink雑談

今回は全然メモとれなかった。あるプロジェクトのドラフト見せてもらって、あとはずっとデザイン哲学についての話しをしていた。

千駄ヶ谷のコーヒーはハウスブレンドだった

MacにCoffeeScriptをインストール

2011-06-07T00:00:00+09:00

MacにCoffeeScriptをインストール

手順

nvmをインストール ... nvmはnode.jsのrvm
nvmでnode.jsをインストール
npmでcoffee-scriptをインストール
環境設定（未解決）
Hello World

nvmとnode.jsのインストール

gitはインストール済み。

git clone git://github.com/creationix/nvm.git ~/.nvm
. ~/.nvm/nvm.sh
setopt no_nomatch
nvm sync
nvm install v0.4.8

最後のnvm installでnode.jsの0.4.8をインストールしている。

以下は上記にたどりつくまでの試行錯誤のログ。

git clone git://github.com/creationix/nvm.git ~/.nvm
. ~/.nvm/nvm.sh
nvm sync
nvm install latest

としたら、installのところで以下のようなメッセージが出てうまくいかない。

nvm_version:27: no matches found: v*.*.*
nvm:40: no matches found: -#
nvm: install N/A failed!

zshのときは以下を実行するといいらしい。

setopt no_nomatch

ここで改めてもう一度、

nvm sync

うまく行った模様。さっきまで出ていた以下のようなメッセージが消えた。

nvm_version:27: no matches found: v*.*[02468].*
nvm_version:27: no matches found: v*.*.*

改めて、

nvm install latest

を実行。がしかし、

nvm: install N/A failed!

と言われて止まってしまう。

nvm ls で最新版を調べて、

nvm install v0.4.8

としたら無事インストールできた。

参考
- http://d.hatena.ne.jp/z3100/20110501/1304255662
- http://blog.sarabande.jp/post/2320225420

CoffeeScriptのインストール

npm install coffee-script

環境設定

まだこの作業は未完了。

ログイン後、以下でnvmが使えるようになる。

. ~/.nvm/nvm.sh

さらにuseコマンドでバージョン指定。

nvm use v0.4.8

これでnodeが使えるようになる。

coffeeコマンドは以下にある。

.npm/coffee-script/1.1.1/package/bin

毎回直接呼ぶのは面倒なわけだけど、どうしたものやら（未解決）。

とりあえず毎回以下を実行してしのぐことにする。

. ~/.nvm/nvm.sh
nvm use v0.4.8
alias coffee='~/.npm/coffee-script/1.1.1/package/bin/coffee'

Hello World

以下の内容でhello.coffeeを作成する。

hello = ->
    console.log("Hello World!")

hello()

以下で実行。

coffee hello.coffee

jsファイルを生成する場合は-cを使う。

coffee -c hello.coffee
node coffee.js

参考
- http://tech.kayac.com/archive/coffeescript-tutorial.html

[アイデア]いま改めて静的なブログシステムを採用してはどうか

2011-06-05T00:00:00+09:00

[アイデア]いま改めて静的なブログシステムを採用してはどうか

新しいblog環境案について考える。

ふりかえり

いまのblog環境の不満点。

重い
- SinatraをCGIで動かしているから
システムを全然メンテできてない
大量の写真を気軽に扱いたい

いいところとしては、

記事の投稿が楽。
- ローカルのdraft.txtに記事を書いて（複数エントリも書ける）、make updateするだけ

かな。いいところは他にもあるんだろうけど特には思い浮かばない。

静的か動的か

さて。

まず最大の不満点は重いことなのだけど、これはCGIで無理やり動かすから遅いわけで、ふつうにサーバー起動させれば負荷はほぼゼロにできる。しかし、今使っているさくらのプランではサーバー起動が禁止されているし、ブログのために新たなサーバー環境を用意するのもどうかなと思っている。

そもそもなんでblogを動的なシステムにしてるんだろうか。静的なシステムじゃだめだろうか。

静的なシステムでも、新しい記事をアップするたびに毎回ブログ全体を構築し直せば、今と同じUIを実現できるはず。動的でなければ成り立たない仕組みは今は使ってない。全体を再構築しなければならない理由は、「前の5件」で順々にページをめくる機能があるからだ。これはカテゴリ表示のときも同じ。

いっそのこと記事単体のhtmlとそのファイル名のリストをサーバー側に置いて、あとはブラウザ側のJavaScriptでUIを構築すればいいじゃんって考えたんだけど、そうするとJavaScriptが不十分な環境だと記事がひとつも読めなかったり、SEO的に問題がでそう…。

もろもろ含めて見えてくるのは、基本静的で一部JavaScriptを使って動的に見せるというラインかな。JavaScriptが動作しない環境では人間にとって便利な一部のUIがなくなる感じ。この場合CGIや動的な仕組みは一切なし。ただしrssの生成等にcronを使う。

静的なhtmlベースでの運用は、なんといっても安心感がある。運用コストも低い。

システムのメンテを楽にしたい

Sinatraにしてもそれなりに進化の速度が早いので、便利な半面、最新版追従の作業がしばしば発生する。

これも静的にしたい理由のひとつで、静的なhtmlの生成の方がシンプルで外部ライブラリへの依存度も減る。動的にhtmlを生成しないのであれば、haml等のテンプレートエンジンだけあればいい。

tumblrとか使ってみたら？

外部のblogサービスを使う手についても考えるんだけど、なかなか踏み切れない。

さがしあたってのネックは写真。新しいシステムでは、たくさんの写真を手軽に扱いたいのだけど、既存サービスの上に乗せようとすると容量その他で制約がでてきそう。

トラックバックやコメント機能

今のシステムでは最初からトラックバックを捨てている。今後もいらない。

コメント機能がほしいかは微妙なんだけど、メンテが面倒なのでない方がいいかな。返事を書くの苦手だし。関連ツイートとかブックマークコメントを表示するブラウザ動作の機能ならあってもいいかもしれない。

oink雑談

2011-06-03T00:00:00+09:00

oink雑談

ほぼ週に一度、株式会社oinkgamesの事務所でテーマを決めずに雑談をしている。今日で４回目かな。

以下てきとーな議事ログ。

オレ遅刻
- 手土産に3本のコーラ
- 世界で売れるのはお茶じゃなくてコーラ
- アメリカのお茶は甘い。炭酸入り
- 「oinkはコーラじゃないですよ」
iPadの対戦ゲームでみんなで遊ぶ
- 音と絵が合ってない？
- 面白いけど売れてないんだろうなー
iPadウォーリーのゲーム
- 対戦の画面の向きがダメ
iPad牽引ビームのゲーム
- 慣れてくると面白そう
iPhoneアプリを売る
- 面白いけどぜんぜん売れてなさそう
- 日本のサイトは有名なゲームを紹介するけど、海外のサイトは「オレこんなのみつけたぜ」的なノリ
子供用アプリを紹介するブログがない
- ひどいアプリ。アイテム課金になっててエサとかを勝手に買えちゃう？
- いや、15分とか過ぎれば認証がかかる
- 設定自体によっては？
- 海外の子供向けアプリはえげつない。のがある
- 子供向けアプリに広告とか課金ボタンが出てほしくない

以下、iPadの話題かな。

よくできた子供向けアプリ
今日の残念アプリ
- 同期していない。可能性はある
- はしに次のページボタンがあるといいのに
もりかわさんのアプリ
- 間がいい
- とてもよくできてる
子供向けじゃないけど子どもが何時間でも遊べそうなアプリ
バランスを取るゲーム
- ここできくちさん（でざいな）登場
- 最長のハマり
- 鳥がなあ。鳥がきついよ
- 雪だるまが溶けてる！
- こうなってきたら最後がみたい
- おっさんでた！

[ruby]RubyのFiberを使ってマイクロスレッドでタスクを管理する

2011-01-08T00:00:00+09:00

[ruby]RubyのFiberを使ってマイクロスレッドでタスクを管理する

@fum1h1ro の開発した社内スクリプト言語ではコルーチンが簡単に書ける。この言語を使ってゲームを開発するようになって、ようやくこのコルーチンの便利さが理解できた。

RiteVMが出ることだし、RubyのFiberについて調べてみるとまさにこれ！ということがわかり、ちょっと触ってみたのでメモしておく。

そもそもFiberがどんな時に便利なのかピンと来ない人も多いかもしれない。オレ自身ごく最近までその便利さが理解できなかった。だが、もはやこれがないと（ゲームの）プログラムが書けないと言っていいくらい必須なものとなりそうなのだ。

Fiber（コルーチン）が使えるのはこんなケースだ。

1回ボタンが押されると3発のミサイルが発射される仕様のゲームがあったとする。

1発目のミサイルはボタンを押した瞬間に発射される
2発目のミサイルはボタンを押した1秒後に発射される
3発目のミサイルはボタンを押した2秒後に発射される
ボタンが押されてから3秒間はミサイルを発射することができない

今までならカウンタ変数を設けて、カウンタが一定値に達したことを条件としてミサイルの発射処理を実行していた。

ここでFiberを用いると上記のような処理を直接的かつシンプルに表現できる。

以下にFiberを使ったコードを具体的に示す。TaskクラスはFiberを継承したクラスでその小さな実装はあとで紹介する。

maintask = Task.new do
  is_ready = true
  is_over = false
  Task.create { Task.sleep 5; is_over = true }

  until is_over
    if is_ready #and pad_pushed?(:a)
      is_ready = false
      puts "fire1!"
      Task.create do
        Task.sleep 1
        puts "fire2!"
        Task.sleep 1
        puts "fire3!"
        Task.sleep 1
        is_ready = true
      end
    end
    Task.yield
  end

  Task.join
  Task.yield true
end

until maintask.resume
  sleep 0.1
  puts "."
end

タスクは親子関係を持っていて、タスクの中ではTask.createを用いていくつでも子タスクを作ることができる。 Task.yieldが呼ばれるとそこでいったん処理が中断し、 Task.sleepは与えられた秒数だけ処理を中断する。

パッドのボタンが押されたとき、ミサイルの発射処理を行うのは以下の部分だ。

      is_ready = false
      puts "fire1!"
      Task.create do
        Task.sleep 1
        puts "fire2!"
        Task.sleep 1
        puts "fire3!"
        Task.sleep 1
        is_ready = true
      end

簡単に説明すると、まず最初のミサイルを発射した後、新しいタスク（fiber）作成している。タスクの中では1秒待って次のミサイルを発射し、もう1秒待ってミサイルを発射し、もう1秒待ってミサイル発射準備を整えているわけだ。is_readyがtrueになるまではここに来ないので次のミサイルを発射することはできない。

ここで作られたタスクは裏で動くことになるので、Task.createメソッド自体はすぐに処理が終了して帰ってくる。

is_overがtrueになるとループが終了するが、メインタスクが起動してから5秒後にis_overをtrueにするという処理も冒頭でタスク化している。

ちなみに、ミサイルの発射部分のタスクは次のようにそれぞれ別のタスクとして書くこともできる。

      Task.create { Task.sleep 1; puts "fire2!" }
      Task.create { Task.sleep 2; puts "fire3!" }
      Task.create { Task.sleep 3; is_ready = true }

このすれば、最初にパッドが押されたタイミングを基準として発射時間を管理することができる。

maintaskの最後に次の2行がある。

  Task.join
  Task.yield true

joinはタスクの終了を待つメソッドだ。引数を省略すると子スレッドすべての終了を待つ。最後でTask.yieldにtrueを渡しているのはmaintask.resumeの戻り値をプログラムの終了条件としているためだ。

Fiberを使って処理を書いていくといろんなものがタスク化出来ることに気づく。きっと発射されたミサイルもそれぞれが独立したタスクとして管理されることだろう。

このように少なくともゲームにおけるキャラクター操作、そしてエフェクト表示やサウンド再生のタイミングなどは、Fiberを用いることでとてもシンプルに管理できるようになるのだ。

RiteVMがでればゲームにRubyを組み込むことはこれまでとは比較にならないほど容易になるだろう。 Rubyで本格的なゲームを作れる日は近いはず。

最後に上記コードを走らせるのに必要なTaskクラスの実装を載せておく。 joinとjoinに関連した部分で長くなっているが、それでも50行ほどの小さなコードだ。

class Task < Fiber
  @@current_task = nil
  attr_accessor :tasks, :status

  def initialize(*args)
    super
    @tasks = []
    @status = :run
  end

  def alive?
    @status
  end

  def resume(*args)
    @@current_task = self
    r = super(self)
    @@current_task = nil
    dead_tasks = []
    @tasks.each do |t|
      begin
        t.resume(t)
      rescue FiberError
        t.status = nil
        dead_tasks << t
      end
    end
    @tasks -= dead_tasks
    r
  end

  def create_task(*args, &block)
    @tasks << Task.new(*args, &block)
  end

  def join(*args)
    args = tasks if args.empty?
    Task.yield while args.flatten.any?(&:alive?)
  end

  def self.create(*args, &block)
    @@current_task.create_task(*args, &block)
  end

  def self.join(*args)
    @@current_task.join(*args)
  end

  def self.sleep(sec)
    t = Time.now
    self.yield while Time.now - t < sec
  end
end

ツッコミは @dan5ya まで。