プログラマでありたい

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

賃貸でも工事なしで付けられるワイヤレスドアモニタ パナソニックのドアモニ 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クラウドデザインパターン設計ガイド

夏のJAWS-UG 三都物語 2014でElasticity の話をしてきました

 7/5に開催された夏のJAWS-UG 三都物語 2014で、初心者向けセッションでElasticityというテーマで話してきました。中身は、Elastic Load Balancer(ELB)とAutoScaling、Elastic IP(EIP)についてです。
 最初にアンケートをとったところ、40人くらいの参加者で、EIPを使ったことがある人が2割程度。ELBが数人で、AutoScalingは0という状況でした。AWSがギーク層だけでなく、一般的に広がってきているのが実感できて、中々うれしい瞬間でした。

伝えたかったことと反省点



 ELBとAutoScalingについては、資料作成時に設定の仕方を説明するか構造を説明するか悩んでました。結局、全体像が解からないと、設定の仕方を知っても仕方がないかと思い構造を中心にしました。当日話してみて、その選択で間違いはなかったと思いましたが、一方で失敗したという点があります。そもそも負荷分散装置(ロードバランサー)が何ぞやという説明が一切なかったので、置いてけぼりの人がそれなりにいたと思います。その辺、資料がなくても臨機応変に説明出来るようになりたいですね。
 ちなみにElasticityというお題だったのですが、これを発音するのが非常に難しかったです。カタカナにすると、「イラステシティー」。噛みまくりました。

感想



 今月1日から東京転勤になった為、大阪在住者としてのJAWSUG大阪参加はこれが最後になります。初めて勉強会で発表したのが2013年のJAWS-UG三都物語でした。それ以来、何回か登壇の機会を頂いて、自分自身かなり勉強させて貰いました。三都で始まって三都で一旦区切りがついたので、感慨深いものがあります。
 もちろん、これからも関西のイベントには積極的に参加するつもりなので、これからもよろしくお願い致します。


See Also:
Amazon Elastic Load Balancing (ELB)の内部構造および拡張・障害時の動き


参照:
夏のJAWS-UG 三都物語 2014
[AWSマイスターシリーズ]Amazon Elastic Load Balancing (ELB)
[AWSマイスターシリーズ]Amazon CloudWatch & Auto Scaling
AWS-CloudDesignPattern

AWSで新タイプのインスタンス発表。バースト可能なマイクロインスタンスの後継機

f:id:dkfj:20140702220713p:plain


 どこぞの公式ブログっぽいタイトルになりましたが、AmazonのクラウドであるAWSの仮想サーバのec2に新タイプのインスタンスが追加されました。T2タイプです。その名の通り、t1.microの後継です。t1.microは、全インスタンスタイプの中で唯一CPUのバースト特性を持ったインスタンスです。バースト特性とは、短期的(十秒程度)に本来のCPU性能以上のリソースを利用できる機能です。サーバの用途として、普段のCPU使用率は10%以下でたまに跳ね上がるというものは割りと多いので、バースト特性は割りと面白いサービスです。しかし、t1.micorは、メモリが0.613GBです。21世紀になって14年という時を考えると、余りにストイック過ぎました。

T2シリーズとは



 そこで登場したのが、今回のT2シリーズです。ラインナップは、microだけでなくsmall,mediumもあります。当然、メモリも増量です。1GB,2GB,4GBと、それなりのミドルウェアをインストールできるレベルです。価格もm1,m3シリーズより安いです。以下、東京リージョンでの参考価格です。

名前 vCPUs ベースライン性能 RAM (GiB) 1時間あたりのCPUクレジット 1時間あたりの料金 Price / Month
t2.micro 1 10% 1.0 6 $$0.020 $14.60
t2.small 1 20% 2.0 12 $0.040 $29.20
t2.medium 2 40% 4.0 24 $0.080 $58.40

 ベースラインやCPUクレジットの考え方は、バースト特性に深く関わります。どれだけバースト期間が続き、性能がどれくらいでるのかということです。私自身も、まだ深く検証していなので、そのうち試してみたいです。

