「Oracle」を含む日記 RSS

はてなキーワード: Oracleとは

2017-10-03

anond:20171003200119

SQLServerを試しに使うとき

サンプルとなるmdfファイルってどこかWeb上にありますか、っていう質問でした


Oracleはあるんだけど。。。

2017-09-27

自民でも公明でも共産でも幸福の科学でも北ちょーでもISでも電通でもKADOKAWAでもヨッピーでもxevra(非表示中)でも不倫議員でもOracleでもYoutuberでも職場不倫していた大嫌いな同僚でも首都直下型地震でもAIでも嘘松でも信号無視の黒ワゴンでも誰でもいいからもう全てリセットしてくれ

この地獄から救ってくれるなら、なんでもいい。俺さえ助けてくれるなら何でもいい。どうでもいい事を大変だ、けしからんと騒ぎ立て、それを扇動する俺様は凄いだろう、と言うのはもうたくさん。

巷にあふれかえる自称正義なんてクソ喰らえ。俺には全く関係ない。俺を救ってくれる人だけが俺の正義だ。

こんな生活はもう嫌だ。死にたい。全部ぶっ壊してくれ。

俺だけか?こんなに死にたいのは、俺だけなのか?

2017-05-22

Javaイベントでは、会場の狭さに文句を言うことは許されない

いきさつ

JJUG CCCというイベントで、「会場が狭い」という感想があった

それに対し、イベント関係者から感想に対する不満や、参加者を見下すような発言があった

なので、思うことを書いてみる。

Javaというユーザー層が特殊言語

技術力軽視のSIer的な組織に属する人が圧倒的に多い。

会社技術はいまだにJava5とかで止まってる。

1年の半分以上がデスマーチ

仕事以外にプログラミングをしたり、技術についての情報収集する人が少ない。

PCを家に持たない人もかなりいるのでは?)

彼らの考えるセミナー勉強会

講師が生徒を集めて集合教育を行うイベント

セミナーで話す講師報酬お金)をもらっていて、技術力がない人でも理解できる説明をする。

結論最初に言え。細かい説明とかはいらない。「今一番売れてるフレームワーク」を教えろ)

ここは大きな主催者側とのすれ違いポイントだと思う。

そもそもJJUGJavaOracle関係者と思い込んでる人も少なくない。

特にナイトセミナーの会場でOracleが使われることが多いので、Oracleから金をもらって運営しているという信じている人もいるだろう。

そういう人たちにとって、企業が行うイベントで会場に不満が出ることは落ち度でしかない。

コミュニティ主催イベントというみんなで作り上げるものなのに、ベンダーに招待された「お客様」として参加してしまっているわけである

JJUG側の変化

日本Javaユーザーが一番多い層(SIer関係者)と乖離してきているのでは?

今までは最新のJava SEとか「辛うじて」自分たちでも手の届きそうな話だったのが、マイクロサービスクラウドとか無縁な話が多くなってきている気もする。

「きちんとしたエンタープライズ的なセミナー」を期待している人に対して、コミュニティ活動理解してもらうのは難しい。

Javaエンタープライズ色が強いところも、コミュニティ活動と結びつきにくいのかもしれない。

ただ、それでもコミュニティ理解してない人たちに対して、敵愾心を煽るような発言必要だったのか?

この規模のイベント無料で参加できるようにするための、運営の労力が大変なのは理解できる。

それに対して愚痴りたくなる気持ちはわかる。

ただ、運営側がだれでも見れるSNSつぶやくとかはどうなのか?

打ち上げとか見えないところで愚痴ればよかったのでは?)

参加者は厳しい状況

JJUGイベントでは聞きたいセッションについて悩むというぜいたくはない。

人気あるセッションは埋まるのとにかく早い。

そして、それを知っている常連の行動はもっと早い。

前日までに部屋を決めて置き、目的の部屋の席にさっさと荷物おいてからトイレや買い出しに行くのだ。

ある意味正解だけど・・・なんだかなぁ

まとめ

初めてJJUG CCCに参加した後輩が「聞きたいセッションがいっぱいで残念だった、もうちょっと広い会場でできればいいのに」と言っていたところに、「運営側の苦労も知らないで文句言うな」という意見が流れてきてむしゃくしゃして書いた。

なので、あまりまとまってない。

Javaユーザーも多く、エンプラな人の比率も高めで、コミュニティ理解せず心無いことを言う人や理解すらしようとしない人も多いと思う。

ただ、彼らをディスってもなんの見返りもないし、そもそも彼らの耳には入らない。

それよりも、彼らに向けた発言を見てしまった、無関係な人を傷つけてしま可能性があることを知ってほしかった。

主催者側も参加者側も、新規古参も、みんなで仲良くJavaを楽しめるといいね

2017-05-20

教えて増田Oracle Database DBA Blonze 12c取得したい。

しかPCが糞非力っていうかエロ動画保存しすぎて容量がない。

というか俺の自宅用PCエロ特化型なので仕事ツールとか入れたくない。

エロだけで満たしたい。

そこでクラウドとか使ってOracleDatabase 12cをインストールしたい。

AWSっていうのが正解だろうか。

しか時間経過とともに料金がかかるということで躊躇している。

それともRasberryPiなどのIoT小型PCインストールか、調べたところ難しいようだ。

おススメの学習方法などあったら教えてほしい。

2017-03-01

障害が発生しているアプリケーション名: VirtualBox.exeバージョン: 5.0.20.6931、タイムタンプ: 0x57220aaf

障害が発生しているモジュール名: VirtualBox.exeバージョン: 5.0.20.6931、タイムタンプ: 0x57220aaf

例外コード: 0xc0000005

障害オフセット: 0x000000000001391d

障害が発生しているプロセス ID: 0x2634

障害が発生しているアプリケーションの開始時刻: 0x01d292470799dc6e

障害が発生しているアプリケーション パス: C:\Program Files\Oracle\VirtualBox\VirtualBox.exe

障害が発生しているモジュール パス: C:\Program Files\Oracle\VirtualBox\VirtualBox.exe

レポート ID: 45cdb9f9-d165-457f-971f-aa8b82132bc8

障害が発生しているパッケージの完全な名前:

障害が発生しているパッケージに関連するアプリケーション ID:

2017-02-26

anond:20170225195916

"Google翻訳オープンソースプロジェクトに使うのはダメなのか? " についての反論

いい記事なのだが、いくつか反論や補足が必要だと思ったので書く。

GPLコンパイラの例

このGPLコンパイラとはGNU bisonやGCC(GNU Compiler Collection)について指しているのがほぼ明確なのでそれらについて書く。

確かに著作権法を元にしたライセンスは、ソフトウェアの出力結果に対してソフトウェア著作権ライセンスが影響しないと解釈するのが妥当であるというのは正しい。

ただしこれは"著作権ライセンス"に限った話である、つまり著作権ライセンスでは不可能な制約がEULAなどでは課すことが可能であるということを意味する。

詳しくはGNUの書いた記事の"契約を元にしたライセンス"という項を読むと良い。以下に引用する。

https://www.gnu.org/philosophy/free-sw.html

ほとんどの自由ソフトウェアライセンスは、著作権を元にしています。そして著作権によって課することができる要求には制限があります。もし、著作権を元にしたライセンスが、上記に記した自由尊重するならば、まったく予期しない他の種類の問題があることはありそうもないでしょう(予期しないことはまま起こりますが)。しかし、ある自由ソフトウェアライセンスは、契約を元にするもので、契約もっと広範な制限を課することが可能です。これは、そのようなライセンスが、容認できないほど制限が強く、不自由でありうる、いくつもの形態がありうることを意味します。

わたしたちは、起こりうるすべてのことをあげることはできないでしょう。もし、契約を元としたライセンス利用者を(著作権を元としたライセンスでは無理な形で)異常に制限するならば、そして、それがここで正当だと述べられていないのならば、それについて検討しないといけないでしょうし、そのライセンスは、不自由である結論づけるかもしれません。

また元の記事の著者はGCCやbisonがGNU GPLのような強いコピーレフト保護されたソフトウェアでも、それによって作成された著作物GPLにならない(つまりコンパイラやパーサーのライセンス継承しない)ことを根拠考察しているようだが、実はbisonやGCCGPLにはライセンスに対する例外付属していることを考慮すべきである

GCCやbisonの著作権保持者であるFree Software Foundationは著作権法の話をするとき、たいていアメリカ合衆国を想定しているがこれらの自由ソフトウェアが広く使われるあたって、著作権法とそれを元にしたライセンスが異なった解釈をされることがありうることをおそらく危惧している、そのため出力に対してソフトウェアライセンスが影響しないことを確実にするためにこれらの例外規定しているのではないか

この二つの理由から、元記事議論世界中に対して広く配布するFLOSSディストリビューションでは(非常に残念ながら)鵜呑みに出来ないと私は考える。

フェアユースについて

フェアユース規定は例えば日本では存在しない、

加えて言えば、たとえフェアユース規定が全世界的に利用できて、営利目的でなければ利用できたとしても、

フリーソフトウェア/オープンソース定義の中に

自由.0: どんな目的に対しても、プログラムを望むままに実行する自由

(i.e. オープンソース定義 6項 利用する分野に対する差別禁止)

がある限り、そのような制限ディストリビューションは受け入れられないだろう。

またOracle vs GoogleJavaAPI訴訟はケースとしてはかなり特例であり、

一般に広く適用すればlibcすら当てはまるのではないかと私は思っている、

これを根拠にしてよいのならばそもそもコンピューター業界がひっくりかえるのではないか

Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか

少なくともUbuntuのようなプロジェクトにおいて、私は断固反対である

というのは現状ほぼすべてのWeb翻訳(例外があれば教えて欲しい)はプロプライエタリないし、それと同じ結果をもたらすSaaSSだからである

Webブラウザを介して使う翻訳サービスはSaaSSの代表例であり、ユーザーコンピューター計算コントロール

つべであるという自由ソフトウェア思想と明らかに相容れないものである

このようなサービスを利用することの弊害として、(例えば)Google翻訳翻訳処理の計算依存することにより、ユーザー入力Googleが常に把握することが挙げられます

もちろんこれはあまり良いことではない。

多くのFLOSSシステムディストリビューション自由ソフトウェアを主に入れるというガイドラインを持っている。

アーカイブのごく一部にnon-free(Ubuntuならrestricted/multiverse)なソフトウェアがあるが、

これは事実上妥協産物であり、排除しても大した問題がないならば配布から除外することに多くのディストリビューション関係者異論を挟まないだろう。

また例えばDebianはあるソフトウェアがDFSG(Debian フリーソフトウェアガイドライン)に適合するフリーソフトウェアであったとしても、それがガイドラインに適合しない著作物依存する場合、contribというセクションに閉じ込めており、それは公式システムの一部ではないとしている。(建前ではcontrib/non-freeセクションはユーザー向けの付加サービスとされる)

