Jewel-mmo開発日記

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のFiberを使ってマイクロスレッドでタスクを管理する

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

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 まで。

組み込みスクリプト言語とRiteVM勉強会開催のお知らせ

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

組み込みスクリプト言語とRiteVM勉強会開催のお知らせ

今週の土曜日の夕方から組み込みスクリプト言語の勉強会をやります。

同僚の @fum1h1ro が自社のゲーム開発用に開発したスクリプト言語の実装や開発に至った経緯について発表してくれる予定です。この社内スクリプト言語は、JavaSriptぽい（ハッシュとかないのでもっとシンプル）言語で、コンパイルにはRaccを使い、VMはCで実装しています。

後半は「RiteVM勉強会」をやりたいと思います。今年公開されると期待される組み込みRubyについて思いを巡らせながら想像で勉強してみたり、どんな環境で動いて欲しいかの要望をMatzに送るべくまとめてみたりする予定です。

ATNDがあります ... http://atnd.org/events/11603

場所はいつもYokohama.rbでも使っている東神奈川の地区センターの和室です。

よろしくお願いします。

Rubyのmapメソッドの使い方

2010-12-06T00:00:00+09:00

Rubyのmapメソッドの使い方

（この記事はRuby Advent Calendar jp: 2010 : ATNDの6日目です。前日はokkezさんでした。）

Rubyにはmapメソッドというたいへん便利なメソッドがあります。

配列aにはいくつかの文字列が入ってるとします。

a = ["a", "abc", "abcdef"]

この文字列を次のように右寄せで表示したいとき、どう書けばいいでしょう。

     a
   abc
abcdef

いろんなやり方がありそうすが、ここではmapメソッドを使った例を紹介すると同時に mapメソッドの使い方について詳しく解説します。

まずeachメソッドで書いてみる

まずその前に。

mapメソッドを使った書き方を紹介する前により易しいeachメソッドを使って書いてみます。

a = ["a", "abc", "abcdef"]
l = 6
a.each {|e| puts e.rjust(l) }

実行結果

     a
   abc
abcdef

eachメソッドで配列の値をひとつひとつ順番に取り出してputsしています。配列から取り出した値は変数eに代入され、要素数だけブロックが繰り返し実行されます。（eはただの変数名です。別にeでなくても任意の好きな名前をつけることができます。）

文字列をレシーバにしてrjustメソッドを呼び出すと、rjustメソッドは文字列を右詰にして返します（左の余白はスペースで埋められます）。右詰めしたあとの文字列の長さは引数で渡しています。

"a".rjust(6) #=> "     a"

rjustメソッドの挙動は上記のような感じです。

同じ処理をCやJavaで書くと、このeachの例のように繰り返しを使うことが多いのではないでしょうか。

mapメソッドを使ってみる

さてここからが本番です。

mapメソッドを用いた書き方を紹介します。

a = ["a", "abc", "abcdef"]
l = 6
a = a.map {|e| e.rjust(l) }
puts a

実行結果

     a
   abc
abcdef

配列の内容が変数eに順々に入ってくるのはeachのときと同じですが、 mapメソッドは戻り値で配列を返します。

上の例でmapメソッドが返す配列は、もとの配列aの要素それぞれにrjustメソッドを適用した結果になります。具体的には配列aの中の文字列は、それぞれ次のように置き換えられて、その結果が新しい配列として作られます。

"a"      → "     a"
"abc"    → "   abc"
"abcdef" → "abcdef"

上の例ではmapメソッドの戻り値を改めてaに代入して全体を新しい配列に置き換えていますが、ここでmap!メソッドを使えば、もとの配列aを直接書き換えてしまうこともできます。

a = ["a", "abc", "abcdef"]
l = 6
a.map! {|e| e.rjust(l) }
puts a

map!は、レシーバの内容を変更してしまう破壊的なメソッドです。

（おっと、説明を忘れていましたが、putsメソッドは引数に配列を渡すと要素それぞれを改行しながら表示してくれます。putsに渡すとき「a.join(\n)」として配列をひとつの文字列に変換してもいいのですが、幸いその必要がありません。）

