カテゴリー［Programingの話］

2014年09月01日

CEDECで気になるセッション

今年は例年とは違って結構面白そうなセッションがあったという印象。
だが仕事が割とアレなもんで行こうかという気にはなれず。
（仮に直行直帰でもパシフィコ横浜は今の家からだとかなり遠いし）

サンドボックス型アクションゲームのマルチプレイ実装方法

オンラインゲームを支える技術っていう、かなり凄い本を書いた方のセッション。
経歴的に自分よりも上の世代の方かと思いきや、写真が若くてビックリ。

これはできれば行きたかった。

“次世代のライティング“実用的速度で動作するボクセルコーントレースライティング解説

PS4 で30ＦＰＳで事前計算不要のリアルタイムＧＩを実装、と聞いてさすがにどんなものなんかな～と興味を持ちました。
ボクセルコーントレースっていうアルゴリズムの事は全く知りません。

ゲーム世界を動かすサイコロの正体 ～ 往年のナムコタイトルから学ぶ乱数の進化と応用

なかなか珍しい擬似乱数のセッション。
擬似乱数は奥が非常に深いものなのだが、それについて書かれている本やこういったセッションはほとんど無いと見えるので。

2020年までのゲームハードウェア技術トレンド
ハードウェア技術が数年後どうなっているのか？ を予測するというこれまた面白そうなセッション。
こういうのも今までありそうで無かった気がする。
ハードウェアの進歩がかなり頭打ちになってきている状況なので、より需要が増えているのかも。

オンラインゲームのデータを守れ！ ～暗号アルゴリズムの正しい使い方～
暗号化アルゴリズムをちょっと自分で調べてみたのだが、少なくともネットでは日本語の資料がとんでもなく少ないっぽいという事が分かったのでより興味がある。

起業一年目の通信簿　～ふりかえり と これから～
知っている人が出ているのもさることながら、内容が非常に興味深い。
色んな意味で参考になりそうな気がする。

あれ、何か中国系？っぽい会社のネットセキュリティに関してのPRセッションがあったような気がしたが…。
勘違いか無くなったのか。

ともあれ、ここら辺のセッションを受けた人、お話を聞かせて下さい！

| 2014年09月01日(月)

2014年07月31日

7月のあれこれをざっくりとまとめてみました

◆7月2日（水）

会社帰りに清澄白川まで行って友人T＆P＆シンヤとテニス。
ほぼ一緒にテニスを始めてから30年まであと2年？

ちなみにサーブしたら五十肩かなんかで激痛が！？ ＜普段からあるものなので特に大事ではないです。

　

◆7月5日（土）
会社のおかげで日帰りの社員旅行に行くことができました。
群馬県の水上（よくスキーで宝台樹に行く途中の所）まで行ってラフティングとバーベキューをやってきました。
天気は雨の予定が何とか曇りで持ちこたえて、川の水はかなり冷たかったものの（まだ谷川岳の雪解け水が残ってるそうです）1日楽しんで来ました。
元一緒のチームだった同世代のデザイナーの方と一緒できたのでぼっちにならずに済みました。

今回ラフティングとバーベキューでお世話になった所のポスター。

　

◆7月26日（土）奥さんがアル中（アルフィー中毒）なもんで…

1年ぶりにアルフィー夏のイベント（去年のは春のツアーで夏のイベントは初参加）でさいたまスーパーアリーナまで行って来ました！
今回はちゃんとボーカル桜井さん（＜僕的にはやはりイチオシ）のメリーアン＆星空のディスタンスがちゃんと聴けたので大満足でした～

メリーアン＆星空のディスタンスは小6～中1の頃ベストテンに長期ランクインしてたのを覚えてる。
去年の春のツアーではメリーアンが聴けなかった。

◆キャンディ・クラッシュのバランス調整アルゴリズムが相当に凄いと思うんだが？

友人Tがやたらとやれやれうるさかったもんでスマホ Candy Crush Saga（キャンディークラッシュサーガ）をインストール＆プレイ

このゲームのレベルデザインの出来の良さはまずます程度で、作れと言われればツールを作る事は可能。

しかしこのバランス調整っぷり何なのマジで！？
どうやったらこういうランダムのバランス調整できるのかマジで想像が付かない。

が、幾つか仮説を考えてみた。

