[Qiita] インスタンスメソッド内での @ と self の違い
上記記事に関連するソース (paiza.IOを使っています。)

スクラム開発の特徴と、チームメンバーの役割

特徴

・実践するのは簡単です！でも、修得するのは難しいです！
・スクラム開発はフレームワーク（枠組み）です
　・複雑で変化の激しい問題に対応するためのものです
　　X　対応する手段
　　O　対応する手段をみんなで模索しながら、製品を作り上げる

スクラム開発に登場する役割

プロダクトオーナー（１人）

・「何を作るか」の責任者
　　・技術的な知識は必ずしも必要ではありません
　　・作成する優先順位を決定します
　　　・ちゃぶ台返しOK（優先順位の変更、仕様の追加、変更、破棄）
　　・製品が仕様どおりかどうかチェックします
　　・製品をリリースするかどうか判断します

開発チーム（３〜９人）

・協力して製品を作り上げます
　　・見積もりは開発者が決定します
　　・作業分担は立候補制です
　　　・一つの作業に複数人でとりかかってもよいです
　　　・むしろどんどん協力しましょう。スクラムですから！
　　　・専門外の仕事も積極的に手伝いましょう

スクラムマスター（１人）

・「どのように作るか」の責任者
　　・「スクラム開発よくわかんない」ってときはこの人に聞きましょう
　　・チームにスクラムのルールを守ってもらうよう促します
　　・チームを守り、支えます
　　・技術的な知識は必要です


※リーダーやマネージャーはいません
※スクラム開発にじゅうぶん慣れたら、
　スクラムマスターもいなくてOKです

Rails3.2 ActiveRecordに関するメモ

ActiveRecordのサブクラスであるModel（以下Model）の機能に関する覚書。

---

一意性制約を定める
Modelに次のように記述する
validates_uniqueness_of :column_name
Migrationに次のように記述し、実行する
add_index :table_name, :column_name, :unique => true

---

validate?の挙動
前提条件：ModelAとModelBの間にリレーションが定められている
ModelA.valid?の戻り値がfalseの場合、
ModelB.valid?の戻り値もfalseとなる。
つまり、リレーションが定められているModelをsaveするときには、
すべてのModelでバリデーションが実行される。

---

saveで保存されるオブジェクト
前提条件：ModelAとModelBに多対多のリレーションが定められている
ModelA.saveを呼び出すと、下記のModelが保存される

• ModelA
• ModelB
• ModelAとModelBの関連テーブルのModel

（関連テーブルのインスタンスは自動的に生成される）

つまり、下記のようなコードで事足りる。
modelA = ModelA.new(hoge: 'hoge') #モデルAをインスタンス化
modelB = ModelB.new(foo: 'foo') #モデルBをインスタンス化
modelA.modelBs << modelB #モデルAとモデルBを関連付ける
modelA.save #関連テーブルのModelが自動生成され、すべてのModelが保存される

VirtualBoxで何かトラブルが発生した時は

とりあえずホストOSごと再起動してみるべし。

coffeescript+jQueryでDOM操作

やりたいこと

coffeescriptで生成したjavascriptでDOM操作をしたい

今回学んだこと

coffeescriptの１行目に
$ ->
と記述することで、それ以下の命令がdocument読み込み完了時に実行される。
jQueryの下記の記述と同等。
$(function() {
  //何らかの処理
});

ディレクトリ構造

shusuke@shusuke-VirtualBox:~/practice/coffee$ pwd
/home/shusuke/practice/coffee
shusuke@shusuke-VirtualBox:~/practice/coffee$ tree
.
├── bin
│   └── hello.js <-coffeescriptをコンパイルしてできたJSファイル
├── lib
│   └── jquery-1.9.0.min.js
├── src
│   └── hello.coffee <-coffeescriptのソースファイル
└── view.html <-練習用のHTML

view.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ja">
<head>
<meta http-equiv="Content-Language" content="ja" />
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  <script type="text/javascript" src="./lib/jquery-1.9.0.min.js"></script>
  <!-- javascriptを読み込む -->
  <script type="text/javascript" src="./bin/hello.js"></script>
</head>
<body>
  <div id="apple">りんご</div>
  <div id="banana">バナナ</div>
  <div id="hoge">HOGE</div>
</body>
</html>

src/hello.coffee

$ ->
  console.log "LOG TEST"
  hoge = $('#hoge')
  msg = if hoge is null then "hoge is null" else "hoge is not null"
  console.log msg
  console.log hoge.html()

