快適 Growl 術

注目

Growl

Growl 使ってますか!Mac ユーザーの皆さん、Growl が OS X の標準機能ではないことに驚いたのも一度や二度ではありませんね!そういえば Windows 版もありますけど、使ったことないからよく知りません。

最近、Mac App Store から “Growl 1.3” がリリースされました。OS X Lion 以降に対応して170円。これを活用する『快適 Growl 術』をいくつか紹介します。


Growl があれば色んな通知が画面の端っこに表示されてとっても便利なわけですが、そもそも Growl に対応しないアプリケーションもいっぱいあります。そう、Apple 純正のアプリケーションとか。

Mail と iChat を Growl

Apple 製の Mail.app と iChat.app で Growl しちゃいましょう。この二つのアプリケーションが Growl したらとっても便利です。GrowlMail は本体から分離されましたからここでは取り上げません。[[wiki:AppleScript]] を使いましょう。

Mail

Mail

Growl with Mail

iChat

IChat

Growl with iChat

それぞれ上記のように設定しましょう。これで良い感じに Growl されますね。ちなみにこれらは Growl 1.3 と OS X Lion で動きます。古いバージョンだとちょっと変えないと動かないと思います。


適当なスクリプトを書いてコンピュータに仕事させるとき、どこまで進んでいるのか、処理が終わったのか、いちいち確認するのも面倒。そう、Growl させちゃえば良いですね。Growl 1.3 なら “GNTP (Growl Notification Transport Protocol)” に対応しています。これはネットワーク経由の通知を可能にし、さらに Windows 版とも互換性があります。これを使いましょう。

Python と Ruby から通知

Python でも Ruby でも、GNTP を利用して Growl するためのライブラリが公開されています。それを用いて、ライブラリがインストールされていれば Growl 通知し、そうでなければ標準出力にメッセージを表示するメソッドを定義してみましょう。

Python

Python

Python では gntp モジュールを使います。

pip install gntp
def notify(title, message):
    try:
        import gntp.notifier
        
        growl = gntp.notifier.GrowlNotifier(
            applicationName="Python/GNTP",
            notifications=["notify"]
        )
        growl.register()
        
        growl.notify(
            noteType="notify",
            title=title,
            description=message
        )
    except ImportError:
        print(title + ": " + message)
    
notify("Title", "Message")

Ruby

Ruby

Ruby では ruby_gntp クラスを使います。

gem install ruby_gntp
def notify(title, message)
  begin
    require 'ruby_gntp'
    
    growl = GNTP.new("Ruby/GNTP")
    growl.register(:notifications => [{
      :name     => "notify"
    }])
    
    growl.notify(
      :name  => "notify",
      :title => title,
      :text  => message
    )
  rescue LoadError
    puts "#{title}: #{message}";
  end
end

notify('Title', 'Message')

これでタイトルとメッセージを通知できました。ライブラリがない場合でも何となく使える感じですね。GNTP を使っているので Windows でも動くはずです。


Automator

Automator

[[wiki:Automator]] からも Growl できます。簡単ですね。

Automator


気付かないといけないことに気付くことのできない皆さん、知らないうちに大切なことは過ぎ去っていきます。がんがん Growl していきましょう!

Fortran プログラムで変数の型に関するバグ

研究室の同期が Fortran のプログラムを書いていて、数日間解決できずに悩んでいたバグを修正した。LL のスクリプトばかり書いていてメモリの扱いを考慮することを忘れ、修正に時間がかかってしまったので、自戒を込めて概略をまとめる。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
program main
    integer :: var_a = 0
    integer :: var_b = 0

    call foo(var_a, var_b)
end program

subroutine foo(var_a, var_b)
    real(8) var_a
    integer var_b

    var_b = 123
    var_a = 0

    write(*, *) var_b !=> 0
end subroutine

上記はできる限り簡略化した Fortran のコード。このコードの15行目で、標準出力に var_b の値を表示すると、12行目で 123 を代入しているにも関わらず値が 0 となっていた。

