nigoblog

技術系会社のCEOブログ~私的編~

ビッグデータ取り扱いまでの流れ1 収集編

最近ビッグデータを取り扱ってきているので、その流れを記録しようかと思います。
Ruby on Railsで構築していますが、一部以外は別の言語やフレームワークでも利用できます。

ビッグデータの定義ですが、この本の帯の「データサイズが悩みの種ならそれはもうビッグデータです」

Hadoopファーストガイド

Hadoopファーストガイド

っていうのがすごくしっくりきました。

丁度データサイズに悩み始めてきたため、ビッグデータを取り扱っているといえるでしょう。

ざっくりとした流れは

  1. fluentdのインストール
  2. td-loggerでアプリケーションログの吐き出し
  3. td-loggerで受け取ったログをS3に送信
  4. S3のデータをHadoopで解析
  5. Hadoopで解析したデータをRDSに突っ込む

というような流れとなっております。

fluentdのインストール

これはいろんなところで書いてあるのであまり深くは書きませんが、
こんな感じでインストールします。

/etc/yum.repos.d/td.repo

[treasuredata]
name=TreasureData
baseurl=http://packages.treasure-data.com/redhat/$basearch
gpgcheck=0
$ yum update
$ yum install td-agent

td-loggerでアプリケーションログの吐き出し

Gemfileにて

gem 'td-logger'

を追加しbundle install

ファイル
config/treasure_data.yml

development:
  agent: localhost:24224
  tag: アプリケーション名
  debug_mode: true  # enable debug mode

production:
  agent: localhost:24224
  tag: アプリケーション名
  debug_mode: false

# disable logging
test:

を追加

取得したい場所に

TD.event.post('[タグの名前]', ハッシュ)

するとログでは

datetime アプリケーション名.タグの名前 json

みたいな感じです。具体的に入れると

TD.event.post('test', { hoge: :piyo })

アプリケーション名をmy_appとするとログは

2014-03-29T00:40:11+09:00	my_app.test	{"hoge":"piyo"}

みたいな感じになります。

td-loggerで受け取ったログをS3に送信

次は

2014-03-29T00:40:11+09:00	my_app.test	{"hoge":"piyo"}

こちらのログをS3に入れます。

設定ファイルに次の設定を追加します
/etc/td-agent/td-agent.conf

<match my_app.event>
  type s3
  aws_key_id AWSのキー
  aws_sec_key AWSのシークレットキー
  s3_bucket バケット名
  s3_endpoint S3のリージョン.amazonaws.com
  s3_object_key_format %{path}%{time_slice}_%{index}_%{hostname}.%{file_extension}
  path events/
  buffer_path /var/log/fluentd/events_s3
  time_slice_format %Y-%m-%d/%H
  time_slice_wait 10m 
</match>

これでオッケー。
あとはしばらく動かして、バケットの中身を見ると、gzip形式のファイルがどんどん溜まっていきます。
それをhadoopで処理します。

動いてないと思ったら

tail -f /var/log/td-agent/td-agent

などでログを見て行きましょう。

というわけで今回はここまで。
次回はhadoopで処理する方法を書いていきます。

参考記事

fluentd+rails+mongoでサクッとログ環境を整備してみる - dev.log

データサイエンティスト養成読本 [ビッグデータ時代のビジネスを支えるデータ分析力が身につく! ] (Software Design plus)

データサイエンティスト養成読本 [ビッグデータ時代のビジネスを支えるデータ分析力が身につく! ] (Software Design plus)

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

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

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

相対性理論について

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

これから、光速は不変ということをもう少し詳しく説明しますが、
その前に不変じゃない普通の速度について説明します。
まずある人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つのキーワードがあり
対応させると
光速 <=> リリース日、リソース
時間・空間 <=> スコープ
このような関係性が見えてきます。

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

まとめ

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

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

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



正しい相対性理論

正しい相対性理論

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

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

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

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

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

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

  1. Railsはviewに渡すのは変数ではなくオブジェクト
  2. 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モデルを例にとってRubyPHPの違いを示してみました。

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

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

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

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

Ruby on Rails環境構築ガイド

Ruby on Rails環境構築ガイド

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 (PERFECT SERIES 6)


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

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

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

クソコード

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

クソ設定ファイル

YMO設定ファイルのこと。

属人性のある技術的作業

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

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

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

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

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

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

理由3. 人がいない

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

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

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

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

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

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

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

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

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

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


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

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

これはあっさり読めるのでおすすめ。コードの美しさに気を使うようになります。

入門Chef Solo - Infrastructure as Code

入門Chef Solo - Infrastructure as Code

インフラ構築の際はchefを利用すること。設定手順書を残すことがスピードを落とします。