2014年5月6日火曜日

C#でFtpWebRequestを使ったリネームがうまくいかない話

最近、C#でFTPを使ってサーバー上のファイルを移動しようとしてはまりました。

ソースはこちら（例外処理など、一部を省略してます）。 

    Uri uri = new Uri("ftp://...");
    string destPath = "/path/to/move"; 
    FtpWebRequest ftpReq = (FtpWebRequest)WebRequest.Create(uri);
    ftpReq.Credentials = new NetworkCredential(this.userName, this.password);
    ftpReq.Method = WebRequestMethods.Ftp.Rename;
    ftpReq.KeepAlive = false;
    ftpReq.RenameTo = destPath;
    FtpWebResponse ftpRes = (FtpWebResponse)ftpReq.GetResponse(); 
 
このとき、ftpReq.RenameToの値は正しい値が入っているのですが、FTPサーバーのログを見ると、RNTOに指定されているパスが壊れており、結果としてステータス550で処理に失敗します。
どうやらこちらを見ると、Visual Studio 2010と.NET Framework 4.0の組み合わせでそうなっているらしく、.NET Frameworkのバージョンを4.5にアップしたら問題は解消されていました。

投稿者 時刻: 0 件のコメント:
ラベル:

2014年3月17日月曜日

[PostGIS] メートル指定の半径で円を作る方法

最近仕事でPostGISを使うようになって、いろいろと調べているので、忘れないようにメモしていきます。

円のポリゴンを作るには、ST_Bufferを使えばよさそうなのですが、ジオメトリ型(geometry)に対してST_Bufferを使うと、バッファのサイズはジオメトリのSRID単位でしか指定できません。
たとえば、WGS84(SRID=4326)の場合だと、度単位の指定になります。

そこで、こういったSRIDでメートル単位でバッファサイズを指定するには、ジオメトリ型を一度ジオグラフィ型(geography)に変換してから、ST_Bufferに与える必要がありそうです。


（例）北緯40度、東経140度から半径100kmの円を作る
select st_setsrid(geometry(st_buffer(geography(st_makepoint(140, 40)), 100000)), 4326)

投稿者 時刻: 0 件のコメント:
ラベル:

2014年2月16日日曜日

Developer Summit 2014 に行きませんでした

今年のデブサミ、本当は激しく行きたかったのですが、仕事的に会場に行くのはちょっと厳しかったので、Twitterのタイムライン #devsumi と講演資料まとめを一通りチェックして、感想とかメモとかTwitterでつぶやいてTLを荒らし、参加した気になりました。

トレンド

クラウド、DevOps, ウェブ開発（HTML5を含む）, スマートフォンといったところでしょうか。

このあたりは、やっぱりゲーム業界やウェブサービス業界が強いですね。開発の効率化が即収益改善につながりますからね。

SI業界は、競争はあるものの、かかった時間を顧客に請求できる性格を持つので、改善意欲としてはちょっと弱いので、どんどん差が拡がるばかりですかね。

もうデスクトップアプリ開発ネタはほとんどないのか…

思ったこと

今回のデブサミでは、エンジニアとしてどうやって成長すべきか、というテーマのセッションがいくつかあり、そのすべてにインスパイアされました。


もがきながら模索を続ける彼らの姿は本当に共感できるし参考になります。私自身、自分がどうあるべきか、そのために何をすべきかものすごく悩んでるところなので。

そんなわけで、上記4つが私的ベストプレゼンです。

それと、個人的にはもっと狭い意味で同業者の話を聴きたいので、エンタープライズに限定したデブサミ、もっと言えばSIerオンリーのデブサミなんてあったらいいなあ、と思いました。SIオワコン説も納得できるのですが、ちょっとは盛り上がりたいな、と。

そして何といっても一番の収穫は、「Twitterタイムラインを荒らす」ことによって、講演者の方から直接コメントをいただいたり、参加者の方とコミュニケーションさせていただいたりして、つながりを拡げることができたことです。これは本当にありがたいことで、ここでできたつながりは何物にも代えがたい、貴重な財産として今後も残っていくはずです。

これから読みたい本


デブサミで紹介された本で、読みたいと思った本をリストアップしておきます（自分用のメモです）。




デブサミには毎年いい刺激を受けています。今年もありがとうございました。

投稿者 時刻: 0 件のコメント:

2013年12月11日水曜日

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

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

  • NPAPI版…Flashのswfファイルのパスが設定される。
  • PPAPI版…アドレスバーに表示されているURLが設定されるっぽい。

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

投稿者 時刻: 0 件のコメント:
ラベル:

2013年12月7日土曜日

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の両方出せるようです。

投稿者 時刻: 0 件のコメント:

2013年11月15日金曜日

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

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

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

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

投稿者 時刻: 0 件のコメント:

2013年11月2日土曜日

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とか使うと、ほかのツールとの連携とかよくなるんじゃないかと勝手に考えたりしていました。

投稿者 時刻: 0 件のコメント:
登録: 投稿 (Atom)