最初サブルーチンの中身だけを追っていて、何度も問題が無いことを確認した。あるとき var_a の値を変えると var_b の値まで連動して変わることに気付き、ようやく何が起こっているか理解。サブルーチンを呼び出す方の、サブルーチンに渡される引数の型を見ると、サブルーチンと一致していない。メインプログラムでは var_ainteger で整数型、4 bytes。サブルーチンの var_areal(8) で実数型の 8 bytes。

サブルーチンに変数の先頭アドレスが渡って、そのあとメモリ空間上のどこまでがその変数の長さなのかは、その変数の型によって決まる。従って長さの違う型で変数が再定義されると、先頭アドレスから間違った長さまでをその変数として用いてしまう。

概略図を以下に掲載する。右側はメモリ空間の一部を、左から 4 bytes ずつに区切ったものとして表記した。ただし簡単のため、1 byte を10進数のように書いてある。

原因が分かり、var_areal(8) である必要があったため、以下のように修正。問題が解決した。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
program main
    real(8) :: var_a = 0
    integer :: var_b = 0

    call foo(var_a, var_b)
end program

subroutine foo(var_a, var_b)
    real(8) var_a
    integer var_b

    var_b = 123
    var_a = 0

    write(*, *) var_b !=> 123
end subroutine

コンパイラによってメモリ空間の扱いが変わるため、このようなバグを作った場合に原因の特定が困難。サブルーチンの内外で変数の型が合致しているか要注意。

追記

研究室の先輩 @tk4terui さんに、コンパイラのオプションをちゃんと付けると、コンパイル時に警告してくれる情報を教わりました。GCC の Fortran コンパイラ ‘gfortran’ では -Wall または -Wconversion オプションを付けると

1
2
3
4
5
6
7
$ gfortran -Wconversion test.f90

test.f90:13.12:

    var_a = 0
           1
Warning: Conversion from INTEGER(4) to REAL(8) at (1)

という感じでちゃんと警告されます。便利。

Ruby + Nokogiri で 気象庁スクレイピング

このあいだの連休中に『たのしい Ruby』を読んで、まあまあかっこよく [[wiki:Ruby]] 書けるようになったから書いてみた。Ruby は 1.9.2 使った。

気象庁 | 過去の気象データ検索

ブロック付きでもなしでも何となく使える感じ。

Ruby はじめてちゃんと勉強して、全部オブジェクトなのはかっこいい。ブロック使うのちょっと慣れるまで気持ち悪かったけど、慣れると便利。

TextMate と BBEdit と行き来しながら書いたけど、TextMate の方が便利。

App Store でのアップグレードについて

アサイド

昨日、@frnk さんと話してて話題になったことであるが、App Store でアップグレード価格を設定できるようになる気がする。明確な根拠のない推測ではあるものの、そう考えられる事由を述べる。

iWork のメジャーアップデートがリリースされていないことがずっと気に掛かっている。iLife の Lion 対応マイナーアップデートが Lion リリースの少し前だったのに比べ、iWork は Lion がリリースしてからマイナーアップデートされた。そうする理由も思い当たらないし、ぎりぎりの判断でその様にしたのではないかと思われる。Lion 対応は NSDocument ベースであるはずの iWork では難しいことではないだろうから、iWork のメジャーアップデートを何らかの事情で先延ばしにしようと決定されたのではないだろうか。

iWork の次期バージョンでは、もちろん Pages の縦書き対応などもあるだろうが、iOS 版との連携強化として iCloud への対応が予想される。すなわち次期バージョンは Snow Leopard 非対応で、Lion 以降の OS を要件とする蓋然性が高い。そしてリリースのタイミングは iCloud が公開されるときであろう。

ここで気になってくるのは、当然 Mac App Store からリリースされるであろう iWork は、過去のバージョンを買った人に対しても通常価格で提供されるのか、それともアップグレード価格を用意するのか、ということである。これは Mac を買うとプリインストールされている iLife とは事情が異なる。そこで、アップグレード価格になるのではないかという予想につながる。

同様に Mac App Store でリリースされている Final Cut Pro X について、Apple は以下のような FAQ を掲載している。

