Mac OS XのBlogライター、Petrus Bloggerを試してみる

Blogger付属のWYSIWYGエディターを使っていると、Preタグの中身の空白が消えたり化けたりすることがあることが分かったため、やむなくBlogger付属のエディターを使うことが出来なくなってしまいました。

そこで、外部のBlogエディターを導入してみることにします。

---

■タイトルのテスト
タイトルはfontタグになるみたいです

目についた機能を列挙してみると、

• Bloggerの機能と連携していて、アプリケーションのメニューからBloggerのDashboardを一発で開いたり出来る。過去記事の編集も可能
• HTMLタグの入力補助や入力補完は一切無い
• 画像のアップロード補助も一切無い
• BloggerのLabelに関しては完全にサポートしている、入力補完はないが入力補助がある

@interface PreTagTest
    NSString *test1;
    id delegate;
@end

@property (retain)NSString *test1;
@property (assign)id delegate;

画像アップロードテスト

↑Edit > Upload Photoを実行するとこのリンクが自動的に張られるのですが、見ての通り表示できません。


Blog > Albumsを押すとアルバム全体が開くので（全体です、二度目以降はキャッシュしているみたいですが、1回目はむちゃくちゃ待たされます）、それから写真を選んでPicasaのページを開き、さらにそこから自分でリンクを拾ってきてようやく表示できます。
使い物にならん・・・orz

ううん、なかなか便利なんですが、編集機能がちょっと弱すぎる感じがしますね。せめてタグの挿入ぐらいはしてくれないとなぁ。画像もドラッグ＆ドロップでサクッと入れたいです。

Google App Engineのcronサポートまとめ

http://code.google.com/intl/en/appengine/docs/python/config/cron.html

■注意
以下の情報は2009/04/09現在（Google App Engine 1.2.0.0）の情報です。皆様がごらんになっているときには古くなっている可能性があります。

---

■時間指定方法
cron.yamlを書く
本家cronとは記法が異なるが、本家cronとほぼ同様のスケジューリングが可能
起動タイムゾーンの指定も可能

cron:
- description: daily summary job
  url: /tasks/summary
  schedule: every 24 hours
- description: monday morning mailout
  url: /mail/weekly
  schedule: every monday 9:00
  timezone: Australia/NSW

■認証
cronによって起動されたURLはadminユーザーによって起動されるため、以下の
2種類の方法で認証が可能
app.yamlのhandlers要素にlogin: adminを指定する

application: hello-cron
version: 1
runtime: python
api_version: 1

handlers:
  - url: /report/weekly
    script: reports.py
    login: admin

2009/04/13追記、以下の方法は利用できません。詳しくはこちらの記事をご覧ください。ご迷惑をおかけいたしまして申し訳ありませんでした。
アプリケーションのRequestHandler内で、users.is_current_user_admin()を利用して判定する（こちらの方法は未確認）

from google.appengine.api import users

# ログインしていない場合やadmin以外の場合にはFalse。adminがログインしている場合のみTrue。
if users.is_current_user_admin():
    # cronジョブをここで実行
else:
    # エラー画面を表示するなど

さらにcronはURLを起動する際にHTTPリクエストヘッダーに以下の要素を付けるため、RequestHandler内でヘッダをチェックすることが出来る

X-AppEngine-Cron: true

■cronタスクの管理方法
cronタスクをアップロードするには、通常のアプリケーションをアップロードするときと同様に以下のコマンドを実行すれば、アプリケーションと一緒にアップロードされる

appcfg.py update

cronタスクだけをアップロードしたい場合場合は以下のコマンドを実行

appcfg.py update_cron

cronタスクを削除したい場合は、cron.yamlを以下のように書き換えてからアップロードすればよい

cron: 

以下のコマンドを実行すれば、現在のcronの設定状況を見ることが出来る（ただし、タイムゾーンを扱う場合はpytzライブラリが必要）

appcfg.py cron_info

■制限

• 今のところPython版のみ（Java版はない）Java版もある。Java版はcron.xmlを記述する。http://code.google.com/intl/ja/appengine/docs/java/config/cron.html
• タスクは20個まで
• 最短実行間隔は1分
• cron.yamlから起動できるのは自アプリのURLのみ。人のアプリを起動したり、全然関係ないURLを指定したり、シェルスクリプトを起動したりは出来ない
• cronから対象URLを起動した場合のCPU時間・通信量もすべて従量対象になる

