投稿者: blogger323

Cubasis とは懐かしい名前で出てきたなあ

今回は Steinberg から先日リリースされた iOS 用 DAW ソフトウェア、Cubasis のファーストインプレッションです。

昔、あるところに…

Cubasis というのは実は私にとってとても懐かしい名前なのです。 その昔 AT 互換機 (DOS/V マシン！) が日本に広がり始めた頃だったと思います。 PC-9801 シリーズ用 Sound Blaster を購入した時にオマケでついていたのが Steinberg の Cubasis というソフトウェアでした。 当時は VST 登場前で MIDI のみ扱えるシーケンサーソフトウェアでした。 これをアップグレードして購入した Cubase Score 1.x (SX じゃないですよ) が私と Cubase との最初の出会いでした。

ちゃんと活用できているかは疑わしいのですが、Cubase との付き合いだけは長いのです。 そんなわけで Cubasis の名前が復活したとあっては見過ごすわけには行きません。 というか「やっぱり Cubase にデータを持って行けないとなあ」と思い、GarageBand for iOS の使用頻度が息子に負けていた私にとってこれは待望のソフトウェアです。

機能など

トラックの種類は MIDI と Audio の 2種類のみととてもシンプルです。 GarageBand のようなコードを選べば勝手にアルペジオを弾いてくれる「スマートなんちゃら」みたいな機能はありませんし、Cubase 7 のコードトラックのようなものもありません。

エフェクトについてはインサートもセンドもマスター用も使えるのは一箇所につき 3種類までです (ずっと下にあるルーティング図を参照)。 使えるのは Reverb/Delay/Chorus/Phaser/Flanger/Filter/Limiter/Compressor/Amp Sim/Overdrive/EQ と一通りは揃っています。 各エフェクターのパラメーターもシンプルですが、レコーダーとして使ってラフにミックスダウンするような使い方であれば特に問題となることはないでしょう。

レイテンシーも問題なく、返しをヘッドホンでモニターしながらのボーカル録りも違和感ありませんでした。 (インターフェイスは iXZ です。この辺詳しくないですが、インサートエフェクトがかかるのでダイレクトモニターということはないと思います。)

MIDI トラックで使用できるインストゥルメントは 70種超。 GM 音源より種類が少ないですが、キワモノを除いてベーシックなものを揃えたという感じなので、たぶん足りるでしょう。 パラメーターとしてはアタックとリリースしかいじれず、やるのであればあとはエフェクトで音色を作ることになります。 まあ、本格的に音色作りするためのものではないということですね。 外部キーボードで弾いてもけっして楽しい音ではないですし、あくまで演奏データ作成時のモニター用という感じです。 特にピアノ系は弾きやすいところまでリリースパラメータを調整した方が良いでしょう。

結局、録音、パートトラック素材作成からラフミックスまでが Cubasis の守備範囲でそれ以上のサウンドづくりは Cubase にインポートしてからということでしょうね。 Cubasis Importer を使えば、インストゥルメントやエフェクトの設定 (ただし、センドエフェクトはダメっぽい) も含めて Cubase に読み込むことができます。

逆に MIDI ファイルやオーディオファイルを PC から持ってきて使うこともできます。 MIDI トラック用のエディターはキーエディター (ピアノロール画面) しかないので、ドラムトラックはループ素材を iPad に放り込んでそれをつなげてざっとつくるというような使い方が良いかも知れません。

誰に向いている？

やはり、Cubasis の特徴は良くも悪くもシンプルということでしょう。 これについて、私はとても好意的に捉えています。 多機能な Cubase だと圧倒されてしまう人でも、この内容であれば全ての機能を把握するのは難しくないはずです。

これだけ Cubase 関連の記事を書いておいて言うのも何ですが、私はコンピューターに向かって音楽を作るのが苦手な人間です。 それよりも演奏の練習の方が好きだったりするし、記事を書くのも自分が操作を忘れないために書いていたりします。 でも、iPad + Cubasis ならば、楽器に向かって傍らに iPad を置けばすみます。 シーケンサー専用機で育った私としては懐かしい感覚です。 音楽をやるときはこういったことが結構重要だったりするのではないでしょうか。

ですので、同じようなプレーヤー系統の人には自信を持ってお勧めできます。 逆にエフェクト等の機能はあくまでもラフミックス用という感じなので、ミックス系の人にとっては微妙な気がします。 コンポーザー系ならば GarageBand とどちらが好みか、Cubase との連携が必要かで判断という感じでしょうか。(勝手に系統をつくってますがw)

他にピッタリハマるのは DAW 初心者です。 ミキシング機能という点では GarageBand は信号フロー図が必要となるような代物ではありませんが、Cubasis ではちゃんとヘルプにフロー図 (下図) が出てきます。 エフェクトも一通り揃ってますし、初心者にとって取り組みやすい数に収まっているとも思います。 基本は抑えられているので、将来パソコンを中心とした DAW 環境にステップアップしたときもまごつくことはないでしょう。 「パソコンで環境を作るとお金かかるし」という人には、まず iPad + Cubasis + 周辺機器で始めてみることをお勧めします。

effect-routing
(Cubasis のヘルプより)

価格面の話をすると、今のモバイルアプリの状況では 4,300円という価格が高く見えるかも知れません。 しかし、iPad + 4,300円 (と必要な周辺機器) で音楽制作を始めることができると考えれば納得できる範囲ではないでしょうか。 GarageBand の値付けはマーケットインフラや端末を Apple が握っているから実現できる価格であり、それと比べてしまうのは酷です。

要望など

