外でMacとiPhoneでなかなかテザリングがつながらない。
よくあるのが、実は裏でWi2とかに接続されているのに、メニューバーではWifiに接続されていないように見えていたりする。
WifiのOff ,Onを行っても、結局裏でwi2等に繋がってしまっている為、なんかうまくいかない。
そんな時には
SystemUIServerを再起動する事で解決することがよくある。
再起動の方法は
ps -ax |grep /SystemUIServer | perl -pe "s/^\s*(\d+).*/\1/g" |head -n 1 |xargs kill
これをファイルとして保存しておいてSpotLightから呼び出すと結構楽
ついに今まで謎にされてきたSORACOMのサービスが明らかになりました。
今までIoTのサービスだということだけを聞いていましたが、それ以外のことは一切謎に包まれていました。
ラッキーなことに事前に使わせて貰っていたので、公開しても良い9/29が過ぎた今日このブログを公開します。
SORACOMのサービスは簡単にいうと、IoTのための世界で一番柔軟な通信回線を提供するというサービスだと思ってます。
そんなSORACOMに対して一番興味を惹かれたのはこの一枚のスライドです。
提供：SORACOM
正直AWSでIoTということで、L4以上のレイヤーを想定していたので、まさかL2で!?というのには胸が熱くなります。
柔軟な通信環境と通信料金を設定出来るようになっている事がビジネスの肝になっていそうで、これは今までの通信の世界では破壊的で、CTOの安川さんらしいなという感じがしました。
ちなみに料金プランを見てみると
https://soracom.jp/services/air/price/soracom.jp
料金を見るとUPの方が安い事がわかります。
SIMフリーのスマホとかタブレットにさして使うとかも考えられますがそういった使い方であれば、正直IIJmioの方が安いと思います。
IoTのための通信回線というのがここの料金からも読み取れますね。
アップロードは安いのでセンサーなどのデータのアップロードや、カメラの映像を飛ばすとかであれば非常にありがたいことになります。
料金プランもs1.とかあるので、
たぶんそのうち、アップロードだけ早いu1.とかダウンロードだけが早いd1.とか出てくるのでしょう。
スピードテスト(
SORACOM Airのスピードテストをしてみた。 ｜ DevelopersIO
)とか、使い勝手とか、APIの話とか、UIの話しは別の人が多分書いてくれるので今回はおいておいて、今回はそのネットワーク周りを探っていきたいと思います。
まずはSIMをさして、自分のIPアドレスを確認するとどうなっているのかを確認してみます。
今回いろいろと検証に利用したのはこの端末
まずは単純にipconfigの値を
モバイル ブロードバンド アダプター モバイル ブロードバンド:
接続固有の DNS サフィックス . . . . .: リンクローカル IPv6 アドレス. . . . .: fe80::ad68:fe85:f4cc:20c3%11 IPv4 アドレス . . . . . . . . . . . .: 10.173.101.69 サブネット マスク . . . . . . . . . .: 255.255.255.0 デフォルト ゲートウェイ . . . . . . .: 10.173.101.1
SIM経由でふられたIPアドレスは10.173.101.69/24というプライベートIPアドレスが振られました。
ここでふと思った事が二つ。
1つ目はプライベートIPだという事です。
もう一つは /24？ということでした。
とは言え、L2でAWSまで接続されているので、マスクは端末が適当に設定していて、正直どうでも良いことなのでしょう。
それかもしかしたら、接続するごとにネットワークアドレスが変わるんじゃないかという事で試してみました。
2回目、10.173.101.69
3回目、10.173.101.69
4回目、10.173.101.69
5回目、10.173.101.69
何回やってもアドレスが変わらないので、楽しくなってきました。
次に速度を変えてみます。
s1.standardだった所からs1.fastに変えてみます。そして切断、接続を繰り返してみます。
やはり変わりません。
次はステータスを休止にして開始にし直してみます。
ちなみに休止のステータスにした途端にネットワークは切られました。素晴らしい速さです。
休止から使用開始とまたステータスを変更しましたが、ここでもIPアドレスが変更されませんでした。
もしかしたら、MSISDN、IMSI当たりとIPアドレスを紐付けているのかもしれません。
そうなると、SORACOM AirのSIMはたった16,581,375枚しか発行出来ない事になってしまいます。
良い風に捉えると、SORACOM AirのIPアドレスが固定されるという事であれば、SORACOM Air同士の通信が出来るんじゃないかなんていう夢も広がります。蟻です。蟻のネットワークが作れます。
しかし、もしIPアドレスが固定されているのであれば、consoleや、APIでそれが見れるようになっていてもおかしくないはずです。
ここはただアドレスを割り振ったキャッシュが数時間残っているというのが一番可能性として高そうです。
(きっと、APIでSIMに対してなにか送信できるサービスができてくるに1票 SORACOM controlみたいな)
参考までに：IIJmio
接続固有の DNS サフィックス . . . . .:
IPv6 アドレス . . . . . . . . . . . .: 2001:240:2401:9bfa:ad68:fe85:f4cc:20c3
一時 IPv6 アドレス. . . . . . . . . .: 2001:240:2401:9bfa:1847:8bce:a8b8:2a30
リンクローカル IPv6 アドレス. . . . .: fe80::7:3a43:1401%11
リンクローカル IPv6 アドレス. . . . .: fe80::ad68:fe85:f4cc:20c3%11
IPv4 アドレス . . . . . . . . . . . .: 100.92.169.196
サブネット マスク . . . . . . . . . .: 255.255.255.0
デフォルト ゲートウェイ . . . . . . .: fe80::7:3a43:1402%11
fe80::7:3a43:1440%11
100.92.169.1
次にこのSIMからインターネットにアクセスした時のGlobal IPをしらべてみます。
What Is My IP Address - Online Privacy and Safety Experts
141.0.9.62
でした。
このIPアドレスを
$ dig -x 141.0.9.62 〜略〜 62.9.0.141.in-addr.arpa. 79173 IN PTR s20-16.opera-mini.net.
まさかのここでOperaTurbo
次にこのSIMからインターネットにアクセスした時のGlobal IPをしらべてみます。
What Is My IP Address - Online Privacy and Safety Experts
54.65.46.149
でした。
このIPアドレスを
$ dig -x 54.65.46.149 〜略〜 149.46.65.54.in-addr.arpa. 300 IN PTR ec2-54-65-46-149.ap-northeast-1.compute.amazonaws.com.
EC2の東京リージョンのIPアドレスがアクセス元のGlobal IP として出てきました。
一安心です。
AWSのIPアドレスからBANするのが好きなサイトとして有名なiTownpageも見てみましたが、無事に見れました。(OperaTurboもOff)
続いてTracerouteで、どのようなネットワーク経路を通ってインターネットに接続されていくのかを見ていきます。
PS C:\Users\ope> tracert google.com google.com [173.194.126.227] へのルートをトレースしています 経由するホップ数は最大 30 です: 1 502 ms 454 ms 556 ms ec2-175-41-192-130.ap-northeast-1.compute.amazonaws.com [175.41.192.130] 2 308 ms 231 ms 125 ms 27.0.0.154 3 608 ms 530 ms 623 ms 27.0.0.136 4 241 ms 294 ms 423 ms 15169.tyo.equinix.com [203.190.230.31] 5 582 ms * 579 ms 72.14.236.82 6 426 ms 570 ms 585 ms 72.14.232.109 7 550 ms 387 ms 546 ms nrt04s08-in-f3.1e100.net [173.194.126.227]
1hop目からいきなりEC2きました。AWSまでL2で来ている事が確認出来ました。
その次のHOPも見てみましたが、
http://www.speedguide.net/ip/27.0.0.154
http://www.speedguide.net/ip/27.0.0.136
http://www.speedguide.net/ip/203.190.230.31
http://www.speedguide.net/ip/72.14.236.82
。
このTracerouteを何回か取ってみることにことにしました。
$ tracert -h 1 amazon.co.jp 1 559 ms 612 ms 697 ms ec2-175-41-192-230.ap-northeast-1.compute.amazonaws.com [175.41.192.230]
$ tracert -h 1 hatena.ne.jp 1 559 ms 612 ms 697 ms ec2-175-41-192-232.ap-northeast-1.compute.amazonaws.com [175.41.192.232]
$ tracert -h 1 www.soracom.jp 1 559 ms 612 ms 697 ms ec2-175-41-192-234.ap-northeast-1.compute.amazonaws.com [175.41.192.234]
なんかコンプリートしたくなってきました。
$ tracert -h 1 google.com 1 559 ms 612 ms 697 ms ec2-175-41-192-236.ap-northeast-1.compute.amazonaws.com [175.41.192.236]
色々なドメインに対してのtracerouteを試してみましたが、今ここを書いている時点では第4オクテットが230,232,234,236が出てきました。
tracerouteの先がs3-website.****の時には少し変わって、12とか20、130が出てきました。
1 498 ms 467 ms 629 ms ec2-175-41-192-12.ap-northeast-1.compute.amazonaws.com [175.41.192.12] 1 35 ms 44 ms 56 ms ec2-175-41-192-130.ap-northeast-1.compute.amazonaws.com [175.41.192.130]
$ 1 559 ms 612 ms 697 ms ec2-175-41-192-20.ap-northeast-1.compute.amazonaws.com [175.41.192.20]
とはいえ、ドメイン200個程試してみましたが、この7個しか見つける事しか出来ませんでした。
今回はSORACOM Airについて色々といじってみましたが、私としては手元にAWSのIPアドレスを引き込める事に非常に魅力を感じました。
さらにSORACOM Beamという別サービスとしてL3以上で付加価値をつけるというのも非常に興味津津です。最近はレイヤーの高い技術ばかりだったので、久しぶりのL3以下の技術にふれられて今日は興奮で寝れないかもしれません。
昨日ははてなのCTO 田中さんでした。
blog.stanaka.org
明日以降もSORACOM リリース記念リレーブログは続きます。
blog.soracom.jp
前回マナカナの画像をBingAPIを使って収集しましたが、
今回はマナカナの画像から、顔だけを切り出して行きます
顔の切り出しをするには、顔の位置を特定してとか色々必要層ですが、
今回はまとめてProjectOxfordのFaceAPIを使います。
Microsoft Project Oxford Face APIs
使うためにはAzureのPortalからMarketplace
FaceAPI
後は必要そうな情報をいれて数クリックで使えるようになりました。
Sign Upが完了したら
https://dev.projectoxford.ai/Developer
にアクセスして、Keyを取得します
Keyが取得出来たら後は使うだけで、顔の切り出しが出来るようになります。
カレントディレクトリに写真があるとして、
以下のスクリプトを実行です。
（実行にはjqとimagemagickが必要です）
APIKeyにはFaceAPIのKeyが入ります。PrimaryでもSecondaryでも良いと思います。
#!/bin/bash IFS=' ' APIKey=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX [ -d face ] && mkdir face for f in $(find ./ -type f); do curl -X POST -H "Content-Type: application/octet-stream" --data-binary @${f} \ "https://api.projectoxford.ai/face/v0/detections?subscription-key=${APIKey}" \ | jq '.[].faceRectangle | "\(.width)x\(.height)+\(.left)+\(.top)"' | xargs -I{} convert -crop {} ${f} face/$(uuidgen)-{}-${f##*/}; done
face/というディレクトリに顔の部分だけを切り出した画像が出来上がって来ます。
なんだか、明らかにマナでもカナでも無い人がいる。。。
機械学習をやっていると、どうしても、マナカナの画像を集めないといけない時があります。
マナカナの画像を効率的に集めるために、BingのSearch APIを使って画像のURLを取得し、
ダウンロードするようにします。
Bing Search API | Microsoft Azure Marketplace
月間5000トランザクションであれば、無料で使えるので、これをつかいます。
5000トランザクションもあれば十分だと思うので、右側にある、0円のものにサインアップします。
次の画面で、「前述の公開元のオファー条件とプライバシーポリシーを読み、内容に同意しました。」
のチェックを入れて、サインアップを押せばサインアップは完了です。
(microsoftのアカウントを持っている事が前提です。)
サインアップが完了したら、
サービス エクスプローラー | Microsoft Azure Marketplaceを開きます。
ここで
「プライマリ アカウント キー 表示する」の”表示する”をクリックすると、APIのキーが表示されるので、それをとっておきます。
APIキーが手に入ったら、実際に画像を収集します。
画像の収集は下のシェルスクリプトで、行います。
$ cat image_download.sh #!/bin/bash # 検索ワード SEARCHWORD="マナカナ" # Bing API のAPIKey APIKEY="*************************************************" #=================================== #=================================== [ -d images ] || mkdir images QUOTEDKEY=$(echo $APIKEY | nkf -wMQ| tr = %) UA="Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36" QUERY=$(echo "'${SEARCHWORD}'"| nkf -wMQ | tr = %) URL="https://${QUOTEDKEY}:${QUOTEDKEY}@api.datamarket.azure.com/Bing/Search/v1/Image?Query=$QUERY&Market=%27ja-JP%27&\$format=json" for i in ` seq 1 15 10000 ` do curl --basic $URL'&$top=15&$skip='$i | jq . | grep MediaUrl |grep -v bing |perl -pe "s/.*: \"(.*?)\".*/\1/g" |xargs -P 15 wget -T 5 -U "$UA" -N --random-wait -P ./images done
$ ./image_download.sh
これで、imagesというディレクトリの中にマナカナの画像が集まってきます。
次は顔を切り出す
blog.tottokug.com
Hoster (RedWinder::MacApp::Hoster) がYosemiteになってInstallできなくなった。
できなくなった原因は、
Contents/distribution.dist
に書かれているVersionチェックの問題。
10.10.x に対して >= '10.4'となっているので、10.10 は10.1扱いで、インストール出来なくなっている。
というわけで、
Contents/distribution.distの7行目のVersionチェックを正規表現でのものに書き換えてあげれば、Yosemiteでも無事にインストール出来る。
- if(!(my.target.systemVersion.ProductVersion >= '10.4')) {
+ if((my.target.systemVersion.ProductVersion+'').match(/10.[1-3]\./)) {
あけましておめでとうございます。
タイトルの通りなのですが私のやっていた会社、株式会社マイニングブラウニーは2015年1月1日から株式会社オークファンの100％子会社となりました。
自分の作った会社だったので、退職とはちょっと違いますが、一つの区切りとして、書いておきたいと思いました。
とりあえず恒例のほしい物リストを
http://www.amazon.co.jp/gp/registry/wishlist/3AYKVKHE1C52X
資金調達を考えて、証券会社の人とお話をしたら、その数分後にオークファンの武永社長から情報交換でもどうですか？というお話が直接ありました。
証券会社の仕事が早すぎるなと思っていたら、本当に偶然声をかけてくれたようです。
今後3年間で私がやりたい事をお話し、オークファンの今後やっていこうとしていることをお聞きしました。
その中で、やろうとしていることが非常に重なっている部分が多く少しワクワクしたのを覚えています。
それからの数ヶ月間は色々悩みながらも、何人かのオークファンのメンバーともお話していく中で徐々に期待に変わっていきました。
株式会社マイニングブラウニーという会社は前身の米国法人も含めると9年3ヶ月やっていたわけですが、
その間データをいかに有効に使っていくのかというのを考えてきました。
考えた中で、自分の中でしっくりきた考えかたとして、幾つかのフェーズによって分類し、キチンと回転させる事が大切だと考えてました。
この円はデータの活用において必要なフェーズを6つに分けたものです。
今までデータを扱うのに指標がなかったため、ビッグデータという言葉がひとり歩きし、
うまく活用できていない企業を見てきました。
データがなかったり、整理できていなかったり、分析できていなかったり。
そんな中、2014年にはビッグデータが幻滅期に入り、やっと過度な期待がなくなり正当な評価をしだしたと感じ始めました。
先進テクノロジのハイプ・サイクル： 2014年
出典: ガートナー (2014年8月)
2015年にはこのチャンスを活かしたいと思っていました。
そこで資金調達を考えはじめたのです。
ここで冒頭の証券会社との話になります。
ビッグデータへの幻滅と同じくして、IoTが騒がれるようになってきました。
正直なところ私はそんなにIoTには興味がないのですが、IoTによってビッグデータが早期に幻滅期を抜ける可能性があることに期待しています。
それはIoTによって莫大な量のデータが手に入るようになり、機械的に処理する必要が出てくる事になってくるそんな時代が見えたからです。
今後3年間で可視化、活用する部分を強化していくことも考えましたが、その場合どうしてもスピード感が足りないと感じていました。
であれば、分析の部分にリソースを集中しようと。
そこでデータの分析について調べ、考えました。
今の段階では、私は
この4段階に分けたいと思います。
今後、ルールを決めるとかそういったことが分析の中に組み込まれていくような気がします。
先ほどの6つのフェーズでいうと、分析というよりもどちらかと言うと整理と可視化に近いです。
いわゆるBIと呼ばれる領域では、この過去に起こったことの理由を探るのに、
人間の外部知識が必要だったりします。
これを機械がやろうとすると、途端に難しくなります。
レジのデータだけでなく、別のデータが必要になってくる可能性もあります。
例えば、クレジットカードを利用した時に、その利用が不正なのか、不正ではないのか
そういったことを検知してこそのMonitoringです。
リアルタイムで人間が見ることを求めていません。リアルタイムで、機械が判断することを求めます。
ここに来ると、確実に機械学習が必要になります。
ちなみに、オークファンの考えるデータの活用に関しての図はプレスリリースに載っている画像の通りで、
の４つに分類しています。
これを先ほどの６つのフェーズに重ねると以下の図のようになります。
そして、オークファンは既にaucfanや、valuefanといったPresentationを展開しています。
また、Solutionについても、力をいれています。
マイニングブラウニーは創業時から要素技術でやっていくと決めていたので、DataとInfomationをサービスとして展開しています。
私はオークファンでDataとInfomationの部分を担当します。
今回の子会社化により、4つの領域すべてに力を入れられることになります。
この4つの領域が噛み合ってビジネスを展開出来る今、数年後が楽しみで仕方ありません。
これからもオークファンとしての私もよろしくお願い致します。
この投稿は クローラー／スクレイピング Advent Calendar 2014の12月23日用です。
まずはこの画像を御覧ください。
図1 各国のECサイトの画像
Eコマースのサイトで、商品の詳細のページを見るだけですぐに商品名、価格を判断出来ましたよね？
それが英語のサイトでも中国語のサイトでも、韓国語のページでも分かりましたよね？
凄いですね。
もしこの能力をコンピュータに移植できたら凄いことですね。
もし、先ほどの画像を身の回りのインターネットに一番疎い人に見せてみて下さい。
きちんとスクレイピング出来たでしょうか？
おそらく出来なかった事が多いのではないかと思います。
こんな事させて何させたいかと、人間のスクレイピング能力は生まれつき持っているものではなく、なんらかの学習のプロセスを経て手に入れたものだということです。
それも、人生における経験ではなく、インターネットに関する経験です。
この経験をもしコンピュータで実現出来たら、スクレイピングの自動化に近づくはずです。
例えば、Eコマース 100サイトから価格情報を収集したいとします。
その場合、100サイト分のスクレイピング用のコードを用意しなくてはいけません。
抽象化したところで、100サイト分の何かしらが必要になります。
これが決まった100サイトとわかっていれば、頑張れるかもしれません。
しかし、100サイトから増減していった時、ずっと対処し続けないといけません。
運用のコストばかり上がってしまい、疲弊していく事は目に見えてます。
この状況を打破するために、人間と同じような成長をし見分ける能力をコンピュータ上に作りたいと思いました。
人間がなぜスクレイピング出来るのかを真剣に考えました。
人間がスクレイピングしている時はどのように判断していくのか仮説を立てました。
この4つから判断しているだろうと考え、この4つを学習させるすべを考えます。
しかし、これには問題があります。
画像2 レコメンドなどで複数の商品が同じページ内に載っている場合
このような場合、複数の抽出すべき項目があり、悩ましいです。
そこで、HTMLを分割することにします。
図3 全体のDOMツリーから、必要部分の抽出
では、これをどのように実装していくかという話になります。
大きくは、
の3つの工程になります。
サイトの性質毎に特定の言葉(ECであれば税込や送料など)の存在に応じて、
全てのタグに点数をつけていきます。点数の付け方は、そこに含まれる単語とタグの深さを計算してつけていきます。
点数をタグの開いた順番に並べ、微分していきます。
微分した値にしきい値を設け、ブロックを構成する部品としてフラグを立てて置きます。
可視化すると先ほどの図2のようなページの場合は以下のようになります。
青がタグの深さ、緑がタグに付けられたスコア、ピンク色がフラグです。
可視化するとこんな感じになります。
図4 タグのスコアリング
真ん中よりも少し左側にフラグが幾つか立っている所があります。
ここがメインの商品の情報になっています。
そして、真ん中から右側に周期的にフラグが現れている所がありますが、これがレコメンドによって表示されている商品です。
次はこれをブロックとしてまとめ上げる工程に入ります。
ここから先はHTMLをツリー構造と見た解析になっていくので、タグの事をノードと呼んで行きます。
バラバラと存在しているフラグ付されたノードをまとめる作業になるのですが、
親のノードからみて、子孫たちがどの程度フラグが立っているかというのを見ていきます。
もし、自ノードの配下のノードでフラグ付されているノードの数が多い場合は自分自身がフラグ付されて行きます。
この工程を何度か繰り返す事によって、ブロックを抜出します。
以下の図で説明すると、まずはピンク色がフラグ付されたノードになります。
フラグ付されたノードが子供の中に割合多くいた場合自分自身がフラグ付されるというルールに基づき、再度フラグ付されます（赤いノード）
全く同じルールにもとづいてルートノードから辿って行くことで、今度は青いノードが生まれます。
図5 フラグから必要最小の範囲の決定
このような工程を何度か繰り替えす事によって、抽出すべきブロックが導きだされます。
この工程は複数回やっても、あるところに集約されますが、だいたい一般的なHTMLの深さであれば、5回もやれば十分集約されます。
これでブロックが抽出出来ました。
ここに機械学習的なアプローチを使っていきます。
この処理に入る段階で既に、ブロックとなっているため、ページ全体のノードの数に比べだいぶ少なくなっています。
だいたい20〜50位のノード位になっています。
これらのノードそれぞれで取得したい項目、例えば"商品名"や"価格"などに対してのそれぞれの尤度を求めて行きます。
下の図の青いノードが商品名かどうかを調べる場合を考えてみます。
青いノードの自己主張だけでは、怪しいので、ピンクのノードの意見も取り入れます。
ピンクのノードは青のノードの位置関係と、含まれる単語、タグ名、アトリビュートから青いノードが商品名のノードであるかどうかを主張します。
図6 ノードが商品名らしいかの投票
ピンクのノードが満場一致で、この青いノードが商品名ですというのであれば良いのですが、そんな事はありません。
なので、ピンクのノードのみんなの意見を集約して、青いノードが商品名だと判断をしていきます。
こんな判断を全てのノードに対して行い、得票数が一番多いノード、かつ閾値を超えているものを商品名として判断します。
しかしこれだけだとピンクのノード全てが同じ重みで判断されてしまいますが、そんなことはないはずです。
なので、各タグに対しての重みの係数を与える事にします。
そして、この係数の調整は、遺伝的アルゴリズムを使って自動的に調整されるようにします。
この仕組によって、ノードが商品名であるのかどうかを判断し、抽出します。
スクレイピングの自動化が出来ました。
そして、サービスとしても提供しています。 hanamgri
しかし、β版リリースから数年たっても未だにβになっています。というのも、今は教師付きの学習が必要ですぐに使えるようなものではないからです。
今後Deep Learningでの特徴の発見が自動的に出来るようになれば、ユーザによる事前の学習を必要とせずに利用できると考えています。
ちょっと小難しい話になってしまいましたが、スクレイピングを機械にやらせようと思い、考えた仕組みの紹介でした。