canvasとJavaScriptでゲームなど(2) タイトルつけてみました

http://akisuesandbox.appspot.com/games/zzz
（前回とパスが変わってます、注意）

前回のゲームに悪のりしてタイトルをつけてみました。

ついでにソースコードも公開してみました。まぁ、JavaScriptなので意図しようとも意図すまいとも自動的にオープンソースになってしまいますけれども、一応ｗ
http://github.com/akisute/gae_akisutesandbox/tree/master

---

以下、余談。

ゲームの画面を制御するにはループと入力受付を制御しなくてはならないのですが、
JavaScriptを用いると、
ループの制御はsetIntevalとclearInterval
入力受付の制御はhogehoge.onmousemoveとかhogehoge.onmousedownに適切なファンクションをセットする
ことで制御が出来るので比較的簡単な気がします。

すごーく昔にDirectXでプログラムを作ったときに
このあたりの制御をするのが余りにも面倒で（といいますか手続き型のプログラミングが面倒で）嫌になって辞めてしまった記憶があります。

最近のゲーム開発環境はどうなんでしょう。特にiPhoneのゲーム開発フレームワークとか大いに気になります。

canvasとJavaScriptでゲームなど

http://akisuesandbox.appspot.com/welcome/zzz

こんなの作ってました。中身は無いに等しいです。

---

以下駄文。

canvasとJavaScriptは思っていたよりは高速に動作しますが、やはりFlashに比べると遅いです。
ですが２Dグラフィックスの勉強にはcanvas + JavaScriptのほうがFlashより向いていると思います。Flashはかじった程度ですが、２Dグラフィックス（線引いたり四角描いたり）というよりはオブジェクトとアニメーションの制御が中心のような印象を受けました。

Your mobile device has encountered an unexpected error (0xE800003A)

いつになってもこのエラーの対処法が覚えられなくてGoogle先生にお尋ねすることになっているので、ここに備忘録を記しておきます。

１．info.plistのBundle identifierとProvisioning ProfileのApp Identifierを一致させる


これはネットのどこを見ても書いてある情報なので大丈夫だと思いますが一応。
面倒ならば、裏技的手法として、Provisioning ProfileのApp Identifierを*だけにするという手段があります。こんな風に。

ABCDEFGHIJK123.*

この方法だとオープンソースのプロジェクトを拾ってきたときでもすぐに実機インストールすることができるので、いちばんお勧めかもしれません。


２．クリーニングする（Shift+Command+K）

で、１．は毎回試すのですが、それでもうまくいかないので次はこれ。クリーニングを行います。
もしくはプロジェクトフォルダ以下のbuildディレクトリの中身をすべて消してしまっても同様の効果が得られます。


今のところこの二つを試したら毎回うまくビルド出来ているので、とりあえずはこれで大丈夫かと思います。

Pythonで、特定のディレクトリ以下にあるすべてのモジュールをインポートする方法

Pythonで特定のディレクトリの下にあるすべてのモジュールをインポートしたいときの方法。
これもGAEOのソースから見つけました。

def initPlugins():
   """
   Initialize the installed plugins
   """
   plugins_root = os.path.join(os.path.dirname(__file__), 'plugins')
   if os.path.exists(plugins_root):
       plugins = os.listdir(plugins_root)
       for plugin in plugins:
           if not re.match('^__|^\.', plugin):
               try:
                   exec('from plugins import %s' % plugin)
               except ImportError:
                   logging.error('Unable to import %s' % (plugin))
               except SyntaxError:
                   logging.error('Unable to import name %s' % (plugin))

キモは二つ。

1. os.listdirで特定のディレクトリ以下のすべてのファイル名・ディレクトリ名を取得する
2. 取得したディレクトリ名を使ってimport文を生成して、exec()で実行する

exec()で無理矢理実行とか正直嫌な感じです。しかしこれ以外に方法はなさそうですね・・・
ファイル名を使ってコマンドインジェクションとかできそうじゃないかと試してみましたが、そもそもファイル名には改行とかバックスラッシュとかが使えないので意外と安全かも。