要望もあります。 まず、この内容であればエフェクトに Tuner を付けて欲しいです。

それと、オーディオワープ (オーディオイベント伸縮機能) も欲しい。 確かに昔の感覚だとオーディオの長さが変わる方がおかしいというのもありますが、今となっては GarageBand ですらやっていることなので、ここは頑張って欲しい。 オーディオループを組み合わせて使う人も多いでしょうから。

とは言っても、私はかなり Cubasis を気に入っています。 なるべく iPad を持ち歩くようにしてみようかなと思うわけですが、そうすると iPad mini も欲しくなってしまったり…。 小さいと操作し辛いよと暗示をかけて物欲を抑えていますが、Retina 版がでたらどうなるんだろう。

WordPress のリビジョンについての間違った認識と正しい対処

WordPress のリビジョン機能は冷遇されているようで検索すれば無効化する方法がたくさん見つかります。 一方でこの機能が「使える」ものだったらやっぱり使いたいよなあ、という人も多いのではないでしょうか。 ブログ記事は書き捨てというやり方だけでなく、注目を集め反応が多かった記事に情報を追記していく場合もあるでしょう。 また、WordPress のビジネス利用も増えていますが、そうであればなおさらリビジョン管理は重要です。 そこで今回は現行のリビジョン機能の何が問題でどうすれば解決するかをまとめたいと思います。

まあ、リビジョン機能止めて別に困らないという人はそれでいいのですけれど。

まずは正しい認識を

まず、WordPress のリビジョン機能について正しい認識を持ちましょう。 あまり理解されていないように思われるのは以下の点です。

  • 自動保存は 1世代のみ
  • リビジョンが作成されるのはポストテーブル (wp_posts) 内容のみ。 wp_postmeta や wp_term_relationships などの関連テーブルは (プラグイン等を用いない限り) リビジョンが作成されない。

つまり、デフォルトの 60秒間隔自動保存でバンバンリビジョンが増えていくというわけではないです。 また、ポストテーブルのリビジョンのみ、すなわちカテゴリーやタグの付け替え履歴は残らないので、WordPress のリビジョン機能は、基本的に記事にしたテキストデータの変更履歴を取るための機能と捉えるのが良いと思います。

データベース関連についても一言言っておきます。

  • 通常の一記事表示ではインデックスを使用した検索になるので、ポスト数が増えても検索時間は比例しない。 なので、個人ブログレベルであれば、リビジョンを作成したからといって (よほど作りの悪いテーマやプラグインを使っていない限り) パフォーマンスに影響が出ることはまずない。

まあ、データベースの容量に関しては確かにリビジョンを作成することでその分使用領域は増えます。 しかし、所詮テキストデータなので、画像に比べればたかが知れています。

あっ、まさかリビジョンを作成するとそのページで使った画像まで何世代も保管されちゃう、なんて思っていたりします？ 念のために言っておきますが、それはないです。 イメージデータそのものはデータベースに入らないですし。

もう一度書きますが、リビジョンが作成されるのはポストテーブルの内容のみです。 ポストテーブルの内容を知らなければこちらで確認しておきましょう。 タグやカテゴリーの情報はポストテーブルに入っておらず、別テーブルから post_id を使ってポストテーブルを参照するようになっています。

でもリビジョン多くね？

と、ここまで読んでも「実際には多数リビジョンが出来てるし、嘘書いてんじゃねーの？」と疑っている人もいるでしょう。 確かにリビジョンが多く作成されてしまうのは事実です。 これは WordPress の以下の動作によるものです。

  1. 下書きの状態 (公開前も含む) でプレビューをするたびにリビジョンが作成される。
  2. クイック編集や一括編集でもリビジョンが作成される。

1. については思い当たる方が多いのではないでしょうか？ 公開前はプレビュー操作を行って最終的な見栄えをチェックしながら文章を調整することがあると思いますが、そこでプレビューする度にリビジョンができてしまうのです。公開された記事のプレビュー操作では自動保存リビジョンとなるのでどんなにプレビューしても 1世代なのですが、公開前だと何世代ものリビジョンができてしまいます。 たいていの場合は公開初版のリビジョンだけあればよいですよね。

2 については更に不要です。 このような編集方法を採るときはタグやカテゴリーを直す場合が多いと思うのですが、そうなるとポストテーブルの項目に変更は発生しないことが多いにも関わらずリビジョンが作成されてしまうということになってしまいます。 ですので、リビジョン比較をしても「同じ内容です」というちょっと悲しいリビジョンばかりできてしまいます。

どうすりゃいいのさ？

さて、これらの不要なリビジョンを保存せずに、意味のあるリビジョンだけ残すにはどうすれば良いのでしょう？ ちょっと考えてもどうしようもなさそうですね。 でも簡単な解決策があるんです。 それは…。

(縦に長い空白地帯)

じゃーん。 リビジョン管理用のプラグイン「Thin Out Revisions」を使えばよいのです。 以下の手順で不要なリビジョンとおさらば！

  1. あなたのサイトのプラグイン検索画面から Thin Out Revisions を検索してインストール、有効化する
  2. 「設定」－「Thin Out Revisions」とメニューを選び 3項目全て ON にして保存する

えっ？ 作者が日本人っぽい？ どっかで見たアイコン？

…実は私がつくったのです。

ステマではありません。作者による告知です！ それとこんな機能もあります。 気に入ったら是非つぶやいたり、「いいね！」したりしてください。お願いします！ お願いします！

(後半雰囲気を変わってしまいましたが、同じ著者によるものです。セッティング項目の見出しは一応読んでね。)

