ひしだまの変更履歴

ひしだまHPの更新履歴。
主にTRPGリプレイの元ネタ集、プログラミング技術メモと自作ソフト、好きなゲームや音楽です。

M.T.GODDESSとMSXエミュレーター改造の話

2011-10-29 23:53:51 | プログラミング

昔作ったものを思い出していたら懐かしくなったので、ちょっとフォローしておくw

M.T.GODDESSはMSX-FANに載っていたゲームで、戦闘シーンがハイドライドやボコスカウォーズのように体当たりで戦うアクションになっている。敵味方はお互い複数居るが、操作できるのは自分のキャラ1人で、味方もコンピューターが動かす。
このうち味方2人分をプレイヤーがジョイスティックで操作できるように改造した。(要するに3人で協力して戦えるようにした)

戦闘シーンはマシン語で書かれている(BASICのDATA文で数値だけ書かれていたはず)ので、手で逆アセンブルして、ジョイスティックで操作できるように書き換え、ハンドアセンブルし直した。
こういった改造をしたのに、マシン語部分のバイト数が改造前と一切変わらなかった!
我ながら感動して、今でも覚えているのだw


MSXエミュレーターは今ではMSX MAGAZINE永久保存版が定番だと思うが、当時はfMSXをいじっていた。
当時のマシンスペックのこともあって実行速度が遅かったので、なんとかしたいと思った。

採ろうとしたアプローチは、対象プログラムをホストマシン上のプログラムに変換してコンパイルして実行するというもの。
プログラムはZ80のマシン語なので、逆アセンブルしてC言語に変換し、コンパイルしてfMSXとリンクするという発想。(fMSX自体がC言語で書かれているので)

しかしマシン語(Z80)というものはプログラム部とデータ部がきっちり分かれている訳ではないので、どこがプログラムとして実行されるかを全て追うのは困難。
また、マシン語ではプログラムの自己書き換えが出来るので、コンパイルするならその部分を判別してエミュレートする必要がある。
ROMのプログラムならそういうことは無さそうに思えるが、メガロムの場合はページ毎にアクセスできる場所を切り替える仕組みになっており、その実現方法はROMによってまちまち。あるROMでは特定アドレスに書き込むとページが切り替わるようになっている(ROMはread onlyなのに、そこへ書き込む!)が、汎用的な決まりなど無い。

大体のところは、メモリーにアクセスする時に直接読み書きするのでなくfMSXのアクセスルーチンを使うようにすれば解決すると思うが、それだとスピード面で全然改善にならない(苦笑)

という訳で、立ち消えになった。


MSXエミュレーターのことはさて置き、MSXでプログラムを勉強するというのは、環境面でも非常に良かったと思う。

フロッピーディスクも普及してなかった頃なので、プログラムは雑誌の紙面に載っているものを全て手打ち(笑)
何かエラーが出たら、基本的には自分が何か打ち間違えているということなので、デバッグの勉強になる。
ソースも全部見られるし全部入力するので、何をやっているのか・どういう書き方をするのか・何が定石なのかという勉強になるし、気になる部分の改造も出来る。

当然の様に、雑誌には初心者プログラマーへの解説もあった。
インターネットなんか無い時代であり、雑誌自体も種類が限られているので、MSXでプログラムを作る人はほぼ全員同じ知識を共有できていたと思う。
(たぶんMSXでプログラムを作っていた人なら、ビット演算のXORなんて常識だと思うw)

今の時代、「インターネットで情報は何でも手に入る」とか云うけれど、個別の事はともかく、全員が共有できる知識なんてものはウェブ上には無いんじゃないか。

もうちょっと言うと、自分はMSX-BASIC→Z80アセンブラ→C言語→VC++JavaScalaと勉強してきた。
技術要素的には、BASICで基礎を覚え、アセンブラでメモリーアクセスを覚え、C言語で構造体を覚え(ポインターはアセンブラをやってれば難しくない)、VC++でクラスとイベントドリブンを覚え、Javaでオブジェクト指向を覚え、Scalaで関数型の考え方を勉強中という感じになる。
つまり新しい言語を勉強すると言っても、今まで覚えてきたことに新しい要素を追加するだけという感じ。