（Ａ）
　・バランス調整専門スタッフがいる
　・スタッフが特定のランダムシード値から始めてひたすらプレイしまくり、そのプレイ内容からアリ、ナシを判定してシード値をリスト化しておく

　・これらのシード値リストを一定回数で回している（一定回数プレイし続ければ、スタッフがプレイしてクリアできた配列に必ず辿り着く）

（Ｂ）
　・（Ａ）とやる事はほぼ同じだが、人ではなく「自動キャンディークラッシュ解法ルーチン（操作可能総当り）」アルゴリズム（ツール）を作成して結果も全て統計で出せるようにする。

　・これをひと晩中ありったけのPCで回す、もしくは専用PCを用意してひたすら計算させてレベル毎のシード値及び難易度リストを自動生成する

　・これらのシード値リストを一定回数で回している

　
（Ｃ）
　・プレイヤー名やFacebookID、端末のIDなどを元にユニークなハッシュ値を生成

　・そのハッシュ値シードにしてメルセンヌツイスターをひたすら回し続けているだけ（※）

（※） （Ａ），（Ｂ） もランダム生成に関しては当然メルセンヌツイスタを使用しています。

あと新しいステージに移行して1日以上が経過すると、クリア可能な配列が出てくるようなバランスになっている感じがする。
現在は120面辺り。
　

もうちょっと書くネタが（キャンディークラッシュじゃないです）あるんだけど相当長くなるので近々また書きます。

| 2014年07月31日(木)

2012年09月20日

そして今日は久々に

ほぼ１２時間コース。久々だなあ。

ただ今日やってて思ったんだけれど、正直プログラミングだけやってていい状態だったら１２時間働いてもそんなに大してキツくはないわ。
ひたすらプログラムだけするのは内容はキツくても基本的に楽しいもんだしね。C++ならばなおさら。

やっぱ原因不明の不具合修正を延々と当ても無くやるとか、原因不明の強制終了の原因を延々と探したり、って正直まともな仕事じゃねえよ。
もちろんやらなきゃどうしようもないからそういうクソみたいな仕事だけれどやる訳なんですがね。

あと仕様策定のミーティングや修正や調整っていうのはまともな仕事ではあるけれど、プログラマーチーフの仕事かどうか、っつーとまた微妙な状況だったりするよな。
まあ、チーム内プログラマーの面談に参加したのは至極真っ当な仕事ですけどね。

| コメント (6) | 2012年09月20日(木)

2012年08月28日

プログラムネタ、なのか？

春香「プログラマーさんっ！納期ですよ！納期！」 - ゴールデンタイムズ

微妙にプログラマーなのか一般的なSEの話なのかWebプログラマーなのか、はたまたアイマスの話なのかが流れが読めず。

教えてくれた某氏が「電車の中で吹いた」と言ってたのはアイマスとのコンビネーションかな？

まあネタとしては面白いんだけれど、どうやってこれを教本とかマニュアルに落とし込むかな、っていう方に興味が行ってしまうなあ。

> 46 ：響「rmコマンドCRONから消し忘れたけどなんくるないさー！」
これがLinux系で凄く重要そうなんだけれど分かってません。

> 77 ：やよい「うぅ、DBに手打ちでデータぶち込んだらデータの整合性がくずれちゃいましたぁ・・・」
これもDBで重要そうなんだけれど厳密には分からないなあ。
手打ちでデータ入れ込むと整合性まで崩れるのか…？
「ゴクリ…」って感じ。

> 89 ：あずさ「えっと、このメソッドはオーバーライドされてて、戻り値の参照がマルチスレッドで排他制御…」
あずさ「あら？ここはどこかしら？」

これの面白さが分かるレベルの奴は相当マルチスレッド分かってるんだけれどね…。
（マルチスレッド部分のバグをVisualStudioなんかで正確に追っていくと、突然に見たことの無いソースに切り替わってイミフになる、を表現していると思われ）

> 96 ：千早「おっPython」
千早「くっ……」
これの意味が知りたいなあ…。

> 145 ：えっ！？IE5.5対応・・・ですか・・・？」
これは割と笑えた。Webプログラマーだよね。
ここだけの話、ウチの社内ツールがIE(9)対応して無くて笑えたんだがｗ

全体的に高度過ぎるんだよね。だから逆に笑えないんだなあ。

| 2012年08月28日(火)

2012年08月14日

Java言語のダメな所３（＋１）大ポイント （４）

