Google ChromeのPPAPI版FlashPlayerではRefererの値がほかのと違う

FlashのプログラムからURLRequestなどを使って外部のリソースにアクセスするとき、Google ChromeのFlash Playerでは、PPAPI版とNPAPI版で、HTTPリクエストのRefererに設定される値が異なるようです。

• NPAPI版…Flashのswfファイルのパスが設定される。

• PPAPI版…アドレスバーに表示されているURLが設定されるっぽい。

検証用のソースとか環境とかは後日追記します。

Windowsでファイルのハッシュ値を調べるには

インターネットでプログラムファイルなどをダウンロードするとき、そのファイルのMD5やSHA1のハッシュ値が掲載されていることがありますが、そもそもダウンロードしたファイルのハッシュ値ってどうやって計算するのかと思って調べたところ、MicrosoftがFCIV(File Checksum Integrity Verifier)というツールを公開していました。

ツールのダウンロードはこちらからできます。
http://support.microsoft.com/kb/841290/ja

ダウンロードしたEXEファイルを実行すると、規約の同意に続いて、インストール先のフォルダを尋ねられるので、適当なフォルダを指定してOKをクリックすると、インストールが完了します。

使用するには、コマンドプロンプト上で、インストールしたフォルダの中にあるfciv.exeを実行します。
次の例は、ファイルのMD5のハッシュ値を出力します。

C:\work>c:\FCIV\fciv.exe -md5 test.py
//
// File Checksum Integrity Verifier version 2.05.
//
dda08d65cc1d27b8a266258dc42a65f4 test.py

SHA1の場合は、オプションを-md5ではなく-sha1にします。

C:\work>c:\FCIV\fciv.exe -sha1 test.py
//
// File Checksum Integrity Verifier version 2.05.
//
f5dc4c19ccabeb9df713f8132a02911a0257444e test.py

オプションを-bothにすると、MD5とSHA1の両方出せるようです。

G空間EXPOの2日目に行ってきた

昨日からG空間EXPOが開かれていますが、今日は、日本地図学会の「進化するタブレット地図」というシンポジウムを聴講してきました。

私自身も、先日アメリカのワシントンに出張に行ったときに、10インチのタブレット端末を持って行ったのですが、観光地やレストランを探したり、そこまでのナビとして、Google Mapsが大活躍しました。
そんなこともあり、これからのタブレット地図はどのようになっていくのか、というところに興味を持って聴いてみました。

私なりに面白いなと思った点をまとめてみます。

• タブレット用の地図アプリは数多く出てきている。
• Google Mapsなどもあるが、特定目的（牛丼屋を探す、など）のアプリも多く存在する。
• これからの地図は、次の方向に進化しそう。
• 双方向性（利用者自身が地図を作る）
• ユビキタス性（いつでもどこでもパーソナライズされた地図を作れる）
• 利用者同士のコラボレーション（SNSとの連携も？）
• 地図のインフラはできてきた。
• 地図データや属性データの提供
• システムインフラまわりが課題になりそう。地図の専門家にはシステムに詳しくない人が多いため、システム屋との協調が重要になるかも。

地図としてのインフラはできてきたが、システムインフラまわりが課題だ、という点は、先日のFOSS4Gで聴いた流れと重なるような気がします。
私のようなシステム屋は、地図アプリを支えるインフラ部分で、地図の進化のお手伝いをできるのかもしれません。

FOSS4G Tokyo 2013 の１日目に行ってきた

FOSS4Gのイベントに行ってきました。

イベントの詳細はこちら。

モチベーションとしては、ここ最近（特に今年に入って）GISの仕事をするようになって、QGISをはじめFOSS4Gのツールにお世話になることがあり、情報収集の目的で参加しました。

ここまで完成度の高いアプリを無料で提供するってほんとにすごいです。今後の発展にも期待です。

 

聴いてきた話の内容を私なりにまとめます。

----

基調講演

• 電子国土Webが「地理院地図」という名前で公開された。
• タイル画像（「地理院タイル」）が使いやすくなった。
• 「国土地理院」または「地理院」の表示だけで使える（申請不要）。
• ディレクトリ構造が単純になった。

 

MapWinGIS

• MapWindowのエンジン部分に使われている。
• MPLライセンス。
• 今後はDotSpatialに移行すると思われるが、日本語の情報がなく、高度すぎて難しい。
• 当面はMapWinGISなのかな。
• MapWindowのToolBoxのソースを見ると、GDALの使い方とか勉強になるよ。
• ベクターデータで読めるのはESRI shapeファイルだけだが、ogr2ogrとかでshapeに変換すれば取り込める。