次回のメジャーリリースでは、高度なマルチカム編集のサポートを提供します。
Finale Cut Pro X — よくある質問にお答えします。

これは Mac App Store でリリースされた Apple 製ソフトウェアに、メジャーアップデートが存在することが示唆されている。Final Cut Pro X のような価格帯のソフトウェアで、アップグレード価格が存在しないということは考えにくい。

iCloud が発表され、Mac App Store や iOS の App Store で、購入済みのものが分かるようになった。これは単に App Store のシステムがそれに対応しただけのことであるはずだが、iCloud の一部として発表された。

これらの事柄を総合的に見て、App Store でアップグレード価格を設定できるような未来が見えてくるのではないだろうか。それもおそらく、この秋に iCloud が公開される頃。

4 Minutes iPhone App Development

一ヶ月と少し前に AUGM Sapporo で、FileMaker ProFileMaker Go のスクリプト機能なら素早く iPhone で動くアプリ的なものを作れます……というようなデモをなさった方(FileMaker Pro のユーザーグループの方)がいらっしゃって、そのときに、「iPhone アプリを開発されている方で、これ(デモで行った Hello World)より早くできるという方がいらっしゃったら是非お知らせください」というようなことも仰っていたので、やってみた。4分弱でシミュレータで動かせる。実機への転送はプロビジョニングファイルさえ用意しておけばプラス数分だと思う。

あ、まだまだ甘いのは初心者なので許してください ><

画面の記録から編集、YouTube への公開まで、今日新しいバージョンがリリースされた ScreenFlow 3 を使用しています。

ああ、それで別に Objective-C/Cocoa touch の方が早くて良いとかそういうこと言いたいんじゃないです。既存のデータベースと連携するなら FileMaker 製品はとても良い選択肢なんだと思う(持ってないけど)。ただネイティブ環境でも Hello World くらい一瞬で書けるし、やろうと思えばいくらでも複雑なことができる。だからまあ、やりたいことに合わせて適切な道具を選び、しっかり勉強していきましょう。

Google+ 所感

アサイド

[blackbirdpie id=”86268863318204416″]

Google+ が始まって1週間ほど経ちました。@ntwojp さんのおかげで早くに招待していただけて、いろいろ試せています。

Google+ というサービスをユーザー視点から見ると、結構使いやすいネットワーキングサービスです。Facebook のあの仰々しさがない、mixi ほど退屈じゃない、Twitter よりはいろいろできる、ある意味特徴のない、ネットワーキングサービス。機能的にはシンプルな Facebook というところで、でも結構これくらいが良いのかも、って思わせてくれる。

じゃあ Web の世界から Google+ を解釈すると、冒頭。

ここ数年、「ソーシャルネットワーキングは Web 検索を殺すのか」という命題がこの界隈には立ちはだかっています。Google の検索ボックスに適切なキーワードを入力することができない人が大勢いるという現実があって、それはインスタント検索とかそういう技術的なアプローチからの改善もあるんだけど、でも結局、人に聞いた方が早いことも多い。Facebook とか Twitter でなんか書けば、なんか返ってきたりする。

Google にとって、その検索アルゴリズムの敗北は到底認められるものじゃありませんから、アルゴリズムの改善が至上命題となります。そう、検索アルゴリズムにソーシャルネットワークを組み入れる、これが Google +1 ボタン です。これから我々は、検索結果に知り合いからのオススメが反映されているのを頻繁に見るようになるし、自分自身も +1 ボタンで Web ページをオススメするようになる。

これは素晴らしいのだけど、じゃあその知り合いを示す「ソーシャルグラフ」をどうするか、+1 ボタンを押すモチベーションをどうするか、みたいな問題が残りますから、Google 謹製ソーシャルネットワークが導入されました。Google+。

すなわち Google+ は Google による Google プラットホームです。Google のあらゆるサービスがここに集約され、回帰していきます。

