君たちは永遠にそいつらより若い

技術と音楽と日々のこと。

IE8, IE9 である環境(ドメイン)でだけ勝手に互換表示になる

Web

IE の互換機能ドキュメントモード・ブラウザモードの違い という前座の記事を書きましたが、本当に書きたかったのは、こっちの話です…！

状況

以下のような状況で、ある環境(ドメイン)でだけIE8, IE9の表示崩れが起きる現象に当たることがあります。

  • デプロイしているコードは同じ
  • ヘッダにも疑わしい変化は無い
  • 違うのはドメインだけ

調べてみると、勝手にIE7互換表示になっている。

原因

以下の二つの条件が重なると、IE8, IE9 は強制的にIE7ドキュメント互換モードでレンダリングします。

ある程度大きいサイトのドメインになると、この親切なリストに登録されていることがあります。そのため、ローカル開発環境では気付かずに、ステージング環境に上げたときに発覚したりします。

詳しくは、 互換表示一覧の概要 をどうぞ。

解決方法

  • Microsoft に削除依頼
    • ドメイン以下、全て影響を受けるので、サブドメインに他サービスがあると巻き添えを喰らう
    • Microsoftのレスポンスの速度がわからないので、リスキー！
  • metaタグ(<meta http-equiv="X-UA-Compatible" content="IE=edge" />)を追加
    • 大抵の場合、こちらの対応になるが、UserAgent について注意が必要
    • Google Chrome Frameの開発が終了 したので、 <meta http-equiv="X-UA-Compatible" content="IE=edge, chrome=1"> と書く必要が無くなったかなと思っています。

この場合は、上記の方法で解決してくださいな。ただし、

metaタグを使った解決をした場合は、以降 UserAgent に注意！！！！

例えば、<meta http-equiv="X-UA-Compatible" content="edge" />を追加したページをIE9で見ると、

ドキュメントモード:IE9標準 ブラウザモード:IE9互換表示

になります。ドキュメントモードは無事修正されましたが、 UserAgent を司るブラウザモードがIE9でなく、IE9互換表示です。つまり、IE9なのに、UserAgent が MSIE 9.0 が含まれなくなる。

参考: IE の互換機能ドキュメントモード・ブラウザモードの違い

  • IE9開発者ツールでブラウザモードを変更した場合のUAの変化

この辺りの理不尽さを把握した上で、UA振り分けを書きましょう＾＾という、お話でした。

IE の互換機能ドキュメントモード・ブラウザモードの違い

Web

IE 対応をしていると、互換モードボタン・開発者ツール・metaタグ(<meta http-equiv="X-UA-Compatible" content="IE=edge" />)で互換表示切り替えをすると思いますが、ドキュメントモード・ブラウザモードの違いや、何が何と結びついているのか、こんがらがりがち。

IE11で変更もあったので、誰かのために覚え書きしときます。

※関連記事: IE である環境(ドメイン)でだけ勝手に互換表示になる

IE 8〜10

  • ドキュメントモード
    • レンダリングエンジンを変更。UserAgent には影響しない。
    • 変更方法
      • 開発者ツール(F12)
      • metaタグ(X-UA-Compatible)
      • ツール>互換表示設定
      • 互換表示ボタン(アドレスバー横)
  • ブラウザモード
    • UserAgent・バージョン ベクター・ドキュメント モード(CSS、DOMとかの扱い)を変更。
    • 変更方法
      • 開発者ツール

IE 11

  • ドキュメントモード
    • レンダリングエンジンを変更。UserAgent には影響しない。
    • 変更方法
      • 開発者ツール(F12)
      • metaタグ(X-UA-Compatible)
      • ツール>互換表示設定
      • (IE11で互換表示ボタンは無くなりました！)
  • ユーザエージェント文字列(旧ブラウザモード)
    • UserAgent を変更。レンダリングエンジンには影響しない。
    • 変更方法
      • 開発者ツール

公式ドキュメントリンク

AndroidDownloadManager にBasic認証などの認証情報が受け継がれずファイル保存が失敗する

Web

テスト中の Web サイトは、IP 制限なり、Basic 認証なり、cookie 認証なり、何らかの認証をかけてコンテンツを保護するものです。そこで発生する Android の悲劇の回避方法の一つを紹介。

