検索

archetype : テンプレートシステム。Maven3の今や、単に "mvn archetype:generate" だけでOK。対話的にarchetypeを一覧から選択＋必要情報を入力できるようになっている。

LifeCycle -> Phases -> Goals の順に構成されている。

LifeCycleはdefault, clean, site の3種類あり、これはどのプロジェクトでも共通・・・らしい。

LifeCycleとPhasesの紐付けも固定・・・らしい。

Phases と Goals の紐付けは、プロジェクトの Packaging やplugin設定で決まる・・・らしい。

勉強中：

• Introduction to the Build Lifecycle
  • http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

というのに遅ればせながら自分もtryしてみたので、駆け足でメモ。

コンセプト：Androidのソースツリーをmirrorモードでsync + そこから任意のバージョンのソースツリーをさらにsyncして、そのソースツリーをmilkodeに突っ込む。

当然、数十GB単位のディスクスペースが必要で、環境準備だけで数時間かかる(mirrorモードのsyncやmilkodeへの登録が時間かかる)。
さらに、週末やお仕事中の「ちょっとした空き時間で調べごと」をしたいだけなので、それ以外の時間はインスタンスを落としておきたい。となるとEBS(Elastic Block Storage)で永続化して必要なときだけインスタンスを上げておく使い方になる。

簡単なサンプルコードを作って遊んでました。

https://bitbucket.org/msakamoto_sf/androidexercise/changeset/c1514aa31b8d

Network Providerはこれで動くのだけれど、Gps Provider が上手く動かない・・・。

もう少し勉強が必要。

昨日美味しい牡蠣をお腹いっぱい食べた上にお酒飲んで、さらにその後江川達也氏の「マンガ最終戦争論」読んでめがっさハイテンションになったのでたまには思いっきり釣りっぽいタイトルにしてみたし、実に久しぶりに技術以外の話題を書いてみる。

日本人を幸せにするたった一つの方法、それは・・・

「given and give」の精神

です。

まず「given」、つまり与えられます。親が産んでくれることで人生を与えられます。食事を与えられます。養ってもらえます。教育を与えられます。会社に入るなり自分で商売を始めるなりした後も、先達や周りの人から助けてもらうこともあります。
そしたら、お礼として「誰かに」giveします。別に「given」してくれた人に直接お礼をする必要はありません。誰か困っている人と出会ったらでも良いですし、あるいは会社の事業や自分の商売でお客に対してでも良いです。何かしら役に立つものを作り、与えます。これも、無償で与えなければならない、というわけではなく、お金を貰っても構いません。

「give and take」と違うところは、見返りを求め合うのではなく、見返りを求めない「give」である点です。
「give and take」は見返りを、お返しを相手に求めます。
「given and give」は、与えるときにお返しを求めません。
なぜなら、最初に来るのは「given」であり、既にどこかから与えられているからです。
「given and give」で「give」するのは、見返りを求めるからではなく、既に与えられたことに対するお返しです。

そして「given and give」は1対1の関係ではなく、自分と周囲の環境の関係です。自分に何かを与えてくれるのは周りの環境全体であり、自分が何かを与える対象も特定の誰かではなく、周りの環境全体で、その内たまたま縁が合った誰か、になります。これも「give and take」と大きく異なる点と考えています。特定の相手に対するやり取りではないので、与えてくれた人・モノと、与える先の人・モノは違っていても構わないのです。
つまり、「given and give」の精神に従えば、「与えられたことに対して『返さなければならない』」義務や、「与えたことに対して『返してもらわなければならない』」期待など存在しません。相手に求めたり、自分で義務感を感じることはないので周囲との関係はずっとリラックスしたものになります。

与えられたら、「ありがとうございます」と感謝すればよく、「何かお返しをしなくちゃ」と焦る必要はありません。
与えたら、「与えられたお返しをすることが出来ました。」と与えた相手に感謝すればよく、「代わりにあなたはこれだけのものを私に返さなければなりません」と相手に強要することもありません。
与えられても、何も与えることが出来なければ、「ごめんなさい、今自分は何も与えるものがありません」と心のなかでゴメンナサイしておけばOKです。子どもや老人は与えられるだけになりがちですが、それに対して罪悪感を感じる必要はなく、変に義務感を感じることも無く、ただ、「ありがとうございます」と感謝すればOKです。

