タイトル/名前 | 更新者 | 更新日 |
---|---|---|
技術/Apache/mod_includeメモ | msakamoto-sf | 2011-08-08 00:22:57 |
技術/Android/DynamicClassLoading | msakamoto-sf | 2011-08-07 18:20:32 |
読書/仏教関連 | msakamoto-sf | 2011-07-24 15:32:02 |
日記/2011/07/18/袋入りのインスタントラーメンで簡易焼きラーメン | msakamoto-sf | 2011-07-18 20:37:15 |
日記/2011/07/10/cURLでApacheSolrにXMLを送信 | msakamoto-sf | 2011-07-10 23:19:02 |
技術/Android/AmbiguousDocuments | msakamoto-sf | 2011-07-10 14:05:41 |
日記/2011/07/09/「頑張って」上手く行ったことなんて無かったけどなぁ。 | msakamoto-sf | 2011-07-09 23:36:02 |
技術/Android/SamePackageName | msakamoto-sf | 2011-07-09 23:10:55 |
日記/2011/07/02/「責任者出てコーイ!」 | msakamoto-sf | 2011-07-02 14:52:10 |
技術/Android/DebuggerDetection | msakamoto-sf | 2011-06-26 19:56:49 |
滅多に使うことが無いけど、使うときも無いでも無いということでメモ。
あんまりApacheのバージョン間で大きな違いはないけど、一応バージョンごとのドキュメントURL:
おまけ:IIS/5.0, 6.0系のSSI
以下、Apache 2.x系での実験。
Androidで、ClassLoaderをカスタマイズして実行時にモジュールをロードする方法について参考リンクをメモ。
流れとしてはdexファイルを読み込んでパッケージローカルに保存、DexClassLoaderを使ってloadClass()する。
ただしこの時注意点があって、DexClassLoaderのコンストラクタには"Optimized Dex"ファイルの出力先ディレクトリを指定する引数がある。これをうっかりSDカードにしてしまうと、SDカードはパーミッション制御の範囲外になるので、悪意のあるアプリによって置き換えられてしまう可能性がある。
"dexファイルを読み込んで・・・"と書いてしまっているが、実際は"dexファイルが入ってるだけのjarファイル"なのでそこだけ注意。
ということで、動的なClassLoadingを行うときのセキュリティ上の注意点についてはとりあえず下記参照。
あと変わり種としてはPackageManagerを使って任意のパッケージからclassを取り出すサンプル:
プラットフォーム的な仕組みであるとか、プラグインモジュールのアーキテクチャに使うと面白そうです。
ただし、Android Developers Blog の記事にもありますが、ロードするDexファイルをビルドするためにAntを使わざるをえないなど、開発に一手間加わってしまう点に注意。
信仰がどーとかではなくて、精神的な辛さや日々の悩みを華麗にスルーするためのテクニックの一つとして、仏教はかなり有用であると思われます。
というわけで、道具、或いはテクニックとして仏教の考え方を日々の生活で使いこなせるようになる、そういう視点で読んできた仏教関連書籍をご紹介。
細かい各論やインド古代史、文化史、仏教の伝来に伴う教義の変遷などは専門家が考えることですのですっぱり無視してます。
上座部系の、つまり瞑想で自分の心の動きを観察して云々・・・という系、あとは原始仏教関連を読んでます。
最初に買った仏教書。ゆるふわ。
仏教を使った精神分析手法・・・と言っても差し支えない。人間の心の動きを仏教視点で分析し、怒りや欲、傲慢の鎮め方を解説。
最近になって何冊も本を書いてますので、この人の本を目にした人も多いのでは。
心の動きを観察する、というのは上座部仏教の印象が強く、そうなると原始仏教に目が行くわけです。
ということで日本が誇る仏教界の巨人、中村元氏の著作を読んでみました。
・「原始仏教―その思想と生活」
・「中村元「仏教の真髄」を語る」
・「中村元が説く仏教のこころ」
・「ブッダのことば―スッタニパータ」
中村元氏による日本語訳は、訳文よりも註解の方が文章量が多くなっているので注意。
「なぜこのような訳出にしたのか」を後世に伝えようという心意気故なのだと思う。多分。
中村元氏による原始仏教の一連の著作は、スッタニパータなど当時の資料を読み解くための文脈を知る上で有用です。
一方で、やはり現代に生きている以上、ブッダが語った言葉を今に活かすための橋渡しも必要です。
そういう場合は、アルボムッレ・スマナサーラ氏の著作が参考になります。
・原訳「スッタ・ニパータ」蛇の章
スッタニパータなら中村元氏による訳出があり、上でも紹介しています。
ただ、スッタニパータって濃縮度が高すぎるんですよね・・・。例えば「牛飼いダニヤ」の話、スッタニパータ読んだだけでは、なんで最後になって雨がふりだしただけで、いきなり牛飼いダニヤが「仏に帰依します」なんて言い出したのか分かりませんでした。
ということで、スッタニパータの中でも「蛇の章」だけを、今の生活に活かすための解説を付けてくれたのがこの一冊です。
お気楽に仏教を知りたいためのエントランス。
手塚治虫版「ブッダ」は取り上げませんでした。あれはあくまでも漫画、フィクションですので。
手塚治虫版の「ブッダ」は「火の鳥」にもつながる輪廻転生の世界観が強く描かれているように感じます。
一方で原始仏教を調べていくと、どうも「解脱」や「悟り」は輪廻転生の輪から外れることを目的としているように思われる。
死んだ後どうなるのか、来世は存在するのか、そうした疑問に対しては「無記」を貫き、まずは今眼の前にある苦しみに同対処すれば良いのか、それを積み重ねていくことで「涅槃」に到達する。
ということで手塚治虫版「ブッダ」は、ゴータマシッダールタという人の伝記としては面白いのですが、仏教を学んだりツールとして使いこなすという視点では向いてないように思えたのでスルーしました。
カップ焼きそば買うよりは確実にウンマーイ。フライパン一個でOK。
注意点としては、汁気が無いためどうしても塩分を摂り過ぎてしまいがち。粉末スープの量を調整して、薄味を意識しましょう。半分くらいに抑えても問題ありません。
塩ラーメンで試してみましたが、思う存分胡椒をふりかけ、スパイシーな塩焼きそばとして楽しめました。
特にプログラムを作成しなくともお手軽に出来ちゃうのでメモ。
curl --data-binary @utf8-example.xml \ -H "Content-Type: application/xml; charset=utf-8" \ http://localhost:8080/solr/update
commitも忘れずに:
curl --data-binary "<commit/>" \ -H "Content-Type: application/xml; charset=utf-8" \ http://localhost:8080/solr/update
ファイル指定の場合に、"@"付けるのに気づかなくて30分ほど嵌った。
Windows版のcURLの例:
http://www.paehl.com/open_source/?CURL_7.21.6
他のWin32版:
http://curl.haxx.se/download.html
なんかどこもかしこも「頑張ろう」「頑張れ」ばっかりだけど、もう戦後50年どころか明治からずーっと日本って頑張ってきたんだから、もういい加減頑張らなくていいと思うんだけど。
30年の人生で、「頑張って」上手く行ったことなんて無かったけどなぁ。
高校受験の時「頑張って」挑んだら、推薦入学の筆記試験で問題冊子丸々2ページ読み忘れてて落ちたので、普通の試験になっちゃったし。
高校の勉強では、「頑張って」真面目に理数系を学ぼうとしたらついて行けなくなって、諦めて自分のペースで授業中内職して教科書の問題を丸暗記し始めたらなんとか持ち直してきたし。
社会人になってからは、「頑張って」あっちこっちソフトウェアの勉強に精を出していたら周りと軋轢を産んで、でもそれは結局自縄自縛で自爆してただけで、結局転職先を3ヶ月で辞めてしまって、暫くニートしてだらだらしてたらなぜかセキュリティ業界に入れてしまったし。
自分の場合、最終的に満足な結果に結びついた行動というのは須らく、「あ~、こんな内職というか、ダメ人間みたいなことしてて良いのかな・・・」と、世間体を気にするような行いばかり。それでも、それが「息をするように自然に思えて」ならなくて、むしろそうしないと、息が出来なくなって死んでしまいそうなほどの切迫感に押されてそうした行動に出ざるを得なかったというか。
いやまぁ実際ですね。高校2年の数学の授業中、最前列で、二年生の数学の教科書と、一年生の数学の教科書を両方開いて、二年生の数学の授業のノートをとりつつ、いそいそと一年生の数学の問題を解いて答え合わせしてたりするのって、すっげー罪悪感あったわwww
でもそれが無ければ、数学死んでたことは確かだし、結果的に「教科書レベルの問題に完全に解答できるようになる」という大学受験の鉄則に従ったことになるので結果オーライ。
頑張らなくって良いんだって。「もっと頑張れ!」なんて外野の声は綺麗すっぱり無視して、自分にとって一番「息をするように自然な」ペースで行こうよ。
頑なに張ってたって、いつか疲れが来てしまうんだし。
人生は、スポーツじゃないし、戦争でも無いんだから。もう戦争は、終わったんだから。
あ、ただし、「怠ける」のはさすがに無しで。でも「不本意な」働きすぎはやめようね、とか、他人が言う「頑張れ」を真に受けて焦る必要は無いよね、とか、そんな話。
パッケージ名が同じ二つのアプリケーションをインストールするとどうなるか?
結論:アプリケーションのアップデートと状況は一緒。
基本的にパッケージ名に対してユニークなuid/gidが発行されるため、パッケージ名が同じであればインストール先/uid/gidも同一となり、アプリケーションのバージョンアップを行う事になる。
ただしapkに署名した場合、証明書が同一である必要がある。後述するが、パッケージ名が同じだが署名が異なる場合、二つ目のアプリはインストール出来ない。
タイトル通り、責任者って「責められる任」だよなぁ。意味調べてみると「政治・道徳・法律などの観点から非難されるべき責・咎」ってまさにそのまま。もう一つ、「人が引き受けてなすべき任務」というのもある。
どこの組織でも「責任者を自分から進んで引き受ける人間が居ない」って話は聞くけど、そりゃその通り。誰が好き好んで「責められる任務」を負わなくちゃいかんのだ。
どっかで、「責任」という言葉を全く使わずに上手く回せてる組織って無いもんかねぇ。
以前、プロジェクトの管理や調整、何かあったときにお客様に頭下げた上で事態収拾に走りまわってる部長と飲んだ時に「色々やりすぎて、自分の肩書きをどう呼べばいいのかわかんねぇwww」とか言ってて、その時は「コーディネータ(調整役)」ってどうでしょうとか返したんだけど。
それに、どう言葉遊びを繰り返したところで、対外的には「責任者出てコーイ!」って言われたらその組織を取りまとめている「頭」が出てくる事になるんだから。だったら、せめて、言葉遊びと笑われても、言葉尻だけでも暗い字面を使いたくないよなぁ。
デバッガが接続されているか確認したい時に。
元ネタ:
boolean isDebuggable = (0 != (getApplicationInfo().flags &= ApplicationInfo.FLAG_DEBUGGABLE)); if ( isDebuggable ) // ...
ただし Context.getAppliccationInfo() は API Level 4 以上。
boolean debugConn = Debug.isDebuggerConnected();
package test.android; import android.app.Activity; import android.content.pm.ApplicationInfo; import android.os.Bundle; import android.os.Debug; import android.view.View; import android.view.View.OnClickListener; import android.widget.Button; import android.widget.Toast; public class Main extends Activity { Button btnCheckManifest; Button btnCheckConnected; /** Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); btnCheckManifest = (Button) findViewById(R.id.main_btn_check_manifest); btnCheckConnected = (Button) findViewById(R.id.main_btn_check_connected); btnCheckManifest.setOnClickListener(new OnClickListener() { @Override public void onClick(View v) { boolean isDebuggable = (0 != (Main.this.getApplicationInfo().flags &= ApplicationInfo.FLAG_DEBUGGABLE)); if (isDebuggable) { Toast.makeText(Main.this, "Debuggable", Toast.LENGTH_SHORT).show(); } else { Toast.makeText(Main.this, "NOT Debuggable", Toast.LENGTH_SHORT).show(); } } }); btnCheckConnected.setOnClickListener(new OnClickListener() { @Override public void onClick(View v) { boolean debugConn = Debug.isDebuggerConnected(); if (debugConn) { Toast.makeText(Main.this, "Debugger Conected", Toast.LENGTH_SHORT).show(); } else { Toast.makeText(Main.this, "Debugger NOT Conected", Toast.LENGTH_SHORT).show(); } } }); } }
これらを使って「デバッガが接続されている端末上では、逆解析されたくないので実行を停止する」テクニックを使っても無意味なので注意すること。
調査不足なので詳細は書けないが、誰でも入手できるソフトウェアで逆解析は比較的容易になりつつある。
恐らく近い将来、このレベルの"AntiDebug"技術は易々と回避されるようになるだろう(或いは、既にそうなっているか)。