Cubase 7 コードトラックの使い方 (チュートリアル視聴メモ)

個人的に今回の Cubase 7 の新機能で一番気になっているのはコードトラックです。 前回の MixConsole に続いて、今回はこのコードトラックについての新機能チュートリアルビデオ視聴メモです。 Chapter 10 ですね。 (追記: 執筆時点では英語を聞き取るしかなかったのですが、2013.5 現在では日本語字幕を表示することが可能になっています。YouTube の字幕メニューで日本語を選びましょう)

訳語は日本語版画面や新機能ガイドに合わせていますが、画面とガイドで違う単語だったりする場合は画面の方に合わせています。 (というか新機能ガイドの訳は今一歩という感じです)

基本

最初はインストゥルメントトラックとコードトラックを一つずつ作成して説明します。

  • 配置されたコードイベントのコードが次のコードイベントの開始位置まで続く。(コードイベント同士で重なりがある場合も同様で開始位置のみが重要)
  • 鉛筆ツールでコードトラックにコードイベントを書き込み、それをダブルクリックしてコードを入力。
  • エディタータブを使ってコードを指定する。右端はベース音指定。右下のボタンを押すことでここから新規コード追加できる。
  • ターゲットを指定してどのトラックで鳴らすかを決める。(「モニターしているトラックを使用」という指定もある)
  • コードイベントをクリックすれば音が鳴る。(当たり前だけど) プレイバックしても鳴る。

コードアシスタント

  • コードアシスタントタブを使ってコードの候補を表示することができる。
  • 複雑性定義スライダーを右に動かすとより複雑なコードが加わる。
  • 検索結果のリストにあるコードをクリックすることで和音を鳴らして確認できる。
  • 前後にコードがあるときはギャップモード設定して、分析対象を前のコードだけか、それとも前後両方のコードにするかを指定できる。
  • 終止形モードではタイプで進行パターンを指定し、ギアアイコン (複雑性定義フィルター) でスケールや代理コードなど音楽的な条件を指定できる。複雑性定義スライダーの操作によって、このギアアイコンで表示される条件の選択が自動的に変わる。
  • 共通音モードでは共通な音の数から指定可。

コードトラックインスペクター

  • コード視聴ボタンはきちんとアクティブにしておく
  • ボイシングメニューで、ライブラリー (ピアノ/ベーシック/ギター)、ライブラリーサブセット (ピアノならロック/ポップ/…)、パラメーター (ギアアイコンで表示) を指定し、どのようなボイシングをするか指定できる。 (ちなみに、ビデオでは「第一転回形、第二転回形」などと言っていますが、これ明示的に指定するには自動ボイシングをオフにしてコードイベントクリック後情報ラインに表示されているボイシングを変更して設定しなければなりません。下図)

    voicing

  • ビデオではいきなりギターアルペジオが鳴っているけれど、これは HALion Sonic SE のサウンドの方でこのように作っているため。 (こんな音があるとは知らなかった…)

スケール

  • スケールイベントをクリックすればスケールを聞いて確認できる。
  • 鉛筆ツールで新たにスケールイベントを作り、スケールを指定できる。(これを行うには自動スケールをオフにする)

MIDI (インストゥルメント) トラックとの連携

  • 各トラックのインスペクターにコードトラックセクションが表示されるようになる。
  • コードトラックと全く違う和音を録音しても、「コードトラックに追従」するよう指定することでコードトラックのコード通りに再生することができる。
  • コードイベントを MIDI (インストゥルメント) トラックにドラッグすれば和音のノートイベントに変換される。

プラグインとの連携

  • Chorder は 1つの鍵盤で和音を鳴らすためのプラグイン。 Chorder にコードイベントをドラッグしてコードを登録することが可能。 まとめてドラッグすればクロマティックに登録される。
  • Halion Sonic SE のパッドにコードイベントをドラッグしてコードをパッドに登録することができる。 パッドをクリックすれば登録されたコードが鳴る。 まとめて複数をドラッグするのも可。 (まあ、この辺はあまり使わないような気がしますが)

使うのはこれからですが、結構なパラメーターがあるので柔軟性はありそうです。 音楽的な知識はあった方が良いでしょうが、感覚でもできるのかな。

そうそう、YouTube は英語字幕を表示できるのですね。 ただ、自動で付いた字幕なので、ここぞというときに信用できないですねw

追記

Rock oN セミナーでコードトラック関連の機能がいろいろ説明されていました。 ustream のアーカイブになっています。 1:15:50 あたりからです。

Cubase 7 MixConsole の使い方 (チュートリアル視聴メモ)

MixConsole は Cubase 7 で導入された新しいミキシング環境です。 かなり大きく変わっているので、これに慣れたら Cubase 6 には戻れないのだろうなあ、という感じです。 今回は New Features チュートリアルビデオのチャプター 1、2 の内容のメモ書きです。 (追記: 執筆時点では英語を聞き取るしかなかったのですが、2013.5 現在では日本語字幕を表示することが可能になっています。YouTube の字幕メニューで日本語を選びましょう)

備忘録としてメモを作っているので、ビデオを見ればわかるし、忘れることもなさそうなことは省いています。 ビデオの順序で書いているのでこれを参考にビデオを見て自分でデモプロジェクトをいじってみれば理解は早いと思います。 とにかく手を動かすのが大事ですよね。 なお、訳はできるだけ Steinberg の訳語に合わせています。

Chapter 1