日本人は狭い島国に単一民族で固まっています。そのような環境で「give and take」してしまうと、義務感と期待感による緊張が増加していきギスギスしてしまいます。だからこそ、相手に期待せず、また自分も過剰な義務感を感じなくて済む「given and give」を軸に据えることで、もっとリラックスして人生を楽しむことが出来るようになると、勝手に思っています。

また念のためですが、貨幣制度を否定しているわけでは無いです。貨幣制度の良し悪し、資本主義の良し悪し、商売するときのポリシーの良し悪し、は分かりません。それは個々人の人生ではなく、十億人単位で動いている世界の流れの中での話になってしまいます。
「given and give」はあくまでも個々人の日常の生活をもっとリラックスさせるためのライフハックであり、今すぐボランティア活動をしなければならない、というような話ではありません。

「～しなければならない」、「～せよ」と誰かに求めるのではなく、まず自分自身がリラックスして人生を楽しみましょう。リラックスして人生を楽しむ人が増えていくことで、きっと、社会全体がリラックスして朗らかなものになっていきます。

・・・仏教の「布施」の話を塩コショウ加えて今風にアレンジして見ました。お口に合いましたでしょうか？

余談：タイトルと冒頭の文章以外、あえて「幸せ」という単語を使っていません。なぜかというと、幸せってなんなのかは個々人が一生懸命頭を捻って、それぞれの人生ごとに考えないといけない、非常に難しい内容だと思うからです。
で、そんな難しくて中々答えのでない問題を考えようとすると、日常からリラックスしていないと、良いアイデアは思いつきません。頭も回転しません。なので、まずはリラックスしましょう、という流れです。リラックスして日々を過ごしていくことで、「幸せって何だろう」という非常に難しい難問に対して自分なりのベストアンサーを考える余裕も生まれるのではないか、と勝手に思っています。

• [ Prev ]
• [ Next ]
• [ 技術 ]

USBストレージに対するSpotlightインデックス作成を無効にする手法(MacOSX Lion, 10.7.2 で確認)：

1. 買ってきたばかりのまっさらのUSBストレージをMacに接続する。
   1. Spotlightのインデックス作成が始まるが、まだまっさらなのですぐ終わる。
   2. まっさらでなければ、しばらくはインデックス作成が動いているが、とりあえず無視する。
2. Terminal を開く。
3. "sudo mdutil -i off /Volumes/(Volume Name)" を実行する。
4. "/Volumes/(Volume Name)" に移動し、"touch .metadata_never_index" を実行。
5. ".Spotlight-V100/", "._.Trashes" は削除してOK
6. ".Trashes/", ".fseventsd/" は残しておく。

最終的に、Terminal上で"mdutil -a -s"したときに "/Volumes/(USB ドライブの Volume名)" について Indexing が disabled されていればOK。

$ sudo mdutil -s /Volumes/REFS/
Password:
/Volumes/REFS:
	Indexing and searching disabled.

あんまり詳しく検証していないのだけど、".fseventsd/"や".Trashes/"まで削除してしまうと、USBドライブを再接続したときに自動的にSpotlightが再indexingを開始してしまう場合があった。というわけで、安定解としては以下の流れ。

1. とにかく "mdutil -i off" でまずSpotlightIndexingを無効化する。
2. ".metadata_never_index", ".fseventsd/", ".Trashes/" の3セット以外のドットファイル・フォルダを削除する。

参考：

• osx - How disable mac snow leopard creating .Spotlight-V100 and .Trash folders in USB Flash Drivers? - Super User
  • http://superuser.com/questions/89556/how-disable-mac-snow-leopard-creating-spotlight-v100-and-trash-folders-in-usb
• Spotlight indexing off on USB drive...: Apple Support Communities
  • https://discussions.apple.com/thread/2608199?start=0&tstart=0
