「ミドルウェア」を含む日記 RSS

はてなキーワード: ミドルウェアとは

2020-05-18

先に言ってよー

ミドルウェアバージョンあげたらアプリケーションが動かなくなった。

不具合から何とかして。

じゃねぇよ。

大事な事は共有してからしろよ…

相手情シス暇なのか何なのか知らなけど、見切り発車で進めんなよ…

「そんな時間かかりますか、ここに問題があるんじゃないですか?(キリ)」じゃねえよ。

こっちはさっき叩き起こされて、状況聞かされてんだぞ。

おまけに、年に1回あるかないか案件半年動いてないし、PCも新調したか環境づくりだってできてねえんだ。

それに会社からじゃないとサーバーアクセス出来ない。

…やるしかないんだけどさ…。

2020-02-19

anond:20200219231014

それはないで?

マシだったのは気になる木とミドルウェア会社かな

あとベンチャー

でもベンチャー死ぬ

2020-02-05

anond:20200205090314

中国は入るかな

ワイ的には逃げ出したくなるハイレベルミドルウェアエンジニアがいつもボロを纏ってたは

身嗜みに興味がないのではなくむしろきっちりしてる。高給取りなのに単純に金がないのだ

どうしてそうなっちゃっているのかというと中国親族支援し続けているからだ

彼が日本にこれたのは優秀な彼なら現状をなんとかしてくれると親族一同で金を出し合ったかなのだ

なので稼げるようになったからそれを返すのは当たり前のことなのだそうだ

あとはベトナムフィリピンインド/雑にイスラム圏(インドネシア、イランイラクパキスタン)

せっかく大学出てそれも理系で、トライリンガル、マルチリンガルだったりするのに、

米国日本傘下のクッソどうでもいいオペレーション業務従事してたり、日本に来てどうでもいい仕事をしてたりする(学んだことが活かせないどころのレベルではない)

プライド死ぬけど彼彼女らの国ではこの給与を得られるは恵まれている部類なのだ


そこにきてただ日本ってだけでワイなんか英語ですらできないのに、彼らの何倍もの給与を貰っているんだもの

頑張らなきゃなってならなきゃ嘘やろ

2020-01-23

標準に則らない

ベストプラクティス技術標準、技術に限らない分野でもやり方の基準みたいなものは有ると思うけど、そういうもの無視して自己流を貫き通す人の行動。

たとえば、採用事例が少なすぎて誰も触ったことがないフレームワークライブラリなら、「ああ、うまく作るために苦労したんだな」という気持ちにもなるけれど、十分枯れたミドルウェアの設定とかがそうなっていたりするとSAN値が削れる。

あとから触ったときに、なんでこんな実装になってるんだろう…というものがあったときに、引き継いだ人間はその理由から想像しなければいけない分だけ、ロスが大きい。そもそも読み解けない場合もある。

担当者がいなくなっていて聞けない場合もあるけれど、まだ残っている場合になぜそうしたのかと問うたりする。すると、「急いでたから」などという理由が返ってくるのだけど、急ぐときこそ標準に従ったほうがスムーズなのでは?という感想しか持てない。そもそも急いでいたから、って時間あるときに直してないじゃない。

実際にその完成にどれくらいの時間がかかったのかは、当時のことを知らないか判断は出来ないけど、思ったよりスピード出てなかったのでは?という想像も出来る。

そういうものはえてして、技術負債として残ったりする。結局損害の方が大きくなったりする可能性があるのにそういうことをやるのだろう。

…と思って、「このやり方だと技術負債になりませんか?」と尋ねてみたら、「バグがないか大丈夫では?」と返ってきて、技術負債というものへの意識の差を感じたりもして悲しみ。

2019-09-14

後出しじゃんけん

隣の部署障害を起こした奴がいて、なかなか上司に詰められていた。

よく知らないミドルウェア保守で、なんとか調べて手順作ってやったけど、現場トラブルで手順が狂い、障害を起こしたらしい。

上司はなんでそんな大切なファイルを消すんだと詰めていたが、それって後出しじゃんけんだわなと思った。

原因調べて、実は大事ファイルでしたと。

なんでそのファイルを避けるようにしなかったのか理解できないみたいな感じの話をしていた。

いや、お前、その事知ったのはその障害があったからじゃん。その重要度が高いの分かったのはホントに詳しい人に確認たからやん?

多分、上司も客に説明するためにそういう言い方してるんだろうけど、理解不能みたいな態度とんなよ。

責めポイント見つけるまで聞いてたお前の質問初心者レベルからな?

2019-09-12

おじさんSE(運用保守)が本当の地獄

QiitaでバズってたおじさんSE設計ができるし全然マシだと思う

・手順書が無いと何もできない、手順書に書かれていることの意味を考えない

マイナー言語ミドルウェア独自フレームワークを使ってることに何の違和感を覚えない

プライベート勉強という概念がない

SIer運用保守ってマジでこんなおじさんたくさんいるぞ

そういう人達マネジメントの適性も無いか高齢になるとヘルプデスクとかで働くらしい

Webエンジニアとは一生交わらない存在

2019-08-10

クチコミサイト運用しているエンジニアだが限界かもしれない

現場でなにが起きているか

ディレクターサイドが大きいタスクを嫌がる工数が足りないと騒ぐ

リファクタしようにも軽微な改善を積まれまくって開発ができない

一個改善をしようとすると経営会議承認を得ないと行けない

デザインが明らかに古い

イベントを行うもイベントが終わるたびに燃え尽き症候群エンジニアがやめていく

開発の経営陣は古いシステムをどうしようという話に一切口を出さず新しいシステム機械学習に夢中

クローズするサービスを残し続ける、保守しなければ無料じゃねーんだよ

裏側でなにが起きているか

最後サーバーセキュリティアップデートしたのはいつだろう

ソースコードカオスなことになっている

仕様理解している人が誰もいないことが稀によくある

DBパンパン、使われていないテーブル多数あるけど怖いので消せない

CTO直下のチームは飽き性で色々なフレームワークを開発し運用チームに渡しまくるせいでもうぐっちゃぐちゃ

マイクロサービスを無理やりしたせいでバージョン違い、ミドルウェアの違いなどで更にカオス

DDDとか会社で誰も回せないし正常に導入できていないのに、推し続ける謎行為(俺たちは勘でDDDをやっている)

どうするべきか

主要なサービス新規事業サービスを乱立するのは良いが、損益点をはっきりさせて撤退する勇気を持つ

24/365は諦めて、24/365のための議論をする

オンプレはもう限界だよ、オンプレでもいいけどサーバー構築を1h以内にやってくれ頼む

大規模なリファクタリングを行うために経営陣は今の現場限界に気づいてくれ、株価見ろよ利益率悪いのが丸わかりだろ・・・

機械学習やってる場合ですか?

自分たちは弱いことを認めて改善をしていけばいい、全員やめろとは言わないけどもっと運用チームの一番下と経営陣がしゃべる時間を作って生の声を聞いてくれ

人事に言いたい

エンジニアイベントごとに巻き込むな、全部任意イベントにしてくれ

エンジニア営業を同じ制度ワークフローで処理するのは限界ってことに気づいて

会社お金の使い方見直しません?その社内イベント本当に必要ですか?

あぁ^~リモート環境ないので障害起きたら出社しなきゃいけないんじゃぁ^~

2019-07-27

(Web)エンジニア転向について

知り合いと飲んだら、過去の私と同じような状況であの日々を思い出して吐き出したくなった。

当時私が参加していたチーム・プロジェクトは美味しそうなFWを使っていた。

サーバサイドのエンジニアは片手ほどの人数で、採用時点でそのFW経験があることを確認されていたし、別チームから転属してきたメンバーも何らかのMVCWSGIFW経験があり、わりとサクッと順応していた。

前職では業界経験だったり、経歴を盛っていると思われるエンジニアもどき仕事していたので、普通に公式ドキュメントを読み、FWソースコード確認することができる同僚との仕事はおもりがなくなったようで気楽だった。

3年前の夏、サーバサイドのチームに新人のN氏が加入した。新人と言っても別チームから来た年上の業界経験豊富インフラエンジニアである

プロジェクトクラウド化や縮小が当時の1年半ほど前から進んでいて、社内のインフラエンジニアはSREに名前を変えるような流れがあった。(実際にはインフラミドルウェアネットワークに長けた彼らは相変わらずそれなりに仕事があったようだが)

その流れの中でN氏は、サーバサイドエンジニアをしてみようと決めたらしい。転向については1年前から部長相談していたとのことだった。しかも、うちのチーム名指しで。これはちょっとしかった。

さっそく、N氏には社内向けの新機能担当してもらい、私がレビュー担当になった。

これがなんというか読むのが辛かった。確実に言えるのはチュートリアル絶対やってないということだった。

機能は満たすが、FWの書き方やお作法については部分的にググった結果がパッチワークされているような。

社内の各チームのアーキテクチャエンジニアならだれでも知っていた、つまりN氏は知っていながら特に準備なしでやってきたわけである

そこから始まる、レビューを通した実プロダクトを使ったチュートリアル。褒めるとこは褒めて、受け入れられないところは参考になる実装ドキュメント提供する。

はじめからチュートリアルを一緒にこなした方が良かった。レビューで大幅に書き換えてもらうのは結構辛い。勿論プロダクトに使えるレベルコードじゃないから仕方ないんだけど。

しかもN氏、臭いである。脂汗を吸った服、毎日履いてくるジーパン、脱いだのが瞬時にわかるほど臭う靴。

当時は Visual Studio Live Share なんて無いし、ペアプロは5分で限界だった。

がっつり書き直しが入るようなコード卒業には2ヶ月ほどかかった。(これは私が時間を十分にとれなかったのも悪かったし、N氏は前のチームの引継ぎ作業も並行していたので)

もう、色々思い出して悲しくなったから書いとくと

ちなみに知り合いのところは、最近の天気のせいなのか生乾き臭マックス縁故入社新人とのことで、当時彼にしてもらったように「ガンバ」と背中叩いておいた。

N氏は今も臭っているようだが今は別プロジェクトだ。スキルセットが増えている分、頼れるエンジニアに近づいたのかな。喉元過ぎればなんとやらで、忘れていた。

最近は私が別チームから支援できた若手のフロントエンドエンジニアレビューしてもらっている。

チュートリアルこなして、書籍記事を読んで手を動かしたうえで相談をしながら実装を進めている。あんまりものは見せられない。

新しいスキルセットは必要になる。

人に教えておらうにも、ある程度は自分勉強しないと適切な質問が出来ない。

ある程度が分からないなら、公式資料書籍、有志のページを当たろう。

2019-07-22

Web業界エンジニア転職するときにチェックしたほうがいい点のメモ

求人資料を見るだけじゃなくて、可能な限り、直接面接で聞いたり、中の人に聞いたほうがよい。

Developer Experienceてきなところっすね。

バックエンド系なので、フロントエンドのことはよくわからない。

給料とかは当然見ると思うので省略)

Windows以外の開発PCを使えるか?

Windowsが悪いという話ではなく、WIndows以外の選択肢MacLinux)を選べるというのが大事

Windows縛りのところはだいたいろくでもない。

リモートワークができるか?

リモートワークが好きってわけではないんだけど、台風の日とか出社しなくてもいいのはありがたい。

あと、リモートワーク可な職場は、非同期コミュニケーションが発達していて、エンジニアとしての仕事がしやす可能性が高い。

ASP/SaaSがどの程度使えるか?

例えば、Github Enterpriseじゃなくて、github.comが使える、とか。ASP/SaaSがどの程度使えるか、ってのは、セキュリティがめんどくさいかそうでないか試金石として有用

Oracle RACを使っていないか

Oracle RACを使っているところは経験上、結構がちがちな開発スタイル可能性が高い。

言語処理系バージョンミドルウェアバージョン

古いRubyとか、古いMySQLを使い続けている職場は、そもそもまり技術に関心がない可能性が高い。

エンジニアブログ

エンジニアブログが無いのは論外(いい会社かもだけど、外からわからん)、あと更新頻度、更新者のプロフィールちゃんと出してるか、など。

更新者のプロフィールちゃんと出している会社は、中の人間の対外発表をそれなりに推奨(黙認)していると想像できる。

その他

本気で転職考える時は、他にもみる観点あるけど、1次スクリーニング的なところだとこんな感じ。

2019-07-06

7payのセキュリティ審査って何をやってたんだろうか

ここ連日騒がれている7pay。

パスワードリセットリンク送付先のメールアドレスに対して設計上の問題脆弱性が発覚して大変な事態に発展しています

昨日の会見では社長ITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています

また、会見内で「セキュリティ審査実施した」と明言がされました。

https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html

セキュリティ審査実施していたにも関わらず、何故今回の問題が見逃されたのか。

非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います

セキュリティ審査とは

その名の通り、サービスローンチ前に実施する、脆弱性問題がないか審査の事・・・だと解釈しました。

審査」というとISMS辺りを連想しちゃいますね。

一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます

以後脆弱性診断と記載していきます

実施した」とはいっても、どういった内容を実施たかはわかりません。

ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチ脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います

通常、脆弱性診断というと、以下のような項目があげられると思います

抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います

詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています

LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティスプラウトなど。

ただ、今回の脆弱性診断が外部ベンダ実施されたのか、内部で実施されたのかはわかりません。

以下、推測をつらつら書いていきます

外部ベンダ発注したが、コスト削減のために対象を削りまくった

脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります

Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます

また、数量計算ベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。

お願いすれば見積もり時にステージング環境で動いているWebサービスクロールして、各ページの評価を付けてくれるベンダもあります

規模と見積もり内容にもよりますが、100~200万といったところでしょうか。

スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万~100万程度でしょうか。

プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います

これ以外にWebSocketを使っていたり、別のサービス連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります

Webサービス200万、スマホアプリ(iOSAndroid)100万*2、プラットフォーム100万とすると、500万円掛かるわけですね。

脆弱性診断をするだけでこれだけのお金が吹っ飛んでしまうわけです。

そしてこれをそのまま発注するかと言われると、多分しないでしょう。

セキュリティお金が掛かる割にリターンが少なく、目に見える結果が必ず出てくるとも限りません。

経営層は中々首を縦には振らないでしょう。

会見でも明らかになったことですが、社長ITリテラシはあまり高そうにありません。

こうなると脆弱性診断の稟議を通すのは中々容易ではなかった可能性もありそうです。

また7月1日に間に合わせたようなところもあるっぽい(?)ので、開発側に資金を全振りしていた可能性もあり、診断に費用を掛けられなかったのかもしれません。

いずれにせよ、全く実施しないのはまずいし重要そうな部分だけピックアップして実施しましょうという話にはなるでしょう。

削れるものをあげていってみましょう。

例えば、iOSスマホアプリ実施しなくても良いかもしれません。iOS上で動くアプリは確かサンドボックス構造になっているはずで、ローカルに何かしらのデータを持っていても外部からアクセスは基本不可であるためです。確か。

そもそもスマホアプリ自体不要かもしれません。7payのサービスへのアクセスインターフェイスとしてのアプリしか提供していないのであれば、取り扱うデータほとんどないと考えられるためです。そのため、スマホアプリAndroidのみ、もしくは両方実施しなくても大きな問題は発生しないのではないかと思います

・・・この辺り私の勘違いというか、「最優先でやるべきだろjk」といった考えがあれば指摘ください。

プラットフォームも、ベンダによります実施しなくとも良いとも思います

