$ s3cmd put bkup-data:xxxx.tar.gz /tmp/xxxx.tar.gz
Connection reset: Connection reset by peer
99 retries left

使っているのは、Amazon S3のRubyライブラリ。バージョンは1.2.6です。

今回はCentOS 5.3から6.2への移行。S3ライブラリや転送するデータサイズ、相手のバスケットなどは変えていないので、やっぱりカーネル関係なんだろうなと。しかし、なかなか原因が特定できず、結構ハマりました。

以前は定期的に2G～3G程度のファイルを送っていたのですが、何度やっても切られるので断念。試しに2Mくらいのファイルを送ったら成功。50Mではアウト。割と早い段階で壁に当たってしまいます。最初はtarのまとめ単位を変えるなりsplitするなりして小さくして回避しようかとも思ったのですが、このサイズだと実際問題厳しすぎる。

で、まぁ色々やってみて、なんとなく特定できたのはLinuxカーネル2.6.17以降でTCP Windowバッファが自動チューニングされるようになっていると。コイツが、どうにかすると他のギアと干渉しあって接続を切るような挙動をしてしまうようです。実際にそうした干渉を確認できたワケではなく、そうらしいよという記述をこの辺やこの辺りで読んで調整入れたところで上手くいったので、そこで止めてしまった曖昧情報で申し訳ないのですが。

ともあれ上手くいったのは、ソケットのバッファ用メモリサイズを手動で設定すること。
/etc/sysctl.conf に、次のような記述を追加します。

net.core.rmem_max = 1747600
net.core.wmem_max = 1747600
net.ipv4.tcp_wmem = 4096 87380 1747600
net.ipv4.tcp_rmem = 4096 87380 1747600

ファイルを書き換えたら、端末をリブートするか、次のコマンドを実行。

$ sudo sysctl -p

正直なところ、バッファサイズをどの程度にすれば良いのか、よく分かりませんでした。この10倍くらいに設定している例もあれば、半分以下のものもあり。試した人の記述では、転送するファイルの総量が大きいほどに値を下げると上手くいくとありました。もちろん、下げすぎればネットワークのパフォーマンスに悪影響が出ます。せっかく自動チューニングしてくれるのだから、そちらに任せたいのですが…残念。しばらく様子見ながら、値は調整するかもしれません。

恐らく、S3に限らずサーバからソケット繋いでファイル転送する色々なサービスで起きる問題なんじゃないかと。同様の問題に当たって変更される場合、あくまで自己責任でお願いします。

No related posts.

jQuery Mobile 1.0 日本語リファレンス

アルファ版からは当然ながら大きく変わっていて、特にAPI関連は、まったくの別物。放置していて申し訳ありませんでした。

jQuery MobileではjQueryの知識も必要になる部分が(当然ながら?)結構あり、こちらも直近の更新はキャッチアップしてないなと思ったり。余計なことですが、名前がそのまんまな「jQuery日本語リファレンス」は前職時代に自分が作って遺してきたものです。後輩の子たち、全然更新してくれないな…とか。

最近jQuery Mobile関連の仕事を続けてもらいまして、特に米国では急速にユーザが増えていることを実感します。ギャラリーに上げられるサイトも増えていて、アプリ(多分、PhoneGapを使用)でもjQuery Mobileを利用したものが散見されるようになりました。

自分でも、趣味サイト1本作ろうかと画策中。楽しみです。

[PR] jQuery Mobile リファレンスが書籍として発売されることになりました

jQuery Mobile ポケットリファレンス

森 直彦 (著)

技術評論社 (2012/1/20)

新品 ￥2,709

Related posts:

1. [jQuery Mobile] 1.0.1公開
2. [jQuery Mobile] チートシートつくりました
3. [jQuery Mobile] ページイベント・チートシート

ベータ2のリリース内容

今回のリリースでは、ライブラリに大幅な向上があります。

• ウィジェットの切り離しによって、必要なコンポーネントだけを選択取り込み可能に
• DOMキャッシュ機能により、メモリ使用量の低減
• ページのプリキャッシュ・オプション
• ページ構造が柔軟に
• チェックボックス、ラジオボタンのデザイン向上
• JavaScriptによる動的ページを作る場合の拡張機能追加

ベータ1リリースから5週間の尽力で、正式版リリースに大きく前進しています。

ベータ3

正式版のRCとしてバグフィックスやパフォーマンス調整に入る前に、更に追加したい幾つかの重要な機能が残されています。来月リリース予定のベータ3では pushState のサポートや、切り替え動作の Firefox や Opera での向上、開発者向けの拡張機能実装などが含まれます。

