iOS開発で頻繁にお世話になる .p12 ファイル(秘密鍵+証明書のセット)の情報を確認する方法です。
SHA1フィンガープリント、有効期限、チームID,名前などがコマンドラインから簡単に確認できます。
カテゴリー: mac開発
Swift2でリリースビルドの時にログ表示しないようにする
Xcode7(Swift2) でデバッグビルドの時だけデバッグ出力して、プロダクションビルドの時はセキュリティのためデバッグログを削る方法のメモ。
このコードにより、print, debugPrintln, NSLogの出力を制御することができます。
事前準備
XcodeプロジェクトのBuild Settings → Swift Compiler → Other Swift Flags の Debug に「-DDEBUG」を追加して下さい。
コード
AppDelegate.swift の冒頭に以下のグローバル関数を追加します。
他のファイルのほうがわかりやすければAppDelegate以外でも大丈夫です。
// リリースビルドでprint, debugPrintを無効化
func print(object: Any) {
#if DEBUG
Swift.print(object, terminator: "")
#endif
}
func debugPrint(object: Any) {
#if DEBUG
Swift.debugPrint(object, terminator: "")
#endif
}
// リリースビルドでNSLog無効化
func NSLog(message:String){
#if DEBUG
Foundation.NSLog(message)
#endif
}
func NSLog(format:String, _ args:CVarArgType...){
#if DEBUG
Foundation.NSLog(String(format: format, arguments: args))
#endif
}
この記事を書いた理由
print, debugPrintは出てきますが、SwiftでNSLogを非表示にする方法がどうしても出てこなかったので記事にしました。
Swift2から廃止されたprintln, debugPrintlnはここに書いていませんが、print, debugPrint と同様の方法で対応可能です。
ググると NSLogを消す方法として、プレフィクスヘッダファイル(.pchファイル)に #define NSLog を方法が出てきますが、こちらはObjective Cにしか効果がないようなので注意。
おまけ
代替案としては、より細かいログレベル制御が可能なXCGLoggerを使うのも手です。
AppDelegateで
import XCGLogger
let log: XCGLogger = {
let log = XCGLogger.defaultInstance()
#if DEBUG
log.setup(.Debug, showThreadName: true, showLogLevel: true, showFileNames: true, showLineNumbers: true, writeToFile: nil)
#else
log.setup(.Severe, showThreadName: true, showLogLevel: true, showFileNames: true, showLineNumbers: true, writeToFile: nil)
#endif
let dateFormatter = NSDateFormatter()
dateFormatter.dateFormat = "MM/dd/yyyy hh:mma"
dateFormatter.locale = NSLocale.currentLocale()
log.dateFormatter = dateFormatter
return log
}()
としておくと、
log.debug("Debugレベルのログです")
log.info("infoレベルのログです")
のようにログレベルごとのログ出力ができるようになります。
plist と json を相互変換する
iOSやMac OS Xで使用されるplist形式(プロパティリスト)と、
Androidやwebシステムで使いやすいJSONに相互変換したい場合のメモ。
続きを読む plist と json を相互変換する
Mac OS X のバッテリー劣化状況を確認する
ほお、と思ったのでメモ。
MacBook AirやMacBook Pro をずっと使っていて、バッテリー(電池)の持ちがなんとなく悪くなった気がするなぁと思った事ありませんか。
そんなときにバッテリーの劣化状況を調べる方法がありました。
ターミナルから、下のコマンドを入力するだけ。
ioreg -c AppleSmartBattery | grep -i Capacity
実行すると、このように出力されます。
$ ioreg -c AppleSmartBattery | grep -i Capacity
| | "MaxCapacity" = 4745
| | "CurrentCapacity" = 3463
| | "LegacyBatteryInfo" = {"Amperage"=3290,"Flags"=7,"Capacity"=4745,"Current"=3463,"Voltage"=8282,"Cycle Count"=282}
| | "DesignCapacity" = 5100
MaxCapacityがバッテリーの最大容量、CurrentCapacyty が今のバッテリー残量、DesginCapacityが製品出荷時の(設計された)バッテリー最大容量です。
劣化状況は MaxCapacity ÷ DesginCapacity という計算をすると求められます。
上の例だと 4,745 ÷ 5,100 = 0.930392… となり、製品出荷時から比べるとパフォーマンスが93%(0.93)に減っているので、損耗率は 100 – 93 = 7% となります。
ちなみに上の例は買ってから1年のMacBook Airです。
1年フルに仕事で使ってたのですが、7%しか劣化していないのですね。
もっと劣化してると思っていたけど結構優秀。
【Mac OS X】スクリーンショットの保存場所を変える方法
デフォルトだと画面のスクリーンショット画像を撮るとデスクトップフォルダに保存されます。
裏ワザ、隠し機能的ですが、ターミナルから下のようなコマンドを入力すると画像の保存フォルダを変更することができます。
【ピクチャフォルダに保存する】
$ defaults write com.apple.screencapture location ~/Pictures $ killall SystemUIServer
ピクチャ以外にも好きなディレクトリにすることもできます。
【ScreenShotsフォルダに保存する】
$ mkdir ~/ScreenShots $ defaults write com.apple.screencapture location ~/ScreenShots $ killall SystemUIServer
戻したくなったら下のコマンドで戻すこともできます。
【デフォルト(デスクトップ)に戻す】
$ defaults delete com.apple.screencapture location $ killall SystemUIServer
以上、クリーンショット保存先を変える方法でした。
散らかってしまいがちなデスクトップもこれで綺麗に整理整頓されるかも。
【Sublime Text 2】Mac OS Xで日本語入力のタブ変換ができなくなった場合の対処方法
Sublime Text 2 をしばらく使っていて、Mac OS Xで日本語入力のタブ変換が出来ないことにふと気づきました。
ひらがなを入力したら変換候補が出てきますが、ここでタブを押して変換候補を切り替えようとしたら、タブキーを押した途端に変換候補の欄が閉じて、入力中の文字が消えてしまう。
カーソルで変換候補を切り替えればいつも通り入力はできます。
でも、つい癖でタブキーを押すたび、入力をやり直すハメになって、手が止まる…。
これじゃいけないとタブ関係のキーバインドを見なおしたら何とかなったので、
修正方法をメモしておきます。
解決方法
メニューからPreferences > Key Bindings – Default を開きます。
すると、下のような怪しい部分があるので…
{ "keys": ["tab"], "command": "insert_best_completion", "args": {"default": "\t", "exact": true} },
{ "keys": ["tab"], "command": "insert_best_completion", "args": {"default": "\t", "exact": false},
"context":
[
{ "key": "setting.tab_completion", "operator": "equal", "operand": true }
]
},
これをコメントアウトしてしまいます。
/*
{ "keys": ["tab"], "command": "insert_best_completion", "args": {"default": "\t", "exact": true} },
{ "keys": ["tab"], "command": "insert_best_completion", "args": {"default": "\t", "exact": false},
"context":
[
{ "key": "setting.tab_completion", "operator": "equal", "operand": true }
]
},
*/
あとは保存すればOK。
これで、ストレスなく快適にSublime Text 2を使えるようになりました。
それで原因は?
なんでしょうね…。
色々とプラグインを入れて使っているため、何が原因かは不明なんです。
情報求む。
Mac OS X で pkg-configでエラーになった
普段から OS Xのパッケージ管理には Homebrew を使っています。
Homebrew に含まれる一部パッケージ(pango)のバージョンを変えてインストールする必要があり、自分でビルドしてみようと思ったところすっかりはまってしまいました。
発生した症状
Homebrew でインストールしたパッケージ(cairo)に依存している箇所でエラーになってしまいました。
具体的には ./configure の実行中に pkg-config で依存しているパッケージの.pc ファイルが存在しないと怒られています。
# config.log pkg-config --cflags --print-errors cairo Package xcb-shm was not found in the pkg-config search path. Perhaps you should add the directory containing `xcb-shm.pc' to the PKG_CONFIG_PATH environment variable Package 'xcb-shm', required by 'cairo', not found
解決するには?
エラーメッセージどおり、環境変数 PKG_CONFIG_PATHの通るところに .pc ファイルを配置するか、環境変数にパスを追加して再実行することで解決しました。
PKG_CONFIG_PATHが空の場合のデフォルトは
/usr/local/lib/pkgconfig
です。
今回は /opt/X11/lib/pkgconfig/ の中に依存している .pcファイルがあったので、パス追加で対応しました。
$ export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/opt/X11/lib/
再実行し、エラーが出なくなるのを確認します。
$ pkg-config --cflags --print-errors cairo
あとは通常通り、./configure, make などを実行すればOKです。
OS X では(Homebrewでは?) X11 関係の pkgconfigのパッケージ情報ファイル(.pcファイル)は /opt/X11/lib/pkgconfig/ にあるのですね。
Mac OS X でポートを開いているプログラムを調べる
WindowsやLinuxでは netstat の -bオプションや-pオプションでポートを待ち受けているプロセスを調べる事ができるのに、Mac OS Xではそんなオプションが無く困った。
なんとか方法が他にないか調べた所、
Mac OS X では lsof を使うのが一番簡単そう。
$ lsof -i | grep LISTEN
結果はこんな感じになる。
$ lsof -i | grep LISTEN Dropbox 303 user 19u IPv4 0xffffff0123456789 0t0 TCP *:17500 (LISTEN) Dropbox 303 user 25u IPv4 0xffffff0123456789 0t0 TCP localhost:26165 (LISTEN) node 56728 user 8u IPv4 0xffffff0123456789 0t0 TCP *:hbci (LISTEN) mongod 57071 user 6u IPv4 0xffffff0123456789 0t0 TCP localhost:28017 (LISTEN) mongod 57071 user 7u IPv4 0xffffff0123456789 0t0 TCP localhost:27017 (LISTEN)
調べようと思った動機は mongodb のListenポートをど忘れして確認したかっただけでした。
実行結果を見ると mongodb は TCP localhost:27017, TCP localhost:28017とあるので、
待ち受けているポートはTCPポート27017, 28017の2つですね。
コマンド引数の文字数制限 – Argument list too long
UNIX系OSで実行するコマンドの最大の長さは execve(2) の制限に依存するそうです。
プログラムの実行引数の制限については、長さの制限は OS によって異なり、FreeBSD では 64KB、Linux のあるディストリビューションでは 128KB、SunOS4〜Solaris は 1MB、HP-UX 10.20 までは 20KB (パッチを当てれば 2MB)、HP-UX 11.x 以降は 2MB です。
この値は伝統的に ARG_MAX というマクロ定数で定義されているため、使っている UNIX, Linux, Mac OS X の ARG_MAX を調べたい場合は /usr/include を ARG_MAX で grep するか、getconf コマンドを使って
% getconf ARG_MAX
結果:
65536
とすることで調べることができます。
FreeBSD なら sysctl で
% sysctl -A kern.argmax
結果:
kern.argmax: 65536
としてもいいです。
なお、ARG_MAX は 4096 以上であるべき、と POSIX には規定されています。
2017年2月現在のコマンドライン最大文字数の参考値が知りたくて、
手元のマシンいくつかで試してみました。
- CentOS release 6.8 (Final / さくらのVPS) … 2621440文字
-
Scientific Linux release 6.2 (Carbon / さくらのVPS) … 2621440文字
-
Mac OS X Sierra (Macbook Pro 2015) … 262144文字
-
Debian(Jessie / さくらのクラウド) … 2097152文字
最低でも20万文字ということで、あまり気にする機会はなさそうですが、
もし大量のファイルを扱う場合などにArgument list too longエラーがでたときは、
以下のように xargs などを使うとARG_MAXの制限を回避できます。
grep foo /path/to/too-many-files/*
たとえばこのように、ワイルドカードでエラーが出てしまう場合、
echo /path/to/too-many-files/* | xargs grep foo
のように echo と xargs を組み合わせるとエラーなく動作します。
なぜこれならエラーにならないかというと、echoはプログラムではなくシェルの内部コマンドなので文字数制限(ARG_MAXの制限)を受けないためです。
また、xargsはARG_MAXの値を把握しているので、引数がARG_MAXを超えそうになると、自動的に複数回に分割して実行してくれるため、ARG_MAXの問題を回避することができます。