プログラマでありたい

おっさんになっても、プログラマでありつづけたい

プログラミング・レスで5分でサックリWebスクレイピング「kimonolabs」

 「Rubyによるクローラー開発技法」で付録か何かで書こうか悩んだ末に書かなかったのが、kimonolabsの話です。kimonolabsは、クローラー/スクレイピングをオンラインで実行できるWebサービス(SaaS)です。クローラー本を書いておいて何ですが、9割の人は自分でクローラーを作らずに、この手のサービスを利用すれば事足りると思います。(書かなかった理由は、Ruby縛りサービスの継続性とスケジュールの問題です。主に最後)
f:id:dkfj:20140813182433p:plain

kimonolabsとは?



 kimonolabsは、先述のとおりWebスクレイピングをしてくれるSaaSです。会員登録してChromeの拡張をいれれば、すぐに使えるようになります。一般的に、Webスクレイピングする場合は、次のような手順が必要です。

  1. 対象ページのダウンロード
  2. ダウンロードしたページから、特定の箇所を抜き出す
  3. 抜き出したデータの保存

 対象ページのダウンロードとデータの保存はそれほど手間ではないのですが、2番目の特定の箇所を抜き出すというのが中々やっかいです。一般的には、各プログラムの構文解析器(パーサー)を使って、xpathやCSSセレクタなので要素を指定して抜き出します。パーサーは、Ruby製のNokogiriやPython製のbeautifulsoupなど色々あります。このツールの使い方を覚えるというのと、xpathやCSSセレクタなどHTMLの要素の指定の仕方の2つを覚える必要があります。それ以前に、プログラミングの仕方を知っていないと出来ません。
 kimonolabsを使えば、このあたりを一切知らなくてもスクレイピングできるという優れ物です。対象のページをブラウザで開いた上で、kimonolabの拡張を開いて取得したい部分をマウスで選択するだけです。簡単便利です。
 私も幾つかスクレイピングのSaaSを知っていたのですが、ここまで完成度が高いものはしりませんでした。前回の、Webスクレイピング勉強会@東京で教えて貰いました。

kimonolabsの使い方 APIの登録編



 それではAmazonの商品ページを対象に、実際の使い方を試してみましょう。アカウントとかは適当に作って下さい。今回の取得対象は、このページを対象に、全体のランキングとカテゴリーごとのランキングを取得するようにします。
※ステマ

1.対象ページを開いた上で、kimonolabのchromeの拡張を起動
f:id:dkfj:20140813185212p:plain

2.取得対象を指定する
 マウスのカーソルを取りたいあたりに移動させると、黄色で選択してくれます。その上で、不要な部分があれば☓をしていけば良いです。複数指定したい場合は、kimonoのメニューの+ボタンで増やします。
f:id:dkfj:20140813185746p:plain
ちなみに、中々思い通り選択してくれなくて、イライラすることもたまにあります。

3.取得データを確認する
 メニューの右の方の、=みたいなのや<>でプレビューできます。
f:id:dkfj:20140813190340p:plain
f:id:dkfj:20140813190356p:plain

4.APIとして登録
 確認して問題なければ、Doneボタンを押してAPIとして登録します。その際に、適当に名前を付けます。
f:id:dkfj:20140813190506p:plain

5.APIの詳細設定
 通知や訪問間隔などの設定をします。
f:id:dkfj:20140813190550p:plain

kimonolabsの使い方 データの取得編



 取得したデータは、kimonoの管理画面もしくはアプリケーションIDとAPIキーを指定したURLで取得できます。
・データのバージョン指定
http://www.kimonolabs.com/api/{VERSION_NO}/{API_ID}?apikey={YOUR_API_KEY}
・時系列で取得
http://www.kimonolabs.com/api/{API_ID}?apikey={YOUR_API_KEY}&kimseries=1

 1時間ごとに取得したデータを、時系列でみた例です
f:id:dkfj:20140813182447p:plain

 データは、json,csv,rssで取得できます。データをプログラムから呼び出して、さらにゴニョゴニョするといったことも簡単にできます。

まとめ



 かなり完成度も高く、無料の範囲でも充分利用できます。今回は紹介していませんが、ページネーションなどもできます。クローラーやWebスクレイピングは、それ自体が目的には成り得ません。収集したデータをどう活用するか、そこからが本当のスタートです。だから、データ取得の部分をサービスで代用できるのであれば、できるだけ利用して楽をすべきです。ということで、今は必要でなくても、頭の片隅に記憶しておいたら良いと思いますよ。
 ついでに言うと、自作のクローラーはどういった場合に作ればよいのか?夏休みの自由研究と、既成のサービスで機能的に物足りなくなってからで良いと思います。もしくは、このサービスをキッカケにクローラーに興味をもったら、この本あたりで中でどのように動いているのか勉強するのも良いですよ。※ステマ