３+１． Java言語仕様自体がOracle（SunMicroSystems）という、ソフトウェア開発者からすると割とダメな会社に所有されてしまっている部分

かつて（10年ちょっと前）SunMicroSystemsがJavaを作っていた頃、MSがMicrosoftJ++ という開発環境を売り出したら訴訟問題になり、最終的にMSはそのJ++を捨てました。という事があったりします。
ちなみにその反省を生かしてMSが仕様のオープン化を前提で開発した開発環境／言語がC#だったりするんだがそれは別に書いた方がいいかな？

まあ当のSunMicrosystemsも結極会社が死んで、その資産を今受け継いでいるのがOracleっていう今の時代からすると終わってる会社で。

まず僕は"データベース屋さん"という分野の仕事がどんなものかは分かってないです。
また官公庁や巨大企業レベルでのDBというものが、どういった要件が必要かという事も理解はしていません。

が、ソフトの仕事をWindows／DOSベースの開発でほぼ20年、ここ最近ではLamp系でのDBがどんなものかも多少は理解してきた所で言わせもらうと、

・ Oracleじゃなきゃダメでしょ

・ Oracleの○○の性能は別格なので他に変えられない

という話はネットでも仕事でも一度も噂レベルですら聞いたことがないです。

でも、この会社はMSに次いで世界で二番目のソフトウェア会社という事らしいです。意味が分かりません。
　
が、丁度こないだヤマモと飲んだ時にこのエントリの話と最後にコレで書こうと思ってるんだ、と話したらこれまたバッチリ正解を教えてくれました。
スーパーサイヤ人じゃないけれど、きっとヤマモは界王様なんじゃないかと思う。
正に「あなたがネ申か」（ってそれはデスノートだが）って感じですが。

「OracleはDBの資格商法で食ってるんですよ」

と聞いてあ、なーると。

１．OracleのDBを導入する（無論コンピュータの知識など何も知らない所に。大抵の場合は請け負った会社がやる＜Oracleが直接ではない）

２．OracleDBの一定以上の機能を使用するような場合は、その機能に応じた資格を所有した人間しか触れません。という決まりにOracleはしている

３．その資格を取るための試験が、そもそも受験料だけで30万とかして、会社のお金で資格を取らせるのがまず前提

４．その資格を持ってると、社員の場合給料が1,2万増えるとかそういう感じ

これじゃ説明になってないんだけれど、資格商法を説明するのは結構難しいな。

誤解を恐れずに言えばこんな感じ？

・ 性能は大したものでは正直無い（この10年代としては特に）

・ 性能などは分からない超お金持ちの客（企業）に、あれこれプレゼンして売りつけて導入させる（10～15年前ならIT化、20～30年前だと銀行や電車、スーパーやコンビニのオンライン化とか）

・ 導入後は保守費用も取れる

・ 保守でも新規導入であっても、導入コスト及びそれに伴う必要な資格でお金を取る

・ Oracleは資格とDBシステムを中間の業者に売るだけ（直接顧客には売らない）

うーん、情弱（2～30年前は世の中のほぼ全ての人が今で言う情弱でした）の人に、その人が必要と思われるサービス（たとえばスマホでWebを見るとかメールするとか）のアプリを本来の価格の10～100倍ぐらいの値段で売るんだけれど、メーカーやキャリアがそれを直接やるのではなく、売る仕事をする奴にハード及びソフトを売りつけて、その売ってる奴らからも金を取るという仕組み、かなあ。
これだとMS及びWindowsのビジネスモデルの説明に近いような気も（MSはハードは売らないけどな）？

ビジネスとしては時代に即したものであるけれど、類まれなレベル（それこそMSに近いレベル）での成功例だろうね。
ある意味ボロい（金持ちに売る＆性能はそこそこ及び最低限で可）って視点だとMSよりも大分上。

こういったコンシューマ向けには一切何も提供はしていない、またソフトウェア及び開発環境、プラットフォーム事業は一切行っていない会社がJavaなんていう言語の権利を持ってるんだからやる事は大体決まってるかな、と。
オラクルvsグーグルのJava-Android特許訴訟、いよいよ山場に from WirelessWire News « WIRED.jp

こんな会社が権利持ってしまってる開発環境、あなたは選択しますか？

（なんだけれど何でかGoogleが選択しちまったんだよな～。まあ三木谷と近い感じだったのかもしれない＜コンシューマ向けサービスを大々的に始めたのは初の試みだった訳で）

