inforno

__有能なプログラマの特徴を思いつくまま列挙してみる __

から。なんか流行ってるらしいし、就職という人生の転機も近いのでやってみます。文系のエセプログラマなんで、そんなにくわしくは書けないけど、まぁなんとかかろうじてできてるかな、って場合はどうやってるか、見たいなのも書いて見ます。

×要求自体をシンプル化する

たぶん、できてない。やろうとするんだけど、できてない気がする。

○メタレベルプログラミング

C#もLisp系も普段使わないので、普段使っている言語で考える。たぶん、これはやっているはず。というか前職(ドリコム)の頃には行き過ぎて分かりづらいコードを量産していた気がする。反省。

で、なんでこういうことをし始めたかというと・・・たぶんシンプルにしたかったんだと思う。そして、コードが動くことだけじゃなく、コードの中身にこだわっていたからだと思う。

○DSLをオンデマンドで自作する

どうだろう。Rubyを書いていたときにはそれっぽいことはしていた。Pythonでもするかなあ・・・。

これも、便利にしたい、とかいうよりは俺の場合はコードの中身の問題だったなあ。だってDSLだったり、DSLぽかったらカッコイイじゃないですか。これって結構大事なモチベーションだったりする。

△デザインパターン

あやしい。一応デザパタ入門、J2EEパターンあたりの本は持っていて、きちんと読んだ。たぶん、組み立て方のパターンは頭にはいっているはず。ただ名前とかは忘れた。ある意味無意識に使えるようになってきている・・・といいなあ。

またまたこれもコードの中身の問題。やっぱりデザパタつかってるとカッコイイ、なんて思っていた時代があったわけです。ぶっちゃけPHP書いてた時代です。Mojaviあたりが出てきた時代からPHPは書いておりまして。その頃のPHPのフレームワークなんてのはいかにJAVAのフレームワークをﾊﾟｸるか、みたいな感じで。だからJ2EEパターンあたりまで押さえていたわけです。

△英語

話せない。書くのは遅い。けどPCでなら読むのは結構読めると思う。英語に対する恐怖心とかはない。

このページ下部に翻訳中のドキュメントが放置してあるのは秘密（笑
というわけで英語。書くのはダメだけど、読める。昔どっかで読んだんだけど、その時もすごい人が「翻訳ソフト買ったり使ったりするくらいなら快適に辞書をひける環境を作れ」っていってた。

というわけでやっぱり辞書が快適にひける環境が大事ではないか、と。俺の場合「英辞郎」＋「DokoPop!」です。これでどこでもctrl+右クリックで一瞬で引けます。翻訳サイトをブックマークレットから利用したりするより絶対こっちのほうがいいです。

また「Babylon」も同じようにどこでも辞書が引けるソフトです。こいつがすごいのはFlash上の文字(例えば歌詞閲覧サイトのFlashとか)でもその場でctrl+右クリックで辞書が引けることです。

というわけでこの辞書環境のおかげで安心して読めます。

△処理系やライブラリの動作原理の精密な理解

精密な理解・・・はしていないし、自分で実装するなんて考えてもみない。ただし、処理系のソースは読む。前にもPythonでgetattrと__getattribute__の違いとかを読んでいた。

これはやっぱり、自分で調べたほうがはやいだろ、っていう気持ちからでしょうか。LLの場合、時として自分の予想と反することがおこるわけで、そういう場合ですね。

○ライブラリに関する知識

たぶん、大丈夫なはず。たぶん・・・

やっぱこれは情報収集をいかにしてるか、ってことだと思う。一応、そこそこRSSは購読してる。動くものを作るときが目的の時（それ自体の学習が目的じゃない場合)はとりあえずライブラリ化されていないか探す。

△基本的なコンピュータサイエンスの知識

宣言的記述と手続き的記述の違いを理解する。 : これは大丈夫。