ベンダ説明でも、主にポートスキャンをして、空いているポートに対してtelnetで色々したりするといった説明がなされたと思います

Webサービスなら443と、空いていても80くらいしか外部には公開していないので、これは実施しないという選択をしても不思議ではないと思います

サーバコンフィグも、DocumentRootがおかしいとか致命的な設定ミスをしていない限りは見てもらう必要はないでしょう。

そもそも構築手順等はノウハウもあるでしょうし、わざわざ見てもらう必要性はほとんどないわけです。

ワイドショーでは「不正海外IPからで、国外からアクセス許可していた」事が取り上げられていましたが、例えプラットフォーム診断をしていても、この辺りは指摘されなかった可能性があります

実施していればもしかしたら備考レベルでの注意や、口頭で「国内のみに留めておいた方がいいかも」といったことは伝えられたかもしれませんが、「利便性」という観点から実行されることはなかったんじゃないかなと思います

Webサービスですが、ログインログアウト処理は必須でしょう。また、新規登録情報変更、退会処理も重要です。

パスワードリセットどうでしょうか。正直これも重要です。なので、ベンダに依頼するにあたってはここも診断対象としていたはずです。

ところで今回の件では協力会社について様々な憶測が飛んでいますが、NRI説が結構人気みたいです。

ただ、NRIにはNRIセキュアというセキュリティに特化した子会社存在しています

もし脆弱性診断をするとなった場合、そこを使わないという手はあまり考えられません。そもそも発注時にそれを見越して診断費も開発の見積もりに含まれているのではないかと思います

ただし、セブン側が「脆弱性診断はこちら側で発注します」と言っていれば話は別です。

NRIセキュアは診断費用が高いらしいので、コストダウンするために別ベンダに診断部分のみ発注する可能性はあります

別のベンダ発注したことで、抜け落ちた可能性はゼロではないかもしれません。

また、NRIセキュアが実施する場合においても、「ここは抑えておいた方が良い」という機能毎やページ毎にランク付けした資料セブン側に提出することと思われますが、どこを実施してどこを削るかの最終的な判断セブンに委ねられます

考えられる事としてはパスワードリセットの処理を診断対象外としたことですが・・・そうする理由もわからないので、うーん・・・

ただ、こうして対象を削りまくることで100万程度、もしくはそれ以下まで診断費用を抑えることができます

特定ベンダと、ツールを用いた定期診断を実施してもらう契約をしていた

この可能性もあるのかなと思います

使ったことはありませんが、SecurityBlanket 365というサービス自動での定期診断が可能なようです。

ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダ逐次依頼する脆弱性診断よりかは安く済むはずです。

ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。

ツールの手が届く範囲での、XSSPoC、ヘッダの有無など、ごく一般的脆弱性診断になると考えられます

でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。

セブン内部でツールを用いた診断を実施していた

脆弱性診断ツールOSSのものもあればベンダ販売していたり、SaaS提供しているものもあります

OSSならOWASP ZAPやw3afがWebサービスの診断が可能です。また、phpcs-security-auditなど、ソースコードを解析し脆弱な箇所がないかを診断するものもあります

ちなみにWebサービスに対する診断を「DAST」、ソースコードに対する診断を「SAST」と言ったりします。

有償のものとなると、DASTは先程のSecurityBlanket、AppScan、Nessus、Vex、VAddyが挙げられると思います

SASTになると、RIPS TECH、Contrast Securityなどでしょうか。

上記のようなツールを用いて、セブン内で脆弱性診断を実施することでセキュリティの知見を高めたり、内部で完結させるための動きを取っていたかもしれません。

こういった動きは結構色んな組織で見受けられます。外部の手を借りずに診断ができれば、関係者間の調整も楽ですし、それと比べると費用も安く済みますからね。

ただし、社内のエンジニアに任せる事になるため、片手間になってしま可能性があります

また、ツール使用方法についてのノウハウは溜まるかもしれませんが、それとセキュリティの知見が溜まるかどうかは別の問題としてあると思います

・・・とは言ってもセブンにはCSIRT部隊ちゃんとあるんですよね。

https://www.nca.gr.jp/member/7icsirt.html

『7&i CSIRT は、7&i グループCSIRT として設置され、グループ企業に対してサービス提供しています。』と記載があります

また、『7&i CSIRT は、7&i HLDGS. の組織内に専任要員を以て設置され、インシデント発生時の対応だけでなく、インシデント発生の未然防止にも注力しています

グループ企業情報システム部門と連携し、7&i グループ内で発生するインシデントに対する未然防止のための調査分析リスク情報の共有、ならびにインシデント対応活動を行なっています。』

という記載もあるため、今回の7payも、7&i CSIRTが動いてセキュリティ関連のチェックをしていたのではないかと思います。「情報システム部門」とはありますが。

組織図上にはありませんが、デジタル推進戦略本部の下か、リスクマネジメント委員会情報管理委員会のどこかに所属しているんじゃないかと思われます

日本CSIRT協議会にも名を連ねているわけですし、CSIRTメンバー専任要因ともありますし、セキュリティ関連の技術知識は十二分にあると思うんですよね。

なので、内部でツールを使って実施していたからといって、こんな重大な不備を見逃すというのはちょっと考え辛いなあ・・・と思います

会見内で言われた二段階認証検討事項に上がらなかったのかなあ・・・と。

まあ、今でも機能しているのであれば、の話ではありますが。

で、これを書いている最中に気付いたのですが以下のようなリリースが出ていたんですね。

https://www.7pay.co.jp/news/news_20190705_01.pdf

これを見ると内部のCSIRT機能していなかったか力不足判断されたかどちらかになるのかな・・・と。

実際はどうだかわかりませんけど・・・

診断を実施したがどこかで抜け落ちた

これも有り得る話かなあ・・・と。

関係者が多いと情報共有にも一苦労です。

開発やベンダCSIRT部隊情報共有したとしても、POが忘れていたとか、伝えたつもりが曖昧表現で伝わっていなかったとか・・・

ベンダ実施して指摘事項として伝えていたけど、いつの間にやら抜け落ちていてそのままサービスイン・・・というのもシナリオとしては考えられますね。

問題認識していたが上申しなかった/できなかった

7payは社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応時間を取られることになります

そういった事を許さな空気が出来上がっていると、まあ中々上には上がってきづらいです。

これも十分にありえる話ですかね。ないといいんですけど。

セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった

どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。

そこで思ったのですが、情報セキュリティ基本方針個人情報保護方針を元にしたチェックリストのようなものセブン内にあって、それを埋めた・・・みたいなことを「セキュリティ審査」と言っていたりするのかなと思ってしまったんですね。

でもこれはセブンペイの社長個人情報保護管理責任者ということで、ISMSPMS等で慣れ親しんだ単語である審査』を使っただけかもしれません。

そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業・・・

そもそもやってない

大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・

というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。

そういえばomni7で以下のお知らせが上がっていましたね。

https://www.omni7.jp/general/static/info190705

『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。

もしくはわかりやす対策提示しろと言われたのかもしれません。それなら仕方ないんですけど。

パスワード定期変更を推奨する因習はいつ消えるんでしょうか。

以上。

以下追記 2019-09-08

一部typoとか指摘事項を修正しました(役不足力不足 etc)。

ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。

所詮「人のつくりしもの」だよ

監査なんて取り揃えた書類通りになっているかどうかなので、監査受けているかセキュリティ的に大丈夫ってことじゃないよ

そんなに監査が万能なら監査できるくらいの人が作り出せば完璧になるはずだろ

ちゃんと読んでいただけましたか?全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・

一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性問題がないか審査の事」、つまり脆弱性診断」を指していると仮定して本エントリを書いています

そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。

監査貴方記載する通り「ある事象対象に関し、遵守すべき法令社内規程などの規準に照らして、業務成果物がそれらに則っているかどうかの証拠収集し、その証拠に基づいて、監査対象有効性を利害関係者に合理的保証すること」です。