Google+ が理解できたところで、Google+ ユーザーの皆さんはぼくの Google+ プロフィールからサークルに追加するなどすると良いと思うし、まだ Google+ を利用できない皆さんは Google アカウントを準備して、早く招待されるように祈りながらそのアカウントをぼくに教えておくなどすれば良いと思います。招待機能が早めに復活してユーザーが増えないとネットワーキングサービスはつまらないし、がんばろう Google!!!!!

Apple のリリーススケジュールを予想する

アサイド

Lion

Mac OS X Lion1 は、現時点で Developer Preview 3 までが開発者向けに公開2されており、2月末3からおよそ1ヶ月毎に数字が増えている。6月はじめの WWDC4 では間違いなくリリース日が発表されるであろう。そこで開発者向けに GM Seed を公開して、間を置いて6月末頃に正式リリースか、またはお得意の “Available Today” か。Mac App Store での公開5なら、物理メディアを製産する期間は考えなくて良いからそれも考えられる。反対に物理メディアを製産するなら、完成から1ヶ月程度は間が開いてもおかしくはない。

iOS 5

iOS は開発者向けに Beta バージョンが公開されてから、およそ2ヶ月から3ヶ月後に正式リリースが慣例6であった。従って WWDC で発表及び Beta リリースが行われ、8月から9月に正式リリースと見るのが妥当。しかし Apple のリソースが Lion に大きく割かれているであろうことを鑑みると、もう少し遅れることもまた十分想定される。

iPhone 5

iOS 5 とほぼ同時期なのはまず間違いない。やはり8月から9月か。当然 A57 やカメラのアップグレードはあるだろう。名前については、iPhone 4 や 大きな変更点がなかった iPad 2 など、ハードウェア的なメジャーアップデート毎に数字を増やす方向性に変わっていることから、iPhone 4S などではなく iPhone 5 となる蓋然性が高い。

iPad 3

来年の春くらい。Retina Display8 に対応して今年中という憶測もあるが、Apple ならそういうことはせず、順当なリリースサイクルを守るだろう。

まとめ

  1. Lion: WWDC 開催中か、または6月末。
  2. iOS 5: WWDC で発表、Beta リリース。8月から9月正式リリース。
  3. iPhone 5: 8月から9月頃。
  4. iPad 3: 来年春。

  1. 2010年10月20日、Apple は Special Event “Back to the Mac” にて、次世代 Mac OS X である “Lion” が発表、デモンストレーションがあり、2011年夏にリリースされると予告。 
  2. 2011年5月13日、Developer Preview 3 が公開された。 
  3. 2011年2月24日、最初の Developer Preview が公開された。 
  4. Apple が毎年開催する開発者向けイベント “World Wide Developers Conference” で、2011年は “Join us for a preview of the future of iOS and Mac OS X.” という予告がある。5月31日付けのプレスリリースでは、WWDC 初日の現地時間6月6日午前10時に Apple CEO Steve Jobs 及び幹部らによる基調講演で、Lion や iOS 5 及び iCloud についての発表が予定されている。 
  5. Mac OS X 10.6.8 のデベロッパービルドから、Mac App Store から Lion を入手できると解釈できる内容のリリースノートが見つかっている。 
  6. 2008年3月6日、iPhone OS 2.0 の Beta 版が公開、同年7月11日、正式リリース。また翌年、2009年3月17日に iPhone OS 3.0 の Beta 版が公開され、同年6月17日に正式リリースされている。2010年4月8日には iOS 4 の Beta 版が公開 され、同年6月21日に正式リリースされた。 
  7. Apple A5 はひとつのチップに CPU、GPU、メモリなどをパッケージした SoC (System on a Chip) で、A4 の後継であるこのチップでは CPU 部分がデュアルコア化されるなどの改良が為されている。 
  8. Retina Display は iPhone 4、iPod touch などに搭載されている高精細ディスプレイ。326 ppi という解像度は、人間の目では一つ一つのピクセルを認識できないと謳われている。 

Autocompleting username UI