jQuery Mobile 1.0では、ベースとなる jQuery core の 1.6.2 以上が必須となることに注意してください。jQuery coreでリリースされている更に上のバージョンもサポートされますが、基本線はこのバージョンを基にしています。

サポート対象プラットフォームの更新

ベータ2では、OperaとFirefox向けのCSSサポートを強化しました。また、Android 2.3搭載モバイルとHoneycombタブレット、HP Palm WebOS 3.0タブレットをサポート対象としています。更にNokia S60以降のデバイスをBグレードに加えました。

Nokia S60以降をBグレードとしたのは、これらの端末がハッシュの変更イベントを正しく検知しないためです。つまり、Nokia端末ではAjaxを使ったページ切り替え機能のような拡張機能が動作しないことになります。

この段階で、jQuery Mobileは現在使われている大部分のデスクトップ、スマートフォン、タブレット、電子リーダー上で動作するようになりました。加えて、プログレッシブ・エンハンスメント手法を採っていることで、古いブラウザ上でも動作します。ここでサポートしている広範囲のプラットフォーム上で、ユニヴァーサルなアクセシビリティを担保することが出来ています。

詳しくは、更新した jQuery Mobile 日本語リファレンス：サポートするプラットフォーム 参照。

ウィジェット：分離により柔軟なビルドが可能に

ページプラグインからウィジェットを「分離」させることは長年の課題でしたが、遂にそれが実現しました(参照 1 2 3)。「分離」とは、実際にどういうことか。各ウィジェットやユーティリティは、各個のスクリプトファイルに分割されています。しかし、ページプラグインが全ての公式プラグインをページ上にマークアップされていないかどうか確認するために、結局全てのプラグインファイルを読み込む必要があったのです。これによって、不要なプラグインを外すとエラーを起こすことになってしまいました。今後のウィジェット追加に際しても、非常に良くない慣行です。

今回のリリースで、全てのUIウィジェットはjQuery Mobileライブラリから完全に分離されました。そのため、もし特定のプロジェクトにおいて不要なプラグインがあれば、それを単純に削除することが出来ます。この変更によって実際に必要なプラグインだけを取り込めば良くなり、ダウンロードされるライブラリのサイズを劇的に小さくすることが出来るでしょう。現在、更に完全な分離が進められています。現時点で、次のファイルは分離されていますので、カスタム・ビルドの際に不要なものは取り除くことが可能です。

• page header/content/footer
• collapsible
• controlgroup
• fieldcontain
• fixheaderfooter
• button
• checkboxradio
• select
• slider
• textinput
• links theming
• listview
• navbar
• grid

いくつかのウィジェットは相互に関係しているので、依存関係表の作成も必要になってきます。たとえば、上記の多くのプラグインが動作にはbuttonプラグインを必要としますので、これを削除するには依存関係にある全てのプラグインが不要である場合だけということになります。

こうした推奨依関係表の作成や、分離機能自体も現在なお更新中です。究極的には、この機能はダウンロード・ビルダーに実装されることになると思われます。

“create”イベントの追加

個々のプラグインにウィジェットを適用する作業は、多くの場合、”pagecreate”イベントで自動的にウィジェット自身によって初期化されます。ページ上で該当するウィジェットがあった場合、プラグインスクリプトが自動的にエンハンス処理を行っていました。たとえば、セレクトメニュープラグインがロードされれば、ページ上のセレクト要素は自動的にエンハンスされます。

この処理が、今後は要素に対して “create” イベントを発行することでも可能になりました。これによって、手動で初期化する際の手間が大きく軽減されます。これまでは、コンテンツがAjaxや動的なマークアップによって変更された際、全てのプラグインを手動で初期化する必要がありました。

今後は、マークアップに “create” イベントを発行することで、ページが作られた時同様に必要なプラグインのチェックや処理を自動的に行わせることができます。たとえばログインフォームなどでAjaxを用いてHTMLのブロックを持ってきた場合、このブロックに対して “create” イベントを発行することで自動的に内包する input や button などのウィジェットをエンハンスすることが出来ます。例えば、次のようなコードになるでしょう。

$( ...new markup that contains widgets... ).appendTo( ".ui-page" ).trigger( "create" );