実はaを置き換えなくても次のようにmapの戻り値を直接putsの引数にすることも可能です。

puts a.map {|e| e.rjust(l) }

（こうすると、aは置き換えられることなく最初の内容が保たれます。）

慣れないうちは結合の優先順位をイメージしにくいかもしれません。参考までに省略されているカッコを書くとこうなります。

puts(a.map {|e| e.rjust(l) })

もっとmapメソッドを使ってみる

さっきのコードでは、文字列の長さを6と決めて右詰の処理を行っていました。

l = 6

この6という数値は、配列の中に含まれる文字列の最も長い文字列の長さを表したものです。

ここでもmapメソッドを使えば最も長い文字列の長さを簡単に求めることができます。

a = ["a", "abc", "abcdef"]
b = a.map {|e| e.length }
l = b.max
puts l #=> 6が表示される

aの要素に対してlengthメソッドを適用した結果をbに代入しています。 bは次のような配列になります。

[1, 3, 6]

maxメソッドは配列の中から最も大きい値を探し出して返してくれます。

[1, 3, 6].max #=> 6

なお、上の例は変数bを省略して次のように書くこともできます。

l = a.map {|e| e.length }.max

まとめ

まとめます。

a = ["a", "abc", "abcdef"]

上記のようにaが文字列の配列だった場合、mapを使うと…

l = a.map {|e| e.length }.max
puts a.map {|e| e.rjust(l) }

このような2行で、当初の目的を達成することができます。特に1行目の最も長い文字列の文字数を求めるところでは、eachよりmapを使ったほうがすっきり書けます。

mapメソッドはとっても便利でかつ使えるケースが多いので、ぜひともこの機会に覚えてください！

とあるスクリプト言語に配列が欲しい

2010-11-10T00:00:00+09:00

とあるスクリプト言語に配列が欲しい

昨日の話はclassを導入しなくてもプロトタイプベースでオブジェクト指向をやるという方向性もあるのかもしれないと思った。

プロトタイプベースというのをよく知らなかったんだけど。あれこれ頭ん中で考えているとそういうのが自然と分かってくるね。

考えるだけでずいぶんと勉強に。普ものだなあ段何気なく使ってたものについてほんと考えさせられる。

さて今日は配列に期待することを書き出してみるぞ！

リテラル

Rubyっぽい書き方に慣れているのでRubyっぽく書いてみる。

a = [1, 2, 3]
a[0] // => 1

もちろん最後の「,」は省略可能だが書いてもいい。

空の配列も作成可能。

a = []

アクセス

a = [1, 2, 3]
a[0] // => 1
a[3] // => nil

インデックスは0からがいい。ところでなんでLuaは1からなんだろうか。範囲外（というか未代入）にアクセスするとnilが返る。

こういう書き方も許して欲しい。

[1, 2, 3][1] // => 2

配列に代入できるもの

事なる種類の値を同じ配列に入れることもできる。

a = [1, "hello", [1, 2, 3]]
a[2][2] // => 3

もらちろん多次元配列も！

配列操作関数

以下のような関数を用意したい。言い方を変えれば配列はこのような操作ができるものであってほしい。

size

a = [1, 2, 3]
size(a) // => 3
size([1, 2]) // => 2

each

a = [1, 2, 3]
each(a, puts) // => 1
              // => 2
              // => 3

上記は以下と同じ意味。

a = [1, 2, 3]
each(a, fanction(e) { puts(e) })

map

a = [1, 2, 3]
a = map(a, to_s)
p(a) //=> ["1", "2", "3"]

flatten

a = [1, 2, [3, 4, 5]]
a = flatten(a)
p(a) //=> [1, 2, 3, 4, 5]

その他

map!, flatten! ... 破壊的に
push, pop, shift, unshift, delete ... これも破壊的か
sort, reverse, sort!, reverse!

ほんとはこう書きたいけどこれは難しいだろうしまた別の話やね。

a.size()
a.map(to_s)

とあるスクリプト言語のオブジェクト指向への道のり

2010-11-09T00:00:00+09:00

