  |
はてなキーワード: IBMとは
よくある勘違いだが、AWS移行しても大半のSIerは消えないから
富士通、日立、IBM、HPEとかのハードウェア系SIerは影響あるけど、NTTデータとかNRIとかNSSOLとかISIDとかCTCとかの一般またはユーザー系SIerは、AWSを使いこなす側に既に移行してる
1.国際NGO「オックスファム」の発表によると、世界で最も裕福な8人が保有する資産は、世界の人口のうち下から半分にあたる約36億人が保有する資産とほぼ同じとのこと。この上位8人のうち、いずれか3名を述べよ。
3.かつて通信業界で問題になり、最近は流通業界でも問題とされる、サービスの最終工程で発生する問題を○○問題という。
4.仮想通貨に採用せれている中核技術で、分散型台帳とも呼ばれる技術を何と呼ぶか。
6.インテル創業者の一人が唱えた「半導体の集積率は18か月で2倍になる」という法則を何と言うか？
7.近年アメリカで評価された思想で、今の自分に意識を向けて、現実を受け入れていく研修を何と言うか。
8.ファイブアイズと呼ばれる諜報にかんする取り決めを結んでいる国として、アメリカ、イギリス以外の3カ国を答えよ。
9.技術的特異点と呼ばれる、人工知能が人間の能力を超えることで生まれる事象を指す言葉は？
金融系システム会社の研修で一般常識問題として出題された問題で、趣旨は得点の問題では無く、自分の業界に関わるキーワードを主体的に取り入れてますか？という気づきに使うものだったんだけど、正直、これが常識かよと心でモヤモヤしてる。はてなー的には全問正解当たり前？
ちなみに自分は6問せ正解だった
http://anond.hatelabo.jp/20170512175648
私にこたえられる質問の類ではないので、あくまで私の私感にすぎないことはご承知おきを。
こういった法改正の欲求がどういったところにあるのか、というのは、いろいろな修正を受ける前の、粗削りな段階が一番わかりやすいと思うので、それを調べます。国会で初めて議論されたのは、1982年IBM産業スパイ事件で、IBMの新商品情報を手に入れようとした日本企業の社員（日立と富士通）を、それと承知の上で、要は盗品と知った上での輸送の共謀をしたということで、国際捜査共助に基づいて、アメリカから日本在住の社員１２人の身柄引き渡しを求められた事件。これで日本には共謀段階での処罰規定はないから、引き渡しには応じられないのではないか、という野党側に対し、日本の12人が、それぞれ個別に日本とアメリカでともに犯罪とされることをやっていないかを調べてからでないと、引き渡し出来るともできないとも言えない、みたいな議論はされています。結局身柄の引き渡しは行われませんでしたが、このIBM産業スパイ事件以降、激化して来る日米貿易摩擦の中で、この件を嚆矢とした共謀罪の制定要求がアメリカからあったとしてもおかしくないと思いますが、この際は具体的な動きはありません。
その次に国会で共謀罪が議論されるのは2002年に、新聞記事で、TOC条約の議論に向けて日本でも共謀罪を制定する、という新聞報道があったことを質した坂上議員の質疑ですが、この際は、法務省が報道を完全否定する形で質疑はほとんどされていません。しかし実はこの前に、長尾立子法務大臣（橋本内閣）が法制審に諮問しているのです。きっかけはおそらくですが、オウム真理教事件です。
この法制審に提出された組織的犯罪刑事法整備参考試案及び事務当局説明要旨には、
一 諮問の背景
近年、暴力団等による薬物、銃器等の取引やこれらの組織の不正な権益の獲得・維持を目的とした各種の犯罪のほか、いわゆるオウム真理教事件のような 大規模な組織的な凶悪事犯、会社などの法人組織を利用した悪徳商法等の大型経済犯罪など、組織的な犯罪が平穏な市民生活を脅かすとともに、健全な社会経済の維持、発展に悪影響を及ぽしかねない状況にある。
と書かれており、オウム真理教の一連のテロ事件に対応するための議論であったことがわかります。これは、当時の報道を記憶されている人だったならばわかると思いますが、坂本堤弁護士一家殺害事件や、公証役場事務長逮捕監禁致死事件で、オウムの犯罪に関する情報を複数得ていながら地下鉄サリン事件を防げなかったという強い批判があったので、その批判をかわす目的で、組織的犯罪に関する刑事法の整備が不十分であることを論拠にしようとしているのだと、私としては考えます。
この文書には、組織的犯罪への加重量刑、犯罪収益の取り締まりなどとともに、章立てて「令状による通信の傍受」という項があります。ここに、数人による共謀の存在が疎明されたときに、令状を取得し、盗聴を可能とすることについての意見を求めています。この段階で対象となっているのは、殺人や誘拐などのいわゆる重大犯罪と、麻薬取引等のいわゆるやくざ案件です。その中では以下のように諮問されています。
１ 令状による傍受の要件等
(1) 検察官又は司法警察員は、次の各号のいずれかに該当する場合において、犯人により犯罪を実行し又は実行することに関連する通信（電話又はファクシミリによる通信、コンピュータ通信その他の電気通信であって、その全部又は一部が有線によって行われるものをいう。以下同じ。）が行われると疑うに足りる状況があり、かつ、犯人を特定し又は犯行の状況若しくは内容を明らかにするため他に適当な方法がないと認められるときは、通信当事者のいずれの同意もない場合であっても、裁判官の発する令状により、犯罪を実行し又は実行することに関連すると思料される通信を傍受することができるものとすること。
ア 死刑、無期懲役若しくは無期禁錮の定めのある罪又は別表５に掲げる罪が犯されたと疑うに足りる充分な理由がある場合において、当該犯罪が数人の共謀によるものであると疑うに足りる状況があるとき
イ アに記載する犯罪が行われ、かつ、更に継続して行われると疑うに足りる充分な理由がある場合において、数人の共謀によるものであると疑うに足りる状況があるとき
ウ ある犯罪がアに記載する犯罪の実行のために必要な行為として行われ、当該アに記載する犯罪が行われると疑うに足りる充分な理由がある場合において、当該アに記載する犯罪が数人の共謀によるものであると疑うに足りる状況があるとき
このウがいわゆる共謀罪に当たるものですが、共謀罪として最初から出てきたわけではなく、共謀段階での捜査ということになっています。動機はやはりこのあたりなのではないかと私は考えています。現状民進党などが指摘している、内心だけの初犯の犯罪の共謀をどうやって探知するんだ、という指摘が実はクリティカルで、政府の答弁では、監視が目的でない、としていっているのですが、出てきた背景を考えると、令状実務を考えて警察が調べたいと思った電話やメールやSNSなどの情報開示を手軽に行いたい、ということが、ことの端緒を考えるとどう考えても本丸だと思うのです。この流れは結局犯罪捜査のための通信傍受に関する法律（平成11年）にも同時につながっていますし、昨年対象犯罪が拡大したところです。この法律ができた時の騒ぎに比べて、対象犯罪の拡大は実にあっさりと通過しましたが、このテロ等準備罪が通信傍受の対象犯罪となれば、当初の目的が達成されることになるのだと思います。
この法制審の議論をしているような段階で、TOC条約が出てきたので、これ幸いとばかりに対象を４年以上としましょうといって600、700と広げていったのが小泉政権時代の案でした。その後、平岡秀夫議員や保坂展人議員などの質疑に応じる形で対象犯罪の数はかなりテロや組織的犯罪にしぼられて百数十としましょうとなったのが00年代中盤の議論、そして安倍政権では小泉政権時代の案に先祖返りしてから出発して、対象犯罪を277とした、ということです。TOC条約などは私がなんども書いている通り、異議が出ようが出まいが、条約２条等を留保することで締結自体は可能です。その後留保の取り下げについて議論してもいいわけです。それをやらないというのはこれを錦の御旗として、できるだけ範囲を広げていきたいという欲求があるからだと思います。私も、これを転び公妨のように、反対運動等や労働運動を取り締まることを主目的とはしていないだろうとは思います。あくまで、「それにも使えるな」という程度の認識だと思います。
警察は捜査上の人権侵害についてきわめていい加減に考えていることは明らかなので、結構単純に、「あやしいっておもったやつをもっと簡単に調べられるようにしてほしい」という動機がほぼすべてなんだと思いますよ。そしておそらく現在の安倍さんたちのような保守派の政治家たち自身は、「自分たちは濫用するつもりはない」と結構本気で思っているとも思います。でも法律の立てつけとしてどうとでもできるよね、という話で、このあたりの未来への想像力、人権侵害の重要性というものは、彼らにいつもいつも軽視しているので、「ごちゃごちゃうるせーな」という態度なんだと思っています。
これは全部あくまで私の私感の話です。
給与がかなり厳しい故に人材の質も高くなく、あと人がとにかく多く、社屋が暗い
給与がかなり厳しいがどうもトップレベルマネジメントや管理職の品質がいいようで会社としての対応はしっかりしている印象
一方でワーカーは続々流出中とのこと
よく知りません
同社出身の人は鬼のようだったり目がすわっていたりという人が多く、恐ろしい環境だったのでは・・と推察
よく知りません
よく知りません
異様な落ち着きがある。公家でしょうか。儲かっているのかは謎
昔はつらそうというイメージ、今はニュースをはたりと聞かず。どんな会社になったんだろう
一人一人はしっかりしていて良い人なのだが組織がややこしすぎて働くのは大変そう
営業現場はいろいろあるようですが、同社系IT人材は優秀で動きの良い人が多い。やはり激しい環境でふるいにかけられているのでしょうか
総合的には悪い感想だったのですが、良い点と悪い点について書きます。
翻訳を始め、会場の広さやスクリーンなど、キャパに見合ったとても良い会場だった。
やはり国内外からiOSエンジニアがたくさん参加されていたので、普段聞けないような話をたくさん聞けたのは良かった。
特に、日本でユーザ数の多いアプリを手がけているエンジニアの話は貴重で、これだけでも参加した価値はあったと思う。
やはりTry!Swiftとついていることもあって、聞きたかったのはSwiftの話だったが、3割くらい無関係or設計やプロダクトの話だった。
決して勉強にならなかったわけではなかったのだが、前年のTry!Swiftがすごく良かったと聞いていて参加した分、期待外れは大きかった。
また、LTは全く関係ない話でも募集していたかもしれないが、それなら元から予定していたトークの間に挟むなど順番も考えて欲しかった。
特に、そのトークに問題があったわけではないが、一日の最後がLTであることも悪い点の一つだった。
これは特に三日目のハッカソンの際に感じたことだが、どうも内輪で盛り上がって置いてけぼりに感じることが多かった。
また、三日目は一日を通してグダグダだったと言わざるを得ないと思う。
これは違うかもしれないが、この日はアプリ道場の方々がメインで立ち回っていた様に見え、初日・二日目と違った様に思う。
など、あげればきりがないと思った。
名指しして申し訳ないが、今後アプリ道場が運営に関わるイベントは参加しないと思う。
決して安くない参加費を払って参加しているわけなので、少しでも知見を得たかったが、どう見ても価格に合う様な価値は得られなかったと思う。（良い点にも書いた通り、参加した意味がなかったわけではない）
隣の芝生ではないが、次週のDroidKaigi 2017がとても良さそうに見えて、参加費も半分以上違うことからこちらの方に参加すれば良かったと感じる。
遠方から来ている以上どちらも参加は難しく、より興味のあったTry!Swiftを選択したが、その分残念だった。
悪い感想エントリになったが、あくまでも個人の感想であり、全員が全員こういった感想ではないと思う。
で、でんでんででん！
春、春、春！
で、でんでんででん！
春、春、春！
とりあえず、迫り来る何かに追われてるの。
ひょ、ひょっとして
は、春！？
春がやって来るわ！
そして、次から次にやって来る。
迫る初夏！
初夏が来る前に
春がアイルビーバッグと言って
また来年やって来るわ。
そして、また迫り来る初夏！
繰り返されるこのポリリズム！
もう、何回も何回も何回も言ってるけど
この歌好きなのよね。
まあ、そんなもうミニスカなんてガラじゃないけど、
そんなことしたら、
そんな適当なことを言ってたら、
恐るべし春！！！
そう言えば、
あれって、当時IBMの一歩先行くために
ふーん。
そんなことより、
桜が咲くのももうすぐだし楽しみね。
桜餅の葉っぱって食べる派？食べない派？
私は食べてもいいもんだと思ってたわ。
きっと正確なのが導き出せボッシュートされるはずよね。
うふふ。
お店を変えてみたわ。
手軽に歩きながら食べれるのがいいわね。
すいすいすいようび～
今日も頑張りましょう！
皆さまはチームワークがいいと聞くと
「誰かがミスを犯しても、周りのみんなが助ける」
なんて考えるのではなかろうか？
浅薄だな〜、本当のチームワークはそうじゃない。
と思ったあなたは一流。数々の修羅場を乗り越えてきた老練家ですな。
本当にチームワークがいい組織は、
みんなに迷惑がかかるという使命感を背負っている人間が集まっている状態こそ、
チームワークがいいというものだ。
例をあげるとDeNA。チームワークがよろしくない。
チームワークは乱れない。
各々がお互いの力を信じている。
世間的にはDeNAのほうがチームワークが良いと思われがちだが、
じっさいのところはGREEに軍配があがる。
中日と同じで今は低迷しているが、あの手の組織はいつか這い上がる。
それでも任天堂の壁は厚い。ニンテンドウ チームワーク クッキョウナリ
あの映画の中にはチームワークの全てが詰まっている。
シルヴェスター・スタローン、ジェイソン・ステイサム、ジェット・リー、ブルース・ウィリス、シュワルツェネッガーと主演級の俳優が同じチームのメンバーとして登場する。
そして彼らは皆一流。最強のチームワークを誇る。
この名だたる企業コンソーシアムのチームワークは最悪。
https://www.google.co.jp/maps/place/@35.6386097,139.6999833,521a,20y,41.58t/data=!3m1!1e3!4m5!3m4!1s0x60188b48682c837f:0xa07320890573c72c!8m2!3d35.6427516!4d139.6999923
みずほ銀行PJの陣頭指揮を取っているはずのみずほ情報総研、開発拠点は全国にありますがその中でも有数の規模を誇るのがこの中目黒です。
毎日夜遅くまでフロアの電気が付いているそうですが、大変ですね。
Google Mapで見ると室外機が沢山載っている、まるで要塞のような建物が見えると思います。
ここはみずほ銀行のシステムの中核をなすデータセンターの一つです。
IBMのメインフレームが沢山入っていたそうですが、今後はどうなっていくのでしょうか。
ちなみにこの建物、建築業協会賞を受賞しているそうです。かっこいいですしね。
中目黒センターの南にある、駒沢通りに面したちょっと変わった形のビルが秋元ビルです。
ここの数フロアをみずほ情報総研が事務所として借り上げています。
みずほ関連の怪文書で中目黒という単語が出てきた場合、中目黒駅近くのみずほの建物ではなく
秋元ビルと中目黒センターの間には、自販機と灰皿が設置されているのですが
朝の九時頃には首から「MIZUHO」のカードキーを下げた方々が大勢喫煙されています。
どんな立ち話をしているのか、気になりますね。
次回は多摩が出来たらいいですね、では。
なんと自宅に居る時間は5時間だけ？継続してたらデスマーチよ。
法律守って作業者が自宅に9時間いられるようにマネジメントするのがお仕事。
（鎮火の初動は、終電まで働かせといて健康管理は自己責任とか言う人の排除から）
というわけで、みずほ銀行が最近また話題になったので、振り返ってみよう。
で、記憶に新しい2011年の東日本大震災システムトラブルの影響で、
システム刷新して再発防止するぜ！というのが2012年スタートの話。
みずほコーポレート銀行にみずほ銀行が吸収合併されて、
はい、クソメンドクサイですね。
しっかし、この合併って超ややこしくて
とか並べると、ウワー関わりたくね－って判るでしょ。
今のみずほ銀行は、旧みずほコーポレート銀行なので、旧富士銀行なのね。
法人格（法律上の会社人格）も、SWIFTコード（世界的な銀行識別番号）も、旧富士銀行のを使ってる。
でも、日本国内で使う統一金融機関コードは、旧みずほ銀行で、旧第一勧業銀行で、旧第一銀行なのね。
なぜなら、旧第一銀行の統一金融機関コードは0001で、旧富士銀行が0003だから。
しかも、元みずほコーポレートたる興銀は企業向けメインで、元みずほ銀行は個人向けがメイン。
AKBと宝塚歌劇団が合併したみたいなもんスよ。そりゃ一歩も引かないわな。
という政治的決着を経て、
外向けに儲かってるところは興銀の日立
（全銀システムはそもそも開発保守をずっとNTTデータがやってるんで、そこしかやるところがないという）
そして三菱東京UFJ銀行の開発はちゃんと終わりました。あそこも無茶やりました。
旧UFJは派閥抗争で完全に疲弊しきった所を、天下の三菱御三家、東京三菱銀行が救済しました。
だから、旧UFJ系（日立）は「実利で残した」という形で、東京三菱側(IBM)が完全にコントロールしてた。
主導権が完全に旧東京三菱側にあるので、旧UFJ(旧三和銀行)がなんか言っても鼻で笑われるレベルね。
つまり、クライアント（依頼主）側の命令系統がキッチリしてるかどうかが全て。
家を建てる時にさ、大工と左官職人と配管職人とガラス屋と設備屋が居るから完成しないとか、無いでしょ。
それぞれの職人にそれぞれの指示をして、結果として一つの建物ができるのはそんなに珍しく無い。
（もちろんちゃんと連携しとかないと穴空いてないから換気扇付けられんとかあるんだけど）
だもんで、日本IBMのプロジェクトマネージャーに全権委任して、組み直せば終わるよ。
みずほ銀行内の揉め事は、全部林さんがOK／NG決めて、IBMのPMが采配して進める。
要は、クライアント（依頼主）側の意思統一ができていないのが一番の問題。
これは、ベンダーがーとか多重請負構造がーとか、そういう問題じゃない。
第一勧業銀行と富士銀行と日本興業銀行の合併が終わってないのが問題。
（外面の話じゃなくて、内部的に一つにまとまってるかってことね）
自社もまともにできてないのにSIとか臍が茶を沸かすぜ。
みんなコダワルねぇ。
ヤヤコシイということだけ判ればエエのに。
とするじゃろ
/*合併前の法人格リスト 第一勧業銀行, 富士銀行, 日本興業銀行*/
社名変更(みずほ銀行, 吸収合併(吸収合併(第一勧業銀行, 会社分割（富士銀行, 富士リテール）), 吸収合併(新規設立(みずほ統合準備銀行), 会社分割(日本興業銀行, 興銀リテール))))
社名変更(みずほコーポレート銀行, 吸収合併(富士銀行, 日本興業銀行))
社名変更(みずほ銀行, 吸収合併(みずほコーポレート銀行, みずほ銀行))
第一勧業銀行が第一銀行から来てることは知らなくて良いなんてコメントは甘い甘い。
日本では古いほうがエライ。それは実にシンプルに帰属意識や誇りに結びつく。
今をときめく日本銀行よりも第一銀行(第一国立銀行)の方がエライのよ。
よしもと新喜劇とAKBと宝塚歌劇団が合併したみたいな話に例えると
「じゃあそれで」
「えぇ……」
「しないだろJK」「含めるに決まってるだろ？」「千秋楽だけ生花は衣装扱いで」
「えぇ……」
「どうかな？公演の日取りは決まってるけど」
「「「おおむね順調です！」」」
（三行で正確に知りたいってのは業腹ってもんだ）
anond:20160426124418 と anond:20160426145507 の続きだゾ。てか長えよ
(略: トークンが定期的に期限切れになるので可用性が下がる。たとえばビデオカメラから複数の動画をアップロードしている途中で切れたらムキーってなる。再認証して途中からできるのもそれはそれで CSRF の温床。AFCP のような場合は期限切れがあってはならないので、パスワード等を預かる認証プロキシの SaaS アプリを筆者は作った。好評だったが、これはもちろん本来あるべきでない欠陥のexploitのはず。)
(略: 個人ユーザ向けのAPI設計ばかりで、雇用者や上司がアカウントを管理するという観点がない。SAMLでは普通にできるのに、OAuthとなるとセキュリティ的に云々と言って拒むサービスばかり。別のUIで既にできてることをAPIにしても意味がない。これまでできなかったことをAPIで可能にするのではなく、単なるシングルサインオンでよければ他にある。実際Googleは個人向けにはOAuthを活用しているが、Google Apps for BusinessはOAuth以外のシステムを使っている。)
(略: 主要な設計ミスは、外部サービスすべてを同等に疑うところ。管理者が各サービスの信用性を判断して権限を調節できるようにしないところ。これまでどれほど多くの製品がOAuthの面倒さのために失敗してきたことか。)
ここまでで「普通の実装における」OAuth がまったくおかしいということはわかりましたが、OAuth が実際うまくいくのはどういうときでしょうか。
初期の OAuth 規格および概念におおよそ付き従っているシステムは一般的に言って、新しい規格ベースのよりもセキュアで、マシです。OAuth 1.0 の実装がすべてセキュアだというのではありませんが、たいてい問題は少ないです。こうしたシステムは通常、次のふたつのアプローチのどちらかに従っています:
とはいえ、このように設計されている OAuth ベースのシステムはごくごく希少で、しかも一般的にこうしたシステムは、他のところで使われている OAuth とは似ても似つかぬものです。OAuth 1.0 規格の方に寄って頑張っていますが、公式には 1.0 は非推奨ですから、こうしたアプローチを使っているシステムはそのうち「アップデート」されて OAuth 2.0 の概念や追加機能すべてを加えて再構築され、セキュリティやユーザビリティをだめにしてしまうことになります。これこそ筆者があらゆる OAuth ベースのものを見逃したくない理由です。もっと古く、もっと機能的な形式の OAuth を使っていても、システムに「改善」が必要だという素敵な考えを管理者のだれかが閃いて台無しにしてしまうからです。ご迷惑をおかけしてすみませんと言うぐらいなら、まったく別のものを使うほうが良いですよね。
他に手はないかと探すとき、人々はよく他の「フレームワーク」にはどんなものがあるかを知ろうとします。しかし、考え抜かれたセキュアな設計を実現するためには必ずしもフレームワークが必要というわけではありません。現状、OAuth とはどのようなものかについての意見はサービスごとに異なっていますので、承認の具体的な動作の仕組みもまったく一定ではありません。そんな中でフレームワークを探しまわるのは、簡単にできることをいたずらに複雑化しているだけのことが多いです。唯一ほんとうに難しい要素、しっかりした規格の必要な要素は、使用する鍵パラメータの改竄を防ぐため変数に署名する方法だけであり、この点に関して、ほとんどの OAuth ベースの実装は一切何もしてくれません。
ウェブサービスの最大手である Amazon は、世界中の企業にサービスを提供する一流プロバイダで、合計 30% 以上という途方もない市場シェアは他者を圧倒しています。Amazon のアプローチは、自分でアプリの認証情報を生成できるコントロールパネルへのアクセスを、すべてのアカウントおよびアカウント管理者に提供することです。この認証情報で、どの Amazon サービスで作業できるか、そのサービスでどの操作を実行できるか、どの権限で作業しなければいけないかを指定できます。この認証情報は必要に応じて「アカウントホルダ」の人が破棄することもできます。
Amazon の API における認証や承認技術には、本質的に制限が多く潜在的に危険性のあるリダイレクトを一切必要としません。Amazon のプロトコルで認証情報は、直接送ることは一切なく、データの署名に使うのであって、これでブラウザを通してパラメータを送る必要のあるときにも改竄不可能にすることができるのです。
Amazon の設計はアカウントの利用状況を API の利用まで適切に把握できますし、API の認証も承認もすべて Amazon 側からスタートし、その際のアプリ認証情報も「Amazon の」コントロールパネルから生成されます。この認証情報はその後、いかなるトークン交換システムも使わず直接 API プロセスで使われます。この設計なら「普通の実装における」OAuth が達成している真のセキュリティ目標をすべて達成し、かつ前述したセキュリティ上およびユーザビリティ上の問題をすべて回避しています。
ひとつ言及せざるをえない短所は、Amazon の権限システムが幾分わかりにくく、あまりユーザに優しくないということです。ただし、このことは何故かほとんどのコントロールパネルにも言えることで、いずれにせよ UI 設計の問題であって、承認プロセス自体の失点ではありません。さらに、Amazon のコントロールパネルはかなりキビキビ使えて、それ自体の API でも使えます。この点たとえば Google の場合のように、筆者の知る限りメタ API もなく、何をするにも何十もの手順が必要なのとは大違いです。
Amazon の認証および承認メソッドは他のサービスプロバイダにも幾つかコピーされています。Google 自身も企業向け製品の一部でこれを利用できるようにしています。Google 自身、純粋な OAuth 設計は企業サービスに向いていないことを認めており、企業サービスには JSON Web Tokens (JWT) の利用を推奨しています。
JWT はサービス間の SSO や API 利用を可能にする規格です。多くの点で JWT は SAML に似ていますが、SAML はややこしくて、XML Security (名前と違って、まったくセキュアではない) の上に構築され、API 利用に向いていないのに比べ、JWT は SAML の主要な目標を、単純かつ使いやすい方法で一切の面倒なく達成しています。HMAC 実装をひとつ用意し、JSON の構築と解析の方法を知っておけば JWT は使えます。既製品をお求めでしたら、膨大な JWT ライブラリが既に存在していますよ。
ただ Google の場合、典型的な JWT 利用法よりも高度で、HMAC のかわりに、もっと高度ですがこの分野では人気の低い RSA デジタル署名を利用するよう要求しています。Google のコントロールパネルではアカウント管理者が自分の企業サービス用に新しい鍵ペアを生成でき、API ログインを署名するために使う秘密鍵をダウンロードできます。こちらのほうが HMAC よりセキュリティは高いですが、Google はプロセス全体を本当に無駄に複雑化しています。コントロールパネルをしょっちゅう完全に再設計して、前と同じことをしたいのに使い方が違っていて混乱する点は言うまでもありません。JWT 利用の実例が必要なら他をあたるようお勧めします。
他に使われている技術は、サードパーティがどんな権限を必要としているかをある種の XML や JSON ファイルで定義してウェブサイトに送信できるようにするサービスのものです。ユーザがあるページを自分のアカウントで訪問し、ファイルの URL (あるいは中身) をそこに貼り付けると、その外部サービスあるいはアプリが求めている権限の一覧やそこに含まれる説明などが表示されるようになっています。それを見て認可したいと思うユーザは、認証情報を生成してそのサードパーティのアプリあるいはサービスに貼り付けます。ユーザは後で無効にしたくなったら認証情報を破棄することができます。これも、開発者におかしな負担を強いることなく、すべてのアカウントに API サービスがあり、権限管理を備え、サービス自体からフローが始まる、実にセキュアな設計です。
承認管理のためにサービス側から提供してもらう必要が本当にあるのは、適切な役職 (管理者やアカウント所有者など) を持つユーザが自分に割り当てられた権限や (望むなら) 期限を持つ認証情報を API 利用のために生成できる何らかのパネルだけです。こうした認証情報はその後、お好みのセキュアな認証システムを通して利用することができます。たとえば HTTP Basic Authentication over HTTPS のような単純なもの、これは事実上どの HTTP ライブラリにも入っていますし、HTTP Digest Authentication、これはもっとセキュアでありながらほとんどの良質なライブラリでサポートされていますし、その他 HMAC, RSA, 楕円関数など認証情報をネットに通す必要のない暗号学的テクノロジーを活用した認証プログラムに基づくものなら何でも使えます。特に HMAC は、承認や認証を実装するほとんどすべての人 (Amazon や、一部の OAuth 実装も含む) によって既に使われています。
こういった種々の実績あるテクニックは、セキュアなプラットフォームを作るために CSRF 対策など複数のフレームワーク同士の相性を勉強する必要があるという重荷を軽くしてくれますし、一般的に、既存アーキテクチャにワンタッチで装着できるようなモジュール化の実装が可能です。ユーザやアプリの認証情報が盗まれる可能性をなくしてくれます。ややこしい CSPRNG を常に使用する必要もありません。このようなシステムは OAuth の生まれるずっと前から存在しており、現在でも一般的です。OAuth は、ユーザの認証情報を要求したり他に弱点があったりするような一部の劣悪な設計のシステムよりはセキュリティが良いかもしれませんが、既にある真の設計を置き換えるものではありません。OAuth が解決すると主張する問題点は実のところ、既存の良く設計されたシステムには存在していませんし、「普通の実装における」OAuth は実のところ、解決すると主張する問題の多くを招き入れるばかりか、最初は存在していなかった問題まで生じさせています。宣伝文句と違って、OAuth にすれば自然と驚くほどセキュアになるというわけではなく、むしろ数々の短所や実装の困難さを考えれば、他の考え抜かれた選択肢のほうがはるかに優れています。
これからサービス設計をして API アクセスを提供することになっている方はどうか、ご自分が実現しようとなさっているのが何なのかを本当に考えてください。他の人がやっていることをコピーするだけで済ませたり宣伝を丸呑みしたりしないでください。どうしてもコピーしなければいけないなら、Amazon (これが最善です) や Rackspace, IBM SoftLayer, Linode, VULTR, Zoho, Zoom ほか、API の素直で健全な認証システムを構築する方法について現時点で多少なりとも理解のあるところをコピーするようにしてください。
2016 年 4月 Insane Coder
元の話も
「赤ちゃんを同伴してIBMが開催したテクノロジーコンファレンスに参加した」
ってだけだしね。
写真を見る限り赤ちゃんはまだ低月齢（首は座っているが激しく動く事は出来ない、3～6か月くらいと思われる）だし
それくらいで大人しい子なら授乳時間とおむつ替え場所さえ確保出来れば
抱っこでコンファレンスで話を聞くくらいなら出来るさ。
でももっと大きくなれば下に降ろせ動きたいと騒ぎ出すし
下に降ろせば好き勝手に暴れるから親がつきっきりで見てないと無理。当然仕事になんてならない。
言葉で聞こうとするのが間違い。
自分の場合、「自分で調べ物しますか？」客「Yahooとか見るわね」→「いつもYahoo!とか見るソフトを開いてください」→ブラウザ判別が必要な場合「画面右上にはバツ印がありますよね？ その下には何がありますか？」という風に聞く。
Chromeなら「横の三本線」になるし、edgeなら「・・・・」になる。
そういう風に、ブラウザごとに明らかに違う場所を複数覚えておいて、
右上や左上はじといった風に誘導しやすい場所から、見えているものを教えてもらう。
そしたら、向こうは見えているものをいうだけ、それでこっちは何のブラウザか分かる。
もうちょっと頭を使うんや！がんばれ！
http://blog.livedoor.jp/itsoku/archives/47616816.html
とそのブックマーク
http://b.hatena.ne.jp/entry/blog.livedoor.jp/itsoku/archives/47616816.html
をみながら思ったんだ
要約するとアメリカは時給１２万円のコーダーの仕事があるらしい
そんでとうぜんにほんじゃそんなことないという流れで
日本はハードばっかりにこだわってソフト軽視だという（まぁそうだろうね私もそういう印象あるよ）
なぜか、このスレの連中（名前からしてビジネス＋）は、文系のせいにしたり大企業のせいにしたりする
このまとめをまるまる信じるとして思うことがある
一瞬なるほどそうなんですかって話になりかけたが
そしてHPやDELLなどのハードにこだわっていろいろ大変なことになってる会社もあるわけだが
なにが言いたいかって、べつにアメリカもその点では変わらないじゃんってことだよ
じゃあなにが違うのかって
理系がベンチャー立てて、googleみたいな企業立ち上げられるかどうかだよね
それだけの話だよね
そこだけが違う
理系（）がベンチャーでgoogleとかほかのIT企業立ち上げたら話は終わるんだよ。amazonでもいいしoracleでもいいし、あとなにがある？あんましらないけどねｗ
もちろんそれが一番難しくてできないから、理系（）のルサンチマン馬鹿どもは文系のせいにしたり、企業のせいにしたりしてるんだろうけどｗ
アメリカだって恐竜って言われてるGEとかIBMみたいな旧態然とした、大企業ってのもありつつベンチャーでITが盛り上がってるわけだからさ
アメリカ人がGEとかIBMのせいにしてるわけじゃないでしょ（まぁそもそもGEもIBMも利益率かなりいい優良会社だけどね）
ようするに能力のないバカが2chで騒いでるんだろうってことが言いたいんだけど
この２ｃｈまとめみたいにルサンチマンやってるダサい連中じゃなくもっとまっとうな理由ってないのかなって思ったわけですよ
日本にはこういう問題があるんだってのがあるんだったら教えてほしいとおもってね
そもそもなんでこの手の奴らって文系理系でわけるのかね。もっというと理系側がわけたがってるよね。お望み通り理系でわけてやったんだから理系の皆さん返信よろしく
就活の参考にしたい
http://anond.hatelabo.jp/20160123172824
博士号歓迎で独自技術を持っている会社なんて海外にはごろごろあるよね。国際機関とか大学とか除いても。給料八百万円(７万ドル弱)なんて低すぎると思う。
例１ エンジニアより：
MathWorks（Matlab作っている会社）物理モデリングシニアエンジニア
条件：
ー 非線形で相互に接続されたシステムの定常状態および動的状態のモデリングおよび計算技術の経験
ー 工学、数学、コンピュータサイエンスの修士号もしくは博士号取得
例２ SAS institute（分析ソフトウェア世界1位 SASを作っている会社）
http://reviews.greatplacetowork.com/sas
ワークライフセンターには、正社員のソーシャルワーカーが複数在籍しており、さまざまな教育やサービスを従業員とその家族に提供している。図書館を併設。子供の教育、大学、介護、離婚、シングルマザーなどの状況をサポートする社員相互のメンターのネットワークを提供。
フィットネススタジオには、５０メートルプール、エアロビスタジオ、マシーン、バスケットコート、ランニングトラック、ソフトボール場、サッカー場を含む運動施設がある。年に１５００のスポーツプログラムを提供。マッサージサロン、美容室、ネイルケア、スキンケア、ジュエリー修理、靴修理、その他のサービスを割引価格で提供
例３ 研究者より：
Mathematica政策研究所 国際研究者（International Researcher）
条件：
ー 様々な状況で技術的な話を明快に説明するための、極めて優れた英語でのスピーキングおよびライティング能力
私はどちらかというとデータアナリストで、SIの本流から外れるけど、SI本流でもそれこそシリコンバレーとかに技術を持った会社はうじゃうじゃあるんじゃありそう。IBMの研究所とかでもよいだろうし。
久しぶりに『批評空間（ http://erogamescape.dyndns.org/~ap2/ero/toukei_kaiseki/ ）』を覗いてみたのですよ。
いやぁ～ 昔と変わりませんなぁ。
ノベルゲーだからテクノロジー上の大きなブレイクスルーがないのを割り引いても、ゲーム内容・ファンの意識には往年を偲ばせるものがあります。
まず物語のパターンが古典落語や歌舞伎並にテンプレ化されてるじゃないですか。
パーツの組み合わせが変わってるだけなんですよね。GoogleのDQNやIBMのワトソンでもシナリオ書けそうです。
次、ユーザー層。
ゼロ年代くらいのファン層がまんま繰り上がってオッサンになっている印象を受けます。
発売日の延期、修正パッチをネタにして騒げる人たちなんかは、ワシントン条約で保護すべきでしょう。
エロゲ界隈は真性オタの牙城と言いますか、原理主義者の聖域のままであってほしいですね。
電車男以降、オタクがライト化するのに抗して生まれた"キモオタ"概念が近年ベタになりつつあるのは懸案事項であります。
『オタキング→ダイエットに成功したサブカル博士→家族をシェアするイロモノ』というキャリアを"詰んで"しまった岡田斗司夫には失望しました。
経産省の旗振りのもと、AKBや深夜アニメと一緒に『クール・ジャパン by 秋元康』なんていうプロモーションされたら海外のファンコミュに亡命します。