See Also:
『Rubyによるクローラー開発技法』を書きました
KimonoLabsと今後のサービスのあり方のはなし


参照:
オープンデータのためのスクレイピング
第1回Webスクレイピング勉強会@東京 (全3回) - connpass


Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

『Rubyによるクローラー開発技法』を書きました

 勉強会やスライドで紹介していましたが、Ruby×クローラーという題材で、『Rubyによるクローラー開発技法』という本を書かせて頂きました。RubyとEmacsの鬼であるるびきちさんとの共著です。


Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

この本を書いた理由



 そもそものキッカケは、るびきちさんのエントリーにある通り、SBクリエイティブの編集者さんが、クローラーの作成経験のある人を探していて、私の書いた「オープンソースのRubyのWebクローラー"Anemone"を使ってみる」を読んで打診してくださったというのが始まりです。
 私自身も、Webからデータを収集して分析するということは、趣味として長年やってきました。一方で、本業の方でクローラーというものを作ったことはなく、せいぜい業務効率化でデータ取得をサポートするスクリプトを作る程度です。もっと言えば、Webサイトの運用で、質の悪いクローラーと戦うことの方が多かったです。そんなこともあり、クローラーというある種グレーゾーンに入りやすいものを題材とするので、書いても良いのかという悩みました。また、そもそもクローラーの本の需要は、ニッチな上に寿命が短いのではという懸念もありました。
 いろいろ考えることはありましたが、クローラーやスクレイピングの技術を正しく使えば有用なことは間違いありません。そこで、私なりのクローラーというものを伝えられればと思い挑戦してみました。

本の内容



 6章構成になっています。

  • 1章 10分クローラー作成
  • 2章 クローラー作成の基礎
  • 3章 収集したデータを分析する
  • 4章 高度な利用法
  • 5章 目的別クローラーの作成
  • 6章 クローラーの運用

 2&3章で、データの収集から解析まで一通り取り扱っています。nokogiri&anemoneやxpathといった基本的なライブラリの使い方から、軽く正規表現や形態素解析・自然言語処理の話をしています。4章の部分は、クローラーを拡張していくにはどうするかという観点で書いています。そして、5章は目的別のクローラーということで、実際のサイトを対象にどのようにデータをとってくるのかを具体的に書いています。おなじみの株価や新聞からの情報収集や、iTunes StoreやGoogle Playからのアプリランキング取得など20以上のトピックスがあります。最後の6章は、主にサーバサイドで動かすにはという話です。この辺りは、AWSの各種サービス(SNS,SQS)との連携などにも触れています。

 全般的には、クローラーを初めて作る人を意識して書いています。クローラーとかスクレイピングは、超絶テクニックが有るわけではなく、どちらかと言えば泥臭い作業の連続です。その辺りを、どのように考えながら作るのかを書いたつもりです。

まとめというか感想



 本を書くということは初めての経験でした。想像以上の大変さで、改めて執筆者の凄さというのを認識できました。また、本の冒頭に家族への感謝の気持ちが書かれていることが多く、今までいったい何なんだろうと思っていました。自分で書いてみて初めて解ったのですが、家族の協力がなければ執筆作業はとてもじゃないですが出来ないです。(平日の晩や土日が潰れるので、家事や子育てなどの負担が重くなる)本当に感謝の気持ちで一杯です。
文系上がりのエンジニアとして何者でもなかった自分が、何かには成れたように思えます。

See Also:
RubyでWebスクレイピングの話をしてきました。第1回Webスクレイピング勉強会@東京
Ruby製の構文解析ツール、Nokogiriの使い方 with Xpath
あらためてRuby製のクローラー、"anemone"を調べてみた
オープンソースのRubyのWebクローラー"Anemone"を使ってみる
開発用プロキシ、「CocProxy」が便利
Rubyによるクローラー開発技法の目次


参照:
新刊『Rubyによるクローラー開発技法』2014/08/25発売! | るびきち×Emacs
SBクリエイティブ:Rubyによるクローラー開発技法

Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

Rubyによるクローラー開発技法 巡回・解析機能の実装と21の運用例

