無印吉澤

■[P2P]2009年の無印吉澤と吉澤を振り返る

あけましておめでとうございます。今年も皆様よろしくお願いします。

今日の日記は、年末年始恒例の一年を振り返る日記（いわゆる反省会）です。昨年までの反省会はこちら（↓）。

• 2005年の無印吉澤と吉澤を振り返る
• 2006年の無印吉澤と吉澤を振り返る
• 2007年の無印吉澤と吉澤を振り返る
• 2008年の無印吉澤と吉澤を振り返る

----

■ 2009年の無印吉澤を振り返って

数えてみたら、去年は12回しか日記書いてませんでした。そのうち5回は単なるP2P SIP勉強会の告知なので、実質7回。

色々理由はあると思うのですが、その一つとしては、ちょっとした感想くらいならtwitterでつぶやいて満足してしまうようになったのが原因かもしれません。ちなみに、去年までtwitterはprotectedで使っていたのですが、今年の5月くらいからpublicにして使うようになって、そこから一気に100人以上followerが増えた一年でした。

日記を書くペースは年々落ちる一方ですが、最近はもう（後述の理由も含めて）仕方ないと自分では諦めました。諦めましたけど、面白い本を読んだり、新しい技術に触れたりして、ネタが出来たときは今後も随時ここに書いていこうと思います。

2009年の読書ネタ（7月以降に読んだ本についてもそのうち……）

• 2009年1月〜3月に読んだ本
• 2009年4月〜6月に読んだ本

2009年の新しい技術ネタ（Androidアプリの機能追加ネタもそのうち……）

• 自作Androidアプリ「Where's My Info?」をAndroid Marketに登録してみました
• RDBからGoogle App Engineのデータストアに乗り換えるときのつまずきポイントとか実例とか

----

■ 2009年の吉澤を振り返って

昨年は、一昨年に引き続いて仕事の忙しい一年でした。

今までは割と個人でちまちまやる仕事が多かったのですが、昨年は小さいチームのリーダ的ポジションとしてチームの回し方を考えたり、自分たちの部署の技術をよそに宣伝したり、逆によその人にインタビューしたり、色々慣れない仕事を経験させてもらいました。

その過程で気の進まない仕事をしたり、気の進まない本を読んだりする機会も多かったのですが……。結果的に、少し視野が広がって今まで気が回らなかったことにも気が回るようになったような気がしています。例えば、小さいチームでもリーダをやってみることで、自分がリーダに何を「してほしい」と思っているかをより明確に意識できるようになりました（これはあとで日記のネタにするかも）。まあ、慣れない分野に飛び出してまず経験してみることは、とても大事だなあと実感した一年でした。

その一方、慣れない仕事が続いて、家に帰ってくるとすっかり気が抜けてしまい、プライベートではなかなか新しいことに手を出せない一年でもありました。去年は読書量を増やすのが目標だったのに、夏の終わりごろからすっかり読書量が減っちゃいましたし……。

ちなみに、昨年の年末に立てた「2009年の抱負」は、以下の4つでした。

1. 週一冊は本を読む
2. 読んだ本、文献や、参加したイベントについては、必ずメモを残す
3. 英語の練習を毎日続ける
4. 新しいプログラム言語を1つ覚える

本は、読みかけの本や、つまらなくて読むのをやめてしまった本を除くと、上期に15冊、下期に10冊。2週間に1冊弱のペースですね。メモについては、日記にこそ書いてないですが、一応残しておいて後で読み返すようになりました。

英語の勉強については、ESL Podcastをほぼ毎日聞いていたのと、「書く英語 基礎編」という本（↓）でライティングの勉強を始めました。ただ、それでも2009年11月に受けたTOEICでは790点になってしまった（WritingはそのままでListeningが25点落ちた）のですが。まあ、高得点にこだわっても仕方ないので、こんなものかなと。

書く英語・基礎編(松本 亨)

新しいプログラム言語については、ちょっとFlexをいじってみたくて、ActionScript 3.0をかじりました。あとは、Androidアプリを作ってみたり、Google App EngineをJavaから触ったり……ってJavaばっかりですね。いかんいかん（？）。

----

■ 2010年の抱負

今年はあまり欲張らずに、以下の3つを抱負にします。

