  |
はてなキーワード: Oracleとは
まだある？
追記（諸説あり）
サッカー・・・Association Football 由来
電車・・・自走式の「電動機付き客車（電動客車）」、および事業用車を含む「電動機付き貨車（電動貨車など）」
ニート・・・Not in Education, Employment or Training
ニコン・・・日本光學工業（ NIPPON KOGAKU K.K.）由来
プリパラ・・・プロミス・リズム・パラダイス・ライブ 諸説あり
ペット(ボトル)・・・polyethylene terephthalate
ラジオ・・・ラジオテレグラフィー(radiotelegraphy)
レーザー・・・（LASER = Light Amplification by Stimulated Emission of Radiation = 輻射の誘導放出による光増幅）
AIDSエイズ・・・後天性免疫不全症候群(acquired immune deficiency syndrome)
AM・・・ante meridiem
BBC・・・British Broadcasting Corporation
℃・・・Celsius
JASRAC・・・Japanese Society for Rights of Authors, Composers and Publishers
LED・・・Light Emitting Diode（発光ダイオード）
MBA・・・Master of Business Administration
NAMCO・・・中村製作所（NAKAMURA Amusement machine Manufacturing Co.,Ltd）語源
NEC・・・Nippon Electric Company,Limited
NHK・・・Nihon Housou Kyoukai
NTT・・・Nippon Telegraph and Telephone Corporation
OK・・・oll korrect（all correct)
PM・・・post meridiem
PR・・・パブリック・リレーションズ (Public Relations)
PTA・・・Parent-Teacher Association
Suica・・・Super Urban Intelligent Card」＆「スイスイ行けるICカード」 由来
SMAP・・・Sports Music Assemble People 由来
TBS・・・Tokyo Broadcasting System Television, Inc
TDK・・・東京電気化学工業（Tokyo Denki Kagaku）
UK・・・United Kingdom of Great Britain and Northern Ireland
USB・・・ユニバーサル・シリアル・バスUniversal Serial Bus
Yahoo!・・・Yet Another Hierarchical Officious Oracle
YKK・・・吉田工業株式会社（Yoshida Kogyo Kabushikigaisha）語源
バンコク・・・クルンテープ・マハーナコーン・アモーン・ラタナコーシン・マヒンタラーユタヤー・マハーディロックポップ・ノッパラッタナ・ラーチャターニー・ブリーロム・ウドム・ラーチャニウェート・マハーサターン・アモーンビーマン・アワターンサティト・サッカタットティヤ・ウィサヌカム・プラシット
ピカソ・・・パブロ・ディエゴ・ホセ・フランシスコ・デ・パウラ・ファン・ネポムセーノ・マリーア・デ・ロス・レメディオス・シブリアーノ・デ・ラ・サンティシマ・トリニダード・ルイス・イ・ピカソ
後で追記する
時間を作ろうとしないと、子育てと両立はできないだろうし、子育てを舐めているわけでもない。
家事と初めての子育てでそんな余裕できないかもしれない。実際、産後２週間で悪露もひどいし起き上がるのも一苦労してる。
でも、産休に入る前の自分がダメすぎてもう少ししっかりしろよ、と自分に喝をいれたい。
だって、うちの子は天使が舞い降りたかと思うほど可愛くって可愛くって。仕事がんばって、しっかり稼いで、子どもに良いべべ着せてあげねば！という気持ちになっているのです。服でなくてご飯でも良いです。とにかく、幸せにしてあげたい。
そして、幸せには一定のお金が必要です。お金がなくても幸せとは、口が裂けても言えない。そして私の稼ぎは底辺。いつも通帳は真っ赤だし、今回の出産も、国の助成ギリギリ。そんな私が子どもを産むのが間違いだって？ほんと、そう思う。でも両親は喜んでくれたので良いのです。あと、私がすごく幸せです。
底辺の私の話だった。
現在の職業は底辺プログラマ。いろんなものを少しずつかじった結果、何のプロフェッショナルにもならないままプログラムは組める程度。年収は下層階級レベル（格差でなく、階級だって。賢い人たちはいつも私を新しく定義していく）。
調べたら次の資格が良さそうだなぁ、と思いつつ、どれがいいものだか。
主に情報技術者系。
基本情報はもっているので、その次のやつ…。一番順当かもしれない。
Web系を少しかじったものの、かじっただけなので体系づけて勉強し直す意味も込めて。
JavaやORACLEくらいしか浮かばない。MicrosoftやSalesforce,AWSまわりもありだけど、やっぱり高い。
2.生きることに活かせそうな資格
資産運用さっぱりわからないので。また、仕事で金融機関に関わることもありそう。現状は仕様に従って作ってるだけなので、基礎知識として。
FPと同じく。
そもそも会計関連もかじっただけなので売り掛け買い掛けといった一部分だけわかるけど、基礎がすっぽぬけている。
3.転職を見据えて
持ってたら安心できるけど、どうなんだろう。
さて、何にしよう。
そして、私は座学が死ぬほど苦手だ。
それでも、喝を入れる意味も含めて頑張りたい
自民でも公明でも共産でも幸福の科学でも北ちょーでもISでも電通でもKADOKAWAでもヨッピーでもxevra(非表示中)でも不倫議員でもOracleでもYoutuberでも職場で不倫していた大嫌いな同僚でも首都直下型地震でもAIでも嘘松でも信号無視の黒ワゴンでも誰でもいいからもう全てリセットしてくれ
この地獄から救ってくれるなら、なんでもいい。俺さえ助けてくれるなら何でもいい。どうでもいい事を大変だ、けしからんと騒ぎ立て、それを扇動する俺様は凄いだろう、と言うのはもうたくさん。
巷にあふれかえる自称正義なんてクソ喰らえ。俺には全く関係ない。俺を救ってくれる人だけが俺の正義だ。
俺だけか？こんなに死にたいのは、俺だけなのか？
JJUG CCCというイベントで、「会場が狭い」という感想があった
それに対し、イベント関係者から感想に対する不満や、参加者を見下すような発言があった
なので、思うことを書いてみる。
1年の半分以上がデスマーチ。
仕事以外にプログラミングをしたり、技術についての情報収集する人が少ない。
（PCを家に持たない人もかなりいるのでは？）
セミナーで話す講師は報酬（お金）をもらっていて、技術力がない人でも理解できる説明をする。
結論を最初に言え。細かい説明とかはいらない。「今一番売れてるフレームワーク」を教えろ）
そもそも、JJUG＝Java＝Oracle関係者と思い込んでる人も少なくない。
特にナイトセミナーの会場でOracleが使われることが多いので、Oracleから金をもらって運営しているという信じている人もいるだろう。
そういう人たちにとって、企業が行うイベントで会場に不満が出ることは落ち度でしかない。
コミュニティ主催のイベントというみんなで作り上げるものなのに、ベンダーに招待された「お客様」として参加してしまっているわけである。
日本でJavaユーザーが一番多い層（SIer関係者）と乖離してきているのでは？
今までは最新のJava SEとか「辛うじて」自分たちでも手の届きそうな話だったのが、マイクロサービス・クラウドとか無縁な話が多くなってきている気もする。
「きちんとしたエンタープライズ的なセミナー」を期待している人に対して、コミュニティ活動を理解してもらうのは難しい。
Javaのエンタープライズ色が強いところも、コミュニティ活動と結びつきにくいのかもしれない。
ただ、それでもコミュニティを理解してない人たちに対して、敵愾心を煽るような発言は必要だったのか？
この規模のイベントを無料で参加できるようにするための、運営の労力が大変なのは理解できる。
ただ、運営側がだれでも見れるSNSでつぶやくとかはどうなのか？
JJUGのイベントでは聞きたいセッションについて悩むというぜいたくはない。
人気あるセッションは埋まるのとにかく早い。
前日までに部屋を決めて置き、目的の部屋の席にさっさと荷物おいてからトイレや買い出しに行くのだ。
初めてJJUG CCCに参加した後輩が「聞きたいセッションがいっぱいで残念だった、もうちょっと広い会場でできればいいのに」と言っていたところに、「運営側の苦労も知らないで文句言うな」という意見が流れてきてむしゃくしゃして書いた。
なので、あまりまとまってない。
Javaはユーザーも多く、エンプラな人の比率も高めで、コミュニティを理解せず心無いことを言う人や理解すらしようとしない人も多いと思う。
ただ、彼らをディスってもなんの見返りもないし、そもそも彼らの耳には入らない。
それよりも、彼らに向けた発言を見てしまった、無関係な人を傷つけてしまう可能性があることを知ってほしかった。
いい記事なのだが、いくつか反論や補足が必要だと思ったので書く。
このGPLのコンパイラとはGNU bisonやGCC(GNU Compiler Collection)について指しているのがほぼ明確なのでそれらについて書く。
確かに著作権法を元にしたライセンスは、ソフトウェアの出力結果に対してソフトウェアの著作権ライセンスが影響しないと解釈するのが妥当であるというのは正しい。
ただしこれは"著作権ライセンス"に限った話である、つまり著作権ライセンスでは不可能な制約がEULAなどでは課すことが可能であるということを意味する。
詳しくはGNUの書いた記事の"契約を元にしたライセンス"という項を読むと良い。以下に引用する。
https://www.gnu.org/philosophy/free-sw.html
ほとんどの自由ソフトウェアのライセンスは、著作権を元にしています。そして著作権によって課することができる要求には制限があります。もし、著作権を元にしたライセンスが、上記に記した自由を尊重するならば、まったく予期しない他の種類の問題があることはありそうもないでしょう(予期しないことはまま起こりますが)。しかし、ある自由ソフトウェアのライセンスは、契約を元にするもので、契約はもっと広範な制限を課することが可能です。これは、そのようなライセンスが、容認できないほど制限が強く、不自由でありうる、いくつもの形態がありうることを意味します。
わたしたちは、起こりうるすべてのことをあげることはできないでしょう。もし、契約を元としたライセンスが利用者を(著作権を元としたライセンスでは無理な形で)異常に制限するならば、そして、それがここで正当だと述べられていないのならば、それについて検討しないといけないでしょうし、そのライセンスは、不自由であると結論づけるかもしれません。
また元の記事の著者はGCCやbisonがGNU GPLのような強いコピーレフトで保護されたソフトウェアでも、それによって作成された著作物はGPLにならない(つまりコンパイラやパーサーのライセンスを継承しない)ことを根拠に考察しているようだが、実はbisonやGCCのGPLにはライセンスに対する例外が付属していることを考慮すべきである。
GCCやbisonの著作権保持者であるFree Software Foundationは著作権法の話をするとき、たいていアメリカ合衆国を想定しているがこれらの自由ソフトウェアが広く使われるあたって、著作権法とそれを元にしたライセンスが異なった解釈をされることがありうることをおそらく危惧している、そのため出力に対してソフトウェアのライセンスが影響しないことを確実にするためにこれらの例外を規定しているのではないか。
この二つの理由から、元記事の議論は世界中に対して広く配布するFLOSSディストリビューションでは(非常に残念ながら)鵜呑みに出来ないと私は考える。
加えて言えば、たとえフェアユースの規定が全世界的に利用できて、営利目的でなければ利用できたとしても、
自由.0: どんな目的に対しても、プログラムを望むままに実行する自由
(i.e. オープンソースの定義 6項 利用する分野に対する差別の禁止)
がある限り、そのような制限をディストリビューションは受け入れられないだろう。
またOracle vs GoogleのJavaのAPI訴訟はケースとしてはかなり特例であり、
一般に広く適用すればlibcすら当てはまるのではないかと私は思っている、
これを根拠にしてよいのならばそもそもコンピューター業界がひっくりかえるのではないか。
少なくともUbuntuのようなプロジェクトにおいて、私は断固反対である。
というのは現状ほぼすべてのWeb翻訳(例外があれば教えて欲しい)はプロプライエタリないし、それと同じ結果をもたらすSaaSSだからである。
Webブラウザを介して使う翻訳サービスはSaaSSの代表例であり、ユーザーがコンピューターの計算のコントロールを
持つべきであるという自由ソフトウェアの思想と明らかに相容れないものである。
このようなサービスを利用することの弊害として、(例えば)Google翻訳に翻訳処理の計算を依存することにより、ユーザーの入力をGoogleが常に把握することが挙げられます。
もちろんこれはあまり良いことではない。
多くのFLOSSシステムディストリビューションは自由なソフトウェアを主に入れるというガイドラインを持っている。
アーカイブのごく一部にnon-free(Ubuntuならrestricted/multiverse)なソフトウェアがあるが、
これは事実上妥協の産物であり、排除しても大した問題がないならば配布から除外することに多くのディストリビューション関係者は異論を挟まないだろう。
また例えばDebianはあるソフトウェアがDFSG(Debian フリーソフトウェアガイドライン)に適合するフリーソフトウェアであったとしても、それがガイドラインに適合しない著作物に依存する場合、contribというセクションに閉じ込めており、それは公式のシステムの一部ではないとしている。(建前ではcontrib/non-freeセクションはユーザー向けの付加サービスとされる)
Ubuntuコミュニティで新規に作られた著作物がコミュニティの哲学に反する物に依存するというのは、かなり致命的である。
たとえ奇跡が起こり、例外的にGoogle翻訳や一部のプロ用翻訳ツールがBSDライセンス(Launchpad上での翻訳用ライセンス)での出力を許したとしても決して褒められたものではない。
Ubuntuのbug#1に"Ubuntuソフトウェアは自由である。常にそうであったし、今後も常にそうである。自由ソフトウェアは万人に望むままの方法で使い、望むままの人間と共有できる自由を与える。この自由は多大な利点である。"とプロジェクト創始者であるマーク・シャトルワースが書いていることをよく考えるべきである。
https://bugs.launchpad.net/ubuntu/+bug/1
この反論を読んだ読者の中にはあまりにGNUプロジェクト寄りに思想が傾いていると思う者がいるかもしれないが、
いわゆる"Linuxディストリビューション"の中には数多くの重要なGNUソフトウェアがシステムの根幹をなす形で入り込んでおり(例えばGCC,bash,glibc etc...)
またUbuntuの派生元となったDebianの成立経緯にはやはりFSFが関わっている。
さらに言えば、システムの保守を手伝う人の中にはシステムがフリーだからボランティアで頑張っているという人もいると思う。(ほとんどではないかもしれない)
のでUbuntu周りの話に限ってはこういった観点で見てもよいと思ったので書いた。
免責： これは法律の専門家によるアドバイスではありません。この情報にしたがって行動した結果に対して責任を負うことはできません。
「Web翻訳の結果をオープンソースソフトウェア(OSS)の翻訳に突っ込んではいけませんという話」
http://blog.goo.ne.jp/ikunya/e/37e5a52e10ab26fcbd4f7ff867e9eace
この話では、「もちろん、利用規約的に問題なければWeb翻訳の結果をOSSの翻訳に突っ込んでも*ライセンス的には*問題ありません。」という追記がされてます。
ですが、プログラマの間で単にWeb翻訳をOSSに使ってはいけないんだという認識が広まってるように見えます。個人的には、この認識が広まってしまうのはいやだなと感じたのでこの文を書いています。
どういう話かというと、自分が個人で開発しているオープンソースソフトウェア(OSS)のドキュメントの日英訳をするにあたってGoogle翻訳を利用するか検討して権利まわりの情報をしらべた結果、これは白に近いグレーだろうという判断したので下訳に使ったという話です。(日英両方についてのドキュメント自体も、オープンソースのライセンスで公開しています)
念のため言っておきますが、これは元記事で問題になっている人を擁護するようなものではありません。翻訳コミュニティの人たちが自分たちのものにグレーなものを入れたくないと思うのは当然でしょうし、権利問題以外にも翻訳クオリティやその他の問題行動の話もあります。
コミュニティの思想にそぐわない人が、そのコミュニティの中で作業していくのは難しいでしょう。
もとの記事のとおり、Excite翻訳の利用規約には私的利用を超えた利用についての禁止が明記されています。こういった明確に禁止されているものについての話はここではしません。
ここでは、Google翻訳に焦点を当てた話をします。Google翻訳の利用規約はどうか？というと、Googleの利用規約については翻訳結果の利用についての記載がありません。
https://www.google.com/intl/ja/policies/terms/
記載がないということは、使用してよいのか？使用してはいけないのか？いったいどちらなのでしょうか？
機械翻訳の権利問題と似た構造の話に、GPL（GNU一般公衆ライセンス）で許諾されたコンパイラによってコンパイルした結果の利用があります。
GPLの本文には、GPLのプログラムの出力結果自体にGPLのものを含む場合にのみその出力結果にGPLが適用されることについての記述がありますが、GPLのものを含まない出力結果についてどういう許諾がされているかの記載はありません。
これについては、コンパイラによるコンパイル結果に対して、コンパイラの著作者はなんら権利を持たないと考えるのが一般的です。
https://www.gnu.org/licenses/gpl-faq.ja.html#GPLOutput
著作権法は人々があなたのプログラムとかれらのデータを使って作った出力結果の利用に関して、あなたに何の発言権も与えていません。
コンパイラと機械翻訳ツールとの違いが、対象が人工の言語であるか、自然言語かので違いしかないと考えるならば、Google翻訳の結果をOSSに利用することも問題ないということになります。
ウィキメディア財団の法務チームは、Google翻訳した文書のウィキペディア内での利用についての見解を公開しています。
https://meta.wikimedia.org/wiki/Wikilegal/Copyright_for_Google_Translations
これはアメリカの法律に基づく話ですが、CC-BY-SA 3.0やそれに類似するライセンスのコンテンツをGoogle翻訳で翻訳してウィキペディアで使用してもGoogleの著作権を侵害する可能性はとても低い(very unlikely)と結論づけています。
要点をまとめると以下の通りです。
ウィキメディア財団の見解には含まれていませんがアメリカの法律でいえば、さらにもう一つ「フェアユース」にあたるのではという話があります。これはGoogle自体がよく知っている話かもしれません。
これはAndroidのAPIにJavaのAPIが流用されていることについて、OracleがGoogleを訴訟したものです。
これについて、Java APIについての著作権が認められたものの、Androidでの使用は「フェアユース」に該当するとGoogleは主張し、カリフォルニア州サンフランシスコの地裁では著作権使用料支払いの対象にはならないという判決が下っています。
「フェアユース」というのは、アメリカの著作権法上の概念で、以下の4要素を判断指針として考えて公正な利用と認められれば、著作権の侵害とはしないと考えるものです。
ということになり、4つの要素どれをとっても、フェアユースであると認めることに対して有利に働きます。これは、AndroidのJava APIの流用と比べても、さらにフェアな利用であるように見えます。
(ちなみにGoogleの利用規約には、「カリフォルニア州の抵触法を除き、本規約または本サービスに起因するまたは関連するいかなる紛争に関しても、アメリカ合衆国カリフォルニア州の法律が適用されます。」と書かれています)
著作権情報センターのサイトに、 コンピュータ創作物についての文化庁の報告書が記載されています。
http://www.cric.or.jp/db/report/h5_11_2/h5_11_2_main.html
この報告書は、機械翻訳のユーザーが機械翻訳システムを使用するために行う原文の編集や出力の編集が創作的寄与となりうることを認めている一方で、機械翻訳の開発者が翻訳物の著作者になるということについては否定的です。
なお、原文解析等のプログラムの作成者及び汎用的な辞書データベースの作成者は、一般的に翻訳物の作成の精度、正確度等を高めることに寄与することとなるが、特定の翻訳物の作成自体にかかわっているわけではないので、その著作者とはなり得ないと考えられる。
これは平成5年とかなり昔に書かれた報告書であり、それから機械翻訳の技術は大幅に進歩しましたが、創造的個性の表現を目指して作られているもので無い機械翻訳であれば、やはり翻訳の結果の利用について問題がないようにみえます。
これにしたがえば、単純に文章をそのまま機械翻訳に投げ入れた出力結果は、原文の著作者の著作物。機械翻訳に投げ入れる前や後に十分な編集をしていれば、加えてその編集した人間の二次著作物になるということになりそうです。
これまで、どうしてGoogle翻訳の結果をOSSに使うことが白に近いと言っているかを説明してきました。
では、どうしてグレーなのかというと、新しい種類の権利問題なので判例がないからです。実際に訴えられたら負けました、ということもまったくありえない話ではないでしょう。
だいたい、ここまでが話したいことの半分です。ここからはグレーなものの良し悪しの話をします。
著作権などの権利問題についてグレーなことをやっているOSSというのはそれほど珍しいわけではありません。
有名なところでいうと、Monoが思いつきます。AndroidのDalvikがJavaのAPIを真似したものであるのと同じように、MonoはMicrosoftの.NETフレームワークを真似しています。つまり、Monoについても訴訟リスクはあっただろうということです。
しかし、OracleとGoogleが対立したのとは対照的な道をMonoはたどります。
2016年、Monoのプロジェクトを運営していたXamarin社は、そのMicrosoft自身によって買収されました。権利的にグレーだったMonoがMicrosoft公認のプロジェクトになったというわけです。
権利的にグレーだからといって、プロジェクトとして失敗に終わるわけではありません。
すこし元の記事に話をもどします。冒頭にも書いた通り、Ubuntuの日本語化プロジェクトに対してWeb翻訳の結果を突っ込むという行為は、批判されるべきだと思っています。
まずは質の問題です。現在のGoogle翻訳などは、UIの翻訳に向いていません。UIのほとんどは、意味合いが文脈に依存する単語や短文です。UIの翻訳は、実際にその機能を動かしながら、動作にあった訳語を割り当てていくべきです。
Google翻訳などを使って一括で、訳語を割り当てても良いUIの翻訳はできません。
（ UIにとっての良い訳については、元記事のいくやさんがとても良い話を書いています: https://github.com/ikunya/howtotranslatelibo/blob/master/howtotranslatelibo.md#ふさわしい翻訳の考え方 ）
次に、白に近かろうがリスクのあるものを入れることになるということです。Ubuntuの日本語化ローカライズであれば、すでに多くのユーザーが使用しているでしょうし、そういうものについてリスクのあるものを後から入れることになります。
そういったことを独断で黙ってやるというのは、歓迎されたものではありません。少なくとも、コミュニティに対して事前に方針を聞いたりすべきだったでしょう。
つまり、クオリティが低い上にリスクのあることを黙ってやったわけで、もちろん批判されるべきでしょう。
とはいえ、OSSには個々の事情があります。次は自分の場合の話をしてみます。
まずは質の話です。
自分のプロジェクトの場合、Google翻訳を使ったのはドキュメントです。日本語で書いたドキュメントをあたらしいGoogle翻訳に入れてみたところ、そこそこのクオリティの翻訳が出力されており、自分でゼロから翻訳するよりも、原文を翻訳しやすく修正したり結果に対して修正を加えていったほうが質と速さの両面でよいと判断したので、Google翻訳を使用しました。
次にリスクの話です。
OSSが企業に権利問題で訴訟されるということはめったにありません。OSSは公益性の高いものなので、むやみに訴えれば社会からの反感を買いますし、ほとんどの場合は訴えても大した金になりません。
訴えられるとすれば、そのOSSが十分に儲かっている場合です。もしOSSで大金が儲かったらGoogleから訴えられてしまう！どうしよう！と考えるのは、宝くじに当たったら強盗におそわれてしまう！どうしよう！と考えるのに似ています。
まず宝くじは当たらないですし、宝くじが当たったらそのお金で対策を行えば良いだけの話です。
実際Linuxでは、特許周りの対策としてOpen Invention Network(OIN)を設立しています。Linuxなどソフトウェアに対して特許を主張しないことに同意した企業から特許を買収して、そういった企業に対してロイヤルティー・フリーで許諾を行っている会社です。
これによって、Linux関連のソフトウェアに対して訴訟をしてきた、いわゆる「パテント・トロール」に対して訴訟をやり返すなどの対抗手段を得ているわけです。
権利問題で訴訟されたことによって失敗に終わったOSSというのはほとんどありません。多くのOSSは、作者が飽きたり、面倒な作業にうんざりしたり、誰にも使われなかったり、競合に勝てなかったりしたことで、フェードアウトしていきます。
結局のところ、自分の場合はGoogle翻訳をつかったところで、Googleにも、自分にも、ユーザーにも、世間にも不利益はなく、むしろドキュメントの質は上がって、Googleも翻訳を改善するためのデータを得られます。
わずかなリスクを避けるために、時間を割いた上、質を落とすというのはくだらないですし、そんなことに時間を使うくらいならコードを書いていたいものです。
結局、Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか？というのは個別の話でしかなく、ひとまとめにWeb翻訳の結果をオープンソースソフトウェアの翻訳にいれてはいけないとか、使うべきとかそう簡単には言えません。
質が悪いしリスクがあるのであれば単純に禁止で済む話ですが、機械翻訳が向上して、質が良いがリスクのある例が増えると話はさらにややこしくなります。
各OSSの翻訳者のコミュニティは機械翻訳の利用についてそのプロジェクトで使って良いかの方針を定めてやっていくしかなく、後からコミュニティに入っていくような人が機械翻訳を使いたい場合はコミュニティの方針を確認した上でやっていくしかないんだろうなあと思うところです。
もちろんスペシャリストがきちんとわかった上でOracleを使ってる案件は大丈夫なんだろうが、中小規模案件でOracle使ってるのにろくなのがない。
・データベースは当然のごとく正規化されてない。昔はされていたのかもしれない。
・使用されていない予約されたカラムの山。必須でない情報でもカラムを作るのでテーブルがどんどん肥大化していく。
・謎のインデックスが大量にあるが、パフォーマンス上本当に必要なインデックスはない。
・ストアドプロシージャが秘伝のタレ化。そのせいでOracleから抜けられない。
Oracleを使うとDB設計者の脳は破壊されるのだろうか。脳が破壊されているからOracleを使うのだろうか。
A- 日本IBM、NTTコミュニケーションズ、アクセンチュア、野村総研(NRI)
B+ NEC、日本HP、新日鉄住金ソリューションズ(NSSOL)、日本総研(JRI)、大和総研(DIR)
B NTTコムウェア、伊藤忠テクノソリューションズ(CTC)、電通国際情報サービス(ISID)
B- 三菱UFJインフォメーションテクノロジー(MUIT)、みずほ情報総研(MHIR)、
C+ JSOL、農中情報システム、SCSK、日立システムズ(HISYS)、日立ソリューションズ(HISOL)
C NECソリューションイノベータ、ニッセイ情報テクノロジー、JR東日本情報システム(JEIS)、
C- オービック、TIS、オージス総研、富士通エフサス、シンプレクス、
D+ 三菱UFJトラストシステム、三菱総研DCS、兼松エレクトロニクス、都築電気、
D 損保ジャパン日本興亜システムズ、インフォコム、セゾン情報システムズ、日商エレクトロニクス、
コベルコシステム、IIJ、ネットワンシステムズ、パナソニックインフォメーションシステムズ、
菱化システム、JRシステム、富士通システムズイースト、東芝ソリューション、富士通FIP
D- ユニアデックス、NECネッツエスアイ、日立産業制御ソリューションズ、
三菱電機インフォメーションシステムズ、MS&ADシステムズ、NTTソフトウェア、
NTTアドバンステクノロジ、JFEシステムズ、テクマトリックス、三井情報、第一生命情報システム、
ソニーグローバルソリューションズ、ワークスアプリケーションズ
E+ 富士通システムズウエスト、富士通マーケティング、三菱電機インフォメーションネットワーク、
中央コンピュータシステム、ティージー情報ネットワーク、リンクレア、ジャストシステム
E NECフィールディング、NEC情報システムズ、富士通BSC、日本情報通信、
住友電工システムソリューション、JR西日本ITソリューションズ、
E- 富士通ネットワークソリューションズ、日立公共システム、NEC通信システム、
F+ 日立ソリューションズ・クリエイト、キヤノンソフトウェア、さくら情報システム、
トヨタコミュニケーションシステム、エクサ、アイネス、TKC、CAC、CEC、SRA
F クオリカ、NSD、DTS、さくらKCS、東邦システムサイエンス、菱友システムズ、
26歳3年目 転職を考えてる。
持ってる資格
Oracle Bronze,Silver
統計検定2級
大規模構築経験あり
仮想基盤やAWS,Azureのパブリッククラウドの構築経験あり
ミドルは、bind,sendmail,samba,nginx,Apache,Zabbix,LDAPとか
麻雀(天鳳)が趣味で、牌譜の解析とかやりたかったから統計を勉強して、資格にチャレンジしてみた。ついでにpythonと数学も。どちらも業務で使うことはほぼない。
趣味Webメディア作ってたから、Wordpressサイト作るくらいなら一晩で出来る程度の能力。
http://anond.hatelabo.jp/20160703171723
それは，一言で言うと「金融緩和してもほぼ全部金融市場が吸い取ってしまい，実体経済に金が回らない」からである。
（以下は素人の私が勝手に考えたものだが，もし同じようなことを言っている経済学者がいたらぜひ教えて欲しい。まあ，素人と同じようなことを考える学者はいないと思うが。）
そもそも私がこういうことを考えるに至ったのは，1990年代終わり〜2000年代初頭にかけてのITバブルがきっかけである。その当時，IT経済を主とする"成長"は「インフレなき経済成長」と呼ばれていた。それは論理的におかしい，何か理由があるはず，と考えた結果，「これは実体経済に回るとインフレを起こすお金の大半が金融経済に回っていて，その結果金融経済が"成長"している一方，実体経済ではインフレが起きていないのでは」という結論に達した。
具体的には，当時のITバブルでは，資金がインターネット上の広告を売る新興企業に流入した。インターネット上は空間的な制約がないので，それら新興企業はほぼ設備投資をすることなく広告をいくらでも増やせる。他方，インターネット広告への期待から，それら新興企業の広告枠を買う企業が現れる。そうするとそれら新興企業の株価が上がる。株価が上がると，それを売って儲ける投資家が現れる。儲けた投資家は，またそれを新興企業に投資する。広告も一種の投資なので，広告枠を買う形で投資を行う者もいる。そうするとまた株価が上がる。
このバブルでは，対象が「インターネット上の広告枠」という無限に近い資源だったこともあり，実体経済には余りお金が回らなかった。せいぜい Sun Microsystems のサーバーが売れた程度である。ただし巨大なバブルだったので，おこぼれといっても巨大で，この後バブルが崩壊すると Sun は後遺症に悩むことになり，最終的に Oracle に買収されて消滅する。
しかしこのバブルの本質は，2次投資，3次投資，...という高次投資によって金融経済の中で資本が循環し，循環の過程で（見かけ上の）資本が拡大していった点にある，と私は考えている（バブルというのは須らくそういうものだが）。
結局このバブルは，「広告にいくら投資しても実際に広告対象の商品が売れなければ意味なくない？」ということに広告主が気づいたことで崩壊した。つまり，いくら金融経済が期待値で拡大しても，最終的に実体経済がそれに見合った成長をしなければ，それはバブルであり，バブルは必然的に崩壊するのである。
次に，この考えの傍証として私が注目したのは，金融経済と実体経済の規模の乖離である。
http://www.meti.go.jp/report/tsuhaku2008/2008honbun/html/i1120000.html によると，2006年時点で，金融資産の規模は実体経済の3.5倍であり，1990年以来の平均成長率は，実体経済が5.7％であるのに対し，金融資産は9.1％となっている。
これは異常である，と思う。
投資というのは，最終的に実体経済が拡大しないと，リターンを得られない。
ちょっと金融からは外れるが，土地転がしを例に考えてみよう。土地の値段は，循環取引的な手法を使えば，原理的には無限に上げることができる。その間，資産規模は拡大していく。しかし，それらはどこまでいっても「投資」であり，その投資を回収するためには，その土地で建物を建てて商売して利益を上げて地代を払ってくれる誰かが必要である。
もちろん投資には期間があって，5年のものもあれば，10年，20年，...といったものもあり，それらが混ざり合っている。従って，必ずしも実体経済と金融経済の規模が一致していなくてもよいが，金融経済の方が実体経済よりも速く成長するのは，やはり異常であろう。
この金融経済と実体経済の乖離は，おそらく1990年代の金融規制緩和以降に始まったのではないかと思う。この規制緩和によって，通貨以外のものを通貨と同様に扱えるようになり（例：株式交換による買収），またBIS規制の枠外で高次金融商品（金融商品に投資する金融商品）が解禁されて，金融商品を土地転がしのように転売することで金融経済が拡大することを可能にしたのではないかと思われる。
その結果，金融経済は恒常的なバブル状態になった。実体経済の成長を伴わない金融経済の成長はまやかしだが，そのまやかしがいつ露呈するかわからないので，それまでは疑心暗鬼ながらもチキンレースを続けている。まやかしだとわかっているが，実体経済よりも遥かに楽に大金をを得られるので，やめるにやめられない。それが今の状況なのではないだろうか。だから逆に，ちょっとしたことで株価が乱高下する。Volatilityが高くなってるのも，恒常的なバブルのせいと考えると個人的には納得がいく。
さて，金融緩和はここでどういう役割を果たしているかというと，このバブルを崩壊させないように金融経済に現金を注入する役割を担っているのではないかと思う。
金融緩和の恩恵を（最初に）受けるのは銀行，投資家，大企業である。
とにかく最初に恩恵を受けるのは銀行。商材であるお金が日銀から低利で借りられる＝安く調達できる。
次が大規模投資家（ファンドや超がつくレベルの資産家等）や大企業。日銀から直接お金を借りるような大銀行の主要顧客になるようなところ。ここも従来より安い金利で資金を借りられるようになる。で，借りた資金を，大規模投資家はより（見かけ上の）リターンの高い金融商品（株式等）につっこむ。大企業は設備投資したり，やっぱり別な金融商品に投資したりする。銀行から借りた資金が，給与を上げる原資に直接使われることはまずないと思う。
つまり金融緩和の恩恵の大半は最初に銀行，投資家，大企業が取ってしまうし，その大半は実体経済ではなく金融経済の拡大に回ってしまう。その方が手っ取り早く稼げるからだ。残った僅かな（文字通りの）「トリクル」だけが，実体経済に回る。だから効果はゼロではないが，金融緩和の規模に比べると遥かに小さいし，また効果が出るのも遅い。設備投資が，さまざまな労働者の給与増に波及するのには，時間がかかるだろう。
近年の「異次元」と呼ばれるような金融緩和でもインフレがおきない（インフレ目標すら達成できない）のも，金融経済が金融緩和で生み出された資金を吸収し，実体経済にほとんど回ってないから，と考えると説明がつくように思う。
一番良いのは，金融規制を1990年代以前と同程度まで強化し，過剰流動性をなくすことだと思う。しかし，ここまでバブルが大きくなってしまうと，その破裂によってもたらされる実体経済への影響は，たとえもともとそれが率としてはトリクルであったとしても，絶対額が巨大なため，悲惨なことになると思われる。なので，風船が急にしぼまないよう，少しずつ空気を抜くような慎重さが必要になるだろう。
個人的には，長期投資は実体経済にとっても有益だが，短期投資（＝投機）は害の方が多いので，短期投資に高い税率を課し，事実上無意味にしてしまうような政策が取れればいいのに，と考えている。株式や債券，その他の金融商品を在庫管理と同様の手法で管理し，例えば今日買った株を今日売ったら税率99％，逆に20年持ち続けた株を売った時は税率1％というようにすることで，長期投資を促すような政策は手法的には可能だと思う。
また高次投資も有害性が高いので，税率を高くする。例えば株式の売買は2次投資だから課税対象だが，配当は1次投資のリターンなので，非課税にするなど。株式はトレーディングの対象ではなく，本来の「直接金融によってリターンを売る権利＆会社の支配権」の位置に戻した方が良いのではないだろうか。
最後に，これは妄想だが，金融経済と実体経済を可能な限り切り離す，というのが本当はできればいいと考えている。具体的には，金融経済はそれ専用の独自通貨を作り，その中で自由になんでもやっていい。ただし実際の通貨に交換できるのは，世界の実体経済のGDPの3%まで，とか決めておく。誰がその3%を使えるかは，金融経済の中で，専用通貨でオークションでもやって決めればよい。まあでもこれは残念ながら実現不可能だろう。
というわけで，今以上に金融緩和をしても無意味なんじゃないかな，と思ってる。
ところで，なぜ財政政策のところが「再分配（例：富裕層への課税強化＆低所得層への扶助）」じゃなくて「財政出動」なんだろう？
ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。
今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。
「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。
タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー
面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。
Javaの1.0がリリースされたのは1996年1月23日ですね。発表されたのが1995年5月23日でJavaの誕生日といった場合にどちらを取るかで揉めることがあります。
かれこれ20年前なわけで、当時のパソコンというとハードウェアはCPU が Pentium 133MHz メモリ16M とかそんな感じだったかなあ。今どきの携帯電話の例としてiPhone 6sを挙げるとCPUが1.85GHz メモリ 2G ってんだから凄いですね。OSは1995年11月23日にリリースされたWindows95とかそんな時代背景です。インターネットがようやく一般に普及し始めたところでしょうか。
今から思うと相当弱いハードウェアですけども、そろそろVM方式を採用しても良さそうな、そんな時代でした。インタープリタだと流石に遅い、でもC言語のようなコンパイル言語だと"Write once, run anywhere"とはいかない、という判断もあったのだろうと思います。Javaが純粋なオブジェクト指向言語ではなくintなどのプリミティブ型を持つというのは、当時のマシンスペックを考えた場合、ある程度妥当な判断だったと言えるでしょう。これが後々苦しくなってくるわけなのですが。
Javaを作った会社はSun Microsystems(サン・マイクロシステムズ)というアメリカの会社で、2010年1月27日にオラクルにより吸収合併され今はありません。SolarisというOSとSPARCプロセッサでUNIXサーバーの販売で90年代後半までは一人勝ちのような状況だったと聞きます。当時にすでに「ネットワークこそがコンピュータ」（The Network is the Computer）というモットーを掲げてたんだからおかしい。1996年リリースのJavaが標準でネットワーク機能を備えていたのもこのあたりの思想から来ているのかもしれませんね。
当時のプログラミング言語としてC++が挙げられますが、C++でのプログラマへの負担といいますか、ヒューマンエラーの起きやすさといいますか、その辺を改善する目的で開発されたのがJavaだったわけです。
1996年の時点にこんな言語が登場したのですから革新的でした。
いろんな企業がJavaに賛同します。その中にはMicrosoftもありました。この時期、Microsoftは次期のWindows開発用のプラットフォームにJavaを据えようと考えていました。その後、袂を分かつことになるのですが……。
プログラム言語として構文などを見ると、C++を強く意識した構文なのは間違いなく、しかしポインタ演算を廃してポインタを機能を限定した「参照」に置き換えるなど簡素化が多く見られます。C++からはいろんな機能が削られています。関数ポインタ、構造体、演算子オーバーロード、テンプレート((テンプレートについては実装が間に合わなかったという話を聞きます))などなど。そのためC++の劣化であるように揶揄する人もいますが、こうしたものを捨てて言語仕様を比較的小さくシンプルに抑えた点は評価に値すると思います。しかし、今でもこうした削減された機能を愛する人からはJavaを腐す要素として挙げられてしまうのでした。
Wikipediaからピックアップすると1.1での大きな機能追加は
といったところです。当初よりJavaの内部文字コードはUnicodeで文字を表すchar型は16bitで設計されていました。Unicodeは当時それほど普及しておらず、Unicode対応のテキストエディタさえ少なかったと記憶しています。時代を先取りしていると言えますが、大きな誤算はUnicodeが当初16bitのコードポイントに世界のあらゆる文字を格納しようとしていたことで、漢字圏の我々からすると16bit=65,536程度の空間に文字が全部入るわけないだろ！というものだったが故に早々に破綻し、Unicodeは21bitのコードポイントに拡張されることになるのです。これはまた後の話。
なんにせよ、日本語が対応されたのは1.1からで、日本でのJavaの採用が始まったのはこの頃からと言えましょう。
当時のJavaのGUIはAWTというものでしたが、これを用いたGUIの開発は当時は結構行われていたイメージですね。Visual BASIC でGUIを作るプロダクトも結構あったと思います。GUIのためのオブジェクト指向言語としてJavaが使われていたイメージがありますね。JavaBeansもそのための仕様でした。件のsetter/getterの話題に繋がっていくのですが。
JDBCはJavaとデータベースをつなぐインターフェースです。RMIではあるJava VMから別のJava VMにオブジェクトを送って実行する、といったことができます。こうした機能が用意されたことで、ソフトウェアのフロントとしてのGUI、裏方の実装のためのネットワーク機能、データベース機能、さらにはソフトウェアを配布するためのJava Appletという布陣でJavaでのソフトウェア開発が加速していた時代といえます。
Microsoft Visual J++ もこの時代ですよ。
Java 1.1以降のバージョンのものは互換性確認のためにOracle Java Archiveからダウンロードすることができ、今でも入手することができます。もちろん、Java7ですら2015年4月にEOL(End of Life,サポート終了)となっているので、通常利用するのはJava8としてください(本稿執筆時点)。
当時のドキュメントを見るのも一興です。現在と比べると標準APIがかなり小さい。なお、当時のjavadocは今とはデザインが大きく異なります。
この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。
strictfpキーワードは浮動小数点演算をやる人は覚えておきましょう。JavaはパフォーマンスのためにCPUの浮動小数点演算を扱うことが許されており、そのため実行するCPUによって精度が異なることがあるんですね。まあ今時のCPUだと大丈夫だとは思うんですが。
リフレクション機能ではJavaのクラスを抽象的に扱うことができます。設定ファイルに書かれたクラス名のclassをロードして実行する……みたいなことができるんですね。フレームワーク的なものを作る場合には多用することになります。
1.2からは新しいGUIのSwingが採用されました。AWTがOSごとのGUIパーツを用いていたためデザインに違いがあったのに対し、Swingでは統一的なルック・アンド・フィールが用いられるようになりました。まぁ今ならJavaFXを使うのが良いと思います。
初期のJavaはやはりVM方式の実行速度の遅さが指摘されていました。実行時の構文解析を伴わないだけインタープリタよりは早いものの、実行バイナリを作るC/C++よりは遅い、そうした評価です。ここではサン・マイクロシステムズのVMにJIT(ジャストインタイムコンパイラ)が乗ったことが挙げられていますが、JIT自体は別の会社が先駆けて開発していたことは記しておきたいと思います。
JITコンパイラは実行時にJavaのバイトコードを環境のネイティブコードにコンパイルして動かす技術です。この後、JITコンパイラ、動的再コンパイル技術、世代別ガベージコレクションを備えたHotspotといった様にJavaVMは進化していきます。現代では実行時の最適化が進み、大きなスケールで見た場合、Javaの実行速度はC/C++での実装と比べてそれほど遅れるものではありません。遅くても倍の時間は掛からない程度といったところでしょうか。
あとは特記すべきはコレクションフレームワークです。皆が多用しているであろうjava.util.Listやjava.util.Mapといったライブラリが整備されたのがこの時なのです。それ以前はjava.util.Vectorやjava.util.Hachtableというクラスが可変長配列の機能を一手に担っていました。今ではVectorやHashtableは使うべきではありません。
Java の開発はSun Microsystems が主導していたけども、すべてがSunのものだったというわけでもなく。Javaには多くの会社が出資していてその中のひとつがMicrosoftだったわけですね。
Microsoft の Visual J++ では delegate とか独自機能拡張もありましたけど、裁判で問題になったのは J++ でコンパイルしたclassファイルはMicrosoftのVMでしか動かないという部分ですね(他社製のVMで動くclassファイルを作ることもできる)。classファイルがどこのVMでも動くの大事だろ、"Write once, run anywhere"だろ、お前何してくれてんの！と喧嘩になったわけです。当時のMicrosoftはブラウザまわりでも独自拡張がやりたい放題、標準規格？なにそれ美味しいの？みたいなスタンスをあちこちで見せていたものです。
結局、この事件でMicrosoftのJavaはバージョン1.1相当でストップ。好き勝手にやれないなら独自に言語作るわーとばかりに.NET フレームワークと C# といった方向に舵を取ります。
JavaがPC上でのUI開発の主力になろうとした勢いはここで潰えます。
Java SE とは別にこの時代に Java EEがリリースされていることは特記しておきたいですね。これ以後、それまでのCGIに取って代わって、JavaはWebサービスの開発のプラットフォームとして多用されるようになります。
2000年あたりからはJavaはGUI開発というよりは、Webサービスの開発が主流という流れになっていきます。インターネットのサービスが非常に発達していった時代、背後ではとてつもない量のJavaのプログラムが支えていたわけです。ただまあ、こうした産業利用は一般的なユーザーの目にはあまり入らないわけです。一般人からすればJavaといえばJava Appletみたいなイメージはずっと残っていたでしょうが、実体としてはJavaといえばServletという時代になっていたわけです。
企業で用いられる社内システムにもServletは多く採用されました。
理由はいろいろ挙げれると思うのですが
というのが大きな理由だろうと思います。JSPというテンプレートエンジンを用いてHTMLを整形してWebページを作り出す、というアーキテクチャはある意味では便利で簡単でした。
もっともHTMLの表現力に足を引きずられるため、GUIの機能性という点では後退したわけなのですが。それでもメリットが大きいと判断されたのでしょう。というか、まともにGUIを組めるプログラマがほとんどいないから、GUIのシステム開発がなかなか成功しないってのもあったんでしょうけどね。
2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホ、ガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。
そこにdocomoのiアプリ、Jフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ！というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリはちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。
iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。
docomoはiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。
この賭場が、将来にAppleのiPhone, GoogleのAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoはSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。
話を2001年に戻しましょう。
Microsoft離反でGUIのプラットフォームとしてのJavaというものは存在感を弱めていました。この分野の復権に寄与したのはJava 1.4 (2002年2月6日)で導入されたJava Web Startです。
Java Appletがブラウザ埋め込みで動作したのに対し、Java Web Startではブラウザから起動しつつも独立したアプリとして起動するのです。
Webシステムが企業の社内システムに採用された話は先に述べたとおりですが、やはりWebシステムのGUIというのはHTMLに引きずられて貧弱だったんですね。
端的に言えば入力値が数字かどうか？みたいなチェックがなかなか難しい。HTML上でJavaScriptでやるわけなんですが、なかなか気持よく入力できるような感じにはならなかったんですね。
また、Ajaxによるブラウザのページ遷移を伴わない通信というのが出てきたのも2005年ぐらいなので、入力値に対してサーバ問い合わせするようなことはできなかった。当時だと一旦画面遷移させないとできなかったわけです。
こうした事情から、クライアントサイド、要するにPC側でもっとリッチなUIが使いたい！という要望があったわけです。Webシステム使いにくい！という不満の噴出と言ってもいい。そこで出てきたのがRIA (Rich Internet Applications)というわけです。
Javaは1.0時代のAppletからそうですが、ネットワークを介して別のPCにプログラムを送り込み、そこで動作させるという能力を持っていました。それこそまさにRIAに求められる機能性だったわけですね。
RIAの代表とされるのは
あたりです。三つ巴の戦い、どこに軍配が上がるのか！？と注目されましたが、勝利したのはHTML / JavaScriptでした。
Google MAP で注目を浴びたAjax技術、それまでブラウザでは不可能と思われていた高級なGUIをHTML / JavaScriptで実現させました。もうやめて欲しいですよね。せっかく脱ブラウザの流れが来たと思ったのにまたWebシステムに逆戻りですよ。
RIAが失速した理由として考慮して置かなければいけないのはスマートフォンの台頭です。RIAでは端末を選ばずどこでも同じアプリが動かせる点がポイントのひとつでしたが、スマートフォンではそうは行かない。"Write once, run anywhere"を破壊したのはスマートフォンだったというわけです。
しかし、先日インストールなしでアプリを実行するAndroid Instant Appsが発表されたりしまして、結局RIAの思想といいますか、要求というのは今でも息づいているのだなと思った次第です。
1.3 / 1.4 では機能追加はあっても言語構文が大きく変わることはありませんでした。大きく変わったのはJava 5です。この時からバージョニングが変わって1.5ではなく5と表記されるようになりました。
Java5の特徴はなんといってもジェネリクス。それまでjava.util.Listにデータを出し入れするのにはキャストが必須だったわけですが、ようやくキャストから開放され型の安全度がぐっと高まりました。その他に以下のような変更があります。
言語としては随分変わっったわけですが、もうかれこれ10年以上前のことですからこれらの機能が「Java5から導入された」という知識は今となってはあまり必要とされません。これらの機能が使えないJava 1.4で開発をする事案が殆ど無いからです。0ではないのが悲しいところではありますが。
Java 6 (2006年12月11日)がリリースされた後、Java 7 (2011年7月28日) が出るまでJavaは停滞してしまいます。その間にSun Microsystemsという会社がなくなってしまったためです。
Sun Microsystems の経営状況が悪化しており、ついに身売りをすることになりました。身売り先はIBMともGoogleとも噂されましたが結局2010年1月27日にオラクルに吸収合併されました。
Javaの停滞中にはJava VM上で動く非Java言語も台頭してきました。Scalaなどですね。
やや戻って2007年にAndroidが発表されます。Androidの開発言語にはJavaが採用されていますが、実行環境はJava VMではなく、ライセンス的な事情でJava(TM)は名乗らない微妙な位置関係にあります。
Java 5 以降で大きく言語仕様に手が入るのは Java 8 (2014年3月18日)です。並列処理を行うためのStream APIと、そのために簡易に関数を定義するためのラムダ式が導入された点が大きいですね。日付APIも刷新されました。
このように、Javaは1.1の黄金時代から今に至るまで利用ジャンルを転戦しながら産業の土台となって支えてきた歴史があります。ジャンルの趨勢により浮き沈みもあります。今後についても決して楽観視はできないでしょう。Javaを学ぶことはプログラミングを学ぶステップとしては意義はあると思いますが、Javaを学べばゴールというわけではありません。プログラム言語も次世代へと移りつつあります。業界動向には注視していきましょう。
ある日、たまにお世話になってるBさんからシステム構築の相談を受けた。知り合いの使ってるシステムが拡張できなくて困っている、知人に会わせるから詳しく聞いて欲しい、という事だった。このお客さんというのは過去にツーショットダイアルでしこたま儲けたらしく、金は持ってるという話だった。そういえば前に、自社でやってる出会い系サイトが重くてしょうがないんだけど助けて欲しいって相談を受けた事がある。第一世代iMacで構築してたらしく、ちょっとカブれたシステム会社にあたっちゃったんだなと思ってた。その時はまとまった時間が取れなくて手伝えなかったんだ。俺はMacは好きだけど、当時仕事ではIAサーバーにSAN繋いでOracleでDB構築とかしてたので、Mac+FileMakerでWebアプリ作ってるって聞いてひっくり返った覚えがある。
K県にあるオフィスへいった。担当者Hさんとはすぐ話が出来たが、オーナーのWさんは渋滞に巻き込まれて1時間ほど遅れて来た。Bさんからは「見た目は思いっきりヤクザだけどいい人だから」と言われていたけど、サングラスでもかけて無い限り普通に人の良さそうな叔父さんだった。日本語は上手。アクセントは中国訛りだけど、システムのことがよくわからないHさんよりよっぽど話が通じる。
内容は「コミュニティサイト」、つまり「出会い系サイト」だと言う。会員数は１万人。有料サイトで1万人はかなり凄いはず。ガラケーの待ち受け画像サイトとか手伝ってた時には、内部関係者とか無理矢理登録させて盛りに盛って5千人も行けばいい方だった。思わず口に出た「え？１万人ですか！？凄いですね」 。WさんとHさんは何故か目を合わせて苦笑いしてる。ハードウェア構成は1万人にしてはちょっとショボイかなと思ったけど、hpのDL380とMSA500の構成を打診してみた。一式200万〜くらいだけど向こうにひっくり返られて、今は数万円の自作PCでやってるって事だった。まあハードで儲ける気はないからいいけど。
出会い系のシステム構築し始めて、一番話が噛み合わなかったのが会員インポート機能だ。現行システムからの移行に使うという。そんな一回しか使わない機能、手動でコンバートするからこの機能外させてくれって何度も言ったんだがどうもこの機能にこだわる。むしろこの機能がキモだとまで言う。あ、だんだんわかってきたぞ。
こいつは有料会員が１万人もいるような優良サイトではなくて、名簿屋から買った会員情報を流しこんで会員数万人に仕立てあげるシステムだ！。俺は金に成るならマルチの管理システムでもなんでも作ったるわと思ってたからやるけど。現行サイトは女性会員として登録しても男性会員から検索できない。これは客がテストのために女性として登録してクレームをつけてくることがあるから、検索できるようにして欲しいと言われた。出会えなかったら客が残らないんじゃないですか？って聞いたら、あまり出会わせないんだと。実会員同士が連絡を取っちゃったら直メールでやりとりしてポイント消費しないから、出会えないのがいいんだと。なるほど、ワルだね！
程なくして（すったもんだあったけど）システムが完成して、同一システムで見た目だけ変えたものをいくつか作らされた。有料出会いサイト、無料の客寄せサイト、そもそも出会いとして機能してないDM送信サイトがあった。有料出会いサイトの売上は、うまくいってるサイトでも月間数十万程度なんだが、１サイトだけずば抜けて売上の高いサイトがあった。毎月コンスタントに500-600万は売り上げて、多い時は1000万を軽く超える。こんなことなら売上のパーセンテージで保守料貰えばよかったなあ。
一体どうしてこのサイトだけこんなに売上があるのかと、ちょっとサイトのメールやりとりを覗き見して青ざめた。こいつらもう出会いなんて全然エサにしてない、初めから「あなたに1000万円当たりました。振込の手続きをするので合言葉'XXXX'を送信してください」などと言ってポイントを消費させてるだけだった。この頃はまだ男性向けが圧倒多数だった気がする。後に女性向けにジャニーズを騙ったり、占いサイトと称して幸福に成るための合言葉を連投させたり、そのうちエスカレートして金の単位は億になり、あからさまに「手続きのために○○円分ポイントを購入してください」という通知になっていく。
このシステムは思いつかなかった。実はガラケーの待ち受け画像サイトやってた時もそうなんだけど、俺は基本的にケチなので「こんなのに金払う奴がいるか？いるわけねーだろ」と思ってしまう。こんなのに引っかかるやつがいるなんて信じられないのでビジネスにしようなんて思いもよらない。引っかかる人っていうのは気の毒に成るくらい頭が気の毒な人なので、「本当に振り込んでいただけるのでしょうか。子供のDSも売ってポイント買いました。振り込まれないともう本当に終わりです。」などと書き込んでいる。胸が痛んだ。このやり方は客を殺すので長続きしない。広告打つにもカネがかかるし、太客をうまく転がしてる方が効率はいいと思う。
Wさんの携帯番号末尾は0001、車のナンバーも・・・１。さすが縁起を重んじる中国人。この番号とるのにいくらかかるんだろうなあ。
