2015年10月14日水曜日

知っておくと便利なURLスキーム

こんにちは山田です。

本日はブラウザから「地図を見るボタン」を選択した際に、地図アプリが立ち上がり、指定した位置を開く
という物を作っている時に気づいたことのお話しです。

URLスキーム?? という謎の言葉が何度が飛び交いました。
ということで調べてみました。

URLスキームとは?

たとえば↓のものです。
http://maps.apple.com/maps?q=渋谷駅

先頭は地図のアプリを開くことを指しており、
q命令らしく
q以降で命令の内容を指定しています。

つまり、地図のアプリケーションを起動⇒渋谷で検索

という流れになります。

参考までに詳しく乗っているリンク先に記載されている情報を転載させていただきます。めもめお、、、
表:「マップ」のURLスキームで使用できるおもなパラメーター

パラメーター     内容
q     検索キーワードを指定する(緯度/経度も指定可)
ll     緯度/経度をカンマ(,)区切りで指定する
spn     表示距離を指定する
t     表示モードを指定する(m:標準、k:航空写真、h:地図+写真)
z     表示サイズを指定する
saddr     経路検索用の出発地を指定する
daddr     経路検索用の目的地を指定する


iPhone/iPad標準「マップ」と「Google Maps」、どちらを選ぶべき?

知っておくとiPhoneをもっと便利に使える「URLスキーム」とは?

2015年10月13日火曜日

~正規表現を使って文字列を取得してみる~

始めまして、開発者のⅠです。
日々の開発で経験したことなど、色々と書かせていただきますので宜しくお願い致します。

さて、今回は正規表現を用いて文字列を取得する方法について書いてみたいと思います。
正規表現については、どこかで耳にしたことがあると思います。それをここで全て説明するのは難しいので省略いたしますが、一言でいうと「抽象的な文字列の表現」と言えます。

※参考URL:http://www.mnet.ne.jp/~nakama/

この正規表現を利用して、例文から条件と合致する文字列を取得してみたいと思います。
正規表現を使って日付と曜日を取得してみましょう。

-----------------------------------------------------------------------
string sentence = "2015年10月13日火曜日, 天気は晴れです, 今日の最高気温は24℃です ";

Regex regDate = new Regex("(2015).*(曜日)");
Match s_date = regDate.Match(sentence);
string test = (string) s_date.Value;
------------------------------------------------------------------------

これで、変数 test に「2015年10月13日火曜日」が入っていれば成功です!

今回はここまでです。

また次回、お会いしましょう。









2015年10月9日金曜日

SQL 算術オーバーフロー エラー

「expression をデータ型 datetime に変換中に、算術オーバーフロー エラーが発生しました。」

こんにちはYです。
クエリを実行中、上記のエラーが発生してちょっと調べてみました。


declare @datetimedisp datetime
set @datetimedisp = 20160101

select
    *
from
    mst_table
where
  1 = 1


どうやら、int型の20160101をdatetime型に暗黙的キャストをSQLServerが行っていたらしく、
キャストの失敗が原因でこのようなエラーが起きていたのだとわかりました。

正しくは 「2016-01-01」または「2016-01-01 00:00:00」と代入するのが正しいようです。
久しぶりに触って忘れていたことでした。

2015年10月7日水曜日

iOS9のATS絡みの審査とリジェクトについて

Zメンです。iOSの開発に関するあれこれを書いていきます。



■iOS9で出てきたATSってなに?


iOS9が出てから(っていうか出る前から)開発者の間でATS絡みの話題が結構出てますね。
ATS自体はいまさら感がありますが、結局審査の時どうなるの?というところが意外と触れられてないです。
ちなみにATSはAppTransportSecurityの略ですね。


簡単に言うと
「今後アプリでの通信は全てHTTPSが推奨ですから!」
「HTTPで通信しようとしたらHTTPSに強制変換しますから!!」
な話です。


これが結構曲者な感じで、
HTTPSといっても『あれね、SSLね』ではなくて、具体的には
 ○TLS バージョン 1.2 以上
 ○接続時に使用できる暗号スイートに制限がある
 ○サーバ証明書に制限がある
   ・SHA256 以上のフィンガープリント
   ・2048 ビット以上の RSA キー、もしくは 256 ビット以上のECCキー
   ・無効な証明書を使用した場合は強制的に失敗になり、接続できない
な条件があります。


なので使用しているサーバーの環境によってそもそも対応できないよ!てことが普通にあるかと。
運営しているサイトがでかければでかいほどこのへんの変更は時間かかりそうですね。



■ATSの暫定対応(非推奨)


先に公開されてる対応方法だけ書いておきます。
といってもいろんなところで既に書かれまくっているので
こことかここ
とか参考にしてもらったほうが早いです。
『iOS ATS』でわんさか出てきます。



■懸念点と審査・リジェクト


今回の仕様変更の影響範囲は通信全てなので、
NSURLConnectionAFNetworkingみたいなAPI通信以外にも
UIWebViewだとかWKWebViewのようなWEBページ表示もしっかり影響範囲です。



大手でもまだまだWebViewベースでアプリを作ってるところもあるなかで、
この仕様変更は結構きついなーと。

一応HTTPSで動作確認はしましたが、
 ・CDN使ってるとこ
 ・広告表示してるとこ・
 ・オーディエンスデータとってるとこ