旧シリーズとの性能・コスト比較



 一般的な話をすると常にCPUの利用率が50%以上を上回っているような使い方をしている場合は、かなり効率的に利用できていると思います。Webサーバ用途などであれば、可用性のために冗長構成を基本とすると、割りと低いCPU利用率になることが多いのではないでしょうか。そんな際に、T2シリーズを利用するとコスト削減効果が高いと思います。参考のために、m1.smallとt2.small、m3.mediumとt2.mediumの対比を見てみましょう。

名前 比較対象 m*シリーズとのCPU m*シリーズとのメモリ比 m*シリーズとのコスト比
t2.micro t1.micro - 1.62倍 0.77倍
t2.small m1.small 1vCPU 1.18倍 0.66倍
t2.medium m3.small 1vCPU 1.07倍 0.79倍

 バースト特性をどう評価するか難しいところがありますが、m1.smallに対してt2.smallのコスト効果が高いことが解ります。

注意点



 t2インスタンスは、r3と同様にHVMタイプのAMIのみ利用できます。HVMは、Hardware Virtual Machineの略で日本語訳が完全仮想です。何に対して完全かというと、もうひとつの仮想化方式であるparavirtual(準仮想)です。旧来のAMIはparavirtual方式で作られていて、最近はHVM形式で提供されることが多いです。色々な所で、いつHVMベースに変えるか議論されていますが、そろそろ新規のインスタンスについてはHVMを使い、旧来のAMIも可能であればHVMに変更するという方向に舵を切ったほうがよさそうですね。

まとめ



 可能であれば、m1.smallはt2.smallに乗り換えた方が良いですよという話です。AMIのHVMからparavirtualへの再構築も、Chefのような仕組みを使っていれば簡単にできるんでしょうね。

参照:
Amazon Web Services ブログ: 【AWS発表】バースト可能な性能を持つ新しい低コストEC2インスタンス

周回遅れで、SSDベースの新しいAmazon EBSの話

 少し前ですが、AWSのサービスに重大なアップデートがありました。ストレージサービスであるEBSに新しいサービスラインナップが追加され、General PurposeというSSDベースのサービスが利用できるようになりました。すでにyoshidashingoさんが色々考察しているので改めてまとめる必要もないですが、自分の中の整理のためにまとめてみます。

EBSのラインナップと価格体系 2014/06~



 今回追加されたのは、General Purpose(gp2)です。従来のスタンダードEBSはMagneticという名前になり、Provisioned IOPSは、io1という略称になりました。


 東京リージョンで利用例

サービス名 ベースラインIOPS Max IOPS 価格体系
General Purpose (SSD) 3(IOPS)×GB 3,000(burst) $0.12 1 か月にプロビジョニングされたストレージ 1 GB あたり
Provisioned IOPS (SSD) 100~4,000の間で指定したIOPS 4,000 0.142 : 1 か月にプロビジョニングされたストレージ 1 GB あたり
0.114 : 1 か月にプロビジョニングされた IOPS あたり
Magnetic
旧スタンダードEBS
40~200IOPS ? $0.080 : 1 か月にプロビジョニングされたストレージ 1 GB あたり
$0.080 /100 万 I/O リクエスト

選択のポイント



 今回追加されたGeneral Purpose(gp2)を考える上で一番のポイントは、IOPSの性能が確保したEBSの容量×3IOPSとなっている点です。100GBの場合は、100×3で300IOPSです。EBSの最大サイズである1TBの場合は、1,000×3で3,000IOPSになります。これ以外にも、gp2にはバーストという考え方があります。例えば、gp2で100GBの場合は、300IOPSがベースラインになります。バーストは、短期的(最大30分)に3,000IOPSまで利用できる機能です。この2つの前提で、gp2とProvisioned IOPS(io1)のどちらを使えば良いのか、ケースごとに考えてみます。

ケース1 1,000IOPS利用したい場合
gp2 334GB以上を選択すると、ベースラインが1,000IOPS。金額は、月額$43.12。4,500円弱
io1 GB×$0.142+1,000(IOPS)×$0.114。334GBと仮定したら、金額はGB×$47.42+$114。15,000円超。
gp2の方がお得