次の仕事でMapWinGISを使おうと考えていたところで、タイミングよくお話を聴けたのは本当にラッキーでした。

 

FOSS4Gの10年

• 10年前、FOSS4Gはちょうど実用化しはじめた時期。
• 2000年代前半～半ばは、使えるFOSS4Gツールが限られており、日本ではオークニーしかやってなかった。
• 2005年あたりから、Google mapsだのiPhoneだのコンシューマー向けの技術が進歩。
• 最近ようやくパーツがそろってきた。ハード、ソフト、コミュニティ　＋データ
• これからは、「データを徹底的にいじくる（QGIS, GRASS）」と「結果をすぐに配信する（MapBox …自分の地図を配信できるクラウドサービス）」が中心に。従来、配信するシステムを開発するフェーズが間にはさまっていたが、配信サービスの充実によって、 システム開発はなくなる方向に。

 

伊豆大島クライシスマッピング報告

東日本大震災のときのsinsai.infoの話も聞きましたが、それよりさらに迅速に開発・情報共有できるようになっていると。地理院など関係各所との連携も進み、データ提供がスムーズに。ただただ感心するばかりでございます。

 

pgRouting

• 経路探索を行うPostGIS拡張
• 最近バージョン2.0が出た。
• SQLで経路探索ができる select * from pgr_dijkstra みたいな感じ。
•  コストの調整ができる（信号があればコストを減らす、一方通行の場合逆走コストを倍にする、上り坂は倍にする）。
• すべてのコストを動的に計算できる（交通事故で通れない、悪天候で通れないなど）データのリビルドが不要。その代わり、検索速度は遅くなる。

 

パネルディスカッション GEOxCODE

• データの作成の部分はある程度確立されているが、表現部分（特にサーバにアップして配信するしくみ）がfoss4gではまだ足りないのでは？
• 表現部分はJavaScriptでやるとしても、アプリケーションとしてまとめあげるのはRubyかPythonじゃないか。
• ビッグデータまわり（解析まわり）のオープンソースプログラムがまだ足りないんじゃないか。その辺をOSGeo.JPで作っていってもいいんじゃないか。
• 解析・表現方法についてのディスカッションが蓄積されていくといいんじゃないか。
• FOSS4Gを整備するためのGeoじゃない人が必要なんじゃないか。

プログラム言語の議論が中心で、個人的にはかなり興味深く聴いてました。

データ表現は、WebならJavaScriptかHTML5になるんでしょうし、デスクトップならPython+PyQtとか使うと、ほかのツールとの連携とかよくなるんじゃないかと勝手に考えたりしていました。

YAPC::Asia 2013 に行ってきた

YAPC::Asiaに行ってまいりました。

セッションは昨日からやっていたようですが、仕事が休めなかったので、今日一日だけの参加となりました。

togetterのまとめはお仕事の速い方がすでに作っていらっしゃるようですので、各セッションの内容はそちらを見るのが一番わかりやすいかと。私も後で確認しようと思います。ありがとうございます！

• 1日目
• 2日目

私のPerlに対する立ち位置は、

「新しいアプリ（Webアプリでもコマンドラインアプリでも）をPerlで作ることはたぶんない（たぶんPythonとか使う）けど、既存システムの改修のお仕事なんかでPerlを使う機会はけっこう多い」

というところで、そういうメンテナンスを効率よくやるために、Perlの開発事情とか最新情報とか仕入れておきたい、というのが、イベント参加のモチベーションでした。
あと、学生時代に最初にまともなプログラミングをしたときの言語がPerlだったので、もともと興味があったこともあります。
（あと、家から近くて参加しやすかったことも一因）

で、 ざっくりとした感想です。

• Webアプリケーション開発まわりは、Mojoliciousの話をはじめ、結構勉強になりました。恥ずかしながらCGIしか使ったことなかったもので…。CGI全部Mojoliciousに置き換えたくなった。
• Perlまだまだ使われてんな～、ってのを実感しました。やっぱりネット業界では依然現役なんですね。 
• CI回してテストとかデプロイを自動化する、みたいなdevopsまわりの話題が多いのは、Perlに限らずどの言語も同じなんですかね。

Perlも進化してるし、それを取り巻く環境も進化してる。そしてPerlはまだまだ使える（使われてる）。
それを実感できて有意義な一日でした。
貴重な勉強をさせてもらって、ありがとうございました。

FlexアプリをApache Antでビルドする

