いまさらながら、iPhone アプリではやっているらしい「パスドラ」をやってみた。

» 私がパズドラで遊ばなくなった理由 - もとまか日記

で挙げられている遊ばなくなった理由がはっきりとしなかったので、自分で試して確かめてみたいというのが理由。

さすがに人気があるだけあって、僕が以前ちょっとやってみたソーシャルゲームにありがちな単にタップするだけの単調なバトルとは違って、パズルを組み合わせたバトルは若干のゲーム性があり、バトルのエフェクトだったり効果音などはきっちり作られていて操作していて気持ちがいい。

が、知らない人のモンスター（序盤だからか自分のモンスターよりも段違いに強い）を仲間で連れて行き、その仲間のモンスターにばかり攻撃させていれば、序盤のノーマルのステージではまったくこちらがやられることはない。なんか飽き始めてきたので、ちょっとスペシャルステージを覗いてみたところあえなくやられてゲームオーバー。

そこで、冒頭で紹介したエントリーにでてくる、魔法石（App Store で1個85円で買える）を使わないとコンティニューできませんよ、という画面がでてきて、納得。

「パズドラ」含め、ソーシャルゲーム全般に自分が感じる違和感は、それをクリアする（クリアするという概念があるのかわからないが。。）のにいったいいくらお金がかかるのかがわからない点だとあらためて確認した。

パズドラが普通のゲームとして人気があり、800円とか1200円でダウンロードできるゲームだったとしたら僕は買うかもしれない。なぜなら、800円とか1200円以上はもう払わなくて良いという安心感がある。

コンティニューで85円は序の口で、ゲームが進んでいくうちに、魔法石5個とか10個必要ですよ、といった仕掛けが用意されているかもしれない。今後果たしていくらかかるかというところが未知数なので、最初は無料だとしてもトータルでいったいいくらなんだという点が見えない。

こどもたちがソーシャルゲームをやりたい、ともし言い出したら、そのあたりをちゃんとわかりやすく説明して、クオリティも料金も確定している他のゲームをやらせることにする。

というわけで、僕も静かにホームボタンを押してパズドラを閉じ、ブルブル震わせて削除した。

\#666666 といった hex 指定の色の明るさを求める方法を調べたのでメモしておきます。

Python で書くと以下の通り。



上記関数を使って、brightness("#666666") = 0.4 のように 0 〜 1 で表される明るさを求め、たとえば 0.5 より大きければ明るい色なので、その上に表示するテキストの色は黒、0.5 より小さければ暗い色なので、テキストの色は白、というように自動的に決めることができる。

参考:
colors - Hex Code Brightness PHP? - Stack Overflow

NPO法人CANVASさんがおこなっている「プログラミングワークショップin東北」に講師として参加し、宮城県の亘理小学校の6年生たちにスクラッチを教えてきました。

普段こどもたちが参加していて、僕もお手伝いしている三軒茶屋で毎月スクラッチのワークショップをおこなっているOtOMOが協力している関係で、内容はいつもOtOMOで初めての子向けに教える時におこなう「ネコから逃げろ！」というゲームをつくるというものでした。

東北のこどもたちにプログラミングを教えるという取り組みの今回が2回目、前回の様子は

» 石巻や仙台などの小学生にプログラミング教室、NPO法人CANVASが開始：ITpro

で紹介されています。

東京からはCANVASのみなさまと亘理小OBのデラさん、現地からは亘理小に娘さんが通われていて自身はフリーでプログラマーをされている Praise First の砂金（イサゴと読むと初めて知りました）さんとその奥さま、こどもたち自身が取材し石巻のことを伝える
「石巻日日こども新聞」を発行しているキッズ・メディア・ステーションの太田さん、といったメンバーに助けられながらも、2日間で40人弱のクラスを3クラス教えるという、人前で話すのはどちらかというとあまり得意でない僕にはなかなかにハードな内容でした。

それでも、いつものように、こどもたちの「わかった！」という瞬間に立ち会えること、楽しんでいる笑顔が見られることで、慣れないことをする大変さは吹っ飛びます。

特に今回は、「iPhone とかのアプリを作っている人です」と紹介してもらうと、「おお」とか「すげー」と生徒さんたちがどよめいてくれたり、プログラマーになりたいという女の子を担任の先生に紹介してもらったりと、気恥ずかしいですがうれしいことの連続でした。

極めつけはワークショップすべてが終わったあとに、先生、生徒さんたちからのサプライズで、合唱のプレゼント。これにはホントやられました。

感謝のお手紙まで生徒さんたちからいただいて、「いやいやこちらの方が何倍も感謝です」という思いです。

亘理小のみなさんの素晴らしさが少しでも伝わるといいなと思い、手紙への返事をあえてブログで紹介します。

説教じみた部分もありますが、まあ一応40年生きてきたので、少しくらいえらそうなことを書かせて下さい。

Ruby on Rails をこれから始める人向けの情報

Ruby on Rails をこれから始めたいのですが、どんな本がおすすめですか？と聞かれたので、ちょっとまとめておきたいと思います。

» 僕が Ruby on Rails を絶賛する理由 - 僕は発展途上技術者

というエントリーを2007年に書きましたが、その後状況はいろいろと変わり、僕自身 iOS アプリや Android アプリを開発するようになったり、Web サービスでも Python on GAE を触るようになったりして、当時ほど Ruby on Rails 一色というわけではなくなりました。