3分過ぎの具体的な機能説明のところからです。

  • 「表示/非表示」タブでチャンネルの表示/非表示を切り替える。Shift キーを押しながらクリックすると選択したチャンネル以外は全てオフとなる。
  • 表示エージェントを使ってルールに従い表示チャンネルを設定。話者は「最初に選択したチャンネルと接続されたチャンネルを表示」を好んでいるとのこと。アンドゥ・リドゥも可。
  • 「チャンネルタイプ」で表示/非表示チャンネルを設定することもできる。 例えばミックス時は 「入力チャンネル」は隠すし、ボイスパートのオーバーダビング時は「インストゥルメントチャンネル」を隠すよね、と。
  • ゾーンタブでチャンネルを表示するサイドを指定する。 ゾーンでチャンネルを選択すると他のエリアでも対応するチャンネルが選択されるので便利。
  • 検索はインクリメンタルサーチ。 検索して表示エージェントメニューから「選択チャンネルのみを表示」を選べば簡単に単独表示にできる、とのこと。 (単独表示ってそんなに使うのか？)
  • A はオートメーション。R:Read、W:Write、A:All
  • B はバイバス。Alt + クリックで全チャンネルの特定の機能をバイパスできる。 I:Insert、E:EQ、C:Channel Strip、S:Send
  • 複数のチャンネルを選択して Q-Link ボタンで一時的にチャンネルをリンク。 リンクしたチャンネルのパラメータは相対位置を保ったまま変更できる。
  • リンクボタンでパーマネントなリンク作成。リンクするパラメータを指定可。 こちらも相対値によるリンク。
  • Sus ボタンで一時的にリンク解除。
  • Abs ボタンで絶対値でのリンクとなる。
  • 下向き三角は機能メニュー。いろいろある。
  • ツールバーの開いてるところを右クリックで表示内容をカスタマイズできる。

Chapter 2

  • EQ カーブセクションをクリックして表示されるウインドウで EQ 設定ができる。 ポイントをドラッグできるほか、Shift + ドラッグで Q 変更。 右クリックのコンテキストメニューで EQオフやプリセットの読み込みなど様々なメニュー。 特に A/B 比較が簡単にできる。
  • 画像セクションはダブルクリックで画像設定。
  • ノートパッドセクションはメモ入力。
  • フェーダーセクションの上のボタンの役割は次の通り。 M:Mute、S:Solo、L:Listen、E:チャンネル設定ウィンドウの表示。
  • ここからチャンネルラックセクションの説明。 「ラック」ボタンで表示するラックを選べる。
  • ルーティングラックは上にインプット、下にアウトプットがある。
  • プリラックではハイカットフィルター (HC)、ローカットフィルター (LC)、ゲインと位相反転スイッチがある。
  • インサートラックでは「INSERTS」表示の右のボタンからプリセットを選んだり、ラック内部をクリックしてエフェクトを選んだりする。
  • EQ 操作は、先の EQ カーブセクションだけでなく、EQ ラックでも行うことができる。 ラック名左の丸印をクリックして個別にバイパスできる (他のラックも)。
  • チャンネルストリップラックでは主にダイナミクス系の様々なモジュールがある。 SC と書かれた小さな丸はサイドチェインで設定するとルーティングラックのアウトプットオプションとして表示される。 ドラッグしてモジュールの位置を変えることができる。 「EQ ポジション」モジュールは EQ の位置を変えるためのもの。 また、ドラッグして簡単にチャンネル間で設定をコピーできる。 ラック名の上で右クリックしてラック設定をプリセットとして保存できる (他のラックも)。 更にチャネルストリップラックでは個別にモジュールをタイトル上の電源アイコンで ON/OFF できる。(説明してないけど)
  • センドラックで右クリックすると簡単に FX チャンネルを追加できる。
  • クイックコントロールラックとデバイスパネルラックは別チャプターで。
  • 「*」+「1|2|3|4」のボタンで 4つセーブできる。 そのまま「1|2|3|4」を押せば切り替え。 (セーブ対象は表示/非表示などの見た目の設定)
  • 「≡」でチャンネルラック非表示

まとめ

というわけでかなり強力に進化していると感じます。 よく見るとコンプレッサーは 3種類あったりして、ビデオで説明されていない部分も多いでしょう。 ビデオでは「Single Window Concept」ということが強調されていましたが、確かにチャンネル設定ウィンドウ (「E」を押して出てくるやつ) を表示して操作する機会は少なくなりそうです。 大量のチャンネルを使うプロジェクトでは各種の機能で目的のチャンネルを見つけて操作するのが簡単になっていると思います。 まあ、私はそんなにチャンネルを使うことはないんですが…。

ついでですが、デュアルディスプレイで左にプロジェクトウィンドウ、右に MixConsole という環境に慣れちゃうと、やはりこれもシングルディスプレイに戻れなくなっちゃいます。 それと、コードトラック (Chapter 10) のメモもつくるかも知れませんが、それ以外はやらないと思います。

Cubase 7 を始めよう

今回の Cubase のバージョンアップではミキシングコンソール画面がガラリとかわり Cubase 5 → 6 のときよりもインパクトの大きいバージョンアップになっているように感じます。 今回は Cubase 7 を始めるための情報を集めてみました。

インストール

私は Windows 64ビット版 6.5 → 7 のアップグレードでしたが、1点途中で躓いた以外は順調に終わりました。 ちなみにインストールは「このコンピューターのほかのユーザーでも使用する (すべてのユーザー)」を選んだ以外デフォルト設定でのインストールです。 躓いた 1点とは Halion Sonic SE へのディスク入れ替え操作です。 以下のような画面が表示されるのですが、入れ替えても先に進みません。

cubase7 install

