どうも、calcsです。
MECE(Mutually Exclusive and Collectively Exhaustive)ってご存知ですか？ 要は集合を漏れや重複のなく、部分集合の集合に分割するってことなんですが。
コンサルティング会社のマッキンゼーが使い始めたとされるこの言葉。プログラマー的には非常に気になるワードな気がしたりしなかったり。
以前if文について書いたことがありましたが、ifとelseは常にMECEです。これらが両立することはありませんし、もれることもないです。
ではelsifはどうでしょうか。これは必ずしもMECEではないです。重複する条件を記述することは文法上可能です（そしてバグになる）。実行はされない処理系が多いですが。
switch文も同様で、default文を入れれば、とりあえず漏れはなくすことができます。しかし各caseが重複していないかはプログラマの頭に委ねられているんです。
例えば動物の特徴を入力して、哺乳綱、鳥綱、両生綱 、魚綱、蠕虫綱を判定するプログラムを書いたとしましょう。これらの項にまたがって存在する生物はいません。
昆虫ってどうするの？昆虫綱が実際にはありますが、ここでは設計上抜けていたわけですね。
学校で習ったことですが、哺乳類は胎生です。なのでそのようにプログラムしますが・・が。
カモノハシをどうするか？ということに気がつくのは、カモノハシという存在が出てきてからなんですね。
かつて鳥類は「毒」を持つことはないと思われていました。が、モリモズという鳥がニューギニアに生息していることが分かり、この常識は破壊されました。じゃあ毒があるから「鳥以外」とはいえないわけです。
結局のところ、MECEに分類することは指標によっては不可能ではないですが、非常に困難な場合が多いわけで、これは自然の摂理なんです。なぜ自然の摂理かというと、分類が先にできるということは稀だからですね。
そしてソフトウェアも、現実の事象を処理するものである以上（たとえゲームのような仮想であっても、『プログラマの脳』を処理しているといえます）、常にMECEであることは困難なんです。
つまり何が言いたいかっていうと、ソフトウェアにバグがあるのは仕方ないんだよ！！ ええー・・。
Archive for the 'チラシの裏' Category
MECEであることの困難性
Yahoo!ウォレットでイラッときたこと。
calcsです。
更新頻度低すぎですね。灰。すみません。
でー、今回はですね草津、瀬田のグルメ情報とかを扱っている、『地域情報サイト アールズマップ』の方のお話です。
まぁサーバ代の足しにでもなればとYahoo!AdPartnerの広告を貼り付けることになったんですけど、口座番号がなぜかエラーではじかれるんですよね。正しく半角数字で入力してくださいとか言って。
してるっつーの！
で、結局なんだったかというと、口座番号をゼロサプライしろということでした。
ゼロサプライというのは、左空白をゼロで埋めて桁を揃えることです。日本では銀行の口座番号は7桁が最大桁長となっていますが、それ未満の桁数も許容されています。場合によっては3桁の口座番号とか。
でもYahoo!ウォレットの登録データの整合性チェックルーチンが、7桁かどうかをチェックしているらしく、左を0で埋める、つまりゼロサプライしないといけないという話。
書いて置けよ！
ごめん。やっぱり人間はCで書かれていたよ
以前人間の体はJavaで出来ているらしいというエントリを書きました。書きました、が。
すみません。やっぱり人間はCで書かれているようです。ソースは今日昼寝した時に見た夢。
前回の激痛と違い、ふと腹部に感じる圧迫感。これは・・、あれだ。
俺「便意か」
しかしトイレに行こうと思っても、なぜか体が動かない。うつぶせの状態からまったく起き上がれないミステリー。やばい。こいつ（＝体）･･動かないぞ!
額ににじむ脂汗。腹は痛くないものの、圧迫感は刻一刻と増している。このままでは・・。
そこで彼女が登場。
彼女「ごめん。バグ作りこんじゃったからブレークポイント設定したの」
な・・バグ･･だと？まさかcancerクラスか？
俺「・・で、何が原因だった?」
我慢は限界だ。
彼女「腸の内容物を保存してるハッシュテーブルがコンフリクトしてた」
俺「・・ハッシュのサイズいくつにしたのさ」
彼女「100」
なんでそんな素因数が多いサイズなんだよ!せめて97か101だろ！
彼女「まーでも何処でバグったかわかったし！ じゃ、いったんプロセス落とすねー」
・・・・プロセスって何ぞ？
ぎゃー。
というところで目が覚めた。もしかしたら病院にいくべきなのかもしれない。ちなみに起きたら便意は無かった。（名誉の為に言っておくが）メルトダウンしたのではなく、それすら脳の生み出した幻想であったのだ。そう、いないはずの彼女と共に。
果たしてキャリアエイドはテクニカルなのか？
どーも、calcsです。
年度が替わってここ最近、うちの団体に入る新団員の人と会う機会が多いです。こういう活動をしていて、自分でもやってみたいと思ってもらえるのはうれしいですね。
でまー、広報などの方はとりあえず置いておくとして、開発側のお話。
「果たしてキャリアエイドはテクニカルなのか？」
よく分からんのですが、うちの団体の技術力って、別に高くは無いと思っています。というか、高い技術を使っていない。団体に入っても、そこらのウェブ系のアプリケーションベンダーや、デザイン業者、ホスティング業者の1~3年目ぐらいが担当するぐらいの仕事しかない気もします。大半は。
まぁ普段作業しながら、レジスタがどうの、命令フェッチのコストがどうの、ゲーム木探索アルゴリズムや数値計算の高速化、動的言語の静的コンパイル、デバッグ手法、そしてコーラはコカかペプシか、といったようなことをグダグダ話してはいますが、実際問題キャリアエイドで扱っている領域には掠りもしていません。
となると別に技術はあんまりいらないよね。オープンソースのCMSを拾ってきてレンタルサーバにインストールして、自分でテンプレートやプラグインを書いたりして俺サイトに染めれる人なら即活躍。そうでない人もバリバリ勉強は出来る。・・気がする。
やや、技術陣は自主的に勉強会開いたりしてますんで、学ぶ機会はオオイヨ！役に立たないことを全力で勉強するのがポリシーダケドネ！
そんなわけで、「無駄にこそ真理がある。無為な時間こそ人生の至福」とか、18世紀の欧州小説に出て来そうなフレーズが思い浮かんだ人はレッツコメント。
僕がプログラミングを好きになった理由
全世界60億人超の皆さん、お久しぶりです。calcsです。
今日は自伝？でも書いてみようかとおもいます。
理由はネタが特にないから。
小さいころは、というか小さいころから工作が大好きでした。
ゴミ捨て場から電化製品を拾ってきては分解。スーパーからダンボールをもらってきては秘密基地の建材にし、使い捨てカメラを分解しては、コンデンサに蓄電されていた電流で感電する（痛い）。
そういう人間でした。
で、まぁそれぐらいならいいんですけど、工作の材料を買うとなると金がかかる。その点ソフトウェアならいくら作っても金がかからない。（多少ソフトがクラッシュしたぐらいではハードがイカレないことはすでに知っていました）
てなわけで、ソフトウェアの道へとのめりこんでいくわけですが･･。
その時はプログラミングをするのに、これほどの書籍費がかかるとは夢にも思わなかったのです･･!（多分続かない）
むしろ生きろ委員会。合議制が学生団体を活かす
続編。
あんまりこっちは書くことないからマキで行くよ！
まぁあえてこういうエントリも書くのは、バランスが大事だよ。っていいたいからだけなんですけど。
合議制の方が効率的に動きそうな問題っていうのは、基本的に間違いをつぶしていけばよくなる類の問題。
文章の誤字脱字の修正とか、契約の免責事項の穴チェックとか。特に前者はプロの校正が一般に流通する書籍には入っていますが、それでも初版だとまず間違いなく複数個の誤植を発見することができます。
こういった問題空間の分割が平易に行える問題は、合議制というか、多人数での分担作業が効果的です。
後、注目したいのは「毒抜き」ですね。ピンで自重せずに仕事をすると、個性がきつすぎる場合があり、それはそれでいいんですけど、ポリティカル・コレクトネスに欠ける場合などがあると、こいつは訴訟リスクなども含めてやばいことになります。
そういう意味で、ラストのチェックというのは合議制がいいかもしれません。後ブレストってのは「まぁそれはそれとして」と、言う立場でアイデアのまとめに入れるのであれば材料出しという意味ではいいかもしれませんね。アイデアを取りまとめていく段階を多数決にすると、よっぽど感性が似た面子でない限り満場一致はありえませんので。
ま、ワンマンはそれはそれで結構意義深いものです。「ワンマン経営」とか、あまりいイメージもたれてないですけど、自覚あるワンマンは十分益することができるというのが私の考えです。それを意義深くするためには合議制の導入も必要、というのがこのエントリのまとめですかね。
くたばれ委員会。合議制が学生団体を殺す
calcsです。最近このぶろぶもなんだか方向性を見失っているので、自重しません。
えー、タイトルの「くたばれ委員会」って、なんぞ？ということなんですが、これは委員会制のことを言っております。はい。合議制といってもいいですが。
この合議制の偏重が学生団体におけるデスバレーの要因じゃないかなー、とか私は思います。もっと言い換えると「三人寄っても文殊には勝てない」てことでもいいですけど。
正確には頭数があっても「船頭多くして・・」と、なりそうと言うかなるに決まっているところに合議制を導入するのが学生の犯しがちな愚です。ザ・衆愚制。
じゃ、具体的に人数揃えてマイナスになる問題って何ですか？と、なると個人のクリエイティビティーが重要な問題。デザイン・設計・コピーライティングとか多分最たるものです。この解決に人足投入したって時間と労力の無駄です。大体。公募制はよしあしですね。必ずしも応募の中から採用せずとも良いんだったらアリでしょうけどね。
(上述した問題について言えば)みんなで考えればいいものが出来る(可能性が高まる)とか、そういうのは私は信じません。
ちょっと考えてほしいんですけど、1000人の人間がいるとします。その人たちを対象に、例えば新しいお菓子のコピーを考えるとしましょう。
1人の心を動かすコピーならポロッと出来るかもしれません。
5人の心を動かすにはかなり勉強が必要です。
10人の心を動かせれば超一流のライターになれるでしょう。
30人の心を動かすには神に愛されなければなりません。
必要なのはたった一人のスーパースター。その一人のセンスって言うのは数字にすると常人の2倍ぐらいなのかもしれない。でも1倍の常人が30人いようとも話にならない。なぜなら「凝集度」という概念が決定的に欠けているから。
何故そういう事が起きるのかと言うと、一人に集まっているとその個性に特化できる。でも30人だと30方向の異なる特徴ベクトル(＝個性)が相殺しあって、原点(＝個性なし)から遠く離れることができないからではないかな、と思いますね。
なにか、思い当たることのある読者の方はいらっしゃったのでしょうか。いたら幸い。いなくても別に構わないや。
初！次回(の私のエントリ)予告。「むしろ生きろ委員会。合議制が学生団体を活かす」
google アボセンスされました。
アボセンス＝あぼーん+アドセンス
まぁ簡単に言うとアカウント停止ってことで。
どーでもいいといえばいいですが(´ ω `)
プログラマが祈らなければいけない理由
calcsです。
プログラマはビルドするたび、テストするたび、実行するたびに祈らなければなりません。祈ったことのないプログラマはおそらくいないでしょう。マジで。
これには理由があります。まぁ祈らないとやってられないというのもありますが、その理由は『グレムリン』という妖怪にあります。
こいつは発明のひらめきを与えたり、エンジニアの手助けをしてくれる妖怪だったのですが、近年は人間の畏敬の念が薄れ、人間を嫌いになって、いたずらをするようになったといわれています。
で、原因不明の機械の不具合などを「グレムリン効果」などといったりするようで、第一次世界大戦中は戦闘機のパイロットなどに計器の不調を引き起こすものとして恐れられたそうです。また、そのあたりからで、飛行機の納品時にはグレムリンへのお供え物をする習慣が一部ではあるのだとか。
そんなわけですのでプログラマも「お願いグレムリン様！」と祈りをささげることで、原因不明の不具合をなんとかやめてもらおうとしているわけです。ハイ。「小人とクツ屋」では小人さんは、靴屋を助けてくれるように、妖精の類は気に入った人間には手助けをしてくれるものなのだそうです。ただし嫌いな人間には嫌がらせをする。
日本では座敷童子も棲む家に富を与えてくれますが、座敷童子が去ってしまうと家は凋落すると言われています。あなたも周囲の妖精さんに感謝して、嫌われないように心がけてみては？
新しい言語はライブラリを覚えるのが大変
calcsです。
はぁ、まいったまいった。
Railsでソフト組んでたんですが、あほなミスをしてはまってしまった。
<% form_for(@data) |f| %>
<%= f.text_field ‘type’>
って書いてたら上手く動かず頭ひねってしまってました。
結論から言うとtypeというのがRubyの基底クラスであるObjectクラスに、すでにレシーバのクラスを返すメソッドとして定義されているので、コリジョンしてそっちがコントローラーのほうで呼ばれているのでした。
あー、Ruby使い始めたのがついこの間だからまだメソッドを把握し切れていないのがしんどい・・。
最近のコメント