貴方の言う「監査」に近いことは「セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ Permalink | 記事への反応(2) | 05:48

2019-04-06

anond:20190406105140

手作りエクセルシートなら各自好きに作れるからどうとでもなるかもしれないけど。

基本的には

1. OS(マイクロソフトとか)やエクセルVBA関数、その他ライブラリ対応を待って、

2. それを利用したミドルウェア屋とかOCR屋とかが対応して、

3. そのミドルウェアを利用したSIer顧客企業システム合致するかテストして

4. 顧客企業自らテストして・・・

みたいにいくつも業者テストがはさまるんじゃないの。

2019-03-27

公式なり非公式なりのフォーラム使わずに、プログラム分かりませんだのとTwitterなどで匿名で喚いた挙句

「あーこの{言語|モジュール|ライブラリ|ミドルウェア}はクソだわ」って言って終わるの

そろそろ辞めてもらっていいですかね。

 

三流以下っすよ、あなた

2019-03-25

Stadiaの開発者インタビュー その2

やっぱり途中で切れたので続きから


サービス提供を開始します。

するとシステムの準備は万端で、必要ソフトウェアの開発が必要ということでしょうか。Microsoftを見ますと、彼等はXBox OneのHWをサーバラックに積んでいるようです。あなたがたの手法とは異なりますか?

違います

するとGoogleインフラバックエンドのみでなくソフトウェアにも投資を考えていますか?

そうです。

自身の開発スタジオも考えていますか?

はい。Stadia Games and Entertainment組織を発表しました。これは我々の1stパーティスタジオです。

それが今起こっている?

はい

Google開発者に対し全てのツール支援しています。Stadia向けの開発は彼らにとって別のターゲットしか過ぎません。Visual Studioを用いる既存ツールや彼らが用いるツールの全てと共に、彼らのワークフロー統合されます。従ってStadia向けの開発はPlayStationXbox向けの開発と同じくらい簡単です。

我々はUnrealサポートします。UnityがStadiaサポートします。予想される多種多用な業界標準ツールミドルウェアが準備されます

意地悪な質問します。Googleコントロールを超えたものがありますよね。特にユーザサイド、クライアントサイドのインフラ家庭内安価ルータです。このような問題をどのように解決しますか?

とても良い質問です。我々はユーザに対し彼等のインフラの中で何が起こっているかをできる限り理解できるよう支援する必要があります。また我々はゲーマーに対し最適な体験を得られるようなチューニングを行うことが可能情報に対し投資を行うだけでなく、我々自身技術を用いて最良のパフォーマンスを実現するつもりです。Google技術の多くがインターネット網の基盤であることを思い出して下さい。我々はDCから情報がどのようにユーザに届くかを良く理解しております。できる限りの最適化を行うつもりです。

デベロッパパブリッシャは既存ゲームをStadia移植できるのですね。しかし同時にGoogleは新しい選択肢も数多く提供できると

その通りです。それこそが我々のプラットフォーム根本的な差別化ポイントです。既存ゲームカタログを持つデベロッパにとってStadia簡単で親しみ易いものです。我々はできる限り摩擦なくゲーム移植を行えるようにします。なぜならゲーマーは好きなゲームを遊びたいですし、彼らの愛するキャラクターストーリー世界を楽しみたいのです。しかし我々はまた開発者未来を描く新しいキャンバスをも提供します。ゲームを高速に配布し、プレーヤーと新しい手段で、特にYoutubeにて繋げます。そして開発者が持つアイデアを実現するための前例の無い技術提供します。


これまでのクラウドシステムクライアントサイドの限界基本的に画質やレイテンシに起こりました。明らかにこれらの問題インパクトはここ数年で新たにより良い技術を得ることとインフラ改善されることで緩和されてきました。しかローカル品質ストリーミング品質との間には今でも根本的なギャップ存在します。私はidソフトウェアZenimax特許を見たのですが彼らはh.264のモーションベクター効果的に用いてクライアントサイドのある程度の予測を立てレイテンシの知覚を減らしていました。Project Streamにも測定可能レイテンシ存在します。ギャップを閉じるために何をしていますか? これらの問題解決されたでしょうか。それとも少なくとも緩和はされましたか

解決されたと同時に緩和されています。まずデータセンターに対しより多くの人々がより良い経験を得られるようにするための投資が行われました。また圧縮アルゴリズムについては我々に抜本的な先進性が存在します。Google圧縮アルゴリズム標準仕様先駆者でありこの点がストリーミングの将来をより確実にします。残念なことですがGoogleでも制御できない点が光の速さです。そのためこの点が常に要因となりますしかし常に理解しなければならないこととして、我々は常にエッジ(終端)にもインフラを構築していることが挙げられますGoogleの中心にある巨大なデータセンタだけではありません。我々はできる限りエンドユーザの側にインフラを構築しています。それによって歴史上の幾つかの問題回避することが可能です。さらにまだ率直な、あまり洗練されていないProject Streamのストリーマーでも信じられない結果を出していますさらに我々はサービスリリース時に1080p60を超える品質を実現できるだけの根本的な改善を行いました。我々は8Kに至るでしょう。

それは素晴しい。それらの改善は全て圧縮に関連するものですか?

圧縮ネットワークです。我々はGoogleインフラに投入した数々の改善点に依っています。BBR、QUIC、WebRTCを基盤としてその上に構築がなされました。だからIPパケットの低レイテンシでの配信だけでなく、送信元へのフィードバックも行うことが可能です。ですのであなたが仰るZenimax使用した技術なら、彼らはここでも利用することが可能です。彼らは彼らのゲーム最適化を行うことができるでしょう。我々はフレーム毎のレイテンシ予測可能で彼らにそれに合わせて調整を行わせることができます


入力を受け取って、ゲームロジックを処理して描画を行うと、60Hzのゲームでは50ms程になります。続いてエンコード転送デコード、表示を行うとストリームではPC上のゲームに比べさらに60ms程かかります。これを改善することはできますか?

我々は改善を続けますStream最初バージョンです。我々は性能向上のために調査を行っており、レイテンシ適応していきますリリース時にはより良くなっているでしょう。

クラウドシステム接続可能性に従って成否が決まります。例えばRed Dead Redemption 2を数万、数十万、場合によっては数百万のプレーヤーオンラインにて同時に立ち上げるとします。システムの成否はアクセスによります。もしゲームプレイできないなら重大な障害となります

かにそのとおりです。そしてそれこそがGoogleが何年もかけて開発してきたスキルであり、抜本的なスケールする能力です。我々がどうやって実現しているのか、何をしてきたかについては今日は詳細にはお話しません。しかGMailMapYoutubeが同時に利用可能であるためと同じ基本的技術のいくつかが我々が依るものです。


我々は現在、現行世代が終了する移行の時を迎えています。これまではコンソールベースラインを定めてきました。Stadia次世代XboxPlayStationに対抗できると考えますか?

我々は競合他社が何をしているかは存じておりません。

でもGoogleには良い予測を立てられる優れた人々がいますよね?

我々の第一世代システムに導入されるGPU10Tflops以上の性能があり、さらスケールアップしま

GPUユーザ間で共有されますか? それとも1人のユーザが独占しますか?

単一インスタンスです。

NVIDIAGPUですか?

AMDです。

カスタムGPUだと思います

カスタムGPUです。

Google要件のために作られた訳ですね。他にも公開できる情報はありますか? Vegaですか? それともNavi、もしくはさら新世代ですか?

情報を公開したくない訳ではないのですが、このプラットフォーム進化することのほうがより重要です。そしてこの進化ユーザ開発者の双方に対しシームレスに行われることを確認して頂きたいのです。そして進化は常に継続し、誰もが常に最新で最高の物を手に入れます

クラウド確約する点ですね。ユーザはHWをアップグレードする必要がないと。

開発者にもこのように考えて欲しいのです。もちろん完全には抽象化されていません。特にゲーム開発者にとっては。しかし我々はそれでもこのプラットフォームが常に進化していると考えて欲しいのです。速さや容量、リソースには制限されていないのだと。

AMDGPUを使うことでStadiaと他のコンソールの間に共通な点ができました。開発者にとって利益となるでしょうか?

シェーダコンパイラツールをいくつか開発しました。これらは開発を楽にするでしょう。しか現在GPUはとても優れており開発者が既にVulkanに親しんでいれば、例えばid Softwareさんは既に全てVulkanに移行していますが、そのような開発者の方々には既存ゲームをStadia移植するのはとても簡単です。Doom Eternal4K、60フレームで動いでいるのは既にご覧になったと思います。非常に素晴しい状態です。これこそが我々にとって重要証明ポイントです。FPSグラフィックプレイアビリティの双方で要求が高いゲームです。 従ってこれは我々のプラットフォームの強力な証拠であり、idさんにも講演して頂きます

CPUについては何か公開できる話はありますか?

x86で2.7GHzで動作しています開発者にとり慣れのあるものです。開発全体を通して、CPUは制約となる要因ではありません。我々は全てのタイトル動作するに十分なCPU提供します。

コア数、スレッド数は?

沢山です。

8コア、16スレッド? それより多い? 少い?

公開できない情報です。ハイパースレッド使用しています

しかサーバ級のCPUです。Stadiaはこれまでのコンソールと違いパッケージングに制約を受けません。熱対策問題も異なりますコンソールとはサイズパッケージング動機が異なりますデータセンタの中でそれはとても汚なく見えるかもしれません。一方でとても帯域幅が高いメモリ使用可能で、とても高速なペタバイト級のローカルストレージ使用可能です。ご家庭のコンシューマデバイスよりも数百倍は速い物です。

するとそれが開発者が全く異なる体験のために利用可能な要因となる訳ですね。得られる機会はとても大きいことでしょう。しかし我々はマルチプラットフォーム時代生活していますGoogle先進的な機能は1stパーティのみが利用できるものですか?

パートナーには彼らが話せる時点で彼らの計画を教えてくれるよう伝えています。Stadiaをこの世界で最も偉大なゲーム開発者達に説明することにはとても興奮します。Stadiaは、開発コードではYetiと呼ばれていましたが、Stadiaビジョン説明すると、開発者リアクションは「これは私が期待したもののものだ。これはまさに我々の次のゲームのためのビジョンのものだ。elastic computingの考え、次世代レベルマルチプレーヤー環境ゲームを観ることと遊ぶことの境をあやふやにし1つの体験にすること」と話されます

イノベーションの1つの領域として、最初のほうで述べましたが、マルチプレーヤー環境において、単純にパケット複数プレーヤーリダイレクすることから原子時計レベルでのコンシステンシーを全ての状態遷移において定期的にクライアント間で更新する真のシミュレーションへの移行が挙げられます。これにより開発者はこれまでには不可能だった分散された物理シミュレーションを得ることができます。これだけでもゲーム設計イノベーションに対し大きく寄与します。このため多くの開発者が、大袈裟でなしに、実際にとても感動的なリアクションを我々のプレゼンに対して返して下さっています


多くの問題解決し、規準を上げる可能性がある訳ですね。

これこそがゲーム業界の素晴しい点です。技術が常に創造性を刺激し、ゲームに対しより大きな聴衆を作り、そのことがプレーヤー開発者に対しより大きな機会を作ってきました。エコシステム進化し、正の方向に回り続けるなら、それはゲームを遊ぶことにとって良いことです。

あなたは先程、スケーラビティとStadiaがどのようにしてより多くのリソースを立ち上げ増大する要求対応するかについて話して下さいました。しかし、同時に10TflopsのGPUサーバクラスCPU存在するとも仰いました。リソース拡張をどのように行うのですか?

3台のGPSが一緒に実行されるデモを行っています。私は上限が無いとは申しません。しかし我々は技術上の限界を上げています。そしてStadiaは静的なプラットフォームではありません。このプラットフォームは5年や6年の間、レベルが変わらない訳ではありません。開発者プレーヤー要求に従い、成長し、進化するプラットフォームです。なぜならStadiaデータセンタの中に構築されています進化させるのは我々にとって簡単なことです。

ここまで第一世代について多くのことを教えて頂きました。すると第二世代やその後の世代もあるでしょう。現状でもスケールアップできるわけですが、3台のGPU連携次世代でも可能ですか?

CPU/GPU/メモリ帯域幅の変更にはいくつかの自然な段階があります。これは家庭の物理な小売の端末よりももっとスムースでより継続的な進化です。しかし、より重要なことは基盤データセンタ網とそれに含まれネットワーク技術への投資です。この2つが一致して行われることが重要でどちらか1つではダメなのです。

先程、エッジ上のインフラについて触れられましたが、例えばNetflixISPキャッシュインストールしている状況があると思います。これがGoogleが行っていることですか? それとも既にYoutubeで行われていますか?

それは我々も既に行っていますGoogleが既に20年以上、行っていることです。我々が依って立つまた別の巨人の肩です。


Project Streamではユーザに対し最低で25Mbpsの帯域幅要件しました。これはストリーミングのみのためですか? それとも他のユーザが同時に同じインスタンス接続する場合を含みますか?

我々はStreamさらに強化させています。従ってユーザはこの制約が全体のスタックに対する改善最適化、また特に時間によって緩和されることを期待するでしょう。我々はその期待の上を行きます

4K60には相当の帯域幅がいるのでしょうね?

4K60はもちろんより要求が高くなります

1080p60は低くなる・・・

私は具体的な数値についてはコメントしません。しかし当然低くなります

インターネット接続環境はStadiaリリースする市場では全体的に上昇機運が見られます。つまりこのパフォーマンス特性ますます多くのユーザが利用可能になります

さらに繰り返しになりますが、BBRを初めとする我々の技術がありますさらに覚えておいて頂きたいのは我々のネットワークに対する理解そのままではありません。それらもまた時と共に改善されていきますYoutubeマクロ

Stadiaの開発者インタビュー

Eurogamerにより独占配信されたStadia開発者二人に対するインタビュー記事

https://www.eurogamer.net/articles/digitalfoundry-2019-google-stadia-phil-harrison-majd-bakar-interview

やっつけなので可能なら原文を読むことをお勧めします。

---

なぜ今なのでしょうか?

タイミング問題です。20年間の蓄積によりGoogleにはデータセンタ内のパフォーマンスに優位性が存在します。Googleデータセンタ内ではHWメーカーです。我々はデータセンタ内で何年もの間、高い性能で端末間を接続する基盤を構築してきました。Youtubeでの経験からプレーヤーサイドの観点からだけでなくデータセンタ内部から技術観点から技術統合を行ってきました。他社でもその視点存在していますGoogleにはその点に固有のアドバンテージ存在します。

これまでの箱をTVの下に置いておいたパラダイムに比べ、無限演算リソースによる可能性が現れます。これまで存在しなかったことをできる可能性があります

その通りです。我々にはレガシーがありません。全てが21世紀のために設計されています開発者制限の無い計算資源が利用でき、何よりもマルチプレーヤーサポートできます。これまでのマルチプレーヤー環境は一番遅い通信に影響を受け開発者は最も遅い接続に対し最適化必要でした。我々のプラットフォームではクライアントサーバも同じアーキテクチャの下にあります。これまではクライアントサーバの間のping支配されていましたが我々の環境なら最速でマイクロ秒で済みます。だからプレーヤーの数は単一インスタンスにて動的にスケールアップが可能です。バトルロイヤルなら数百から数千、数万のプレーヤーが集まることも可能です。それが実際に楽しいかどうかは置いておくとしても、新聞ヘッドラインを飾ることが可能技術です。