状況

  • サイトにIP 制限、Basic 認証、cookie 認証などをかけている
  • 何故か Android だけファイル(画像, pdf, zip etc...)の閲覧・保存・ダウンロード時に認証を通り抜けられずダウンロードに失敗しましたと表示される
  • 画像を表示した後の、画像を保存、リンク先を保存 を押下した際にも発生
  • 元の拡張子を無視して.bin という拡張子で保存されることもある
  • PC, Android, iPhone 共に、ページ・画像・js, css類は認証を通過している
  • Android でも機種やブラウザ(標準ブラウザ or Chrome)によって通り抜けたり、通り抜けられなかったり

原因

  • Android は、ブラウザとファイルのダウンロードのプロセスが別(の場合がある)
  • ブラウザがアクセスした後、バックグラウンドで AndroidDownloadManager がダウンロード処理を行っている(場合がある)
  • 故に、認証情報を受け継ぐことが出来ていない
  • アクセスログを確認すると UserAgent が AndroidDownloadManager になっている

解決方法(回避方法)

  • Content-Disposition: attachment; ヘッダを出して、添付ファイルとしてダウンロードさせる
  • すると AndroidDownloadManager に処理を移譲せずに、ブラウザ自体がファイルをダウンロードするので、認証情報が受け継がれ、認証を通り抜けられる
  • 一見、ダウンロードマネージャと同じような動作をするが、実際にアクセスログの UserAgent を確認すると、ブラウザの UserAgent として来ている！
  • 結果表示は、機種やブラウザによって様々。ダウンロードされたり、そのまま表示されたり。

私が確認した端末たちで成功しただけなので、まだまだ海のように広い Android 界には例外端末があるかもしれませぬ。

参考資料

Xperia SO-01BのQ&Aページ(端末の公式サイトなので、きっちりした方への説明へオススメ★)

Android Chrome browser unnecessarily renames names & types of downloaded files

Android and the HTTP download file headers

Android 4.0系端末でダウンロードするときのUser Agent

memcached で session.save_path が合っているのに保存できない

Web

過ぎ去りしある日のこと。

memcached に書き込めないファイルがあるよ！