GAEOでPythonのunittestモジュールを使って単体テストにチャレンジ

■まとめ
site-packagesにインポートするモジュールとかまとめておくのが使うのがいちばん楽


■何がしたいか
以下のようなGAEOプロジェクトがあります。



ここで、test.controller.forecastareaTest.pyにforecastareaモジュールのテストケースを記述するためには、applicationディレクトリにPYTHONPATHを通す必要があります。
それをいちばんスマートにやるにはどうすればよいかいろいろ悩んでました。


■どうしてそこで悩むの？
forecastareaTest.pyは単体で動作させなくてはいけないからです。
もしここで、jweeklyforecastディレクトリの直下にテストケースをおくことが出来るのであれば、

application_root = os.path.join(os.path.dirname(__file__), 'application')
test_root = os.path.join(os.path.dirname(__file__), 'test')
sys.path.append(application_root)
sys.path.append(test_root)

from application.controller import ForecastareaController
from test.controller import TestForecastarea

こんな風に自分のディレクトリからのパスをsys.pathに追加してからインポートすれば一発です。applicationもtestも自分の子供ディレクトリですから楽です。
しかしforecastareaTest.pyの位置から見ると・・・

application_root = os.path.join(os.path.dirname(__file__), '../../../application')
sys.path.append(application_root)

from application.controller import ForecastareaController

こんな風にインポートしなくちゃいけなくなります。相対指定とかする必要があって、ちょっとやな感じです。

PROJECT_HOME = '/User/akisute/DropBox/Projects/GoogleAppEngine/jweeklyforecast/'
application_root = os.path.join(PROJECT, 'application')
sys.path.append(application_root)

from application.controller import ForecastareaController

これでもいいのですが、これだとPROJECT_HOMEが各テストケースごとにべた書きになってしまいます。これまたディレクトリの移動に弱いです。
ディレクトリが動いたらテストケース100件の定数を全部書き直しとか嫌すぎです。


■最終的に出した結論がこれ
site-packagesディレクトリの中にjweeklyforecast_path.pyなる以下のようなモジュールを配置。

#!/usr/bin/env python
#encoding: utf-8
import os, sys

PROJECT_HOME = '/Users/akisute/Dropbox/Projects/GoogleAppEngine/jweeklyforecast'
sys.path.append(PROJECT_HOME)
sys.path.append(os.path.join(PROJECT_HOME, 'application'))

そしてこれを各テストケースからインポート。
するとapplicationディレクトリにパスが通るからインポートして使えるという仕組みです。

#!/usr/bin/env python
#coding: utf-8
import logging
try:
    import jweeklyforecast_path
except Exception, e:
    logging.warn("jweeklyforecast_path not found.")

import unittest
from controller.forecastarea import Forecastarea

class TestForecastarea(unittest.TestCase):
    """Forecastarea test case.
    """
    #以下テストケースがずらずらと続く・・・

ディレクトリが動いたり環境が変わったときには、このjweeklyforecast_pathをsite-packagesにコピーして、中身のPROJECT_HOMEを書き直すだけですみます。


■最後になりましたが
意味不明な記事になってしまってごめんなさい。自分の理解度不足ゆえグダグダになってしまいました＞＜

GTDで己の無知の知を知る

OmniFocusを導入していちばん大事だと思ったことなのですが、
GTDを実践していると、「実はびっくりするぐらい自分は何も分かっていない」ということが明らかになります。

どういうことか？
と申しますと、

たとえば今開発しているアプリに新機能を追加したので、テストしたいと考えています。
ですからまずはOmniFocusに「〜をテストする」という考えを追加します。

これだけでは行動に落とし込めないので
「テストクラスを書く」
「テストクラスをTextMateから実行する」
といった行動レベルに分解する必要があるのですが、

ここでふと「テストクラスを書くって、どうやるんだっけ」とか
「TextMateからテストを実行するショートカットってどうだったっけ」とか
そういう疑問が次々にわいてくるわけです。

だからそれらの本筋アクションを実行する前に、
「Pythonのunittestの使い方をネットで調べる」
「サンプルコードを動かして学ぶ」
「TextMateのショートカットを調べてEvernoteにメモする」
というような雑用作業が次々に出てきてしまいます。