クライアントサーバの双方でこの利益を得られるのでしょうか

両方です。

すると開発者に対しStadiaホリデーシーズンにぴったりの最高の製品だと言えると。理に適った範囲無限計算資源が得られると。

ユーザが我々のプライベートLANからはみ出さないだけでもその効果は大きいものです。Googleは45万kmに及ぶ光ケーブルにより世界中データセンタ間を接続しています米国西海岸から東海岸まででも20ms、フランクフルトからマドリッドでも20ms。これにより開発者は最も極端な場合においてもレイテンシ予測可能でそれに従い設計を行うことができます


Youtbeとの統合について教えて下さい。

StadiaYoutube技術と深く結びついていますが、実際には一歩引いています今日ゲーム業界を考えてみて下さい。2つの世界共存しています。1つはゲームプレイする人々で、もう1つはゲームを見る人達です。2億人の人々がYoutubeゲーム毎日見ています2018年には述べで500億時間ゲームを視聴するのに費されています時間人口の双方で信じられない程の視聴が存在します。我々のビジョンはこの2つの世界を1つにすることでゲームを見ることができ、かつ、プレイもできる、双方向に楽しめることです。

まり重要なのはゲームシステムでもなくコンソールでもありません。噂とは異なり我々はコンソールビジネスには参入しません。我々のプラットフォームの要点はコンソールでは無いことで、皆が集まる場所を作ることです。我々は箱でなく場所を作る。今までと異なる体験を得られる場所です。ゲームを見るなり、遊ぶなり、参加する場所であり、かつユーザが楽しむ場所であり、ユーザ他人を楽しませる場所です。

から我々のブランドはStadiaといいます。これはスタジアム複数形です。スタジアムスポーツを行う場所ですが同時に誰もがエンターテイメントを楽しむ場所でもあります。だから我々はそれをブランドにしたかったのです。皆が遊んで、観て、参加して、さらにはゲームをする場所。一歩下がって見ることもできる場所。常にどのボタンを押したか意識しないでも良い場所。他のアーキテクチャでは実現できない場所です。

まりリアルタイムシミュレーションゲームで全ての駒が人々であるようなものですか?

その通りです。そして単純に技術的に深い点を求めて、我々は第一世代でも4K60fpsHDRサラウンドサポートしました。さら開発者必要インフラに従ってスケールします。それだけでなく、同時にYoutubeに常に4K60fpsHDR画像送信することが可能です。だからあなたゲーム体験の思い出は常に最高の状態になります

Googleは全てを記録するでしょうか?

プレーヤー次第です。Googleは全てを記録はしません。もしプレーヤーが望むならGoogle4Kストリームしま

共有が友達だけか、世界中に公開かも自由選択可能です。Googleユーザ制御を明け渡します。もしユーザYoutubeで公開すれば誰でもリンククリックすることでそのゲームを遊ぶことができます

するとユーザshareするだけで誰でもがその特定ゲームに参加することができる訳ですね。

そう。そしてこれはマルチプレーヤーゲームロビーの新しい形となりますYoutubeクリエイターなら誰でもがファンチャンネルのsubscriberを自分ゲームへと誘うことができます生主として、Youtubeクリエイターとして私は視聴者を私のゲームに瞬間的に招待できます。それが私と10人の友達でも、(訳注: セレブの)Matpatと彼の数百万の購読者でも、技術は同じです。

アカウントシステムベースYoutubeですか?

Googleアカウントの一部です。従ってGMailアカウントがStadiaへのログインに利用できます。他の基盤についても説明させて下さい。最初サービス立ち上げから全ての画面への対応を行いますTVPCラップトップタブレット携帯です。我々のプラットフォームの基本は画面に依存しないことです。これまで40年間、ゲーム開発は端末依存でした。開発者として私は制約の範囲内で、私の創造性を開発対象の端末に合わせてスケールダウンする必要がありました。

我々はStadiaでそれを逆にしたいのです。我々は開発者に対し彼らの考えをスケールさせ、どの端末の縛りから解放したいのです。パフォーマンスに優れ、リンククリックすればゲームは5秒以内に開始されますダウンロードもなく、パッチもなく、インストール必要なく、アップデートもありません。多くの場合、専用のHWも必要がありません。従って古いラップトップChromeブラウザ使用する場合にでも皆さんが既に持っているだろうHID仕様に準ずるUSBコントローラ動作します。そして、もちろん、我々自身コントローラも開発中です。

なぜ独自コントローラを作るのですか? USBコントローラはどこにでもあるじゃないですか

コントローラ自作する理由はいくつかあります。1つはTVへの接続です。我々はChromecastをストリーミング技術採用します。Stadiaコントローラの最も優れた機能の1つはそれがWiFi接続DC内のゲームに直接接続することです。ローカルデバイスとは接続しません。

それは面白い。するとほとんどそれ自体が端末な訳ですね。

その通りです。これこそが我々のブランドの実現であり、具現化です。そして独自コントローラにより最高のパフォーマンスが実現します。ゲームに直接接続するためにプレーヤーは画面を移動することが可能です。プレーヤーはどの画面でも自由に遊び、停止し、他の画面でゲームに復帰することが可能です。

そしてコントローラには2つの追加されたボタンがあります。1つはGoogle Assistantの技術マイクを用いますユーザ選択により、ユーザプラットフォームゲームの双方に対し、自然言語を用いて会話が可能です。例えば「Hey, Google。MadjとPatrickと一緒にGame Xをやりたいな」と言えばStadiaマルチプレーヤーゲーム指定した友人と共に直ぐに開始します。

するとGoogle伝統的なUI回避するのですね?

我々はゲーマー可能な限り素早くゲームに辿り着かせるよう考えています。数多くの研究を行いましたが、多くのゲーマーゲームを起動したら直ぐに友人とゲームを開始したいと考えていますゲーマーUI時間を費したくは無いのです。

誰かが言ったことですが、現在コンソールは起動した時にまるで仕事のように感じると言うのです。ゲーム自体更新や、ゲーム更新があります。我々はそれらを完全に取り除きたいと考えています。もう1つのボタンは、ちょっと趣が異なるのですが、Youtubeシェアできます

端末は何でも良いのですね? スマホスマートTVも?

Youtubeが観られるならどこでもStadiaは動きます

TVへの接続にはChromecastが使用されると。では実際にはどのように動きますか?Chromecastがスマホラップトップからストリーミングを受け取るのでしょうか?

Chromecastはスマホからストリームを受取はしません。Chromecastはスマホから命令のみ受けます画像NetflixYoutubeから直接受け取ります。Stadia場合、StadiaコントローラからChromecastへとこのゲームインスタンスへと接続せよと命令がなされ、Chromecastはゲームインスタンスから動画ストリームを受け取りますクライアントはとてもシンプルです。行うのはネットワーク接続ビデオと音声のデコードのみです。Chromecastは入力を処理しません。全て入力コントローラが扱いますビデオと音声とネットワーク接続Chromecastの基本動作で全て既に組込まれています

Stadiaの起動はどうするのですか? コントローラで?

そうです。とても良く出来ていますWiFiに繋ぐだけです。コントローラにはWiFiIDとPWを入れるだけです。それだけです。ホームボタンを押すと勝手Chromecastを探し直ぐにChromecast上でクライアントを起動します。UIが表示され直ぐにゲームを遊ぶことができますデジタルパッドでUI操作することも可能です。これが重い処理を全てクラウドへと移行する点の美しさです。Chromecastのような低消費電力の端末で説得力のある体験ができますChromecastは5W位下です。Micro-USBで給電可能です。典型的コンソール100から150Wもします。またこれまで説明しませんでしたが、例えスマホでも行うことは動画再生だけです。従ってAssassin's CreedDoomや他の重いゲームあなたスマホの上でモバイルゲームよりも低消費電力で動作します。だからスマホ10時間でも遊べます