Googleも十分にそこら辺は反省はしているだろうと思われるので、

Google → Developers → Build mobile apps

に、Android以外の Google App Engine とかも合わせて開発してたりするんじゃねーか、と。

　

という感じで全くカケラもまとまりませんでしたが、こんな感じでいかがでしょうか？
Javaのダメな所。＞ヒデヲ氏

| コメント (4) | 2012年08月14日(火)

2012年08月07日

とりあえず”今日は”落とします

帰ってくるのがここ最近ではMAXで遅すぎの25時過ぎ。
今日は風呂も無しです。

メキシコ戦は最後まで見たいですが、多分寝ます。＜何だかんだでこのエントリ書いたりしてたら最後まで見てしまいました

ツイートに返信とか、ブクマ整理（昨日クロームを2つ立ち上げてから、タブ保存用のウィンドウを先に閉じてアボンとなった。履歴から復活）とかをメシ食いつつやってたら寝る時間に。

まあ今日の仕事が遅くになったのは仕方が無い事で。
ちょうどの区切りでもあるし、乗りかかった状態なので問題ありつつもやれそうになったので電車がある内は何とかしないとな、と。

　
ただコレだけは言わせてもらいますわ。

　iOSアプリの iTunesConnect への申請登録クソ過ぎワロタｗｗｗｗｗｗｗｗｗ

ちっとはGooglePlay見習えや。

っていうかGooglePlayがAppleのダメさ加減を全部リサーチした上で簡易な登録フォーマットにしてる事はほぼ間違いないか、と。

Macはかつてそのアプリ開発参入への閉鎖性でオワコンPCとなって徐々に死んでいった訳ですが。
それはWindowsの開放性とアプリ開発環境への信頼性と較べると歴然としたものであって。

今のiOSからは、かつてのMacの閉鎖性とほぼ同じようなものをひしひしと感じてしまうんだよね。
ま、これもジョブスの思想＆呪いかなあとも思うけれど。
根底から開発者を一切信用してないっていうか何ていうか。
つーかクラックされないアプリケーション（OSやデバドラを含め）などこの世に存在しないので、どこかで適当に切り上げて諦める、という視点が必要なのでは無いかと。

iOSでのそこら辺へのこだわりようは若干偏執的とまで言っていいかと。

そして、多くの場合歴史が示している通りに歴史は繰り返すものだったりする訳で。
やっぱ多様性を維持拡大できたプラットフォームというのが生き残るんじゃないかと。

| コメント (2) | 2012年08月07日(火)

2012年07月31日

Java言語のダメな所３大ポイント （３）

※ あくまでも個人的な感想です。

筆者は本格的なJavaのコーディングは行っておりませんが、C/C++に関しては２０年弱ほど職業プログラマーとしてのコーディング歴があり（同じコードを使いまわして20年じゃないよ）、大規模レベルのAndoroidアプリの開発において初めてJava開発環境に関わりました。

３． packageという、C++のnamespaceをむしろダメにしたような機能が付いてくる（＜指摘内容が言語仕様レベルかは不明）

http://ja.wikipedia.org/wiki/%E3%83%91%E3%83%83%E3%82%B1%E3%83%BC%E3%82%B8_(Java)

こいつは自分の体験談のみなもんで確証が無くて申し訳ないのだが、Ecripseからひとつのパッケージをコンパイルして、それをコマンドラインからJARに固めて外部から呼び出しを行った場合での不具合が余りにも酷いので挙げさせてもらった。
（前の2つに較べたら大分弱い）

まずプログラムを行う際に自分が作成する成果物を、package というC++のnamespaceのような名前空間のようなものに定義する事ができる（他社、他のプロジェクトと衝突しないために”すべき”である）。
これは別にC++でもnamespaceで（更に#include を組み合わせる事により更に強力に）実現できるもの。
そしてこのpackageはソースファイルの先頭部分（＜クラス等定義の前）に”テキストにて”記述する。
Ecripseのような統合環境を使用していても、ソース内に使用するpackageは記載する事ができるし、この記述が自動で削除されたり上書きされるような事も無い。

が、実際に使ってみた場合に（＜どこかやり方が間違ってる可能性はあるんだが）以下のような不具合が発生する。

