2016-05-13

人生に必要なのは、鼻毛カッターではないだろうか？

　東京ビッグサイトに３日間出勤中です。りんかい線に乗るために座れないよと思ってたら、有楽町線で豊洲まで行けばいいことに気が付きました。そのお陰で得た時間で1つ有益な話をしましょう。それは、鼻毛カッター！

鼻毛カッター

　私が今まで買ったガジェットの中で、『想像以上に満足したもの』のベスト3に入るのが鼻毛カッターです。パナソニックは、少し気取ってエチケットカッターと言っていますが、日立の場合はズバリ鼻毛カッター。鼻にいれて5秒くらいバリバリしてると、綺麗サッパリ剃れます。掃除の為に中に溜まった毛をみると、ビックリするぐらい太いのや、細かい毛まで沢山入っていて爽快です。そんなことを半月に一度ほど楽しんでいます。そんなこんなでもう7年くらい使っています。

blog.takuros.net

鼻毛カッターと衝撃の開発秘話

　そもそも何故私が鼻毛カッターに興味を持ったのか。キッカケは、@naoya_itoさんの記事を見てです。
d.hatena.ne.jp

　そして最近紹介された開発秘話

電動鼻毛カッターの開発秘話に自分の鼻毛でドッグフーディングすると剃った毛がまた生えるまで数週間かかってテストできないと書いててゲラゲラ笑ってたんだけど、克服するため人工鼻毛を開発したところまで読み技術者としての自分を恥じました https://t.co/5rNyJVTM2Z
— Naoya Ito (@naoya_ito) March 23, 2016

twitter.com

　その衝撃の開発秘話です。これは是非よんで欲しいので、敢えて内容は紹介しません。ただ小見出しを見てください。世界のパナソニックのWebサイトでこんなに熱く面白い記事が読めるとは思いませんでした。

鼻毛はなぜ必要なのか。
鼻毛が出ていると仕事ができないと思われる？
鼻毛処理の研究に、人生をかける。
奥から生えている鼻毛も逃さない。
剃り味が良すぎてもダメ。
開発チームから鼻毛が消えた。
人工の鼻毛を開発。
安心して鼻毛を剃ってもらうために。
鼻毛カッターで、体中の毛を剃った。
鼻毛だけじゃない、耳毛も剃れる。
鼻毛の処理方法が間違っていると、化膿する可能性も。
鼻毛処理に掃除機の技術をプラス。
私と鼻毛は「切っても切れない関係」ですね。

　そして、最後の結論が秀逸すぎます

『鼻毛は、コミュニケーションを破壊する魔物。』

人工の鼻毛を開発してまで作った鼻毛カッター。納得の使用感です。

感想

　あなたの人生に、鼻毛カッターは必要ないですか？

パナソニックエチケットカッターグレー ER-GN50-H

出版社/メーカー: パナソニック(Panasonic)
メディア: ヘルスケア&ケア用品
購入: 39人クリック: 151回
この商品を含むブログ (24件) を見る

See Also:
替え刃もあるよ。Panasonicの鼻毛カッター

2016-05-10

Googleの狙う未来

　前回、Nexus 5Xを使ってみてgoogle恐ろしいと感じたというエントリーを書きました。

Nexus 5Xを使って垣間見たスマホの未来

Nexus5xというかAndroidを持ち始めての感想。Googleさん、恐ろしいね。登録してないのに自宅・職場を把握するのは無論のこと、隔週の定例で、出勤時間が違う日も把握してる。唐突に目黒の情報を出されて、その意味する事が解った時にビビった
— Takuro SASAKI (@dkfj) March 30, 2016

最近Publickeyさんを見てたら、GoogleのCEOであるサンダー・ピチャイのブログの翻訳を解りやすく解説した記事があり、いろいろと腑に落ちました。

www.publickey1.jp

スマホ普及後の世界