今までの自分は、こういう「調べる」とか「学ぶ」というアクションを
全く思考に入れずにプログラムを作ったり仕事をしたりしていました。
これが今までずっと「なぜか知らないが、たったこれだけしか仕事の量がないのにどうしてこんなに時間がかかるのか」と思っていた原因なんだなぁと独り合点しています。

おかげさまで、今では「自分は何も知らないのだから時間がかかる」という風に考えられるようになり、仕事が進まないストレスも減ったかなーと。

pythonで、Objective-Cのカテゴリのように、あるクラスのソースを変更せずに任意のメソッドを追加する方法

■結論
すべてのクラスには__bases__という隠しフィールドがあるので、そこに任意のスーパークラスを作って追加する


■何がしたいか
たとえば以下のようなクラスがあります。

class Foo:
def do_something(self, x):
  print x
  return

このクラスのソースコードに指一本触れずに以下のメソッドを追加したい。

  def another_method(self, x, y):
  print x+y
  return

って将軍様が言っていたので、一⑨さんは考えました。


■チーン！ひらめいた！
まずは以下のようにスーパークラスになるクラスを作ります。

class SampleCategory:
def another_method(self, x, y):
  print x+y
  return

そしてここからがポイント。__bases__というTupleに、今作ったスーパークラスのtype型を追加します。
スーパークラスを宣言した後で・・・

from com.akisute.example import Foo
Foo.__bases__ += (SampleCategory,)

これだけです。
なぜかこれでうまくいくのがPythonのふしぎ。

実際のソースコードの例は以下のようになります（以下、拙作のプログラムから抜粋）

#!/usr/bin/env python
# encoding: utf-8
"""Login Authentication plugin.
Extends BasicController to give it an additional function for authentication
using Google account.
"""
import sys
import os

class LoginAuthPlugin:
    def is_login(self):
        """Returns True if requesting user is logged in."""
        #Do some work here
        return false

from gaeo.controller import BaseController
BaseController.__bases__ += (LoginAuthPlugin,)

JavaScriptのprototype書き換えにも似ていますね。
ただしprototype書き換えに比べて優れているのは、__bases__はTupleなので、簡単に好きなだけスーパークラスを追加することが出来ます。
（prototypeだと複数のスーパークラスを追加するのがきわめて困難）

from com.akisute.example import Foo
Foo.__bases__ += (SampleCategory,)
Foo.__bases__ += (AnotherCategory,)

■元ネタ
GAEOでpluginを読み込んでBaseControllerを拡張するときにこのテクが使われていました。
GAEO作った人は凄い。

Firebugのconsole APIを使ってLoggerもどきを作ってみた

突然ですが、Firebugのconsole APIは凄く便利です。

console.log("abesi");
console.debug("object:%o, decimal:%d, float:%f", anObject, count, Math.PI);

問題はこれ、Firebugがインストールされていて、かつコンソールが有効になっているとき以外は
エラーになってしまいます。
（consoleというオブジェクトがないから）
これをなんとかしたい。
それからついでに、せっかくlog, debug, info, warn, errorと5つも種類があるので、ログレベル制御もしてみたい。

ということで思い立ったが吉日、車輪の再発明をしようということで、ちょっとLoggerもどきを書いてみました。
http://gist.github.com/79018

使い方はこんな感じです。

    //Get logger
    var logger = new Logger(Logger.LEVEL_DEBUG);

    logger.debug($("abesi"));
    logger.info(hidebu);
    logger.warn("tawaba=%d", 100);

ログレベル制御をしているので、ログレベルをInfoにするとdebugログが出なくなる・・・はずです。
JavaScriptのprototypeなんて触ったのは実は人生初なので問題点が多々あるかと思いますが、まぁ、せっかくですから、どうぞお使いください。

MacとiPhone向けの高機能GTDツール、OmniFocusを使って、ThinkingRockと比べてみました

