エンジニアの独り言

勉強会のメモとか、日々感じたことを忘れないように

PS4リモートプレイアプリでPS4に接続する際にPSN(PlayStaionNetwork)ログインで「サーバとの接続を確立できませんでした(18.xxxxxxxxxx)」エラーとなる場合の回避策

勉強会の記事とかじゃないです。すみません。

忙しかったのが少し落ち着いたのでPS4でもやるかと思ったらリモート接続できなくて30分ほど調べたので備忘録として残しておきます。

概要

こう言う状態をどう回避するか？と言う話。

ログインエラー

なぜこの記事を書いたのか？


WIndowsだと回避手順を解説する動画とかが出回っているが、私はMacだったのでその方法が使えなかった。(もしかしたら似た方法で回避できるのかもしれないけど)

ちなみにその動画は「PSN サーバーとの接続を確立できませんでした」でgoogle検索すると上の方に出てくるはずなのでリンクは貼りません。

 多分、自分の検索力が弱くてこの方法を見つけられなかっただけなんだろうけど、将来の自分ためのメモとして残しておく。

 

手順

セキュリティソフトのファイアーウォール機能をOFFにするだけです。

 

以下、説明

Sonyの別のサービスだけど、回避手順の参考になったので載せておく。

この手順の中でPSNの記述が出てくる。

 

t.co

このPlayMemoriesOnlineと言うアプリとPS4のリモートプレイアプリの立ち位置が同じなのでは？と考えたので同じ手順できないか？を試してみた。

 

この手順の中でPSNのアカウント管理画面にサインインできるか確認してくださいと言う記述がある。

 

セキュリティソフトウェア(※)のファイアーウォール機能を無効にします。

と言う記載があるのでその通りにすること。

この状態でもう一度PS4への接続を行ったら自分はログインできるようになった。(ちなみに自分は手順にあるキャッシュの削除などはやってない)

※ ちなみに使っていたセキュリティソフトは「カスペルスキー インターネットセキュリティ」のchrome拡張を入れていた。それ以外のセキュリティソフトやchrome拡張なしの場合に同じような状況を引き起こすかどうかは検証していない。

 

chrome拡張の表示

 

どれがファイアーウォール機能に該当するのかわからなかったので、ONになっていた以下の機能を全てOFFにした。

* ウェブ保護

* Webトラッキング

* ネット決済保護

* 危険サイト診断

 

ただし、Sonyさんのページに書かれているように、設定をOFFにするのは一時的にすること。ログインできたら忘れずに元に戻してください。

(もし。このページを見た誰かが同じようにやって戻し忘れても責任は負いません)


これで久しぶりにtsushimaにいける。

13-c-3 社内システムの構造と設計、実装のはなし

デブサミ2014 勉強会
選んだ理由
  • 今触っているサービスではオープンな部分の機能追加よりも、社内向けの情報を表示したり、連携したりする改修のほうが多いので、その参考に。
  • よくあるダメダメな社内システムに対する改善を会社に伝えるときの参考。
ポイント 
  • 社内システムほど他システムとの連携をかんがえる。
  • JSONAPIで連携するのが良さげ。
  • OAuth流行、支配的になっている。
  • WebAPIの使用制限(googleMap,他OpenWebAPI)
  • トラフィック・レスポンスタイムを考慮する必要あり
  • コストを払うのは誰なのかを意識すること
社内システムについて
  •  性能より、機能があることのほうが優先される
  •  Long LifeCycle
  •  TargetUserが自分
問題点
  • 情報と権限を管理する人が別
  • 情報と機能の冗長化（悪い意味で）
  • UXの欠如
  • 自動化の障壁
  • 全部入り -> アップデート不可能
  • 社内システム連携 -> 危険極まりない
    • DB直接 -> 密結合
    • SOAP,CORBA,SOA -> 過去の遺物
    • rpc, ProtocalBuffer,Thrift,MessagePack -> Make it Simple
 権限の分断を最小限に。
  • 参照権限はフラットに、複数の方法で見れるように
  • UIはAPIを使うのがBest
  • 単機能ツールの連携で実現する -> アップデート容易性を担保する
  • 機能はAPIとして公開する
  • API互換性を担保すれば後ろ側を変えても問題ない
    • プロトコル
    • データ構造
    • ドキュメントに頼らないことが大事
  • 意味の一貫性
    • Success -> OKとか
  • クライアント要件の普遍性と不変性
    • クライアントを含めて社内システムです 
  • 長期運用のことを考えると
    • 見た目の分かり易さ
    • アップデートの容易さ
    • テストの容易さ
大事なのはコレ
  • 1 times curl >>> 100 pages dosc
  • ease to try >>> performance
  • loosely coupled >>> strict protocol
「いま」欲しいものだけを作る
  • 優先度ハック
    • 機能を切り刻む
  • 逆優先度ハック
    • 細かい機能追加タスク
    • 今いらないならあとで。
    • 細かいからいつでもできるでしょう。
    • 後でやればいいなら、今は作るな。
  • 要件定義は難しい
  • 開発・運用の前提がアーキテクチャをシンプルにする

社内システムほど試しやすいものはない -> だからいっぱい試してみようー。

13-b-2 グリーにおけるChef導入事例～既存の資産を活かし新しい技術を導入する～

デブサミ2014 勉強会
発表資料

https://speakerdeck.com/ryotarai/guriniokeruchefdao-ru-shi-li-ji-cun-falsezi-chan-wohuo-kasixin-siiji-shu-wodao-ru-suru