bin/hello.js

// Generated by CoffeeScript 1.4.0
(function() {

  $(function() {
    var hoge, msg;
    console.log("LOG TEST");
    hoge = $('#hoge');
    msg = hoge === null ? "hoge is null" : "hoge is not null";
    console.log(msg);
    return console.log(hoge.html());
  });

}).call(this);

実行結果（HTML表示時のjavascriptコンソール）

[23:24:31.514] LOG TEST
[23:24:31.514] hoge is not null
[23:24:31.515] HOGE

在庫数量の決め方（１）

必要以上に在庫を抱えないためには、必要以上に商品を仕入れないようにすればよい。では、仕入れる量はどのようにして決めればよいだろうか。
例えば、現在の在庫が最大である60個だとしよう。発注から入荷までに必ず２日かかり、１日に必ず20個の商品を売り上げている場合、発注数量はいくつにすればよいだろうか。

在庫数量(個)	60/60
発注から入荷まで	2日
売上ペース	20個/日

今日発注すると2日後に入荷する。売上ペースから計算すると、入荷時の在庫数量は20/60個となり、40個を補充することができる。よって、40個発注すれば、品切れを起こさず、かつ倉庫内に収めることができる。
では、在庫量をより少なくすることはできないだろうか。これを考えるには、発注から入荷までの時間と、売上ペースに注目するとよい。最大在庫数量を40個に設定すれば、2日に1度、商品を40個発注することで在庫を維持できる。
まだ改善の余地はある。発注から入庫までには2日かかるという制約はあるが、2日に1度しか発注できないという制約はない。つまり、毎日20個発注すると決めれば、最大在庫数量を20個まで減らすことができる。
これが、在庫管理の根本となる考え方だ。実際には、様々なことを考慮して、最大在庫数量や発注数量などを決定することになる。ここでは、説明を簡単にするために極端な例を示した。

在庫を抱えすぎることによる弊害

在庫を抱えすぎると、店の経営に様々な問題が発生する。
第一に、在庫スペースの維持に費用がかかることだ。倉庫が大きければ大きいほど、地代や固定資産税がかさみ、経営を圧迫する。
第二に、需要の変化に対応するのが難しくなる。古い製品が在庫スペースを占領していると、新商品を仕入れることができなくなる。結果として、新商品を販売する機会を逃してしまう。
第三に、現金や預金が少なくなることで、資金繰りを悪化させる。仕入れに大量の資金を費やしたばかりに、取引先への支払いや借金の返済が遅れてしまうことがあり、黒字倒産になりかねない。
これらを踏まえて、適切な量の商品を仕入れることが在庫管理の基礎といえる。では、具体的にはどのように仕入れたらよいのだろうか。それについては次回。

在庫を抱える目的

在庫はなぜ抱える必要があるのだろうか。また、なぜ在庫を減らすことが良いと言われているのだろうか。
まずは、在庫を抱える必要性について、田中屋という八百屋を例に考えてみよう。
田中屋では、毎朝トマトを仕入れて、陳列棚に並べて販売している。陳列棚には100個のトマトを並べることが出来る。トマトは1日あたり約90個売れており、売れ残った分は毎日破棄していた。
ある日を境に、トマトの売れ行きが伸び始め、昼頃には全て売れてしまうようになった。夕方になってもトマトを求めて客がやってくるが、品切れのために売ることが出来ない。より多く仕入れれば品切れにならないのだが、陳列棚には100個までしか並べることができない。
そこで、店主はトマトを200個保管できる倉庫を用意した。倉庫の維持には費用がかかる。しかし、1日あたりトマトを300個売ることができるようになった。在庫を用意することで、品切れに対処したのだ。
このように、在庫を用意する目的は「販売機会の損失」を防ぐことにある。適切な料の在庫を持つことで、需要に対応して売上を伸ばすことができる。
では、在庫を大量に確保すればいいのかというと、そんなことはない。それについては次の記事で書こうと思う。

在庫管理を学ぼうと思った理由