Bees with machine gunsを使って負荷テスト

 静的サイトの運用であれば、現状ではS3 Web Hosting機能が最適と考えています。OSやミドルウェアのアップデートも不要で、かつ仮想サーバを起動するより圧倒的に安価です。一方で、ほぼ無敵のS3といえども、一定時間で過剰なアクセスがあった場合はスロットリング(throttling)といって、規制されてアクセス制限が掛かる可能性があります。しかし、その閾値がどれくらいなのか、謎です。(全体のリソース状況によるので、一定ではないとのこと)
 ちょっと試してみたかったので、負荷テストをおこなってみました。S3に対する負荷テストの場合、そんじょそこらの負荷では太刀打ち出来ません。そこで、複数のサーバから負荷を掛けてみることにしてみました。と言っても、複数のサーバをコントロールするのは面倒臭いので、Bees with machine gunsを使ってみました。

Bees with machine gunsとは?



 Python製の負荷テストツールです。Bees with machine gunsをインストールしたマシン(親機)から、Beeとよばれる子機(EC2 micro instance)を操作します。子機は、任意の数を起動可能です。複数のBeeから一斉に負荷を掛けて、最後に親機で集計します。負荷テスト自体は、Apache Benchを利用しているようです。
f:id:dkfj:20140728051149p:plain

Bees with machine gunsのインストール



Bees with machine gunsは、以下のモジュールに依存しています。

  • Python 2.6
  • boto
  • paramiko

 特別なものが無いので、楽勝と思いきやハマりました。Amazon Linuxを利用してたのですが、手順通り進めていくと、下記のようなエラーにぶち当たります。

/usr/lib64/python2.6/site-packages/Crypto/Util/number.py:57: PowmInsecureWarning: Not using mpz_powm_sec. You should rebuild using libgmp >= 5 to avoid timing attack vulnerability.
_warn("Not using mpz_powm_sec. You should rebuild using libgmp >= 5 to avoid timing attack vulnerability.", PowmInsecureWarning)

Traceback (most recent call last):
File "/usr/bin/bees", line 3, in
from beeswithmachineguns import main
File "/usr/lib/python2.6/site-packages/beeswithmachineguns/main.py", line 27, in
import bees
File "/usr/lib/python2.6/site-packages/beeswithmachineguns/bees.py", line 36, in
import paramiko
File "/usr/lib/python2.6/site-packages/paramiko/__init__.py", line 69, in
from transport import SecurityOptions, Transport
File "/usr/lib/python2.6/site-packages/paramiko/transport.py", line 32, in
from paramiko import util
File "/usr/lib/python2.6/site-packages/paramiko/util.py", line 32, in
from paramiko.common import *
File "/usr/lib/python2.6/site-packages/paramiko/common.py", line 98, in
from Crypto import Random
File "/usr/lib64/python2.6/site-packages/Crypto/Random/__init__.py", line 29, in
from Crypto.Random import _UserFriendlyRNG
File "/usr/lib64/python2.6/site-packages/Crypto/Random/_UserFriendlyRNG.py", line 38, in
from Crypto.Random.Fortuna import FortunaAccumulator
File "/usr/lib64/python2.6/site-packages/Crypto/Random/Fortuna/FortunaAccumulator.py", line 39, in
import FortunaGenerator
File "/usr/lib64/python2.6/site-packages/Crypto/Random/Fortuna/FortunaGenerator.py", line 36, in
from Crypto.Cipher import AES
File "/usr/lib64/python2.6/site-packages/Crypto/Cipher/AES.py", line 50, in
from Crypto.Cipher import _AES
ImportError: /usr/lib64/python2.6/site-packages/Crypto/Cipher/_AES.so: undefined symbol: rpl_malloc

 暗号化あたりのモジュールの問題のようで、GNU MPとMPIRを入れ替えた上で、再ビルドが必要のようです。この辺りを参考に、設定します。
The Bug Charmer: Building PyCrypto on Amazon EC2

# yum groupinstall "Development Tools"
# yum install python-devel
# 
# ./configure
# make
# make check
# make install
# wget https://ftp.gnu.org/gnu/gmp/gmp-6.0.0a.tar.bz2
# bzip2 -dc gmp-6.0.0a.tar.bz2 | tar xvf -
# cd gmp-6.0.0
# ./configure
# make
# make check
# make install
# wget http://www.mpir.org/mpir-2.6.0.tar.bz2
# bzip2 -dc mpir-2.6.0.tar.bz2 | tar xvf -
# cd mpir-2.6.0
# ./configure
# make
# make check
# make install
# yum reinstall python
# wget http://ftp.dlitz.net/pub/dlitz/crypto/pycrypto/pycrypto-2.6.tar.gz 
# tar xzvf pycrypto-2.6.tar.gz 
# cd pycrypto-2.6
# vi configure
if test $ac_cv_func_malloc_0_nonnull = yes; then :

