2014-08-11

Homebrew のパッケージを Brewfile で管理してみる

最近の Homebrew には、パッケージ管理ファイル Brewfile をデフォールトで使えるようになっている。

適当な場所に Brewfile を作成し、brow bundle コマンドを実行する。これで、Brewfile に書いてあるパッケージがインストールされる。書式に下記の通り:

$ cat Brewfile
# Packages

install git
$ brew bundle

上の例では git パッケージがインストールされる。

あとがき

Brewfile を使えば (Mac OS に) インストールするパッケージを git でバージョン管理することができるようになる。複数の Mac 環境を持っている場合に、パッケージを統一できるので便利。

追記

brew bundle を実行すると、こんな警告が出る。Brewfile はこれからも使えるのかな?

Warning: brew bundle is unsupported and will be replaced with another, incompatible version at some point.

2014-08-09

エアコンの除湿と冷房、効果と電気代の差について

Never まとめに良いまとめがあったので、自分メモ用にまとめとく。

結論を先に書くと、除湿だけなら「冷房の方が効果も高く、電気代も安くなる場合がある」。

目的

冷房と除湿では目的が違う:

冷房
部屋の「温度」を下げる
除湿
部屋の「湿度」を下げる

「冷房」の目的は温度を下げることだけど、副作用として除湿も行なってしまう。どれくらい除湿するかは考えられていない。何故なら、目的が部屋の温度を下げることだから。

「除湿」の目的は湿度を下げることだけど、「できるだけ温度を下げずに湿度を下げる」という制限がある。

二種類の除湿

除湿には二種類のタイプがある:

弱冷房除湿
冷房の機能を弱めたもの
再熱除湿
冷房機能で除湿した後、部屋が冷えないように温め直す

特に記述がなければ、普通の「除湿」は「弱冷房除湿」と思っていい。

電気代は 「弱冷房除湿 < 冷房 < 再熱除湿」という順になる。

比較表

温度低下湿度低下電気代金
冷房
再熱除湿
弱冷房除湿

あとがき

実家に帰ってエアコンの説明書を読んでみたけど、「弱冷房除湿」か「再熱除湿」かは分からなかった。最新のエアコンを調べてみると、「再熱除湿」がついていたり、ついていなかったり。比較的最近の機能なのかと思う。少くとも、うちがエアコンを買った数年前 (?) には、そんな機能はなかったんじゃないかな。

Never まとめにもあるよう:

電気代をおさえたいときは、弱冷房(じゃくれいぼう)除湿や、高めの温度に設定した冷房(れいぼう)がおすすめ

高温・多湿な夏に、除湿と冷房を同時に行ないたければ、(うちの機種だと) 冷房だけの方が電気代も効果も高そう。かなり勉強になった。

各種プロジェクト向け .gitignore ファイル

新しいフレームワーク、新しいツールを使ってプロジェクトを開始する時、当然そのプロジェクトは git で管理するとして、.gitignore をどうするかは頭痛のタネになる。

例えば、ぼくは XCode で iOS アプリを開発しようとしているけれども、どのファイルを Git で管理すれば良いのか分からない。どのファイルを無視して良いのか分からない。そこで役に立つのが GitHub が集積している .gitignore ファイル一群。

XCode ならば Objective-C.gitignore というファイルをコピーすればいい。

# Xcode
#
build/
*.pbxuser
!default.pbxuser
*.mode1v3
!default.mode1v3
*.mode2v3
!default.mode2v3
*.perspectivev3
!default.perspectivev3
xcuserdata
*.xccheckout
*.moved-aside
DerivedData
*.hmap
*.ipa
*.xcuserstate

# CocoaPods
#
# We recommend against adding the Pods directory to your .gitignore. However
# you should judge for yourself, the pros and cons are mentioned at:
# http://guides.cocoapods.org/using/using-cocoapods.html#should-i-ignore-the-pods-directory-in-source-control
#
# Pods/

内容充実な .gitignore ファイルが用意されている。

CocoaPods を使う場合は Pods ディレクトリーを .gitignore に含めることを勧めない、とのコメントもあり。ぼくは Pods ディレクトリーを ignore しちゃう派だけど、そこら辺は自己責任で決められたし。Pods ディレクトリーを含める・含めないについては下記記事を参照とのこと。

あとがき