ところがこれを今の人がJavaやScalaから入るとなると、覚えることが多くて、そりゃ大変だろうなぁと思う。
(MSX-BASICなら、パソコンの電源を入れたらBASICの画面になるので、PRINT "hello"って書けばもうプログラミング完了だよ。インストールもコンパイルもツールの起動も何も要らない。初心者にとってどれほど楽かw)
まぁ逆に今の時代は入門書もいっぱい出ているから、なんとかなるのかもしれないけど。(どの入門書が良いのか探すのも一苦労かもしれないけど^^;)

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

プログラミングのどの分野に興味があるか?

2011-10-29 17:18:29 | プログラミング

ある人に「プログラミングのどの分野に興味があるか?」と聞かれ、とっさに「プログラミング全般」と答えたけれども、あまりにも漠然としているorz (頭が悪いので臨機応変なやりとりって苦手でして…)
ので、もうちょっと詳しく考えてみた。


そもそも自分は物を作るのが好き。

小学生時代はずっとレゴブロックで遊んでいたし、プラモデルやタミヤの模型に手を出していた時期もある。
そうこうしている内にファミコンが出てゲームにハマったが、ナッツ&ミルクロードランナーの自作ステージを作るのも好きだった。(ファミコンじゃないけど、アクションパズルΦ自作ステージを一番多く作ったのも自分だなw)

そして友人がパソコンを買って 見せてもらったのをきっかけにプログラミングを知り、それ以来ずっとプログラムを作ってきた。


プログラムを作るのが楽しいというのは、
(1)出来たプログラムを実行して使うのが楽しい、あるいは便利(例えばゲームとか業務システムとか)
(2)プログラムを作ること自体が楽しい(パズルを解くのと似ている)
という2つの面があるのではないかと思う。

(1)の「プログラムの目的」については、当初はゲームを作ることだった。
そしてプログラムを作っている内に「いかに綺麗に書くか」といったプログラムの作り方そのもの(つまり上記の(2))にも興味が出てきた。


仕事のプログラムの場合は、当然(1)「プログラムの目的」が重視される。「動けばいい」と言う人は、(1)しか考えていないのだろう。
実際には仕事のプログラムこそ品質(バグの少なさやメンテナンスの容易さ(後から他の人が見ても分かるようにする))、つまり(2)「プログラムの作り」が重要なんだけど。

自分の場合は、自分が関わるプロジェクト(仕事)のプログラムの品質は良くしたいと思っている。
仕事では自分一人でプログラムを全部作るなんて事は無くてチームメンバーが居るから、全員のプログラムの品質が良くないといけない。
だから(少なくとも自分程度の技術力でも分かるような)変なプログラムを作らせない為にどうすればいいかといった事を考えることもある。
(自分がウェブページで色々技術的な事を書いているのは、主要な目的は自分の記憶力が悪いのでメモしておくことだけど、メンバーに「これを見れ」と伝える目的もある。いちいち説明するの面倒だからね(爆))
スケジュール管理だのリスク管理だのも、良い仕事の為には必要だろうとは思う。

もっと言うと、SIの仕事はお客さんの問題を解決することであって、既存パッケージを組み合わせるとかコンピューターシステムを作らないとかって事もアリ。
お客さんと直接話して問題を解決する(いわゆる上流工程)のが面白いという人も居るだろう。それは分かる。人の役に立つのは嬉しいからね^^
あるいはプロジェクトをとりまとめて成功させるのが好きだという人も居るだろう。

でも僕はやっぱりプログラムを作らない仕事には意欲が湧かないなぁ…。少なくとも自分が目指したい場所ではない。
時間が経てば興味が移り変わることも自然だと思うけれど、自分は変わらなかった。


ところで、プログラミングの「分野」ってどういう分け方があるだろう?

組み込み系・業務(サービス)系・ゲーム系とか、バッチ系・ウェブ系・リアルタイム系とか、あとは理論派・実践派とか?

