  |
はてなキーワード: ORACLEとは
IT関連事業者の国内外の差が酷すぎる。
差と言っても、憧れの差だ。
Googleには夢がある、Microsoftにも（賛否両論あろうけれど）、Appleにも、IBMにも、Sunにも、Intelにも、AMDにも、Oracleにも、Nokiaにも、憧れるべきものがある。KasperskyやAvira、Yahoo!（最近ではASUSだって）にも、まだ輝きがある。大きな会社が輝いていると、小さな会社まで輝いて見える。
で、日本って何があるよ？
今のNECには夢がない（少なくとも、PC98時代には、もっと違っていた）、東芝にも、松下にも、富士通にも、NTTデータにも、シャープにも、憎たらしい某会長のCanonにも、沖電気にも、憧れなど無いじゃない。三菱とかに至っては、もはや存在さえ忘れかけてるじゃない……。微かに、林檎に惨敗したSonyとか、この木何の木の日立とかに有るか無きか程度じゃない。任天堂の方が（そして、かつてのセガの方が）、100万倍も1000万倍も憧れるものを持っているじゃない。まあ、サイボウズとかJUSTSYSTEMとかの例外もあるにはあるけれど……大会社が軒並み死んでるじゃない……。
はてブの人気エントリに「今回のmixiのリニューアルについて - 専門家に聞く」ってのがあるんだけど、そのページのにある寺田さんの発言がステキすぎて目が離せません。
文章構造、悪くないと思うけどね…。
とりたてて良くもないけど、そこそこいい感じじゃないすか？具体的にどう悲惨なんだろね。
今までの化石みたいなTableレイアウトのソースに比べれば、死ぬほどマトモでしょ。
個人的にはHTML要素のid・class指定にLowerCamelCaseを使うのは好きじゃないとか、onmouseover・onmouseoutみたいなDOMイベントをHTMLソース上に書かなくてもいいじゃんとかはあるけど。
但し、せっかくCSSにしたんだからHTMLソースを短くする努力をした方が良かった気がする。
PVが半端ないから、HTMLソースの量でも結構大きく響いてくるはず。
本当にそうですね…！やっぱり時代はPHPですよね（笑
今回のリニューアルは「テンプレートのリニューアル」であり、「システムも含めた全面的なリニューアル」ないんでそりゃ変わらないでしょ。
数千台のサーバで運営されており、実績のある現在のPerlベースのシステムを、PHPベースに変更することで何のメリットがあるんですかね？
「PHPだと、Perlと違い実行時にプロセスが立ち上がらないので高速です」とか言いそうな予感がプンプンしますが…。
「Javaベースにして、Oracleにしましょう」といった話であれば、はいはいSIer乙って気分になるんだけど、PHPが出てくるところがなんとも微笑ましいです。
どう考えても創業以来からの身内で開発をしているとしか思えません。技術や知識が古く、独自の思考をもった温室エンジニアたちが、権限ばかり与えられて新しく入ったデザイナーやコーダーと上手に連携できていない様子が目に浮かぶようです。
んー、1000万IDあるサイトを、運用する技術とかだけでも結構なもんだと思うけどね。
サイトのスケールアウトの難しさとか… 知ってるのかな？
どこまでいっても「なぜ上場したのか・・・」という問題に尽きます。
なんかあんまり触れられてないけど、今回のmixiのデザインリニューアルで一番強く思ったのは「mixiが持っていたキャッチーさが薄くなってしまった」ということ。
同時期に開始したGreeと、mixiの二つのSNSの内、mixiだけが圧倒的な勢いでユーザ数をのばしていった理由。
他のウェブサービスでは見ない原色系の色遣い。パッと見て親しみやすい感じ。オタクっぽくない感じ。
そこがmixiのアイデンティティだと思っていたので、普通になっちゃったことにビックリした。
初期のデザインコンセプトが「人と人をつなげる楽しいウェブサイト」だったとすると、
今回のリニューアルのデザインコンセプトは「ソーシャルプラットフォーム」みたいな感じで独自色を薄くした感じなのかねぇ…。
あと、非常に分かりづらいメニュー構成（操作メニューが2つあって、その意味づけがはっきりしていない）は、変わらないのが相変わらず駄目だと思った。
システムの機械語レベルの挙動を意識するとどういうところが気になるようになるか、それを現代の環境ではどう教えるか、という点が問題でしょうね。
・メモリやレジスタ幅(桁数)と情報の規模の関係を意識する - まあ、Oracle は 64bit OS で使えとか、xfs を 32bit OS で使うと(atomic な部分の更新が泣き別れになって)クラッシュの危険が高いとか
・API 仕様を意識する - 上の例の続きだけど、パッチのあたってない古い gzip で 2Gbytes 以上のファイルが圧縮できないとか
・コードを展開した結果、関数の出入りやインタフェースでどう膨れ上がるか、リソースの解放がどれだけ無意味になりうるかを知っている - C++ とかの場合。Tomcat もクラスロード(とリソースの確保も -- 追記)で1時間待たされるとかくだらないことが起こるけど、開発効率と運用のトレードオフだからなぁ
・(Ruby, PHP, Java などの)VMに頼るべきでない場合が何かを知っている - 速度もだけど、VMがバグ持ちの場合、デバッグが困難を極めることもある
・ビット操作系のコードを書けないと困る - まあ、ioctl や fnctl で苦労したことがあればどういうものかは判ると思うけど
・(追記)strace とか ldd とかくらい言われる前にやってほしい - 実際 Java と PHP しか知らないと本当にこの辺はできない
・(追記)497(×10^-n)日で落ちた、と言われた瞬間にカーネルのバグを疑ってほしい - lbolt 溢れ系のバグは本当にありふれている
いまどきは障害対応系の運用をやったほうがプログラマとしてコード書くよりもこの辺の問題に詳しくなれる気がします。
追記：「こういうこともわからん子供たち」をうまく使って利益を上げる会社と、「こういうこともわからん子供たち」を教えるのにフラストレーションを感じるハッカーがひとりで回している会社、どっちが上記のようなことを学びやすいかというのは難しいところです。SUSv3 (昔のオライリーの POSIX 本でもいいけど)を面白いと思えない人に正直あまり細かいことを学べるとは思えないし‥
それは・・・
と答えようとして頭がうにになった。
こんなことも答えられない自分に絶望した。
limit句がつかえないのはわかる。
topでとってrownumだっけかと調べてみたらそれはOracleだった。
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1111889701
・・・あれ、row_number() なんて関数しらんな。
そうか自分が最後に触ってたのは2000までだったか。
だめだ、なんかへこんだ。
もう何もかも忘れてしまった。
javaをやっている。できれば明日中に完成させたい。
が、さっぱりわからない。
やりたいことがさっぱり実現できない。
基本的なことがわからないからだ。
しかたがないのでベタに書いているが、アホ臭い。
それほど大きなものではないので今はこれでもいいのだが、なんだろうこの寂しさは。
それぞれちょっと調べればわかるとおもうのだけど、
意外とわからなかったりする。
・・・。なんだろうこのめんどくささは。
SQLとかはmySQLとかOracleとかSQLserverとかの方言をまたいでくれるようなサイトが昔しあったが、そんな感じで、表記を横断してくれるサイトはないだろうか。
いちいちわからなくてイライラする。
全然進まない・・・。
就活のときに参考にしたのだが、冷静に考えてみると、要は学生の作った人気投票。
これって社会人が見たらどう思うのだろう。。
【2008卒確定版（高学歴用民間版）】(金融/コンサル/商社/マスコミ/デベ/海運/メーカー/インフラ/その他)
73 GS McK
72 MS ML Fidelity BCG Bain JAL/ANA（パイロット）フジテレビ
71 日銀 UBS DB JP LB BAH AT.Kearney RB AC(戦) Deloitte/TC NRI(コンサル) 日本テレビ
70 野村證券(IB/FE/リサーチ) Barclays 日興citi 野村AM ADL Monitor MRI P&G(マーケ/ファイナンス)
--------------------------------------------------------------------------------------------------------
69 DBJ Monex 朝日新聞 集英社 電通 テレ朝 小学館 講談社
68 citibank（法人） みずほ(GCF) JBIC 日経新聞 読売新聞 TBS テレ東 三菱地所 三井不動産 日本郵船 商船三井 新日石 JR東海
67 東証 松井証券 三菱商事 準キー 博報堂 旭硝子 任天堂 新日鐵 JFE 東電 関電
66 みずほ（IB/FT） 三菱東京UFJ(戦財・国金・FT) 三井物産 NHK 共同通信 川崎汽船 トヨタ 本田技研 ソニー 信越 味の素 中電 東北電 九電 JR東 昭和シェル 東ガス JRA JICA JETRO
65 三菱東京UFJ（IB） 時事通信 東京建物 東急不 キリン 日産 キヤノン 三菱化学 住友化学 松下電器 花王 富士フイルム 北電
--------------------------------------------------------------------------------------------------------
64 農中 新生銀(IB) 住友商事 伊藤忠 毎日新聞 産経新聞 サントリー 三菱重工 旭化成 三井化学 デンソー 住友電工 住友金属 JR西 大ガス
63 大和SMBC 東京海上 三菱UFJ信託 ADK 住友不 野村不 住友3Ｍ ブリヂストン アサヒ 富士ゼロ 日立(BM) 出光 中国電 四国電 北陸電 JASRAC NRI(SE)
62 日本生命 みずほ信託 丸紅 地方新聞 森トラスト 三菱倉庫 川崎重工 神戸製鋼 東芝 資生堂 王子/日本製紙 東レ JT 鹿島 リコー 日本IBM アクセンチュア(非戦) Oracle NTTデータ
61 JA共済 三菱東京UFJ 日本政金公庫 住友信託 MS海上 リクルート 双日 三菱電機 日清製粉 J&J 日本リバ 日本hp NTTコミュ 日立(SE)
60 SMBC みずほ（OP） 野村證券（OP） 損保ジャパン 中央三井信託 第一生命 豊田通商 地方局 森ビル 住友倉庫 ヤマハ発動機 帝人 日清食品 明治製菓 シャープ NEC 富士通 大成 清水 DNP NTT東西
断片的な知識と体系的な知識
http://sengoku.blog.klab.org/archives/50257017.html
途中までは「なるほど」とかなり同意しつつ読んでたけど、途中で「コンピュータサイエンスのための離散数学」が出てきた時点で、おれのような底辺プログラマには関係ない世界の話だと悟った。