• 1. 週一冊は本を読む

  • 昨年は2週間に1冊弱のペースだったので、今年も引き続きこれを目標にインプットを増やします。あとは、量を急に増やすのは難しそうなので、出来るだけ「定番」とか「古典」とか言われてるような本を優先して読むようにしようと思います。

• 2. 読んだ本、文献や、参加したイベントについては、必ずメモを残す

  • これも引き続き。出来るだけ、「他の人に話すネタ」や「他の人にアドバイスするためのロジック」の形に変えてストックしようと思い、去年から紙の日記を書いてます。まとまったら紙じゃなくてWebに書けばいいんですが、キーボードに向かうより紙に書いたほうが、僕はなぜかはかどるので……。

• 3. 週一回は運動する

  • 去年は仕事に熱中しすぎて体調を崩すことが多く、11月の頭には新型インフルエンザで倒れてしまったりしてたので、今年はなんとか体力を付ける方向で頑張りたいと思います。まずは週一でウォーキングをするくらいからかなぁ。

繰り返しになりますが、今年も無印吉澤と吉澤をよろしくお願いします。

■[書評]2009年4月〜6月に読んだ本（みんなもマーケティング本を読むといいよ！）

元旦の日記で「今年は週一冊は本を読む」と宣言したのはさっぱり守れていないのですが、4〜6月に読んだ本についてメモしておきます。この時期はマーケティング関係の本を色々読んでました。

• ポジショニング戦略
• コトラーのマーケティング・コンセプト
• キャズム
• [新版]MBAマーケティング
• イノベーションのジレンマ
• クリティカルチェーン
• ビジュアライジング・データ

----

ポジショニング戦略[新版](アル・ライズ/ジャック・トラウト/フィリップ・コトラー(序文))

「ポジショニング」というマーケティング用語を生み出したアル・ライズ自身による、ポジショニングの解説書です。

本書によると、ポジショニングとは「消費者の頭の中にあるイメージを操作し、それを商品に結びつける」ことと定義されています。消費者は日々膨大な情報に翻弄されているため、頭の中の情報爆発を防ぐために製品のブランドやランク付け（すなわちポジショニング）が重要である、というのが著者の主張です。原著は30年以上前に発刊されたそうなのですが、この点は今でも有効な主張に思えます。

本書では、有効なポジションをつかむための方法や成功例が多数紹介されているのですが、個人的に特に印象深かった話をいくつかピックアップしてみます。

• 重要なのは、人の頭の中に一番に入っていくこと。(p.29)
• 新製品は、必ず既製品に対抗する形でポジショニングしなければならない。消費者の「頭の中のはしご（ある基準に基づくリスト）」を作り、その中で既製品より上に登らなければならない。(p.42)
• 成功したいなら、ライバルのポジションを無視してはいけない。もちろん、自分のポジションを無視するなど言語道断。(p.46)
• どんなポジションでも良い、自社がすでに消費者の中に確立したポジションを活用する。(p.52)
• パワーのある企業がよい商品を生むのではなく、パワーのある商品がよい企業を生み出す。例えば、コカ・コーラ社は、コカ・コーラという製品が持つ実力（製品力）の反映でしかない。(p.63)
• 自社製品ラインナップの抜け（工場の穴）を埋めるのは間違っている。消費者の頭の中でなく、工場の中で穴を探してしまうと、市場におけるポジションを見逃してしまう。その穴は、市場では既にほかの製品に埋められていないか？(p.76)
• 新商品には新名称が鉄則。新しい商品に既存ブランドの名前を付けるのは、情報社会では命取りになりかねない失策。(p.126)

Eric Sink on the Business of Softwareでこの本が強く薦められているのを見て、「マーケティング本か……」とやや尻込みしながら読んだのですが、マーケティング用語を全然知らなくても、読み物として十分面白く読める本でした。マーケティングに興味を持つための取りかかりの本としては、かなりお勧めできます。

----

コトラーのマーケティング・コンセプト(フィリップ・コトラー/恩藏 直人)

現代マーケティングの第一人者（らしい）フィリップ・コトラーによる、マーケティング用語の一言解説集です。読みやすく、それぞれの用語についての感じをつかむにはよい本でした。一方、マーケティング用語が順不同で（原著はアルファベット順に）解説されているため、マーケティング用語同士の関係や全体感をつかみたい方は、後述する「[新版]MBAマーケティング」の方がお勧めです。

