2014-03-18

相対性理論とアジャイル開発の関係

考えネタ

今回はディレクター向けにアジャイル開発の難しい点を(特殊)相対性理論を用いて解説したいと思います。

おそらくタイトルの段階でどちらも理解している方は内容が想像つくのではないのでしょうか。

相対性理論について
アジャイル開発におけるスコープ
2つの関係
まとめ

相対性理論について

もうこの名前だけでわけわからんって方が多いかと思いますが、一言で相対性理論を表すと
「光速は不変」
とにかくこれだけ抑えておけばこれから話す内容も理解できるかと。

これから、光速は不変ということをもう少し詳しく説明しますが、
その前に不変じゃない普通の速度について説明します。
まずある人Aが時速5kmで歩いているとします。
Aは電車の中にいて、この電車は時速80kmで動いているとします。
すると電車の外にいる人からするとAは時速85kmで動いている状態となります。
これが普通です。

次にAが光だったとします。
光なので光の速度 c で動きます。
光は電車の中にいて、この電車は時速80kmで動いているとします。
すると光は時速 c + 80 kmになるでしょうか。
答えはなりません。
理由はよくわかりませんが、これこそが相対性理論の光速不変たる所以です。

次にもう一度電車の例で例えます。
レーザー光を電車の床から天井に向けて照射したとします。
電車の中から見ている人のイメージはこちら
f:id:nigohiroki:20140317224223p:plain

電車が動いていると外から見ている人には光はこう見えます
f:id:nigohiroki:20140317224259p:plain

光の部分だけ取り出すと
f:id:nigohiroki:20140317224321p:plain
こんな感じになります。

長さ(移動距離)は速度 x 時間なので
光速 x 時間が光の長さになります。

さて、この時光の長さが変わっているかと思います。
長い方を L1
短い方を L2
しかし光速は先ほど説明したように不変で c と定義します。
すると
L1 = c x 時間1
L2 = c x 時間2
となります。
L1 != L2 なので時間1 != 時間2 です。
「あれ? 時間が違うってどういうこと?」
と思いますよね?
そのままの意味で、光速で動くものは動いていないものと比較し時間の進み方が違います。
つまり相対性理論を考えるとこの世で絶対的なものは光速であり、空間と時間は相対的だということです。

ちなみにこの理論を駆使すると速度と関係のある F=maや E = 1/2 mv^2なんかの速度以外が全て相対的になるため、速度が光速に近づくものは質量が無限に近づきます。

では次にアジャイル開発の話

アジャイル開発におけるスコープ

スコープは簡単にいうと機能です。あるプロジェクトにおいてプロジェクトを進めるにあたって考えなければいけないものが、

スコープ
リソース
納期・リリース日

の3つがあります。
あるプロジェクトで実際に開発したことがある方はわかるかもしれませんが、

リソース
納期・リリース日

は絶対的なものです。
リソースは減ることはあっても増えることはめったにありません。
納期・リリース日も特に受託の場合なんかは絶対に遅らせることは出来ません。

とすると、確実にスコープが揺らぐものとなります。

無理やり式に直すと
リリース日 - 現在の日 = スコープ x リソース
絶対的なリリース日とリソース、相対的なスコープという関係性が見えてくるかと思います。

2つの関係

ここまで見ていくと

絶対的なもの
相対的なもの

という2つのキーワードがあり
対応させると
光速 <=> リリース日、リソース
時間・空間 <=> スコープ
このような関係性が見えてきます。

ではこの関係性をどう活かしていこうかということですが、
これまで見てきたように光速は不変なものというのは物理学的に変わらない事実です。
そしてプロジェクトにおいてもリリース日、リソースは不変です。
つまりプロジェクトを成功させるにはいかにスコープを揺らがせてもいいかにかかっています。
設計の段階でスコープを不変のものにしてしまうとそのプロジェクトは絶対に炎上します。
スコープを変動させてプロジェクトがうまくいくようにどうディレクションしていくか。
これこそがアジャイル開発では重要なことです。

まとめ

特に構成も考えず書いていたら、相対性理論の説明いらなくね?みたいな記事になりました。
プロジェクトでも不要なスコープをどんどん削っていくことが重要ですね!
あとアジャイル開発においてリリース日を変動させる裏技も書いております。
詳しくはこちらの本を参考に!

アジャイルサムライ−達人開発者への道−