Warning: Unknown: Failed to write session data (memcache). Please verify that the current setting of session.save_path is correct (tcp://xxx.xxx.xxx.xxx:11211) in Unknown on line 0

ちょっと大きめの数百KBのデータを順次 memcache に突っ込んでいたら、書き込めるファイルとそうでないファイルがあった。ファイルサイズの閾値にも今ひとつ法則性が無い。

あのとき調べたこと

memcached は立ち上っているとして、以下あたりを見ていった。エラーメッセージを元に調べた際、大体の他記事はtcp://が付いてねーよ！と言うものだった。付いてるし！！

  • memcached の session.save_path は合ってる？ちゃんとtcp://ついてる？
  • php.ini の upload_max_filesize に引っかかってない？
  • apache の LimitRequestBody とかの制限サイズに引っかかってない？
  • memcached の limit_maxbytes は十分？メモリ不足してない？
  • memcached の maximum object size に引っかかってない？ ←私はこれにひっかかっていた！

maximum object size is 1MB ですよ奥さん

いつ消えるかわからないので、該当項引用。

http://docs.oracle.com/cd/E17952_01/refman-5.6-en/ha-memcached-faq.html

16.6.5.2: What is the maximum size of an object you can store in memcached? Is that configurable?

The default maximum object size is 1MB. In memcached 1.4.2 and later, you can change the maximum size of an object using the -I command line option.

For versions before this, to increase this size, you have to re-compile memcached. You can modify the value of the POWER_BLOCK within the slabs.c file within the source.

In memcached 1.4.2 and higher, you can configure the maximum supported object size by using the -I command-line option. For example, to increase the maximum object size to 5MB:

$ memcached -I 5m

If an object is larger than the maximum object size, you must manually split it. memcached is very simple: you give it a key and some data, it tries to cache it in RAM. If you try to store more than the default maximum size, the value is just truncated for speed reasons.

要するに、オブジェクトの上限は一般的な設定では1MBですよ。ということ。意味不明な発生条件だったのは、私が調子こいてデータ突っ込んでいるうちに、累計1MBを超過して、データが書き込めなくなったその瞬間にのみエラーが発生していたということ。

一つの解決方法は、-Iオプションで、上限を調節すること。以下は、上限を5MBに設定して、いいの！？って聞かれているところ。よくないので止めて、実装を変えました＾＾

# memcached -u root -I 5m -d WARNING: Setting item max size above 1MB is not recommended! Raising this limit increases the minimum memory requirements and will decrease your memory efficiency.

参考にした記事

Failed to write session data, php and memcached

http://stackoverflow.com/questions/12112319/failed-to-write-session-data-php-and-memcached

「おうちでできるクラドニ図形の作り方」動画を作った

アート テクノロジー

誰でも簡単なコードと装置を使って、おうちでかっこいいクラドニ図形を描けるよーという動画を作ってみました。なんじゃそれ？という方も、まずは動画をどーぞ。

クラドニ図形とは

f:id:kuteken:20140311162237p:plain

f:id:kuteken:20130522141512j:plain

クラドニ図形（Chladni figure）は、ドイツの物理学者エルンスト・クラドニの名にちなんだ図形であり、物体の固有振動の節を可視化する方法である。

from Wikipedia

平面に粉をバラまいて、そこに音(振動)を与え、音を「見る」ことができる方法です。KAKKOII!!!!

用意するもの

さてさて。動画でざっくり紹介しましたが、実際に何を用意したのかをご説明します。

f:id:kuteken:20140309151721j:plain

  • 鉄板

    今回は0.3mmの鉄板にしました。まず、手に入りやすく、音の減衰率の小さい金属として鉄を選択しました。減衰率が小さいほど、振動が収束しづらくなります。薄い方が小さい音量で振動しやすいのですが、ハンズで触った感じ、0.1mmだとふにゃふにゃすぎ平面を保てそうになかったので、ギリギリの薄さとして0.3mmを採用しました。

  • スピーカーユニット

    なんでもいいです。他のクラドニマシーンですと、スピーカを釘で打ちつけたりしていますが、鉄板を使うとスピーカーユニットの磁石が鉄板にくっつくので楽ちんです。動画では、5Wくらいの小ぶりなスピーカーをつかっています。

  • 砂糖

    塩でもなんでも、お好みの粉を使ってください。動画ではスティックシュガーを3本分使ってます。うっかり出力を大きくすると、ぶっ飛んだりするので、掃除機必須。

  • 高周波発生装置

    ファンクションジェネレータなどの高価な機械はいらないです。便利な世の中ですね。以下のような高周波発生Webツールを書いたので、これ使って、ブラウザから直接音を出しましょう。ちなみにChromeでしか動作確認してません。

    http://kuteken.github.io/DIYChladniFigure/

    コードはこちら https://github.com/kuteken/DIYChladniFigure

やり方

動画を見て下さい！ Just do it!!

おまけ

各種アーティストの皆様が、クラドニ図形にチャレンジしています。シャレオツ…!

感想など

「誰も味わったことのない体験を」｜『BIRDMAN』築地ROY良が語るクリエイターに問われる覚悟。

http://careerhack.en-japan.com/report/detail/294

こちらの記事でクラドニ図形を見て、「ウオー！すげーかっこいい！やりてー！」と思って、当日のお昼休みに渋谷のハンズですぐ鉄板を買っていましたｗ単純w

実際にやってみると、砂糖の粒度がでかかったのか、このセットでは細かい模様の違いはわかりにくかったですね。動画で示した2,000Hzや12,000Hzは、いい感じになりました。板、粉あたりを調整すると、もっときれいに出そう…！みなさんもやってみてくださいな！

実際、材料を用意したり、機械をいじってたのは2時間くらい（あとは動画撮影・編集に半日）。とてもお手軽なHowto動画なので、小中学生が夏休みの自由研究とかで使ってくれたらいいのになーーなーー＾＾

謝辞

  • 音楽: gift / [EPV_151] a EP / lost and found
  • レンズ提供: Kyosuke Inoue
  • 英語チェック: Shizuka Horiki
  • 手タレ: Saori Ayuha

突貫工事にご協力いただいた皆様、ありがとうございました…！！！

イベント: 「Photo Hack Day Japan」に参加しました

イベント

去る2014年2月22日（土）・23日（日）、Photo Hack Day Japan に参加していました。

概要

f:id:kuteken:20140303003526p:plain

Photo Hack Dayとは、米Aviary社が主催している、写真に関するAPIを利用して写真アプリを開発するハッカソンです。世界各国で開催され、今回日本では初開催。

http://photohackday.org/

豪華な審査員、豪華な景品。ご飯とエナジードリンク飲み放題。最初の2時間はAPIのデモ、実質の開発制限時間は24時間くらいで開発。最後に、デモ＆英語プレゼン。という流れでした。

f:id:kuteken:20140303005405j:plain

f:id:kuteken:20140303005128j:plain

↑ドキドキプレゼンタイム

作ったもの

Healing Photos というプロダクトを作りました。

f:id:kuteken:20140303004021p:plain

f:id:kuteken:20140303004030p:plain

PUX APIでユーザの顔写真を分析した情報から、 ユーザの年齢・性別に合った癒し系を写真を 500pxの美しい写真からピックアップし、ギャラリーにします。 また、Leap Motionでそのギャラリーをビューでき、 Leap Motionのジェスチャーで500pxにお気に入り登録することができます。

結果と感想

結果、賞は逃しましたが、諸々ノベルティやらデモに使用したLeap Motionをもらえたりしました。Thank you, Avinash.

f:id:kuteken:20140222125853j:plain

諸感想ありますが、皆さんの作品を見ていて、会場と審査員におっと思わせるコンセプトや、それを固く支える技術力、パフォーマンス力がなければ、賞は取れないと確信を得られました。バンドの方でもライブを重ねる度に同じようなことを感じます。なんでもそういったコアの部分は同じなのかもしれませんね。成果を出せる実力を確実につけて行くために、日々鍛錬…ッします。

ハッカソンには過去参加したことがあったものの、今回初めてエンジニアリングの主戦力＆プレゼンターとして、全て自分で背負った上で参加することによって、様々な気付きが得られました。id:hatone のアドバイスのおかげです。いつもありがとう。僕は、まだまだ自分の伸びしろを信じています。

イベント: 「IAシンキングによるモバイル再設計」に参加してきました

イベント UX

今日は本を読んでのんべんだらりとしようと思っていたのですが、キャンセル待ちだった勉強会に空きが出たので急遽参加してきました。

…3週間前から、イベント3連チャンで週末mixiオフィスで過ごしているなw

イベント概要

IAシンキングによるモバイル再設計

2014/03/02 (日) 13:30 - 17:30

http://devlove.doorkeeper.jp/events/9020

話し手: UXデザイナー 坂本 貴史さん

↓新しい著書が発売予定です！！買いましょう！！

モバイルIAシンキング クロスチャネル時代のIA思考術

モバイルIAシンキング クロスチャネル時代のIA思考術

f:id:kuteken:20140302232059j:plain

  1. 講義
  2. ワークショップ1「現行サイトの情報を把握する」
  3. ワークショップ2「表示要素からユーザニーズを明らかにする」
  4. ワークショップ3「モバイルサイト設計(タイトルメモり忘れた…)」
  5. 発表・講評

講義

駆け足の講義に関わらず、非常に濃いお話で、中でも「ライナーデザイン」のお話がぐっときました。

Responsive Design Workflow

Responsive Design Workflow

この本に書かれているレスポンシブデザインのデザイン手法の一つで「全てのコンテンツを上から大事な順番に並べて行く手法」です。モバイルサイト設計は、限られたスペースに要素をつめるので、コンテンツファーストで考えなくてはなりません。このときに、「ライナーデザイン」でコンテンツを組み立てていくと、コンテンツの優先順位、項目が直列であるか並列であるかが、クリアになりやすいのです。

f:id:kuteken:20140302235649p:plain

↑Bのようなローカルナビをそのまま上に詰め込んでしまうのはNG。ありがち。

「ライナーデザイン」でそのページのコアコンテンツをはっきりさせ、コンテンツファーストでサイトを組み立てれば、このようにはなりません。

PCサイトからモバイルサイトの移行はこのように情報の再整理が必要となるので、一筋縄ではいきません…！変換ゲートウェイを通しただけでは、それっぽく配置しただけの使いづらいサイトになります…！！！

ワークショップ

  • ワークショップ1「現行サイトの情報を把握する」
  • ワークショップ2「表示要素からユーザニーズを明らかにする」
  • ワークショップ3「モバイルサイト設計(タイトルメモり忘れた…)」

ワークショップ1では、現行サイトの要素分解と仮説立て。ワークショップ2では、カスタマージャーニーマップとストーリーの作成。ワークショップ3では、ワークショップ2で導いた要求整理を元に、サイトの設計を行いました。

講評では、『「ユーザニーズ/課題」「要求整理」「実際のUI」がすべて対になり、すべて理由がつけられますか？』と全チーム指摘されました…。坂本さんのサンプルは、カスタマージャーニーマップと実際のサイト設計に軸が通っていて、背景に背骨が通っていた。やはりいいものを見るだけではなくて、自分でダメなものをつくって、講評をいただくと体で覚えられるのでいいですね。

f:id:kuteken:20140302232115j:plain

↑今回のワークショップで、私の描いたヘボ設計たち。

ウオー！次はもっと上手く書ける気がする…！坂本さん、ありがとうございました。