ぐらめぬ・ぜぷつぇんのはてダ

2008/11/24以降のメインブログはこちらになります。 : http://www.glamenv-septzen.net/

本はてなダイアリにはコメント・トラックバックを受け付ける記事を公開します。

2011-02-05

「会社の飲み会で偉い人の隣でにこにこ笑いながら・・・」

「会社の飲み会で偉い人の隣でにこにこ笑いながらなんでこんなことをしているんだろうと考えていた。」:

http://anond.hatelabo.jp/20101204223555

相当自分を追い詰めているように思える。

お金に余裕があるならカウンセリングなど受けた上で1〜2ヶ月くらいゆっくり休職して会社と距離を置いた方が良いかもしれない。

ここまで自分を追い詰めてしまうと、自分がどれだけ心身が擦り切れているのかすら気づくことが出来なくなる。

冗談抜きで壊れるぞ。心身ともに。

疲れたのなら休んでいいと思う。少しくらい歩みを止めて足元を見つめても、長い人生を考えれば決して無駄にならないと思う。

ご自愛下さい。

2011-01-07

[]酒飲みながらたまには政治がらみの妄想を垂れ流す。名づけて「黄昏計画」www

全て居酒屋での戯言レベル。笑い話というかネタというか。ぶっちゃけ厨二病的な何か。

数十年後ここに書いてある内の一つでも実現されてたら「俺ってすげー!!」って見せびらかすための証拠的な何か。

「黄昏計画」って?

「もう頑張るの止めようよ、疲れたでしょ?おうちに帰ろうよ。」と、引きこもるための国家レベルの計画。経済成長率の面で言い換えるならば、「ほどほどの経済状態の維持」を目標とする。つまり、プラス成長を目指すのは疲れるからやめて、まぁゼロで横ばい。マイナスは避けようよ、程度。

これを軸として、三つの柱を据える。

  • 鉄鋼、石油、ウランなどどうしても日本国内じゃ賄えない材料以外は、基本自給自足を目指す。
  • 節約志向:贅沢はもう疲れるからやめようよ、的な。
  • 人生のリセット支援

国家レベルで、資本主義自由経済の良さは残しつつ、「もっと金を、企業成長を、経済成長を」という貪欲さを抑えるのではなく、「放棄」する・・・つまり「本当はもっと経済成長してお金儲けてウハウハしたいんだけど、お上が抑えつけるからできない」という状態ではなくて、「なんだか経済成長、お金儲けバンザイ、ってゆーノリ疲れたな・・・。そこまで貪欲でなくとも、ほどほどでぼちぼちで生きて行けないかな?」ってユー感じで、自主的に棄権するイメージ。お金儲けの競争レースから「一ぬーけた!」でとっととリタイア・棄権しちゃおう、というのを国家レベルの基本目標としちゃうのが「黄昏計画」ww

まぁあくまでも国家としてそういう方向を目指す、そういう方向で色々支援政策を打ち出す、というスタンスで、別に「いーや、俺は会社作って大成長させるぜ〜〜〜!!」という個人や企業を制限とかはしたりしない。まぁその辺はどうぞご勝手にという。

ということで、内側に縮小していくのが基本方向なので、当然自給自足できないと辛い。で、当然、自給自足となると以前ほどの贅沢はできなくなるので、というか贅沢って疲れない?的な。なので、節約志向を支援する。

さらに、どうせ経済成長目指さないんだったら、みんなもう少しゆる〜く生きてみようよ、ってことで、人生のリセット支援も一つの柱に据える。というか「黄昏計画」がマジで実現しちゃうと雇用状態が180度どころか360度回った上に北と南が逆転するくらい環境が変わってしまうので、そもそも「ひとつの会社に50年」という前提が消滅して、どこもかしこも「ひとつの会社は長くて20年」だらけになる。いくつか専門技能や職業上の制約で完全な「スペシャリスト」として30年以上の経験を積んでいく人も出てくるだろうけど、基本、「人生リセット」による「その人なりの『ぼちぼち感』を見つける」ってゆーのを支援する。「ぼちぼち」で満足できちゃえば、無理して贅沢に走ることも無い・・・かも・・・ってなれば、節約志向とつながり、ひいては自給自足支援にもつながり、「国家レベルでのひきこもり」である「黄昏計画」の趣旨とも合致するwwww

では、今現在頭の中でぼわぼわ湧いている妄想政策を、上記三つの柱ごとにメモ。

国家レベルでの自給自足

国内でまかなえる材料に付いてはなるべく国内でまかないましょう、という方針。ただし、鉄鉱石・石油など外国から買わないとどうしようもない材料も当然出てくるので、その分、輸出できる産業は維持する必要は残る。