• 非常にMac的なショートカットと、GTDツールというよりアウトラインプロセッサーのような操作感覚に慣れるまでが大変だが、慣れてしまえば大変高速にタスクを収集・処理できる優良ソフト=OmniFocus
• 名前の通り、フォーカス能力が超強力。自分が今何をしているか、何をするべきかに一瞬でフォーカスできる
• 「次に今すぐ行動可能なアクション」だけが目の前に表示される快感
• Macのどこからでもショートカットキー一発でタスクを収集できる機能や、現在の検索条件および画面設定をパースペクティブとして保存できる機能など、地味に便利な機能がそろっている
• 入力補完がかなり高レベルのできばえで気持ちよく使える。Remember the Milkと同等以上
• 日本語版のOmniFocusは翻訳が狂っていたり日付指定フォーマットに一部問題があるので、英語版を推奨
• 欠点は高すぎることと、Mac+iPhoneの環境が前提になっていること（それ以外の環境で利用できない）
• 安くてどこでも使えるシステムを構築したい方にはThinkingRock + Remember the Milkをお勧め

つい先日にThinkingRockを使いはじめた旨の記事を書いたのですが、
アレからしばらくして、やっぱり我慢ならなくなり、ついにMac&iPhone向けの高機能GTDツール、OmniFocusに手を出してしまいました。
ということでThinkingRockと比較してみたレポをアップしたいと思います。


■そもそもGTDとは何ぞや
グーグル先生にお尋ねになるか、または以下の本を読んでみていただけるとよいかと思います。
はじめてのGTD ストレスフリーの整理術


■これまで試したGTDツール変遷

フランクリンプランナー
↓
Remember the Milk + フランクリンプランナー
↓
Remember the Milk Pro + Appigo Todo + フランクリンプランナー
↓
Remember the Milk Pro + Remember the Milk for iPhone + フランクリンプランナー
↓
ThinkingRock + Remember the Milk for iPhone + フランクリンプランナー
↓
OmniFocus + OmniFocus for iPhone + フランクリンプランナー

新しい物好きが災いして、いろいろと試してます。
一時期フランクリンプランナーを辞めようかと思った時期もあったのですが、紙の手帳はやはり絶対必須みたいです。
私はアナログな人間だからか知りませんが、ペンで書かないと頭に入ってこないですし、モニタを見るのも嫌だというぐらい疲れているときでも紙でしたら平気です。あと、会議中にiPhoneを取り出してメモを取るのがはばかられるという問題もあったりします。

その後長いことRemember the Milkを使っていたのですが、使い込んでいるうちにRemember the Milkは備忘録としては超一級でもGTDツールとしては3流という結論に至ってしまったため、別のツールを探す必要性が出てきました。
（コンテキストの概念がないのはまだ運用で何とかなったのですが、プロジェクトの階層化ができないのと、プロジェクトとアクションをシームレスに追加変更できないのが致命的でした）


えーマジ？階層化できないの？キモーイ！orz

そこで最初に目を付けたのが前回ご紹介したThinkingRockです。


■ThinkingRock + Remember the Milk
この組み合わせの長所と短所を簡単にご紹介すると以下のようになります。

○長所

• ThinkingRockは厳密にGTDのプロセスを体現しているので、GTD初心者には最適。使っているだけでGTDの考え方を学べる
• プラットフォームを全く選ばない。ThinkingRockはJavaさえあればどこでも動きますし、Remember the MilkはWebに接続できればどこからでも利用できます
• プラットフォーム間の連携が容易。DropBoxを利用してThinkingRockのデータベースを共有することで、手持ちのマシン全てで簡単に同期を行うことが出来ます。WinとMacの間の連携もスムーズ
• ほとんど無料。必要な出費は、せいぜいRemember the MilkをProにして（年間たったの25ドル）iPhoneからでも利用できるようにする程度

×短所

• ThinkingRockとRemember the Milkの間の連携が全くない。Remember the Milkで収集したタスクをThinkingRockに移動したり、逆にThinkingRockから明日やりたいタスクを持ち出すためにRemember the Milkに書き出すなどといった無駄な作業を行う必要があります
• ThinkingRockは厳密にGTDのプロセスを体現しているがゆえに厳密すぎ、逆にRemember the Milkは備忘録程度の機能しかなくプロジェクトを扱うには不向き
• どちらのツールもフォーカス力不足。プロジェクトが30程度、アクションが100を超えてくるともはや制御不能