$as_echo "#define HAVE_MALLOC 1" >>confdefs.h

#else
#  $as_echo "#define HAVE_MALLOC 0" >>confdefs.h

#   case " $LIBOBJS " in
#  *" malloc.$ac_objext "* ) ;;
#  *) LIBOBJS="$LIBOBJS malloc.$ac_objext"
# ;;
#esac


$as_echo "#define malloc rpl_malloc" >>confdefs.h

# pip uninstall PyCrypto
# python setup.py build
# pyton setup install
# pip install beeswithmachineguns

インストール後に、botoの設定を行ないます。.botoファイルとpemの用意をします。

vi ~/.boto
[Credentials]
aws_access_key_id = 'your access key'
aws_secret_access_key = 'your secret access key'

Bees with machine gunsの利用



 設定が全て終わっていれば、次のようなコマンドでBee(子機)の起動できます。

bees up -s 4 -g セキュリティグループ名 -k pemファイル名

 -sが起動するサーバ数、-gがセキュリティグループ名です。注意点としてはNon-VPCのネットワークで起動するので、Non-VPCのセキュリティグループを作成しておく必要があります。そして、親機からsshでアクセス出来るようにしておく必要があります。

 負荷テストは、次のような形です。
nが負荷リクエストの総数。cが同時接続数です。少ない台数で同時接続数を上げ過ぎると、処理しきれずにエラーがでます。注意点としては、/で終わるURLでないとテストできません。