Ubuntuコミュニティ新規に作られた著作物コミュニティ哲学に反する物に依存するというのは、かなり致命的である

たとえ奇跡が起こり、例外的Google翻訳や一部のプロ翻訳ツールBSDライセンス(Launchpad上での翻訳ライセンス)での出力を許したとしても決して褒められたものではない。

Ubuntubug#1に"Ubuntuソフトウェア自由である。常にそうであったし、今後も常にそうである自由ソフトウェアは万人に望むままの方法で使い、望むままの人間と共有できる自由を与える。この自由は多大な利点である。"とプロジェクト創始者であるマーク・シャトルワースが書いていることをよく考えるべきである

https://bugs.launchpad.net/ubuntu/+bug/1

この反論を読んだ読者の中にはあまりGNUプロジェクト寄りに思想が傾いていると思う者がいるかもしれないが、

いわゆる"Linuxディストリビューション"の中には数多くの重要GNUソフトウェアシステムの根幹をなす形で入り込んでおり(例えばGCC,bash,glibc etc...)

またUbuntu派生元となったDebianの成立経緯にはやはりFSFが関わっている。

さらに言えば、システム保守を手伝う人の中にはシステムフリーからボランティアで頑張っているという人もいると思う。(ほとんどではないかもしれない)

のでUbuntu周りの話に限ってはこういった観点で見てもよいと思ったので書いた。

追記

Ubuntu Japanse Teamの関係者に読まれたようなので満足しました。(2017/2/27 22時)

2017-02-25

Google翻訳オープンソースプロジェクトに使うのはダメなのか?

免責: これは法律専門家によるアドバイスではありません。この情報にしたがって行動した結果に対して責任を負うことはできません。

最近プログラマの間で

Web翻訳の結果をオープンソースソフトウェア(OSS)の翻訳に突っ込んではいけませんという話」

http://blog.goo.ne.jp/ikunya/e/37e5a52e10ab26fcbd4f7ff867e9eace

が、話題になってますね。

Ubuntu翻訳プロジェクトで発生したトラブルの話です。

この話では、「もちろん、利用規約的に問題なければWeb翻訳の結果をOSS翻訳に突っ込んでも*ライセンス的には*問題ありません。」という追記がされてます

ですが、プログラマの間で単にWeb翻訳OSSに使ってはいけないんだという認識が広まってるように見えます個人的には、この認識が広まってしまうのはいやだなと感じたのでこの文を書いています

どういう話かというと、自分個人で開発しているオープンソースソフトウェア(OSS)のドキュメントの日英訳をするにあたってGoogle翻訳を利用するか検討して権利まわりの情報をしらべた結果、これは白に近いグレーだろうという判断したので下訳に使ったという話です。(日英両方についてのドキュメント自体も、オープンソースライセンスで公開しています)

注意書き

念のため言っておきますが、これは元記事問題になっている人を擁護するようなものではありません。翻訳コミュニティの人たちが自分たちのものにグレーなものを入れたくないと思うのは当然でしょうし、権利問題以外にも翻訳クオリティやその他の問題行動の話もあります

コミュニティ思想にそぐわない人が、そのコミュニティの中で作業していくのは難しいでしょう。

Google翻訳利用規約について

もとの記事のとおり、Excite翻訳利用規約には私的利用を超えた利用についての禁止が明記されています。こういった明確に禁止されているものについての話はここではしません。

ここでは、Google翻訳に焦点を当てた話をします。Google翻訳利用規約はどうか?というと、Google利用規約については翻訳結果の利用についての記載がありません。

https://www.google.com/intl/ja/policies/terms/

記載がないということは、使用してよいのか?使用してはいけないのか?いったいどちらなのでしょうか?

GPLコンパイラの例

機械翻訳権利問題と似た構造の話に、GPLGNU一般公衆ライセンス)で許諾されたコンパイラによってコンパイルした結果の利用があります

GPLの本文には、GPLプログラムの出力結果自体GPLのものを含む場合にのみその出力結果にGPL適用されることについての記述がありますが、GPLのものを含まない出力結果についてどういう許諾がされているか記載はありません。

これについては、コンパイラによるコンパイル結果に対して、コンパイラ著作者はなんら権利を持たないと考えるのが一般的です。

GNU自体もそういう見解を持っています

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自体がよく知っている話かもしれません。

Oracle vs GoogleJava API訴訟

これはAndroidAPIJavaAPIが流用されていることについて、OracleGoogle訴訟したものです。

これについて、Java APIについての著作権が認められたものの、Androidでの使用は「フェアユース」に該当するとGoogleは主張し、カリフォルニア州サンフランシスコ地裁では著作権使用料支払いの対象にはならないという判決が下っています

(この裁判自体はまだ続いているようです)

フェアユース」というのは、アメリカ著作権法上の概念で、以下の4要素を判断指針として考えて公正な利用と認められれば、著作権侵害とはしないと考えるものです。

Google翻訳結果のOSSでの利用をこれに当てはめると

ということになり、4つの要素どれをとっても、フェアユースであると認めることに対して有利に働きます。これは、AndroidJava APIの流用と比べても、さらにフェアな利用であるように見えます

さて、ここまではアメリカ法律での話でした。

(ちなみにGoogle利用規約には、「カリフォルニア州抵触法を除き、本規約または本サービスに起因するまたは関連するいかなる紛争に関しても、アメリカ合衆国カリフォルニア州法律適用されます。」と書かれています)

文化庁見解

今度は日本法律に基づく話です。

著作権情報センターサイトに、 コンピュータ創作物についての文化庁報告書記載されています

http://www.cric.or.jp/db/report/h5_11_2/h5_11_2_main.html

この報告書は、機械翻訳ユーザー機械翻訳システム使用するために行う原文の編集や出力の編集創作的寄与となりうることを認めている一方で、機械翻訳開発者翻訳物の著作者になるということについては否定的です。

なお、原文解析等のプログラム作成者及び汎用的な辞書データベース作成者は、一般的翻訳物の作成の精度、正確度等を高めることに寄与することとなるが、特定翻訳物の作成自体にかかわっているわけではないので、その著作者とはなり得ないと考えられる。

これは平成5年とかなり昔に書かれた報告書であり、それから機械翻訳技術は大幅に進歩しましたが、創造個性表現を目指して作られているもので無い機械翻訳であれば、やはり翻訳の結果の利用について問題がないようにみえます

これにしたがえば、単純に文章をそのまま機械翻訳に投げ入れた出力結果は、原文の著作者著作物機械翻訳に投げ入れる前や後に十分な編集をしていれば、加えてその編集した人間二次著作物になるということになりそうです。

白に近いグレー

これまで、どうしてGoogle翻訳の結果をOSSに使うことが白に近いと言っているか説明してきました。

では、どうしてグレーなのかというと、新しい種類の権利問題なので判例がないからです。実際に訴えられたら負けました、ということもまったくありえない話ではないでしょう。

グレーなものを作ることの良し悪し

だいたい、ここまでが話したいことの半分です。ここからはグレーなものの良し悪しの話をします。

著作権などの権利問題についてグレーなことをやっているOSSというのはそれほど珍しいわけではありません。

有名なところでいうと、Monoが思いつきますAndroidDalvikJavaAPIを真似したものであるのと同じように、MonoMicrosoft.NETフレームワークを真似しています。つまりMonoについても訴訟リスクはあっただろうということです。

しかし、OracleGoogle対立したのとは対照的な道をMonoはたどります

2016年Monoプロジェクト運営していたXamarin社は、そのMicrosoft自身によって買収されました。権利的にグレーだったMonoMicrosoft公認プロジェクトになったというわけです。

権利的にグレーだからといって、プロジェクトとして失敗に終わるわけではありません。

Ubuntu日本語化プロジェクトでの良し悪し

すこし元の記事に話をもどします。冒頭にも書いた通り、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というのはほとんどありません。多くのOSSは、作者が飽きたり、面倒な作業うんざりしたり、誰にも使われなかったり、競合に勝てなかったりしたことで、フェードアウトしていきます

そういったこともまた、OSSリスクなわけです。

結局のところ、自分場合Google翻訳をつかったところで、Googleにも、自分にも、ユーザーにも、世間にも不利益はなく、むしろドキュメントの質は上がって、Google翻訳改善するためのデータを得られます

わずかなリスクを避けるために、時間を割いた上、質を落とすというのはくだらないですし、そんなことに時間を使うくらいならコードを書いていたいものです。

Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか

結局、Web翻訳の結果をオープンソースソフトウェアで使うべきか、そうではないか?というのは個別の話でしかなく、ひとまとめにWeb翻訳の結果をオープンソースソフトウェア翻訳にいれてはいけないとか、使うべきとかそう簡単には言えません。

質が悪いしリスクがあるのであれば単純に禁止で済む話ですが、機械翻訳が向上して、質が良いがリスクのある例が増えると話はさらにややこしくなります

OSS翻訳者コミュニティ機械翻訳の利用についてそのプロジェクトで使って良いか方針を定めてやっていくしかなく、後からコミュニティに入っていくような人が機械翻訳を使いたい場合コミュニティ方針確認した上でやっていくしかないんだろうなあと思うところです。

2017-02-03

ファミマの窓からORACLEが見える

彼ら今なにしてんの?

データベース商法続けてるの?

そういやあのデータベース商法って類例があまりないよな

2016-12-19

Oracle案件に当たりなし説

もちろんスペシャリストがきちんとわかった上でOracleを使ってる案件大丈夫なんだろうが、中小規模案件Oracle使ってるのにろくなのがない。

Oracle案件ありがちなこと。

データベースは当然のごとく正規化されてない。昔はされていたのかもしれない。

使用されていない予約されたカラムの山。必須でない情報でもカラムを作るのでテーブルがどんどん肥大化していく。

業務必要リレーション崩壊している。

・謎のインデックスが大量にあるが、パフォーマンス上本当に必要インデックスはない。

・ストアドプロシージャが秘伝のタレ化。そのせいでOracleから抜けられない。

Oracleを使うとDB設計者の脳は破壊されるのだろうか。脳が破壊されているかOracleを使うのだろうか。

開発環境準備するのも面倒だしインターフェースダサいし、もうOracleが絡む案件やりたくない。

2016-11-28

SIerランク

ランク 企業

A+ OracleCiscoNTTデータSAP

A 日立製作所富士通