実はこの画面、下の方に「OK」、「キャンセル」ボタンが隠れているようです。 かすかにボタン上部が 2つ見えてますよね？ なので左側ボタンのわずかに見えている上部を押すか、ヤマハの説明するようにタブ＋ Enter で操作すれば先に進めます。

ところで、2ちゃん経由で知ったのですが、HALion Sonic SE (と Groove Agent ONE も？) のプリセットがロードできず eLicenser のアップデートをすると解消されるケースがあるようです。 リンク先に書いてある解消方法は、「eLicenser Control Center のアンインストール＋最新版インストール」とそれでもダメだった場合の「手動 DLL 削除＋最新版インストール」です。 (追記: 公式情報出ました)

それと Cubase は昔から複数のメジャーバージョンを並存させることができます。 Cubase 7 をインストールしても Cubase 6 (6.5) は削除されません。

どこから始める？

今回、インストール時に結構な大きさのファイルをダウンロードするようになりましたが、チュートリアルやデモプロジェクトもオンラインでの提供に変わっています。 チュートリアルについては現時点で日本語字幕ありのものは見当たりませんが、英語は慣れなので気にせず聞いてみましょう。多少細かい内容が聞き取れなくても画面の動きと合わせれば何ができるかはわかると思います。 (追記: 2013.5 現在では日本語字幕を表示することが可能になっています。YouTube の字幕メニューで日本語を選びましょう)

マニュアルも現時点で日本語で読めるものは新機能ガイドしかなく、オペレーションマニュアルから新機能の部分を抜粋したつくりになっており、参照先となるページが存在しなかったりして微妙な感じです。 特にソフトウェアに関しては英語を嫌っていては使えない製品ばかりになりかねないので、開き直って英語マニュアルに慣れちゃいましょう。 一応、1月中旬に日本語版マニュアルは japan.steinberg.net で提供予定ではあります。 (追記: 日本語マニュアルはこちらです)

関連情報

というわけで関連する情報をまとめておきます。

チュートリアルビデオ

You Tube 上での提供なのでどこからでも見れるようになりました。 10分前後のチャプターに分割されているのでモバイル端末で空き時間に少しずつみることもできるでしょう。

とりあえず、私は New Features の Chapter 1、2 (MixConsole) と 10 (コードトラック) を見て、これだけでお腹いっぱいな感じではあります。

デモ・マニュアル

デモについては、新たに追加された Lucky 7 だけでなく旧製品のプロジェクトも Cubase 7 用プロジェクトとなって提供されています。 Live Forever については Cubase 6 のときに書いたトラックの構成に関する記事が今でも参考になると思います。 MixConsole に慣れたいならば、まずはデモプロジェクトを開き MixConsole を使ってシグナルルーティングやエフェクト構成を確認してみると良いと思います。 ちなみに Lucky 7 もウタモノで結構な数のトラックをボーカル用に使っています。

Facebook for WordPress と Social Interaction Analytics

今回は Facebook と Google の Social Interaction Analytics の話です。 Facebook 関連シリーズ (1回目、2回目) も今回で一区切りです。

初期化コードとイベントリスナー

詳細は Social Interaction Analytics のページに書いてあるので簡単にすませますが、Facebook の「いいね！」ボタンが押されたのをトラックするには以下のようなコードでイベントリスナーを登録します。 

FB.Event.subscribe('edge.create', function(targetUrl) {
  _gaq.push(['_trackSocial', 'facebook', 'like', targetUrl]);
});

先の記事に書いた通り、fb_xd_fragment の件もあって WordPress で「いいね！」ボタン等 Facebook の機能を使うのであれば、Facebook for WordPress プラグインがお勧めです。 しかし、ここでの問題は上のコードをどこに置いたらよいかということです。 Facebook for WordPress を使用すると以下のようなコードがページに埋め込まれます。 

<script type='text/javascript'>
/* <![CDATA[ */
window.fbAsyncInit=function(){FB.init({"channelUrl":"https:\/\/hetarena.com\/wp-content\/plugins\/facebook\/channel.php","status":true,"cookie":true,"xfbml":true,"appId":"my_app_id"});}
/* ]]> */
</script>
<div id="fb-root"></div><script type="text/javascript">(function(d){var js,id="facebook-jssdk",ref=d.getElementsByTagName("script")[0];if(d.getElementById(id)){return;}js=d.createElement("script");js.id=id;js.async=true;js.src="http:\/\/connect.facebook.net\/ja_JP\/all.js";ref.parentNode.insertBefore(js,ref);}(document));</script>

これは非同期のスクリプトファイル読み込み処理と初期化コードです。 非同期のため、何も考えずに先のイベントリスナー登録コードを書いてしまうと FB という変数が未定義でエラーとなってしまいます。 プラグインの出力する window.fbAsyncInit の関数の FB.init の後に先のイベントリスナー登録コードを埋め込むことができれば良いのですが、プラグインに手を加えたくないですね。 どうすれば良いのでしょう？

facebook_jssdk_init_extras フィルター

実はちゃんと ‘facebook_jssdk_init_extras’ という名前でそれ用のフィルターが用意されています。 ここにコールバックを登録しておけば目的の位置にコードを出力することができます。 プラグインの readme.txt の中で以下のように説明されています。

* `facebook_jssdk_init_extras` – add extra JavaScript to the `fbAsyncInit` JavaScript function called after the Facebook JavaScript SDK is loaded

というわけで以下の様なコードを function.php に書いておけばオッケーです。 

add_filter('facebook_jssdk_init_extras', 'my_facebook_init');

function my_facebook_init() {
  return
"
  FB.Event.subscribe('edge.create', function(targetUrl) {
    _gaq.push(['_trackSocial', 'facebook', 'like', targetUrl]);
  });
";

}

readme.txt やソースを読むといいことがあるよということで。

PowerShell の学び方

Windows の管理用スクリプトは VBScript から PowerShell スクリプトの時代に変わっています。 PowerShell で書くスクリプトについてなかなか馴染めませんでしたが、最近ようやっとその理由がわかったので、同じような境遇の方へのヒントとなるようにまとめてみました。

PowerShell はコマンドレットの実行環境

まず私の犯した大きな間違いは PowerShell を VBScript のようにプログラミング言語と捉えてしまったことです。 VBScript の置き換えでこれまで通り各オブジェクトを操作するのだろうと考えてしまいました。

しかし、そう捉えてしまうのは誤りです。 そうではなくコマンドレットの実行環境と捉えるのが正しいです。 PowerShell はその名の通り、perl よりも sh の立場なのです。

そう捉えればスクリプトセンターのラーニング領域から探し出せるリファレンスっぽいものが「Windows PowerShell Quick Reference」とかいうたった 2ページのチープなガイドのみなのも納得できます。 Unix で sh の文法だけでなく各コマンドを知っていることも重要なように、「コマンドレット」の使い方を知っていないとまずいのです。 私は、スクリプトセンターで PowerShell の情報を探すよりもどのようなコマンドレットがあってそれぞれ何があるかを把握すべきだったのです。 コマンドレットのリファレンスはこちらにあります。

実行時に注意すること

先のリファレンスと同じサイトで提供されている「Getting Started」もざっと目を通しておくのがよいと思います。 特に気をつけねばならないのは必要なモジュールをインポートしないと目的のコマンドレットを使えないことがあるというところです。

例えば Active Directory を操作するスクリプトを書く場合は以下の一文が必要となるでしょう。 

Import-Module ActiveDirectory

オブジェクトの操作

先の Quick Reference にも書いてありますが、.Net Framework のオブジェクトは [] で括ってつかいます。 static なメソッドはそのまま呼べますね。 

$tmpText = [system.io.path]::GetTempFileName()

また PowerShell では .NET Framework クラスの名前空間は system になっているので、’system.’ を省略することもできます。 

$tmpText = [io.path]::GetTempFileName()

オブジェクト生成であれば New-Object コマンドレットを使います。 以下は COM オブジェクトの例ですが、.NET Framework クラスであれば -TypeName パラメータを指定します。 詳しくはNew-Object のリファレンス参照ということで。 

$ie = New-Object -COMObject InternetExplorer.Application
$ie.Navigate2("www.microsoft.com")
$ie.Visible = $true

いかがでしょう。 これでだいぶ PowerShell が身近になったのではないでしょうか？ 特に管理用スクリプトはサンプルのコピペ実行では危険で、内容をきちんと理解し、修正できなければなりません。 結局は自分で手を動かして覚えていくしかないのですが、オブジェクトのリファレンスの他にコマンドレットのリファレンスを参照できるようになればかなり楽になると思います。

PHP for Windows でイベントログを出力する

Windows 版の PHP を使うことがあり、アプリケーションからイベントログに出力するのに手こずったので、ポイントをメモ書きしておきます。 環境は IIS 7.5 (Windows Server 2008 R2) と PHP 5.4 です。

インストール

インストールについても簡単に触れておきます。 Microsoft より PHP on IIS というページで PHP を Windows 上で動かすための情報が公開されています。 この中に「PHP on Windows ガイドライン」が提供されているのでこれに従って進めれば PHP が稼働する IIS サイトを構築することができます。

それなりのボリュームになっていますが、メインはインストール関連の第2章とベストプラクティスの第5章です。 FastCGI と Non Thread Safe 版 PHP の組み合わせというのがポイントです。 5章の「PHP 実行プロセスのリサイクル設定」はちゃんとやっておきましょう。

実行権限

さて、本題に入って行きます。 Windows 版 PHP の syslog 関数の出力先はイベントログになっていますが、そのままでは IIS 上の PHP アプリケーションからは出力できませんでした。 以下のパラメータが php.ini で指定されていると IIS 上の PHP は仮想ユーザーの権限で実行されます。 

fastcgi.impersonate=1

先のガイドラインには上のように 1に設定するよう書かれていますが、これを 0に設定してアプリケーションプールにイベントログ出力可能なユーザーを割り当てるのも一つの方法です。 しかし、今回は fastcgi.impersonate=1のまま仮想ユーザーにイベントログ出力の権限を与えることにしました。

「仮想」ユーザーなので実体となるユーザーはないのですが、代わりに相当するグループ IIS-IUSR にイベントログ出力権限を与えます。 この方法も結構面倒なのですが、詳細は Microsoft の Technet に書かれているのでここでは簡単に触れるにとどめます。 リンク先の手順を参考にして IIS-IUSR (S-1-5-17) に 0x3　(読み取り＋書き込み) を設定します。

まず以下のコマンドで現在の設定が出力されるので、これを保存しておきます。 ファイルにリダイレクトすると良いでしょう。 

wevtutil.exe gl application /f:xml

続いて権限設定変更のコマンドを入力します。 これで IIS-IUSR グループにもイベントログを出力する権限が追加されます。 

wevtutil.exe sl application /ca:O:BAG:SYD:(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x7;;;SO)(A;;0x3;;;IU)(A;;0x3;;;SU)(A;;0x3;;;S-1-5-3)(A;;0x3;;;S-1-5-33)(A;;0x1;;;S-1-5-32-573)(A;;0x3;;;S-1-5-17)

