« August 2007 | Main | October 2007 »

September 30, 2007

某所の

鰻屋さんで晩飯。ビール飲みながら優雅に出待ち、と。

| | Comments (0) | TrackBack (0)

外出

所用で外出。荷物が重いわ。色々持ちすぎかな。

| | Comments (0) | TrackBack (0)

September 27, 2007

やっと

完了。相変わらずエクスプレス予約にはイライラさせられる。まぁいいや。帰ろう。

| | Comments (0) | TrackBack (0)

強行軍

今日は朝から本社で会議した後、新幹線に乗って東京で会議を二発。意外とひとつ目の会議が早く終わったので助かった。

さぁ、頑張って行こう。

| | Comments (0) | TrackBack (0)

September 26, 2007

定時退社日の

定時後に会議を設定される。何もなければ問題もないんだけど、今日は生家に直帰して飯を食う予定だったからたまらない。予定はキャンセル、晩飯をスパゲッティ屋で食うはめに。

とかなんとかいいながら食い過ぎるぐらい食ったんだけどさ。

| | Comments (0) | TrackBack (0)

昨日は

21時前から0時過ぎまで飲む。大したことはないはずなんだけど、今朝は起きられず。朝飯よりも追加の睡眠を選択する体たらく。疲れてるのか?

| | Comments (0) | TrackBack (0)

September 24, 2007

狙い通りに

業務が推移。しめしめ。

| | Comments (0) | TrackBack (0)

今日は

世間様は休日ですか。駅に来るまで忘れてたよ。

| | Comments (0) | TrackBack (0)

September 23, 2007

こちらも一回まとめておきますか

マシン語を知らない子ども達から始まった議論も、ここを含めて各所を巻き込み、最終的にはスラッシュドットまでエラいことになっているようですが、まとめ。

議論に参加したのは、15年ぐらいこの商売やってきて日々感じてきた、そして近年とみにそう感じる強さと頻度があがってきた思いと、マシン語を知らない子ども達の主張がある程度合致したから。

で、俺涙目(笑)あたりから、それなりに知識があるのに、そんなにマシン語必須を否定する人達は、じゃ何を推奨するんだろうか、ということに興味が移った。そういう違う立場にいる人間が推奨するものたちを並べて比較できれば、初学者はうれしいかも知れんし、あわよくば新しい世界がひろがるんじゃないか、といった感じ。

で、そういう訳なので

ぼちぼち収束?

自分にとって何が有用だったか、ってそりゃ普通に専門教育受けているから答えは「大学の情報系学科に入学してください」としかいえないなぁ。具体的な書籍名は忘れた。

これは非常に残念。今後またなにかひどい目にあってそれを切りぬけたときに、心の底から"あぁ、あれやっといてよかったな"と思ったらまた教えてほしい。

読んでる方に誤解してほしくないのは、書籍による知識の習得を否定している訳ではないこと。書籍を通じて知識を得ようとしない技術屋っていうのはダメを通り越してありえないレベルだから、書籍による知識の習得自体は重要。そう、当り前すぎてあえていう必要がないぐらい重要。

それはさておき、

後半は話題を移したつもりへのshiro氏のコメント

限られた時間の中で初学者に学んでもらうとすれば、モデルとしてのプロセッサ、OS、言語処理系、DB、計算理論といった横に広がる階層をひととおり、そして現場で要求される部分一箇所について、モデルから現実へのマッピングを深く、というT字形の学習計画が良いのではないかという気がします。一度そういう足場を作れば、それで不十分な時にモデルの階層をどこまで下がって(あるいは上がって)さらに学べば良いかが自分でわかるでしょうし。モデル階層の下の方はプロセッサ(ノイマンアーキテクチャ)か、組み合わせ/状態回路くらいまでわかっていて欲しいですが、現実へのマッピングとして386アセンブリをすらすら読める必要は(そういう現場でない限りは)無いと思います。

このT字型の学習計画という考え方はいいと思う。個々人の志向により、Tの縦棒を降ろす位置と深さが異なる、と。ここであえて"現場"といわなかったのは、"初学者"の話であんまり特定のドメインを想定しすぎると、"つぶしが効かない"ことになっちゃわないかなぁという一抹の不安があるから。