とあるスクリプト言語のオブジェクト指向への道のり

職場に独自の小さなスクリプト言語とそれを動かすVMがある。

ゲームの組み込みに使われているんだけど、VMで動作する特性上使い勝手がよく、文法もJavaScriptによく似ていて取っ付き易い。

そして素晴らしいことに要望を出すとすぐに改善されるのだ。先日は0を真に変えてもらったりもした（偽になるのはnilとfalseだけとなった）。

まだ配列とハッシュがないのだけど、これも近々サポートされることになりそう。そこで、その先にある（と思われる）オブジェクト指向言語化について考えてみた。

次の3ステップでオブジェクト指向化できないかな？ツッコミどころはありそうだけど、たたき台ということで。

※ここから先興味のある方はJavaScriptをイメージしてもらうといいかも

その1。「値.関数名()」と書いたらレシーバを第1引数として渡す

次のようにメンバ変数（ハッシュ）に関数を代入して呼び出すと、強制的に第1引数に自分自身が渡される。

value.method = function(self, a) { ... }
value.method(a)

考えたのだけどハッシュに関数を入れた場合、 selfが欲しいケースの方が断然多いんじゃないかな。

だたしselfが不要な場合もあるかもしれないので、そのときは次ように「!」を使って呼び出す方法も用意しておく。

value!method(value, a)

これは負荷対策以外に意味はないけど。

その2。メンバ関数（インスタンスメソッド）の定義方法

関数側も引数の定義でselfと毎回記述するのはウザイ。

function method(self, a) {
  puts(self.keys)
}

そこで次のように書けたらどうだろうか。

function method(@, a) {
  puts(@keys)
}

関数内の@は自動的に「self.」に置き換えられる。

関数定義は次のような形の方がよりいいかな。

function @method(a) {
  puts(@keys)
}

なんかインスタンスメソッドを定義しているように見えていい感じだ。

しかしどうせならclassキーワードを導入したらどうだろう。

class Klass {
  function method(a) {
    puts(@keys)
    @method2()
  }
  function method2() {
  }
}

おぉこれでいいじゃないか！

もちろん@は「self.」に展開されるだけなので、上の@method2()のように関数呼び出しにも使える。

さてここまで来ればオブジェクト指向言語まであと一歩。

その3。ミックスイン

Klassクラスを次のように定義したとする。

class Klass {
  function method1() { ... }
  function method2() { ... }
}

これをオブジェクト（ハッシュオブジェクト）に関連付けなくてはいけない。ここでmixinという新たな仕組みを用意する。

obj = {}
mixin(obj, Klass)
obj.method1()
obj.method2()

mixinはKlassクラスが持っている関数のポインタそれぞれをobjのメンバに代入する関数だ。イメージとしては次のような感じ。

obj.method1 = Klass.method1
obj.method2 = Klass.method2

あくまで静的にメソッド呼び出しを解決したいので、 mixinするクラスに階層などはない。同じ関数名があればあとからmixinしたものが優先される。

class型という新しい値が必要になっちゃうかな。

ちなみにmixinは次のように書けた方がいいかもしれない。

obj = {}
obj.mixin(Klass)

でもここまできたらこう書きたいよね！

obj = new(Klass)

またはこうかな。

obj = Klass.new

クオリティと門とYokohama.rb

2010-09-04T00:00:00+09:00

クオリティと門とYokohama.rb

In rubykaigi2010,

@kakutani の発表をみてこんなことを思った。以下、まずは当日感じたままを書いておく。

「クオリティ」とよばれるものがあらしい。バイク乗りたちの言葉らしい（この本に出てくる話らしい）。

この「クオリティ」はライダーがバイクで走っているときに感じる言葉に表せないようなもの。とにかく「いい感じ」な何かだと認識した。

この「クオリティ」を自ら得るためには「門」を建てればいい。かくたにさんにとっての「門」はrubykaigiであると。

で、あとの詳しい話はもう覚えてないんだけど、そのとき「クオリティ」というものが何であるかはすぐに理解できた。そして「門」が、「クオリティ」に通じるための有効な手段であることも同意できた。