• Spotlight Indexing External USB Drive?: Apple Support Communities
  • https://discussions.apple.com/thread/1850611?start=0&tstart=0
• Disable spotlight for USB thumbdrives?: Apple Support Communities
  • https://discussions.apple.com/thread/1461768
• Mac Spotlightで検索インデックスの作成を停止する裏技 / Inforati
  • http://inforati.jp/apple/mac-tips-techniques/system-hints/how-to-disable-mac-spotlight-indexing.html
• Snow LeopardになってSpotlight停止機能はより簡単に | Macの手書き説明書
  • http://veadardiary.blog29.fc2.com/blog-entry-2514.html

• [ Prev ]
• [ Next ]
• [ 技術 ]

とりあえず：

otool -L 実行バイナリ

例：

$ otool -L ./mongod
./mongod:
  	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) 
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3)

どこでotoolなんてコマンド見つけたのか・・・忘れた。とりあえずldd, objdump, elfread の代替としてotoolが使えるのは分かった。

WebSocketについていよいよRFCも発行されたので、もう少し本格的にいじってみるかと思い、今さらながらgihyoの記事を参考にJettyでWebSocketを試してみた。

• 特集：Jettyで始めるWebSocket超入門｜gihyo.jp … 技術評論社
  • http://gihyo.jp/dev/feature/01/websocket

が・・・2010年8-9月頃の記事であるため、Jettyのバージョンが8となり、いろいろ記事のコードでは動かなくなってる。

まずインターフェイスが分離されている。記事ではWebSocketクラス一つをimplementしているが、Jetty 8 ではWebSocket.OnXXYYというように用途別に最低限度必要なinterfaceのみに分離されている。今回はチャットとしてテキストメッセージしか扱わないので、WebSocket.OnTextMessageをWebSocketとあわせてimplementする。

この時点で「こりゃあ、直接jetty-websocketのテストコード漁ったほうが早そうだ」と見切りをつけて、githubからjettyのコードをclone。
以下のテストコードが見つかったので、流用。

• https://github.com/eclipse/jetty.project/blob/master/jetty-websocket/src/test/java/org/eclipse/jetty/websocket/TestServer.java

で、特にコンテキストパスとかは設定せずに実装。こんな感じになりました。

webSocketChat.MyWebSocket.java:

package webSocketChat;
 
import java.io.IOException;
import java.util.Set;
import java.util.concurrent.CopyOnWriteArraySet;
 
import org.eclipse.jetty.websocket.WebSocket;
 
public class MyWebSocket implements WebSocket, WebSocket.OnTextMessage {
 
    Connection conn;
 
    static Set<MyWebSocket> _connections = new CopyOnWriteArraySet<MyWebSocket>();
 
    public void onOpen(Connection paramConnection) {
        conn = paramConnection;
        synchronized (_connections) {
            _connections.add(this);
        }
    }
 
    public void onClose(int paramInt, String paramString) {
        synchronized (_connections) {
            _connections.remove(this);
        }
    }
 