でもそれなら今までと対して変わらないじゃん?・・・てとこなんだけど、「黄昏計画」ではもうちょい視点を変えて、科学力と技術力を駆使して、錬金術のごとく材料を自給自足できないか?ってゆーのを重要視する。

植物からまだまだ材料は取り出せないかな?繊維や食品としてしか利用できないなんてもったいない。もっと化学製品につながるようなタンパク質やらアミノ酸やら化学反応やらは取り出せないだろうか?

海水からウランを抽出するのを効率化出来ないか?海藻から石油とかどうなった?とかとか。

日本とその周囲に存在する膨大な自然や植物から、もっともっと産業に使える材料を取り出せない?

ってことで、そういう方面の研究やら開発を国家レベルでガンガン支援しますよ〜ってーのが一点目。

二点目が、「人の自給自足」。メインとなるのが「廃村、過疎地域の有効活用」。

猫の額程度ではあるけど田んぼや畑がある廃村や過疎地域を活用して、「最低限度のインフラと、野菜や米の種、肥料代は提供するから、後は自給自足でよろしく!」としちゃう。

これは主に都市部でどうしても就職先が見つからず、もうホームレスになるしか無い・現状なってしまっている人の支援。

最低限度は賄うので、あとは自活してみて。

で、都市部や近郊で1ルーム月云万を国家で負担するのはさすがに無理なので、廃村になったエリアとか過疎地域などを活用する。

電気・水道・ネット環境かな?インフラとしては。ガスはオプション。で、ネット環境使って商売始めるのも有り。

まぁ一種のベーシックインカム。まぁ申し込み対象とか適用対象の制限とかに相当苦労しそうだけど・・・。もちろん、ある程度の収入を自力で得られるようになったらそこから立ち退かなければならない、とか制限は必要かもしれない。

廃村・過疎地域の有効活用に絡んで、「人の分散」も妄想してるんだけどこれは「人生リセット支援」と強く関連するので後述。

節約志向:贅沢はもう疲れるからやめようよ、的な。

高級店の出店規制ではなくて、もっと単純に、所得税の申告時に、一年前の預金残高と今の預金残高を比べて貯蓄が溜まっていれば、あるていど控除されるとか、中〜低所得者向けに、節約を奨励する・優遇する政策を妄想してる。

お給料は少ないけど、それに見合った程々の質素な生活を楽しんでる人をもっと支援する方針。

いや、だって国家レベルでひきこもるのが黄昏計画なんでwww

もちろん虚偽報告であるとか、複数の口座を組み合わせて申告時にだけ貯蓄額が大きいように見せかけるとか悪質行為に対するペナルティは厳しくする必要がある。

また、あくまでも自己申告制なので、まぁ気に食わない人は申告しなければ、従来と変わらない。

企業向けとしては、例えば売上高が同じでも労働時間が短くなればそれだけ効率UPっつーことでいろいろ税制上優遇されるとか。もちろん虚偽報告に対するペナルティや、そのための監査システムは組み上げる必要があるけど。

ぶっちゃけ、国家レベルでひきこもり・内向きになるのでとにかく仕事は確実に、今よりさらに無くなる。つまり企業側にとっても、まぁ企業のノリによりけりだけど、成長志向よりは「ぼちぼち」志向に切り替えないときっついかもしれない。

ようするに勝手に目標高くして「達成できない・・・」と悲嘆にくれるより、現状維持できりゃオッケー、のんびり行こうよ的な企業の活きる余地を国家側としてもなるべく用意出来ればなぁ、ってところ。

なにしろ「黄昏計画」は「ひきこもり計画」、確実に経済規模は縮小していく。というわけで、余ってしまった企業はどんどん倒産していくし、仕事は減って求人も減り、どんどん失業率は上がっていく。

そこで、前述の自給自足支援で受け皿を確保していくとともに、「人生リセット」で仕事と人生を疎結合にして再就職フォローも行っていく。

お金が足りなければ国債バンバン発行して賄う。もちろん、自給自足支援で徹底的に優遇したバイオマテリアル関連で特許取得を奨励して、そのアガリを諸外国からちゃっかりいただくのも忘れずに。

まぁ全体として「貧しくとも慎ましやかに、平穏に」過ごす人たちのことを優遇することで、節約志向を推進する。

人生のリセット支援

基本方針は2点。

  • 人口の都市部集中の解消
  • 仕事と人生の疎結合を支援

まず一点目の都市部集中の解消ですが、これ、あとは会社や仕事、住居の問題さえ解決出来ればかなりごっそり地方に戻せるんじゃないかと。

ぶっちゃけWebを介した物流や大型スーパーの地方進出により、「都会に出ないと手に入らない」日用品ってどんどん減ってるのは確かなんです。あとは「仕事」さえ都市部からひっぺがせれば、もう無理して人口過密な都市部で高い家賃払いつつ満員電車に揉まれる必要はありません。