A- 日本IBMNTTコミュニケーションズアクセンチュア野村総研(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兼松エレクトロニクス都築電気

日興システムソリューションズ、キャノンITソリューション

D 損保ジャパン日本興亜システムズ、インフォコムセゾン情報システムズ日商エレクトロニクス

コベルコシステムIIJネットワンシステムズパナソニックインフォメーションシステムズ、

菱化システムJRシステム富士通システムイースト東芝ソリューション富士通FIP

D- ユニアデックスNECネッツエスアイ日立産業制御ソリューションズ、

三菱電機インフォメーションシステムズMS&ADシステムズ、NTTソフトウェア

NTTアドバンステクノロジ、JFEシステムズ、テクマトリックス三井情報第一生命情報システム

ソニーグローバルソリューションズ、ワークスアプリケーションズ

E+ 富士通システムウエスト富士通マーケティング三菱電機インフォメーションネットワーク

中央コンピュータシステムティージー情報ネットワークリンクレアジャストシステム

E NECフィールディングNEC情報システムズ富士通BSC日本情報通信

住友電工システムソリューションJR西日本ITソリューションズ、

インテック明治安田システムテクノロジー

E- 富士通ネットワークソリューションズ、日立公共システムNEC通信システム

スミセイ情報システム丸紅情報システムズ双日システムズ

京セラコミュニケーションシステムsky

F+ 日立ソリューションズクリエイトキヤノンソフトウェアさくら情報システム

トヨタコミュニケーションシステムエクサアイネスTKCCACCEC、SRA

F クオリカNSDDTSさくらKCS東邦システムサイエンス、菱友システムズ、

ヤマトシステム開発CTCシステムマネジメント

G 大塚商会富士ソフト、コア、アルファシステムズ

H トランスコスモス旭情報サービス、ジャステックシステナ、Minoriソリューションズ、

東京コンピュータサービス

2016-10-20

俺の年収査定して欲しい

中小SIer 客先常駐インフラエンジニア

26歳3年目 転職を考えてる。

持ってる資格

Linux (LPIC Level 1,2,3)

Oracle Bronze,Silver

基本情報技術者

セキュリティスペシャリスト

統計検定2級

大規模構築経験あり

OSUNIX/Linux系は割と扱える

仮想基盤やAWS,Azureパブリッククラウドの構築経験あり

Ansible,Chefを用いて自動構築できる

ドルは、bind,sendmail,samba,nginx,Apache,Zabbix,LDAPとか

コードはshellとpythonが少々。



麻雀(天鳳)が趣味で、牌譜の解析とかやりたかたか統計勉強して、資格チャレンジしてみた。ついでにpython数学も。どちらも業務で使うことはほぼない。

趣味Webメディア作ってたから、Wordpressサイト作るくらいなら一晩で出来る程度の能力


いまこれで年収300万くらい。安い?普通

このスキル感に年収合ってる?

増田の皆さんに査定して欲しい。

あと転職するならデータサイエンスセキュリティに興味あるのでそっち方面に行こうと思ってる。

オススメ戦略を教えてください。

2016-07-09

最近セールスフォースってつまらない

マークベニオフOracleラリーキーノートで互いに「ニセモノに気をつけろ!」とやりあい

日本のウダ社長が twtter で dis ってくるコモノの相手をイチイチしてあげて、

マーケ上条さんが競合を口汚く罵っていた、

あのころにはもう戻れないの

2016-07-04

それでも(これ以上の)金融緩和に反対する理由

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%を使えるかは,金融経済の中で,専用通貨オークションでもやって決めればよい。まあでもこれは残念ながら実現不可能だろう。

終わりに

というわけで,今以上に金融緩和をしても無意味なんじゃないかな,と思ってる。

ところで,なぜ財政政策のところが「再分配(例:富裕層への課税強化&低所得層への扶助)」じゃなくて「財政出動」なんだろう?

いや,財政出動でもいいんだが,富裕層への課税強化を同時にやっちゃダメなの?

2016-06-17

1.0から学ぶJava

タイトルを見て釣られクマーな皆さんこんにちは

ホッテントリメーカーで作るような煽りタイトルって、みなさんもう見飽きてると思うんですよね。

今調べたらホッテントリメーカー2008年だそうで。どうりでねー。古臭いなーと思いましたよー。

「一から学ぶJava」ってのをね、1.0にするだけでこんなに素敵なタイトルになるんだから面白いですねー。

タイトルを思いついただけだったんですけど、思いついたらやっぱりちゃんと中身も書かないと行けないじゃないですか。やだー

面倒くさいんですけどね。ちょっと1.0から学んでみましょうか。

Java 1.0 1996年1月23日

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を腐す要素として挙げられてしまうのでした。

Java 1.1 1997年2月19日

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は今とはデザインが大きく異なります。

  • java.applet
  • java.awt
  • java.awt.datatransfer
  • java.awt.event
  • java.awt.image
  • java.beans
  • java.io
  • java.lang
  • java.lang.reflect
  • java.math
  • java.net
  • java.rmi
  • java.rmi.dgc
  • java.rmi.registry
  • java.rmi.server
  • java.security
  • java.security.acl
  • java.security.interfaces
  • java.sql
  • java.text
  • java.util
  • java.util.zip

この時代であれば、全パッケージを舐めて標準APIを学ぶこともそう難しくはありませんでした。この時代から触っている人間は新バージョンが出るたびに増えるAPIを順に学んでいけたのです。しかし、現代にJavaを学ぶ場合、どのバージョンでは何があって……というのをいちいち学ぶ必要はほぼありません。Java5以前は一緒くたでいいと思いますし、一部のAPIで歴史的経緯があってねーというのを知っていればおそらく十分ではないでしょうか。

Java 1.2 1998年12月8日

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は使うべきではありません。

Microsoft 離反

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 EE

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のシステム開発がなかなか成功しないってのもあったんでしょうけどね。

iアプリ Javaアプリ EZアプリ

2000年あたりというと携帯電話の普及も取り上げなければなりません。現代のスマホガラケーに比べれば非常に機能は貧弱で、まさに携帯「電話」でした。要するに電話とメールぐらいしかできなかったんですね。

そこにdocomoiアプリJフォン(ボーダフォンを経て現ソフトバンク)のJavaアプリ、auのEZアプリという携帯電話上でちょっとしたアプリが動くよ!というのが乗るようになってきたんです。これがJavaを組込み用途にコンパクトにしたJava MEというものが土台となっていて(正確にはiアプリちょっと違う)Servletと並ぶJava言語の大きなもうひとつの領域となっていました。

iアプリは当初は容量が10k byteまでといった制約があり、容量制限が非常に厳しかったのですが、新機種が出るたびに容量は緩和されていきました。

docomoiアプリ含めiモードによって一世を風靡します。こうした土台を作ると、その上で商売をしたい人がたくさんやってきて、勝手にコンテンツを作ってくれる。docomoはそれらから手数料を取るので労せずして大金を稼げるというわけです。賭場の胴元というわけです。

この賭場が、将来にAppleiPhone, GoogleAndroidに荒らされることになります。docomoがなかなかiPhoneを出さなかったのもiモードという自前の賭場を失うことを良しとしなかったためです。金づるを失ったdocomoSamsungと組んで独自の携帯向けOSであるTizenの開発に乗り出します。そんなTizenですが鳴かず飛ばず。噂ではインドあたりではリリースされたとか、なんとか。

RIA時代

話を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の思想といいますか、要求というのは今でも息づいているのだなと思った次第です。

Java 5 (2004年9月30日)

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を学べばゴールというわけではありません。プログラム言語次世代へと移りつつあります。業界動向には注視していきましょう。

2016-06-08

ただの出会えない系サイトだと思ったら大間違いなんだからね!

 下手なスパムも数撃ちゃ当たる

 ある日、たまにお世話になってるBさんからシステム構築の相談を受けた。知り合いの使ってるシステム拡張できなくて困っている、知人に会わせるから詳しく聞いて欲しい、という事だった。このお客さんというのは過去ツーショットダイアルでしこたま儲けたらしく、金は持ってるという話だった。そういえば前に、自社でやってる出会い系サイトが重くてしょうがないんだけど助けて欲しいって相談を受けた事がある。第一世代iMacで構築してたらしく、ちょっとカブれたシステム会社にあたっちゃったんだなと思ってた。その時はまとまった時間が取れなくて手伝えなかったんだ。俺はMacは好きだけど、当時仕事ではIAサーバーSAN繋いでOracleDB構築とかしてたので、Mac+FileMakerWebアプリ作ってるって聞いてひっくり返った覚えがある。

 K県にあるオフィスへいった。担当者Hさんとはすぐ話が出来たが、オーナーのWさんは渋滞に巻き込まれて1時間ほど遅れて来た。Bさんからは「見た目は思いっきヤクザだけどいい人だから」と言われていたけど、サングラスでもかけて無い限り普通に人の良さそうな叔父さんだった。日本語は上手。アクセント中国訛りだけど、システムのことがよくわからないHさんよりよっぽど話が通じる。

 内容は「コミュニティサイト」、つまり出会い系サイト」だと言う。会員数は1万人。有料サイトで1万人はかなり凄いはず。ガラケーの待ち受け画像サイトとか手伝ってた時には、内部関係者とか無理矢理登録させて盛りに盛って5千人も行けばいい方だった。思わず口に出た「え?1万人ですか!?凄いですね」 。WさんとHさんは何故か目を合わせて苦笑いしてる。ハードウェア構成は1万人にしてはちょっとショボイかなと思ったけど、hpのDL380とMSA500の構成を打診してみた。一式200万〜くらいだけど向こうにひっくり返られて、今は数万円の自作PCでやってるって事だった。まあハードで儲ける気はないからいいけど。

 出会い系システム構築し始めて、一番話が噛み合わなかったのが会員インポート機能だ。現行システムからの移行に使うという。そんな一回しか使わない機能、手動でコンバートするからこの機能外させてくれって何度も言ったんだがどうもこの機能にこだわる。むしろこの機能キモだとまで言う。あ、だんだんわかってきたぞ。

 こいつは有料会員が1万人もいるような優良サイトではなくて、名簿屋から買った会員情報を流しこんで会員数万人に仕立てあげるシステムだ!。俺は金に成るならマルチ管理システムでもなんでも作ったるわと思ってたからやるけど。現行サイト女性会員として登録しても男性会員から検索できない。これは客がテストのために女性として登録してクレームをつけてくることがあるから検索できるようにして欲しいと言われた。出会えなかったら客が残らないんじゃないですか?って聞いたら、あまり出会わせないんだと。実会員同士が連絡を取っちゃったら直メールでやりとりしてポイント消費しないから、出会えないのがいいんだと。なるほど、ワルだね!

 程なくして(すったもんだあったけど)システムが完成して、同一システムで見た目だけ変えたものをいくつか作らされた。有料出会いサイト無料の客寄せサイト、そもそも出会いとして機能してないDM送信サイトがあった。有料出会いサイトの売上は、うまくいってるサイトでも月間数十万程度なんだが、1サイトだけずば抜けて売上の高いサイトがあった。毎月コンスタントに500-600万は売り上げて、多い時は1000万を軽く超える。こんなことなら売上のパーセンテージ保守料貰えばよかったなあ。

 一体どうしてこのサイトだけこんなに売上があるのかと、ちょっとサイトメールやりとりを覗き見して青ざめた。こいつらもう出会いなんて全然エサにしてない、初めからあなたに1000万円当たりました。振込の手続きをするので合言葉'XXXX'を送信してください」などと言ってポイントを消費させてるだけだった。この頃はまだ男性けが圧倒多数だった気がする。後に女性向けにジャニーズを騙ったり、占いサイトと称して幸福成るための合言葉を連投させたり、そのうちエスカレートして金の単位は億になり、あからさまに「手続きのために○○円分ポイントを購入してください」という通知になっていく。

 このシステムは思いつかなかった。実はガラケーの待ち受け画像サイトやってた時もそうなんだけど、俺は基本的ケチなので「こんなのに金払う奴がいるか?いるわけねーだろ」と思ってしまう。こんなのに引っかかるやつがいるなんて信じられないのでビジネスにしようなんて思いもよらない。引っかかる人っていうのは気の毒に成るくらい頭が気の毒な人なので、「本当に振り込んでいただけるのでしょうか。子供DSも売ってポイント買いました。振り込まれないともう本当に終わりです。」などと書き込んでいる。胸が痛んだ。このやり方は客を殺すので長続きしない。広告打つにもカネがかかるし、太客をうまく転がしてる方が効率はいいと思う。

 Wさんの携帯番号末尾は0001、車のナンバー・・・1。さすが縁起を重んじる中国人。この番号とるのにいくらかかるんだろうなあ。

 仕事溜まってるとついつい逃げてしまってこんな1円にもならないテキストを書いている。俺、ダメ人間

2016-04-26

OAuthのことを1ミリも知らない俺が

OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324

http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html

OAuth がうまくいかない理由と、既存サービスゼロデイ攻撃方法

OAuth とは

認証 (authentication: 本人確認) と承認 (authorization: 権限付与) のシステムを設計し、API を規定し、複数の異なるシステムを統合するために用いられる提案をまとめたものです。

OAuth には色々な種類があり、version 1.1a や 2、その各部の上に他の規格を乗せたものなどが存在します。世の中に出回っている数々の実装によって、具体的な利用状況は大きく異なります。

おことわり

前にも OAuth について書いたことがあり、たくさんの反響をいただきました。前回の記事に対する批判の一部を避けるため、今回の記事について先に断っておきたいのですが、この記事は OAuth の使われる典型的な場面に焦点を当てており、論じられる点のほとんどは、何らかの方法OAuth を利用する大手サービスのほとんどすべてに当てはまるということです。

言いかえると、OAuth を用いているあらゆるプラットフォームが壊れているとは限りません。OAuth にはバリエーションが多いうえに、2.0 だけに限っても 76 ページに渡るパターンがありますので、OAuth に基づいた何かに適合していながらもセキュアであり、使っても問題ないものは存在しうると言えます。ですから、あなたお気に入りOAuth 実装や設計が、ここで論じられる問題の一部または全部を免れていることもありえます。確率は低いですが。

また、OAuth を使っているものの中には規格を誤用しているものがあるとか、OAuth はその使い方を強制しているわけではないとか言う人もいるかもしれません。どちらにせよ、ここでは特定の OAuth ベースの規格について述べるのではなく、現状で大手が OAuth をどう利用しているかについてを、それが規格に適っているかどうかに関わりなく論じるつもりです。こうすることで、多くの読者に影響を与えることになるでしょう。危険な方法OAuth を使っているサービス利用者であっても、また自ら OAuth ベースサービスを管理していて、他のみんなが作っているのを真似てプラットフォームを作ろうと思っている人だとしても関係があるのです。

記事の構成

この記事は長くなりますし、言ってみればほとんどの章はそれ自体でひとつの記事として十分なほどの話題を扱いますので、大まかな流れをご説明しておきましょう。

この記事は、現在 OAuth 業界でおこなわれていることを調査した結果のまとめです。OAuth を使う製品のすべてにこの記事のあらゆる点が当てはまるというのではなく、危険だったり無価値だったりするサービスの背後に見つかった慣例や根本原因を紹介する記事です。

この前書きのあとは、まず OAuthセキュリティ欠陥を分析することから始めるつもりです。こうした欠陥の中には、セキュリティコミュニティでよく知られていて、書籍などですでに分析されている一般原則が当てはまるものもあります。しかしこの記事では書籍化されていないケースも扱いますし、有名な欠陥についても、平均的な開発者および責任者に理解しやすく、対策の必要性がはっきりするように工夫するつもりです。

その後は、OAuth の主要素が一般的に言ってどのように実装されており、そうした普通の実装がどのようにサービスを使いものにならなくするのか、すなわちそのサービスで達成できることを極度に、不適切に、かつ意図に反して低下させてしまうのかを分析します。ごく一部のケースでは回避策の足がかりになるかもしれないテクニックについて論じますが、そういうのを実装する馬鹿らしさにも注目します。こうした記述の中では繰り返し何度も、OAuth を使う人たちがどれほど自分と自分のビジネスにとって損なことをしているのかが説明されます。

最後に、OAuth が適切に使われうる数少ない場面と、すでに利用されている OAuth の代替品を簡単に取り上げます。代替技術に関する調査の結果を提供するつもりですが、その中には Amazon のような大企業がセキュアで使いやすく信頼性の高い API を実現するために何をしているかの報告も含まれるでしょう。

責任ある情報公開

いま普通に使われているかたちにおける OAuth の欠陥の幾つかを悪用すれば、大手サービスに対して強力な攻撃を仕掛けることができます。OAuth に対する攻撃は何も新しいものではありません。IBM や Oracle を含め、懸念した IETF メンバーOAuth ベースサービスに対する攻撃を 50 クラスも記述した 71 ページもの文書を 3 年以上前に出したように、また筆者も前回の記事でこうした点のいくつかを議論したようにです。それにも関わらず、OAuth ベースシステムの主要なセキュリティ欠陥は非常に蔓延しています。

筆者は、いくつかの大手企業の役員や開発者に、そこの OAuth ベースシステムが抱えるセキュリティ欠陥を指摘したことがあります (そのうちのひとつは 4 年前のことです) が、全員、自社システムを修正するために一切何もしませんでした。まるで、OAuth の人気度からして、他の現実的な解決策をひとつも聞いたことがなく、それゆえに OAuth が最もセキュアな選択肢に違いないと決めてかかっているようです。どうも、OAuth のコア原則に対する攻撃のデモを文書化した情報も、聞いたことがないか、肩をすくめて無視するかしているようです。そこで、この情報をもっと広く拡散することによって、影響のある人たちの尻を蹴りとばしてあげたい、そしてサービスを設計あるいは管理している人たちにモーニングコールの役割を果たしてあげたいと願っています。

というわけで、OAuth ベースの何かを提供あるいは利用するご自分のサービスを調べて、こうした欠陥の一部あるいは全部が存在することに気づいたなら、どうぞ責任をもってこの情報を取り扱ってください。ご自分のサービスを適切にアップデートしたり、関係する問題に対応するようビジネスパートナーに適切な圧力をかけたりしてください。

ここで言及されている情報やリンクされている情報は今のところ既存のサービス悪用できるかもしれませんが、どうぞ責任ある行動をとり、他人のもの破壊するのではなく改善することを目指してください。この記事は、自社サービス不適切に実装している人たちへのモーニングコールのつもりで、その改善を促すために書いているのであり、悪用したがっているハッカーたちのハウツーもののつもりではないのです。

想定する利用形態

この記事では、ふたつのシナリオに注目して、その場面でどのように OAuth が組み合わされているのか、そしてなぜうまくいかないのかを検討します。記事を通して何度もこれらのシナリオに戻ってきますので、頭に入れておくことは大事です。

まず、Exciting Video Service (略して EVS) というサービスを思い描いてみましょう。ユーザが動画をアップロードしたり友人と共有したりできて、完全公開にしたりアクセス制限を設定したりできるようになっています。また EVS は動画のアップロードや削除、およびだれが視聴できるかの権限管理に OAuth ベースの API を提供しています。

ただ、例としてこの想像上のサービスに焦点をあてますが、論じられる問題はあらゆるサービスにも当てはまります。ファイルであろうと文書ストレージであろうと、カレンダー管理やオンライン会議、ディスカッショングループ、はたまたリソース管理であろうと OAuth ベース API を提供する他のいかなるものであろうとです。また、筆者は本当にどの特定の動画サービスのことも言っていないということを覚えておいてください。問題点の一部あるいは全部は、OAuth を使っている既存の動画サービスに当てはまるかもしれませんが、EVS がそのサービスのことを指すわけではありません。どれが当てはまるかは読者への練習問題ということにしてもいいですね。

ひとつめのシナリオとして、ビデオカメラの製造会社を想定しましょう。そのビデオカメラには、録画した内容を EVS にアップロードする機能のあるソフトウェアを付属させたいと思っています。つまり、ユーザビデオカメラを自分のコンピュータに接続して、その独自ソフトウェアを開き、ビデオカメラからアップロードしたい動画を選んでしばらくすると、それが EVS にアップロードされているというものです。

ふたつめのシナリオとしては、ある中小企業が職員用に EVS で 50 アカウントを購入し、全職員が動画をアップロードして同じ部門の職員と共有できるようにする、ということにしましょう。この会社は A Friendly Custom Platform (AFCP) というソフトウェアで職員と所属部門の管理をしており、この AFCP サービスを EVS に統合したいと考えています。望んでいるのは、管理者が AFCP を使ってだれかを営業部門に配置したら、その職員が自動的営業部門メンバー所有の動画すべてに対するアクセス権を取得するということです。営業部門からいなくなった人には逆のことが起こるようにもしてほしいと思うはずです。

問題点

セキュリティ関連
認証情報の盗難 / アクセス権の詐称

トークンベースの認証システム (OAuth のコア) が現在よく利用されている最大の理由のひとつには、「適切に実装されれば」サードパーティアプリサービスに各ユーザの認証情報 (パスワード等) を提供しなくて済むという点があります。サードパーティに個人ユーザの認証情報を渡すのは、以下の理由から望ましくありません:

上記の問題点は、OAuth だけでなくあらゆるトークンベースの認証システムでも回避できます。よく OAuth の強みとして挙げられていますが、独自というわけでは全然なくて、他にも同じ強みを実現しつつ OAuth の弱点のない選択肢はあるのです。

さて、確固とした土台に基づいてはいるものの、「普通の実装における」OAuth は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:

  1. ユーザサードパーティアプリ/サービス (たとえば AFCP) を訪ねて、特定のサービスと統合したいことを知らせる。
  2. AFCP は、EVS でホスティングされた特別なログインページを出してユーザに EVS の認証情報を入力させる。
  3. EVS は、その指定したアクセスレベルユーザが本当にサードパーティ (AFCP) へ与えたいのか確認する。
  4. EVS は AFCP に一種のトークン (複数の場合もある) を提供し、各種 API コールに使えるようにする。

このトークンユーザの認証情報ではありませんから、そしてひとりのユーザひとつアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。

この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。

(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)

(略: そうした詐欺を企業自体が後押ししているような風潮もある)

(略: スタンドアロンアプリなら、ログインを詐称する必要すらない)

この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザ組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は?

クライアントアプリユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。OAuth は悪意あるアプリに対していかなる防御策も提供していないので、エンドユーザインストールするネイティブアプリすべての信頼性に自分で責任を負う。

さらに

クライアント開発者は、ユーザから直接に認証情報を集めるようなクライアントアプリを書くべきではなく、システムブラウザのような信用できるシステムコンポーネントにこの役目を移譲すべきだ。

基本的に言って、OAuthセキュリティガイドラインは、OAuth を利用する開発者ユーザを攻撃しようとすべきではないとか、悪いことをしてはならないと言っています。外部の開発者が悪いことをしないことに頼るというのは、正気のサービス設計者が依拠するセキュリティモデルではありません。

私の知る主要な OAuth ベースサービスはほぼすべて、ここに概説した手法で攻撃可能です。

OAuth こそセキュリティの新たな金字塔だとお考えの皆さん、目を覚ましてください! 「普通の実装における」OAuth は、始まる前から負けていますよ。OAuth が存在するよりずっと前に実装された数多くのシステムはセキュアで、この問題を効率的に回避しています。残念なことに、あまりに多くのサービスが、せっかくセキュアだったのにインセキュアな OAuth モデルに移行してきました。だれかが開発者管理者に「OAuthもっとセキュア」「先取り思考」「将来への投資」とか何とか素敵な (しかし具体性の皆無な) バズワードを並べたてたからでしょう。ほとんどの場合、こうした変更は本当に既存の問題に対応しているのか、あるいは以前のシステムより幾らかでも良くしてくれるのかどうかをレビューすることさえなく実装されています。

OAuth サービスに偽装

OAuth ベースサービス設計でよく見かける間違いは、ブラウザ用に、パラメータひとつとして client_secret (あるいは同様のもの) を受け取るエンドポイントを提供することです。OAuth の client_id と client_secret パラメータは、基本的に言ってサードパーティプラットフォーム固有の API ユーザ名とパスワードと等価ですから、EVS の API を利用する開発者だけにしか知られるべきではありません。パスワード同然のものなのですから、client_secret パラメータは「絶対に」ユーザブラウザを通して送信すべきではありません (ヒント: パラメータ名の中に secret という言葉が入っているよ)。アプリサービスユーザがその client_id と client_secret を見つけることができる場合、そのユーザはそのサービスのふりをすることができ、潜在的には何かイケナイことができてしまうということになります。さらに注意すべき点として、client_secret パラメータを別の名前にするサービスもありますから、ご自分の関係するサービスをよくチェックして、他のパラメータも秘密にする必要があるのかどうかを調べてください。残念ながら、重要な変数が自分の素性をいつも表に出しているとは限らないため、この問題は意外と多く存在しています。加えて、client_id だけ使う認証フローOAuth の上に乗せるサービスも出てくるでしょう。これには用心してください。特定の状況では、そういう client_id はまさしく client_secret 同然の働きをするのですから。

「普通の実装における」OAuth は、ウェブブラウザを使ってユーザを複数のウェブサイトに移動させるわけで、ひとつサイトから別のサイトに client_id と client_secret (あるいは同様のもの) を送ってもらう必要があります。そうやって、たとえば AFCP と EVS の間でこれらをやりとりするわけですから、ユーザブラウザの HTTP ログをモニタリングすれば、本当に見えてしまいます。これはアプリに組み込まれた独自ブラウザ各種でも、単に右クリックすれば何らかのネットワーク・ログ機能を持つ何らかの inspector にアクセスできてしまう場合などには可能です。

EVS と連携した AFCP にこの欠陥があると、AFCP に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に FacebookGMail 用の OAuth エンドポイントを利用しているとして、client_id と client_secret の両方がブラウザを通して送信される場合、Facebookユーザは全員 GMail に対して Facebookのもののふりをすることができてしまうということです。

この問題は、OAuth エンドポイントユーザウェブブラウザから平文で client_secret を送ってくることを期待するときにはいつも存在します。あるいはそうする必要があると誤解した API 利用者が、埋め込むべきでないところに secret を埋め込むときもです。この脆弱性が存在している可能性が高いのは、エンドポイントが client_secret (または同等品) と redirect_uri の両方を期待する (あるいはオプションとしてでも受け付ける) 場合です。redirect_uri パラメータは、今回のケースで言うと EVS がユーザログインさせたあとでそのブラウザをどこに送るべきか指示するために使うよう設計されています。そうやって redirect_uri がエンドポイントへの転送に使われている場合、その処理はユーザブラウザで実行されることが期待されているわけです。主要な OAuth 文書はどちらも、client_secret と redirect_uri の両方をこうした用途に使うようなケースを指示したり求めたりはしていません。

ざっと検索してみたところ、残念なことに、潜在的に違反の可能性があるそういった OAuth ベース API がたくさん見つかります。GoogleOAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローひとつあります:

client_secret: 開発者コンソールで取得したクライアントパスワード (Android, iOS, Chrome アプリとして登録した場合のオプション)

Citrix もこんな間違いをしています:

(略: 以下、実際に脆弱だと確認したわけではないが、secret と redirect を併記しているサイトが列挙されている。)

Google で 2 分検索しただけでこのリストができました。皆様がもうちょっと労力をかければ、ずっと多く見つかることでしょう。ただし、上記リストは、こうしたサービスのどれかが脆弱だとか、誤用しやすすぎるということを直接に示すものではありません。色々な要素があり、たとえば Zendesk は特にこのケースでは redirect_uri パラメータリダイレクトに使わないと明言していますし、アプリからエンドポイントを呼ぶときはフル機能版ブラウザではなく curl を使うべきだとさえ書いて、開発者が危険なことをするような誤解を極力避けようとしています。それでも、経験の浅い開発者はこうしたエンドポイントを独自ブラウザで読もうとするかもしれません。さらに、この組み合わせが世に出回っているというだけで開発者の警戒心が下がっていき、経験を積んだ OAuth ベースサービス開発者でさえも似たような状況で潜在的ヤバイ誤用を気にせず適用するようになってきています。特に client_secret が別の名前になって、「秘密を守る」という概念が失われている場合はそうです。

サービスがこの点に関して壊れている指標となるのは、人気のある複数の OAuth ライブラリがこのサービスでうまく動かないときです。そういうサービス一般的にいって独自の「SDK」を提供しており、サードパーティ開発者が選んだライブラリではこのフランケンシュタイン的な OAuth が使えないと苦情が来たときにはその SDK を使うよう指示します。こうしたカスタマイズは気付かれないまま進行することも多くあります。開発者の大多数は、SDK が提供されているなら、わざわざ手元のソフトで頑張らずに済ませたいと思うものですから。

この種の攻撃は前述のセキュリティ文書で「4.1.1. クライアント機密情報を取得する脅威」に分類されています。しかしサーバウェブブラウザを使用を要求し client_id と client_secret (または似た用途のもの) を同時に渡させるという具体的な攻撃パターンには一言も言及がありません。おそらく、その文書の執筆陣の予想では、こんな馬鹿げたサービスはだれも設計しないだろうし、その API を使う開発者もそれを独自のウェブブラウザや SDK で使ったりはしないだろうと思っていたのでしょう。こうした開発者OAuth の規格からバラバラに取り出した要素をグチャグチャに混ぜて接着しておいて、自分のプラットフォームOAuth 本来のセキュリティを保持していると思っています。そのツギハギのせいでどんな新しい問題が入り込むかもしれないのに、そこは一顧だにしません。残念ながら、これが近年の OAuth 業界によくあるやり方で、この既に猛威をふるっている問題は、パレード参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。

おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。GoogleOAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントウェブブラウザベースアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフロー標準的ブラウザ用のエンドポイントコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。

前掲のセキュリティ文書は、 このエントリーをはてなブックマークに追加ツイートシェア

2016-04-09

Javadisられまくってるけど

というかOracledisられてると言った方が正しいのかもしれないけど、Scalaとかは今後どうなるんでしょうね

オワコンなんですかね

2016-01-25

理系()のやつらは何してるの?

http://blog.livedoor.jp/itsoku/archives/47616816.html

とそのブックマーク

http://b.hatena.ne.jp/entry/blog.livedoor.jp/itsoku/archives/47616816.html

をみながら思ったんだ

要約するとアメリカは時給12万円のコーダー仕事があるらしい

そんでとうぜんにほんじゃそんなことないという流れで

日本ハードばっかりにこだわってソフト軽視だという(まぁそうだろうね私もそういう印象あるよ)

まぁここまではいいんだけど

なぜか、このスレの連中(名前からしてビジネス+)は、文系のせいにしたり大企業のせいにしたりする

このまとめをまるまる信じるとして思うことがある

一瞬なるほどそうなんですかって話になりかけたが

べつにアメリカだって、かつてのGEやらIBMなんか

そしてHPDELLなどのハードにこだわっていろいろ大変なことになってる会社もあるわけだが

なにが言いたいかって、べつにアメリカもその点では変わらないじゃんってことだよ

じゃあなにが違うのかって


理系ベンチャー立てて、googleみたいな企業立ち上げられるかどうかだよね

それだけの話だよね

そこだけが違う

理系()ベンチャーgoogleとかほかのIT企業立ち上げたら話は終わるんだよ。amazonでもいいしoracleでもいいし、あとなにがある?あんましらないけどねw

uberとかあるじゃん

もちろんそれが一番難しくてできないから理系()ルサンチマン馬鹿どもは文系のせいにしたり、企業のせいにしたりしてるんだろうけどw

アメリカだって恐竜って言われてるGEとかIBMみたいな旧態然とした、大企業ってのもありつつベンチャーITが盛り上がってるわけだから

アメリカ人GEとかIBMのせいにしてるわけじゃないでしょ(まぁそもそもGEIBM利益率かなりいい優良会社だけどね)

はいえ、いまはもうソフト軽視なんてされてないと思うよ

IoTとか展示会みにいったときあほほどきかされたし

ようするに能力のないバカ2chで騒いでるんだろうってことが言いたいんだけど

じゃあなんでこんなのかいたかって

この2chまとめみたいにルサンチマンやってるダサい連中じゃなくもっとまっとうな理由ってないのかなって思ったわけですよ

日本にはこういう問題があるんだってのがあるんだったら教えてほしいとおもってね

そもそもなんでこの手の奴らって文系理系でわけるのかね。もっというと理系側がわけたがってるよね。お望み通り理系でわけてやったんだから理系の皆さん返信よろしく

就活の参考にしたい

2016-01-23

SIはやめておけ

20代の数年間SIで働いた。1年以上前退職して今は別業界にいる。

今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくり暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。

一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。

以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。

工数至上主義

受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積おかしくても顧客と対等な関係が築けていないから追加請求もできない。時間(工数)をかければ良い成果物ができるかもしれないがそれを説明して顧客に嫌な顔をされたくないから、限られた工数の中での最善を尽くす。最善を尽くす、聞こえは良いが要は手を抜く。

まり、どう頑張っても売上は同じなのだから、良いもの価値を生むものを作ろうと考えない人が多い。社内で開発者と呼ばれる人間もそうだし、マネジメント層はそういうものづくり志向を持った人をリスク扱いすることもある。

これが諸問題の根源で、いかに述べるような組織プロジェクトが出来上がっていく。

作業効率化しない

マニュアル作業の正確さをかたくなに信じてる人だらけで、ITとは何なんだと考えさせられる。

私は定型作業効率化しようとjsやrubyスクリプトを書いたりしていた。テストデータを開発用DBに突っ込んだり、テキスト処理して整形したり、Excelからコード生成したりするよくあるやつ。

あるとき上司に肩越しに自分作業を覗かれて「何やってるの?」と聞かれ、そういうスクリプトを作ってると答えたら、工数とリスクの話をされた。曰く「そのスクリプト作るのに何日かかるの?工数に乗ってないよね?」「スクリプトテストもちゃんとしないと結果が正しいって保証できなくない?」と。この時はイラッとして「30分でできる数十行のスクリプトだし自分作業工数内で完結する。むしろ工程や別の人でも同じことを再現性できて楽になる」とか真面目に説明してプログラムも見せたが、読もうとはせず(読めないので)1時間無駄にした。

技術力いらない

前述したようなビジネスモデルから営業力と、予定工数で無難プロジェクトを終えるマネジメント力が大事。IT企業だが開発者は自社で持たない。不況の時に待機コストが発生するリスクがあるし、自社で抱えるより単価の安い開発者人材派遣系の企業や下請けにいっぱいいるから。

社長があるとき社内広報で「技術は買うものだ」と言っていた。文脈で明らかに技術=技術者のことだったので、使い捨ての人売り業と揶揄されていることへの自覚が無いと思う。

そういう人が集まっているor残っている組織なので開発者ほとんどいない。20〜30人ぐらいの課に1人ぐらいの割合でstaticおじさんがちらほらいるぐらい。大体20代からプロジェクトリーダーという立場をやり始め、だんだん大型の案件を扱えるようになっていき、後は出世ゲーム部長お気に入り課長になり、部門長のお気に入り部長になる。その繰り返し。

開発案件でのBP(ビジネスパートナー委託先、派遣下請け比率自分の周りだと1:5ぐらいが多い。プロパー社員一人が5人の開発を仕切る、みたいな形。案件規模によりだいぶ差があると思う。この比率が高い=マネジメント力のある組織と考える会社はこの数字を上げようと必死で、比率の低い組織は評価が下がる。

私は開発が好きだったのでエンジニアとして生きていきたい、というようなことを評価面談の度に伝えているが、その度に会社の目指す方向を説かれてモチベーションが下がる。

意識の低い開発者メンバー

上述の通り、案件で接する開発者基本的に社外の人間なのだが、彼らの技術力と意識の高さにはものすごいばらつきがある。言われたものはなんでもこなせる人、何でこの歳まで技術者やれてるんだと疑う人、このプロジェクトおかしいと良い意味で騒ぐ人、何も意見を言わない人、CっぽくJavaを書く人、人当たりは良いが技術力がいまいちな人、すぐ休む人、バグやミスを隠す人…etc。

まぁ色んな人がいるのはどの業界のどの職種も同じだが問題は質だ。私の主観になるが本当にエンジニアとして尊敬できるレベルの人は1%いるかいないか。というのも、ほとんどの技術者は長年SIやその周辺企業と付き合ってきているので同じ体質に染まっているのだ。顧客が良いといえば良いという態度(この場合顧客は私が所属する企業)、請負場合は工数を超えない範囲で手を抜く姿勢、その他諸々。技術力だけをひたすら磨き続けてきたという人はごく一部だけだったし、そんな人でもGitHubアカウント持ってない・ブログやってない・OSSに貢献したことない、といった具合でクローズド世界で生きている。

そうした技術者とやっていく中で最も厄介なのが教育コストだ。案件のあるなしで人が都度入れ替わり、新しい人が来るたびに同じシステム・技術要素の説明をして何とかやる気が出るようモチベートして、というのを繰り返すのに疲れた。私の会社固有の変なルール説明はてきとうにしておいて、私は技術が好きな仲間が欲しかったので今のシステム課題と技術面での改善や展望をよく話す。が、あまり食いつかれることはない。これは私の問題だが、そうした期待と落胆のループ疲弊の一因だ。

static BP

ある時、一つの課に6年近くいるというBPと一緒に仕事をする機会があった。その課にはプロパー技術者が長いことおらず、彼がその課の技術的中心を担っているという話だった。抜けられると途端に色んなものが崩壊するからという理由で、その人の派遣元にはかなり高額の単価を支払っていたと聞いた。課員が口をそろえて「あの人はすごい」「何でもできる」というので初めはかなり期待していた。

だが、拍子抜けした。あまりにも仕事が雑なのだコミットされたコードはTODOコメントだらけだし、バグがあまりにも多かった。一度も実行されずにコミットされ、他の人がチェックアウトした時点で判明したバグなんかもあった。それでも声が大きく、プロパーが技術を知らないのをいいことに自分ブランディングに完全に成功していた。客先にも顔を出し、信頼を得ているらしかった。「自分は設計が得意でテスト以降の工程には興味が無い」と言っていた。確かに彼が関わった各システムには独特の概念が埋め込まれた設計があったが、その複雑な設計は保守性が低く、他の開発者が触ると容易にバグを引き起こしていた。

また、彼はJavaの有名なフレームワークであるStruts拡張したいわゆるオレオレフレームワークを開発しており、それの出来は悪くなかったと思う。そのフレームワークに欠けているものをうまく補うような形になっていた。だがフレームワークバージョンを上げると壊れるというのが残念な点で負債になりかけていた。

私は異動したが、彼は今でもそこにいると聞いた。

技術の話

テストコード書けない

(最低限のものしか作らないから)安くて早い!という触れ込みで売っているので、テストの工数が異常に少ないことも多い。特にテストコードを書くなんてもってのほか。そういう世界でやってきた人ばかりなので、30や40超えたマネジメント側は「テストコードって何?」状態だ。大型の改修案件が来た時にはコア機能だけでもテストを書いていこうと見積段階から社内で提案したが「顧客に『そんなメリットあるなら何で今までのプロジェクトではやってないの?』って問われるから絶対言うなよ」と拒否された。

保守案件をやっていた頃、時間を捻出してコソコソとテストコードを書いたりしていた。その案件を離れてしばらく後、ある時リポジトリを覗いたら私が書いたテストコードがばっさり消えていて驚いた。コミットログから課内のstaticおじさん的な人が消したとわかったが、そのコミットコメントが「現在使用していないコードを削除」だった。これはもう問う気も失せて何も言えなかった。

リファクタできない

先述したようにテストがそもそもないプロジェクトが基本なのでリファクタできないのだが、たとえテストがあったとしても勝手なリファクタは許されない。ソースコード顧客の持ち物なので同意なしに改変することはいわば契約違反なのだ。たとえ内的品質が向上してコスト削減に繋がるとしても、そのためにお金を支払う顧客はまずいない。

レビューない

私がいたどの案件にもコードレビューがなかった。リーダー開発者数人という構成場合、まず開発者は全員下請けリーダーは技術の心得がない場合が多い。そうなると彼らの成果物の良し悪しを図るのは目に見えるシステム挙動実施されたテスト結果のExcel報告書だけになる。これが非常に非効率で、少しコードを読めばわかる明らかなバグや仕様理解齟齬が頻発していた。特に入試験と呼ばれるリリース直前の顧客側での最終確認や本番稼働中におけるhotfixは全機能をきちんとテストせずにデプロイされることが多く、そのhotfixがさらなるバグを引き起こしたりもしていた。

そもそもテストを書けという話だがテストが無いプロジェクトに足すのはかなり大変なので、レビューサイクルをきちんと回すだけでもかなり変わる。実際、私が入った案件ではすべてのコミットに目を通すようにし、明らかな問題は都度指摘することで品質の向上に繋がった。欲を言えば他の開発者にもレビューしてもらいたいが、下請けの彼らの工数を増やすことは嫌がられる。

新規技術試せない

無難プロジェクトをこなすことと新しい技術を試すことの両立こそ技術者の腕の見せどころだと思っているが、ほとんどの場合それは許されなかった。新規にせよ継続にせよ案件を受注する段階で営業マネジメント層と顧客間で「今回は過去に実績のあるこの技術でやります」という契約が結ばれているからだ。その技術(言語フレームワーク)がいかに古く、保守性も将来性もないものだとしても受注できればよいし、その技術のサポート切れか何かの拍子で再度リプレイス案件でも受注できればさらラッキーぐらいの考えでいる。

常に横に倣えのアーキテクチャは私にとって面白くはなかった。

横に倣え

また横に倣えが加速してさらに悪い事に、同じアーキテクチャネットワーク再利用するために既存のサーバに新システム相乗りすればよいという発想も珍しくない。「資産再利用によりコスト削減」という触れ込みだったが、ただでさえスケールしない低スペックオンプレミスサーバ上で複数アプリケーションサーバ運用した結果、予想通り耐障害性が下がった。

また、Oracleライセンスが高いという理由で一つのDBインスタンス上に10数個のシステムが同時稼働しているなんてこともあった。1つのシステムが高負荷なクエリを投げたせいで関連する全システム共倒れになったこともあったがOracleのバグとして報告していた。

static Perlおじさん

新人の頃にOJTでstaticおじさんの下に付いたことがあった。そのとき担当したのはPerlデータ連携用のバッチを書くという開発業務だったのだが、最悪の思い出だ。

まずプログラム構造仕様書というのを書かされた。メソッド単位でのモジュールを全てExcel上に記述し、処理の順番と内容を説明するという謎資料だった。あまりに意味がわからなかったので「UMLのクラス図を書けばよいのですか?」と聞いたら「Perlクラスなんて必要ない。構造プログラミング研修でならってないのか」と返ってきた。「俺が前に書いたPerlバッチがあるから参考にしろ」と言われ、あるリポジトリをチェックアウトして見てみると1ファイル4,000行の.plがいくつか並んでいた。その時の私は何もわかっていなかったのでそういうものかと思ってしまったが後で調べて明らかにおかしいと気づいた。

また、そのプロジェクトのメイン言語Javaで、Eclipseを使っていたのでPerlプラグインを入れてコーディングデバッグをしていたらやめろと言われた。理由は「Eclipse上で動くPerlが信用できない。サクラエディタで書いてプリントデバッグすれば充分だ」と言われた。その時の私は何もわかっていなかったので、プラグイン品質が悪いとかそういう話かと思い「じゃあvimで書きます」と言ったら「サクラエディタしろと言っただろ!」と一喝され、vim vs サクラエディタという史上類を見ないエディタ論争が起きた。

待遇・制度

給与

SI業界の中では高いのかもしれないが決してよくはない。4年目(たぶん25歳)ぐらいで残業込みで年収400万にやっと届いたがそこからほとんど変わっていない。30歳の先輩に聞いたところ「500万前後残業してない場合の月の手取りは未だに20万切ることがある。残業抜きでは新婚生活が厳しい」と言っていた。いわゆる年功序列がきっちりしていてこのまま続けてもしばらくは給与が伸びないということがわかった。

個人での貢献で差がつくのは±10万程度。その程度ならいっそ無くてもいいのでは、と思う。というかそもそも生産性をきちんと評価する制度存在しない。これはどの組織でも難しい問題だと思うが、形骸化した評価制度上司の気に入った人間にS評価を付けているだけならいっそ止めたほうが時間の無駄にならなくてよい。

マシン

会社から貸与されるノートPCは低スペックすぎて開発には使い物にならない。なので開発者基本的デスクトップ使用せざるを得ないのだがこれもメモリ4G、1.2GHz程度で大したマシンでもない。本当に開発する気がない。

組織問題

とにかくクローズド組織

つの間にかどこかで意思決定がされていて、関与する機会がほとんどない。だがほとんどの社員がそれで良いと思ってる。失敗しても自分が決めたことじゃないから上層の責任だ、そう言えるので楽だから

情報共有をしない、というか意図的にしないようにしているとまで感じる。連絡はメール添付ファイルベースで行っているし、共有のファイルサーバなんてのもあったが一部のフォルダ権限を持った人間しか見られない。何で他の部や課が行った過去の見積提案資料自由に見られないんだよ。

ソースコードリポジトリも同様。外部に公開しないのはまだわかるが、プロジェクト外にすら基本は公開していない。別に奪われて困る大した技術もない。

会社が用意した提案資料共有サイトみたいなのもあったが、それに至ってはもっとひどい。課長以上もしくは部長から承認を与えられた者のみ閲覧可能。共有とは。

意思決定の遅さ

どうでもいいことを決めるにも承認や根回しや説得が必要になる。それがプロジェクト利害関係者ならまだわかるものの、まったく関わっていない上長(課長部長、時には部門長)を通さないと進まないという異常さ。

コスト削減

利益率向上のためにコスト削減ということがしきりに言われており、過剰なコスト削減対応生産性の低下を招いている。たとえば顧客に見せる資料以外は白黒で印刷しろ、みたいなルール。色がないために情報が伝わりにくい。というかそもそも印刷せずに各自ノートPCで見ろという話だが、先述したようにノートPCは低スペックすぎるので多くの社員デスクトップを使っている。ITとは。

本当に無駄しか思えない承認・申請フローの煩雑さに加え、使っているシステムの使い勝手も悪く、ひどい日は一日がそうした事務作業で終わる。しかもそのシステムは自社で以前開発したものだというから泣けてくる。こんな作業が定常的に発生するのでいっそ事務員派遣で雇うべきという提案が何度もされたが、課の予算オーバーするから無理だという回答しか返ってこない。

残業削減

表向きは社員健康促進という触れ込みで残業時間削減を全社的に取り組んでいる。残業減らせと声をかけただけでは誰も帰らないので、勤怠システムと入退館管理システム監視し、削減できていない組織や人間評価を下げるようになった。

その結果、サービス残業が復活した。30時間を超えると部長説明しないといけない、50時間を超えるとその上へ…みたいなループ。表向きの残業時間削減・コスト削減としては成功したかもしれないが、社員残業時間を管理するとかい無駄な仕事を増やしたし、管理される社員ストレスサービス残業に繋がったので下策だと思う。

他人残業時間をExcelにまとめる仕事があって、そこに給与が発生してると思うと泣きたい。

そもそも無駄作業や工数至上主義作業効率が悪いから残業しているので、残業が少ない奴が偉いと一斉に舵取りしただけでは生産性をちゃんと評価できていないことに変わりはない。一昔前の残業多い奴は頑張ってて偉い、というのと本質レベルで何も変わっていない。

辞め方

2016-01-14

北朝鮮公式

かなりオープンサイトだ。

nmap www.korea-dpr.com

Starting Nmap 6.47 ( http://nmap.org ) at 2016-01-14 21:20 JST
Stats: 0:00:00 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 0.55% done
Nmap scan report for www.korea-dpr.com (87.98.231.40)
Host is up (0.28s latency).
rDNS record for 87.98.231.40: cluster011.ovh.net
PORT      STATE    SERVICE
1/tcp     open     tcpmux
3/tcp     open     compressnet
4/tcp     open     unknown
6/tcp     open     unknown
7/tcp     open     echo
9/tcp     open     discard
13/tcp    open     daytime
17/tcp    open     qotd
19/tcp    open     chargen
20/tcp    open     ftp-data
21/tcp    open     ftp
22/tcp    open     ssh
23/tcp    open     telnet
24/tcp    open     priv-mail
25/tcp    closed   smtp
26/tcp    open     rsftp
30/tcp    open     unknown
32/tcp    open     unknown
33/tcp    open     dsp
37/tcp    open     time
42/tcp    open     nameserver
43/tcp    open     whois
49/tcp    open     tacacs
53/tcp    open     domain
70/tcp    open     gopher
79/tcp    open     finger
80/tcp    open     http
81/tcp    open     hosts2-ns
82/tcp    open     xfer
83/tcp    open     mit-ml-dev
84/tcp    open     ctf
85/tcp    open     mit-ml-dev
88/tcp    open     kerberos-sec
89/tcp    open     su-mit-tg
90/tcp    open     dnsix
99/tcp    open     metagram
100/tcp   open     newacct
106/tcp   open     pop3pw
109/tcp   open     pop2
110/tcp   open     pop3
111/tcp   open     rpcbind
113/tcp   open     ident
119/tcp   open     nntp
125/tcp   open     locus-map
135/tcp   open     msrpc
139/tcp   filtered netbios-ssn
143/tcp   open     imap
144/tcp   open     news
146/tcp   open     iso-tp0
161/tcp   open     snmp
163/tcp   open     cmip-man
179/tcp   open     bgp
199/tcp   open     smux
211/tcp   open     914c-g
212/tcp   open     anet
222/tcp   open     rsh-spx
254/tcp   open     unknown
255/tcp   open     unknown
256/tcp   open     fw1-secureremote
259/tcp   open     esro-gen
264/tcp   open     bgmp
280/tcp   open     http-mgmt
301/tcp   open     unknown
306/tcp   open     unknown
311/tcp   open     asip-webadmin
340/tcp   open     unknown
366/tcp   open     odmr
389/tcp   open     ldap
406/tcp   open     imsp
407/tcp   open     timbuktu
416/tcp   open     silverplatter
417/tcp   open     onmux
425/tcp   open     icad-el
427/tcp   open     svrloc
443/tcp   open     https
444/tcp   open     snpp
445/tcp   filtered microsoft-ds
458/tcp   open     appleqtc
464/tcp   open     kpasswd5
465/tcp   open     smtps
481/tcp   open     dvs
497/tcp   open     retrospect
500/tcp   open     isakmp
512/tcp   open     exec
513/tcp   open     login
514/tcp   open     shell
515/tcp   open     printer
524/tcp   open     ncp
541/tcp   open     uucp-rlogin
543/tcp   open     klogin
544/tcp   open     kshell
545/tcp   open     ekshell
548/tcp   open     afp
554/tcp   open     rtsp
555/tcp   open     dsf
563/tcp   open     snews
587/tcp   open     submission
593/tcp   open     http-rpc-epmap
616/tcp   open     sco-sysmgr
617/tcp   open     sco-dtmgr
625/tcp   open     apple-xsrvr-admin
631/tcp   open     ipp
636/tcp   open     ldapssl
646/tcp   open     ldp
648/tcp   open     rrp
666/tcp   open     doom
667/tcp   open     disclose
668/tcp   open     mecomm
683/tcp   open     corba-iiop
687/tcp   open     asipregistry
691/tcp   open     resvc
700/tcp   open     epp
705/tcp   open     agentx
711/tcp   open     cisco-tdp
714/tcp   open     iris-xpcs
720/tcp   open     unknown
722/tcp   open     unknown
726/tcp   open     unknown
749/tcp   open     kerberos-adm
765/tcp   open     webster
777/tcp   open     multiling-http
783/tcp   open     spamassassin
787/tcp   open     qsc
800/tcp   open     mdbs_daemon
801/tcp   open     device
808/tcp   open     ccproxy-http
843/tcp   open     unknown
873/tcp   open     rsync
880/tcp   open     unknown
888/tcp   open     accessbuilder
898/tcp   open     sun-manageconsole
900/tcp   open     omginitialrefs
901/tcp   open     samba-swat
902/tcp   open     iss-realsecure
903/tcp   open     iss-console-mgr
911/tcp   open     xact-backup
912/tcp   open     apex-mesh
981/tcp   open     unknown
987/tcp   open     unknown
990/tcp   open     ftps
992/tcp   open     telnets
993/tcp   open     imaps
995/tcp   open     pop3s
999/tcp   open     garcon
1000/tcp  open     cadlock
1001/tcp  open     unknown
1002/tcp  open     windows-icfw
1007/tcp  open     unknown
1009/tcp  open     unknown
1010/tcp  open     surf
1011/tcp  open     unknown
1021/tcp  open     exp1
1022/tcp  open     exp2
1023/tcp  open     netvenuechat
1024/tcp  open     kdm
1025/tcp  open     NFS-or-IIS
1026/tcp  open     LSA-or-nterm
1027/tcp  open     IIS
1028/tcp  open     unknown
1029/tcp  open     ms-lsa
1030/tcp  open     iad1
1031/tcp  open     iad2
1032/tcp  open     iad3
1033/tcp  open     netinfo
1034/tcp  open     zincite-a
1035/tcp  open     multidropper
1036/tcp  open     nsstp
1037/tcp  open     ams
1038/tcp  open     mtqp
1039/tcp  open     sbl
1040/tcp  open     netsaint
1041/tcp  open     danf-ak2
1042/tcp  open     afrog
1043/tcp  open     boinc
1044/tcp  open     dcutility
1045/tcp  open     fpitp
1046/tcp  open     wfremotertm
1047/tcp  open     neod1
1048/tcp  open     neod2
1049/tcp  open     td-postman
1050/tcp  open     java-or-OTGfileshare
1051/tcp  open     optima-vnet
1052/tcp  open     ddt
1053/tcp  open     remote-as
1054/tcp  open     brvread
1055/tcp  open     ansyslmd
1056/tcp  open     vfo
1057/tcp  open     startron
1058/tcp  open     nim
1059/tcp  open     nimreg
1060/tcp  open     polestar
1061/tcp  open     kiosk
1062/tcp  open     veracity
1063/tcp  open     kyoceranetdev
1064/tcp  open     jstel
1065/tcp  open     syscomlan
1066/tcp  open     fpo-fns
1067/tcp  open     instl_boots
1068/tcp  open     instl_bootc
1069/tcp  open     cognex-insight
1070/tcp  open     gmrupdateserv
1071/tcp  open     bsquare-voip
1072/tcp  open     cardax
1073/tcp  open     bridgecontrol
1074/tcp  open     warmspotMgmt
1075/tcp  open     rdrmshc
1076/tcp  open     sns_credit
1077/tcp  open     imgames
1078/tcp  open     avocent-proxy
1079/tcp  open     asprovatalk
1080/tcp  open     socks
1081/tcp  open     pvuniwien
1082/tcp  open     amt-esd-prot
1083/tcp  open     ansoft-lm-1
1084/tcp  open     ansoft-lm-2
1085/tcp  open     webobjects
1086/tcp  open     cplscrambler-lg
1087/tcp  open     cplscrambler-in
1088/tcp  open     cplscrambler-al
1089/tcp  open     ff-annunc
1090/tcp  open     ff-fms
1091/tcp  open     ff-sm
1092/tcp  open     obrpd
1093/tcp  open     proofd
1094/tcp  open     rootd
1095/tcp  open     nicelink
1096/tcp  open     cnrprotocol
1097/tcp  open     sunclustermgr
1098/tcp  open     rmiactivation
1099/tcp  open     rmiregistry
1100/tcp  open     mctp
1102/tcp  open     adobeserver-1
1104/tcp  open     xrl
1105/tcp  open     ftranhc
1106/tcp  open     isoipsigport-1
1107/tcp  open     isoipsigport-2
1108/tcp  open     ratio-adp
1110/tcp  open     nfsd-status
1111/tcp  open     lmsocialserver
1112/tcp  open     msql
1113/tcp  open     ltp-deepspace
1114/tcp  open     mini-sql
1117/tcp  open     ardus-mtrns
1119/tcp  open     bnetgame
1121/tcp  open     rmpp
1122/tcp  open     availant-mgr
1123/tcp  open     murray
1124/tcp  open     hpvmmcontrol
1126/tcp  open     hpvmmdata
1130/tcp  open     casp
1131/tcp  open     caspssl
1132/tcp  open     kvm-via-ip
1137/tcp  open     trim
1138/tcp  open     encrypted_admin
1141/tcp  open     mxomss
1145/tcp  open     x9-icue
1147/tcp  open     capioverlan
1148/tcp  open     elfiq-repl
1149/tcp  open     bvtsonar
1151/tcp  open     unizensus
1152/tcp  open     winpoplanmess
1154/tcp  open     resacommunity
1163/tcp  open     sddp
1164/tcp  open     qsm-proxy
1165/tcp  open     qsm-gui
1166/tcp  open     qsm-remote
1169/tcp  open     tripwire
1174/tcp  open     fnet-remote-ui
1175/tcp  open     dossier
1183/tcp  open     llsurfup-http
1185/tcp  open     catchpole
1186/tcp  open     mysql-cluster
1187/tcp  open     alias
1192/tcp  open     caids-sensor
1198/tcp  open     cajo-discovery
1199/tcp  open     dmidi
1201/tcp  open     nucleus-sand
1213/tcp  open     mpc-lifenet
1216/tcp  open     etebac5
1217/tcp  open     hpss-ndapi
1218/tcp  open     aeroflight-ads
1233/tcp  open     univ-appserver
1234/tcp  open     hotline
1236/tcp  open     bvcontrol
1244/tcp  open     isbconference1
1247/tcp  open     visionpyramid
1248/tcp  open     hermes
1259/tcp  open     opennl-voice
1271/tcp  open     excw
1272/tcp  open     cspmlockmgr
1277/tcp  open     miva-mqs
1287/tcp  open     routematch
1296/tcp  open     dproxy
1300/tcp  open     h323hostcallsc
1301/tcp  open     ci3-software-1
1309/tcp  open     jtag-server
1310/tcp  open     husky
1311/tcp  open     rxmon
1322/tcp  open     novation
1328/tcp  open     ewall
1334/tcp  open     writesrv
1352/tcp  open     lotusnotes
1417/tcp  open     timbuktu-srv1
1433/tcp  open     ms-sql-s
1434/tcp  open     ms-sql-m
1443/tcp  open     ies-lm
1455/tcp  open     esl-lm
1461/tcp  open     ibm_wrless_lan
1494/tcp  open     citrix-ica
1500/tcp  open     vlsi-lm
1501/tcp  open     sas-3
1503/tcp  open     imtc-mcs
1521/tcp  open     oracle
1524/tcp  open     ingreslock
1533/tcp  open     virtual-places
1556/tcp  open     veritas_pbx
1580/tcp  open     tn-tl-r1
1583/tcp  open     simbaexpress
1594/tcp  open     sixtrak
1600/tcp  open     issd
1641/tcp  open     invision
1658/tcp  open     sixnetudr
1666/tcp  open     netview-aix-6
1687/tcp  open     nsjtp-ctrl
1688/tcp  open     nsjtp-data
1700/tcp  open     mps-raft
1717/tcp  open     fj-hdnet
1718/tcp  open     h323gatedisc
1719/tcp  open     h323gatestat
1720/tcp  open     H.323/Q.931
1721/tcp  open     caicci
1723/tcp  open     pptp
1755/tcp  open     wms
1761/tcp  open     landesk-rc
1782/tcp  open     hp-hcip
1783/tcp  open     unknown
1801/tcp  open     msmq
1805/tcp  open     enl-name
1812/tcp  open     radius
1839/tcp  open     netopia-vo1
1840/tcp  open     netopia-vo2
1862/tcp  open     mysql-cm-agent
1863/tcp  open     msnp
1864/tcp  open     paradym-31
1875/tcp  open     westell-stats
1900/tcp  open     upnp
1914/tcp  open     elm-momentum
1935/tcp  open     rtmp
1947/tcp  open     sentinelsrm
1971/tcp  open     netop-school
1972/tcp  open     intersys-cache
1974/tcp  open     drp
1984/tcp  open     bigbrother
1998/tcp  open     x25-svc-port
1999/tcp  open     tcp-id-port
2000/tcp  open     cisco-sccp
2001/tcp  open     dc
2002/tcp  open     globe
2003/tcp  open     finger
2004/tcp  open     mailbox
2005/tcp  open     deslogin
2006/tcp  open     invokator
2007/tcp  open     dectalk
2008/tcp  open     conf
2009/tcp  open     news
2010/tcp  open     search
2013/tcp  open     raid-am
2020/tcp  open     xinupageserver
2021/tcp  open     servexec
2022/tcp  open     down
2030/tcp  open     device2
2033/tcp  open     glogger
2034/tcp  open     scoremgr
2035/tcp  open     imsldoc
2038/tcp  open     objectmanager
2040/tcp  open     lam
2041/tcp  open     interbase
2042/tcp  open     isis
2043/tcp  open     isis-bcast
2045/tcp  open     cdfunc
2046/tcp  open     sdfunc
2047/tcp  open     dls
2048/tcp  open     dls-monitor
2049/tcp  filtered nfs
2065/tcp  open     dlsrpn
2068/tcp  open     advocentkvm
2099/tcp  open     h2250-annex-g
2100/tcp  open     amiganetfs
2103/tcp  open     zephyr-clt
2105/tcp  open     eklogin
2106/tcp  open     ekshell
2107/tcp  open     msmq-mgmt
2111/tcp  open     kx
2119/tcp  open     gsigatekeeper
2121/tcp  open     ccproxy-ftp
2126/tcp  open     pktcable-cops
2135/tcp  open     gris
2144/tcp  open     lv-ffx
2160/tcp  open     apc-2160
2161/tcp  open     apc-agent
2170/tcp  open     eyetv
2179/tcp  open     vmrdp
2190/tcp  open     tivoconnect
2191/tcp  open     tvbus
2196/tcp  open     unknown
2200/tcp  open     ici
2222/tcp  open     EtherNet/IP-1
2251/tcp  open     dif-port
2260/tcp  open     apc-2260
2288/tcp  open     netml
2301/tcp  open     compaqdiag
2323/tcp  open     3d-nfsd
2366/tcp  open     qip-login
2381/tcp  open     compaq-https
2382/tcp  open     ms-olap3
2383/tcp  open     ms-olap4
2393/tcp  open     ms-olap1
2394/tcp  open     ms-olap2
2399/tcp  open     fmpro-fdal
2401/tcp  open     cvspserver
2492/tcp  open     groove
2500/tcp  open     rtsserv
2522/tcp  open     windb
2525/tcp  open     ms-v-worlds
2557/tcp  open     nicetec-mgmt
2601/tcp  open     zebra
2602/tcp  open     ripd
2604/tcp  open     ospfd
2605/tcp  open     bgpd
2607/tcp  open     connection
2608/tcp  open     wag-service
2638/tcp  open     sybase
2701/tcp  open     sms-rcinfo
2702/tcp  open     sms-xfer
2710/tcp  open     sso-service
2717/tcp  open     pn-requester
2718/tcp  open     pn-requester2
2725/tcp  open     msolap-ptp2
2800/tcp  



  
  

2015-11-17

NTTドコモ課金および決済基盤「MoBills」でSQLServerOracleの両方を採用

SQLServerOracleを両方使ってるってどういうことだ・・・

SQLServerパフォーマンスでなかったからExadataに乗り換えたということ?

NTTドコモSQL Server 2014を採用、全契約回線課金・決済システムに”

http://cloud.watch.impress.co.jp/docs/news/20150828_718454.html

NTTドコモ、料金システムリアルタイム・ビリング基盤を「Oracle Exadata」で刷新

http://japan.zdnet.com/article/35073567/

NTTドコモ課金および決済基盤「MoBills」でSQLServerOracleの両方を採用

SQLServerOracleを両方使ってるってどういうことだ・・・

SQLServerパフォーマンスでなかったからExadataに乗り換えたということ?

NTTドコモSQL Server 2014を採用、全契約回線課金・決済システムに”

http://cloud.watch.impress.co.jp/docs/news/20150828_718454.html

NTTドコモ、料金システムリアルタイム・ビリング基盤を「Oracle Exadata」で刷新

http://japan.zdnet.com/article/35073567/

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん