비비나비 : 로스앤젤레스 : (미국) Los Angeles

• Recess
• 2004/05/15 (Sat) 17:49
• 신고

私も興味があります。プログラミングには色々ありますが、どの種類のプログラミングでしょうか。

• hills
• 2004/05/15 (Sat) 18:30
• 신고

私も興味あります。
技術以外に、仕事の話など興味ありますね。
将来性とか。。。
何しろ、ＣＳメジャーなので、気になります。
ソフト系でしょうか？

• ぷろぐらみんぐ
• 2004/05/16 (Sun) 03:42
• 신고
• 삭제

私はC,C++を勉強しました。プログラミングを勉強したり、実際に作ってみたりしていますが、今ひとつ仕事の経験がないので、プログラミングでどうゆうことができるのかがはっきりわかりません。　学校で勉強したり、家で独学してJavaなどもやっていますが、学校にいる人たち（プログラミングをやっている人たちや自分も含めて）は、ひとつのプログラミングを作るにも、時間と、頭をつかって、苦労して完成させるためか、あまり詳しくおしえあったりという事がないような気がします。実際に、プログラマーだった人にアドバイスをしてもらおうとしても、余計に混乱するような回りくどい説明だったりします。　プログラマーの方がいれば、実際にプログラミングを使って、どのような仕事をされていたのか、教えていただけませんか？　まだまだ駆け出しなので、本当に初歩的な質問ですが、お願いします。もちろん現代の社会には、プログラミングが使われているシステムだらけなのは理解できますが、実際に、身近な日常でどのように活かされているとか、例をだして教えていただけるとありがたいです。

• チョコばなな
• 2004/05/16 (Sun) 12:07
• 신고

彼氏がCSメジャーで卒業し、現在プログラマーとして働いています。
やはり学校で学んだことよりも、仕事をしてからのほうがたくさんのことを覚えた、と言ってます。
お給料は65K強もらっています。子供がいないので、今は彼のお給料だけでやっていけています。
＃4さんの質問ですが、身近な日常で、というのは会社に雇われて、ということでなく、個人的に、と言う意味でしょうか？

• Scottc
• mail
• 2004/05/16 (Sun) 15:38
• 신고
• 삭제

渡米前は日本の会社でSEをやってました。主にVC++やそれに似た言語で組んでました。
具体例を出してしまうと迷惑をかけてしまうんで、もし詳しく知りたいのであればメールください。
例えばショッピングサイトを作るとしましょう。その会社ではデータベースで商品の管理をしてます。お客さんはブラウザを使って商品を検索したりオーダーします。
プログラムの核になるのは商品管理データベースです。
このシステムは大きく分けて、(1)データ管理部、(2)HUI(HumanUserInterface)部、(3)ネットワーク部でつくります。
(1)データ管理部は、複数のお客さんのＰＣからくる更新・閲覧の要求を順序だてて処理します。関連する計算もするし、ＰＣからの要求を制限したり拒否したりもします。普通はデータベース・サーバ上で動作します。ホストプログラムともいいます。
(2)ネットワーク部はネットワークカードの管理はもちろん、ＰＣ〜データベース間の要求のやり取り方式(こまんどフォーマット)やプロトコル管理なんかをします。これは直接お客さんにデータベースをいじらせないために、そしてデータベースの情報は分かりにくいので、お客さんの言葉に近くなるよう仲介をします。
(3)HUIは皆さんにおなじみのパソコン画面を見ながら、TEXT BOXに文字を入力したり、欲しい条件にあった情報を表示してあげたりします。クライアントプログラムともいいます。
このときHUIの処理自体は人間の代わりにネットワーク部をつかってデータ管理部にアクセスするだけです。
誤解されやすいですが、HUI自体がデータベースの更新等をするわけではありません。データの処理をデータ管理部ににお願いするだけです。だって、もし各ＰＣでそういう処理をするように作ったらデータの処理内容を外部にもらしてしまいますから。ついでにデータベースの変更があったとき、全てのプログラムの変更すべき場所を探し出し、プログラムを作り直さないといけないからです。まぁ余談ですが。
とまぁ、分かりにくいかもしれませんが、プログラムのほとんどは、データベース＆データ処理部、HUI(GUI)、ネットワーク(メッセージング)に分割して作っていきます。お客さんとはデータをどうやって管理するか、お客さん用の端末をどうやって見せるか、を話し合います。そしてそれらを実現するにはどういう処理をしてあげなくてはいけないかを大きなコンセプトから徐々に細かく分割して、最後にみんがが授業でやったような、Input＆Outputでお互いをつなげあっていくプログラムを作っていきます。
これって、Windowsとかで動く単体のプログラムでも同じコンセプトです。
例えばWindowsMediaPlayerで動画を見るとします。データファイルの読み取りをするデータ部、それをデコードしてImage情報としてHUIに渡してあげるデータ処理部、表示はもちろん、早送り・一時停止などの操作をユーザに提供するHUI部、各種Window達とそのホストプロセスを仲介するメッセージング部といった具合に作っていきます。
モノにもよるけど、普通はプログラムの設計、プログラミング、テストの３段階で進み、それぞれ同じくらい時間がかかります。
特にプロとアマの違いはテストでしょう。プログラマにとって一番つまらない工程だけど、これを十分にできない会社(Micro$oft？)は後でユーザからものすごいブーイングにあいます。契約しだいでは損害賠償ものです。
チョコばななさんの言うとおり、仕事を始めてからのほうが上達します。そして常に仲間と情報交換したり、プログラマのフォーラムサイトなどで勉強したりします。これ以上書くとますます混乱させるだけなので失礼します。