また、Ruby on Rails の環境を自分の開発マシンに用意するのも

» Mac OS X 10.8 Mountain Lion に Ruby on Rails 環境をセットアップする - 僕は発展途上技術者

で書いたように、最近はちょっと面倒になりました。

それでも Web サービスをつくる、それもユーザー向けで毎日サービスを運用しながら、少しずつ改善していき手を入れ続けるような性質の Web サービスならば、いまでも Ruby on Rails を絶賛おすすめ中です。

さて、その Rails を学ぶためのおすすめ本ですが、2007年から変わらず



がおすすめです。

僕の手元にあるのは第2版までの日本語版と第3版の英語版で、上記第4版は正直言うと中身をみていないのですが、変わらず良書であることは間違いないでしょう。

Rails のみならず、デプロイ方法やテストの書き方など Web サービスを作る上でのベストプラクティスを学ぶことができるので、2007年にこの本を最初に手をとるまでPHPで断片的な知識でもって Web サービスを開発していた僕にとっては、それらが一気に整理されて大変ためになったことを覚えています。

Rails 以前に Ruby の基本的な知識が必要という場合（Ruby on Rails を始めたいという方はたいがいそうだと思いますが）は、



を Rails 本を読む前に読んでおいたほうがいいでしょう。 Ruby を使う人達が言っている「Ruby がたのしい」という言葉の所以がわかると思います。

順番としては「たのしいRuby」を読んでから「RailsによるアジャイルWebアプリケーション開発 第4版」を読むのがおすすめですが、この2つを読み通すにはそれなりの時間がかかるでしょう。

もっと手っ取り早く学びたい、あるいは先にざっと概要を知っておきたいという場合は、今は動画で学ぶという方法があります。

» Rubyの基礎 (全32回) - ドットインストール

» Ruby on Railsの基礎 (全46回) - ドットインストール

ドットインストールは動画でプログラミングを学習できるサイトで、すべての動画を無料で観ることができる素晴らしいサイトです。ひとつの動画が3分弱なので、上記2つをぶっ通しで観れば、4時間くらいで概要をつかむことができます。その上で書籍を読めば効率的に学ぶことができるのではないでしょうか。

Ruby on Rails でとりあえずアプリが作れるようになった人向けの情報

さて、ここまでの基本情報を身に着け、ちょっとした Web アプリを作れるようになって初学者を卒業した段階で必要そうな情報も紹介しておきます。

この段階になると、具体的にやりたいことが出てきて「こういうことがしたいんだけれどどう書けばいいんだ？」といった疑問が多く出てくるようになると思います。そういうときに役立つのが以下のレシピブックです。





英語ですが、知っておくと便利な Tips を動画で紹介している

Ruby on Rails Screencasts - RailsCasts

もおすすめです。

Ruby と Rails をやってて強力だなあと思うのは便利で豊富な gem と呼ばれるライブラリの存在なのですが、たくさんあり過ぎてどれを選んでいいか迷うときがあります。そういうときに上記 RailsCasts で紹介されているものを使うというひとつの判断基準になります。

どの gem を使うかの判断基準として

The Ruby Toolbox - Know Your Options!

を使うのもいいでしょう。Ruby Toolbox では各 gem のメンテされ具合や利用者数、評判などを比較することができます。

Rails の API ドキュメントを調べたいという場合は、インクリメンタルサーチができる

Ruby on Rails - APIdock

がおすすめです。

Ruby のコーディングスタイルが気になってきたら、

Rubyアソシエーション: コーディング規約

で紹介されている各コーディング規約を参考にするといいと思います。

いままで他の言語、フレームワークをやってきた人向けへのアドバイス

いままで他の言語、フレームワークをやってきて、Ruby on Rails で実際にアプリを開発し始めたときによく見る悪いパターンというのを紹介したいと思います。

Ruby on Rails では DB のスキーマ情報の変更を Migration という仕組みで綺麗に管理しているのですが、それを無視して sql ファイルで管理しようとするのはやめたほうがいいです。初期データ投入も、seed.rb に Ruby でわかりやすく書くというスタンダードな方法を取り、sql ファイルをインポートという方法は避けたほうがいい。

メソッド名や変数名の付け方を Ruby や Rails 流にあわせましょう。Rails ではモデル名を名詞の単数形で定義すると、自動的にその名詞の複数形で DB 内の対応するテーブルの名前がつけられるなど、英語のルールに従うことが必要なので、メソッド名や変数名を英語でつけるというのが特に必要です。その際の名前付けも、なるべく正確に、そしてスペルミスをしないように辞書で確認するなど気をつけたほうがいいです。

人が作ったものは信用できないということで、すでに Rails の機能にあるのに、あるいは同じ機能の gem があるのに、同等の機能を実現するライブラリを自作してしまう人がいるのですが、複数人が関わるプロジェクトではそれはできるだけやめたほうがいいでしょう。もし自作のライブラリを採用したいとしたら、github などで公開し、すでに世にでていて多くのユーザーを獲得している先行のライブラリと同等のドキュメントをそろえ、前述したThe Ruby Toolboxで見て、既存のライブラリよりも多くのユーザーを獲得していると証明できるくらいでないと、と思います。