> > > | シグマ・コンピュータで動かしていたのと全く同じプログラムを、
> > > | 普通のコンピュータで動かしたら１００倍くらい高速になったのだ。
> > > この話がよくわからんのです。たかがOSの違いで、100倍の性能差が
> > > 出るものなのでしょうか。
> > これはOSだけじゃなくて、ハードウェアなのでは?
> 藤原さんのページによると、
> | コンピュータのハードウェアは全く同じで、シグマのソフトウェアを
> | 載せたのと、世界中に出回っているアメリカで開発されたソフトウェアを
> | 載せた２種類のコンピュータがあった。
確かに藤原さんのページだけ読むとその様に読めますね。
私の読み方のほうが間違ってました。
ただ、実は他のページ読んで、
シグマはハードウェアの規格だと思いこんでしまいました。
そのページって言うのは↓なのですが、
http://www.sra.co.jp/people/k2/miscellany/sigma.html
もう一度、読んでみたらどこにもシグマはハードウェアの規格だ
なんて書いてないですね。勝手に勘違いしてしまったようですf(^^;)
# この投稿の元になった投稿は、裏掲示板に投稿されたものですが、
# 返信を書いたら文字数制限でひっかかりましたし、話題自体表向きだと
# 思いますので、表に振ります。あしからずご了承ください。
>はじめまして。
はじめまして。
>とりあえず、目立ったツッコミ所を列挙しますと・・・
引用順をちょっと変えます。
> ・main関数はvoidにすべし(ANSI規格って見たことありますか？)
これは、規格からするともちろん変なんですが、高々1箇所なので
実害は少ないですよね。ていうかなんでこんなことを規約で縛ろうと
するのかがむしろ不思議です。
> ・関数の再帰呼び出しは原則禁止(リストや木構造は使うなと)
必要もないのに再帰を使うのはよくないと思いますが(階乗の計算
くらいループでできるだろうと)、木構造では避けられませんよね。
> ・includeのネストは原則禁止(まさかMakefileを手作業で作っているとか？)
この規約は実によく見ます。割と権威があるはずの(C FAQでも
取り上げられている)Indian Hillのコーディング規約にすらこれが
書いてあります。
http://www.gfd-dennou.org/arch/comptech/cstyle/cstyle-ja.htm
| ヘッダファイルはネストしてはならない。したがって
| ヘッダファイルのプロローグでは、このヘッダが機能
| するために他に #include しなければならないファイルを
| あげておくべきである。いくつかのソースファイルが
| 多数の同じヘッダをインクルードしなければならないと
| いうような極端な場合は、共通する #include をひとつの
| インクルードファイルにまとめるのもよいだろう。
あるヘッダが機能するためには、普通別のヘッダファイルが
たくさん必要になるので、「多数の同じヘッダをインクルード
しなければならないというような極端な場合」というのは極端でも
なんでもなく、当たり前の状況だと思うんですが… はっきり言って
支離滅裂です。
この時代には、そんなに巨大なプログラムはなかったんですかね。
> 天下の大企業の規約とは思えんです・・・
いやあ、天下の大企業でも、統一コーディング規約を持って
いるわけではないでしょうし。たいていはプロジェクトごとに
ばらばらなんでは。
>またおもしろそうなモノがあれば紹介しますね。
よろしくお願いします。
私がよく見たのは、「1ソースファイル1関数」ですねえ。
あと、「変数名は8文字以内」とか、「関数名はプレフィクス+番号」とか、
ひどいのだと「関数を呼び出すときには、引数を必ず変数に代入しろ」
とか。FORTRAN時代の名残なんでしょう。これはさすがに守られて
いませんでしたが。
> > | シグマ・コンピュータで動かしていたのと全く同じプログラムを、
> > | 普通のコンピュータで動かしたら１００倍くらい高速になったのだ。
> > この話がよくわからんのです。たかがOSの違いで、100倍の性能差が
> > 出るものなのでしょうか。
> これはOSだけじゃなくて、ハードウェアなのでは?
藤原さんのページによると、
| 正確には、シグマ計画で作り上げた物は、コンピュータではなく、
| シグマＯＳというコンピュータを制御しているオペレーティング
| ・システムであるが、そんな細かいことはどうでも良い。
…
| コンピュータのハードウェアは全く同じで、シグマのソフトウェアを
| 載せたのと、世界中に出回っているアメリカで開発されたソフトウェアを
| 載せた２種類のコンピュータがあった。
とありましたから、ソフトだけを変えたんじゃないかと思ったわけですが。
ただ、前回挙げたこっちのページには
http://www.zdnet.co.jp/macwire/0006/20/c_kangaroo.html
| 早い話が「どんな機械を作れば通産省がそれを『シグマ・ワーク
| ステーション』と認定してくれて開発費を持ってくれるか」と
| いうのを爺さんたち，午前中とは打って変わった熱心さで学んで
| らっしゃったわけである。
とありますし、ハードの規格も存在したわけですよね。
でも規格があるにせよ、後方互換性がある範囲で性能を上げる分には
問題ないんじゃないかとも思うんですが…
もし、単に、既にシグマが衰退していてどのメーカーもわざわざ
性能向上なんかやろうとしなかった、というのなら、
それはまた別の問題のような気がしますし。
てなわけでいろいろGoogleしたら、ヒットしたのは2chのスレ。
http://216.218.192.139/infosys/kako/977/977484630.html
>>12
| 3)横並びのハードウェアスペックを作るために、参加メーカーの一番レベル
| の低いところでも開発可能なスペックをあわせた。出る杭を打ち込んで、
| 世界的に通用しない機械をメーカーに強要した。
うーん。
ところでこのスレ>>33に渡邊克宏さんが降臨してる…
>>33で挙げられているページは現在は
http://katsu.watanabe.name/doc/comphist/
にありますね。
> | シグマ・コンピュータで動かしていたのと全く同じプログラムを、
> | 普通のコンピュータで動かしたら１００倍くらい高速になったのだ。
> この話がよくわからんのです。たかがOSの違いで、100倍の性能差が
> 出るものなのでしょうか。
これはOSだけじゃなくて、ハードウェアなのでは?
進歩を止めたシグマ規格のハードウェアで動作させていたプログラムを
進歩し続けてる普通のコンピュータで動作させたら、
100倍くらい速かったという意味では?
いや、正直私もわかってていってませんが、
前後関係から そう読んだのですが。
>LinuxをベースにOSを作るなら、それは「国産」OSではない
たぶん某食品業界みたいに出産地ではなく“出荷地”で決めているとか（笑）。
いちおう“出荷”は国内なので国産牛です。とか。
インド人や中国人が手がけていても日本国内で宿泊させて作らせれば国産（おい）。
> コンピュータが進歩しないという大前提
この発想がどこから出てきたのかが知りたいと思うのは私だけ？
> この話がよくわからんのです。たかがOSの違いで、100倍の性能差が
> 出るものなのでしょうか。
読んでみましたが良く解りませんでした・・・
シグマが「進化しないマシン」に乗せられたとして、
その古いスペックのマシンと最新のマシン（シグマ完成時）で比べた結果とか？
# シグマはコンピュータが進化しない前提で作成されたので
# 最新マシンで走らせると対応ドライバなくてハングったりバグったりする。
# だから同じマシンでは比較できなかった、という理由だったら笑うしかないですね。
> ところで政府がLinuxをベースにOSを作るなら、それは「国産」OSでは
> ないんじゃないかと思うんですが、どうでしょうか。
あっ。確かに(^^;;;;;;;;
ニュース読んだまま吟味しないで超ボケかましました。
# ここは「純国産」じゃないので・・・って逃げようかしら。:-D
国がLinuxディストリビューションを作って便乗商売でも始めたいのでしょうか。
# なんか色々と対応が遅くて苦情でまくりなんじゃ・・・。:-p
> シグマの悪夢の再来ですか？（笑）
シグマプロジェクトがなぜ失敗したのかについては、藤原博文さんの
本とか、以下のページ
http://www.zdnet.co.jp/macwire/0006/20/c_kangaroo.html
なんかを読むと「コンピュータが進歩しないという大前提を立てて
開発した」ということになっていますが、確かにその前提がムチャなのは
当然として、
http://www.pro.or.jp/~fuji/mybooks/okite/okite.9.1.html
| シグマ・コンピュータで動かしていたのと全く同じプログラムを、
| 普通のコンピュータで動かしたら１００倍くらい高速になったのだ。
| 高速化の作業は不要になってしまった。シグマ・コンピュータの
| ソフトウェアを捨て去り、普通のコンピュータに直してしまえば
| 要求を完全に満たしてしまうのだ。業務用に開発したソフトウェアは
| 一切手をつけなくても高速になったのだ。
この話がよくわからんのです。たかがOSの違いで、100倍の性能差が
出るものなのでしょうか。
ところで政府がLinuxをベースにOSを作るなら、それは「国産」OSでは
ないんじゃないかと思うんですが、どうでしょうか。
> > 誘導されたことに後からでも、気がつければいい方で、
> > ある人はいつまで経っても「自分のアイディアだ」と思い込んでます。
> ここまでいくと神業かも。
もっとも、私も「神業」を見たのは1度だけです。(^^;)
いつも誰にでも通用するわけじゃないみたいですし、
やっぱり、神業には相手もある程度の能力が必要みたいですし。
相手の立場がよほど上の場合でないと通常は使わないようです。
> たとえば新人相手にJavaとかを教えているとき、「なぜ動かないのか」と
> 質問があれば、原因を絞り込む手伝いだけをして、なるべく最後は
> 本人に問題を発見させるようにしてはいますが、「ええいじれったい」と
> 答えを言っちゃうこともしばしば (^^;
私も堪え性がないので...イライラしてついっ(X.X)
> 説得がうまい人は相手に自分の意見を言わせますよ。
ここまでは、誘導的な質問を繰り返せば割と用意に可能ですが、
> あたかも相手が自分の言いたい意見に自力でたどり着いたように装うんです。
これは至難の業ですね。少なくとも私には。
> 誘導されたことに後からでも、気がつければいい方で、
> ある人はいつまで経っても「自分のアイディアだ」と思い込んでます。
ここまでいくと神業かも。
たとえば新人相手にJavaとかを教えているとき、「なぜ動かないのか」と
質問があれば、原因を絞り込む手伝いだけをして、なるべく最後は
本人に問題を発見させるようにしてはいますが、「ええいじれったい」と
答えを言っちゃうこともしばしば (^^;
住基ネットの不祥事のせいか、何やら国産OSがどうのこうのと騒いでおりますが、
どうなんでしょうね。というか、今更！？ TRONは？
Linuxベースらしく、また揉めて立ち消え→税金が無に帰す
という気もしないでもないです。しかも今後増税していくっていうのに。;-<
皆さんはどう思います？
> 説得がうまい人は相手に自分の意見を言わせますよ。
> 相手が自分で気づく様に質問で導くんです。
難しい。でもそれができると相手の能力を引き出せますね。:-)
> ある人はいつまで経っても「自分のアイディアだ」と思い込んでます。
もし、そうだとしても「その次」で良い方向に向くキッカケになるならグッドですね。
> 誘導テクだけじゃなくて本当に妙案を思いつく奴なので
> 私も気持ちよく誘導されてしまうことがあります。
いいなぁ、こういう方とも仕事がしてみたいです。
> みたいなのを「設計書」と呼んでいるプロジェクト。
それでプログラムを直すと設計書に反映してて・・・
終いにはプログラムコードをそのまま貼り付けてしまってたプロジェクトも(^^;
> 構造体宣言をネストすると表現できないっちゅうに。
C++とかJavaなんかでクラスを定義したらもっと大変なことに！？
> 「同じことを複数の箇所に書くな」という原則に反します。
結局、プログラムも設計書も書き方は一緒ってことですね。
重複した情報が散乱しないようにドキュメントにまとめる。
# プログラムなら共通のインクルードファイルにまとめる、ですね。
DBテーブルの正規化なんかがありますがこれも似たようなものでしょうね。
つまり、プログラマはプログラムを綺麗に書く練習をしないと、
いざアプリやテーブルの設計をさせられた大変なことになる、と。;-<
> 「表示区分」があるところでは「表示コード」になったり「表示種別」に
> なったりして何が何やらわからなくなるもんなんですよね…
そういう微妙に違うのってありますね〜。
あとローマ字のプロジェクトは「sho」と「syo」などが混在していたり。
# ローマ字表記も体系があるのになんで使用しないのだろう・・・？
> たとえば列挙型はint型よりは抽象度が高いわけですが。
> Javaマンセーな人は最近になってようやく気づいたんですかね:-p
いやいや。未だに#defineしたり、constにしたりして名前をつけると
「なんか解り辛い」っていうCプログラマもたくさんおりますので。;-)
# なんかラッパーが嫌いな人もいそう・・・。;-<
> > 相手を怒らせない様に相手に間違いを認めさせる技術力 :-P
> 40間近のオッサン相手に腫れ物に触るように・・・ですか。嫌過ぎ。;-<
説得がうまい人は相手に自分の意見を言わせますよ。
相手が自分で気づく様に質問で導くんです。
あたかも相手が自分の言いたい意見に自力でたどり着いたように装うんです。
質問で誘導するんです。とりあえず相手の意見に同意した上で
「すると〜の場合は、どうしたらいいんでしょう?」と
答えがわかりきった質問を繰り返します。
結論にたどり着くための階段を用意するんですね。
私の知り合いにいるのですが、
誘導テクだけじゃなくて本当に妙案を思いつく奴なので
私も気持ちよく誘導されてしまうことがあります。
誘導されたことに後からでも、気がつければいい方で、
ある人はいつまで経っても「自分のアイディアだ」と思い込んでます。
> これは、プログラミング言語のステートメントを使って、
> 書いているプロジェクトもありますね。
ありますね。
if (入力値 < 0) {
エラー表示("入力値がマイナスです");
}
みたいなのを「設計書」と呼んでいるプロジェクト。
> あとはDBのカラムに入っている値を設計書に書いたりとか。
これもありますね。DBの表定義に限らず、構造体の定義まで
Excelで書きたがる人っています。
構造体宣言をネストすると表現できないっちゅうに。
> 区分がその値だったらどういう意味になるのかを教えてほしいです。
> # 「〜コード一覧」ってのを作成してくれれば済むのですが・・・
そういう区分はCなら列挙型になるべきものであり、それがドキュメント上で
「整数型」になっているようじゃ、もうソースを見るほうがマシというものです。
その「何とかコード」は意味的に「型」なので、あっちこっちに登場するはずで、
その型の、変数やメンバやDBのカラムにいちいちコード一覧を書くことは、
「同じことを複数の箇所に書くな」という原則に反します。
よって、DBMSに列挙型がなかろうと、その言語に列挙型がなかろうと、
せっかくドキュメントを書くのなら、ドキュメント上では「列挙型で
あるかのように」扱えなければ嘘だと思うんですが、所詮手書きのドキュメント、
「表示区分」があるところでは「表示コード」になったり「表示種別」に
なったりして何が何やらわからなくなるもんなんですよね…
> > でも、「抽象度が高い」という言葉は、なかなか理解してもらえないものです。
> 仰りたいことは解るのですが、なんと言ってよいのやら・・・
たとえば列挙型はint型よりは抽象度が高いわけですが。
Javaマンセーな人は最近になってようやく気づいたんですかね:-p
> コメントもそうですけど、「ソースを見ればわかることをいちいち
> 繰り返すことはない」と思います。どうせ変更に追従できないんですし。
これは、プログラミング言語のステートメントを使って、
書いているプロジェクトもありますね。
あとはDBのカラムに入っている値を設計書に書いたりとか。
区分がその値だったらどういう意味になるのかを教えてほしいです。
# 「〜コード一覧」ってのを作成してくれれば済むのですが・・・
> でも、「抽象度が高い」という言葉は、なかなか理解してもらえないものです。
仰りたいことは解るのですが、なんと言ってよいのやら・・・
# 最近流行りのSE本には書かれていますかね。:-p
> 納得できる力を持っていてなおも納得しない人にならなくちゃいけないのではないかと。
> 日々精進ですね。私もがんばらなくちゃ(^^)
む、難しいですね。私も精進します。
> 結局バランスでしょうけど。
そうですね。書くことが義務になってしまうと、
文章の盛り込み方も段々おかしくなってくるのかも。
> 休むに似たりなのかしら。f^^;
かと言って、後から良い案が浮かぶと
「もうちょっと吟味できたんじゃないのか？」なんて人もいますし(;^^A
> 相手を怒らせない様に相手に間違いを認めさせる技術力 :-P
40間近のオッサン相手に腫れ物に触るように・・・ですか。嫌過ぎ。;-<
しばらく旅に出てました。左腕が盛大に日焼けしてます。
> > 会社によって同じ外部設計書・詳細設計書と言われるものでも
> > どう考えてもメモ程度だろうってものから、結構細かく書かれているな〜って
> > ものありますね。
> どっちがいいんでしょうね。肝心なことが書いてないのは論外ですが、
> 細かく書くことを義務付けているようなところって
> 書くことが大事になっちゃったりしません?
コメントもそうですけど、「ソースを見ればわかることをいちいち
繰り返すことはない」と思います。どうせ変更に追従できないんですし。
量の問題もありますが、プログラム以外のところにプログラムの説明を
書くのなら、プログラムそのものよりも抽象度が高くなくちゃ無意味
なんですよね。
でも、「抽象度が高い」という言葉は、なかなか理解してもらえないものです。
うまく説明する方法はないものか…
> > 何年経っても、納得いくような答えは出ない気もしますが。
> それを言われちゃうと辛いです（笑）
むしろ納得してそこで止まっちゃう方が怖い。
納得できる力を持っていてなおも納得しない人にならなくちゃいけないのではないかと。
日々精進ですね。私もがんばらなくちゃ(^^)
> 会社によって同じ外部設計書・詳細設計書と言われるものでも
> どう考えてもメモ程度だろうってものから、結構細かく書かれているな〜ってものありますね。
どっちがいいんでしょうね。肝心なことが書いてないのは論外ですが、
細かく書くことを義務付けているようなところって
書くことが大事になっちゃったりしません?
結局バランスでしょうけど。
> > 「ある課題が与えられたときに、少なくとも実現するための2通りの方法を検討しろ」
> やっぱり互いのメリット・デメリットを計りにかける癖をつけるためでしょうね。
> プログラムだと何通りか書き方があると思うのでこれはかなり有効かも。
私は、一番最初にひらめいた方法を最終的に採用することって多いんですけど
一旦、完全に否定する理由を探して、別案も考えますが、
周りから見るとモドカシイらしく、
なに、そんなこと悩んでるの?○○ってやり方(私が最初に思いついた案)で
決まりじゃんとか言われたり。
休むに似たりなのかしら。f^^;
> > 最初の印象や、礼儀正しくない言葉を聴いた瞬間に
> > 相手の意見を解釈する脳内回路を切断してしまう人もいますね。
> > 反対意見を言われた段階で切断しちゃう人とか。
> 今のリーダーがそうです。
> 思い違いをしているところとか指摘すると、
> 「こんなことは解ってるんだ！！」と逆ギレします。;-<
> 「なんだよ、じゃぁお前は引数から何から熟知しているのか！？」と
> 逆ギレされたことも（笑）
じゃあ、一番最初に身につけなくちゃいけないのは
相手を怒らせない様に相手に間違いを認めさせる技術力 :-P
...難しそう(^^;)
> 何年経っても、納得いくような答えは出ない気もしますが。
それを言われちゃうと辛いです（笑）
> 短期間でころころプロジェクトを移っていると
> 本質を理解する前に目の前の問題だけを解決するような状態になるかもしれませんね。
そうですね。プロジェクトへの就業期間が短いと、
業務的な流れを理解する前に次のところへ移ってしまいます。
> 逆に色々なstyleを経験できるので、自分の切り口をドンドン新しくしてくれるかも。
良いところ、悪いところを色々見れるのは確かにメリットかもしれませんね。
会社によって同じ外部設計書・詳細設計書と言われるものでも
どう考えてもメモ程度だろうってものから、結構細かく書かれているな〜ってものありますね。
# でもどこの会社行ってもコーディング規約には
# 「sizeof関数」と書かれているのには閉口します。:-p
> 本サンプルって説明しやすくするために、バカに短くなっているのでどうですかね。
> 理論で本質をつかむために本を読むのはいいんですけど。
私はサンプルをそのまま打ち込まないですね。
自分がやってみたい処理の部分だけを読み取って抜き出すのが好きというか。
学校の勉強でも読むだけより実際に自分の言葉にまとめて
書いてみたほうが良く憶えるって話もありますね。
> 「ある課題が与えられたときに、少なくとも実現するための2通りの方法を検討しろ」
どこかで聞いたことがあるかも。
やっぱり互いのメリット・デメリットを計りにかける癖をつけるためでしょうね。
プログラムだと何通りか書き方があると思うのでこれはかなり有効かも。
> よく調べたらテストプログラムのデバッグ中の変更を元に戻し忘れて
私はシェルスクリプトのデバッグのために、
if文の演算子をnot条件にしてテストして、
そのまま結合環境に持っていってしまったことが・・・
# テスト項目は全部通してあったのですが。
シェルのスクリプトデバッガってのないですかね？
（え？ 自分で作れって？）
念のため最後に正常系をもう一度流すべきだと学びました。
> 慎重さってどうやったら身につくんでしょうね。
> どうも気がつかないんですよね。肝心な部分に。
まったくです。
> 最初の印象や、礼儀正しくない言葉を聴いた瞬間に
> 相手の意見を解釈する脳内回路を切断してしまう人もいますね。
> 反対意見を言われた段階で切断しちゃう人とか。
今のリーダーがそうです。
思い違いをしているところとか指摘すると、
「こんなことは解ってるんだ！！」と逆ギレします。;-<
ひとつ前のプロジェクトでは、
リーダーが知らなかったUNIXコマンドをたまたま私が知っていたので
「こういうのがありますよ」って教えてあげたのですが、
「なんだよ、じゃぁお前は引数から何から熟知しているのか！？」と
逆ギレされたことも（笑）
# つくづくリーダー運の悪い私
> よく調べたらテストプログラムのデバッグ中の変更を元に戻し忘れてて
> 全部の試験項目をやってなかったとかいう(T-T)
あー、それやっちゃったことあります…
http://member.nifty.ne.jp/maebashi/seiha/hosoku000.html#miss
読者の皆様には、どうもご迷惑をおかけしました。
> 慎重さってどうやったら身につくんでしょうね。
つくづく。
> そこはそれ、プログラマたるもの、ミスを犯さないよう精神集中するよりは、
> ミスを犯さないようなシステムを考えるべきなんでしょうが。
> 単純作業は自動化するとか。でも、これが忙しさにかまけているとなかなか。
自動化する段階でミスをするとか(^^;)
この前、全テストを自動化して実行できるるような
テスト用のプログラムを作って、PASSが出たんですけど、
お客様のところへ持って行ったら動かないなんてことがありました。
よく調べたらテストプログラムのデバッグ中の変更を元に戻し忘れてて
全部の試験項目をやってなかったとかいう(T-T)
慎重さってどうやったら身につくんでしょうね。
どうも気がつかないんですよね。肝心な部分に。
> でも、10人前の仕事というか、きれいな設計ができる人は、
> かなりの確率でCommunicationのスキルもあるように思います。
そうですね。少なくとも相手の意思を理解する能力はある人が多いですね。
中には逆に誰がどう聞いても誤解のない様に見える文章を読んで
ありえないような誤解をしてくれる人もいますが。
そんな解釈はありえないだろ。常識的に考えて。って言いたくなる人。
相手にうまく説明できるskillとなると、極端に少なくなる気がしますが。
私に関して言えば、他の能力はともかく、説明ベタの人から必要な情報を
うまく聞き出す能力は身についてきたかな。
> いわゆる「礼儀正しい」かどうかはともかくとして、少なくとも
> 「何言ってるのかわかる」という点で。
最初の印象や、礼儀正しくない言葉を聴いた瞬間に
相手の意見を解釈する脳内回路を切断してしまう人もいますね。
反対意見を言われた段階で切断しちゃう人とか。
reviewなんだから、反対意見もちゃんと聞いてくれよ〜＞社内の某氏 (T-T)
> > > 9.注意力
> > これが一番自信なし(^^;
> > 徹夜すると単純なポカをよくやりますし。
> 私は徹夜しなくてもよくやります。f(^^;)
そこはそれ、プログラマたるもの、ミスを犯さないよう精神集中するよりは、
ミスを犯さないようなシステムを考えるべきなんでしょうが。
単純作業は自動化するとか。でも、これが忙しさにかまけているとなかなか。
設計上のポカは、なんとか早期に検出できるような開発手法をとるとか。
でもこれもなかなか…
> いわゆる「こんぴゅーたおたく」的な人物って仕事じゃ使えないというか。
> 10人前の仕事ができてもcommunication取れない人より、
> communicationが取れる1人前の仕事をする人がいい。
でも、10人前の仕事というか、きれいな設計ができる人は、
かなりの確率でCommunicationのスキルもあるように思います。
いわゆる「礼儀正しい」かどうかはともかくとして、少なくとも
「何言ってるのかわかる」という点で。
いやその、私のことはさておき (^^;
> ここ3年くらい考えて自分の納得の行く答えが見つからなかったので
> こちらに書き込みさせていただきました。
何年経っても、納得いくような答えは出ない気もしますが。
私もいつまで経ってもミスばかりしてますし。
しかも、年々ミスが重症になっている様な...(X-X)
> > systemを作れる/運営できる能力かな。
> ふむふむ。だとすると、私は設計面がかなり弱いから、
> 長期でどっぷり浸かるようなプロジェクトを経験する必要がありますね。
短期間でころころプロジェクトを移っていると
本質を理解する前に目の前の問題だけを解決するような状態になるかもしれませんね。
逆に色々なstyleを経験できるので、自分の切り口をドンドン新しくしてくれるかも。
同じものを続けるのも良し悪しですが、一度はある程度の長さのプロジェクトは
必要かもしれませんね。
> 自分の知識を総動員して、あるいは直感的に答えを導けるか、
> もしくは「解決方法がある」という知識を持っているか、ということですね。
> 前者は大なり小なり経験を積まないとならないものですね。
後者も最近なら知りたいことの核心部分をサクっとWEBで調べられるというのも
能力なのかも。いや、特別な力だとは思わないのですが、
できない人はいつまでもできなかったりしますね。
> 本を読んだだけじゃできないことというか。
> # 本を読むだけじゃなくサンプルを自力で打ち込む人は経験になりますね。:-)
本サンプルって説明しやすくするために、バカに短くなっているのでどうですかね。
理論で本質をつかむために本を読むのはいいんですけど。
誰か(不明)の受け売りですけど、
「ある課題が与えられたときに、少なくとも実現するための2通りの方法を検討しろ」
とかいうのがあって、常にそうしていると、
ダンダンとよりよい方法を考えるクセがつくとかいう。
> > 9.注意力
> これが一番自信なし(^^;
> 徹夜すると単純なポカをよくやりますし。
私は徹夜しなくてもよくやります。f(^^;)
> > 私個人にとっての一番大事な技術力は有能な人といい関係を保つ能力かな。
> いい関係、ですか。難しいですね。
最近のsystemって複雑で、最初から最後まで一人でやり遂げられるような
単純な仕事って減ってると思うんです。
周りと正しい情報を共有することってすごく大事だと思ってます。
いわゆる「こんぴゅーたおたく」的な人物って仕事じゃ使えないというか。
10人前の仕事ができてもcommunication取れない人より、
communicationが取れる1人前の仕事をする人がいい。
いや、communicationが取れる10人前の仕事のできる人が一番だけどそれは。
> 本多さんもおっしゃってますけど、それだけ期待されてるんじゃ
> ないでしょうか。
そうだと良いのですけど・・・(^^;
> 知識ばかり仕入れてもセンスを磨かなければしょうがないし、
> センスを磨くためにも知識は必要。ある時期、知識とセンスの
> 両方を持ったスーパープログラマーであった人も、この業界では
> 新しい知識を仕入れなければセンスの方も腐っていく。
ほるほど。確かにそうですね。
基礎となる知識がなければそれをうまく生かすのは無理ですし、
より新しいものを作っていくためには知識が必要なりますね。
> とはいえ、雑誌で拾った新技術のうたい文句を鵜呑みにするようでは
> 危険ですし。
新技術だからって単に取り入れると、きっと落とし穴に落ちるでしょうし、
デメリット面なんかも良く考えないとダメですね。
# メディアはいい面ばかりもてはやしますけど。
> 日々勉強ですよね。私もがんばらねば。
私も頑張ります。
こんちは(^^)
> これって、すごく難しい質問ですね。
難しいですよね。
ここ3年くらい考えて自分の納得の行く答えが見つからなかったので
こちらに書き込みさせていただきました。
> 技術者としての目的は「要求を満たすsystemを作る/運営する」だから、
> systemを作れる/運営できる能力かな。
ふむふむ。だとすると、私は設計面がかなり弱いから、
長期でどっぷり浸かるようなプロジェクトを経験する必要がありますね。
> ある場面では誰も思いつかなかった 一瞬のひらめきでしょうし、
> ある場面では誰かのやったことをパクることかもしれません。
自分の知識を総動員して、あるいは直感的に答えを導けるか、
もしくは「解決方法がある」という知識を持っているか、ということですね。
前者は大なり小なり経験を積まないとならないものですね。
本を読んだだけじゃできないことというか。
# 本を読むだけじゃなくサンプルを自力で打ち込む人は経験になりますね。:-)
> 9.注意力
これが一番自信なし(^^;
徹夜すると単純なポカをよくやりますし。
> 客観的に評価するなら成果が大きく副作用が少ない場合、技術力が高いでしょう。
なるほど。そうかー。
いくら良いものでもリスク面が強ければダメですものね。
> 私個人にとっての一番大事な技術力は有能な人といい関係を保つ能力かな。
いい関係、ですか。難しいですね。
> それだけ期待されているんじゃないですか?
雰囲気的にあまりそうは思えないんですけど・・・(^^;
> #的外れな回答でしたら、すいません。
いえいえ。雑談を所望してますので。:-)
> 関数のオーバーロードとちゃんと区別できるのか、ちょっと気になったり。
> ＃この辺はC++ではどうなるんでしたっけ？
こういう問題は、なんらかの優先順位を持ち込めば解決するわけですが、
問題はその優先順位が直感的かどうかですよね。
ただ、「Java謎+落とし穴〜」にも書いたのですけれども、私は関数の
オーバーロード自体さほど重要な機能とは思ってないので、
「混乱するような使い方はするな」ってことでよいかと思いますけど。
C++における関数オーバーロードの優先順位は、「プログラミング言語C++ 第3版」
の7.4のところに書いてあるようですが、可変長引数に関する説明は…
これでいいのかなあ?