僕がどんな人間か知っている人には「何を無茶なことを考えているんだ」と思われるかもしれないが、ゆくゆくは、自分でソフトハウスを立ち上げたいと考えてる。
そのために今できることの一つは、業務知識を学ぶこと。日商簿記3級を取得したのも、その一環。
簿記の勉強をしてみて感じたことがある。それは、会計に関する知識だけでは、他社のソフトウェアに対抗できるようなものを作れないということ。
会計処理の多くの部分は、会計法や簿記のルールに基づいて行われている。どの会社も似たような処理を行なっているので、IT化にあたってはパッケージソフトの導入がベターなんだ。となると、会計ソフトの開発で「他社との差別化」をするのはかなり難しいと思うんだよね。
会計知識と組み合わせることで、システム開発に役立つ知識は何だろうか。そう考えた時に頭に浮かんだのが「在庫管理」だった。
在庫管理に関しては法が整備されているわけではないので、会社ごとに独自のプロセスがあると考えられる。つまり、パッケージソフトでは手の届かないようなところを解決できるようなシステムを提案するチャンスがあると思うんだ。
さらに、在庫管理と会計処理を一括して行うことができるシステムを構築できれば、顧客の事務処理にかける時間をかなり削減できる。在庫情報をモバイル端末でリアルタイムに参照できるようにすれば、顧客の営業活動にも良い影響を与えられる。取引先の企業にもシステムを導入できれば、EDIの実現により、顧客の受発注処理をより効率化できる。
在庫管理に関する知識の他にも、学ぶべきことはたくさんある。まずは、今の自分にできるところから手をつけて、一歩ずつ着実に目標に向かって進んでいこう。

Rails3.0にCapybaraとlaunchyを追加

Gemfileに下記の2行を追加。

gem 'capybara'
gem 'launchy'

bundle installを実行。下記のようなエラーがでる。
bundle install
-- 省略 -- 
Installing nokogiri (1.5.0) with native extensions
Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem native extension.

/usr/local/bin/ruby extconf.rb
checking for libxml/parser.h... yes
checking for libxslt/xslt.h... no
-----
libxslt is missing.  please visit http://nokogiri.org/tutorials/installing_nokogiri.html for help with installing dependencies.
-----
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers.  Check the mkmf.log file for more
details.  You may need configuration options.

Provided configuration options:
        --with-opt-dir
        --without-opt-dir
        --with-opt-include
        --without-opt-include=${opt-dir}/include
        --with-opt-lib
        --without-opt-lib=${opt-dir}/lib
        --with-make-prog
        --without-make-prog
        --srcdir=.
        --curdir
        --ruby=/usr/local/bin/ruby
        --with-zlib-dir
        --without-zlib-dir
        --with-zlib-include
        --without-zlib-include=${zlib-dir}/include
        --with-zlib-lib
        --without-zlib-lib=${zlib-dir}/lib
        --with-iconv-dir
        --without-iconv-dir
        --with-iconv-include
        --without-iconv-include=${iconv-dir}/include
        --with-iconv-lib
        --without-iconv-lib=${iconv-dir}/lib
        --with-xml2-dir
        --without-xml2-dir
        --with-xml2-include
        --without-xml2-include=${xml2-dir}/include
        --with-xml2-lib
        --without-xml2-lib=${xml2-dir}/lib
        --with-xslt-dir
        --without-xslt-dir
        --with-xslt-include
        --without-xslt-include=${xslt-dir}/include
        --with-xslt-lib
        --without-xslt-lib=${xslt-dir}/lib


Gem files will remain installed in /usr/local/lib/ruby/gems/1.9.1/gems/nokogiri-1.5.0 for inspection.
Results logged to /usr/local/lib/ruby/gems/1.9.1/gems/nokogiri-1.5.0/ext/nokogiri/gem_make.out
An error occured while installing nokogiri (1.5.0), and Bundler cannot continue.
Make sure that `gem install nokogiri -v '1.5.0'` succeeds before bundling.

調べた結果、libxslt-develが必要らしいので、インストール。
yum install libxslt-devel

再度bundle installを実行。
bundle install
今度はうまくいった。

一歩前へ！

社長（友人）「今度、とあるシステムをリプレースするから、設計をしてくれないかな」
僕「（　゜д゜）」

設計か・・・うむ、やってみる。やってやる。やってやるぞー！
現在は、既存システムのマニュアルや、社長の話を聞きつつ、データ構造やUIを設計している段階。ある程度まとまったら、一度クライアントと直に会って、詳細を詰めていく予定。



僕「開発方式はどうする？」
社長（友人）「まかせるよ」
僕「（ ＾ω＾）」

システムの規模とウォーターフォールへの不信感から、反復式で設計をまとめた後に、反復式で製造することにした。製造はBDDで行おうと思ったんだけど、NetBeans＋PHP＋BDDという環境を整えるのに手間取りそう。普段使っているPHPUnitを利用して、TDDで開発する。TDDに関しては、業界で賛否両論あるのだが、やってみないことには何も実感できないよね。