ここで “create” イベントと “refresh” メソッドの違いに注意してください。新しい “create” イベントは、生のマークアップに対して包含する複数のウィジェットを適用します。一方 “refresh” メソッドは(幾つかの)ウィジェットに実装されており、既に適用されたウィジェットに対してプログラムから操作を行った場合などに、見た目の更新をするために呼び出すものです。

たとえば、ページがロードされた後で動的に ul 要素を追加し、そこに data-role=”listview” 属性を指定したとします。この要素に対して “create” イベントを実行させれば、この要素は listview スタイルのウィジェットになります。このリストに、プログラムから更に幾つかのアイテムを追加したとします。その場合は、リストビューウィジェットの “refresh” メソッドを呼び出して、リストの見栄えを更新してやります。

DOMキャッシュ管理機能

従来、Ajaxによるページ遷移時には、移動前のDOMに移動先のDOMを追加していくようになっています。これまで、この追加されたページは全体がリフレッシュされるまで追加されたままになっている仕様でした。そのため、あまりに多くのページを行き来されると、ブラウザ上のメモリを消費して動作を重くさせたり、最悪はクラッシュさせる危険性がありました。

ベータ2では、DOMを小さく保つための簡単な仕組みを実装しています。それは、次のように機能します。Ajaxによってページがロードされた場合、遷移が完了すると以前のページはDOMから一度削除されます。このページにユーザが戻ってきた場合、ブラウザはページ内容をキャッシュから取り出すか、必要であれば再度サーバへ要求するようになります。これが階層化リストの場合であれば、ユーザがリストに含まれないページへ遷移した際に全てのリストページを削除することになります。複数ページを内包したファイルである場合はこの限りでなく、あくまでjQuery MobileによってAjaxで取得されたページに限った動作です。

新しく追加されたページオプション “domCache” によって、以前のようにDOMをキャッシュし続けるか、それとも削除して小さく保つかを制御することが出来ます。初期状態では、この “domCache” オプションは “false” に指定されています。これは、ベータ1以前とは異なりDOMのサイズを積極的に制御しようとします。もしこれを “true” に変えるならば、DOMのサイズに関する問題を自分自身で、複数のデバイスに対してテストする必要が出てくるでしょう。

もしこの “domCache” を各ページ単位で指定したい場合、ページコンテナ要素に対して data-dom-cache=”true” 属性を指定するか、次のようなコードを記述します。

elem.page({ domCache: true});

この domCache オプションはグローバル設定も可能です。

$.mobile.page.prototype.options.domCache = true;

ページのプリフェッチ・オプションの追加

今回追加されたクールな機能のひとつが、このプリフェッチ・オプションです。Ajaxによるページ取得をプリフェッチさせることができます。たとえば、各写真が別個のHTMLページになっているフォトギャラリーを作るとしましょう。スライドショーで前後のページをプリフェッチさせることにより、Ajaxローダが逐一動かずに写真を表示させることが可能になります。使い方は簡単で、ページ上のリンク要素に data-prefetch 属性を指定するだけです。フレームワークがバックグラウンドで自動的にページをレイジー・ロードしてDOMに追加しておきます。jQuery Mobileによるサイト構築時、HTMLページは個別に分けられることを奨励していますが、実際は複数ページのテンプレートやネスト構造リスト(!)を使って、ページ切り替えを速くしようとしている姿を見かけます。このプリフェッチ機能が、そうした手法の代替になることが期待されます。

link text

プログラムから $.mobile.loadpage( url ); を呼ぶことでも、ページをプリフェッチできます。プリフェッチリンクは、当然ながらそこに遷移されない場合でも追加のHTTPリクエストを発生させますので、ユーザが遷移する可能性の高いリンクのみに適用するよう心がけましょう。

グローバル・コンフィグ・オプションの追加：autoInitializePage

ページの初期化処理を更に制御したい開発者のために、新たに autoInitializePage オプションを追加しました。これを false に設定すると、ページ作成時の自動初期化処理が停止し、開発者が手動によるページ初期化を行う前にマークアップを操作したりすることができるようになります。初期状態ではオプションは true に設定されています。

ロード時のメッセージを、実行後に指定可能に

以前は、ロード時のテキストメッセージを初期化オプションとして設定可能なだけで、特定の状況で動的にメッセージを変えることは出来ませんでした。追加機能により、実行時にプログラムから動的にメッセージを変えることが可能です。

$.mobile.loadingMessage = "My custom message!";

スワイプイベント発生の閾値設定追加

スワイプに関するコードは、jquery.mobile.js内でかなりハードコーディングされています。このイベントが発生するための閾値も定数になっていますが、開発者がこの値を調整したい場合もあるでしょう。そのための指定が出来るようになりました。

