昨日 技術的負債というメタファというエントリーを書いたけれども、それから少し考えてみたら、間違ってたかなと思う所があったので、続編エントリーを。 わたしの感覚ですと、okuさんのエントリーの「汚い方」――Smart UI と、「綺麗な方」――Layered architecture で作られたソフトウェアは、同じものの汚い/綺麗というよりも、たまたまある領域では同じ目的につかえるけれども本質的には全く別の製品であって、それをわたしは「プレハブ」と「きちんとした家」に喩えました。 そして「プレハブで十分なところにきちんとした家を立ててもしかたがない」というジャッジが、真か否かを問うのに「技術的負債」というメタファに基づくモデルで語る領域じゃないんじゃないかしら？――というのが前回のエントリーのダイジェスト。 だけれども、わたしが間違っていたのは、okuさんの文脈でも技術的負債についてはすでに

先週の土曜日、3331 Art chiyoda で行われました、マツドサイエンティストナイト4 に行ってきました（松戸でも夜でもありませんでしたが）。 タイトルは「超低高度衛星の秘密」。いままでは マツドサイエンティスト こと 野田○○さんがゲストを招きつつお話ししていたそうですが、今日は野田さんが主役の話題です。 まずはメンバーのご紹介。 野田篤司さん。謎のエンジニア（自称）。前述のとおり今日は司会ではありません。 鹿野司さん。ごぞんじ くねくね な方。サイエンスライターです。野田さんと知り合ったのは 1999 or 2000で、野田さんが 超低高度衛星を始めたのは2006年。それからすぐの 2007年頃に取材しようとしたそうですが、、、、大人の事情で実現せず。今日はちょっとしたリベンジ？ 石川月美 さん。肩書きは女子高生。一部ではサテライトガール の二つ名も（でもそれだとご自身が衛星に

濱野さんの「入門Git」を初めて読んだ時、いきなり 第二章から Git の構造の説明を始めてしまう構成に「Git<の使い方>入門」じゃなくて「Git<の作り方>入門」でしたかーっ（さすがメンテナですね）、、と思ったことを覚えています。 入門Git 作者: 濱野純(Junio C Hamano)出版社/メーカー: 秀和システム発売日: 2009/09/24メディア: 単行本購入: 31人 クリック: 736回この商品を含むブログ (155件) を見る それは結構楽しい体験で、それまで全く思っても見なかった「Git作ってみたいな」という うずうずとした衝動がわたしに芽生えるきっかけでした。それ程に Git の設計はシンプルで 手に終えそうで、それでいて「うまくいく仕組み」が備わっている、興味深いものだったのです。まさにハックと呼ぶにふさわしいそれは、VCS全般に抱いていた「しっかり綿密に作りこ

Nキーロールオーバーとは、N個のキーが同時あるいは逐次に押下されたとき、それをONだと認識できることです。一時に N個のキーまでを ON と認識でかきるかです。N の部分には同時認識の上限値が入るか、N のままで「全キー同時押し」ができることを示す用語です。 この用語は、PS/2 ポートが標準の時代には、純粋に同時押下認識数を示していました。同時押し認識できる キースイッチ配線はコストがかかる一方で、高速タイピングをする場合などで同時認識は有用であったため、スペック上の差異として強調される項目の一つでありました。Nキーロールオーバーは高級キーボードの証でもありました。 しかしUSBポートのキーボードが登場してから、少々面倒な事になります。というのも、USB の電文書式上の制約により、修飾キー以外のキーは6キーまでしか押せません。せっかくスイッチの配線を奢って任意数の同時押しを認識できるよう

おはようございます。 さてさて二日目。朝起きて早速温泉につかった後（朝風呂サイコー！）、今日の予定を話し合います。 わたしの提案は「朝ご飯食べて、プリキュアみてから観光に行こう！」です。・・・というわけで、8:30にお部屋に戻ってこれるように食堂へ。 あら、朝食はバイキングなのですね。なんだか花咲くいろは のエピソードを思い出します。・・・とか話ながら食堂に入ったら、なんと順番待ち。仕方が無いので一度自室にもどって待つことに。うう、わたしのプリキュアが〜。 てな感じで 8:30頃朝食開始 いろいろ種類豊富にとってきてしまうのは、食いしん坊の性とというもの。取り皿に取らせていただいた食べ物はスタッフがおいしくいただきました。 というわけで、観光に。まずは大内宿へ、れっつらごー！　です。 大内宿 そんなこんなで本日のドライブ開始。本日はアニソン付きのご機嫌ドライブと相成ります。 途中、Piyo