ちなみに、本書によると「日本企業の90%はマーケティングを担当する専門セクションを置いていない」そうです(p.167)。コトラーはこれを、「マーケティング部門を置くと、そこしかマーケティングを考えなくなってしまう。日本では、全社員がマーケティングを意識して行動するのですばらしい！」みたいな観点で書いているのですが、それはたぶん違うよなあ……。個人的には、日本企業でもマーケティング部門をちゃんと用意して、そこに権限を与えた方が良いような気がします。

----

キャズム(ジェフリー・ムーア)

有名な「キャズム」の本です。一時期、ブログがブームになった頃に「キャズムを超えた」だの「アーリー・アダプタの影響力が云々」だの色々言われていたので、本書に出てくるキーワードだけは知っている人も多いと思います。僕も、今までそのへんのキーワードしか知らなかったので、改めて原著を読んで、「そういうことだったのか！」と驚かされるところが多かったです。

本書では、新製品がキャズムを超えるのが難しいのは、アーリーアダプタはその製品で何ができるのかを重視する（製品重視の視点）一方で、キャズムの先にいるアーリーマジョリティはその製品の市場を重視する（市場重視の視点）からだと主張しています。つまり、アーリーアダプタでの採用例がいくら増えても、市場を作れなければいつまでもキャズムを超えられない、と。この難題を解決するためには、ホールプロダクト（製品だけでなくその周辺のサービスなどを含む。今風に言うとエコシステムか？）の構築が重要であり、今後はホールプロダクトをR&Dの対象にしなければならないと論じています。

また、本書ではposition statementのひな形を以下のように定義していました。前回紹介したEric Sinkの定義よりはやや複雑ですが、これはこれで面白いと思うので紹介しておきます。

[ (1) 代替手段 ] で問題を抱えている
[ (2) ターゲット・カスタマー ] 向けの、
[ (3) ターゲット・カテゴリー ] の製品であり、
[ (4) この製品が解決できること ] することができる。
そして、 [ (5) 対抗製品 ] とは違って、
この製品には [ (6) ホールプロダクトの主だった機能 ] が備わっている。

----

改訂3版 グロービスMBAマーケティング(グロービス経営大学院)

※僕が読んだのは第2版なのですが、既に第3版がでているのでそちらにリンクしています。

マーケティングについての良い本を探しているときに、P2P todayの横田さんから「まずは一般的なフレームワークを一通り勉強したら？」とお勧めされた本です。マーケティング用語同士の関係や全体感が整理されており、確かに（僕のような）初心者が基礎知識をつけるにはとても良い本でした。さすがヨコタン。

一方、初心者向けではあるのですが、知識が網羅的に書かれているので、読んでも「マーケティングすげー！これは重要だよ！」みたいなテンションの上がり方はしないのが難点です。もし、マーケティングに興味があるなら、上に挙げたような別の本を先に読んでテンションを上げておいた方がいいかもしれません。

----

イノベーションのジレンマ―技術革新が巨大企業を滅ぼすとき (Harvard business school press)(クレイトン・クリステンセン/玉田 俊平太)

有名な「イノベーションのジレンマ」です。ちなみに初めて知りましたが、原題は "The Innovator's Dilemma" で「イノベーターのジレンマ」なんですね。

本書では、イノベーションのジレンマが起こる理由を、既存の製品を取り巻くバリュー・ネットワークという概念（これもエコシステムと同義か）で説明しています。企業がある製品を開発することが「技術的に」可能であったとしても、実績ある企業は自分たちが属するバリュー・ネットワークの財務構造や組織の文化に束縛されているために、そのバリュー・ネットワークを壊しかねない破壊的技術は採用できない、というのが本書の説明（の僕なりの解釈）です。

イノベーションのジレンマ自体はかなり有名な概念ですが、本書ではその中身をかなり深く掘り下げており、原著に当たる価値はあると思いました。特に、組織の能力はそのプロセスと価値基準にあり、組織の構成員がその両者を強く理解している（現在のバリュー・ネットワークで価値を生み出す能力が高い）ほど、「破壊的技術を導入させるためのインセンティブ」を組織の構成員に与えることは難しくなる、といったくだりは衝撃的でした。そういう意味で、本書の内容は組織論にも近いかもしれません。

----

クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?(エリヤフ ゴールドラット/三本木 亮)

本書もビジネス書なのですが、こちらはマーケティングではなくてプロジェクトマネジメントに関する「ビジネス小説」です。ちなみに、ビジネス小説というのは、「ビジネス上の難題にぶち当たった主人公が」、「○○という新しい技術/手法/考え方を知り」、「仕事がうまくいくようになる」というテンプレートに沿った小説のことです。

冗長な部分を取り払うと、本書の主張はだいたい次のような感じです。小説スタイルで書かれているので、このまとめが正しいのかもあまり自信がないのですが……。

• 従来の経営は、部分最適が全体最適に繋がる、という経営哲学に基づいて行われていた。この経営哲学を本書では「コスト・ワールド」と呼ぶ。
• しかし、実際の現場では、部分的な改善が全体の改善には繋がらず、全体のスループットは強度の一番弱い部分に依存する。つまり、もっともスループットが出ない部分を補強する、という取り組みを繰り返す必要がある。この経営哲学を本書では「スループット・ワールド」と呼ぶ。
• 個々の作業ごとにバッファを用意するやり方は、コスト・ワールドに沿った考え方。スループット・ワールドに沿ったやり方としては、個々の作業見積もりはかなりタイト（作業の終わる確率が50%〜90%のスケジュール）に設定しておいて、作業の合流地点に大きな共通バッファを持たせる。
• 特定のスペシャリストがクリティカルパスだけでなく複数の非クリティカルパスに関わるために、結果として作業が遅れることがある。スペシャリストを守るための人単位のバッファも必要。

「ザ・ゴール」みたいなビジネス小説が好きな人にとっては面白いと思いますし、単に小説として読めば面白いと思うのですが……僕は話の結論や整合性（どこまでが作り話なのか？）が気になってあまり集中できませんでした。

----

ビジュアライジング・データ ―Processingによる情報視覚化手法(Ben Fry)

最後はビジネス書から離れて、プログラミングに関する本です（癒される……）。

本書は、Processingというプログラミング環境を題材に、情報の視覚化（Information Visualization）のやり方を解説した本です。冒頭で、「データの理解において最も重要なポイントは、どういう問いに答えたいのかを知ることです」と訴え、答えに至るまでの過程を以下の7ステップに分解して示しています。

1. データ収集（acquire）
2. 解析（parse） … 構造の付加、カテゴリ分け
3. フィルタリング（filter）
4. マイニング（mine） … パターンを見つけたり、数学的処理をしたり
5. 表現（represent） … 視覚化モデルの選択
6. 精緻化（refine） … 基本表現の改善
7. インタラクション（interact） … 操作、表示のカスタマイズの手段を提供

前半では、このように「情報の視覚化」の考え方を示した上で、後半はProcessingを使って上記の各プロセスをどう改善できるかを示しています。

かなり面白く勉強になる本なのですが、書籍の内容とは別に、ProcessingがJavaベースなのが個人的にはどうしてもなじめませんでした……。これ、もうちょっと軽量なスクリプト言語をベースにした方がもっととっつきやすかったような気がするんですよね（ProcessingはJavaの上に軽量な環境を作ろうとしてるんですが、いかんせんJavaベースなので限界が）。やりたいことと比較して、Javaだとちょっと書くことが多くて面倒すぎるような。でも、この本自体は、色々新しい観点を示してくれていい本ですよ。お勧めです。

----

7〜9月分に読んだ本についてはまたあとで……。

■[Programming][GAE]RDBからGoogle App Engineのデータストアに乗り換えるときのつまずきポイントとか実例とか

先週末は、某温泉街に籠もってGoogle App Engine（GAE）を色々いじって遊ぶという2泊3日の合宿に参加してました。合宿と言っても「GAE」以外に特にテーマも決まって無くて、みんな適当に好きなことをやってたんですが、僕はGAEの初心者なので、

「リレーショナルデータベースのために書かれたテーブル定義を、Google App Engineに置き換えようとしたらどれくらい大変なのか？」

をテーマに決めて、下の本を読みながらコードを書いたり消したりして遊んでました。

Google App Engine for Java [実践]クラウドシステム構築 (WEB+DB PRESS plus) (WEB+DB PRESSプラスシリーズ) (WEB+DB PRESS plusシリーズ)((株)グルージェント)

----

■ 先にまとめ

まだ勘違いも多そうですが、今回分かった「リレーショナルデータベースに慣れた人のつまずきポイント」を先にまとめておきます。

• GAEのデータストアでは、複合主キーのある表を作れない。

  • 例えばJDOだと、@PrimaryKeyを複数のインスタンス変数に付けるとコンパイル時に例外が出る。
  • ちなみに、主キーのない表も作れない。こちらもコンパイル時に例外が出る。

• 一意なIDを割り当てるためのカウンター（オートインクリメント機能）が必要なら、自前で実装する必要がある。

  • トランザクション処理を使うことで、このようなカウンターを実装できる。
  • JDOインターフェイスでは、valueStrategyにIdGeneratorStrategy.INCREMENT（なんかそれっぽい）を選べるが、GAEでは使えないらしく実行時に例外が出る。

• UNIQUE制約に相当する機能もない。恐らく、自前で実装することもできない？

  • UNIQUE制約は、自前で定義することもできない、ような気がする……。
  • GAEのトランザクション処理は参照したデータに対する排他処理のため、新しく追加する行の値に対する制約にはなり得ないのではないか。

• 多対多の関係を表現しにくい。

  • リレーショナルデータベースに慣れていると、多対多の関係を表現するときは、関係を表す表を新たに追加したくなってしまうけど……。
  • GAEでは複数の表をまたがるトランザクションは基本的に作れないので、途中で処理に失敗した場合の例外処理を書くのがすごく面倒。
  • 当然、JOIN処理なんて無い。
  • 多対多を実現する方法としては、一方の表に、もう一方のIDのリストを格納する列を用意すると楽。GAEでは、「リスト内のいずれかの値がAに一致する」といった検索クエリを「listItems == :A」のような形で記述できる。

• JDOとJPAのどっちを使えばいいのか分からない。

  • JPAを選んでもリレーショナルデータベース固有の機能は使えないので、JDOを使っておけば良いような気がする。でも、情報がなくてよく分からない……。

以下は、上のつまずきポイントに気付くまでに、実際に書いたり消したりしていたソースコードの話です。文章の最後にソースコードも置いておきましたので、興味のある方はダウンロードしてみてください。

----

■ 具体例

最近作ったAndroidアプリ（Where's My Info?）のテーブル定義がシンプルだったので、これをGAEのデータストアに置き換えることを試みました。GAEのデータストアへのアクセス方法は以下の3種類があるのですが、今回は最も情報が多いJDOを使っています。

• JDOインターフェイス（Java Data Objects、汎用的な仕様）
• JPAインターフェイス（Java Persistence API、RDB向け）
• ローレベルAPI（Key-Valueで値を保持するAPI、高速だが低機能）

まず、元にしたAndroidアプリのテーブル定義は、以下のようなものです。個人情報（information）と情報提供先（knowers）の関係を、主キーのないinformation_knowersテーブルで表現しています。

これを、GAEのデータストアで定義すると、以下のようになります。GAE上で扱う表のことを、ここでは「エンティティ」と呼んでいます。

こうして見ると、リレーショナルデータベースでの定義と比べて、やや汚くなってるのが分かります。以下は、リレーショナルデータベース版との違いです。

• Knowerエンティティの列に、関係するInformationのIDのリストを追加。

• IDを一意に割り当てるためのカウンタを追加。

  • 主キーが必須なので、ダミーの主キーを定義している。
  • 今この資料を書きながら思ったけど、IDを一意に割り当てるためのカウンタ類は、1つのエンティティにまとめてしまえそう……。

で、最後にこのアプリを、ユーザ毎に別の領域にデータを格納できるように拡張すると、データストアの定義は以下のようになります。

• 「110487681081245093660」というのは、Googleが提供するアカウント認証サービスから取得できる、ユーザ毎に一意なユーザID。

• InformationエンティティとKnowerエンティティのキーには、ユーザID + "/" + ユーザ毎に一意なIDを使っている。

  • ユーザIDとユーザ毎に一意なIDを組み合わせた複合主キーが使えたら、ホントはそっちの方がよかったんだけど……。
  • クエリとインデックスの方法を使って前方一致検索をすることで、特定のユーザに関係する列のみを取り出すことができる。リンク先にあるのはPython版のコードだが、Java版でも同じ方法が使える。

実例とソースコードを、それぞれ以下の場所に置いておいたので、もし興味があったら覗いてみてください。

実例（注意：管理者＝僕にはデータ丸見えなので、ホントの個人情報は書かないで！）
http://wheres-my-info.appspot.com/

ソースコード（上の実例で動いてるのと同じものです）
WheresMyInfoWeb.zip

----

■ 感想

Eclipseのプラグインを使ってると、Google App Engineのソースコードを書くのも、本番環境にデプロイするのもすごく簡単です。でも、このデータストアを使って大規模なコードを書くのは、正直言って全然出来そうな気がしません。

こんなのを使ってあんなgmailみたいな巨大アプリを書いてると思うと、やっぱりGoogleの連中はイッちゃってるよ、あいつら未来に生きてんな……と思っていたら、今回の合宿の参加者から「Googleの中では、BigTableに（GAEには含まれてない）Chubbyを組み合わせて使ってるんじゃない？」との指摘が。そんな、ひどい……。

■[mobile][Android]自作Androidアプリ「Where's My Info?」をAndroid Marketに登録してみました

最近日記を書いていなかったので、すっかり書くタイミングを逸してしまっていたのですが、実はDoCoMoのAndroidケータイ「HT-03A」を持ってます。ビックカメラで実機を触って気に入って、HT-03A発売日（7月10日）の1週間後くらいに購入しました。

その後、Hello Worldレベルよりもましな「ちゃんとした体裁の整ったAndroidアプリ」を開発する作法を勉強しようと思って、暇を見ては（日記も書かずに）ちょこちょことプログラミングをしていたわけですが……今日ようやっとAndroid Marketに登録するところまでこぎ着けました。今日はここまでの経緯をネタにいろいろ書いてみようと思います。

----

■ 今回自作したアプリ「Where's My Info?」

最近、引っ越しをしたり、携帯電話を買い換えたりすることが多かったので、色々と不便を感じていました。具体的には、こんなあたりが不満でした。

• 何かの書類に申し込みするときに、メモなどを見ないと、新しい住所/電話番号を正確に思い出せない。
• 古い住所/電話番号をどこに提供したのかわからない。何かの申し込みのときに、古い住所/電話番号を使ってなかったか？

そこで、今回はこの問題を解決するために「Where's My Info?」というアプリを開発しました。あまり「Androidならでは！」という感じはしないアプリですし、既存のパスワード管理ソフトに似た面もありますが、携帯に載ってるとそこそこ便利なアプリなんじゃないかと思ってます。

以下は、Android Marketに載せるために作ったスクリーンショットと紹介文です。スクリーンショットは一部英語になってますが、日本語ロケールならちゃんと日本語が表示されます。

あなたはメールアドレスや電話番号を2つ以上持っていませんか？ "Where's My Info?"はあなたの個人情報を、いつ、どこで、誰に提供したかを管理するソフトウェアです。例えば、以下のような場合に、面倒な作業を手助けします。

• 携帯キャリアを変えたので、メールアドレスや電話番号を差し替えたい。でもどこに書いたっけ？
• 引っ越したので、住所を差し替えたい。でもどこに書いたっけ？
• etc.

自分で使うために作ったアプリということもあって、今後もちゃんとメンテするつもりですので、是非使ってみて感想を聞かせてください。現時点では、これから以下の機能を追加しようと考えています。

• データのimport/export
• 情報提供先へのカメラ画像の追加（どこで情報提供したかわかりやすくする）
• 個人情報の並び替え

----

■ Androidアプリ開発の感想

基本的には、まあ、ものすごく敷居が低いですねー。

開発に使う言語はJavaで、かつEclipseでAndroidアプリを開発するためのプラグインもあります。エミュレータの起動や、実機へのインストールもそのプラグイン経由で出来るので、Java+Eclipseに慣れてる人なら特に楽だと思います。

ただ、これはフレームワーク全般に言えることですが、ライブラリが基本提供する機能から外れて、ちょっと気の利いたことをやろうとするととたんに詰まります。今回僕がつまずいたのは以下のポイント。

• リストを表示するためのListViewをカスタマイズして、各項目の中にテキスト2行を表示したい。

  • Android Series: Custom ListView items and adapters(Software Passion) を見て解決。

• ListViewからコンテキストメニューを呼び出したい。

  • Long click on list activity item - Android Developers や How do you implement context menu in a ListActivity on Android? - Stack Overflow を見てもよく分からず、結局試行錯誤してるうちになんかうまくいった。

• タブを表示させる方法がよく分からない。

  • Add a "footer" in a TabActivity - Android Developers を参考にレイアウトのXMLを手直ししたらうまくいった。

• ListViewの中にチェックボックスを作ったときに、そのチェックボックスの値を取る方法が分からない。

  • Checkbox Text List :: Extension of Iconified Text tutorial :: anddev.org - Android Development Community を参考に手直ししてうまくいった。

• 戻るボタンを押すと古い情報が表示されてしまう……。

  • Activityの後始末し忘れ。もう使わないActivityはfinish()でちゃんと終わらせる。

• ダイアログのタイトルを消したい。

  • Dialog with No Title - Android Developers

で、こうやって見て分かるように、細かいことを気にし出すと日本語圏にはあんまり情報がなくなってきます……。

----

■ 特に参考になった書籍、Webサイト

とはいえ、日本語でもAndroid関係の情報はかなり出てきていて、特に以下の本は役立ちました。幅広い話題についてかなり細かく書かれているので、この本だけ買っておけば大体なんとかなります。

Google Androidプログラミング入門(江川 崇/竹端 進/山田 暁通/麻野 耕一/山岡 敏夫/藤井 大助/藤田 泰介/佐野 徹郎)

あと、WebサイトではTaosoftwareのblogにかなりお世話になりました。Android関係で疑問に思ったことを検索すると、日本語圏だと大体ここにたどり着くような感覚です。

Taosoftware
http://www.taosoftware.co.jp/blog/

とりあえず、今日はここまでで。Androidについては、またネタが溜まったらなんか書きます。

■[tDiary]tDiary 2.1系から2.2.2にアップグレード

tDiary.org - tDiary 2.2.2リリース

今回のリリースは、主にAmazonプラグインのためです。AmazonがAPI利用に認証を求めるようになったため、2009年8月15日以降、未対応プラグインでは利用できなくなります。amazon.rbを利用している場合は必ずアップデートしてください。

今回のバージョンアップ、Amazonプラグインを使っている人は対応必須みたいです。今まではセキュリティ対策のアップグレードがあっても、手でコードいじって済ませてたんですが、せっかくの良い機会なので今回はちゃんとコード入れ替えました。

なんか挙動がおかしい、というところがあったらtwitterあたりで教えてください。最近、日記を書く気が起こらなくてすっかりtwitterに引き篭もり中です……。

■[P2P][SIP]第13回P2P SIP勉強会のお知らせ（P2Pの技術体系についていろいろ議論）

来週の7月20日（月曜・海の日）に、第13回P2P SIP勉強会が開催されます。直前の告知になってしまい申し訳ありませんが、P2P SIP勉強会の特性*1を考慮すると、どうしても告知が直前にならざるを得ないもので、どうかご容赦ください。

今回は、勉強会のWebサイトにある情報からはよく分からないのですが、おそらくはP2Pの技術体系を（政治的な意図抜きで）改めて見直す「くたばれ！P2P●●●」企画なんだと思います。大西さんとeffyさん、および参加者によって「私の考えるP2Pの定義」合戦が激しく繰り広げられるものと予想されます。そういうのがお好きな方は是非ご参加ください。

第十三回P2P SIP勉強会の告知(なんとなく実験 with SIProp開発記)

• 案内

  • 日程

    • 2009/07/20(月・祝)

  • 時間

    • 14:00〜

  • 参加費

    • なし

  • 懇親会

    • 検討中

  • 会場

    • 東工大 西7号館

• プログラム

  • 大西さんとeffyさんによる『真・P2P●●● 検討いいんかい』

    • 思いっきり技術よりに倒した内容の大学で使える●●●を作成するための大討論会です。
    • 最終目標は、P2Pの技術体系についてまとめた資料をアウトプットすることです。

参加を希望される方は、SIPropのサイトに記載のメールアドレスまで申し込みをお願いします。

■[P2P][SIP]第13回P2P SIP勉強会延期のお知らせ

今週末の5月24日（日曜日）に、第13回P2P SIP勉強会が予定されていたのですが、昨今のインフルエンザ流行に伴い開催延期になりました（なんで告知文を書いた数時間後になってそんなこと言いだすの……）。

開催延期となりましたので、このページに記載していた勉強会開催のお知らせは削除しました（良く読まずに、間違えて来ちゃう人がいるとまずいので）。Noritsuna先生の次回作にご期待ください。