最近仕事でAdobe Flexを使っていて、
やっぱりFlexアプリでも本気でCI回したい！と思ってきたので、
まずはApache Antでビルドできるようにしてみました。


今どきmavenじゃない？って感じもしなくはないですが、
ちょっとチャレンジみたもののよくわからなかったので、
そこはおいおいやるとして…。

今回はこちらを参考にさせてもらいました。

• FlexのCI用のビルド環境を構築する。

環境

• Java SE Development Kit 7u10
• Adobe Flex SDK 4.1.0.16076A
• Apache Ant 1.9.2

build.xmlの書き方

Flex SDK 4.1.0.16076Aには、Ant用のタスクが定義されたjarがすでに入っているので、
あとはbuild.xmlの中でこのjarを参照し、ビルドタスクを書いてあげればOKです。

サンプル：

    
        build flex application with apache ant.
    
 
    
    
    
 
    
    
    
 
    
    
        
            
            
            
            
                
                
            
        
    

これで、Flexアプリのフォルダに移動し、antを実行すればビルドできます。

C:\work>ant
Buildfile: C:\work\build.xml

main:
    [mxmlc] 設定ファイル "C:\flex_sdk_4.1.0.16076A\frameworks\flex-config.xml"
をロードしています
    [mxmlc] C:\work\bin\Test.swf (1305012 バイト)

BUILD SUCCESSFUL
Total time: 45 seconds

第11回ジオメディアサミットに行ってきた

イベントの詳細はこちら。

内容はこちらによくまとまってます。


個人的に超ざっくりまとめると、これからの地図は、

• SNSとの連携
• シチュエーションを自動的に把握

の２つの方向に進化していきそうです。

前者は、FBで友達がアップした写真のカフェへの行き方をナビゲートしてくれるとか。

後者はある意味セマンティックWebの世界とも重なるのかもしれません。
たとえば、飲食店だったら、現在時刻をもとに、今空いてるお店だけをフィルタリングしてくれるとか。

そうすると、もう「地図アプリ」という存在ではなく、プラットフォームの一部になる、と。

まだまだ地図には可能性が秘められてますね。

July Tech Festaに行ってきた

昨日 July Tech Festa に行ってきました。
目的はChefを勉強すること！

で、お昼に受付をして、そのままお弁当をもらい、ランチセッションへ。
ランチセッションのあと、Chefのハンズオンに出ようと思ったのですが、
満員っぽかったので、予定を変えて、Jenkinsのセッションだけ聴いて帰ってきました。

ランチセッションは、ご飯食べながらだったので、メモはほとんどとらなかったのですが、
Facebookが裏でプライベートChef使ってる、というのは初めて知りました。

Jenkinsのセッションのメモはこちら（スライドはこちら）。

「Jenkinsで始める継続的デリバリーと実践の道程」

• 継続的デリバリー(CD)では、リリースごとにフィードバックを得ることが重要。
• ユーザーからのフィードバック
• デリバリープロセスへのフィードバック（うまくいかなかった箇所の改善など）
• アーキテクチャを考えることが大事。
• デリバリーのロールバックはどうするか？
• ダウンタイムなしでリリースするには？
• データベースのマイグレーションは？
• カナリアリリース（一部の人だけに先行してリリース）も検討
• モニタリング
• アプリケーション
• ユーザーの行動
• 安定的なデプロイ
• 繰り返し実施しても同じ結果が得られること（これがいわゆる「冪等性（べきとうせい）」ってやつかな）
• 意図した時間で実行できること。 
• 失敗談とその対策
• Selenium RCが時間かかりすぎた⇒Web Driverを使った。
• VBスクリプトで作った初期化処理が失敗することがあった⇒WMI(Windows Management Instrumentation)を使うようにした。
• バッチからテストを実行すると、正常終了しないことがあった⇒Antでテストを実行するようにした。
• 次のステップ
• マルチ構成

AWS Summit Tokyo 2013 に行ってきた

今日から始まったAWS Summitに行ってきました。

午前中の基調講演は仕事のためパスし、午後からの参戦だったのですが、それにしても人が多かったこと。
各セッションの開始前には、部屋の前に200～300人くらいはいようかというくらいの長蛇の列ができて、かなりの混乱状態に。
このあたりは次回は改善されててほしいですね。

で、肝心の内容ですが、ひたすら上級者向けのテクノロジーセッションを聴いてきましたので、
以下にまとめてみます。

「AWSをフルに活用しながら、あんしんできるセキュアなクラウド利用法とは？」

