S+になりました!!!
スプラトゥーンを11月末に初めて早5ヶ月、やっとS+になりました。
わかバリアつよい!
Intensity shuttleを使ってMacでWii Uを録画する
負けた試合の分析や、プライベートマッチでふざけてる動画がとれるのは楽しい!ということで、録画の環境を紹介。
紹介すること
- 最短の手順
- Intensity Shuttle for Thunderboltとは
- HDMIスプリッター USB給電タイプを購入した話
- 動画の録画にはOpen Broadcaster Software(通称OBS)
- Nintendo Creators Programについて
手順
Wii U→Intensity Shuttle→TV
の構成をHDMIでつなぐIntensity Shuttle→Mac
をThunderboltで繋ぐ- Wii Uの設定で画面解像度を720oに選択する
- Open Broadcaster Software(通称OBS)のMac版をインストール
- OBSを立ち上げて、Wii Uをソースに追加する
- OBSの設定
- 録画して、Youtubeにアップロード
述べた手順で撮った動画がこちら
Intensity Shuttle for Thunderboltとは
パススルー方式で、1080p30fpsや720p60fpsで録画可能なキャプチャボードです。 USB3.0方式とthunderbolt形式があり、自分はMacなので後者を選択。
手頃な値段かつそれなりの高画質(1080p60fps)を探してたんですが、はMacユーザーにとって、あまり選択肢は多くなさそうです。
ヨドバシかどこかの家電量販店のキャプチャボードランキングでも、Mac対応のものではこれが1位でした。
※パススルー方式とは、キャプチャボードを通すものの、アウトプットにラグがない形式のキャプチャボード
HDMIスプリッター USB給電タイプを購入した話
理由は2つ
MediaExpressをアクティブにしてないとTVにソース(Wii Uの画面)が転送されない
Wii U→Intensity Shuttle→TV
で接続するとMacでアプリを開いて、アクティブにしておかないとWii Uのプレーができません。
MacのChromeやFinderを見たりすると、画面の転送がストップしてしまう。。。
たまに暗転する
プレー中にTVが真っ暗になるケースが何回かありました。1試合に1回は起きてるかな。
録画は問題なくされてるが、プレーに響くので結構辛い
ということで、自分はHDMIスプリッター USB給電タイプ を購入しました。
USB給電式のいいところは、Wii Uから電源をとれるところ。 これで今のところ、キャプチャしたい時だけMacをつないでいます。
※スプリッタの購入と同時にHDMIケーブル1.5m を2本買うことをお忘れなく。
構成
そんなに難しくないですね。PS4を繋ぎたくなったら今度はスプリッタの前にHDMIの切替器をおいて、PS4とWii Uをつなぐのだろうか・・・?
ただし、ブラビアリンクが使えなくなるとのレビューを見かけたし、PS4はデフォルトで録画機能がついてるので、今はWii Uのみ。
mp4に変換していおいて、Youtubeをストレージとして使うのが利口なのではないかと思う。
Nintendo Creators Programについて
Youtube上のNintendoの著作物での広告売上をシェアする仕組み。もともと、任天堂の著作物を含む動画の広告売上はすべて任天堂に入ってたけど、それが投稿者にシェアされるようになった。
プログラムが適用されるソフトも決まってるのでYoutubeに動画を投稿する際には確認すべし。
公式: https://r.ncp.nintendo.net/guide/
Wikipedia: Nintendo Creators Program - Wikipedia
Splatoonの動画を取るだけで、任天堂様に貢献できるのはいいこと。イカのサポートは長くやってほしい。
OBSの設定
OBSの設定には、
- 全体設定(
global.ini
) - 動画の設定(
プロファイル
)
の、2つがあります。
いい感じにしたファイルをGoogle Driveにあげておいたので使ってみてください。
OBS > ファイル > 設定フォルダーを表示
のbasic
といフォルダとglobal.ini
というファイルを置き換えれば、1280x720の動画がmp4で取れるようになっています。
Wii Uのキャプチャに必要だったもの
SplatoonのAmiibo3種(ボーイ、ガール、イカ)ゲット!+α
やっとSplatoonのAmiiboを3種類ゲットしました!!!!!!!
ミッションクリアするとギアがもらえるので、粛々とネットで調べてたんですよ。
しかしネットではびこるのは転売
元値は単体で1200円、トリプルセットで3000円なのですが、
1つ2000円くらいしてたりして、買う気になれなかった。いまは、1600円くらいに落ち着いてるけど、転売ヤーが儲かるところが気に喰わないので定価ゲットを狙ってた。
Amazonプライムなら定価だろうという謎の自信に満ち溢れてたんですが、へし折られました(笑)
1月中旬には多くの家電量販店で再販されたみたいだが即品切れのよう。
ノジマオンラインやヨドバシ.comでも売り切れだったので諦めていた。
しかし、Twitterでは「店頭に普通に売ってたー」と複数見かけたので、朝イチで渋谷のヤマダに行ってきました!
イカが残り1こ、ガール、ボーイは残り2こだったので、運が良かった!
早速、ガールのミッションをクリアしまして、イカパッチンやらヒーローチャージャーレプリカをゲットしました〜
普段、シューターの自分にとって、DJたこ将軍をチャージャーやるのは本当に辛かった。。。
ついでに
PS4のコントローラー充電器も買いました
アタッチメントを充電部分につけて置くだけ。
いままで、USBコードが1本しかなく、コントローラー1つをローテしながら使ってたが、これで解決。 ついでに、定位置に戻す、つまり片付けるようになりそうなので良さそう。
ちなみに2つおくとこんな感じ
イイネ!
お値段1900円ほど。
iPhoneをGenius Barに持って行く前にすること
Genius Barとは
iPhoneをはじめとするApple製品のカスタマーサポートで、各Apple Storeで専門スタッフが不具合をマンツーマンで聞いてくれるサービス。
私はiPhone5のWi-Fi接続不良、iPhone6の予期せぬ終了で計2度、お世話になりました。
前回持って行った時、スタッフと話していて勉強になったことを紹介。
予約する
当日行って受付するのもいいですが、予約してから行くとほとんど待たずに診てもらうことができる。当日だと予約できないことがあるので、2〜3日前に予約することをおすすめ。
診断する
予約時に診断することが強制されている。入力したメールに診断URLが添付されてくる。それを開くと診断が始まり、Appleに型番をはじめとするiPhoneのハード情報が送信されるため、店頭で設定を開いて型番などを教える必要がなくなる
DFUモードによる復元
バックアップをしてから実行してください。
PCにつなぎ、iTunesに繋いだ状態でホームボタンと電源ボタンを押し続けると、基盤レベルの復元モードになる。
店員さんいわく、「普通のリストアと違い、これでソフトウェアの問題なのか、ハードの問題なのかの切り分けができる。ソフトの問題ならこれで直る。実行後1週間くらい試験的につかってみてください」
また、急にアプリが強制終了するようになったり、動作がもっさりする場合もこれで直るケースが有るという。ただし、この方法は公にしていない。
フロー
したがって、持って行く前に
- DFUモードによる復元を行う
- 試験運用
- なおらなければ予約
- 診断
というフローをとれば、交換したい時だけお店にいけばいいことになります。
保証対象かどうかは、スタッフに尋ねないとわからないので、無償で交換できるか知りたい場合も行く必要あり。 対象外の場合はまるごと交換で3万4,5千円でした(2016/1/31時点のiPhone6 128GB)。
まとめ
- Apple Storeに持ってく前にやるべきはDFU復元、試験運用、予約、診断
- 保証対象かどうかはお店で知ることができる
- 保証対象なら無償、対象外なら3万程度かかる
- DFU復元は動作が重くなった、急にアプリが強制終了するようになったなどの場合にも直るケースがある
- DFU復元は非公式
iTunes Connectでアプリがレビューに入ったとか、リジェクトされたとかをslackに通知する
から、派生して作った。ヤマトはラインで見れちゃうのでいらない子になっちゃったしね。今まで、一部の人がメールを受け取った際にチームに共有してたのでタイムラグや共有し忘れを防ぎたくてつくった
今回もGMailを定期的にGoogle App Scriptで読み込んで、SlackのWebhookを叩くという流れ。
iTunes Connectからくるメールの件名はフォーマットが決まってるのでそれに応じて通知を変えたら見やすくなりました。
レビューが通った場合はこんな感じ
ステータスは全部で8つかな。
- Processing for App Store => アップロードが完了し、アプリの処理中の状態
- has completed processing => アップロード後の処理が完了した状態
- Waiting For Review => 申請が完了しました。レビュー待ちな状態
- Developer Rejected => アプリの申請を取り下げた状態
- In Review => レビューに入った状態
- New message from App Review => レビューアプリに対して、Appleより連絡があった状態。おもに仕様の確認やリジェクトの時
- Pending Developer Release => レビューを通過した状態
- Ready for Sale => 公開処理が完了し、ストア反映待ちな状態
特に、"has completed processing"は1時間で終わるときから1日位かかるときもあったので、見逃しがちだった。これで迅速な申請作業に移れそう。
ソース
Google App Scriptから直接Slackに通知
割と本気で家庭用Slack Botを作ってみた - 八発白中 がかなり、あついですね。
VPSはおもちゃ箱なんだなあと、ゆめがあるなあと感じます。
とはいえ、お金をかからない方法をとるという強かなスタンスもまた、アリです!
またまたやってみました。Google App Scriptの定期実行。
今回はヤマトからの未読メールかつ、不在通知メールがあれば、notificationチャンネルにメール内容を投稿し、さらにメールを既読にするGoogle App Script。
これをGoogle App Scriptのcron機能で1時間毎とかに実行する
フックをDocsやらCalendarの更新などにすれば使いみちはいくらでもあるので、テンプレとして今後使えそう。
以前、Spread Sheetの情報をマスタとしてゴミの日の前日にSlackに翌日がなんのゴミの日かを通知cronを実装した時の話を書きましたが
IFTTTを介さずともslackに通知できるし今後はIF GAS Then Slackスキームで行こうと思う。
ナプラケアテクトリペア
シャンプーとコンディショナーをリピート
fluentd(td-agent)でGoogle Cloud Storageにログをためる
初めてrubyを書いた。mixinとかいろいろ省略してかけるとかaliasをメソッドに貼るとか便利だなーというのが感想。
gemの公開もbundleコマンドでさくさく出来たのでこれは開発者にとってかなり魅力的なのでは。エコシステム?が素晴らしい。
さて、本題ですが、今、開発中のfluentdのoutputプラグインの使い方をメモ。Fluentd(td-agent)からGoogle Cloud Storageにログのファイルを直接置くという役割。
ルビー書き始めて2日なのでまだまだクソース&開発中です。まさかりまってます
gem
fluent-plugin-google-cloud-storage-out | RubyGems.org | your community gem host
github
モチベーション
Google Cloud Storage (以下、GCS)にとりあえずログを置く
GCSに置いとけばあとからBigQueryにインポートできるので、生ログをとりあえずここにためて置くと良さそう。
BigQueryにストリーミングインサートするとお金がかかるし、安定してなかった?という話もあったので、直接GCSに置くことに。
とはいえ、各ホストからログのアグリゲーションをするのもめんどくさそう。いっそ各々でtd-agentが動いてるのでそこから送っちゃおうという魂胆
さらには、オンプレミスで減価償却するよりもクラウドの値段が下がるほうが速いんじゃないのかな。GCSはとてもやすい。
一応既存のものはあったが
fluent-plugin-google-cloud-storage | RubyGems.org | your community gem host
というgemがすでにあったが、最新のGoogle Client APIや認証の形式についていっていないようだし、gem公開をしたかったのでw
使い方
インストール
よしなにgemで
Service Accountを登録し、認証情報(.json)をよしなに配置
GCSのAPI状態がEnableか確認して、鍵を作成。
td-agent.confを編集
<match *.log> type google_cloud_storage_out service_account_json_key_path /etc/td-agent/client_secrets.json bucket_id log-hangar path activity/%Y_%m_%d/${hostname}_%H%M_${unique} unique_strategy timestamp unique_format %S format json compress gzip buffer_type memory buffer_chunk_limit 100m </match>
- service_account_json_key_path 名の通り、jsonキーのパス
- bucket_id => bucketは現状は作成済みでなければならない
- path => GCS上のファイルパス。unique_strategyを設定する場合、
${unique}
をパスに含まなければならない。含まない場合はローテートされるまえにバッファのフラッシュが2回起きると上書きされてしまう - unique_strategy => [increment, timestamp, chunk_id]から選択。
${unique}
をどう置換するかの実装を選ぶ。- increment => 0, 1, 2, ...とカウンタが使われる
- timestamp => フォーマットに従って、バッファフラッシュ時のタイムスタンプに置換
- chunk_id => バッファのchunkのユニークIDに置換する
- unique_format => timestampの場合に使われる。
- format => デフォルトのfileアウトと同じ実装
再起動
よしなに.テスト時はバッファのmemory容量を10kとか低い値にするとテストしやすかった
参考にしたもの
- fluent-plugin-google-cloud-storage
- PRもいくつか送っているが、そもそもこれを参考に書きなおしている
- google-api-ruby-client
- gemを公開するまでの手順
- 数コマンドでクソースをパブリッシュできちゃう怖さ。
- 検索: fluent-plugin-redshiftとかたくさんある。GCS関連はまだ上述のものと私が書いたものの2つだけ。
展望
- ドキュメント
- ユニットテスト
- ストレステスト
- エラーハンドリング
- コードスタイルに合わせる
- 英語を良くする
まとめ
fluentdがプラガブルなので、素人でもとりあえず動くプラグインはかけた。fluentdすごい