どこかでshiro氏も書いておられたけど、足場を築くにふさわしいポイントとそうでないポイントというのがあると思うんだよね。希望に目を輝かせた少年/少女が、プログラマを志したときにどういうルートで攻略するのがよいのか、例えば自分の息子がプログラマになりたいと言ったら、どんなアドバイスをするか、みたいなね。まぁ思い留まらせるというのはひとまず置いといて。

で、その足場を築くにふさわしいうちのひとつのポイントがマシン語の習得だと私は考えている、ということになりますかね。

えーっと、それから、

「当たりの付け方」と「何を為さざるべきか」

というか突き詰めていけばですよ。

○○をやらせるべきか否かを考えている人間ではなく、○○をやりたいぜ、やってやるぜと考えている人間の方にイニシアチブはあるんですよ。「やらせる」とか言ってる人はどうあがいたって他人の頑張りの「結果」しか受け取ることができないんだから、「やらせる」なんて言ってる連中が最も心を砕かなきゃいけないことは

楽しんでもらう、のめり込んでもらうために我々は何をしないべきか?

じゃないのか、と思うわけです。老害って言われるのはお互いに不幸だもの。

んー、これはちょっと微妙に違って、"やらせる"という感覚はないんですわ。あくまでやる気のある人が読んで、自分の行く先を考えるのに役に立ててくれればいいか、と。だから、やみくもに何かを否定してばっかりより、"こっちで商売するにはこれがあるとないとでは大違いだ。だから必須。"っていうのを並べてくことができたらいいかなとは思ったんだけど。

引用前後しますが

「当たりの付け方」と「何を為さざるべきか」

ここまで書いて、「問題」に対処するのに必要な力ってのは、下のレイヤーを知っているかどうかよりも、どんな武器を持っているかってことのような気がしてきました。ソフト、言語においてはバイナリアンとしての力は足腰として重要だと思いますが、我々は普段足腰で仕事してるわけではない。ただしんどい状況になってくると足腰を含めた全身の体力を求められることもある。

そういうあるドメインでの"足腰"の効果的なトレーニング方法、それも理論だけじゃなくて実践が一覧できる状況ってあるといいんじゃないかと今回の議論を通じて思ったという次第。まぁこの発想自体が大きなお世話で老害なのかも知れんけど。

と、こんな感じですかね。ここまで読んでいただくと分かるかもしれないけど、この議論、ただのパロディや否定だけじゃなくて後に続く人が出てほしいと本気で思ってます。次に出てくる人が必須と定義するものがなんなのか非常に楽しみにしてます。だから、みんな批判を恐れずに自分の思いを吐露してください。

| | Comments (0) | TrackBack (0)

September 20, 2007

いや、だからさ

体系的に勉強するべし

本読めば?パタヘネでもヘネパタでも。読んだこと無いけど。というか一実装系をいじったことがあるく<らいで理解したつもりになられるほうが困ると思うんだけどいかがか。

本を読んで解決する程度の問題なんであれば、あなたがたのの後輩が読むべき本は何よ。それが聞きたいのさ。読んだこともない本でなく、本当に自分にとってためになった本を示してもいいんじゃないの?

体系的に勉強するべし

逆にこれらの知識って実装を知らないと駄目かってそんなことはないと思うんだよね。それこそ、モデルに関する理解のほうが重要なんじゃないかと。

だからね、そのモデルに対する理解を得るために効果的ななにかを例示してもいいんじゃない?せいぜい"そんなのはオールドタイプの幻想だ"って批判を受ける程度のリスクしかない訳だしさ。

体系的に勉強するべし

時間は有限なんだから、スキルだってある程度のところで切らないと切りがないよ。

その有限の時間を売って生業を建てるのが仕事ってもんだど思うんだけどね。"きりがない"って判断基準はソフト屋には分かってもらえても、いわゆる"スーツ"の連中には理解してもらえないよ。

| | Comments (0) | TrackBack (1)

September 19, 2007

件の