パッケージ名は実際にはJARに格納される際のパス（ディレクトリ名）と完全に一致している必要があるらしく、このパッケージ名とファイルが存在するパスの不一致により、実行時に”呼び出しているクラス名が存在しない”という例外を吐かれる。
更にこの例外を吐かれている要因を突き止める事がほぼ不可能（指定されているパスに”ファイルが見つからない”というエラーしか出さない）。

言い替えてみると、packageはnamespaceのふりをしている癖に、実際には#includeのパスを兼ねていて勝手にそれ（ファイルの存在位置）を強制する、という感じだろうか。

まあ特殊な環境でやっているものだから必ずこういうものだ、っていうのかどうかは不明でアレなんだけれど。

namespaceの名前自体を気に入らないから変えてみますた、って思ってやってみたら#includeの書き換えを全部行うどころか、ファイルが置いてある場所のディレクトリ名変更や移動までやる必要がある、っていう代物の状態だった。＜当然SVNのフォルダとか名前変更とかまでやらされる羽目になるオチまで着いてくる
（これを行う為にどうもEcripseには”リファクタリング：名前の変更”という機能がある様子）

統合環境（IDE）前提の言語なのは理解できるが、この中途半端な対応状態は相当のレベルで酷い。
あとから作成されている言語仕様や環境なのに

「何故この機能がこうなっているのか」を説明できない要素がある

っていうのは正直結構怪しいと思わされる。
少なくともこのエラーメッセージから見た目上の仕様から何から全て、この理由でこうなっていますという明確な裏づけが一切感じられない。
敢えて挙げるとしたら、ZIPアーカイバに全てを委ね過ぎてしまってるからじゃね？ っていう邪推はしてしまうけどね。＜そんなのは当然裏づけとして認められません

　
まあ正直「言語のダメな所」の1点として挙げるには若干弱い要素だったりはするんだけれどね。
実質的ネタ切れですハイ。
最初にヒデヲに言われてじゃあ「ダメな３大ポイント」にしよう、それぐらいネタあるだろう、ってやってみたんだけれど思ったよりも最初の２つが大きな問題過ぎて、残りは結構瑣末なものかなって感じだった。
デバッガーの話とかしようかなと思ったけれど、実際に使ってみてはいないので書くまでに調べる内容が多くなり過ぎるのでコイツもネタとしては没。

てな感じでオマケじゃないけれど、３大ポイントに付け加えた若干言いがかり的な部分をもう１回追加でやります。＜３．１、３．２でやろうと思ったけれどやはり長くなったもので別項目扱いにする。

という訳でまだ二週はこのネタは継続で続けられそうですハイ。

| 2012年07月31日(火)

2012年07月24日

Java言語のダメな所３大ポイント （２）

※ あくまでも個人的な感想です。

筆者は本格的なJavaのコーディングは行っておりませんが、C/C++に関しては２０年弱ほど職業プログラマーとしてのコーディング歴があり（同じコードを使いまわして20年じゃないよ）、大規模レベルのAndoroidアプリの開発において初めてJava開発環境に関わりました。

２．Java はアプリケーションがヒープ管理する事ができない言語である

Javaでは言語レベルで”ガベージコレクション（通称ガベコレ）”がサポートされており、また使用が強制されるという仕様となっている。

C/C++、アセンブラ等においてはメモリ管理はアプリケーションに任されており、この事によって（主にゲーム機や組み込み系ハードにおける）決して十分では無いメモリーを最大限に生かす事が可能となっている。
が、その反面ポインタを直でアプリが管理する事が必須であるため、削除済みのオブジェクトを正規のオブジェクトとして扱うという検出が困難なバグや、オブジェクトの削除忘れ（メモリリーク）といったお約束のバグが常につきまとう。

ガベコレの詳細な説明は今回はしませんが、アプリケーションが直接メモリーを管理する事ができないという事が言語レベルで前提なので（JNIのレベルまで作りこめば別だが）、上記のようなメモリ関連のバグ自体を発生させる事がJavaではそもそもできないようになっている。

”基本的には”いいことずくめです。
また正直この部分に関しては５～10年後には恐らく意識をすることなくほぼ全員のプログラマーがプログラミングをしている事でしょう（現行の据え置きゲーム機の開発は除いて）。
恐らくGoogle及びAndroidがJavaを選択した理由はここら辺を見越したものではあるかと推測する。

が、以下の状況が満たされない（これには非常に残念ながらAndroid開発環境も含まれる）環境においては尋常ではないレベルで問題が発生する。