# bees attack -n 10000 -c 250 -u http://xxxxxxxxxx.s3-website-ap-northeast-1.amazonaws.com/
Read 4 bees from the roster.
Connecting to the hive.
Assembling bees.
Each of 4 bees will fire 2500 rounds, 62 at a time.
Stinging URL so it will be cached for the attack.
Organizing the swarm.
Bee 0 is joining the swarm.
Bee 1 is joining the swarm.
Bee 2 is joining the swarm.
Bee 3 is joining the swarm.
Bee 3 is firing his machine gun. Bang bang!
Bee 2 is firing his machine gun. Bang bang!
Bee 0 is firing his machine gun. Bang bang!
Bee 1 is firing his machine gun. Bang bang!
Bee 1 is out of ammo.
Bee 0 is out of ammo.
Bee 2 is out of ammo.
Bee 3 is out of ammo.
Offensive complete.
     Complete requests:		10000
     Requests per second:	406.720000 [#/sec] (mean)
     Time per request:		621.828500 [ms] (mean)
     50% response time:		544.250000 [ms] (mean)
     90% response time:		804.250000 [ms] (mean)
Mission Assessment: Target successfully fended off the swarm.
The swarm is awaiting new orders.

 上記の結果をみると、毎秒406リクエストをこなしていたのが解ります。念の為、アクセスログを見てみると、全て200 O.K.でした。

 では、S3の限界に挑戦する為に、台数を増やしてみます。追加でBeeを増やせないようなので、一度落とします。

# bees down

 10台立ててみました。Beeが一杯です。
f:id:dkfj:20140728051259p:plain

# bees attack -n 100000 -c 250 -u http://xxxxxxxxxx.s3-website-ap-northeast-1.amazonaws.com/
Read 10 bees from the roster.
Connecting to the hive.
Assembling bees.
Each of 10 bees will fire 10000 rounds, 25 at a time.
Stinging URL so it will be cached for the attack.
Organizing the swarm.
Bee 0 is joining the swarm.
Bee 1 is joining the swarm.
Bee 2 is joining the swarm.
Bee 3 is joining the swarm.
Bee 4 is joining the swarm.
Bee 5 is joining the swarm.
Bee 6 is joining the swarm.
Bee 7 is joining the swarm.
Bee 8 is joining the swarm.
Bee 9 is joining the swarm.
Bee 5 is firing his machine gun. Bang bang!
Bee 6 is firing his machine gun. Bang bang!
Bee 3 is firing his machine gun. Bang bang!
Bee 0 is firing his machine gun. Bang bang!
Bee 2 is firing his machine gun. Bang bang!
Bee 8 is firing his machine gun. Bang bang!
Bee 4 is firing his machine gun. Bang bang!
Bee 4 is out of ammo.
Bee 6 is out of ammo.
Bee 0 is out of ammo.
Bee 5 is out of ammo.
Bee 2 is out of ammo.
Bee 8 is out of ammo.
Bee 3 is out of ammo.
Offensive complete.
     3 of your bees didn't make it to the action. They might be taking a little longer than normal to find their machine guns, or may have been terminated without using "bees down".
     Complete requests:		70000
     Requests per second:	330.450000 [#/sec] (mean)
     Time per request:		529.952571 [ms] (mean)
     50% response time:		523.142857 [ms] (mean)
     90% response time:		548.285714 [ms] (mean)

 3台のBeeが行方不明になってしましました。親機の性能不足でしょうか?それとも、子機の性能不足でしょうか?念の為、親機をc3.largeに変更しておきます。

 同時接続数を減らして、再度実行します。

# bees attack -n 10000 -c 200 -u http://xxxxxxxxxx.s3-website-ap-northeast-1.amazonaws.com/
Read 10 bees from the roster.
Connecting to the hive.
Assembling bees.
Each of 10 bees will fire 1000 rounds, 20 at a time.
Stinging URL so it will be cached for the attack.
Organizing the swarm.
Bee 0 is joining the swarm.
Bee 1 is joining the swarm.
Bee 2 is joining the swarm.
Bee 3 is joining the swarm.
Bee 4 is joining the swarm.
Bee 5 is joining the swarm.
Bee 6 is joining the swarm.
Bee 7 is joining the swarm.
Bee 8 is joining the swarm.
Bee 9 is joining the swarm.
No handlers could be found for logger "paramiko.transport"
Traceback (most recent call last):
  File "/usr/bin/bees", line 5, in <module>
    main.main()
  File "/usr/lib/python2.6/site-packages/beeswithmachineguns/main.py", line 127, in main
    parse_options()
  File "/usr/lib/python2.6/site-packages/beeswithmachineguns/main.py", line 119, in parse_options
    bees.attack(options.url, options.number, options.concurrent)
  File "/usr/lib/python2.6/site-packages/beeswithmachineguns/bees.py", line 325, in attack
    results = pool.map(_attack, params)
  File "/usr/lib64/python2.6/multiprocessing/pool.py", line 148, in map
    return self.map_async(func, iterable, chunksize).get()
  File "/usr/lib64/python2.6/multiprocessing/pool.py", line 422, in get
    raise self._value
AssertionError: PID check failed. RNG must be re-initialized after fork(). Hint: Try Random.atfork()

 paramiko.transportのエラーがでました。

感想



 この後も、何度もパラメータや起動台数を変更しながら試してみました。どうも台数や接続数が多いと安定しない模様です。もう少し、調べてみる必要があります。S3 WebHositingに関して言えば、秒間400接続くらいであれば、余裕でこなせる模様です。流石!!


参照:
newsapps/beeswithmachineguns · GitHub
The Bug Charmer: Building PyCrypto on Amazon EC2

62nd Ruby/Rails勉強会@関西に参加してきた

 ここ半年ほど、Rubyでクローラーを作る本を書いていました。そんなこともあり、前回JAWSUG三都物語に参加した時に、アジャイルウェアの川端さんにRuby関西で話さないかとお誘いを受けました。もともとRubyのコミュニティに興味あったので、参加させて貰いました。
http://rubykansai.doorkeeper.jp/events/1316062nd Ruby/Rails勉強会@関西 #rubykansai - Ruby関西 | Doorkeeper

他の方の発表



RailsGirlsOsakaに参加して思ったこと
 RailsGirlsにスタッフとして参加した@to_uedaさんの感想。RailsGirls面白そうです。次は京都の企画があるので、興味がある人はチェック。
Rails Girls - Japanese


【LT】ちょっとしたTipsの提案をします
 @pinzoloさんのLT。デバッグツールなど個々人が独自で使うGemは、Gemfile.localを使おうという話。最初はGroupじゃダメなのと思ってたけど、自由な環境を使いたいという前提が解った時にしっくりきました。

【LT】るびまの告知
@muryoimplさんのLT。るびまが10周年で、記念メッセージ募集中のこと。併せて、るびまの編集・発行フローの紹介。るびまの中の人、初めてみました。もうちょっと話聞いてみたかったです。
Rubyist Magazine 十周年へのメッセージ


Railsで実装されているGitLabのGit Flow | GitLab実践入門 - Merge Requestによる開発
 GitLabを使って、GitHubチックにGit Flowを使う話。かなり参考になりました。会場からも、かなり具体的な質問が出てきて勉強になりました。リポジトリもCVS⇒SVN⇒Gitと進化してきているので、開発フローも改めて考えなおした方が良いですね。

「develop ブランチなんてオワコン」説
develop ブランチなんてオワコン - Togetterまとめ

Ruby初級者向けレッスン 50回 ブロック
@higakiさんによるRubyレッスン。毎回恒例のようで、今回はblockについて。言語の基本的な所をちゃんと勉強したことが無かったので、かなり勉強になりました。
higaki/learn_ruby_kansai_62 · GitHub

@IT Rails4入門記事をツッコもう
 時間が余ったので急遽追加されたコンテンツ。@agilekawabataさんがモデレータとなって、アジャイルウェアさんが連載している「開発現場でちゃんと使えるRails4入門」について話しあおうという企画。私も発表者の一人として、壇上にあがったもののRails4はまだ使っていないので特に突っ込めることは無かったです。すんません。テーマとして挙がったのは

  • rvm派 or rbenv派。

  壇上は、rbenv派多数。rvm派は川端さんと私だけ。rbenvが軽量なのが人気の理由とのこと

  • 利用するエディタ、開発環境は?

  意外なことにvim派とemacs派が多数で、それぞれ半々くらい。その次が、sublimetext。他にはAtomとNetBeans。みんな軽い環境が好きなんですね。(私もVim派)

  • Rails4の新機能つかってる?

  8つくらいの機能について、軽い解説と使っているかどうか。端末ごとのテンプレートは良いねという話と、config/secrets.ymlは必須だねという結論。Module#concerningは、どう使うのが良いか中々難しいとのことです。後は、CSRFプロテクションの変更は対応必須。

 全般的には、記事へのツッコミというより、川端さんへのツッコミになっているのが面白かったです。

感想



 初参加でしたが、かなり楽しかったです。参加者のレベルは、本当の初心者から上級者まで様々です。間違ったことを言っても直ぐにマサカリが飛んできて訂正してもらえるので、発表する方としても安心して話せるのではという感じでした。また、最後の告知で知ったのですが、町ごとにRuby勉強会が立ち上がっていて、気軽に勉強できる下地ができているようです。なかなか見習うべき所が多かったです。


See Also:
Rubyで作るクローラー Ruby crawler

賃貸でも工事なしで付けられるワイヤレスドアモニタ パナソニックのドアモニ VL-SDM110

 お家の防犯グッズの1つに、ドアモニタがあります。最近の物件だと当たり前のようについてたりしますが、ちょっと古い物件だと付いていないことが殆どです。この前まで住んでいた所にも付いてませんでした。賃貸だと工事できないので、ドアモニタは付けれないかなぁと思ってたのですが、ワイヤレスなこのご時世だと簡単に付けれました。


 私が使っていたのは、パナソニックのVL-SDM100という機種です。3ミリくらいの隙間があれば付けられるという代物なので、結構な確率で取り付けられるとおもいます。取り付けた様子は下の写真の通りですけど、殆ど違和感なかったです。

外から見た写真
f:id:dkfj:20140113113939j:plain

横から見た写真
f:id:dkfj:20131104140815j:plain

部屋の中から見た写真
f:id:dkfj:20131104140819j:plain

 かなりスッキリしていますよね。そして、画面は専用のモニタで見るのですが、ボタンを押して数秒くらいで見えます。操作もボタンを押すだけで、簡単です。息子が2歳くらいの時から、ピンポンとチャイムがなるとトコトコ歩いて行って、教えてもいないのにモニターを操作して見ていました。それくらい簡単です。電池の持ちもよくて、半年に1回くらいの交換で充分です。
 賃貸なのでドアモニタ諦めてるという人は、是非セキュリティの向上に検討してみてはいかがでしょうか?後は、不動産を貸している人も、ちょっとした付加価値向上に良いのではないのでしょうか?1万円くらいです。

「クラウドソーシングの衝撃」は、誰にとって衝撃なのか?

 先日の日替わりセールで買っていたクラウドソーシングの衝撃 (NextPublishing)を読みました。流し読みなので、後でゆっくり読むつもりだけど、頭に残ったの点は2つです。

  • 個人的に仕事を頼んでみたい
  • スキルをもった暇人の暇つぶしと比較されるプロはたまらんなぁ

個人的に仕事を頼んでみたい



1点目については、自分の苦手の分野のところを数万円くらいの金額でこなしてくれるのであれば、個人的にも仕事を頼んでみたいですね。最近はあまりしていませんが、個人的に自分が使うiOSアプリを作ったりします。自分用なのでアイコンやアプリ内のボタン等は、デザインもへったくれもないようなものになっています。クラウドソーシングが、その辺りいい感じのものが安価で発注できるのであれば、お願いした上でiTunes Storeとかに並べるのも面白いなぁと思います。また、もっと言うと、作りたいけど時間が取れずに取り掛かっていないものは山ほどあるので、プログラミングをお願いするのも今となってはありかもしれません。

スキルをもった暇人の暇つぶしと比較されるプロはたまらんなぁ



 この本を読んで、一番衝撃を受けたのが下記の1節です。

 ランサーズにコンペティション型の仕事として発注した。応募期間がわずか1週間であったにもかかわらず、152件の応募作品が集まり、その中の1件が記念ロゴとして採用された。この採用された記念ロゴは、実際に使用されており、同社のウェブサイトでみることができる。日活がこの採用されたロゴの製作者に報奨金として支払ったのは、わずか7万円であった。業界関係者の証言によると、この仕事を従来のように大手広告代理店やデザイン会社に発注した場合は、152件の候補デザインを出してもらうためには1000万円以上の予算と、3ヶ月以上の時間がかかったであるとのことであった。

 既存の広告代理店やデザイン会社に発注したら1,000万円掛かるはずだけど、クラウドソーシングだと7万円で済んだということです。それもそのはずです。仮に1作品7万円と仮定すると、クラウドソーシングでも、実際は152個×7万円で1,000万円程度の制作活動があったのです。それを採用されたものだけに支払うという方式を取ることにより、残りのコストが無かったことになっているだけです。
 これは、既存のルールで戦っている会社は勝てません。あとクラウドソーシングに参加している人たちも、勝てません。利益があるのは、システムを作っている胴元と発注者だけです。システム設計として著しく不均衡ですが、世の中には暇を持て余した高スキルの人というのは沢山いるということで成り立っているのでしょう。儲けは二の次で、評価されれば良いという動機の人も多々いると思います。そうなると、元々それで生計を立てていた人はたまらんやろなぁというのが感想です。


 一方で我が身を省みると、本業の仕事としてAWSの導入コンサルやトレーニングをする一方で、JAWSUGでは無償でハンズオンの手伝いとか設計相談しています。両者について自分の中で整合性を考えたこともなかったですが、この辺りの動きがクラウドソーシングなどの動きと似ているのかもと少し考えました。そもそもオープンソースの成り立ちも同じですね。

まとめ

 クラウドソーシングの定義自体は、ずっと前からしっていました。しかし、身近なものとして考えることがなく別世界のものだと思っていました。どうやら、そうではなさそうですね。この手のものを理解するには、使ってみるのが一番なので何か試してみようと思います。

クラウドソーシングの衝撃 (NextPublishing)

クラウドソーシングの衝撃 (NextPublishing)

夏のJAWS-UG 三都物語 2014でCDP道場に入門してきました

f:id:dkfj:20140708075033j:plain
(西島さん、撮影の写真)


 7/5に開催された夏のJAWS-UG 三都物語 2014で、もう1つのネタです。一度はやってみたいと思っていた、CDP道場に初めて参加してきました。もともとスタッフとしての参加でしたが、JAWS−UG沖縄の西島さんの尽力のお陰で、当日まで何もせず手ぶらで参加してチームリーダするだけで済みました。ありがとうございます&役に立たずにすいません。

CDP道場について



 お題とチームの回答については、今後も使い回しをする可能性があるので省略します。(正直言うと、お題のURLも結果のアーキテクチャの写真も残しておくのを忘れてました。)私のチームには、AWSを普段使いしている人はいなかったものの、オンプレミスでのアーキテクチャ設計が豊富な人がいたので、やりたいことをAWSでどう実現するかを翻訳するだけで、ほぼアーキテクチャが完成しました。その点、非常にチームに恵まれていました。チームメンバーの皆さん、ありがとうございました。
 ちなみに初めて参加だったのですが、経験者としてCDP道場に参加するのは、どこまで引っ張って良いか非常に悩ましいです。今回の場合は、アーキテクティングの時間が、1時間と非常に短かかったです。AWSに関しては初心者の方が殆どなので、調べながらではタイムアウトになることは目に見えていました。となると、AWS難しいという印象だけ残して帰っていくことになるかもしれません。一方で、私が主体となってやると、恐らく置いてけぼり感が満載で、面白くないでしょう。そう言った点で、非常にさじ加減が難しかったです。最後の方は、時間がなくてちょっと答えを出し過ぎてしまいました。
 初心者向きであれば、AWSの各サービスのチートシートを作って、30分で説明して2時間くらいあれやこれやが出来ればなぁと思いますが、全体の尺が非常に長くなるので中々難しいですね。アーキテクチャの選択ごとに、関係するサービスの説明をしていたのですが、短い時間でどこまで伝えられたか自信がないです。

セッションストアと外接について



 最後に、AWSの堀内さんを始めJAWSUGのコアメンバーの猛者に色々とツッコミを頂きました。印象に残ったのが2点。1つ目は、セッションストアにElastiCacheという選択に対して、MultiAZをどう対応させるかという指摘です。これは、ElastiCacheのMemcachedがAZを跨いでCache Clusterを構築できないことに起因します。セッションストアにMemcachedを使うというアイデアに、それならElastiCacheがあるよという脊髄反射をして、その辺りの考慮を完全に失念していました。
 会場でのディスカッションでは、DynamoDBをセッションストアに使ってはというアイデアなどが出てきました。自分ならどうするかなという所を、改めて考えてみました。まず基本方針としては、以下3点です。

  • セッションストアは、必ずアプリケーション・サーバから別だしにする(ローカルのサーバのメモリにセッションを格納しない)
  • レプリケーション機能は、過信しない(セッション用途で使うのであれば、準リアルの同期(≒レプリケーション)では不足)
  • ELBのスティッキー設定は、補助的に使う(例え同じサーバに割り振られなくても、セッションがある状態にする)

 上記考慮の上で、セッションストアに何を使うかの優先順位です。

  1. アプリケーションがAPIの類であれば、ステートレスにしてセッションを使わない
  2. ミドルウェア/フレームワークで、セッションストアとしてDynamoDBを利用できるのであれば、それを利用する
  3. EC2上にKyotoCabinetを構築して、マルチマスタ構成にする。ただし、アプリ側からはマスタスレイブ構成として、どちらかのAZを優先して接続するようにする。(マスタに接続できない場合は、アプリ側でスレイブに倒す)
  4. 選択肢がない場合は、DBをセッションストアとして利用する
  5. ELBの方でスティッキー設定をした上で、ミドルウェアのセッションのレプリケーション機能を使う
  6. セキュリティ上問題にならないのであれば、署名付きでCooki Storeも検討する

 正直、使うミドルウェアやフレームワーク次第なのですが、みんなどうしているのでしょうか?各言語・フレームワークごとのベストプラクティスをまとめてみたいものですね。(1年ほど前に、考えていました。)
アプリケーション・サーバのセッションの保存先の話


 2点目の指摘事項は、外部システムの接続をサーバから直接で良いのかという点です。要は、外部のシステムと密結合にする危険性についてです。この指摘については、100%同意です。基本的にはSQSをかまして、システム間を疎結合にします。場合によっては、SWFが使えないか考えます。この辺りは、密結合の危険性とSQS,SWFが何ぞやという説明が必要なので、時間切れになってしまいました。

感想



 やってみて解ったのですが、CDP道場は上手くやればどんなレベルの人にも勉強になります。初心者の人は、中級者以上の人がどう考えるのか。また中上級者の人は、AWSやJAWSUGのコアメンバの指摘やディスカッションを通して、別の見方に触れられます。中々、効率的な学習の仕方だと思うので、機会があれば臆せずに積極的に参加すると良いですね。
 ちなみに個人的には、悩む機会が多い共有ストレージやコンテンツ同期の方法でCDP道場やって、色々なパターンを見てみたいと思いました。


See Also:
アプリケーション・サーバのセッションの保存先の話
アプリケーション・サーバのセッションの保存先の話


参照:
CDP道場とは?その1 | 夏のJAWS-UG 三都物語 2014
CDP道場とは?その2 | 夏のJAWS-UG 三都物語 2014
CDP道場とは?その3 | 夏のJAWS-UG 三都物語 2014
CDP道場とは?その4 | 夏のJAWS-UG 三都物語 2014


Amazon Web Servicesクラウドデザインパターン設計ガイド

Amazon Web Servicesクラウドデザインパターン設計ガイド