    public void onMessage(String paramString) {
        for (MyWebSocket c : _connections) {
            try {
                c.conn.sendMessage(paramString);
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }
 
}

webSocketChat.MyWebSocketServer.java:

package webSocketChat;
 
import javax.servlet.http.HttpServletRequest;
 
import org.eclipse.jetty.server.Server;
import org.eclipse.jetty.server.handler.ResourceHandler;
import org.eclipse.jetty.server.nio.SelectChannelConnector;
import org.eclipse.jetty.websocket.WebSocket;
import org.eclipse.jetty.websocket.WebSocketHandler;
 
public class MyWebSocketServer extends Server {
    SelectChannelConnector _connector;
    WebSocketHandler _wsHandler;
    ResourceHandler _rsHandler;
 
    public MyWebSocketServer(int port, String dir) {
        _connector = new SelectChannelConnector();
        _connector.setPort(port);
        addConnector(_connector);
 
        _wsHandler = new WebSocketHandler() {
            public WebSocket doWebSocketConnect(
                    HttpServletRequest paramHttpServletRequest,
                    String paramString) {
                System.out.printf("protocol=%s¥n", paramString);
                return new MyWebSocket();
            }
        };
        _rsHandler = new ResourceHandler();
        _rsHandler.setDirectoriesListed(true);
        _rsHandler.setResourceBase(dir);
        _wsHandler.setHandler(_rsHandler);
        setHandler(_wsHandler);
    }
 
    private static void usage() {
        System.err.println("java -cp CLASSPATH " + MyWebSocketServer.class
                + " [ OPTIONS ]");
        System.err.println("  -p|--port PORT    (default 8080)");
        System.err.println("  -d|--docroot file (default 'src/main/resources/html')");
        System.exit(1);
    }
 
    public static void main(String... args) throws Exception {
 
        int port = 8080;
        String docroot = "src/main/resources/html";
 
        for (int i = 0; i < args.length; i++) {
            String a = args[i];
            if ("-p".equals(a) || "--port".equals(a))
                port = Integer.parseInt(args[++i]);
            else if ("-d".equals(a) || "--docroot".equals(a))
                docroot = args[++i];
            else if (a.startsWith("-"))
                usage();
        }
 
        MyWebSocketServer server = new MyWebSocketServer(port, docroot);
        server.start();
        server.join();
 
    }
}

で、HTMLファイルはどんなのを用意したかというと、こちらはGoogleのpywebsocketからそのままごっそりコピペ。

• http://code.google.com/p/pywebsocket/source/browse/trunk/src/example/console.html

で、継ぎ接ぎだらけですが曲がりなりにもチャットが動きました。

JettyとWebSocket、両方勉強できて一石二鳥かとも思ったんですが、Jettyの構造とか使い方もう少し勉強しないとダメですね・・・。

すべてのAndroidプログラマにオススメの一冊です。

自分もAndroidプログラミングを勉強していて、いくつかセキュリティ面も調査してきました。

本書籍で新しく勉強になった点など、以下、読書メモです。

• "3.5 固有識別子"(p29 - )
  • アプリ側で生成したUUIDを識別に使用するのがオススメ
  • 以下は非推奨
    • READ_PHONE_STATE必要：IMEI, IMSI, ICCID
    • READ_PHONE_STATE不要：シリアルNo, ANDROID_ID
• "4.2.1 ディレクトリ" p42以降：アプリケーションをSDカードに移動→apkがSDカードに移る。Audio/Videoなど容量の大きいリソースを抱えたAPKの場合は効果的。データやファイルなどは"/data/data"以下のままのようだ。
  • apkをSDカードに配置させるには、p45の"SDカードインストール"も参照。
• p83 : "5.5.2 プリファレンスメソッド" : 3種類もある・・・
  • Context.getSharedPreferences() : MODE指定可能
  • PreferenceManager.getDefaultSharedPreferences() : MODE指定不可、MODE_PRIVATE固定
  • Activity.getPreferences() : MODE指定可能
• p89 : データベースファイルの保護 :
  • SQLiteDatabase.openOrCDreateDatabase() : MODE指定不可、但し 644 でDBファイルが作成されるので要注意(他アプリからも読取は可)
  • Context.openOrCreateDatabase() : MODE指定可能
  • SQLiteOpenHelper : MODE指定不可、MODE_PRIVATE固定
• "6.5 疑われやすいパーミッションの組み合わせ" (p117 - )
  • パーミッションの「組み合わせ」に対して、疑われてしまいそうなペアを示してくれているので、開発したアプリがこれらに該当する場合はユーザーへ分かりやすい形で明記する必要がある。
• "7.6 コンテントプロバイダのパーミッション設定事例" : 事例ベースで解説してくれているので分かりやすい。
  • コンテントプロバイダのパーミッションは、他(Activity/Receiver/Service)より複雑なので、最終的にこうした事例ベースに当てはめた上で検討することになりそう。
• "OSによるインテントデータの隠ぺい" (p153 - ) : log上でIntent内容がマスクされるか否か、抜き書き
  • "tel:" マスクされる
  • "smsto:" : マスクされる
  • "mailto:" : アドレスはそのまま表示される
  • "http://" : URLとクエリがそのまま表示される
  • "geo:" : そのまま表示される
• "9.2.3 ProGuardの使用法" (p199)
  • "アンドロイドSDKの注意点" : まさにこれに嵌ってしまった・・・。
  • SDK r16 にアップデートしたら再発。SDKェ・・・。
• "動作している環境からパスワードを生成し、使用する" (p233 - )
  • 当然ながら、ここに掲載されているサンプルコードをそのまま使うのではなく、改造して使う。
  • ProGuardのセクションでは特に記されていないが、SDKのクラス・メソッドの呼び出しは難読化されないので、例えばPBEKeySpec()の呼び出し箇所から変数を逆に辿り、パスワードが解析される危険性は残る。(とはいえ、カジュアルハックの防止には効果がありそう)

以下は、本書を読んでいて不足感を感じた点です。

• ログ出力についての記述 : android.util.Log#v(), d(), i() ... はisLoggable()と組み合わせないと、なんだけど、自分の認識以上に常識化してるのかな？あるいは、そもそも秘密情報はデバッグログといえども出力しない、というのは当たり前の前提になっているのだろうか。
• アプリケーションに焦点を絞っているから仕方ないとは思うが、サーバとの通信(HTTP, HTTPSを使ったAPI呼び出しなど)関連のトピックが無い。
  • 例１：HTTPSを使うときの証明書の扱い
    • Androidにインストール済みのルート証明書
    • 自己署名証明書の危険性、などなど
  • 例２：OAuthの2-legged/3-leggedで使われるConsumerKeyの取り扱い
    • 他、サーバサイドと絡めたtokenの適切な扱いなど。

上記のような不足感はあるものの、Androidアプリに特化した「セキュア開発」本としては日本で恐らく第一であり、内容的にも必要十分と思われます。Androidアプリの開発者全てにオススメできる一冊です。

バージョンごとに専用のディレクトリ作って、

repo init -u https://android.googlesource.com/platform/manifest -b (バージョン)

してて、その度に10GB位ごっそり削られてた。

よくよく考えれば、repoってgitをAndroidのソースツリー用に制御する仕組みで、結局はgitで管理されてる。
ということは、単に「あるソースツリーの特定のバージョンを調べたい」だけであれば、

git archive --format=tar (バージョン) | (cd /tmp/ && tar xf - )

で済む。"(バージョン)"の正式な値については

git tag

で確認できる。

適当に調べただけなので、もしかしたらarchive以外に、特定のtagやcommit-idのファイルを取得するのに適したコマンドがあるかもしれない。

• [ Prev ]
• [ Next ]
• [ 技術 ]

今更ながらCSRFやCSSXSS関連の参考リンクをメモ。

• 開発者のための正しいCSRF対策
  • http://www.jumperz.net/texts/csrf.htm
• 高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由, hiddenパラメタは漏れやすいのか？
  • http://takagi-hiromitsu.jp/diary/20060409.html
• おさかなラボ - [CSRF]高木氏のエントリへの返答
  • http://kaede.to/~canada/doc/csrf-response-to-mr-takagi
• CSRF対策のトークンをワンタイムにしたら意図に反して脆弱になった実装例 - 徳丸浩の日記
  • http://www.tokumaru.org/d/20110127.html
• なるほど：CSRF対策に「ワンタイムトークン」方式を推奨しない理由
  • http://blogs.wankuma.com/jitta/archive/2006/04/13/22414.aspx
• CSRFとCSSXSSは分けて議論したい | 水無月ばけらのえび日記
  • http://bakera.jp/ebi/topic/2508
• こめんと(2006-03-30) : ■ [Security] えび日記: CSRFの説明に追記
  • http://www.oiwa.jp/~yutaka/tdiary/20060330.html
• こめんと(2006-04-02) : ■ [Security] CSRF と CSSXSS に関する議論について
  • http://www.oiwa.jp/~yutaka/tdiary/20060402.html
• CSSXSSの問題 - adiary開発日誌
  • http://adiary.blog.abk.nu/090
• なぜCSSXSSに抜本的に対策をとることが難しいか
  • http://blog.ishinao.net/2006/03/31/