ThinkingRockとRemember the Milkで、無料＆どこでも使えるGTDを！

お金がかからずに、どこでも使える組み合わせと言う意味で、これからGTDをやってみようとお考えの方には最適ではないかと思われる組み合わせです。ThinkingRockは本当にお勧め。
問題はプロジェクトとアクションの数が増えてきたときです。どちらのツールもフォーカスをするための機能が貧弱です。
ThinkingRockには検索とソート程度しかフォーカスをするための選択肢がなく、
RtMには強力な検索機能がありますが、ThinkingRockがメインのシステムになっているため生かしきれませんでした。あと、検索結果を残すためのSmart Listが10とか20とか大変な数になってしまい、今度はどのSmart Listを利用すればよいのかわけがわからなくなるという別の問題が生じる恐れが・・・


■それで結局、OmniFocusってどうなの？
対するOmniFocus。こちらも長所と短所をまとめてみました。

○長所

• 「今すぐ出来る行動」と「今すぐは出来ない行動」を自動的に判断してくれるのが素晴らしい
• Mac版、iPhone版ともに、タスクに対するフォーカス能力が超強力
• MacとiPhoneが完全にシームレスに同期可能。iPhoneからいつでもメインのシステムに入っているアクション一覧を参照可能だし、iPhoneからいつでもInboxの整理をしたり出来る
• ThinkingRockに比べ入力補完やショートカットキーが大変充実しておりサクサク使える

×短所

• 高い。高すぎる。Mac版とiPhone版あわせて1万円、さらにMobile Me代が年間1万円
• Mac+iPhone以外では利用できない。うかつに携帯を買い換えたりPCを買い換えたりしようものならタスクが参照できなくなる危険がある
• 同期が重い。Mobile Meを利用しているのですが、同期ボタンを押したらたまに2分とか待たされるときがあります。RtMなら20秒程度で済むのに

OmniFocus for iPhone

OmniFocusの機能で特筆に価するのはなんといってもフォーカス力です。
Thingsのようなほかの有名GTDツールを使ったことがないので比較は出来ないのですが・・・

「期日が明日までで、かつ仕事先のオフィスの近くで出来るタスクだけを表示してほしい」
「今週どうしてもやっておきたかったとマークしたタスクだけを、今すぐ行動できるものだけ表示してほしい」
「そういえば最近Blog書いていなかったので、Blogネタの中で一番時間がかからないものを書きたいからアクションを表示してほしい」
「時間が空いたので開発をしたい。開発タスクの中で次に行動できるアクションを表示してほしい」

このようなニーズを（設定さえしておけば）ショートカットキー一発で満たしてくれるというのが神業的に素晴らしいです。
しかもMacの中だけではなく、iPhoneでもほぼ同じことが出来ます。
帰りの電車の中で、「家に帰ったら寝るまで1時間しかないけれども、何が出来るか」などと考えたりできるわけです。もう最高。


今日、帰ってから実行するアクションは・・・

「今すぐここで出来る行動」を管理できると言うのも素晴らしい点です。
たとえば3月3日現在の地点で、「今すぐやる」リストに3月8日開催の「例大祭の列に並ぶ」なんてアクションを出されてもイラッとするだけです。
このアクションは3月8日の朝に「今すぐやる」リストに表示されてほしいのです。そしてこれが実現できているGTDツールが意外なほど少ない。
RtMには「開始日時」の概念がないですし、ThinkingRockには「開始日時」の設定項目がありますが、それを使って今すぐ実行可能なタスクだけにフォーカスをすることが出来ないに等しかったので役に立ちませんでした。


これで安心！あとは例大祭のことは忘れてソースでも書きましょうか！


あとは完全に主観になってしまいますが、「使っていて楽しい」というのも非常に重要なポイントです。
はじめてのGTD ストレスフリーの整理術にも、「使っていて楽しいツールを利用するとタスクを管理するのが楽しくなる」といった旨の記述がありますし、使っていて楽しくて仕方がないと思うのであれば少々高くてもお金を出す価値はあると思います。