ここには Objective-C の他にも、Android, Elisp, Rails, Scala, Swift, TeX と様々な言語・フレームワークへの gitignore ファイルが集まっている。gitignore ファイルをどうするか頭を悩ます時間があったら、サクッとここのファイルを使わせてもらおう。時間の節約にもなるし、勉強に繋がることもある。

bash 変数を使って cd を楽にする方法

深い階層へ軽動したい時、cd コマンドを打つのは面倒。たとえ bash のパス補完が効くとしても、手間はかかる。そこで、目的のパスを bash 変数に保存することでこの問題の対処をしている。例えば、このブログ記事の下書きが置いてあるディレクトリーへ移動するには、次のコマンドを使う:

$ cd $blog

.bashrc に書く設定は次の通り:

blog="$HOME/Documents/blog/"

ディレクトリー階層がどんなに深くても、この方法なら一発で辿り着けるので便利。

パスに空白が含まれる場合

時として、パスに空白が含まれる場合がある。自分でそういうパスを作ろうとは思わないけど、他人の git repository を clone したらパスに空白が空いていた、等々何ともしがたい状況はある。そういう時、同じ要領で変数を指定しても cd で失敗する。

$ grep somedir ~/.bashrc
somedir="$HOME/Documents/path with space"
$ cd $somedir
bash: cd: /Users/ataka/Documents/path: No such file or directory

path の中に含まれる空白が引数の区切りとして扱われている。「path with space」というディレクトリー名の最初の「path」しか cd に渡っていない。これを解決する方法は、多少武骨だけれども変数を "" で囲む。

$ cd "$somedir"

これで「path with space」へと移動できた。

あとがき

ディレクトリー移動はコマンドライン操作の基本。ここで楽できると、随分ストレスが減る。もし良ければ試してみて欲しい。

2014-07-26

ReactiveCocoa 勉強会に参加した #rac_kansai

2014-07-26 (土)。はてなの京都オフィスを借りて開催された ReactiveCocoa 勉強会に参加した。

内容は Objective-C で Reactive プログラミングを行なうライブラリー ReactiveCocoa の勉強会。

LT で 10 分弱、話しをしたので資料を置く。

ReactiveCocoa では直接 Collection 系 (NSMutableArray とか NSMutableDictionary とか) を Observe できない。RACSubject を使えば大低の場合、代替の機能を提供できる、という話をした。

スライドには簡略化したコードしか書いていない。サンプル・コードは ViewController の他に ViewModel と Model を作って MVVM な作りにしてある。また、口頭でしか伝えなかった KVO と ReactiveCocoa を使った Observe のサンプル・コードも書いてある。興味のある方はどうぞ。

see also.

2014-07-14

find コマンドでファイル名正規表現検索

find コマンドの検索では専ら -name オプションを使う。これだと細かいファイル名指定が出来ない。先日、正規表現が使えると教えてもらったのでメモ。

画像検索を例に...

JEPG, PNG 画像を検索してみる。-name オプションを使う場合はこんな感じ。二回に検索を分ける。

$ find . -name '*.jpg'
$ find . -name '*.png'

正規表現を使う

正規表現を使う場合、検索開始パスの前に -E オプションを付ける。検索には -name の代わりに -regex を使う。拡張子 .jpg と .png なファイルを検索する場合はこんな感じ。

$ find -E . -regex '^.+\(jpg|png)$'

大文字・小文字を無視したい

Windows 系のソフトを使うと、ファイル名が大文字だったりする。アルファベットの大文字・小文字を無視させて検索する場合は -regex ではなく -iregex を使う:

$ find -E . -iregex '^.+\(jpg|png)$'

沢山の画像フォーマットに対応

JPEG の拡張子は .jpg の他に .jpeg も使われる。画像ファイルには GIF もまだ健在。ウェブをやっていると ico ファイルも扱うか? 最近は .svg も使われるようになってきた。全部に対応するよう、正規表現を書いてみる。

$ find -E . -iregex '^.+\(jpe?g|png|gif|ico|svg)$'

ここまでくると、随分、実用的になったかな。

Man は Mac OS X に付いてくるものを参考にした。BSD 系の find みたいね。

2014-06-26

What's New in Android (Google I/O 2014) 殴り書きメモ