製造が終わったら、操作説明書や運用手順書も作らないとな。

さあさあ、脱プログラマへの第一歩なのよ！(｀・ω・´)ｼｬｷｰﾝ

Rails3でデータベースの日付を日本時間にする方法

Rails3では、データベースに日付を格納するときにUTCとするため、
日本時間のみを扱いたい場合はちょっと不便。

下記の方法で解決できる。
（参考URL： http://blog.libero-tecnologia.net/?p=40）

config/application.rbに下記2行を追加

    config.time_zone = ‘Tokyo’
    config.active_record.default_timezone = :local

Rails3.0 bundle install時のsqliteエラー解決方法

bundle install時に、次のようなエラーが出る場合がある。
An error occured while installing sqlite3 (1.3.5), and Bundler cannot continue.
Make sure that `gem install sqlite3 -v '1.3.5'` succeeds before bundling.

適切なバージョンのsqliteをインストールしていないために、このエラーが起きるようだ。
yumでsqliteをインストールしてみたが、インストールされるバージョン(3.3)が古いために解決できなかった。

yum install sqlite-devel #これではダメ！

sqlite3.5以上のソースをダウンロードしてインストールしてみた。

wget http://www.sqlite.org/sqlite-autoconf-3070900.tar.gz
tar zxvf sqlite-autoconf-3070900.tar.gz
cd sqlite-autoconf-3070900
./configure

make

checkinstall -R --fstrans=no --exclude=/selinux

**************************************
**** RPM package creation selected ***
**************************************

This package will be built according to these values:

1 -  Summary: [ Package created with checkinstall 1.6.0 ]
2 -  Name:    [ sqlite-autoconf ]
3 -  Version: [ 3070900 ]
4 -  Release: [ 1 ]
5 -  License: [ GPL ]
6 -  Group:   [ Applications/System ]
7 -  Architecture: [ i386 ]
8 -  Source location: [ sqlite-autoconf-3070900 ]
9 -  Alternate source location: [  ]
10 - Requires: [  ]
11 - Provides: [ sqlite-autoconf ]

Enter a number to change any of them or press ENTER to continue: 2 #Nameを指定する
Enter new name:
>> sqlite

This package will be built according to these values:

1 -  Summary: [ Package created with checkinstall 1.6.0 ]
2 -  Name:    [ sqlite ]
3 -  Version: [ 3070900 ]
4 -  Release: [ 1 ]
5 -  License: [ GPL ]
6 -  Group:   [ Applications/System ]
7 -  Architecture: [ i386 ]
8 -  Source location: [ sqlite-autoconf-3070900 ]
9 -  Alternate source location: [  ]
10 - Requires: [  ]
11 - Provides: [ sqlite-autoconf ]

Enter a number to change any of them or press ENTER to continue: 3 #Versionを指定する
Enter new version:
>> 3.7.9

This package will be built according to these values:

1 -  Summary: [ Package created with checkinstall 1.6.0 ]
2 -  Name:    [ sqlite ]
3 -  Version: [ 3.7.9 ]
4 -  Release: [ 1 ]
5 -  License: [ GPL ]
6 -  Group:   [ Applications/System ]
7 -  Architecture: [ i386 ]
8 -  Source location: [ sqlite-autoconf-3070900 ]
9 -  Alternate source location: [  ]
10 - Requires: [  ]
11 - Provides: [ sqlite-autoconf ]

Enter a number to change any of them or press ENTER to continue: #Enterを押下

rpm -ivh /usr/src/redhat/RPMS/i386/sqlite-3.7.9-1.i386.rpm

sqliteがインストールされたことを確認する。
sqlite3
SQLite version 3.7.9 2011-11-01 00:52:41
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .q

Railsのbundle installを実行してみる。

mkdir work_rails_check

cd work_rails_check/

rails new checkapp

cd checkapp/
bundle install
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.

なんとかうまくいった。ほっと一息。

CentOSにRails3.0を導入(CheckInstall使用)

今回、Rails3の導入にCheckInstallというツールを利用する。
CheckInstallの導入方法

以下Railsインストール手順

あらかじめgccをインストール
yum install gcc


あらかじめrpm-buildをインストール

yum install rpm-build

あらかじめzlib-develをインストール
yum install zlib-devel

あらかじめ必要なパッケージをインストール
yum install gcc gcc-c++ make perl zlib-devel openssl-devel readline-devel libxml2-devel bzip2-devel unzip libjpeg-devel libpng-devel freetype-devel rpm-build -y

Rubyソースコードをダウンロード(ruby-1.9.3-p0だと、Gemがうまく動作しない)

wget http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p290.tar.bz2

アーカイブを展開

tar xjf ruby-1.9.2-p290.tar.bz2

コンパイルしてCheckInstallでRPMパッケージ化

cd ruby-1.9.2-p290

./configure
make

checkinstall -R --fstrans=no

・・・途中でいろいろ聞かれるが、EnterキーでOK

RPMパッケージからrubyをインストール

cd /usr/src/redhat/RPMS/i386/
rpm ivh ruby-1.9.2-p290-1.i386.rpm

Rubyのバージョンを確認。
ruby -v
ruby 1.9.2p290 (2011-07-09 revision 32553) [i686-linux]

Gemのバージョン確認。
gem env
RubyGems Environment:
  - RUBYGEMS VERSION: 1.3.7

Railsインストール。(バージョン3.1.2だと、Railsバージョン確認でエラーが出る)
gem install rails -v 3.0

Railsバージョン確認
rails -v
Rails 3.0.0

以上でRailsのインストールが完了する。
できればRails3.1を使いたかったのだが、今回は妥協した。

(未完成記事)CentOSにRails3を導入(CheckInstall使用)

こちらの新しい記事を参照してください。
以下の記事は古いものです。

今回、Rails3の導入にCheckInstallというツールを利用する。
CheckInstallの導入方法

以下Railsインストール手順

あらかじめgccをインストール
yum install gcc

あらかじめrpm-buildをインストール

yum install rpm-build

あらかじめzlib-develをインストール
yum install zlib-devel


Rubyソースコードをダウンロード

wget ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p0.tar.bz2

アーカイブを展開

tar xjf ruby-1.9.3-p0.tar.bz2

コンパイルしてCheckInstallでRPMパッケージ化

cd ruby-1.9.3-p0

./configure
make

checkinstall -R --fstrans=no

・・・途中でいろいろ聞かれるが、EnterキーでOK

RPMパッケージからrubyをインストール

cd /usr/src/redhat/RPMS/i386/
rpm -ivh ruby-1.9.3-p0-1.i386.rpm

Rubyのバージョンを確認。
ruby -v
ruby 1.9.3p0 (2011-10-30 revision 33570) [i686-linux]

ここまではうまくいったものの、Gemが使用できない。
どなたか解決できるかた、お願いできませんか（・w・；
gem env
<internal:gem_prelude>:1:in `require': cannot load such file -- rubygems.rb (LoadError)
        from <internal:gem_prelude>:1:in `<compiled>'

CentOSにCheckInstallを導入する

CheckInstallとは？
ソフトウェアのソースコードからRPMパッケージを簡単に作成できるツール。
ソースコードをコンパイルしてインストールした場合、そのソフトウェアのアンインストールなどの管理がしづらくなる。RPMを利用してインストールすれば、管理が容易になる。

導入手順
参考URL　http://mymo.blog8.fc2.com/blog-entry-2.html

RPMforgeレポジトリを設定
wget http://dag.wieers.com/packages/rpmforge-release/rpmforge-release-0.3.6-1.el5.rf.i386.rpm
rpm -Uhv rpmforge-release-0.3.6-1.el5.rf.i386.rpm

デフォルトで無効になるように設定ファイルを次のように修正
vi /etc/yum.repos.d/rpmforge.repo

enabled = 1

↓
enabled = 0

RPMの署名を検証するキーを導入

wget http://dag.wieers.com/packages/RPM-GPG-KEY.dag.txt

rpm --import RPM-GPG-KEY.dag.txt

RPMforgeのリポジトリを有効化
yum --enablerepo=rpmforge list

checkinstallのインストール
yum --enablerepo=rpmforge install checkinstall

PHPUnitをNetBeansで使うときに「'".\php.exe"' は、内部コマンドまたは外部コマンド、 操作可能なプログラムまたはバッチ ファイルとして認識されていません。」というエラーの解決方法

PHPUnitをNetBeansで使いたいんだけど、「'".\php.exe"' は、内部コマンドまたは外部コマンド、 操作可能なプログラムまたはバッチ ファイルとして認識されていません。」って怒られる・・・(´・ω・｀)


