セキュリティ＆プログラミングキャンプキャラバン 2008 京都

セキュリティ＆プログラミングキャンプキャラバン 2008 京都にいってきました。

http://www.jipdec.or.jp/camp/caravan/kyoto.html

元々のセキュリティ＆プログラミングキャンプが若手技術者の育成がターゲットであるからか、会場には学生さんとおぼしき方々が多い印象を受けました。私も hex ではぎりぎり 10 代の若手なつもりですが、私と同じ位の年の人は少なかったように感じました。80 名超来られていたとのことですが、直感的に 1-2 割位でしょうか。

全般的にターゲットを若年層に設定していること、時間の制約があることなどから、あまり細かい技術内容には立ち入らず、キャンプなどで行う事のオーバービュー的な要素が強かったように思いますが、スピーカの方々各々の話の棲み分けがあり楽しいひとときでした。今お仕事させて頂いている会社の方とも偶然あったり。個々の内容について思う事をつらつらと。

吉岡さん

興味あったのは、コードリーディングの話 (ここなどでも書かれておられます) で、方法論にも興味はあるのですが、その大切さというか、開発者にとっての有用性みたいなものをどうメッセージアウトされ、キャンプで取り組まれているのか、という辺り。

ウェブ開発では社内フレームワークであれ OSS フレームワークであれ、何らかのフレームワークを取り入れた開発が当たり前になってると思うのですが、利用しているフレームワークのコードを読んでいる人って思ったより少ない？という感覚が背景にあったりします。(あくまで私個人の少ない経験にしか基づいていないですが)「開発」に携わる業務をしていれば、人のコードを読む機会はそれなりにあるはずで、「読む事」自体を業務で経験しないことは少ないはずなのだけれども、その読む「対象」を、作っているプロダクトそのものから、一つ下の層 (フレームワーク等) に広げる事が少ないのは何故なのかなぁ？と。想像するに

その層は高度で理解の難しいものである等 => 心理的な敷居
方法がよくわからない等 => 方法論的なところ
業務的に必要な事は大抵のことは (コードリーディングしなくても) 実現出来る等 => 必要を感じない

最初の二つの、やってみたいがイマイチやり方がわからないパターンでは、方法論や対象の選び方を体系たてて伝えていけば、きっといいのだろうなぁ、と。三つ目のパターンは、「仕組みがわからないと気持ち悪い」といった感覚であったり、「より良いものを作りたい」といった感覚であったり、そういう要素が絡んでくるから、別のメッセージが必要なのかな、など。結論はないのですが、そんな事を思いながらお話伺ってました。

竹迫さん

最近のウェブアプリケーション開発動向の話。紹介にあった 100% javascript の MSX のエミュレータ。すごい。。。

jsMSX - The first MSX emulator 100% written in Javascript

サーバサイド javascript までは、なかなかまだ遠いのではないかなぁ、というのが正直な印象ですが、javascript は processing.js 他、本当に色々面白い取り組みがあるので、そういう情報交換などの為にも、関西圏で JS や AS の勉強会 (OSC 2008 Kansai の Shibuya.js 以来そういうのに出ていない) を探してみようと思いました。福岡の tenjin.web みたいなのってないかしら。

園田さん

PC の堅牢性についてのお話を中心の話題にその周辺を。生体認証もモノによってはそこまで安全ではないという話が面白く。サーバのアタックログの話の際に、私が管理していた学生時代研究室のマシンがクラックされた悲しい思い出が蘇ってしまいました。。。

長谷川さん

Unicode 周りの脆弱性の話を中心に。多対一変換の脆弱性 (パストラバーサル) や、Unicode 制御文字列を利用した拡張子の偽装といった、本日の中ではかなり詳細技術よりの内容でした。正直そういう観点で考えた事がなかったので新鮮でした。以下にも色々資料あるようです。

http://www.utf-8.jp/

後者の例の RLO をちょっと試してみました。

		String a = "this-" + "\u202E" + "txt.exe";
		System.out.println(a);

確かに、this-exe.txt って表示されます。ini と、先述のパストラバーサルなんかとあわせるとちょっとどきっとする系かもしれないですね。

その他

質疑応答の時に思ったことなど。

「コード読んでみたいのだけれど対象の選び方がわからない」という質問について

自分だったらどう答えるだろう、と思い。

コードを読む前提が「何かを作ること」か、「ソフトウェア (とかプロトコルとか) の振る舞いを知ること」かで少し変わってくるのかなぁ、と思いました。

私の場合は、基本的に作りたいものがあって、そこに近い領域のものを読むか、もしくは類似しているものを選んで読む事が多い気がします。「近い領域」というのは、Java で Web アプリを作りたい場合、Servlet の基本仕様の上でさらにフレームワークがのっかり、そのフレームワークを利用してコードを書くので、そのフレームワーク層を読むということです。(Web アプリを作りたい時に、DB のソースをいきなり読むことはないですね ^^;)
Choistudy では Cubby/Seasar/S2Dao 周り、JS 書く場合には YUI、jQuery 及び jQuery Plugin などのソース。基本的にチュートリアルやリファレンス、サンプルコードだけでもある程度書けるのですが、「よりシンプルな形で、より自分が書くコードを少なくする方法を知るため」にソースを読む事が多い気がします。(基本、自分の書くコードを信用していないので、同じ事が出来るなら、極力少なく実現したい (笑))。後は標準で提供されてない機能を拡張によって実現したい時など。

例えば、TCP/IP のネットワーク通信をするミドルウェアを作ってみたい、であれば、下の層であればカーネルの TCP/IP や Socket API の実装周りを調べるもよし、逆に同じ層でいけば、目標に似たような機能をもつミドルウェアを探すも良しなのでは。それ以外に、最近では Socket API なども抽象化するフレームワーク (Java だと Apache Mina とか、Perl の POE とか) もあるので、そちらが対象という方針もあるかと思います。

要は、作りたいものの近傍にあるフレームワークや API 、もしくはそれを使っているもの、などをコードを読む対象として選ぶ。

後者の場合は、私にはあまりあてはまらないパターンです。(かつて業務では、ミドルウェアの機能検証を行っていた際に、アンドキュメントな機能を調べる為やドキュメントのないベータ版の振る舞いを調べる為に読んだ事もありますが)
ただ、この場合 HTTP サーバの実装を知りたい、等対象がはっきりしてると思いますので、選び方としては、規模、記述言語の好み、開発コミュニティの中心言語などなどを基準にしたらいいのかな、と思います。

いずれにせよ、皆様おっしゃっていたように、あまり「大きすぎるもの」に最初からチャレンジすると気持ちが萎える事も多いかと思いますので、ある程度ボリューム小さいものを選ぶのが良いという点は共通でありますね。

「コンピュータサイエンスの教育が体系だっていないと感じる」との質問について

この辺りは Choistudy を運営していく際に、弊社でも良く話題に上がる話です。学生さんもそのように感じているのだなぁ、という事を知りました。業界的には ITSS など、その辺りの制度仕組み的な所はこれから序々に整って行く所なのでしょうね。