タグ

ブックマーク / ameblo.jp/argv (10)

  • 『低レベルなプログラミング』

    「低レベルなプログラミング」と聞いて、どういうものをイメージするだろうか。プログラマとそうでない人では、答えが違ってくるのではないだろうか。 一般の人には、「誰でもできそうな簡単なプログラミング」、あるいは「質の悪いプログラミング」といった意味にとられるかもしれない。 しかし、プログラミングについての文脈で「低レベル」といわれる場合は、通常は「ハードウェアに近い」という意味である。つまり、「低レベルなプログラミング」とは、「ハードウェアが理解する言葉」に近い(たとえばアセンブラのような)言語を使ったプログラミングだとか、直接ハードウェアに命令を送って制御するようなプログラミングのことである。 このハードウェアとの「近さ」は測定できる類のものではないが、プログラマ(あるいはその周辺の業界人)は、なんとなく了解していると思う。このブログの「スキルアップのためにラップを剥がしてみる」というエント

    『低レベルなプログラミング』
    advblog
    advblog 2009/05/05
  • 『サンプルコードで語る難しさ』

    プログラミング入門者のための教材として、「カレンダーを表示するプログラムを作れ」という課題がある。この課題に対して「カレンダーなんて OS に付属しているのに、なんでそんなもの作るんですか?」という人がいる。なんという的外れな意見だろう。言うまでもなく、勉強のために作るのであって、使いたいから作るわけではない。 これは極端な例だが、この手の齟齬はよく起こる。ブログのコメントなどを読んでいると、「来の意図が伝わっていないな」と思うことは日常茶飯事である。 ★ CodeZine の「コーディングスタイルの常識をぶち壊せ」という記事のコメントや「はてブ」のコメントを読んでいて、改めて感じた。 この記事の2つ目のサンプルソースについて、「こんな用途に switch は使うべきでない」とか、「配列を使ったほうがよい」などというのは野暮である。「常識」的に考えて、この記事の著者も他の読者もそんなこと

    『サンプルコードで語る難しさ』
    advblog
    advblog 2008/11/26
  • 『できること、できないこと』

    「こういうことができるか?」といった質問を受けることがある。質問する方は簡単なのだが、答えるのは難しい。何かが「できる」ためには、いろんな要因があるからだ。 ・理論的にできる/できない ・技術的にできる/できない ・時間的にできる/できない ・費用的にできる/できない ・感情的にできる/できない など。 ソフトウェア開発者の中には、理論的・技術的な可能性にしか注目しない人がいる。例えば、「既存のシステムにこんな機能を追加したいが、可能か?」という質問があったとする。それが、システムの仕様として矛盾がなく、実装方法が頭に浮かぶようなら、「できます」と答えてしまう。 しかし、ほとんどの仕事には「いつまでに(納期)」「いくらで(予算)」など、他の条件があるはずだ。質問者と回答者の間で、そうしたことが全く話題にならなかったとしたら、誤解が生じている可能性がある。回答者は多忙で寝る時間もない状態なの

    『できること、できないこと』
    advblog
    advblog 2008/10/27
  • 『コピー指向プログラミング』

    以前、「簡単コピー・プログラミングの罠」という記事で、コピー・プログラミングの危険性について書いた。ここでいうコピー・プログラミングとは、同じアプリケーション開発の中で、似た機能を量産するためにソースコードをコピーすることである。同記事には書いていないが、他にも、「バグがコピーされてしまう」問題や、ソースコードが無駄に大きくなるなどの問題もある。 そもそも、プログラミングでは「同じことを何度も書く」ということは避けるべきだ。その理由をあらためてここに書く必要もないだろう。同じことを何度も書かずに済ませるにはどうするか、ということは、構造化プログラミングからオブジェクト指向やアスペクト指向に至るまで、プログラミング技術の発展における重要な課題のひとつだったはずだ。 アプリケーションに固有の「業務ロジック(ビジネスロジック)」なども、開発プロジェクト内で共通化を行い、重複コードをなくすのが理想

    『コピー指向プログラミング』
    advblog
    advblog 2008/09/28
    コピって!コピって!
  • 『感情の行き違い』

    技術者同士でシステムの設計方針などについて話していると、白熱してしまうことがある。お互い、声も大きくなってしまっているのだろう。傍から見ていると、喧嘩でもしているかのように見えるらしい。後から「あの人とやりあってましたね」などと言われるが、なんのことか分からない。人たちは議論を楽しんでいるくらいなのだ。 会議の議事録でも、そういう誤解が起こりやすい。終始和やかな雰囲気の会議だったはずなのに、後から議事録を読むと、言い争いをしていたかのような印象を受けることがある。会議中、相手に気を使って、わざわざ婉曲な表現で話したのに、断定的な文章になって残されてしまったりする。 会議に出席している人が読むだけなら、大きな問題はないのだが、出席していない人に誤解され、いらぬ心配をさせたりすることもある。 議事録を書く人の力量にもよるが、ビジネス文書の形で、会議の雰囲気まで伝えることは容易ではない。 もっ

    『感情の行き違い』
    advblog
    advblog 2008/04/15
  • 『ドキュメント内のリテラルにも注意』

    というように、決まった値を持つようなもの(名義尺度や順序尺度 )である。 プログラミングでこうした値を扱う場合は、数値やコード値をそのまま(リテラル )では記述せず、定数を定義して、それを使う。あるいは、「列挙型 」を扱える言語であれば、そちらを使う。 ソースコードが読みやすくなるのはもちろん、数字と「意味」の対応が変わった時に、定義だけを変えれば対応できるからだ。例えば、途中に新しいステータスが挿入されて後ろの数字がずれたとしても、既存のソースコードには影響しない(もちろん、挿入したステータスを使う必要がある箇所は別だし、新しいステータスの追加により「意味」が微妙に変わったりすると、修正が必要にはなるが)。 これはプログラマにとっては基的なテクニックであり、初心者の書いたコードでもそうなっていることがほとんどだろう。

    『ドキュメント内のリテラルにも注意』
    advblog
    advblog 2008/03/10
  • 『車輪を発明しようとする前に』

    プログラミングをしていて、何か機能が必要になったとき、「こういう機能は既に誰かが作っているのではないか」と考えてみることは重要である。そういう発想がないと「車輪の再発明」をしてしまう。何でも自作しないと気がすまない人もいるが、既に安定して動くコードやライブラリがあるのなら、それを流用した方が効率がよいことは言うまでもない(プログラミング自体の勉強が目的なら別だが)。 もちろん、事前に、既存のコードやライブラリを探す場合と自作する場合とで、どちらが時間が掛かりそうかを判断する必要がある。 そのためには、自分のプログラミング能力と、調査能力を把握しておかなければならない。調査能力については、ネットの「検索力」も重要だが、周囲の人や掲示板等への「質問力」なども影響する。 そして、もっと重要なのは、探そうとしている処理のニーズ(一般性と言ってもいい)を見極めることだ。多くの人が必要としそうな処理な

    『車輪を発明しようとする前に』
  • 『プログラマは考えるのが仕事』

    悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 私の職場では2つ穴のパイプファイル(リングファイル)をよく使う。そのため、私はデスクの上にハンディタイプの2穴パンチを置いている。紙の縁に噛ませてパチンと鋏むだけの、よくあるやつだ。 あるとき、若いプログラマがこのパンチを借りに来た。何気なく彼の様子を見ていると、紙の真ん中を決めるのに苦労しているようだ。私のパンチには紙の位置を合わせるためのガイドが付いていないので、うまくできないのだろう。バインダーに綴じられた紙は、縁が揃っておらず、ガタガタになっていた。 こういうパンチを使うときは、紙を半分に折って、折り目をパンチの真ん中(目印がついている)に合わせるのである。もちろん、

    『プログラマは考えるのが仕事』
  • 『GOTOを使ってもいいんですか?』

    悪態のプログラマとある職業プログラマの悪態を綴る。 入門書が書かないプログラミングのための知識、会社の研修が教えないシステム開発業界の裏話は、新人プログラマや、これからプログラマを目指す人たちへのメッセージでもある。 ある新人プログラマに質問を受けた。処理の流れをどう書いたらいいのか分からないという。 「GOTO を使ったらいいんじゃないの?」 「GOTO を使ってもいいんですか?」 なるほど、彼は GOTO を使ったらクビになるとでも思っているらしい。しかし、このケースでは、GOTO を使わなければ、既存の処理の流れを大きく書き直すか、かなり不自然な書き方をしなければ、目的を実現できなさそうだ。また、GOTO を使っても、コードがそれほど読みにくくなるようなこともないようだった。 「なるほど、どこかで GOTO を使ってはいけないと聞いたんだね。じゃぁ、なんで使ってはいけないと思う?」

    『GOTOを使ってもいいんですか?』
  • 『私が資格を取ろうとしない理由』

    ITPro の「情報処理技術者試験は,存在価値がなくなったのか? 」という記事を読んだ(※)。実は、私は資格を取ろうとしない技術者の一人である。いい機会なので、なぜ取ろうとしないのか、考えてみることにした。 まず思いつくのは、「他にもっとやりたいことが沢山ある」ということだ。この業界、常に新しく面白そうな技術が出てくる。調べてみたいことがどんどん増えて追いつかない状況だ。そんな中で、特に面白そうでもない資格試験の勉強をする気にはなれない。 では、もっと時間に余裕があれば資格の勉強をするのだろうか? と考えると、やはりしないだろう。おそらく、別の趣味に使うと思う(小説を読んだり、映画を観たり・・・)。・・・結局のところ、単に勉強が嫌いなだけかもしれない。 ここまできて、「勉強しなければ受からない」という前提で考えていることに気がついた。資格試験というと、どうしてもそういうイメージがある。周り

    『私が資格を取ろうとしない理由』
  • 1