ここまでで以下のようなコードを使ってイベントログを出力できるようになります。 

  openlog("My Message", LOG_PID, LOG_USER);
  syslog(LOG_INFO, "Hello, World");
  closelog();

「説明が見つかりません」エラーをなくす

これでイベントログには出力されるようになりましたが、イベントビューアーで確認したときに説明欄に以下のようなメッセージが表示されてしまいます。 ちなみに ID 2 は LOG_INFO を指定した場合で、priority を変えると変化します。

ソース “PHP-5.4.8” からのイベント ID 2 の説明が見つかりません。このイベントを発生させるコンポーネントがローカル コンピューターにインストールされていないか、インストールが壊れています。ローカル コンピューターにコンポーネントをインストールするか、コンポーネントを修復してください。

これを避けるためにはレジストリエディターで以下のように EventMessageFile と TypesSupported というキーを作成します。 この例では PHP 5.4.8 を想定しています。 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\eventlog\Application\PHP-5.4.8]
"EventMessageFile"=hex(2):43,00,3a,00,5c,00,70,00,68,00,70,00,35,00,5c,00,70,\
  00,68,00,70,00,35,00,2e,00,64,00,6c,00,6c,00,00,00
"TypesSupported"=dword:00000007

EventMessageFile は php5.dll のフルパスを示す REG_EXPAND_SZ (展開可能な文字列値) です。 上の例では C:\php5\php5.dll になっているのですが、適宜変更して設定します。 TypesSupported は REG_DWORD の 7です。 これはサポートされているタイプを表すフラグですが、詳しくはMicrosoft のリファレンスを参照してください。

これで「説明が見つかりません」エラーが消えると思います。

イベントビューアー上で PHP のログを確認しやすくする

イベントビューアーを使ってログを確認する時に、PHP のログのみ拾うためのカスタムビューを作っておくと便利です。 以下のようにイベントソースに PHP-5.4.8 のような PHP バージョン文字列を設定します。 イベントソースはカンマ区切りで複数設定できます。 これを設定すると左のツリーの「カスタムビュー」の下から簡単に保存したビューが選べるようになり便利です。

カスタムビューの設定

フィルタじゃNG！ fb_xd_fragment の問題への正しい対処の仕方

「fb_xd_fragment が Google Analytics のログに残るのは Facebook の「いいね！」ボタンのバグなので、Analytics 側でフィルタの設定を行いましょう」という記事が世の中に溢れています。 ちょっと気になったので調べてみたところ、根本的な対処が必要であることがわかったのでメモ書きしておきます。

どうすればよいのか

先の現象のことは実は Facebook JavaScript SDK のドキュメントできちんと説明されています。 詳細はそちらを読んでいただくとして結論だけ言うと、対策は channelUrl というパラメータを設定して対応するページを用意することです。 channelUrl を設定するとパフォーマンスが向上し、逆に設定しないと以下のような問題が発生するので、設定することが強く推奨されています。 Facebook からするとこれらの問題はバグというよりも仕様なのでしょう。

  1. フレームを使うと Social Plugins が表示されないことがあります。
  2. 自動再生ビデオやオーディオを埋め込むと 2つのストリームを再生してしまいます。
  3. channelUrl パラメータを設定しないと fb_xd_bust や fb_xd_fragment といったパラメータつきのログが残ります。

というわけで fb_xd_fragment がログに出ているときの正しい対処法は channelUrl を設定することです。 ログのフィルタはそれができない場合の次善策ではありますが、1 や 2 の現象に関しては全く効果がありません。

具体的な対処方法は

JavaScript SDK ドキュメント からの抜粋ですが、以下のようなページを用意します。 PHP での例です。 

 <?php
 $cache_expire = 60*60*24*365;
 header("Pragma: public");
 header("Cache-Control: max-age=".$cache_expire);
 header('Expires: ' . gmdate('D, d M Y H:i:s', time()+$cache_expire) . ' GMT');
 ?>
 <script src="//connect.facebook.net/en_US/all.js"></script>

そして「いいね！」ボタン等を設置するページに以下の JavaScript を埋め込み、非同期 js ファイルロードのコードと組み合わせて使います。 channelUrl のところに作成したページの URL を指定します。 

<script>
  window.fbAsyncInit = function() {
    // init the FB JS SDK
    FB.init({
      appId      : 'YOUR_APP_ID', // App ID from the App Dashboard
      channelUrl : '//WWW.YOUR_DOMAIN.COM/channel.html', // Channel File for x-domain communication
      status     : true, // check the login status upon init?
      cookie     : true, // set sessions cookies to allow your server to access the session?
      xfbml      : true  // parse XFBML tags on this page?
    });

    // Additional initialization code such as adding Event Listeners goes here

  };
</script>

JavaScript の書かれたページと channelUrl のページとで document.domain およびプロトコルを合わせておかなければならないとのことなので、環境によってはサーバーサイドで処理が必要かも知れません。

WordPress を使用しているのであればずっと簡単に解決する方法があります。 Facebook for WordPress プラグインを使うのです。 これをインストールするだけで先の 2つの処理を加えてくれます。

余計なひとこと

今回、ちょっとがっかりなのは fb_xd_fragment について書いた記事は多いものの、channelUrl の対策をきちんと説明した記事は見つからなかったことです。 だからこそこうして記事にしているというのはありますが、残念です。

WordPress で簡単に OGP の設定を行う方法

Open Graph Protocol (OGP) についての記事は小難しいものが多いように見えたので触らないでおいたのですが、とりあえず対応するにはセマンティックな meta タグを埋め込むぐらいの話のようなので、これは対応せねばと思いました。 今回は WordPress を OGP に対応させるためにしたことをまとめます。

