ブログヘラルド経由の情報で、Facebookが新しいタイムラインの機能をテストしているようです。
スクリーンショットは元記事に掲載されている新旧タイムラインです。上がテスト中の画面です。下のリンクをクリックすれば、さらに拡大した画面を確認できます。
ユーザー名やユーザー画像下に表示されているユーザー情報（生年月日・職業など）は情報がカバーに表示されるようです。また、「友人」「写真」「地図」「いいね！」はサムネイルからアイコンに変わってユーザー画像右に並ぶようです。
「Summary」にはユーザータイムラインの重要なイベントが掲載されるようです。
テストはユーザータイムラインのみのようですが、いずれFacebookページも変更になりそうな予感がします。
WordPressでスラッグが自動で（勝手に）変更される場合の対処について、情報展開します。
固定ページなどで「スラッグ」に「news」と設定しました。が、自動保存されたあとのパーマリンクの末尾が「news」ではなく、「news-2」になってしまいます。
また、公開後は「スラッグ」の内容も「news-2」に変更されてしまいます。「スラッグ」の内容を「news」に戻しても変更できません。
「news-2」「news-3」という風に、末尾に番号が付与されるのは、同じスラッグの記事がすでに存在しているのが原因です。
スラッグを変更できるようにするには、同じスラッグの記事のスラッグ名を変更するか、その記事が不要であればゴミ箱に移動したあと、完全に削除します（下）。
完全に削除しないと同じスラッグが存在しているとみなされます。
そもそも、スラッグの末尾に番号が自動付与されて「あっ」と思ってしまうのは、次のような操作手順が原因ではないかと思われます（私がそうでした）。
WordPressではタイトルを入力して、そこからフォーカスが外れると「下書きを保存しました」というメッセージを表示し、記事データがデータベースに保存されます。
つまり、この「データベースに保存される」という動作を把握していなかったのが問題を発生させた真の原因です。
普段MTを使っているせいもありますが、MTでは「保存」をクリックしない限り正式なデータとして保存されないので、そこで勘違いしてしまったようです。
なお、スラッグの末尾に番号が自動付与されるのは全然構いませんが、スラッグを変更して保存または更新したときに
みたいなメッセージを出してくれるといいかもしれません。そうすると表示するメッセージに枚挙に暇がなくなるかもしれませんが。
話がそれますが、調べていたところ「カテゴリスラッグはマルチサイトモードでは変更できない」という記事を見つけましたので備忘録で掲載しておきます。
共著「Facebookデザインプロフェッショナルガイド」発売と「Facebook Power Session 2012」のお知らせです。
本書は、多分大好評の「Facebookページプロフェッショナルガイド」の制作編を抜き出し、内容の最新化およびパワーアップを図ったものです。
この本が記念すべき10冊目の執筆となります（とりあえず脱稿しました）。
Facebookデザインプロフェッショナルガイド ※カバーイラストラフです
本書と同時に、Facebookのマーケティング編となる「Facebookマーケティングプロフェッショナルガイド」も発売されます。
Facebookマーケティングプロフェッショナルガイド ※カバーイラストラフです
書籍は2012年7月中旬発売予定です。次にお知らせする「Facebook Power Session 2012」の開催日が最短となる予定です。
書籍刊行と連動して、セミナーが開催されます。
以下、「Facebook Power Session 2012」告知ページからの引用です。
Facebookページへのタイムラインの導入、「App Center」の発表など、Facebookをめぐる状況は日々変化しています。企業のFacebook活用が当たり前になった現在、ただ活用するだけでなく、Facebookの変化・進化にどう対応していくかとともに、いかに確実に「結果」を出し、その成果を持続していくかが喫緊の課題となっています。
そこでマイナビでは、Facebookの運用・マーケティング面での活用ポイントを解説した『Facebookマーケティング プロフェッショナルガイド』、同様に制作・デザイン面のポイントを解説した『Facebookデザイン プロフェッショナルガイド』の同時刊行を記念して、2冊の著者陣によるセミナーを開催することにしました。
Facebook活用のポイントから実例、アプリ活用やスマートフォンへの対応、運用や効果測定など、いま時点で知っておきたいFacebookのノウハウを1日で聞くことができる貴重な機会ですので、ぜひご参加ください。
開催概要は次のとおりです。
ということで、Facebookに興味のある方は是非ご参加ください。
現在発売中の「Facebookページプロフェッショナルガイド」は、4刷も売れ行き好調で、残るは市中在庫のみらしいです。
こちらもよければどうぞ。
Movable Typeで最適な画像ファイルタイプを選択する「ImageTypeOptimizerプラグイン」を公開します。
ちょっと変わったプラグインですが、要はSEO対策用です。
このプラグインでは、記事本文に埋め込まれたimg要素の画像について、異なる画像タイプがサーバ上に存在する場合、最適なサイズの画像タイプを選択します。
例えば、サーバ上に次のような「img1」「img2」という画像ファイルがあり、それぞれjpgとpngの2種類の画像タイプがあると仮定します。
これとは別に、ブログ記事本文で次のようなimg要素を記述しているとします。
「img2」のファイルサイズはpngの方が小さいので、「img2」のimg要素には「img2.png」を設定した方がページ表示速度が速くなります。
が、それをひとつひとつ手作業で行うのは現実的ではありません。
このプラグインを適用すれば、記事本文に埋め込まれたimg要素の「img2」の拡張子を一発で「.jpg」から「.png」に変換します。
操作方法は、記事一覧画面で該当する記事を選択し、「画像ファイルタイプの最適化」を選択するだけです（再構築は別途必要）。
実行すると、さきほどの記事のimg要素の拡張子が最適なサイズのものに書き換わります。
で、この記事だけを読むと「異なるファイルタイプの画像をどうやって用意するんだ？」という疑問がわくと思います。
異なる種類の画像は、以前紹介した「ブラウザから実行可能な画像形式一括変換ツール」で簡単に作成できます。
画像サイズは画像ファイルタイプによって違いがあり、写真やグラデーションのように色調が連続して変化する画像はjpg、そうでない場合はgifやpngの方がファイルサイズが小さくなる傾向にあるようです。
同じファイルタイプでファイルサイズを最適化させるツールも色々出回っていて色々試してみましたが、サイズの最適化はファイルタイプを変える方が効果が大きいようです（というか、ファイルタイプを替えずに同等の効果を出せる方法がみつかってません）。
で、ブログ記事を作り、画像を埋め込むときに、ファイルサイズを考えてgif/jpg/pngを使い分けている場合は別として、常に同じファイルタイプで作り、最適化されていない（過去記事の）画像が大量にアップロードされていることもあると思います。
このプラグインは、そのようなウェブサイトの最適化を目指すものです。
MT5.1版：1050円/1インストールMT（動作確認後、購入してください）
下記のリンクをクリックして、プラグインアーカイブをダウンロードします。
プラグインアーカイブを展開し、中にあるImageTypeOptimizerフォルダごと、Movable Type のアプリケーションディレクトリのpluginsディレクトリにアップロードします。
システム管理画面のプラグイン設定画面で、「ImageTypeOptimizer～」が表示されればインストール完了です。
このプラグインでは、変換を実行した画像について次のようにログに出力します。
理由は、拡張子が異なる同一ファイルが大量にある状態では、ディスクをそれなりに圧迫しています。変換を実行したファイルが分かればどちらを削除すれば良いかが分かります。
ログ出力を抑止するには、該当のブログまたウェブサイトのプラグイン設定画面で「ImageTypeOptimizer～」→「設定」をクリックし、「変更したURLをログ出力する」のチェックをはずしてください。
Facebookのアプリ開発でJavaScript SDKをテストできる「JavaScript Test Console」について紹介します。
文字通り、Facebook上でJavaScript SDKをテストするためのコンソールで、テキストエリアにFacebookアプリ用のJavaScriptコードを書いて実行させるというものです。
テキストエリアにはアプリ（HTML）の内容を丸ごと記述すればいいようです。その際、JavaScript SDKの読み込みは不要です。
最初は「Status」が「not_authorized」になっているので、「Login」をクリック。
Rellというアプリのログイン画面が表示されるので「Facebookでログイン」をクリック。
なお「このアプリによるFacebookタイムラインへの投稿の公開範囲」というのがあるので、テストを行う場合は、ログイン前に「自分のみ」を選択しておいた方がいいでしょう。
これで「Status」が「connected」になりました。その右にある「Disconnect」をクリックすればRellアプリからログアウトします。「Logout」をクリックするとFacebookからログアウトされるので注意しましょう。
まずサンプルで動作を確認してみましょう。テキストエリア下にある「Examples」をクリック。
「account-info」をクリックします。他にも多くのサンプルが用意されています。
クリックすると、前の画面に自動的に戻って、テキストエリアにサンプルコードが表示されます。また同時に実行内容がテキストエリア下に表示されます。
実行後、テキストエリア右にはこのようなものが表示されます。
三角マークをクリックすると内容が表示されます。これは実行プログラムの中に埋め込まれた「Log.info()」、つまりログが表示されるようです。
「Log.info()」とログの内容はスクリーンショットのような対応になっています。
ページをリロードすれば、Rellアプリのログイン状態以外はすべてクリアされます。
ログのみをクリアしたい場合は、ログのエリアにマウスをポイントすれば「Clear」が表示されるので、それをクリックします。
サンプルでかなりまかなえそうですが、プログラムを手入力する場合の使い方も紹介します。
簡単なところで、次のような「いいね！」ボタンのxfbmlを入力します。手入力した場合は「Run Code」をクリックします。
これで実行されました。
サンプル・手入力にかかわらず、「Run Code」をクリックすれば何回でも実行できます。
実行場所を変更するには、テキストエリア下にあるプルダウンメニューから「Website」「Canvas」「Page Tab」のいずれかを選択します。
選択すると同時にそのページに移動して、同じようにプログラムを実行することができます。
「Save Code」をクリックするとコードが保存されるようです。が、どこに保存されたコードがどうやって再利用できるかは不明です。
Movable TypeのMTEntryIfCategoryタグとMTIfCategoryタグの違いについて調べてみました。これはMTQにあがっていた質問の回答です。
公式サイトのMTIfCategoryタグの説明は次のようになっています。
コンテキスト内に指定されたカテゴリが含まれる、またはアクティブなブログ記事が指定されたカテゴリに属している場合に有効になる条件タグです。
公式サイトのMTEntryIfCategoryタグの説明は次のようになっています。
コンテキスト内に指定されたカテゴリが含まれる、またはアクティブなブログ記事が指定されたカテゴリに属している場合に有効になる条件タグです。MTIfCategoryブロックタグと異なる点は、コンテキスト内のブログ記事に対してのみ適用する点です。
公式サイトに記載はありませんが、ソースコード上、このタグは非推奨になっています。
１項と２項の説明はおいといて（笑）、概ねつぎのような違いがあるようです。
以下、サンプルです。
MTIfCategoryタグは、カテゴリコンテキストとなるテンプレートで利用できます。
<mt:TopLevelCategories>
<$mt:CategoryLabel$>
<mt:IfCategory name="foo">
（fooカテゴリの処理を記述）
</mt:IfCategory>
<$mt:SubCatsRecurse$>
</mt:TopLevelCategories>あるいは、ブログ記事コンテキストとなるテンプレートでも利用できます。
<mt:Entries>
<mt:EntryTitle>
<mt:IfCategory name="foo">
このブログ記事はfooに属しています
</mt:IfCategory>
</mt:Entries>カテゴリアーカイブ・ブログ記事アーカイブ内で次のように記述することもできます。
<mt:IfCategory name="foo">
（fooカテゴリの処理を記述）
</mt:IfCategory>一方、MTEntryIfCategoryタグは、MTEntriesタグなど、ブログ記事コンテキストとなるテンプレートでのみ利用できます。
<mt:Entries>
<$mt:EntryTitle$>
<mt:EntryIfCategory name="foo">
このブログ記事はfooに属しています
</mt:EntryIfCategory>
</mt:Entries>またはブログ記事アーカイブ内で次のように記述します。
<mt:EntryIfCategory name="foo">
このブログ記事はfooに属しています
</mt:EntryIfCategory>３項の説明で、ブログ記事コンテキストではMTIfCategoryタグ・MTEntryIfCategoryタグのどちらを使っても同じ動作になるようですが、以下のサンプルでは動作に違いがありました。
あるブログ記事「test」が、次のように2つのカテゴリ「foo」「bar」に属していると仮定します。プライマリカテゴリは「foo」です。
このような状態で次のようにカテゴリコンテキストとブログ記事コンテキストが入れ子になったテンプレートでMTIfCategoryタグ使うと、ブログ記事「test」の処理では、「このブログ記事はfooに属しています。」のみが表示されます。
<mt:TopLevelCategories>
<mt:CategoryLabel>
<mt:Entries>
<mt:EntryTitle>
<mt:IfCategory name="foo">
このブログ記事はfooに属しています。
</mt:IfCategory>
<mt:IfCategory name="bar">
このブログ記事はbarに属しています。
</mt:IfCategory>
</mt:Entries>
<$mt:SubCatsRecurse$>
</mt:TopLevelCategories>ところが、MTEntryIfCategoryタグを使うと、「このブログ記事はfooに属しています。」と「このブログ記事はbarに属しています。」の両方、つまりブログ記事が属しているすべてのカテゴリが対象になります。
<mt:TopLevelCategories>
<mt:CategoryLabel>
<mt:Entries>
<mt:EntryTitle>
<mt:EntryIfCategory name="foo">
このブログ記事はfooに属しています。
</mt:EntryIfCategory>
<mt:EntryIfCategory name="bar">
このブログ記事はbarに属しています。
</mt:EntryIfCategory>
</mt:Entries>
<$mt:SubCatsRecurse$>
</mt:TopLevelCategories>カテゴリコンテキストでMTIfCategoryタグの場合：プライマリカテゴリを対象
上記以外の場合：全カテゴリを対象
これは内部の実装でこのような処理になっているようです（間違っていたらすいません）。
どちらのテンプレートも「type="primary"（指定したカテゴリがプライマリの場合）」または「type="secondary"（指定したカテゴリがプライマリ以外の場合）」を指定できます。
<mt:TopLevelCategories>
<mt:CategoryLabel>
<mt:Entries>
<mt:EntryTitle>
<mt:IfCategory name="foo" type="primary">
このブログ記事はfooに属しています。
</mt:IfCategory>
<mt:IfCategory name="bar" type="primary">
このブログ記事はbarに属しています。
</mt:IfCategory>
</mt:Entries>
<$mt:SubCatsRecurse$>
</mt:TopLevelCategories>このモディファイアを適用した場合は、どちらのテンプレートタグも同じ動作になるようです。
次のように、MTEntriesタグにcategory/categoriesモディファイアを使った場合、
<mt:Entries category="foo">
<$mt:EntryTitle$>
</mt:Entries>MTIfCategoryタグやMTEntryIfCategoryを次のように使えば、出力は同じになると思います（間違ってたらすいません）。
<mt:Entries>
<mt:IfCategory name="foo">
<$mt:EntryTitle$>
</mt:IfCategory>
</mt:Entries>ただし、後者はすべてのブログ記事を取得してから判定するため、再構築のパフォーマンスは前者の方がいいのではないかと思います。
言い換えると、後者のような書き方は通常、すべてのブログ記事を対象にして、その中で個別にカテゴリを判定したい場合に用いるのが適切かと思います。
特定のカテゴリのみで最初からフィルタリングしたい場合は前者を用います。
2010年4月頃、Googleが検索結果表示順位のアルゴリズムにウェブページの読み込み速度を採用するという情報が流れましたが、本当にページ読み込みが早い方がGoogle検索順位が上がるのでしょうか。
ということで、訳あってこのブログでページ速度の改善を実施しましたので、Google検索順位ではありませんが、PV（ページビュー）やGoogle検索数がどのように変わったかをお伝えします。
結論から申しますと、Google検索数は増加したようです。が、「検索数が増加した」ということだけで、検索順位が上がったかどうかは未確認のため不明です。
ちなみに、当ブログでは検索トラヒックの約65%がGoogleからの流入です。青がグーグル・緑がYahoo!です。
表示速度改善を行うきっかけになったのは、4月の新サーバ移転がきっかけです。
移転前はさくらインターネットの「マネージドサーバ」で、そこから同じさくらインターネットの「ビジネスプロ」に移転、つまり下位のプランに移りました。
その後、わずかですがPV（ページビュー）が下がりました。
まずはサーバ移転前後のPV推移をご覧ください。赤線はサーバ移転前と移転後の差を分かりやすくするために描いてます。4月の移転から微妙にPVが下がっているのが分かります。3月までは12000PVを超える日が結構ありましたが、4月から超えなくなりました。
（クリックすれば拡大します）
これだけでは何が原因か分かりにくいので、「トラヒック」→「すべてのトラヒック」で「参照元/メディア」から「Google」を選択し、Googleだけのトラヒックに絞ったのが下のグラフです。4月のサーバ移転以降、明らかに右肩下がりになっています。ブログのデザインは一切変更していません。
（クリックすれば拡大します）
ということで、「何か対策しないとまずい」と思い立って、表示速度の改善を行いました。実際に何をやったかは後で書きます。まずはグラフの推移をご覧ください。
まず、表示速度改善前後のPV推移です。速度改善してからPVが増加しています。
（クリックすれば拡大します）
次に「トラヒック」→「すべてのトラヒック」で「参照元/メディア」から「Google」を選択し、Googleだけのトラヒックに絞った推移です。こちらは明らかに増加しているのが分かります。
（クリックすれば拡大します）
改善したのは、とりあえず次の項目です（具体的な数値がなくてすいません）。
実施時にはソーシャルブックマークボタンも外しました。が、外し過ぎてSMSからのトラヒックがなくなるのもまずいと思い、今は元に戻しています。
サイドバーに表示していた「はてなブックマークカウンタ」とか「なかのひと」とか、読み込みに時間がかかっていたものははずしています。5つくらいあったバナー画像も読み手には不要なのでとっぱらいました。
体感ですが、おそらく改善前後で2秒程度は違っていると思います。
2012/05/31追記
ウェブマスターツールの「Labs」→「サイトパフォーマンス」のデータで確認したところ、2秒ほど短縮されていました（下）。
（クリックすれば拡大します）
冒頭にも書いたとおり、表示速度が速くなったことで本当にGoogle検索数が増加したのかどうか、この情報だけではなんともいえないかもしれません。
改善後の投稿記事がたまたまGoogle検索に多くヒットするようになったという可能性もありますし、何もしなくてもPVは復活したかもしれません。
また他にも要因があるかもしれないので、話半分くらいで読んでもらえればと思います。
根本的に何か勘違いしているとか、「あのデータが不足しているよ」とかありましたらつぶやいてください。
古い情報かもしれませんが、Windowsでタスクバーの順番を入れ替えられる「Taskbar Shuffle」を紹介します。
文字通り、Windowsのタスクバーに表示されたタスクボタンの順番を入れ替えられます。ドラッグ＆ドロップで入れ替えられるので非常に便利です。
動作は下の動画でご確認ください。
「Taskbar Shuffle」はWindows Vista/XP/2000などが対応しています。Windows 7はデフォルトで並べ替え可能なので不要かと思います。
「Taskbar Shuffle」のページにある「32-bit Taskbar Shuffle v2.5」または「64-bit Taskbar Shuffle v2.5」をクリック。
ダウンロードしたファイルをダブルクリックして実行。一応、以下にインストールウィザードを掲載しておきます。
ウィザードが開始するので「Next」をクリック。
「I agree the agreement」をクリックして「Next」をクリック。
「Next」をクリック。
インストールフォルダを選択して「Next」をクリック。
スタートメニュー名を入力して「Next」をクリック。
「Install」をクリック。
インストールが完了しました。「Finish」をクリック。
「スタート」→「Taskbar Shuffle」でタスクトレイに常駐すれば起動完了です。これでドラッグ＆ドロップができるようになります。
ということで、Windows VistaやXPを使っている方、いかがでしょうか。
Google ChromeでサイトパフォーマンスのボトルネックをチェックできるChrome拡張「PageSpeed」を紹介します。
この拡張を利用すれば、「ブラウザのキャッシュを活用する・圧縮を有効にする・CSSスプライトに画像をまとめる」といったパフォーマンスの最適化のための項目や、その詳細なデータを確認することができます。
Using PageSpeed Insights for Google Chromeのページにある「Install PageSpeed Insights」またはその左のアイコンをクリック。
ページ右側にある「CHROMEに追加」をクリック。
「追加」をクリック。これでインストールが開始します。
インストールが完了しました。
Windowsの場合、測定したいページを表示した状態で「F12」をクリックして、表示されたデベロッパーツールの右側にある「PageSpeed」をクリック。
「分析」をクリック。
分析が開始します。
分析結果です。中央には提案の概要、左側には優先度（高・中・低）別の対策が表示されます。
左側の項目をクリックすれば、詳細な情報が中央に表示されます。
以前のバージョンではスコア（100点満点で何点か）も表示されていたようですが、確認したバージョンではその表示はありませんでした。
Linuxコマンド「gzip」の使い方を紹介します。
ネットで色々調べた中では、オプション解説のバリエーションはこの記事が一番多いと思います（笑）。各オプション動作については、サーバで実行して確認しています。
指定したファイルを圧縮・解凍します。圧縮後の拡張子は「.gz」になります。
オプションは次の通りです（「-h」そのままです。手抜きですいません）。Linuxのディストリビューションによっては異なるかもしれません。サーバはFreeBSD 7.1で確認しています。
| オプション | 代替オプション | 意味 |
|---|---|---|
| -1 | --fast | 圧縮時間が最も早い（圧縮率が最も低い） fastest (worst) compression |
| -2 .. -8 | 圧縮レベルを指定 set compression level | |
| -9 | --best | 圧縮率が最も高い（圧縮時間が最も遅い） best (slowest) compression |
| -c | --stdout --to-stdout | 標準出力し元ファイルを維持 write to stdout, keep original files |
| -d | --decompress --uncompress | ファイルを解凍 uncompress files |
| -f | --force | 強制上書き force overwriting & compress links |
| -h | --help | ヘルプ表示 display this help |
| -k | --keep | 実行中にインプットファイルを削除しない don't delete input files during operation |
| -l | --list | ファイル情報を表示 list compressed file contents |
| -N | --name | 元ファイル名とタイムスタンプを保持または復元 save or restore original file name and time stamp |
| -n | --no-name | 元ファイル名とタイムスタンプを保持または復元しない don't save original file name or time stamp |
| -q | --quiet | 警告を出力しない output no warnings |
| -r | --recursive | ディレクトリ内のファイルを再帰的に処理 recursively compress files in directories |
| -S .suf | --suffix .suf | 「.gz」の代わりの拡張子を利用 use suffix .suf instead of .gz |
| -t | --test | 圧縮ファイルをテスト test compressed file |
| -V | --version | バージョン表示 display program version |
| -v | --verbose | 詳細を表示 print extra statistics |
オプションの具体的な使い方は２項以降をご覧ください。
ファイルfoo.txtを圧縮するには、次のようにします。
%gzip foo.txtなお、gzipでファイルを圧縮すると、圧縮後に元ファイルが削除されます。削除されないようにするには４項を参照してください。
ファイルfoo.txt.gzを解凍するには、「-d」オプションをつけます。
%gzip -d foo.txt.gzなお、ファイルを解凍すると、解凍後に圧縮ファイルが削除されます。削除されないようにするには４項を参照してください。
また、解凍ファイル名の末尾に「.gz」をつけなかった場合、「.gz」がついたファイルを探して解凍するようです。
次のように、gzipコマンドに「-c」オプションをつけ、リダイレクトで圧縮（または解凍）ファイル名を指定します。
圧縮の場合
%gzip -c foo.txt > foo.txt.gz解凍の場合
%gzip -cd foo.txt.gz > foo.txt「-c」は圧縮（または解凍）結果を標準出力するオプションで、標準出力の内容をリダイレクトすることで、元ファイルを残したままgzファイルを作成できます。
あるディレクトリ配下にあるファイルすべてを圧縮（または解凍）したい場合は、「-r」オプションをつけ、ディレクトリ名を指定します。
%gzip -r hoge圧縮率を上げるには「-数字」で指定します。値の範囲は「1」から「9」で、「9」にすると圧縮率が最大になります。ただし圧縮時間がかかります（＝CPU使用率に影響します）。
%gzip -9 foo.txt仕事では常に「-9」をつけてます。
圧縮したままファイルの内容を見るには、「-cd」オプションをつけます。これで解凍内容を標準出力します。
%gzip -cd foo.txt.gzパイプでlessを連結すれば、スクロールができて便利です。
%gzip -cd foo.txt.gz | lessまたは「zcat」コマンドを利用します。
%zcat foo.txt.gzすでに圧縮ファイルが存在する場合に上書きしたい場合は、「-f」オプションをつけます。
%gzip -f foo.txtこのオプションをつけないでgzipを実行すると、次のように上書き確認のメッセージが表示されます。
foo.txt.gz already exists -- do you wish to overwrite (y or n)?圧縮ファイルの圧縮率・サイズを表示するには「-l」をつけます。
%gzip -l foo.txt.gz
compressed uncompressed ratio uncompressed_name
1083 3296 67.1% foo.txt圧縮・解凍の詳細を表示するには、「-v」オプションをつけます。
圧縮の場合
%gzip -v foo.txt
foo.txt: 67.1% -- replaced with foo.txt.gz解凍の場合
%gzip -dv foo.txt.gz
foo.txt.gz: 67.1% -- replaced with foo.txt圧縮ファイルをテストするには「-t」オプションをつけます。「-v」オプションをつければ「OK」などが表示されます。
%gzip -tv foo.txt.gz
foo.txt.gz: OK拡張子を「.gz」以外のものにしたい場合は「-S 拡張子」をつけます。例えば「.gzip」という拡張子にしたい場合は次のようにします。
%gzip -S .gzip foo.txt独自の拡張子にした場合、を解凍する場合も「-S 拡張子」をつける必要があります。
%gzip -d -S .gzip foo.txt.gzipまたは
%gzip -d -S .gzip foo.txt
iPhoneのiOSのアップデートはパソコン経由（iTunes）を使う方法がありますが、単体でアップデートすることも可能です。
ということで、パソコンを使わずにiPhoneのiOSをアップデートする方法を紹介します。
エントリーで利用したiPhoneはソフトバンクのiPhone4Sで、5.1から5.1.1のアップデートを元に記事をおこしています。
iPhoneを電源を接続した状態にします。
そうでない場合、バッテリー残量が50%以上あるかどうか確認します。50%以下では、iOS最新版のダウンロードはできても、その後のインストールに進めないようです。
iPhoneをWi-Fiに接続した状態にします。
WiFiを使うのは、auのサイトの説明では「データ通信料を発生させないため」とありますが、3Gでも可能かもしれません（間違ってたらすいません）がダウンロードに時間がかかる可能性があります。
WiFi機器を持っていない方は、各キャリアのWiFiアクセスポイントを使う手がありますが、それはまた別の設定が必要になります。このエントリーではそこまで書ききれないため、別途エントリーしたいと思います。すいませんが、ここでは「WiFiが利用可能」という前提で話を進めます。
「設定」→「WiFi」をタップ。
「オン」にするとWiFiネットワークが表示されるので、該当のスポットをタップします。
チェックマークがつけば接続成功です。
WiFiに接続されている場合は3Gより優先されると思いますが、本当につながっているか気になる場合は、「一般」→「ネットワーク」→「モバイルデータ通信」を「オフ」にして、ブラウザから任意のサイトにアクセスできることを確認してみてください。
「設定」→「一般」をタップ。
「ソフトウェア・アップデート」をタップ。
アップデート確認中です。
アップデートがある場合、「ダウンロードしてインストール」をタップ。
利用条件の「同意する」をタップ。
アップデートのダウンロードが開始します。
アップデートの準備が開始します。
インストール確認が表示されるので、「インストール」をタップ。タップしなくても10秒程度で自動的に開始します。
アップデート検証中です。
このあとアップデートが開始します。キャプチャがとれなくなりますが、5.1から5.1.1のアップデートでは、
ローディング画像
↓
アップルのロゴ表示
↓
アップルのロゴの下にローディング画像表示
↓
アップルのロゴ表示
↓
アップルのロゴの下にローディング画像表示
という具合に画面が切り替わりました。全体で20分程度で完了しました。アップデートが完了すると、次のようにロック画面が表示されます。
「設定」→「一般」→「ソフトウェア・アップデート」をタップするとバージョンが表示されます。「設定」→「一般」→「情報」でもバージョンを確認できます。
Movable Typeの再構築時にgzip圧縮したファイルを出力する「GzipFilePublisherプラグイン」を公開します。
このプラグインでは、テンプレートの再構築時に圧縮ファイルを同時に出力します。例えばメインインデックス「index.html」を再構築した場合、「index.html.gz」も同時に出力します。
圧縮ファイルの出力有無は、テンプレートの中にある次の行で判断します。
<mt:ignore>gzip</mt:ignore>下記のリンクをクリックして、プラグインアーカイブをダウンロードします。
プラグインアーカイブを展開し、中にあるGzipFilePublisherフォルダごと、Movable Type のアプリケーションディレクトリのpluginsディレクトリにアップロードします。
システム管理画面のプラグイン設定画面で、「GzipFilePublisher～」が表示されればインストール完了です。
冒頭に記したとおり、圧縮ファイルを出力させたいテンプレートの任意の位置に、次の内容を記載してください。
<mt:ignore>gzip</mt:ignore>圧縮ファイルを出力するタイミングは、再構築で通常のファイルが出力された時点となります。出力ファイルの内容に変更がない場合は通常のファイルが出力されないのと同様、圧縮ファイルも出力されません（本プラグインのMTIgnoreタグを挿入しても、ファイル内容の変更にはなりません）。
.htaccessの作成が簡単にできる老舗のオンラインサービス「.htaccess Editor」を紹介します。
このサービスでは次の作成が行えます（2012年6月現在）。
| 操作 | 内容 | 主な使用ディレクティブ |
|---|---|---|
| ファイル一覧の拒否 | アクセスURLにindex.htmlがない場合のファイル一覧の表示・非表示を決定 | Options -Indexes Options Indexes |
| ベーシック認証 | ベーシック認証（ユーザー・パスワード入力によるアクセス）を有効にする | AuthUserFile AuthGroupFile AuthName AuthType |
| エラーページ | アクセスしたURLが存在しない場合などの代替エラーページを表示 | ErrorDocument |
| デフォルトページ | URLをスラッシュで止めたときにアクセスするファイルの優先順位を決定 | DirectoryIndex |
| WWW あり・なし統一 | アクセスしたURLのwwwあり・なしを統一 | RewriteEngine on RewriteCond RewriteRule |
| リダイレクト | アクセスしたURLを別のURLにリダイレクト | Redirect |
| アクセス制限 | 指定したURLからのアクセスを許可または拒否 | allow from deny from |
| モバイルアクセス制限 | モバイルアクセス制限機能を有効にする | allow from |
使い方は、各項目で表示されるフォームに必要事項を入力すると、.htaccessへの設定内容がテキストエリアに表示されるので、それをコピー＆ペーストするだけです。
たとえば、面倒なベーシック認証も次のように各項目を設定するだけです。
これでページ下にあるテキストエリアにずばっと表示されます。
ディレクティブが思い出せないときなど非常に便利です。
ウェブサイトのパフォーマンスを向上させるテクニックの1つに、HTTPリクエスト数を減らす方法があります。
複数のJavaScriptファイルを1つにまとめるのもその1つですが、複数のファイルを1つにまとめる作業はちょっと面倒です。
が、本エントリーで紹介するオンラインサービス「JMerge」を利用すれば、ウェブサイトで利用している複数のJavaScriptファイルを簡単にマージすることができます。
ページ内にマージしたくないJavaScriptファイルがある場合も、簡単に除外できます。
フォームの「URL:」に、ウェブサイトのURLを入力して「Continue」をクリック。
ウェブサイトで使われているJavaScriptファイルを上から順番に検索し、一覧として表示します。ここに表示されているファイルがマージ候補になります。
表示されたURLをクリックすれば、マージしたくないCDNやAdsense、Analyticsなどのコードを削除できます。
最後に「Combine them!」をクリックすれば、マージしたソースコードが表示されます（IEの場合はファイルのダウンロード）。
単にマージするだけでなく、ファイルを取捨選択できるという、かゆいところに手が届くサービスですね。
「CSS Sprite」は背景画像などの複数の画像ファイルをひとつの画像にまとめて、画像の中から表示させたい部分の座標をbackground-positionプロパティで指定するという手法です。これにより画像ファイルのHTTPリクエスト数を減らすことができます。
この手法は背景画像での利用が一般的なのですが、img要素でも利用することができるようなので、本エントリーで紹介します。
本エントリーでは、次のソーシャルブックマークボタン用の4つの画像を1つにまとめて、CSS Spriteを行ってみます。
背景画像の場合はbackground-positionプロパティでさくっと表示できるのですが、img要素として表示させるのにかなり苦労しました。ということで、コピペで使えそうなサンプルも用意しました。
「そういう場合、背景画像に変更するのが本来では？」というツッコミはなしでお願いします（笑）。
まず、スプライト画像（ばらばらの画像をひとつの画像にマージしたもの）にしたい複数の画像を、zipツールなどで圧縮しておきます。
ここでは次の4つの画像を圧縮して「sprite.zip」を作っておきます。
スプライト画像の作成には、定番の「CSS Sprite Generator」を利用します。言語が選択できるので、「日本語」を選択しておくといいいでしょう。
さきほど圧縮した「sprite.zip」を指定します。
各種設定も備忘録的に残しておきます。「重複する画像」「元画像をリサイズ」はデフォルトのままにします。
「スプライト画像設定」では、オフセットや連結方向、保存フォーマットなどを設定します。ここではスクリーンショットの設定にしました。背景画像で「repeat-x」の指定をする場合は縦方向に、「repeat-y」の指定をする場合は横方向に連結してください。
「CSS設定」もデフォルトのままとします。
「スプライト画像とCSSを作成」をクリック。
表示された画面で、CSSルールとスプライト画像のダウンロードが行えます。
ダウンロードした画像ファイルは「sprite.gif」など、適当にリネームしてください。
また、表示されたCSSルールは背景画像用です。今回は背景画像に用いるのではありませんが、利用したい値が含まれているので、どこかにメモしておきましょう。
下は完成したスプライト画像です（便宜上、枠線とパディングはCSSでつけています）。
リンクつき画像のHTMLは次のようになります。
<ul id="sbm_icon">
<li>
<a href="http://.../">
<img src="sprite.gif" width="16" height="73" class="sprite-hatena" />
</a>
</li>
<li>
<a href="http://.../">
<img src="sprite.gif" width="16" height="73" class="sprite-delicious" />
</a>
</li>
<li>
<a href="http://.../">
<img src="sprite.gif" width="16" height="73" class="sprite-livedoor" />
</a>
</li>
<li>
<a href="http://.../">
<img src="sprite.gif" width="16" height="73" class="sprite-yahoo" />
</a>
</li>
</ul>マークアップのポイントは以下のとおりです。
CSSは次のとおりです。
#sbm_icon li {
display: inline-block;
}
#sbm_icon a {
width: 16px;
height: 16px;
float: left;
overflow: hidden;
}
#sbm_icon a img {
border: none;
}
.sprite-hatena {
margin-top: 0; /* 不要 */
}
.sprite-delicious {
margin-top: -19px;
}
.sprite-livedoor {
margin-top: -38px;
}
.sprite-yahoo {
margin-top: -57px;
}a要素にwidthプロパティとheightプロパティで表示サイズを指定し、「overflow: hidden」で画像の表示範囲を制限しています。ここではすべて同じ値なので、ひとつのセレクタに丸めてますが、サイズが異なる場合は「sprite-xxx」のclass属性をa要素に格上げして、個別に指定してください。
また、classセレクタのmargin-topプロパティの値はCSS Sprite Generatorで出力したCSSのbackground-positionプロパティをそのまま使います。
スプライト画像の一番上の画像表示にmargin-topプロパティは不要ですが、一応書いておきました。
動作サンプルも用意しています。
画像のみの場合のHTMLは次のようになります。
<ul id="sbm_icon">
<li>
<img src="sprite.gif" width="16" height="73" class="sprite-hatena" />
</li>
<li>
<img src="sprite.gif" width="16" height="73" class="sprite-delicious" />
</li>
<li>
<img src="sprite.gif" width="16" height="73" class="sprite-livedoor" />
</li>
<li>
<img src="sprite.gif" width="16" height="73" class="sprite-yahoo" />
</li>
</ul>CSSは次のとおりです。２項でaセレクタに指定していたプロパティをliセレクタに移動しています。
#sbm_icon li {
display: inline-block;
overflow: hidden;
width: 16px;
height: 16px;
}
.sprite-hatena {
margin-top: 0; /* 不要 */
}
.sprite-delicious {
margin-top: -19px;
}
.sprite-livedoor {
margin-top: -38px;
}
.sprite-yahoo {
margin-top: -57px;
}こちらも動作サンプルを用意しています。
CSS Spriteの話ではありませんが、上記のサンプルでは「display: inline-block;」の指定を行っていて、過去バージョンのIEでは正常に動作しません。
その場合、次のような条件付きコメントを設定すると良いでしょう（間違っていたらご指摘ください）。
<!--[if lte IE 7]>
<style>
#sbm_icon li {
display: inline;
zoom: 1;
</style>
<![endif]-->
Facebookが2012年9月に予定している変更点について、Facebookの開発者ブログの情報をもとにお知らせします。
Platform Updates: Operation Developer Love
ソーシャルプラグインのひとつ、Live Streamプラグインが2012年9月5日に廃止されます。
開発者ブログでは「Comments Boxプラグインに置き換えてください」という告知をしています。
9月5日を過ぎてもLive Streamプラグインを設置している場合はComments Boxプラグインをレンダリングするようです。
Live StreamプラグインとComments Boxプラグインは似ていますが、次の違いがあります。
細かいですが、Commentオブジェクトのプロパティ名「likes」が「like_count」に、QuestionOptionのプロパティ名「votes」が「vote_count」に変更されます。
その他にも細かい変更があるようです。詳細は冒頭の開発者ブログ、または「Developer Roadmap」をご確認ください。
Firefox 11以降では3D表示（ページインスペクタ機能を利用）が可能です。が、どういうわけか3Dにできないケースもあるようです。私がそうでした。
ということで、Firefoxで3Dが表示されない場合の対処方法について紹介します。
対処方法は後回しにして（笑）、まずは3Dの表示方法から説明します。
メニューから「Web開発」→「調査」を選択。または画面を右クリックして「要素を調査」を選択。
ブラウザ右下に表示された「3Dビュー」をクリック。
これで3Dビューに切り替わります。マウスでドラッグすれば方向を変えられ、ホイールでズームイン・ズームアウトができます。
ところが、冒頭で述べたとおり、私の環境では「3Dビュー」ボタンが表示されませんでした。
ネットを検索しても、
「3Dこんな風に表示されました！すごい！最高！」
という、まったく苦労せずに表示されました系の情報しか見つからず、PC環境のせいと思って諦めていたのですが、最近ふと思い立って調べたところ、対処方法をみつけました。
ということで前置きが長くなりましたが、対処方法について説明します。
3Dビューにならないのは、そもそもブラウザがWebGLをサポートしていない状態にあるようです（そこまでは前回の調査でたどりつきました）。
WebGLとは、ウェブブラウザで3次元コンピュータグラフィックスを表示させるための標準仕様のことです。
WebGLをサポートしているかどうかは「Does My Browser Support WebGL?」のサイトにアクセスします。
次のように「Nay」が表示されればWebGL未サポート状態です。４項に進んでください。
ちなみにサポートされていれば「Yay」が表示されます。
FirefoxがWebGLをサポートできるようにコンフィグを変更します。
アドレスバーに「about:config」を入力。
「細心の注意を払って使用する」をクリック。
検索フォームに「webgl」と入力すると、WebGL関連のコンフィグが表示されます。
「webgl.force-enabled」「webgl.disabled」の2つの項目について、次の値にしてください。ダブルクリックすれば値が切り替わります。
次のようになればOKです。
これで再度「Does My Browser Support WebGL?」のサイトにアクセスして、「Yay」になることを確認します。
「Nay」のままの場合は、Firefoxを再起動した後にもう一度確認してみてください。
コンフィグ変更後、Firefoxを一旦終了して再起動します（再起動しないと変更したコンフィグは有効にならないようです）。
再起動後、１項の手順で「3Dビュー」が表示されれば完了です。
参考サイトは下記です。ありがとうございました。
TwitterアプリケーションをTwitterに登録する方法を紹介します。
前置きですが、以前、Movable TypeにTwitterアカウントでコメント投稿できる「TwitCommentプラグイン」というものを公開しました（下）。
公開したプラグインはサーバにアップロードしたあと、Twitterアプリケーションとして登録する必要があるのですが、公開した2011年11月から1年半ほど経って、当時の手順（Twitterのログイン画面から進む）でアプリケーションを登録しようと思ったら、まったく分かりませんでした。
ということで、本エントリーでTwitterアプリケーションを登録する手順のみ、改めて紹介します。
Twitterアプリケーションを作成し、そこにアプリケーション（URLのみ）を登録します。
Twitterの開発者ページにアクセスして「Create an app」をクリック。
Twitterのアカウントでログイン。
次の画面で次のアプリケーション情報を設定します。
開発者規約に目をとおして、その下にある「Yes, I agree」をチェック。
CAPTCHAを入力して「Create your Twitter application」をクリック。
入力内容に問題がなければアプリケーションが作成されます。
登録後の「Details」タブの下に、アプリケーション情報が表示されます。
登録後の状態ではAccess token（アクセストークン）は発行されていないので、画面下にある「Create my access token」をクリック。
Access tokenとAccess token secretが発行されました。Access levelのデフォルト値は「Read-only」のようです（後で変更できます）。
アイコンや「Application Type（さっきのAccess level）」の設定は「Settings」タブから行えます。
OAuth情報やリクエスト種別などの設定は「OAuth」タブから行えます。Access tokenとAccess token secretは値を変更できます。
登録したアプリケーションの一覧を見るには、ページ上部にある「My applications」をクリック。
こんな感じでアプリケーション一覧が表示されます。ぼかしている部分に表示されているアプリケーション名をクリックすれば、さきほどのアプリケーション設定画面に移動します。
以上です。
iPhoneやAndroidで日本語入力が激速になる（かもしれない）「フリック入力」を紹介します。
知らない人にとっては目から鱗なテクニックですが、知っている方にはきわめて当たり前の内容なので、速やかにスルーしてください（笑）。
スクリーンショットに示す「日本語テンキー」を利用します。ついでに他の入力方法も併せて紹介します。
基本的な入力方法として、「う」を入力する場合「あ」を3回タップすれば入力できます。
ケータイからスマホに切り替えたばかりの人は、この入力方法が親しみやすいのではないかと思います。
操作回数を減らす方法として、「あ」を長押しタップすると、あ行の残りの候補が表示されます。
その状態でスワイプ（ドラッグ）すれば「い」～「お」が選択できます。「う」を選択する場合は、タップした状態から上方向にスワイプ（ドラッグ）します。
最速の「フリック入力」とは、２項の方法で候補文字の表示を待たずに、フリックして文字を入力することです。
スクリーンショットは「あ」の部分を上方向にフリックして「う」を入力したところです（なれてくれば表示を見ることはないと思いますが）。
上達すれば、かなり早いスピードで日本語を入力できるようになるかもしれません。YouTubeにも多くの動画がアップされており、ざっと探したところ「分速386文字」の動画をみつけました。
ちなみにAndroid端末でも同様の入力が可能です（Android端末の方はそもそもこの記事を読まないと思いますが）。
話がそれますが、濁音・半濁音や「っ」などの促音は、文字を選択したあとに左下から選択できます。
ということで、より快適なiPhoneライフをどうぞ。
Facebookページ「小粋空間」が2000いいね！達成しました。クリックしてくれた皆様、ありがとうございます。
Facebookページ「小粋空間」
ちなみに「2000」というのはまったくたいした数字ではなく、日本語Facebookページランキングでは2012年6月11日現在で2833位です。
が、Facebookページを立ち上げたときに2000に到達すると思っていなかったので、一応記念エントリーです。
ついでに当ブログのfacebook関連記事のいいね！ランキングTOP10も掲載しておきます。
ブログ全体のいいねランキングは以下のリンクからどうぞ。
Facebookページの方は、基本的にこのブログの投稿分を反映させていますが、タイムラインにページの更新情報などもたまに投稿しています。ということでFacebookページの方もごひいきに。