議論に参入してから、ここにおいでくださるお客様がうなぎ登りだ。ご興味お持ちいただいて、それは喜ばしいことなんだけど、なんとなく心情的にぬるい日記が書きにくかったり(笑)。いや、いいんだけどね。

| | Comments (0) | TrackBack (0)

September 18, 2007

後半は話題を移したつもり

だった。わかりにくくてすまん。

俺涙目(笑)

でもアーキテクチャ固有の脂っこい問題だけ誰かに丸投げして押しつけておいて、"私はプロのソフト屋でござい"ってのはちょっと虫がよすぎるように思う。

ここで問題にしたかったのは、

アトミック #2

じゃあ、トラブルがあったときに全部自己解決しないといけないかといえばそうでもなくて、それはそういうレイヤを得意としている人に丸投げする、という選択肢もあり得る。

この部分。マシン語知識云々とは少し離れる。

低レイヤ以外の技術ってそんなに軽いのか

なんでアセンブリレベルデバッグができない人間は交換可能な部品になるのか理解できない。

そうじゃない。"アセンブリデバッグができない"でなくて、"丸投げで済ませる"人間。

この商売を15年ほどやってきて実感するのは、技術屋がもっとも成長するのは問題点にぶちあたっ(てそれを解決し)たときだということ。当然納期の問題もあるのでなんでもかんでも深く潜ってきゃいいってもんでもないけど、それはあくまで政治的なファクタによるやむを得ない措置であって、基本的には発生した問題点を根本から解決することでそのソフトウェアと担当者は確実にレベルアップする。

いうなれば問題点が発生したタイミングというのは、その問題点をつぶし、以降自らの紡ぐコードに同様の問題点を発生させないよううにできる大きなチャンスな訳だ。

"丸投げ"という行為は、その折角のチャンスを自ら半ば捨て去ることに等しい。"僕はもうこの方向に成長する気はありません"という宣言にも思える。成長のチャンスを自ら放棄するものにプロとして生き残る余地は残されてない。結果交換可能な存在に甘んずるしかない、というロジック。

低レイヤ以外の技術ってそんなに軽いのか

もちろん、仕事ならそれじゃすまない場合だってあるだろうけど、その場合にアセンブリで追いかけるのととりあえずワークアラウンドを入れてしまうというのはちょっと考慮の余地があるんでないかな。もしくはバージョンを変えるだけで動くならそれでもいいかもしれない。

ワークアラウンド大いに結構。でもそれが本当にワークアラウンド足り得ること、望まぬ副作用を生じさせないことはどうやって検証する?アセンブリで追っかけるのと同等の環境の実装に対する深い理解が必須じゃないの?なんでバージョンを変えるとうまく動くのさ?ただ"バージョンを変えるとうまく動くんだから前のバージョン固有の問題だと思います"なんて報告、誰が納得してくれんの?(まぁそういう桃源郷が存在するのを知らんから、いまこの身を苦海に沈めねばならんだけの話なのかも知れんが。)

ワークアラウンドもバージョン変更も確かに"アリ"。でもそれを"アリ"にするのはその問題に対する深い理解。誰かに丸投げしてるだけじゃその理解が得られないでしょ。

で、だ。

以前同期と飲んでいて、"ソフト屋にもっとも大事なことは何か"という話題になったことがある。そのとき"あきらめないこと"と答えたんだけど、人をプロ足らしめるのはそういう基礎体力の部分だと思うんだよね。サーバの構築方法、RDBMSのボトルネック、たしかに重要な問題だけど、そういった問題は各業務の遂行上必須の知識、言い替えればドメイン固有の知識であって、この基礎体力の土台の上に築かれるものだと思う。

んで、前のエントリでも書いたけど、その基礎体力、言い替えるとリテラシを養うためにはマシン語の習得は効果的だ、というのがこちらの主張な訳だけど、ここで改めてマシン語の習得に否定的な方々にお伺いしたい。そういう基礎体力を養う、つぶしの効くソフト屋になるための方法で、マシン語の習得よりも効果的な方法ってなんだろう?皮肉とか変なレトリックじゃなくて、アイデアがあれば本当に聞きたい。

| | Comments (7) | TrackBack (1)

September 17, 2007

子供を

連れて自宅から一時間ぐらいの公園へ。天気がいいのはいいけど暑いな。ビールが進む。

# もちろん運転は嫁さんの人がします。

| | Comments (0) | TrackBack (0)

September 16, 2007

俺涙目(笑)

いやいや、議論の土俵を完全に見誤っていたようで。

アトミック #2

えー、違う違う。末尾呼び出し最適化は関数呼び出しをループじゃなくて、ジャンプに変換する。

gccはもうちょっとがんばる、というのは置いといて、"たいしたことない"の意図は了解。

アトミック #2

ちーがーうー。そんな適当な説明していると「ロックの取得は高コストだから」とかいって、新人がひどいコード書いちゃいますよ?

失礼しました。いろんな意味で完全に読み違ってました。

もともとのこちらの主張を別のいいかたをすると、ソフトウェア開発におけるリテラシとは何ぞやという話において、それは個々のデバイスの振舞に対する理解であり、それを習得する現状最適のツールはマシン語への理解である、というものであるつもりなんだけど、リテラシの位置づけについてはそれほど異なっていないように思われます、というかやっと気がつきました。

# Java VMとかを広い意味でのデバイスとしてとらえれば、だけど。

そうなると争点はツールとしてのマシン語の有効性に関するとらえ方、ということになると思うんだけど、じゃマシン語の理解以外に現状最適のツールってなんだろう?個々の処理系に縛られない汎用性の高いものって何があるのかな?

でもって、最後にひとついわせてほしい。

アトミック #2

機械語レベルの知識が必要な現場があるのもわかるし、知識があると自己解決できる場面があるのもわかる。じゃあ、トラブルがあったときに全部自己解決しないといけないかといえばそうでもなくて、それはそういうレイヤを得意としている人に丸投げする、という選択肢もあり得る。例えば、LL でプログラムを書いていて特定のアークテクチャで問題がよくわからない挙動を示したら、普通にバグレポートを投げりゃいいじゃん。と、まあそういうスタンスな訳ですよ。

えーっと、誰かのおもりをするためだけに飼われている社畜はいません(少なくともうちの会社には)。ソフト屋が誰かに助けてもらうことを前提としてソフトウェア関連スキルのポートフォリオを組むのはやめた方がいい。最初はいい。分からないこともあるだろう。誰かと協力しなきゃ解決できない問題もあると思う。でもアーキテクチャ固有の脂っこい問題だけ誰かに丸投げして押しつけておいて、"私はプロのソフト屋でござい"ってのはちょっと虫がよすぎるように思う。

ただでさえそういうレイヤを得意とする種族はもう既に減少しているんですわ。そういう現状に危機感を抱いたその種族が起こしたのがこの議論な訳で。職場にそういう希少種族が棲息していない可能性もあるよ、場所によっては。

それにね、普通の人、というのは現状何かの言語でプログラムを組んでいる人のことだけど、そういう人であればまぁ1週間もあれば、大概の別言後でプログラムを書きはじめることができると思う。3ヶ月もやってれば、新たに習得した言語で前にやってた言語でできたレベルのこと+αのことはできるようになるんじゃないかな。つまり"LL でプログラムを書いていて特定のアークテクチャで問題がよくわからない挙動を示したら、普通にバグレポートを投げ"るだけの人はいつでも交換可能な部品にすぎない。それはプロなんかじゃないよね。お金もらってりゃある意味プロとは呼んでもらえるかもしれないけど。

さらに普通の業務ではベンダの問題でもベンダにレポート投げただけじゃ終わらなくて、バグじゃないって言い張るベンダに証拠を突き付けて対応を迫ったり、場合によってはある程度具体的な修正方法をソースがないモジュールに対しても例示しなきゃいけなかったりする。で、ベンダがちゃんと直した納品物を評価して初めて担当者の業務も終了と。途中何度も"俺のコードじゃねぇよ"とか、"今さらそんなこというなら最初から内製にさせてくれりゃよかったじゃねぇか"とか、主に社内に向かって切れたくなることもあるけど、でもそれができて一人前なんだそうですわ、プロとして。

