2013-05-26

Pull Request が Merge された後でしたこと

前回、github のとあるリポジトリに Pull Request したことを綴りました。

githubでPull Request送られてきたら。

人生初めての Pull Request が Merge されて、
その後に何する必要があるの？ってところを
メモにします。

自分のローカルリポジトリにある、master ブランチが古くなってるはずなので
以下で Pull しましょう。

$ git checkout master
Switched to branch 'master'
$ git branch
  RouletteClass
* master
$ git remote add upstream https://github.com/whitech0c0/LabRoulette.git #fork元
$ git pull upstream master
remote: Counting objects: 16, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 10 (delta 4), reused 9 (delta 3)
Unpacking objects: 100% (10/10), done.
From https://github.com/whitech0c0/LabRoulette
 * branch            master     -> FETCH_HEAD
Updating 4d71127..a97d447
Fast-forward
 README.md   | 48 +++++++++++++++++++++++++++--------------------
 roulette.rb | 77 +++++++++++++++++++++++++++++++++++++++-------------------------------------
 2 files changed, 68 insertions(+), 57 deletions(-)
 mode change 100644 => 100755 roulette.rb
$ git push origin master
Counting objects: 13, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 1.31 KiB | 0 bytes/s, done.
Total 7 (delta 3), reused 0 (delta 0)
To https://github.com/yuji-shimoda/LabRoulette.git
   4d71127..a97d447  master -> master

次は、Pull Request した自分の修正用ブランチを更新する。

$ git checkout RouletteClass
Switched to branch 'RouletteClass'
$ git branch
* RouletteClass
  master
$ git rebase master
First, rewinding head to replay your work on top of it...
Fast-forwarded RouletteClass to master.

これで、Merge 済みの更新リポジトリに追いつけたはずです。

上記の作業は、以下を参考に作業しました。

GitHubでプルリクエスト用ブランチを保守するメモ

2013-05-25

github の Pull Request に初挑戦。

git や github の使い方をいまいち分かっていないので、お勉強。

こんなブログ記事を見つけました。
ソーシャルコーディング

実際、複数人でWEB上で開発するとなると github で Pull Request は避けて通れないはず

手順は、以下です。（初心者なので間違ってたら、バシバシ指摘してください）

github のリポジトリで、Fork をクリック
- 自分の github 上に、https://github.com/yuji-shimoda/LabRoulette.git が生成されます。
ローカル環境で git clone する
- $ git clone https://github.com/yuji-shimoda/LabRoulette.git
修正用のブランチを作成
- $ cd LabRoulette
- $ git checkout -b RouletteClass
各種のソースコードを修正したら、ローカルリポジトリに add/commit
- $ vi roulette.rb
- $ git add .
- $ git commit -m "commit message."
github のフォークしたリポジトリに、push
- $ git push origin RouletteClass
github のページから、pull request ボタンをクリック

とりあえず、はじめての Pull Request に挑戦してみました。

もっと、他にも便利な機能があるんだろーなーと感じた次第

2013-05-20

Ruby で RSS Reader の作成（その４）

今回は、すこし趣旨をずらしてみます。

Qiita にこんな情報が落ちてました。
OpenFastladderをherokuにデプロイする方法

最近、ローカル環境で動かしている Fastladder を heroku 環境で動かしたいなぁと
すこし挑戦してみました。

手順は、Qiita の投稿どおりです。

動かしてみた際の、ログイン画面はこんな感じ

f:id:yuji_shimoda:20130520231241p:plain

実際に、フィードを読み込ませた際の画面は、以下

f:id:yuji_shimoda:20130520231351p:plain

こんな簡単に My RSS Reader が出来てしまうのも
オープンソースの Fastladder と無料の heroku 環境のお陰ですね。

少しいじって遊んでみます。
＃本格的に使いこなすなら、有料を検討したほうが良いと書いているので
＃もっと自由度の高い VPS をレンタルしたほうがいいのかな〜

2013-05-18

ブログのデザイン変更します。（しました）

初めてブログにコメント貰えたんですが、以前のデザインだと
あまりにもコメントが読みにくかったのでちょっと変えてみました。

レイアウトとか、崩れたりすれかもしれませんが
今後もちょいちょい変えるかもしれません、、、

2013-05-17

Ruby で Thread を使う（その２）

RSS Feed をマルチスレッドで取得するテストコードを作成。
ブログにソースコード書いても読みにくいので、github 見てください。
ちなみに、スレッド使ってない方はこっち。