トランザクション、ロールバック、正規化、外部結合、などなど、RDBの基本 : たぶん大丈夫。昔出会い系のシステムを作っていたときに、ログ集計とかそんなもろもろの部分をやっていていやになるほどやった。出会い系だから、入金とかもからんでいて、結構しんどかった。出会い系でも会員が10万とかになると結構しんどいものがあったし、勉強になったなあ、と思う。
その点、最近はO/Rマッパつかったりで生のSQLなんて全然書かないし、衰えている気がする。その出会い系のところでは10行以上のSQLをガリガリ書いて集計とかをしていた。

言語理論 : コンパイラ―原理・技法・ツール、計算論 計算可能性とラムダ計算あたりは読んだ。でもこれは違うな。というわけでこれはダメそうだ。

プロダクションシステム、前向き推論、後ろ向き推論、フレーム、などの人工知能系の概念 : さわりぐらいはやっている。ので簡単なのなら分かる。俺のような文系のプログラマがここらへんのさわりをやるんだったら、Schemeによる記号処理入門がオススメ。
Schemeがわかる人ならすぐ読みきれる。薄いし。練習問題もあるし、コード例もあってわかりやすい。Schemeの解説も随時されているけど、やっぱりSchemeがわからない人にはちょっとオススメしかねるなあ。

ここはいかに本を読んでるかが勝負だと思った。

×セキュリティ技術の基本

これは、だめだ。今勉強したい分野のひとつ。

△プロトコルの詳細

これってどう仕組みか、長所は？短所は？とかっていうことだろうか？それだったらだいたい分かる。HTTP、FTPくらいかなあ、telnetで話せるのは。他はググりながら恐る恐るしゃべるんだろう（笑

これっていつ覚えたんだっけ。たぶん、昔本を読んだんだと思う。HTTPとかFTPはぶっちゃけ使うものってこと。使わないプロトコルなんて、絶対覚えられないとおもう。

○異質なプログラミングパラダイムを理解しておく

大丈夫なのではなかろうか。普段使ってるのはaboutに書いてあるとおりC、JAVA、Python、Ruby、Javascript、C、Delphiといったそこらへんの言語だけど、ふつけるも読んだし、Schemeはわりと好き。gaucheがWindowsで完璧に動くようになれば、メインにするかもしれない。最近はOcamlにすげえ興味がある。

これはただの興味（笑　なにも実用的な意味はなかったりする。単純に、新しい言語を覚えるのは楽しい。それだけ。

×汎用のキーカスタマイズツール

昔は窓使いの憂鬱で、Windowsのキーバインドをviにしていたけど、やめた。俺以外の人が触ると、「このWindows みたいなの 使いにくい」って言われるわ、学校行ったら全然思うようにPCが使えないわで散々だった。つまり俺ポータビリティが落ちすぎる。

Linuxならvim+zsh+screenでzshのキーバーインドもviにして、reverse-i-searchとか自分が使う機能を適当なキーにバインドして使っている。正直、これでなれると生bashでもつらくなるので、そうならないようにWindowsにbashを入れて両方使えるようにしている。

○開発環境の具体的な機能の理解と使いこなし、開発環境のマクロ言語、開発環境の正規表現

大丈夫。俺にとってはvimを使いこなしてるか、と等価だったりする（笑

もうvimを使い始めて3年くらいになるわけで、よく考えたら甘酸っぱい10代からvimを使っているわけで。それでも全然使いこなせている気がしない。

こういうvimを使いこなそうってのは、「気持ちよさ」からきている気がする。ずっと昔は俺も秀丸で書いていたりしたわけだけど、なんていうか、圧倒的に気持ちいい。キーボードを打つのが。

例えば、頭のなかでコードが出来上がっていて、あとはそれをゴリゴリ実装するだけだとする。他のエディタだとその過程がなんかもどかしい。んだけどvimだとその過程が楽しかったりするんだなあ、これが。

○スクリプト言語

自信をもって○を付けられるのがこれくらいな罠。

Rubyでご飯を食べていたこともあれば、Pythonでエミュレータを書いたりする変な人はそうそういないような気がする。RubyとPythonは票がわれそうだし。実際両方やっている身としてはどっちかやってればいいとつくづく思う。

せっかくなのでRubyとPythonについて、文系の素人プログラマが思っていることを書いてみる。どっちも完璧に好みにあうわけでは当然ない。文句を言いたい点は実はPythonの方が多い。でもRubyには決定的にどうもなあ、な部分があるのでPythonに傾いている。

