 
|
はてなキーワード: 設計とは
俺はコード書くのは好きで何時間でもやってられるけど、設計とか要件とか整理したりマニュアル書いたりするのはマジでヤリたくないよ。
そんなのコード書けないヤツがやれよとか思うわ。
今日は父方の祖父の命日です。
喪の作業が
全く進んでいないのだなぁと
痛感しました。
当時を回想してみて
改めて思った。
まだ、否認の段階、なのだと
☆
どうでもいいことは抜け落ちるけど
大事な特定のことははっきりと覚えている。
いや、大事なことがいつ起きても保存して置けるように
日常のどうでもいいことは抜け落ちていくように
設計されているのかもしれない。
９年前の２月７日、
そこそこ気にしていた朝を覚えているし
GLAYが「いつか」を歌っていた。
いつも一緒に部活の帰りを共にしている3人のうち、
Sくんはデートか何かが一緒に帰らずに
3人で自転車を漕いで帰った事も覚えている。
その帰り道、
いつもどおり部活をして夜にちょっと集まってゲームをしようという
約束をしていた。
そして、帰り、死去の話を一通り聴いたあと
楽しく興じていた。
不思議なくらいに、いつもどおりの楽しさがあったことを
覚えている。
今になって思えば、脆弱な心を保つための
躁的防衛だったのだと理解できるが
☆
もともとの高血圧だったこともあるだろうが
倒れてしまったとの事だった。
律儀で真面目な人だった。
そして、真面目さを強さとして昇華させている人だった。
他人を疲れさせるだけ。
なぜなら、柔軟性がなくて頑固なだけだから。
真面目な人と一緒の空間に居たら安らげないでしょ？
それでも、じいちゃんの真面目さは
圧倒的に優しさと強さを持っている真面目さだった。
多分に美化をしている可能性もあるが…。
☆
ただ、当日のことは克明に覚えているのだが
それからのこと、たとえば
どうしても思い出すことが出来ない。
いや、覚えているんだけど、
すごく限定的。たとえば、自分がどこに居たのかは
覚えているがそこで何をして何を話して何を行動したのかは
全く覚えていない、
それに当時の場面を思い返したときに主人公の視点で世界を捕らえていないことに
気づく。
「自分が居る空間を上から自分が観覧している」というイメージでの
自分から見た世界じゃなくて、自分がその場全体を見ている感じ。
これも離人とか解離とかっていう一種の
心的防衛なのだと、今になると思う。
そう考えると
当然のことなのかもしれない。
だって、意識は自分を上から見ている自分が持っていてしまっているのだから。
☆
どれだけ
「大切な人には伝えられるうちに愛しているって伝えろ」みたいな
ご高説をたれられても、やっぱり人間は
愛してるって伝えないんですよね。
どれだけ悲痛な別離や死別の話を聴いても
全く他人の痛みからは学べないわけです。
だとすると、できることはたったひとつ、
思いっきり後悔を背負って生きていくこと。
他人が身をもって示してくれた痛みに
耳を傾けても行動に移さなかった罰を受けるしかないのだ、と。
もしも人間が
他人の痛みから学ぶことが出来たのなら、
こんなにも悲しい物語は断続的に永続的に
津々浦々で発生するわけがない。
人間は
今を大切にすることなど出来ない。
失うまでは絶対に気づくことは出来ない。
その鞭と無能さの償いとして
後悔という消えない荷物を背負っていくしかないのだと思う。
ガチでメーラとWordとExcel,パワポ（しかも2003（笑））、teraterm、FFFTP位しかつかわねーからさ
あいつら本気でXP(笑）、メモリ1GBで足りてるとか思ってるからタチがわりーわ。
・コードがかける若手SE（笑）がEclipseとかMySQL、Oracle,Chrome,Firefox,IE,Java,.netと使うからある程度スペックが欲しい。(と言っても今時の５万で買える普通スペックで良い。。）
↓
・若手が新しいPC寄越せと要求
↓
・年食ったコードがかけないSE（笑）はOffice2003（笑）位しか使わないし、めんどくさいから要らないと抜かす
↓
・先輩がいいって言ってるのにお前らが要求するのか？とか言って取り合わない。
↓
・ほんとに必要な最前線の若手にまともなPCが行かない、その結果朝にパソコン起動してメーラとEclipseが起動するのに１５分かかる環境の出来上がりｗｗｗ
一方部課長以上の役職には全員Androidタブレットが支給され
お飾り部長には組織移行都度に新PCが卸される（結局何してるかもしらんがｗOfficeとIEしかつかわねーくせによｗｗｗ）
そりゃ社員がセットアップするし、何も入ってねぇから環境移行もし易いもんなｗｗ
もちろんAndroidタブレットはメール確認するくらいにしか使わないｗｗｗ
iPadやAndroidタブレットのブラウザ、メールをちょこっと触った位で最新になったと思い込むめでたい老害達。
そのHTML5とサーバサイドの開発するのは俺たち若手SEなんだがなｗｗｗｗ
でも結局使わないし飽きて部長のタブレットは机の中に入れっぱかおきっぱ。
クラウドクラウド、SalesforcrSalesforce
クソウォーターフォール維持しながらスピード感がとか寝言ぬかしてんじゃねーぞｗｗヴォケが。
上の承認が～承認が～って要件定義が～ってお前らクソ共の承認があってスピードも何もねぇだろうがｗｗｗ
その上テストドリブンしようとすると、要件が固まってないだろ！とか抜かすし、殺すぞ。
結果アホ共が思いつきで言い放った言葉は忘れない
SalesForceのパンフレットに開発は１月を目処に実装する、みたいな文言を間に受けて
え？じゃあ、プロトタイピングとかテストドリブン型とかでやるの？とか聞くと、
いや、客の要件をしっかり聞いて要件をしっかり洗い出して～上司の承認をしっかりと得て手戻りがないように～とか抜かすｗｗｗｗｗｗ
おい、お前それ今までとかわらねーじゃねーかｗｗｗｗｗ
あーいうのは少人数チームで全員が開発者としてプログラムが十二分に書けて仕様書とかの書類を最低限にして
要件定義や決定権限の大部分を現場に委任して優先順位の高い項目からを集中してやるから出来るのであって
日本のほとんどのアホSI企業の典型的なコードの書けないExcel書くだけの御用聞きSE（笑）なんて邪魔以外の何者でもないｗｗｗ
そんなゴミSE（笑）が多くを占める会社で出来る事じゃねーんだよｗｗｗｗ
あーいうゴミ共は居るだけでどーでもいい好みでの文句をグダグダいうから余計に作業が遅くなるｗｗｗ
こういうクソみたいなことばっかりやってるから古い日本企業はダメなんだよ、ゴミどもが、さっさと潰れろ。
そして俺はクソSI業界を見限ってソーシャルゲーム業界に転職準備をしているのであった（完）
http://anond.hatelabo.jp/20120207005408
まなめはうす恐るべし
ちなみに私のPCのスペックはPen4 1.6Ghz メモリ1GB HDD 30GBです。
これでメインはJavaのStruts2とSpring Eclipse3.7で組んでます。
これより低い奴出てこいや…
とりあえず一部間違えていたので訂正ｗｗｗ
１．HDDは37GBでした。ごめんなさい、実際に見てみたら間違えてました。でもいつもSVNチェックアウトするときとかデカイzipを落とす時はいつも何か消してからしています。
２．ケースはチェーンで鍵がかけられているので開けられません(^p^)よって自分での拡張は不可
後、時々あった。
PGなんてのはゴミがやる仕事だからそんなの気にかける方がゴミ
とか
とか
コードを書かなきゃいけない時点で大手ではない
ちなみにT○SとかI○M、NT○の人もコード普通に書いてたよ。
ってか書くとこは書くでしょｗｗ
んで上みたいな考えの人はそれで構わないでしょう。
そうやって思っててコードやプログラム部分なんてどうでもいい。
フロントエンドやバックエンドが発達しても設計書レベルや提案レベルに落としこむ場合に実コードの知識なんて影響しない思うならそれでどうぞって感じ
いつまでも何でもバッチ処理（笑）にこだわる人も良くいますしねｗｗｗｗ
私からしたらいつまでコードの書けないSE（笑）が成り立つか逆に聞きたい位ｗｗｗ
ま～コードがかけないSE（笑）からいつも馬鹿にされてるのを知ってるから、コードがかけるSE（笑）はどんどん逃げてっているんですよね～
わざわざプログラム（笑）とか馬鹿にされてまで居るものじゃねーよｗｗｗ
現在どんどんSI業界から出来る人が率先して辞めてるからｗｗｗ
ただでさえ人材不足のクソSI業界にいつ影響が表面化するか（もうしてるか？）楽しみですNE!
私は先に役に立たない大量の船頭しかいない泥船から抜け出しますｗｗｗ
戻って来ることもないでしょう！多分！
それではアデュー！
犯罪の弁護人は、世界で全員を敵に回そうとも被告人の味方であることを求められる。こんな厳しい仕事を進んでやる人が一人でもいるから、裁判の正当性が担保されるのだ。それを理解していない筈はない。単純にポピュリズムというか、衆愚主義にのっかって(群集の快感原理に訴えかけて) 弁護士会への懲戒請求を煽る。
http://www.sponichi.co.jp/society/news/2012/01/28/kiji/K20120128002522420.html にもあるが、結局の所教育問題ってのは誰でも口をはさみたくなるが故に、しばしば間違っていることであっても「正しい」という信念のもとに正当化される。しかし、教育を左右するというのは国の基礎を左右している、という責任感はあるのだろうか(私には全く感じられない)。建っている建物の基礎を変更するんだから、ドラスティックに変更したら、いくら設計図が正しくても工程管理のミスで家が引っくり返ることがある。ましてや、その棟梁が選挙で選ばれる(すなわち、継続性が保証されない)政治家だと言う。
短期的に見ればミクロな世代間格差や想定していない副作用でおかしなことになるだろうし、長期的に見れば右に左にゆさぶられた教育の現場がぐだぐだになるだろう。教育改革は1つのサイクルすら5年、10年という長丁場の覚悟がないと、本来は為しえない難事業なのだ。どうしてもドラスティックに変えたければ、特区や特定校指定などといった「離れ」でまず実験をすべき。これは、別に教育に限った話ではなく、生きているシステムは全てそうだ。
#竜馬とたけち#
身分制度に疑いを持たないため、将来彼を自分の手足として使うことを当然と考える武市と
そもそも身分制度に頓着がないため、純粋な友人として見ている竜馬の違いは大きいのう
#大村益次郎の知恵#
「竹竿台場も江川台場も役に立たぬ意味では同じです。画餅にすぎぬ。
もともと実現不可能なものを命じられているのであれば、幕府に差し出さねばならぬ図面や設計書もうんと立派なものにする。
図面さえ出しておけば幕府は安心し納得する。５～６年以上かかる大工事の計画書でなければいけません。
なに、心配入りません、3年待たずして必ず状況は変わります。程無く幕府も砲台設置は無意味と気づくでしょう。」
「吉田寅次郎はアホな人ですね。
天下の佐久間象山に就いておきながら、なぜ蘭学を学ばない、なぜ科学を収めようとしなかったのか！
蘭書を読み科学を学べばわざわざ命を捨ててアメリカに行く必要はない。」
あの船の動力室を見れば、西洋の合理主義もオランダの国力も手に取るようにわかる。
→多分これが可能なのは佐久間象山と大村益次郎のふたりだけで、
吉田は日本の中ではとても優秀ながら、これが出来なかった、というか普通できないから海外に行こうとした。
子供の頃から山鹿流を極めて、外国と合戦するという視点に囚われていたから
逆にそれをUnlearnするのはなみたいていのことじゃ難しいというのもあったと思う。
大村益次郎や福沢諭吉レベルの合理性というのは、なかなか難しい。
しかし吉田松陰は合理性の鬼ではないどころかその逆に非常に忠義や友情と言った人間的なものに強かったから
教育者としては短い人生で歴史に名を残すほどに多くの人に影響を与えているというのが面白い。
大阪には、庶民のためにここまで命を投げ出す人がおったんか、と何やら胸が熱うなったな。
それまでわしにとって大阪は出世前の足場に過ぎず、いずれ若い頃学んだ江戸に戻って一旗揚げるつもりやったんやが
何やしらん、大阪の町と底で暮らす人々が愛おしゅう思えてきてね
「この土地に骨をうずめるのも悪うないか」と思って、大阪で異形を開き、適塾をスタートさせることにしたっちゅうわけや。
アヘン戦争が最も愚かな戦争であれば、こちらは戦争と呼ぶのもおぞましいヤクザのゆすりたかり。
アヘンで荒廃した国を蹂躙し、さらに絞り足りぬといえに土足で入り込んで略奪放火までしていくとか。
勝利後の条約がまたひどくて、お前紳士の国とかそれ歴史の教科書見ながらいえんの？レベル。
（ただ、当時の補給線・調達や、兵隊の編成事情を見ても多少は納得する部分もある。
アングロサクソン系はもともとどうしようもない野蛮人であり、それをよく知っているからこそ
自分を律する啓蒙主義みたいなのも流行ったんだと考えると、今やたら紳士ぶってるのもわからんではない
特にロシアの領土拡大・不凍港獲得は、開国後の日本を威圧することに。
→アヘン戦争とか見てると、本当にこの当時のゲスでヤクザなイギリスを相手にしないためにも
鎖国というのは全く不合理ではなかったかも、と思えてくるから困る。
当時のイギリスのゲスさ強欲さ残忍さなどどれをとっても、松前商人をはるかに上回るレベル。（ただし頭も良いから余計たち悪い）
（日本が侵略されなかったのはこちらを食べつくすのに忙しかったからと、日本はそれほど旨みがなかったから、なんだろうか）
→にも関わらず、イギリスはなぜか日本に対しては国と国としての対応をシてくれている。（フェートン号事件をはじめ３件くらい海賊行為があったけど）
実際オランダと同じように、軍艦を一隻無料で寄贈してくれたりとよくわからない。
オランダやロシアとことを荒立てないみたいな駆け引きがあったんだろうか・・・なぜ他の国も辛抱強かったんだろうか、とかいまだによく分からない。
実家に帰るといつも「～の背後にはCIAが」とか「地震兵器が！」とか「統一教会が！」とか「在日が！」とかいうの。
で、「その証拠は？」と聞くと、返答は以下のパターン
「証拠がないのがやつらのすごいところ」
「確定的な証拠を待っている前に状況証拠で判断して動かないと」
「証拠を求めすぎるのが現代の流行だな」
やってらんないのだが、家の設計上居間にPCが置いてあってその前に陰謀論者が鎮座してる。
でトイレ行くにも玄関行くにも風呂行くにもその居間を通らないとダメ。
「こないだ俺が言ったこと思い出していってみろ、テストだ」とか
「どうして俺の言うことがわからない。家族だったらわかるだろう」とか
別の家族は気が小さいので、俺みたいに時折反論したり
無視したりできない。
家族として、どうやって好きになってコミュニケーションとればいいのかわかんないところだよ。
俺がいろんなことに疲れて、実家で少しくつろごうとしてもそんなのに付き合わなきゃいけない。
こういう人ってどうすれば強引な陰謀論を人に伝えなくなるんだろうか。
関連書籍でも読んでみるか
村田蔵六にその才を見出された嘉六であったが、
提灯張替えの職人に過ぎぬ最下層身分の彼が長崎で味わった苦労と屈辱は並大抵のものではない
・まず嘉蔵のためについてきた御目付役が嘉蔵を自分の下男として扱うのである
（この当時、能力があっても、身分が下であるというだけで敬意を払われることはないどころか見下される）
さらに身分はその役人の「中間」よりも下だから食事も何もかもが中間以下の待遇に甘んじるほかない。
・それでも嘉蔵が幕府の通訳や蘭学者にあって色々学ぶためには、この役人にお願いして連れていってもらうしかない。
理解能力がゼロの役人に土下座し、頓珍漢な取り調べを受け、たいして役に立たない取次しかしてもらえない。
それでいて、いざ蘭学者と接する段になると役人は役に立たず、嘉蔵の下働きをすることになる。
下働きといっても、現在の感覚であれば能力が嘉蔵の要求にこたえるため西に東に走りまわるところを想像するだろうが
江戸時代は身分があるから、嘉蔵が土下座して役人に紹介状などを書いてもらうことになる。
それでも当時の身分意識から役人は「嘉蔵に使われている」という気分になるから、必要以上に嘉蔵につらくあたる。
しかしこれで蒸気船建造が失敗すれば役人の責任にもなるから、嘉蔵の願いは結局聞いてやらねばならない。
役人は役人で、散々いじめながら身分意識の概念に囚われてストレスを抱えているという状態だった
→江戸時代は、安定という名の「怠慢許容・推進システム」が恐ろしいほど機能してたわけだな
身分が上のものしか学問をしてはならぬ。しかし身分が上のものは学問しない。
おお、時代が発展しないから努力しなくても身分は維持できる。やったね！まるでいまの○○○○みたいだ！
→そんな悪循環と貼りのむしろの中、目付も中間も寝静まった夜中に懸命に蒸気船の研究を続ける嘉蔵であった。
何のために長崎でこんな地獄の日々を送らねばならないのか、と時に思わないでもなかったが
そのたびに頭に浮かぶのは、オランダ船スンピン号の動力室であった！
嘉蔵は苦労について蔵六に述べることなく、蔵六とは設計の打ち合わせを行い、
その後何度か長崎に行き、そのたびに辛い日々に耐えることになる
好みが自由になれば幾度でも同じ事をします。
もちろん正気では怖くてこのようなことは言えません 私は狂人でありたいのです
しかし私の行動は周囲に迷惑を及ぼします 同志の金子くんもそれで死んでしまいました
しかし怖いとか悲しいとか言うのは私事です いつまでも泣いてはいけないのであります
私は長州藩を いや日本国全体を考えねばならないのであります！
私はこうして入られない 皆さん何かしましょう
みなさん学問をしましょう ここには私達がいるあなた達がいる 互いに教えあおうではありませんか
人と人の出会いほど尊いものはありません 私には知らないことがたくさんある
みなさんはひとり残らず私の師匠です！
悪口がお好きな人だと聞き及んでおりますが、他には何がお得意ですか？
字が得意？それはすばらしい。ぜひ私に書を教えてください
旅の経験がある人は、旅の話を教えて下さい
そうすれば私は獄舎にいながらしてあらゆるところにいけるのであります
同じ怒りが心の方向で全にも悪にもなるのです。
みなさんは言葉だけで行動しない牢の外にいる人達よりも君子たるべき素質も資格も十分備えている立派な人なのです
あとはその心を正義に向けましょう。自分のためだけでなく人のために戦うとき小さな殻を破れるのです
みなさんはあと一歩の人たちなのです！
いちおうフォローしておくと
大規模SI,SE会社でも 部署によってはコードリーディングから始める部署もあるから 会社名というより部署名。
同じ会社でも ビルやオフィスが違うと 設計＝なんちゃって設計 だったり 設計＝コード読めるだったりする。
その辺が 大規模会社の 問題点かと思う。 できる部署もできない部署も 同じ会社名でよばれるからね。
それで、いや会社に出したんだから会社として責任取れよってお客さんは思うけど、そんなん別部署だし。
NTTや東芝程の大会社ともなれば、部署が違えばもはや別会社。
その辺を踏まえて 設計を発注しないとお客さんはあぶないとおもう。
そうはいっても、 設計＝コード読めるレベルの人は高給取り確定で そこらの小さな会社にいるかと言われると・・・
というレベルだし、やっぱり大企業に出すしか無いというのもまたけっこう真実だと思う。日本の場合。
んーそれが現状のITは上流はろくにコード読めないのが当たり前になってる
http://el.jibun.atmarkit.co.jp/karyu/2008/10/sepg2-0e2d.html
http://d.hatena.ne.jp/ryoasai/20120125/1327501906
本当はあなたの言うとおり、設計するならそれについて知らないといけないのが当たり前なんだけどそうじゃなくなってるのがおかしい。
簿記会計の処理するために 自分自身が簿記できるくらい勉強する のは 設計に入るし
デザイン周りの処理するのに 簡単なデザインできるくらい勉強するのは 設計に入るし
プロ並みにとはいわんが、業務知識があって、それをベースにそれぞれのプロとコミュニケーションして設計するってのは設計の基礎。
既存システムの巻き取りで、死にながら既存システムのコードを読んでコードレベルで、旧設計を理解するのも設計の基礎
って思ってる俺は間違ってるのか？
（俺自身 大規模設計の時はそれをやるので、最初はプロと作って業務知識を担当者に教えてもらうところから始める）
設計だけの設計がなんか、半完成のプラモを組み立てるみたいなことをイメージしている気がした。（それ設計違う）
例えが違うかもしれないけど、楽譜が読めないけど指揮者なら出来る、みたいなことをいわれても、指揮の前提には、楽譜が読めて、総譜を暗記していて、その次に指揮ってのがプロでしょ？指揮しかできない。っていわれたら、普通は楽譜は読めるのが前提だよね。一般的には。そうじゃなければ、指揮の真似で棒を振るしかできないという言い方になると思う。
http://www.asahi.com/business/update/0124/TKY201201240616.html 24日のニュース
http://www.meti.go.jp/press/20100820003/20100820003-2.pdf その発端ともいえる二年前の報告書
始まりは、ありがちな汚職だと思えた･･･その巨大プロジェクトの実体は！
1部～2部で内容が重複してるから、ストーリーだけ知りたい人は3部から読むのをお勧めする。図表もあるのでわかりやすい。
これについてのブコメやTwitterを見ていると不祥事を叩いたり、やめた事を批判して55億賠償しろって人も結構いるのだけど、なんかもうそういう問題よりも気になる点が山ほどある。自分の感想をまとめておく。不祥事そのものより、その裏にあるプロジェクト全体や日本の開発にありがちな問題にもっと注目されて欲しいのでそういう視点で書く。
入札前の情報漏れにしても、その後のNTTDとのやりとりにしても、情報漏洩やそれにまつわる金銭の動きは犯罪だ。けどもそれが行われた動機が私利私欲のためだけとは思えない。
共有されるべき情報が共有できるようにされていない。やりとりできるべき情報ができるようにされていない。必要な情報がちゃんと流れていないから、イレギュラーな方法で流れている。特許庁, NTTD, TSOL この三社間のコミュニケーションがどこも投げやり丸投げ気味で、慢性的に情報不足だった感が伺える。ここを改善する必要があるよね。
極秘情報は必要最小限にして、より情報の共有を図るべき、入札前に必要な情報は公開できるようにすべきって報告書でも書かれている。
入札での評価が金額偏重で、マネージメント力を評価してなかったって問題。マネージメント力を評価してないのマジやばい。あ、でもマネージメント力を評価するには、全体を理解できる人材が必要だよね。で、次の問題に繋がるんだけど。
報告書だと、上流の話しか出てこない。だから、｢設計もろくにできないで55億無駄にしたのか！｣って話になるけど、ちょっと待って。設計しかできない人間が山ほどいても捗るわけがないってことなんだよ。特に、このプロジェクトは既存システムを0から作り直すのだから、既存システムをよく理解して、また既存システムにかかわる技術者とよくコミュニケーションが取れて、それを設計に正しく咀嚼できるスキルの持ち主が必要で、設計しかできない人材ではなく全体を理解できる人材が必要だったはず。
既存システムをちゃんと理解できてない人間だらけになったということが報告書でも繰り返し指摘されてるけど、その根底には設計しかできない人間が山ほどいても捗るわけがないという問題があると思うんだ。
6年？そもそも設計に数年ってのが、もうそういうの無理が来てるって感じ？6年経つ間に色々変わっちゃう。
どうしても、がちがちのウォーターフォールでやるなら、もっと受注も小分けにして、まずは既存システムの仕様まとめプロジェクトから開始するのが良かったんじゃないかな。
6年まとめてどん！だと中断の決断もなかなかできないよね。
これだけプロジェクトが炎上していたのに、汚職がきっかけで調査が入るまで炎上がちゃんと認知されていなかったというのがやばくね？もし汚職が見つからなかったら、炎上のまま･･･
これは国のプロジェクトだから汚職で厳しい調査が入って、プロジェクト炎上まで色々赤裸になったという見方もあるかも。民間だったらもっとなし崩し的に炎上プロジェクトを続行するケースが多いように思う。
もうね、
ＴＳＯＬによる設計作業は ，平成１８年当初６０人体制でプロジェクトをスタートさせたが，翌年初めには遅延が 始まったため，順次増員を行い，同１９年３月には２００人，同年５月には４５０人体制とした。
(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
ＴＳＯＬは ，工程の遅れの解消に向けて，大幅な人員の増強でこれに対処しようとし，平成２０年１１月以降に は １３００人もの体制を整えたが
(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ
あたりまえのこと。TSOLでも仕様をしっかり理解してる人は少数だったのに、増員の9割は下請けだったのだから、さらに破滅の様相が想像できるってものだよ。
大量の下請け同士の連携や情報共有がされていなかった。経験やノウハウの共有がなされていなかった。と報告書にある。なんでこうなっちゃうんだろうな。何のためのプロジェクト管理なんだろ。ノウハウの管理はもっと意識されるべきだよ。
人数増やしてプロジェクトが炎上するというのは、お約束すぎる。規模の大小や分野にかかわらず、開発をやった事のある人ならわかると思う。
開発や設計って？という人にもわかりやすいように説明する。
例えば、優れた売れっ子のマンガ家がいて、老練な担当者がついていて、名アシスタントがいて、才能ある若手アシスタントがいて、10人のチームでマンガを描いていたとしよう。一方、大して技術もない凡人を100人集めて、前出のチームと同じマンガができるとかと聞かれたらどう思うだろう？殆どの人はそれは無理じゃない？と思うだろう。1000人でも無理かもしれない。
開発も同じなんだよ、本質的にはね。
でもそう思われにくいのはなんでだろう？それは多分、開発に従事する人にはマンガ家のような才能や際立った技術は必要ないと思われてるからだ。言われた所を言われたようにベタを塗るだけがプログラマの仕事だと思われているからだ。実際それをプログラマなのだと定義している会社もある。技術はお金にならない低俗なものだという偏ったイメージもこの世界には蔓延している。それが上流偏重の問題なんだ。
売れっ子のマンガ家のような設計(マンガで言えばネームや原作)からプログラミングまでこなせる技術者、老練な担当者のようなプロジェクトマネージャ、名アシスタントのような匠のプログラマ、勉強熱心な技術者は実際に存在してる。並以下の人材を倍集めたって100人集めたって彼らと同じものができるわけじゃない。
でも、どんなプロジェクトにもそんなスター的な人材が確保できるとはいえないし、単純な増員で対応できるようにする必要が、日本の大きな会社や大きなプロジェクトではあった。それを可能にするのが分業化だ。工程を徹底的に分業化することで、末端のセクションの習得コストを出来る限り低くし、品質の維持も図る。言い方を変えれば、創作を出来る限り製造にするということ。
それによるデメリットは明確だよね。新しいアイデアが実現されにくくなる。時代の流れの速さに追いついていけない。個々の持っているスキルが生かされない、技術が評価されない。技術者のモチベーションが下がる。なにより、正しい分業化とマネージメントが行われずに盲目的に人数を増やすと、ただただ炎上にしかならないってこと。お金だけが莫大にかかっていくということ。
これは間違いない。
このまま続けていたら、沢山の技術者の尊い人生がデスマに捧げられただろう。数年間のどろどろの煮詰まった成果物は、黒歴史を語るまいとひた隠しに、更なる問題を生み出しながら使われ続けただろう。考えただけで悪夢だ。
このプロジェクトのやりなおしに、どれだけ前回の経験が生かされるのか、そこにこそ注目していきたいと思う。
時間ができたら後で読む
http://www.jpo.go.jp/torikumi/system/system_optimize_re.htm
実際の業務の内容がある
http://myatsumoto.hatenablog.com/entry/2012/01/26/082554 良いまとめ
まあ有利な条件で出て行ければ出て行ったほうがいいかもね。
でもさ、首都圏での震災って、俺たちが生きている間にはほぼ確実に起きるわけじゃん？
これくらいは将来の予定として織り込んでおくべきだと思う。
まず、震災による直接的な被害だよね。
死んでしまったり怪我で障害が残ったり、身内がそうなったりの危険がある。
持ち家なら家が倒壊・焼失する可能性もあるし、そうでなくても家財を失うこともある。
次に失職のリスク。
勤め先によってリスクの多寡は違うけど、震災を理由に首を切るところも出てくるでしょう。
そのとき大勢の人間がいっせいに失職するわけで、その中で新たな就職先を見つけるのは本当に大変だと思う。
正直、そんなリスクを抱えるくらいなら、今のうちに近畿・中京あたりに逃げて仕事を見つけておいたほうが、国外へ移住するよりハードルも低いし、よほど安定した将来設計が組めると思うのだが、どうだろうか？
Python vs Ruby vs PHP vs Haskell プログラミング言語バトル part1
http://anond.hatelabo.jp/20120118220204
Rubyistってなんであんな小学校の図書室で毎日読書してそうな
顔面オジサン、オバサンばっかなの？
Scalaer: 鼻持ちならない、モヒカン
Lisper: マジキチ
Rubyist: ネクラ、オタク、キモメン、いじめられっこネクラチビメガネ、色黒、キモオタ、顔面オジサン、オバサン
Rubyのブロックが便利すぎて、Pythonをやめたくなった。
いちいちtemporaryな関数を作成してから目的の関数に渡していたのがばからしくなった。
リストやジェネレータ式の内包表記が便利過ぎて
どうせ廃れる。
609
＞リストやジェネレータ式の内包表記が便利過ぎて
おれもそう信じてたけど、Rubyの、メソッド呼び出しを続けて書けるほうが便利だわ。
まるでjQueryみたい。といってもjQueryのほうが後発だけど。
たとえば「xsから0以上のものを選んで、その二乗の和を求める」場合
sum([ x*x for x in xs if x > 0 ])
これだと、後ろから読まないといけないんだよね。でも
xs.select{|x| x > 0}.map{|x| x*x }.sum
これなら頭からひとつずつ読めばいいから、わかりやすいし、考えたとおりに書きやすい。
まさにスクリプトって感じがする。
Python: [[x,y] for x in xs for y in xs]
Ruby: xs.map{|x| xs.map{|y| [x,y] } }.flatten(1)
いっぽうメソッドチェーンは
orz.sage().hage().hoge().hige() タイプの問題には向いている
つまり向いている方向がちがう
(まあHaskellなら hige . hoge . hage . sage と書くだけだというのは置いといて）
強い弱いということで言うと、問題を解くのに必要な一番能力が弱い
（限定された）道具を使うという考え方があるようだよ
ベタ再帰は強い（汎用的）、がそれゆえ読むのに注意を必要とする
foldrは再帰よりは弱いが、foldrで表現可能な問題のクラス（原始再帰）はかなり
広いので、mapやfilterで済むならもちろんそのほうが望ましい
ではこの問題は弱いmapやfilterを結合させるほうがいいかというと、
俺はlist comprehensionのほうが集合表記そのもの=whatを表現していて好きだな
Pythonのlist comprehensionのsyntaxはあまり好きではないが
それは大きな問題じゃない
メソッドチェーンってバグをわかりにくくするだけだと思うなあ。もちろん性能面もあるし。linqとかは良いと思うけど。
同じメソッドチェーンでも、linqなら良いけどrubyなら悪い .....
一言で言うと「俺はRubyが大嫌いなんだぁーー」ということですな
内包表記は構文でサポートしないと難しい（マクロがあれば別だが）
メソッドチェーンが関数型の方法に比べて特に優れている点があるようには思えないが
パイプ順に書きたければ書けるし
680,663
Pythonには関数型として致命的な弱点があるから、メソッドチェーンでは簡潔なコードが書けない
たとえば「(1) Rubyは 条件判定が(文ではなく)式」だから以下のようなコードが書ける
if test
if test_1 then test_1_1 else test_1_2 end
else
if test_2 then test_2_1 else test_2_2 end
end
}
あるいは「(2) Rubyはブロック内で局所宣言が可能」だから上のコードを以下のように書き換えてもいい
cond_1 = if test_1 then test_1_1 else test_1_2 end
cond_2 = if test_2 then test_2_1 else test_2_2 end
if test then cond_1 else cond_2 end
}
関数型言語であれば「(1) 条件判定(if/case)が式」で「(2) 局所宣言(let .. in .. end)が可能」なの当たり前
ところが残念な事に、どちらもPythonには欠落しているから、上の例はストレートにコード化できない
だからPythonではメソッドチェーンは使われないし、「酸っぱい葡萄」に見える
Rubyでもリスト内包表記が言語として組み込まれてくれると嬉しい
だと思う
頭に浮かんだロジックをすばやくコード化するのはメソッドチェーンが適しているし、
じっくり腰を据えてコード設計するならリスト内包表記のほうが美しい
自分は、たぶんこのスレもRubyコアの中の人も見ているだろうから
そのうちRubyにもリスト内包表記が実装されるんじゃないかと期待しているw
メソッドチェーンは書き易い
内包表記は見た目が整ってて綺麗、最終的な型がわかり易い
いじょ。
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
前記事
http://anond.hatelabo.jp/20120108211250
■「呪い」はツールで封じるべき
http://anond.hatelabo.jp/20120112030008
まとめると、はてブのコメントが偏りすぎると(はてな的に)困ったね、という話でした。
で、ここからがやっと本題です。じゃ、具体的にどうするのって話です。
まず、誰もがわかりきっていることですが、すでにはてなブックマークは価値ある情報を共有するブックマークとしての利用者ばかりではなく、記事やページに対するレビューというか批判や皮肉を投げ捨てる場として使うユーザーと混在している状態なわけです。「どうでもいい」と思っていることにすらブックマークしてひと言皮肉を言わずにはいられない人も世の中にはいるのです。宝箱とごみ箱がごっちゃになっているわけで、まずこの両者をはっきりと区別できるようにすべきです。
そこで、参考にしてほしいのはAmazonのレビューです。個人的にAmazonのレビューの情報設計の素晴らしいと思うところは、レビューそのものに対する「役に立ったかどうか」の評価軸の他に、商品に対する「評価の高いレビュー」と「評価の低いレビュー」を対立軸で並列させている点です。これをはてブにうまく適用すれば、その記事に対する否定的な意見と肯定的な意見のどちらが多いのか一目瞭然になる上、どちらの意見も有益な情報を拾えるようになるわけです。
つまり、
・現状はあまり機能していないページの評価に対するスターを改善し、「お気に入り度」のような形でブックマーク時に5段階でページを評価させるようにしておく。
→これで今まで曖昧だったページ自体の評価がはっきりする。
→デフォルトは★３つにしておけば、面倒な人は入力しないでいいが、全体のコメントには反映されにくい。
・ページへの評価が低いユーザーと高い評価のユーザーを並列でコメントの評価順に並べる。
・評価とコメントが矛盾しているようなユーザーも出てくるので、ユーザーコメントに対する評価やランク付けも今までより厳密に、匿名でプラス評価とマイナス評価で行う。
・さらにホッテントリは徐々にページ自体の評価を基準としてブックマーク数と合算してポイント制に移行すればいい。
基本的にはこれで全然違ってくると思う。まぁ、Twitterと同期させたことで、はてブも閉鎖されたコミュニティでなくなりつつあるので、新しい血を入れる、ということも引き続き進めていきつつ。あと、話がずれるけど、増田にツイートボタンやいいね！ボタンを置いたのもいい対策だと思う。増田に関して言えば、これではてブの偏りがより明確になった気がする。で、他のコミュニティにも拡散された後で、大勢が変わってくると、一部の「ズレた」ことに気づいた初期段階でコメントを残したはてブの人たちは、空気を読んで自分のコメントを消したりする非常に香ばしい状況も垣間見れたりするわけです。
これを増田に書いた意味については面倒なので問いたださないでください。
そんなわけで、はてなには引き続きがんばっていただきたいです。
周辺物件に比べて、割安で、中古での値上がり率が一番いいらしいです。
「丸紅は大手商社だし、それは素晴らしい。いいんじゃない」って安易に考えてませんか？？
そうなんです。そこには裏があるのです。
よくよく、建設予定地、近隣の状況を見て下さい！
六義園周辺の予定地（不忍通り、日本医師会前）なんて、とてもひどい状況です。
不忍通りの道路拡幅事業を逆手に、将来、既存不適格になるような計画を
近隣の反対を押し切り、無理矢理に進めています。
既存不適格になるような物件であれば、将来どうなるか分からない。
もし何かトラブル（例えば直下型地震があり建物が損壊した場合など）が
あれば、既存不適格のために修復もできない状況になるかもしれません。
のべ床面積をぎりぎりのところに設定されている。
悪巧みの想像力は素晴らしいのに、協調的、未来志向的な想像力にはとても欠けている。
総合商社ってこの程度の交渉力で、身勝手に計画を進めるのですね。
近隣の住民は、既存不適格にならないような計画に変更してくれれば、
このような反対をすることはしないと言っているそうですが、
丸紅は少しも譲歩する気配はなく、利益のために設計変更はできないとの一点張りだそうです。
ここはどこなんだろう？土地の強制収用しているどこかの外国なのか？と思ってしまいます。
あーそうか、丸紅は商社で、どこか外国で商売をやっているのと同じ感覚なのか？
それとも、マンション開発は本業ではないので、窓際の人達に好き勝手やらせているだけなのか？
最近の大手(三井、三菱、東建、野村、東急)は、既存不適格などには敏感で、
ブランドイメージが落ちるようなことは決して手を出さないという話を良く聞くのですが、
グランスイートシリーズをブランドに育て上げようという考えはなく、
逆説的にいうと
そのようなブランドイメージとか本筋で勝負しても勝てないから、
それにしてもたちが悪い。
売ってしまえば将来どのようになっても関係ない。
今現在、合法であれば上質な住まいなんだという、売り手感覚が許せない。
例えば、電化製品や車の不具合があれば、すぐにリコールになるのに、
さて、どのような方向に進むのか・・・。
いつも抽象度が高くて不満が残る作者だが不満があるけどこれはかなり実用的
フォークの歯はなぜ四本になったか 実用品の進化論 ペトロスキーシリーズ面白すぎ
ヨーロッパ史における戦争 (中公文庫) - マイケル ハワード おもしろすぎワロタ
有事対応コミュニケーション力 (生きる技術！叢書) - 著者陣が嫌いな人ばっかだけどタイトルが魅力
ためらいのリアル医療倫理 ～命の価値は等しいか？ - 岩田 健太郎 -内田樹押しなのがやだけど魅力
かかわり方のまなび方 - 西村佳哲
自分をいかして生きる (ちくま文庫) - 西村 佳哲 最近はまってる西村先生シリーズ
クルセイダーキングス デウス ウルト【完全日本語版】 むずい
変われる人 8000人のキーパーソンと会食してわかったこと - 鮒谷周史;
あなたは、なぜ「自分に似た人」を探すのか――崩壊する「大衆」と台頭する「鏡衆」
文明論之概略を読む 上 (岩波新書 黄版 325) - 丸山 真男 立ち読み一覧
資本主義と自由 (日経BPクラシックス) - ミルトン・フリードマン
「新訳」乱気流時代の経営 (ドラッカー選書) - P・F. ドラッカー
新訳 見えざる革命―年金が経済を支配する (ドラッカー選書)
JavaScript って生き物っぽいって思ったのがきっかけだった。
なんか菌？に遺伝子いれてたんぱく質を生産させるやつ？ Function は菌の細胞膜で prototype は遺伝子で、だから prototype に全然関係ない違う生物の遺伝子を生きてる菌に入れちゃったり。そうすると全然ちがうたんぱく質が生産されたり。prototype にべべーっとコピーして追加するのなんてまさしくそれっぽい。
だってプロトタイプベースって、生き物しかいない世界じゃない？基本的に。インスタンスってのは生き物じゃない設計図があってそれにしたがって出来た生き物がインスタンスってイメージあんだけど。プロトタイプベースの世界にはそんな設計図も生き物じゃないものもないよね？なのにわざわざインスタンスっていうのに何か違和感？ご都合主義的なもの感じる。クラスは型で、インスタンスを実体だとかなんとかって氾濫してるせいかな。多分この辺の用語が JavaScript をわかりにくくさせてる気がする。
僕の感覚では、オブジェクトってのは生き物で、クラスベースってのは神が設計図に基づいて生き物を生産してる世界で、インスタンスベースってのは生き物が生き物を複製してる世界のイメージだ。多分、原始の生物はインスタンスベースみたいな世界で、海の中にうようよしてたんだろうな、とか。
オブジェクトじゃないものは、生き物じゃない死んでるたんぱく質や RNA の破片みたいな。それだけじゃなにもできないみたいな。それだけじゃ命がないから、生き物の殻に詰めるってのが JavaScript のコンストラクタのイメージ。
Perl の bless したらこれはもう命入ったよ生き物だからねっあとは勝手にしてねってのも、Python の名前空間さえあればなんとかなるよねってのも、JavaScript のハッシュさえあれば世界作れるよねってのも、みんなどこか似ている。ちゃんと OOP を理解できてるかは別としてもこの三つはわりとすぐやりたいことができた。昔 Java の本を買ってきて挫折したのにくらべたら、なぜかずっとわかりやすかった。（bless という命名はすごく洒落てる）
全然関係ないけど、Django の日本語リファレンスは何か萌える。ラクダ本の日本語訳はむかつくのに。
プログラミングを始めたばっかりの時は、なんだか難しい用語の意味を理解しないと OOP がわからないと思ってた。それは僕らの住んでる世界とは全然関係のないプログラミングの技術ってやつだと思ってた。
でも多分違う。
世界が動く仕組みさえあれば、あとは作り手に世界の成り立ちを抽象化する表現力さえあれば、世界は勝手に表現されていくし、動き出してく。たまたま僕らの世界はオブジェクトなもので溢れていて、プログラミング言語が進化すれば世界に似るのも当然だろう。いや逆か。プログラミング言語が世界に似てきたから、オブジェクトなんていう世界に似た概念が出てきたってことか。なんだか難しい用語ってのは、その表現の一部分の技術に名前をつけてるだけなんだな、と。例えば何とか歌唱法や何々画法とか何とかレトリックとかパースの取り方みたいなのと同じ。それは表現を理解する手助けにはなるけど、その意味を知る事がイコール表現力をあげることにはならないんだよね。これに気づくのに遠回りしすぎたなあ。
（知識を得るだけで、100% 還元される人もいるかもしれないけど、そんなのは一部の天才だけだと思う。殆どの凡人はそうはいかない。とはいえ、元の錬度が低ければ、コツをいくつか教わるだけでいきなりうまくいくこともある。ただ、それをまるまんま実力だと思うのは、どんな分野でも危険だ。恋愛テクニックやらを必死に読んでる連中が男女間の深い人間関係を上手くやれてるとはちょっと想像できない！）
プログラミングで表現力を上げるにはどうすればいいんだろう。きっと他と同じだろうな。いい表現を沢山味わって、世界をよく観察して、どう成り立ってるかどう動いてるか、私達はそれをどう認知しているのか、考えることかもしれない。漫画家を志す人が美術解剖学を学んだり、優れた画家が絵筆で世界を生々しく描写するように、優れたプログラマは世界のなりたちをプログラムに写し取ったり、世界の仕組みを作る事が出来るのだと思う。