2006年にサービスが開始されてから怒濤の勢いで普及し、いまや Web 上で誰も彼もが利用している Twitter。そしてサービスを便利に利用するため、世界には数多くのクライアントソフトウェアが蔓延っています。これらを全て把握することは、困難の域を通り越して、もはや不可能と言っても過言ではありません。そんな中、Mac や iPhone、iPad 上で世界的に流行っているクライアントを独断でいくつか選び、メンションを送るときなどに便利なユーザー名補完機能に焦点を当て、その UI を比較してみたいと思います。

Twitter

Twitter Inc.atebitsTweetie を買収し、公式クライアントとして無料で配布しているもので、Mac、iPhone、iPad それぞれに提供されています。

Twitter for Mac version 2.1

Mac App Store から配布されています。最新のバージョン2.1でユーザー名補完機能が搭載されました。“@” を入力するとすぐ下にアイコンとユーザー名のリストが表示され、文字を入力する毎にインクリメンタルに候補が絞られていきます。ここから選択することでユーザー名が入力されます。キーボードからもアクセスしやすいように配慮されていることにも注目です。

Twitter for iPhone version 3.3.4

iPad 版とはユニバーサルで、App Store から配布されています。“@” の描かれたボタンを押すか、“@” を入力することでリストが表示され、やはりインクリメンタルに候補が絞られます。これをタップするとユーザー名が入力されます。

Twitter for iPad version 3.3.4

iPhone 版と同じように動作します。

公式クライアントでは、iOS 版で “@” ボタンによるアクセスが用意されているほかは、Mac 版も含めた3つでほとんど同じように動作しています。また “#” から始まるハッシュタグでも、同様の補完機能が用意されていることも付け加えておきます。

公式クライアントという特性上、Twitter Inc. が想定する Twitter サービスの使い方に沿って各機能が実装されているという印象を強く感じます。

Twitterrific

Twitterrific は Iconfactory が世界で 初めて Mac 向けに作ったクライアントに端を発するソフトウェアです。現在のバージョン4シリーズでは、Mac OS X の Cocoa フレームワークに iOS の Cocoa touch フレームワークを移植することを目的とした、“Chameleon Project” という彼らが主催するオープンソースのプロジェクトによって、Mac 版と iOS 版でコードベースの多くを共有しており、そのためそれぞれの機能や UI はとても似通ったものになっています。またどのプラットホームでも基本は広告付きの無料版であり、Mac では Mac App Store で有料版を購入するか Iconfactory のサイトからプロダクトキーを購入することで、iOS 版ではアプリ内課金で、それぞれ広告を非表示にすることができます。

Twitterrific for Mac version 4.1

“@” に続けてユーザー名を入力することで、Tweet を書き込む欄の下側にアイコンとユーザー名の候補が横に並んで表示され、インクリメンタルに絞り込まれていきます。この横に並んでいるのが特徴的で、ちゃんとスクロールもします。

Twitterrific for iPhone version 4.1

Mac 版と同じく、候補が横に並びます。候補がキーボードのすぐ上に位置していて、選択するときにあまり指を移動しなくても良いように配慮されています。

Twitterrific for iPad version 4.1

iPhone 版と同じ感じです。

Chameleon Project によって、ユーザー名補完についてもプラットホームを問わず同じような UI になっていることが分かります。マウスカーソルを前提にした UI と、タッチを前提にした UI ではそもそもまったく考え方が異なるため、果たしてこの同じような UI であるということがどういった意味を持つのか、十分議論が必要な部分ではありますが、それでも Twitterrific では最低限の調整は加えられていることが伺えます。

また横に候補を並べることにより、ユーザー名の長さが短い場合に表示面積を節約できるというメリットが生まれています。これは副次的に、人間の認知の中でユーザー名の長さがある一定の役割を果たしていると仮定すれば、目的のユーザー名を見つけやすいという効果が得られている可能性があります。

Tweetbot version 1.1

iPhone 向けのアプリを自立するロボットのキャラクターに見立て、次々と独創的な UI と共に送り出してきた Tapbots が挑んだ Twitter クライアント、それが Tweetbot です。鳥型のロボットに見立てられたこのアプリは、これまで同様に特徴的な UI を備えています。全体的なレイアウトは公式クライアントを下敷きとしているように見受けられますが、随所に独特の工夫がみられます。