このセクションを選んだ動機

同一チームでChefベースで構築されているImmutableなインフラがあるが、
自分が担当している方にも展開できるようにまずは基礎知識として蓄えたいと思った

Chefとは？
  • Chef is Infrastracture as a Code
  • 冪等性が担保されている(何も入っていない別のサーバに対して実行する場合の話のはず)
    • altertableとかまでChefで行う場合は別テーブルに回避して、importするとかの処理を入れないといけない)
  • Mutable-Infrastractureと相性良い(Immutable-Infrastractureであっても十分有用性はある)
導入背景
  • Chefによる効率化
  • オペミスの回避
  • リードタイム改善（インフラチームに発注してからサーバをアプリチームに提供できるまで）
導入前の状態
  • GreeではDebianを使用
  • サーバ別のメタパッケージがそれぞれ存在し設定ファイルはスクリプトで生成していた
    • 各設定値パッケージ内部 or サーバ管理システムに問い合わせ
  • 既存のサーバ管理システムをそのまま使いたい
    • 上記の様な制限があるとchefを導入する際の障壁になることがあるので注意
    • 運用スクリプトがサーバ管理システムに依存しているため、構築済みのサーバはいままで通り運用
      • 既存サーバに関しては臨機応変さが必要。(JUnitなどと同じく管理対象外のものに対していきなり全展開をするのは厳しさがあるようで、追加分から始める方が良さそうに感じた)
導入
  • 構成



chef

 |- role

      |- cookbookA

      |- cookbookB

      |- nodeの属性

テストを書く
  • テストの方法
  • テストを書く理由
    • TDD的な開発の後押し
    • リグレッションを防ぐ
    • ドキュメント代わり
    • 本番サーバの構築テスト
  • TestKitchen
    • 単体test環境みたいなもの？
  • [WIP](=進行中の作業)でPullRequestを投げる
    • github - jenkins - ChefBridge で自動テスト
  • 共通node設定はYAMLでjsonに変換して使用
事件：Jenkinsサーバに繋がらなくなった
  • VertualBoxのHost-Only-Networkのルーティングが変わったため
    • Chefで更新をかけるときは要注意
テストに時間がかかると...
  • いろいろ手を抜く -> cookpadのプレゼンでも似たようなことを言っていた気がする。
    • vmのロールバック
      • sahara
      • TestKitchenドライバー
    • chefSpec
      • TestKitchenと同じ内容は書かないことでテスト時間の短縮
    • FoodCrinic
      • Lintツール
Chef導入により改善された運用
  • 何かしら障害があり、構築logが見たい場合
    • 以前：screenコマンドで手動保存したものを検索
    • Chef導入後 : 実行logはDBに保存(Chefのレポートハンドラ -> fluentd -> DB)
Chefを使うことによる利点として感じたこと
  • インフラ構築の高速化
  • インフラドキュメント= テストコード
  • Chefにすれば、vagrantで同じ環境作りやすそう。

(ただ、その環境を使ってアプリの単体試験をするとなると、ローカルPCのスペックが要求される)

  • Chef導入する際に、それにより何がデキるようになるのか？を意識してログやテスト方法を設計されていた？

13-c-1 cocos-2d-xにおけるスマートフォン開発のここまでとこれから

デブサミ2014 勉強会
発表資料

http://www.slideshare.net/syuhari/dev-sumi

選択した理由 
  • ゲーム開発は一切経験が無かったので、入門編として聞いてみようと思った。
使用する言語
cocos-2dと2d-xの違い
  • 2dはiOSappしかつくれない
  • 2d-xはiOS以外にAndroid等にも対応
cocos-2d-xについて
  • 全てがcocos-2d-xで実装できるわけではなく、課金やnotificationについてはそれぞれの言語で実装する必要がある。
  • Androidは描画が重いので、音声と同期させるのは難しい
  • バージョンアップするとメソッド名が変わったりするので最初に選定するときに調査を詳細にする必要がある。(バージョンアップ＝作り直し)
 実例紹介
  • スターウォーズ的なスクロール -> カメラ位置をしたから見上げるようにして画像を上にスクロールさせると実装できる
  • ver3からはC++λが使えるようになり、開発効率アップ
  • COCOSTUDIO  今はWINDOWS版だけだがMac OS版の開発が始まった。
Javascriptバインディング
Action
  • 簡単なゲームを作ってみよう
  • facebookにコミュニティあるのでコミュニティに参加しよう
感想
  • ゲーム開発の経験は無いが、ざっくりどんなことができるのかは理解できた。
  • オブジェクトの移動経路を作りだすのに物理的な素養がある程度必要であることを理解した。
  • マルチプラットフォームで開発するにはcocos-2d-xであることが必要(cocos-2dではiOSappしか作れない)

デブサミ2014に行ってきました(ブログを始めたきっかけ)

デブサミ2014 勉強会

今年のデブサミの

【14-B-L】悩める金融系SEの軌跡～COBOLからScalaへ～

を聞いて、行動を起こさないと何も始まらないといっていた(行動を起こした結果がCOBOL -> scala)のを聞いて、

まずは、自分が思ったことをアウトプットすることから始めようと思いました。

どこかの勉強会で聞いた「勉強会に参加したら自宅に帰ってブログに書くまでが勉強会」というのもトリガーになっています。

（どこで聞いたか忘れてしまいましたが…）

 

各セクションの感想は順次追加していきます