わたしはソフトウェアの技術者で、建築のことなんて全然わからないのですが、「東日本大震災における建築物の被害報告 Part1」という特集に惹かれてかってしまいました。 建築技術 2011年 09月号 [雑誌] 出版社/メーカー: 建築技術発売日: 2011/08/17メディア: 雑誌購入: 6人 クリック: 73回この商品を含むブログ (1件) を見る この特集、15章80ページもある大変なボリュームのあるもので、読み応えは抜群でした。 衝動買いだったのですが、これは買って良かったと思える素敵な一冊でした。 * * * このような特集が気になってしまう背景ですが、それは技術に対する無力感（絶対に勝てない絶望感）が、わたしの心に植え付けられてしまったからです。 津波でほとんどが流されてしまった木造建築の映像ををみると、津波が来うる土地に木造家屋を建ててはいけない・・と思ってしまいます。 今回の

コンパイル時ダックタイピング - みねこあ にて、過去のわたしは ダックタイピングは ad-hoc polymorphism subtype polymorphism parametric polymorphism のどれにあたるか？ コンパイル時ダックタイピング - みねこあ という点で悩んで、混乱していました。 その点について、英語版のWikipedia Duck typingとAd-hoc polymorphism がわかりやすかったので気持ち翻訳してみました。 * * * まずは、Duck typing - Wikipedia から。 Structural type systems Duck typing is similar to but distinct from structural typing. Structural typing is a static typing s

例の OOP の三大要素「カプセル化（≒情報隠蔽）」「継承」「ポリモーフィズム」は、有名なわりには「詠み人知らず」で、しかもあまり良いモノではありません。 sumim さんによれば、もともとはC++でのOOPを説明する要素から「抽象データ型」「継承」「動的結合」の三つが抜き出され、その後変化した物だと思われるそうです。(オブジェクト指向の概念の発明者は誰ですか？(改訂版) - Smalltalkのtは小文字です)。 そのようは背景から、「三大」は 静的OOPLに偏っており、しかも C++ 界隈ですら、C++ プログラミングスタイルの進化から取り残され、古びて現状に一致しなくなっており、21世紀に入ってからのまともな C++ 本で そのままを使っているのをわたしはみたことがありません。 この「三大」を 「OOPとは何か」の文脈で 取り上げるメリットはもうないのです。（デメリットならたくさんあ

先週の日曜日ですが、話題の空と宇宙展を見に上野の国立科学博物館に行ってきました。 これがすっごく面白かったのですよ！ 空 航空史のほうはあまり興味がなかったので、実際の所堪能できたとは言えません。予習していけば良かったと、ちょっと後悔。 こちらは日本初の飛行機（の模型）。二宮忠八の有名なカラス型飛行機の模型と絵が凄くキュートでした。これは・・・すてきすぎ。「評価されなくてスポンサーた突かなくて頓挫した」なエピソードは、大変有名ですが、この模型だけでもうれなかったのかしらとか、不謹慎なことを考えてしまったり。 プロペラ。 ぐるぐる回っているのが目を引きました。エンジンごと回転させることで冷却もするよというのは「なるほど！」と思ったり（というか、そんなことも知らなかったくらい 航空機には疎かったり(^^;) 日本初の動力飛行にかんする展示スペースにあった、アンリ・ファルマン複葉機とハンス・グラ

Traits は、inline関数や Cのマクロに似ています。 Traits を クラスに use した際に、継承や委譲と違い、メソッドの持ち主を指し示すのではなく、メソッドそのものをクラスに展開してしまいます。これは通常のコール/リターンする関数と、 inline関数や Cのマクロ の間柄によく似ています。 これを「フラッティング」と呼ぶのですが、たいていは実効効率 の問題で用いられる inline関数と違い、Traits の場合「フラッティング」は可読性の為だと言います。 Even though a class may have been constructed by composing small traits in a complex hierarchy, there is no need to require that it be viewed in the same way.

