月: 2014年1月

[WordPress] Markdownで記述した記事内のソースコード部分をハイライトする方法

WordPress

この辺は至る所で既に書かれた話題だと思いますが、自分にあった方法の備忘録という事でご紹介します！
WordPressで楽しく記事を書くにあたって、僕の要件は下記の通りです：

  • Markdownで書きたい
  • 記事内で紹介したプログラムのソースコードのシンタックスをハイライトしたい
  • ハイライトのカラースキーマにSolarized-darkを使いたい

Solarizedの配色は見やすいしカッコイイのでマジでおすすめです。

これらは、以下の二つのプラグインを使用する事で実現できます：

しかし、ここで一点問題があります。
highlight.jsは、記述するプログラムの言語をタグのクラス名で明示的に指定出来ます。
指定しなければ、自動で言語を検出してくれますが、その精度はイマイチです。
残念な事に、Markdownの記法ではクラス名を指定出来ません。
だからといって、HTMLを部分的に書くなんて気持ちよさが半減です！
以下のプラグインがこの悩みを解決してくれました：

このプラグインで、Markdown記法でも言語を明示できるようになります！
以下のようにして、コードの最初の行に#!に続いて言語の名前を記述すればOK。

#!ruby
class Foo < Bar
  def hello
    puts "Hello World!"
  end
end

結果:

#!ruby
class Foo < Bar
  def hello
    puts "Hello World!"
  end
end

objectivec、bash、javaなどhighlight.jsで対応している言語の名前を指定できます。
快適！

蛇足

もう少し調べたら、GitHub Flavored Markdown for WordPressというのがあって、three backticksでコードブロックが使えるようになるらしい。
現状で割と満足なので、また気が向いたらトライしてみよう。

CocoaPodsで自動生成されたターゲットにPreprocessor Macroを定義する方法

CocoaPods

どんな時に必要？

CocoaPodsベースのプロジェクトでアプリケーションを開発している時で、特に自前のモジュールもpodでパッケージングしている場合に必要になる事があります。
僕の場合は、pod化した自前モジュールをUnitTestしたい時でした。

ビルド方法によってPreprocessor Macroを切り替えたい

サーバサイドのAPIラッパモジュールを例にとって考えてみたいと思います。
サーバサイドには、ステージング環境や本番環境の切り替えが必要な事がよくあります。
また、その切り替え方法にはPreprocessor Macrosを使用するのが一般的だと思います。

達成したい要件は、以下のようにビルド方法によって環境を切り替える事です：

  • UnitTestの時は必ずステージング環境でコンパイル
  • このモジュールを使用するアプリケーションのワーキングスペースorプロジェクトでは、各ターゲットの設定に従う

Prefix Headerでは上手く出来ない

モジュールをpod化していなければ、普通にUnitTestターゲットのprefix header(*.pch)内に定義すればいいだけです。
しかしpod化している場合、モジュールはCocoaPodsが自動で生成したプロジェクトでコンパイルされるため、テストターゲットで定義したフラグは効果がありません。
さらに、Podsプロジェクトのprefix headerとかプロジェクトのBuild Settingsで設定しても、pod installを実行する毎にリセットされてしまいます。

Podfileのpost_installでフラグを指定する

Podfileには、podがインストールされた後のイベントをHookできます。(参考: CocoaPods Guides – Podfile Syntax Reference)
これを使って、モジュールのターゲットのPreprocessor Macrosを変更できます。
Podfileは以下のように書きます：

workspace 'APIWrapper'

platform :ios, '6.0'

xcodeproj 'Tests/APIWrapper Tests'

target :'APIWrapper Tests', :exclusive => true do
   pod 'Kiwi/XCTest'
   pod 'APIWrapper', :path => './'
end

# インストール後に実行される処理を記述
post_install do |installer|

  POD_TARGET_NAME = "Pods-APIWrapper Tests-APIWrapper"

  # 変更したいビルドターゲットを探す
  classy_pods_target = installer.project.targets.find{ |target| target.name == POD_TARGET_NAME }
  unless classy_pods_target
    raise ::Pod::Informative, "Failed to find '" << POD_TARGET_NAME << "' target"
  end

  # ビルド設定を追加
  classy_pods_target.build_configurations.each do |config|
    # Debugターゲットのみ変更
    if config.name == "Debug"
      # Preprocessor Macrosを変更する
      config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= ['$(inherited)']
      # ステージングのフラグを立てる
      config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] <<  "STAGING"
    end
  end

end

これで、UnitTest用ワーキングスペースで、テスト対象のpodモジュールのPreprocessor Macrosを変更できます！
アプリケーション用のワーキングスペースでは、テスト用の設定は全く気にせずにコーディングできます。