ここまでを認識した時点ですぐに「Yokohama.rb」が頭に浮かんだ。思いついてしまえば、すごく自然なことで、今までなかったのがおかしなくらい自然なことのように思えた。

発表が終わって、かくたにさんが大ホールの階段を上がっていくとき、「Yokohama.rbを立ち上げます！」とのどまででかかったんだけど「お疲れさまでした」としか言えなかった。

帰りの電車であるrubykaigi参加者にYokohama.rbについて話してみたら「参加してみたい！」言ってくれたので、このとき立ち上げることを決意した。家に帰るとすぐにtwitterで宣言した。

By the way,

2010年の春から横浜で「ふつうのHaskellプログラミング読書会」というのを開催している。

横浜には @hkhumanoid が立ち上げた「横浜へなちょこプログラミング勉強会」という地域勉強会があり、Googleグループには100名くらいのメンバーが参加していた（と思う。2010の春の時点で）。

そのとき残念ながら「横浜へなちょこプログラミング勉強会」の活動は休止してしまっていた。

なんとか復活させたいと思っていたところに、会場の予約その他を手伝ってくれるという @saytx が現れて、ならばとMLに「ふつうのHaskellプログラミング読書会」を提案し、活動を再開させることができた。そして今日はその6回目の読書会。

この「ふつうのHaskellプログラミング読書会」の運営はとても楽なものだった。数ヶ月前まで運営されていた「横浜へなちょこプログラミング勉強会」という箱があり、面倒だと思われた事務手続きを一手に引き受けてくれる人までいた。オレ自身はMLへ参加のお知らせを投げるだけだったので（根回しはしたわけだけど）、あまりに楽過ぎて、とても自分が主催しているとは思えなかった。

今では自分で会場を予約したり、ATNDにページを作ったり、懇親会の会場を予約したりすることにも慣れた。いつの間にか横浜で勉強会を開くスキルがすっかり身に付いていたのだ。

Yokohama.rbを立ち上げるのに必要なものは全部そろっていた。そしてYokohama.rbという門を建てた。ここクオリティがあると信じている。

Anyway,

「横浜へなちょこプログラミング勉強会」の @hkhumanoid と毎回運営を手伝ってくれる仲間に感謝しつつ、これからはじまるYokohama.rbをよろしくお願いします。

勝手にレベルの上がるのを見守るRPG

2010-08-26T00:00:00+09:00

勝手にレベルの上がるのを見守るRPG

先日ボタンを押すだけで経験値が増えるRPGを考えたのだが、もう一歩進んで、見てるだけで勝手にレベルが上がるのはどうだろうかと思った。

操作が不要なわけだから、ただプログラム回してひたすら経験値を上げるだけの簡単なゲームと思って試しに実装しようと思ったんだけど、いざ作り始めてみるとこれが難しい。

一般的なRPGとは操作方法がまったく違うわけで、つまりUIがまったく違うので、そもそも基本画面をどんな形にすれば良いのかが決まらない。

ただ見てるだけだとちゃんとしたゲームにならないので、そこに何を足せば面白くなるのか、何かを足すにしても出来るだけ少ないシステムで面白くするにはどうすればいいかというところで悩んで、実装が進まなくなってしまった。

以下メモ。

shachiは町を歩いています
shachiは町を出ました
shachiはスライムに遭遇しました
shachiは戦っています
shachiは戦っています
shachiはスライムを倒しました
- => 「やくそう」を入手
shachiはぼーっとしています
shachiはやる気がありません
shachiはドラゴンに遭遇した
shachiは戦っています
shachiは剣の扱い方がわかりません
shachiは敵と戦う勇気がありません
shachiは戦っています
shachiはダメージを与えることができません
shachiはドラゴンにまったく歯が立ちません
shachiはドラゴンを倒しました
- => shachiはレベルが上がりました
shachiは町に戻りました
shachiは剣の修行をしています
- 成果はありませんでした
shachiは剣の修行をしています
- => shachiは剣のレベルが上がりました

test

2010-06-02T00:00:00+09:00

test

test...