Facebook for WordPress プラグインを使うのがお手軽

OGP 対応で一番簡単なのは公式プラグインである Fackbook for WordPress をインストールすることです。 インストールしただけで特に設定をしなくても OGP 対応タグを記事中に埋め込むようになります。 「いいね」ボタン等の機能は無効にしておくことができ、埋め込む App ID の指定もできます。 公式プラグインという安心感があるので OGP 対応が目的の場合も Facebook for WordPress を選択するのが、良いように思います。

私の場合、App ID は今回初めて取得しました。 まだ、十分に調べることが出来ていませんが、App ID を記事に埋め込むことで様々な機能が有効になるので、きちんと設定しておくべきです。

以下 Facebook のサイト上で行うアプリ設定についての話です。 記事に埋め込んで機能させるためには、その記事を公開するサイトのドメイン (ここなら hetarena.com) を App Domains として設定しておかねばなりません。 また、App Domains に設定するためには、そのアプリと Facebook 統合方法でその URL が使われていなければなりません。 何にも設定しないと App Domains 登録でエラーになるので、例えば「Website with Facebook Login」のサイト URL として https://hetarena.com/ を設定しておきます。 こうすることで App Domains にも hetarena.com を設定できるようになります。

できるだけシェイプアップしたい

本当に簡単に済ませるのであればここまでで、ここから先はこだわりの話です。 OGP 対応のみが目的のとき、Facebook for WordPress の出力する余分な JavaScript が記事に埋め込まれるのが気になります。 そこで、Facebook for WordPress のソースを見てみると、OGP 対応は open-graph-protocol.php というファイルの Facebook_Open_Graph_Protocol というクラスだけを使えば済むことに気が付きました。 app_id と locale は呼び出し元クラスの情報を使っているのですが、以下のように強引に書き換えてしまいます。 my app id は自分 App ID です。 locale については特にデバッガーもエラーを吐かないので、省略しました。 

--- a/includes/open-graph-protocol.php
+++ b/includes/open-graph-protocol.php
@@ -121,12 +121,7 @@ class Facebook_Open_Graph_Protocol {
                        self::OGP_NS . 'type' => 'website'
                );

-               if ( isset( $facebook_loader ) ) {
-                       if ( isset( $facebook_loader->locale ) )
-                               $meta_tags[ self::OGP_NS . 'locale' ] = $facebook_loader->locale;
-                       if ( isset( $facebook_loader->credentials ) && isset( $facebook_loader->credentials['app_id'] ) && $facebook_loader->credentials['app_id'] )
-                               $meta_tags[ self::FB_NS . 'app_id' ] = $facebook_loader->credentials['app_id'];
-               }
+               $meta_tags[ self::FB_NS . 'app_id' ]  = 'my app id';

                if ( is_home() || is_front_page() ) {
                        $meta_tags[ self::OGP_NS . 'title' ] = get_bloginfo( 'name' );

あとは functions.php に以下を入れます。 open-graph-protocol.php へのパスは適切に書きましょう。 

require_once( '/path_to_ogp/open-graph-protocol.php' );
add_action( 'wp_head', array( 'Facebook_Open_Graph_Protocol', 'add_og_protocol' ) );

これで余分な出力はなくなり、OGP の meta タグのみ出力されるようになりました。

…とここまで書いてアレなのですが、埋め込まれている JavaScript に重要な働きがあることがわかりました。 fb_xd_fragment がログに残る件がらみなのですが、詳細は別記事でご確認ください。 そういうわけでこのようにクラスを切り出して使うのはお勧めしません。 Facebook for WordPress をそのまま使いましょう。 (この段落は 2012/12/4 追記)

アイキャッチイメージを記事に設定する

Facebook for WordPress (Facebook_Open_Graph_Protocol クラス) の動作では、記事に設定された「アイキャッチ画像」の情報を image プロパティとして埋め込みます。 Facebook のデバッガーによれば縦横 200px 以上のイメージをきちんと設定しておくことが推奨とのことです。 これまでアイキャッチ画像は使っていなかったので、新たに 200px 四方のロゴをアップロードして全ての記事のアイキャッチ画像として設定することにします。

(2013/1/20 追記: もっと手軽な方法がありました。)

まず、記事に見える形で表示したくないので、テーマファイルから以下の行を削除しました。 

<?php the_post_thumbnail(); ?>

続いて記事へのアイキャッチ画像の設定ですが、面倒なので SQL で実行することにしました。 以下の SQL 文はアイキャッチ画像が設定されていない post/page に対して ID 654 の画像をアイキャッチ画像として設定するためのものです。 

START TRANSACTION;

INSERT INTO wp_postmeta (post_id, meta_key, meta_value)
SELECT id, '_thumbnail_id', 654
FROM wp_posts
WHERE post_type IN ('page', 'post')
AND NOT EXISTS
(SELECT * FROM wp_postmeta
 WHERE meta_key = '_thumbnail_id'
 AND wp_postmeta.post_id = wp_posts.id);

COMMIT;

何か失敗したときに Rollback ができるようにトランザクションを有効にして実行しています。 これで image プロパティも meta タグとして埋め込まれるようになりました。 これらを実行する時は、画像 ID だけでなくテーブル名も自分の環境に合わせてください。 マルチサイト環境ならば wp_2_postmeta、wp_3_postmeta、… となりますね。

これで「簡単な」なのかという声が聞こえそうですが、やっている内容に比べたら簡単にやっているのではないでしょうか…。(苦しい)