Google I/O 2014 のセッション「What's New in Android」が YouTube ライブされていたので見た。司会の二人は止まることなく口を開き、1 時間のセッションを駈け抜けた。大まかな内容は掴めたけど、テキストに直せるほどの情報はメモしきれなかった。きっと後日公開されるスライドを見て欲しい、ということなのだと思う。

詳しいことは、スライドや他の人のブログに譲るとして、速報的にメモの欠片を箇条書きで出してみる。

Meterial APIs

  • ウィジェット
    • View.setElevation()
    • View.setTranslationZ()
  • アニメーション
    • Activity Transitions
    • Animation curves
    • Animated Reveal
  • アイコン
    • State Animations (StateListAnimator, AnimatedStateListDrawable)
    • Touch Feedback Ripples (RippleDrawable)

Render Thread

  • UI Thread: UI 部品を作るスレッド
  • Render Thread (NEW): 表示するスレッド

Supported Lib

  • CardView
  • RecyclerView
  • Palette
  • RoundedBitmapDrawable
  • ViewPropertyAnimator

カメラとオーディオ

  • Camera2 APIs
  • 新しいオーディオのバッファリング
  • Media Session - フレキシブルなプレイバック・コントロール
  • Media Controller

ステータス・バー

  • Theme attr: android:statusBarColor
  • 固定色 (solid color)
  • 透明 (@color/transparent)

マルチ・ネットワーキング

  • SMS
  • 特定のキャリア機能

Android L での通知

Material テーマ

  • 背景: カード型、影付き
  • 前景: dark text
  • アクセント・カラー: 小さな丸アイコンの中の色を設定 (Notification.Builder.setColor())
  • 小さなアイコン・バッチ
  • 開くビュー (Expanded views) とアクション・ボタン
  • 必要ならカスタム・ビューも OK

Media Style

  • アクセント・カラー: 背景色
  • 最大 6 個までのアクション・アイコン
  • 畳み込んだ時は、最大 2 個まで
  • カスタム・プログレスバー
  • 新しい Media Session API 対応

Hands-up 通知

以下の要件に使われる:

  • 高い優先度
  • 人を誘う
  • 音を出す
  • full screen intent

ロック画面

3 種の通知: 状態によって表示する通知情報が変わる

  • visibility_private
  • visibility_public
  • visibility_secret

通知のスマートなソート

  • カテゴリー: 電話・メッセージ・アラーム・ソーシャル
  • 古いものより、良いものを

Android Studio

ほとんどの情報が黒塗りで公開されず。笑いを誘う。

その他

  • Enterprise
  • ART (Dalvik を置き換える)
  • Android Wear (スマホ・アプリへの通知は自動的に wear にも)
  • Android TV (対応!)

Android Wear 〜 身に付けられる Android

Google I/O 2014 のキーノートで Android Wear SDK が発表された。Wearable、いわゆる「身に付けられる」ガジェットに対して Android アプリを作成できるようになる (もちろん、そのガジェットは Android ベースでないといけない)。

Android Wear として 3 つのスマート・ウォッチが紹介された。

  • LG G Watch (今日から Play Store で発売)
  • Samsong Gear Live (今日から注文受付)
  • Motorola Moto 360 (2014 年夏発売)

(日本での発売は??)

Android Wear SDK

Android Wear SDK を使うと以下の機能を持った「Wear」向けアプリが作れる。

  • カスタム UI
  • センサー制御
  • 音声操作
  • データ転送 (スマホやタブレットへ)

デモ by LG G Watch

Android Wear では「OK Google」からの音声検索、Android 通知の受信なども基本的にサポート。タッチパネル方式で、左右のスワイプでページをめくったり、上下のスワイプで通知を表示するデモが行なわれた。

対応しているアプリとして、Gmail, Twitter, Facbook、万歩計、天気予報などを見ることができた。この他、音声入力からリマインダーを設定したり、Google Keep にノートを取ったりと機能も多彩。

極めつけは Lyft を使って車を呼ぶデモまで見せた。

Android Wear SDK は、今までと一味違ったサービス提供の門戸を開きそう。

Android One 〜 低価格 Android スマートフォン発表

Android One

Google I/O 2014 のキーノートで android one が発表された。$100 を切る低価格スマートフォン。スペックは以下の通り:

  • デュアル SIM
  • SD カード
  • 4.5 インチ・ディスプレイ
  • FM ラジオ

あとがき