などなどがほんとに動作保障しきれるのか?とかなり不安です。
一部通信エラーっぽいログとか出てたし。(ログはかなり不親切)


なので jQueryみたいなCDNのはまだいいとして、個々の広告業者なんかは
しらみつぶしに検証するとかほんと時間の無駄。


クックパッド開発者ブログ
さすがcookpadさん、この辺も言及されてますね。


で、本題のそもそもATSを無効にした場合、
とくにWebView使ってて NSAllowsArbitraryLoadsで設定を切らざるを得ない場合、
はたして審査は通過するのか、ということです。


このあたりは丁度審査中なので追って追記します。
2015.10.08 追記)
審査無事通過しました。
ドメインを個別に指定する方法でも、BOOL値切替でもどちらでも
今のところ審査には支障はないみたいです。



ちなみに、審査通ったからと言ってHTTPSとか考慮しないし、
という訳ではなく、iOSX?以降で必須にされる場合ももちろんあるだろうし、
Appleに対してすべての通信がSecureであるよ、とちゃんと伝える意味でも
早めにATSに準拠したかたちに修正するのが望ましいでしょうね。



参考)Apple Developer 公式ドキュメント


wgetでサイト内のリンク切れチェック(いろいろ実験)

以前、wgetでサイト内のリンク切れチェックの記事でwgetのspiderオプションを紹介しましたが、実施するにあたって
  • 「-recursive -level 1」とすると指定ページだけチェックして終わり?もしくは指定したページからリンクされたページまで辿る?
  • 同一URLのリンクが複数貼られていた場合、毎回チェックしにいくのか
  • リダイレクトされるURLの場合、リダイレクト先まで追ってくれるのか
  • 一斉に大量のリクエストを送ってサーバに負荷をかけ過ぎないか
のような疑問が浮かんだので、実際に実験してみました。

準備

以下の様なリンク構造を持ったサイトを用意しました。



やかましい矢印は他ページへのリンクを表しています。/detail/4.htmlからはトップページ(index.html)へ302リダイレクトするようにしています。

結果


-recursive -level1でどこまでリンクを辿るのか

wget --spider --no-directories --background -o test.log --recursive --level 1 --no-verbose --execute robots=off http://localhost/index.html
上記コマンドを実行したところ、以下の様なアクセスログになりました。
127.0.0.1 - - [17/Sep/2015:19:15:56 +0900] "HEAD /index.html HTTP/1.1" 200 -
127.0.0.1 - - [17/Sep/2015:19:15:56 +0900] "GET /index.html HTTP/1.1" 200 66
127.0.0.1 - - [17/Sep/2015:19:15:56 +0900] "HEAD /list/1.html HTTP/1.1" 200 -
127.0.0.1 - - [17/Sep/2015:19:15:56 +0900] "GET /list/1.html HTTP/1.1" 200 111
127.0.0.1 - - [17/Sep/2015:19:15:56 +0900] "HEAD /list/2.html HTTP/1.1" 200 -
127.0.0.1 - - [17/Sep/2015:19:15:56 +0900] "GET /list/2.html HTTP/1.1" 200 4340
-level 1とすると、指定ページから貼られているリンクだけチェックするようです。

同一URLのリンクが現れた時、毎回チェックするのか

-level 3と指定して実行したところ、以下の様なアクセスログになりました。
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "HEAD /index.html HTTP/1.1" 200 -
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "GET /index.html HTTP/1.1" 200 66
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "HEAD /list/1.html HTTP/1.1" 200 -
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "GET /list/1.html HTTP/1.1" 200 111
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "HEAD /list/2.html HTTP/1.1" 200 -
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "GET /list/2.html HTTP/1.1" 200 148
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "HEAD /detail/1.html HTTP/1.1" 200 -
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "GET /detail/1.html HTTP/1.1" 200 180
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "HEAD /detail/2.html HTTP/1.1" 200 -
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "GET /detail/2.html HTTP/1.1" 200 180
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "HEAD /detail/3.html HTTP/1.1" 200 -
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "GET /detail/3.html HTTP/1.1" 200 180
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "HEAD /detail/4.html HTTP/1.1" 302 -
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "HEAD /index.html HTTP/1.1" 200 -
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "GET /index.html HTTP/1.1" 200 66
一度チェックしたURLは再度現れても省略されるようです。これは助かります。
ただ、パラメータが付くURLの場合、その順番が若干ずれるだけで別URLとみなされるので、
URLの埋め方によっては効率が悪くなってしまいますね。

リダイレクト先まで追ってくれるのか

先ほどのアクセスログにもありますが、リダイレクト先も追ってくれます。これも助かります。
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "HEAD /detail/4.html HTTP/1.1" 302 -
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "HEAD /index.html HTTP/1.1" 200 -
127.0.0.1 - - [17/Sep/2015:19:20:32 +0900] "GET /index.html HTTP/1.1" 200 66
ただし、リダイレクト後のURLはチェック済みであっても再度確認しにいくようですので、注意が必要です。

サーバへの負荷は大丈夫か

パラメータだけ異なるリンクを100個ほど増やして試してみたところ、今回の環境(windows上に立てたapache)では65req/secほどでした。
通常のwebサイトでは問題なさそうですが、ページごとの処理内容やサーバのスペックにもよるかと思いますので、
参考程度として頂けたらと思います。