　OSがストレージへのメモリスワップ及び仮想メモリ等を使用して、実質的にほぼ無限と言ってよいサイズのメモリを提供してくれる場合（あえて数値を出すとすれば一般的なアプリなら数GB程度、HD画質のムービーオーサリングレベルならば数100G～TBレベルは必要か）。

Windowsのような据え置きPC環境においては、現状これはほぼ達成されてると言って良いかという認識。
だが、Android端末のようなスマホに搭載されている物理メモリーは多い機種で１GB、少ない機種に至っては284MB程度なんていうお粗末なものがゴロゴロしていたりする。
また、OSレベルでメモリスワップが提供されてしかるべきであるはずが、Androidに関して言えば何故か恐ろしい事に提供されていません。

で、こういう環境だとむしろガベコレが必須であるという環境がむしろとんでもなく困った事になる訳で。
オブジェクトはいくらでもnewして作れば良い、使用しなくなったオブジェクトに関しては適切なタイミングで削除は行われる。
だがしか～し！ メモリが既に足りていない状態で更にオブジェクトをnewしようとするとどうなるのか？ ＞これは例外を吐かれて”以上”となる。
ｃatch すればいいってのはナシで。＜このケースにおいては完全にムダなので

メモリが足りない時に仮にオブジェクトを全て管理できていたとしても、削除できないオブジェクトがあればそもそも確保可能なメモリを増やすことができない。
更に言えばJavaではnewと対になるべき構文のdeleteが存在しない言語である。
つまり実質的にメモリ不足例外を吐かれた時点でアプリが仮に落ちなかったとしても対応する術は無く、強制終了と同じ事となる。 参考

更に恐ろしい事にオブジェクト（のサイズ）やメモリーの管理がそもそもできない為、実質的に落ちる時点までメモリーが足りてるのか足りていないのを判断する術も無いのだ。

正直、

　こんな環境でアプリケーションを作れ、と？

と言いたくなるような状況だったりする。
まあそうは言っても世の中に大量にAndroidアプリは溢れている訳ではあるんですがね。
そもそもメモリーを食わないようなアプリを作れって事なんだろうけれど。

　
と、若干Android向けの話になってしまって恐縮ですが、ま、LinuxだろうとWindowsだろうと、据え置きPCでの動作やサーバーPC上で動くようなプログラムに関しては全く問題が無いと言って良い問題だとは思います。（１．と同じ）
そして端末の搭載メモリーがこの先GB、数十GBが当然という状況になるにつれて（そして毎年スマホの平均スペックが上がり続けている限り）、この問題も徐々に解決（？）されていく事はほぼ間違い無いです。

以下独り言。
前に読んだ中島聡さんのエントリーLife is beautiful: Oracleの「Android訴訟」についてひと言で「Java選択した時点で筋が悪い」ってな表現があったんでこんな感じの事かな？ と思って改めてエントリーを読んでみたんだけれど、遥かにそれ以前の話だた～よ。

| コメント (4) | 2012年07月24日(火)

2012年07月17日

Java言語のダメな所３大ポイント （１）

※ あくまでも個人的な感想です。

筆者は本格的なJavaのコーディングは行っておりませんが、C/C++に関しては２０年弱ほど職業プログラマーとしてのコーディング歴があり（同じコードを使いまわして20年じゃないよ）、大規模レベルのAndoroidアプリの開発において初めてJava開発環境に関わりました。
　
１．JavaVM上で動かすコードがコンパイルされたアセンブラコードではなく、ソースコードそのままである点

そもそもの設計段階に文句をつけている訳だが、サーバー上で完結するようなシステム／アプリならばいざ知らず、クライアントへ実行ファイルを配布して実行するタイプだと本当に致命的。
アプリを有償ダウンロードして終わりというレベルの商売ならば、かろうじてアリだろう。

基本的に配布されるアプリ（パッケージ）にソースコードがほぼそのままの状態で含まれているのがJavaアプリケーション。
jar という形式で配布や実行ファイルが作成されるのだが、この中身は単なるZIPファイル。
更にその中には、クラス名から構成から変数名まで、ソースコードがほぼそのまま残されている。＜テキスト形式ではさすがに無いが

これらを解析するツールがそもそも存在してる為、配布されているJavaアプリは全て容易に解析が可能となっている。

この容易さという部分が重要。

