元増田って
http://anond.hatelabo.jp/20091010180917
でいいですよね?
違ったら以下は無視してね。
内部設計書は書いてますよ。
いやまちがえた。オタクがみんなきもいわけじゃない。
新しい物にはすぐ飛びつくくせにすぐ飽きて忘れ去るオタクきもい。
どんだけ見た目きもくても、一つのことにめちゃくちゃはまってるオタクは別にきもくない。
まぁそのはまってる物がエロゲとかだと別のベクトルできもいことはきもいんだけど、基本的なスタンスはきもくない。
なんかぽんぽん新しいアニメの話題出されても困る。
何か一つのことが好きならこっちだってそれについて調べたり興味持ったりする暇はあるのに
こっちがそれについて調べてうっすら知識つけた頃には相手が飽きてる。ありえん。はやすぎ。
で「今期のアニメははずればっかりだったわ」とか言ってる。あんだけハマってたくせに。
で「来期のアニメもはずればっかりだわ」とか言ってる。見るくせに。んでもってハマるくせに。
で「お前アニメとか興味ないもんなー」とか言ってる。
はぁ?こっちがせっかく知識つけてもそれを披露する暇がないんだよ。お前がもう興味なくしてるから。
一緒にアニメ見てても「女にはわかんねーだろうなこのノリw」とか言うし。
女がロボアニメ見てかっこいいって言っちゃだめかよ。おとなしく少女マンガ見てろってか。
じゃあもう感想言わんわぼけ。最初から相手をシャットアウトしといて文句言うなぼけ。
適切に共通化されるというのが、幻想というか、正しい表現ではなくて、何が適切?というのがあるから。
適切の基準が曖昧でプロジェクトによってことなるのもその通りです。
エンジニア的には正しくても、会社的に正しくないことがあり元増田のおっしゃる通りだと思います。
王道が共通化というのは訂正します。
ただエンジニア的には共通化は正しく、
エンジニア上がり人は取り締まりに役になってもこんな事言ってたりします。
http://d.hatena.ne.jp/iad_otomamay/20090413/1239632703
内部設計の段階で、内部設計書書いて(or担当者に書かせて)してはどうでしょうか?
そして、そのプロジェクトではどのような設計が、適切に共通化した設計か判断できる人間と
レビュー実施するようにすべきだと思います。
実装されているか(共通化を含む)項目つくるものだと思うのですが、
内部設計書は作ってないのですか?
担当者のせいばかりにしていても解決しない問題と思っています。
Radioheadの"Creep"じゃないかと思う
http://www.youtube.com/watch?v=XFkzRNyygfk
http://www.lyricsfreak.com/r/radiohead/creep_20113302.html
曲調のおかげですごく沁みるんだよね
まあもちろんあれだよ、麻生さんないし当時の政権が壮絶に無能で全く悪意もなくこんな予算を切っていたという可能性も否定はしないけど、さすがにそれは逆にないんじゃないかなぁ。
単に景気対策のためだから精査して遅くなるより額の大きさを重視しただけなんじゃないかと。
高速4車線だって別にやるべきでないというほどのことでもないし、雇用・能力開発機構が天下り団体だからといってそこにやった金が丸々天下り役員の人件費に消えるわけでもなく多くは失業者対策に回るし、全体としてみれば削られなかった額のほうが多いわけで民主党だって大部分は必要だったと認めたようなもの。それを悪意があるから無駄遣いしまくったんだと決め付けるほうが悪意あると思うが。民主党の政策で財源がいるといっても多くは恒久措置なんだから埋蔵金がなくなったら財源確保できませんというのじゃだめなんだから。景気対策の補正で一時的なものなら埋蔵金でいいんだが。麻生に埋蔵金使われたから財源確保できませんというのは責任転嫁だろう。
9割以上完成していて、12月には貯水に移る予定だった事業も凍結
長井ダム凍結「なぜ今」 : 山形 : 地域 : YOMIURI ONLINE(読売新聞)
http://www.yomiuri.co.jp/e-japan/yamagata/news/20091009-OYT8T01243.htm
↓↓
【小沢王国】胆沢ダム当面継続 達増拓也(小沢の側近)知事「当然のこと」【進ちょく率75%】
http://tsushima.2ch.net/test/read.cgi/newsplus/1255168337/465
465 :名無しさん@十周年:2009/10/10(土) 20:30:40 ID:VLhBvXDBO
http://sankei.jp.msn.com/region/tohoku/iwate/090306/iwt0903060225000-n1.htm
田川ダム(調査中)
http://www.i-ppi.jp/Search/Web/Koji/Keika/List.aspx
(入札事例)
「生活が、第一」(?)
お前等分かり易すぎwwww
一名様ごあんなーいwwww
例えば、出会ってから一か月経たずに両想いになって
それから一週間も経たないうちに相手が事故に遭って亡くなった、などの
そんな短期間の恋愛、しかもお互いが望まない形での別れを
経験されたことがある方がいましたら、お話お聞かせ願えませんか?
他人事だと思って面白半分で訊いてるわけじゃありません。
私自身、似たような境遇にあるので(言い表しづらいので正確な引用が出来ないのですが)
他の同じような経験をされた方が、今現在その短い過去をどう思っているのか
他の誰かを好きになったりしているのかなとか、参考にさせて頂きたくて。
比較してどうするんだ、って話ですが・・・多分、気を紛らわしたいのだと思います。
そんな理由で申し訳ないですが、良ければお願いします。
ちなみに私はある程度立ち直れて、意地でもその方を一生好きでいさせてもらおう、とか思ってます。
そんな短期間で相手を深く知れた訳ないだろ、とか幼稚な恋だとか言われたら
私は実際、後先考えず幸せを享受してた子どもに過ぎなかったので、反論できないし
こんなこと思っていられるのも、まだ2,3カ月しか経過していないからかもしれないけども
今のところは相変わらず、その方のことばっかり考えてます。
あ、話それますが・・・その方との会話の中で
"ぼくは弱虫のくずやろうだけど、君は美しくてとても対等に付き合えそうにない でも好きだから・・・"
などといった内容の歌詞の洋楽がその時の状況にリンクした、とその方が言っていたのですけれど
元の英詩は知らないし、この和訳でググっても見つけられず、未だにもやもやしてるので
御存知の方教えて頂けますと大変助かりますorz
麻生が立派な政治をしてたとも思わないが国をつぶすほどのことはしてないと思う。結局民主が停止したのは3兆ぐらいなわけで無駄遣いは少ないほうがいいが、数兆円程度なら別に国がつぶれるほどのものではないはず。削った3兆の中身だって閣内でも「明らかな無駄と言い切れるほどのものは少ない」と認めてるわけだし。
橋下知事に「『お前』メール」 府職員に100人もいる! : J-CASTニュース
http://www.j-cast.com/2009/10/09051410.html
ファックコミュニケーションが男性コミュで主流な理由とか - pal-9999の日記
http://d.hatena.ne.jp/pal-9999/20070527/p1
【トレビアン恋愛】ファックコミュニケーションで男女関係の恋愛攻略! - livedoor ニュース
http://news.livedoor.com/article/detail/3195575/
時には同じそうに見えるけど2つ作っておくことも悪くないという事。
納得できないなぁ。
王道はやっぱり、「全ての技術者が、案件に対して充分な技術力を有する事」だし、
「管理は一元化する、そのために、同じ振る舞いを幾つもの箇所に書いたりはしない」事だと思う。
でも我々は王の器ではないので、現実解として
「適度に上級者に頼る」し、「適度に二重管理」もする。
王では無いものが王道を進んで痛い目を見るのは当たり前のことです。
貴方が、「俺は以前にこの道を行って酷い目に遭った、だからこれは王道じゃない!」
と言われましても、王たる証が御座いませんと。
適切に共通化されるというのが、幻想というか、正しい表現ではなくて、何が適切?というのがあるから。
速度に対して最適化するのか、メモリーにたいして最適化するのか、費用に対して最適化するのか、期間に対して最適化するのか?
なので、適切に共通化 という単語が成立しにくい。ある条件下ではAという共通化が最適でも、違う条件下ではBという共通化が最適だったりする。
そんで、プロジェクト1年目の受注では条件Aだったが、翌年の追加案件ではBだった。みたいなことが起こりえる。他にも色々。
そんで、重要なのは、この辺というのは、人によって解釈が違うし、主義もあるし、宗派もあるってこと。
規律だ設計だ、ルールだを持ち出しても良いけど、現実問題として、人を理由とした摩擦や問題は起きるという事。
そういう事例に対して、設計は正しいのにみんながルールを守らないから、とか言い出してもしょうがなくて、
リーダーに求められるのはプロジェクトを成功させることであって、モジュールを共通化させることではない。という事。
よって、目的達成のために、最適な手段をとる。という意味では、共通化という命題は、技術的にはすばらしいが政治的にすばらしくないことがあるので、
趣味ではなく業務としてのプログラムでは、優先課題ではない。という事。
で、結局、どうするかと言われれば、今いるメンバーで、出来る範囲で、次のプロジェクトが来ても、問題ない程度で設計するって話しになる。
ぶっちゃけたところ、共通化の話題は、結構、オブジェクト指向だ、やれなんだで、宗教論争になりがちで、理想を追い求めガチだから、ほどほどにしろ、って口をすっぱくしていわないと、
共通化のための共通化になって、全体を阻害することがあるから、マネージングする側としては要注意だと。
イヤ本当に、正直、理想を追い求めた、高度すぎる抽象化はいらん。結局、ながくプロジェクトを続けられるコツは、次がどうなるか何てわからないんだから、共通化は『ほどほど』にしておく。ってところに落ち着く。
で、技術的に高度なところだけは、信頼できる人にやって貰うか、自分でヤルって話しに落ち着く。そこ以外は、なんつーか、もう、ほんと、手工業だからねぇ、この業界。って話し。
なんというか、適当な設計だなぁって言われることもあるだろうけど、そういう風に、各個人毎に機能を割り振って、最低限の所だけ押さえるのも設計と思うわけですよ。
一人でやってるなら、共通化しちゃっても良いことも、複数人でやってると分けた方がよいこともある。その辺のさじ加減が設計。ほんと、人依存。
ちょっと追記。
共通関数をコピペして&修正した場合もコピー先全パス試験しろという職場にはこの方法は向かないですね。
(多分、対官公庁、対銀行の仕事してる人は全パス試験しろってことになるんだろうな。)
あるあ・・・あるある。
真面目な関係のビジネスパートナー20代女性に突然「レロレロ」と送信。
世の男どもは皆スーツ着て皆大人ぶっているけど、そういうことが屡々あるものである。
それらで処理すればいいか。逆にいえばそれらに該当しなければ問題なしと。
私の理解不足かもしれない。もうすこし詳細教えてください。
私は適切に共通化されるなら、共通化すべきだと思う。
つまり王道は共通化すること。
共通化してはいけないものを無理やり共通化してるから問題ってことですよね?
でも、実際担当者さんって、意地でも共通化しようとしてコピペで逃げればいい物を、関数を変えて、それを報告しないでデグレってあとで地雷とか
特にわからないのが、この部分。
これってどこまで共通化すべきと言うのが、
ある程度詳細設計書(指示書?)みたいなのがあるのに
勝手に変えて作ってきて問題を発生させているってことですよね。