「ビル･ゲイツは西さんとジェットヘリで来られました。」MSX開発当時を知るヤマハと元ビクターのエンジニアの方々にインタビュー。当事者ならではの貴重な証言がもりもり飛び出す！そのほか、米国での体験を語るSF作家宮内悠介先生のMSX愛、サンリオがMSXに参入予定だった!?などのこぼれ話、マイクロソフト内部にいてMSXの普及に尽力したトム佐藤氏の視点、MSXの知識を問うMSX検定（クイズ）などなど、“MSX30周年企画”の一環として週アスPLUSにて連載された記事を1冊に。電子版のみの書下ろしもあり。
「MSXを作れ!!」ジェットヘリで来て発注するスゴい男たち週刊アスキー･ワンテーマ｜電子書籍（4月9日発売） - 週アスPLUS

イイね！速攻で購入してkindleに転送された。後でゆっくり読もうっと :)

2015-04-10

時には名誉ある撤退を

リリース三ヶ月前の技術的挑戦はワクワクするが、リリース一週間前のそれはただのストレスである。解決できなかったからといって必須なものは後回しにすべきではないし、昨日はそれで解決できるか不明でストレスがやばかった。まあ今は山場を超えたので精神が安定しつつあるんだけど。
一週間前 - mizchi's blog

うんうん、分かる。ちゃんとテストしてるつもりでも、リリース直前に限って重大なバグが出てくるんだよね。

結局さ、人間追い詰められないと「そろそろテストするか」って気にならないわけですよ。事前に確認しておけば楽になるって分かってても、基本的にこの業界の人って忙しいわけで、間際になってテストしてみたら「あれ？」ってことになる。いつもすいません、はい ^^;

じゃあどうすればいいかというと、これがまたケースバイケースという身も蓋もない言い方しか出来ないんだな。理想はある程度（少なくとも一ヶ月ぐらいは）コードをフリーズしてひたすらテストできればいいんだけど、しょっちゅうデプロイするようなウェブサイト系のプロダクトだと論外だったりする。プロダクトごとにベストプラクティスを探っていくしかない。

ただ一つ言えるとすると、人間の能力には限界があるってことは理解しておいた方がいいと思う。明日納期だから、どうしたって解決しないといけない問題があって、何とかパッチを作ったとしよう。無事リリースできて、良かったね。でもこういうコードはろくにテストもレビューもされてなくて、あらたな重大バグを生む可能性が極めて高い。さらにパッチを出す。顧客の心象はどうだろうね。

ソフトウェアって、結局作った人への信頼しかないと思うんだ。仕事だって信頼されている人のところに多くの仕事が集まるよね。納期が大事じゃないとは言わないけど、長い目で見て、時には名誉ある撤退をすることも必要じゃないのかな。

2015-04-03

プログラマとして自然にキャリアを積めるような業界になって欲しい

日本のプログラマの場合、40歳になるとマネジャーになるという選択肢しかないですよね。そういうのはそもそもおかしいと思うんです。
40歳になっても50歳になってもいいプログラムを書けということではありませんが、20〜30代の時に良いプログラムを書いたら、すごい給料がもらえるようになると、後の人生設計が変わってくるんです。
ぼくと同じ年のアメリカ人の友人の中には、プログラムしか書けない人が、若いうちにたくさん稼ぎ、今はプログラムを書かずとも幸せな人世を送っている人はたくさんいますよ。
【未踏会議】坂村健氏・村井純氏・竹内郁夫氏ぶっちゃけ対談！日本の大学はココがダメ・起業せず教育の道を選んだ理由etc.｜CodeIQ MAGAZINE

まさにこれ。日本のソフトウェア企業はソフトウェア技術者を大事にしないところが多すぎる。最近はやっとソフトウェアの重要性が分かってきたかな！？いや、業界を見るかぎり、根幹はあまり変わってないように思う。もちろんプログラマを大切にしてくれる企業もあることはあるけど、少ない印象。

いずれにせよ、この国でソフトウェア技術者として長きにわたりキャリアを積んでいくことは容易じゃない。すごい才能を持っているか、私のように出世街道を外れた変人(笑)になるか。

願わくば、プログラマとして自然にキャリアを積めるような業界になって欲しいと、切に願う。マジで。

プログラマを長く続けるには、どうすればいいの？ - プログラマyasuhoの隠れ家

2015-04-03

分からないことがあったら、すぐ誰かに聞いた方がいいの！？

プログラマ系のお仕事。
わからないところを数時間悩む自分
職場で毎日詰んでる件

分かる。プログラマに限らないと思うけど、プログラム開発してると、そんなのばっかりだ（笑）

ボクの中でプログラミングはパズルゲームなので、分からないところを悩むのも楽しみの一つだと思ってる。悩んでた問題が解けた時の快感は、まさに難解なパズルが解けた時のあの感覚だ。だからやめられないんだよな、プログラマ :)

とはいえ、どうしても分からない問題だってある。仕事として模範的な回答は「あまり時間をかけず、知ってる人に聞け」で、それはそれで正しいんだけど、そればっかりやってると、自分で分からないことを調べることが出来なくなってしまう。パズルの解き方を教えてもらっても、自分で解けるようにはならないよね！？

調べることと聞くこと、うまくバランスするといいんじゃないかな。

2015-02-26

マイコンと私と昔話

そういう無線ショップにパソコンが入ってくることになる。パソコンは少なくとも初期の頃無線と関係無かったけど、趣味的電子機器の来る場所は無線ショップだったのだ。
初期パソコンはアマチュア無線ショップで売られていた - 仮想と現実

あー、そういえばそんな感じだったねえ。

ボクが最初に触れたマイクロコンピュータ（以降マイコン）東芝のEX-80BSは、かつて秋葉原にあった角田無線のX-Oneというお店（今はソフマップのMac館になっている細長いビル）の5Fか6Fあたりに展示されていた。角田無線は名前の通り、アマチュア無線を中心に扱うお店で、1Fは当時流行っていたBCLに関連したラジオやグッズなどが展示されていたように思う。

当時マイコンが多く展示されていたラジオ会館は、名前の通り無線屋さんが多かった。エスカレータで行けた1-4Fあたりまではアマチュア無線関係のお店が多く、それより上にマイコンショップが多かった印象。ちなみに最上階にはBit-InnやマイコンセンターRAMがあり、秋葉原のマイコンの聖地的な感じになっていた。

あと名前は忘れてしまったんだけど、ラジオ会館近くの雑居ビルの2Fにマイコン屋があった。周辺には、これまた無線屋さんが多かったな。というか、当時の秋葉原は無線屋さんが多かった気がする。

家電屋さんも扱っているお店がちらほら。今はやはりソフマップになってしまった、かつてのヤマギワ電気本店の1Fには、結構な数のマイコンが展示されていた。初めて買ってもらったコンピュータであるSHARPのPC-1211というポケコンは、ここで買ったんだよな。とてもメジャーとは思えなかったマイコンを1Fで展示していたのは何故だろう。マイコンが好きな店員さんがいたのかな :)

実際のところはよく分からないけど

たぶんあまり売れるもんじゃなかったんだと思う。今の貨幣価値で考えると、30-50万円ぐらいしたと思われる代物を、大人はもちろん、子供が簡単に買ってもらえるわけはなく。羨望の眼差しでマイコンを眺めて、触って、カタログを持ち帰る人々が大半だったはず。

そんな事情を店側も分かっていたのか、当時のショップでは、マイコンをほとんど自由に触らせてくれた。何時間も触っていても、文句を言われた覚えはない（当時のお店の店員さん、ゴメンナサイ…）マイコンはもちろん、マニュアルも備え付けられていて、ロードやセーブも自由ってところが多かった。ほんと、おおらかな時代だった。

そうそう。MZ-80K/Cなんかは、電源投入状態で放置されているところが多く、不遇な存在だった。カセット入れたままにしておくと取られてしまう危険があったからだと思うんだけど、マーケティング的には不利だったね、あれは。

商売にはならなかったと思うけど

自由に使わせてもらえたおかげで、コンピュータとプログラミングの楽しさを存分に体験させてもらうことができました。今の私があるのは、あの頃広い心でマイコンを使わせてくれたショップの方々のおかげです。この場を借りて、お礼申し上げます。ありがとうございました (_O_)

2015-01-22

コードの可読性は、名前の付け方でほとんど決まる

議論の中で私は、
コーディングで垂直方向にそろえるインデントをとるべきかというささやか
な聖戦を仕掛けました。私は全面的に賛成です。理由を説明しましょう。
【翻訳】私がコーディングで垂直方向にそろえるインデントをとる理由 | POSTD

コードブロックのイン
デントを自動的にとるアイデアは面白いね。こういうのがIDEで使えるんだ
ったら、垂直方向のインデントを取ることには賛成だな。個人的には、テーブル
のように表形式で見ることが望ましいと思える時はインデントを揃えるけど、

const table_t tables[] = {
    { 10,   "foo", },
    { 2,    "bob", },
    { 33,   "brah", },
    { 0,    NULL, }, // terminator
};

そうでない時には、基本的には揃えない。

foo()
{
    param_t p;

    p.size = sizeof p;
    p.horizontal = 0;
    p.vertical = 1;
    <...>
}

インデントを揃えるかどうかは、その労力に見合うだけのメリットがあるかどう
かで判断してる。

ところで

名前の付け方やスペースの入れ方、さらにキャピタライゼーションルールをよく
考えて適用することで、私たちのコードはかなり読みやすくなりました

コードの可読性は、この名前の付け方でほとんど決まる。プログラムは言ってみ
れば、名前の集合体だ。クラス名/メソッド名/関数名、一時変数に至るまで、そ
れが何を表しているのかが明確になっていれば、プログラムを読み解くのがとて
も楽になる。

意味のある名前にしよう

sub1(), sub2()なんてのは論外だよね（笑）1と2に分けた理由があるはずだ。も
し付ける名前に迷うようなら、命名対象が何をすべきか定義できてないんじゃな
いかな。そもそも何をするものだったのか、原点に戻って考えてみよう。

別にカッコいい名前を考える必要なんてないんだ。一生懸命、英和辞典を使って
意味を考えた名前が、後で見たら何のことか分からない、なんて経験はない！？
ボクの場合、最初に思いついた名前を使うことが多い。それが一番素直なネーミ
ングであることが多いから。

forループのインデックスとか、スコープが限定される場合はtempとかでもいい
と思う。やり過ぎないレベルで :)

抽象的な名前は避けよう

get_data()とか。データって何だよ（笑）突き詰めて考えると、それが何のオブ
ジェクトかは決まるはず。

命名規則を統一しよう

ある場所ではget_vertical_position, 他ではgetVerticalPositionとか、ちょっ
とモヤモヤするよね。プログラム全体で命名規則は統一した方が読む側も内容が
想像できる。同じ意味でコーディングスタイルも統一するといいよ。

一つの変数を別の意味で使うことは避ける

countやsizeを別の場所で違う意味で使うことは、なるべくしないようにする。
意味のある名前にすることが望ましいけど、そこまでこだわる必要がなければ、
スコープを限定するという方法もある。

foo()
{
    {
        int count;

        <...>
    }

    {
        int count;

        <...>
    }
}

これに限らず、名前のスコープを限定することは大事。オブジェクト思考言語だ
とやりやすいけど、意識をすることは必要。javaでいつの間にかシングルトンだ
らけだった、なんて経験はない！？ :)

関数/メソッドの戻り値、例えばretなんかを使いまわす、なんてのは例外。

結論

コーディングは、自分自身の考えを表現する創造的な方法です。表現したアイデ
アを難しく見せてしまうようなツールであるのなら、インデントではなく、ツー
ル自体を改善すべきでしょう。

この結論には同意。コーディングは自己表現なんだ。せっかく作ったプログラム
だから、ぜひ主張しよう :)