そういう意味だと、自分が主にやってきた分野というのは当然あるとして、他の分野にも興味自体はある。だから「興味があるのは全般」という考えになっちゃうのかな。
でも理論とか組み込みとかになると、たぶん付いていけないけど(苦笑)


では自分が一番何をしてきたか(興味がある事をやってきたはず)と考えると、プログラムの改造・改良かもしれない。

例えばM.T.GODDESSの改造は神懸かっていたし(公開してないので誰も知らないが(爆))、大学の卒業研究ではC言語の改良版を作りたかったし(さすがに無謀だったので、作ったのはLispをC言語に変換するツール)、MSXエミュレーターの拡張をしようとしていた時期もあったな(汗)

例えばHadoopに興味を持ったのは自分のプロジェクト(お客さん)の抱えている問題が「夜間バッチが遅い」なのでそれを解決できるかもと思ったからだが、Hadoopそのもののプログラミングは面倒なのでPigHiveAsakusaFWといったアプリが作られていて、そちらにもすごく興味を引かれる(笑)
(今作っているshrも、使っていると色々機能追加したくなってきて面白いw)

つまりは、「面白いソフトがある」→「使っていると改造したくなる」というのが自分の行動原理なのかも。
改めて自分が今までに作ったツールを見てみると、既存アプリを便利に使う為のものが多い。(しかもエンドユーザーをターゲットにしたものがほとんど無い^^;)


もうひとつ興味があることとして思い浮かぶのが、「良いプログラムを作りたい」ということ。

「良いプログラムって何?」って言うと、開発効率が良い(短時間で作れた)・ソースの見た目が分かりやすい(美しい)・実行効率が良い・バグが無い・使う人から喜ばれるもの、かな。
ここまで揃ったら、もはや「芸術品」だね(笑)
(たとえ綺麗に作れても、使われないシステムだったら作った意味が無いので、芸術品とは思えない)
プログラマーなら誰でも目指している物だろうから、特に自分だけが興味を持っている分野というわけでもないと思うけど。

自分が新しいプログラミング言語を勉強したいと思うのも「良いプログラム」の一環かな?
新しい考え方っていうのも興味深いし。


ここまで考えてきて気付いたけど、やっぱり自分は「何を作るか(新しいサービスを作ること)」は眼中に無い(爆)
というか、「発想する力が無いので、出来ない」っていうのが正しいのだが。

世間では“誰も作っていないサービスを発明する”ことが評価される(それは当然だと思う)けど、みんながみんなそれを出来なきゃいけないって訳でもないし、実際できないし。
発想する人と作る人と改造する人、適材適所で分担してやればいいじゃん!

(とは思うが、他人が作ったものを改造するなんて事は誰でも出来るので、自分の得意分野とか言うのは憚られる…)

あるいは、SIの仕事ならお客さんの役に立つシステムを作るのが当然だが、その為の業務分析だのなんだの…には興味は無いんだよなー。
分析された結果を、コンピューターシステム上に上手く・素早く実現(作成)させることには興味がある。


うーん。

一言で答えられるような上手い答えは出せなかったけど、色々考えを整理するきっかけになった素晴らしい質問でした。ありがとうございました。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

staticプログラムの怖ろしいところ

2011-10-23 04:11:44 | PG(Java)

フィールド・メソッドが全てstaticなJavaプログラムを目にする機会があって、「これが噂のstaticおじさんプログラムか!」と感激したw まさか単なるネタだと思っていたものを実際にこの目で見ることが出来るとは…。
あまりに感激して嬉しくなって気分が良くなったので、オブジェクト指向バリバリのプログラムに書き換えてみた(爆)

使い捨ての、一度実行したら結果を目で確認して終わり、というプログラムならstaticだけで作ることもあるけど、本格的なプログラムがそれじゃ問題大きすぎるよなぁ。


という流れで、もしstaticプログラムが納品物だったら…と想像してみた。

特にこのstaticプログラムは、C言語の人がJava“の文法だけ”を覚えた感じがありあり。
つまりはJavaの初心者が作ったものとしか思えない。
ということは、Javaの作法や定石・はまり所が分かっていない可能性が大。つまり潜在バグのリスクが大きい。(例えば、ServletStruts1のActionクラス)のプログラムを書かせたら、マルチスレッドのことを意識せずフィールドを使いそう)