ただしOmniFocusは欠点も無茶苦茶多いです。まず第一にMac + iPhoneの組み合わせ以外では利用不可能。これだけで使う人を選んでしまいます。
残念ながら今後Windowsなど他のプラットフォームで利用可能になることも永遠にないと思います・・・(開発元のOmni社がMac製品しか作らないので）。
そしてべらぼうに高い値段。「無料でいくらでもネット上に落ちているタスク管理ツールに1万円＋αも出せるかどうか」というところがポイントになりそうです。
この「Mac信者のMac信者によるMac信者のためのGTDツール」と言わんばかりのハードルの高さを乗り越えられるかどうかが肝だと思います。実際にはMac信者とか全く関係なしに非常に良いツールなのですが・・・


■まとめ
初めての人、複数台マシンを持っている方、Linuxユーザーの方、無料だけれどもしっかり使える優良ツールをお探しの方にはThinkingRock＋αを、 手持ちのコンピュータが全てMacで携帯はもちろんiPhoneという方、人とは違うものを使ってみたい方、「次にいますぐ行動可能なアクション」だけが目の前に出てくる快感を味わってみたい方にはOmniFocusをお勧めします。


■おまけ：日本語版のOmniFocusはイマイチ
何がイマイチって、まず翻訳が何かおかしい。所々見ていてへんな単語が・・・フォマーットとか・・・
そして何より、日付の指定が日本語じゃないとできないのです。


英語版だとこう指定できます。「next sun@8」で来週の日曜日の8時にセットできます。
「tod」だけで今日の0時、「tom」で明日0時、「now」で今この瞬間にセット。
便利！


ところが日本語版だとこうなります。ちょっと！なんだよ「翌週日曜日」って！
「明日」とか「今日」とか「今」って入力面倒じゃないの！
こんなところまで余計なローカライズしなくていいよ！！

と言うことで私は英語版を強くお勧めいたします。
英語版のダウンロードは、http://www.omnigroup.com/applications/omnifocus/ の画面右端、



こちらをクリックすると英語版がダウンロードできますよ。

CONIT社主催の、iPhone開発者懇親会に参加してきました

• 主催はコニットさん、サムライチェスの中の人
• 会場は超満員（総勢で120名近くの方が集まったそうです）
• 参加者のメンツが凄すぎ、国内のiPhone関連の大御所が全員集まったような感じ！
• 名刺入れ二つ分の名刺が全部無くなった、こんなに名刺交換したのはたぶん生まれて初めて

昨日は港区海岸付近で開催された、株式会社コニット様主催の「iPhone開発者懇親会」に参加して参りました！
参加された皆様、本当にお疲れ様でした！


右を見ても左を見ても「どこかで聞いたことがあるアプリの作者さん」だったり
「RSSを購読しているブログの中の人」だったりと、なんだかとんでもない空間に迷い込んだ気分でした。

---

以下、ちょっとだけ写真紹介。



コニットさん（サムライチェスを開発された会社さん）が今年のMac Worldの際に行ったプレゼンをされているの図。



同じくプレゼン、UEIの清水社長。
「果たして来年同じように浮かれていられるか」というトークが衝撃的でした。
確かに、国内iPhone開発者全体の課題ですよね。国内市場が小さいから。



最後に、LCD Clock開発者の方からお話ししていただいた、興味深いエピソードをいくつか。

• 米国と日本では、米国のほうが圧倒的にクレームの量が多い。彼らはたかが115円のアプリにそこまで言うかというぐらいケチョンケチョンに文句をつけてくる
• しかし、日本のクレームの方が理不尽なものが多い。たとえばiPhone SDKの仕様上どうしても再現できない問題にクレームをつけてきて金返せだのレビューで星1個つけるだの
• 機能に文句をつけられるのはわかるが、お金を取るところに文句をつけられるとやっぱり萎える
• 開発者とデザイナーが二人にわかれていると、デザイナーは開発者にちょっと無茶な要求を出来るから、開発者が120％の力を出せる。開発者一人が作ると、自分が出来ないことを知っているから、仕様が丸く収まってしまう。

特に開発者とデザイナーの話が凄く興味深かったですね。
自分の限界を知っているから丸く収まってしまう、といわれると確かに納得です。

---

ところで、なんだか私のブログがMacお宝鑑定団さんで紹介されているような気がするよー・・・
ものすごい恐縮です・・・