• booi
• mail
• 2004/05/16 (Sun) 19:39
• 신고

自分も興味があって勉強中なんですがなかなか苦労してます。できればオフ会やりませんか？

• Scottc
• 2004/05/16 (Sun) 20:18
• 신고

正直、私もいろいろ苦労しました。老婆心ながら一言。「分からないことがあったら適当に見切りをつけて人に聞こう」が鉄則だと思います。
”バリバリ”コーディングできるようになってしまうと、「なんであんなことに・・・」って笑っちゃうことも、たった一つの構文ミスで全く動かないのがコンピュータの世界。とくに自分の得意分野以外は、どんなプロでも素人同様、さっぱり分からないのが事実です。
プログラムに挑もうとしている皆さんは、恐れずに恥ずかしがらずに、隣の人や先生、フォーラムサイトにすがりつきましょ。
「自分の環境はこれで、"何"がやりたい。"ここ"までは分かる。」ってのを伝えると、エンジニア系の人ってうるさいくらいに教えてくれたりします。

• ボールペン
• mail
• 2004/05/17 (Mon) 05:52
• 신고
• 삭제

確かに自分の分野以外はとぼしくなりがちですよね。まあ、それはそうと今からはじめられるかたがたに、http://www.crew.sfc.keio.ac.jp/lecture/mmb2000/JavaLectures/top_page/flamebase.htmlこのサイトなどで勉強するのもいいかもしれません。いちからできていいかもです。

• piroです
• 2004/05/17 (Mon) 11:00
• 신고

＞scottcさん
SEをなさっていたとのことですが、著作権などの処理はどうなさっていたのでしょうか。
私自身、ソフトを作って売る仕事ではないのですがもしそうなった場合、オープンソースした場合もしくはしない場合の著作権侵害に当たらないようにするには、どうされていましたでしょうか。

• Scottc
• 2004/05/17 (Mon) 23:40
• 신고

正直、著作権に真剣に取組んでいませんでしたね、私の会社では。もちろんインストール時に出てくる使用許諾の際に、(丸ごとの)盗用禁止に同意してもらいます。webでコード公開している人も著作権保護・放棄に同意を条件にしてたりしますよね。著作権の基本ルールは「著作権出願以前に広く公開されているものは著作権保護の対象にならない」ですから、本で出版されているものや、みんなが使っているコードを使う場合は、はなっから著作権を無視してしまうのが現状でしょう。
よっぽど革命的なルーチンを書かない限り特許には穏やかです。システム特許は別ですが。
もし著作権侵害に当たる場合は速やかに著作権オーナに連絡し使用許諾を得ます。コピー機等の製品開発では少なくても100くらいの特許を申請するみたいですので、他社の特許を侵害することが沢山あります。その場合、クロスライセンシングといって、特許の貸し借りをして帳尻を合わせるみたいですね。
さてと本題です。
彼らが一番神経を尖らせるのは、コード改変時の責任放棄です。もしプログラムがトラぶったとき、会社はそれをサポートする義務が出てきます(普通はただで)。運用開始半年はお客さんからのクレームに怯えながら時が過ぎるのを待ちます。問題があれば原因究明・修正・テストして、問題解決ならお客さんのところに持っていきます。でもね、部分修正が他に波及しない保証はないので、それもチェック。これ一番しんどい作業。だからトラブルの原因が"お客さんによる"コード改変によるものなら責任とりたくないですよね。ので、「ユーザによるコード改変やリバース・エンジニアリングによる不具合の発生は一切の責任を負いません！」ってのに同意させます。実際あるんです、仕様変更でまたお金を払うのが嫌で、会社がプログラミングに詳しいシステム部の人使って改造するの。
金ケチられてトラぶって責任を押し付けられないように、必ず責任放棄の条文に同意させましょう。

• piroです
• 2004/05/18 (Tue) 07:50
• 신고

やはり曖昧なものなんですね。
コード書いていって使う名前なんて同じ物が多いし、FOR（）だってWHILE（）だってみんな使うでしょう。
たとえば同じ動作のソフト（UIも同じ）が片方は著作権があり片方は無いとするとソースがまるで違っていても無い方は訴えられるんでしょうか。それとも何％までは同じでもいいがそれ以上は駄目とかあるんでしょうか。
ソースが違うものは著作権侵害に当たらないとすれば、何でも作れますよね〜。

• Scottc
• 2004/05/18 (Tue) 11:12
• 신고

よっぽど儲かってるソフトかコンスーマ向けでない限り気にしないだろうね。例えばMicrosoftはLYNUXを潰すためにコード特許を主張したけど、逆に世界中から「すでに公開されてた」って突っ込まれたりしてたし。よっぽど戦略的に特許をとらない限り上手くいかないんじゃないかな？
人のコードを見てるとその人の性格が見えるね。大胆だったり、臆病だったり。マメな人、雑な人。for文やwhile文なんて特にそう。構文自体が条件式をもってるけど、それをループ判定に使わずに、ループの中で自力で判定したり、for文を全く使わずにwhile文だけで済ませてる人とか。
変数の範囲は決まってるけど、万が一のために上下限判定をつけたり。
だからあとで誰が読んでもわかるようにコメントを入れるようにしてるよ。特に会社は部署移動で後任者に引き継ぐとき大変だから沢山いれるね。昔、先輩にコメントはコードの倍ぐらいいれろって言われたことある。特に処理が込み入ったり、他のルーチンとの同期が大事な場所を重点的に。そうするとみんなでコードを使いまわすときに便利だしね。

• sed
• 2004/05/18 (Tue) 11:45
• 신고

>実際あるんです、仕様変更でまたお金を払うのが嫌で、会社がプログラミングに詳しいシステム部の人使って改造するの。

ちゃんとバージョン管理して(cvsでブランチ作るとか)、パッチ作ってくれる分には構わないけどね。しかし、こういう会社に限って、バックアップもとらずに、本番系のシステムを行き成り書き換えたり...(^^;

• piroです
• 2004/05/18 (Tue) 12:18
• 신고

そうですか。多分大丈夫ってとこでしょうかね。
これからは安心してがりがりと”もどき”ソフト作ってこうと思います。