自分が検収担当者やソースレビューの担当者だったら、こんなプログラムは一目で却下するなぁ。
あるいはプロジェクトリーダーとしてメンバーを選ぶときにこんなプログラムを出されたら、さすがに断るなぁ。


こんなソースを見せられたら、まず考えるのは「何のジョークだろう?」。
でもさすがに納品物ならジョークなプログラムを出すような会社は無いだろう^^;

次に考えられるのは、新人教育の一環として、新人に作らせたのか?
でもそれならソースレビューで直させているはず。
それがそのまま出てきたのならば、ソースレビューをしていないか、レビューアーのレベルも低いということ。

新人じゃないとすれば、さらに根が深い。
特にアーキテクト(最初に雛形を作る人)がこんなだったとしたら、その会社全体のレベルが疑われる。

現実にありそうなのは、(忙しくて)誰もチェックしていないということ。つまり、品質の低いプログラムがあっても野放し。


結論:いずれにしても、staticプログラムが出てくる時点で、アウト! 信用を失う。
怖いですね(汗)

…いや待てよ? 検収側がstaticおじさんなら、逆にオブジェクト指向なプログラムを出すと却下されるのか? それはそれで怖いなw

コメント (1)
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ScalaのREPL上でHadoopのSequenceFileを操作する

2011-10-11 01:08:23 | PG(Scala)

ScalaのREPL上でHadoopのHDFSを操作するツールで、SequenceFileの表示部分を強化した。

Path(ファイル)に対してshowを実行すると、SequenceFileかどうかを自動判別し、SequenceFileであればWritableを文字列化して表示する。
WritableにtoStringが実装されていないときはゲッターメソッドを呼び出してそれらの値を表示する。
AsakusaFWのWritableはtoStringが実装されているのでそのまま表示する)

自分で言うのもナンだけど、超便利!(笑)

また、100件ずつ表示するmoreコマンドを用意。
catは今まで全件表示にしていたけれど、headと同じに変更。件数が多いファイルを不用意に指定すると悲惨なことになるという経験をしたので(爆)
tailはスキップバイト数(行数ではない)を指定できるようにしたので、大きなファイルの末尾でも高速化した。1行当たりのバイト数というのは計算では出せないので、スキップバイト数はユーザーが指定する必要があるけれど…。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

ノーチラスオープニングイベント+Asakusa on AWS+WindGate+YAESS

2011-10-04 23:19:03 | PG(分散処理)

今日はノーチラス・テクノロジーズさんのオープニングイベント& Asakusa-Hadoop on AWS 事例解説+Inside WindGateの解説+「YAESS」に行ってきました。昨日登記も完了したそうで、発進おめでとうございます。
Togetter: #nt_opening

調子に乗ってオープニングイベントのピザとかサンドイッチとかたくさん頂いてお腹が苦しいので(爆)、記録を簡単にメモ。


まずはokachimachiorzさんの挨拶からスタート。

ノーチラス・テクノロジーズさんの方向として、HadoopAsakusa(OSS)のエンタープライズサポートと、会計/EDI/原価計算などのソリューションパッケージの提供。品質重視。
新しい技術を積極的に使っていくが、古くても新しくても必要なものを使う。
そしてカスタマー(お客さん)ファーストで、技術をお客さんに届ける(使ってもらわないと意味が無い)。

なるほど、確かに。


次は須賀さんのAsakusa on AWS。アンゼルセンサービス(パン屋)さんの生産管理システムへAsakusaを導入した事例。

原価計算のシステムで、データ量は1GB程度でビッグデータではないが、BOM(木構造)の展開・積み上げをやっていて、現行システムで4時間。
Hadoopでの並列計算処理(ストアドプロシージャやファンクションをDSL)に置き換えて、30分になったとのこと。まだチューニングしてないので、もっと短くなるはず。
(BOMはRDBMSでは効率が悪く、BSPの方が速いらしいが、今はMapReduceでやっている)