それはRubyの特徴でもあるobj.methodというやつ。カッコつけなくてもメソッドが実行できるっていう。これがどうも俺には扱いにくくてならない。関数をオブジェクトとして扱いづらいし、メソッド呼んでることを忘れて、めちゃくちゃ重いコードを書いてしまう。

Pythonなら標準では（）つけないと呼び出せないし、propertyを使えばカッコを付けずに呼び出すこともできる（ココらへん参照)。これがいいんだなあ。たしかPascalあたりから引っ張ってきたものだと思うんだけど。

そのほか、Rubyにはあんまり文句はない。Pythonと違って命名規約がわりと浸透していて統一感があるし、(pythonではgethoge,get_hoge,getHogeが混在している。）、メタプログラミングも統一感があるし(pythonはmetaclassとかデスクリプタとかややこしい)、ブロックは便利だし、call/ccあるし（笑

○プログラミングに飽きて、プログラマを辞めたくなったときの準備をしておく

大丈夫だ。そもそもPCにはDTMから入ったのでそこに戻るのだろう。

○：9(開発環境についての部分はまとめたので3つで数えた)、△:5、×:3。○とその他半々といったところ。文系のくせに、文系っぽいところがとことんダメな気がするのは気のせいか。

○の理由はだいたい「コードの美しさ」、「興味」の2点だったなあ。これは今後も維持していこう。逆にいえば×の部分は興味がもてないのが原因なんだろう。どうやってモチベーションをあげるか、が大事と見た。

こうやって改めて客観的に自分を見てみるのもよいものだなあ。

考えてみるとやっぱりコンピュータの基本があやしいなあ。こういう人はこれからもっと増えてくるはず。一般的なプログラマなら意図的にやろうと思わないと、やらないで過ぎてしまう。

「ゲーム機の変わりに○○を買ってもらって・・」とか「大学で初めて○○に触って・・・」みたいな世代とは根本的に違うんだろうな。俺の年齢ってちょうどPCがPCになった最初の世代なんだよなあ。だって、小学校の時にWindows95ありましたもん。だいたいのソフトはもう、一通りそろってましたもん。中学生から携帯もってましたもん。

というわけで、なんにもしらなくてもPC使えて、プログラムだって組める。そういう世代だからこそ、基礎をもっと勉強しないとなあ。

パッド入力部分を書いたので、動くゲームも出てきました。といってもまだほとんどのゲームが動かないんですけど。画面はブルジョアソフトウェア研究所さんのTkShoot 1.00が動作している様子です。

さて、ここまできたので基本的にはこの企画も終了かなー、という感じがします。目的はPythonのパフォーマンスについて知ることだったので。

作成の過程でかなりPythonのパフォーマンス関連について勉強ができてよかったと思います。

速度

サウンドは作っていないので、それを除くと1frameだいたい0.4秒弱くらいで動きます(もちろんpsycoを導入して)。変にベタ書きしたりはしていません。わりとメソッドはちゃんと分割しています。ただ、LDA $ssss(absolute addressingのLDA)だけ、実行回数が多いので完全にベタ書きしました。

んで感じたのは

• プリプロセッサでマクロを使えばそこそこ実用的な速度になりえるのではないか
• bytecodehacksでインライン化すれば結構いけるんじゃないか。ただし、bytecodehacksがオブジェクトのメソッドには対応していないので、classを使わずに書くことになる。
• 部分的にCで拡張モジュールを書けば、わりといけそう

ってことでしょうか。

まぁただ、JAVAとかC系全く分かりません＞＜っていう人以外は、素直にC系かJAVAで書いたほうがいいと思います。

高速化のためにオブジェクトのプロパティをローカルにだしたり

するので、無駄に行数も増えますし、ぶっちゃけ読みにくいです。それでも普段使い慣れてるLLで書けるってのは大きな利点だとは思います。

10年くらいして、マシンがもっと速くなることに期待しましょう、ということで（笑

その他雑感

現時点でも単純なゲームくらいなら、そこそこ動くのでコンピューターの仕組みの基礎を学ぶには、もしかしたらLLでエミュレータってのはいいかも。当然ですけど、デバッグの段階ではアセンブリ言語を書くことになりますし、そのアセンブリ言語の内容も完全に自分で処理するわけですから、単に本で読むよりは格段CPUやメモリについて詳しくなれると思います。ただ、CPUの仕組みを勉強しながら書くのはきついものがあるかもしれませんが・・・

他の利点としては「俺エミュレータ書いたんだぜ」と自慢できる（笑）、自分の書いたエミュレータでゲームが動くと結構感動できる、というくらいでしょうか。

というわけで、とりあえず動くようになりました。今のところソースをアップする気はないです。（してもほとんどのゲームは動かないし意味無い）

確実にいないと思いますが、もし、「俺もLLでエミュレータ書いてみるんだぜ！だからお前のしょーもないソースも参考にしてやるから見せるんだぜ！ついでにエミュってどうやって作るのか教えるんだぜ！」というような方や「おめーソースがないのに信用できるか！」という方がおられましたら、この記事のコメント欄やはてブなんかのコメントに、「うｐ」とか書いてください。適当にソースまとめてうｐして、それをネタに簡単なエミュの書き方でも記事にします（笑

まぁとにかく書いてて楽しかったです。チャレンジ精神旺盛な方、そして時間があまっている方は是非LLでエミュにチャレンジしてみてください。

#追記　
アップしました。コチラの記事へドウゾ。

PythonによるNESエミュレータ開発5

時間があればちょっとずつ続けてます。

とりあえず画面がでるようにはなりました。速度は全然追いつかないですけど。

CPU

基本的には変化なし。細かいバグが多くて大変・・・・

わずかでも速くしたいところなので、あまり構造を壊さず速度を上げられないかな、と思ってPrefetch cueを実装してみました。Prefetch cueはCPUの非常に基本的な最適化で、基本的故に単純、実装しても負荷になることはないだろう、ってことですな。

エミュレーターでは（とくにPythonでは)ハードウェアでいうメモリが遅いうんぬんとは別の理由で、メモリアクセスはかなり重い処理になります。