処理の概要は、以下です。

　スレッド版
　subscriptions.xml に記載された Feed のアドレスを取得して、
　登録件数分のスレッドを生成。RSS ライブラリで Feed のタイトル、リンク、記事を
　標準出力に対してHTML形式で出力する。

　スレッド使ってない方は、上の作業を地道に２４回繰り返す。

なぜ、２４件かというと普段チェックするニュースサイトの登録件数が２４件だから。

$ grep xmlUrl subscriptions.xml | wc -l
      24

まずはスレッド版のテストコードから。
最初、time コマンドで計測しながら
出力されるHTMLコードの行数を調べてみた。

$ time ./parallel.rb | wc -l
    3294

real	0m3.779s
user	0m1.985s
sys	0m0.152s
$ time ./parallel.rb | wc -l
    3294

real	0m3.220s
user	0m1.963s
sys	0m0.145s
$ time ./parallel.rb | wc -l
    3294

real	0m5.674s
user	0m1.991s
sys	0m0.149s
$ time ./parallel.rb | wc -l
    3294

real	0m3.191s
user	0m1.955s
sys	0m0.158s
$ time ./parallel.rb | wc -l
    3294

real	0m4.874s
user	0m1.974s
sys	0m0.153s
$ time ./parallel.rb | wc -l
    3294

real	0m5.715s
user	0m1.977s
sys	0m0.154s

計測した結果、TAT が安定しない、、、
なんでかなー、なんでかなーと考えていて
はたと気づく。＃記事の更新も、そんなに頻繁にしてなさそう

手動で、ぐだぐだ実行してるから
Ruby VM の起動に掛かる時間が、
一定してないんだろう、、、多分

というわけで、以下のような
シェルスクリプトにより連続実行テスト。

$ cat test.sh
#!/bin/sh
# by Yuji Shimoda

COUNTER=0

while :
do
  if [ $COUNTER -ne 10 ]; then
    time ./parallel.rb | wc -l
    COUNTER=$(($COUNTER+1))
  else
    exit
  fi
done

多分、TAT が安定するはず。

$ ./test.sh 
    3286

real	0m5.139s
user	0m1.996s
sys	0m0.150s
    3286

real	0m2.057s
user	0m1.922s
sys	0m0.140s
    3286

real	0m2.083s
user	0m1.948s
sys	0m0.141s
    3286

real	0m2.095s
user	0m1.949s
sys	0m0.140s
    3286

real	0m2.063s
user	0m1.926s
sys	0m0.144s
    3286

real	0m2.466s
user	0m1.949s
sys	0m0.144s
    3286

real	0m2.055s
user	0m1.925s
sys	0m0.141s
    3286

real	0m2.093s
user	0m1.955s
sys	0m0.147s
    3286

real	0m2.094s
user	0m1.960s
sys	0m0.142s
    3286

real	0m2.099s
user	0m1.951s
sys	0m0.141s
$

うん、安定した。
１回目のロードで時間が掛かってるけど、２回目以降は
キャッシュに載っかってるんで早い早い。
おおよそ、2 sec 程度

次は、スレッドなし版
test.sh を書き換えてテスト

$ ./test.sh 

real	0m7.561s
user	0m1.938s
sys	0m0.130s

real	0m5.948s
user	0m1.941s
sys	0m0.122s

real	0m7.536s
user	0m1.904s
sys	0m0.120s

real	0m5.093s
user	0m1.918s
sys	0m0.119s

real	0m5.987s
user	0m1.929s
sys	0m0.121s

real	0m5.223s
user	0m1.937s
sys	0m0.124s

real	0m7.301s
user	0m1.907s
sys	0m0.123s

real	0m4.403s
user	0m1.904s
sys	0m0.120s

real	0m4.466s
user	0m1.915s
sys	0m0.125s

real	0m4.907s
user	0m1.933s
sys	0m0.122s
$

えらい不安定やな、、、
thread 生成しない分、sys の使用率は若干低いめ
ただし、目に見えて分かるレベルの TAT の悪さ。
早くても 4.4 sec 〜 7.5 sec も処理に時間が掛かる。

最終的には、取得したフィード情報は
標準出力に出力する代わりに、SQL 発行して
データベースに登録する。
PostgreSQL とかDBの処理性能にもよるけど、スレッド版の方が
早く処理出来るということは明らかかな。

以上