続いて二点目の仕事と人生の疎結合ですが、これは少々強引ですが「国家による半強制的な領地替え」を妄想しています。5年、あるいは10年毎に他県への引越し・転職を国家レベルで推奨・優遇します。個人だけでなく、企業に対してもそうして移ってきた新しい人を迎え入れたり、5年や10年単位で入れ替わっても問題ない業務プロセスを構築した企業を優遇するようにします。

つまり国家レベルで終身雇用に対して「サヨナラ」を言ってしまうわけです。終身雇用なんて無くとも、個人レベルでの幸せは追求できる国家を目指すんです。少なくとも、目指しているということを各種の優遇・推奨政策で表明するわけです。しかも、5年〜10年サイクルでの転職を全ての年齢層で推奨・優遇してしまうわけですから、とんでもない混乱とパラダイムシフトが起こります。

もちろん、これらの優遇政策は強制ではなくて、自己申告制です。なので「お上はお上、ウチの会社はウチの会社」で終身雇用を貫いても何ら問題はありませんし、20年、30年と同じ会社でスキルを蓄積するのは個人や会社の好みの問題ですので行政からペナルティを与えることはありません。

とりあえず以上を基本方針として、具体的な妄想を垂れ流していきます。

  • VPNを活用した在宅業務の優遇
    • 業務によりけりになってしまうが、例えば本社は東京でも、VPNやSkypeを活用して北海道にいても仕事できるような環境を構築した企業に対しては何かしら優遇措置を行う。法人税の引き下げなど。
    • 個人宅での作業が難しければ、例えば各社の遠隔業務用の部屋が割り当てられるセンター的な建物を各地方に用意して、そこに出勤するとか。
  • 退職時の職場評価の活用
    • 「推薦状」的な仕組みをハローワークなり行政側で用意し、誠実に仕事して周りと上手くやれていれば、転職時にそれを客観的な評価として活用できる。退職後、その職場や会社からハローワークに評価シートを送るなどしてうまく連携できないか?
  • 副業支援政策
    • 例えば農村地方在住で、遠隔で仕事しているのであれば、遠隔作業の時間を少なめにして、農業を兼業するという生活形態もあり得る。そうした副業形態を所得税の申告などで優遇する。また、副業を許可し、そのための便宜を図る企業に対して何らかのボーナスを与える。
  • 海外レベルでの異文化シャッフル
    • 一生のうちに少なくとも二カ国での職業体験を推奨する。年齢は問わない。ワーキングホリデーを全年齢対象に広げ、さらにそのための休職など便宜を図る企業を優遇する。
  • 社会人学生支援
    • 一旦就職した後、大学に再入学する場合に奨学金支援などを行う。また、そうして専門性を高めた人間を雇用する企業に対して何らかのボーナスを与える。

これらにより、「一旦入った会社で一生終身雇用」という文化を破壊し、様々な職業を経験したり、外国での職業体験を通じて人生観が変わったりなどを国家として支援し、優遇する。さらに進化したコンピュータネットワークを活用して可能なかぎり都市部の仕事を地方でもできるようにしたりして、都市部集中の必要性を下げる。

また、国内でも人の入れ替わりを推進し、村社会的な閉鎖性を漸減していく。「ウチの常識はよその非常識」というカルチャーショック体験を推奨する。さらに社会人学生支援を強力に打ち出すことで、「学び直す」ことが可能であることをアピールする。

「真・黄昏計画」ww

「裏」って付けても何らおかしくないネーミングでまさしく厨二病乙www

まぁぶっちゃけると、こういう政策が仮に実現したとしても「まぁ、本来の目的に沿って有効に活用されるのは、もって30年程度じゃね?」というのを前提とするのが「黄昏計画」www

30年も経ってしまえば、世代は変わるし世界情勢は変化するし科学技術の進歩に伴い新たなビジネスは出てくるだろうし環境は変化するし、云々カンヌンで「黄昏計画」の趣旨が通用しなくなってるだろうな〜・・・というのが黄昏計画で忘れちゃいけない大前提www

ただ、その次の30年のためにどういう日本を用意しておけるのか、あるいは自分たちの子ども、さらには孫に、どういう日本社会をプレゼントできるのか・・・ってゆーのを考えたときに、「貧乏でもなんとかなったよ〜、経済成長率について国際社会からボロクソ言われも、案外なんとかやってけるから肩の力抜いていこうぜ〜」っていう「経験」を用意出来れば個人的には素敵だなぁと思うんです。