ケース2 3,000IOPSを利用したい場合
gp2 1,000GBを選択すると、ベースラインが3,000IOPS。金額は、月額$120。12,000円強
io1 GB×$0.142+3,000(IOPS)×$0.114。1,000GBと仮定したら、金額は$142+GB+$342。50,000円弱。

結論



 io2がコスト的にメリットが出るケースは非常に少ないです。少ないストレージ容量で、高IOPSが必要なケースのみです。今後の価格改定にもよりますが、gp2を使った方が有利なケースが殆どです。何か価格設定が間違っているようで、非常に気になります。バーストについては、別途検証してみたいです。


See Also:
Amazon Elastic Load Balancing (ELB)の内部構造および拡張・障害時の動き
AWSのEBS Provisioned IOPSからEBSについて妄想する
結構知らないAmazon EBSの細かい話。主にEBSのネットワークの構造について


参照:
Amazon Web Services ブログ: 【AWS発表】新しいSSDベースのElastic Block Storage
料金 - Amazon Elastic Block Store (EBS ) EC2用ブロックストレージ | アマゾン ウェブ サービス(AWS 日本語)
Amazon EBSのGeneral Purpose(SSD)雑感→3000PIOPSの100GB(io1)より3000IOPS Infiniteの1000GB(gp2)のほうがおトク! - yoshidashingo

RubyでWebスクレイピングの話をしてきました。第1回Webスクレイピング勉強会@東京

 ちょっと間が空きましたが、第1回Webスクレイピング勉強会@東京に参加して、LT枠でRubyでWebスクレイピングの話をしてきました。



 今まで全く参加したことがないレイヤーの勉強会だったので、新しい発見があり非常に勉強になりました。スクレイピングのAPIであるkimonoimportioなど、全く知らないサービスに出会えました。私は趣味でスクレイピングをしているのですが、本職としてやっている方のノウハウや悩みどころを聞けて参考になりました。

 また、資料中に書いているのですが、現在Rubyでクローラーを作る本を書いています。一応全編書き終えてるので、夏頃に出ればなぁという状況です。そして、東京に異動することになりました。勉強会に参加しやすくなるので、色々な所に顔をだしてみたいと思っています。

 ちなみに第2回Webスクレイピング勉強会@東京にも登壇予定です。ブログやサイトから、ヘッダーやフッター、サイドバーなどを除いて本文だけ抽出するにはどうするのというテーマで、20分ほど話す予定です。


参照:
第1回Webスクレイピング勉強会@東京 (全3回) - Qiita
2014/06/22 第1回Webスクレイピング勉強会@東京 #東京スクラッパー - Togetterまとめ
第1回Webスクレイピング勉強会@東京に参加してきました - 夜はいよいよ冴えたのだ。

発表者資料
オープンデータのためのスクレイピング
Webスクレイピング勉強会@東京 オープニングトーク (第1版) #東京スクラッパー
ScrapyとPhantomJSを用いたスクレイピングDSL
Webスクレイピングの基礎知識 #東京スクラッパー
CasperJSを使って任意のWebサイトを電子書籍化する方法
渡る世間は自然言語ばかり #東京スクラッパー
オープンデータのためのスクレイピング

See Also:
オープンソースのRubyのWebクローラー"Anemone"を使ってみる - プログラマになりたい
Capybara-DSLのはなし - プログラマになりたい
複数並行可能なRubyのクローラー、「cosmicrawler」を試してみた - プログラマになりたい
開発用プロキシ、「CocProxy」が便利 - プログラマになりたい
iTunesのランキングを毎日自動で取得する その1 - プログラマになりたい
Rubyのtwitterライブラリで、Twitter Streaming APIが扱えるようになっていた - プログラマになりたい


Rubyによるクローラー開発技法

Rubyによるクローラー開発技法

Spidering hacks―ウェブ情報ラクラク取得テクニック101選

Spidering hacks―ウェブ情報ラクラク取得テクニック101選