自動補完の UI は、“@” を入力すると現れる吹き出し風のボタンか、またはキーボードのすぐ上に表示されているツールバー上のボタンを押すことで表示されます。これはモーダルに画面を覆って、インクリメンタルにユーザーを検索するようになっています。

基本的には公式クライアントと同じ構成ですが、“@” を入力したあとにもう1ステップ、ボタンをタップするという動作が加えられています。これは排他的にに検索画面が表示されるため、“@” をユーザー名以外に使いたいとき、すぐに画面遷移しては困ることから、明示的にそれがユーザー名であることを指示するという意味合いがあるのだと考えられます。しかしこれは排他的な検索画面を表示することで起きる問題であり、公式クライアントがそうであるように非排他的な選択肢を提供すれば、1ステップ操作を減らせるのではないかと思われます。排他的に検索画面を表示しなければならない合理的な理由があるとは思えませんし、検索するという UI に何かこだわったのかもしれません。

Designing of UI

ここまで大きく分けて3種類、プラットホームも分けると7種類の UI を見てきました。それぞれ少しずつ、機能の見せ方が違っていました。多くの部分が似通っているのは、この機能自体がある程度その見せ方を規定しているからであると考えられます。逆にこの少しずつの差異は、その開発者が何を考えてデザインしているのかを知る手がかりとなります。

UI のデザインとは、すなわち機能そのもののデザインであると言っても過言ではないでしょう。利用者にとってはその実装に関わらず UI こそが機能です。ですから、ひとつの機能をソフトウェアに追加するとき、機能を実装することよりその UI を実装する方がよほど神経を使うことも少なくありません。デザインとはそれほど重要なことなのです。機能の働きが正しく利用者に伝わるように、そしてそれが不便を強いたりすることのないように。

[blackbirdpie id=”69091587338153984″]

コロラド大学からのサバイブ — コーディング編

前回の準備編に続いて、今回はコーディングに移りますが、まず最初に完成形となるコードを掲載します。

# coding: UTF-8

import os
import datetime
import mechanize
import urllib

# Set directory name.
directory_name = "images"

if not os.path.isdir(directory_name):
    os.mkdir(directory_name)

# Set dates.
start_date = datetime.date(2005, 1, 1)
end_date = datetime.date(2010, 12, 31)

current_date = start_date

while current_date <= end_date:
    
    print current_date
    
    browser = mechanize.Browser()
    browser.set_handle_robots(False)
    
    # Open web page.
    response = browser.open("http://argo.colorado.edu/~realtime/modis/")
    
    # print "=== HTML Source ==="
    # print response.read()
    
    # Check forms.
    # print "\n=== Fomrs ==="
    # for form in browser.forms():
    #     print form
    
    # Select first form.
    browser.select_form(nr=0)
    
    # Set day.
    browser["month"] = [current_date.strftime("%m")]
    browser["day1"] = [current_date.strftime("%d")[0]]
    browser["day2"] = [current_date.strftime("%d")[1]]
    browser["year"] = [current_date.strftime("%y")]
    # Set location.
    browser["alon0"] = "135"
    browser["alon1"] = "160"
    browser["alat0"] = "30"
    browser["alat1"] = "45"
    # Set options.
    browser["day_opt"] = ["7"]
    browser["cont_opt"] = ["T"]
    browser["cont_anot"] = ["T"]
    
    # Check forms.
    # print "\n=== Forms ==="
    # for form in browser.forms():
    #     print form
    
    # Submit.
    response = browser.submit()
    
    # print "=== HTML Source ==="
    # print response.read()
    
    # Check links.
    # print "\n=== Links ==="
    for link in browser.links():
        # print link
        if link.url[-4:] == ".gif":
            print link.url
            urllib.urlretrieve(link.url, directory_name + "/" + current_date.isoformat() + ".gif")
    
    current_date += datetime.timedelta(7)

print "Ended."

ここからはこのコードを目指して、どういった手順で書いていくかを説明します。 続きを読む