「経済成長率をプラスにするには、まだ努力が足りない、改善が足りない、もっと貪欲になれよ!!」って〜ノリですと、何時まで経っても「あれが足りない、これが足りない、あれが欲しい、これが欲しい、だから日本はもうダメだ、ウチの会社はもうダメだ、この業界はもうダメだ」と悲観論や滅亡論で堂々巡りばっかりです。

そうじゃなくて、一旦立ち止まって、「アレ?よくよく考えたら、俺らこれだけ良い物持ってるんだから、もうちょっと『ゆっくりしていってね!!』的なノリでもよくね?」って、意外と自分たちの「満たされてる点」を振り返り、活用したりするのはアリなんじゃないかなと妄想するわけです。

っていうか、今のあくせくした、滅亡論・悲観論大好きな週刊誌が飛び交う、さらにそれを目にして脊髄反射的に「だから日本は/会社は/業界はもうだめだ、海外に出ていくしか無い、なぜなら(お好きなラベリング草食男子でも若者でも老害でもすきなラベリングをどうぞ)はもうダメだからだ」とグダグダのたまい、ブクマコメントとか発言小町憂さ晴らしガス抜きする。

人身事故で電車が遅れたとき、事故に遭ってしまった人の安否よりも先に、会社に遅刻することを心配し、その場にいない、事故に巻き込まれた人に悪態をつく。

「○○は□□でなければならない」「○○よ、△△せよ」「これからは□□の時代」に脊髄反射で不安感や焦燥感を掻き立てられる。

そんな日本人や日本社会、子供とか孫に残したい?いやまぁ、所詮これまで書いたのも個人の妄想だし好みの問題だけど、あくまでも個人の意見だけど、こと人生と仕事の価値観に付いては、もうちょいゆるゆるでもよくね?っつーのが本音。

で、結局「黄昏計画」ってーのは「どこまで貧乏でも国家として維持できるか」を試すチキンレースでもあるわけで。

とにかくひきこもり+内需縮小確定な計画なので、人が余る余る。公務員も余る。余分な企業は倒産する。転職も支援はするけど、専門技能の蓄積が不要なオフィスワークや単純作業が中心となってしまうかもしれない。

「黄昏計画」のもうひとつの狙いとしては、国家レベルで「まぁ60年〜80年が寿命の人間が作る組織なんて、せいぜいもって30年だよねwww」というのを明確に各種支援・優遇政策で打ち出し浸透させるっつーのもあったり。

もちろん50年以上活動を続ける、立派な大企業もあるわけだけれど、まぁ無理してそれを目指さなくてもいいじゃない、っていう。

計画自体がその根っこに「まぁこの計画ももって30年だよねwww」としてるので。

なので、ホントのホントに最後の狙いとしては、「さて、どうやって死のうか?」っつーのをかなり早い段階からデザインさせるっつーのがある。まぁ狙ったとおりに死ぬことなんて運絡みもあって難しいとは思うけど、それでも、老いて病気になって苦しんで死ぬことを前提とした人生設計や組織設計ができるようになれば、結構世の中変わるんじゃない?ってーのは根拠のない妄想としてあるんです。

お酒も無くなっちゃったので、今宵の妄想はこれまで。

2010-08-15

[][] 派遣PGの感じる「怒り」をデコンパイルしてみた

はてなブックマーク - Togetter - 「派遣PG時代の思い出」

昨日〜今日にかけてはてブで盛り上がりを見せたエントリです。ここぞとばかりに、IT業界の日頃の不満をブクマコメントに叩き付け、「これだから日本のIT業界は、大企業は駄目なんだ(嘆息)」と溜飲を下げる技術者が多数続出しています。

自分もその一人で、ブクマコメントで愚痴を呟いています。

技術面での良し悪し・新旧・正邪ではなくて、リーダーやマネジャー・組織文化・経営レベルの好き嫌いや不安感で、辛い縛りが根付いてる。一人の作業者じゃどうにも出来ない。どこにでもある人間の問題。

はてなブックマーク - msakamoto-sfのブックマーク - 2010年8月13日

しかし、このエントリでは少し視点を変え、「何故自分は、こうしたネタに挙げられている現場に対してエントリと同様の怒りを覚えるのだろう、あるいはエントリの著者は怒りを感じているのだろう」という点について自分なりに掘り下げたいと思います。

端的にまとめると、次の三つが「怒り」を作り出した犯人です。

  • 「最新技術へのキャッチアップ」という名の脅迫状
  • 「WHY」の断絶
  • 独りよがりの「美しいソースコード

「最新技術へのキャッチアップ」については、その裏側に「『自分だけ』向上心」という真犯人が居ますがそれは最後に紹介します。

続きを読む

2010-03-16

なぜx86ではMBRが"0x7C00"にロードされるのか?