C/C++及びアセンブラで書かれたプロジェクトは最終的に実行ファイルの段階で、プラットフォームのアセンブラへと変換される。
が、これを逆アセンブル、逆コンパイルというリバースエンジニアリング技術により解析を行い、クラック行為等を行う事は実質上可能である。
が、この行為が可能な能力というものは非常に限られた高度な能力で、全プログラマーを能力順に並べた場合、これができる人間は確実に上位5%以内に入る。＜これはかなり多めに見積もった数字である

これをJavaに関していうと、最低限の言語仕様が理解できるレベルであればツール等が充実している事、プラットフォーム毎のバイナリコードで無いのでJavaのコードさえ読めれば解析が可能である事により、リバースエンジニアリングに必要な技術力（要は参入障壁）が劇的に低いと言える。

あえてC/C++の 5% に対して数値化するのであれば、20～30％という数を挙げさせて頂く。

この構造上の欠陥点に早くから気づいていた人たちは多く、Javaに関しては”難読化”（Obfascate）というキーワードが示す対策が取られてはいる。
Javaの標準開発環境であるEcripseにおいてはこの難読化ツールが標準で組み込まれており、Andoroidアプリで言えばアプリ定義用のXMLファイルにて定義を行えば自動的に難読化は行われる。

のだが、この難読化というのは単にクラス名、変数名、関数名を分かりづらい記号に置換するだけのものであり、ソースがそのまま内包されている事にはなんら変わりはない。
リバースエンジニアリングへの障壁が若干上がっているだけで、本質的に本気でやる気になった場合はC/C++のそれよりも遥かに容易に行う事が可能である。

　
と非常に前置きが長くなって申し訳無いのだが、要するにアプリケーション開発者がアプリ配布後のクラック等の行為に対して、必要以上に対策を行う必要があるという見えないコストを孕んでいるのだ。

しかもこのコスト、プロジェクト終盤どころかリリース後に発覚したりするので始末に負えない。

サービスやアプリがようやく完成しました！ → リリース → 大人気 → クラック等される →
対策が必要 → アプリやサービスの再設計レベルの修正が必要

という一連の流れはちょっと大げさに書いたりはしたけれども、まあ全く考えられない話では無いかな、と。

そもそもJava的なVM上でソースがそのまま動くという思想はウィルス的なものを排除もしくは早期に発見する目的で考案された仕様と推察するのだが、それはそっくりそのままリリース＝ソース公開というアプリ、サービスを販売する視点からすると問題がありすぎる、ちょっと踏み込んで表現すると危険な思想の部類に入るものかなあ、と。

　
※ 冒頭にも少し書いたけれど、サーバー上で大メモリ＆高速CPUハードウェア構成の前提で更に外に公開される事が無いアプリ／サービスを作成する分に関しては、この件は全く問題になりません。

　
以下独り言。
最初の1項目でもうこんな超大作になってしまった…。ちゃんと構成を考えて書ければいいのだがそれだと今の倍は時間かかるし。
これをどうやって今北産業にまとめるというのか。
（基本的に超複雑な事を説明しているので、簡単に説明しようとする方が間違いではあるんだが）

| 2012年07月17日(火)

2012年07月10日

Programming の話

あらあらまあまあ。
ヒデヲ氏からリクエストがあったもんだから、じゃー自己流解釈でJavaとObjective-Cの話でもやりますか、っていう気になっていざエントリー書こうと思ったら、

未だにプログラミングについてのカテゴリーが作られて無かったッス。

ま、仕事の愚痴と近況報告以外ではプログラミングは仕事の話になってしまうから、と後は色々と書き始めると長くなるからっていう理由が大きかったかな。
でもまあ最近は大体自分の状況がどれぐらいか多少は分かってきたので、自分が知ってること理解している事を少しずつでも他人へ伝えるのも必要な事なのかなって思い始めたり。

なもんで気が向いたら＆リクエストがあり次第、プログラミングについてのエントリを書いていこうと思ったりしてます。

　
ヒデヲ氏とのTwitterでのやり取りはこんな感じ。

@papicon_mk3 そこらへんももっとkwsk！ こないだのもエントリで読みたいっす（・∀・）

— ホリヒデヲさん (@hidewo_h) 6月 29, 2012

　
一応今月は火曜日にプログラミングの話でエントリーを書こうと思います。
なもんで本題は来週！

| 2012年07月10日(火)