作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未
出版社/メーカー: オーム社
発売日: 2011/07/16
メディア: 単行本（ソフトカバー）
購入: 42人クリック: 1,991回
この商品を含むブログ (245件) を見る

正しい相対性理論

アーティスト: 相対性理論
出版社/メーカー: commmons
発売日: 2011/04/27
メディア: CD
購入: 7人クリック: 590回
この商品を含むブログ (107件) を見る

2014-03-15

MVCモデルで見るRubyとPHPの違い

ruby rails

約1年くらいPHPを触っていないのでもしかしたら的はずれなことを言ってしまうかもしれませんが、MVCモデルを例にとってRubyとPHPの違いを自分なりに考えてみたいと思います。

自分が利用したことのあるフレームワーク
 Ruby -> Rails
PHP -> CodeIgniter
なのでここから見ていきます。

ちなみにこれからダラダラと書きますが、結論は(個人的に)Rubyの方が優れているという内容を書きます。

MVCモデルについて、詳しく説明することもないのですが、RailsとCodeIgniterで大きく違う点を示したいと思います。
まずはCodeIgniterのMVCモデルから
f:id:nigohiroki:20140315143356p:plain
このようになっております。

次にRailsのMVCモデル
f:id:nigohiroki:20140315143422p:plain
両者での大きな違いは

Railsはviewに渡すのは変数ではなくオブジェクト
Railsはviewからもモデルのメソッドを呼び出す

つまりRubyは全てのものがオブジェクトであるという点からPHPとはMVCの概念も異なるということが言えます。

仮にとあるWebサービスのユーザーランキングページを作るとします。
そのページにはユーザーのランキング情報プラス各ユーザーの詳細情報も見ることができます。

CodeIgniterではまずモデルにランキング情報を取得するメソッドを作成します。
同様にモデルにユーザーの詳細情報を取得するメソッドも作成します。
コントローラーでランキング情報を取得するメソッドを呼び出し、
結果をループさせユーザーの詳細情報が付与されたランキング情報のハッシュを作成します。
そのハッシュをviewに渡しforeachで表示させます。
イメージ的には

<?php
//モデル
function ranking{
  ~
  // {"rank" => , "user_id" => }
  return ranking_hash;
}
function user_info($user_id){
  ~
  // {"id" => , "name" => }
  return user_info_hash;
}
?>

<?php
//コントローラー
$ranking = $this->モデル->ranking;
foreach($ranking as $user){
  $user_data       = $this->モデル->user_info($user["user_id"]);
  $ranking_array = { "rank" => $user["rank"], "user" => $user_data } 
}
?>

//ビュー
<?php foreach($ranking_array as $user): ?>
<tr>
  <td><?php echo $user["rank"]; ?></td>
  <td><?php echo $user["user"]["name"]; ?></td>
</tr>
<?php endforeach; ?>

このような感じかと思います。

一方Railsで同様のことをすると
コントローラーでモデルのランキングメソッドを呼び出す
ビューでモデルの詳細メソッドを呼び出す
このようになります。

#モデル
def self.ranking
  ~
  ranking_object
end
def user_name
  self.name
end

#コントローラー
@ranking = モデル.ranking

#ビュー
<% @ranking.each do |rank, user| %>
<tr>
  <td><%= rank %></td>
  <td><%= user.user_name %></td>
</tr>
<% end %>

このような感じになります。CodeIgniterと比べるとコントローラーのやることがかなり減るかと思います。
また、そもそもコントローラーで@rankingとしなくても、ビュー側で

<% モデル.ranking.each do |rank, user| %>

というようにも書くことが出来ます。
ただこれは一長一短でもあり、ビューにプログラミング要素を入れ過ぎないようにすることも必要です。

メリット・デメリットを整理すると

	メリット	デメリット
CodeIgniter	ビューのロジックが減るためデザイナーが扱いやすい	コントローラーが肥大化する
Rails	コントローラーがスッキリする	デザイナーにもオブジェクト指向を理解してもらう必要がある

あとは色々パターンがあるためRailsの場合はチューニングがめんどくさそうです。
CodeIgniterの場合はコントローラーのベンチマークをとってチューニングするだけで良さそうですが。

まとめですが、個人的にはコントローラーがスッキリするRailsの方が好きだし優れていると感じます!

駆け足気味でしたが、MVCモデルを例にとってRubyとPHPの違いを示してみました。

これから新たな言語を学ぶ方や、PHPをずっとやっている方はRubyを使ってみてはいかがでしょうか?

ちなみにずっとPHPをやっていた方は最初はコントローラーが長くなるかと思いますが、徐々に慣れていきスッキリとしたコントローラーになるでしょう。

Ruby on Rails 3 アプリケーションプログラミング

作者: 山田祥寛
出版社/メーカー: 技術評論社
発売日: 2011/05/12
メディア: 大型本
購入: 27人クリック: 664回
この商品を含むブログ (41件) を見る

Ruby on Rails環境構築ガイド

作者: 黒田努
出版社/メーカー: インプレスジャパン
発売日: 2013/03/22
メディア: 単行本（ソフトカバー）
クリック: 3回
この商品を含むブログ (6件) を見る

2014-03-12

Rails初心者から中級者になったと感じたきっかけ

ruby rails 考え

エンジニア(プログラマー)をやっていると基本的には徐々にレベルアップしていきます。
しかしある点で閾値を越えて、レベルが一気に上がると感じる瞬間があります。
皆さんどうでしょうか?

自分の場合は
クラスメソッドとインスタンスメソッドの違いをはっきり理解したことがそのきっかけでした。

これまでぼんやりとモデルにメソッドを追加していたものがかなり自信を持ってメソッドを追加出来るようになりました。

今回はクラスメソッドとインスタンスメソッドの違いを簡単に紹介して、他にも初級者から中級者に上がるようなパターンを考えてみたいと思います。

クラスメソッドとインスタンスメソッドの違い

本当にその名の通りなんですが、
クラス全体で使えるのがクラスメソッド
あるクラスのインスタンスで使えるのがインスタンスメソッド
具体例を書くと、rubyでは

class Dog
    #クラスメソッド
    def self.choge
    end

    #インスタンスメソッド
    def ihoge
    end
end

このように書きます。とりあえずクラスはDog(犬)です。
クラスメソッドは self.メソッド名という書き方をします。

メソッド内のselfの違い

これはこちらの記事が参考になります。
インスタンスメソッド内での self の値を調べた - (ﾟ∀ﾟ)o彡 sasata299's blog
クラスメソッド内ではオブジェクト、インスタンスメソッド内ではインスタンスとなります。
(解説していけば解説していくほどそのまんまだな)

呼び出し方の違い

呼び出し方は

#クラスメソッド
Dog.choge
#インスタンスメソッド
dog = Dog.new
dog.ihoge

のようになります。クラスメソッドはクラスからそのまま呼び出し、インスタンスメソッドはクラスのインスタンスから呼び出します。

使い方の違い

ここがある意味今回の記事一番のポイントかと思います。
説明するとこれまで同様、そのまんまの説明になるので、上記のDogを利用した具体例から。
クラスメソッドの場合

Dogのうち一番年齢の高いDogを取り出すメソッド
Dogのうちオスのみを取り出すメソッド

例えばこんな感じ

class Dog < ActiveRecord::Base
    # 一番年齢の高いDog
    def self.get_oldest
        self.order("age DESC").limit(1)
    end

    # オスのみを取り出す
    def self.get_male
        self.where(:sex => "male")
    end
end

要は「クラス全体の中から何かを取り出す」場合などに利用されます。

インスタンスメソッドの場合

とあるDogの年齢、性別をHashで取り出すメソッド
とあるDogの親のDogを取り出すメソッド(親が子のIDを持っているケース)

class Dog < ActiveRecord::Base
    # 年齢、性別
    def get_profile
        { :age => self.age, :sex => self.sex } 
    end

    # 親を取り出す
    def get_parent
        Dog.where(:child => self.id)
    end
end

こちらは「あるインスタンスの何かを取り出す」場合などに利用されます。インスタンスメソッドの場合は更新系もよく出てくるかと思います。

とりあえずここまででクラスメソッドとインスタンスメソッドの違いはなんとなくわかっていただけたかと。

初級者から中級者に上がるパターン

自分の場合は先に紹介したクラスメソッドとインスタンスメソッドの違いというところなのですが、
皆さんはいかがでしょうか?

オブジェクト指向が理解出来た
データ構造が理解出来た
ベンチマークを意識するようになった
探索や最適化などのアルゴリズムを実装出来た

などなどが考えられるかと思います。
というわけで今後はRails上級者目指して頑張って行きたいと思います!

パーフェクトRuby (PERFECT SERIES 6)

作者: Rubyサポーターズ,すがわらまさのり,寺田玄太郎,三村益隆,近藤宇智朗,橋立友宏,関口亮一
出版社/メーカー: 技術評論社
発売日: 2013/08/10
メディア: 大型本
この商品を含むブログ (22件) を見る

2014-02-22

スタートアップはいかにして技術的負債に立ち向かっていくか

ネタ考え

技術的負債が最近の話題なので自分もちょっと考えてみようかなと

まず技術的負債の定義から考えると

クソコード

読みにくい、メンテしにくい、おかしな動作するといったYMOコードのこと。

クソ設定ファイル

YMO設定ファイルのこと。

属人性のある技術的作業

~さんしか出来ないデプロイ。~さんしか出来ない復旧など、特定の誰かしか出来ない作業のこと。

まぁ他にも色々あるかと思いますが、とりあえずこのような感じかなと。
一般的にはコードレビューやテストコード、技術共有のミーティングなどで防ぎます。
しかしスタートアップはいくつかの理由により一般的な対処が出来ず技術的負債がめちゃくちゃ出やすい環境です。
その理由は、

理由1. とにかくスピード重視

テストコードなんか書いてる余裕などないと。とにかく動けばいいやと。

理由2. 仕様が固まりにくい

動きながら考えなきゃついていけないというのがスタートアップ。仕様を固めても次の週には意味がないものになっていたりすることがざらにある。

理由3. 人がいない

これは技術や作業を共有する人がいないということ。エンジニア一人で進めていたら属人性とかどうでもいいですよね、その時は。それによってオレオレコードオレオレ設定ファイル、オレオレ作業手順が生まれます。

スタートアップで技術的負債が生まれやすいのは上記のような理由にあるのではないかと思います。
そして技術的負債を残し積み重ねていった結果、3, 4年目に入るエンジニアが苦労するなど。
ブログに技術的負債を放置するクソみたいな会社と書かれます。
そのようなITベンチャーがこの世にいくつあるだろうか。

長い目で見た場合、スタートアップも技術的負債を放っておくわけには行きません。
そこで今回はスタートアップがその環境の中でどのように技術的負債に立ち向かっていくかを考えてみたいと思います。

スピード重視に対するソリューション

寝る時間、遊ぶ時間を削ってテストコードやcookbook, serverspecなどを書く。
仕事中はそんなの書いている余裕など全くありません。「いやテストコードを含めて実装だろ」。そんなのは重々承知の助なわけです。それ以上にスピードを求められるし自分自身が求めるわけです。
となると余暇を利用するしかありません。

フロント側も荒れがちなので、なるべくsassやcoffeescriptを利用する。
sassは以前から利用していたのですが、最近coffeescriptを利用してこりゃすごい!となりました。
sassは入れ子が書きやすいのでスコープが小さくなることが技術的負債になりにくいかなと。
coffeescriptは見やすさが格段に向上します。
coffeescriptはRails4を使っているとturbolink周りでハマるので注意。

仕様が固まりにくいことに対するソリューション

状況的には上記にもあるように、1週間前に実装したことが全く意味がないことだったみたいなそういう状況。意味のないコードがたまることが技術的負債レベルを向上させます。
そういう場合はスパッとそのファイルを消去!
使わない機能を実装した部分は使われなくなった瞬間消しましょう。
後になんだこれというのがなくなります。

人がいないことに対するソリューション

いくつか対策があると思います。一つは技術的負債へ理解を持つ。
作業している時に「あ、これいつか負債になる」っていうのが感覚でわかるようになればそれを避けつつ作業します。ただ「あ、これいつか負債になる。しかしアカギ意外にもこれをスルー」ということはよくあるので、強い心を持つ必要があります。
他には共有の場を設ける。最近は「Qiita team」というチームでノウハウや作業履歴を共有する場があるので積極的に使う。一人しかいなくても、後に優秀な人が入ってきてこれを見られると恥ずかしいということを考えると、技術的負債は生み出さなくなるかと思います。
エンジニアメンバーを最低2人にする。いなければCEOが技術を身につける。
監視が目的です。3人いればなお良いです。

という感じで少し無理矢理な感じもしますが、技術的負債への対策はしっかりと考えてやっていくべきではないかと思います。