MBR(Master Boot Record)からのOSロードを解説する書籍やWeb上の記事の殆どでは、「BIOSはPOST後に、MBRを0x7C00にロードしてそこにJMPする」と書いてあります。

しかし、「なぜ0x7C00なのか?0x7C00はどういう意味で、あるいは経緯で、どういう意図で、誰が決定したのか?」については(msakamoto-sf自身が調べた範囲では)誰も語ってくれません。

0x7C00は "32KB - 1024B" という「いかにも何かありげ」な場所に位置します。一方、初期のIBM PC 5150の最小メモリモデルは16KBのRAMしか搭載していません。そのため、「最小メモリモデルではMBRをロード出来ないのでは?」という疑問も出てきます。

MS-DOSのベースとなった 86-DOS(QDOS) の開発者 Tim Paterson, IBM PC 5150 の ROM BIOS を開発した David Bradley 両氏に直接メールで質問した結果、これらの謎が解明されました。

ということで、「なぜx86ではMBRが"0x7C00"にロードされるのか?」、0x7C00の持つ意味、出自、起源について以下のURLにまとめました。もし「0x7C00」について喉に刺さった魚の骨のような感触を抱いているのであれば、ぜひご一読をお奨めします。

Assembler/なぜx86ではMBRが"0x7C00"にロードされるのか?(完全版) - Glamenv-Septzen.net

English Version:Glamenv Septzen: Why BIOS loads MBR into 0x7C00 in x86 ?

2010-03-03

[]いっそ「リズム駆動開発」とか。

TDDに関する議論がアツイですが・・・デブサミ2010のTDDのトラックを実際に聞いてきて、正直TDDにはついていけなくなったな〜という感じがデブサミ直後はありました。

完全に外野席からになってしまいますが、「テスト」「品質」、言葉一つ取っても十人十色の解釈で、「うえ〜〜〜、TDDをきちんと理解しようとしたら、こうした言葉の定義から厳密に理解しないと駄目なの〜〜〜??しかもみんな解釈がばらばらで、どれを信じればよいのかさっぱりだ〜〜」状態です。

日経ち、「そもそも何でTDDが取りあげられてきたんだろう?」という疑問が出てきました。

TDDでは「RED→GREEN→REFACTORING」が「マントラ」として重視されており、このテンポというかステップを細かく繰り返すことでプログラミングに集中し、生産性を向上させる・・・というのが「そもそもの」TDDのキモなのかなと自分なりに想像したのですが如何でしょうか?(実際、「テストを先に書く」=「クライアント側の使い方を先に考えて、実装コードは後に書く」というのは昔から使われていたテクニックのようですので技法としては昔からのもののようです)

・・・そう、テンポ・・・つまりリズムですよ!・・・多分。

xUnitを使ってテストコードを書くなんて、きっと「おまけ」みたいなものなんですよ!・・・多分。

テストコードを書くのはあくまでも「リズム感」「テンポ」を維持する為のものなんですよ!・・・多分。

こうして「多分」を三つほど重ねた上で、でっち上げてみました!名付けて「リズム駆動開発(Rhythm-Driven-Development)」!!

ごめんなさい・・・!!真面目に最前線でTDDやBDDの議論をしている皆さん、本当にごめんなさい・・・。

一応、自分の5年間に渡る雑多なシステム開発の経験をベースに書いてみました。メーカー(工場内)のシステムや決済情報の中継システムなどに主に携わっていたのですが・・・ご想像の通り、「ガチガチのウォーターフォール開発」です、ええ。

でもですね・・・それでも、自分なりに「テンポ良く」コーディング出来てたな〜とは思うのです。

何でだろう・・・と振り返ると、やっぱり、テストコードこそ書いたりはしませんでしたが、「細かくコーディングして、頻繁に動作確認」を繰り返していたからではないかな〜と思うのです。

自分の場合はJavaの担当が多く、結構自分一人で好きなテンポで作れる環境があったので、こうしたやり方で殆ど通してきました。

ところがですね、隣のC言語のチームとかを見ると、「コードを100%書ききるまで実行しない」「実行するのはテスト仕様書に基づくテスト作業から」というのが一般的だったんです。まぁ生産性やバグ密度は自分のJavaも、隣のCもどっこいどっこいであんまり変わらなかったんですが、それでも「ノリの良さ」というのはやっぱり違った気がします。

あるいは・・・別の現場の話ですが、「完成しました〜」と手渡されたJavaコード。「コンパイルは通ったけど一度も実行していなかった」・・・動かしてみたら正常系すらまともに動作しない(泣)。そう、そのプログラマにとっては、「コーディング完了 = コンパイル完了」で、動作確認はテストフェーズという意識だったんですね。

だから一番の目的は「リズミカルに開発することで、生産性を向上させる」、コレではないかな〜と思うんです。

で、リズムさえ整えられれば、別にTDDを使わなくても良いんではないかな〜とも思った次第です。

TDDでもテストコードを書いて自動化するのが難しい部分があるじゃないですか。並行/並列処理、非同期I/O、通信、ハードウェア制御。そうした部分のテストコードを書こうとして何時間も頭を悩ませたりライブラリを探すのは「リズム感」を崩してしまう。

それならいっそ、「ここは自動化テストに組み込むのが難しいので、まぁ手動で従来通りテストでも良いんじゃない?」と妥協しても良いんじゃないかなーと。

従来通りの手動によるテストでも、リズム感さえ保てればそれでOKじゃね?というのがRDDの妥協案です。

RDDの詳細は、前掲の個人のBlogエントリにまとめてあります。こちらではRDDを思いついたmsakamoto-sfの背景や、妥協の産物としてのRDDの要点をまとめてみました。

半分はネタですが、半分は本気です。

2010-01-30

[]第49回PHP勉強会発表資料

第49回PHP勉強会@関東 - events.php.gr.jpでの発表資料を公開します:

http://www.glamenv-septzen.net/medias/php_studies/49th_acme_brainphack.pdf

隣の席のあの人などを吃驚させたい時などにどうぞ。

Lithiumは興味深かったですし、CakePHPのDatasourceも健闘してます。IDEではNetBeanssymfonyをサポートしてたりとか初耳でした。Agaviはまだ頑張ってたんですね(失礼!)。

MongoDBは初めて知りましたが、CouchDBにつけ、スキーマレスなDBって流行ってますね。

発表者・参加者の皆様、gusagi様、会場提供の株式会社コンテンツワン様、ありがとうございました。

そのうちPHPバージョン1を最新Linux環境で動かそう!とか、さいっこうにKYなネタを披露するかも知れません。

2010-01-28

[]PEAR_PackageProjector のdir_roles有効化patch

PEAR_PackageProjector1.0.1リリース - 過去と他人はかえられないが、未来と自分はかえられる でのリリースで、PEAR_PackageFileManager2側へ "dir_roles" 設定が渡っていないようだったので、修正パッチを作成しました。これでディレクトリを対象としたrole指定が出来るようになる筈です。

2010-01-24

[]予告:第49回PHP勉強会で、JOJODIO様がBrainF*ckで”HelloWorld”するようです。

やる夫やらない夫シリーズでお馴染みの、「でっていう」も"HelloWorld"する予定だよ!

一足早めに楽しみたい人はopenpearから"Acme_BrainPhack"をインストールだ!

そんな一発ネタばかりというわけでもない、第49回PHP勉強会はこちらから。

http://events.php.gr.jp/events/show/88

2009-12-30

[]車輪の「再発明」と「再実装」を分けて考える

ソフトウェア開発で既存ライブラリや先行事例があるにもかかわらず、様々な理由でそれを利用せず、コードやプログラミング技法を再び一から作ってしまうことを「車輪の再発明」と呼び、無駄なコストとして非難される場面が多い。

オブジェクト指向プログラミングのメリットを宣伝する時にも、OOPの機能を活用した再利用可能なライブラリによるプログラミングの省力化という観点から「車輪の再発明をする必要はない」という風に持ち出される事が多い。

自分は「車輪という"アーキテクチャ"の再発明はする必要が無いが、車輪という"物体それ自体"は自分で創る必要がある場合も多い」という意見で、gihyo.jpの記事に絡めたエントリを書いたことがある。: [雑記]いい加減「車輪の再発明」の暗喩を使うのはどうかと思うが。 - ぐらめぬ・ぜぷつぇんのはてダ

今回、さらにすっきりと綺麗にまとめられたエントリを発見したのでこちらでも取り上げておきたい。

自分は「車輪の再発明」と「車輪の再実装」は完全に異なると考えていて、

「車輪の再発明」で無駄に頭を悩ませる必要はないですが、

寧ろ「車輪の再実装」は非常に重要だと考えています。

ただ、「車輪の再実装」は習作でしかないことも多く、

習作は習作だということです。

http://d.hatena.ne.jp/Isoparametric/20091230/1262134418

このエントリはソフトウェア技術の学習やソースコードリーディングという観点から、車輪の再発明を「再発明」と「再実装」に切り分けた上で、「自分なりに再実装することで、既存のライブラリの機能やソースコードをより詳しく理解する助けやきっかけになる」と述べている。

これには全く同意見で、自分の場合はPHPのWebアプリフレームワークでまさに同じ事を感じた。一旦完成系、つまりstableリリースに到達したWebアプリケーションのフレームワークのソースコードは、PHPとWebアプリをちょこっと囓った程度の人間には理解出来ないほどの技巧が詰め込まれている。それを理解する為の手法の一つとして、自分は「オレオレフレームワーク」、つまり自作のフレームワークを作ることで、MVCDB周りの処理の共通化・自動化などを「再実装」した。その経験があったからこそ、symfonycakephpのフレームワークを使うことになっても特に躓くことなく、フレームワークのソースコードを読みこなすことが出来た。

とはいえ、MVCやDBのテーブルの自動マッピングなどの概念を「再発明」したか?と言われればNOだった。特にイベント駆動のフレームワークであるXhwlayの時などは、アイデア自体はPieceProjectが既に実装していた。ところが、状態遷移について殆ど知らなかったためソースコードを読んでも理解出来ず、ならば自分で実装してみようと作ったのがXhwlayになる。なので「再発明」はしておらず、「再実装」したのがXhwlayになる。

というわけで、「車輪の再発明」の良し悪しについては「再発明」と「再実装」に分けて考えるべきで、「再発明」の対象というのはアルゴリズムデザインパターンプロトコルなどの概念的なもの、「再実装」の対象はそれを実際に動かす為のソースコード、と考えると分かりやすいんじゃないかと思う。

アルゴリズムやデザインパターン、プロトコルなど概念的なものは、再発明するよりは洗練された先人のアイデアを拝借した方が良いと思う。

そしてそれがどう実現されているのか、それを学ぶにあたり、既製のライブラリを参考に自分で「再実装」するのは色んな面から決して無駄なことではないと思う。

現場の話をすれば、ライブラリがあってもライセンス的に使えなかったりして、やむなく「再実装」する場合もあるし。

というわけで、十把一纏めにして「車輪の再発明は無駄!」と切って捨ててしまうのは良くないと思うな、という話(結局ケースバイケース)。

余談:以前zip圧縮ファイルについての調べ物をまとめた事があるが(技術/歴史/zip,gzip,zlib,bzip2 - Glamenv-Septzen.net)、圧縮アルゴリズムの世界はライセンスや特許の影響が大きい為、再発明や再実装のカオスという感じがある。だがこの膨大な車輪の再発明・再実装の積み重ねのお陰で、多様かつ豊富な圧縮解凍ツールが作られたのだから・・・あ、それを言いだしたらUNIX系OSからしてそもそもが、再発明と再実装の積み重ねか!!

[]車輪の再実装時の注意点

自分の書いたソースには過去の自分の見識しかなく、先人の書いたソースには先人の見識がある - 神様なんて信じない僕らのために経由、

車輪の再実装 - Life like a clown

1. 「既に誰かが実装しているはず」と言う疑いを持つ事

「車輪の再実装」を行うときに最も重要なのは,自分が車輪の再実装をしている事をきちんと認識している事だと思います.

同意。自分の場合、「自分が思いついた機能の8割は、世界のどこかで誰かが既に実装済。」というのを念頭に置いている。そして「残り2割」をどうしても妥協出来なくなった場合、再実装したりする。YakiBikiがそのケースだった。

「既に発明/実装済。」と言うことを知ってないと、「再」発明/実装なのかどうかすら自覚出来ないので、それは結構負担が高いなと。真似したいお手本が無い、そもそも真似なのかどうかすら知らない、というのはさすがに大変だと思うので、折角インターネット検索エンジンがあるのだからまずは探してみましょうよ、みたいな。

2. 「既存の実装には何かしらの意味があるはず」という意識を持つ事

プログラミングを理解する上でまずい事の一つに,自分の理解の及ばないコードに遭遇した際にそのコードを「ダメなもの」と決めつけてしまう,と言うものがあります.

自分も・・・最初の頃は、「俺が書いたコードの方がエレガントだぜ〜〜ヒャーハハ!!」となっていた時期があった。しかしやがて、

「なんでこんな訳の分からない実装になってるんだ・・・こうやった方が絶対に簡潔に記述できるはずなのに」と言う疑問にはたびたび遭遇します.しかし,多くの場合,必ずそれには理由が存在します.何かしらの別の問題が存在しており,それら全てを考慮した結果として,そう言う「めんどくさい」実装になっています.

ということを身をもって学び、謙虚さと敬意を払うよう心がけるようになった。(まぁ中には・・・「さすがにどんなに譲歩しても、これ、アウトでしょ?」と言いたくなるコードもありましたが・・・)

スティール・ボール・ラン」というJOJOシリーズの漫画でお気に入りの台詞を使うなら「レッスン4、敬意を払え」。

既に動いているシステムのソースコードで悩ましげな箇所に遭遇した時は特に。どんなに??なコードでも、曲がりなりにも動いている・使われている以上、誰かが苦労して開発したコードであることは間違いないのだから、敬意を払ってソースコードと付き合いたいものである。

2009-10-19

[]「とりあえずソースコード読んで仕様理解して。」「無理です。」

「とりあえず教科書丸暗記してテストで100点取ってきて。」「無理です。」

バカ正直に受け取ってソースコードを最初から最後まで読んでも何も分からなかった。

自分でシステムの特定部分に興味を持ち(きっかけは仕事で依頼されたからでも良い)、自分の手で資料を手繰りソースをgrepして現場の暗黙規定を周りに聞き回り、世間話に紛れ込ませた話の切れ切れから人間模様を想像し、システムの歴史を時間の許す範囲で遡り、それでようやく、何とかシステムのほんの一部を自分の血肉に出来る。「仕様を理解」して、「Why」に答えられるようになる。

「ソース読めば分かるだろう」という人は、大抵はそのシステムに長く(「長く」の程度は様々だろうが、少なくとも新参よりは長い)携わっている。

システムにどんな人が関わり、どういう経緯を経て諸々の機能が実装されたのか知っている。

例えるなら「漫画日本の歴史」「漫画世界の歴史」を読み込んでるようなものだ。人物関係や事の経緯・背景、一連の流れが頭に入ってドラマとなっているのであれば、教科書や文献資料は、正確な記述を求めるためのソースコードでしかない。

システムを理解する為に、ソースコードを読むよりは効果的な方法がある。取り扱うデータのデータ構造と状態遷移。それとコンポーネントの配置図。別にUMLでなくともよい。殆どの場合、それらは絵と図で構成されているだろう。そして、ソースコードという文章の羅列よりは余程脳に優しく、素早く浸透していく。

だから自分は、他人よりは多少、絵を描く。Excelで描く。大雑把でも良いので描く。言葉も混ぜる。ドキュメントは無駄じゃない(場合もある)。ソースコードは電子計算機プログラミングするものだ。対して仕様書・説明書・ヘルプマニュアルを始めとするドキュメントは、人間の(=読み手の)イメージをプログラミングする。イメージのプログラミングに効果的なのが、図と絵、表であり、その現場で標準となっている文書フォーマット(フォントサイズやヘッダーフッター・マージン、WordかExcelかなど)だ。

人月神話(新装版), フレデリック・P・ブルックス, Jr, ピアソン・エデュケーション

第9章 五ポンド袋に詰め込んだ十ポンド

(中略)

表現はプログラミングの本質である

(中略)

しかし、データやテーブルの表現をやり直す事で戦略的突破が実現される場合の方がはるかに多い。ここにこそ、プログラムの真髄がある。私にフローチャートだけを見せて、テーブルは見せないとしたら、私はずっと煙に巻かれたままになるだろう。逆にテーブルが見せて貰えるなら、フローチャートはたいてい必要なくなる。それだけで、みんな明白に分かってしまうからだ。

もし「とりあえずソースコード読んで仕様を理解して」と言う人がいて、真実、そのやり方で全く何の問題もなく仕事をこなしてきたというならその人は相当頭が良いに違いない。だけど自分はそこまで頭は良くない。弄って壊さないと分からないし、例え一部分を血肉に出来たところでその他大部分は闇の中だ。多分その人と同等までシステムを理解するには、半年から1年はかかるだろう。それだって、偶々仕事の担当上まんべんなくシステムを見る事が出来た場合で、担当の割り振りによってはずっとシステムの一部分しか知らなくても問題ない場合もあるかも知れない。

だから自分はとりあえず諦める事にした。勿論可能な限り調べて理解しようと努めるが、それでも漏れは生じる。

そうした漏れに対して、「なんで理解できなかったんだろう、気づかなかったんだろう」と自分を責めるのを止める事にした。

理解できないのが、漏れが生じるのが普通なのだ。ソースコードを読むだけで仕様を理解できるなんて、きっと余程頭の良い人間に違いない。上司は/リーダーは「とりあえず〜」と言ってきた以上は過去自分もソースコードを読むだけで仕様を理解してきたのだから、頭が良い人間に違いない。

でもだからといって自分を責める必要は無い。責めたところで頭は良くならないし。

もしそれが原因で仕事を解雇されたなら、自分程度の頭でも働ける別の場所を探すしかないけど。

頭が良くないから、だから自分は多少、絵を描く。Excelでざっくり描く。UMLのパチモンでも良いので描く。時には、真っ白な紙にお気に入りの黒ボールペンと赤ボールペンで書き連ねる。そういうやり方でしか、システムを把握できない。システムに対する認識が他者と相違ないか信じる事が出来ない。

図・絵・表を多用すれば、言葉を連ねるよりは余程他者の脳内に素早くイメージを構築できる。

救いは仏陀に求めるので、ご意見を乞う。