  |
はてなキーワード: rdbとは
プログラミング言語は何でもいいから、RDB（リレーショナルデータベース、Relational Database）勉強したほうがいいよ。SQL。
RDB＆SQLですか。現時点ではよく分かってないのですが、勉強してみます。
もし勉強の参考になるページ知っていたら、教えていただければ幸いです。
あと、「SEと交渉して安くする」っていうのは、相手先の会社に敵対的にならないように気をつけてね。最悪のケースは、交渉決裂→他の会社をあたってみる→他の会社のエンジニアは、今のシステムを把握していないので、その分までこめて予算を出してくる→結局、今の会社よりも高い金額を払うことになる/気まずいけど、今の会社に再び頼むってことになりかねない。
なるほど、会社かえるとを引き継ぎ完了するまでのコストが発生するってことですね。
それを考えるとやっぱり今の会社に頼むのがいいのかな
プログラミング言語は何でもいいから、RDB（リレーショナルデータベース、Relational Database）勉強したほうがいいよ。SQL。
OracleとかMySQLとか色々あるけど、SQL言語覚えてればどれも大体は似ている。
業務用システムって、たいてい、データベースのエンジンは他の会社が作っている奴とかオープンソースの奴をそのまま持ってきて、データベースと利用者をつなぐインターフェース部分だけ作っているところがほとんどだから。
あと、「SEと交渉して安くする」っていうのは、相手先の会社に敵対的にならないように気をつけてね。最悪のケースは、交渉決裂→他の会社をあたってみる→他の会社のエンジニアは、今のシステムを把握していないので、その分までこめて予算を出してくる→結局、今の会社よりも高い金額を払うことになる/気まずいけど、今の会社に再び頼むってことになりかねない。
一番やって欲しいのは、既存の現場の問題点の洗い出しをして、どういう機能が足りていないのかを、しっかり説明して欲しい。どの機能を加えると、どれぐらいの作業量が必要そうか、という感覚が、頼む側にもあると、やりやすい。
新しいシステムを外注するなら、複数の会社に頼んで見積もりださせてもいいかもしれないけど、稼動中の今のシステムの改良でしょ？今のシステムとまったら、困るわけでしょ？だったら、今の会社に頼むのが一番速い＆安い＆ちゃんとやってくれる気がするんだけど。
中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント
ちょっと囓っただけの素人が自分を過信して陥る三つの罠？
d:id:fromdusktildawn:20081026さんは「共通化とか抽象化ができるようになった中途半端に優秀な』人を対象にしているのに対して、d:id:JavaBlack:20081026さんは『ちょっと齧っただけの素人』を対象（元記事に対してかもしれない）にしているので、適用対象のレベルがそれぞれ違う気もするけど。
d:id:JavaBlack:20081026さんの記事に対するブクマコメントの幾つかやトラックバック先において、『Java屋らしい』との書き込みがあるけれど、具体的に『Java屋らしい』とはどんなことを指すのでしょう？
当方嫌われ者のエンタープライズ開発withJavaな人間ですが、Javaがよく使われるエンタープライズ向け開発などを行っていると、プログラミングは企業入ってから覚えました、っていう人の方がマジョリティだから、こういう“プログラミングのセオリー”のようなものは知る機会がないと言っていい。よほどいい先輩に当たらないと、こういうことすら教えてくれないことの方が多い。
プログラマなら自分で調べて当然、という意見もあるだろうけど、上記“マジョリティ”の彼らは、自宅でコーディングなんてするはずがないし、早くコーディングなんて卒業したい、と考えている人種。
そんな人たちは、こういうことを『知らない』し、『知ろう』とも思っていない。
そういう現場にとっては、
とある程度型にはめて指導することは、とりあえず『最低限のレベル』を守るためには有効だと思うのだけれど。まぁ元記事では『中途半端に優秀な』とわざわざ断っているから、こういうことを最低限知っていて、杓子定規になんでもかんでも共通化したりローカル変数ばっかり使っている人に対しての進言なんだろうとは思いますが。
『Java屋らしい』とは、Javaが静的型付け言語だけに、なんでもかんでも「こうしなければいけない、ならない」と断定してしまう点を指して『堅い（硬い？）』ことを言っているのでしょうか？
あと、『Java屋は長ーいメソッド名が見やすいと感じるらしい』というコメントについては、Java屋がCOBOLerに対して、
なんて書くのは冗長だよなー。とか、xx区分みたいな項目が横並びに何十項目もあるRDBなんて作るんじゃねぇ、とか思う心理と似たようなものなんでしょうか。
そもそもJavaがこんなにdisられるようになったそもそもの理由も知りたい。
教えてLLな人。
分裂勘違い君劇場を、わんさかブックマークする人達というのは何を好きこのんでいるのだろう。浅く、薄っぺ。腹が立つので、ブックマーカーに突っ込みを入れてみよう。ちなみにこのエントリ「日本でしか生きていけないと将来破滅するリスクがあるので世界中どこでも生きていける戦略のご紹介 - 分裂勘違い君劇場」には今現在183のブックマークがついていた。
考えさせられる
そうですか?腹が立つという意味なら同意です。
分裂君の評論能力にはつくづく感心させられるなぁ。
ある意味正しい。きちんとblogの形にまとめてくる能力は評価できますね。でも、なんだかバックグランドとして透けて見える彼の価値観がどうにもよろしくない。プロフィールのところで、逃げを打つあたりも疑問だしネ。
同意。全くその通り。地方のSEにこんな感じのリーダが昔は沢山いた。世間狭すぎる。会社にべったりのスキルを獲得しないで、何をやった気になってるんだろう。大型開発ほど、困難な開発ほど、会社として総力戦になる。自ずと独自製品べったりになる。そんな現場に立ち会っていない。というか、立ち会ったかも知れないが外野として俯瞰していた感じだ。
AJaxが無いのは書き漏らしたのかな。独自製品べったりを嫌うだけあって運用管理ツールは無いな。Apatche, MTが無いあたりは勘定系などのSEなのかと思わせられる。それにしても、「正規表現、TCP/IP」は一般教養だからここに書かない方がいいのでは。iosが無いのはネットはやらない人なんだな。
国家に対しても同じことが言えます。
IT系企業と国家を同列で考えるのはいかがな物か。しかも、文の構成から見てIT企業の考察から類推している(国家破滅の例としてIT企業を出したとは思えない)。
全ての資産を一点がけするのが危険な投資戦略であるように、自分の生活基盤となる国家を一カ所だけに限定してしまうのも、極めて危険な賭なのです。
またも、理由を開示せず類推で話を終えている。投資のポートフォリオをどっかで聞きかじったんだろうが、薄っぺらい。
「1人の異性しか知らず、最初につきあった異性と一生添い遂げなければならない」というのはいかにも古めかしい道徳観念です
古いとしか言っていない。良い悪いの話じゃないのか。古いが悪いのはITだけだよ。価値観なんて人それぞれ、古かろうが主流じゃなかろうが幸福追求に都合が良ければそれでよし。
また、タバコ依存症から抜け出すために、さまざまな方法があるように、日本依存症から抜け出すにも、さまざまな方法があります。
まただ。しかも、今回は「依存症」という単語で一本書こうとした糸口が透けて見える。面白いけど、調査不足。力不足。埋め草が多すぎる。
なぜ、この話題で計算式を出さない。計算してみればあなたの提案がとても難しい物だというのがよく分かるはず。私の資産では年率16％の運用利回りをたたき出さないと生活はできない。平均的な資産運用は5％。企業は年金の運用を2〜5％でやっている。16％の運用ができるなら、日本にいた方がいい。
新しく登場した.NETやC#にしても、過去にマスターしたスキルにほんのちょっと上積みしたぐらいのわずかな薄皮でしかなく、いままで蓄積した基本スキルはそのまま通用します。
仕事は何をやってるんだろう。わずかな薄皮で日々しのげる楽な仕事なんだろうなぁ。スコープも狭いし。
自営業は、あたると凄いんです。
あたらないと書いてるように見えるのだが、気のせいだろうか。
いちいち、けちを付けて申し訳ない。なんだか、今猛烈に反省モードです。しかも、初めて彼の日記を読み切ったのですが、薄っぺらいという感想は変わりませんが好きになったかも(w。愛されるべきSEなんですね。でも、これだと商談取れないぞ。
RDBのプログラムなんだけど、ありがちなこんな二つのテーブルがあるとします。
地方
地方コード 地方名 1 北海道 2 東北 3 関東 4 北陸
地方コード 都道府県コード 都道府県名 1 1 北海道 2 2 青森 2 3 岩手 2 4 宮城
で、このデータをもとに
みたいな出力が欲しい場合って、どうしてますか？
地方テーブルだけを取得するSQLまず投げて、都道府県テーブルを地方コードを条件にしてその地方の数だけ取得するのか
あるいは、二つのテーブルを外部結合して丸ごと取得して、コード値の変化を見ながら出力の内容をコントロールするプログラムを書くのか
どうしてます？
いや、元増田の「分からんから開き直る」という態度はアマチュアでもプロでも害悪でしかないぞ。つーか人としてどうよ。おまけに自分はリスクを取らず増田で無知な人を煽ってるのが卑怯すぎる。
というか、Webでサービスを公開しなくてもプログラミングなんて十分学べる。
今では教科書だって充実している。手元で動かしてみるのも良いし、ソースをブログに貼り付けて反応を待つのも良いし、何でもありだ。ビバインターネット。情報化社会。
むしろ、サービスを公開しなきゃプログラミングじゃないという印象を振りまかれることの方が迷惑。
あとは実際に必要な学習のコストだけど、さっきまでそこで書いてたんだが、
HTMLやシェル(ファイル名)やRDB(SQL)とか、他のプログラミング言語として解釈されそうな文字列をエスケープしてればおkですよ。
これくらいなら、簡単にできるでしょ？一応、高木浩光が言ってることを極限まで簡単にしてみたんだが。
http://anond.hatelabo.jp/20070906231939
返事がもらえた。とてもうれしいです。
そうだね。何をやろうかな？Web系ならPerlとRubyとPHPとASPとRDBなら扱ったことがある。でも最近ほとんど使って無いからかなり能力がさび付いていて、最初は役に立てないかもしれないけど、がんばりたい。仕事のプログラムに疲れたら遊びのプログラムをする、やのさとるさんみたいに僕はなりたいと感じます。せっかくITが今ものすごく面白いことになっているのに、これを黙ってみているだけなのは本当にもったいない。
俺の住む世界はアイティーとやらに支えられているらしい。
アイティーに関われば、俺の住む世界をさらに素敵なものにしていけるに違いない。していきたい。
そう願って、何も知らなかった文系新卒の俺が金融系のシステム会社に入って、もう一年以上が経つのだ。
昔、お遊びでゲームを作ったことはあった。RPGツクールなんかが好きだった。
パズルみたいで楽しかった。コンピュータの中身が理解できて、わくわくした。
楽々と基本情報技術者の資格を手にし、半年後にはほとんど勉強もせずにソフ開も取得した。
研修の課題では同期の誰よりも速く、短く効率のいいソースを仕上げた。
現場に出て、本番機に触った。
３０年間親会社を支え続ける偉大なシステムの中身を、わくわくしながら覗いた。
そこには、俺の求めていた世界とはまったく違うものが広がっていた。
俺が産まれる前から、入れ替わり立ち替わり何人もの手によって継ぎ足されたロジック。
何千行にもわたって、似たような処理が何回もひたすら繰り返される似たようなモジュール何十本。
1993年に行う臨時処理のロジックが、今もコメントもなしに埋め込まれている。
仕様がわからなくなれば、キャビネへと走って、黄ばんだ方眼紙に鉛筆で書かれた仕様書を探し、
そして修正履歴のみが書かれているのを確認して肩を落とす。
半年後に臨時で行われる業務に対応するため、いくつかのモジュールについて、処理可能なユーザーコードをひとつ、条件に加える。
与えられた期間は２週間だった。ずいぶん長いなと思った。
何枚もの設計書を書いた。つまり、方眼紙状のExcelテンプレートに同じ文章をコピペした。
追っていったモジュールはどれも、ヒープもソートもメモリ管理も論理演算も出番がなかった。
あるのはただ、IF文とMOVE文とばかりだった。ソースの難易度は使われている命令の数とは関係ないことを学んだ。
テストデータを作るため、階層型DBを何回も辿ってデータをアウトプットさせるモジュールを書いた。資格試験で学んだSQLは、無用の知識だった。
協力会社への仕事割り振りやユーザー対応に毎日忙しそうだった上司が、夜遅くまでの残業続きでくまのできた目を皿のようにして設計書をレビューした。
２日後、承認が出た。フェーズが設計から開発に移った。
ロジックを丸々コピペしてソースを修正し、コンパイルし、実行した。
２週間はあっという間だった。
俺のせいで、半年後以降は使われないロジックがソースにまたひとつ増えた。
今回の対応については、Excel方眼紙にレポートをまとめて共有ドライブに入れておいた。
だが共有ドライブの検索には時間がかかるし、Excelシートの中身となれば検索から漏れることも多い。
きっと誰にも読まれないだろう。
２バイト文字が使えない関係上、原則、ソースにはコメントはあまり入れられない。
数年後の新人はきっと、俺の書いたモジュールを見て「このロジックは何だ」と首を捻るんだろう。
数年後の俺はきっと、今回のレポートを共有ドライブから探し回って新人にパスを教えてから、
協力会社の管理に追われる作業に戻って目の下にくまを作るのだろう。
俺がやりたかったシステム開発って、こんなものだったのか。
俺は部署の中で、俺の望む仕事を探し続けた。
先輩たちは忙しくて誰も興味を持ってないけど、自動化できる作業はいくらでもある。
よく使われるExcelシートを改造し、定例作業をクリックだけでできるようにした。
ExcelVBAとはいえ、書いていて心地よかった。引数が明確な関数と変数のスコープと全角文字があったからだ。
COBOLで打つプログラムより、控えめに見て100倍くらいの生産性を発揮できていたと思う。
先輩たちは喜んでくれたが、ただし俺の仕事を、あまり仕事とは見なさなかった。
それでもよかった。業務時間外は俺は相変わらずスクリプトを書いていた。とても楽しかった。
VBAから入って、WSHなんてものを知り、やがてJavaScriptを学び、ネットで資料を探し、はてなを知り、はてブでWeb技術についての記事を読みふけった。
知れば知るほどに、どんどんCOBOLが、メインフレームが嫌いになっていく。
先輩は誇らしげに言う。システムはたいしたことをやっていない。業務知識こそが大事なのだ。
ユーザーより詳しく業務を理解し、適切に提案し、設計する能力。
協力会社を率いて、わかりやすい文書で指示を行い、スケジュールを調整する能力。
人を動かすぶん、責任も大きくやりがいもある。優秀な人材こそが我が社の強みだ。
そんな人材が育つよう、我が社は安定して働ける環境と福利厚生を整えている。
ああ、そうだよ。先輩、あなたは正しい。
俺だってメインフレームの信頼性のすごさはわかってる。
密なユーザーとの関係から生まれるシステム子会社としての強みも認識してる。
それだけじゃない。社内環境も悪くない。給料もいいし休みも取れるし先輩は優しい。
ここは、いい会社だ。
けど駄目なんだ。
３０年前のシステムを枯れた言語でツギハギする仕事じゃ、俺の心はやっぱり満たされない。
ユーザーの業務知識ばかり身につけたって、俺自身の人生には、いいことなんてない。
俺が求めていたのは、この仕事じゃないんだ。
社内の誰も、TumblrもTwitterもやっていない。ライフハックなんて聞いたこともない。
Joostやモバゲーや２ちゃんねるが社会に与える影響について誰も語れない。
休日はゴルフや酒に興じている。自宅にPCを持ってない人までいる。
おかしいことじゃない。普通の人たちだ。
それどころか彼らは、仕事とプライベートを切り分けている、立派な人たちだ。
でも、やっぱり俺の生きていきたい世界は、ここじゃないんだ。
たぶん俺がいるのは極北なんだろう。
ここが、人月計算とExcelとスーツの世界というやつなんだろう。
俺は80文字×32行の緑文字を見つめながら、遠い夢を見続ける。