　スマホの普及率が6割を超えて、必要とする人にはほぼ行き渡っている状況です。次は、AppleWatchなどいわゆるウェアラブル・コンピュータと呼ばれるモノに広がろうとしています。ただし、根本的には一人の人間が同時に扱えるデバイスは１つしかありませんし、一人あたりに割り当てられた時間は１日２４時間しかありません。スマホ普及時は、電車や外出先など今までタッチできなかった隙間時間にインターネットができる（⇒広告を配信できる）という大きなアドバンテージがありました。その時間はスマホによって既に埋められたので、例えウェアラブル機器が普及しても、今後は機器間での時間の奪い合いにしかなりません。そしてGoogleの戦略としては、そこを全て抑えるという方向に進んでいるというのが、Googleのレターでよく解りません。
※上記の文脈でいうとメーカー等が、せいぜい60億か70億人という先が見えている人に対してではなく、桁が２つや３つ違うモノに対するインターネット（IoT）に関心がいくのは当然に帰結なのでしょうね。

感想

　この手の話を考えると、結局人の時間をどれだけ専有できるかになってきます。そして、それは広告の話に帰結します。雑な考え方すると広告費というパイを、普及数×占有時間で割っていくという図式です。最後は、広告モデルってどんなに強力なんだよと絶望して終わります。

See Also:
Nexus 5Xを使って垣間見たスマホの未来

Amazon Web Services クラウドネイティブ・アプリケーション開発技法一番大切な知識と技術が身につく (Informatics&IDEA)

posted with ヨメレバ

NRIネットコム株式会社,佐々木拓郎,佐藤瞬,石川修,高柳怜士,佐藤雄也,岸本勇貴 SBクリエイティブ 2016-04-20

Amazon

Kindle

楽天ブックス

2016-05-09

Node.jsのWebスクレイピングモジュール　『cheerio-httpcli』の使い方その１　cheerioでhtmlの要素指定

　少し間が空きましたが、cheerio-httpcliの使い方です。cheerio-httpcliは、HTMLパーサーであるcheerioに、文字コード変換のiconvを組み合わせたHTTPクライアントモジュールで取得したコンテンツの文字コードを良しなにUTF-8に変換してくれます。HTMLの解析＆取得自体はcheerioのラッパーなので、DOM指定でHTMLの要素を取得するといったことが簡単に出来ます。cheerioを上手い感じに補っているので、cheerio-httpcliはWebスクレイピングに最適なモジュールとなっています。

cheerioのDOMセレクト機能

　cheerio-httpcliを見る前に、生のcheerioの機能を見てみましょう。そこでまず、基本中の基本であるHTML中から任意のタグを指定して取得するDOMセレクトの機能です。この部分については、cheerioのGithubページにマニュアルがあるので、そちらを見ながらです。

cheerioの基本的な構文

　cheerioのDOMセレクターの基本的な構文は、以下のとおりです。

$( selector, [context], [root] )

selectorは、取得対象の指定。contextは、範囲指定。rootは、どのhtmlタグを親とするかです。何も指定しない場合は、通常htmlタグになるでしょう。selectorとcontextの関係が解りにくいので、実例をみてみましょう。