さらにページングされている場合、C言語ならポインタでいけるんですけど、Pythonではそうはいかないので、いちいち長ったらしく書くか、ページング用にメソッドを書いてそれをはさむことになります。

そう、関数の呼び出しが非常に多い部分なのです。実際、profileモジュールでデータを取ってみてもメモリ読み込み書き込みが結構なウェイトをしめてました。

そこでPrefetch用のクラスを作って、別スレッドで現在のPC+いくらかをとるようにしてみました。これは現在のオペコードを実行している間に実行されます。これで次のオペコードを実行する前にオペコードとオペランドを取得でき、メモリ読み込み関数を呼ぶ回数が減ります。ただし、本物のPrefetch cueと同じでジャンプ命令が多いとあんまり効果がありません。

Prefetch-cueを入れてみると、まぁコードの内容によりますが、psycoを入れて1frame 0.075くらいまではいきました。PPUをいれると全然なんですけど（笑

PPU

なんとか表示できるまでにきました。正直つらいです（笑　特にスクロールに関してはloopyの文書の文書が重要、ということをしらなかったのではじめはサッパリでした。

描画部分はpygameです。pygameで描画する場合、更新したRectだけupdateするってのが常套手段なわけですが、エミュの場合はどうも・・・。というわけで今は毎回全体を描画しています。これも結構重い処理になるなあ。

ほとんどスクロールしないゲームの場合、もしかしたら32x32くらいに区切ってスプライトが動いたところだけ更新するようにしたら、結構軽いのかもなあ。

というわけで、PPUをつめてパッド入力あたりを書けばマッパー0のゲームなら動き出しそうな感じがします。ちなみにマッパーは全然です。とりあえずPythonで書いてみることが目的なので実際に使うことは想定して無いですし。

卒論の試問会も終わり、家探しの旅も終わり、つかの間の落ち着きが戻ってきました。なんか資格とかをとらないといけないらしいので、それをちょっとずつ勉強しつつ、こっちもちょっとずつ進めていきたいなーと思ってます。