スマートTVではStadiaYoutubeクライアントに組込まれるのでしょうか。それともStadia独立して起動させますか?

今の所、我々はChromecastのみに集中しています。でも技術的、機能的な観点からYoutubeがある場所ならどこでも動きます。我々はまだStadiaをどのようにユーザに届けるかは検討中です。

コントローラに話が戻りますが、モバイル端末にはやはり物理的なアタッチメント必要に思われます。例えばスマホコントローラ接続するような。MicrosoftのXCloudを見ていると操作には実際に問題があるようです。

Googleには解決手段があります

そうでしょう。スマホコントローラ取り付け以外にも、明らかな解決手段としてSwitchのようなクライアント端末を作るのでしょうか?

サービス開始時から提供されるサードパーティによる解決手段サポートしています。他にもアイデアがありますしかし今は話せません。

なるほど。GoogleUbisoftデモを行いましたが、これまでにDoom 2016でもデモを行いました。他にも開発企業はありますか?

良い質問です。私がこのプロジェクトに参加する前からチームは既に何社かと提携しここ何年かの間に技術提供していました。StadiaLinuxベースです。グラフィックAPIはVulkanです。開発企業クラウドインスタンス作成しますので、開発キットも今ではクラウドにありますしかクラウドだけでなく、開発社のプライベートDCでも、机上のPCでも可能です。

すると開発者物理的なHWを持つことが可能ですか?

もしそうしたいなら。でも我々は今後のトレンドが開発でも配布でもますますクラウドへと移行していくと考えています。従って今後数年で開発者にとってクラウド中心、クラウドネイティブゲーム開発での標準となるでしょう。

どの企業自身クラウドシステムを開発しているように見えます。例えばOriginクラウドがあるでしょう。しか必要とされるインフラ要件は、我々がここで話しているような内容を達成するには、3rdパーティには荷が重いように思えます。彼らは自身クラウド継続しながら、Googleシステムを導入するでしょうか。

デベロッパーパブリッシャーはとても賢くクラウドネイティブとなる新しいゲーム体験を達成するために必要ツール技術について考えていると思いますしかしそれは世界中で何千ものアクセスポイントを持つデータセンターを運営することや、それらの運営必要な莫大な投資資本とは異なるものです。Googleは今年単年でも$13Bの資本を投下しています

それはとても巨額ですね。しかしそれでも依然としてシステムを構築しインストールするのは根本的な問題です。多分野に渡る段階的なロールアウトになるのでしょうか?

米国では全ての必要場所に展開が終わっています。Project Stream試験必要環境2018年末には整いました。我々はGoogle社内で、Google社員対象2017年の始めから2年間の間、プライベートテストを行ってきました。2019年には米、加、西欧、英にて Permalink | 記事への反応(1) | 06:10

2019-03-10

量子コンピュータエンジニア始めて5年が経った」を読んで

https://qiita.com/YuichiroMinato/items/7192a15505d15409e904

Googleが早くから問い合わせており、海外リサーチ能力は高い

アメリカのように量子コンピュータ用のミドルウェアを開発する起業が出てきているわけでもない状態で、

名前も聞いたことがない日本企業に対して、多くのコメントがあるのは、

Googleが問い合わせている」という点がある。


これが富士通NECNTTという名前が出てきたら吐き捨てられていたと思われる。


もう一つ、海外企業リサーチ能力がすごく、資金がどこから出ているのか、把握している。

異能vationはあまり注目されていない

日本企業技術判断する際に、純粋技術評価されなくなっているのではないか


人脈が大事

大学先生などの人脈がスタートアップでは大事

地方大学ハブとなるのはおそらく紹介できるかとかなのだろうが。

2018-10-29

オンボードメモリマウスって便利だけど一度なんかのソフトと相性が悪かったりして不具合でると泥沼になってクソだな

ミドルウェア削除しただけじゃ元通りにならんし

2018-09-19

とある会社機械学習環境を整備しているんだが心が折れそうだ

昨今流行りの機械学習プロジェクトがぽこぽこ立ち上がっている状況なのだが、一部の人を除き、apt-getで躓いているのは会社にとって損失だと考え、オンプレクラウドのようなものを構築することにした。

グループ全体の規模はそこそこ大きいが、将来単なるアッセブリー屋になることが目に見えている事もあり(今後20年以内には喰われてしまうという憶測もあり)ネットワークLinuxコンテナプログラミングが出来る自分が社内の機械学習、引いてはITインフラ民主化、なんだったら外販できるくらいのもの作ってやろうと鼻息巻いて無理やり一人プロジェクトを興すことにした。

まずは既存DHCPサーバ名前解決ができないDNSサーバからゲートウェイPCを用いてネットワーク的に分離、社内の物理的な設置スペースの問題デスクトップPCサーバPCが離れた所にあるため、WireGuardでVPN構築、ゲートウェイPCはそれぞれKea DHCPサーバ、PowerDNSサーバを稼働させ、OpenStack導入検討時に悩んだ鶏が先か卵か先か問題解決することにした。

上述の通り、システム構築にあたってOpenStackやMAAS,RancherOSなどを検討したが、社内のニーズを「100%」汲みとった上で、次世代オンプレクラウド個人的にはエッジクラスタがゆるく繋がるアメーバクラウド?のような呼称があっている気がするが)を構築するにはどれも痛し痒しで何かしら制限がついて回るのは許容できなかった。これは今後5年、特に海外事業所の開発者の事を考えた時には外せない要件だった。

とはいえmiekg/dnsを用いてCoreDNS進化版を作るにはリソースが足りず、BINDを用いるにはSA対応がしんどすぎるため、APIを備えており、今後も進化が見込めるであろうOSS、また必要であれば商用製品保守サービスが受けられる事から上記2つを選択した。

PowerDNSはさておき、ISC KeaはナウでYANGなLinux YANGに対応しようとしているなど(言いたかっただけ)、世の中のオンプレ環境を塗り替えるためには兎にも角にもAPIゲートウェイ重要だと考えたため、双方が提供しているAPIをうまく吸収するミドルウェア(とちょっとしたAPIサーバ)をGo言語作成した。

次に世の中のパブリッククラウドOpenStackなどを触ったことのある開発者はCloud-initに慣れているはずという前提の元、対応コスト勘案の結果、NoCloudで対応しつつ、上記APIサーバ連携し、ベアメタルマシン管理した事のある人はわかる、ベアメタルマシン特有の諸問題解決することにした。

まぁなんだかんだ大企業なのでお金解決する手段もあるが、そもそも高集積ラック搭載GPUサーバ購入の稟議が通るような会社だったら既にKubernetes導入しているだろうし、俺もこんなことしてない。

脱線したが、上記以外にも検証バックアッププランとしてAnsible記述などの作業はありつつも、3ヶ月かけてようやく基礎となるインフラ基盤が構築できたため、nuxt.js+go簡単フロントエンドサーバを構築し、一人情シス様相を呈している部下のリソース開放、Calico対応+Kubernetes導入、不安がっている上席が安心できるように、分かりやすい餅を用意しようとしている、というのが現状。

ここまで寝る時間も惜しんでトップスピードを維持したまま頑張ってきたものの、少し限界を感じている。

特にオンプレクラウド部外者が中々見えてこないものがあり、なんならその見えないもの限界まで吸収できるように、かつ現実的に実現可能ギリギリラインを狙っているのだが、そもそも周りに相談しようとしても何を言っているのか解説する所から始めないといけない。

覚悟はしていたが、ふとした時にとてつもない脱力感に襲われてしまう。

世の中を切り開いてきた諸氏はおそらく一度はぶつかったであろう、この内なる自分の壁をどのように突破してきたのだろうか?