• AWSでは、ゲートウェイ型のセキュリティツールを使うより、ホスト型のツールを使ったほうがよい。ゲートウェイ型だと、トラフィックの増大によって負荷が高くなるし、SPOF（単一障害点）になりうる。ホスト型だと、スケールアウトしたホストそれぞれにインストールしておけばそういった心配はなくなる。
• 対策ソフトの種類
• マルウェア対策ソフト…要はウィルスバスターとか。
• WAF（ウェブアプリケーションファイアウォール）
• SaaS型…DNS設定を変えて、すべての通信を外部のWAFを通すようにする。代表的なのはScutum。
• ネットワーク型…危機として設置。AWS上では、AMIとして提供されているものもある。
• ホスト型…ホストの中にソフトウェアをインストールする。代表的なのはmodsecurity。
• ネットワーク型IDS/IPS…パケットの監視。Snortなど。
• ホスト型IDS/IPS…整合性監視などによる不正検知。tripwire, ossecなど。
• 攻撃のフェーズごとの防御策
• ポートスキャン対策 ⇒ ネットワーク型IDS/IPS
• 侵入防止 ⇒ WAF
• バックドア作成防止 ⇒ マルウェア対策ソフト
• 痕跡削除検知 ⇒ ホスト型IDS/IPS
• トレンドマイクロの製品 Deep Security 紹介
• 上記の４つのツールがすべて入っている。
• Amazon Management Consoleと連動
• 対応OSはWindowsとRedHat/CentOS。UbuntuなどのDebian系には対応してないっぽい。 

 「ハイブリッド構成を支えるAWSテクノロジー」

• ハイブリッド構成の利用シーンと考慮すべきポイント
• 開発での利用…本番に環境をどのように持ち込むか。
• ディザスタリカバリでの利用…データをバックアップサイトとどうやって同期するか。
• 一部のシステムの移行…どうやって接続するか、どうやって連携させるか。
• インフラ
• DirectConnect…専用線でつなげる。自分でコントロールできるというメリットが大きい。
• VPCを拠点間のゲートウェイとして使うこともできる。
• データ
• S3…大容量のファイルは、マルチパートを使うと速度を向上できる。また、小さいファイルが多数ある場合は、キー名を分散させるとよい。
• インスタンスへの転送…asperaなどの製品を使うとよい。
• ブロックデバイスのコピー…AWS Storage Gateway, DRBD
• VMのコピー…VMWareのvmdkファイルをAWSにコピーできる。
• DBの同期…ファイルやブロックデバイスの同期では対応できない。AWSではCloudOptというサービスがある。
• 運用
• IAMによる権限管理
• すでにSSOを構築している場合には、STSというサービスを使うとそれらと連携できる。
• VPCでステージング環境を作ると、EIP以外は全く同じ環境を作れる。CloudFormationを使うと、JSON形式で設定を記述できる。

「AWSクラウドで構築する、ワールドクラスの分散クラウドアーキテクチャ」

• マルチリージョンは難しい
• マルチリージョンのユースケースとは？
• UX向上…なるべくユーザーに近いところにCloudFront置いたりインスタンス立てたり。
• DR…バックアップサイトを作り、障害発生時に瞬時にフェールオーバーしたい。
• リージョン間でAMIをコピーしたりEBSスナップショットを保存できたりはする。
• S3でもリージョンをまたいでデータをコピーできる。
• Route53で重みづけ振り分けができる。
• 非常に高い可用性の実現
• リージョン間でデータ同期したい
• なぜ難しいか？
• CAP定理…一貫性・可用性・ネットワーク分断耐性のうち、分散システムではすべてを同時に満たすことはできない　⇒参考 
• 合意プロトコルの構築が難しい⇒誰がマスターになるか、誰がデータをメンテナンスするのかなどをノード間で合意する必要がある。正しく合意ができるか、適切な期間で合意可能か、理論的に適切なパフォーマンスか、という観点が必要。仕組みとしてはzookeeperが有名。
• 耐障害性…リージョン間での非同期レプリケーション（同期ではパフォーマンスの点で非現実的）。GlusterFSなどの分散ファイルシステムや、Cassandraなどの分散データベースを使う手はある。
• プラクティス
• "Game Day"　本番環境でテストしよう。
• 障害は必ず起こる。なので、迅速に復旧できるような運用を日ごろから行うこと。
• できる限り、「マルチAZ」を使ったほうがよい。
• 上のような課題をある程度解決している。

まとめ

togetterのまとめが作られていました。 相変わらず仕事早いですね。。。

• 基調講演
• 初日全般

ちなみに明日は行かないので、タイムライン追いかけます。