• scrollSupressionThreshold (default: 10px)
• durationThreshold (default: 1000ms)
• horizontalDistanceThreshold (default: 30px)
• verticalDistanceThreshold (default: 75px)

vClick機能の停止

ベータ1で実装されたvClick機能ですが、テストの結果、様々な問題を引き起こすことがわかりました。そこで、元通りに戻すことになったとのことです。問題について詳しくは、翻訳は割愛します。興味がある方は元記事を。

ページコンテナがオプションに

文書構造をよりフレキシブルにするため、ページコンテナとしての data-role=”page” 属性付きの要素はオプション扱いとなりました。これによって既存のサイト流用や外部コンテンツとのマッシュアップがしやすくなったはずです。

これで page, header, content, footer の data-role 要素は全てオプションとなりました。ここで、ページのコード例を確認できます。

実際背後では、コンテナが無い場合にはフレームワークが自動的にマークアップを追加しています。しかし、実際に記述するマークアップはシンプルに出来るでしょう。ただし、複数ページを包含させるためには、やはりページコンテナは必要となります。

チェックボックスとラジオボタンのデザイン変更

以前のチェックボックスやラジオボタンは、ハイライト時に背景が全て変わっていました。これは、特にチェックリストで複数のアイテムが選択可能な時に、少し目立ち過ぎの感がありました。そこで、デザインをよりスッキリしたものに変更することにしました。

コントロールの新デザインは、ややシンプルなものになっています。チェックボックスやラジオボタンは、タップするとボタン全体がハイライトされるのではなく、シンボルの色が変わるだけになっています。ただし、横方向に並べてグループ化されたチェックやラジオは、依然としてボタン全体が彩色されます。

サポートプラットフォームの拡大

ブラウザのサポート対象拡大に伴い、CSS3によるbackground gradients指定のベンダープレフィックスを追加しました。Opera用(-o)、Internet Explorer用(-ms)のプレフィックスが、通常のルールに追加されています。