昨日は久々に 一番最初の会社の同僚達と飲んできました。超ブラックだったこの会社は日々驚愕のエピソードを体験させてくれたので何年経っても記憶が薄れることがありません。 給料日は同期みんなでマクドナルドにいって会社の愚痴をいいながらお昼を食べるのが習わしでした。昼を食べ終わり会社に変える際に「あぁ、この角曲がったら社屋に鉄球が叩き込まれていて崩壊していないかな」とか語り合ったのは、今となっては良い思い出です。 ──そう、思えば本当に酷い会社でした。 * * * 絶対に守れるはずの無いスケジュールが引かれ、その上常に案件は3件同時進行（定時分・残業分・休日分 と揶揄してました）、誰も手が開いていない状態でも平気で新しい仕事が放り込まれ、真実の鐘は22時、プライベートは掛け値なしにゼロであり、徹夜明けの朝、やってきた新人に仕事の指示をするようになったら一人前みたいな酷い生活。 そこで「人間追い込ま

きむら(K)さんち経由、実はオブジェクト指向ってしっくりこないんです！。いろいろ強烈なインパクトが満載で、スルーできませんでした。 特に「メンバー関数をstatic宣言すればインスタンス宣言をしなくてもいい」ということ知ってからは、メンバー関数を従来のファンクションのように使っている。共有変数も、pubulic static宣言していまう。したがってプロパティなんて作らない。 staticを理解していない人のコードを見ると、いちいちインスタンス宣言しているので笑ってしまう。 ぎゃーっ....。本人はまわりを笑っているつもりでも、逆にまわりに嗤われていますよ、絶対。 ここ以外にも突っ込みどころ満載のエントリーですので、読みながら突っ込むお手々が止まらなくって、腕がつりそう。そんな突っ込み連打なエントリーもおもしろそうですが、わたしはそういうのは上手く書けないので（性格がネチっこいから、なんだ

衝撃のそらのおとしもの 第二話を現実にするイベント、空フェス!に行って参りました。会場は、3331 Arts Chiyoda。なんか学校を改装したもの？みたいで、ホントにここが会場？・・って感じでした。 入場すると、パンツと風船がもらえます。 なので会場は風船だらけ。 そして宙に浮かぶ風船の親玉。 か、かわいい...。（彼女はその後大活躍するのですが、それについては後ほど） さて、開会宣言です。 開会宣言を行うのは、一番最初に空飛ぶパンツを作った野尻さん(SF作家)。 全てはここから始まったと行っても過言ではありません。 * * * 空フェスは大好評で、会場まで少し迷った関係上、パンツ羽ばたき飛行機のワークショップは、2巡目移行になってしまったので、会場内をぶらぶらと見学です。まずは、野尻さんの脇に移っている巨大なボール。 これはチームラボさんのチームラボボール。ヘリウムが充填されていてほ

PHP はやはり良くないツールなのかもしれないと思いました。 私は PHP のことを良く知らないので、単なる「思いました」なのですが、PHP に関するいろいろなエントリと、私の ASP での底辺開発現場の経験を ミックスすると、どうもそのような気がしてくるのです。 これまで 「PHP 酷い」を聞いても、それでも PHP 自体に罪はなさそうにおもっていたけれど、今回はじめて「実は PHP にも罪があるんじゃないかしら」と疑問におもった次第です。 そんな疑問のきっかけになったのは、関数禁止令です。 * * * 筋肉炒飯 - 【逆説】PHP を使いつつ思考停止をすると頭脳が腐敗する さんのエントリはなんかすごくデジャブで、一連の PHP ネタの中では、群を抜いた共感度 No.1 でした。 私が見たのは ASP での開発現場でしたが、 別に他のプログラミング言語であれば劇的に改善するというものでは

今年もLLイベントに行ってきました。 いきなりネガティブなことを書いてしまいますが、いろんな「LLの祭典」という色合いは年々失せ、一方で代わりに「Blog や Web の有名人に会いにいこーっ」みたいな色が強くなった気がします。 ちなみに今回のイベントの LL = Perl、Python、Ruby、Java、史郎さん、といった感じ。 Language Update は今回ないよ。 ΩΩ Ω＜な、なんだって――！！？ 今回はまつもとさんが居ないよ。 ΩΩ Ω＜な、なんだって――！！？ ・・・ということで、泡沫言語のいろんな状況をみてうれしくなりたい趣味のわたしはいきなりがっくり。 朝から生テレビ！ 史郎さんがおもしろそうなことをいっぱい降るのに、ほかの二人がボールを投げ返してくれない。斜め上の話に言っちゃうぅ、、というフラストレーションが貯まることが多かったです。 並列プログラミングの話 ケ