ひたすら孤独との戦いだというのは頭では理解しているものの、突発的にくるこの脱力はいかんともしがたい。

推敲もせずに大変失礼極まるが、コメントをいただければ幸いである。

2018-09-08

anond:20180908155359

iOSiPhoneOSだと思うけど。

増田が言っているドコモガラパゴス化の要因として指しているのはMOAPの事なのではないかなぁ。

あれはOSではなくてミドルウェアで、OSSymbianだった気がする。

2018-08-31

anond:20180831152349

ハードウェアってCPUとかグラボとかメモリの数値の事言ってるでしょ。

OSミドルウェアは同じなんて到底言えないよ。

2018-08-15

サマータイムB2B通信。あと費用負担の話

以前、短期間だけど、B2B通信ミドルウェアメーカーにいた。B2B通信っていうのは企業間でのデータのやりとりのこと。

あなたが近所のスーパードラッグストアで買い物をしているとする。お店は品物を仕入れるため、B2B通信で「冷えピタ20ケース売ってください」というデータを送り、受け取った卸売業者は「受注しましたよ」というデータを返す。卸売業者はさらに、メーカーに対して発注データを送り、メーカー卸売業者に受注しましたよというデータを返す。

あるいは、あなたAmazonで買い物をしたとする。Amazonクレジットカード会社請求データを送り、クレジットカード会社は成否をAmazonに返す。

あるいは、あなたが使っているA銀行の口座から、別のB銀行の口座に振込をしたとする。当然、銀行間でやり取りが行われる。

こういうデータのやり取りが、毎日恐ろしい件数で行われている。サマータイムが導入されるとしたら、B2B通信にも影響がある。ちょっと考えただけでも、

サマータイム導入が決まった場合、そういった問題が起きないように対応しなければいけないわけだけど、

限られた予算の枠内でサマータイム導入にコストを取られるということは、それ以外の施策は後回しになる。停滞のもとだ。

対応方法企業によってばらけそうなところも問題だ。B2B通信しているすべての企業が揃って完璧対応をできれば問題ない。でも、場合によっては、「うちはIT予算に余裕がないので、サマータイムの切り替わりタイミングサーバ時計を2時間ずらすだけにします」みたいなところも出てくるだろう。そうすると、「時刻は確かに2時間ずらされているけど、タイムゾーン指定JSTのまま」みたいなデータが送られてくることになる。メーカーユーザ企業の力関係にもよるけど、ミドルウェアでは「通信相手ごとにサマータイム対応方法が違う」という前提で複雑なプログラムを組まないといけなくなるかもしれない。

おそらく、サマータイムの開始・終了時には、夜間にも関わらず関係各社の担当者が待機させられることになるだろう。B2B通信も夜中には頻度が下がるのが確かだけど、ないわけではない。データの種類によっては「毎日1回夜中の3:00に送る」みたいなケースもある。万が一何も起きなければ安心して寝ればいいけど、何か障害が起きた場合、影響が大きくなる早朝までに対応しなければいけないので、ミドルウェアメーカー運用担当者も開発担当者も召集され、タクシーで集まって全員で対応するハメに、というのも十分ありうる。

海外との取引がある企業もあるから日本だけの話でもない。「へぇ日本でもサマータイム導入されるんだ。どれどれ、このJDTっていう1時間ずれるやつかな」なんて中途半端対応されてトラブルになるケースもあるかもしれない。

……ここまで書いてきて思ったけど、サマータイム対応問題なのは費用負担が一番大きいんじゃないだろうか。

オリンピックは、主催者や、そこから仕事をもらっている広告代理店建築業者、スポーツ用品メーカーなどが収入を得る。それ自体別にいいんだけど、そのためにサマータイムが導入されて、オリンピック関係ない企業や、そこで働く人たちが負担を求められている。娯楽はそもそも提供する側がサービスして、享受する側がお金を払うという交換をするわけだけど、サマータイム導入で反感を買っているのは、オリンピックから直接利益を受けない企業や人が、「あくまサマータイム対応コストがかかるのであって、オリンピックお金徴収わけではないか問題ない」という論理でタダ働きさせられることが大きい気がする。いわば、日本全体から金をふんだくって、オリンピック主催者関係者に集約するかたちになっている、その構図が問題なのではないか

そこで提案なんだけど、「サマータイムは導入してもいいから、対応にかかる費用東京オリンピック主催者請求できる」というかたちに持っていくのがいいのでは。

「いやいや、開始までの時間が残り少ないのが問題だよ」という意見もあると思うけど、費用請求できるなら、優先度上げてできることが色々増えるよね。単純に人を増やしたり、深夜残業代にあてることだけじゃなくて。

たぶん、開催時刻をずらすんじゃなくてサマータイム導入、という話が出たのも、「IOCとの契約時間が決まっちゃってるから変えると違約金払わされる」とかそういうことだと想像するので、サマータイム対応にかかる費用主催者負担して違約金回避できるなら、問題ないよね。……まさか対応費用が払えないほど莫大になることがわかっていて、それを全国の企業押し付けようとしているわけではないよね? もちろん、「サマータイム対応費用を都や国が補助金とか出して負担する」ではダメですよ。それだと結局、主催者が儲かるために国民全員に負担押し付けるかたちになっちゃうので。

いやぁ、いい案を思いついた。これなら全員がニッコリ、Win-Winな感じになれそうですね。よかったよかった。

2018-06-24

開発環境と本番環境を一つにすれば効率的そもそもお金貰えるの?

そもそも弊社って開発環境の代金を見積もりに入れてなくて、

なんか対応が入る度に本番環境からソース落としてきてCentOSiso使ってVirtualBox仮想環境作って

yumで手順書見ながら必要ミドルウェアとか導入して、

本番環境と同じ設定でメールとか飛んだらまずいからその部分を探して修正して、

反映の際はそこだけ戻してってやってるんだけど、

これはもしかして物凄く頭が悪いのか?

2018-05-12

元号が変わることへの対応なんてミドルウェア任せにできないものかね

昭和から平成プログラムの書き換えが面倒で一気に和暦が減ったが、今時はそれくらいの自動化はできていて欲しいところ。

glibc.NET FrameworkJavaOracleあたりのメジャーどころは標準で和暦機能提供しているわけだし。

2018-04-01

anond:20180401183450

もう痛いほど分かる。

フレームワークって生産性上げるためのおまけに過ぎないのに、知ってないと話にならない基盤になってるんだよね。

それなのに色々ある上にミドルウェアとの組み合わせとかもあるしもう正直ついてけねー。フレームワークについて考えたくねー。

2018-03-11

自分自己肯定感が弱いと感じている

日頃、自分の興味のあることに関する課題発見し、それを解決するためにアプリ(小規模だけど)を開発し公開している。作ったものがたまにバズることがあって、その結果1日の広告収入が1万円を超えたこともあった。しかし、定期的に作ったアプリに対して使った技術要素やコーディング量を見返した時、これぐらいのものはxxさんなら自分より短時間かつ高クオリティで開発できるなと思うことがあるのだ。

興味があることに自分課題発見し実際に手を動かしているのですごい!みたいな話を聞いたことがあるが、理解はできても共感ができない。

常にネガティブ感情を抱いているわけでもなく、難しい箇所をうまくコーディングできた時は自分のことを天才だと感じることや、ミドルウェアを含むバックエンドからフロントエンドまで1人で開発できるようになり、昔の自分と比べて成長したと感じることはある。ただ、これらのポジティブ感情は一瞬で終わり、あっという間に上に書いたようなネガティブ感情自分支配するようになる。

レッドコーダーやKaggle Masterになるか未踏に採択されるなどのレベルに達すれば、自分を認めることが出来るような気はしているが、あいくそこまでの能力は持ち合わせていない。

https://anond.hatelabo.jp/20180311003723 を見て書きたくなった

ログイン ユーザー登録
ようこそ ゲスト さん