background-image: -webkit-linear-gradient(top, #3c3c3c, #111); /* Chrome 10+, Saf5.1+ */
background-image:    -moz-linear-gradient(top, #3c3c3c, #111); /* FF3.6 */
background-image:     -ms-linear-gradient(top, #3c3c3c, #111); /* IE10 */
background-image:      -o-linear-gradient(top, #3c3c3c, #111); /* Opera 11.10+ */
background-image:         linear-gradient(top, #3c3c3c, #111); /* Standard, non-prefixed */

これによって、backgroundのgradients機能が WebKit, Firefox, Opera, Internet Explorer 10, そしてプレフィックスを付けないことによって標準準拠している全てのブラウザで使えるようになりました。以前ブログで書かれたように、一度 -ms プレフィックスを外さなければなりませんでした。これは IE9 が border radius などの機能についてコンフリクトを起こし、Microsoftがこれを修正してくれないためです。このため、WP7やMangoを含む古いバージョンのIEでは、背景色がフラットなものになってしまいます。この問題について詳しくは issue #2046 を参照してください。

コードフォーマットのクリーンアップとJSLint対応

全てのコードフォーマットがjQueryコアのスタイルガイドに準拠したものになりました。これによって、ライブラリが JSLint などバリデーションツールで動くようになっています。

ベータ1からの更新

ベータ1で追加された useFastClick オプションは、削除されています。これは、前述のとおり vclick が使われないようになっているためです。

この他、細かいバグ修正などの変更履歴は元記事参照のこと。

日本語リファレンスについては、徐々に更新していきます。

Related posts:

1. [jQuery Mobile] BartenderプラグインでフッタをiOSアプリ風にする
2. [jQuery Mobile] ActionSheetプラグイン
3. [jQuery Mobile] SEOとユーザビリティを両立させるポイント

jQuery Mobile 日本語マニュアル

jQuery MobileはjQueryコアベースのモバイル端末用フレームワークですが、触ってみてもらえるとわかるようにJava Scriptのコーディングが必要な部分は、ほとんどありません。マークアップを基本に、jQuery Mobileが data- で始まる属性値を探してプラグイン化していくスタイルで、昔自分が作った jGlycy と基本的な発想は同じ。HTML5で data- 属性が使えるようになったことで、きっちり採用になりました。

雑感

しばらくいじってみた感想ですが、「さすが…」の部分と、「やっぱりまだアルファ版」の部分が、結構あります。

基本コンセプトは、分かりやすいものです。Ajaxによるページの切り替え機構も見事ですが、トランジションがスムーズなだけにDLのディレイがモッサリ感じてしまうことも確か。パケット料金がかかることとのトレードになりますが、サイト構造によってはプリロードの機能が欲しいかも。

フォームの制御は、文句無く使うべき。やっぱりネイティブコントロールは、タッチパネルにフレンドリーでないので、操作キツいですから。長めのセレクトリストなどが別ページに自動的にジェネレートされるのも自然だし、開発者は大分助かると思います。

ちょっとひっかかるのは、ひとつはブラウザの履歴制御。ハッシュを書き換えながらやっていくのですが、途中でリロードなどを挟むと上手く繋がらないことが多い感じが。スマートフォン上では余計な操作が減るので問題は大分減ると思いますが、ちょっとストレスです。

その他、現時点では意外とバグが多い印象です。リファレンスに記載されていることでも、実際には動かない機能が幾つか。公式ドキュメントでもデモは実際には説明してあるコードでは無かったり、デモ自体が上手く動いていなかったり。この辺は、日本語リファレンスの方では注意書きを添えたり、割愛してしまったりしました。ベータ版では、ちゃんと仕上げてくると思います。

jQuery UIであまり盛り上がらなかったテーマローラーについては、今後の提供予定に入っています。確かにデフォルトのテーマもすぐに見飽きる感じなので、センスの良い選択肢が幾つかあると嬉しいですが、デザイナーさん次第でしょうか。

最後に、ここで前に説明したレスポンシブ・レイアウト対応の機能もキッチリ入っています。ここは特に今後キモになってくると思いますので、スマホ対応サイト構築時は初手から考慮しておくことをオススメします。

Related posts:

1. [jQuery Mobile] ActionSheetプラグイン
2. [jQuery Mobile] ベータ2 リリースノート
3. [jQuery Mobile] Paginationプラグイン

簡単におさらいしておくと、次のようなページを
フレキシブル・グリッド・バージョン (A List Apart)
最終的には、次のようなレスポンシブ・レイアウトに
レスポンシブ・レイアウト・バージョン (A List Apart)
仕上げようという試みです。

基になるレイアウト

まずは、大まかなレイアウトの構造を確認しておきましょう。全体の構成は大きく分けて4つのブロックから出来ています。

mastはfloat: left、それ以外の3つはfloat: rightが指定されて、こうした段組になっています。
(これはあくまで、今回のサンプルの話です。レスポンシブ・レイアウトは、どんな段組にしようと基本的には実装可能です)

レスポンシブ初歩

では、これをウインドウサイズを縮めた時に、縦方向に並ぶよう記述してみましょう。

@media screen and (max-width: 600px) {
  .mast,
  .intro,
  .main,
  .footer {
    float: none;
    width: auto;
  }
}

非常に簡単なことで、各クラスのfloat指定を無くしてやるだけです。コードは「横幅が600pxより小さくなった場合、4つのクラスに対してfloat: noneとwidth: autoを指定する」という意味になります。

動作は、こちらから確認できます。いかがでしょうか。

画像の組み換え

次に、mainブロックにある画像に着目してみます。

現在、3×2のレイアウトになっていますが、スクリーンを小さくしていくと画像が小さくなりすぎてしまうので、ある地点から2×3のレイアウトに変えようと思います。

各人物のエリアには figure というクラスが割り当てられていて、約1/3の大きさになるように指定されています。そして、それぞれ右側にマージンをとっています。ただし、レイアウト上右端に来る2人(HOLMESとWINTER)は、右側のマージンが不要なので、id指定により除去しています。

.figure {
  float: left;
  margin: 0 3.317535545023696682% 1.5em 0;   /* 21px / 633px */
  width: 31.121642969984202211%;             /* 197px / 633px */
}

li#f-mycroft,
li#f-winter {
  margin-right: 0;
}

ここでスクリーンの横幅が400px以下だった場合には、figure の横幅が約半分になるようメディア・クエリーで指定します。

@media screen and (max-width: 400px) {
  .figure,
  li#f-mycroft {
    margin-right: 3.317535545023696682%;    /* 21px / 633px */
    width: 48.341232227488151658%;          /* 306px / 633px */
  }

  li#f-watson,
  li#f-moriarty {
    margin-right: 0;
  }
}

更に、右側のマージンが不要になる人物(つまり右端に来る人物)も変わるので、そこの指定も行っています。

動作を確認してみてください。

大画面対応

さきほどのレイアウト組み換えは、逆にスクリーンが大きくなった際にも有効なテクニックです。

次のコードは、スクリーンの幅が1300pxを超えた場合に、人物を横一列に並べるよう指定しています。

@media screen and (min-width: 1300px) {
  .figure,
  li#f-mycroft {
    margin-right: 3.317535545023696682%;    /* 21px / 633px */
    width: 13.902053712480252764%;          /* 88px / 633px */
  }
}

動作はこのようになります。

更に進んだ使い方

これらのテクニックを応用することで、更に進んだレイアウトが可能になります。

前回の冒頭で紹介した最終形では、次のような工夫をしています。

• 各メニューが、小さな画面では最上部に横並びになる (ナビゲーションはページの先頭にあった方が便利なはず)
• 小さくすると、ロゴがシンプルな小さいバージョンに換わる (余計なものを除去)
• 大きな画面では、メニューが右上に並ぶ (人物が横一列にならび高さが低くなるので、そちらに移してもレイアウト上問題ないはず)

あとはCSSのテクニックとの組み合わせばかりなので、コードを挙げての説明は割愛します。必要に応じて、サンプルのコードを直接開いてみてください。工夫次第で、かなり色々なことが出来ると思います。

古いブラウザへの対応

このようにメディア・クエリーは非常に強力な機能です。しかし、きちんと対応しているのは主なブラウザでは次のあたりになります。

• Safari 3以上
• Google Chrome
• Firefox 3.5以上
• Opera 7以上

何かと問題の Internet Explorer も、次のバージョン9からはメディア・クエリーに対応すると表明はしています。

実際のところ、メディア・クエリーが動作しないブラウザであってもフレキシブル・グリッドなどは機能するものが多いですし、極端に大きくしたり小さくした際に最適なレイアウトが得られないだけなので問題は無いかもしれません。しかし、せっかく用意したものなので少しでも多くのブラウザに対応させたいということであれば、次のような方法があります。

• jQueryのMedia Queryプラグインを使う。非常に限定的な機能しか使えませんが、2007年からある便利なツールです。
• Css3-mediaqueries-jsを使う。スクリプトがメディア・クエリーの記述を探し出して解析し、動作をエミュレートしてくれます。おかげでIE5以上、Firefox全般、Safari 2以上でもメディア・クエリーが使えるようになります。

これらを導入することで、古いブラウザ環境であってもJavaScritpが動作するようになっていれば、対応できるようになります。

レスポンシブ・レイアウトは、Webの閲覧デバイスが加速度的に多様化している現在、ユーザにとっても開発者にとっても重要なものになってくるでしょう。これからサイトデザインやリニューアルをする場合、最初から設計に組み込んでおくのが良いと思います。

Related posts:

1. [Design] Responsive Layoutを学ぶ(1)

どうも「Responsive Layout」を日本で何と呼んでいるか分からず、だから見つからないのだと思うのですが。海外にすごく良い記事があったので、こちらのサンプルを用いながら、自分用にまとめておきます。

なお、サンプルは元記事のものへのリンクですが、本文は自分のざっとの理解で書いていますので、翻訳にはなっていません。ご了承ください。

デバイスごとに個別にページを用意

サイトが世に必要とされはじめた頃は、これが定番でしたね。サブドメインで m.example.com とか mobile.example.com とか。最近になっても smartphone.example.com なんてのも見かけます。

日本のガラケー対応は、あまりにもPC向けページとは作りが異なるので、結局これしかない部分もあります。また、デバイスによって画面のステップ数を変えるようなこだわりがある場合は、必要かもしれません。

しかし、ほぼ同じアーキテクチャで閲覧できる最近のスマートフォンで、そうした手間をかけるのは面倒です。SEOやメディアからの被リンクにも、あまり良いことは無いですし。

かといって、PCそのままのページ構成では読みにくい場合があることも事実。そこでまず出てくるのがフレキシブル・レイアウトです(まだ、今回取り上げたい「レスポンシブ・レイアウト」ではないので、慌てずに)。

フレキシブルなレイアウト

フレキシブル・レイアウトがどういったものなのか、サンプルを見てみましょう。

フレキシブル・グリッド・サンプル (A List Apart)

PCブラウザで閲覧している場合、ウインドウサイズを大きくしたり小さくしたりすると、どういうものかすぐに分かると思います。いわゆる Fruid Grid (可変グリッド)と呼ばれる構造に、フレキシブル・イメージという親のグリッドにあわせて画像サイズが自動調整されるテクニックを用いた、まさに「フレキシブルな」レイアウトになっています。

可変グリッドやフレキシブル・イメージについては詳細な説明は割愛しますが(要望があれば、どこかで)、スクリプトは事実上IE対応のみで、マトモなブラウザ相手であればHTML+CSSだけでサクサク実装できるのが魅力です。

これで概ね幸せだったのですが、iPhoneサイズで見るには、まだ残念な感じです。極端にブラウザを細くすると、グリッドがヘシャげて読みにくくなることが分かるかと。

そこでレスポンシブ・レイアウトの登場です。

レスポンシブなレイアウト

レスポンシブ・レイアウトでは、フレキシブル・レイアウトのように画面サイズに対して線形比率でレイアウトするのではなく、一定の閾値(ブレーク・ポイント)を堺にスタイルを切り替えることで、更に柔軟な構成を実現します。

まずは、実際に動作するサンプルを見てみましょう。

レスポンシブ・レイアウト・サンプル (A List Apart)

ブラウザサイズを変えていくと、ある地点でレイアウトが変わることがわかると思います。たとえば小さくしていくとサイドバーとコンテンツが縦に並んだり、画像の配置が変わったりといった具合です。この切り替わる境界点が「閾値」の部分です。

更に注目して欲しいのは、依然としてフレキシブル・レイアウトの動作も残している点です。閾値内でのレイアウトには、また従来のテクニックを組み合わせることが可能になっています。

これであれば、例えば同じスマートデバイスでもiPhoneとGalaxy Tabのように大きさが異なるディスプレイで、あるいは縦横の切替で、それぞれに最適な見せ方をすることができます。

次に、具体的な実装を見て行きましょう。

メディア・クエリー

元々はCSS2.1から登場した登場したメディア・タイプが、「デバイスによってスタイルを切り替える」という発想のスタートだったと思います。

実際に多くのメディアタイプが定義され、可能性を感じさせる仕様でした。しかし、メディア側の実装がなかなか追いつかず、実質的にはprintくらいしか使われていないと思います。

そこで登場したのが、考え方を引き継いで、より柔軟な実装を可能にした「メディア・クエリー」です。

メディア・クエリーは、メディア・タイプのようにデバイス依存のクラスを作成するのではなく、レンダリングするデバイスのサイズや性能を調べ、それを基に適用するスタイルを切り替えるものです。例えば次のコードは、iOS、Android、PCなどを問わず、出力先がスクリーン(プリンタなどではなく)で、デバイスの横幅が480px以内であればshetland.cssを適用するという意味になります。

この例では、960×480のスマートフォンを縦に持っている時は、横幅が480pxなのでスタイルが読み込まれます。しかし、横に持ち替えると条件に合致しなくなるので、この行は無視されるようになります。

こうしたことは、近年はJavaScriptを用いて実現するのが常套でした。しかし、メディア・クエリーの実装が進んできたことで、こちらを使えば更に解像度や色数など、更に進んだ機能にも対応できます。

またメディア・クエリーは、スタイルシート自体を切り分けるだけでなく、CSSファイルの中に記述することも可能です。

@media screen and (max-device-width: 480px) {
  .column {
    float: none;
  }
}

更に、importの記述により切り分けることも出来ます。

@import url("shetland.css") screen and (max-device-width: 480px);

特定のデバイスを見分けて切り分けるよりも、その特性にあわせたスタイルを適用する方が合理的であるという考え方を基に、こうした機能は実装されました。

レスポンシブ・レイアウトは、このメディア・クエリーを活用して多種多様なデバイスで最適な表示を実現するようデザインします。

次回で、具体的な実装方法を見ていきます。

Related posts:

1. [Design] Responsive Layoutを学ぶ(2)

Prezi日本語マニュアル

Preziは、無料で使える新しいタイプのプレゼン作成ツールです。PowerPointとは発想が異なり、プレゼン全体を一枚の大きな模造紙のように見立てて、その中を移動して行くようなイメージです。

最初にこのツールを見たのが2009年の1月でした。自分と仕事をしたことのある人は分かると思うのですが、ホワイトボードの前に陣取って全体像を描きながら説明するのがスタイルの自分には、非常にシックリくるツールです。当時は日本語が使えずに利用機会は無かったのですが、その後、限定的ではありますが日本語も使えるようになったので、徐々に利用が増えていきました。

単に「ちょっとカッコイイ感じのプレゼンが作れるツール」ではなく、ツールが思考の方を引っ張る好例ではないかと思っています。今自分はフリーで仕事をしていますが、以前のようにメンバーが居る立場であれば、ロジカルに物事を考える練習としてでも使わせてみたいななどと考えながらドキュメントを作りました。

興味を持ったら是非、ちょっと触ってあきらめずに、一本プレゼンを作ってみて下さい。
きっと、プレゼンの組み立てそのものが変わると思います。

No related posts.

Mandlin – QuickSilver風 ウェブナビゲーションツール

詳しい使い方はリンク先を見ていただくとして、YubNub+QuickSilverといった風の、様々な検索エンジンをキーボードベースで操ることのできるツールです。

自分が欲しくて作ったものなので使い勝手にはそれなりに満足していますが、なにしろ呼び出しにマウスを持ってクリックしなければいけないのが、なんとも残念な点で。せめてポップアップを開くAPIがあればショートカットキーもどきも出来なくは無いのですが… ポップアップではなく、コンテント・スクリプトでウインドウから描画してタブのコンテンツ内で表示させることも考えましたが、他人の家にあがりこむような感じにちょっと抵抗があったので、とりあえず由としておきます。

作成にあたって気づいた点など、徐々に リファレンス の方で更新していければと思っています。

Related posts:

1. [Chrome Extension] APIリファレンスの日本語訳

今回、勉強がてら公式のAPIドキュメントを日本語訳してみたので、公開しておきます。

Google Chrome Extension API 日本語リファレンス

馴染みのあるWeb技術ばかりで出来ているので、チュートリアルに沿ってひとつ作ってみれば、簡単に理解できました。あとはガイドを斜め読みしながら出来ることをおさえておき、作りながら必要にあわせてAPIリファレンスをひいてみる感じで。

まだ出来ることも限られていますが、プロセスが分かれていることもあり軽量で快適です。なかなかFFから移行できずにいたのが、おかげで最近はすっかりChromeメインで使っています。

というわけで幾つか作ってみたのですが、どうやら ギャラリーページのバグ でアップロードできず… いずれ問題が解決したら公開しようと思います。

作成途中で気づいたTipsなどもあるので、オリジナルのコンテンツも追加していく予定です。

Related posts:

1. [Chrome Extension] QuickSilver風の拡張機能

商業的利用やプロモーションのためにツイッターを利用する行為は許可されています。興味のあるユーザーとの間に、互いに価値のある関係を作るためにツイッターを利用する場合などです。ところが、自分のアカウントやサイトなどに注意を引くためだけに、ユーザーをフォローする行為はスパムとして扱われる可能性があります。まったく同じものを宣伝、または販売促進するためにたくさんのアカウントを登録することもスパムとして扱われる可能性があります。また本物ではない＠付きのつぶやきを投稿することや、検索結果に表示するためだけに投稿することもスパムとして扱われる可能性があります。さらに、つぶやきに関係のないリンクを貼ったり大勢のユーザーがあなたをブロックした場合などもスパムとして扱われる可能性があります。

ここにはハッシュタグに関する記述はありません。

もう一息、英語の方のヘルプフォーラムを調べてみたところ、それらしいものを見つけました。これによると、次のような行為がイエローカードに当たるようです。

• 同じ、或いは似たような呟きを繰り返す。
• 同じ、或いは似たようなリンクを繰り返し貼る。
• 同じ話題の単語、或いはハッシュタグを乱用する。
• 自動化された呟きや返信を送る。
• キーワードを基にした似たようなメッセージを送るボットやアプリケーションを使う。
• 複数のアカウントから似たようなメッセージを投稿する。
• 頻繁にフォロー/フォロー解除を繰り返す。

自分はハッキリは言われませんでしたが、ラグビー関連の話題を持ち出す際に慣例として使っていた #rugby が「同じハッシュタグの乱用」に当たったのではないかと思います。興味の無い人が読まなくて良いように呟きの先頭につけていたのですが、今後は止めにします。(アカウント分けた方が良いのかな…)
なお、「状況を改善して欲しい」とお願いしたところ、今朝から検索にヒットするようになりました。

どうやらTwitter検索八分は、完全にスパムアカウントとして凍結する前の「執行猶予」のようなもののようです。
「別に検索されなくてもいいや」としていると、場合によってはアカウント自体を停止されてしまうかもしれません。
気になる人は、エゴサーチで自分の発言がヒットするか試してみることをお勧めします。

No related posts.