Android プロジェクトが初めてお披露目した時、Android スマホは低価格でスペックの低いものになると言われた。iPhone が高級スマートフォンを代表するなら、iPhone が狙えないターゲットに向けて発売されると。主に中国・インド・東南アジアなどの市場を目指すだろうと。

ところが蓋を開けてみれば、各社フルスペックで高価な Android 機がメイン・ストリームになった。Android One は、原点に戻ってターゲットを絞り直したような製品に思える。安価な Android を大勢が持つことで、世界は変わる、と言われたけれど、それは実現するのかしらん。

Android L 〜 Google I/O 2014 Keynote より

2014 年度の Google I/O 基調講演 (Keynote) は、Apple の WWDC と足並みを揃えるかのように開発者向けの発表に重きが置かれた。Android 5.0 Lolipop の発表はなかったし、Nexus シリーズの新作発表もなかった。少しばかりスマート・ウォッチやスマート・テレビといったガジェット類が紹介されたけど、発表の中心は開発者向けの SDK やサービスだった。

今年は発表内容が多い上に、一つの内容がボリュームたっぷりだった。複数回に分けて、ぼくが興味を持った点に絞ってまとめを書く。まずは Android L について。

Android L

新しい Android のスタイル。明言されなかったけど、Android 5.0 Lolipop は「Android L」なのかもしれない。リリースは今年後半を予定。プレビュー版は明日リリース。

Material Design — インターフェースの変更

L は Material Design という新しいデザインを導入する。iOS がバージョン 7 で見た目を変えてきたのと同じくらいインパクトがある。

Material Design はスマートフォン、タブレット、WEB でインターフェースを統一する。Windows の様なフラットデザインと、iOS の様な三次元効果 + アニメーションを融合させた新しいスタイル。例えば Google Now の様なカード式の見た目、更にカードをタップするとそのカードが浮き上がり少し大きくなる様に見えるアニメーションをシンプルな API で提供する。

通知センターも改良される。Google Now タイプのカード式。通知の優先度を変えられたり、通知カードを広げたり、アクション用のボタンを配置することが可能。この他、Hands-up 通知と呼ばれる「重要」な情報のみをユーザー操作に影響を与えないよう表示する機能も付いた。これはフルスクリーン時でも通知されるらしい。

ロック画面にも通知センター機能が追加される。これは、情報の種類 (プライベートか、それとも周りの人に知られても良いものか?) によって表示が変わる。通知センターと同じように全ての情報が表示されるもの。通知が来たことだけを知らせるもの。複数のパターンが用意されている。

ロック画面の解除にも新機能。Android Wear などと Bluetooth 通信することで、認証画面なしでロック解除が可能になるという。今は「時計」くらいしかガジェットが存在しないけど、この先、ロック解除を目的とした「指輪」が作られるかもしれない。

ART

Android のランタイムが従来の Dalvik から ART に変わる。ART 自身は今の Android (KitKat) でも使えるけれど、L 以降は ART がデフォールトになる。

ART に変わることで、アプリの起動時間が短くなったり、実行性能が上がったり、バッテリー消費が抑えられる。

Project Volta

Android が省電力に力を入れる。それが Project Volta。紹介されたのは 3 つの機能。

1 つ目は Battery Historian。バッテリーの利用状況を調べることが出来るツール。これでバッテリー消費の激しいサービスやアプリ、機能を見つけて改善を促すものと思われる。

2 つ目は Job Scheduler API。適切なタイミングでアプリ/サービス(?)を起動・終了させることができる。ずっと起動しっぱなし... ではなく、必要な時だけ「動かす」ことでバッテリー消費を減らすことが出来る。

3 つ目は Battery Saver。省電力モードかな。

その他

この他にも色々発表があったけど、長くなるので箇条書き。

  • 64 bit CPU 対応
  • Android Extension Pack: GPU の強化
  • 仕事用と個人用のデータを分離 (どうやるのかな?)

あとがき

Android L は、Android のスマートフォンやタブレットだけでなく、TV や Wearable にも同じ UI を提供する。機能としても、Android ファミリーの「連続性」を強く意識しているように感じた。で、どこからどこまでが「Android L」なのかが分からない。

ともかく、Android L で Google はスマホ・タブレットの世界からもっと広い「家電」へと腕を伸ばしてゆくことになりそう。普及がどれくらいのペースで進むか楽しみ。