調査した結果、
C:\xampp\php\phpunit.batの中にヒントが隠されていた。


（phpunit.bat　一部抜粋）
if "%PHPBIN%" == "" set PHPBIN=.\php.exe


つまり、システム環境変数に、下記のようなものを追加してやればいい。

結果、問題なくPHPUnitが動作するようになった。

めでたしめでたし。

変数名に漢字やかなを使っても良いものか？

最近のプログラミング言語では、シンボルとして日本語を認識できるものがいくつかあるらしい。僕はそういうものはScalaしか知らないけどね。Rubyもできるんだったかな・・・記憶があいまいだ。
事務系のプログラムを作るときに、変数名やメソッド名に日本語を使いたい時があるんだ。「貸倒引当金」とか「利益余剰金」とか、英語に翻訳するのがすごくめんどうなのよね。そのままローマ字表記で「kashidaore_hikiate_kin」とかにしてもいいんだろうけど、どこにアンダーバーをいれればいいのか迷う。例えば、引当金だったら「hikiate_kin」にするのか「hikiatekin」にするのか、悩んじゃう。
プログラミングの原則的には「シンボルは英語で定義する」なんだけど、それを守ろうとするあまりに作業効率が極端に低下するのであれば、例外を認めてもいいんじゃないかな。社内でしか使わなかったり、特定の業種に特化したりするシステムを作る上であれば、なおさらね。

一緒に遊べるアクションゲーム。

「星のカービィWii」発売まで、いよいよ一週間をきったよ。買おうかどうか迷っていたけれど、思い切って予約した。おそらくkonozamaだろうけどね。
据え置きゲーム機は、2000年に発売した「星のカービィ64」以来だから11年ぶり。でも、多人数同時プレイができる据え置きカービィは、1996年の「星のカービィスーパーデラックス」が最後だから・・・15年ぶりってことか。「毛糸のカービィ」は例外扱いさせてね。あれはもともと「毛糸のフラッフ」として開発されていたものが、途中でキャラクターとしてカービィを起用したものなんだよ。

僕が知っている協力プレイ可能アクションゲームは、

• 星のカービィスーパーデラックス
• 毛糸のカービィ
• NewスーパーマリオブラザーズWii
• がんばれゴエモン２
• ワイワイワールド2 SOS!!パセリ城

これくらいかな。

特に思い出深いのは「がんばれゴエモン２」。よく友だちと一緒に遊んでいて、最初のステージで白い招き猫を集めるのが恒例だったよ。ゴエモン、エビス丸、サスケ、それぞれの個性が強い点も面白い。コミックボンボンではエビス丸がゲイとして描かれていたけど、あれって公式設定なのか？

「毛糸のカービィ」は癒しゲー。一部の敵キャラクターはぶつかってもダメージを受けない。それどころか、いくらダメージを受けてもスコアが減るだけでゲームオーバーにならない。そしてグラフィックやBGMがめっちゃファンシー。彼女と一緒に遊んでみたいな・・・彼女いないけど。

やっぱり、協力プレイできるゲームは据え置きがいいなー。携帯ゲーム機だと、人数分の本体とソフトを用意しないといけないんだもの。ポケモンやモンハンみたいな「超」がつくほど人気のあるタイトルならいいけど、そうでなければ一緒に遊べる仲間がいなくてさみしい思いをすることがよくある。友だちが少ないとか言っちゃダメ。

そもそもMVCとは。

様々なフレームワークで用いられているMVCについての僕の認識を書いてみる。

Viewは画面。これについては特に書くことはない。

Controllerは、ViewやModelの処理を起動するもの。

Modelはドメインモデルのこと。業務処理に合わせて、データを保持したり、データを編集したりするのがModelの役割。

フレームワークの入門者向け解説を読むと、Modelはデータを保持するだけのものだと勘違いすることがある(僕もそうだった)。Strutsの解説ではModel＝Beanとされていることがあるし、Railsの解説でもgenerate modelでModelが作られるとされていることがある。間違いではないんだけれど、ちょいと言葉が足りないのではあるまいか。

一部の企業が採用している設計方針では、Modelを実現するために、ServiceクラスとModelクラスを作る。Serviceクラスではデータの編集を行い、Modelクラスではデータの保持を行う。このようにすることでクラスの役割はわかりやすくなる。このような場合でも、MVCに照らしあわせれば、ServiceクラスはMVCのModelの役割に含まれている。










このあたりを再認識することはけっこう重要だと思った。特にRailsを使う上ではね。