  |
はてなキーワード: ネイティブアプリとは
増田のようなスタンスを否定する謂れは一切無いし、むしろそういうライトなファンを如何に獲得するかがコンテンツの発展につながることは承知の上で、ではなんでゲームもふれて欲しいという熱心なファンが多いのかというと、やっぱり情報量が段違いなんですね
で、このアイドルゲームのスタンスとしては、アイドルはアイドルであるまえに人間だと
それを表すための膨大で多角的なテキストがゲームには詰まってるのです
しかも最近はソシャゲベースで展開していますから、時間軸という概念を獲得しまして、もはや容易には伝えきれない量になっていて、もう自分でやって自分で発掘してもらうしか無いのです
正直申し訳ない気はしないでもないです
ただ、メディアミックス展開や二次創作だけでなく、大本のゲームを、更に言うなら最新のネイティブアプリだけでなくブラウザゲームのほうも触れて欲しいというのはそういう事情があるのです
http://anond.hatelabo.jp/20160522003506
ども。
この辺りの一連の発言（特に後二者）を見るに、多分React以前の前提がいろいろ違っています。単にJSやNodeやNPMやSPAやWeb APIといったフロントエンドの世界観に対して、興味がないどころか漠然とした不信があり、サーバ側でヘビーにHTMLを作って吐くスタイルを守り続けたい人なのだ、という印象を受けます。
ユーザの各操作毎にサーバ側で外見のHTMLを組み立て直して配信するという旧来のWebの方が特殊な世界です。それこそAndroid/iOS開発やデスクトップアプリで、そんなやり方はしません。UI関連のことはクライアントで完結し、メニュー遷移程度で通信したりしない。サーバは静的データの配信とDB操作に専念する。SPAとは、やっとブラウザがそういうネイティブアプリのレベルに追いつき、同じやり方ができるようになった、というだけの話です。
とりあえずReactは、まずその前提を受け入れてから使うものです。その前提なしに使えないこともないですが、メリットは活きないでしょう。その時点で既に「よくわかんないんですけどSQLiが…」と漠然とした不安を表出されるようだと、道のりが遠いな…と。もちろん「私の周囲にそういう案件はない」ということなら、それで構いません。
具体例を出せとのことだったので。私の場合は変幻する数百のテキストフィールドとリアルタイム集計が登場する勤務予定表的なものを、1人でjQueryのSPAで作った際、数百行のHTMLと数千行のJSがスパゲティ化し「こりゃいかん、メンテ不能になりそう」と思ったのが、具体的にReactを覚えるきっかけでした。実際非常にうまく行き、10年後の誰かにも「この時代のベスト」として自信を持って残せます。JSXの局所的な見た目の問題など、アプリ全体の構造の見通しやすさと比べたら些細な話です。Angularなら出来たかもしれませんが、サーバ側処理とページ遷移を多用して書くことに関しては検討すらしていません（私の知っているどんなフレームワークを使ってもユーザビリティと、見通しの良いコードを保つことは無理だったと思います）。ビデオ再生や大きな画像処理を伴うアプリでもReactを使っており、そちらではページ遷移などもってのほかです。
「変な独自拡張を入れてまでJSを使い続ける理由がわからん」についても、まるでJSが生来の嫌われ者で、クライアント側でもPythonやRubyを使いたい人が多くいるかのような書き方のように思えるのですが。実際そんなことはないですよね？ たぶんES6は人々から積極的に愛されています。現状、クライアント側にPythonが進出するのではなく、逆にデスクトップやモバイルやサーバ側にどんどんJavaScriptが進出する流れが起きています。
速度に関しては、Reactはやってる内容の割に十分速くて実用的だよね（mustache使うよりは速いよね）ということであり、賢い人が手間暇かけて最適化した生DOM操作より遅いのは言うまでもありません。また、JSXはシンタックスハイライトが出来ないとかも、そうとう昔の話です。今は普通のJS技術者が普通に触れる程度の成熟はしています（枯れたとまでは言いませんが）。
OAuth ディスの記事を酒の勢いで訳してみたゾ。前半はつまらないから、「章のまとめ」か、それ以降だけ読むといいゾ。なぜか後半が切れてた。こっちだけでいいゾ anond:20160426145507 anond:20160426150324
http://insanecoding.blogspot.com/2016/04/oauth-why-it-doesnt-work-and-how-to-zero-day-attack.html
認証 (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 は、上記の問題を回避しようとして以下のような手順に沿ってシステムに情報を提供します:
このトークンはユーザの認証情報ではありませんから、そしてひとりのユーザとひとつのアプリの組み合わせだけに有効で、指定された権限しか持たず、あとから破棄されるようになっていますから、きちんと前述の問題点を回避しているように思えます。しかし実際には、ちゃんとした土台を核として持っているにも関わらず、OAuth の普通の実装で使われているこのフローは、上に挙げた問題すべてに対処しているとは言えません。
この設計はそもそも危険なスタート地点から始まっています。セキュアなプラットフォーム設計の第一原則は、危険な地点から始まったものは既にダメ、逆転不可能、ということです。手順 1 のせいで、EVS 自体ではなく EVS を利用するサービスから始まっているので、ユーザは最初の一歩からして中間者攻撃を受けたような状態にあります。これは、かかってきた電話に個人情報や口座番号などを教えるようなもので、自分の使っているサービスの者だと名乗っていますが、番号が本物かどうか分からなかったり非通知だったり、という場面のコンピュータ版だと言えます。最近はこういう詐欺がたくさんありますから具体例を挙げる必要はありませんね。要点は、接続を開始する相手が信用できなければ、その接続は一切信用できないということです。EVS 自体の側から手順を始めるのでない限り、上に挙げた目標をすべて実現する API 利用のためのセキュアな認証システムは設計不可能です。
(略: 手順 2 で、それっぽいページに誘導すれば認証情報を盗める)
(略: そうした詐欺を企業自体が後押ししているような風潮もある)
(略: スタンドアロンのアプリなら、ログインを詐称する必要すらない)
この種の攻撃は前述のセキュリティ文書で「4.1.4. 脆弱性を突かれたブラウザや組み込みブラウザを使ったエンドユーザ認証情報のフィッシング脅威」として分類されています。提案されている解決策は？
クライアントアプリがユーザに直接認証情報を求めることは避けるべきだ。加えて、エンドユーザはフィッシングや良い習慣について教育を受けることもできる。良い習慣は、たとえば信用できるクライアントにしかアクセスしないことだ。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 に少しでもアクセス権限のある職員に本来の権限より多い権限を取得させてしまい、本来アクセスできないはずのところに許可が下りてしまう危険があります。別の例では、仮に Facebook が GMail 用の 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 がたくさん見つかります。Google は OAuth の色々な利用方法を提案していますが、その中に、両方を一緒に使うことを広めるフローがひとつあります:
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 業界によくあるやり方で、この既に猛威をふるっている問題は、パレードの参加者がどんどん増えて、人が使っている手法や、使っている「と思う」手法をコピーしていくことで、とどまるところを知らない連鎖になっています。
おそらく、上記のサービスを使っているシステムのうち、この問題のせいで悪用可能なものは多数あることと思います。特にデスクトップアプリでは、コンパイルされたアプリのバイナリから秘密情報がそのまま取り出せることは、サービス側で何も危険なことを要求していなくてもよくあります。Google が OAuth の使い方を多数提供しているうちで、client_secret と redirect_uri を両方受け取るエンドポイントのことが書いてあるのはたったひとつだけだというのは重要な点です。少なくとも Google の場合、redirect_uri があっても、このエンドポイントをウェブブラウザベースのアプリには推奨していません。しかし、だからといって実際に独自ブラウザでそれを使う人や、このフローを標準的なブラウザ用のエンドポイントにコピーする人が一切いなくなるはずがありません。それに加え、Google は例外なのであって、世の中にはセキュアな OAuth フローを受け入れず client_secret (や同等品) を常に渡すよう要求する愚かなサービスが今も満ちあふれており、そのフローがウェブブラウザを通るときでさえも要求しているのです。さらに悪いことに、こうしたサービスの多くはユーザのウェブブラウザを通して「しか」利用できないのですが、これは後ほど詳述します。
日本国内において家庭用ゲーム市場の衰退が叫ばれる中、スマホ用ゲームアプリこそが最後のフロンティアであると各企業はこぞって開拓船に奴隷を乗せて送り出している。
アプリは毎日のように生まれ出で、さながら夜空を埋める星のようである。そして生まれた星にはイナゴの群れが取り付き、多くはその重みと自重に耐え切れず地上へ落下し星屑と成り果てている。この星屑の組成は100%が糞であるから世界は糞とイナゴの死骸まみれで阿鼻叫喚である。
では落ちない星はどうなのか、これは落ちるまでは糞でないと言える。どれもいつか落ちるだろうとは熟練イナゴの話だが、パズドラなんかはもう3年もかぷかぷと笑っている。イナゴ諸兄におかれましては取り付く星を選ぶに当たり将来の糞とこういった綺羅星とを区別する基準を手に入れるべきである。
他のイナゴに一歩差をつけたいあなたがするべきことは何か。イナゴは主に2chのスマホアプリ板とiphone板に生息している、そこを観察するのがよい。確認するのはリセマラの必要度合い、ただこの一点である。これが高いゲームは糞である。
リセマラが必要になるということはつまり、ゲーム内通貨（Nが出ないガチャを回すためのもの、以下これをパワストーンと呼ぶ）のゲーム内入手方法が限られており、プレイアブルかどうかがガチャの景品のレアリティに大きく依存していてなおかつ同レアリティ間でも格差が激しい（金特をよこさないPR以下に人権はなく、リセマラするならSR彼女一択。ただしエミリと小筆は除く）、加えてその排出率が極めて小さい（具体的にはSR以上で3%前後。ただしこの中には森河一派が含まれている）ことを意味するからだ。これは一般に糞ゲーである。6分以上かけて単発で1%未満の当たりを狙う過酷な労働に多くの青少年は心身を破壊され二度とボールを握れない体になってしまった。またリセットのたびに大量のデータの再DLを促すコナミが各通信事業者と癒着関係にあることも明白である。焦らずそのうちメダルでSRチケを取ればいいじゃないという意見もあろうが、これにはやはり過酷な労働を強いられる上に、森河一派によって神経衰弱に陥る危険性もあり、国際労働基準の観点からは賛同しかねる。
安易にランキングイベントを乱発しその都度累計ボーダーを上げていくコナミには猛省が必要であるが、パワストーンのゲーム内配布が大幅に緩和された点を持って良運営とする向きも無いではない。しかしいくら配られたところで出ないものは出ないのだからこれに意味はないというのもうなずける話である。ランキングイベントの乱発はモードの少なさに起因するところが大きい、すみやかなペナントの実装が待たれる。
何にせよ伊集院の愛したパワプロは死に絶えた。彼が出したコナミへの絶縁状はまことに正しいものであった。
ところで、皆が皆ネイティブアプリを作りだしたためグリーは任天堂に先んじて死んでしまった。無念である。
任天堂のスマホ参入についての記事がいろいろ出てるけれど、岩田社長はゲーム系メディアのインタビューは
基本的に受けてくれないので突っ込んだ話が出てこない。
日経ビジネスの井上理記者はゲーム業界に詳しい方で、岩田社長の覚えもめでたくよくインタビュー記事を書いておられる。
しかしその記事は溢れる任天堂愛にほっこりするばかりで、厳しい部分にはノータッチでなんとももどかしい。
（後半の記事で詳細が話されるかもですが、厳しい質問は出てこないはず）
http://business.nikkeibp.co.jp/article/topics/20150319/278932/
そこで、某西田宗千佳氏などのインタビューお断り系のズバズバ切り込むメディアが訊きそうなことについて考えてみた。
あえて嫌味っぽく痛いところを突いてみたつもり。
スマートデバイスにどのようなソフトを出すべきか、どんな課金方法にすべきかといった課題を解決するためには数年の検討を
必要としたが、それは決して遅くないと伺いました。
しかし、モバイル業界はコンシューマー業界よりも環境の変化が早い世界であり、経営判断の遅さが命取りになりかねません。
事実、パートナーであるDeNAさんはブラウザゲームからネイティブアプリへの変化への対応が遅れ、一線を退いたという過去を
持っておられます。
「スマホは順調だがコンシューマーへの動線ができず、コンシューマーの売上が落ち込む」
といった現在想定しているシナリオとのズレが出てきたときの方向修正をどのようにイメージされておりますでしょうか。
それとも、変化が起きてからまた数年を費やして熟考するのでしょうか？
任天堂の強みはハードソフト一体型ビジネスであり、それを生かせないスマートデバイスでは長期的なビジネスを持続することは
困難だから決して手を出さないと繰り返しおっしゃってこられました。
しかし、他社のハードウェアが前提となる環境でも任天堂の強みを発揮できるとの結論に至り、今回スマートデバイスへの
そこから想像できることは、コンシューマービジネスにおいても、ソフトの内容や料金体系その他の課題について真剣に
考え抜くことで、ハードソフト一体型ビジネスに拘わる必要はないという「答え」を導き出せるのではという検討も
当然なさっておられるのではないかということです。
減少が続く自社ハードでの独占に拘らず、マイクロソフトやソニーなどの他社ハードにソフトを供給することは、
任天堂ユーザーの全体数を増加させることにつながります。それは今回のスマホ展開の目的でもある「ゲーム人口の拡大」
数年後、
「ずっと否定してきたが、実は前からソフト専業化について考えてきた。ようやく全体像がまとまったので今回発表することができた」
「時は来た」
というお話を聞かせて頂ける可能性があるのではないでしょうか。
2014年の5月、10月に行われた決算発表会で、それぞれ新興国への展開の進捗に関する質疑応答がございました。
そこで、先進国向けのプラットフォームを持っていくだけでは価格の面で難しいので、新興国向けの製品を開発中であるというお話がありました。
今回発表された「コードNX」は、この新興国向けに開発中の廉価ハードだと考えてよいのでしょうか。それとも、平行して2つの製品の開発を
行っているのでしょうか。
スマートデバイスにおけるDeNAとの役割分担に関する説明の中で、DeNAはバックエンドのサーバー周りのシステムの開発を任せるが、
ソフト開発はIP貸しではなく任天堂自身が中心となって行うというお話がございました。
現在、任天堂は携帯機と据置機の2つのゲーム専用機プラットフォームを展開しておられますが、ソフトの発売スケジュールに大きな空白が
しばしば発生し、定番タイトルの投入により一時的に販売が上向くことがあっても勢いを維持できずに失速するという状態が続いています。
現在の2つのプラットフォームへのソフト供給に苦しむ中、スマートデバイス、コードNXを加えた4つのプラットフォームの維持に必要なソフトを
供給していくための具体的な施策をお持ちであればぜひお聞かせください。。
あるいは、開発リソースには限りがあり、ソフトの品質や数を大きく増やすことは困難であるため、増えた分だけどこかを削るといった
方針なのでしょうか。
ゲーム専用機への情熱を失っていないことをアピールすることを目的として今回コードNXについて発表されたとのことですが、
「スマートデバイスやコードNXに注力する分だけ、現行の家庭機向けの開発リソースは減らされるのではないか」
「Wii Uと3DSは早期に終息に向かい、ソフトが出なくなってしまうのではないか」
ミドルからローレンジのSIMロックフリーWindows Phoneを各社がどんどん出すようだけど、
http://pc.watch.impress.co.jp/docs/news/20150227_690388.html
freetel、2015年夏までにWindows Phone 8.1搭載スマホを国内販売
マウスコンピューター、Windows Phone参入の背景にあるもの
http://pc.watch.impress.co.jp/docs/column/ubiq/20150223_689555.html
http://www.windowsphone.com/en-gb/how-to/wp8/basics/feature-and-service-availability
だから、いま出回っているSIMロックフリーWindows Phoneを買って、Mapsを立ち上げても、何も表示されない。
ストアアプリでGoogle Mapsのオフィシャルでないアプリが無料ダウンロードできるが、広告表示が惨すぎで使い物にならない。
方向音痴にとって、まともな地図アプリが使えないことは致命的なんだけど、
近々、Windows PhoneのMapsが日本をサポートする予定があるんだろうか？
それとも、国内でWindows Phoneを発売しようとしている各社は、この問題について知らんぷりしているんだろうか？
答えがどちらであるかによって、今後Windows Phoneを買うかどうか決めたい。
HTML5でモバイルのアプリはネイティブアプリからWebアプリとか記事書いてた人たち息してる？
全てがとって変るわけではなくて、ネイティブアプリでないと表現し辛いものはネイティブアプリで開発が行われるでしょう。しかし、モバイルがもっとWebアプリになれば、プラットフォーム毎の言語を習得しなくてもJavaScriptで書けるとか言ってた人息してる？ネイティブアプリで普通に出来ることをモバイルWebアプリでやろうとすると難易度高いよね。超高いと言った方がいいかな？企業はAppleやGoogleへ収益のいくらかを払わなくて済むから今後そうなって行くでしょうとか言ってた人息してる？これからはHTML5の時代とか言ってたキュレなんとかの人も息してる？そうやって煽ってた人達はモバイルWebアプリは思ったより厳しかったという記事書いて欲しいね。もう書いてあって俺が知らないだけかもしれないが
「ソーシャルゲーム協会」なる団体があったことに驚き、
「そんな団体があったとして、パズドラその他がまだ流行ってるのに業界団体が潰れるわけないだろ、釣りだろ」とおもって検索すると本当にそういうニュースがあることに驚き、
一方、これと入れ替わるように台頭してきたのが、スマホでアプリをダウンロードして遊ぶスマホゲームだ。ガンホー・オンラインエンターテインメントが12年にリリースした「パズル＆ドラゴンズ（パズドラ）」は大ブレークし、これまでに累計3200万ダウンロードを記録。
という文に、「えー！？パズドラとかはソーシャルゲームに含まれないの？」とソーシャルゲームという単語の定義を揺さぶられ、
『パズル&ドラゴンズ』（ガンホー・オンライン・エンターテイメント）に代表されるスマートフォン向けの「ネイティブアプリ」[3]のゲームもソーシャルゲームと呼ばれることがあるが、
という文に安心し、
直後の
という文に「えーマジか！自分の『ソーシャルゲーム』の定義は正確じゃなかったのか」
と再度ショックを受けた。
今30代中盤で社内SEとして事業会社に勤務しており、転職は考えてませんが、
Web系の企業でネイティブアプリの開発をやるか、元請けSIerで業務系SEをやるか、迷ってみました。
迷っている理由はこうです。
・Web系
プロダクトマネージャーとして面白いB2Cサービスを開発できるという点は魅力的です。
自分の才覚次第で大金を手にすることが可能な点も魅かれるものがあります。
ただし、40代、50代になって体力や成長速度が落ちたときに、エンジニアを続けられるか、という不安が拭えません。
一生、最新技術の学習とアウトプットを続けていく覚悟が必要ですが、正直言って
10年後も続けられる自信はありません。
市場の変化が激しく、数年後に会社の業績が悪化し、職を失うリスクもあります。
自社の深い業務知識を身につけて、社内コンサルを目指すことになります。
ゼロベースでシステムの構想を練ることが出来るのは最高にエキサイティングで、
社内SEにしか出来ない特権ですが、社内の調整仕事は面倒ですし、
・業務系SE
20代の頃はSIerで働いていたので、モノつくりへのこだわりや誇りがあり、
ベンダーが質の低いコードでシステムを作ると、自分で作り直したくなります。
また、30代になってくると、元請けSIerの給料の良さを感じます。
ただし、今あるフルスクラッチorアドオン必須のSIerの世界は確実に崩壊し、
クラウドの向こう側にある半製品を業務にどうフィットさせるか、という
正直、モノつくり出来ないなら社内SEやってた方が楽しいだろうなと思います。
今30代前半でSEとして元請けSIerに勤務しておりますが、転職を考えており、
Web系の企業でネイティブアプリの開発をやるか、ユーザ企業で社内SEをやるか、凄く迷っています
迷っている理由はこうです。
・Web系
当面の年収が高めである点と、面白いB2Cサービスを開発できるという点は魅力的です。
ただし、40代、50代になって体力や成長速度が落ちたときに、エンジニアを続けられるか、という不安が拭えません。
一生、最新技術の学習とアウトプットを続けていく覚悟が必要ですが、正直言って
10年後も続けられる自信はありません。
市場の変化が激しく、数年後に会社の業績が悪化し、職を失うリスクもあります。
・業務系SE
ある特定分野の深い業務知識を身につけて、PMを目指すことになります。
当面は仕事を続けることができるでしょうが、SIという業態のシュリンクは
避けられず、10年、20年先に会社があるのかどうかも不明です。
元請けSIerで仕事をしていたときに、ユーザ企業の社内SEのかたと話す機会がありました。
ITの会社ではないユーザ企業には、技術に長けた人も少なく、できる人に仕事が集中しがちです。
クラウドなどがユーザ企業でも身近になり、ITとビジネスが直結してきているなか、
ユーザ企業の社内SEとしてビジネスに貢献していけたら、とても楽しそうだと思います。
今20代後半でWebエンジニアとしてベンチャーに勤務しておりますが、転職を考えており、
Web系の企業でネイティブアプリの開発をやるか、元請けSIerでSEをやるか、凄く迷っています
迷っている理由はこうです。
・Web系
当面の年収が高めである点と、面白いB2Cサービスを開発できるという点は魅力的です。
ただし、40代、50代になって体力や成長速度が落ちたときに、エンジニアを続けられるか、という不安が拭えません。
一生、最新技術の学習とアウトプットを続けていく覚悟が必要で すが、正直言って
10年後も続けられる自信はありません。
市場の変化が激しく、数年後に会社の業績が悪化し、職を失うリスクもあります。
・業務系SE
ある特定分野の深い業務知識を身につけて、PMを目指すことになります。
売り上げは大きくありませんが、安定しており、10年、20年先も恐らく
仕事を続けることができるでしょう。
ただし、賃金は年功序列であり、急激な年収増加は見込めません。
またプロジェクトごとの変化が少ないので、退屈に感じるかもしれません。
理由くらい書けよ糞が
他のWindowsプログラムがやっていて、多くの方が「できて当然」だと思っていることは、7割くらいであれば.NET(フレームワーク名)を叩けばできます。
.NET対応言語はC#、VB.NET、J#、F#、JScript.NET、C++/CLIなどがあり、実際の開発においてはこれらの中から自分に合った言語を選ぶことになります。
個人的な感想ですが、この中で最もゆとり仕様なのはC#です。StackOverflowなどのノウハウが一番蓄積されているのもC#だと思います。
「頻繁なアップデートを追跡しないといけない」「Visual Studioが必要」という問題はありますが、がんばってください
なお、.NETはメモリを食うので、数値計算みたいなことをしたいのであればC++が現状一番まともだと思います。がんばってください
昔のMacのプログラムのGUIはCarbonというライブラリで作っていました。今はCocoaというライブラリで作っています。
残念なことに、どちらも言語はObjective-Cです。がんばってください
ブラウザアプリは、ユーザのWebブラウザ(Chrome、Firefox、Opera、Safariなど)上で動作するシステムと、遠隔のサーバ上で動作するシステムが連携して成立します。
従って、ブラウザアプリを作る言語は、サーバ用言語とクライアント用言語の2種類を考えなければなりません。めんどくさいですね。
ひとたびそのめんどくささを突破してしまえば、Webブラウザさえあればどこでも動くようになります。素晴らしいですね。
クライアント用の言語は、まぁ、JavaScriptしかないと思います。がんばってください
JavaScriptも(正直なところ)あまり褒められた言語ではないので、近頃ではもうちょっとまともな言語を作って、それをJavaScriptに変換する方法が取られたりします。CoffeeScript、TypeScript、Haxeとかですかね。がんばってください
JScriptとかいう、名前が紛らわしい上にゴミブラウザ上でしか動かないゴミ未満言語もありますけど、そんなもんで作っても私の環境では動かせませんので悪く思わないでください。
そもそも選択肢が全くありませんので仕方がないです。がんばってください
Xamarinがあるじゃないかって？まぁそういうのもあるかもしれませんね。がんばってください
私の勉強不足で、Java以外の選択肢は知らないです。Java以外にあるんですかね？
Perlは使い捨てスクリプトを作るのに適しています。CPANクライアントは昔から安定して動きません。だいぶオワコン化してます。がんばってください 私は鞍替えしました
PythonはPerlより見た目がすっきりしたPerlです。easy_install・pipはすごく安定していてびっくりします(Windows除く)。3系とかいう邪念は捨てて2系教の悟りを開きましょう。がんばってください
RubyはPerl(の処理系のソースコード)より(処理系のソースコードが)綺麗なPerlです。私の手元のUbuntuで「ruby」と入力すると「Command not found.」と返ってくることからも解るとおり、多くの*NIXではOS標準でインストールされておりません。昔のgemは何故あんなにすごい時間をかけてrdocを作っていたのでしょうか。日本人が作ったのでムラ意識の強い日本人の仲間が大勢います。他の国は知りません。がんばってください
これ以上言語を増やすのはやめましょう。バベルの塔で大勢の人間が不幸になったのに、それを人間が自ら引き起こしてどうするんですか。
言語処理系を作るのであれば、BNFという言語で文法を定義して、yacc・bisonというツールに食わせればひな形ができます。ぶら下がりelseとの格闘が待ってますが、がんばってください
1からOSを作った方もいますが、デバイスドライバの流用などを考えると、だいたいはLinuxやBSDのソースコードを改変するお仕事だと思います。
昔はCGIと言っていました。所詮は80番ポートでlistenするだけのプログラムであり、BSDソケットをlistenできるライブラリを有する言語であれば何でもいいのですが、いくつかの宗教があります。
PHPはバンドネオンと同じくらい習得が困難な言語なのに、宣伝の仕方を間違えたために「自分はできる」と勘違いしたプログラマが暴徒と化し、イスラム教と同じくらい不当に低く評価されている言語です。きちんと勉強して使う分には、悪くない選択肢だと思います。がんばってください
Javaは、Eclipse・Netbeansといった超重量級IDEを起動して、Java EEやSpringといった超重量級ライブラリに依存したwarを、Jboss・WebSphereなどの超重量級アプリケーションサーバ上で動作させるため、メモリが貧弱な環境ではIDEとサーバを同時に起動すらできません。サーバのメモリが潤沢であれば悪くない選択肢だと思います。がんばってください
C#は、選択肢が全くないことを除けば、状況はJavaとあまり変わりません。Microsoftがお好きな方、何かの間違いでWindowsサーバを使わざるを得ない方であれば、悪くない選択肢だと思います。がんばってください
Goはよくわからないですがきっといい言語です。がんばってください
http://business.nikkeibp.co.jp/article/opinion/20140411/262770/
ソシャルゲームが没落してるんじゃなくて、ブラウザを使ったゲーム主体からネイティブアプリ主体に移行しているから。パズドラもドラクエも全部ネイティブアプリなんだから。で、GREEは未だに、スマホ対応とは名ばかりのクソゲーを量産してる。今ドリランドとかやってみたらクソ臭にビックりするよ。しかも起動させるたびにGREEのアカウントと認証させられるし、画面重いしで不快感しか生まないっていうのが現状。
つまらない、画面が汚い、二重の認証がクソ。これがGREEの3重苦。
ガンホーだって色々言われているとは思うけれど、GREEはそれを遥に下回るクソぶりだ。ガンホーの社長が「彼ら（GREE・Mobage）とは合わない」っていうのはまぁ合ってると思う。
ケムコやカルチャーブレーンはクソゲーメーカーだったけど、ゲームメーカーではあった。最低限。だけど、GREEはゲームメーカーですらない。そんな会社がいつまでも儲けていることのほうがよっぽどおかしいだろ。
で、もっとびっくりするのがこの記事。
http://diamond.jp/articles/-/50656
なんと、今年出た記事だ。2012年ごろに出た記事ではない。
1回でもまともに今流行ってるアプリをプレイしたなら恥ずかしくてこの記事は書けないと思うけど。アプリをインストールするだけならタダでできるんだけど。
取材しろよ。
