  |
はてなキーワード: RDBMSとは
こんなのそこらへんの学生でも持ってるスキルだろ。こういう甘い条件で人を集めてバサバサと不採用にして何がしたいのかわからん。たまにいいのが来ればいいや？みたいな感じ？どうせ内部では経歴や年齢や学歴で差別してるんだろ（と疑われても仕方がない）。
（株）はてな 6.59% 445352200円
毛利 裕二 5.98% 404128400円
梅田 望夫 4.30% 290594000円
伊藤 直也 1.79% 120968200円 ○
田中 慎司 1.30% 87854000円 ○
小林 直樹 1.15% 77717000円
お金の額面はともかくの話なんだけど、
○をつけたのは、はてなのコードを書いたことがあると"思われる人"。「名前 プログラミング」で検索して有意な結果が出た人に○つけた。各株主の詳細知りたい人は適当にググって
で、さらに
はてなの年収は524万円が平均年収です。（有価証券報告書調べ）
http://heikinnenshu.jp/joho/hatena.html
スクリプト言語（主に Perl/PHP/Python/Ruby/JavaScript）によるアプリケーション、ライブラリ開発の経験
ScalaやGoにおけるアプリケーション、ライブラリ開発の経験
iPhoneアプリ、もしくはAndroidアプリの開発経験
UNIX系OS、RDBMS （特に Linux、MySQL）についての基礎知識
コンピュータサイエンス（アルゴリズムとデータ構造、分散技術、自然言語処理技術、機械学習、データマイニング、型理論）に関する基礎知識
ネットワーク技術（HTTP、DNS、TCP/IPなど）についての基礎知識
大学卒／275,000円〜
http://hatenacorp.jp/recruit/fresh/application-engineer-entry
この毛利 裕二という人の持ち株の資産を新卒の給料(計算だるかったから計算からボーナス抜いたけど、手取り分で考えたらボーナス分くらいは消えるだろう)で稼ぐとしたら122年かかるし、梅田 望夫という人は88年かかる。本当にこの人たちにはそれほどの価値(上にあげた新卒に求めるやたらと高いスペック)分の価値があるのか？いや、価値があると思ったから株をあてがったんだろうけど...
まぁなんていうか...、はてなのエンジニアのみなさんお疲れ様です...業務がんばってください
構文によって書き方が違うのがわかりにくい。
SELECTはまだいい。問題はINSERTとUPDATEである。
INSERTはVALUESで書くくせに、UPDATEになるとSETで=でつなげているのモヤモヤする。
さらに()が必要な構文だったり必要ではないものであったり統一感がないのが混乱する。
INTOで文章らしさを出しているのかしらないが、どちらにしろ文章にならないので中途半端なのでいらないのではないだろうか。
ちょっとした検索したい場合はいいかもしれないが、プログラムの一部としての長ったらしいSQLは可読性も悪ければ保守性も悪いで誰も得しない。
さらに解決される順番が未だによくわからない。特にGROUP BYを使う場合にどういったタイミングでされるのか非常にわかりにくい。
サブクエリを無駄に重ねたり、ON DUPLICATED KEY UPDATEをわざわざ書いたりとなぜ１文で完結させようとするのだろうか。
どっちみちトランザクションで複数文になるのならば、最初から複数文となることを前提した仕様としてもいいのではないか。
（そもそもコードから呼ぶ場合はフレームワーク周りでなんとかしろという話ではありますが）
他にもストアドプロシージャやSQL高速化の問題もあるとは思うが、自分自身が未熟者でそこまで語れないので書けない。
プログラミング言語については様々な文句が噴出するにもかかわらずSQLについて文句が出ないのはどういう了見なのだろうか。
反対にNoSQLでRDBMSのようなことを始める本末転倒な人たちも見かけるがそれぞれ適材適所な使い方をするべき。
体系的に学んでいれば今よりもっとすっきりと理解できるものかもしれないが、嫌悪感を抱いてしまった以上は学ぶことなくずっと憎み続けていくことになるのだろう。
そういうわけでやはり僕はSQLが好きになれない。
うん。分かる分かる。
過去に掠っただけの経験を盛って何とか面談相手のニーズに合致してますアピールをしなきゃならないこの苦しさ。
日本のシステム開発の現場って無駄にギョームケイケンを求めすぎなんだよな。
どの現場も作ってるもんは画面の入力内容をRDBMSに保存して、画面やら帳票やらファイルに出力するだけ。
オンラインとバッチ、汎用機とオープン系、この位の粒度で経験がかぶってて、オブジェクト指向の言語どれか一つ使いこなせりゃ別に現場に入ってから学習で全然事足りるし、業務知識なんて販売管理やら在庫管理やらの一般的な業務システムの知識を本とかで仕込んでおいて後は現場で覚えりゃ十分。
まるで、専門知識がなければ戦力にならないかのようにみんな面接してくるけど、どうせお前外部の人間にそこまで深くコミットした仕事させねーだろって思うわ。
http://anond.hatelabo.jp/20140905175927
エクセルは表計算ソフトだ！と言い他の使い方を認めない人は宗教ぽくて怖いです。
視点も狭く融通がきかなそうなので、モテないでしょうね。たぶん童貞です。
DBをエクセルにするかアクセスにするか他のRDBMSにするかは要件次第です。
RDBの知識がある方は、無駄にアクセスを使おうとすることもありますが、
全体の効率を考えたらエクセルの方がはるかに良い場合もあります。
（もちろんデータ量や入力状況によってはアクセスを検討すべき可能性もあると思います）
ケースバイケースなので、「エクセルは表計算ソフト」だといい除外する視点の小ささは
股間の小ささに繋がります。
視点がゴリゴリに凝り固まってて、他者の視点で考えられない童貞は、
RDBでリレーションできても女の子とリレーションすることはできませんよ。
byみおり
MySQLに限らないけど、「GPLは営利目的では使えない的な思い込み」は止めて欲しい。
先週、システム開発の提案で客先に行ってきた。
当方、30前半のSE。対応してくれた担当者は40代後半の情報システム部門の方。
提案したシステムの規模はそれほど大きくはなく、お客さんからもあまり予算はないと言われていたため、RDBMSに「MySQL」を使ったWebシステムを提案したところ、「それほど可用性は求めてないし、無料で使えるDBの方がいい」と言われた。
あぁ、商用ライセンスを購入すると勘違いしたんだな、と思ったので、「MySQLはGPLライセンスもあるので無料で使うことができますよ」と説明したところ、担当者の顔が険しくなった。
「GPLだとソースコードを公開しないといけないんだよ？たとえMySQLのソースコードを改変していなくても、MySQLを使ったソフトウェアであればソースコードを公開しないといけないし、それを企業で使おうとすると犯罪になるよ。」
「だからウチでは重要なシステムはOracleを使っているし、重要度が低いシステムPostgreSQLを使ってる。」
「たまたま提案先がウチだからいいものの、他の企業にそんな提案すると恥をかくし、あなたの会社の信用も堕ちる。」
いろいろ言われたけど、要約するとこんな感じ。
「確かにGPLだと他の誰かにMySQLを使ったソフトウェアを頒布する場合はソースコードも渡さないといけないですが、今回は御社に導入するWebシステムですから問題ないですよ」
とは返したものの、
「Webシステムなのが問題なんだ。システムを使う人にソースコードを公開しないといけないんだよ。TOPページとかにリンクを貼るの？ソースコードはこちら、みたいなの。ありえないよね？」
「システムを使った社員がソースコードを持って帰って公開したらどうなるの？機密情報の流出だよ。」
と捲し立てられてしまった。
心の中では「Webシステムだと利用者全員にソースコード公開とか、なわけねーだろ」と思いつつも、相手の勢いがスゴいし反論するための明確な情報を持っていなかったので一旦持ち帰って再検討することになりました。
http://www.ipa.go.jp/files/000028332.html
英語が苦手なのでIPAが公開しているGPLv3の日本語訳で確認したところ、「0. 定義」の項目に以下の文言があった。
著作物の「コンベイ」（convey)とは，プロパゲートに当たる行為のうち第三者が複製すること又は複製物を受領することを可能にする行為をいう。ただし，コンピュータネットワーク上での単なるやりとりであって複製物の伝送を伴わない場合は，コンベイに当たらない。
そりゃそうだよね。てかWebシステム利用者にソースコードを公開しないといけないとか誰が言い出したんだよ。
で、結局提案はPostgreSQLに変更しました。ライセンス云々関係なくPostgreSQLに統一されているんだったら運用コスト面でその方がいいし、MySQLを提案したのは俺がPostgreSQLより得意だからってだけだから。
ライセンスについては調べたことを担当者に伝えるかどうか思案中…。
ここまで捲し立てられたのは初めてだったけど、今までもお客さんから「GPLだけど商用ダメなんじゃないの？」って言われたことが多いんだよね。
もう一度言うが
増田です。
匿名なら良いか、と思って酔った勢いでぶちまけて少し後悔してた。
けど小さいながらも反響があって嬉しい。
NoSQLとかnode.jsのくだりで突っ込まれたけど、あまり具体的に書くとバレるのが怖いからこういうサラッと書くだけにした。
本当は具体的なソフト名なんだけど、狭い業界で特定が怖いので語れません。
例えば"今の時代NoSQLっすよね～。ノードを足せばいくらでもスケールできるんですよ。RDBMSとかオワコンなんでこのシステムはNoSQLで作るのが良いと思います"と言うなら、RDBMSのメリット（トランザクションとか一貫性が保証されることとか）を知ってないとおかしいよね。実際RDBMSのほうがよっぽど使えるケースも多々あるわけで。
ヘビィに使えばどちらのケースでも解決が難しい問題が起こることも経験としてよく知ってます。
あんまり具体的に書くと議論が明後日にいくからこのへんで許してください。
本筋は最近のテンプレートになりつつあるエンジニア(勉強会でハッカソンでgithubでオープンソース活動でノマドな感じ。得意なことはプレゼンテーション。将来の夢はエバンジュリストです、みたいな)に物申したい、ということです。
外で勝手にやるのは別にどうでもいいんですが、こういう人がチームにいると言及しているような問題が起こる、ということですね。
セルフプロデュース活動は組織とまったく関係ない分野でしてほしいと思います。
チーム力と会社の金を使って個人では出すことが難しい成果を出して、意図してかせずか、それを自分の手柄として発表する。勿論無断で。みたいな。
個人の時間と金を削って出した成果を発表するのは、その心意気とか探求心とかの面で本当に尊敬します。
Google エンジニアの Steve Yegge 氏、Google+ への懸念を漏らす
http://japan.internet.com/busnews/20111013/8.html
で記事になってたけど、原文とちょっと要旨が変わっちゃってサービスへの警鐘みたいになってしまってたので、全文訳してみた。くそ長い。お暇な方どうぞ。
（2011/10/19 08:14）ありがたい誤訳の指摘をいただいたので3カ所修正。
Stevey の Google プラットフォームぶっちゃけ話
僕は6年半ばかり Amazon にいて、今はそれと同じくらい Google にいる。この二つの会社について強く感じることは（しかもその印象は日々強まるのだけれど）、 Amazon は全てにおいて間違っていて、 Google は全てにおいて正しいということだ。そう、やりすぎな一般化だけど、驚くほど正確だと思う。いやもうとにかくね。百、いや二百のポイントで二つの会社を比較することが出来るだろうけど、僕が正しく覚えていれば、 Google はそのうち三つを除いて優れている。実にある一点に関してはスプレッドシートを書いたんだけど、法務が外に出すなって言うんだ。リクルーティングは惚れ込んだみたいだけどね。
つまり、まあ簡単に言えば、 Amazon の人事採用プロセスってのは基本的に欠陥品なんだ。だって、チームがチーム毎に、自分達のために人を採用するんだぜ。だから、色々平均化の努力はしてるみたいだけど、採用基準はチームによって信じられないくらいバラバラさ。そんでもって作業工程ってのも腐ってる。ソフトウェア信頼性工学なんてお呼びじゃないし、エンジニアに何でもやらせようとするんだ。コーディングする時間もないくらい。もちろんこれもチーム毎にバラバラで、要するに、運次第ってところ。施しやら困った人を助けるのやら、コミュニティに貢献するのやら、そんなのはもってのほか。バカにしに行くんでもなけりゃ、近寄るべきじゃないね。それにまた施設も染みだらけの壁に囲まれた箱みたいな家畜場で、装飾やらミーティングエリアなんてものには一銭も使ってない。給料やら福利厚生なんてのも最悪だ。まして最近じゃあ Google やら Facebook っていうライバルがいるのにね。社員特典なんてものも見たこと無かったな。採用通知の番号を照合して、ハイ終わり。コードベースも悲惨そのもの。エンジニアリング基準ってものがないんだから。チームによっては個別にがんばっていたくらいかな。
公平に言えば、彼らは良いバージョン管理ライブラリシステムを持っていた。これは僕らもまねるべきだし、僕らのところには同様のものが無い、良い pubsub システムもあった。でも多くの部分で彼らが使っていたのは、ステートマシンの情報を RDBMS に突っ込んだり読み出したりするだけのくそみたいなツールの塊だった。僕らならただでも欲しくないようなね。
僕が思うにその pubsub システムとライブラリ管理システムが、まさに Amazon が Google より優れている三つのうちの二つだ。
早期にリリースして、狂ったようにイテレートするってのも彼らのうまいところじゃないかって言うかもしれない。けど逆もまたしかり。彼らは早期にリリースすることを何にもまして優先する。品質保持やらエンジニアリング規則、その他長い目で見たら重要になってきそうなものはみんな後回し。そんなだからたとえ市場で競争相手よりアドバンテージがあったとしても、結局ちょっとしたことをやるのにも問題を起こしちゃうよね。
でも、一つ、そんな政治的な、思想的な、技術的なへまを補うだけの、彼らが本当に本当にうまくやってることがある。
Jeff Bezos は悪名高きマイクロマネージャーだ。彼は Amazon の小売りサイトの1ピクセルまで管理する。彼は以前 Larry Tesler を雇った。 Apple の主任科学者で、たぶん世界で最も有名で尊敬される HCI エキスパートさ。そんでもって、 Jeff は Larry が言ったことを、 Larry が辞めるまで3年間無視し続けた。 Larry は大規模なユーザビリティ研究もやっただろうし、少しの疑いの余地も無く誰もそのひどいサイトを理解できないってことをデモしたに違いない。けれど、 Jeff は1ピクセルたりとも動かさせはしなかった。トップページにぎっちりつまった内容の1ピクセルたりともね。それらはまるで何百万という彼の貴重な子供達なのさ。けれど Larry はそうじゃなかった。
マイクロマネジメントが Amazon が僕らよりうまくやっている三つ目ってわけじゃあない。つまり、まあ、彼らはうまくマイクロマネジメントをやっていたと思うけど、それを強みって言いたいわけじゃ無い。まずは何が起こっているかみんなに理解してもらうための文脈を準備しているだけさ。僕らはこれから、公衆の面前で、 Amazon で働きたけりゃ私に金を払えと言ってのける男について話すわけだからね。誰かが彼に反対したときは、彼は彼の名前入りの小さな黄色いポストイットを手渡して、誰が会社を動かしているかを常に忘れさせまいとする。思うに彼は全くの… Steve Jobs なのさ。ファッションとデザインセンス抜きのね。 Bezos はとんでもなく頭が切れる。誤解しないで欲しい。彼の前じゃ、普通のコントロールフリークなんてヤクが極まったヒッピーみたいなもんだよ。
それである日 Jeff Bezos が指令を出した。まあ彼がいつもやってることなんだけど。その度にみんなはピコピコハンマーで叩かれるありんこみたいに走り回るんだ。でもそのある一度、2002年かそのくらいのことだったと思うけれど、彼は指令を出した。とんでもなく巨大で、目の玉が飛び出るほど重たいやつを。普段の指令が頼んでも無いボーナスに思えるようなやつを。
彼の巨大な指令はこんな感じだった。
1)この時点より、全てのチームはサービスインターフェースを通じて全てのデータと機能を公開すること。
2)各チームは各々そのインターフェースを通じて通信しなければならない。
3)その他の全てのプロセス間通信は許可されない。ダイレクトリンク、他のチームのデータソースから直接データを読むこと、メモリ共有モデル、バックドア、全てを禁じる。ネットワーク越しのサービスインターフェースを経由した通信だけが許可される。
4)使用する技術は問わない。 HTTP 、 Corba 、 Pubsub 、 カスタムプロトコル、何でも良い。 Bezos は気にしない。
5)全てのサービスインターフェースは、例外なく、外部に公開可能なようにゼロから設計されなければならない。すなわち、チームは全世界のデベロッパに向けてインターフェースを公開することができるよう、設計し、計画しなければならない。例外は無い。
6)そうしない者は解雇される。
7)ありがとう！良い一日を！
ハハ！。ここにいる君たち150人ちょっとの元 Amazon 社員ならもちろんすぐにおわかりの通り、7番は僕が付け加えたジョーク。 Bezos は間違いなく君たちの一日なんかに興味ないからね。
それでも、6番は、本当だった。だからみんな一生懸命会社に行った。 Bezos は、さらに上級のチーフ熊ブルドッグであるところの Rick Dalzell に率いられた数人のチーフブルドッグを雇って、成果と進行を監視させた。 Rick は元レンジャーで、陸軍士官学校出身で、元ボクサーで、元 Wal（ごにょごにょ）Mart で拷問のような削減をやってのけた人物で、デカくて愛想の良い、「堅牢なインターフェース」という言葉を連呼する男だった。 Rick は歩き回り、「堅牢なインターフェース」について語り回り、そして言うまでも無く、みんなたくさんの進展をし、 Rick にそれを知らせた。
それからの数年間、 Amazon 内部はサービス指向アーキテクチャに姿を変えていった。その変化を形にしている間に、彼らは非常に多くのことを学んだ。 SOA に関する学問や論文は当時もいくつかあったけれど、 Amazon のとんでもない規模からすれば、そんなもの、インディ・ジョーンズに向かって「通りを渡るときは左右をよく見るんだよ」って言うくらいの意味しかない。 Amazon の開発スタッフはその途上でとにかくたくさんの発見をした。そのほんの一部をちょっぴり挙げると、こんな感じだった。
とまあこれらがほんの一例。他にもたくさんの、おそらく何百の、 Amazon が見つけた個別の発見や教訓があった。外部サービスにはおかしなところがいくつもあったけれど、君たちが考えるほどじゃあない。サービスに対して組織するってことは、外部のデベロッパを信用できないのと同じように、お互いを信用することなんてできないんだということを、チームに教えてくれたんだ。
募集要項
・運営ツールの開発
求める経験
【必須経験】
・C/C++、perl、Ruby、Python、PHPなどを用いたプログラム開発経験
【歓迎経験】
C/C++, Perl, Ruby, Python, PHP全部使ったことあるよ！
PythonとPHPは仕事では使ったことないから微妙だけど。あとC++の言語仕様は完璧には把握できてないけど。
でもC/C++は商用のコンパイラを作るプロジェクトに参加してたこともあるしバッチリだよ。
Rubyは1.6の頃にインタプリタのソース全部読んだりしたけど最近の進化にはついていけてないかも。
【歓迎スキル】
・MySQL、PostgreSQL等のRDBMSに関する知識
このへんも全部あるよバッチリ。
そんなものは求められてないだろうけど、
RDBMSも3Dも仮に一から自分で全部作れと言われても簡単なものなら作れるレベルだよ。
しかし…
ストアードプロシージャでビジネスロジックを実装するメリットを認めつつも、以下の点からビジネスロジックをクライアント言語で実装できる場合はできるだけそうした方が良いという結論に達した。
RDBMSによっては無料あるいは有料でソースレベルデバッガを使用できる場合もあるが、通常はクライアント言語のデバッグ機能を使う方がはるかに便利だ。何か問題があったときに、どこが問題なのかを見つけることがクライアント言語で記述した場合よりもはるかに時間がかかる。
また、Unit Testing Framework(xUnit)も使用できない場合がほとんどだ。
ストアードプロシージャ用の静的解析ツールの存在を知らない。巡回的複雑度を知りようにも知るすべはないのだ。それが行えるツールを知らないだけかもしれないが。
仮にストアードプロシージャの変更を全てAlter xx等で構成されたSQLスクリプトファイルで管理し、それをバージョン管理システムに含めたとしても（というか、最低そうすべきなんだが）、あるリビジョンのコード一式に対応するデータベーススキーマを取り出すのは難しいか面倒だ。
トリガーでビジネスロジックを実装する場合も、上記問題点が全てあてはまる。
さらにトリガーの場合は、どのような場合にどのような処理が実行されるのかを俯瞰することが難しくなるという問題もある。
一つは、Oracleで言うところのストアードファンクション、つまりSELECT等のDML内で使用する関数で、そうした方がパフォーマンス的にも良い場合。
「人材の流動化か囲い込みか（http://remote.seesaa.net/article/147006872.html）」で示される問題は、SIerの案件であれば１つや2つはよく起こっている。ここまで問題が積み重なっててひどいのはあまりない（...と思いたい）以下は実際にみてきた現場の惨状。
excel方眼紙はよく見かけます。修正にやたらと手間がかかるので苦痛です。継続的にメンテナンスする必要があるドキュメントには向いてません。あと、ソースコードを日本語訳したようなひどい設計書が多いです。そんなもんソースコードで十分だろって思います。
本番環境でコンパイルしたりとか、恐ろしい事をしている現場がありました。それでソースコードレポジトリとの同期が取れてなくてどのファイルが実際に稼働しているコードなのか分からなくなったりもしていました。
ユニットテストがないのはデフォルトです。テスト仕様書が残っていればまあいい方ですが、テスト項目に「正常に動くこと」としか書かれてない場合もあって信用できません。
5.GUIがひどすぎる
RDBMSをつかったシステムで、会社の休業日を管理するテーブルの編集画面にレコード番号が必要かどうかで議論が始まり一時間くらいぐだぐだと会議をしたりします。そんなもん年月日でユニークキーにしておけば十分。いちいちユーザに番号を振らせるという手間をとらせたいんだろうか。
自社で一貫して設計から実装まで担当しているSIerは別として、そうでないSIerには実際にモノを作っている人間は居ない。仕様の検討段階での資料作成から、アーキテクチャ設計、設計、テスト、運用までほとんど外注にたよりきっており、ざっくりなマネジメントをしているだけだったりする。
設計から外注に丸投げしているSIerでは、日本式のやりかたとか言う以前に、そもそもSIerの社内にシステム開発を行ったオリジナルメンバーが存在すること自体少ない。
すでにSIerでは内製することすら出来ない状態まで空洞化している。
元記事のコメントより
コストダウンの名の下に人減らしだけは進みましたが、そのことがどれくらい破壊的な影響をもたらしているかを、上の人が全く理解できていません。上の人ほど開発経験に乏しく、細部を理解できていないのです。
『鉄筋減らしてコストダウン』して住めないマンションを大量生産したマンション販売会社がありましたが、IT業界は減らすどころか「鉄筋も柱も無くしてコストダウン」を目指してる感さえあります。
IT業界は減らすどころか「鉄筋も柱も無くしてコストダウン」を目指してる感さえあります。
ってのは言い得て妙だ。
「SIerはモノを作るのが仕事ではありません、マネジメントするのが仕事です」ｷﾘｯ!
ってよく言うけど、マネジメントに関しても、技術的な問題が起こっても解決するだけの力がないので、下請けに残業してくれという根性マネジメントしか出来てない。顧客から仕様変更の要求があった場合でも、どういう影響があるかも理解できてないので、全部請けてきて下請けに丸投げとか。
たちが悪いのは見当違いなルールを課して管理したつもりになっている事。
外注に頼り切っているSIerでは、アーキテクチャ設計、ドキュメント整備、ソースコード管理、テストの自働化、GUIデザインは社外の他人まかせになってしまっており、現状の開発方法でどのような問題があるのか気づくことができない。そういった現場から遠い場所にいる連中が現場をうまく回すためのルールを作れるとは思えない。