データセンター内の既存のシステムとAmazon VPCをインターネット(VPN接続)でつなぐ構成となっている。
(※Amazon VPCは、VPN接続で自社システムの延長のように扱えるサービス)

AmazonにはEMRというHadoopを時間貸しするサービスがあるが、EMRはApacheHadoopベースであり、AsakusaはCDHベース(MultipleOutputsが追加されている)なので、EMRは使わなかった。
HDFSのファイルシステムとしてEBSを使用。バックアップはS3にとっている。
障害時は復旧優先で、HDFSはキャッシュとしてしか使っていないので、データを再ロードして処理する。障害のログはEBSに残っているので、後から調査する。
マルチAZにとる災害対策で、通信障害時は別のAZに切り替える。
まさにクラウドサービスを最大限利用した構成という感じ(笑)

ちなみに、出されたサンドイッチはアンデルセンサービスのものだそうです。ご馳走様でした。


ashigeruさんのWindGate・YAESS。酒が入ったせいか、いつもより勢いがある感じw

WindGateはポータブルなデータ転送ツール。
ThunderGateがMySQL専用で管理用カラムを追加する必要があったりするのに対し、WindGateは色々なRDBに対応し、管理カラムも使わない。Windowsでも動く。
いずれはThunderGateの機能も取り込んでThunderGateという名称に改名したいらしい(WindGateという地名は無いから(爆))。

WindGateは、MySQL・PostgreSQL・Oracle・フラットファイルといったデータストアからJDBC/TCPで読み込み、SSH経由でHDFSへ転送し、結果を逆方向へ転送する。
これらの機能を司るリソースプロバイダー(ソースドライバー・ドレインドライバー)・プロセスプロバイダー(プロセスという呼び名だが実体はThread)は、例によってプラグインで追加できる構成になっている。


もうひとつの話題がYAESS(やえす)。ポータブルなバッチ実行ツール。

現在のAsakusaでは、experimental.shというシェルが作られる。これは実験(テスト実行?)用なので、ローカルのbash/Linuxをターゲットとしていて(csh,dsh,Windowsは対象外)、並列実行はしない。
YAESSは「Yet Another Experimental Shell Script」とのことでw、Windowsからもバッチ実行できるし、外部のWindGateを起動したりすることも出来る。

ただし運用管理は別システムに任せる。カレンダーやスケジュール、条件付実行やAsakusa以外のバッチ等には対応しない。YAESSも、あくまで実験用。

YAESSの主なコンポーネントは、JobSchedulerとExecutorとScriptHandler。
ScriptHandlerがThunderGate・WindGate・Hadoopジョブ等の実際の起動を行う。
JobSchedulerは並列実行や順序の制御を行い、進行状況やエラー状況の収集・キャンセルの実行といったことはExecutorが行う。
これらもプラグインで追加できる。ScriptHandlerにデバッガの仕掛けを入れれば、デバッグに使えるかも?という意見が出ていた。

YAESSはライブラリーとして使うこともでき、バッチより細かい粒度で処理を実行できる。
TestDriverからYAESS経由でAWS上のHadoopを実行するなんて構想もあるようだ。

こりゃなかなか面白いなぁ。


他にも今後のAsakusaの改善点として、

  • 今は毎回全データを転送しているが、明らかに遅いので、更新のあったデータだけを差分転送したい(データをキャッシュする)。
    (キャッシュが壊れたら、全データを転送し直す)
  • Range Join
  • Join Expression(結合時に簡単な演算を実行する)
  • ネストしたデータモデル(データモデルの中に別のデータモデルを含める)
  • テスト周りの改善

AsakusaFWを無理矢理Windowsで動かした身としては、Windows対応といったらその辺りのシェルをCygwinを使ってなんとかする程度のイメージで考えていたけれど、YAESSはその部分ですら(他のソフトに依存せず)独立して動かす方向なわけか。
なかなか燃える!w

次々色々出てきて、マッチアップも大変だけど、やはり素晴らしい。

コメント
  • Twitterでシェアする
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする