UMLJavaができない奴は英語ができない奴と同類

UMLとJavaは
プログラマにとって世界共通語みたいなものだ。

その標準語すらつかいこなせないとは
国際化社会に背いているのと同然。

UMLやJavaを勉強しようとしないプログラマは
戦時中の日本のように、国際化社会を否定して
英語を使うことを禁止した旧日本軍のヴァカどもと同類。

UMLやJavaを勉強しようとしないプログラマは
プログラマ同士どころか顧客とのコミュニケーションがろくに取れない愚か者である。

君たち、諸君は、国際標準語たるUMLとJavaくらいできなくては
国際プログラマとして使い物にならない存在である。

>>1は、
うん、国際プログラマだね。

UMLができない香具師は国連を脱退した国賊と同じ
ならず者国家と同類

>>1
どうでもいいことに騒ぐなヴォケ。
金儲けしか考えてないUMTPに騙されてんのか？

その昔、中国では
漢字が国中に浸透し、普及していった。
しかし、どの字体もまちまちであった。
どれも個人の癖があり字体が統一されていなかった。
始皇帝はそれにイライラしていた。
そこで始皇帝が漢字の字体を統一した。

今のIT業界でも仕様書、プログラミング言語が乱立しているため
プログラマ同士のコミュニケーションが取りづらい状況になっている。

そのために、UMLとJavaを用いてコミュニケーション形態を統一すべきだ。

乱立した仕様で狂ったIT業界を統一しよう。

>>4
日本語しかしゃべれない香具師は日本人としか
コミュニケーションが取れない。
日本人としか仕事ができない。
それでいいのか？

今こそ、UMLで世界を統一すべきだ！

UMLってなに？計算できる？

>>6
こういう狂ったスレが乱立する事の方が問題

>>8
UMLとは計算するためにある者ではない。
どちらかというと、顧客とのコミュニケーションを円滑にするために作られた約束事である。

5分で絶対に分かるUML - 0分
http://www.atmarkit.co.jp/fjava/devs/01fivemin/fivemin00.html

>>9
狂ったスパゲティコードが乱立することのほうが問題

Javaでスパゲティコードを玉砕！

>>8
もちろん出来ない
UMLと一口に言ってもバージョンによって微妙に異なるし、
MDAのような「デバッグ可能な動くモデル」を目指す派と
Agile開発に代表されるような「スケッチ」として活用する派がある

個人的には1.3で十分だったスケッチ派の俺

てゆうかUMLはいっぺん廃棄して作り直せって幹事

>>12
玉砕なんか…
釣りっぽいがつられとく

>>1は日本語が不自由な方ようです。
以降、なま暖かい目で見守って上げてください。

>>1
いったい何がしたいんだオメーはよ！
自分でたてたネタスレだろ？
自作自演してでも盛り上げろヴォケ！

>>1
国際標準語はMS公式APIとライブラリだろ。
ぁふぉか。

設計できる人間にとっては、記法や言語なんてたいしたもんだいじゃない。
ところが、
能力の伴わない人間がやたらその辺を強調するんだよな。

だからといって企画屋にUMLを持ち込んで
この動きでいいんですね？と念を押してバ
グの責任も押し付けた気になるのはやめて
ください。

俺がその提案書一日で書きますよ！とか言
ってフロー図描いて、客先で図の読み方を
必死に語るのやめて下さい。

>>19
> 設計できる人間にとっては、記法や言語なんてたいしたもんだいじゃない。
> ところが、
> 能力の伴わない人間がやたらその辺を強調するんだよな。
根拠がないな。

貴様は記法を統一せずして英語しか解らない顧客にたいしてハングル語で
仕様書を出すのか？

なんと無礼な奴だ。顧客が去ってゆくぞ。

顧客には、UMLよりまだDFDのほうが(ry

ネジの規格も統一せず、ネジ穴に収まらない独自仕様のネジを
押しつけるとは言語道断。

客先に応じて使い分ければいいだけの話。

UMLはプログラマ以外に浅く広く広まって欲しいね。
今の路線でマニアックになると結局はプログラマやSEだけのツールになりそう。
それじゃあ意味無い。新入社員研修に必須になるくらい、一般化する方向に進んで欲しい。

>>21
19の言いたいのは、重視されるのは設計であって記法ではない
ということだと思われ。記法はプロジェクトの開発プロセスに
応じて合意されたものを利用すれば良い。

問題は馬鹿ほど無意味に記法に拘り、UMLで何かを描いている
だけで、自分は大したことをしていると思いこみがちだと言うこと。
ていうか、そういう馬鹿が身近に結構いて鬱だ。

いくらでも機械翻訳がある今の時代、神設計だったら顧客が基地外じゃない限りハングルでも怒られないだろうしなｗ

UML知ってもオブジェクト指向や開発手法をしっかり勉強しなければただの糞です。
UMLってプログラマ間の会話等などには使える。
また、複雑系の簡略化およびその説明に使われるべきもの。
設計書には・・・腐れSEやなんちゃってSEが多すぎて無理…
JAVA(OOに向いた言語)知らないで設計とか・・・あほすぎてやってられん。
プロジェクト破綻してるよ・・・

>>26
>
> 問題は馬鹿ほど無意味に記法に拘り、UMLで何かを描いている
> だけで、自分は大したことをしていると思いこみがちだと言うこと。
> ていうか、そういう馬鹿が身近に結構いて鬱だ。
藻前と>>19の周りだけだ。
そういうバカがいたら、きっちりとUML教育してやれ

UMLはエスペラントのようなもの
世界共通ですよといっても実際には普及していない
現実世界で英語や仏語などが流通しているように
DFDや処理のフローチャートがスタンダード
＃実際UMLより分かり易いし

>>29
おっしゃるとおりで

>>31
まちがった。26でした。

さあ、盛り下がってまいりました！

>>30
> UMLはエスペラントのようなもの
> 世界共通ですよといっても実際には普及していない
> 現実世界で英語や仏語などが流通しているように
> DFDや処理のフローチャートがスタンダード
> ＃実際UMLより分かり易いし
それはお前の会社か？

うちでは思いっきりUMLつかってるぞ。
仕様書にシーケンス図とか思いっきりかいてあるし。

フローチャートなんて、アクティビティ図が有ればいらないだろ.

オブジェクト指向の時代がすでに到来済みの現代では、
フローチャートやアクティビティよりもステートチャート図のほうが
わかりやすいケースが多いんだがな。

>設計書には・・・腐れSEやなんちゃってSEが多すぎて無理…

それじゃよっ。ｸﾜｯ
上が馬鹿だからどうしようもねー。何も瓦ねー。

オブジェクト指向時代は会話もオブジェクト指向！

「私.尋ねる(上司 , "給料上げろ");」
「上司 throws NullPointerException」

どのあたりが?

>>34
あなたの会社内部ではそうでしょうけど
玄人同士で判り合っててもそれまでの話ですよ。
実装レベルならよいですけど。

お客さんにダイアグラムの読み方から
説明せんといかんような状況ではやっぱり困ります。
概念設計して、それを承認するのはお客さんですから。

>30のエスペラント説はまさにしかりしかり。
UMLの質が悪いって事じゃなくて、
話しても通じないんじゃまだまだ使えないって事だよね。

待つしかないのか。

>34
何年か前に上からの命令でUMLブロンズ資格を全員取得した
しかし定着しなかった
新しい言語ができても普及しないことの方が多い

>>39
> >>34
> あなたの会社内部ではそうでしょうけど
> 玄人同士で判り合っててもそれまでの話ですよ。
> 実装レベルならよいですけど。
>
> お客さんにダイアグラムの読み方から
客にはユースケースで十分。

彼らには、クラス図とか見せてもわからんだろうが

シーケンス図、コラボレーション図くらいなら
顧客でも大抵はわかる。

>>39
> >>34
> あなたの会社内部ではそうでしょうけど
> 玄人同士で判り合っててもそれまでの話ですよ。
玄人の中には、わざとわかりにくいスパゲティコードを
沢山書いて自分の立場を維持し、保身に走ろうとする御仁がいる。
UMLを使うことで少しでもそういった事態を緩和しようという動きも取ることができる。

これをXPなどとからめればさらによい。

>>39
> 待つしかないのか。
待つのではなく、普及させる、教育することが重要だ。

>>40
ブロンズさえできれば図をよんだだけですぐに理解できる。
設計はキツイが。

>>41
ユースケースって結局、散文なんですよね。
ユースケース「図」自体には何にも書いてない。

お客さん、字がいっぱいだと読んでくれなさそうで
不安なんですよ。実際に使った事ないので。

DFDだと説明もしやすいし、視覚に訴えやすいんで
話してると漏れとかもお客さんからよく指摘してくれる。

うーん。悩んでないで、いいからやってみろって事ですかねぇ。

>>42
玄人って言い方が悪かった。
開発者側のコミュニケーション手段としては有効だろうけど
顧客向けに収めるドキュメントにはどうなのかなあって
話なんです。

俺はUMLが悪い物とは思ってなくて下流ではよく使ってますが
うちの会社小規模なんで上流まで俺がやらんといかんのです。
まだ基本設計をUMLで納品した事はないので
使ってみてダメだった、って訳でなくて、漠然と不安があるってだけです。

UMLって、そもそも顧客とのコミュニケーションを円滑にするためにつくられたものだと
思ったけど。
それにユースケースの場合はとくに顧客にわかりやすく

またJAVA厨（大文字ｗ）が、嫉妬に狂ってクソスレをたてたのか。

百聞は一見に如かずとはいうけど、「百見は一文に如かず」も真だな。
ユースケースとか絵だけだと、エンドユーザと何に合意できたのか、
あとあと揉めそう。

>>48
ユースケースは文で書くんだよ。
絵はユースケース「図」。

良い感じに寂れてきたな
１はどこいった？

JavaはCより難しい
http://pc5.2ch.net/test/read.cgi/tech/1095677476/

>>51
そのスレの1も相当な馬鹿でステキだな

>>52
おまえよりはましだよ

おちつけオマエら

いまどきJavaもできないでたかがＣができたくらいで威張ってる奴は英語ができずに
朝鮮語できたくらいで威張ってる馬鹿と同類

Java言語自体は非常に簡単。
その周辺技術をどれだけ理解習得し、顧客や上司の前で適切に用いられるかだろ。

されどJavaを実際に使いこなすのは困難。
J2EEを習得し実践に役立てることがどれだけ大変なことか。

そしてそれが構造的な製作の下地として
生かされているかといえば、えてしてNO。

ならばJ2EE+UMLという図式の延長で済
む案件が多いかといえばNO。

結局は、メーカーが説明しやすい環境っ
てだけじゃねーの。ここまで使いこなせる
奴は、元々CもRDBMSも業務分析もでき
なきゃおかしいだろ。

J2EEの変わりに

Tomcat + Struts + Oracle
なんて組み合わせもなくはないのだが

ふーん、Servlet＋JSP＋JDBCってJ2EEじゃないんだ。

そうはいうけど

EJBを始めとするJ2EEの全ての機能を使わなくてもいいだろ

Javaを使わなくてもいいけどな。(ｹﾞﾗ

Perlの方がはるかにマルチプラットフォーム対応だし。

元々Perlプログラマーだったけど、今更Perlはないだろう。
Rubyならまだしも。

Rubyで作られたシステムってどんなのがあるの？

TDiaryとか、色々あるよ。
Perlよりは多い。

いくらなんでもPerlより多くはないだろ。。

UMLで仕様書書かせるのはやめてほすい

ユースケース（ユースケース記述）やシーケンス図って
お客さんとの打ち合わせで使うもんなのかな？
なんか説明しずらい。

業種によるだろうね。
UMLが普及する前からシーケンス図を使っている業種もあるからなぁ。

要は
ユースケースていいたいだけちゃうんか

>>63
Javaはコンパイルされた状態でマルチプラットフォーム対応なんだよ。
ま、要はエミュだけど。

>>72
プラットフォームへの対応は不十分だけどな。

ＢＡＳＩＣ　ラテン語

Ｃ　　　　　ドイツ語

Ｃ＋＋　　英語

Ｐｅｒｌ　　　フランス語

ＶＢ　　　　日本語

Ｊａｖａ　　　ロシア語

ＰＨＰ　　　中国語

ＪＳＰ　　　朝鮮語

Ｃ＃　　　　米語

ＵＭＬ　　　エスペラント語

エスペラント語は悲しすぎる・・・

>>68
UMLだけでしか仕様書かかないのはまずいけど
クラス図やシーケンス図など使ってくれると
こちらとしては設計しやすいよ。
わかりやすいのはすごくありがたいし。

>>74
なんでJSPが朝鮮語なんだよ！（ｗ

あ、ハングルか。なるほどね。

エスペラントという言語はあるがエスペラント語という言語はない

いいじゃん、HTML言語とか
普通に世の中使ってる人いるだろ

クラス単位に処理を記述するよりも、所々のイベント、I/Oでマトリクス作った方が早いと思うの俺だけ？
プロジェクト内の文書互換性にもよるんだろうけど。

ナイキが著作権で敗訴　中国の裁判所が侵害認定
http://news13.2ch.net/test/read.cgi/news/1104459086/l50

ユースケース図ピンチ？

UMLを強制するやつは糞

C#はベトナム語だろ。
米語にふさわしくない。
米語はD言語だ

UMLとJavaをそれぞれ覚える事が出来ず。
UMLをJava以外で活用できないヤシは屑

UMLが各言語（国）の共通語じゃないの？Javaが共通語な世界…不安だ…

UMA

私、Java厨になるー
Java厨になるー
なるー

>>86
大抵の、オブジェクト指向の解説をしている
サイトや書籍はJavaを標準語のように使って
解説しているケースが多いけどね

派遣で客先との面接のとき、UMLの経験は？って大概聞かれるんだよな。
その度、読むだけならって自信なさげに答えてしまう俺
既に出来上がってる物のカスタマイズとしてUMLが読めないと話にならないらすぃ

>>86
JavaはIT業界では共有財産と見なされている傾向にあるらしい。
(だからSunはJavaだけでは儲けることはできないとわかって、
Javaを利用した応用技術を考えているそうだ)

共有財産と見なされるほど共通語に近づいたともいえようよ

>>90
逆にUML試験を、「流行っているから試験を受けたのか？」と頭の悪そうな女面接官に勘違いされたこともある。
元SEだなんて言っていたがうさん臭い女だったな。
ＵＭＬのことにも否定的そうな印象だった。
まだ30代の女みたいだったがマネージャや役員を兼ねているみたいで
時代遅れな頑固ジジイと考え方が一緒でウザかったな。

>>1-92
自演乙

使う側がまず考え方を改めない限りはUMLなんて無意味だろ。
うちなんかOO言語使って手続きプログラミングしまくってる
からUML使う余地があまりない。
使ったら使ったで、ご老体やご老体の遺志を継がんとする若い連中が
顔しかめるし。

正直、設計手法なんてどうでもいい。
顧客満足度が高けりゃ、UMLも構造化もOOもDOAもSOAも関係ない。

だから、ちゃんと仕事してください＞PG
ｵﾅｶﾞｲｼﾏｽ

>>95
お前みたいなヤツが、IT業界のレベルを落としている。

お前の部下はきっとこう思っているよ。
「あんなヤツ、クビにしちまえ」

>>96
そうか？
そうかもしれんな。
ただ、顧客が公道走る乗用車を求めてるのに、F1カーの設計図・部品を作っても仕方ないだろ。
F1カーを作りたければ、そのような所へいけばいい。それは否定しない。

俺は思うに、「IT業界のレベルが低い」と言われるのは、顧客満足度が低いことに起因してると思ってるんだがな。
PGに言っても分かってもらえんかもしれんが。

>>94
なにもかも老体が悪い。
UMLを使うから金をよこせ！
といってやっちまえ

>>97
アフォか。話題を必死にそらそうとしていることが見え見栄だぞ。
乗用車を作るのに乗用車の設計図も部品もいらないと抜かすか。

顧客満足度が低いのではなく
やる気がないお前がレベルを下げるような行為をしているのがいけないのだろう。
どうせ定年であと数年で引退するらとかいって適当にやろうとしているんだろ。ふざけるな。
それと顧客のレベルが低い。
顧客が技術をわかっていれば
もっとましなものを作れる。
日本の顧客はプログラマに作ってもらったもので大きな収入を得られると思っていないやつが多い。
プログラムを作るなんて非常に簡単なことだと思い込んでいる。
作るのにかける時間、計画を練り設計する時間を考慮すればもっとましなものが作れることをわかってない。
そのくせ仕様変更は平気でする。大半の顧客はド素人だから仕様変更しても固定された決まった一定の工数だけで
簡単に修正できると勘違いしている。ちょっとPCを使えたからといってみたこともないソフトをプログラマが即座に
使えると思い込んでる馬鹿な上司にそっくりだ。

顧客満足度が低いと思うなら顧客満足度を高めてみろ。

100get

>>99
お前、「顧客のレベルが低い」って客の目の前で言えるのか？ｗ
最下層工程しかやらなくて言い人は好きなことが言えて気楽だな。

顧客に技術レベルを理解させる事など期待してはいけない。
顧客は自分がかねだしてるっていう意識があるから何でも言ってくるし。
顧客はバカって考えると、バカ相手に仕事をするのが大変なことだと気づく。
だからコーダーより高い金もらえる訳。顧客の分野の知識を持ち合わせて
信頼を得るよう努力すればいい。

>>102
それで、顧客分野の知識は顧客以下。
技術レベルは最下層行程のヤツ以下。

そんなお前みたいなのが中間に入っているから、糞システムが乱造されるんだよ。

>>103
三流孫会社の奴ならそう思っても仕方ないｗ

>>102
なんか、法律関係の会社に出向してた奴が、
4年の出向期間を過ぎて自分の会社に戻ってきたとき、
弁護士の資格をもっていた。

その後、親会社の法務部に配属換えになったらしい。
プログラムもろくに書けない奴だったのに。
俺らは踏み台ですか。そーですか。

>>105
どこをどう踏み台にされたのかよく分からないのだが。
弁護士資格を得たのは単にそいつがよう勉強したからだろ？

簿記とって経理になった人は何人か知ってるけど
弁護士は凄いね。

>>103
糞システム・・・
お疲れ様です

海外の発注元からはシーケンス図で仕様が届く。
複合フラグメントを使ってるから、たぶん1.5か2.0。
日本が遅れてるのかな・・・？

>>94
> 使う側がまず考え方を改めない限りはUMLなんて無意味だろ。
> うちなんかOO言語使って手続きプログラミングしまくってる
> からUML使う余地があまりない。
> 使ったら使ったで、ご老体やご老体の遺志を継がんとする若い連中が

肝心な若者が、頭の悪い先輩や上司の言うことを何でもかんでも
鵜呑みにしてしがらみを引き継ぐのは大問題だな。
いくら先輩や上司が過去に優れた業績を残したからと言って
それが現代のやり方に合致してるとは限らないしねえ。

>>109
おまえんとこ、関数とかクラス単位で受注してるの？(´Д｀;)

シーケンス図で仕様が届くってのは
関数単位とかクラス単位というよりか、
インターフェイスの仕様が既に決まってて実装だけ受注とか、
そういうのだったらありうるんじゃないすかね。

そういう仕事、俺はやった事ないけど。

レガシーマイグレーションにおける効果的な UML の使い方

・ヒヤリングに行く前に業界の図解本等を読んで、あらかじめモデリングしてゆこう。
・モデリングの対象はモノではなく、業務系ではデータと処理である。
・伝票・帳簿・帳票から分析する。
・旧システムは当時の分析手法でモデル化されたもので、既に最適化済みである。よって、現実世界とはギャップがある。それを見失しなわないことが重要。
・お客様にあわせて道具を選ぶ。CRC カード*1や、アセンブリライン図*2はわかりすいので理解してもらいやすい。

*1 CRC カード: クラス(Class)、その責務(Responsibility)、協調関係のあるクラス(collaborator)を一枚のカードに書いたもの。参考 :CRC (Class Responsibility Collaborator) モデルの概要

*2 アセンブリライン図: オブジェクトとプロセスとの関係を表現するための図。

>>113
えーと結局UMLだからどうという話ではない、って事ですね。

UML = 生まれて 間もない らいおんrらいおんrらいおんららいおんららいおんらいらいおんらいらいおんらいおらいおんらいおらいおんらいらいおんらいらいおんらい

俺も英語、UML、JAVA勉強中だけど、スレタイは結構的を射ているとおもう

>>116
仕事する上で、絶対に必要という訳ではない、って事ですね。

Factoryとかそういうのが出るとシーケンス図とか一向に記述できない。
まいっちんぐ

正直、大人にもなって英語ができないんじゃ人間失格だと思う

UML,Javaは、俺様の見通しではあと３年もしたら業界必須でしょう。
ただ、UMLもJavaも難しいので誰でもはできない。
UMLとJavaが合体すると、優秀な香具師だと生産性が従来の１００倍
くらいにはなるので馬鹿は必要、１人で１００人分。
１万人で１００万人分。
馬鹿はIT業界から追放される。

馬鹿は必要？
馬鹿は不要でしょ。

UMLって、設計の表記の問題だから、
表現方法を考えてきた人なら、直ぐにマスターできると思うのだけど、
そういうわけにはいかないの？
（ＯＯが理解できてることが前提になるかもしれないけど。・・・あっ、ほとんどいないや>_<）

UMLをJavaに落とせるように設計できる先輩はすごい。
インターフェースとかデザインパターンとか使って
おまけに再利用までできるようなULを設計する先輩
はすごい。
さすが東大出のSEだけのことはあります。

umlはすごくないんだよね
umlを書く側にもセンスが必要だし
それを読み解くにもセンスが必要

>>123
んなこと東大生でなくても簡単にできるんだけど。

かつ東大生でもダメな奴はダメ。
おっきい会社に出向に行って驚いた。

日立？富士通？NEC？

日立は学歴があるだけで無能が奴が集まる会社

アイコンが「木」らしいな。

気になってクリックしたくなるな

日本語ベイシックじゃダメですか？

Javaはともかく、UMLなんて覚えてもなぁ

>>132
UMLよりJavaがイイなんて、
おまい一体どんな仕事してるんだ。

職場でUMLを使うことを准必須のような状況にするということになった。
で、3日ほど格闘。ふ〜ん思想的なことはわかってキター。

そうそうコードはC++で書くんだけどね。
だから、UMLからコード生成はツールではなく自分達の頭でやることになるようだ。
UMLの話からはちょっとそれるが、昔、噂にだけは聞いたことある人間コンパイラー
みたいだなと(w 難易度はケタ違いに違うけど。


格闘始めるよりも前に、真っ先にここにきて>>10を読めば、もっと理解が早かった
んだが… 運が悪かった。

>>134

素直にC++対応のツール使え
それじゃツールの意味がない

>>134
頭悪い職場だなｗ

UMLってコーディング出来ない学者の作ったお絵かきだろう。
元々、プログラマが脳内でやってた事を無闇に図にするから、フォーマットばっかり増えて破綻するんだよ。

>>137
お前頭割るそうだね。

>138
なんだと！！てめーじゃあUMLの何図がすげーつーんだよ！！

慶応SFCのビデオ講義でも見てUML覚えようぜ
いまのところ、登録しなくても見れる。
ttp://gc.sfc.keio.ac.jp/cgi/class/class_top.cgi?2004_14921

>>137
そだな。
ＵＭＬ使って仕様書遊びしてる似非ＳＥに払う金を節約すりゃ
破綻するプロジェクトも多少は少なくなるだろう。

Undefined Moderation Lesson

UMLは物事の捉え方を変える手段でしょ。
30過ぎたオッサンは包括的な概念を捉えられないﾄﾞｷｭｿばっかりだもん。

>>143が設計したシステムはＳＩ後に性能問題で地獄を見る予感！

とりあえずUMLとJava的な考え方は当たり前、常識的な
考え方として認知されて欲しいからageとく

PHPなんて言語覚えるよりUMLを覚えようぜ

ＵＭＬをおぼえてもフローチャートを描かされる職場のほうが多そう

デザインパターンとか覚えないと、話にならないね。プ

自戒もふくめていわせてもらうが。
UMLなんて平仮名と同じさ。デザインパターンは小学校でならう漢字かな。
勉強しなきゃマスターできないから、書けないやつもいる。
しかしそれが書けるからといって、実のある文書を書けるとは限らない。
平仮名も漢字も完全マスターしても小説家になれるとは限らないし、
平仮名すら満足に書けなくても天才画家と呼ばれる人はいる。

でも漢字も読めねーやつとは仕事したくねぇ

>>147
> ＵＭＬをおぼえてもフローチャートを描かされる職場のほうが多そう

そんな職場や会社はそろそろ淘汰される時期だろう。
年貢の納め時というか

━↓注目！━━━━━━━━━━━━━━━━━━━━━━━
　　 ◆驚愕の新規参入ビジネス、新春第一弾スタート!　◆

●緊急情報が入りました! !
●まだ殆どの方に知られていません。
●国内版、驚愕の新規参入ビジネスが立ち上がります。
●今は縁故スタート前の立ち上がり段階での水面下情報です! !
●今すぐ下記より資料請求して下さい! !

　　　 http://www.1final.biz/FS/60104.php?ID=G9327

「比較的低い出身階層の日本の生徒たちは、学校での成功を否定し、
　将来よりも現在に向かうことで、自己の有能感を高め、
　自己を肯定する術を身につけている。
　低い階層の生徒たちは学校の業績主義的な価値から離脱することで、
　『自分自身にいい感じをもつ』ようになっているのである。」
（『階層化日本と教育危機』有信堂、２００１年、２０７頁）

苅谷さんはこれが９０年代の傾向であること。中教審のいわゆる
「自分探しの旅」イデオロギーと深く連動していることを指摘している。
「学ばないこと」が有能感をもたらすという事実は、
「学ばないことは『よいこと』である」という確信が、無意識的であるにせよ、
低階層の子どもたちのうちにひろく根づいていることを意味している。

http://blog.tatsuru.com/archives/001572.php

UMLを知らない奴が仕事の能率を下げることは明白

UMLで大規模開発を表現するのは難しい。

配置図とか使えば？
配置図ってただの絵だと思ってなめていたけど
後になってすごい助かることがある。
そうだ、こういう分割の仕方してたんだって。
切羽詰まってくるとそういう当たり前のことがあやふやになってしまうんだよね。
恐ろしいことに。

配置図はよく重宝するね。
あれで創造力がふくらむ。

クライアントサーバシステムや
ネットワーク構成図は
あれを使って代用することがある。

>>156
ああ、確かに仕様書の版をかさねていくと
前の版で削除された仕様が、現在あるものとして
頭に残っていることとかがあるな。
ゴーストと呼んでいるんだけど。

Ghost=大脳

上司や客先に出す資料のネタとしてしか使いどころがない。
できて困ることは無いだろうが、できなくて困ることがあるとは思えん。
そもそもJavaって時点で予算ギリギリ寄せ集めのプロジェクトだし・・・
どこまで金のかかるプロジェクトになればUML見ることが出来るんだ？

>>160
客先に出すなんてすごいな。
それだけでもかなり活用してる方だ。

>>160
> 上司や客先に出す資料のネタとしてしか使いどころがない。
> できて困ることは無いだろうが、できなくて困ることがあるとは思えん。
> そもそもJavaって時点で予算ギリギリ寄せ集めのプロジェクトだし・・・

詳しく、「Java ⇒　ぎりぎり寄せ集めのプロジェクト」
という論理について説明して。

新人や外人とともに戦うWebアプリ屋だったんじゃね？

皆さん、注目してください！！！！！！！！！！！！！！！！！
　
C言語厨の正体は高卒であることが発覚しました！
さあ、Java叩きに必死になっているC言語を思う存分報復し虐めてあげましょう！！！


専門卒や高卒でPG/SEの人っているの？Part2
http://pc8.2ch.net/test/read.cgi/prog/1141003614/

レスが全部詭弁だったってばれた法政卒が暴れてるだけだよ。
？？ １：事実に対して仮定を持ち出す
？？ ２：ごくまれな反例をとりあげる
？？ ３：自分に有利な将来像を予想する
？？ ４：主観で決め付ける
？？ ５：資料を示さず自論が支持されていると思わせる
？？ ６：一見関係ありそうで関係ない話を始める
？？ ７：陰謀であると力説する
？？ ８：知能障害を起こす
？？ ９：自分の見解を述べずに人格批判をする
？？ 10：ありえない解決策を図る
？？ 11：レッテル貼りをする
？？ 12：決着した話を経緯を無視して蒸し返す
？？ 13：勝利宣言をする
？？ 14：細かい部分のミスを指摘し相手を無知と認識させる
？？ 15：新しい概念が全て正しいのだとミスリードする
チェックしてね＾＾

はいはい高卒C言語厨君必死だね

（・∀・）ｲｼﾞｮｳｼﾞｻｸｼﾞｴﾝﾃﾞｼﾀ