var html = (function() {/*
        <ul id="fruits">
          <li class="apple">Apple</li>
          <li class="orange">Orange</li>
          <li class="pear">Pear</li>
        </ul>
*/}).toString().match(/\/\*([^]*)\*\//)[1];

var cheerio = require('cheerio'),
    $ = cheerio.load(html);

console.log($('.apple', '#fruits').text());
//=> Apple

console.log($('ul .pear').attr('class'));
//=> pear

console.log($('li[class=orange]').html());
//=> Orange

　selectorについては解るのですが、contextについては直感的ではないような気がしますね。上記１番目の#fruitsを指定している例だと、id="fruits"のモノに限定して検索しています。一方で、2番めの例ではselectorでul .pearで指定して、.attrメソッドで、そのclassの属性を出力するようにしています。3つ目の例は、classがorangeのliタグを検索しています。個人的には3番目が一番直感的で使いやすいです。id指定であれば、ul[id=fruits]でいけますね。

　それでは、ulタグの中のliタグといった指定の仕方はどうするのでしょうか？悩んだのですが、下記のような書き方で指定できました。単純にスペースで区切れば良いのですね。

console.log($('ul li[class=orange]').text());
//=> Orange

属性表示＆操作用メソッド

　ここで、属性を表示する為のメソッドを確認してみましょう。
いろいろありますが、スクレイピング用途であれば.attr以外は使わなさそうですね。他に挙げるとしたら、.removeClass等で不要なクラスを一括削除して抽出しやすくするくらいだと思います。

メソッド	概要
.attr( name, value )	属性取得と設定メソッド。nameのみの場合は取得、設定したい場合はvalueを指定
.prop( name, value )	プロパティの取得と設定メソッド。（input checkbox等の）状態を取得したい場合はnameのみ指定。
.data( name, value )	data属性の取得と設定メソッド
.val( [value] )	input, select, and textarea属性用
.removeAttr( name )	属性削除
.hasClass( className )	クラスを持っているか true/false
.addClass( className )	クラスの追加
.removeClass( [className] )	クラスの削除
.toggleClass( className, [switch] )	条件に一致したクラスの追加or削除
.is( selector )
.is( element )
.is( selection )
.is( function(index) )

まとめ

　ざっとですが、cheerio-httpcliの核の1つであるcheerioによるhtmlの要素抽出の仕方が解りました。今回の一連の調査・実験は、AWS Lambda+Node.jsでどこまでクローラー／Webスクレイピングの実行基盤を作れるか試しています。今回のような基本的なスクレイピングに始まり、動的サイトや巡回型のクローラーを作ってみようと考えています。次は、cheerio-httpcliから実際のサイトの取得を試してみます。Lambdaとは何ぞやという人は、下記の本をよろしくお願い致します。数ヶ月遊び倒せるくらいサンプルを載せております。

Amazon Web Services クラウドネイティブ・アプリケーション開発技法一番大切な知識と技術が身につく (Informatics&IDEA)

posted with ヨメレバ

NRIネットコム株式会社,佐々木拓郎,佐藤瞬,石川修,高柳怜士,佐藤雄也,岸本勇貴 SBクリエイティブ 2016-04-20

Amazon

Kindle

楽天ブックス

シリーズ目次：
Node.jsでスクレイピングするならば
 AWS Lambdaでcheerio-httpcliを実行する
 Node.jsのWebスクレイピングモジュール　『cheerio-httpcli』の使い方その１　cheerioでhtmlの要素指定

参照：
GitHub - ktty1220/cheerio-httpcli: iconvによる文字コード変換とcheerioによるHTMLパースを組み込んだNode.js用HTTPクライアントモジュール
 GitHub - cheeriojs/cheerio: Fast, flexible, and lean implementation of core jQuery designed specifically for the server.

2016-05-05

Amazonプライム・フォト（cloud drive）で、写真のバックアップ。或いはAmazonプライムが凄い

　動物園のカバの方が、もう少し活発に動いているのではないかと思われるくらい、怠惰に過ごしているゴールデンウィークです。時間があるので色々とやろうとしているのですが、気がつけば寝てばかりという現実ありますよね。そんな中で唯一生産的なことをしたのが、自宅のMac miniに入れた写真の整理です。

ホームメディアサーバーとしてのMac mini

　以前紹介しましたが、我が家のMac miniはメディアサーバーとしての役割を果たしています。テレビやホームシアターシステムにつないで、音楽や映画を流すためです。が、AmazonプライムにプライムビデオやPrime Musicがついたことで、その役割はほぼFire TVに奪われました。

データの保管先としてのMac mini

　そんな状況で、残された役割はデータの保管先としてのMac miniです。iPhoneとNexusのバックアップ先として利用しています。以前は、プライベートの開発や収集したデータのバックアップ際にも利用していました。しかし、それらの殆どがクラウドもしくはサービス上に保存されている為、バックアップすべきデータとして重要なのは写真だけということに気が付きました。ということで、Mac miniにためられた写真の保管先の検討です。
　一部のデータは、AWS S3に保存されアーカイブ化されています。自動実行するように設定していなかったので、今回自動化しようとしました。が、考えてみると、S3上に置いた写真データは一度も見返したことがなかったです。また、Amazon Primeに入っていると、cloud driveの機能の一部としてAmazonプライム・フォトが容量無制限で使えます。ということで、Amazonプライム・フォトに鞍替えすることにしました。

Amazonプライム・フォトの設定

　Mac版を利用しましたが、設定は簡単です。インストーラーをダウンロードして、アプリインストール後にサインアップするだけです。そして、任意のファイルをアップロードします。

インストーラーからインストール。ダブルクリックするだけです。
f:id:dkfj:20160505123218p:plain

アカウントの設定。Amazonのアカウントです。
f:id:dkfj:20160505123227p:plain

アップロード対象の設定。好きなものを選びます。私は写真のみを対象としましした。
※スクリーンショットはサブのMabbook Airの設定時のものです。
f:id:dkfj:20160505123231p:plain

アップロードが開始したら、後は待つだけです。
f:id:dkfj:20160505123235p:plain

アップロード済みのものは、Webからも閲覧できます。
f:id:dkfj:20160505123222p:plain

Amazonプライムについて

　改めて最近のAmazonプライムの拡充っぷりは凄いと思います。ビデオと音楽が聴き放題で、写真の保存も無制限。月一冊まで、Kindle本も無料で読めます。特典が配送が速いだけだった時代に比べると、隔世の感があります。
　年会費3,980円でこのサービスは素直に凄いと思います。囲い込み完了したら、米国みたいに値上げするという話もありますが、その時はその時に損得を考えれば良いでしょう。

2016-05-05

AWSアプリ本の20%ポイント還元セールのお知らせ　『Amazon Web Services クラウドネイティブ・アプリケーション開発技法』

　4/20に発売されて、出だし好調の『Amazon Web Services クラウドネイティブ・アプリケーション開発技法』です。朝起きると、AmazonでKindle版が20%のポイント還元セールの対象となっていました。
　紙版の税込み価格は3,974円とかなり高い部類に入りますが、Kindleだと3,577円と10%オフで397円の割引された値段となっています。今だと更に20%ポイント還元なので、20%分の715ptが還元されます。紙版に較べて、実質的に1,112円分お得です。是非ご検討ください。

Kindle版のメリット

　紙の本に較べて、Kindle版は次のようなメリットがあります。

（物理的に）軽い
増刷・改訂時の修正がアップデートで手に入る

　1つ目のメリットとしては、物理的に軽いということです。紙版は鈍器のような本と言われることがあるくらい分厚いです。先日、配るために紙袋に4冊いれて歩いていました。他の荷物とあいまって、手が千切れるかというくらい重かったです。Kindleは、何冊いれても軽いです。
　2つ目のメリットとしては、増刷や改訂時に内容が修正された場合にKindle版であればアップデートすれば最新のものが手に入るということです。これは結構大きいと思います。増刷のタイミングはいつになるか解りませんが、可能なかぎり最新の状態で修正していこうと思います。変化の速い分野なので、これは嬉しいかもしれません。
※なお出版元のSBクリエイティブのWebサイトにも改定情報は掲載されます。

Kindle版の注意点

　現状提供している形式は、固定長フォーマットです。つまりPDFを画像として取り込んでいるものです。その為にサイズが大きく、何と140MBもあります。その為Kindle版は、物理的には軽いけど、論理的には重い本となっています。また、電子書籍のメリットである検索やハイライトができません。何とかして欲しいですね。。。

その他

　この本は、Amazon上のカテゴリではクラウドとWeb構築・管理に分類されています。現時点では、どちらのカテゴリでも1位です。出版社に聞いた所、このカテゴリ管理は完全にAmazonに管理されていて出版社の意向も反映されないようです。

f:id:dkfj:20160505112031p:plain

　モバイルプログラミングのカテゴリにも属して欲しいのですが、何か方法はないものでしょうか？Amazonの場合、機械学習のデータを重視しているので、モバイルプログラミングに属するホント一緒に購入された場合や、モバイルプログラミングカテゴリから検索で本書にたどり着く人が多ければ反映されるんじゃないかなぁと思っています。誰か知っている人いるでしょうか？

Amazon Web Services クラウドネイティブ・アプリケーション開発技法一番大切な知識と技術が身につく (Informatics&IDEA)

posted with ヨメレバ

NRIネットコム株式会社,佐々木拓郎,佐藤瞬,石川修,高柳怜士,佐藤雄也,岸本勇貴 SBクリエイティブ 2016-04-20

Amazon

Kindle

楽天ブックス

2016-04-27

Amazon AuroraとMariaDB Connector/Jの話

　今月創刊したクラウド専門誌の日経クラウドファースト。その特集の1つが、Amazon Auroraです。私も、その特集の執筆に協力させて頂きました。

itpro.nikkeibp.co.jp

　その中で、AuroraとMariaDB版のConnector/Jについて少し触れています。個人的にはMariaDB版のConnector/Jは、設計思想や実装面から将来性があり、かなり面白い製品と思っています。せっかくの機会なので、少し紹介します。

Auroraのクラスタ・エンドポイントとインスタンス・エンドポイント

　MariaDBのConnector/Jの話をする前に、まずAuroraに接続するためのエンドポイントの説明をします。Auroraには、クラスタ・エンドポイントとインスタンス・エンドポイントの2種類のエンドポイントを持っています。
　インスタンス・エンドポイントは、Auroraの各インスタンスに直接接続する為のエンドポイントです。立ち上げたインスタンスの数のぶんだけ、エンドポイントが作られます。これに対して、クラスタ・エンドポイントは、Auroraのマスターノードに接続する為のエンドポイントです。マスターノードのインスタンス・エンドポイントへのDNSのエイリアスになっていて、フェイルオーバーが発生すると、新しいマスターノードのインスタンス・エンドポイントへ切り替えられます。図示化すると、下記のような形になっています。

f:id:dkfj:20160427080205p:plain

　Auroraの呼び出し元としては、クラスタ・エンドポイントのみ記述しておけば良いという形となります。

MariaDB版Connector/Jの接続方法

　これに対して、MariaDB版Connector/Jは全く別のアプローチをしています。何とクラスタ・エンドポイントを一切利用せず、インスタンス・エンドポイントを全て登録するという形になっています。

f:id:dkfj:20160427080210p:plain

　そして、MariaDB Connector/Jの方で、どのインスタンスがマスターノードか把握して、そこにクエリーを投げるという形になっています。どうしてこのような構造になっているのかというと、高速なフェイルオーバーの為です。前述の通り、Auroraのクラスタ・エンドポイントの切り替えは、DNSを利用しています。そのTTLは5秒なので、障害検知後の切り替えは最低5秒は掛かります。それより短縮する為のアプローチなのです。
　ちなみに、MariaDB Connector/Jがマスターかスレイブか判断する方法としては、InnoDBのステータスを見ています。リードレプリカの方は、書き込み禁止のステータスがかえってくるのでそこを判断しているようです。

MariaDB版Connector/Jの可能性

　意外に単純な仕組みですが、これは結構面白いアーキテクチャです。現在は、フェイルオーバーの高速化のためだけの仕組みになっています。しかし、Connector/Jとしては、どれがマスターでどれがスレイブか把握できているということになります。そうであれば、Connector/J自身でクエリを判断して、更新系であればマスターに参照系であればリードレプリカにと振り分けが出来るはずです。リードレプリカへの振り分けは、アプリの実装含め悩みどころなので夢が広がりますね。

まとめ

　今回の特集の中で、MariaDB Connector/Jの話はごく一部です。これ以外にもAuroraのアーキテクチャ面の解説や耐障害性など、かなり濃い話をいろいろ書いています。Auroraを使う前に読んでおくと、結構理解が進んで良いと思います。
　ちなみに日経クラウドファーストの執筆陣は、cloudpackさんやサーバーワークスさん、クラスメソッドさん、TISさんにNRIとAWSのプレミアコンサルティングパートナーが揃っています。かなり濃いメンツで、企画のための会議にもかなりディープな情報が出てきています。ということで、興味がある人は日経クラウドファーストの購読を是非よろしくおねがいします。ついでに、Amazon Web Services クラウドネイティブ・アプリケーション開発技法もよろしくお願いします。

itpro.nikkeibp.co.jp

Amazon Web Services クラウドネイティブ・アプリケーション開発技法一番大切な知識と技術が身につく (Informatics&IDEA)

posted with ヨメレバ

NRIネットコム株式会社,佐々木拓郎,佐藤瞬,石川修,高柳怜士,佐藤雄也,岸本勇貴 SBクリエイティブ 2016-04-20

Amazon

Kindle

楽天ブックス

Amazon Web Services パターン別構築・運用ガイド

posted with ヨメレバ

NRIネットコム株式会社,佐々木拓郎,林晋一郎,小西秀和,佐藤瞬 SBクリエイティブ 2015-03-25

Amazon

Kindle

楽天ブックス

2016-04-26

AWSのストレージよもやま話 s3,ebsからStorage Gateway,EMRFSまで

　昨日、VPCの話を書いていて思い浮かんだのがストレージの話です。AWSのストレージといえば、S3とEBSが中心です。しかし、オンプレからの移行ではNAS相当のものがなくて、先人たちは色々と試行錯誤してきました。また、製品群を見返すとAWS自身も相当いろいろ検討して苦労したのだなと解ります。という訳で、何の役に立たないAWSのストレージの四方山話です。

s3fs

　事実上無限の容量を持つS3をファイルシステムとして扱えるs3fs。誰しも一度は夢をみて、夢敗れるファイルシステムではないでしょうか。これは純正のライブラリではなく、サードパーティ製です。構造としては下記の通りで、問題点としてはメタデータ（ファイル一覧や個々のファイルの日付・サイズ等の情報）を持たない点です。よって使い方によっては、かなり遅いです。また初期のものはメモリーリークとか多く、定期的な再起動が必要だったりします。

f:id:dkfj:20160426080823p:plain

みんな薄々と気が付いていると思いますが、s3fsが悪いのではないです。s3fsに夢を見過ぎた我々が悪いのです。

Storage Gateway

　最近では、EBS自体が16TBまで作れるので、EBS単体で大容量ファイルサーバの構築も簡単になっています。昔は1TBまでだったので、仮想ボリュームとして束ねたり、Storage Gatewayの利用を検討したものです。Storage Gatewayは、S3をストレージ・ボリュームとして扱えるもので、当初はオンプレからクラウドへバックアップする際に利用することが多かったです。Storage Gatewayは幾つかタイプがあって、Gateway-Cached Volumeは、EBS上にキャッシュがなければStorage Gateway経由でS3に取りに行くという構造になっています。そこに夢を見たのですよ。

f:id:dkfj:20160426080846p:plain

　個人的には、アーキテクチャとして中々良いのではと思っています。ただ1つ残念なのがというか、致命的だったのがメタ情報自体もStorage Gateway側（S3）に持っている為に、キャッシュに載っていなくて大量ファイルがあるようなディレクトリを参照した日には待てど暮らせど応答が返ってこないということになります。
　今だとEBSの容量が大きくなったので、Cached volumeではなくゲートウェイ保管型の方でも良いような気もしてきています。最近は、あまり触ることもなくなりましたが、地味に色々な所で活躍していると思います。

EMRFS（Elastic MapReduce FileSystem）

　EMRFSは、その名の通りEMR（Elastic MapReduce）用のファイル・システム。S3を束ねてファイルシステムとして利用できる。メタ情報は、S3ではなくDynamoDBに保存するのがポイントになっている。Consistent Viewとして整合性のあるビューを提供されます。

f:id:dkfj:20160426080850p:plain

　これをサービスとして出したらいいのじゃないのと思う人は多いでしょう。ただ、EMRで利用すること前提で、知名度低いです。

EFS（Elastic File System）

　AWSのNASタイプのファイルサービスとして鳴り物入りで登場したのがEFSです。恐らく全てのAWSユーザが待ち望んでいたサービスではないでしょうか。S3のように従量課金制で、容量も拡張型です。複数のインスタンスからマウントできます。

f:id:dkfj:20160426080840p:plain

　しかし、待てど暮らせど状態がプレビューから変わりません。また、アーキテクチャが全然公開されず実体は謎のままです。このサービスは我々の願望が生み出した夢で、現実には発表されていないのではとたまに疑っています。

まとめ

　ちょっと解説が大変なので省略しますが、これ以外にもRDS for Auroraで使われているQuorum型のストレージがあります。ストレージは設計の肝になることが多いので、よく考えてみましょう。個人的な結論としては、アプリを改修してS3ベースに出来るのが一番幸せです。なかなかそう出来ないのが、現実なんですよね。
　最近だしたAmazon Web Services クラウドネイティブ・アプリケーション開発技法には、EC2やEBSに頼らないシステムの構築方法を紹介しています。ぜひ御覧ください。