こういうのがソフトウェアのプロだって考えたら、"誰かにお任せ"なスタンスはまずいと思いません?

| | Comments (2) | TrackBack (1)

もう少しだけ

粘着してみる(笑)。

# キモかったら言ってください。やめます。

アトミック

末尾再帰最適化なんてそれこそたいしたことないと思うけど、この例がたいしたこと無いのはその通りで、実際問題として大変なのはもとのコードと機械語の命令が1対1対応するわけではないことだったりする。で、その場合に生成されるコードを想像してデバッグしないといけない状態ってなんなんでしょ。排他制御はまさにそういう例だとは思うけど、こういうバッドノウハウ的なコード生成は関係なくて、要するにどういう処理がアトミックにできるのかという話だよね、多分。ということで、「生成されるコードを想像できないといけない」というのは言いすぎだと思うのだ。

ちょっと引用長すぎたかな?

プロシージャコールがループに変わってしまう末尾最適化を"たいしたことない"と言い切ってしまう強さには敬服します。多分コンパイラによる最適化の話をしたときに、書いたコードと吐き出されるコードのセマンティックな距離が最大になる例のひとつだと個人的には思うけどね。

アトミック云々に限定しすぎるのもどうかとは思うけど、例えば"どういう処理がアトミックにできるか"を認識するためには自分が書いたコードがアトミックにできる処理なのかそうでないのかの区別ができなきゃいけない。そして、区別するためには"バッドノウハウ的なコード"になるか、クリティカルなコードを含むか大体想像できてないといけない。だからこそ"コンパイラの出力を想像できるぐらいにはなっとかないとプロとしてはまずいと思う。"という発言をしたという訳。

で、前のエントリで"瑣末な部分に属する"としたのは、決して"関係ない"ということが言いたいわけじゃなくて、"(一見)難解そうに見えるけども一度CPUによる割算というものがわかれば自分の中でパターン化しておける"、つまり上のいい方にそろえると、"書いたコードと吐き出されるコードのセマンティックな距離はそんなにはなれていない"という意味と"一般的にレジスタ値は各コンテキストで閉じているので、レジスタオペレーションだけしか出てこないこれらの例はコンテキストローカルなものだと一見して認識できる"という意味を含んでいる。いや、要はこういう例を見て本気で"マシン語って恐いなぁ"とか思っちゃう人がいるとアレなので、"全然難しくないよ"ということが言いたかっただけなんですけどね。

アトミック

たとえば、この例でいうと「共有変数へのアクセスはアトミックに行うか、排他制御する必要がある」ということと、「インクリメントは読み出し、加算、書き込みを伴う処理でアトミックではない」ということを理解させればいいんじゃないかなぁ。いや、もちろん機械語レベルの知識があるならそれで説明するのが手っ取り早いだろうけど。

それって結局

The_Value++ ;

っていうコードは
mov The_Value, %eax
inc %eax
mov %eax, The_Value

という風にコンパイルされて、コンパイル後のコードそれぞれの行間でディスパッチ(割り込み)が起きうるよ、という話を日本語に翻訳しただけの話だよね。んで、これが本質である以上、いわゆるマシン語の知識は必須だよね、プロなら。

遠回りしても時間がかかっても自分なりの理解が得られればいいというのは、まぁそりゃそうなんだけど、かりにもプロであって、本質にかかわる理解を得る近道が存在することを認識したなら、その道をとれるように自分を鍛え上げておくのが当り前だと思うな。プロの端くれとして自戒の意味も込めて。

アトミック

あと、shiro さんのコメントを読んで気づいたんだけど、もしかして一部の人は無意識的に CISC プロセッサを前提にしているんじゃないだろうか。いや、もしかしてバイナリアンな人たちは RISC でもすいすいと読むのかな。

"一部の人"がどうだかは分からないけど、組込みやってるとARMやSHにはよくお目にかかる、というか最近はそんなのばっかりなので、基本的にはRISCの人です。まぁRISCでもCISCでもそんな変わんないですよ。遅延分岐とか癖もあったりするけど、それさえ押さえときゃ総命令数は少ない訳で。

アトミック

まぁ、なんというかモデルとしてコンピュータでの命令実行がどうなっているのか、という話は知っておいてしかるべきだとは思うんだけど、実装の泥臭いところまで知っているべきというのは、なんか違うと思うんだよね。

モデルとして一般論を"知っている"だけじゃなくて、"深く理解"して設計の基礎に置けるようになっておかないとプロとしてはいまひとつ使えませんぜ、という話だと思うんですよ。そのためには泥くさい所も含めてなんかひとつぐらいは具体的なターゲットを設定して経験積むのが近道ですよ、と。

さすがに今回のプロジェクトは初めてPowerPC使うからまずはアセンブラから、とかはやらなくてもいいと思うけどさ。ARMでもx86でも自分の持ってる具体的な理解をベースに、必要に応じてデータシートのコード表引っ張りだしてコンパイラの出力と見比べることで、自分の想像を補正しつつより確実なコーディングを行うことはまちがいなく可能だから、そのためにもなんかひとつはアセンブラレベルの経験(デバグでもプログラミングでもいいけど)をしておこうね、というのがもともとの主張なんではないかなぁ。

| | Comments (0) | TrackBack (1)

September 15, 2007

トラバをいただいたので

顔を真っ赤にして反論(笑)。

[Programming]コンパイラの出力

ふむふむ。なるほど。さて以下のコードはそれぞれ、ある関数を逆アセンブリしたものですが、どういう処理でしょう。

なんか割算。といういい方はもちろん確認してから言ってるのでフェアじゃないんだけど。

# そう、いうほどバイナリアンじゃないんだ実は。

基本形はこれ

mov    %edi,%eax
mov (なんか定数),%edx
imul %edx

(なんか定数)の所には何が入るかというと、例えばx/3が計算したい場合には2をレジスタビット数だけ乗じた数を3で割った数が入る。この場合は32bitマシンのようなので、
2^32/3 = 1431655765.3

が入る。16進整数に近似すると上の例の0x55555556になるわな。これ要は
a / b = (a * (2^32 / b)) / 2^32

と変換をして、最後の" / 2^32"の部分がbitシフトで表せる上に、imulの答えは上位32bitがedxに入るため、imul直後のedxの値が割算の答えになっているというアルゴリズムなわけだ。

あとは

sar    $0x1f,%edi
sub %edi,%edx

みたいなのが両方に共通してあるけどこれは割算とどう関係するのかとか、下の例で割算の答えをさらにシフトしてるのはなんでかみたいなことは興味がおありであれば調べていただくとして、今回マシン語を知らない子ども達から始まった議論は、上で解説したような3行のパターン(の複合系だったりシフトとの組合せだったりするけど)が割算やモジュロを書いたときに"コンパイラががんばれば"吐き出されることが想像できた方がいい、もうちょっと突き詰めてどうしてコンパイラががんばったときにidivが出てこないのか理解しておいた方がいいという話なんだけどおわかりだろうか?

まぁ今回みたいにレジスタオペレーション"だけ"のコードは単一コンテキスト内で完結しているという意味で瑣末な部分に属するんだけどね。コンテキスト外の、例えばメモリオペレーション回りが本当は重要なんですわ。

で、

[Programming]コンパイラの出力

いやぁ、すごい。つうか、C コンパイラの最適化をなめてないかい?

このふたつの例はそんなにとっぴなものじゃない。知ってりゃわかる話だし、初心者が始めてぶちあたったとしても、Cのコードと見比べながらちゃんと調べればわかる。まぁ除算器使わないという決断をコンパイラが下すという部分は最適化の機構が働いているんだろうけど、"なめてんのか?"といわれるほど恐いもんじゃない。末尾最適化なんかのごついのはまぁ置いとくとして、メモリアクセスの減少とかパイプライン動作を考慮したアセンブリ命令の順序の置き換えなんかのほうがデバグ時に障害となる可能性が大きいです。

いや、やってみりゃそんなに大変なもんじゃないって。だからやっといた方がいいんだよ。

最後に、

[Programming]コンパイラの出力

アトミックな処理というのをわからないと排他制御の必要がわからないというのはそのとおりだと思うけど、それってアセンブリのレベルまで落とさないと説明できないのかな。

新人君とかに"なんでたった1行のインクリメント文をセマフォでガードしなきゃいけないんですか?"と聞かれたときは、アセンブリレベルの話をするのが一番的確で一番簡単だと思うんだけど、他になんかいい説明方法ありますかね?もしアイデアあるようであれば真剣に知りたいです。

個人的には、コンテキストが(乱暴な言い方をすると)レジスタ群とメモリ上の値のセットである限り、コンテキストスイッチのトリガに割り込みが含まれる限り、アセンブリレベルの話はどうしても出てきちゃうと思うんだけどね。

| | Comments (0) | TrackBack (1)

September 14, 2007

お守りをしている

サーバが不調だったので、色々した上でrebootしたところ、パッケージ管理システムまで立ち上がらなくなって焦る。

ライブラリ参照関係が変わって、ライブラリが見えなくなったのが原因らしい。

気付くのに一時間、復旧に二時間といったところ。疲れた。

| | Comments (0) | TrackBack (0)

つーかね

なんか盛り上がりそうなのは知ってたんだけど、二日ほど飲んだくれてたので出遅れた。いや、なにってマシン語を知らない子ども達の話。

なんかいろいろ否定的意見もあるようですが、基本的にマルチスレッドとかマルチタスク扱うときにアセンブラの知識ない人はつかえないっすよ。タイミングバグとかのデバグ一人でできんてことでしょ?排他制御の必要性が具体性を伴って実感できないってことだと思うんですが。

たとえば

static int a ;

thread1 () {



a++ ;



}

thread2 () {



a-- ;



}


こんなコードのそれぞれのインクリメント処理とデクリメント処理をセマフォ(or mutex)で保護してやらなきゃいけない理由が直感的にわかんないでしょ?Cしか知らないと。

# まぁこういうコードの作り自体がいいか悪いかは置いとくとしてね。

だからマシン語はただの教養じゃないと思う。文字どおり必須知識。DOSの時代とかコマンドラインでちまちま一本道のプログラム作ってるうちはいいけど、複数プロセスやスレッドが強調して動くシステムが当り前になった昨今その重要度は増してると思うけどな。

そういう意味ではマルチタスク環境において

マシン語を知らない子ども達

マシン語ができない人が書いたプログラムは、一見うまく動いているように見えたとしても、それは奇跡のようなバランス、自転車で言えば補助輪がついた状態で奇跡的に動いているに過ぎず、なにか未知の問題が発生したときに素早くコンピュータ内部でおきていることに直感を巡らせ、適切な処置・対応をするためにはマシン語の理解は不可欠と言って良いでしょう。

これは真実。いまも日々痛みを伴って実感する死よりもリアルな真実。

まぁ実際に日常的に書く必要はないけど、コンパイラの出力を想像できるぐらいにはなっとかないとプロとしてはまずいと思う。コンパイラの出力を想像するという意味では、gdbとかでアセンブラレベルデバグを嫌っちゅーほどして慣れるのが一番近道かな。そのうちアセンブラコードの並びを見てCソースコードのどの行かわかるようになる。

んでもうちの職場でも平気で"アセンブラはわかりません"なんて言い切って終わらしちゃう人の割合は増えてるんだよね。たくさん修羅場くぐってもらわなきゃいけないんだろうなぁ。

マシン語読みの言語知らず

無理矢理飲ませる事はない。彼らの喉が渇くのを待ちさえすれば。

いつになったら彼らの喉は渇くんでしょうか?

ただ、386は初学者にはきついかも知んないとおもう。SHなんかどうだろう?パイプラインとかフェッチとかCPUのさらに中を意識できるし。

| | Comments (0) | TrackBack (1)

September 13, 2007

久々に

わくわくする仕事の話。うまくいくといいなぁ。

| | Comments (0) | TrackBack (0)

September 12, 2007

昨日は

近所に越してきた後輩と職場の近くで飲んだ。帰る瞬間にやつが近所に住んでるのを忘れ、電車があるのに一人でタクシーで帰宅。一緒に帰ればよかった。今後は気をつけよう。

| | Comments (0) | TrackBack (0)

September 10, 2007

魔法の折り畳み傘

折り畳み傘をかえてから、この傘を持っていれば雨に降られないという感じの日々が続いている。今日も降り出したけど、まだ傘はさしていない。続くか、ジンクス。

| | Comments (0) | TrackBack (0)

うちの

会社はフレックス制(製造部門を除く)なんだけど、いつだか、勤務時間をごまかしたお馬鹿さんがいたせいで、機械的に分きざみで勤務時間を管理するようになった。

それはめんどくさくていい迷惑なんだけど、コアタイムに間に合いさえすればきっちり時間がカウントされるので、"九時までに行かなきゃ"とか、そういう感覚も薄れていたり。

会社にとっては損失だよなぁ、やっぱり。

| | Comments (0) | TrackBack (0)

September 09, 2007

ファイルダイアログ

C#でちょっとしたプログラムを作成中。

まずはGUIから作るべと思って、SaveFileDialogをつかうと、


  • マイコンピュータを選択すると何も表示されなくなる

  • フィルタを変更すると何も表示されなくなる


という問題に遭遇。半日きっかりはまる。

googleさんと格闘して、なんとかまったく同じ問題ではまっていた人を発見。原因はMain関数の前のおまじない、いままであってもなくても動くから無視していた"[STAThread]"を書いていなかったことであることが判明。

やっと[STAThread]の必要性がひとつわかった。これからはちゃんと書こう。

| | Comments (0) | TrackBack (0)

September 07, 2007

今日は

この前キャンセルになった打合せ。こんな日にかぎってすごくお久しぶりな方から飲み会のお誘い。

行きたいなぁ。

| | Comments (0) | TrackBack (0)

台風一過

というには少し雲が多いような気もするけど、まぁ晴天。

ところで、子供の頃"たいふういっか"を台風ファミリー(しかも任侠系)のことだと思っていたのは自分だけだろうか。関係ないけど。

| | Comments (0) | TrackBack (0)

September 06, 2007

台風

接近中。かなりそれたけど、それでも風が強くなってきた。早く帰るに限るな。

| | Comments (0) | TrackBack (0)

少しだけ

今朝は気になることが二つほど。最近、身近で気味の悪い話を聞いたところなので、気にしすぎだとは思うけど、仮に何かあるのであれば、家族を守るために戦わなきゃいけない。

願わくば私に戦い抜き、家族を守り抜く勇気と力、そして知恵をお与え下さい。

| | Comments (0) | TrackBack (0)

September 05, 2007

マテ!

ソレハホントウニナオッタノカ?

| | Comments (0) | TrackBack (0)

ちょっとした

計算ミスで今月は現金がヤバい。そう、苦しいじゃなくてヤバいと表現しなきゃいけないレベル。

今月はアフィリエイトの初収入があるはずなんだけど、それもすぐに使わなきゃいかんっぽい。

この状況に刺激されて、もう一件アフィリエイトプログラムに参加する準備中。キャッシュフローの入口は多い方がいいからね。

| | Comments (0) | TrackBack (0)

September 04, 2007

なんとなく

GTDもどきをやってみる。リストが消化されていくのはたしかに心地いい気はするな。リストがちょっと長めなのがアレだが。

| | Comments (0) | TrackBack (0)

嫁さんの人を

叱る。なんで衛生面であんなにルーズになれるのかいまだに理解に苦しむ。

まだまだ旅は続くのか。

| | Comments (0) | TrackBack (0)

September 03, 2007

たまった

仕事を一気に片付ける。あーすっきりした。

| | Comments (0) | TrackBack (0)

新たに

知人から依頼を受けて、ツールを構想中。Perl使ってよければ一瞬なんだけど、Windowsアプリといわれると少し時間がかかる。素人さんはコマンドライン使えないからなぁ。

| | Comments (0) | TrackBack (0)

September 02, 2007

練習

マネージャやってる方のバンドの練習に出撃。早すぎて誰もいない。楽器ないし暇だ。

| | Comments (0) | TrackBack (0)

« August 2007 | Main | October 2007 »