経験の浅いプログラマーがデバッグにてこずってるのって、 これと似ていて、 むやみやたらにクリックするのだけど、 自分の知ってるパターンに収束させることができない、みたいな。 これについては、経験を積めば、 自分の知ってるパターンが増えてきて、 バグだ、と思ったときには既に自分の知ってるパターンだから直せる、とか、 ちょっと試行錯誤すればパターンに落とし込めるとか、 そうなるんじゃないかな、と。 経験の浅いプログラマーがデバッグできない理由 については、コンパイラの吐くエラーが実は直接的が原因を示していない、とか、そういうレベルの話では実感だな、って思います。 「そうそう、コンパイラがこんなこと言うときは実際にはあんな事が起きてるんですよ」みたいな知識データベース。そしてコンパイラが検出出来ないタイプのバグについても、現象に「あれ？、どこかでみたぞ、これ」となる。そういう「良くあるパターン」

C++ の本積みがナウなヤングに総受けらしいです。わたしもちょっとやってみましたが、タワーというより2階建て戸建て住宅でちょっと心苦しい感じでした。（uskzさんのはデッカイマンションみたいでしたが） しかし C++ ばっかり人気なのはちょっと嫉妬です。そこで Smalltalk の本を積んでみました！ ふっふっふ、マイナー言語と言われつつも、結構なかなか、充実でしょう？（特に日本語の本！） 正直、わたしは 似非Smalltalker なので、わたしのタワーは単なるコレクションなのが C++ タワーとは違う所ですが（あっちは仕事上必読）、そうは言いつつも良書のヒット率は高いです。また、80年台後半から90年代前半までの本が多いのですが、にもかかわらずそれほど内容が古びていないのも「過去から来た未来の言語」の面目躍如といったところ。 * * * 良本ぞろいのSmalltalk ですが、個人的

とりあえず、C++ を使ってはいけなかったコトだけは解った - みねこあ について、もうすこし具体的に。 誰が使えないのか分かりませんが、多分ここでこれだけ書くということは、入社半年たたない新人より、名目上10年以上ソフト屋やってるやつが100倍使えない（リアルに工数が100倍かかる）という話でしょう。 一人増えたー、とかだったらまだ...だったのですが、なんかどんどん増やされていくのですよね。2ヶ月に一人ペース。もうムリです。背負えません。 * * * 言われるのは、「わたしにコーディングさせるのはモッタイナイ。要件分析や設計をやり、コーディングはその人達に任せるべきだ」なのです。けれども、わたしゃ SE(笑) なんかに成る気はさらさら無いですし、わたしの趣味以前に、そもそもこの人達は「プログラミングを任せられる」ほど C++ を使えない、みたいな。うーん、どーしたもんかかしら。 もっと

「ジェネリクス指向」と言うのを、恥ずかしながら今まで全く聞いたことが無くって、それでその語感をすっごく胡散臭く感じてしまったのです。 まず、「なんとか指向」がどうも buzzっぽく感じて胡散臭い。そして、ダックタイピングすら出来ない 奇形OOPL が、漸くそれが出来るようになったとき、「俺っちてば、OOPを超えたぜっ」と中二病を発症したかのような印象を受けてしまってどうにも胡散臭いです。 Smalltalk派じゃないOOP の 祖(?)、C++ にしても確か「総称の実装は必須」と最初から言い切ってたし、メイヤー先生の OO も総称はあって当たり前って感じでしたし。宗派に依らず総称をOOP外のパラダイムと言ってしまうのは違和感を感じます。でも一方で、サブタイプによる多態しか持たない言語にとって、総称は新たなプログラミングテクニックですし、総称と多態は重なるけれど 同じものではないですし。だか

さあ、ここからどんどん暗黒面に突っ走りますよ！（つまりは愚痴です） 結構前に、余ったCOBOLエンジニアがたくさんいるから COBOL の仕事を創出するんだ、みたいな記事を読んで、「バッカじゃないかしら」と思ったのだけれども、図らずも不景気で わたしの周辺の環境もそうなってきました。 なるほど、仕事はないけれど社員はクビに出来ないってなると、不景気は品質による淘汰ではなくって、品質悪化を加速するのね...orz などと、グチグチ言ってみるも、現実はどうにも変わらない。 「その人を追加されるとチーム全体のパフォーマンスが落ちる」という人をどんどんチームに叩き込まれて、人が増えたのだから稼ぎも上げろということを言われます。ムチャを現場に押しつけて・・・とは思いますが、出来ない人を社内失業させない、という要件からすれば、出来ない人のための仕事を用意できないようなウチのチームの作り方は、背任と言っ